사진 앱 3개를 만든 뒤에야 시장 조사를 했다: 올해 나온 경쟁 앱 설치 중앙값 1,166

올해 들어온 압축 앱 32개 중 26개가 설치 1만 미만이었습니다

사진 압축 범주의 숫자가 가장 먼저 나왔습니다. 한국어 6개, 영어 3개 검색어로 상위 30위를 모으니 앱이 103개였고, 제목에 압축·용량·리사이즈 같은 단어가 있는 유틸만 남기자 71개였습니다. 그중 47개가 2025~2026년, 32개가 2026년에 나왔습니다.

2026년에 나온 32개의 누적 설치는 최대 73,286이었고, 10만을 넘긴 앱은 0개, 1만 미만이 26개였습니다. 우리와 같은 "업로드용 사진 만들기" 자리를 노린 올해 앱은 설치가 0이었습니다. 상위권은 2013~2022년에 나온 앱들이 차지했습니다. 맨 위 앱은 4,306만 설치였습니다.

한 시간 반 뒤 같은 방법으로 나머지 두 범주도 봤습니다. 사진 반전·회전은 검색 결과 유틸 46개 중 2026년 신규가 7개뿐이고, 설치 중앙값은 373입니다. 형식 변환은 71개 중 38개가 올해 나왔고 중앙값은 셋 중 가장 낮은 136입니다. 세 범주 모두 2026년 신규 앱 가운데 10만 설치를 넘긴 앱은 없었습니다.

20일 뒤인 10월 23일 운영 점검에서, Play 공개 페이지의 다운로드 표시는 사진 용량 줄이기 5+, 반전·회전 1+, 형식 변환 0+였습니다. 공개 20일 된 앱의 숫자라, 최대 10개월 쌓인 다른 앱의 누적값과 나란히 비교할 수는 없습니다. 출발이 느리다는 신호까지만 읽습니다.

확인을 생략한 이유는 만드는 쪽이 더 싸 보였기 때문입니다

시장 확인이 빠진 원인은 세 단계로 이어져 있었습니다.

첫째 단계는 앱 목록을 기능으로 정한 것입니다. 9월 21일에 고친 기획서(PRD)는 앱 14개를 정하면서, 후보마다 기존 개발사 한 곳의 앱을 "기준 앱"으로 붙였습니다. 같은 절에는 다운로드 순위나 수익 예측을 이 순서에 반영하지 않았다고 스스로 적어 두었습니다.

둘째 단계는 기준 앱이 만든 착시입니다. 압축 앱의 기준 앱은 389만 설치였고, 검색 상위권도 2013~2022년에 나온 수백만~수천만 설치 앱들이었습니다. 살아남은 앱만 보면 "같은 기능을 더 깔끔하게 만들면 몫이 있다"는 생각이 자연스럽게 듭니다. 올해 들어온 앱들이 어떻게 됐는지는 아무도 보지 않았습니다.

셋째 단계가 가장 컸는데, 만드는 비용이 너무 낮았습니다. 사진 반전·회전 앱은 엔진 커밋(7821dbd, 9월 24일 13:29)부터 내부 테스트 트랙 업로드(bc0ea78, 20:51)까지 7시간 22분이 걸렸고, 형식 변환 앱은 그날 밤 22:39에 내부 트랙에 올라갔습니다(7b9fd55). 심사와 스토어 등록을 빼면 하루 안에 앱 하나가 나오니 "일단 내고 숫자를 보자"가 합리적으로 보였습니다. 정작 수집은 4분이면 끝나는 일이었습니다.

근본 원인은 절차였습니다. 릴리스 게이트와 실기기 확인은 다 있었지만 "만들기 전에 시장 숫자를 본다"는 관문은 없었습니다. (그 게이트들 이야기는 AI 코딩 에이전트로 20일 만에 Android 앱 4개를 출시한 방법에 있습니다.)

처음 가설 세 개는 데이터로 뒷받침되지 않았습니다

