AI tools for Forward Deployed Engineering — Vasuman Moza, Varick Agents

URL: https://www.youtube.com/watch?v=l0FLhNqBOic 날짜: 2026-07-29 채널: AI Engineer (aiDotEngineer)

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

AI는 이미 작업의 실행(execution)을 거의 해결했으며, ==다음 병목은 "얼마나 헤드카운트를 늘리지 않고 고객 비즈니스 깊숙이 들어갈 수 있는가"==다. Varick Agents는 이 병목을 Forward Deployed Engineer(FDE)와 이들을 보조하는 자체 "FD Agent"로 해결한다.

• 몇 년 전만 해도 "AI가 종단간(end-to-end) 태스크를 해결해준 적 있냐"고 물으면 거의 아무도 손을 들지 않았지만, 지금은 모두가 손을 든다 — 실행은 더 이상 병목이 아니다
• 진짜 병목은 "얼마나 그 비즈니스를 깊이 이해할 수 있는가"다. 의료 회사의 영업팀과 SaaS 회사의 영업팀은 완전히 다르게 운영되기 때문
• MIT 리뷰 등 통계에 따르면 생성형 AI 파일럿의 95%가 프로덕션에 도달하지 못하고, 별도 통계로 87%는 측정 가능한 ROI를 만들지 못하는데, 원인은 AI를 "고장난 프로세스" 위에 그냥 얹기 때문

발표자 Voss(Varick Agents CEO)는 실행 병목이 해소된 지금, "AI를 중심으로 업무를 어떻게 재설계할 것인가"가 다음 시대의 핵심 과제라고 주장하며, 이를 위한 자사의 FDE 방법론과 사내 개발 도구 "FD Agent"를 소개한다.

---

1. 왜 Forward Deployed Engineering이 필요한가

AI가 실행을 해결한 지금, 병목은 비즈니스 프로세스를 이해하고 재설계하는 능력으로 이동했다.

1.1. 실행(execution) 병목의 종료

1. 모델·하네스의 성숙

   1. 모델 지능의 향상: 지금의 모델들은 지능 자체가 더 이상 제약이 아닐 정도로 발전했다
   2. 하네스의 발전: 브라우저 유즈 툴링이나 API 툴링, 견고한 MCP들이 구축되면서 거의 완벽에 가깝게 작업을 실행할 수 있게 됐다

2. 남은 병목: 비즈니스 이해

   1. 업종별 상이함: 모든 비즈니스, 모든 고객이 다르다. 예를 들어 헬스케어 회사의 영업팀과 SaaS 회사의 영업팀은 완전히 다르게 돌아간다
   2. 컨텍스트 추출의 어려움: 직원과 팀에서 그 맥락을 뽑아내 API 콜이나 단순 모델 호출에 넣는 것 자체가 매우 어렵고, 넣어도 금방 깨진다

1.2. 운영의 중심이 인간에서 AI로 이동

1. 현재: 오늘날 업무는 소프트웨어 위에서든, 소프트웨어와 무관하게든 인간이 수행한다
2. 미래: 운영이 AI 중심으로 재편되며, 이는 단순히 Cursor·Claude Code·Codex·Factory 같은 AI 툴을 제공하는 것을 넘어 운영 방식과 프로세스 자체를 바꾸는 것을 의미한다
3. FDE의 역할: 기업에 직접 들어가 "지금 어떻게 돌아가는지"를 이해하고 "내일은 어떤 모습일지"를 재구상하는 것이 FDE의 역할이며, Varick은 이것이 자사 핵심 업무라고 믿는다

---

2. Forward Deployed Engineer가 실제로 하는 3가지 일

2.1. 첫 번째: 인간이 일하는 방식을 매핑한다

1. 현장 배치(embedding)

   1. 부서 단위 스코핑: 수천 명 규모 엔터프라이즈라도 하나의 부서(예: 재무팀)로 범위를 좁혀 여러 FDE를 직접 배치한다
   2. 프로세스 리드 인터뷰: 재무팀이라면 AP(매입채무)·AR(매출채권)·카드 정산·뱅킹·빌링·FP&A 등 프로세스 리드 각각과 인터뷰해 현재 운영 방식을 파악한다

