애자일에서 아키텍처 설계의 죽음

Source: Dev.to

20년 전, 애자일 커뮤니티는 물었다: 디자인이 죽었는가? 그들은 잘못 답했다.

나는 15년 동안 팀들이 “진화적 디자인”으로 시스템을 구축하는 모습을 지켜봤다. 그들이 속도를 축하하는 모습을 보았고, 그 시스템이 18개월 뒤 무너지는 모습을 보았다.

오해

Martin Fowler의 2004년 에세이는 전제 조건이 있었다: 숙련된 개발자, 포괄적인 테스트, 작은 시스템, 리팩터링을 할 수 있는 권한을 가진 팀.
조직들은 다른 모든 것을 무시하고 “사전 설계 없음”을 채택했다. 그 결과는 진화적 디자인이 아니라 우연적 디자인이었다.

확장 문제

시스템이 작을 때는 리팩터링 비용이 저렴하다. 하지만 시스템은 작게 머무르지 않는다.

나는 “발생형 아키텍처”를 받아들인 한 핀테크 기업을 컨설팅했다. 2년간 빠른 배포를 이어갔다. 그 후 다중 통화 지원을 추가하려 했지만, USD 가정이 모든 곳에 깔려 있었다. 한 달짜리 기능이 8개월이 걸렸다.

숨겨진 부채의 세 가지 카테고리

• 구조적 결합: 마이크로서비스가 네트워크 호출을 가진 분산 모놀리스로 변했다.
• 개념 파편화: “고객”이 세 개 서비스에서 각각 다른 의미를 가진다.
• 성능 부채: 하나의 기능에 대해 데이터베이스 쿼리가 17번 실행된다.

해결책

중요한 기능을 구현하기 전에 다음을 물어본다:

• 이것이 도입하는 새로운 개념은 무엇인가?
• 우리가 어떤 가정을 코드에 담고 있는가?
• 무엇을 변경하기 어려울까?
• 가능한 확장 지점은 어디인가?

한 팀은 아키텍처 스파이크에 하루를 추가로 투자했다. 6개월 후 푸시 알림을 추가하는 데 3스프린트가 아니라 3일이 걸렸다.

디자인을 되돌리기

애자일 선언문은 “계획을 따르는 것보다 변화에 대응한다”고 말한다. “계획이 없다는”을 말하는 것은 아니다.
선택적 압력이 없는 진화는 혼돈을 만든다. 소프트웨어에서는 그 압력이 바로 디자인이어야 한다.

전체 기사와 사례 연구 및 구현 체크리스트는 agilelie.com에서 확인하세요.