대형 공공 차세대 시스템. 원청 한 곳, 그 아래 협력사 셋이 각각 다른 영역을 맡습니다. 협력사 A는 대외연계(인터페이스), B는 업무화면, C는 데이터 이행을 담당합니다.
3주 차 주간회의. A는 "우리는 일정대로입니다", B도 "정상입니다", C도 "문제 없습니다"라고 보고합니다. 그런데 4주 차, B의 화면 개발이 통째로 멈춥니다. 이유는 단순합니다 — B가 화면에서 호출할 연동 규격(인터페이스 정의서)을 A가 아직 확정하지 못했기 때문입니다. A의 입장에선 "우리 산출물 일정은 지키는 중"이고, B 입장에선 "받을 게 안 와서 못 한다"입니다. 둘 다 거짓말을 하지 않았는데 프로젝트는 멈췄습니다.
문제는 능력이 아니라 아무도 벤더 사이의 인계 지점을 한 장에서 보고 있지 않았다는 것입니다. 각자 자기 일정만 봤습니다. 이 빈자리를 메우는 조직이 **PMO(프로젝트 관리 조직)**입니다. PMO는 코드를 짜지 않습니다. 대신 표준을 깔고, 진척을 한곳에 모으고, 벤더 사이의 의존과 이슈를 통합 관리해 여러 수행사를 한 방향으로 끌고 갑니다. 이 모듈은 그 일의 구조를 다룹니다.
- 1PMO가 표준·방법론·진척 통합·품질·리스크/이슈 통합·보고·자원 조정의 어떤 역할을 하는지 설명할 수 있다
- 2PMO 유형(지원형·통제형·지시형)의 차이와 한국 대형 SI에서 원청 PMO가 통제형에 가까운 이유를 말할 수 있다
- 3복수 벤더의 인터페이스·일정 의존·책임 경계를 정렬하는 통합 일정·통합 이슈관리의 필요성을 설명할 수 있다
- 4벤더 관리(성과·SLA·에스컬레이션·정기 점검회의)의 통제 지점을 식별할 수 있다
- 5PMO 관리 항목 표와 다수 벤더 통합 이슈/리스크 관리대장을 읽고 위험을 판정할 수 있다
PMO는 무엇을 하는 조직인가
코드를 짜지 않는 대신, 모두가 같은 틀로 일하게 만든다
규모가 커지면 '잘하는 개별 팀'만으로는 프로젝트가 굴러가지 않습니다. 팀이 셋만 돼도 각자의 일정·산출물 양식·진척 보고 방식이 제각각이면, 관리자는 "지금 전체가 어디까지 왔는지"를 알 수 없습니다. **PMO(Project Management Office, 프로젝트 관리 조직)**는 바로 이 '전체를 한 방향으로 정렬'하는 일을 전담하는 조직입니다.
PMO는 직접 개발하지 않습니다. 대신 여러 팀·벤더가 같은 틀로 일하도록 표준을 깔고, 흩어진 진척·품질·리스크를 한곳으로 모아 경영진과 발주사에게 보고합니다. 핵심 역할을 정리하면:
| PMO 역할 | 하는 일 | 없으면 생기는 문제 |
|---|---|---|
| 표준·방법론 | 산출물 양식, 단계별 절차, 명명 규칙을 정의·배포 | 벤더마다 문서 양식이 달라 비교·취합 불가 |
| 진척 통합 | 벤더별 진척을 마스터 스케줄로 취합, 임계경로 관리 | 각자 "정상"인데 전체는 지연 |
| 품질 관리 | 산출물 검토·인수 기준 운영, 품질 게이트 통과 판정 | "냈다"와 "쓸 수 있다"가 구분 안 됨 |
| 리스크/이슈 통합 | 전 벤더 리스크·이슈를 한 대장에 모아 추적·에스컬레이션 | 같은 위험을 여러 곳에서 따로 떠안다 터짐 |
| 보고 | 경영진·발주사용 통합 현황 보고(주간/월간/마일스톤) | 윗선이 실제 상태를 늦게 알게 됨 |
| 자원 조정 | 벤더 간 인력·일정·인터페이스 인계 조율 | 인계 지점에서 일정이 어긋남 |
요약하면 PMO는 **"누가, 무엇을, 언제까지, 어떤 기준으로 하고, 그 결과를 어떻게 모아 보고하는가"**를 설계하고 통제하는 조직입니다.
PMO의 세 가지 성격 — 지원형·통제형·지시형
PMO라고 다 같은 강도로 개입하지 않습니다. 조직이 PMO에 부여하는 권한에 따라 보통 세 유형으로 나눕니다. 같은 'PMO'라는 이름이라도 어느 쪽이냐에 따라 협력사가 체감하는 통제 강도가 크게 다릅니다.
| 유형 | 개입 강도 | 핵심 행동 | 비유 |
|---|---|---|---|
| 지원형(Supportive) | 낮음 | 템플릿·가이드·교육·도구를 제공. 따를지는 팀 자율 | 도서관 — 필요하면 빌려 쓰세요 |
| 통제형(Controlling) | 중간 | 표준 준수를 점검·강제. 산출물·보고가 기준을 못 맞추면 반려 | 검문소 — 기준을 통과해야 다음 단계 |
| 지시형(Directive) | 높음 | PMO가 PM을 직접 보유, 프로젝트를 직접 운영·지휘 | 사령탑 — 직접 명령하고 책임진다 |
한국 대형 SI의 원청 PMO는 대개 통제형에 가깝습니다. 발주사가 원청에 책임을 묻고, 원청은 다시 복수 협력사에 같은 기준을 강제해야 하기 때문입니다. 원청 PMO는 산출물 양식·진척 보고 주기·품질 게이트를 정해 두고, 협력사가 그 기준을 준수하는지 주기적으로 점검합니다. 기준 미달이면 산출물을 반려하고 보완을 요구합니다. 직접 개발을 대신하지는 않지만(그건 협력사 몫), '같은 틀을 강제'한다는 점에서 단순 지원을 넘어섭니다.
확대
같은 'PMO'라는 이름이라도 부여된 권한에 따라 협력사가 체감하는 통제 강도가 크게 다릅니다. 지원형은 템플릿을 빌려 주는 도서관, 통제형은 기준을 통과해야 다음으로 넘기는 검문소, 지시형은 직접 명령하고 책임지는 사령탑입니다. 한국 대형 SI의 원청 PMO는 대개 통제형 — 반려 권한이 있는 상대에게 지원형처럼 굴면 산출물이 막힙니다. 그래서 일하기 전에 "이 PMO는 어느 유형인가"를 먼저 읽는 것이 중요합니다.
여러 수행사를 어떻게 한 방향으로 모으나
인터페이스 · 일정 의존 · 책임 경계 — 세 가지 정렬 축
복수 벤더 구조에서 PMO가 통제해야 할 것은 '각 벤더가 잘하는가'보다 **'벤더와 벤더 사이가 잘 맞물리는가'**입니다. 정렬해야 할 축은 세 가지입니다.
- 인터페이스(연동 규격): 벤더 A가 만드는 데이터·API를 벤더 B가 받아 씁니다. 이 규격(인터페이스 정의서, I/F 명세)이 명확하고 합의돼 있어야 양쪽이 따로, 동시에 개발할 수 있습니다. PMO는 인터페이스 정의서를 '공통 산출물'로 못 박고, 변경 시 영향받는 모든 벤더에 즉시 전파합니다.
- 일정 의존(dependency): A의 산출물이 B의 시작 조건이면, A의 지연은 자동으로 B의 지연입니다. PMO는 이 인계 지점을 마스터 스케줄에 명시해, '어느 지연이 어디로 번지는지(임계경로)'를 봅니다.
- 책임 경계(boundary): 문제가 생겼을 때 "이건 누구 몫인가"가 모호하면 벤더끼리 서로 떠넘기며 시간이 갑니다. PMO는 영역·산출물·인수 기준별로 책임 주체를 사전에 명문화합니다(R&R, 역할과 책임).
이 세 가지가 정렬되지 않으면, 각 벤더가 아무리 잘해도 통합 단계에서 한꺼번에 터집니다. ScenarioBlock의 A·B 사례가 바로 인터페이스·일정 의존이 정렬되지 않은 결과였습니다.
통합 일정과 통합 이슈관리 — 흩어진 것을 한 장으로
정렬의 도구는 '통합'입니다. PMO는 벤더별로 흩어진 두 가지를 하나의 마스터 뷰로 모읍니다.
- 통합 일정(마스터 스케줄): 모든 벤더의 마일스톤·산출물 기한·인계 지점을 한 장에 모읍니다. 벤더별 일정만 보면 각자 "정상"이지만, 통합하면 인계점의 어긋남(=병목)이 보입니다. 임계경로(전체 완료를 결정하는 가장 긴 의존 사슬)를 여기서 관리합니다.
- 통합 이슈/리스크 관리대장: 전 벤더의 이슈(이미 발생)와 리스크(아직 잠재)를 한 대장에 모읍니다. 같은 위험을 여러 벤더가 따로 떠안다 터지는 것을 막고, '누구 책임 경계에서 막혔는가'를 명시해 에스컬레이션 경로를 분명히 합니다.
이슈와 리스크는 다릅니다. 이슈는 '이미 일어나 지금 대응이 필요한 것', 리스크는 '아직 안 일어났지만 일어나면 곤란한 것'입니다. PMO는 리스크를 미리 추적해 이슈가 되기 전에 줄이고, 이미 이슈가 된 것은 담당·기한을 붙여 닫습니다. 이 모듈의 마지막 산출물 예시에서 두 표의 실제 형태를 봅니다.
벤더 관리 — 성과·SLA·에스컬레이션·정기 점검
계약은 시작일 뿐, 관리는 매주 일어난다
벤더(협력사)를 계약했다고 관리가 끝나는 게 아닙니다. 벤더 관리는 계약된 성과가 실제로 나오게 만드는 주기적 통제입니다. 핵심 수단은 네 가지입니다.
- 성과 관리: 약속한 산출물·일정·품질이 실제로 나오는지 계획 대비 실적으로 측정합니다. '냈다'가 아니라 '인수 기준을 통과했다'로 판정합니다.
- SLA(서비스 수준 협약): 특히 운영(SM) 단계에서, 응답시간·복구시간·가용성 같은 측정 가능한 기준을 계약에 명시하고 위반 시 패널티/개선 의무를 둡니다. (SLA의 상세는 별도 모듈에서 다룹니다.)
- 에스컬레이션: 벤더 수준에서 못 푸는 이슈를 정해진 단계(벤더 PM → 원청 PMO → 발주사)로 끌어올립니다. 누가, 무엇을, 언제 올릴지를 미리 정의해 둬야 '터질 때까지 아무도 안 올리는' 상황을 막습니다.
- 정기 점검회의: 주간 운영회의가 통제의 심장입니다. 약속 대비 실제 진척, 신규/변경 이슈·리스크, 벤더 간 인계 지연, 다음 마일스톤과 에스컬레이션 항목을 다룹니다. 회의의 산출물은 '갱신된 통합 대장'과 '담당·기한이 붙은 액션 아이템'이어야 합니다 — 그렇지 않으면 회의는 안부 인사로 끝납니다.
확대
그림: PMO는 벤더 "사이"를 세 축으로 정렬하고 통합 도구로 한 장에 모으며, 못 푸는 이슈는 정해진 경로로 끌어올린다.
직접 해보기 — 산출물 두 장 채우기
ScenarioBlock의 상황(A=대외연계, B=업무화면, C=데이터 이행)을 그대로 씁니다. 당신은 원청 PMO입니다. 아래 두 표를 직접 채우거나, 예시를 읽으며 '왜 이렇게 적는가'를 따져 보세요. 정답 해설은 ObserveBlock에 있습니다.
(1) PMO 관리 항목 표 — PMO가 무엇을, 어떤 주기로, 어떤 산출물로 관리하는지.
| 관리 항목 | 관리 주기 | 산출물 | 판정 기준 |
|---|---|---|---|
| 표준·방법론 준수 | 단계별(착수 시 배포) | 산출물 양식·명명 규칙 | 양식 일치 여부 |
| 진척(통합 일정) | 주간 | 마스터 스케줄 | 계획 대비 실적, 임계경로 지연 0 |
| 품질(인수) | 산출물 제출 시 | 검토의견서·인수확인서 | 인수 기준(연동 테스트 등) 통과 |
| 리스크/이슈 | 주간(상시 등록) | 통합 이슈/리스크 대장 | 신규/변경 추적, 미해결 노후화 없음 |
| 통합 보고 | 주간/월간/마일스톤 | 통합 현황 보고서 | 발주사 보고 기한 준수 |
| 자원·인계 조정 | 상시 | 인터페이스 정의서·R&R | 인계 지점 합의·전파 완료 |
(2) 다수 벤더 통합 이슈/리스크 관리대장 — 전 벤더를 한 대장에. 책임 경계와 에스컬레이션을 분명히.
| ID | 구분 | 내용 | 담당 벤더 | 책임 경계 | 영향 | 상태 | 기한 | 에스컬레이션 |
|---|---|---|---|---|---|---|---|---|
| R-001 | 리스크 | 인터페이스 정의서 확정 지연 가능성 | A | A 산출 → B 시작 조건 | B 화면 개발 중단 | 진행 | 4주차 | 원청 PMO |
| I-002 | 이슈 | I/F 미확정으로 B 화면 개발 중단(발생) | A→B | A 책임(미산출) | 전체 2일 지연 | 발생 | 즉시 | 발주사 보고 |
| R-003 | 리스크 | C 데이터 이행 검증 기간 부족 | C | C 단독 | 오픈 일정 위협 | 진행 | 6주차 | 원청 PMO |
| I-004 | 이슈 | B '완료' 보고했으나 A 연동 테스트 미통과 | B | 통합 책임(연동) | 인수 보류 | 발생 | 5주차 | 원청 PMO |
대상: 원청 PMO 관점에서 3개 협력사(A·B·C) 통합 관리- PMO 관리 항목 표의 핵심은 "판정 기준" 열이다 — 관리는 "본다"가 아니라 "기준으로 통과/반려를 판정한다". 기준이 없으면 점검은 안부 인사가 된다
- I-002는 R-001이 현실이 된 결과다 — 리스크(R)를 미리 추적했기 때문에 이슈(I)가 됐을 때 당황하지 않고 바로 에스컬레이션 경로(발주사 보고)가 작동한다. 리스크 추적의 가치가 여기 있다
- I-004의 책임 경계가 "통합 책임(연동)"인 점에 주목 — B가 "우리 완료"라 보고해도 A 인터페이스와 맞물려 동작(연동 테스트 통과)하지 않으면 통합 관점에선 미완. 대장을 보고만으로 닫으면 안 된다
- 에스컬레이션 열이 비어 있지 않아야 한다 — "이건 벤더가 알아서"가 아니라, 어느 선까지 올릴지가 사전에 정해져 있어야 터질 때 즉시 작동한다
- 같은 "정상" 보고라도, 통합 대장에서 책임 경계와 인계 지점으로 교차 검증하면 A·B 사례 같은 "각자 정상, 전체 지연"이 미리 보인다 — 이것이 통합 관리의 목적이다
현장에서 자주 보는 함정
증상: 주간회의마다 협력사들은 각자 "일정대로", "정상"이라고 보고합니다. 그런데 통합 테스트·오픈이 가까워지자 연동 오류·데이터 불일치·기능 누락이 한꺼번에 쏟아집니다. 막상 따지면 "우리 산출물은 냈다", "받을 게 안 왔다"며 책임이 공중에 뜹니다.
원인: PMO가 벤더별 보고를 따로 받았을 뿐, 벤더 사이를 통합해 보지 않았습니다. (1) 각 벤더의 '내부 완료'를 '통합 완료'로 착각했고, (2) 인터페이스·일정 의존·책임 경계를 한 장에 모은 통합 뷰가 없었으며, (3) 이슈/리스크 대장에 '책임 경계' 열이 없어 누구 몫인지가 모호했습니다.
해결 방향(이 트랙·이 모듈에서 다룸):
- 모든 산출물의 '완료'를 **객관적 인수 기준(연동 테스트 통과 등)**으로 판정 — '냈다'와 '쓸 수 있다'를 분리한다.
- 벤더별 일정을 마스터 스케줄로 통합해 인계 지점·임계경로를 한 장에서 본다.
- 통합 이슈/리스크 대장에 '책임 경계'와 '에스컬레이션' 열을 두어, 막힌 지점의 주체와 끌어올릴 경로를 항상 명시한다.
- 정기 점검회의의 산출물을 **'갱신된 대장 + 담당·기한 붙은 액션'**으로 못 박아, 회의가 안부로 끝나지 않게 한다.
PMO의 일은 벤더를 의심하는 게 아니라, 각자 정직하게 일해도 인계 지점에서 어긋날 수 있다는 전제 위에서 그 틈을 통합으로 메우는 것입니다.
심화 — 문패는 통제형인데 권한은 지원형일 때
심화: PMO 권한의 실체 — 반려의 딜레마, 지시 경로의 법적 제약, 제3자 PMO의 역설
본문은 PMO를 유형으로 분류했지만, 현장에서 PMO의 실제 힘은 문패가 아니라 계약과 이해관계가 정합니다. 통제형이라는 이름을 달고도 통제가 작동하지 않는 지점이 세 곳 있습니다.
- 반려의 딜레마: 원청 PMO는 협력사 산출물의 반려 권한과 전체 일정 책임을 동시에 집니다. 반려하면 임계경로가 밀리고, 그 지연 보고서를 발주사에 쓰는 것도 PMO 자신입니다. 그래서 반려는 자해가 되고, 대신 "조건부 통과 — 보완은 다음 단계에서"가 쌓입니다. 조건부 통과가 세 번 겹치면 게이트는 이미 형해화된 것입니다. 처방은 조건부 통과의 '조건'을 통합 대장에 기한·담당과 함께 등록해 일반 이슈와 똑같이 추적하는 것 — 조건이 대장 밖에 있으면 그것은 통과이지 조건부가 아닙니다.
- 지시 경로의 법적 제약: 원청 PMO가 협력사 소속 개발자에게 업무를 직접 지시하면 위장도급·불법파견 소지가 생깁니다(도급은 일의 완성을 맡기는 계약이지 사람을 지휘하는 계약이 아닙니다). 그래서 지시는 반드시 협력사 PM을 경유해야 하고, 그만큼 통제의 속도는 느려집니다 — 이 느림은 비효율이 아니라 적법성의 비용입니다. 급하다고 개발자를 직접 부리는 PMO는 당장은 빠르지만, 조직에 법적 리스크를 쌓고 있는 것입니다.
- 제3자 PMO의 역설: 대형 공공사업은 PMO 자체를 별도 용역으로 발주하기도 합니다. 이때 PMO사는 서류상 통제자이지만 계약상으로는 원청 수행사와 나란한 '을'입니다. 대기업 원청이 중견 PMO사의 시정요구를 "참고하겠습니다"로 받아넘겨도 PMO에게는 강제 수단이 없습니다 — PMO의 권한은 발주사가 과업지시서에 써서 위임한 만큼만 존재합니다. 검토·보고 권한만 있고 게이트 승인·반려 권한이 없는 PMO는 통제형이 아니라 문서 수집상입니다.
규모가 클수록 이 구조 문제가 커집니다. 소형 사업의 PMO는 사실상 원청 PM 겸직이라 권한 공백이 없지만, 다층·다벤더 대형 사업일수록 '권한은 어느 계약 문서의 어느 조항에서 나오는가'를 착수 단계에 확인해야 합니다. 일하기 전에 PMO 유형을 읽으라는 본문의 조언은, 정확히는 그 유형이 계약서에 적혀 있는지를 읽으라는 뜻입니다.
상황: 공공 차세대 사업에서 발주기관이 PMO 용역을 별도 발주했고, 중견 컨설팅사가 수주해 들어갔습니다. 3개월 차, PMO가 원청(대기업 SI)의 설계 산출물에서 인터페이스 정의 누락을 찾아 반려 의견과 시정요구 공문을 냈습니다. 원청 사업부장의 반응은 정중하지만 단호했습니다 — "PMO사는 저희 계약 상대가 아니지 않습니까. 검토의견은 참고하겠습니다." 원청은 발주기관 담당 과장에게 직접 설명해 설계 승인을 받아냈고, PMO의 반려 의견서는 회의 자료 첨부물로 격하됐습니다. 이후 PMO 보고서는 아무도 기다리지 않는 문서가 됐습니다. 그리고 10개월 차, 그 인터페이스 누락이 통합테스트에서 터져 오픈이 두 달 밀리자 발주기관은 PMO를 문책했습니다 — "이러라고 PMO를 뽑은 게 아닌데, 그동안 뭘 하셨습니까."
원인: PMO의 권한이 과업지시서에 '산출물 검토 및 의견 제시'까지만 적혀 있었고, 발주사 승인 절차와의 연결 고리가 없었습니다. PMO 검토와 무관하게 발주사가 승인할 수 있는 구조에서는, 원청 입장에서 PMO를 거칠 이유가 없습니다 — 발주사에 직접 가는 쪽이 빠르고 확실하니까요. PMO는 권한 없이 책임만 지는 자리가 됐고, 그 구조는 첫 반려가 무력화된 순간 모두에게 학습됐습니다.
진단: 계약 문서 세 개를 나란히 놓고 확인합니다 — PMO 과업지시서에 승인·반려 권한이 있는가, 원청 계약서에 'PMO 검토 협조 의무'가 있는가, 발주사 내부 승인 절차에 'PMO 검토의견서 첨부'가 필수인가. 셋 다 없다면 PMO 통제는 제도가 아니라 상대의 선의에 의존하고 있는 것입니다. 실제로 우회가 일어났는지는 승인 이력으로 봅니다 — PMO 반려 의견이 있는 산출물이 발주사 승인을 받은 건수가 곧 우회의 횟수입니다.
해결: PMO 명의의 권한을 키우려 하지 말고, 발주사 명의의 절차에 PMO를 끼워 넣습니다. 발주사와 협의해 "PMO 검토의견서가 첨부되지 않은 산출물은 발주사가 승인 접수하지 않는다"는 내부 절차를 만들면, 시정요구가 PMO의 부탁이 아니라 발주사 승인의 전제 조건이 됩니다. 시정요구 공문도 PMO 명의가 아니라 발주사 명의로 나가도록 대필·보좌 구도로 바꿉니다. 사업 중간이라도 이 절차 합의는 가능하며, 다음 사업부터는 제안 단계에서 과업지시서에 게이트 권한을 명문화하는 것이 근본 처방입니다 — PMO의 힘은 전문성에서 나오는 것 같지만, 실제로는 절차의 어느 위치에 앉아 있는가에서 나옵니다.
한국 대형 SI 현장에서 이 일은 원청 PMO·사업관리(PM) 자리의 핵심 업무입니다. 발주사(공공기관·대기업)는 원청 한 곳에 책임을 묻고, 원청 PMO는 그 아래 복수 협력사(다단계 하도급 포함)의 진척·품질·이슈를 통제해 발주사에 통합 보고합니다. 당신이 직접 코드를 짜지 않더라도, 산출물 양식을 정하고, 마스터 스케줄을 운영하고, 매주 협력사 점검회의를 주재하고, 통합 이슈/리스크 대장을 갱신하며, 발주사 보고를 책임지는 자리입니다.
이 자리에서 가장 자주 쓰는 무기가 바로 이 모듈의 두 산출물 — PMO 관리 항목 표(무엇을 어떤 기준으로 통제하는가)와 통합 이슈/리스크 관리대장(누가 어디서 막혔고 어디로 올릴 것인가) — 입니다. 협력사 엔지니어가 실제 작업을 하더라도 일정·품질·범위·산출물에 대한 책임은 원청 관리자에게 있고, 잘못된 '정상' 보고에 속지 않으려면 인수 기준과 통합 뷰로 교차 검증하는 감각이 필수입니다. 기술을 아는 PMO는 협력사와 대등하게 대화하고, '냈다'와 '쓸 수 있다'의 차이를 판정할 수 있습니다.
다음 모듈에서는 이런 운영·관리가 실제로 무엇으로 남는지 — SI 프로젝트와 SM 운영에서 단계별로 만들어지는 산출물 체계를 한 장의 지도로 정리하고, 어느 시점에 어떤 문서를 누가 만드는지를 다룹니다.
실전 랩으로 손에 익히기: PMO·벤더 관리 실습 — PMO 유형·멀티벤더 조율·통합 관리를 설계합니다.
관련 모듈로 더 깊이:
- 공공 정보화사업과 감리 — 공공사업에서 다자 구조를 감리·검사로 통제하는 앞 단계
- 프로젝트 역할 — PMO가 조율하는 PM·PL·SE 등 프로젝트 역할의 책임 구분
- 계약·과업범위·M/M·검수 — 벤더 관리의 바탕이 되는 과업범위·M/M·검수의 경계