추리 게임 시나리오, 외주에서 자체 파이프라인으로

문제: 추리 시나리오를 한 편 늘리려면 매번 외부 제작사와 새로 계약해야 했다. 팀에는 전담 작가도, 완성된 원고를 검수할 사람도 없었다.
결정: 용의자 한 명을 이루는 필드와 개수를 스키마로 고정하고, Claude 세션 하나가 설계 역할, 작성 역할, 검수 역할을 차례로 맡는 10단계 저작 파이프라인을 만들었다. 다음 단계로 넘어가도 되는지는 Python 스크립트(게이트)가 판정한다. 게이트는 산출물 존재와 승인 상태를 검사하고, 체크포인트 B와 C에서는 스키마 검증기를 직접 실행한다. 체크포인트 A는 검수 역할의 보고를 사용한다.
결과: 파이프라인으로 만들고 Studio에서 고쳐 올린 작품 7건이 와디즈 펀딩 캠페인으로 공개됐다. 초안 한 편 비용은 AI 호출 비용 수준으로 줄어들었다.

Sleuth는 플레이어가 AI 용의자와 직접 대화하며 단서를 모으고 범인을 지목하는 모바일 추리 게임이다. 시나리오 한 편을 새로 만들려면 매번 외부 제작사와 계약을 새로 맺고 원고를 기다려야 했고, 받은 원고도 우리 플랫폼이 읽는 정해진 스키마의 데이터로 다시 가공해야 했다. 팀은 6명이었고 전담 시나리오 작가가 없었다. 백엔드와 콘텐츠 도구는 내가 주로 맡게 되었다.

오늘 다룰 주제 요약

이 글은 그 병목을 Claude 세션 하나가 설계, 작성, 검수를 차례로 맡는 파이프라인으로 옮긴 과정이다. 에이전트에게 맡길 일과 코드가 판정할 일을 어디서 나눴는지, 그리고 제작자가 개발자 없이 이 결과물을 검증하고 올릴 수 있게 하려고 무엇을 했는지를 적는다.

1. 문제와 조건

콘텐츠 라인업을 채우려고 추리 콘텐츠 전문 제작사와 시나리오 5편과 이미지 에셋 납품 계약을 맺었다. 초기 라인업에는 통하는 방식이었다. 추가 시나리오마다 새 계약이 필요했고, 제작 일정이 발주 주기에 묶였다.

직접 만들 때의 어려움은 사건 하나가 시나리오 한 편으로 끝나지 않는다는 점이다(처음에 콘텐츠 하나를 만드는데 거의 반년이란 시간이 들었다...). 용의자 서너 명의 배경, 관계, 말투와, 대화 중에 조건이 맞으면 용의자가 숨기던 사실을 열어 주는 장치(트리거)와, 이 모두가 맞물리는 단서 구조를 한꺼번에 설계해야 한다. 넘기기 전에 확인할 것은 세 가지였다. 단서가 정말 정답을 증명하는가, 용의자가 앞뒤가 다른 말을 하지 않는가, 플레이어가 풀 수 있는 순서로 단서가 열리는가. 이걸 보려면 쓴 사람과 다른 시선이 필요한데 따로 고용할 여유가 없었다.

그래서 전담 작가와 검수자를 두는 대신, 이미 매일 쓰던 Claude Code 세션을 저작 엔진으로 쓰기로 했다. LLM API 계약과 과금 체계를 새로 만들 필요가 없는 대신, 실행 단위가 API 호출 하나가 아니라 세션 하나가 여러 역할을 차례로 맡는 것이 된다.

2. 검토한 선택지

처음 해 본 건 단순히 프롬프트에 "체크포인트를 반드시 지켜라"라고 적는 것이었다. (하지만 사흘 만에 에이전트 루프가 이 규칙을 건너뛰었다. 그 사건과 뒤에 만든 게이트는 다음 글에서 다룬다.)

안	버린 이유
프롬프트 지시를 더 강하게 쓴다	지시를 지킬지 정하는 쪽이 같은 세션의 같은 모델이다. 이미 한 번 무너졌다
역할 구분 없이 한 세션이 쓰고 채점까지 한다	방금 쓴 맥락 그대로 자기 결과물을 채점하게 된다
역할마다 별도 프로세스와 API 키로 격리한다	격리는 런타임이 보장하지만 세션, 과금, 재시도를 조율하는 비용이 혼자 만들고 운영하는 파이프라인에는 맞지 않았다

별도 에이전트 프로세스 대신 한 세션이 시스템 프롬프트를 바꿔 가며 역할을 차례로 맡고, 게이트가 단계 진행과 산출물 존재를 검사하는 구성을 택했다. 격리를 런타임에 맡기지 못하는 대신 넘어가는 지점마다 코드가 확인하게 했다.

3. 구조: 세 역할, 세 체크포인트, 에이전트 규약

