월요일 오전, 같은 입력을 받은 두 PM.
받은 것은 셋입니다 — 고객이 보낸 장문의 불만 메일, 금요일 정기회의 녹취 텍스트, 그리고 주말 새벽 결제 지연 장애의 로그 묶음. A는 이 셋을 붙들고 하루를 씁니다. 메일을 읽어 요구를 추리고, 회의 녹취를 손으로 정리하고, 로그를 뒤져 장애 보고서를 쓰고, WBS를 엑셀로 다시 그리고, 저녁에야 고객 회신을 씁니다. 빠뜨린 액션아이템 하나가 다음 주에 사고로 돌아옵니다.
B는 같은 셋을 정해진 워크플로에 흘려보냅니다. 회의 녹취는 회의록 초안으로, 회의록은 액션아이템 표로, 요구는 WBS 초안으로, 로그는 RCA 초안으로, 그리고 이 모두를 묶어 고객 회신 초안까지 — 각 단계를 AI가 초안으로 빠르게 펼칩니다. 단, B는 어느 것도 그대로 내보내지 않습니다. 단계마다 사실·담당·기한·민감정보를 사람 눈으로 확인해 확정합니다. 오후엔 검토만 남습니다.
둘의 차이는 'AI를 쓰느냐'가 아니라, 흩어진 입력을 하나의 통합 워크플로로 묶고, 어디까지 AI에 맡기고 어디서 사람이 확정하는가를 설계했느냐입니다. 이 캡스톤은 B의 그림 — 지금까지 배운 AI 활용을 하나의 PM 자동화 파이프라인으로 종합하는 일 — 을 다룹니다.
- 1고객 메일·회의록·장애 로그라는 입력을 PM 산출물(회의록·액션아이템·WBS·리스크·RCA·고객 회신)로 잇는 통합 워크플로를 그릴 수 있다
- 2각 단계에 맞는 프롬프트 템플릿을 설계하고, AI 출력을 일관된 형식으로 받아낼 수 있다
- 3"AI 초안, 사람 확정" 원칙에 따라 단계마다 사실·담당·기한·민감정보를 검증하는 절차를 적용할 수 있다
- 4프롬프트 템플릿 모음·액션아이템 표·AI 출력 검증 체크리스트를 팀의 표준 산출물로 만들 수 있다
- 5자동화가 빠르게 만들어 주는 만큼, 잘못된 초안이 그대로 굳을 때의 위험과 그 차단점을 설명할 수 있다
흩어진 입력을 하나의 파이프라인으로
입력 셋 → 산출물 일곱, 그 사이를 잇는 워크플로
PM의 하루에 들어오는 것은 대개 정리되지 않은 텍스트입니다 — 고객이 보낸 메일, 회의에서 오간 말, 장애가 남긴 로그. 지금까지 이 트랙에서 회의록 자동화·WBS 초안·RCA 보조·RFP 분석을 각각 배웠다면, 캡스톤의 목표는 그것들을 하나의 흐름으로 잇는 것입니다.
큰 그림은 단순합니다. 입력 셋이 들어오면, 단계를 거쳐 산출물 일곱이 나옵니다.
| 단계 | 입력 | AI가 만드는 초안 | 사람이 확정할 핵심 |
|---|---|---|---|
| 1 요구 분리 | 고객 메일 | 요구사항·불만·질문을 분리한 목록 | 어떤 게 진짜 요구이고 어떤 게 감정 표현인가 |
| 2 회의록 | 회의 녹취 텍스트 | 결정사항·논의·미결 항목 요약 | 실제 결정과 단순 발언의 구분 |
| 3 액션아이템 | 회의록 | 담당·기한이 붙은 할 일 표 | 담당·기한이 실제 합의된 값인가 |
| 4 WBS | 요구 + 액션아이템 | 작업 분해·선후관계 초안 | 빠진 작업·비현실적 일정 없는가 |
| 5 리스크 | WBS + 메일 맥락 | 리스크 목록과 영향·대응 초안 | 실제로 일어날 법한가, 대응이 구체적인가 |
| 6 RCA 초안 | 장애 로그 | 타임라인·원인 후보·재발방지 초안 | 원인이 추측인가 근거가 있는가(확정은 사람) |
| 7 고객 회신 | 위 산출물 종합 | 사과·조치·재발방지·일정 회신 초안 | 약속한 일정·표현이 책임질 수 있는 값인가 |
핵심은 각 단계의 출력이 다음 단계의 입력이 된다는 점입니다. 회의록이 좋아야 액션아이템이 정확하고, 요구 분리가 정확해야 WBS가 헛돌지 않습니다. 그래서 앞 단계에서 사람이 한 번 확정하고 넘기는 것이, 뒤에서 잘못이 누적되는 것을 막습니다.
AI는 초안, 사람은 확정 — 이 원칙이 파이프라인을 지탱한다
자동화는 매력적이지만, 매력의 크기만큼 위험합니다. AI는 그럴듯하게 없는 사실을 지어내고(환각), 회의에 없던 담당자를 적어 넣고, 비어 있어야 할 기한을 임의로 채웁니다. 이 초안이 검증 없이 그대로 고객에게 가면, 잘못의 책임은 AI가 아니라 사람과 조직에 남습니다.
그래서 이 파이프라인의 모든 단계에는 같은 게이트가 붙습니다 — 사실·담당·기한·민감정보.
- 사실: 입력(메일·회의·로그)에 없던 내용을 AI가 지어내지 않았는가.
- 담당: 적힌 담당자가 실제로 그 일을 맡기로 한 사람이 맞는가.
- 기한: 적힌 날짜가 실제 합의된 값인가, AI가 임의로 채운 값은 아닌가.
- 민감정보: 입력에 고객 개인정보·계약 금액·내부 시스템 정보가 섞여 들어가지 않았는가, 출력에 그것이 노출되지 않는가.
이 네 가지를 통과하지 못한 초안은 확정되지 않습니다. AI가 속도를 주고, 사람이 신뢰를 줍니다. 둘 중 하나만으로는 PM 산출물이 되지 못합니다.
그림: 입력 셋이 산출물 일곱으로 흐르되, 사실·담당·기한·민감정보 네 게이트를 사람이 확정하지 못한 초안은 확정되지 않는다.
단계별 프롬프트 — 출력 형식을 미리 정한다
좋은 프롬프트는 '형식'을 고정한다
AI 출력을 검증하기 쉬우려면, 출력이 매번 같은 형식으로 나와야 합니다. 자유 서술로 받으면 사람이 항목을 일일이 찾아야 하지만, 표·목록 형식으로 받으면 빈칸과 오류가 한눈에 보입니다. 그래서 프롬프트에는 **역할·입력·출력 형식·제약(지어내지 말 것)**을 명시합니다.
아래는 각 단계의 프롬프트 템플릿 골격입니다. 대괄호 부분만 그날의 입력으로 바꿔 씁니다.
[1. 고객 메일 → 요구 분리]
역할: 너는 SI 운영 PM의 보조다.
입력: 아래 고객 메일 전문.
할 일: 내용을 (요구사항) / (불만·감정) / (질문) 세 갈래로 분리해 표로 정리하라.
제약: 메일에 없는 내용을 추측해 채우지 마라. 불확실하면 "확인 필요"로 표시하라.
출력: | 구분 | 내용 | 근거가 된 문장 | 표.
---
[고객 메일 전문을 여기에]
[2. 회의 녹취 → 회의록]
역할: 너는 회의록 작성 보조다.
입력: 아래 회의 녹취 텍스트.
할 일: (결정사항) / (주요 논의) / (미결·다음 회의로) 로 나눠 요약하라.
제약: 발언과 '결정'을 구분하라. 결정이 아닌 것을 결정으로 적지 마라.
출력: 세 묶음의 불릿 목록.
---
[녹취 텍스트를 여기에]
[3. 회의록 → 액션아이템 표]
역할: 너는 액션아이템 정리 보조다.
입력: 위에서 확정한 회의록.
할 일: 할 일을 담당·기한·상태가 있는 표로 만들어라.
제약: 담당·기한이 회의록에 없으면 비워 두고 "미정"으로 표시하라. 임의로 채우지 마라.
출력: | 액션 | 담당 | 기한 | 상태 | 비고 | 표.
[4. 요구+액션 → WBS 초안]
역할: 너는 WBS 작성 보조다.
입력: 확정된 요구 목록과 액션아이템.
할 일: 작업을 단계(분석/설계/구현/검수)로 분해하고 선후관계를 표시하라.
제약: 공수(M/M)·기간은 '초안 추정'임을 명시하고, 확정값으로 단정하지 마라.
출력: | WBS ID | 작업 | 선행작업 | 산출물 | 추정(초안) | 표.
[5. WBS+메일 → 리스크 목록]
역할: 너는 리스크 식별 보조다.
입력: WBS 초안과 고객 맥락.
할 일: 일어날 법한 리스크를 (영향)·(발생가능성)·(대응)으로 정리하라.
제약: 막연한 리스크 말고, 이 프로젝트 맥락에서 구체적인 것만.
출력: | 리스크 | 영향 | 가능성 | 대응(초안) | 표.
[6. 장애 로그 → RCA 초안]
역할: 너는 장애 분석 보조다. 원인 '확정'은 사람이 한다.
입력: 아래 장애 로그.
할 일: 시간순 타임라인과 (원인 후보)를 근거 로그와 함께 제시하라.
제약: 단정하지 마라. 각 원인 후보에 '근거 로그'와 '추가 확인 필요'를 붙여라.
출력: 타임라인 + | 원인 후보 | 근거 로그 | 확인 필요 | 표.
---
[로그를 여기에]
[7. 종합 → 고객 회신 초안]
역할: 너는 고객 회신 초안 작성 보조다.
입력: 확정된 회의록·액션·RCA·일정.
할 일: (현황 사과)·(원인 요약)·(조치)·(재발방지)·(일정) 순서로 정중한 회신 초안을 써라.
제약: 확정되지 않은 일정·원인을 약속처럼 쓰지 마라. 사람이 채울 곳은 [확인]으로 남겨라.
출력: 메일 본문 초안.
이 템플릿의 공통점은 **"없으면 지어내지 말고 비워 두라"**는 제약입니다. AI가 빈칸을 임의로 채우지 못하게 막아야, 사람이 빈칸을 보고 채울 수 있습니다.
같은 파이프라인 안에서도 AI에 맡기는 정도는 단계마다 다릅니다. 회의 요약은 AI에 적극 맡기되 담당·기한처럼 책임지는 값은 사람이 채우고, RCA의 근본 원인 '확정'과 고객 회신의 약속은 사람이 전면 검토합니다. 그리고 어느 단계든 초안은 사실·담당·기한·민감정보 네 게이트를 사람이 통과시켜야 확정됩니다 — AI는 없는 사실을 지어내고(환각) 없던 담당자를 적어 넣기 때문입니다. 잘못된 초안이 검증 없이 고객에게 가면 책임은 AI가 아니라 사람과 조직에 남습니다. AI가 속도를, 사람이 신뢰를 주는 분담이 무너지면 그 산출물은 PM 산출물이 되지 못합니다.
직접 해보기 — 입력 셋을 산출물로 묶기
아래 가상의 입력 셋을 받았다고 하고, 위 프롬프트 템플릿을 순서대로 적용해 산출물을 만들어 보세요. 각 단계 출력은 다음 단계로 넘기기 전에 사실·담당·기한·민감정보를 점검합니다. 점검 결과의 예시는 ObserveBlock에 있습니다.
[고객 메일]
"주말에 결제가 자꾸 지연돼 고객 항의가 빗발쳤습니다. 원인과 재발방지책,
그리고 다음 분기 결제 개선 일정을 이번 주 안에 회신 부탁드립니다.
참고로 결제 실패한 고객 명단(이름·연락처)을 첨부합니다." (개인정보 첨부)
[회의 녹취 일부]
"...그래서 결제 타임아웃을 늘리자는 의견이 있었고, 김PL이 다음 주까지
모니터링 강화안을 보겠다고 했고요. 일정은 아직 확정 못 했습니다..."
[장애 로그 일부]
03:12 payment-api timeout to gateway (5s)
03:12 retry x3 failed
03:15 queue backlog 4,200
03:40 manual restart, recovered
먼저 (1)고객 메일에서 무엇을 AI에 넣으면 안 되는지 가리고, (2)각 단계 프롬프트를 적용한 뒤, (3)나온 초안에서 AI가 임의로 채운 값이 있는지 찾아보세요.
단계: 요구분리 → 회의록 → 액션아이템 → WBS → 리스크 → RCA → 고객회신- 민감정보: 고객 메일의 "결제 실패 고객 명단(이름·연락처)"은 그대로 AI에 넣으면 안 된다 — 마스킹하거나 제외하고, 분석에 불필요한 개인정보는 입력 단계에서 가린다
- 요구 분리: 진짜 요구는 (원인)·(재발방지책)·(다음 분기 일정 회신)이고, "항의가 빗발쳤다"는 감정·맥락이다 — AI가 이 둘을 섞어 요구로 부풀리지 않았는지 확인
- 액션아이템: 회의록에 "김PL이 모니터링 강화안" "다음 주까지"는 있으나 결제 타임아웃 변경의 담당·기한은 없음 → AI가 빈 담당·기한을 임의로 채웠다면 "미정"으로 되돌린다
- RCA: 로그는 timeout·retry 실패·큐 적체·수동 재시작까지만 보여준다 — AI가 "근본 원인은 게이트웨이 장애"라고 단정했다면 이는 추측, "원인 후보 + 추가 확인 필요"로 표시해 사람이 확정
- 고객 회신: "다음 분기 개선 일정"은 아직 확정되지 않았으므로 회신 초안에 구체 날짜를 약속처럼 쓰면 안 됨 → [확인] 자리로 남기고 사람이 확정 후 채운다
- 핵심 감각: AI가 일곱 산출물을 몇 분 만에 펼쳐도, 확정 도장은 사람이 찍는다 — 빠른 초안일수록 빈칸·추측·민감정보를 더 꼼꼼히 본다
현장에서 자주 보는 함정
증상: AI 파이프라인을 도입한 뒤 산출물이 빠르게 나오자, 검토가 점점 형식적으로 변합니다. 어느 날 AI가 RCA 초안에 "근본 원인은 DB 커넥션 고갈"이라고 단정했고, 그 문장이 그대로 고객 회신과 경영보고에 실립니다. 그런데 실제 원인은 게이트웨이 타임아웃 설정이었고, 잘못된 재발방지책이 한 달을 허비합니다. 또 다른 날엔 액션아이템 표의 담당·기한이 AI가 임의로 채운 값이었는데, 그 담당자는 그 일을 맡은 적이 없었습니다.
원인: 속도에 익숙해지면서 "AI 초안 → 사람 확정"의 확정 단계가 비어버렸습니다. AI는 모르면 비워 두는 게 아니라 그럴듯하게 채우는 경향이 있고(환각), 그 채움이 표 형식에 깔끔하게 들어가면 사람 눈에는 '확정된 사실'처럼 보입니다. 형식의 깔끔함이 검증의 부재를 가립니다.
해결 방향(이 캡스톤이 묶은 것):
- 프롬프트에 **"없으면 지어내지 말고 비워 두라"**를 항상 넣어, 빈칸이 빈칸으로 보이게 한다.
- 단계마다 AI 출력 검증 체크리스트(사실·담당·기한·민감정보)를 통과해야 다음 단계로 넘긴다 — 통과 못 한 초안은 확정 금지.
- RCA의 원인 '확정'과 고객에게 하는 '약속'은 반드시 사람이 한다. AI는 후보·초안까지만.
- 민감정보는 입력 단계에서 마스킹·선별 — 출력이 깔끔해도 입력이 새면 사고다.
자동화의 목적은 사람을 빼는 게 아니라, 사람이 '검증'이라는 가장 중요한 일에 집중하도록 단순 작업을 덜어주는 것입니다.
이 캡스톤이 향하는 자리는 "AI를 잘 쓰는 PM·운영 담당"입니다 — 발주사·원청의 IT 운영(SM) 담당, 서비스데스크 리드, SI 사업관리(PM/PMO). 이들은 직접 서버를 만지기보다, 고객 메일·회의·장애라는 정리되지 않은 입력을 받아 회의록·액션아이템·WBS·리스크·RCA·고객 회신이라는 책임 있는 산출물로 바꿉니다.
현장에서 AI는 이미 이 자리에 들어와 있습니다. 다만 잘 쓰는 사람과 못 쓰는 사람의 차이는 'AI를 쓰느냐'가 아니라, 흩어진 일을 하나의 워크플로로 묶고, 단계마다 사실·담당·기한·민감정보를 검증해 확정하는 절차를 가졌느냐입니다. 면접과 실무에서 "AI로 업무를 어떻게 자동화하느냐"를 물으면, 답은 도구 이름이 아니라 "AI는 초안, 사람은 확정"이라는 원칙과 그것을 보장하는 체크리스트입니다. 잘못된 AI 초안을 그대로 고객에 보고한 책임은 언제나 사람에게 남는다는 것을, 관리자는 알고 있어야 합니다.
여기까지가 AI 활용 트랙의 마무리입니다. AI가 만든 산출물을 들고 면접장에 서려면, 이제 그 산출물을 평가할 시장과 직무를 알아야 합니다.
관련 모듈로 더 깊이:
- AI를 PM·운영 보조로 — 'AI는 초안, 사람은 확정' 원칙이 출발한 AI PM 개요
- AI로 장애 대응 보조 — 장애 로그에서 RCA 초안을 만들고 검증하는 흐름
- AI로 RFP·RFI 분석 — RFP 추출·분류를 AI로 가속하고 사람이 대조하는 법
다음 모듈에서는 이 모든 역량이 실제로 팔리는 곳 — 한국 IT 채용 시장과 직무 지형(SI·SM·운영·PMO가 어떤 회사에서 어떤 이름으로 사람을 뽑는지, 무엇을 보고 뽑는지)을 정리하며 자격·취업 단계(Phase 13)로 넘어갑니다.