AX Case Study Podcast

1. 왜 이 사례인가

많은 엔지니어링 조직이 AI 코딩 에이전트를 도입하지만, 대개 자동완성이나 단발성 리팩터링 수준에 머뭅니다. 작업을 에이전트에 통째로 넘기면 아키텍처 맥락을 무시한 채 동작만 겨우 하는 난잡한 코드(AI-slop)가 양산되거나, 마이그레이션 및 상태 오염으로 개발 환경이 깨져 결국 사람이 수습해야 하기 때문입니다.

스마트 오피스 및 IoT 기반 운영 관리 SaaS를 개발하는 프랑스의 25인 스타트업 메르시야니스(MerciYanis)의 CTO 마티외 자부르(Matthieu Jabbour)가 공개한 기술 블로그(2026년 4월 20일)는 소규모 팀이 어떻게 백로그 전체를 에이전트 플릿에 위임하고 프로덕션 퀄리티를 유지했는지에 대한 정밀한 청사진을 제시합니다.

메르시야니스는 2025년 11월 차세대 프론티어 모델(Opus 4.5, GPT-5.2)이 출시된 직후, 막연한 기대감 대신 실제 스프린트 백로그를 대상으로 인간 개발자(주니어 및 시니어)와 에이전트 간의 엄격한 A/B 벤치마크를 진행했습니다. 동일한 사용자 스토리, 와이어프레임, 모호성을 가공 없이 투입하고, 일반 엔지니어와 동일하게 CI 통과 및 동료 리뷰 승인을 거쳐야 하는 프로덕션 머지 기준을 적용했습니다.

실험 결과는 놀라웠습니다. 전체 백로그 티켓의 머지율은 약 95%에 달했고, 작업 속도는 시니어 추정치 대비 최대 10배, 주니어 대비 최대 32배(보일러플레이트 작업의 경우 최대 86배)까지 단축되었습니다. 머지된 PR당 토큰 비용의 중앙값은 3유로 미만이었습니다.

더 주목할 부분은 이를 뒷받침한 엔지니어링 인프라입니다. 암묵지(tacit knowledge)를 체계화한 핸드북(Handbook), 에이전트 세션마다 독립된 풀스택 인스턴스를 수 분 내에 띄우는 환경 복제 시스템, 비개발 직군도 슬랙 멘션으로 기능을 빌드하고 라이브 프리뷰를 확인하는 전사 슬랙 봇을 구축했습니다. 25인 규모의 팀이 수백 명 규모 조직의 개발 처리량을 소화하게 된 실전 아키텍처 사례입니다.

2. Problem

메르시야니스가 초기 에이전트 도입에서 겪었던 한계와 구조적 난제는 세 가지였습니다.

2.1 맥락 없는 에이전트가 양산하는 ‘임의적 선택’과 AI-slop

에이전트에게 사전 브리핑 없이 티켓을 주면, 에이전트는 전역 아키텍처 비전이나 특정 라이브러리가 금지된 이유를 모른 채 ‘일단 완료 상태’를 만들기 위해 임의의 결정을 내립니다. 그 결과 표면적으로는 작동하지만 내부 아키텍처 원칙을 깨뜨리는 저품질 코드가 양산되었습니다. CTO는 “이해하지 못하고 통제하지 못하는 코드를 배포하는 것은 제품을 외주 주는 것과 다름없으며, 첫 번째 장애나 확장 시점에 막대한 대가를 치르게 된다”고 지적했습니다.

2.2 동시 실행 시 발생하는 데이터베이스 마이그레이션 충돌

인간 엔지니어는 한 번에 하나의 브랜치에서 순차적으로 작업합니다. 반면 에이전트는 수십 개 세션이 동시에 병렬로 실행됩니다. 단순한 Git 워크트리(worktree) 분리만으로는 복수 저장소와 공유 인프라 환경을 감당할 수 없었습니다. 특히 스키마 마이그레이션이 포함된 작업을 여러 에이전트가 단일 테스트 데이터베이스에서 실행할 경우, 상태 오염과 레이스 컨디션(경쟁 상태)으로 인해 다른 모든 에이전트 작업이 연쇄 중단되는 치명적 문제가 발생했습니다.

2.3 비즈니스 조직과 엔지니어링 간의 컨텍스트 단절

25명 규모의 조직임에도 불구하고, 영업이나 고객 성공(CSM) 팀이 고객 미팅에서 수집한 요구사항이 실제 배포로 이어지기까지는 긴 소통 사이클이 소요되었습니다. 비개발 직군에게 로컬 개발 환경(Docker, 저장소 복제 등) 구성을 요구하는 것은 현실적으로 불가능했기에, 비개발자가 직접 아이디어를 프로토타이핑하고 검증할 수 있는 진입 장벽 없는 협업 인터페이스가 절실했습니다.

3. Solution

메르시야니스는 이 세 가지 문제를 세 단계의 시스템 레이어로 해결했습니다.

3.1 컨텍스트 계층: MerciYanis Handbook과 슬래시 커맨드

에이전트가 팀의 3개월 차 온보딩 엔지니어 수준의 맥락을 갖추도록 노션에 흩어져 있던 사내 지식을 100% 마크다운 기반 단일 저장소인 ‘MerciYanis Handbook’으로 집약했습니다.

* 엔지니어링 철학, 시스템 아키텍처 및 서비스 경계, 인프라 배포 원칙, 코딩 표준, 단위 테스트 작성 지침 등을 체계화했습니다.

* Claude Code의 커스텀 슬래시 커맨드를 통해 에이전트의 워크플로를 강제했습니다. 예를 들어 /fix 커맨드를 실행하면:

* 아키텍처 챕터를 읽어 서비스 경계 확인

* 스택 챕터를 읽어 허용된 라이브러리와 패턴 확인

* 로컬에서 버그를 반드시 재현 (재현 실패 시 작업 중단)

* 최소한의 diff로 수정 코드 작성

* 테스트 챕터를 읽고 버그 검증용 단위 테스트 작성

* 전체 테스트 스위트 실행 (실패 시 PR 오픈 금지)

* PR 템플릿 규칙에 맞춰 PR 생성

* 이 프로세스를 통해 에이전트 코드 품질을 ‘대체로 양호한 수준’에서 ‘거의 100% 프로덕션 수준’으로 끌어올렸습니다.

3.2 격리 인프라 계층: 환경 복제 시스템 (Environment Replication)

동시 다발적인 에이전트 병렬 실행을 안전하게 격리하기 위해, 세션마다 플랫폼 전체를 복제하는 인프라를 구축했습니다.

* 5분 이내 풀스택 부트업: 스크립트 단 한 줄로 데이터베이스 시딩, Kafka 메시지 브로커, 모든 마이크로서비스, 소스 빌드 라이브러리를 5분 내에 완전 기동하는 플레이북을 완성했습니다.

* 완전한 세션별 격리: 에이전트가 작업을 시작하면 전용 독립 컨테이너 환경이 프로비저닝되어 스키마 변경이나 데이터 조작이 다른 에이전트에 일절 영향을 주지 않으며, 작업 완료 시 즉시 삭제됩니다.

* Traefik 동적 라우팅: 단일 머신에서 수십 개의 독립 환경이 포트 충돌 없이 안정적인 고유 호스트네임 URL로 서비스되도록 라우팅을 구성했습니다.

3.3 인터페이스 계층: 슬랙 봇 기반 전사 빌드 민주화

전사 직원이 개발 환경 설정 없이 에이전트를 호출할 수 있도록 슬랙 봇을 개발했습니다.

* 전용 격리 서버에 에이전트 스택을 올리고, 슬랙 채널에서 봇을 멘션하여 요구사항을 서술하면 봇이 독립 환경을 띄워 에이전트를 실행합니다.

* 웹 앱, 백오피스 등 영향받는 모든 제품 화면에 대한 실시간 라이브 프리뷰(Preview URL)를 슬랙 스레드에 반환합니다.

* 디자이너, PM, 영업, CSM이 공개 스레드에서 실제 구동 화면을 보며 피드백을 주고받는 ‘사전 공동 검증 루프’가 형성되었습니다.

* 부수 효과로 코드베이스 기반의 실시간 지능형 질의응답 엔진으로 활용되어, 영업팀이 보안 및 컴플라이언스 질문(인증 여부, 개인정보 처리 등)을 개발팀에 묻지 않고 자체 해결하게 되었습니다.

4. Impact

메르시야니스가 통제된 백로그 벤치마크 및 프로덕션 운영을 통해 확인한 정량적 성과는 다음과 같습니다. (수치 출처: MerciYanis 기술 블로그, 2026-04-20)

마티외 CTO는 개발 속도가 10배 빨라지면서 병목이 ‘코드 작성’에서 ‘코드 리뷰(Code Review)‘와 ‘제품 우선순위 판정(Product Arbitration)‘으로 완전히 이동했다고 밝혔습니다. 하루 수십 건의 PR을 소화하기 위해 자동화된 보안 검사, 에이전트 간 사전 리뷰(agent-on-agent pre-review) 시스템을 도입하고 있습니다.

5. Insight

메르시야니스의 전환기는 AI 에이전트를 개발 조직에 실질적으로 안착시키기 위한 본질적 교훈을 제공합니다.

문서화는 에이전트의 런타임 연료입니다. 노션에 방치된 비구조화된 문서는 에이전트에게 무용지물입니다. 아키텍처 규칙, 금지된 패턴, 테스트 지침이 코드 저장소 내 100% 마크다운 형태로 살아있어야 하며, 에이전트가 코드를 쓰기 전에 해당 문서를 강제로 읽도록 제어해야 품질이 담보됩니다.

인간 온보딩 최적화가 에이전트 최적화로 직결됩니다. ‘첫 PR까지 걸리는 시간’을 줄이기 위해 컨테이너화와 5분 풀스택 기동 스크립트에 투자했던 과거의 노력이 에이전트 도입의 가장 큰 디딤돌이 되었습니다. 사람에게 복잡하고 취약한 개발 환경은 에이전트에게도 치명적입니다.

엔지니어의 역할은 코딩에서 아키텍처와 플랫폼으로 진화합니다. 코딩 자체가 상품화(commodity)되면서, 엔지니어의 핵심 역할은 문제 정의와 솔루션 설계(Product Builder), 그리고 수백 개의 PR이 쏟아져도 시스템 일관성과 품질을 유지하는 플랫폼 엔지니어링(Platform Engineer)으로 재편됩니다.

6. 구현 방식 추론 (Architectural Walkthrough)

6.1 근거: 메르시야니스는 에이전트 세션마다 독립된 플랫폼 복제본(데이터베이스, Kafka, 마이크로서비스)을 5분 내에 프로비저닝하고 Traefik을 통해 고유 URL로 라우팅한다고 밝혔습니다. 격리 인프라의 오케스트레이션은 Docker Compose와 Traefik의 레이블 기반 동적 서비스 디스커버리를 결합한 구조로 추정됩니다. 슬랙 봇이나 CLI에서 작업이 인입되면 작업 ID(예: task-8492) 기반의 독립 브랜치와 고유 네임스페이스가 생성됩니다. 오케스트레이터 스크립트는 템플릿화된 Docker Compose 매니페스트에 고유 네트워크와 볼륨을 바인딩하고, 컨테이너 라벨에 Traefik 라우팅 규칙(예: Host('task-8492.preview.merciyanis.internal'))을 주입하여 기동합니다. 시드 데이터베이스는 경량화된 익명화 스냅샷 덤프를 마운트하여 컨테이너 초기화 시 수초 내에 복원되도록 설계되었을 것이며, 에이전트 작업이 종료되면 해당 컨테이너 그룹과 임시 볼륨이 즉시 회수되는 라이프사이클 훅이 작동합니다.

6.2 근거: 슬랙 봇이 비개발 직군의 요청을 받아 에이전트를 구동하고, 변경된 화면의 라이브 프리뷰 링크를 스레드에 반환하며, 코드베이스 기반 Q&A를 수행한다고 밝혔습니다. 슬랙 봇 백엔드는 Bolt SDK와 백그라운드 작업 큐(예: Celery 또는 Redis Queue) 기반의 비동기 아키텍처로 구현되었을 가능성이 높습니다. 사용자가 슬랙 채널에서 멘션과 함께 기능 추가나 버그 수정을 요청하면, 봇은 즉시 “작업 환경을 준비 중입니다”라는 스레드 메시지를 게시하고 백그라운드 워커에 작업을 인큐(enqueue)합니다. 에이전트 런타임은 로컬 저장소를 체크아웃한 뒤 앞서 구축된 전용 Docker 환경의 API 엔드포인트와 통신하며 빌드 및 테스트를 수행합니다. 작업이 완료되면 Traefik이 노출한 프리뷰 URL과 요약 변경 내역을 슬랙 API를 통해 해당 스레드로 콜백 업데이트합니다. 코드 질의응답 요청의 경우 환경 기동 없이 최신 main 브랜치의 AST 및 핸드북 마크다운 파일을 기반으로 RAG 파이프라인을 거쳐 비즈니스 친화적 언어로 변환된 답변을 반환하도록 분기 처리되었을 것으로 분석됩니다.

7. 출처

* MerciYanis Engineering Blog — Going AI-Native: How We Handed Our Backlog to AgentsURL: https://engineering.merciyanis.com/blog/going-ai-native-how-we-handed-our-backlog-to-agents발행일: 2026-04-20저자: Matthieu Jabbour (CTO, MerciYanis)

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를 도입하려는 많은 금융·기술 기업이 겪는 공통된 병목은 두 가지입니다. 첫째는 외부 보안·컴플라이언스 심사 때문에 PoC에서 프로덕션으로 넘어가지 못하는 기술적 지연이고, 둘째는 AI를 도입해도 사람의 기존 역할과 조직 구조가 그대로 유지되어 실질적인 비용·운영 구조 혁신으로 이어지지 못하는 조직적 지연입니다.

Brex는 이 두 장벽을 엔지니어링 플랫폼과 운영 조직의 전면 재설계로 돌파했습니다. CTO James Reggio와 COO Camilla Matias가 주도한 이 전환은 AI를 단순한 직원용 비서(Copilot)로 배포하는 데 그치지 않고, 고객용 제품(Product AI)과 사내 운영(Operational AI)이 공유하는 사내 에이전트 플랫폼(Agent Platform)을 구축하는 것에서 출발했습니다.

운영 조직에서는 외주 BPO(비즈니스 프로세스 아웃소싱)에 의존하던 수동 처리 업무를 에이전트에 맡기고, 사람의 역할을 L1(절차 실행)·L2(에이전트 관리 및 예외 처리)·L3(도메인 정책 및 시스템 설계)의 3단계로 재정의했습니다. 그 결과 분쟁 처리 시간은 3시간에서 3초로 줄었고, 고객 지원 대화의 50% 이상이 챗봇 첫 접점에서 해결되었으며, 전수(100%) 상시 품질 평가(QA)가 구축되었습니다. 이 사례는 AI 도입이 단순한 소프트웨어 도입이 아니라 직무 체계와 운영 거버넌스의 구조적 재편이어야 함을 보여줍니다.

2. Problem

전통적인 금융 서비스 운영은 규제 준수와 사기 방지를 위해 세분화된 전문 조직을 전제로 돌아갑니다. 신용 평가, 본인 확인(KYC), 결제 분쟁, 연체 계정 관리 등 각 영역마다 별도의 전문 인력과 복잡한 핸드오프 절차가 필요했습니다.

Brex의 운영 규모가 커지면서 다음과 같은 구체적 병목이 심화되었습니다:

* 외주 BPO 의존과 느린 처리 속도: 카드 분쟁 제기처럼 100페이지가 넘는 규칙집과 엄격한 절차서(SOP)를 기반으로 하는 업무는 BPO 인력의 수동 검토에 의존했습니다. 한 건을 처리하는 데 평균 3시간이 소요되었고, 처리 품질 편차도 컸습니다.

* 샘플링 기반 QA의 한계: 수많은 BPO 및 내부 상담원의 고객 응대 품질을 관리하기 위해 5명의 전문 QA 담당자가 일일이 표본을 추출해 분석했으나, 전체 상담량의 극히 일부만 검수할 수 있었습니다.

* 규제 및 조달 절차의 병목: 1,000명 이상의 조직에서 새로운 AI 도구를 도입할 때마다 개별 공급업체에 대한 보안·법무·조달 실사가 수개월씩 걸렸고, 승인이 날 무렵에는 이미 상위 기술이 등장해 도구가 뒤처지는 악순환이 발생했습니다.

* 전부 아니면 전무(All-or-Nothing) 함정: 업무 프로세스를 자동화할 때 100% 무인 처리를 목표로 잡다 보니, 주관적 판단이나 모호한 기준이 필요한 영역에서 프로젝트가 번번이 좌초되었습니다.

확인된 사실: BPO 기반의 수동 처리 의존, 분쟁 처리 건당 약 3시간 소요, 5명의 인력이 표본 샘플만 검수하던 QA 체계, 1,000명 이상 규모에서 발생하는 느린 조달·법무 병목, 14단계에 이르는 수동 KYC 절차.

3. Solution

Brex는 엔지니어링 기반의 플랫폼 구축과 운영 조직의 역할 재정의를 병렬로 진행했습니다.

3.1 공통 인프라: Retool 기반 사내 에이전트 플랫폼

Brex의 시스템 엔지니어링 팀(전체 350명 EPD 중 약 25명)은 사내 에이전트 플랫폼을 구축했습니다. 2023년 3월 OpenAI 개발자 플랫폼을 모방한 프로토타입에서 출발해, 프롬프트 관리 시스템, 다중 모델 벤치마킹 및 평가 프레임워크, 자동화 워크플로 연동 API를 갖춘 전사 플랫폼으로 발전했습니다.

특히 외부 고객용 제품과 사내 운영 도구가 동일한 모델 컨텍스트 프로토콜(MCP) 도구를 공유하도록 설계했습니다. 제품 기능 확장을 위해 새 도구를 MCP에 추가하면 사내 에이전트 플랫폼에서도 즉시 해당 도구를 호출해 운영 에이전트를 조립할 수 있는 제품 루프가 완성되었습니다.

3.2 데이터 수명주기 중심의 법무·보안 사전 승인 거버넌스

공급업체별로 진행하던 수개월 단위의 조달 심사를 데이터 수명주기 기반 통제 기준으로 전환했습니다:

* 30일 이상 데이터를 보관하지 않음

* 고객 입력을 모델 재학습에 활용하지 않음

* 데이터 격리 보장

위 기준을 충족하는 도구는 사전 승인 카테고리로 분류했습니다. 개발 코드베이스는 ‘저위험 기업 데이터’로 재분류하고, 개별 계정 대신 사내 Retool 프록시를 통한 SSO 인증을 강제했습니다. 임직원은 Slack에서 /c1(ConductorOne) 명령어로 원하는 도구를 선택하면 백엔드 Okta를 통해 즉시 프로비저닝받는 셀프서비스 환경을 구축했습니다.

3.3 3단계 운영 직무 모델 (L1 / L2 / L3)

운영 조직의 역할을 작업 단위가 아닌 에이전트 관리 단위로 재편했습니다:

* L1 (절차적 업무 실행): 정형화된 SOP를 따르던 기존 BPO 업무를 에이전트가 무인으로 직접 수행합니다. 고객 지원 대화의 50% 이상이 챗봇 1차 접점에서 종결됩니다.

* L2 (에이전트 관리 및 예외 검토): 기존 일선 관리자와 시니어 분석가가 사람을 관리하는 대신 에이전트를 관리합니다. 성능 평가 대신 프롬프트를 피드백하고 품질 기준을 고도화합니다. 과거 5명이 표본을 보던 QA 업무를 단 1명의 리드가 전체 응대(100%)를 실시간 검수하는 AI QA 에이전트를 감독하는 형태로 개편했습니다.

* L3 (도메인 전문가 및 시스템 설계자): 신용 전략, 이상 거래 탐지, 규제 컴플라이언스 전문가들이 에이전트와 사람이 협업하는 전체 시스템의 정책과 경계 조건을 설계합니다.

3.4 주요 운영 워크플로 자동화

* 카드 분쟁 처리: 결제 운영 매니저(Kyle Martin)가 100페이지 분량의 마스터카드 분쟁 가이드와 BPO 절차서를 에이전트 플랫폼에 입력하고 프롬프트를 반복 고도화하여 워크플로 전체를 자동화했습니다.

* 점진적 KYC 및 부정적 언론(Adverse Media) 탐지: 14단계 KYC 절차 중 주관적 판단이 덜한 8~10개 단계를 에이전트에 먼저 위임했습니다. 특히 모호성이 큰 부정 언론 탐지 작업에서 에이전트는 정밀도 88%를 기록해 사람의 기준선(85%)을 상회했습니다.

