Salesforce 구축: 비용과 기간, 실패 패턴

Salesforce 구축은 라이선스 한 줄로 승인되고 하나의 대형 프로그램으로 납품됩니다. 라이선스 한 줄은 공개되어 있고, 사용자당 월 단위이며, 이사회 문서에서도 방어하기 쉽습니다. 그 라이선스를 누군가가 실제로 쓰는 시스템으로 바꾸는 모든 것은 그 줄 바깥에 있고, 사업계획서의 숫자가 첫 분기를 버티는지를 결정하는 것도 바로 그 바깥입니다.

Salesforce는 영국 가격을 파운드로 공개합니다. Sales Cloud Enterprise는 연간 청구 기준으로 사용자당 월 £140이고 Unlimited는 £280입니다. Enterprise 사용자 쉰 명이면 필드 하나 설정하기도 전에 연 £84,000입니다. 그 조직을 운영 환경에 올리는 서비스에 대한 저희 자체 추정치는 첫해 라이선스 지출의 1배에서 3배이며, 그 범위 안에서 어디에 놓이는지는 우연이 아닙니다. 이를 움직이는 요인은 네 가지이고, 그중 기술적인 것은 하나뿐입니다.

이어지는 글에서 가장 중요한 단어는 정착입니다. 기술적으로 정확하지만 아무도 쓰지 않는 시스템은 부분적인 성공이 아니기 때문입니다. 그것은 유지보수 청구서가 붙은 전손입니다.

Salesforce 구축에는 비용이 얼마나 듭니까? 라이선스는 보통 더 작은 쪽 절반입니다. Salesforce는 영국에서 Sales Cloud Enterprise를 사용자당 월 £140으로 제시하므로 사용자 쉰 명이면 연 £84,000이고, 그 위에 얹히는 구축 서비스에 대한 저희 자체 추정치는 첫해 라이선스 지출의 1배에서 3배입니다. 이 배수를 움직이는 것은 연동할 시스템의 수, 원본 데이터의 상태, 프로세스 커스터마이징의 정도, 그리고 조직이 제품에 맞춰 자기 프로세스를 바꿀 의사가 있는지입니다.

Salesforce 구축에 실제로 포함되는 것

Salesforce 프로그램에는 여섯 개의 비용 항목이 있고, 가격 페이지에 나오는 것은 그중 하나뿐입니다.

첫째는 라이선스로, 사용자당 월 단위의 공개 가격입니다. 둘째는 구축 서비스, 즉 조직을 설정하고 설정으로 안 되는 것을 만들고 프로젝트를 굴리는 컨설턴트와 개발자입니다. 셋째는 데이터 마이그레이션으로, 구축 안의 한 작업으로 산정되면서 실제로는 그 자체로 하나의 프로젝트처럼 움직입니다. 넷째는 연동, 즉 이미 데이터를 들고 있는 시스템에 Salesforce를 붙이는 일입니다. 다섯째는 교육과 변화 관리입니다. 여섯째는 지속적인 운영 관리인데, 이것은 사업계획서에 결코 등장하지 않습니다. 다른 모든 청구서가 지급된 뒤에 시작되기 때문입니다.

라이선스만 적은 사업계획서는 조금 틀린 것이 아닙니다. 흔히 두 배에서 네 배가 틀리며, 그 격차는 거의 전부 셋째, 다섯째, 여섯째 항목에 있습니다.

라이선스는 작은 쪽 숫자입니다

Salesforce의 영국 Sales Cloud 가격은 공개되어 있고 파운드로 표시됩니다.

Starter Suite는 사용자당 월 £20입니다. Pro Suite는 연간 청구 기준 £80입니다. 영국 중견 시장 구매자가 가장 자주 도달하는 Enterprise는 £140인데, 웹 API가 붙는 첫 등급이기 때문입니다. Unlimited는 £280이고 Full sandbox와 Premier Success Plan을 포함합니다. Agentforce 1 Sales는 £440입니다. 따로 구매하면 Premier Success Plan의 가격은 순 라이선스 비용의 30%입니다.

여기서 두 가지가 따라 나옵니다. Pro Suite에서 Enterprise로 올라가는 차이는 사용자당 월 £60이고 쉰 명이면 연 £36,000인데, 이 이동은 영업팀이 요청한 어떤 기능 때문이 아니라 연동 요구사항 하나 때문에 강제되는 경우가 많습니다. 그리고 지원 플랜은 비율이므로, 실제로 쓰는 지원의 양이 아니라 라이선스 청구액에 비례해 늘어납니다.

서비스와 라이선스의 비율, 그리고 그것을 움직이는 것

계획에 쓸 만한 숫자는 인일 단가가 아닙니다. 첫해 서비스 비용과 첫해 라이선스 지출의 비율입니다. 그 비율은 논쟁할 수 있을 만큼은 안정적이기 때문입니다.

영국 중견 시장 작업에서 얻은 저희 자체 구간은 다음과 같습니다. 데이터가 깨끗하고 연동이 없는, 거의 표준 그대로의 단일 클라우드 배포는 첫해 라이선스 지출의 대략 0.5배에서 1배에 놓입니다. 연동이 두세 개 있고 커스텀 오브젝트와 자동화가 적당히 있는 전형적인 구축은 1배에서 3배입니다. 레거시 데이터를 안고 연동이 다섯 개 이상이며 프로세스 커스터마이징이 무거운 멀티 클라우드 프로그램은 3배에서 5배로 가고, 때로는 그 위로도 갑니다. 이것은 공개된 수치가 아니라 저희 추정치이며, 업계 고정 비율을 제시하는 파트너에게는 그 출처를 물어야 합니다.

