가역성 테스트

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)

A freshly poured concrete slab sets around four anchor bolts on a steel template and upright conduits, bordered by timber formwork, with a wheelbarrow on the ground beyond. — AI로 생성한 이미지

Data Architect 과정의 첫 번째 장인 데이터 아키텍트처럼 생각하기의 모듈 3/7. 각 모듈은 독립적으로 읽을 수 있습니다. 이전: 데이터 모델은 뼈대다 · 다음: 아키텍처는 트레이드오프의 기술이다

이 모듈이 답하는 질문: 아키텍처적인 결정과 평범한 결정을 어떻게 구분할까요?

아키텍트는 많은 결정을 내립니다.

하지만 모든 결정이 아키텍처적인 결정은 아닙니다.

이 구분은 중요합니다. 모든 결정을 아키텍처로 다루면 비교적 바꾸기 쉬운 것들을 두고 논쟁하느라 시간을 다 씁니다. 정말 아키텍처적인 결정을 알아보지 못하면, 오늘 5분 만에 내린 결정을 푸는 데 5년이 걸릴 수 있습니다.

그렇다면 차이를 어떻게 알까요?

저는 단순한 질문 하나를 던지기를 좋아합니다.

이 결정을 나중에 되돌리기가 얼마나 어려울까?

저는 이것을 가역성 테스트라고 부릅니다.

되돌리기 어려울수록, 그리고 다른 것들이 그것에 더 많이 의존할수록, 더 많은 아키텍처적 주의를 기울일 가치가 있습니다.

어떤 결정은 바꾸는 비용이 적다

단순한 것부터 시작해 봅시다.

필드 이름을 고객 카테고리라고 붙였습니다. 6개월 뒤 비즈니스는 다들 실제로는 고객 세그먼트라고 부른다고 결정합니다. 레이블을 바꿉니다. 문서 몇 개를 고치고 사용자 교육을 조금 해야 할 수도 있지만, 큰 아키텍처적 사건은 아닙니다. 다만 원래 API 이름과는 함께 살아야 합니다. 그것을 바꾸는 데는 훨씬 큰 결과가 따르니까요. 그러니 이것은 레이블 변경과, 그에 따를 수 있는 혼란을 감당하는 정도의 일일 수 있습니다.

결정을 내렸습니다. 마음을 바꿨습니다. 다음으로 넘어갔습니다.

이제 다른 결정과 비교해 보십시오.

고객 식별자를 만들고 있습니다. 그것이 무엇을 의미하는지, 어떤 형식을 쓰는지, 어떤 시스템이 생성하는지 정합니다. 그리고 공개합니다.

Salesforce가 그것을 씁니다. 데이터 웨어하우스가 씁니다. 연동 플랫폼이 씁니다. 고객 포털이 씁니다. 다른 애플리케이션 다섯 개가 그것을 저장하기 시작합니다. 보고서와 데이터 파이프라인이 씁니다. 어쩌면 결국 고객도 그것을 봅니다.

3년 뒤, 누군가 말합니다.

식별자를 그렇게 설계하지 말았어야 했나 봐요.

전혀 다른 대화입니다.

차이는 한 결정이 다른 결정보다 더 기술적이라는 데 있지 않습니다.

차이는 가역성입니다.

이런 일이 어떻게 일어나는지 보십시오. 비즈니스가 고객 이름의 일부에 번호를 붙여 키를 만들어 왔다고 합시다. 몇 년 동안 잘 작동합니다. 아무도 이름을 바꿔야 했던 적이 없으니까요. 그러다 1년 이상 지나 실제로 이름이 바뀌고, 갑자기 키가 나머지 데이터가 기대하는 패턴과 맞지 않게 됩니다. 이것이 키가 어떤 고유한 의미도 담아서는 안 되는 이유 중 하나입니다.

아키텍처는 중력을 만든다

아키텍처적인 결정은 주위에 무언가를 끌어모으는 경향이 있습니다. 저는 그것을 중력이라고 생각합니다.

개체 모델을 고르면, 그 주위에 자동화가 만들어집니다.

