세일즈포스 생태계에서 커리어를 시작하려는 분들에게 Salesforce Certified Administrator 자격증은 가장 먼저 넘어야 할 산입니다. 저 역시 독학으로 준비하며 막막함을 느꼈던 시절이 있었습니다. 시중에는 수많은 유료 강의와 복잡한 가이드가 넘쳐나지만, 결국 핵심은 ‘시스템의 논리’를 이해하고 ‘시험의 유형’에 익숙해지는 것입니다. 오늘은 제가 직접 경험한, 가장 효율적이면서도 확실한 합격 노하우를 공유해 드리겠습니다.

자격증 준비의 첫걸음: 무작정 외우기보다 구조를 파악하라

세일즈포스 어드민 시험은 단순히 기능을 아는지를 묻지 않습니다. “A라는 기업이 이런 비즈니스 상황에 처했을 때, 관리자로서 어떤 도구를 제안하겠는가?”와 같은 상황 판단 문제가 주를 이룹니다. 따라서 공부의 시작은 반드시 공식 학습 플랫폼인 Trailhead여야 합니다.

저는 ‘Admin Beginner’ 트레일믹스를 따라가며 직접 개발자 환경(Developer Edition)에서 클릭하고 설정을 바꿔보았습니다. 눈으로만 보는 10번의 강의보다, 직접 유효성 검사 규칙(Validation Rule) 하나를 만들어 에러 메시지를 띄워보는 1번의 실습이 시험장에서 훨씬 더 큰 기억의 자산이 됩니다.

현실적인 시험 준비: 덤프(Dump)를 어떻게 활용할 것인가?

자격증 시험을 준비하다 보면 ‘덤프’라는 용어를 피할 수 없습니다. 덤프는 과거 기출문제나 예상 문제 모음집을 뜻합니다. 결론부터 말씀드리면, 덤프는 ‘합격의 지름길’이 될 수는 있지만 ‘실력의 지름길’은 아닙니다. 하지만 응시료가 200달러에 달하는 고가의 시험인 만큼, 덤프를 전략적으로 활용하는 것은 현실적으로 매우 중요합니다.

덤프 활용 시 주의해야 할 세 가지 원칙

1. 정답을 맹신하지 마라: 시중에 유통되는 무료 혹은 유료 덤프들 중에는 오답이 상당히 섞여 있습니다. 정답이라고 표시된 번호만 외웠다가는 실제 시험에서 큰 낭패를 볼 수 있습니다.
2. 공식 문서로 교차 검증하라: 덤프 문제를 풀다가 이해가 안 가거나 답이 이상하다면, 반드시 Salesforce Help 문서를 검색해야 합니다. 예를 들어 ‘Master-Detail’ 관계에 대한 문제라면 공식 문서에서 해당 관계의 특징과 제한 사항을 직접 확인하는 과정을 거치세요. 이 과정이 진짜 공부입니다.
3. 문제의 키워드를 분석하라: 덤프는 문제 은행 방식이기에 비슷한 문장이 반복됩니다. “Record Level Access”가 나오면 OWD나 Sharing Rule을 떠올리고, “Automate”가 나오면 Flow를 떠올리는 식의 키워드 매칭 훈련이 필요합니다.

영역별 핵심 요약: 시험에 반드시 나오는 ‘필승’ 테마

Salesforce Administration 시험에서 비중이 높고 덤프에서도 자주 등장하는 테마 3가지를 정리했습니다.

핵심 테마	시험에 나오는 결정적 포인트
보안 및 권한(Security)	OWD(전체) -> Role(수직) -> Sharing Rule(수평)로 이어지는 권한 확장 로직 파악
표준 및 커스텀 오브젝트	Master-Detail과 Lookup의 차이점, Roll-up Summary 필드 생성 조건
비즈니스 자동화(Automation)	Workflow, Process Builder, Flow 중 어떤 상황에 무엇이 최선인지(대세는 Flow)

실제 시험장 피드백과 당일 대응 전략

시험은 105분 동안 60문제를 풀어야 하며, 합격 커트라인은 약 65%입니다.

1. 상황 제시형 문제의 함정: “Sales Manager는 보고 싶어 하지만 Sales Rep은 숨겨야 한다”는 식의 보안 문제는 시험의 단골 손님입니다. 이럴 때는 가장 엄격한 설정(Private)부터 시작하는 논리를 잊지 마세요.
2. Mark for Review의 마법: 덤프에서 보지 못한 생소한 문제가 나와도 당황하지 마세요. 체크해 두고 넘어가면, 뒷부분의 다른 문제 지문 속에서 힌트를 얻는 경우가 의외로 많습니다.
3. 영문 대 한글, 무엇이 유리한가?: 한국어 번역이 과거보다 좋아졌지만, 기술 용어의 원뜻을 이해하기에는 영문 시험이 더 유리할 수 있습니다. 평소 영문 자료로 공부했다면 영문 시험을 선택해 용어의 혼동을 줄이시기 바랍니다.

마치며: 자격증은 ‘어드민 커리어’의 시작점일 뿐입니다

합격 통보를 받는 순간의 기쁨은 대단하지만, 자격증 자체가 실무 능력을 보장해주지는 않습니다. 덤프를 통해 시험 유형을 익히되, 그 과정에서 찾아본 공식 문서와 실습 환경에서의 경험이 진짜 여러분의 실력이 됩니다.

자격증 취득 후에는 실제 프로젝트 환경을 구축해 보거나, 한국 내 세일즈포스 커뮤니티 활동을 통해 실무자들의 고민을 엿보는 과정을 추천합니다. 여러분의 합격을 진심으로 응원합니다!

---

Salesforce Administration 자격증 관련 FAQ

덤프만 외워서 합격할 수 있나요?

