Salesforce 연동이 프로토콜 때문에 실패하는 일은 거의 없습니다. 인증은 이미 풀린 문제이고, 레코드 하나를 등록하는 것도 이미 풀린 문제입니다. 프로젝트를 끝장내는 것은 하루치 요청 할당량과 데이터 모델의 형태이며, 이 두 가지는 대개 가동 후 3주쯤 지나 야간 작업이 오류를 뱉기 시작하고 테스트에서는 왜 멀쩡했는지 아무도 설명하지 못하는 시점에 발견됩니다.

패턴은 예측이 가능할 만큼 일정합니다. 개발자가 Developer Edition 조직을 상대로 만들고, 전부 통과하고, 고객이 검수를 승인합니다. 그다음 그 코드는 마케팅 커넥터와 데이터 웨어하우스 추출 작업과 2019년부터 돌아가던 Apex 트리거가 이미 함께 살고 있는 운영 조직을 만납니다. 넉넉해 보이던 요청 예산은 다른 사람들이 이미 쓰고 있는 공동 지갑이었던 것으로 드러납니다.

이 글은 그 놀라움을 앞쪽으로 끌어옵니다. 어떤 API를 써야 하는지, 할당량은 어떻게 계산되는지, 내가 쓰지 않은 코드를 내 쓰기 작업이 깨울 때 무슨 일이 벌어지는지, 인증은 어떻게 바뀌었는지, 그리고 되돌리는 데 비용이 큰 데이터 모델 결정은 무엇인지입니다.

Salesforce 연동의 성패는 무엇이 가릅니까? 프로토콜이 아니라 할당량과 데이터 모델입니다. 하루치 API 요청 할당량은 조직 전체가 공유하며 에디션과 라이선스 수에서 나옵니다. 그래서 얌전하게 만든 연동이 같은 조직의 형편없는 연동 때문에 굶을 수 있습니다. 첫 줄부터 일괄 처리를 전제로 설계하고, 무엇이든 쓰기 전에 외부 ID와 upsert를 합의하고, 보내는 모든 레코드가 남의 Apex를 실행시킨다고 가정하십시오.

Salesforce 연동이 반드시 맞혀야 하는 것

네 가지가 있고, 무게는 서로 다릅니다.

첫째는 할당량입니다. 코드가 보내는 모든 동기 호출은 조직 전체가 공유하는 하나의 하루치 할당량에서 빠져나갑니다. 그 조직을 쓰는 다른 모든 소비자와 같은 지갑을 나눠 씁니다.

둘째는 그 아래에 있는 플랫폼입니다. Salesforce는 HTTP 인터페이스가 달린 데이터베이스가 아닙니다. 애플리케이션 플랫폼이고, 여러분의 쓰기 작업은 여러분의 프로젝트를 들어본 적도 없는 관리자가 설정해 둔 트리거, 플로우, 검증 규칙, 중복 규칙, 롤업 요약을 실행합니다.

셋째는 데이터 모델입니다. Lead, Contact, Account, Opportunity는 서로 바꿔 쓸 수 없고, 이들 사이의 전환은 단방향이며 부작용을 남기고, 잘못 고르면 코드 수정이 아니라 데이터 이행이 됩니다.

넷째는 동일성입니다. 내 시스템과 Salesforce가 어떤 레코드가 어떤 레코드인지 어떻게 합의하느냐의 문제입니다. 이걸 놓치면 기계의 속도로 중복이 생깁니다. 이 글의 나머지는 전부 이 네 가지 중 하나에서 파생됩니다.

API 지형도와 실제로 필요한 것

Salesforce는 커다란 API 계열을 공개하고 있습니다. 권위 있는 목록은 Salesforce API 색인이며, 아래 이름들은 기억이 아니라 거기에서 가져온 것입니다.

REST API와 SOAP API

REST API는 레코드 모양을 한 모든 작업의 기본 선택지입니다. 생성, 조회, 수정, 삭제, 쿼리, describe. 웹 폼이 Lead를 쓰는 경우, 포털이 고객의 열린 케이스를 읽는 경우, 그리고 처리량이 적은 대화형 경로에는 이쪽이 정답입니다.

