떠오르는 AI 직무 FDE란 무엇인가? 일반인도 도전할 수 있을까?

지난 2년간 AI 업계에서 가장 인기 있는 인재는 모델을 학습시키는 사람과 AI 제품을 만드는 사람이었다.

2026년에 이르러 또 하나의 포지션이 갑자기 급부상했다: FDE.

정식 이름은 Forward Deployed Engineer다. 솔직히 이름만 들어서는 무엇을 하는 사람인지 모르는 경우가 많다.

몇 가지 숫자를 먼저 보자.

• LinkedIn 보고서에 따르면 FDE 관련 포지션은 2023년부터 2025년까지 42배 증가했다.
• OpenAI는 2026년 5월 Deployment Company를 설립하며 초기 투자 40억 달러 이상을 투입했고, 인수를 통해 배포 엔지니어와 전문가 약 150명을 영입했다.
• 이어서 AWS는 10억 달러를 투자해 수천 명의 엔지니어를 고객 팀에 파견했다.

빅테크가 이들을 급히 영입하려는 것은 바람이 바뀌었음을 보여준다. 모델 리더보드에서 0.1점 차이는 고객이 체감하지 못할 수 있다. 하지만 레거시 시스템에 통합되고 워크플로에서 작동하며 실제로 비용을 절감해주는 AI 시스템이라면 고객이 계속 비용을 지불할 의사가 있다.

AI 업계는 '모델 비교'에서 '구현 능력 비교'로 넘어갔다.

여러분이 AI 전환을 준비 중이거나 다음 커리어 방향을 찾고 있다면, 이 글에서 세 가지를 명확히 알 수 있다: FDE가 무엇인지, 그들이 실제로 무엇을 하는지, 코딩 배경이 없는 사람이 단계적으로 어떻게 전환할 수 있는지.

1. FDE란 정확히 무엇인가?

나는 이렇게 설명하는 편이 좋다고 생각한다.

FDE란 고객의 실제 업무 현장에 들어가 AI를 데모 단계에서 실제 운영 환경(프로덕션)까지 끌어올리는 사람이다.

고객이 "AI 고객센터를 만들고 싶다"고 말한다고 가정해 보자. 일반적인 요구사항 목록은 기능 구현부터 시작하겠지만, FDE는 더 깊이 파고들어야 한다.

• 지금 고객센터가 하루에 처리하는 티켓이 몇 건인지
• AI가 어떤 질문에 답할 수 있는지
• 어떤 답변은 사람이 확인해야 하는지
• 고객 데이터가 어디에 저장되어 있는지
• AI가 틀렸을 때 답변을 어떻게 철회할지
• 출시 후 응답 속도, 해결률, 인건비 중 무엇을 추적할지

이 질문들이 명확해진 후에야 코딩이 시작된다. 시스템을 만든다고 작업이 끝나는 것은 아니다. 데이터 연결, 권한 설정, 평가, 프로덕션 배포, 사용량 모니터링, 현장에서 마주친 문제점을 제품 팀에 전달하는 일까지 해야 한다.

전체 작업 흐름은 여섯 단계로 압축할 수 있다.

1문제 발견
2→ 프로세스 분석
3→ 솔루션 설계
4→ 시스템 구축
5→ 프로덕션 배포
6→ 결과 모니터링

요구사항은 시작점일 뿐, 결과가 인도물이다.

그래서 FDE는 보통 세 가지를 동시에 처리해야 한다.

코드를 쓸 줄 아는 사람은 많지만, 고객 현장에 가서 어수선한 상태를 출시 가능한 수준으로 정리하려는 사람은 훨씬 드물다. 그래서 FDE를 채용하기 어렵고 몸값도 점점 올라간다.

2. FDE는 하루 종일 무엇을 할까?

한 유통 체인이 AI 업체를 찾아와 "스마트 재고 보충 에이전트"를 원한다고 말한다고 가정해 보자. 듣기에는 명확해 보이지만, FDE가 현장에 도착하면 질문이 쏟아진다.

• 어떤 매장이 가장 자주 품절되는지
• 재고 보충이 판매량, 날씨, 휴일, 프로모션 계획 중 무엇을 반영하는지
• 에이전트가 추천만 제공하는지, 아니면 직접 구매 주문서를 생성하는지
• 특정 금액을 초과하면 수동 승인이 필요한지
• 재고 업데이트는 하루 한 번이면 충분한지
• 추천이 틀렸을 때 재고 부족과 손실은 누가 처리하는지

