| 상황 | 구조 없는 DM 거래 | 인플스 AI(전자계약+에스크로) |
|---|---|---|
| 제품만 받고 잠적 | 현금·제품 손실, 추적·독촉만 가능 | 대금이 에스크로에 묶여(크리에이터 90%/플랫폼 10%) 현금 손실 차단 |
| 게시 기한 초과 | 구두 약속뿐, 회수 근거 약함 | 계약 위약 조항으로 회수 협상 가능 |
| 무료 현물 협찬 미게시 | 환수 근거 사실상 없음 | 미게시 시 제품가 환수 조항으로 대응 |
| 분쟁 발생 | 개별 연락·증거 수집 | report_issue·dispute_contract·call_manager·request_mediation으로 중재 |
왜 협찬 먹튀가 생기는가: 문제는 사람보다 순서
제품 협찬을 자주 돌리는 브랜드가 반복적으로 겪는 분쟁이 '제품만 받고 후기 안 올리기'입니다. 원인은 의외로 단순합니다. 거래 순서가 '브랜드가 먼저 주고, 크리에이터가 나중에 게시'로 설계돼 있기 때문입니다. 제품(또는 선금)이 이미 상대 손에 넘어간 상태에서는 게시를 끌어낼 지렛대가 사라지고, 브랜드가 할 수 있는 일은 DM 독촉과 캡처 증거 수집 정도로 좁아집니다. 직관적으로도 '잃을 게 적은' 무상 현물 거래일수록 이행 동기가 약하다고 볼 수 있는데, 미게시 비율 같은 구체 수치는 공개·검증된 통계가 아니므로 단정하지 않겠습니다. 핵심은 사람을 더 잘 고르는 것만으로는 구조적 위험이 남는다는 점, 그리고 돈과 산출물이 교환되는 순서를 바꾸는 것이 더 직접적인 해법이라는 점입니다.
가장 직접적인 방어: 게시·검수 후 정산하는 에스크로
인플스 AI의 핵심 방어선은 에스크로 정산입니다. 브랜드 대금이 곧바로 크리에이터에게 가지 않고, 크리에이터가 약속한 콘텐츠를 게시하고 검수가 끝난 뒤에야 풀립니다. 코드 기준으로 에스크로 금액은 크리에이터 90% / 플랫폼 10%로 분할되며, 흐름은 ① 양측이 sign_contract로 전자서명하면 에스크로가 자동 펀딩되고 ② 게시·검수가 승인되면 release_escrow_payment로 릴리스되며 ③ 마일스톤이 여러 단계라면 단계별로 propose_milestones·release_milestone_payment를 통해 같은 90/10 비율로 정산되고 모든 마일스톤이 정산되면 계약이 완료됩니다. 이 순서에서는 제품만 받고 잠적해도 대금이 에스크로에 묶여 있어 브랜드의 현금 손실이 구조적으로 줄어듭니다. 다만 실결제 에스크로 연동(토스페이먼츠)과 Vision 기반 자동검수는 베타/예정 단계이므로, 현재는 게시 URL·광고 표기·납품 조건을 사람이 직접 검수한 뒤 approve_deliverable·release_escrow_payment로 정산을 푸는 방식으로 운영합니다.
전자계약과 위약 조항: 발생했을 때 회수하는 근거
에스크로가 '현금 손실'을 줄인다면, 전자계약은 '의무와 회수 근거'를 만듭니다. create_contract로 게시 의무, 게시 기한, 무료 수정 횟수, 광고 표기, 그리고 미게시·기한 초과 시 위약 조항을 한 문서에 담고 양측이 sign_contract로 서명합니다(서명 시 에스크로가 펀딩됩니다). 전자서명된 계약은 분쟁이 생겼을 때 협상과 회수의 기준선이 됩니다. 무료 현물 협찬이라 정산금이 없는 경우에도, 계약에 '약속 기한 내 미게시 시 제품 정가 상당액을 환수한다'는 조항을 넣으면 회수 근거를 둘 수 있습니다. 다만 위약 조항은 계약상 근거일 뿐 자동 강제집행 수단은 아니며, 광고 표기(뒷광고 방지) 등은 공정거래위원회 「추천·보증 등에 관한 표시·광고 심사지침」상 경제적 이해관계 표시 의무와도 연결되므로 계약 문구에 함께 반영하는 것이 좋습니다. 계약·세무·법적 처리는 일반 참고·추정 수준이며, 금액이 크거나 다툼이 길어지면 전문가·공식기관 확인을 권합니다.
단계별 대처: 노쇼가 이미 발생했다면
이미 미게시 분쟁이 벌어졌다면 다음 순서를 권합니다. 첫째, 계약서의 게시 기한과 위약 조항을 다시 확인합니다(계약이 있으면 이 단계가 가장 빠릅니다). 둘째, 정산 전이라면 보류금을 풀지 말고 report_issue로 문제를 기록한 뒤 dispute_contract로 분쟁을 열어 대금을 보류 상태로 둡니다. 셋째, call_manager로 매니저를 호출하고 필요하면 request_mediation으로 중재를 요청해 '게시' 또는 '환수' 중 하나로 합의를 시도합니다. 넷째, 합의가 되면 게시·검수 후 approve_deliverable·release_escrow_payment로 정산하거나, 합의가 안 되면 위약 조항을 근거로 회수를 진행합니다. 계약·에스크로 없이 진행된 일반 DM 거래라면 회수가 훨씬 어렵습니다. 이 경우 현실적인 답은 본 건 회수에 매달리기보다 '다음 캠페인부터 구조를 갖추는 것'입니다.
반복 협찬 브랜드가 처음부터 세팅할 체크리스트
제품 협찬을 반복적으로 운영하는 브랜드라면 첫 캠페인부터 다음을 표준으로 만드는 것이 좋습니다. ① 검색·비교(search_influencers, compare_influencers)로 후보의 광고 표기 이력과 과거 이행 패턴을 함께 본다. ② 캠페인(create_campaign)과 아웃리치(draft_outreach_messages, send_outreach) 이후에는 반드시 전자계약(create_contract → sign_contract)을 거친다. ③ 정산은 항상 에스크로로 두고, submit_deliverable로 받은 게시물의 광고 표기·납품 조건을 확인한 뒤 approve_deliverable·release_escrow_payment로 푼다. ④ 비용 면에서, 브랜드 측 가격은 GMV 5%(Pro)이고 가입·검색·브리프·후보검토는 베타 무료이며 정식 과금은 계약 성사·정산 시점의 거래 수수료입니다. 별개로 정산 시 크리에이터는 에스크로 분할에 따라 90%를 수령합니다(두 항목은 부과 대상과 시점이 다르므로 합산해 '총 수수료 몇 %'로 단정하지 않습니다). 소액 다건의 현물 협찬에도 같은 구조를 적용해 볼 수 있습니다. 단가·세무는 일반 참고 수준이며, 대가의 사업소득/기타소득 원천징수·세금계산서 등은 국세청 안내 등 공식 자료를 함께 확인하는 것을 권합니다.
FAQ
제품만 무료로 협찬하고 정산금이 없는데도 에스크로가 의미가 있나요?
정산금이 없으면 에스크로로 묶을 현금 자체가 없는 것은 맞습니다. 다만 이 경우에도 전자계약에 '기한 내 미게시 시 제품 정가 상당액 환수' 같은 위약 조항을 넣으면 회수 근거가 생깁니다. 무상 협찬일수록 이행 동기가 약해 미게시 위험이 커질 수 있으므로 계약 문서화가 더 중요합니다. 가능하면 소액이라도 정산금을 두고 에스크로로 게시·검수 확인 후 지급하는 구조를 권합니다.
이미 제품만 받고 후기를 안 올린 상태인데 지금 할 수 있는 게 있나요?
계약이 있다면 게시 기한과 위약 조항부터 확인하세요. 정산 전이라면 보류금을 풀지 말고 report_issue로 기록한 뒤 dispute_contract로 분쟁을 열어 대금을 묶고, call_manager·request_mediation으로 중재를 요청하세요. 계약·에스크로 없이 진행된 DM 거래라면 회수가 어려워, 현실적으로는 다음 캠페인부터 전자계약과 에스크로 구조를 도입하는 것이 답입니다.
Vision 자동검수나 알림톡 독촉이 게시를 자동으로 강제해 주나요?
Vision 기반 자동검수와 카카오 알림톡 리마인드는 베타/예정 기능입니다. 현재는 게시 URL과 광고 표기, 납품 조건을 사람이 직접 검수한 뒤 정산을 푸는 방식으로 운영합니다. 어떤 기능도 게시를 '강제'하지는 못하며, 핵심은 게시·검수 전에는 대금이 풀리지 않는다는 정산 순서 자체입니다.
위약 조항으로 돈을 무조건 돌려받을 수 있나요?
위약 조항은 회수를 위한 계약상 근거이지 자동 강제집행 수단은 아닙니다. 에스크로에 보류된 금액 범위 안에서는 보류·차감이 비교적 명확하지만, 그 이상을 청구하려면 합의 또는 별도 절차가 필요합니다. 금액이 크거나 분쟁이 길어질 경우 전문가 자문과 공식기관 확인을 함께 받는 것을 권합니다.
투명성 고지 · 참고 출처
- · 작성: 인플스 AI 편집팀(브리찌). 최종 업데이트 2026-06-10.
- · 성격: 일반 정보성 콘텐츠입니다. 단가·세무·법률 등 수치와 규정은 일반적 참고용 추정이며 실제와 다를 수 있어, 중요한 판단은 해당 전문가·공식 기관 확인을 권장합니다.
- · 이해관계: 자사 서비스(인플스 AI) 안내를 포함합니다.
- · 출처: 인플스 AI 제품 정책 및 아래 공개 자료를 참고했습니다. 원문은 각 링크에서 확인할 수 있습니다.