SOAP API는 같은 일을 WSDL로 하고 지금도 살아 있습니다. 상당수의 기업용 미들웨어가 이것을 기본으로 말하기 때문이고, 클라이언트를 생성할 수 있는 강한 타입의 계약을 주기 때문입니다. 사람들이 자주 틀리는 지점은 SOAP은 낡았고 REST는 현대적이라고 단정하는 것입니다. 둘 다 현행이며, SOAP의 create()와 update()는 각각 최대 200건의 레코드를 받습니다. 전송 형식보다 이쪽이 더 크게 작용합니다.

Bulk API 2.0

Bulk API 2.0은 물량을 다루기 위한 비동기 작업 기반 경로입니다. CSV를 올리면 Salesforce가 잘라서 뒤에서 처리하고, 결과는 폴링으로 가져옵니다. Salesforce의 Bulk API 제한은 이동하는 24시간 기준 최대 15,000배치, 같은 구간에서 최대 1.5억 건의 레코드 적재, 그리고 작업 파일 상한 150 MB를 허용합니다.

사람들이 자주 틀리는 지점은 Bulk을 나중에 손볼 튜닝 항목으로 취급하는 것입니다. 이것은 다른 프로그래밍 모델입니다. 결과는 비동기로, 레코드 단위로 돌아오며, 코드는 처음부터 그 방식으로 결과를 받아야 합니다.

Composite와 sObject Collections

이 둘은 REST API에서 가치가 가장 높고 가장 적게 쓰이는 부분입니다. composite 요청은 한 번의 호출에 최대 25개의 하위 요청을 담고, 그중 최대 5개를 쿼리나 sObject Collections 작업으로 쓸 수 있으며, 뒤쪽 하위 요청은 앞쪽이 돌려준 ID를 참조할 수 있습니다. sObject Collections는 같은 오브젝트의 레코드를 한 번의 요청으로 최대 200건까지 처리합니다. 둘 다 하루치 할당량에 대해 호출 한 번으로 계산되며, 그게 바로 핵심입니다.

사람들이 자주 틀리는 지점은 이것들이 있다는 사실 자체를 모른다는 것입니다. Account를 만들고, 다음에 Contact을 만들고, 다음에 Opportunity를 만드는 세 번의 순차 호출은 한 번의 composite 요청보다 할당량을 세 배 쓰고 지연도 세 배입니다.

Streaming, 변경 데이터 캡처, Pub/Sub

Streaming API는 PushTopic, 일반 이벤트, 플랫폼 이벤트, 변경 이벤트를 위한 CometD 기반 구독 채널입니다. 변경 데이터 캡처는 레코드가 생성, 수정, 삭제, 복원될 때 거의 실시간으로 알림을 발행해서, 외부 저장소가 폴링 없이 Salesforce를 따라갈 수 있게 합니다. Platform Events는 여러분이 직접 정의하는 사용자 이벤트입니다.

Pub/Sub API는 발행, 구독, 스키마 조회, 토픽 탐색을 하나의 API로 합친 더 새로운 gRPC 및 HTTP/2 인터페이스이며, 페이로드는 JSON이 아니라 Avro입니다. 새로 이벤트 기반으로 만든다면 여기서 시작하십시오.

사람들이 자주 틀리는 지점은 이벤트를 보장된 피드로 취급하는 것입니다. 이벤트는 대사 작업을 대신하지 못하며, 그 이유는 다음 절에 있습니다.

API 요청 한도가 진짜 제약이다

이 절이 아키텍처를 결정하며, 대개는 설계가 끝난 뒤에야 읽히는 절이기도 합니다.

하루치 할당량은 어떻게 계산되는가

Salesforce의 API 요청 한도 문서는 할당량을 사용자별이나 애플리케이션별이 아니라 에디션과 라이선스 수로 정합니다. API 접근이 포함된 Enterprise와 Professional 에디션은 100,000회에 더해 Salesforce 또는 Salesforce Platform 라이선스 1개당 1,000회를 받습니다. Unlimited와 Performance 에디션은 100,000회에 더해 라이선스 1개당 5,000회입니다. Developer Edition은 일괄 15,000회, Full 샌드박스는 5,000,000회입니다.

