SI 프로젝트 관리, 왜 같은 실수를 반복하는가: 현장 PM이 말하는 구조적 처방
SI 프로젝트의 실패는 기술 부족이 아닌 관리 구조의 결함에서 비롯됩니다. 범위 정의 부실, 역할 모호성, 변경 통제 부재라는 세 가지 근본 원인을 해소하면 납기 준수율을 최대 60% 이상 끌어올릴 수 있습니다.
국내 SI 현장에서 10년 넘게 프로젝트 를 이끈 PM들에게 "가장 힘든 순간이 언제였냐"고 물으면 공통된 답이 돌아옵니다. 기술적 난제가 아닙니다. "중간에 요구사항 이 바뀌었는데 아무도 문서화하지 않았을 때", "발주처 담당자가 세번바뀌면서 초기 합의가 사라졌을 때"라는 이야기입니다. 도구나 기술이 아니라 관리 구조 자체가 문제입니다. 이 글은 그구조적 문제를 해부하고, 실제 SI 현장에서 효과가 검증된 처방 을 제시합니다.
SI 프로젝트 실패의 진짜 원인: 숫자로 보는 현실
전 세계 IT 프로젝트의 약 31%가 완전 실패(취소 또 는 전면 재착수)로 종결되며, 52%는 당초 예산의 189%를 초과 집행한 채로 완료됩니다.
국내 SI 시장은 글로벌 평균보다 상황이 더 복잡합니다. 공공 SI 특유의 납품 체계(나라장터 입찰 → 계약 → 감리 → 최종 검수)와 다단계 하도급구조 가 맞물려, 원청 PM이 실질적으로제어할 수 없 는 변수 가 처음부터 쌓입니다.
실패 원인을 분해하면 세가지 패턴으로 수렴됩니다.
① 범위정의의 공백(Scope Gap) RFP에 "기존 시스템 연동"이라고 쓰여 있지만, 레거시 DB 스키마를 착수 후에야 처음 확인하 는 경우 가 비일비재합니다. 착수 단계에서 발견되지 않 은 연동복잡도는 실행 단계에서 공수 를 두 배로 불립니다.
② 역할경계의 모호성(Role Ambiguity) 발주처 담당자, PM, 기술 리드, 협력사 서브PM이 동시 에 의사결정을 요구받는 상황에서 RACI 매트릭스 없이 구두로 역할을 나누면 반드시 충돌 이 발생합니다.
③ 변경통제 부재(Uncontrolled Change) "이거 하나만바꾸면 되잖아요"로 시작하 는 요구사항 변경 이 누적되면, 프로젝트 후반에 WBS 전체를 재작성해야 하 는 상황 이 벌어집니다.
착수 단계에서 결판 나는 프로젝트 헌장
많은 PM이 착수 단계를 계약서 서명 과 킥오프 미팅으로 끝냅니다. 그러나 **프로젝트 헌장(Project Charter)**은 계약서와 다릅니다. 헌장은 기술적 범위보다 관리 기준을 명문화하는 문서입니다.
헌장에 반드시 담아야 할 7가지 항목
- 프로젝트 목적 과 성공 기준 — "시스템 오픈"이 아니라 측정 가능한 지표(예: 처리 시간 50% 단축, 오류율 1% 미만)로 기술
- 범위 경계선(In/Out Scope) — 포함되는 것보다 포함되지 않 는 것을 명시하 는 것 이 더 중요
- 의사결정 권한 위임 구조 — 어느 규모의 변경까지 PM이 단독 결정가능한지
- 변경 요청 처리 절차(CCB: Change Control Board) — 요청 → 영향 분석 → 승인 → 반영 의 4단계 프로세스
- 핵심 가정 및 제약사항 — "레거시 API 문서는 착수 후 2주 내 제공"처럼 양측이 전제하는조건
- 의사소통 채널 과 주기 — 보고 빈도, 에스컬레이션 경로, 긴급 연락처
- 프로젝트 종료 기준 — 무엇을 완료해야 "끝"으 로 인정할 것인지
헌장이 부실하면이후 모든 이슈가 "해석의 문제"로 귀결됩니다. 그리고 해석 싸움은 항상 PM이 집니다.
WBS 너머: 의존성 지도를 그려라
Work Breakdown Structure(WBS)는 SI 프로젝트 의 필수도구이지만, WBS만으로는 충분하지 않습니다. 태스크를 나열하 는 것과 태스크 간 의존성을 파악하는 것은 전혀 다른 작업입니다.
의존성 매핑의 핵심 원칙
SI 프로젝트에서 가장자주 간과되는 의존성은 외부 의존성입니다.
- 발주처가 제공해야 하는 데이터나 승인이 늦어지면 내부 일정이 연쇄지연됩니다.
- 외부 API(금융결제, 공공데이터 등)의 테스트 환경 제공 시점이 시스템 연동일정을 결정합니다.
- 레거시 마이그레이션은 운영팀의 협조 없이 단독진행이 불가능합니다.
이러한 외부 의존성을 크리티컬 패스에 명시적으 로 포함시켜야 합니다. 외부 의존성이 크리티컬 패스에 있다면, 그 항목 의 지연 위험은 리스크 대장 최상단에 올라가야 합니다.
외부 의존성을 명시적으로 관리한 프로젝트는 그렇지않은 프로젝트 대비 일정 편차를 평균 34% 감소시켰습니다.
공수 산정 시 버퍼 설계
공수 산정 에서 흔히 빠지는 항목들이 있습니다.
| 항목 | 흔히 누락되는 이유 |
|---|---|
| 코드 리뷰 및 내부 테스트 | "개발하면서 같이 하면 되지"라는 착각 |
| 문서화 (설계서, 운영 매뉴얼) | 납품 전날 몰아서 쓰는 악습 |
| 발주처 피드백 반영 사이클 | 리뷰 1회당 평균 3~5일 소요를 무시 |
| 통합 테스트 환경 구성 | 개발 환경과 운영 환경의 차이 해소 시간 |
| 이관 및 인수인계 | "끝났으니 알아서 하세요"가 안 통하는 이유 |
경험칙으 로 총 추정 공수 의 20~30%를 버퍼로 확보하되, 이를 PM이 몰래 숨기는 것이 아니라 헌장에 "관리 예비(Management Reserve)"로 명시해두어야 합니다.
다중 이해관계자 관리: 영향력이 아니라 불안감을 관리하라
전통적인 이해관계자 관리는 "영향력 높음/관심 도 높음" 사분면 에 있 는 사람 을 집중 관리하라고 가르칩니다. 맞는 말이지만, SI 현장에서는 한 가지를 추가해야 합니다. 불안감이 높은 이해관계자입니다.
발주처 담당자가 IT 비전문가인경우, 프로젝트가 제대 로 진행되고 있는지 가시성이 없으면 불안해집니다. 그 불안감이 잦 은 "추가 요청"과 "범위 변경"으 로 표출됩니다. 기술적으로 문제가 없어도 커뮤니케이션이 부족하면 클레임이 생깁니다.
가시성 확보를 위한 대시보드 운영
주간 보고서 를 50페이지 PPT로 제출하는 대신, 1페이지 상태 대시보드 를 매주 월요일오전 에 이메일로 발송하 는 방식이 훨씬 효과적입니다.
대시보드 에 포함할 핵심 정보:
- 전체 진행률 (%) — WBS 기준
- 이번 주완료 항목 — 3개 이내로 압축
- 다음 주예정 항목 — 3개 이내
- 현재 이슈 — 있으면 한줄 요약, 없으면 "이슈 없음"으로 명시
- 의사결정 대기 항목 — 발주처 확인/승인 이 필요한 것
“프로젝트 관리에서 '보고'의 목적은 정보 전달이 아닙니다. 이해관계자의 불안을 낮추는 것입니다. 그 목적에 맞게 형식을 설계해야 합니다.”
이슈 대장(Issue Log) 운영의 실제
이슈 대장 은 단순한 버그 목록이 아닙니다. 미결 의사결정 사항을 추적하 는 도구입니다.
각 이슈에 는 다음 이 포함되어야 합니다:
- 이슈 번호및 등록일
- 이슈설명 (누가, 무엇을, 왜 문제라고 하는가)
- 영향도 (일정/비용/품질 중어디에 영향을 미치는가)
- 담당자와 처리 기한 — 이것이 없으면이슈 대장은 불만 목록에 불 과
- 현재 상태및 최종 해결 방법
이슈 대장 은 주간 미팅에서 가장 먼저 리뷰되어야 하며, 처리 기한이 지난 항목 은 자동으로 에스컬레이션 대상이 됩니다.
클라우드 시대의 SI 프로젝트: 인프라 관리가 바뀌었다
2020년대 SI 프로젝트 는 더 이상 물리 서버 납품이 아닙니다. 클라우드 인프라(AWS, GCP, Azure, 또는 국내 클라우드)를 기반으로 하는 프로젝트 가 급속도로 늘고 있습니다. 이는 프로젝트 관리에 도 새로운 변수를 추가합니다.
국내 공공기관의 클라우드 전환 프로젝트 비중이 2022년 대비 2.3배 증가하였으며, SI 사업 중 클라우드 인프라 구축·운영을 포함하는 프로젝트 가 전체의 58%를 차지합니다.
클라우드 기반 SI에서 추가로 관리해야할 항목:
비용 거버넌스: 클라우드는 사용량 기반 과금이므 로 개발·테스트 환경에서 의도치 않은 비용이 발생합니다. 프로젝트 초기에 태깅 정책과 예산 알림을 설정해야합니다.
환경 분리 정책: 개발(Dev) → 스테이징(Staging) → 운영(Prod) 환경을 어떻게 분리하고 접근 권한을 관리할 것인지를 착수단계에서 확정해야 합니다.
IaC(Infrastructure as Code) 적용 범위: 인프라 를 코드로 관리하면 환경 재현성이 높아지지만, 팀원 의 학습 곡선도 고려해야 합니다. Terraform 또는 Pulumi 도입 여부는 프로젝트 규모와 팀역량을 함께 고려해야 합니다.
방법론 선택: 하이브리드가 현실이다
"이 프로젝트는 워터폴로 할 건가요, 애자일 로 할 건가요?" — 이 질문 자체가 현실을 단순화하고 있습니다. 국내 SI 환경에서 순수 애자일은 작동하기 어렵습니다. 이유가 있습니다.
계약 구조: 총액 고정 계약(Fixed Price)에서는 스코프를 유동적으로 가져가기어렵습니다.
감리 체계: 공공 SI의 감리는 특정 시점에특정 산출물을 요구합니다. 스프린트 산출물 이 감리 기준을 충족하지 못하면 문제가 됩니다.
발주처 참여도: 스프린트 리뷰에 발주처 담당자가 매 2주마다 참여해주기 를 기대하기 어려운경우가 많습니다.
현실적으로 작동하는 방식은 마일스톤 기반외부 관리 + 스프린트 기반 내부 운영의 조합입니다.
- 발주처 와 는 마일스톤(설계 완료, 1차 개발 완료, UAT 시작, 오픈) 기준으로 커뮤니케이션
- 내부 팀은 2주 스프린트로 실제 개발진행
- 마일스톤 산출물 은 스프린트 결과물 을 모아 작성
이렇게 하면 외부적으로는 계약·감리 요건을 충족하면서, 내부적으로는애자일의 적응성과 가시성을 활용할 수 있습니다.
프로젝트 종료를 어떻게 닫을 것인가
많은 PM이 오픈 당일을 프로젝트 완료 로 착각합니다. 실제로 SI 프로젝트에서 가장 위험한 시간 은 오픈 후 30일입니다. 이 기간에 숨어있던 이슈들 이 실사용자 를 통해 터져 나옵니다.
종료 단계 에서 반드시 처리해야 할 항목:
- 결함 처리 기준 합의: 오픈 후 발생하는 이슈 중 계약 범위 내 수정 사항과 추가 계약이 필요한 사항의 경계 를 명확히
- 운영 이관 체크리스트: 시스템 계정, 접근 권한, 배포 절차, 모니터링 알림 설정 이 모두 이관되었는지 확인
- 프로젝트 회고(Retrospective): 잘된 점, 개선점, 다음 프로젝트에서 바꿔야 할 것을 팀내부에서 문서화
- 교훈 등록(Lessons Learned): 조직 차원에서 재사용 가능한 지식을공식 문서로 남기는 것
회고를 건너뛰는 팀은 같 은 실수를 반복합니다. 데이터가 아니라 경험이 쌓이는 것 처럼 보이지만, 문서화되지 않은 경험 은 담당자가 떠나는 순간 사라집니다.
Muwall이 SI 프로젝트 관리에 어떻게 기여하는가
Muwall은 SI 사업자들이 프로젝트 인프라를 빠르게 구축하고 운영할 수 있도록 클라우드 호스팅 과 SI 커뮤니티 플랫폼 을 제공합니다. 반복적으로 발생하는 인프라 셋업 작업 을 표준화하고, 프로젝트별 환경 을 빠르게 프로비저닝할 수 있 는 구조를 지원합니다.
SI 프로젝트 의 기술 스택 이 복잡해질수록, 인프라 관리에 소요되 는 PM의 시간도 늘어납니다. 핵심 관리 업무에 집중할 수 있도록, 클라우드인프라의 운영 부담을 낮추는 것이 Muwall의 역할입니다.
자주 묻는 질문
SI 프로젝트 관리에서 가장 먼저 해야 할 일 은 무엇인가요?
프로젝트 헌장 작성이 가장 먼저입니다. 계약서 가 아닌 관리 기준문서로서, 범위 경계(In/Out Scope), 변경 통제 절차, 의사결정 권한 구조, 종료 기준을 착수 첫 주 안에 발주처 와 합의해야 합니다. 헌장이 없으면 이후 모든 분쟁이 '해석 문제'로 귀결됩니다.
국내 SI 환경에서 애자일 방법론 을 적용할 수 있나요?
순수 애자일 은 현실적 으로 어렵습니다. 총액 고정 계약구조와 감리 요건 때문입니다. 대신 '하이브리드' 방식 이 효과적입니다. 발주처와 는 마일스톤 기반으로 커뮤니케이션하고, 내부 팀은 2주 스프린트로 운영하는 방식입니다. 외부 요건(계약·감리)과 내부 민첩성(적응·가시성)을 동시에 충족할 수 있습니다.
프로젝트 종료 후에도 이슈 가 계속 생기는데 어떻게 관리해야 하나요?
오픈 후 30일이 가장 위험한 기간입니다. 계약 종료전 에 발주처와 '결함 처리 기준'을 합의해야 합니다. 계약 범위 내 수정 사항(기존 기능의 오동작)과 계약 외 추 가 요청(새 기능, 범위 확장)의 경계 를 문서 로 명확히 하고, 보증 기간과처리 절차 를 종료 회의에서 확인받아야 합니다.