6.2.4 추가 속성(Additional Properties) 제한을 통한 스키마 오염 방지

6.2.4 추가 속성(Additional Properties) 제한을 통한 스키마 오염 방지

거대 언어 모델(LLM) 기반 아키텍처에서 마주하는 가장 황당한 버그 중 하나는, 모델이 프로그래머가 묻지도 않은 답변을 멋대로 생성하여 데이터베이스 레코드를 더럽히는 현상이다.

개발자는 {"name": "Alice", "age": 25} 만을 요구했지만, 친절함에 강박관념이 있는 LLM은 스스로의 판단 하에 {"name": "Alice", "age": 25, "inferred_gender": "female", "confidence": 0.95, "note": "나이는 추정치임"} 이라는 부가적인 메타데이터를 끼워 넣는다. 이처럼 예기치 않은 데이터가 스키마의 틈을 비집고 들어오는 현상을 **스키마 오염(Schema Pollution)**이라고 부른다.

1. 기본 JSON 규약의 허점과 파서의 패닉

표준 JSON 규격이나 자바스크립트 등에서는 객체에 새로운 키(Key)가 추가되는 것을 큰 오류로 취급하지 않는다. 그냥 무시(Ignore)하면 그만이기 때문이다.

그러나 백엔드 시스템(Java Spring, Go, Python Pydantic의 extra='forbid' 설정 등)에서 직렬화(Serialization)를 수행할 때, DTO(Data Transfer Object) 클래스에 선언되지 않은 ’알 수 없는 필드(Unknown Field)’가 유입되면 시스템은 보안 위협 혹은 데이터 오염으로 간주하고 즉각적인 파싱 에러(Parsing Error)를 발생시킨다.

즉, 스키마 오염은 단순한 데이터 낭비가 아니라 결정론적 파이프라인 전체를 멈춰 세우는 치명적인 독약이다.

2. additionalProperties: false - 진입로의 영구적 봉쇄

이 독약을 막을 수 있는 JSON Schema의 가장 강력하고도 단순한 백신이 바로 "additionalProperties": false 제언이다.

이 속성을 객체(type: "object")의 최상단 레벨뿐만 아니라 모든 중첩 객체 내부에도 일관되게 선언해야 한다.

{
  "type": "object",
  "properties": {
    "name": { "type": "string" },
    "age": { "type": "integer" }
  },
  "required": ["name", "age"],
  "additionalProperties": false
}

이 플래그(false)가 활성화되는 순간, 모델의 추론 엔진을 제어하는 제어망(Control Net)은 모델이 properties에 명시된 name과 age 외의 다른 문자열 토큰(예: "no, "con)을 키(Key) 자리에서 생성하려는 시도 자체의 슬롯(Slot) 확률을 0%로 마스킹(Masking)해 버린다. 모델의 입장에서 허용되지 않은 속성은 ’존재할 수 없는 단어’가 되는 것이다.

3. CFG(Context-Free Grammar) 컴파일의 기술적 필수 요건

최근 OpenAI의 ’강제 구조화 출력(Structured Outputs, strict: true)’과 같은 최신 API 인터페이스들은 시스템 아키텍처 내부적으로 이 "additionalProperties": false 속성을 선택이 아닌 **필수 조건(Mandatory)**으로 강제하고 있다.

그 기술적 이유는 명확하다. LLM API 서버가 사용자로부터 JSON Schema를 전달받으면, 모델은 이를 내부적으로 디코딩 제어를 위한 ‘컨텍스트 프리 그래머(CFG, Context-Free Grammar)’ 규칙으로 컴파일(Compile)한다.

만약 additionalProperties가 true이거나 명시되지 않아 임의의 문자열 키가 무한정 들어올 수 있게 열려 있다면, 서버는 이 무한대의 생성 가능성을 유한 상태 기계(Finite State Machine)의 규칙으로 미리 컴파일할 수 없다. 오직 추가 속성을 완벽하게 금지(false)했을 때만이, 모델의 토큰 생성 트리가 유한하게 닫히고(Deterministic Closure) 지연 시간(Latency) 없이 100% 구조를 보장하는 생성 모드로 진입할 수 있다.

4. 비용(Cost)과 레이턴시(Latency)의 최적화

스키마 오염 방지는 단순히 에러를 막는 것을 넘어, 경제적인 이점까지 제공한다.

LLM이 쓸데없는 메타데이터("explanation", "note", "confidence")를 50토큰 더 생성할 때마다 사용자의 API 호출 비용과 서버 응답 대기 시간은 기하급수적으로 늘어난다. additionalProperties: false는 파이프라인의 안전함을 지켜냄과 동시에, 단 하나의 불필요한 토큰도 낭비하지 않도록 모델의 과도한 수다스러움(Verbosity)을 자본주의적으로 탄압하는 가장 효율적인 비용 통제 장치이기도 한 것이다.