포워드 디플로이드 엔지니어링: 소프트웨어 엔지니어의 새 직군

아마존이 10억 달러짜리 조직을 따로 세웠다

아마존이 2026년 6월, AWS 안에 10억 달러짜리 포워드 디플로이드 엔지니어(FDE) 조직을 세웠다. 앞서 OpenAI가 40억 달러, 앤트로픽이 15억 달러를 같은 곳에 부었다. 세 회사가 몇 달 간격으로 같은 판단을 내린 데는 이유가 하나다, 모델은 충분히 똑똑해졌는데, 기업이 그걸 자기 업무에 얹지 못한다. 데모는 근사하게 돌아가도, 실제 워크플로우와 사내 시스템, 규제, 지저분한 데이터 위에 올리는 순간 멈춰 선다. 그 마지막 구간을 사람이 직접 고객사 안으로 들어가 손으로 메우는 직무가 FDE다.

이 모델을 처음 만든 건 팰런티어다. 2010년대 초, 정보기관 고객은 자기가 뭘 원하는지 정식 요구사항으로 내놓을 수 없었다. 그래서 팰런티어는 엔지니어를 분석가 옆에 앉혀 두고, 일이 실제로 굴러가는 방식을 관찰하며 그 자리에서 도구를 만들게 했다. 2016년 무렵엔 이 FDE 수가 일반 제품 엔지니어보다 많아졌다. 산출물을 넘기고 빠지는 컨설턴트와 달리, FDE는 자기가 만든 시스템이 프로덕션에서 도는 것까지 책임진다. 15년 전 정보기관용으로 다듬은 이 방식을, 지금 AI 기업들이 엔터프라이즈 판매의 표준 조직으로 제도화하고 있다.

세 직군의 교집합에 서는 자리

FDE는 세 직군의 교집합에 선다. 프로덕션급 코드를 쓰는 소프트웨어 엔지니어이면서, 고객의 업무를 뜯어 모델로 옮기는 솔루션 아키텍트이고, 뭘 만들지부터 정하는 프로덕트 감각까지 요구받는다. 팰런티어에서 FDE는 핵심 엔지니어와 똑같은 기술 면접을 통과한다, 고객사 안에 앉아 있을 뿐, 코드가 무른 자리가 아니다.

• 풀스택 구현력. 프런트부터 데이터 파이프라인, 인증, 배포까지 혼자 끝까지 만든다. 고객사엔 각 계층을 나눠 맡을 팀이 없다고 보고 움직인다.
• 고객 대면과 도메인 모델링. 회의실에서 현장 담당자의 말을 듣고, 정리되지 않은 업무를 데이터 스키마와 에이전트 동작으로 옮긴다. 요구사항이 문서로 오지 않는다는 걸 전제로 일한다.
• 빠른 프로토타이핑. 며칠 안에 돌아가는 걸 손에 쥐여 주고, 반응을 보며 깎아 나간다. 완성도보다 “이게 맞는 문제냐"를 먼저 확인한다.
• 통합과 배포. 사내 시스템, SSO, 온프레미스, 규제·보안 요건 위에 AI를 실제로 올린다. 데모와 프로덕션을 가르는 건 대부분 이 구간이다.
• 판매의 기술 파트너. 계약 전 PoC를 이끌고, 계약 후 확산을 책임진다. GTM 엔지니어링이라 불리는 이유다.

회사마다 진입 장벽이 다르다

진입 장벽은 회사마다 다르다. 팰런티어는 대학 졸업 후 1년 경력으로도 뽑고, 램프 같은 곳은 시니어 FDE에 5년 이상을 요구한다. 공통점은 코드를 못 쓰면 시작이 안 된다는 것, 고객 앞에 서는 자리이기 전에 엔지니어 자리다. 주니어는 선임 FDE 밑에서 한 계정을 붙어 배우고, 시니어가 되면 배포 하나를 처음부터 끝까지 소유하며, 리드는 여러 계정과 그 밑에 깔리는 재사용 가능한 플랫폼 사이에서 균형을 잡는다.

보상은 후하다. a16z가 “IT 업계에서 가장 뜨거운 직무"라 부른 데는 이유가 있다, 파는 사람과 만드는 사람을 한 몸에 얹은 희소 인력이라 값이 매겨진다. 채용은 두 갈래다. OpenAI·앤트로픽·아마존처럼 자사 AI를 기업에 심으려는 벤더, 그리고 초기 대형 고객을 직접 뚫어야 하는 GTM 중심 스타트업. 국내라면 삼성SDS·LG CNS 같은 SI 대기업의 내재화 조직과, 네카라쿠배의 엔터프라이즈 팀이 같은 인력을 두고 이름만 다르게 부른다. 다만 국내 SI의 다단계 하도급 구조는 이 모델과 정면으로 부딪힌다, 요구정의를 원청이 쓰고, 구현을 하청이 맡고, 운영이 또 다른 회사로 넘어가는 방식과, 한 사람이 고객 안에서 통째로 안는 FDE는 사고방식이 정반대다.

이 일에 맞는지 보려면 사이드 프로젝트 하나를 남을 위해 끝까지 배포해 보면 된다. 남의 어설픈 요구를 듣고, 스키마로 옮기고, 그 사람 환경에 올려 실제로 쓰이게 만드는 것, 이 한 번의 경험이 알고리즘 문제 백 개보다 이 직무를 잘 설명한다.