How Forward Deployed Engineering is done at Decagon - Sunny Rekhi
📺 원본 영상: How Forward Deployed Engineering is done at Decagon — Sunny Rekhi
🎙️ 채널: AI Engineer
📅 정리 일자: 2026-07-29
⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료, 차트, 코드, 슬라이드 등은 포함되지 않을 수 있습니다.
개요
Sunny Rekhi는 Decagon에서 Forward Deployed Engineering(FDE)이 단순한 고객 맞춤 구현 조직이 아니라, 제품 엔지니어링과 거의 동일한 역할로 작동한다고 설명한다. Decagon은 24시간 운영되는 AI 고객지원 에이전트를 제공하는 회사이며, 이 강연은 AI 에이전트 제품이 실제 엔터프라이즈 고객 환경에 들어갈 때 어떤 방식으로 배포되고, 학습되고, 제품화되는지를 다룬다.
이 발표의 핵심은 “고객 한 곳을 위해 만든 해결책이 다음 고객에게도 작동해야 한다”는 원칙이다. AI 코딩 도구가 빠른 구현을 가능하게 만들수록, 오히려 엔지니어에게 더 희소해지는 역량은 코드를 빨리 쓰는 능력이 아니라 일회성 패치를 참아내고 확장 가능한 제품 구조로 끌어올리는 판단력이라는 점을 강조한다.
Decagon이 해결하려는 문제
Decagon은 전통적인 고객지원 경험을 AI 에이전트로 대체하려는 회사다. 사용자가 브랜드에 전화를 걸었을 때 “결제 문의는 1번, 멤버십 문의는 2번”과 같은 IVR(Interactive Voice Response)을 거치거나, 이메일을 보낸 뒤 며칠을 기다리는 경험은 여전히 많은 기업의 고객지원에서 반복된다. Rekhi에 따르면 Decagon은 이 흐름을 사람과 유사하게 응답하는 AI 고객지원 에이전트로 바꾸려 한다.
중요한 점은 Decagon이 단순히 FAQ 답변 자동화만을 목표로 하지 않는다는 것이다. 강연자는 Decagon이 고객사의 복잡한 인바운드 지원 업무를 처리하기 위해 도입된 뒤, 이미 연결된 백엔드 시스템과 고객 접점을 활용해 매출 창출 업무로 확장된다고 설명한다. 예컨대 Hertz 사례에서는 고객지원 업무를 자동화하는 데서 출발했지만, 이후 차량 리스 갱신이나 연장 시점에 고객에게 선제적으로 연락하는 흐름까지 Decagon 안에서 처리하게 되었다.
02:30 - Hertz 사례를 통해 인바운드 고객지원 자동화에서 매출 창출 워크플로로 확장되는 흐름을 설명하는 구간
이 사례는 FDE의 역할을 이해하는 데 중요하다. 고객지원 AI는 도입 순간부터 고객사의 운영 시스템, 브랜드 톤, 고객 데이터, 정책, 워크플로와 깊게 연결되어야 한다. 따라서 “모델을 붙인다”는 수준의 문제가 아니라, 특정 기업의 실제 업무가 AI 에이전트 안에서 신뢰성 있게 실행되도록 제품과 운영을 함께 설계하는 문제가 된다.
Decagon의 FDE는 두 가지 일을 한다
Rekhi는 Decagon의 Forward Deployed Engineering을 크게 두 가지 축으로 설명한다. 첫 번째 축은 AI 고객지원 에이전트의 “두뇌”를 각 기업에 맞게 구성하는 일이다. 사람이 고객지원 업무를 배울 때 정책, 말투, 예외 처리, 에스컬레이션 기준을 익히듯이, Decagon의 에이전트도 고객사가 원하는 응답 방식과 업무 절차에 맞게 설정되어야 한다.
이 과정에는 브랜드 톤앤매너, 사용자 의도 분류, 사람 상담원에게 넘겨야 하는 케이스, 백엔드 시스템에서 실행해야 하는 액션 등이 포함된다. 비밀번호 재설정처럼 비교적 단순한 작업도 인증 시스템 접근이 필요하며, 더 복잡한 업무에서는 CRM, 주문 시스템, 멤버십 시스템, 결제 시스템 등 다양한 사내 시스템과의 통합이 필요해진다. 즉, 에이전트 설정은 프롬프트 몇 줄을 바꾸는 문제가 아니라 기업 운영 체계 안에서 AI가 어떤 권한과 절차로 행동할지 정하는 일이다.
두 번째 축은 고객 현장에서 드러난 요구사항을 제품으로 되돌리는 일이다. Rekhi는 특정 엔터프라이즈 고객이 요청한 기능이 2주 뒤 다른 고객에게서도 등장하는 일이 놀라울 정도로 자주 발생한다고 말한다. 따라서 FDE는 고객 A의 문제를 해결할 때 고객 B, C, D, E에게도 적용될 수 있는 방식으로 문제를 추상화해야 한다. 이 지점에서 FDE는 단순한 구현자가 아니라 제품 감각을 가진 엔지니어가 된다.
04:20 - Decagon의 두 가지 Forward Deployed Engineering 역할, 즉 에이전트 구성과 제품 요구사항 반영을 나누어 설명하는 다이어그램 구간
Forward Deployed Engineering과 Product Engineering의 경계가 사라진다
강연에서 가장 중요한 주장 중 하나는 Decagon에서 FDE가 Product Engineering과 동일한 기준으로 운영된다는 점이다. Rekhi는 “Forward Deployed Engineering is identical to Product Engineering”이라고 표현하며, 같은 수준의 엔지니어링 역량, 같은 보고 구조, 때로는 같은 팀 안에서 일한다고 설명한다.
이러한 조직 설계는 AI 에이전트 제품의 특성과 맞물려 있다. Fortune 20급 대기업이 현장에서 제기하는 문제는 단순한 고객 맞춤 요구가 아니라 제품 로드맵에 반영되어야 할 핵심 기능인 경우가 많다. 고객의 복잡한 운영 문제를 가장 먼저 보는 사람이 FDE라면, 그 사람이 제품의 미래 기능을 정의하는 데서 떨어져 있어서는 안 된다.
전통적인 소프트웨어 조직에서는 Professional Services, Solutions Engineering, Product Engineering이 비교적 분리되어 있었다. 그러나 Decagon의 사례에서는 이 구분이 흐려진다. AI 에이전트가 고객의 실제 업무를 수행하는 제품이라면, 고객 환경에서 발생하는 예외와 요구사항이 곧 제품 품질의 일부가 되기 때문이다. 결국 FDE는 고객 옆에서 제품을 “설치”하는 사람이 아니라, 고객 현장을 제품 학습의 최전선으로 바꾸는 사람에 가깝다.
50명에서 500명으로 커지며 역할은 어떻게 분화되었나
Decagon은 1년 사이 50명에서 500명 규모로 성장했다고 소개된다. Rekhi는 이 빠른 성장 속에서 초기의 “Agent Software Engineer” 역할이 더 전문화된 두 갈래로 나뉘었다고 설명한다. 초기에는 한 사람이 에이전트의 동작 설정, 고객과의 워크플로 정리, 백엔드 통합, 제품 기능 반영까지 모두 담당했다.
규모가 커지면서 Decagon은 이 역할을 Agent Builder와 Agent Software Engineer로 나누었다. Agent Builder는 Decagon 플랫폼의 모델과 설정 방식에 깊은 직관을 가진 사람들로, 가능한 한 UI 안에서 고객별 에이전트를 구성한다. 이들은 어떤 유스케이스에서 어떤 모델 설정과 운영 방식이 적합한지 판단하며, UI로 처리되지 않는 부분은 제품으로 끌어올릴 신호로 포착한다.
07:30 - Agent Builder와 Agent Software Engineer로 역할이 분화된 조직 구조를 설명하는 구간
반면 Agent Software Engineer는 고객 현장에서 나온 제품 요구를 엔지니어링 시스템 안으로 가져오는 역할에 더 집중한다. 이들은 고객 한 곳을 위한 빠른 해결책을 만들 수 있지만, 그보다 더 중요한 책임은 그 해결책이 향후 고객에게 재사용될 수 있도록 제품화하는 것이다. 이 분화는 역할을 쪼개기 위한 분화라기보다, 반복되는 배포 경험을 조직적으로 학습하기 위한 구조에 가깝다.
AI 코딩 시대에 더 중요해진 것은 절제다
Rekhi는 AI 코딩 도구가 좋아진 상황에서 FDE가 빠지기 쉬운 유혹을 지적한다. 중요한 고객이 급한 기능을 요구하면, 엔지니어는 Codex나 Claude Code 같은 도구를 사용해 빠르게 일회성 구현을 만들고 싶은 압박을 느낄 수 있다. 그러나 그는 이제 희소한 역량이 빠른 코딩 자체가 아니라, 그 요구사항을 어떻게 확장 가능한 구조로 만들지 판단하는 절제라고 말한다.
이 관점은 AI 시대의 엔지니어링 역량을 다시 정의한다. 구현 속도가 빨라질수록 임시 패치의 비용도 더 빨리 누적될 수 있다. 특히 고객이 직접 소유하고 운영해야 하는 AI 에이전트가 프롬프트와 패치의 블랙박스로 변하면, 고객도 Decagon도 장기적으로 안정적인 운영을 하기 어렵다.
따라서 FDE는 고객의 긴급한 요구와 제품의 장기적 일관성 사이에서 균형을 잡아야 한다. 빠르게 움직이되, 빠름이 곧 일회성 대응을 의미해서는 안 된다. Rekhi가 반복해서 강조하는 원칙은 하나의 고객 요청을 해결할 때 그 해결책이 다음 고객들의 배포 속도와 품질을 높이는 방향이어야 한다는 것이다.
성공은 첫 대화에서 정의되어야 한다
Decagon이 배운 또 하나의 중요한 교훈은 고객과의 첫 대화에서 성공 기준을 명확히 해야 한다는 것이다. Rekhi는 딜을 스코핑하는 아주 초기 단계부터 고객이 무엇을 성공으로 보는지 좁혀야 하며, 가능하면 이를 문서로 남겨야 한다고 설명한다. 이는 고객지원 AI처럼 업무 범위가 쉽게 확장될 수 있는 제품에서 특히 중요하다.
여기서 성공 기준은 단순히 “AI를 도입한다”가 아니다. 어떤 채널을 지원할 것인지, 전화인지 이메일인지 문자 메시지인지 WhatsApp인지, 어떤 고객 불편을 먼저 해결할 것인지, 어떤 지표를 개선해야 하는지까지 합의되어야 한다. 이 합의가 없으면 기업 고객의 복잡한 요구가 계속 늘어나고, 실제 가치 검증은 뒤로 밀릴 수 있다.
09:30 - 고객 성공 기준과 지원 채널, 성과 지표를 초기 스코핑 단계에서 명확히 해야 한다는 내용을 설명하는 구간
AI 코딩이 구현 비용을 낮춘 시대에도 요구사항 정리는 오히려 더 중요해진다. 빠르게 만들 수 있다는 사실은 잘못된 것을 빠르게 만들 위험도 함께 키운다. Rekhi의 메시지는 명확하다. 특히 대기업 고객과 일할 때는 “일단 시작”하는 태도가 아니라, 무엇을 만들어야 하는지에 대한 정렬이 먼저 필요하다.
산업별 전문성은 배포 속도를 높이는 복리 자산이다
Decagon은 여러 산업군의 고객을 상대하면서 산업별 경험이 누적될수록 다음 배포가 빨라진다는 사실을 배웠다고 한다. 금융 서비스 고객 A, B, C를 경험한 팀이 금융 서비스 고객 D를 맡으면, 고객이 사용하는 용어와 규제적 맥락, 성공 지표, 자주 등장하는 워크플로를 이미 이해하고 있기 때문에 훨씬 빠르게 신뢰를 얻을 수 있다.
이 지점에서 FDE의 전문성은 단순한 기술 지식이 아니다. 고객의 언어로 말할 수 있고, 고객이 아직 구조화하지 못한 문제를 이미 본 패턴으로 해석할 수 있는 능력이 중요해진다. 같은 AI 에이전트 제품이라도 금융, 여행, 커머스, 기술 서비스 기업에서 요구되는 정책과 사용자 의도는 다르기 때문이다.
결국 산업별 전문성은 배포 조직의 생산성을 높이는 지식 자본이다. 한 번의 고객 배포에서 얻은 학습이 다음 배포의 요구사항 수집, 에이전트 구성, ROI 판단, 제품 기능화에 모두 영향을 미친다. Rekhi가 말하는 “모든 배포가 이전 배포보다 빨라져야 한다”는 원칙은 이 축적 효과를 전제로 한다.
엔지니어가 직접 해야 하는 일은 제품으로 반영되어야 한다
Decagon의 중요한 운영 원칙은 엔지니어가 수동으로 해야 하는 일이 발견되면 이를 제품으로 반영해야 한다는 것이다. Rekhi는 Decagon의 이상적인 방향을 자연어만으로 에이전트를 완전히 설정할 수 있는 시스템이라고 설명한다. 따라서 어떤 고객 배포에서 엔지니어가 직접 코드를 쓰거나 수동으로 설정해야 하는 일이 반복된다면, 그것은 제품이 해결해야 할 신호가 된다.
CRM 통합 사례가 이를 잘 보여준다. 초기에는 고객별로 커스텀 통합을 반복해서 만들었지만, 같은 종류의 통합이 계속 등장하자 Decagon은 이를 self-serve 방식으로 바꾸었다. 그 결과 과거에는 엔지니어가 직접 코드를 작성해야 했던 작업을 고객이나 Agent Builder 팀이 직접 처리할 수 있게 되었다.
이 변화는 단순한 효율 개선이 아니다. 제품이 고객 배포 경험을 흡수하면서 조직 전체의 병목이 줄어드는 구조적 변화다. FDE가 모든 고객 문제를 직접 처리하는 방식은 성장할수록 한계에 부딪히지만, 반복 업무를 제품화하면 고객, 비엔지니어 팀, 다음 배포 팀이 모두 같은 개선의 혜택을 받는다.
12:04 - FDE가 고객 요구를 받아 제품과 비즈니스 전체로 확장하는 퍼널 구조를 설명하는 구간
빠른 가치 증명과 장기적 확장의 균형
엔터프라이즈 고객과 일할 때 Decagon은 가능한 한 빠르게 가치를 증명하려 한다. 고객지원 AI는 채널, 사용자 의도, 정책, 백엔드 시스템, 매출 워크플로까지 포함할 수 있어 복잡도가 사실상 끝없이 커질 수 있다. 그렇기 때문에 처음부터 모든 것을 구현하려 하면 가치 검증까지 몇 달이 걸릴 수 있다.
Rekhi는 먼저 빠르게 가치를 보여준 뒤, 고객과의 다년간 파트너십 안에서 점진적으로 확장하는 접근을 강조한다. 이는 엔터프라이즈 세일즈와 제품 배포가 만나는 지점에서 매우 실용적인 전략이다. 고객은 제품이 실제 업무에서 작동한다는 증거를 빨리 원하고, 공급자는 초기 성공을 기반으로 더 넓은 워크플로로 확장할 수 있다.
이때 FDE는 어떤 문제를 먼저 풀어야 가장 빠르게 ROI를 보여줄 수 있는지 판단해야 한다. 모든 요구사항을 같은 우선순위로 다루는 것이 아니라, 고객의 과거 지원 데이터와 반복 패턴을 분석해 자동화 효과가 가장 큰 영역을 먼저 제안해야 한다. 이 때문에 Rekhi는 FDE가 실행자이면서 동시에 조언자여야 한다고 말한다.
14:24 - 과거 지원 데이터를 분석해 자동화 우선순위와 ROI가 높은 영역을 고객에게 제안하는 조언자 역할을 설명하는 구간
FDE는 실행자이자 조언자다
고객은 종종 “X, Y, Z를 해달라”고 요청한다. Rekhi는 고객이 많은 경우 옳지만, FDE가 그 요청을 그대로 수행하는 데서 멈춰서는 안 된다고 설명한다. 여러 고객을 반복해서 접하는 FDE는 특정 고객 내부에서는 보기 어려운 산업 간 패턴과 자동화 기회를 볼 수 있기 때문이다.
Decagon은 고객의 과거 지원 데이터를 수집하고 분석해 어떤 업무를 먼저 자동화해야 가장 높은 ROI가 나오는지 제안한다고 한다. 때로는 고객이 처음 요청한 문제가 실제로는 가장 큰 가치 지점이 아닐 수 있다. 이때 FDE는 고객의 요구를 존중하되, 더 큰 효과를 낼 수 있는 우선순위를 제시해야 한다.
이 역할은 AI 도입 컨설팅과 제품 엔지니어링이 결합된 형태에 가깝다. FDE는 제품을 아는 사람이고, 고객 현장을 아는 사람이며, 여러 배포 사례를 통해 축적된 비교 지식을 가진 사람이다. 따라서 좋은 FDE 조직은 고객의 요구를 빠르게 구현하는 것뿐 아니라, 고객이 AI를 어디에 적용해야 하는지 더 잘 판단하도록 돕는다.
Decagon이 얻은 세 가지 성장 원리
Rekhi는 Decagon이 빠르게 성장할 수 있었던 이유를 세 가지로 정리한다. 첫째, 고객 요구에 매우 빠르게 움직였다는 점이다. 둘째, 고객에게 단순 실행자가 아니라 조언자로 신뢰를 얻었다는 점이다. 셋째, 커스텀 작업을 제품화하는 데 집중했다는 점이다.
그러나 그는 이 원칙들이 회사가 50명일 때와 500명일 때 같은 방식으로 작동하지는 않는다고 말한다. 초기에는 강한 실행력과 고객별 대응만으로도 많은 문제를 해결할 수 있었지만, 규모가 커지면 시스템 설계가 중요해진다. 배포 경험을 공유하고, 현장의 지식을 플랫폼에 되돌리고, 에이전트가 고객 A와 상호작용하며 얻은 개선이 고객 B에게도 도움이 되도록 만드는 체계가 필요해진다.
16:58 - 현장의 지식을 플랫폼으로 되돌리고 고객 간 학습 효과를 축적하는 성장 원리를 설명하는 구간
이 변화는 AI 에이전트 회사의 성장 방식에 대한 중요한 시사점을 준다. 고객 현장에 가까이 있는 것만으로는 충분하지 않다. 현장의 학습이 제품에 축적되고, 제품의 개선이 다음 현장 배포를 빠르게 만드는 순환 구조가 만들어져야 한다. Decagon의 FDE 모델은 바로 이 순환을 조직적으로 설계하려는 시도다.
마무리 / 핵심 정리
이 강연은 Forward Deployed Engineering을 고객 맞춤 개발 조직으로만 이해하는 관점을 넘어선다. Decagon에서 FDE는 AI 에이전트를 고객 환경에 맞게 구성하고, 고객 현장에서 발견한 문제를 제품으로 되돌리며, 반복되는 수작업을 self-serve 기능으로 바꾸는 핵심 제품 조직이다.
특히 AI 코딩 도구가 엔지니어링 속도를 높인 시대에는 “빨리 만드는 능력”보다 “무엇을 제품화해야 하는지 판단하는 능력”이 더 중요해진다. 고객 한 곳을 위한 임시 구현은 당장의 만족을 줄 수 있지만, 장기적으로는 제품을 취약하게 만들 수 있다. 반대로 FDE가 고객 문제를 확장 가능한 제품 구조로 번역하면, 한 번의 배포는 다음 배포의 속도와 품질을 높이는 자산이 된다.
Decagon의 사례가 보여주는 가장 큰 교훈은 FDE가 현장과 제품 사이의 단순한 연결선이 아니라는 점이다. 좋은 FDE는 고객의 언어를 이해하고, 빠르게 가치를 증명하며, 반복되는 문제를 제품으로 흡수하고, 고객에게 더 높은 ROI 경로를 제안한다. AI 에이전트 시대의 엔터프라이즈 소프트웨어에서 이 역할은 점점 더 제품 전략의 중심에 가까워질 가능성이 크다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | How Forward Deployed Engineering is done at Decagon — Sunny Rekhi |
| 채널 | AI Engineer |
| 리포트 작성 | 2026-07-29 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.