The Dirty Secret of Forward Deployed Engineering - Natalie Meurer, Sierra
📺 원본 영상: The Dirty Secret of Forward Deployed Engineering - Natalie Meurer, Sierra
🎙️ 채널: AI Engineer
📅 정리 일자: 2026-07-29
⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료, 차트, 코드, 슬라이드 등은 포함되지 않을 수 있습니다.
개요
Natalie Meurer는 Forward Deployed Engineering(FDE)을 하나의 명확한 직무라기보다, 시대와 회사의 필요에 따라 계속 확장되어 온 고객 책임 중심의 엔지니어링 방식으로 설명한다. 강연의 핵심 주장은 도발적이다. “Forward Deployed Engineering은 존재하지 않는다”는 말은 이 역할이 허상이라는 뜻이 아니라, DevOps, 데이터 통합, 커스텀 솔루션, 고객 교육, AI 에이전트 구축까지 너무 많은 일을 포괄하게 되면서 단일 정의로는 설명하기 어려워졌다는 의미에 가깝다.
이 발표는 Palantir에서 시작된 FDE의 역사적 변화를 따라가며, 왜 2026년 현재 AI 기업들이 다시 이 역할에 주목하는지를 설명한다. 특히 코드 작성 비용이 낮아지고, 소프트웨어 가격 모델이 사용량 기반에서 성과 기반으로 이동하면서, 고객 문제를 직접 이해하고 제품으로 번역할 수 있는 엔지니어의 가치가 더 커졌다는 점이 강연의 중심축이다.
FDE라는 이름의 역설
Natalie Meurer는 Sierra의 Head of Agent Engineering으로 자신을 소개하면서, 본인이 원래는 정책과 기술 정책에 관심이 많았고 이후 Palantir에서 2016년부터 2021년까지 프라이버시 팀, 인프라 엔지니어, Forward Deployed Engineer로 일했다고 말한다. 이 경력은 강연의 관점을 결정짓는다. 그는 FDE를 추상적인 유행어로 다루는 것이 아니라, 실제 고객 현장과 온프레미스 배포, 방위 및 법집행기관과의 작업을 통해 경험한 운영의 언어로 설명한다.
강연 초반에 제시되는 “더러운 비밀”은 FDE가 존재하지 않는다는 주장이다. 그러나 이 말은 FDE가 쓸모없다는 뜻이 아니다. 오히려 그 반대에 가깝다. FDE라는 용어가 DevOps, 데이터 통합, 솔루션 엔지니어링, 고객 교육, 프로덕트 피드백, AI 에이전트 구축까지 담아내면서 너무 넓어졌기 때문에, 하나의 직무 설명으로는 더 이상 정확히 작동하지 않는다는 것이다.
이 지점에서 중요한 것은 FDE의 본질을 기술 스택이 아니라 책임의 방향에서 찾는다는 점이다. 일반적인 소프트웨어 엔지니어가 코드베이스와 제품 내부의 완성도를 중심으로 움직인다면, FDE는 고객의 현장 문제와 결과에 더 직접적으로 묶인다. 그래서 FDE는 특정 언어나 프레임워크를 아는 사람이라기보다, 고객의 환경에서 소프트웨어가 실제로 작동하게 만들고 그 결과를 제품으로 되돌려 보내는 역할에 가깝다.
Palantir에서 시작된 FDE의 첫 번째 얼굴
강연자는 Palantir의 2016년 채용 공고를 회상하며, 당시 Forward Deployed Software Engineer라는 표현에서 가장 강조된 부분이 “Forward Deployed”였다고 설명한다. 오늘날 채용 공고가 보통 특정 프로그래밍 언어, 프레임워크, 경력 연차를 앞세우는 것과 달리, 당시 Palantir는 위치와 현장성을 강조했다. 이는 단순한 수사가 아니라 실제 업무 방식과 연결되어 있었다. 많은 배포가 온프레미스 환경에서 이루어졌고, 고객의 시스템 안으로 들어가야만 문제를 해결할 수 있었기 때문이다.
초기의 FDE는 대중이 상상하는 화려한 고객 현장 전략가라기보다 DevOps에 가까웠다. 플랫폼 안정성이 업무의 큰 비중을 차지했고, 고객 환경에서 서버가 내려가거나 인스턴스가 문제를 일으키면 직접 대응해야 했다. 강연자는 자신의 Palantir 온보딩 프로젝트가 EC2 인스턴스에 소프트웨어를 배포하는 일이었다고 설명하는데, 이는 초기 FDE가 얼마나 인프라 운영과 배포 안정성에 밀착되어 있었는지를 잘 보여준다.
04:48 - 초기 Palantir FDE가 수행하던 배포 및 DevOps 성격의 업무
이 시기의 FDE는 고객 곁에 있는 엔지니어라는 표현을 문자 그대로 구현했다. 고객이 문제를 겪는 장소와 시간에 맞춰 소프트웨어를 고치고, 배포를 유지하며, 운영 환경의 불확실성을 흡수하는 것이 역할의 핵심이었다. 따라서 2008년 무렵의 FDE를 하나의 “빈티지”로 표현한다면, Natalie의 말처럼 플랫폼 안정성과 약간의 공포가 섞인 역할이었다고 할 수 있다.
데이터 통합으로 확장된 두 번째 역할
2012년 이후 Palantir의 플랫폼이 안정화되면서 FDE의 업무는 단순한 배포와 운영을 넘어 데이터 통합으로 이동한다. 강연자는 데이터 통합 소프트웨어가 데이터 없이 얼마나 유용하냐고 청중에게 묻고, 이를 영화가 상영되지 않는 영화관에 비유한다. 플랫폼이라는 극장이 세워졌더라도 그 안에 고객의 실제 데이터가 들어오지 않으면, 사용자는 아무런 가치를 얻을 수 없다는 뜻이다.
이 시점에서 FDE는 고객의 흩어진 데이터를 이해하고 연결하는 사람으로 바뀐다. 고객의 데이터가 20곳에 나뉘어 있다면, 단순히 API를 붙이는 것만으로는 충분하지 않다. 어떤 데이터가 어떤 업무적 의미를 갖는지, 조직 내에서 어떤 의사결정과 연결되는지, 그리고 이를 어떤 형태로 모델링해야 하는지를 이해해야 한다. Palantir가 말하는 Ontology(온톨로지)는 이 맥락에서 등장하며, 강연자는 이를 데이터에 대한 일종의 Taxonomy(분류 체계)로 설명한다.
06:16 - 여러 곳에 흩어진 고객 데이터와 데이터 통합 문제
이 변화는 FDE가 순수 인프라 엔지니어에서 도메인 모델러로 확장되는 순간을 보여준다. 고객의 운영 환경을 알아야 안정적으로 배포할 수 있었던 것처럼, 고객의 업무 언어를 알아야 데이터를 의미 있게 통합할 수 있다. 결국 FDE는 시스템과 고객 사이의 번역자 역할을 맡게 되었고, 이 번역 능력이 이후 커스텀 솔루션과 AI 에이전트 구축으로 이어지는 기반이 되었다.
Slate와 Foundry, 그리고 데이터에서 의사결정으로
2016년 무렵 FDE의 역할은 다시 한 번 확장된다. 이제 FDE는 이미 통합된 데이터를 바탕으로 고객이 실제 문제를 풀 수 있는 커스텀 솔루션을 만들기 시작했다. Palantir 내부의 Slate는 드래그 앤 드롭 방식으로 페이지 컴포넌트를 데이터 소스에 연결하는 빌더였고, 이 도구를 통해 FDE는 대시보드와 업무 화면을 구성할 수 있었다. 데이터가 준비된 뒤의 질문은 “이 데이터를 어떻게 유용하게 만들 것인가”였고, 그 답을 가장 잘 찾을 수 있는 사람은 데이터를 직접 통합하고 고객의 문제를 이해한 FDE였다.
07:26 - Slate에서 데이터 소스와 화면 컴포넌트를 연결해 대시보드를 만드는 과정
그러나 강연자는 대시보드 자체에도 한계가 있었다고 지적한다. 데이터 소스에 다시 쓰기(write-back)하지 않는 대시보드는 시간이 지나며 낡고, 실제 업무 흐름 속에서 충분한 가치를 만들기 어렵다. 이 말은 단순히 보기 좋은 시각화가 부족했다는 의미가 아니다. 의사결정을 내리는 사용자가 다시 시스템에 행동을 남기고, 그 행동이 데이터와 프로세스를 갱신해야 비로소 소프트웨어가 운영의 일부가 된다는 뜻이다.
이 흐름은 Palantir Foundry로 이어진다. Foundry의 시대는 데이터를 보는 것을 넘어 데이터에서 의사결정으로 이동하는 과정이었다. FDE는 이 과정에서 고객의 현장 지식을 제품 위에 얹어 실제 업무 흐름을 만드는 역할을 맡았고, 그 결과 FDE는 단순한 배포 인력이 아니라 고객 문제를 제품화하는 엔지니어로 자리 잡게 되었다.
플랫폼화와 고객 Enablement의 등장
2020년을 전후해 Palantir는 IPO를 앞두고 있었고, 더 이상 모든 고객 문제를 현장 파견 인력에 의존해 해결할 수 없었다. 강연자는 핀란드나 캔버라 같은 장소로 사람을 계속 보내는 방식만으로는 확장성이 부족했다고 설명한다. 이때 FDE의 네 번째 역할이 등장한다. 고객이 스스로 플랫폼 위에서 더 많은 일을 할 수 있도록 Enablement(역량 부여)를 제공하는 것이다.
Airbus와의 Skywise 사례는 이 변화를 보여주는 대표적인 예로 언급된다. Palantir는 수천 명의 Airbus 엔지니어가 Foundry 플랫폼 위에서 FDE가 하던 종류의 일을 직접 수행할 수 있도록 만드는 데 초점을 맞췄다. 이는 FDE가 사라졌다는 뜻이 아니라, FDE가 직접 모든 것을 만드는 역할에서 고객 조직이 같은 방식으로 일할 수 있도록 구조를 만드는 역할로 확장되었다는 의미다.
이러한 플랫폼화는 오늘날 AI FDE와도 연결된다. 강연자는 Palantir가 자신이 떠난 이후 AIP Bootcamp 같은 프로그램을 통해 대규모 언어 모델을 활용한 고객 문제 해결 방식을 확산하려 했다고 언급한다. 여기서 흥미로운 점은 FDE가 자동화의 대상이면서 동시에 자동화를 설계하는 주체라는 사실이다. 고객 문제를 이해하고, 그 문제를 소프트웨어와 에이전트가 해결할 수 있는 형태로 바꾸는 능력은 여전히 중심에 남는다.
09:18 - AIP Bootcamp 사례에서 FDE와 Deployment Strategist가 고객에게 플랫폼 사용을 교육하는 장면
FDE Vintage라는 렌즈
Natalie는 FDE의 역사를 하나의 직선적 진화라기보다 “빈티지”의 축적으로 설명한다. 2008년의 FDE는 플랫폼 안정성과 DevOps에 가까웠고, 2012년의 FDE는 데이터 통합과 온톨로지 모델링에 가까웠으며, 2016년의 FDE는 커스텀 솔루션과 대시보드 구축에 집중했다. 2020년의 FDE는 고객 Enablement와 플랫폼 확장으로 이동했고, 2026년의 FDE는 AI 엔지니어링과 제품 개발, 고객 성과 책임이 뒤섞인 역할이 되었다.
10:21 - 2008년부터 현재까지 FDE 역할의 변화를 설명하는 FDE Vintage 타임라인
이 표현이 유용한 이유는 FDE를 채용하거나 평가할 때 단일 기준으로 보기 어렵다는 현실을 드러내기 때문이다. 어떤 FDE는 장애 대응과 배포 안정성에 강하고, 어떤 FDE는 고객 데이터를 모델링하는 데 강하며, 또 다른 FDE는 고객 워크플로를 빠르게 프로토타이핑하는 데 강하다. 모두 FDE라는 이름 아래 묶이지만, 실제로 축적한 경험의 종류는 상당히 다르다.
따라서 “당신은 어떤 빈티지의 FDE인가”라는 질문은 농담처럼 들리지만 실무적으로 꽤 날카롭다. 이 질문은 후보자가 고객 현장에서 어떤 문제를 해결해 왔는지, 제품과 운영 사이의 어느 지점에서 강점을 갖는지, 그리고 AI 시대의 새로운 FDE 역할에 얼마나 자연스럽게 적응할 수 있는지를 드러낸다.
2026년, 왜 FDE가 다시 뜨거워졌는가
강연자는 2026년 현재 FDE가 거의 모든 곳에서 이야기되고 있다고 말한다. Google Cloud Platform(GCP)이 Customer Engineer 또는 FDE 성격의 인력을 채용하려는 움직임을 보였고, OpenAI도 기업 AI 도입을 지원하기 위한 조직과 투자를 강화했다는 사례가 언급된다. Box의 Aaron Levie를 비롯한 여러 인물들도 X에서 이 역할의 중요성을 이야기했다. 이는 FDE가 특정 회사의 독특한 문화에서 나온 직무를 넘어, AI 기업 전반의 운영 모델로 확산되고 있음을 보여준다.
그런데 바로 이 확산 때문에 FDE의 정의는 더 혼란스러워진다. 강연자는 오늘날의 FDE 채용 공고들을 모두 합치면, 8년 경력의 Staff Engineer이면서 6년의 직접 영업 경험과 4년의 Solution Architect 경험을 갖고, 교육 경험까지 있으면 좋은 사람을 찾는 것처럼 보인다고 농담한다. 이 농담은 과장이지만 현실의 압축이기도 하다. 기업들은 고객 앞에서 말할 수 있고, 제품을 이해하며, 코드를 작성하고, 아키텍처를 설계하고, 결과까지 책임지는 사람을 원한다.
이 지점에서 “FDE는 존재하지 않는다”는 말은 다시 의미를 얻는다. FDE가 존재하지 않는 것이 아니라, 너무 많은 기대가 하나의 이름에 얹히면서 직무가 과잉 정의되고 있다는 것이다. 하지만 강연자는 이것이 문제가 되지 않는다고 본다. 역할의 이름이 불완전하더라도 고객에게 책임지는 엔지니어링이라는 공통점은 여전히 강력하기 때문이다.
코드가 저렴해질 때 엔지니어링은 어디로 이동하는가
AI 시대의 결정적 변화는 코드 생산 비용의 하락이다. 강연자는 이제 백그라운드 에이전트에 프롬프트를 던지면 꽤 훌륭한 결과물을 빠르게 얻을 수 있는 시대가 되었다고 설명한다. 이 변화는 엔지니어의 역할을 단순 코드 작성에서 고객 문제의 식별, 요구사항의 해석, 제품적 판단, 결과 검증으로 이동시킨다. FDE는 원래부터 고객 신호를 제품으로 번역하는 역할이었기 때문에, 이 변화에서 더 큰 영향력을 갖게 된다.
과거의 FDE가 고객과 이야기하고 프로토타입을 만드는 데 머물렀다면, 이제는 코딩 에이전트를 활용해 엔드투엔드 솔루션까지 직접 구축할 수 있다. 이는 FDE의 생산성을 높이는 동시에 제품 개발 과정에서 FDE의 위치를 강화한다. 고객의 문제를 가장 가까이서 관찰한 사람이 곧바로 해결책을 만들고, 그 해결책을 제품 팀의 학습으로 되돌릴 수 있기 때문이다.
동시에 제품 엔지니어링의 경계도 흐려진다. 강연자는 Sierra에서 실제로 Product Engineering이 더 고객 대면적으로 변하고 있다고 말한다. 좋은 Product Engineer와 좋은 FDE 모두 고객과 제품을 함께 생각해야 하며, 심지어 인프라 엔지니어도 소프트웨어가 어떻게 배포되고 운영되는지를 고객 결과의 관점에서 이해해야 한다는 것이다.
Agent Engineering은 FDE의 일부인가
Natalie는 Sierra에 합류했을 때 Deployment Team이라는 이름을 좋아하지 않았고, 2024년 7월 Agent Engineering이라는 개념에 대한 글을 썼다고 말한다. 당시 그의 관점에서 Agent Engineering은 AI Engineering의 하위 분야였고, Forward Deployed Engineering처럼 높은 고객 책임성을 가지면서도 독립된 기술 도메인으로 볼 수 있었다. 즉 에이전트를 설계하고 배포하며 고객 성과를 만드는 일을 별도의 전문 영역으로 이해한 것이다.
하지만 강연의 후반부에서 그는 자신의 생각이 완전한 그림은 아니었다고 돌아본다. Agent Engineering은 분명 결과에 집중하는 역할이고, 따라서 FDE의 한 형태라고 볼 수 있다. 그러나 2026년의 관점에서는 Agent Engineering만이 FDE에 가까운 것이 아니라, Product Engineering, AI Engineering, Solutions Engineering, Customer Engineering 전체가 FDE적 방향으로 이동하고 있다.
15:35 - Agent Engineering, Product Engineering, AI Engineering, Solutions Engineering이 FDE적 방향으로 수렴하는 구조
이 변화의 핵심은 고객을 대신해 결과를 가능하게 만드는 모든 엔지니어링이 FDE의 성격을 띠게 된다는 점이다. 에이전트를 만들고, 프로덕션에 배포하고, 데이터를 통합하고, 고객이 이를 활용하도록 돕는 일은 더 이상 분리된 직무 경계 안에 머물기 어렵다. 따라서 Agent Engineering은 FDE의 부분집합이면서, 동시에 FDE가 AI 시대에 어떤 모습으로 확장되는지를 보여주는 가장 선명한 사례다.
성과 기반 가격 모델과 FDE의 결합
강연자는 소프트웨어 판매 방식이 바뀌고 있다는 점도 중요한 전환으로 제시한다. Sierra는 Outcome-based Pricing(성과 기반 가격 모델)에 집중해 왔고, 소프트웨어가 제공한 가치에 대해 고객이 비용을 지불해야 한다고 본다. 전통적인 Seat-based Pricing(좌석 기반 과금)은 제품 사용자가 몇 명인지에 따라 가격을 매기는 방식이며, 제품이 실제 성과에 어느 정도 기여했는지를 명확히 귀속하기 어려운 환경에서 오랫동안 사용되어 왔다.
반면 AI 에이전트는 결과에 더 직접적으로 연결될 가능성이 있다. 고객 경험 AI의 경우, 실제로 판매가 발생했는지, 고객 문의가 해결되었는지와 같은 결과를 측정할 수 있다. 강연자는 OpenAI나 Anthropic 같은 Foundation Model 제공자에게 지불하는 비용은 Usage-based Pricing(사용량 기반 과금)의 예에 가깝다고 설명한다. 사용량은 측정하기 쉽지만, 그 사용이 어떤 비즈니스 결과로 이어졌는지는 별도의 해석이 필요하다.
14:37 - 사용량 기반 가격과 성과 기반 가격의 차이 및 AI 고객 경험의 Outcome-based Pricing
성과 기반 가격 모델이 확산되면 FDE의 중요성은 더 커진다. 고객이 단순히 소프트웨어 접근권을 사는 것이 아니라 결과를 구매한다면, 그 결과를 보장하고 구현하는 역할이 필요하기 때문이다. FDE는 고객 환경을 이해하고, 제품을 조정하며, 에이전트가 실제 업무 성과를 내도록 만드는 사람이다. 결국 성과 기반 가격 모델은 FDE를 비용 센터가 아니라 매출과 고객 가치의 핵심 연결점으로 만든다.
“FDE는 죽었다, FDE 만세”라는 결론
강연의 마지막 문장은 “Forward Deployed Engineering is dead. Long live Forward Deployed Engineering.”이라는 역설로 정리된다. 이는 낡은 의미의 FDE, 즉 특정 회사의 특정 현장 파견 엔지니어라는 좁은 정의는 죽었다는 뜻이다. 동시에 고객 결과에 책임지는 엔지니어링 방식으로서의 FDE는 그 어느 때보다 중요해졌다는 뜻이기도 하다.
이 결론은 AI 시대 엔지니어링 조직에 중요한 시사점을 준다. 코드 작성 능력은 여전히 중요하지만, 그것만으로는 충분하지 않다. 고객의 문제를 구조화하고, 데이터와 워크플로를 이해하며, AI 에이전트나 제품 기능을 통해 측정 가능한 결과로 연결하는 능력이 점점 더 중요해진다. FDE는 바로 이 지점에서 제품, 엔지니어링, 세일즈, 고객 성공의 경계를 가로지르는 역할로 부상한다.
결국 이 강연은 FDE라는 직무명을 방어하거나 폐기하자는 이야기가 아니다. 오히려 그 이름 아래 쌓인 여러 역사적 층위를 이해하고, 자신 또는 조직이 어떤 종류의 고객 책임 엔지니어링을 필요로 하는지 명확히 하자는 제안에 가깝다. AI가 코드를 더 싸게 만들수록, 고객 문제를 정확히 이해하고 결과를 책임지는 엔지니어의 가치는 더 비싸진다.
마무리 / 핵심 정리
Natalie Meurer의 강연은 Forward Deployed Engineering을 하나의 직무 설명서가 아니라 엔지니어링이 고객과 만나는 방식의 역사로 읽게 만든다. Palantir의 초기 FDE는 온프레미스 배포와 플랫폼 안정성에서 출발했지만, 이후 데이터 통합, 온톨로지 모델링, 커스텀 솔루션, 고객 Enablement, AI 기반 자동화로 확장되었다. 이 누적된 역할 때문에 FDE는 더 이상 단일한 정의를 갖기 어렵지만, 고객에게 직접 책임진다는 공통된 축은 계속 남아 있다.
AI 시대에는 이 축이 더 중요해진다. 코드가 빠르고 저렴하게 생성될수록, 어떤 문제를 풀어야 하는지, 어떤 결과를 보장해야 하는지, 고객의 실제 환경에서 무엇이 작동하는지를 판단하는 능력이 차별점이 된다. 그래서 FDE는 사라지는 직무가 아니라 여러 엔지니어링 역할 속으로 확산되는 사고방식이 된다. 강연의 핵심 메시지는 명확하다. 앞으로의 엔지니어는 제품 안쪽만 보는 사람이 아니라, 고객의 결과를 제품으로 번역하는 사람이어야 한다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | The Dirty Secret of Forward Deployed Engineering - Natalie Meurer, Sierra |
| 채널 | AI Engineer |
| 리포트 작성 | 2026-07-29 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.
Related Reports
- How Forward Deployed Engineering is done at Kepler - Vinoo Ganesh
- Forward Deployed Engineering 101 — Kevin Bai, Anthropic, ex Palantir & Rippling Founding FDE
- 팔란티어 CEO, 왜 OpenAI를 지금 공개 저격했나 - 토큰만 태우는 AI 논쟁, 이제 돈값 싸움이다
- How Forward Deployed Engineering is done at Cognition — Jia Wu
- How Forward Deployed Engineering is done at Decagon - Sunny Rekhi