사업관리 방법론? 개발 방법론? 도대체 방법론이 뭔데? PM의 나침반! 🧭

사업관리 방법론? 개발 방법론? 도대체 방법론이 뭔데? PM의 나침반! 🧭

안녕하세요, 여러분의 프로젝트 성공 파트너, 수다쟁이 PM입니다! 🙋‍♀️

PM이 되어보니, 프로젝트가 단순히 코딩만으로 완성되는 게 아니란 걸 뼈저리게 느낍니다. 견고한 건물을 지으려면 설계도부터 시공, 감리까지 모든 과정이 필요하듯, SW 프로젝트도 성공적인 완수를 위해 체계적인 접근 방식, 즉 '방법론'이 필수죠.

🤔 잠깐, '방법론'이 뭔가요? 집 짓기로 이해해봐요!

'방법론'이라는 말부터 어렵다고요? 괜찮아요. 우리가 '멋진 집 한 채'를 짓는다고 상상해봅시다.

• 사업관리 방법론은 '집 짓기 프로젝트 전체를 관리하는 법' 입니다. 언제까지 집을 완성할지(일정), 얼마의 돈을 쓸지(예산), 어떤 인부들을 쓸지(자원) 계획하고, 설계는 잘 되고 있는지, 자재는 제때 들어오는지, 민원은 없는지 관리해야죠. 갑자기 비가 많이 와서 공사가 늦어지면 어떻게 할지(위험 관리), 집주인의 마음이 바뀌어 창문을 더 내달라고 하면 어떻게 할지(변경 관리) 등을 총괄하는, '건축 현장 소장님의 경영 노하우'에 가깝습니다.
• 개발 방법론은 '그래서 집을 어떻게 지을 건데?'에 대한 답입니다. 벽돌을 한 장 한 장 쌓아 올릴 건지(폭포수 모델), 아니면 공장에서 만든 벽체를 가져와 조립할 건지(컴포넌트 기반), 그것도 아니면 일단 1층만 먼저 짓고 살아보면서 2층 설계를 바꿀 건지(애자일) 결정하는 '건축 시공팀의 구체적인 기술'이죠.

이해가 되시나요? 사업관리 방법론이 전체 공사를 무사히 끝내는 법이라면, 개발 방법론은 그 안에서 벽돌을 쌓는 구체적인 기술인 셈입니다. 이 두 가지가 잘 맞물려 돌아갈 때, 비로소 야근 없는 평화가 찾아올 확률이 조금은 높아집니다. 🚀

1. 사업관리 방법론: 무엇을, 어떻게 관리할까?

사업관리 방법론은 '프로젝트라는 배'가 목적지까지 성공적으로 항해하도록 이끄는 모든 활동을 다룹니다. 크게 보면 다음과 같은 영역들을 관리하게 되죠.

• 계획 & 통제: WBS로 작업을 쪼개고, 간트 차트로 일정을 그리며, 계획과 실제의 차이를 계속 줄여나가는 활동.
• 품질 & 위험: 지속적인 검증으로 완성도를 높이고, 터지기 전 시한폭탄을 미리 해체하는 활동.
• 보안 & 산출물: 정보 자산을 지키고, 프로젝트의 모든 역사를 기록하고 관리하는 활동.

이런 관리 활동들을 체계적으로 정리해놓은 대표적인 '지식 체계'가 바로 PMBOK(Project Management Body of Knowledge) Guide입니다. PMBOK은 전 세계 프로젝트 관리의 '바이블'로 불리며, 특정 규칙이라기보다는 모든 상황에 적용할 수 있는 지식과 모범 사례를 담은 가이드라인입니다.

2. 개발 방법론: 어떤 방식으로 만들까?

개발 방법론은 소프트웨어를 만드는 '레시피'와 같습니다. 크게 세 가지 흐름으로 나눌 수 있습니다.

1) 예측 중심 방법론 (폭포수 모델) '폭포수'처럼 위에서 아래로, 한 방향으로만 개발을 진행하는 가장 전통적인 방식입니다. 요구사항 분석 → 설계 → 구현 → 테스트 단계를 순서대로 엄격하게 따르죠.

• 장점: 프로세스가 단순해서 이해하기 쉽고, 각 단계가 명확해 진행 상황 파악이 용이합니다.
• 단점: 한번 출발한 기차의 목적지를 바꾸는 것만큼이나 변경에 취약하고, 테스트 단계에 가서야 "아, 이거 아니네!" 하는 심각한 오류가 발견될 수 있습니다.