첫 주에는 코드를 한 줄도 안 쓸 수도 있다. 먼저 매장 관리자에게 지금 어떻게 재고를 보충하는지 듣고, 공급망 담당자와 규칙을 확인하고, IT와 인터페이스를 점검하고, 보안 부서와 권한을 논의한다. 프로세스가 명확해지면 엔지니어링 단계에 들어간다.

• 재고, 판매, 주문 시스템을 연결하고
• 과거 데이터를 정리하고
• 모델 호출과 에이전트 워크플로를 작성하고
• 직원들이 기꺼이 열어볼 페이지를 만들고
• 로그인, 권한, 로그, 모니터링을 추가하고
• 테스트 데이터를 준비하고
• 수동 검토와 장애 대비 대체 경로를 구축한다

출시 후에도 모니터링을 계속해야 한다. 매장이 실제로 쓰는지, 추천 채택률은 어떤지, 품절률이 줄었는지, 직원들이 몰래 엑셀로 돌아가고 있다면 그 이유는 무엇인지까지 모두 FDE의 몫이다.

사용률이 너무 낮은데 "사용자가 사용법을 모른다"고 하고 그냥 떠나면 프로젝트는 실패할 가능성이 높다. 페이지든 프로세스든 모델 출력이든 사람들이 불편해하는 부분이 있으면 다시 돌아가 고쳐야 한다.

FDE가 전달하는 것은 이미 실제로 돌아가는 비즈니스 프로세스다. 예쁜 데모를 만드는 것은 산을 반쯤 오른 것에 불과하다.

3. FDE와 프로그래머, PM, 프리세일즈의 차이는 무엇인가?

이 역할들은 함께 일하는 경우가 많고 경계도 겹친다. 각자 무엇에 책임을 지는지 보는 것이 가장 간단한 구분법이다.

FDE의 경계는 더 넓다. 오전에는 고객과 비즈니스 미팅, 오후에는 데이터베이스 확인, 저녁에는 인터페이스 수정이 같은 날 일어날 수 있다.

하지만 오해하면 안 된다. FDE의 E는 여전히 Engineer(엔지니어)다.

OpenAI의 현재 FDE 채용 공고는 지원자가 프로덕션 수준의 프론트엔드와 백엔드 코드를 작성하고 검토할 수 있어야 한다고 명시한다. Palantir의 주니어 포지션도 최소 하나의 프로그래밍 언어에 능숙할 것을 요구한다. 따라서 컴퓨터 공학 배경이 없어도 전환할 수는 있지만, 코딩을 완전히 건너뛰는 것은 불가능하다.

비즈니스와 고객을 더 좋아하고 장기적으로 프로덕션 코드를 쓰고 싶지 않다면, Deployment Strategist, AI Product Manager, Industry Solution Consultant, Customer Success, AI Consulting 같은 역할을 살펴볼 수 있다. 이 역할들도 AI 구현 체인 안에 있지만 엔지니어링 책임은 더 가볍다.

4. 왜 지금 FDE가 주목받을까?

이유는 간단하다. AI가 강력해질수록 구현 문제가 더 두드러지기 때문이다.

데모는 하루면 만들지만, 프로덕션은 그렇게 호락호락하지 않다

모델 API를 연결하고 문서를 몇 개 넣고 채팅 페이지를 만들면 하루 만에 상사를 감동시킬 수 있다. 하지만 출시를 준비하는 순간 더러운 데이터, 지저분한 권한, 레거시 시스템의 인터페이스 부재, 모델 출력 변동, 보안 감사, 직원들의 사용 습관 문제가 한꺼번에 드러난다.

모델 업그레이드는 현장의 혼란을 해결해주지 않는다. 기업은 비즈니스 속으로 들어가 이런 문제들을 하나씩 처리할 사람이 필요하다.

에이전트가 실제로 '행동'하기 시작했다

챗봇이 질문에 잘못 답하면 사용자가 그 답변을 채택하지 않으면 된다. 하지만 에이전트가 이메일을 보내고, 주문을 수정하고, 결재를 상신할 수 있다면 오류가 곧바로 비즈니스에 영향을 준다.

신원 확인, 권한, 평가, 로그, 수동 검토, 예외 복구가 모두 필수적이다. 회사마다 시스템이 다르기 때문에 이 작업을 획일적인 매뉴얼로 완수하기 어렵다.

AI 기업은 고객이 제품을 쓰게 만들어야 한다

