FDE을 제대로 알고 준비하기

지금 2026년 봄 실리콘밸리의 빅테크에서는 이상한 풍경이 펼쳐지고 있습니다.

Meta는 또 한 차례 전 임직원의 10% 정리해고를 발표했고, Google, Microsoft, Amazon은 엔지니어링 조직을 대폭 줄이고 있습니다. 하루가 다르게 해고뉴스가 나오는데, 그런데 같은 기업들이 동시에 공격적으로 채용하고 있는 단 하나의 포지션이 있습니다.

FDE(Forward Deployed Engineer)

팔란티어가 만든 이 직함은 이제 오픈AI, 앤쓰로픽, 구글은 물론이고 마이크로소프트, 세일즈포스, 서비스나우, 아마존, 그리고 SAP, 오라클 같은 전통 엔터프라이즈 SaaS 기업, 심지어 맥킨지와 딜로이트 같은 컨설팅 펌까지 채용 공고 최상단에 올려놓고 있습니다.

서울을 기반으로 하는 FDE엔지니어를 찾는 구글 클라우드

이번 5월, AI 산업의 가장 큰 세 기업이 열흘 사이에 같은 발표를 했습니다.

5월 4일. 앤쓰로픽이 블랙스톤·골드만삭스와 컨설팅 합작법인을 출범시켰습니다.

5월 11일. 오픈AI가 'OpenAI Deployment Company'를 공식화하며, 150명의 FDE(Forward Deployed Engineer)를 투입했습니다.

5월 13일. 구글이 "수백 명 규모의 FDE 조직을 구글 클라우드에 신설하겠다"고 발표했습니다. (위의 이미지 참고)

이게 무슨 의미일까요?

세 회사가 각자 다른 자본 구조와 다른 조직 형태를 택했지만, 모두 'FDE'라는 같은 직바카라명을 채택했다는 사실에 주목해야 합니다. 우연한 동시성이 아닙니다. 산업 차원의 공식화입니다.

새로운 골드러시처럼 보입니다. 그런데 제가 필드에서 보고 있는 광경은 이렇습니다.

한국의 뛰어난 엔지니어들, PM들, 컨설턴트들이 이 기회 앞에서 떨어지는 연습을 반복하고 있습니다.

오늘 이 글에서는 FDE라는 직함 속에 숨은 의미를 말씀드리고, FDE로의 새로운 기회를 준비하시는 분들에게 진짜 도움이 되는 필드 경험과 지식을 나누려 합니다.

"FDE 준비"라는 말이 가장 위험한 이유

지원자들은 지금까지 엔지니어링 포지션을 준비하던 것과 별 다름없이 보통 이렇게 준비합니다.

온라인 문제 은행 LeetCode를 풉니다. 시스템 디자인 바카라을 봅니다. 클라우드 자격증을 갱신합니다. AI 관련 용어를 외웁니다. RAG, 에이전트, 벡터 DB, LLM Ops. 행동 면접 답변을 정리합니다. 그리고 자신있게 면접에 임합니다.

그리고는 아쉬운 소식을 듣습니다. 왜 떨어졌는지도 모릅니다. "내가 코딩이 부족했나?" "AI 경험이 약했나?" 다시 같은 패턴으로 준비합니다. 결과는 같습니다.

저와 면접을 진행한 분들에게는 면접 후에 언질을 드리기는 했지만, 문제는 실력이 아닙니다. 방향입니다.

FDE는 직함이 같다고 같은 직업이 아닙니다. 팔란티어의 FDE와 구글의 FDE와 오픈AI의 FDE는, 사실 완전히 다른 직업입니다. 같은 옷을 입었지만 다른 사람들이고, 다른 도메인에서 다른 역량을 갖고 다른 업무를 합니다. 그리고 여기에 Salesforce, ServiceNow, SAP, Oracle, Microsoft까지 각자의 무대를 만들어가고 있습니다.

