위험 관리 방안

번호에 대해 리스크 번호는 기획 당시 문서의 것을 그대로 씁니다. R3·R9는 결번입니다.

읽는 법

각 리스크에 트리거(이런 신호가 보이면)와 대응(그때 이렇게 한다)이 붙어 있습니다. 트리거를 미리 정해두면 “좀 더 지켜보자”로 시간을 흘려보내지 않게 됩니다.

R1 해소 — 기획서 v6 반영 완료 (2026-09-03) 기존 1순위 리스크였던 “기획서 미반영 상태로 개발 진행”은 해소됐습니다. 기획 문서 10편이 원문 기준으로 전면 재작성됐습니다. 다만 그 과정에서 제품 정의부터 틀렸던 것이 확인됐고, 그 여파가 R2에 남아 있습니다.

상위 리스크

R2 · 3주 설계를 14일에 넣는다 — 심각도 높음 / 확률 높음

기획서 12장은 3주 기준입니다. v1 공개까지 잡은 집중 개발 기간은 14일. 일주일이 빕니다.

• 트리거 — Day 7(9/09) 알파에서 1루프 완주 실패, 또는 방어선 5개 중 2개 이상 미착수
• 영향 — 방어선을 못 채우면 기획서 기준으로 v1 자체가 성립하지 않음
• 대응 — ① 컷 순서대로 ⑨→⑧→⑦→⑥→손상1층 순으로 기계적으로 제거 ② 하루 비트를 5개로 고정 ③ 그래도 안 되면 엔딩 4종 중 2종만(반복·인계) 구현하고 나머지는 텍스트로 축약

R4 · LLM 판정이 게임으로 성립하지 않는다 — 심각도 높음 / 확률 중간

기획서 2.5가 지목한 바로 그 벽입니다 — “대화는 자연스러워지는데 게임이 되지 않는다.”

• 트리거 — Day 6(9/08) 시점에 의심도가 발화 내용과 무관하게 움직임, 또는 같은 발화 반복 투입 시 판정이 흔들림
• 대응 — ① 계산은 코드, 판단은 LLM 분리를 다시 확인 (8.5). 수치가 LLM에서 나오면 즉시 코드로 회수 ② 판정 일관성 실험(11.1 첫 행)을 앞당겨 실행 ③ 의심 판정 프롬프트를 좁힌다 — 자유 판단이 아니라 몇 개 범주 중 선택

R5 · 전이 시연 착수가 늦어진다 — 심각도 높음 / 확률 중간

방어선 ⑤인데 순위상 5번이라 뒤로 밀리기 쉽습니다.

기획서 10.3: 늦추면 짧은 작업이 안 끝나는 게 아니라 아예 시작을 못 한다.

• 트리거 — Day 8(9/10)까지 어댑터 인터페이스 미착수
• 영향 — 3주차에 발견하면 못 고침. 14일이면 더 그렇다. 도메인 개념이 코어로 새어 들어갔는지를 확인할 기회 자체가 사라진다
• 대응 — 코어가 돌기 시작하면 즉시 첫 어댑터를 시도. 완성이 아니라 막히는지만 확인하는 30분짜리 작업으로 먼저 친다

R6 · 공개 오픈 트래픽에서 LLM 비용이 터진다 — 심각도 높음 / 확률 중간

로그인이 없으므로 봇·크롤러·반복 접속에 그대로 노출됩니다.

현행 대응 — 2026-09-16~17 외부 API(Core Sonnet 5 · NPC Haiku 4.5)로 확정되면서 판당 $0.68~0.97의 변동비가 생겼습니다. 대신 익명 진입을 없애고 구글 로그인 + 사용자당 판 수 제한 + 전역 하루 정원 + 입력 길이 상한을 코드로 걸었고, 계정에는 Anthropic 콘솔 지출 한도를 겁니다 (인프라 — LLM 비용). 남은 트리거는 콘솔 지출이 한도의 80%에 닿는 것입니다.

• 트리거 — 일일 사용량이 상한의 80% 도달, 또는 세션당 평균 루프 수가 비정상적으로 높음
• 대응 — ① 세션/IP당 루프 제한 ② 캐싱 ③ 컨텍스트 축소 ④ Agent 역할만 저가 모델로 하향 ⑤ 최후에는 대기열

