필드도 아키텍처다

🌐 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 데이터 아키텍처의 모듈 6/10. 각 모듈은 독립적으로 읽을 수 있습니다. 이전: 올바른 개체를 골라라 · 다음: 관계에는 결과가 따른다

이 모듈이 답하는 질문: Salesforce는 각 데이터를 물리적으로 어떻게 표현해야 할까요?

필드를 만드는 데는 1분쯤 걸립니다. 새 필드, 유형 선택, 이름, 다음, 다음, 저장. 바로 그래서 필드는 아키텍처로 취급받지 못합니다.

10년 된 org에 들어가 계정을 열어 보십시오. 필드 500개. Status2__c, Legacy_Status__c, Old_Status__c, Status_New__c. 서로 다른 고객 번호 세 개. 어느 연동이 아직 쓰는지 아무도 몰라서 아무도 지우지 못하는 체크박스 하나. 필드를 만드는 데는 1분이 걸렸습니다. 그것과 함께 사는 데는 몇 년이 걸립니다. 그래서 이 모듈의 생각은 단순합니다. 필드는 아키텍처적인 결정이다. 늘 큰 결정은 아니지만, 모든 필드는 데이터의 의미, 동작, 정체성, 품질에 관한 무언가를 담고 있고, 개체처럼 추가하기는 쉽고 빼기는 놀랄 만큼 어렵습니다.

이 데이터는 실제로 무엇을 뜻하는가?

2장에서 엔터티에 속성을 주었습니다. 배송에는 예정 시간대가 있고, 트럭에는 VIN이 있습니다. 이제 그것을 구현하는데, 여기서 사람들은 곧장 “텍스트 필드”로 뛰어듭니다. 잠깐만요. 유형 전에 저는 데이터가 무엇을 뜻하는지 알고 싶습니다. 숫자인가, 우연히 숫자로 된 식별자인가? 날짜인가, 시점인가? 자유 텍스트인가, 승인된 집합 중 하나인가? 사람이 입력하는가, 다른 시스템이 소유하는가? 바뀔 수 있나? 고유해야 하나? 비어 있을 수 있나? 아예 저장해야 하나, 계산해야 하나? 설정 화면의 질문이 아닙니다. 데이터 아키텍처의 질문이고, 필드 유형은 답한 뒤에 옵니다.

숫자가 늘 숫자는 아니다

Steve Trucking은 트럭마다 차량 번호를 줍니다. 이를테면 001247. 숫자 필드일까요? 아마 아닐 겁니다. 차량 번호를 더하나요? 1247번 트럭 빼기 1246번 트럭이 트럭 한 대인가요? 우연히 숫자를 담은 식별자이고, 숫자 필드라면 앞자리 0까지 날려 버립니다. 우편번호, 제품 코드, 계좌 번호, 운송장 번호도 마찬가지입니다. 값의 생김새가 의미를 말해 주지 않습니다. 샘플 데이터의 생김새가 아니라 필요한 동작에 맞춰 유형을 고르십시오.

사람이 그것을 식별해야 하는가?

모든 사용자 정의 개체에는 Name 필드가 있고, 첫 결정은 텍스트냐 자동 번호냐입니다. 저는 묻습니다. 사람이 이것을 식별해야 하는가? 사람들은 리테일 파트너를 이름으로, 트럭을 차량 번호로 압니다. 하지만 시스템이 매일 밤 생성하는 배송 목록은요? Salesforce가 Name을 요구했다고 아무도 “배송 목록 10-02 3번”을 입력해서는 안 됩니다. 자동 번호를 주십시오. 다만 그 생성된 Name을 레코드의 정체성과 혼동하지 마십시오. 자동 번호는 사용자를 돕고, Salesforce ID는 레코드를 식별하며, 리테일 파트너 자체의 배송 목록 참조 번호는 시스템을 넘나들며 같은 대상을 식별할 수 있습니다. 세 가지 다른 일입니다.

세부 사항 화면

유형을 고르고 다음을 클릭하면 설정이 세부 사항을 묻습니다. 이 모듈의 결정 대부분이 실제로 내려지는 화면이 여기이고, 보통은 서둘러 내려집니다.

새 사용자 정의 필드 2단계: 세부 사항(스크린샷, 2026-10-12). 원본 크기

