이해관계자, 소통, 의사결정

cd ~/gh-pm-lab
source pm-lab/env.sh

1이해관계자 찾기

이해관계자(stakeholder)는 프로젝트의 결정이나 결과에 영향을 주거나 받는 사람과 조직이다. 회의에 오는 사람만 적으면 빠지는 사람이 생긴다. 다음 순서로 찾는다.

1. 결과물을 쓰는 사람과 결과물 때문에 일이 바뀌는 사람: 베타 신청자, 고객지원.
2. 승인하거나 막을 수 있는 사람: 스폰서, 법무, 개인정보 담당.
3. 자원을 대는 사람: 개발·QA 팀, QA를 겸임시키는 다른 프로젝트, 외부 업체.
4. GitHub 기록에 나타난 사람: 결정 기록의 결정자, 리뷰어, 범위 변경을 요청한 사람(실습 12의 LP-07 요청자).

Launchpad에서는 일곱 이해관계자를 찾았다. 이름 대신 역할로 적는다. 분석표는 사람을 평가하는 문서로 읽힐 수 있으므로 공개 범위를 팀으로 제한하고, 사람에 대한 의견 대신 관심사와 기대를 적는다.

2세 가지 분석: 격자, 현저성, 참여 수준

권력·관심 격자

권력(결과를 바꿀 수 있는 정도)과 관심(결과에 신경 쓰는 정도)을 1~5로 매기고 3 이상을 높음으로 본다. 네 칸마다 기본 전략이 다르다. 키트의 분석표 예시에서 칸을 계산해 보자.

awk -F'|' '$2 ~ /S-[0-9]/ {
  id = $2; gsub(/ /, "", id); name = $3; gsub(/^ +| +$/, "", name)
  p = $4 + 0; i = $5 + 0
  q = (p >= 3) ? ((i >= 3) ? "긴밀히 관리" : "만족 유지") : ((i >= 3) ? "계속 알림" : "관찰")
  printf "%s  권력 %d 관심 %d  %s  %s\n", id, p, i, q, name
}' github-pm-starter-kit/samples/d-stakeholder-register.md

S-01  권력 5 관심 4  긴밀히 관리  스폰서(사업본부장)
S-02  권력 4 관심 2  만족 유지  법무 담당
S-03  권력 2 관심 5  계속 알림  마케팅 담당
S-04  권력 3 관심 5  긴밀히 관리  개발·QA 팀(dev-kim, dev-lee, qa-park)
S-05  권력 2 관심 2  관찰  고객지원 리드
S-06  권력 3 관심 1  만족 유지  알림 발송 서비스 업체
S-07  권력 1 관심 3  계속 알림  베타 신청자

격자는 지금의 값이다. 고객지원은 베타가 시작되어 문의가 생기면 관심이 올라가므로 M1 1주 전에 다시 매긴다. 격자의 칸은 기본값이고, 마케팅처럼 권력은 낮아도 범위 요청(LP-07)을 계속 내는 이해관계자에게는 요청이 결정되는 경로를 따로 알려 준다.

현저성 모델

미첼(R. K. Mitchell), 애글(B. R. Agle), 우드(D. J. Wood)는 1997년 Academy of Management Review에서 이해관계자가 얼마나 주목받는지(현저성, salience)를 세 속성으로 설명했다. 권력(power)은 원하는 결과를 강제할 수 있는 힘, 정당성(legitimacy)은 요구가 사회적으로 받아들여지는 정도, 긴급성(urgency)은 요구가 시간에 민감하고 중요한 정도다. 속성을 몇 개 갖느냐로 일곱 유형이 된다.

격자와 달리 이 모델은 속성이 바뀌면 유형이 바뀐다는 점을 다룬다. 아래 세 경우의 유형을 정하자.

1. 평소의 스폰서(사업본부장): 예산과 마감을 정할 수 있고, 회사가 그 권한을 인정한다. M1이 위험하다는 보고를 받은 뒤에는 이번 주 안에 답을 원한다.
2. 알림 발송 업체: 계정 승인으로 LP-04를 멈출 수 있지만 Launchpad의 결정에 요구할 권리는 없고, 서두르지도 않는다.
3. 마케팅 담당: 유입 경로 기록(LP-07)을 베타 전에 원한다. 요구는 회사 목표(신청 1,000건)와 맞지만 범위를 정할 권한은 없다.

