목록으로
AI

요즘 다들 뽑는다는 FDE, 잘하는 사람은 뭐가 다를까?

OpenAI, Anthropic까지 뽑는 FDE(Forward Deployed Engineer)는 Palantir가 만든 직무예요. 그 직무를 만들고 겪은 사람들의 글 아홉 편에서 좋은 FDE를 가르는 기준 일곱 가지를 모았어요. 마인드로직도 이런 사람을 찾고 있어요.

2026-09-21

요즘 다들 뽑는다는 FDE, 잘하는 사람은 뭐가 다를까?

TL;DR

OpenAI, Anthropic까지 뽑기 시작한 FDE(Forward Deployed Engineer)는 원래 Palantir가 2000년대 중반 정보기관과 일하면서 만든 직무예요. 그 직무를 만들고 겪은 사람들이 남긴 글을 아홉 편 읽었는데, 좋은 FDE를 가르는 기준이 일곱 가지로 모였어요. 값은 고객이 얻은 결과에 매기고, 고객이 아직 못 찾은 문제를 먼저 찾아주고, 틀린 주문에는 안 된다고 말하고, 한 곳에서 배운 것을 다음 곳에서 다시 쓰는 사람이에요. 마인드로직도 이런 사람을 찾고 있어서, 읽다가 "이거 나 얘기인데" 싶은 분은 끝까지 읽어 주세요.

FDE가 뭔지부터

FDE는 고객 회사에 들어가 앉아서 일하는 엔지니어예요. 본사에서 제품을 만들어 던져주는 대신, 고객 옆자리에서 실제 데이터와 실제 업무를 보면서 그 자리에서 소프트웨어를 만들고 결과까지 책임져요. 2006년에 열세 번째 직원으로 합류한 Shyam Sankar(현 CTO)가 정보기관 현장에서 이 방식을 만들었고, 2009년에는 이미 회사 안에서 직함으로 쓰이고 있었어요. 지금은 AI 에이전트를 기업에 넣는 회사들이 거의 같은 이름으로 같은 자리를 뽑고 있어요.

이름이 퍼지니까 글도 많이 나왔어요. Palantir 안에 있는 사람, 나온 사람, 밖에서 지켜본 사람이 각자 "진짜 FDE는 이렇다"를 썼는데, 겹치는 대목이 분명했어요. 그 겹치는 부분을 일곱 가지로 모아 봤어요.

1. 값은 결과에 매긴다

FDE 모델을 가장 짧게 설명하는 문장은 돈 얘기예요. Interconnect의 Kevin Xu와 David Huang은 FDE의 보상은 성과에 묶여 있고 청구 시간과는 상관이 없다고 썼어요.

Their work is compensated as a percentage of outcome achieved, e.g. productivity gain or cost reduction, rather than billable hours.

그래서 훈련된 FDE는 시간을 팔면 돈이 되는 일을 거절하기도 한다고 해요. 고객이 시켜서 한 달 붙어 있으면 청구서는 커지지만, 그 일이 고객이 얻어야 할 결과와 상관이 없으면 단기 매출을 버리고 빼는 쪽을 택한다는 거예요.

Palantir CEO Alex Karp는 같은 말을 회사 입장에서 했어요. 고객이 원하는 결과를 얻으면 그 가치의 일부를 수수료로 가져간다는 거예요. 상장 서류에도 가격이 고정·다년 계약이고 고객이 얻을 가치를 기준으로 정해진다고 적혀 있어요. Ethan Ding은 이 구조가 컨설팅 회사와 소프트웨어 회사가 규모를 키울 때 생기는 인센티브 불일치를 없앤다고 정리했어요. 시간을 팔면 오래 걸릴수록 이득이고, 사용량을 팔면 많이 쓸수록 이득인데, 결과를 팔면 고객이 잘될수록 이득이니까요. Palantir 초기 임원 Bob McGrew의 YC 강연에도 "Price the outcome"이 한 챕터로 들어 있어요.

