AX Case Study Podcast

1. 왜 이 사례인가

기업이 코딩 에이전트를 도입하는 방식은 대개 점진적입니다. 관심 있는 팀부터 먼저 써 보고, 효과가 확인되면 범위를 조금씩 넓힙니다. 하지만 Affirm은 다른 길을 택했습니다. 2026년 2월, 일주일 동안 평소 하던 엔지니어링 업무를 멈추고 800명이 넘는 엔지니어에게 실제 업무를 기획부터 구현, 테스트, 코드 리뷰까지 에이전트로 처리하게 했습니다. 이 프로젝트의 이름은 AI Retooling Week였습니다.

Affirm은 연간 1억 3,000만 건이 넘는 거래를 처리하는 신용 네트워크를 운영합니다. 돈을 다루는 회사라 사소한 실수도 큰 비용으로 이어지며, 품질은 계약상 결코 타협할 수 없는 조건입니다. 이런 회사가 전사 개발 업무를 일주일간 멈춘 결과, 2026년 4월 기준 Affirm의 전체 PR 가운데 60% 이상이 에이전트 지원을 받아 작성되고 있습니다. 넉 달 전만 해도 이 비율은 거의 0이었습니다.

이 사례를 눈여겨볼 이유는 성공적인 수치보다 그 과정을 솔직하게 기록했다는 데 있습니다. 글을 쓴 개발자 생산성 조직 책임자 Daniel Martin은 준비 과정과 워크플로를 소개한 뒤, 그 주에 무엇이 막혔는지를 가감 없이 적었습니다. 코드 생성이 빨라지자 리뷰, CI, 문서, 도구 연동 같은 기존 병목이 한꺼번에 드러났고, 몇 주 뒤에는 CI 파이프라인이 멈추는 일까지 일어났습니다. 코딩 에이전트를 조직 전체로 넓히려는 기업이 무엇을 먼저 준비해야 하는지 생생하게 보여 주는 사례입니다.

2. Problem

Affirm의 신용 네트워크를 더 확장하려면 품질 좋은 소프트웨어를 더 빠르게 배포해야 했습니다. 하지만 개발 속도를 가로막는 제약이 적지 않았습니다. 원문은 금융을 다루는 사업 특성과 함께, 12년 동안 쌓여 온 모노레포의 구조적 병목을 원인으로 꼽습니다. 비대해진 테스트 스위트, 수작업에 의존하는 코드 리뷰, 불안정한 CI, 필요한 배포 속도를 따라가지 못하는 인프라가 문제였습니다.

AI 도구를 전혀 쓰지 않고 있던 것은 아닙니다. Affirm은 2025년 내내 AI 지원 개발에 투자했고, 12월에는 엔지니어의 80% 이상이 AI 개발 도구를 매주 활용하고 있었습니다. 바로 그 무렵 차세대 도구들이 기술적 기준점을 넘어섰습니다. 원문은 Anthropic의 Opus 4.5 같은 모델이 등장하면서 코딩 에이전트가 코드베이스를 탐색하고, 접근 방식을 계획하며, 코드를 작성하고, 테스트를 실행해 오류를 수정하는 전 과정을 사람의 개입을 최소화한 채 안정적으로 수행할 수 있게 되었다고 설명합니다.

진짜 문제는 엔지니어 사이의 격차였습니다. Affirm의 데이터와 인터뷰에 따르면 수십 명의 엔지니어는 이미 이 도구를 자사 코드베이스에 능숙하게 쓰며 일하는 방식을 완전히 바꾸고 있었지만, 나머지 800명은 그렇지 못했습니다. 게다가 이 격차는 시간이 갈수록 점점 더 벌어지고 있었습니다. 결국 당면 과제는 소수만이 누리던 가속을 800명 전체 개발자에게 빠르게 넓히는 일이었습니다.

확인된 사실: 연간 1억 3,000만 건 이상의 거래, 돈을 옮기는 사업 특성, 12년 된 모노레포의 병목(테스트 스위트, 수작업 리뷰, 불안정한 CI, 배포 인프라), 2025년 12월 기준 엔지니어 80% 이상이 AI 개발 도구 주간 사용, 수십 명의 선도 사용자와 나머지 800명의 격차.

3. Solution

3.1 경영진이 정한 일주일

1월 중순, Affirm 사장(President)은 전사 메시지를 통해 에이전트 방식의 AI 개발이 소프트웨어를 만드는 핵심 방식이 될 것이라고 공식 선언했습니다. 같은 메시지에서 AI Retooling Week의 일정도 못 박았습니다. 그 주에는 필수 회의를 뺀 모든 회의를 멈추고, 제품 출시 일정을 미루며, 모든 엔지니어와 매니저가 주말까지 실제 업무 하나를 처음부터 PR 제출까지 완전히 에이전트 방식으로 완수해야 했습니다.

점진적인 확산 대신 전용 주간을 정한 이유는 앞서 언급한 격차 때문이었습니다. 도구를 이미 잘 쓰는 엔지니어와 그렇지 못한 동료 사이의 차이가 갈수록 벌어지고 있었고, 경영진은 이 간극을 단기간에 메우기를 바랐습니다.

3.2 9명이 2주 동안 만든 기본 워크플로

Retooling Week를 앞두고 Affirm은 엔지니어 9명으로 태스크포스 성격의 워킹 그룹을 꾸렸습니다. 이들의 과제는 2주 안에, 보통의 Affirm 개발자라면 누구나 별도 설정이나 전문 지식 없이도 코딩 업무 대부분을 자동화할 수 있는 표준 워크플로를 만드는 것이었습니다. 이 그룹이 내린 세 가지 핵심 결정이 이후의 성패를 좌우했습니다.

* 기본 도구 하나: Claude Code를 표준 에이전트 도구로 지정하고, 워크플로 전체를 이 도구의 기능에 맞춰 설계했습니다. 엔지니어들이 첫날부터 뚜렷한 출발점을 갖고 시작할 수 있게 하기 위함이었습니다.

* 로컬 우선 개발: 도구 생태계가 아직 하나의 중앙 플랫폼으로 통합되지 않았고, 엔지니어가 곧바로 실질적인 생산성을 낼 수 있어야 했기 때문입니다.

* 판단이 필요한 곳의 명시적인 사람 확인 지점: 의도 정의, 계획 승인, 최종 코드 리뷰와 병합은 사람이 직접 맡고, 그 외의 기계적인 반복 작업은 안전성이 보장되는 한 최대한 자동화했습니다.

“기본”이 곧 “필수”를 뜻하지는 않았습니다. 다른 도구를 선호하는 엔지니어는 공유된 산출물을 조금만 수정해 활용할 수 있었고, 기본 워크플로가 맞지 않는 팀은 테크 리드가 책임지고 맞춤 조정을 진행했습니다. 전파한 기본 원칙은 도구의 종류와 상관없이 단순명료했습니다. 계획(Plan), 리뷰(Review), 실행(Execute), 검증(Verify), 리뷰(Review), 전달(Deliver)의 여섯 단계입니다.

3.3 작업 하나, 에이전트 세션 하나, PR 하나

워크플로의 기본 규칙은 작업 하나 = 에이전트 세션 하나 = PR 하나였습니다. 핵심은 의사결정을 작업 앞단으로 당기는 데 있었습니다. 코드를 구현하면서 에이전트와 질문을 주고받는 대신, 계획 단계에서 아키텍처와 범위를 먼저 확정하고 좁게 나눈 작업을 에이전트에게 넘기는 방식입니다. 이렇게 하면 엔지니어는 작업마다 독립된 worktree를 생성해 여러 작업을 병렬로 매끄럽게 처리할 수 있습니다. Affirm은 각 단계마다 맞춤형 사내 도구를 구축했습니다.

* 계획: 에이전트 지원 계획 스킬이 요구사항을 구조화된 구현 계획으로 변환하고, 범위를 뚜렷하게 나눈 세부 작업으로 쪼갭니다.

* 리뷰: 코드를 작성하기 전에 담당 엔지니어가 이 계획을 직접 검토하고 승인합니다.

* 실행: 에이전트가 전용 worktree 안에서 배정된 작업 하나를 실제로 구현합니다.

* 검증: 에이전트가 로컬에서 테스트와 린터를 실행하고, 발견된 문제를 스스로 고치며 코드를 자체 검토합니다. CI가 실패하면 빌드 로그를 직접 읽어 원인을 분석하고 수정안을 작성합니다. CI를 완전히 통과할 때까지 이 과정을 스스로 반복합니다.

* 리뷰: 담당 엔지니어가 에이전트의 최종 산출물을 검토하고 다듬습니다. 이때 엄격한 원칙을 세웠습니다. 검토하지 않은 AI 산출물을 동료에게 보내지 않는다는 점입니다. 리뷰어도 팀의 아키텍처 맥락이 담긴 보조 도구로 PR을 검토하지만, 코드는 직접 눈으로 읽고 자신의 판단으로 에이전트가 놓친 결함을 잡아냅니다.

* 전달: 사람의 최종 승인을 받아 안전하게 병합합니다.

이 모든 과정의 밑바탕에는 코드베이스의 계층마다 세심하게 배치한 컨텍스트 파일이 있었습니다. 코딩 스타일, 도메인 지식, 팀의 주요 결정을 에이전트가 언제든 찾아볼 수 있게 정리해 둔 것입니다. 이러한 도구들은 사내 플러그인 형태로 배포되었고, 각 팀이 직접 만든 스킬을 공유할 수 있는 중앙 마켓플레이스도 함께 운영했습니다.

3.4 배우면서 일하는 한 주

Retooling Week의 일정은 학습과 실제 업무가 조화를 이루도록 설계했습니다. 월요일에는 경영진의 킥오프와 함께 실제 업무 과제로 전체 워크플로를 시연하는 라이브 데모를 진행했고, 화요일에는 실제 난제에 도구를 적용하는 방법을 보여 주는 “art of the possible” 세션을 온·오프라인으로 열었습니다. 수요일은 방해 없는 집중 작업 시간, 목요일은 팀별 데모 세션이었으며, 금요일에는 엔지니어링 리더들이 선정하고 전사가 투표한 우수 사례 데모를 발표했습니다.

한 주 내내 시간대별 전용 지원 채널을 가동하고, 막힌 엔지니어를 위한 헬프데스크 세션을 운영했으며, 팀별 에이전트 PR 제출 현황 순위표를 투명하게 공개했습니다. 작업과 코드베이스의 특성에 따라 진행 속도와 난이도가 다를 수밖에 없음을 처음부터 인정했고, 완성도보다는 새로운 시도와 실험 자체를 독려했습니다.

확인된 사실: 1월 중순 사장의 전사 메시지, 필수가 아닌 회의 중단과 출시 일정 연기, 모든 엔지니어·매니저의 에이전트 PR 제출 목표, 9명 워킹 그룹과 2주 준비, Claude Code 기본 도구·로컬 우선·사람 확인 지점의 세 가지 결정, 테크 리드의 맞춤 조정, 여섯 단계 사고방식, 작업·세션·PR 1:1:1 원칙과 worktree 병렬 작업, 단계별 사내 도구, 검토하지 않은 AI 산출물 공유 금지 규칙, 다층 컨텍스트 파일, 사내 플러그인과 스킬 마켓플레이스, 요일별 일정과 지원 체계.

4. Impact

4.1 Retooling Week의 측정 결과

Affirm은 팀별 및 워크플로 단계별 도입률, PR 생성 수, 오픈된 PR 대비 병합된 PR의 비율까지 세밀하게 추적했습니다.

원문에서는 “에이전트 지원” PR을 “Claude가 전부 작성했을 가능성이 매우 높은” PR로 정의합니다. 도입 초기 반신반의하던 엔지니어들도 주 중반을 지나며 실질적인 효용을 체감하기 시작했고, 여러 팀에서 주가 끝나기도 전에 이 업무 방식을 앞으로 어떻게 이어 갈지 묻기 시작했습니다.

4.2 드러난 병목

원문은 이번 프로젝트에서 얻은 가장 소중한 수확이 무엇이 잘 작동하지 않는지를 여과 없이 파악한 것이라고 밝힙니다.

* 변경 리뷰: 전사 설문에서 가장 많은 불만이 쏟아진 단계였습니다. 전체 응답자의 약 40%가 주관식 설문에서 묻지도 않았는데 이 문제를 스스로 꼽았습니다. PR이 리뷰 단계에서 며칠씩 묶이는 일이 빈번했고, 쏟아져 나오는 PR 물량을 기존의 수작업 리뷰 방식으로는 감당하기 어려웠습니다.

* CI 속도와 안정성: 단위 테스트 실행 시간은 p75 기준 약 8분 수준이었지만, 임시 테스트 환경에서 돌아가는 전체 E2E 회귀 테스트는 100분이 넘게 걸렸습니다. 에이전트 기반 개발의 핵심인 “변경, 검증, 수정, 재검증”의 빠른 피드백 루프를 염두에 두고 만든 인프라가 아니었습니다.

* 도구 연동: 엔지니어들은 수십 개의 MCP를 통해 에이전트를 사내 시스템 곳곳에 연결하고 싶어 했습니다. 연동을 중앙에서 통제하는 것은 필수적인 보안 원칙이었으나, 요청이 한꺼번에 쏟아지면서 검토 체계가 마비되었습니다. 연동 지점이 늘어날수록 보안 위험도 함께 커져 신중한 검토가 불가피했습니다. 게다가 실제 작업에서는 CLI가 MCP보다 더 안정적인 경우가 많았습니다. 표준화된 설정 기준과 명확한 담당 부서, 서비스 수준 합의(SLA)가 마련되지 않은 상태에서 무분별한 연동은 개발을 돕기는커녕 오히려 큰 짐이 되었습니다.

* 문서 접근성: Affirm에는 지난 10년 넘게 축적된 기술 및 제품 명세가 여러 문서 저장소와 소스 코드 곳곳에 흩어져 있었습니다. 숙련된 개발자는 경험으로 찾아갈 수 있지만, 에이전트가 정확한 결과물을 내려면 정리되고 일원화된 맥락 정보가 필수적입니다. MCP 연동을 지원하는 시스템과 그렇지 않은 시스템이 뒤섞여 있어, 엔지니어가 직접 문서를 찾아 에이전트에게 쥐여 주는 번거로운 작업을 반복해야 했습니다.

* CI 부하: 로컬에서 즉시 검증할 환경이 부족하다 보니, 엔지니어들은 결과물을 확인하기 위해 코드를 CI에 바로 밀어 넣었습니다. 수많은 에이전트가 앞다투어 PR을 올리자 Buildkite에 병목이 발생해 대기 시간이 급증했고, 급기야 Retooling Week가 끝난 몇 주 뒤에는 사내 테스트 격리(quarantine) 서비스와 메인 CI 파이프라인 전체가 마비되는 사태까지 벌어졌습니다.

원문은 이 상황을 “에이전트 코딩은 개발 파이프라인에 있던 모든 마찰을 키웠다”는 한 문장으로 압축합니다. 코드 작성이 눈 깜짝할 사이에 이뤄지자, 수작업 리뷰와 파편화된 문서, 취약한 로컬 테스트 환경, 느린 CI 파이프라인 등 이전에는 조금 불편해도 넘어가던 요소들이 업무 전체를 멈추게 하는 치명적인 장애물로 드러난 것입니다.

확인된 사실: 위 표의 수치, “에이전트 지원” PR의 원문 설명, 주 중반의 인식 변화, 리뷰 병목(약 40% 자발 언급), 단위 테스트 p75 약 8분·E2E 100분 이상, MCP 연동 요청 폭증과 보안 검토 부담, CLI의 상대적 안정성, 문서 분산, Buildkite 대기 증가, 몇 주 뒤 테스트 격리 서비스와 CI 파이프라인 중단.

5. Insight

강제 장치가 점진적 확산보다 훨씬 빨랐습니다. 원문이 꼽은 첫 번째 교훈은, 일반 업무 회의를 전면 중단하고 경영진이 강력하게 뒷받침한 전용 주간이 몇 달에 걸친 점진적 전파보다 단 5일 동안 비교할 수 없이 많은 도입을 이끌어 냈다는 사실입니다. 엔지니어들에게 새로운 도구를 익힐 충분한 시간을 마련해 주었고, 조직 구성원 전체가 같은 출발선에서 시작할 수 있었습니다. 특히 제품 출시 일정을 미루겠다는 결정을 경영진이 전사 차원에서 먼저 공표한 점이 이러한 과감한 시도를 가능하게 만든 핵심 열쇠였습니다.

도구의 성능만큼 지원 조직의 존재가 중요합니다. 전담 엔지니어 그룹이 표준 경로를 미리 닦아 두고, 실시간 지원 채널을 운영하며 현장의 피드백을 즉각 반영했습니다. 원문은 이 팀이 없었다면 도구 사용 권한만 던져 주고 위키 문서 하나 올려둔 채 각자 알아서 잘 쓰기만을 바라는 수준에 그쳤을 것이라고 회고합니다. Affirm은 행사를 성공적으로 이끈 이 임시 조직을 상설 전담 팀으로 전환해 도구 연동 관리, 상시 지원, 비용 통제를 계속 맡겼습니다.

명확한 기본 도구를 정하고 그 위에 워크플로를 설계해야 합니다. 엔지니어들에게 절실했던 것은 어떤 도구를 써야 하는지, 올바른 작업 흐름은 무엇인지, 그리고 어디서부터 시작해야 하는지에 대한 분명한 가이드였습니다. 기본값을 명확히 제시하되 각 팀이 상황에 맞게 조정할 여지를 남겨 둔 유연성이 원문에서 꼽은 가장 성공적인 결정 중 하나였습니다.

코드 생성이 빨라지면 병목은 필연적으로 검증 단계로 이동합니다. 이번 프로젝트에서 드러난 문제들은 대부분 에이전트 자체의 성능이 아니라 리뷰, CI, 문서, 연동 같은 주변 환경에서 비롯되었습니다. 따라서 Affirm은 이후의 리소스를 검증 파이프라인을 개선하는 데 가장 많이 집중했습니다. 빌드 실패의 원인이 코드 자체의 결함인지, 불안정한 테스트 때문인지, 아니면 인프라 문제인지를 자동으로 가려내고, 로컬 테스트 환경을 대폭 강화하며, 무거운 테스트들을 훨씬 빠르고 가벼운 계층으로 전환하는 작업을 진행하고 있습니다.

같은 세션이 작성한 코드와 테스트는 서로의 오류를 가려버릴 위험이 있습니다. 에이전트가 요구사항을 잘못 이해한 상태에서 구현 코드와 단위 테스트를 동시에 작성하면, 테스트는 오류 없이 통과하고 코드 커버리지도 완벽해 보이지만 실제 결함은 그대로 프로덕션에 배포됩니다. Affirm은 이러한 맹점을 막기 위해 PR diff를 초기 인수 기준과 대조하고 복수의 서로 다른 모델을 교차 활용해 독립적으로 검증하는 시스템을 시범 운영하고 있습니다.

장기적으로 누적되는 2차 문제를 경계해야 합니다. 원문은 에이전트가 생성한 코드가 급증함에 따라 시간이 지나면서 코드베이스 비대화, 코드 리뷰 및 배포 병목, 사내 스킬과 컨텍스트 파일의 무분별한 난립, 실제 운영 시스템에 대한 개발자들의 이해도 저하 같은 복합적인 문제가 발생할 수 있다고 경고합니다.

복제 조건과 한계. 이 접근법은 경영진이 비즈니스 출시 일정을 기꺼이 늦출 수 있는 결단을 내릴 수 있고, 사전 준비 기간에 핵심 인력을 전담으로 투입할 수 있으며, 사내에 이미 도구의 효용을 검증한 소수의 선도 그룹이 존재하는 조직이어야 효과를 볼 수 있습니다. 아울러 60%와 58%라는 수치는 Affirm 엔지니어링 블로그가 자체적으로 공개한 결과이며, 58% 증가는 주간 병합 PR 수라는 단순 양적 지표입니다. Affirm 스스로 밝혔듯이, 코드 리뷰와 CI 인프라가 뒷받침되지 않는다면 PR 수의 증가는 개발 속…

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit parkdaesun.substack.com

