Salesforce 멀티클라우드 통합 프로젝트의 상당수가 같은 지점에서 비용이 부풀어 오릅니다. 팀은 MuleSoft(뮬소프트)를 살지 말지부터 논의하고, 라이선스를 확보한 다음에야 어떤 연결을 어떻게 이을지 그리기 시작합니다. 문제는 도구 선택이 아닙니다. 문제는 통합 패턴을 정하는 순서입니다. 패턴을 먼저 그리지 않고 도구를 사면, 비싼 플랫폼으로 잘못된 패턴을 구현하게 됩니다. 이 글은 Salesforce를 AWS, Azure, 네이버클라우드, 그리고 on-prem 레거시 시스템과 잇는 통합에서 어떤 패턴을 언제 써야 하는지, 한국 엔터프라이즈가 무엇을 먼저 진단해야 하는지를 아키텍처 관점에서 정리합니다.
대기업 IT 환경에서 Salesforce는 혼자 동작하지 않습니다. 주문은 ERP에, 정산은 별도 회계 시스템에, 고객 행동 데이터는 데이터 레이크에, 인증은 그룹사 통합 인증에 있습니다. 이 시스템들을 잇는 일을 단순한 배관 작업으로 보면, 처음 몇 개 연결은 빠르게 붙지만 연결 수가 늘수록 손댈 수 없는 거미줄이 됩니다. 통합은 배관이 아니라 설계입니다.
도구가 아니라 패턴이 먼저입니다
통합을 시작할 때 첫 질문은 “어떤 도구를 살 것인가”가 아닙니다. 첫 질문은 “각 연결이 어떤 성격인가”입니다. 모든 연결은 두 축으로 나뉩니다. 동기인가 비동기인가, 그리고 실시간인가 배치인가. 이 두 축을 각 연결마다 정해 두면, 도구 선택은 그 뒤에 자연스럽게 따라옵니다.
동기 연결은 호출한 쪽이 응답을 기다립니다. 사용자가 화면에서 “재고 확인” 버튼을 누르고 결과를 즉시 봐야 한다면, 그 연결은 동기여야 합니다. 비동기 연결은 호출한 쪽이 기다리지 않습니다. 주문이 생성되면 ERP에 알리되, Salesforce는 ERP의 처리 완료를 화면에서 기다리지 않습니다. 이 구분이 중요한 이유는 장애가 번지는 방식이 다르기 때문입니다. 동기 연결에서는 외부 시스템이 느려지면 Salesforce 사용자도 함께 느려집니다. 한 레거시 시스템의 응답 지연이 화면 전체의 멈춤으로 보입니다. 비동기 연결은 외부 시스템이 잠시 멈춰도 Salesforce는 자기 일을 계속합니다.
실무에서 가장 흔한 실수는 모든 연결을 동기로 묶는 것입니다. 구현이 단순해 보이기 때문입니다. 하지만 동기 연결 다섯 개가 한 트랜잭션에 엮이면, 그중 가장 느린 시스템이 전체 응답 시간을 결정합니다. 가장 약한 고리가 전체 속도를 정합니다. 프로덕션에서 한 시스템이 점검에 들어가면 Salesforce의 핵심 화면이 멈추는 사고가 여기서 나옵니다. 그래서 원칙은 분명합니다. 사용자가 결과를 즉시 봐야 하는 흐름만 동기로 두고, 나머지는 모두 비동기로 분리합니다.
패턴별로 무엇을 언제 쓰는가
Salesforce는 통합을 위한 여러 기능을 제공합니다. 각각은 특정 패턴을 위해 만들어졌고, 잘못된 자리에 쓰면 비싼 대가를 치릅니다. 네 가지를 패턴 기준으로 정리합니다.
첫 번째는 Platform Events(플랫폼 이벤트)입니다. 이벤트 기반 통합의 핵심 도구입니다. 어떤 일이 생겼다는 사실을 발행하면, 그 사실에 관심 있는 시스템들이 각자 구독해서 처리합니다. 발행한 쪽은 누가 듣는지 알 필요가 없습니다. 주문 생성, 상태 변경, 결제 완료처럼 “일이 일어났다”는 신호를 여러 시스템에 동시에 알려야 할 때 적합합니다. 비동기이고 느슨하게 결합되므로, 새 시스템을 통합 경로에 추가할 때 기존 발행 로직을 고치지 않아도 됩니다. AWS의 EventBridge나 Azure의 Event Grid와 묶으면, Salesforce에서 발행한 이벤트가 클라우드 전반의 워크플로를 깨웁니다.
두 번째는 External Services(외부 서비스)입니다. 외부 REST API를 OpenAPI 명세로 등록하면, Salesforce가 그 API를 Flow에서 호출할 수 있는 액션으로 만들어 줍니다. 코드 없이 동기 호출을 붙일 때 빠릅니다. 다만 동기 호출이므로, 외부 API가 느리거나 불안정하면 그 부담이 Salesforce 트랜잭션에 그대로 실립니다. 외부 서비스가 안정적이고 응답이 빠른 경우, 그리고 호출 빈도가 governor limit 안에 들어오는 경우에 적합합니다.
세 번째는 API 게이트웨이를 거친 통합입니다. 연결할 시스템이 늘어나고, 인증과 속도 제한, 로깅, 변환을 한곳에서 통제해야 할 때 게이트웨이 계층이 필요해집니다. 여기서 MuleSoft 같은 통합 플랫폼이 의미를 가집니다. MuleSoft는 단순한 커넥터가 아니라 API를 자산으로 관리하는 계층입니다. 연결이 열 개를 넘고, 같은 백엔드를 여러 채널이 재사용하며, SI 여러 곳이 동시에 손대는 환경이라면 게이트웨이의 투자 대비 효과가 분명합니다. 반대로 연결이 두세 개뿐인데 MuleSoft를 사면, 도구가 문제보다 큽니다.
네 번째는 데이터 통합입니다. 실시간 호출이 아니라 대량의 데이터를 주기적으로 합쳐야 할 때 Data Cloud(데이터 클라우드)가 답이 됩니다. Data Cloud의 Data Streams는 외부 원천에서 데이터를 끌어와 Salesforce 안에서 하나의 고객 뷰로 묶습니다. 여기서 Identity Resolution(아이덴티티 해소)이 흩어진 레코드를 한 사람으로 정리하는데, 이 부분의 설계는 통합 전체의 데이터 품질을 좌우합니다. 고객 360을 어떻게 묶을지는 Data Cloud Identity Resolution의 설계 원칙에서 더 깊이 다룹니다.
인증과 보안은 연결만큼 중요합니다
통합을 이야기할 때 데이터 흐름에는 신경을 쓰면서 인증을 뒤로 미루는 경우가 많습니다. 실제로는 인증 설계가 통합의 절반입니다. 시스템 사이를 오가는 호출은 누가, 어떤 권한으로 호출하는지가 매번 검증돼야 합니다.
SSO(통합 인증)는 사용자 경험만의 문제가 아닙니다. AWS, Azure, 네이버클라우드, 그리고 Salesforce가 같은 신원 체계를 공유해야, 각 시스템이 호출자를 신뢰할 근거가 생깁니다. 시스템 간 호출에는 보통 OAuth 2.0의 client credentials 흐름이나 JWT 기반 인증을 씁니다. 사람이 아니라 시스템이 호출하므로, 토큰의 발급과 회전, 만료를 자동화해 두지 않으면 운영 단계에서 인증 실패가 산발적으로 터집니다. 만료된 토큰 하나가 야간 배치 전체를 멈추는 일이 드물지 않습니다.
여기서 한국 대기업 환경의 제약이 들어옵니다. 그룹사가 자체 통합 인증 체계를 운영하는 경우가 많고, Salesforce를 그 체계에 연동해야 합니다. 이 연동을 통합 프로젝트 초기에 합의하지 않으면, 기술 연결이 다 끝난 뒤 인증 단계에서 다시 몇 주를 씁니다. 보안팀이 호출 경로와 토큰 저장 위치를 검토할 수 있게, 인증 흐름을 처음부터 문서로 그려 두는 편이 빠릅니다.
한국 엔터프라이즈가 먼저 진단할 것
기술 패턴이 정리돼도 프로덕션 승인이 나지 않는 경우가 많습니다. 한국 대기업과 SI 통합 프로젝트에는 고유한 제약이 있습니다.
첫째는 데이터 국내 보관입니다. 금융과 공공, 일부 산업에서는 고객 데이터의 국내 보관이 요건입니다. 이 때문에 네이버클라우드가 통합 경로에 들어옵니다. Salesforce와 글로벌 클라우드, 그리고 국내 보관용 네이버클라우드 사이에서 어떤 데이터가 어디에 머무는지를 데이터 흐름도로 그려 두지 않으면, 보안 검토 단계에서 통합 설계를 다시 손봐야 합니다. 어떤 데이터는 국외로 나가도 되고 어떤 데이터는 국내에 머물러야 하는지를 연결마다 표시하는 작업이 초기에 필요합니다.
둘째는 SI 인수인계입니다. 대형 통합 프로젝트는 보통 SI 업체가 구축하고, 운영은 내부 팀이나 다른 업체가 맡습니다. 통합 경로가 복잡할수록 인수인계의 공백이 위험해집니다. 어느 연결이 무엇에 의존하는지, 장애가 났을 때 어디부터 봐야 하는지가 구축 팀의 머릿속에만 있으면, 운영 단계에서 작은 변경 하나가 연쇄 장애를 부릅니다. 통합 아키텍처 문서, 연결 인벤토리, 그리고 장애 대응 절차를 구축 단계의 산출물로 명시해 두어야 합니다.
셋째는 변경 영향 분석입니다. 멀티클라우드 통합에서는 한 시스템의 변경이 다른 시스템으로 번집니다. ERP의 필드 하나가 바뀌면 그 데이터를 받는 Salesforce 흐름이 영향을 받고, 다시 그 데이터를 발행하는 이벤트의 구독자들이 영향을 받습니다. 이 의존 관계를 추적할 수 없으면, 작은 변경마다 전체 회귀 시험을 돌려야 합니다. 그래서 연결을 느슨하게 결합하는 이벤트 기반 패턴이 장기적으로 변경 비용을 낮춥니다. Salesforce 거버넌스와 통합 운영 모델을 함께 설계하는 일이 여기서 의미를 가집니다. 진단의 범위와 산출물은 Data 360 데이터 기반 진단에 정리해 두었습니다.
핵심 정리
Salesforce 멀티클라우드 통합의 성패는 어떤 도구를 사느냐가 아니라 어떤 패턴을 어디에 쓰느냐에서 갈립니다. 정리하면 다음과 같습니다.
- 도구보다 패턴이 먼저입니다. 각 연결이 동기인지 비동기인지, 실시간인지 배치인지를 그린 다음 도구를 고릅니다.
- 동기는 사용자가 화면에서 응답을 기다려야 하는 흐름에만 씁니다. 나머지는 Platform Events로 비동기 분리해 장애 전파를 막습니다.
- 연결이 많고 재사용이 잦을 때만 MuleSoft 같은 게이트웨이 계층이 값을 합니다. 두세 개 연결에는 과합니다.
- 인증은 통합의 절반입니다. SSO와 시스템 간 토큰 흐름을 초기에 설계하고 보안팀과 합의합니다.
- 한국 환경에서는 데이터 국내 보관과 네이버클라우드 경로, SI 인수인계를 통합 설계 단계에서 먼저 정합니다.
지금의 통합 설계가 3년 뒤의 운영 비용을 결정합니다. 패턴을 먼저 정하고 느슨하게 결합한 조직은 새 시스템을 더할 때마다 기존 경로를 재사용합니다. 반대로 도구부터 사고 연결을 동기로 묶어 온 조직은 시스템이 늘 때마다 같은 장애를 다시 만납니다. 한쪽은 시간이 지날수록 통합이 단단해지고, 다른 쪽은 손댈수록 부서지기 쉬워집니다. 데모를 통과하는 통합이 아니라 프로덕션에서 버티는 통합을 목표로 한다면, 도구 비교 전에 연결의 성격과 데이터 흐름 지도부터 그려야 합니다.
