제3정규형까지 설계하고, 한 발 물러서라

🌐 28개 언어로도 제공

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

AI로 생성한 이미지

AI로 번역했습니다. 아직 커뮤니티의 검토를 거치지 않았습니다. 영어로 읽기

Data Architect 과정 2장인 의미를 위한 데이터 모델링의 모듈 5/6. 각 모듈은 독립적으로 읽을 수 있습니다. 이전: 데이터를 제자리에 두라 · 다음: 모델을 Salesforce로 옮겨라

이 모듈이 답하는 질문: 깔끔하게 정규화된 모델에서 언제 의도적으로 물러서야 할까요?

지난 모듈에서 저는 제3정규형까지 설계하라고 했습니다.

이제 그것을 깨라고 말하려 합니다.

가끔은요.

중요한 구분입니다. 실수로 지저분한 데이터 모델을 만드는 것과 깔끔한 모델을 의도적으로 비정규화하는 것 사이에는 큰 차이가 있습니다. 애초에 데이터가 어디에 속하는지 모른다면, 그것을 다른 곳에 복사하는 것은 아키텍처가 아닙니다. 그냥 중복입니다.

하지만 깔끔한 논리 모델을 이해하고 나면, 데이터를 소비하는 사람과 시스템을 위해 데이터의 모양을 다르게 만드는 결정을 의식적으로 내릴 수 있습니다.

가능한 곳에서는 제3정규형까지 설계하라. 그리고 필요할 때 한 발 물러서라.

그 문장이 말하지 않는 것에 주목하십시오. 제3정규형이 더 이해하기 쉽다고 말하지 않습니다. 때로는 더 어렵습니다. 완전히 정규화된 모델은 비즈니스 아이디어 하나를 개체 다섯 개에 흩어 놓을 수 있고, 쓰는 사람은 그것을 머릿속에서 다시 조립해야 합니다. 정규화는 각 사실이 어디에 속하는지 알려 줍니다. 그것이 읽고, 쓰고, 보고하기에 가장 쉬운 모양이라고 약속하지는 않습니다. 그래서 물러서는 것은 실패가 아니라 설계 기술입니다.

진실을 모델링하는 데서 시작하십시오. 그다음 그 진실을 어떻게 전달할지 정하십시오.

앉아, 기다려, 모델링

개들로 돌아갑시다. 이번에는 몇 가지를 의도적으로 선택합니다.

품종: 선택 목록인가, 독립된 테이블인가? 이 모듈 뒤에서 드릴 질문들에 넣어 보십시오. 정보 열이 둘 이상인가? 그렇습니다. 적어도 크기가 있습니다. 값이 몇 개인가? 켄넬 클럽들은 수백 개의 품종을 인정합니다(미국 켄넬 클럽만 해도 205개). 약 20개라는 제 경험칙을 훌쩍 넘습니다. 그래서 품종은 독립된 테이블이 될 자격이 있고, 각 개는 자기 품종을 가리킵니다. 모듈 1부터 들고 온 질문이 이것으로 정리됩니다. 품종은 독립된 상자입니다.

숙련도: 선택 목록. 배우는 중, 잘함, 능숙. 레이블 세 개, 그 밖에 더 할 말은 없고, 바뀌지도 않습니다. 선택 목록이 바로 그런 데 쓰는 것입니다.

개마다 재주를 몇 개 아는가? 답은 이미 모델에 있습니다. 그 개의 개 재주 레코드를 세면 됩니다. 하지만 훈련사는 테이블 두 개에 걸친 보고서를 만들지 않고도 모든 보고서에서 그 숫자로 정렬하고 필터링하고 싶어 합니다. 그래서 저는 한 발 물러서서 개에 아는 재주 수(Tricks Known)를 바로 둡니다. 그것은 사본입니다. 진실은 여전히 개 재주에 있고, 그 수는 그것의 표현이며, 보조를 맞춰야 합니다. Salesforce는 정확히 그 일을 하는 깔끔한 방법을 주고, 모듈 6에서 보게 됩니다.

