토스 미니앱 심사는 두 번 받습니다

결론부터 말씀드리면, 토스 미니앱을 내려면 심사를 두 번 받습니다. 앱 정보 심사와 번들 심사입니다. 이 둘은 하나의 절차가 아니라 별개의 큐이고, 앞의 하나는 앱을 다 만들기 전에 먼저 낼 수 있습니다.

저는 마감이 닷새 남은 시점에 이걸 알았습니다. 몰랐다면 늦었습니다.

이 글에서 다룰 것은 두 가지입니다. 1) 두 심사가 어떻게 나뉘고 각각 며칠이 걸리는지, 2) 왜 순서를 바꾸면 시간을 벌 수 있는지.

먼저 불리한 이야기부터 하겠습니다

제가 낸 앱은 ‘눈싸움’입니다. 부엉이와 눈싸움을 해서 이기면 쓸데없는 선물을 받아 모으는 앱입니다. 보도블록 한 장, 다 쓴 건전지 같은 것들입니다.

이 앱은 성과를 내려고 만든 물건이 아닙니다. 단기 노출 창이 있었고, 그 창 안에서 지표를 한 번 관측해 보는 것이 목적이었습니다. 오래 붙잡아 둘 구조가 아니라는 건 만들 때부터 알고 있었습니다.

그러니 아래 이야기는 “이렇게 하면 성공합니다"가 아닙니다. 마감이 있는 일정에서 심사 구조를 잘못 읽으면 어디서 며칠을 잃는가에 대한 기록입니다.

심사가 하나인 줄 알았습니다

처음에는 앱스토어처럼 생각했습니다. 다 만들어서 올리면 사람이 보고 통과시켜 준다, 그게 심사다. 이 그림에서 제가 할 일은 하나뿐입니다. 빨리 만들어서 빨리 올리는 것.

이 그림은 틀렸습니다.

첫째, 앱스토어·플레이스토어 심사는 아예 거치지 않습니다. 토스 앱 안에서 도는 미니앱이라 스토어를 통하지 않습니다.

둘째, 대신 토스 내부 심사가 둘입니다.

앱 정보 심사    1~2 영업일    이름 · 아이콘 · 설명 · 스크린샷
번들 심사       최대 3 영업일  실제로 도는 코드

공식 문서는 앱 정보 검토가 번들 검토에 선행한다고 씁니다. “앱 정보 검토가 끝나야 앱을 출시할 수 있어요"라는 문장입니다.

여기까지 읽고 제가 한 계산은 이랬습니다. 1~2일 더하기 3일이면 최대 5영업일. 그런데 마감까지 닷새였습니다. 주말이 끼면 넘깁니다.

“그러면 둘을 동시에 내면 되지 않나”

제가 제일 먼저 떠올린 우회로입니다. 그리고 이건 안 됩니다.

검토 요청은 한 번에 한 버전만 제출할 수 있습니다. 검토 중에 뭔가를 고치려면 요청을 취소하고 새 번들을 올려야 하는데, 그 순간 최대 3영업일 시계가 처음부터 다시 돕니다.

이 구조에서 재제출은 단순히 “한 번 더"가 아닙니다. 날짜를 통째로 되감는 일입니다. 마감이 있는 일정에서 가장 비싼 실수가 여기 있습니다. 서두르다 덜 된 번들을 올리면, 그 서두름이 사흘을 먹습니다.

그러니 동시에 내는 건 답이 아닙니다. 다른 축을 봐야 했습니다.

갈림길은 “앱을 만들려면 코드가 있어야 하는가"였습니다

콘솔에서 앱을 새로 만들 때 무엇을 요구하는지 직접 확인했습니다.

앱 이름      10자 이내
appName      고유 ID
앱 유형      게임 / 비게임

셋뿐입니다. 번들을 요구하지 않습니다.

이게 갈림길입니다. 앱 정보 심사가 보는 것은 이름·아이콘·설명이고, 이것들은 전부 앱이 완성되기 전에 만들 수 있습니다. 아이콘은 그림이고 설명은 글입니다. 코드가 한 줄도 없어도 됩니다.

그래서 순서를 이렇게 바꿨습니다.

앞으로 뺀 것   앱 정보 제출     코드가 없어도 낸다. 1~2영업일을 여기서 소진
그동안         개발 + 기기 테스트
마지막         번들 제출        재제출이 없어야 한다

두 심사를 겹치게 만든 게 아닙니다. 앞의 심사를 개발 기간 뒤로 숨긴 것입니다. 개발하는 동안 앱 정보 심사가 알아서 돌아가 있으면, 번들을 낼 때는 번들 심사 하나만 남습니다. 최대 5영업일이 최대 3영업일이 됩니다.

