출시 사고 21건, 에러는 0건이었다 — 1인 개발 석 달의 사고 연대기와 그 뒤에 만든 출시 게이트

올해 8월 중순부터 미니게임과 앱을 본격적으로 쏟아내기 시작했습니다. 지금 Google Play에 올라 있는 앱은 88개이고, 토스 앱인토스는 워크스페이스 한도 50개를 다 채웠습니다. 그 석 달 동안 출시 사고를 21건 밟았습니다.

돌아보니 21건 모두 공통점이 하나 있었습니다. 아무것도 에러를 내지 않았습니다. 빌드는 성공했고, 콘솔은 초록불이었고, 앱은 열면 멀쩡히 돌아갔습니다. 그래서 길게는 5주 동안 몰랐습니다.

이 글은 그 21건을 정리한 기록입니다. 사고마다 무엇이 잘못됐는지, 얼마나 몰랐는지, 왜 못 잡았는지, 지금은 무엇이 막는지를 적었습니다. 금액은 적지 않습니다.

한 문장으로 줄이면

콘솔의 초록불(승인, 활성, 발송 완료)은 성공 지표가 아니다. 성공 지표는 항상 사용자 쪽에서 본 값이다.

실기기에서 배너가 보인다, 동의 시트가 실제로 뜬다, 발송 수가 올라간다, 다른 앱 홈에 아이콘이 뜬다, 주소를 직접 열면 200이 온다. 21건은 전부 이 중 하나를 확인하지 않아서 생겼습니다.

1. 심사에서 걸린 것

날짜	사고	왜 못 잡았나	지금 막는 장치
8/15	Play 첫 심사 “잘못된 개인정보처리방침” 반려	사이트 전체가 404였는데 주소를 직접 열어 보지 않았다	제출 전에 방침 URL 응답 코드를 직접 확인
8/15	토스 “접속 직후 바텀시트” 반려	사용 횟수 조건이 있었는데도 검수자가 연타하면 진입 직후로 판정됐다	같은 세션에서 한 판 이상 해야 시트가 뜨는 조건
8/29	아동 앱(수학 몬스터) Play 가족 정책 반려 — 다른 앱 소개 목록에 타로·사주가 보였다	목록이 실행 중에 받아 오는 CSV라 빌드와 무관하게 노출이 바뀌었다	앱 레지스트리에 아동 여부를 반드시 적고, 아동 앱은 아동 앱만 보여 주는 필터
9/19~20	토스 “최초 접속 20초 초과”로 신규 6종이 13번 반려	20초가 네트워크 시간이 아니라 화면이 안정되는 시점이었다	첫 로딩 외부 요청 0개 검사, 첫 화면 16초 동안 변화 없음 검사
11/6	Play “유효한 개인정보처리방침 페이지가 아님” 반려	정본으로 넘어가는 리다이렉트 주소(www)를 썼는데, 자동 검사는 통과하고 사람 검토만 거부했다	방침 URL은 리다이렉트 없는 정본 하나만

20초 반려는 원인이 두 겹이었습니다. 첫 화면에서 바깥으로 나가던 요청(아이콘, CSV, 광고 스크립트)을 없앤 뒤에도 반려가 이어졌고, 실기기를 지켜본 사용자가 “화면이 계속 바뀐다”고 짚어 줬습니다. 다른 앱 소개 목록이 로딩 뒤에 통째로 다시 그려지면서 10~20초 동안 화면이 움직이고 있었습니다. 자세한 과정은 토스 20초 콜드 스타트 글에 있습니다.

2. 수익이 조용히 0이었던 것

날짜	사고	몰랐던 기간	지금 막는 장치
8/26	AdMob 계정 무효 트래픽으로 29일 정지	정지 통보로 앎	개발 빌드는 샘플 광고 ID만, 실광고 ID는 출시 빌드에서만 검사
9/10	토스 10종이 광고 지면 0개로 라이브	2일	래퍼마다 광고 지면 설정이 있는지 자동 검사
9/13	보상형 광고 시트의 ‘다음에 할게요’ 버튼이 배너 뒤로 깔려 광고 강제처럼 보였다	그날	화면 바닥에 고정된 요소가 배너 높이를 비우는지 검사

