AI 코딩 에이전트에게 런치 레이어(launch layer)가 필요한 이유

코딩은 10배 빨라졌습니다. 하지만 출시(launching)는 그렇지 않았습니다.

코딩 에이전트(coding agent)에게 반쯤 형성된 아이디어를 던져주면, 커피가 식기도 전에 작동하는 앱을 건네줄 것입니다. 백엔드(Backend), 프런트엔드(frontend), 스키마(schema), 몇 가지 API 통합(API integrations), 그리고 통과하는 테스트들까지 말이죠. 예전에는 집중해서 일주일은 걸렸을 부분이 이제는 오후 한때의 프롬프팅(prompting)으로 끝납니다. 이것은 사실이며, 여러분도 이미 체감했을 것입니다.

그런 다음 그 결과물을 출시(ship)하려고 하면, 시간이 멈춘 듯한 느낌을 받습니다.

왜냐하면 에이전트는 코드를 제품으로 바꾸는 부분을 작성하지 않았기 때문입니다. 에이전트는 비즈니스 로직(business logic)을 작성했습니다. 데이터베이스를 프로비저닝(provision)하거나, OAuth 앱을 등록하거나, 세션 스토어(session store)를 연결하거나, 결제 미터(billing meter)를 설정하거나, 낯선 사람이 어떻게 비용을 지불하게 할지 고민하지 않았습니다. 그중 어느 것도 앱 자체는 아닙니다. 하지만 그 모든 것들이 앱과 첫 유료 사용자 사이를 가로막고 있습니다. 병목 현상(bottleneck)이 이동한 것입니다. 이제 문제는 더 이상 코드가 아닙니다. 코드가 존재해야 하는 경제적 껍데기(economic shell)입니다.

그 껍데기가 새로운 희소 자원입니다. 이 에세이는 왜 그런지, 그리고 무엇이 그 간극을 메울 수 있는지에 대해 다룹니다.

실제 비용: "에이전트가 앱을 완성함"에서 "첫 유료 사용자"까지

구체적으로 살펴보겠습니다. "운영 접착제(ops glue)"라는 표현은 그것이 얼마나 많은 작업인지를 교묘하게 숨기는 표현이기 때문입니다.

백엔드 배포(Deploy the backend). 2026년에도 백엔드를 배포한다는 것은 여전히 다음과 같은 의미입니다: 서비스를 생성하고, 리전(region)을 선택하고, Dockerfile을 작성하고, 환경 변수(env vars)를 설정하고, 데이터베이스를 프로비저닝(provision)하고, 연결 문자열(connection string)을 연결하고, 상태 확인(health checks)을 구성하고, 도메인을 연결하고, TLS를 추가하는 것입니다. 각 단계는 개별적으로는 지루하며, 모두 합치면 하루가 걸립니다. 여러분의 에이전트는 한 시간 전에 애플리케이션 로직을 마쳤습니다. 이제 여러분이 시스템 관리자(sysadmin) 역할을 수행하는 동안 에이전트는 유휴 상태(idle)로 머물러 있습니다.

로그인 추가(Add login). 에이전트가 오후 한때 만든 프로젝트에 "Google로 로그인"을 추가한다는 것은 다음을 의미합니다: OAuth 앱을 등록하고, 리다이렉트 URI(redirect URIs)를 구성하고, 콜백(callback)을 처리하고, 세션을 저장하고, 무언가를 해싱(hash)하고, 다음 주면 잊어버릴 제공업체의 문서 40분 분량을 읽는 것입니다. 로그인은 사용자가 있는 모든 서비스의 기본 요건(table stakes)입니다. 이는 배포(deploy)의 일부여야 합니다. 하지만 거의 그렇지 않습니다.

관리형 데이터베이스(managed database)를 구축하세요. 에이전트는 데이터베이스가 이미 존재한다고 가정합니다. 이제 당신은 데이터베이스를 프로비저닝(provision)하고, 자격 증명(credentials)을 관리하며, 이를 저장소(repo)에 노출되지 않게 유지하고, 마이그레이션(migrations)을 실행하며, 백업을 걱정해야 합니다. 더 많은 계정, 더 많은 대시보드, 교체(rotate)해야 할 더 많은 비밀값(secrets)이 생깁니다.