1. 왜 이 사례인가

원문은 SAP 전환을 기업이 맞닥뜨리는 가장 복잡하고 위험 부담이 큰 과제 가운데 하나로 꼽습니다. SAP 전환 프로젝트는 탐색, 설계, 테스트, 전환(cutover)을 거치며 12~18개월 동안 이어집니다. 업무 프로세스와 커스텀 코드가 복잡하게 얽혀 있는 데다, 사람 컨설턴트만으로는 단기간에 확충하기 어려운 도메인 전문성이 필요하기 때문입니다.

KTern.AI는 SAP 인증을 받은 DXaaS(Digital Transformation as a Service) 플랫폼으로, SAP S/4HANA 마이그레이션과 시스템 전환을 돕습니다. 이 회사는 기존 SaaS 플랫폼을 에이전트 플랫폼으로 개편하면서, 전환 단계별 작업을 각각 전담하는 전문 에이전트 20여 개를 Amazon Bedrock AgentCore 위에 올렸습니다. 원문은 이 에이전트들이 SAP 프로젝트 전체 기간을 평균 45%, 탐색·평가 기간을 60~70% 줄였다고 밝힙니다.

이 사례를 고른 이유는 뛰어난 성과 수치보다 구체적인 운영 방식에 있습니다. KTern.AI는 에이전트를 하나씩 코드로 개발하지 않고, 프롬프트·도구 연결·오케스트레이션 패턴으로 구성된 설정(configuration)만으로 배포합니다. 새 에이전트를 만드는 데 걸리던 시간도 2~3주에서 4~6시간으로 줄었습니다. 몇 달씩 이어지는 프로젝트에서 에이전트가 맥락을 잃지 않도록 돕는 메모리 설계, 고객사마다 다른 규칙을 코드 수정 없이 반영하는 멀티테넌트 구성도 함께 다룹니다. 도메인 소프트웨어 기업이 에이전트 인프라를 직접 구축하지 않고 어디까지 관리형 서비스에 맡길 수 있는지 보여 주는 사례입니다.

2. Problem

KTern.AI의 플랫폼이 발전할수록, 단순한 일문일답 형태의 AI 기능만으로는 자율적인 SAP 전환을 이끌기에 한계가 드러났습니다. 에이전트가 몇 달, 길게는 몇 년에 걸친 프로젝트 전체를 시야에 넣고 추론해야 했고, 여러 업무 영역을 동시에 조율하면서도 엄격한 기업 보안과 컴플라이언스 기준을 지켜야 했기 때문입니다. 원문은 맞물려 있던 과제를 다섯 가지로 정리합니다.

* 대규모 지속 맥락: 에이전트는 수백 번 이어지는 상호작용 속에서 상태를 유지하고, 과거 결정을 참조하며 프로젝트 전 기간에 걸친 맥락을 축적해야 했습니다. 하지만 맥락을 지나치게 많이 주입하면 응답이 느려지고 비용이 늘어나며 환각 위험도 커집니다. 따라서 핵심 목표는 무조건 많은 맥락이 아니라 적절한 맥락을 선별하는 것이었습니다.

* 안전하고 통제된 도구 연결: SAP API, 고객사 ERP 시스템, 프로세스 저장소, KTern.AI 데이터 저장소에 실시간으로 접근하려면, 기업 보안팀의 기준을 충족하는 인증 체계와 감사 가능한 연결 방식이 필수적이었습니다.

* 멀티테넌시와 설정 기반 유연성: 고객사는 저마다 독립된 테넌트로 운영되며, 프로세스와 예외 처리 방식, 비즈니스 규칙도 제각각입니다. 배포할 때마다 엔지니어가 맞춤형 코드를 작성하지 않고도 에이전트를 테넌트별 환경에 맞춰 유연하게 설정할 수 있어야 했습니다.

* 동적 확장: 가벼운 SAP 평가 작업에는 에이전트 몇 개를 몇 시간 동안만 쓰지만, 전사 마이그레이션 프로젝트에서는 에이전트 수십 개가 몇 달 동안 쉬지 않고 돌아갑니다.

* 프로덕션 수준의 관측성: 상세한 로그, 트레이스, 지표 없이 멀티 에이전트 워크플로를 디버깅하는 일은 기업 환경에서 불가능합니다. 에이전트의 모든 판단과 도구 호출 경로를 빠짐없이 추적할 수 있어야 했습니다.

AgentCore를 도입하기 전 KTern.AI는 자체 구축한 컨테이너 스택에서 애플리케이션을 운영했습니다. 원문은 이 방식이 작동은 했으나, 핵심 경쟁력인 “SAP 전환을 이해하는 에이전트 설계”와 무관한 기반 인프라 관리에 엔지니어링 역량을 낭비하게 만들었다고 설명합니다. 에이전트를 하나 추가할 때마다 오케스트레이션, 메모리, 도구 접근, 인증, 모니터링 인프라를 일일이 따로 구축해야 했고, 에이전트당 최소 2~3주가 걸렸습니다.

확인된 사실: SAP 전환 프로젝트 12~18개월, 지속 맥락·도구 연결·멀티테넌시·동적 확장·관측성의 다섯 가지 과제, 자체 운영 컨테이너 스택, 에이전트당 최소 2~3주 개발 기간.

3. Solution

3.1 도메인은 KTern.AI가, 인프라는 AgentCore가

KTern.AI는 Strands Agents SDK로 에이전트를 만들고 Amazon Bedrock AgentCore 위에서 운영합니다. 설계의 핵심 원칙은 관심사의 분리입니다. SAP 도메인 지식은 KTern.AI 계층에 집중하고, 호스팅, 확장, 메모리, 도구 접근, 인증, 관측성과 같은 인프라 영역은 전부 AgentCore에 맡겼습니다. 모델은 Amazon Bedrock을 통해 Anthropic Claude 계열 모델 등을 사용합니다.

모든 에이전트는 커스텀 오케스트레이션 코드 없이 설정으로 배포합니다. 에이전트의 동작 방식은 프롬프트, 도구 연결(tool binding), 오케스트레이션 패턴으로 정의됩니다. 오케스트레이션 패턴은 작업 성격에 맞춰 Strands의 멀티 에이전트 패턴 세 가지를 나누어 씁니다. 병렬 탐색에는 스웜(swarm), 순차 진행 작업에는 워크플로(workflow), 조건부 파이프라인에는 그래프(graph)를 적용합니다.

3.2 아키텍처

기업 사용자가 KTern.AI 플랫폼에 전환 요청을 전달하면, 이 요청은 에이전트 오케스트레이션 계층으로 들어갑니다. 전문 에이전트들은 AgentCore 런타임 위에서 세션별로 완벽히 격리된 상태로 실행되므로, 다른 고객사의 맥락에 접근하는 일이 원천 차단됩니다. 원문이 밝힌 AgentCore 주요 구성 요소별 역할은 다음과 같습니다.

에이전트는 AWS PrivateLink 기반 VPC 인터페이스 엔드포인트를 통해 Amazon Bedrock과 AgentCore에 접근하므로, 트래픽이 공용 인터넷을 거치지 않습니다. 주변 보조 시스템으로는 Amazon S3, AWS Lambda, AWS IAM을 활용합니다.

3.3 전환 단계를 나눠 맡는 에이전트 네트워크

KTern.AI는 20개가 넘는 전문 에이전트를 프로덕션 환경에서 운영하며, 고객 시나리오별로 50개가 넘는 에이전트 설정을 관리합니다. 에이전트는 저마다 SAP 전환 과정의 특정 영역을 책임집니다. 원문이 소개하는 핵심 에이전트는 다음과 같습니다.

* 리버스 엔지니어링 에이전트: 기존 SAP 환경에서 커스텀 ABAP 코드, 사용자 출구(user exit), 개선(enhancement), 설정, 프로세스 변형을 스캔하여 현재 시스템 상태 목록을 구축합니다. 이 결과물은 후속 에이전트들이 마이그레이션 영향도와 현대화 경로를 판단하는 공통 기준 자료가 됩니다.

* 포워드 엔지니어링 에이전트: 파악된 현재 상태를 토대로 클린 코어(표준 기능은 디지털 코어에 두고 확장은 외부로 분리하는 원칙)에 부합하는 목표 아키텍처, 표준 연동 패턴, 마이그레이션 코드를 작성하며, 유지·리팩터링·폐기 대상 항목을 권고합니다. 리버스 엔지니어링 에이전트와 맞물려 “리버스에서 포워드로 이어지는” 연속 파이프라인을 구성합니다.

* Fit-to-standard 에이전트: 비즈니스 프로세스를 SAP 표준 프로세스와 대조하여 커스터마이징으로 갈라지는 지점을 찾아내고 대체 방안을 제안합니다. 과거 기능 컨설턴트가 수백 개 프로세스를 수작업으로 검토하던 업무입니다.

* 커스텀 코드 분석 에이전트: 커스텀 ABAP 코드 전반을 마이그레이션 호환성, 사용 중단(deprecated) API 활용 여부, 성능 위험, 현대화 가능성 측면에서 평가하고, 객체별 복잡도를 분류하여 우선순위에 따른 조치 방안을 제시합니다.

* 테스트 케이스 생성 에이전트: 비즈니스 프로세스 흐름, 커스텀 코드 분석 결과, 시스템 설정 데이터를 바탕으로 테스트 데이터, 기대 결과, 검증 기준이 포함된 실행 가능한 테스트 케이스를 생성합니다.

* 프로세스 마이닝 에이전트: 구매-지급(P2P), 주문-수금(O2C), 기록-보고(R2R) 등의 SAP 이벤트 로그를 분석하여, 설계된 프로세스와 실제 운영 환경 간의 차이, 병목 구간, 재작업 루프, 자동화 기회를 도출합니다.

* 예외 마이닝 에이전트: 미대사 송장, 보류된 구매 주문, 미결 대변 메모, 청구 예외처럼 주로 사후에 발견되던 재무·영업 부문의 운영 예외를 FI, CO, SD, MM 모듈 전반에서 사전에 찾아 분류합니다. Gateway를 통해 고객사 시스템의 재무·영업 데이터에 직접 접근합니다.

3.4 프롬프트 관리와 평가

원문은 프롬프트를 중앙에서 통합 관리하여 전체 에이전트 배포에 걸쳐 버전 관리, 롤백, 일관된 거버넌스를 적용한다고 설명합니다. 에이전트 설정, 오케스트레이션 패턴, 적용 모델 역시 설정 기반으로 유연하게 테스트하며 배포 부담 없이 개선을 이어갑니다. 특히 결과물의 정확도가 가동(go-live) 위험과 직결되는 테스트 케이스 생성 에이전트의 경우, 별도의 자체 평가 도구를 구축하는 대신 AgentCore Evaluations를 활용해 설정이 바뀔 때마다 평가를 수행합니다. 원문은 이 방식을 통해 기반 모델 업데이트 등으로 일어나는 동작 변화를 조기에 감지한다고 설명합니다.

확인된 사실: Strands Agents SDK + Amazon Bedrock AgentCore, 도메인·인프라 관심사 분리, 프롬프트·도구 연결·오케스트레이션 패턴으로 구성된 설정 기반 배포, 스웜·워크플로·그래프 패턴, AgentCore 6개 구성 요소의 역할, PrivateLink VPC 엔드포인트, Claude 계열 모델, 20개 이상의 프로덕션 에이전트와 50개 이상의 설정, 7개 핵심 에이전트의 역할, 중앙 프롬프트 관리(버전 관리·롤백), 설정 변경마다 실행하는 평가.

4. Impact

원문은 다음 수치가 KTern.AI가 프로덕션 SAP 전환 프로젝트 전반에서 내부적으로 측정한 값이라고 명시합니다. 외부 감사를 거친 수치는 아니며, AWS 블로그에 KTern.AI와 AWS 담당자가 공동으로 기고한 내용입니다.

원문은 과거 탐색·평가 단계가 초기 프로젝트 예산에서 가장 큰 몫을 차지했다고 설명합니다. 시스템 가동 후 지원 요청이 40% 줄어든 주요 원인으로는 커스텀 코드 분석 에이전트가 잠재 위험을 초기에 식별해 낸 점을 꼽습니다. 절감한 월 480시간의 엔지니어링 리소스는 에이전트 고도화와 신규 기능 개발에 전량 재투자했습니다. 새 에이전트는 설정 배포를 거쳐 당일 바로 프로덕션 환경에 적용됩니다.

품질 측면에서는 표준화된 에이전트 기반 프로세스를 도입하면서, 투입되는 컨설턴트 팀의 역량에 따른 프로젝트별 품질 편차가 줄었다고 설명합니다. 관측성 측면에서는 기존에 여러 시스템의 로그를 수작업으로 대조하던 디버깅 작업이 몇 분 단위로 단축되었으며, 이러한 환경이 99.8% 가동률을 안정적으로 뒷받침한다고 밝힙니다.

한편 원문 초반에 등장하는 “7배 빠른 전환, 전체 작업량 24% 감소”라는 수치는 축적된 전환 패턴 지식 엔진과 하이퍼오토메이션을 아우르는 KTern.AI 플랫폼 전체를 가리키는 설명이며, 본문에서 다룬 에이전트 도입 성과와는 구별되는 별개의 수치입니다.

현재 KTern.AI는 에이전트 네트워크의 적용 범위를 공급망(Supply Chain), 인사(HR), Basis 운영 영역으로 확장하고 있습니다.

확인된 사실: 위 표의 수치와 “내부 측정”이라는 원문 단서, 탐색 단계의 예산 비중, 가동 후 요청 감소의 주된 요인, 480시간 재투자, 당일 배포, 품질 편차 감소, 추적 시간 단축, 7배·24%가 플랫폼 전체 수치라는 점, 공급망·HR·Basis 확장 계획.

5. Insight

도메인 기업은 도메인에 집중하고 인프라는 외부에 맡깁니다. KTern.AI가 AgentCore로 전환하며 얻은 가장 큰 소득은 단편적인 수치 개선보다 엔지니어링 리소스의 투입처가 바뀌었다는 점입니다. 이전에는 에이전트를 하나 만들 때마다 오케스트레이션, 메모리, 인증, 모니터링 환경을 조립하는 데 2~3주를 쏟아야 했지만, 이제는 SAP 전환을 깊이 이해하는 에이전트를 설계하는 본질적 작업에 그 시간을 사용합니다. 확보한 월 480시간을 에이전트 고도화에 온전히 재투자한 점이 이러한 변화를 잘 보여 줍니다.

에이전트를 코드가 아닌 설정으로 다루면 확장이 한결 수월해집니다. 에이전트 하나를 프롬프트, 도구 연결, 오케스트레이션 패턴의 조합으로 규정하면, 새로운 에이전트나 고객사용 변형 모델을 추가할 때 설정값 하나만 새로 정의하면 됩니다. 20여 개의 에이전트를 50개가 넘는 설정으로 유연하게 운영할 수 있는 배경입니다. 커스텀 오케스트레이션 코드를 직접 작성하고 싶을 때마다 설정 기반으로 풀어내는 편이 개발 속도와 유지보수성 면에서 훨씬 유리했다는 점 역시 원문이 꼽는 첫 번째 교훈입니다.

장기 프로젝트에서는 메모리 설계가 에이전트의 완성도를 결정합니다. 12~18개월 동안 이어지는 장기 프로젝트에서 에이전트가 매 작업마다 처음부터 다시 파악해야 한다면, 숙련된 컨설턴트처럼 일관되게 추론하기 어렵습니다. 그렇다고 모든 맥락을 전부 집어넣으면 응답이 느려지고 비용이 치솟으며 환각도 잦아집니다. 원문이 “첫 프롬프트를 쓰기 전에 메모리부터 설계하라”고 권고하는 배경입니다.

품질 평가는 출시 시점에 한 번으로 끝내지 않고 설정이 바뀔 때마다 수행합니다. 기반 파운데이션 모델이 업데이트되거나 프로덕션 데이터의 특성이 달라지면 에이전트의 동작 양상도 함께 바뀝니다. 설정이 변경될 때마다 평가를 자동으로 실행해야 고객이 문제를 겪기 전에 선제적으로 변화를 포착할 수 있습니다.

기업 고객 환경에서는 명확한 보안 검증이 도입을 가르는 전제 조건입니다. 규제가 엄격한 산업군의 고객은 에이전트가 내부 시스템에 접근하기 전에 인증 방식, 접근 제어 범위, 감사 가능 여부부터 꼼꼼히 점검합니다. 원문은 에이전트별 최소 권한 부여와 도구 호출에 대한 감사 기록 체계를 갖춘 덕분에, KTern.AI가 별도의 접근 제어 작업을 하지 않고도 보안팀이 프로덕션 배포를 승인할 수 있었다고 밝힙니다. 보안 요구사항에 확실히 대응할 수 있다면 구매 절차는 걸림돌이 아닌 신속한 도입의 계기가 됩니다.

복제 조건과 한계. 이 방식은 KTern.AI처럼 수년에 걸쳐 축적한 SAP 전환 패턴과 깊이 있는 전문 지식을 갖추고 있어야 실질적인 효과를 낼 수 있습니다. 설정만으로 에이전트를 빠르게 찍어낼 수 있는 이유는 그 설정에 채워 넣을 도메인 지식이 이미 탄탄하게 정리되어 있기 때문입니다. 또한 제시된 성과 수치는 모두 KTern.AI 내부 측정 결과이며, AWS 블로그에 AWS 담당자와 공동 작성한 자료라는 점을 함께 고려해야 합니다. 인프라 비용 70% 절감 역시 기존에 자체 운영하던 컨테이너 스택과 비교한 인프라 비용 기준입니다.

한 줄 요약: SAP처럼 길고 복잡한 전환 프로젝트에서는 인프라 관리를 전문 플랫폼에 위임하고 에이전트를 설정 기반으로 신속하게 배포하는 구조가, 도메인 전문성을 수십 개 에이전트로 빠르게 확장하는 유효한 방법이 될 수 있습니다.

6. 원문에 없는 추정 (구현 가설)

6.1 공통 에이전트 정의 위에 고객사 설정을 덧씌우는 구조

근거: 원문은 20개가 넘는 에이전트가 50개가 넘는 설정으로 운영되고, 에이전트의 동작이 프롬프트·도구 연결·오케스트레이션 패턴으로 정의되며, 고객사마다 프로세스·예외·비즈니스 규칙이 다른 독립 테넌트로 운영된다고 설명합니다. 프롬프트는 중앙에서 버전 관리하고 롤백할 수 있습니다.

에이전트 수보다 설정 수가 두 배 이상 많다는 점을 고려하면, 에이전트의 핵심 역할을 정의하는 공통 기본값과 고객사 시나리오별 변경 요소를 분리하여 관리했을 가능성이 높습니다. 예컨대 예외 마이닝 에이전트의 기본 설정에는 공통 역할 프롬프트와 FI·SD 모듈 데이터 조회 도구가 정의되어 있고, 고객사 설정에는 해당 기업 고유의 예외 판단 기준, 사용 가능한 도구 허용 범위, 대상 SAP 시스템 접속 정보가 추가로 얹히는 형태입니다. 이렇게 계층을 분리하면 공통 프롬프트를 수정했을 때 모든 고객사 환경에 일괄 반영하면서도 고객사 고유의 규칙은 안전하게 유지할 수 있습니다. 만약 공통 프롬프트 변경이 특정 고객사에서 문제를 일으키더라도 해당 고객사만 이전 버전으로 고정하는 유연한 대처도 가능했을 것입니다. 테넌트 간 분리는 AgentCore 런타임의 세션 격리 기능과 함께 메모리 저장 단위를 고객사 및 프로젝트별로 구분하는 방식으로 구현했을 것으로 추정됩니다.

6.2 리버스 엔지니…

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit parkdaesun.substack.com

1. 왜 이 사례인가