여기서 두 가지가 따라옵니다. 사용자 60명짜리 Enterprise 조직은 하루 대략 160,000회를 쓰며, 무한 공급이 아닙니다. 그리고 할당량이 라이선스에서 나오는 이상 이를 늘리는 방법은 사용자 라이선스를 더 사거나 추가 API 호출을 사는 것 둘뿐이고, 둘 다 Salesforce의 Your Account 앱을 통해 구매합니다.

무엇이 계산되고, 다 쓰면 무슨 일이 생기는가

할당량은 24시간 동안 그 조직에 들어온 모든 호출의 합계로 측정되며, REST API, SOAP API, Bulk API, Bulk API 2.0, 그리고 대부분의 Connect REST API 호출을 함께 포함합니다. 모바일 앱처럼 특정 Salesforce 연결 앱에서 오는 호출은 제외됩니다.

사람을 잡는 것은 바로 그 합산입니다. 여러분의 연동에는 자기 몫의 예산이 없습니다. 리포팅 커넥터, 마케팅 플랫폼, 그 조직에 있는 다른 모든 연동과 하나의 예산을 나눠 쓰며, 30초마다 폴링하는 형편없는 소비자 하나가 그것을 다 마셔 버리고 아주 잘 동작하고 있는 코드를 굶길 수 있습니다.

조직이 할당량을 넘기면 요청은 403과 REQUEST_LIMIT_EXCEEDED로 실패합니다. 유료 운영 조직에는 강제 적용 전에 어느 정도의 초과가 허용되지만, 체험판 조직과 Developer Edition에는 그런 유예가 없습니다. 유예가 없다고 보고 설계하십시오.

설계를 확정하기 전에 측정하라

코드를 쓰기 전에 조직의 할당량과 현재 하루 소비량을 관리자에게서 받아 두십시오. REST API에는 그것을 위한 조직 한도 리소스가 있습니다. 기존 소비자들이 이미 70%를 쓰고 있다면 레코드 단위 동기 연동은 성립하지 않으며, 튜닝으로 성립하게 만들 수도 없습니다.

일괄 처리는 최적화가 아니라 설계 결정이다

할당량이 유한하고 공유된다는 사실을 받아들이는 순간, 설계는 저절로 정해집니다.

단건 호출을 반복문으로 돌리지 마십시오. Contact 5,000건을 하나씩 만드는 작업은 5,000회를 씁니다. 같은 5,000건을 sObject Collections로 요청당 200건씩 보내면 25회입니다. 이 200배라는 계수가 중간 규모 조직의 할당량 안에 들어가는 연동과 들어가지 못하는 연동을 가릅니다.

작업이 목록이 아니라 그래프 모양일 때는 Composite을 쓰십시오. 부모와 자식을 한 번의 요청으로 만들면 왕복도 사라지고, ID를 기다리는 동안 코드가 들고 있어야 할 중간 상태도 사라집니다.

트랜잭션이라기보다 적재나 추출에 가까운 것에는 Bulk API 2.0을 쓰십시오. 설계상 비동기이고 사용자에게 동기적인 답을 주지 않으므로 대화형 경로에는 맞지 않습니다.

참조 데이터는 캐시하십시오. 선택 목록 값, 레코드 유형 ID, describe 결과는 좀처럼 바뀌지 않는데도 매 실행마다 이유 없이 다시 조회됩니다. 이 변경 하나만으로 순진하게 만든 연동의 호출량 4분의 1이 사라지는 경우가 흔합니다.

거버너 제한: 내 쓰기가 남의 코드를 실행한다

Salesforce는 고객이 작성한 Apex를 트랜잭션 단위의 엄격한 상한 안에서 실행합니다. 연동에 실제로 걸리는 Apex 거버너 제한은 동기 트랜잭션당 SOQL 쿼리 100건, SOQL이 가져오는 레코드 50,000건, DML 문 150건, DML이 처리하는 레코드 10,000건, 동기 CPU 시간 10초, 힙 6 MB입니다.

