uniflow
KO / EN
Self-Growth·개념·2026-08-12

개인 개발자 앱 출시, 코드보다 오래 걸린 것들

AI로 앱 만들기는 빨라졌는데, 정작 오래 걸린 건 코드가 아니었습니다. 무료 PDF 도구 하나를 직접 만들어 배포하며 겪은 심사 지연과 잔손들, 그리고 스크립트와 제품 사이의 거리에 대한 기록입니다.

심사 대기 화면을 6시간째 보고 있었습니다

사내에서 혼자 쓰던 파이썬 스크립트가 하나 있었습니다. PDF를 이미지로 바꾸고 페이지를 정리하는, 그야말로 잡일용 코드였습니다. 파이썬을 모르는 동료가 "그거 나도 쓸 수 있게 해줄 수 있어요?"라고 묻길래, 실행 파일로 묶어서 주기로 했습니다. 거기까지는 반나절이면 될 줄 알았습니다.

개인 개발자 앱 출시는 그때부터 시작해서 일주일 넘게 이어졌습니다. 그리고 그 일주일 동안 제가 코드를 쓴 시간은 절반도 되지 않습니다. 애플 공증 심사 화면에서 "In Progress"만 여섯 시간 넘게 바라본 날도 있었고, 다른 앱은 앱스토어 심사에서 며칠씩 밀렸습니다. 처음에는 제가 뭘 잘못 넣었나 싶었는데, 찾아보니 저만의 일이 아니었습니다.

숫자로 확인한 앱 폭증

체감을 데이터로 확인해봤습니다. 앱 분석 업체 Appfigures 집계 기준으로 2026년 1분기 전 세계 앱 출시는 전년 대비 60% 증가했고, iOS만 보면 80% 증가했습니다. 2026년 상반기에만 App Store에 약 56만 개의 새 앱이 추가됐는데, 이는 2025년 한 해 동안 출시된 총량과 맞먹는 규모입니다.

원인으로 가장 자주 지목되는 건 이른바 바이브 코딩 — AI 도구에 말로 지시해서 앱을 만드는 방식입니다. 만드는 비용이 거의 0에 수렴하니, 제출량이 폭발하는 건 자연스러운 결과입니다.

참고로 일부 매체가 인용하는 "84% 급증"이라는 수치는 산출 근거와 1차 출처가 확인되지 않습니다. 검증 가능한 숫자는 위의 60%(전 세계)와 80%(iOS)입니다.

만들기는 폭발했는데, 통과는 좁아졌습니다

흥미로운 건 스토어의 앱 총량은 오히려 줄고 있다는 점입니다. Google Play는 2024년 초 340만 개 수준에서 2026년 7월 기준 약 189만 개로 감소했습니다. 2025년 한 해 동안 정책 위반으로 차단된 앱만 175만 개입니다.

애플도 2026년 6월 WWDC에서 앱 심사 지침을 개정했습니다. 방치되거나 품질이 낮거나 기존 앱을 베낀 앱은 이미 등록된 것이라도 삭제할 수 있게 했고, 손전등·배경화면·단순 타이머·효과음처럼 이미 포화된 카테고리는 "확실히 더 낫지 않으면" 신규 등록을 받지 않겠다고 명시했습니다. 반복 제출자는 개발자 프로그램 자격을 잃을 수 있다는 경고까지 붙었습니다.

제출은 두 자릿수로 늘어나는데 다운로드 증가율은 연 2~3%에 머뭅니다. 입구는 넓어지고 병목은 심해지는 구조입니다. 애플은 여전히 제출의 90%를 48시간 안에 처리한다고 밝히고 있지만, 나머지 10%의 대기가 길어졌다는 개발자 보고가 이어집니다. 제 여섯 시간은 그 10% 안에 있었던 셈입니다.

개인 개발자 앱 출시에서 정작 오래 걸린 것들

그런데 이 글에서 정말 하고 싶은 이야기는 심사 대기가 아닙니다. 일주일 중 대부분을 잡아먹은 건 코드가 아니라 그 바깥이었다는 사실입니다.

만들어 배포한 무료 PDF 변환 도구에서 실제로 나온 문제들을 적어봅니다.

