The Dirty Secret of Forward Deployed Engineering — Natalie Meurer, Sierra

한 줄 핵심

Forward Deployed Engineering은 원래 고객 현장 문제를 해결하는 여러 역할의 묶음이었고, AI와 에이전트 시대에 들어 그 범위가 더 넓어져 결국 제품·운영·배포·고객성과를 모두 책임지는 형태로 수렴하고 있다.

시간별 요약

1. 0:01
   발표자는 Forward Deployed Engineering의 정의가 너무 넓어져 이제는 하나의 직무라기보다 여러 역할을 묶어 부르는 말이 되었다고 본다. 본인의 Palantir와 Sierra 경험을 바탕으로, 이 개념의 역사와 현재 의미를 다시 정리하겠다는 문제의식을 제시한다.
2. 4:01
   초기의 FDE는 사실상 DevOps와 같았고, 서버 배포와 운영 안정성이 핵심이었다. 이후 데이터 통합, ontology, Slate 같은 커스텀 솔루션 구축으로 역할이 확장되면서, 고객 환경을 깊이 이해해 데이터를 실제 의사결정에 연결하는 일이 중심이 되었다.
3. 8:01
   Foundry 시대로 오면서 FDE는 고객을 대신해 일하는 역할에서 고객이 스스로 더 많은 작업을 하도록 돕는 역할로 바뀌었다. Airbus 사례처럼 enablement가 중요해졌고, 최근에는 AIFTE처럼 LLM을 활용해 그 작업을 자동화하는 방향으로도 진화하고 있다.
4. 10:01
   오늘날 FDE 채용은 전통적 엔지니어, 세일즈, 솔루션 아키텍트, 교육 역량까지 한 번에 요구하는 방향으로 과도하게 넓어졌다. 그럼에도 공통점은 항상 고객 책임에 있으며, AI로 코드 생산비용이 낮아질수록 FDE는 단순 구현보다 제품에 고객 신호를 연결하는 역할로 더 중요해진다.
5. 13:01
   AI 시대에는 제품 엔지니어도 고객 접점과 배포 책임을 가져야 하고, 반대로 FDE는 제품 개발에 더 깊게 관여하게 된다. 여기에 outcome-based pricing이 확산되면, 고객 성과를 실제로 보장할 수 있는 조직과 역할이 필요해지고, 결국 모든 직무가 FDE 방향으로 수렴한다.
6. 15:00
   발표의 결론은 Forward Deployed Engineering이 이미 죽었고 동시에 어디에나 존재한다는 역설이다. 정의는 흐려졌지만, 고객 성과를 책임지는 방식으로 제품·에이전트·배포를 묶는 사고방식은 앞으로 더 넓게 확산될 것이라고 강조한다.

실무 인사이트

• FDE를 채용할 때는 직무명보다 고객 책임 범위를 먼저 정의해야 하며, DevOps·데이터 통합·솔루션 구축·enablement 중 무엇이 핵심인지 분리해 두어야 한다.
• AI로 코드 생산비용이 낮아진 만큼, 엔지니어링 팀은 구현 속도보다 고객 성과를 제품 신호로 되돌리는 루프를 설계하는 데 더 많은 시간을 써야 한다.
• 에이전트나 AI 제품을 도입할 때는 기능 완성도보다 outcome-based pricing이 가능한지, 즉 실제 성과를 측정하고 보장할 수 있는지가 더 중요한 설계 기준이 된다.