FDE와 SI 외주개발 차이: 요구 변경과 운영 책임을 비교하는 기준

FDE와 SI 외주개발의 차이는 이름보다 업무를 발견하는 과정, 요구 변경을 승인하는 규칙, 출시 후 운영 책임을 어떻게 정했는지로 비교해야 합니다. FDE 협업은 현업과 반복해서 구현 경로를 찾는 데 무게를 둘 수 있지만 무제한 변경을 뜻하지 않습니다. SI도 업무 탐색과 반복 개발을 포함할 수 있으므로 같은 업무·평가·인수 조건을 제안서에 넣어 실제 수행 방식을 확인하세요.

SI는 시스템 통합을 뜻하는 System Integration의 약자이고, 외주개발은 일을 외부 조직에 맡기는 계약 관계를 가리킵니다. 두 말은 완전히 같은 분류가 아닙니다. FDE도 Forward Deployed Engineer 또는 Engineering이라는 역할·협업의 명칭이므로 외주 여부를 대신 설명하지 못합니다. 고객팀과 밀접하게 일하는 외부 엔지니어가 있을 수 있고, SI 프로젝트 안에 그런 역할을 배치할 수도 있습니다. 이름만 놓고 서로 배타적인 선택지로 보면 제안의 실제 조건을 놓칩니다.

범위가 잘 정리된 업무라면 산출물과 검수 기준을 합의해 구현하는 방식이 맞을 수 있습니다. 반대로 현업이 어느 단계에서 막히는지, 현재 모델과 데이터로 해결할 수 있는지부터 확인해야 한다면 탐색과 평가에 시간을 배정한 협업이 필요합니다. 이 차이를 FDE와 SI의 일률적인 우열로 바꾸지는 마세요. 발주자가 검토할 대상은 미정인 문제를 누가 얼마나 오래 다루고, 그동안의 결정이 다음 구현과 비용에 어떻게 연결되는지입니다.

이 글은 동일한 가상 AI 업무를 놓고 두 제안을 비교하는 실무 안내입니다. 어떤 회사의 계약 사례나 표준 단가를 재현한 것이 아닙니다. 비교할 제안은 편의상 범위 명세 중심 제안과 반복 탐색 중심 제안으로 부르며, 각각이 SI 또는 FDE 전체를 대표하지 않습니다. 실제 제안에 탐색과 납품이 섞여 있다면 단계별로 나눠 읽으세요. 한 업체를 선택하더라도 처음과 끝의 협업 방식은 달라질 수 있습니다.

공식 FDE 설명과 우리 계약의 조건을 구별한다#

2026년 10월 28일 확인한 OpenAI의 10월 22일 글은 실제 고객 업무를 배우고 평가하며 결과를 재사용하는 자사 FDE 활동을 설명합니다. 공식 사업 페이지에서는 Product·Research 팀과의 연결, professional services 파트너와의 협업, 출시 후 고객팀의 역량 이전을 구분합니다. 이를 모든 FDE가 제공하는 계약 조건으로 읽을 수는 없습니다. 이 글의 두 제안 유형과 변경표는 발주 검토용 설계 예시이며 OpenAI의 계약 방식이나 국내 SI의 공통 관행을 입증하는 자료가 아닙니다.

• OpenAI FDE 역할 원문: 고객 업무 학습·평가·재사용의 설명. SI 대비 우월성이나 일반 단가의 근거가 아님.
• OpenAI FDE 협업 안내: 해당 회사의 조직 연결·파트너·내부 이전 설명. 다른 업체의 지원 보장이 아님.

변경을 허용하는 규칙과 멈추는 조건을 같이 정한다#

발주서에는 모르는 항목을 빈칸으로 감추지 말고 미정 목록으로 남깁니다. 주문 문의에서 거래처 식별이 가능한지, ERP 갱신 시각을 읽을 수 있는지, 부서별 열람 범위가 다른지 등이 여기에 들어갑니다. 범위 명세 중심이라면 이 항목을 언제까지 누가 확정할지 적고, 반복 탐색 중심이라면 어떤 관찰과 실험으로 판단할지 정하세요. 미정이 풀리지 않을 때 기간을 늘릴지 기능을 줄일지 결정할 사람이 필요합니다. 실패한 가설도 확인한 결과로 남겨 다음 팀이 같은 탐색을 반복하지 않게 합니다.

변경 요청은 요청자, 업무상 이유, 영향을 받는 사용자와 데이터, 희망 적용일을 기록하는 데서 시작합니다. 구현팀은 예상 투입과 다른 기능에 미칠 영향, 평가와 운영 위험을 설명하고 고객 책임자는 채택·보류·제외를 결정합니다. 금액이나 일정에 영향이 없는 변경이라도 권한과 외부 전송 범위가 바뀌면 승인이 필요할 수 있습니다. 작은 수정이라는 이름이 승인 절차를 건너뛰는 근거가 되지 않도록 위험 항목을 별도로 표시하세요.

반복 탐색을 택했다면 시간 한도와 우선순위 교체 규칙이 특히 중요합니다. 회의마다 새 기능이 추가되면서 기존 기능을 모두 유지한다면 탐색이 무제한 개발로 변합니다. 이번 반복의 목적, 사용할 인력과 시간, 다음에 판단할 날짜, 남은 과업을 함께 보세요. 변경을 받아들이는 대신 미루는 항목이 생기면 그 항목의 사용자에게도 알립니다. 범위를 줄여도 안전과 권한 검증까지 빠지는지 따져야 하며 검증을 못 한 기능은 출시 대기 상태로 남깁니다.

