[AI Frontier] AI를 팔기 위해 다시 사람을 보낸다. 전방배치형 엔지니어(FDE)가 뜨는 이유

[AI Frontier]

모델 성능이 좋아지면 기업 도입도 쉬워질 것 같지만 실제 병

목은 데이터·업무·권한·평가·사용자 채택 쪽으로 옮겨가고 있다. FDE의 부상은 AI가 사람을 다시 필요로 한다는 역설보다, 제품이 고객 현장과 만나는 방식이 바뀌고 있다는 신호에 가깝다.

2026년 9월 8일 구글 클라우드와 액센츄어는 새로운 공동 조직을 발표하면서 전방배치형 엔지니어(Forward Deployed Engineer, FDE) 1,000명 규모의 인력을 구축하겠다고 밝혔다. 이미 약 5만 명의 구글 클라우드 숙련 인력을 보유한 액센츄어가 별도로 FDE 조직을 키운다는 점이 눈에 띈다.

자동화를 파는 회사가 고객에게 다시 사람을 보내는 장면은 얼핏 모순처럼 보인다. 하지만 현재 엔터프라이즈 AI의 문제를 보면 오히려 자연스럽다. 모델은 빠르게 좋아졌지만, 기업의 데이터 구조와 업무 절차, 보안 권한, 성과 측정 방식은 같은 속도로 바뀌지 않았다.

FDE는 바로 이 틈에서 등장한다. 중요한 것은 직함의 유행이 아니다. AI 제품의 경쟁력이 모델 성능만으로 결정되지 않고, 고객 조직 안에서 실제 업무로 전환되는 속도까지 포함하기 시작했다는 점이다.

최근 공식 신호

1,000명

구글 클라우드·액센츄어가 구축하겠다고 밝힌 FDE 인력 규모

서울 FDE 공고

50%

OpenAI 서울 FDE 역할에 명시된 예상 출장 비중

채용 수요 신호

42배

Reuters가 LinkedIn 데이터를 인용해 전한 2023~2025년 관련 수요 증가 폭

1,000명 FDE 조직이 말하는 것은 채용 규모보다 ‘배포 격차’다

구글 클라우드와 액센츄어의 발표는 FDE를 단순 지원 인력으로 설명하지 않는다. 공동 조직이 맡을 역할에는 산업별 반복 솔루션 구축, AI 실험과 전사 배포 사이의 간극 축소, 사용자 채택 확대가 함께 들어 있다. 한 번의 데모보다 실제 운영 단계가 중요해졌다는 뜻이다.

OpenAI의 채용 공고도 비슷하다. 서울 FDE는 고객 요구 파악에서 기술 범위 설정, 시스템 설계, 구축, 프로덕션 전환까지 전체 과정을 맡는다. 성공 기준도 “구축 완료”가 아니라 실제 사용, 업무 영향, 평가 결과가 제품과 모델의 다음 방향에 반영되는지에 놓여 있다.

AGENCYTIMES VIEW

지금 나타나는 병목은 ‘모델이 할 수 있는가’보다 ‘이 조직에서 안전하게 반복 사용할 수 있는가’에 가깝다. FDE를 모델과 고객 사이에 사람을 한 명 더 붙이는 직군으로만 보면 좁다. 실제 역할은 이 배포 격차를 줄이는 데 가깝다.

FDE란 무엇인가: 컨설턴트와 솔루션 엔지니어 사이에서 생긴 새 역할

전방배치형 엔지니어는 고객 가까이 들어가 실제 문제를 정의한다. 필요하면 코드를 직접 작성하고 프로토타입을 운영 시스템으로 옮긴다. 팰런티어가 오래전부터 이 방식을 널리 알렸고, 지금은 OpenAI와 Anthropic 같은 AI 기업에서도 같은 직함이나 유사한 역할이 확인된다.

다만 FDE를 하나의 표준 직무로 생각하면 오해가 생긴다. 회사마다 영업 이전의 기술 검증에 더 가깝기도 하고, 계약 이후의 구축·운영에 더 가깝기도 하다. 중요한 것은 직함보다 책임 범위다.

