FORWARD DEPLOYED ENGINEERING · 한국어 리서치 노트 · 2026.08

FDE란
진짜 무엇인가

파견의 새 이름도, 만능 개발자의 직함도 아니다. FDE는 모호한 현장 문제를 생산 시스템과 측정 가능한 변화로 바꾸는 운영 모델이다.

01

DEFINITION

FDE의 본질은 ‘현장 배치’가 아니라 학습 루프의 소유다

장소가 고객사라는 사실은 필요조건도 충분조건도 아니다. 핵심은 모호함에서 시작해 문제·제품·운영을 함께 바꾸고, 성과와 학습을 코어 제품으로 되돌리는 데 있다.

01
발견

현장을 관찰하고 실제 병목을 찾는다

02
정의

문제와 성공 기준을 함께 다시 쓴다

03
가설

가장 작게 검증할 변화에 베팅한다

04
구현

설명에 그치지 않고 직접 만든다

05
적용

실제 업무·데이터·사용자에 연결한다

06
측정

채택과 워크플로 성과를 확인한다

07
재정의

실패 신호를 다음 제품 판단으로 돌린다

08
내재화

고객이 소유할 수 있게 하고 철수한다

SI의 기본 질문

“정의된 요구사항을
어떻게 구현할까?”

좋은 SI는 복잡한 통합을 안전하게 완수한다. 이 역할은 없어지지 않으며, FDE보다 열등한 것도 아니다.

FDE의 기본 질문

“무엇을 바꿔야 실제 성과가 나며,
어떻게 증명할까?”

필요하면 문제와 스코프를 바꾸고, 코드·업무 프로세스·채택 방식까지 함께 손댄다.

엄격한 답

FDE만 할 수 있는 특별한 기술은 없다. 차이는 능력의 독점이 아니라 전체 루프를 한 팀에 묶는 권한·책임·제품 환류 구조다.

02

STRUCTURAL DIFFERENCE

SI와 FDE를 가르는 6개의 구조

아래는 직군의 우열표가 아니라 운영 모델 비교다. SI 조직도 오른쪽 방식으로 일할 수 있고, FDE 팀도 왼쪽으로 퇴행할 수 있다.

판별 축전통 SI의 중심FDE의 중심현장에서 물을 질문
01문제 정의권

발주 전 또는 발주자가 주로 정의

현장·사용자와 함께 지속적으로 재정의

FDE가 문제를 바꿀 권한이 있는가?

02계약 / 스코프

과업·산출물·변경 절차 중심

성과 가설·타임박스·가변 백로그 중심

스코프 변경이 예외인가, 정상 운영인가?

03실행 속도

역할·승인 게이트를 따라 단계적으로 이동

소수 팟이 발견→코드→배포를 짧게 반복

현장 신호가 며칠 안에 제품으로 돌아오는가?

04제품 피드백 루프

고객별 요구 반영이 프로젝트 안에 머물 수 있음

현장 신호가 코어 제품·모델·플레이북을 바꿈

다음 고객의 제품이 더 좋아지는가?

05내재화 / 철수

검수·인수 또는 유지보수 전환

고객 메인테이너가 독립 운영하면 종료

의존도를 낮추는 것이 계약의 성공인가?

06재사용 자산화

산출물·컴포넌트·레퍼런스

평가셋·도구·추상화·배포 패턴을 코어로 환류

복붙이 아니라 공통 능력으로 흡수되는가?

한국적 맥락 공공 소프트웨어 사업은 법적으로 과업 확정과 변경, 계약금액·기간 조정 절차를 명시한다. 따라서 “요구사항을 받은 뒤 변경을 관리하는 구조”는 단순한 편견이 아니라 실제 계약 체계의 한 축이다. 다만 모든 민간 SI가 같은 방식이라는 뜻은 아니다. 소프트웨어 진흥법 ↗

03

SMALL POD

왜 소규모 팀이어야 하는가

‘사람을 적게 써서 싸게 만들기’가 아니다. 현장 신호가 책임자에게 도달하고 다시 제품이 되기까지의 거리를 줄이기 위해서다.

큰 분업 조직
현장→기획→PM→개발→QA→승인

인계가 늘수록 맥락 손실·대기·책임 경계가 늘어난다.

FDE 코어 팟
현장 문제LEADFDEMAINTAINER

같은 사람들이 관찰·결정·구현·측정을 반복한다.

01

의사결정 대역폭

모든 핵심 인원이 같은 맥락을 공유해, 요구 전달 대신 함께 판단한다.

02

끝까지 책임

