JSON으로 답해"는 작동 안 함 — 출력 형식 강제의 함정과 비용

Q: 프롬프트의 "형식 강제" 요청으로 일관된 구조를 얻을 수 있는가?

**단순 텍스트 요청으로는 안 되고, 모델에 스키마를 주입하여 형식을 강제해야만 파싱 가능한 출력을 얻는다.** "JSON으로 답해 주세요"라는 프롬프트 수준에서는 필수 키 누락, 자료형 오류, 깨진 JSON이 여전히 발생하며, 이를 방지하려면 Structured Output 기술을 적용해야 한다.

Q: "JSON으로 답해" 요청만으로 왜 파싱이 자꾸 실패하나?

모델은 텍스트 생성 엔진이기 때문에 프롬프트 수준의 형식 요청은 **강제 조건이 아니라 권유**일 뿐이다.

Q: Structured Output을 적용하면 실제로 무엇이 달라지나?

OpenAI와 LangChain의 `with_structured_output` 메커니즘을 사용하면, 모델이 응답 생성 단계에서 스키마 제약을 받아 형식 위반이 원천적으로 차단된다.

Q: 프롬프트 구조에서 형식 강제를 어디에 배치해야 하나?

2026년 기준 효과적인 프롬프트는 **역할 → 목표 → 맥락 → 입력 → 제약 → 출력 형식 → 검증 규칙** 7단계로 설계된다.

Q: 모델 버전·API 변경에 따른 출력 안정성은 어느 정도인가?

2024~2025년 OpenAI `gpt-4o` 모델은 Structured Output 지원이 안정적이나, 모델 업데이트나 새 버전 도입 시 스키마 준수율이 미세하게 변할 수 있다.

Q: 비용과 운영: 구조화 출력을 모든 시나리오에 써야 하나?

**아니다.** Structured Output의 토큰 오버헤드(5~15%)와 지연 증가를 고려하면, 다음과 같이 선택적으로 적용하는 게 현실적이다.

프롬프트의 "형식 강제" 요청으로 일관된 구조를 얻을 수 있는가?

단순 텍스트 요청으로는 안 되고, 모델에 스키마를 주입하여 형식을 강제해야만 파싱 가능한 출력을 얻는다. "JSON으로 답해 주세요"라는 프롬프트 수준에서는 필수 키 누락, 자료형 오류, 깨진 JSON이 여전히 발생하며, 이를 방지하려면 Structured Output 기술을 적용해야 한다.

단순 요청의 한계: 프롬프트에서 형식을 텍스트로만 명시하면 모델이 의도적으로 형식을 벗어날 수 있으며, 특히 복잡한 중첩 구조에서 오류율이 높아진다.
Structured Output 효과: LangChain with_structured_output 또는 Claude의 스키마 주입을 사용하면 모델이 정의된 스키마 범위 내에서만 응답을 생성하도록 강제되어 파싱 실패가 제거된다.
2026년 표준: OpenAI gpt-4o, Claude 3.5 이상의 모델은 스키마 기반 구조화 출력을 기본 기능으로 지원하며, 이를 활용하지 않으면 검증 로직이 백엔드에 남게 된다.

"JSON으로 답해" 요청만으로 왜 파싱이 자꾸 실패하나?

모델은 텍스트 생성 엔진이기 때문에 프롬프트 수준의 형식 요청은 강제 조건이 아니라 권유일 뿐이다. 특히 복잡한 추론이 필요하거나 예외 상황이 있을 때 모델은 설명을 덧붙이거나 형식을 변형하곤 한다.

실제 발생하는 문제들

필수 키 누락: 프롬프트에서 "이름, 나이, 직무를 JSON으로 출력하라"고 요청했을 때, 모델이 일부 값이 불확실하다고 판단하면 그 필드를 생략하고 설명을 추가한다. 파서는 KeyError를 던진다.

자료형 오류: "age": "서른두" 처럼 숫자를 문자열로 반환하거나, 날짜를 임의 포맷으로 출력한다. 스키마에서 정수나 ISO 8601 형식을 기대했다면 타입 검증에서 걸린다.