운이 좋다면 가능할 수도 있지만 위험 부담이 큽니다. 최근 세일즈포스는 문제 유형을 조금씩 변형하고 있으며, 단순 암기만으로는 풀 수 없는 상황 판단 문제가 늘고 있습니다. 개념 이해 70%, 덤프 활용 30%의 비율을 권장합니다.

시험 응시료를 할인받는 팁이 있나요?

세일즈포스에서 무료로 제공하는 Certification Days 웨비나를 신청하세요. 1~2시간 분량의 요약 강의를 듣고 나면 이메일로 40달러에서 70달러 정도의 할인 쿠폰을 보내줍니다. 결제 전 구글에 ‘Salesforce certification coupon 2026’ 등을 검색해 최신 코드를 확인하는 것도 필수입니다.

자격증 유효기간과 갱신 방법은 어떻게 되나요?

세일즈포스 자격증은 한 번 따면 평생 가는 것이 아니라, 매년 유지보수(Maintenance)를 해야 합니다. 다행히 재시험을 볼 필요는 없고, Trailhead에서 제공하는 무료 유지보수 모듈을 정해진 기한 내에 완료하면 됩니다. 기한을 넘기면 자격증이 소멸되어 다시 200달러를 내고 시험을 봐야 하니 주의해야 합니다.

세일즈포스 관리자들 사이에서 “한 번 쓰면 절대 과거로 돌아갈 수 없다”고 정평이 난 도구가 있습니다. 바로 브라우저 확장 프로그램인 세일즈포스 인스펙터(Salesforce Inspector)입니다.

무거운 데이터 로더를 설치하고 로그인을 반복하는 번거로움 없이, 웹 브라우저 우측의 작은 화살표 하나로 수천 건의 데이터를 즉시 올릴 수 있는 이 마법 같은 도구의 활용법을 공유합니다. 엑셀 데이터를 복사해서 붙여넣기만 하면 끝나는, 가장 현대적인 데이터 적재 방식을 소개합니다.

1. 왜 인스펙터(Inspector)인가? (데이터 로더와의 한판 승부)

데이터 로더가 대형 덤프트럭이라면, 인스펙터는 기동성이 뛰어난 퀵서비스 오토바이와 같습니다.

특징	데이터 로더 (Data Loader)	세일즈포스 인스펙터 (Inspector)
준비 과정	프로그램 설치, 자바 설치, 로그인	브라우저 확장 프로그램 클릭 끝
데이터 입력	CSV 파일 저장 필수	엑셀에서 그냥 복사+붙여넣기(Ctrl+C, V)
속도	설정 및 매핑에 시간 소요	매핑 자동화로 즉시 실행
결과 확인	별도의 로그 파일 확인	화면에서 즉시 에러 행 확인 및 수정

2. 초간단 3단계 업로드 프로세스 (엑셀에서 바로 끝내기)

인스펙터를 사용하면 CSV 파일로 변환할 때 발생하는 ‘한글 깨짐’ 걱정을 할 필요가 없습니다. 엑셀의 데이터 포맷 그대로를 복사하기 때문입니다.

1단계: 엑셀 데이터 복사

업로드할 엑셀 시트에서 헤더(컬럼명)를 포함하여 데이터를 드래그한 뒤 Ctrl + C를 누릅니다. (인코딩 변환이나 CSV 저장 단계가 아예 생략됩니다!)

2단계: Data Import 메뉴 진입

세일즈포스 우측 상단의 인스펙터 화살표를 클릭하고 [Data Import] 메뉴를 선택합니다.

• Action: Insert, Update, Upsert 중 선택
• Object: 데이터를 넣을 대상 오브젝트(예: Account, Lead) 선택

3단계: 붙여넣기 및 매핑 (Paste & Map)

중앙의 하얀 박스에 Ctrl + V로 데이터를 붙여넣습니다. 인스펙터의 놀라운 점은 엑셀 헤더와 필드명이 조금만 비슷해도 자동으로 매핑(Auto-mapping)을 잡아준다는 것입니다. 빨간색으로 표시된 매핑되지 않은 필드만 수동으로 지정해 주면 준비 끝입니다.

3. 인스펙터 사용 시 ‘실무자만 아는’ 꿀팁

단순해 보이지만, 인스펙터를 더 스마트하게 쓰는 기술이 있습니다.

• Batch Size 조절: 기본값은 200입니다. 만약 업로드 중 에러가 발생한다면 ‘Options’에서 배치를 1~50 사이로 줄여보세요.
• 실시간 에러 수정: 업로드 중 특정 행에서 에러가 나면 화면에 즉시 빨간색으로 표시됩니다. 에러 메시지를 확인하고 엑셀에서 수정한 뒤, 해당 행만 다시 복사해 넣으면 되므로 피드백 루프가 굉장히 짧습니다.
• ID 값 추출의 간편함: 업데이트(Update)를 위해 ID가 필요하다면, 인스펙터의 [Data Export] 기능을 쓰세요. 쿼리 한 줄로 ID를 뽑아낸 뒤 엑셀로 바로 내보내고(Copy to Excel), 수정 후 다시 Import로 가져오는 과정이 물 흐르듯 연결됩니다.

4. 주의사항: 인스펙터도 ‘이것’만은 조심하세요

기동성이 좋은 만큼 주의해야 할 점도 명확합니다.

1. 대용량 데이터의 한계: 수십만 건 이상의 초대용량 데이터는 브라우저 메모리 한계로 인해 멈출 수 있습니다. 1~2만 건 내외의 작업에 가장 최적화되어 있습니다.
2. 복사 오류: 엑셀에서 복사할 때 숨겨진 행이나 필터링된 행이 포함되지 않았는지 반드시 확인하세요. 눈에 보이는 것만 복사되는 특성이 있습니다.
3. 인코딩의 역설: CSV 저장이 필요 없어서 한글 깨짐은 덜하지만, 엑셀 자체의 데이터에 특수문자가 섞여 있으면 붙여넣기 과정에서 포맷이 틀어질 수 있습니다.

---