구분	FDE	솔루션 엔지니어	컨설턴트	고객성공
핵심 산출물	운영 가능한 시스템과 반복 가능한 구축 패턴	제품 적합성 검증과 기술 제안	문제 정의와 변화·프로세스 설계	사용 확대, 갱신, 고객 성과
코드 작성	높음. 필요하면 직접 구축	조직에 따라 중간	조직과 프로젝트에 따라 다름	일반적으로 낮음
제품팀 피드백	핵심 역할. 현장 패턴을 제품으로 되돌림	주로 기능·기술 요구 전달	프로젝트 범위 중심	사용성과 고객 요구 중심
대표 성공 기준	프로덕션 사용과 측정 가능한 업무 효과	기술 검증과 계약 전환	프로젝트 목표 달성	활성화·유지·갱신

※ 위 표는 직무명을 획일적으로 정의한 것이 아니라, 공개된 FDE 역할과 일반적인 엔터프라이즈 소프트웨어 운영 구조를 비교하기 위한 AgencyTimes 편집 프레임이다. 실제 책임 범위는 회사마다 다르다.

모델이 강해질수록 왜 사람의 비중이 다시 커지는가

AI 모델의 성능 향상은 기업 도입의 필요조건이지 충분조건은 아니다. 같은 모델을 사용해도 한 회사에서는 매일 쓰는 업무가 되고, 다른 회사에서는 개념 검증(Proof of Concept, PoC)에서 멈춘다. 차이는 모델 밖에서 생긴다.

AGENCYTIMES DECISION MODEL

AI 사업가치 ≈ 모델 역량 × 데이터 적합성 × 업무 통합 × 통제·평가 × 사용자 채택

정량 계산식은 아니다. 배포가 어디에서 막히는지 찾기 위한 개념 모델이다. 한 항목만 낮아도 모델 성능을 높이는 것만으로는 실제 업무 성과가 제한되기 쉽다.

데이터 적합성. 기업 데이터는 깔끔한 학습 예제가 아니다. 접근 권한이 다르고, 부서마다 정의가 다르며, 오래된 시스템과 최신 클라우드가 섞여 있다. AI가 답을 잘하더라도 필요한 데이터를 안전하게 가져오지 못하면 업무 시스템이 되지 못한다.

업무 통합. 직원이 별도의 채팅창에서 AI를 한 번 쓰는 것과, 주문·계약·고객지원·개발·분석 과정에 AI가 들어가는 것은 다른 문제다. 후자는 기존 시스템의 이벤트, 예외 처리, 승인 순서까지 이해해야 한다.

통제와 평가. 무엇을 자동화할지보다 어디서 멈추고 사람이 승인할지를 먼저 정해야 하는 업무가 많다. 모델 평가도 단순 정확도를 넘어 해당 조직의 실패 비용과 연결돼야 한다.

사용자 채택. 기술적으로 돌아가는 시스템이 실제로 쓰인다는 보장은 없다. 기존 화면보다 느리거나, 책임 소재가 불분명하거나, 결과를 다시 사람이 전부 확인해야 하면 현장에서는 금방 우회된다.

FDE가 맡는 일은 이 네 가지를 한꺼번에 다루는 데 가깝다. 그래서 고객과 직접 이야기하는 능력과 코드를 만드는 능력이 같은 역할 안에 들어온다.

FDE의 진짜 역할은 고객별 코드를 많이 쓰는 것이 아니다

여기서 FDE와 단순 맞춤 개발을 가르는 기준이 생긴다. 고객마다 다른 코드를 빠르게 만들어 주는 데서 끝나면 확장성은 낮다. 사람 수를 늘려야 매출도 늘어나는 서비스 사업과 크게 다르지 않다.

반대로 현장에서 발견한 반복 문제를 제품 기능, 구축 도구, 평가 체계, 플레이북으로 되돌릴 수 있다면 FDE는 제품 개발의 일부가 된다. 팰런티어는 자사의 플랫폼이 현장 엔지니어와 핵심 엔지니어링 조직 사이의 반복 피드백으로 발전해 왔다고 설명한다. OpenAI 역시 FDE 역할에 반복되는 작업 방식을 도구·플레이북·재사용 블록으로 정리하고, 현장 평가 결과를 제품과 모델 로드맵에 반영하는 책임을 명시한다.

