애자일 vs 워터폴: 개발 방법론

우리는 왜 항상 쫓기는가?

개발자라면 익숙한 풍경이 있습니다. 기획자는 "이거 간단하죠?"라며 마감 3일 전에 스펙을 바꿉니다. 디자이너는 "이 버튼 1픽셀만 옮겨주세요"라고 배포 직전에 요청합니다. 개발자는 "안 돼요, DB 구조를 다 뜯어고쳐야 해요"라고 절규합니다.

이 영원한 고통의 굴레를 끊기 위해 수많은 천재들이 고민했습니다. 그 결과 탄생한 두 가지 거대한 흐름이 바로 워터폴(Waterfall)과 애자일(Agile)입니다. 처음엔 "그냥 옛날 방식 vs 요즘 방식 아니야?"라고 생각했는데, 알고 보니 둘은 "불확실성(Uncertainty)"을 다루는 철학 자체가 완전히 다르더군요.

제가 처음 프로젝트를 진행할 때는 이 차이를 몰라서 많이 헤맸습니다. 애자일이라고 하면서 실제로는 워터폴처럼 일하거나, 워터폴이 필요한 상황에서 무리하게 애자일을 적용하려다가 실패하는 경우를 많이 봤죠. 이제는 각 방법론이 왜 존재하는지, 언제 써야 하는지 명확하게 이해하게 됐습니다.

워터폴 - "완벽한 설계"의 로망

워터폴은 이름 그대로 물이 위에서 아래로 떨어지듯, 거슬러 올라갈 수 없는 방식을 말합니다. 이 방식은 원래 건축(Architecture)과 제조업(Manufacturing)에서 왔습니다.

프로세스 - 한 번 지나가면 끝이다

1. 요구사항 분석 (Requirements): 고객이 원하는 모든 것을 문서로 남깁니다. (이 단계에서 문서만 수백 장이 나옵니다.)
2. 설계 (Design): DB 스키마, 아키텍처, UI 기획을 완벽하게 끝냅니다. "블루프린트(청사진)"를 그리는 단계입니다.
3. 구현 (Implementation): 설계도대로 코딩만 합니다. 이 단계에서는 기획을 바꿀 수 없습니다.
4. 테스트 (Verification): 다 만든 후 버그를 잡습니다.
5. 유지보수 (Maintenance): 오픈 후 고칩니다.

워터폴이 필요한 순간

워터폴이 "나쁜 것"은 아닙니다. 실패 비용이 천문학적인 경우에는 워터폴이 필수입니다.

• 건축: 아파트를 10층까지 지었는데 "화장실 위치를 바꿉시다"라고 할 수 있나요? 못 합니다. 처음부터 완벽하게 설계해야 합니다.
• 의료 기기 / 항공 우주: NASA에서 화성 탐사선을 쏘는데 "일단 쏴보고 궤도 수정하죠"라고 못 합니다. 버그 하나가 수조 원의 손실이나 인명 피해로 이어집니다.
• SI 프로젝트: 계약서에 정의된 기능 목록 100개를 납기일 내에 딱 맞춰야 돈을 받는 구조에서는 워터폴이 가장 "안전한" 선택입니다.

소프트웨어에서의 비극

하지만 소프트웨어(Software)는 이름 그대로 "Soft(부드러운)"한 것입니다. 콘크리트로 짓는 건물이 아닙니다. 6개월 동안 설계도대로 만들었는데, 그 사이에 경쟁사가 더 좋은 기능을 내놓으면? 우리 제품은 나오자마자 쓰레기가 됩니다. 이것이 워터폴의 가장 큰 약점, "변화에 대한 무능력"입니다.

제가 처음 SI 프로젝트를 했을 때, 6개월 동안 열심히 만들었는데 막상 오픈하니 고객이 "아, 이게 아닌데..."라고 하는 걸 경험했습니다. 그때 깨달았죠. 소프트웨어는 건물이 아니라는 걸.

애자일 - "혼돈을 친구로 만들기"

2001년, 유타 주의 스키 리조트에 17명의 개발자가 모였습니다. (켄트 벡, 로버트 마틴 등 전설적인 인물들이죠.) 그들은 선언했습니다. "우리는 불확실한 미래를 예측할 수 없다. 그러니 계획을 따르기보다 변화에 적응하자."

애자일 선언문 4가지 핵심 가치

1. 공정과 도구보다 개인과 상호작용을
2. 포괄적인 문서보다 작동하는 소프트웨어를
3. 계약 협상보다 고객과의 협력을
4. 계획을 따르기보다 변화에 대응하기를

핵심 원리 - 피드백 루프

애자일의 핵심은 "짧게 만들고, 빨리 욕먹자"입니다. 1년짜리 프로젝트를 2주 단위(Sprint)로 쪼갭니다.

• 2주 동안: 기획, 디자인, 개발, 테스트, 배포를 다 합니다.
• 2주 후: 동작하는 제품을 고객에게 보여줍니다.
• 피드백: "이 버튼 불편해요." → 바로 다음 2주 계획에 반영합니다.