깨진 JSON: 생성 과정에서 토큰이 끊기거나 모델이 따옴표를 닫지 않은 채 응답이 종료되면 JSON 파서가 실패한다. 프롬프트 요청만으로는 이를 방지할 수 없다.

Structured Output을 적용하면 실제로 무엇이 달라지나?

OpenAI와 LangChain의 with_structured_output 메커니즘을 사용하면, 모델이 응답 생성 단계에서 스키마 제약을 받아 형식 위반이 원천적으로 차단된다.

기술적 적용 방식

Python + Pydantic 스키마:

from pydantic import BaseModel, Field
from langchain_openai import ChatOpenAI

class ExtractedInfo(BaseModel):
    name: str = Field(description="사람의 이름")
    age: int = Field(description="나이 (정수만)")
    role: str = Field(description="직무")

llm = ChatOpenAI(model="gpt-4o")
structured_llm = llm.with_structured_output(ExtractedInfo)
result = structured_llm.invoke("John은 35세의 소프트웨어 엔지니어다.")
# result는 항상 ExtractedInfo 인스턴스이며, 필드 누락이 없다.

효과:

모델이 스키마 범위 내에서만 응답을 생성하도록 내부적으로 제약된다.
파서가 검증 로직 없이 곧바로 구조화된 데이터를 받는다.
백엔드 예외 처리 코드가 대폭 줄어든다.

그러나 비용이 있다

모델이 스키마 준수를 위해 추론 오버헤드를 발생시킨다. 단순 텍스트 생성보다 토큰 소비가 5~15% 증가할 수 있으며, 응답 지연도 미세하게 늘어난다. 대규모 배치 처리에서는 이 차이가 누적된다.

프롬프트 구조에서 형식 강제를 어디에 배치해야 하나?

2026년 기준 효과적인 프롬프트는 역할 → 목표 → 맥락 → 입력 → 제약 → 출력 형식 → 검증 규칙 7단계로 설계된다. 여기서 "출력 형식"과 "검증 규칙"이 핵심이다.

시스템 프롬프트 템플릿

# 역할
당신은 뉴스 기사에서 정보를 추출하는 AI다.

# 출력 형식 (6단계)
다음 JSON 스키마로만 응답한다:
{
  "headline": "기사 제목 (필수)",
  "date": "발행일 (YYYY-MM-DD 형식)",
  "entities": ["등장 인물/기관 배열"],
  "sentiment": "긍정|중립|부정 중 하나"
}

# 검증 규칙 (7단계)
- 불확실한 내용은 null로 표시한다.
- entities 배열이 비어 있으면 빈 배열 []을 반환한다.
- sentiment는 반드시 열거값 중 하나여야 한다.

이 구조를 코드에서 Pydantic으로 정의하면, 프롬프트와 스키마가 일치하여 검증이 자동화된다.

구조화 출력과 프롬프트 텍스트 요청을 함께 쓸 때의 함정은?

많은 팀이 "Structured Output을 사용하니까 프롬프트는 대충 써도 된다"는 착각을 한다. 그러나 스키마 강제와 프롬프트 품질은 직교한다. 스키마는 형식만 보장할 뿐, 내용 정확도는 보장하지 않는다.

실패 사례

시나리오: "고객 만족도 평가"를 스키마로 강제했는데, 모델이 제시된 텍스트에서 만족도를 찾지 못해도 임의 값을 반환한다.

{
  "satisfaction_score": 7,  // 스키마 위반 없음. 그러나 텍스트에 근거 없음.
  "reason": "고객이 만족해 보였다"  // 추측
}

원인: 스키마는 "점수는 1~10 정수"라는 형식만 강제한다. 프롬프트에서 "확실하지 않으면 null을 반환하라"는 지시가 없으면 모델은 채우려고 한다.

올바른 접근

프롬프트의 검증 규칙 단계에서 명시:

