Stop letting the prompt be your state machine

개요

LLM 기반 기능에서 프롬프트 자체를 상태 관리 메커니즘으로 사용하는 것을 지양하고, 대신 타입이 명확한 워크플로우 단계와 구조화된 출력 및 스키마 유효성 검사를 통해 결정론적이고 테스트 가능한 시스템을 구축해야 합니다.

주요 내용

* 프롬프트는 런타임이 아니다: LLM 모델이 의도 결정, 데이터 수집, 응답 형식 지정, 지속 등 모든 작업을 프롬프트 내에서 처리하도록 방치하는 것은 위험하며, 이는 '우발적인 런타임' 함정으로 이어져 결과의 일관성을 보장하기 어렵게 만듭니다.
* 결정론의 실제 의미: LLM 자체의 출력은 확률적이므로 제어할 수 없지만, 출력의 형식(구조화된 출력 및 스키마 유효성 검사), 모델 호출 전후 단계, 모델에 입력되는 데이터, 유효성 검사 실패 시 처리 방식, 인간 검토 여부 등은 제어 가능하며 이를 통해 '동일 입력, 동일 워크플로우 단계, 동일 가드레일'을 달성할 수 있습니다.
* 타입이 명확한 워크플로우 단계: 복잡한 작업을 모델 호출을 중심으로 명확한 입력 및 출력 타입을 가진 개별 단계로 분할해야 합니다. 모델 호출은 전체를 아우르는 것이 아니라 파이프라인의 한 단계로 포함되어야 하며, 각 단계는 독립적으로 단위 테스트가 가능해야 합니다.
* 구조화된 출력 및 스키마 유효성 검사: 모델 호출 단계에서는 원시 문자열 대신 JSON 모드, 툴 호출 또는 스키마 제약 완성 등을 사용하여 구조화된 데이터를 반환받고 즉시 스키마 유효성 검사를 수행해야 합니다. 유효성 검사 실패는 예외로 처리하여 애플리케이션의 다른 부분에 영향을 미치지 않도록 해야 합니다.
* 재시도, 멱등성 및 실패 게이트: 유효성 검사 실패 시 스크립트가 중단되지 않도록 재시도 메커니즘을 포함하고, 외부 상태에 영향을 미치는 경우 멱등성을 확보해야 합니다. 워크플로우 레이어가 이러한 제어를 담당합니다.
* 인간 검토 게이트: 고영향 또는 되돌릴 수 없는 결정이 필요한 경우, 자동화된 처리 대신 인간 검토를 위한 제어 게이트를 두어 최종 커밋 전에 검토하도록 해야 합니다. 이는 LLM의 능력이 부족해서가 아니라, 잘못된 결정의 비용이 자동화 이득보다 클 수 있기 때문입니다.

시사점

LLM 기반 시스템의 신뢰성과 유지보수성을 높이기 위해서는 프롬프트에 모든 로직을 위임하는 대신, 타입이 명확한 워크플로우, 구조화된 출력, 엄격한 스키마 유효성 검사, 그리고 적절한 오류 처리 및 인간 검토 메커니즘을 통합하는 아키텍처 설계가 필수적입니다.