그 Apex를 쓴 사람은 여러분이 아닙니다. 그래도 이 제한에 걸립니다. 들어오는 쓰기 작업이 해당 오브젝트에 존재하는 모든 트리거를 실행하는 트랜잭션을 시작하기 때문입니다.

Apex 없이 이해하는 벌크화

이 개념은 Apex 파일을 한 번도 열지 않더라도 알아둘 값어치가 있습니다.

Salesforce는 트리거에 레코드 하나가 아니라 레코드의 컬렉션을 넘깁니다. 제대로 작성된 트리거는 컬렉션 전체를 쿼리 한 번과 업데이트 한 번으로 처리합니다. 언제나 레코드 하나만 받는다고 가정하고 작성된 트리거는 레코드마다 쿼리 한 번과 업데이트 한 번을 실행합니다.

두 번째 트리거는 몇 년 동안 완벽하게 동작합니다. 사용자는 화면에서 한 건씩 저장하기 때문입니다. 그러다 여러분의 연동이 한 번의 요청으로 200건을 보내면 트리거는 쿼리를 200번 실행하고, 쿼리 100건 상한을 뚫고 나가며, 배치 전체가 실패합니다.

Bulk API 2.0은 적재 데이터를 200건 단위 덩어리로, 각각 별개의 트랜잭션으로 처리하므로 이것은 이론상의 이야기가 아닙니다. 이력이 쌓인 조직에 처음 대량 적재를 할 때 나오는 표준적인 모습입니다.

어떻게 대응할 것인가

납기를 약속하기 전에, 쓰기를 수행할 모든 오브젝트의 트리거와 플로우를 감사하십시오. 벌크화되지 않은 트리거가 있다면 누군가 고쳐야 하고, 그 누군가에게는 Apex 역량과 배포 일정이 필요합니다. 견적의 한 항목으로 잡으십시오.

수정이 범위 밖이라면 배치 크기를 줄이십시오. 요청당 200건은 최댓값이지 의무가 아니며, 50건으로 낮추면 트리거 작업이 잡히는 동안 출시할 여유가 생기기도 합니다. 할당량을 먹으므로 임시 조치로 다루십시오.

내년에도 동작할 인증

이 영역은 실질적으로 바뀌었고, 공개된 안내 중 상당수는 이제 틀렸습니다.

OAuth 2.0의 사용자 이름과 비밀번호 흐름은 피해야 할 것입니다. 자격 증명을 요청에 그대로 노출하고, 최근 조직에서는 Salesforce가 기본으로 차단하며, 연결 앱에서의 폐지도 예정되어 있습니다. 아직 이것을 쓰는 연동에는 날짜가 붙은 이행 계획이 필요합니다.

사람이 개입하지 않는 서버 대 서버 작업에서 현행 답은 두 가지입니다. 인증서로 어서션에 서명하는 JWT 베어러 흐름과, 소비자 키와 시크릿을 토큰으로 교환하는 클라이언트 자격 증명 흐름입니다. 통합 사용자와 클라이언트 자격 증명으로 REST API 호출하기에 대한 Salesforce의 안내는 이 흐름이 리프레시 토큰을 발급하지 않는다고 명시하며, 따라서 기존 토큰이 만료되면 클라이언트가 새 액세스 토큰을 요청합니다.

연결 앱과 외부 클라이언트 앱

이 모든 것을 담는 그릇은 예전에는 연결 앱이었습니다. 지금은 외부 클라이언트 앱입니다. Salesforce는 Spring ‘26부터 연결 앱 생성이 제한된다고 분명히 밝히고 외부 클라이언트 앱을 권장하며, 이를 보안을 개선하고 패키징 문제를 해결하도록 설계된 새 세대라고 설명합니다.

연동 문서에 “연결 앱을 만드세요"라고 적혀 있다면, 그것은 새 조직에서는 제공되지 않을 수도 있는 경로를 설명하는 것입니다. 작업 범위를 잡기 전에 대상 조직에 어느 쪽이 해당하는지 확인하십시오.

전용 통합 사용자로 실행하고 교체를 계획하라

