Lovable 5배 확장이 결제·정산 팀에 던지는 신호

AI 앱 빌더의 폭발적 성장이 결제 현장에 던지는 진짜 신호

2026년 6월, Lovable이 Google Cloud와 다년간 계약을 체결하며 인프라 사용량을 5배 늘리겠다고 발표했다. 동시에 Anthropic Claude에 대한 접근 범위도 확대된다. 표면적으로는 하나의 스타트업과 클라우드 대기업 간의 계약 소식이다. 그런데 결제·정산·자동화를 직접 운영하는 작은 팀 입장에서 이 뉴스를 읽으면 전혀 다른 풍경이 보인다.

Lovable은 '바이브 코딩(vibe coding)' 플랫폼이다. 자연어로 요구사항을 입력하면 풀스택 웹 애플리케이션을 생성해주는 도구로, 2025년 말 기준 월간 활성 사용자 수십만 명, 생성된 앱이 수백만 개를 넘어선 것으로 알려져 있다. 이 규모가 5배가 된다는 건, 코드를 직접 쓰지 않는 사람들이 만드는 '소프트웨어'가 기하급수적으로 늘어난다는 뜻이다. 그리고 그 소프트웨어 중 상당수는 결제 기능을 포함할 것이다. 이게 우리가 이 뉴스를 그냥 지나쳐선 안 되는 이유다.

Google Cloud 5배 확장 — 숫자 뒤에 숨은 인프라 전쟁

Lovable의 Google Cloud 사용량 5배 확장은 단순한 서버 증설이 아니다. 이 계약에는 두 가지 핵심 구성 요소가 있다. 첫째는 Vertex AI를 포함한 Google Cloud AI 인프라를 통한 연산 자원 확보이고, 둘째는 Google Cloud 경로를 통한 Anthropic Claude 모델 접근권 확대다.

Google은 Anthropic에 이미 수십억 달러를 투자했고, Vertex AI를 통해 Claude 모델을 제공하고 있다. Lovable이 이 경로를 확대한다는 건, 코드 생성의 '두뇌' 역할을 Claude가 더 많이 맡겠다는 선언이다. Claude는 특히 코드 생성과 구조화된 출력에서 경쟁 모델 대비 높은 신뢰도를 보여왔다. Anthropic이 공개한 SWE-bench 벤치마크 기준으로 Claude 3.7 Sonnet은 62.3%의 실제 소프트웨어 엔지니어링 문제 해결률을 기록하며 GPT-4o 계열을 앞섰다. 이 조합이 의미하는 바는 명확하다. AI가 생성하는 코드의 품질이 빠르게 올라가고 있고, 그 코드로 만들어지는 서비스의 복잡도도 함께 올라간다. Stripe 결제 연동, 세금 계산 자동화, 정산 리포트 생성 같은 기능들이 이제는 개발자 없이도 '그냥 만들어지는' 시대가 본격적으로 열리고 있는 것이다.

Lovable + Claude 조합의 트레이드오프 — 속도와 신뢰 사이

여기서 중요한 트레이드오프가 등장한다. Lovable이 만들어주는 코드는 빠르고 가시적이다. 비개발자도 30분 안에 Stripe 연동 결제 폼을 만들 수 있다. Lovable 커뮤니티에는 실제로 '2시간 만에 SaaS 결제 페이지 완성'류의 사례가 넘쳐난다. 그런데 결제와 정산 시스템에서 '30분 만에 완성된 코드'는 그 자체로 위험 신호일 수 있다.

구체적인 예시를 들어보자. Stripe Webhooks를 처리하는 코드에서 idempotency key를 제대로 처리하지 않으면 어떻게 될까? 동일한 결제 이벤트가 두 번 처리되어 이중 정산이 발생한다. AI가 생성한 코드가 이 엣지 케이스를 빠뜨리는 건 드문 일이 아니다. 실제로 2024~2025년 사이 AI 코드 생성 도구의 보급이 확산되면서, Indie Hackers와 Hacker News 커뮤니티에서 'AI가 짜준 결제 코드 때문에 고객 청구가 두 번 나갔다'는 사례가 반복적으로 보고됐다. Lovable과 Claude의 결합이 강력해질수록 이 위험은 더 넓은 범위로 확산된다. 코드를 이해 못 하는 사람도 결제 로직을 구현할 수 있게 되기 때문이다. AI가 양의 지식(Ai양의지)으로 쌓아올린 방대한 코드 패턴은 분명 강점이지만, 그 지식이 돈을 다루는 시스템에 적용될 때는 반드시 도메인 기반의 검증 레이어가 필요하다.

결제·정산 코드를 AI가 짜면 실제로 어떤 일이 생기나

우리 팀이 직접 부딪혀온 맥락에서 보자. 정산 자동화 시스템은 단순한 CRUD 앱이 아니다. 환불 처리 타이밍, 부분 취소 로직, 카드사별 정산 주기 차이, 세금 코드 분기 처리 — 이런 것들은 비즈니스 규칙이 코드에 강하게 결합되어 있는 영역이다. AI가 생성한 코드는 이 규칙을 '일반적인 케이스'로 처리하는 경향이 있다.