세일즈포스 인스펙터 관련 실무 FAQ

Q. 인스펙터로 업로드한 데이터도 트리거가 작동하나요?

네, 동일하게 작동합니다. 인스펙터도 결국 세일즈포스 API를 사용하기 때문입니다. 만약 트리거 실행을 피하고 싶다면 인스펙터 옵션이 아니라, 세일즈포스 내부의 자동화 설정을 조정해야 합니다.

Q. 엑셀의 ‘날짜’ 형식이 자꾸 에러가 나요.

인스펙터는 텍스트를 그대로 복사해 오기 때문에 엑셀의 셀 서식이 중요합니다. 엑셀에서 날짜 컬럼을 YYYY-MM-DD 형식의 텍스트로 미리 변환한 뒤 복사해 보세요. 그러면 세일즈포스가 오류 없이 받아들입니다.

Q. 보안상 확장 프로그램을 써도 괜찮을까요?

인스펙터는 세일즈포스 커뮤니티에서 가장 널리 쓰이는 오픈소스 도구 중 하나입니다. 하지만 기업 보안 정책에 따라 크롬 확장 프로그램 설치가 제한될 수 있으니, 사전에 IT 팀의 가이드를 확인하는 것이 좋습니다. 데이터 자체는 별도의 서버를 거치지 않고 브라우저와 세일즈포스 간에 직접 통신하므로 상대적으로 안전합니다.

---

오늘 정리해 드린 세일즈포스 인스펙터(Salesforce Inspector) 활용법이 여러분의 반복되는 데이터 업무 시간을 획기적으로 줄여주길 바랍니다. 처음에는 생소할 수 있지만, 한 번 익숙해지면 왜 다들 이 도구를 ‘관리자의 필수 생존템’이라 부르는지 바로 체감하실 수 있을 거예요.

오늘 글이 도움이 되셨다면 좋겠습니다. 여러분의 칼퇴근과 효율적인 데이터 관리를 진심으로 응원합니다!

세일즈포스에 데이터를 열심히 쌓는 궁극적인 이유는 무엇일까요? 결국 ‘우리 비즈니스가 어디로 가고 있는지’를 한눈에 파악하기 위해서입니다. 하지만 단순히 리포트를 만들고 대시보드에 차트를 배치한다고 해서 경영진이 만족하는 것은 아닙니다. 데이터는 넘쳐나는데 정작 필요한 정보는 보이지 않는 ‘데이터의 홍수’ 현상을 겪기 쉽거든요.

오늘은 제가 실무에서 대시보드를 구축하며 느꼈던, ‘진짜 일 잘하는 관리자’의 시각화 전략을 공유해 보려 합니다.

시각화의 첫 단추: 리포트 타입 선택의 기술

리포트를 만들기 전 가장 먼저 고민해야 할 것은 어떤 데이터를 엮을 것인가입니다. 세일즈포스 리포트에는 크게 세 가지 유형이 있는데, 상황에 따라 적절한 선택이 필요합니다.

• Tabular(표 형식): 엑셀처럼 단순히 리스트를 나열할 때 씁니다. 데이터 전체를 훑어보기엔 좋지만, 시각화(차트)를 만들기엔 부적합합니다.
• Summary(요약 형식): 특정 필드(예: 영업 담당자, 지역)를 기준으로 데이터를 그룹화합니다. 대시보드 차트의 90%는 여기서 시작됩니다.
• Matrix(행렬 형식): 행과 열 양쪽으로 그룹화를 하는 방식입니다. 월별/지역별 매출 현황처럼 다차원적인 분석이 필요할 때 유용합니다.

대시보드 설계 시 고려해야 할 3가지 원칙

차트를 배치할 때 제가 항상 스스로에게 던지는 질문 세 가지가 있습니다. 이 원칙만 지켜도 대시보드의 퀄리티가 확 달라집니다.

1. 보는 사람(Persona)이 누구인가?

영업 사원이 보는 대시보드와 영업 본부장이 보는 대시보드는 완전히 달라야 합니다. 영업 사원에게는 ‘오늘 내가 팔아야 할 기회(Opportunity)’가 중요하지만, 본부장에게는 ‘이번 분기 전체 파이프라인과 목표 대비 달성률’이 중요합니다. 한 대시보드에 모든 걸 다 넣으려 하지 마세요.

2. 색상에 의미를 부여하라 (Conditional Formatting)

단순히 알록달록한 차트는 예쁘긴 하겠지만 유용하진 않습니다. 목표치에 도달하지 못한 수치는 빨간색으로, 안정권인 수치는 초록색으로 표시되는 ‘조건부 서식’을 적극 활용하세요. 보는 사람이 차트를 보자마자 “아, 저기 문제가 있구나”라고 느낄 수 있어야 합니다.

3. ‘차트’보다 중요한 것은 ‘필터’

대시보드 상단에 배치하는 필터(Dashboard Filters)는 대시보드의 활용도를 수십 배 높여줍니다. 지역별, 팀별로 필터를 걸어두면 하나의 대시보드로 여러 부서가 각자의 데이터만 골라 볼 수 있어 관리가 매우 편해집니다.

실무에서 자주 쓰이는 핵심 시각화 차트 비교

어떤 데이터를 어떤 차트로 그려야 할지 헷갈린다면 아래 가이드를 참고해 보세요.

데이터 성격	추천 차트	활용 예시
전체 대비 비중	Donut / Pie Chart	제품별 매출 비중, 리드 소스 분석
시간 흐름에 따른 변화	Line Chart	월별 신규 가입자 수 추이, 매출 트렌드
목표 대비 현재 수치	Gauge Chart	이번 달 매출 목표 달성률 (0% ~ 100%)
단계별 데이터 흐름	Funnel Chart	영업 파이프라인 단계별 전환율 분석
단순 수치 강조	Metric / Number	오늘 신규 발생한 케이스(Case) 수

