FDE (Forward Deployed Engineer)

FDE(Forward Deployed Engineer, 포워드 디플로이드 엔지니어) 는 고객이나 현업의 현장에 직접 들어가 아직 정의되지 않은 문제를 발견하고, 해결책을 직접 만들어 실제로 쓰이게 하고, 성과까지 책임지는 엔지니어입니다. 흔히 "개발자 + 컨설턴트 + PM"으로 설명하지만 그것만으로는 부족합니다. FDE를 가르는 것은 직무의 조합이 아니라 일이 시작되는 방향입니다.

구조를 뒤집는다 — 결과에서 출발해 거꾸로 만든다

전통적인 소프트웨어 개발은 본사 제품팀이 제품을 정의하고, 현장의 솔루션 엔지니어나 영업이 만들어진 제품을 고객에게 적용하는 순서로 움직입니다. FDE는 이 순서를 뒤집습니다. 아직 정답이 없는 현장에 엔지니어가 먼저 들어가, 고객이 만들어야 할 결과를 내려면 무엇이 필요한지를 현장에서 찾고, 그 과정에서 발견한 해결책을 다시 제품이나 패턴으로 일반화합니다.

그래서 FDE에게 주어지는 것은 상세한 구현 지시가 아니라 "이 업무 시간을 절반으로 줄여라", "생산 증산을 지원하라" 같은 달성해야 할 결과입니다. 구체적인 방법은 FDE가 현장에서 결정합니다. 여러 회사의 채용 공고와 Palantir의 구조를 겹쳐 보면 FDE의 정의는 이렇게 좁혀집니다.

고객·현업의 아직 정의되지 않은 문제를 기술로 해결해 측정 가능한 성과를 만들고, 그 과정에서 발견한 것을 제품과 조직의 학습으로 환류시키는 현장 배치형 엔지니어.

핵심 단어는 넷입니다. Problem → Build → Outcome → Productization. 이 네 개가 한 사람 안에서 이어지지 않으면 FDE라기보다 SI, AI 컨설팅, 프로페셔널 서비스, 솔루션 엔지니어에 가까워집니다. 이 흐름을 여덟 단계로 풀어 쓴 것이 FDE Loop입니다.

좋은 FDE는 두 개의 질문을 동시에 한다

FDE가 단순한 고객 맞춤 개발과 갈리는 가장 중요한 지점입니다. FDE의 목표는 한 고객에게만 작동하는 해결책이 아닙니다. 하나의 구체적인 문제를 풀면서 동시에 "이 해결법을 한 산업, 한 문제 범주 전체에 어떻게 적용할 수 있을까"를 생각합니다.

• 단기 목표 — 지금 이 고객의 문제를 해결하고 실제 성과를 만든다.
• 장기 목표 — 그 과정에서 발견한 것을 일반화해, 다음 고객은 더 적은 노력으로 같은 문제를 푼다.

그래서 좋은 FDE는 "이 문제를 지금 어떻게 해결하지?"와 "이 문제는 다른 100개 조직에서도 반복될 문제인가?"를 같이 묻습니다. 두 번째 질문이 빠지면 SI가 됩니다. FDE의 오너십을 한 문장으로 줄이면 이렇습니다. 현장의 고통을 흡수해서 제품으로 바꾸는 것. OpenAI도 FDE의 성공을 단순 납품이 아니라 프로덕션 정착, 측정 가능한 업무 임팩트, 재사용 가능한 패턴, 제품·모델 로드맵 피드백으로 정의합니다.

SI·컨설턴트·솔루션 엔지니어와 무엇이 다른가

전통 직무를 네 가지 역량 축 — 생각하고(Think), 만들고(Build), 현업에서 작동하게 하고(Deploy), 다시 쓸 수 있게 만드는(Scale) — 으로 놓고 보면 차이가 선명합니다.

이 결합이 희소한 것입니다. 경제 구조도 다릅니다. 일반적인 SI·컨설팅은 투입 시간과 인원에 따라 매출이 늘고, 계약서에 정해진 산출물을 전달하며, 고객 문제를 해결해도 자기 제품이 좋아진다는 보장이 없습니다. 오히려 문제 해결에 많은 사람이 오래 투입될수록 매출이 늘 수 있습니다. FDE는 반대 방향을 지향합니다. 사람을 더 투입해 해결하는 대신 자동화·재사용·제품화로 다음 문제를 더 싸게 풀어야 하고, 그래야 컨설팅 회사로 변하지 않습니다.

