AI/LLM 도입 프로젝트를 가까이에서 보다 보면, 모델을 고르는 것보다 “현장에 안전하게 붙여서 실제로 돌아가게 만드는 일”이 훨씬 어렵다는 걸 체감합니다. 이 글에서는 그 라스트마일을 맡는 Forward Deployed Engineer(FDE) 역할이 왜 뜨는지, 시장 수요/보상은 어떤 흐름인지, 그리고 Bigdata ML/DL, LLM 플랫폼 스타트업의 “현업 FDE”로 3여년간 발로 뛰며 일했던 경험을 바탕으로 느낀 조직 설계 인사이트를 정리합니다.
FDE란 무엇인가: 엔지니어 + 컨설턴트, 그리고 ‘임베딩(embedding)’의 의미
Pave는 FDE를 고객 현장에 밀착해 커스텀 구현·통합을 수행하는 엔지니어-컨설턴트 하이브리드 로 정의합니다. 제품을 “설명”하는 사람이 아니라, 고객의 환경에서 실제로 “되게 만드는” 사람에 가깝습니다.
Pragmatic Engineer도 비슷한 관점을 취합니다. FDE는 고객팀과 제품팀을 오가며 다음을 동시에 수행합니다.
- SW 엔지니어링(구현/통합/배포)
- 세일즈/고객 성공(문제 정의, 가치 증명, 채택 가속)
- 플랫폼/제품 피드백(범용 기능으로 승격 가능한 패턴 발굴)
이게 솔루션 아키텍트(Solutions Architect)나 Sales Engineer(SE)와 닮아 보이지만, FDE는 보통 코어 제품에 준하는 엔지니어링 기대치(실제 구현 소유, 프로덕션 책임) 가 더 큽니다. 다만 회사마다 역할 정의는 크게 다르다는 점이 핵심입니다.
왜 지금 FDE가 각광받나: “모델”이 아니라 “구현”이 경쟁력이 되는 시기
Emergence Capital의 주장 중 제일 와닿았던 문장은 요약하면 이렇습니다.
경쟁우위는 “어떤 모델을 쓰느냐”보다 “안전하고 신뢰 가능하게 구현하느냐”에서 나온다.
AI/LLM은 데모는 쉽지만, 현장에 들어가면 곧바로 복잡해집니다.
- 데이터는 제각각이고(권한/마스킹/품질/스키마)
- 워크플로우는 SOP대로 안 돌아가고
- 툴/시스템은 유기적으로 얽혀 있으며
- 무엇보다 “신뢰”를 잃는 순간 도입이 멈춥니다(환각, 감사 추적, 책임소재 문제)
Emergence Capital은 여기서 FDE가 하는 핵심을 “워크플로우 발견 → 툴 통합 → 신뢰 구축”으로 봅니다. SOP 문서가 아니라 실제 프로세스를 관찰하고, 그것을 코드로 ‘라벨링’해서 시스템이 신뢰할 수 있는 형태로 만드는 일이 라스트마일 병목을 푼다는 관점입니다.
시장 수요 동향: 채용 공고는 폭증, 그러나 아직 ‘소수 역할’
수요는 확실히 늘고 있습니다.
- Pave: 2023~2025년 사이 FDE 채용이 증가 추세
- Betts: 2024~2025년 FDE 공고가 200%+ 증가
그런데 동시에 Pave 데이터(2025년 9월 기준)에서는 FDE 보유 기업이 1.24% 로 나타납니다. 즉 “많이 필요해졌지만, 아직 대부분의 회사는 역할을 정식으로 제도화하지 못한 상태”에 가깝습니다.
제가 현장에서 느낀 체감도 비슷합니다. 회사에 “FDE 포지션”이 없어도, 실제로는 누군가가 FDE처럼 움직입니다. 이를테면 현업 담당자가 엔지니어링과 운영 사이에서 라스트마일을 메우는 ‘현업 FDE’ 가 생기는 구조입니다.
이 구조는 단기적으로 강력하지만, 장기적으로는 병목과 소진이 생기기 쉽습니다(뒤에서 다시 다루겠습니다).
보상(Compensation) 동향: 평균은 ‘생각보다 낮고’, 상위 티어가 ‘기준을 끌어올림’
보상은 출처/표본에 따라 인식이 크게 갈립니다. 요지는 “평균”과 “상위 티어”를 분리해서 봐야 한다는 점입니다.
- Pave: FDE 보상은 일반 SWE 대비 −9.2% 낮음, 대신 TAM/지원 엔지니어 대비는 높음
→ 조직에서 FDE를 “코어 SWE”가 아니라 “현장 구현/지원 성격”으로 분류하는 회사가 많다는 신호로도 읽힙니다. - Betts: 평균 연봉은 대략 $115k~$130k 범위로 제시(지역, 경력, 도메인, 회사 단계에 따라 편차 큼)
→ 특히 대기업(대표적으로 Palantir)의 고연봉/고변동 보상이 시장 인식을 끌어올린다고 분석합니다. - Palantir JD(Forward Deployed Software Engineer): 뉴욕 기준 기본급 $135k~$200k (주식/사인온 등 추가 가능), 최대 25% 출장 요구
→ “엔드투엔드 구현을 소유”하는 만큼 기대치와 보상 상단도 높게 형성된 사례입니다.
정리하면, FDE는 분명히 뜨는 역할이지만, 모든 회사가 그 가치를 SWE급으로 가격 매기지는 않는다는 게 현실입니다. 그래서 개인 입장에서는 “내가 하는 일이 FDE인데 보상/평가 프레임이 지원 조직에 묶여 있다” 같은 미스매치가 생기기 쉽습니다.
(현업 경험) FDE의 본질은 ‘혼돈’인데, 사람을 지키는 최소 경계가 없으면 갈립니다
최전선으로 출동하기 전에 항상 들던 생각입니다.
FDE의 본질은 혼돈이고, 표준이 없는 곳에 표준을 만들러 가는 사람이다. 그런데 정작 본인을 보호해주는 표준은 없다.
실제로 “현업 FDE”로 일할 때 시간이 어디에 쓰이느냐를 나눠보면, 지극히 개인적인 경험으로 대략 이렇게 흘러가곤 했습니다.
- 요구 수집/조율 50%
- 실제 구현 20% (어느정도의 변동은 있음)
- 운영/신뢰(모니터링·가드레일·권한·감사) 30%
여기서 소진을 만드는 핵심은 기술의 다양성 자체라기보다, 대화에서 드러난 두 가지였습니다.
- 끝없이 바뀌는 요구와 데드라인
- 장애 운영 책임의 전가
둘 다 결국 “변경 비용이 0인 구조”, “책임이 가장 가까운 사람에게 떨어지는 구조”에서 폭발합니다.
“표준화 vs 유연성”은 대립이 아니라, ‘무엇을 표준화할지’의 경계 문제입니다
현장은 제각각이니 기술/환경을 통째로 표준화하기 어렵습니다. 하지만 저는 오히려 이런 곳일수록 ‘혼돈을 다루는 방식의 표준(메타-표준)’ 이 필요하다고 봅니다. 유연성을 죽이지 않으면서도 사람을 지키는 장치입니다.
예를 들면 아래 두 축이 특히 효과가 큽니다.
1) 변경 통제: “바뀔 수는 있는데, 공짜는 아니다”
- 스코프 변경 시 일정/범위/품질 중 무엇을 희생하는지 명시
- 변경 요청은 트리아지 후 다음 배포로 이월하는 원칙
- Acceptance criteria를 최소 단위로 고정
2) 운영 책임: “권한·런북·모니터링 없는 운영은 금지”
- 운영 소유권/온콜/롤백 권한이 없는 팀은 운영 책임을 질 수 없음
- 최소한의 런북/알람/대시보드 없이는 프로덕션 반영 불가
간단히 말해, FDE의 본질이 혼돈이라면 조직이 해야 할 일은 “혼돈 제거”가 아니라 혼돈의 비용을 공정하게 배분하고, 책임을 시스템으로 고정하는 것입니다.
우리 조직은 FDE를 어디에 붙여야 할까: 고객 성공/세일즈 vs 코어 제품 엔지니어링
원본 자료의 열린 질문이 아주 중요합니다.
FDE 역할을 “고객 성공/세일즈 지원”과 “코어 제품 엔지니어링” 중 어디에 더 무게를 두고 설계해야 성과가 나는가?
정답은 회사 상황마다 다르지만, 저는 판단 기준을 “무엇이 병목인가”로 두는 편이 낫다고 봅니다.
- 도입/채택이 병목이면: 고객 성공/세일즈에 가까운 FDE(문제정의, 빠른 PoC, 현장 설득)가 효과적
- 안정성/신뢰/운영이 병목이면: 코어 제품/플랫폼에 가까운 FDE(가드레일, 관측성, 권한/감사, 배포 표준)가 효과적
특히 AI/LLM은 “한 번 사고 나면 도입 자체가 멈추는” 특성이 강해서, 저는 많은 조직에서 운영/신뢰를 누가 소유하느냐가 결국 성패를 가른다고 봅니다.
마무리: FDE는 ‘AI의 골드러시’를 실제 매출로 바꾸는 라스트마일 역할입니다
FDE 채용은 늘고 있지만(공고 200%+ 증가), 아직 제도화한 회사는 소수이고(1.24%), 보상도 “평균 vs 상위 티어”의 간극이 큽니다. 무엇보다 FDE의 본질은 다양한 현장의 혼돈을 다루는 일이기 때문에, 기술 표준만큼이나 변경 통제와 운영 책임의 최소 경계가 없으면 사람이 먼저 소진됩니다.
정식 FDE가 없더라도, 이미 조직 어딘가에서 “나도 모르게 전향되어진 현업 FDE”가 태워지고 있을 수 있습니다. 그 역할을 지속 가능하게 만들 장치를 지금부터라도 설계해보면 좋겠습니다.