PostgreSQL JSONB와 정규화된 테이블: 선택과 마이그레이션

진짜 문제: 빠르게 움직이되 스스로 궁지에 몰리지 않기

요구사항이 매주 바뀌는 건 새로 무언가를 만들 때 흔한 일입니다. 고객이 필드를 하나 더 요청하고, 영업이 다른 워크플로를 원하며, 지원은 감사 로그를 필요로 합니다. 데이터베이스는 결국 이런 변화들의 무게를 떠안게 됩니다.

빠른 반복은 단순히 화면을 빨리 내보내는 것이 아닙니다. 필드를 추가, 이름 변경, 삭제해도 리포트나 통합, 오래된 레코드를 깨뜨리지 않아야 합니다. 또한 “지난달에 배송 메모가 없던 주문이 몇 건이었나?” 같은 새 질문에 대해 매번 원오프 스크립트를 만들지 않고 바로 답할 수 있어야 합니다.

그래서 초기에 JSONB와 정규화된 테이블 중 무엇을 쓸지 결정하는 것이 중요합니다. 둘 다 쓸 수 있고, 둘 다 잘못 쓰면 고통을 줍니다. JSONB는 오늘 거의 무엇이든 저장할 수 있으니 자유처럼 느껴집니다. 정규화된 테이블은 구조를 강제하니 더 안전하게 느껴집니다. 진짜 목표는 지금 데이터가 얼마나 불확실한지와 얼마나 빨리 신뢰 가능한 상태가 되어야 하는지에 맞춰 저장 모델을 선택하는 것입니다.

팀이 잘못된 모델을 선택하면 증상은 보통 분명합니다:

• 단순한 질문이 느리고 지저분한 쿼리나 커스텀 코드로 변합니다.
• 동일한 것을 나타내는 두 레코드가 서로 다른 필드 이름을 사용합니다.
• 선택적 필드가 나중에 필수로 바뀌고 옛 데이터와 맞지 않습니다.
• 데이터베이스에서 규칙(고유값, 필수 관계)을 강제할 수 없어 우회책이 필요합니다.
• 작은 변경에도 리포트와 내보내기가 계속 깨집니다.

실용적 결정은 이렇습니다: 어디에 유연성이 더 필요한가(그리고 일시적인 불일치를 감수할 수 있는가), 어디에 구조가 더 필요한가(데이터가 돈, 운영 또는 규정 준수를 좌우하기 때문에).

JSONB와 정규화된 테이블, 간단한 설명

PostgreSQL은 전통적인 컬럼(text, number, date)에 데이터를 저장할 수 있고, JSONB로 전체 JSON 문서를 한 열에 담을 수도 있습니다. 차이는 “새로운 것 vs 오래된 것”이 아니라 데이터베이스가 무엇을 보장해주길 원하는가입니다.

JSONB는 키, 값, 배열, 중첩 객체를 저장합니다. 하지만 모든 행이 같은 키를 갖는지, 값의 타입이 항상 같은지, 참조된 항목이 다른 테이블에 실제로 존재하는지는 자동으로 강제하지 않습니다. 검사와 제약을 추가할 수는 있지만, 직접 결정하고 구현해야 합니다.

정규화된 테이블은 각 항목이 무엇인지에 따라 데이터를 별도 테이블로 나누고 ID로 연결합니다. 고객은 한 테이블, 주문은 다른 테이블에 있고 각 주문은 고객을 가리키는 식입니다. 이렇게 하면 모순에 대한 보호가 강해집니다.

일상적인 관점에서 트레이드오프는 명확합니다:

• JSONB: 기본적으로 유연하고 변경하기 쉽지만 표류하기 쉽습니다.
• 정규화된 테이블: 변경에 더 신중해야 하지만 검증과 일관된 조회는 더 쉽습니다.

간단한 예는 지원 티켓의 커스텀 필드입니다. JSONB라면 마이그레이션 없이 내일 새 필드를 추가할 수 있습니다. 정규화된 테이블은 필드를 추가하는 것이 더 의도적이지만 리포트와 규칙은 더 명확합니다.

언제 JSONB가 빠른 반복에 적합한가

