모든 Salesforce org에는 기술 부채가 있고, 부채 0을 목표로 삼으면 부채 자체보다 나쁜 결정을 내리게 됩니다. 물어야 할 질문은 어떤 부채를 지금 고치고, 어떤 부채를 알려진 촉발 요인에 맞춰 계획하고, 어떤 부채를 그대로 둘지입니다. 이 판단은 거버넌스 결정입니다. 플랫폼 책임자가 결정하고, 항목마다 이름을 붙여 기록하고, 분기마다 다시 검토합니다.
안정된 부채와 불어나는 부채
부채는 부주의보다 구조 때문에 쌓입니다. 요구 사항은 설계가 소화하는 속도보다 빨리 들어오고, 선언형 도구 덕분에 더 많은 사람이 더 적은 통제 아래서 만들며, 합병과 플랫폼 확장은 설정 위에 설정을 쌓습니다.
각 항목이 안정된 부채인지 불어나는 부채인지가 중요합니다. 아무도 건드리지 않는 오래된 유효성 규칙이 여전히 쓰이는 필드와 레코드 유형에 걸려 있다면 안정된 부채입니다. 유지 비용이 거의 없습니다. 반면 Opportunity가 수정될 때마다 실행되고, 이제는 오류를 돌려주는 엔드포인트를 호출하며, 아무 알림 없이 실패하는 Flow는 불어나는 부채입니다. 실행될 때마다 데이터를 망가뜨리고 연동 장애를 가립니다. 둘을 똑같이 다루면 앞의 부채에 노력을 낭비하거나 뒤의 부채를 키우게 됩니다.
복잡하다고 모두 부채는 아닙니다. 복잡한 업무 프로세스를 처리하는 복잡한 Flow는 올바른 설계입니다. 부채는 지름길 때문에 생긴 복잡성입니다. 간단한 Flow로 할 수 있는 일을 하는 긴 Apex 클래스는 부채이고, Flow로는 효율적으로 처리할 수 없는 대량 작업을 맡은 긴 Apex 클래스는 부채가 아닙니다. 뚜렷한 이득 없이 잘 돌아가는 로직을 리팩터링하면 위험을 줄인다면서 버그를 더하게 됩니다.
세 등급: 고치기, 계획하기, 감수하기
나이가 아니라 영향 범위와 추세로 분류합니다.
| 등급 | 정의 | 예시 | 결정 |
|---|---|---|---|
| 활성 위험 | 지금 데이터를 훼손하거나, 업그레이드를 막거나, 규제 노출을 만드는 부채 | 처리되지 않은 fault path 때문에 오류를 삼키는 Flow, 공유 규칙을 우회하는 커스텀 코드 | 수정, 기한은 주 단위 |
| 잠재 위험 | 지금은 안정적이지만 예측 가능한 촉발 요인이 오면 활성화되는 부채 | 대량 처리를 고려하지 않아 현재 데이터량에서만 버티는 트리거, 샌드박스 새로 고침 후 깨지는 하드코딩된 Record Type ID | 계획, 촉발 요인에 맞춘 일정 |
| 비활성 | 쓰이지 않고, 아무도 건드리지 않으며, 해가 없는 부채 | 어디에서도 참조하지 않는 필드, 할당된 사용자가 없는 Permission Set, 아무도 열지 않는 리포트 폴더 | 감수, 릴리스 창에서 정리 |
비활성 항목이 길게 늘어서 있어도 활성 위험이 없는 org가, 항목은 적지만 그중 세 개가 활성 위험인 org보다 상태가 좋습니다. “쓰이지 않는” 항목을 지우기 전에는 의존성을 확인해야 합니다. 필드 하나가 여전히 유효성 규칙, Flow, 공유 리포트에서 참조될 수 있습니다.
플랫폼이 바뀌면 등급도 움직입니다. Data Cloud나 Agentforce를 도입하면 기존 부채의 등급이 다시 매겨집니다. 고객 식별 매칭은 일관된 필드에 기대므로, 단독 CRM에서는 비활성이던 제각각의 전화번호 형식이 누군가 그 필드를 매칭에 쓰는 날부터 잠재 위험이 됩니다. 중복 Account, 고아 Contact, 한 번도 종결 처리되지 않은 Opportunity가 섞인 CRM 데이터를 근거로 답하는 에이전트는 그 불일치를 답변에서 그대로 되풀이하고, 프롬프트를 고쳐도 해결되지 않습니다. 확장 전에 등급을 다시 매겨야 합니다. 잠재 부채는 프로젝트 도중보다 계획된 정리 주기에 치우는 편이 쌉니다.
표준 상태 점검이 놓치는 영역
표준 상태 점검(health check)은 보안을 검토하고, 쓰이지 않는 필드를 세고, 결과를 범주별로 정리합니다. 스캐너는 설명이 없는 Flow와 fault path가 처리되지 않은 Flow를 나란히 보여 줍니다. 앞의 Flow는 비활성이고, 뒤의 Flow는 활성 위험일 수 있습니다. 도구는 발견까지만 합니다. 등급을 매기려면 판단이 필요하고, 통상적인 점검이 건너뛰는 네 개 층을 봐야 합니다.
- 자동화. 실행 경로, 재귀, 실행 순서 충돌, 평상시 부하에서의 governor limit 노출을 봅니다. Flow가 많다는 사실 자체는 위험이 아닙니다. 같은 수정에 함께 실행되며 서로를 호출하는 몇 개의 Flow가 위험입니다.
- 연동 구조. 예약 작업과 미들웨어를 포함해 org를 읽거나 쓰는 모든 시스템을 봅니다. 필드 API 이름, 선택 목록, 오브젝트 관계가 바뀌면 어떤 외부 시스템이 깨지는지가 핵심 질문입니다.
- 데이터 모델. 업무 현실과 더 이상 맞지 않는 스키마를 봅니다. 여러 실체를 한 오브젝트에 담느라 레코드 유형이 많아진 오브젝트, 순환 조회 관계가 그 예입니다. 비용은 다음 마이그레이션이나 합병 때 드러납니다.
- 거버넌스 공백. 누가 배포할 수 있는지, 코드 리뷰가 있는지, 명명 규칙이 있는지, 스키마 변경에 영향도 분석이 필요한지를 봅니다. 이 공백은 첫날에는 아무것도 망가뜨리지 않습니다. 대신 팀과 팀 사이에서 부채가 불어나게 둡니다.
정비 순서
- 안정화. 프로덕션에서 실패하는 자동화, governor limit에 가까운 프로세스, 오류 처리가 없는 자동화를 먼저 고칩니다.
- 지원 종료 대응. Salesforce가 폐지를 발표한 기능, 예를 들어 Workflow Rules와 Process Builder에서 벗어나 대체 기능인 Flow로 옮깁니다. 기한은 조직이 아니라 Salesforce가 정합니다. 가장 복잡한 전환부터 시작합니다. 예상보다 오래 걸리기 때문입니다.
- 리팩터링. 강하게 결합된 연동을 분리하고, 데이터 모델을 단순하게 만들고, 새 부채를 막는 통제를 더합니다. 끝나는 날짜가 있는 프로젝트가 아니라 분기마다 역량을 떼어 두는 상시 활동입니다.
세 단계를 동시에 진행하면 팀이 감당할 수 있는 수준을 넘는 변경이 생깁니다. 정비는 사용자가 기능으로 여기게 된 동작, 버그까지 포함한 동작도 바꾸므로 단계마다 별도의 변경 관리가 필요합니다.
책임자와 분기 검토가 있는 결정
활성 위험 부채가 다시 쌓이지 않게 하는 통제는 세 가지입니다.
- 지명된 책임자. 모든 Flow, Apex 클래스, 연동 설정에 상태를 책임지는 담당자를 둡니다. 담당은 개인이 아니라 역할(“Service Cloud 자동화 책임자”)에 연결해, 사람이 바뀌어도 책임이 이어지게 합니다.
- 배포 관문. 프로덕션 전에 자동 점검을 돌립니다. Flow의 fault path, 팀이 정하고 강제하는 테스트 커버리지 기준, 하드코딩된 ID가 없는지를 확인합니다.
- 분기별 부채 검토. 플랫폼 책임자가 새 연동, 새 데이터 소스, 새 에이전트 액션처럼 바뀐 부분을 보고 목록의 등급을 다시 매기는 짧은 회의입니다. 결과물은 항목마다 책임자와 날짜가 붙은 수정 목록입니다.
플랫폼 책임자는 이 목록의 항목마다 수정, 계획, 감수 중 하나를 정해 서명합니다. 감수하기로 한 부채는 그때부터 이름과 날짜가 붙은 결정으로 남습니다. 규모가 큰 org에서 이 검토를 누가 맡는지는 Center of Excellence 노트에서 다룹니다.
확인할 항목
- 모든 활성 위험 항목에 책임자와 주 단위 기한이 있습니까?
- 모든 잠재 위험 항목이 이름 붙은 촉발 요인(데이터량, 확장, 샌드박스 새로 고침, 폐지 일정)에 연결되어 있습니까?
- 마지막 연동, 데이터 소스, 에이전트를 추가한 뒤 목록의 등급을 다시 매겼습니까?
- Workflow Rules나 Process Builder 프로세스가 아직 남아 있다면, Flow로 옮기는 날짜가 정해진 계획이 있습니까?
- 분기 목록에는 누가 서명하고, 어디에 보관합니까?