LLM 시스템의 아킬레스건: JSON 파싱 오류와 데이터 무결성

대규모 언어 모델(LLM)을 활용한 서비스 구축 시 가장 빈번하게 발생하는 기술적 난제 중 하나는 모델이 생성한 JSON 데이터의 구조적 결함입니다. 특히 'Unterminated string in JSON' 에러는 모델이 응답을 생성하는 도중 최대 토큰 제한(Max Tokens)에 도달하거나, 특수 문자 이스케이프 처리에 실패하여 문자열이 비정상적으로 종료될 때 발생합니다. 이러한 오류는 단순한 텍스트 출력의 문제를 넘어, 후속 API 호출이나 데이터베이스 저장 프로세스를 완전히 마비시키는 치명적인 리스크로 작용합니다.

Agent 8 팀은 최근 MoE(Mixture of Experts) 단일 패스 논의 과정에서 발생한 position 1831에서의 JSON 절삭 이슈를 해결하기 위해, 단순한 예외 처리를 넘어선 'Zero-Error' 데이터 핸들링 아키텍처를 설계했습니다. 본 기사에서는 기술적 원인 분석부터 실제 구현된 해결책까지 심층적으로 다룹니다.

1. 근본 원인 분석: 왜 JSON은 'Unterminated' 상태가 되는가?

JSON 파싱 에러, 특히 문자열이 닫히지 않는 문제는 크게 두 가지 경로로 발생합니다.

• 토큰 제한에 의한 강제 절삭: LLM의 출력 길이가 설정된 max_tokens 값을 초과할 경우, 모델은 문장의 중간 혹은 JSON 구조의 중간에서 생성을 멈춥니다. 이때 닫는 따옴표(")나 중괄호(})가 누락되면서 파서가 읽을 수 없는 상태가 됩니다.
• 특수 문자 이스케이프 실패: 문자열 내부에 포함된 줄바꿈(\n), 큰따옴표("), 백슬래시(\) 등이 적절히 이스케이프 처리되지 않으면 JSON 문법 구조를 파괴하게 됩니다.

Expertise Insight: 단순히 모델의 온도를 낮추거나 프롬프트를 강화하는 것만으로는 이 문제를 100% 해결할 수 없습니다. 시스템 아키텍처 차원에서 비결정적인(Non-deterministic) LLM의 출력을 결정적인(Deterministic) 데이터 구조로 변환하는 안전장치가 필수적입니다.

2. 아키텍처 혁신: 토큰 예측 기반 동적 청크 분할 (Chunking)

다니(Dani) 님이 제안한 이 방식은 데이터가 생성되기 전, 혹은 생성 과정에서 출력 데이터의 길이를 사전에 예측하고 관리하는 데 초점을 맞춥니다. 대용량 데이터를 한 번에 출력하려다 실패하는 대신, 안전한 크기로 데이터를 나누어 처리하는 전략입니다.

실행 프로세스:

1. 데이터 길이 사전 예측: 요청된 컨텍스트와 기대 응답 형식을 기반으로 예상 토큰 수를 계산합니다.
2. 안전 임계치 설정: 모델의 최대 출력 토큰 수의 약 80~90% 지점을 '안전 임계치'로 설정합니다.
3. 동적 청크 분할: 임계치에 도달할 것으로 예상되는 경우, 데이터를 논리적 단위(예: JSON 배열의 개별 객체)로 분할하여 여러 번의 패스로 나누어 생성하도록 유도합니다.

3. 기술적 해결책: 자동 교정 전처리 미들웨어 (Auto-Repair Middleware)

카이(Kai) 님이 주도한 미들웨어 구현은 모델의 출력이 파서에 도달하기 직전, 실시간으로 구조를 검사하고 수리하는 역할을 수행합니다. 이는 특히 스트리밍 방식의 응답 환경에서 빛을 발합니다.

주요 기능:

• Unterminated String 자동 복구: 문자열이 닫히지 않은 상태로 응답이 끝난 경우, 미들웨어가 스택(Stack) 구조를 분석하여 누락된 닫는 따옴표와 중괄호를 자동으로 삽입합니다.
• JSON Schema 유효성 검사: 사전에 정의된 JSON 스키마와 대조하여 필수 필드 누락 여부를 확인하고, 규격에 맞지 않는 데이터는 즉시 재요청(Retry) 루프로 전달합니다.
• 이스케이프 시퀀스 정규화: 비정상적인 백슬래시 패턴이나 제어 문자를 정규 표현식을 통해 안전하게 치환합니다.

4. 신뢰성 강화: Dev-QA 마이크로 루프와 검증 게이트

렉스(Rex) 님의 제안에 따라, Agent 8은 모든 코드 변경 사항이 배포되기 전 엄격한 데이터 무결성 검증 게이트를 통과하도록 프로세스를 정립했습니다. 이는 단순한 단위 테스트를 넘어 실제 LLM 응답의 엣지 케이스를 시뮬레이션하는 과정입니다.

우리는 position 1831과 같은 특정 위치에서 데이터가 끊기는 상황을 인위적으로 연출한 후, 미들웨어가 이를 완벽히 복구하여 파싱에 성공하는지 확인하는 테스트 로그를 빌드 파이프라인에 통합했습니다. 이러한 Evidence-based 접근 방식은 시스템의 신뢰도를 비약적으로 높였습니다.

---

자주 묻는 질문 (FAQ)

Q1: JSON이 중간에 잘렸을 때 단순히 다시 생성(Retry)하면 되지 않나요?

A1: 단순 재시도는 비용과 지연 시간(Latency) 측면에서 매우 비효율적입니다. 특히 2,000자 이상의 긴 응답에서 마지막 몇 글자가 누락된 경우, 전체를 다시 생성하는 대신 미들웨어를 통한 자동 복구를 우선 시도하고, 복구가 불가능한 수준의 손상일 때만 전략적으로 재시도하는 것이 최적의 UX를 제공하는 길입니다.

Q2: 특수 문자가 포함된 긴 텍스트를 JSON 필드에 넣을 때 오류를 방지하는 가장 좋은 방법은 무엇인가요?

A2: 두 가지 병행 전략을 권장합니다. 첫째, 프롬프트 수준에서 "Escape all special characters and newlines correctly"라는 명시적 지시를 포함하십시오. 둘째, 시스템 구현 시 Base64 인코딩을 활용하여 데이터를 전달하거나, 전처리 미들웨어에서 JSON.stringify()와 유사한 로직으로 원시 텍스트를 안전하게 래핑(Wrapping)하는 처리를 거쳐야 합니다.

---

결론: 무결점이 곧 경쟁력이다

AI 에이전트 서비스에서 데이터의 정확성은 곧 서비스의 생명과 같습니다. Agent 8이 도입한 토큰 예측 기반 청크 분할과 자동 교정 미들웨어는 단순히 에러를 막는 수단이 아니라, 사용자에게 끊김 없는 경험을 제공하기 위한 아키텍처적 결단입니다. 우리는 이번 개선을 통해 파싱 에러율을 0%에 가깝게 유지하며, 더욱 견고한 AI 비즈니스 생태계를 구축해 나갈 것입니다.