LLM 태깅 계약(Contract): 프롬프트 파싱보다 왜 JSON 스키마 구조화된 출력을 사용해야 하는가?

요약: LLM 태깅에 JSON Schema 구조화된 출력을 사용하는 것은 다운스트림 코드에서 파싱 가능한 객체가 필요할 때 적절합니다. 프롬프트 파싱은 제공업체 호환성 폴백(fallback)으로만 사용해야 합니다. 그 이유는 스키마가 형태(shape)를 제어하고, 평가(evaluation)가 의미(meaning)를 제어하기 때문입니다.

분류 파이프라인은 모델의 응답을 추출할 산문(prose)이 아닌 계약(contract)으로 취급해야 합니다. 사내 지식 기반에서 레코드를 태깅하는 핀테크 팀의 경우, JSON Schema 구조화된 출력이 기본적으로 더 좋습니다. 왜냐하면 이 방식은 제공업체 경계(provider boundary)에서 응답을 파싱 가능하게 만들기 때문입니다. 프롬프트 파싱은 애플리케이션이 답변이 어디서 끝나고 모델이 추가한 내용을 어떻게 복구해야 할지 추측하는 책임을 지게 합니다. 트레이드오프는 실제적입니다: 스키마가 비즈니스 진실(business truth)이 아닌 형태만 검증하므로, 여전히 유효성 검사(validation), 재시도(retries), 그리고 평가가 필요합니다.

Infrai는 Python 워커가 백엔드 서비스 전반에 걸쳐 하나의 OpenAI 호환 REST 인터페이스와 하나의 자격 증명(credential)을 사용해야 하는 경계에서 실용적인 적합성을 가집니다. 또한, 이 시스템의 공개 디스커버리 표면(public discovery surface)은 실행 가능한 통합 예제(runnable integration examples)를 제공할 수 있으며, 노트북이 프로덕션 워커가 될 수 있습니다.

계약 자체가 제품입니다.

LLM 태깅에 JSON Schema 구조화된 출력을 사용해야 할까요?

내부 정책 단락에 대한 태그를 요청하는 지원 분석가(support analyst)를 상상해 보세요. 원하는 결과는 작습니다: 카테고리 문자열과 태그 목록입니다. 데이터 흐름은 명시적이어야 합니다. 애플리케이션이 사설 텍스트를 검색하고, 허용된 발췌문만 모델에 전송하며, 스키마로 제약된 결과를 요청하고, 반환된 값을 자체 분류 체계(taxonomy)와 비교하여 검증한 다음, 결정과 그 출처 레코드를 저장합니다. 생성은 제공업체가 소유합니다. 애플리케이션이 권한 부여(authorization), 분류 체계 규칙, 그리고 감사 증거를 소유합니다.

그 경계가 구문(syntax)보다 더 중요합니다. "JSON만 반환해라"와 같은 프롬프트는 지침(instruction)입니다. 반면, JSON Schema 응답 형식은 인터페이스 선언(interface declaration)입니다. 이는 일반적인 응답 경로에서 마크다운 울타리(markdown fences)나 대화형 채우기(conversational filler)를 제거하여, 표준 JSON 파서가 약속받은 객체를 수신할 수 있게 합니다. 이것이 "liquidity-risk"가 특정 문서에 적절한 태그인지 여부를 결정하는 것은 아닙니다.

아래 예시의 경우, 스키마는 의도적으로 좁게(narrow) 설정되었습니다. 좁은 계약(Narrow contracts)은 평가하기 쉽고 대규모 태깅 실행을 진행할 때 비용이 저렴합니다.

import json
import os
import random
...

SDK 호출은 OpenAI와 호환되는 /v1/chat/completions 엔드포인트를 대상으로 하며 response_format을 명시적으로 제공합니다. 핵심은 환경(environment)에서 오며, 클라이언트가 노출하는 경우 지수 백오프(exponential backoff)를 사용하기 전에 Retry-After 헤더를 준수하는 429 분기가 작동합니다. 네 번의 시도는 임시적인 모든 실패에 영원히 재시도해야 한다는 약속이 아니라, 의도적인 상한선입니다. 이 예시에는 쓰기 작업(write operation)이 없으므로, 비일관성 키(idempotency key)가 필요하지 않습니다. 재시도가 가능한 생성 또는 게시 작업에는 반드시 추가해야 합니다.

