한 번에 거대한 중첩 JSON을 요청하면 출력 중단으로 모든 답변이 손실되는 '포맷 택스' 문제가 발생한다는 경험 공유

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

TL;DR

중첩된 JSON을 한 번에 생성하라고 모델에 요구하면 모델이 값 추출과 정확한 형식 출력을 동시에 수행하는 과정에서 출력 토큰 한계로 응답이 중간에 끊기면 전체 결과가 파싱 불가 상태로 무효화되는 '포맷 택스'가 발생한다. 이를 완화하기 위해 원문은 각 필드를 '키 = 값' 한 줄로 출력하도록 하고 전체 스키마를 모델이 완료할 수 있는 크기의 여러 호출로 분해해 코드에서 재조합하도록 설계하면 컷오프가 발생해도 손실이 한 필드나 한 호출로 제한된다고 권고한다. 동일한 369필드 SEC 공시 사례에서 단일 호출로는 최첨단 모델들이 0.0%를 기록했으나 스키마 분해와 평면 출력으로 qwen3.6-27b가 0%에서 85%로 개선된 점이 근거로 제시되며, 저자는 이 관찰이 모델 능력보다 요청의 형태가 결과에 결정적 영향을 준다는 실무적 교훈을 시사한다고 결론지었다.

주요 논점

01찬성다수

단일 대형 JSON 요청은 형식 출력 실패 시 전체 응답을 잃게 만드는 구조적 위험을 내포하므로, 필드별 평면 출력과 스키마 분해가 더 실용적이라는 주장이다.

02중립분열

대형 모델이 단일 호출 문제를 해결할 가능성은 남아 있으나, 현재 관찰된 0% 결과와 분해 후 85% 개선은 요청 설계가 우선적이라는 관점이 유효하다는 주장이다.

합의점 vs 논쟁점

합의점

단일 호출로 많은 필드를 중첩된 JSON 형식으로 요구하면 출력 컷오프가 발생할 때 전체 응답 신뢰성이 크게 떨어진다는 점에 동의하는 것으로 보인다.
출력을 평면 라인으로 만들고 스키마를 분해해 여러 호출로 처리하면 컷오프 시 손실 범위를 제한할 수 있다는 점은 실무적으로 설득력을 가진 방법론이다.

논쟁점

분해 방식이 항상 모델 크기나 모델 계열과 무관하게 우월한지 여부는 불확실하며, 저자는 프런티어 모델들도 같은 방식으로 이득을 볼 것이라고 추정하였으나 해당 모델들로의 재검증은 이루어지지 않았다.
한 번에 많은 필드를 요청하는 워크플로를 근본적으로 바꿀 수 없는 상황에서 중간 대안(예: 스트리밍/체크포인트 방식)들이 더 적합할 수 있는지에 관한 의견이 갈리는 점이 존재한다.

실용적 조언

중첩된 구조의 큰 스키마를 한 번에 요청하지 말고 출력 컷오프가 발생해도 피해를 국한시키도록 각 필드를 평면 라인으로 내보내도록 설계하라.
전체 필드 집합을 모델이 완성할 수 있는 크기의 여러 호출로 쪼갠 뒤 코드에서 원래의 중첩 구조로 재조립하라; 원문에서는 1,000개 필드를 약 30회의 호출로 나누어 처리한 사례를 예로 들었다.
출력 실패 시 한 줄 또는 한 호출 분량만 손실되도록 하면 잘못된 형식 때문에 전체 결과가 무효화되는 리스크를 제거할 수 있으므로 파싱 전용의 단순한 재조립 로직을 마련하라.

섹션별 상세

대형 중첩 JSON을 한 번에 생성하도록 요청하면 모델은 동시에 값을 찾는 작업과 정확한 중첩 형식을 출력하는 작업을 수행해야 하며, 이로 인해 출력 토큰 한계에 도달하면 응답이 중괄호나 따옴표 중간에서 끊기기 쉽다. 끊긴 출력은 JSON 파서가 전체 응답을 무효화하게 만들기 때문에 일부 필드의 정답이 맞더라도 전체 결과가 버려진다. 원문에서는 369개 필드를 요구한 단일 호출에서 여러 최첨단 모델의 점수가 모두 0.0%로 기록되었다는 관찰을 근거로 이 메커니즘의 실효성을 지적한다. 이 문제는 요청의 형태가 출력 신뢰성에 결정적 영향을 미친다는 실무적 귀결을 갖는다.

