사용량 한도
사용량 한도는 한 달, 하루, 분당 요청처럼 서비스가 허용하는 사용 범위를 숫자로 정한 규칙이다. AI 코딩에서는 모델 호출 횟수, 토큰 수, 크레딧, 빌드 시간, 저장 공간, 동시 실행 워커 수가 모두 한도가 될 수 있다. 초보자는 기능 구현에만 집중하다가 한도 초과로 자동답변, 배포 빌드, 이미지 생성, 테스트 실행이 멈추는 상황을 뒤늦게 만난다. 좋은 운영 방식은 한도를 문서화하고, 70~80%에 도달하면 알림을 보내며, 한도 초과 시 사용자에게 어떤 메시지를 보여줄지 미리 구현하는 것이다.
영어 표기
Usage Limit
예시
Q&A 자동답변 워커에 하루 AI 호출 한도를 두고, 80%를 넘으면 알림을 남기며 새 질문은 대기 상태로 보존하는 회귀 테스트와 사용자 안내 문구를 함께 작성하고, 알림 로그가 남는지도 검증한다.
참고
한도는 비용 통제와 장애 예방을 동시에 담당하는 운영 지표다.
카테고리
비즈니스·수익화
난이도
basic
태그
사용량한도 · 예산
함께 읽기
연관 용어
버전 관리·배포
관측 가능성
영어 표기 Observability
서비스가 왜 느리거나 실패하는지 운영자가 추적할 수 있도록 로그, 메트릭, 트레이스, 알림을 설계하는 개념이다. 단순히 에러가 났다는 사실을 아는 것을 넘어, 어느 요청에서 어떤 사용자 흐름과 어떤 배포 이후에 문제가 생겼는지 설명할 수 있어야 한다. 바이브 코딩에서는 AI가 만든 코드가 예외를 삼키거나 로그를 남기지 않는 경우가 많아, 관측 가능성이 부족하면 장애 원인 분석이 급격히 어려워진다.
비즈니스·수익화
토큰 기반 과금
영어 표기 Token-Based Pricing
AI 서비스의 사용량을 토큰(입력 토큰 + 출력 토큰)으로 측정하여 과금하는 비즈니스 모델로, AI API 서비스의 가장 기본적인 과금 방식이다. Claude API, OpenAI API 등이 이 모델을 사용하며, 일반적으로 입력 토큰보다 출력 토큰의 단가가 더 높다(모델이 새로운 토큰을 '생성'하는 것이 기존 토큰을 '읽는' 것보다 더 많은 연산을 필요로 하기 때문). 바이브 코딩의 비용이 예상보다 높아질 수 있는 주요 원인이 토큰 기반 과금이다. 그 이유: 대규모 코드베이스를 컨텍스트로 제공하면 입력 토큰이 급증하고, AI가 긴 코드를 생성하면 출력 토큰이 급증하며, 에이전틱 워크플로에서 여러 번의 반복(수정 → 테스트 → 수정)이 일어나면 누적 비용이 기하급수적으로 증가한다. 비용 관리 전략: 컨텍스트 엔지니어링으로 불필요한 입력 줄이기, 작은 모델(Sonnet, mini)을 기본으로 사용하고 복잡한 작업에만 큰 모델(Opus) 사용, 캐싱을 활용하여 동일한 컨텍스트의 재전송 방지 등.
비즈니스·수익화
크레딧 기반 과금
영어 표기 Credit-Based Pricing
작업의 복잡도에 따라 다른 양의 '크레딧'을 소비하는 과금 모델로, 토큰 기반 과금의 사용자 친화적 대안이다. 토큰 기반 과금이 '연료 소비량으로 과금하는 것'이라면, 크레딧 기반 과금은 '주행 거리로 과금하는 것'에 비유할 수 있다. 간단한 작업(코드 자동완성, 짧은 질문)은 적은 크레딧을, 복잡한 작업(멀티파일 에이전트 작업, 대규모 리팩토링)은 많은 크레딧을 소비한다. Windsurf(월 25 Cascade 크레딧 무료), Replit(작업 복잡도에 따라 크레딧 차등 소비), GitHub Copilot(월 50 요청) 등이 이 모델을 채택하고 있다. 크레딧 기반 과금의 장점: 사용자가 비용을 예측하기 쉽고(토큰 수를 계산할 필요 없음), 무료 티어 설계가 직관적이며, 복잡도에 비례한 공정한 과금이 가능하다. 단점: 크레딧 1개의 가치가 도구마다 다르고, 작업 복잡도의 판단 기준이 불투명할 수 있으며, 크레딧이 소진되면 작업이 중단되어 개발 흐름이 끊길 수 있다.