FDE: AI 시대의 직업 전환을 알리는 호각이 울렸는가?
👦🏻 저자: Henry(DeerFlow 팀)[1]
필자는 최근 한 달간 전면적인 경력 전환을 준비 중인 네 명의 친구를 만났다—프론트엔드 개발자, 솔루션 아키텍처 전문가, 제품 매니저, 전통적인 알고리즘 엔지니어였다. 이들의 배경, 나이, 거주 도시는 모두 달랐지만, 공통으로 물었던 영문 약어 하나가 있었다: FDE[2]가 과연 내가 도전해볼 만한가?
FDE는 Forward Deployed Engineer[2]의 약자이다. 이 용어는 2년 전만 해도 팔란티어(Palantir) 커뮤니티 내에서만 통용되던 ‘업계 은어’였으나, 오늘날에는 헤드헌터들의 인사 면접 첫 질문, 채용 공고에서 빈번히 등장하는 직무명, 그리고 소셜미디어에서 ‘AI 시대에 가장 가치 있는 직무’ 후보군 중 하나로 조용히 자리 잡았다. 오픈AI(OpenAI)는 2026년 5월, 바로 이 이름을 딴 ‘Deployment Company’[3]를 설립했으며, 초기 투자액은 40억 달러에 달한다. 이 회사는 고객 현장에 직접 엔지니어를 파견해 고객의 실제 업무 흐름 속으로 들어가도록 명확히 밝혔다. 앤트로픽(Anthropic)의 Applied AI 팀 역시 4개의 시간대에 걸쳐 FDE를 동시 채용하고 있다. 이 용어가 업계 은어에서 명확한 공식 용어로 바뀌기까지 단 1년여밖에 걸리지 않았다.
필자의 이전 기사 《슈퍼 개별자에게 보내는 글》[4]에서는 ‘인간의 엔진’—호기심, 자율 학습 능력, 자기 주도성, 실천 능력—이 완전한 클로즈드 루프(Closed-loop) 안에서 어떻게 발현되는지를 논했다. 그러나 인간은 공중에 떠 있지는 않는다. 인간은 구체적인 직무 좌표계에 의해 ‘받쳐져야’ 한다. 만약 슈퍼 개별자가 AI 시대의 생산 관계를 구성하는 ‘원료’라면, FDE는 바로 지난 1년간 시장이 만들어낸 가장 눈에 띄는 ‘직무 형태’라 할 수 있다.
필자의 견해로는, FDE는 컨설팅에도 속하지 않으며, 아웃소싱에도 속하지 않는다. 오히려 FDE는 슈퍼 개별자와 가장 가까운 위치에 있다—차이점은, FDE가 ‘모델 기업 × 고객’ 사이의 틈새에서 조직화된 슈퍼 개별자라는 점뿐이다.
혹시 아시는가—‘Forward Deployed’라는 표현은 어디서 유래했을까? 원래는 미군 용어인 ‘Forward Deployed Forces’에서 비롯된 것으로, 해외 또는 전선에 배치되어 신속하게 대응할 수 있는 부대를 의미하며, 이는 본토 기지에 머무르는 후방 부대와 대비되는 개념이다. 팔란티어는 2000년대 말 이 용어를 소프트웨어 산업으로 차용하여, ‘엔지니어를 본사에서 벗어나 고객 현장에 상주시키는’ 작업 방식을 묘사하였다. 심지어 내부 팀 이름조차 군사용 음성 표기법을 따르며 델타(Delta)와 에코(Echo)라고 명명하였다. 이번에 오픈AI와 앤트로픽이 이 용어를 다시 채택한 것은 우연이 아니다—엔지니어를 전선으로 파견한다는 본질은 결코 변하지 않았다.
본 기사에서는 필자가 최근 만난 네 명의 친구가 제기한 세 가지 구체적인 의문에 답하려 한다:
- FDE는 단지 AI라는 외피를 입은 컨설팅 회사일 뿐인가? 전통적 컨설팅과의 경계는 어디인가?
- FDE는 단지 고급 소프트웨어 아웃소싱일 뿐인가? 지금 내가 하는 ‘乙方(바이어 측)’ 일과 어떤 차이가 있는가?
- 나는 FDE가 적합한가? 어떤 유형의 사람이 이 직무에 의해 강화될 것이며, 또 어떤 유형의 사람은 소진될 것인가?
필자의 태도는 신중한 낙관이다: FDE는 실제로 성장하고 있지만, 그렇다고 해서 모든 사람의 경력 전환 출구가 되지는 않는다. 이를 ‘뜨겁게’ 다루는 것보다, 이를 ‘정확히’ 설명하는 것이 훨씬 중요하다.
오픈AI의 Deployment 팀에서 시작하기
FDE가 이번에 다시 주목받기 시작한 시점을 하나로 압축해야 한다면, 필자는 2026년 5월 11일을 선택하겠다—그날 오픈AI는 ‘Deployment Company’[5] 설립을 발표했으며, COO 브래드 라이트캡(Brad Lightcap)이 기존의 비즈니스 부문을 떠나 특별 프로젝트(Special Projects) 담당자로 전임하여 샘 알트먼(Sam Altman)에게 직접 보고하도록 하였다. 같은 주에 오픈AI는 영국의 AI 컨설팅 기업 토모로(Tomoro)를 인수하였고, 이 과정에서 150명의 Forward Deployed Engineer 및 Deployment Specialist를 새 회사에 일괄 편입시켰다.
흥미로운 점은, 오픈AI 채용 페이지에 샌프란시스코, 뉴욕, 워싱턴 등지에 더해 생명과학(Life Sciences), 반도체(Semiconductor), 정부(Gov) 등 산업별로 세분화된 여러 FDE 포지션이 동시에 게시되고 있다는 사실이다. 심지어 ‘FDE 채용 담당자’[6]라는 직무 자체도 모집 중이다. 분석가들은 이 팀이 3년 내에 2,000–4,000명 규모로 확장될 것으로 추산한다. 이는 단순한 연구 그룹이 아니라, 정규군에 버금가는 규모이다.
앤트로픽 측도 거의 동일한 행보를 보이고 있다. Applied AI 팀 산하의 Forward Deployed Engineer 포지션[7]은 보스턴, 뉴욕, 시애틀, 샌프란시스코, 워싱턴, 런던 등 6개 지역에서 동시에 공개되었으며, 고객 현장 출장 비율을 25%–50%로 요구한다. 최근 반복적으로 인용되는 사례 중 하나는 금융기술(FinTech) 기업 FIS인데, 이 기업은 공고문에서 “앤트로픽의 Applied AI 팀과 forward-deployed engineers가 이미 FIS에 투입되어 Financial Crimes AI Agent를 공동 설계하고, 지식 이전(Knowledge Transfer)을 통해 FIS가 향후 추가 Agent들을 독자적으로 확장할 수 있도록 지원하고 있다”고 명시하였다.
이 문장 속에는 FDE라는 직무의 진정한 모습이 숨어 있다. FDE는 프리세일즈 아키텍트도 아니고, SDR(Sales Development Representative)도 아니며, 고객 교육을 위한 ‘에반젤리스트(Evangelist)’도 아니다. FDE는 모델을 품고 고객의 코드베이스 속으로 들어가는 엔지니어이다. 브래드 라이트캡 본인은 이를 더욱 직설적으로 표현하였다: “고객들이 우리에게 말한 바에 따르면, 그들이 필요로 하는 것은 pilot 단계에서 production 단계로 이행할 수 있는 역량이다. Deployment Company는 바로 우리 엔지니어를 고객 팀에 직접 투입하여, 충분한 자원을 제공해 실제 결과물을 전달하는 것이다.”
이 일을 도식화하면, 세 당사자 간 관계가 매우 명확해진다:
이 도식에서 가장 정보량이 풍부한 두 선은, FDE가 양쪽으로 전달하는 피드백이다. 고객 쪽으로는, FDE가 모델을 SaaS처럼 판매하는 것이 아니라, 고객의 데이터, 권한, 규정 준수, 내부 시스템을 하나의 통합 파이프라인으로 연결하여 모델이 실제로 작동할 수 있도록 한다. 모델 기업 쪽으로는, FDE가 고객의 실제 고통 포인트와 실패 사례를 product 및 research 팀으로 가져와 로드맵에 영향을 미친다—예를 들어, 반복적으로 오류가 발생하는 tool calling 패턴 하나가 SDK의 다음 내장 추상화로 바뀔 수도 있다.
이것이 바로 FDE가 이번 라운드에서 두 개의 선두 모델 기업에 의해 동시에 재도입된 이유이다. 이는 단순히 ‘우리도 팔란티어처럼 컨설팅을 해야 한다’는 수준을 넘어서는 것이다. FDE는 모델 기업을 위한 ‘신호 감지 장치’이며, 전선에서 가장 밀도 높은 고객의 고통 포인트는 반드시 자신들의 사람이 현장에 있어야만 포착할 수 있다. 파트너사가 번역해 전달하는 요구사항은 언제나 한 단계 이상의 간격이 존재한다. 앤트로픽은 혼합형 전략을 택하고 있다: 한편으로는 자체 FDE를 운영하면서, 다른 한편으로는 컨설팅 기업 및 PE(Private Equity) 거물들과 합작형 배포 네트워크를 구축하고 있다. 하나는 자체 운영 중심이고, 또 하나는 생태계 중심이지만, 그 핵심은 동일하다: 모델 기업은 더 이상 단순한 API 공급자가 아니라, 고객의 제품 속으로 직접 엔지니어를 파견하는 존재가 되어야 한다.
다음으로 해결해야 할 것은 두 가지 가장 흔한 비교 질문이다—FDE와 전통적 컨설팅(맥킨토시, 액센츄어 등)의 경계는 어디인가? 또 우리가 익숙한 소프트웨어 아웃소싱과 FDE는 같은 것인가?
FDE는 맥킨토시가 아니다: 모델 경계 vs. 프로세스 경계
많은 사람이 FDE의 업무 내용을 처음 들었을 때, 가장 먼저 떠오르는 반응은 “이건 새 버전의 맥킨토시나 액센츄어가 아닌가?”이다.
이런 연상은 충분히 이해된다. 정장 차림, 고객 현장 출장, 고객 회의실에서 화이트보드를 그리며 C레벨 임원과 목표를 맞추는 모습—시각적으로 보면, FDE와 컨설팅 컨설턴트는 정말 닮아 있다. 그러나 한 단계 더 깊이 들어가면, 이 둘의 업무 근본 구조는 완전히 다르다. 컨설팅은 ‘프로세스 경계’를 팔고, FDE는 ‘모델 경계’를 판다.
이 둘을 한 표에 나란히 놓으면, 차이는 즉각 드러난다.
이 표에서 특히 주목할 가치가 있는 항목은 ‘자산 감가상각’이다.
전통적 컨설팅의 수익 창출 논리는 자산 재사용에 있다—어떤 은행에 제공한 솔루션을 조금 수정해서 다음 고객에게 재판매하거나, 소매업계 디지털 전환 매뉴얼을 30개 고객사에 반복 적용하는 식이다. 이것이 지난 30년간 액센츄어, 드로이트, 맥킨토시 디지털이 성장해온 기본 경제 모델이다.
FDE는 이런 자산이 없다. 모델 능력은 여전히 급속히 변화하고 있다—오늘은 정교한 프롬프트 체인을 설계해야 하는데, 다음 버전의 모델에서는 한 마디로 해결될 수도 있다. 이 속도 앞에서 컨설팅의 ‘방법론 축적’은 급속히 가치를 잃는다. 따라서 FDE는 자산 재사용 모델을 사용할 수 없고, 매번 클로즈드 루프를 새로 돌려야 한다—모델 경계를 재평가하고, 도구 스택을 재선정하며, 제품 형태를 재구성해야 한다. 겉보기에는 비효율적으로 보이지만, 이는 모델의 속도를 따라잡는 유일한 방법이다.
혹시 아시는가—‘Product Overhang’이란 무엇인가? 필자는 이전 기사 《슈퍼 개별자에게 보내는 글》[4]에서 이 용어를 설명한 바 있다: 모델의 능력이 기존 제품 형태를 이미 초월했으나, 이를 실현하기 위한 제품 진입점, 권한, 컨텍스트가 부족해 현실화되지 못하는 상태를 의미한다. FDE라는 직무의 가치는 본질적으로, 고객의 특정 시나리오에서 ‘공중에 떠 있는’ Overhang을 구체적이고 실행 가능한 제품으로 실현하는 데 있다. 고객이 사는 것은 모델 API 호출 한도가 아니라, “누군가 이 Overhang을 내 비즈니스에 실제로 구현해 줄 수 있는 능력”이다.
이것은 ‘프로젝트 구조’ 항목의 차이를 설명해준다. 컨설팅 프로젝트의 표준 구조는 SOW(Statement of Work)+WBS(Work Breakdown Structure)+단계별 검수이다: 계약서에 무엇을, 언제, 어떤 기준으로 전달할 것인지 명확히 기술한다. 이 구조의 전제는 계약 체결 전에 목표가 이미 명확히 정의되어 있다는 것이다.
FDE 프로젝트는 이러한 구조를 따를 수 없다. 고객이 가장 자주 하는 말은 “AI가 내게 뭔가 도움이 될 것 같긴 한데, 정확히 무엇인지 잘 모르겠다”는 것이다. 즉, 목표 자체가 프로젝트의 일부이다. 따라서 FDE는 SOW를 받지 않고, ‘mission’—즉 상대적으로 모호한 방향성—을 받아들인다. 이후 반복(iteration)을 통해 이 방향성을 점차 명확히 하고, 어느 반복 단계에서 쌓아온 모델 이해를 바탕으로 구체적인 제품 형태로 구현한다.
‘전달물’ 항목 또한 자세히 살펴볼 가치가 있다. FDE가 퇴장한 후 고객 시스템에 남는 것은 실제로 작동하는 기능이다—아마 작을 수도 있고, 보기 좋지 않을 수도 있으며, 사용자 인터페이스조차 없을 수도 있지만, 매일 누군가 호출하고, 수정하고, 비난하는 실시간 활성 기능이다. 컨설팅의 전달물은 PPT와 변화 관리 보고서이며, 프로젝트 내에서 코드를 작성하거나 ERP를 설정했더라도, 최종적으로 고객 고위 임원의 손에 남는 것은 여전히 방법론 문서이다.
‘보호벽’ 항목은 가장 미묘한 차이를 보여준다. FDE의 보호벽은 모델 능력의 경계에 대한 실시간 감각이다—당신이 지난 한 달간 몇 개의 실제 고객 시나리오를 돌렸느냐에 따라, 클로드(Claude) 4.7이 무엇을 할 수 있고, 무엇을 위해 클로드 5를 기다려야 하는지를 당신이 다른 사람들보다 더 정확히 안다. 이 감각은 PPT에 담을 수도, 지식 베이스에 저장할 수도 없으며, 단지 최근 90일간 직접 손을 댄 엔지니어의 두뇌 속에만 형성된다.
따라서 누군가 “FDE는 새 버전의 액센츄어일 뿐”이라고 말한다면, 이렇게 대답할 수 있다: 액센츄어의 엔지니어는 고객의 프로세스를 재설계하러 가는 반면, FDE는 모델의 경계를 재탐색하러 간다. 전자의 자산은 10년간 축적될 수 있으나, 후자의 자산은 90일 후에는 다시 새로 자라야 한다.
FDE는 소프트웨어 아웃소싱이 아니다: 공동 탐색 vs. 요구사항 구현
‘FDE는 새 버전의 액센츄어다’는 오해가 첫 번째 층이라면, ‘FDE는 고가의 소프트웨어 아웃소싱이다’는 오해는 두 번째 층이다. 이 오해는 더 위험한데, 겉보기 증거가 너무나도 풍부하기 때문이다: FDE는 실제로 고객 현장에서 코드를 작성하고, 고객의 비즈니스에 맞춘 기능을 개발하며, 고객의 근무 시간에 따라 조정된다. 겉보기에는 아웃소싱 엔지니어와 전혀 다르지 않아 보인다.
그러나 피드백 루프(feedback loop)를 살펴보면, 이 차이는 숨길 수 없다.
이 도식에서 가장 핵심적인 차이는, 상단 부분이 얼마나 단순한가가 아니라, 하단 부분에 모델 기업으로 향하는 피드백 체인이 추가되었다는 점이다. 이 체인은 장식이 아니라, FDE라는 직무가 존재하는 진정한 이유이다. 이 차이를 자세히 풀어보면, 최소 네 가지 대비가 가능하다.
받는 것이 다르다. 아웃소싱은 SOW—계약 체결 전에 이미 명확히 정의된 요구사항 목록—를 받는다: 어떤 기능을 만들 것인지, 어떤 기술 스택을 사용할 것인지, 어떤 기준으로 검수할 것인지, 위반 시 어떻게 배상할 것인지 등. FDE는 ‘mission’을 받는다—고객 스스로도 무엇을 원하는지 정확히 모르고, 다만 ‘AI가 뭔가 도움이 될 것 같다’는 정도만 알고 있다. SOW는 확정성(determinism)을 전제로 하며, mission은 탐색(exploration)을 전제로 한다. 이 둘은 완전히 다른 프로젝트 시작 자세를 요구한다.
하는 범위가 다르다. 아웃소싱은 국지적 전달—한 모듈, 한 웹사이트, 한 데이터 파이프라인—을 수행하고, 완료 후 패키징하여 떠난다. FDE는 엔드투엔드(end-to-end)—비즈니스 고통 포인트에서 출발하여 모델 선정, 제품 형태 설계, 실제 사용자 유지율(retention) 및 이탈률(churn)까지 책임지는—작업을 수행한다.
청구 방식이 다르다. 이 점은 가장 직관에 어긋나는 부분이다. 모델 기업이 FDE를 고객 현장에 파견할 때, 궁극적으로 관심 있는 것은 단순히 이번 프로젝트에서 얼마의 컨설팅 비용을 받을 것인가가 아니라, 이 고객이 앞으로 얼마나 많은 토큰(token)을 소비할 것인지, 리텐션 고객이 될 것인지, 더 많은 비즈니스 영역으로 확장할 것인지이다. FDE의 진정한 KPI는 프로젝트 검수서에 기재된 숫자가 아니라, 모델 토큰의 장기 소비 곡선이다.
피드백의 향방이 다르다. 이 네 가지 대비 중 가장 심층적인 차이이다. 아웃소싱 프로젝트에서, 고객의 피드백은 아웃소싱 기업에 도달하는 것으로 끝나며, 해당 기업이 다른 고객에게 판매할 미래 제품에 영향을 주지 않는다. 반면 FDE의 피드백은 모델 기업의 로드맵으로 돌아간다—고객이 실제 시나리오에서 겪은 모든 문제, 모든 프롬프트 실패, 모든 도구 호출 버그는 다음 버전의 학습 데이터, 다음 버전의 도구 설계, 다음 버전의 제품 기능에 대한 입력 자료가 된다. 즉, 각 FDE가 배치된 고객은 모델 기업 입장에서 자연스럽게 ‘디자인 파트너(Design Partner)’가 된다.
이것이 바로 모델 기업이 고임금을 지불하고 FDE를 채용하려는 진정한 이유이다. 그들은 단순히 서비스를 팔고 있는 것이 아니라, 고객 현장에서 실제 세계의 제품 형태 신호를 수집하고 있는 것이다. 이러한 신호는 구매할 수도 없고, 수집할 수도 없으며, 설문 조사로도 얻을 수 없다—그것은 오직 구체적인 엔지니어가 구체적인 고객의 업무 흐름 속에서 직접 몇 차례 벽에 부딪힌 후에야 가져올 수 있는 것이다.
혹시 아시는가—오픈AI와 앤트로픽의 FDE 총 보상은 얼마인가? Levels.fyi에 공개된 앤트로픽 소프트웨어 엔지니어 데이터[8]에 따르면, 시니어 SDE의 총 보상 중위값은 이미 $710K에 달한다. FDE는 리스크가 더 높다—모델 능력의 불확실성, 고객 비즈니스의 불확실성, 제품 형태의 불확실성이라는 세 가지 리스크를 동시에 감당해야 하므로, 업계 정리 자료[9]에 따르면, 선두 AI 실험실의 FDE 중·고급 총 보상은 일반적으로 $350K–$550K 수준이며, 스태프(Staff)급 이상은 $630K+까지 도달할 수 있다. 이 금액은 단순히 ‘아웃소싱 근무 시간’에 대한 대가가 아니라, ‘제품 + 고객 + 모델’ 세 가지 리스크를 종합적으로 감당하는 사람에 대한 보상이다. > 2006년, 필자가 사회에 첫발을 내딛었을 때, 한 국영기업에 입사하여 당시 진행 중이던 정보화 전환 사업에 참여하였다. 그 시절 우리 그룹은 액센츄어 컨설턴트를 현장에 상주시키기 위해 하루 3,500위안의 컨설팅 비용을 지불하였고, 그들은 수년간 머물렀으며, 당시 언론에서는 이를 ‘골드칼라(Gold Collar)’라고 불렀다. 이후 필자는 독일 SAP 회사로 이직하였는데, SAP는 컨설팅 산업의 이름조차 정의하였고, SAP 컨설턴트는 ‘골드칼라’의 상징이었다. 이런 관점에서 볼 때, FDE의 급여는 최소 24–36개월 동안 지속적으로 상승할 것이며, 수요 역시 안정적으로 증가할 것이다.
아웃소싱은 노동력 차익거래(labor arbitrage)이지만, FDE는 전선 감지기(frontline sensor)이다. 이 둘을 혼동하면, 고객사는 SOW 방식으로 FDE를 채용할 수 있다고 잘못 판단하게 되고, 후보자 역시 아웃소싱 업무 자세로 FDE를 대하게 된다. 양측 모두 곧바로 벽에 부딪힐 것이다.
해외 FDE의 두 가지 뿌리: 팔란티어와 차세대 모델 기업
많은 사람이 FDE라는 용어가 오픈AI가 창안한 것으로 오해한다. 그러나 사실은 그렇지 않다. FDE는 두 가지 역사적 뿌리를 가지고 있는데, 하나는 팔란티어에서, 또 하나는 2023년 이후 등장한 차세대 모델 기업에서 비롯된 것이다. 이 두 가지 뿌리를 나란히 비교해보면, FDE라는 직무가 진정으로 무엇을 하는지 더 명확히 이해할 수 있다.
먼저, 연대표를 한 장 보자.
첫 번째 뿌리는 팔란티어이다.
팔란티어는 2003년 피터 틸(Peter Thiel), 알렉스 카프(Alex Karp), 조 랜스데일(Joe Lonsdale) 등에 의해 창립되었으며, 초기 고객은 미국 정보기관이었다. 카프 CEO는 CS 전공자가 아니었다—그는 프랑크푸르트에서 철학자 위르겐 하버마스(Jürgen Habermas) 밑에서 박사 과정을 밟았고, 미국으로 돌아온 후 틸에 의해 CEO로 영입되었다. FDE라는 직무는 바로 카프와 같은 ‘비전형 CEO + 고도로 기밀 유지가 필요한 고객’ 조합에서 비롯된 것이다: 36Kr의 회고 기사[10]에 따르면, 팔란티어 초기에는 정보기관으로부터 매우 혹독한 비판을 받았는데, 그 이유는 엔지니어들이 실제 업무 시나리오에 접근할 수 없었고, 요구사항이 여러 차례 전달되면서 왜곡되었기 때문이었다. 이후 팔란티어는 자사 엔지니어를 고객 현장에 직접 파견해 정보 분석가와 함께 업무를 수행하도록 하는 협약을 체결하였다. 이 모델은 이후 쉬암 산카르(Shyam Sankar)에 의해 체계화되어 FDE의 원형이 되었다.
2009년에는 FDE가 상업 분야로 확장되었다. JP모건이 팔란티어의 메트로폴리스(Metropolis) 플랫폼을 도입할 때, 120명의 FDE가 내부 위협 감시 업무를 위해 현장에 투입되었다. 이때부터 FDE는 단순히 ‘엔지니어를 출장 보낸다’는 수준을 넘어, 고객에게 깊이 침투하는 체계적인 전략이 되었다: 파운드리(Foundry)/고담(Gotham)을 단순히 라이선스만 제공하는 것이 아니라, 고객의 실제 업무 흐름 속에 진정으로 작동하도록 하는 것이다.
팔란티어의 FDE 채용에는 반직관적인 기준이 하나 있다—CS 학위를 요구하지 않는다. 이것을 ‘혹시 아시는가’ 섹션에 넣을 수 있다.
혹시 아시는가—팔란티어 FDE는 CS 학위를 요구하지 않는다? SkillScouter가 정리한 팔란티어 채용 기준[11]과 팔란티어 공식 채용 페이지[12]에 따르면, 팔란티어은 명시적으로 CS 전공이 아닌 지원자를 환영하며, 최근 채용된 FDE는 기계공학, 경제학, 철학 등 다양한 전공 출신이다. 팔란티어이 진정으로 엄격히 평가하는 두 가지 요소는: 불완전한 정보 속에서도 행동할 수 있는 능력, 그리고 C레벨 고객과 직접 대화할 수 있는 능력이다. CS 학위는 가산점일 뿐, 진입 자격이 아니다. 카프 본인은 이 기준의 최초 사례이기도 하다—철학 전공 CEO가 물리학, 수학, 철학 전공의 FDE들을 이끌었다.
두 번째 뿌리는 2023년 이후 등장한 차세대 모델 기업이다.
챗GPT가 2022년 말 출시된 후, 오픈AI는 곧바로 한 가지 사실을 깨달았다: 모델 API를 문서에 나열해놓고 고객이 스스로 연결하라고 하는 방식은 전혀 통하지 않는다는 것이다. 고객은 사용하고 싶지 않은 것이 아니라, 어떻게 사용해야 할지 모를 뿐이다—그들에게는 비즈니스 문제가 있지만, 이를 해결할 제품 형태가 없다. 그래서 오픈AI, 앤트로픽, 코히어(Cohere), 스케일(Scale), 글린(Glean), 시에라(Sierra), 헤비아(Hebbia), 데카곤(Decagon) 등 일련의 기업들이 대규모로 FDE를 채용하기 시작하였다.
이 새로운 세대의 FDE는 팔란티어의 플레이북을 그대로 학습하였다—엔지니어를 고객 현장에 파견하여 엔드투엔드로 하나의 워크플로우를 완전히 구동시키는 것이다. 그러나 제품의 실체는 완전히 달라졌다: 팔란티어 시대의 FDE는 데이터 통합과 UI 맞춤화를 담당했고, 새로운 세대의 FDE는 프롬프트 설계, 에이전트 오케스트레이션, 도구 호출, 워크플로우 내재화를 담당한다.
프래그매틱 엔지니어(Pragmatic Engineer)의 FDE 관련 특별 기사[13]에서는 이 새로운 버전을 “클로드가 실제의, 구체적인, 고가치 문제를 해결하도록 기업 내부에 배치되는 것(embedded with enterprises to make Claude solve real, specific, high-value problems)”이라고 표현하였다—이 표현은 팔란티어 시대와 거의 동일하지만, 단지 ‘데이터’가 ‘모델’로 바뀐 것뿐이다.
이 두 가지 뿌리를 나란히 놓고 보면, 매우 명확한 공통점과 차이점을 확인할 수 있다.
공통점: 고객이 사는 것은 소프트웨어가 아니다. 고객이 사는 것은 ‘내 문제를 해결해줄 수 있는 엔지니어 + 도구 조합’이다. 이것은 지난 30년간 기업 소프트웨어 역사에서 오히려 이례적인 현상이다. SAP, 오라클(Oracle), 세일즈포스(Salesforce)는 소프트웨어 자체를 팔았다—엔지니어는 ‘고객이 이 소프트웨어를 사용할 수 있도록 돕는’ 보조 자원이었다. 반면 팔란티어는 정반대였다: 도구는 ‘FDE가 고객 현장에서 문제를 해결할 수 있도록 돕는’ 레버일 뿐이다. 차세대 모델 기업은 이 역전된 관계를 계승하였다—오픈AI는 GPT-4 라이선스를 파는 것이 아니라, “우리 FDE가 GPT-4를 이용해 고객의 고객센터 자동화를 실제로 구동시켜 드리겠습니다”를 파는 것이다.
차이점: 팔란티어 시대는 OPS 통합에 치중—핵심은 데이터 통합, 온톨로지 모델링, 권한 관리였다. 차세대는 모델 능력의 실제 적용에 치중—핵심은 프롬프트 설계, 에이전트 오케스트레이션, 리텐션 최적화였다. 전자는 시스템 통합업체의 고도화된 버전이며, 후자는 제품 엔지니어의 확장된 버전이다.
마지막으로 흥미로운 사실 하나: 팔란티어 초기 FDE 중 많은 이들이 이후 창업가가 되거나, 바로 차세대 모델 기업에 합류하였다. 앤트로픽, 오픈AI, 시에라, 헤비아의 초기 팀에는 ex-팔란티어 이름을 수없이 열거할 수 있다. 이는 우연이 아니다—FDE라는 직무 자체가 제품 리스크, 고객 리스크, 엔지니어링 리스크를 동시에 감당하도록 강제하기 때문에, 이는 거의 창업가를 위한 훈련 과정과 같다. 필자는 팔란티어를 ‘숨겨진 창업 훈련 캠프’로 보는 편이다: 그것이 양성한 것은 단순한 엔지니어가 아니라, 불완전한 정보 속에서도 무에서 유를 창출해내는 일을 추진할 줄 아는 사람들을 양성한 것이다. 두 가지 뿌리는 결국 2023년 이후 합류하였다.
국내 FDE: 솔루션 아키텍처 전문가에서 AI 도입 엔지니어로
이 두 가지 뿌리의 합류는 주로 해외에서 일어났다. 국내에서는 FDE라는 용어가 등장한 지는 그리 오래되지 않았지만, 이에 대응하는 업무 내용은 갑작스럽게 나타난 것이 아니다. 국내 FDE를 이해하려면, 먼저 그 두 가지 국내 전신을 분명히 알아야 하고, 또 미국식 FDE와의 세 가지 ‘풍토적 차이’를 분명히 인식해야 한다.
두 가지 국내 전신
첫 번째 전신은 클라우드 벤더의 솔루션 아키텍처 전문가(Solution Architect, SA)이다. 알리바바 클라우드, 텐센트 클라우드, 화웨이 클라우드는 지난 10년간 고객에게 아키텍처를 설명하고, PoC(Proof of Concept)를 작성하며, 마이그레이션 계획을 수립하고, 구축 및 상용화까지 지원하는 일련의 솔루션 아키텍처 전문가 팀을 육성해왔다. 화웨이는 내부에 ‘구축 엔지니어(Delivery Engineer)’라는 별도 직렬을 두어 프로젝트를 고객 데이터센터에 실제로 설치하는 업무를 담당한다. 이 체계는 이미 FDE 업무의 80%를 수행하고 있으나, 중심은 여전히 프리세일즈 및 구축에 있다—엔드투엔드 제품 반복 개발 책임은 SA에게 있지 않으며, 요구사항 변경은 변경 관리 절차를 따라야 하고, 모델 업데이트는 본사의 일정에 따라야 한다.
두 번째 전신은 AI 스타트업에서 새로 등장한 직무이다. 미니맥스(MiniMax)는 BOSS 직聘에 ‘AI 프리세일즈 솔루션 전문가’를 채용 공고로 올렸고, 문월(月之暗面), 지푸(智谱), 통의(通义), 혼위안(混元) 등 모델 기업들도 유사한 직무를 공고로 내걸고 있다. 이름은 약간 다르지만, 채용 공고(Job Description) 내용은 고도로 유사하다: 고객 시나리오를 이해하고, 데모를 만들고, 프롬프트를 조정하고, RAG(Retrieval-Augmented Generation)를 실행하고, 구축 계획을 작성하며, 고객 엔지니어링 팀과 협력하여 상용화까지 이끈다. 이 직무군이야말로 진정한 의미의 ‘국내 FDE’라 할 수 있다.
세 가지 풍토적 차이
사설화 배포 + 데이터 규정 준수가 순수 모델 호출 모델을 압도한다. 국내 B2B 고객은 데이터의 외부 유출 금지, 모델 가중치의 통제 가능성, 감사 추적 가능성에 대한 요구가 미국 시장보다 훨씬 높다. FDE 프로젝트에서 순수 API 호출 및 프롬프트 실행 작업량은 전체의 30%에 불과할 수 있고, 나머지 70%는 모델을 고객 데이터센터로 이전하고, 인증 절차를 통과하며, 데이터 중앙 플랫폼과 연동하고, 규정 준수를 위한 사전 신고 절차를 수행하는 것이다.
모델 능력이 여전히 SOTA(State-of-the-Art)를 따라가고 있어, 발휘 공간이 엔지니어링 레이어로 압축된다. 미국의 오픈AI, 앤트로픽은 모델 능력 자체로 고객을 설득할 수 있다. 반면 중국의 통의, 도우바오(豆包), 킴이(Kimi), GLM, 딥시크(DeepSeek)는 능력 차별화가 크지 않아, 고객의 판단 기준은 에이전트 오케스트레이션, RAG 검색 품질, 도구 통합, 워크플로우 설계 등 엔지니어링 역량에 더 많이 집중된다. 국내 FDE는 ‘우리 모델이 얼마나 강한가’를 경쟁하지 않고, ‘내가 이 비즈니스를 실제로 구동시킬 수 있는가’를 경쟁한다.
B2B 고객의 지불 의사 및 가격 책정 리듬이 미국과 일치하지 않는다. 팔란티어식 ‘먼저 FDE를 현장에 파견하고, 이후 고가의 구독료를 받는’ 모델은 국내에 직접적으로 복제하기 어렵다. 국내 고객의 예산은 연간 구매 계획에 따라 움직이며, 지불 방식은 프로젝트 기반에 치우쳐 있고, FDE의 상업 모델은 종종 구독 + 사설화 라이선스 + 프로젝트 구축의 혼합 형태로 구성된다.
독특한 포지셔닝: 내부 FDE
많은 대기업 내부 AI 팀은 이제 ‘내부 고객’을 대상으로 FDE 모드를 활용하고 있다. 알리바바 클라우드 PAI는 엔지니어를 타오바오에 파견하고, 텐센트 혼위안도 유사한 메커니즘을 통해 웨이신(WeChat), 광고 사업부와 협업하고 있다. 채용 공고에서는 ‘산업 현장 적용 엔지니어’, ‘AI 애플리케이션 엔지니어’, ‘지능화 비즈니스 전문가’ 등으로 표기되지만, 본질적으로는 내부 FDE—즉, 모델 팀의 역량을 엔드투엔드로 비즈니스 측에 전달하는 역할—이다. 이는 대기업 리더들에게 새로운 통찰을 제공한다: 몇 명의 내부 FDE가 비즈니스 측에 상주하며 첫 번째 데모를 구동시키고, ROI 데이터를 비즈니스 담당 임원에게 제출하면, 부서 벽은 10차례의 정렬 회의보다 훨씬 빠르게 사라질 수 있다.
누가 FDE에 적합한가, 누가 부적합한가
필자는 이전 기사 《슈퍼 개별자에게 보내는 글》[4]에서 슈퍼 개별자의 다섯 가지 ‘엔진’—호기심 강함, 탐색 및 혁신 정신 강함, 자율 학습 능력 강함, 자기 주도성 강함, 실천 능력 강함—에 대해 논한 바 있다. 이 다섯 가지는 FDE의 입문 자격증이지만, 전부는 아니다. FDE는 이 다섯 가지 엔진 외에도 매우 구체적인 추가 특성을 요구하며, 또 명확히 부적합한 인격 유형도 존재한다. 필자는 우수한 엔지니어들이 FDE로 전환한 후 적응하지 못하는 경우를 수없이 보았고, 그 문제는 대부분 능력이 아니라 성격과 업무 선호도에서 비롯된다.
FDE에 적합한 다섯 가지 특성
영업 및 커뮤니케이션을 거부하지 않음. FDE의 일상은 문을 닫고 코드를 쓰는 것이 아니라, 고객의 CTO, 비즈니스 책임자, 조달 담당자, 규정 준수 담당자, IT 담당자와 직접 소통하는 것이다. 전형적인 리듬은 다음과 같다: 고객 CTO가 데모 도중 당신을 끊고 질문한다. 이때 FDE의 반응은 “다음 주에 다시 찾아오겠습니다”가 아니라, 즉시 IDE를 열어 프롬프트를 수정하고 다시 실행해 보여주는 것이다. “고객이 현장에 있고, 나는 그 자리에서 수정한다”는 것이 FDE의 평범한 일상이다.
모호한 영역을 즐김. FDE는 명확한 PRD(Product Requirement Document)가 아니라, “우리는 AI로 뭔가를 해보고 싶습니다”라는 한 마디를 받는다. 고객 스스로도 무엇을 원하는지 명확히 말하지 못하고, FDE가 그 모호한 기대를 구체적인 형태로 성장시켜야 한다. 만약 당신이 명확한 요구사항이 있을 때만 움직일 수 있다면, FDE는 매일 당신을 불안하게 만들 것이다.
엔지니어링 역량이 탄탄하되, 10배의 성과를 요구하지 않음. FDE는 당신이 회사 내에서 코드가 가장 깔끔하거나 알고리즘이 가장 깊은 사람이 되기를 요구하지 않는다. FDE가 요구하는 것은 엔드투엔드로 구동 가능한 능력이다: 프론트엔드는 클릭 가능한 페이지를 대충 만들어도 되고, 백엔드는 작동 가능한 서비스를 구축할 수 있어야 하며, 모델은 비즈니스 데이터 소스와 연결되어야 한다. FDE의 세계에서는 “대충 되면 됨”이 결점이 아니라, 덕목이다.
피드백을 통한 개선을 즐김. FDE의 업무에는 ‘고객에게 욕먹고 다시 해야 하는’ 순간이 많다: 오늘의 데모가 내일 비즈니스 담당자로부터 “이게 제가 원한 게 아닙니다”라고 평가받을 수 있고, 지난주에 합의한 방안이 이번 주에 고객의 고위 임원이 바뀌면서 다시 처음부터 해야 할 수도 있다. FDE에 적합한 사람은 이런 피드백을 연료로 삼으며, 엔드투엔드 책임을 감당할 수 있고, “요구사항을 제대로 설명하지 않았다”는 식으로 책임을 전가하지 않는다.
모델 경계에 민감함. 이것은 가장 기술적이면서도 가장 은닉된 특성이다. FDE는 어떤 작업은 LLM이 수행하는 것이 적합하고, 어떤 작업은 그렇지 않으며, 어떻게 fallback 해야 하는지를 판단할 수 있어야 한다—이 민감도는 논문을 읽는 것으로는 얻을 수 없고, 실패 사례를 직접 경험해야만 형성된다. 실패 사례가 쌓이면, FDE는 모델 경계에 대한 ‘근육 기억(muscle memory)’을 갖게 된다: 어떤 시나리오에서는 RAG를 사용해야 하고, 어떤 시나리오에서는 규칙 기반 처리가 필요하며, 어떤 시나리오에서는 반드시 인간이 fallback할 수 있는 인터페이스를 제공해야 한다.
FDE에 부적합한 네 가지 유형
코드 속에 숨고 싶어 하는 순수 기술주의자. FDE의 약 50% 시간은 코드 작성에 쓰이지 않는다—고객 회의, 내부 조율, 제품 토론, 계약 진척 등에 사용된다. 만약 당신의 기쁨이 4시간 연속 방해받지 않고 코드를 쓰는 데서 오는 것이라면, FDE는 당신을 장기간 정신적 고갈 상태에 놓이게 할 것이다.
OKR이 있어야 움직일 수 있는 사람. FDE의 목표는 당신의 성과표에 있지 않고, 고객에게 있다. 업무 진척은 고객의 프로젝트 마일스톤, 모델의 능력 변화, 당신의 시나리오 판단 등에 의해 공동 결정된다. “먼저 OKR이 있어야 무엇을 해야 할지 알 수 있다”는 습관을 가진 사람은 기준점을 잃게 될 것이다.
‘승진’을 ‘작품’보다 더 중시하는 사람. FDE는 대기업의 승진 체계에서 유리하지 않다—고객 만족도, 프로젝트 계약, 재사용률 등 지표는 코드량이나 상용화 빈도에 비해 직급 심사에서 설득력이 떨어진다. 만약 당신의 업무 동기에서 승진이 가장 우선순위라면, FDE는 좋은 선택이 아니다.
비즈니스 맥락을 거부하는 사람. FDE는 반드시 고객의 손익계산서(P&L), 투자수익률(ROI), 조달 프로세스, 규정 준수 요구사항을 이해해야 한다. 만약 당신이 돈, 계약, 비즈니스 논리에 대해 본능적으로 거부감을 느낀다면, FDE 업무는 당신이 자신의 기술적 이상을 팔고 있다고 느끼게 할 것이다.
Self-Check 체크리스트
7개의 질문으로, 각각 FDE의 실제 업무 시나리오를 반영하였다. 5개 이상에 ‘예’라고 대답한다면 FDE를 진지하게 고려해볼 수 있고, 3개 이하라면 신중히 생각해보는 것을 권장한다.
1. 당신은 매일 50%의 시간을 코드에서 고객 회의, 메시지 응답, 전화 통화로 옮기는 데 동의할 수 있는가?
2. 고객이 “이건 안 되는데, 왜 안 되는지도 잘 모르겠어요”라고 말할 때, 당신의 첫 반응은 호기심인가, 아니면 성급함인가?
3. 아무도 PRD를 써주지 않더라도, 당신은 클로드 코드(Claude Code)와 함께 일주일 내에 고객에게 보여줄 수 있는 프로토타입을 구동시킬 수 있는가?
4. 동일한 전달물에 대해 고객이 8개 버전을 요청해도, 당신은 기계적인 실행이 아니라 판단력을 유지할 수 있는가?
5. 모델이 잘못된 답변을 줄 때, 당신의 첫 반응은 fallback을 설계하는 것인가, 아니면 모델이 못한다고 불평하는 것인가?
6. 당신은 계약 체결, 보고서 작성, 고객 검수, 법무팀과의 규정 준수 조항 협의를 기꺼이 수행할 수 있는가?
7. 당신은 빠른 프로토타이핑과 빠른 실패를 수용할 수 있는가?
다섯 가지 특성, 네 가지 반대 유형, 일곱 가지 자가 진단 질문—결국은 하나의 질문으로 귀결된다: 당신은 자신의 제품 감각, 엔지니어링 역량, 비즈니스 판단력이라는 세 가지 능력을 하나의 업무 흐름 속에서 동시에 연마할 준비가 되어 있는가?
결론: 슈퍼 개별자에서 슈퍼 직무로
필자는 이전 기사에서 ‘인간의 엔진’—호기심, 탐색 정신, 자율 학습 능력, 자기 주도성, 실천 능력—이 대기업 내부에서 어떻게 완전한 클로즈드 루프를 통해 발현되는지를 논하였다. 본 기사는 또 다른 주제를 다룬다—직무 형태. FDE는 AI 산업 혁명에서 첫 번째로 이름을 얻고, 급여대를 설정받고, 채용 공고에 명시되며, 고객의 실제 지불로 검증된 새로운 직무 형태이다. FDE는 ‘슈퍼 개별자’ 개념의 동의어가 아니라, 이 일련의 재구성 과정에서 ‘허상에서 현실로’ 첫 번째로 구체화된 좌표이다.
FDE는 종착점이 아니다. 필자의 판단에 따르면, FDE는 새로운 분업 구조에서 이름을 얻은 첫 번째 형태일 뿐이다. 향후에는 Forward Deployed PM, Forward Deployed Designer, Forward Deployed Researcher 등—고객 시나리오와 긴밀히 결합되어, 모호한 영역에서 제품을 만들어내야 하는 모든 직무가 각자의 ‘선제 배치(Forward Deployed)’ 버전을 갖게 될 것이다. 직무 이름은 바뀔 수 있지만, 그 근본 논리는 동일하다: 모델 능력이 앞서 가고, 제품 형태가 뒤따르며, 직무 구조는 업무 흐름에 따라 다시 재편된다.
세 부류의 독자에게 각각 한 마디를 남긴다.
기술자에게: FDE는 당신이 회사에서 코드를 가장 잘 쓰는 사람이 되기를 요구하지 않지만, 당신이 하루의 절반을 코드에서 고객 쪽으로 옮기려는 의지를 요구한다. 만약 당신의 대답이 ‘예’라면, 시장 창구가 막 열렸으며, 국내 선두 모델 기업, 클라우드 벤더, 대기업 내부 AI 팀의 채용이 가속화되고 있다. 만약 당신의 대답이 ‘아니오’라면, 그 역시 문제가 없다. 새로운 분업 구조 속에는 당신을 위한 또 다른 자리를 계속 만들어낼 것이다.
HR 및 OD(조직 개발) 담당자에게: ‘명실상부(名實相副)’를 경계하라. 당신의 회사에는 이미 FDE 역할을 수행하는 인력이 존재할 수 있으며, 다만 직무 코드는 ‘솔루션 전문가’, ‘산업 아키텍처 전문가’, ‘AI 애플리케이션 엔지니어’로 표기되어 있을 뿐이다. 이들을 식별하고, 재분류하며, 실제 업무 내용에 부합하는 성장 경로를 제공하는 것이, 신입을 0에서 채용하는 것보다 훨씬 효율적이다.
관리자에게: FDE 모드는 외부뿐 아니라 내부에도 적용 가능하다. 회사 내부에 몇 명의 ‘내부 FDE’를 배치하여 비즈니스 측에 상주시키고, 모델 팀의 역량을 엔드투엔드로 비즈니스 프로세스에 전달하는 것이, 새로운 AI 부서를 신설하고 10차례의 크로스팀 정렬 회의를 여는 것보다 훨씬 효과적일 수 있다. 부서 벽은 조직 설계로 해소되는 것이 아니라, 실제로 구동 가능한 데모 하나로 해소되는 것이다.
AI 시대의 직업 전환이 이미 시작되었다. FDE는 그 첫 번째 신호탄이며, 이는 모델 능력의 변화 속도가 이미 새로운 직무를 강제로 창출할 정도로 빨라졌음을 알려준다. 필자는 독자에게 하나의 구체적인 질문을 남기고 싶다—만약 3년 후 당신의 회사 조직도에 세 개의 새로운 직무가 추가된다면, 그것이 어떤 세 가지 직무일 것 같습니까? 이 질문에 대해 생각해보는 것이, 이 기사를 읽는 것보다 훨씬 유용할
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
