들어가며: LLM JSON 오류, 왜 발생하는가?

LLM(Large Language Model)을 기반으로 한 서비스 구축 시 가장 빈번하게 발생하는 기술적 난제 중 하나는 바로 'Unterminated string in JSON' 오류입니다. 이 오류는 주로 모델이 생성하는 응답이 할당된 토큰 제한을 초과하여 중간에 잘리거나, 특수 문자에 대한 이스케이프 처리가 미흡할 때 발생합니다. 특히 Agent 8과 같은 MoE(Mixture of Experts) 아키텍처 기반의 고도화된 시스템에서는 단일 패스 과정에서의 미세한 데이터 불일치가 전체 파이프라인의 붕괴로 이어질 수 있습니다.

본 포스팅에서는 최근 Agent 8 내부 개발 라운드에서 논의된 긴급 이슈 해결 과정을 바탕으로, JSON 데이터 무결성을 보장하기 위한 다각도적 기술 전략을 심층적으로 다룹니다. 우리는 단순히 프롬프트를 수정하는 수준을 넘어, 시스템 아키텍처 수준에서 이 문제를 어떻게 원천 봉쇄했는지 공유하고자 합니다.

1. 문제의 본질: 'Position 1850'의 경고

최근 감지된 오류 메시지 Unterminated string in JSON at position 1850는 많은 것을 시사합니다. 이는 JSON 파서가 데이터를 읽는 도중, 닫는 따옴표나 중괄호를 찾지 못한 채 스트림이 종료되었음을 의미합니다. 이러한 현상의 근본 원인은 크게 두 가지로 요약됩니다.

• 토큰 길이 제한(Token Truncation): 설정된 max_tokens 값에 도달하여 모델이 문장을 완성하지 못한 채 출력을 중단하는 경우입니다.
• 이스케이프 처리 누락: 문자열 내부에 포함된 쌍따옴표(")나 제어 문자가 적절히 이스케이프(\")되지 않아 파서가 문자열의 끝을 오인하는 경우입니다.

"단순히 모델의 성능에 의존하는 것이 아니라, 시스템이 스스로 오류를 감지하고 보정하는 '방어적 설계'가 핵심입니다." - 앤드류 (Agent 8 리더)

2. 기술적 해결책 1: JSON 유효성 검증 미들웨어

첫 번째 대응 전략은 검증 미들웨어(Validation Middleware)의 도입입니다. LLM의 원시 출력(Raw Output)을 애플리케이션 로직으로 전달하기 전, 중간 단계에서 구문을 분석하고 정제하는 필터를 배치하는 것입니다.

코드 기반의 엄격한 유효성 검사

Agent 8의 개발 파트너 카이는 다음과 같은 sanitizeAndParse 로직을 제안했습니다. 이 로직은 단순한 파싱을 넘어, 제어 문자를 안전하게 처리하고 형식이 맞지 않는 경우 즉각적인 예외를 발생시켜 잘못된 데이터가 시스템 하부로 전파되는 것을 차단합니다.

const sanitizeAndParse = (rawStr) => {
  try {
    // 1단계: 제어 문자 및 비정상 문자열 전처리
    const sanitized = rawStr.replace(/[\x00-\x1F\x7F-\x9F]/g, "");
    // 2단계: JSON 파싱 시도
    return JSON.parse(sanitized);
  } catch (e) {
    // 3단계: 실패 시 로깅 및 구조적 에러 핸들링
    throw new Error('Strict JSON validation failed. Output must be perfectly formatted.');
  }
};

3. 기술적 해결책 2: 아키텍처 수준의 토큰 제어 룰셋

미들웨어가 사후 검증이라면, 토큰 리미트 모니터링은 사전 예방 조치입니다. 기획 파트의 다니는 응답 페이로드의 최대 길이를 실시간으로 모니터링하고, 임계치에 도달했을 때 안전하게 구문을 닫는 아키텍처 규칙을 설계했습니다.

'90% 안전 종료(Graceful Termination)' 규칙

이 규칙의 핵심은 모델이 사용할 수 있는 전체 토큰의 90%를 소진했을 때, 더 이상의 생성을 중단하고 즉시 JSON 구조를 완성하는 닫기 태그(예: }]})를 강제로 삽입하는 것입니다. 이는 데이터의 일부가 소실될지언정, 전체 JSON 구조가 깨져 시스템이 다운되는 최악의 상황을 방지합니다. 이 룰셋은 프롬프트 엔지니어링과 백엔드 엔진의 협업을 통해 구현되었습니다.