사용량에 따른 과금(Bill for usage). 이 부분이 진정으로 어려워지는 지점이며, 대부분의 사이드 프로젝트가 조용히 사라지는 이유입니다. Stripe는 기본 요소(primitives)를 제공할 뿐, 미터링 과금(metered billing)을 제공하지 않습니다. 사용량을 측정해야 하는 AI 앱에는 다음과 같은 것들이 필요합니다: 사용 이벤트(usage events), 집계(aggregation), 크레딧 잔액(credit balance), 충전(top-ups), 호출 실패 시 환불(refunds), 재시도 시 중복 결제가 발생하지 않도록 하는 멱등성(idempotency). 이는 제품을 만드는 대신 소비하게 되는 2주에서 4주 분량의 작업이며, 엣지 케이스(edge cases)를 잘못 처리하게 되고 수치를 완전히 신뢰할 수 없게 만듭니다.

최종 사용자에게 비용을 청구하세요. 이것은 AI 앱의 경제 모델 전체를 무너뜨리는 요소이며, 거의 아무도 이야기하지 않는 부분입니다. 당신의 앱이 LLM을 호출하고, 비디오를 생성하고, 페이지를 스크레이핑(scrape)할 때마다 모든 호출은 실제 비용을 발생시킵니다. 데모 단계에서는 당신이 그 비용을 부담합니다. 하지만 프로덕션(production) 환경에서는 가입자가 늘어날수록 당신은 더 가난해집니다. 살아남으려면 호출당 발생하는 비용을 이를 트리거한 사용자에게 전가해야 합니다. 이를 직접 수행한다는 것은 요청당 비용을 추적하고, 이를 적절한 사람에게 할당하며, 직접 구축해야 하는 잔액(balance)과 대조하여 정산하는 것을 의미합니다. 대부분의 데모는 이 과정을 완전히 생략합니다. 이것은 지루한 부분입니다: 누가 비용을 지불하는가?

모두 합산해 보십시오. 에이전트는 오후 한때 만에 제품을 작성했습니다. 제품을 둘러싼 껍데기(shell) — 배포(deploy), 로그인(login), 데이터베이스(database), 미터링 과금(metered billing), 최종 사용자 결제(end-user payments) — 는 그 뒤를 잇는 일주일의 작업이며, 모든 앱에 대해 매번 똑같이 반복되는 일주일입니다. 이는 차별화되지 않은 작업입니다. 프로젝트 전반에 걸쳐 동일합니다. 그리고 이것은 코드가 저렴해진다고 해서 저렴해지지 않는 바로 그 작업입니다.

그 비대칭성(asymmetry)이 문제의 핵심입니다. 프로덕션은 붕괴되었습니다. 껍데기는 그렇지 않았습니다.

런치 레이어(launch layer)란 무엇인가

런치 레이어(launch layer)는 누락된 나머지 절반입니다. 이는 에이전트가 작성한 앱을 단 한 번의 명령으로 — 로그인, 데이터베이스(database), 사용량 기반 과금(usage billing), 최종 사용자 결제(end-user payments)가 이미 부착된 상태로 — _하나의 제품(product)_으로서 출시하는 레이어입니다. 나중에 과금 기능을 덧붙이는 배포 도구(deploy tool)가 아닙니다. 배포와 함께 제공되는 껍데기(shell)입니다.

차별점이며, 특히 AI 앱에 있어 이것이 가장 중요한 이유는 바로 사용량 기반의 최종 사용자 결제(metered, end-user-pays billing) 때문입니다:

당신의 AI 앱은 API 호출마다 돈을 소모합니다. 과금 시스템을 직접 구축하지 않고도, 사용량에 따라 사용자에게 비용을 청구하세요.

구체적으로, SettleMesh를 사용하면 구축하지 않아도 되는 두 가지가 있습니다:

• 매니페스트 플래그(manifest flag)로서의 사용량 기반 과금(Metered billing). 사용량 이벤트, 집계, 잔액, 충전, 실패 시 환불, 멱등성(idempotency) 등을 처리하는 2~4주간의 과금 프로젝트가 billing.enabled: true 하나로 압축됩니다. 모든 사용량 기반 호출은 실행 전에 가격이 책정되고 잔액에 기록됩니다.
• 헤더(header)를 통한 최종 사용자 결제(End-user-pays). 앱이 사용자를 대신하여 작업을 수행할 때, X-Settle-Payer를 부착하면 비용은 당신이 아닌 _사용자_의 잔액에서 차감됩니다. LLM 호출 비용, 렌더링, 스크래핑(scrape) 비용이 이를 트리거한 사람에게 그대로 전달됩니다. 당신의 앱은 가입자가 늘어날 때마다 점점 더 가난해지는 상황을 멈출 수 있습니다.