연동에는 최소 접근 권한의 API 전용 프로필을 가진 자체 사용자를 주십시오. 특정 직원 계정으로 돌리지 마십시오. 그 직원이 퇴사해서 계정이 비활성화되는 순간 연동은 멈춥니다. 가장 나쁜 시점에, 아무 곳도 가리키지 않는 오류와 함께 말입니다.

인증서는 만료되고 시크릿은 교체됩니다. 둘 다 그날이 오기 전까지는 조용하고, 둘 다 연동을 부분이 아니라 통째로 멈춥니다. 만료일은 사람이 관리하는 달력에 넣고, 자격 증명은 시크릿 관리 도구에 두고, 실전에서 필요해지기 전에 샌드박스에서 교체를 연습하십시오.

데이터 모델의 함정

여기가 3주를 잡아먹는 지점입니다. 되돌리려면 코드를 바꾸는 것이 아니라 데이터를 옮겨야 하기 때문입니다.

Lead, Contact, Account, Person Account

Lead는 아직 회사 레코드에 연결되지 않은 미검증 잠재 고객입니다. Contact은 Account에 붙은 사람입니다. Account는 조직입니다. 전환은 Lead를 Account와 Contact으로 바꾸고 선택적으로 Opportunity까지 만들지만, SOAP의 convertLead 호출은 대상의 비어 있는 필드만 덮어쓴다고 명시하고 있어, 공들여 채운 Lead 필드가 기대한 자리에 도착하지 않을 수 있습니다.

Person Account는 이를 더 복잡하게 만듭니다. 소비자 대상 조직은 개인을 Account와 Contact이 합쳐진 형태로 표현하려고 이 기능을 켜며, 법인 Account 모델을 전제로 작성된 연동은 그런 조직에서 손대지 않고는 동작하지 않습니다. 이 사실은 맥 빠질 만큼 규칙적으로 뒤늦게 발견됩니다.

들어온 레코드가 어떤 오브젝트가 되는지는 현업과 문서로 정하십시오. 기술적 결정이 아닙니다.

외부 ID와 upsert

이것이 Salesforce가 주는 유일하게 제정신인 멱등성 장치이며, 협상 대상이 아닌 것으로 다뤄야 합니다. 오브젝트에 외부 ID로 표시한 사용자 정의 필드를 만들고 거기에 여러분 시스템의 기본 키를 저장하십시오. 그러면 upsert 작업, 즉 /sobjects/{Object}/{ExternalIdField}/{Value}에 대한 PATCH를 쓸 수 있습니다. 일치하는 것이 없으면 레코드를 만들고, 정확히 하나 일치하면 갱신합니다. 일치 0건은 201, 1건은 200, 여러 건은 추측하지 않고 300으로 실패합니다.

그 결과는 분명히 말해 둘 값어치가 있습니다. upsert가 있으면 실패한 요청의 재시도가 안전합니다. 없으면 모든 재시도가 잠재적 중복이고, 야간 작업 중 잠깐의 네트워크 끊김이 며칠 단위로 재는 정리 작업으로 바뀝니다.

내 쓰기에 발동하는 규칙들

중복 규칙은 연동이 만드는 레코드를 막거나 경고할 수 있습니다. 검증 규칙은 관리자가 설정한 조건을 만족하지 못한 레코드를 거부합니다. 필수 필드는 출시하고 몇 달 뒤에 추가될 수 있고, 그 순간부터 잘 돌아가던 연동이 모든 레코드에서 실패하기 시작합니다.

이들 중 무엇도 버그가 아닙니다. 조직이 설정한 대로 동작하는 것입니다. 잘못은 거부된 쓰기를 전송 오류로 보고 영원히 재시도하는 것이고, 올바른 대응은 필드 수준의 사유를 붙여 사람에게 보여 주는 것입니다. 같은 범주의 문제를 서드파티 API 연동의 비용과 실패 유형 안내서가 다른 맥락에서 다룹니다.

오류 처리, 멱등성, 재처리

재처리 장치가 없는 연동은 사람이 손으로 데이터를 고치는 일로 바뀝니다. 이것은 예측이 아니라 실제로 일어나는 일입니다.