비슷해 보이지만 하는 일이 다른 칸이 두 개 있습니다. 설명은 org를 유지보수하는 사람들, 그리고 이제는 그것을 읽는 AI 도구를 위한 것입니다. 필드가 무엇을 뜻하는지, 누가 소유하는지, 어디서 오는지. 도움말 텍스트는 화면 앞의 사용자를 위한 것입니다. 여기에 무엇을 입력하는지. 둘 다 채우십시오. 그다음에 필수, 고유, 외부 ID가 오고, 각각은 따로 절을 둘 만합니다. 그 아래의 기본값은 수식이 될 수 있어서, 새 레코드가 빈칸 대신 합리적인 값으로 시작할 수 있습니다.

필수는 보이는 것보다 큰 결정이다

필드 마법사에는 필수라는 작은 체크박스가 있고, 1장에서 봤듯이 시한폭탄이 될 수 있습니다. 5년 된 개체에 레코드가 200만 건 있는데, 이제 누군가 새 필드에 늘 값이 있어야 한다고 정합니다. 그 이전의 200만 건은요? 그 값을 보내지 않는 연동은요? 값이 알려지기 전에 레코드를 만드는 자동화는요? 값이 세 단계 뒤에야 나오는 프로세스는요?

“필수”는 데이터 품질 결정처럼 들리고, 때로는 그렇습니다. 하지만 값이 언제 알려지는지는 비즈니스 프로세스의 일부입니다. 그러니 누군가 “그건 늘 있어야 해요”라고 했다고 필수를 체크하지 마십시오. 언제 알려지는지, 누가 제공하는지, 없을 때 어떻게 되는지 물으십시오. 모듈 7에서 이것을 완전한 일관성 사다리 위에 올려 보겠습니다.

고유도 무언가를 뜻한다

필드를 고유로 표시하면 비즈니스에 대해 진술하는 것입니다. “보통 반복되지 않는다”가 아니라 **“두 레코드가 절대 이 값을 가질 수 없다”**입니다. 강한 진술입니다. 그리고 화면은 한 가지를 더 정하게 합니다. “ABC”와 “abc”는 같은 값일까요, 다른 값일까요? 사람이 입력하는 것이라면 대소문자 비구분이 더 안전한 기본값입니다. 2장의 키 규칙, 고유하고, 변하지 않고, 의미가 없고, 절대 개인정보가 아니어야 한다가 여기 적용됩니다. 누군가 직원 이메일이 고유하다고 하면 저는 묻기 시작합니다. 바뀔 수 있나, 퇴사했다 돌아올 수 있나, 주소가 재사용될 수 있나, 인수 후에는 어떻게 되나? 이메일은 쓸모 있고, 오늘은 고유할 수도 있습니다. 그렇다고 좋은 정체성이 되는 건 아닙니다.

외부 ID: 경계를 넘는 정체성

여기서 외부 ID가 제 몫을 합니다. 화면이 잘 설명합니다. 그 필드는 “외부 시스템의 고유 레코드 식별자”가 됩니다. ERP에는 고객 873492가 있고, Salesforce에는 자체 레코드 ID가 있습니다. ERP가 갱신을 보내면 그것이 어느 레코드에 속하는지 어떻게 알까요? 필드를 외부 ID로 표시하면 연동이 그것으로 upsert할 수 있습니다. 레코드가 없으면 만들고, 있으면 갱신합니다(Upsert a Record Using an External ID (opens in a new tab)). 그리고 하위 레코드를 적재할 때 Salesforce ID를 먼저 조회하지 않고 상위를 그 외부 ID로 가리킬 수 있습니다. 저는 Salesforce가 조회를 대신하게 하는 거라고 말합니다. 아주 강력합니다.

ERP의 번호가 Salesforce 레코드의 정체성이 되지 않는다는 점에 주목하십시오. 그것은 속성이고, 레코드 하나가 여러 개를 가질 수 있습니다. ERP 고객 ID, 레거시 ID, 파트너의 ID. 괜찮습니다. 비즈니스 엔터티 하나가 여러 시스템에서 다르게 알려질 수 있습니다. 아키텍처 질문은 어느 시스템이 각 식별자를 소유하며, 그것이 어떤 약속을 하는가입니다. 비즈니스가 정말 보장할 때만 고유로 표시하십시오.

필드 유형별로

이제 유형 자체입니다. 아무 개체에서나 새 필드를 열면 설정이 전체 목록을 보여 주는데, 제가 살펴볼 순서대로 묶여 있습니다. Salesforce가 대신 계산하는 필드, 관계 필드, 그리고 데이터 유형.

설정, 새 사용자 정의 필드 1단계: 데이터 유형(스크린샷, 2026-10-12). 원본 크기

전체 목록을 한눈에 보겠습니다. 각각에 대해 기억했으면 하는 한 가지와 함께.