£84,000 예시에 대입하면 아래쪽은 £42,000, 중간은 £84,000에서 £252,000, 위쪽은 £252,000 이상입니다. 이 폭 자체가 이야기의 전부입니다. 대략 라이선스와 비슷하다는 말만 들은 구매자는, 양 끝이 열 배 차이 나는 범위의 한가운데에 닻을 내린 것입니다.

비율을 움직이는 네 가지 변수

Salesforce 프로젝트를 한 구간 위로 확실히 밀어 올리는 것은 네 가지뿐이며, 모든 범위 협의는 누군가 숫자를 내놓기 전에 이 넷을 확정해야 합니다.

첫째는 연동할 시스템의 수입니다. 하나가 늘 때마다 별도의 설계, 별도의 자격 증명, 별도의 오류 경로, 그리고 상대 벤더가 릴리스를 낼 때 깨지는 또 하나가 늘어납니다. 연동 비용은 덧셈이 아니라 덧셈보다 조금 더 나쁩니다. 실패 방식이 곱해지기 때문입니다.

둘째는 원본 시스템의 데이터 품질입니다. 양이 아닙니다. 품질입니다. 프로그램에서 가장 일관되게 과소평가되는 항목이므로 아래에서 자세히 다룹니다.

셋째는 프로세스 커스터마이징의 정도, 즉 목표 설계가 제품을 설치한 그대로의 모습에서 얼마나 멀어지는가입니다.

넷째는 조직이 제품에 맞춰 자기 프로세스를 바꿀 것인가입니다. 비용과 성패 모두에 대해 단독으로 가장 강한 예측 변수이지만, 이것을 범위에 넣는 사람은 거의 없습니다. 기술 평가 자리에서 던져지는, 사람에 관한 질문이기 때문입니다.

바꿀 의사는 범위 산정의 문제입니다

자기 영업 프로세스를 Salesforce의 기회 모델에 맞추는 조직은 저렴하고 업그레이드가 되며 지원이 잘 되는 시스템을 얻습니다. Salesforce가 기존 스프레드시트를 그대로 재현해야 한다고 고집하는 조직은 릴리스마다 싸우는 비싼 시스템을 얻습니다.

발굴 단계에서의 단서는 말투입니다. 이해관계자가 우리 일하는 방식대로 시스템이 돌아가야 한다고 말하면 커스터마이징 예산은 두 배가 되려는 참입니다. 원래 어떻게 돌아가야 하는지 보여주고 그 이유를 알려 달라고 말하면 예산은 절반이 되려는 참입니다. 두 문장 모두 합리적입니다. 싼 것은 한쪽뿐입니다.

이것을 정직하게 다루는 방법은 값을 매기는 것입니다. 제안서에 숫자를 두 개 넣으십시오. 하나는 표준 모델, 하나는 맞춤 제작이고, 차액이 논증을 대신하게 하십시오. 단계 명명 규칙 하나가 커스텀 자동화와 영구적인 업그레이드 위험으로 £18,000이 든다는 것을 본 구매자는 대개 명명 규칙 쪽을 바꿉니다. 그거 됩니다라는 말만 들은 구매자는 바꾸지 않습니다.

발굴 단계와, 좋은 발굴이 만들어 내는 것

발굴은 수주를 위해 가장 자주 깎이고 나중에 가장 자주 탓을 듣는 단계입니다. 슬라이드 한 벌을 내놓는 발굴은 영업 활동이었습니다. 산출물 네 개를 내놓는 발굴은 공학 작업이었습니다.

첫째는 프로세스 맵입니다. 리드가 매출이 되기까지 거치는 실제 단계의 순서를, 의사결정 지점과 그것을 책임지는 사람과 함께 그린 것이며, 관리자에게 설명을 부탁하는 대신 실제 작업을 관찰해서 만듭니다.

둘째는 데이터 모델입니다. 오브젝트, 필드, 관계, 선택 목록 값, 그리고 필드마다 그것을 유지할 사람의 이름입니다. 주인이 없는 필드는 아무도 채우지 않는 필드가 됩니다.

셋째는 연동 목록입니다. Salesforce에 데이터를 보내거나 받는 모든 시스템에 대해 방향, 양, 빈도, 레코드를 이어 주는 식별자, 그리고 연결이 실패했을 때 무슨 일이 벌어지는지를 적습니다.

넷째는 측정 가능한 완료 정의입니다. 영업팀이 Salesforce를 쓰고 있다가 아니라, 이번 분기에 종료된 기회의 90%에 담당자가 설정한 종료일과 금액과 단계가 들어 있고 주간 파이프라인 회의는 스프레드시트 없이 Salesforce 대시보드에서 진행된다와 같은 형태여야 합니다.

경쟁 입찰에서는 소프트웨어 RFP 지침이 그대로 적용됩니다. 모든 입찰자에게 발굴에서 무엇이 나오는지 묻고, 산출물의 이름을 대지 못하는 곳은 걸러내십시오.

일정이 사라지는 곳은 데이터 마이그레이션입니다

마이그레이션은 구축 비용의 몇 퍼센트로 견적되고 그 몇 배로 소모됩니다. 원인은 하나의 오해입니다. 팀은 레코드 건수를 기준으로 산정하지만, 마이그레이션 공수는 원본 품질에 비례합니다.

잘 관리된 시스템 하나에서 믿을 만한 기본 키를 달고 깨끗한 200만 행을 옮기는 일은 꼼꼼히 해도 일주일입니다. 레거시 CRM 하나와 지역별 스프레드시트 셋과 회계 패키지에 흩어진 4만 행을, 공통 식별자 없이 비고 필드에 십일 년치 자유 텍스트를 안은 채 옮기는 일은 두 달이고 오픈 시점에도 여전히 틀려 있습니다. 뒤쪽 일은 레코드 수가 오십분의 일이고 공수는 여덟 배입니다.

