데이터를 일관되게 유지하기

🌐 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 과정 3장인 Salesforce 데이터 아키텍처의 모듈 9/10. 각 모듈은 독립적으로 읽을 수 있습니다. 이전: 소유권과 생명주기 · 다음: Salesforce 물리 모델을 설계하라

이 모듈이 답하는 질문: 데이터를 어떻게 일관되게 유지하며, 각 층의 비용은 얼마일까요?

모두가 깨끗한 데이터를 원합니다. 요구사항 회의에서 누군가 “우리가 정말 원하는 건 일관성 없는 데이터예요”라고 말하는 걸 들어 본 적이 없습니다. 의견이 갈리는 건 그다음입니다. 규칙을 어디서 시행할까? 화면에서? 필수 필드? 선택 목록, 유효성 규칙, 중복 규칙, Flow, Apex? 모두 도움이 됩니다. 서로 바꿔 쓸 수는 없고, 모든 층에는 비용이 있습니다.

제 일반 원칙은 규칙을 합리적으로 가능한 만큼 아래로 내리라는 것입니다. 값이 다섯 가지 중 하나여야 한다면 사람들이 아무거나 입력하게 두고 나중에 자동화로 정리하지 마십시오. 두 레코드가 식별자를 공유해서는 절대 안 된다면 누군가 보고서에서 발견하기를 기대하지 마십시오. 레코드가 화면, API, 연동, 데이터 적재, 에이전트 어디서 오든 규칙이 지켜져야 한다면 UI에서만 시행하지 마십시오. 규칙이 데이터에 가까울수록 우회하기 어렵습니다. 저는 이것을 일관성 사다리라고 부릅니다.

첫 번째 칸: 필드 유형과 어휘

첫 일관성 규칙은 모듈 6의 그것입니다. 올바른 유형을 골라라. 날짜는 날짜, 시점은 날짜/시간, 돈은 통화. 누군가 규칙을 쓰기 전의 일관성입니다.

배송 상태를 텍스트 필드로 만들면 Delivered, delivered, DELIVERED, Complete, Done, Dropped off를 얻게 되고, 누군가는 그 여섯 개가 같은 뜻인지 알아내야 합니다. 아니면 어휘를 한 번 정의하십시오. 배송 완료, 값 하나, 의미 하나. 그것을 제한된 선택 목록으로 만들어 API를 통해서도 목록에 없는 것은 무엇이든 거부하게 하고, 여러 필드가 목록을 공유한다면 글로벌 값 세트로 만드십시오(자세한 내용은 모듈 6에 있습니다).

하지만 입력을 막으려고만 선택 목록을 쓰지는 마십시오. 정말 값인가요, 다른 엔터티인가요? 이름만 있는 물류 센터 아홉 곳은 선택 목록처럼 보일 수 있지만, 주소, 센터장, 처리 용량, 트럭이 있는 아홉 곳은 레코드입니다. 규칙은 모델을 강화해야지, 나쁜 모델을 보상해서는 안 됩니다. 그리고 정말 통제된 어휘라면 필드에서 통제하십시오. 혼란을 허용해 놓고 AZ, Arizona, Ariz, Phoenix area를 애초에 원했던 값으로 바꾸는 Flow를 만들지 마십시오.

두 번째 칸: 필수와 고유

필수와 고유는 단순해서 매력적입니다. 체크하면 문제 해결. 가끔은요. 모든 트럭이 생성되는 날부터 차량 번호를 가지고 두 트럭이 같은 번호를 쓰지 않는다면, 두 체크박스 모두 진짜 비즈니스 규칙을 표현합니다. 강한 일관성입니다.