묶음	유형	기억할 것
계산	자동 번호	최대 30자, 그중 20자는 접두사나 접미사. 사람을 위한 레이블이지 레코드의 정체성이 아니다
	수식	저장되지 않고 읽을 때 계산된다. 3,900자
	롤업 요약	세부 레코드의 개수, 합계, 최솟값, 최댓값. 마스터-세부 사항에서만
관계	조회, 마스터-세부 사항, 외부 조회	모듈 7
데이터	확인란	참 또는 거짓, 기본값은 직접 고른다. 플로우에서는 여전히 null이 나올 수 있다
	숫자, 백분율, 통화	반올림 규칙. 앞자리 0은 사라진다. 소수점 이하 15자리
	날짜, 날짜/시간, 시간	하루, 한 시점, 또는 하루 중 시각. 시점은 UTC로 저장된다
	이메일, 전화, URL	저장할 때 서식이 적용되고 검사된다. 80자, 40자, 255자
	지리적 위치, 주소	필드 하나보다 많이 차지하는 복합 필드. 3개와 9개
	선택 목록, 다중 선택	관리자가 소유하는 통제된 어휘
	텍스트, 텍스트 영역, 긴 텍스트, 서식 있는 텍스트, 암호화된 텍스트	255자까지는 레코드에 저장되고 인덱스 가능. 그 이상은 인덱스도 필터링도 안 된다

Salesforce가 계산하는 필드

자동 번호는 새 레코드마다 순서상 다음 번호를, 직접 정한 형식(예: T-{000000})으로 매깁니다. 사람에게 편한 손잡이가 필요하고 아무도 그것을 지어낼 필요가 없어야 할 때 쓰십시오. 전체 값은 최대 30자이고, 그중 20자는 접두사나 접미사 몫입니다. 다만 2장에서 배운 것을 기억하십시오. 자동 번호는 사람을 위한 레이블이지 레코드의 정체성이 아니며, 번호가 늘 엄격하게 연속되지는 않습니다.

수식 필드는 다른 필드로부터 값을 계산합니다. 강력하고, 저장할 때가 아니라 레코드를 읽을 때 계산되므로 낡아 버릴 저장 값이 없습니다. 수식이 무엇을 반환할지는 직접 고릅니다. 확인란, 통화, 날짜, 날짜/시간, 숫자, 백분율, 텍스트, 시간.

새 사용자 정의 필드, 수식: 반환 유형 선택(스크린샷, 2026-10-12). 원본 크기

그다음 필드, 연산자, 함수로 수식 자체를 쓰고 구문을 검사합니다. Use Formula Assistant(수식 도우미 사용) 버튼에 주목하십시오. 이제 Salesforce의 AI가 수식 작성을 도와줍니다. 쓰십시오. 그리고 그것이 쓴 것을 읽으십시오. 수식의 주인은 도우미가 아니라 당신입니다.

수식 도우미가 있는 수식 편집기(스크린샷, 2026-10-12). 원본 크기 수식은 최대 3,900자이고, 저장되거나 컴파일될 때 15,000바이트를 넘을 수 없습니다. 긴 수식은 서로를 참조하는 여러 수식 필드로 나눌 수 있습니다. 긴 텍스트 영역, 암호화된 필드, 설명 필드는 수식에 쓸 수 없습니다.

롤업 요약 필드는 마스터에 있으면서 세부 레코드의 개수, 합계, 최솟값이나 최댓값을 구합니다. 마스터-세부 사항 관계에서만 작동하고, 이것이 애초에 마스터-세부 사항을 고르는 가장 큰 이유 중 하나입니다. 롤업 요약과 그 한계는 모듈 7에서 다시 다루겠습니다.

저장인가, 파생인가?

이 값을 애초에 저장해야 하는가? 수량과 단가가 있다면, 누군가 또는 어떤 자동화가 합계를 유지해야 할까요? 수식이 파생시키는 게 나을 수 있습니다. 계산의 원천이 하나이고, 읽을 때 다시 계산되니 수량을 바꾸면 답이 따라옵니다. 수식에도 나름의 한계가 있고(저장 크기와 표시 길이, Formula Field Limits and Restrictions (opens in a new tab)), 복잡한 수식은 유지보수하기 어려워집니다.

하지만 때로 비즈니스는 오늘의 답을 원하지 않습니다. 그때의 답을 원합니다. 내년에 할인 규칙이 바뀌면 작년 청구서가 갑자기 다른 금액을 보여야 할까요? 당연히 아닙니다. 그러니 질문은 “Salesforce가 이걸 계산할 수 있나?”가 아닙니다. **“이것은 현재의 계산인가, 과거의 사실인가?”**입니다. 과거의 사실은 저장합니다.