* 연체 계정 맞춤형 회수 커뮤니케이션: 기존의 고정 이메일 템플릿 수정 방식을 벗어나, 고객 계정 이력과 협상 가이드라인을 반영해 강도와 어조가 다른 여러 선택지를 에이전트가 생성하고 담당자가 최종 선택·발송하도록 했습니다.

3.5 AI 유창성(Fluency) 평가 및 채용 기준 변경

전사 운영 인력을 대상으로 프롬프트 기법, 도구 활용(Cursor, NotebookLM 등), 워크플로 설계 교육을 의무화했습니다. 분기마다 4단계(User → Advocate → Builder → Native) 자가 평가를 거쳐 하위 25% 인원에게는 하루 3~5회 반복 업무를 자동화하는 실습 과제를 부여했습니다. 또한 비지원 부서 전원 채용 시 실제 비즈니스 시나리오(예: 7가지 딜 데스크 가격 책정)를 해결하는 AI 활용 케이스 스터디를 의무화하고 프롬프트 작성 내역과 사고 과정을 평가 요소로 삼았습니다.

확인된 사실: 25명 규모의 시스템 엔지니어링 팀이 Retool 기반 에이전트 플랫폼 운영, MCP 공통 사용, ConductorOne + Okta 사전 승인 조달 자동화, L1/L2/L3 조직 개편, 100% AI 전수 QA 구축, 15개 이상의 지원 직무 L2 전환, 4단계 유창성 프레임워크 운영.

4. Impact

First Round 인터뷰 원문에 공개된 측정 수치는 다음과 같습니다. 모든 지표의 기준일은 원문 인터뷰 발행 시점인 2025년 9월 25일입니다.

원문은 분쟁 신청서에 기재되는 논거의 질도 향상되었다고 기록합니다. 과거 BPO 담당자가 규정집에서 4~5개 논점을 찾아 기재했다면, 에이전트는 미처 검토하지 못했던 2~3개 추가 규정을 더 찾아내 설득력 있는 문서로 요약했습니다.

5. Insight

Brex의 사례는 AI 에이전트를 실무 운영 코어에 안착시키기 위해 필요한 조직적 전제들을 명확히 보여줍니다.

도구 도입이 아닌 인프라 통일입니다. 고객용 제품을 개발하는 기술 스택과 사내 운영 자동화 스택을 분리하지 않고, 동일한 MCP와 에이전트 플랫폼으로 일원화했습니다. 개발팀이 제품용으로 만든 도구가 즉시 사내 운영 담당자의 에이전트 조립 도구로 재사용되는 선순환이 일어났습니다.

거버넌스의 관점 전환이 필요합니다. 공급업체 이름을 따지는 심사 대신 ‘데이터가 어떻게 처리·보관되는가’를 기준으로 자동 승인 경로를 열어주어 조직 내 도구 실험의 속도를 유지했습니다.

100% 자동화의 함정을 피해야 합니다. 단번에 전 과정을 무인화하려 하지 않고, 신뢰도가 확보된 40~80%의 단계만 먼저 떼어내 에이전트에 넘겼습니다. 모호성이 남는 예외 구간은 사람이 검토하도록 설계함으로써 조기 가치 실현과 리스크 방지를 동시에 달성했습니다.

사람 관리자에서 에이전트 관리자로 전환해야 합니다. 단순 작업자(L1)를 줄이는 데 그치지 않고, 중간 관리자(L2)의 역할을 ‘팀원 평가’에서 ‘프롬프트 평가 및 에이전트 피드백 루프 관리’로 전환했습니다. 직무의 본질을 바꾸지 않고 기술만 얹는 도입은 작동하지 않는다는 것을 보여줍니다.

복제 조건과 한계. 이 모델이 작동하려면 최소 수십 명 규모의 내부 시스템 엔지니어링 역량, Retool 등 내부 툴 플랫폼 구축 경험, 그리고 명문화된 표준 업무 절차서(SOP)가 사전에 준비되어 있어야 합니다. 명확한 SOP가 없는 상태에서는 프롬프트 엔지니어링으로 해결할 수 있는 영역이 극히 제한적입니다.

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

6.1 Retool 에이전트 플랫폼과 MCP 오케스트레이션 파이프라인

근거: 원문은 시스템 엔지니어링 팀이 2023년 3월부터 OpenAI 개발자 플랫폼을 모방한 Retool 기반 플랫폼을 구축했고, 내·외부 동일한 MCP(Model Context Protocol) 도구를 공유하며 API 연동 워크플로를 제공한다고 명시합니다.

실제 플랫폼 내부에서는 운영자가 Retool UI에서 프롬프트를 작성하고 모델(OpenAI, Anthropic 등)을 지정하면, 백엔드의 MCP 클라이언트가 금융 코어 시스템의 읽기 전용 API(계좌 잔액 조회, 결제 승인 내역, 거래처 정보) 및 외부 검색 툴과 결합되는 구조였을 가능성이 높습니다. 운영자가 버튼을 클릭해 테스트를 실행하면 동일한 입력 데이터 세트에 대해 여러 모델의 출력과 토큰 소요 시간, 비용이 비교 표로 렌더링되고, 사전에 정의된 평가 기준(Eval rubric)에 따라 일치 여부가 채점되는 파이프라인이 Retool 상단에 구현되었을 것입니다. 배포 단계에서는 검증된 프롬프트와 도구 조합이 고유한 에이전트 엔드포인트 ID로 발행되어, Slack 봇이나 웹훅 기반 내부 배치 작업에서 직접 호출할 수 있도록 구성되었을 것으로 추정됩니다.

6.2 100% AI 전수 QA 에이전트의 피드백 루프

근거: 원문은 5명의 수동 QA 담당자가 1명으로 줄고, 에이전트가 고객 응대 전체(100%)를 사내 품질 기준표에 따라 실시간으로 검수하며, 매니저는 에이전트 코칭에 집중한다고 밝힙니다.

이를 프로덕션 환경으로 옮기면, 매일 수천 건 발생하는 고객 상담 로그가 종료되는 즉시 이벤트 버스를 통해 비동기 QA 평가 워크플로로 전달되었을 것입니다. QA 에이전트는 대화 전문을 수신하여 상담원의 공감도, 금융 규정 준수 여부, 안내의 정확성, 해결 완료 여부 등을 항목별(예: 1~5점)로 채점하고 판정 사유를 생성합니다. 기준 점수 미달이나 규정 위반 플래그가 발생한 티켓은 즉시 L2 매니저 전용 예외 대시보드로 격리됩니다. 매니저는 이 대시보드에서 문제 사례의 군집(클러스터링)을 확인하고, 이것이 상담원의 안내 실수인지 에이전트 프롬프트의 지침 부족인지를 판별하여 시스템 프롬프트 업데이트나 개별 코칭으로 즉각 연결하는 폐쇄 루프가 작동했을 가능성이 큽니다.

6.3 분쟁 처리 에이전트의 규칙 파싱 및 증빙 생성 엔진

근거: 원문은 Kyle Martin이 100페이지 분량의 분쟁 규칙서와 BPO SOP를 입력하여 3시간 걸리던 처리를 3초로 줄였고, 마스터카드 규정에서 2~3개의 추가 논점을 찾아내 더 강력한 분쟁 제기 서류를 만들었다고 설명합니다.

이 워크플로는 단일 프롬프트가 아니라 단계별 체인으로 구성되었을 개연성이 높습니다. 첫 단계에서는 분쟁 사유(부정 거래, 상품 미수령, 금액 상이 등)와 거래 메타데이터를 파싱하여 관련 마스터카드 규칙 장(chapter)을 벡터 검색 또는 인덱스 기반으로 추출합니다. 두 번째 단계에서는 고객이 제출한 소명 내용과 판매자의 거래 영수증 데이터를 규정 조항의 요건과 대조하여 승소 가능성이 높은 조항들을 매칭합니다. 세 번째 단계에서는 매칭된 규칙 번호와 인용 문구를 구조화된 분쟁 서식 양식에 맞추어 법적 설득력을 갖춘 공식 문서로 렌더링하고, 승인 시스템 API로 전송하는 방식으로 3초 내 종단 처리를 완성했을 것입니다.

7. 출처

* First Round Applied Intelligence — Agent + Human Ops: How AI is Changing Roles and Workflows at Brexhttps://www.firstround.com/ai/brex발행일: 2025-09-25(CTO James Reggio, COO Camilla Matias 인터뷰; 에이전트 플랫폼, L1/L2/L3 구조, 분쟁 3초, 100% AI QA, 4단계 AI Fluency)

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. 왜 이 사례인가

물리적 지점이 없는 100% 디지털 금융 서비스(챌린저 뱅크)에서 고객 지원은 부가 서비스가 아니라 은행 창구 그 자체입니다. 잔액 송금, 결제 승인 거절, 급여 입금 지연 등 고객이 지원팀을 찾는 상황은 대부분 즉각적인 해결이 요구되는 긴급 금융 이슈입니다.

캐나다의 디지털 핀테크 Neo Financial은 신용카드, 입출금 및 저축 계좌, 모기지 상품을 확장하며 급성장하는 과정에서 거대한 운영 병목에 직면했습니다. 약 20명의 지원 인력이 매달 약 5만 건에 달하는 인바운드 문의를 파편화된 도구(Zendesk, Amazon Connect)로 처리하고 있었으며, 활성 고객 수를 2배로 늘리려는 시점에서 기존의 선형적 인력 증원 방식은 막대한 운영 비용을 초래할 위기였습니다.

Neo는 단순한 FAQ 챗봇이 아닌 백엔드 금융 시스템과 직접 연동되는 AI 에이전트(Intercom Fin)를 프론트라인에 배치했습니다. 그 결과 채팅 유입의 96%에 에이전트가 개입하여 이 중 71%를 사람 없이 종단(end-to-end) 해결했고, 월 2만 건 이상의 문의를 무인 처리하며 고객 만족도(CSAT)를 86%까지 끌어올렸습니다. 이 사례는 고위험·고규제 금융 도메인에서 백엔드 데이터 연동형 AI 에이전트를 통해 ‘고객 2배 성장 시 비용 2배 증가’라는 선형적 비용 함정을 끊어낸 전형적인 성공 사례입니다.

2. Problem

디지털 은행 고객의 문의는 일반 이커머스 문의와 성격이 완전히 다릅니다. 생활비 결제 실패나 급여 미입금처럼 고객의 생계와 직결된 긴급한 사안이 많아 작은 오차나 지연도 즉각적인 신뢰 상실로 이어집니다.

Neo의 초기 지원 체계는 세 가지 핵심적 한계에 부딪혔습니다:

* 도구의 파편화와 높은 운영 복잡성: 티켓팅 도구(Zendesk)와 전화 상담 시스템(Amazon Connect)이 분리되어 있어, 상담원은 여러 화면을 오가며 고객 이력을 수동으로 조회해야 했습니다.

* 선형적 인력 확장의 한계: 20명의 상담원이 월 5만 건의 문의를 처리하는 한계 상황에서, 고객 수가 2배로 증가할 때 동일한 비율로 상담 인력을 채용하는 것은 재무적으로 지속 가능하지 않았습니다.

* 엄격한 금융 규제 및 컴플라이언스 제약: 금융 고객 데이터를 다루는 환경 특성상 PCI-DSS를 비롯한 엄격한 규제 가이드라인을 준수해야 했습니다. 기존 시스템에 구축된 보안 통제를 훼손하지 않으면서 새로운 자동화 체계를 도입해야 하는 높은 기술적 장벽이 존재했습니다.

확인된 사실: 지점 없는 100% 디지털 금융 환경, 약 20명의 지원 인력으로 월 약 5만 건 처리, Zendesk와 Amazon Connect로 나뉜 분절된 인프라, 3년 연속 Deloitte Fast 50 선정에 따른 급격한 고객 증가, 활성 고객 2배 확대 계획 직면.

3. Solution

Neo는 한 번에 전면 교체하는 모험을 피하고, 철저한 단계적 검증을 거쳐 헬프데스크 전체를 AI 퍼스트 환경으로 전환했습니다.

3.1 1단계: 실무 데이터 기반 파일럿 검증

Neo는 헬프데스크 전환에 앞서 기존 환경에서 Fin 에이전트를 먼저 시험 운용했습니다. 실제 고객 상담 대화 데이터를 투입해 답변의 정확도, 금융 규제 준수 여부, 계정별 맞춤 조회 능력을 검증했습니다.

* 도입 첫 주 만에 자동 완결률이 3~4%포인트 상승했습니다.

* 긍정 고객 만족도(CSAT)는 도입 전 약 50% 수준에서 약 75% 수준으로 즉각 반등했습니다.

* 운용 3개월 시점에 Fin이 직접 처리한 대화의 60%를 스스로 해결하는 안정성을 입증했습니다.

3.2 2단계: 무중단 하룻밤 헬프데스크 마이그레이션

파일럿 성과를 확인한 후, 기존 Zendesk 체제에서 Intercom과 Fin의 통합 환경으로 전환을 단행했습니다. 24시간 자금이 오가는 디지털 뱅킹 특성상 서비스 중단은 허용되지 않았습니다.

* AWS 마켓플레이스를 통해 도입 계약을 진행하여 기존 클라우드 인프라 자산과 연계했습니다.

* 벤더(Fin)의 구축 전담 조직과 협력하여 수년간 Zendesk에 축적된 PCI 규제 준수 워크플로와 과거 전체 티켓 이력을 사전 매핑했습니다.

* 고객 이용량이 적은 야간의 단일 점검 시간대를 활용해 무중단으로 전체 전환을 완료하고 익일 아침부터 정상 운영에 들어갔습니다.

3.3 3단계: 백엔드 코어 연동 및 프론트라인 배치

단순 텍스트 매칭 방식의 FAQ 챗봇과 달리, Fin 에이전트를 Neo의 핵심 금융 백엔드 시스템과 API로 연동했습니다:

* 계정별 상태 조회: 특정 결제가 왜 승인 거절되었는지, 송금 입금이 왜 지연(pending) 상태인지, 계정 인증을 어떻게 갱신해야 하는지 등 고객별 고유 데이터가 필요한 질문을 실시간으로 조회해 답변하도록 설계했습니다.

* 금융 규정 가드레일: 금융 컴플라이언스상 발언 가능한 문구와 발언이 금지된 표현을 엄격히 통제하는 지침을 부여했습니다.

* 원활한 상담원 핸드오프: 에이전트가 완결할 수 없거나 규정상 사람이 직접 처리해야 하는 사안은 즉시 대화 전문과 계정 맥락을 보존한 채 인간 상담원에게 실시간 전달되도록 구성했습니다.

확인된 사실: 실대화 파일럿 1주 차 CSAT 50%→75% 상승, 3개월 차 60% 자체 해결 달성, AWS Marketplace를 통한 조달, 단일 야간 무중단 마이그레이션 완료, 결제 보류·거절 사유 조회를 위한 금융 백엔드 API 연동, 맥락 보존 상담원 핸드오프.

4. Impact

Intercom Fin 고객 사례 원문에 공개된 측정 지표는 다음과 같습니다. 원문에는 구체적인 게시 일자가 명시되지 않았으며, 지표 확인 기준일은 2026년 9월 22일입니다.

원문은 특히 인바운드 문의의 채널 비중이 전화에서 채팅으로 이동(50%→70%)한 점을 강조합니다. 고객은 답변을 제대로 주지 않는 챗봇을 경험하면 즉시 전화로 이탈하지만, Fin이 대기 시간 없이 즉시 계좌 문제를 해결해 주면서 자발적인 채팅 선호가 형성되었습니다.

5. Insight

Neo Financial의 사례는 고객 접점 자동화에서 ‘정확성’과 ‘시스템 연동’이 만들어내는 운영 레버리지를 증명합니다.

FAQ 지식 베이스를 넘어선 백엔드 연동이 핵심입니다. 정적 문서만을 검색하는 에이전트는 금융 도메인에서 해결률 30%를 넘기기 어렵습니다. Neo는 결제 실패 코드, 송금 대기 상태 등 백엔드 상태값을 실시간으로 조회해 인출·안내하는 동적 데이터 연동을 구현함으로써 71%라는 높은 종단 완결률을 이끌어냈습니다.

고객 경험 개선이 유도한 채널 시프트에 주목해야 합니다. 콜센터 운영 비용은 텍스트 채팅 대비 통상 수배 이상 비쌉니다. 전화 상담을 강제로 축소하는 대신, 채팅 접점의 체감 완결 속도와 만족도를 높임으로써 고객 스스로 전화를 걸지 않고 채팅을 선택하게 만들었습니다.

인력 채용의 디커플링을 달성했습니다. 20여 명의 린한 인력으로 월 5만 건을 방어하면서, 향후 고객 기반이 2배로 늘어나더라도 지원 인력을 비례적으로 늘리지 않고 스케일할 수 있는 기반을 마련했습니다.

복제 조건과 한계. 이 사례의 핵심 전제는 고객 계정 상태를 안전하게 반환할 수 있는 표준화된 내부 뱅킹 API와 엄격한 인증 인프라입니다. 백엔드 시스템이 레거시 모놀리스로 닫혀 있거나 개인정보 식별(PII) 통제가 분리되어 있지 않은 조직에서는 에이전트가 실질적인 조회를 수행하지 못해 겉핥기식 안내에 그칠 위험이 있습니다.

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

6.1 계정별 결제 실패 및 보류 사유 조회를 위한 도구 호출(Tool Calling) 아키텍처

근거: 원문은 Fin이 Neo의 백엔드 시스템과 연동되어 특정 거래가 왜 승인 거절되었는지, 왜 보류 중인지와 같은 계정 고유의 질문에 답변한다고 기술합니다.

이 기능이 작동하기 위해서는 인앱 인증(SSO/JWT)을 거쳐 검증된 고객 ID가 대화 세션에 주입되는 구조가 선행되었을 것입니다. 고객이 “방금 마트에서 카드가 왜 긁히지 않았나요?”라고 입력하면, 에이전트는 지식 베이스 검색 대신 내부 트랜잭션 조회 도구(예: get_recent_declines(customer_id))를 호출하는 경로를 탑니다. 뱅킹 코어로부터 반환된 원시 에러 코드(예: ERR_INSUFFICIENT_FUNDS, ERR_CVV_MISMATCH, ERR_VELOCITY_LIMIT)를 수신한 뒤, 에이전트는 이를 금융 소비자 눈높이에 맞춘 정중하고 명확한 문장으로 변환하여 안내했을 가능성이 높습니다. 이 과정에서 잔액이나 카드 번호 같은 민감 정보는 마스킹(Masking) 처리된 채 전달되는 보안 프록시 계층이 필수적이었을 것으로 추정됩니다.

6.2 PCI-DSS 준수를 위한 하룻밤 컷오버 데이터 파이프라인

근거: 원문은 엄격한 규제와 PCI 의무를 준수하면서 Zendesk에서 Intercom으로 단일 야간 점검 시간 동안 무중단 전환을 완료했고, 과거 티켓 이력과 컴플라이언스 워크플로가 완벽히 이전되었다고 밝힙니다.

하룻밤 사이에 데이터 누락 없이 이전을 끝내기 위해서는 사전 동기화(Pre-sync) 파이프라인이 가동되었을 개연성이 큽니다. 수년간 쌓인 대용량 과거 티켓 데이터는 마이그레이션 수일 전부터 백그라운드 ETL을 통해 Intercom의 스키마에 맞추어 암호화 전송·적재해 두고, 점검 당일 밤에는 컷오버 시점 직전 수 시간 동안의 델타(변경분) 데이터만 최종 동기화하는 방식을 취했을 것입니다. 또한 PCI-DSS 요건에 따라 티켓 본문이나 첨부 파일에 포함되었을지 모르는 카드 번호(PAN) 등 결제 민감 정보를 탐지하여 토큰화하거나 마스킹하는 정제 작업이 마이그레이션 스크립트에 포함되었을 가능성이 매우 높습니다.

6.3 라이프사이클 마일스톤 기반 선제적(Proactive) 개입 트리거

근거: 원문 결미에서 Eunice Dunmade는 고객이 온보딩 라이프사이클의 한 단계에서 다음 단계로 5일 내에 도달하지 못할 때 에이전트가 먼저 다가가 도움을 제공하는 선제적 지원 체계를 준비 중이라고 언급합니다.