여러분이 셰프가 되고 싶다고 칩시다. 그런데 어떤 음식 셰프인지를 안 정하고 "요리 공부하면 되겠지"라고 생각하면 어떻게 될까요? 미슐랭 파인다이닝 셰프와 호텔 뷔페 셰프와 동네 분식집 셰프, 중식, 일식, 프랑스 요리는 다 셰프지만, 칼 잡는 법부터 다릅니다. 들어가는 재료도, 만드는 속도도, 손님을 대하는 방식도 완전히 다르죠. 요리학원에서 같은 기본기를 배워도, 어느 무대로 갈지 안 정하면 — 어느 주방도 그를 원하지 않습니다. FDE도 똑같습니다.

왜 지금, 왜 FDE인가

본론에 들어가기 전에 짚어둘 숫자가 하나 있습니다.

엔터프라이즈 AI 파일럿은 95%가 실패합니다. 모델이 약해서가 아니라, 프로덕션에 올라가면 그대로 동작하지 않기 때문입니다.

이 문장이 모든 것을 설명합니다. 지난 3년간 전 세계 기업들은 AI에 돈을 쏟아부었습니다. PoC는 화려했습니다. 데모는 박수를 받았습니다. 그런데 프로덕션으로 넘어간 비율은 처참합니다. 왜? 모델은 좋은데 — 그 모델이 기업의 실제 워크플로우, 데이터 거버넌스, 레거시 시스템, 컴플라이언스 제약 안에서 작동하게 만들 사람이 없었기 때문입니다. 이걸 깨달은 회사들이 동시에 같은 결론에 도달했습니다. "우리도 팔란티어처럼 해야 한다. 엔지니어를 고객 안에 박아넣어서, 진짜 작동하는 시스템을 만들어내는 내야 한다."

이게 lay off와 FDE 채용이 공존하는 이유입니다. 데모 만드는 엔지니어는 이제 잉여고, 프로덕션에 안착시키는 엔지니어는 부족합니다. 시장이 보고 있는 가치의 무게중심이 옮겨간 겁니다.

자, 이제 팔란티어, 구글, 오픈AI의 FDE를 해부하며, 본격적으로 이야기 해 봅시다.

1. 팔란티어형 FDE - 컨설턴트도 SE도 아닌 제3의 직군

팔란티어가 만든 원형 FDE를 정확히 이해해야 나머지가 보입니다. 많은 분들이 팔란티어 FDE를 "고객 현장에 가는 시니어 엔지니어" 정도로 이해하시는데, 그건 절반의 진실입니다.

핵심은 이겁니다. 팔란티어는 FDSE(Forward Deployed Software Engineer)를 한 고객에게만 전담시킵니다. 그리고 그 옆에 Deployment Strategist(DS)라는 또 다른 직군을 붙입니다. DS는 기술과 운영 우선순위 사이의 갭을 메우고, 일이 진짜 문제를 풀고 있는지, 고객 조직 안에서 채택되고 있는지를 보는 사람입니다. 즉, 2인 1조 모델입니다.

소프트웨어 회사는 보통 고객사 팀이나 파트너에게 구현을 맡깁니다. 컨설팅 펌은 매번 다른 기술 스택으로 처음부터 짓습니다. 팔란티어는 자기 사람을, 자기 스택으로, 고객의 프로덕션에 직접 박아넣습니다. 이게 카테고리를 만들었습니다.

그런데 진짜 천재적인 부분은 따로 있습니다.

컨설팅 펌은 한 고객을 위해 한 번 만들고 시간 단위로 청구합니다. 팔란티어는 한 고객을 위해 한 번 만들고, 그게 흥미로운 방식으로 실패하는 걸 지켜본 다음, 그 실패를 플랫폼 인프라로 전환합니다. 모든 고객 프로젝트가 사실은 R&D 투자였고, 그 투자는 운영 인사이트로 회수됐습니다. 고객당 배포 비용은 플랫폼이 성숙할수록 떨어졌고, 우위는 복리로 쌓였습니다.