마무리하며: 대시보드는 ‘정답’이 아니라 ‘질문’을 유도해야 한다

좋은 대시보드는 단순히 결과를 보여주는 데 그치지 않고, “왜 저 수치가 떨어졌지?”, “이 지역 매출은 왜 늘었을까?”라는 비즈니스적인 질문을 던지게 만듭니다. 데이터가 말해주는 이면에 집중할 수 있도록 최대한 심플하고 직관적으로 구성하는 것이 관리자의 진짜 실력입니다.

오늘 제가 공유해 드린 팁들이 여러분의 세일즈포스 활용 능력을 한 단계 높여주길 바랍니다. 차근차근 리포트 타입부터 점검해 보시는 건 어떨까요?

---

자주 묻는 질문 (FAQ)

Q1. 리포트에는 데이터가 보이는데, 대시보드에서는 안 보여요. 왜 그런가요?

이 문제는 보통 ‘Running User’ 설정 때문일 가능성이 큽니다. 대시보드는 특정 사용자의 권한으로 데이터를 조회하도록 설정되는데, 리포트를 조회하는 사람의 권한과 대시보드 실행 유저의 권한이 다르면 데이터가 보이지 않거나 다르게 보일 수 있습니다. 대시보드 설정에서 ‘View Dashboard As’ 항목을 확인해 보세요.

Q2. 엑셀처럼 수식을 써서 리포트 필드를 만들 순 없나요?

세일즈포스 리포트에는 **’Summary Formula Column’**이라는 강력한 기능이 있습니다. 리포트 내에서 수치를 계산(예: 승률 = 수주 건수 / 전체 건수)하여 보여줄 수 있죠. 오브젝트 자체에 필드를 새로 만들지 않고도 리포트 안에서만 계산된 값을 보고 싶을 때 아주 유용합니다.

Q3. 대시보드 새로고침 주기를 더 짧게 할 순 없나요?

표준 설정에서는 하루에 몇 번(Enterprise 에디션 기준 1시간 단위 등) 자동 새로고침이 가능하지만, 실시간에 가까운 데이터를 원한다면 유료 확장 기능을 쓰거나 별도의 대시보드 컴포넌트를 고려해야 합니다. 하지만 대부분의 비즈니스 의사결정은 수동 새로고침 버튼을 누르는 것만으로도 충분히 대응 가능합니다.

세일즈포스 관리자로 살다 보면 가장 많이 받는 질문 중 하나가 바로 “분명히 필드를 만들었는데 왜 보고서 만들 때는 안 보이죠?”입니다. 시스템 설정에서는 분명히 보이는데, 보고서 편집기에서는 아무리 검색해도 나오지 않는 기현상. 이는 대부분 리포트 타입(Report Types)에 대한 이해 부족에서 시작됩니다. 오늘은 실제 실무 현장에서 벌어지는 에피소드를 통해 이 문제를 뿌리 뽑아보겠습니다.

월요일 오전, 영업팀장의 호출과 어드민의 식은땀

영업팀장: “어드민님, 지난번에 요청한 ‘고객별 최근 상담 내역’ 보고서 말이에요. 제가 직접 수정하려고 보니까 ‘상담 메모’ 필드가 아예 검색이 안 되는데요? 필드 삭제하신 거 아니죠?”

어드민: “네? 그럴 리가요. 제가 금방 확인해 보겠습니다.”

(어드민은 급히 오브젝트 매니저에 들어가 필드가 정상적으로 존재하는 것을 확인한다. 하지만 실제로 보고서를 새로 만들려고 하니, 팀장님 말씀대로 해당 필드가 리스트에 없다. 식은땀이 흐르기 시작한다.)

어드민: “아… 팀장님, 죄송합니다. 필드는 살아있는데 ‘리포트 타입’에 반영이 안 되어 있었네요. 1분만 기다려주세요!”

이런 상황, 세일즈포스 어드민이라면 누구나 한 번쯤 겪어보셨을 겁니다. 필드를 생성했다고 해서 모든 보고서에 자동으로 나타나는 것이 아니라는 점, 바로 여기서부터 커스텀 리포트 타입의 중요성이 시작됩니다.

데이터의 연결 고리, Inner Join과 Outer Join 이해하기

보고서가 제대로 나오지 않는 이유는 크게 두 가지입니다. 첫째는 필드가 리포트 타입 레이아웃에 포함되지 않았기 때문이고, 둘째는 리포트 타입 자체가 데이터의 관계를 잘못 정의했기 때문입니다. 이를 이해하려면 데이터베이스의 조인(Join) 개념을 알아야 합니다.

1. 교집합(A with B): “둘 다 있는 것만 가져와!”

표준 리포트 타입의 상당수는 Inner Join 방식을 따릅니다. 예를 들어 ‘계정 및 연락처(Accounts with Contacts)’ 리포트 타입을 선택하면, 연락처가 하나도 없는 계정은 보고서에서 아예 누락됩니다.

• 문제점: 영업팀장이 “연락처가 없는 계정 리스트를 뽑아달라”고 하면 이 리포트 타입으로는 절대 결과값을 낼 수 없습니다.

2. 외부 조합(A with or without B): “B가 없어도 일단 A는 다 보여줘!”

이것이 바로 Outer Join입니다. ‘계정이 주체이고, 연락처가 있으면 보여주되 없어도 계정은 리스트에 남겨두는’ 방식입니다.

• 해결책: 커스텀 리포트 타입을 생성할 때 관계 설정을 “A 레코드에는 연관된 B 레코드가 있거나 없어도 됨”으로 설정해야 합니다. 이렇게 해야 비어 있는 데이터까지 포함된 완벽한 현황판을 만들 수 있습니다.

필드가 안 보일 때 해결하는 3단계 프로세스

새로 만든 필드가 보고서에서 보이지 않는다면 다음 순서대로 점검해 보세요.

Step 1. 필드 레벨 보안(FLS) 확인