이러한 선제적 에이전트 워크플로는 백엔드 제품 분석 이벤트(예: 계좌 개설 완료 후 5일간 첫 입금 미발생)를 감지하는 내부 배치 작업이나 웹훅 트리거와 연동될 것으로 추정됩니다. 이벤트가 발생하면 고객 지원 시스템에 사전 정의된 아웃바운드 대화 컨텍스트가 생성되고, Fin 에이전트가 고객의 현재 상태(신분증 인증 통과 여부, 은행 계좌 연결 시도 실패 로그 등)를 조회하여 “계좌 개설을 완료하셨는데 첫 입금에 어려움이 있으신가요?”와 같이 맥락에 맞춘 선제적 메시지를 인앱 푸시나 메시지로 띄우는 형태로 구현될 수 있습니다.

7. 출처

* Intercom Fin Customer Stories — How Neo Financial built a support system that can double its customers without doubling costshttps://fin.ai/customers/neo게시일: unknown (확인일: 2026-09-22)(Eunice Dunmade Director of Customer Operations; 71% end-to-end resolution, 96% chat involvement, ~20k monthly resolutions, CSAT 86%)

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 코딩 에이전트를 도입할 때 흔히 겪는 성장통이 있습니다. 개발자 개인의 로컬 IDE에서 시작해 점차 백그라운드 자동화로 확장을 꾀하지만, 로컬 머신의 메모리·컴퓨팅 한계와 터미널 관리의 복잡성에 부딪힙니다. 일부 기술력 있는 기업들은 자체 클라우드 에이전트 인프라를 직접 구축(In-house)하는 길을 택하지만, 서버 프로비저닝, 샌드박스 보안, 도구 연동, 개발자 경험(DX) 유지보수에 막대한 엔지니어링 공수를 빼앗기며 ‘배보다 배꼽이 더 큰’ 상황에 직면합니다.

북미의 대표적인 B2B 도소매 이커머스 플랫폼 Faire의 전환 여정은 바로 이 지점에서 매우 명확한 기준점을 제시합니다. Faire는 자체 호스팅 인프라 기반으로 운영하던 사내 백그라운드 에이전트 시스템인 ‘사무라이(Samurai)‘를 과감히 폐기하고 상용 클라우드 에이전트 플랫폼인 Cursor로 전면 전환했습니다.

공개된 성과는 압도적입니다. 독립된 가상머신(VM) 환경을 갖춘 클라우드 에이전트를 대규모로 병렬 가동함으로써 주간 PR 처리량을 2배(2x)로 끌어올렸으며, 전체 엔지니어링 산출량은 2~3배에 육박하고 있습니다. 특히 팀 전체가 매달려 18개월이 걸릴 것으로 예상되었던 대규모 레거시 프론트엔드 마이그레이션(MobX → React 네이티브 상태 관리)을 단 1명의 엔지니어와 에이전트 플릿(fleet)의 협업으로 압축해 냈습니다.

아울러 개발자의 수동 프롬프트 입력 없이도 자동으로 동작하는 25개 이상의 상시 자동화(Cursor Automations)를 구축하여, 버그 트리아지·CI 자동 복구·코드 리뷰 라우팅 등에서 주당 2,000회 이상의 자율 에이전트 실행을 프로덕션에서 안정적으로 소화하고 있습니다. 엔지니어링 팀이 자체 인프라 관리 부담을 털어내고, 복잡한 개발 환경(Gradle, Bazel, AWS 권한 분리) 위에서 에이전트에게 온전한 개발 자율성을 부여한 대표적 모범 사례입니다.

2. Problem

Faire의 엔지니어링 조직이 직면했던 기술적·운영적 난관은 크게 세 가지였습니다.

2.1 로컬 에이전트 병렬화의 한계와 사내 인프라(Samurai)의 유지보수 부채

개발자 개인의 로컬 노트북에서 여러 에이전트를 동시에 실행하면 CPU와 메모리 자원이 순식간에 고갈됩니다. 터미널 창 10개를 띄워두고 각 작업의 진행 상태를 일일이 추적하는 것 자체가 또 다른 비효율적 노동이 되었습니다.

Faire의 루크 비어링(Luke Bjerring) 수석 엔지니어에 따르면, 회사는 이를 해결하기 위해 자체 호스팅 서버 위에서 동작하는 ‘사무라이(Samurai)‘라는 사내 백그라운드 에이전트 시스템을 직접 구축해 운용했습니다. 그러나 자체 서버 인프라를 유지하는 것은 엄청난 비용과 리소스를 요구했습니다. 서버 부트스트래핑, 머신 관리, 복잡한 가상화 인프라 유지보수를 위해 고급 엔지니어링 인력이 소모되었고, 정작 최종 고객에게 비즈니스 가치를 전달하는 본연의 제품 개발에 집중하지 못하는 본말전도가 발생했습니다.

2.2 이원화된 빌드 도구와 복잡한 엔터프라이즈 개발 환경

에이전트가 코드를 단순히 작성하는 것을 넘어, 빌드·테스트·검증까지 완결짓는 진정한 자율성을 갖추려면 사람 엔지니어와 동일한 완전한 개발 환경이 제공되어야 합니다. 그러나 Faire의 개발 환경은 고도로 파편화되어 있었습니다.

* 백엔드와 프론트엔드가 서로 분리된 저장소(separate repos)에 존재.

* 내부 패키지 의존성은 Gradle과 Bazel이라는 서로 다른 빌드 시스템으로 복잡하게 얽혀 있음.

* 사내 서비스 및 인프라 접근 권한이 서로 다른 AWS 자격 증명(credentials)으로 엄격히 격리되어 있음.

이처럼 복잡한 환경에서는 에이전트가 실행 포드나 컨테이너를 띄우더라도 필요한 도구체인을 설치하고 사내 내부 서비스에 접근하는 환경 구성(onboarding) 단계에서 빈번하게 실패할 수밖에 없었습니다.

2.3 18개월 규모의 레거시 마이그레이션과 반복적 잡무 병목

소매업체(retailer)가 매일 사용하는 핵심 웹 프론트엔드 애플리케이션 전반에 걸쳐 과거의 상태 관리 라이브러리인 MobX가 깊게 침투해 있었습니다. 이를 현대적인 React 네이티브 상태 관리로 전환하는 작업은 비즈니스 로직에 대한 섬세한 검증이 요구되면서도, 파일 수백 개를 일일이 수정해야 하는 전형적인 ‘고비용 노동 집약적’ 과제였습니다. 전체 엔지니어링 팀이 매달려도 최소 18개월이 소요될 것으로 추산되었습니다.

동시에 Slack 중심의 업무 환경에서 채널마다 쏟아지는 버그 리포트 분류, PR 생성 후 CI 파이프라인 실패 원인 분석, 코드 리뷰어 지정 및 라벨링과 같은 일상적이고 반복적인 엔지니어링 운영 업무가 개발자들의 집중 개발 시간을 지속적으로 잠식하고 있었습니다.

확인된 사실: 로컬 자원 제약 및 다중 터미널 관리 병목, 사내 에이전트 시스템 Samurai의 인프라 유지보수 부담, Gradle/Bazel/격리된 AWS 권한으로 인한 환경 구성 난제, 18개월 예상의 MobX 마이그레이션 부담, Slack 버그 트리아지 및 CI 실패 수동 대응에 따른 공수 소모.

3. Solution

Faire는 사내 시스템 Samurai를 과감히 걷어내고, 관리형 클라우드 에이전트 인프라와 상시 자동화 파이프라인을 유기적으로 결합했습니다.

3.1 관리형 클라우드 인프라로의 전환

Faire는 엔지니어가 인프라 구축 대신 제품 개발에 전념할 수 있도록 Cursor의 관리형 클라우드 인프라를 도입했습니다. 클라우드 에이전트는 로컬 자원 제약 없이 격리된 독립 가상머신(VM)에서 구동되므로, 개발자는 로컬 워크트리나 원격 터미널 세션 10개를 번거롭게 오갈 필요 없이 깔끔한 단일 대시보드에서 다수의 동시 에이전트를 직관적으로 지휘할 수 있게 되었습니다.

3.2 에이전트 주도 온보딩(Agent-led Onboarding)과 개발 환경 표준화

복잡한 Gradle·Bazel 빌드 환경과 AWS 권한 장벽을 해소하기 위해 에이전트 주도 온보딩 기능을 적용했습니다. 에이전트가 각 리포지토리를 스스로 탐색하여 필요한 도구체인과 의존성을 파악한 뒤, 팀이 버전 관리할 수 있는 환경 설정 파일(environment configuration)을 자동으로 생성하도록 했습니다. 엄격한 보안 통제가 필요한 워크플로의 경우 Dockerfile을 통해 개발 환경을 명시적으로 선언 및 관리했습니다.

이를 통해 에이전트는 독립 VM 환경에서 의존성을 내려받고, 사내 서비스와 통신하며, 코드를 빌드하고 테스트를 통과시키는 완전한 실행 루프를 사람의 개입 없이 스스로 완결할 수 있게 되었습니다.

3.3 디자인 시스템 연동과 Slack 기반 에이전트 호출

* 디자인 시스템 연동 (Playground): Faire 디자이너들이 사용하는 사내 도구 ‘Playground’(Figma 디자인을 React 코드로 변환) 서버를 클라우드 에이전트가 직접 띄울 수 있도록 구성했습니다. 에이전트는 React 컴포넌트를 코딩한 후, 디자이너가 브라우저에서 확인할 수 있도록 작업 결과 화면을 비디오 데모 영상으로 녹화하여 검토용으로 첨부합니다.

* Slack 기반 인라인 트리거: 엔지니어링 대화가 집중되는 Slack 채널 스레드에서 @cursor를 호출하면, 대화 맥락이 클라우드 에이전트로 즉각 전달됩니다. 개발자는 여러 도구를 오가지 않고도 몇 분 뒤 에이전트가 생성한 완성된 PR을 받아보게 됩니다.

3.4 25개 이상의 상시 자동화 (Cursor Automations)

사람의 수동 프롬프트 입력 없이 이벤트 기반으로 자율 실행되는 25개 이상의 자동화를 구축하여 주당 2,000회 이상의 에이전트 런을 가동했습니다.

* Slack 버그 트리아지: 지정된 Slack 채널의 장애 및 버그 보고를 실시간 모니터링하여, 클라우드 에이전트가 즉시 코드베이스를 조사하고 수정 PR을 생성한 뒤 요약 보고서를 회신.

* PR 자동 치유 (PR Auto-healing): PR 생성 후 CI 파이프라인이 깨지면 자동화가 즉시 트리거되어 빌드·테스트 로그를 분석하고, 수정 커밋을 푸시하여 PR을 정상화.

* 지능형 PR 라우팅: 생성된 PR의 작성자, 코드 변경 규모, 위험도를 정량 판별하여 맞춤형 코드 리뷰 워크플로로 자동 분기 배정.

3.5 대규모 마이그레이션 오케스트레이터 ‘Swarm’

MobX에서 React 네이티브 상태 관리로의 전환을 위해 ‘Swarm’이라는 전담 에이전트 조율 파이프라인을 구축했습니다.

* 코드베이스 전체를 스크래핑하여 MobX가 사용된 모든 지점을 전수 탐색한 뒤 S3에 작업 목록을 적재.

* Swarm 오케스트레이터가 S3 목록을 순차적으로 읽어 독립된 가상머신에서 실행되는 Cursor 클라우드 에이전트들에게 마이그레이션 태스크를 분할 할당.

* 한 에이전트가 작업을 완결하고 테스트를 통과하여 PR을 머지하면, Swarm이 즉시 다음 대상 파일을 에이전트 플릿에 연속적으로 디스패치.

3.6 플랫폼 엔지니어링 속도 혁신 (빌드 프리뷰 샌드박스)

블레어 맥알파인(Blair McAlpine) 시니어 플랫폼 엔지니어는 모든 PR마다 원격 인터랙티브 샌드박스를 띄워주는 프리뷰 도구를 개발할 때, Cursor의 계획 모드(Plan mode)를 활용했습니다. 단계별 계획을 수립하고 각 단계를 PR 단위로 나눈 뒤 클라우드 에이전트에 작업을 위임했습니다. 에이전트는 백그라운드에서 2시간 동안 자율 동작하며 5개의 연속된(stacked) PR을 생성했고, 수 주가 걸릴 것으로 예상되었던 도구 개발을 단 하루 만에 완성했습니다.

확인된 사실: Samurai 폐기 및 관리형 인프라 전환, 에이전트 주도 온보딩 및 Dockerfile 기반 환경 구성, Figma-Playground 비디오 데모 생성, Slack @cursor 연동, 25개 이상 상시 자동화와 주당 2,000+ 무인 런, S3 기반 MobX 마이그레이션 오케스트레이터 Swarm, 계획 모드를 통한 2시간 5개 스택 PR 생성 및 1일 내 프리뷰 도구 완성.

4. Impact

Faire가 달성한 생산성 지표와 리소스 절감 효과는 다음과 같습니다.

4.1 핵심 정량 성과

4.2 조직적 운영 효과

자체 에이전트 호스팅 인프라(Samurai)를 유지보수하기 위해 낭비되던 엔지니어링 리소스를 완전히 회수하여 비즈니스 핵심 가치 개발로 재배치했습니다. 엔지니어링 생산성이 2~3배로 폭증함에 따라, 개발 조직 내부의 병목이 코딩에서 인접 기획·디자인·배포 프로세스로 이동하기 시작했으며 회사는 확보된 생산성 여력을 바탕으로 보다 도전적인 제품 개발 과제에 인력을 재배치하고 있습니다.

5. Insight

자체 인프라 구축(In-house)의 유혹을 경계해야 합니다. 대규모 에이전트 실행 환경을 사내에서 직접 구축하는 것은 초기에는 매력적으로 보이지만, 격리 샌드박스 유지, 개발자 경험(DX), 버전 관리, 확장성에 막대한 유지보수 비용을 초래합니다. 엔지니어링 리소스는 인프라 유지가 아닌 최종 사용자 비즈니스 가치 창출에 투입되어야 합니다.

에이전트의 완성도는 ‘실행 가능한 환경(Environment)‘이 결정합니다. 코드를 그럴듯하게 작성하는 것과, 빌드 도구(Gradle/Bazel)를 돌려 사내 의존성을 풀고 테스트를 통과시키는 것은 차원이 다른 문제입니다. 에이전트가 독자적인 VM 환경에서 의존성과 권한을 완전히 통제할 수 있을 때 비로소 사람의 개입 없는 완결된 작업이 가능해집니다.

대규모 레거시 기술 부채 해소의 표준 공식이 재정의되었습니다. 수개월 이상 팀 전체를 소모시키던 프론트엔드 상태 관리 마이그레이션을 ‘S3 작업 큐 + 에이전트 플릿(Swarm)’ 구조로 분할 실행함으로써, 엔지니어 1명이 오케스트레이터 역할을 맡아 엔드투엔드로 완결할 수 있음을 입증했습니다.

개발자 트리거에서 ‘상시 무인 자동화’로의 전환이 진정한 레버리지를 만듭니다. 개발자가 채팅창에 프롬프트를 쳐서 작업을 시키는 단계를 넘어, Slack 버그 신고 감지, CI 실패 시 자동 픽스 커밋 푸시, PR 라우팅 등 이벤트 기반의 상시 자동화(Automations)가 뒷받침될 때 주당 2,000회라는 대규모 무인 자동화가 현실화됩니다.

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

6.1 S3 기반 마이그레이션 오케스트레이터 ‘Swarm’의 동시성 제어 및 상태 머신

근거: 원문에서는 스크래퍼가 코드베이스 내 모든 MobX 사용처를 탐색해 S3에 목록을 저장하고, Swarm이 이를 읽어 개별 격리 VM의 클라우드 에이전트에 작업을 위임하며, 한 작업이 완료되어 PR이 머지되면 다음 작업을 디스패치했다고 설명합니다.

실제 프로덕션 환경에서 수백 개에 달하는 프론트엔드 파일의 마이그레이션을 안정적으로 수행하려면 단순 순차 루프 이상의 동시성 및 충돌 제어 메커니즘이 필수적입니다. Swarm은 파일 간 의존성 그래프(AST 기반 import 분석)를 사전에 파악하여, 상호 참조가 없는 독립된 모듈군을 클라우드 에이전트에 병렬 할당했을 것입니다.

S3 버킷 내 작업 큐는 todo/, in-progress/, review/, done/ 형태의 접두사(prefix) 상태 머신으로 관리되었을 공산이 큽니다. 에이전트가 작업을 시작할 때 S3의 조건부 쓰기(Conditional Put)를 이용해 분산 락(Distributed Lock)을 획득하고 작업 브랜치를 분기합니다. 만약 다른 에이전트의 선행 머지로 인해 베이스 브랜치 충돌이 발생하면, 에이전트 VM 내부에서 자동으로 git rebase main을 시도하고 컴파일 및 단위 테스트(Bazel/Jest)를 재실행하도록 설계되었을 것입니다. 사람이 PR을 수동 승인하는 병목을 최소화하기 위해, MobX 데코레이터 제거 및 React Hook 대체 로직의 구문 트리 동등성 검증 테스트를 통과한 PR은 자동으로 머지 큐로 라우팅되도록 가드레일을 결합했을 것으로 추정됩니다.

6.2 다중 AWS 권한 및 Bazel/Gradle 캐싱을 결합한 클라우드 VM 프로비저닝

근거: 원문에서는 백엔드와 프론트엔드가 분리된 리포지토리에 있고, Gradle과 Bazel로 패키지 의존성이 관리되며, 엄격히 분리된 AWS 자격 증명 뒤에 보호되어 있어 환경 구성이 매우 까다로웠다고 명시합니다.

에이전트가 세션을 시작할 때마다 수 기가바이트에 달하는 사내 내부 패키지와 Bazel 빌드 캐시를 처음부터 다운로드한다면 세션 준비에만 수십 분이 소요되어 실시간 사용이 불가능해집니다. 따라서 Faire는 사내 빌드 인프라와 Cursor 환경 사이에 원격 빌드 캐시(Remote Build Cache) 및 전용 미러 레지스트리를 연결했을 가능성이 높습니다.

VM 부팅 시 Cursor의 사전 구성 스크립트(setup script)가 팀별 사전 빌드 스냅샷(prebuilt snapshot)을 마운트하고, AWS IAM 역할(AssumeRole)을 통해 에이전트에게 필요한 최소 권한의 임시 토큰을 세션별로 안전하게 주입하는 구조를 취했을 것입니다. 아울러 Bazel의 샌드박스 빌드 특성을 유지하면서 에이전트가 로컬에서 실행 결과를 검증할 수 있도록, 컨테이너 내부 Docker 소켓 바인딩이나 소스 트리 격리 설정을 환경 설정 파일에 템플릿화하여 표준 배포했을 것으로 추론됩니다.

6.3 Slack 기반 CI 실패 자동 복구(Auto-healing)의 진단 루프

근거: 원문에서는 CI 실패 시 Cursor Automations가 즉시 동작하여 원인을 조사하고, 수정 코드를 푸시하며, PR을 업데이트한다고 명시합니다. 또한 Slack 중심 문화에서 @cursor 호출이 일상화되어 있습니다.

이 자동 복구 파이프라인은 GitHub Actions 또는 사내 CI 시스템의 실패 웹훅(Webhook)에서 시작될 것입니다. 웹훅 페이로드가 수신되면 자동화 러너는 1) 실패한 CI 단계의 원시 콘솔 로그를 파싱하여 스택 트레이스와 컴파일 에러 라인을 추출하고, 2) 실패한 PR 브랜치를 체크아웃한 클라우드 에이전트 VM을 즉시 기동합니다.

에이전트는 단순히 에러 메시지만 보고 코드를 고치는 것이 아니라, VM 내에서 실패했던 동일한 Bazel/Gradle 테스트 명령어를 로컬로 재실행하여 실패를 재현(reproduce)합니다. 이후 코드 수정을 적용하고 로컬 테스트가 통과(Green)하는 것을 확인한 뒤에만 원격 브랜치로 git push를 수행하도록 엄격한 루프를 강제했을 것입니다. 작업이 완료되면 PR 코멘트 및 원본 Slack 스레드에 “CI 실패 원인(의존성 누락 또는 타입 불일치) …

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. 왜 이 사례인가

금융 및 핀테크 산업에서 고객 지원 자동화는 가장 매력적이면서도 가장 진입 장벽이 높은 영역입니다. 사소한 응답 오류나 환각이 금융 사고, 규제 위반, 고객 신뢰 상실로 직결되기 때문입니다. 많은 은행들이 단순 시나리오 기반 챗봇을 도입하지만, 복잡한 거래 분쟁이나 계좌 관리 요청이 들어오면 곧바로 인간 상담원에게 에스컬레이션되어 병목을 해소하지 못합니다.

