LLM 응답의 불확실성을 극복하는 기술적 정공법

거대언어모델(LLM)을 활용한 서비스 구축 시 개발자들이 직면하는 가장 흔하면서도 치명적인 문제는 JSON 파싱 오류입니다. 특히 'Unterminated string in JSON' 에러는 모델이 응답 도중 토큰 제한에 걸려 문자열을 닫지 못하거나, 보이지 않는 제어 문자가 포함될 때 발생합니다. 이를 해결하기 위한 가장 직접적인 방법은 출력 전 단계에서 제어 문자를 필터링하는 미들웨어를 배치하고, 토큰 여유분을 강제하는 린터(Linter) 룰을 시스템에 내재화하는 것입니다. Agent 8은 단순히 에러를 보고하는 것에 그치지 않고, 시스템이 스스로 코드를 수정하고 규칙을 업데이트하는 'Living Software' 원칙에 따라 이 문제를 해결했습니다.

본 아티클에서는 Agent 8 팀이 최근 겪었던 Unterminated string in JSON at position 5251 오류를 어떻게 분석하고, 이를 원천적으로 차단하기 위해 어떤 아키텍처적 결단을 내렸는지 상세히 공유합니다.

1. 문제의 본질: 왜 JSON은 깨지는가?

MoE(Mixture of Experts) 아키텍처나 복잡한 에이전트 워크플로우에서 LLM은 구조화된 데이터를 생성하도록 요청받습니다. 하지만 다음과 같은 상황에서 JSON은 무너집니다.

• 토큰 절단(Truncation): 모델의 최대 출력 토큰 수에 도달하여 JSON의 닫는 기호(], })가 생성되지 못함.
• 특수 문자 이스케이프 누락: 문자열 내부에 줄바꿈, 탭, 혹은 유니코드 제어 문자가 포함되어 표준 JSON 파서가 이를 해석하지 못함.
• 비결정적 특성: 동일한 프롬프트라도 확률적 생성 과정에서 예기치 않은 문자가 삽입됨.

"단순한 재시도(Retry)는 임시방편일 뿐입니다. 시스템의 런타임이 데이터의 무결성을 스스로 검증하고 정제할 수 있는 방어 로직을 갖추어야만 진정한 Living Software라 할 수 있습니다." — Andrew, Agent 8 Lead

2. 실시간 데이터 정제를 위한 safeJSONStringify 미들웨어

Agent 8의 개발 파트너 카이(Kai)는 출력 버퍼 단계에서 작동하는 safeJSONStringify 미들웨어를 제안했습니다. 이 로직의 핵심은 JSON 파싱을 방해하는 유니코드 제어 문자 범위(\u0000-\u001F, \u007F-\u009F)를 정규표현식으로 제거하고, 직렬화 실패 시 안전한 폴백(Fallback) 데이터를 반환하는 것입니다.

// middleware/jsonValidator.js
export function safeJSONStringify(obj) {
  try {
    return JSON.stringify(obj, (key, value) => {
      if (typeof value === 'string') {
        // JSON 파싱을 방해하는 제어 문자 및 이스케이프 오류 유발 문자 제거
        return value.replace(/[\u0000-\u001F\u007F-\u009F]/g, '');
      }
      return value;
    });
  } catch (error) {
    console.error('JSON Stringify Error:', error);
    return '[{"partnerId":"dev","role":"contributor","content":"Fallback: JSON serialization failed."}]';
  }
}

이 미들웨어는 에이전트가 생성한 원시 문자열이 API 응답으로 나가기 직전, 메모리 상에서 즉각적으로 정제 작업을 수행합니다. 이는 프론트엔드에서 발생할 수 있는 렌더링 크래시를 원천적으로 차단하는 효과를 가져옵니다.

3. 정책적 방어: YAML 기반 출력 린터(Linter) 도입

코드 레벨의 정제뿐만 아니라, 기획 단계에서의 '안전장치'도 중요합니다. 다니(Dani) 파트너는 토큰 절단 문제를 해결하기 위해 시스템 설정 파일에 직접 린터 규칙을 주입했습니다. 이 규칙은 모든 JSON 출력이 반드시 유효한 기호로 종료되어야 함을 명시하며, 출력 시 500 토큰 정도의 여유 버퍼를 강제합니다.

# config/output_linter_rule.yml
output_rules:
  - rule_id: strict-json-termination
    description: "모든 JSON 출력은 반드시 유효한 배열 닫기 기호 ']'로 종료되어야 함."
    enforcement: strict
    max_tokens_buffer: 500
    fallback_strategy:
      action: retry
      max_attempts: 2
      on_fail: "trigger_safe_fallback_json"

이러한 설정은 시스템이 스스로를 감시하게 만듭니다. 만약 모델이 응답을 끝내지 못할 것으로 예상되면, 시스템은 내부적으로 retry를 수행하거나 안전한 형태의 기본 JSON을 반환하여 전체 파이프라인의 중단을 막습니다.

4. Living Software: 자가 복구하는 시스템의 가치

이번 업데이트의 진정한 가치는 '문제 발견 -> 논의 -> 코드 자동 생성 -> 시스템 반영'의 전 과정이 에이전트들 사이의 협업으로 이루어졌다는 점에 있습니다. 렉스(Lex)의 보안 및 무결성 검토를 거쳐 최종 승인된 이 솔루션은 Agent 8이 단순한 챗봇이 아니라, 스스로의 취약점을 보완하며 진화하는 소프트웨어임을 증명합니다.

자주 묻는 질문 (FAQ)

Q1. JSON 파싱 에러가 발생했을 때 단순히 다시 생성(Retry)하는 것과 무엇이 다른가요?

A1: 단순 재시도는 비용과 시간이 소모되며, 동일한 오류가 반복될 확률이 높습니다. Agent 8의 방식은 safeJSONStringify를 통해 원인이 되는 특수 문자를 즉각 제거하고, 린터 룰을 통해 토큰 부족 현상을 사전에 방지하므로 훨씬 결정적(Deterministic)이고 효율적인 해결책을 제공합니다.

Q2. 제어 문자를 제거하면 데이터의 실제 내용이 변질될 우려가 없나요?

A2: 제거 대상인 \u0000-\u001F 범위의 문자들은 대부분 텍스트의 의미 전달에 불필요한 비가시적 제어 문자들입니다. 핵심 정보는 보존하면서 JSON 규격에 어긋나는 노이즈만 제거하기 때문에 데이터의 비즈니스적 가치는 훼손되지 않습니다.

결론: 엔터프라이즈 급 AI 서비스를 향한 여정

안정적인 API 응답은 B2B 고객사 연동이나 대규모 서비스 운영에서 타협할 수 없는 요소입니다. Agent 8 팀은 이번 'Unterminated string' 이슈 해결을 통해, LLM의 비결정성을 엔지니어링의 힘으로 제어할 수 있음을 보여주었습니다. 우리는 앞으로도 시스템의 무결성을 지키기 위해 코드로 대화하고, 로직으로 증명하는 Living Software의 길을 걸어갈 것입니다.