이제 반전: 강아지 학교가 고양이를 받기 시작합니다. 어떻게 할까요? 한 가지 선택지는 개 테이블 옆에 고양이 테이블을, 개 재주 옆에 고양이 재주를 추가하는 것입니다. 모든 것이 두 배가 됩니다. 화면도 둘씩, 보고서도 둘씩, 그리고 토끼를 받는 날에는 셋씩. 다른 선택지는 한 발 물러서서 알아차리는 것입니다. 고양이에게도 주인이 있고, 브리더가 있을 수도 있고, 품종, 생년월일, 그리고 인내심만 있으면 재주 한두 개도 있습니다. 개와 같은 사실, 같은 관계입니다. 그래서 일반화합니다. 반려동물(Pet), 그리고 개나 고양이를 나타내는 종(Species). 각 품종도 종에 속하며, 종이 진짜로 사는 곳은 거기입니다. 래브라도는 개입니다. 반려동물은 일부러 그 사본을 가지고 다닙니다. 그래서 모든 화면과 보고서가 품종을 조회하지 않고도 “개인가 고양이인가?”로 시작할 수 있습니다. 또 하나의 의도적인 사본이고, 모듈 6에서 자기만의 일을 맡습니다.

이것이 변화를 위한 설계이고, 트레이드오프입니다. 너무 일찍 일반화하면 모든 것이 아무도 이해하지 못하는 유형 필드를 가진 모호한 “Thing”이 됩니다. 저는 비즈니스가 실제로 두 번째 종류를 가져오고, 여기서의 개와 고양이처럼 둘이 거의 모든 것을 공유할 때 일반화합니다. 고양이에게 아주 다른 사실이 필요하다면 다시 생각해 보겠습니다.

Click to enlarge

이제 같은 종류의 선택을, 걸린 것이 더 큰 Steve Trucking에서 해 봅시다.

가장 깔끔한 모델이 늘 최고의 시스템은 아니다

정차지에 있는 배송팀을 떠올려 보십시오. 배송에는 품목들이 있습니다. 설치에는 체크리스트가 있습니다. 단계마다 사진이 필요합니다. 수령인이 서명합니다.

정규화된 모델은 아름답습니다. 배송 → 배송 품목 → 설치 체크리스트 → 사진, 각자 제자리에.

그러다 실제로 쓰는 사람들과 마주 앉습니다. 배송팀은 하루에 정차지 열 곳쯤을 마감하는데, 진입로에서, 신호가 안 잡히는 경우도 많습니다. 제 아름다운 모델이 정차지 하나를 마치려고 그들을 화면과 관련 목록의 미로로 보낸다면, 저에게는 아키텍처 문제가 있는 것입니다.

우리가 설계하는 것은 데이터 모델만이 아닙니다.

우리는 시스템을 설계합니다.

때로는 사용자 경험이 이긴다

제가 완벽하게 정규화된 모델에서 가끔 물러서는 이유 중 하나가 이것입니다. 사용자 경험.

어떤 개념은 기술적으로는 독립된 엔터티가 될 수 있지만, 분리하면 거의 가치 없는 복잡성만 더할 수 있습니다. 여러 단계의 하위 레코드를 가진 상위 레코드는 학문적으로는 깔끔하지만 입력하고 관리하기엔 괴로울 수 있습니다. 개념이 작고, 안정적이고, 주로 선택지로 쓰일 수도 있습니다.

여기서 저는 **“이 사실은 이론적으로 어디에 속하는가?”**만 묻기를 멈추고 **“이 시스템은 실제로 어떻게 쓰일까?”**를 묻기 시작합니다.

클릭 하나가 늘었다는 불평마다 모델을 평평하게 하라는 뜻은 아닙니다. 사용성이 정당한 아키텍처 입력이라는 뜻입니다.

때로는 보고가 이긴다

보고도 흔한 이유입니다.

각 리테일 파트너는 지역별, 월별 정시 배송 성과표를 원합니다. 깔끔한 모델에서 배송은 자기 물류 센터를 알고, 물류 센터는 자기 지역을 압니다. 기술적으로는 그 길을 따라갈 수 있습니다.