부분 성공이 정상 상태입니다. sObject Collections는 allOrNone의 기본값이 false이므로 200건짜리 요청이 성공 187건과 실패 13건을 각각의 사유와 함께 돌려줄 수 있고, Bulk API 2.0도 같은 방식으로 레코드 단위 결과를 줍니다. 바깥쪽 HTTP 상태만 확인하는 코드는 레코드를 조용히 흘리면서 성공을 보고합니다.

재시도 전에 실패를 분류하십시오. 행 잠금, 타임아웃, 할당량 소진 같은 일시적 상태는 지수 백오프를 받을 자격이 있습니다. 검증 오류나 필수 필드 누락 같은 결정적 실패는 영원히 똑같이 실패하고, 재시도는 아껴야 할 할당량만 태웁니다.

복구 불가능한 레코드는 페이로드와 오류를 함께 데드 레터 저장소로 보내 사람이 살펴보고 다시 제출할 수 있게 하십시오. 쓰기가 외부 ID를 키로 삼고 있으므로 재제출은 안전합니다. 내 식별자와 Salesforce ID의 대응 관계는 양쪽 모두에 기록하십시오. 6개월 뒤 어떤 고객의 레코드가 왜 틀렸는지 설명해 줄 수 있는 것은 그 로그뿐입니다.

그리고 대사하십시오. 플랫폼 이벤트와 변경 이벤트는 이벤트 버스에 72시간 보관되며, Salesforce의 플랫폼 이벤트 할당량은 하루 전달량을 Enterprise에서 25,000건, Unlimited와 Performance에서 50,000건으로 제한합니다. 레코드 건수와 수정 일시를 주기적으로 비교하면 스트림이 흘린 것을 잡아낼 수 있습니다.

미들웨어냐 직접 연결이냐

점 대 점 직접 연결은 플랫폼 벤더가 인정하는 것보다 더 자주 정답입니다. 하나의 출처, 하나의 대상, 한 방향, 적당한 물량, 안정적인 계약이라면 직접 만들고 라이선스는 건너뛰십시오.

미들웨어가 값을 하는 때는 위상이 더 이상 직선이 아닐 때입니다. 여러 시스템이 데이터를 주고받고, 현업 담당자가 배포 없이 변환을 바꿔야 하고, 각자 따로 고장 나는 시스템들을 가로질러 조율이 필요하고, 중앙 집중식 모니터링과 재시도가 정말로 필요한 경우입니다.

솔직히 말하면 미들웨어는 비용을 없애는 것이 아니라 옮깁니다. 매핑도, 오류 처리도, 운영 지식도 여전히 값을 치러야 하고, 거기에 라이선스와 두 번째 파이프라인과 새로 뽑아야 할 두 번째 역량이 더해집니다. 미들웨어도 여러분의 코드가 부를 바로 그 API를 부르므로 API 할당량은 달라지지 않습니다.

위상이 그것을 요구하기 때문에 고르십시오. 코드가 줄어 보이기 때문이 아니라. 자체 개발과 구매 결정 안내서는 밑단 시스템에 대해 같은 저울질을 다루고, CRM과 ERP 연동 안내서는 다중 시스템 사례를 다룹니다. 논쟁 대신 평가를 원하신다면, 그것이 저희 소프트웨어 개발 업무가 시작되는 지점입니다.

샌드박스, 배포, API 버전

샌드박스에서 만드십시오. 운영을 상대로도, 운영 설정을 공유하지 않는 Developer Edition 조직을 상대로도 만들지 마십시오. 여러분을 깨뜨리는 것은 바로 그 설정이기 때문입니다.

새로 고침이 무엇을 하는지 이해하십시오. 새로 고침은 샌드박스를 운영에서 뜬 새 사본으로 바꾸므로, 거기에만 있던 테스트 데이터는 사라집니다. 새로 고침을 견뎌야 하는 것은 무엇이든 스크립트로 만들고 다시 실행할 수 있어야 합니다. 팀은 보통 테스트 데이터를 한 주 치 잃고 나서 이것을 배웁니다.

