엔터프라이즈 Salesforce 조직에서 SI 의존도를 낮추는 문제는 대부분 비용 이슈로 오해받습니다. 실제로는 아키텍처 지식이 외부에 갇혀 있다는 구조적 리스크입니다. Salesforce SI 의존도 줄이기는 단순히 계약을 종료하는 문제가 아니라, 조직 내부에 아키텍처 의사결정 역량을 재구축하는 작업입니다. 이 작업을 계약 협상이나 인력 채용 문제로만 접근하면 대부분 실패합니다.
문제의 본질은 지식이 아니라 권한입니다. 조직도상 CIO나 CTO가 최종 의사결정권자여도, 실제 아키텍처 변경 하나하나가 SI 파트너의 승인과 견적을 거쳐야 진행된다면 그 조직은 이미 통제력을 잃은 상태입니다.
SI 의존이 구조적 리스크가 되는 지점
많은 조직이 SI 의존을 “불편하지만 감수할 만한 비용”으로 여깁니다. 이 판단은 대부분 두 가지를 놓칩니다. 하나는 의존의 복리 효과이고, 다른 하나는 위기 상황에서의 협상력 붕괴입니다.
Salesforce 오브젝트 모델, Flow 자동화, Apex 트리거가 5년 이상 누적되면 그 조직의 org는 단일 벤더만 이해하는 블랙박스가 됩니다. 신규 요구사항이 들어올 때마다 SI가 “기존 로직과의 충돌 검토”를 명목으로 견적을 부풀리는 구조가 고착됩니다. 이 시점부터는 기술 부채가 아니라 지식 부채입니다. 코드는 org 안에 있지만, 왜 그렇게 설계했는지에 대한 맥락은 계약이 끝나면 함께 사라집니다.
두 번째는 협상력입니다. SI 계약 갱신 시점에 내부 대안이 전혀 없는 조직은 가격 인상을 그대로 수용할 수밖에 없습니다. 실제로 이 규모의 조직에서는 SI 교체 논의 자체가 내부적으로 금기시되는 경우가 흔합니다. “지금 바꾸면 아는 사람이 아무도 없다”는 두려움이 협상 테이블에서 그대로 드러나기 때문입니다.
세 번째는 아키텍처 표류입니다. SI가 여러 담당자를 순환 배치하면서 프로젝트마다 다른 설계 철학이 섞여 들어갑니다. 어떤 프로젝트는 Flow 중심으로, 다른 프로젝트는 Apex 중심으로 구현되고, 이 둘을 통합할 내부 아키텍트가 없으니 org 전체가 일관성 없는 패치워크가 됩니다. 이런 상태에서 Agentforce나 Data Cloud 같은 신규 레이어를 얹으면 문제가 기하급수적으로 커집니다. 실제로 이 유형의 조직 진단을 진행하면 표면적인 버그보다 설계 철학의 불일치가 더 큰 리스크로 드러나는 경우가 많습니다. 이 패턴에 대해서는 SI 의존이 거버넌스를 어떻게 무너뜨리는가에서 더 구체적으로 다뤘습니다.
SI 의존도를 줄이는 아키텍처 설계 방식
SI 의존도 줄이기의 시작점은 계약 재협상이 아니라 지식 지도 작성입니다. 현재 org에서 어떤 결정이 SI에게 있고, 어떤 결정이 내부에 있는지를 명확히 분리하는 작업이 선행되어야 합니다.
아키텍처 결정권의 재배치
실무에서 효과적인 구조는 세 층위로 나누는 것입니다. 첫째, 전략적 아키텍처 결정, 즉 Data Cloud 도입 여부, Agentforce Topics 설계, Identity Resolution ruleset 정의 같은 의사결정은 내부 아키텍트가 소유합니다. 둘째, 구현 실행, 즉 Flow 빌드, Apex 코딩, 통합 스크립트 작성은 SI나 외부 개발 인력에 위임할 수 있습니다. 셋째, 검증과 승인은 반드시 내부 거버넌스 보드를 거치도록 합니다.
이 구조가 작동하려면 내부에 최소 한 명의 시니어 아키텍트가 있어야 합니다. 이 역할은 코딩 능력보다 판단력이 중요합니다. SI가 제안하는 설계안을 이해하고, 대안을 요구하고, 기술 부채가 쌓이는 지점을 알아채는 능력입니다. 컨설턴트 200명, 사업부 15개 규모의 조직에서 Center of Excellence를 운영해 본 경험에 비추어 보면, 이 역할이 공백일 때 SI 의존도는 절대 줄어들지 않습니다. 반대로 이 역할 하나만 채워져도 SI와의 관계가 “지시받는 관계”에서 “감리받는 관계”로 바뀝니다.
기술 부채 레지스트리 운영
두 번째 축은 기술 부채를 문서화하는 체계입니다. org 안에 존재하는 모든 커스텀 Apex, 레거시 Flow, 사용되지 않는 Validation Rule을 목록화하고, 각 항목에 대해 “누가 만들었고 왜 만들었는지”를 기록해야 합니다. 이 작업은 지루하지만 SI 의존도 줄이기의 핵심 인프라입니다. 지식이 문서화되지 않으면 사람이 바뀔 때마다 조직은 원점으로 돌아갑니다.
실무에서는 이 레지스트리를 분기별로 갱신하고, 신규 SI 계약이나 프로젝트 킥오프 전에 반드시 검토하도록 프로세스를 고정합니다. 위험도가 400만 유로 이상에 달하는 플랫폼 리스크가 드러나는 경우, 대부분 원인은 복잡한 로직 자체가 아니라 그 로직의 존재 이유를 아무도 기록해두지 않았다는 데 있습니다.
하이브리드 운영 모델
SI를 완전히 제거하는 것은 대부분의 조직에게 현실적이지 않습니다. 목표는 제로가 아니라 통제 가능한 의존입니다. 내부 팀이 아키텍처와 로드맵을 소유하고, SI는 구현 역량을 제공하는 파트너로 역할이 재정의되어야 합니다.
이 모델에서는 SI와의 계약 구조도 바뀝니다. 시간 단가 기반 계약에서 산출물 기반 계약으로 전환하고, 각 산출물에 대해 내부 아키텍트의 승인 게이트를 명시합니다. 이렇게 하면 SI가 불필요한 복잡성을 추가할 유인이 줄어듭니다. 견적이 시간이 아니라 결과물에 묶이기 때문입니다.
또한 지식 이전 조항을 계약에 명시적으로 포함해야 합니다. 프로젝트 종료 시점에 아키텍처 문서, 의사결정 로그, 설계 근거를 인도받는 것을 계약 조건으로 못박지 않으면, SI 교체 시점마다 같은 문제가 반복됩니다. 이 부분은 내부 CoE(Center of Excellence) 구축 방법에서 다룬 운영 체계와 직접 연결됩니다.
대부분 조직이 놓치는 함정
가장 흔한 실수는 SI 의존도 줄이기를 인력 채용 문제로 축소하는 것입니다. 내부 관리자 한두 명을 채용하고 “이제 우리도 내재화했다”고 선언하는 경우가 많습니다. 하지만 그 인력이 아키텍처 결정권을 실제로 행사할 수 있는 조직 구조와 예산 권한이 없다면, SI는 여전히 실질적인 의사결정자로 남습니다.
두 번째 함정은 급격한 전환입니다. 5년간 쌓인 SI 의존을 6개월 안에 해소하려는 시도는 대부분 org 장애로 이어집니다. 실제로 위기 프로젝트 대응 사례를 보면, 90일 내 정상화가 가능한 경우는 SI를 즉시 배제한 경우가 아니라, SI의 역할을 재정의하면서 내부 검증 레이어를 먼저 세운 경우입니다. 전환은 단계적이어야 하고, 각 단계마다 내부 팀이 실제로 판단할 수 있는지를 검증해야 합니다.
세 번째 함정은 문서화를 사후 작업으로 미루는 것입니다. “일단 급한 불부터 끄고 문서는 나중에”라는 접근은 거의 항상 문서화가 영원히 미뤄지는 결과로 이어집니다. 기술 부채 레지스트리는 SI 의존도 줄이기 프로젝트의 첫 산출물이어야지, 부수적인 결과물이어서는 안 됩니다.
네 번째 함정은 Agentforce나 Data Cloud 같은 신규 이니셔티브를 기존 SI 의존 구조 위에 그대로 얹는 것입니다. Atlas Reasoning Engine 기반 에이전트를 설계하면서 Topics와 Actions의 경계를 SI에게 전적으로 위임하면, 새로운 레이어에서도 같은 의존 구조가 그대로 복제됩니다. 신규 이니셔티브는 오히려 내부 통제력을 회복할 좋은 기회이며, 이 시점에 아키텍처 소유권을 명확히 재정의하지 않으면 다음 5년도 같은 패턴이 반복됩니다. 이런 구조적 재설계는 org 전체의 건강도를 진단하는 작업과 병행되어야 효과가 있으며, 이 지점에서 Org 진단 및 고도화 접근이 유효한 이유가 여기에 있습니다.
다섯 번째 함정은 내부 아키텍트를 단수로 두는 것입니다. 핵심 인력 한 명에게 모든 아키텍처 지식이 집중되면, 그 사람이 이탈하는 순간 조직은 SI 의존보다 더 위험한 단일 실패점을 갖게 됩니다. 최소 두 명 이상이 아키텍처 결정 로그와 기술 부채 레지스트리에 동등하게 접근하고 검토할 수 있어야 합니다.
앞으로의 관점
지금 SI 의존도를 방치하는 조직은 5년 후 Agentforce, Data Cloud, 그 다음에 나올 어떤 신규 레이어를 도입하든 같은 문제를 반복할 것입니다. 신규 기술 도입 자체가 리스크를 만드는 것이 아니라, 그 기술을 얹을 기반이 이미 통제 불가능한 상태이기 때문입니다. 반대로 지금 아키텍처 결정권을 재배치하고 지식 문서화 체계를 세운 조직은, 다음 플랫폼 전환기마다 협상력과 실행 속도 두 가지를 모두 확보하게 됩니다.
핵심 정리
- SI 의존도 줄이기는 계약 문제가 아니라 아키텍처 결정권 재배치 문제이며, 전략적 결정과 구현 실행을 명확히 분리해야 합니다.
- 기술 부채 레지스트리를 분기별로 운영하지 않으면 사람이 바뀔 때마다 조직의 아키텍처 지식이 원점으로 돌아갑니다.
- 완전한 SI 제거보다 산출물 기반 계약과 지식 이전 조항을 명시한 하이브리드 운영 모델이 현실적으로 더 안정적입니다.
- 90일 내 조직 정상화가 가능했던 사례들은 대부분 SI를 즉시 배제하지 않고 내부 검증 레이어를 먼저 세운 경우입니다.
- Agentforce나 Data Cloud 같은 신규 이니셔티브 도입 시점은 아키텍처 소유권을 재정의할 최적의 기회이며, 이 시점을 놓치면 의존 구조가 새 레이어에 그대로 복제됩니다.