첫 가설은 "기존 상위 앱의 불만을 막은 앱이면 설치가 난다"였습니다. 상위 6개 앱의 최신 리뷰에서 3점 이하 127건을 주제별로 세니 광고 과다가 39건, 오류 19건, 유료·구독 17건, 용량이 목표대로 안 줄어든다는 불만이 12건이었습니다. 우리 앱은 구독이 없고, 결과가 원본보다 커지지 않게 막혀 있습니다. 그런데 올해 들어온 32개 중 26개는 설치 1만에도 못 갔습니다. 이 숫자는 불만을 막은 앱과 막지 않은 앱을 나눠 세지 않았으므로 가설을 직접 반박하지는 못합니다. 불만을 막는 것만으로 설치가 난다는 근거도 데이터에는 없었습니다. (불만 1위인 광고는 우리 앱에도 있었습니다. 9월 23일 1.0.3에서 운영자 결정으로 켜 둔 앱 오프닝 광고를 에이전트가 같은 유형이라고 보고했고, 운영자는 유지했습니다.)

두 번째 가설은 운영자가 냈습니다. 세 앱을 하나의 통합 사진 유틸로 묶으면 사람들이 찾을 거라고 봤습니다. 에이전트가 바로 "사진 도구 모음", "사진 유틸", "이미지 도구"를 검색해 보니 상위는 기본 사진 앱, 갤러리, 대형 사진 편집기 같은 범용 앱이었습니다. 범주 이름 검색 결과는 범용 앱이 차지했다는 것까지가 데이터입니다. 검색량은 공개되지 않으니, 그렇게 검색하는 사람이 몇 명인지는 모릅니다.

같은 날 오후에 문서 뷰어 쪽도 같은 질문으로 봤습니다. 한 개발사가 낸 앱 세 개를 비교하니 한글 문서 뷰어 하나는 436k, PPT 뷰어 하나는 469k 설치였고, 통합 오피스 앱은 13k였습니다. 개발사 한 곳의 앱 세 개이고 한글 뷰어 수요는 정책 변화와 겹쳐 있어서, 이것으로 "통합보다 단일이 낫다"를 증명하지는 못합니다. 방향 신호로만 봤습니다. 세 번째 가설 "AI 기능을 붙이면 다르게 보인다"는 리뷰로 따져 봤습니다. 한국어 문서 뷰어 리뷰 15,043건 가운데 AI·요약·번역을 요청한 리뷰는 0.36%였습니다. 리뷰에서 요청이 드물다는 뜻이지, AI 기능이 차별점이 될 수 없다는 증거는 아닙니다. 두 신호가 같은 쪽을 가리켜서 다음 앱은 한글뷰어 슈가독 하나로 좁혔습니다.

에이전트는 기획서 순서를 따랐고, 중앙값 식도 틀렸습니다

코딩 에이전트는 기획서의 순서를 그대로 실행했습니다. 세 번째 앱을 올리는 동안 "다음 앱을 만들기 전에 시장을 보자"고 먼저 말한 적이 없습니다. 운영자가 물었을 때 에이전트는 동향 분석을 하지 않았다고 인정했고, 기획서의 "예측이 아니다" 문구를 근거로 들었습니다.