예를 들어 월말 정산 배치를 Lovable로 만든다고 가정하자. Claude는 그럴듯한 Python 코드를 내놓을 것이다. datetime 처리, DB 쿼리, 이메일 발송까지 한 번에 나온다. 그런데 2월 말일 처리는? 타임존 변환은? 국내 PG사별 정산 마감 기준 차이는? 이런 것들은 코드 생성 모델이 아니라 도메인 경험이 해결하는 문제다. 반면 AI 생성 코드가 진짜 강점을 발휘하는 구간도 있다. API 클라이언트 래핑, 데이터 변환 매핑, Slack 알림 훅 연결 같은 반복적인 보일러플레이트 작업에서는 Lovable 수준의 도구가 팀의 실질적인 개발 속도를 2~3배 끌어올린다. 우리 팀이 직접 써봤을 때, 정산 리포트 CSV 파싱 및 가공 파이프라인의 프로토타이핑 시간이 기존 3일에서 반나절로 줄었다. 단, 이후 QA와 엣지케이스 커버리지 작업에는 기존과 동일한 시간이 들었다. AI는 '빠른 초안 생성 도구'이지 '완성된 검증 도구'가 아니라는 점을 다시 한번 확인한 경험이었다.

HEDVION 팀이라면 이렇게 쓴다 — 실전 시나리오 3가지

시나리오 1: 신규 PG사 연동 프로토타입 빠르게 검증하기 새로운 PG사 API 연동을 검토할 때, Lovable + Claude로 연동 프로토타입을 하루 안에 만든다. 실제 결제 처리를 붙이기 전에 요청/응답 구조를 빠르게 눈으로 확인하는 용도다. 이때 생성된 코드는 철저히 '탐색용'이고 프로덕션에 그대로 나가지 않는다. 탐색 단계에서 AI 생성 코드를 활용하고, 도메인 검토 및 재작성 단계를 명확히 분리하는 게 핵심이다.

시나리오 2: 내부 정산 모니터링 대시보드 MVP 외부에 노출되지 않는 내부 관리 도구 — 정산 현황 집계, 오류 트랜잭션 필터링, 담당자별 처리 현황 시각화 — 이런 용도라면 Lovable이 만들어주는 UI와 기본 로직으로 충분히 운영 가능하다. 실제 돈이 오가는 로직이 아니라 '읽기 전용 모니터링' 레이어이기 때문이다. 여기서는 속도가 정밀도보다 중요하다.

시나리오 3: 자동화 스크립트의 뼈대 생성 후 도메인 살 붙이기 매주 수작업으로 하던 정산 데이터 집계나 파트너사 이메일 발송 같은 반복 작업 자동화의 초안 코드를 AI로 빠르게 뽑고, 팀원이 비즈니스 규칙을 덧붙이는 방식이다. 'AI가 기본 뼈대, 사람이 도메인 살' 구조다. 이 접근법에서 핵심은 리뷰어가 생성된 코드의 구조를 이해할 수 있어야 한다는 점이다. 코드를 이해 못 하는 사람이 리뷰하면 AI 생성 코드를 그대로 신뢰하게 되고, 그게 가장 위험한 시나리오다.

지금 바로 써먹을 실행 가능한 시사점

1. AI 생성 코드 사용 범위를 명시적으로 정책화하라. "결제 트랜잭션을 직접 처리하는 코드(결제 요청, 환불, 정산 배치)는 AI 초안을 그대로 프로덕션에 배포하지 않는다"는 규칙을 팀 내 문서로 만들어라. 규칙이 없으면 빠른 사람이 그냥 올린다. 실제로 이 규칙 하나가 이중 청구 사고를 막는 마지막 방어선이 되는 경우가 많다.

2. Lovable 류 도구를 탐색·내부 도구 용도로 지금 당장 도입하라. 새 기능 탐색, 내부 도구 프로토타이핑, 반복 자동화 초안 작성 — 이 세 영역에서 도입 효과는 즉각적이다. 도구를 아예 안 쓰는 건 경쟁력 손실이다. 단, 용도 범위를 팀이 공유해야 한다.

3. Claude API 직접 연동을 결제 데이터 처리에 적용하라. Lovable이 Claude를 쓴다면, 우리도 직접 쓸 수 있다. 정산 오류 로그 분류, 이상 거래 패턴 1차 감지, 파트너사 문의 초안 생성 같은 작업에 Claude API를 연동하면 반복 업무를 눈에 띄게 줄일 수 있다. Anthropic의 Message Batches API를 활용하면 비동기 대량 처리 비용도 최대 50% 절감 가능하다.

4. Google Cloud + Vertex AI 경로를 인프라 옵션으로 열어둬라. Lovable이 이번 계약으로 Vertex AI 경로를 강화한다는 건, Claude 모델을 Google Cloud 네트워크 안에서 쓸 수 있다는 의미다. 지금 당장 마이그레이션이 아니라, 옵션을 알고 있는 것 자체가 협상력이다. 특히 AWS 단일 클라우드에 묶여 있는 스택이라면, 멀티클라우드 전략 검토 시 Vertex AI 경유 Claude 접근이 레이턴시와 비용 면에서 유리한 케이스가 생긴다는 점을 지금부터 파악해두면 된다.

원문: AI News & Artificial Intelligence | TechCrunch