역할 사이로 실패를 넘길 수 없다. 현장 성과가 날 때까지 한 팟이 소유한다.

03

빠른 재정의

틀린 가설을 버리는 비용이 낮아 문제와 스코프를 자주 다시 쓸 수 있다.

04

고객과의 신뢰

실제 결정권자가 직접 코드와 운영을 다루므로 현장 피드백이 왜곡되지 않는다.

권장 형태: 2–4명의 코어 팟으로 시작하고 보안·데이터·법무·플랫폼 전문가는 필요할 때 결합한다. 복잡도가 커졌다면 팟을 비대하게 만들기보다 문제를 나누고 공통 플랫폼을 강화한다. 작은 팀은 정의가 아니라 피드백 지연을 낮추는 설계 원리다.

04

STACK & INFRA

독립 스택은 필요하다. 독립된 ‘그림자 운영계’는 필요 없다

FDE는 고객의 긴 릴리스 열차에만 의존하지 않고 실험할 수 있어야 한다. 그러나 고객 데이터와 프로덕션 책임까지 별도 인프라로 빼면 내재화·보안·거버넌스를 해친다.

결론

개발·검증 능력은 독립적으로,
데이터·접근통제·운영 소유권은 고객 체계 안에서.

FDE DELIVERY PLANE

빠르게 배우는 층

  • 프로젝트 템플릿·공통 컴포넌트
  • 평가 하네스·회귀 테스트
  • 안전한 샌드박스·합성 데이터
  • CI/CD·관찰성·기능 플래그
  • 재사용 플레이북·추상화
검증된 변경 →API · POLICY · AUDIT← 운영 신호
CUSTOMER PRODUCTION PLANE

안전하게 소유하는 층

  • 실데이터와 원천 시스템
  • IAM·승인·감사·보존 정책
  • 프로덕션 런타임과 SLO
  • 보안·법무·리스크 통제
  • 고객 Maintainer와 런북
독립성이 필요한 이유
  • 첫 실험을 고객의 분기 릴리스 일정에서 분리
  • 고객마다 반복되는 기반 작업을 표준화
  • 평가와 관찰성을 기본값으로 강제
  • 현장 학습을 다음 배포의 속도로 전환
선을 넘는 신호
  • 실데이터를 승인 없이 외부로 복제
  • 고객만을 위한 포크가 영구적으로 증가
  • FDE만 배포·장애 대응이 가능
  • 계약 종료 후 시스템도 함께 멈춤
05

OPERATING MODEL

FDE 팀에 필요한 네 가지

올라운더 몇 명을 뽑는 것으로는 부족하다. 사람·권한·운영·평가가 같은 방향을 가리켜야 한다.

01

사람

작은 코어 팟 + 고객 메인테이너

  • 성과와 우선순위를 번역하는 Deployment Lead
  • 프론트·백엔드·데이터를 넘나드는 FDE
  • 업무 맥락과 운영을 이어받을 고객 측 Maintainer
  • 보안·플랫폼·법무는 필요 시 붙는 전문 지원
02

권한

문제·스코프·배포를 바꿀 수 있어야

  • 현업 사용자에게 직접 접근
  • 성과가 낮으면 백로그를 버리고 다시 정의
  • 안전한 데이터·로그·샌드박스 접근
  • 배포·롤백·킬스위치와 예산 판단에 참여
03

운영

발견과 개발을 분리하지 않는 리듬

  • 1–2주 단위의 가설→배포→학습
  • 평가셋과 실제 사용 로그를 같은 회의에서 검토
  • 의사결정·실패·범용화 후보를 짧게 기록
  • 첫날부터 페어링·런북·인수 계획 시작
04

평가

산출량보다 고객이 독립해 얻는 성과

  • 업무 KPI: 시간·비용·품질·리스크 변화
  • 채택률·반복 사용·현업 워크플로 침투율
  • 평가 통과율·신뢰성·운영 사고
  • 학습 주기·재사용률·Maintainer 독립도
LEADING학습 주기→평가 품질→채택
OUTCOME업무 KPI→독립 운영→재사용 레버리지

경계할 지표: 투입 M/M, 코드 라인 수, 완료 기능 수, 문서 수, 검수 통과만으로 FDE를 평가하면 팀은 가장 빠르게 SI형 납품 조직으로 수렴한다.

06

THE HARD ARGUMENT

“FDE = SI / 파견직”에 대한 가장 강한 답

‘우리는 더 똑똑하고 빠르다’는 반박은 약하다. 인력의 품질은 구조적 차이가 아니며 SI도 충분히 잘할 수 있다. 반박은 반드시 권한·루프·종료 조건으로 해야 한다.