숫자에도 작은 오류가 있었습니다. 이 글을 쓰며 수집 스크립트를 다시 읽어 보니 정렬한 목록 s에서 중앙값을 s[len(s)//2]로 구했더군요. 값이 32개일 때 이 식은 가운데 두 값 중 큰 쪽(1,304)을 줍니다. 가운데 두 값 1,028과 1,304의 평균인 진짜 중앙값은 1,166입니다. 결론은 같지만 보고서에 남은 1,304는 위쪽 중앙값이라, 이 글은 1,166을 씁니다. 반전·회전은 값이 7개(홀수)라 373이 정확합니다. 형식 변환은 38개(짝수)라 136도 위쪽 중앙값인데, 값 목록이 기록에 남지 않아 다시 계산하지 못했습니다. 진짜 중앙값은 136 이하입니다.

계획한 앱 11개를 보류로 기록하고 범주를 바꿨습니다

선택지는 네 가지였습니다.

• U04~U14 11개를 계획대로 계속 만들기: 사진 세 범주와 같은 분포라면 같은 결과를 11번 반복합니다. 다만 이 11개 범주는 아직 수집하지 않았습니다. 10월 4일 백로그에 보류로 기록했습니다.
• 광고로 설치를 사기: 설치 한 건이 돌려주는 값을 실측하기 전에는 하지 않기로 했습니다.
• 이미 만든 세 앱을 내리기: 공개해 두는 비용은 거의 없고, 사용자가 실제로 친 검색어는 공개한 뒤에만 Play 콘솔에서 보입니다. 그래서 그대로 두고 30일 동안 숫자를 봅니다.
• 수요가 바뀌는 범주로 옮기기: 공공기관 메일이 2026년 10월부터 .hwp 첨부를 막아 HWPX 문서가 늘어나는 시점이었습니다. 이 범주에서는 2026년 5월에 나온 앱 하나가 417,538 설치까지 갔습니다. 이것을 골랐습니다.

확인 방법에도 다른 길이 있었습니다. 유료 앱 시장 분석 서비스는 설치 추이와 검색어 추정치를 보여 주지만 구독 비용이 듭니다. Play가 검색량을 공개하지 않으니 키워드 도구가 주는 Play 검색량은 어디까지나 추정치입니다. 인기 차트 페이지를 손으로 살펴보면 돈은 안 들지만, 차트 상위만 봐서는 올해 들어온 앱들의 분포가 나오지 않습니다. 스크립트를 고른 이유가 따로 기록돼 있지는 않습니다. 에이전트가 이미 그 저장소에서 일하고 있었고, 비용이 몇 분이었다는 것이 실제 조건이었습니다.

한글뷰어는 10월 4일 착수해 10월 10일에 공개했고, 광고 SDK 없이 냈습니다. 착수 전에 리뷰 데이터와 렌더링 실험을 먼저 했다는 점이 사진 앱 때와 다릅니다. (렌더링 실험은 안드로이드 한글 뷰어 만들기: rhwp + WebView를 문서 222개로 실측한 기록에 적었습니다.)

새 앱을 만들기 전에 올해 들어온 같은 범주 앱의 설치 중앙값부터 보십시오.

만들기 전에 돌리는 15분 절차

10월 3일에 돌린 순서에, 그날 빠졌던 2번(판정 규칙 먼저 적기)을 더했습니다. 수집은 Python 라이브러리 google-play-scraper로 했습니다. Play 공식 API가 아니라 Play 웹 페이지를 읽는 비공식 라이브러리입니다.

1. 사용자가 칠 검색어를 할 일 단어로 6~9개 적습니다. 우리는 "사진 용량 줄이기", "사진 KB 줄이기", "compress image" 등 한국어 6개, 영어 3개를 썼습니다.
2. 판정 규칙을 숫자를 보기 전에 적어 둡니다. 예: 올해 신규 앱의 설치 중앙값이 천 단위이고 10만을 넘긴 앱이 0개면, 범용 기능 하나짜리 앱은 만들지 않는다.
3. 검색어마다 상위 30위의 앱 ID를 모으고, 앱마다 누적 설치, 출시일, 평점 수, 광고·인앱 결제 여부를 읽습니다.
4. 제목 단어로 같은 일을 하는 앱만 남깁니다. 우리는 범용 사진 편집기, 동영상, PDF 앱을 제외 목록으로 걸러 냈습니다. 103개가 71개가 됐습니다.
5. 출시 연도가 올해인 앱만 골라 개수, 설치 중앙값(값이 짝수 개면 가운데 두 값의 평균), 최대, 1만 미만 개수, 10만 이상 개수를 셉니다. 상위 10개 앱의 출시 연도도 봅니다.
6. 내 앱 ID가 결과 목록에 있는지 확인합니다.
7. 상위 6개 앱의 최신 리뷰를 앱마다 최대 200건 받아 3점 이하만 남기고, 광고·결제·오류 같은 주제 단어로 셉니다.
8. 범주 이름("사진 유틸" 같은 것)으로도 한 번 검색합니다. 통합 앱을 생각하고 있다면 이 결과를 먼저 보십시오.

아래는 그날 돌린 수집 코드를 3~6단계에 맞춰 정리한 판입니다. 이 정리판 자체는 실행해 보지 않았고 문법 검사만 거쳤으니, 검색어와 두 정규식은 자기 범주에 맞게 고쳐 쓰십시오. 중앙값은 statistics.median으로 구합니다. 앞에서 말한 위쪽 중앙값 오류를 막는 줄입니다.

import re, statistics, time
from google_play_scraper import search, app

QUERIES = [("사진 용량 줄이기", "ko", "kr"), ("사진 KB 줄이기", "ko", "kr"), ("compress image", "en", "us")]
KEEP = re.compile(r"압축|용량|크기|사이즈|compress|resiz|kb|size", re.I)
DROP = re.compile(r"video|동영상|pdf|editor|편집", re.I)
YEAR, MY_APP = 2026, "com.example.myapp"

ids = set()
for q, lang, country in QUERIES:
    ids |= {r["appId"] for r in search(q, lang=lang, country=country, n_hits=30) if r.get("appId")}
    time.sleep(1)

rows = []
for app_id in sorted(ids):
    try:
        d = app(app_id, lang="ko", country="kr")
    except Exception:
        continue
    time.sleep(0.4)
    name = f'{d.get("title") or ""} {app_id}'
    if not KEEP.search(name) or DROP.search(name):
        continue
    m = re.search(r"\d{4}", d.get("released") or "")   # "Oct 3, 2026" or "2026. 10. 3."
    rows.append((int(m.group()) if m else None, d.get("realInstalls") or 0))

new = [n for y, n in rows if y == YEAR]
print("same-task apps:", len(rows), "| released in", YEAR, ":", len(new))
if new:
    print("median", statistics.median(new), "| max", max(new),
          "| under 10k", sum(n < 10_000 for n in new), "| 100k+", sum(n >= 100_000 for n in new))
print("my app in results:", MY_APP in ids)

4분은 한 범주의 수집과 첫 보고에 걸린 시간(09:47~09:51)입니다. 검색어를 고르고, 사람이 결과 표를 판정 규칙과 맞춰 보는 시간까지 넣어 15분을 잡습니다.

중앙값이 기대치가 아닌 이유와 데이터의 빈칸

표본부터 한쪽으로 기울어 있습니다. 검색어 9개의 상위 30위에 든 앱만 표본에 들어갔고, 순위에 오르지 못한 올해 앱은 빠졌습니다. 올해 나온 같은 종류 앱 전체의 중앙값은 1,166보다 낮을 가능성이 높습니다. 1,166은 검색 상위에 든 올해 앱의 결과라 "잘 만든 앱의 기대치"로 읽을 수 없습니다. 그 안에서도 1만을 넘긴 앱이 6개 있었습니다(최대 73,286).

수요가 갑자기 바뀌는 범주에서는 지난 분포가 앞날을 말해 주지 않습니다. 문서 뷰어가 그런 예였습니다. 정책 변경 직후라 신규 앱이 수십만 설치를 얻고 있었습니다.

설치 수는 전 세계 누적이고, 검색 순위는 로그인하지 않은 결과라 실제 사용자 화면과 다를 수 있습니다. 리뷰 주제는 단어 정규식으로 세었기 때문에 한 리뷰가 여러 주제에 들어갈 수 있고, 앱 6개의 최신 리뷰만 봤습니다. 출시일 필드가 빈 앱은 연도 집계에서 빠집니다. 라이브러리가 웹 페이지 형식에 기대므로, Play가 페이지를 바꾸면 수집이 깨집니다.

다음에 확인할 것

사진 용량 줄이기의 30일 측정이 11월 2일에 끝납니다(측정 예정, 2026-11-02). 그때 노출, 설치 전환율, 실제 유입 검색어를 보고 세 앱을 하나로 합칠지 정합니다. 2026년 10월 24일 기준으로 통합 작업은 시작하지 않았습니다.

보류로 기록한 U04~U14 범주(사진 PDF, 동영상, 오디오 등)는 아직 하나도 수집하지 않았습니다. 보류가 맞는지는 같은 절차로 그 범주들을 수집해 봐야 판단할 수 있고, 운영자도 보류를 명시적으로 확정하지 않았습니다. 다음 수집은 중앙값을 고친 스크립트로 돌립니다.

자주 묻는 질문

다른 AX 노트

• 대개편 직후 DAU는 올랐고, 자연 유입 코호트 D1은 15.2%에서 11.2%로 내려갔다
• 커밋 701개로 본 AI 코딩 1년: '완성'에서 '원인·검증'으로
• AI 코딩 에이전트로 20일 만에 Android 앱 4개를 출시한 방법
• Android assets를 미리 gzip한 실측: APK 이득은 0, .pack.gz는 .pack이 되어 FileNotFoundException
• SKT 판매 삼성 폰에서 market://을 열면 스토어 선택 창이 뜬다: Play 패키지부터 지정하기
• addOnCompleteListener(this)가 onStop에서 지운 리스너 때문에 스플래시에 멈춘 버그

회고와 숫자 글 전체 보기 · AX 노트 전체 보기