계약을 맺는 것은 문턱을 넘은 것에 불과하다. 모델이 핵심 프로세스에 들어간 후에야 사용량 증가, 갱신, 부서 확장이 일어난다.

FDE는 고객의 성과에 가장 가까운 위치에 있고, AI 기업의 매출에도 가장 가까운 곳에 있다. 이것이 OpenAI와 AWS가 과감하게 투자하는 상업적 이유다.

AI 프로그래밍은 제너럴리스트의 생산성을 극대화한다

예전에는 기업용 애플리케이션을 만들려면 제품, 프론트엔드, 백엔드, 데이터, 운영(O&M) 팀이 준비될 때까지 기다려야 했다. 이제 엔지니어링 역량을 갖춘 제너럴리스트는 AI 프로그래밍을 활용해 프로토타입 구축, 통합, 테스트, 수정을 훨씬 빠르게 완료할 수 있다.

몇 명의 인원이 고객 팀에 들어가 몇 주 만에 첫 버전을 만들고 실제 피드백을 바탕으로 빠르게 반복할 수 있다. 이제 계산이 마침내 성립한다.

이전 단계는 누구의 모델이 더 강력한지가 관건이었다면, 지금은 누가 모델을 비즈니스에 맞게 녹여낼 수 있는지가 관건이다. FDE는 바로 그 틈새에 서 있다.

5. 일반인에게 기회는 어디에 있는가?

"결국 시니어 프로그래머를 위한 것이 아니냐"고 생각할 수 있다.

시니어 엔지니어에게 유리한 점이 분명히 있지만, FDE 역량은 여러 경로에서 만들어진다. 일반인이라고 해서 처음부터 다시 시작할 필요는 없다. 이미 가진 것을 살펴보고 부족한 절반을 채우면 된다.

소프트웨어 엔지니어: 가장 가까운 위치

여러분은 이미 프로덕션 코드를 작성하는 법과 시스템이 왜 죽는지 알고 있다. 이제 사용자 인터뷰, 비즈니스 프로세스, 요구사항 범위, ROI, 채택률에 집중하자.

가장 직접적인 연습 방법은 고객 미팅, 프리세일즈 지원, 내부 AI 구현 프로젝트에 적극적으로 참여하는 것이다. 다른 사람이 요구사항을 Jira 태스크로 쪼개 주기를 기다리지 말라.

데이터 분석가: 전환에 매우 적합

데이터 분석가는 보통 SQL을 알고, 지표를 이해하며, 비즈니스 부서와 소통하는 데 익숙하다. 부족한 부분은 주로 엔지니어링이다.

• 노트북을 서비스로 전환하는 법
• API를 연결하는 법
• 로그인과 권한을 처리하는 법
• 배포와 모니터링을 하는 법
• 오류 발생 후 복구하는 법

당신만 실행할 수 있는 분석을 동료들이 매일 열어볼 수 있는 도구로 바꾸는 것은 FDE로 가는 큰 한 걸음이다.

제품, 컨설팅, 업계 운영 직군: 업계 경험은 가치가 있다

제조업에서 일했다면 일정 관리와 수율을 알고, 금융에서 일했다면 감사와 규정 준수를 알며, 유통에서 일했다면 재고와 매장 운영을 안다. 이런 경험은 몇 개 강의로 얻을 수 있는 것이 아니다.

프로그래밍, 데이터베이스, API, 배포를 보완하고 실제 동작하는 시스템을 직접 만들어봐야 한다. 전환 가능한 역할은 다음과 같다.

• Deployment Strategist
• AI Product Manager
• AI Solution Consultant
• Solutions Engineer
• Technical Implementation

일단 AI 구현 현장에 들어간 다음, 엔지니어링 책임을 점차 늘려가는 방식이다.

프리세일즈, 구현, 솔루션 아키텍트: 이미 절반은 와 있을지도 모른다

여러분은 고객에 익숙하고, 기업 환경에서 권한, 조달, 레거시 시스템이 얼마나 골치 아픈지 알고 있다. 이제 코딩이라는 허들을 넘어 데모 제작과 제품 설정에서 개발, 테스트, 배포, 유지보수로 옮겨가면 된다.

이 경로는 보통 완전한 전직보다는 짧다.

완전한 초보자: 먼저 하나의 단단한 기술을 연습하라

기술 경험도 업계 경력도 없다면 FDE에 바로 뛰어드는 것은 매우 어렵다. 데이터 분석, AI 운영, 기술 지원, 구현 컨설팅, 주니어 개발, 업계 솔루션 어시스턴트 같은 역할부터 시작할 수 있다.