이렇게 하면 1년 뒤에 엉뚱한 물건을 만들 확률이 0%에 수렴합니다. 방향을 2주마다 수정(Pivot)할 수 있으니까요.

처음엔 "2주마다 배포? 그게 가능해?"라고 생각했는데, 막상 해보니 이게 정말 효과적이더군요. 고객 반응을 빨리 받으니까 잘못된 방향으로 가는 시간을 엄청나게 줄일 수 있었습니다.

애자일의 실천 도구들

애자일은 "철학(Mindset)"이고, 이것을 실제로 수행하는 방법론(Framework)은 따로 있습니다.

스크럼 - 규칙이 있는 단거리 달리기

가장 널리 쓰이는 프레임워크입니다. 럭비 용어에서 따왔습니다.

• 스프린트(Sprint): 보통 2주 단위의 개발 주기. 이 기간에는 외부 간섭(기획 변경)을 차단합니다.
• 역할:
  • PO (Product Owner): "무엇을 만들지" 결정합니다. 고객의 대변인.
  • Scrum Master: "방해물을 제거"합니다. 팀이 잘 달리게 돕는 코치.
  • Team: 실제 만드는 사람들.
• 이벤트:
  • 데일리 스탠드업: 매일 아침 15분. "어제 뭐 했고, 오늘 뭐 할 거고, 막히는 게 뭔지" 공유.
  • 스프린트 리뷰: 만든 걸 시연하고 박수받는 시간.
  • 회고(Retrospective): "다음엔 더 잘하려면 뭘 고칠까?" 반성하는 시간.

칸반 - 멈추지 않는 컨베이어 벨트

도요타 자동차 공장에서 유래했습니다.

• 시각화: 화이트보드에 To Do → Doing → Done 포스트잇을 붙입니다.
• WIP 제한 (Work In Progress): Doing 칸에는 딱 3개만 붙일 수 있다는 식의 룰을 정합니다.
  • 이게 핵심입니다. 일이 안 끝나면 새 일을 시작 못 합니다. 팀원들이 달라붙어서 병목을 뚫어야 합니다.
• 무한 흐름: 스프린트 같은 기간이 없습니다. 그냥 하나 끝나면 바로 배포합니다. 유지보수 팀에 적합합니다.

XP: 개발자의 극한 수련

스크럼이 "관리"에 초점을 둔다면, XP는 "기술적 실천"을 강조합니다.

• 짝 프로그래밍 (Pair Programming): 한 컴퓨터에서 둘이 같이 짭니다. 실시간 코드 리뷰 효과가 있습니다.
• TDD (테스트 주도 개발): 테스트 코드를 먼저 짭니다.
• 지속적 통합 (CI): 하루에도 수십 번 코드를 합칩니다.

"스크럼으로 일하면서 XP의 기술을 쓰는 것"이 최강의 조합입니다. 제가 팀에서 이 조합을 시도했을 때, 코드 품질이 눈에 띄게 좋아지는 걸 경험했습니다.

현실의 괴리 - "가짜 애자일"

많은 회사들이 "우리는 애자일해요"라고 말합니다. 하지만 실상은 이렇습니다.

• 아침에 서서 미팅(스탠드업)은 하는데, 부장님 훈화 말씀 시간이 된다.
• 2주마다 스프린트는 하는데, 1년치 기획서는 이미 확정되어 있다.
• "애자일이니까 문서 필요 없죠?"라며 기획서도 없이 말로 때운다.
• 배포는 3개월에 한 번 한다.

이것을 "Water-Scrum-Fall"이라고 부릅니다. 겉무늬만 스크럼이고, 속은 여전히 수직적인 워터폴인 것이죠. 애자일의 핵심인 "권한 위임(Empowerment)"과 "실패 용인" 문화가 없으면, 애자일은 그저 "개발자를 쪼는 도구"로 전락합니다. "2주 안에 무조건 끝내!"라고 채찍질하는 건 애자일이 아니라 Death March(죽음의 행진)입니다.

제가 처음 "애자일"이라는 회사에 들어갔을 때, 이런 가짜 애자일을 경험했습니다. 스탠드업은 하는데 의미가 없고, 스프린트는 하는데 기획은 바뀌지 않고... 그때 깨달았죠. 애자일은 형식이 아니라 문화라는 걸.

회고를 잘하는 법

애자일의 꽃은 회고입니다. 회고가 없으면 애자일이 아닙니다. 많은 팀이 회고 시간에 "수고하셨습니다" 하고 끝내거나, 남 탓만 하다가 싸움이 납니다. 제대로 된 회고를 위해서는 KPT (Keep, Problem, Try) 방식을 추천합니다.

1. Keep (지킬 것): 이번 스프린트에서 좋았던 점. "코드 리뷰를 꼼꼼하게 해서 버그를 미리 잡은 것 좋았어요."
2. Problem (문제점): 아쉬웠던 점. (사람을 비난하지 말고 현상을 말해야 함). "기획서가 개발 도중에 바뀌어서 야근을 했어요."
3. Try (시도할 것): 다음 스프린트에 당장 실행할 구체적인 액션 아이템. "다음부터는 기획 수정 시 마감일을 하루 늦추기로 합의해요."