이게 무슨 말이냐. 초기 Gotham 배포는 깊이 맞춤형이었습니다. 그런데 엔지니어들이 여러 고객에서 같은 구조적 문제가 반복된다는 걸 발견했죠. 팔란티어는 이걸 매번 새로 풀지 않고, 플랫폼의 원시 요소(primitive)로 인코딩했습니다 — 온톨로지, 객체 모델, 권한 시스템, 워크플로우 엔진, 출처 추적 같은 것들이죠. FDE는 비용 센터가 아니라, 현실의 복잡성을 소프트웨어 인프라로 변환하는 메커니즘이었던 겁니다.

그래서 팔란티어형 FDE 인터뷰에서 평가하는 건 LeetCode 능력이 아닙니다. 지원자에게서 평가하고자 하는 건 이런 겁니다.

식중독 발생을 어떻게 더 빠르게 추적할 것인가

의료 공급망의 어느 지점이 환자를 죽이고 있는가

임원이 "AI"를 원하지만 진짜 문제는 프로세스 실패다 — 대화를 어떻게 전환할 것인가

답이 없는 문제. 데이터는 흩어져 있고, 이해관계자는 서로 싸우는 환경. 이 안에서 혼돈을 명확성으로 바꿔내는 능력을 원하고 있는 것이죠.

팔란티어형 FDE의 본질은 엔지니어 + PM + 컨설턴트 + 운영자가 한 사람에 압축된 형태입니다.

그리고 한국에 이런 분들이 어디 있는지는 밑에서 이야기하겠습니다.

2. 구글 클라우드형 FDE - PoC 무덤에서 고객 구출하는 사람

구글 FDE의 무게 중심은 팔란티어와 완전히 다릅니다.

팔란티어형이 "혼돈에서 명확성을 만드는 사람"이라면, 구글형은 "PoC의 무덤에서 고객을 구출하는 사람"입니다.

엔터프라이즈에서 PoC는 성공시켰는데 프로덕션으로 못 넘어갑니다. 이게 현재 엔터프라이즈 AI 시장의 가장 큰 갭입니다. 그리고 그 갭은 기술 문제가 아니라 거의 항상 엔터프라이즈 아키텍처 문제입니다.

구글 클라우드 FDE가 매일 마주하는 질문은 이런 것들입니다.

이걸 관리형 서비스(Vertex AI)로 할 것인가, 커스텀 배포로 할 것인가?

ID, 보안, 접근 권한을 어떻게 구조화할 것인가? Workspace SSO와 어떻게 연결할 것인가?

데이터와 임베딩을 어디에 저장할 것인가? BigQuery에 둘 것인가, 별도 벡터 DB를 쓸 것인가?

레이턴시는? 가관측성은? 비용은? 이 셋의 트레이드오프를 어떻게 잡을 것인가?

RAG 프로토타입을 어떻게 프로덕션에 안전하게 옮길 것인가?

이런 질문은 LLM 프롬프트 엔지니어링 바카라에는 나오지 않습니다. 클라우드 아키텍처를 깊이 이해하면서 동시에 AI 시스템의 행동 특성을 알아야 답할 수 있죠.

그래서 구글형 FDE는 화이트보드 앞에서 VP와 대화하면서, 아키텍처 다이어그램을 그리고, 플랫폼 선택을 정당화하고, 고객이 묻기 전에 불편한 엔터프라이즈 질문을 선제적으로 던질 수 있어야 합니다. "이 RAG 시스템에 PII가 들어가면 GDPR은 어떻게 처리하실 건가요?" "벡터 DB가 down 됐을 때 fallback 전략은 뭔가요?" "이 비용 구조가 사용량 10배가 되면 어떻게 변하나요?"

이건 솔루션 엔지니어링과 다릅니다. SE는 파는 사람이고, FDE는 짓는 사람입니다.

연봉도 다릅니다. 구글 FDE 시작 베이스는 $127K–$183K + equity 수준이고, 시니어/리드 레벨로 올라가면 훨씬 더 갑니다.

3. 오픈AI형 FDE - AI가 현실에서 쓸모있게 만드는 사람

오픈AI의 FDE는 또 다른 종입니다.