현장 문제 발견

→

빠른 구축

→

프로덕션 검증

→

반복 패턴 추출

→

제품으로 환류

FDE 조직을 볼 때 인원 수보다 중요한 지표는 현장 학습 회수율이다. 한 고객을 위해 해결한 문제가 다음 고객의 구축 시간을 줄이는가. 그렇다면 인력이 제품의 학습 장치가 된다. 그렇지 않다면 고비용 맞춤 개발 인력이 된다.

언제 FDE가 맞고, 언제 비싼 컨설팅이 되는가

모든 AI 기업이 FDE를 크게 운영할 필요는 없다. 반대로 모든 대형 고객에게 FDE를 붙인다고 좋은 사업이 되는 것도 아니다. 판단 축은 두 가지다. 고객 환경의 배포 불확실성과 현장에서 만든 해결책의 재사용 가능성이다.

배포 불확실성	재사용 가능성	권장 방식	판단
높음	높음	FDE 적합 구간	현장에서 배우고 제품화할 가치가 큼
높음	낮음	컨설팅 함정 주의	고객별 특수 요구가 누적돼 유지비가 커질 수 있음
낮음	높음	제품화 우선	셀프서비스·템플릿·표준 통합으로 전환할 구간
낮음	낮음	표준 구축 파트너	전담 FDE보다 일반 구현·운영 체계가 경제적일 수 있음

FDE의 가치가 가장 커지는 곳은 배포 불확실성과 재사용 가능성이 모두 높은 구간이다. 아직 정답은 없지만 한 고객에서 해결한 문제가 같은 산업의 다른 고객에게 반복될 가능성이 있는 영역이다. 의료, 법무, 제조, 반도체처럼 업무 맥락은 복잡하지만 공통 패턴이 존재하는 산업에서 FDE가 세분화되는 이유도 여기서 설명할 수 있다.

OpenAI가 의료·법률·정부와 같은 분야별 FDE 역할을 별도로 두는 것도 같은 맥락에서 읽을 수 있다. 고객 맞춤화와 산업별 재사용성을 동시에 확보하려는 구조다.

한국 기업이 FDE를 볼 때 확인할 여섯 가지

한국에서도 FDE라는 직함은 더 자주 보일 수 있다. OpenAI는 이미 서울 FDE를 채용하고 있고, Anthropic 역시 서울에서 Applied AI 인력을 모집하고 있다. 구매 기업이 확인할 것은 명함의 직함보다 공급사가 실제로 어디까지 책임지는지다.

FDE 도입·구매 체크리스트

프로덕션 책임: 데모와 PoC를 넘어서 실제 운영 전환까지 책임 범위에 들어가는가?
데이터와 권한: 어떤 데이터에 접근하고, 누가 권한을 승인하며, 기록은 어디에 남는가?
평가 기준: 정확도보다 실제 업무 성공·실패를 판단할 평가 항목이 정의돼 있는가?
맞춤 코드의 소유권: FDE가 떠난 뒤 누가 유지보수하며, 특정 공급사에 얼마나 종속되는가?
제품 환류: 현장에서 만든 기능이 향후 표준 제품으로 흡수되는가, 계속 별도 프로젝트 비용으로 남는가?
성과 측정: 구축 완료가 아니라 처리시간, 오류율, 승인시간, 매출, 비용처럼 업무 결과로 설명할 수 있는가?

플랫폼과 B2B 시스템을 운영해보면 새로운 기능 자체보다 목표 이벤트, 데이터 품질, 권한, 측정 기준이 실제 성과를 좌우하는 경우가 많다. 생성형 AI도 크게 다르지 않다. FDE는 이 문제를 사람의 현장 판단으로 빠르게 풀 수 있지만, 그 판단이 조직과 제품에 남지 않으면 같은 문제를 다음 고객에서 다시 풀게 된다.