모든 요청 경로에 API 버전을 명시적으로 고정하고 폐지 정책을 파악하십시오. Salesforce의 API 지원 종료 정책은 각 버전을 최소 3년간 지원하고, 지원 종료 최소 1년 전에 고객에게 알리겠다고 약속합니다. 버전 21.0부터 30.0까지는 Summer ‘25에 폐지되었고, 폐지된 버전으로 보낸 요청은 410 Gone을 돌려받습니다.

이것은 성능 저하가 아니라 완전한 정지이며, 그래서 버전 고정은 유지보수 계획에 속합니다. 같은 규율은 여러분이 직접 공개하는 API에도 적용되며, 그 이야기는 API 버저닝 글에서 다룹니다.

영국 데이터 보호와 CRM 데이터

CRM은 거의 전부가 개인 데이터입니다. 이름, 근무처, 전화번호, 이메일 주소, 대화 기록. 그것을 시스템 사이로 옮기는 일은 UK GDPR에 따른 처리입니다.

첫 번째 질문은 누가 컨트롤러인가입니다. 컨트롤러와 프로세서에 관한 ICO의 안내는 컨트롤러를 처리의 목적과 수단을 정하는 당사자로, 프로세서를 컨트롤러를 대신해 처리하는 당사자로 정의합니다. 대행사가 여러분을 위해 연동을 만들고 운영한다면 그 대행사는 보통 프로세서이며, GDPR Article 28의 요건을 충족하는 서면 계약은 선택이 아니라 필수입니다.

두 번째는 국제 이전입니다. Salesforce 조직도, 사이에 놓인 미들웨어도 영국 밖에 있을 수 있고, ICO의 국제 이전 안내는 사용할 수 있는 장치와 이전 위험 평가가 필요한 경우를 정리합니다. 서명하기 전에 데이터가 어디에 내려앉는지 확정하십시오.

여기서 세 가지가 따라옵니다. 필요하지 않은 필드는 복사하지 마십시오. 최소화는 법적 요건인 동시에 매핑 작업도 줄여 줍니다. 운영 개인 데이터를 충분히 고민하지 않은 채 샌드박스에 넣지 마십시오. 그리고 삭제가 전파되게 하십시오. Salesforce에서 지운 연락처가 데이터 웨어하우스에 그대로 남아 있는 것은 살아 있는 컴플라이언스 문제이며, AI 에이전트가 그 레코드에 닿을 때도 마찬가지입니다.

Salesforce 연동 비용

Salesforce는 자사 가격 페이지에서 에디션과 라이선스 가격을 공개하고 있고, 여기서는 그 숫자를 인용하지 않습니다. 연동 설계를 좌우하는 것은 정가가 아니라 그 라이선스가 만들어 내는 API 할당량이기 때문입니다.

아래 수치는 벤더 가격이 아니라 Mecanik의 영국 전문 서비스 자체 추정치이며, 조직이 이미 존재하고 질문에 답할 수 있는 관리자가 있다고 가정합니다.

단순한 단방향 연동, 즉 웹 폼이 외부 ID를 가진 Lead를 만들고 합리적인 오류 처리가 붙은 경우는 보통 GBP 3,000에서 GBP 7,000입니다. 오브젝트 한두 개의 양방향 동기화에 충돌 해결과 대사 작업을 더한 경우는 대개 GBP 15,000에서 GBP 40,000입니다. 재처리, 데드 레터 처리, 모니터링을 갖춘 Pub/Sub 기반 이벤트 주도 연동은 일반적으로 GBP 30,000에서 GBP 80,000 사이에 놓입니다.

산출물에 들어 있어야 하는 것

짐작이 아니라 현업과 합의한 필드 수준 매핑 문서. 동기화하는 모든 오브젝트의 외부 ID. 데드 레터 저장소와 문서화된 재제출 절차를 갖춘 오류 처리. 대사 작업. 조직 할당량 대비 API 소비량 모니터링과 상한 훨씬 아래에서 울리는 경보. 토큰 교체, 인증서 만료, 재처리를 위한 운영 문서. 새로 고침을 견디도록 스크립트로 만든 샌드박스 설정. 이것들이 없는 연동은 청구서에 뭐라고 적혀 있든 시제품입니다.

