Skip to content
←

Split View: Forward Deployed Engineer의 크래프트 — 요구사항 발굴, 도메인 모델링, 그리고 채택을 향한 최적화

|

Forward Deployed Engineer의 크래프트 — 요구사항 발굴, 도메인 모델링, 그리고 채택을 향한 최적화

들어가며 — 스킬 목록은 문을 열어 줄 뿐이다

앞선 글은 Forward Deployed Engineer에게 필요한 지식 — 리눅스·네트워크·쿠버네티스·DB·API 통합·보안 — 을 지도로 정리하고, 그 도메인들의 진행률을 추적하는 인터랙티브 체크리스트를 함께 붙였습니다. 그 지도는 문을 열어 줍니다. 하지만 고객사 건물 안에 들어간 뒤 실제로 무엇을 하는지에 대해서는 거의 아무 말도 하지 않습니다. 그건 다른, 더 낯선 크래프트입니다.

Palantir은 이 역할을 대비로 설명합니다. 일반 엔지니어가 "one capability, many customers"를 만든다면, FDSE — 사내 이름으로 "Delta" — 는 "one customer, many capabilities"를 만들며, 기존 플랫폼이 고객의 가장 어려운 문제를 풀도록 "embeds directly with our customers"합니다. 스킬 목록은 Delta가 무엇을 아는지를 말합니다. 크래프트는 Delta가 한 고객과 몇 달에 걸쳐, 그들의 혼돈을 작동하는 무언가로 바꾸기 위해 하는 일입니다. 그 대부분은 여섯 가지 움직임으로 이루어집니다.

고객이 ASK 한 것
   |
   |   요구사항 발굴   (진짜 통증을 파고든다)
   v
고객이 NEED 하는 것
   |
   |   공유 도메인 모델   (양쪽이 함께 가리키는 계약)
   v
당신이 BUILD 한 것  -- demo -->  피드백   (모델이 틀렸다; 반복)
   |
   |   나머지엔 아니오   (목표를 움직이는 것만 짓는다)
   v
ADOPTION   (당신이 떠난 뒤에도 쓴다)  =  유일한 점수

위에서 아래로 읽으면 그 루프가 곧 이 일입니다. 여섯 가지 움직임으로 이름 붙이면 이렇습니다.

  • 요구사항 발굴 — 요청을 뚫고 그 아래 통증까지 파고든다.
  • 도메인 모델링 — 고객의 현실을 양쪽이 함께 가리킬 수 있는 공유 모델로 바꾼다.
  • 통합 — 그 모델을, 데이터가 문서와 절대 맞지 않는 지저분하고 에어갭이며 레거시인 시스템에 연결한다.
  • 데모 — 작동하는 데모를 세일즈용 소품이 아니라 일차 피드백 도구로 다룬다.
  • 아니오라고 말하기 — 목표를 움직이는 것만 짓고 나머지는 거절한다.
  • 채택을 향한 최적화 — 유일한 점수는 당신이 떠난 뒤에도 그들이 쓰는가이다.

이 글의 나머지는 이것들을 하나씩 다룹니다.

요구사항 발굴 — 요청한 것 vs 진짜 필요한 것

명시된 요청이 진짜 요청인 경우는 거의 없습니다. 그것은 고객이 이미 절반쯤 스스로 진단해 압축해 놓은 통증의 결과물이고, 그 진단은 자주 틀립니다. 이 간극은 끊임없이 나타납니다.

  • 대시보드를 요청하지만, 필요한 것은 더 빨리 내려지는 결정이다.
  • **"엑셀로 내보내기"**를 요청하지만, 필요한 것은 자정마다 두 시스템을 손으로 대조하는 일을 멈추는 것이다.
  • 더 빠른 리포트를 요청하지만, 필요한 것은 다시 확인하지 않고도 그 숫자를 믿는 것이다.

FDE의 첫 일은 발굴입니다 — 요청을 뚫고 그 아래 통증까지 파고드는 것.