FDE는 커리어의 첫 정거장인 경우가 드물다. 여러 경험 경로가 결국 수렴하는 지점에 가깝다.

6. 일반인을 위한 6개월 로드맵

채용 공고를 읽고 나서 가장 쉬운 행동은 강의를 북마크에 저장하는 것이다. 6개월 후 북마크는 가득 차 있지만, 이력서는 여전히 비어 있다.

6개월이면 FDE 포트폴리오를 만들 수 있다. 합격 여부는 기존 경험과 엔지니어링 수준, 목표 회사의 요구에 달려 있다.

1~2개월차: 엔지니어링 기초 다지기

가장 많이 쓰이는 것부터 배우자.

• Python 또는 TypeScript
• SQL과 데이터베이스
• HTTP, JSON, API
• Git
• 오류 처리와 테스팅
• Docker와 기본 배포

이 단계의 통과 기준은 단 하나다. 다른 사람이 배포 후 열어서 쓸 수 있는, 데이터베이스와 API가 포함된 작은 애플리케이션을 독립적으로 만드는 것.

입력, 처리, 저장, 오류 보고, 배포가 동작하게 만들어라. 프레임워크가 최신인지는 지금 중요하지 않다.

3~4개월차: 완성된 AI 애플리케이션 만들기

첫 버전에 모델 API, RAG, Tool Calling, 구조화된 출력, 로그, Evals, 실패 시 재시도, 수동 검토를 계속 추가하라.

PDF를 업로드하고 채팅하는 것 같은 것은 이제 그만하라. 구체적인 업무를 선택하라.

• 영업팀이 리드를 정리하고 후속 조치를 제안하도록 돕는 도구
• 고객센터가 지식을 검색하고 답변을 작성하도록 돕는 도구
• 재무팀이 경비 청구 서류를 확인하도록 돕는 도구
• 운영팀이 데이터를 정리하고 이상 징후를 알려주는 도구
• 제조팀이 설비 고장 및 유지보수 기록을 조회하도록 돕는 도구

두 번째 단계는 네 가지 지표에 집중한다.

5~6개월차: 실제 사용자를 찾아라

시험 사용할 의향이 있는 3~5명을 찾아 2주 연속 사용하게 하라. 기존 프로세스와 새 프로세스에 각각 걸린 시간, 사용 횟수, 채택된 제안, 수동 조치가 필요했던 오류, 사용자가 중간에 포기한 이유를 기록하라.

실제 사용자는 모든 숨은 문제를 드러낸다. 더러운 데이터, 부족한 권한, 불편한 UI, 끊임없이 바뀌는 프로세스, 높은 모델 비용 같은 것들이다. 이런 문제를 해결해야 프로젝트가 FDE 프로젝트처럼 보인다.

마지막으로 이를 케이스 스터디로 정리하라.

1비즈니스 배경
2→ 기존 프로세스
3→ 이 문제를 선택한 이유
4→ 시스템 아키텍처
5→ 데이터와 권한
6→ 평가 방법
7→ 사용 결과
8→ 실패와 조정
9→ 재사용 가능한 부분

이력서에는 프레임워크 이름을 줄이고 세 가지만 명확하게 적어라. 누가, 얼마나 오랫동안 사용했는지, 지표가 어떻게 바뀌었는지.

7. 구직할 때 'FDE'만 검색하지 말라

이 포지션의 이름은 아직 완전히 통일되지 않았다. Forward Deployed Engineer 외에도 아래 이름으로 검색할 수 있다.

• Forward Deployed AI Engineer
• Applied AI Engineer
• AI Deployment Engineer
• Solutions Engineer
• AI Solutions Architect
• Deployment Strategist
• AI Application Delivery Engineer
• AI Solution Engineer
• Agent Engineer

포지션을 발견하면 다음 네 가지를 확인하라.

1. 고객과 현장 사용자에게 직접 접촉하는가?
2. 프로덕션 코드를 직접 작성해야 하는가?
3. 문제 발견부터 출시까지 전체 과정에 책임을 지는가?
4. 출시 후 채택률과 비즈니스 성과를 추적해야 하는가?

네 가지가 모두 해당된다면 그 일의 내용은 FDE에 가깝다.

면접 준비 방법

FDE 면접에서는 종종 매우 모호한 문제가 주어진다. 예를 들어 "병원이 AI로 환자 대기 시간을 줄이고 싶어 한다. 어떻게 하겠는가?" 같은 문제다.

