3편 : 프로젝트 방법론 1 - 누구나 계획은 있다.

 

두근두근! 드디어 프로젝트 방법론에 대한 이야기를 해볼 차례가 되었습니다.

우리가 왜! 프로젝트 방법론에 대해 알아야 하는지 궁금하신 분들은 1, 2편을 한 번 봐주세요!

 

 

프로젝트 방법론에 대한 고민은, 제가 소프트웨어 공학을 본격적으로 공부해 봐야겠다고 마음먹은 결정적인 이유였습니다.

 

IT 기획자로 전직하기 전, 저는 광고기획자로서 수많은 프로젝트를 진행한 경험이 있었습니다. 그래서 처음 IT 프로젝트를 맡았을 때도 익숙한 방식으로, 늘 해오던 프로젝트 관리 방법을 적용했죠.

 

광고주와 미팅하고, 전체 일정을 짜고, 외주사에게 업무를 맡기고, 마감을 맞추는 구조.
개발자에게 업무를 전달하고 진행 상황을 체크하는 모든 과정을, 말 그대로 ‘외주사에 요청하듯이’ 운영했습니다.

 

그리고…

 

제 첫 IT 프로젝트는 폭★파 됐습니다.

 

프로그램 개발은 일반적인 프로젝트와는 전혀 다른 매커니즘을 가지고 있었고,
그 차이를 뼈저리게 느낀 순간이었죠.

 

오늘은 그 이야기를, 그리고 제가 겪은 프로젝트 방법론에 대한 시행착오를 함께 나눠보고자 합니다.

---

 

워터폴 방법론 : 익숙하지만, 치명적인 한계를 품고 있었다.

제가 처음 접한 개발 방법론은 워터폴(Waterfall) 모델이었습니다.

 

기획 → 설계 → 개발 → 테스트 → 배포.

 

딱 봐도 순서대로 흘러가는 구조죠. 말 그대로 ‘폭포수’처럼 단계별로 차례차례 내려가는 방식입니다.

 

이거, 되게 익숙한데?

처음에는 이 방식이 참 익숙하게 느껴졌습니다.
기획서를 만들고, 디자인 시안을 확정하고, 외주사에게 맡기고, 결과물을 마감하는 구조.

 

광고기획에서도 늘 그렇게 해왔기 때문에 “개발도 결국 일정을 짜고, 문서화하고, 진행만 잘하면 되겠지”라고 생각했어요.

 

실제로 워터폴은 기획자 입장에서 장점도 많았습니다.

• 단계가 명확해서 일정 관리가 수월하고,
• 전체 일정을 예측하기 좋으며,
• 문서 기반으로 커뮤니케이션하기 때문에 초기 계획이 잘 잡혀 있으면 안정감도 있었죠.

이 방식에 대해 별다른 의심은 없었습니다.
오히려 “이런 시스템이라면 모든 프로젝트가 효율적으로 굴러가겠는데?” 싶을 정도였으니까요.

 

하지만 실무는… 계획대로 되지 않았습니다

 

당시 제가 맡았던 프로젝트 중 하나는
기획 단계에서 정의한 핵심 기능이 기술적으로 구현이 어려운 구조였습니다.
그런데 그 사실을 우리는, 테스트 단계에 와서야 깨달았습니다.

이미 개발은 거의 마무리된 상태였고, 전체 설계가 해당 기능을 전제로 구성되어 있었기 때문에 다시 구조를 수정하거나 처음부터 다시 짜는 건 현실적으로 불가능했죠.

 

결국 이 프로젝트는 해결책을 찾지 못한 채 종료되었습니다.

 

아무리 계획이 명확해도,
실현 가능한 구조가 아니면 아무 의미가 없다는 걸요.

 

그리고 그 실현 가능성을 중간에 검증할 수 없다는 것,

 

그게 바로 워터폴 모델이 가진 치명적인 한계였습니다.