그래서 이 역할은 컨설팅이 아닙니다. The Pragmatic Engineer는 선을 깔끔하게 긋습니다 — 컨설턴트는 "one-off recommendations"를 내놓고 떠나지만, FDE는 고객과 오래 함께 일하며 결과를 소유합니다. 진단을 남에게 넘기고 떠날 수 없습니다. 그 안에서 삽니다. 발굴 작업은 구체적이고 화려하지 않습니다 — 실제로 그 일을 하는 사람 곁에 앉고, 그들의 실제 프로세스를 그리고, 어디서 가치가 새는지 지켜보는 것. Palantir의 엔지니어들은 "talking to customers, who know the subject matter best"에 진짜 시간을 쓴다고 말합니다.

그리고 지반은 계속 움직입니다. OpenAI의 Colin Jarvis가 (The Pragmatic Engineer를 통해) 말했듯, 스코핑 단계에서 고객이 묘사한 것은 종종 "doesn't match the data/system reality on the ground"입니다. 그러므로 발굴은 짓기 전에 끝내는 단계가 아닙니다. 프로젝트 내내 계속되고, 모든 데모가 새로운 발굴입니다.

도메인을 공유 모델로 만들기 — 핵심 행위

여기가 이 일 전체를 정의하는 움직임이자, 스킬 목록이 가르쳐 줄 수 없는 부분입니다. 진짜 통증을 알아낸 뒤, 당신은 고객의 지저분한 현실을 명시적 모델로 바꿔야 합니다 — 그들 비즈니스의 실제 명사와 동사, 엔티티와 그 사이의 관계 — 양쪽이 함께 가리키고 함께 논쟁할 수 있는 것으로. Palantir은 일상 업무를 "designing, writing and testing workflows"라고 표현하는데, 모든 워크플로 밑에는 "고객의 세계가 무엇인가"에 대한 모델이 깔려 있습니다.

이 모델이 곧 계약입니다. "필요한 것"과 "짓는 것" 사이에 정확히 놓여, 그 둘을 모두 읽을 수 있게 만듭니다. 당신과 고객의 이해가 어긋날 때, 당신은 모델로 걸어가 손가락으로 가리킬 수 있어야 합니다 — 이 엔티티, 이 관계, 여기서 우리의 이해가 갈라진다고. 모델이 없으면 의견을 주고받을 뿐이고, 모델이 있으면 공유된 산출물을 디버깅하는 것입니다. 우연이 아니게도, Palantir이 두 역할로 공식화한 분업이 바로 이것입니다 — 문제와 모델을 소유하는 Deployment Strategist, 소프트웨어를 소유하는 FDSE. 다만 OpenAI와 Anthropic에서는 한 명의 FDE가 그 둘을 함께 집니다.

이 모델을 제대로 잡는 것이 FDE가 하는 일 중 레버리지가 가장 큰 일이고, 별도로 다룰 만큼 깊습니다. 이 시리즈의 다음 글은 이 모델을 형식화하는 것 — 소프트웨어가 추론할 수 있는 *온톨로지(ontology)*로 바꾸는 것 — 을 다루고, 그다음 글은 그 모델 위에서 Graph RAG로 검색하는 것을 다룹니다. 지금은 원칙만 붙잡으면 됩니다. 모델은 코드보다 먼저 오고, 틀린 모델을 아무리 아름답게 구현해도 여전히 틀린 것입니다.

지저분하고, 에어갭이며, 레거시인 환경에 통합하기

여기서 앞선 준비기의 지식 지도가 실제로 쓰입니다. 다만 크래프트는 그린필드 엔지니어링과 다릅니다 — 환경이 구체적이고 반복적인 방식으로 당신과 싸우기 때문입니다.

  • 닫힌 망. 에어갭 구역, 사설 레지스트리, 사내 프록시가 예외가 아니라 기본값이다.
  • 거짓말하는 데이터. 진짜 데이터는 아무도 완전히 이해하지 못하는 레거시 시스템에 살고, 문서와 절대 일치하지 않는다.
  • 물려받은 규모. Palantir의 한 엔지니어는 문제의 형태를 대략 이렇게 요약한다 — 비즈니스가 멈추면 안 되는 워크플로에 데이터를 공급하는 테라바이트급 파이프라인을 어떻게 짓고 유지하는가.
  • 모든 단계의 관문. 고객사 보안팀은 우회할 장애물이 아니라 통과해야 할 관문이며 — 당신이 얼마나 빨리 반복할 수 있는지에 대한 실제 제약이다.

