세일즈포스 운영 점검 체크리스트: org 진단부터 Flow·AI 생성 코드까지

세일즈포스 운영 점검은 "지금 잘 돌아가는가"가 아니라 "데이터와 사용자가 지금보다 몇 배 늘어도 버티는가"를 확인하는 작업입니다. 구축 후 몇 년이 지나면 필드·자동화·연동이 겹겹이 쌓이고, 최근에는 AI가 생성한 코드까지 더해지면서 문제가 조용히 누적되는 속도가 빨라졌습니다. 이 글은 세일즈포스 구축·운영 파트너 아이투맥스가 세일즈포스 공식 발표와 최근 아키텍트 가이드를 바탕으로, 운영 점검 때 확인할 항목을 org 진단, Flow 확장성, AI 생성 코드 세 영역의 체크리스트로 정리한 것입니다.

세일즈포스 운영 점검이란? 왜 지금 필요한가

세일즈포스 운영 점검은 org의 설정·권한·자동화·코드를 정기적으로 훑어보고, 장애가 나기 전에 고칠 순서를 정하는 일입니다. 도입 첫날의 org는 단순하지만, 해마다 제품이 추가되고 커스텀 필드와 연동이 늘어나면서 누구도 전체 그림을 보지 못하는 상태가 됩니다. 관리자는 설정을, 보안 담당자는 권한을, 아키텍트는 설계를, 현업 책임자는 라이선스만 보는 식입니다.

세일즈포스도 이 문제를 공식적으로 짚고 있습니다. 2026년 11월 공개된 Salesforce Health Insights는 org를 상시 스캔해 벤치마크와 비교하고, 고칠 항목을 심각도 순으로 보여주는 기능입니다. 세일즈포스는 사람이 수동으로 하는 org 점검이 최대 3주까지 걸리고, 끝나는 시점에는 이미 내용이 낡아 있다고 설명합니다(Salesforce 공식 블로그). 이 기능은 Winter '27 릴리스부터 Signature Success Plan 고객의 Core 제품에 추가 비용 없이 제공됩니다. 해당 플랜이 아니라면 같은 관점의 점검을 직접 해야 한다는 뜻이기도 합니다.

세일즈포스 org 진단, 무엇부터 확인해야 하나

가장 먼저 확인할 것은 "쓰고 있는 것"과 "고쳐야 할 것"을 나눠 보는 일입니다. Health Insights도 이 두 축(제품 활용도, 구현 상태)으로 결과를 보여주는데, 직접 점검할 때도 같은 틀이 유용합니다.

이 표에서 우선순위는 "영향 범위 × 고치는 데 드는 노력"으로 정합니다. 권한 공백처럼 영향이 크고 고치기 쉬운 항목을 먼저, 데이터 모델 재설계처럼 영향은 크지만 손이 많이 가는 항목은 별도 과제로 떼어 냅니다.

Flow는 어떻게 점검해야 하나: 커질수록 터지는 5가지

Flow 점검의 핵심 질문은 하나입니다. "이 레코드가 한 번에 200건 들어와도 같은 결과가 나오는가?" Data Loader 작업이나 대량 API 연동은 200건을 한 트랜잭션으로 보내고, 그 트랜잭션 안의 모든 자동화가 같은 한도를 나눠 씁니다. Salesforce Ben이 2026년 11월 정리한 Flow 확장 실수 10가지 중, 운영 점검에서 특히 자주 걸리는 항목은 다음 다섯 가지입니다.

• 반복(Loop) 안에서 조회·저장: 5건일 때는 문제없지만 200건이면 조회 100회·DML 150회 한도에 바로 닿습니다. 조회는 반복 전에 한 번, 저장은 반복 후 한 번으로 바꿉니다.
• 같은 레코드를 여러 번 저장: 저장할 때마다 다른 트리거·Flow·유효성 규칙이 다시 돌아 CPU 시간과 잠금 위험이 늘어납니다.
• 하드코딩된 ID: 레코드 유형·큐 ID를 직접 넣으면 샌드박스와 운영 환경의 값이 달라 배포 때마다 손을 대야 합니다. DeveloperName 조회나 커스텀 메타데이터로 바꿉니다.
• 오류 경로 없음: 실패 시 무엇을 할지 정하지 않으면, 반쯤 처리된 레코드가 남거나 오류가 아무도 모르게 쌓입니다. 공통 오류 기록 서브플로를 두는 방식이 관리하기 쉽습니다.
• 단건 디버그만으로 테스트 완료: 한 건 성공은 확장성을 증명하지 못합니다. 대량 데이터로 조회 수·DML 수·CPU 시간이 한도의 몇 %인지 확인해야 합니다.

점검 순서는 데이터가 가장 많이 쌓이는 객체의 Flow부터, 그리고 같은 트랜잭션을 공유하는 다른 자동화까지 함께 보는 것이 효율적입니다.

AI가 짠 세일즈포스 코드, 무엇을 더 확인해야 하나

AI가 생성한 코드는 기능이 맞고 테스트를 통과해도 운영에서 트랜잭션을 멈춰 세울 수 있습니다. 세일즈포스 공식 블로그의 아키텍트 글(2026년 11월 5일)은 그 이유를 "AI는 눈앞의 작업만 최적화하고, 그 코드가 실행될 트랜잭션 전체는 보지 않기 때문"이라고 설명합니다.