하지만 보고 도구도 그럴 수 있을까요? 직접 보고서를 만드는 사람들도요? 질문 자체보다 더 복잡한 보고 아키텍처 없이 그 질문에 답할 수 있을까요?

그때 저는 지역을 배송에 복사하거나 파생시켜, 그것이 소비되는 곳 가까이 둘 수 있습니다.

이제 중복이 생겼습니다. 그래서 질문이 하나 더 필요합니다. 진실은 누가 소유하는가?

원천 값이 바뀌면 제 사본은 어떻게 될까요? 바뀌어야 할까요? 아니면 배송이 일어났을 때 참이었던 값을 유지해야 할까요? 서로 다른 요구사항입니다.

비정규화는 복잡성을 없애지 않습니다.

옮길 뿐입니다.

조회인가, 선택 목록인가?

Salesforce 관리자들이 늘 만나는 더 작은 예가 있습니다. 사용자는 값의 집합 중에서 골라야 합니다. 다른 엔터티를 만들어 연결할까요, 선택 목록을 쓸까요?

배송 상태를 보십시오. 예약됨, 적재됨, 배송 중, 도착 임박, 배송 완료, 설치 완료, 예외, 반품. 짧고 안정적인 레이블 목록입니다. 선택 목록이 정확히 제가 원하는 것입니다.

이제 정차지 유형을 보십시오. 배송만, 배송과 설치, 배송과 헌 제품 수거. 이것은 자기 정보를 담고 있습니다. 정차지에 걸리는 시간, 배송팀에 필요한 기술, 적용되는 설치 체크리스트. 독립적으로 바뀌고, 비즈니스가 관리합니다. 레이블이 아니라 엔터티입니다.

이론적으로 정규화할 수 있는 모든 개념마다 개체를 만들면, 기술적으로는 아름답지만 아무도 즐겨 쓰지 않는 시스템을 만들 수 있습니다. 쉽다는 이유로 모든 개념을 선택 목록으로 만들면, 아주 빨리 스스로를 구석에 몰아넣을 수 있습니다.

그래서 저는 묻습니다. 자기 정보가 있나? 관계가 있나? 독립적으로 바뀌나? 데이터로 관리해야 하나? 비즈니스가 언젠가 레이블 이상을 필요로 할 수 있나?

설계 회의에서 제가 실제로 던지는 질문들은 이렇습니다.

정보 열이 둘 이상인가? 값에 설명, 소요 시간, 기술 목록, 담당자가 필요하다면 더 이상 레이블이 아닙니다.

값이 몇 개인가? 제 경험칙은 약 20개입니다. 값이 20개를 넘으면 선택 목록이 무너지기 시작하고, 개체를 생각할 때입니다. 50개쯤인 미국 주는 우리가 감수하는 예외이고, 국가는 더 나쁩니다. 솔직히 국가 선택 목록을 좋아하는 사람이 있나요? 저는 짜증스럽습니다.

값이 시간이 지나며 만들어지나, 누가 만드나? 선택 목록 값을 추가하는 것은 구성 변경이고, 즉 관리자가 필요하다는 뜻입니다. 비즈니스가 매주 값을 추가하는데 추가하는 사람이 관리자가 아니라면, 선택 목록은 새 값마다 티켓을 하나씩 끼워 넣습니다.

사람들이 그것으로 필터링하고 보고해야 하나? 선택 목록은 그런 데 훌륭합니다. 조회는 그만큼 깔끔하지 않습니다. 조회마다 한 단계가 더 생깁니다. 보고서 유형은 관련 개체의 짧은 사슬만 따라가고(사용자 정의 보고서 유형은 개체 관계를 최대 네 개까지 허용합니다), 화면은 관련 목록 안의 관련 목록이 되며, 코드는 더 복잡해집니다.

값 목록은 흔히 선택 목록으로 시작해, 시간이 지나며 독립된 개체가 될 자격을 얻습니다. 자격을 얻게 두십시오.