관계 필드

조회, 마스터-세부 사항, 외부 조회 관계도 필드이고, 모델의 선이 실체가 되는 곳입니다. 조회는 느슨한 연결이고, 마스터-세부 사항은 하위 레코드의 생명, 소유권, 보안을 상위에 묶으며, 외부 조회는 모듈 4의 외부 개체에 그 외부 ID로 맞춰 닿습니다. 이들 사이의 선택은 별도 모듈을 둘 만큼 큰 결정입니다.

확인란

확인란(Checkbox)은 가장 단순한 필드입니다. 참 또는 거짓, 체크됨 또는 체크 안 됨. 레코드에 대한 예/아니요 사실에 딱 맞습니다. 활성 여부, 설치 필요, 서명 수령. 하나를 만들 때 Salesforce는 기본값을 체크됨이나 체크 안 됨 중에서 고르게 하는데, 이건 진짜 결정입니다. 모든 새 레코드가 그 값으로 시작하기 때문입니다. 연동이 그 필드를 보내지 않고 만든 레코드도 마찬가지입니다. 보고서와 목록 보기는 그것을 True와 False로 필터링하고, 가져오기 도구와 주간 내보내기는 1과 0으로 보여 줍니다.

알아 둘 함정이 하나 있습니다. 레코드의 필드에는 값이 두 개지만, 그 주변의 자동화에는 세 번째 값이 있을 수 있습니다. 플로우에서 한 번도 설정되지 않은 확인란 변수는 false가 아니라 null이고, 그것을 레코드에 저장하면 실패합니다(Trailblazer Community (opens in a new tab), Salesforce 알려진 문제 W-11208535 (opens in a new tab)도 참고). 합리적인 기본값을 고르고, 플로우와 코드가 null을 의도적으로 다루게 하십시오.

숫자, 백분율, 통화

숫자는 실수를 저장하고 앞자리 0을 모두 버립니다. 바로 그래서 001247 같은 차량 번호는 숫자가 아닙니다. Salesforce는 숫자 필드를 0에서 먼 쪽으로 반올림합니다. 12.345는 12.35가 되고, −12.345는 −12.35가 됩니다. 그리고 병합 필드에서는 필드에 설정한 소수 자릿수가 아니라 사용자의 로캘에 맞춰 반올림합니다.

백분율은 소수를 저장하고 백분율로 보여 줍니다. 0.10을 입력하면 10%가 보입니다. 소수점 이하 15자리를 넘으면 정밀도를 잃습니다.

통화는 돈의 형식으로 표시되고, 여러 통화를 쓰는 org에서는 통화 코드를 함께 가지며 환율을 쓸 수 있습니다. 고급 통화 관리 (opens in a new tab)를 쓰면 기회는 날짜별 환율, 즉 거래가 마감된 기간의 환율을 쓸 수 있습니다. 날짜별 환율을 쓰는 것은 기회와 그 주변(제품, 일정, 분할, 그리고 그 보고서)뿐이고, 다른 개체의 통화 필드는 단일 고정 환율을 유지합니다. 반올림을 조심하십시오. 소수 자릿수가 없으면 Salesforce는 그냥 잘라 버리고(23.5는 23이 됩니다), 한 자리 이상이면 0에서 먼 쪽으로 반올림합니다.

날짜, 날짜/시간, 시간

유형 셋, 의미 셋. 날짜는 하루입니다. 계약은 어떤 날짜에 만료됩니다. 날짜/시간은 한 시점입니다. 배송이 그날 아침 9시 42분에 도착했습니다. 시간은 날짜가 전혀 없는 하루 중 시각입니다. 매장은 매일 7시에 문을 엽니다.

함정은 시점입니다. Salesforce는 날짜/시간 값을 GMT(UTC)로 저장합니다. 사용자가 입력한 시각은 그 사용자의 시간대로 읽혀 변환된 뒤 저장되고, 누군가 그것을 읽을 때 다시 읽는 사람의 시간대로 변환됩니다. 대부분은 바로 원하는 대로입니다. 하지만 제가 수업에서 드는 예가 있습니다. 로스앤젤레스의 코디네이터가 일요일 밤 늦게, 태평양 시간 오후 10시에 배송을 기록합니다. 그 아래에서 Salesforce는 월요일 아침, GMT 오전 5시를 저장했습니다. 다른 시간대에서 날짜별로 묶은 보고서나 원시 값을 읽는 연동은 그 일요일 배송을 월요일에 넣을 수 있습니다. “그 일이 일어난 날”은 누구의 시계에 묻느냐에 달려 있습니다. 사용자들의 시간대를 지켜보고, 비즈니스가 뜻하는 것이 어느 시간대인지 정하십시오.

