글로벌 패션 리테일러를 위한 90일 Salesforce 정상화

상황

연 매출 8억 유로 규모의 글로벌 패션 리테일러가 18개월째 Salesforce Sales Cloud 배포를 시도하고 있었습니다. 원래 오픈 예정일은 14개월 전이었습니다. 프로젝트는 당초 90만 유로 예산에 맞서 240만 유로의 SI 비용을 소진했습니다. 현 구축 파트너는 원래 계약 금액보다 40% 더 많은 금액을 ‘범위 변경’ 비용으로 청구했으나, 딜리버리는 여전히 미완이었습니다.

비즈니스는 상당한 운영 타격 아래 돌아가고 있었습니다. 영업팀은 Excel로 파이프라인을 관리했습니다. Salesforce 배포가 신뢰받지 못했기 때문입니다. 데이터 오류가 너무 많고, 성능 문제가 너무 많았습니다. 경영진은 프로젝트와 구축 파트너 양쪽에 대한 신뢰를 잃었습니다. Salesforce 투자가 이사회 수준에서 의심받고 있었습니다.

SI와의 관계는 완전히 무너졌습니다. SI의 어카운트 매니지먼트로의 에스컬레이션은 SLA와 사과를 낳았을 뿐 딜리버리는 없었습니다. 고객사는 SI에 법적 통지를 보냈습니다. 프로젝트는 기술 프로젝트에서 법적 분쟁으로 넘어갔고, SI는 딜리버리보다 자기 입지를 지키는 데 몰두했습니다.

고객사에 필요한 것은 피해를 평가하고, 무엇을 구제할 수 있는지 판단하며, 새로 부임한 CFO가 정한 빠듯한 90일 마감에 맞춰 남은 요구사항을 딜리버리할 독립 아키텍트였습니다.

과제

첫 2주는 전적으로 진단이었습니다. 전체 그림이 분명해지기 전까지 조직이나 프로젝트 계획에 어떤 변경도 가하지 않았습니다.

기술 진단은 원래 요구사항 명세에 맞서 현 조직 상태를 문서화했습니다. 원래 범위의 87개 기능 요구사항 중 34개는 완전히 딜리버리됐고, 28개는 부분적으로(작동하지만 미완), 25개는 시작되지 않았습니다. ‘완전히 딜리버리된’ 34개에는 SI가 ‘백로그 항목’으로 기록한 알려진 결함과 함께 딜리버리된 11개가 포함돼 있었습니다. 사실상 서류상으로는 딜리버리됐으나 실제로는 망가진 것들이었습니다.

데이터 모델에는 근본적인 아키텍처 문제가 있었습니다. 계정 계층이 고객사의 B2B 도매 구조에 맞지 않게 모델링되어, 다지역 계정 소유를 막는 제약을 만들었습니다. 리드 전환 프로세스는 전환할 때마다 데이터 무결성 문제를 일으키는 방식으로 커스터마이징되어 있었습니다. Record-Triggered Flow가 governor limit을 고려하지 않고 작성되어 대량 작업 실패를 일으켰습니다. 테스트 커버리지는 42%로, Salesforce가 요구하는 75%와 프로덕션 워크로드가 요구하는 80%를 한참 밑돌았습니다.

프로세스와 거버넌스의 그림도 기술적 그림과 일치했습니다. 제대로 된 변경 통제가 없었습니다. 요구사항 변경은 SI 프로젝트 매니저와 구두로 합의됐고, 공식적으로 문서화된 적이 없으며, 고객사와 SI가 종종 다르게 해석했습니다. ‘범위 변경’ 비용은 어떤 경우에는 정당한 추가 작업이었고 다른 경우에는 SI의 실수였으나, 공식 변경 지시서가 없으니 판가름할 방법이 없었습니다. UAT 프로세스도 없었습니다. 고객사는 SI가 진행한 데모를 근거로, 서면 테스트 케이스에 맞춘 체계적 사용자 인수 테스트 없이 산출물을 인수했습니다. 사용자는 각 릴리스 이후까지 어떤 테스트에도 참여하지 않았고, 이는 결함이 테스트가 아니라 프로덕션에서 발견됐다는 뜻이었습니다.

