4편 : V-모델과 애자일, 기획자는 어디에 서 있어야 할까?

 

지난 글에서 저는, 계획대로만 흘러가지 않는 IT 프로젝트의 현실 속에서
워터폴, 반복적 모델, 점증적 모델, 나선형 모델을 차례차례 경험하며
'완벽한 계획'보다는 '지속적인 조정'이 더 중요하다는 깨달음을 얻게 되었다고 말씀드렸었습니다.

 

그리고 이제, 이 구조와 유연함의 양 극단을 동시에 품은 두 가지 방법론을 이야기하려고 합니다.

 

바로 V-모델과 애자일(Agile) 입니다.

 

 

V-모델 – ‘계획’과 ‘검증’을 동시에 추구한 방식

---

 

[V-모델]

 

V-모델은 겉모습만 보면 워터폴의 쌍둥이처럼 보입니다.
기획 → 설계 → 구현 → 테스트 → 배포, 흐름은 비슷하지만, 가장 큰 차이는 테스트 단계가 사전에 짝지어져 있다는 것이에요.

 

즉, 기획을 했다면 그에 대응하는 수용 테스트가,
설계를 했다면 단위 테스트나 통합 테스트가
미리 연결되어 있어, "우리가 만든 게 제대로 된 건가?"를 한눈에 확인할 수 있도록 구조화된 모델이죠.

 

이 구조는 기획자 입장에서 꽤 반가웠습니다.
테스트의 책임과 목적이 선명해지고,
"이건 우리가 이렇게 설계했으니까, 이렇게 검증하자"라는 합의가 가능해졌거든요.

 

하지만…

 

V-모델도 결국 ‘계획 중심’ 모델입니다.
한 번 설계가 정해지면, 그에 따라 구현하고 테스트하는 구조라
중간에 기능이 바뀌거나 요구사항이 수정되면 모든 걸 다시 맞춰야 하죠.

 

저는 실제로, 테스트 단계에서 기획 실수로 인한 구조적 오류가 드러났는데
그걸 수정하기엔 너무 늦어버린 프로젝트를 경험한 적이 있어요.

 

"이미 거대한 V의 오른쪽 끝에 와 있었기 때문이죠." 🫠

 

V-모델은 똑똑했지만, 현실의 변화 속도까지 감당하긴 어려웠습니다.

 

 

애자일 – 계획보다 ‘사람’이 먼저인 방법론

---

 

애자일

 

 

이쯤에서 세상은 점점 더 빠르고, 유연하고, 예측 불가능해지기 시작했습니다.
이럴 때 등장한 것이 바로 애자일(Agile) 방법론입니다.

 

애자일은 기존의 방식과는 발상이 완전히 달라요.

 

“계획을 따라가는 게 아니라, 변화를 수용하는 것이 더 중요하다.”

 

 

처음엔 충격이었죠.
“계획 없이 개발을 한다고?”
“매일 아침 회의를 한다고?”
“일정을 2주 단위로 쪼갠다고?”

 

하지만 그 안에 담긴 가치는 꽤 인상 깊었습니다.

 

• 고객과의 소통이 문서보다 우선되고,
• 변화하는 요구사항도 반영할 수 있어야 하며,
• 협업과 커뮤니케이션이 핵심이라는 이야기.

저는 특히 스크럼(Scrum) 방식의 프로젝트에서
기획자의 역할이 얼마나 능동적이어야 하는지를 새삼 깨달았어요.

 

매일 아침 데일리 미팅에서 “어제 뭐했어요?”, “오늘 뭐해요?”, “어디 막혔어요?”를 공유하고,
2주마다 “이 기능 괜찮았나요?”, “어떤 반응이 있었나요?”를 검토하며
기획자는 항상 지금 무슨 기능이 개발되고 있고,
그 기능이 왜 필요한지를 팀 전체에 설명할 수 있어야 했습니다.

 

기획이 ‘끝나고 전달되는 것’이 아니라,
‘계속 같이 만들어가는 것’이 된 거죠.

물론, 장점만 있는 건 아니었어요.

• 끝없는 변경에 시달리며 일정 감각이 흐트러지기도 하고,
• 계속되는 회의와 검토로 체력 소모도 컸으며,
• 무엇보다 ‘정신적 여유’를 가지기 힘든 프로젝트도 있었죠.

하지만 분명했던 건,
애자일이야말로 기획자가 진짜 ‘기획자’로서 존재할 수 있는 환경이라는 거였습니다.

 

기획자는 어디에 서야 할까?

---

이쯤 되면 이런 질문이 생길 거예요.

“그럼 어떤 방법론을 써야 돼요?”

 

정답은 없습니다.
상황에 따라, 팀에 따라, 프로젝트의 성격에 따라 달라질 뿐입니다.

실제로 저는

• 프로젝트 초기 설계는 V모델처럼 정리하고,
• 구현 단계는 애자일 스프린트로 진행하며,
• 리스크가 큰 기능은 반복적 프로토타이핑으로 먼저 검증하고,
• 전체 로드맵은 점증적 모델처럼 계단식으로 쪼개서 접근하는 식으로
  혼합 전략을 사용하는 경우가 많았습니다.

중요한 건 ‘어떤 방법론을 쓰는가’보다
그 방법론을 어떻게 잘 활용하는가예요.

 

그리고 기획자는
그 중심에서 팀을 조율하고,
문제의 본질을 파악하며,
‘지금 어떤 방법이 가장 적절할까’를 계속 고민하는 역할을 맡고 있죠.

 

방법론은 도구일 뿐, 핵심은 사람

---

 

결국 제가 느낀 건 이거였습니다.

방법론은 그냥 도구다.
프로젝트를 성공시키는 건, 결국 사람이다.

 

기획자도, 개발자도, 디자이너도
서로가 어떤 상황에 있는지 공감하고,
함께 문제를 풀어가는 태도가 진짜 중요했어요.

정답 같은 프로세스를 따르기보다는,
우리가 잘 협업할 수 있는 방식을 같이 만들어가는 것.

 

그게 진짜 ‘좋은 방법론’ 아닐까요?