그리고 비교할 때 조심하십시오. 그 아래에서 날짜/시간은 하나의 큰 숫자입니다. Apex는 그것을 1970년 1월 1일 00:00:00 GMT 이후의 밀리초 수로 읽습니다(Datetime Class (opens in a new tab)). 하루가 아니라 정밀한 한 시점입니다. 그러니 두 날짜/시간이 같은지(==) 묻는 것은 원하는 대로 되는 일이 거의 없습니다. 9:42:00과 9:42:01은 같지 않고, “월요일”과 월요일의 어떤 시점도 같지 않습니다. 대신 범위를 물으십시오. 시작 이후(>=)이면서 끝 이전(<=). “월요일의 모든 배송”은 비즈니스가 뜻한다고 정한 시간대에서 월요일 00:00 >=이고 월요일 23:59:59 <=인 모든 배송입니다.

재미있는 것도 하나 있습니다. Salesforce는 아무 날짜나 저장하지 못합니다. 유효한 날짜는 1700년 1월 1일부터 4000년 12월 31일까지이고, Salesforce는 날짜와 날짜/시간에 같은 범위를 제시합니다(Data Import Dates (opens in a new tab)). 경계조차 GMT 기준의 시점이라서, 태평양 시간대 사용자에게 가장 이른 유효 값은 1699년 12월 31일 오후 4시입니다. 지역 역사 학회의 창립일은 들어가지 못할 수도 있습니다. 그리고 고전적인 “종료일 없음” 요령인 9999년 12월 31일은 거부됩니다. 먼 미래의 자리표시 값이 필요하다면 4000년 이전이어야 합니다.

이메일, 전화, URL

이것들은 서식이 있는 필드이고, 문자를 저장하는 것 이상을 합니다. 이메일은 최대 80자이고 올바른 형식인지 검사됩니다. 연락처와 리드에서는 클릭하면 그 주소로 이메일 작성이 시작됩니다. 전화는 최대 40자이고 전화번호 형식으로 표시되며, org에 전화 시스템이 연결되어 있으면 클릭 투 다이얼이 됩니다. URL은 최대 255자이고 링크로 열립니다. 플랫폼이 동작을 공짜로 주는 것이고, 그래서 저는 전화번호를 일반 텍스트 필드에 절대 저장하지 않습니다.

연동도 검사를 받습니다. 형식이 잘못된 이메일 주소처럼 필드 형식에 맞지 않는 값은 유효성 검사에 실패하고, 그 필드만이 아니라 레코드 전체가 거부됩니다. 그러니 원천 시스템의 데이터가 지저분하다면 도착하기 전에 정리하거나, 적재되지 않을 레코드에 대비하십시오.

지리적 위치와 주소

지리적 위치는 위도와 경도를 담습니다. 그 아래에서 Location__c라는 필드는 실제로 따로 읽고 설정할 수 있는 두 값, Location__Latitude__s와 Location__Longitude__s입니다. 그리고 그것으로 쿼리할 수 있습니다. SOQL의 DISTANCE와 GEOLOCATION 함수는 반경 안의 레코드를 찾거나 거리순으로 정렬합니다. “이 트럭에서 25마일 안의 모든 미결 배송”은 쿼리 하나입니다. WHERE DISTANCE(Location__c, GEOLOCATION(33.45, -112.07), 'mi') < 25 (Location-Based SOQL Queries (opens in a new tab)). 주소는 거리, 시, 주나 도, 우편번호, 국가로 된 주소 전체를 담고, 사용자는 주소를 검색해 각 부분을 채울 수 있습니다.

둘 다 복합 필드입니다. 화면에서는 필드 하나, 그 아래에서는 여러 개. 그리고 개체의 한도에서 필드 하나보다 많이 차지합니다. 지리적 위치는 사용자 정의 필드 3개로, 주소는 9개로 계산됩니다. 이미 붐비는 개체에서는 이게 중요합니다.

선택 목록과 다중 선택

선택 목록은 사용자가 입력할 수 있는 것을 통제합니다. 직접 정의한 목록에서 값 하나. 상태? 아마 선택 목록일 겁니다. 하지만 값은 메타데이터이고, 관리자가 추가하거나 바꿔야 합니다. 그래서 저는 여전히 묻습니다. 누가 값을 소유하는가, 얼마나 자주 바뀌는가, 여러 개체에 같은 목록이 필요한가, 값 자체가 정보를 담고 있는가, 다른 시스템이 그 어휘를 소유하는가.