키를 고르면, 다른 시스템들이 그것을 저장하기 시작합니다.

마스터 데이터가 있을 곳을 고르면, 연동이 그곳으로 흘러가고 그곳에서 흘러나오기 시작합니다.

공유 모델을 고르면, 비즈니스 프로세스가 누가 무엇을 볼 수 있는지에 의존하기 시작합니다.

연동 패턴을 고르면, 시스템들이 그 타이밍과 동작에 의존하기 시작합니다.

그런 결정이 오래 존재할수록 더 많은 중력이 생깁니다. 결국 원래 결정을 바꾼다는 것은 그 주위에 쌓인 모든 것을 바꾼다는 뜻이 됩니다.

AI도 그 중력을 느낍니다. AI 도구는 시스템에 이미 있는 것에서 출발합니다. 핵심 설계 요소가 일단 들어가면, 그 뒤의 모든 AI 상호작용은 그 요소를 사실로 취급하고 그 위에 짓고, 또 짓고, 또 짓습니다. 그 결정은 더 많은 결정들을 거치며 앞으로 메아리치고, 아무도 원래 결정을 다시 들여다보지 않습니다. 생성할 때마다 중력이 더해집니다.

그래서 데이터 모델이 “뼈대”라는 것이 중요합니다. 변화가 나빠서 신중한 것이 아닙니다. 의존성이 변화를 비싸게 만들기 때문에 신중한 것입니다.

두 가지 질문을 던져라

설계 결정을 볼 때 저는 두 가지 질문을 던집니다.

되돌리기가 얼마나 어려운가?

얼마나 많은 것이 그것에 의존하게 될까?

둘은 관련 있지만 같지는 않습니다. 기술적으로 바꾸기 쉬워도 사용처가 수백 곳인 것이 있습니다. 예전에는 명확성을 위해 표준 개체의 레이블을 바꾸곤 했습니다. 이를테면 계정을 “고객”으로요. 하기 쉽습니다. 그러다 다른 시스템이 계정을 파트너용으로 쓰려 했는데, 그럴 수 없었습니다. 반대로 사용처는 몇 곳뿐인데 바꾸려면 엄청난 마이그레이션이 필요한 것도 있습니다. 내부의 여러 곳에서 참조되는 개체의 API 이름처럼요. 밖에서는 아무도 보지 못하지만, 잘못 붙여 두면 팀을 계속 헷갈리게 합니다. 어느 쪽이든 주의를 기울일 가치가 있습니다.

흔한 데이터 결정 몇 가지를 생각해 보십시오.

이 비즈니스 개념을 나타내는 Salesforce 개체는 무엇인가?
고유 식별자는 무엇인가?
어느 시스템이 기록 시스템(system of record)인가?
이 데이터는 Salesforce에 복사되는가, 아니면 다른 곳에서 접근하는가?
개체 하나인가, 서로 관련된 여러 개체인가?
데이터는 누가 소유하며, 얼마나 오래 보관하는가?
기본 접근 경계는 무엇인가?
이 데이터는 시스템 사이를 어떻게 이동하는가?

이런 결정은 Lightning 페이지에서 필드를 어디에 둘지 정하는 것과 매우 다릅니다. 페이지 디자인도 중요합니다. 틀렸을 때의 비용이 다를 뿐입니다.

Click to enlarge

폭발 반경을 생각하라

가역성을 생각하는 또 다른 방법은 폭발 반경입니다. 이 결정을 바꾸면 무엇이 함께 움직일까?

필드로 모델링했던 것이 사실은 하위 개체가 되어야 한다고 합시다. 그건 단순한 스키마 변경이 아닙니다. 기존 데이터는 어떻게 될까요? 보고서, 그 필드를 기대하는 연동, 그것을 참조하는 Apex와 Flow, 보안, 분석, 원래 구조에 따라 행동이 정해지는 AI 에이전트는요?

반경이 클수록 원래 결정을 더 신중하게 내려야 합니다.

