- 갑자기 어디에나 있는 직함
- 정의 — 고객사 현장에 배치되는 엔지니어
- 비슷한 직무 넷과 무엇이 다른가
- 왜 AI 제품 시대에 급부상했는가
- 이 직무가 맞는 사람, 맞지 않는 사람
- 직접 연습하기
- 참고 자료
갑자기 어디에나 있는 직함
채용 공고를 훑다 보면 낯선 직함 하나가 부쩍 자주 보입니다. 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 완전 가이드 시리즈
참고 자료
- A Day in the Life of a Palantir Forward Deployed Software Engineer — Palantir Blog — 이 글의 정의와 "한 고객, 많은 기능" 대비의 출처입니다.
- OpenAI Careers — Forward Deployed Engineer 공고들. 생명과학·반도체 전담 FDE와 FDE 매니저 포지션까지 확인할 수 있습니다.
- Anthropic 채용 공고 보드 — Applied AI 조직의 Forward Deployed Engineer 포지션이 올라오는 곳입니다.
- What are Forward Deployed Engineers, and why are they so in demand? — The Pragmatic Engineer — 직무 비교와 팔란티어 모델의 역사에 관한 분석 기사입니다.
현재 단락 (1/27)
채용 공고를 훑다 보면 낯선 직함 하나가 부쩍 자주 보입니다. Forward Deployed Engineer, 줄여서 FDE. 팔란티어가 만든 직무이고, 지금은 OpenAI가 샌프...