가장 기초적인 단계입니다. 필드를 만들 때 해당 사용자의 ‘프로필’에 읽기 권한을 주었는지 확인하세요. 본인에게 안 보인다면 권한 문제일 확률이 높습니다.

Step 2. 커스텀 리포트 타입 레이아웃 편집

표준 리포트 타입은 새 필드가 자동으로 추가되지만, 커스텀 리포트 타입은 관리자가 직접 수동으로 필드를 레이아웃에 던져넣어 주어야 합니다.

• Setup > Custom Report Types > 해당 타입 선택 > Edit Layout으로 들어가서 우측 필드 리스트에서 새로 만든 필드를 드래그하여 레이아웃에 추가하세요.

Step 3. ‘보고서에 추가(Add to Report)’ 옵션 체크

필드를 생성할 때 마지막 단계에서 “이 필드를 기존 리포트 타입에 자동으로 추가하시겠습니까?”라는 체크박스가 있습니다. 급하게 필드를 만들다 이 부분을 놓치면 나중에 일일이 리포트 타입을 찾아다니며 수정해야 하는 번거로움이 발생합니다.

보고서 만들기 전 반드시 확인해야 할 3가지

완벽한 보고서를 설계하기 위해 다음 세 가지만큼은 꼭 자문해 보세요.

1. 기준 오브젝트가 무엇인가? (어떤 데이터가 누락되면 안 되는가?)
   • 누락되면 안 되는 오브젝트를 ‘A(Primary Object)’로 설정해야 합니다.
2. 연관 관계가 ‘필수’인가 ‘선택’인가?
   • 하위 레코드가 없는 경우도 보고서에 나와야 한다면 반드시 ‘with or without’ 관계의 커스텀 리포트 타입을 만드세요.
3. 사용자가 직접 필드명을 찾을 수 있는가?
   • 리포트 타입 레이아웃 편집기에서 필드 이름을 ‘표시 이름(Display As)’ 기능을 통해 사용자가 이해하기 쉬운 한글로 미리 변경해 두면 질문 전화가 확연히 줄어듭니다.

리포트 타입은 데이터의 창문입니다

보고서는 세일즈포스에 쌓인 원천 데이터를 가치 있는 정보로 바꾸는 최종 결과물입니다. 필드가 보이지 않는 현상은 단순한 오류가 아니라, 데이터의 관계 설정을 재검토하라는 시스템의 신호일 때가 많습니다. 오늘 알려드린 레이아웃 편집 방법과 조인(Join)의 개념만 명확히 잡으셔도, “필드가 안 보여요”라는 팀장님의 호출에 당황하지 않고 여유 있게 대처하실 수 있을 것입니다.

---

리포트 타입 관련 자주 묻는 질문 (FAQ)

Q1. 표준 리포트 타입은 수정할 수 없나요?

네, 세일즈포스에서 기본으로 제공하는 표준 리포트 타입(예: Accounts & Contacts)의 필드 구성이나 관계 설정은 수정이 불가능합니다. 표준 타입에서 원하는 필드가 보이지 않거나 관계가 맞지 않는다면, 지체 없이 ‘Custom Report Type’을 새로 생성하는 것이 정신 건강에 이롭습니다.

Q2. 커스텀 리포트 타입을 만들었는데 기존 보고서에 바로 적용할 수 있나요?

아쉽게도 이미 만들어진 보고서의 리포트 타입을 중간에 바꿀 수는 없습니다. 보고서의 ‘속성’에서 리포트 타입을 변경하는 기능은 제공되지 않기 때문에, 새로운 커스텀 리포트 타입을 기반으로 보고서를 새로 생성해야 합니다. 따라서 처음부터 리포트 타입을 신중하게 선택하는 설계 역량이 중요합니다.

Q3. 리포트 타입에 필드를 추가했는데도 여전히 안 보여요.

간혹 브라우저 캐시 문제일 수 있습니다. 설정을 마친 후 보고서 편집 화면을 새로고침(F5) 하거나, ‘Fields’ 패널 상단의 검색창 옆에 있는 새로고침 아이콘을 클릭해 보세요. 또한, 해당 필드가 ‘Hidden’ 상태로 레이아웃에 들어가 있는지도 다시 한번 확인이 필요합니다.

---

오늘의 가이드가 여러분의 칼퇴를 돕는 유익한 정보가 되었길 바랍니다. 데이터 구조를 완벽히 장악하는 어드민이 되는 그날까지 응원하겠습니다!

다음에는 “보고서 수식(Summary Formula)으로 전년 대비 성장률 계산하기”와 같은 심화 주제로 찾아오겠습니다. 궁금한 점은 언제든 말씀해 주세요!

세일즈포스 개발을 하다 보면 누구나 한 번쯤은 맞닥뜨리는 공포의 메시지가 있습니다. 바로 System.LimitException: Too many SOQL queries: 101입니다. 잘 작동하던 기능이 대량의 데이터를 처리할 때 갑자기 멈춰버리는 이 에러는 세일즈포스 입문자와 숙련자를 가르는 기준점이 되기도 합니다. 오늘은 이 에러가 왜 발생하는지, 그리고 실무에서 이를 어떻게 완벽하게 해결하고 예방할 수 있는지 심층적으로 다루어 보겠습니다.

101 에러, 왜 나만 괴롭히는 걸까?

세일즈포스는 ‘멀티 테넌트(Multi-tenant)’ 환경입니다. 즉, 하나의 물리적 서버 자원을 여러 기업이 나누어 씁니다. 만약 한 명의 개발자가 효율적이지 못한 코드로 서버 자원을 독점하면 다른 사용자들에게 피해가 가기 때문에, 세일즈포스는 하나의 트랜잭션 내에서 실행할 수 있는 SOQL 쿼리 수를 최대 100개로 엄격히 제한하고 있습니다. 101 에러는 바로 이 ‘100개’라는 마법의 숫자를 넘겼을 때 발생합니다.

