출처 https://youtu.be/C3-UfkTPi7U · 길이 17:16 · 채널 Tech Bridge · 공개 2026-07-29 발표자 Kevin — Anthropic Applied AI 팀의 Member of Technical Staff, 전 Rippling FDE 조직 및 Palantir 출신 자막 YouTube 자동 생성 한국어·영어 자막. 원문 자동자막의 오인식은 문맥에 맞게 정정했다.
개요
FDE(Forward Deployed Engineering)는 단순한 고객지원이나 외주 개발이 아니라, 복잡한 기술을 비기술 구매자의 실제 업무 결과로 번역하는 고객 대면 소프트웨어 엔지니어링과 GTM 모델이다. Kevin은 Palantir의 Foundry와 FDE 사례를 출발점으로, 이 모델이 필요한 조건과 플랫폼 위에서 확장 가능하게 만드는 설계 원칙을 설명한다.
한눈에 보는 요약
- FDE의 출발점은 제품을 파는 데서 멈추지 않고 고객의 업무를 이해해 결과(outcome) 를 함께 만드는 것이다. 고객은 데이터가 예쁘게 정리됐는지가 아니라 판매량·처리량 같은 사업 결과를 산다.
- FDE가 모든 기술 회사의 정답은 아니다. 매우 기술적인 제품을 비기술 구매자에게 팔아야 하는 특수한 교차점일 때 특히 유효하다. 기술 구매자에게 기술 제품을 파는 경우에는 개발자 참여·세일즈 주도 등 다른 GTM이 더 적합할 수 있다.
- 엔터프라이즈 FDE는 고객마다 처음부터 코드를 만드는 개발숍이 아니다. 공유 플랫폼과 프리미티브 위에서 고객별 애플리케이션·워크플로를 조립해야 유지보수 비용과 엔지니어 이탈을 막을 수 있다.
- FDE를 도입하기 전에는 “유행하니까 원하는가?”가 아니라 정말 필요한가, 공유 플랫폼을 이미 갖췄거나 투자할 의지가 있는가를 먼저 물어야 한다.
- AI는 고객 맞춤형 소프트웨어를 만드는 비용을 낮추고 거의 모든 플랫폼을 더 커스터마이즈 가능하게 만든다. 그래서 고객이 구현을 이해하지 못한 채 성공·실패를 떠안는 문제가 더 많은 회사로 확산될 수 있다.
- 좋은 FDE의 최소 정의는 고객 앞에 세워도 신뢰할 수 있는 소프트웨어 엔지니어다. 일반화 가능한 발견은 플랫폼으로 되돌리고, 특정 고객에게만 필요한 코드는 현장에 남긴다.
장면별 상세 설명
[00:00] 1. FDE 101의 범위와 발표자의 배경
Kevin은 Anthropic Applied AI 팀에서 일하고 있으며, 그 전에는 Rippling에서 FDE 기능을 처음 만든 사람으로 합류해 1년 만에 약 25명 규모로 키웠다고 소개한다. 그보다 앞서 Palantir에서도 일했다. 이 강연은 직함이나 회사 목록보다 FDE라는 기능의 역사, 역할의 본질, Palantir가 이를 GTM으로 선택한 이유, 다른 조직에 적용하는 방법을 다룬다.
[01:30] 2. Foundry가 제공하는 것과 기술만으로 부족한 이유
Palantir의 Foundry는 조직의 데이터를 한곳에 모아 온톨로지를 만들고, 그 위에서 애플리케이션을 구축하게 하는 플랫폼으로 설명된다. 흩어진 테이블을 사업에서 사용하는 의미 있는 객체와 단일한 진실의 원천으로 묶는 접근이다.
하지만 산업 리더에게 “데이터를 정리했다”고만 말하면 곧바로 “그래서 내 사업에 무슨 도움이 되나?”라는 질문이 나온다. 기술 플랫폼은 고객이 실제 가치를 얻기까지 학습과 구현이라는 큰 세금을 요구한다.
[02:20] 3. 소프트웨어가 아니라 결과를 판다
Palantir식 해법은 제품과 서비스를 따로 파는 대신 하나의 결합된 제안으로 파는 것이다. 고객은 소프트웨어 조각이나 엔지니어의 시간을 사는 것이 아니라 결과를 산다. FDE는 고객의 사업을 이해하고 Foundry 위에 해법을 만들어, 고객이 실제로 중요하게 여기는 지표—예를 들어 진열 공간 확보나 판매 처리량—로 연결한다.
여기서 데이터 모델과 구현 방식은 고객의 목표를 달성하기 위한 수단이다. 고객이 데이터가 어떤 테이블에 어떻게 저장됐는지까지 이해해야만 성공하는 구조라면 플랫폼이 아니라 고객에게 구현 부담을 떠넘긴 셈이다.
[03:15] 4. 고객의 최전선에 엔지니어를 보내는 이유
“엔지니어를 최전선에 보낸다”는 발상은 엔지니어가 원래 고객을 상대하기 좋아서가 아니다. 기술을 구매한 뒤 고객이 스스로 가치를 구현하기 어려운 경우, 엔지니어가 고객의 업무 맥락 안으로 들어가 문제를 정의하고 해결책까지 완성해야 하기 때문이다. FDE는 영업과 제품 개발 사이의 빈틈을 메우는 고객 대면 엔지니어링 기능이다.
[04:05] 5. FDE가 필요한 단 하나의 교차점
FDE의 필요성을 판단하는 축은 두 개다. 무엇을 파는가—기술적으로 복잡한가—와 누가 사는가—구매자와 사용자가 기술을 흡수할 수 있는가—다. GitHub나 Datadog처럼 복잡한 제품이어도 CTO·CIO와 소프트웨어 엔지니어가 구매·사용한다면 고객이 복잡성을 업무의 일부로 감당할 수 있다. 반대로 Jira·Slack·Rippling처럼 비기술 구매자가 써도 설정 중심의 제품이라면 FDE가 필수는 아니다.
FDE가 특히 맞는 곳은 매우 기술적인 제품을 비기술 구매자에게 판매하는 조합이다. 이 교차점이 Palantir가 Foundry와 FDE를 함께 운영한 핵심 배경이다.
[05:00] 6. Fortune 500 고객에게 필요한 현장 엔지니어
Foundry는 애플리케이션을 만드는 플랫폼이므로 Google·Meta처럼 내부 엔지니어링 역량이 큰 회사에는 상대적으로 덜 매력적일 수 있다. 반면 석유·가스 같은 산업의 Fortune 500 기업은 플랫폼을 최대한 활용할 데이터·소프트웨어 엔지니어링 깊이가 충분하지 않을 수 있다.
이때 선택지는 고객이 스스로 학습하고 구현할 때까지 기다리거나, 고객이 채용·관리·유지하지 않아도 되는 숙련 엔지니어를 함께 보내는 것이다. FDE는 플랫폼 사용법만 가르치는 사람이 아니라 고객의 문제를 이해하고 해결 소프트웨어까지 만드는 역할이다.
[05:55] 7. 고객의 문제를 해결하고 소프트웨어를 만든다
발표자는 FDE를 고급 레스토랑의 웨이터에 비유한다. 고객의 요구를 가까이에서 파악하고, 무엇을 원하는지 알아내며, 그 요구를 충족시키는 방식으로 서비스와 제품을 조합한다는 뜻이다. 다만 FDE는 단순한 컨설턴트가 아니다. 플랫폼을 이해하는 소프트웨어 엔지니어로서 고객의 업무 문제를 실제로 작동하는 해법으로 바꾼다.
[06:50] 8. FDE 모델이 만들어내는 계약 경제성
발표자는 공개 SaaS 기업의 평균 계약 가치(ACV)를 예로 들며 FDE 모델의 경제성을 주장한다. 발표 중 언급한 비교값은 Balance 약 400만 달러, ServiceNow 약 120만 달러, Workday 약 60만 달러이며, 그 뒤로는 50만 달러를 넘는 공개 SaaS 사례가 거의 없다고 설명한다. 이 수치는 독립 검증한 시장 통계가 아니라 강연자가 제시한 당시의 비교 예시로 읽어야 한다.
핵심은 엔지니어를 붙여 주는 비용을 서비스 매출로만 보는 것이 아니다. 고객의 사업 결과까지 연결하면 기술 플랫폼이 만들어내는 계약 가치와 제품 차별화가 함께 커질 수 있다는 주장이다.
[07:45] 9. 디자인 파트너십을 엔터프라이즈로 확장하기
초기 B2B 스타트업은 고객과 가까이 일하며 문제를 이해하고, 시간·기술·리소스를 투입해 해법을 만드는 디자인 파트너십으로 제품-시장 적합성을 찾는다. FDE의 핵심 주장은 이 방식이 초기 스타트업에만 갇힐 이유가 없다는 것이다. 플랫폼과 운영 체계를 갖추면 고객 밀착형 학습과 구현을 엔터프라이즈 규모로 확장할 수 있다.
[08:30] 10. FDE와 개발숍을 가르는 플랫폼 프리미티브
고객마다 처음부터 코드를 쓰면 FDE 조직은 결국 개발숍이 된다. 고객별 저장소를 계속 늘리는 방식은 유지보수 비용을 키우고, 엔지니어가 수십 개의 코드베이스를 학습해야 하므로 조직의 채용·잔류에도 악영향을 준다.
FDE의 구별되는 조건은 공유 플랫폼 위에서 일하는 것이다. 이미 마련된 프리미티브를 조립해 애플리케이션·워크플로·고객별 해법을 만들고, 반복되는 바퀴를 다시 발명하지 않는다. 프리미티브가 없다면 손익계산서가 유지보수 비용을 감당하지 못한다.
[09:35] 11. 도입 전에 먼저 물어야 할 두 질문
첫 번째 질문은 “FDE를 원하는가?”가 아니라 “FDE가 정말 필요한가?” 다. 유행하는 조직 모델을 복사하기보다, 기술적으로 복잡한 것을 비기술 구매자에게 GTM해야 하는 특수한 상황이 있는지 확인해야 한다. 그렇지 않다면 개발자 참여 조직, 세일즈 주도 방식, 전통적인 SaaS GTM 등 다른 선택지가 있다.
두 번째 질문은 “FDE가 올라갈 플랫폼과 공유 프리미티브가 있는가, 아니면 만들 의지가 있는가?” 다. 고객에게 돈을 벌어다 주는 엔지니어를 채용하는 것만으로는 충분하지 않다. 플랫폼 없는 FDE는 단기 매출을 만들더라도 장기적으로 커다란 유지보수 부채가 된다.
[10:40] 12. 플랫폼은 FDE의 확장 장치다
FDE를 운영하려면 고객별 요구를 받아들이면서도 여러 고객에게 재사용할 수 있는 기반이 필요하다. 발표자는 FDE 조직이 플랫폼 위에 공유 프리미티브를 쌓아야 한다고 거듭 강조한다. 아무리 좋은 엔지니어라도 공유 기반 없이 고객별 코드를 만들면 현장별 예외가 누적되고, 플랫폼 팀과 FDE 팀 모두가 유지보수에 묶인다.
[11:35] 13. AI가 바꾸는 것은 FDE의 필요 조건이 아니라 시장의 기본값
AI는 코드를 쓰고 정교한 고객 맞춤형 소프트웨어를 만드는 일을 훨씬 쉽게 만들었다. 하지만 이것이 모두가 Palantir의 FDE 조직을 그대로 복제해야 한다는 뜻은 아니다. 발표자의 가설은 소프트웨어 산업 자체가 변했다는 것이다. 이제 거의 모든 플랫폼이 에이전틱하고 커스터마이즈 가능해지므로, 고객은 자신이 실제로 무엇을 구매하고 있는지 또는 어떻게 구현해야 하는지 모를 가능성이 커진다.
고객의 구현 역량에 제품의 성공·실패를 맡긴 채 상향 판매나 수평·수직 확장을 시도하기는 어렵다. AI가 맞춤형 구현을 쉽게 만들수록 고객의 업무 맥락을 이해하고 결과까지 책임지는 현장 역할의 범위가 넓어질 수 있다.
[13:05] 14. 프리미티브는 얼마나 원자적이어야 하는가
Q&A에서 “공유 프리미티브를 얼마나 작게 쪼개야 하는가?”라는 질문이 나온다. 답은 사용자와 산업에 따라 달라진다. 데이터 모델을 매번 처음부터 정의하지 않아도 되게 만드는 것부터 시작할 수 있지만, 모든 도메인에 똑같은 원자성을 강요할 수는 없다.
어떤 산업에서는 프리미티브만으로 앱의 60%가 이미 만들어지고 나머지 40%만 고객화해도 충분하다. 다른 산업에서는 훨씬 세밀한 설정과 도구가 필요하다. 프리미티브의 경계는 기술적 우아함보다 고객군의 공통성과 반복되는 업무 패턴을 기준으로 정해야 한다.
[14:25] 15. AWS와 DynamoDB가 보여주는 공유 기반
AWS를 예로 들면 모든 개발자가 서버 랙을 직접 사고 운영하지 않아도 된다. AWS가 DynamoDB 같은 공유 프리미티브를 제공하기 때문에 팀은 데이터베이스를 처음부터 만들지 않고도 자신만의 애플리케이션을 만들 수 있다. 반대로 특정 산업과 고객군을 깊이 겨냥하는 플랫폼은 더 세밀한 프리미티브가 필요할 수 있다.
따라서 “프리미티브는 무조건 작아야 한다”가 정답이 아니다. 넓은 사용자층을 섬기는 플랫폼인지, 특정 도메인의 복잡한 변형을 지원해야 하는지에 따라 적절한 추상화 수준이 달라진다.
[15:45] 16. 여러 FDE의 협업과 코드 소유권
여러 FDE가 한 고객 프로젝트에 함께 참여하는 것은 권장되는 패턴이다. 한 사람이 모든 맥락을 독점하면 휴가나 이직 때 단일 장애점이 되기 때문이다. 서로 다른 회사의 팀이 협업하거나 경쟁적으로 같은 프로젝트를 맡는 경우에는 계약자·파트너의 소유권과 책임 경계를 명확히 해야 한다.
플랫폼과 현장 코드의 경계도 단순하다. 특정 고객에게만 필요한 고유 기능은 현장에 남기고, 일반화할 수 있는 발견은 장기적으로 플랫폼에 환류한다. 초기에는 프리미티브가 충분하지 않아도 괜찮다. FDE가 앞서 탐색하면서 다음 제품·서비스로 일반화할 기회를 찾아내는 역할도 하기 때문이다.
[16:50] 17. 좋은 FDE의 최소 프로필
마지막 질문에 대한 답은 의외로 간단하다. 좋은 FDE는 별도의 신비한 직군이 아니라 소프트웨어 엔지니어로 채용할 수 있고, 동시에 고객 앞에 세워도 신뢰할 수 있는 사람이다. 기술 역량과 고객 커뮤니케이션 중 하나만 가진 사람이 아니라, 두 역할을 같은 엔지니어링 책임 안에서 수행할 수 있어야 한다.
부록 — 실전 체크리스트
- 우리 제품은 정말 기술적으로 복잡한데 비기술 구매자에게 판매되는가?
- FDE가 필요한지, 단지 유행하는 조직 모델을 원하는 것인지 구분했는가?
- 고객별 코드가 올라갈 공유 플랫폼과 재사용 가능한 프리미티브가 있는가?
- 특정 고객용 기능과 여러 고객에 일반화할 기능의 환류 경로를 정했는가?
- 한 사람에게 고객 맥락이 집중되지 않도록 두 명 이상의 FDE가 협업하는가?
관련 페이지
원문 인용 모음
- [00:53] “forward deployed engineering 101.”
- [02:57] “They are buying an outcome.”
- [04:54] “Very technical to a non-technical buyer.”
- [08:31] “They are building on top of a platform.”
- [09:39] “Do I need an FDE function? Not want.”
- [12:07] “Nearly every platform is agentic.”
- [16:53] “A FDE is a customer-facing software engineer.”