FDE와 SI 파견의 차이는 상주 여부가 아니라 계약이 시작되는 지점, 산출물과 검수 기준, 수익 구조에 있습니다. SI 계약은 확정된 요구사항을 구현하고 투입 인력 기준으로 과금하는 반면, FDE 방식은 요구사항이 확정되기 전의 문제 정의부터 운영 정착까지 결과를 책임지고 현장에서 배운 것을 재사용 가능한 자산으로 되돌립니다. 빅시프트 같은 FDE 방식 개발사를 검토할 때는 명칭이 아니라 계약서의 책임 경계, 평가 기준, 산출물 목록으로 실제 차이를 확인해야 합니다.
FDE(Forward Deployed Engineer)가 국내에 알려지면서 "결국 SI 파견의 새 이름 아니냐"는 반응도 함께 늘고 있습니다. 고객사 가까이에서 일하는 겉모습만 보면 두 방식은 비슷해 보입니다. 이 글은 그 회의론을 피하지 않고, 발주 기업이 계약서와 견적서에서 두 방식을 실제로 구분할 수 있는 기준을 정리합니다. FDE 개념 자체가 처음이라면 FDE의 정의와 AI 외주 실행 가이드를 먼저 읽는 편이 좋습니다.
왜 "FDE는 SI 재포장"이라는 말이 나오는가
이 의심에는 실제 근거가 있습니다. 국내에는 고객사 상주 개발 문화가 이미 오래 자리 잡았고, 상주라는 형태만 보면 FDE와 구분되지 않기 때문입니다. FDE라는 직함만 새로 붙이고 일하는 방식은 그대로인 회사도 있습니다. 오픈AI와 팔란티어의 FDE가 SI 파견직과 무엇이 다른지 짚은 지디넷코리아의 2026년 8월 기획 보도는 FDE를 고객과 함께 문제를 정의하고 도입 전략부터 구현·안정화까지 잇는 역할로, SI 파견을 사전에 정해진 요구사항을 수행하는 역할로 대비합니다.
명칭은 누구나 바꿀 수 있으므로, 발주 기업에 필요한 것은 명칭이 아니라 구조를 보는 기준입니다. 아래에서 세 가지 구조적 차이와 판별 체크리스트를 차례로 정리합니다.
같은 점과 다른 점 한눈에 보기
두 방식이 공유하는 겉모습부터 인정해야 비교가 정확해집니다. 고객 환경에서 일하고, 고객 시스템과 데이터에 접근하며, 프로젝트 단위로 계약한다는 점은 같습니다. 차이는 계약 이전과 이후의 책임 구조에서 나타납니다.
| 비교 항목 | SI 파견·일반 외주 | FDE 방식 |
|---|---|---|
| 계약 시작점 | 확정된 요구사항과 제안요청서 | 아직 모호한 업무 문제와 측정할 결과 |
| 요구사항 변경 | 변경 계약과 추가 견적의 대상 | 검증 과정에 예정된 업데이트 |
| 주된 산출물 | 명세에 따른 기능과 검수 문서 | 운영 시스템, 평가셋, 인수 문서 |
| 검수 기준 | 명세 이행 여부 | 실제 사용과 운영 지표 |
| 과금 기준 | 투입 인력과 기간 | 단계별 범위와 결과 |
| 계약 종료 후 | 유지보수 계약으로 분리 | 운영 정착과 지식 이전까지 포함 |
| 프로젝트 학습 | 개별 프로젝트에서 종료 | 재사용 가능한 모듈과 플레이북으로 축적 |
차이 1: 계약이 시작되는 지점이 다릅니다
SI 계약은 요구사항이 확정된 뒤에 시작됩니다. 발주사가 무엇을 만들지 정의하고, 수행사는 그 명세를 구현하는 분업 구조입니다. FDE 방식은 요구사항이 확정되기 전, 업무 문제가 아직 모호한 시점에 시작됩니다. 팔란티어의 Dev versus Delta 역할 설명은 이 차이를 권고안을 남기고 떠나는 컨설턴트와 달리, 한 고객의 기술적 결과를 위해 여러 역량을 조합해 구현까지 책임지는 역할로 설명합니다.
생성형 AI 프로젝트에서 이 차이는 더 커집니다. 지디넷코리아 보도에서 업계 관계자는 AI 프로젝트가 초기 설계를 해두어도 구현하는 동안 계속 바뀐다고 설명했습니다. 요구사항이 계속 바뀌는 프로젝트를 확정 명세 계약으로 진행하면 변경 계약이 반복되고, 그 비용과 지연은 발주사가 부담하게 됩니다.
차이 2: 산출물과 검수 기준이 다릅니다
SI 계약의 검수는 명세 이행 여부를 확인합니다. FDE 방식의 검수는 실제 사용자가 결과를 신뢰하고 업무에 쓰는지, 운영 지표가 합의한 기준을 통과하는지를 확인합니다. 산출물 목록도 달라집니다. 기능과 검수 문서 외에 문제 정의서, 고정 평가셋과 평가 결과, 배포·모니터링·복구 문서, 운영자 인수 기록이 남아야 FDE 방식의 산출물이라고 부를 수 있습니다.
공공기관 온프레미스 NL2SQL 구축 사례처럼 업무 용어와 데이터베이스 스키마 연결, SQL 검증, 권한과 감사 로그까지 운영 흐름으로 설계하고 검수 기준을 업무 지표에 두는 방식이 FDE형 산출물의 한 예시입니다. 검수 기준이 명세 이행에만 묶여 있다면 명칭과 무관하게 SI형 계약입니다.
차이 3: 수익 구조와 인센티브가 다릅니다
투입 인력 기준 과금은 투입 시간이 늘수록 수행사 매출이 늘어나는 구조라서, 효율화와 자동화에 대한 인센티브가 구조적으로 약합니다. FDE 방식은 단계별 범위와 결과에 과금을 연결하고, 현장에서 검증된 해결책을 재사용 가능한 모듈과 플레이북으로 축적해 다음 프로젝트의 원가를 낮춥니다.
a16z가 2025년 6월 발표한 서비스 주도 성장 에세이는 구현 서비스를 외부 컨설팅에 넘기지 않고 FDE를 직접 두는 방식이 전통 컨설팅 모델로는 얻기 어려운 피드백 루프와 데이터 우위를 만든다고 설명합니다. 같은 에세이는 ServiceNow가 상장 당시 총마진 63.2%에서 2024년 79%까지 개선된 사례를 들어, 서비스 비중이 높은 초기 구조가 장기적인 제품 회사 성장과 양립한다고 주장합니다. 발주 기업 입장에서는 수행사의 학습이 자산으로 축적되는 구조인지가 다음 단계 견적과 품질에 직접 영향을 줍니다.
"국내에서 상주하면 결국 SI 아닌가요"에 대한 판별 기준
정당한 질문입니다. 판별 기준은 근무 위치가 아니라 계약과 산출물입니다. 아래 다섯 가지 질문을 실제 제안서와 계약서에 대입해 보면 명칭과 무관하게 방식을 구분할 수 있습니다.
| 판별 질문 | FDE 방식이라면 | SI 파견에 가깝다면 |
|---|---|---|
| 요구사항이 확정된 뒤 시작하는가 | 문제 정의 단계가 계약 범위에 포함 | 요구사항 문서 접수 후 구현 시작 |
| 품질을 무엇으로 검증하는가 | 합의된 고정 평가셋과 합격·거절 기준 | 시연과 명세 이행 확인 |
| 실패 사례는 어떻게 처리되는가 | 실패 로그가 개선 항목으로 기록·반영 | 다음 변경 계약으로 이월 |
| 프로젝트 후 무엇이 남는가 | 재사용 모듈, 평가셋, 플레이북 | 납품 기능과 검수 문서 |
| 인수 계획이 있는가 | 운영 문서와 교육이 범위에 포함 | 유지보수 인력 상주가 전제 |
다섯 항목 중 세 개 이상이 오른쪽에 해당하면, 계약서에 어떤 명칭이 쓰였든 SI형 구조로 보는 편이 정확합니다.
발주자가 계약서와 견적서에서 확인할 여섯 가지
제안 단계에서 아래 여섯 항목을 확인하면 명칭 논쟁 없이 방식을 구분할 수 있습니다.
- 문제 정의 단계의 분리 — 발견·검증 단계가 별도 범위와 비용으로 구분돼 있는지 확인합니다.
- 평가 기준의 명문화 — 고정 평가셋의 구성 주체, 합격·거절 기준, 회귀 테스트 계획이 문서에 있는지 확인합니다.
- 산출물 목록 — 소스코드, 프롬프트, 평가셋, 운영 문서가 납품 대상으로 명시돼 있는지 확인합니다.
- 변경 처리 방식 — 요구사항 변경이 전부 추가 견적 대상인지, 검증 루프의 일부로 흡수되는지 확인합니다.
- 운영 전환과 인수 조건 — 안정화 기간, 교육, 인수 완료 기준이 계약에 포함돼 있는지 확인합니다.
- 실제 투입 인력 — 제안 발표에 참여한 엔지니어가 실제로 개발하는지, 핵심 개발이 재하청되는지 확인합니다.
업체별로 이 항목을 같은 형식으로 받아 비교하려면 FDE 업체 선정 기준과 가이드의 RFP 체크리스트를 함께 사용할 수 있습니다.
SI 방식이 오히려 맞는 경우
FDE 방식이 모든 프로젝트의 정답은 아닙니다. 다음 조건이라면 일반 SI나 인력 보강이 더 단순하고 비용 효율적일 수 있습니다.
- 요구사항, 화면, 인터페이스와 인수 기준이 이미 확정돼 있습니다.
- 내부에 통합을 관리할 PM과 기술 리더가 있습니다.
- 규정상 확정 명세 기반 발주가 필요한 조달 환경입니다.
- 모델 출력의 불확실성이 없는 전통적인 시스템 구축입니다.
프로젝트 성격에 따라 SaaS, 전문 외주 개발사, 대형 SI 중 무엇이 맞는지는 생성형 AI 솔루션 업체 유형별 비교에서 조건별로 확인할 수 있습니다.
자주 묻는 질문
FDE는 SI 파견직의 새 이름인가요?
명칭만 바꾼 회사도 있고 실제로 다른 구조로 일하는 회사도 있습니다. 요구사항 확정 전의 문제 정의 책임, 평가셋 기반 검수, 재사용 자산 축적, 인수 계획의 네 가지가 계약에 있는지로 구분해야 합니다.
고객사에 상주하면 FDE인가요?
상주는 FDE의 정의가 아니라 수단입니다. 현장 관찰이 필요한 구간은 상주하고 개발과 문서화는 원격으로 진행하는 혼합 방식도 FDE 방식에 해당합니다.
SI 업체가 FDE 서비스를 시작했다면 무엇을 확인해야 하나요?
기존 방식에서 무엇이 달라졌는지 물어야 합니다. 문제 정의 단계의 계약 분리, 평가셋 운영 경험, 제안에 참여한 엔지니어의 실제 개발 참여 여부를 사례로 확인하는 편이 안전합니다.
맨먼스 견적과 FDE 견적은 어떻게 비교하나요?
총액이 아니라 단계별 범위와 종료 조건으로 비교해야 합니다. 발견·프로토타입 단계를 분리 견적으로 받으면 두 방식의 실제 차이가 드러납니다.
FDE 방식이 SI보다 항상 나은가요?
아닙니다. 요구사항과 인수 기준이 이미 확정된 프로젝트라면 일반 SI나 인력 보강이 더 단순하고 비용 면에서도 유리할 수 있습니다.