무엇을 약속하기 전에 원본을 프로파일링하십시오

프로파일링은 날짜에 합의하기 전에 개수를 세는 일입니다. 모든 원본 시스템에 대해 수행하고, 제안서의 마이그레이션 항목에 서명이 들어가기 전에 수행하십시오.

필드별로 널 값을 세십시오. 선택 목록으로 만들 생각인 모든 필드에서 서로 다른 값의 개수를 세십시오. 서로 다른 값이 340개인 국가 열은 선택 목록이 아니라 정제 프로젝트이기 때문입니다. 후보 키를 공유하는 레코드가 몇 건인지 세십시오. 날짜와 전화번호와 우편번호의 서식 일관성을 측정하십시오. 담당자도 이메일 주소도 없고 삼 년간 아무 활동도 없는 레코드를 세십시오. 그것들을 두고 가자고 제안할 때 편들어 줄 사람은 아무도 없기 때문입니다.

중간 규모의 자산이라면 프로파일링에 이틀에서 닷새가 듭니다. 프로그램에서 가장 저렴한 위험 감축 수단이며, 이것을 건너뛰는 것이 마이그레이션 산정이 한 방향으로만 틀리는 이유입니다.

중복 제거와, 플랫폼이 주는 규칙

Salesforce에는 기본 중복 관리 기능이 있고 그 한도가 설계를 좌우합니다. 오브젝트당 활성 중복 규칙은 최대 다섯 개, 활성 일치 규칙은 한 개까지 둘 수 있고, 중복 규칙을 여러 개 쓰면 오브젝트당 활성 일치 규칙이 다섯 개까지 늘어나며, 중복 규칙 하나가 참조할 수 있는 일치 규칙은 세 개까지입니다.

개수보다 중요한 동작이 두 가지 있습니다. 일치 키는 일치 수식이 적용되기 전에 비교 대상을 가장 가능성 높은 중복 100건으로 좁히므로, 진짜 근접 일치가 100건을 넘는 레코드는 끝까지 평가되지 않습니다. 그리고 규칙은 흔한 몇몇 경로에서 아예 실행되지 않습니다. 빠른 생성, 그리고 Apex 리드 변환을 켜지 않은 상태의 Lead 변환이 그것이며, 중복 규칙을 켜 둔 조직에 중복이 나타나는 경로가 바로 이것입니다.

그러므로 중복 제거는 마이그레이션 작업이고, 적재 전에 스테이징 데이터에서 끝내는 일이지, 켜 두고 잊어도 되는 런타임 기능이 아닙니다. 기본 규칙은 두 번째 방어선입니다.

external ID와, upsert가 insert보다 나은 이유

옮기는 모든 오브젝트에는 external ID가 필요합니다. 원본 시스템의 기본 키를 담는, 색인이 걸린 커스텀 필드를 말합니다. 마이그레이션 설계에서 단독으로 가치가 가장 높은 결정이며, 이 결정을 내리는 데는 비용이 들지 않습니다.

external ID가 있으면 그 필드로 레코드를 만들지 갱신할지 결정하는 upsert를 쓸 수 있습니다. 값이 일치하지 않으면 레코드가 생성되고, 한 번 일치하면 그 레코드가 갱신되며, 두 번 넘게 일치하면 중복 대신 오류가 반환됩니다. 그러면 모든 적재가 멱등해지고, 두 번 돌려도 데이터가 두 배가 되지 않으며, 따라서 예행연습을 할 수 있습니다.

세부 두 가지가 물어뜯습니다. external ID로 하는 일치가 대소문자를 구분하지 않는 것은 그 필드에 고유 속성이 있고 대소문자 무시 옵션이 선택된 경우뿐이며, 그렇지 않으면 ABC123과 abc123은 서로 다른 두 레코드입니다. 그리고 필드가 고유 색인 없는 external ID라면, 적재에 쓰는 계정에는 모든 데이터 보기 권한이 필요합니다.

이력을 옮길 것인가, 쓸모 있는 것을 옮길 것인가

기본 요구는 전부 가져오라는 것입니다. 그것은 거의 언제나 틀렸고, 서로 다른 세 가지 방식으로 비쌉니다.

마이그레이션 공수가 듭니다. 가장 오래된 데이터가 가장 더럽고 그 가치에 비해 지나치게 많은 정제 시간을 먹기 때문입니다. 저장 용량이 듭니다. 그리고 저장 용량은 실재하는 비용 항목입니다. Enterprise와 Professional과 Unlimited 조직에는 데이터 저장 용량 10 GB에 사용자 라이선스당 20 MB가 배정되므로, Enterprise 사용자 쉰 명이면 합계 11 GB이지 사용자당 11 GB가 아닙니다. 그리고 정착이 듭니다. 죽은 레코드로 가득한 시스템은 검색 결과를 믿지 말라고 사용자를 훈련시키기 때문입니다.

방어할 수 있는 입장은 진행 중이고 최근인 레코드는 전부 옮기고, 종료된 레코드는 사업이 실제로 보고에 쓰는 기간만큼 옮기고, 나머지는 읽을 수 있는 형태로 어딘가에 보관하는 것입니다. 쓸 데 없는 개인정보를 계속 들고 있는 것은 자산이 아니라 부채이므로, 이 건에서는 저장 용량의 논리와 컴플라이언스의 논리가 모처럼 같은 방향을 가리킵니다.