여기서의 크래프트는 조정(reconciliation)입니다 — 한 손엔 깨끗한 도메인 모델을, 다른 손엔 실제의 더러운 바이트를 들고, 어느 쪽도 틀렸다고 우기지 않으면서 그 간극을 좁히는 것. 좋은 FDE들의 방식에서 빌려 온 유용한 규율 하나는, 먼저 합성 데이터로 프로토타입해 해법의 형태를 증명하고 — 그다음에야 진짜 소스에 연결하는 것입니다. 놀라움은 늘 거기 숨어 있습니다. 앞 절의 모델이 이것을 견딜 만하게 만듭니다 — 바이트가 당신의 이해와 모순될 때, 당신에게는 "뭔가 어긋났다"는 막연한 느낌이 아니라 고쳐야 할 명시적 대상이 있습니다.

데모, 이해관계자, 그리고 기대 관리

데모는 세일즈용 소품이 아닙니다. FDE에게 데모는 일차 피드백 도구입니다 — 당신의 요구사항 발굴이 틀렸음을 발견하는 가장 빠르고 값싼 방법. Palantir은 좋은 버전을 "rapid cycle between creating solutions and seeing them in action", 즉 고객과 손을 맞잡고 반복하는 것이라 표현합니다. 고객의 마음을 바꾸거나 당신이 그들의 마음을 오해했음을 드러내는 데모는, 코드를 버리더라도 제 몫을 다한 것입니다. 이 "버리는 프로토타입" 방식의 구체적 메커니즘은 버리는 프로토타입 플레이북에서 따로 다뤘습니다.

틀리기 쉬운 크래프트 포인트가 둘 있습니다. 첫째, 방 안에는 이해관계자가 한 명이 아닙니다 — 여럿이고, 자주 갈라져 있으며, 각자 성공을 다르게 잽니다. 그 방을 붙잡는 것 — 이견을 소리 내어 이름 붙이고, 가장 큰 목소리를 위해 조용히 짓는 대신 결정으로 몰고 가는 것 — 이 일의 일부입니다. 둘째, 너무 매끈한 데모를 경계하십시오. 완성된 것처럼 보이는 데모는 당신이 아직 벌지 못한 약속을 만듭니다 — 무엇이 진짜이고, 무엇이 가짜이며, 무엇이 남았는지 이음매를 보여 주는 것이 기대를 정직하게 유지하고, 어려운 부분이 닥쳤을 때 신뢰를 지킵니다.

언제 아니오라고 말할까 — 과잉 설계 피하기

"one customer, many capabilities"는 설명이지 허가증이 아닙니다. 고객이 요청하는 모든 기능을 지으려는 순간 그것은 함정이 됩니다. 당신이 임베드돼 있기 때문에, 그들이 성공하길 바라기 때문에, 예라고 말하는 것이 봉사처럼 느껴지기 때문에 — 과잉 설계는 FDE의 기본 실패 모드입니다. 당신이 추가하는 모든 기능은, 결국 당신이 떠날 환경에서 당신이 유지보수해야 할 하나입니다.

규율은 고객의 실제 목표를 움직이는 것만 짓고 나머지엔 아니오라고 말하는 것입니다 — 분명하게, 일찍, 이유를 붙여서. The Pragmatic Engineer는 이를 직접 지목합니다 — FDE는 고객 성공과 제품 사이의 다리이고, 다리는 경쟁하는 요구들에 우선순위를 매기고 아니오라고 말해야 합니다. Anthropic의 FDE 공고도 다른 각도에서 같은 곳을 가리킵니다 — 미션은 "codify repeatable deployment patterns"하고 인사이트를 제품으로 되돌리는 것. 즉 일회성 맞춤보다 일반화되는 것을 택하라는 뜻입니다. 맞춤은 당신의 퇴장에서 살아남지 못하니까요.

성공은 실제로 어떻게 측정되나 — 짠 코드가 아니라 채택

위 움직임 중 어느 것도 산출량으로 채점되지 않습니다. The Pragmatic Engineer는 분명히 말합니다 — FDE는 "measure success in terms of impact on the customer's goal", 즉 배포한 코드 줄 수가 아니라 조립 라인에서 나오는 불량품이 줄었는가로 잽니다. Palantir의 엔지니어들도 보상을 같은 식으로 묘사합니다 — 소프트웨어가 고객의 의사결정에 미친 임팩트를 직접 눈으로 보는 것. 지표는 당신의 커밋 로그가 아니라 고객의 세계를 가리킵니다.

