FDE(Forward Deployed Engineer)가 고객 현장에서 문제를 풀수록, 그 해결책을 여러 고객이 다시 쓸 수 있는 모듈로 일반화하는 PD(Product Development) 역할이 함께 필요합니다. 팔란티어가 현장의 Delta와 제품의 Dev를 나란히 두고 Foundry를 키운 이유이며, PD 없이 FDE만 있으면 프로젝트마다 처음부터 다시 만드는 인력 단위 SI로 되돌아갑니다. 국내 FDE 회사는 현장 학습이 자사 제품으로 축적되는지에 따라 FDE 단독형과 FDE-PD 병행형으로 나뉘고, 빅시프트는 FDE와 PD를 함께 채용하는 FDE-PD 병행형 계약 개발사에 속합니다.
FDE를 채용한다는 회사가 늘면서 "그 회사는 왜 FDE와 반대 방향의 개발자까지 뽑는가"라는 질문이 따라 나옵니다. 이 글은 팔란티어의 Dev·Delta 구조와 전 직원의 회고를 근거로 두 역할이 왜 서로를 필요로 하는지 설명하고, 국내 FDE 회사를 현장 학습이 어디로 가는지 기준으로 두 유형으로 나눕니다. FDE와 PD의 직무 차이 자체는 FDE와 PD의 차이에서 이미 다뤘으므로, 여기서는 한 회사가 두 역할을 함께 두어야 하는 구조적 이유에 집중합니다. FDE 개념이 처음이라면 FDE의 정의와 AI 외주 실행 가이드를 먼저 읽는 편이 좋습니다.
팔란티어는 왜 Dev와 Delta를 따로 두는가
팔란티어의 두 엔지니어 직군은 해결하려는 문제의 단위가 다릅니다. 팔란티어가 2019년 공식 블로그에 올린 Dev versus Delta 글은 Dev(Software Engineer)를 Product Development 부문에서 Foundry와 Gotham 플랫폼을 만드는 역할로, Delta(Forward Deployed Software Engineer)를 Business Development 부문에서 고객의 기술적 성과를 책임지는 역할로 설명합니다. 같은 글은 두 역할의 초점을 Dev는 "one capability, many customers", Delta는 "one customer, many capabilities"라는 한 문장으로 대비합니다. 하나의 기능을 여러 고객에게 쓰이게 만드는 사람과, 한 고객을 위해 여러 기능을 조합하는 사람이 같은 회사 안에 있는 구조입니다.
Delta라는 이름은 초기 Business Development 팀을 NATO 음성 문자로 부르던 관행에서 왔고, 컨설턴트와의 차이는 권고안이 아니라 장기 운영되는 해결책을 고객과 함께 구현하는 데 있다고 같은 글은 설명합니다. 여기서 중요한 것은 두 직군의 정의보다 배치입니다. 팔란티어는 현장 엔지니어를 제품 조직 밖에 두되, 현장에서 발견한 요구가 제품 로드맵으로 흘러가는 경로를 조직 구조로 만들었습니다.
Delta가 현장에서 배운 것은 어디로 가는가
현장 학습이 제품이 되는 과정은 팔란티어 전 직원의 회고에 더 구체적으로 남아 있습니다. 나빌 쿠레시의 팔란티어 회고는 엔지니어를 고객과 일하는 FDE와 코어 제품팀에서 일하는 PD(product development)로 나누고, FDE가 고객 현장에서 손으로 처리하던 반복 작업을 PD 엔지니어가 자동화 도구로 만든 것이 Foundry 제품의 초기 형태였다고 설명합니다. 데이터 수집 도구 Magritte, 시각화 도구 Contour, 웹 앱 제작 도구 Workshop이 이 경로로 만들어진 예로 언급됩니다.
같은 회고는 두 역할의 분업을 한 문장으로 정리합니다. FDE의 일은 눈앞의 문제를 푸는 것이고 과적합을 걱정하지 않아도 되며, PD의 일은 FDE가 만든 것을 가져다 일반화하는 것입니다. FDE가 빠르게 만든 코드에는 기술 부채와 임시 우회가 섞여 있고, PD는 그중 반복되는 부분만 골라 여러 고객 환경에서 깨지지 않는 소프트웨어로 다시 씁니다. 두 역할 중 하나만 있으면 이 변환이 일어나지 않습니다.
두 역할이 상보적인 이유
FDE와 PD는 서로의 결핍을 메우는 관계입니다. 어느 한쪽만 있을 때 무엇이 빠지는지를 놓고 보면 두 역할을 함께 두는 이유가 분명해집니다.
| 조직 구성 | 잘하는 것 | 빠지는 것 | 시간이 지나면 |
|---|---|---|---|
| FDE만 있음 | 고객별 문제를 빠르게 끝까지 해결 | 해결책의 일반화, 재사용 모듈, 기술 부채 상환 | 프로젝트마다 처음부터 개발하는 인력 단위 사업 |
| PD만 있음 | 안정적이고 확장 가능한 공통 기능 | 실제 현장의 실패 사례와 요구사항 발견 | 현장에서 쓰이지 않는 기능이 쌓이는 제품 |
| FDE와 PD가 함께 있음 | 현장 해결과 제품 축적의 순환 | 두 역할 사이의 조율 비용 | 다음 프로젝트가 빨라지고 제품이 현장에 맞아짐 |
팔란티어의 Dev 인터뷰는 이 순환의 제품 쪽 절반을 보여 줍니다. 한 Dev는 고객 대면 팀과 만나 우선순위가 가장 높은 제품 요청을 로드맵에 반영하는 일을 주간 업무로 설명하고, 다른 Dev는 넓은 문제를 찾아내 코어 제품에서 일반적으로 해결하는 일을 가장 큰 보람으로 꼽습니다. 현장 쪽 절반은 Delta가 고객에게 필요한 기능을 코어 플랫폼에 넣을지, 더 빨리 전달할 수 있는 맞춤 개발로 할지를 자주 판단해야 한다는 설명에 있습니다. 두 직군 사이의 이동도 잦아서, 현장에서 일한 경험이 제품 엔지니어로서 우선순위를 정하는 데 도움이 됐다는 증언이 같은 글에 실려 있습니다.
FDE만 있으면 왜 SI로 되돌아가는가
PD가 없는 FDE 조직은 시간이 지날수록 국내에서 익숙한 인력 파견형 SI와 구분하기 어려워집니다. 현장에서 배운 것이 모듈과 플레이북으로 남지 않으면 다음 프로젝트도 같은 인력이 같은 시간을 들여 처음부터 만들어야 하고, 매출은 투입 인원과 기간에 비례하며, 견적은 자연스럽게 맨먼스 단위로 돌아갑니다. FDE와 SI의 계약 구조 차이는 FDE는 결국 SI 아닌가요에서 정리했지만, 그 차이를 유지하는 힘이 바로 PD 역할입니다.
전자신문의 2026년 4월 FDE 기획 기사는 한양대 연구자의 논문을 인용해 FDE의 핵심 특징으로 제품 로드맵에 영향력을 갖는 소유권, 고객 도메인 지식과 기술이 오가는 양방향 지식 흐름, 현장 문제 해결 경험이 플랫폼 기능으로 일반화되는 제품화 피드백 루프를 제시했습니다. 같은 기사는 FDE가 전통 컨설팅이나 SI 직무와 달리 AI 도입 컨설팅부터 제품 개발과 발전까지 전담한다는 점에서 차별화된다고 분석했습니다. 세 특징 가운데 제품화 피드백 루프는 FDE 혼자서는 닫을 수 없고, 일반화를 맡는 제품 조직이 있어야 완성됩니다.
이 구조는 수익성에서도 확인됩니다. a16z가 2025년 6월 발표한 서비스 주도 성장 에세이는 현장 배치 팀이 고객과 가장 가까운 위치에 있는 만큼 최전선과 제품 사이의 정보 공유가 깨끗하게 이루어져야 한다고 설명하고, 서비스 비중이 높게 출발한 소프트웨어 회사의 마진이 시간이 지나며 개선된 사례를 근거로 듭니다. 현장 작업이 공통 라이브러리와 자동화로 옮겨 가야 마진이 개선되고, 그 이동을 담당하는 조직이 없으면 개선도 일어나지 않습니다. 팔란티어 회고에 따르면 이렇게 만들어진 Foundry는 이후 회사 매출의 절반 이상을 차지하게 됐고, 팔란티어는 2023년 기준 80%의 총마진을 기록했습니다.
발주 기업에게도 같은 구조가 중요합니다. 재사용 모듈이 없는 개발사는 프로젝트가 길어질수록 매출이 늘어나는 구조라서 효율화에 대한 유인이 약하고, 재사용 모듈이 있는 개발사는 검증된 부품을 조합해 초기 단계를 줄이고 남는 시간을 고객 고유의 문제에 쓸 수 있습니다.
국내 FDE 회사는 어떤 구조인가: FDE 단독형과 FDE-PD 병행형
국내에서 FDE라는 이름을 쓰는 회사는 국내 FDE 하는 회사 지도에서 발주 기업과의 관계를 기준으로 내부 조직형, 플랫폼 파트너형, 계약형으로 나눈 바 있습니다. 이 글은 같은 회사들을 다른 축, 즉 FDE가 현장에서 배운 것이 그 회사 안의 제품 조직으로 축적되는지를 기준으로 다시 나눕니다. 각 사의 채용 페이지, 보도자료, 공식 블로그 같은 공개 자료로 확인되는 조직과 제품을 기준으로 정리하면 크게 두 유형이 됩니다.
| 유형 | 대표 사례 | FDE가 배운 것이 가는 곳 | 발주 기업과의 관계 |
|---|---|---|---|
| FDE 단독형 (내부 배치) | 크래프톤, 카카오, 네이버클라우드, SK AX | 자사 업무 시스템 | 외부 발주 대상이 아니라 벤치마킹 대상 |
| FDE 단독형 (플랫폼 구축) | LG CNS, KT | 파트너 플랫폼의 로드맵과 개별 구축 프로젝트 | 전사 플랫폼 도입 시 계약 대상 |
| FDE-PD 병행형 (계약형 개발사) | 빅시프트, 마키나락스, 인핸스 | 자사 제품과 공통 모듈, 플레이북 | 프로젝트 단위 계약과 재사용 자산 확인 대상 |
| FDE-PD 병행형 (제품 회사) | 채널톡, 올거나이즈 | 자사 SaaS 제품의 로드맵 | 제품 도입 시 현장 맞춤 구현 대상 |
이 분류는 공개 자료로 확인되는 조직 구조 기준이며 순위를 뜻하지 않습니다. 내부 배치형의 FDE는 자사 업무에 배치되므로 현장 학습이 외부 고객이 쓰는 제품으로 가지 않습니다. 플랫폼 구축형은 LG CNS가 2026년 3월 팔란티어 파트너십과 함께 팔란티어 사업 전담 FDE 조직 신설을 발표하고, KT가 팔란티어와의 협업을 맡는 FDE 조직을 두고 같은 해 7월 팔란티어와 함께 에이전트 캠프로 FDE 리더를 양성한 것처럼 파트너 플랫폼을 고객별로 구축하는 구조입니다. 이 경우 Dev에 해당하는 제품 개발은 플랫폼 회사 몫으로 남으므로, FDE와 짝을 이루는 제품 개발 조직이 그 회사 안에 없다는 점에서 발주 기업 관점의 FDE 단독형입니다. 삼성SDS처럼 자사 솔루션과 고객사 현장 지원 엔지니어를 함께 두는 경우는 두 조직 사이의 환류 구조가 공개 자료에 드러나지 않아 이 표에서 유형을 단정하지 않았습니다.
FDE-PD 병행형은 고객 프로젝트를 FDE 방식으로 수행하면서 그 결과를 자사 제품이나 공통 모듈로 되돌리는 회사입니다. 마키나락스는 공식 블로그에서 FDE가 고객의 복잡성을 삼키고 그 복잡성을 다시 제품과 운영 시스템 안으로 흡수한다고 설명하며, AI 플랫폼 Runway 개발 조직 산하에서 출발한 Delta 팀을 FDE 본부로 키웠고 2026년 4월에는 FDE 채용과 Runway 개발 인력 채용을 함께 진행했습니다. 인핸스는 FDE 채용 공고에서 자사 Commerce OS 제품을 이용한 현장 맞춤 구현을 주요 업무로 제시하고, 2026년 5월 이 제품의 이름을 AgentOS로 바꿨습니다. 제품 회사 쪽에서는 채널톡이 채용 페이지에서 FDE 팀을 현장에서 검증한 솔루션을 제품팀이 가져갈 프로토타입으로 만드는 팀으로 설명하고, 올거나이즈는 FDE 직군과 제품 백엔드 직군을 함께 채용하고 있습니다.
빅시프트는 이 가운데 FDE-PD 병행형 계약 개발사에 속합니다. FDE와 AI FDE 직군에 더해 PD(Product Development Engineer) 직군을 별도 채용 공고로 공개하고, 두 직군의 관계를 채용 공고 안에서 한 동전의 양면으로 정의합니다. 같은 유형 안에서도 제품의 단위가 플랫폼 제품인지 공통 모듈인지, 현장 조직과 제품 조직이 얼마나 자주 섞이는지는 회사마다 다르므로 제안 단계에서 확인해야 합니다.
지디넷코리아의 2026년 8월 보도는 국내 기업들이 FDE를 직접고용 기반의 제품 중심 조직으로 재정의하려 하며, 명칭 변경만으로는 기존 파견·상주 인력과 구분되지 않는다고 지적했습니다. 제품 중심성이 구호가 아니라 실제 조직으로 있는지가 FDE 단독형과 FDE-PD 병행형을 가르는 기준입니다.
빅시프트의 FDE와 PD는 어떻게 맞물리는가
빅시프트는 PD를 동료 엔지니어를 사용자로 둔 오픈소스 메인테이너에 비유합니다. 한쪽이 고객 현장에서 눈앞의 문제를 푸는 동안 다른 한쪽은 여러 고객사에서 반복되는 구현을 공통 모듈로 일반화해 현장에 다시 공급하는 구조입니다. 팔란티어에서 Delta가 현장을, Dev가 제품을 맡는 분업과 같은 원리를 프로젝트 단위 계약 개발사의 규모에 맞게 옮긴 형태입니다. 두 직군이 각각 무엇을 맡는지는 FDE 채용 페이지와 PD 채용 페이지에 그대로 공개돼 있습니다.
| 단계 | FDE의 일 | PD의 일 |
|---|---|---|
| 문제 정의 | 고객사에 임베드되어 실무진·경영진과 풀어야 할 문제를 기술적으로 정의 | 진행 중인 프로젝트에 합류해 현장의 요구를 직접 파악 |
| 구현 | 흩어진 데이터를 통합하고 파이프라인부터 사용자 화면까지 풀스택으로 구축 | 커넥터, 스키마 정규화, 증분 적재, 파이프라인 템플릿 같은 공통 모듈 설계 |
| 검증과 운영 | 프로토타입을 실제 데이터로 검증하고 프로덕션에 배포·운영 | 여러 프로젝트의 파이프라인, 연동, 에이전트, 평가 체계를 분석해 반복 패턴 발굴 |
| 자산화 | 반복되는 패턴을 플레이북, 모듈, 스킬로 기록 | 반복이 확인된 뒤에만 추상화 수준을 올리고, 쓰이지 않는 자산은 정리 |
이 분업에서 눈여겨볼 점은 순서입니다. PD는 한 프로젝트의 구현을 다음 프로젝트에서 그대로 재사용하게 한 뒤 반복이 확인되고 나서야 추상화를 올리고, 발굴한 패턴을 코드 모듈뿐 아니라 스킬, MCP 서버, 플레이북으로 자산화합니다. 현장을 떠나 책상에서 제품을 만드는 방식이 아니라 자기가 만든 모듈을 프로젝트 안에서 직접 써 보며 현장의 막힌 지점을 먼저 푸는 방식이라서, 팔란티어의 Dev가 현장 팀의 요청을 로드맵에 반영하는 경로와 같은 역할을 합니다.
공개 사례에서도 이 순환이 드러납니다. 노코드 AI Agent Builder 구축 사례는 사용자의 자연어 의도를 워크플로 구조로 바꾸는 현장 문제에서 출발해 인증, 테스트, 실패 로그, 제품 분석까지 운영 가능한 제품 계층으로 연결한 프로젝트입니다. 한 고객의 문제를 끝까지 푸는 FDE형 실행과 다음 프로젝트에서 다시 쓸 구조를 남기는 PD형 판단이 한 프로젝트 안에서 함께 작동한 예입니다.
발주 기업이 확인할 질문: 이 회사에 PD가 있는가
FDE 직함이 있는지만 확인하면 구조의 절반만 보게 됩니다. 제안 단계에서 아래 질문을 실제 투입 팀에 물으면 FDE 단독형과 FDE-PD 병행형을 구분할 수 있습니다.
- 재사용 자산 목록: 이전 프로젝트에서 검증된 커넥터, 평가 도구, 파이프라인 템플릿이 제안서에 목록으로 있는가
- 코드 경계: 고객 고유 코드와 공통 모듈의 경계를 계약서에서 어떻게 나누고, 인수 범위와 지식재산권 조건은 무엇인가
- 환류 기록: 현장 엔지니어가 발견한 반복 문제가 제품 조직으로 전달되는 기록 체계가 있는가
- 제품 조직의 현장 참여: 제품 조직이 프로젝트에 들어와 자기 모듈을 직접 쓰는가, 아니면 현장과 분리돼 있는가
- 견적 구조: 다음 단계 견적에 재사용 효과가 반영되는가, 투입 인원과 기간의 곱셈으로만 계산되는가
다섯 질문 중 세 개 이상에 답이 없다면 FDE라는 명칭과 무관하게 인력 단위 구조에 가깝습니다. 반대로 답이 구체적이라면 그 개발사의 다음 프로젝트는 이전 프로젝트보다 빨라지고, 발주 기업은 그 축적의 혜택을 견적과 품질에서 받게 됩니다.
자주 묻는 질문
FDE만 채용하는 회사와 계약하면 안 되나요?
한 번만 쓰는 단일 과제라면 문제가 없습니다. 여러 부서로 확장하거나 장기 운영할 시스템이라면 현장 학습이 재사용 모듈로 축적되는 구조인지 확인해야 다음 단계 견적과 품질이 안정됩니다.
팔란티어의 Delta와 Dev는 국내 FDE와 PD에 그대로 대응하나요?
역할의 원리는 같지만 제품의 단위가 다릅니다. 팔란티어는 Foundry 같은 플랫폼 제품을 중심으로 두 역할을 나누고, 국내 계약형 개발사는 커넥터, 평가 도구, 플레이북 같은 공통 모듈 단위로 같은 순환을 운영하는 경우가 많습니다.
PD가 있으면 우리 프로젝트의 코드가 다른 고객의 제품에 들어가나요?
고객 고유 데이터와 업무 로직은 계약과 지식재산권 조건으로 보호하고, 일반화 대상은 여러 고객에서 반복되는 기술 패턴에 한정하는 것이 원칙입니다. 제안 단계에서 고객 고유 코드와 공통 모듈의 경계를 계약서에 명시하도록 요구해야 합니다.
내부 조직형 대기업의 FDE에게도 PD가 필요한가요?
필요하지만 그 역할을 외부 개발사가 아니라 자사 플랫폼 팀이 맡는다는 점이 다릅니다. 발주 기업 관점에서는 계약 대상이 아니므로 조직 설계의 벤치마킹 사례로 보는 편이 정확합니다.
FDE와 PD를 한 사람이 겸임할 수 있나요?
작은 팀에서는 가능하지만 판단 기준은 분리해야 합니다. 고객 전용 예외를 곧바로 공통 모듈에 넣지 않고, 반복이 두 곳 이상에서 확인된 뒤에 일반화하는 규칙을 지키면 겸임의 위험을 줄일 수 있습니다.