2. "잘못됐을 때 무슨 일이 일어나는가"가 핵심

   1. 문서화의 한계: 회사 문서는 대체로 "정상 경로(golden path)"와 예외 케이스 한두 개만 다루지만, 현실은 그렇지 않다
   2. 실제 사례: "AP의 Sarah가 오늘은 이 방식으로 워크플로우를 처리하지만, 문제가 생기면 Chris에게 넘기고 Chris는 매입주문서와 인보이스 정산에 4일의 사이클타임이 걸린다" — 이런 회사별 고유한 예외 흐름이야말로 AI가 사람 개입 없이 종단간 프로세스를 처리하지 못하는 진짜 병목이다

2.2. 두 번째: AI를 중심으로 프로세스를 재설계한다

1. "고장난 프로세스 위에 AI를 얹는" 문제

   1. 낮은 ROI의 원인: MIT 리뷰의 생성형 AI 파일럿 95% 프로덕션 미도달 통계, 별도 통계로 87%가 측정 가능한 ROI를 못 낸다는 수치가 이를 뒷받침한다
   2. 엔지니어링 비유: 코딩에서조차 "goal loop"와 최신 기술이 있어도 "가서 알아서 리팩터링해" 라고 맡기기 어려운데, 하물며 재무·영업·마케팅·조달·물류의 비기술 오퍼레이터에게 AI 툴을 그냥 쥐어주면 소프트웨어 엔지니어만큼의 ROI를 못 낸다

2. 재설계의 균형

   1. 너무 다르면 채택률 하락: 기존에 11단계 워크플로우에 익숙한 사람에게 갑자기 1단계로 바꿔버리면 적응하지 못하고 채택률이 떨어질 수 있다
   2. 적당히 다르게, ROI는 확보: 예를 들어 8단계 중 4단계는 완전 자동화, 3단계는 사람이 개입하는 human-in-the-loop, 1단계는 리스크가 너무 높거나 에이전트가 가치를 못 내는 영역이라 사람이 전담하는 식으로 나눈다

2.3. 세 번째: 기존 시스템 위에 에이전트를 배포한다

1. 엔터프라이즈는 시스템 오브 레코드에 묶여 있다

   1. 마이그레이션 현실: 대부분의 엔터프라이즈가 NetSuite, Dynamics, SAP, Salesforce 등에 이미 이전을 마쳤다
   2. 실제 고객 사례: 한 고객사는 NetSuite로 이전하는 데만 500만 달러와 5년이 걸렸다고 밝혔다. 이런 고객에게 "이 AI 툴을 쓰려면 NetSuite에서 이전해야 한다"고 하면 바로 거절당한다

2. Varick OS 플랫폼

   1. 시스템 위에서 동작: Salesforce·NetSuite·Dynamics·SAP 등 기존 시스템에서 이전을 요구하지 않고, 그 위에서 에이전트를 스핀업·모니터링하며 거버넌스와 평가(eval)를 내장한 자체 Varick OS 플랫폼을 사용한다
   2. 엔터프라이즈가 AI를 가장 필요로 하는 이유: 몸집이 너무 커서 쉽게 움직일 수 없기 때문에 오히려 이런 접근이 필요하다

---

3. 왜 자체 "FD Agent"를 만들었나

3.1. 최고의 FDE를 찾기 어려운 이유

1. 두 가지 역량의 결합이 희귀함

   1. 기술 역량: AI를 일반 엔터프라이즈 고객보다 1만 배 잘 이해하고 말하는 상위 1% 기술자여야 한다
   2. 소통 역량: 동시에 high IQ·high EQ로 고객에게서 정보를 실시간으로 끌어내고 그들의 눈높이에 맞춰야 한다 — 보통은 기술을 가르치는 컨설턴트거나, 소프트스킬을 가르치는 엔지니어 둘 중 하나이지 둘 다인 사람은 드물다

2. FD Agent의 목적: 기존 FDE를 보강해 한 명의 FDE/전략가가 여러 고객 커뮤니케이션을 동시에 관리할 수 있게 한다

   1. 현실적 부담: 고객은 24시간 이메일을 보내고 수백 페이지 문서를 전달하며, AP는 AR에, AR은 정산에, 정산은 FP&A에 의존하는 식으로 각 프로세스 리드가 각자 가장 중요하다고 생각하는 방향으로 FDE를 끌어당긴다
   2. 컨설팅 회사와의 차별화: 이 컨텍스트를 관리하면서도 50명을 채용하지 않는 것이, Varick이 전통적 컨설팅과 다르면서도 인간 중심의 handholding 경험을 제공하는 방식이다

3.2. ROI 비교: 포인트 솔루션 vs 부서 전체 트랜스포메이션