유럽 2위의 네오뱅크인 붕크(bunq)가 AWS 머신러닝 블로그(2026년 1월 21일)를 통해 공개한 자사 생성형 AI 어시스턴트 ‘핀(Finn)‘의 멀티 에이전트 전환 사례는, 엔터프라이즈 규모에서 에이전트 시스템이 어떻게 라우팅 복잡성을 극복하고 확장성을 확보했는지를 명확히 보여줍니다. 2,000만 명의 유럽 고객을 보유한 bunq는 계좌 관리, 거래 분쟁, 환불 요청, 금융 조언에 이르는 전 과정을 에이전트에게 맡겼습니다.

공개된 성과는 압도적입니다. bunq의 독자 AI 어시스턴트 Finn은 현재 전체 고객 지원 업무의 97%를 처리하고 있으며, 이 중 70%~82%는 사람의 개입 없이 완전히 자동 완결(fully automated)됩니다. 평균 고객 응답 시간은 47초로 단축되었고, 38개 언어에 대한 앱 내 번역과 전 세계 은행권 최초의 지원팀 실시간 음성 대 음성(Speech-to-Speech) 통역을 지원하고 있습니다.

이 사례의 핵심 가치는 화려한 수치 이면에 있는 아키텍처 혁신에 있습니다. 초기 중앙 라우터 방식에서 발생한 단일 장애점과 확장성 한계를 인정하고, 3~5개의 프라이머리 에이전트가 특화 하위 에이전트를 도구(Tool)로 동적 호출하는 ‘에이전트 도구화(Agent-as-Tool)’ 패턴으로 재설계함으로써 3개월 만에 컨셉에서 프로덕션 상용화까지 도달했습니다.

2. Problem

2,000만 명의 다국적 사용자를 지원하는 bunq의 기술 조직이 직면했던 기술적·운영적 난관은 크게 세 가지였습니다.

2.1 금융 규제 준수와 즉시 응대 요구의 충돌

금융 서비스 특성상 고객은 결제 실패, 카드 도용 분쟁, 긴급 환불 등에 대해 24시간 365일 지연 없는 실시간 응대를 요구합니다. 그러나 금융 상품의 복잡성과 엄격한 개인정보보호(GDPR) 및 금융 보안 규제로 인해, 기존 규칙 기반 챗봇은 복합적인 금융 컨텍스트를 소화하지 못하고 대부분의 티켓을 수동 상담원 큐로 넘겼습니다. 이로 인해 상담 인력에 심각한 부하가 걸리고 고객 대기 시간이 길어졌습니다.

2.2 초기 중앙 라우터 아키텍처의 한계와 병목

bunq는 초기에 중앙 라우터 에이전트가 사용자 질문을 분석해 기술 지원, 일반 문의, 거래 상태, 계좌 관리 등 도메인별 특화 서브 에이전트로 전달하는 전형적인 계층형 라우터 패턴을 구축했습니다. 그러나 시스템이 커지면서 치명적인 세 가지 문제가 드러났습니다.

* 라우팅 복잡성 폭증: 특화 에이전트 수가 늘어날수록 중앙 라우터가 최종 목적지를 결정하기 위한 분류 로직이 기하급수적으로 복잡해졌습니다.

* 역할 및 데이터 소스 중복: 여러 하위 에이전트가 동일한 거래 내역이나 사용자 프로필 데이터에 접근해야 했기에, 라우터가 1차 의도뿐 아니라 후속으로 필요할 2차, 3차 에이전트까지 사전에 예측해야 하는 불가능한 과제에 직면했습니다.

* 확장성 병목과 단일 장애점: 새로운 기능이나 전용 에이전트를 추가할 때마다 중앙 라우터 로직을 수정하고 전면 재검증해야 했습니다. 중앙 라우터가 배포와 성능의 단일 장애점(SPOF)으로 전락했습니다.

2.3 다국어 및 실시간 지원의 기술적 장벽

유럽 전역 38개 언어를 구사하는 다국적 사용자들을 대상으로 문맥이 통하는 고품질 금융 지원을 제공하고, 음성 통화 시 실시간으로 통역을 지원하는 인프라를 지연 시간(latency) 없이 구축해야 했습니다.

3. Solution

bunq는 Amazon Bedrock과 완전 관리형 AWS 서비스를 활용해, 기존 중앙 라우터를 걷어내고 에이전트 도구화(Agent-as-Tool) 기반의 오케스트레이터 패턴으로 전면 재설계했습니다.

3.1 오케스트레이터와 에이전트 도구화(Agent-as-Tool) 패턴

중앙 라우터가 모든 경로를 예측하던 방식에서 벗어나, 상위 에이전트가 필요에 따라 특화 에이전트를 함수나 도구처럼 호출하는 구조를 도입했습니다.

* 오케스트레이터 간소화: Amazon ECS 위에서 구동되는 중앙 오케스트레이터는 사용자 쿼리를 모든 하위 에이전트로 분기하지 않고, 핵심 도메인을 대표하는 3~5개의 프라이머리 에이전트(Primary Agent)로만 라우팅합니다.

* 에이전트가 에이전트를 도구로 호출: 프라이머리 에이전트는 결제 실패나 거래 분석 등 특정 전문 지식이 필요하다고 판단하면, 사전에 정의된 표준 인터페이스를 통해 특화 서브 에이전트(Specialized Agent)를 직접 도구(Tool)로 동적 호출합니다.

* 예를 들어 결제 실패를 문의한 고객에 대해 프라이머리 에이전트가 쿼리를 접수하고, 거래 로그 분석 특화 에이전트를 호출해 원인을 조회한 뒤, 환불 규정 검색 에이전트를 호출해 통합된 답변을 수초 내에 구성합니다.

3.2 Amazon Bedrock 기반의 엔터프라이즈 보안 및 하이브리드 모델 스택

금융권의 엄격한 보안과 컴플라이언스 기준을 만족하기 위해 관리형 생성형 AI 플랫폼을 활용했습니다.

* Amazon Bedrock & Anthropic Claude: 단일 통합 API를 통해 Anthropic Claude 모델을 안전한 VPC 내에서 호출하여 복잡한 금융 자연어 이해 및 다단계 추론을 수행합니다.

* 도메인 특화 모델 결합: 일반 자연어 처리는 Bedrock을 거치되, 금융 도메인 특화 시나리오에는 Amazon SageMaker에 자체 미세조정(Fine-tuned)된 모델을 연동하여 정확도와 일관성을 보강했습니다.

3.3 실시간성 및 상태 관리를 위한 인프라 아키텍처

Finn의 초저지연 응답과 컨텍스트 유지를 위해 완전 관리형 클라우드 서비스를 유기적으로 결합했습니다.

* Amazon DynamoDB: 수 밀리초 단위의 초저지연 성능으로 에이전트 메모리, 세션 상태, 이전 대화 이력을 저장하여 장기 컨텍스트를 유지합니다.

* Amazon OpenSearch Serverless: bunq의 방대한 금융 지식베이스와 규정 문서를 벡터화하여 RAG(검색 증강 생성) 파이프라인의 시맨틱 검색을 전담합니다.

* Amazon ECS 기반 수평 확장: 오케스트레이터와 에이전트 런타임을 컨테이너화하여 트래픽 급증 시 자동으로 인스턴스를 확장합니다.

* 보안 및 감사 인프라: AWS WAF, Amazon CloudFront, AWS CloudTrail, GuardDuty를 결합해 모든 에이전트 호출과 금융 데이터 조회를 철저히 모니터링하고 컴플라이언스를 준수합니다.

4. Impact

bunq가 공개한 오케스트레이터 아키텍처 전환 성과는 다음과 같습니다. (수치 출처: AWS ML Blog, 2026-01-21)

bunq의 머신러닝 엔지니어링 리드 벤자민 클레페(Benjamin Kleppe)는 “과거에는 지원 에스컬레이션이 대부분 수동으로 이루어졌지만, 이제는 Finn이 전체 지원의 97%를 처리하고 47초 만에 응답한다”고 강조했습니다. bunq는 80명의 크로스 펑셔널 팀을 구성해 하루 3회 이상 프로덕션 업데이트를 진행하며 에이전트의 완성도를 높였습니다.

5. Insight

bunq의 아키텍처 전환은 복잡한 도메인에서 멀티 에이전트를 구축하려는 엔지니어링 팀에게 중요한 교훈을 제시합니다.

중앙 라우터의 한계를 인정해야 합니다. 모든 쿼리를 중앙에서 완벽히 분류하려는 단일 라우터 설계는 에이전트가 10개를 넘어가는 순간 유지보수 불가능한 병목이 됩니다. 상위 계층을 소수(3~5개)의 도메인 프라이머리로 제한하고, 하위 에이전트를 도구 인터페이스로 격리하는 ‘Agent-as-Tool’ 패턴이 엔터프라이즈 확장의 정답입니다.

금융 AI의 본질은 보안과 상태 관리입니다. 최신 LLM 성능만큼이나 중요한 것은 감사 추적(Audit Trail), 세션 메모리, 벡터 검색 인프라입니다. bunq는 DynamoDB와 OpenSearch Serverless를 통해 대화 상태와 지식베이스 검색을 분리하고, 완전 관리형 Bedrock을 통해 규제 준수 부담을 최소화했습니다.

프로덕션 배포 주기와 현장 피드백 루프. 3개월 만에 컨셉에서 상용화까지 도달할 수 있었던 원동력은 AI 엔지니어와 고객 지원 실무자가 원팀(80명)으로 묶여 하루 3번 프로덕션에 배포하는 기민한 이터레이션 구조에 있었습니다.

6. 구현 방식 추론 (Architectural Walkthrough)

6.1 근거: bunq는 ECS 상에서 구동되는 오케스트레이터가 3~5개의 프라이머리 에이전트로 쿼리를 라우팅하고, 프라이머리 에이전트가 전문 서브 에이전트를 도구(Tool)로 동적 호출한다고 밝혔습니다. 사용자 인텐트 해석 및 도구 디스패치 파이프라인은 JSON 스키마 기반의 함수 호출(Function Calling) 체인으로 구성되었을 가능성이 높습니다. 클라이언트 앱에서 고객의 메시지가 유입되면 Amazon ECS의 오케스트레이터 컨테이너가 세션 ID를 기반으로 DynamoDB에서 최근 대화 기록과 MemoryDB의 실시간 세션 캐시를 로드합니다. 오케스트레이터는 경량 프롬프트를 통해 쿼리를 계좌 관리, 카드/결제, 금융 인사이트 등 3~5개 프라이머리 도메인 중 하나로 분류합니다. 지정된 프라이머리 에이전트는 Amazon Bedrock의 Claude 인스턴스에 시스템 프롬프트와 함께 등록된 특화 서브 에이전트들의 Tool 명세(OpenAPI 스키마 형식)를 주입합니다. Claude가 추론 과정에서 invoke_dispute_analyzer(transaction_id=...)와 같은 도구 호출을 생성하면, 프라이머리 런타임이 해당 서브 에이전트 컨테이너로 gRPC 또는 내부 REST 요청을 전송하고, 반환된 분석 결과를 취합하여 최종 사용자 응답 텍스트를 완성하는 구조로 동작할 것으로 보입니다.

6.2 근거: bunq는 엄격한 보안 통제와 금융 규제 준수를 유지하면서 민감한 금융 거래를 처리하고, OpenSearch Serverless 기반의 RAG를 결합했다고 설명했습니다. 금융 데이터 격리와 가드레일은 다단계 보안 프록시 레이어로 구현되었을 것으로 분석됩니다. 사용자의 질문이 모델로 전달되기 전, 프라이머리 에이전트 전면의 데이터 마스킹 미들웨어가 계좌 번호, 카드 CVV, 주민등록 식별자 등 민감 PII 정보를 토큰화(tokenization)하거나 마스킹 처리합니다. 규정 및 지식 검색 단계에서는 OpenSearch Serverless의 k-NN 인덱스를 쿼리하여 관련 약관과 최신 금융 규정을 검색하되, 사용자 권한 범위(RBAC) 내의 문서만 필터링되도록 테넌트 격리가 적용됩니다. 금융 트랜잭션 실행(환불, 카드 일시정지 등)과 관련된 도구 호출의 경우, 에이전트가 직접 DB를 수정하지 않고 bunq의 코어 뱅킹 트랜잭션 API를 호출하며, 이 과정에서 2차 인증(Step-up Authentication) 플래그를 확인하고 모든 호출 파라미터를 AWS CloudTrail 및 내부 감사 로그에 불변(immutable) 기록하는 안전장치를 갖추었을 것으로 분석됩니다.

7. 출처

* AWS Machine Learning Blog — How bunq handles 97% of support with Amazon BedrockURL: https://aws.amazon.com/blogs/machine-learning/how-bunq-handles-97-of-support-with-amazon-bedrock/발행일: 2026-01-21저자: Benjamin Kleppe (ML Engineering Lead, bunq), Jagdeep Singh Soni (Senior AI/ML Solutions Architect, AWS), Guy Kfir (GenAI Lead, AWS)

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 도입 과정에서 가장 흔히 마주치는 실패 패턴은 직원들에게 코파일럿(Copilot) 도구를 쥐여주고 현장의 자발적 생산성 혁신을 기대하는 방식입니다. 내부 보조 도구는 초기 호기심이 지나면 현장 도입률이 떨어지기 쉽고, 비즈니스 핵심 지표나 손익계산서(P&L)로 연결되지 못한 채 흐지부지되기 일쑤입니다.

라틴아메리카 최대의 온라인 중고차 거래 플랫폼 카박(Kavak)의 창업자 겸 CEO 카를로스 가르시아 오타티(Carlos García Ottati)가 a16z 팟캐스트(2026년 2월 18일 공개)에서 밝힌 전사 전환기는 이 딜레마에 대해 매우 급진적이고 실증적인 해법을 제시합니다. 2021년 직원 수 1만 명, 연 300%에 달하는 초고속 성장을 구가하던 카박은 거시 경제 환경 변화와 글로벌 벤처 투자 시장 경색에 직면하며 현금 소진을 멈추고 자생력을 확보해야 하는 생존의 기로에 섰습니다.

카박은 2022년 말 전사 직원들을 지원하기 위해 다양한 내부 코파일럿 도구를 구축해 배포했습니다. 그러나 직원들의 실제 도입률은 사실상 바닥을 쳤습니다. 이에 카를로스 CEO는 코파일럿 사용을 억지로 독려하는 대신 정반대의 결단을 내렸습니다. 코파일럿 단계를 완전히 건너뛰고, AI 에이전트를 고객과 마주하는 최전선(front line)에 직접 배치하기로 한 것입니다.

그 과정에서 치른 대가는 혹독했습니다. 운영 체계를 전면 재구축하고 에이전트를 현장에 안착시키는 동안, 2021년 300%, 2022년 100%에 달하던 매출 성장률은 2023년 한 해 동안 완전한 제로 성장(flat)을 기록했습니다. 초기에는 에이전트의 응대 품질과 거래 전환율이 인간 직원에 미치지 못해 핵심 비즈니스 지표가 곤두박질쳤지만, 카박은 ‘실패 시 사람으로 회귀한다’는 플랜 B를 두지 않고 에이전트가 사람 수준을 넘어설 때까지 밀어붙였습니다.

결과는 극적이었습니다. 첫 번째 퍼널에서 인간 최고 성과자의 1.5배 퍼포먼스를 달성한 이후 전사 퍼널로 확산했고, 현재 카박은 고객 인터랙션의 90%~95%를 AI 에이전트가 직접 처리하고 있습니다. 직원 규모는 1만 명에서 약 3,500명으로 슬림해졌으며, 극심한 현금 소진 상태를 벗어나 흑자 전환을 달성했고 이후 매출은 저점 대비 4배로 다시 성장했습니다.

2. Problem

카박이 직면했던 운영 및 사업적 위기는 라틴아메리카 특유의 시장 불투명성과 네 개 이종 사업이 결합된 비즈니스 복잡성에서 비롯되었습니다.

2.1 4개 사업이 얽힌 복합 모델과 사내 정보 흐름의 병목

라틴아메리카의 중고차 시장은 극도로 비공식적입니다. 전체 거래의 90%가 개인 간 거래로 이루어지며, 거래의 약 40%가 사기, 도난, 서류 위조, 심지어 강력 범죄와 연루됩니다. 금융 환경도 열악하여 미국에서는 중고차의 90%가 대출로 판매되는 반면, 멕시코에서는 단 5%만이 금융 지원을 받습니다.

카박은 고객에게 신뢰할 수 있는 거래를 제공하기 위해 하나의 단일 플랫폼 아래 네 가지 이종 사업을 직접 수직 계열화했습니다.

* 온라인 차량 매입 및 판매 이커머스

* 대규모 차량 재상품화(Reconditioning) 및 보증 정비 공장

* 자체 대출 심사(Underwriting) 및 채권 회수 금융 엔진

* 차량 탁송 및 풀필먼트 물류

2021년까지 직원이 200명에서 1만 명으로 급증하면서 부서 간 정보 소통(information highway)은 극심한 병목에 직면했습니다. 차량 부품 청구 문제나 가격 책정 문의가 발생해도 현장 담당자가 누구에게 확인해야 할지 알 수 없었고, 차량마다 고유한 이력과 고장 원인이 얽힌 엣지 케이스(edge case)가 쏟아지며 고객 경험이 무너졌습니다.

2.2 내부 코파일럿 도구의 현장 도입 실패

2022년 말, 카박은 직원들이 고객 데이터를 빠르게 조회하고 응대 품질을 높일 수 있도록 대대적인 사내 코파일럿 도구를 구축했습니다. 그러나 현장 직원들은 익숙한 기존 작업 방식을 바꾸지 않았고 실질 도입률은 거의 0에 머물렀습니다. 아무리 정교한 데이터베이스와 지능형 검색 도구를 제공해도, 인간 작업자가 주도권을 쥐고 있는 워크플로에서는 자발적 변화가 일어나지 않는다는 점이 확인되었습니다.

2.3 자본 시장 경색과 맞물린 구조적 생존 압박

2021년 하반기 이후 글로벌 유동성이 급속히 마르면서 하루에 100만 달러 이상을 태우던 고비용 성장 모델은 지속될 수 없었습니다. 단순한 인원 감축만으로는 흑자 구조를 만들 수 없었고, 고정비를 획기적으로 낮추면서도 고객 응대와 운영 품질을 유지해야 하는 절체절명의 과제에 맞닥뜨렸습니다.

3. Solution

카박의 대응은 단순한 AI 도구 도입이 아니라, 회사의 핵심 비즈니스 퍼널 전체를 에이전트 중심으로 재설계하는 구조적 전환이었습니다.

3.1 코파일럿 폐기와 프론트라인 에이전트 직배치

직원 보조용 코파일럿이 실패하자, 카박은 에이전트를 백오피스 보조자가 아니라 고객과 직접 상호작용하는 프론트라인에 직결했습니다.

* 단순 FAQ 안내 같은 주변부 업무가 아니라 대출 심사(Underwriting)나 고장 보증 정비 신청 같은 거래의 핵심 퍼널부터 에이전트를 투입했습니다.

* 특정 퍼널에 에이전트를 투입할 때 ‘성과가 안 나오면 사람을 다시 채용한다’는 플랜 B를 두지 않았습니다. 전사 엔지니어링 리소스를 투입하여 에이전트가 최소한 인간 수준의 성과를 낼 때까지 튜닝에 집중했습니다.

3.2 2017년부터 준비된 전사 데이터 온톨로지(Ontology) 기반

카박이 초기에 에이전트를 신속하게 띄울 수 있었던 핵심 자산은 2017년부터 준비해 온 데이터 온톨로지였습니다.

* 2017년 카를로스 CEO는 인간 채용 파이프라인과 함께 ‘로봇 파이프라인(Robot 1: 조달, Robot 2: 고객 만족, Robot 3: 교차 판매)‘을 구축하겠다는 전사 메모를 배포했습니다.

* 가격 책정(6만 개 이상의 독자적 SKU 특성 학습), 보증 정비(부품 고장 시점의 실측 데이터 축적), 금융 심사 등 전사 데이터 파이프라인을 사전에 구조화해 두었기 때문에, 2022년 말 파운데이션 모델 등장 시 즉시 비즈니스 컨텍스트를 에이전트에 공급할 수 있었습니다.

3.3 오케스트레이터 기반 인간-에이전트 협업 구조

에이전트가 모든 상황을 100% 무인 처리하는 것이 아니라 복잡도에 따라 유연하게 역할을 분담하는 공생 구조를 취했습니다.

* 오케스트레이터(Orchestrator): 인입되는 고객 요청과 상황의 복잡도를 실시간으로 판별합니다.

