장편 생성 회고: 상태 객체 기반 컨텍스트 전략과 대표적 실패 사례

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

장편 생성에서 전체 문서를 매번 컨텍스트로 넣으면 토큰 사용량이 급증해 비용과 컨텍스트 한계에 봉착하므로 압축된 상태 객체와 최근 챕터만 제공하는 방식으로 비용을 선형화했다는 실무적 전략이 소개되었다; 그러나 이 방식은 무출력 완료, 모델의 임의 인물 생성, 조기 사건 해결, 교차 챕터 모순, 상태 롤백 난항 같은 실패 모드를 낳았고 각 실패는 max_tokens 여유 확보와 stop_reason·텍스트 존재 강제 검사, 등장인물 명부 주입과 타이밍 제약, 전체 문서에 대한 별도 검증 패스, 상태 스냅샷 정책으로 해결되었다는 점이 실제 수치와 함께 보고되었다.

실용적 조언

출력 목표보다 충분한 max_tokens 여유를 확보하고 응답의 stop_reason 및 실제 텍스트 블록 존재 여부를 강제 검사하도록 파이프라인을 구성해야 한다는 점이 우선 순위로 제시되었다. 또한 파일 수정 시간과 단어 수를 교차검증하는 보조 체크를 두어 프로세스 종료 코드만으로 완료를 판단하지 않도록 해야 하며 이러한 다중 검증은 무출력 완료로 인한 데이터 오염을 방지한다.
각 생성 호출에 완전한 등장인물 명부와 플롯 타이밍 제약을 명시적으로 주입하는 방법이 재현성 문제를 크게 줄였고 프롬프트의 제약 문구는 단순 금지보다 구체적인 비트 서열과 함께 제공해야 효과가 크다는 실무적 권고가 도출되었다. 상태 객체는 스냅샷 방식으로 버전 관리하거나 git 커밋 형태로 기록해 특정 시점 복원이 가능하도록 설계해야 재작업 비용을 낮출 수 있다.
최종 검증으로 완성 문서 전체를 대상으로 한 'fresh eyes' 패스를 도입해야 교차 챕터 모순과 타이밍 문제를 포착할 수 있으며 이 단계는 챕터별 검증으로는 도달할 수 없는 높은 가치를 제공한다는 점이 경험적으로 확인되었다. 비용 최적화를 위해 상태 갱신과 일부 검증은 저비용 모델로 수행하고 최종 생성과 수리 패스에만 고급 모델을 사용하는 하이브리드 전략을 고려할 것을 권장한다.

섹션별 상세

장편 문서 생성에서 전체 문서를 매번 컨텍스트로 넣는 방식은 토큰 사용량이 기하급수적으로 증가해 비용과 컨텍스트 한계에 직면한다는 문제였으며 실제 사례로 28장짜리 책을 재전송하면 누적 입력이 약 2.2M 토큰으로 늘어나며 초안 단계 비용이 대략 15배로 확대된다고 보고되었다. 이를 해소하기 위해 각 챕터 생성 시 압축된 상태 객체와 최근 1–2개 챕터만 제공하는 아키텍처를 도입했고 상태 객체는 등장인물 목록, 설정, 처리된 비트 등을 요약한 구조로 저비용 모델을 통해 지속 갱신하는 흐름을 택했다. 이 접근은 비용을 챕터 수에 대해 거의 선형으로 만들었으나 동시에 장기적 가시성을 잃어 교차 챕터 일관성 문제가 새롭게 부각되는 설계적 트레이드오프를 드러냈다.

API 호출에서 출력이 기대치보다 짧게 잘리고도 프로세스는 정상 완료(exit code 0)로 기록되는 무출력 완료 사례가 발생했고 그 원인은 max_tokens 설정과 모델의 내부적 'thinking' 단계가 출력 토큰 예산을 먼저 소진해 응답의 content 배열에 텍스트 블록이 없는 형태의 정상 응답을 반환한 데 있었다. 현장 대응으로는 출력 목표보다 여유를 둔 max_tokens 확보(예시로 3k 단어 출력 목표에 대해 8k에서 16k로 확장), stop_reason과 실제 text 블록 존재 여부를 강제 검증하는 실패 규칙 도입, 파일 수정 시간과 단어 수로 최종 결과를 교차검증하는 절차를 채택했다. 이러한 검증 조치로 무출력 완료를 실패로 간주하고 수리 루틴을 실행하게 되어 이후 배치 오류와 부분 JSON 파싱 실패에 의한 '완료로 표시되었으나 사실 실패한' 사건을 줄였다.