값이 어디에 있는지도 결정입니다. 목록이 한 필드에서 한 번 쓰인다면 값을 필드 자체에, 개체에 두십시오. Salesforce의 기본 동작이 그것입니다. 하지만 같은 값 집합이 여러 곳에 나타나기 시작하면, 이를테면 계정, 배송, 창고의 지역(Region)처럼, 사본들이 서로 어긋나기 전에 글로벌 값 세트로 승격하십시오. 글로벌 값 세트는 그 모두를 위한 목록 하나를 유지하며, 활성과 비활성을 합쳐 최대 1,000개 값까지 담습니다(Picklist Limitations (opens in a new tab)). 설정 화면의 설명이 왜 중요한지 말해 줍니다. 값 세트는 “사용자가 API를 통해 승인되지 않은 값을 추가할 수 없도록 제한됩니다.” 목록 하나, 소유자 하나, 그리고 새 철자를 몰래 들여오는 연동은 없습니다.

그 마지막 점이 제한된 선택 목록과 제한되지 않은 선택 목록의 차이입니다. 제한된 선택 목록에서는 관리자가 정의한 값만 어디서든 허용됩니다. 다른 값을 보내는 사용자, 가져오기, 연동은 “bad value for restricted picklist field” 오류를 받고, 레코드는 저장되지 않습니다. 제한되지 않은 선택 목록에서는 사용자가 화면에서는 여전히 목록에서 고르지만, API, 가져오기, 자동화는 아무 값이나 보낼 수 있고, Salesforce는 그것을 저장하고 비활성 값으로 추가합니다(Picklist Limitations (opens in a new tab), Create a Custom Picklist Field (opens in a new tab)). 그렇게 org에 “Delivered”, “delivered”, “Dlvrd”가 생깁니다. 글로벌 값 세트는 늘 제한됩니다. 제 기본값은 제한된 쪽입니다. 제한되지 않은 쪽은 다른 시스템이 정말 값을 소유할 때 하는 의도적인 선택이고, 그때는 누군가가 비활성 값 정리를 맡아야 합니다.

설정, 선택 목록 값 세트: 새 글로벌 값 세트(스크린샷, 2026-10-12). 원본 크기

다중 선택 선택 목록은 사용자가 여러 값을 고를 수 있게 하고, 값들은 세미콜론으로 구분되어 함께 저장됩니다. 화면에서는 편하지만 다른 모든 곳에서는 불편합니다. 필터링, 보고, 연동이 더 어렵고, 롤업 요약의 필터에 쓸 수 없습니다. 한 레코드에 여러 값이 있다는 건 보통 2장의 교훈을 뜻합니다. 빠져나오려는 하위 개체가 있다는 것입니다.

선택 목록에는 정의한 값보다 값이 하나 더 있습니다. 빈 값입니다. 레코드는 아무것도 선택하지 않은 채로 있을 수 있고, 그게 사람들을 잡습니다. 수식이나 유효성 규칙에서는 선택 목록을 ISBLANK만으로 검사할 수 없습니다. ISBLANK(TEXT(Field__c))나 ISPICKVAL(Field__c, "")로 씁니다(Trailblazer Community (opens in a new tab)). 그러니 모든 선택 목록에 대해 “값 없음”이 무엇을 뜻하는지 정하십시오. 허용되는가, 그리고 그런 일이 생기면 무엇을 뜻하는가? 그다음 수식, 유효성 규칙, 필터가 그것을 처리하게 하십시오.

그리고 때로 속성은 사실 엔터티입니다. 누군가 물류 센터 선택 목록을 요청합니다. 아홉 곳입니다. 쉽습니다. 그러다 각각에 주소, 관리자, 운영 시간, 용량, 지역, 트럭이 있다는 걸 알게 됩니다. 그건 선택 목록이 아닙니다. 하나의 대상입니다. 아직 개수가 많지 않다는 이유만으로 엔터티를 선택 목록으로 만들지 마십시오. 1년 차에는 기분이 좋고 5년 차에는 끔찍합니다. (목록이 자기 개체를 가질 자격이 생기는 때에 대한 제 경험칙은 2장 모듈 5에 있습니다.)

텍스트 계열

저는 텍스트를 두 종류로 가르치고, 그 둘을 가르는 선은 255자입니다.