워터폴은 처음부터 끝까지 일직선으로 흘러가는 방식이라,
뒤늦게 문제가 발견되면 앞으로 돌아갈 수 없고,
그러다 보면 프로젝트 전체가 한 번에 무너져버릴 수도 있습니다.

 

 

---

반복적, 점증적, 그리고 나선형 모델

워터폴 모델에서의 실패를 경험한 뒤, 저는 다양한 프로젝트에서 점점 새로운 방식들을 접하게 되었습니다.

바로 반복적 모델, 점증적 모델, 그리고 나선형 모델이었습니다.

 

이 방식들은 모두 워터폴의 단점을 보완하려는 시도였고,

실제로 실무에서 마주치는 수많은 변수들에 대응하기 위한 방식이기도 했습니다.

 

기획자 입장에서 이 방식들은 각각 다른 어려움과 장점을 가지고 있었지만, 결국 하나의 공통된 방향을 가리키고 있다는 것도 느낄 수 있었습니다.

 

“완벽한 계획보다는, 지속적인 확인과 조정”이라는 철학 말이죠.

---

반복적 모델 – 계속 만들어보고, 계속 바꿔가는 방식

프로토타이핑 과정

 

반복적 모델은 처음부터 완벽하게 만들려고 하지 않고, 기능의 일부 또는 프로토타입을 빠르게 만든 후, 테스트하고 피드백을 받아 다시 개선하는 과정을 반복하는 방식입니다.

 

처음에는 이 방식이 굉장히 낯설게 느껴졌습니다.

 

"기획이 끝나지도 않았는데 개발을 시작한다고?"

"계속 바꾸면 언제 끝나는 건데?"

 

이런 질문들이 머릿속에 맴돌았죠.

 

하지만 직접 프로젝트를 경험해보니, 초기 단계에서 결과물을 확인할 수 있다는 것만으로도 훨씬 안전하게 느껴졌습니다.
기획자 입장에서, 가설을 실제 기능으로 확인할 수 있다는 건 매우 큰 장점이었고, 고객이나 유저의 반응을 빠르게 반영할 수 있는 유연함도 큰 강점이었습니다.

 

반면 단점도 분명했습니다.

 

기획이 고정되지 않기 때문에 일정 관리가 어려워졌고,
“이게 끝인가?” 싶은 시점이 자꾸 뒤로 밀리는 경험도 자주 겪었습니다.
기획자가 전체 구조를 머릿속에 정확히 그리고 있지 않으면,
프로젝트가 방향성을 잃고 산으로 갈 수 있다는 점도 리스크였습니다. SI 프로젝트에서는 적합하지 않았죠.

---

점증적 모델 – 조금씩 쌓아 올리되, 방향은 확실하게

점증적 모델

 

점증적 모델은 기능을 작게 나눠서, 핵심 기능부터 차례차례 쌓아 올리는 방식입니다.

 

전체 제품을 한 번에 만드는 게 아니라,
핵심 기능 → 부가 기능 → 보조 기능 순으로 점진적으로 확장해 나가는 구조입니다.

 

이 방식은 반복적 모델보다 조금 더 체계적이고 안정감이 느껴졌습니다.

 

특히 기능 단위로 작업을 나눌 수 있어서,
기획도 “이번 스프린트에 필요한 기능만” 집중해서 할 수 있었던 점이 마음에 들었습니다.

 

기획자의 업무량이 확실히 줄어든 느낌은 아니었지만, 업무의 범위가 명확해졌다는 점에서 훨씬 관리하기 쉬웠습니다.

 

하지만 이 방식도 어려움이 없지는 않았습니다.
기능 단위로 설계하고 개발하다 보니, 전체 구조의 통일성이 흐트러지는 경우가 종종 있었고,

 

기능 간 연계나 통합 테스트에서 문제가 발생하기도 했습니다.
결구 마지막에는 워터폴 방법론으로 운영 되는 양상을 보였습니다.

---

나선형 모델 – 현실에선 보기 드문 이상적인 구조