FDE의 원형: Palantir의 Echo와 Delta

Palantir를 이해할 때 흔한 오해가 하나 있습니다. Palantir에 한 종류의 FDE만 있는 것이 아닙니다. 대략 Echo = Deployment Strategist, Delta = Forward Deployed Software Engineer, Dev = Core Software Engineer 구조이고, 현재 채용 페이지에도 Delta와 Echo가 별도 역할로 운영됩니다.

• Echo(Deployment Strategist) 는 문제를 발견하고 구조화합니다. 단순 요구사항 수집이 아니라 "무엇이 가장 중요한 문제인가, 데이터가 무엇을 의미하는가, 사용자는 왜 그렇게 행동하는가, 어디에서 실제 임팩트가 발생하는가"를 종합합니다. 컨설턴트 + PM + 비즈니스 애널리스트 + 사용자 리서처에 가깝습니다.
• Delta(FDSE) 는 실제로 만듭니다. 고객과 첫 대화를 하는 순간부터 제품이 운영 업무를 바꿀 때까지 끝까지 소유하며, New Grad 공고에조차 아키텍처 결정, 대규모 데이터, 커스텀 애플리케이션, LLM 워크플로, 프로덕션 솔루션, 사용자부터 임원까지의 이해관계자 관리가 명시돼 있습니다.

Palantir의 진짜 혁신은 직무가 아니라 운영 모델입니다. 현장 → 제품 학습 루프. 현장에서 발견한 문제를 일회성 개발로 끝내지 않고 중앙 제품·엔지니어링으로 다시 가져갑니다. Palantir 초기에는 제품팀에 들어가기 전에 일정 기간 고객 현장에서 일하는 경험을 요구했습니다. 현장을 경험하지 않은 사람이 현장에 필요한 제품을 결정하기 어렵다는 판단입니다.

OpenAI형 FDE는 여기에 모델 피드백 루프를 더합니다. 고객 문제 → AI 애플리케이션 → 프로덕션 → 평가(eval) → 모델 실패 발견 → 연구·제품 개선으로 이어지며, 최근에는 Technical Deployment Lead를 따로 두어 Palantir의 Echo + Delta 구조와 다시 닮아가고 있습니다. Google Cloud는 자사 GenAI FDE를 "Embedded Builder"로 부르며, 아키텍처를 설명하고 끝나는 자문 역할이 아니라 고객 환경 안에서 직접 코드를 쓰고 디버깅하고 배포까지 하는 역할로 정의합니다.

하나의 직무가 아니다 — 최소 다섯 가지 변형

한국에서는 크게 세 방향으로 나타납니다. AI 회사가 고객 기업에 들어가 구축하는 외부 AI 배치형(한국딥러닝·Superb AI·마키나락스), SaaS 제품을 고객 워크플로에 맞춰 구현하고 제품에 피드백하는 SaaS 제품 FDE형(채널코퍼레이션·Sendbird·PortOne), 그리고 자기 회사 현업 안으로 들어가는 사내 AX FDE형(크래프톤·패스트뷰)입니다. 세 번째가 한국 대기업 AX에서 가장 현실적인 모델이며, 이를 Internal FDE로 따로 정리했습니다. FDE라는 직함보다 어떤 운영 모델인지를 봐야 하는 이유입니다.

2026년 한국에서 일어나고 있는 일

크래프톤 채용 공고의 역할 정의가 특히 구체적입니다. AI Transformation 부서 소속으로, AI 개발팀도 PM 조직도 아닙니다. 팀카이는 FDE를 "고객사의 에이전트를 직접 만들고 합의한 운영 지표가 실제로 움직일 때까지 현장에 있는 사람"으로 정의하며 AI 응대율·AI 업무 처리율 같은 지표를 FDE가 책임지게 합니다. 무언가를 만든 사람이 아니라 성과를 만든 사람으로 평가한다는 뜻입니다.

FDE에게 필요한 능력

여러 채용 공고를 겹쳐 놓으면 열 개 정도의 역량으로 수렴합니다. 문제 발견, 문제 구조화, 워크플로 모델링, 가치 판단, 빠른 구현, 시스템 연동, AI 엔지니어링과 평가, 배포·운영, 정착·변화 관리, 패턴 추출입니다. 이 가운데 Palantir 모델이 특히 강조하는 것은 넷입니다.