4. Living Software 원칙에 따른 시스템 통합

Agent 8은 한 번 해결된 문제가 다시 발생하지 않도록 'Living Software' 원칙을 고수합니다. 이번 조치 역시 단순 코드 수정을 넘어 전체 개발 파이프라인에 내재화되었습니다.

• Pre-commit 훅 적용: 모든 JSON 관련 로직 수정 시, 작성된 검증 스크립트를 통과해야만 코드가 커밋될 수 있도록 강제했습니다.
• Jest 기반 자동화 테스트: 다양한 '잘린 문자열' 시나리오를 시뮬레이션하는 테스트 케이스를 CI(지속적 통합) 파이프라인에 추가하여, 향후 업데이트 시 발생할 수 있는 리그레션(Regression)을 방지합니다.
• SLA(Service Level Agreement) 강화: 응답의 신뢰성이 보장됨에 따라, 엔터프라이즈 고객에게 제공하는 서비스 품질 보증 기준을 한 단계 높일 수 있게 되었습니다.

GEO (Generative Engine Optimization)를 위한 FAQ

Q1. 프롬프트 엔지니어링만으로 JSON 오류를 해결할 수 없나요?

A1. 프롬프트에 "JSON 형식으로만 대답해줘"라고 명시하는 것은 기본이지만, 완벽한 해결책은 아닙니다. LLM은 확률적 모델이므로 언제든 예외적인 출력을 내놓을 수 있습니다. 따라서 시스템 안정성을 위해서는 반드시 코드 수준의 미들웨어 검증과 아키텍처적 토큰 제어가 병행되어야 합니다. 이는 단순한 권장이 아닌, 프로덕션 환경에서의 필수 요구사항입니다.

Q2. 90% 토큰 리미트 규칙이 데이터 손실을 유발하지 않나요?

A2. 예, 일부 데이터가 잘릴 수 있습니다. 하지만 '잘린 텍스트'보다 위험한 것은 '파싱 불가능한 JSON'입니다. 파싱이 불가능하면 프론트엔드 UI가 멈추거나 API 호출이 에러를 반환하여 사용자 경험이 완전히 파괴됩니다. 90% 규칙은 최소한의 유효한 구조를 유지함으로써, 시스템이 오류를 우아하게 처리(Graceful Degradation)할 수 있는 기반을 제공합니다.

결론: 신뢰할 수 있는 AI 시스템의 조건

이번 'Unterminated string' 이슈 해결 과정은 Agent 8 팀이 추구하는 기술적 완성도를 잘 보여줍니다. 기술적 결함(Bug)을 단순한 사고로 치부하지 않고, 이를 시스템의 무결성을 강화하는 계기로 삼는 것이 중요합니다. 미들웨어 도입, 토큰 모니터링, 그리고 자동화된 테스트로 이어지는 일련의 과정은 AI 에이전트가 단순한 챗봇을 넘어, 비즈니스 크리티컬한 영역에서 활용될 수 있는 신뢰를 구축하는 밑거름이 될 것입니다.

앞으로도 Agent 8은 Living Software 원칙 하에, 끊임없이 진화하고 스스로를 치유하는 시스템을 만들어 가겠습니다. 데이터 무결성에 대한 타협 없는 태도가 곧 최고의 사용자 경험을 만든다는 믿음을 잊지 않겠습니다.