하지만 플랫폼이 규칙을 시행하기 시작하면, 당신의 프로세스에 화요일 오후의 예외가 있다는 건 신경 쓰지 않습니다. 저는 이 예를 수업에서 몇 년째 써 왔습니다. 한동안 써 온 개체에 레코드가 많습니다. 누군가 필드를 추가하고 필수를 체크합니다. 레코드를 만들어 테스트합니다. 아름답게 작동합니다. 그러다 토요일 밤 배포, 테스트가 돌고, 오래된 테스트 클래스가 새 필드 없이 그 개체를 만듭니다. 쾅. 또는 누군가 그 필드가 생기기 전의 옛 레코드를 편집합니다. 또는 연동이 5년째 보내던 같은 페이로드를 보냅니다. 쾅. “그 필드는 바꾸지도 않았는데요.” 플랫폼은 상관하지 않습니다. 유효한 레코드가 무엇인지에 대한 계약을 바꾼 겁니다. 새 규칙은 새 데이터에만 영향을 주지 않습니다. 옛 데이터로 할 수 있는 일을 바꿉니다.

세 번째 칸: 유효성 규칙

유효성 규칙으로는 훨씬 풍부한 것을 말할 수 있습니다. 상태가 배송 완료라면 실제 배송 시각이 채워져 있어야 한다. 정차지가 설치라면 체크리스트가 완료되어야 정차지를 마감할 수 있다. 레코드가 저장될 때 실행되므로, 페이지, API, 데이터 적재, 연동, 에이전트 어디서 저장되든 레코드를 보호합니다. 그것이 핵심입니다. 규칙이 레코드를 보호해야 한다면, 모든 쓰기가 마주치는 곳에 두십시오.

그리고 이빨이 있습니다. 그것이 장점이자 비용입니다.

옛 레코드 문제

여기서 상황이 험해집니다. 레코드가 100만 건 있고, 오늘 규칙을 추가합니다. 배송 시각은 경로 출발보다 이를 수 없다. 합리적입니다. 하지만 7년 전 마이그레이션 탓에 옛 레코드 2만 건이 그것을 위반합니다. 사용자가 그중 하나를 열어 전화번호를 바꿉니다. 저장. 규칙이 발동합니다. “전화번호를 바꿨는데 왜 2019년 배송 시각 얘기를 하죠?” 정당한 질문입니다.

그래서 유효성 규칙은 무엇이 참이어야 하는지만 말해서는 안 됩니다. 언제 시행할지도 말해야 합니다. ISNEW()와 ISCHANGED() 같은 함수로 규칙을 새 레코드나 관련 필드가 실제로 바뀌는 저장으로 한정할 수 있습니다(Validation Rule Considerations (opens in a new tab)).

하지만 레코드는 사람이 편집할 때만 바뀌는 게 아니고, 그 이유의 상당수는 당신의 통제 밖에 있습니다. 연동이 밤사이 상태를 갱신합니다. Flow가 날짜를 찍습니다. 관리자가 영역을 재배정하면 레코드 1만 건의 소유자가 바뀝니다. 누군가 배송 품목을 편집하면 배송의 롤업이 다시 계산되고, 그것이 배송을 저장하므로, 배송을 건드린 적도 없는 사용자에게 배송의 유효성 규칙이 발동합니다(Roll-Up Summary Field (opens in a new tab)는 유효성 오류가 세부 사항이나 마스터에 나타날 수 있다고 경고합니다). 그 저장 하나하나가 새 규칙을 만납니다. 그러니 새 규칙마다 물으십시오. 이 규칙이 그 저장에 적용되어야 하는가?

선택지는 이렇고, 이것들을 규칙에 엮어 넣습니다.

• 항상, 모든 저장에서. 규칙이 정말 레코드에 관한 것이고 옛 데이터가 통과할 때 맞습니다. 하지만 “모든 저장”이 무엇을 뜻하는지 알아 두십시오. 소유자만 바꾸는 배치 작업도, 레코드 어디든 어떤 필드의 사소한 편집도 그것을 통과해야 합니다.
• 새 레코드에만, ISNEW()로. 규칙은 레코드가 만들어질 때 한 번 확인하고 다시는 확인하지 않습니다. 과거는 그대로 남지만, 미래도 마찬가지입니다. 나중의 편집으로 새 레코드가 규칙을 어겨도 아무도 막지 않습니다. 그게 중요하다면 다음 것과 짝지으십시오.
• 규칙이 다루는 필드가 바뀔 때만, ISCHANGED()로. 전화번호를 편집해도 배송 시각 규칙은 깨어나지 않습니다.
• 특정 작성자는 제외. 수식에서 $Permission으로 확인하는 사용자 정의 권한은 사람들에게는 규칙을 계속 적용하면서 연동 사용자나 데이터 마이그레이션은 통과시킵니다(How to Reference a Custom Permission in a Validation Rule (opens in a new tab)). 의도적으로, 소수에게만 주십시오.
• 특정 날짜부터, CreatedDate를 규칙이 시행된 날과 비교해서. “새로운”이 “이것을 시행하기 시작한 이후”를 뜻할 때입니다. ISNEW()와 달리 그 레코드들을 이후의 모든 저장에서 계속 확인하므로 같은 경고가 적용됩니다. 배치 소유자 갱신 같은 사소한 변경이, 그사이 어긋나 버린 레코드에서 실패할 수 있습니다.

