많은 org 리뷰가 아무도 실행하지 않는 보고서로 끝나고, 여섯 달 뒤 같은 문제가 운영 장애로 돌아옵니다. 비용을 들일 가치가 있는 리뷰는 더 좁은 일을 합니다. 다음 단계(두 번째 클라우드 도입, 마이그레이션, 인수합병)에서 장애를 일으킬 결정을 찾아내고, 누군가 조치할 수 있도록 순위를 매깁니다. 이 체크리스트는 리뷰를 발주하고 결과를 직접 읽어야 하는 스폰서를 위해 정리했습니다.
도구는 임계값을 측정합니다
헬스 체크 도구는 임계값을 측정합니다. API 한도, 스토리지, 관리자 권한이 남아 있는 비활성 사용자 같은 항목입니다. 이런 발견 사항은 중요하고 대개 고치는 비용도 적습니다. 하지만 부하가 걸려야 드러나는 설계 선택은 보여 주지 못합니다. 데이터가 이미 있다는 이유로 새 기능을 계속 Account에 얹는 결정, 공통 설계 없이 여러 팀이 만든 자동화, 아무도 설명하지 못하는 연동이 그렇습니다.
모든 임계값을 통과한 org도 프로젝트 하나만 더 얹으면 문제가 터질 수 있습니다. 그래서 리뷰는 설정을 읽는 동시에 그 설정을 바꾼 사람을 인터뷰합니다. 누가, 언제, 왜 결정했는지 묻습니다. 자동화는 개수를 세기보다 의존성 지도(각 Flow, 트리거, 연동이 무엇을 읽고 쓰고 호출하는지)를 요구해야 합니다. 서로 얽힌 Flow 몇 개가 독립적인 Flow 여러 개보다 바꾸기 어려울 수 있습니다.
읽어야 할 다섯 영역
1. 데이터 모델
관계와 카디널리티, 핵심 객체(Account, Contact, Opportunity)의 필드 증가, 표준 객체와 중복되는 커스텀 객체(표준 Contract 옆에 따로 만든 커스텀 계약 객체 같은 경우), 그리고 모델이 실제 업무를 반영하는지 과거 프로젝트 이력을 반영하는지 살펴봅니다.
대표적인 장애 유형은 객체 과적입니다. 영업, 서비스, 재무, 마케팅 필드가 구분 없이 Account에 쌓이면 권한이 얽히고, 리포트 해석이 모호해지고, 자동화가 충돌합니다. 그때는 설정 변경으로는 부족하고 데이터 마이그레이션이 필요해집니다. 연동에 쓰이는 객체에 External ID 필드가 있는지도 확인합니다. Salesforce 레코드 ID를 연동 키로 쓰는 연동은 데이터를 다시 적재하거나 다른 org로 옮기는 순간 깨집니다.
2. 자동화
Process Builder나 Workflow Rules가 아직 업무 로직을 처리한다면 그 자체가 발견 사항입니다. Salesforce는 두 도구의 지원을 종료하고 Flow로 옮기도록 안내하며, 이 전환은 단순 변환으로 끝나지 않는 재설계 작업입니다.
더 큰 질문은 일관성입니다. 서로 다른 사람이 실행 순서를 문서화하지 않은 채 같은 객체 트리거에 Flow를 여러 개 만들면, 결과는 어느 Flow가 마지막에 실행되느냐에 따라 달라집니다. 종료 조건 없는 재귀 트리거, 루프 안의 데이터베이스 업데이트, 이미 Apex가 처리하는 로직을 중복한 Flow를 확인합니다. 마지막 경우는 인력 교체 뒤에 흔히 생깁니다. Apex 클래스가 있다는 사실을 아무도 알려 주지 않아 누군가 Flow를 새로 만드는 식입니다.
3. 연동
문서화되지 않은 것까지 포함해 org에 닿는 모든 외부 시스템을 지도로 만듭니다. Connected Apps, Named Credentials, External Services를 실제 API 사용량과 대조합니다. 연결마다 책임자, 인증 방식, 데이터량, 오류 처리 방식을 기록합니다.
특히 두 가지를 봐야 합니다. 아무도 설명하지 못하지만 여전히 돌면서 API 호출을 소비하는 연동은 보안 노출면이자 한도 소모 요인입니다. 특정 개인의 인증 정보로 도는 연동은 그 사람의 계정에 묶여 있고, 그 사람이 떠날 때 어떻게 할지 아무도 정하지 않았습니다. 미들웨어 계층이 필요한지는 시스템 수와 변환 로직에 따라 달라집니다. 리뷰는 답을 전제하지 말고 그 결정과 책임자를 기록해야 합니다.
4. 보안과 접근 권한
접근 모델에는 눈에 보이지 않는 부채가 쌓입니다. 권한이 넓은 소수의 프로필 위에 아무도 검토하지 않은 Permission Set(권한 집합)이 계속 늘어납니다. System Administrator 프로필 사용자를 세어 보고, 각 사용자가 왜 그 프로필을 쓰는지 물어야 합니다. Organization-Wide Defaults(조직 전체 기본값)와 공유 규칙을 실제 업무 요구와 비교합니다. 열린 모델을 나중에 조이는 작업은 고통스럽고, 제한적인 모델을 여는 작업은 쉽습니다. Permission Set 할당이 사용자 수보다 빠르게 늘어난다면 접근 모델이 표류한다는 신호입니다.
에이전트 도입을 계획한다면 같은 질문을 에이전트가 호출할 수 있는 모든 액션으로 넓힙니다. 그 액션이 누구의 권한으로 실행되는지, 그 범위를 누가 승인했는지 확인합니다.
5. 배포 규율
변경이 운영 환경에 도달하는 방식은 org 안에 무엇이 있는지만큼 많은 것을 알려 줍니다. 버전 관리가 기준 상태를 담고 있는지, 최종 검증용 샌드박스가 운영 환경을 반영하는지, 릴리스 전에 변경을 검토하는지, 릴리스마다 롤백 계획이 있는지 확인합니다. 샌드박스와 운영 환경이 서로 달라 어느 쪽이 기준인지 아무도 모르는 상태가 일상적인 릴리스를 긴 롤백으로 바꿉니다. 팀에게 기준 환경이 어디인지 물으면 됩니다. 망설인다면 그것도 발견 사항입니다.
영향 범위와 조치 난이도로 순위 매기기
발견 사항 목록은 계획이 아닙니다. 각 항목을 두 축으로 평가합니다. 영향 범위는 장애가 났을 때 영향을 받는 사용자, 레코드, 후속 시스템의 규모와 그 조건이 얼마나 자주 생기는지입니다. Account가 업데이트될 때마다 실행되는 로직 오류는 1년에 두 번 쓰는 객체의 설정 오류보다 앞섭니다. 조치 난이도는 수정이 얼마나 어려운지입니다.
| 난이도 낮음 | 난이도 높음 | |
|---|---|---|
| 영향 범위 넓음 | 즉시 수정: 보안 설정 오류, 집중 작업으로 옮길 수 있는 지원 종료 자동화 | 별도 예산과 단계를 갖춘 프로그램 차원의 과제: 데이터 모델 재구성, 연동 재설계 |
| 영향 범위 좁음 | 기술 부채 백로그로 꾸준히 처리: 필드 정리, 비활성 자동화, 할당되지 않은 Permission Set | 새 연동이나 두 번째 클라우드처럼 위험을 키우는 계기가 생길 때까지 보류 |
어느 칸에 예산을 배정하느냐에 따라, 다음 대형 프로그램이 깨끗한 기반에서 출발할지 아무도 다시 열고 싶어 하지 않는 과거 결정을 끌고 갈지가 갈립니다. 백로그 운영 방법은 기술 부채 노트에서 다룹니다. org가 이미 어려운 상황이라면 프로젝트 정상화부터 보는 편이 맞습니다.
확인할 항목
- 리뷰가 배포 규율을 포함한 다섯 영역을 모두 다룹니다.
- 도구 출력만이 아니라 org를 변경한 사람을 인터뷰한 내용이 포함되어 있습니다.
- 핵심 객체의 자동화에 의존성 지도가 붙어 있습니다.
- 모든 발견 사항에 영향 범위, 조치 난이도, 지정된 책임자가 있습니다.
- 주요 발견 사항이 한 페이지에 들어가고, 그 페이지만 보고 어디에 예산을 쓸지 정할 수 있습니다.