Agile가 Waterfall보다 제시하는 거짓 약속

Source: Dev.to

워터폴 vs. 애자일 신화

20년 동안 우리는 Waterfall이 고대 유물—경직되고 관료적이며 근본적으로 부서졌다는 신화를 받아들여 왔습니다. 한편, Agile은 인증, 컨설턴트, 그리고 의심할 여지 없는 교리와 함께 종교적 지위에 올랐습니다.

나는 두 방법론 모두에서 시스템을 구축하며 15년을 보냈습니다. 팀이 스프린트하면서 건축적 재앙을 초래하는 모습을 목격했습니다. 48시간마다 변화를 수용하려다 완벽히 좋은 엔지니어들이 번아웃되는 것도 보았습니다.

왜 워터폴이 특정 프로젝트에서 애자일보다 더 나은 성과를 낼 수 있는가

깊은 아키텍처 의존성을 가진 복합 시스템

워터폴의 악명 높은 순차적 접근 방식은 애자일의 파편화된 점진적 개발보다 더 나은 소프트웨어를 만들어내는 경우가 많습니다.

애자일의 “매혹적인 이야기”

애자일은 작은 반복, 지속적인 피드백, 적응형 계획이라는 이야기를 판매합니다. 실제로는? 극장입니다.

• 플래닝 포커 예시 – 간단한 API 엔드포인트를 3 스토리 포인트로 추정하고 모두가 동의합니다. 다음 스프린트에서 리팩터링하려는 인증 시스템과 해당 엔드포인트가 어떻게 상호 작용할지에 대해서는 아무도 언급하지 않습니다.
• 단기 집중 – 애자일은 금요일까지 무언가를 전달하는 것을 보상하고, 6주 뒤를 생각하는 것을 장려하지 않습니다.

3개월 후, 그 엔드포인트가 적절한 캐싱을 방해하고 모바일 팀이 하나 대신 세 개의 별도 API 호출을 하도록 강요합니다.

개발자들은 실제로 어떻게 일하는가

프로그램을 작성하는 방식이 애자일이 제시하는 대로는 아니다. 우리는:

1. 문제에 대해 생각한다
2. 아키텍처를 스케치한다
3. 의존성을 이해한다
4. 그런 다음 구축한다

워터폴은 이 자연스러운 인지 과정을 형식화했다. 애자일은 이를 파괴했으며, 그 파괴를 “진보”라고 불렀다.

• 맥락 전환 비용 – 작업을 전환하면 약 20–25 분 정도 집중력이 손실된다. 일일 스탠드‑업과 스프린트 중간에 우선순위가 바뀌는 2주 스프린트에서는 깊은 작업을 하는 것이 아니라, 인터럽트 기반 개발을 하게 된다.
• 단계 일관성 – 워터폴은 명확한 단계(분석, 설계, 구현, 테스트)를 제공한다. 각 단계는 한 번에 하나의 문제 영역에 머무르게 하여 깊은 집중을 가능하게 한다.

지속적인 반복은 아키텍처 근시증을 낳는다: 2주 계획 수립은 2주 문제에 최적화된다. 6개월치 기술 부채를 줄일 수 있는 리팩토링조차 스프린트에 들어가지 않는다.

실제 사례

회사: 재무 보고 플랫폼 구축.

애자일 코치 조언: “작게 시작하세요. 워킹 스켈레톤을 구축하세요.”

Result: 기술 부채가 상환될 수 있는 속도보다 더 빠르게 축적됩니다. 이는 방법론이 장기적인 아키텍처 일관성보다 단기 기능 속도를 최적화하기 때문입니다.

Waterfall’s Counterpoint

• 분석 (3 주) – 요구사항을 정의하고, 첫날부터 레거시와 블록체인 정산을 모두 처리할 수 있는 데이터 모델을 설계합니다.
• 설계 → 구현 → 테스트 – 견고한 기반 위에 순차적으로 구축합니다.

네, 첫 번째 기능은 나중에 출시되지만, 4개월 차에 파고들 필요가 없는 기반 위에 배치됩니다.

Source: …

애자일에서의 아키텍처 침식

애자일은 아키텍처가 중요하지 않다고 가장한다. 그 결과는 시스템 일관성이 한 스프린트씩 서서히 감소하는 것이다.

1. 무해한 지름길 – 개발자가 기능을 빠르게 배포하기 위해 컨트롤러에서 직접 DB 호출을 추가한다.
2. 패턴 복제 – 다음 스프린트에 다른 사람이 그 패턴을 보고 그대로 따라한다.
3. 6개월 후 – 레이어드 아키텍처는 스위스 치즈보다 구멍이 더 많아진다.

잘 수행된 워터폴 프로젝트에서는 구현이 시작되기 전에 의도적으로 아키텍처 경계가 설정된다. 구현은 설계를 실현할 뿐이며, 스프린트마다 새로 설계하지 않는다.

Waterfall이 (또는 그 구조적 장점이) 의미가 있을 때

단순히 “우리는 이제 워터폴을 진행합니다”라고 선언할 수는 없지만, 그 구조적 장점을 다시 통합할 수는 있습니다.

워터폴의 강점을 프로세스에 통합하는 방법

1. 실제 설계 단계 만들기 – 주요 이니셔티브 전에 설계를 위해 멈추세요: 요구사항 분석, 아키텍처 설계, 설계 검토.
2. 중단 없는 구현 시간 보호 – 개발자가 회의에서 벗어나도록 구현 시간을 할당하세요.
3. 탐색과 실행을 구분 – 일부 스프린트는 탐색용이어야 하고, 다른 스프린트는 검증된 설계에 따라 순수하게 실행해야 합니다. 두 가지를 혼합하지 마세요.
4. 기술 부채를 아키텍처 위반으로 가시화 – 구현이 의도된 설계와 벗어나는 구체적인 사례를 추적하세요.
5. 스프린트 전에 명세 작성 – 핵심 아키텍처에 영향을 주는 기능은 먼저 사양을 작성하세요.
6. 아키텍처 검토를 릴리즈 게이트로 – 주요 릴리즈 전에 아키텍처 상태를 검토하세요.

마무리 생각

워터폴의 순차적 구조는 버그가 아니라; 깊은 아키텍처 일관성을 요구하는 복잡한 시스템에 있어서는 오히려 기능이었다.

• 구축 전에 생각하는 것은 낭비가 아니라, 기본이다.
• 구현 전에 설계하는 것이 경직된 것이 아니라, 책임감 있는 행동이다.

애자일은 우리에게 귀중한 도구들을 제공했다: 긴밀한 피드백 루프, 이해관계자 협업, 경험적 적응. 그러나 그것은 반복을 과대평가하고 아키텍처를 과소평가했다.

양쪽의 장점을 차용함으로써—애자일의 민첩함과 워터폴의 체계적인 계획—우리는 속도를 희생하지 않으면서도 견고하고 유지보수 가능한 시스템을 제공할 수 있다.

앞으로의 길은 애자일도 워터폴도 아니다.
각 접근법이 최적화된 것이 무엇인지 이해하고, 양쪽의 장점을 취하는 하이브리드 방식을 구축하는 것이다.

진자는 너무 한쪽으로 치우쳤으며, 더 나은 소프트웨어는 중간 어딘가에 있다.

Read more at agilelie.com