JSON 컬럼에 새 필드를 넣으면 스키마 변경 없이 배포할 수 있나요? 읽기·인덱스·검증은 어떻게 유지하나요?

JSON은 필드 추가의 물리적 유연성을 주지만 데이터 의미와 소비자의 계약을 없애지 않습니다. 필수값·타입·버전·기본값을 정하고 구·신 코드가 혼합된 기간의 읽기·쓰기를 검증해야 합니다.

동작 원리와 전제

금액을 숫자로 저장하다 문자열로 바꾸면 파싱·정렬·집계가 달라집니다. 필드 생략과 JSON null, SQL NULL의 차이도 확인합니다. 자주 검색하는 속성은 expression index·생성 컬럼·정규 컬럼 중 실제 접근 비용에 맞춰 선택합니다.

선택과 실패 처리

문서 전체를 읽고 한 필드만 수정해 다시 쓰면 다른 요청의 변경을 덮을 수 있습니다. 원자적인 경로 갱신이나 문서 버전 조건이 필요한지 봅니다. 관계·유일성·참조 제약이 중요하면 JSON 안에 넣었다고 자동 강제되지 않으므로 저장 구조를 다시 검토합니다.

구체적인 사례와 검증

예를 들어 status가 문자열에서 객체 {code, reason}으로 바뀌면 같은 JSON 컬럼이지만 옛 소비자는 더 이상 읽지 못할 수 있습니다. 새 표현을 먼저 추가하고 구·신 읽기 호환과 백필·쓰기 전환을 나눕니다. JSON 경로를 직접 인덱싱하는 질의도 새 구조를 따라 바뀌어야 합니다. 전체 문서를 저장하는 PUT형 갱신과 부분 patch형 갱신의 의미를 API에서 구분합니다. 사용자가 주지 않은 필드를 삭제할지 유지할지 명확하지 않으면 동시 변경뿐 아니라 일반 요청도 데이터를 잃습니다. 문서 크기 증가가 로그·복제·응답 비용을 키우는지도 대표 데이터로 측정하겠습니다.

혼합 타입·과거 버전·큰 문서·동시 부분 변경을 시험합니다. 데이터 migration과 인덱스 생성의 부하를 따로 측정합니다. JSON은 스키마가 없는 것이 아니라 스키마의 일부 책임이 DB 구조 밖으로 옮겨간 선택이라고 설명하겠습니다.