참여 수준 평가 매트릭스

참여 수준을 모름, 저항, 중립, 지지, 주도의 다섯 단계로 나누고, 이해관계자마다 현재(C)와 목표(D)를 표시한다. 차이가 큰 칸부터 참여 전략을 쓴다.

차이가 가장 큰 것은 베타 신청자(세 칸)와 고객지원(두 칸)이다. 둘 다 권력이 낮아 격자만 보면 뒤로 밀리지만, M1에서 베타 초대를 받는 사람과 그 문의를 받는 사람이다. 분석표의 참여 전략 열에 신청 완료 화면의 일정 안내와 M1 1주 전 위키 안내를 적은 이유다. 키트의 양식은 templates/stakeholder-register.md, 채운 예는 samples/d-stakeholder-register.md다.

cp github-pm-starter-kit/templates/stakeholder-register.md pm-lab/stakeholder-register.md

3소통 계획

소통 계획은 대상, 알릴 것, 주기와 시점, 형식과 매체, 담당을 정한다. 이 과정에서는 두 열을 더한다. 그 소통이 남기는 GitHub 기록과, 상대가 받았는지 확인하는 방법이다. 보냈다는 기록만 있고 받았는지 확인할 방법이 없으면, 10월 23일 결정 요청처럼 결정자가 요청을 읽었는지 알 수 없다.

소통은 정기 소통과 사건 소통으로 나눈다. 사건 소통은 정해 둔 조건이 생기면 정기 주기를 기다리지 않는다.

cp github-pm-starter-kit/templates/communication-plan.md pm-lab/communication-plan.md

## 사건 소통 (조건이 생기면)

| 조건 | 대상 | 알릴 것 | 기한 | 형식과 매체 | 담당 |
| - | - | - | - | - | - |
| 예상 완료일이 일정 허용 범위(2작업일)를 넘는다 | S-01 | 예외 보고: 원인, 예상 완료일, 선택지 | 판정한 날부터 1작업일 | 결정 요청 이슈, 메신저로 링크 | PM |
| 결정 요청이 기한을 넘긴다 | 결정자 | 대기 중인 결정과 늦어질 때의 영향 | 다음 작업일 아침 | decision-queue.sh 결과 댓글 | PM |
| 리스크 점수 15 이상이 새로 생긴다 | S-01, S-04 | 리스크 서술과 대응 | 1작업일 | kind:risk 이슈, 상태 보고 | PM |
| 개인정보 관련 결함을 찾는다 | S-01, S-02 | 결함 내용, 영향 범위, 조치 | 당일 | 비공개 채널로 먼저 알리고 이슈에는 요약만 적는다 | QA |

정기 소통 표 전체는 samples/d-communication-plan.md에 있다. 매주 금요일 상태 보고(실습 16), 매주 수요일 사전 리포트(실습 11), 격주 스프린트 리뷰가 정기 소통이다.

4믿을 수 있는 상태 보고와 나쁜 소식의 시점

상태 보고가 믿을 만하려면 두 규칙을 지킨다. 판정 기준은 보고를 시작하기 전에 정하고 중간에 바꾸지 않는다. 지표로 정한 판정과 PM의 판단이 다르면 둘 다 적고 이유를 쓴다. 판정을 말없이 고치면 이해관계자는 다음 보고부터 모든 판정을 의심한다.

실습 14의 10월 21일 값으로 연습한다. 공수 영역은 CPI 0.76으로, 기준(0.85 미만 적색)에 따르면 적색이다. 그런데 AC 42시간 가운데 LP-01의 18시간은 추정 12시간보다 6시간 많고, 그 6시간은 10월 14일 법무 의견으로 정책을 한 번 다시 쓴 시간이며 다시 일어나지 않는다고 PM이 판단했다고 하자. 그 6시간을 빼면 CPI는 32 ÷ (42 − 6) = 32 ÷ 36 = 0.89로 황색 기준(0.85 이상)에 든다.