광고 지면 0개 사고가 제일 무서웠습니다. 광고가 없어도 게임은 완전히 정상이라 사용자 쪽에서도, 콘솔에서도 이상 신호가 없었습니다. 앱별 광고 수익을 날짜별 표로 쌓는 장부를 만들다가, 그 10개 칸이 0인 걸 보고서야 알았습니다(광고 지면이 빠진 채 출시된 이야기).

AdMob 정지는 개발폰과 가족 폰에 실광고 ID가 든 빌드를 깔아 둔 것이 원인이었습니다. 이의 신청도 안 되고 정지 기간에는 콘솔에 들어갈 수도 없었습니다(무효 트래픽 정지 기록).

3. 동작은 하는데 아무도 못 본 것

날짜	사고	몰랐던 기간	지금 막는 장치
8/19	다른 앱 소개 목록이 4줄짜리 옛 CSV로 남아 신작이 어디에도 안 떴다	며칠	레지스트리를 사이트로 내보내는 명령이 구조 검사를 먼저 돌린다
9/4	Play에 라이브된 6종이 사이트 레지스트리에서 ‘미출시’로 남았다	3일	스토어가 라이브인데 사이트 설치 페이지가 없으면 실패
9/12	Play 등록정보 언어 수가 앱마다 1·2·29개로 제각각, 동영상은 2개 언어에만	수 주	기준 29개 언어, 한국어 전용 앱은 명단으로 따로 관리
9/14	토스 ‘핵심 지표’가 29개 앱 전부 비어 있었다 — 노출·추천 최적화에 쓰이는 입력	5주	토스 등록 단계에 수동 확인 항목
11/1~3	사이트 배포가 네 번 실패 — 새 앱 5개의 아이콘 파일이 없었다	3일	앱 아이콘 존재 검사, 출시 표시보다 아이콘을 먼저

가장 오래 몰랐던 것이 토스 핵심 지표입니다. 콘솔에 안내 문구는 있었지만 출시 절차에 그 항목이 없어서 다섯 주 동안 29개 앱이 빈칸이었습니다. 배포 실패는 푸시가 곧 배포가 아니라는 걸 알면서도 확인을 빼먹은 경우입니다(앱 15개를 하루에 만든 기록).

4. 데이터가 거짓말을 한 것

날짜	사고	몰랐던 기간	지금 막는 장치
9/7	토스 기능성 푸시 동의자 0명 — 동의를 요청하는 코드 자체가 없었다	3주	앱 코드에 동의 요청과 ‘판 끝’ 신호가 있는지 자동 검사
9/8	뱀 게임의 토스 설명이 “950”으로 나갔다 — 다른 칸의 숫자가 밀려 들어갔다	4일	레지스트리 CSV 구조 검사
9/12	동의 시트가 안 뜬 진짜 원인은 그룹 코드와 템플릿 코드 불일치	3주	래퍼의 템플릿 코드가 콘솔 값과 같은지 검사
9/12	시트가 실패했는데도 ‘물어봤다’로 기록해 그 기기를 영구히 다시 묻지 않게 만들었다	—	시트가 실제로 떴다는 결과값일 때만 기록, 다음 날 발송 수로 확인
10/27	토스 분석 이벤트의 커스텀 값이 전부 사라지고 있었다 — 래퍼 25개가 같은 형식 오류	수 주	아직 자동 검사 없음, 화면 이벤트 대비 비율로 수동 확인

푸시 사고는 세 겹이었습니다. 콘솔은 매일 “발송 완료”를 띄웠는데 받을 사람이 0명이었습니다. 요청 코드를 넣자 이번에는 코드 불일치로 시트가 안 떴고, 고치자 실패한 요청까지 ‘물어봤다’로 기록하고 있었습니다. 세 개를 다 고치는 데 3주가 걸렸습니다(푸시 동의 근본 원인).

분석 이벤트 사고는 아직 자동 검사가 없는 유일한 항목입니다. “이벤트는 원래 적게 잡힌다”고 넘겼는데, 실제로는 값이 전부 빠지고 이름만 남고 있었습니다. 그동안의 성장 프로그램 측정은 이 버그 때문에 거의 쓸 수 없었습니다.

5. 빌드와 배포가 조용히 틀린 것