그것이 아키텍트가 자기가 맡은 시스템 부분 너머를 봐야 하는 이유이기도 합니다. Salesforce 안에서 보면 쉬워 보이는 변경도, 기업 전체에서 보면 다른 시스템 열두 개에 영향을 줄 수 있습니다.

기업 차원의 결정과 Salesforce 차원의 결정

데이터 아키텍트는 두 수준에서 생각합니다.

Salesforce 안에서는 개체, 관계, 키, 볼륨, 접근, 자동화, 그리고 플랫폼에서 데이터가 어떻게 동작하는지를 결정합니다.

기업 전체에서는 더 넓은 질문을 던집니다. 고객은 실제로 어디에 있는가? 제품은 누가 소유하는가? 주문은 어느 시스템이 생성하는가? 우리의 권위 있는 식별자는 무엇인가? 어떤 정보가 시스템 사이에 복사되고, 어떤 정보가 제자리에 머무는가?

두 수준은 연결되어야 합니다. 저는 내부 모델이 그 자체로는 완벽하게 말이 되지만 주변 기업과는 맞지 않는 Salesforce 구현을 본 적이 있습니다. 그것으로는 부족합니다. Salesforce의 구조는 기업 수준에서 표현되어야 하고, 기업의 결정은 다시 Salesforce로 흘러들어야 합니다.

아키텍처는 양방향 통행입니다.

Click to enlarge

비용이 큰 결정에서는 속도를 늦춰라

기술 분야의 위험 하나는 구현하기 가장 쉬운 결정이 내리기도 가장 쉬운 결정처럼 보일 수 있다는 것입니다. 둘은 같은 것이 아닙니다.

사용자 정의 개체를 하나 더 만드는 것은 쉽습니다. 필드를 하나 더 만드는 것도 쉽습니다. API를 하나 더 연결하는 것도 점점 쉬워지고 있고, AI는 그 모든 것을 더 쉽게 만듭니다.

하지만 구현의 쉬움은 아키텍처적 결정의 비용에 대해 거의 아무것도 말해 주지 않습니다.

되돌리기 어려운 결정 앞에서는 잠시 멈춰서 물으십시오. 우리가 실제로 푸는 문제는 무엇인가? 어떤 대안을 검토했는가? 무엇을 가정하고 있는가? 볼륨이 커지면, 비즈니스가 바뀌면 어떻게 되는가? 또 무엇이 이것에 의존하게 될까? 틀리면 어떻게 되는가?

개체를 만들 때마다 6개월씩 검토할 필요는 없습니다. 하지만 틀렸을 때의 비용에 비례하는 숙고는 필요합니다. 한 부서나 하위 시스템만을 위한 개체라면 더 빨리 움직여도 됩니다. 참조 데이터나 핵심 고객 개체, 여러 시스템에서 쓰는 것이라면 시간을 들여 충분히 생각하십시오.

이유를 기록하라

중요한 결정에는 또 다른 문제가 있습니다. 사람들은 그 결정이 왜 내려졌는지 잊어버립니다.

3년 뒤 누군가 아키텍처를 보고 묻습니다. “대체 누가 이렇게 설계한 거지?” 때로는 정말 나쁜 설계였다는 게 답입니다. 그런 일도 있습니다. 하지만 때로는 아주 좋은 이유가 있었습니다. 지금은 사라진 플랫폼 제약, 규제 요건, 선호하는 방식을 지원하지 못했던 다른 시스템, 마감을 맞추려고 알면서 받아들인 트레이드오프.

우리가 결정한 무엇만 기록하고 왜를 기록하지 않으면, 다음 아키텍트는 알 길이 없습니다.

중요한 결정은 적어 두십시오. 50쪽짜리 문서일 필요는 없습니다. 쓸모 있는 의사결정 기록은 아주 짧을 수 있습니다.

맥락: 어떤 문제를 풀고 있는가?

선택지: 어떤 현실적인 대안을 검토했는가?

결정: 무엇을 선택했는가?

결과: 무엇을 얻고, 무엇을 포기하는가?

책임자: 이 결정에 누가 책임을 지는가?

검토: 어떤 이유나 날짜가 되면 다시 살펴봐야 하는가?