2) 반복/점진적 방법론 (CBD 모델) 전체 시스템을 한 번에 다 만들지 않고, 재사용 가능한 '부품(컴포넌트)'을 조립해나가는 방식입니다.

• 장점: 검증된 부품을 재사용하니 개발 속도가 빠르고, 문제가 생겨도 해당 부품만 교체하면 되어 유지보수가 용이합니다.
• 단점: 쓸만한 부품 라이브러리를 만드는 데 초기 비용과 노력이 많이 들고, 컴포넌트 관리를 잘못하면 오히려 더 복잡해질 수 있습니다.

3) 적응형 방법론 (애자일) 정해진 계획보다 '변화에 대한 대응'을 중요하게 생각하는 방식입니다. 짧은 주기로 계획과 개발, 피드백을 반복하며 점진적으로 제품을 완성해 나갑니다.

• 장점: 변화무쌍한 요구사항을 끌어안는 데 탁월하며, 짧은 주기마다 동작하는 결과물을 보여주어 고객을 안심시킬 수 있습니다.
• 단점: 매일 열심히 노를 젓는데, 정신 차려보니 제자리를 맴돌고 있을 수도 있어요. 명확한 장기 계획과 리더십이 없으면 산으로 가기 쉽습니다.

---

💡 수다쟁이 PM의 실전 꿀팁: 그래서 공공에선 뭘 쓰나요?

자, 이렇게 많은 방법론들을 알아봤는데, 머리가 복잡하시죠? 여기서 다들 궁금해하는 질문이 나옵니다. "그래서 결론이 뭔데? 공공 프로젝트에서는 뭘 쓰라는 건데?"

하하, 좋은 질문입니다! 교과서에 나오는 수많은 방법론들, 다 공부하면 좋겠지만 우린 당장 프로젝트를 해야 하잖아요? 그래서 제가 딱! 정리해 드릴게요.

현재 대한민국 공공 정보화 사업에서는 이렇게 조합하는 경우가 가장 많습니다.

• 사업관리 방법론: 한국지능정보사회진흥원(NIA)에서 발행한 '전자정부지원사업 사업관리 방안'을 표준으로 삼습니다. PMBOK 기반의 '한국형 맞춤 룰북'이죠.
• 개발 방법론: 사업 초기에 요구사항을 명확히 정의하고 시작하는 폭포수(Waterfall) 모델과, 시스템의 재사용성과 유지보수성을 높이는 CBD(컴포넌트 기반 개발) 방법론을 혼합한 형태를 가장 흔하게 사용합니다.

이때 또 다른 질문이 나오죠. "아니, 요즘 대세는 '애자일'이라는데, 공공에선 왜 못 쓰나요?"

애자일의 자유로운 영혼과 공공의 '칼각' 계약서는 상극일 수 있거든요. 공공 프로젝트는 대부분 정해진 기간, 예산, 인력, 그리고 명확한 과업 범위(RFP) 안에서 '결과물'을 만들어내야 하는 계약을 기반으로 하기 때문입니다.

하지만 여기서 유능한 PM의 역량이 드러납니다. 🧐

비록 프로젝트의 큰 틀은 폭포수 모델을 따르더라도, 애자일의 장점인 '주기적인 아침 소통(데일리 스크럼처럼)', '짧은 주기의 중간 시연', '고객의 빠른 피드백 반영' 같은 요소들을 프로젝트에 녹여낼 수 있습니다.

결국 중요한 것은 '어떤 방법론을 썼다'가 아니라, '각 방법론의 장단점을 이해하고 우리 프로젝트 상황에 맞게 최적의 조합을 만들어냈는가' 입니다. 이게 바로 이론을 넘어선 진짜 '실전'이죠! 🏆

 

마무리하며

복잡하고 다양한 변수가 존재하는 정보화 사업 환경에서, 이러한 사업관리 및 개발 방법론에 대한 깊은 이해와 더불어 상황에 따른 '유연한 적용 능력'은 성공적인 프로젝트 수행을 위한 PM의 핵심 역량입니다. 저 수다쟁이 PM과 함께, 여러분의 프로젝트도 늘 성공 가도만 달리기를 응원합니다! 📈