부분적으로 딜리버리된 28개 중 19개는 표적 개발로 완료할 수 있었습니다. 나머지 9개는 아키텍처적으로 잘못된 접근으로 만들어져 재구축해야 했습니다. 시작되지 않은 25개는 적합한 팀과 방법론이 있다면 모두 90일 안에 실현 가능했습니다. 데이터 모델 문제는 아키텍처 수정이 먼저 필요했습니다. 그렇지 않으면 새 요구사항이 무너진 기반 위에 올라갔을 것이고, 정상화는 원래와 같은 방식으로 실패했을 것입니다.

진단 단계를 마치며 CFO에게 한 말

무너진 계정 계층 위에서 87개 요구사항을 딜리버리할 수는 없습니다. 아키텍처 복구에 2주, 전부 딜리버리하는 데 8주. 그것이 버티는 유일한 길입니다.

실행

모든 요구사항에 비즈니스 책임자가 작성하고 개발 착수 전에 서명한 서면 인수 기준 문서가 있었습니다. 완료된 모든 항목은 완료로 표시되기 전에 그 기준에 맞춰 비즈니스가 테스트했습니다. 그것이 원래 SI가 고객사는 인수하지 않은 요구사항을 딜리버리됐다고 주장하게 만든 모호함을 제거했습니다.

성과

87개 요구사항 전부가 90일 안에 프로덕션 딜리버리됐습니다. 프로젝트 시작 시점에 한 번도 시작되지 않았던 25개를 포함해서 말입니다. 영업팀은 오픈 후 3주 안에 Excel에서 Salesforce로 완전히 이전했고, 프로덕션 운영 첫 30일 동안 치명적 장애는 없었습니다.

아키텍처 기반(재구축된 계정 계층, 깨끗한 데이터 모델, governor limit에 안전한 자동화, 84% 테스트 커버리지)은 비즈니스에 우회해야 할 플랫폼이 아니라 그 위에 쌓을 수 있는 플랫폼을 주었습니다. 리포팅 계층은 영업팀이 입력하는 것과 같은 모델 위에서 돌았습니다. CFO가 분기 리뷰에 필요로 한 파이프라인 지표가 2년 만에 처음으로 존재했습니다.

CFO 마감은 지켜졌습니다. 원래 SI와의 법적 분쟁은 고객사에 유리한 조건으로 해결됐습니다. 기술 진단 문서는 무엇이 딜리버리됐고 안 됐는지에 대한 객관적 기록을 제공했고, 이는 합의 협상에서 고객사의 입지를 강화했습니다.

더 중요하게는, 조직이 플랫폼으로서의 Salesforce에 대한 신뢰를 되찾았습니다. 18개월의 정체는 Salesforce가 이 비즈니스에 통할 수 있는지에 대해 이사회 수준에서 진짜 회의를 낳았습니다. Service Cloud, 나아가 Data Cloud로 확장하는 로드맵을 갖춘, 작동하고 도입된 배포가 그 신뢰를 재건했습니다.

돌아보며

이 패턴은 실패 방식이 아키텍처적이고 절차적일 때, 리더십이 진단은 변경에 선행해야 한다는 것을 받아들일 때, 그리고 비즈니스 책임자가 서면 인수 기준에 기꺼이 서명할 때 통합니다. 정체된 프로그램이 빠듯한 마감에 다가서고 원래 SI 관계가 무너졌을 때라면 언제든 옳은 선택입니다. 깨끗한 기반 위에서의 정상화는 처음부터 다시 시작하는 것보다 싸고 빠릅니다.

이전 구축이 구조적 임계점을 넘었을 때는 덜 통합니다. 예컨대 데이터 모델이 너무 심하게 커스터마이징되어 마이그레이션 비용이 재구축 비용을 넘을 때, 또는 조직의 커스터마이징이 너무 오래 문서화되지 않아 진단 자체가 수개월짜리 프로젝트가 될 때입니다. 그 지점에서는 통제된 재시작이 정직한 답입니다.

더 일찍 했어야 할 일은 서면 인수 기준입니다. 이 프로젝트가 복구한 실패 방식을 가장 일관되게 막아주는 단 하나의 변경은, 개발 착수 전에 모든 요구사항이 비즈니스 책임자가 서명한 ‘완료’ 정의를 갖도록 강제하는 것입니다. 그 변경은 비용이 들지 않고, 고객사의 권한 안에 있으며, 원래 18개월을 소진한 범위 분쟁의 적어도 절반은 막았을 것입니다.