Advertisement본문 중간 · 반응형본 도메인에서만 게재
  • 윈도우에서만 저장이 실패했습니다. 원본 파일을 열어둔 채로 덮어쓰려 했는데, 윈도우는 파일을 잠급니다. 맥에서는 아무 문제가 없었습니다.
  • 윈도우에서 앱이 실행 즉시 종료됐습니다. 맥 전용 이벤트를 조건 없이 연결한 게 원인이었고, 오류창 없이 조용히 죽어서 원인을 찾는 데만 한참 걸렸습니다.
  • 아이콘이 낯선 디스켓 모양으로 나왔습니다. 빌드 옵션 한 줄이 빠져 있었습니다.
  • 455쪽짜리 PDF를 열었더니 멈췄습니다. 제 테스트 파일은 20쪽이었습니다.
  • 트랙패드 두 손가락 스크롤이 먹지 않았습니다. 제가 늘 쓰는 방식인데도, 개발 중에는 한 번도 확인하지 않았습니다.

코드가 아니라 경계에서 터졌습니다

목록을 다시 보면 공통점이 보입니다. 한 줄도 "알고리즘을 잘못 짰다"는 문제가 아닙니다. 전부 운영체제 차이, 실제 파일 크기, 사용자의 손버릇, 배포 인프라 — 코드와 세상이 만나는 경계에서 터졌습니다.

그리고 이 문제들은 하나같이 누군가 실제로 써봐야만 드러났습니다. AI는 제가 요청한 기능을 아주 빠르게 만들어줬지만, "윈도우에서도 켜지는지"는 묻지 않으면 확인해주지 않습니다. 애초에 물어볼 생각을 하려면 그런 경계가 있다는 걸 알아야 합니다.

스크립트와 제품 사이의 거리

혼자 쓰는 스크립트와 남에게 주는 제품은 전혀 다른 물건입니다. 스크립트는 내가 아는 조건에서만 돌면 됩니다. 파일 경로도 알고, 파일 크기도 알고, 안 되면 그 자리에서 고칩니다.

제품은 그 전제가 전부 사라집니다. 내가 모르는 컴퓨터에서, 내가 예상 못 한 파일로, 내가 없는 자리에서 돌아야 합니다. 그 차이를 메우는 일이 잔손입니다. 경고 문구 하나, 진행 표시 하나, 아이콘 하나, 반대편 운영체제에서 한 번 켜보는 일. 하나하나는 사소하고, 전부 합치면 개발 시간보다 깁니다.

앱 제출이 폭증한 현상도 같은 자리에서 설명됩니다. 만드는 비용은 0에 가까워졌지만 다듬는 비용은 그대로입니다. 그러니 다듬지 않은 결과물이 대량으로 밀려들고, 심사하는 쪽의 부담이 커지고, 결국 규칙이 조여집니다.

그래서 무엇이 품삯이 되는가

이 경험에서 제가 얻은 건 "AI로는 안 된다"는 결론이 아닙니다. 오히려 반대입니다. AI 덕분에 혼자 쓰던 스크립트를 제품으로 만들 생각 자체를 하게 됐습니다. 예전이라면 시작도 안 했을 일입니다.

다만 그 과정에서 값이 매겨지는 지점이 옮겨간 것 같습니다. 코드를 짜는 능력이 흔해질수록, 끝까지 다듬는 사람이 희소해집니다. 그리고 그 다듬는 일은 실력이라기보다 성향에 가깝습니다. 반대편 운영체제에서 한 번 켜볼 생각을 하는가. 455쪽 파일로 열어볼 생각을 하는가. 아이콘이 이상한 걸 그냥 넘기지 않는가.

결국 꼼꼼함과 세심함, 그리고 거기에 시간을 얼마나 들일 것인가의 문제입니다. 그건 코드 실력과는 다른 축이고, 아직은 사람 쪽에 남아 있는 몫으로 보입니다.

물론 이것도 얼마나 갈지는 모르겠습니다. 다만 확실한 건, 앱 하나를 끝까지 올려보기 전에는 이 차이를 이렇게 선명하게 느끼지 못했다는 것입니다. 안 쓰던 근육을 쓴 기분입니다.

Advertisement글 최하단 · 띠배너본 도메인에서만 게재