가치는 문서에 있지 않습니다. 가치는 추론을 보존하는 데 있습니다.

그리고 결정이 바뀌면 원래 결정을 지우지 마십시오. 대체하십시오. 2027년에 옳았던 결정이 2030년에는 옳지 않을 수 있습니다. 볼륨도, 비즈니스도, Salesforce도, 우리의 이해도 모두 바뀌니까요. 제가 남기고 싶은 것은 이야기입니다. 이런 맥락이 있었고, 이런 결정을 이런 이유로 내렸고, 이런 것이 바뀌었고, 그래서 지금 이렇게 결정한다. 늘 답을 알고 있었던 척하는 것보다 훨씬 가치 있습니다.

Click to enlarge

시험 너머: AI는 결정에서 의존성까지의 시간을 줄인다. AI 도구는 몇 초 만에 데이터 모델을 제안하고, 그 위에 개체, 자동화, 연동 코드, 사용자 인터페이스까지 만들 수 있습니다. 예전에는 의심스러운 결정 위에 많은 것이 의존하게 되기까지 몇 달의 개발이 필요했지만, 이제는 의존성이 거의 즉시 생깁니다. 그러니 결과물만이 아니라 결과물 아래의 결정을 검토하십시오. AI는 도움이 됩니다. 선택지를 나열하고, 가정에 이의를 제기하고, 의사결정 기록의 초안을 쓸 수 있습니다. 하지만 결정은 여전히 아키텍트가 내리고, 되돌리기 어려운 결정일수록 인간의 판단이 더 중요합니다.

어떤 결정이 중요한지 알라

제가 여러분이 기르기를 바라는 기술 중 하나는 어디에 주의를 쏟을지 아는 것입니다.

모든 구성 선택을 아키텍처 정상회담으로 만들지 마십시오.

하지만 조직이 앞으로 10년을 함께 살아야 할 결정을 가볍게 내리지도 마십시오.

물으십시오.

되돌리기가 얼마나 어려울까?

얼마나 많은 것이 그것에 의존하게 될까?

답이 매우 어렵다와 많다라면, 아마 아키텍처적인 결정을 찾은 것입니다.

Click to enlarge

속도를 늦추십시오. 요구사항을 이해하십시오. 대안을 탐색하십시오. 트레이드오프를 드러내십시오. 결정하십시오. 그리고 이유를 기록하십시오.

아키텍처의 목표는 절대 바뀌지 않을 결정을 내리는 것이 아닙니다.

목표는 마음을 바꾸는 비용이 클 결정을 알아보는 것입니다.

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

어떤 결정이 아키텍처적인지: 되돌리기 어렵고, 많은 것이 그것에 의존하는 결정.
각 결정에 틀렸을 때의 비용에 비례해 얼마나 주의를 기울일지.
어떤 결정을 맥락, 선택지, 결과, 책임자, 검토 시점과 함께 기록할지.
Salesforce 차원의 결정이 기업 차원의 결정과 어떻게 맞물리는지.

더 알아보기

Object Relationships Overview (opens in a new tab), Salesforce 도움말(영어, 확인일 2026-10-09, 재확인일 2026-10-12): 마스터-세부 사항 관계에서 세부 사항의 접근과 소유권은 마스터를 따르며, 마스터를 삭제하면 세부 사항도 삭제된다.
Considerations for Object Relationships (opens in a new tab), Salesforce 도움말(영어, 확인일 2026-10-09, 재확인일 2026-10-12): 조회 관계는 모든 레코드에 값이 있을 때만 마스터-세부 사항으로 변환되며, 변환하면 공유 모델이 바뀌고(Controlled by Parent로), 관계 유형에 따라 사용할 수 있는 표준 보고서 유형이 정해진다.
Roll-Up Summary Field (opens in a new tab), Salesforce 도움말(영어, 확인일 2026-10-09, 재확인일 2026-10-12): 롤업 요약은 마스터-세부 사항 관계에만 있으며, 마스터-세부 사항을 조회 관계로 바꾸려면 먼저 삭제해야 한다.