나선형 모델

 

나선형 모델은 반복적인 개발 구조에 리스크 분석을 결합한 방식입니다.
매 반복마다 계획 → 리스크 분석 → 설계 → 개발 → 검토를 거치면서
결과물을 점진적으로 발전시키는 구조죠.

 

문서상으로 보면 굉장히 탄탄한 방식이고,
위험을 줄이면서 품질을 높이는 데 특화된 구조처럼 보입니다.

 

실제로도 대형 프로젝트나 금융, 항공, 국방 같이 실패 비용이 큰 분야에서는
나선형 모델이 적합하다고 이야기되곤 합니다.

 

하지만 솔직히 말하자면,
저는 이 모델을 실제로 적용하는 팀을 거의 본 적이 없습니다.

 

---

왜 잘 쓰이지 않을까?

나선형 모델은 잘 쓰이기 위해 필요한 조건이 너무 많습니다.

• 반복마다 리스크 분석 역량이 필요하고
• 분석한 리스크를 문서로 남기고 반영할 여유도 필요하며
• 일정과 예산도 충분해야 제대로 된 의미를 가질 수 있죠

하지만 현실은 항상 빠듯하고,
기획자도 개발자도 디자이너도 눈앞에 있는 작업만 해내기 바쁩니다.

결국 나선형 모델은
현실보다 이론에 가까운 방법론으로 남아 있는 경우가 많습니다.

---

기획자 입장에서 느낀 한계

기획자 입장에서 나선형 모델은
분명 매력적인 요소들이 있었습니다.
“리스크를 미리 고려한다”는 점은
예산이 크고 안정성이 중요한 프로젝트에서는 정말 유용할 수 있으니까요.

하지만 실무에서 느낀 건,
이 방식을 제대로 구현할 수 있는 팀 자체가 거의 없다는 점이었습니다.

• 중소 규모 프로젝트에는 오버스펙이고
• 리스크 분석 경험이 없는 팀에선 프로세스 흉내만 낼 가능성이 큽니다
• 반복이 쌓일수록 관리 복잡도도 급증합니다

결국 저 역시도
나선형 모델은 “한 번쯤은 경험해보고 싶은 방식”으로 남아 있을 뿐,
현실적으로 채택할 수 있었던 프로젝트는 거의 없었습니다.

---

기획자로서, 이 방법론들을 바라보며

워터폴에서 벗어나 반복적, 점증적, 나선형 모델을 경험하며
저는 프로젝트를 바라보는 관점 자체가 바뀌었습니다.

과거에는
"일정을 정확히 짜고, 계획대로 밀어붙이는 게 중요하다"고 생각했지만,
이제는
"지속적으로 검증하고, 유연하게 조정할 수 있어야 좋은 결과가 나온다"고 느끼게 되었습니다.

기획자에게도 방법론은 ‘기술자들의 언어’가 아닙니다.
프로젝트를 성공으로 이끌기 위한 ‘기초 체력’과도 같은 개념이라고 생각합니다.

 

 

다음 글에서는
이러한 반복성과 구조화된 접근을 모두 품고 있는
V-모델, 그리고 요즘 가장 자주 회자되는 애자일(Agile)에 대한 이야기를
실제 프로젝트 경험을 바탕으로 풀어보겠습니다.

 

두 방법론 사이에서
기획자는 어떤 태도를 취해야 할까요?

다음 편에서 자세히 다뤄보겠습니다.

 

 

 

 

-이전글-

2025.03.22 - [프로젝트 관리] - 2편 : 단순히 ‘작동’하는 것을 넘어 – 진짜 좋은 소프트웨어란?

2편 : 단순히 ‘작동’하는 것을 넘어 – 진짜 좋은 소프트웨어란?

2025.03.16 - [프로젝트 관리] - 1편 : 소프트웨어 공학을 공부해야 하는 이유

1편 : 소프트웨어 공학을 공부해야 하는 이유