Click to enlarge

때로는 규모가 답을 바꾼다

레코드 몇천 건에서 아름답게 작동하는 설계가 수백만 건에서는 전혀 다르게 동작할 수 있습니다.

그러니 다이어그램만 보지 마십시오. 숫자를 아십시오.

Steve Trucking은 1년에 약 100만 건을 배송하고, 매년 30퍼센트씩 성장합니다. 배송마다 상태 갱신이 약 여덟 번 쌓입니다. 올해 상태 레코드가 800만 건이고, 3년째에는 1년에 약 1,350만 건입니다. 여기에 1년에 사진 400만~500만 장이 더해집니다.

같은 모델. 전혀 다른 아키텍처.

규모를 고려한 아키텍처(Architecting at Scale)에서 훨씬 깊이 다룹니다. 지금은 기억하십시오. 볼륨은 데이터 모델링 결정을 바꿀 수 있습니다. 논리적으로 옳은 관계가 모든 규모에서 자동으로 최선의 물리 설계는 아닙니다.

소비자마다 원하는 모양이 다르다

지금까지는 운영 시스템을 생각했습니다. 코디네이터가 배송을 경로에 배정합니다. 배송팀이 정차지를 마감합니다. 비즈니스가 돌아가며 시스템이 바뀝니다.

하지만 비즈니스는 수년치 이력도 분석하고 싶어 합니다. 어느 파트너와 지역이 늦나? 배송 시간은 어떻게 변했나? 설치에 두 번째 방문이 얼마나 자주 필요한가?

분석 시스템은 같은 정보를 다르게 구성하기를 원할 수 있습니다. 데이터 웨어하우스, 팩트, 디멘션, 스타 스키마 같은 용어를 듣게 될 겁니다. 여기서 풀어 설명하지는 않겠습니다. Steve Trucking에서는 Snowflake 웨어하우스이고, 과정 후반에 다시 다룹니다.

지금은 이것만: 소비자마다 같은 진실의 다른 모양이 필요할 수 있습니다.

AI라는 또 하나의 소비자

그리고 이제 또 하나의 소비자가 있습니다. AI입니다.

수령인이 “제 배송 어디쯤이에요?”라고 문자를 보냅니다. AI 어시스턴트는 이런 것을 찾아볼 수 있습니다.

배송 10427, 경로 3312, 정차지 7, 트럭 117, 시간대 13:00–15:00.

전통적인 애플리케이션은 그 관계들을 따라가는 데 아무 문제가 없습니다. 하지만 수령인에게 답하려면 어시스턴트에게는 여러 곳에서 모은 맥락이 필요합니다.

고객님의 Redrock 식기세척기는 오늘 피닉스 물류 센터에서 출발한 경로의 일곱 번째 정차지입니다. 트럭은 세 정차지 전에 있고, 고객님의 오후 1~3시 시간대 안에 도착할 예정입니다.

관련된 여러 엔터티에서 정보를 가져와 특정 소비자 하나를 위한 더 평평하고 맥락이 풍부한 표현을 조립했습니다.

그렇다고 정규화된 모델을 부순다는 뜻은 아닙니다. “AI는 평평한 데이터를 좋아하니 전부 거대한 개체 하나에 넣자”는 뜻은 더더욱 아닙니다. 그러지 마십시오.

진실의 원천은 깔끔하게 유지됩니다. AI는 자기가 하는 일에 맞게 만든 표현을 받습니다. 방금 분석에서 본 것과 같은 아이디어입니다.

하나의 진실의 원천이 소비를 위한 여러 모양을 지원할 수 있습니다.

그라운딩과 검색은 과정 후반에 훨씬 깊이 다룹니다.

여러 개의 진실을 만들지 마라

여기에는 위험이 있습니다.

보고를 위해 지역을 배송에 복사하고, 평평하게 만든 버전을 Snowflake로 보내고, AI 어시스턴트를 위해 맥락이 풍부한 버전을 만들었다면, 어느 것이 맞을까요?