2. 고객이 아직 못 찾은 문제를 찾아준다

시킨 일을 잘하는 것과 잘하는 FDE는 다르다고, Palantir에서 250명 규모의 FDE 프로그램을 설계한 Vinoo Ganesh가 썼어요.

Good FDEs solve the problems they're given, but great FDEs understand the customer's business well enough to surface problems the customer had given up on or hadn't yet articulated.

그가 든 예는 소박해요. 고객사 담당자가 매일 45분씩 손으로 하던 데이터 작업이 있었는데, 그 사람은 그걸 문제라고 생각하지 않았어요. 늘 그렇게 해왔으니까요. 요청이 오기를 기다리지 않고 자동화해 버렸고, 그 뒤로 신뢰가 달라졌다고 해요.

Interconnect 글도 같은 자리를 짚어요. FDE가 현장에서 발굴하는 건 고객 스스로도 몰랐던 데이터와 문제, 조직 안 어딘가에 갇혀 있던 지식이에요. 그걸 끌어내 제품으로 일반화하는 과정을 그들은 "context R&D"라고 불렀어요. 고객이 말한 요구사항만 받아 적으면 절대 나오지 않는 것들이에요.

3. 고객보다 고객 사업을 더 챙기는 주인

Palantir 글로벌 커머셜 총괄 Ted Mabrey는 이 직무의 원형을 프랑스 식당 웨이터에 비유했어요.

The waitstaff is an intrinsic part of the kitchen. If you want to order the wrong wine with the fish, the wait staff will simply tell you no.

프랑스 식당의 웨이터는 주방의 일부다 — Palantir가 말하는 FDE의 원형 (개념도)

고객 조직은 무엇을 주문해야 하는지 잘 모르고, 시장은 그들에게 먹기 편한 것만 팔아 왔으니, 음식을 가져다주는 사람이 요리의 일부가 되어 의견을 가져야 한다는 거예요. 그가 든 표현이 재밌어요. 가끔 무례한 프랑스 웨이터가 손님보다 손님의 식사를 더 신경 쓰는 것처럼, FDE는 고객 사업의 주인처럼 행동하도록 훈련받는다고 해요.

같은 글에서 그가 「진짜 FDE」의 조건으로 든 것들도 전부 이 방향이에요. 소프트웨어 납품이 아니라 최종 결과에 책임진다, 제품 범위를 끝없이 넓힌다, 조직 정렬·도입·프로세스 재설계 같은 비기술 문제도 자기 일로 삼킨다, scope creep을 가치의 신호로 반긴다. 그리고 한 줄이 더 있어요. "There are no rules, there is only taste."

4. 요청을 그대로 받지 않는다

세 글이 각자 표현으로 같은 말을 해요. 고객이 원한다고 해서 만들지 않고, 왜 원하는지를 먼저 판다는 거예요.

Vinoo Ganesh의 글에는 고객이 석 달짜리 기능을 요구했을 때 이틀을 들여 왜 필요한지부터 파고들었더니 설정 하나로 끝나는 문제였다는 사례가 나와요. Palantir 채용 공고 자체에도 "no라고 말하는 능력"이 이 자리에서 잘하는 조건이라고 적혀 있습니다. 1번의 「청구 시간 성격의 요청은 거절한다」도 같은 원칙의 돈 쪽 표현이에요.

5. 그럼 컨설팅과 뭐가 다를까?

여기까지 읽으면 "그냥 잘하는 컨설팅 아닌가"라는 생각이 들 거예요. Palantir도 2015년쯤 같은 비판을 받았어요. Bob McGrew가 YC 강연에서 답한 차이는 두 가지예요.