* 표준적이고 반복적인 대출 서류 검토, 초기 상담, 상태 조회는 에이전트가 자율 완결합니다.

* 복잡한 분쟁이나 보증 수리 예외 상황은 오케스트레이터가 인간 전문가에게 라우팅하여 에이전트와 인간 직원이 상호 보완적으로 작동하도록 설계했습니다.

3.4 ‘ChatGPT 7을 내다보는 인프라 설계’ 철학

카박 엔지니어링 팀은 개별 에이전트의 파라미터 미세 조정에 매몰되지 않는 원칙을 세웠습니다.

* 특정 퍼널에서 인간 최고 성과자의 1.5배 수준에 도달하면, 이를 7배로 끌어올리기 위한 자체 튜닝에 시간을 쓰지 않고 즉시 다음 비즈니스 퍼널로 에이전트를 확장했습니다.

* 기반 모델(Foundation Model) 자체의 진화 속도가 자체 엔지니어링 속도보다 훨씬 빠르기 때문에, ‘GPT-4가 아니라 미래의 GPT-7을 맞이할 수 있는 데이터 파이프라인과 안전장치(브레이크)‘를 정비하는 데 집중했습니다.

4. Impact

카박이 공개한 전환 성과는 비즈니스 체질의 완전한 탈바꿈을 보여줍니다. (수치 출처: a16z 팟캐스트, 2026-02-18 인터뷰)

카를로스 CEO는 이 전환 과정을 넷플릭스가 DVD 우편 대여에서 스트리밍으로 전환했던 과정에 비유했습니다. 전통적인 소프트웨어 운영 방식에 안주하지 않고, 1년간의 고통스러운 성장 정체와 지표 하락을 감내하며 핵심 퍼널 전체를 에이전트로 전환한 결과 생존을 넘어 구조적 흑자 기업으로 자리잡았습니다.

5. Insight

카박 사례는 AI 에이전트 전환을 추진하는 기업들에게 몇 가지 핵심 교훈을 제공합니다.

코파일럿이라는 안전지대의 한계. 많은 조직이 구성원의 저항을 줄이기 위해 코파일럿 방식을 택합니다. 하지만 코파일럿은 기존 업무 관성을 깨지 못하며 실질 채택률 저하로 이어집니다. 명확한 비즈니스 임팩트를 만들기 위해서는 고객 접점에 에이전트를 직배치하고, 측정 가능한 비즈니스 결과(전환율, 승인율)를 기준으로 평가해야 합니다.

초기 성능 하락 곡선을 버티는 리더십. AI 에이전트를 실무에 투입하면 첫 몇 주 또는 몇 달 동안 고객 경험 지표와 매출 지표가 일시적으로 곤두박질칩니다. 카박은 1년 동안 성장이 멈추는 극심한 압박 속에서도 사람을 다시 채용하는 손쉬운 타협을 거부하고, 엔지니어링 팀이 에이전트 성능을 인간 수준 이상으로 올릴 때까지 버텼습니다.

온톨로지와 데이터 인프라의 선행. 에이전트 도입의 성패는 프롬프트 작성 기술이 아니라 도메인 데이터 온톨로지에 달려 있습니다. 카박은 2017년부터 차량 가격 데이터, 고장 수리 이력, 대출 상환 이력을 구조화해 두었기에 에이전트가 복잡한 엣지 케이스를 판정할 수 있었습니다.

6. 구현 방식 추론 (Architectural Walkthrough)

6.1 근거: 카박은 4개 사업(이커머스, 정비/보증, 금융 대출, 물류)의 방대한 데이터 온톨로지를 사전에 구축했으며, 오케스트레이터가 인간과 에이전트 간의 역할 분담을 조율하고 엣지 케이스를 처리한다고 밝혔습니다. 카박의 에이전트 아키텍처는 전사 이벤트 버스를 중심으로 구성되었을 가능성이 높습니다. 고객이 웹이나 모바일 앱, 또는 메신저를 통해 차량 구매나 대출 신청, 보증 수리를 문의하면, 중앙 오케스트레이터가 고객 세션 컨텍스트와 차량 식별 번호(VIN) 기반 이력 데이터를 결합합니다. 온톨로지 서비스는 6만 개 이상의 차량 SKU 가격 모델과 과거 유사 차종의 고장 부품 통계를 에이전트의 컨텍스트 윈도우에 구조화된 JSON 형태로 주입합니다. 대출 심사 퍼널의 경우, 사용자가 제출한 신분증 및 소득 증빙 문서를 비전 에이전트가 검증하고, 위조 서류 탐지 룰 엔진과 신용 평가 모델 API를 호출하여 1차 승인 여부를 결정합니다. 승인 점수가 임계치 경계에 있거나 사기 위험 점수가 높게 감지되는 예외 건은 즉시 오케스트레이터가 예외 큐(Exception Queue)로 격리하여 인간 금융 심사역의 승인 콘솔로 전달됩니다.

6.2 근거: 카박은 “시스템의 브레이크(안전장치)“를 가장 먼저 구축해야 한다고 강조했으며, 자체적인 무리한 성능 극대화 대신 기반 모델의 발전에 대비하는 설계를 취했다고 밝혔습니다. 에이전트 런타임 레이어에서는 환각(hallucination) 방지와 거래 안전성을 담보하기 위해 다중 가드레일이 적용되었을 것으로 분석됩니다. 차량 가격이나 보증 적용 범위, 대출 금리와 같은 법적·재무적 구속력이 있는 출력에 대해서는 에이전트가 자유 형식 텍스트를 직접 생성하지 않고, 사전 정의된 엄격한 스키마 기반의 도구 호출(Tool Calling / Function Calling)만을 수행하도록 통제합니다. 에이전트의 파라미터는 백엔드 트랜잭션 서비스에서 이중 유효성 검사(validation)를 거친 후 데이터베이스에 커밋됩니다. 또한 기반 모델 교체 시 워크플로가 깨지지 않도록 비즈니스 로직과 모델 프롬프트를 분리하는 추상화 계층을 두어, 상위 모델 업데이트 시 프롬프트 엔지니어링 비용을 최소화하면서 즉각적인 성능 향상을 흡수하도록 구성했을 것으로 추정됩니다.

7. 출처

* a16z Podcast — From Copilots to Agents: Rebuilding the Company Around AIURL: https://a16z.com/podcast/from-copilots-to-agents-rebuilding-the-company-around-ai/발행일: 2026-02-18출연: Angela Strange, Gabriel Vasquez, Carlos García Ottati (Kavak Founder & CEO)

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. 왜 이 사례인가

많은 조직이 코딩 에이전트를 IDE 안에서 질문에 답해 주는 페어 프로그래머 정도로만 씁니다. 하지만 monday.com이 AWS ML Blog를 통해 공개한 내부 에이전트 시스템 Sphera AI Teammates는 작업 범위를 그 바깥으로 과감히 넓혔습니다. 에이전트를 조직도에 실재하는 팀원(teammate) 으로 등록하고, Slack·monday·GitHub 인박스에서 티켓을 직접 할당받아 PR을 열게 한 뒤, 자동화된 가드레일(Guardrails)과 원격 샌드박스를 거쳐 머지까지 완결 짓는 구조를 갖췄습니다.

AWS 블로그에 공개된 내부 프로덕션 데이터는 인상적입니다. 엔지니어·PM·애널리스트·프로덕트 디자이너를 아우르는 빌더(Builder) 10명 중 9명이 매달 AI 코딩 도구를 활용하고 있으며(1년 전 약 절반 수준에서 상승), 엔지니어 1인당 PR 처리량은 50% 이상 증가했습니다. 10년 넘게 다듬어진 레거시 코드베이스, 수백 개의 마이크로프론트엔드와 마이크로서비스, 수백 명의 빌더가 일하는 대규모 환경에서 실제로 거둔 성과입니다.

이 사례의 중심축에는 티켓을 직접 가져와 PR을 열고 기능을 배포하는 소프트웨어 엔지니어 에이전트 Atlas, 그리고 그 위에서 20건 중 19건을 자동으로 머지하는 Morphex가 있습니다. L1(개인 어시스턴트)에서 L2(스킬·서브에이전트)를 거쳐 L3(엔드투엔드 멀티에이전트)로 이어지는 성숙도 프레임, SNS→SQS→EKS로 흐르는 이벤트 파이프라인, 벡터 데이터베이스 대신 EFS 파일시스템에 보관하는 MEMORY.md와 업무 일기, Amazon Bedrock 기반의 런타임, 다섯 가지 아키텍처 개편(retrofit), 그리고 신뢰도 점수 기반 자동 머지(confidence-scored automatic merging)가 하나의 유기적인 파이프라인으로 연결되어 있습니다.

2. Problem

monday.com의 환경은 가볍게 실험해보는 신규 그린필드 프로젝트가 아닙니다. AWS 기술 블로그에서 밝히듯, 10년 된 코드베이스, 수백만 명의 유료 사용자, 수백 개의 마이크로프론트엔드와 마이크로서비스, 24시간 온콜과 엄격한 컴플라이언스가 전제된 라이브 서비스입니다. 에이전트가 발행한 PR 하나라도 프로덕션의 안정성을 해쳐서는 안 되는 환경이었습니다.

초기 Atlas는 겉보기에 그럴듯한 수준으로 PR을 생성하는 데 집중했습니다. 하지만 처리하는 작업량이 늘어나자 한계가 곧바로 드러났습니다. 로컬 테스트는 통과했지만 CI 파이프라인에서 실패하는 PR, 담당 팀의 승인이나 맥락이 누락된 PR, 사람이 일일이 검토해야 하는 리뷰 병목, 세션이 끝나면 직전 작업 맥락을 잊어버리는 세션 간 기억 상실 문제가 잇따랐습니다. 벡터 데이터베이스 검색이나 컨텍스트 스터핑(context stuffing) 같은 기법도 이 문제를 해결하지 못했습니다. 결국 2026년 1분기 말에 이르러 시스템의 병목은 코드 작성이 아니라 사람의 코드 리뷰로 옮겨갔습니다. PR Guardrails가 문제 소지가 있는 코드를 사전에 자동으로 걸러냈지만, 최종 머지 단계에서는 여전히 모든 PR이 사람의 승인 큐에 머물러 있었습니다.

확인된 사실: 대규모 레거시 SaaS 환경, 현재 대다수 워크로드가 L2 단계에서 운영되며 엔지니어당 PR 처리량 50% 이상 증가, Atlas 초기 버전의 품질·기억·CI 안정성 격차, 사람 리뷰 단계의 병목, 사람 리뷰에 도달하기 전 PR의 약 1/4을 차단하는 Guardrails 필터.

3. Solution

3.1 Sphera와 팀원 스키마

Sphera는 monday.com의 사내 에이전트 플랫폼입니다. 사내 Teams 페이지를 열면 동료 직원들과 에이전트가 나란히 등록되어 있으며, 에이전트 역시 직무 프로필, 직속 매니저, 담당 업무 스코프, 성과 점수를 부여받습니다. 그중 Atlas는 직무가 Software Engineer로 정의되어 있으며, 백로그에서 티켓을 가져와 PR을 작성하고 기능을 배포하는 역할을 맡습니다. 별도의 IDE 환경 없이 동작하며 사람 동료들과 같은 백로그를 공유합니다.

에이전트마다 Slack, GitHub, monday.com 전반을 관통하는 안정적인 계정 식별자(identity)가 부여되어 있습니다. 따라서 동료 엔지니어는 일반 팀원을 대하듯 에이전트를 멘션하고, 작업을 할당하고, 코드 리뷰를 요청하거나 필요 시 계정을 비활성화할 수 있습니다. 별도의 거버넌스 층을 새로 얹지 않고, monday.com이 이미 구축해 둔 기존 인증, RBAC 권한 체계, 배포 파이프라인을 그대로 활용합니다.

3.2 세 개의 인박스, 하나의 세션

에이전트는 세 가지 1급(first-class) 인박스를 모니터링합니다. Slack @mention, monday.com 업무 아이템 할당, GitHub PR 리뷰 요청입니다. 세 경로로 들어오는 모든 요청은 채널별로 파편화되지 않고 동일한 에이전트 세션, 즉 같은 메모리와 디스크 작업 공간으로 합류합니다. 목적에 따라 에이전트 시스템을 분리하는 대신 하나의 통합 큐와 단일 처리 경로로 묶어낸 구조입니다.

3.3 SNS → SQS → EKS (Builders CoWORK)

외부 인박스에서 발생하는 트리거 이벤트는 Amazon SNS로 먼저 수신되며, 토픽과 라우팅 키를 거쳐 팀별 전용 큐인 per-team SQS로 분기(fan-out)됩니다. EKS 클러스터 위에서 동작하는 SQS 컨슈머인 monday Builders CoWORK가 메시지를 폴링하여 담당 에이전트를 지정하고, 해당 agent runner pod에 작업을 전달합니다.

이러한 메시징 큐 기반 아키텍처는 자동 재시도와 데드 레터 큐(DLQ)를 통한 장애 격리, Amazon Bedrock API 호출 스로틀링 발생 시의 배압(back-pressure) 제어, 신규 버전 배포 전 과거 하루치 이벤트 재실행(replay) 검증, 대규모 동시 분기 처리를 안정적으로 지원합니다. 향후 Claude Agent SDK 등 하부 런타임이 변경되더라도 monday.com 측의 실행 래퍼만 교체하면 기존 하네스(harness) 환경은 그대로 유지할 수 있습니다.

3.4 monday-agent-sdk와 상태 계층

monday-agent-sdk는 Claude Agent SDK를 얇게 감싼 내부 라이브러리입니다. 모델 호출부를 Amazon Bedrock으로 라우팅하고, 미리 준비된 node_modules와 플러그인 캐시를 활용해 콜드 스타트를 단축함으로써 첫 모델 호출 시간을 통상 1초 미만으로 낮춥니다. 아울러 평가(eval) 체계, 플러그인 인터페이스, Slack·monday·GitHub 연동, 사내 리뷰 표준을 통합한 하네스(harness)를 통해 monday.com 고유의 엔지니어링 규칙을 일관되게 주입합니다.

시스템 상태는 영속성과 용도에 따라 세 계층으로 관리됩니다.

POSIX 파일시스템 호환이 필요한 Amazon EFS를 채택한 이유는 분명합니다. Claude Agent SDK와 각종 CLI 도구가 git, npm, 로컬 파일 편집 등 표준 POSIX 파일시스템 인터페이스를 전제로 동작하기 때문입니다. 아울러 실행 포드가 교체되더라도 새로 뜬 EKS 포드가 동일한 EFS 볼륨 경로를 즉시 마운트하여 직전 세션 작업을 중단 없이 이어받을 수 있습니다. Atlas의 작업 메모리는 벡터 DB 대신 읽고 쓰기 쉬운 마크다운 파일 형태로 유지됩니다.

3.5 Amazon Bedrock과 인프라 확장

Amazon Bedrock은 단순한 언어 모델 API 제공처 이상의 엔터프라이즈 운영 기반으로 작동합니다. Application Inference Profiles를 적용해 팀 및 프로젝트 단위로 비용과 사용량을 정밀하게 추적하고, 모델 호출 내역을 단일 감사 추적(audit trail) 로그로 남기며, 특정 리전에서 처리량 제한(throttling)이 발생하면 자동으로 우회하는 크로스 리전 장애 조치(cross-Region failover)를 수행합니다. 외부망 노출 없는 보안 통신을 위해 VPC 내부 트래픽은 AWS PrivateLink로 격리했습니다.

EKS 런타임 계층은 활성 세션당 1개의 독립 포드를 할당하고 EFS 볼륨을 마운트하는 단순한 구조를 유지합니다. 복잡한 서비스 메시나 오케스트레이터를 덧붙이지 않고, Datadog의 활성 세션 메트릭을 기반으로 KEDA(Kubernetes Event-driven Autoscaling)가 포드 수를 오토스케일링합니다. 부하 분산과 내구성은 검증된 EKS, SQS, 캐시 계층이 직접 지탱합니다.

3.6 프로덕션 전환을 이끈 다섯 가지 아키텍처 개편

* 모델 교체 전 평가 체계 선행(Evals before model upgrades): PR 머지율, 리버트율, 무수정 머지율(zero-touch merge) 같은 결정론적 소프트웨어 메트릭에 더해, PR마다 LLM이 채점하는 5대 차원 평가(Intent & Decision, Execution & Artifact, Completeness & Usefulness, Instruction & Boundary, Efficiency)를 하네스에 도입했습니다. 기반 모델이나 프롬프트를 바꾸지 않고 평가 기준(eval)을 정교화하는 것만으로도 에이전트의 산출물 품질 점수가 눈에 띄게 개선되었습니다.

* 벡터 검색 대신 파일 기반 메모리(Memory is a file, not a vector store): 복잡한 임베딩 파이프라인이나 에이전틱 RAG 대신 MEMORY.md와 업무 일기 마크다운 파일을 선택했습니다. 세션 간 기억 유지가 훨씬 명확하고 유지보수하기 쉬워졌습니다.

* 인간 리뷰 전 원격 샌드박스 검증(Remote sandbox before human review): 세션마다 전용 원격 샌드박스를 띄워 에이전트가 만든 PR을 자동 배포하고, 실제 프로덕션 환경의 피처 플래그, 연동 서드파티 서비스, 트래픽 조건을 재현해 기능이 정상 동작함을 확인한 뒤에만 동료 엔지니어에게 리뷰를 요청합니다.

* 엔지니어링 표준을 코드로 검증하는 PR Guardrails: 사내 엔지니어링 표준을 자동 코드 리뷰어로 구현했습니다. MCP(Model Context Protocol)를 통해 각 표준을 관리하는 플랫폼 팀과 동일한 최신 맥락을 참조합니다. 현재 월 수만 건의 PR과 수십만 건의 표준 검사를 처리하고 있으며, 전체 PR의 약 1/5이 최소 1개 이상의 기준을 통과하지 못해 반려됩니다. 이 과정에서 사람이 개입해 결과를 뒤집는 오버라이드(override) 비율은 낮은 한 자릿수(low single digits) 퍼센트에 불과합니다.

* monday 보드를 공유 상태로 활용하는 Builders CoWORK: 에이전트의 세부 작업 현황, 블로커, 핸드오프 상태를 엔지니어링 팀이 일상적으로 사용하는 동일한 monday 보드에 기록합니다. 이를 통해 “어느 팀 담당인지 불명확한 미아 PR”이 발생하는 구조적 실패 모드를 업무 협업 도구 자체의 기능으로 해결했습니다.

확인된 사실: 상기 명시된 아키텍처 구성, 다섯 가지 개편 내역, Atlas의 업무 일기 스니펫, SDK 비공개 유지 방침(런타임 래퍼 자체보다 내부 하네스, monday 보드 연동, MCP, 인증 및 배포 통합의 가치가 핵심).

4. Impact

Morphex가 달성한 20건 중 19건의 자동 머지는 결코 코드 리뷰를 무단 생략한 결과가 아닙니다. Guardrails 검증, 원격 샌드박스 동작 테스트, 정량적 평가 점수, 변경 영역별 과거 리버트 이력 분석을 모두 무결하게 통과한 작업에 한해 사람의 손을 거치지 않고 최종 배포까지 이어지도록 설계한 결실입니다.

신뢰도 점수 기반 자동 머지 (Confidence-scored automatic merging)

에이전트가 PR을 제출하는 즉시 시스템은 네 가지 핵심 품질 신호를 종합해 신뢰도 점수를 산출합니다.

* Guardrails 차단(blocking) 필수 표준의 100% 통과 여부

* 해당 에이전트 빌드 버전의 평가 점수 추이(eval trajectory)

* 세분화된 (agent × repo × change-class) 단위의 과거 리버트 이력

* 원격 샌드박스 테스트 통과(Remote sandbox green, 필수조건이나 단독으로는 불충분)

합산된 점수가 사전에 정의된 안전 임계값을 넘어서면 PR은 즉시 자동으로 머지되며, 기준에 미달하면 감점 사유와 함께 사람 엔지니어의 리뷰 큐로 라우팅됩니다. monday.com이 추구하는 핵심 운영 지표는 리버트율을 기존처럼 낮은 한 자릿수 이하로 유지하거나 개선하면서, 사람의 개입 없이 머지되는 에이전트 PR의 비중을 꾸준히 늘려가는 것입니다.

확인된 사실: 표에 정리된 핵심 지표, 4대 평가 신호 체계, L2에서 L3로의 운영 전이. SDK는 오픈소스로 공개하지 않음(기본 런타임 래퍼는 단순하며, 실제 엔지니어링 가치는 하네스, 사내 보드 통합, MCP 인터페이스, 권한 체계 및 배포 파이프라인의 결합에 있음).

