요즘 FDE라는 포지션이 눈에 들어온다.
FDE는 Forward Deployed Engineer의 약자다. 말 그대로 제품팀 안쪽에만 있는 엔지니어가 아니라, 고객이 있는 현장 쪽으로 앞으로 배치되는 엔지니어에 가깝다.
처음 들으면 세일즈 엔지니어와 비슷해 보일 수 있다. 고객을 만나고, 문제를 듣고, 기술적으로 설명하고, 데모도 만들 수 있기 때문이다. 하지만 내가 이해한 FDE의 핵심은 조금 다르다.
FDE는 단순히 제품을 설명하는 사람이 아니라, 고객의 복잡한 문제를 실제로 돌아가는 소프트웨어로 바꾸는 사람이다.
왜 지금 FDE가 다시 뜰까
FDE라는 역할은 Palantir와 강하게 연결되어 있다. Palantir는 오래전부터 고객 현장에 엔지니어를 깊게 붙여서, 데이터와 운영 문제를 실제 시스템으로 풀어내는 방식을 써왔다.
그런데 최근에는 AI 회사들에서도 이와 비슷한 역할이 중요해지고 있다.
이유는 단순하다. AI 제품은 API만 제공한다고 바로 가치가 생기지 않는다. 모델이 아무리 좋아도, 고객 입장에서는 여전히 이런 문제가 남는다.
- 우리 데이터와 어떻게 연결할 것인가
- 어떤 업무 흐름 안에 넣을 것인가
- 결과를 어떻게 검증할 것인가
- 사람이 어디에서 승인하거나 개입해야 하는가
- 보안, 권한, 감사 로그는 어떻게 처리할 것인가
- 실제 사용자가 이걸 믿고 쓸 수 있는가
결국 AI의 가치는 모델 자체보다 배포와 적용에서 갈리는 경우가 많다. 데모에서는 멋있게 보였던 기능도 실제 회사 안에 들어가면 데이터 권한, 레거시 시스템, 조직 문화, 책임 소재 같은 문제를 만나게 된다.
FDE는 바로 이 간극을 메우는 역할이다.
FDE가 실제로 하는 일
FDE의 하루는 회사마다 다르겠지만, 큰 흐름은 대략 비슷할 것 같다.
먼저 고객의 문제를 듣는다. 그런데 여기서 중요한 것은 고객이 처음 말한 요청을 그대로 믿지 않는 것이다. 고객은 보통 “대시보드가 필요하다”, “AI 챗봇을 만들고 싶다”, “업무를 자동화하고 싶다”처럼 말한다.
하지만 FDE가 파고들어야 하는 질문은 조금 다르다.
- 실제로 시간이 낭비되는 지점은 어디인가
- 누가 이 문제로 가장 고생하고 있는가
- 지금은 어떤 방식으로 우회하고 있는가
- 어떤 데이터는 믿을 수 있고, 어떤 데이터는 믿기 어려운가
- 이 시스템이 실패하면 누가 피해를 보는가
- 작게라도 성공했다고 말하려면 무엇이 바뀌어야 하는가
그다음에는 문제를 작게 잘라서 실제로 동작하는 형태로 만든다. API를 붙이고, 데이터를 정리하고, 화면을 만들고, 권한을 처리하고, 로그를 남기고, 평가 기준을 만든다. 필요하면 고객 환경 안에 직접 배포한다.
여기서 중요한 점은 “프로토타입을 만들었다”에서 끝나지 않는다는 것이다. FDE가 만드는 것은 보여주기 위한 데모가 아니라, 실제 업무에서 테스트될 수 있는 작은 시스템에 가깝다.
사례로 보면 더 쉽다
예를 들어 어떤 회사가 “사내 문서 기반 AI 챗봇”을 만들고 싶다고 해보자.
일반적인 데모라면 문서를 넣고 질문에 답하게 만들면 된다. 하지만 FDE 관점에서는 질문이 더 많아진다.
- 어떤 문서는 누구에게 보여주면 안 되는가
- 답변에 반드시 출처가 있어야 하는가
- 틀린 답변이 나오면 어떤 위험이 있는가
- 사용자는 채팅창을 열어서 질문할 만큼 이 문제가 자주 발생하는가
- 답변보다 중요한 것이 문서 승인 흐름일 수도 있지 않은가
이렇게 보면 문제는 “챗봇 만들기”가 아니라 “조직 안에서 신뢰할 수 있는 지식 접근 흐름 만들기”가 된다. 구현도 달라진다. 단순 RAG 데모가 아니라 권한 관리, 출처 표시, 피드백 수집, 평가 데이터셋, 운영 모니터링이 필요해진다.
또 다른 예로 물류 회사의 수요 예측 대시보드를 생각해볼 수 있다. 고객은 더 정확한 예측을 원한다고 말하지만, 실제 문제는 예측 정확도 자체가 아닐 수도 있다. 재고 부족 위험을 더 빨리 발견하고, 담당자가 어떤 조치를 해야 하는지 명확히 알려주는 것이 더 중요할 수 있다.
이 경우 FDE는 모델 성능만 보는 것이 아니라, 의사결정 흐름 전체를 본다. 누가 언제 보고, 어떤 기준으로 판단하고, 어떤 액션을 취하는지까지 봐야 한다.
필요한 능력
FDE에게 필요한 능력은 꽤 넓다. 그래서 이 역할이 어렵고, 동시에 흥미롭다.
첫 번째는 당연히 엔지니어링 능력이다. 코드를 잘 짜야 하고, API, 데이터베이스, 클라우드, 배포, 디버깅, 보안에 대한 감각이 있어야 한다. 고객 앞에서 만든다고 해서 대충 만들어도 되는 것은 아니다. 오히려 불확실한 환경에서 안정적으로 판단해야 한다.
두 번째는 AI와 데이터에 대한 이해다. 특히 AI 회사의 FDE라면 LLM 워크플로우, RAG, 평가, 데이터 파이프라인, 관측성, 실패 모드에 대한 감각이 필요하다. “모델이 답을 잘한다”와 “고객 업무에 넣어도 된다” 사이에는 꽤 큰 차이가 있다.
세 번째는 커뮤니케이션 능력이다. FDE는 엔지니어와만 이야기하지 않는다. 고객사의 실무자, 관리자, 임원, 보안팀, 법무팀, 내부 제품팀과 모두 대화해야 할 수 있다. 같은 문제를 상대에 맞는 언어로 번역하는 능력이 중요하다.
네 번째는 제품적 판단이다. 무엇을 만들고, 무엇을 만들지 않을지 결정해야 한다. 고객이 원한다고 다 만들어주면 커스텀 개발 지옥에 빠질 수 있다. 반대로 너무 제품 원칙만 고집하면 고객의 현실을 놓친다. 이 사이에서 균형을 잡아야 한다.
FDE에게 필요한 분석적 사고
내가 보기에 FDE의 핵심은 분석적 사고다. 여기서 분석적 사고란 숫자를 잘 다루는 것만을 말하지 않는다. 모호한 상황에서 문제의 구조를 잡는 능력에 가깝다.
좋은 FDE는 고객의 요청을 그대로 작업 목록으로 바꾸지 않는다. 먼저 문제를 다시 정의한다.
“챗봇을 만들어주세요”라는 요청을 받으면 이렇게 생각해야 한다.
- 정말 챗봇이 필요한가
- 검색이 더 나은가
- 워크플로우 자동화가 더 나은가
- 사람이 승인해야 하는 단계는 어디인가
- 틀렸을 때 비용이 큰 답변과 작은 답변은 무엇인가
- 성공 여부를 어떻게 측정할 것인가
즉, FDE는 기술을 바로 적용하는 사람이 아니라, 기술이 들어갈 수 있는 문제의 모양을 찾는 사람이다.
이 점에서 FDE는 AI 시대에 더 중요해질 가능성이 있다. AI로 코드를 더 빨리 만들 수 있게 되면, 단순 구현의 희소성은 줄어든다. 대신 무엇을 구현해야 하는지, 어떤 순서로 검증해야 하는지, 어디까지 자동화하고 어디에 사람을 남겨야 하는지를 판단하는 능력이 더 중요해진다.
내가 생각하는 FDE의 정의
지금 기준으로 내가 정리한 FDE의 정의는 이렇다.
FDE는 고객의 모호한 문제를 실제로 배포 가능한 소프트웨어 결과물로 바꾸고, 그 과정에서 얻은 현장의 학습을 다시 제품 방향으로 연결하는 엔지니어다.
그래서 FDE는 단순히 코딩을 잘하는 사람도 아니고, 말을 잘하는 세일즈 역할도 아니다. 고객의 현실을 이해하고, 기술적으로 구현하고, 제품적으로 판단하고, 다시 학습을 구조화하는 사람이다.
이 역할이 흥미로운 이유도 여기에 있다. AI 시대에는 더 많은 회사가 “우리가 진짜 원하는 업무 흐름은 무엇인가”를 다시 묻게 될 것이다. 그리고 그 질문에 답하려면, 기술과 현장 사이를 오갈 수 있는 사람이 필요하다.
FDE는 바로 그 경계에 있는 역할처럼 보인다.