오픈AI의 FDE 팀은 수천만 달러에서 수십억 달러 가치의 문제를 푸는 데 집중합니다. 금융(Morgan Stanley), 제조(반도체, 자동차), 통신(T-Mobile, Klarna) 등 산업 전반에서 일합니다. 깊은 도메인 임베딩, 평가 중심 개발, 가드레일 구현, 수개월에 걸친 사용자와의 반복을 통해 20-50%의 효율 개선과 높은 채택률을 달성합니다 — Morgan Stanley에서는 98% 도입률을 기록했죠.

이 숫자가 중요합니다. 98% 도입률. 보통 엔터프라이즈 소프트웨어가 사내 도입률 30% 넘기면 성공이라고 봅니다. 98%는 사실상 모든 금융 어드바이저가 매일 쓴다는 뜻입니다. 이게 어떻게 가능했을까요?

2023년 Morgan Stanley는 오픈AI의 첫 엔터프라이즈 고객이었고, FDE 프랙티스를 정립한 프로젝트였습니다. 당시는 RAG라는 패턴조차 확립되기 전이었습니다. 팀은 retrieval tuning 기법을 직접 개발해야 했고, 리서치 리포트가 정확하게 표면화되고 신뢰받을 수 있도록 만들어야 했습니다. 6-8주 만에 retrieval 최적화, 가드레일을 포함한 전체 파이프라인을 구축했습니다. 여기서 OpenAI형 FDE의 본질이 드러납니다. 현장이 곧 실험실이고, 배포가 곧 연구입니다. OpenAI형 FDE 인터뷰에서 묻는 질문은 이런 식입니다.

데모 품질을 넘어서 RAG 시스템을 어떻게 평가하겠는가?

에이전트 워크플로우의 실패 모드는 어디서 발생하는가?

문제가 검색인지, 프롬프트인지, 도구 사용인지, 모델 한계인지 어떻게 구별하는가?

프로덕션에서 silent failure(틀렸는데 틀린 줄 모르는 실패)를 어떻게 방지하는가?

마지막 질문이 가장 중요합니다. 엔터프라이즈 AI에서 가장 무서운 건 모델이 멈추는 게 아니에요. 모델이 자신감 있게 틀린 답을 내놓는 겁니다. 그리고 그걸 잡아내는 건 모니터링 도구가 아니라 eval 체계입니다.

평가 프레임워크(Evaluation frameworks)는 2026년 FDE가 무조건으로 갖추어야 할 스킬이 되었습니다. 앤쓰로픽의 FDE 채용 공고는 'LLM 프로덕션 경험, 고급 프롬프트 엔지니어링, 에이전트 개발, 평가 프레임워크, 스케일 배포 경험'을 명시적으로 요구합니다. 환각, 회귀, 편향, grounding gap을 프로덕션 전에 잡아내는 eval suite를 만드는 건 이제 옵션이 아니라 필수입니다.

즉 OpenAI형 FDE는 단순한 솔루션 엔지니어링이 아닙니다. 현장에서 작동하는 AI 제품 엔지니어링입니다. 연봉도 다릅니다. OpenAI FDE 중간 레벨이 기준 $220K-$280K. 출장은 50%까지 요구됩니다.

그리고 엔터프라이즈 SaaS 전체로 확산되는 FDE

그리고 시장이 여기서 멈출리가 없죠. 팔란티어, 구글, 오픈AI는 시작이었습니다. 이제 더 큰 그림을 봐야 합니다. AI 리딩 기업이 노리는 시장이 전통적인 엔터프라이즈 SaaS 시장이었기에, 그들의 반격을 합니다.

세일즈포스는 FDE를 "오늘날 가장 핫한 역할"이라고 부르면서, AI 에이전트 런칭의 성패를 좌우하는 사람이라고 정의합니다. Agentforce 출시 이후 세일즈포스는 인도, 미국 등 전 세계에 FDE를 채용 중입니다.

서비스나우도 "Applied AI Forward Deployed Engineering 팀"을 키우고 있습니다. 스타트업 속도로 AI 솔루션을 만들고, 미션 크리티컬한 문제를 풀고, 엔터프라이즈 스케일에서 실질적 임팩트를 만드는 팀이라고 채용 페이지에 명시되어 있습니다.