같은 고객 현장에서 코드를 만들어도,
현장 학습이 코어 제품과 다음 고객의 능력을 바꾸고
고객의 의존도를 낮출수록 성공이라면 FDE다.

FIELD사용·실패·업무 성과
→
EVAL재현 가능한 신호
→
CORE제품·모델·도구 변화
→
SCALE다음 배포의 속도·품질

이 구조는 OpenAI가 서울 FDE 역할에서 “제품·모델 로드맵을 바꾸는 평가 기반 피드백”을 성공 기준으로 두고, Palantir가 FDE를 현장 신호가 제품 개발로 되돌아가는 “인간판 역전파”에 비유하는 공식 설명과 맞닿아 있다. OpenAI ↗ Palantir ↗

비판에 반박할 수 있는 조건
  • FDE가 문제와 성공 기준을 공동 정의한다.
  • 현장 신호가 코어 제품·모델 로드맵을 실제로 바꾼다.
  • 같은 팟이 프로토타입부터 안정적 운영까지 책임진다.
  • 고객이 독립할수록 계약 성공에 가까워진다.
  • 고객별 학습이 재사용 자산으로 축적된다.
그 비판이 맞아지는 조건
  • 고객이 요구사항과 우선순위를 일방 지시한다.
  • M/M·상주·기능 수·검수가 계약의 중심이다.
  • 코드는 고객별 포크에 갇히고 제품팀으로 환류되지 않는다.
  • FDE가 빠지면 배포·운영·개선이 멈춘다.
  • 장기 유지보수 매출을 위해 의존성을 남긴다.

따라서: 이름만 FDE이고 요구사항을 받아 납품한다면 사실상 SI다. 반대로 SI 회사라도 성과 기반 스코프, 제품 환류, 내재화 후 철수 구조를 갖추면 FDE 방식으로 일하는 것이다.

07

PRIMARY SOURCES

주장을 버티게 하는 공식 근거

직함 소개가 아니라 실제 역할·성공지표·제품 구조를 명시한 1차 자료를 우선했다. 각 설명은 원문의 직접 인용이 아니라 핵심을 한국어로 요약한 것이다.

01 · OPENAI · SEOUL ROLE

발견부터 프로덕션 롤아웃까지의 end-to-end 소유

채택, 측정 가능한 워크플로 영향, 제품·모델 로드맵을 바꾸는 평가 기반 피드백을 성공 기준으로 제시한다.

원문 보기 ↗02 · OPENAI · DEPLOYMENT LEAD

영향·운영 레버리지·제품 영향을 함께 측정

현장 신호의 로드맵 반영, 패턴 재사용, KPI의 배포 전후 측정을 FDE 운영의 일부로 둔다.

원문 보기 ↗03 · OPENAI · FRONTIER

비즈니스 문제→배포→연구로 이어지는 양방향 루프

고객의 생산 환경에서 얻은 학습이 시스템뿐 아니라 모델의 발전에도 연결된다는 구조를 설명한다.

원문 보기 ↗04 · PALANTIR · ARCHITECTURE

Forward Deployed Engineering을 인간판 역전파로 설명

현장에 깊이 들어간 엔지니어가 새 기능을 만들고 제품 개발에 되돌리는 구조를 공식 문서에서 제시한다.

원문 보기 ↗05 · PALANTIR · SEOUL ROLE

작은 팀, 최소한의 감독, end-to-end 실행

열린 질문에서 출발해 고객과 나란히 문제를 이해하고 설계·구현·배포하는 역할을 명시한다.

원문 보기 ↗06 · 대한민국 · 소프트웨어 진흥법

과업 확정·변경과 계약 조정을 제도화한 한국의 맥락

공공 SW 사업은 과업 내용을 확정하고, 변경 시 계약금액·기간을 조정하는 절차를 둔다. 전통 SI의 스코프 구조를 이해하는 실증적 배경이다.

원문 보기 ↗

읽는 법: FDE와 SI는 법적으로 배타적인 자격이나 표준 직군이 아니다. 이 자료는 공개된 운영 설명에서 반복되는 구조를 추출한 분석 프레임이며, 개별 회사의 명칭보다 실제 계약·권한·측정·제품 환류를 우선해서 보도록 설계했다. 자료 확인일 2026.08.27.

08

FIELD CHECK

FDE인지 SI인지 판별하는 체크리스트

프로젝트 시작 전 계약서와 팀 구조를 보며 체크한다. ‘예’가 많다는 사실보다, 문제 정의·제품 환류·철수 조건 세 항목이 실제로 작동하는지가 더 중요하다.