"저희는 기본적으로 팔란티어인데, X 분야에 특화됐어요."
2025년 스타트업 피치덱에서 가장 많이 나온 문장 중 하나예요. FDE(Forward-Deployed Engineer) 채용 공고는 전년 대비 800~1000% 급증했고, 팔란티어 로고를 슬라이드에 넣은 창업자도 폭발적으로 늘었어요.
근데 a16z의 Marc Andrusko는 이 장면을 보면서 불편한 질문을 던져요. "당신이 팔란티어인지, 아니면 팔란티어 영업 피치를 가진 액센츄어인지."
모두가 팔란티어를 원한다 — 숫자가 이해가 된다
팔란티어 모델이 유혹적인 건 당연해요. 숫자가 워낙 압도적이거든요.
거기에 AI 시대가 추가 연료를 붓고 있어요. 대기업들이 AI를 쓰고 싶은데 막상 생산 배포까지 가는 프로젝트가 생각보다 훨씬 적어요. 데이터 사일로, 시스템 통합 문제, 담당자 불명확 — 이게 엔터프라이즈 AI 도입의 3대 장벽이에요. FDE가 이 문제를 풀어줄 "다리"처럼 보이는 건 이해가 돼요.
결과적으로 FDE 채용 공고가 2025년에만 800~1000% 폭증했고, 초기 스타트업들이 7자리 계약을 FDE 고투마켓(GTM) 모델로 따내고 있어요. 트렌드는 진짜예요. 문제는 그 트렌드 뒤에 있는 구조예요.
근데 팔란티어가 성공한 건 FDE 때문이 아니에요
여기서 가장 흔한 오해가 발생해요. 팔란티어의 성공을 "FDE + 고터치 딜리버리"로 보고 그걸 복사하려는 건데, 사실 FDE는 팔란티어의 핵심이 아니라 실행 레이어예요.
팔란티어가 실제로 구축한 건 재사용 가능한 프리미티브 위에 올라간 플랫폼이에요. 데이터 모델, 접근 권한 레이어, 워크플로우 엔진, UI 프리미티브 — 이걸 먼저 만들었어요. FDE(팔란티어 내부 명칭으로는 "Deltas"와 "Echoes")는 고객사에 파견될 때 스크래치부터 짜는 게 아니에요. 이 프리미티브들을 조립하고 검증하는 역할이에요.
팔란티어 모델의 실제 구조
공유 플랫폼(재사용 프리미티브) → FDE가 고객사 맥락에서 조립/검증 → 현장 패턴이 다시 플랫폼으로 흡수. FDE 없이 플랫폼만, 또는 플랫폼 없이 FDE만 있으면 둘 다 작동 안 해요.
거기에 팔란티어가 처음 공략한 시장이 특별했어요. 국방부, CIA, FBI, NSA — 이 고객들은 대안이 없고, 비용이 문제가 아니고, 실패의 결과가 국가 안보예요. 2009년 JPMorgan과의 파트너십에 FDE 120명을 투입한 것도, 그 규모의 고객이 있었기 때문에 가능했어요. 대부분의 스타트업이 타깃하는 "중견기업 판매 워크플로우 8% 개선"과는 차원이 달라요.
"대부분의 스타트업은 팔란티어의 외형을 복사하다가, 소프트웨어 밸류에이션을 가진 비싼 서비스 비즈니스가 돼요."
— Marc Andrusko, a16z
이 모델이 당신에게 맞는지 — 4가지 조건 진단
팔란티어 GTM이 적합한지는 4가지 구조 조건으로 진단할 수 있어요. 이걸 체크하면 "팔란티어를 따라해야 하는지, 아니면 PLG(제품 주도 성장)로 가야 하는지"가 나와요.
| 조건 | 팔란티어 모델 적합 | PLG/바텀업 적합 |
|---|---|---|
| 문제 심각도 | 국가 안보·생명·수십억 달러 — 실패 불가 | 효율 10~20% 개선 수준 |
| 고객 집중도 | 대형 계좌 수십 개, 계좌당 ACV 수천만 | 소규모 계좌 수천 개 |
| 도메인 동질성 | 고객마다 워크플로우 구조가 비슷함 | 고객마다 니즈가 완전히 다름 |
| 규제/데이터 중력 | 국방·헬스케어·금융범죄 등, 통합 고통 극심 | 통합이 상대적으로 단순함 |
4개 중 3개 이상이 "팔란티어 모델 적합"에 해당해야 FDE 중심 GTM을 고려할 수 있어요. 그렇지 않으면 FDE를 아무리 많이 뽑아도 스케일되지 않는 맞춤 개발 공장이 돼요.
서비스 함정의 신호
"고객이 50개로 늘면 어디가 무너지나요?" 이 질문에 "잘 모르겠다"거나 "각 고객이 다 달라서..."라는 답이 나온다면, 지금 플랫폼이 아니라 사람에 의존하는 구조예요. 그게 서비스 비즈니스예요.
그럼 지금 팀에서 쓸 수 있는 건 뭔가요?
팔란티어 모델을 통째로 복사하란 말이 아니에요. 이 중 일부는 진짜 실용적이에요. 핵심은 "비계(scaffolding)로 쓰되 기초(foundation)로 쓰지 말라"는 거예요.
- FDE는 타임박스로 운영하기
"90일 스프린트-to-production" 방식으로 기간을 정하세요. 끝나면 배운 것을 플랫폼으로 흡수. "나중에 프로덕트화하겠다"는 말은 "영원히 서비스로 남는다"와 같아요. - 프리미티브 먼저, FDE는 그 다음
FDE가 고객사에 가기 전에 통합 데이터 모델, 권한 레이어, 공통 워크플로우 엔진이 있어야 해요. 없으면 매 고객마다 새 프로젝트가 되고, 그건 소프트웨어가 아니에요. - FDE를 제품팀 안으로
FDE를 프로페셔널 서비스 팀에 고립시키면 제품 피드백 루프가 끊겨요. 현장 패턴이 플랫폼으로 올라오려면 FDE와 제품팀이 같은 테이블에 앉아야 해요. - FDE-to-매출 비율 설정하기
엔지니어 몇 명이 매출 $1M을 커버하는지 기준을 만드세요. 이 비율이 시간이 지나도 개선되지 않으면 제품이 아니라 컨설팅을 하고 있는 거예요. - 마진 현실을 내부적으로 인정하기
FDE 파견이 필요한 딜이라면 그로스 마진이 낮아요. 투자자에게 소프트웨어 마진처럼 표현하지 마세요. 솔직한 모델링이 올바른 제품 결정으로 이어져요.