클라우드 코딩 에이전트를 외부 SaaS로 도입하면 편리하지만, 기업 내부의 개발 환경과 도구 생태계를 에이전트에게 그대로 제공하기는 어렵습니다. HubSpot은 이 문제를 직접 해결하기로 했습니다. 수십만 개 마이크로서비스와 하루 100만 건 이상의 빌드를 처리하는 기존 쿠버네티스(Kubernetes) 인프라 위에 에이전트 실행 플랫폼을 자체 구축한 것입니다.

HubSpot Product Blog에 2026년 1월 23일 게재된 엔지니어링 블로그 포스트에 따르면, 이 플랫폼의 이름은 Crucible이며 배포 이후 6개월 만에 7,000개 이상의 완전 AI 생성 PR이 병합되었고, 50,000개 이상의 PR이 AI 코드 리뷰를 거쳤습니다.

이 사례가 눈길을 끄는 이유는 단순한 에이전트 활용법에 그치지 않고, 기업이 자체 에이전트 인프라를 어떻게 구축하는가에 관한 구체적인 아키텍처와 운영 경험을 공개했다는 점입니다. 빌드 캐시 전략, 에이전트 행동을 제어하는 훅(hooks) 시스템, 비결정론적 AI와 결정론적 코드 로직의 분리 방법 등 다른 조직에서도 참고할 수 있는 설계 결정들이 담겨 있습니다.

2. Problem

HubSpot 엔지니어링 조직이 에이전트 플랫폼을 구축하며 마주한 문제는 크게 두 가지였습니다.

첫째, 외부 클라우드 에이전트 서비스로는 HubSpot의 개발 환경을 재현하기 어려웠습니다. HubSpot은 수만 개에 달하는 마이크로서비스, 사내 전용 빌드·배포 시스템, 내부 도구 및 라이브러리로 이루어진 복잡한 엔지니어링 생태계를 갖추고 있습니다. 블로그 포스트 저자인 Stephan Lensky는 사내 전용 도구의 비중이 높아 외부 제공업체 환경으로 이를 복제하기가 상당히 어려울 것이라고 판단했습니다.

둘째, 에이전트가 사내 빌드 로그, 통합 테스트, 내부 서비스에 접근하는 긴밀한 피드백 루프가 필요했습니다. 에이전트가 PR을 생성할 때는 빌드 통과 여부와 테스트 실패 여부를 실시간으로 확인하고, 그 결과에 맞춰 다음 행동을 조정할 수 있어야 했습니다. 이를 구현하려면 에이전트가 사내 개발 도구 전반과 맞물려 돌아가야 했습니다.

초기 에이전트 운영 과정에서 반복해서 나타난 실패 패턴도 있었습니다. 에이전트가 빌드에 실패한 상태인데도 작업을 마쳤다고 판단하거나, 사용자에게 필요한 내용을 알리지 않거나, PR 생성 자체를 빠뜨리는 일이 발생했습니다.

확인된 사실: HubSpot의 기존 K8s 인프라 규모(하루 100만 건 빌드, ~3,000개 EC2 인스턴스, 수만 개 마이크로서비스), 외부 에이전트 서비스 대신 자체 플랫폼 구축을 선택, 6개월 운영 후 7,000+ AI 생성 PR 병합, 50,000+ AI 코드 리뷰.

3. Solution

HubSpot은 기존 K8s 인프라를 바탕으로 Crucible이라는 에이전트 실행 플랫폼을 자체 구축했습니다. Claude Code를 핵심 모델로 채택하고, 이를 사내 개발 환경에 통합하는 데 필요한 모든 작업을 직접 구현했습니다.

3.1 Crucible 아키텍처

Crucible은 네 가지 핵심 구성 요소로 이루어집니다.

* 프론트엔드: 실행 이력을 조회하고 전사 로그를 확인하는 내부 인터페이스

* API 서버: 새 에이전트 실행 요청을 처리하고, 실행 상태와 결과(파일 변경 git diff)를 반환

* 쿠버네티스 Job: 에이전트 실행 1건이 K8s Job 리소스 1개에 1:1로 대응하며, API 서버가 Job을 동적으로 생성하고 모니터링

* 도커 이미지: Claude Code와 사내 개발 도구 일체를 미리 설치한 커스텀 이미지. 이미지 진입점(entrypoint)에서 대상 Git 리포지터리 클론과 실행 프롬프트를 통한 Claude 실행을 자동으로 처리

이 구조는 모든 에이전트 실행을 샌드박스로 격리해 확장이 쉬우며, 코드 변경뿐 아니라 PR 리뷰 같은 다양한 요청도 처리할 수 있습니다.

3.2 주요 엔지니어링 난제 해결

컨테이너 환경 재현: 사내 도구 대부분이 로컬 노트북 환경을 전제로 만들어져 K8s 컨테이너에서는 동작하지 않았습니다. 개발팀은 이들 도구가 컨테이너 환경에서도 정상 작동하도록 다수의 도구를 직접 수정했습니다.

빌드 속도: Java 빌드 시간이 10~15분에 달했습니다. 기존 빌드 인프라를 운영하며 얻은 경험을 살려 전용 K8s 노드 풀에서 에이전트를 실행하고 호스트에 빌드 캐시를 마운트했습니다. 그 결과 대부분의 리포지터리에서 첫 빌드 시간을 2~3분으로 단축했습니다.

리소스 튜닝: 리포지터리 크기에 따라 메모리를 비롯한 하드웨어 자원 요구량이 달랐습니다. 팀은 K8s가 제공하는 수직 확장(vertical scaling)의 이점을 활용해 이 문제를 원활하게 처리했습니다.

3.3 GitHub·Slack 통합: Sidekick

HubSpot은 Crucible 위에 GitHub와 Slack 연동 기능을 구현했습니다. 기존 사내 AI 어시스턴트인 Sidekick을 확장하여, GitHub 이슈나 Slack에서 @-멘션으로 에이전트를 호출하는 인터페이스를 제공합니다.

지원하는 워크플로는 세 가지입니다.

이슈 계획(Issue planning): GitHub 이슈에서 @SidekickAI create a plan을 멘션하면 에이전트가 구현 계획을 이슈 댓글로 남깁니다. 사용자는 이 계획을 검토·수정한 뒤 다음 구현 단계로 넘어갑니다.

자율 구현(Autonomous implementation): Sidekick에게 이슈를 배정하면 에이전트가 자율적으로 이슈를 구현하고 PR을 생성합니다. 이슈 세부사항, 커밋·푸시 지침, 사용자 소통 방식(댓글 게시 또는 PR 본문 편집)은 템플릿 기반 프롬프트로 구성됩니다.

PR 리뷰: PR이 새로 생성되거나 ready for review 상태로 바뀔 때, 또는 Sidekick을 리뷰어로 직접 지정할 때 자동으로 실행됩니다.

확인된 사실: Crucible 구성 요소(프론트엔드·API서버·K8s Job·Docker), Claude Code 기반, Sidekick GitHub·Slack @-멘션 연동, 빌드 시간 10~15분 → 2~3분, 6개월 이내 7,000+ AI 생성 PR, 50,000+ AI 리뷰.

3.4 에이전트 신뢰성 확보: 결정론 + 훅

자율 구현 워크플로에서는 세밀한 조정 작업이 가장 많이 필요했습니다. 개발팀은 두 가지 핵심 원칙을 적용했습니다.

비결정론적 변환과 결정론적 로직의 분리. 기능 구현 과정에서 LLM의 유연성이 필요한 영역과 결정론적 코드로 처리할 수 있는 영역을 엄격히 구분했습니다. 예를 들어 이슈 작업을 시작할 때 새 브랜치를 만들고 드래프트 PR을 생성하는 작업은 언제나 결정론적 코드로 먼저 실행합니다. 그런 다음 생성된 브랜치 이름과 PR 번호를 에이전트 프롬프트에 템플릿 값으로 넣어주며, 에이전트에게 이 작업을 맡기지 않습니다.

훅(hooks) 시스템으로 에이전트 행동 강제. Claude Code의 훅 기능을 활용해 에이전트의 동작을 여러 단계에서 제어합니다. 실제 적용 중인 훅의 예시는 다음과 같습니다.

* 커밋 메시지가 지나치게 길면 자동으로 차단

* 관례에 어긋나는 편집(예: Java 전체 한정 클래스명 사용)은 자동 차단하되, 두 번째 시도는 허용

* 빌드가 통과하고 변경 사항이 커밋·푸시되기 전에는 에이전트가 임의로 작업을 끝낼 수 없음

확인된 사실: 결정론적 로직과 AI 로직의 분리 적용, Claude Code 훅 시스템 활용, 커밋 메시지 길이·코딩 스타일·작업 완료 조건 강제, 정확한 Git 리포지터리를 찾기 위한 소형 에이전트 활용, PR 추적을 위한 브랜치 이름·PR 본문에 엔지니어 username 임베드.

4. Impact

HubSpot Product Blog(2026-01-23) 기준 제시 지표입니다.

블로그 포스트는 대부분의 HubSpot 엔지니어가 Crucible과 Sidekick을 매일 활용해 작업 속도를 높이고 있다고 밝혔습니다. 또한 Crucible이 대규모 코드 마이그레이션 자동화나 빌드 실패 자동 수정 등 사내 여러 업무에 두루 쓰이고 있다는 점도 언급했습니다.

5. Insight

이 사례는 에이전트 인프라를 자체 구축하는 편이 언제 더 유리한가를 잘 보여줍니다.

내부 도구 생태계가 복잡할수록 자체 구축이 유리합니다. 외부 에이전트 서비스를 도입하려면 네트워크 접근, 인증, 내부 도구 재현이라는 세 가지 장벽을 넘어야 합니다. HubSpot처럼 사내 전용 빌드 시스템, 자체 라이브러리, 방대한 마이크로서비스 아키텍처를 갖춘 조직에서는 외부 서비스를 쓰기보다 자체 플랫폼을 꾸리는 편이 환경 재현 속도와 제어력 측면 모두에서 더 나을 수 있습니다.

빌드 속도는 에이전트 피드백 루프의 핵심 변수입니다. 에이전트가 빌드 결과를 확인하며 다음 행동을 결정하는 환경에서, 빌드에 10분씩 걸린다면 에이전트가 여러 차례 시도하기 어렵습니다. 전용 노드 풀과 빌드 캐시를 도입해 첫 빌드 시간을 2~3분으로 줄인 조치는 에이전트의 실질적인 생산성 개선으로 이어졌습니다.

결정론적 로직이 에이전트 신뢰성을 뒷받침합니다. LLM에 모든 과정을 맡기면 비결정성이 쌓이게 됩니다. HubSpot은 브랜치나 PR 생성처럼 반드시 수행해야 하는 작업은 일반 코드로 확실하게 처리하고, 창의적인 판단이 필요한 영역만 LLM에 넘겼습니다. 훅 시스템은 이러한 경계를 실행 시점에 강제하는 역할을 합니다.

복제 조건: 자체 K8s 인프라와 컨테이너 환경을 안정적으로 다루는 역량이 먼저 갖춰져야 합니다. 아울러 사내 개발 도구를 컨테이너 환경에 맞춰 수정하는 데도 적지 않은 엔지니어링 공수가 들어갔습니다. 따라서 이러한 투자를 회수하려면 에이전트를 활용하는 규모(엔지니어 수 × 사용 빈도)가 충분히 뒷받침되어야 합니다. 배포 6개월 만에 7,000건의 PR이 생성되었다는 수치는 이 같은 투자가 타당했음을 보여줍니다.

6. 원문에 없는 추정 (구현 가설)

6.1 에이전트 프롬프트 생성 파이프라인

근거: 포스트는 자율 구현 프롬프트가 템플릿에서 생성되며 이슈 세부사항, 커밋·푸시 지침, 사용자 소통 방법이 포함된다고 설명합니다. 또한 계획 단계의 이슈 댓글이 구현 단계의 프롬프트 입력이 됩니다.

이슈 제목과 본문만으로는 에이전트가 어떤 파일을 수정해야 하는지 파악하기 어렵습니다. 포스트에서 “파일에 대한 구체적인 참조를 포함한 상세 구현 계획이 에이전트에게 큰 도움이 된다”는 언급이 있는 것으로 보아, 계획 단계 에이전트가 이슈를 분석해 관련 파일 경로와 함수 서명을 구현 프롬프트에 포함하는 RAG 또는 코드 검색 레이어가 있을 가능성이 높습니다. 또한 사내 코딩 스타일 가이드와 기존 패턴 예시를 프롬프트에 포함하는 컨텍스트 주입 단계가 표준화되어 있을 것으로 추정됩니다.

6.2 코드 리뷰 에이전트의 피드백 분류

근거: 포스트는 PR 리뷰 에이전트가 50,000건 이상의 PR을 처리했으며, 코드 리뷰 품질 향상에 대한 별도 포스트를 예고합니다. 또한 에이전트가 생성한 코드에서 중복 코드와 패턴 불일치가 가장 많이 발견되는 문제라고 언급합니다.

리뷰 에이전트가 단순 스타일 지적과 기능적 오류 지적을 구분하지 못하면 리뷰어의 주의가 분산됩니다. 에이전트 리뷰가 실질적으로 활용되려면 코드베이스 전체의 기존 패턴을 벡터 저장소나 임베딩으로 보유하고, 현재 PR의 변경 사항이 기존 패턴과 얼마나 유사한 코드를 이미 가지고 있는지 판별하는 중복 탐지 레이어가 작동할 것으로 보입니다. 리뷰 댓글의 심각도를 자동으로 라벨링(예: blocking/non-blocking/suggestion)하는 구조가 엔지니어 수용률을 높이는 데 중요하며, 이 분류 정확도 데이터가 리뷰 에이전트의 파인튜닝 소재가 될 것으로 분석됩니다.

6.3 멀티 리포지터리 환경에서의 리포지터리 선택 에이전트

근거: 포스트는 GitHub 이슈에서 에이전트를 트리거할 때 올바른 Git 리포지터리를 선택하는 문제를 소형 에이전트를 통해 해결했다고 설명합니다.

HubSpot 규모의 조직에서 수만 개의 마이크로서비스 리포지터리가 있다면, 이슈 제목과 설명만으로 올바른 리포지터리를 자동 선택하는 것은 비결정적 문제입니다. 이 소형 에이전트는 이슈 내용에서 서비스명이나 기능 영역을 추출하고, 내부 서비스 레지스트리나 팀 소유권 메타데이터와 대조해 후보 리포지터리 목록을 좁히는 방식으로 작동할 개연성이 높습니다. 엔지니어가 이슈에 리포지터리를 명시할 수 있는 방법을 함께 제공해, 소형 에이전트의 추론이 불확실한 경우 수동 오버라이드가 가능한 구조를 갖추고 있을 것으로 추정됩니다.

7. 출처

* HubSpot Product Blog — Cloud Coding Agents at HubSpothttps://product.hubspot.com/blog/cloud-coding-agents-at-hubspot게시일: 2026-01-23 (블로그 본문 날짜, 저자: Stephan Lensky)

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit parkdaesun.substack.com

1. 왜 이 사례인가

에이전트형 AI 도입 사례는 대형 기술 기업이나 수백 명 규모의 조직에서 나오는 경우가 많습니다. Equipter는 그 반대편에 있습니다. 건설 장비를 제조·판매하고 미국과 캐나다 전역에 400개 이상의 렌탈 파트너를 둔 이 회사의 내부 영업팀은 단 6명에 불과합니다.

그런데 이 팀에는 매주 150~200건의 인바운드 리드가 유입됩니다. 건설 현장은 일정이 촉박하므로 반응 속도가 계약 성사를 좌우합니다. 6명이 200건을 빠르게 처리하면서 기존 상담과 계약 마감까지 동시에 챙기는 것은 현실적으로 매우 어려운 과제입니다.

Salesforce 케이스 스터디는 Equipter가 Sales Cloud의 Agentforce를 도입해 이 병목을 어떻게 해결했는지를 다룹니다. 규모가 작은 팀이 단 2주 만에 에이전트를 실제 환경에 배포하고, 사실상 포기했던 장기 미응대 잠재 고객층까지 다시 활성화했다는 점에서 주목할 만합니다.

2. Problem

Equipter 영업팀이 마주한 핵심 과제는 단순한 업무량 부담이 아니었습니다. 속도와 파이프라인 폭이 함께 맞물린 구조적 병목이었습니다.

6인 팀이 영업 초기 접촉(prospecting)부터 계약 체결(closing)까지 전 과정을 도맡아 처리합니다. 매주 150~200건의 인바운드 리드가 들어오고, 건설 업계 특성상 고객은 장비를 급히 필요로 합니다. 팀은 2시간 내 응답을 목표로 잡았지만 현실적으로 지키기 어려웠습니다. 신규 리드와 진행 중인 거래를 함께 챙기다 보면 응답 시간은 8시간, 때로는 하루를 넘기기 일쑤였습니다.

문제는 여기서 그치지 않았습니다. 제때 응답하지 못한 리드는 시간이 흐르며 방치된 잠재 고객으로 굳어졌습니다. 영업팀은 쏟아지는 새 리드를 쫓느라 과거에 응대하지 못한 수백 건의 잠재 고객에게 다시 연락할 엄두를 내지 못했습니다. 미응대 리드로 이루어진 파이프라인이 계속 쌓여 가고 있었습니다.

확인된 사실: 6인 영업팀, 주당 150~200건 인바운드 리드, 목표 응답 시간 2시간, 실제 응답 시간 평균 8시간(때로는 하루 이상), 미응대 리드 누적.

3. Solution

Equipter는 인력을 추가로 채용하는 대신 Sales Cloud에 Agentforce를 배포하는 방식을 선택했습니다. 도입 과정은 크게 두 단계로 진행되었습니다.

3.1 소셜 미디어 리드 전담 에이전트 배포

첫 번째 대상은 소셜 미디어에서 유입되는 리드였습니다. 웹사이트에서 직접 문의하는 구매 의향이 높은 리드보다 전환율이 낮아 자율 에이전트를 시험 적용하기에 알맞은 대상이었습니다.

팀은 기본 제공(out-of-the-box) 템플릿을 활용해 2주 만에 에이전트를 배포했습니다. 에이전트는 리드가 들어오면 수분 내에 4일간 총 4회 이어지는 이메일 아웃리치 일정을 시작합니다. 각 이메일은 유입 경로(소셜 미디어 등)와 CRM에 수집된 잠재 고객 정보를 바탕으로 맞춤 작성됩니다. 에이전트가 초기 접촉을 도맡는 동안, 영업 담당자는 웹사이트를 통해 들어온 구매 의향이 높은 리드에 집중합니다.

소셜 미디어 리드의 응답률은 에이전트 도입 이후 4%에서 약 10%로 2.5배 올랐습니다.

3.2 장기 미응대 잠재 고객 재활성화

팀은 추가 시험으로 최대 10개월 동안 연락이 끊겼던 잠재 고객에게 에이전트로 다시 말을 건네 보았습니다. 결과는 기대 이상이었습니다. 오랫동안 방치되었던 잠재 고객의 응답률이 신규 리드와 동일한 수준으로 나타났습니다.

이는 리드 자체의 질이 떨어져서가 아니라 적절한 시점에 꾸준히 연락을 받지 못해 계약으로 이어지지 않았음을 보여줍니다. 에이전트가 규칙적으로 연락을 취한 덕분에 이 잠재 고객층이 실제 영업 파이프라인으로 다시 편입되었습니다.

3.3 에이전트-영업 담당자 인계 구조

에이전트와 잠재 고객이 나눈 대화 내역과 맥락은 Sales Cloud에 그대로 기록됩니다. 잠재 고객이 회신하면 담당자에게 즉시 알림이 전달됩니다. 영업 담당자는 앞서 기록된 대화를 바탕으로 장비 제원, 견적, 대여 지점 안내 등 구체적인 상담을 바로 이어갑니다. 에이전트가 미리 파악해 둔 맥락이 사람 담당자의 영업 출발점이 되는 구조입니다.