대부분의 경우 이 에러는 코드의 논리적 흐름이 반복문(For Loop) 안에서 쿼리를 호출하고 있을 때 발생합니다. 데이터가 한두 건일 때는 문제가 없다가, 실제 운영 환경에서 수십 건 이상의 레코드가 한꺼번에 처리되는 순간 쿼리 횟수가 100회를 초과하며 시스템이 셧다운되는 것입니다.

실무 사례로 보는 101 에러의 주범과 해결책

가장 흔한 실수 사례를 통해 코드를 어떻게 개선해야 하는지 살펴보겠습니다.

안 좋은 예시 (Anti-Pattern)

아래 코드는 계정(Account) 리스트를 돌면서 각 계정에 속한 연락처(Contact)를 매번 쿼리합니다. 만약 계정이 101개라면 즉시 에러가 발생합니다.

Apex

// 치명적인 실수: 루프 내부의 쿼리
for (Account acc : Trigger.new) {
    List<Contact> cons = [SELECT Id FROM Contact WHERE AccountId = :acc.Id];
    // 비즈니스 로직 수행...
}

권장 예시 (Bulkification 전략)

해결 방법은 쿼리를 루프 밖으로 꺼내는 ‘벌크화(Bulkification)’입니다. 쿼리는 단 한 번만 수행하고, 결과 데이터를 Map에 담아 루프 안에서 꺼내 쓰는 방식입니다.

Apex

// 해결책: 쿼리를 한 번으로 최적화
Set<Id> accIds = Trigger.newMap.keySet();
List<Contact> allContacts = [SELECT Id, AccountId FROM Contact WHERE AccountId IN :accIds];

// 효율적인 데이터 접근을 위한 Map 활용
Map<Id, List<Contact>> accToConMap = new Map<Id, List<Contact>>();
for (Contact con : allContacts) {
    if (!accToConMap.containsKey(con.AccountId)) {
        accToConMap.put(con.AccountId, new List<Contact>());
    }
    accToConMap.get(con.AccountId).add(con);
}

// 루프 안에서는 쿼리 없이 Map에서 데이터를 가져옴
for (Account acc : Trigger.new) {
    List<Contact> cons = accToConMap.get(acc.Id);
    // 비즈니스 로직 수행...
}

이 방식을 사용하면 처리해야 할 레코드가 1,000건이든 10,000건이든 쿼리는 단 1회만 실행됩니다. 이것이 세일즈포스 개발의 정석입니다.

내 코드에는 쿼리가 없는데 왜 101 에러가 날까?

때로는 내 Apex 클래스 안에는 루프 쿼리가 없는데도 101 에러가 발생하여 우리를 당황하게 합니다. 이때는 다음 두 가지 가능성을 의심해야 합니다.

1. 트리거 재귀(Recursion): 레코드를 업데이트할 때 트리거가 다시 자기 자신을 호출하거나 다른 트리거를 연쇄적으로 깨워 쿼리 횟수가 누적되는 경우입니다. Static 변수를 활용하여 트리거 재귀를 방지하는 로직이 필요합니다.
2. 선언적 도구(Flow/Process Builder)의 영향: 세일즈포스는 코드뿐만 아니라 해당 트랜잭션에서 실행되는 플로우나 프로세스 빌더의 쿼리 사용량도 합산합니다. 특히 플로우 내에서 ‘Get Records’ 요소가 루프 안에 들어가 있다면 101 에러의 강력한 용의자가 됩니다.

101 에러 예방을 위한 3단계 체크리스트

시스템의 안정성을 높이기 위해 개발 과정에서 반드시 지켜야 할 체크리스트입니다.

• 쿼리 수집(Collection): 모든 SOQL은 WHERE 필드 IN :컬렉션 형태를 갖추고 루프 외부에서 실행되는가?
• Map 기반 아키텍처: 관계가 있는 데이터를 매칭할 때 중첩 For문을 돌리는 대신 Map을 사용하여 CPU 시간과 쿼리 효율성을 챙겼는가?
• 트랜잭션 가시성: 디버그 로그(Debug Log)의 LIMIT_USAGE_FOR_NS 섹션을 확인하여 현재 트랜잭션의 쿼리 사용량이 위험 수준(예: 80회 이상)에 도달하지 않았는지 모니터링하는가?

101 에러에 대해 자주 묻는 질문 (FAQ)

Q1. 에러가 발생한 위치를 어떻게 정확히 찾을 수 있나요?

세일즈포스 Setup > Debug Logs에서 로그를 생성한 뒤 실행해 보세요. 로그 파일에서 SOQL_EXECUTION_BEGIN 키워드를 검색하면 어떤 쿼리가 반복적으로 실행되고 있는지 추적할 수 있습니다. 또한 로그 하단의 Cumulative Limit Usage 섹션을 보면 어느 시점에 쿼리 수가 급증했는지 한눈에 파악할 수 있습니다.

Q2. 쿼리 결과가 5만 건을 넘으면 어떻게 하나요?

101 에러는 쿼리의 ‘횟수’에 대한 제한이고, 5만 건 제한은 쿼리로 가져오는 ‘레코드 수’에 대한 제한입니다. 만약 5만 건 이상의 대량 데이터를 처리해야 한다면 Batch Apex를 사용해야 합니다. 배치 클래스는 데이터를 200개(기본값) 단위의 작은 묶음으로 나누어 여러 개의 독립된 트랜잭션으로 처리하므로 101 에러와 5만 건 제한을 동시에 회피할 수 있습니다.

Q3. 플로우(Flow)에서도 101 에러를 피하는 방법이 있나요?