1. 포인트 솔루션의 한계: 영업의 프로스펙팅 하나만, 혹은 재무의 AP 하나만 건드리는 point solution은 5~10%의 ROI에 그친다
2. Varick의 부서 전체 전환: 부서 전체를 한 번에 전환하는 방식으로 25%, 50%, 75%의 ROI를 만들어내며, 이는 매출 증대·비용 절감·리스크 완화 세 가지를 실제로 돌려주는 것이다

---

4. FD Agent의 기술적 구조 (JD Puit, Head of Engineering 발표)

4.1. 문제 발견의 계기

1. 플랫폼팀 vs FDE팀의 온도차: JD는 플랫폼팀에서 Codex·Claude와 편하게 일하는 반면, 사무실 반대편의 FDE팀은 스트레스에 절어 잠도 못 자고 클라이언트 이메일에 시달리는 모습을 목격했다
2. 기존 FDE 워크플로우의 문제: "150페이지 문서를 Claude에 업로드하고 프롬프트를 넣은 뒤 2분 기다리면 장황하고 부정확한 분석이 나온다"는 것이 FDE들의 실제 반응이었다

4.2. FD Agent의 3단계 (Codex의 FDE 버전)

1. 1단계 — Engagement Agent (완성)

   1. 역할: FDE 전용으로 만든 더 나은 Claude. Granola 노트를 가져오고, 문서를 종합하며, PPT를 읽는다
   2. 핵심 기능: "이 프로세스는 누가 담당하냐", "이메일에는 Sarah라고 철자가 이렇게 돼 있는데 Slack 메시지엔 다르게 돼 있다. 같은 사람이냐" 같은, FDE가 하루 종일 묻고 클로드 응답을 기다리며 시간을 낭비하는 질문들에 답한다

2. 2단계 — Workflow Agent (완성, 플랫폼에 내장)

   1. 작동 방식: Engagement Agent를 플랫폼 안에 임베드해, FDE가 실제로 워크플로우를 구축할 때 "이 엣지 케이스를 빼먹었다", "이 프로세스 소유자가 누군지 물어봐야 이메일이 맞는 곳으로 간다" 등을 실시간으로 알려준다
   2. 위치: Claude나 Codex 등 FDE가 쓰는 어떤 모델 옆에서 함께 작동하며, FDE가 만드는 워크플로우가 실제 프로세스를 정확히 반영하도록 보장한다

3. 3단계 — 자율 어시스턴트 (아직 개발 중)

   1. 목표 시나리오: 고객이 "QC 리포트 수신 이메일을 바꾸고 싶다" 같은 이메일을 보내면, 에이전트가 이를 처리해 회사에 대한 기존 이해를 조회하고, 플랫폼 위 워크플로우에 자율적으로 변경을 반영한다
   2. 기대 효과: FDE가 개입할 필요 없이, 고객 인터뷰나 프로세스 이해 같은 고부가가치 업무에 시간을 쓸 수 있게 된다

4.3. 기술 스택 상세

1. 단일 진실 공급원(Single Source of Truth): 의존성 그래프

   1. 표현 방식 선택: 그래프 DB든 Postgres든 도구는 중요치 않으며, 핵심은 의존성 그래프(dependency graph)를 쓴다는 것
   2. 이유: 엔터프라이즈의 워크플로우는 대체로 선형적이나 사이클이 많이 섞여 있고, 프로세스 오너들은 "C가 A와 B의 승인 전에 뭔가를 처리하지 않도록" 의존성 기반으로 동작하길 원한다

2. 자체 모델 학습 — 문제 1: 좋은 분석 산출

   1. 프론티어 모델의 한계: 추출된 컨텍스트가 있어도 Claude 같은 프론티어 모델은 장문 분석에서 지나치게 장황하고, "고객이 실제로 신경 쓰는 디테일이 무엇이고 무시해도 되는 디테일이 무엇인지"를 구분하는 감각이 없다
   2. 컨설턴트 비유: JD는 "우리가 실제로 컨설턴트를 채용하고 나서야 컨설턴트의 가치를 믿게 됐다"며, 이 디테일 선별 감각이 프론티어 모델에 결여돼 있다고 말한다
   3. 해결책: 오픈소스 모델(Kimi K2.6을 선호한다고 언급) 위에 자체 post-training을 진행해, 디테일과 명료함 사이의 균형을 잡는다

