데이터 모델은 뼈대다
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)
Data Architect 과정의 첫 번째 장인 데이터 아키텍트처럼 생각하기의 모듈 2/7. 각 모듈은 독립적으로 읽을 수 있습니다. 이전: 아키텍트처럼 생각하기 · 다음: 가역성 테스트
이 모듈이 답하는 질문: 왜 데이터 모델이 그 위에 세워진 무엇보다 중요하며, 어떻게 판단할까요?
데이터 아키텍처를 가르칠 때 제가 거듭 돌아오는 문장이 있습니다. 데이터 모델은 뼈대다.
데이터 모델은 시스템의 뼈대입니다. 나머지는 모두 그 주위에 세워지고, 몸의 나머지를 붙잡아 주는 것도 그것입니다. 누군가를 볼 때 뼈는 보이지 않지만, 그 사람이 얼마나 곧게 서는지, 어떻게 움직이는지, 무엇을 들 수 있는지는 뼈가 정합니다.
Salesforce 구현에서 우리가 만드는 모든 것을 생각해 보십시오. 데이터 모델을 중심으로 자동화를 만듭니다. 그것을 대상으로 Apex를 쓰고, 그것을 읽고 갱신하는 Flow를 만듭니다. 데이터를 넣고 빼는 연동을 만듭니다. 그 위에 보고서와 분석을 만들고, 그것을 둘러싸고 보안을 설계합니다. 그리고 점점 더, 그 데이터를 이해하고 그에 따라 행동해야 하는 AI 에이전트를 만듭니다. 모두가 그 아래의 구조에 의존합니다.
그래서 데이터 모델을 초기에 제대로 잡는 것이 그토록 중요합니다. 뼈대는 나중에 바꿀 수 있습니다. 하지만 아마 아플 겁니다.
비즈니스에서 시작하라
섹션 제목: “비즈니스에서 시작하라 ”좋은 데이터 모델은 단순한 질문에서 시작합니다. 비즈니스가 실제로 표현해야 하는 것은 무엇인가? “어떤 Salesforce 개체가 있지?”가 아닙니다. “빨리 만들 수 있는 게 뭐지?”는 더더욱 아닙니다.
우리는 먼저 비즈니스를 이해하려 합니다. 이 비즈니스에서 중요한 것은 무엇인가? 그것들은 어떻게 연결되는가? 누가 소유하는가? 시간이 지나며 어떻게 변하는가? 무엇을 기억해야 하고, 무엇이 비즈니스 프로세스들 사이에서 공유되는가? 이것들을 이해한 뒤에야 개체, 필드, 관계로 옮기기 시작해야 합니다.
당연하게 들립니다. 실제로는 거꾸로 하기가 아주 쉽습니다. 누군가 기회나 케이스나 자산처럼 보이는 것을 알아보고 곧바로 그것을 중심으로 설계를 시작합니다. 때로는 그게 정확히 맞습니다. 때로는 네모난 말뚝을 둥근 구멍에 넣으려는 것이고, 그 결정을 중심으로 충분히 많은 것이 만들어지고 나면 말뚝을 다시 빼는 비용이 매우 커집니다.
제가 늘 듣는 질문이 있습니다. 고객사가 배송지를 여러 곳 가질 수 있습니다. 각 배송지를 계정으로 해야 할까요, 사용자 정의 개체로 해야 할까요? 답하기 전에 먼저 알아야 할 것을 보십시오. 이 비즈니스에서 배송지가 무엇을 의미하는지, 그리고 그것에 무슨 일이 일어나는지. 그것이 개체보다 비즈니스를 먼저 모델링하는 것입니다. (제 답은 3장에서 드리겠습니다.)
지원. 성장. 성능.
섹션 제목: “지원. 성장. 성능. ”데이터 모델을 볼 때 저는 세 가지 시험을 통과하기를 원합니다. 비즈니스를 지원하고, 비즈니스와 함께 성장하고, 성능을 내는 것.
지원. 모델은 비즈니스가 실제로 이루려는 것을 지원해야 합니다. 기술적으로 데이터를 저장할 수 있는 모델과 비즈니스를 잘 표현하는 모델 사이에는 큰 차이가 있습니다. 모델이 잘 맞지 않아서 이상한 필드, 특수 플래그, 복잡한 자동화와 예외를 계속 추가하고 있다면, 저는 정말 자동화가 문제인지 묻기 시작합니다. 어쩌면 모델이 틀렸을지도 모릅니다. 좋은 모델은 비즈니스를 더 이해하기 쉽게 만들어야지, 더 어렵게 만들면 안 됩니다.
성장. 성장이라고 할 때 레코드가 더 많아지는 것만 뜻하지 않습니다. 볼륨은 중요합니다. 레코드 1만 건과 1억 건은 전혀 다른 문제를 만듭니다. 하지만 비즈니스는 복잡성에서도 성장합니다. 제품을 추가하고, 새 시장에 들어가고, 회사를 인수하고, 프로세스를 바꾸고, 채널을 늘리고, 새 시스템을 연결합니다. 하나라고 생각했던 것이 실제로는 다섯 가지 다른 것임을 알게 됩니다. 오늘 아름답게 작동하는 모델도 내일을 위한 여지가 없으면 함정이 될 수 있습니다. 그래서 저는 이미 있는 것을 계속 바꾸는 설계보다 추가를 통해 성장하는 설계를 선호합니다. 새것을 추가하는 것은 보통 수십 가지가 의존하는 것을 재정의하는 것보다 쉽습니다.
성능. 데이터는 가만히 있지 않습니다. 우리는 데이터를 쓰고, 찾고, 조회하고, 공유하고, 보고하고, 연동하며, 점점 더 AI 시스템이 행동하기 전에 맥락으로 데이터를 가져옵니다. 다이어그램에서는 아름다워 보여도 운영하기에는 끔찍한 모델이 있을 수 있습니다. 그래서 우리는 데이터가 어떻게 저장되는지와 데이터가 어떻게 쓰일지 둘 다를 위해 설계합니다.
그리고 계속 성능을 내야 합니다. 규모가 커져도 성능을 내야 합니다. 사용자 수가 늘 때, 데이터 볼륨이 늘 때, 실제 조건과 최대치에서, 평균적인 날이 아니라 한 해 중 가장 바쁜 날에도. 그리고 예상치 못한 일이 일어나도 계속 성능을 내야 합니다.
지원. 성장. 성능. 이 과정 내내 이 세 가지 시험으로 돌아오겠습니다.
너무 평평하거나, 너무 복잡하거나, 그냥 틀리거나
섹션 제목: “너무 평평하거나, 너무 복잡하거나, 그냥 틀리거나 ”저는 데이터 모델이 세 가지 방식으로 잘못되는 것을 봐 왔습니다.
첫째는 처음부터 잘못된 것을 고르는 것입니다. 충분히 비슷해 보인다는 이유로 표준 개체를 쓰고, 애초에 맞지 않았기 때문에 몇 년 동안 예외를 덧붙입니다. 그것이 네모난 말뚝입니다.
둘째는 모델을 너무 평평하게 만드는 것입니다. 모든 것을 개체 하나에 넣고, 처음에는 그게 멋지게 단순해 보입니다. 그러다 비즈니스가 성장하고, 그중 일부는 자기만의 생명주기가 있고, 여러 인스턴스를 가질 수 있고, 별도의 보안이 필요하거나 자기만의 관계가 있다는 걸 알게 됩니다. 갑자기 우리는 일대다 관계를 필드 1, 필드 2, 필드 3으로, 또는 점점 더 복잡해지는 플래그와 자동화로 표현하고 있습니다. 모델이 성장할 자리를 남겨 두지 않은 것입니다.
셋째는 반대의 실수입니다. 과도하게 정규화합니다. 개체 뒤에 개체가 이어지고 모든 개념이 완벽하게 분리된 우아한 다이어그램을 만듭니다. 기술적으로는 아름답지만 실제로는 괴롭습니다. 사용자는 이해하기 힘들어하고, 관련 목록이 줄줄이 달린 페이지 레이아웃과 Lightning 페이지는 끝없이 깊게 느껴질 수 있습니다. 쿼리는 더 복잡해지고, 자동화는 더 많은 관계를 넘나들고, 보고는 더 어려워지고, 플랫폼은 평범한 비즈니스 질문에 답하려고 더 많은 일을 합니다.
그렇다면 평평한 것과 정규화된 것 중 무엇이 맞을까요? 공식은 없습니다. 머릿속에 최적의 모델을 그려 두고, 거기서 멀어질 때의 트레이드오프를 이해하는 것입니다. 그것이 아키텍처의 기술이며, 모듈 4와 모델링하는 법을 배우는 다음 장에서 다시 다룹니다. 지금은 구조 자체가 아키텍처적인 결정이라는 것을 알아 두십시오.
뼈대를 바꿀 때는 조심하라
섹션 제목: “뼈대를 바꿀 때는 조심하라 ”시스템이 운영되기 시작하면 저는 데이터 모델의 근본적인 변경에 매우 신중해집니다.
텍스트 필드가 몇 년째 있었는데 누군가 “이제 그렇게 쓰지 않아요. 숫자로 바꿉시다”라고 말한다고 해 봅시다. 필드 하나 바꾸는 일처럼 들립니다. 하지만 그 필드에 무엇이 의존하고 있을까요? Flow, Apex, 보고서, 연동, 데이터 파이프라인, 외부 애플리케이션, AI 에이전트. 그리고 과거 데이터는 어떻게 될까요? 코드나 Flow가 아직 참조하는 동안에는 플랫폼 자체가 필드 유형 변경을 허락하지 않는데, 그것만 봐도 그 변경이 얼마나 멀리까지 미치는지 알 수 있습니다.
때로는 이미 있는 것을 바꾸지 않는 것이 정답입니다. 변경이 얼마나 심각한지에 따라, 저는 새로운 것을 만들고, 신중하게 마이그레이션하고, 옛 구조를 폐기 예정으로 두는 쪽을 택합니다.
바꾸기보다 추가하라. 놀라게 하기보다 폐기 예고를 하라.
Salesforce는 메타데이터로 그것을 표현할 방법도 줍니다. 필드의 Field Usage를 DeprecateCandidate, 즉 “폐기 예정이며 더 이상 사용하지 않음”으로 설정할 수 있습니다. 그러면 그 개체를 읽는 모든 사람에게 필드가 표시됩니다. 필드를 숨기지는 않으므로, 그것을 실제로 퇴역시키는 것은 여전히 당신이 실행해야 할 결정입니다.
아키텍처의 다른 부분이 무언가에 의존하기 시작하면, 그 의미를 바꾸는 것이 이름을 바꾸는 것보다 훨씬 위험할 수 있기 때문입니다. 최악은 이름은 그대로인데 내용이 바뀌는 필드입니다. 하류의 모든 것이 여전히 그 이름을 믿습니다.
필드에 필수 상자를 체크하는 것처럼 단순한 일도 시한폭탄이 될 수 있습니다. 이미 데이터를 수집했다면 일부 레코드에는 그 필드가 비어 있습니다. 그리고 며칠, 몇 주, 몇 달 뒤에 누군가 그 레코드 중 하나를 갱신하면, 필수 필드 때문에 저장이 실패하고, 아무도 그 값을 갖고 있지 않습니다. 필드를 필수로 지정하는 단순한 변경이 의도치 않은, 그리고 뒤늦은 결과를 낳을 수 있습니다. 필수, 그리고 값이 실제로 언제 알려지는지는 3장에서 다시 다룹니다.
시험 너머: AI도 뼈대 위에 짓는다. AI 도구에 애플리케이션을 만들어 달라고 하면 개체, 필드, Flow, Apex, 컴포넌트, 테스트를 몇 분 만에 생성합니다. 원래 데이터 모델이 틀렸다면, 우리는 나쁜 결정의 결과를 피한 것이 아니라 가속한 것입니다. 생성된 모든 층이 그 구조에 의존하는 또 하나가 되기 때문입니다. 그래서 저는 인간 아키텍트가 AI가 생성한 데이터 모델을 검토하고, 이해하고, 책임지기를 원합니다. 모듈 7에서 이를 더 깊이 다룹니다.
뼈대가 먼저다
섹션 제목: “뼈대가 먼저다 ”이 과정에서 우리는 많은 기술을 다룰 것입니다. 개체와 관계, 대용량 데이터, 쿼리, 연동, 마이그레이션, 트랜잭션, 보안, Data 360, 그리고 AI. 그 모든 것의 아래에 데이터 모델이 있습니다.
모델이 비즈니스를 지원하고, 비즈니스와 함께 성장할 수 있고, 우리가 데이터를 쓰려는 방식에서 성능을 낸다면, 우리는 튼튼한 기반을 세운 것입니다. 기반을 잘못 놓으면 그 뒤의 모든 것이 더 어려워집니다.
데이터 모델은 뼈대다. 아키텍트는 뼈대를 설계할 때 매우 신중해야 합니다. 기존 구조를 바꾸면 연쇄적인 결과가 생길 수 있습니다.
아키텍트가 여기서 결정하는 것
섹션 제목: “아키텍트가 여기서 결정하는 것 ”- 모델이 비즈니스를 지원하는지, 함께 성장할 수 있는지, 데이터가 쓰일 방식에서 성능을 내는지.
- 어떤 개념이 표준 개체에 맞는지, 아니면 네모난 말뚝인지.
- 모델을 얼마나 평평하게, 또는 얼마나 정규화할지, 그리고 그 이유.
- 뼈대에 대한 변경을 제자리에서 바꾸는 대신 추가, 마이그레이션, 폐기 예고 중 무엇으로 할지.
더 알아보기
섹션 제목: “더 알아보기 ”- Considerations for Converting the Field Type of a Custom Field (opens in a new tab), Salesforce 도움말(영어, 확인일 2026-10-02, 재확인일 2026-10-12): 어떤 유형 변경이 데이터를 잃을 수 있는지, 그리고 Apex, Flow, 프로세스가 참조하는 필드의 유형을 왜 바꿀 수 없는지.
- Data Classification Metadata Fields (opens in a new tab), Salesforce 도움말(영어, 확인일 2026-10-02, 재확인일 2026-10-12): Field Usage 값(Active, DeprecateCandidate, Hidden)과 그 밖의 분류 필드.