데이터 형태를 잘못 설계할 위험이 가장 크고 엄격한 규칙을 강제할 필요가 적을 때 JSONB는 강력한 선택입니다. 제품이 아직 워크플로를 찾는 중이라면 모든 것을 고정 테이블에 억지로 넣는 것이 빈번한 마이그레이션으로 속도를 늦출 수 있습니다.

필드가 매주 바뀌는 경우가 좋은 신호입니다. 예를 들어 마케팅이 계속 질문을 추가하고 라벨을 바꾸고 단계를 제거하는 온보딩 폼을 생각해보세요. JSONB는 각 제출을 있는 그대로 저장하게 하므로 내일 버전이 달라져도 문제가 없습니다.

JSONB는 또한 “알 수 없는 것”에 적합합니다: 아직 완전히 이해하지 못했거나 통제하지 못하는 데이터입니다. 파트너의 웹훅 페이로드를 수집한다면 원시 페이로드를 JSONB에 저장하면 즉시 새 필드를 지원하고 나중에 어떤 필드를 우선 컬럼으로 올릴지 결정할 수 있습니다.

초기 단계에서 흔한 사용 사례는 빠르게 바뀌는 폼, 이벤트 캡처 및 감사 로그, 고객별 설정, 기능 플래그, 실험 등입니다. 주로 데이터를 쓰고 전체를 그대로 읽어오며 형태가 아직 확정되지 않았을 때 특히 유용합니다.

한 가지 가드레일은 사람들 기대보다 더 큰 도움을 줍니다: 사용 중인 키를 짧고 공유된 메모로 기록해 두어 같은 필드의 철자가 다섯 가지로 갈라지는 일을 피하세요.

언제 정규화된 테이블이 더 안전한 장기 선택인가

데이터가 단순히 “이 기능용”이 아니게 되고 공유되고 조회되며 신뢰될 때 정규화된 테이블이 이깁니다. 사람들이 여러 방식으로 레코드를 슬라이스하고 필터링할 경우(상태, 소유자, 지역, 기간) 컬럼과 관계는 동작을 예측 가능하게 하고 최적화하기 쉽습니다.

정규화는 데이터베이스가 규칙을 강제해야 할 때도 중요합니다. JSONB는 무엇이든 저장할 수 있는데, 이게 바로 강력한 보장이 필요할 때 문제입니다.

지금 정규화해야 한다는 신호들

다음 항목들이 여러 개 해당하면 JSON 우선 모델에서 벗어날 때입니다:

• 일관된 리포트와 대시보드가 필요할 때.
• 필수 필드, 고유값, 다른 레코드와의 관계 같은 제약이 필요할 때.
• 둘 이상의 서비스나 팀이 동일한 데이터를 읽고 쓸 때.
• 단순한 인덱스를 잘 사용할 수 없어 많은 행을 스캔해야 하는 쿼리가 생길 때.
• 규제나 감사 환경에 있어 규칙을 증명해야 할 때.

성능은 흔한 전환점입니다. JSONB로 필터링하면 값을 반복해서 추출해야 하는 경우가 많습니다. JSON 경로에 인덱스를 걸 수는 있지만 요구사항은 유지보수하기 어려운 인덱스의 누더기가 되기 쉽습니다.

구체적 예

프로토타입에서 각기 다른 필드를 가진 ‘고객 요청’을 JSONB로 저장했습니다. 나중에 운영팀은 우선순위와 SLA로 필터되는 큐가 필요합니다. 재무팀은 부서별 합계를 원합니다. 지원팀은 모든 요청에 고객 ID와 상태가 반드시 있어야 합니다. 이런 경우 정규화된 테이블이 빛을 발합니다: 공통 필드를 위한 명확한 컬럼, 고객 및 팀으로의 외래 키, 잘못된 데이터 유입을 막는 제약.

30분 안에 쓸 수 있는 간단한 결정 프레임워크

거창한 데이터베이스 이론 논쟁은 필요 없습니다. 중요한 건 하나의 빠른 문서화된 답입니다: 유연성이 엄격한 구조보다 더 가치 있는 곳은 어디인가?

시스템을 만드는 사람들과 사용하는 사람들(개발자, 운영, 지원, 경우에 따라 재무)과 함께 이 작업을 하세요. 목표는 한쪽을 무조건 고르는 것이 아니라 제품의 각 영역에 맞는 적합한 모델을 선택하는 것입니다.