그 밑단에는 Aev(1 USD = 100 Aev, Stripe를 통해 충전)라고 불리는 선불 크레딧 단위, 통합된 사용자별 지갑, 그리고 수익을 앱 소유자에게 자동으로 분배하는 정산 엔진(settlement engine)이 자리 잡고 있습니다. 당신은 앱을 작성하기만 하면 됩니다. 런치 레이어가 누가 로그인했는지, 무엇을 사용했는지, 비용이 얼마인지, 그리고 누가 누구에게 지불하는지를 처리합니다.

설계 단계부터 에이전트 불가지론적(agent-agnostic)입니다. 당신이 이미 사용 중인 코딩 에이전트가 무엇이든 — Claude Code, Codex, Hermes, OpenClaw, Cursor, 혹은 다음에 선택할 그 무엇이든 — 코드를 작성합니다. 통합할 것도, 채택할 SDK도 없습니다. 에이전트는 그저 settlemesh deploy를 실행하기만 하면 됩니다. 슬로건이 그 형태를 잘 보여줍니다: 어떤 에이전트로든 빌드하고, SettleMesh로 출시하세요. 런치 레이어는 "내 컴퓨터에서는 잘 돌아가는데"와 "낯선 사람이 방금 나에게 돈을 지불했다" 사이의 모든 과정을 수행합니다.

settlemesh deploy
# 앱 라이브 상태, 로그인 연결 완료, 데이터베이스 프로비저닝 완료,
# 미터링 기반 과금 활성화, 최종 사용자 결제 준비 완료

그 간극이 메워졌습니다.

왜 지금인가

이것은 단순한 도구 선호의 문제가 아닙니다. 이는 구조적인 변화이며, 세 가지 단계를 거칩니다.

생산(Production)이 제로(0)를 향해 붕괴하고 있습니다. 에이전트(Agents)는 소프트웨어 생산의 한계 비용을 수십 배 이상 낮추고 있습니다. 전 세계 앱의 수는 인간의 관리 반경을 훨씬 초과할 직전 단계에 와 있습니다. 누구나 오후 한때에 작동하는 앱을 생성할 수 있게 되면, 앱을 생성하는 것 자체는 더 이상 희소하고 가치 있는 행위가 아니게 됩니다.

따라서 구조(Structure)가 희소한 것이 됩니다. 생산이 더 이상 희소하지 않을 때, 희소해지는 것은 생산 주변의 모든 것입니다 — 즉, 누가 소프트웨어를 사용하는지(identity, 신원), 얼마나 사용했는지(metering, 미터링), 누가 누구에게 지불하는지(settlement, 결제), 그리고 그것이 어떻게 발견되고 다른 소프트웨어와 결합되는지(distribution, 배포)입니다. 즉, 경제적 껍데기(economic shell)입니다. 우리가 방금 살펴본 바로 그 '접착제' 역할을 하는 부분입니다. 저렴한 코드는 그 껍데기를 덜 가치 있게 만드는 것이 아니라, 오히려 더 가치 있게 만듭니다. 왜냐하면 그 껍데기를 필요로 하는 코드는 훨씬 더 많아지는 반면, 각 조각을 감싸는 고정 비용은 동일하기 때문입니다.

그리고 기존의 상거래 레이어(commerce layer)는 이를 감당할 수 없습니다. 구독, 계약, 앱스토어의 30% 수수료, 일주일씩 걸리는 검토 주기 — 이 모든 것은 인간의 속도와 인간의 규모에 맞춘 상거래를 위해 설계되었습니다. 분 단위의 생성, 미세한 금액, 높은 빈도, 그리고 기계 대 기계(machine-to-machine) 호출로 이루어진 경제를 지원할 수 없습니다. 에이전트가 다른 에이전트의 앱을 시간당 수천 번 호출하는 앱을 구축할 때, 계약에 서명하거나 송장을 승인할 인간은 루프(loop) 안에 존재하지 않습니다. 우리가 가진 상거래 레이어는 결코 그런 트래픽을 위해 구축되지 않았습니다.