| 공수 | 적색 (판단: 황색) | CPI 0.76, EAC 147h (BAC 112h). 판단이 다른 이유: AC 42h 중 6h는 LP-01 정책 재작성(10-14 법무 의견) 1회분이다. 이를 빼면 CPI 0.89. 10-28 보고에서도 CPI가 0.85 미만이면 판단도 적색으로 한다. |

기준에 따른 판정(적색)을 지우지 않고 앞에 둔다. 판단의 근거와 그 판단을 거둘 조건(다음 주에도 0.85 미만이면)을 함께 적는다.

나쁜 소식은 정기 보고를 기다리지 않는다. 10월 21일(수)에 EVM 예상 완료일 11월 19일이 나왔다. 그날 알리면 결정 기한(10월 23일)까지 3작업일이 있고, 결정이 22일에 나면 선택지 2(Sprint 2 첫날인 10월 26일부터 개발 1명 추가)를 위해 다른 팀과 사람을 조정할 날이 남는다. 금요일 정기 보고(10월 23일 오후)로 알리면 결정과 조정을 같은 날 해야 하므로 선택지 2는 사실상 사라진다. 늦게 알릴수록 선택지가 줄어든다. 소통 계획의 사건 소통 첫 줄(판정한 날부터 1작업일)이 이 규칙이다.

5결정 요청과 결정 회의

결정 요청은 여섯 부분으로 쓴다.

결정 회의는 결정 요청만 안건으로 둔다. 요청 이슈를 회의 1작업일 전까지 결정자에게 보내고, 회의에서는 선택지의 숫자를 확인하고 결정한 뒤 결과를 결정 기록 댓글(실습 10)로 남기고 이슈를 닫는다. 결정자가 회의에 오지 못하면 결정을 위임받은 사람을 이슈에 적는다.

키트의 결정 요청 양식 templates/ISSUE_TEMPLATE/decision.yml은 이 여섯 부분과 관련 이슈 칸을 둔다. 결정자와 결정 기한은 필수 칸이다. 3단계의 리스크 양식과 같은 방법으로 저장소의 .github/ISSUE_TEMPLATE/에 넣고, 라벨을 만든다.

웹에서 양식으로 제출하면 본문은 칸마다 ### 칸 이름 제목 아래에 답이 적힌 Markdown이 된다. 터미널에서는 같은 제목으로 본문 파일을 써서 만든다. 아래는 마케팅이 요청한 LP-07을 M1에 넣을지 정하는 결정 요청이다.

cat > pm-lab/d-04.md <<'EOF'
### 결정할 것

마케팅이 요청한 유입 경로 기록을 M1 범위에 넣을지 정한다.

### 선택지와 영향

1. M1에 넣는다: 16h 추가. Sprint 2에는 Sprint 1에서 이월된 LP-02, LP-03이 이미 있다
2. M2에 둔다: 베타 기간의 유입 경로는 남지 않는다

### 권고안

2

### 결정자

스폰서(사업본부장)

### 결정 기한

2026-10-30

### 늦어질 때의 영향

Sprint 2 계획을 다시 해야 한다.

### 관련 이슈

LP-07
EOF

6결정 대기 목록

