같은 10‑Q 문서와 같은 모델로 비교한 결과 nfield가 82%로 선두를 차지하고 단일 호출 라이브러리는 최대 37%에 그쳤다

작성자는 자신이 라이브러리를 만든 사람이라고 공개한 뒤 코드 링크를 댓글에 올린다고 밝혔고, 같은 문제를 겪은 LangChain 사용자들이 공감할 것이라는 문맥을 덧붙여 피드백을 요청했다. 게시물 자체에 여러 비교 수치와 구체적 사례가 포함되어 있어 다른 사용자들이 재현 경험이나 추가 실험 결과를 공유하기 용이한 상태가 조성되었다. 작성자의 요청은 문제 재현 지점과 대규모 스키마 추출 워크플로에서의 경험 공유로 귀결되었다.

• 대규모 스키마를 추출할 때는 먼저 모델의 실제 토큰 한도를 확인하고 그 한도에 맞춰 스키마를 분할하는 계산을 자동화해야 한다. 호출을 최소화하면서도 각 호출이 토큰 한도 안에 들도록 필드를 묶는 로직을 구현하면 실패 시 재시도 범위를 좁힐 수 있다. 또한 평탄화된 'path = value' 출력 방식을 사용하면 일부 라인 손실이 전체 파싱 실패로 확산되는 것을 방지할 수 있으며, 이후 경로 표기를 따라 중첩 구조를 재구성하는 후처리 파이프라인을 준비해야 한다.
• 작업 파이프라인에 기존 Pydantic 모델이나 dataclass를 입력으로 받을 수 있는 통합 지점을 마련하면 nfield처럼 입력 타입을 그대로 활용해 기존 코드와 호환성을 유지할 수 있다. 테스트 단계에서는 필드 수를 50개 이하와 초과 구간으로 나눠 단일 호출과 분할 호출의 성능 차이를 비교해 분할 적용 임계값을 실험적으로 확인해야 한다. 벤치마크는 같은 모델과 동일한 문서셋으로 반복 실행하여 결과의 일관성을 검증하는 것이 중요하다.

Token limit

— 모델이 한 번의 호출 또는 응답에서 처리할 수 있는 토큰 수의 상한으로, 입력·출력 합계가 이 한도를 넘으면 출력이 잘리거나 에러가 발생한다. 긴 문서나 넓은 스키마를 다룰 때 호출을 나누는 기준이 되며 모델 선택과 호출 분할 전략에 직접 영향을 준다.

Schema splitting

— 전체 JSON 스키마를 여러 개의 작은 작업 단위로 나누어 각 호출이 모델의 토큰 한도 안에 들어가도록 하는 기법으로, 모델 출력이 중간에서 잘려 전체 결과가 무효화되는 문제를 회피한다. 분할 후에는 각 호출 결과를 재조합해 원래의 중첩 구조를 복원하는 후처리가 필요하다.

Pydantic

— Python 데이터 검증 및 설정 라이브러리로, 타입 선언에 따라 구조화된 모델을 정의하고 JSON 직렬화/역직렬화를 지원한다. 게시물에서는 nfield가 dict, Pydantic 모델, dataclass 입력을 받아 기존 파이프라인에 쉽게 통합되는 점을 강조하는 맥락에서 언급됐다.

Flat path serialization

— 중첩된 JSON 구조 대신 'path = value' 형태의 평탄한 라인 단위 출력으로 각 필드를 독립적으로 출력하게 하는 직렬화 방식으로, 출력이 중간에 잘려도 해당 라인만 손실되며 전체 문서가 무효화되는 확률을 낮춘다. 이후 코드에서 경로 표기를 따라 중첩 구조로 재구성한다.