이것의 잔인하고 명료한 버전은 한 문장의 질문입니다 — 당신이 떠난 뒤에도 그들이 계속 썼는가? 아무도 열지 않는 아름다운 시스템은 실패이고, 누군가의 일상 업무에서 없으면 안 되는 존재가 된 하드코딩된 프로토타입은 성공입니다. 이 질문은 위쪽의 모든 것을 다시 규정합니다 — 발굴도, 공유 모델도, 데모도, 아니오라고 말하는 규율도 모두 채택을 위해 존재합니다. 제품 회사에는 두 번째 축도 있습니다 — 고객 안에서 배운 것이 제품이 됩니다. Anthropic은 문자 그대로 FDE에게 그 패턴을 Product·Engineering으로 되돌리라고 요구합니다. 최고의 FDE는 자신을 단순한 전달 수단이 아니라 로드맵의 센서로 만듭니다.

정직한 부분 — 다리로 서 있기

이 일의 어려운 부분은 기술이 아닙니다. 당신이 어느 쪽에도 온전히 속하지 못한다는 것입니다. 고객의 좌절을 당신 회사로 나르고, 당신 제품의 한계를 고객에게 나르며, 둘 다 여전히 참인 그 간극에 서 있습니다. 모호함은 예외가 아니라 기본값입니다 — Anthropic 공고는 "operate autonomously, thrive under ambiguity"할 사람을 대놓고 찾고, 모든 FDE 공고가 같은 말을 어떤 형태로든 반복합니다.

그리고 물리적 현실이 있습니다 — Palantir은 약 25%, Anthropic은 25–50%의 출장, 고객의 일정에 맞춰, 그들의 보안 경계 안에서, 자주 그것이 깨졌을 때 그들이 부를 유일한 이름으로. 이것은 어떤 사람에게는 에너지를 주고, 어떤 사람에게는 조용히 소모시킵니다. 서명하기 전에 자신이 어느 쪽인지 아는 편이 낫습니다. 이 크래프트는 정말로 드물고 빠르게 복리로 쌓입니다 — 다만 그 값은 스킬 목록이 결코 언급하지 않는, 두 조직 사이의 일종의 무주지(homelessness)로 치릅니다.

마치며

지식 지도는 당신을 유능하게 만듭니다. 크래프트 — 진짜 필요를 파고들고, 도메인을 양쪽이 가리킬 수 있는 것으로 모델링하고, 적대적 환경에 통합하고, 데모를 피드백으로 쓰고, 아니오라고 말하고, 채택을 향해 끈질기게 최적화하는 것 — 은 당신을 신뢰받게 만듭니다. 앞은 체크리스트이고, 뒤는 판단이며, 그것은 오직 지켜보는 고객 앞에서 일을 해 봐야 얻어집니다.

토대를 쌓는 중이라면 지식 지도와 그 체크리스트 도구에서 시작하십시오. 여기서부터 시리즈는 위의 가장 레버리지 큰 움직임으로 더 깊이 들어갑니다 — 다음 글은 도메인 모델을 온톨로지로 형식화하고, 그다음 글은 그 위에서 Graph RAG로 검색합니다. 코드는 애초에 어려운 부분이 아니었습니다. 고객의 세계가 실제로 무엇인지 정하는 것 — 그것이 크래프트입니다.

참고 자료

The Craft of a Forward Deployed Engineer: Requirement Archaeology, Domain Modeling, and Optimizing for Adoption

Introduction — The Skill List Gets You in the Door

An earlier post mapped the knowledge a Forward Deployed Engineer needs — Linux, networking, Kubernetes, databases, API integration, security — and paired it with an interactive checklist to track your progress across those domains. That map gets you in the door. It says almost nothing about what you actually do once you are inside a customer's building, which is a different and stranger craft.

Palantir frames the role by contrast: a regular engineer builds "one capability, many customers," while a Forward Deployed Software Engineer — a "Delta," in Palantir's internal name — builds "one customer, many capabilities," someone who "embeds directly with our customers" to make an existing platform solve their toughest problem. The skill list tells you what a Delta knows. The craft is what a Delta does with a single customer, over months, to turn their reality into something that works. Six moves make up most of it.