평면화된 필드 출력 방식은 각 필드를 '키 = 값' 한 줄로 내보내도록 하는 방식으로, 출력이 중단될 경우 손실을 하나의 필드 또는 라인으로 국한시키므로 전체 응답이 무효화되는 위험을 줄인다. 이 방법은 모델에게 중첩 구조를 동시에 유지하도록 요구하지 않고, 대신 각 라인을 이후 코드에서 재조합하는 워크플로로 설계되어 있다. 원문 예시에서처럼 'filing.revenue = 1284500' 형태로 출력하면 잘린 출력이 있더라도 나머지 라인은 파서나 단순한 텍스트 처리로 보존할 수 있다. 이 접근은 출력 완결성이 중요한 대량 필드 추출 작업에서 복원성을 크게 개선한다.

스키마를 여러 개의 호출로 분해하는 전략은 전체 1,000개 필드 같은 큰 작업을 모델이 완성할 수 있는 크기의 여러 요청으로 나누는 것으로, 각 호출이 토큰 한계 내에서 끝나도록 설계하면 출력 컷오프가 발생하더라도 손실 범위를 제한할 수 있다. 원문에서는 1,000개 필드를 약 30개의 호출로 나누어 처리한 사례를 제시하며, 같은 문서 집합에서 qwen3.6-27b 모델이 단일 호출에서 0%였던 점수에서 분해 후 85%로 개선된 사실을 근거로 들고 있다. 이 결과는 모델의 정답 능력 자체보다 요청의 형태와 출력 길이 관리가 결과에 큰 영향을 준다는 실무적 시사점을 제공한다.

이미지 분석

Chart
이미지는 단일 호출(빨강)과 분해 호출(파랑)의 점수 비교를 시각화하여 단일 호출에서 0%에 수렴한 반면 분해 호출은 높은 점수를 기록한 구간을 보여준다. 이 시각적 근거는 원문 텍스트의 수치적 주장을 보완하며, 출력 형식이 결과에 미치는 영향을 한눈에 확인하게 한다.
동일한 369개 필드 추출 작업에서 단일 호출 방식과 스키마 분해 방식의 성능 차이를 비교한 결과 스냅샷이다.

용어 해설

ExtractBench: — ExtractBench는 문서에서 다수의 필드를 구조화된 JSON으로 추출하는 성능을 측정하는 벤치마크로, 대량의 중첩 필드를 포함한 법인 공시 문서 등을 대상으로 모델의 응답 완결성과 정확도를 평가한다. 이 벤치마크는 단일 호출로 많은 필드를 요청할 때 발생하는 출력 중단 문제와 형식 오류에 민감하여 요청 형태와 파싱 관행의 영향을 평가하는 데 유용하다.
Format tax: — 포맷 택스는 모델에게 중첩된 JSON 같은 엄격한 출력 형식을 동시에 만들게 할 때 발생하는 실패 메커니즘을 가리키며, 모델이 답을 찾는 작업과 형식을 정확히 출력하는 작업을 병행하면서 토큰 한계로 응답이 중단되면 전체 출력이 무효화되는 현상을 뜻한다. 이 문제는 출력 컷오프가 발생할 경우 단일 장문의 구조형 응답 전체가 파싱 불가능해지는 점에서 비용이 크다.
Schema Decomposition: — 스키마 분해는 하나의 대형 출력을 요구하는 대신 전체 필드 집합을 적당한 크기의 여러 호출로 쪼개어 각 호출이 모델의 출력 한계를 넘지 않도록 하는 방법론으로, 각 호출 결과를 코드로 재조합해 원래의 중첩 구조를 복원하는 절차를 포함한다. 이 방식은 개별 호출이 컷오프되어도 손실 범위를 해당 호출의 필드로 국한시켜 전체 작업의 복원력을 높인다.

코드 예제

text

filing.revenue = 1284500
filing.subsidiaries[0].name = Brookstone Holdings

중첩 JSON 대신 필드별 평면 라인으로 출력하여 컷오프 시 손실을 국한시키는 예시 출력 형식이다.

언급된 도구

qwen3.6-27b추천

369개 필드 문서 추출 실험에서 스키마 분해 후 성능 개선을 보인 테스트 모델

ExtractBench중립

문서에서 다수 필드를 추출하는 성능을 측정한 벤치마크

언급된 리소스

문서이미지: single-call vs split-call 성능 비교 스크린샷