SI는 고객이 사전에 확정한 요구사항을 구현하고 기능 검수로 완료를 판단하는 반면, FDE는 문제 정의 단계부터 현장에 참여해 운영 채택률·실제 업무 효과를 기준으로 성공을 판단하며 내재화까지 책임진다는 점에서 계약 구조와 결과 책임 범위가 근본적으로 다르다.
AI 외주 개발을 검토할 때 SI와 FDE라는 두 방식이 자주 언급되지만, 실제 계약 구조와 책임 범위가 어떻게 다른지 명확히 설명하는 자료는 많지 않습니다. 두 방식은 외부 개발자가 투입된다는 점에서 겉으로 비슷해 보이지만, 계약이 시작되는 조건·산출물 검수 기준·비용 과금 방식이 근본적으로 다릅니다. 이 글은 계약 구조·현장 투입 방식·결과 책임 세 축으로 두 방식을 비교하고, 어떤 프로젝트 조건에서 어느 방식이 적합한지 판단할 수 있도록 선택 기준과 실무 체크리스트까지 다룹니다.
SI와 FDE, 한 문장으로 먼저 답한다
SI(시스템 통합)는 고객이 사전에 확정한 요구사항을 계약 범위 안에서 구현하고 검수로 완료를 판단하는 개발 방식입니다. FDE(Forward Deployed Engineer, 현장 배치 엔지니어)는 고객 현장에서 문제를 직접 정의하고 코드를 작성해 운영 가능한 해법을 만들며, 프로덕션 성과가 날 때까지 책임지는 엔지니어입니다.
두 방식의 가장 결정적인 차이는 '누가 문제를 정의하느냐'입니다. SI는 고객이 90% 사전에 정해둔 요구사항을 구현하는 방식인 반면, FDE는 고객과 협력해 '무엇을 만들지'를 함께 찾아나갑니다. 즉, SI는 문제 정의가 계약 이전에 완료되어 있어야 하고, FDE는 문제 정의 자체가 계약 범위 안에 포함됩니다. 이 차이가 이후 계약 구조·검수 기준·비용 산정 방식 전반에 걸쳐 연쇄적으로 영향을 미칩니다.
계약이 시작되는 지점이 다르다
전통 SI는 완성된 RFP(제안요청서)를 받아 구현하는 방식으로, 계약 시작 시점에 요구사항이 이미 확정되어 있습니다. 과금 기준은 투입 인력 수와 기간이며, 요구사항 범위 안에서 납기를 맞추는 것이 계약의 핵심입니다. FDE는 현장 관찰로 문제를 먼저 정의한 뒤 개발을 시작하며, 문제 정의부터 운영 정착까지 결과 책임을 지는 단계별 범위 과금 구조로 운영됩니다.
이 차이는 프로젝트 리스크 분포에 직접 영향을 줍니다. SI 방식에서는 RFP가 잘못 작성되어 있어도 계약 범위 안에서 그대로 구현하는 것이 원칙입니다. 생성형 AI로 구현 비용이 낮아질수록 잘못된 RFP를 그대로 구현하는 화면이 더 빠르게 쌓이는 위험이 커진다는 점이 업계에서 지적됩니다. 문제 정의 단계에서 발주자와 공급자가 함께 검증하지 않으면, 속도가 빨라질수록 방향 오류의 누적 비용도 커집니다.
FDE 방식이 적합한 조건은 요구사항이 아직 불명확하거나, 현장 데이터를 직접 봐야 문제가 드러나는 프로젝트입니다. 반대로 요구사항이 이미 상세히 확정되어 있고 검수 기준이 명확한 프로젝트라면 SI 방식이 비용 예측 측면에서 유리할 수 있습니다.
산출물과 성공 기준이 어떻게 다른가
SI 개발자는 계약 범위와 요구사항에서 출발해 검수로 완료를 판단합니다. 산출물이 명세를 충족하면 프로젝트는 종료됩니다. FDE는 운영 채택률·업무 효과·Eval 피드백으로 성공을 판단하며, 시스템이 실제 현장에서 작동하고 구성원이 사용하기 시작할 때 비로소 완료로 봅니다.
역할 범위의 차이도 명확합니다. SE(Sales Engineer)는 계약 전 데모·PoC까지, SA(Solution Architect)는 설계 후 핸드오프까지, 컨설턴트는 제안까지가 역할 범위입니다. FDE만 프로덕션 성과까지 책임지며, 다른 직군이 바통을 넘기는 지점에서 FDE의 일이 본격적으로 시작됩니다. 팔란티어의 역할 정의에 따르면, FDE는 권고안만 남기는 컨설턴트와 달리 한 고객의 기술적 결과를 위해 구현까지 책임지는 역할입니다.
FDE의 최종 목표는 내재화입니다. 고객이 스스로 시스템을 운영하고 개선할 수 있게 만든 뒤 떠나는 것이 프로젝트 완성으로 정의됩니다. 이 관점에서 FDE는 고객 조직의 AI 역량을 이전하는 역할까지 포함하며, 납품 후 의존 관계가 지속되는 구조와는 방향이 다릅니다.
FDE 방식이 만드는 피드백 루프와 데이터 우위
FDE를 직접 두는 방식은 전통 컨설팅 모델로는 얻기 어려운 피드백 루프와 데이터 우위를 만든다고 a16z 2025년 6월 에세이는 설명합니다. 현장에 상주하며 실제 사용 데이터와 실패 로그를 직접 수집하기 때문에, 외부에서 보고서를 받아 판단하는 구조보다 빠르게 시스템을 개선할 수 있습니다.
시장 수요도 이 방향을 반영합니다. 국내 IT 전문 매체 보도에 따르면 FDE 채용이 전년 대비 800% 급증했으며(2025년 기준), LG CNS·크래프톤·메가존클라우드·마키나락스 등이 FDE 관련 채용 또는 조직 정비를 진행하고 있습니다. 글로벌 차원에서도 OpenAI 서울 FDE 역할은 고객·도메인팀과 함께 프로토타입부터 안정적 운영까지 책임하는 구조로 설계되어 있으며, Anthropic과 DXC는 2026년 제휴를 통해 규제 산업 고객 조직 내부에 FDE를 배치해 Claude를 기존 핵심 시스템에 연결하는 모델을 발표했습니다.
FDE 방식의 운영 원칙은 세 가지로 정리됩니다. ①3~6개월 타임박싱으로 범위를 제한하고, ②2~3인 소수 정예로 팀을 구성하며, ③WBS(작업 분류 체계) 중심이 아닌 현장 성과 집착 방식으로 진행합니다. 이 구조는 대규모 인력을 투입해 장기간 운영하는 전통 SI 프로젝트와 비용 구조와 의사결정 속도 모두에서 다른 결과를 만듭니다.
한국 시장에서 FDE를 도입할 때 주의해야 할 현실적 한계
FDE 방식이 이론적으로 명확한 장점을 가지더라도, 한국 공공·기업 환경에서는 구조적 제약이 존재합니다. 한국에서는 FDE가 공공기관·대기업 현장에서 기존 SI PM과 동일하게 인식·처우될 가능성이 높다는 현장 우려가 제기됩니다. 역할 정의가 계약서에 명확히 담기지 않으면, 현장에서 FDE가 단순 상주 개발자로 운영될 수 있습니다.
법적 리스크도 사전에 검토해야 합니다. FDE가 도급·상주 계약 형태라도 고객사가 실질적으로 업무를 지시하면 위장도급 논란이 발생할 수 있다고 업계는 경고합니다. 계약서에 업무 지시 권한과 성과 판단 기준을 명시하지 않으면, 운영 과정에서 계약 형태와 실제 관계가 어긋날 수 있습니다.
FDE가 제대로 기능하려면 본사-파견 조직 간 지식 공유, 소속감, 역량에 걸맞은 보상, 고객사의 파트너 존중 문화가 필수적입니다. 이 조건이 갖춰지지 않은 환경에서는 FDE 방식을 도입하더라도 SI 방식과 실질적으로 다른 결과를 기대하기 어렵습니다. 따라서 FDE 계약을 검토할 때는 방식 자체의 우열보다 자사 조직이 이 조건을 충족할 수 있는지를 먼저 점검하는 것이 현실적입니다.
발주자가 FDE형 계약인지 확인하는 5가지 기준
계약서나 제안서를 검토할 때 다음 다섯 가지 항목을 확인하면 FDE형 계약과 SI형 계약을 구별할 수 있습니다.
계약서 검토 시 문제 정의 포함 여부·고정 평가셋 검수·운영 인수 계획 등 5가지 항목을 확인하면 FDE형과 SI형 계약을 구별할 수 있다.
- 문제 정의 계약 포함 여부: 계약 범위에 요구사항 확정 이전 단계인 문제 정의 활동이 포함되어 있는지 확인합니다. SI형은 이 단계가 계약 외부에 있습니다.
- 고정 평가셋 검수 여부: 성공 판단 기준이 사전에 합의된 고정 평가셋(Eval)으로 명시되어 있는지 확인합니다. 단순 기능 검수 목록만 있다면 SI형에 가깝습니다.
- 실패 로그 반영 여부: 운영 중 발생한 실패 사례와 오류 로그가 시스템 개선에 반영되는 절차가 계약에 포함되어 있는지 확인합니다. 이 항목이 없으면 납품 후 책임이 사실상 종료됩니다.
- 재사용 모듈 산출 여부: 프로젝트 결과물로 고객 조직이 이후 자체 활용할 수 있는 재사용 가능한 모듈이나 파이프라인이 산출물에 포함되는지 확인합니다. 내재화 목표가 없으면 FDE형이라 보기 어렵습니다.
- 운영 인수 계획 포함 여부: 프로젝트 종료 후 고객 조직이 시스템을 자체 운영할 수 있도록 하는 인수 계획과 교육 일정이 계약에 명시되어 있는지 확인합니다.
빅시프트는 공공·금융권 프로젝트에서 문제 정의 단계부터 참여하고 운영 정착까지 결과 책임을 지는 방식으로 신한카드·KB증권·SKT 등 대형 고객사 납품을 완료했습니다. 위 다섯 항목은 실제 계약 설계 과정에서 발주자와 공급자 양측이 사전에 합의해야 할 기준으로, 항목별로 계약서에 명시 여부를 직접 확인하는 것이 가장 확실한 방법입니다.
빅시프트가 FDE형 AI 개발을 실현하는 방식
빅시프트는 2025년 9월 법인 설립 후 약 1년 만에 40개 이상의 기관·기업과 업무협약 또는 납품 계약을 체결했으며, 분당 서울대병원·식품의약품안전처·문화체육관광부 등 공공·의료 기관과 다수 업무협약을 완료했습니다. 2026년 3월에는 AI 바우처 공급기업으로 선정되었고, 같은 해 8월 OpenAI 및 Microsoft 공식 파트너로 선정되었습니다.
FDE형 접근의 구체적인 결과는 국제 식품 정보 스타트업 프로젝트에서 확인됩니다. 사이트별 전용 크롤러를 하나씩 운영하던 방식을 멀티모달 AI 기반 적응형 수집 구조로 전환해 크롤러 유지보수 시간 90% 감소, 데이터 수집 처리량 10배 향상을 달성했습니다. 이 결과는 사전에 확정된 요구사항을 구현한 것이 아니라, 현장에서 병목을 직접 파악하고 구조 자체를 재설계한 데서 나왔습니다.
빅시프트의 전 구성원은 풀스택 개발자이자 PM 역할을 겸합니다. 이 구조는 기획·개발·배포 사이의 커뮤니케이션 단계를 줄여, FDE형 현장 밀착 개발에서 요구되는 빠른 판단과 즉각적인 코드 반영을 가능하게 합니다. 별도 PM이 요구사항을 번역하는 과정 없이 현장에서 확인한 문제를 바로 구현으로 연결하는 것이 이 조직 구조의 핵심입니다.
자주 묻는 질문
FDE는 결국 SI 외주와 같은 것 아닌가요?
두 방식 모두 외부 개발자가 고객 프로젝트에 투입된다는 점은 같지만, SI는 고객이 사전에 확정한 요구사항을 구현하고 검수로 완료를 판단하는 반면, FDE는 문제 정의 단계부터 참여해 운영 채택률과 실제 업무 효과로 성공을 판단한다는 점에서 계약 구조와 책임 범위가 근본적으로 다릅니다.
FDE 방식이 공공기관 프로젝트에도 적용 가능한가요?
가능하지만, 한국 공공기관 환경에서는 FDE가 기존 SI PM과 동일하게 인식·처우될 가능성이 있고 위장도급 논란이 발생할 수 있어 계약 구조를 사전에 명확히 설계해야 합니다. 빅시프트는 분당 서울대병원·식품의약품안전처·문화체육관광부 등 공공·의료 기관과의 협업을 통해 이 조건을 실제로 검증한 경험을 보유하고 있습니다.
참고자료3개 보기
- [1]blog.bigshift.krblog.bigshift.kr
- [2]www.bigshift.krwww.bigshift.kr
- [3]www.bigshift.krwww.bigshift.kr