플로우 역시 벌크화 원칙이 동일하게 적용됩니다. 루프 안에서 ‘Get Records’나 ‘Update Records’ 요소를 절대 배치하지 마세요. 대신 루프 시작 전에 필요한 데이터를 모두 가져오고, 루프 안에서는 ‘Assignment’ 요소를 이용해 컬렉션 변수에 데이터를 모은 뒤, 루프가 끝난 다음에 한꺼번에 ‘Update’ 요소를 실행해야 합니다.

마치며: 리밋은 제약이 아닌 아키텍처의 가이드라인

Too many SOQL queries: 101 에러는 결코 무서운 적이 아닙니다. 오히려 우리에게 “이 코드는 비효율적이니 더 나은 구조로 개선하라”고 알려주는 친절한 가이드라인에 가깝습니다. 벌크화와 Map 활용을 습관화한다면 리밋의 공포에서 벗어나 훨씬 더 견고한 세일즈포스 시스템을 구축할 수 있을 것입니다.

오늘 정리한 해결법이 여러분의 디버깅 시간을 줄여주고, 더 나은 코드를 작성하는 데 도움이 되기를 바랍니다. 다음에는 CPU 타임아웃 리밋을 줄이는 고도의 최적화 기법에 대해 다루어 보겠습니다.

세일즈포스 자동화의 심장, 플로우 트리거 5종 심층 분석 및 아키텍처 가이드

세일즈포스 생태계에서 ‘선언적 개발(Declarative Development)’의 위상이 그 어느 때보다 높습니다. 과거에는 Apex 코딩으로만 가능했던 복잡한 로직들이 이제는 플로우(Flow)라는 강력한 도구 안에서 모두 구현 가능해졌기 때문입니다. 특히 워크플로우와 프로세스 빌더가 공식적으로 은퇴의 길을 걸으면서, 모든 관리자와 개발자에게 플로우 마스터는 선택이 아닌 생존의 문제가 되었습니다.

하지만 단순히 플로우를 ‘그릴 줄 아는 것’과 ‘최적화된 설계를 하는 것’은 전혀 다른 차원의 이야기입니다. 그 설계의 시작점이 바로 트리거 유형(Trigger Type)의 선택입니다. 트리거를 잘못 선택하면 시스템의 퍼포먼스가 급격히 저하되거나, 거버너 리밋(Governor Limits)의 벽에 부딪혀 비즈니스 프로세스가 마비될 수 있습니다. 오늘은 현업에서 가장 많이 쓰이는 5가지 플로우 트리거를 파헤치고, 각 상황에 맞는 아키텍처 설계 전략을 공유하겠습니다.

1. 레코드 트리거 플로우 (Record-Triggered Flow): 최적화의 승부처

가장 대중적이면서도 기술적 깊이가 요구되는 유형입니다. 레코드의 생성, 수정, 삭제가 일어나는 순간 실행되는데, 여기서 우리는 실행 시점(Order of Execution)에 주목해야 합니다.

Fast Field Updates (Before-Save)는 플로우의 보석 같은 기능입니다. 레코드가 데이터베이스에 실제로 저장되기 직전에 값을 변경합니다. 이는 데이터베이스에 ‘쓰기’ 작업을 한 번만 수행하게 만들므로, After-Save 방식보다 압도적으로 빠릅니다. 만약 업데이트하려는 대상이 트리거를 발생시킨 ‘자기 자신’이라면, 고민할 필요 없이 무조건 이 방식을 써야 합니다. 예를 들어, 리드의 특정 주소 정보를 바탕으로 지역(Region) 필드를 자동 할당하는 로직은 여기서 처리하는 것이 베스트 프랙티스입니다.

Actions and Related Records (After-Save)는 레코드가 저장된 이후에 작동합니다. “저장이 완료되었으니 이제 다른 일을 해도 좋다”는 신호와 같습니다. 관련 있는 다른 레코드를 생성하거나, 이메일 알림을 보내고, 외부 시스템으로 데이터를 전송하는 등의 작업은 여기서 이루어집니다.

2. 스케줄 트리거 플로우 (Schedule-Triggered Flow): 효율적인 자원 관리의 핵심

많은 관리자가 간과하는 사실 중 하나는, 모든 것을 실시간(Real-time)으로 처리할 필요는 없다는 점입니다. 실시간 처리가 많아질수록 시스템 부하는 커집니다. 이때 구원투수가 되는 것이 바로 스케줄 트리거 플로우입니다.

이 유형은 배치(Batch) 프로세스처럼 작동합니다. 예를 들어 “매일 밤 12시에 종료일이 지난 영업 기회의 상태를 ‘기간 만료’로 변경하라”는 요구사항이 있다면, 굳이 레코드가 수정될 때마다 트리거를 태울 필요가 없습니다. 스케줄 플로우를 통해 비혼잡 시간대에 일괄 처리함으로써 시스템의 안정성을 확보할 수 있습니다. 특히 대용량 데이터를 다룰 때 세일즈포스가 내부적으로 200개씩 묶어서(Chunking) 처리해주기 때문에 리밋 관리 측면에서도 매우 유리합니다.

3. 스크린 플로우 (Screen Flow): 사용자 경험(UX)의 완성

플로우 중 유일하게 사용자 인터페이스를 가지는 유형입니다. 단순한 데이터 입력 창을 넘어, 비즈니스 로직이 가미된 ‘지능형 마법사’ 역할을 수행합니다.

실무에서는 주로 복잡한 인테이크(Intake) 과정을 간소화할 때 사용합니다. 예를 들어 고객 서비스 센터에서 상담원이 전화를 받으면서 정보를 입력할 때, 고객의 유형(개인/기업)에 따라 다음에 보여줄 화면을 동적으로 제어할 수 있습니다. 이는 데이터 입력의 오류를 원천 차단하고 교육 비용을 획기적으로 줄여줍니다. 또한, 라이트닝 페이지나 유틸리티 바에 배치하여 접근성을 높일 수 있다는 점도 큰 장점입니다.

4. 자동 실행 플로우 (Autolaunched Flow): 모듈화와 재사용성의 실현

