Skip to content
←

Split View: FDE(Forward Deployed Engineer)란 무엇인가 — 고객사 현장에 배치되는 엔지니어

✨ Learn with Quiz
|

FDE(Forward Deployed Engineer)란 무엇인가 — 고객사 현장에 배치되는 엔지니어

갑자기 어디에나 있는 직함

채용 공고를 훑다 보면 낯선 직함 하나가 부쩍 자주 보입니다. Forward Deployed Engineer, 줄여서 FDE. 팔란티어가 만든 직무이고, 지금은 OpenAI가 샌프란시스코·뉴욕·도쿄를 포함한 여러 도시에서 뽑고 있으며, 앤트로픽도 Applied AI 조직 아래에 같은 이름의 포지션을 열어 두고 있습니다. 생명과학 전담 FDE, 반도체 전담 FDE처럼 산업별로 쪼갠 공고까지 나오는 중입니다.

그런데 이 직함을 한국어로 검색하면 나오는 것이 거의 없습니다. 포워드 디플로이드 엔지니어라는 말 자체가 번역이 안 된 채로 떠돌고, 세일즈 엔지니어나 컨설턴트와 뭐가 다르냐는 질문에는 답이 흩어져 있습니다. 이 글은 그 공백을 메우는 FDE 완전 가이드 시리즈의 1편입니다. 정의에서 시작해 기술 지도, 온보딩, 장애 진단, 고객 커뮤니케이션, PoC 운영, 경력 전환, 인터뷰 준비까지 여덟 편으로 이어집니다.

정의 — 고객사 현장에 배치되는 엔지니어

이름부터 풀겠습니다. 전진 배치를 뜻하는 forward deployed는 군사 용어입니다. 병력을 본진이 아니라 최전선 가까이에 두는 것. 그 은유 그대로, FDE는 본사 사무실이 아니라 고객사 현장에 배치되는 엔지니어입니다. 물리적으로 상주하기도 하고 원격으로 붙기도 하지만, 핵심은 위치가 아니라 방향입니다. 일하는 좌표계가 자사 코드베이스가 아니라 고객의 환경이라는 것.

팔란티어의 공식 블로그는 이 직무를 제품 엔지니어와의 대비로 정의합니다. 제품 엔지니어가 하나의 기능을 많은 고객에게 전달하는 사람이라면, FDE는 한 고객에게 많은 기능을 전달하는 사람입니다. 하는 일을 나열하면 이렇습니다. 고객의 데이터와 인프라에 자사 제품을 연결하는 통합 코드를 쓰고, 고객 환경에서만 터지는 장애를 진단하고, "이게 안 돼요"라는 말을 엔지니어링 요구사항으로 번역하고, 현장에서 반복되는 패턴을 제품팀에 되돌려 보냅니다. 데모 슬라이드가 아니라 프로덕션에서 돌아가는 코드가 결과물이고, 성공의 척도는 계약서 서명이 아니라 고객의 실제 업무가 제품 위에서 돌아가는가입니다.

비슷한 직무 넷과 무엇이 다른가

FDE를 처음 들으면 대부분 이미 아는 직무 중 하나로 환원하려 합니다. 그 직감이 절반쯤 맞고 절반쯤 틀립니다. 경계가 회사마다 다르다는 전제 위에서, 경향을 표로 가르면 이렇습니다.

직무코드를 쓰는 위치개입 시점성공의 척도관계의 길이
FDE고객 환경 안의 프로덕션 코드계약 전후 전 구간제품이 실제 업무에 쓰이는가수개월에서 수년
솔루션스 아키텍트(SA)레퍼런스 설계와 예제도입 설계 단계아키텍처 채택설계 구간 중심
세일즈 엔지니어(SE)데모와 PoC 수준계약 전계약 성사계약 체결까지
컨설턴트권고안과 산출물 문서프로젝트 단위납품 완료프로젝트 종료까지
서포트 엔지니어재현 환경문제 발생 후티켓 해결티켓 단위

기준선은 두 개입니다. 첫째, 고객의 프로덕션 환경에 남는 코드를 쓰는가. SE의 데모는 계약이 끝나면 버려지고 컨설턴트의 권고안은 문서로 남지만, FDE가 쓴 통합 코드는 고객의 시스템 안에서 계속 돌아갑니다. 둘째, 계약 이후에도 관계가 이어지는가. FDE는 팔고 떠나는 직무가 아니라 굴러가게 만들고 지키는 직무입니다. 그래서 The Pragmatic Engineer의 분석처럼 FDE는 소프트웨어 엔지니어링, 세일즈 지원, 플랫폼 엔지니어링이 한 사람 안에 섞인 형태가 됩니다.

왜 AI 제품 시대에 급부상했는가