범위 명세를 택했더라도 현업 질문을 모두 추가 비용으로만 처리할 필요는 없습니다. 처음 합의한 동작과 다른 결함, 미리 알린 가정의 변화, 새 업무 요구를 구별할 기준을 만들 수 있습니다. 반대로 처음 듣는 모든 요청을 하자 수정으로 부르면 공급자가 작업량을 판단하기 어렵습니다. 쟁점이 생겼을 때 계약의 어느 버전과 검수 표본을 참조할지 연결해 두세요. 여기서 설명하는 구분은 운영 협의를 위한 것이며 실제 대가와 책임을 정하는 문구는 개별 계약에서 검토합니다.

자료 제공이 늦어지는 상황도 변경 기록에 넣습니다. ERP 접근을 받지 못해 가린 파일로만 검증했다면 확인한 범위와 미확인 범위를 구분해야 합니다. 구현팀이 연결할 수 없는 환경을 성공 시연으로 포장해서는 안 되고, 고객도 접근 대기를 전부 구현팀의 지연으로 돌려서는 곤란합니다. 제공 책임자, 기다리는 자료, 그동안 가능한 과업, 전체 일정을 다시 판단할 조건을 기록합니다. 출입과 계정이 준비돼도 실제 데이터 사용 허용 범위가 다르면 다시 확인하세요.

사업상 효과가 확인되지 않으면 탐색을 멈출 수 있는 기준도 필요합니다. 예를 들어 담당자의 검토 부담이 줄지 않고 예외 처리도 안정되지 않는다면 원인을 분석한 뒤 과업을 줄이거나 종료를 선택할 수 있습니다. 이것을 모든 FDE의 실패 보상이나 무상 추가 개발 약속으로 읽지는 마세요. 이미 만든 자산과 평가 기록을 어떤 상태로 받을지, 미완료 과업과 남은 접근 권한을 어떻게 정리할지 합의해 두면 중단 뒤에도 결정 근거를 보존할 수 있습니다.

운영 인수표로 협업 방식의 마지막 빈칸을 찾는다#

인수 때는 처음 참여하지 않은 운영자가 가상 주문 문의의 정상·누락·권한 차단을 재현하게 합니다. 평가를 실행하고 결과가 달라진 표본을 찾은 뒤 설정을 바꾸거나 기능을 되돌리는 경로를 확인하세요. 원개발자가 옆에서 매번 명령을 알려 줘야 한다면 인수 문서나 교육이 덜 된 상태입니다. 범위 명세 중심 계약은 산출물 체크에 이 시연을 더할 수 있고, 반복 탐색 중심 계약은 과정에서 쌓은 업무 지식을 다른 담당자가 쓰는지 확인하는 자리로 삼을 수 있습니다.

사고 대응표에는 연락처만 적지 않습니다. 누가 사건을 접수하고, 누가 업무 영향을 판정하며, 어떤 권한으로 기능을 멈추고 다시 여는지 연결합니다. 외부 API 장애나 모델 동작 변화처럼 구현팀이 원인을 통제하지 못하는 사건도 있을 수 있습니다. 그때도 감지·설명·우회·재개 검증 중 누가 무엇을 맡는지는 정할 수 있습니다. 원인을 고칠 책임과 고객에게 상황을 설명할 책임이 다르면 둘 다 표에 남기세요.

소스코드와 데이터 외에 평가 표본, 업무 규칙의 결정 이력, 연결 설정, 배포 기록, 알려진 실패와 제외 범위가 필요합니다. 고객 계정에 자산이 남는지, 공급자의 공통 코드나 유료 도구를 계속 쓸 조건이 무엇인지도 확인합니다. 계약 종료 후 유지할 권한과 회수할 권한을 나누고 새 운영자가 필요한 비밀을 교체한 뒤 재실행할 수 있어야 합니다. 특정 사람이 계속 접속해 줘야만 돌아가는 상태를 완전한 이전으로 취급하지 않습니다.

두 제안을 고를 때는 현재 불확실성이 어디에 남았는지로 돌아가면 됩니다. 입력·출력과 실패 조건이 명확하다면 그 범위를 책임 있게 납품하고 인수할 제안을 찾습니다. 현업 판단과 구현 경로를 계속 발견해야 한다면 참여 시간, 탐색 한도와 중단 결정을 갖춘 제안을 검토하세요. 탐색 단계 뒤 범위를 확정해 구현 계약으로 넘어가는 조합도 가능합니다. 어느 선택이든 고객 내부의 정책 승인자와 운영 인수자가 사라지지는 않습니다.

최종 비교표에는 업체가 스스로 붙인 방식 이름 옆에 실제 약속을 적습니다. 누가 현업을 만나고, 변경을 며칠마다 판단할지, 남은 투입을 어디에서 볼지, 종료 때 무엇을 재현할지 답이 남아야 합니다. 정해진 반복 주기는 예시일 뿐 회사의 승인 속도와 위험에 맞춰 협의할 항목입니다. 설명이 구체적인 제안부터 같은 표본으로 검토하면 상주 인원수나 멋진 시연에 가려졌던 운영 책임을 확인할 수 있습니다.

역할과 고객 준비 조건은 FDE 뜻과 역할에서 확인할 수 있습니다. 투입 한도를 정할 때는 FDE 프로젝트 비용 산정의 가정 워크시트를 참고하세요. 내부팀 보유 판단은 SI와 인하우스 개발팀 비교로 구분했습니다. 일반 계약 항목은 소프트웨어 외주 계약 체크리스트에 정리했습니다. SaaS까지 포함한 선택은 AI 챗봇 도입 방식 비교를 함께 살펴보세요.