FDE(Forward Deployed Engineer), 요즘 채용공고에 보이는 이 직군은 뭘까
채용 사이트를 보다가 처음 보는 직함을 만났습니다.
FDE(Forward Deployed Engineer).
번역하면 "전진 배치 엔지니어"입니다. 처음엔 무슨 군사 용어인가 싶었습니다. 찾아보니 팔란티어(Palantir)에서 시작된 직군이고, 최근 국내 AI·데이터 회사들도 이 이름으로 사람을 뽑기 시작했더군요.
공고를 읽어 내려가다가 한 줄에서 멈췄습니다.
"고객의 문제를 정의하고, 실현 가능한 솔루션을 기획·제안·실행합니다."
제가 15년간 해온 일이 그거였습니다. 회사를 옮길 때마다 뭔가 문제가 터진 곳에 들어가서, 원인을 파악하고, 시스템을 만들고 나왔거든요. 그런데 그동안 제 직함은 개발자였다가 팀장이었다가 PM이었습니다. 하는 일에 이름이 없었던 셈입니다.
이 직군을 알아보면서 정리한 내용을 공유합니다. 저처럼 "이게 뭐지?" 하고 검색하다 들어오신 분께 도움이 되면 좋겠습니다.
1. FDE가 뭔가 — 한 문장으로
고객사에 직접 들어가서 문제를 정의하고, 만들고, 넘겨주고 나오는 엔지니어입니다.
자문만 하는 것도 아니고, 시키는 대로 만드는 것도 아닙니다. 둘 다 합니다. 그게 핵심입니다.
팔란티어가 이 직군을 만든 이유가 거기 있습니다. 정부기관이나 대기업에 소프트웨어를 팔았는데, 고객이 그걸 자기 문제에 어떻게 써야 할지 모릅니다. 그렇다고 요구사항을 받아서 만들자니 고객이 요구사항을 정의할 줄 모릅니다. 그래서 엔지니어를 고객사에 보냈습니다. 가서 직접 보고, 직접 정의하고, 직접 만들라고요.
"Forward Deployed"라는 말이 여기서 나옵니다. 본사에 앉아서 티켓을 받는 게 아니라, 고객이 있는 최전선에 나가 있는다는 뜻입니다.
2. SI·컨설팅과 뭐가 다른가
이 질문이 제일 많이 나옵니다. 표로 정리하면 이렇습니다.
| 하는 일 | 끝나는 지점 | 구조적 한계 | |
|---|---|---|---|
| 컨설팅펌 | 진단하고 전략 보고서를 준다 | 보고서 제출 | 고객이 실행을 못 함 |
| SI | 요구사항을 받아서 구축한다 | 납품·검수 | 요구사항이 있어야 시작 가능 |
| 솔루션 회사 | 제품을 팔고 도입을 지원한다 | 도입 완료 | 제품에 고객을 맞춰야 함 |
| FDE | 진단부터 구축·인계까지 | 고객이 스스로 굴릴 수 있을 때 | 사람 수가 곧 매출 한계 |
한 줄로 줄이면 이렇습니다.
컨설팅펌은 만들지 않고
SI는 정의하지 않고
솔루션 회사는 제품에 고객을 맞춘다
FDE는 정의하고, 만들고, 넘긴다
"그러면 SI 개발자랑 뭐가 달라요?"
이 직군을 알아보는 사람이면 누구나 드는 의문입니다. 저도 그랬고요. 실제로 국내 채용 시장에서는 이름만 FDE이고 내용은 기존 SI인 공고도 섞여 있습니다.
구분하는 방법은 공고 문장을 보는 겁니다.
| 진짜 FDE에 가까운 문장 | 이름만 FDE일 가능성 |
|---|---|
| "고객의 문제를 정의하고" | "요구사항에 따라 개발" |
| "ROI/TCO 관점에서 올바른 선택을 설계" | "설계서 기반 구현" |
| "업무 환경과 일하는 위치를 스스로 정의" | "고객사 상주 필수" |
| "고객이 스스로 운영할 수 있도록 인계" | "유지보수 지원" |
핵심은 "정의"라는 단어가 있느냐입니다. 무엇을 만들지 정하는 권한이 없으면 FDE가 아니라 파견 개발자입니다.
3. FDE에게 요구되는 것
여러 회사 공고를 모아 보면 공통점이 뚜렷합니다.
필수 역량
| 왜 필요한가 | |
|---|---|
| 개발 실무 3년 이상 | 백엔드·데이터 엔지니어링·BI 구축 중 하나. 직접 만들 수 있어야 함 |
| SQL과 DB 이해 | 거의 모든 FDE 공고에 나옵니다. 고객 데이터를 직접 뜯어봐야 하니까요 |
| 고객 대면 | "직접적인 커뮤니케이션에 부담을 느끼지 않는 분" — 업무의 절반이 사람 상대 |
| AI 도구 활용 | 코딩 에이전트로 혼자 여러 일을 처리하는 것이 전제 |
우대 사항에서 읽히는 것
- ERP, CRM, BI, 클라우드, 인프라에서 문제를 정의하고 해결한 경험
- 엑셀이나 SaaS로라도 실제 업무 변화를 만들어본 경험
마지막 줄이 재미있습니다. 거창한 시스템이 아니라 엑셀로라도 업무를 바꿔봤느냐를 봅니다. FDE가 뭘 하는 자리인지 이 한 줄에 다 들어 있습니다. 기술 스택이 아니라 변화를 만들어본 경험을 보는 겁니다.
4. 왜 지금 이 직군이 생겼을까
FDE는 팔란티어에서 10년 넘게 있던 개념인데, 국내에서 갑자기 늘어난 건 최근입니다. 이유가 두 가지라고 봅니다.
① AI 에이전트가 구현을 대신하기 시작했다
예전에는 "만드는 것" 자체가 병목이었습니다. 요구사항이 정해지면 그걸 구현하는 데 몇 달이 걸렸으니까요.
지금은 다릅니다. 저도 지난 몇 달 AI 코딩 에이전트로 서비스를 여러 개 만들어 보면서 체감했는데, 구현 속도가 문제가 아니게 됐습니다. 그러면 병목이 앞으로 옮겨갑니다.
예전 병목: 요구사항 → [구현] → 배포
지금 병목: [무엇을 만들까] → 구현 → 배포
무엇을 만들지 정하는 사람, 그게 되면 끝인지 판단하는 사람이 더 중요해집니다. FDE가 그 자리입니다.
② 중소·중견기업이 AI를 도입하려는데 방법을 모른다
대기업은 내부에 전략팀도 있고 IT 조직도 있습니다. 컨설팅펌에 맡기면 보고서가 나오고, SI에 발주하면 구축이 됩니다.
중소·중견기업은 그게 안 됩니다.
- "AI 도입하고 싶다"는 있는데 무엇을 만들지 정의를 못 합니다
- 요구사항이 없으니 개발사도 견적을 못 냅니다
- 만들어 줘도 이게 잘된 건지 판단을 못 합니다
이 빈 자리를 메우려고 만들어진 직군이 FDE입니다. 진단부터 구축, 그리고 고객이 직접 운영할 수 있게 넘기는 것까지 한 사람이 가는 구조입니다.
5. 이 직군이 맞는 사람
여러 공고와 사례를 정리하면서 세운 기준입니다.
맞을 가능성이 높은 사람
- 도메인이 여러 번 바뀐 경력. 보통은 "일관성이 없다"고 읽히는데, FDE는 고객사가 매번 바뀌니 그게 오히려 요건이 됩니다
- 개발도 하고 기획도 해본 사람. 공수를 직접 판단할 수 있어야 "이건 2주, 저건 2개월"을 그 자리에서 말할 수 있습니다
- 데이터부터 뜯어보는 습관. 대시보드보다 원본 데이터를 먼저 보는 쪽
- "만들어 놨는데 안 쓰더라"를 겪어본 사람. 이 경험이 있으면 접근 방식이 달라집니다
안 맞을 가능성이 높은 사람
- 한 기술을 깊게 파고 싶은 사람. FDE는 넓게 씁니다. 깊이는 도메인마다 필요한 만큼만
- 고객 대면이 부담스러운 사람. 인터뷰하고 설득하는 게 업무의 절반입니다
- 완성도를 끝까지 올리고 싶은 사람. 여기서는 "언제 멈출지"가 더 중요합니다
6. FDE 공고를 볼 때 확인할 것 다섯 가지
이름이 같아도 내용이 다른 경우가 많아서, 저는 이 다섯 개를 봅니다.
① 문제 정의가 업무에 있는가
"고객의 문제를 정의하고"가 있으면 진짜에 가깝습니다. 없고 구현 이야기만 있으면 SI입니다.
② 상주 방식이 어떻게 되는가
고객사에 책상 받고 몇 달 앉아 있는 구조인지, 인터뷰하고 내부에서 만들고 다시 방문하는 구조인지. 전자면 파견에 가깝습니다. 면접에서 반드시 물어야 할 항목입니다.
③ 진단은 누가 하는가
회사에 따라 컨설턴트나 별도 조직이 앞단을 맡기도 합니다. 그 경우 FDE는 받아서 만드는 쪽이 될 수 있습니다. 진단 단계에 FDE가 참여하는지를 확인하세요.
④ 프로젝트가 끝나면 무엇이 남는가
FDE 한 명이 프로젝트 하나를 끝내는 구조면, 사람 수가 곧 매출 한계입니다. 그래서 다음 고객에게 다시 쓸 수 있는 자산을 어떻게 쌓는지가 그 회사의 수준을 보여줍니다.
⑤ 보상과 성장 경로
연차가 아니라 역량으로 보상이 정해지는지, 그리고 위로 갈 자리가 있는지. FDE로 시작해서 어디까지 갈 수 있는 구조인지 물어보면 회사가 이 직군을 진지하게 보는지 알 수 있습니다.
7. 개인적으로 인상 깊었던 것
이 직군을 알아보면서 가장 크게 남은 문장이 있습니다.
만들어 놨는데 안 쓰면 다 부질없습니다.
저도 겪어 봤습니다. 현장에 좋은 시스템을 만들어 줬는데 아무도 안 씁니다. 20년 된 프로그램을 계속 쓰면서요. 이유는 단순합니다. 편하니까. 바꾸는 비용을 현장이 떠안기 때문입니다.
그래서 저는 현장에 들어갈 때 쓰던 걸 그대로 두는 방식을 씁니다. 화면을 바꾸라고 하면 저항하지만, 안 바꿔도 된다고 하면 저항할 이유가 없어집니다. 데이터만 뒤에서 가져와서 묶고, 그게 쌓인 다음에 구조를 설계합니다. 시스템은 마지막에 나옵니다.
AI 에이전트가 코드를 써 주는 시대에 남는 일이 이런 거라고 생각합니다. 무엇을 만들지 정하고, 그게 실제로 쓰이게 만드는 것. FDE라는 직군이 지금 생겨난 이유도 거기 있다고 봅니다.
8. 정리 — FDE 한눈에 보기
| 한 줄 정의 | 고객사에 들어가 문제를 정의하고, 만들고, 넘겨주고 나오는 엔지니어 |
| 출발점 | 팔란티어. 최근 국내 AI·데이터 회사들이 도입 중 |
| SI와 차이 | SI는 요구사항을 받아서 만들고, FDE는 요구사항을 정의하는 것부터 한다 |
| 컨설팅과 차이 | 컨설팅은 보고서에서 끝나고, FDE는 만들어서 돌아가게 한다 |
| 요구 역량 | 개발 실무 3년 + SQL/DB + 고객 대면 + AI 도구 활용 |
| 핵심 태도 | "무엇을 만들까"보다 **"무엇이 되면 끝인가"**를 먼저 정한다 |
| 가장 흔한 실패 | 만들었는데 현장이 안 쓰는 것 |
| 공고 볼 때 | "문제를 정의하고"가 있는지 · 상주 방식 · 진단 참여 여부 |
혹시 이 직군을 알아보고 계신다면, 공고의 기술 스택보다 "고객의 문제를 정의하고" 같은 문장이 있는지를 먼저 보세요. 그게 없고 구축 이야기만 있으면, 이름만 FDE일 가능성이 있습니다.
그리고 도메인을 여러 번 갈아타서 "경력이 일관성 없다"는 소리를 들어 오셨다면, 이 직군에서는 그게 강점이 됩니다. 저도 그래서 관심이 생겼습니다.
backtodev
A 40-something PM returns to code. Learning, failing, and growing.