이 직무가 2020년대 중반에 갑자기 뜨거워진 데에는 구조적인 이유가 있습니다. 완성형 SaaS는 FDE가 필요 없습니다. 가입하고, 설정 몇 개를 고르면 끝나는 제품은 현장 엔지니어가 설 자리가 없습니다. FDE가 필요해지는 것은 제품이 미완성 플랫폼일 때입니다. 범용 능력 덩어리는 있는데, 그것이 특정 고객의 데이터·권한 체계·업무 흐름에 붙어야만 가치가 나오는 제품. 지금의 LLM이 정확히 그렇습니다. 모델은 범용이지만 가치는 고객마다 다르게 조립해야 하고, 그 조립은 설치가 아니라 공사에 가깝습니다.

여기서 핵심 논리가 나옵니다. 제품이 미완성일수록 현장 엔지니어링이 제품의 일부가 됩니다. 고객이 경험하는 것은 모델 그 자체가 아니라 자기 업무 위에서 돌아가는 조립 결과물이고, 그 조립을 해내는 사람이 없으면 제품은 사실상 존재하지 않는 것과 같습니다. 팔란티어가 이 모델의 원조입니다. 온톨로지 기반 플랫폼을 정부와 대기업에 팔면서, 한때는 제품 엔지니어보다 현장의 FDE가 더 많았을 정도로 이 직무에 회사를 걸었습니다. 그리고 LLM 시대가 오자 OpenAI와 앤트로픽이 같은 구조를 그대로 가져갔습니다. 파는 것이 미완성 플랫폼이라는 조건이 같기 때문입니다.

부수 효과도 큽니다. FDE는 제품팀이 절대 볼 수 없는 것을 봅니다. 실제 고객 데이터의 지저분함, 보안팀의 거부 사유, 현업 사용자가 진짜로 원하는 것. 이 관찰이 제품 피드백 루프를 타고 로드맵이 되면, FDE 한 사람이 영업과 제품 리서치를 겸한 셈이 됩니다. 비싼 직무가 성립하는 이유입니다.

이 직무가 맞는 사람, 맞지 않는 사람

솔직한 적성 이야기로 마무리하겠습니다. FDE가 잘 맞는 사람은 모호함을 견디는 사람입니다. 문서가 없는 시스템, 처음 보는 인프라, 서로 말이 다른 이해관계자 사이에서 빠르게 지도를 그리는 일이 업무의 절반입니다. 설명하는 것을 즐기는 사람, 기술적 깊이와 대인 커뮤니케이션 중 하나를 포기하고 싶지 않은 사람에게는 드물게 좋은 자리입니다.

반대로 하나의 코드베이스를 깊게 파는 데서 기쁨을 얻는 사람, 방해받지 않는 몰입 시간이 생산성의 전부인 사람에게는 힘든 직무입니다. 고객 미팅과 장애 대응이 일정을 수시로 쪼개고, 출장이나 상주가 섞이는 경우도 많습니다. 보상은 회사와 지역에 따라 편차가 크다는 것 정도만 말할 수 있고, 구체적 숫자는 공고와 오퍼에서 직접 확인하는 것이 정확합니다. 이 시리즈의 다음 글부터는 이 직무를 실제로 준비하는 쪽으로 들어갑니다. 먼저 기술 지도입니다.

직접 연습하기

읽는 것만으로는 늘지 않는 감각이 있습니다. 이 블로그에는 FDE 훈련용 인터랙티브 도구가 두 개 있습니다.

  • FDE 엔지니어 키우기 RPG — 낯선 고객 환경에서 시간·신뢰도·접근 권한을 배분해 장애 원인을 진단하는 의사결정 게임입니다. 31개 현장 미션, 6개 점검 시나리오, 8개 도메인 레벨이 있습니다.
  • FDE 커리큘럼 로드맵 — 10개 도메인 65개 스킬을 자가 점검 기준과 함께 추적하는 학습 체크리스트입니다.

FDE 완전 가이드 시리즈

참고 자료

What Is a Forward Deployed Engineer (FDE) — the Engineer Stationed at the Customer Site

A Title That Is Suddenly Everywhere

Skim job boards these days and one unfamiliar title keeps surfacing: Forward Deployed Engineer, FDE for short. Palantir created the role. OpenAI is now hiring FDEs across San Francisco, New York, Tokyo, and other cities, and Anthropic lists positions under the same name inside its Applied AI organization. There are even industry-specialized postings — FDEs dedicated to life sciences, FDEs dedicated to semiconductors.

Search for this title in Korean, though, and almost nothing comes back. The phrase floats around untranslated, and the question everyone asks — how is this different from a sales engineer or a consultant — has only scattered answers. This post is part 1 of the FDE Complete Guide series, written to fill that gap. It runs eight parts: definition, skill map, onboarding, incident diagnosis, customer communication, PoC operations, career transition, and interview preparation.