날짜	사고	몰랐던 기간	지금 막는 장치
8/31	토스 번들 6개가 전부 같은 게임이었다	테스트 푸시까지 나감	업로드 전 번들 안 페이지 제목 확인
9/11	예약 글의 태그 2048이 숫자로 해석돼 공개일 빌드가 죽었다	그날 글 미배포	예약 글 점검 스크립트
11/7	사이트에 음성 파일 6,147개를 넣자 배포가 10분 시간 초과로 전부 실패	그날	사이트 파일 수를 3,300개 수준으로 관리

같은 게임 6개 사고는 래퍼 폴더를 복사한 뒤 경로를 바꾸는 단계가 조용히 실패해서 생겼습니다. 번들은 정상으로 만들어졌고 업로드도 됐습니다. 테스트 푸시를 연 뒤에야 여섯 개가 모두 같은 화면이라는 걸 알았습니다.

그 뒤에 만든 것 — 출시 게이트

9월 12일부터 규칙을 하나 정했습니다. 체크리스트가 전부 체크되고 검사 도구가 통과하기 전에는 “출시 완료”라고 말하지 않는다. 스토어에 보이는 건 출시의 절반이라는 뜻입니다.

구성	내용
자동 검사	72개. 레지스트리, 개발, 광고, 빌드, 토스, 사이트 단계로 나뉜다
체크리스트	앱마다 98항목. 자동 40, 수동 52, 나머지는 해당 없음 표시
판정	체크 안 된 항목이 하나라도 있으면 실패
증거	수동 항목은 날짜, 수치, 명령 출력과 함께 체크한다
보조 도구	첫 로딩 검사, 첫 화면 안정 검사, 광고 지면 검사, 배너 가림 검사, 뒤로가기 검사, 허브 최신판 검사, QR 디코드 검사

자동 검사는 기계가 셀 수 있는 것을 셉니다. 광고 지면 설정이 있는가, 푸시 템플릿 코드가 같은가, 첫 로딩에 외부 요청이 없는가, 사이트에 아이콘과 설치 페이지가 있는가, QR을 찍으면 맞는 주소가 나오는가.

기계가 못 보는 것은 수동 항목으로 남깁니다. 실기기에서 배너가 실제로 보이는가, 동의 시트가 실제로 뜨는가, 다음 날 발송 수가 0보다 큰가. 이런 항목은 “했다”가 아니라 “사용자에게 동작하는 걸 확인했다”로 체크하고, 확인한 값을 같이 적습니다. 그래서 출시 직후 앱 상태는 ‘출시 완료’가 아니라 ‘출시됨(검증 대기)’이고, 다음 날 수치까지 확인해야 닫힙니다(14개를 같은 날 내고 일주일).

배운 것

• 에러가 없다는 건 아무 뜻도 없습니다. 21건 모두 에러 없이 일어났습니다. 확인은 항상 결과 쪽에서 합니다.
• 콘솔 숫자 대신 사용자 쪽 값을 봅니다. “발송 완료”가 아니라 받은 사람 수, “활성”이 아니라 실기기 화면입니다.
• 규칙을 적었으면 기존 앱에도 적용합니다. 그룹 코드 사고는 규칙을 문서에 적어 놓고 이미 나간 앱에는 적용하지 않아서 3주를 끌었습니다.
• 사람 기억은 배치가 커지면 반드시 빠뜨립니다. 앱 15개를 하루에 낼 때 기억에 기대면 하나는 빠집니다. 셀 수 있는 건 기계가 셉니다.
• 도구가 못 잡는 사고는 계속 생깁니다. 분석 이벤트 사고는 게이트가 생긴 뒤에 발견됐습니다. 체크리스트는 사고가 날 때마다 한 줄씩 늘어납니다.

만든 앱들은 GAMES와 APPS에 있고, 일부는 브라우저에서 바로 해볼 수 있습니다. 소식은 이 블로그와 인스타그램(@fadongkwon.soft)↗ (새 창에서 열림)에서 전해드립니다.

이 글의 사고와 날짜는 2026년 8월~11월 제 출시 기록(출시 체크리스트의 사고 표와 작업 기록)에서 옮겼습니다. 심사 기준과 콘솔 동작은 바뀔 수 있으니 같은 작업을 하신다면 최신 가이드를 먼저 확인해 주세요.