이미 있는 레코드에 규칙을 추가하나요? 켜기 전에 파급 효과를 끝까지 생각하십시오. 이제 기존 레코드 모두가 다음 저장에서 그것을 통과해야 하고, 그 저장은 예상치 못한 곳에서 올 수 있습니다. 야간 연동, 배치 소유자 변경, 롤업, 목록 보기에서의 대량 갱신. 그중 무엇이 규칙에 부딪히고, 레코드 하나가 실패하면 그 작업은 어떻게 될까요? 켜기 전에 섹션에 제가 쓰는 순서가 있습니다.

규칙을 만족시키려고 과거를 다시 쓰지 마라

옛 레코드 2만 건은 어떻게 할까요? 데이터가 틀렸고 올바른 값을 안다면 고치십시오. 하지만 다른 종류의 “수정”도 봤습니다. 과거의 진실은 아무도 모르고, 레코드가 통과하기만 하면 되니 오늘의 규칙을 만족하는 값으로 갱신하는 것입니다. 저는 그게 싫습니다. 옛 레코드를 규칙에 맞추려고 갱신하면 LastModifiedDate가 바뀌어 중요한 이력 정보가 파괴되고, 값을 지어내는 것은 과거에 대해 모르는 것을 아는 척하는 것입니다. 과거를 다시 쓰는 대신 규칙보다 먼저 존재한 레코드에 대해 우회를 두십시오. 보기 흉할 수 있지만 정직합니다.

UI 유효성 검사는 데이터 유효성 검사가 아니다

페이지 레이아웃에서 필드를 필수로 만들면 사용자는 그것 없이 저장할 수 없습니다. 그러다 야간 연동이 레코드 5만 건을 삽입합니다. 그것이 당신의 페이지를 거쳤나요? 아닙니다. 대량 적재도, API 클라이언트도, 에이전트도 아닙니다. UI 요구사항은 데이터가 아니라 그 화면을 보호합니다. 동적 양식의 필드 유효성 검사도 같은 식으로 피해 갈 수 있습니다. 그러니 물으십시오. 이 데이터는 어디로 들어올 수 있는가? Lightning, 포털, 모바일, 연동, API, 대량 적재, Flow, Apex, 에이전트. 문이 많을수록 그중 하나만 지키는 규칙을 덜 믿게 됩니다.

네 번째 칸: 중복 규칙

이제 레코드 안의 일관성에서 레코드 사이의 일관성으로 넘어갑니다. Acme Corporation, ACME Corp, Acme Inc. 고객이 넷일까요, 하나일까요? 필드 규칙으로는 답할 수 없습니다. 일치 규칙은 레코드를 어떻게 비교할지 정하고, 중복 규칙은 중복 가능성이 있는 것을 찾았을 때 무엇을 할지 정합니다. 경고와 함께 허용, 차단, 또는 보고. 개체당 활성 중복 규칙은 최대 5개, 각 규칙에 일치 규칙은 최대 3개이며, 일치 키가 각 비교를 가장 가능성 높은 중복 100건으로 좁힙니다(Things to Know About Duplicate Rules (opens in a new tab)).