255자까지: 레코드와 함께 저장. 텍스트는 최대 255자를 담고, 거의 어디서나 쓸 수 있습니다. 수식, 필터, 보고서, 목록 보기에서, 고유 필드나 외부 ID로, 그리고 인덱스를 걸 수 있습니다. 텍스트 영역도 255자를 담되, 짧은 메모처럼 여러 줄로 담습니다.

255자 초과: 참조로 저장. 긴 텍스트 영역(Text Area (Long))은 최대 131,072자를 담고, 서식 있는 텍스트 영역(Text Area (Rich))은 같은 양을 서식, 링크, 이미지와 함께 담습니다. 저는 이것들을 옆에 따로 저장되고 레코드는 포인터만 갖는 것으로 생각하는데, 실제로 그렇게 동작합니다. 인덱스가 없어서 고유나 외부 ID로 만들 수 없고, SOQL WHERE 절에서 필터링할 수 없으며(SOQL WHERE (opens in a new tab)), 수식에 쓸 수 없고(Formula Field Limits and Restrictions (opens in a new tab)), 보고서는 사용자 정의 필드의 처음 254자만 보여 주며, 보고서 필터는 처음 255자 정도만 검색합니다(Filter Restrictions for Text Area (Long) Fields (opens in a new tab)). 서식 있는 텍스트 필드에 올린 이미지는 하나에 최대 1MB이고 파일 스토리지에 계산되며, 텍스트는 데이터 스토리지에 계산됩니다(Rich Text Area Field Considerations (opens in a new tab)). 그러니 누구든 그 값으로 검색, 정렬, 매칭, 보고를 해야 한다면 255자 아래로, 텍스트 필드로 두십시오.

암호화된 텍스트(Text (Encrypted))는 Classic Encryption을 써서 최대 175자를 암호화된 형태로 저장합니다. org가 Shield Platform Encryption을 쓴다면 대신 일반 텍스트 필드를 암호화하고, 다른 많은 유형도 그 방식으로 암호화할 수 있습니다.

모든 필드에 설명을 달아라

제 기준은 모든 필드에 설명을 단다입니다. 오래전부터 믿어 왔고, AI 시대에는 그 어느 때보다 중요합니다. org를 읽는 모든 AI 도구와 에이전트는 필드가 무엇을 뜻하는지 이해하려고 설명을 읽습니다. 빈 설명은 일어나기만 기다리는 추측입니다. Customer_Status__c는 무엇을 뜻할까요? 누가 소유하나요? 어디서 오나요? 사용자가 편집할 수 있나요, 아니면 오늘 밤 ERP가 덮어쓰나요? 6개월 뒤 저는 기억하지 못할 것이고, 3년 뒤 org를 관리하는 관리자는 우리가 알려 주지 않는 한 모를 것입니다. 레이블은 문서가 아니고, API 이름도 아닙니다.

많이 공유되는 개체(계정, 연락처, 기회)에서는 특수 필드에 이름 접두사도 씁니다. 출처와 목적이 이름 자체에 드러나도록요. 예를 들어 ERP가 소유하는 것은 모두 같은 접두사로 시작합니다. 열두 단어짜리 API 이름을 원하는 게 아닙니다. 모델이 스스로를 설명하기를 원합니다.

중요한 것을 분류하라: 분류 체계 필드

Salesforce는 모든 필드에 분류 메타데이터 묶음을 줍니다. 저는 이것을 분류 체계 필드라고 부릅니다. 데이터 오너(Data Owner), 필드 사용(Field Usage: Active, DeprecateCandidate, Hidden), 데이터 민감도 수준(Data Sensitivity Level: Public, Internal, Confidential, Restricted, MissionCritical), 규정 준수 분류(Compliance Categorization: PII, HIPAA, GDPR, PCI, CCPA 등)를 기록할 수 있습니다. 사용자 정의 필드뿐 아니라 표준 필드에서도 작동합니다(Data Classification Metadata Fields (opens in a new tab)).

왜 굳이 할까요? 프로세스가 그것을 읽을 수 있기 때문입니다. 필드를 GDPR로 표시하면 프로세스가 레코드의 모든 GDPR 필드를 찾아 마스킹하거나 제거할 수 있습니다. 그리고 Salesforce의 트러스트 레이어가 대규모 언어 모델에 프롬프트를 보낼 때, 바로 이 분류를 써서 민감한 필드를 마스킹할 수 있습니다. 나갈 때 고객의 이름, 이를테면 “Maria Lopez”를 자리표시자로 바꾸고, 모델은 이름을 보지 못하며, 들어올 때 응답에 이름을 다시 넣습니다(Einstein Trust Layer (opens in a new tab)).

