같은 프로젝트, 두 PM의 금요일.
A는 한 주 내내 부지런했습니다. 고객 실무 담당자와 매일 통화하며 요청을 즉시 처리하고, 협력사 개발자와도 수시로 메신저로 조율했습니다. 그런데 금요일 오후, 발주사 임원이 갑자기 전화합니다. "이 프로젝트 지금 어떻게 돌아가는 겁니까? 나는 보고를 못 받았는데요." A는 당황합니다 — 실무자와는 매일 이야기했지만, 정작 예산과 일정을 쥔 사람에게는 한 마디도 전하지 않았던 것입니다.
B는 주초에 이해관계자를 종이 한 장에 그려뒀습니다. 실무 담당자(관심 높음·영향 보통)에게는 매일 챙기고, 발주사 임원(영향 높음·관심 낮음)에게는 금요일마다 한 페이지 요약 보고를 보냅니다. 협력사 PM과는 주간 회의를 잡고, 회의 때마다 **결정사항과 액션아이템(담당·기한)**을 회의록으로 남겨 모두에게 공유합니다. 같은 금요일, B의 임원은 이미 요약 보고를 받아 상황을 알고 있습니다.
둘의 차이는 성실함이 아닙니다. A도 충분히 부지런했습니다. 차이는 **"누구에게, 무엇을, 언제, 어떻게 전할지를 미리 설계했는가"**입니다. 이 모듈은 그 설계 — 이해관계자를 식별·분석하고, 관여 전략을 세우고, 회의록으로 커뮤니케이션을 증거로 남기는 법 — 를 다룹니다.
- 1프로젝트의 이해관계자를 빠짐없이 식별하고, 관심도×영향력 매트릭스로 분석할 수 있다
- 2매트릭스의 네 구역(면밀 관리·만족 유지·정보 제공·모니터링)에 맞는 관여 전략을 세울 수 있다
- 3커뮤니케이션 계획(누구·무엇·언제·채널·주기)을 표로 설계해 보고 누락을 막을 수 있다
- 4회의록에 논의·결정사항·액션아이템(담당·기한)을 구분해 기록하고, 결정과 미결을 분리할 수 있다
- 5R&R(역할과 책임)을 명확히 해 "누가 그걸 하기로 했지?"가 사라지게 만들 수 있다
이해관계자를 먼저 '식별'한다
보이는 사람만 챙기면, 안 보이는 사람이 프로젝트를 흔든다
커뮤니케이션의 출발점은 채널이나 보고서가 아니라 **'누구에게 전할 것인가'**입니다. 그 '누구'의 목록이 이해관계자(Stakeholder) — 프로젝트에 영향을 주거나 받는 모든 사람·조직입니다.
초보 PM은 눈앞에 있는 사람(매일 통화하는 고객 실무자, 같이 일하는 개발자)만 이해관계자로 인식합니다. 그러나 시나리오의 A처럼, 안 보이지만 영향력이 큰 사람(발주사 임원, 스폰서, 감사 부서)을 빠뜨리면 프로젝트가 흔들립니다. 그래서 첫 단계는 빠짐없이 적어보는 식별입니다.
SI/SM 프로젝트의 전형적인 이해관계자 지도:
| 구분 | 누구인가 | 이들이 신경 쓰는 것 |
|---|---|---|
| 발주사(고객) 임원·스폰서 | 예산·계약을 쥔 의사결정권자 | 일정·예산·성과, 큰 리스크 |
| 발주사 현업·실무 담당 | 시스템을 실제로 쓸 사람 | 기능이 자기 업무에 맞는가 |
| 원청(SI 주사업자) PM | 전체 사업을 책임지는 관리자 | 범위·일정·품질, 협력사 통제 |
| 협력사(하도급) 엔지니어 | 실제 개발·작업을 수행 | 명확한 과업, 일정 부담 |
| 운영(SM)팀 | 오픈 후 운영을 인수받을 팀 | 인수인계·문서·안정성 |
| 감사·보안·법무 | 규정·보안을 점검 | 규정 준수, 보안 요건 |
식별의 요령은 **"이 사람이 빠지면 나중에 문제가 되는가?"**를 묻는 것입니다. "감사 부서는 마지막에만 보면 되겠지" 하고 빼면, 오픈 직전 보안 점검에서 막혀 일정이 통째로 밀립니다. 일단 넓게 적고, 그다음 분석으로 관여의 강도를 차등합니다.
관심도 × 영향력으로 '분석'한다
모두에게 똑같이 쏟으면, 정작 중요한 사람을 놓친다
이해관계자를 다 적었다면, 모두에게 같은 노력을 쏟을 수는 없습니다. 시간과 보고는 한정돼 있으니까요. 그래서 두 축으로 분석해 관여 강도를 차등합니다.
- 영향력(Power) — 이 사람이 프로젝트의 의사결정·예산·일정을 흔들 힘이 있는가.
- 관심도(Interest) — 이 사람이 프로젝트의 진행에 얼마나 관심·관여하는가.
두 축을 높낮이로 나누면 네 구역이 나오고, 각 구역마다 다른 전략을 씁니다.
| 구역 | 영향력 | 관심도 | 관리 전략 | 대표 예시 |
|---|---|---|---|---|
| 면밀 관리(Manage Closely) | 높음 | 높음 | 가장 긴밀하게 — 자주 소통, 의사결정에 참여시키고 만족을 적극 관리 | 발주사 PM, 원청 PM, 핵심 현업 책임자 |
| 만족 유지(Keep Satisfied) | 높음 | 낮음 | 큰 그림(마일스톤·예산·리스크)만 간결히 정기 보고해 만족시키되 세부로 피곤하게 하지 않음 | 발주사 임원, 스폰서 |
| 정보 제공(Keep Informed) | 낮음 | 높음 | 진행 상황을 꾸준히 알림 — 관심이 높으니 정보 갈증을 채워 우군으로 만듦 | 현업 실무자, 운영(SM)팀 |
| 모니터링(Monitor) | 낮음 | 낮음 | 최소한의 정보만, 상태 변화만 관찰 — 과한 노력 불필요 | 일반 사용자, 간접 관련 부서 |
가장 자주 틀리는 지점이 '만족 유지' 구역입니다. 영향력이 높다고 해서 발주사 임원을 매일 실무 회의에 부르면, 그는 세부에 관심이 없으니 피곤해하고 신뢰가 떨어집니다. 반대로 "관심 없으시니 보고 안 드려도 되겠지" 하면, 정보가 끊긴 임원은 어느 날 갑자기 개입해 프로젝트를 흔듭니다. 적정한 거리에서, 요약된 큰 그림을, 정기적으로 — 이것이 만족 유지의 핵심입니다.
또 하나, 이 매트릭스는 고정이 아닙니다. 평소 관심 낮던 임원도 장애·지연이 터지면 관심도가 급등합니다. 위기 때는 매트릭스를 다시 그려 관여 전략을 조정해야 합니다.
그림: 관심도×영향력으로 이해관계자를 네 구역으로 나눠 관여 강도를 차등한다 — 영향력 높고 관심 낮은 임원(만족 유지)을 놓치면 프로젝트가 흔들린다.
커뮤니케이션 계획 — 누구·무엇·언제·채널·주기
'그때그때'는 반드시 누락된다 — 보고를 시스템으로 만든다
이해관계자를 분석했다면, 이제 각자에게 무엇을 언제 어떻게 전할지를 미리 표로 못 박습니다. 이것이 **커뮤니케이션 계획(Communication Plan)**입니다. 시나리오의 A가 임원 보고를 빠뜨린 것은 게을러서가 아니라, '언제 누구에게 보고한다'는 약속이 없었기 때문입니다. 즉흥에 맡기면 바쁜 주에는 반드시 누락됩니다.
커뮤니케이션 계획은 다섯 칸으로 설계합니다.
- 누구(대상) — 어떤 이해관계자/그룹에게.
- 무엇(내용) — 어떤 정보를(진척률·리스크·마일스톤·이슈 등).
- 언제·주기 — 얼마나 자주(주간·격주·마일스톤마다·수시).
- 채널 — 어떤 수단으로(주간보고서·회의·메일·메신저·대시보드).
- 담당 — 누가 그 커뮤니케이션을 책임지는가.
예시 커뮤니케이션 계획:
| 대상 | 무엇(내용) | 주기 | 채널 | 담당 |
|---|---|---|---|---|
| 발주사 임원(만족 유지) | 마일스톤·예산·주요 리스크 요약(1장) | 주 1회(금) | 요약 보고서(메일) | 원청 PM |
| 발주사 PM(면밀 관리) | 상세 진척·이슈·결정 필요 사항 | 주 1회 회의 + 수시 | 주간회의·메신저 | 원청 PM |
| 현업 실무자(정보 제공) | 화면·기능 진행, 검토 요청 | 격주 | 데모·메일 | 업무 분석가 |
| 협력사 PM(면밀 관리) | 과업 진행·블로커·일정 | 주 1회 회의 | 개발 주간회의 | 원청 PM |
| 운영(SM)팀(정보 제공) | 오픈 일정·인수인계 산출물 | 마일스톤마다 | 인수인계 회의 | 원청 PM |
계획의 핵심 효과는 '중요한 사람에게 정기적으로 전달된다'는 보장입니다. 임원에게는 금요일마다 한 장이 가고, 협력사와는 매주 회의가 돌아갑니다. 보고가 PM의 기억력이 아니라 달력에 박힌 약속이 되는 것 — 이것이 누락을 막는 유일한 방법입니다.
회의록 — 말한 것을 증거로 남긴다
논의·결정·액션을 분리하고, 결정과 미결을 나눈다
회의는 커뮤니케이션이 가장 밀도 높게 일어나는 자리입니다. 그런데 회의가 끝나고 나면 **"그래서 뭐가 정해졌지?", "그거 누가 하기로 했지?"**가 흐려집니다. 이것을 막는 도구가 **회의록(Minutes)**입니다.
좋은 회의록은 세 가지를 분리해서 적습니다.
- 논의(Discussion) — 무슨 이야기가 오갔는가. 배경·근거를 남겨, 나중에 "왜 그렇게 정했지?"에 답합니다.
- 결정사항(Decisions) — 합의되어 확정된 사실. "API 연동은 REST로 한다", "오픈은 6월 30일로 한다." 이미 끝난 결론입니다.
- 액션아이템(Action Items) — 결정을 실현하기 위해 누가·언제까지·무엇을 할 것인가. 담당자와 기한이 반드시 붙어야 합니다.
이 셋을 섞으면 회의가 '말잔치'로 끝납니다. 결정만 적고 액션을 빠뜨리면 '정해졌는데 아무도 안 하는' 일이 생기고, 액션만 적고 논의 배경을 빠뜨리면 다음에 "왜 이렇게 했지?"로 되돌아갑니다.
또 하나 중요한 구분이 결정과 미결(Open Issues)의 분리입니다. 회의에서 모든 게 정해지지는 않습니다. **이번에 확정된 것(결정)**과 **아직 못 정해 다음으로 넘기는 것(미결)**을 따로 적어두면, 미결 항목이 추적되어 어딘가에서 증발하지 않습니다.
| 회의록 항목 | 무엇을 적나 | 왜 필요한가 |
|---|---|---|
| 논의 | 오간 의견·배경·근거 | 나중에 "왜 그렇게 정했나" 답변 |
| 결정사항 | 확정된 결론 | 합의의 증거, 번복 방지 |
| 액션아이템 | 담당·기한·할 일 | 실행·추적·독촉의 근거 |
| 미결(Open Issue) | 못 정한 것 + 다음 결정 시점 | 미결 항목 증발 방지 |
직접 해보기 — 이해관계자 분석 표와 회의록 템플릿
아래는 '정산 시스템 구축' SI 프로젝트의 이해관계자 분석 표 일부입니다. 관심도·영향력을 판정하고 → 매트릭스 구역에 따라 전략을 도출하는 흐름에 주목하세요. 빈 행(운영(SM)팀)을 직접 채워 보세요.
| 이해관계자 | 관심도 | 영향력 | 관리 전략 | 핵심 메시지 |
|---|---|---|---|---|
| 발주사 임원(스폰서) | 낮음 | 높음 | 만족 유지 | 마일스톤·예산·리스크만 주간 요약 |
| 발주사 PM | 높음 | 높음 | 면밀 관리 | 상세 진척·결정 필요 사항, 긴밀 소통 |
| 현업 실무 담당 | 높음 | 보통 | 정보 제공 | 화면·기능 진행, 검토 요청 |
| 협력사 개발 PM | 높음 | 보통 | 면밀 관리 | 과업·블로커·일정, 주간 회의 |
| 운영(SM)팀 | (직접 작성) | (직접 작성) | (직접 작성) | (직접 작성) |
작성 요령: 운영(SM)팀은 보통 오픈 전까지는 관심이 낮다가 인수인계 시점에 관심이 급등합니다. 지금 시점의 관심·영향을 판정하되, 시점에 따라 전략이 바뀔 수 있음을 메모로 남기세요. 핵심 메시지 칸에는 "이 사람에게 한 줄로 무엇을 전할 것인가"를 적습니다.
이해관계자 · 관심도 · 영향력 · 전략아래 회의록 템플릿에서 액션아이템에 담당·기한이 붙었는지, 결정과 미결이 분리됐는지를 확인하며 빈칸을 채워 보세요.
| 항목 | 내용 |
|---|---|
| 회의명 | 정산 시스템 구축 주간 진척 회의 (3주차) |
| 일시·장소 | 2026-06-22 14:00 / 발주사 회의실 |
| 참석자 | 발주사 PM(김), 원청 PM(박), 협력사 개발 PM(이), 업무분석가(최) |
| 안건 | 1. API 연동 방식 확정 2. 검수 일정 협의 3. 추가 요청(모바일) 처리 |
논의·결정·액션·미결을 나눠 적습니다.
| 구분 | 내용 | 담당 | 기한 |
|---|---|---|---|
| 논의 | 외부 쇼핑몰 연동을 REST/파일배치 중 무엇으로 할지 검토. 실시간성 요구로 REST 우세 | — | — |
| 결정 | API 연동 방식은 REST로 확정 | — | — |
| 액션 | REST 연동 인터페이스 설계서 작성 | 협력사 이 | 06-27 |
| 액션 | 검수 일정 초안 작성해 발주사 회람 | 원청 박 | 06-25 |
| 미결 | 모바일 화면 추가 요청 → 범위 밖, 변경요청(CR)으로 처리할지 다음 회의에서 결정 | (직접 작성) | (직접 작성) |
작성 요령: 미결 행의 담당·기한을 직접 채우세요(예: 담당=원청 박 / 기한=다음 회의 전까지 영향 산정). 미결에도 "언제 다시 결정할지"가 붙어야 증발하지 않습니다. 그리고 이 회의록은 작성 후 참석자 전원에게 공유하고 이의 없음을 확인해야 비로소 '증거'가 됩니다 — 그게 마지막 한 칸입니다.
참석 · 안건 · 논의 · 결정 · 액션아이템 · 미결- 이해관계자 분석 표에서 운영(SM)팀의 관심도·영향력이 "시점에 따라 변한다"는 메모와 함께 판정됐는지(인수인계 시점에 관심 급등)
- 모든 이해관계자에게 관리 전략(면밀 관리·만족 유지·정보 제공·모니터링) 중 하나가 매핑됐는지
- 회의록의 액션아이템마다 담당자와 기한이 빠짐없이 붙었는지 — 담당·기한 없는 액션은 실행되지 않는다
- 결정사항(확정)과 미결(Open Issue)이 분리돼 있고, 미결에도 "언제 다시 결정할지"가 적혔는지
- 추가 요청(모바일)이 "그냥 해드릴게요"가 아니라 변경요청(CR) 검토 대상으로 회의록에 기록됐는지 — 구두 합의 금지
- 핵심 감각: 이해관계자 분석 표와 회의록은 "나중에 누가 됐다/안 됐다, 누가 하기로 했다/아니다로 다툴 때 펴 보는 합의 문서"다 — 작성 후 공유·확인까지 마쳐야 증거가 된다
현장에서 자주 보는 함정
증상: 프로젝트 후반, 범위·일정·비용을 두고 발주사와 수행사가 부딪칩니다. 고객은 "그 기능은 분명히 해주기로 했다"고 하고, 수행사는 "그런 합의는 없었다"고 맞섭니다. 양쪽 다 진심입니다 — 기억이 서로 다르게 굳었을 뿐입니다. 입증할 문서가 없으니 결국 목소리 큰 쪽, 또는 갑(발주사)의 뜻대로 흘러가고, 수행사는 손해를 봅니다.
원인: 합의가 구두로만 오갔고, 회의록으로 남기고 공유·확인받는 절차가 없었습니다. 매일 통화하고 메신저로 조율했지만, "오늘 무엇이 결정됐고 누가 무엇을 하기로 했는지"를 글로 정리해 양쪽이 확인한 기록이 없습니다. 구두 합의는 기억이 엇갈리는 순간 증거력이 0이 됩니다. 특히 발주사·원청·협력사가 얽힌 다자 구조에서는, 한 채널의 합의가 다른 채널에 전달되지 않아 더 꼬입니다.
해결 방향(이 모듈에서 다룬 것):
- 모든 회의를 회의록으로 남기고, 결정사항·액션아이템·미결을 분리해 적는다.
- 회의록을 참석자 전원에게 공유하고, 일정 기간(예: 2영업일) 내 이의가 없으면 확정으로 간주한다는 규칙을 둔다 — 공유·확인까지 마쳐야 증거다.
- 고객의 추가 요청은 구두로 받지 않고, 회의록·변경요청(CR)으로 문서화해 범위·일정·비용 영향과 함께 의사결정을 받는다.
- 이해관계자 분석으로 '영향력 큰 사람'에게도 정기 보고가 가게 해, "나는 못 들었다"는 사태(시나리오의 A)를 막는다.
회의록을 잘 쓰는 비결은 문장력이 아니라 습관과 절차입니다. "말로 끝내지 않는다, 적고 공유하고 확인받는다" — 이 한 줄이 SI/SM 현장에서 PM과 회사를 지키는 가장 값싸고 강력한 방어선입니다.
한국 SI/SM 현장에서 PM의 일은 코드가 아니라 사람과 말의 흐름을 통제하는 일에 가깝습니다. 발주사(갑)·원청(을)·협력사(병)가 한 프로젝트에 얽혀 있고, 정보는 이 사이를 정확히 흘러야 합니다. 여기서 PM이 반드시 챙기는 세 가지가 있습니다.
- 이해관계자 빠짐없이 챙기기 — 매일 보는 실무자만이 아니라, 예산·일정을 쥔 발주사 임원(만족 유지), **오픈 후 운영을 받을 SM팀(정보 제공)**까지 지도에 올립니다. "나는 보고를 못 받았다"는 임원의 한마디가 잘 굴러가던 프로젝트를 흔드는 일이 실제로 자주 일어납니다.
- 회의록이 곧 증거 — 갑·을·병이 얽힌 구조에서 분쟁은 '말의 진실'을 다투는 일이 됩니다. 회의록에 결정·합의·고객 요청을 적고 공유·확인까지 받아두는 것이, 나중에 범위 변경·일정 지연·추가 비용을 두고 다툴 때 회사를 지키는 근거가 됩니다. 신입 시절 "회의록은 잡무"라고 여겼다가, 분쟁 한 번에 그것이 가장 중요한 산출물임을 배우는 PM이 많습니다.
- R&R 명확화 — "이건 우리 일이 아닌데요 / 협력사가 하는 줄 알았는데요"로 일이 공중에 뜨는 것을 막습니다. 회의록의 액션아이템에 담당과 기한을 못 박는 것이 R&R을 글로 굳히는 가장 실전적인 방법입니다. 책임 소재가 흐릿하면, 잘된 일은 서로 자기 공이고 안 된 일은 서로 남 탓이 됩니다.
기술을 아는 PM이 강한 이유가 여기서도 드러납니다 — 협력사가 "그건 다음 주에 됩니다"라고 회의에서 말할 때, 그 말의 현실성을 가늠해 액션아이템의 기한을 합리적으로 못 박고, 무리한 약속이 회의록에 그대로 박히지 않게 조율할 수 있습니다. 이해관계자를 읽고, 말한 것을 증거로 남기고, 책임을 글로 굳히는 능력 — 이것이 갑과 병 사이에서 프로젝트를 지키는 PM의 비기술적이지만 가장 핵심적인 무기입니다.
관련 모듈로 더 깊이:
- 회의록·액션아이템·관리대장 — 증거가 되는 회의록·액션아이템을 실제로 작성하는 법
- 주간보고·경영보고 — 이해관계자별 보고를 주간 경영 보고로 정리하는 법
- 프로젝트 역할 — R&R 명확화의 토대가 되는 발주사·원청·협력사 역할 구분
다음 모듈에서는 이런 관리 직무가 실제로 어떤 산업 구조 위에서 작동하는지 — SI(시스템 통합)·SM(시스템 유지보수)·SaaS의 사업 구조와 그 안에서 발주사·원청·협력사가 맺는 계약·역할 관계를 정리합니다.