처음 목표는 아주 단순했다.
여행 기사에 추적 가능한 예약 링크 하나 넣기.
그런데 실제 흐름은 이랬다.
제휴 경로 찾기
→ 광고주가 다른 네트워크로 이동한 사실 확인
→ CJ Publisher 가입
→ 프로필 작성
→ 프로모션 속성 등록
→ 세금 정보
→ W-8BEN
→ 지급 설정
→ 국내 은행 직접 경로가 안 보임
→ Payoneer
→ KYC
→ 신원 확인
→ 주소 확인
→ 서류 거절
→ 이름 철자 오류 발견
→ 챗봇에게 사람을 연결해 달라고 요청
→ FAQ 반복
→ 결국 사람 상담 요청.
링크 하나치고 보스가 너무 많다.
12개 언어를 운영하는 사이트라면 국가마다 네트워크, 광고주 프로그램, 지급 방식이 달라질 수 있어 문제가 더 커진다.
1. 광고주를 아는 것과 수익화 경로를 아는 것은 다르다
유명 여행 브랜드는 누구나 안다.
하지만 지금 특정 지역의 Publisher가 어느 네트워크를 통해 가입해야 하는지까지 아는 사람은 급격히 줄어든다.
Booking.com의 CJ 흐름은 지역 선택부터 시작하며, 신청 전에 활성화된 CJ 계정이 필요하다.[1]
여기서 구분해야 한다.
- audience region: 독자가 어디에 있는가;
- tax residence: 운영자가 세법상 어디에 거주하는가;
- bank country: 지급 계좌가 어느 나라에 있는가.
모두 국가를 묻지만 질문은 완전히 다르다.
맞지 않는 지역을 억지로 골라 다음 화면으로 넘어가는 것은 금물이다.
등록 폼은 탈출 게임이 아니다.
2. CJ 가입은 회원가입이 아니라 상태 머신이다
로그인을 만들었다고 끝이 아니다.
사용자 정보, 네트워크 프로필, 프로모션 속성, 주소, 세금 서류, 지급 수단, 계정 활성화가 이어진다.
7/8까지 오면 사람 마음은 이미 종료 상태다.
시스템은 말한다.
지급 정보를 완료하세요.
CJ는 글로벌 브랜드, 리포트, API, 지급 기능을 제공하고, Payoneer를 통해 현지 은행 계좌와 현지 통화 지급도 지원한다고 안내한다.[2]
필요한 확인이라는 건 이해된다.
그래도 귀찮다.
3. 미국 밖에 사는데 왜 W-8BEN이 나오는가
W-8BEN은 “나는 미국인입니다” 양식이 아니다.
미국 밖의 개인이 외국인 신분과 소득의 실질 소유자임을 증명하고, 필요하면 조세조약 혜택을 청구하는 데 쓰인다.[3]
위험한 행동은 이것이다.
“0%가 이득이니 0%를 넣자.”
조약 혜택은 소득 종류, 거주국, 조약 조항과 조건에 따라 달라질 수 있다.[3]
신원 정보는 법적 문서와 일치시킨다.
세율과 조약 판단은 튜토리얼 복붙으로 처리하지 않는다.
4. CJ Payments에서 막히면 Payoneer라는 두 번째 던전이 열린다
직접 은행 지급이 자신의 국가에 맞지 않으면 Payoneer가 등장한다.
CJ도 Payoneer를 현지 통화·현지 은행 지급을 위한 글로벌 파트너로 설명한다.[2]
그다음 질문은 사업 형태, 입금 출처, 웹사이트, 활동 지역, 신원, 주소다.
금융 서비스라 KYC가 필요한 것은 정상이다.
하지만 사용자 입장에서는,
여행 링크 하나 넣으려다가 금융기관에게 “당신이 진짜 당신입니까?”를 증명하고 있다.
장르가 바뀌었다.
5. 신원 확인이 끝나도 주소 확인에서 다시 멈춘다
Payoneer는 등록 주소가 실제 거주지인지 확인하기 위해 거주 증명을 요청할 수 있다고 설명한다.[4]
공공요금, 은행 명세, 정부·세금 서류 등이 흐름에 따라 사용될 수 있다.
문제는 사람이 보기엔 충분해 보이는 서류도 자동 판정에서 떨어질 수 있다는 점이다.
신원 확인은 승인.
사업 설문도 제출.
남은 것은 주소 하나.
그런데 거주 증명이 거절된다.
여기서 계정 이름의 철자 오류가 중요해진다.
6. 한 글자 오류가 신원·주소·지급을 동시에 막는다
금융 KYC는 이름을 연결 키로 사용한다.
여권
→ 계정 이름
→ 세금 양식
→ 주소 증명
→ 은행 명의
→ 수취인.
“대충 같은 사람”은 데이터베이스 조인이 아니다.
Payoneer 공식 도움말은 개인 계정 이름 변경을 Settings → Profile settings → Name and email → Edit → Request name change에서 신청한다고 안내한다.[5]
그런데 등록 중에는 그 옵션이 안 보일 수 있다.
그래서 지원센터로 간다.
챗봇은 다시 그 메뉴를 안내한다.
그 메뉴가 없어서 문의한 건데.
이 지점이 자동화의 happy path 바깥이다.
사람 상담에는 이름 수정, 주소 서류 수동 재검토, 재거절 시 정확한 사유를 한 번에 요청하는 편이 낫다.
7. 12개 언어 사이트는 하나의 ASP로 끝나지 않는다
다국어 수익화는 같은 링크를 번역하는 일이 아니다.
시장마다 국내 쇼핑 네트워크, CJ/Awin, Amazon 스토어별 프로그램, 광고주 승인 상태가 다를 수 있다.
필요한 것은 링크 모음이 아니라 Affiliate Router다.
locale
→ market
→ merchant
→ network
→ approval state
→ trackable link
→ payout readiness.
이 단계부터 수익화는 URL 문제가 아니라 상태 관리 문제다.
8. 사람들이 중간에 그만두는 이유는 어렵기 때문이 아니라 자잘하게 귀찮기 때문이다
각 단계는 대부분 쉽다.
클릭, 입력, 선택, 업로드, 대기.
하지만 서비스 발견, 공식 가입 경로, 지역 선택, 세금 용어, 지급 서비스, KYC, 서류 거절, 지원센터까지 쌓이면 피로가 폭발한다.
경쟁력은 종종 비밀 지식이 아니라 지루한 파이프라인을 끝까지 통과하는 능력에서 나온다.
Friction is the moat.
누구나 할 수 있다.
아무도 하고 싶지 않다.
9. 진짜 강점은 참는 것이 아니라 다음번 귀찮음을 없애는 것이다
매번 근성으로 해결하면 확장되지 않는다.
시스템은 네트워크 가입, 사이트 심사, 광고주 승인, 세금·지급 준비, locale/market 지원, 추적 경로, 다음 사람 작업을 상태로 저장해야 한다.
AI와 코드가 맡을 일은 탐색, 공식 확인, 상태 장부, 라우팅, 링크 검사, 다음 행동 제안.
사람이 맡을 일은 신원 확인, 세금 선언, 은행 정보, 약관 동의, 광고주 신청.
여권, 세금번호, 은행번호, 전체 주소는 공개 채팅이나 GitHub에 올리지 않는다.
AI가 알아야 하는 것은 필드의 의미이지 비밀 값이 아니다.
결론: 어려운 것은 링크가 아니라 운영이었다
예약 제휴 하나로 시작했다.
결과는 CJ, W-8BEN, Payoneer, 신원 확인, 주소 증명, 이름 수정, 사람 상담이었다.
체크리스트는 7/8.
아직 링크는 한 개도 안 붙었다.
다국어 사이트의 수익화 핵심은 광고 찾기가 아니다.
국가, 언어, 광고주, 네트워크, 세금, KYC, 추적, 지급을 끊기지 않게 연결하는 것이다.
한 번 배선하면 다음부터 재사용할 수 있다.
그때 비로소 귀찮음이 경쟁력이 된다.
- CJ / Booking.com Publisher Signup — regional programme flow, active CJ account requirement, affiliate programme steps
- CJ, Publisher — global affiliate network, APIs, reporting, local-currency payouts and Payoneer partnership
- Internal Revenue Service, Instructions for Form W-8BEN — foreign individual status, beneficial owner, FTIN and treaty-benefit instructions
- Payoneer, “Proof of Residence: Why It’s Needed and How Best to Provide It” — residence verification purpose and document guidance
- Payoneer Support, “I want to change the name on my Payoneer account.” — individual-account name-change request flow