비용은 마찰입니다. 영업 담당자가 만드는 계정마다 중복 가능성 있음이 뜬다면, 때로는 정확히 원하는 것이고, 때로는 사람들이 읽지도 않고 클릭해 넘기는 법을 배웁니다. 정당한 레코드끼리도 비슷해 보일 수 있고, 연동에는 사람과 다른 동작이 필요할 수 있습니다. 그리고 그 경고는 Salesforce 자체의 것입니다. 그 알림과 중복 가능성 목록은 당신이 만든 사용자 정의 화면과 어울리지 않을 수 있고, 저장이 헤드리스(headless)일 때, 즉 연동, 데이터 적재, 에이전트일 때는 그것을 보여 줄 화면이 아예 없습니다. 그러니 모든 경로에서 중복이 어떻게 드러날지 정하십시오. 사람에게는 경고, API에는 차단된 저장과 오류, 또는 나중에 누군가 검토하도록 보고 옵션과 중복 레코드 세트. 좋은 아키텍처는 최대한의 시행이 아니라 올바른 시행입니다.

그리고 중복 규칙이 실제로 어떤 문을 지키는지 확인하십시오(Things to Know About Duplicate Rules (opens in a new tab)). API와 데이터 가져오기 도구를 통해서는 아무도 경고를 보지 못합니다. 경고로 설정한 규칙은 그냥 저장을 차단합니다. 어떤 경로는 규칙을 아예 건너뜁니다. 빠른 생성(Quick Create), 삭제 취소(Undelete) 버튼, 수동 병합, Lightning Sync나 Einstein Activity Capture가 추가한 레코드. 그리고 같은 순간에 저장된 레코드끼리는 서로 비교되지 않고, 이미 Salesforce에 있는 레코드와만 비교됩니다. 같은 고객이 두 번 들어 있는 파일을 적재하면 두 행 모두 통과할 수 있습니다. 중복 규칙은 좋은 그물입니다. 문의 자물쇠는 아닙니다.

시험 포인트. 중복 규칙은 같은 순간에 저장된 레코드끼리 비교하지 않고, 이미 Salesforce에 있는 레코드와만 비교합니다. API와 가져오기 도구에는 경고가 없습니다. 규칙이 잡아낸 중복은 그냥 저장되지 않습니다. 그리고 저장과 그것이 일으키는 모든 것은 하나의 트랜잭션으로 실행됩니다. 어느 부분이든 실패하면 전부 롤백됩니다.

경계 하나. 중복 규칙은 org 하나를 깨끗하게 유지합니다. 기업 차원의 정체성은 해결하지 않습니다. Salesforce에는 Acme Corporation, ERP에는 ACME-10382, 청구 시스템에는 고객 77193이 있다면, 중복 규칙은 그것들이 같은 회사라고 말해 줄 수 없습니다. 그것은 마스터 데이터, 6장입니다.

다섯 번째 칸: 자동화

어떤 규칙은 아래 칸에 담기엔 너무 복잡합니다. 관련 레코드, 다른 시스템, 의존 레코드, 여러 단계의 프로세스가 필요합니다. 그것이 Flow, Apex, 때로는 연동 로직입니다. (Workflow Rule이나 Process Builder는 아닙니다. 지원이 종료되었습니다.) 자동화는 강력하고 더 비쌉니다. 움직이는 부품이 더 많고, 테스트와 오류 처리가 더 필요하고, 자동화 하나가 다른 자동화에 걸려 넘어질 길도 더 많습니다. 그리고 코드는 자기만의 오류를 가져옵니다. 필드 유형으로 시행할 수 있다면 저는 Apex를 쓰지 않습니다. 유효성 규칙이 분명하게 말할 수 있다면 Flow가 있다는 이유로 Flow를 만들지 않습니다. 필드 문제를 프로세스 엔진으로 풀지 마십시오.

전부 아니면 전무: 레코드가 함께 바뀔 때

지금까지 각 칸은 저장 하나를 보호합니다. 하지만 레코드는 함께 바뀝니다. 배송과 그 품목, 주문과 그 줄, 개체 세 개를 갱신하는 Flow. 여기서 플랫폼은 강한 보장을 줍니다. 저장과 그것이 일으키는 모든 것, 즉 트리거, Flow, 그것들이 호출하는 클래스는 하나의 트랜잭션으로 실행됩니다. 어느 부분이든 실패하면 전체가 롤백되고 아무것도 커밋되지 않습니다(Apex Transactions (opens in a new tab)). 배송이 절반만 생기는 일은 없습니다.