확인된 사실: Agentforce + Sales Cloud, 소셜 미디어 리드 에이전트 2주 만에 배포, 아웃리치 캐던스 4일 4회 이메일, 응답률 4% → ~10% (2.5배), 오래된 잠재 고객 응답률 = 신규 리드 수준, 에이전트 접촉 리드의 약 2%가 실제 영업 기회로 전환, David Beiler VP Sales 인용문.

4. Impact

Salesforce 케이스 스터디(약 2026-03-18 기준)에서 제시한 지표입니다.

David Beiler VP, Sales는 “Agentforce가 응답 시간을 수분으로 단축하여 팀이 더 높은 가치의 대화에 집중할 수 있게 했다”고 말합니다.

에이전트가 접촉한 리드 가운데 2%가 전환되었다는 수치는 단순한 비율 이상의 의미가 있습니다. 응대할 여력이 없어 사실상 버려두었던 파이프라인에서 나온 성과이기 때문입니다. Equipter의 평균 계약 규모를 감안하면 그냥 흘려보낼 뻔한 매출을 되살려낸 셈입니다.

케이스 스터디는 다음 단계로 렌탈 파트너 전담 에이전트 배포를 계획 중이라고 밝혔습니다. 렌탈 파트너 문의와 직접 판매 문의를 갈래별로 나누어 전달하는 복잡한 라우팅 업무를 맡기는 것이 목표입니다.

5. Insight

이 사례의 핵심 교훈은 소규모 조직에서 AI 에이전트는 인력 감축이 아니라 처리 용량(capacity)의 한계를 넓혀 준다는 점입니다.

응답 속도 자체가 영업 경쟁력입니다. 장비가 급히 필요한 건설 업계 고객에게 8시간 뒤 연락하는 것과 몇 분 만에 대응하는 것은 계약 성사율에 곧바로 영향을 미칩니다. 에이전트가 응답 지연 문제를 해소해 준 덕분에 영업팀은 고객의 초기 관심을 실제 계약으로 전환하는 데 화력을 모을 수 있었습니다.

버려지던 파이프라인을 되살릴 수 있습니다. 오랫동안 연락이 끊겼던 고객의 응답률이 신규 리드와 같았다는 사실은, 기존에 손실되었다고 여긴 파이프라인이 사실 연락 시점과 지속성의 문제였음을 드러냅니다. 에이전트는 인력 부족으로 챙기지 못했던 공백을 촘촘히 메웠습니다.

2주 배포는 낮은 도입 장벽을 보여줍니다. Salesforce의 기본 템플릿을 활용해 2주 만에 실제 운영 환경에 적용할 수 있었다는 점은, 별도의 AI 개발팀이 없는 작은 기업도 에이전트를 실무에 바로 활용할 수 있다는 좋은 선례가 됩니다.

복제 조건: Salesforce CRM이 리드 관리의 중심에 자리 잡고 있어야 합니다. 에이전트가 작성하는 맞춤형 메시지의 완성도는 CRM에 축적된 고객 데이터의 양과 질에 정비례합니다. 케이스 스터디의 지표(응답률 2.5배, 전환율 ~2%)는 Salesforce 고객 사례에 실린 내용이며, 외부 감사를 거친 수치는 아닙니다.

6. 원문에 없는 추정 (구현 가설)

6.1 소셜 미디어 리드 품질 분류와 에이전트 분기 로직

근거: 케이스 스터디는 소셜 미디어 리드가 웹사이트 리드보다 전환 의향이 낮아 에이전트 처리의 우선 대상으로 삼았다고 설명합니다. 영업 담당자는 웹사이트 유입 고의향 리드에 집중합니다.

이 분기를 자동화하려면 리드 소스 필드(Salesforce의 Lead Source)를 기반으로 Agentforce가 처리할 리드와 영업 담당자에게 직접 배정할 리드를 자동으로 구분하는 라우팅 로직이 필요합니다. 향후 렌탈 파트너 전담 에이전트 배포 계획을 고려하면, 이 라우팅 레이어가 이미 구성되어 있으며 에이전트 유형(소셜/렌탈/직판)에 따라 다른 캐던스와 개인화 템플릿을 적용하도록 설계될 것으로 보입니다.

6.2 4일 캐던스의 중단 조건과 에스컬레이션 트리거

근거: 케이스 스터디는 에이전트가 4일 연속 4회 이메일 캐던스를 운영하며, 잠재 고객이 응답하면 담당자에게 알림을 발송한다고 설명합니다.

응답 외에도 캐던스를 중단해야 하는 조건들이 있습니다. 옵트아웃(수신 거부) 요청, 이미 다른 채널에서 영업 담당자와 접촉 중인 경우, 이메일 하드 바운스 등입니다. 건설 업계에서 동일한 잠재 고객이 여러 경로(소셜, 웹, 파트너 추천)로 동시 유입되는 중복 리드 상황도 발생할 수 있습니다. 이 경우 중복 접촉을 방지하는 중복 감지 로직이 Sales Cloud 내에서 작동하고 있을 가능성이 높습니다. 캐던스 4번이 모두 무응답으로 끝나는 경우에도 해당 리드를 ‘장기 재활성화 풀’로 이관하는 별도 자동화 경로가 있을 것으로 추정됩니다.

6.3 대화 맥락 인계와 담당자 준비 품질

근거: 케이스 스터디는 에이전트와 잠재 고객의 대화 내역이 Sales Cloud에 기록되고, 담당자가 이를 바탕으로 장비 사양·가격·렌탈 위치 논의로 즉시 연결한다고 설명합니다.

에이전트가 수집한 맥락이 영업 담당자에게 실질적으로 유용하려면, 에이전트 대화의 요약본 또는 구조화된 필드(잠재 고객이 언급한 필요 장비 유형, 프로젝트 시작 시점, 지역 등)가 CRM 레코드에 자동으로 추가되는 구조가 필요합니다. 단순히 이메일 전문을 저장하는 것과 달리, 담당자가 첫 번째 실제 통화 전에 빠르게 훑어볼 수 있는 형태로 요약이 제공될 경우 인계 경험의 품질이 높아집니다. 이 구조화 방식이 성숙할수록, 에이전트 수집 맥락이 담당자 성과에 미치는 영향을 측정하는 내부 지표로 발전할 가능성이 있습니다.

7. 출처

* Salesforce — Equipter increases lead response rates 2.5x with Sales Cloudhttps://www.salesforce.com/customer-stories/equipter/게시 연도: 약 2026-03-18 (queue 기재 기준; Salesforce 원문 미표기)

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit parkdaesun.substack.com

1. 왜 이 사례인가

대부분의 GTM(Go-To-Market) AI 도입 사례는 대규모 조직이 운영 효율을 개선한 이야기입니다. 하지만 머지(Merge)는 정반대의 조건에서 이 난제에 도전했습니다. 수익 운영(RevOps) 4명과 마케팅 5명, 총 9명의 작은 인력으로 영업, 고객 성공(CS), 마케팅을 동시에 빈틈없이 지원하면서도 수만 개에 달하는 엔터프라이즈 계정을 상시 관리해야 하는 구조였습니다.

도전 과제는 단순히 인력 부족에 그치지 않았습니다. 머지가 제공하는 제품 자체의 기술적 복잡성이 GTM 운영의 난도를 구조적으로 높였습니다. 머지의 핵심 제품인 머지 유니파이드(Merge Unified)는 8개 카테고리에 걸친 B2B 고객 대면 통합 API를 전 산업군에 제공하는 수평적 플랫폼입니다. 여기에 머지 에이전트 핸들러(Merge Agent Handler)가 추가되면서, 고객사는 엔터프라이즈급 MCP(Model Context Protocol) 서버와 AI 에이전트를 손쉽게 연결할 수 있게 되었습니다. 즉, 잠재 고객마다 서로 다른 기술 스택과 독자적인 활용 사례(use case) 조합에 맞추어 정밀한 제품 포지셔닝을 제시해야 했습니다.

클레이(Clay) 고객 사례 페이지는 머지의 RevOps 및 마케팅 리드 팀 부르시에(Tim Bourcier)가 클레이 기반 AI 에이전트 워크플로를 구축하여 이러한 운영 복잡성을 해결한 과정을 구체적인 데이터와 함께 소개합니다. 이 사례가 특히 주목받는 이유는 단순한 단일 SaaS 도구 도입에 머물지 않고, 각 데이터 레이어가 다음 레이어로 통찰을 지속 공급하는 유기적 복합 데이터 시스템을 구축했다는 점입니다.

2. Problem

머지의 GTM 팀이 직면한 과제는 표면적으로는 단순한 정보 부족처럼 보였지만, 본질적으로는 데이터 사일로 현상과 실시간 계정 인텔리전스의 부재였습니다.

세일즈포스(Salesforce), 공(Gong), 각종 스프레드시트 등 사내 도구에 원천 데이터는 충분히 쌓여 있었습니다. 그러나 실무자가 그 방대한 데이터를 실제 영업 활동에 즉각 활용할 수 있는 형태로 통합하고 해석하는 데 지나치게 많은 시간이 소모되었습니다. 부르시에는 “회사에는 매우 정교한 시스템과 방대한 데이터 포인트, 수많은 지식이 축적되어 있었습니다. 문제는 이것을 일선 실무자들이 당장 활용할 수 있도록 어떻게 실시간으로 전달하느냐였습니다”라고 당시 상황을 설명합니다.

구체적인 병목은 다음 세 가지 영역에서 두드러졌습니다.

첫째, 아웃바운드 영업 단계에서 담당자가 타깃 계정마다 적합한 접근 메시지를 개별적으로 일일이 조사해야 했습니다. 머지의 제품군이 8개 카테고리에 걸쳐 광범위하게 분산되어 있어, 동일한 기업이라도 분기마다 신제품을 출시하거나 조직 개편이 발생하면 필요한 연동 유스케이스가 완전히 달라집니다. 지난 분기의 낡은 포지셔닝으로 이번 분기 고객에게 접근할 경우 미팅 전환율이 급락할 수밖에 없었습니다.

둘째, 고객 성공(CS) 팀이 계약 갱신이나 확장(upsell) 논의를 준비할 때, 공에 저장된 통화 녹취록과 세일즈포스의 제품 사용 데이터를 수작업으로 일일이 검토해야 했습니다. 고객 성공 매니저(CSM) 한 명이 자신이 담당하는 모든 계정의 방대한 통화 녹음을 물리적으로 청취하는 것은 불가능에 가까웠습니다.

셋째, 오프라인 이벤트 투자 대비 비즈니스 성과 추적이 불투명했습니다. 분기 영업 파이프라인의 20~25%가 오프라인 콘퍼런스와 이벤트에서 창출되었지만, 공식 부스 밖 복도나 휴게 공간에서 명함 없이 나눈 수많은 유력 대화들이 세일즈포스에 제때 기록되지 못해 후속 조치 없이 유실되는 리드가 상당수에 달했습니다.

확인된 사실: RevOps 4명·마케팅 5명 팀 구성, Merge Unified API 8개 카테고리, Merge Agent Handler(엔터프라이즈 MCP 서버), 데이터 소스는 Salesforce·Gong·스프레드시트·기타 도구.

3. Solution

부르시에 리드가 구축한 시스템은 세 개의 핵심 레이어로 구성되며, 각 레이어가 다음 단계로 정제된 데이터를 순차 공급하도록 정교하게 설계되었습니다.

3.1 TAM 지도 구축 및 엔터프라이즈 계정 실시간 모니터링

첫 번째 과제는 어떤 타깃 계정에 영업 리소스를 집중할지 명확히 선별하는 작업이었습니다. 세일즈포스에 등록된 50,000개 이상의 계정을 클레이로 일괄 보강(enrich)하여 산업군, 세부 업종, 그리고 계정별 맞춤 머지 유스케이스를 자동으로 분류하고 태깅했습니다. 영업 담당자가 계정마다 시간을 들여 리서치하는 대신, 시스템이 사전에 준비한 완결된 데이터를 바탕으로 즉시 대화에 나설 수 있게 했습니다.

하지만 전체 시장(TAM) 지도는 과거 시점의 스냅샷일 뿐이며, 엔터프라이즈 계정의 비즈니스 환경은 살아 숨 쉬듯 빠르게 변합니다. 부르시에는 별도의 클레이 에이전트를 구축하여 핵심 1,500개 엔터프라이즈 계정의 동향을 매주 실시간으로 추적했습니다. 이 에이전트는 타깃 기업의 신제품 출시, 신규 기능 업데이트, 전략적 파트너십 체결, 주요 임원진 영입 등 전통적인 정적 데이터베이스에서는 포착하기 어려운 실시간 이벤트를 전방위로 감지합니다. 유의미한 비즈니스 변화가 포착되면, 에이전트는 계정 담당자에게 핵심 맥락 요약과 함께 즉시 발송 가능한 맞춤형 콜드 이메일 초안을 자동으로 전달합니다.

확인된 사실: Salesforce 50,000개 이상 계정 보강·태깅, 1,500개 엔터프라이즈 계정 주간 모니터링, SDR 주당 10시간 이상 절감, 응답률 20% 향상, 엔터프라이즈 미팅 15% 증가 (Clay 게시 기준).

3.2 고객 건전성 지능화 및 CS 팀 지원

두 번째 레이어는 기존 고객의 이탈을 막고 계약 규모를 확장하기 위해 동일한 인텔리전스 파이프라인을 적용했습니다. 부르시에는 클레이를 공 및 세일즈포스와 연동하여 분기별 사업 리뷰(QBR) 미팅의 통화 녹취록을 심층 분석하는 전담 에이전트를 구축했습니다. 이 에이전트는 고객과의 대화에서 드러나는 뉘앙스와 감정 흐름, 구체적인 제품 개선 요청과 불편 사항, 그리고 API 카테고리별 실사용량 추이를 정밀 추출하여 이탈 위험이나 추가 라이선스 구매 가능성을 나타내는 신호를 자동으로 포착합니다.

이러한 분석 결과는 CS 조직 전체에 두 가지 경로로 실시간 제공됩니다. 개별 고객 담당자는 계약 갱신이나 업셀 상담에 들어가기 전, 해당 고객의 최근 API 사용 패턴과 관심 제품 영역, 최근 통화 분위기를 완벽히 숙지한 상태로 미팅을 주도합니다. 조직 차원에서는 고객 세그먼트 및 제품 카테고리별 건전성 현황이 전사 대시보드로 집계됩니다. 아울러 동일한 통찰이 제품 개발 팀에도 공유되어, 과거 상담 녹음 파일 속에 방치되던 고객의 생생한 피드백이 체계적으로 정제된 제품 개선 데이터로 전환됩니다.

에이전트가 고객의 부정적 감정이나 이탈 위험을 감지하여 알림을 발송하면 CS 팀이 선제적으로 밀착 지원에 나서며, 지원 티켓과 제품 개선 백로그가 내부 시스템에 자동으로 등록됩니다.

확인된 사실: CSM 주당 5시간 절감(통화 녹취·계정 데이터 수동 검토 대체), 유지율 및 확장율 10% 향상 (Clay 게시 기준).

3.3 이벤트 전 주기 자동화

세 번째 레이어는 오프라인 이벤트 투자의 전 과정을 세 단계 자동화 워크플로로 완벽히 지원합니다.

사전 이벤트 선별: AI 에이전트가 주요 글로벌 콘퍼런스 플랫폼을 상시 스캔하며 행사 장소, 연사의 전문성, 세션 아젠다의 적합성, 예상 참가자 프로필 등을 머지의 내부 기준에 맞추어 정량 평가합니다. 각 행사의 예상 스폰서십 투자 가치를 산출하여 마케팅 팀에 추천함으로써, 무분별한 참가를 지양하고 검증된 핵심 이벤트에 예산을 집중할 수 있도록 뒷받침합니다.

현장 실시간 리드 캡처: 행사 부스 밖 복도나 라운지에서 우연히 대화를 나눈 잠재 고객의 이름과 소속 기업을 슬랙 채널에 간단히 입력하면, 클레이가 백그라운드에서 해당 인물의 상세 연락처와 회사 정보를 실시간 보강하여 세일즈포스 리드를 생성합니다. 동시에 이상적인 고객 프로필(ICP) 점수를 즉시 부여하고 최적의 후속 이메일 시퀀스로 자동 연결합니다. 명함조차 교환하지 못했던 현장 대화가 불과 수 분 만에 CRM 시스템에 온전히 기록됩니다.

미팅 전 브리핑: VIP 디너나 주요 고객 미팅이 예정된 경우, 참석자의 직무 이력, 소속 기업의 주요 제품군, 기존 머지 연동 여부, 그리고 가장 추천할 만한 머지 통합 솔루션을 일목요연하게 정리한 맞춤형 브리핑 문서를 담당자에게 사전에 자동 전달합니다.

확인된 사실: 이벤트 리드의 50% 이상이 이 시스템 없이는 후속 조치 없이 소실될 것이라는 Bourcier의 설명, 이벤트 파이프라인 대비 비용 비율(cost-to-pipeline ratio) ~2배에서 5배 방향으로 개선 중 (Clay 게시 기준).

확인된 사실 (전체): Gong·Salesforce·Clay 통합, 이벤트 파이프라인 비중 분기별 20~25%, RevOps·마케팅 합산 9인 팀이 영업·CS·마케팅을 동시 지원.

4. Impact

클레이 공식 고객 사례(게시 연도 미표기)에서 확인된 정량적 성과는 다음과 같습니다.

5. Insight

머지 사례의 핵심 본질은 개별 AI 도구의 단순 도입에 그치지 않고, 선행 레이어가 생성한 데이터가 후속 레이어를 지속적으로 강화하는 유기적 복합 데이터 시스템을 구축했다는 점입니다.

TAM 인텔리전스가 아웃바운드 영업의 적중도를 비약적으로 높입니다. 50,000개 계정의 자동 분류와 핵심 1,500개 계정의 실시간 모니터링이 결합되면, 영업 담당자는 “누구에게 연락할 것인가”를 고민하는 소모적 리서치에서 벗어나 “지금 이 고객에게 왜 이 제품이 필요한가”를 설득하는 고부가가치 세일즈에 온전히 집중할 수 있습니다. 다루는 제품이 수평적이고 활용 사례가 다양할수록 이러한 실시간 계정 지능화의 파급력은 극대화됩니다.

실시간 고객 건전성 신호가 사후 수습 위주의 CS를 선제적 케어로 전환합니다. 고객의 계약 이탈 징후를 연간 갱신 미팅 시점에 이르러서야 뒤늦게 알아차리는 것과, 수 주 전 상담 통화에서 발생한 미세한 불만을 즉각 감지하여 선제적으로 대응하는 것은 고객 유지율에서 결정적인 격차를 만듭니다. 통화 녹음과 자동화 워크플로를 실시간으로 결합한 인프라가 이러한 대응 시차를 획기적으로 줄였습니다.

오프라인 이벤트의 진정한 투자수익률(ROI)은 현장 접점 데이터화의 완결성에 달려 있습니다. 공식 부스 방문자 명단에만 의존하던 기존의 관행에서 벗어나, 현장에서 일어나는 모든 비공식적 대화까지 빠짐없이 CRM으로 연결할 때 비로소 마케팅 예산 투자의 타당성을 정량적으로 증명할 수 있습니다.

복제 조건: 이러한 파이프라인이 정상 작동하려면 세일즈포스와 공 등에 충분한 양질의 업무 데이터가 사전에 축적되어 있어야 하며, 부르시에 리드처럼 비즈니스 전략과 데이터 엔지니어링, AI 자동화 도구를 복합적으로 다룰 수 있는 전문 인재가 핵심 역할을 맡아야 합니다. 데이터 레이어 간의 유기적 결합 없이 단일 SaaS 도구만 도입해서는 이러한 연속적 시너지 효과를 창출하기 어렵습니다. 아울러 공개된 성과 지표(미팅 +15%, 유지율 +10% 등)는 클레이 공식 고객 사례에 기술된 수치이며, 제3자 기관의 독립적인 회계 감사를 거친 데이터는 아닙니다.

6. 원문에 없는 추정 (구현 가설)

6.1 1,500개 계정 주간 모니터링의 신호 분류

