FDE는 상주 파견과 무엇이 다를까? 팔란티어식 현장 배치 엔지니어

Projects often start with an open ended question like "Why are we delaying so many flights?" or "How can we better identify instances of money laundering?"

팔란티어의 Forward Deployed Software Engineer 채용 공고에 있는 문장입니다. 「왜 비행기 지연이 이렇게 많은가」, 「자금 세탁을 어떻게 더 잘 찾아낼 것인가」. 개발자에게 주는 일감이 기능 목록이 아니라 질문입니다.

FDE(Forward Deployed Engineer)라는 말이 요즘 다시 자주 보입니다. AI 회사들이 이 직무를 뽑기 시작하면서입니다. 그런데 한국에서 이 말을 처음 들으면 대개 한 가지가 먼저 떠오릅니다. 고객사에 개발자를 보내 상주시키는 일, SI의 상주 파견입니다.

FDE를 상주 파견의 새 이름으로 읽을 때 놓치는 것

겉으로 보면 둘은 같습니다. 개발자가 고객 회사에 가서, 고객 옆에서, 고객의 시스템을 만듭니다. 그래서 FDE를 「미국식으로 포장한 파견」으로 이해하는 것도 무리는 아닙니다.

이 이해로는 설명되지 않는 것이 있습니다. 팔란티어는 FDE를 외주 인력이 아니라 자기 회사의 정식 엔지니어 직무로 뽑고, 공고에서 그 역할을 이렇게 씁니다.

As an FDSE, your responsibilities look similar to those of a startup CTO: you'll work in small teams with minimal supervision and own end-to-end execution of high stakes projects.

파견 개발자에게 「스타트업 CTO와 비슷한 책임」을 기대하는 회사는 없습니다. 파견은 정해진 일을 정해진 기간 동안 하는 계약이고, 무엇을 만들지는 고객사가 정합니다. 둘이 같은 일이라면 이 문장이 나올 이유가 없습니다.

질문에서 시작하는 일과 명세에서 시작하는 일

제가 보기에 둘을 가르는 첫 번째 차이는 일이 어디서 시작하느냐입니다. 상주 파견은 명세에서 시작합니다. 요구사항 정의서가 있고, 화면 목록이 있고, 개발자는 그것을 만듭니다. 명세가 틀렸다면 그건 명세를 쓴 쪽의 문제입니다.

FDE는 위 공고의 문장처럼 질문에서 시작합니다. 「비행기 지연이 왜 많은가」에는 명세가 없습니다. 어떤 데이터를 봐야 하는지, 무엇을 만들어야 하는지부터 엔지니어가 현장에서 찾아야 합니다. 공고가 하루 일과로 아키텍처 논의, 대규모 데이터 정리, 웹 앱 개발과 함께 「고객사 임원과의 대화」를 나란히 적어 둔 것도 그래서입니다. 문제를 정의하는 사람과 만드는 사람이 같은 사람입니다.

파견과 FDE를 가르는 네 가지 기준

일의 시작점 말고도 갈리는 곳이 더 있습니다. 표로 놓으면 이렇습니다.

기준	상주 파견	FDE
처음에 정해져 있는 것	명세와 기간	풀어야 할 문제
결과에 대한 책임	명세대로 만들었는가	문제가 풀렸는가
끝나고 남는 것	그 고객사의 시스템	고객사의 결과 + 제품에 쌓이는 것
돈을 받는 방식	투입 인원 × 기간 (M/M)	대개 제품 사용 계약에 묶임

셋째 줄이 가장 중요하다고 생각합니다. 팔란티어의 FDE는 맨손으로 들어가지 않습니다. 팔란티어의 데이터 플랫폼을 들고 들어가 고객의 문제에 맞춰 배치하고, 공고에 따르면 내부의 제품 팀과도 함께 일합니다. 제가 이해하는 구조는 이렇습니다. 한 고객사에서 반복해서 필요했던 것이 다음 고객사에서는 플랫폼 기능이 되어 있습니다. 파견 개발자가 만든 것은 그 고객사에 남고, 다음 프로젝트는 다시 처음부터입니다.

넷째 줄은 제 추론이 섞여 있습니다. 팔란티어가 FDE 비용을 어떻게 계약에 넣는지는 공개된 자료로 확인하지 못했습니다. 다만 FDE가 제품을 배치하는 사람이라면, 그 비용은 사람의 시간이 아니라 제품이 만든 결과로 회수하는 쪽이 자연스럽습니다.

