리스크 관리

읽는 법

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

상위 리스크

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

기획서 12장은 3주 기준입니다. 우리 데드라인은 14일. 일주일이 빕니다.

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

R3 · 이은상(Flutter) 역할이 비었다 — 심각도 높음 / 확률 확정

기획서에 모바일 앱이 없습니다. 텍스트 웹으로 공개 투표에 나갑니다. Flutter 담당 40건이 통째로 대상을 잃었습니다.

• 트리거 — 이미 발생. D-13(9/03) 안에 재배치하지 않으면 하루를 잃음
• 대응 — 웹 화면 5장을 둘로 나눈다. 김충식 = 아침 화면 · 대화창 · 권고 배너 (게임 본류), 이은상 = 루프 노트 · 인스펙터 + 전이 도메인 화면. 인스펙터는 1차 사용자의 핵심 기능이고 노트는 대표 캡처 후보라, 비중이 가볍지 않다
• 대안 — Flutter 경험을 살려 모바일 웹 최적화를 전담 (공개 투표 유입의 상당수가 모바일)
• 담당 — 류준 · 이은상

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

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

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

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

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

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

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

R6 · 공개 투표에서 LLM 비용이 터진다 — 심각도 높음 / 확률 중간

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

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

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

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

• 트리거 — D-5(9/11)까지 엔딩 4종 텍스트 초안 미완
• 대응 — 코드 담당자가 쓰지 않는다. 텍스트 작업을 별도 카드로 분리하고 시간을 따로 확보. 팀 3인 이상이 읽고 확인
• 담당 — 류준 (기획서 작성자가 문체를 가장 잘 안다)

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

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

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

R9 · 인원 이탈 — 심각도 높음 / 확률 낮음

이탈 시	1차 백업
장민석 (코어·도메인)	신채연
신채연 (에이전트)	장민석
김충식 (웹 본류)	이은상
이은상 (노트·인스펙터)	김충식
류준 (PM·인프라·텍스트)	장민석

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

9/05~9/06, 9/12~9/13 두 번의 주말이 모두 작업일입니다.

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

제출 직전 리스크 (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개로 자른다
• 담당 — 미정

리스크 리뷰 주기

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

결정 로그

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