형식 검증을 통과한 값이 저장소에서 거부될 수 있다
주장
입력 검증의 기준을 “모양이 계약과 같은가”에서 멈추지 않고 “이 값이 저장소에 실제로 담기는가”까지 넓힌다. 타입·길이·필수 여부가 전부 맞아도 저장 계층이 거부하는 값의 부류가 따로 있다.
NUL 입력이 드러낸 저장소 제약
- PostgreSQL의
text·jsonb는 NUL(0x00)을 담지 못한다. 원문 프로젝트에서psycopg.DataError/psycopg.errors.UntranslatableCharacter로 실측했다. - JSON 스펙이
"\u0000"이스케이프를 허용하고 파서가 이를 실제 NUL 문자로 만들므로, 파서를 거친 외부 입력(LLM 출력 포함)에서 도달 가능한 값이다. - Vigilantis에서는 형식 검증 계층을 통과한 NUL이 저장소 조회 단계에서야 드라이버 예외로 드러났다 — 거절 기록 없이 예외로 끝나는 경로였다.
저장소 접근 전에 거절을 기록하기
- 저장 계층의 제약(문자 집합·인코딩·길이)을 검증 계층의 규칙에 함께 싣는다.
- 담기지 않는 값의 판정을 저장소 접근 앞에 둔다.
- 저장 불가 값은 예외가 아니라 정상 거절 사유 코드로 기록한다 — 방어가 있어도 기록이 없으면 운영자에게는 없는 것과 같다.
- 집합·사전형 Test Double은 무엇이든 받아 이 차이를 감춘다. 실제 저장소로 한 번은 확인한다.
적용 범위와 한계
모든 저장소 제약을 검증 계층에 복제하자는 원칙이 아니다. 신뢰할 수 없는 출처의 입력이 지나는 경로에서, 거부가 예외로만 드러나는 제약을 골라 판정을 앞당긴다.
승격 원문
C:/labs/team/vigilantis/obsidian-vault/40 Knowledge/Atomic/형식 검증을 통과한 값이 저장소에서 거부될 수 있다.md