FDE 붐을 “AI 시대에 사람이 다시 중요해졌다”는 이야기로만 끝내면 핵심을 놓친다. 엔터프라이즈 AI 기업의 시장진입 전략(Go-to-Market, GTM)은 제품 판매에서 제품 + 현장 엔지니어링 + 학습 환류까지 넓어지고 있다.

다음에 볼 지표도 FDE 인원 수가 아니다. 고객 한 곳을 프로덕션에 올리는 데 걸리는 시간, 이후 실제 사용률, 한 프로젝트에서 만든 구성요소가 다음 프로젝트에서 얼마나 재사용되는지, 그리고 서비스 인력이 늘어날수록 매출총이익률이 어떻게 움직이는지를 봐야 한다. FDE의 장기 경쟁력은 사람을 많이 보내는 능력보다 보낸 사람에게서 배운 것을 얼마나 빨리 제품으로 되돌리는가에서 갈릴 가능성이 크다.

Summary

FDE의 부상은 AI 모델이 부족해서가 아니라 기업의 실제 업무에 AI를 넣는 과정이 여전히 어렵다는 사실을 보여준다. FDE가 높은 가치를 만드는 구간은 배포 불확실성과 재사용 가능성이 동시에 높은 영역이다. 기업은 FDE 인원 수보다 프로덕션 전환, 평가 기준, 맞춤 코드의 소유권, 현장 학습의 제품 환류 여부를 확인해야 한다.

FAQ

전방배치형 엔지니어에 대해 자주 묻는 질문

Q. FDE란 무엇인가요?

FDE는 고객 조직 가까이에서 문제를 정의하고 코드를 직접 작성해 AI나 소프트웨어를 실제 업무에 배포하는 엔지니어다. 구축 과정에서 발견한 반복 패턴을 제품팀에 되돌리는 역할까지 포함할 때 일반적인 맞춤 개발과 차이가 커진다.

Q. FDE와 솔루션 엔지니어는 무엇이 다른가요?

회사마다 경계가 달라 한 문장으로 구분하기는 어렵다. 다만 FDE는 계약 전 기술 설명에 그치기보다 프로덕션 구축과 코드 작성, 실제 업무 영향까지 책임지는 경우가 많고 현장 학습을 제품 개발로 환류하는 비중도 높다.

Q. AI가 발전하는데 왜 FDE가 더 필요해지나요?

모델 성능과 기업 도입 난이도는 같은 문제가 아니기 때문이다. 실제 배포에는 데이터 접근, 기존 시스템 통합, 보안과 승인, 평가 체계, 사용자 채택이 필요하며 FDE는 이 여러 문제를 한 고객 환경에서 빠르게 연결한다.

Q. FDE는 앞으로도 계속 중요한 직군일까요?

모든 배포에서 같은 수준의 FDE가 계속 필요하다고 보기는 어렵다. 반복되는 구축 패턴이 제품화되면 일부 업무는 줄어든다. 반대로 AI가 새로운 산업과 고난도 업무로 들어갈수록 새로운 배포 격차가 생기기 때문에 FDE 방식은 다른 형태로 이어질 가능성이 있다.

TERMINOLOGY

본문에 나온 주요 용어

용어	뜻	실무 포인트
FDE	전방배치형 엔지니어(Forward Deployed Engineer)	고객 현장에서 문제 정의부터 구축·배포·피드백 환류까지 맡는 역할
PoC	개념 검증(Proof of Concept)	기술이 가능한지 확인하는 단계. 실제 운영과는 별도 과제가 남을 수 있음
GTM	시장진입 전략(Go-to-Market)	제품을 어떤 고객에게 어떤 판매·구축 방식으로 확산할지 정하는 구조
프로덕션	실제 업무에 지속 사용되는 운영 환경	데모가 아니라 보안·안정성·권한·유지보수까지 포함해 봐야 함
평가 체계	AI 결과와 업무 성과를 지속 확인하는 기준	정확도뿐 아니라 실패 비용, 승인, 처리시간 등 실제 업무 기준과 연결해야 함

이 블로그 검색