플랫폼 심사에 들어가기 전에, 승인되면 정확히 무엇이 달라지는지 한 문장으로 적어보신 적 있습니까?
저는 안 적었습니다. 2주를 심사에 쓰고, 반려를 세 번 맞고, 마지막 반려가 고칠 수 없는 사유였을 때 처음 계산해봤습니다. 답은 "아무것도"였습니다.
하려던 일
숏폼 파이프라인이 이미 돌고 있었습니다. 앱 자산으로 세로 영상을 렌더해서 유튜브 3채널(ko/en/ja)에 매일 자동 게시합니다. 유튜브는 API 심사가 필요 없어서 이 부분은 오래전에 무인화됐습니다.
거기에 짧은 영상 플랫폼 하나를 붙이려고 했습니다. 렌더된 mp4와 게시 큐는 유튜브와 공유하고, 발행 상태만 따로 관리하면 되는 일이었습니다. 코드는 하루에 관통했습니다. 샌드박스에서 실제로 3편이 PUBLISH_COMPLETE까지 갔습니다. 남은 건 심사 승인뿐이었습니다.
반려 1: 아이콘
첫 반려 사유는 앱 아이콘이 웹사이트 아이콘과 다르다는 것이었습니다.
같은 도안이었으니 착오라고 생각했는데, 열어보니 진짜 달랐습니다. 데모 촬영용으로 급히 만든 PNG는 각진 정사각형에 코너가 완전 불투명(alpha 255)이었고, 실제 사이트 favicon은 둥근 사각형에 코너가 완전 투명(alpha 0)이었습니다. 크기와 비율만 맞추고 코너 알파를 안 봤습니다. 육안으로 잡히는 불일치였고, 심사자가 맞았습니다.
favicon 좌표를 1024px로 정확히 스케일해서 투명 배경으로 재렌더하고 재제출했습니다. 정당한 반려였습니다.
반려 2: "웹사이트가 완성된 상태가 아님"
두 번째 반려는 등록한 Website URL이 "fully developed" 하지 않다는 것이었습니다 — 랜딩/로그인 페이지는 안 된다고요.
그 URL은 앱 40여 개가 올라간 제 허브였습니다. 랜딩 한 장이 아니었습니다. 원인을 파보니 도메인 앞단 CDN이 자동화 요청에 봇 확인 챌린지를 먹이고 있었습니다. 브라우저 UA를 써도 apex 도메인은 403이 떨어집니다. 심사 크롤러가 봤을 화면은 제 허브가 아니라 챌린지 페이지였을 겁니다.
이건 제가 못 고치는 종류였습니다 — CDN 설정을 풀면 다른 문제가 생깁니다. 그래서 URL을 이 개발 블로그 도메인으로 교체했습니다. 정상 200이고, 발행된 글이 백 편 넘게 있으니 "fully developed"에 대한 반론 여지가 없습니다. 아이콘도 새로 만들어 함께 재제출했습니다.
여기까지가 제가 잘한 부분입니다. 두 반려 모두 실제 원인을 파고, 실측으로 확인하고, 고쳤습니다.
당신이라면 세 번째 반려를 어떻게 읽으시겠습니까
세 번째 회신이 왔습니다.
TikTok for Developers currently does not support
personal or internal company use.
Not acceptable: A utility tool to help upload contents
to the account(s) you or your team manages.두 번째 문장이 제 앱의 정의 그대로입니다. 내가 운영하는 계정에 내 콘텐츠를 올리는 유틸리티. 그게 제가 만든 것이고, 그게 불허 항목입니다.
여기서 갈림길이 있었습니다. 앞의 두 반려는 고쳐서 다시 냈으니, 반사적으로 손이 갑니다 — 서류 문구를 바꿀까, 용도 설명을 다시 쓸까, 아이콘을 또 만질까. 반려 = 결함 = 수정이라는 회로가 두 번 성공하면 세 번째에도 그 회로가 먼저 돕니다.
하지만 이 사유에는 결함이 없습니다. 아이콘이나 URL 같은 표면이 아니라, 앱이 속한 범주에 대한 판정입니다. 자기게시 도구는 규격을 아무리 맞춰도 이 API의 대상이 아닙니다. 같은 앱을 다시 내면 같은 사유로 다시 반려됩니다. 고칠 것이 없는 사유를 고치려고 하면 네 번째 반려를 버는 것뿐입니다.
그래서 처음으로 계산을 해봤습니다
재제출을 접기로 하고 나서야, 애초에 물어야 했던 질문을 물었습니다. 승인되면 무엇이 달라졌을까?
기록을 다시 열어보니 답이 이미 적혀 있었습니다. 착수 첫날, 제 노트에 이렇게 써 있었습니다.
공유 가이드라인이 게시마다 명시적 사용자 동의를 요구한다: 공개범위 드롭다운 기본값 없음, 댓글/듀엣/스티치 기본 전부 꺼짐, 상업콘텐츠 토글 기본 OFF, 게시 버튼 앞 음원 사용 고지, 미리보기 제공, 워터마크·프리셋 문구 금지.
심사 승인이 푸는 제약은 딱 하나입니다 — "미심사 클라이언트의 게시물은 비공개 전용"이라는 제약. 그게 풀리면 공개로 올릴 수 있습니다.
동의 요구는 안 풀립니다. 승인 후에도 게시 한 건마다 사람이 폼을 열고, 미리보기를 보고, 공개범위를 직접 고르고, 게시를 눌러야 합니다. 그래서 저는 애초에 이 API를 무인 스케줄러에 편입하지 않았습니다 — --yes 무인화는 승인의 근거였던 동의 절차를 스스로 깨는 것이니까요. 클릭 승인 폼을 웹으로 따로 만든 이유가 그것이었습니다.
승인 후의 최종 상태를 적어보면 이렇습니다.
- 사람이 폼을 열고 미리보기를 보고 공개범위를 골라 게시를 누른다. 편당 1회.
- 그 플랫폼 앱에서 손으로 올리는 것과 사람 손이 드는 횟수가 같다.
승인이 사왔을 것은 "API로 올릴 수 있음"이라는 사실 하나이고, 아끼는 사람 손은 0회입니다. 유튜브 자동게시가 저에게 준 것(매일 사람 손 0회)을 이쪽은 승인돼도 못 줍니다.
반려는 제가 값을 잃게 만든 사건이 아니었습니다. 값이 애초에 없었다는 걸 드러낸 사건이었습니다.
분모도 없었습니다
하나 더 있습니다. 이 채널의 노출·유입 데이터는 여태 0건입니다. 게시된 건 샌드박스 3편이 전부고 전부 비공개였습니다. 캡션에 URL을 넣어도 클릭이 안 되는 플랫폼이라 유입 경로는 프로필 링크 하나뿐입니다.
즉 승인을 계속 쫓았어도, 승인 다음에 "이 채널이 되는가"를 재려면 노출부터 쌓아야 했습니다. 재측정 날짜만 잡고 기준선을 안 잡은 실험과 같은 계열입니다 — 판정할 숫자가 준비되지 않은 채로 자격을 쫓고 있었습니다.
걷어낸 것: 없음
종결 비용이 0이었습니다. 스케줄 잡 0건, 자동 파이프라인 편입 0건. 승인 전에는 편입하지 않겠다는 규칙을 지켰기 때문에, 내릴 스케줄이 아예 없었습니다.
grep -ril tiktok ~/Library/LaunchAgents/ # 0건
grep -c -i tiktok engine/autopilot.sh # 0코드·자격증명·게시 원장은 전부 보존하고 상단에 종결 배너만 달았습니다. 한 번도 켜보지 않고 닫은 채널이 폐기 비용 0이었던 것과 같은 이유입니다 — 아직 아무것에도 묶여 있지 않으면 떼는 데 드는 것이 없습니다. 배관은 이미 관통돼 있으니(샌드박스 실게시 3편), 정책이 바뀌면 그때 다시 켜면 됩니다.
안 하는 것도 적어뒀습니다. 재제출(사유가 자격이라 무의미) · 심사 서류만 멀티유저 제품처럼 쓰는 것(심사에 거짓을 내는 것) · 기기 자동화로 우회(약관 위반 + 계정 밴 리스크).
자가진단 3줄
심사·승인·자격 대기 중인 트랙이 있다면 이 세 가지를 확인해보세요.
- "승인되면 무엇이 달라지는가"를 한 문장으로 쓸 수 있습니까? 못 쓰면 아직 계산을 안 한 겁니다. 답이 "아무것도"인 트랙이 실제로 있습니다.
- 승인이 푸는 제약과 안 푸는 제약을 구분해 적어봤습니까? 대개 승인은 권한 하나만 풀고, 정작 내가 원했던 자동화는 다른 조항이 막고 있습니다.
- 반려 사유가 "결함"입니까 "자격"입니까? 결함은 고치면 되고, 자격은 고쳐도 안 됩니다. 이 둘을 같은 반사로 처리하면 반려를 계속 벌게 됩니다.
솔직한 부분
아이콘·URL 반려를 고친 작업은 낭비가 아니었습니다. 실제 원인을 실측으로 찾았고, 그 과정에서 CDN이 자동화 요청을 막고 있다는 사실도 알아냈습니다(다른 자동 검증에서 계속 쓰는 정보입니다).
낭비였던 건 진행 중에 트랙 자체의 값을 다시 계산하지 않은 것입니다. 진행 중인 일은 자기 값을 재검토하지 않습니다. "다음 반려를 고치는 것"이 눈앞의 과제가 되면, "이걸 통과해서 뭘 얻나"는 질문이 사라집니다. 첫날 노트에 답이 적혀 있었는데도 2주 동안 그 노트를 다시 열지 않았습니다.
숏폼 자체는 유튜브 3채널로 계속 나갑니다. 렌더 파이프라인도, 큐도 무영향입니다. 잃은 건 이 플랫폼 하나이고, 그게 주려던 것은 처음부터 0이었습니다.
지금 승인·심사·자격을 기다리는 트랙이 있으시다면, 그 승인이 아껴줄 사람 손 횟수를 숫자로 적어보세요. 0이면 지금 접는 게 이득입니다.