The Definition — an Engineer Stationed at the Customer Site

Start with the name. Forward deployed is a military term: placing forces not at the home base but near the front line. The metaphor carries over directly. An FDE is an engineer stationed not at headquarters but at the customer site. Sometimes that means physically residing there, sometimes working remotely — but the essence is not location, it is orientation. The coordinate system you work in is not your own codebase; it is the customer environment.

Palantir's official blog defines the role by contrast with product engineers. A product engineer delivers one capability to many customers; an FDE delivers many capabilities to one customer. The day-to-day list looks like this: write the integration code that connects your product to the customer's data and infrastructure, diagnose the failures that only happen in that one environment, translate "it does not work" into engineering requirements, and send the patterns you keep seeing in the field back to the product team. The deliverable is code running in production, not a demo deck, and the measure of success is not a signed contract but whether the customer's real work actually runs on the product.

How It Differs from Four Neighboring Roles

Hearing about FDEs for the first time, most people try to reduce the role to one they already know. That instinct is half right and half wrong. With the caveat that boundaries vary by company, the tendencies separate like this.

RoleWhere the code livesWhen they engageMeasure of successLength of relationship
FDEProduction code inside the customer environmentBefore and after the contractWhether real work runs on the productMonths to years
Solutions Architect (SA)Reference designs and examplesAdoption design phaseArchitecture adoptedMostly the design window
Sales Engineer (SE)Demos and PoC-level codePre-contractContract closedUntil signing
ConsultantRecommendations and deliverable documentsPer projectDelivery acceptedUntil project end
Support EngineerReproduction environmentsAfter a problem occursTicket resolvedPer ticket

Two lines matter most. First, does the person write code that stays in the customer production environment. An SE's demo is discarded once the deal closes and a consultant's recommendation survives only as a document, but the integration code an FDE writes keeps running inside the customer's systems. Second, does the relationship continue after the contract. FDE is not a sell-and-leave role; it is a make-it-run-and-keep-it-running role. That is why, as The Pragmatic Engineer's analysis puts it, the FDE blends software engineering, sales support, and platform engineering inside one person.

Why the Role Surged in the AI Product Era

There is a structural reason this role heated up in the mid-2020s. A finished SaaS product does not need FDEs. If signing up and picking a few settings is enough, there is no room for a field engineer to stand. FDEs become necessary when the product is an unfinished platform — a lump of general-purpose capability that only produces value once it is attached to one specific customer's data, permission model, and workflow. Today LLMs are exactly that. The model is general, but the value has to be assembled differently for every customer, and that assembly is less like installation and more like construction.

This yields the core logic: the less finished the product, the more field engineering becomes part of the product itself. What the customer experiences is not the model as such but the assembled result running on top of their own work — and without someone to do that assembly, the product might as well not exist. Palantir is the origin of this model. Selling an ontology-based platform to governments and large enterprises, it bet the company on this role to the point that, for a stretch of its history, field FDEs outnumbered product engineers. When the LLM era arrived, OpenAI and Anthropic took the same structure wholesale — because the condition is identical: what they sell is an unfinished platform.

The side effect is large too. FDEs see what product teams never can: how messy real customer data is, why the security team says no, what line users actually want. When those observations ride the product feedback loop back into the roadmap, one FDE has effectively doubled as sales support and product research. That is why such an expensive role pays for itself.

Who Fits This Role, and Who Does Not

Let me close with an honest fit check. The people who thrive as FDEs are the ones who tolerate ambiguity: half the job is drawing a map quickly amid undocumented systems, unfamiliar infrastructure, and stakeholders who contradict each other. If you enjoy explaining things, and you refuse to give up either technical depth or human communication, this is a rare seat that demands both.

Conversely, if your joy comes from digging deep into one codebase, and uninterrupted flow time is the whole of your productivity, this role will wear you down. Customer meetings and incident response slice the calendar constantly, and travel or on-site residency is often part of the deal. On pay, the honest statement is that variance is wide by company and region — check postings and offers directly rather than trusting any secondhand number. From the next post on, this series turns to actually preparing for the role, starting with the skill map.

Practice by Doing

Some instincts do not grow by reading. This blog carries two interactive tools built for FDE training.

  • FDE Career RPG — a decision game where you allocate time, trust, and access to diagnose failures in an unfamiliar customer environment. 31 field missions, 6 health-check scenarios, 8 domain levels.
  • FDE Curriculum Roadmap — a progress-tracked checklist of 65 skills across 10 domains, each with a concrete self-check criterion.

FDE Complete Guide series

References