그리고 반려됐습니다

앱 정보를 냈고, 반려됐습니다.

사유는 로고였습니다. 제가 올린 로고 두 장은 모서리를 둥글게 깎고 그 바깥을 투명하게 비워 둔 PNG였습니다. 요즘 앱 아이콘이 다 둥그니까 둥글게 만들어 두는 게 맞다고 생각했습니다.

통하지 않았습니다. 배경색으로 꽉 채운 각진 정사각형으로 바꿔서 다시 냈고, 그러자 통과했습니다.

두 장의 차이를 눈으로만 보면 작습니다. 그래서 픽셀을 직접 세어 봤습니다.

                모서리 픽셀의 알파    투명 픽셀 비율
반려된 로고            0                4.1%
통과한 로고          255                0.0%

4.1%가 둥근 모서리를 깎아내면서 생긴 빈 면적입니다. 반려와 통과를 가른 건 색도 모양도 아니고 **이 4.1%**였습니다.

왜 각진 쪽을 요구하는지는 반려 사유에 적혀 있지 않았습니다. 모서리를 깎는 건 플랫폼이 알아서 하니 원본은 꽉 찬 사각형으로 받고 싶은 것이라고 짐작하고 있습니다만, 확인한 건 아닙니다. 확실한 건 결과뿐입니다 — 투명 여백이 있는 로고는 반려되고, 꽉 찬 각진 정사각형은 통과했습니다.

재제출하고 약 1분 만에 승인됐습니다.

여기서 한 가지 배웠습니다. 반려가 전부 사흘짜리는 아닙니다. 규격 문제처럼 기계적으로 확인되는 건 거의 즉시 돌아옵니다. 앞에서 “재제출은 날짜를 되감는다"고 썼는데, 그건 번들 쪽 이야기입니다. 앱 정보 쪽은 훨씬 가볍습니다. 이 차이를 몰라서 저는 반려 메일을 보고 마감을 놓쳤다고 잠깐 생각했습니다.

용어가 어긋나 있었습니다

반려 사유에는 ‘썸네일’이라고 적혀 있었습니다.

저는 스크린샷을 의심했습니다. 세로 이미지 넉 장을 올려 둔 참이었으니 그게 썸네일이겠거니 했습니다. 규격을 다시 재 봤더니 전부 맞았습니다.

콘솔에는 ‘썸네일’이라는 칸이 아예 없습니다. 업로드 슬롯은 앱 로고, 다크모드 로고, 스크린샷 셋뿐입니다. 반려문의 ‘썸네일’은 로고를 가리키는 말이었습니다.

이런 건 문서를 읽어서는 알 수 없습니다. 반려를 한 번 받아야 알게 됩니다. 그러니 반려 사유의 단어가 콘솔의 칸 이름과 안 맞으면, 단어를 믿지 말고 슬롯 목록과 대조하십시오. 실제로 존재하는 칸은 셋뿐입니다.

되돌릴 수 없는 칸이 하나 있습니다

appName입니다. 앱의 고유 ID이고, 생성한 뒤에는 바꿀 수 없습니다.

이름이야 나중에 고치면 된다고 생각하고 앱을 만들면 그걸로 끝입니다. 바꾸려면 앱을 다시 만들어야 하고, 그러면 앱 정보 심사도 다시 받습니다. 앞에서 기껏 앞으로 당겨 둔 그 심사입니다.

저는 앱을 만들기 전에 이 값을 확정하고 들어갔습니다. 이건 운이 좋았던 게 아니라, 콘솔을 먼저 열어 보고 무엇이 수정 불가인지 확인한 덕입니다. 만들기 전에 한 번 열어 보는 데 10분이면 됩니다.

심사 기간은 공식 수치이고, 실제는 밀릴 수 있습니다

1~2영업일과 최대 3영업일은 공식 안내 값입니다.

제가 낸 시기는 출품이 몰리는 때였습니다. 커뮤니티에는 “평소엔 몇 시간이면 끝났는데 닷새째 검토 중"이라는 글이 올라와 있었습니다. 제가 겪은 건 아니라 사실로 단정하지는 않겠습니다 — 다만 물량이 몰리는 시기에 공식 기간을 그대로 믿고 일정을 짜는 건 위험하다고 봅니다. 이건 제 판단입니다.

마감이 있다면 공식 기간에 최소 이틀은 얹어서 잡으십시오.

정리하면

심사를 하나로 세면 일정이 틀립니다.

두 개로 세고, 앞의 하나를 개발 기간 뒤로 숨기십시오. 코드가 없어도 낼 수 있는 심사입니다.

그리고 번들은 딱 한 번만 내십시오.