What the customer ASKS for
   |
   |   requirement archaeology   (dig for the real pain)
   v
What the customer NEEDS
   |
   |   shared domain model       (the contract both sides point at)
   v
What you BUILD  -- demo -->  feedback   (the model was wrong; repeat)
   |
   |   say no to the rest        (build only what moves the goal)
   v
ADOPTION   (they still use it after you leave)  =  the only score

Read top to bottom, that loop is the job. Named as six moves:

  • Requirement archaeology — dig past the request to the pain underneath.
  • Domain modeling — turn the customer's reality into a shared model both sides can point at.
  • Integration — wire that model into messy, airgapped, legacy systems where the data never matches the docs.
  • Demos — treat a working demo as the primary feedback instrument, not a sales prop.
  • Saying no — build only what moves the goal; refuse the rest.
  • Optimizing for adoption — the only score is whether they still use it after you leave.

The rest of this post takes them one at a time.

Requirement Archaeology — What They Need vs What They Asked For

The stated request is almost never the real one. It is a compressed artifact of a pain the customer has already half-diagnosed, and the diagnosis is often wrong. The gap shows up constantly:

  • They ask for a dashboard; they need a decision made faster.
  • They ask to export to Excel; they need to stop reconciling two systems by hand at midnight.
  • They ask for a faster report; they need to trust the number without re-checking it.

The FDE's first job is archaeology: dig past the request to the pain underneath it.

This is why the role is not consulting. The Pragmatic Engineer draws the line cleanly — consultants make "one-off recommendations," whereas FDEs work with customers long-term and own the outcome. You cannot hand a diagnosis to someone else and leave; you live inside it. The discovery work is concrete and unglamorous: sitting with the people who do the job, mapping their actual process, watching where value leaks. Palantir's engineers describe spending real time "talking to customers, who know the subject matter best."

And the ground truth keeps moving. As OpenAI's Colin Jarvis put it (via The Pragmatic Engineer), what the customer describes in scoping "doesn't match the data/system reality on the ground." So archaeology is not a phase you finish before building. It runs the whole engagement, and every demo is a fresh excavation.

Modeling the Domain Into a Shared Model — The Core Act

Here is the move that defines the whole job, and the one the skill list cannot teach. Once you know the real pain, you have to turn the customer's messy reality into an explicit model — the actual nouns and verbs of their business, the entities and the relationships between them — that both sides can point at and argue over. Palantir describes the daily work as "designing, writing and testing workflows"; underneath every workflow is a model of what the customer's world is.

The model is the contract. It sits exactly between "what they need" and "what you build," and it is the thing that makes both legible. When you and the customer disagree, you should be able to walk to the model and point: this entity, this relationship, this is where our understanding diverges. Without it, you are trading opinions. With it, you are debugging a shared artifact. This is also, not coincidentally, the split Palantir formalized into two roles — a Deployment Strategist who owns the problem and the model, and an FDSE who owns the software — though at OpenAI and Anthropic the single FDE now carries both.

Getting this model right is the highest-leverage thing an FDE does, and it is deep enough to deserve its own treatment. The next post in this series is about making the model formal — turning it into an ontology the software can reason over — and the one after that is about retrieving over that model with Graph RAG. For now, hold onto the principle: the model comes before the code, and a wrong model implemented beautifully is still wrong.

Integrating Into Messy, Airgapped, Legacy Environments

This is where the knowledge map from the prep post gets spent — but the craft is different from greenfield engineering, because the environment fights you in specific, repeatable ways:

  • Closed networks. Airgapped segments, private registries, and corporate proxies are the default, not the exception.
  • Data that lies. The real data lives in a legacy system nobody fully understands, and it never matches the documentation.
  • Scale you inherit. A Palantir engineer sums up the shape of the problem as, roughly, how to build and maintain a terabyte-scale pipeline feeding a workflow the business cannot afford to have go down.
  • A gate on every step. The customer's security team is a gate you pass, not an obstacle you route around — and a real limit on how fast you can iterate.

