6.2.3 필수 필드(Required Fields)와 선택 필드(Optional Fields)의 전략적 분리

6.2.3 필수 필드(Required Fields)와 선택 필드(Optional Fields)의 전략적 분리

JSON Schema를 작성할 때 개발자는 객체 내의 어떤 속성값(Property)이 반드시 존재해야 하는지 required 배열을 통해 명시할 수 있다. 여기에 명시되지 않은 필드들은 자연스럽게 ’선택 필드(Optional Fields)’가 된다.

거대 언어 모델(LLM) 기반의 결정론적 오라클을 설계할 때, 필수 필드와 선택 필드의 철학은 일반적인 데이터베이스 설계 철학과 완전히 다르게 접근해야 한다. 결론부터 말하자면, AI 파이프라인에서 단순한 의미의 선택 필드(Optional Field)는 가능하면 모조리 제거하고 모든 필드를 필수 필드로 승격시켜 뼈대의 변동성을 없애야 한다.

1. 선택 필드(Optional Fields)가 유발하는 ’키 누락(Key Omission)’의 공포

전통적인 API 구조에서는 데이터 전송량을 줄이기 위해, 값이 없으면 아예 JSON 페이로드에서 해당 키(Key)를 생략해 버리는 것이 관례다.

그러나 LLM에게 이를 허용하는 순간 결정론적 파서는 지옥을 맛보게 된다.
만약 문서 요약 봇에게 {"summary": "...", "author": "..."}라는 스키마를 주면서 author를 선택 필드로 두었다고 가정해 보자. 문서에 저자가 명시되어 있지 않을 때, LLM은 다음과 같이 변덕을 부린다.

  • A 패턴: 똑똑하게 author 키를 생략하고 {"summary": "..."} 만 반환한다.
  • B 패턴: 저자가 없다는 것을 알리기 위해 멋대로 {"summary": "...", "author": "없음"} 이라고 생성한다.
  • C 패턴: 빈 문자열을 넣어 {"summary": "...", "author": ""} 라고 생성한다.

백엔드 모델 파서(예: 파이썬의 Pydantic 등) 입장에서는, 키가 아예 없는 것(KeyError)과 빈 문자열인 것의 분기 처리를 일일이 해주어야 하는 소프트웨어의 취약성(Brittleness)이 발생한다.

2. 모든 필드의 필수화(Required)와 명시적 Null (Explicit Null)

따라서 오라클 시스템을 구축하는 엔지니어는 LLM이 키(Key)의 존재 여부를 스스로 결정하게 내버려 두어서는 안 된다. 모든 DTO의 뼈대는 100% 동일한 개수의 키를 가져야 한다.

이를 구현하는 완벽한 설계 패턴이 바로 모든 속성을 required 배열에 몰어넣되, 해당 속성의 타입에 **명시적 Null(Explicit Null)**을 허용하는 것이다.

{
  "type": "object",
  "properties": {
    "summary": { "type": "string" },
    "author": { 
      "type": ["string", "null"],
      "description": "문서의 저자. 문서 내에서 저자를 찾을 수 없다면 절대 지어내지 말고 null을 반환하라."
    }
  },
  "required": ["summary", "author"]
}

이 패턴을 적용하면, 문서에 저자가 없을 때 LLM은 키를 삭제하는 대신 {"summary": "...", "author": null}을 반환하도록 수학적으로 강제된다.

이 설계가 가져오는 효과는 압도적이다. 백엔드 시스템은 항상 response.get("author")가 안전하게 존재할 것임을(적어도 KeyError는 발생하지 않음을) 100% 신뢰할 수 있으며, 단지 그 값이 null인지 아닌지만 체크(if response.author is None:)하면 되는 지극히 평범하고 결정론적인 소프트웨어 로직으로 회귀하게 된다.

3. 강제성의 역효과 방어

주의할 점은, null을 허용하지 않고 모든 것을 필수적인 문자열이나 숫자로 꽉 채워(Required + No Null) 버릴 경우 발생하는 부작용이다.

만약 저자가 기재되지 않은 문서를 던져주면서 "author": {"type": "string"}만을 필수 필드로 강제한다면, LLM은 구조 파괴를 피하기 위해 필사적으로 “알 수 없음”, “Anonymous”, 혹은 지어낸 허구의 이름(사실적 환각)을 텍스트로 채워 넣게 된다. 시스템의 구조는 지켰지만 데이터의 진실성이 훼손된 것이다.

따라서 ‘필수 필드 + 명시적 Null 허용’ 구조는, 구조론적 결정성을 100%로 보존하면서도 모델에게 **‘모른다고 대답할 수 있는 합법적 도피처(Escape Hatch)’**를 제공하는 가장 정교하고 실용적인 스키마 설계 전략이다.