Cursor, Lovable, Bolt, v0 등으로 만든 앱을 완성하는 작업을 맡게 될 때, 가장 먼저 해야 할 일이 있습니다. 리포지토리를 30분만 읽고, 5가지 항목의 견적을 작성하는 것입니다. 이 항목들은 항상 동일하며, 그중 단 하나라도 무너지면 '3~5일'이라는 기간은 성립하지 않습니다.
견적 이야기를 할 때 대부분 사람들은 '화면이 몇 장인가'로 계산합니다. 하지만 화면 수는 코드 베이스 내에서 정보량이 가장 적은 숫자입니다. 4개의 화면으로 구성된 앱이 14개 화면의 앱보다 두 배 더 걸리는 일은 흔하게 발생합니다. 그 이유는 작업량을 결정하는 것이 화면 자체가 아니라 **연결점(seam)**이기 때문입니다.
아래에 실제로 사용하고 있는 5가지 항목과, 가상의 예약 앱 사례를 제시합니다.
모든 화면을 포함하는 것은 아닙니다. 최초의 유료 사용자가 접하게 될 화면과, 무언가 문제가 생겼을 때 누군가가 열어보게 되는 관리자 화면만 포함합니다. 그 외는 5번째 항목인 '하지 않을 목록(Do Not List)'으로 보냅니다.
예시: 필라테스 스튜디오 예약 앱
- 고객 측: 클래스 목록, 클래스 상세, 예약, 결제, 예약 목록 — 5개 화면
- 관리자 측: 오늘 수강하는 사람, 예약 취소/이동 — 2개 화면
- 합계
7개 화면. 목업에 있던 랜딩 페이지(LP), 리뷰, 쿠폰은 공개일의 화면이 아닙니다.
실제 작업량을 결정하는 숫자는 이쪽입니다. 연결점(seam)이란 경계를 의미합니다: 네트워크 호출, 두 번째 환경, 파일, 정기 실행, 외부 서비스, 시간. 연결점은 실제로 작동하는 환경에서 검증해야 하며, 바로 이 부분이 AI로 만들면서 한 번도 통과하지 못한 부분입니다.
같은 앱에 적용한다면: 2명이 동시에 누를 수 있는 DB 쓰기(중복 예약), 결제, SMS/LINE 알림, 이메일 전송, 사진 업로드, 배포할 위치 — 6개의 연결점이 있습니다. 결제와 알림은 제대로 구현하려면 각각 하루가 걸립니다. 코드가 길어서가 아니라, 검증하는 시간이 길기 때문입니다.
대략적인 채점 규칙:
| 화면의 성격 | 예상 시간 |
|---|
| 연결점이 없는 경우 | 1시간 |
| ... | |
| 내가 작업한다고 해서 빨라지지 않는 것들이 있습니다. 이것은 공수와 분리하여, 계약 전에 '일정상의 위험(Calendar Risk)'으로 전달해야 합니다. 중간에 발견되는 것이 가장 비용이 많이 들기 때문입니다. | |
- 결제 사업자 심사: 실제 사용을 위한 심사 기간 동안 기다릴 수밖에 없습니다. 테스트 모드로 만들고, 승인 후에 실전 키로 전환합니다. -
- 문자/LINE 발신지 등록: 발신 번호의 사전 등록과 심사가 필요하여 즉시 처리되지 않습니다. -
- 도메인 및 DNS: 반영을 기다려야 하며, 인증서는 그 이후입니다. -
- 스토어 심사: 5일차에 App Store에 올라가야 한다면, 그것은 이미 코딩 견적이 아닙니다. -
- 데이터 이전: '고객 400건이 스프레드시트에'는 신규 개발이 아니라 중복 제거를 포함한 이관 작업입니다.
예시에서는 결제 사업자의 계좌는 이미 있지만 알림 발신지가 미등록 상태입니다 — 알려지지 않은 점 2가지, 약 3~5일의 달력 일수가 필요합니다. 제 가용 시간은 쓰지 않지만, 공개일을 정하게 됩니다.
7개 화면과 6개 연결점, 그리고 알려지지 않은 점들을 병렬로 진행한다고 가정하면, 5일은 이렇게 채워집니다.
| 날짜 | 작업 내용 | 그날 보여줄 수 있는 것 |
|---|
| D1 | 로그인, 데이터 모델 수정, 관리자 화면의 수강자 목록 | 시드 데이터를 이용해 예약이 통과됨 |
| ... | | |
| D5는 여유 시간이 아닙니다. 고객이 직접 접해야만 알게 되는 두 가지 문제가 발견되는 날입니다 (예: 접수가 항상 태블릿으로 이루어짐, 클래스 이름에 슬래시(/)가 들어감 등). | | |
견적은 이번 주에 만들지 않을 것을 적어야 비로소 정직해집니다. 저의 경우는 이렇습니다.
- 리뷰/평점 — 예약 흐름에 의존하지 않으므로 뒤로 미룸
- 쿠폰 — 공개 시에는 단일 가격으로 설정
- 다국어 — 나중으로 미룸
- 리마인더 자동 발송 — 1회만 보내고, 스케줄링 발송은 뒤로 미룸
- 기존 스프레드시트 이전 — 별도의 프로젝트로 견적 분리
나중에 이것을 요청받았을 때의 대답은 '추가'가 아니라 '교체'입니다. "D3에 쿠폰을 넣을 수 있지만, 알림이 다음 주로 미뤄집니다. 어느 것을 먼저 진행할까요?" 이 한 문장이 어떤 계획 도구보다도 마감 기한을 지켜왔습니다.
실제로 발생했던 순서대로:
- D2 이후의 사양 추가. 화면이 고정된 후의 디자인 변경은 하류 검증 전체를 다시 만들어야 하므로 가장 비용이 높습니다. -
- '또 다른 시장을 위해' 두 번째 결제 사업자를 추가하는 경우. 사업자마다 Webhook, 환불, 입금, 청구서 연결점(seam)이 별도의 세트가 됩니다. -
- D3에서 발견된 이전 문제. 현재 데이터가 어디에 있는지 아무도 보고 있지 않았습니다. -
- 심사가 필요한 외부 서비스를 API 호출로 계획에 포함시키는 경우.
이것들은 모두 'AI가 작성한 코드가 나쁘다'는 이야기가 아닙니다. AI가 내놓는 코드는 충분히 작동합니다. 부족한 것은 **검증(Verification)**이며, 견적이 가격을 매겨야 할 곳은 바로 그 지점입니다.
1페이지, 5가지 항목. 화면 → 연결점(Seam) → 불명확한 부분(달력 날짜) → 일할 계산 → 제외 사항. 숫자는 감이 아니라, 화면은 루트에서, 연결점은 import와 설정에서, 불명확한 부분은 사업자의 관리 화면에서 세고 있습니다. 고객이 직접 검산할 수 있는 견적만 제시합니다.
3~5일 만에 완성하는 것은 현실적입니다. 다만 그것은 작업이 '건설'이 아니라 '빼기(Subtraction)와 검증'이기 때문입니다. 무엇을 줄여야 할지 적지 않은 견적은, 견적이 아니라 날짜가 붙은 희망 사항입니다.
서울의 1인 스튜디오(주식회사 CPC AI)에서, AI로 만든 앱을 그대로 인계받아 공개까지 완성하고 있습니다. 일본어 상담도 가능합니다.