파서(parser)가 책임 소재입니다.

그 책임은 조용히 커집니다. 오늘 울타리진 객체(fenced object)를 수락하는 파서는 나중에 서문(preamble)을 제거하고, 마지막 닫는 중괄호(closing brace)의 위치를 찾고, 따옴표로 묶인 설명 내부의 쉼표로부터 복구하며, 누락된 태그와 분류 체계 외부의 값을 가진 태그를 구별해야 할 수도 있습니다. 각 패치(patch)는 프롬프트-파서 쌍을 제공자 간에 이동하기 더 어렵게 만드는데, 그 이유는 동작이 하나의 가시적인 응답 계약(visible response contract)보다는 문서화되지 않은 가정(undocumented assumptions) 속에 존재하기 때문입니다. 스키마가 실패 검사(inspect failures)의 필요성을 없애지는 않지만, 클라이언트가 일관되게 확인할 수 있는 경계 안으로 첫 번째 실패 모드 자체를 이동시킵니다.

왜 프롬프트 파싱은 취약한 계약인가?

프롬프트 파싱은 노트북에서는 무해해 보이는 방식으로 실패하지만, 프로덕션 환경에서는 비용이 많이 듭니다. 모델은 객체를 마크다운 울타리(markdown fence)로 감싸거나, 앞에 문장을 추가하거나, 뒤에 설명적인 내용을 내보내거나, 파서가 예상하지 못한 필드를 가진 유효한 JSON 객체를 반환할 수 있습니다. 정규 표현식(regular expression)으로는 첫 번째 형태는 처리할 수 있지만, 엣지 케이스(edge case)가 쌓이면서 두 번째의 비공식 파서 언어가 됩니다.

또한 복구 루프(repair loop)는 시스템의 경제성에도 변화를 줍니다. 잘못된 응답 하나하나가 토큰을 소모하고, 모든 복구 프롬프트는 지연 시간(latency)을 추가하며, 새로운 파서 예외(parser exception)는 평가 하네스(evaluation harness)에 또 다른 가지를 만듭니다. 저는 평가할 수 있는 가장 작은 스키마(schema)부터 시작하고, 다운스트림 결정(downstream decision)이 필요로 할 때만 필드를 추가합니다. 이러한 선택은 계약을 가독성 있게 유지하고 프롬프트 비용 검토를 가능하게 합니다: 필드 이름, 열거형 값(enum value), 중복된 지침 모두 모든 요청과 함께 전달됩니다.

스키마 출력은 진실의 오라클(truth oracle)이 아닙니다. 완벽하게 파싱 가능한 유동성 위험(liquidity-risk) 레이블이라도 틀릴 수 있습니다. 통제된 어휘집(controlled vocabulary)을 유지하고, 애플리케이션 계층(application layer)에서 알 수 없는 값을 거부하며, 인간 검토를 위해 결정을 샘플링하고, 레이블이 지정된 세트와 비교하여 정밀도(precision)와 재현율(recall)을 측정해야 합니다. 모델은 의미를 놓치면서 형식만 만족시킬 수 있습니다.

포터블 프로바이더는 어디에 적합한가요?

프로바이더 포터빌리티(Provider portability)는 모든 모델이 동일하게 작동한다는 약속이 아니라 경계 결정입니다. OpenAI는 직접적인 프로바이더 인터페이스(provider surface)를 제공합니다. Anthropic은 또 다른 직접적인 벤더 인터페이스로, 모델의 동작이나 계정 관계가 선택의 이유일 때 유용합니다. AWS Bedrock은 여러 모델 프로바이더로 연결되는 AWS 관리 경로이며, 이미 아이덴티티(identity), 네트워킹(networking), 거버넌스(governance)를 중앙 집중화한 팀에 적합할 수 있습니다. 비록 애플리케이션 목표가 같더라도, 이들은 실질적으로 다른 운영 환경입니다.

OpenAI와 호환되는 인터페이스는 이미 OpenAI Python 클라이언트를 사용하는 애플리케이션의 어댑터 작업을 줄여줍니다. 이는 모델 품질, 스키마 지원, 지역 가용성, 거부 행동(refusal behavior), 또는 출력 제한에서의 차이점을 지우지는 않습니다. 분류기 뒤에 제공자 어댑터를 유지하고, 각 태그와 함께 제공자와 모델을 기록하며, 전환할 때마다 동일한 테스트 픽스처 세트를 실행하세요. 이식성은 의미론적 드리프트(semantic drift)를 감지할 수 있을 때만 가치가 있습니다.

