왜 AI 빌드 비용이 예측 불가능하게 느껴지는가\n\nAI 지원 빌드는 처음에는 저렴하게 느껴지다가 어느 순간 갑자기 그렇지 않게 됩니다. 그 이유는 고정된 기능 가격을 지불하는 것이 아니라 시도들에 대해 지불하기 때문입니다: 메시지, 생성된 코드, 수정, 테스트, 재작업. 계획이 모호하면 시도 횟수가 빠르게 늘어납니다.\n\n대부분의 비용 급증은 몇 가지 공통된 패턴에서 옵니다:\n\n- 범위가 암시만 되어 있고 문서화되지 않음(예: "인증 추가"라고만 하고 역할, 공급자, 비밀번호 재설정이 없음).\n- 재시도가 쌓임(거의 맞는 프롬프트가 310개의 후속을 유발).\n- 사양이 중간에 변경됨(새 필드, 새 화면, 다른 규칙)으로 이전 작업이 대체됨.\n- 숨겨진 요구사항이 늦게 등장(로딩, 검증, 엣지 케이스, 오류 상태).\n\n추정할 때 실제로 예산에 넣는 항목을 명확히 하세요:\n\n1) 플랫폼이 청구하는 크레딧 또는 사용 단위\n2) 토큰(프롬프트와 출력의 크기)\n3) 시간(검토, 테스트, 수정에 드는 시간)\n\n어떤 추정치든 단일 숫자가 아니라 범위로 다루세요. UI에서는 작아 보여도 로직이 크거나 그 반대일 수 있습니다. 최선의 경우는 강력한 첫 초안, 최악의 경우는 여러 번의 수정 루프입니다.\n\n이 가이드의 나머지 부분은 반복 가능한 기능 버킷(auth, CRUD, 통합, UI 리디자인)을 사용합니다. 크레딧 기반의 비브코딩 플랫폼인 Koder.ai (koder.ai)를 사용하면 이 차이를 빠르게 느낄 수 있습니다: 처음에 "대시보드 만들기"로 시작했다가 나중에 역할, 감사 로그, 새 레이아웃을 추가하면, 그 제약들을 미리 작성해두는 것보다 훨씬 더 많은 크레딧을 소모합니다.\n\n## 크레딧과 토큰을 간단히 이해하기\n\n사람들은 종종 토큰, 크레딧, 빌드 스텝이라는 세 가지를 섞어 말합니다. 이들을 분리하면 비용 예측이 쉬워집니다.\n\n토큰은 모델이 읽거나 쓰는 작은 텍스트 단위입니다. 프롬프트는 토큰을 사용하고, 모델의 응답도 토큰을 사용하며, 긴 채팅 기록은 모델이 다시 읽어야 하기 때문에 토큰을 소비합니다.\n\n크레딧은 플랫폼이 사용하는 청구 단위입니다. Koder.ai와 같은 도구에서는 크레딧이 일반적으로 모델 사용과 채팅 뒤의 플랫폼 작업(예: 에이전트가 작업 실행, 파일 생성, 결과 확인)을 포함합니다. 내부 세부 사항을 알 필요는 없지만 사용량을 늘리는 요인을 인식해야 예산을 세울 수 있습니다.\n\n빌드 스텝은 프로젝트에 대한 하나의 의미 있는 변경입니다: "이메일 로그인 추가", "users 테이블 생성", "이 화면을 엔드포인트에 연결" 같은 것들입니다. 하나의 기능은 종종 많은 스텝을 필요로 하고, 각 스텝은 여러 모델 호출을 유발할 수 있습니다.\n\n사용량은 컨텍스트가 길 때(큰 사양, 방대한 채팅 기록, 참조되는 파일이 많을 때), 반복이 많을 때, 출력이 클 때(전체 파일 재작성, 큰 코드 블록), 또는 모델이 추측하게 만드는 모호한 요청이 있을 때 가장 빠르게 증가합니다.\n\n작은 프롬프트 변경도 재시도 횟수에 영향을 주어 비용을 크게 바꿀 수 있습니다. "완전한 인증 시스템"은 원치 않는 옵션을 초대합니다. 반면 "이메일과 비밀번호만, 소셜 로그인 없음, 정확히 두 개의 화면"은 관리해야 할 부분을 줄입니다.\n\n유효한 규칙 하나: 움직이는 부분이 적을수록 재시도가 적습니다.\n\n## 기능 우선 방식의 비용 추정\n\n"화면"이나 "메시지"로 추정하는 것을 멈추세요. 사용자가 소리 내어 부를 법한 기능 단위로 추정하세요. 이렇게 하면 예산을 대화량이 아니라 결과에 묶을 수 있습니다.\n\n각 기능마다 세 부분을 추정하세요:\n\n- Build: 코드 생성 및 앱에 연결\n- Test: 흐름을 실행하고 명백한 버그와 핵심 엣지 케이스 처리\n- Revise: 작동을 확인한 뒤 두 번째 손질(텍스트 수정, 검증, 작은 UX 수정)\n\n대부분의 초과 지출은 첫 초안이 아니라 테스트와 수정에서 발생합니다.\n\n각 부분에 대해 범위를 사용하세요: 낮음(직관적), 일반(약간의 주고받음), 높음(깜짝 놀랄만한 문제). 플랫폼이 크레딧 기반이면 크레딧으로 추적하세요. 토큰을 직접 추적한다면 토큰으로 추적하세요. 핵심은 현실이 바뀌어도 정직하게 유지되는 예측을 만드는 것입니다.\n\n두 줄은 자체적으로 과도한 지출을 방지합니다:\n\n1) **Unknowns buffer(알 수 없는 항목 여유, 10–20%)**를 별도의 항목으로 둡니다. 기능 안에 숨기지 마세요.\n\n2) **Later changes requested(나중에 요청된 변경)**을 별도 버킷으로 둡니다(예: "팀 추가", "대시보드를 X처럼 만들어 달라"). 분리하지 않으면 원래 견적이 정상적인 변경 때문에 비난받게 됩니다.\n\n다음은 가볍게 복사해 쓸 수 있는 템플릿입니다:\n\ntext\nFeature: Password login\n- Build: low 30 | typical 60 | high 120\n- Test: low 15 | typical 30 | high 60\n- Revise: low 10 | typical 20 | high 40\nSubtotal (typical): 110\n\nBuffer (15%): 17\nLater changes (held): 50\n\n\n이 템플릿을 각 기능(auth, CRUD, 통합, UI 리프레시)에 대해 반복하세요. 계획을 세울 때는 "typical" 합계를 사용하고, 최악의 경우 확인을 위해 "high" 합계도 계산하세요.\n\n## 일반 기능 추정: 인증(auth)과 CRUD\n\n인증과 CRUD는 기본적으로 보이지만 범위가 모호하면 비용이 많이 듭니다. 메뉴처럼 다루세요: 옵션마다 비용이 추가됩니다.\n\n### 인증: 단순히 "로그인"이라고 하지 말고 정확한 형태를 정의하세요\n\n"완료" 상태가 무엇인지 기록하세요. 가장 큰 비용 요인은 로그인 방식 수와 권한 경로 수입니다.\n\n구체적으로 적으세요:\n\n- 로그인 방식(이메일/비밀번호, 매직 링크, Google, Apple, SSO)\n- 역할 및 권한(admin/editor/viewer 및 각 역할의 권한)\n- 비밀번호 규칙(길이, 복잡도, 잠금, 재설정 흐름)\n- 세션 규칙(만료, 로그아웃, 기억하기 동작)\n- 계정 수명 주기(초대, 비활성/삭제, 이메일 확인)\n\n단지 "인증 추가"라고 하면 일반적인 솔루션이 제공되고 나중에 엣지 케이스를 패치하느라 추가 비용을 내게 됩니다. 형태를 미리 결정하는 것이 더 저렴합니다.\n\n### CRUD: 테이블이 아니라 화면과 규칙을 세어라\n\nCRUD 비용은 엔티티 수와 각 엔티티가 필요로 하는 동작량에 의해 결정됩니다. 실용적인 모델: 각 엔티티는 보통 36개의 화면(목록, 상세, 생성, 편집, 때로는 관리자나 감사 뷰)을 의미하며, 추가로 API 작업과 검증이 필요합니다.\n\nCRUD 범위를 정할 때는 엔티티를 명시하고 필드, 타입, 검증 규칙(필수, 고유, 범위)을 포함하세요. 그리고 목록 동작을 정의하세요: 필터, 정렬, 페이징, 검색. "검색"은 단순 포함 필터일 수도 있고 훨씬 무거운 기능일 수도 있습니다.\n\n관리자 화면이 사용자 화면과 다른지 결정하세요. 별도의 레이아웃, 추가 필드, 일괄 작업은 작업량을 두 배로 만들 수 있습니다.\n\n비용을 빠르게 증가시키는 엣지 케이스는 행 수준 권한, 감사 로그, CSV 가져오기/내보내기, 소프트 삭제, 승인 워크플로우 등이 있습니다. 모두 구현 가능하지만, 원하는 것을 명시적으로 선택하면 예산이 예측 가능해집니다.\n\n## 통합(integrations) 추정: 추측 없이\n\n통합은 숨겨진 작업 때문에 비싸게 느껴집니다. 해결책은 "X에 연결" 대신 작고 테스트 가능한 청크로 나누는 것입니다. 그러면 추정이 더 예측 가능하고 프롬프트도 깔끔해집니다.\n\n튼튼한 통합 범위에는 보통 다음이 포함됩니다:\n\n- 연결 및 인증(API 키 또는 OAuth, 토큰 리프레시)\n- 한 객체의 엔드투엔드(해피패스 요청 하나)\n- 동기화 동작(웹후크 또는 스케줄, 페이징, 레이트 리밋)\n- 실패 처리(재시도, 멱등성, 재실행 경로)\n- 테스트 및 엣지 케이스(잘못된 데이터, 권한 부족, 타임아웃)\n\n프롬프트 전에 데이터 계약을 고정하세요. 필요한 객체와 정확한 필드를 나열하세요. "고객 동기화"는 모호합니다. "Sync Customer{id, email, status} 및 Order{id, total, updated_at}"처럼 명확하면 모델이 불필요한 테이블, 화면, 엔드포인트를 만들어내는 것을 막습니다.\n\n다음으로 방향과 빈도를 결정하세요. 단방향 동기화(가져오기 전용)는 양방향보다 훨씬 저렴합니다. 양방향이 꼭 필요하면 우선권 규칙(source of truth, last-write-wins, 수동 검토)을 미리 정하세요.\n\n실패에 대비하세요. API가 다운되었을 때 무엇을 할지 결정하세요. 로그 항목 + 알림 + 수동으로 "재실행 동기화" 버튼 정도면 충분한 경우가 많습니다. 최소한으로 유지하면 필요하지 않은 전체 운영 시스템 비용을 피할 수 있습니다.\n\n마지막으로 서드파티의 특이점과 테스트를 위해 버퍼를 추가하세요. 간단한 API라도 페이징, 이상한 열거형, 불일치 문서, 레이트 리밋 등이 있으므로 통합 테스트와 수정에 대해 20–40% 추가 예산을 잡는 것이 현실적입니다.\n\n## 리디자인 및 UI 변경 추정\n\nUI 작업은 예산이 몰래 새어나가는 곳입니다. "리디자인"은 색상만 바꾸는 것부터 전체 흐름을 재구축하는 것까지 의미할 수 있으니 무엇을 바꾸는지 명확히 하세요: 레이아웃, 컴포넌트, 카피, 사용자 단계 중 무엇인지.\n\n시각적 변경만과 동작에 영향을 주는 변경을 분리하세요. 시각적 변경은 스타일, 간격, 컴포넌트 구조를 건드립니다. 버튼의 동작, 검증 방식, 데이터 로딩을 바꾸면 기능 작업으로 봐야 합니다.\n\n### 페이지 목록처럼 범위를 정하세요\n\n"앱 전체를 리디자인"은 피하세요. 정확한 화면과 상태를 나열하세요. 나열할 수 없으면 추정할 수 없습니다.\n\n범위를 구체적으로 유지하세요:\n\n- 포함되는 페이지(예: 로그인, 대시보드, 설정)\n- 포함되는 상태(빈, 로딩, 오류, 성공)\n- 변경 내용(레이아웃, 컴포넌트, 카피, 흐름)\n- 참조 스타일(몇 가지 메모: 색상, 타이포그래피, 간격)\n- 허용되는 패스 수(예: 빌드 1회 + 다듬기 1회)\n\n이런 프롬프트는 모델이 코드베이스 전체에서 디자인을 추측하는 것을 막아 불필요한 주고받음을 줄입니다.\n\n### QA 패스는 건너뛰지 마라\n\nUI 변경은 보통 데스크톱과 모바일 각각에 대해 최소 두 번의 점검이 필요합니다. 접근성 기본(명도 대비, 포커스 상태, 키보드 탐색)도 간단히 추가하세요.\n\n실용적 추정 방법은:\n\n(페이지 수) x (변경 깊이) x (패스 수)\n\n예: 3페이지 x 중간 깊이(새 레이아웃 + 컴포넌트 조정) x 2패스(빌드 + 다듬기)는 예측 가능한 크레딧 청크입니다. 온보딩 흐름도 바꾸면 별도의 항목으로 처리하세요.\n\n## 단계별: 프롬프트로 예산된 범위 만들기\n\n크레딧을 통제하는 가장 저렴한 방법은 모델에게 요청하기 전에 원하는 것을 결정하는 것입니다. 재작업이 비용을 뛰어넘게 만드는 원인입니다.\n\n먼저 사용자와 목표를 한 문단으로 적으세요. 예: "작은 클리닉 접수 담당자가 로그인하고, 환자를 추가하고, 예약을 잡고, 오늘 목록을 본다." 이렇게 경계를 정하면 모델이 추가 역할, 화면, 워크플로를 발명하는 것을 막습니다.\n\n그다음 제품을 모듈 대신 화면과 액션으로 설명하세요. "예약 모듈" 대신 "캘린더 화면: 생성, 재예약, 취소, 검색"처럼 쓰면 작업량을 셀 수 있습니다.\n\n필요한 데이터의 필수 요소만 포함하세요. 아직 모든 필드가 필요하지 않습니다. 강력한 프롬프트에는 보통 다음이 포함됩니다:\n\n- 사용자와 역할(누가 무엇을 할 수 있는가)\n- 화면과 액션(사용자가 클릭하는 동작)\n- 핵심 테이블과 주요 필드(무엇을 저장해야 하는가)\n- 수락 체크(작동을 확인하는 방법)\n- 범위 외 항목(빌드하지 않을 것)\n\n수락 체크는 두 번 지불하는 일을 막아줍니다. 각 기능에 대해 "사용자가 이메일로 비밀번호 재설정 가능" 또는 "예약 생성 시 이중 예약 방지" 같은 2–4개의 체크를 작성하세요. Koder.ai를 사용하면 이러한 체크는 코드 생성 전에 Planning Mode에 자연스럽게 들어맞습니다.\n\n범위 외 항목을 명확히 하세요: "관리자 대시보드 없음", "결제 없음", "다국어 없음", "외부 캘린더 동기화 없음" 등. 이렇게 하면 "있으면 좋을" 작업이 깜짝 등장하는 것을 막습니다.\n\n작게 나누어 빌드하고 각 청크 후에 다시 추정하세요. 간단한 리듬은: 화면 또는 엔드포인트 하나 생성 → 실행 → 문제 수정 → 다음으로 이동입니다. 만약 청크가 예상보다 비용이 많이 든다면 다음 청크를 줄이거나 범위를 잘라서 이탈을 막으세요.\n\n## 품질을 잃지 않으면서 프롬프트 비용을 줄이는 방법\n\n대부분의 비용 급증 원인은 한 번의 메시지에 너무 많은 작업을 집어넣는 것입니다. 모델을 팀원처럼 대하고 작은, 명확한 단계로 브리핑하세요.\n\n먼저 계획을 요청하고 바로 코드를 요청하지 마세요. 가정과 열린 질문이 담긴 짧은 빌드 계획을 요청하고 확인한 뒤 첫 번째 작은 구현 단계를 요청하세요. 계획, 빌드, 테스트, 카피라이팅, 스타일링을 한 번에 요청하면 긴 출력과 더 많은 실수를 초대합니다.\n\n컨텍스트를 좁히세요. 변경에 필요한 화면, 컴포넌트, API 노트만 포함하세요. Koder.ai를 사용하면 관련된 특정 파일만 선택하고 이름으로 참조하세요. 여분의 파일은 토큰을 늘리고 관련 없는 영역까지 수정을 끌어들입니다.\n\n작은 diff를 요청하세요. 가능한 한 한 번의 프롬프트는 한 가지 변경만 하게 하세요: 단일 엔드포인트, 한 폼, 한 오류 상태, 한 화면. 작은 변경은 리뷰하기 쉽고, 문제가 생기면 관련 없는 작업을 재작업하지 않아도 됩니다.\n\n간단한 작업 규칙:\n\n- 요청: 먼저 계획, 그다음 한 구현 단계, 그다음 짧은 리뷰 체크리스트\n- 제공: 최소한의 컨텍스트(현재 동작, 원하는 동작, 제약 조건)\n- 제한: 수정 라운드 수 고정(예: 두 번)\n- 요구: 무엇이 변경되었는지 간단 요약\n- 기록: 재작업 원인을 기록하고 프롬프트 템플릿 업데이트\n\n루프를 일찍 멈추세요. 두 번째 시도가 여전히 빗나가면 입력을 변경하세요. 누락된 세부 정보를 추가하거나 상충되는 요구사항을 제거하거나 정확히 실패한 사례를 보여주세요. 단순히 "다시 시도"를 반복하면 토큰만 소모되고 문제 해결로 가까워지지 않습니다.\n\n예: "로그인 + 비밀번호 분실"과 더 나은 레이아웃을 원한다면 세 개의 프롬프트로 하세요: (1) 흐름과 필요한 화면 요약, (2) 인증 흐름만 구현, (3) UI 간격과 색상 조정. 각 단계는 검토 가능하고 저렴합니다.\n\n## 예산을 크게 늘리는 흔한 실수\n\n대부분의 초과 지출은 큰 기능이 아니라 작은 범위의 차이에서 시작되어 프롬프트 라운드가 늘어나고, 생성된 코드가 많아지고, 수정이 늘어나는 과정에서 발생합니다.\n\n### 예산을 갉아먹는 다섯 가지(대신 할 일)\n\n완료 조건에 동의하기 전에 빌드 시작\n\n승인 체크 없이 코드를 생성하면 재작성 비용을 내게 됩니다. 사용자 동작, 표시될 오류, 저장되어야 할 데이터 등 3–5개의 체크를 먼저 작성하세요.\n\n모호한 단어 사용\n\n"모던", "멋지게", "더 낫게 만들어줘"는 긴 주고받음을 초대합니다. 대신 "데스크톱에서 2열 레이아웃, 모바일에서 단일 열" 또는 "기본 버튼 색상 #1F6FEB"처럼 구체적으로 적으세요.\n\n한 번에 여러 기능을 집어넣기\n\n"인증 추가, 결제 추가, 관리자 대시보드 추가"는 변경 추적과 추후 작업 예측을 어렵게 합니다. 기능 하나씩 하고 변경된 파일 요약을 요청하세요.\n\n데이터 모델을 늦게 변경\n\n테이블 이름 변경, 관계 변경, ID 체계 변경은 UI, API, 마이그레이션 전반에 걸친 수정을 강제합니다. 핵심 엔티티는 초기에 고정하세요. 일부 필드는 "미래"로 남겨둬도 됩니다.\n\n테스트를 마지막까지 미루기\n\n버그는 재생성-수정-재생성 루프로 이어집니다. 기능당 작은 테스트 세트를 요청하세요. 한 번에 거대한 테스트 패스를 하는 것은 피하세요.\n\n구체적 예: Koder.ai에 "CRM을 개선해줘"라고 요청하면 레이아웃을 바꾸고 필드를 이름 바꾸고 엔드포인트를 조정하는 동시에 여러 변화가 발생할 수 있습니다. 이후 통합이 깨지면 무엇이 바뀌었는지 찾는 데 크레딧을 소모하게 됩니다. 대신 "데이터 모델은 건드리지 말고, 목록 페이지 UI만 업데이트하고 API 라우트는 수정하지 말 것, 다음 4개 체크를 통과할 것"이라고 하면 변동을 제한하고 비용을 안정적으로 유지할 수 있습니다.\n\n## 시작하기 전 빠른 비용 체크리스트\n\n예산 수립을 하나의 마법 프롬프트가 아닌 작은 프로젝트 계획처럼 다루세요. 2분 확인으로 대부분의 초과 지출을 미리 잡을 수 있습니다.\n\n다음 항목을 점검하고 어떤 항목이라도 "아니오"이면 코드 생성을 계속하기 전에 바로 고치세요:\n\n- 기능 목록이 경계가 명확함: 무엇을 하고 무엇을 하지 않는지 시작과 끝이 정해져 있음.\n- 기능별로 범위(낮음/일반/높음)가 있고, 첫 빌드에 사용할 하나의 수치에 합의함.\n- 프롬프트에 승인 체크와 명확한 제외 항목이 포함됨.\n- 작은 청크로 빌드하고 각 청크 후에 검토: 동작 확인, 변경 사항 읽기, 다음 청크 진행 여부 결정.\n- 통합과 UI 수정처럼 항상 확장되는 부분을 위한 예산을 예약함.\n\nKoder.ai를 사용한다면 각 청크를 스냅샷 포인트로 다루세요: 한 조각 생성 → 테스트 → 계속 진행. 스냅샷과 롤백은 데이터 모델 편집, 광범위한 UI 리팩터링, 통합 재작성 같은 위험한 변경 전후에 가장 가치가 있습니다.\n\n간단한 예: "사용자 관리 빌드" 대신 "이메일 로그인만, 비밀번호 재설정 포함, 소셜 로그인 없음, 관리자만 사용자 비활성화 가능, 로그인 및 재설정에 대한 테스트 포함"처럼 범위를 정하면 재시도를 줄이고 크레딧을 절약할 수 있습니다.\n\n## 기능 목록으로 작은 앱 추정 예시\n\n다음은 복사해 쓸 수 있는 현실적인 작은 예시입니다. 내부 도구로, 로그인, 두 개의 간단한 모듈, 하나의 통합이 있는 앱입니다.\n\n하나의 "빌드 사이클"을: 짧은 계획 → 코드 생성/업데이트 → 빠른 리뷰 및 수정으로 가정하세요. 크레딧은 주로 실행한 사이클 수와 각 사이클의 규모에 따라 추적됩니다.\n\n내부 도구 기능 목록:\n\n| 기능 | 포함 내용 | Low | Typical | High |\n|---|---|---:|---:|---:|\n| 로그인 + 역할 | 로그인, 로그아웃, 두 개 역할(Admin, User), 보호된 페이지 | 1 사이클 | 2 사이클 | 4 사이클 |\n| CRUD 모듈 1 | "Employees" 목록, 생성/편집, 기본 검증, 검색 | 2 사이클 | 3 사이클 | 6 사이클 |\n| CRUD 모듈 2 | "Assets" 목록, 생성/편집, 직원에 할당, 감사 필드 | 2 사이클 | 4 사이클 | 7 사이클 |\n| 하나의 통합 | 자산이 할당될 때 외부 서비스로 이벤트 전송 | 1 사이클 | 2 사이클 | 5 사이클 |\n\n체크포인트를 촘촘히 유지하는 프롬프트 순서 예:\n\n1. 계획: 각 기능에 대한 필드, 화면, 규칙과 범위 외 항목 확인\n2. 모듈 1만 빌드: Employees 엔드투엔드 생성 후 중지\n3. 리뷰: 흐름 테스트, 버그 수정, 필드 고정 후 다음으로 이동\n4. 모듈 2 반복\n5. 핵심 흐름이 안정되면 통합 추가\n\n코드가 존재한 후 결정을 바꾸면 비용이 급증합니다. 일반적인 트리거는 역할 변경, 늦게 추가되는 필드(특히 모듈과 통합을 모두 건드리는 필드), 통합 오류(인증 실패, 페이로드 불일치), 폼 존재 후의 UI 리디자인입니다.\n\n다음 단계: 기능별로 계획하고 사이클 단위로 빌드하며 각 사이클 후에 크레딧을 재확인하세요. 위험한 변경 전에 스냅샷을 찍어 롤백하면 전형적인 범위 안에 프로젝트를 유지하기 쉽습니다.