예를 들어 스프린트마다 AI가 같은 트리거에 기능을 하나씩 더하면, 조회 한도 사용률이 15% → 32% → 51% → 59%로 올라갑니다. 각 기능은 단독 테스트를 모두 통과하지만, 어느 순간 무해해 보이는 변경 하나가 한도를 넘깁니다. 사람이 개발할 때는 몇 달에 걸쳐 일어나던 일이 AI로는 하루 오후 만에 일어날 수 있다는 것이 이 글의 지적입니다.

같은 글은 실행 맥락별로 거버너 한도를 "예산"처럼 나눠 쓰라고 권합니다.

운영 점검 관점에서 확인할 것은 세 가지입니다. 첫째, 트리거 테스트가 200건 대량 기준으로 작성돼 있는가. 둘째, 테스트가 "통과 여부"뿐 아니라 "한도의 몇 %를 썼는가"를 기록하는가. 셋째, 개발팀이 AI에게 테스트 기준을 규칙으로 주고 있는가(이 글은 저장소 규칙 파일에 "200건 대량 테스트 필수"를 명시하라고 권합니다).

세일즈포스 운영 점검 체크리스트

위 내용을 정기 점검용으로 줄이면 다음과 같습니다. 분기에 한 번, 그리고 대규모 데이터 이관이나 신규 연동 직전에 한 번씩 돌리는 것을 권합니다.

• 활성 사용자 대비 라이선스 사용률, 90일 이상 미접속 계정 확인
• 관리자 권한·전체 데이터 조회 권한을 가진 사용자 목록 재확인
• 객체별 실행 자동화(Flow·트리거·프로세스) 개수와 실행 순서 정리
• 반복 안 조회·저장, 하드코딩 ID가 있는 Flow 목록화
• 오류 경로가 없는 Flow와 오류 알림 수신자 확인
• 자식 레코드 1만 건 이상 부모 레코드, 한 사용자 소유 1만 건 이상 객체 확인
• 주요 트리거의 200건 대량 테스트 존재 여부와 한도 사용률 기록
• AI 생성 코드에 대한 리뷰·테스트 기준 문서화 여부

아이투맥스는 운영 점검을 어떻게 지원하나

아이투맥스는 세일즈포스 구축 이후의 유지보수·운영 대행 서비스를 제공합니다. 위 체크리스트처럼 org 상태를 살펴보고 개선 순서를 정하는 일은 운영 대행이 다루는 범위와 맞닿아 있습니다. 사내에 전담 인력이 없거나, 담당자가 바뀌면서 각 자동화가 왜 만들어졌는지 아는 사람이 없어졌다면 운영 파트너와 함께 점검 범위부터 정해 보는 것도 방법입니다.

운영 대행의 범위와 진행 방식은 세일즈포스 유지보수·운영 대행 안내에서, 파트너를 고를 때 확인할 기준은 세일즈포스 파트너 선택 가이드에서 자세히 보실 수 있습니다.

마무리

세일즈포스 운영 점검은 한 번 하고 끝나는 프로젝트가 아니라, org가 커지는 속도에 맞춰 반복하는 습관입니다. 특히 AI로 개발 속도가 빨라진 지금은 "기능이 맞는가"와 "한도 안에서 도는가"를 따로 확인하는 기준이 필요합니다. 우리 org에서 어디부터 봐야 할지 막막하다면, 데이터가 가장 많은 객체의 자동화부터 위 체크리스트로 점검해 보시길 권합니다.

자주 묻는 질문 (FAQ)

Q1. 세일즈포스 운영 점검은 얼마나 자주 해야 하나요?

분기 1회 정기 점검을 기본으로 하고, 대규모 데이터 이관·신규 시스템 연동·대형 릴리스 직전에 추가로 점검하는 것을 권합니다. 자동화와 코드가 자주 바뀌는 org일수록 주기를 짧게 가져가는 편이 안전합니다.

Q2. Salesforce Health Insights는 누구나 쓸 수 있나요?

세일즈포스 발표 기준으로 Winter '27 릴리스부터 Signature Success Plan 고객의 Core 제품에 추가 비용 없이 제공됩니다. App Launcher에서 "Salesforce Health Insights"를 검색해 실행합니다. 해당 플랜이 아니라면 같은 항목을 수동 점검이나 파트너 점검으로 확인해야 합니다.

Q3. 거버너 한도(Governor Limit)란 무엇인가요?

여러 기업이 같은 플랫폼 자원을 나눠 쓰는 세일즈포스에서, 한 트랜잭션이 쓸 수 있는 조회 수·DML 수·CPU 시간 등을 제한하는 상한선입니다. 예를 들어 동기 트랜잭션에서 SOQL 조회는 100회, CPU 시간은 10,000ms가 한도이며, 넘으면 트랜잭션 전체가 실패하고 변경 사항이 되돌려집니다.

Q4. Flow와 Apex 중 무엇으로 자동화해야 하나요?

같은 레코드의 필드만 바꾸는 단순 자동화는 저장 전(before-save) Flow가 빠르고 관리하기 쉽습니다. 대량 처리·복잡한 계산·외부 연동이 많은 로직은 Apex가 유리할 수 있습니다. 중요한 것은 도구 선택보다, 같은 트랜잭션을 공유하는 자동화 전체가 한도 안에서 도는지 확인하는 것입니다.