- 만족도가 텍스트에 명확하지 않으면 satisfaction_score를 null로 둔다.
- reason 필드에는 텍스트의 직접 인용 또는 "정보 부족"을 기록한다.

이를 스키마에도 반영:

class SatisfactionEval(BaseModel):
    satisfaction_score: Optional[int] = Field(None, ge=1, le=10)
    reason: str = Field(description="근거 또는 '정보 부족'")

결론: 스키마 강제 + 프롬프트 지시 + 선택적 필드 설계가 삼위일체여야 신뢰도가 높아진다.

모델 버전·API 변경에 따른 출력 안정성은 어느 정도인가?

2024~2025년 OpenAI gpt-4o 모델은 Structured Output 지원이 안정적이나, 모델 업데이트나 새 버전 도입 시 스키마 준수율이 미세하게 변할 수 있다. 예를 들어 동일 스키마를 gpt-4o와 gpt-4-turbo에서 실행했을 때 필드 누락률이 0.3% 차이가 난 사례가 있다.

회귀 테스트 체크리스트

구조화 출력을 적용했다면, 모델 버전 업데이트 시 자동화된 일괄 평가를 실행해야 한다:

100개 이상 샘플에서 스키마 준수율 99% 이상 유지 확인
선택적 필드 null 비율이 예상 범위 내인지 검증
엣지 케이스(매우 긴 입력, 모호한 요청 등)에서 타입 오류 발생 여부 확인

GitHub Actions 같은 CI/CD 도구로 자동화하면, 프롬프트를 코드처럼 버전 관리하고 품질 저하를 즉시 감지할 수 있다.

비용과 운영: 구조화 출력을 모든 시나리오에 써야 하나?

아니다. Structured Output의 토큰 오버헤드(5~15%)와 지연 증가를 고려하면, 다음과 같이 선택적으로 적용하는 게 현실적이다.

시나리오	구조화 출력 필요성	이유
API 응답 또는 DB 저장	필수	파싱 실패가 장애로 이어짐
단순 요약·번역	선택	형식 강제 오버헤드 > 검증 이득
복잡한 중첩 데이터	필수	수동 검증 비용이 매우 높음
실시간 스트리밍	신중	스키마 강제 시 토큰 버퍼링 증가
교육·분석용 텍스트	선택	형식 고정의 필요성 낮음

비용 산정 예시

월 100만 요청 기준:

구조화 출력 적용: 토큰 10% 증가 → 월 추가 비용 약 20~50달러 (모델에 따라 변동)
파싱 실패 대응: 재요청 + 검증 로직 개발 + 모니터링 → 월 개발 비용 수백 달러

초기 도입은 비용이지만, 장기적으로는 운영 비용을 낮춘다.

핵심 정리

출력 형식 강제는 프롬프트 텍스트만으로 구현 불가: "JSON으로 답해"라는 요청은 권유일 뿐 강제가 아니며, 필수 키 누락, 타입 오류, 깨진 JSON이 여전히 발생한다.
Structured Output이 2026년 표준: LangChain의 with_structured_output 또는 Claude의 스키마 주입을 사용하면 모델이 정의된 스키마 범위 내에서만 응답하도록 내부적으로 강제되어 파싱 안정성이 크게 올라간다.
스키마 강제 + 프롬프트 지시 + 선택적 필드 설계가 삼위일체: 스키마만으로는 내용 정확도를 보장할 수 없으며, 프롬프트의 검증 규칙 단계에서 불확실한 경우의 처리(null 반환, 근거 제시 등)를 명시해야 신뢰도가 높아진다.
모델 버전 변경 시 회귀 테스트 필수: 자동화된 일괄 평가(CI/CD)로 스키마 준수율 99% 이상 유지를 정기적으로 검증해야 버전 업데이트 후에도 안정성을 보장한다.
모든 시나리오에 필요하지는 않으나, API 연동과 복잡한 데이터 추출에서는 필수: 토큰 오버헤드(5~15%)가 있지만, 파싱 실패 대응과 검증 로직 개발 비용을 고려하면 초기 도입이 장기적 운영 비용을 낮춘다.