5단계 체크리스트

1. 가장 중요한 10개 화면과 그 뒤의 정확한 질문을 나열하세요. 예: “고객 레코드 열기”, “연체 주문 찾기”, “지난달 정산 내역 내보내기”. 질문을 이름지을 수 없다면 설계할 수 없습니다.

2. 항상 정확해야 하는 필드를 강조하세요. 상태, 금액, 날짜, 소유권, 권한 같은 건 실수하면 비용이 나거나 지원 화재를 일으키므로 보통 제약이 있는 정규 컬럼에 둬야 합니다.

3. 자주 바뀌는 것과 거의 바뀌지 않는 것을 표시하세요. 매주 바뀌는 항목(새 폼 질문, 파트너별 세부)은 JSONB 후보가 강합니다. 거의 바뀌지 않는 핵심 필드는 정규화 쪽으로 기울입니다.

4. UI에서 검색, 필터, 정렬이 반드시 필요한 것을 결정하세요. 사용자가 자주 필터링한다면 1등 시민 컬럼(또는 신중히 인덱싱된 JSONB 경로)으로 두는 것이 낫습니다.

5. 영역별로 모델을 선택하세요. 일반적인 분리는 핵심 엔터티와 워크플로는 정규화된 테이블로, 추가적인 빠르게 변하는 메타데이터는 JSONB로 두는 것입니다.

세부에 빠지지 않는 성능 기초

속도는 보통 한 가지에서 옵니다: 가장 흔한 질문들을 저렴하게 답하게 만드는 것. 이는 이념보다 더 중요합니다.

JSONB를 사용한다면 작고 예측 가능하게 유지하세요. 몇 개의 추가 필드는 괜찮지만, 거대하고 계속 변하는 블롭은 인덱싱하기 어렵고 오용하기 쉽습니다. 어떤 키가 항상 존재할 것이라면(예: "priority"나 "source") 키 이름과 값 타입을 일관되게 유지하세요.

인덱스는 마법이 아닙니다. 읽기 속도를 높이는 대신 쓰기에는 비용이 들고 디스크를 더 사용합니다. 자주 필터하거나 조인하는 것만 인덱스하고, 실제 쿼리 형태대로 인덱스하세요.

인덱싱 기본 규칙

• 상태, owner_id, created_at, updated_at 같은 일반 필터에는 btree 인덱스를 사용하세요.
• JSONB 컬럼 내부를 자주 검색한다면 GIN 인덱스를 사용하세요.
• (meta->>'priority') 같은 한두 개의 핫한 JSON 필드에는 표현식 인덱스를 선호하세요. 전체 JSONB를 인덱스하는 것보다 낫습니다.
• 특정 부분만 중요하면 부분 인덱스(partial index)를 사용하세요(예: status = 'open'인 행만).

JSONB 안에 숫자나 날짜를 문자열로 저장하지 마세요. "10"은 "2"보다 먼저 정렬되고, 날짜 연산도 번거로워집니다. 실제 숫자/타임스탬프 타입을 컬럼으로 두거나 최소한 JSON 숫자로 저장하세요.

혼합 모델이 종종 승리합니다: 핵심 필드는 컬럼에 두고 확장 가능한 추가는 JSONB에 둡니다. 예: operations 테이블에 id, status, owner_id, created_at 같은 컬럼과 선택적 답변을 위한 meta JSONB.

나중에 고통을 만드는 흔한 실수들

초기에는 JSONB가 자유처럼 느껴집니다. 고통은 보통 몇 달 뒤, 더 많은 사람이 데이터에 관여하면서 “되는 대로”가 “이걸 바꾸려면 깨진다”로 변할 때 나타납니다.

이 패턴들이 대부분의 정리 작업을 야기합니다:

