실패하는 Salesforce 구축이 한 번에 무너지는 경우는 드뭅니다. 하나씩 보면 합리적이던 결정이 쌓여 실패하고, 그 결정 대부분은 개발이 시작되기도 전인 첫 몇 주 안에 내려집니다. 플랫폼 자체가 원인인 경우도 드뭅니다. 피해는 검토 없이 자동화한 프로세스, 아무도 책임지지 않는 공유 데이터, 서둘러 만든 연동, 그리고 교육으로 해결할 수 있다고 여긴 낮은 사용자 정착에서 나옵니다.
분석 단계는 아무도 묻지 않은 것을 자동화합니다
요구사항 수집은 받아 적기로 끝나는 경우가 많습니다. 현업이 지금의 프로세스를 설명하면 컨설턴트가 사용자 스토리로 옮기고, 그 프로세스가 자동화할 가치가 있는지 물을 권한이 있는 사람은 아무도 없습니다. 그 결과 설정은 잘못된 프로세스를 아주 충실하게 재현합니다. 수작업 우회 방식을 그대로 옮긴 Flow, 조직도를 그대로 담은 객체 관계, 예외를 규칙처럼 강제하는 유효성 검사 규칙이 그렇습니다.
빠진 역할은 설계 결정권자, 즉 요구사항을 받아 적는 데 그치지 않고 거절할 권한까지 있는 사람입니다. 분석 단계를 분석가에게만 맡기고 설계 책임자가 범위 확정 뒤에 합류하면, 명세와 플랫폼이 감당할 수 있는 수준 사이의 간극은 이미 계획에 들어가 있습니다. 누군가 그 간극을 보게 되는 시점은 개발 단계입니다.
공유 객체에 책임자가 없습니다
Salesforce 표준 데이터 모델에는 Account, Contact, Opportunity가 어떻게 연결되는지에 관한 가정이 깔려 있습니다. 업무 방식이 다르면 반사적으로 사용자 정의를 택합니다. 커스텀 객체, 커스텀 관계, 정션 객체 위에 또 정션 객체를 얹는 식입니다. 누군가 그 결과를 모델링한다면 사용자 정의 자체는 문제가 되지 않습니다. 필드 단위로 그때그때 결정하면 이후의 모든 변경 비용이 올라갑니다. 연동, 리포트, 해당 레코드를 건드리는 모든 Flow가 영향을 받습니다.
거버넌스 공백은 이 표류를 가속합니다. 여러 팀이 조율 없이 배포하고, 샌드박스는 운영 데이터 규모를 반영하지 못하며, 릴리스끼리 서로 덮어쓰고, 모든 팀이 쓰는 객체에는 책임자가 없습니다. 영업팀은 자기 업무에 맞춰 Account를 바꾸고, 서비스팀은 또 자기 방식대로 바꾸며, 그 객체에는 아무도 설명하지 못하는 필드가 계속 쌓입니다.
해법은 위원회보다 오너십 모델에 가깝습니다. 공유 객체마다 지정된 책임자를 두고, 변경이 두 팀 이상에 영향을 주면 검토를 거치며, 데이터 모델을 설계 문서로 다룹니다. 설정을 시작하기 전에 검토하고, 표준 객체에서 벗어나는 결정은 모두 이유와 함께 기록합니다.
오지 않는 2단계
연동은 감당할 만한 실패가 값비싼 실패로 바뀌는 지점입니다. 첫 릴리스 때는 미들웨어 계층을 세우는 것보다 빠르다는 이유로 포인트 투 포인트 연결을 만들고, 미들웨어는 2단계로 넘어갑니다. 2단계는 좀처럼 오지 않습니다. org에는 ERP, 마케팅 플랫폼, 데이터 웨어하우스와 맺은 직접 연결이 쌓이고, 연결마다 인증 방식, 오류 처리, 재시도 로직이 제각각입니다.
연결 하나가 끊어져도 업무 프로세스가 멈추기 전까지는 아무 경고도 뜨지 않습니다. 관리자는 “데이터가 틀렸다”는 티켓을 받고 어느 연결이 원인인지 거꾸로 추적해야 합니다. 새 시스템을 하나 추가할 때마다 데이터를 공유하는 기존 연결을 모두 손봐야 하고, ERP 교체는 얽힌 연결을 푸는 프로젝트가 됩니다.
스폰서가 미들웨어 제품을 고를 필요는 없습니다. 첫 릴리스 전에 스폰서가 정할 일은 연동에 모니터링되는 계약 경계를 둘지, 그리고 각 연결과 인증 정보, 장애 알림을 누가 책임질지입니다. 날짜도 예산도 없는 2단계는 하지 않겠다는 결정이며, 그렇게 기록해야 합니다.
사용자 정착을 교육 문제로 볼 때
낮은 사용자 정착은 자주 잘못 진단됩니다. 흔한 대응은 교육 추가, 문서 보강, 경영진 메시지입니다. 저는 Salesforce를 가르칩니다. PLB에서는 관리자 과정과 Service Cloud 과정을, Capgemini에서는 AXA 대리점 팀 대상 도구 교육을 맡습니다. 교육장에는 분명한 한계가 있습니다. 시스템이 어떻게 작동하는지는 보여 줄 수 있지만, 아무도 책임지지 않는 프로세스를 따를 만한 프로세스로 바꿀 수는 없습니다.
사용자 정착 실패는 대개 설계에서 비롯됩니다. 요구사항을 실무자가 아닌 관리자에게서 받아 시스템이 실제 일하는 방식과 맞지 않는 경우가 있습니다. 데이터 모델이 무겁고 화면이 필드로 가득해 기존 우회 방식보다 느린 경우도 있습니다. 리포트용 데이터 수집을 중심으로 범위를 잡아 사용자에게 새로 주는 것이 없는 경우도 있습니다.
사용자 정착은 설계 제약 조건으로 다뤄야 합니다. 필수 필드 하나, 추가 화면 하나가 모두 마찰이며, 설계 단계에서 누군가는 그 마찰을 정당화하는 업무 성과가 무엇인지 물어야 합니다. 답이 “리포트에 필요하다”라면, 다음 질문은 사용자가 직접 입력하지 않고도 그 데이터를 확보할 방법이 있는지입니다.
처방보다 진단이 먼저입니다
이런 원인은 혼자 나타나는 경우가 드뭅니다. 데이터 모델 문제 옆에는 거버넌스 공백이 있고, 연동 문제는 사용자 정착 문제를 키웁니다. 늦게 오거나 틀린 데이터를 사용자가 더는 믿지 않기 때문입니다. 따라서 어려움에 빠진 프로그램의 첫 산출물은 잘못된 점을 모두 나열한 목록보다, 무엇을 막고 있는지를 기준으로 문제의 순위를 매긴 진단이어야 합니다.
이 진단에 드는 비용이 가장 적은 시점은 구축사를 고르기 전입니다. 2022년 Disneyland Paris에서 저는 구축사 선정 전에 B2B 프로세스를 감사하고 Salesforce 목표 모델을 작성했습니다. 덕분에 후보 구축사에게 개발 중에 범위를 찾아내게 하는 대신, 문서로 정리된 목표 모델을 기준으로 비교할 수 있었습니다.
이미 어려움에 빠진 프로그램에도 같은 분류가 적용됩니다. 먼저 다른 문제를 막고 있는 문제를 찾습니다. 리포트, 자동화, 연동이 모두 데이터 모델에 기대므로 그 문제는 데이터 모델인 경우가 많습니다. 나머지는 그 뒤에 순서대로 배치합니다. 읽어야 할 다섯 영역은 org 리뷰 체크리스트에, 복구 첫 90일은 프로젝트 정상화 노트에 정리했습니다.
확인할 항목
- 요구사항 분석 단계에 요구사항을 기록만 하지 않고 거절할 수 있는 설계 결정권자가 있습니다.
- Account와 Contact를 비롯한 모든 공유 객체에 지정된 책임자가 있습니다.
- 표준 객체에서 벗어난 모든 결정이 이유와 함께 기록되어 있습니다.
- 연동 “2단계”에 날짜, 예산, 책임자가 정해져 있습니다.
- 사용자 정착이 낮을 때, 교육을 더 잡기 전에 누군가 프로세스를 점검했습니다.