유지 비용

모니터링, 연 3회의 Salesforce 릴리스, 자격 증명 교체, 그리고 관리자가 말없이 할 필드 변경을 위해 월 GBP 400에서 GBP 1,500을 잡아 두십시오. 여기에 예산을 붙이는 조직이 연동이 계속 동작하는 조직입니다.

실제로 만들려면

여기서의 실패 유형은 지루할 만큼 일정합니다. 뒤늦게 발견한 할당량, 아무도 감사하지 않은 트리거, Contact이었어야 할 Lead, 실패한 배치를 다시 돌릴 방법의 부재. 넷 다 설계 시점에는 막기 싸고, 진짜 레코드가 존재한 뒤에는 고치기 비쌉니다.

Mecanik은 소프트웨어 개발 업무의 일부로 Salesforce 연동을 만들고 유지하며, 코드를 한 줄 쓰기 전에 조직의 할당량, 트리거, 데이터 모델을 감사하는 것부터 시작합니다. 전체 계약이 아니라 범위가 정해진 연동 작업을 원하신다면 웹 개발자 채용을 바로 진행하실 수 있습니다.

자주 묻는 질문

Salesforce 연동은 하루에 API 호출을 몇 번이나 쓸 수 있습니까? 에디션과 라이선스 수에 따라 달라지며, 할당량은 연동별이 아니라 조직 전체 단위입니다. API 접근이 포함된 Enterprise와 Professional 에디션은 100,000회에 더해 Salesforce 또는 Salesforce Platform 라이선스 1개당 1,000회를, Unlimited와 Performance는 100,000회에 더해 라이선스 1개당 5,000회를 받고, Developer Edition은 이동하는 24시간 동안 일괄 15,000회를 받습니다.

Salesforce에서는 REST API와 Bulk API 중 무엇을 써야 합니까? 대화형이고 물량이 적으며 레코드 모양을 한 작업에는 REST API를, 물량이 많고 비동기 응답이 허용되는 적재와 추출에는 Bulk API 2.0을 쓰십시오. 그 중간에 있는 것에는 요청당 200건인 sObject Collections와 요청당 하위 요청 25개인 Composite이 있으며, 둘 다 할당량에 대해 호출 한 번으로 계산되어 압박의 대부분을 없애 줍니다.

서버 대 서버 Salesforce 연동에는 어떤 OAuth 흐름을 써야 합니까? JWT 베어러 흐름이나 클라이언트 자격 증명 흐름을 API 전용 통합 사용자로 실행하십시오. 사용자 이름과 비밀번호 흐름은 최근 조직에서 기본으로 차단되고 폐지도 예정되어 있어 새 작업에 써서는 안 됩니다. 또한 Spring ‘26부터 연결 앱 생성이 제한되며 Salesforce는 이제 외부 클라이언트 앱을 권장한다는 점도 알아 두십시오.

Salesforce 연동이 큰 배치에서만 실패하는 이유는 무엇입니까? 거의 언제나 벌크화되지 않은 Apex 트리거 때문입니다. Salesforce는 트리거에 레코드의 컬렉션을 넘기는데, 한 번에 한 건을 받는다고 가정하고 작성된 트리거는 레코드마다 쿼리를 실행하고 배치가 도착하는 순간 SOQL 쿼리 100건 제한을 넘깁니다. 화면에서 한 건씩 저장하는 사용자에게는 멀쩡히 동작하기 때문에 발각되지 않은 채 살아남습니다.

Salesforce와 연동하려면 미들웨어가 필요합니까? 출처 하나, 대상 하나, 한 방향이고 물량이 적당하다면 필요하지 않으며, 직접 만드는 편이 더 싸고 단순합니다. 미들웨어가 값을 하는 때는 여러 시스템이 데이터를 주고받거나, 현업이 배포 없이 매핑을 바꿔야 하거나, 중앙 집중식 조율과 재시도가 필요해진 뒤입니다. 미들웨어는 비용을 없애는 것이 아니라 옮기며, API 할당량을 늘려 주지도 않습니다.