Salesforce 인하우스 팀 구축을 채용 공고 몇 개 올리는 일로 착각하는 CIO가 많습니다. 실제로는 조직 구조, 역할 경계, SI와의 권한 이양 순서를 동시에 설계해야 하는 아키텍처 문제입니다. 관리자 한 명을 뽑아놓고 SI 의존도가 그대로인 조직을 여러 곳에서 봅니다.
SI 의존이 구조적으로 굳어지는 이유
Salesforce를 3년 이상 운영한 조직에서 SI 의존도가 낮아지지 않는 이유는 단순합니다. 초기 구축 단계의 지식이 SI 컨설턴트의 머릿속에만 남아 있기 때문입니다. Flow 로직, Apex 트리거 순서, Sharing Rule 예외 처리 같은 결정들이 문서화되지 않은 채 넘어가면, 다음 변경 요청도 같은 SI에게 돌아갈 수밖에 없습니다.
이 구조는 비용보다 리스크가 더 큽니다. SI 담당 컨설턴트가 교체되면 조직은 자기 시스템의 설계 의도를 다시 배우는 처지에 놓입니다. 400만 유로 이상의 숨은 플랫폼 리스크가 기술 실사에서 드러나는 사례의 상당수는, 문서화되지 않은 커스터마이징이 원인입니다. 이런 리스크는 관련 글 Salesforce 거버넌스와 SI 의존성에서 더 자세히 다룬 바 있습니다.
인하우스 팀을 만들자는 결정이 나오는 시점은 대개 두 가지입니다. 하나는 SI 비용이 연간 예산에서 통제 불가능한 비중을 차지할 때, 다른 하나는 품의 과정에서 “우리가 우리 시스템을 이해하지 못한다”는 사실이 드러날 때입니다. 두 경우 모두 늦은 타이밍입니다. 인하우스 전환은 위기가 오기 전, Org가 안정적일 때 설계하는 것이 맞습니다.
Salesforce 인하우스 팀 구축의 역할 아키텍처
인하우스 팀은 채용 순서가 아니라 역할 계층으로 먼저 설계해야 합니다. 실무에서 작동하는 구조는 3계층입니다.
첫째, 운영 계층입니다. Salesforce Administrator가 이 계층을 담당합니다. 권한 관리, 사용자 온보딩, Flow 유지보수, 리포트와 대시보드 관리가 핵심 업무입니다. 이 역할이 없으면 SI에게 사소한 변경 요청까지 매번 발주해야 하는 구조가 됩니다.
둘째, 확장 계층입니다. Salesforce Developer 혹은 Technical Consultant가 담당합니다. Apex, Lightning Web Components, External Services 통합, Data Cloud Data Stream 설정처럼 코드 기반 작업을 처리합니다. 이 계층이 취약하면 신규 기능 요청이 전부 SI로 넘어가고, 인하우스 팀은 티켓 접수 창구로 전락합니다.
셋째, 설계 계층입니다. Solution Architect 혹은 내부 CoE(Center of Excellence) 리드가 담당합니다. Org 전체의 데이터 모델, Sharing 아키텍처, Agentforce Topics와 Actions의 거버넌스, 릴리스 관리 정책을 책임집니다. 이 계층은 대부분의 조직이 마지막까지 미루는 역할인데, 사실은 가장 먼저 확보해야 하는 역할입니다. 설계 계층 없이 운영과 확장 계층만 채용하면, SI가 나가는 순간 Org의 아키텍처적 일관성이 무너지기 시작합니다.
역량 로드맵 관점에서 보면 이 세 계층은 순차적으로 채용하되, 설계 계층의 채용 시점을 최대한 앞당기는 것이 맞습니다. 실무에서 자주 나오는 실패 패턴은 Administrator부터 채용하고 Solution Architect는 예산이 남으면 고려하는 순서입니다. 이 순서는 단기 비용은 아끼지만, 2년 뒤 다시 SI에 재의존하는 결과로 이어집니다.
계층 구조 (권장 채용 순서)
1. Solution Architect / CoE Lead ← Org 아키텍처 결정권
2. Salesforce Developer ← 코드 기반 확장
3. Salesforce Administrator ← 일상 운영
4. Business Analyst (겸직 가능) ← 요구사항 정리, Prompt Builder 시나리오 설계CoE(Center of Excellence) 구조를 함께 설계해야 채용 이후에도 역할 간 충돌이 생기지 않습니다. CoE의 역할과 KPI 설계는 Salesforce CoE 구축 글에서 다룬 프레임워크를 참고할 수 있습니다.
SI에서 인하우스로의 이관 시퀀스
역할을 채용했다고 SI 의존이 자동으로 줄지 않습니다. 이관 시퀀스를 명시적으로 설계해야 합니다. 실무에서 효과적인 순서는 다음과 같습니다.
먼저 지식 이관 단계입니다. SI가 만든 Flow, Apex 클래스, Data Cloud Identity Resolution ruleset에 대한 아키텍처 문서를 요구합니다. 이 단계에서 SI의 협조도가 곧 계약의 질을 보여줍니다. 문서화를 거부하거나 지연하는 SI는 애초에 지식 종속을 의도한 관계였을 가능성이 높습니다.
다음은 병행 운영 단계입니다. 인하우스 팀이 저위험 변경 건(리포트 수정, 권한 조정, 간단한 Flow 수정)을 직접 처리하고 SI는 검토자 역할로 물러납니다. 이 단계를 3~6개월 유지하면서 인하우스 팀의 실수율과 처리 속도를 측정합니다.
마지막은 권한 이양 단계입니다. Release Management, Sandbox 전략, Deployment Pipeline의 소유권을 인하우스 팀으로 완전히 넘깁니다. SI는 이 시점부터 신규 기능 개발이나 Agentforce 확장 같은 고난도 프로젝트에만 제한적으로 관여합니다.
이 3단계를 거치지 않고 바로 “SI 계약 종료 후 인하우스 전환”을 시도하는 조직은 대부분 6개월 안에 운영 장애를 겪습니다. 이관은 스위치가 아니라 그라데이션입니다.
대부분이 놓치는 함정
가장 흔한 함정은 인하우스 팀을 SI의 축소판으로 만드는 것입니다. SI가 하던 업무를 그대로 내재화하려는 조직은, SI와 똑같은 문제를 내부에서 반복합니다. 문서화 부재, 역할 모호성, 릴리스 프로세스 부재가 SI 밖으로 옮겨질 뿐입니다. 인하우스 전환은 SI 대체가 아니라 거버넌스 재설계여야 합니다.
두 번째 함정은 Agentforce와 Data Cloud 같은 신규 영역의 역량을 기존 Administrator에게 떠맡기는 패턴입니다. Atlas Reasoning Engine 기반의 Topic 설계, Identity Resolution ruleset 튜닝, Data Graph 구성은 전통적인 Admin 스킬셋과 다른 역량입니다. 채용 공고에 “Salesforce Admin 경력 3년 이상”만 적어놓고 Data Cloud 아키텍처를 기대하는 조직이 여전히 많습니다. 이 격차는 채용 실패로 이어지거나, 채용 후 6개월 안에 재교육 비용으로 되돌아옵니다.
세 번째 함정은 인하우스 팀의 커리어 경로를 설계하지 않는 것입니다. Administrator로 채용된 인력이 2년 뒤 Developer나 Architect로 성장할 경로가 없으면, 가장 유능한 인력부터 이직합니다. 조직 내부에 성장 경로가 없다는 신호는 채용 시장에서 빠르게 퍼집니다. 인하우스 팀 구축은 채용 프로젝트가 아니라 리텐션 설계 프로젝트로 봐야 정확합니다.
네 번째 함정은 품의 단계에서 인하우스 전환의 ROI를 SI 비용 절감으로만 산정하는 것입니다. 실제 가치는 비용 절감보다 의사결정 속도에 있습니다. 릴리스 승인, 긴급 장애 대응, 신규 요구사항 반영 속도가 SI 발주 사이클(보통 24주)에서 인하우스 실행 사이클(13일)로 단축되는 것이 핵심 지표입니다. 이 지표를 품의 문서에 명시하지 않으면 예산 승인 단계에서 설득력을 잃습니다.
인하우스 전환을 진지하게 검토하는 조직이라면, 전환 전에 현재 Org의 건강 상태를 먼저 진단하는 것이 순서상 맞습니다. 문서화되지 않은 커스터마이징이나 방치된 자동화가 많은 Org를 그대로 인하우스로 넘기면, 새 팀이 첫 3개월을 부채 정리에만 쓰게 됩니다. Org 진단과 고도화 프레임워크는 Org 진단 및 고도화 페이지에서 다루는 접근과 맞닿아 있습니다.
앞으로의 릴리스 주기를 보면 이 판단은 더 중요해집니다. Summer 릴리스마다 Agentforce와 Data Cloud 기능이 확장되는 흐름에서, SI에게만 의존하는 조직은 매 릴리스마다 새로운 학습 곡선을 외주로 지불하게 됩니다. 인하우스 팀이 릴리스 노트를 자체적으로 해석하고 반영할 수 있는 수준에 도달하면, SI는 전략적 파트너로 남고 운영 부담은 내부로 이동합니다. 이 전환이 늦어질수록 SI 종속 비용은 누적됩니다.
핵심 정리
- Salesforce 인하우스 팀 구축은 채용 순서가 아니라 역할 계층 설계에서 시작합니다. Solution Architect 역할을 가장 먼저 확보하는 조직이 재의존을 피합니다.
- SI에서 인하우스로의 이관은 지식 이관, 병행 운영, 권한 이양의 3단계 시퀀스로 진행할 때 운영 장애 없이 완료됩니다.
- Agentforce, Data Cloud 관련 역량은 전통적인 Administrator 스킬셋과 다르므로 채용 공고 단계에서 명확히 분리해야 합니다.
- 인하우스 전환의 ROI는 비용 절감보다 의사결정 속도(SI 발주 사이클 2
4주 대비 인하우스 실행 13일)로 산정해야 품의 단계에서 설득력을 가집니다. - 전환 전 Org 건강 상태 진단이 선행되지 않으면, 신규 인하우스 팀이 초기 몇 달을 기술 부채 정리에만 소진하게 됩니다.