설정이냐 코드냐

Salesforce의 모든 요구사항은 선언적 방식으로도, 코드로도, 둘을 섞어서도 충족할 수 있으며, 이 선택이 앞으로 십 년간 그 시스템을 보유하는 비용을 결정합니다. 코드 편집기를 한 번도 열지 않더라도 이 구분은 또렷이 붙들어 둘 가치가 있습니다.

무엇이 선언적이어야 하는가

선언적이라는 말은 설정으로 만든다는 뜻입니다. 오브젝트, 필드, 페이지 레이아웃, 검증 규칙, 그리고 Salesforce의 시각적 자동화 빌더인 Flow가 여기에 속합니다. 관리자가 바꿀 수 있고, 런타임을 Salesforce가 소유하므로 플랫폼 업그레이드를 견디며, 적절한 권한을 가진 사람에게는 내용이 보입니다.

Salesforce 자신의 레코드 트리거 자동화 결정 가이드가 쓸 만한 기준선을 줍니다. 자동화 밀도를 세 축으로 측정하는데, 데이터 변경 하나에 발동하는 자동화의 수, 트랜잭션당 레코드 양, 그리고 하위 갱신이 관련 오브젝트로 얼마나 멀리 연쇄되는가입니다. 밀도가 낮은 경우, 즉 자동화가 열다섯 개 미만이고 레코드가 1건에서 200건인 배치이며 하위 쓰기가 많아야 한 번이라면, 레코드 트리거 Flow여야 합니다.

같은 가이드는 이 목록의 어떤 항목보다 돈을 많이 아끼는 규칙 하나를 줍니다. 오브젝트당 진입점을 하나만 두라는 것입니다. 같은 오브젝트에서 Flow와 Apex 트리거를 섞는 것이 실행 순서 결함을 영구적으로 만드는 길입니다.

커스텀 코드가 옳을 때

중간 밀도는 혼합에 속합니다. Flow가 흐름을 지휘하고 호출 가능한 Apex가 무거운 일을 맡으므로, 순서는 보이는 채로 남고 연산은 테스트 가능한 곳에 놓입니다. 높은 밀도는 그냥 Apex 트리거입니다. 그 지점에서는 선언적 도구가, 애초에 그것을 만들라고 설계되지 않은 시스템을 만드는 데 쓰이고 있기 때문입니다.

로직이 정말로 복잡할 때, 단위 테스트를 제대로 해야 할 때, 같은 동작이 여러 진입점에서 호출되어 한 번만 존재해야 할 때에도 코드가 옳습니다. 그 작업을 사람을 뽑아 안고 가는 대신 발주할 생각이라면, 저희 소프트웨어 개발 서비스는 바로 이 경계, 플랫폼이 끝나고 맞춤 엔지니어링이 시작되는 지점을 위해 있습니다.

용어는 움직이고, 낡은 용어는 경고 신호입니다

Salesforce는 도구를 폐기하며, 폐기된 도구를 전제로 쓰인 제안서는 그것이 실제로 언제 쓰였는지를 알려 줍니다. Salesforce는 2025년 12월 31일에 Workflow Rules와 Process Builder 지원을 종료했습니다. 기존 규칙은 계속 동작하지만 고객 지원도 버그 수정도 없으며, 권장 경로는 Migrate to Flow 도구를 써서 Flow Builder로 옮기는 것입니다.

각 선택의 장기 비용

선언적으로 만든 것은 만들기도 바꾸기도 더 쌉니다. 그 대가는 희석입니다. 문서가 없는 flow가 백 개 쌓이면, 레코드를 저장했을 때 무슨 일이 일어날지 아무도 예측하지 못하는 시스템이 됩니다.

코드는 만들기가 더 비싸지만 규모가 커졌을 때 따져 보는 비용이 훨씬 쌉니다. 읽을 수 있고, 버전을 관리할 수 있고, 테스트할 수 있기 때문입니다. 그 대가는 개발자가 필요하다는 것이며, Salesforce 개발자도 유지보수 계약도 없는 조직은 결국 자기 시스템을 바꿀 수 없게 됩니다.

가장 비싼 실패는 이 둘 중 어느 쪽도 아닙니다. 전부 선언적으로 만든 파트너가 떠난 뒤, 문서도 지정된 주인도 없는 조직에 남겨진 시스템입니다. 모든 것이 돌아가고 어느 것도 안전하게 바꿀 수 없는데, 이는 관리되지 않는 맞춤 소프트웨어와 같은 처지이며, 저희가 소프트웨어 유지보수에 실제로 드는 비용 글에서 길게 다룬 내용입니다.

연동, 그리고 한도가 아키텍처를 바꾸는 이유

연동은 저희 Salesforce 연동의 한도와 실제 비용 글에서 따로 다룹니다. 여기에 속하는 요점은 플랫폼 한도가 아키텍처의 입력 조건이지, 아홉째 주에 발견되는 운영상의 세부가 아니라는 것입니다.

형태를 정하는 것은 주로 두 가지 한도입니다. Enterprise Edition 조직의 총 API 요청 할당량은 24시간당 100,000회에, 라이선스 수에 라이선스 종류별 횟수를 곱한 값을 더하고, 추가로 구매한 몫을 더한 것입니다. Salesforce 라이선스의 경우 그 횟수는 1,000입니다. Salesforce 자신의 계산 예시는 Salesforce 라이선스 15개를 가진 Enterprise 조직이 115,000 요청을 받는 것입니다. 이 할당량은 조직 전체 단위이고 사용자별이 아니며, 20초 이상 실행되는 동시 인바운드 요청은 운영 환경에서 25개가 상한입니다.