근거: 기사는 에이전트가 타깃 기업의 신제품 출시, 기능 업데이트, 파트너십 체결, 조직 개편을 지속적으로 스캔하며 일반적인 정적 데이터베이스에서 확인하기 어려운 정보를 실시간으로 추출한다고 설명했습니다.

이 주간 모니터링 에이전트가 실무에서 노이즈 없이 작동하려면 정교한 신호 가중치 평가 로직이 내장되어 있을 것으로 분석됩니다. 기업의 모든 뉴스나 공지가 영업 기회로 이어지는 것은 아니므로, 머지의 핵심 비즈니스(예: 신규 CRM/ATS 연동 카테고리 진출, AI 에이전트 도입 선언, 엔터프라이즈 API 전략 발표 등)와의 연관성에 따라 신호의 점수를 차등 부여하는 필터링 레이어가 결합되어 있을 가능성이 큽니다. 아울러 영업 담당자에게 즉시 전달되는 ‘추천 이메일 문구(suggested wording)’는 머지의 내부 제품 포지셔닝 가이드라인과 연동된 프롬프트 템플릿 또는 검색 증강 생성(RAG) 파이프라인을 거쳐 자동 생성될 개연성이 높습니다.

6.2 Gong 통화 분석의 에스컬레이션 로직

근거: 기사는 에이전트가 고객의 감정 변화를 감지하여 알림을 발송하면 CS 팀이 선제적으로 개입하고, 내부 지원 티켓과 제품 개선 요청이 자동으로 생성된다고 설명했습니다.

고객의 계약 이탈 위험 신호와 라이선스 확장 기회 신호를 단일 분석 파이프라인에서 정확하게 판별하려면 독립적인 트리거 임계치가 설정되어 있을 것으로 보입니다. 통화 텍스트 내에서 특정 핵심 키워드(경쟁사 솔루션 언급, 특정 API 연동 지연, 가격 정책 불만 등)의 출현 빈도와 부정적 감정 점수가 복합적으로 결합될 때 우선순위 알림을 생성하는 규칙 기반 평가 엔진이 작동할 가능성이 높습니다. 또한 지원 티켓 및 제품 요청 자동화의 경우, 클레이 워크플로가 지라(Jira)나 제품 관리 도구의 웹훅(Webhook) 엔드포인트를 호출하는 형태로 구현되어 있을 개연성이 큽니다. 이러한 알림 시스템은 거짓 양성(false positive) 비율이 높아지면 실무진에게 외면받기 쉬우므로, CSM의 실제 수용 피드백을 반영해 필터링 민감도를 지속 튜닝하는 피드백 루프를 운영하고 있을 것으로 추정됩니다.

6.3 이벤트 Slack-to-CRM 파이프라인의 무결성

근거: 기사는 직원이 현장에서 만난 잠재 고객의 이름과 소속 회사를 슬랙 채널에 입력하면 클레이가 자동으로 연락처를 보강하여 세일즈포스에 리드를 생성한다고 설명했습니다.

이 현장 워크플로의 성패는 불완전한 입력 데이터에 대한 보강 정확도에 달려 있습니다. 단순한 이름과 회사명만으로는 동명이인이나 지사 정보가 혼동되어 링크드인 프로필이나 공식 업무 이메일을 잘못 매핑할 위험이 항상 존재합니다. 부르시에 리드가 시스템이 없었다면 50%의 리드가 유실되었을 것이라고 표현한 배경에는, 자동화 시스템의 완벽한 100% 매칭을 전제하기보다는 실질적인 발굴률 제고에 방점이 찍혀 있습니다. 따라서 실제 운영 환경에서는 클레이가 연동된 복수의 데이터 제공자(예: Apollo, People Data Labs, LinkedIn 등)를 단계별로 조회하는 워터폴(waterfall) 보강 로직을 적용했을 가능성이 높으며, 신뢰도 임계치에 미달하는 모호한 데이터의 경우 영업 오퍼레이션 담당자에게 슬랙 봇을 통해 수동 확인을 요청하는 예외 처리 큐가 마련되어 있을 것으로 분석됩니다.

7. 출처

* Clay — How Merge books 15% more enterprise meetings by researching 1,500 key accounts weekly with Clayhttps://www.clay.com/customers/merge게시 연도: 미표기 (접근일: 2026-09-22)

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit parkdaesun.substack.com

1. 왜 이 사례인가

맞춤형 인쇄 이커머스 시장에서 빠른 배송 속도는 단순한 마케팅 문구가 아닌 핵심 운영 약속입니다. Jukebox는 스티커, 명함, 포스터, 굿즈 등을 당일 생산(same-day production)해 전 세계로 배송하는 글로벌 맞춤 인쇄 플랫폼입니다. “업계에서는 생산에만 2~6일이 걸리지만 우리는 당일 제작한다”는 포지셔닝으로 차별화해 왔습니다. 로레도 루친(Loredo Rucchin, CEO & Founder)의 설명처럼, 제품 제작 속도에 걸맞은 고객 지원 체계가 뒤따르지 못하면 전체 주문 경험은 순식간에 무너집니다.

사업이 성장하면서 지원 조직이 감당해야 할 압박도 급격히 커졌습니다. 지난 1년간 주문량이 80% 증가하면서 연간 고객 지원 대화량도 83% 급증했습니다. 인입되는 문의의 대부분은 주문 상세 내역 확인, 배송 일정 조회, 주문 취소 등 즉각적인 조치가 필요한 긴급 사안이었습니다. 특히 연말이나 대규모 프로모션 시즌에는 하룻밤 사이에 대기열이 수천 건까지 치솟았습니다. 반면 기존에 쓰던 레거시 Zendesk 환경은 당시 실시간 라이브 채팅을 지원하지 않았고, 브랜드 톤과도 동떨어져 고객에게 “지나치게 기계적이고 딱딱하다”는 인상을 주었습니다.

Jukebox는 Zendesk에서 Intercom 헬프데스크와 AI 에이전트 Fin으로 전면 전환했습니다. Fin 전문 파트너사인 ActiveLabs가 기존 Zendesk 헬프센터 문서를 이전하고 최적화했으며, 자체 백엔드 API를 연동해 주문, 배송, 생산 진행도, 실시간 가격 데이터에 Fin이 직접 접근할 수 있도록 인프라를 연결했습니다. 그 결과 Fin은 피크 시즌 판매 문의의 90%를 처리하고, 최대 65%의 종단 해결률을 달성했으며, 구매 전환율 40% 성장을 견인했습니다. 지원 인력을 한 명도 늘리지 않고도 대화량 83% 증가를 성공적으로 흡수한 것입니다. 인쇄만큼 빠른 지원을 AI로 구현해 브랜드 약속을 지켜낸 대표적인 이커머스 AX 사례입니다.

2. Problem

Jukebox의 구매 여정은 전 세계 고객을 대상으로 24시간 내내 이어집니다. 자정에 배송 예정 시각을 확인하려는 바이어부터 결제 직후 인쇄용 파일을 긴급히 교체해야 하는 고객, 연말 12월 31일 밤 11시 59분에 들어오는 주문 문의까지, 답변 지연은 곧장 장바구니 이탈과 매출 손실로 직결됩니다.

Jukebox가 겪던 핵심 병목은 크게 세 가지였습니다.

* 운영 속도와 지원 속도의 불일치: 제품은 당일 생산하면서도 고객 지원은 레거시 티켓 대기열에 묶여 있어 답변이 한참 지연되었습니다. 매달 접수되는 수천 건의 대화 중 상당수가 주문 변경, 제작 현황 확인, 긴급 취소 요청이었기에 느린 응대는 고객 불안을 가중시켰습니다.

* 피크 시즌의 부하 폭증: 주요 마케팅 캠페인이나 연말 세일(12월 31일 New Year’s Eve는 연중 가장 바쁜 날)에는 대기열이 하룻밤 사이 수천 건 단위로 폭증해 소수 정예(lean) 지원팀의 처리 역량을 순식간에 넘어섰습니다.

* 기존 CS 플랫폼의 한계: 레거시 Zendesk는 라이브 채팅 부재, 제한적인 커스터마이징, 경직된 인터페이스 탓에 브랜드 고유의 친근한 톤앤매너를 전달하지 못했고, 팀이 필요로 하는 방향으로 기민하게 확장되지 못했습니다.

맞춤 인쇄 상품은 규격, 해상도, 재단선, 파일 포맷 오류 하나가 곧장 생산 지연과 파손으로 이어집니다. 단순한 정적 FAQ 안내를 넘어, 개별 주문 상태, 복잡한 정책 예외(다품목 주문 중 부분 취소, 무료배송 환불 차액 안내 등)까지 능동적으로 처리할 수 있는 고도화된 지원 체계가 절실했습니다.

확인된 사실: 글로벌 맞춤 인쇄 이커머스, 당일 생산, 주문 +80%·지원 대화 +83%(연간), Zendesk→Intercom+Fin 전환, ActiveLabs 마이그레이션, 월 수천 건 긴급 문의, 피크 시 수천 건 대기열, Loredo Rucchin CEO 인터뷰.

3. Solution

Jukebox는 Fin을 단순한 FAQ 챗봇이 아니라 “빠르고 명확한 브랜드 구매 경험의 연장선”으로 설계했습니다.

3.1 지식 베이스와 제품 카탈로그 실시간 학습

Fin에 헬프센터 문서 전체와 전체 제품 카탈로그 데이터를 학습시켰습니다. 특히 Fin이 실시간 제품 상세 페이지의 최신 데이터에 접근할 수 있도록 구성하여 규격, 인쇄 해상도, 파일 설정 기준을 고객에게 정확하게 안내하도록 했습니다. 이를 통해 결제 전후 인쇄 파일의 오류를 미리 교정해 공정 단계에서의 제작 지연을 원천 차단했습니다.

3.2 자연어 지침(Guidance) 기반 정책과 브랜드 톤 정밀 제어

지원팀은 Fin Guidance 기능을 활용해 복잡한 운영 정책과 브랜드 음성을 자연어 규칙으로 세밀하게 규정했습니다. 원문에 공개된 주요 지침은 다음과 같습니다.

* 최근 주문 내역 조회를 요청받으면 “View Order” 형태의 클릭 가능한 바로가기 링크를 제공합니다.

* 다품목 주문에서 무료배송 조건을 적용받은 고객이 일부 품목만 취소(부분 취소)할 경우, 배송비 정산 기준에 따라 실제 환불액이 예상보다 적어질 수 있음을 사전에 명확히 설명합니다. 전체 주문 취소 시에는 배송비를 포함한 전액이 환불된다는 점을 함께 안내합니다.

* 고객이 보낸 문의 제목에 이미 주문 번호가 포함되어 있다면, 번호를 다시 묻지 않고 해당 주문 번호를 바탕으로 즉시 조회를 진행합니다.

* “not centered”(인쇄 치우침), “reprint”(재인쇄), “damaged”(파손) 등 품질 이상을 나타내는 핵심 키워드가 사진이나 파일 첨부와 함께 접수되면, AI 처리를 중단하고 즉시 전담 상담원에게 티켓을 라우팅합니다.

3.3 커스텀 백엔드 API 연동과 2분 즉시 취소 워크플로

Jukebox는 자체 백엔드 시스템을 API로 연결해 Fin이 고객의 주문 상세 정보, 실시간 배송 상태, 공장 생산 진행도, 맞춤 견적 및 가격 데이터에 실시간으로 접근할 수 있도록 했습니다. 로레도 루친 대표는 “주문 내역, 배송 예정일, 취소 관련 문의에 대해 Fin이 제공하는 답변의 디테일 수준이 워낙 정교해, 고객들이 실제 사람과 대화하고 있다고 느낄 정도”라고 평가했습니다.

주문 직후 취소 처리는 과거 고객 경험에서 가장 큰 마찰을 빚던 지점이었습니다. 결제 직후 아트워크 파일이 잘못 올라갔거나 옵션을 잘못 선택한 사실을 인지했을 때, 고객이 기다림 없이 Fin을 통해 즉시 주문을 취소할 수 있도록 백엔드 취소 로직을 연동했습니다. 그 결과 주문을 취소한 고객의 98%가 2분 이내에 설정을 올바르게 수정해 재구매하는 선순환을 만들어냈습니다. “취소 절차를 수월하게 열어둘수록 즉각적인 재주문으로 이어진다”는 이커머스 운영 철학을 시스템으로 구현한 것입니다.

3.4 ActiveLabs 협업을 통한 헬프데스크 전면 이전

Fin 전문 파트너사인 ActiveLabs와 협력하여 기존 Zendesk 헬프센터 문서를 Intercom 환경으로 신속하게 마이그레이션했습니다. 단순 문서 복사에 그치지 않고 Fin의 검색 인덱싱과 구매 고객의 질의 패턴 양쪽에 최적화되도록 지식 구조를 전면 재정비했습니다.

확인된 사실: 지식베이스+제품 카탈로그+라이브 페이지, NL 지침(주문 링크·부분 취소·긴급 에스컬레이션), API 연동(주문·배송·생산·가격), 즉시 취소(98% 2분 내 재구매), ActiveLabs 마이그레이션, Fin·Intercom·AI Insights 사용, Fin 도입 약 2년.

4. Impact

Intercom 공식 Fin 고객 사례에 공개된 정량적 성과는 다음과 같습니다. 원문 기준 게시일은 명시되지 않았으며, 확인일은 2026-09-22입니다.

정성적으로는 AI Insights 기능을 활용해 지속적으로 고객 불만을 유발하던 특정 제품을 데이터로 빠르게 식별해 카탈로그 라인업에서 선제적으로 제외하는 등, CS 대화 데이터를 제품 라인업 개선에 직접 활용하고 있습니다.

5. Insight

브랜드의 속도 약속은 고객 지원 속도로 완성됩니다. 당일 생산을 핵심 가치로 내세우는 브랜드라면, 바이어는 주문 확인, 배송 상태, 취소 처리 역시 그에 걸맞은 속도로 이루어지기를 기대합니다. Fin은 24시간 연중무휴 다국어 즉각 대응 체계를 갖춤으로써 제작 현장의 속도와 고객 지원의 반응 속도를 일치시켰습니다.

취소 경험의 마찰을 없애면 재구매 파이프라인이 열립니다. 이커머스에서 주문 취소를 무조건 방어해야 할 손실로 보아서는 안 됩니다. 잘못된 옵션을 선택한 고객에게 신속하고 매끄러운 취소 경험을 제공했을 때 98%가 2분 안에 다시 주문했다는 수치는, 마찰 없는 취소 동선이 곧장 구매 전환으로 이어짐을 보여주는 정량적 증거입니다.

피크 시즌 대응의 본질은 채용이 아닌 흡수력(Elastic Capacity)입니다. 연말 성수기 문의의 90%를 AI가 자동 해결하면서 기존 지원팀 인력이 무리한 초과 근무 없이 연휴를 보낼 수 있었다는 사실은, 주문이 급증하는 계절성 이커머스 비즈니스에서 AI 에이전트가 어떤 운영 레버리지를 발휘하는지 잘 보여줍니다.

CS 대화 데이터를 제품 의사결정으로 환류하는 체계가 작동합니다. 단순 문의 종결에 머무르지 않고 AI Insights 분석을 통해 반복적인 클레임을 일으키는 결함 SKU를 찾아내 라인업에서 제거함으로써, 지원 부서가 제품 품질 관리의 센서 역할을 겸하게 되었습니다.

복제 조건과 한계. 이 모델이 작동하려면 주문, 배송, 생산, 가격 조회가 실시간으로 가능한 백엔드 API 체계와 예외 정책을 세밀하게 통제할 수 있는 자연어 가이던스 역량, 헬프센터 지식을 AI 친화적으로 재구조화할 수 있는 마이그레이션 실행력이 갖춰져야 합니다. 또한 40%의 전환 성장과 65% 종단 해결률은 솔루션 벤더 사례에 기반한 자체 보고 수치이며, 엄밀한 A/B 대조군 실험 결과나 독립적인 제3자 감사 데이터는 원문에 명시되어 있지 않습니다. Fin 도입에 따른 구체적 운영 비용이나 인간 상담원 이관 시의 라우팅 정확도 세부 지표 또한 비공개 상태입니다.

한 줄 요약: 당일 생산 이커머스에서 AI 전환의 성패는 백엔드 연동을 통해 구매 직전의 기술 문의와 구매 직후의 취소·배송 조회를 생산 라인과 동일한 속도로 즉시 처리할 수 있는가에 달려 있습니다.

6. 원문에 없는 추정 (구현 가설)

6.1 주문·배송·취소 처리를 위한 Fin Custom Action과 세션 컨텍스트 파이프라인

근거: 원문은 Fin을 자체 커스텀 백엔드 API에 연결해 주문 상세 내역, 배송 상태, 생산 진행도, 가격 조회, 취소 처리를 실시간으로 자동화했다고 기술합니다.

구매자가 자사몰 로그인 세션, 주문 번호, 인증 이메일을 통해 식별되면, Fin은 단순 문서 검색 단계를 건너뛰고 내부 시스템과 통신하는 커스텀 액션(Custom Action) 파이프라인을 실행했을 것입니다. 구체적으로는 get_order_status, request_cancellation, list_recent_orders 같은 엔드포인트를 호출하는 구조를 갖추었을 개연성이 큽니다. 다품목 주문 중 부분 취소에 따른 무료배송 차액 정산 로직은 API가 반환한 정량 데이터(기존 적용된 배송비, 취소 대상 품목 금액, 재계산된 환불 가능액)를 사전에 설정된 Fin Guidance 프롬프트 템플릿과 실시간으로 결합해 고객에게 자연스러운 문장으로 안내했을 것입니다. 또한 “View Order” 링크는 백엔드 주문 시스템이 생성한 주문별 딥링크(deep link) URL을 동적으로 수신받아 대화 카드 내 클릭 가능한 버튼 컴포넌트로 렌더링하는 방식을 취했을 가능성이 높습니다. API 응답 지연이나 백엔드 시스템 예외가 발생할 경우를 대비해, 이전 대화 맥락과 입력된 주문 식별자를 온전히 유지한 채 상담원 대기열로 즉시 이관하는 인간 개입(HITL) 안전망을 갖추었을 것으로 추정됩니다.

6.2 불량 키워드 및 미디어 첨부 감지 기반의 즉시 라우팅 게이트

근거: 원문은 “not centered”, “reprint”, “damaged”와 같은 특정 단어가 파일 첨부와 함께 접수될 경우 Fin 응답을 즉시 중단하고 사람 상담원에게 연결하도록 학습시켰다고 밝힙니다.

고객 지원 인입 파이프라인의 최전단에 텍스트 토큰 필터와 첨부 파일 감지 로직이 결합된 라우팅 규칙이 작동했을 것입니다. 고객 메시지에서 사전에 지정된 불량 관련 키워드가 감지되고 동시에 이미지나 PDF 등 멀티미디어 파일(MIME 타입)이 확인되면, LLM의 추가 답변 생성을 차단하고 즉각 인터콤 인박스의 긴급 티켓으로 전환하는 트리거가 설정되었을 가능성이 큽니다. 재인쇄나 배송 파손 클레임은 인쇄 공장 현장의 재작업 승인과 물리적 생산 스케줄 조정이 수반되는 사안이므로, 일반적인 단순 주문 조회 큐와는 완전히 분리된 전담 “품질 보증 및 재작업(QA/Rework)” 큐로 분기하여 숙련된 현장 담당자에게 배정했을 것으로 추정됩니다.

6.3 성수기 판매 문의 90% 처리를 위한 퍼스트 터치 큐 제어 전략

근거: 원문은 연말 성수기 및 대규모 세일 기간 동안 Fin이 전체 판매 문의의 90%를 처리했으며, 12월 31일 밤 11시 59분 문의까지 원활하게 감당했다고 서술합니다.