Deloitte 같은 글로벌 컨설팅 펌도 빠르게 움직이고 있습니다. Deloitte의 FDE 채용 공고는 명시적으로 'SAP, Oracle, ServiceNow, Salesforce 같은 엔터프라이즈 생태계에 대한 친숙함', '규제 산업과 거버넌스 중심 환경 경험', '맞춤형 작업을 재사용 가능한 제품 역량으로 전환하는 플랫폼화 경험'을 요구합니다. 글로벌 FDE 조직 차터, 레퍼런스 아키텍처, 보안/프라이버시 패턴, 평가/모니터링 표준을 만들 사람을 찾고 있죠.

마이크로소프트, SAP, Oracle도 같은 방향으로 가고 있습니다. 명칭이 정확히 "FDE"가 아닐 뿐, 본질은 같습니다. 고객 안에 들어가서, AI를 실제로 작동하게 만드는 사람.

그리고 한 가지 더 짚어야 할 흥미로운 발전이 있습니다. 팔란티어는 'AI FDE'라는 이름의 AI 에이전트를 만들었습니다. 대화형 명령으로 파운드리를 운영하는 에이전트인데, 자연어 요청을 파운드리 작업으로 번역해서 데이터 변환 파이프라인 생성, 코드 저장소 관리, 온톨로지 구축 같은 일을 대신해줍니다.

즉, FDE라는 역할 자체가 이미 AI로 일부 자동화되기 시작했다는 뜻입니다. 그렇다면 인간 FDE의 가치는 어디로 가는가? — 자동화가 닿지 못하는 영역, 모호한 문제를 정의하고, 이해관계자를 설득하고, 도메인 지식을 시스템 설계로 번역하는 영역으로 갑니다. 코드 작성보다 판단력의 가치가 더 커지는 거죠.

그렇다면 어떻게 준비해야 하는가

다 좋은 이야기인데, "그래서 구체적으로 뭘 어떻게 하라는 말이냐" 하시겠죠?. 세 가지를 꼭 점검하시길 제안드립니다.

첫째, 어떤 종류의 FDE를 목표로 할 것인가를 정하십시오.

"FDE를 준비한다"는 말은 "운동을 준비한다"는 말과 같습니다. 마라톤과 역도와 양궁은 다 운동이지만 준비 방식이 완전히 다르죠. 팔란티어형(혼돈에서 명확성)인지, 구글 클라우드형(엔터프라이즈 아키텍처)인지, 오픈AI형(AI 행동 신뢰성)인지, 세일즈포스/서비스나우형(SaaS 위의 에이전트 배포)인지, SAP/Oracle형(ERP와 AI 통합)인지를 먼저 정해야 합니다. 안 정하면 모든 준비가 평균에 머물고, 어디서도 선택이 안 됩니다.

둘째, 자신의 SI/ERP 경험을 FDE 언어로 재번역하십시오.

"통신사 빌링 시스템 차세대 프로젝트 PM"이라고 쓰면 안 됩니다. "수억 건의 트랜잭션이 발생하는 운영 환경에서 모호한 비즈니스 요구를 데이터 모델과 워크플로우로 구조화하고, 다층 이해관계자와의 합의를 통해 프로덕션 배포까지 단독 오너십으로 수행"이라고 써야 합니다. 같은 경험, 다른 언어. 글로벌 채용 시장은 후자만 알아듣습니다.

셋째, AI 시스템의 행동을 다뤄본 경험을 만드십시오.

단순 LLM API 호출이 아닙니다. RAG 시스템의 실패 모드를 분석해본 경험, 에이전트 워크플로우를 디버깅해본 경험, eval 체계를 직접 설계해본 경험. 이건 바카라으로 공부한 수준은 안 됩니다. 바로 드러납니다. 작은 프로젝트라도 직접 만들어서, 실패하고, 분석하고, 개선해본 흔적이 있어야 합니다.

한국이 SI 강국에서 FDE 강국으로