둘째는 트랜잭션 단위로 강제되는 Apex 거버너 제한입니다. SOQL 쿼리는 동기 100개, 비동기 200개이고, SOQL로 가져오는 레코드는 50,000건, DML 문은 150개, DML이 처리하는 레코드는 10,000건, 힙은 동기 6 MB와 비동기 12 MB, CPU 시간은 동기 10,000밀리초에 비동기 60,000밀리초입니다.

이것들을 무시한 설계는 레코드 스무 건으로 하는 사용자 인수 테스트는 통과하고, 첫 번째 진짜 야간 적재에서 무너집니다. 그것은 버그가 아닙니다. 기본값 그대로 내려진 아키텍처 결정입니다.

환경과, sandbox 갱신이 파괴하는 것

Salesforce는 저장 용량과 갱신 주기가 서로 다른 sandbox 네 종류를 제공하며, 조합을 잘못 고르는 것은 뒤늦게 드러나는 일정상의 오류입니다.

Developer sandbox는 200 MB를 담고 하루에 한 번 갱신합니다. Developer Pro는 1 GB를 담고 역시 매일 갱신합니다. Partial Copy는 5 GB를 담고 템플릿으로 정의한 운영 데이터의 표본을 복사하며 닷새마다 갱신합니다. Full은 운영 환경의 복제본이고 29일마다 갱신합니다. Enterprise Edition에는 Developer sandbox 25개와 Partial Copy 한 개가 포함되고, Full sandbox는 Unlimited와 Performance에 딸려 오거나 추가 구매합니다.

Full sandbox의 29일 주기는 사람들이 너무 늦게 대비하는 제약입니다. 현실적으로 유일한 마이그레이션 예행연습 환경이 한 달에 한 번만 갱신되므로, 문제를 드러낸 예행연습은 깨끗하게 다시 해 보기까지 한 달을 잡아먹습니다. Full sandbox로 두 번 예행연습하는 것은 두 주가 아니라 아홉 주짜리 창입니다.

Developer와 Developer Pro sandbox는 메타데이터만 복사하므로, 개발자가 시험 삼아 넣어 둔 것은 갱신 뒤에 사라집니다. 테스트 데이터는 버전 관리에 둔 재실행 가능한 스크립트여야 하며, 그렇지 않으면 팀은 갱신할 때마다 하루를 손으로 다시 만드는 데 씁니다.

릴리스 관리는 change sets냐 파이프라인이냐

운영 조직에서는 Apex를 개발할 수 없으므로 모든 변경은 다른 곳에서 시작되어 옮겨져야 합니다. 어떻게 옮기느냐는 꼬리가 긴 결정입니다.

Change sets는 내장 메커니즘입니다. 설정 화면에서 바꿀 수 있는 것만 실어 나르고 레코드는 결코 나르지 않으며, 같은 운영 조직에 속한 조직들 사이에 배포 연결을 요구하고, 인바운드 change set은 구성 요소별이 아니라 통째로 배포됩니다. 클릭으로 조립되므로 차이를 비교할 수도, 리뷰할 수도, 반복할 수도 없으며, 같은 change set을 두 사람이 각각 조립하면 내용이 달라집니다.

관리자 한 명이 매달 릴리스하는 작은 조직에서는 그것으로 돌아갑니다. 같은 조직을 두 사람이 바꾸는 순간 돌아가지 않습니다. 병합도 이력도 없고, 무엇이 나갔는지의 기록이 누군가의 기억 속에만 있기 때문입니다.

대안은 소스 중심 파이프라인입니다. 메타데이터를 Git에 두고, 변경은 차이로 리뷰하고, 배포는 브랜치에서 실행합니다. 갖추는 데 며칠이 들고, 릴리스 관리를 기억에 기대는 일에서 반복 가능한 일로 바꿉니다. 만드는 사람이 둘 이상이라면 나중의 개선이 아니라 구축의 일부로 취급하십시오.

75% 커버리지 규칙은 품질 기준이 아닙니다

Apex를 운영 환경에 배포하려면 단위 테스트가 Apex 코드의 최소 75%를 덮고 그 테스트가 통과해야 합니다. Salesforce는 커버리지가 테스트의 효과를 시사하지만 보장하지는 않는다는 것, 그리고 테스트는 동작을 단언해야 한다는 것을 분명히 밝히고 있습니다.

이것이 상업적으로 무슨 뜻인지 읽으십시오. 75%는 관문이고, 관문은 공략당합니다. 무엇을 단언하기 위해서가 아니라 숫자를 맞추려고 쓰인 테스트 클래스는 통과하고 배포되고 아무것도 잡아내지 못합니다. 파트너의 작업을 검토할 때 커버리지가 몇 퍼센트냐고 묻지 마십시오. 테스트 메서드 세 개를 보여 달라고 하고 단언이 몇 개인지 세십시오.

Salesforce 구축은 오픈이 아니라 정착에서 실패합니다

시스템이 오픈하고, 프로젝트가 닫히고, 청구서가 지급되고, 여덟 달 뒤에도 영업 임원은 여전히 스프레드시트로 예측을 돌립니다. 아무것도 고장 나지 않았습니다. 그것이 실패한 Salesforce 프로그램의 가장 흔한 결말이며, 어떤 기술 지표에도 잡히지 않습니다.

셈법이 가혹한 이유는 라이선스 비용이 어떻든 계속되기 때문입니다. Enterprise 사용자 쉰 명에 월 £140이면 시스템을 쓰든 안 쓰든 연 £84,000이므로, 정착률 40%는 구축 비용을 무엇엔가 배분하기도 전에 라이선스만으로 연 £50,000 남짓이 순수한 낭비라는 뜻입니다.