• JSONB를 쓰레기통처럼 다루기. 팀마다 조금씩 다른 형태를 저장하면 커스텀 파싱 로직이 곳곳에 생깁니다. 기본 컨벤션을 정하세요: 일관된 키 이름, 명확한 날짜 형식, JSON 안의 작은 버전 필드.
• 핵심 엔터티를 JSONB 안에 숨기기. 고객, 주문, 권한 등을 블롭으로만 저장하면 조인이 어색해지고 제약 적용이 어려우며 중복이 생깁니다. 누가/무엇을/언제가 핵심이면 컬럼에 두고 선택적 세부만 JSONB로.
• 마이그레이션을 긴급할 때까지 미루기. 어떤 키가 존재하는지, 어떻게 바뀌었는지, 어떤 키가 공식인지 추적하지 않으면 첫 대규모 마이그레이션이 위험해집니다.
• JSONB가 자동으로 유연하고 빠르다고 가정하기. 규칙 없는 유연성은 불일치일 뿐입니다. 속도는 접근 패턴과 인덱스에 달려 있습니다.
• 시간이 지남에 따라 키를 바꿔 분석을 망가뜨리기. status를 state로 바꾸거나 숫자를 문자열로 바꾸고 시간대가 섞이면 리포트가 조용히 망가집니다.

구체적 예: 팀이 tickets 테이블과 폼 답변을 담는 details JSONB 필드로 시작했습니다. 나중에 재무는 카테고리별 주간 분해를 원하고, 운영은 SLA 추적을 원하며, 지원은 팀별 ‘오픈’ 대시보드를 원합니다. 카테고리와 타임스탬프가 키와 포맷 사이에서 흩어지면 모든 리포트가 원오프 쿼리가 됩니다.

프로토타입이 미션 크리티컬해졌을 때의 마이그레이션 계획

프로토타입이 급여, 재고, 고객 지원 같은 핵심 업무를 담당하면 “나중에 데이터 고치자”는 더 이상 용납되지 않습니다. 가장 안전한 경로는 작은 단계로 마이그레이션하면서 옛 JSONB 데이터도 새 구조가 검증될 때까지 작동하게 하는 것입니다.

단계적 접근은 위험한 대규모 리라이트를 피합니다:

• 목적지(대상)를 먼저 설계하세요. 목표 테이블, 기본 키, 명명 규칙을 문서화합니다. 무엇이 실체인지(Customer, Ticket, Order)와 무엇이 유연하게 남을지 결정하세요(메모, 선택적 속성 등).
• 기존 데이터 옆에 새 테이블을 만드세요. JSONB 컬럼은 유지하고 정규화된 테이블과 인덱스를 병행해서 추가합니다.
• 백필을 배치 단위로 하고 검증하세요. JSONB 필드를 새 테이블로 청크 단위로 복사하고 행수, 필수 필드 not null, 샘플 체크로 검증합니다.
• 쓰기 전에 읽기를 전환하세요. 쿼리와 리포트를 먼저 새 테이블에서 읽도록 바꿉니다. 출력이 일치하면 새 구조로 쓰기를 시작하세요.
• 잠그기(락다운). JSONB에 쓰기를 중단하고, 오래된 필드를 삭제하거나 동결하세요. 외래 키, 고유 규칙 같은 제약을 추가해 잘못된 데이터가 다시 들어오지 않게 합니다.

최종 전환 전에:

• 일주일 정도 두 경로(옛 것 vs 새 것)를 병행 실행하고 출력을 비교하세요.
• 느린 쿼리를 모니터링하고 필요한 인덱스를 추가하세요.
• 롤백 계획(feature flag나 설정 스위치)을 준비하세요.
• 팀에 정확한 쓰기 전환 시간을 알리세요.

확정하기 전에 빠르게 확인할 항목들

접근을 확정하기 전에 현실 점검을 하세요. 이 질문들이 대부분의 미래 문제를 초기 단계에서 잡아줍니다.

결과를 결정하는 다섯 가지 질문

• 지금(또는 다음 릴리스)에 고유성, 필수 필드, 엄격한 타입이 필요합니까?
• UI에서 사용자들이 자주 필터링하고 정렬해야 하는 필드는 무엇입니까(검색, 상태, 소유자, 날짜)?
• 곧 대시보드, 내보내기, 재무/운영으로 보낼 리포트가 필요합니까?
• 새로운 팀원이 10분 안에 데이터 모델을 손쉽게 설명할 수 있습니까?
• 마이그레이션이 워크플로를 망가뜨리면 롤백 계획이 있습니까?

