고객의 앱이 역대 최고의 한 달을 보냈습니다. 가입자가 세 배로 늘었고, 여러분이 구축한 워크플로우가 순조롭게 돌아가고 있으며, 창업자는 감격에 젖어 있습니다. 그런데 플랫폼 청구서가 도착합니다. 플랜 허용량을 200만 워크로드 단위 초과했고, 1,000단위당 30센트로 청구됩니다. 이는 119달러 플랜 위에 $600의 초과 요금이 붙은 것입니다 — 그리고 계약서에 고정 월 수수료 안에 "호스팅 포함"이라고 적혀 있다면, 그 $600은 고객의 예산이 아니라 여러분의 마진에서 나갑니다. 고객의 성공이 곧 여러분의 손실이 된 것이고, 업무 범위 어디에도 이를 예상한 부분은 없었습니다.
이것이 2026년 노코드 에이전시 운영의 결정적 가격 리스크입니다. 버블은 소비량 기반으로 청구하고, 웹플로우는 대역폭과 콘텐츠 볼륨을 계량하며, 둘 다 주기적으로 가격을 개편합니다. 고정 수수료는 이러한 비용이 예측 가능한 척합니다. 그러나 예측 가능하지 않습니다. 이 상황에서 살아남는 에이전시는 플랫폼 지출을 실제 모습 그대로 대합니다: 벤더에서 출발해 여러분의 장부를 거쳐 고객에게 흘러가는 통과 비용 — 여러분의 실제 수익은 마크업과 관리 수수료이며, 결코 환급금 자체가 아닙니다.
2026년 버블이 실제로 청구하는 방식
버블의 표면 가격은 온순해 보입니다. 연간 청구 기준으로 웹 플랜은 스타터 월 $29, 그로스 $119, 팀 $349이며, 무료 티어는 $0이고 엔터프라이즈는 문의 시 책정됩니다. 월간 청구는 더 비쌉니다: 각각 $32, $134, $399입니다. 그러나 대부분의 프로덕션 청구서에서 플랜 요금은 가장 작은 부분입니다. 진짜 계량기는 워크로드 단위입니다.
모든 유료 플랜에는 월간 워크로드 단위 허용량이 포함됩니다: 스타터 175,000단위, 그로스 250,000단위, 팀 500,000단위. 무료 플랜은 50,000단위를 포함하지만 실제 앱을 배포할 수 없습니다. 워크로드 단위는 서버 작업 — 데이터베이스 검색, 워크플로우 실행, API 호출, 페이지 로드, 파일 작업 — 을 측정하며, 소비량은 작업에 따라 크게 달라집니다. 단순한 페이지 로드는 약 0.52단위이고, 복잡한 검색 하나가 1050단위를 소모할 수 있습니다. 워크플로우가 잦거나 검색이 최적화되지 않은 앱은 트래픽이 인상적이어 보이기도 전에 스타터 허용량을 다 써버릴 수 있습니다.
허용량이 소진되면, 추가 티어 없이 적용되는 초과 요율은 1,000단위당 $0.30입니다. 한 달에 백만 단위 추가 — 백엔드 워크플로우가 무거운 성장하는 앱이라면 쉽게 발생 — 는 $300입니다. 사전 구매한 워크로드 티어는 최대 티어에서 1,000단위당 약 $0.10까지 단위 요율을 크게 낮춰주지만, 급등 직전에 티어를 구매해야 하며, 티어 자체가 별도의 월간 약정입니다.
특히 에이전시에게 이 상황을 위험하게 만드는 세 가지 역학이 있습니다. 첫째, 소비량은 사전에 예측하기가 진짜로 어렵습니다; 동일한 사용자 수를 가진 두 앱도 워크플로우가 어떻게 구축되었는지에 따라 워크로드가 10배 차이 날 수 있습니다. 둘째, 초과 사용은 기본적으로 켜져 있으며, 버블은 허용량의 75퍼센트와 100퍼센트에서 계정 소유자에게 이메일을 보냅니다 — 그러나 에이전시가 계정을 보유하고 있다면, 그 이메일은 급등을 일으킨 사용자들의 고객이 아니라 여러분에게 갑니다. 셋째, 초과 사용을 끄는 것이 청구서를 우아하게 제한하지 않습니다: 앱이 한도에 도달하면 초과 사용이 다시 켜지거나, 티어가 구매되거나, 다음 주기가 시작될 때까지 오프라인 상태가 됩니다. "아무도 지켜보지 않아서 사용 한도에 걸려 사이트가 다운됐다"는 고객과 나누고 싶지 않은 대화입니다.
웹플로우는 다른 계량기로 같은 형태를 가진다
웹플로우는 워크로드 단위를 사용하지 않지만, 에이전시 관점에서 그 가격 책정은 동일한 변동성 프로필을 가집니다: 적당한 기본 요금에 고객의 성공에 따라 움직이는 계량기가 더해집니다.
2026년 5월 웹플로우는 기존 CMS와 비즈니스 사이트 플랜을 단일 프리미엄 플랜으로 통합했습니다: 연간 청구 기준 사이트당 월 $25(월간 $39)로 정적 페이지 300개, CMS 항목 20,000개, 대역폭 50GB를 포함합니다. 월 $15의 베이직 플랜은 커스텀 도메인과 10GB 대역폭을 포함하지만 CMS는 전혀 없습니다. 포함된 대역폭을 초과하는 모든 것은 유료 추가 옵션으로 최대 2.5테라바이트까지 판매됩니다 — 따라서 고객의 입소문 마케팅이나 이미지·영상 트래픽이 많은 분기는 곧바로 더 큰 웹플로우 청구서로 전환됩니다.
그리고 사이트 플랜은 세 가지 청구서 중 하나일 뿐입니다. 디자인 협업을 위한 워크스페이스 플랜, 추가 디자이너 좌석, 추가 로케일, 이커머스 거래 용량이 모두 사이트당 요금 위에 별도로 청구됩니다. "언어 하나만 더" 또는 "편집자 두 명만 더 접근 권한을" 요청하는 고객은 계량화된 스택을 늘리도록 요청하는 것입니다 — 그리고 계약서에 "웹사이트 및 호스팅"에 대한 단일 정액 월 수치를 견적했다면, 그 모든 "예"가 여러분의 마진을 줄입니다.
두 플랫폼 모두 가격을 개편합니다. 버블은 2026년 10월에 스타터 가격을 조정했고, 웹플로우는 연중에 전체 사이트 플랜 라인업을 재편했습니다. 오늘의 플랫폼 가격을 내장한 여러 달짜리 고정 견적은 벤더가 가만히 있을 것이라는 내기입니다. 그 내기는 수년째 지고 있습니다.
계약의 실수: 계량 비용을 고정 수수료에 묶는 것
실패 양상은 거의 항상 같은 문장입니다. 제안서나 기본 서비스 계약서에 묻혀 있는 문장 말입니다: "호스팅을 포함"하는 고정 월 수수료. 고객에게는 단순함으로 읽힙니다. 실제로는 여러분의 에이전시가 벤더 변동성의 보증인이 되게 만듭니다 — 고정된 보험료를 받고 무제한의 계량 하방 리스크를 흡수하는 것입니다.
에이전시 구축에 관한 업계 보고서는 일반적인 버블 프로젝트 수수료를 $20,000에서 $250,000 사이라고 하며, 특정한 마진 함정을 지적합니다: 고객 앱을 인도하고 고객의 비즈니스가 성공하면 소비가 증가하고, 고객이 예산에 없던 더 많은 비용을 지불하거나 에이전시가 그 증가분을 흡수합니다. 모호한 범위에 대한 고정 가격은 소프트웨어 서비스 전반에서 이미 에이전시-고객 분쟁의 가장 흔한 원인입니다; 고정 가격 안에 계량되는 제3자 청구서를 추가하면 모든 사용량 급등이 재협상으로 변합니다.
같은 함정이 AI와 자동화 작업에서 한 단계 아래로 나타납니다. API 및 토큰 비용을 정액 리테이너에 묶는 에이전시는 벤더 가격 변동이 하룻밤 사이에 손실이 되는 것을 발견합니다. 플랫폼 지출은 토큰 지출과 정확히 똑같이 행동합니다: 제3자가 계량하고, 고객이 주도하며, 여러분의 통제 밖에 있습니다. 그 세 가지 속성을 가진 비용은 고정 수수료 안에 속하지 않습니다. 통과 조항에 속합니다.
묶음에는 두 번째, 더 조용한 비용이 있습니다: 고객에게서 숫자를 숨깁니다. 워크로드 단위 추세를 한 번도 보지 못한 고객은 그것을 줄일 최적화 작업을 승인할 이유가 없습니다 — 낭비적인 검색을 재구성하고, 무거운 로직을 백엔드 워크플로우로 옮기고, 급등 후 원시 초과 요금을 내는 대신 급등 전에 워크로드 티어를 구매하는 일 말입니다. 투명한 통과 비용 청구는 사용량을 함께 지켜보는 공유 대시보드로 바꾸며, 이는 최적화 작업이 스스로 판매되는 유일한 구조입니다.
해법: 플랫폼 지출을 통과 비용으로 만들기
통과 비용은 에이전시가 고객을 대신하여 지불하는 비용 — 벤더 구독, 사용료 청구서, 라이선스 비용 — 으로, 원가 또는 처리 마크업을 붙여 고객에게 다시 청구됩니다. 이 개념은 에이전시 회계에서 표준입니다: 고객 자신의 비용이 여러분의 수익이 되지 않고 장부를 통해 흘러갑니다. 노코드 플랫폼에 적용하면 세 가지 실행 가능한 모델이 있습니다. 앱이 출시되기 전에 문서로 고객별로 하나를 선택하세요.
모델 1: 고객이 벤더 계정을 보유하고 직접 지불한다. 고객이 자신의 버블 또는 웹플로우 계정을 만들고, 자신의 카드를 추가하며, 플랜, 티어, 초과 사용을 소유합니다. 에이전시는 협업자 또는 게스트 편집자로 초대받습니다. 이것이 가장 깔끔한 구조입니다 — 계량 청구서가 여러분의 장부에 절대 닿지 않습니다 — 그리고 자체 재무 기능을 갖춘 대형 고객에게는 올바른 기본값입니다. 알려진 단점: 고객이 비용을 아끼려고 플랜 티어에 과소 투자하는 경우가 있으며, 이는 성능 병목과 한도 초과 중단을 초래하여 여러분이 진단하고 설명해야 합니다. 이 모델을 선택한다면 인도 문서에 최소 티어 권장 사항을 넣고 그 아래로 운영하는 것은 고객의 위험 부담이라는 조항을 넣으세요.
모델 2: 에이전시가 지불하고 원가에 마크업을 더해 재청구한다. 여러분이 벤더 계정을 보유하고, 자신의 카드로 플랫폼 청구서를 지불하며, 매월 정확한 플랫폼 지출에 처리 수수료를 더해 고객에게 청구합니다 — 일반적으로 통과 비용의 10~20퍼센트로, 대부분의 에이전시가 벤더 관리, 조정, 현금 선지급을 충당하는 데 사용하는 범위입니다. 이 모델은 청구서 하나와 벤더 관리 제로를 원하는 소규모 고객에게 적합합니다. 계약서에는 마크업 비율, 청구 주기, 그리고 — 결정적으로 — 벤더 가격 인상이 자동으로 전가된다는 점을 명시해야 합니다. 그 마지막 문장이 없으면 모든 버블 또는 웹플로우 가격 개편이 여러분의 가격 책정을 다시 엽니다.
모델 3: 사용 한도와 초과 조항이 있는 묶음 케어 플랜. 명시된 한도까지 플랫폼 지출을 포함하는 정액 월 리테이너를 견적합니다 — 예를 들어 "그로스 플랜과 월 최대 $150의 워크로드 초과 사용을 포함" — 한도를 초과하는 것은 원가에 마크업을 더해 청구합니다. 이는 고객에게 평범한 달에는 예산 예측 가능성을 주면서 급등 리스크를 있어야 할 곳에 둡니다. 한도에는 플랜 티어와 달러 초과 허용량을 모두 명시해야 합니다; 숫자 없는 "호스팅 포함"은 모델 0, 즉 여러분이 탈출하려는 함정입니다.
어떤 모델을 선택하든, 다섯 가지 조항이 업무 기술서에 포함되어야 합니다: 누가 벤더 계정을 보유하고 누구의 카드가 등록되어 있는지; 누가 초과 사용과 티어 업그레이드를 지불하는지, 그리고 어느 달러 임계값을 넘으면 티어 구매 전에 서면 승인이 필요한지; 재청구 지출에 대한 마크업 비율; 허용량, 소비, 추세를 보여주는 매월 청구서와 함께 보내는 사용 보고서; 그리고 벤더의 정가 변동이 계약 수정 없이 전가된다는 고객의 확인. 다섯 번째 조항이 에이전시가 잊어버리는 것이고 나중에 가장 필요로 하는 것입니다.
올바르게 기록하기: 환급금은 여러분의 수익이 아니다
플랫폼 지출이 여러분의 에이전시를 통해 흘러가면, 부기는 그것을 여러분이 실제로 버는 것과 눈에 띄게 분리해야 합니다. 버블이 고객의 10월 초과 사용에 대해 여러분의 카드에 $300을 청구했다고 가정합니다 — 1,000단위당 $0.30로 백만 단위 추가 — 그리고 여러분이 고객에게 $345를 재청구합니다: 원가 $300에 15퍼센트 처리 수수료를 더한 금액입니다. 그 청구서에서 여러분의 실제 수익은 $345가 아니라 $45입니다. 전체 $345를 수익으로 기록하면 매출이 과대 계상되고, 수익 기반 세금이나 가치 평가 계산이 부풀려지며, 이후의 환불이나 크레딧이 수익 환입(revenue reversal)이 되게 합니다 — 실제로는 고객의 돈이 통과하는 것인데도 말입니다.
회계 기준도 동의합니다. ASC 606에 따르면, 본인 대리인 프레임워크는 서비스가 고객에게 이전되기 전에 여러분이 통제하는지 묻습니다. 여러분은 버블의 컴퓨팅이나 웹플로우의 대역폭을 통제하지 않습니다 — 벤더가 통제합니다 — 따라서 재청구된 플랫폼 지출에 대해 여러분의 에이전시는 대리인이며, 올바른 표시는 순액입니다: 마크업은 수수료 수익으로, 환급금은 대응하는 통과 항목에 상쇄되어 흘러갑니다. 구체적으로, 두 쌍의 계정을 유지하세요: 통과 수익은 통과 비용과 대응하고, 수수료 수익은 독립적으로 섭니다. 통과 쌍은 타이밍 차이를 제외하고 매월 대략 제로로 정산되어야 합니다; 마크업은 여러분의 마진이 측정되는 수수료 수익에 있습니다.
다음은 이를 평문 회계로 표현한 것입니다. 에이전시가 버블의 $300 초과 요금을 자신의 카드로 지불한 다음 고객에게 $345를 청구합니다:
2026-10-01 open Assets:Checking:Operating USD
2026-10-01 open Assets:Receivable:Client-Acme USD
2026-10-01 open Expenses:Passthrough:Bubble-WU USD
2026-10-01 open Income:Passthrough-Reimbursement USD
2026-10-01 open Income:Fees:Hosting-Markup USD
2026-10-31 * "Bubble" "October WU overage, client Acme app, 1M units at 0.30 per 1K"
Expenses:Passthrough:Bubble-WU 300.00 USD
Assets:Checking:Operating -300.00 USD
2026-10-31 * "Acme Corp" "October platform reimbursement plus 15 percent hosting admin fee"
Assets:Receivable:Client-Acme 345.00 USD
Income:Passthrough-Reimbursement -300.00 USD
Income:Fees:Hosting-Markup -45.00 USD논리를 따라가 보세요. 첫 번째 거래는 벤더 청구를 여러분 자신의 소프트웨어 비용이 아니라 통과 비용으로 기록합니다 — 일반 운영 비용에 놓는 것이 비용 기반이 부풀려 보이고 마진이 얇아 보이게 만드는 실수입니다. 두 번째 거래는 고객 청구서를 분할합니다: $300은 환급 라인과 상쇄되어 비용과 함께 제로로 정산되고, 오직 $45의 마크업만 수수료 수익에 들어갑니다. 고객이 초과 요금에 이의를 제기하거나 버블이 크레딧을 발행하면, 조정은 통과 쌍에 반영되고 보고된 수익은 절대 움직이지 않습니다. 문서는 이와 같은 계정 구조 패턴을 더 깊이 다루며, Fava는 통과 쌍을 별도의 조각으로 렌더링하여 매월 한눈에 제로로 정산되는지 확인할 수 있게 합니다.
두 가지 부기 습관이 이를 지속시킵니다. 첫째, 매월 고객별로 플랫폼 지출을 조정하세요 — 벤더 청구서와 여러분의 재청구 양쪽에 대해 — 워크로드 대시보드는 예상보다 자주 청구서와 어긋나며, 여러분이 건너뛴 달이 바로 티어가 아무도 모르게 갱신된 달입니다. 둘째, 고객의 플랫폼 잔액이 분기를 넘어 여러분의 카드에 얹혀 있게 절대 두지 마세요; 재청구는 수수료와 동일한 지급 조건으로 매월 청구하세요, 재청구되지 않은 $600 초과 요금이 비용에 오래 쌓여 있는 것은 여러분이 결코 동의하지 않은 무이자 대출입니다.
다음 단계: 이미 체결한 계약을 감사하세요
이번 주에 현재의 기본 계약과 업무 기술서를 꺼내 이 리스크를 만드는 문장을 찾으세요: 고정 숫자에 붙은 "호스팅 포함"의 어떤 변형이든. 각각에 대해 실제로 세 모델 중 어느 것을 설명하는지 — 고객 지불, 마크업 재청구, 한도 있는 케어 플랜 — 그리고 다섯 가지 조항이 있는지 확인하세요: 계정 보유자, 초과 사용 책임, 마크업 비율, 월간 사용 보고, 벤더 가격 변동의 자동 전가. 대부분의 에이전시는 최소 한 고객이 한도 없는 묶음에 있고 최소 한 계약이 가격 개편에 대해 침묵하고 있음을 발견합니다.
그런 다음 갱신 순서대로 수정하세요, 앱이 가장 빠르게 성장하는 고객부터 시작하여 — 다음 급등이 일어나는 곳입니다. 신규 구축은 첫날부터 고객 보유 계정이나 명시적 재청구 조건으로 옮기고, 사용 대시보드를 월간 청구서에 넣고, 계량 청구서가 해야 할 일을 하도록 두세요: 고객의 성공에 따라 오르내리고, 고객의 예산으로, 여러분의 마진은 여러분의 것으로 유지되도록.