상태 객체 전략에 따른 가시성 부족이 직접적으로 새 등장인물의 임의 생성으로 이어진 사례가 있었는데 사례에서는 23장에서 'Corporal Fenn'이라는 이름이 모델에 의해 창조되어 이후 챕터에서 재사용되었고 그 이름은 원안 개요에 존재하지 않았다. 이 문제는 최근 몇 챕터만 제공되는 맥락에서 기존 캐스트 항목이 보이지 않자 모델이 대체 표현을 생성한 것이며, 해결책은 각 생성 호출에 완전한 등장인물 명부를 주입하고 '이 명부가 완전하므로 기존 역할을 대체하는 새 이름을 만들지 말라'는 규칙을 명시적으로 부여한 프롬프트 제약을 적용한 것이다. 이 규칙을 적용한 결과 인물 창조율이 사실상 0으로 떨어졌으며 프롬프트 제약이 일관성 유지에 단단한 방벽 역할을 한다는 결과가 확인되었다.

플롯 타이밍 통제 실패 사례는 아웃라인에서 특정 이벤트를 27장에서만 발생시키도록 기획했지만 중간 챕터에서 모델이 동일 이벤트를 미리 실행해 최종 기대 효과가 소멸한 사건으로 나타났고 흥미롭게도 더 능력 있는 모델로 업그레이드할수록 즉흥적 해결 확률이 증가했다는 관찰이 있었다. 그 해결책으로는 단순한 금지 문구가 아니라 구체적 비트 시퀀스와 '챕터 K 이전에는 X를 해결하지 말라'는 명확한 타이밍 제약을 프롬프트에 포함해 모델 생성 과정의 자유도를 제한하는 방식이 채택되었다. 이 접근은 강력한 모델일수록 더 엄격한 펜싱(fencing)이 필요하다는 실무적 교훈을 제시했으며 프롬프트 설계가 품질 제어의 핵심 수단이라는 결론을 뒷받침했다.

교차 챕터 모순과 상태 관리 관련 비용 구조는 각 챕터 검증만으로는 포착할 수 없고 전체 문서를 조합해 보는 별도의 검증 패스가 가장 가치가 높았다는 결론으로 귀결되었으며 느슨한 상태 객체를 단일 JSON으로 뮤터블하게 운영한 탓에 롤백과 재작업 비용이 크게 증가했다는 문제가 뒤따랐다. 실무 해결책으로는 각 챕터 완료 시점의 상태 스냅샷을 저장하거나 git 커밋 형태로 기록해 필요한 시점에 정확한 시점 복원이 가능하도록 만들었고 전체 조합물에 대해 'fresh eyes' 검증을 수행해 교차 문맥 모순을 자동으로 찾아내도록 워크플로를 재편했다. 비용 관점에서 저가 모델로 상태 갱신을 수행하는 클린 런은 수 달러에 불과했으나 고급 모델과 복구 패스를 포함한 전체 생산 아웃풋은 약 550회 API 호출에 걸쳐 대략 35달러의 비용이 소요되었다는 실제 수치가 제시되어 총비용 판단에 실무적 근거를 제공했다.

용어 해설

컨텍스트 윈도우(Context Window): — 모델이 한 번의 호출에서 참조할 수 있는 입력 토큰의 범위로서, 긴 문서를 다룰 때는 전체 텍스트를 한 번에 넣을 수 없어 일부만 유지하게 되고 이로 인해 장기적 일관성 문제가 발생한다.
상태 객체(State Object): — 작품 전개에서 핵심 정보(등장인물 목록, 설정, 미해결 플롯 비트 등)를 압축해 기록하는 구조로서, 각 챕터 생성 시 최신 상태를 반영하도록 입력받아 토큰 비용을 줄이지만 가시성 부족이 교차문서 불일치의 원인이 된다.
중단 사유(Stop Reason): — 모델 응답이 왜 중단되었는지를 나타내는 API 응답 필드로서, 출력이 비어 있거나 thinking 단계로 토큰 예산을 소진했을 때 적절한 실패 판단 근거로 사용해야 하는 진단 지표이다.
전체 문서 검증(Full-Document Validation): — 각 챕터별로는 드러나지 않는 교차 챕터 모순을 찾아내기 위해 완성된 문서 전체를 대상으로 진행하는 검수 단계로서, 챕터별 검증으로는 포착할 수 없는 불일치와 타이밍 오류를 발견하는 핵심 품질 관리 절차이다.