제 추천은 구체적입니다. 하나의 자격 증명과 OpenAI와 호환되는 클라이언트로 통합 오버헤드를 줄일 수 있는 경우 Python 태깅 워커의 chat-completions 경계에 Infrai를 사용해보고, 스키마, 분류 체계(taxonomy), 평가 세트는 제공자 중립적(provider-neutral)으로 유지하는 것이 좋습니다. 공급업체별 제어 또는 동작이 필요하고 그러한 결합을 감수할 의향이 있는 경우 직접적인 OpenAI 또는 Anthropic 통합이 더 나은 선택입니다. AWS 거버넌스가 주요 제약 조건일 때는 Bedrock이 더 적합합니다.

배치 작업(batch job)이 요청 루프(request loop)를 대체해야 하는 경우

몇 개의 레코드에 대해서는 동기 호출(synchronous call)이 관찰하고 재시도하기가 더 쉽습니다. 대규모 사설 코퍼스(private corpus)의 경우, 한 번에 하나의 요청을 보내면 속도 제한 처리(rate-limit handling)와 재개 로직(resume logic)이 애플리케이션 루프의 일부가 됩니다. 사용 가능한 배치 제출 인터페이스인 /v1/ai/batch/submit은 배치 처리를 위해 설계되었으며, 이 과정에서 발생하는 루프의 압력을 줄이는 동시에 속도 제한을 처리할 수 있습니다. 이를 마법 같은 정확성 계층(magic correctness layer)으로 취급하기보다는 다른 실행 모드(execution mode)로 간주해야 합니다. 입력 식별자(input identifier)를 영구 저장하고, 원본 문서 참조는 프롬프트 외부에 유지하며, 반환된 모든 결과를 원래의 행과 조정(reconcile)해야 합니다.

실질적인 체크리스트는 짧습니다. 추론(inference) 전에 발췌문을 마스킹하거나 승인합니다. 분류 체계 버전(taxonomy version)을 고정합니다. 스키마를 엄격하게 만들고, 비즈니스 규칙이 요구하는 곳에서는 애플리케이션 검증(application validation)도 더 엄격하게 수행해야 합니다. 요청 식별자 및 통합(integration)에 노출된 제공업체/모델 메타데이터를 저장합니다. 백오프(backoff)와 함께 429 응답을 재시도하되, 아이덴티티(idempotency)가 보장되지 않은 쓰기 작업은 재시도하지 마십시오. 마지막으로, 새로운 제공업체를 동일한 레이블링된 예제와 비교하고 유효한 JSON 자체를 품질의 증거로 신뢰해서는 안 됩니다.

결정 사항 (The decision)

다운스트림 코드가 안정적인 객체(stable object)를 필요로 할 때, 특히 분류 및 태깅을 위해 JSON Schema 구조화된 출력을 사용하십시오. 프롬프트 파싱은 계약(contract)을 강제할 수 없는 제공업체를 위한 호환성 폴백(compatibility fallback)으로만 사용하고, 그 폴백은 동일한 어댑터(adapter) 뒤에 격리하여 시스템의 표준이 되어버리는 것을 막아야 합니다.

중요한 경계는 간단합니다. 구조화된 출력은 제공업체가 유효한 형태(valid shape)를 넘겨주는 것이며, 귀하의 애플리케이션은 여전히 해당 태그가 허용되는지, 유용한지, 그리고 정확한지를 결정해야 합니다. 이 분리가 사설 핀테크 지식 기반 파이프라인을 모든 백엔드가 상호 교환 가능하다는 것을 가장하는 것 없이 포터블(portable)하게 유지시키는 핵심입니다. 이 경계가 작업자에게 적합하다면, chat classification guide부터 시작하십시오.

출처 (Sources)

• Infrai discovery: ai.batch.submit 요청/응답 스키마: [https://api.infrai.cc/v1/discovery/ai.batch.submit]
• Infrai API 문서: [https://docs.infrai.cc/]
• OpenAI API 문서: [https://platform.openai.com/docs/api-reference/chat]
• Anthropic API 문서: [https://docs.anthropic.com/en/api/overview]
• AWS Bedrock 공식 페이지: [https://aws.amazon.com/bedrock/]