이것이 바로 네이티브 결제 레이어(native settlement layer) — 즉, 인간의 속도가 아닌 에이전트의 속도로 실행되는 과금 및 결제가 필요한 이유입니다. 그것이 바로 런치 레이어(launch layer)가 채우는 위치입니다.

이것은 로드맵상의 약속이 아니라 실제 작동하는 서비스입니다

이 분야의 모든 것에 대해 던질 수 있는 합당한 질문은 다음과 같습니다: 이것이 실체 없는 제품(vaporware)인가, 그리고 에이전트가 구축한 코드가 과연 실제 제품이 될 수 있는가? 이에 대해 솔직하게 설명하겠습니다.

시스템의 핵심은 이미 프로덕션(production) 환경에서 실행 중입니다. 설계되거나 계획된 단계가 아니라, 실제로 작동하고 있습니다:

• 이산적 비용 가산 마진 (Discrete cost-plus markup), m은 1.0에서 1.5 사이 — 모든 미터링(metered) 호출은 실제 확인된 비용을 기준으로 가격이 책정됩니다.
• 통합된 사용자별 Aev 지갑 (A unified per-user Aev wallet) — Stripe를 통해 자금이 충전되는 사용자당 하나의 잔액을 가집니다.
• X-Settle-Payer를 통한 최종 사용자 결제 (End-user-pays via X-Settle-Payer) — 호출 비용은 개발자가 아닌 호출을 트리거한 사용자에게 부과됩니다.
• 중첩된 빌링 (Nested billing) — 다른 앱을 호출하는 앱이 체인을 따라 하위 단계까지 정확하게 정산합니다.
• 소유자 수익 배분 (Owner revenue split) — 앱 소유자의 수익 배분액이 자동으로 계산되고 정산됩니다.

오늘날 이 셸(shell) 위에서 실제로 작동하는 앱들이 있습니다. 작동 가능한 지갑 루프를 갖춘 비디오 편집 앱, Whisper를 엔드 투 엔드(end-to-end)로 실행하는 YouTube 스크립트 앱, 에이전트가 구축한 MovieAgent 등이 있으며, 각각의 앱은 라이브 머신러리(machinery)를 통해 배포되고, 결제되며, 정산됩니다.

아직 이루어지지 않은 것은 밀도(density), 즉 네트워크 상의 노드 수입니다. 그것이 솔직한 격차이며, 런치 레이어(launch layer)가 구축됨으로써 얻는 것이 아니라 사용됨으로써 얻게 되는 유일한 것입니다. 그 밑바탕에 깔린 경제학은 오늘날 실제로 존재합니다.

만약 당신이 AI 앱을 만든다면, 제안은 좁고 구체적입니다: 자신의 API 비용을 직접 부담하는 것을 멈추고, 매 프로젝트마다 동일한 셸 구축에 일주일을 소비하는 것을 멈추며, 빌링 시스템을 직접 작성하지 않고도 사용자에게 사용량 기반으로 요금을 부과하십시오. settlemesh deploy를 실행하면, 셸이 배포와 함께 제공됩니다.

그리고 한 단계 더 나아가, 저렴한 프로덕션은 소프트웨어의 정의 자체를 재편하기 때문에: 오늘 배포된 앱은 내일의 조립 가능한 API(composable API)가 됩니다. 런치 레이어를 통해 출시되는 모든 앱은 이미 미터링 및 정산이 완료된 상태로 도착하며, 이는 다음 에이전트가 계약이나 통합 회의 없이도 해당 앱을 호출하고, 사용량만큼 결제하며, 그 위에 구축할 수 있음을 의미합니다. 네트워크는 스스로 성장합니다.

settlemesh.io에서 직접 시도해 보세요. Claude Code, Codex, Hermes, OpenClaw, Cursor 또는 다음에 등장할 그 어떤 에이전트로든 구축한 뒤, settlemesh deploy를 실행하면 런치 레이어가 함께 배포됩니다.

어떤 에이전트로든 구축하세요. SettleMesh로 출시하세요.

SettleMesh는 StructureIntelligence Inc.의 제품입니다 — settlemesh.io · github.com/StructureIntelligence. Aev는 SettleMesh의 선불 크레딧 단위입니다: 1 USD = 100 Aev, Stripe를 통해 충전됩니다.