서둘러 모델을 고르지 말라. 환자가 어느 단계에서 기다리는지, 대기와 분류를 누가 하고 있는지, 현재 평균 대기 시간은 얼마인지, 데이터가 어디에 저장되는지, 어떤 결정이 의료진의 판단을 필요로 하는지, 프로젝트 성공을 정의하는 지표가 무엇인지를 먼저 명확히 해야 한다.

문제가 명확해지면 시스템, 권한, 출시 범위에 대해 이야기하라. 면접관이 보고 싶어하는 것은 모호한 문제를 명확한 문제로 바꿀 수 있는지 여부다. 모델 이름을 열 개 외운다고 이 단계를 통과할 수는 없다.

8. '이름만 바뀐 현장 납품'을 경계하라

FDE가 인기를 얻으면서 같은 이름이지만 일이 전혀 다른 포지션이 더 많이 등장할 것이다. 어떤 자리는 핵심 코드를 작성하고 채택률을 끌어올리며 현장 경험을 제품에 반영하게 하지만, 어떤 자리는 매일 현장의 불을 끄고 코드는 메인 저장소에 들어가지도 못하며 평가가 인일(man-day)과 검수로만 이뤄진다.

둘 다 FDE라고 불리지만 직업적 가치는 크게 다르다. 면접에서 다음을 직접 질문해도 된다.

1. FDE가 작성한 코드는 어떤 저장소에 들어가는가?
2. 팀은 제품, 엔지니어링, 아니면 프로젝트 전달 부서 중 어디에 속하는가?
3. 프로젝트는 채택률과 비즈니스 지표를 보는가, 아니면 기한 내 검수만 보는가?
4. 현장 문제는 어떻게 제품 로드맵에 반영되는가?
5. 프로젝트 종료 후 장기 운영 책임은 누구에게 있는가?
6. 지난 세 프로젝트에서 재사용 가능한 컴포넌트는 무엇이 쌓였는가?
7. 여행, 현장 근무, 당직에 보내는 시간의 비중은 얼마나 되는가?

판단 기준은 간단하다.

• 진짜 FDE: 프로덕션 코드를 작성하고 성과에 책임을 지며 경험이 제품으로 환원된다.
• 이름만 바뀐 현장 지원: 인일 단위로 과금되고 검수 중심이며 모든 프로젝트를 매번 처음부터 다시 시작한다.

성과에 책임을 지라고 요구하면서도 데이터 권한, 기술 의사결정권, 제품 지원을 주지 않는 회사라면 그 일은 아마 매우 힘들 것이다. 직함이 새로워졌을 뿐 일하는 방식은 전혀 바뀌지 않았을 수 있다.

마지막으로

FDE의 폭발적인 성장은 AI가 다음 단계로 넘어갔다는 신호다. 모델은 계속 강력해지겠지만, 모델과 실제 비즈니스 사이에는 더 큰 간극이 생겨났다.

고객은 현장에 들어가 어수선한 데이터, 레거시 시스템, 비즈니스 규칙, 실제 사용자를 이어줄 사람이 필요하다. 이 일은 진입 장벽이 높다. 코드를 쓸 줄 알아야 하고, 비즈니스를 이해해야 하며, 고객을 마주하고 출시 후 결과를 감당해야 한다.

일반인에게 기회는 이미 가진 절반의 스킬 안에 숨어 있다. 코드를 쓸 줄 안다면 비즈니스와 고객 역량을 보완하고, 업계를 안다면 엔지니어링과 배포를 보완하고, 데이터·프리세일즈·구현 경험이 있다면 현재 역량을 더 키우고, 완전한 초보자라면 검증 가능한 하나의 하드 스킬을 먼저 연습하라.

지금 딱 하나만 한다면 이렇게 하라.

실제 문제를 찾고, 출시할 수 있는 도구를 만들고, 세 사람이 2주 연속 사용하게 하라.

그것을 끝내면 여러분의 작업은 이미 FDE의 일처럼 보이기 시작한다. 직함은 그다음에 얻어도 된다.

참고 링크

• LinkedIn: 제대로 작동하는 일의 미래를 구축하다
• OpenAI: OpenAI Deployment Company 출시
• AWS: 파트너를 위한 Forward Deployed Engineering 소개
• OpenAI: Forward Deployed Engineer 채용 공고
• Palantir: 신입 Forward Deployed Software Engineer

**

글쓴이 소개