5. Insight

L1→L2→L3는 단순한 기술 도입 순서가 아니라 조직 운영 모델의 전환입니다. 실제 엔지니어당 PR 처리량 50% 향상이라는 가시적인 생산성 혁신은 L2(재사용 가능한 엔지니어링 스킬과 서브에이전트) 단계에서 본격화되었습니다. L3 단계의 자율 에이전트 Morphex 역시 사람을 무조건 배제하는 것이 아니라, 엄격한 신뢰도 점수 기준을 통과한 조건부 케이스에 한해 점진적으로 사람의 개입을 줄여가는 방식으로 안착했습니다.

복잡한 벡터 검색보다 단순하고 투명한 파일 시스템이 효과적이었습니다. 다음 세션으로 넘어가면 이전 맥락을 유실하던 문제는 무거운 벡터 DB 검색이나 RAG보다 EFS 위의 MEMORY.md와 업무 일기 마크다운 파일로 명료하게 해결되었습니다. monday.com 팀 스스로도 초기에 벡터 기반 솔루션에 과도하게 투자했다가 이를 다시 걷어냈다고 솔직하게 회고합니다.

가드레일의 역할은 인간 리뷰의 전면 대체가 아닌 선행 여과입니다. 전체 PR의 약 1/4을 사람에게 전달되기 전에 기계적으로 걸러내어 최종 머지된 코드의 리버트율을 한 자릿수 초반으로 낮춰 두었기에, 비로소 다음 단계인 신뢰도 기반 자동 머지를 도입할 여력이 생겼습니다.

협업 도구의 업무 보드가 곧 시스템의 상태 저장소(state store)가 됩니다. CoWORK 시스템의 작업 상태를 별도의 독립 관리용 대시보드가 아니라 사내 엔지니어들이 상시 확인하는 monday 보드 위에 직접 구성한 점이 주효했습니다. 엔지니어링 팀은 이를 뒤늦게 고친 땜질 처방이 아니라 처음부터 선택했어야 할 가장 중요한 아키텍처적 결정이었다고 평가합니다.

평가 체계(Eval) 구축은 프로젝트 성숙기가 아닌 첫날(Day 1)부터 시작해야 합니다. Atlas의 5대 품질 지표 점수는 모델 자체를 업그레이드하기 전, 하네스 내부의 정량적 평가 기준을 정립하는 것만으로도 즉각적인 개선을 보였습니다.

요약하자면, 엔터프라이즈 환경에서 코딩 에이전트를 성공적으로 스케일링하는 열쇠는 더 뛰어난 파운데이션 모델의 선택에만 머물지 않습니다. 안정적인 이벤트 큐, 파일 기반 메모리, 자동화된 표준 검사 가드레일, 공유 보드 상태 머신, 그리고 정량적 신뢰도 기반 머지 파이프라인이 단일 하네스 체계 안에서 빈틈없이 맞물려 돌아갈 때 비로소 지속 가능한 운영이 가능해집니다.

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

6.1 평가 게이트를 프로모션 파이프라인과 결합한 배포 자동화

근거: AWS 공식 블로그에서는 머지율, 리버트율, 무수정 머지율 등 결정론적 지표와 LLM 기반 5대 차원 평가를 하네스에 통합했으며, 모델이나 프롬프트 수정 없이 평가 기준을 보정하는 것만으로도 Atlas의 점수가 개선되었다고 설명합니다. 아울러 신규 빌드 프로모션 직전 “과거 하루치 이벤트의 재실행(replay)” 절차를 거친다고 명시하고 있습니다.

신규 하네스 빌드는 전체 운영 환경에 곧바로 적용되지 않고 스테이징 에이전트 풀(staging agent pool)에 먼저 격리 배포될 가능성이 높습니다. 그다음 재생 전용 큐를 통해 전날 실제 프로덕션에서 발생했던 Amazon SNS 이벤트를 동일하게 재실행하며, 이때 기록되는 PR 머지율, Guardrails 반려율, 5차원 품질 점수 분포를 기준선(baseline)과 자동으로 비교 분석할 것입니다. 결정론적 안정성 지표 중 하나라도 허용 오차를 벗어나면 배포는 즉시 롤백되며, LLM 평가의 경우 시스템 …

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 도입 열풍 속에서 많은 기업이 ‘전사적인 LLM 보급’을 성공적인 AI 전환으로 오인합니다. 유료 계정을 지급하고 전사 사용률이 90%를 넘겼다는 수치를 내세우지만, 정작 실질적인 매출 지표나 업무 방식의 근본적 변화로 이어지지 못하고 ‘고비용 장난감’에 머무는 경우가 대부분입니다.

유럽의 대표적인 HR 및 급여 소프트웨어 유니콘 Personio(기업가치 30억 달러 이상, 직원 1,500명, 고객사 15,000곳) 역시 출발점에서는 똑같은 함정에 빠져 있었습니다. 400명 규모의 대형 영업 조직을 이끄는 최고수익책임자(CRO) 필립 라코어(Philip Lacor)는 2024년 5월 CEO 주도로 진행된 ‘AI 서지 위크(AI Surge Week)’ 직후, 팀원의 90%가 매주 LLM을 사용하고 있음에도 “단순 사용률이 높다는 사실만으로는 시장 진출 방식(GTM)의 진정한 혁신에 도달할 수 없다”는 현실을 직시했습니다.

Personio가 이후 6개월(2024년 5월~11월) 동안 단행한 작업은 신생 AI 네이티브 스타트업이 아닌, 수년간 축적된 레거시 프로세스와 데이터 부채를 안고 있는 성숙한 B2B SaaS 엔터프라이즈가 어떻게 실질적인 비즈니스 성과를 창출할 수 있는지를 보여주는 정석적인 플레이북입니다.

SaaStr에 공개된 핵심 성과는 명확합니다. 사내에 400개 이상의 맞춤형 AI 어시스턴트를 구축했고, 확장(Expansion) 영업 SDR이 고객 1곳을 조사하는 데 쏟던 시간을 2시간에서 15분으로 단축했으며, 인당 파이프라인 생성량을 약 2배로 끌어올렸습니다. 아울러 웹사이트에 배치된 AI SDR인 ‘Nia’는 7일 동안 140건의 데모 미팅을 24시간 실시간으로 자동 확정했습니다. 수많은 툴을 겉핥기로 도입하는 대신, 기존 스택(Salesforce, Gong, Snowflake, Bedrock) 위에 철저한 데이터 정제와 현장 맥락을 결합해 비즈니스 임팩트를 증명해 낸 사례입니다.

2. Problem

Personio가 직면했던 문제는 크게 세 가지 차원에서 전개되었습니다.

2.1 상향식 실험의 한계와 통제 불능의 아이디어 분산

초기 AI 서지 위크는 OpenAI, Mistral, AWS 등의 강사를 초빙해 사내에 큰 열기를 불어넣었습니다. 그러나 상향식(Bottom-up) 열풍만으로는 조직 차원의 근본적 한계를 돌파할 수 없었습니다.

첫째, 구성원 중 누가 업무 시간의 40%를 AI 구축에 쏟을 것인가에 대한 자원 배분(Resource allocation)이 불가능했습니다. 둘째, 현업 실무자가 기존의 낡은 업무 방식을 완전히 중단해도 좋은지에 대한 공식적 권한 부여(Permission)가 없었습니다. 셋째, 50가지 쏟아지는 아이디어 중 비즈니스에 직결되는 3가지를 가려내는 우선순위화(Prioritization)가 작동하지 않았습니다. 슬랙 채널을 열자마자 수많은 제안이 쏟아졌지만, 첫 번째 프로젝트가 완성되기도 전에 새로운 아이디어로 시선이 분산되면서 통제력을 잃고 표류하기 시작했습니다.

2.2 파편화된 도구와 극심한 컨텍스트 스위칭

현장 세일즈 실무진의 일상은 극심한 비효율에 짓눌려 있었습니다. 전담 GTM 엔지니어가 2주간 어카운트 매니저(AM)를 그림자 밀착 관찰(shadowing)한 결과, 실무자들은 단순한 고객 분석 업무 하나를 처리하기 위해 7~8개의 서로 다른 시스템을 끊임없이 오가고 있었습니다. Amplitude에서 제품 사용 데이터를 확인하고, 계약 관리 시스템에서 갱신 조건을 조회하고, CRM에서 과거 이력을 뒤지는 식의 분절된 작업으로 인해 담당자들은 한 가지 업무에서 하루 2.5시간, 다른 업무에서 주당 3시간씩 허비하고 있었습니다.

특히 기존 고객을 대상으로 추가 제품을 제안하는 확장 SDR들은 콜을 걸기 전 고객사 정보를 조사하는 데만 매일 2시간을 허덕이며 소진하고 있었습니다.

2.3 오염된 데이터와 얕은 영업 인텔리전스

화려한 AI 툴을 얹기에 앞서 드러난 사내 데이터 상태는 심각했습니다. Salesforce에 등록된 고객 및 리드 데이터의 3분의 1(약 33%)이 중복 레코드로 오염되어 있었습니다. 또한 딜을 수주하거나 실주했을 때 영업 담당자가 기록하는 사유의 30%가 단순 ‘기타(Other)‘로 채워져 있었으며, 기재된 내용조차 깊이가 얕아 제품 개선이나 경쟁사 대응에 아무런 통찰을 주지 못했습니다. 데이터가 오염되고 맥락이 결여된 상태에서 기성 AI 솔루션을 그대로 도입하는 것은 무용지물이었습니다.

확인된 사실: 1,500명 임직원 및 400명 세일즈 조직 규모, 2024년 5월 서지 위크 이후 90% 주간 LLM 사용률 대비 체감 혁신 부재, Salesforce 레코드의 33% 중복 오염, 실주 사유 30%가 ‘기타’로 처리되는 데이터 결함, 실무자의 7~8개 시스템 순회 및 일일 2시간 사전 조사 낭비.

3. Solution

Personio는 화려한 신규 툴을 무분별하게 구매하는 대신, 조직 거버넌스 재편, 철저한 현장 업무 분석, 그리고 데이터 인프라 정제라는 3대 축을 중심으로 GTM 파이프라인을 재설계했습니다.

3.1 톱다운-바텀업 결합과 15인 크로스펑셔널 워킹그룹

라코어 CRO는 상향식 활력에 방향성과 결단력을 부여하기 위해 2024년 6월 ‘AI Powered Go-To-Market’ 전담 워킹그룹을 신설했습니다. 서로 다른 전문성을 지닌 세 축의 15인으로 팀을 구성했습니다.

* 데이터 및 시스템 팀 (Data & Systems): Snowflake와 기반 데이터 아키텍처, 인프라를 총괄.

* RevOps 및 GTM 엔지니어: 비즈니스와 기술을 잇는 전담 가교 역할(GTM 전담 엔지니어 2명 배치).

* 현업 비즈니스 (The Business): 마케팅, 영업, 고객성공(CS) 등 실제 툴을 사용할 현장 사용자.

라코어는 데이터 팀이 단독으로 LLM을 구축했을 때 비즈니스 맥락 부족으로 실패했던 경험과, 영업 인력이 단독으로 시도했을 때 인프라 지원을 받지 못해 좌절했던 과거 실패를 거울삼아 조직 간 장벽을 완전히 허물었습니다.

3.2 고객 여정 중심의 Jobs-to-be-Done (JTBD) 매핑

아이디어 과열로 인한 분산을 막기 위해 철저한 직무별 과업 분석(JTBD)을 선행했습니다. GTM 엔지니어의 2주간 현장 관찰을 토대로 SDR, AE, CS, 솔루션 엔지니어(SE)의 실제 일과를 분 단위로 쪼개고, 이를 전체 고객 여정에 겹쳐 놓았습니다. 이를 통해 P&L에 가장 큰 병목을 유발하거나 고객 경험의 간극이 가장 큰 핵심 지점을 도출한 뒤 소수의 프로젝트에 자원을 집중 투입했습니다.

3.3 기존 스택 극대화와 데이터 정제 (70%의 기반 공수)

라코어는 “새로운 툴을 찾아 헤매지 말라. 툴은 만병통치약이 아니다”라고 강조합니다. 실제로 AI 구현 공수의 70%는 데이터 정제와 워크플로 정비였으며, LLM 연동은 나머지 30%에 불과했습니다.

* 핵심 스택: CRM(Salesforce), 고객 통화 분석(Gong), 실시간 대화(Qualified), 데이터 웨어하우스(Snowflake), 파운데이션 모델 계층(Amazon Bedrock).

* 데이터 정제 작업: Salesforce 자동 중복 제거 시스템 구축, 외부 데이터를 연동한 가망 고객 데이터베이스 정제, 5,000건 이상의 Gong 통화 녹음과 고객 이메일 전문을 Snowflake에 적재.

* 사내 고유 맥락 주입: 이상적 고객 프로필(ICP) 정의서, 영업 피치 덱, 온보딩 프로세스 문서, 제품 교육 자료를 모델에 체계적으로 결합.

3.4 4대 핵심 프로덕션 유즈케이스

* 수주/실주 인텔리전스 (Win/Loss Intelligence): Snowflake에 적재된 통화 녹음, 이메일, CRM 데이터를 기반으로 GTM 전용 언어 모델을 파이프라인화했습니다. 경쟁사 대응 배틀카드가 실시간으로 자동 갱신되며, 10,000건 이상의 실제 고객 통화 데이터에 기반해 제품 결함 및 개선점을 제품 팀에 정량 피드백하는 ‘GTM 브레인’으로 발전했습니다.

* 확장 SDR 어시스턴트 (Expansion SDR Assistant): GTM 엔지니어가 Salesforce 내부에 직접 임베딩된 보조 도구를 개발했습니다. 고객사 이름을 입력하면 10~20개 사내 시스템에서 데이터를 즉시 취합해 교차 판매(cross-sell) 요약과 신호등(초록/노랑/빨강) 추천을 제공합니다.

* 아웃바운드 인텐트 스코어링 (Intent Scoring): 웹사이트 방문, 경쟁 플랫폼(G2, Trustpilot) 활동, 기존 고객사 사용자의 이직 신호 등을 종합한 동적 구매 의향 점수를 매일 산출하여 Salesforce 화면에 불꽃 아이콘(🔥🔥🔥)으로 시각화했습니다.

* 실시간 AI 인바운드 SDR ‘Nia’: 웹사이트에 유입된 데모 요청을 실시간 24시간 체제로 응대하고 캘린더 미팅을 즉각 확정하는 자율 에이전트를 배치했습니다.

3.5 일일 전담 모니터링과 문화적 보상 체계

Nia 도입 초기 약 4주간 전담 관리자가 없었을 때 에이전트가 법률적 조언을 남발하거나 경쟁사를 비방하고, 제품 질의에 답변하느라 정작 중요한 미팅 예약을 누락하는 사고가 발생했습니다. 이에 Personio는 ‘Ami’라는 전담 모니터링 인력을 배치해 매일 에이전트의 출력을 검수하고 실시간으로 피드백을 반영하는 운영 가드레일을 세웠습니다.

아울러 조직 문화 정착을 위해 CRO가 직접 딜 리뷰 시 PPT를 금지하고 Gong AI 요약 화면을 실시간으로 띄워 시연했으며, 우수 영업사원 포상 제도인 프레지던트 클럽(President’s Club)의 2~3개 좌석을 매출 실적이 아닌 ‘AI 기여도’ 우수자에게 배정하는 파격적인 보상책을 도입했습니다.

확인된 사실: 15인 크로스펑셔널 워킹그룹, 2주간의 현장 관찰을 통한 JTBD 분석, Salesforce·Gong·Qualified·Snowflake·Bedrock 스택, 5,000건 이상 Gong 통화의 Snowflake 적재, 4대 유즈케이스 구축, 전담 모니터링 인력 배치, 프레지던트 클럽 좌석 배정을 통한 문화적 드라이브.

4. Impact

Personio가 6개월 동안 달성한 정량적·정성적 비즈니스 임팩트는 다음과 같습니다.

4.1 핵심 정량 성과

4.2 자본 및 비용 효율성

라코어 CRO에 따르면 Personio는 현재 AI 도구 및 인프라에 수십만 달러(multiple six figures)를 집행하고 있으며, 고도화된 SDR 에이전트 1기당 연간 비용은 약 10만 달러 수준입니다.

그러나 이 투자의 목적은 단순한 인력 감축이 아닙니다. 비즈니스가 지속 성장하는 과정에서 신규 인력을 비례해서 채용하는 대신, 기존 인력의 1인당 생산성을 극대화하여 “인력 증원 없이 매출을 2배로 늘릴 수 있는가(Can we double revenue without doubling headcount)?”라는 엔터프라이즈 스케일링 과제를 해결하는 구조적 전환을 달성했습니다.

5. Insight

단순 사용률(Usage)은 조직 혁신(Transformation)이 아닙니다. 팀원의 90%가 ChatGPT를 열어보고 있다는 사실은 실험의 시작일 뿐 비즈니스 결과가 아닙니다. 조직의 실제 P&L과 직결된 자원 배분, 낡은 프로세스의 중단 권한, 명확한 우선순위 설정은 오직 강력한 경영진의 톱다운 리더십이 결합될 때만 가능합니다.

AI의 본체는 모델이 아니라 데이터와 맥락입니다. 전체 구현 공수의 70%는 Salesforce 중복 제거, 5,000건의 고객 통화 녹음 연동, ICP 및 사내 교육 자료 주입과 같은 고된 데이터 기반 작업이었습니다. 기초 인프라와 맥락이 부실하면 아무리 최신 LLM을 가져와도 환각과 일반론만 쏟아낼 뿐입니다.

에이전트 배포는 끝이 아니라 ‘일일 모니터링’의 시작입니다. Nia 에이전트의 초기 실패가 증명하듯, 자율 에이전트를 실무에 투입한 뒤 매일 출력을 전수 검토하고 교정하는 전담 인력(HITL)이 없으면 고객 경험을 훼손하고 치명적인 컴플라이언스 리스크를 초래합니다.

기술 도입의 성패는 문화적 보상 체계가 결정합니다. 아무리 좋은 도구를 만들어도 실무자가 쓰지 않으면 무용지물입니다. CRO가 솔선수범하여 회의 방식을 바꾸고, 최고 권위의 사내 포상(President’s Club) 기준을 매출 순위가 아닌 AI 혁신 기여도로 돌려놓은 파격적인 조치가 전사 400개 어시스턴트라는 자발적 확산의 기폭제가 되었습니다.

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

6.1 세일즈포스 내 임베디드 확장 어시스턴트의 데이터 페더레이션 및 추천 파이프라인

근거: 원문에서는 GTM 전담 엔지니어가 Salesforce 내부에 직접 임베딩된 어시스턴트를 개발했으며, 계정명을 입력하면 10~20개 시스템(Amplitude 사용량, 계약 시스템 등)에서 데이터를 가져와 교차 판매 요약과 신호등(초록/노랑/빨강) 추천을 제공한다고 명시합니다.

실제 구현 환경에서는 10~20개 개별 SaaS의 외부 REST API를 영업 담당자의 브라우저 화면에서 실시간으로 직접 호출하지 않았을 가능성이 높습니다. 대규모 동시 조회가 일어날 경우 API 속도 지연(latency)과 호출 제한(rate limit) 문제가 발생하기 때문입니다. 대신 주요 사용량 데이터(Amplitude)와 계약 데이터는 이미 Snowflake 데이터 웨어하우스로 사전 동기화(Fivetran 또는 Reverse ETL 파이프라인)되어 있으며, Salesforce Lightning Web Component(LWC)는 사내 API 게이트웨이를 통해 단일 쿼리로 Snowflake 및 CRM 데이터를 집계할 것입니다.

집계된 정형 지표(라이선스 소진율, 활성 사용자 추이)와 비정형 데이터(최근 Gong 통화 요약)는 Amazon Bedrock 상의 경량 파운데이션 모델(Claude Haiku 등)로 전달되어 사전에 정의된 프롬프트 템플릿(Personio ICP 및 교차 판매 룰셋)을 거칩니다. 모델은 “사용자 수가 한도에 근접했고 최근 30일간 근태 관리 모듈 뷰가 40% 증가했음”과 같은 근거와 함께 최종 신호등 판정을 JSON 구조로 반환하며, 화면 렌더링에 소요되는 총 지연 시간은 2~3초 이내로 통제되도록 캐싱 레이어를 결합했을 것으로 추정됩니다.

6.2 실시간 웹 AI SDR(Nia)의 안전 가드레일 및 긴급 핸드오프 아키텍처

