프랑스의 요금표는 당신에게 유로를 제시합니다. 하지만 프로젝트가 왜 지연되는지 이해하고 싶을 때는 쓸모가 없습니다.

저희는 최근 모바일 프로젝트들의 시간 추적 데이터를 다시 분석하여 모든 것을 기능 단위별 시간으로 재분류했습니다. 유로가 아닌 시간입니다. 시간이란, 견적을 내주는 사람의 일일 단가(TJM)에 의존하지 않기 때문입니다.

간단한 결론: 비용이 많이 드는 것은 고객이 생각하는 것과 거의 다릅니다.

실제 배분 (시간 기준)

기준: React Native + Expo를 사용한 앱, Supabase 백엔드, iOS + Android용. 약 700시간 분량의 표준 프로젝트입니다.

우리가 빠졌던 함정: 우리는 outbox를 메모리에 저장하는 방식으로 첫 버전을 출시했습니다. 사용자가 결제 단계(tunnel)에서 앱을 종료하면, 마지막 6개의 동작이 사라집니다. 아무런 경고 없이 말이죠. 프로덕션 배포 3주 후, 로그 대조를 통해 이 사실을 발견했습니다. 복구 작업에 22시간이 소요되었습니다.

결제 기능에 90시간이 소요되는 이유

SDK 구현은 반나절이면 충분합니다. 나머지는 모두 정합성 맞추기(reconciliation) 작업입니다.

클라이언트 측에서 확인된 구매는 아무것도 증명하지 못합니다. 서버 측에서 영수증을 검증하고, 갱신 웹훅(webhooks), 환불, 유예 기간(grace periods), 무료 체험, 플랜 변경, 그리고 사용자가 iOS에서 구매한 후 Android에서 로그인하는 경우 등을 모두 처리해야 합니다.

// Apple 웹훅 — 구독 상태는 절대로 클라이언트로부터 오지 않습니다
const notif = await verifyAppleSignedPayload(req.body.signedPayload)

...

여기에 두 배를 곱하십시오. Google Play는 자체적인 의미론(semantics), 상태(states), 용어(vocabulary)를 가지고 있습니다. 두 개의 구현, 두 세트의 테스트, 그리고 변덕스러운 두 개의 샌드박스(sandbox) 환경이 필요합니다.

발견된 함정: Apple의 샌드박스는 구독 기간을 압축합니다 (1개월 = 몇 분). 이를 고려하지 않고 작성된 갱신 테스트는 샌드박스에서는 통과(green)되지만 프로덕션에서는 실패합니다. 우리는 30일 후 프리미엄 액세스 권한을 잃은 실제 사용자를 통해 이 문제를 발견했습니다.

AI 어시스턴트가 시간을 절약해 주는 곳 — 그리고 그렇지 않은 곳

우리는 매일 Claude Code와 함께 작업합니다. 이점은 실재하지만 매우 불균등하게 분포되어 있으며, 이는 정확히 발표된 데이터와 일치합니다.

Stanford의 연구를 인용한 Google Cloud의 DORA 보고서에 따르면: 단순한 작업과 새로운 코드에서는 35-40%의 이득이 있지만, 복잡한 레거시(legacy) 코드에서는 10% 미만입니다. 동일한 보고서는 1년 동안 작성자당 풀 리퀘스트(pull requests)가 20% 증가했음을 측정했으며, 채택률은 약 90%에 달합니다. Stack Overflow 2025는 사용자의 84%가 사용 중이며, 51%가 매일 사용한다고 밝혔습니다.

위 표의 구성 요소들에 대한 저희의 자체적인 배분은 다음과 같습니다:

고객에게 중요한 결과는 다음과 같습니다: 이점은 이미 크게 무겁지 않았던 영역에 초점을 맞춥니다. 가격 자체를 바꾸는 것이 아니라, 그 위치를 이동시키는 것입니다.

솔직하게 언급할 반론(contre-point)이 있습니다. 2025년 7월의 랜덤화 임상시험인 METR (arXiv 2507.09089)은 숙련된 개발자들이 AI를 사용했을 때 19% 더 느리다고 측정했지만, 그들은 자신들이 20% 더 빠르다고 추정했습니다. METR은 2026년 2월에 방법론적 결함(선택 편향, biais de sélection)을 인정했습니다. 따라서 이 수치는 그대로 유지되지 않지만 — 인식과 현실 사이의 격차는 여전히 좋은 상기시켜주는 점입니다: 시간을 측정하고, 추정하지 마십시오.

실제로 우리가 하는 일

우리가 기획 단계에서 적용하는 세 가지 사고방식(réflexes)이 있습니다:

1. 5분 만에 '오프라인 여부?'와 '결제 방식?'을 묻습니다. 마지막에가 아니라요. 이 두 답변이 예산의 3분의 1을 결정합니다.
2. 전체 패키지(forfait global)로가 아닌, 브릭별 시간으로 견적을 냅니다. 고객은 자신이 무엇을 구매하는지 보고 항목별로 판단할 수 있습니다.
3. 가능하다면 v1부터 오프라인 우선(offline-first) 방식을 적용합니다. 읽기 전용 캐시와 명확한 메시지가 130시간 대신 15시간으로 80%의 사용 사례를 커버합니다.

유로화로 번역하거나, 전체 세부 내역과 3년간의 비용이 궁금하다면: 모바일 앱 개발 가격 2026년: 실제 수치.

그리고 저희 도구에 대해서는: Claude Code로 애플리케이션 만들기.

여러분의 브릭은 측정하셨나요? 비율이 저희와 다르신가요? 댓글을 남겨주세요.