70B 모델로 엄격한 JSON 스키마 유효성 확보한 운영 경험

커뮤니티는 실무적 수치와 운영 흐름에 대해 실용성을 크게 인정했고 추가적인 개선 방안을 묻는 반응이 많았다. 일부는 재시도 로직을 더 세분화하거나 출력 안내를 보다 구조화된 템플릿으로 바꿔 잔여 실패를 줄이는 사례를 공유했고 다른 이들은 Outlines나 LMQL 같은 출력 유도 도구를 도입해본 경험을 언급했다. 전반적으로 경험 공유는 공감과 실무적 질문을 동시에 유발했고 더 정교한 자동 교정 기법에 대한 관심으로 이어졌다.

• LLM을 JSON으로 안정화하려면 출력 규격을 호출 시점에 명확히 고정하고 런타임에서 엄격한 스키마 검증을 실행하는 것이 우선이다. 구체적으로는 JSON 모드로 모델을 호출해 디코딩 단계의 불확실성을 줄이고, 파싱 실패 시 원시 출력을 로그로 보존해 오류 패턴을 분석해야 한다. 이 흐름은 장애 원인 파악과 장기적 품질 개선에 필수적이다.
• 검증 실패 처리로는 검증 에러를 프롬프트에 포함해 한 번만 재시도하는 정책이 실무에서는 균형점으로 작동했다. 재시도 시에는 어떤 필드에서 어떤 타입 오류가 났는지 명시적으로 전달해 모델이 동일한 실수를 반복할 확률을 낮춰야 한다. 반복 재시도를 무제한으로 늘리면 지연과 비용이 급증하므로 고정된 재시도 횟수와 정적 페일백 조합이 현실적인 선택이다.
• 이모지와 과도하게 긴 텍스트 필드는 별도 전처리 규칙이나 포스트프로세싱을 적용해 처리해야 한다. 예컨대 이모지는 유니코드 제거 또는 이스케이프 규칙을 적용하고, 긴 필드는 요약해서 넣거나 외부 스토리지 레퍼런스로 교체하는 방식으로 파싱 실패를 예방할 수 있다. 이러한 전처리 규칙은 스키마 설계 단계에서 필드별 허용 범위를 명문화해 자동화해야 실무적 안정성이 확보된다.

JSON mode

— 모델이 출력 형식을 엄격한 JSON으로 제한하도록 하는 호출 설정으로, 토큰 생성 규칙을 제약해 파싱 실패를 줄이는 방식이며 스키마 기반 검증과 결합하면 출력 일관성을 크게 높일 수 있어 프로덕션 파이프라인에서 유효성 보장에 중요한 역할을 한다.

Zod

— TypeScript 생태계의 런타임 스키마 검증 라이브러리로, JSON 객체를 선언적 스키마로 정의한 뒤 검증 결과와 에러 메시지를 반환하여 모델 출력의 구조적 일관성과 필드별 오류 원인을 빠르게 식별할 수 있게 한다.

Retry loop

— 모델 출력이 스키마 검증을 통과하지 못할 때 실패 원인을 프롬프트로 되돌려 한 번 더 생성하도록 요청하는 제어 흐름으로, 오류 유형을 명시적으로 모델 입력에 포함해 같은 실수를 반복할 확률을 낮추는 운영 기법이다.