근거: 원문에서는 Qualified의 대화형 에이전트 Nia가 7일간 140건의 미팅을 잡았으나, 초기 4주간 법률 자문 제공, 경쟁사 비방, 복합 질의 시 미팅 예약 누락 등의 문제가 발생해 ‘Ami’라는 전담 인력이 매일 검수하며 튜닝했다고 밝힙니다.

이 문제를 기술적으로 방어하기 위해 시스템은 단일 LLM 프롬프트에만 의존하지 않고 이중 안전 가드레일 및 의도 분류(Intent Classification) 레이어를 구축했을 것입니다. 방문자가 입력한 메시지는 메인 응답 생성기로 들어가기 전 가드레일 필터를 통과하며, “독일 노동법 기준 휴가 일수 계산”과 같은 법적 조언 요구나 경쟁사 관련 키워드가 감지될 경우 “해당 문의는 전문 담당자가 안내해 드립니다”라는 고정된 결정론적(deterministic) 템플릿 응답으로 즉시 강제 우회시켰을 것입니다.

아울러 고객이 “가격이 얼마인가요? 그리고 내일 미팅 가능한가요?”처럼 질문과 예약 의도를 동시에 던졌을 때 미팅 예약을 놓치던 현상은, 응답 생성 파이프라인을 1) 제품 질의 답변 태스크와 2) 캘린더 예약 링크 호출(Tool Calling) 태스크로 분리 실행하도록 오케스트레이션을 개편함으로써 해결했을 가능성이 높습니다. 일일 검수 담당자 ‘Ami’는 전날 인입된 챗 로그 중 예약 미완료 건이나 플래그가 지정된 대화를 대시보드에서 일괄 필터링하여 프롬프트 음의 예시(few-shot negative examples)로 지속 주입하는 피드백 루프를 운용했을 것으로 추론됩니다.

6.3 Gong 통화 데이터 기반의 동적 배틀카드 생성 및 피드백 루프

근거: 원문에서는 5,000건 이상의 Gong 통화 녹음과 이메일 데이터를 Snowflake에 적재하고 GTM 전담 언어 모델을 구축하여, 정체되어 있던 경쟁사 배틀카드에 10~15%의 새로운 인사이트를 지속 추가하고 제품 피드백을 전달했다고 설명합니다.

이 워크플로는 매일 야간에 돌아가는 배치 임베딩 및 요약 파이프라인으로 구현되었을 것입니다. Gong의 웹훅을 통해 새로 업로드된 통화 스크립트 중 경쟁사 이름이 멘션된 세그먼트만을 자동으로 추출(parsing)하여 Snowf…

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) 자동화를 시도할 때 챗봇 FAQ 응대나 이메일 초안 작성 보조와 같은 가벼운 작업부터 출발합니다. 하지만 Vercel이 SaaStr 공개 인터뷰에서 공개한 사례는 그보다 한 걸음 더 깊은 코어 영역을 겨냥했습니다. 숙련된 영업 담당자가 매일 수작업으로 처리하던 인바운드 리드 적격성 심사(lead qualification) 파이프라인 전체를 인공지능 에이전트로 전면 이관한 것입니다.

Vercel의 COO 잔 드위트 그로서(Jeanne DeWitt Grosser)는 Google과 Stripe에서 각각 10년 가까이 GTM 조직을 총괄한 베테랑 리더입니다. SaaStr 보도에 따르면 그녀는 Vercel에 합류한 지 약 6주 만인 2025년 6월에 전담 GTM 엔지니어링 팀을 신설하고, ‘GTM 조직 전반에 에이전트를 도입하라’는 명확한 단일 미션을 부여했습니다. 전담 팀이 구축한 리드 적격 심사 에이전트는 2025년 8월 상용 배포되었으며, 사람이 결과물을 전수 검증하는 HITL(Human-in-the-Loop) 모드를 약 6주 운영한 뒤 해당 업무의 전담 인력을 과감하게 축소했습니다.

그로서 COO가 SaaStr 인터뷰에서 요약한 성과는 매우 압축적입니다. 기존에 약 10명의 인바운드 SDR(Sales Development Representative)이 매달려 처리하던 업무를 단 1.25명 수준(미국 전담 1명 + 유럽 및 아시아·태평양 전체 커버 약 20% 공수)으로 줄였으며, 시스템 운영에 소요되는 인프라 및 토큰 비용은 연간 약 5,000달러에 불과해 자체 추산 기준으로 32배의 ROI를 달성했습니다. 토마시 퉁구즈(Tomasz Tunguz)가 레니(Lenny) 팟캐스트 인터뷰를 인용해 분석한 바에 따르면, 시스템 개편 전후로 리드에서 영업 기회로 이어지는 전환율(lead-to-opportunity conversion rate)은 하락 없이 평탄(flat)하게 유지되었습니다. 단순히 처리 속도만 높이고 산출물 품질이 무너진 반쪽짜리 실험이 아니었다는 점이 이 사례의 핵심 가치입니다.

Vercel GTM 엔지니어링 팀의 드루 브레드빅(Drew Bredvick)이 2026년 1월에 작성한 기술 회고는 동일한 프로젝트를 엔지니어의 시각에서 구체적으로 풀어냅니다. 주말 프로토타입 개발에서 시작해, 웹 폼 제출 접수부터 계정 리서치, 적격 판정, Slack 승인 루프, 맞춤형 응대 메일 초안 작성에 이르는 전 과정을 하나의 완결된 소프트웨어 제품처럼 구축해 낸 여정이 담겨 있습니다.

아울러 SaaStr 인터뷰 기사에는 리드 심사 외에도 Vercel 내부에서 가동 중인 인접 에이전트의 성과가 함께 소개됩니다. 고객 지원 에이전트가 전체 지원 티켓의 93%를 처리하고, 콘텐츠 에이전트가 직전 분기 주요 콘텐츠 업데이트 작업의 96%를 소화했다는 내용입니다. 다만 본 분석의 중심축은 어디까지나 인바운드 리드 적격 심사 에이전트이며, 93%와 96% 수치는 동일 출처에서 함께 언급된 별도의 인접 에이전트 실적으로 구분하여 다룹니다.

2. Problem

드루 브레드빅이 정리한 도입 이전의 운영 병목은 매우 구체적이고 현실적이었습니다. 공식 웹사이트의 Contact Sales 폼에는 유효한 잠재 고객뿐 아니라 대량의 스팸과 무관한 문의가 무차별적으로 섞여 들어왔고, 접수된 리드는 전문성이나 맥락에 대한 고려 없이 당번 SDR에게 기계적인 순번(라운드로빈)으로 배정되었습니다. 이로 인해 최초 응답까지 걸리는 대기 시간은 24~48시간까지 길어졌고, 시차와 무관하게 영업 담당자들은 ‘이 리드가 과연 시간을 들여 검토할 가치가 있는지’를 판단해 달라는 내부 핑에 시달려야 했습니다. 정작 SDR들은 잠재 고객과 심도 있는 대화를 나누기보다 스팸 분류, 회사 및 담당자 뒷조사, 적격 여부 판정, 콜드 메일 초안 작성과 같은 사전 수작업에 대부분의 업무 시간을 빼앗기고 있었습니다. 지능형 라우팅은커녕 ‘지금 즉시 응대 가능한 최적의 영업 인력’을 찾아 매칭해 주는 시스템조차 전무했던 것입니다.

퉁구즈가 인용한 그로서 COO의 회고는 이러한 비효율을 직관적으로 드러냅니다. 기존에는 꼬박 10명의 전담 SDR이 달라붙어 인바운드 접수와 사전 분류 작업을 처리해야 했지만, 이제는 에이전트가 생성한 결과물을 최종 검수하는 인력 1명만이 남아 해당 파이프라인을 지탱하고 있으며, 나머지 9명의 숙련 인력은 보다 높은 부가가치를 창출하는 아웃바운드 영업으로 전진 배치되었습니다. 이 과정에서 가장 엄격하게 요구된 전제 조건은 전환율을 사람이 직접 처리하던 시절과 동일한 수준(flat)으로 방어하는 것이었습니다.

SaaStr 기사에 소개된 사전 관찰 과정 역시 문제 정의의 중요한 통찰을 담고 있습니다. GTM 엔지니어는 시스템 개발에 앞서 최고 성과를 내는 일급 SDR을 며칠 동안 그림자처럼 밀착 관찰(shadowing)하며, 그가 LinkedIn, BuiltWith, 고객사 웹사이트, 사내 CRM, Slack 대화 이력을 오가며 브라우저 탭을 열고 닫는 작업 순서를 하나하나 그대로 기록했습니다. 그 탭들의 이동 순서야말로 ‘현장에 실재하는 사람의 실제 워크플로’였으며, 엔지니어링 팀이 자동화해야 할 대상은 낯선 새 시스템이 아니라 숙련자가 머릿속으로 밟아오던 바로 그 탭들의 작업 시퀀스였습니다.

확인된 사실: 공개 접수 폼의 스팸 유입 및 느린 응답 지연(드루 서술 기준 24~48시간 소요), 10명 규모의 인바운드 전담 SDR 운영(SaaStr·퉁구즈·드루 공통), 리드 전환율의 전후 동일 유지(flat) 목표 및 달성(퉁구즈/그로서), 최고 성과 SDR 관찰을 통한 실제 워크플로 문서화(SaaStr), 2025년 8월 런칭 및 약 6주간의 HITL 검증 기간 운영(SaaStr).

3. Solution

해법은 겉만 번지르르한 대화형 챗봇이 아니었습니다. 고객 리서치 → 적격성 분류 → 응대 메일 초안 작성 → 사람의 원클릭 승인으로 이어지는 완결된 엔드투엔드 인바운드 처리 파이프라인이었습니다.

3.1 빌드 삼각대와 ‘사람 우선’ 원칙

SaaStr 인터뷰에 따르면 Vercel 내부에서 에이전트를 개발할 때는 항상 일관된 협업 모델을 적용합니다. GTM 엔지니어 + 데이터 사이언티스트 + 해당 업무 최고 전문가(SME)로 구성된 ‘빌드 삼각대’가 한 팀으로 뭉쳐, 먼저 현장의 최고 실무 경험(Best Practice)을 문서로 정리한 뒤 이를 실행 가능한 워크플로 코드로 변환합니다. 초기 단계에서는 에이전트의 출력을 사람이 전수 검수하며, 시스템에 처음부터 자율적 실행 권한을 부여하지 않습니다. 현장 전문가가 더 이상 수정할 피드백이 없다고 판단하는 시점에 도달해서야 비로소 사람의 개입을 줄여나가는 방식입니다.

리드 적격 심사 에이전트 역시 이 원칙을 충실히 따랐습니다. 담당 엔지니어는 최우수 SDR이 띄우던 브라우저 탭들을 도구 호출(Tool Calling) 인터페이스로 그대로 옮겨 담았고, 생성형 AI 모델을 연결하기 전에 시스템을 결정론적(deterministic) 워크플로로 먼저 단단하게 구현했습니다. 이후 실제 상용 트래픽을 흘려보내는 약 6주간의 프로덕션 섀도 모드를 거치며, 최우수 SDR이 에이전트가 쏟아내는 모든 판정 결과와 메일 초안을 직접 검토하고 교정했습니다. SaaStr는 이 시스템을 두고 ‘최우수 SDR이 수동으로 수행하던 판단 로직을 아키텍처로 구현함으로써, 상위 10% 수준의 성과를 24시간 내내 100% 일관되게 발휘하는 체계를 완성했다’고 평가합니다.

3.2 런타임 파이프라인 (드루 회고 및 오픈소스 템플릿)

드루의 프로덕션 아키텍처 설명과 Vercel Labs의 오픈소스 참조 저장소(vercel-labs/lead-agent)가 보여주는 런타임 처리 흐름은 다음과 같이 일치합니다.

* 폼 접수 및 1차 보강: 잠재 고객의 Contact Sales 제출 즉시 Clearbit, ZoomInfo 등의 API를 호출해 기업 및 담당자 데이터 자동 보강(Enrichment).

* 심층 리서치 에이전트: 웹 검색과 기업 공시, 기술 스택 신호를 조회해 회사 규모와 사업 모델을 심층 분석.

* 구조화된 자격 판정: 수집된 데이터를 바탕으로 리드를 사전 정의된 버킷(적격 / 추가 팔로업 필요 / 단순 기술지원 문의 / 영업 무관 스팸 등)으로 정밀 분류.

* Slack 기반 맥락 전달: 분류 근거와 추론 요약 메모를 담당 SDR의 Slack으로 즉시 알림.

* 초안 작성 및 푸시: 적격 판정을 받은 리드에 한해 개인화된 맞춤 응대 메일 초안을 자동 생성하여 Outreach 등 세일즈 시퀀스 도구로 연동.

이로써 현장 영업 인력의 일상 업무는 ‘스팸 걸러내기, 웹 검색, 자격 판단, 콜드 메일 작성 및 발송’의 중노동에서 ‘AI가 분석하고 작성해 둔 결과물을 검토한 뒤 승인 버튼을 누르는 작업’으로 완전히 재편되었습니다. 한편 GitHub에 공개된 참조 구현 템플릿은 Next.js, AI SDK, 내구성 있는 백그라운드 워크플로 실행을 위한 Workflow DevKit, Slack 상호작용 승인을 위한 Slack Bolt, 심층 웹 조사를 위한 Exa 검색 API를 핵심 스택으로 명시하고 있습니다. 다만 이는 외부 공개용 참조 아키텍처(reference architecture)이며, Vercel 사내 프로덕션 파이프라인과 1:1로 완전히 동일하다고 단정할 근거는 템플릿 문서에 명시되어 있지 않습니다.

3.3 확장과 유지보수 체계

SaaStr에 따르면 이 에이전트의 초기 프로토타입은 단 한 명의 엔지니어가 단 주말 이틀 동안 개발했으며, 불과 6주 만에 상용 프로덕션 환경에 배포되었습니다. 이후 Vercel은 동일한 프레임워크를 오프라인 이벤트 후속 관리, 제품 주도 적격 리드(PQA) 판정, 특정 시점 기반 캠페인 등 사내 30개 이상의 SDR 워크플로로 전격 확대 적용했습니다. 시스템 유지보수에 투입되는 리소스는 엔지니어 1인 업무 시간의 약 20%(SaaStr) 혹은 퉁구즈 및 드루가 언급한 25~30% 수준에 불과합니다. 출처별로 집계 방식에 약간의 차이가 있지만, 대규모 전담 개발팀을 상시 유지할 필요 없이 소수의 공수만으로 안정적인 운영이 가능하다는 점은 공통된 사실입니다.

확인된 사실: GTM 엔지니어·데이터 사이언티스트·도메인 전문가로 구성된 삼각 협업 체계, 실무 문서화 선행 후 결정론적 워크플로 구축 및 섀도 HITL을 거친 점진적 인력 축소(SaaStr), 폼 접수→데이터 보강→심층 리서치→적격 판정→Slack 알림→초안 작성 파이프라인(드루), Next.js·AI SDK·Workflow DevKit·Slack Bolt·Exa 기반의 오픈소스 참조 스택, 주말 프로토타입 개발 및 6주 내 상용화와 30개 워크플로 확장(SaaStr), 엔지니어 1인 기준 약 20~30% 수준의 경량 유지보수 공수.

4. Impact

인바운드 리드 적격 심사 에이전트와 관련하여 객관적으로 확인된 정량적 성과는 다음과 같습니다. 각 지표의 출처와 산출 기준을 명시합니다.

업무 처리 속도와 관련된 정성적 평가는 퉁구즈와 그로서 COO의 인터뷰를 통해 확인할 수 있습니다. 야간이나 주말에 리드가 쌓이던 큐 적체를 해소함으로써 최종 계약 전환까지 필요했던 영업 터치 횟수를 유의미하게 단축했다는 설명입니다. 다만 구체적인 터치 횟수의 절대적인 수치는 1차 출처에 수치로 공개되지 않았습니다.

인접 에이전트 성과 (동일 SaaStr 인터뷰 언급 · 리드 에이전트와 독립된 실적)

지표수치비고고객 지원 에이전트 케이스 자율 처리율93%SaaStr. 고난도 기술 및 인프라 문의가 포함된 지원 티켓 대상사내 콘텐츠 에이전트 작업 처리율96%SaaStr. 직전 분기 진행된 주요 콘텐츠 업데이트 작업 대상Vertex AI 기반 지원 에이전트 운영비용인프라 월 약 300달러 + 토큰 월 약 1.2만 달러 (연간 약 15만 달러, 전담 엔지니어 3명)SaaStr. 리드 적격 에이전트의 연간 5,000달러 인프라 비용과는 완전히 별개의 예산 라인

확인된 사실: 상기 표에 명시된 수치와 각 출처의 엄격한 매핑. 기존 9명의 SDR을 해고한 것이 아니라 아웃바운드 영업으로 재배치했다는 그로서 COO의 인용(퉁구즈). 인력 감축 자체가 목적이 아니라 영업 인력을 상위 밸류체인으로 이동시켰다는 SaaStr의 설명.

5. Insight

이 사례에서 최신 파운데이션 모델의 이름보다 훨씬 두드러지는 본질은 바로 ‘사람의 실제 워크플로를 소프트웨어 제품으로 전환해 낸 방식’입니다.

사람의 행동을 정밀하게 문서화한 뒤에야 모델을 연결했습니다. SaaStr가 거듭 강조하는 성공 방정식의 순서는 명확합니다. 최우수 실무자 섀도잉 → 결정론적 코드 워크플로 구축 → 도구 호출 연동 → 섀도 모드 전수 검증 → 점진적 사람 개입 축소입니다. 드루 엔지니어가 회고하듯 주말 동안 가볍게 프로토타입을 만들었을 수는 있지만, 상용화 직전의 치열했던 6주는 현장 최고 실무자의 ‘드러난 선호(revealed preference)’와 암묵지를 코드로 번역해 내는 엄밀한 과정이었습니다.

리드 전환율을 완벽히 방어하며 인력을 재배치했습니다. 인바운드 인력을 10명에서 1명 수준으로 줄였음에도 리드 전환율이 이전과 동일(flat)하게 유지되었다는 사실이야말로 가장 중요한 품질 지표였습니다. 단순히 인건비를 줄였다는 사실만으로 성공을 자축하지 않았습니다. 아울러 남은 1명의 핵심 역할이 단순 반복 업무가 아니라 ‘에이전트 산출물의 최종 QA 및 승인’이라는 점은, 무리한 완전 무인화보다 사람이 책임 버튼을 쥐고 있는 HITL 구조가 엔터프라이즈 운영의 안정적인 기본값임을 증명합니다.

비용과 ROI를 주장하는 두 가지 층위가 존재합니다. 그로서 COO와 SaaStr가 밝힌 연간 5,000달러는 순수 인프라 호스팅 및 모델 토큰 비용에 가깝고, 드루 엔지니어가 밝힌 연간 6만 달러 비용과 200만 달러 이상의 절감액은 엔지니어링 인건비 공수와 영업 인력 효율화까지 반영한 종합적 산출물입니다. 양측 모두 32배(32×)의 높은 ROI를 제시하지만 계산식에 반영된 분모와 분자의 기준이 서로 다릅니다. 이 사례를 사내에 벤치마킹할 때는 어떤 비용 층위를 의사결정 기준으로 삼을지 명확히 구분해야 합니다.

타 조직 복제 시의 전제 조건과 한계. 공개된 자료만으로는 Vercel 내부의 구체적인 CRM 커스텀 필드 매핑 규칙, 스팸 필터링 임계값, Outreach 발송 권한 체계, Slack 승인 SLA를 그대로 재현하기 어렵습니다. 오픈소스 저장소의 lead-agent 코드 역시 어디까지나 참조 아키텍처(reference architecture)일 뿐입니다. 또한 고객 지원 93% 자율 처리나 콘텐츠 96% 소화는 사내의 에이전트 도입 문화와 삼각 협업 체제 아래서 탄생한 인접 성공 사례일 뿐, 리드 적격 심사와 동일한 파이프라인에서 동작한다고 볼 근거는 없습니다. 아울러 32배 ROI나 200만 달러 이상의 절감액 역시 기업 자체의 추산치이며 독립된 외부 회계 감사를 거친 수치는 아닙니다.

요약하자면, 인바운드 리드 자격 심사처럼 이미 현장 전문가들이 일정한 패턴으로 수행하던 업무를 성공적으로 에이전트화하기 위해 필요한 것은 화려한 모델의 명칭이 아닙니다. 철저한 실무 섀도잉을 통해 빚어낸 결정론적 워크플로와 Slack 기반의 직관적인 휴먼 인 더 루프(HITL) 승인 체계가 조화롭게 결합될 때 비로소 진정한 비즈니스 가치가 완성됩니다.

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