R7 · 텍스트 품질이 못 따라간다 — 심각도 중간 / 확률 높음

코드가 다 돌아도 대사와 엔딩이 약하면 이 제품은 값이 떨어집니다. 기획서가 “가장 공들여야 할 지점”으로 지목한 유일한 항목입니다.

• 트리거 — Day 9(9/11)까지 엔딩 4종 텍스트 초안 미완
• 대응 — 코드 작업 틈에 쓰지 않는다. 텍스트 작업을 별도 카드로 분리하고 시간을 따로 확보한다. 쓴 뒤 하루를 묵혔다가 다시 읽고 확인한다

R8 · 발화 예산 숫자 미확정 — 심각도 중간 / 확률 확정

기획서 안에서 갈립니다 — 0장·4.3·5.1은 6회, 12.1은 5회(하한 3).

• 트리거 — 이미 발생. 도메인 규칙은 테스트가 먼저 박히는 지점(9.3)이라 구현 착수를 막고 있음
• 대응 — Day 1 안에 하나로 확정. 튜닝 여지를 남기려면 설정값으로 빼고 기본값만 정한다

R10 · 주말 번아웃 — 심각도 중간 / 확률 높음

9/05~9/06, 9/12~9/13 두 번의 주말이 모두 작업일입니다. 혼자 만드는 프로젝트라 쉬는 날을 대신 메워 줄 사람이 없습니다.

• 트리거 — 매일 저녁 점검에서 이틀 연속 계획 대비 절반 미만 소화
• 대응 — 의지 문제로 다루지 않는다. 범위를 줄인다. 야근으로 메우면 어디가 늦는지 안 보이게 된다

v1 공개 직후 리스크 (2026-09-17 추가)

외부 API 전환 뒤 평가 부록 A.19 「판정과 결정」에서 나온 품질 항목입니다. 운영 보안·외부 키 한도 관련 항목은 공개 문서에 적지 않고 개발 저장소의 운영 문서에서 관리합니다.

R11 · 신의 질문(advisor) 응답이 5~7초로 흔들린다 — 심각도 중간 / 확률 높음

Sonnet 5의 advisor p95가 표본마다 4.6초~7.4초로 갈려, 지연 게이트(p95 ≤ 5초) 통과·미달이 뒤집혔습니다.

• 트리거 — 운영 중 advisor p95가 5초를 계속 넘음
• 대응 — (제안) ① 표본이 작아(n=1·n=3) 흔들린 수치이므로 운영 로그의 advisor 지연으로 다시 본다 ② 대기 표시를 UI에서 분명히 한다

R12 · planner beats 상한이 강제되지 않는다 — 심각도 중간 / 확률 중간

Anthropic 구조화 출력에서 스키마의 maxItems가 설명 문구로 강등돼, planner가 beats를 7개(상한 6) 내는 경우가 있습니다. 공개 운영 조합 self-play에서 5회 중 1회 재생성으로 복구됐고, Core만 Sonnet으로 바꾼 판(NPC는 로컬)에서는 재생성 2회 + 폴백 1회까지 갔습니다.

• 트리거 — 운영 로그에서 planner 폴백 발생
• 대응 — (검토 중) 프롬프트에 상한을 명시하거나 응답 후 6개로 자른다

리스크 리뷰 주기

시점	하는 일
매일 저녁	새 리스크 확인, 트리거 도달 여부 점검
Day 7 (9/09)	전체 재평가
Day 12 (9/14)	오픈 리스크만 남기고 정리

결정 로그

날짜	결정	이유
2026-09-03	R1 해소 처리	기획서 v6 원문으로 기획 10편 전면 재작성 완료
2026-09-03	R5 전이 착수를 “30분 탐색”으로 먼저 친다	완성이 아니라 막히는지 확인이 목적
2026-09-03	텍스트 작업을 코드와 분리된 카드로	붙여두면 항상 코드에 밀린다
2026-09-17	R6에 현행 대응 기록 — 로그인·판 수 제한·전역 정원·콘솔 지출 한도	외부 API 확정으로 판당 비용 발생
2026-09-17	R11·R12 등록 — advisor 지연, planner 상한	A.19 판정의 운영 관찰 항목. 운영 보안 항목은 비공개로 관리