주문이 폭증하는 피크 시즌에는 단순 FAQ와 표준 주문 조회 트래픽이 평시 대비 압도적으로 늘어나므로, 시스템 차원에서 Fin 우선 응대(First-touch deflection) 정책을 일시적으로 한층 강화했을 가능성이 높습니다. 사람 상담원 연결 버튼의 노출 조건을 고위험 결제 오류나 품질 불량 건으로 좁히고, 표준적인 규격 안내 및 배송일 조회는 Fin이 1차 종결하도록 유도하는 동적 라우팅 정책을 적용했을 것으로 보입니다. 또한 파트너사 ActiveLabs가 헬프센터 구조를 Fin의 검색 알고리즘에 맞춰 사전 최적화해 두었으므로, 대형 프로모션 시작 전 프로모션 할인 규칙, 마감 시한, 명절 배송 마감 일정 등을 자연어 지침과 카탈로그 메타데이터에 미리 동기화해 둠으로써 트래픽 폭증기에도 오답 없이 문의를 흡수했을 것으로 추정됩니다.

7. 출처

* Intercom Fin Customer Stories — How Jukebox delivers instant buyer support at scale with Finhttps://fin.ai/customers/jukebox게시일: unknown (확인일: 2026-09-22)(Loredo Rucchin CEO & Founder; 50% 개입, 최대 65% 해결, 40% 전환 성장, 주문 +80%/대화 +83%, 90% 피크 판매 문의 처리, 98% 취소 후 2분 내 재구매)

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit parkdaesun.substack.com

1. 왜 이 사례인가

GTM(Go-to-Market) 개발 플랫폼 Clay는 이상적 고객 프로필(ICP)을 발굴하고 데이터를 보강(enrichment)하여 정밀한 성장 캠페인을 집행할 수 있도록 돕는 B2B SaaS 기업입니다. 고객이 데이터 기반 영업 전략을 성공적으로 안착시키도록 돕는 고객 지원은 Clay의 성장과 제품 경험을 견인하는 핵심 동력이었습니다.

초기 Clay는 2만 명 규모의 Slack 커뮤니티를 중심 창구로 삼아 고객 지원을 운영했습니다. 활발한 커뮤니티는 브랜드의 핵심 자산이었으나, 별도의 자동화 장치 없이 수동으로 티켓을 처리하다 보니 늘어나는 문의량을 체계적으로 관리하고 우선순위를 선별하기 어려웠습니다. 고객 입장에서도 사소한 문의 하나를 해결하기 위해 매번 Slack 채널을 찾아와야 하는 사용 마찰이 컸습니다. 더욱이 지원팀 인원은 단 3명에 불과해 상담원 한 명이 매주 200건 이상의 티켓을 감당하고 있었습니다. 고객 수가 가파르게 증가하는 상황에서 팀 규모를 2배로 늘리지 않고는 급증하는 문의를 따라잡을 수 없다는 현실적 위기감이 팽배했습니다.

이에 Clay는 Intercom의 AI 에이전트 Fin을 도입하고, ‘인앱 채팅 → Slack(Channeled 연동) → 이메일’로 이어지는 단계적 확장을 추진했습니다. 현재 Fin은 전 채널 상담 대화의 90%에 개입하여 이 중 최대 50%(평균 45~50%)를 사람 개입 없이 종단 완결(End-to-End)하고 있습니다. 매달 인입되는 약 7,000건의 티켓 중 절반 가까이를 Fin이 도맡아 해결하면서, 사람 상담 인력은 복잡하고 전략적인 기술 문의에 온전히 집중할 수 있게 되었습니다.

2. Problem

Fin을 도입하기 전, Clay 지원팀이 직면했던 세 가지 핵심 병목은 다음과 같았습니다:

* 다채널 확장과 커뮤니티 정체성의 상충: 2만 명 규모의 Slack 커뮤니티 지원은 고객 소통에 탁월했지만, 정교한 자동화 체계가 없어 급증하는 문의량을 체계적으로 분류하고 우선순위를 매기기 어려웠습니다. 또한 모든 문의가 Slack 채널을 거쳐야만 해결되는 구조 탓에 다른 접점을 원하는 고객에게 불필요한 번거로움을 주었습니다.

* 지원 인력의 번아웃과 과부하: 고객 수와 지원 요청량이 빠르게 늘어나는 반면 자동화가 전무해 팀이 만성적인 과부하 상태에 빠졌습니다. 고객을 돕는 일 자체는 보람찼지만, 끝없이 반복되는 단순 티켓 처리와 대기열 관리 업무로 인해 팀원들의 피로가 극에 달했습니다.

* 응답 지연과 선입선출의 한계: 단순 선입선출(FIFO) 대기열 방식에서는 AI가 즉시 답변할 수 있는 간단한 문의조차 답변을 받기까지 4~6시간을 대기해야 했습니다. 즉각 해결 가능한 손쉬운 질문(low-hanging fruit)을 사전에 걸러내 신속하게 처리할 방법이 없었던 것입니다.

확인된 사실: 2만 명 규모 Slack 커뮤니티, 3인 지원팀 기준 인당 주 200건 이상(200+) 티켓 처리, 수동 커뮤니티 지원 체계, 응답 대기 시간 4~6시간, AI 도입 없이 팀 규모 2배 증원 필요 인식(Jess Bergson), FIFO 대기열의 한계.

3. Solution

3.1 도구 선택: 기술 + 팀 + 통제

Clay는 뛰어난 AI 기술력뿐 아니라 도입 전 과정을 든든하게 뒷받침해 줄 파트너 지원을 원했고, Intercom의 Fin에서 두 조건을 모두 확인했습니다. 특히 의사결정에서 다음 두 가지가 결정적이었습니다.

* 팀의 자발적 수용(Buy-in): 전체 지원팀이 Fin 도입 초기 테스트에 직접 참여했습니다. AI가 상담원을 대체하는 위협이 아니라 일하는 환경을 개선하는 기회임을 팀원들이 직접 체감하면서 막연한 두려움을 해소했습니다.

* 고객 경험에 대한 통제력: Fin의 규칙 설정과 워크플로가 투명하게 공개되어 있어, 최종적으로 고객에게 전달되는 상담 경험을 지원팀이 직접 제어할 수 있었습니다.

조지 딜데이(George Dilthey, Head of Support)는 1단계(tier 1) 기본 문의에 그치지 않고 심화 기술 문의인 tier 2·3 영역까지 Fin의 답변 규칙을 설정했으며, 환불 등 내부 백엔드 시스템과도 직접 연결했다고 설명합니다. 과거에는 자동화하기 어려웠던 영역까지 운영 범위가 확장된 것입니다.

3.2 단계적 롤아웃: 인앱 → Slack → 이메일

Clay의 접근법은 작게 시작해 점진적으로 확장하는 방식이었습니다. 먼저 상대적으로 통제가 용이한 인앱 채팅에 Fin을 우선 배포해 성과를 검증한 뒤, Slack과 이메일 채널로 순차 확장했습니다.

Slack 지원 환경은 서드파티 통합 애플리케이션인 Channeled를 활용해 Fin과 연결했습니다. 제스 버그슨(Jess Bergson, Head of CX)은 수많은 고객이 지켜보는 공개 Slack 커뮤니티 특성상 단 한 번의 오류도 용납되지 않아 초기 배포가 무척 두려웠으나, 실제 운영 결과는 예상보다 훨씬 매끄러웠다고 회고했습니다.

3.3 운영 변화

Fin 도입 이후 지원팀의 운영 방식과 사내 역할은 다음과 같이 재편되었습니다:

* 고객은 문의 접수 후 평균 10초 이내에 정확한 답변을 받습니다.

* 지원팀은 단순 응대에서 벗어나 가장 복잡하고 전략적인 기술 문의에 집중합니다.

* Fin 상담 대화에서 반복되는 질문이나 콘텐츠 공백(gap)을 교육(Education) 및 콘텐츠 마케팅 팀과 공유해 사전 안내 문서를 선제적으로 보강합니다.

* 고객 대화 속에서 파악된 제품 기능 요청과 개선 사항을 제품(Product) 팀에 직접 전달하는 피드백 루프를 가동합니다.

* 조지 딜데이는 고객지원의 핵심 지표였던 ‘원터치 티켓(한 번의 응답으로 종결되는 티켓)’에 대한 시각이 바뀌었다고 강조합니다. 한 번의 답변으로 닫히는 단순 문의라면 사람이 시간을 쓸 것이 아니라 애초에 AI가 도맡아야 할 영역이라는 인식의 전환입니다.

확인된 사실: 전체 팀 테스트 참여 및 수용(buy-in), tier 2/3 및 환불 시스템 연동, ‘인앱 → Slack(Channeled) → 이메일’ 단계별 롤아웃, 전 채널 90% 개입 및 45~50% 종단 해결(인앱 초기 20%), 월간 티켓 약 7,000건(~7k), 10초 미만(<10초) 응답 속도, 콘텐츠·제품 피드백 루프 구축.

4. Impact

정성적으로도 지원팀의 역할과 조직 문화가 크게 달라졌습니다. 지원팀은 단순 티켓 처리자에서 고난도 문제 해결사로 진화했으며, 고객은 대기 시간 없는 즉각적인 안내 덕분에 Clay 플랫폼에 훨씬 빠르게 안착하고 있습니다. 조지 딜데이는 AI 도입의 궁극적인 목표가 사람을 대체하는 것이 아니라, 구성원을 지치게 만드는 지루한 반복 업무를 대체하는 데 있었다고 강조합니다.

확인된 사실: 위 표 수치. 큐 ID 016(Intercom이 Clay를 GTM outbound에 사용)과는 별개 사례 — 본건은 Clay가 Fin 고객인 지원 AX.

5. Insight

커뮤니티 우선 원칙과 자동화는 양립할 수 있습니다. 2만 명 규모의 공개 Slack 커뮤니티라는 브랜드 핵심 자산을 유지하면서도, Fin을 통해 응답 지연을 해소하고 급증하는 문의량을 안정적으로 흡수했습니다. 기존 커뮤니티를 축소하거나 폐쇄하지 않고도 옴니채널로 고객 접점을 확장할 수 있음을 보여준 사례입니다.

공개 채널 배포의 전제 조건은 통제력과 투명성입니다. 워크플로와 응답 규칙을 세밀하게 제어할 수 있는 투명성이 뒷받침되지 않는다면, 수많은 사용자가 지켜보는 공개 Slack 채널에 AI 에이전트를 전면 배치하기 어렵습니다. 더욱이 Tier 2·3 심화 기술 문의나 환불 시스템 연동까지 맡기려면 내부 시스템 접근에 대한 정교한 통제가 필수적입니다.

단계적 롤아웃이 공개 채널의 브랜드 리스크를 줄입니다. 상대적으로 리스크 관리가 용이한 인앱 채팅 환경에서 먼저 20%의 해결률을 검증한 뒤, Slack과 이메일로 확장하며 해결률을 45~50%까지 끌어올렸습니다. 이러한 점진적 확장이 공개 커뮤니티 환경에서의 배포 실패 부담을 극소화한 핵심 전략이었습니다.

운영 지표의 재정의가 필요합니다. 지원팀의 ‘원터치 티켓’ 비율을 무조건 높이는 것이 미덕이 아니며, 한 번의 답변으로 해결되는 단순 문의는 애초에 사람이 아닌 AI가 전담해야 할 영역이라는 실무적 인식 전환이 필요합니다.

복제 조건과 한계. 환불 등 핵심 백엔드와 연동할 수 있는 내부 API 환경, Fin 및 Channeled 서드파티 도구의 정교한 설정 역량, 공개 커뮤니티에서 발생할 수 있는 잠재적 브랜드 리스크에 대한 조직적 수용이 전제되어야 합니다. 한편 Fin의 고객 만족도(CSAT)는 현재 모니터링 단계이며, 장기 이탈률이나 순추천지수(NPS)에 미친 영향은 원문에 공개되지 않았습니다. 또한 벤더가 작성한 고객 사례의 특성상 Fin 운영 비용이나 상담원 에스컬레이션의 정확도에 대한 세부 수치는 다루어지지 않았습니다.

한 줄로: 커뮤니티 중심 지원을 확장하려면 AI를 단순히 덧대기보다, 통제 가능한 AI 워크플로를 인앱에서 먼저 철저히 검증한 후 공개 커뮤니티로 단계적 확장하는 접근이 안전합니다.

6. 원문에 없는 추정 (구현 가설)

6.1 tier 2/3·환불 연동을 위한 Fin Custom Action 파이프라인

근거: 원문은 Fin을 tier 2·3 질문까지 설정하고 환불 등 내부 시스템과 연결했다고 기술합니다.

환불 요청이 인입되면 Fin은 대화 흐름 속에서 주문 번호나 구독 ID를 먼저 식별한 뒤, 인증된 사용자 세션 컨텍스트를 바탕으로 내부 결제(billing) API(예: create_refund_request 또는 check_refund_eligibility)를 호출하는 커스텀 액션(Custom Action) 파이프라인을 거쳤을 것입니다. Tier 2·3 문의는 지식베이스 검색만으로는 답하기 어려운 외부 도구 연동, 계정 권한, 데이터 처리 상태 관련 이슈가 다수를 차지하므로, Fin의 워크플로 빌더 내에서 ‘내부 시스템 실시간 조회 필요’ 조건 분기와 문의 난이도별 에스컬레이션 규칙을 차등 설정했을 가능성이 높습니다. API 호출이 실패하거나 환불 정책 기준을 충족하지 못하는 예외 상황에서는 이전 대화 맥락이 온전히 첨부된 티켓 형태로 사람 상담원에게 즉각 이관하는 인간 개입(HITL, Human-in-the-Loop) 게이트가 포함되었을 것으로 추정됩니다.

6.2 Channeled 기반 Slack 공개 커뮤니티 Fin 라우팅

근거: 원문은 인앱 성과 확인 후 Channeled 서드파티 앱으로 Slack에 Fin을 연결했고, 공개 커뮤니티라 오류 여지가 없어 무서웠다고 회고합니다.

서드파티 통합 앱인 Channeled는 공개 Slack 채널의 개별 스레드를 Fin의 대화 세션에 실시간 매핑하는 미들웨어 역할을 수행했을 것입니다. 불특정 다수가 열람하는 공개 채널의 메시지가 Fin으로 전달될 때, 민감 정보 자동 마스킹, 응답 초안 사전 검토, 특정 위험 키워드 감지 시 사람 상담원으로의 즉시 에스컬레이션 규칙을 적용했을 가능성이 큽니다. 또한 인앱 채팅에서 이미 검증을 마친 Fin의 기술 지식 및 워크플로 설정을 Slack 채널 프로필로 동기화하되, 공개 채널 특유의 오답 리스크를 방어하기 위해 초기에는 Fin 개입률을 채널별로 낮게 유지하고 점진적으로 끌어올리는 단계적 게이트를 두었을 가능성이 있습니다. 이후 달성된 전 채널 90% 개입률은 인앱, Slack, 이메일이 동일한 Fin 인스턴스 정책을 공유하면서도 인입 채널별 라우팅과 응답 방식만 분기하는 구조로 확장되었을 것으로 추정됩니다.

7. 출처

* Intercom Fin Customer Stories — Transparency and trust: Why Clay chose Finhttps://fin.ai/customers/clay게시일: unknown (확인일: 2026-09-22)(Jess Bergson Head of CX, George Dilthey Head of Support; 90% 개입, 45~50% 해결, ~7k tickets/mo, 20k Slack community, Channeled Slack 연동)

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit parkdaesun.substack.com

1. 왜 이 사례인가

AI 코딩 에이전트를 다룬 수많은 글은 대개 “엔지니어 10명분의 생산성”을 내세우는 과장된 데모나 제로투원(0 to 1) 시연에 주목합니다. 글로벌 결제 기업 체크아웃닷컴(Checkout.com)은 정반대의 길을 선택했습니다. 에이전트에게 무제한의 자율성을 부여하는 대신, 기존 개발 프로세스 안에서 엄격하게 범위가 제한된 작업(narrow contract)에 배치하는 것이야말로 실질적인 개발 속도를 끌어올리는 핵심이라고 설명합니다.

사내 AI 코딩 에이전트인 Agent HAL은 단순한 대화창 인터페이스에 머무르지 않고 실제 개발 파이프라인에 깊숙이 통합되어 있습니다. 2026년 6월 17일 기준, 체크아웃닷컴에서 생성되는 전체 PR의 18%를 HAL이 직접 만들어냅니다. 사람의 개입 없이 거대한 기능을 한 번에 배포한 것이 아니라, 요구사항과 범위가 명확한 작은 작업 단위들을 꾸준히 처리해 PR로 전환해 낸 결과입니다.

금융 거래를 다루는 결제 기업에서 자동화에 따른 방심과 안일함(automation complacency)은 치명적인 위험 요소입니다. 따라서 HAL은 스스로 모든 것을 결정하는 완전 자율형 에이전트가 아니라 철저히 통제 가능한 에이전트로 설계되었습니다. 최종 승인은 반드시 사람이 내리며, 기존과 동일한 CI 및 보안 검증 게이트를 거치고, 자동 머지는 원천 금지하는 안전장치가 시스템 구조에 그대로 보존되어 있습니다.

2. Problem

체크아웃닷컴이 HAL을 도입하기 전 마주했던 병목은 단순한 “코드 작성 속도”의 문제가 아니라, 개발 프로세스 곳곳에 숨어 있던 마찰이었습니다.

* 백로그의 모호성: 실제 코드를 작성하기 전 단계에서 가장 값비싼 엔지니어링 시간이 낭비되었습니다. 작업 티켓의 내용이 모호하면 요구사항을 파악하고 조율하느라 일주일씩 허비하기 일쑤였습니다.

* PR 부패(branch rot): 사람이든 에이전트든 PR을 생성해 두어도, 메인 브랜치(main)에 새로운 변경 사항이 지속적으로 반영되면 리베이스 충돌이나 CI 테스트 실패가 누적됩니다. 결국 PR이 제때 처리되지 못하고 방치되어, 정작 엔지니어가 검토하려 할 때는 즉시 머지할 수 없는 상태로 굳어지곤 했습니다.

* 잦은 맥락 전환(context switching): 금요일 오후에 불시에 접수되는 보안 취약점 경고(advisory)처럼 업무 흐름을 끊는 돌발 작업들이 엔지니어의 몰입 시간을 파편화했습니다. 기존에는 알림 내용을 일일이 확인하고 서비스에 실제로 영향을 미치는지 판단하는 데만 매번 반나절 이상을 소모해야 했습니다.

* 소규모 기능의 백로그 적체: 사내 대시보드에 검색 필터를 추가하는 것과 같은 작업은 범위가 작고 명확하지만, 대규모 프로젝트나 시급한 현안에 밀려 몇 주씩 백로그에 머물렀습니다.

확인된 사실: 속도 개선의 핵심은 화려한 제로투원 데모가 아니라 범위가 명확한 작업의 반복 수행에 있다는 인식, 백로그의 모호성·PR 부패·업무 흐름을 끊는 유지보수·소규모 기능의 백로그 적체가 주요 병목이었다는 점, 결제 서비스 특성상 무검토 승인이나 자동 머지는 원천적으로 허용되지 않는다는 점.

3. Solution

3.1 프로세스에 내장(Embedded), 덧붙이지 않음

HAL은 엔지니어링 팀이 이미 일상적으로 사용하는 도구 체계에 직접 연결됩니다. 작업은 라벨이 지정된 티켓, 예약된 정기 작업(scheduled job), HAL이 생성한 PR의 후속 작업처럼 명확히 정의된 진입 게이트를 통해 인입되며, 그 결과물은 항상 사람이 검토할 수 있는 PR 형태로 산출됩니다.

HAL은 단순히 PR을 열어두고 작업을 끝내지 않습니다. PR 생성 이후의 전체 생명주기를 스스로 책임지고 관리합니다:

* 자신이 수정한 코드 변경 사항을 스스로 사전 검토

* CI 파이프라인 실패 시 원인을 분석하고 수정 커밋 반영

* 메인 브랜치(main)에 새 커밋이 머지되면 지속적으로 최신 상태 유지(리베이스)

