월요일 오전, 같은 입력을 받은 두 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는 후보·초안까지만.
- 민감정보는 입력 단계에서 마스킹·선별 — 출력이 깔끔해도 입력이 새면 사고다.
자동화의 목적은 사람을 빼는 게 아니라, 사람이 '검증'이라는 가장 중요한 일에 집중하도록 단순 작업을 덜어주는 것입니다.
심화 — 파이프라인이 팀의 것이 될 때
심화: 검증 역량의 침식과 확정의 서명
혼자 쓰는 파이프라인과 팀이 쓰는 파이프라인은 다른 물건입니다. 파이프라인이 팀 표준이 되는 순간, 개인의 습관으로 버티던 것들이 구조적 문제로 돌아옵니다.
- 검증 역량의 침식(deskilling): 확정 게이트의 역설은, 검증을 잘하려면 그 산출물을 스스로 만들 줄 알아야 한다는 것입니다. WBS 공수 추정이 타당한지는 공수를 잡아 본 사람만 알아봅니다. 그런데 초안을 늘 AI가 만들면, 주니어는 만들어 보는 경험 자체를 잃습니다 — 몇 년 뒤 그 주니어가 확정 도장을 찍는 자리에 앉으면, 게이트는 형식만 남습니다. 그래서 성숙한 팀은 훈련을 절차에 박습니다: 주니어는 주기적으로 AI 없이 산출물을 처음부터 작성해 보고, 시니어의 확정 과정(무엇을 왜 고쳤는지)을 수정 이력으로 공유받습니다.
- 판단형 값에는 근거 산정식을: 사실·담당·기한 게이트는 원본과 대조하면 걸러지지만, 공수·일정·리스크 평가 같은 판단형 값은 대조할 원본이 없습니다. 이런 값은 "맞는지" 대신 "어떻게 나왔는지"를 검증합니다 — AI 초안에 산정 근거(작업 분해 기준·유사 프로젝트 비교)를 함께 요구하고, 근거 없는 숫자는 그럴듯해도 [확인]으로 되돌립니다.
- 확정의 서명: 팀 파이프라인에서는 "누가 이 초안을 확정했는가"가 남아야 합니다. 확정자 실명이 붙지 않은 산출물은 초안으로 취급하는 규칙이 있어야 책임이 파이프라인 뒤로 숨지 않습니다. 확정자가 AI 초안을 얼마나 고쳤는지(수정률)를 가끔 들여다보면 게이트의 건강도 보입니다 — 수정률이 0%에 수렴한다면 검증이 통과 의례가 됐다는 신호입니다.
- 템플릿은 개인 노트가 아니라 팀 자산으로: 프롬프트 템플릿이 개인 메모장에 살면, 그 사람의 부재가 곧 파이프라인의 부재입니다. 템플릿에 버전·소유자·개정 이력을 붙여 팀 저장소에 두고, 고치면 이유를 남깁니다 — 프롬프트도 산출물 양식과 같은 문서 관리 대상입니다.
파이프라인 도입 첫 달의 성패는 프롬프트 품질이 가르지만, 1년 뒤의 성패는 이 네 가지 — 훈련·근거·서명·자산화 — 가 가릅니다.
상황: 파이프라인 도입 1년 차. 신규 유지보수 제안 건에서 AI가 요구 목록으로부터 WBS 초안과 공수 추정을 만들었고, 담당 주니어 PM이 게이트 체크리스트(사실·담당·기한·민감정보)를 확인해 확정했습니다. 그 일정이 제안서에 실려 계약됐는데, 착수해 보니 연동 테스트 구간의 공수가 실제의 절반도 안 되게 잡혀 있었습니다. 첫 달부터 일정이 밀렸고, 고객과의 관계는 지연 사과로 시작됐습니다.
원인: 게이트는 살아 있었지만 거를 수 있는 것만 걸렀습니다 — 사실·담당·기한은 원본 대조가 가능하지만, 공수 추정의 타당성은 대조할 원본이 없는 판단형 값이라 도메인 감각으로만 검증됩니다. 확정자인 주니어는 입사 후 줄곧 AI 초안 검토만 해 왔고 공수를 바닥부터 잡아 본 적이 없어, 그럴듯하게 분해된 표를 보고도 타당성을 판단할 근거가 없었습니다. 확정 이력을 보니 최근 반년 동안 AI 추정치가 수정된 건이 거의 없었습니다 — 게이트가 조용히 통과 의례가 되어 있었던 것입니다.
진단: 사고 건의 WBS를 시니어가 재산정하며 어긋난 지점을 특정했습니다 — AI 초안에는 연동 대상 시스템의 테스트 환경 확보, 데이터 정합성 검증처럼 문서에는 안 적혀 있지만 현장에서는 항상 발생하는 작업이 통째로 빠져 있었습니다. 요구 목록에 없는 것은 AI 초안에도 없었고, 그것이 빠졌음을 알아볼 눈이 게이트에 없었습니다.
해결: 판단형 값의 게이트를 바꿨습니다 — 공수·일정 초안에는 산정 근거(작업 분해 기준, 과거 유사 건 대비)를 반드시 첨부시키고, 그 근거를 검증할 수 있는 등급의 확정자만 서명하게 했습니다. 주니어 육성에는 분기마다 AI 없이 WBS를 처음부터 작성해 시니어 산정과 비교하는 훈련을 넣었고, AI 초안 수정률을 팀 지표로 두어 0%에 붙으면 게이트 운영을 점검합니다. 자동화가 빼앗아 간 것은 시간이 아니라 연습 기회였다는 것 — 그것을 절차로 되돌려 놓는 것이 해결이었습니다.
이 캡스톤이 향하는 자리는 "AI를 잘 쓰는 PM·운영 담당"입니다 — 발주사·원청의 IT 운영(SM) 담당, 서비스데스크 리드, SI 사업관리(PM/PMO). 이들은 직접 서버를 만지기보다, 고객 메일·회의·장애라는 정리되지 않은 입력을 받아 회의록·액션아이템·WBS·리스크·RCA·고객 회신이라는 책임 있는 산출물로 바꿉니다.
현장에서 AI는 이미 이 자리에 들어와 있습니다. 다만 잘 쓰는 사람과 못 쓰는 사람의 차이는 'AI를 쓰느냐'가 아니라, 흩어진 일을 하나의 워크플로로 묶고, 단계마다 사실·담당·기한·민감정보를 검증해 확정하는 절차를 가졌느냐입니다. 면접과 실무에서 "AI로 업무를 어떻게 자동화하느냐"를 물으면, 답은 도구 이름이 아니라 "AI는 초안, 사람은 확정"이라는 원칙과 그것을 보장하는 체크리스트입니다. 잘못된 AI 초안을 그대로 고객에 보고한 책임은 언제나 사람에게 남는다는 것을, 관리자는 알고 있어야 합니다.
여기까지가 이 트랙의 마지막 캡스톤입니다. ITSM 운영부터 프로젝트 관리, SI/SM 현업, 문서·산출물, 협업 도구, AI 활용까지 — 들어온 일을 분류하고, 우선순위와 SLA로 약속하고, 변경을 통제하고, 산출물로 증명하고, AI로 속도를 더하는 '책임 있는 운영·관리자'의 사고를 한 바퀴 돌았습니다.
관련 모듈로 더 깊이:
- AI를 PM·운영 보조로 — 'AI는 초안, 사람은 확정' 원칙이 출발한 AI PM 개요
- AI로 장애 대응 보조 — 장애 로그에서 RCA 초안을 만들고 검증하는 흐름
- AI로 RFP·RFI 분석 — RFP 추출·분류를 AI로 가속하고 사람이 대조하는 법
이 트랙은 여기서 끝납니다. 지금까지 직접 만든 산출물 — 장애보고서·RCA·WBS·SLA 리포트·RFP 분석·AI 자동화 기록 — 이 그대로 당신의 포트폴리오이자 면접의 근거가 됩니다. 자격증과 취업 준비는 이 트랙과 별도로 다뤄집니다.