URL: https://www.youtube.com/watch?v=cO1f2wOxSH4 날짜: 2026-08-01 (영상 게시일: 2026-07-31) 채널: a16z 출연: Jesse Zhang(Decagon 공동창업자·CEO), Ashwin "Asha" Sreenivas(Decagon 공동창업자·CTO), a16z 진행자
📌 핵심 질문 / 이 영상이 다루는 핵심 논점
고객지원 AI 에이전트로 시작한 Decagon은 어떻게 3년 만에 최대 규모 은행·항공사·통신사를 고객으로 확보하며 Sierra와 양강 구도를 형성했는가. 그리고 ==프론티어 모델이 계속 똑똑해지고 결국 AGI에 도달하더라도, "애플리케이션 레이어" 회사인 Decagon은 왜 10년 후에도 존재할 권리(모트)를 가지는가==.
- 오픈소스 모델을 파인튜닝해 워크플로우의 90%를 처리하며 레이턴시·비용·성능을 동시에 확보
- "고객지원을 잘하는 에이전트"가 아니라 "비즈니스 프로세스를 따르는 에이전트"를 만들었다는 것이 확장의 핵심
- 모델이 완벽해지더라도 엔터프라이즈 내부에 안전하게 배포하려면 거버넌스·협업·테스트·레거시 연동을 담당하는 소프트웨어 레이어가 반드시 필요하며, 그것이 애플리케이션 회사의 장기 모트다
Decagon은 프론티어 랩(Anthropic, OpenAI)이 "마지막 스타트업"이 되어 모든 것을 집어삼킬 것이라는 2026년 상반기의 지배적 내러티브에 정면으로 반박한다. 인간이 이미 "일종의 AGI"이면서도 여전히 CRM·데이터베이스 같은 소프트웨어가 필요하듯, AGI 에이전트도 작업을 저장하고 정보를 꺼내 쓸 어딘가가 필요하다는 것이 이들의 핵심 논리다.
1. 모델 전략: 오픈소스 vs 프론티어, 그리고 "가짜 트레이드오프"
Decagon은 비용이 아니라 레이턴시를 위해 오픈소스로 전환했고, 그 결과 비용 절감은 "공짜 보너스"로 따라왔다.
1.1. 오픈소스 전환의 실제 계기
- 초기: 프론티어 일변도
- 창업 초기 전략: 서비스를 일단 작동시키는 게 목표였던 시절엔 무조건 프론티어 모델(OpenAI, Anthropic)을 썼다. 당시 두 랩은 서로를 앞지르며 경쟁하던 시기였다.
- 전환점: 대형 고객(수백만 고객 보유)과 일하고 음성 에이전트를 출시하면서 레이턴시가 결정적 변수가 됐다. "좋은 답변"만으론 부족하고 "매우 빠른 답변"이 필요해졌다.
- 오픈소스로의 전환 (약 1년 전 시작)
- 프론티어 랩의 소형 모델 한계: 프론티어 랩도 스몰 모델을 내놓지만, 원하는 방식으로 통제하기 어렵고 기본 성능도 필요한 과제 수준에 못 미친다.
- 파인튜닝의 필요성: 그래서 오픈소스 모델을 가져와 직접 파인튜닝·개조해야 했다. 이를 위해 비용이 많이 드는 전담 리서치 팀(Decagon Labs)을 꾸렸다.
1.2. 모델을 평가하는 3차원 프레임과 "가짜 트레이드오프"
- 비용·지능·레이턴시 3축
- 일반적 트레이드오프 구조: 모든 모델은 비용/지능/레이턴시 세 축으로 평가할 수 있고, 필요에 따라 어느 지점에 위치할지 결정한다.
- Decagon의 선택: 에이전트의 개별 태스크(예: "이 대화 주제가 뭔지 파악" "악성 사용자인지 판별")는 프론티어 모델의 범용 지능을 요구하지 않는다. 지능을 일부 포기하는 대신 레이턴시 이득을 얻었다.
- "똑똑한 모델 vs 저렴한 모델"은 잘못된 이분법
- 실제 관찰: 트위터식 논쟁은 "가장 똑똑하지만 비싼 모델"이냐 "덤 다운시켜 저렴하게"냐로 프레이밍되지만, Decagon의 경험상 이는 거짓 트레이드오프다.
- 근거: 특정 과제에 파인튜닝된 "더 멍청한" 소형 모델이 그 과제에서는 크고 똑똑한 최신 프론티어 모델보다 더 높은 성능을 낸다. 결과적으로 태스크 성능·비용·속도 세 가지를 모두 잡는다.
1.3. 오늘날의 모델 배분과 프론티어가 여전히 필요한 영역
- 90 대 10 구조
- 오픈소스 90%: 현재 Decagon 워크플로우의 90%가 오픈소스 기반이며, 주 목적은 음성 에이전트의 레이턴시 최적화였다.
- 프론티어 10%: 신규 프로젝트·신규 제품에는 여전히 프론티어(클로즈드 소스) 모델을 쓴다.
- 프론티어가 필요한 보조(auxiliary) 태스크
- 정형화된 보조 모델: 리부킹, 헬스케어 프로세스 처리처럼 잘 정의된 태스크는 스마트한 보조 모델로 충분하다.
- 비정형·탐색적 태스크: 최근 출시한 "Duet Autopilot"(핵심 대화 에이전트를 개선하는 에이전트)은 수백만 대화를 리뷰해 트렌드를 찾고 모델 변형을 만들어 비교하는, 훨씬 광범위하고 개방적인 탐색 작업이다. 이런 일에는 프론티어 급 지능이 필요하다고 판단한다.
1.4. 엔터프라이즈의 오픈소스 파인튜닝 자체 내재화는 시간이 걸릴 것
- 비트리비얼한 작업
- 데이터·이밸류에이션 요구: "오픈소스 쓰기로 했다"고 바로 되는 게 아니라 데이터를 확보하고, 무엇보다 좋은 평가(eval) 체계를 만들어야 한다. Decagon의 eval은 자사 태스크에 특화돼 있어 공개 벤치마크로는 대체가 안 되고 자체 벤치마크를 만들어야 했다.
- 엔터프라이즈 관성: 대기업은 모델 리스크 거버넌스, 보안 검토 등을 거쳐야 해서 움직임이 느리다. 결국은 그 방향으로 가겠지만 속도는 느릴 것으로 본다.
- 오픈소스 전환의 손익분기점
- "유스케이스가 굳어졌을 때" 전환이 이득: 프로덕션에서 규모가 커지고 에이전트의 형태가 확정된 시점부터는 오픈소스가 레이턴시·비용 양쪽에서 명백히 유리해진다.
- 신규 유스케이스는 여전히 프론티어: 새롭고 실험적인 유스케이스는 인프라 걱정 없이 API만 호출하면 되는 프론티어 모델을 계속 쓰게 된다 — 이 때문에 엔터프라이즈 전체로 보면 오픈소스 인퍼런스 비중이 오히려 최근 줄어드는 역설적 현상이 나타난다(신규 유스케이스가 계속 쏟아지기 때문).
2. 인소싱 vs 아웃소싱 판단 기준, 그리고 토크노믹스에 대한 태도
2.1. 무엇을 자체 구축하고 무엇을 사올 것인가
- 자체 구축 기준: 유스케이스와 강하게 결합된 것
- 엔드투엔드 평가 철학: Decagon은 개별 태스크의 loss curve가 아니라 "이 모델이 다른 모델들과 함께 작동해 최종 고객 결과를 만들어내는가"를 평가 기준으로 삼는다. 이 평가 인프라 자체가 자사 유스케이스에 워낙 특화돼 있어 직접 만들 수밖에 없었다.
- 아웃소싱 기준: 회사 공통 사항
- 라벨링 데이터·데이터셋 다양성 측정: 여러 기업에 공통적으로 필요한 작업은 벤더에서 구매해 모델을 더 빨리 프로덕션에 올리는 쪽을 택한다.
- 최종 목표: "최고의 모델을 최대한 빨리 프로덕션에 올리는 것"이 유일한 판단 기준이다.
2.2. 토크노믹스(tokenomics)는 우선순위가 아니다
- 레이턴시·정확도가 1순위, 비용은 부수 효과
- 드라이버가 아니라 결과: 비용·레이턴시·성능을 트레이드오프하지 않고 레이턴시와 성능을 최적화한 결과로 비용 절감이 "공짜로" 따라왔다.
- 성장 단계 기업의 우선순위: 지금 단계에서 가장 중요한 건 성장이지 비용이 아니다. 고객은 대화 비용이 얼마인지 신경 쓰지 않고 에이전트 성능만 신경 쓴다.
- 토큰 사용량은 오히려 증가 추세
- 역설적 현상: 대화당 토큰 사용량은 시간이 갈수록 늘고 있다. 품질 향상을 위한 체크, 병렬 처리 등으로 모델 호출 횟수 자체가 늘었기 때문이다.
- 토크노믹스 논쟁의 진짜 대상: "프론티어 모델만 쓰다가 오픈소스로 갈아탈지"를 고민하는 단계의 기업에게나 유효한 논쟁이며, 이미 오픈소스 모델을 빠르게 학습·배포하는 역량을 확보한 기업에게는 덜 중요한 이슈가 된다.
3. "애플리케이션 vs 인프라(랩)" 논쟁 — 거짓 이분법
2026년 상반기를 지배한 "프론티어 랩이 마지막 스타트업"이라는 내러티브에 대한 정면 반박.
3.1. 엔터프라이즈가 애플리케이션 회사와 파트너십을 맺는 이유
- 파인튜닝은 고객 맞춤이 아니라 유스케이스 맞춤
- 일반적 오해: 많은 사람이 파인튜닝을 "특정 고객사에 맞추는 것"으로 오해하지만, Decagon의 파인튜닝 대부분은 "고객지원"이라는 유스케이스 자체에 맞춘 것이다.
- 규모의 경제: Decagon처럼 이 일만 전담하는 회사는 이 튜닝에 막대한 시간·리서치를 투입할 가치가 있지만, 개별 엔터프라이즈가 자기 연구 자원을 고객지원 행동 튜닝에 쓸 가치는 낮다.
- 비즈니스 로직은 파인튜닝이 아니라 컨텍스트로 주입해야 함
- 파인튜닝의 함정: 자사 프로시저를 파인튜닝으로 가르치면, 프로시저를 바꿀 때마다 매번 되돌려 재학습해야 해서 말이 안 된다. 인컨텍스트로 주입해야 한다.
- 계속 반복되는 엔지니어링 부담: 직접 에이전트를 만들면 런칭 다음 날 대화 로그를 보고 "이 세 가지를 바꿔야겠다"는 게 계속 나오고, 그때마다 엔지니어링 공수가 반복적으로 들어간다.
- 비즈니스 로직이야말로 애플리케이션 레이어의 존재 이유
- 모델과 무관한 영역: "고객의 항공편이 취소돼 3명을 한 번에 리부킹해야 한다"는 것은 비즈니스 로직이지 모델 자체와는 무관하다. 이것을 인코딩하는 일은 애플리케이션 레이어에 남는다.
- 랩도 애플리케이션을 만들지만 범용적: 랩들도 애플리케이션 역량을 갖추겠지만 상당히 범용적인 수준에 그칠 것이고, Decagon 같은 "깊은 수직 영역"에서는 통합·비즈니스 로직 캡처·테스트/실험·QA·컴플라이언스 모니터링 툴링까지 갖춘 깊은 제품이 필요하다는 게 이들의 테제다.
3.2. "랩이 스타트업을 다 죽인다"는 견해에 대한 반박: 인간도 "일종의 AGI"다
- AGI 이후에도 소프트웨어는 필요하다
- 비유의 핵심: 인간 자체가 일종의 AGI인데도 데이터베이스에 뭔가를 저장하고 CRM으로 추적하는 소프트웨어가 필요했다. AGI 에이전트들도 마찬가지로 작업을 저장하고 정보를 꺼내 쓰고 추론할 어딘가가 필요할 것이다.
- 영향받는 것은 일부 SaaS: "사람이 일하기 위한" 용도로만 설계된 일부 SaaS 카테고리는 타격을 받겠지만, 소프트웨어 전체가 사라지지는 않는다.
- 양방향 침식(bleeding into each other's space)
- 랩의 애플리케이션화: 랩들은 엔터프라이즈가 ROI를 체감하는 방식이 애플리케이션이라는 걸 알기에 애플리케이션 레이어를 계속 침범한다.
- 애플리케이션의 모델 내재화: 반대로 애플리케이션 회사는 자체 모델을 만들어 성능·레이턴시·비용을 더 짜낼 수 있음을 깨닫고 랩의 영역으로 들어간다. 장기적으로 애플리케이션 레이어 회사가 특정 수직영역의 "랩"이 되는 방향으로 수렴할 수 있다.
4. Forward Deployed Engineer(FDE)와 Agent PM: "그라인드"에서 "제품화"로
4.1. FDE에 대한 두 가지 흔한 오해
- FDE = 컨설팅이라는 오해
- 팔란티어와의 차이 강조: Decagon의 Ashwin은 팔란티어 출신(deployment strategist)이지만, 팔란티어처럼 대규모 딜을 단번에 클로징할 수 있는 회사는 극소수이며, 그 전략을 그대로 베끼면 "현대판 대행사(에이전시)"가 될 뿐이라고 지적한다.
- 인용: 전 팔란티어 CTO의 표현으로 "forward deployed engineer들은 고통을 먹고 제품을 배설한다(eat pain and excrete product)"는 문구를 언급한다. FDE는 자유 컨설팅이 아니라 제품 산출을 위한 수단이어야 한다.
- FDE는 초기 단계에만 유효한 모델
- AI 제품은 워크플로우 자체가 새롭다: 5년 전 SaaS는 사용자가 뭘 하려는지 이미 다 파악돼 있었지만, AI 제품은 아무도 워크플로우를 써본 적이 없어 FDE가 고객과 함께 워크플로우를 "처음으로" 배우는 역할을 한다.
- 장기적으로는 제품화해야 함: 워크플로우를 알게 된 후에는 FDE에 의존하지 않고 제품화해야 하며, 그렇지 못하면 "고급 에이전시"에 불과하다.
4.2. Decagon의 FDE·Agent PM은 실제로 핵심 제품(core product)을 만든다
- 일회성 산출물 금지 원칙
- FDE의 산출물 기준: 고객사와 일하며 "제품에 없는 무엇이 필요한가"를 발견하지만, 그 결과물은 해당 고객 전용 일회성이 아니라 다음 10개 고객이 같은 요청을 하면 공짜로 받을 수 있는 핵심 제품 기능이어야 한다.
- Agent PM의 역할
- 프로세스 개선까지 포함: Agent PM은 제품이 오늘 왜 부족한지, 엔터프라이즈 안에서 실제로 배포 가능하려면 뭐가 필요한지를 파악하며, 이는 제품 개선뿐 아니라 고객의 업무 프로세스를 AI 도입에 맞게 바꾸는 "프로세스화(processizing)" 작업까지 포함한다.
5. Duet & Duet Autopilot — "에이전트를 만드는 에이전트"
Decagon이 스스로 "매우 마법 같다(very magical)"고 표현한 사내 도구. 프론티어 랩의 리즈닝 모델 발전(주로 Claude Code류 코딩 에이전트를 겨냥해 만들어졌지만 Duet에도 잘 맞았던)이 있었기에 처음으로 가능해졌다.
5.1. 기존 방식의 반복 노동
- AOP(Agent Operating Procedure) 수작업 작성
- Decagon 자체 포맷: AI에게 업무 방식을 가르치는 자체 절차 포맷(AOP)을 직접 만들어 이전에는 이를 전부 코드로 작성해야 했다.
- 부수 작업들: 시스템 접근·API 호출용 툴 작성, 테스트·시뮬레이션 작성, 프로덕션 배포 후 대화 수동 모니터링까지 방대한 부가 작업이 필요했다.
- 가장 큰 비효율 지점: 신규 고객마다 AOP를 처음부터 수작업으로 써야 하는 것과, 런칭 후 대화를 리뷰하며 에이전트를 지속 개선하는 반복 작업이었다.
5.2. Duet: 두 번째, 더 크고 느린 에이전트
- 입력과 산출
- 입력: "아직 아무것도 구축되지 않았지만, 여기 대화 기록들과 문서가 있다"는 정도만 주면 된다.
- 산출: Duet이 스스로 최적의 프로시저 작성 방법을 찾아내고, 이에 맞는 테스트·시뮬레이션까지 자체적으로 작성하며, 프로덕션에 올라간 이후에는 모든 대화를 모니터링해 잘되는 지점/못하는 지점을 플래그하고 개선안을 초안으로 작성해준다.
- AOP 자체가 이 패턴의 결과물: "코드로 프로시저 작성 → 순수 텍스트로 작성하면 훨씬 쉽고 효율적이지 않을까"라는 발견 자체가, 바로 이 FDE 반복 작업을 제품화한 사례였다.
5.3. Duet Autopilot: 핵심 에이전트를 개선하는 에이전트
- 역할: Duet으로 프로시저를 작성한 이후에도 에이전트가 라이브된 뒤 대화를 리뷰하고 개선점을 찾는 데 여전히 많은 시간이 든다는 걸 발견하고, 이를 제품화한 것이 Duet Autopilot이다.
- 작동: 수백만 건의 최근 대화를 리뷰해 트렌드를 찾고, 핵심 대화 모델의 변형(variant)들을 만들어 어떤 변형이 더 나은 성능을 내는지 비교·검증한다.
5.4. "제품화 원칙"
- 모든 투자 판단의 기준: FDE·엔지니어링 투자를 어디에 할지는 "포워드 디플로이드 업무에서 무엇을 제품화할 수 있는가"라는 하나의 질문으로 수렴한다. 궁극적으로 고객 대면 인력이 덜 필요해지는 방향으로 계속 제품화한다.
6. 세일즈 전략과 Sierra 대비 "글래스박스" 포지셔닝
6.1. 실제 이탈 고객 사례: Sierra → Decagon
- Sierra의 "블랙박스" 경험
- FDE 의존 구조: 고객이 Sierra와 일할 때는 거의 전적으로 FDE를 통해서만 새 저니(journey)를 만들거나 대화 인사이트를 얻을 수 있었다.
- 결과: FDE가 다른 업무에 배치되면 병목이 생겨, 해당 고객은 1년 동안 저니를 3개밖에 만들지 못했다.
- Decagon 전환 후 결과
- 속도 차이: 같은 고객이 Decagon(Duet)으로 전환한 뒤 한 달 만에 새로운 저니 7개를 스스로 구축했다.
- 핵심 차이: Decagon이 옆에서 도와주더라도 최종적으로는 고객 스스로 통제하고 반복(iterate)할 수 있는 "제품"을 제공한다는 점이 "글래스박스" 철학의 핵심이다.
6.2. 세일즈 조직 구성과 창업자의 직접 관여
- 창업자 시간 배분: Jesse는 시간의 약 80%를 세일즈에 쓴다고 밝혔다.
- 딜을 잘게 쪼개는 전략(piecemeal)
- 초기 인력 프로필: 초기 세일즈 팀에는 비전통적 세일즈 배경 인재와 아이비리그 운동선수 출신이 많았다.
- 대형 조직 공략법: 대형 은행 같은 조직은 모든 서페이스·모든 유스케이스를 한꺼번에 배포하지 않고, 상위 1~2개 유스케이스를 골라 먼저 "승리"를 확보하는 방식으로 접근한다. 이는 세일즈팀이 아니라 창업자가 직접 프로세스·오라클·제품 관점에서 설계해야 하는 일이라고 강조한다.
- 딜 클로징 속도의 비결: 배포 여정의 사전 매핑
- 엔터프라이즈의 진짜 질문: "이 제품이 나에게 통할까"뿐 아니라 "실제로 라이브까지 갈 수 있을까"(특히 금융 서비스 등 규제 산업)가 관건이다.
- 세부 로드맵 제시: 모델 리스크 프로세스, 테스트 프로세스, 초기 롤아웃 방식, 이슈 발생 시 대응·재발 방지 방안까지 첫 미팅에서 100% 라이브까지의 여정을 구체적으로 제시한다. 기술 자체만큼이나 "배포 프로세스를 함께 설계해주는 것"이 대형 딜 클로징의 핵심이라고 강조한다.
7. 고객지원에서 "AI 컨시어지"로 — 유스케이스 확장의 동력
7.1. 확장 사례
- 인바운드 세일즈로 확장: 고객지원용으로 도입했던 고객사가 "우리 제품과 브랜드에 대해 이미 잘 알고 있으니 인바운드 세일즈 문의 응대·디스커버리·적격 리드를 엔터프라이즈 담당자에게 배정하는 것도 해달라"고 요청한 사례.
- 운영 워크플로우로 확장: 고객 계정에 문제가 감지되면 선제적으로(proactively) 연락하는 운영 워크플로우로 확장한 사례.
7.2. 확장을 가능케 한 핵심: "비즈니스 프로세스를 따르는 에이전트"라는 처음부터의 설계
- 의도된 유연성: Decagon이 처음부터 의도적으로 만든 것은 "고객지원을 잘하는 에이전트"가 아니라 "비즈니스 프로세스를 잘 따르는 에이전트"였다. 세일즈 리드 적격 심사도, 고객지원 질문 응대도 결국 "비즈니스 프로세스를 따르는" 동일한 문제로 환원된다.
- 모델이 좋아진 지점: 지시 따르기(instruction-following) 능력
- 과거: 매우 좁고 구체적인 지시만 줘야 했다.
- 현재: 더 넓고 큰 지시를 줘도 모델이 사람처럼 해석해 빈틈을 채운다. 고객지원은 좁은 경로면 충분하지만, 세일즈 디스커버리는 열린 질문과 대화의 자연스러운 흐름(bob and weave)이 필요한데, 모델이 이를 감당할 수 있게 됐다.
7.3. 12개월 로드맵보다 빠른 실행
- 로드맵의 무의미함: AI 발전 속도가 너무 빨라 12개월 단위의 정밀 로드맵은 현실적으로 의미가 없고, 테마 정도만 파악한 뒤 "지금 당장" 만드는 게 낫다고 본다.
- 장기 비전은 고정: "AI 에이전트가 브랜드/비즈니스의 프론트도어가 되어, 리액티브든 프로액티브든 모든 고객 상호작용을 처리해야 한다"는 컨시어지 비전은 확고하며, 무엇을 만들지는 고객들의 시그널을 따라간다.
8. 병목: AI가 아니라 채용, 그리고 "1인 유니콘" 신화 반박
8.1. 진짜 병목은 사람
- 토큰은 풍부, 판단력은 부족: "우리는 토큰을 게걸스럽게 소비하는 존재"라고 표현할 만큼 토큰 사용량이 많지만, 정작 부족한 건 훌륭한 인재다. AI 에이전트가 "무엇을 만들지" 판단하거나 "이 정도면 완성됐다"는 감각(taste)을 갖기엔 아직 이르다고 본다.
- AI 코딩 스타트업이 채용을 줄이지 않는 이유: AI를 가장 정교하게 쓰는 사용자 집단인 AI 코딩 스타트업들조차 미친 듯이 채용 중이다. 모두가 동일한 도구에 접근할 수 있게 되면 경쟁자도 더 빨리 더 많이 만들 수 있으므로, 결국 모두가 채용을 늘리고 산출량도 늘리는 결과로 수렴한다("1/3 시간에 끝낼 수 있다"는 건 "3배 더 만들 수 있다"로 이어진다).
8.2. 아직 해결되지 않은 기술적 병목
- 음성-투-음성(voice-to-voice) 모델은 여전히 활발한 연구가 진행 중인 프론티어 영역이다.
- 소형 모델을 "기본 상태에서" 더 똑똑하게 만드는 것도 계속 지켜보는 영역이다.
- 다만 비즈니스 관점에서 병목은 모델보다 "회사를 얼마나 빨리 지을 수 있는가"에 있다고 강조한다.
9. "그라인드 슬롭(grind slop)" 논쟁과 팀 문화
9.1. "그라인드"를 강요하지 않는다는 원칙
- 자발성 강조: 주말 출근을 강제하거나 근무시간을 관리하지 않는다. 사무실에 있는 이유는 커뮤니케이션을 극대화하기 위해서다.
- 일 자체가 재미의 원천: "야망 있는 사람들에 둘러싸여 있으면 그게 그냥 정상이 된다"는 식으로, 열심히 일하는 것을 특별한 미덕으로 포장하지 않는다.
9.2. "팀 스포츠"로서의 조직 문화
- 기능 간 경계가 옅음: 엔지니어가 초기 세일즈콜에 들어가고, 세일즈 담당자가 제품 디버깅에 참여하는 등 부서 간 경계를 매우 흐리게 운영한다.
- 국제 오피스 확장 시 문화 유지 방법
- 신규 입사자 SF 온보딩: 신규 입사자는 입사 시 몇 주간 샌프란시스코로 데려와 "원조 데카곤 문화"에 몰입시킨다.
- 허브 인력 파견: 뉴욕·런던처럼 이미 규모가 커진 오피스는 자체 문화가 자리잡았지만, 신규 오피스(호주 등)에는 기존 허브 인력을 몇 달간 파견해 문화가 지나치게 달라지지 않도록 관리한다.
10. 국제화 전략
10.1. 예상보다 이른 해외 진출의 두 가지 동력
- 톱다운 압력: 어느 기업이든 이사회·경영진이 "일단 뭐라도 AI를 도입해야 한다"는 압박을 받고 있고, 코딩 에이전트·고객서비스가 가장 쉬운 시작점으로 꼽힌다.
- 언어 장벽의 해소: 과거엔 "우리 앱이 독일어를 지원하지 않는다" 같은 것이 진출 장벽이었지만, AI 덕분에 언어 적응이 훨씬 쉬워졌다.
10.2. 선택과 집중
- 투자 기준: "이미 미국 오피스를 통해 자연스럽게 고객을 확보한 시장"에만 깊게 투자한다.
- 간과되는 장벽들: 데이터 레지던시 요건, 시장을 더 잘 아는 로컬 경쟁자 등은 여전히 신중하게 다뤄야 할 변수다.
10.3. 수직 vs 수평, 그리고 CRM의 미래
- 시장 통합(consolidation) 전망: 지리·수직영역·시장 세그먼트 모두에서 장기적으로는 통합이 일어날 것으로 본다. Salesforce, Zendesk가 역사적으로 수평 플랫폼이 승리했던 것처럼, 이 업계도 규모와 깊이를 갖춘 수평 플랫폼이 승리할 것이라는 게 Decagon의 테제다(수직 특화 기능은 시간이 지나며 점차 추가).
- CRM은 사라지지 않는다
- 데이터 저장의 필요성 불변: 인간 컨시어지도 결국 CRM에 정보를 기록해 나중에 추적하듯, AI 컨시어지도 정보를 저장할 곳이 필요하다.
- 인터페이스만 달라질 가능성: 향후 CRM은 그래픽 인터페이스 없이 에이전트가 직접 API로 사용하는 "진실의 원천(source of truth)"으로만 남을 수 있다는 시나리오도 제시한다.
- Decagon의 입장: 자사는 CRM을 만들 의사가 전혀 없으며, "에이전틱 레이어"에만 집중하겠다고 명시적으로 밝힌다.
11. AI와 일자리 — "일자리는 죽이지만 커리어는 죽이지 않는다"
11.1. 실제 관찰된 제번스의 역설(Jevons Paradox) 사례
- 잠재 수요가 공급을 초과: 비용이 30% 절감된다고 팀의 60%를 해고하는 회사는 거의 없었다. 대신 "이미 가치가 확인된 서비스를 더 저렴하게 더 많이 제공"해 고객 유지·활성화를 높이는 데 쓴다.
- 구체적 수치 사례: 약 2년 반 전 한 고객사는 월 약 5만 건의 티켓을 처리하고 있었는데, Decagon 도입 후 실제로는 훨씬 더 많은 잠재 수요가 있었음을 발견했다. 이에 지원 접근성을 확대(모든 페이지에 노출, 무료 사용자에게도 즉시 지원 제공)해 이전에는 드러나지 않았던 수요를 흡수했다.
11.2. "일자리는 죽지만 커리어는 안 죽는다"는 프레임
- 자동화 대상은 "지루하고 하찮은" 반복 업무: 매우 고빈도·단순 반복인 업무(전화 받고 클릭해서 답 찾아주는 일)는 AI가 해야 하는 일이지 인간이 계속할 일이 아니다.
- 거의 무한한 대체 업무: 대신 고객을 더 행복하게 만드는, 사람이 할 수 있는 일은 사실상 무한하다고 본다. 실제로 고객사에 따라 BPO 활용을 크게 줄인 곳도 있고, 성장 속도가 너무 빨라 오히려 인력 규모를 유지하면서 매출 창출형 업무로 전환한 곳도 있다 — 상황에 따라 다르다(depends on the customer).
12. Decagon의 장기 모트: "엔터프라이즈에 배포 가능하게 만드는 인프라"
12.1. 모델이 완벽해져도 필요한 레이어
- 모델 자체의 완벽함은 배포 가능성과 무관: "모든 모델이 완벽하고 실수하지 않는다"고 가정해도, 엔터프라이즈 내부에 이를 배포하려면 다음이 필요하다.
- 가드레일: 모델이 무엇을 할 수 있고 할 수 없는지 명시하고, 파국적 실수를 막는 장치.
- 협업 인프라: 각 영역 전문가인 사내 수백 명이 협업해 에이전트가 예상대로 작동하는지 확인할 수 있는 체계.
- 규제 준수 테스트: 규제선을 넘지 않는지 테스트·검증하는 체계.
- 인사이트 추출: 수백만 건의 대화에서 다른 팀에 유용한 인사이트를 뽑아내는 체계.
- 레거시 연동: 기업이 이미 갖고 있는 레거시 시스템과의 통합.
- 단기 모트, 장기는 미지수: "이런 게 커모디티화되면 그다음엔 어떻게 될지는 3년 후에나 알 수 있을 것"이라며, 최소 향후 몇 년은 이 엔터프라이즈 배포 인프라가 핵심 모트가 될 것이라 전망하되 장기적 확신은 유보한다.
13. 창업자 개인의 AI 활용 — "나 자신을 위한 Jesse/Asha 봇"
13.1. 개인 컨텍스트 캡처 에이전트
- 문제의식: 모델은 아이디어 브레인스토밍에는 이미 매우 똑똑하지만, 병목은 "비즈니스 컨텍스트"다. 매번 제약 조건·목표를 다시 설명해줘야 하는 게 비효율적이었다.
- 해결책: 옆에서 계속 지켜보며 채용 후보·채용 필요 인력·진행 중인 딜·현재 당면한 문제들을 자동으로 컴파일하는 개인용 에이전트를 직접 만들었다. 이후 "이 후보 어때?"라고 물으면 과거 유사 후보와 비교해 보완적 인재가 필요한지 등을 스스로 추론해준다.
13.2. 공동창업자 관계와 AI 사고 파트너의 유사성
- 공동창업의 이점: 아이디어를 빠르게 주고받으며 결론에 더 빨리 도달할 수 있다는 점이 1인 창업자 대비 결정적 장점이라고 본다.
- AI를 "반박하는 파트너"로 활용: 과거 모델은 무엇이든 동의하는 "예스맨"이었지만, 최근 모델(예: "반박하라, 직설적으로 말하라"는 시스템 프롬프트를 적용한 Claude)은 실제로 반대 의견을 낸다. Jesse가 이 프롬프트를 아내에게 공유했더니 "하루 종일 클로드가 너무 못되게 굴어서 껐다"는 에피소드를 전한다.
14. X(트위터) vs LinkedIn 전략
14.1. 초기: LinkedIn 중심
- 초기엔 "고객이 X가 아니라 LinkedIn에 있다"는 판단으로 LinkedIn 위주였다.
14.2. X의 재발견: "모두가 읽는 단일 타임라인"
- 자기 홍보는 무의미: 자기 회사를 대놓고 홍보하는 포스팅은 트랙션이 거의 없다.
- 사고 리더십의 가치: X는 모두가 읽는 하나의 타임라인이라 사람들의 생각을 "동기화"시키는 힘이 있다. 여기서 목소리를 내는 것 자체가 가치가 있다.
- "프리스트 클래스(priest class)" 비유: (Jeremy Giffon이 언급했다는) 과거엔 억만장자가 되는 게 최고의 지위 상징이었지만, 이제는 억만장자가 된 사람들도 세상의 화두를 좌우하는 "X 인플루언서"가 되고 싶어 한다는 관찰을 인용한다.
- 파급 효과: X에서 화제가 되면 팟캐스트에서 언급되고, 이는 다시 메인스트림 언론 보도로 이어지는 연쇄효과가 있다(예: 뉴욕타임스 보도 사례 언급).
14.3. 채널별 용도 구분
- LinkedIn: 공지, 제품 소개, 펀드레이즈 등 "클래식한" 발표용.
- X: 그 순간의 화두(예: 오픈소스 vs 클로즈드소스 논쟁) 위에 자신을 위치시키는 용도. AI 리서치 인재 채용에도 유효.
- 글쓰기는 창업자 본인이 직접 하며, AI는 어떤 주제로 쓸지 브레인스토밍하는 데만 활용한다.
주요 발언 모음
"An AI agent should just be the front door of your business. And every interaction, whether it's like reactive or proactive with a customer, should be handled by AI." — Jesse Zhang
"The thing that we built was not an agent that does customer support well, but rather an agent that follows business process well." — Jesse Zhang
"Even once you have AGI, agents are going to need somewhere to store work and pull information from and reason about things. I don't think software as a whole in any meaningful way is going away." — Jesse Zhang
"Forward deployed engineers eat pain and excrete product." (전 Palantir CTO의 표현 인용)
"It's like AI will kill jobs but not careers in a way, because like those jobs that are being done currently should not be done by humans." — Jesse Zhang
"So today 90% of our workflow is on open source... on the specific task we want them to do, they actually outperform the large, smart, state-of-the-art models." — Ashwin Sreenivas
"Hiring." — 현재 가장 큰 병목이 무엇이냐는 질문에 대한 즉답
핵심 데이터 & 수치
- 오픈소스 90% / 프론티어 10%: Decagon 전체 모델 워크플로우 중 오픈소스 파인튜닝 모델 비중이 90%, 신규·실험적 프로젝트에 프론티어 모델 10% 사용
- 오픈소스 전환 시작 시점: 약 1년 전(리서치팀 Decagon Labs 신설)
- Sierra→Decagon 전환 고객: Sierra 사용 시 1년간 저니(journey) 3개 구축 → Decagon(Duet) 전환 후 한 달 만에 저니 7개 구축
- 월 티켓 볼륨 사례: 약 2년 반 전 한 고객사 월 약 50,000건 → Decagon 도입 후 지원 접근성 확대로 잠재 수요 추가 발굴
- Jesse의 세일즈 시간 비중: 약 80%
- 영상 길이: 약 80분(4,815초), 2026-07-31 게시
결론 및 시사점
- AI 애플리케이션 회사가 프론티어 랩에 잠식되지 않으려면, 모델 자체가 아니라 "비즈니스 프로세스를 캡처하고 엔터프라이즈에 안전하게 배포 가능하게 만드는 인프라 레이어"에서 깊이를 확보해야 한다.
- 모델 선택은 "가장 똑똑한 모델이냐 저렴한 모델이냐"의 이분법이 아니라, 좁은 태스크에 파인튜닝된 소형 모델이 비용·속도·정확도를 동시에 잡을 수 있다는 인식에서 출발해야 한다.
- Forward Deployed Engineering은 신생 AI 제품이 워크플로우를 처음 배우는 초기 단계에서만 정당화되며, 궁극적으로는 그 산출물을 반드시 제품화(productize)해야 한다. 그러지 못하면 "현대판 컨설팅/에이전시"로 전락한다.
- AI로 인한 자동화는 반드시 인력 감축으로 이어지지 않는다 — 비용이 낮아지면 이전엔 억눌려 있던 잠재 수요(latent demand)가 드러나는 제번스의 역설이 실제로 관찰된다.
- "일자리는 사라져도 커리어는 사라지지 않는다"는 프레임은, 반복적·저부가가치 업무는 AI가 흡수하되 인간은 더 가치 있는(그리고 아직 무한해 보이는) 업무로 이동한다는 낙관적 시나리오를 제시한다. 단, 이는 산업·기업별로 편차가 크다는 점도 함께 인정해야 한다.