따라서 담당 엔지니어가 코드를 검토하는 시점에는 PR이 충돌 없이 최신 상태를 유지하며 즉시 머지 가능한 상태로 준비되어 있습니다.

3.2 백로그 선행: 준비도 점수화

정기 예약 작업으로 유입되는 각 작업 티켓의 준비도(readiness)를 자동으로 점수화하여 티켓 본문에 기록합니다. 요구사항이 지나치게 부실하거나 맥락이 부족한 티켓(thin ticket)의 경우 섣불리 구현에 착수하지 않고 구체적인 세부 내용을 보완해 달라고 요청합니다. 에이전트가 필요한 질문을 능동적으로 던지는 과정에서 백로그 자체가 자연스럽게 정제됩니다.

3.3 소규모 신규 기능, 유지보수만이 아님

실제 프로덕트 엔지니어링 작업의 상당수는 범위가 작고 명확합니다. 대표적인 사례가 사내 대시보드에 새로운 필터를 추가하는 작업이었습니다. 이 작업은 몇 주 동안 백로그에 머물러 있었지만, HAL이 티켓을 전달받은 당일 오후 곧바로 PR을 생성했고 같은 날 동료 검토와 머지까지 완료되었습니다. 새로운 API 엔드포인트 구현이나 프론트엔드 UI 변경 등에서도 동일한 패턴이 적용됩니다.

PR을 올리기 전에는 별도의 리뷰 페르소나가 구현 내용을 사전 검증합니다. 코드를 작성한 페르소나와 완전히 분리된 맥락(컨텍스트)과 시스템 프롬프트를 부여함으로써, 동일한 세션에서 요구 스펙을 연속으로 오독하는 치명적인 실수를 방지합니다. 스펙 충족 여부가 불충분하다고 판단되면 무엇이 누락되었는지를 명확히 보고하고 작업을 중단하며, 최종 승인 권한은 철저히 사람 엔지니어에게 남겨둡니다.

3.4 유지보수: 금요일 오후 취약점 알림

서비스 운영 중 보안 취약점 알림이 접수되면 — 실제 위협과 단순한 노이즈가 뒤섞여 있어 모두 선별(트리아지) 작업이 필요합니다 — HAL이 티켓을 할당받아 각 알림 내용을 분석합니다. 이어 필요한 라이브러리 의존성을 업데이트하거나 특정 버전에 고정(pin)하고, 전체 테스트 스위트를 실행하여 검증한 뒤 해당 보안 권고를 해제하는 PR을 생성합니다. 검토 담당 엔지니어는 의존성 파일 외에 다른 코드가 변경되지 않았는지 확인하고 테스트 통과 로그를 점검한 뒤 머지 버튼을 누르기만 하면 됩니다. 여러 리포지토리에서도 정기 예약 작업을 통해 동일한 자동화 흐름이 병렬로 실행됩니다.

3.5 통제, 자율이 아님

HAL의 모든 실행 과정은 명확히 정의된 특정 지시 사항으로 추적 및 감사가 가능합니다. 엔지니어는 진행 중인 작업을 언제든 즉각 중단할 수 있으며, 사람이 남긴 피드백은 다음 실행 단계에 직접 반영됩니다. 아울러 요구사항을 정의한 담당자가 구현 결과까지 임의로 승인할 수 없도록 하는 상호 견제 구조가 안전하게 유지됩니다.

HAL이 생성한 PR 역시 일반 엔지니어의 PR과 완전히 동일한 품질 게이트를 거칩니다. 단위 및 통합 테스트, 보안 취약점 스캔, 공식 지정된 승인자의 필수 리뷰를 모두 통과해야 하며, 자동 머지는 일체 허용되지 않습니다. 시스템의 신뢰는 에이전트 모델 자체의 막연한 능력에서 오는 것이 아니라, 이를 철저히 감시하고 검증하는 프로세스에서 비롯됩니다.

확인된 사실: 전체 PR의 18% 생성(2026-06-17 기준), 이벤트 기반 작업 인입(라벨 티켓·예약 작업·소유 PR 후속 작업), PR 자체 리뷰·CI 오류 수정·주기적 리베이스 수행, 백로그 준비도 점수화 및 불충분한 티켓 거부 메커니즘, 구현과 리뷰 페르소나의 분리, 대시보드 필터 당일 PR 생성 및 머지 사례, 취약점 알림 자동 처리, 일반 작업과 동일한 CI/보안 게이트 적용 및 자동 머지 원천 금지.

4. Impact

정성적인 관점에서, 엔지니어들은 맥락 파악 부담은 적지만 번거로운 마찰이 컸던 단순 반복 작업들을 백그라운드 에이전트에 위임하고 본연의 핵심 업무 몰입도를 회복했습니다. HAL은 당초 ‘몇 가지 지루한 반복 작업을 덜어보자’는 소규모 실험으로 출발했으나, 현재는 체크아웃닷컴 소프트웨어 배포 체계의 핵심 축으로 확고히 자리 잡았습니다.

확인된 사실: 18% PR, 당일 머지 사례, 취약점 처리 시간 축소, 인지 부하 감소 프레이밍. HAL PR의 결함률·롤백 빈도·인프라 비용은 미공개.

5. Insight

자율이 아니라 명확히 한정된 계약이 실질적인 속도를 만듭니다. 체크아웃닷컴은 에이전트에게 무작정 자율성을 위임하지 않고, 이미 검증된 개발 게이트 안에서 작고 범위가 명확한 작업에만 엄격하게 한정했습니다. 18%라는 생산성 수치는 화려한 대형 기능 하나를 배포해서 얻은 결과가 아니라, 잘 정의된 소규모 PR이 꾸준히 축적되어 만들어진 성과입니다.

코드 작성보다 백로그 정제가 먼저입니다. 코딩에 착수하기 전 티켓의 준비도를 먼저 평가하고 내용이 부실한 티켓을 걸러냄으로써, 에이전트가 불완전한 스펙을 근거로 ‘그럴듯하지만 틀린(confidently wrong)’ PR을 양산하는 비효율과 낭비를 사전에 차단합니다.

구현과 리뷰 페르소나를 철저히 분리해야 합니다. 동일한 맥락 안에서 요구 스펙을 읽고 코드를 작성한 뒤 자체 채점까지 진행하면, 잘못된 해석과 논리 오류가 두 번 연속 굳어지기 마련입니다. 새로운 컨텍스트를 부여받은 독립적인 리뷰 페르소나와 사람 엔지니어의 최종 판단을 단계적으로 분리 배치해 검증의 실효성을 극대화했습니다.

PR 생성 이후의 생명주기 관리가 성패를 가릅니다. PR을 생성한 뒤 그대로 방치하면 메인 브랜치의 빠른 변화에 밀려 브랜치 부패(branch rot)가 발생하고, 엔지니어가 검토할 시점에는 이미 머지할 수 없는 폐기물이 되기 쉽습니다. 실패한 CI 파이프라인의 수정과 지속적인 리베이스까지 에이전트가 완결해 주어야만 엔지니어의 검토 시간이 낭비되지 않습니다.

적용 조건과 한계. 세밀한 라벨링과 정기 예약 실행 체계, 철저한 CI 게이트, 결제 플랫폼에 걸맞은 엄격한 보안 검사 및 승인 워크플로, 그리고 높은 티켓 작성 문화가 선행되어야 합니다. 한편 생성된 18%의 PR 중 실제 머지까지 도달한 최종 비율이나 배포 후 결함률, 에이전트 운영 인프라 비용 등은 공개되지 않은 한계가 있습니다.

한 줄 요약: 에이전트 엔지니어링의 본질은 모든 것을 알아서 처리하는 만능 자율 AI의 환상이 아니라, 기존 가드레일 안에서 손이 많이 가는 정형화된 작업을 묵묵히 처리하여 사람이 즉시 검토할 수 있는 양질의 PR로 준비해 두는 든든한 조력자를 구축하는 데 있습니다.

6. 원문에 없는 추정 (구현 가설)

6.1 이벤트 게이트와 PR 생명주기 오케스트레이터

근거: 원문은 HAL이 라벨된 티켓·예약 작업·소유 PR 활동으로 작업을 받고, PR을 열고 떠나지 않으며 자체 리뷰·CI 수정·main 이동 시 리베이스를 수행한다고 기술합니다.

특정 티켓 라벨(예: hal-ready)이나 정기 cron 스케줄러가 HAL의 실행을 트리거하면, 에이전트는 티켓 설명과 관련 코드 맥락을 분석한 뒤 작업 브랜치를 분기하여 구현에 착수했을 것입니다. PR이 생성된 후에는 웹훅(webhook)을 통해 CI 파이프라인의 실행 결과를 전달받고, 빌드나 테스트가 실패하면 동일 브랜치에 수정 커밋을 스스로 추가하는 오류 자동 복구 루프가 동작했을 것으로 보입니다. 메인 브랜치(main)에 새로운 커밋이 머지될 때마다 HAL은 자신이 생성한 PR에 대해 자동 리베이스를 시도하고, 만약 코드 충돌이 발생하면 작업을 중단하거나 담당 엔지니어에게 알림을 에스컬레이션했을 가능성이 높습니다. 최종적으로 사람 엔지니어에게 리뷰 요청 알림이 도달하는 시점에는 모든 CI 테스트가 정상 통과(green)하고, 최신 메인 브랜치와의 리베이스가 완료되었으며, 구현 에이전트와 분리된 리뷰 페르소나의 사전 검사까지 무사히 마친 상태였을 것입니다.

6.2 백로그 준비도 점수와 얇은 티켓 거부 루프

근거: 원문은 HAL이 예약 실행으로 각 티켓의 준비도를 점수화해 티켓에 다시 쓰고, 너무 얇으면 상세를 요청하며 작업하지 않는다고 밝힙니다.

티켓 준비도 점수는 설명 본문의 구체성, 인수 조건(Acceptance Criteria) 명시 여부, 관련 코드 파일 및 API 명세 참조의 충실도, 모호한 자연어 표현의 포함 비율 등을 LLM이 다각도로 평가하여 0~100점 척도로 산출하는 방식이었을 것입니다. 계산된 점수가 사전에 설정된 기준 임계값에 미치지 못하면, HAL은 Jira(또는 사내 이슈 트래커) 티켓에 자동으로 코멘트를 남겨 ‘구현에 필요한 구체적인 API 엔드포인트나 화면 구성, 검증용 테스트 시나리오’를 질문하고 해당 작업의 실행을 건너뛰었을 것으로 추정됩니다. 이러한 피드백 루프가 반복되면서 사내 백로그의 작성 품질이 전반적으로 상향 평준화되었고, 대시보드 필터 추가와 같이 명확하게 정제된 소규모 티켓들만 HAL의 실행 큐에 진입함으로써 당일 PR 생성과 머지가 가능했을 것입니다.

6.3 취약점 알림 처리의 의존성 전용 diff 가드

근거: 원문은 HAL이 취약점 알림 티켓을 받아 의존성을 업데이트·핀하고 테스트 후 PR을 열며, 리뷰 엔지니어는 변경이 의존성만인지 확인한다고 합니다.

HAL의 실행 프로필은 dependencies-only와 같은 엄격한 모드로 제한되어, 패키지 파일 외에 일반 애플리케이션 비즈니스 로직이 수정되는 것을 원천 차단하는 diff 검증 절차가 PR 생성 직후 자동으로 실행되었을 것입니다. 패키지 매니페스트와 잠금 파일(lockfile)의 변경 사항 및 테스트 스위트의 실행 로그를 PR 설명 본문에 일목요연하게 첨부하고, 사내 보안 스캔 게이트를 통과해야만 엔지니어의 최종 승인이 가능한 상태로 전환되었을 것으로 보입니다. 나아가 여러 리포지토리에 걸쳐 예약 작업이 돌아갈 때 리포지토리별로 동일한 의존성 관리 프로필이 병렬 적용됨으로써, 금요일 오후에 집중되는 보안 권고 폭주를 엔지니어의 수작업 개입 없이 안정적으로 흡수하는 파이프라인으로 확장되었을 가능성이 큽니다.

7. 출처

* Checkout.com Engineering Blog — How our AI coding agent generates 18% of our PRshttps://www.checkout.com/blog/how-agent-hal-ships-software-checkout-com발행일: 2026-06-17 (Featuring Agent HAL)

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit parkdaesun.substack.com

1. 왜 이 사례인가

아시아·태평양 금융 서비스 기업 머니포워드(Money Forward)는 소프트웨어를 구축하는 모든 부서에 코딩 에이전트를 도입하는 것을 목표로 설정했습니다. 개발 부서에서 먼저 기술적 효용을 입증한 뒤, 기획(Product)과 디자인, QA 조직으로 적용 범위를 단계적으로 넓혔습니다.

많은 기업이 AI 코딩 도구를 개발자 개인에게만 지급하고 코드 자동완성 수준의 효율 개선에 머무는 것과 달리, 머니포워드는 개발 속도가 빨라질수록 기획·디자인·QA 등 인접 부서가 새로운 병목으로 떠오른다는 점에 주목했습니다. 사내 엔지니어링 생산성 및 AI 연구 부서인 MEPAR(Engineering Productivity and AI Research)가 다양한 AI 코딩 솔루션을 면밀히 비교·평가한 뒤 커서(Cursor)를 전사 표준 플랫폼으로 낙점했고, 2026년 3월 기준 1,000명 이상의 직원이 매일 실무에서 커서를 활용하고 있습니다.

핵심 성과는 뚜렷합니다. 엔지니어 1인당 주당 15~20시간의 업무 시간을 절감했고, 커서 도입 단 1주 만에 코딩 에이전트를 실무에 쓰는 엔지니어가 30% 증가했으며, QA 테스트 생성 시간은 70% 단축되었습니다. 개발 부서를 넘어 기획·디자인·QA 실무진이 프로덕션 코드베이스와 직접 소통하며 소프트웨어 개발 수명 주기(SDLC) 전반을 혁신한 대표적 사례입니다.

2. Problem

초기에 머니포워드 엔지니어링 팀은 타사 벤더의 코드 자동완성 도구와 기본적인 AI 채팅 기능을 도입해 활용하고 있었습니다. 하지만 실질적인 개발 업무 시간 단축으로 이어지지 못했고, 사내 도입 확산은 정체에 부딪혔습니다.

이후 코딩 에이전트 도입으로 개발 속도가 본격적으로 빨라지자, 개발 프로세스와 맞물려 있던 인접 부서들의 병목이 수면 위로 떠올랐습니다.

* QA의 수작업 테스트 작성 부담: QA 엔지니어가 복잡한 제품 명세를 일일이 분석하고, 사용자 스토리별 테스트 케이스를 도출한 뒤, 자동화 스크립트까지 직접 작성해야 하는 반복 노동의 비중이 지나치게 컸습니다.

* PM의 명세와 실제 코드 간 괴리: 제품 요구사항 문서(PRD)가 실제 시스템 구현과 어긋나거나, 문서에 기재되지 않은 기술적 제약이 코드에만 숨어 있어 개발 착수 전에 잠재적 결함을 걸러내기 어려웠습니다.

* 디자인 조직의 정보 단절: 디자이너는 정적인 시안과 개발자의 간접적인 설명에 의존해야 했기에, 실제 사용자 여정이나 실시간 비즈니스 데이터 흐름과 단절된 채 작업할 수밖에 없었습니다.

* 비개발 직군의 도구 수용성 한계: 기존 터미널 중심의 AI 도구는 코드 변경에 따른 화면 결과를 검증하기 위해 별도의 보조 도구를 거쳐야 했기에, 디자인·QA·기획 실무진의 실제 활용률이 크게 떨어졌습니다.

확인된 사실: 기존 AI 도구 도입 정체, 엔지니어링 가속화 이후 기획·디자인·QA 병목 심화, QA의 수동 테스트 케이스 및 스크립트 작성 부담, PM·디자이너의 프로덕션 코드 및 데이터 접근 제약, 복잡하게 상호 연결된 프로덕션 시스템 보유.

3. Solution

3.1 엔지니어링에서 먼저 증명

커서 도입 초기, 머니포워드는 전사 엔지니어링 올핸즈(All-hands) 미팅에서 에이전트가 복잡한 소프트웨어 개발 전 과정을 완결(End-to-End)하는 모습을 직접 시연했습니다. 이를 계기로 개발자들의 자발적인 관심과 수요가 즉각 촉발되었고, 도입 불과 1주 만에 코딩 에이전트를 실무에 활용하는 엔지니어 수가 30% 증가했습니다.

엔지니어들이 커서를 통해 실제로 해결한 주요 업무 사례는 다음과 같습니다.

* iOS 애플리케이션의 서비스 레이어 리팩터링

* Rails 애플리케이션 최적화(10배 성능 개선)

* Terraform을 활용한 AWS·GCP 배포 환경 관리

* 레거시 프론트엔드의 Vue→React 대규모 마이그레이션

아론 리(Aaron Li, Staff Engineer)는 단순 코드 보조에 그쳤던 기존 도구와 달리, 커서 에이전트는 실질적인 작업 전체를 자율적으로 완결할 수 있다는 점이 엔지니어들의 자발적 전환을 이끌어낸 핵심 요인이었다고 평가합니다.

3.2 MEPAR 평가와 전사 롤아웃

머니포워드의 사내 조직인 MEPAR(Engineering Productivity and AI Research)는 시중의 다양한 AI 코딩 솔루션을 체계적으로 비교·평가한 끝에 커서를 전사 표준 플랫폼으로 낙점했습니다.

트란 바 빈 손(Tran Ba Vinh Son, Group Company CTO 겸 MEPAR 매니저)은 특정 거대언어모델에 종속되지 않는 커서의 모델 비의존(Model-agnostic) 인프라 덕분에, 비동기 클라우드 에이전트를 활용해 장시간이 소요되는 복잡한 작업을 손쉽게 병렬 처리할 수 있었다고 설명합니다. 또한 사내 내부 도구와 유기적으로 연결해 로컬 하드웨어의 자원 한계에 구애받지 않고 풍부한 맥락(Context)을 즉각 불러올 수 있는 점도 중요한 장점으로 꼽았습니다.

커서가 최종 선정된 핵심 요인은 네 가지입니다.

* 최소한의 환경 설정: 복잡한 개발 환경 구성 없이도 에이전트와 즉시 협업을 시작할 수 있어, 기술적 숙련도가 서로 다른 다양한 부서 구성원들도 쉽게 다룰 수 있습니다.

* 시각적 검증 역량: 내장 브라우저 환경을 제공하므로, 디자이너와 QA 엔지니어가 에이전트가 수정한 UI 화면 결과를 별도 도구 없이 시각적으로 검증할 수 있습니다.

* 통합 에이전트 워크스페이스: 코드 생성부터 리뷰, 테스트, 디버깅에 이르는 소프트웨어 개발 라이프사이클 전체를 단일 플랫폼 내에서 매끄럽게 처리합니다.

* 대규모 코드베이스 처리 성능: 복잡하게 얽힌 엔터프라이즈 프로덕션 환경에서도 안정적으로 맥락을 탐색해 내므로, 코드 탐색에 익숙하지 않은 직군도 프로덕션 코드에 안전하게 접근할 수 있습니다.

3.3 QA: MCP 기반 이중 에이전트 테스트 자동화

QA 엔지니어는 모델 컨텍스트 프로토콜(MCP)을 활용해 Jira 티켓과 Notion 기획 문서를 커서 환경으로 곧바로 불러옵니다. 이어 첫 번째 에이전트가 기획 명세를 바탕으로 정형화된 테스트 케이스를 설계하면, 두 번째 에이전트가 이를 실행 가능한 Playwright 테스트 스크립트로 자동 변환합니다.

이 파이프라인 덕분에 테스트 생성 시간이 70% 단축되었으며, QA 팀은 기계적인 스크립트 작성에서 벗어나 위험 기반 테스트(Risk-based testing)와 상위 품질 게이트 검증에 더 많은 공수를 투입할 수 있게 되었습니다. 나아가 장애 원인 분석, 테스트 결과 리포팅 자동화, 개발 착수 전 기획 명세 검토까지 커서 에이전트의 활용 영역을 전방위로 넓혔습니다.