정착은 또한 기술팀이 고칠 수 없는 유일한 실패 방식입니다. 파트너는 명세대로 정확히 만들고 모든 인수 기준을 충족하고도 아무도 열지 않는 것을 남기고 갈 수 있습니다. 발굴 단계의 완료 정의가 사용에 관한 것이어야 하는 이유가 그것이고, 오픈으로 프로젝트를 닫았다고 보면 안 되는 이유도 그것입니다.

정착을 실제로 움직이는 실천

정착을 확실히 움직이는 것은 네 가지이고, 그중 어느 것도 교육 영상이 아닙니다.

역할별 교육을 따로 하는 것. 영업 담당과 영업 관리자는 서로 다른 이유로 시스템의 서로 다른 부분을 쓰므로, 합쳐서 한 번 하는 세션은 양쪽 다 제대로 못 가르칩니다. 역할마다 그 역할의 업무 흐름만 가르치십시오.

필수 필드 집합을 작게 두는 것. 보고가 성립하는 최소한의 필드를 골라 그것만 필수로 하고 나머지는 전부 선택으로 두십시오. 필수 필드가 하나 늘 때마다 레코드를 절반쯤 쓰다 포기할 이유가 하나 늘고, 입력을 벌하는 시스템에는 입력이 덜 들어옵니다.

관리자 보고가 그 데이터에 의존하게 하는 것. 실제로 통하는 것은 이것입니다. 주간 파이프라인 회의가 회의실에 스프레드시트 없이 Salesforce 대시보드에서 진행되면 데이터는 입력됩니다. 그러지 않는 쪽의 선택지가 그 대화에서 사라지는 것이기 때문입니다. 관리자가 개인 스프레드시트를 들고 있으면 CRM은 선택 사항이고, 그 사실은 모두가 압니다.

주중에 시간이 배정된, 이름이 있는 주인을 두는 것. 위원회가 아닙니다. 조직을 소유하고 관리자 권한을 쥐고 정착으로 평가받으며 그것을 위한 시간이 확보된 한 사람입니다. 이것이 없는 조직은 첫 달부터 낡아 갑니다.

실패 방식과 그 이른 전조

저희가 복구를 의뢰받는 Salesforce 구축 실패는 대부분 여섯 가지 방식으로 설명되며, 각각은 피해가 드러나기 훨씬 전에 신호를 보입니다.

망가진 프로세스를 그대로 복제하는 것. 전조는 원하는 결과가 아니라 현행 시스템을, 그것도 옛 시스템의 필드 이름으로 서술하는 요구사항 문서입니다. 나쁜 프로세스를 자동화하면 그것은 더 빨라지고 더 바꾸기 어려워집니다.

한계 없는 커스터마이징. 전조는 반려가 한 건도 없는 변경 요청 기록입니다. Enterprise Edition은 오브젝트당 커스텀 필드 500개와 커스텀 오브젝트 200개를 허용하는데, 플랫폼 한도에 닿기 훨씬 전에 아무도 유지할 수 없는 것을 만들기에 충분한 여유입니다.

단일한 주인이 없는 것. 전조는 Salesforce는 누구 것이냐는 물음의 답에 그리고라는 말이 들어 있는 것입니다.

전부 옮기는 것. 전조는 보존 기간에 대한 판단이 아니라 레코드 건수로 정의된 마이그레이션 범위입니다.

테스트 환경 규율이 없는 것. 전조는 선택 목록 값일 뿐이니 운영에서 그냥 바꾸자고 누군가 말하는 것입니다.

사용이 아니라 오픈을 측정하는 것. 전조는 마지막 마일스톤이 숫자가 아니라 날짜인 프로젝트 계획입니다.

소규모, 중규모, 복잡한 구축의 기간

경과 시간과 공수는 서로 다른 질문인데 구매자는 이 둘을 뒤섞습니다. 아래는 영국 중견 시장 작업에서 얻은 저희 자체 구간이며, 공개된 수치가 아닙니다.

소규모 구축, 즉 단일 클라우드에 사용자 25명 안팎까지, 연동은 많아야 하나, 깨끗한 데이터 원본 하나라면 경과 6주에서 10주, 컨설턴트 공수 20일에서 45일입니다. 중규모, 즉 클라우드 하나나 둘에 걸친 사용자 25명에서 150명, 연동 두 개에서 네 개, 진짜 마이그레이션이 있는 경우는 4개월에서 7개월, 90일에서 220일입니다. 복잡한 프로그램, 즉 사용자 150명 이상, 멀티 클라우드, 연동 다섯 개 이상, 둘 이상의 국가에 걸치는 경우는 9개월에서 18개월, 400일 이상입니다.

그 총량 안에서 발굴은 공수의 10에서 15%, 설정과 구축이 30에서 40%, 데이터 마이그레이션이 20에서 30%이고 원본 품질이 나쁘면 가파르게 올라가며, 연동이 10에서 20%, 테스트와 교육과 하이퍼케어가 15에서 20%입니다. 불어나는 항목은 매번 마이그레이션입니다.

경과 시간이 공수를 팀 인원으로 나눈 값을 넘는 데에는 팀 잘못이 아닌 이유들이 있습니다. sandbox 갱신 주기, 사용자 인수 테스트에 이해관계자를 확보할 수 있는지, 그리고 API가 필요한 제삼자를 기다리는 시간입니다. 그 위험을 누가 지는지는 계약이 정하며, 그래서 고정 가격이냐 실비 정산이냐라는 물음이 CRM 작업에서는 대부분의 작업에서보다 더 중요합니다.