하나는 같은 고객에서 시간이 갈수록 경제성이 좋아지는가예요. 컨설팅은 프로젝트마다 비슷한 인력과 시간이 들고 끝나면 관계도 끝나는데, FDE 모델은 처음엔 손해를 보더라도 점점 적은 인력으로 더 큰 가치를 내야 해요. 다른 하나는 한 고객에서 만든 것이 다음 고객에서 다시 쓰이는가예요. Palantir는 정보기관 세 곳에 따로 만들던 데이터베이스를 "객체·속성·미디어·링크"라는 공통 구조로 추상화했고, 그게 온톨로지가 됐어요. 그는 이걸 자갈길을 포장도로로 바꾸는 일이라고 불렀어요.

자갈길이 포장도로가 된다 — 고객별 커스텀이 공통 플랫폼으로 일반화되는 과정 (개념도)

스케일의 정의도 달라요. SaaS는 고객당 비용을 줄여서 커지고, FDE 모델은 고객당 계약 크기를 키워서 커져요. Barry McCardel은 개별 배포의 마진이 나빠도 된다고까지 썼어요. 배포 한 건은 연구개발 비용으로 봐야 한다는 이유예요. 고객별 마진을 따지기 시작한 조직은 이미 프로페셔널 서비스 회사가 됐다는 게 그의 진단이에요. Ted Mabrey의 표현을 빌리면, 형태만 베끼고 기능은 못 베낀 회사들이 많다는 거죠.

6. 코드보다 먼저 현장, 그리고 첫 주에 무언가를

Palantir에서 8년을 보낸 Nabeel Qureshi는 FDE의 효율이 고객의 언어를 얼마나 빨리 배우고 그 사업이 어떻게 돌아가는지 얼마나 깊이 파고드느냐에 달려 있다고 썼어요. 첫 몇 주 안에 작은 가치라도 실제로 돌아가는 걸 내놓아야 고객이 "이 사람들 진짜구나"를 안다고요. Palantir 안에서는 이걸 "ship on day one"이라고 부릅니다.

FDE로 3년을 일한 Gautham Senthilnathan은 한 문장으로 줄였어요.

You don't write a line of code until you understand the operator's day better than they do.

7. 어떤 사람을 뽑는가

Nabeel Qureshi가 본 FDE는 고통 내성이 높고, 낯선 회사 깊숙이 들어가 신뢰를 얻어내는 사회적·정치적 감각이 있는 사람이에요. 고객사 최고위층과 파트너가 되는 일이 곧 업무라서요.

Bob McGrew는 현장에 상주하는 도메인 전문가와 빠른 프로토타이퍼를 짝지었는데, 전문가는 "지금 방식은 충분하지 않다"고 믿는 이단아여야 하고, 엔지니어는 코드의 아름다움보다 속도를 택하는 사람이어야 한다고 했어요. 둘을 합치면 스타트업 창업자의 스킬셋이라는 게 그의 말이고, 실제로 Palantir 출신 창업자가 유난히 많은 이유로도 자주 꼽혀요.

7년간 1,000번 넘게 면접을 본 Anjor Kanekar의 기준은 더 짧아요. 똑똑한가, 그리고 이길 수 있는가. 그가 쓴 비유도 하나 옮겨요. FDE의 일은 고객에게 「드래곤」을 만들어 주되, 그러려고 새로 발명한 「이상한 브릭」을 제품팀으로 가져오는 것이라고요. 그 단계를 빼면 "a very expensive consultancy in a t-shirt"가 된다고 했어요.

이 글이 자기 얘기 같다면

이 글을 읽으면서 "나는 저 자리에서 잘할 것 같은데"라는 생각이 들었다면, 그 감이 맞을 가능성이 높아요. 마인드로직은 대학·공공기관·기업에 AI를 넣는 일을 하고 있고, 고객 옆자리에 앉아 문제를 찾고, 그 자리에서 만들고, 결과까지 책임지고 싶은 분을 찾고 있어요. 채용 페이지에서 열려 있는 자리를 확인하고 지원해 주세요. 잘 맞을지 먼저 이야기해 보고 싶다면 편하게 연락 주셔도 좋아요.

참고한 글