첫 세 질문에 대해 “예”라면 이미 정규화된 테이블(또는 하이브리드: 핵심 필드는 정규화, 롱테일은 JSONB) 쪽으로 기울고 있습니다. 마지막 질문 하나만 예라면 더 큰 문제는 프로세스이지 스키마가 아닙니다.

간단한 경험 법칙

데이터 형태가 불분명할 때는 JSONB를 사용하되 항상 필요할 소수의 안정 필드(id, owner, status, created_at 등)는 이름지어 두세요. 사람들이 일관된 필터, 안정된 내보내기, 엄격한 검증을 기대하기 시작하면 ‘유연성’의 비용은 빠르게 커집니다.

예시: 유연한 폼에서 신뢰할 수 있는 운영 시스템으로

주간 단위로 바뀌는 고객 지원 인테이크 폼을 떠올려 보세요. 어느 주에는 “기기 모델”을 추가하고, 다음 주에는 “환불 사유”를 추가하고, 그 다음 주에는 “priority”를 “urgency”로 바꿉니다. 초반에는 폼 페이로드를 하나의 JSONB 컬럼에 넣는 것이 완벽해 보입니다. 마이그레이션 없이 변경을 배포할 수 있으니 아무도 불평하지 않습니다.

세 달 뒤, 관리자들은 “urgency = high이고 device model이 iPhone으로 시작하는 것” 같은 필터, 고객 등급에 따른 SLA, 지난주 수치와 일치해야 하는 주간 리포트를 원합니다.

실패 모드는 예측 가능합니다: 누군가가 “이 필드는 어디로 갔나?”라고 묻습니다. 오래된 레코드는 다른 키 이름을 썼고, 값 타입이 바뀌었거나("3" vs 3), 필드 자체가 절반의 티켓에는 아예 존재하지 않았습니다. 리포트는 특수 케이스의 누더기가 됩니다.

실용적 중간 지점은 하이브리드 설계입니다: 안정적이고 비즈니스에 중요한 필드는 실제 컬럼으로 두고(created_at, customer_id, status, urgency, sla_due_at 등), 변동이 잦은 새 필드나 드문 필드는 JSONB 확장 영역에 둡니다.

낮은 방해로 진행할 수 있는 타임라인 예시:

• 1주차: 필터와 리포트에서 반드시 필요한 5~10개 필드를 선택하고 컬럼을 추가하세요.
• 2주차: 최근 레코드부터 기존 JSONB에서 그 컬럼을 백필하세요, 그다음 오래된 것들로 확장합니다.
• 3주차: 새 레코드가 컬럼과 JSONB 둘 다 채우도록 쓰기 로직을 업데이트(임시 이중 쓰기).
• 4주차: 읽기와 리포트를 컬럼으로 전환하고 JSONB는 확장 속성으로만 유지합니다.

다음 단계: 결정하고 문서화하고 계속 배포하세요

아무 것도 하지 않으면 결정이 대신 내려집니다. 프로토타입은 자라서 가장자리가 굳어지고 모든 변화가 위험하게 느껴집니다. 더 나은 방법은 지금 작은 문서화된 결정을 내리고 계속 빌드하는 것입니다.

앱이 빠르게 대답해야 하는 5~10개의 질문을 나열하세요(예: “이 고객의 모든 오픈 주문 표시”, “이메일로 사용자 찾기”, “월별 수익 보고”). 각 항목 옆에 절대 깨지면 안 되는 제약(unique email, required status, valid totals)을 적으세요. 그런 다음 명확한 경계를 그리세요: 자주 변경되며 드물게 필터되거나 조인되는 필드는 JSONB에 두고, 검색·정렬·조인·검증이 매번 필요한 것은 컬럼과 테이블로 승격하세요.

노코드 플랫폼을 사용한다면 이 분리가 시간이 지남에 따라 더 관리하기 쉬워집니다. 예를 들어 AppMaster (appmaster.io)는 PostgreSQL 테이블을 시각적으로 모델링하고 요구사항이 바뀔 때 기본 백엔드와 앱을 재생성해 반복적인 스키마 변경과 계획된 마이그레이션을 덜 고통스럽게 만듭니다.