제품 없는 FDE는 비싼 파견

이 표를 뒤집어 보면 경계가 보입니다. 현장에 들어가는 엔지니어 아래에 쌓이는 제품이 없다면, 셋째 줄의 오른쪽 칸이 비고 FDE는 상주 파견과 같아집니다. 이름만 바뀐 파견입니다.

그래서 저는 업체가 「FDE 방식으로 하겠다」고 할 때 그 말이 맞는지는 업체 쪽 자산을 보면 안다고 생각합니다. 매번 처음부터 만드는 업체라면 FDE라는 말은 단가를 올리는 데 쓰일 가능성이 큽니다. 비슷한 문제를 여러 번 풀면서 쌓은 공통 부품이나 플랫폼이 있고, 그 위에서 고객의 문제만 새로 푸는 업체라면 이름에 맞는 방식입니다.

규모는 기준이 아닙니다. 큰 회사의 파견도 있고 작은 회사의 FDE도 있습니다. 갈리는 것은 끝나고 무엇이 남느냐입니다.

AI 회사들이 다시 FDE를 뽑는 배경

팔란티어의 오래된 직무가 최근 다시 주목받는 데는 AI의 사정이 있습니다. OpenAI도 Forward Deployed Engineer 직무를 뽑고 있습니다.

AI 도입은 데모와 실제 업무 사이가 유난히 멉니다. 모델은 데모 데이터에서 잘 돌아가지만, 실제 회사의 데이터는 형식이 제각각이고 업무 규칙은 문서에 없고 사람 머릿속에 있습니다. 그 간극은 원격으로 메일을 주고받아서는 좁혀지지 않습니다. 누군가 현장에서 데이터를 직접 보고 담당자에게 물어야 합니다. 제품은 있는데 현장에서 쓰이지 않는 상황을 푸는 사람이 필요해졌고, 그 역할에 이미 이름이 있었던 셈입니다.

같은 이유로 FDE는 PoC(시범 적용)와 자주 함께 이야기됩니다. 현장에 들어가 실제 데이터로 짧게 돌려 보는 것이 PoC의 형식이기 때문입니다. PoC를 결정으로 이어지게 하는 조건은 PoC는 왜 유료여야 할까?에 따로 정리했습니다.

FDE 제안을 받은 발주사가 물을 질문

발주사 입장에서 FDE 방식 제안을 받았다면, 이름보다 내용을 확인하는 질문 몇 개로 충분합니다.

먼저 「끝나고 무엇이 남는가」를 묻습니다. 결과물이 우리 회사의 시스템뿐인지, 업체의 제품 위에서 돌아가는지에 따라 이후 유지보수와 비용 구조가 완전히 달라집니다. 제품 위에서 돈다면 그 제품의 사용료와 계약 기간을 따로 확인해야 합니다.

다음으로 「무엇으로 성공을 판단하는가」를 묻습니다. FDE가 문제에서 시작한다면 성공 기준도 「명세대로 만들었다」가 아니라 문제 쪽의 숫자여야 합니다. 업체가 이 질문에 화면 목록으로 답한다면 그건 파견의 언어입니다.

마지막으로 「현장에 누가, 얼마나 오는가」를 묻습니다. FDE의 가치는 현장에서 문제를 정의하는 사람이 직접 만드는 데서 나옵니다. 영업 담당이 와서 듣고 개발은 다른 사람이 원격으로 한다면, 이름은 FDE여도 구조는 일반 외주와 같습니다.

여기까지가 확인한 내용

FDE의 정의와 역할은 팔란티어의 채용 공고에서 확인한 것입니다. 팔란티어가 FDE를 내부에서 「Delta」라고 부른다는 것과 그 역할을 설명한 팔란티어 블로그 글도 있지만, 이 글을 쓰는 시점에 원문을 열어 볼 수 없어 인용하지 않았습니다. 상주 파견과의 비교, 제품이 없으면 FDE가 파견이 된다는 판단은 제 해석입니다. 업계에서 이 용어를 쓰는 방식이 회사마다 조금씩 달라서, 다른 회사의 FDE는 이 표와 다르게 움직일 수 있습니다.