#CS#Methodology#Agile#Waterfall
애자일 vs 워터폴: 개발 방법론
계획대로 착착 진행하는 워터폴, 변화에 민첩하게 대응하는 애자일. 우리 팀에는 어떤 방식이 맞을까요? 무조건 애자일이 정답은 아닙니다.
2025년 6월 2일
Codemapo
계획대로 착착 진행하는 워터폴, 변화에 민첩하게 대응하는 애자일. 우리 팀에는 어떤 방식이 맞을까요? 무조건 애자일이 정답은 아닙니다.
내 서버는 왜 걸핏하면 뻗을까? OS가 한정된 메모리를 쪼개 쓰는 처절한 사투. 단편화(Fragmentation)와의 전쟁.
미로를 탈출하는 두 가지 방법. 넓게 퍼져나갈 것인가(BFS), 한 우물만 팔 것인가(DFS). 최단 경로는 누가 찾을까?
이름부터 빠릅니다. 피벗(Pivot)을 기준으로 나누고 또 나누는 분할 정복 알고리즘. 왜 최악엔 느린데도 가장 많이 쓰일까요?
매번 3-Way Handshake 하느라 지쳤나요? 한 번 맺은 인연(TCP 연결)을 소중히 유지하는 법. HTTP 최적화의 기본.
개발자라면 익숙한 풍경이 있습니다. 기획자는 "이거 간단하죠?"라며 마감 3일 전에 스펙을 바꿉니다. 디자이너는 "이 버튼 1픽셀만 옮겨주세요"라고 배포 직전에 요청합니다. 개발자는 "안 돼요, DB 구조를 다 뜯어고쳐야 해요"라고 절규합니다.
이 영원한 고통의 굴레를 끊기 위해 수많은 천재들이 고민했습니다. 그 결과 탄생한 두 가지 거대한 흐름이 바로 워터폴(Waterfall)과 애자일(Agile)입니다. 처음엔 "그냥 옛날 방식 vs 요즘 방식 아니야?"라고 생각했는데, 알고 보니 둘은 "불확실성(Uncertainty)"을 다루는 철학 자체가 완전히 다르더군요.
제가 처음 프로젝트를 진행할 때는 이 차이를 몰라서 많이 헤맸습니다. 애자일이라고 하면서 실제로는 워터폴처럼 일하거나, 워터폴이 필요한 상황에서 무리하게 애자일을 적용하려다가 실패하는 경우를 많이 봤죠. 이제는 각 방법론이 왜 존재하는지, 언제 써야 하는지 명확하게 이해하게 됐습니다.
워터폴은 이름 그대로 물이 위에서 아래로 떨어지듯, 거슬러 올라갈 수 없는 방식을 말합니다. 이 방식은 원래 건축(Architecture)과 제조업(Manufacturing)에서 왔습니다.
워터폴이 "나쁜 것"은 아닙니다. 실패 비용이 천문학적인 경우에는 워터폴이 필수입니다.
하지만 소프트웨어(Software)는 이름 그대로 "Soft(부드러운)"한 것입니다. 콘크리트로 짓는 건물이 아닙니다. 6개월 동안 설계도대로 만들었는데, 그 사이에 경쟁사가 더 좋은 기능을 내놓으면? 우리 제품은 나오자마자 쓰레기가 됩니다. 이것이 워터폴의 가장 큰 약점, "변화에 대한 무능력"입니다.
제가 처음 SI 프로젝트를 했을 때, 6개월 동안 열심히 만들었는데 막상 오픈하니 고객이 "아, 이게 아닌데..."라고 하는 걸 경험했습니다. 그때 깨달았죠. 소프트웨어는 건물이 아니라는 걸.
2001년, 유타 주의 스키 리조트에 17명의 개발자가 모였습니다. (켄트 벡, 로버트 마틴 등 전설적인 인물들이죠.) 그들은 선언했습니다. "우리는 불확실한 미래를 예측할 수 없다. 그러니 계획을 따르기보다 변화에 적응하자."
애자일의 핵심은 "짧게 만들고, 빨리 욕먹자"입니다. 1년짜리 프로젝트를 2주 단위(Sprint)로 쪼갭니다.
이렇게 하면 1년 뒤에 엉뚱한 물건을 만들 확률이 0%에 수렴합니다. 방향을 2주마다 수정(Pivot)할 수 있으니까요.
처음엔 "2주마다 배포? 그게 가능해?"라고 생각했는데, 막상 해보니 이게 정말 효과적이더군요. 고객 반응을 빨리 받으니까 잘못된 방향으로 가는 시간을 엄청나게 줄일 수 있었습니다.
애자일은 "철학(Mindset)"이고, 이것을 실제로 수행하는 방법론(Framework)은 따로 있습니다.
가장 널리 쓰이는 프레임워크입니다. 럭비 용어에서 따왔습니다.
도요타 자동차 공장에서 유래했습니다.
To Do → Doing → Done 포스트잇을 붙입니다.Doing 칸에는 딱 3개만 붙일 수 있다는 식의 룰을 정합니다.
스크럼이 "관리"에 초점을 둔다면, XP는 "기술적 실천"을 강조합니다.
"스크럼으로 일하면서 XP의 기술을 쓰는 것"이 최강의 조합입니다. 제가 팀에서 이 조합을 시도했을 때, 코드 품질이 눈에 띄게 좋아지는 걸 경험했습니다.
많은 회사들이 "우리는 애자일해요"라고 말합니다. 하지만 실상은 이렇습니다.
이것을 "Water-Scrum-Fall"이라고 부릅니다. 겉무늬만 스크럼이고, 속은 여전히 수직적인 워터폴인 것이죠. 애자일의 핵심인 "권한 위임(Empowerment)"과 "실패 용인" 문화가 없으면, 애자일은 그저 "개발자를 쪼는 도구"로 전락합니다. "2주 안에 무조건 끝내!"라고 채찍질하는 건 애자일이 아니라 Death March(죽음의 행진)입니다.
제가 처음 "애자일"이라는 회사에 들어갔을 때, 이런 가짜 애자일을 경험했습니다. 스탠드업은 하는데 의미가 없고, 스프린트는 하는데 기획은 바뀌지 않고... 그때 깨달았죠. 애자일은 형식이 아니라 문화라는 걸.
애자일의 꽃은 회고입니다. 회고가 없으면 애자일이 아닙니다. 많은 팀이 회고 시간에 "수고하셨습니다" 하고 끝내거나, 남 탓만 하다가 싸움이 납니다. 제대로 된 회고를 위해서는 KPT (Keep, Problem, Try) 방식을 추천합니다.
단순히 반성문 쓰는 시간이 아닙니다. "우리가 일하는 방식을 고치(Refactor)는 시간"입니다. 코드만 리팩토링하지 말고, 팀의 프로세스도 리팩토링하세요.
애자일을 한다면서 "이거 몇 시간 걸려요?"라고 묻는다면 하수입니다. 애자일에서는 시간(Time) 대신 규모(Size)를 추정합니다. 이것을 스토리 포인트(Story Point)라고 합니다.
이렇게 합의된 포인트로 스프린트의 양을 조절합니다. "우리 팀은 지난번에 30포인트를 처리했으니, 이번에도 30포인트어치 일만 가져오자." 이것이 지속 가능한 속도(Sustainable Velocity)를 만드는 비결입니다.
처음엔 "이게 뭔 소리야?"라고 생각했는데, 막상 해보니 시간 추정보다 훨씬 정확하더군요. 상대적인 크기로 비교하니까 오히려 더 명확했습니다.
"팀원이 500명인데 스크럼을 어떻게 하나요?" 스타트업이 커지면 스크럼 1개로는 감당이 안 됩니다. 이때 등장한 것이 스포티파이(Spotify)의 조직 구조입니다. (지금은 스포티파이도 안 쓴다는 소문이 있지만, 업계 표준 용어가 되었습니다.)
이 구조의 핵심은 "자율성(Autonomy)과 정렬(Alignment)의 조화"입니다. 각 스쿼드는 자율적으로 결정하되, 챕터를 통해 기술적 정렬을 맞추는 것이죠.
| 구분 | 워터폴 (Waterfall) | 애자일 (Agile) |
|---|---|---|
| 적합한 분야 | 건축, 하드웨어, 금융 차세대 | 스타트업, 웹/앱 서비스, AI |
| 요구사항 | 처음에 확정 (불변) | 계속 바뀜 (환영) |
| 고객 참여 | 시작과 끝에만 | 전 과정에 참여 |
| 실패 시점 | 프로젝트 끝날 때 (재앙) | 2주 뒤 (기회) |
| 팀 구조 | 기획팀/디자인팀/개발팀 분리 | 기능별 목적 조직 (Squad) |
| 문서 | 방대하고 상세함 | 필요한 만큼만 (Just Enough) |
무조건 애자일이 정답은 아닙니다. 여러분이 만약 은행의 원장 이관 시스템을 만든다면, 애자일하게 하다가 돈이 사라지면 큰일 납니다. 철저한 워터폴이 맞습니다. 하지만 여러분이 "시장 반응을 아직 모르는 신규 서비스"를 만든다면, 워터폴은 자살 행위입니다.
중요한 건 방법론의 이름이 아닙니다. "우리는 지금 불확실성과 싸우고 있는가, 아니면 복잡성과 싸우고 있는가?" 불확실하다면, 빨리 실행하고 빨리 실패하세요. 그게 가장 싸게 먹히는 길입니다.
제가 여러 프로젝트를 경험하면서 깨달은 건, 방법론은 도구일 뿐이라는 겁니다. 중요한 건 우리 팀의 상황에 맞는 도구를 선택하는 것이죠. 애자일이든 워터폴이든, 팀이 잘 돌아가고 고객이 만족하면 그게 정답입니다.
"Agile is not about going faster. It is about learning faster." (애자일은 더 빨리 가는 게 아니라, 더 빨리 배우는 것입니다.)