6.1 폼 접수부터 구조화된 자격 판정까지의 데이터 파이프라인

근거: 드루의 회고록에서는 웹 폼 접수 후 Clearbit과 ZoomInfo를 통한 데이터 보강(Enrichment), 기업 및 담당자에 대한 심층 리서치, 그리고 리드를 4대 범주(적격 / 추가 팔로업 필요 / 단순 지원 문의 / 영업 무관 스팸)로 분류하는 구조를 명시합니다. SaaStr는 엔지니어가 SDR이 보던 LinkedIn, BuiltWith, 웹사이트, CRM, Slack 탭을 도구 호출 단계로 변환했다고 설명합니다. 오픈소스 lead-agent 템플릿 역시 AI SDK의 generateObject를 활용해 자격 카테고리와 판정 추론을 스키마 형태로 추출하고 Exa 웹 검색 에이전트를 내장하고 있습니다.

실제 시스템에서는 잠재 고객이 웹 폼을 제출하는 즉시 프론트엔드에 성공 응답을 반환한 뒤, 백그라운드에서 Workflow DevKit을…

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. 왜 이 사례인가

많은 조직이 인공지능을 도입할 때 주변부 업무부터 조심스럽게 적용합니다. 챗봇, 사내 FAQ 응대, 내부 문서 초안 작성처럼 오류가 발생해도 손쉽게 되돌릴 수 있는 영역에서 먼저 경험을 쌓은 뒤 점차 핵심 비즈니스로 영역을 넓혀가는 방식이 일반적입니다.

Paychex는 이러한 관행을 정면으로 뒤집었습니다. 베인앤드컴퍼니(Bain & Company)의 고객 성과 보고에 따르면, Paychex는 베인 및 OpenAI의 지원을 바탕으로 HR·복리후생·급여 서비스 업계 최초로 실제 프로덕션 급여(payroll) 처리 파이프라인에 에이전트형 AI를 직접 통합한 사례를 구축했습니다. (원문의 ‘industry’s first’는 베인과 Paychex 측의 발표 표현이며, 외부 공인 기관의 독립 검증을 거친 것은 아닙니다.)

급여 업무는 계산 착오나 일정 지연에 대한 허용 한계가 사실상 제로에 가깝습니다. 케이스 스터디 기준 80만 곳 이상의 기업 고객이 회차마다 단 1원의 오차도 없는 정확한 지급을 요구하며, 베인의 동반 영상 자료에 따르면 월간 급여 처리 규모는 거의 100만 건에 달합니다. 이러한 미션 크리티컬 파이프라인에 자율 에이전트를 배치했다는 것은 안전한 실증 테스트(PoC) 차원을 넘어 핵심 수익 창출과 고객 신뢰의 근간을 건 과감한 승부수였습니다.

동시에 이 사례가 주목받는 이유는 화려한 기술 스펙이 아니라 정교한 현장 운영 설계에 있습니다. 수십 년간 고객들이 익숙하게 사용해 온 이메일과 셀프서비스 접점을 일방적으로 없애지 않았고, 에이전트를 담당 실무 전문가의 보조자이자 파트너 위치에 배치했으며, 상용 배포 전에 그림자(shadow) 모드를 운영하여 요구 정확도 기준을 완벽하게 충족했습니다. 베인 보고서가 제시하는 핵심 지표인 지급 및 처리 시간 80% 단축, 인적 투입 공수 30% 절감은 인터뷰 영상이 촬영된 2026년 5월 11일을 기준으로 산출된 수치입니다.

한편 같은 달 Paychex는 HCM(인적자본관리) 전반을 아우르는 WISE 플랫폼을 공식 발표했고, 몇 달 뒤 초기 도입 성과를 추가로 공개했습니다. 해당 지표들은 별개의 보도자료를 통해 발표된 성과이므로, 본 분석에서는 베인 케이스 스터디의 급여 엔진 구현을 중심으로 살펴보되 WISE 발표 수치와 합산하거나 동일시하지 않고 엄격히 분리하여 다룹니다.

2. Problem

Paychex의 수많은 고객사는 단일화된 방식으로만 급여 업무를 처리하지 않았습니다. 상당수 기업은 온라인 셀프서비스 포털을 이용했지만, 이메일과 같은 기존의 전통적인 소통 채널을 여전히 선호하는 고객도 많았습니다. 베인의 인터뷰 영상 자료에 따르면 고객의 약 80%는 온라인 포털을 통해 시스템에 접속하지만, 나머지 고객군은 여전히 이메일에 급여 변동 명세를 담아 전송하고 있었습니다.

이러한 고객 맞춤형 유연성을 지속적으로 보장하려면, 비정형 이메일로 인입되는 각종 급여 요청서를 사람이 직접 일일이 읽고, 검증하고, ERP 시스템에 입력·처리하는 작업을 유지할 수밖에 없었습니다. 내부 운영을 자동화하겠다는 명분만으로 수많은 고객에게 채널 전환을 강제할 수는 없었고, 비정형 데이터를 정밀한 검증 없이 백그라운드 배치 시스템으로 곧바로 밀어 넣는 방식 역시 불가능했습니다.

Paychex의 엔지니어링 및 기술 총괄 상무(Managing Director of Engineering and Technology) 데이브 윌슨(Dave Wilson)은 당시의 제약 조건을 다음과 같이 회고합니다. 이메일에서 추출한 데이터를 담당 전문가의 확인 없이 백그라운드 엔진에서 일방적으로 처리하도록 둘 수는 없었습니다. 에이전트는 서비스 현장 전문가의 곁에서 긴밀하게 협업하는 형태로 동작해야지, 전문가를 건너뛰고 독단적으로 처리하는 구조가 되어서는 안 되었습니다. 오랜 기간 쌓아온 고객 신뢰와 서비스 품질 기준을 훼손하지 않으면서 자동화를 달성하려면 실무자와의 공존이 필수적인 전제 조건이었습니다.

더 큰 문제는 단순한 작업량의 압박에 그치지 않았습니다. 실제 상용 급여 프로세스는 오류에 대한 관용도가 전혀 없는 환경입니다. 사원 정보의 오매칭, 잘못된 세무·공제 검증, 지급 오류는 즉각적인 고객 신뢰 추락과 심각한 컴플라이언스 및 법적 리스크로 이어집니다. 조금 틀려도 사후 피드백으로 보완하면 그만인 여타 업무와는 실패 비용의 규모 자체가 달랐습니다.

확인된 사실: 셀프서비스와 이메일 등 다채널 접점 유지의 필요성, 수작업 기반의 문서 판독·검증·입력 부담, 오류에 대한 극단적인 무관용 원칙, 80만 이상 기업 고객 및 월간 거의 100만 건에 이르는 급여 처리 규모(영상 자료 기준), 베인앤드컴퍼니 및 OpenAI의 기술 지원을 받아 라이브 급여 처리에 에이전트를 도입했다는 사실.

추론: 급여 프로세스는 안전한 파일럿 대상이 아닌 핵심 매출 및 신뢰 직결 영역이므로, 주변부 단순 업무 자동화에 비해 초기 구축 위험과 성공 시 누릴 수 있는 비즈니스 ROI가 동시에 매우 크다고 경영진이 판단했을 가능성이 높습니다. (공식 문서에 구체적인 ROI 산출 공식은 미공개.)

3. Solution

Paychex와 베인이 선택한 해법은 단순한 질의응답형 챗봇이 아니었습니다. 고객이 보낸 다양한 형식의 급여 입력 데이터를 스스로 읽고, 비즈니스 규칙에 따라 검증하며, 최종 트랜잭션까지 실행하는 전담 에이전트를 구축하되, 기존 고객 접점의 신뢰 자산을 결코 해치지 않는 설계를 핵심 원칙으로 삼았습니다.

3.1 기반: 고유 데이터, 신뢰, 확장성

베인 보고서는 성공적인 구축 기반으로 세 가지 요소를 강조합니다. Paychex만의 고유한 급여 도메인 데이터, 55년 이상 다져온 고객과의 깊은 신뢰, 그리고 대규모 엔터프라이즈 트래픽을 안정적으로 견뎌내는 기술 인프라입니다. 단순한 기술 검증용 PoC를 넘어 실제 프로덕션 환경에서 작동하는 자율 에이전트를 완성할 수 있었던 원동력 역시 이러한 역사적 토대에 있었습니다. 윌슨 상무는 인터뷰에서 Paychex가 1971년 창립 이래 반세기가 넘도록 고객 신뢰를 축적해 왔음을 거듭 강조했습니다.

3.2 Shadow mode: 상용 배포 전 병렬 운전 검증

에이전트를 실제 상용 환경에 전면 배포하기에 앞서, 개발팀은 기존 급여 실무 전문가의 실제 처리 흐름과 병렬로 맞물려 돌아가는 그림자(shadow) 모드를 선행 운영했습니다. 사람 실무자가 판단 루프 안에 직접 머무르는(Human-in-the-Loop) 이 검증 기간을 거치면서 시스템은 점진적으로 신뢰도를 확보해 나갔습니다. 베인 영상 페이지의 ‘Learning in the dark’ 섹션은 처음부터 전권을 AI에 위임할 수 없었으며, 숙련된 전문가가 매 결과물을 일일이 검증해야 했다고 명시합니다. 설령 사람이 최종 개입해야 하는 예외 건이라 하더라도 에이전트가 앞단의 기초 작업을 이미 완료해 둔 상태였기에 실무자의 소요 시간을 크게 절감할 수 있었습니다.

그림자 모드 운영 과정에서 수집된 풍부한 실무 피드백은 모델 미세조정과 전체 파이프라인의 완성도를 높이는 데 집중 투입되었습니다. 윌슨 상무는 PoC 단계에서 실제 프로덕션 체계로 전환할 당시, AI 모델 자체를 튜닝하는 공수와 에이전트를 안정적으로 서빙하는 파이프라인 엔지니어링 공수에 거의 대등한 시간과 자원을 쏟았다고 회고합니다. 생성형 AI 기술이 숨 가쁘게 발전하는 와중에도 인프라 파이프라인과 모델 고도화라는 두 마리 토끼를 병행해서 밀어붙인 결과였습니다.

3.3 「Father」 일화: 하드코딩 대신 맥락적 추론 학습

이 과정에서 널리 알려진 대표적 사례가 바로 교회 고객사의 급여 대장에 등장한 「Father」 명칭 이슈입니다. 초기 에이전트는 이 단어를 인명으로 매칭하지 못해 처리에 실패했습니다. 하지만 시스템은 「Father」가 고유 인명이 아니라 성직자를 가리키는 종교적 호칭(신부/목사) 이라는 비즈니스 맥락을 학습했고, 이후 동일한 패턴의 예외 케이스를 정확하게 처리해 냈습니다. 베인은 이를 단순 예외 처리 코드로 하드코딩해 때우기보다, 에이전트가 전후 고객 맥락을 포괄적으로 연결하여 이해하도록 유도한 대표적 사례로 꼽습니다. 그림자 모드가 실무에서 요구하는 ‘정밀한 정확도 기준’을 달성하기 위한 귀중한 학습 신호로 작동했음을 보여주는 대목입니다.

3.4 역할 분담: 엔드투엔드 처리와 예외 관리·고객 자문

충분한 그림자 검증 기간을 마친 후, 시스템은 에이전트가 정상 급여 건의 엔드투엔드(end-to-end) 완결 처리를 도맡고 실무 직원은 복잡한 결과 검토 및 시스템이 넘긴 예외 상황 처리에 집중하는 분업 구조로 전환되었습니다. 지루하고 반복적인 수기 데이터 입력에서 해방된 실무진은 고객과의 관계를 심화하고 전문적인 비즈니스 가치를 전달하는 자문(advisory) 서비스에 더 많은 시간을 할애할 수 있게 되었습니다. 윌슨 상무는 고객이 기대하는 높은 수준의 전문성과 인간적 유대감은 전문가가 변함없이 유지하고, 에이전트는 번거롭고 반복적인 데이터 작업만을 온전히 흡수해 낸 이상적인 분업 모델이라고 설명합니다.

3.5 Bain과 OpenAI의 협업

보고서에서는 이번 급여 엔진 구축이 베인앤드컴퍼니와 OpenAI의 적극적인 지원, 그리고 데이브 윌슨 상무가 이끄는 내부 엔지니어링 및 기술 조직의 주도하에 완성되었다고 밝히고 있습니다. 다만 활용된 파운데이션 모델의 구체적인 명칭, 양사 간 상세 계약 구조, 사내 투입 인원과 세부 조직 구성 등은 외부에 공개되지 않았습니다.

확인된 사실: 베인 및 OpenAI의 기술 협업, 상용 배포 전 그림자 모드(Human-in-the-Loop) 운영, 비정형 입력 판독·검증·처리를 포괄하는 에이전트 구축, 전문가 병행 검증 후 종단 처리 및 예외 리뷰로의 역할 분담, 「Father」 호칭 사례를 통한 맥락 학습, 모델 튜닝과 파이프라인 엔지니어링의 병행 추진, 반세기가 넘는 고객 신뢰와 고유 데이터 및 엔터프라이즈 인프라 기반.

추론: 에이전트 도입의 목적이 직원의 물리적 감원이 아니라, 실무 전문가는 고부가가치 예외 대응과 고객 자문에 집중하고 에이전트는 표준적 반복 트랜잭션을 전담 처리하는 고도화된 운영 모델을 구축하는 데 있었을 가능성이 큽니다. (조직 개편이나 인력 감축과 관련된 구체적 통계는 비공개.)

4. Impact

베인의 케이스 스터디 보고서가 공식 제시한 비즈니스 임팩트는 명료한 두 가지 핵심 수치로 요약됩니다. 모든 통계는 보고서 각주에 명시된 바와 같이 인터뷰 영상 촬영 시점인 2026년 5월 11일 기준입니다.

보고서에 따르면 평균 급여 처리 소요 시간이 80% 단축되었으며, 실무 직원들은 이렇게 확보된 시간을 서류 처리 대신 고객 대상 고부가가치 자문 업무에 재투자하고 있습니다. 그리고 이번 혁신의 궁극적 성격을 단적으로 드러내는 핵심 문장이 제시됩니다. 「Customers haven’t noticed a change in service. That’s the point.」 — 즉, 서비스 이행 주체가 AI로 바뀌었음에도 고객이 어떠한 이질감이나 서비스 변화를 눈치채지 못하게 만드는 것이야말로 이번 프로젝트의 핵심 목표였다는 뜻입니다.

윌슨 상무는 인터뷰를 통해 급여 처리 속도를 80%나 끌어올리는 과정에서도 기존 고객들이 편하게 이용하던 소통 방식을 그대로 지켜주었으며, 이를 통해 기존의 신뢰 관계를 한층 더 두텁게 만들었다고 회고합니다. 베인의 동반 영상 자료 역시 이번 프로젝트의 진정한 승리는 표면적인 수치 절감 그 자체보다, 전문가가 되찾은 여유 시간을 활용해 고객과의 상담을 늘리고 파트너십을 더욱 공고히 한 점에 있다고 결론짓습니다.

향후 발전 방향에 대해 보고서는 텍스트 기반 처리를 넘어선 음성 자율 에이전트의 도입, 한 차원 높은 초개인화 서비스, 그리고 수백만 건 단위의 이메일 처리를 수십억 건 규모로 확장하는 장기적 로드맵을 제시하고 있습니다. (다만 세부 투자 규모나 구체적인 일정은 공개되지 않았습니다.)

인접 발표 및 수치 혼동 주의

베인 보고서에 기록된 80% 시간 단축 및 30% 노력 절감 지표와 출처 및 측정 기준이 전혀 다른 인접 보도 내용이 존재하므로, 이를 임의로 합산하거나 동일한 성과로 오인해서는 안 됩니다.

* 2026-05-19: Paychex는 HCM 생태계 전반을 지원하는 차세대 에이전트 지능 플랫폼인 WISE(Workforce Intelligence Strengthened by Expertise)의 공식 출시를 발표했습니다. Flex, Paycor, SurePayroll 플랫폼 전반을 아우르는 구조로 소개되었으며, Agents, Intelligence, Assistants, Advisory의 4대 기능 계층으로 구성되어 있습니다. 베인 보고서에서 다룬 급여 처리 엔진이 이 WISE 플랫폼과 동일한 시스템이라고 단정할 수 있는 객관적 근거는 케이스 스터디 원문에 존재하지 않습니다.

* 2026-08-31: Paychex는 WISE 플랫폼을 조기 도입한 5만 곳 이상의 기업 고객을 대상으로 측정한 초기 성과 지표를 추가 발표했습니다. 여기에는 음성 및 이메일 에이전트의 35만 건 이상 고객 대화 처리, 20% 이상의 무인 자율 해결률, 이메일 에이전트의 평균 처리 시간 약 3분 달성(수작업 대비 80% 이상 빠름 주장), 근무 시간 및 급여율 산정 오류의 약 90%를 급여 실행일 전에 사전 수정하는 성과 등이 포함되어 있습니다. 이는 WISE라는 별도 상용 제품의 조기 성과 지표이며, 베인 보고서가 2026년 5월 11일 기준으로 발표한 80% 및 30% 절감 수치와는 출처와 맥락이 완전히 다릅니다.

확인된 사실: 베인 보고서의 80% 처리 시간 단축 및 30% 인적 노력 절감(2026-05-11 기준), 고객 관점에서의 서비스 이질감 제로 달성 서술, 이후 발표된 WISE 플랫폼 런칭(5월 19일) 및 조기 성과 보고(8월 31일)는 독립된 공식 보도자료에 기반한 수치라는 점.

추정: 베인과의 협력을 통해 개발된 라이브 급여 에이전트 역량이 향후 WISE라는 전사 통합 브랜드 및 상용 제품군으로 고도화·상품화되었을 가능성이 높습니다. 그러나 공개된 자료만으로는 두 프로젝트 간의 구체적인 시스템 아키텍처 연동 여부나 계약 관계를 단정할 수 없습니다.

5. Insight

이 사례가 주는 가장 값진 교훈은 최신 기술 스택의 단순한 나열이 아니라, 과감한 문제 정의와 현장 중심의 운영 설계에 있습니다.

가장 까다로운 핵심 문제부터 돌파했습니다. 베인은 이를 두고 “과감하게 홈런을 노리는 도전(shoot for the fences)”, “가장 어려운 문제부터 정면 돌파(picking the hard problem)”라는 표현으로 설명합니다. 주변부 업무에서 손쉬운 파일럿만 반복하는 통상적인 접근법과는 정반대의 길을 걸었습니다. 급여처럼 오차를 용납하지 않는 미션 크리티컬 영역에 진입하는 것은 성공 시 누릴 수 있는 파급력도 크지만 실패 시 떠안아야 할 리스크 또한 치명적입니다. Paychex는 이러한 트레이드오프를 명확히 인지하고 핵심 엔진부터 과감하게 공략했습니다.

고객의 소통 채널을 억지로 단일화하지 않았습니다. 운영 효율을 높이겠다고 고객들이 수십 년간 써오던 이메일 접점을 인위적으로 차단하지 않고, 에이전트 스스로 비정형 이메일 데이터를 능숙하게 해석하도록 만들었습니다. 기업의 디지털 전환과 고객의 기존 업무 습관이 부딪힐 때, 이를 고통스러운 고객 마이그레이션 과제로 전가하는 대신 에이전트의 지능적 역량으로 자연스럽게 흡수한 셈입니다. 윌슨 상무는 인터뷰에서 AI가 온라인 포털 경험과 기존 이메일 소통 방식을 부드럽게 잇는 가교 역할을 해냈다고 강조합니다.

그림자 모드로 현장의 신뢰 기준을 먼저 달성했습니다. 프로덕션 배포에 앞서 실제 전문가의 작업과 에이전트를 실시간으로 병렬 운전시켰으며, 「Father」 호칭 사례처럼 현장에서 마주친 수많은 비즈니스 예외 맥락을 시스템의 학습 기회로 흡수했습니다. 특히 ‘사람이 개입하더라도 에이전트가 사전 작업을 대부분 마쳐두어 업무가 빨라졌다’는 설명은, 완전한 무인 자동화만을 고집하기보다 부분 자동화와 유연한 사람 개입(예외 에스컬레이션)을 균형 있게 결합한 하이브리드 운영 체계가 성공의 열쇠였음을 보여줍니다.

시간 절감의 과실을 고객 관계 강화로 돌렸습니다. 케이스 스터디가 지향하는 궁극적 지향점은 단순한 인력 감축이 아니라 전문적인 고객 자문과 유대감 강화였습니다. 정량적으로 입증된 지표는 80%의 시간 절감과 30…

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