CRM 프로그램에서의 영국 데이터 보호

CRM은 사람에 대한 데이터베이스이므로 UK GDPR이 사실상 그 전부에 적용되며, 모든 구축에서 세 가지 물음이 나옵니다.

여기에 DPIA가 필요합니까

ICO의 DPIA가 필요한 경우 지침은 UK GDPR Article 35(1)에서 나오는 일반 원칙, 즉 처리가 사람의 권리와 자유에 높은 위험을 초래할 가능성이 높은 경우 DPIA가 필요하다는 원칙을 제시하고, Article 35(4)에 따른 ICO 자체의 작업 목록을 함께 실었습니다.

그중 둘은 전형적인 CRM 마이그레이션에 정면으로 걸립니다. 여러 출처에서 얻은 개인정보를 결합하거나 비교하거나 대조하는 것으로 정의되는 데이터 매칭은 통합 마이그레이션이 하는 바로 그 일입니다. 대규모 프로파일링은 Lead와 Account 스코어링을 포함합니다. ICO는 또한 엄격한 규칙은 아니지만 대개 유럽 기준 중 두 가지가 겹치면 DPIA가 필요함을 시사한다고 밝히고 있습니다. 이 지침은 Data (Use and Access) Act로 인한 변경 때문에 현재 재검토 중이므로, 요약에 기대지 말고 원문을 확인하십시오.

데이터는 실제로 어디에 있습니까

Salesforce는 전 세계 규모의 플랫폼이고 여러분의 조직이 어느 인스턴스에서 도는지는 계약 사항이지 가정할 일이 아닙니다. ICO의 국제 이전 간편 안내는 2026년 1월 15일에 마지막으로 갱신되었고 세 단계 판정을 제시합니다. 그 처리에 UK GDPR이 적용되는가, 영국 밖 조직으로의 이전을 여러분이 개시하는가, 수령자가 별개의 법인인가입니다. 셋 다 그렇다면 제한된 이전입니다.

제한된 이전에는 영국의 적정성 규정, 국제 데이터 이전 협정이나 부속서 또는 구속적 기업 규칙 같은 적절한 안전장치, 아니면 예외가 필요합니다. 안전장치에 기대는 경우 ICO는 이전 위험 평가를 기대합니다. 이것은 엔지니어링 과제가 아니라 계약 검토이며, 마이그레이션 뒤가 아니라 앞에서 일어나야 합니다.

구축 파트너는 처리자입니다

파트너가 여러분의 조직을 설정하고 데이터를 적재하고 그에 대한 자격 증명을 쥐고 있을 때, 그들은 여러분을 대신해 개인정보를 처리하고 있는 것입니다. ICO의 컨트롤러와 프로세서 지침이 그로부터 따라오는 것을 정하고 있으며, 실무적 함의는 계약상의 것입니다.

문서화된 지시, 비밀 유지, 보안, 하위 처리자, 감사권, 그리고 계약 종료 시 데이터의 삭제 또는 반환을 담은 서면 합의가 필요합니다. 마지막 항목이 가장 자주 빠지는 조항입니다. 여러분의 고객 데이터베이스 전체 사본을 Full sandbox에 열한 달 동안 들고 있으면서 계약에는 삭제에 관해 아무 말도 없는 파트너는, 그쪽이 아니라 여러분 쪽에 열려 있는 책임입니다.

후보 파트너에게 물어볼 것

여섯 가지 질문과, 대화를 끝내야 하는 답들입니다.

발굴에서 무엇이 나오는지 물으십시오. 답이 프로세스 맵, 데이터 모델, 연동 목록, 측정 가능한 완료 정의가 아니라 제안서라면, 그들은 범위를 잡는 것이 아니라 팔고 있는 것입니다.

원본 데이터를 어떻게 언제 프로파일링할지 물으십시오. 마이그레이션 산정에 합의한 뒤에 프로파일링이 이루어진다면 그 산정은 짐작입니다.

자동화의 기본 선택이 무엇인지 묻고, 밀도 논증이 나오는지 들으십시오. 언제나 Flow 또는 언제나 Apex라고 답하는 파트너는 도구를 하나만 가진 것입니다. 2026년에 Process Builder를 지정하는 파트너는 삼 년 동안 지원 종료 공지를 읽지 않은 것입니다.

변경이 sandbox에서 운영 환경으로 어떻게 옮겨지는지 물으십시오. change sets라는 답은 관리자가 한 명인 조직에서는 받아들일 만하고, 그보다 큰 무엇에서든 경고입니다.

오픈 이후 누가 그 조직을 소유하며 그것이 주당 몇 시간인지 물으십시오. 답하지 못한다면 정착은 누구의 문제도 아닙니다.

계약이 끝날 때 그들의 sandbox에 있는 여러분의 데이터가 어떻게 되는지 묻고, 그 답을 이메일이 아니라 계약서로 받으십시오. 저희 기술 실사 안내에 적어 둔 같은 규율이 여기에도 적용됩니다. 확언을 받아들이지 말고 주장을 검증하십시오.

답이 Salesforce가 아닐 때

사용자가 대략 열 명 미만이고 연동 요구가 없으며 다섯 단계 파이프라인에 들어맞는 프로세스라면, Enterprise 라이선스도 그 구축도 문제보다 큽니다. 더 싼 CRM이나 사용자당 £20인 Starter Suite로 일이 되고, 나중에 감당할 수 있는 비용으로 갈아탈 수 있습니다.