업데이트. Salesforce는 이제 LLM을 위한 패턴 기반·필드 기반 마스킹이 에이전트에는 비활성화되어 있다고 문서화합니다. 마스킹이 에이전트가 답하는 데 필요한 맥락을 없앨 수 있기 때문입니다(Data Masking Limitations in Agentforce (opens in a new tab)). 분류는 다른 생성형 AI 기능의 마스킹은 여전히 이끌지만, 개인정보를 에이전트에게서 떼어 놓는 데 그것을 믿지 마십시오. 그것은 접근과 설계의 결정입니다(12장).

제 입장은 이렇습니다. 분류는 핵심적인 때에 중요하다. 거버넌스가 하라고 해서 모든 칸을 채우는 3주짜리 작업으로 만들지 마십시오. 중요한 곳에 쓰십시오. 개인정보, 재무 데이터, 규제 대상 데이터, 그리고 비즈니스에 이름 있는 소유자가 필요한 필드. 요점은 민감도가 누군가의 머릿속 지식이기를 멈추고 필드의 일부가 된다는 것입니다.

시험 너머: AI가 바꾸는 것. 부실한 필드 문서화는 예전엔 다음 관리자를 괴롭혔습니다. 이제는 스키마를 읽는 모든 AI 도구와 에이전트를 오도합니다. Flag2__c는 민감한가, 권위 있는가, 아직 쓰이는가? AI는 또 어떤 팀보다 빠르게 필드를 만들어 내므로, 이름, 설명, 분류는 집안일이 아니라 아키텍처의 일부입니다.

모든 필드는 약속이다

필드가 세상에 나가 데이터를 모으기 시작하면 모든 것이 거기에 기대기 시작합니다. 화면이 그것을 보여 주고, 플로우가 그것으로 분기하고, 유효성 규칙이 그것을 검사하고, 보고서가 그것으로 묶고, 연동이 그것을 보내고 읽고, 이제는 AI 도구가 그것을 두고 추론합니다. 그 하나하나가 필드에 대해 가정을 합니다. 유형, 길이, 비어 있을 때가 있는지, 값이 무엇을 뜻하는지. 나중에 필드를 바꾸려면 먼저 그 가정을 하나도 빠짐없이 찾아야 합니다. 선택 목록 값 이름 바꾸기, 텍스트 필드 줄이기, 텍스트 필드를 선택 목록으로 바꾸기는 작은 변경처럼 들리지만, 다른 회사 시스템의 연동을 깨뜨릴 수 있습니다. 그래서 필드는 약속입니다.

Click to enlarge

이 모듈을 마치고 필드 만들기를 두려워하게 되길 바라는 건 아닙니다. Salesforce는 확장되도록 만들어졌으니 활용하십시오. 저는 질문이 “어떤 필드 유형을 골라야 하지?”에서 **“이 데이터는 무엇을 뜻하고, 우리는 어떤 동작을 약속하는가?”**로 바뀌기를 바랍니다. 유형, 필수, 고유, 외부 ID, 선택 목록, 수식, 설명, 분류. 함께 모이면 그것들이 2장 논리 모델의 물리적 표현입니다.

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

• 필드 유형을 고르기 전에 값이 무엇을 뜻하는지, 그리고 그것이 속성인지, 식별자인지, 통제된 어휘인지, 사실은 다른 엔터티인지.
• 값이 파생할 수 있는 현재의 계산인지, 저장해야 하는 과거의 사실인지.
• 어느 시스템이 각 식별자를 소유하며, 그 고유성이 비즈니스의 진짜 약속인지.
• 필수 값이 실제로 언제 알려지는지, 그리고 그 값이 없는 레코드와 연동은 어떻게 되는지.
• 사람, 프로세스, AI가 필드를 안전하게 쓰려면 어떤 설명, 이름, 분류가 필요한지.

더 알아보기

• Salesforce 도움말, Data Classification Metadata Fields (opens in a new tab)(영어), 확인일 2026-10-02.
• Salesforce 도움말, Einstein Trust Layer: Designed for Trust (opens in a new tab), Data Masking Limitations in Agentforce (opens in a new tab)(영어), 확인일 2026-10-02.
• Salesforce Developers, Insert or Update (Upsert) a Record Using an External ID (opens in a new tab)(영어), 확인일 2026-10-02.
• Salesforce 도움말, Picklist Limitations (opens in a new tab)(영어), 확인일 2026-10-02.
• Salesforce 도움말, Formula Field Limits and Restrictions (opens in a new tab)(영어), 확인일 2026-10-02.
• Salesforce Developers, Date Formats and Date Literals (opens in a new tab)(영어), 확인일 2026-10-02.