SI가 구축한 Salesforce를 2년쯤 운영한 조직은 비슷한 증상을 호소합니다. 필드 하나를 바꾸는 데도 외부 견적을 받아야 하고, 분기마다 유지보수 계약 금액이 오르며, 정작 무엇이 어떻게 설정돼 있는지 내부에는 아는 사람이 없습니다. 대부분은 이것을 비용 문제로 봅니다. 진짜 원인은 다릅니다. Salesforce 거버넌스, 즉 누가 무엇을 어떤 절차로 바꾸는지를 정한 운영 모델이 처음부터 없었던 것입니다. 종속은 기술이 만든 것이 아니라 운영 모델의 공백이 만든 결과입니다.
이 글은 SI 주도로 구축한 Salesforce에서 의존도가 커지는 구조적 원인을 짚고, Center of Excellence(전사 운영 조직), 권한 체계, 릴리즈와 변경 관리, 샌드박스 전략, DevOps를 어떻게 엮어 인하우스 역량을 세울지 정리합니다. 그리고 무엇을 내부로 가져오고 무엇을 외부에 남길지에 대해 분명한 입장을 제시합니다.
의존도는 어디서 자라는가
SI가 구축을 맡는 것은 합리적인 선택입니다. 초기 구축은 짧은 기간에 깊은 전문성이 필요하고, 내부에 그 인력을 상시로 두는 것은 비효율적입니다. 문제는 구축이 끝난 다음입니다. 인수인계 문서가 화면 캡처 묶음에 그치고, 운영 권한이 여전히 SI 계정에 남아 있으며, 변경 요청은 모두 외주 티켓으로 처리됩니다. 이 상태가 굳으면 작은 변경 하나에도 외부 일정과 견적이 끼어듭니다.
여기서 비용이 두 갈래로 자랍니다. 첫째는 직접 비용입니다. 자체로 처리할 수 있는 설정 변경까지 외부 인건비로 나가고, 단가는 시간이 지날수록 협상력이 SI 쪽으로 기울며 오릅니다. 둘째는 더 비싼 간접 비용입니다. 변경에 시간이 걸리니 현업의 개선 요청이 쌓이고, 쌓인 요청은 우회로 처리됩니다. 누군가 보고서를 수기로 만들고, 누군가 스프레드시트로 데이터를 보정합니다. 시스템은 점점 현실과 멀어지고, 그 격차를 메우는 비용은 어디에도 집계되지 않습니다.
구조를 보면 종속의 핵심은 코드나 설정이 아닙니다. 핵심은 변경 권한과 변경 지식이 외부에 있다는 사실입니다. 같은 시스템이라도 내부가 권한과 지식을 쥐고 있으면 의존도는 낮고, 외부가 쥐고 있으면 높습니다. 그래서 의존도를 줄이는 일은 시스템을 다시 만드는 일이 아니라, 권한과 지식의 소유를 옮기는 일입니다.
인하우스와 SI의 경계를 어떻게 그을 것인가
여기서 분명한 입장을 밝힙니다. 운영의 통제권은 인하우스가 쥐고, 대규모 신규 구축과 깊은 전문 영역은 SI에 맡기는 것이 맞습니다. 모든 것을 내부로 가져오려는 시도는 인력 비용으로 실패하고, 모든 것을 외부에 두는 관행은 의존도로 실패합니다. 경계를 분명히 긋는 것이 둘 다 피하는 길입니다.
내부가 반드시 쥐어야 하는 것은 세 가지입니다. 권한 체계, 즉 누가 무엇을 볼 수 있고 바꿀 수 있는지를 정하는 Profile(프로파일)과 Permission Set(권한 집합)의 설계입니다. 다음은 변경 승인 절차로, 어떤 변경이 누구의 결재를 거쳐 어떤 환경을 통과해 프로덕션에 올라가는지를 정하는 규칙입니다. 마지막은 릴리즈 관리로, 변경을 묶어 안전하게 배포하는 파이프라인의 운영입니다. 이 세 가지는 조직의 통제력 그 자체이므로 외부에 맡기면 의존도가 다시 자랍니다.
반대로 외부에 맡겨도 무방한 것도 있습니다. 새로운 클라우드의 대규모 도입, 복잡한 통합 아키텍처 설계, 단기간에 깊은 전문성이 필요한 일회성 프로젝트가 그렇습니다. 다만 이 경우에도 한 가지 조건이 붙습니다. 산출물의 설계 의도와 운영 방법이 내부 표준 문서로 흡수되어야 하고, 운영 권한은 프로젝트 종료와 함께 내부로 회수되어야 합니다. 구축은 외부가 하더라도, 그 결과를 운영하는 손은 내부에 남아야 합니다.
이 경계를 한 문장으로 정리하면 이렇습니다. 일상적으로 반복되는 변경은 내부가, 드물지만 깊은 구축은 외부가 맡되, 통제권은 언제나 내부에 둡니다. 한국 대기업의 SI 주도 관행에서는 통제권까지 외부에 두는 경우가 많은데, 바로 그 지점이 의존도가 굳는 자리입니다.
운영 모델을 세우는 다섯 기둥
의존도를 줄이는 운영 모델은 다섯 기둥으로 구성됩니다. 하나씩 보겠습니다.
첫째, Center of Excellence입니다. 변경 요청이 들어오면 누가 우선순위를 정하고, 무엇이 표준에 맞는지 누가 판단하는가. 이 역할이 없으면 모든 요청이 동등한 무게로 SI에 흘러갑니다. CoE는 비즈니스 담당자, 관리자(Administrator), 아키텍트가 모여 변경의 가치와 위험을 함께 판단하는 작은 조직입니다. 대기업이라면 부서마다 흩어진 Salesforce 요구를 한곳에서 조율하는 역할이기도 합니다. CoE가 자리 잡으면 외주로 나가던 판단이 내부로 돌아옵니다.
둘째, 권한 체계입니다. 사람이 늘고 부서가 바뀔 때마다 권한을 즉석에서 부여해 온 조직은, 시간이 지나면 누가 무엇을 볼 수 있는지 아무도 설명하지 못합니다. Profile은 최소한으로 두고 Permission Set으로 기능 권한을 조립하는 모델이 표준입니다. 권한 변경이 내부 절차로 처리될 수 있어야, 인사 이동마다 SI에 요청하는 종속에서 벗어납니다.
셋째, 릴리즈와 변경 관리입니다. 변경을 모아 정해진 주기로 배포하고, 각 변경이 어떤 환경을 거쳐 왔는지 추적할 수 있어야 합니다. 변경이 즉흥적으로 프로덕션에 반영되는 조직은, 사고가 날 때마다 외부 전문가를 부르는 데 익숙해집니다. 변경 관리가 절차화되면 사고 자체가 줄고, 내부가 직접 대응할 수 있는 범위가 넓어집니다.
넷째, 샌드박스 전략입니다. 개발, 통합 테스트, 사용자 검증, 프로덕션으로 이어지는 환경의 층위를 정하고, 각 층에서 무엇을 확인하는지 규칙을 세웁니다. 샌드박스가 하나뿐이거나 용도가 뒤섞인 조직은, 안전하게 시험할 곳이 없어 모든 변경을 외부에 맡기게 됩니다. 환경의 층위가 분명하면 내부 인력도 위험 없이 변경을 시도할 수 있습니다.
다섯째, DevOps입니다. 변경을 버전으로 관리하고 환경 사이의 배포를 자동화하는 파이프라인입니다. Salesforce DevOps Center나 그에 준하는 도구로 메타데이터를 추적하면, 누가 무엇을 언제 바꿨는지가 남습니다. 이 기록이 곧 인수인계 문서를 대신하고, SI가 떠난 뒤에도 내부가 시스템을 이해할 수 있게 합니다. 앞의 네 기둥이 절차라면, DevOps는 그 절차를 떠받치는 기술 기반입니다.
이 다섯 기둥은 따로 떨어진 항목이 아니라 한 몸입니다. CoE가 우선순위를 정하고, 권한 체계가 누가 손댈 수 있는지를 정하며, 변경 관리가 절차를 강제하고, 샌드박스가 시험할 곳을 주고, DevOps가 그 전부를 기록합니다. 하나라도 빠지면 나머지가 헐거워집니다. 권한 체계 없이 DevOps만 도입하면 누구나 배포할 수 있는 위험한 자동화가 되고, CoE 없이 변경 관리만 두면 절차는 있으나 우선순위가 없는 병목이 됩니다.
인하우스 역량은 어떻게 키우는가
운영 모델을 세웠다고 해서 내부에 역량이 저절로 생기지는 않습니다. 역량은 사람과 지식으로 쌓입니다. 여기에는 의도된 설계가 필요합니다.
먼저 내부에 누구를 둘지 정합니다. 최소한의 인하우스 구성은 시스템 전반을 책임지는 Salesforce Administrator 한 명과, 아키텍처 결정을 내릴 수 있는 시니어 한 명입니다. 대기업이라면 여기에 비즈니스 분석가가 더해집니다. 이 인력이 SI와 함께 일하면서 설계 의도를 흡수하는 것이 핵심입니다. 처음부터 모든 일을 내부가 하지 않아도 됩니다. SI가 일하는 방식을 곁에서 보고, 문서로 남기고, 점차 더 많은 변경을 직접 처리해 가는 점진적 전환이 안전합니다.
다음은 지식의 이전입니다. 인수인계는 프로젝트 막바지의 한 번짜리 행사가 아니라, 구축 내내 이어지는 과정이어야 합니다. SI가 내리는 설계 결정과 그 근거를 그때그때 내부 표준 문서로 적어 두면, 그 문서가 곧 인하우스 역량의 토대가 됩니다. DevOps 파이프라인의 변경 기록이 이 문서를 보완합니다. 무엇이 왜 그렇게 설정됐는지가 남아 있어야, SI가 떠난 뒤에도 시스템이 이해 가능한 상태로 유지됩니다.
이 전환은 보통 18개월 안팎에 걸쳐 일어납니다. 처음 몇 달은 내부가 SI를 관찰하고, 다음 몇 달은 함께 변경을 처리하며, 그 뒤로는 일상 변경을 내부가 주도하고 SI는 자문과 대규모 구축에만 관여하는 구조로 좁혀 갑니다. 이 곡선을 의도적으로 설계하지 않으면, 18개월 뒤에도 첫날과 같은 의존 상태에 머뭅니다. 더 깊은 진단과 운영 모델 설계는 Salesforce 조직 현황 진단과 운영 모델 설계에서 다룹니다.
이 모델은 새로 구축하는 조직에만 해당하지 않습니다. 이미 SI 주도로 운영 중인 조직도 같은 순서로 통제권을 회수할 수 있습니다. 차이는 출발점뿐입니다. 신규 조직은 처음부터 경계를 긋고, 기존 조직은 굳어 버린 경계를 다시 긋습니다. 프로덕션 전환 단계에서 이 운영 모델을 함께 설계하는 일이 왜 중요한지는 Agentforce 도입에서 파일럿이 멈추는 이유에서 다룬 인수인계 논의와 같은 맥락입니다.
핵심 정리
SI 주도 구축이 잘못된 것이 아닙니다. 잘못된 것은 운영 권한과 변경 지식까지 외부에 남겨 둔 운영 모델의 공백입니다. 정리하면 다음과 같습니다.
- 의존도는 시스템이 아니라 운영 권한과 변경 지식의 위치에서 옵니다. 재구축이 아니라 소유권 이전이 먼저입니다.
- 일상 변경의 통제권은 내부가 쥐고, 대규모 신규 구축과 깊은 전문 영역은 SI에 맡깁니다. 통제권만은 언제나 내부에 둡니다.
- 운영 모델은 CoE, 권한 체계, 변경 관리, 샌드박스 전략, DevOps 다섯 기둥으로 세웁니다. 하나라도 빠지면 나머지가 헐거워집니다.
- 인하우스 역량은 사람과 지식의 점진적 이전으로 쌓입니다. 인수인계는 막바지 행사가 아니라 구축 내내 이어지는 과정이어야 합니다.
지금의 운영 모델이 3년 뒤의 유지보수 비용을 결정합니다. 통제권을 내부에 둔 조직은 변경이 늘어도 한계 비용이 거의 늘지 않고, 외부에 둔 조직은 변경마다 비용과 일정이 따라붙습니다. 한쪽은 시간이 지날수록 가벼워지고, 다른 쪽은 무거워집니다. SI가 떠나도 흔들리지 않는 조직을 목표로 한다면, 가장 먼저 그릴 것은 새 화면이 아니라 권한 체계와 변경 절차의 지도입니다.
