How Forward Deployed Engineering is done at Kepler - Vinoo Ganesh
📺 원본 영상: How Forward Deployed Engineering is done at Kepler — Vinoo Ganesh
🎙️ 채널: AI Engineer
📅 정리 일자: 2026-07-29
⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료, 차트, 코드, 슬라이드 등은 포함되지 않을 수 있습니다.
개요
Vinoo Ganesh는 이 강연에서 Forward Deployed Engineering(FDE)을 단순한 고객 대응 역할이나 Go-to-Market 조직의 확장으로 보지 말아야 한다고 주장한다. 그가 Palantir에서 Project Frontline을 만들고, 이후 Citadel과 Kepler에서 유사한 기능을 구축하며 얻은 핵심 결론은 FDE가 제품팀의 연장선이며, 현장에서 발견한 문제를 일반화 가능한 제품 전략으로 바꾸는 방식이라는 점이다.
강연은 Palantir Foundry가 형성되던 초기 경험을 중심으로 전개된다. 겉으로는 고객 현장에 나가 문제를 해결하는 엔지니어 이야기처럼 보이지만, 실제 주제는 “무엇을 만들 것인가”를 어떻게 발견하고, 고객의 언어와 업무 흐름을 어떻게 제품의 구조로 흡수할 것인가에 가깝다.
FDE는 역할이 아니라 제품 전략이다
Ganesh가 가장 먼저 분명히 하는 것은 Forward Deployed Engineering이 직무명이 아니라 제품을 발견하고 설계하는 방식이라는 점이다. 그는 Palantir 초기에 FDE가 지금처럼 영업 전략으로 정리되어 있지 않았다고 설명한다. 오히려 2013년 무렵 Palantir가 Foundry라는 데이터 플랫폼을 만들어가는 과정에서, FDE는 고객 현장의 문제를 통해 제품이 어떤 형태를 가져야 하는지 알아내는 product strategy로 작동했다.
그가 말하는 “forward deployed”는 원래 군사 용어이며, Palantir는 이 표현을 문자 그대로 받아들였다. 그는 Iraq, Afghanistan, Bagram 같은 현장을 언급하며, 가장 중요한 환경에서 실제 사용자가 필요로 하는 소프트웨어를 작동하게 만드는 것이 출발점이었다고 설명한다. 이 맥락에서 FDE는 회의실에서 요구사항을 정리하는 사람이 아니라, 고객의 업무가 실제로 벌어지는 장소에 들어가 제품이 실패하는 지점과 반복되는 고통을 직접 관찰하는 사람이다.
이 관점은 FDE를 고객 성공(Customer Success)이나 솔루션 아키텍트와 구분한다. 고객을 만족시키는 것 자체가 최종 목적이라면 임시 스크립트와 수작업 자동화만으로도 충분해 보일 수 있다. 그러나 Ganesh가 말하는 FDE의 목적은 그렇게 발견한 문제를 제품팀의 학습 자산으로 바꾸고, 반복 가능한 제품 레버리지로 일반화하는 데 있다. 즉, 현장의 문제 해결은 끝이 아니라 제품 전략의 입력값이다.
Phoenix의 실패가 보여준 현장 부재의 비용
강연 초반에 등장하는 Phoenix 사례는 FDE가 왜 제품 전략이어야 하는지를 보여주는 반면교사다. Palantir는 2013년 무렵 대규모 금융 고객의 거래 데이터를 저장하기 위해 Phoenix라는 제품을 만들었다. 문제는 이 시스템이 고객과 충분히 대화하지 않은 상태에서, 즉 실제 금융기관의 데이터 품질과 운영 맥락을 직접 보지 않은 상태에서 설계되었다는 점이다.
Phoenix는 특정 조건에서는 완벽하게 작동했지만, 실제 데이터가 들어오자 곧바로 무너졌다. 금융기관의 데이터에는 빈 날짜 값이 있었고, 이 값은 Unix epoch인 1970년 1월 1일로 기본 처리되었다. 시스템은 1970년부터 2013년까지 10분 단위의 time bucket을 생성하려 했고, 그 결과 약 230만 개의 keyspace가 만들어졌다. Ganesh는 Cassandra가 file handle당 약 5MB를 요구한다고 설명하며, 이 구조 때문에 서버를 시작하는 데 14TB RAM이 필요한 상태가 되었다고 말한다.
03:50 - Phoenix의 time-bucketed key space 설계가 epoch 기본값과 결합되며 Cassandra 메모리 문제로 이어지는 사례
이 실패의 본질은 단순히 더 많은 고객 조사를 하지 않았다는 데 있지 않다. Ganesh는 더 근본적인 문제가 고객과 함께 소프트웨어를 공동으로 만들지 않았다는 점에 있었다고 본다. 고객의 실제 데이터, 운영 습관, 예외 상황, 시스템 경계를 보지 않고 만든 제품은 이론적으로는 정교할 수 있지만, 현실의 거친 데이터 앞에서는 쉽게 붕괴한다. FDE가 제품 전략이라는 그의 주장은 바로 이 실패 경험에서 출발한다.
요구사항 문서보다 월요일 아침의 첫 행동이 중요하다
첫 번째 현장 사례는 대규모 dispatching and shipping company에서 시작된다. 고객사의 VP of Operations는 47페이지짜리 요구사항 문서를 준비했고, 그 안에는 custom dashboard, 14개 metrics, drill-down alerts, 대형 BI 도구에 가까운 프로젝트가 담겨 있었다. Palantir 팀은 이 문서를 있는 그대로 받아들였고, 약 3개월짜리 개발 프로젝트로 추정되는 일을 몇 달 동안 스코핑했다.
그러나 누군가 실제 현장에 가서 dispatcher에게 “월요일 아침에 이 정보로 가장 먼저 무엇을 하느냐”고 묻자, 문제의 본질은 완전히 달라졌다. 사용자는 트럭이 늦었는지 확인하고, 늦었다면 새 도착 예정 시간(ETA)이나 관련 조치를 위해 dispatcher에게 연락한다고 답했다. 결국 고객이 요청한 것은 거대한 BI 대시보드였지만, 실제 문제는 지연 상태를 알려주는 단순한 Slack alert로 해결될 수 있었다. Ganesh는 이 문제를 네 시간 만에 end-to-end로 해결했다고 설명한다.
05:42 - 47페이지 요구사항 문서가 실제로는 단순한 Slack alert 문제였음을 보여주는 dispatching company 사례
이 사례가 중요한 이유는 고객이 대개 문제를 말하는 것이 아니라 자신이 상상한 해결책을 말한다는 데 있다. FDE의 일은 고객이 적어온 솔루션을 구현하는 것이 아니라, 그 솔루션 뒤에 있는 실제 업무 목표를 찾아내는 것이다. Ganesh는 FDE가 반드시 “무엇을 달성하려 하는가”, “해결책이 생긴 뒤 무엇이 일어나는가”, “오늘은 이 문제를 어떻게 해결하고 있는가”를 이해해야 한다고 말한다. 이 세 질문은 요구사항을 제품 backlog로 옮기는 과정이 아니라, 고객의 언어를 실제 문제로 되돌리는 과정이다.
그가 제시하는 실용적 원칙도 분명하다. 하루 안에 해결할 수 있는 문제라면, 복잡한 제품 전략 회의를 열기보다 바로 만들고 배포해 피드백 루프를 닫는 편이 낫다. 작은 해결책은 신뢰를 만들고, 그 신뢰는 더 깊은 문제에 접근할 권한을 준다. 그렇게 축적된 수만 시간의 현장 경험이 Palantir Foundry처럼 여러 vertical에 적용 가능한 일반 제품으로 이어졌다는 것이 Ganesh의 설명이다.
말보다 행동을 관찰해야 진짜 문제가 보인다
두 번째 사례는 데이터 파이프라인과 Parquet migration에 관한 이야기다. 고객사의 한 data quality engineer는 CSV에서 Parquet으로의 전환을 강하게 반대했다. Palantir 입장에서는 S3 bucket에 매일 약 1TB의 데이터를 CSV로 떨어뜨리는 방식이 비효율적이었고, Parquet으로 옮기면 파이프라인 비용과 compute 비용을 줄일 수 있었다. 그러나 해당 엔지니어는 거의 1년 동안 “Parquet is way worse”라는 식으로 반대했고, 팀은 그 이유를 제대로 이해하지 못했다.
전환점은 고객 현장에 직접 가서 사용자의 업무를 끝까지 관찰했을 때 찾아왔다. 그녀는 S3에서 CSV 파일을 Windows 컴퓨터로 내려받고, 더블클릭해서 열어본 뒤 데이터 품질을 spot check하고 있었다. CSV는 엑셀이나 기본 도구로 바로 열 수 있었지만, Parquet은 같은 방식으로 열어볼 수 없었다. 그녀가 반대한 것은 columnar storage format 자체가 아니라, 자신의 품질 확인 루틴이 깨지는 것이었다.
09:27 - CSV에서 Parquet으로 전환하지 못했던 실제 이유가 Windows에서 파일을 직접 열어보는 품질 확인 루틴이었다는 설명
그날 밤 팀은 Parquet viewer를 만들었고, 며칠 안에 migration 승인을 얻었다. Ganesh는 그 결과 pipeline execution time이 약 17시간에서 2시간으로 줄었다고 설명한다. 이 사례는 사용자가 말로 표현하는 반대 이유보다, 반복적으로 수행하는 행동이 훨씬 더 정확한 신호라는 점을 보여준다. 문서나 인터뷰에서는 “Parquet이 싫다”로 보였던 문제가, 현장 관찰에서는 “열어서 확인할 수 없다”라는 훨씬 작은 문제로 바뀌었다.
Ganesh는 FDE가 관찰해야 할 신호를 매우 구체적으로 설명한다. 사용자가 같은 일을 하루에도 여러 번 반복하거나, 도구 사이에서 copy and paste를 하거나, 탭을 자주 전환하거나, 작업 중간에 휴대폰을 꺼내 든다면 그곳에는 제품 기회가 숨어 있다. 사용자가 “어쩔 수 없이 이렇게 해야 한다”고 말하며 짜증을 보이는 순간도 마찬가지다. FDE의 목표는 사용자의 내일을 오늘과 다르게 만드는 것이며, 그 출발점은 “당신의 아침에서 가장 짜증나는 부분은 무엇인가”라는 질문이다.
현장에 들어가지 않으면 얻을 수 없는 정보가 있다
Ganesh는 가장 가치 있는 정보가 문서에 남지 않는다고 강조한다. Parquet 사례의 문제도 문서나 설문으로는 찾기 어려웠고, 고객 건물에 badge를 받아 들어가 실제 업무를 관찰했기 때문에 발견할 수 있었다. 그는 Afghanistan, Iraq, SoHo, Palo Alto, San Francisco 같은 장소를 언급하며, 중요한 문제는 고객의 사무실 벽 안에서 살아 움직인다고 말한다.
이 지점에서 FDE는 단순한 원격 컨설팅과 달라진다. 좋은 질문을 던지는 것만으로는 충분하지 않고, 실제 업무가 벌어지는 방에 들어가야 한다. Ganesh는 고객사 badge와 contractor email address를 “data mining permit”에 비유한다. 이는 고객 시스템에 접근할 권한이라는 뜻을 넘어, 고객 조직의 비공식적 언어, 반복 행동, 예외 처리, 인간적인 불편함을 관찰할 수 있는 허가에 가깝다.
따라서 이름만 Forward Deployed Engineer인 상태로 뉴욕의 좋은 회의실에 앉아 있는 것은 본질을 놓치는 일이다. 현장에 상주하는 사람만이 고객이 공식적으로 말하는 요구와 실제로 겪는 문제 사이의 차이를 볼 수 있다. Ganesh가 인용한 Palantir식 표현처럼, “residents get the truth”라는 말은 FDE의 운영 원칙을 압축한다. 진실은 보고서가 아니라 거주와 관찰에서 나온다.
언어를 정의하면 제품의 기반을 장악한다
세 번째 축은 ontology와 언어의 문제다. Ganesh는 한 조직 안에서도 같은 대상을 부르는 이름이 팀마다 다르다고 설명한다. Sales는 customers라고 부르고, operations는 clients라고 부르며, finance는 billing entities라고 하고, developers는 org IDs라고 부를 수 있다. 표면적으로는 단어 차이에 불과해 보이지만, 실제로는 integration breakage, data quality issue, pipeline failure로 이어진다.
Palantir의 ontology 개념은 처음부터 거대한 철학적 설계로 등장한 것이 아니라, 사람들이 각자의 도메인에서 이해하는 방식대로 일할 수 있게 하려는 필요에서 나왔다고 Ganesh는 설명한다. 조직은 nouns와 verbs로 구성된다. nouns는 entity를 정의하고, verbs는 그 entity에 대해 수행되는 operation을 정의한다. FDE는 현장에서 이 nouns와 verbs를 발견하고, 어떤 용어를 canonicalize할지 정리하면서 제품이 고객 조직의 언어적 기반이 되도록 만든다.
13:53 - 조직을 nouns와 verbs로 해석하며 FDE가 ontology와 용어 체계를 정의해야 한다고 설명하는 구간
이 과정이 중요한 이유는 사용자가 제품만 채택하는 것이 아니라 제품의 언어도 함께 채택하기 때문이다. 예를 들어 DAU(Daily Active Users)는 product team에게는 고품질 활성 사용자를 의미할 수 있지만, InfoSec 관점에서는 단순 로그인 수를 의미할 수 있다. 최근 AI 생태계에서도 “skills”, “MCPs”, “agents” 같은 용어가 빠르게 퍼지고 있지만, 각각이 정확히 무엇을 의미하는지는 조직과 제품에 따라 다르게 해석될 수 있다.
Ganesh의 관점에서 FDE는 이런 과부하된 단어를 찾아내고, 시스템 경계와 integration point를 이해하며, translation layer가 어디서 발생하는지 파악해야 한다. Snowflake에서 Databricks로 넘어가는 지점, Palantir에서 Tableau로 넘어가는 지점, Anthropic에서 SAP로 이어지는 지점에는 항상 언어의 변환이 있다. FDE가 그 언어를 정의하고 제품 안에 codify할 수 있다면, 그 제품은 단순 도구를 넘어 고객의 사고와 운영을 지탱하는 기반이 된다. 그는 이를 “linguistic foundation”이 되면 lock-in이 발생한다고 표현한다.
15:51 - 사용자가 제품의 언어를 채택하면 플랫폼이 linguistic foundation이 되어 lock-in을 만든다는 설명
빠르게 만들되, 운영될 운명을 전제로 만들어야 한다
마지막 사례는 temporary hack의 위험에 관한 이야기다. Ganesh는 한 고객의 data retention 문제를 해결하기 위해 Groovy로 빠른 스크립트를 만든 경험을 소개한다. 그 스크립트는 production을 염두에 둔 것이 아니었고, 초기 문제를 해결하기 위해 급하게 만든 임시 처방에 가까웠다. 그러나 12개월 뒤 그 스크립트는 거의 10만 명 규모의 고객 조직 곳곳에서 실행되고 있었다.
17:32 - Groovy 임시 스크립트가 대규모 고객 환경에서 장기간 운영되며 production debt가 된 사례
이 경험은 FDE가 빠르게 배포하는 능력만으로는 충분하지 않다는 점을 보여준다. 고객의 고통을 즉시 줄이는 스크립트나 hack은 신뢰를 만들 수 있지만, 그것이 제품 전략으로 연결되지 않으면 장기 부채가 된다. Ganesh는 고객 성공을 위해 무엇이든 만들어주는 사람이 FDE라면 이런 일이 반복된다고 지적한다. 고객을 성공시키는 역할은 solutions architect나 customer success 조직에도 있으며, FDE의 고유한 책임은 현장 해결책을 제품 생태계 안에서 지속 가능한 형태로 판단하고 일반화하는 것이다.
그가 제시하는 기준은 매우 현실적이다. 지금 배포하려는 것이 6개월 뒤 새벽 2시에 전화를 받게 만들 것인지, 빠른 해결이 장기적으로 제품 전체에 어떤 trade-off를 만드는지, 고객 사이트를 떠난 뒤 누가 이 시스템을 인수할 수 있는지, 깨졌을 때 누구의 책임이 되는지를 생각해야 한다. 이 질문들은 완벽주의를 요구하는 것이 아니라, 임시 해결책이 실제로는 오래 살아남는다는 소프트웨어 현실을 인정하라는 요구다.
Ganesh는 “this is just temporary”가 engineering과 FDE에서 가장 위험한 말이라고 강조한다. 누군가의 삶을 편하게 만든 hack은 production으로 들어가고, 한번 production에 들어간 것은 생각보다 오래 유지된다. 그래서 FDE는 모든 배포물을 적어도 18개월은 운영될 것처럼 생각해야 한다. 빠른 ship은 여전히 중요하지만, 그것이 core product offering으로 흡수되어야 하는지, 고객 goodwill을 위한 단발성 해결로 남겨야 하는지를 구분하는 판단이 FDE의 핵심 역량이 된다.
Project Frontline의 치트시트가 말하는 좋은 FDE
Ganesh가 Palantir의 Project Frontline에서 가르친 FDE의 모습은 일반적인 product management나 customer success 프로세스와 다르다. 많은 조직은 FDE 기능을 만들 때 요구사항을 수집하고, 사용자 리서치를 예약하고, insight를 정리하는 방식으로 접근한다. 그러나 이런 방식은 현장에서 얻은 발견이 제품 방향을 어떻게 바꾸는지까지 연결하지 못하면 충분하지 않다.
그가 말하는 올바른 FDE는 문제를 재정의하고, 고객 현장에 badge를 받아 들어가며, 고객이 있는 곳이라면 전쟁터, 해양 oil rig, 먼 지역까지 이동한다. 그리고 고객 사이트를 떠나기 전에 작은 fix를 배포해 goodwill을 얻지만, 동시에 그 fix가 제품 생태계 안에서 어떤 의미를 갖는지 end-to-end로 소유한다. 단순히 고객의 당장 불편한 점을 해결하는 것이 아니라, 그 해결책을 nouns와 verbs로 번역하여 이후 문제 해결의 기반이 되게 만드는 것이다.
20:41 - Project Frontline식 FDE가 현장 fix를 제품 레버리지로 바꾸는 과정을 정리하는 구간
이 차이는 “무엇을 배웠는가”와 “제품 관점에서 무엇을 ship했는가”의 차이로 요약된다. FDE가 고객 현장에서 많은 것을 배웠더라도, 그것이 제품 레버리지로 전환되지 않으면 조직의 전략 자산이 되지 않는다. 반대로 작은 alert, viewer, terminology 정리, integration layer가 반복 가능한 제품 구조로 일반화된다면, 그것은 Foundry 같은 플랫폼이 되는 출발점이 될 수 있다.
Kepler와 초기 스타트업에 주는 교훈
강연의 마지막에서 Ganesh는 Kepler가 FDE를 제품 기능의 확장으로 구축하고 있다고 설명한다. 특히 초기 스타트업이라면 FDE를 Go-to-Market 확장으로 오해해서는 안 된다고 강조한다. Palantir처럼 오랜 기간과 막대한 자본을 가진 회사라면 FDE를 영업적으로 활용할 여지가 있지만, 초기 회사는 아직 어떤 제품이 최대 레버리지를 만들지 알아내야 하는 단계에 있다.
따라서 초기 회사의 FDE는 고객 앞에서 데모를 잘하고 계약을 확대하는 역할보다, 현장에서 제품의 형태를 발견하는 역할에 가까워야 한다. 고객이 요구하는 대시보드를 그대로 만드는 대신 실제 월요일 아침의 행동을 보고, 반대 의견을 말로 설득하려 하기보다 사용자의 반복 동작을 관찰하고, 조직마다 다른 단어를 제품 ontology로 정리해야 한다. 이렇게 해야만 고객에게 끈끈하게 붙는 제품, 즉 sticky product를 만들 수 있다.
Ganesh의 결론은 product leverage가 고객을 이기는 유일한 방법이라는 것이다. Citadel의 portfolio manager가 수억 달러를 거래하는 의사결정도, Palantir의 warfighter ecosystem에서 이루어지는 판단도, 결국 제품이 실제 문제를 반복 가능하게 해결할 수 있을 때 가능해진다. FDE는 이 제품 레버리지를 만드는 현장 기반 전략이며, 그래서 단순히 고객을 만나러 가는 엔지니어가 아니라 제품의 미래를 발견하는 엔지니어다.
마무리 / 핵심 정리
이 강연의 핵심은 Forward Deployed Engineering을 “고객 앞에 나가는 엔지니어”라는 표면적 정의에서 떼어내는 데 있다. Ganesh는 FDE가 고객 성공이나 영업 지원의 하위 기능이 아니라, 제품이 무엇을 해야 하는지를 발견하는 전략적 장치라고 본다. 고객은 대개 문제보다 해결책을 말하고, 문서는 실제 업무의 고통을 숨기며, 조직의 언어는 데이터와 시스템의 구조를 결정한다.
좋은 FDE는 이 모든 것을 현장에서 관찰한 뒤, 작은 해결책을 빠르게 ship하고, 그 해결책이 제품으로 일반화될 수 있는지 판단한다. 동시에 모든 hack은 production이 될 수 있다는 사실을 기억하며, 빠른 실행과 운영 책임 사이의 균형을 잡아야 한다. 결국 FDE의 가치는 고객의 말을 구현하는 데 있지 않고, 고객의 현실을 제품의 언어와 구조로 바꾸는 데 있다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | How Forward Deployed Engineering is done at Kepler — Vinoo Ganesh |
| 채널 | AI Engineer |
| 영상 길이 | 약 22분 19초 |
| 리포트 작성 | 2026-07-29 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.