FDE(Forward Deployed Engineer)는 한 고객의 실제 문제를 발견하고 데이터·시스템에 솔루션을 연결해 운영 성과를 만드는 역할입니다. PD(Product Development)는 여러 고객에게 반복해서 쓸 수 있도록 공통 기능, 플랫폼과 개발 표준을 만드는 역할입니다. 빅시프트처럼 맞춤형 AI 제품을 구축하는 팀은 프로젝트 안에서 FDE의 현장 학습과 PD의 제품화 원칙을 함께 운영해야 일회성 데모와 과도한 맞춤 개발을 피할 수 있습니다.
FDE와 PD는 누가 더 기술적인지를 가르는 직무가 아닙니다. 두 역할은 서로 다른 최적화 대상을 가집니다. FDE는 특정 고객의 업무 결과와 도입 속도를 우선하고, PD는 반복 사용성과 안정적인 확장을 우선합니다. 이 글에서 PD는 일반적인 Product Designer가 아니라, 팔런티어 조직 맥락에서 쓰인 Product Development를 뜻합니다.
먼저 용어를 구분해야 한다
팔런티어 전 직원의 회고에는 당시 엔지니어 조직이 고객과 일하는 FDE와 코어 제품팀의 PD로 나뉘었다고 설명돼 있습니다. FDE가 현장에서 특정 문제를 해결하면 PD는 반복되는 해결 방식을 일반화해 더 많은 배포에서 쓸 수 있는 제품 기능과 도구로 바꾸는 구조입니다. 이는 모든 회사가 따라야 할 표준 직무 체계라기보다, 현장 학습과 제품 레버리지를 연결하는 조직 설계로 이해하는 편이 정확합니다.
팔런티어의 Dev와 Delta 역할 설명도 비슷한 차이를 한 고객을 위해 여러 역량을 조합하는 현장 엔지니어와, 여러 고객에게 공통으로 쓰이는 제품 역량을 만드는 엔지니어의 관점으로 설명합니다. 오늘날 다른 AI 기업은 PD 대신 Product Engineer, Core Product, Platform Engineering 같은 명칭을 사용할 수 있습니다.
FDE 자체가 낯설다면 먼저 FDE의 정의와 AI 외주 실행 가이드에서 역할 범위와 일반 SI·컨설팅의 차이를 확인할 수 있습니다.
FDE와 PD의 핵심 차이
| 비교 항목 | FDE | PD(Product Development) |
|---|---|---|
| 출발점 | 특정 고객의 모호한 업무 문제 | 여러 고객에게 반복되는 제품 문제 |
| 주요 사용자 | 현업 담당자, 운영자, 고객 엔지니어 | 제품을 사용하는 전체 고객과 내부 개발팀 |
| 요구사항 | 현장에서 발견하고 계속 수정 | 제품 전략과 반복 신호를 바탕으로 우선순위화 |
| 주된 산출물 | 고객별 워크플로, 연동, 평가셋, 운영 배포 | 공통 API, 플랫폼 기능, 개발 도구, 재사용 모듈 |
| 성공 기준 | 실제 사용, 업무 지표, 안정적인 운영 전환 | 재사용률, 확장성, 안정성, 유지보수성과 제품 지표 |
| 속도와 범위 | 좁은 문제를 빠르게 끝까지 해결 | 공통 문제를 오래 유지할 수 있게 일반화 |
| 기술 부채 | 초기 가치 검증을 위해 제한적으로 감수 가능 | 여러 고객에게 전파되지 않도록 구조적으로 상환 |
| 고객 접점 | 높음. 인터뷰와 현장 관찰이 핵심 | 상대적으로 낮지만 제품 리서치와 현장 신호가 필요 |
같은 기능도 두 역할의 질문은 다릅니다. 예를 들어 한 기관의 문서 검색 정확도가 낮다면 FDE는 실제 문서, 권한과 사용자 질문을 확인해 검색 파이프라인과 평가셋을 고칩니다. PD는 같은 문제가 다른 고객에게도 반복되는지 확인하고, 공통 검색 설정이나 평가 도구로 제품화할지를 판단합니다.
FDE에서 PD로 넘어가는 제품화 루프
좋은 조직은 FDE와 PD를 인수인계 관계가 아니라 반복 루프로 운영합니다.
- 현장 발견 — FDE가 사용자, 데이터, 시스템과 운영 제약을 관찰합니다.
- 얇은 해결책 배포 — 가장 중요한 업무 흐름 하나를 실제 데이터로 구현하고 평가합니다.
- 반복 신호 기록 — 고객 고유 요구와 다른 프로젝트에서도 재현되는 문제를 분리합니다.
- 제품화 판단 — PD가 공통 인터페이스, 설정값, SDK 또는 플랫폼 기능으로 만들 범위를 정합니다.
- 코어 제품 반영 — 테스트, 문서, 버전 정책과 마이그레이션 경로를 갖춘 기능으로 출시합니다.
- 다음 현장 검증 — FDE가 다른 고객 환경에서 재사용해 일반화가 실제로 작동하는지 확인합니다.
OpenAI의 FDE 역할 설명에도 현장 배포에서 얻은 피드백을 제품·연구팀에 전달하고, 작동한 패턴을 도구와 플레이북으로 정리하는 책임이 포함돼 있습니다. 즉 현대의 FDE도 고객별 구현만 끝내는 역할이 아니라 제품 학습을 만드는 역할에 가깝습니다.
AI 프로젝트에서 두 역할이 특히 필요한 이유
생성형 AI는 같은 모델을 써도 데이터, 업무 규칙, 권한, 실패 허용 범위에 따라 결과가 크게 달라집니다. 현장 맥락이 없으면 제품팀은 실제 실패를 보기 어렵고, 제품화 원칙이 없으면 고객별 프롬프트와 연결 코드가 계속 늘어납니다.
- FDE는 환각, 권한 위반, 느린 응답처럼 운영에서 드러나는 실패를 실제 로그와 평가셋으로 바꿉니다.
- PD는 평가 실행기, 권한 계층, 관측 도구와 배포 파이프라인처럼 반복되는 기반을 공통 기능으로 만듭니다.
- FDE는 사용자가 결과를 신뢰하고 업무에 채택하는지 확인합니다.
- PD는 모델이나 인프라가 바뀌어도 제품 전체가 안정적으로 유지되게 합니다.
RAG 프로젝트라면 기업용 RAG 공급사·아키텍처 선택 가이드에서 검색 품질, 권한과 운영 소유권을 먼저 정리하면 두 역할의 경계를 잡기 쉽습니다.
한 팀이 FDE와 PD를 함께 맡아도 되는가
초기 프로젝트나 작은 제품팀에서는 가능합니다. 다만 담당자 수보다 의사결정 기준을 분리해야 합니다. 같은 엔지니어가 오전에는 고객의 긴급한 연동 문제를 해결하고 오후에는 공통 SDK를 설계할 수 있지만, 고객 전용 예외를 곧바로 코어 제품에 넣어서는 안 됩니다.
다음 세 가지 기록을 분리하면 겸임의 위험을 줄일 수 있습니다.
| 기록 | 반드시 남길 내용 |
|---|---|
| 고객별 결정 로그 | 해당 고객에게만 필요한 규칙, 보안·계약 제약, 임시 우회 방식 |
| 반복 신호 목록 | 두 곳 이상에서 나타난 문제, 발생 조건, 공통화 예상 효과 |
| 제품화 제안서 | 지원 범위, 비지원 범위, API와 설정, 테스트·마이그레이션 계획 |
빅시프트는 공개 사례에서 기획, 데이터 구조화, 모델 적용과 제품 개발을 한 프로젝트 흐름으로 연결합니다. 예를 들어 노코드 AI Agent Builder 구축 사례에서는 사용자의 자연어 의도를 워크플로 구조로 바꾸는 현장 문제를 다루면서 인증, 테스트, 실패 로그와 제품 분석까지 운영 가능한 제품 계층으로 연결했습니다. 이는 특정 고객 문제를 해결하는 FDE형 실행과 재사용 가능한 제품 경험을 만드는 PD형 판단이 함께 필요한 사례입니다.
외주 개발사를 볼 때 FDE와 PD 역량을 함께 확인하는 법
외주사에 FDE라는 직함이 있는지만 확인하면 역할의 절반만 보게 됩니다. 다음 질문을 실제 투입 팀에 물어야 합니다.
- 현업 인터뷰 결과를 기술 범위와 평가셋으로 바꾼 사례가 있는가?
- 고객별 코드와 재사용 가능한 코어 모듈을 어떻게 분리하는가?
- 빠른 프로토타입 이후 기술 부채를 언제, 어떤 기준으로 정리하는가?
- 현장 실패가 제품 개선 항목으로 들어가는 기록 체계가 있는가?
- 소스, 프롬프트, 평가셋, 인프라와 운영 문서를 고객에게 어떻게 인계하는가?
- 담당 엔지니어가 빠진 뒤에도 다른 사람이 운영할 수 있는가?
전략 수립과 실행 조직의 차이까지 비교하려면 AX 컨설팅의 전략 수립과 실행 지원 구분도 함께 참고할 수 있습니다.
자주 묻는 질문
PD는 Product Designer를 뜻하나요?
이 글의 PD는 Product Development를 뜻합니다. 팔런티어의 FDE·PD 조직 맥락에서 코어 제품을 개발하고 현장 해결책을 재사용 가능한 기능으로 일반화하는 역할입니다. 다른 회사에서는 Product Engineer나 Platform Engineer로 부를 수 있습니다.
FDE와 PD 중 누가 고객 요구사항을 정하나요?
FDE는 고객 현장에서 요구사항을 발견하고 검증하며, PD는 여러 고객에게 공통으로 제공할 제품 범위와 우선순위를 정합니다. 고객 고유 요구와 반복 가능한 제품 요구를 구분하는 공동 판단이 필요합니다.
FDE가 만든 코드를 PD가 그대로 제품에 넣나요?
보통은 그대로 넣지 않습니다. 현장 코드는 빠른 검증을 위해 고객 환경에 맞춰져 있을 수 있으므로, PD가 지원 범위, 인터페이스, 테스트, 보안과 마이그레이션 조건을 다시 설계한 뒤 코어 제품에 반영해야 합니다.
AI 외주 프로젝트에도 PD 역할이 필요한가요?
한 번만 쓰는 단순 자동화라면 별도 직무까지 필요하지 않을 수 있습니다. 여러 부서·고객으로 확장하거나 장기 운영할 시스템이라면 재사용 구조, 버전 관리와 기술 부채를 책임지는 PD 관점이 필요합니다.