대량 작업은 당신이 고르는 예외입니다. 데이터 적재나 Apex Database 메서드는 부분 성공을 허용할 수 있습니다. 좋은 레코드는 저장되고, 나쁜 레코드는 오류와 함께 돌아오며, 누군가 그것을 처리해야 합니다(DML Statements vs. Database Class Methods (opens in a new tab)). 100만 행 적재에는 그게 맞을 때가 많지만, 그러면 일관성은 프로세스가 됩니다. 누가 오류 파일을 읽고, 실패한 레코드는 어떻게 될까요?

그리고 타이밍이 있습니다. 같은 순간의 두 저장은, 따로였다면 하나가 걸렸을 확인을 둘 다 통과할 수 있습니다. 기존 주문을 찾아보고 없으면 만드는 Flow는 두 건을 통과시킬 수 있고, 방금 보았듯 중복 규칙은 같은 시각에 저장된 레코드끼리 비교하지 않습니다. 고유로 표시된 필드나 외부 ID는 플랫폼이 모든 저장에서 확인하므로, 둘 중 하나만 이깁니다. 고유성을 필드까지 내려야 할 이유가 하나 더 생긴 셈입니다. 잠금, 경합, 재시도는 그 자체로 하나의 주제이고, 11장 트랜잭션, 동시성, 안정성에서 깊이 다룹니다.

규칙을 아래로 내려라, 거기 속하지 않을 때까지

“합리적으로 가능한 만큼 아래로”는 “늘 가장 아래로”가 아닙니다. 기회가 특정 단계에 이르러야만 필드가 필수라면, 스키마에서 필수로 만드는 것은 틀립니다. 규칙이 조건부이니 유효성 규칙이 올바른 칸입니다. 중복이 사람에게는 경고해야 하지만 승인된 연동에는 자체 대사가 있다면, 두 경로 모두를 위해 설계하십시오. 목표는 비즈니스 규칙을 올바르게 표현하는 가장 낮은 층입니다.

모든 층에는 비용이 있다

Click to enlarge

보여 드리고 싶은 트레이드오프가 이것입니다. 필드 유형과 통제된 값은 단순하고 강하지만, 필드가 표현할 수 있는 것에만 통합니다. 필수와 고유는 무딥니다. 켜면 모든 쓰기가 그것을 만족해야 합니다. 유효성 규칙은 더 풍부한 조건을 표현하지만 옛 레코드의 편집을 막고 배포를 놀라게 할 수 있습니다. 중복 규칙은 레코드 사이를 보호하지만 사용자와 연동에 마찰을 더합니다. 자동화는 무엇이든 다루지만 오케스트레이션, 오류, 테스트, 성능을 당신이 떠안게 합니다. 공짜인 층은 없습니다. 각 규칙의 층을 그것이 어떻게 실패하는지 알고 고르십시오.

켜기 전에

기존 org에 규칙을 추가하는 것은 체크박스가 아니라 롤아웃입니다. 오늘 몇 건이 그것을 위반하고, 왜인가? 정말 틀렸나? 올바른 값을 알 수 있나? 규칙이 과거에도 참인가, 지금부터만 참인가? 어떤 연동, 테스트, 자동화가 그것에 부딪힐까? 좋은 순서는 이렇습니다. 측정하고, 틀렸다고 증명할 수 있는 것을 정리하고, 규칙의 범위를 정하고, 정당한 이력에 대한 의도적 우회를 두고, 모든 쓰기 경로를 테스트한 뒤, 시행합니다. 측정과 정리는 그 자체로 하나의 분야입니다. 프로파일링, 표준화, 모니터링, 스튜어드십. 5장 데이터 품질과 거버넌스에서 다룹니다. 금요일에 체크박스를 켜고 토요일 밤에 결과를 발견하는 것보다 훨씬 낫습니다.

