2025년 8월 17일·7분
데이터 모델링 선택이 아키텍처를 장기적으로 고정하는 방법
데이터 모델링 결정은 수년간 데이터 스택을 규정합니다. 락인이 발생하는 지점, 트레이드오프, 그리고 선택지를 유지하는 실용적 방법을 확인하세요.
데이터 모델링 결정은 수년간 데이터 스택을 규정합니다. 락인이 발생하는 지점, 트레이드오프, 그리고 선택지를 유지하는 실용적 방법을 확인하세요.
데이터 아키텍처에서의 “락인”은 단지 공급업체나 도구의 문제가 아닙니다. 스키마를 변경하는 것이 너무 위험하거나 비용이 많이 들어서 하지 않게 될 때 발생합니다—그 이유는 대시보드, 리포트, ML 기능, 통합, 그리고 데이터가 "무엇을 의미하는지"에 대한 공유된 이해가 깨지기 때문입니다.
데이터 모델은 다른 모든 것보다 오래 살아남는 결정 중 하나입니다. 웨어하우스는 교체되고, ETL 도구는 바뀌며, 팀은 재구성되고, 네이밍 규칙은 흐려집니다. 하지만 수십 개의 다운스트림 소비자가 테이블의 컬럼, 키, 그리고 그레인에 의존하게 되면 모델은 계약이 됩니다. 이를 변경하는 것은 단순한 기술적 마이그레이션이 아니라 사람과 프로세스 전반의 조정 문제입니다.
도구는 교체 가능하지만, 종속성은 그렇지 않습니다. 한 모델에서 “revenue”로 정의된 지표가 다른 모델에서는 “gross”일 수 있습니다. 고객 키가 한 시스템에서는 "청구 계정(billing account)"을 의미하고 다른 시스템에서는 "사람(person)"을 의미할 수 있습니다. 그런 의미 수준의 약속은 퍼진 뒤 되돌리기 어렵습니다.
대부분의 장기 락인은 초기의 몇 가지 선택으로부터 비롯됩니다:
트레이드오프는 정상입니다. 목표는 약속을 피하는 것이 아니라 가장 중요한 약속을 의도적으로 하고, 가능한 한 많은 것들을 되돌릴 수 있게 유지하는 것입니다. 이후 섹션은 변경이 불가피할 때 파손을 줄이는 실용적 방법에 집중합니다.
데이터 모델은 단순한 테이블 집합이 아닙니다. 초판이 끝나기도 전에 많은 시스템이 조용히 그 모델에 의존하는 계약이 됩니다.
한 번 모델이 “공식화”되면 다음으로 확산되는 경향이 있습니다:
각 종속성은 변경 비용을 곱합니다: 더 이상 하나의 스키마만 편집하는 것이 아니라 많은 소비자를 조정해야 합니다.
하나의 공개된 메트릭(예: “활성 고객”)은 중앙화되어 있지 않은 경우가 많습니다. 누군가는 BI 도구에서 정의하고, 다른 팀은 dbt에서 재구현하고, 성장 분석가는 노트북에 하드코딩하며, 제품 대시보드에서는 약간 다른 필터로 다시 삽입합니다.
몇 달 후에는 “한 메트릭”이 사실상 경계 케이스 규칙이 다른 여러 유사 메트릭이 됩니다. 지금 모델을 바꾸면 쿼리가 깨지는 것뿐 아니라 신뢰가 깨질 위험이 큽니다.
락인은 다음과 같은 곳에 숨어 있습니다:
*_id, created_at)모델의 모양은 일상 운영에 영향을 줍니다: 넓은 테이블은 스캔 비용을 올리고, 높은 그레인의 이벤트 모델은 지연을 증가시키며, 불분명한 라인리지는 사고 원인 규명(티어) 난도를 높입니다. 메트릭이 드리프트하거나 파이프라인이 실패하면, 온콜 대응은 모델이 얼마나 이해 가능하고 테스트 가능한지에 달려 있습니다.
“그레인”은 테이블이 나타내는 상세 수준입니다—한 행이 정확히 무엇인가. 작은 것 같지만 이것이 종종 아키텍처를 조용히 고정하는 첫 번째 결정입니다.
order_id). 주문 합계, 상태, 고수준 리포팅에 적합합니다.order_id + product_id + line_number). 제품 구성, 품목별 할인, SKU별 반품에 필요합니다.session_id). 퍼널 분석과 어트리뷰션에 유용합니다.문제는 비즈니스가 필연적으로 물어볼 질문을 자연스럽게 답할 수 없는 그레인을 선택할 때 시작됩니다.
만약 오직 orders만 저장하고 나중에 “수익 기준 상위 제품”이 필요해지면 다음과 같은 일을 해야 합니다:
order_items 테이블을 만들고 백필한다(마이그레이션 고통), 또는orders_by_product, orders_with_items_flat)—시간이 지나며 이들은 서로 달라집니다.마찬가지로 sessions를 주된 팩트 그레인으로 선택하면 구매를 세션에 신중히 연결하지 않는 한 “일별 순수 수익(net revenue by day)”은 어색해집니다. 깨지기 쉬운 조인, 중복 집계 위험, 그리고 “특별한” 메트릭 정의가 생깁니다.
그레인은 관계와 밀접히 연결됩니다:
빌드 전에 이해관계자들에게 대답할 수 있는 질문을 하세요:
키는 모델이 “이 행이 현실 세계의 다른 행과 동일한 것”인지 결정하는 방법입니다. 잘못하면 조인이 엉키고 증분 로드가 느려지며 새 시스템 통합이 체크리스트가 아니라 협상이 됩니다.
자연 키는 비즈니스나 소스 시스템에 이미 존재하는 식별자입니다—예: 송장 번호, SKU, 이메일 주소, CRM의 customer_id. 서로게이트 키는 내부에서 생성한 ID(종종 정수나 해시)로 창고 밖에서는 의미가 없습니다.
자연 키는 이미 존재하고 이해하기 쉬워 매력적입니다. 서로게이트 키는 잘 관리하면 안정적이어서 매력적입니다.
소스 시스템이 피할 수 없이 변경될 때 락인이 드러납니다:
customer_id 네임스페이스가 겹칠 수 있습니다.웨어하우스 전체에서 자연 키를 사용하면 이러한 변경이 팩트, 디멘션, 다운스트림 대시보드 전반에 파급될 수 있습니다. 역사적 메트릭이 갑자기 바뀌는 일이 발생할 수 있습니다.
서로게이트 키를 사용하면 새로운 소스 ID를 기존 서로게이트 정체성에 매핑함으로써 소스 식별자가 바뀌어도 웨어하우스 정체성을 안정적으로 유지할 수 있습니다.
실제 데이터는 병합 규칙이 필요합니다: “동일한 이메일 + 동일한 전화 = 동일 고객”, “가장 최신 레코드를 우선”, “확인될 때까지 둘 다 유지” 등. 이 중복 제거 정책은 다음에 영향을 줍니다:
실용적 패턴은 별도의 매핑 테이블(종종 정체성 맵이라고 불림)을 유지해 여러 소스 키가 하나의 웨어하우스 정체성으로 어떻게 합쳐지는지 추적하는 것입니다.
데이터를 파트너와 공유하거나 인수한 회사를 통합할 때, 키 전략이 작업량을 결정합니다. 한 시스템에 묶인 자연 키는 잘 돌아다니지 않습니다. 서로게이트 키는 내부에서 잘 작동하지만, 다른 쪽에서 조인하려면 일관된 크로스워크를 공개해야 합니다.
어느 쪽이든 키는 단순한 컬럼 선택이 아니라 비즈니스 엔터티가 변화 속에서 어떻게 살아남을지를 결정하는 약속입니다.
시간은 “단순한” 모델을 비용이 많이 드는 것으로 바꾸는 곳입니다. 대부분의 팀은 현재 상태 테이블(고객/주문/티켓당 한 행)으로 시작합니다. 쿼리하기 쉽지만 나중에 필요할 답을 조용히 삭제합니다.
일반적으로 세 가지 옵션이 있으며, 각각은 다른 도구와 비용에 락인을 만듭니다:
effective_start, effective_end, is_current 플래그 사용.만약 언젠가 “당시 우리가 무엇을 알고 있었나?”가 필요할 가능성이 있다면 덮어쓰기만으로는 안 됩니다.
팀들은 보통 다음 상황에서 누락된 히스토리를 발견합니다:
사후에 이를 재구성하는 것은 고통스럽습니다. 상류 시스템들이 이미 진실을 덮어썼을 수 있기 때문입니다.
시간 모델링은 단순한 타임스탬프 컬럼 이상입니다.
히스토리는 저장소와 컴퓨트 비용을 증가시키지만 나중에 복잡성을 줄이기도 합니다. 추가 전용 로그는 수집을 저렴하고 안전하게 만들 수 있고, SCD 테이블은 일반적인 ‘as of’ 쿼리를 간단하게 만듭니다. 오늘의 대시보드만이 아니라 비즈니스가 물어볼 질문과 일치하는 패턴을 선택하세요.
정규화와 차원 모델링은 단지 “스타일”이 아닙니다. 이들은 시스템이 친절하게 만드는 대상—파이프라인을 유지하는 데이터 엔지니어인지, 매일 질문에 답하는 사람인지—을 결정합니다.
정규화 모델(종종 3NF)은 데이터를 더 작은 관련 테이블로 분해하여 각 사실을 한 번만 저장합니다. 목표는 중복을 피하고 그로 인한 문제를 줄이는 것입니다:
이 구조는 데이터 무결성에 좋고 업데이트가 자주 일어나는 시스템에 유리합니다. 엔지니어링 중심 팀에 적합합니다.
차원 모델링은 분석을 위해 데이터를 재구성합니다. 일반적 스타 스키마는:
이 레이아웃은 빠르고 직관적입니다: 분석가는 복잡한 조인 없이 디멘션으로 필터/그룹할 수 있고, BI 도구는 이를 잘 이해합니다. 제품팀도 혜택을 봅니다—일반적인 메트릭 쿼리가 쉽고 오해하기 어려워 자가 서비스 탐색이 현실적이 됩니다.
정규화 모델은 다음에 최적화됩니다:
차원 모델은 다음에 최적화됩니다:
락인은 실제입니다: 수십 개의 대시보드가 스타 스키마에 의존하면 그레인이나 디멘션을 바꾸는 것은 정치적·운영상 비용이 큽니다.
갈등을 줄이는 일반적 접근은 두 레이어를 명확한 책임으로 유지하는 것입니다:
이 하이브리드는 기록 시스템을 유연하게 유지하면서 비즈니스에 필요한 속도와 사용성을 제공해 한 모델이 모든 일을 하도록 강요하지 않습니다.
이벤트 중심 모델은 어떤 일이 발생했는지를 설명합니다: 클릭, 결제 시도, 발송 업데이트, 지원 티켓 회신. 엔터티 중심 모델은 무엇인지(고객, 계정, 제품, 계약)를 설명합니다.
엔터티 중심 모델(고객, 제품, 구독 같은 현재 상태 컬럼이 있는 테이블)은 운영 리포팅과 “활성 계정 수는?” 또는 “각 고객의 현재 요금제는?” 같은 단순 질문에 적합합니다. 또한 직관적입니다: 사물당 한 행.
이벤트 중심 모델(추가 전용 팩트)은 시간에 따른 분석에 최적화되어 있습니다: “무엇이 바뀌었나?” “어떤 순서였나?” 소스 시스템에 더 가깝기 때문에 나중에 새로운 질문을 추가하기가 쉽습니다.
잘 설명된 이벤트 스트림(타임스탬프, 액터, 오브젝트, 컨텍스트 포함)을 유지하면 핵심 테이블을 재모델링하지 않고도 새 질문에 답할 수 있습니다. 예: 나중에 “첫 가치 발생 시점(first value moment)”, “단계 간 이탈(drop-off)”, “무료 체험 시작에서 첫 결제까지의 시간” 등을 기존 이벤트에서 도출할 수 있습니다.
한계도 있습니다: 이벤트 페이로드에 핵심 속성(예: 어떤 마케팅 캠페인이 적용되었는지)이 전혀 캡처되지 않았다면 나중에 이를 새로 만들어낼 수는 없습니다.
이벤트 모델은 더 무겁습니다:
이벤트 우선 아키텍처라도 accounts, contracts, product catalog 같은 안정적인 엔터티 테이블은 필요합니다. 이벤트는 이야기를 제공하고, 엔터티는 등장인물을 정의합니다. 결정적 락인은 얼마나 많은 의미를 “현재 상태”로 인코딩할지 vs 히스토리에서 유도할지입니다.
시맨틱 레이어(메트릭 레이어)는 원시 테이블과 사람들이 실제로 사용하는 숫자 사이의 번역지입니다. 메트릭과 슬라이싱 가능한 디멘션(날짜, 지역, 제품) 및 항상 적용되어야 할 필터를 한 번 정의하면, 각 대시보드나 분석가가 로직을 다시 구현하는 일을 줄일 수 있습니다.
메트릭이 널리 채택되면 비즈니스를 위한 API처럼 동작합니다. 수백 개의 리포트, 알림, 실험, 예측, 보너스 플랜이 이에 의존할 수 있습니다. 나중에 정의를 바꾸면 SQL은 여전히 동작하더라도 신뢰가 깨질 수 있습니다.
락인은 기술적 문제만이 아닙니다—사회적 문제입니다. 예를 들어 “Revenue”가 항상 환불을 제외했다면, 순수익(net revenue)으로 갑자기 바꾸면 트렌드가 하루아침에 이상해 보입니다. 사람들은 무엇이 바뀌었는지 묻기도 전에 데이터를 믿지 않게 됩니다.
작은 선택들이 빠르게 굳어집니다:
orders는 주문 수 집계라는 의미를 암시합니다. 모호한 이름은 일관성 없는 사용을 초대합니다.order_date로 그룹핑할지 ship_date로 할지 결정하면 내러티브와 운영 결정이 달라집니다.메트릭 변경을 제품 릴리스처럼 다루세요:
revenue_v1, revenue_v2를 만들고 전환 기간 동안 둘 다 제공하세요.시맨틱 레이어를 의도적으로 설계하면 의미를 변경할 때 모두가 놀라지 않도록 락인 관련 고통을 줄일 수 있습니다.
모든 스키마 변경이 동일하지 않습니다. 새 NULL 허용 컬럼을 추가하는 것은 보통 낮은 위험입니다: 기존 쿼리는 이를 무시하고 다운스트림 잡은 계속 실행되며, 나중에 백필할 수 있습니다.
문맥이 바뀐 기존 컬럼의 의미를 바꾸는 것은 비용이 많이 드는 유형입니다. 예를 들어 status가 이전에는 "결제 상태(payment status)"를 의미했는데 지금은 "주문 상태(order status)"를 의미하면, 모든 대시보드와 알림, 조인이 은밀하게 잘못되었지만 소리는 나지 않습니다. 의미 변경은 시끄러운 실패가 아니라 은밀한 데이터 버그를 만듭니다.
여러 팀이 소비하는 테이블에는 명시적 계약과 테스트를 정의하세요:
pending|paid|failed) 및 숫자 범위이는 데이터 계약 테스트와 같습니다. 우발적 드리프트를 막고 “파괴적 변경”을 명확한 카테고리로 만듭니다.
모델을 진화시켜야 할 때는 구·신 소비자가 공존할 수 있는 기간을 목표로 하세요:
공유 테이블에는 명확한 오너가 필요합니다: 누가 변경을 승인하는가, 누가 알림을 받는가, 롤아웃 프로세스는 무엇인가? 오너 + 리뷰어 + 폐기 일정 같은 경량 정책이 도구 어느 것보다 파괴 방지에 효과적입니다.
데이터 모델은 단순한 논리 다이어그램이 아니라 쿼리가 어떻게 실행될지, 비용이 얼마나 들지, 나중에 무엇이 고치기 어려운지에 대한 물리적 배팅입니다.
파티셔닝(보통 날짜별)과 클러스터링(자주 필터링하는 키, 예:customer_id 또는 event_type)은 특정 쿼리 패턴에 보상을 주고 다른 패턴을 벌합니다.
예: event_date로 파티셔닝하면 “최근 30일” 필터가 저렴하고 빠르지만, 많은 사용자가 긴 기간에 걸쳐 account_id로 슬라이스하면 여러 파티션을 스캔하게 되어 비용이 폭증하고 팀들은 요약 테이블이나 추출물을 만들어 모델을 더욱 고착시키는 해결책을 고안하게 됩니다.
넓은(비정규화된) 테이블은 BI 도구에 친화적입니다: 조인이 적고 놀람이 적으며 “첫 차트까지의 시간”이 빨라집니다. 또한 큰 테이블에 대한 반복 조인을 피하면 쿼리당 비용이 저렴할 수 있습니다.
대신 단점은 데이터 중복입니다. 저장소가 늘고 업데이트가 복잡해지며 일관된 정의를 강제하기 어려워집니다.
강하게 정규화된 모델은 중복을 줄이고 무결성을 개선할 수 있지만, 반복 조인으로 쿼리가 느려지고 비기술 사용자들이 직접 리포트를 만들 때 경험이 나빠질 수 있습니다.
대부분 파이프라인은 증분으로(신규 행 또는 변경된 행) 로드됩니다. 이는 안정적인 키와 append-친화적 구조에서 가장 잘 동작합니다. 과거를 자주 재작성해야 하는 모델(예: 많은 파생 컬럼을 재구성해야 하는 경우)은 비용과 운영 위험이 큽니다.
모델은 무엇을 검증할 수 있고 무엇을 고칠 수 있는지를 결정합니다. 메트릭이 복잡한 조인에 의존하면 품질 검사는 локализ화하기 어려워집니다. 테이블이 백필 방식(일별, 소스 배치)에 맞춰 파티셔닝되어 있지 않으면 재처리는 훨씬 많은 데이터를 스캔·재작성해야 해서 일상적 수정이 주요 사고로 변할 수 있습니다.
데이터 모델을 나중에 바꾸는 것은 거의 ‘리팩터’가 아닙니다. 사람들은 여전히 그 도시(시스템)에 살고 있고: 리포트는 계속 작동해야 하고, 정의는 일관되어야 하며, 오래된 가정은 대시보드·파이프라인·보상에 깊게 박혀 있습니다.
다음과 같은 트리거가 반복적으로 나타납니다:
가장 낮은 위험 접근법은 마이그레이션을 엔지니어링 프로젝트이자 변경 관리 프로젝트로 취급하는 것입니다.
내부 데이터 앱(관리 도구, 메트릭 탐색기, QA 대시보드)이 있다면 이를 일급 마이그레이션 소비자처럼 다루는 것이 도움이 됩니다. 팀들은 가끔 Koder.ai 같은 빠른 앱 제작 워크플로를 사용해 계약 검사 UI, 대조 대시보드, 이해관계자 검토 도구를 병렬 실행 중에 신속하게 만들기도 합니다.
성공은 “새 테이블이 존재한다”가 아닙니다. 성공은:
마이그레이션은 재조정과 이해관계자 승인 때문에 예상보다 더 많은 시간을 소비합니다. 비용 계획을 1급 작업으로 다루세요(인력 시간, 이중 운영 컴퓨트, 백필). 트레이드오프와 일정 정리가 필요하면 /pricing을 참조하세요.
되돌릴 수 있게 설계하는 것은 모든 미래 요구를 예측하는 것이 아니라 변경을 저렴하게 만드는 것입니다. 목표는 도구(웨어하우스→레이크하우스), 모델링 접근(차원→이벤트 중심), 메트릭 정의의 변화가 전체 재작성으로 이어지지 않도록 하는 것입니다.
모델을 명확한 계약이 있는 모듈형 레이어로 취급하세요.
v2를 병렬 제공하고 소비자 마이그레이션 후 v1을 폐기.작지만 실효 있는 거버넌스를 유지하세요: 메트릭 정의가 포함된 데이터 사전, 핵심 테이블별 명시된 오너, 무엇이 왜 누가 변경했는지 기록하는 간단한 변경 로그(레포의 Markdown 파일 등).
작은 도메인(예: “orders”)에서 이 패턴을 파일럿하고 v1 계약을 게시한 뒤 최소 하나의 계획된 변경을 버전 프로세스로 실행해 보세요. 잘 되면 템플릿을 표준화하고 다음 도메인으로 확장하세요.
락인(lock-in)은 많은 다운스트림 소비자가 테이블에 의존하게 되어 변경이 너무 위험하거나 비용이 많이 들어서 더 이상 바꾸지 못하는 상태를 말합니다.
창고나 ETL 도구를 바꾸더라도, 곡물(grain), 키, 히스토리, 메트릭 정의에 담긴 의미는 대시보드, ML 피처, 통합, 그리고 공유된 비즈니스 언어 전반에 걸쳐 계약처럼 남아 있습니다.
널리 사용되는 각 테이블을 인터페이스처럼 취급하세요:
목표는 ‘절대 변경하지 않기’가 아니라 ‘놀라움 없이 변경하기’입니다.
나중에 요청될 질문을 어색한 우회 없이 답할 수 있는 grain을 선택하세요.
실용적 점검:
일대다 관계의 ‘하나’ 쪽만 모델링하면 나중에 백필이나 중복된 파생 테이블에 비용을 치르게 될 가능성이 큽니다.
자연 키(송장 번호, SKU, 소스의 customer_id)는 이해하기 쉽지만 변경되거나 충돌할 수 있습니다.
대조적으로, 서로게이트 키는 내부에서 생성되는 안정적 ID로서 소스 ID 변경에 대응해 매핑을 유지하면 안정적인 내부 정체성을 제공합니다.
예상되는 CRM 마이그레이션, M&A, 또는 여러 ID 네임스페이스가 있다면:
만약 언젠가 ‘그때 우리는 무엇을 알고 있었나?’라는 질문이 나올 수 있다면 덮어쓰기(overwrite)만으로는 부족합니다.
일반 옵션:
시간 문제는 대부분 모호함에서 옵니다, 단순히 컬럼이 없어서가 아닙니다.
실무 권장 기본값:
시맨틱 레이어(메트릭 레이어)는 원시 테이블과 실제 사용 숫자 사이의 번역표입니다. 메트릭을 한 번 정의하면 수백 개의 보고서, 알림, 실험, 예측, 성과 보상 등이 그것에 의존할 수 있습니다. 정의 변경은 기술적 변화뿐 아니라 사회적 신뢰의 문제를 만듭니다.
정책:
orders vs order_items).공유 테이블에는 명시적 계약과 테스트가 필요합니다:
스키마 변경 시 안전한 패턴:
물리적 선택은 사용자 행동을 유도합니다:
우선적으로 발생하는 접근 패턴(예: 최근 30일, account_id 기준)을 기준으로 설계하고, 백필/재처리 방식에 맞춰 파티셔닝 전략을 정하세요.
모델 변경은 대부분 ‘리팩터’가 아니라 사람들이 여전히 살고 있는 도시를 옮기는 일과 비슷합니다: 보고서는 계속 돌아가야 하고, 정의는 일관되어야 하며, 기존 가정은 대시보드와 파이프라인, 보상 체계에 깊게 박혀 있습니다.
안전한 접근:
성공 판단 기준:
변경을 싸게 만드는 것이 목적입니다. 모든 미래 요구를 예측하는 것이 아니라, 변화를 저렴하게 만드는 설계를 하세요.
원칙:
사전 체크리스트:
effective_starteffective_endis_current감사, 재무, 고객 지원, 규정 준수 관련 질문을 기준으로 선택하세요—오늘의 대시보드만 보고 결정하지 마세요.
revenue_v1revenue_v2이렇게 하면 락인이 흩어진 SQL 대신 관리되는 문서화된 계약으로 바뀝니다.
비용과 일정을 계획할 때는 이중 운영 컴퓨트와 백필 비용, 이해관계자 승인이 주요 병목임을 예산에 반영하세요. 교차 시나리오와 트레이드오프를 정리해야 하면 /pricing을 참고하세요.
경량 거버넌스: 데이터 사전, 핵심 테이블별 오너 명시, 변경 로그(레포의 Markdown 파일 등)를 운영하세요.
실용적 다음 단계: ‘orders’ 같은 작은 도메인에서 템플릿을 파일럿하고 v1 계약을 게시한 뒤, 버전 프로세스를 통해 한 번 계획된 변경을 실행해 보세요. 성공하면 템플릿을 표준화해 다음 도메인으로 확장하세요.