작업은 10단계(STEP 0~9)다. 설계 역할(STEP 0~1)은 사건의 진실과 단서 구조를 확정한다. 작성 역할(STEP 2~5)은 잠긴 설계만 보고 용의자, 프롤로그, 엔딩, 트리거를 써서 게이트가 읽는 시나리오 파일로 조립한다. 검수 역할(STEP 6~9)은 스키마 검증, 이미지 슬롯 목록, QA 질문을 만들고 새로 창작하지 않는다. 체크포인트 A, B, C는 각각 STEP 1, 5, 9 뒤에서 "여기까지 확인했으니 넘어가도 좋다"는 승인을 받는 지점이다. 파이프라인은 C에서 끝나고, 이미지 생성과 업로드는 Studio가 맡는다.

파이프라인

역할을 셋으로 나눈 것은 앞에서 말한 세 가지 검수 항목에 하나씩 대응시킨 결과다. 단서가 정답을 증명하게 하려고 설계 역할이 진실과 단서 구조를 먼저 잠그고(체크포인트 A), 용의자가 앞뒤가 다른 말을 하지 않게 하려고 작성 역할은 잠긴 설계만 보고 쓰고(B), 단서가 풀 수 있는 순서로 열리는지는 검수 역할이 열리는 순서를 시뮬레이션해 확인한다(C).

이 절차를 세션마다 같게 만든 것이 Agent 규약이다. 저장소 루트의 CLAUDE.md가 파이프라인 구조, 시나리오 파일의 작성 규칙, 검증 단계, 상태 파일은 게이트로만 바꾼다는 규칙을 한곳에 모아 둔다. 스킬 5종은 자주 하는 일의 진입 절차를 고정한다. 새 사건 만들기(sleuth-case-new), 이어서 진행하고 체크포인트 처리하기(run), 수정 요청을 담당 스텝으로 보내 영향 범위를 먼저 알리고 해당 스텝만 다시 돌리기(revise), 검증기를 돌려 결과를 쉬운 말로 풀어 주기(validate), 완성된 시나리오에서 추리 흐름 설계문서를 만들기(review)다. 저장소에는 프롬프트와 게이트, 검증 스크립트만 있고 LLM API 클라이언트는 없다. 글을 쓰고 판단하는 쪽은 이 규약을 읽고 따르는 Claude 세션이다.

4. 용의자를 필드와 개수로 고정하기

외주 원고를 받을 때는 용의자가 "잘 쓰인 인물"이면 됐다. 직접 만들면서는 이 기준으로 검수할 방법이 없었다. 잘 쓰였는지는 사람이 읽어야 아는데 읽을 사람이 없었기 때문이다. 그래서 용의자 한 명이 무엇으로 이루어지는지를 먼저 고정했다. 기본 페르소나(3~5문장 약력 포함), 상대 인물과의 관계와 당일 행적, 감정별 말투 예시 5개(최소 3개, 모델에게 예시 몇 개를 보여 말투를 따라 하게 하는 few-shot), 트리거가 발동할 때 드러나는 것들(0~3개)이다. 개수가 정해져 있으니 행적이 6개뿐인 용의자는 사람이 읽지 않아도 걸린다. 개수로 못 거르는 것은 검수 역할이 대조한다. 범행 시간대의 행적은 설계 단계에서 확정한 분 단위 진실과 정확히 일치해야 한다.

분량은 용의자 한 명에 한글 약 2,000자를 기준으로 했다. 이 내용이 대화 때 그대로 모델의 페르소나 프롬프트가 되기 때문이다. 채우는 방식도 정했다. "늘 묵묵히 일했다" 같은 수식어 대신 시각, 장소, 도구, 수량, 목격자로 채운다. 구체적인 진술이어야 다른 증언과 부딪히고, 부딪혀야 추리 재료가 된다. 범인이 아닌 용의자에게는 어떤 단서로도 완전히 닫히지 않는 알리바이의 구멍을 하나씩 남기게 했다. 알리바이가 빈틈없이 증명되면 소거법으로 용의자가 한 명씩 지워지기 때문이다. 용의자의 숨겨진 비밀의 기본값은 빈 값이다. 모델이 대화 중에 실제로 꺼낼 수 있는 사실이라 하나 늘 때마다 유출 위험도 늘어, 필요한 만큼만 의도해서 채우게 했다.

5. 에이전트에게 맡긴 것과 맡기지 않은 것

가장 오래 고민한 것은 "이 동작을 에이전트가 직접 해도 될까?"였고, 결론은 동작마다 달랐다.