The craft here is reconciliation: holding your clean domain model in one hand and the actual dirty bytes in the other, and closing the gap without pretending either is wrong. A useful discipline, borrowed from how good FDEs work, is to prototype against synthetic data first — prove the shape of the solution — and only then wire it to the real source, where the surprises live. The model from the previous section is what makes this survivable: when the bytes contradict your understanding, you have an explicit thing to correct rather than a vague feeling that something is off.

Demos, Stakeholders, and Setting Expectations

A demo is not a sales artifact. For an FDE it is the primary feedback instrument — the fastest, cheapest way to discover that your requirement archaeology was wrong. Palantir describes the good version as a "rapid cycle between creating solutions and seeing them in action," iterating hand-in-hand with the customer. The demo that changes the customer's mind, or reveals that you misunderstood theirs, has earned its keep even if you throw the code away. The mechanics of that disposable-prototype approach are their own topic, covered in the throwaway-prototypes playbook.

Two craft points are easy to get wrong. First, the room is not one stakeholder — it is several, often divided, each measuring success differently. Part of the job is holding that room: naming the disagreement out loud and driving it to a decision instead of quietly building for whoever spoke loudest. Second, resist the too-polished demo. A demo that looks finished creates a promise you have not earned yet; showing the seams — what is real, what is faked, what is left — is what keeps expectations honest and keeps trust intact when the hard part arrives.

Knowing When to Say No — Avoiding the Over-Build

"One customer, many capabilities" is a description, not a license. It becomes a trap the moment you try to build every capability the customer asks for. Because you are embedded, because you want them to succeed, because saying yes feels like service — over-building is the FDE's default failure mode. Every feature you add is one you will have to maintain in an environment you will eventually leave.

The discipline is to build only what moves the customer's actual goal, and to say no to the rest — clearly, early, with the reason attached. The Pragmatic Engineer names this directly: the FDE is a bridge between customer success and product, and the bridge has to prioritize and say no to competing demands. Anthropic's FDE posting points the same way from another angle: the mandate is to "codify repeatable deployment patterns" and feed insights back to product — that is, prefer what generalizes over the one-off bespoke thing, precisely because the bespoke thing does not survive your departure.

How Success Is Actually Measured — Adoption, Not Lines Shipped

None of the moves above are scored on output. The Pragmatic Engineer is explicit that FDEs "measure success in terms of impact on the customer's goal" — fewer defective products coming off the assembly line, not lines of code deployed. Palantir's engineers describe the reward the same way: seeing first-hand the impact the software had on the decisions the client was making. The metric points at the customer's world, not your commit log.

The brutal, clarifying version of this is a single question: did they keep using it after you left? A beautiful system nobody opens is a failure, and a hardcoded prototype that becomes load-bearing in someone's daily work is a success. That question reframes everything upstream — the archaeology, the shared model, the demos, the discipline to say no all exist to serve adoption. There is a second axis, too, at product companies: what you learned inside the customer becomes the product. Anthropic literally asks its FDEs to contribute those patterns back to Product and Engineering. The best FDEs make themselves a sensor for the roadmap, not just a delivery mechanism.

The Honest Part — Being the Bridge

The hard part of this job is not technical. It is that you belong fully to neither side. You carry the customer's frustration back to your company and your product's limits forward to the customer, and you stand in the gap while both are still true. Ambiguity is the baseline, not the exception — Anthropic's posting asks bluntly for people who "operate autonomously, thrive under ambiguity," and every FDE posting says some version of the same thing.

Then there is the physical reality: travel of roughly 25% at Palantir, 25–50% at Anthropic, on the customer's timeline, inside their security perimeter, often as the single name they will call when it breaks. This energizes some people and quietly drains others, and it is worth knowing which one you are before you sign up. The craft is genuinely rare and it compounds fast — but it is paid for in a kind of homelessness between two organizations that the skill list never mentions.

Closing

The knowledge map makes you competent. The craft — digging for the real need, modeling the domain into something both sides can point at, integrating into a hostile environment, using demos as feedback, saying no, and optimizing relentlessly for adoption — is what makes you trusted. The first is a checklist; the second is judgment, and it only comes from doing the work in front of a customer who is watching.

If you are building the foundation, the knowledge map and its checklist tool are where to start. From here, the series goes deeper into the single highest-leverage move above: the next post makes the domain model formal as an ontology, and the one after that retrieves over it with Graph RAG. The code was never the hard part. Deciding what the customer's world actually is — that is the craft.

References