열린 결정 요청을 결정 기한으로 나누면 결정 대기 목록이 된다. gh issue list의 --json 필드는 gh 2.101.0 소스에서 확인했다. labels는 name, color 등이 든 객체의 배열이고, assignees는 login이 든 객체의 배열이며, createdAt은 UTC 시각이다. 키트의 decision-queue.sh는 이 JSON에서 본문의 “결정 기한”과 “결정자”를 찾는다. 양식으로 만든 본문(### 결정 기한 다음 줄)과 실습 16 상태 보고의 형식(- 결정 기한: 2026-10-23(금))을 모두 읽는다.

gh issue list -R "$PM_REPO" --label kind:decision --state open --limit 200 \
  --json number,title,createdAt,labels,assignees,body,url > pm-lab/decisions.json
jq -r '.[] | "#\(.number) \(.createdAt) \(.title)"' pm-lab/decisions.json
bash github-pm-starter-kit/decision-queue.sh pm-lab/decisions.json --today 2026-10-28

재현 화면의 이슈 여섯 건은 키트의 samples/d-decisions.json과 같다. 실습 저장소에 결정 요청이 없으면 이 파일로 같은 결과를 얻는다: bash github-pm-starter-kit/decision-queue.sh github-pm-starter-kit/samples/d-decisions.json --today 2026-10-28.

• 기한이 지난 요청: D-01(M1 일정 조정안)은 10월 23일이 기한이었고 3작업일이 지났다. 실습 16의 결정 요청을 이슈로 옮긴 것이다. 결정자가 스폰서이므로 소통 계획의 사건 소통 둘째 줄에 따라 스폰서에게 이 목록을 보낸다.
• 2작업일 안: D-03(QA 교차 검증 담당)은 오늘이 기한이다. LP-05가 다음 날(10월 29일) 시작하므로 오늘 결정되지 않으면 바로 일정에 영향을 준다.
• 기한이 없는 요청: D-06(개인정보 보관 기간)은 양식을 쓰지 않아 기한과 결정자가 없다. 목록은 순서를 정할 수 없다고 알린다. 요청자에게 기한과 결정자를 받아 본문에 적는다.

“지난 작업일”과 “요청 후 작업일”은 주말을 뺀 작업일이다. 요청일은 createdAt(UTC)을 한국 시각(--tz +09:00)으로 바꿔 센다. 여러 저장소의 결정 요청을 모을 때는 gh search issues --label kind:decision --state open --owner 조직 --json number,title,createdAt,labels,assignees,body,url,repository의 결과를 같은 스크립트에 넣는다. 검색 결과에는 repository 필드가 더 있다.

매일 아침 점검

--fail-overdue를 붙이면 기한이 지난 요청이 있을 때 종료 코드 2로 끝난다. 워크플로가 이 코드를 보고 댓글을 올릴지 정한다.

bash github-pm-starter-kit/decision-queue.sh pm-lab/decisions.json --today 2026-10-28 --fail-overdue > pm-lab/queue.md; echo "종료 코드 $?"
bash github-pm-starter-kit/decision-queue.sh pm-lab/decisions.json --today 2026-10-22 --fail-overdue > pm-lab/queue.md; echo "종료 코드 $?"

종료 코드 2
종료 코드 0

키트의 templates/workflows/decision-queue.yml은 평일 아침 08:43(한국 시각)에 이 명령을 실행하고, 기한이 지난 요청이 있을 때만 저장소 변수 DECISION_ISSUE에 적은 이슈에 목록을 댓글로 올린다. 이슈만 읽고 쓰므로 워크플로의 기본 토큰으로 동작하고, Project 권한은 필요 없다.

      - name: 결정 대기 목록 만들기
        id: queue
        env:
          GH_TOKEN: ${{ github.token }}
        run: |
          gh issue list -R "${{ github.repository }}" --label kind:decision --state open --limit 200 \
            --json number,title,createdAt,labels,assignees,body,url > decisions.json
          today=$(TZ=Asia/Seoul date +%F)
          set +e
          bash github-pm-starter-kit/decision-queue.sh decisions.json --today "$today" --fail-overdue > queue.md
          rc=$?
          set -e
          cat queue.md
          if [ "$rc" -eq 2 ]; then echo "overdue=true" >> "$GITHUB_OUTPUT"; elif [ "$rc" -ne 0 ]; then exit "$rc"; fi

      - name: 기한이 지난 요청이 있으면 댓글로 올리기
        if: steps.queue.outputs.overdue == 'true'
        env:
          GH_TOKEN: ${{ github.token }}
          DECISION_ISSUE: ${{ vars.DECISION_ISSUE }}
        run: gh issue comment "$DECISION_ISSUE" -R "${{ github.repository }}" --body-file queue.md

gh variable set DECISION_ISSUE -R "$PM_REPO" --body 31

위 명령의 31은 결정 대기 목록을 받을 이슈 번호의 예다. 실습 저장소에서는 운영 이슈 번호나 결정 대기 목록용으로 새로 만든 이슈의 번호를 쓴다.

7협상과 갈등 대응

원칙 협상과 BATNA

피셔(R. Fisher)와 유리(W. Ury)는 Getting to Yes(1981)에서 원칙 협상(principled negotiation)의 네 원칙을 제시했다. 사람과 문제를 분리한다. 입장 대신 이익에 집중한다. 서로 이익이 되는 선택지를 여러 개 만든다. 객관적 기준을 쓴다. 그리고 협상이 깨졌을 때 택할 최선의 대안(Best Alternative To a Negotiated Agreement, BATNA)을 미리 알아 두라고 했다. 내 BATNA보다 나쁜 합의는 받지 않는다.

D-04를 두고 마케팅 담당과 PM이 협상한다고 하자. 두 사람씩 역할을 나눠 10분 동안 협상하고, 아래 표와 비교한다.

객관적 기준은 이미 있다. LP-07을 개발 업무로 하면 16시간이 들고, D2의 일정 위험 분석에서 M1 마감 확률은 21.7%였다. 이익을 보면 마케팅에 지금 필요한 것은 채널별 신청 수다. LP-07의 집계 화면은 M2에 있어도 된다. 그래서 다른 선택지가 나온다.

1. 신청 저장 시 주소의 utm_source 값 하나만 신청 기록에 함께 저장한다. LP-03의 저장 로직에 한 칸을 더하는 일로, 개발 담당 추정 3시간이다. 집계 화면은 M2의 LP-07에서 만든다.
2. 채널마다 다른 랜딩 주소를 쓰고, 웹 분석 도구에서 주소별 신청 완료 수를 센다. 개발 0시간, 마케팅 2시간.

갈등 대응 유형

토머스(K. W. Thomas)와 킬만(R. H. Kilmann)은 1974년 갈등 대응 유형 검사(TKI)를 만들었다. 자기 이익을 주장하는 정도(주장성)와 상대 이익을 돕는 정도(협조성)의 두 축으로 다섯 유형을 나눈다. 어느 유형이 늘 옳지 않고, 상황에 맞는 유형을 고른다.

다섯 상황에 맞는 유형을 고르자.

1. 마케팅이 베타 신청자 이메일을 홍보 메일 목록에 넣자고 한다. 동의 문구에는 홍보 수신이 없다.
2. D-04의 LP-07 범위를 두고 마케팅과 PM의 의견이 다르고, 결정 기한까지 3작업일이 있다.
3. QA 담당을 겸임시키는 다른 프로젝트 PM이 11월 첫 주 QA를 모두 가져가겠다고 한다. 두 프로젝트 모두 그 주에 QA가 필요하다.
4. QA 이틀 전, 개발 두 명이 코드 정리 방식을 두고 다툰다. 기능과 일정에는 영향이 없다.
5. 마케팅이 신청 버튼의 색을 브랜드 색으로 바꿔 달라고 한다. 30분이면 된다.

• Launchpad의 이해관계자 일곱을 격자의 네 칸에 놓고 기본 전략을 말할 수 있다.
• 현저성 모델로 스폰서, 알림 발송 업체, 마케팅의 유형을 정하고 유형이 바뀌는 조건을 말할 수 있다.
• 참여 수준 매트릭스에서 차이가 가장 큰 이해관계자와 그 참여 전략을 찾았다.
• pm-lab/stakeholder-register.md와 pm-lab/communication-plan.md를 채웠다. 소통 계획에 사건 소통 조건이 있다.
• 지표 판정과 PM 판단이 다른 상태 보고 한 줄을 이유와 거둘 조건까지 써 보았다.
• 결정 요청 양식을 저장소에 넣고, 결정 요청 이슈 하나를 만들었다.
• decision-queue.sh로 결정 대기 목록을 만들고 기한이 지난 요청을 찾았다.
• D-04 협상에서 양쪽의 이익과 BATNA를 적고, 입장과 다른 선택지를 하나 이상 만들었다.

마치며...

Launchpad의 이해관계자 일곱을 격자, 현저성, 참여 수준으로 분석했고, 소통 계획에 정기 소통과 사건 소통을 나눠 적었다. 상태 보고에는 기준에 따른 판정(공수 적색)과 PM 판단(황색, CPI 0.89)을 이유와 함께 나란히 적었다. 결정 요청을 여섯 부분의 이슈로 만들고, 10월 28일의 결정 대기 목록에서 기한이 3작업일 지난 D-01과 기한이 없는 D-06을 찾았다. D4에서는 한 프로젝트를 넘어, 여러 후보가 같은 사람을 두고 경쟁할 때 무엇을 먼저 할지와 출시 뒤의 효익을 누가 책임지는지 다룬다.