프리모템 분석으로 위험 대장 만들기, 근거 줄까지 대조
「프로젝트가 실패했다」 고 가정하고 원인을 거꾸로 찾게 한 뒤, 위험마다 계획서 줄 번호와 문구를 달게 해서 스크립트로 대조합니다. 담당·가능성이 실행마다 흔들리는 칸도 가려냅니다.
계획서에 「보안성 검토는 신청 후 보통 6주」 와 「1~2월 이관」 이 같이 적혀 있어도, 착수 회의에서는 둘을 나란히 놓고 보는 사람이 잘 없습니다. 실패를 가정하고 원인을 거꾸로 찾는 사전 부검(pre-mortem)을 AI 에 맡기고, 나온 위험이 정말 계획서에서 나왔는지 대조합니다.
[1] 계획서 줄마다 P1, P2 처럼 번호를 붙입니다. 이 번호가 대조의 열쇠입니다. 예시는 가상 사내 교육 플랫폼 교체 계획(11줄)입니다.
P2 1단계(2026년 11월~12월): 업체 선정과 계약. 인사팀 교육파트가 주관한다.P3 2단계(2027년 1월~2월): 지난 5년치 수강 이력과 강의 영상 420개를 옮긴다. 이관은 IT 운영팀이 맡는다.P4 3단계(2027년 3월): 신입 120명으로 첫 운영을 하고, 4월부터 전 직원 1,800명으로 넓힌다.…P7 제약 1: 정보보안팀의 클라우드 보안성 검토는 신청 후 보통 6주가 걸린다.P9 제약 3: IT 운영팀은 1월에 회계 시스템 연말 결산 지원이 겹쳐 투입 인력이 절반으로 준다.…[2] 역할은 시스템 프롬프트에 한 문장, 나머지는 메시지에 둡니다. <context> 에 시키는 이유를 적은 것은 Anthropic 프롬프트 작성 안내대로, 이유를 알면 목표에 맞는 답이 나오기 때문입니다. 「일반적인 위험 목록은 이미 있다」 는 문장이 교과서식 나열을 막습니다.
(시스템) 당신은 사내 IT 프로젝트의 위험 관리 담당자입니다. 낙관적인 전망을 보태는 것이 아니라 계획서의 빈틈을 찾는 것이 일입니다. <context>이 결과는 착수 회의 전에 프로젝트 리더가 위험 대장 초안으로 씁니다. 팀 회의에서는 다들 잘될 거라는 말만 해서, 계획서에 실제로 적힌 일정·인력·제약에서 나오는 위험을 먼저 보려는 것입니다. 일반적인 프로젝트 위험 목록은 이미 있으니 되풀이할 필요가 없습니다.</context> <instructions>지금은 {실패를 확인하는 시점}이고, 이 프로젝트는 실패했습니다. <plan> 만 근거로 실패 원인을 거꾸로 찾아 위험 대장으로 적으세요.- 마크다운 표 하나. 열: ID | 실패 원인 | 근거 | 조기 경보 신호 | 담당 | 가능성- 근거: 계획서 줄 번호와 그 줄의 문구를 글자 그대로. 예) P7 「신청 후 보통 6주가 걸린다」- 조기 경보 신호: 언제, 무엇을 보면 이 원인이 진행 중인지 알 수 있는지.- 담당: 계획서에 나온 부서 이름만. 정할 수 없으면 「미정」.- 가능성: 상·중·하 가운데 하나와 그렇게 본 계획서 근거 한 구절. 근거가 없으면 「판단 불가」.- 근거 문구가 계획서에 없는 위험은 표에 넣지 말고, 표 아래 「계획서 밖 위험」 에 한 줄씩(최대 3개).- 같은 원인을 두 행으로 나누지 않습니다. 표와 「계획서 밖 위험」 말고는 쓰지 않습니다.</instructions> <plan>{번호 붙인 계획서}</plan>[3] 두 번 돌립니다. 대화창이라면 시스템 문장을 메시지 맨 위에 붙입니다.
$ claude -p --model claude-sonnet-5-5 --max-turns 1 --tools "" --setting-sources "" --strict-mcp-config --system-prompt "$(cat role.ko.txt)" < prompt.ko.txt > out.ko.1.txt첫 실행은 위험 8개, 두 번째는 6개였습니다. 첫 실행의 한 행입니다.
| R3 | 외부 강사 저작물 약 126개(420×30%)의 게시 동의를 제때 받지 못했다. 동의 받는 담당과 일정이 계획서에 없어 미동의 영상이 개시 때 빠졌다. | P8 「강의 영상 가운데 약 30%는 외부 강사 저작물이라 새 플랫폼 게시 동의를 다시 받아야 한다」 | 12월 말까지 동의 대상 목록과 강사 연락처가 확정되지 않았다. 2월 초 동의서 회신율이 절반 미만이다. 동의 담당자 지정 공문이 없다. | 미정 | 중 — P8 「약 30%」(약 126개)가 외부 회신에 달려 있는데, 계획서 어디에도 담당과 기한이 없다. |보안성 검토 6주(P7)와 1단계 일정(P2), 1월 인력 절반(P9)과 이관(P3)의 충돌은 두 번 다 잡았습니다. 기존 LMS 병행 운영 여부처럼 계획서에 아예 없는 것은 「계획서 밖 위험」 으로 따로 나왔습니다.
[4] 스크립트로 대조합니다. 근거 문구가 그 줄에 글자 그대로 있는지, 담당이 계획서의 부서인지, 여러 위험이 같은 줄에 기대는지(SHARED)를 봅니다.
#!/usr/bin/env python3"""usage: check_risks.py plan.txt out.txt "owner1,owner2,..." """import re, sys, collectionsplan = {l.split(" ", 1)[0]: l.split(" ", 1)[1] for l in open(sys.argv[1], encoding="utf-8") if l.strip()}owners = {o.casefold() for o in sys.argv[3].split(",")} | {"미정", "tbd"}rows = [[c.strip() for c in l.strip().strip("|").split("|")] for l in open(sys.argv[2], encoding="utf-8") if l.startswith("|")][2:]bad, used = 0, collections.defaultdict(list)for r in rows: rid, cite, signal, owner = r[0], r[2], r[3], r[4] for pid, quote in re.findall(r"(P\d+)\s*[「\"“]([^」\"”]+)[」\"”]", cite): used[pid].append(rid) if quote not in plan.get(pid, ""): bad += 1; print(f"QUOTE {rid}: {pid} 「{quote}」 not in plan line") if owner.casefold() not in owners: bad += 1; print(f"OWNER {rid}: {owner}")for pid, ids in sorted(used.items(), key=lambda x: int(x[0][1:])): if len(set(ids)) > 1: print(f"SHARED {pid}: {' '.join(sorted(set(ids)))}")print(f"{len(rows)} risks, {bad} problems")sys.exit(1 if bad else 0)$ O="인사팀 교육파트,IT 운영팀,정보보안팀,각 본부 교육 담당자"$ python3 -I check_risks.py plan.ko.txt out.ko.2.txt "$O"; echo "exit $?"QUOTE R6: P4 「3월: 신입 120명으로 첫 운영을 하고, 4월부터 전 직원 1,800명으로 넓힌다」 not in plan lineSHARED P2: R1 R5SHARED P3: R1 R2 R4SHARED P4: R5 R66 risks, 1 problemsexit 1두 번째 결과의 R6 은 계획서에 없는 「3월:」 을 문구 앞에 붙였습니다. 뜻은 같아 눈으로는 놓치는 종류입니다. 첫 결과는 0 problems 였습니다. SHARED 는 오류가 아니라 같은 원인을 둘로 나누지 않았는지 볼 자리입니다.
[5] 두 결과를 나란히 놓고 흔들린 칸을 사람이 찾습니다. 보안성 검토 지연의 담당은 1회 정보보안팀, 2회 인사팀 교육파트였습니다. 외부 강사 동의의 가능성은 「중」 과 「판단 불가」 로 갈렸고, SSO 연동은 1회엔 별도 행, 2회엔 이관 인력 부족 행에 합쳐졌습니다. 담당이 갈린 행은 계획서가 책임을 정하지 않았다는 뜻이므로 회의에서 정합니다. 「판단 불가」 칸에 숫자 점수를 억지로 채우지 않습니다.