고객 두 곳에 모두 “활성”이라는 필드가 있습니다. 한 곳에서는 지난 1년 동안 구매했다는 뜻입니다. 다른 곳에서는 서비스 계약이 현재 유효하다는 뜻입니다. 공유 커넥터는 두 필드를 모두 정확히 옮길 수 있습니다. 둘을 같은 비즈니스 상태로 취급하는 공유 규칙은 한 고객에게 틀릴 수 있습니다. 배포에서 보고된 사례가 아니라 설명용 예시입니다.
공유 플랫폼과 고객 업무 환경의 배포에 관한 대화는 회사가 인프라의 많은 부분을 재사용하면서도 각 고객 환경 안에서 상당한 일을 한다고 설명합니다. 제시된 비율은 그 회사에만 해당합니다. 일반적인 구조 질문은 공유할 수 있는 기계적 부분이 끝나고 각 업무의 의미가 시작되는 곳이 어디냐는 것입니다.
전송 계약과 비즈니스 계약 분리하기
전송 계약은 원본 인증, 변경된 레코드 읽기, 식별자 보존, 안전한 재시도, 실패 노출을 명시할 수 있습니다. 이런 동작은 한 번 구현하고 반복해서 테스트할 수 있습니다. 모든 연동에 데이터의 신뢰할 만한 경로가 필요하므로 가치가 있습니다.
비즈니스 계약은 어느 레코드가 권위 있는지, 상태가 무엇을 뜻하는지, 언제 행동이 허용되는지, 누가 실수를 고칠 수 있는지를 말합니다.
- 공유 전송 식별 · 재시도 · 이벤트 ID
유효한 이벤트 전달
- 각 업무의 정책 의미 · 동의 · 시점
행동 허용 여부 결정
- 허용된 행동 쓰기 · 감사
결과 기록
이 비즈니스 계약은 워크플로에 달려 있습니다. 다른 고객과 원본 및 목적지가 같아도 다른 답이 필요할 수 있습니다.
매장에서 이메일 시스템으로 연결하는 경우를 생각해 보세요. 플랫폼은 이벤트 수집, 중복 제거, 감사 이력을 제공할 수 있습니다. 워크플로 소유자는 “구독”이 특정 마케팅 목적의 허가인지, 구매하면 장바구니 알림을 제외하는지, 동의 변경이 이미 대기 중인 메시지에 어떻게 영향을 주는지 정의해야 합니다. 필드 이름만 보고 추측할 수 있는 커넥터 기능이 아닙니다.
아래 Tajo 예시 매핑은 필드 세 개를 그대로 복사합니다. 어느 행도 마케팅 동의를 정의하지 않습니다. 전송 방식을 재사용하면 작업은 줄지만, 어떤 상태에서 어떤 행동이 허용되는지는 워크플로 책임자가 정해야 합니다. 깔끔한 매핑은 빈자리를 드러낼 뿐 메우지는 못합니다.
실행 전 동기화 검토
고객 업데이트를 이메일 플랫폼에 동기화해 주세요.
고객 동기화
| 원본 필드 | 대상 필드 | 규칙 |
|---|---|---|
email | EMAIL | 직접 복사 |
first_name | FIRSTNAME | 직접 복사 |
last_name | LASTNAME | 직접 복사 |
합성 데이터 미리보기 통과
필드 3개 매핑 · 대상에 쓰기 없음
Tajo 매핑 도구를 바탕으로 한 예시 화면입니다. 합성 데이터 미리보기와 저장된 초안은 동기화를 활성화하지 않습니다.
| 공유 계층 | 개별 업무 계층 |
|---|---|
| 인증과 토큰 갱신 | 이 워크플로에 접근할 수 있는 주체 |
| 이벤트 전송과 재시도 | 비즈니스 상태 전환으로 인정할 이벤트 |
| 안정적인 식별자와 중복 제거 | 같은 실제 고객을 가리키는 레코드 |
| 로깅과 복구 연결 지점 | 다툼이 있는 상태를 누가 어떻게 해결하는지 |
| 계약 검증 | 필드 값의 의미와 행동에 쓸 수 있는 시점 |
설계의 경계를 보여주는 표이지 모든 구현을 이렇게 깔끔하게 나눌 수 있다는 주장은 아닙니다.
의견 차이를 숨기면 재사용은 깨집니다
범용 플랫폼에는 예외마다 설정 필드가 늘어날 때가 많습니다. 처음에는 재사용을 지키는 것처럼 보입니다. 나중에는 설정이 기술 선택인지, 법적 제약인지, 비즈니스 결정인지 아무도 구분하지 못합니다. 공유 핵심부가 자신이 소유하지 않은 선택을 원격으로 조종하게 됩니다.
안정적인 불변 조건을 찾으세요. “같은 원본 이벤트를 같은 목적지 레코드에 두 번 적용하지 않는다”는 공유 엔진에 둘 수 있습니다. “고객이 활성 상태가 되면 할인을 보낸다”는 “활성”, 허용된 오디언스, 제안 정책의 소유자가 정해지기 전에는 공유할 수 없습니다. 엔진은 승인된 정책을 실행할 수 있지만 스스로 만들어서는 안 됩니다.
유지보수에도 도움이 됩니다. API가 바뀌면 플랫폼 팀은 어댑터와 테스트를 갱신할 수 있습니다. 자격 있는 고객의 정의가 바뀌면 비즈니스 소유자는 전송 계층을 다시 쓰지 않고 정책과 테스트 예시를 바꿀 수 있습니다. 명확한 경계는 변경을 그 권한이 있는 사람에게 보냅니다.
의미를 평평하게 만들지 않고 기계적 부분 재사용하기
각 업무의 규칙에는 비용이 들기도 합니다. 재사용 가능한 계약이 전혀 없는 플랫폼은 개별 스크립트 모음이 됩니다. 답은 반복되는 의미를 추상화하기 전에 반복되는 기계적 부분을 찾는 것입니다. 잘 설계된 공유 구성 요소는 타입이 정해진 조건, 이벤트 시각, 행동 제한을 받되 조건의 비즈니스 정의는 개별 업무 영역에 남길 수 있습니다.
실제 사례로 경계를 시험해야 합니다. 정상 이벤트, 중복, 늦은 수정, 철회된 권한을 가져오세요. 각각의 대응을 어느 계층이 맡는지 묻습니다. 실패를 배정할 수 없다면 추상화가 소유권을 숨기고 있습니다. 새 고객 때문에 공유 “활성” 열거형에 서로 관련 없는 해석이 여럿 붙는다면 공유 타입이 너무 넓습니다.
함께 읽을 배포에 관한 글은 기능이 실제 워크플로 안에서 작동하는지 묻습니다. 이 글은 워크플로의 의미를 지우지 않고 무엇을 한 번만 만들 수 있는지 묻습니다.
계층 사이의 인터페이스는 잘못된 가정을 거부할 만큼 명확해야 합니다. 공유 엔진은 행동 요청을 받기 전에 이벤트 ID, 원본 시각, 행위자, 선언된 목적을 요구할 수 있습니다. 각 업무의 워크플로는 그 행동이 허용되는지 결정하는 정책을 제공할 수 있습니다. 목적이 없다면 엔진이 요청을 거부하고, 정책이 모호하다면 해당 업무 소유자가 해결해야 합니다. 범용 코드에 비즈니스 권한을 넘기지 않고 재사용을 유지하는 실제적인 방법입니다. 수락 사례 하나와 거부 사례 하나로 계약을 문서화하고 어느 계층이 바뀌든 둘 다 시험하세요.
재사용 가능한 커넥터는 각 업무의 의미를 표현하기 쉽게 하고 안전하게 실행하게 해야 합니다. 필드 이름이 같다는 이유로 서로 다른 약속을 똑같아 보이게 해서는 안 됩니다.
자주 묻는 질문
연동 플랫폼은 보통 무엇을 재사용해야 하나요?
기본 요구사항이 같다면 인증 방식, 전송, 멱등성, 재시도, 로깅, 계약 검사처럼 안정적인 기계적 부분을 공유할 수 있습니다.
무엇이 비즈니스별로 남아야 하나요?
필드의 의미, 원본의 권위, 동의 규칙, 시점 요구사항, 상태에 따라 누가 행동할 수 있는지는 해당 비즈니스와 워크플로에 맞춰 정해야 합니다.
팀은 그 경계를 어떻게 시험하나요?
기존 구성 요소로 새 워크플로를 표현해 보세요. 그러는 과정에서 비즈니스 의미가 달라지거나 예외가 일반 설정에 숨는다면 그 로직은 개별 업무 영역에 두고 인터페이스를 명시하세요.