전방으로 배치된 엔지니어
요즘 누군가 무슨 일을 하느냐고 물으면 예전만큼 한마디로 답하기가 어렵다.
오랫동안 우리는 일을 잘게 나눠 왔다. 프론트엔드와 백엔드를 가르고, 기획과 디자인과 개발을 가르고, 그 안에서 또 잘게 갈랐다. 경계를 나눌수록 한 사람이 한 우물을 깊게 팔 수 있었기 때문이다. 깊이는 분업의 보상이었다.
그런데 그 보상을 이제는 다른 방식으로도 손에 넣을 수 있게 됐다. 내가 깊게 파지 않은 우물의 물을, 도구에게 길어오게 하는 것이다. 백엔드를 깊이 모르는 사람이 그럭저럭 쓸 만한 서버 코드를 짓고, 디자인을 배운 적 없는 사람이 멀쩡한 화면을 그린다. 그러자 경계를 유지하는 비용이, 경계를 허무는 이득보다 비싸지기 시작했다. 한 사람이 더 넓은 폭의 일을 혼자 끌고 가는 편이 외려 효율적인 시대가 된 것이다.
나부터가 그렇다. 프론트엔드를 본업으로 삼아 왔지만 요즘은 코틀린과 스프링 부트로 짜인 서버 코드를 열어 고치고, 테이블 구조를 바꾸는 DDL을 쓰고, 쌓인 데이터를 메우는 백필(backfill) 전략을 고민한다. 얼마 전까지만 해도 내 영역이라 여기지 않던 일들이다. 깊이 알아서가 아니라 모르는 만큼을 도구에 기대어 건너가고 있다. 한 사람이 감당하는 일의 폭이 나도 모르는 새 부쩍 넓어졌다.
그리고 경계가 흐려지면 그제야 비로소 드러나는 물음이 있다. 그래서 정말 값진 일은 어디에 있었나. 직무를 나누던 선이 옅어지는 동안, 그 물음 위에서 조용히 번지고 있는 직군이 하나 있다.
전방으로 배치된 엔지니어
전방 배치 엔지니어(Forward Deployed Engineer), 줄여서 FDE라 부르는 자리다.
이름부터 군대에서 왔다. '전방 배치(forward deployed)'란 본국의 안전한 기지가 아니라 분쟁이 벌어질 수 있는 최전선 가까이에 병력을 미리 가져다 두는 것을 가리키는 말이다(Forward-basing, Wikipedia). 후방에서 완성품을 보내는 대신 일이 벌어지는 바로 그 자리에 사람을 가져다 둔다는 뜻이다.
이 말을 소프트웨어에 처음 끌어다 쓴 곳은 팔란티어(Palantir)다. 팔란티어는 자사 엔지니어를 두 갈래로 나눠 불렀다. 본진에서 제품 자체를 만드는 쪽을 '데브(Dev)', 고객의 현장에 직접 들어가 그 제품을 고객의 문제에 맞춰 깎아내는 쪽을 '델타(Delta)'라 했다(Palantir, 2019). 한쪽이 여러 고객이 두루 쓸 하나의 기능을 만든다면, 다른 한쪽은 한 고객을 위해 여러 기능을 엮어내는 일을 한다. FDE는 후자다.
말이 거창하지, 실제로 이들이 일한 곳은 책상 앞이 아니었다. 초기 팔란티어의 FDE들은 아프가니스탄의 군 기지와 미국 중서부의 공장까지 직접 찾아가 플랫폼을 설치했다(Palantir S-1, 2020). 문제가 살아 숨 쉬는 현장이 곧 그들의 작업실이었다.
이렇게까지 한 데에는 이유가 있다. 정말 어려운 문제는 말끔한 요구사항으로 정리되어 건네지지 않는다. 팔란티어의 초기 고객이던 정보기관은 자신들이 무엇을 원하는지조차 또렷이 말해주지 못하는 경우가 많았다. 그러니 엔지니어가 그들 곁에 서서 문제를 함께 겪으며 알아내는 수밖에 없었다(Reflections on Palantir, 2024). FDE라는 자리는 처음부터, 정의되지 않은 문제를 향해 사람을 먼저 보내는 일이었다.
그들이 실제로 하는 일
그렇다면 FDE는 현장에서 정확히 무엇을 할까.
가장 흔한 오해는 이들을 고객을 상대하는 영업쯤으로 여기는 것이다. 하지만 FDE는 데모를 돌리고 계약을 따내는 사람이 아니다. 공고 1,000여 건을 분석한 자료를 보면, 영업 할당량(quota)을 진 자리는 사실상 한 곳도 없었다(bloomberry, 2025). 이들은 고객사의 환경 안에서 실제로 돌아가는 코드를 쓴다. 커밋 권한을 쥐고, 장애가 나면 호출을 받고, 배포가 끝난 뒤에도 그 시스템을 책임진다. 일이 끝났다는 기준부터가 '머지된 PR'이 아니라 '서비스가 실제로 켜진 날'이다.
그래서 일과의 상당 부분이 책상 밖에서 흘러간다. 회사마다 다르지만 근무 시간의 4분의 1에서 절반가량을 고객의 현장에서 보낸다(The Pragmatic Engineer, 2025). 어떤 FDE는 첫 임지로 1년간 툴루즈의 항공기 공장에 들어가 주 나흘을 제조 현장 사람들 옆에 붙어 일했다(Reflections on Palantir, 2024). 코드를 짜는 시간이 가장 큰 덩어리이긴 해도 보통 한 주의 절반을 넘지 않는다. 나머지는 고객의 업무를 들여다보고, 문제의 범위를 정하고, 무엇을 만들지 합의하는 데 쓰인다.
여기서 컨설턴트와 갈린다. 컨설턴트는 보고서를 남기고 떠나지만, FDE는 돌아가는 코드를 남기고 그 자리에 머문다. 첫날 문제의 지도를 그린 사람이 반년 뒤 그것이 고장 났을 때 호출받는 바로 그 사람이다. 그리고 현장에서 부딪히며 알아낸 것을 본진의 제품팀으로 실어 나른다. 한 고객을 위해 급히 엮어낸 해법에서 되풀이되는 패턴이 보이면 그것이 다음 제품의 정식 기능이 된다. 말하자면 이들의 현장 작업은 비용이 아니라 일종의 R&D다(Barry, 2024).
코드는 그 일의 한 수단일 뿐이다.
왜 지금, 이 자리가 다시 붐비는가
한동안 팔란티어 바깥에선 잘 들리지 않던 이 직군이, 요즘 갑자기 다시 붐비기 시작했다. 그것도 다름 아닌 AI 회사들에서.
이유는 의외로 단순하다. 모델의 성능은 더 이상 가장 큰 병목이 아니다. 병목은 그 뛰어난 모델을 저마다 사정이 다르고 규제로 얽힌 현실의 업무 한복판에 실제로 꽂아 넣는 '마지막 한 구간'에 있다.
"엔터프라이즈가 AI를 산다는 건, 할머니가 아이폰을 손에 쥐는 것과 비슷하다. 쓰고 싶은 마음이야 굴뚝같지만, 누군가 옆에서 처음 세팅을 해줘야 한다."
— a16z, 2025 (Services-Led Growth)
실제로 기업의 생성형 AI 파일럿 가운데 95%가 이렇다 할 성과로 이어지지 못했다는 MIT의 조사가 한동안 회자됐다(The New Stack, 2025). 모델이 모자라서가 아니다. 모델은 멀쩡한데, 그것을 현장에 앉히는 일에서 어긋난 것이다.
전에 나는 도구가 세상의 평균은 알아도 '여기'는 모른다고 적은 적이 있다. 이 회사의 사정, 이 업계의 규칙, 이 조직의 정치를 읽어내는 일은 여전히 사람의 몫이다. FDE는 바로 그 '여기'를 메우러, 고객의 현장으로 걸어 들어가는 자리다.
그래서 프런티어 AI 기업들이 앞다투어 이 사람들을 뽑는다. OpenAI는 도시마다 FDE 조직을 두었고, 2026년 5월에는 아예 기업 현장 배치만 전담하는 'OpenAI Deployment Company'를 40억 달러 규모로 세우며 응용 AI 기업 한 곳을 통째로 사들였다(OpenAI, 2026). 앤트로픽 역시 'Forward Deployed Engineer, Applied AI'라는 이름으로 사람을 뽑으면서, 엔지니어를 고객사 안에 심는 15억 달러 규모의 합작 법인을 따로 띄웠다(Anthropic, 2026).
채용 공고로 보면 흐름이 더 선명하다. 집계 기관마다 기준이 달라 숫자는 들쭉날쭉하다 — 전년 대비 수백 퍼센트가 늘었다는 집계가 있는가 하면(a16z, 2026), 링크드인 기준 2년 사이 40배 가까이 불었다는 분석도 있다(Computerworld, 2026). 척도는 제각각이어도 가리키는 방향은 하나다. 가파르게, 늘고 있다.
그래서, 무엇을 갖춰야 하는가
공고들이 늘어놓는 기술 목록은 어찌 보면 평범하다. 파이썬을 중심에 두고 클라우드와 LLM·에이전트 경험을 얹는 식이다(bloomberry, 2025). 하지만 정작 사람을 가르는 자리는 거기가 아니다.
되풀이해 등장하는 조건은 코드 바깥에 있다. 모호함을 견디는 힘, 고객과 마주 앉아 대화하는 능력, 그리고 무엇보다 — 문제에 곧장 달려들지 않고 먼저 문제의 윤곽부터 그려내는 습관이다. 팔란티어식 면접에서 가장 흔한 탈락 사유가 '범위를 정하기도 전에 답부터 내놓는 것'이라는 이야기는 그래서 의미심장하다(Exponent, 2026).
채용하는 쪽이 즐겨 드는 이상적인 후보가 하나 있다. 스타트업의 첫 열 명 안에 들었던 엔지니어다(The Pragmatic Engineer, 2025). 정해진 일이 없는 곳에서 무엇을 해야 하는지부터 스스로 정해 끝까지 굴려본 사람. 결국 이들이 찾는 건 특정 기술 스택이 아니라 그런 태도에 가깝다.
값이 옮겨가는 자리
여기까지 따라오다 보면 한 가지 그림이 떠오른다. FDE라는 자리가 새삼 비싸진 건, 그들이 코드를 더 잘 짜서가 아니다. 문제가 살아 있는 곳에 가장 가까이 서 있기 때문이다.
나는 요즘 문제를 푸는 일의 값은 점점 내려가고 문제를 찾고 정의하는 일의 값은 외려 오른다고 생각한다. 도구가 푸는 쪽을 통째로 떠맡을수록, 사람에게 남는 값은 무엇을 풀 것인가를 가려내는 쪽으로 옮겨간다. FDE는 한 조직이 그 이동에 걸어둔 베팅이다. 가장 값나가는 일이 이제 책상이 아니라 현장에, 푸는 쪽이 아니라 찾는 쪽에 있다는 베팅.
전에 나는 일의 무게중심이 만드는 쪽에서 판단하는 쪽으로 넘어간다고 적었다. FDE는 그 무게중심이 회사 바깥, 문제의 현장에까지 닿은 모습인 셈이다.
그렇다면 나는 지금 당장 무엇을 해야 하는가.
꼭 FDE라는 이름표가 답은 아닐 것이다. 중요한 건 그 이름이 가리키는 방향이다. 깔끔한 요구사항이 책상에 도착하기를 기다리는 대신 문제가 아직 엉켜 있는 곳으로 먼저 걸어 들어가는 일. 푸는 법을 익히는 데 쏟던 시간의 얼마간을 무엇을 풀지 가려내는 데로 옮겨보는 일.
당장 또렷한 답이 있는 건 아니다. 다만 값이 어디로 옮겨가는지는 어렴풋이 보이고, 그 방향을 가늠해보는 일이 요즘은 꽤 흥미롭다.