셰 레스터(Xie Lester, Chief Quality Office 디렉터)는 커서 도입이 조직 전반의 소프트웨어 품질 보증 방식 자체를 근본적으로 바꾸고 있다고 말합니다.

3.4 Product: 코드 기반 PRD 작성

프로덕트 매니저(PM)는 코드 저장소에서 직접 시스템 간의 상호작용 관계를 추출하고, 아키텍처 다이어그램을 자동 생성하며, 실제 프로덕션 구현 세부사항에 단단히 기반한 PRD를 작성합니다. 이를 통해 개발이 시작되기 전에 잠재적인 엣지 케이스와 기획에서 간과하기 쉬운 시스템 제약을 사전에 찾아냅니다.

오오니시 쇼이치로(Shoichiro Onishi, PM)는 문서에 세부 명세가 빠져 있더라도 커서가 실제 코드베이스를 직접 탐색해 숨겨진 동작 규칙을 찾아내 명확히 제시해 준다고 강조합니다.

3.5 Design: 프로덕션 코드에 직접 프로토타이핑

디자이너는 커서의 내장 브라우저 기능과 풀스택 코드 맥락을 활용해, 실제 애플리케이션 프론트엔드 코드 위에서 UI를 직접 수정하고 실시간으로 검증합니다. 또한 에이전트와 MCP를 통해 프로덕트 분석 데이터에 접근함으로써 데이터에 기반한 정밀한 사용자 경험 설계를 구현합니다.

스도 료타(Ryota Sudo, Product Designer)는 기획 명세와 데이터에 직접 다가가면서, 타인의 간접적인 설명에 의존하지 않고 제품의 실제 동작 원리를 깊이 이해한 상태에서 디자인할 수 있게 되었다고 설명합니다.

확인된 사실: 일일 실사용자 1,000명 이상, 엔지니어 1인당 주당 15~20시간 절감, 도입 1주 내 에이전트 활용 엔지니어 30% 증가, QA 테스트 생성 시간 70% 단축, Jira·Notion 연동 MCP 및 이중 에이전트(테스트 케이스 생성→Playwright 스크립트 변환), PM의 코드 기반 PRD 작성 및 아키텍처 다이어그램 생성, 디자이너의 내장 브라우저 및 데이터 분석 MCP 활용, MEPAR 주도 도구 평가와 비동기 클라우드 에이전트 운영.

4. Impact

정성적 측면에서는, 개발 속도가 빨라지면서 인접한 기획·디자인·QA 조직이 새로운 병목으로 떠올랐다는 문제의식 아래 에이전트 적용 범위를 개발 외 부서로 적극 확장했다는 점이 핵심입니다. 특히 터미널 환경에 머무르지 않고 직관적인 UI/UX와 내장 브라우저를 제공한 것이 기획·디자인·QA 실무진의 수용성을 비약적으로 끌어올린 결정적 배경으로 꼽힙니다.

확인된 사실: 위 표의 수치는 모두 Cursor 공식 고객 사례(2026-03-18) 기준입니다. 프로덕션 결함률, 롤백 빈도, 인프라 운영비용 변동 등은 공개되지 않았습니다.

5. Insight

개발 조직만 빨라지면 병목은 인접 부서로 이동합니다. 머니포워드는 엔지니어링 생산성이 비약적으로 높아진 뒤 기획·디자인·QA가 새로운 제약 요인이 되었다는 점을 직시하고, 동일한 에이전트 플랫폼을 소프트웨어 개발 수명 주기(SDLC) 전반으로 확장했습니다.

비개발 직군으로 확장하려면 시각적 인터페이스와 통합 작업 환경이 필수적입니다. 터미널 중심 도구는 디자이너나 QA 엔지니어가 화면 결과를 확인하기 위해 별도의 보조 도구를 거쳐야 하므로 정착하기 어렵습니다. 직관적인 내장 브라우저와 통합 워크스페이스가 전사적 수용을 이끌어낸 핵심 전제 조건이었습니다.

QA의 역할이 하류(Downstream)에서 상류(Upstream)로 이동합니다. 단순한 테스트 스크립트 작성 자동화에 머물지 않고, 장애 원인 분석, 개발 착수 전 기획 명세 검토, 위험 기반 테스트 설계 등 소프트웨어 개발 초기 단계의 품질 게이트로 업무 중심축이 옮겨갔습니다.

타사 도입을 위한 전제 조건과 한계. 복잡하게 얽힌 대규모 코드베이스에서 안정적으로 맥락을 찾아내는 검색 성능, Jira·Notion 등 협업 도구와의 원활한 MCP 연동, 그리고 장시간 작업을 소화할 비동기 클라우드 에이전트 인프라가 선행되어야 합니다. 다만 벤더 고객 사례라는 특성상 에이전트가 생성한 코드의 장기적 결함률, 보안 거버넌스 프로세스, 직군별 재교육에 투입된 실질 비용 등은 공개되지 않았습니다.

한 줄 요약: 소프트웨어 개발 전 주기에 걸쳐 에이전트를 확산하려면 엔지니어링에서 먼저 가치를 확실히 증명한 뒤, 비개발 직군이 프로덕션 코드와 데이터에 안전하게 접근할 수 있는 시각적 통합 플랫폼을 마련해야 합니다.

6. 원문에 없는 추정 (구현 가설)

6.1 QA 이중 에이전트와 MCP 컨텍스트 주입 파이프라인

근거: 원문은 QA가 MCP로 Jira 티켓과 Notion 문서를 커서에 공급하고, 한 에이전트가 테스트 케이스를 생성한 뒤 다른 에이전트가 Playwright 스크립트로 변환한다고 기술합니다.

Jira 및 Notion MCP 연동은 티켓 ID나 문서 URL을 입력값으로 받아 사용자 스토리, 인수 조건(Acceptance Criteria), 관련 기획 명세를 구조화된 맥락 블록으로 자동 주입하는 형태였을 것입니다. 첫 번째 에이전트는 이 맥락을 바탕으로 Given-When-Then 형식의 논리적 테스트 시나리오 목록을 작성하고, 두 번째 에이전트는 동일 작업 세션이나 신규 브랜치에서 해당 시나리오를 Playwright 테스트 파일로 매핑했을 것으로 보입니다. 테스트 생성 시간을 70% 단축하려면, 에이전트가 기본 스크립트 골격과 DOM 선택자(Selector) 후보를 일괄 생성한 뒤 QA 엔지니어가 위험도가 높은 핵심 분기만 선별 검토·보정하는 인간 참여형(HITL, Human-in-the-loop) 루프가 결합되었을 가능성이 높습니다. 또한 장애 분석과 개발 전 명세 검토는 동일한 MCP 파이프라인을 통해 과거 장애 티켓이나 로그를 조회하고 사전 품질 점검을 거치는 워크플로로 확장되었을 것입니다.

6.2 비동기 클라우드 에이전트와 내부 도구 컨텍스트 게이트

근거: MEPAR CTO는 모델 비의존 인프라로 장시간 작업을 비동기 클라우드 에이전트에 병렬화하고, 내부 도구에 연결해 로컬 하드웨어 제한 없이 컨텍스트를 가져온다고 말합니다.

엔지니어가 Vue→React 마이그레이션이나 Terraform 기반 인프라 배포처럼 수 시간 이상 걸리는 복잡한 작업을 동시에 여러 개 진행하려면, 각 에이전트가 격리된 클라우드 샌드박스에서 독립 브랜치를 생성하고 사내 API나 내부 문서 게이트를 통해 읽기 전용 맥락을 공급받는 아키텍처가 필수적이었을 것입니다. 아울러 기획자나 디자이너가 프로덕션 코드베이스를 다룰 때는 의도치 않은 코드 수정을 방지하기 위해 읽기 전용 권한과 브라우저 프리뷰 샌드박스로 작업 범위를 통제하는 역할 기반 접근 제어(RBAC)가 함께 적용되었을 가능성이 큽니다. 전사 1,000명 이상의 일일 사용자가 안정적으로 공존하기 위해서는 MEPAR가 에이전트 실행 정책, 내부 도구 접근 허용 목록(Allowlist), API 호출 및 토큰 사용량 쿼터를 중앙에서 통제하는 거버넌스 레이어를 마련했을 것으로 추정됩니다.

7. 출처

* Cursor Customer Stories — Money Forward brings Cursor’s coding agents to product, design, and QAhttps://cursor.com/blog/money-forward발행일: 2026-03-18 (Featuring Aaron Li, Tran Ba Vinh Son, Xie Lester, Shoichiro Onishi, Ryota Sudo)

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit parkdaesun.substack.com

1. 요약

회계상 이익은 지분 평가를 거쳐 대차대조표에 반영된다. 반면 실물 투자 현금은 차입금으로 조달되며, 설비투자 중 증분 부채 비중은 32%로 확대되었다.

계약상 위험은 공급망 최하단의 모델 기업으로 전가된다. 두 모델 기업은 약 1.2조 달러의 약정 지출을 부담한다. 시장 가격을 결정하는 핵심 변수는 공급 시점이다.

최종 수요량은 증가하지만 토큰 가격은 떨어진다. Ramp 집계 기준 기업이 실제로 내는 100만 토큰당 실효 가격은 6개월간 41% 하락했다. 이 격차가 축소되면 계약상 손실은 네오클라우드, 모델 기업, 보증인, 하이퍼스케일러 주당순이익의 순서로 전이된다.

2. 질문과 방법

이 리포트는 2026년 AI 인프라 구축에 투입되는 대규모 자금의 조달원과 이동 경로를 추적한다. 회계상 보고되는 이익이 누구의 장부에 어떤 계정으로 기재되는지 규명하고, 최종 소프트웨어 수요가 시장 기대를 밑돌 경우 손실이 전가되는 계약상 순서를 파악한다. 나아가 자본과 위험의 배치가 2030년까지 어떤 궤적으로 재편되는지 살펴본다.

분석을 위해 자금의 흐름을 세 갈래로 분리한다. 첫째는 손익계산서상 영업이익과 영업외이익을 구분해 확인하는 보고 이익이다. 둘째는 영업현금흐름, 설비투자(Capex), 주식 및 채권 발행, 미개시 임대 약정으로 집계되는 실제 현금 흐름이다. 셋째는 의무 인수(take-or-pay), 계약 해지권, 채무 보증, 잔존가치 보증 조항으로 설정된 계약상 위험의 전가 경로다. 기초 자료로는 Amazon, Alphabet, Microsoft, Meta, Nvidia, Oracle, CoreWeave, Nscale, SpaceX 등의 공시 보고서(10-Q, 10-K, 8-K, S-1)와 공식 발표를 활용한다. 비상장 기업인 Anthropic과 OpenAI의 재무 수치는 내부 문건을 인용한 언론 보도(WSJ, Reuters, FT, The Information)를 원천으로 하며 본문에서 보도 수치임을 적시한다. 이어 인프라 임대 단가를 결정하는 제약 요소와 토큰 수요, 매출액, 투자자본수익률(ROI) 추이를 점검해 자본 순환 구조가 유지되는 조건을 정리하고, 2030년까지 전개될 세 가지 시나리오에서 손실이 파급되는 계층을 도출한다.

데이터에는 명확한 전제와 한계가 존재한다. 비상장 모델 회사의 모든 실적 수치는 언론 보도에 의존한다. 특정 월의 매출에 12를 곱해 산출하는 연환산 매출(run-rate)은 확정 연간 매출과 차이를 보인다. 일례로 OpenAI의 2025년 실제 매출은 130.7억 달러였으나 연말 시점 연환산 매출은 214억 달러로 집계되었다. 클라우드 마켓플레이스를 통한 판매 인식 방식도 상이하다. Anthropic은 총액 기준으로, OpenAI는 순액 기준으로 계상하므로 단순 수치 합산에는 구조적 한계가 따른다. Meta를 제외한 주요 하이퍼스케일러의 2026년 3분기 실적 공시일은 10월 28~30일로 예정되어 있어 작성 기준일인 2026년 10월 26일 시점에는 포함되지 않았다. Meta는 10월 중 공시된 3분기 10-Q 수치를 반영했다.

3. 지분 평가이익과 회계상 순환 구조

3.1 본업 영업이익을 앞지른 지분 평가이익

빅테크 기업과 반도체 제조사의 손익계산서를 살피면 클라우드 및 칩 판매 등 본업에서 거둔 영업이익보다 피투자 기업의 지분 가치 재평가에서 발생한 영업외이익이 더 크게 계상되는 현상이 나타난다.

Amazon의 2026년 2분기 영업외 세전 기타수익 534억 달러는 필자 계산상 같은 기간 AWS 영업이익 166억 달러의 3.2배이며 전사 영업이익 275억 달러의 1.9배다1,2. Alphabet 또한 2026년 2분기 기타수익으로 계상한 980억 달러 가운데 771억 달러가 세후 순이익에 기여했다. 이는 전체 주당순이익 9.11달러 중 6.26달러를 차지하며 필자 계산으로 69% 비중을 나타낸다3,4.

이러한 지분 평가이익은 피투자 모델 기업과의 대규모 자본 제휴 및 컴퓨팅 인프라 공급 계약에 직접 연동되어 있다. Amazon이 장부에 반영한 Anthropic 관련 증권의 가치는 2026년 6월 30일 기준 무의결 우선주 925억 달러와 전환사채 979억 달러로 집계된다2. Amazon은 2분기에 Series G 라운드로 50억 달러, Series H 라운드로 50억 달러를 집행했으며 향후 집행할 잔여 출자 약정액은 213억 달러다2. 이는 Anthropic이 2026년 4월 Amazon과 맺은 계약에서 향후 10년 동안 AWS 인프라에 1,000억 달러 이상을 지출하기로 확약하고, Amazon이 기본 50억 달러에 최대 200억 달러를 추가 투자하기로 합의한 구조에 근거한다7.

Alphabet의 경우 공정가치 측정대체법을 적용한 비상장 지분 증권 장부가가 2025년 말 641억 달러에서 2026년 6월 30일 1,243억 달러로 확대되었다. 2분기 공시에서 이 중 879억 달러가 공정가치 재측정 항목으로 처리되었다8. Alphabet의 잔여 출자 약정액은 분기 중 300억 달러에서 200억 달러로 줄었다. 공시 문건에 특정 상대방 사명이 적시되지는 않았으나 언론 보도는 이를 Anthropic에 대한 약정으로 파악하고 있다4. Alphabet이 2023년 4월 Anthropic에 처음 집행한 투자액은 3억 달러였다4. Microsoft는 2025년 10월 단행된 법인 재자본화 과정을 거쳐 OpenAI Group PBC 지분 약 27%를 취득했다. 이와 연계하여 OpenAI는 Azure 클라우드 인프라를 향후 2,500억 달러 규모로 추가 이용하기로 합의했다9.

3.2 수주잔고와 평가이익의 다중 계상 구조

보고되는 평가이익의 이면에는 단일 컴퓨팅 계약에 묶인 자금이 복수의 재무제표를 순환하며 지표를 증폭시키는 구조가 자리한다.

Amazon과 Anthropic 사이의 거래 관계를 바탕으로 회계적 자금 이동 경로를 추적하면 세 단계로 확인된다(필자 계산). 첫째, Anthropic이 AWS 인프라 이용을 위해 10년간 1,000억 달러 이상을 지출하기로 약정하면 해당 총액은 즉시 AWS의 수주잔고(RPO)에 포함된다. AWS 수주잔고는 회사 발표를 인용한 보도 기준 2026년 2분기 4,960억 달러를 기록해 전년 동기 대비 약 2.5배 확대되었다10. 둘째, Anthropic 매출의 47%(2025년 기준 21.6억 달러)는 AWS 및 Google 마켓플레이스를 통해 발생하며, Anthropic은 이 거래액을 총액 기준으로 자사 매출에 계상한다. 이 과정에서 플랫폼 수수료 약 3.51억 달러(매출 1달러당 약 16센트)는 마케팅 비용으로 처리된다. Amazon과 Google은 2025년 말 기준 Anthropic 매출채권 9.09억 달러의 60%를 보유하고 있다11. 셋째, 해당 계약을 근거로 Anthropic의 기업가치가 상향되면 Amazon은 보유 지분의 공정가치 평가이익 505억 달러를 자사 영업외이익으로 기재한다2. 하나의 컴퓨팅 구매 계약이 수주잔고, 총액 매출, 지분 평가이익이라는 세 가지 재무 지표로 동시에 전환되는 셈이다.

주요 기업의 수주잔고 합계는 가파르게 팽창했다. Microsoft의 상업 부문 수주잔고는 OpenAI 제외 시 25% 증가에 그쳤으나 전체 수치는 84% 증가한 6,780억 달러에 달하며 향후 12개월 내 매출로 인식될 비중은 약 30%다12. Google Cloud 수주잔고는 2026년 1분기부터 반영된 TPU 하드웨어 공급 계약을 포함해 5,140억 달러로 집계되었다13. 여기에 AWS의 4,960억 달러10, 전년 동기 대비 2,090억 달러 늘어난 Oracle의 6,640억 달러14, CoreWeave의 1,037억 달러15를 단순 합산하면 약 2.46조 달러에 이른다(필자 계산). 다만 OpenAI와 Anthropic의 다년 약정은 복수 하이퍼스케일러 장부에 중복 반영되어 있다. Goldman Sachs는 중복분을 차감한 실질 잔고를 1.7조 달러 이상으로 추정한다16. BofA는 Oracle 수주잔고의 절반 이상이 OpenAI 한 곳에 집중되어 있다고 파악한다17.

반대편에 있는 모델 개발사의 손익계산서에는 평가이익과 대칭되는 대규모 손실이 계상된다. 상장 서류 초안 보도에 따르면 Anthropic의 2025년 순손실 420억 달러 중 약 340억 달러, 2026년 상반기 순손실 807억 달러 중 약 720억 달러가 발행 금융상품의 가치 상승에 따른 비현금성 공정가치 재평가 손실이었다18,19. 유출된 감사 재무제표 보도에 나타난 OpenAI의 2025년 실적 역시 영업손실 209.2억 달러에 전환 지분 및 워런트 평가손실 415.5억 달러가 더해져 연결 순손실 약 604억 달러, 귀속 순손실 385억 달러로 나타났다20,21. OpenAI는 2025년 연구개발비 191.8억 달러 가운데 105.9억 달러를 Microsoft에 컴퓨팅 사용료로 지급했으며, 이는 해당 연도 매출 130.7억 달러의 81%에 상당한다22.

국제 금융기구들은 이러한 상호 연계 구조에 대해 주의를 환기했다. IMF는 금융안정보고서(2026-10-13)에서 2023년 이후 공개된 14건의 AI 거래를 점검하며 약 3,000억 달러의 지분과 약 6,500억 달러의 부채가 약 1.4조 달러의 미래 매출 약정을 지탱하고 있다고 평가했다. 기초 자산 가치 하락 시 연결된 미래 매출이 함께 소멸하는 구조를 “역방향 위험(wrong-way risk)”으로 지목했다23. BIS 연차보고서(2026-06-28) 또한 반도체 기업과 하이퍼스케일러가 모델 기업 지분을 취득하고 모델 기업은 장기 컴퓨팅 구매를 약속하는 순환 금융의 세부 조건이 불투명하게 공시되는 실태를 짚으며, 단일 자산이 여러 대차대조표에서 중복 담보화될 위험을 언급했다24.

장부상 이익과 수주잔고는 지분 재평가와 다년 약정을 매개로 증폭되고 있다. 반면 실물 설비투자를 실행하기 위한 실제 현금 조달은 상이한 경로를 밟고 있다.

4장부터 이어지는 전체 리포트는 블로그에서 읽어 주세요. 설비투자 현금의 조달 경로와 부채 구조, 위험의 전가 경로, 인프라 임대 단가, 최종 수요 점검, 2030년 시나리오와 결론, 참고 자료까지 모두 담겨 있습니다.

https://ax.yumes.net/ko/research/ai-economy-money-flow/

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit parkdaesun.substack.com