시험 너머: AI가 바꾸는 것. 에이전트는 어떤 사람보다 빨리 레코드를 만들고, 나쁜 레코드도 똑같이 빨리 만듭니다. 사용자가 에이전트일 때 “사용자들은 그러면 안 되는 걸 알아요”는 보호 장치가 아닙니다. 중요한 규칙은 모든 작성자가 마주치는 데이터 층에 두십시오. 그러면 에이전트가 회사의 불문율을 기억할 필요가 없습니다.

Steve Trucking: 배송을 보호하라

배송을 보십시오. 상태는 어휘 하나에서 옵니다. 제한된 선택 목록입니다. 리테일 파트너의 주문 참조는 파트너별로 고유해야 하므로, 고유로 표시된 외부 ID이고 배송 목록을 upsert하는 데 씁니다. 실제 배송 시각은 상태가 배송 완료가 되면 필수입니다. 그 변경으로 한정한 유효성 규칙입니다. 설치 정차지는 체크리스트가 완료되고 필요한 사진(식기세척기라면 급수관, 배수관, 수평)이 찍혀야 마감할 수 있습니다. 유효성 규칙이고, 플랫폼 밖에 저장된 사진을 확인해야 한다면 자동화입니다. 다시 보낸 배송 목록으로 같은 주문이 두 번 들어오면 외부 ID가 잡아내고, 비슷해 보이는 서로 다른 두 주문은 일치의 문제입니다.

제가 “전부 Flow에 넣으라”고 하지 않았다는 점에 주목하십시오. 규칙마다 자기 칸에 있습니다. 규칙마다 물으십시오. 중요한 모든 쓰기 경로에서 이것을 올바르게 시행하는 가장 낮은 층은 무엇인가?

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

• 각 규칙이 어느 칸에 속하는지: 필드 유형, 통제된 어휘, 필수나 고유, 유효성 규칙, 중복 규칙, 자동화.
• 어떤 쓰기 경로를 보호해야 하는지: UI, 포털, 모바일, 연동, 대량 적재, API, 자동화, 에이전트.
• 새 규칙이 과거 레코드에도 적용되는지, 아니면 과거에 대한 우회를 두고 새로운·변경된 데이터로 한정되는지.
• 기존의 나쁜 데이터를 통과시키려고 다시 쓰는 대신 증거로 고칠 수 있는지.
• 규칙 하나가 얼마만큼의 마찰, 복잡성, 유지보수를 감수할 가치가 있는지.

깨끗한 데이터는 사람들에게 좋은 데이터를 입력하라고 부탁해서 나오지 않습니다. 옳은 일은 쉽고, 틀린 일은 어렵고, 중요한 규칙은 우회하기 어렵게 만드는 아키텍처에서 나옵니다. 다음으로 Steve Trucking의 한 단면에 이 장을 모아 보겠습니다.

더 알아보기

• Salesforce 도움말, How to Reference a Custom Permission in a Formula, Workflow Rule, or Validation Rule (opens in a new tab)(영어) 및 Roll-Up Summary Field (opens in a new tab)(영어), 확인일 2026-10-13.
• Salesforce 도움말, Picklist Limitations (opens in a new tab)(영어), 확인일 2026-10-02.
• Salesforce 도움말, Validation Rule Considerations (opens in a new tab)(영어), 확인일 2026-10-02.
• Salesforce 도움말, Things to Know About Duplicate Rules (opens in a new tab)(영어), 확인일 2026-10-13: 한계, 규칙이 실행되지 않는 경로, 경고 없이 차단되는 API·가져오기 저장, 서로 비교되지 않는 동시 저장.
• Apex Developer Guide, Apex Transactions (opens in a new tab)(영어) 및 DML Statements vs. Database Class Methods (opens in a new tab)(영어), 확인일 2026-10-13: 하나의 트랜잭션은 한 단위로 롤백되고, Database 메서드는 부분 성공을 허용할 수 있다.
• Salesforce 도움말, Workflow Rules & Process Builder End of Support (opens in a new tab)(영어), 확인일 2026-10-02.