3. 자체 모델 학습 — 문제 2: 올바른 컨텍스트 추출(그래프 탐색)

   1. 탐색의 어려움: 거대한 지식 그래프가 있어도 그 안에서 신뢰성 있게 올바른 컨텍스트를 찾아 순회하는 것 자체가 어렵다
   2. RL 환경 구축: post-trained 모델 위에 자체 커스텀 툴을 노출한 RL 환경을 만들어 그래프 순회 능력을 학습시킨다
   3. 커스텀 툴 예시: "A와 B가 같은 사람인지 확인"(회사마다 닉네임이 많아 Claude가 자주 혼동함), "지식 그래프 내 중복 사이클이나 DAG(방향성 비순환 그래프) 위반 식별" 등

---

5. Varick Agents의 전체 접근 방식

1. 감사(Audit)로 시작: 모든 인게이지먼트는 FDE·전략가를 회사에 투입해 내부에서부터 어떻게 돌아가는지 배우는 감사로 시작한다 — Voss는 이것이 가장 큰 병목이라고 재차 강조한다
2. 그다음 구현(Implementation): 자사 플랫폼 위에 에이전트를 구축한다. 미래의 자동화를 위한 기술적 요소들도 여전히 필요하지만, 진짜 병목은 forward deployed 모션 자체다
3. 채용 및 사업 확장: Varick은 실리콘밸리에서 가장 빠르게 성장하는 스타트업 중 하나로 적극적으로 채용 중이며, AI가 실제로 내부 업무에 임팩트를 내길 원하는 기업들과의 협업도 원한다

---

주요 발언 모음

"Everyone is saying that 2026 and onwards is the year of the forward deployed engineer." (Voss)

"I only started believing in consultants once we started hiring them at Veric." (JD Puit)

"The next bottleneck is how deep can you go into a customer without scaling headcount exponentially." (Voss)

"AI is solving the execution of work... I will go as so far as to say that knowledge work is almost entirely solved. The difference is... designing how work gets completed around AI is the next bottleneck." (Voss)

"One of the quotes from our clients said that they spent $5 million and 5 years migrating to NetSuite." (Voss)

핵심 데이터 & 수치

• 95%: MIT 리뷰 기준 생성형 AI 파일럿 중 프로덕션에 도달하지 못한 비율
• 87%: 측정 가능한 ROI를 내지 못하거나 아예 프로덕션에 배포되지 못한 AI 파일럿 비율 (별도 통계)
• 500만 달러 / 5년: 한 고객사가 NetSuite로 이전하는 데 실제로 든 비용과 기간
• 5~10%: 포인트 솔루션(예: 영업 프로스펙팅 하나만 자동화) 적용 시의 ROI
• 25%, 50%, 75%: Varick의 부서 전체(department-wide) AI 트랜스포메이션 적용 시 달성한 ROI
• Kimi K2.6: Varick이 자체 post-training 베이스로 선호한다고 언급한 오픈소스 모델

결론 및 시사점

1. AI가 실행(execution) 자체를 거의 해결한 지금, 다음 병목은 헤드카운트를 늘리지 않고 고객 비즈니스를 깊이 이해하는 능력이며, 이것이 Forward Deployed Engineering이 뜨는 이유다.
2. "고장난 프로세스에 AI를 얹는" 접근은 실패율이 높다(파일럿 95% 프로덕션 미도달, 87% ROI 미달). 프로세스 자체를 AI 중심으로 재설계하되 기존 워크플로우와 너무 다르지 않게 유지해 채택률을 지켜야 한다.
3. 엔터프라이즈는 시스템 오브 레코드(NetSuite, SAP, Salesforce 등)에서 벗어나길 원하지 않으므로, 마이그레이션을 요구하지 않고 기존 시스템 위에서 동작하는 에이전트 아키텍처가 실질적으로 채택된다.
4. 기술+소통 역량을 겸비한 최고의 FDE는 희귀하므로, FDE를 대체하는 것이 아니라 보강하는 "FD Agent"(Engagement → Workflow → 향후 자율 어시스턴트 3단계)를 자체 개발해 1인당 커버 가능한 고객 수를 늘린다.
5. 프론티어 모델(Claude 등)은 장문 분석에서 장황하고 "무엇이 중요한 디테일인지" 구분하는 감각이 부족하다 — 이 문제는 오픈소스 모델의 자체 post-training과 지식 그래프 순회를 위한 RL 환경 구축으로 해결한다.
6. 부서 단위 하나만 건드리는 point solution(5~10% ROI)보다, 부서 전체를 전환하는 접근(25~75% ROI)이 훨씬 큰 임팩트를 낸다는 것이 Varick의 핵심 세일즈 포인트다.