• 지저분한 문제를 피하지 않는 태도. 실제 현장은 정리된 데이터나 깨끗한 API가 아니라 레거시 시스템, 불완전한 프로세스, 고객의 불만과 긴급한 요구로 가득합니다. 경쟁사가 하기 싫어하는 지저분한 데이터 통합과 까다로운 현장 문제를 감수하는 것이 복제하기 어려운 경쟁력이 됩니다. 이 관점을 압축한 말이 "고통이 곧 해자"입니다.
• 높은 자율성. 상세한 지시 없이 "이 결과를 만들어라"만 받고도 스스로 문제를 정의하고 원인을 찾고 설계하고 구현하고 검증하고 수정할 수 있어야 합니다.
• 기존 제품에 반박할 수 있는 독립성. 현장에서 제품이 작동하지 않으면 "현재 제품의 가정이 틀렸다"고 말할 수 있어야 합니다.
• 일반화 능력. 개별 문제를 푸는 능력과, 그 문제에서 패턴을 발견해 "다음에는 이 문제가 생기지 않게 무엇을 바꿀까"로 전환하는 능력이 동시에 필요합니다.

FDE에 맞는 사람은 하나의 전형적인 경력으로 정의하기 어렵습니다. 물리학에서 소프트웨어로, 연구에서 현장 엔지니어링으로 옮겨온 교차 분야 배경이 잘 맞는 경우가 많고, 공통점은 "왜 내가 이 문제를 풀어야 하는가"에 대한 자기만의 이유가 있다는 것입니다. 그래서 FDE 적합성은 이력서나 면접만으로 판단하기 어렵고, 실제 문제에 투입해서 보는 것이 가장 정확합니다. 이 원칙을 양성 모델로 옮긴 것이 FDE 레지던시입니다.

'이름만 FDE'를 가려내는 6가지 질문

FDE라는 이름은 빠르게 유행하고 있습니다. 글로벌에서도 FDE 채용은 폭증했지만 일부는 실제로는 프로페셔널 서비스나 고객별 커스텀 개발을 FDE라고 부르는 수준이라는 비판이 있습니다. 그래서 "우리도 FDE 한다"보다 아래 질문이 먼저입니다.

• 현장에 직접 들어가는가
• 문제 정의 권한이 있는가
• 직접 만드는가
• 프로덕션까지 책임지는가
• KPI를 책임지는가
• 결과가 제품·자산에 반영되는가

여섯 개 중 두세 개뿐이면 FDE가 아닐 가능성이 높습니다. 그리고 가장 흔한 실패는 FDE라는 이름의 팀만 만들고 계약 방식, 평가 방식, 의사결정 구조, 현업과의 협업 방식은 그대로 두는 것입니다. 그러면 FDE는 기술 지원팀, 고급 SI 조직, 솔루션 엔지니어 조직 중 하나로 변합니다. FDE는 직군 하나를 추가하는 것이 아니라 조직이 제품과 업무를 만드는 방식을 바꾸는 선택입니다. Forward Deployed Engineer라는 명사보다 Forward Deployed Engineering이라는 동사가 본질입니다.

FDE 채용이 답이 아닐 수도 있다

FDE를 이야기하는 입장에서도 솔직히 말하면, 지금 필요한 것이 FDE 채용이 아닌 경우가 많습니다. 뛰어난 FDE 한 명을 데려와도 데이터 접근 권한이 없고, 현업의 핵심 담당자를 만날 수 없고, 내부 규칙 때문에 실험할 수 없고, 현장 피드백을 받아줄 곳이 없으면 세계 최고의 FDE도 성과를 내기 어렵습니다. FDE는 구현, 현업과의 관계 관리, 발견한 것을 통합하는 제품 리드가 함께 움직이는 팀 스포츠이고, 기존 프로세스를 우회하고 조직 경계를 넘을 수 있도록 위에서 보호해 주는 스폰서 — 이른바 '탑 커버' — 가 필요합니다. 우리 회사에 필요한 질문은 "FDE를 뽑을까"가 아니라 "AX 실행 역량을 누가 보유하고, 그 사람이 움직일 수 있는 조건이 있는가"입니다.