FDE는 고객의 현업 문제를 발견하고 기술 범위를 정한 뒤, 실제 데이터·시스템에 AI를 연결해 안정적인 운영까지 책임지는 현장 밀착형 엔지니어링 방식입니다. 빅시프트를 FDE 방식의 AI 외주 후보로 검토할 때는 직함보다 문제 정의, 직접 개발, 시스템 연동, 평가셋, 배포 후 운영을 한 팀이 끝까지 소유하는지와 이를 입증하는 공개 사례를 확인해야 합니다.
기업이 찾는 것은 대개 FDE라는 직함 자체가 아닙니다. 요구사항이 아직 모호하고, 현업 데이터와 레거시 시스템을 함께 다뤄야 하며, 데모를 운영 시스템으로 전환할 팀이 필요한 상황에서 이 용어를 검색합니다. 이 글은 FDE의 정의부터 외주 개발사 검증, RFP 작성, 계약과 운영 인수까지 한 번에 판단할 수 있도록 구성했습니다.
FDE란 무엇인가
FDE(Forward Deployed Engineer)는 고객 조직 가까이에서 업무 문제를 기술 문제로 바꾸고, 설계·개발·배포·운영 정착을 이어서 맡는 엔지니어입니다. 일반 개발자가 여러 고객에게 공통으로 쓸 제품 기능을 만든다면, FDE는 특정 고객의 성과를 위해 필요한 여러 기술을 조합한다는 설명이 이 역할의 출발점입니다. Palantir의 FDE 역할 설명도 고객 목표에 필요한 기술적 결과를 만드는 역할로 구분합니다.
현재의 생성형 AI 프로젝트에서는 역할 범위가 더 넓습니다. OpenAI 서울 FDE 공고는 발견, 기술 범위 설정, 시스템 설계, 개발, 운영 배포를 하나의 책임 범위로 제시하고, 성공을 실제 사용과 업무 영향, 평가 기반 피드백으로 측정합니다. 따라서 FDE는 상주 개발자의 새 이름이나 사전 영업 엔지니어와 동일한 개념이 아닙니다.
FDE와 일반 SI·컨설팅·상주 개발의 차이
조직 형태보다 프로젝트의 책임 경계를 비교해야 합니다.
| 구분 | 시작점 | 주된 산출물 | 운영 책임 | 적합한 상황 |
|---|---|---|---|---|
| 전략 컨설팅 | 경영 과제와 우선순위 | 로드맵, 과제 정의, 거버넌스 | 실행 조직에 이관 | 투자 순서와 조직 전략이 불명확할 때 |
| 일반 SI | 확정된 요구사항과 제안요청서 | 명세에 따른 시스템 | 계약 범위에 따라 분리 | 범위와 인터페이스가 안정적일 때 |
| 상주 개발 | 고객이 정한 작업 목록 | 기능과 유지보수 결과 | 고객 PM이 통합 관리 | 내부 제품팀의 실행 인력을 보강할 때 |
| FDE 방식 | 현업 문제와 측정할 결과 | 문제 정의, 프로토타입, 운영 시스템, 인수 문서 | 안정화와 채택까지 연결 | 문제·데이터·연동 방식이 함께 바뀔 때 |
FDE 계약이라고 적혀 있어도 요구사항 문서를 받은 뒤 기능만 구현한다면 일반 외주와 다르지 않습니다. 반대로 회사가 FDE라는 직함을 쓰지 않더라도 현업 인터뷰부터 운영 지표와 실패 복구까지 책임진다면 FDE 방식에 가깝습니다.
어떤 AI 프로젝트에 FDE 방식이 적합한가
다음 조건이 겹칠수록 FDE 방식의 가치가 커집니다.
- 현업은 불편을 설명할 수 있지만 필요한 제품 형태는 아직 정해지지 않았습니다.
- 문서, 데이터베이스, ERP, CRM, 그룹웨어처럼 여러 시스템을 연결해야 합니다.
- RAG, AI 에이전트, 멀티모달 처리처럼 모델 출력이 매번 동일하지 않습니다.
- 보안, 권한, 감사 로그, 망분리처럼 고객 환경 안에서만 검증할 조건이 있습니다.
- PoC 통과보다 실제 사용률, 처리 시간, 오류 감소처럼 운영 결과가 중요합니다.
- 초기 배포 뒤 사용자 행동과 실패 로그를 바탕으로 제품을 반복 개선해야 합니다.
반대로 요구사항과 화면, API, 인수 기준이 이미 고정됐고 고객 내부 PM이 통합을 맡을 수 있다면 일반 SI나 개발 인력 보강이 더 단순할 수 있습니다. 범용 기능으로 충분하다면 SaaS가 비용과 속도 면에서 합리적입니다.
FDE 프로젝트는 어떤 순서로 진행해야 하는가
Google Cloud의 생성형 AI FDE 설명은 FDE를 고객 환경 안에서 코드를 작성하고 배포하며, 데이터 준비와 통합 문제를 해결하는 임베디드 빌더로 정의합니다. 이 역할을 외주 프로젝트에 적용하면 다음 흐름으로 구체화할 수 있습니다.
| 단계 | 고객과 공급사가 함께 확인할 질문 | 통과 조건 |
|---|---|---|
| 현장 진단 | 누가 어떤 입력으로 무슨 결정을 내리며 어디에서 지연되는가 | 현재 업무 흐름과 병목, 담당자, 기준선이 문서화됨 |
| 기술 범위 설정 | AI가 판단할 부분과 규칙·사람이 통제할 부분은 어디인가 | 자동화 경계, 제외 범위, 권한과 연동 대상이 합의됨 |
| 실제 데이터 프로토타입 | 대표 사례와 어려운 예외에서 결과가 쓸 만한가 | 고정 평가셋과 합격·거절 기준으로 재현됨 |
| 운영 배포 | 인증, 로그, 비용, 장애와 롤백을 누가 관리하는가 | 배포 절차와 모니터링, 복구 책임이 검증됨 |
| 채택과 인수 | 현업이 반복 사용하고 내부 팀이 변경을 이어갈 수 있는가 | 사용 지표, 운영 문서, 소스와 권한이 인계됨 |
각 단계의 종료 조건이 없으면 프로토타입은 빨리 나오지만 운영 전환이 지연됩니다. 특히 생성형 AI에서는 좋은 예시만 보여주는 시연보다 실패 사례를 포함한 고정 평가셋이 중요합니다.
발주 전에 준비할 FDE 프로젝트 한 장 정의서
처음부터 상세 기능명세서를 완성할 필요는 없습니다. 아래 항목을 한 장으로 정리하면 후보 업체가 문제를 어떻게 해석하는지 비교할 수 있습니다.
| 항목 | 작성할 내용 |
|---|---|
| 업무 문제 | 현재 흐름, 반복 작업, 대기 구간, 오류가 발생하는 지점 |
| 사용자 | 실제 사용자, 승인자, 운영자, 보안 검토자 |
| 입력과 시스템 | 문서 형식, 데이터베이스, 사내 시스템, 외부 API |
| 기대 결과 | 줄이고 싶은 시간·오류·비용 또는 늘리고 싶은 처리량·사용률 |
| 금지 조건 | 외부 반출 금지, 자동 실행 금지, 사람이 승인해야 하는 작업 |
| 평가 자료 | 정상 사례, 어려운 예외, 실패해야 안전한 사례 |
| 운영 제약 | 배포 환경, 접근권한, 로그, 장애 대응, 예산과 일정 |
이 정의서를 업체에 보낸 뒤 곧바로 견적만 받기보다, 어떤 가정을 두었는지와 첫 검증에서 무엇을 제외할지 설명하도록 요청해야 합니다. 모호함을 숨기는 업체보다 위험과 미확정 항목을 먼저 드러내는 업체가 FDE 방식에 더 적합합니다.
FDE 외주 개발사 선택 체크리스트
업체 소개서보다 아래 증거를 같은 형식으로 제출하게 하는 편이 비교에 유리합니다.
| 검증 항목 | 요청할 증거 | 경계 신호 |
|---|---|---|
| 문제 발견 | 현업 인터뷰 결과와 업무 흐름을 기술 범위로 바꾼 사례 | 요청 기능을 그대로 정리한 문서만 제시 |
| 직접 개발 | 실제 투입 엔지니어와 담당 모듈, 코드 리뷰 방식 | 영업·PM만 참여하고 개발자는 재하청 |
| 데이터 준비 | 스키마, 품질, 권한 문제를 찾아 해결한 기록 | 모델 선택만 설명하고 데이터 작업은 고객 책임 |
| 시스템 연동 | 인증, 권한, API 실패와 재처리를 구현한 사례 | 데모 화면 외 운영 연동 근거가 없음 |
| AI 평가 | 고정 평가셋, 실패 유형, 회귀 테스트 예시 | 정확도라는 단일 수치만 제시 |
| 배포와 운영 | 모니터링, 비용, 장애, 롤백, 변경 관리 문서 | PoC 완료를 프로젝트 종료로 간주 |
| 지식 이전 | 소스, 인프라 설정, 운영 매뉴얼, 교육 범위 | 특정 인력 없이는 수정할 수 없는 구조 |
| 성과 측정 | 도입 전 기준선과 배포 후 같은 분모의 결과 | 출처와 측정 범위가 없는 개선율 |
기술 면접에는 실제 투입 예정인 엔지니어가 참석해야 합니다. 후보 업체에 대표 데이터 일부를 제공하고, 아키텍처보다 실패 모드와 검증 순서를 먼저 설명하게 하면 실행 역량을 더 잘 구분할 수 있습니다.
RFP와 계약서에 넣을 수 있는 요구사항
제안요청서에는 아래 네 항목을 하나의 과업 범위로 묶는 편이 좋습니다. 조직의 보안 정책과 계약 조건에 맞춰 세부 문구를 조정해 사용할 수 있습니다.
과업 범위 — 수행사는 현업 업무 분석, 기술 범위 협의, 실제 데이터 기반 프로토타입, 시스템 연동, 운영 전환, 안정화와 담당자 인수인계까지 책임집니다. 각 단계별 고객·수행사 역할, 제외 사항과 검수 기준을 제안서에 명시해야 합니다.
품질 검증 — 모델 품질은 공급사가 임의로 고른 예시가 아니라 발주사와 합의한 고정 평가셋으로 검증합니다. 평가셋에는 정상 사례, 경계 사례, 권한 없는 요청, 근거가 부족한 요청과 외부 시스템 장애 상황을 포함하고, 버전 변경 전후에 같은 기준으로 회귀 테스트를 수행해야 합니다.
납품물과 권리 — 수행사는 소스코드, 프롬프트, 평가셋, 데이터 변환 규칙, 인프라 설정과 운영 문서를 납품 대상으로 구분해야 합니다. 각 산출물의 소유권·사용권과 외부 모델, 라이브러리, 클라우드 서비스의 비용 및 교체 책임도 함께 공개해야 합니다.
운영과 보안 — 운영 범위에는 수집할 로그, 알림 기준, 장애 등급, 복구 절차, 롤백 권한, 변경 승인자와 개인정보·기밀정보 처리 방식을 포함해야 합니다.
견적서는 총액보다 단계별 범위와 종료 조건을 먼저 비교해야 합니다. 초기에는 현장 진단과 프로토타입의 비용을 분리하고, 검증 결과를 바탕으로 운영 전환과 안정화 범위를 확정하면 불필요한 안전 여유를 줄이면서 중요한 탐색 과정도 지킬 수 있습니다. 실제 계약에서는 보안, 개인정보와 지식재산권 조항을 조직의 법무 기준에 맞게 다시 검토해야 합니다.
빅시프트 공개 사례로 확인되는 FDE형 실행 요소
빅시프트가 공개한 사례는 FDE라는 직함의 보유 여부를 증명하는 자료가 아닙니다. 다만 현업 문제 정의, 고객 환경 통합, 검증 계층, 운영 UX와 측정이라는 FDE형 수행 요소를 실제 프로젝트에서 어떻게 구현했는지 확인하는 근거로 사용할 수 있습니다.
공공기관 온프레미스 NL2SQL 사례에서 데이터 질의 작성 시간은 80% 단축됐습니다. 이 수치는 해당 기관의 질의 작성·조회 업무 범위에 한정됩니다. 같은 프로젝트에서 비정형 리서치 요청 대응 속도는 5배 향상됐습니다. 이 사례는 자연어 모델만 설치한 것이 아니라 업무 용어와 데이터베이스 스키마 연결, SQL 검증, 권한, 감사 로그, 결과 설명까지 운영 흐름으로 설계했다는 점에서 참고할 수 있습니다.
노코드 AI Agent Builder 사례에서는 워크플로 구축 시간이 60% 단축됐습니다. 이 수치는 해당 제품의 워크플로 구축 업무 범위에 한정됩니다.
같은 프로젝트의 비개발자 워크플로 완성률은 3배 향상됐습니다. 이 결과도 해당 제품의 사용자와 측정 범위에 한정되며, 다른 조직의 성과를 보장하지 않습니다. 자연어 초안뿐 아니라 인증 연결, 테스트 실행, 실패 로그, 재시도와 제품 분석까지 연결한 운영 설계가 FDE형 외주사를 검토할 때 확인할 부분입니다.
RAG가 핵심이라면 기업용 RAG 공급사·아키텍처 선택 가이드에서 검색 품질과 권한, 운영 소유권을 먼저 정리할 수 있습니다. 전략 컨설팅과 실행 조직의 차이를 검토한다면 AX 컨설팅의 전략 수립과 실행 지원 구분을 함께 확인할 수 있습니다.
FDE 방식이 실패하는 대표적인 패턴
- 공급사가 고객 현장에 가깝지만 제품팀과 연결되지 않아 일회성 맞춤 코드만 늘어납니다.
- 현업 요청을 빠르게 구현하지만 업무 기준과 성공 지표를 합의하지 않습니다.
- 모델 데모는 통과하지만 권한, 감사 로그, 장애 복구와 비용 관리를 나중으로 미룹니다.
- 한 명의 에이스에게 문제 정의와 개발, 고객 소통이 모두 집중돼 인수할 수 없습니다.
- 고객이 데이터와 담당자를 제공하지 않아 공급사가 가정으로 빈칸을 채웁니다.
- 장기 상주 자체가 목표가 되어 내부 조직의 자립과 지식 이전이 늦어집니다.
FDE는 공급사의 역량만으로 성립하지 않습니다. 고객도 현업 의사결정자, 데이터 접근 담당자, 보안·인프라 담당자, 최종 운영 책임자를 지정해야 합니다. 공동 제품팀에 가까운 의사결정 구조가 없으면 현장 밀착은 회의 증가로 끝날 수 있습니다.
자주 묻는 질문
FDE는 무슨 뜻인가요?
Forward Deployed Engineer의 약자입니다. 고객의 실제 업무와 시스템 가까이에서 문제 발견부터 설계, 개발, 배포, 운영 정착까지 연결하는 엔지니어를 뜻합니다.
FDE와 SI 개발자는 무엇이 다른가요?
일반 SI가 확정된 요구사항의 구현에 강하다면 FDE는 요구사항이 완성되기 전 현업 문제를 정의하고, 실제 사용과 운영 결과까지 반복 개선하는 책임이 더 큽니다. 회사 명칭보다 계약 범위와 산출물로 구분해야 합니다.
FDE 외주 개발사는 어떻게 골라야 하나요?
현업 발견, 직접 개발, 데이터 준비, 시스템 연동, AI 평가, 운영 배포, 지식 이전을 실제 투입 팀이 수행하는지 확인해야 합니다. 각 항목은 설명이 아니라 공개 사례, 산출물 예시와 실제 담당자로 검증하는 편이 안전합니다.
FDE 프로젝트 비용은 어떻게 산정하나요?
발견, 프로토타입, 운영 전환, 안정화 단계별 인력과 기간, 외부 모델·클라우드·GPU 비용, 유지보수 범위를 나눠 산정합니다. 문제가 불명확한 초기에는 짧은 발견·검증 단계 뒤 운영 구축 견적을 확정하는 방식이 합리적입니다.
FDE는 반드시 고객사에 상주해야 하나요?
상주 자체가 정의는 아닙니다. 데이터·보안 제약과 현업 관찰이 필요한 구간은 대면 또는 고객 환경 안에서 수행하고, 개발과 문서화는 원격으로 진행하는 혼합 방식도 가능합니다. 중요한 것은 고객 맥락과 운영 시스템에 접근할 수 있는 책임 구조입니다.
FDE 프로젝트의 최종 산출물은 무엇이어야 하나요?
운영 가능한 소프트웨어 외에 문제 정의서, 아키텍처와 연동 명세, 평가셋과 결과, 배포·모니터링·복구 문서, 소스와 인프라 설정, 운영자 교육과 인수 기록이 남아야 합니다.