실제 요구가 어떤 제품도 지원하지 않는 업무 흐름 하나뿐이고 나머지는 이미 처리되어 있다면, 여러분은 애플리케이션 하나를 얹으려고 플랫폼을 사는 것입니다. 그것은 대개 목적에 맞춰 만든 시스템의 자리이고, 저희 맞춤 소프트웨어 개발은 그 전제에서 출발합니다. 만들 것인가 살 것인가의 결정은 차별화하는 프로세스가 사업의 핵심인지 그 주변의 세부인지에 달려 있습니다.

아무도 그 시스템을 소유하지 않을 것이라면 사지 마십시오. 영업 과정에서 가장 말하기 어려운 것이고 낭비를 가장 믿을 만하게 예측하는 것입니다. 주인 없는 CRM은 요란하게 망가지지 않습니다. 사용자당 월 £140을 내면서, 대체하기로 했던 그 스프레드시트의 사본으로 조용히 변해 갑니다.

그리고 목표가 CRM이 아니라 AI 에이전트 계층이라면, 그것은 돌아가는 구축을 대체하는 것이 아니라 그 위에 얹힙니다. 셈법은 저희 Agentforce에 실제로 드는 비용 글에서 다룹니다.

작업의 순서

통하는 순서는 이렇습니다. 데이터를 프로파일링하고, 산출물 네 개가 나올 때까지 발굴을 하고, 표준 모델에 합의한 뒤 거기서 벗어나는 모든 것에 값을 매기고, 오브젝트당 자동화 진입점 하나로 구축하고, Full sandbox에서 마이그레이션을 두 번 예행연습하고, 역할별로 교육하고, 날짜가 아니라 사용 수치가 충족될 때까지 프로젝트를 열어 둡니다.

실패하는 순서는 이렇습니다. 계약하고, 설정하고, 마이그레이션을 늦추고, 교육을 한 번만 하고, 날짜에 맞춰 오픈하고, 프로젝트를 닫습니다.

Mecanik이 하는 일은 이 가운데 라이선스 관리가 아니라 엔지니어링에 해당하는 부분입니다. 실제 플랫폼 한도를 놓고 하는 연동 설계, 마이그레이션 프로파일링과 도구 제작, 설정이 바닥났을 때의 맞춤 개발, 그리고 CRM 데이터를 고객 앞에 내놓는 프런트엔드 작업입니다. 저희가 어떻게 참여하는지는 소프트웨어 개발 서비스와 웹 개발자 채용 페이지에서 설명합니다. 서명하기 전에 파트너의 견적에 대한 제삼자 의견이 필요하다면, 그 검토만을 위해 개발자를 고용할 수도 있습니다.

자주 묻는 질문

영국에서 Salesforce 구축에는 비용이 얼마나 듭니까? Salesforce는 영국에서 Sales Cloud Enterprise를 연간 청구 기준 사용자당 월 £140으로 제시하므로, 사용자 50명이면 라이선스만 연 £84,000입니다. 그 위의 구축 서비스에 대한 저희 자체 추정치는 거의 표준 그대로의 배포가 첫해 라이선스 지출의 0.5배에서 1배, 전형적인 중견 시장 프로젝트가 1배에서 3배, 레거시 데이터와 무거운 커스터마이징을 안은 멀티 클라우드 프로그램이 3배에서 5배입니다.

Salesforce 구축에는 시간이 얼마나 걸립니까? 저희 자체 구간은 단일 클라우드에 깨끗한 데이터로 사용자 25명까지가 6주에서 10주와 컨설턴트 20일에서 45일, 연동이 두 개에서 네 개인 사용자 25명에서 150명이 4개월에서 7개월과 90일에서 220일, 레거시 마이그레이션이 있는 멀티 클라우드 프로그램이 9개월에서 18개월과 400일 이상입니다. 불어나는 단계는 데이터 마이그레이션인데, 공수가 레코드 건수가 아니라 원본 데이터 품질에 비례하기 때문입니다.

Salesforce 구축은 왜 실패합니까? 거의 언제나 오픈이 아니라 정착에서 실패합니다. 기술적으로 정확하지만 아무도 쓰지 않는 시스템은 라이선스 청구서가 계속 도는 전손입니다. 흔한 원인은 망가진 프로세스의 복제, 한계 없는 커스터마이징, 지정된 단일 주인의 부재, 이력 데이터의 전량 이관, 테스트 환경 규율의 부재, 그리고 사용이 아니라 오픈을 측정하는 것입니다.

Salesforce는 설정으로 만들어야 합니까, 커스텀 코드로 만들어야 합니까? Salesforce 자신의 결정 가이드가 자동화 밀도로 기준선을 정합니다. 오브젝트에 자동화가 열다섯 개 미만이고 레코드 1건에서 200건인 배치이며 하위 쓰기가 많아야 한 번이면 레코드 트리거 Flow여야 합니다. 중간 밀도는 Flow가 호출 가능한 Apex를 지휘하는 방식이 맞습니다. 높은 밀도는 Apex 트리거가 맞습니다. 같은 오브젝트에서 Flow와 Apex 트리거를 섞지 말고 오브젝트당 진입점을 하나만 두십시오.

Salesforce 구축에 DPIA가 필요합니까? 필요한 경우가 많습니다. ICO는 여러 출처에서 얻은 개인정보를 결합하거나 비교하는 것을 뜻하는 데이터 매칭과 대규모 프로파일링을 DPIA가 필요함을 시사하는 작업으로 열거하고 있고, 리드 스코어링을 동반한 통합 마이그레이션은 두 가지를 모두 합니다. 이 지침은 Data (Use and Access) Act에 따라 현재 재검토 중이므로, 요약이 아니라 ICO의 현재 입장을 확인하십시오.