현명한 관리자는 같은 로직을 두 번 쓰지 않습니다. 자동 실행 플로우는 트리거 없이 존재하며, 오직 호출(Call)에 의해서만 움직입니다.

이 유형의 진가는 서브 플로우(Subflow)로서의 역할에서 드러납니다. 예를 들어 기업마다 복잡한 ‘할인율 계산 로직’이 있다고 가정해 봅시다. 이 로직을 영업 기회 플로우에도 넣고, 주문 플로우에도 각각 넣는다면 나중에 로직이 바뀔 때 모든 곳을 수정해야 합니다. 대신 할인율 계산만 수행하는 자동 실행 플로우를 하나 만들고, 각 플로우에서 이를 호출하게 만들면 유지보수가 매우 단순해집니다. 이는 프로그래밍의 ‘함수(Function)’ 개념과 같습니다.

5. 플랫폼 이벤트 트리거 플로우 (Platform Event-Triggered Flow): 확장 가능한 아키텍처

현대적인 엔터프라이즈 환경에서는 시스템 간의 연동이 필수입니다. 플랫폼 이벤트 트리거는 외부 시스템이나 세일즈포스 내 다른 프로세스로부터 ‘이벤트 메시지’를 수신했을 때 실행됩니다.

가장 큰 특징은 비동기(Asynchronous) 처리입니다. 어떤 작업이 완료될 때까지 기다리는 것이 아니라, 메시지만 던져두고 다음 작업을 진행하는 방식입니다. 예를 들어 배송 시스템에서 “배송 완료” 신호를 쐈을 때, 세일즈포스가 이를 받아 고객에게 문자를 보내고 상태를 업데이트하는 로직을 짤 때 유용합니다. 이는 시스템 간의 결합도(Coupling)를 낮추어 한쪽의 장애가 다른 쪽으로 전이되는 것을 막아줍니다.

선택을 위한 최종 가이드: 상황별 매칭 리스트

어떤 트리거를 써야 할지 여전히 모호하다면, 아래의 실무 가이드를 참고해 보세요.

업무 요구사항	최적의 트리거 유형	추천 이유
현재 수정 중인 레코드의 필드 값만 바꾼다	Record (Before-Save)	가장 빠르고 리밋 소모가 적음
레코드가 생성될 때 관련 하위 레코드도 만든다	Record (After-Save)	ID가 생성된 후 연관 관계 설정 가능
매주 월요일 아침 미결 업무 리포트를 보낸다	Schedule-Triggered	정기적인 배치 작업에 최적화
사용자의 선택에 따라 입력 항목이 달라져야 한다	Screen Flow	인터랙티브한 UI 제공 가능
여러 플로우에서 공통으로 쓰는 로직이 있다	Autolaunched Flow	코드의 재사용성 및 유지보수 용이
외부 시스템의 신호를 받아 즉시 처리해야 한다	Platform Event	비동기식 대용량 연동에 강점

실무자가 가장 자주 묻는 질문 3가지 (FAQ)

Q1. 하나의 오브젝트에 여러 레코드 트리거 플로우를 만들어도 될까요?

기술적으로는 가능하지만, 관리가 매우 어려워집니다. 세일즈포스는 ‘Trigger Order’ 기능을 통해 실행 순서를 지정할 수 있게 지원하므로, 로직이 너무 복잡하다면 목적별로 분리하되 반드시 순서를 명시해야 합니다. 하지만 가급적이면 하나의 오브젝트에는 하나의 After-Save 플로우(또는 Before-Save)를 유지하고, 내부에서 ‘Decision’ 요소를 통해 분기하는 것이 전체적인 로직 흐름을 한눈에 파악하기에 더 좋습니다.

Q2. 스케줄 플로우가 실행되지 않고 실패하는 주된 원인은 무엇인가요?

가장 흔한 원인은 ‘쿼리 제한’이나 ‘권한 문제’입니다. 스케줄 플로우는 특정 실행 유저의 권한으로 돌아가는데, 그 유저가 대상 레코드에 접근 권한이 없으면 무시될 수 있습니다. 또한, 실행 조건(Filter)을 지정하지 않아 대상 레코드가 너무 많을 경우 타임아웃이 발생할 수 있습니다. 항상 ‘Start’ 요소에서 조건 필터를 꼼꼼하게 설정하여 처리 대상을 최소화하는 습관이 필요합니다.

Q3. 플로우 내에서 루프(Loop)를 돌릴 때 주의할 점은 무엇인가요?

플로우의 가장 무서운 적은 ‘루프 안의 쿼리(DML/SOQL)’입니다. 루프 안에서 레코드를 하나씩 업데이트(Update)하거나 조회(Get Records)하면 즉시 거버너 리밋에 걸려 플로우가 중단됩니다. 반드시 루프 밖에서 변수(Collection Variable)에 데이터를 모은 뒤, 루프가 끝난 후에 한 번에 DML 작업을 수행하는 ‘벌크화(Bulkification)’를 적용해야 합니다. 이는 관리자와 개발자를 구분하는 가장 큰 실력 차이이기도 합니다.

---

도구의 이해가 시스템의 품격을 만든다

세일즈포스 플로우는 단순한 자동화 도구를 넘어선 강력한 로우코드 엔진입니다. 5가지 트리거의 특성을 명확히 이해하고 적재적소에 배치하는 능력은, 효율적인 시스템 운영뿐만 아니라 여러분의 전문성을 증명하는 지표가 될 것입니다. 오늘 정리해 드린 트리거별 특징과 주의사항을 바탕으로, 여러분의 조직에 가장 최적화된 자동화 아키텍처를 설계해 보시길 바랍니다.

이후에는 이러한 플로우를 테스트하고 배포하는 과정에서의 팁이나, 에러 발생 시 디버깅하는 노하우에 대해서도 다루어 보도록 하겠습니다. 여러분의 성공적인 자동화 여정을 응원합니다.