필사 모드: What Is a Forward Deployed Engineer (FDE) — the Engineer Stationed at the Customer Site

• A Title That Is Suddenly Everywhere
• The Definition — an Engineer Stationed at the Customer Site
• How It Differs from Four Neighboring Roles
• Why the Role Surged in the AI Product Era
• Who Fits This Role, and Who Does Not
• Practice by Doing
• References

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.

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

• Next: The FDE Skill Map — Baselines, Working Levels, and Check Questions for 8 Domains

References

• A Day in the Life of a Palantir Forward Deployed Software Engineer — Palantir Blog — the source for the definition and the one-customer-many-capabilities contrast used in this post.
• OpenAI Careers — Forward Deployed Engineer postings, including life-sciences and semiconductor FDE roles and an FDE manager position.
• Anthropic job board — where Forward Deployed Engineer positions in the Applied AI organization are posted.
• What are Forward Deployed Engineers, and why are they so in demand? — The Pragmatic Engineer — an analysis of the role comparison and the history of the Palantir model.