마지막으로, 제가 정말 하고 싶은 이야기입니다.

대한민국은 SI 강국입니다. 이건 정말 엄청난 자산입니다. SAP에서 자랑하는 고객 프로젝트 대표 성공 사례의 대부분은 대한민국 기업입니다. 30년 동안 한국의 SI 엔지니어들은 통신사 빌링 시스템, 은행 코어뱅킹, 정부 행정 시스템, 대기업 ERP 전환을 만들어왔습니다. 고객의 모호한 요구사항을 정리하고, 흩어진 데이터를 연결하고, 레거시 시스템과 신규 시스템을 통합하고, 임원의 정치적 요구와 현업의 실무적 비명 사이에서 살아남는 법을 익혀왔습니다.

이게 무슨 역량인지 아십니까? 이게 정확히 FDE의 역량입니다.

팔란티어가 요구하는 "혼돈에서 명확성을 만드는 능력". 한국 SI 컨설턴트는 매일 합니다.

Google Cloud가 요구하는 "엔터프라이즈 통합과 거버넌스". 한국 SI 아키텍트의 일상입니다.

OpenAI가 요구하는 "레거시 인프라가 핵심 제약인 환경에서 배포". 한국 SI 엔지니어가 30년 동안 해온 그 일입니다.

Salesforce, ServiceNow, SAP가 새로 키우는 FDE 조직이 필요로 하는 "도메인 깊이 + 시스템 통합 + 다중 이해관계자 관리" — 한국 SI 출신이 이미 갖춘 기본기입니다.

문제는 우리가 이걸 "FDE 역량"으로 번역해서 팔지 않았다는 것입니다.

한국의 SI 인재는 풀스택입니다. 비즈니스 도메인을 이해합니다. 고객과 직접 대화합니다. 모호함을 견딥니다. 그리고 무엇보다 '근면 성실'합니다. 그런데 우리는 이걸 "SI 노가다"라고 자조해왔고, 글로벌 시장에서는 이 역량을 가리키는 단어를 모르고 있었습니다.

지금 그 단어 'FDE'가 생겼습니다. .

저는 가끔 이런 상상을 합니다. 한국이 SI 강국이라는 타이틀에 머무는 대신, FDE 강국으로 재포지셔닝하는 미래. 글로벌 AI 기업이 엔터프라이즈 고객을 만날 때, "그 프로젝트는 한국 FDE에게 맡기면 됩니다"라는 말이 자연스럽게 나오는 시장. 30년 동안 쌓아온 SI 역량이 글로벌 AI 도입 시장의 핵심 인프라가 되는 그림.

불가능한가요? 저는 충분히 가능하다고 봅니다. 단, 두 가지가 필요합니다.

첫번째는 개인 차원의 재포지셔닝입니다.

SI/ERP 경험을 FDE 언어로 번역하고, AI 시스템 다루는 경험을 더하고, 어떤 종류의 FDE인지 명확히 타겟팅하는 것입니다.

다른 하나는 생태계 차원의 재포지셔닝입니다.

한국 SI 기업들이 "단가 후려치기 게임"에서 벗어나 "FDE급 인재 양성소"로 자신을 재정의하는 것. 이건 개인이 아니라 산업이 풀어야 할 숙제입니다.

직함은 통일된 것처럼 들립니다. 일은 그렇지 않습니다.

같은 FDE라는 단어 아래 다섯, 여섯, 일곱 개의 다른 직업이 있고, 그 모두에 한국 SI 인재가 잘할 수 있는 자리가 있습니다. 단, 어떤 무대에서 어떤 공연을 할지를 먼저 정해야 합니다.

새로운 게임이 시작되었습니다. 한국 SI의 30년 자산이 글로벌 AI 시장의 가장 비싼 역량으로 재평가되는 게임이요. 떨어지는 연습을 반복하는 분들이 너무 많아서 이 글을 적었습니다.

여러분의 30년이, 여러분의 다음 30년의 무기가 되었으면 좋겠습니다.

늘 여러분의 도전에 응원의 박수를 보냅니다.