쓰는 일은 맡겼다. 사건 설계, 용의자, 프롤로그와 엔딩, 트리거, 이미지 프롬프트 초안은 세션이 쓴다. 무엇을 몇 개나 써야 하는지는 4절의 스키마로 미리 정했다.
다음 단계로 넘어가는 판정은 맡기지 않았다. 스텝 완료와 체크포인트 승인은 게이트가 기록하고, 선언된 산출물이 디스크에 있는지 확인한다. B와 C에서는 검수 역할이 적은 Critical(통과를 막는 가장 높은 심각도) 개수를 믿지 않고 게이트가 검증기를 직접 다시 돌린다.
승인은 원칙적으로 사람 몫이다. 대화형으로 돌릴 때는 검수 결과를 보여 주고 사람의 응답을 기다린다. 다만 사람 없이 돌리면(/loop와 /goal 처럼) Critical이 없을 때 세션이 승인 명령을 직접 실행할 수 있고, 게이트는 사람이 눌렀는지 에이전트가 눌렀는지 구분하지 못한다.
되돌리기 어려운 업로드는 파이프라인에서 뺐다. 업로드와 최종 이미지 생성을 Studio로 넘기고 파이프라인은 넘겨도 되는 시나리오 파일을 만드는 데서 멈추게 했다.

완전 자동 창작은 처음부터 목표가 아니었다. 에이전트에게 맡긴 것은 구체화하는 일이고, 사람에게 남긴 것은 논리의 완결성과 재미를 판단하는 일이다.

6. 이미지에서 드러난 것

텍스트는 프롬프트와 검증기 규칙으로 꽤 잡혔는데 이미지는 그렇지 않았다.

이미지 제작 파이프라인 개선 개요

한 케이스의 이미지 에셋 42장이 모두 서로 다른 콘텐츠에서 가져온 것처럼 보였다. 추적해 보니 모델의 오류가 아니었다. 이미지 목록이 연속된 두 장면에 같은 부스, 같은 카메라, 같은 유리벽을 주면서 그 너머에 서로 다른 방이 있다고 적어 놓았고, 두 이미지는 각자 받은 프롬프트를 정확히 그렸다. 이미지 모델은 상태가 없어 시나리오 파일도 다른 슬롯도 보지 않고 프롬프트 하나로 그린다. 외관, 위치, 시간, 조명을 프롬프트에 다 적지 않으면 모순은 저작 단계에서 생긴다.

그래서 전역 아트 디렉션, 장소별 고정 건축 설명, 인물별 고정 외양을 한 번 정해 두고 필요한 프롬프트 앞에 그대로 붙이도록 바꿨다. 이 고정 설정을 바이블이라고 부른다. 문장으로 고정되지 않는 기하(소실점, 가구 배치)는 평면도에서 카메라별 구조 레퍼런스 이미지를 렌더해 함께 줬다. Studio는 바이블을 기준으로 해당 인물과 구조 레퍼런스, 앞 장면의 연속성 레퍼런스를 자동으로 불러 이미지 생성에 붙인다.

위 규칙들을 적용한 예시

7. 제작자 스스로 콘텐츠 수정 및 배포하기(studio)

파이프라인이 만드는 것은 시나리오 파일까지다. 그 뒤의 일은 처음에는 개발자의 손을 거쳐야 했다. 스크립트 기반이다보니 CLI 환경에서 작업해야 했고, 비개발자가 접근하기엔 쉽지 않았다. 이미지는 슬롯 목록을 보며 따로 만들어 연결해야 했고, 업로드는 운영 데이터베이스에 직접 쓰는 일이라 실수의 대가가 컸다. 제작자가 저장소를 열거나 명령어를 칠 필요가 없게 하려고, 이 단계를 Studio라는 제작자용 데스크톱 앱 안으로 모았다. 작년까지 상상만 하던 일인데, 올 5월을 계기로 추진하게 되었다.

Sleuth Studio

제작자는 앱에서 스키마 검증 결과(Critical, Warning)를 읽고, 이미지 슬롯에 이미지를 연결하고, 검증을 통과한 케이스를 올린다. 업로드는 앱이 업로드 직전에 검증하고 올린 뒤에 캐시를 갱신하며, 올린 뒤 원본이 바뀌었는지도 감지한다. 파이프라인이 시나리오를 만들고 Studio에서 고쳐 올리는 이 흐름으로 와디즈에 공개한 작품 7편을 냈다.

8. 결과와 측정

비용은 케이스 초안 한 편 기준으로, 수십만원대 외주 원고료가 파이프라인에서는 LLM과 이미지 생성 API 호출 비용으로 많아야 5만 원이었다. 이 숫자에는 사람이 검수하고 고친 시간과 Claude Code 구독료가 들어 있지 않고 초안까지의 비용이다. 사실 외주로 시나리오를 받더라도 AI에 맞게 프롬프트화하고 우리 서비스의 규격에 맞게 가공하는 작업에 상당히 오랜 기간 소요됐다. 그런 측면에서 이렇게 팀 내부적으로 자체 파이프라인을 정형화한 점은 뜻깊은 일이다.