대형 공공 차세대 시스템. 원청 한 곳, 그 아래 협력사 셋이 각각 다른 영역을 맡습니다. 협력사 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의 일은 벤더를 의심하는 게 아니라, 각자 정직하게 일해도 인계 지점에서 어긋날 수 있다는 전제 위에서 그 틈을 통합으로 메우는 것입니다.
한국 대형 SI 현장에서 이 일은 원청 PMO·사업관리(PM) 자리의 핵심 업무입니다. 발주사(공공기관·대기업)는 원청 한 곳에 책임을 묻고, 원청 PMO는 그 아래 복수 협력사(다단계 하도급 포함)의 진척·품질·이슈를 통제해 발주사에 통합 보고합니다. 당신이 직접 코드를 짜지 않더라도, 산출물 양식을 정하고, 마스터 스케줄을 운영하고, 매주 협력사 점검회의를 주재하고, 통합 이슈/리스크 대장을 갱신하며, 발주사 보고를 책임지는 자리입니다.
이 자리에서 가장 자주 쓰는 무기가 바로 이 모듈의 두 산출물 — PMO 관리 항목 표(무엇을 어떤 기준으로 통제하는가)와 통합 이슈/리스크 관리대장(누가 어디서 막혔고 어디로 올릴 것인가) — 입니다. 협력사 엔지니어가 실제 작업을 하더라도 일정·품질·범위·산출물에 대한 책임은 원청 관리자에게 있고, 잘못된 '정상' 보고에 속지 않으려면 인수 기준과 통합 뷰로 교차 검증하는 감각이 필수입니다. 기술을 아는 PMO는 협력사와 대등하게 대화하고, '냈다'와 '쓸 수 있다'의 차이를 판정할 수 있습니다.
다음 모듈에서는 이런 관리자가 협력사와 대등하게 대화하기 위해 갖춰야 할 — 관리자를 위한 IT 기술 기초(Web/WAS/DB)의 구조와 용어를 정리합니다.
관련 모듈로 더 깊이:
- 공공 정보화사업과 감리 — 공공사업에서 다자 구조를 감리·검사로 통제하는 앞 단계
- 프로젝트 역할 — PMO가 조율하는 PM·PL·SE 등 프로젝트 역할의 책임 구분
- 계약·과업범위·M/M·검수 — 벤더 관리의 바탕이 되는 과업범위·M/M·검수의 경계