그 질문에는 답이 필요합니다. 저는 권위 있는 값이 어디에 있는지 알고 싶습니다. 나머지는 모두 목적에 따라 그 진실을 표현한 것입니다.

그곳이 기록 시스템(system of record)입니다. 비정규화된 사본은 좋을 수 있습니다. 정차지 화면, 성과표, Snowflake, AI 맥락은 각자 자기에게 맞게 만든 모양으로 일을 더 잘하고, 그것들을 참조하는 것은 괜찮습니다. 하지만 무언가 바뀌면 변경은 기록 시스템, 보통은 관계형 모델에서 시작해 모든 사본으로 흘러갑니다. 아무도 Snowflake에서 지역을 고치거나 AI의 맥락을 손으로 편집하지 않습니다. 원천에서 고치고, 변경이 흘러가게 하십시오.

Click to enlarge

그리고 데이터가 바뀔 때 가장 중요합니다. 오늘 물류 센터 하나가 다른 지역으로 옮겨 가면, 지난달 배송에 새 지역이 보여야 할까요? 그럴 수도, 아닐 수도 있습니다. 이력을 위해서는 배송이 일어났을 때 참이었던 지역이 필요할 수 있습니다. 그건 더 이상 동기화 문제가 아닙니다. 비즈니스 결정입니다.

그래서 비정규화는 결코 우연히 일어나서는 안 됩니다. 중복된 사실 하나하나가 소유권, 동기화, 이력, 신뢰에 대한 질문을 낳습니다. 1장의 트레이드오프 사고입니다. 무엇을 사는지(더 쉬운 화면, 더 단순한 보고서, AI를 위한 더 나은 맥락)와 무엇을 치르는지(중복 데이터, 동기화, 더 복잡한 진실의 소유권)를 아십시오. 그리고 깔끔한 논리 모델에서 시작했기에, 우리는 각 사본을 가리키며 이렇게 말할 수 있습니다. “이건 원래 저쪽에 속한다는 걸 압니다. 이 요구사항 때문에 그 표현을 여기에 둡니다.” 검토하고, 반론하고, 기록할 수 있는 결정이고, 그래서 다음 아키텍트가 이유를 알 수 있습니다.

아키텍트가 여기서 결정하는 것

비정규화를 검토할 때, 저는 이것을 결정합니다.

• 각 비즈니스 사실의 권위 있는 원천이 어디에 있는지.
• 깔끔한 모델이 사용자, 보고, 규모, 성능에 실제 문제를 만드는지.
• 더 단순한 표현이 중복을 감수할 가치가 있는지, 그리고 사본이 어떻게 믿을 만하게 유지되는지.
• 현재 원천이 바뀔 때 과거 값도 바뀌어야 하는지.
• 분석이나 AI가 운영 시스템과 다른 모양의 데이터를 필요로 하는지.

출발점은 결코 바뀌지 않습니다. 진실이 어디에 속하는지 아십시오. 그리고 요구사항이 정당화할 때, 전달을 위해 모양을 만드십시오.

다음으로 Salesforce가 다시 등장합니다. 우리가 설계한 것을 물리 데이터 모델로 바꿀 것입니다.

더 알아보기

• Build Powerful Reports with Custom Report Types (opens in a new tab), Salesforce Admins, 2019년 6월 24일(영어, 확인일 2026-10-12): 사용자 정의 보고서 유형은 “최대 4개의 개체 관계에 걸칠 수 있다.”
• Unleash the hounds, terriers and lapdogs: American Kennel Club recognizes 3 more breeds (opens in a new tab), PBS NewsHour, 2026년 1월 2일(영어, 확인일 2026-10-12): “AKC는 이 세 신규 품종을 포함해 205개 품종을 인정한다.”
• 재미로: FCI Breeds Nomenclature (opens in a new tab), 국제축견연맹(Fédération Cynologique Internationale)(영어, 확인일 2026-10-12): 국제 연맹의 품종 목록으로, 열 개 그룹으로 나뉩니다. 훑어보면 품종이 왜 독립된 테이블이 될 자격이 있었는지 알 수 있습니다.