어려움에 빠진 Salesforce 프로젝트가 우연히 무너지는 경우는 드뭅니다. 불만 뒤에는 대개 같은 조건이 있습니다. 원래 설계에서 벗어난 데이터 모델, 여러 팀이 실행 순서 합의 없이 쌓아 올린 자동화, 어느새 운영 환경 수동 변경으로 흘러간 배포 경로입니다. 단계마다 결정 책임자와 종료 산출물을 정한 게이트 방식으로 진행하면 90일 안에 통제력을 되찾을 수 있습니다. 이 순서를 건너뛴 복구 시도는 증상만 고치고 원인은 그대로 둡니다.
불만은 원인을 가립니다
스폰서는 눈에 보인 현상을 말합니다. 지난 릴리스가 운영 환경을 망가뜨렸다, 구축사가 연락이 없다, 영업팀이 다시 엑셀로 돌아갔다는 식입니다. 정작 물어야 할 질문은 한 번의 사건이 왜 이렇게 큰 피해를 냈느냐입니다. 답은 대개 아무도 보지 못한 곳에 쌓인 위험이고, org의 현재 모습을 파악한 사람이 없었다는 데서 비롯됩니다.
그래서 정상화는 수정부터 시작하지 않습니다. 첫 주부터 개발에 들어간 팀은 읽어 보지도 않은 기반 위에 쌓아 올리고, 배포하는 변경 하나하나가 줄여야 할 불확실성을 오히려 키웁니다. 세 가지 조건은 함께 다뤄야 합니다. 데이터 모델이 망가진 채로 자동화를 고치면 장애 지점이 다른 곳으로 옮겨갈 뿐입니다.
책임자가 정해진 세 개의 게이트
각 단계는 의존 관계를 따릅니다. 데이터 모델을 모르면 자동화를 안정시킬 수 없고, 자동화가 안정되기 전에는 배포 신뢰를 회복할 수 없습니다.
| 게이트 | 기간 | 핵심 결정 | 결정 책임자 | 종료 산출물 |
|---|---|---|---|---|
| 1. 급한 불 끄기 | 1-30일 | 신규 설정 동결 | 스폰서 | 메타데이터·자동화 인벤토리 |
| 2. 안정화 | 31-60일 | 객체별로 남길 자동화 선택 | 프로세스 오너와 설계 결정권자 | 충돌 없는 자동화, 작동하는 배포 경로 |
| 3. 신뢰 회복과 인계 | 61-90일 | 통제된 릴리스별 진행 여부(Go/No-go) | 릴리스 오너 | 현행 상태 문서, 자동화 인벤토리, 데이터 사전 |
게이트 1: 급한 불 끄기
손대기 전에 먼저 읽습니다. org 메타데이터 전체를 추출하고, 활성 Flow, Apex 트리거, 남아 있는 Process Builder를 각각이 건드리는 객체와 대조해 지도로 만듭니다. 그다음 디버그 로그를 보고 어느 자동화가 실제 운영 환경에서 실행되는지 확인합니다. 데이터 모델에서는 깨진 참조를 점검합니다. 더 이상 존재하지 않는 Record Type을 가리키는 lookup, 서로 모순되는 유효성 검사 규칙, 아무도 채우지 않는 필드가 대상입니다.
봉쇄 조치는 신규 설정 동결입니다. 작은 변경 위원회가 검토한 서면 영향 평가 없이는 어떤 변경도 운영 환경에 올라가지 않습니다. 동결은 정치적인 결정이므로 스폰서가 책임지고 직접 공지합니다. 복구 팀 혼자서는 동결을 강제할 수 없습니다.
게이트 2: 안정화
무엇을 개선하기 전에 충돌부터 해소합니다. 가장 위험한 패턴은 같은 객체에서 서로 경쟁하는 자동화입니다. 같은 저장 시점에 Opportunity Stage를 업데이트하는 Flow 두 개가 정해진 순서 없이 돌면 경쟁 상태가 생기고, 결과는 어느 쪽이 마지막에 실행되느냐에 따라 달라집니다. 사용자는 간헐적인 버그라고 보고하지만 디버깅을 더 해도 끝나지 않습니다. 이 동작이 설계 자체에 들어 있기 때문입니다.
해법은 객체와 트리거 이벤트마다 자동화 진입점을 하나로 두는 것입니다. 어떤 로직을 남길지는 업무 결정이므로 프로세스 오너가 설계 결정권자와 함께 정하고, 그 결정을 문서로 남깁니다.
데이터 모델 수리는 병행하되 순서를 정해 둡니다. 이해관계자가 직접 보는 리포트를 깨뜨리는 관계를 먼저 고치고, 다음이 필드 수준 문제, 마지막이 유효성 검사 로직입니다. 이 게이트에서 배포 경로도 마련합니다. 운영 환경을 반영하는 샌드박스를 두고, org에 무엇이 들어 있어야 하는지는 버전 관리를 기준으로 삼습니다.
게이트 3: 배포 신뢰 회복과 문서 인계
안정화가 유지되는지 증명합니다. 범위가 제한된 실제 변경 하나를 골라 전체 경로(샌드박스, 검증, 롤백 계획을 갖춘 운영 릴리스)를 거치게 하고 결과를 기록합니다. 복잡도를 조금씩 높여 세 번 반복합니다. 세 번째 주기가 끝나면 팀은 경로가 작동한다는 사실을 보여 주었고, 그 경로를 쓰는 습관도 생깁니다.
거버넌스는 작게 유지합니다. 의사결정 기록, 어떤 객체와 자동화를 누가 책임지는지 적은 메타데이터 오너십 매트릭스, 월 1회 검토면 충분합니다. 문서를 고객사 쪽 지정 책임자에게 넘기면 이 게이트가 닫힙니다.
복구 시도가 흔히 놓치는 것
범위 확대. org가 다시 돌아가기 시작하면 현업은 새 기능을 요구합니다. 성과를 보여 주고 싶은 복구 팀은 다시 개발을 시작하고, 구조적인 문제는 그대로 남습니다. 대응책은 명시적인 범위 게이트입니다. 게이트 1과 2는 복구 전용입니다. 게이트 3에는 눈에 띄는 변경을 한두 개 넣을 수 있는데, 업무 가치보다 새 배포 경로를 실제로 써 보게 한다는 이유로 고릅니다. 이 원칙을 현업에 말하는 사람은 스폰서입니다.
게이트 대신 날짜. 90일은 계획을 위한 기간입니다. 게이트 1에서 데이터 모델 손상이 예상보다 깊게 드러나면 게이트 2를 늘립니다. 날짜를 맞추려고 작업을 압축하면 겉으로는 안정적이지만 부하가 걸리면 다시 무너지는 org가 남습니다.
뒤로 미룬 문서화. 어려움에 빠진 프로젝트에는 거의 언제나 문서가 없습니다. 현행 상태 문서와 자동화 인벤토리 없이 떠나는 팀은 다음 팀에게 같은 숨은 위험을 물려주고, 같은 주기가 되풀이됩니다. 이 문서는 첫날부터 계획에 종료 산출물로 넣어 둡니다.
진척을 측정하는 방법
“org가 나아진 것 같다”는 측정값이 아닙니다. 게이트마다 운영 지표가 필요합니다.
- 게이트 1 종료: 메타데이터 인벤토리가 완성되어 있고, 모든 활성 자동화의 실행 순서가 문서화되어 있으며, 마지막 2주 동안 계획에 없던 운영 변경이 한 건도 없습니다.
- 게이트 2 종료: 알려진 자동화 충돌이 남아 있지 않고, 배포 경로가 수동 단계 없이 처음부터 끝까지 실행되며, 범위 안의 모든 객체에서 깨진 참조가 해소되었습니다.
- 게이트 3 종료: 통제된 릴리스를 세 번 마쳤고, 기록된 의사결정이 두 건 이상이며, 짧은 이해관계자 설문 결과가 첫 주에 잡은 기준선보다 나아졌습니다.
이 지표는 의도적으로 운영 중심입니다. 업무 성과가 드러나려면 90일보다 오래 걸립니다. 이 단계에서 측정하는 대상은 안정적인 딜리버리의 조건이 돌아왔는지입니다. 진단 자체는 org 리뷰 체크리스트에서, 버전 관리에 먼저 넣을 대상은 기술 부채 노트에서 다룹니다.
확인할 항목
- 변경 동결에 책임자가 있고, 스폰서가 직접 공지했습니다.
- 모든 객체에 트리거 이벤트별 자동화 진입점이 하나씩만 있습니다.
- 팀이 운영 환경 수동 작업 없이 변경을 처음부터 끝까지 배포할 수 있습니다.
- 현행 상태 문서와 자동화 인벤토리가 산출물로 계획에 들어 있고, 인계 후 책임자도 지정되어 있습니다.