단순히 반성문 쓰는 시간이 아닙니다. "우리가 일하는 방식을 고치(Refactor)는 시간"입니다. 코드만 리팩토링하지 말고, 팀의 프로세스도 리팩토링하세요.

스토리 포인트와 플래닝 포커

애자일을 한다면서 "이거 몇 시간 걸려요?"라고 묻는다면 하수입니다. 애자일에서는 시간(Time) 대신 규모(Size)를 추정합니다. 이것을 스토리 포인트(Story Point)라고 합니다.

왜 시간을 안 쓸까?

• 주니어에게 1시간짜리 일이 시니어에게는 10분짜리 일입니다. 기준이 다릅니다.
• 개발은 변수가 많아서 시간 예측이 원래 불가능합니다.

플래닝 포커 하는 법

1. 팀원들이 피보나치 수열 카드(1, 2, 3, 5, 8, 13, 21...)를 하나씩 갖습니다.
2. 기획자가 기능을 설명합니다. "로그인 페이지 만들기".
3. 하나, 둘, 셋 하면 카드를 냅니다.
   • A개발자: 3
   • B개발자: 8
4. 왜 차이가 나는지 토론합니다. (이 과정에서 숨겨진 복잡도를 발견합니다.)
5. 다시 투표해서 합의를 봅니다.

이렇게 합의된 포인트로 스프린트의 양을 조절합니다. "우리 팀은 지난번에 30포인트를 처리했으니, 이번에도 30포인트어치 일만 가져오자." 이것이 지속 가능한 속도(Sustainable Velocity)를 만드는 비결입니다.

처음엔 "이게 뭔 소리야?"라고 생각했는데, 막상 해보니 시간 추정보다 훨씬 정확하더군요. 상대적인 크기로 비교하니까 오히려 더 명확했습니다.

스포티파이 모델 - 규모의 확장

"팀원이 500명인데 스크럼을 어떻게 하나요?" 스타트업이 커지면 스크럼 1개로는 감당이 안 됩니다. 이때 등장한 것이 스포티파이(Spotify)의 조직 구조입니다. (지금은 스포티파이도 안 쓴다는 소문이 있지만, 업계 표준 용어가 되었습니다.)

1. 스쿼드(Squad): 가장 작은 단위의 팀(6-12명). 기획/디자인/개발이 다 있습니다. "작은 스타트업"처럼 독자적으로 움직입니다.
2. 트라이브(Tribe): 스쿼드의 집합. (예: 뮤직 플레이어 트라이브, 결제 트라이브).
3. 챕터(Chapter): 직군별 모임. (예: 안드로이드 챕터, 백엔드 챕터). 스쿼드는 다르지만 같은 기술을 쓰는 사람들끼리 노하우를 공유합니다.
4. 길드(Guild): 취미나 관심사 모임. (예: 와인 길드, 러스트 언어 길드).

이 구조의 핵심은 "자율성(Autonomy)과 정렬(Alignment)의 조화"입니다. 각 스쿼드는 자율적으로 결정하되, 챕터를 통해 기술적 정렬을 맞추는 것이죠.

비교 요약표

구분	워터폴 (Waterfall)	애자일 (Agile)
적합한 분야	건축, 하드웨어, 금융 차세대	스타트업, 웹/앱 서비스, AI
요구사항	처음에 확정 (불변)	계속 바뀜 (환영)
고객 참여	시작과 끝에만	전 과정에 참여
실패 시점	프로젝트 끝날 때 (재앙)	2주 뒤 (기회)
팀 구조	기획팀/디자인팀/개발팀 분리	기능별 목적 조직 (Squad)
문서	방대하고 상세함	필요한 만큼만 (Just Enough)

정리하면서 - 은탄환은 없다

무조건 애자일이 정답은 아닙니다. 여러분이 만약 은행의 원장 이관 시스템을 만든다면, 애자일하게 하다가 돈이 사라지면 큰일 납니다. 철저한 워터폴이 맞습니다. 하지만 여러분이 "시장 반응을 아직 모르는 신규 서비스"를 만든다면, 워터폴은 자살 행위입니다.

중요한 건 방법론의 이름이 아닙니다. "우리는 지금 불확실성과 싸우고 있는가, 아니면 복잡성과 싸우고 있는가?" 불확실하다면, 빨리 실행하고 빨리 실패하세요. 그게 가장 싸게 먹히는 길입니다.

제가 여러 프로젝트를 경험하면서 깨달은 건, 방법론은 도구일 뿐이라는 겁니다. 중요한 건 우리 팀의 상황에 맞는 도구를 선택하는 것이죠. 애자일이든 워터폴이든, 팀이 잘 돌아가고 고객이 만족하면 그게 정답입니다.

"Agile is not about going faster. It is about learning faster." (애자일은 더 빨리 가는 게 아니라, 더 빨리 배우는 것입니다.)