AI 기능을 도입하려는데 요구사항은 계속 바뀌고, 현업은 “써보면 알 것 같다”고 말하며, 개발팀은 데이터와 승인 권한이 없다고 멈추는 상황이 있습니다. 이때 외부 업체가 FDE(Forward Deployed Engineer)를 투입하겠다고 제안하면, 많은 의사결정자는 전통 SI와 무엇이 다른지부터 묻게 됩니다.
판단의 기준은 고객사 현장에 사람이 나오는지, AI를 쓰는지, 직함이 무엇인지가 아닙니다. 제품이 배포된 뒤 누가 사용 정착, 성능 검증, 운영 문제 해결, 다음 개선 우선순위까지 책임지는가가 핵심입니다. 이 책임 구조가 없다면 FDE라는 이름을 붙였더라도 수행 방식은 전통적인 구축형 SI에 가까울 수 있습니다.
세 수행 모델은 무엇을 끝으로 보는가
전통 SI, FDE, 인하우스팀은 모두 업무 시스템을 만들 수 있습니다. 차이는 프로젝트의 완료 조건과 계약 이후의 행동에서 드러납니다.
| 비교 축 | 전통 SI | FDE 방식 | 인하우스팀 |
|---|---|---|---|
| 주된 완료 기준 | 약정 범위의 개발·검수·인수 | 현업 성과가 나는 제품의 배포·정착·개선 | 사업과 제품의 지속 성과 |
| 요구사항 변화 | 변경 계약 또는 별도 범위로 관리하기 쉬움 | 성과 목표 안에서 우선순위를 재조정 | 조직 내부 우선순위에 따라 상시 조정 |
| 현업과의 관계 | 발주자와 수행사 관계가 중심 | 공동 운영자에 가까운 밀도 높은 협업 | 같은 조직의 업무 조정 |
| 배포 후 책임 | 하자보수·유지보수 범위에 따라 제한 | 사용성, 운영 흐름, 모델 품질을 계속 확인 | 제품 수명주기 전체를 담당 |
| 축적되는 자산 | 산출물, 소스코드, 운영 문서 | 재사용 가능한 제품 역량과 현장 학습 | 조직의 도메인 지식과 제품 역량 |
| 주된 위험 | RFP 밖의 문제를 해결하지 못함 | 책임 범위가 모호하면 고비용 상주 개발로 흐름 | 채용·리더십·우선순위 부족으로 속도가 느려짐 |
여기서 FDE의 본질은 “현장에 배치된 개발자”가 아닙니다. 현업의 업무 흐름, 데이터 제약, 의사결정권자를 이해한 뒤 제품을 바꾸고, 그 변화가 운영 결과로 이어지는지 확인하는 역할입니다. 개발을 완료했는데 사용자가 돌아오지 않거나, AI 출력이 검토 대기열만 늘리거나, 담당자가 바뀌자 프로세스가 멈춘다면 FDE의 일이 끝났다고 보기 어렵습니다.
반대로 SI가 모두 낮은 수준의 방식이라는 뜻도 아닙니다. 범위가 안정적이고, 연계 대상과 검수 기준이 명확하며, 배포 후 운영 주체가 고객사에 준비되어 있다면 SI는 예측 가능한 비용과 일정으로 구축을 진행하는 데 적합합니다. 문제는 성과 책임이 필요한 과제를 구축 계약처럼 다루거나, 구축 과제를 FDE라는 이름으로 과도하게 포장하는 데 있습니다.
FDE가 맞는 프로젝트와 맞지 않는 프로젝트
FDE 방식은 불확실성이 큰 과제에서 힘을 발휘할 수 있습니다. 특히 다음 조건이 겹칠 때 검토할 이유가 있습니다.
- 현업이 해결하려는 문제는 분명하지만, 화면·기능·에이전트 작업 흐름은 아직 확정되지 않았다.
- 모델 정확도보다 업무 처리시간, 누락 감소, 승인 속도, 매출 또는 비용 같은 운영 결과가 중요하다.
- 데이터 품질, 권한, 예외 처리, 사용자 교육을 제품 개발과 함께 풀어야 한다.
- 한 부서에서 검증한 방식을 다른 팀이나 지점으로 확장할 가능성이 있다.
- 고객사 내부에 제품 책임자나 운영 책임자가 있지만, AI·소프트웨어 실행 역량이 부족하다.
예를 들어 AI가 문서를 요약하는 기능을 만드는 일은 비교적 좁은 개발 과제로 정의할 수 있습니다. 반면 AI가 문서를 분류하고, 담당자에게 배정하고, 위험 항목을 올리고, 사람이 수정한 결과를 다음 업무 규칙에 반영하는 체계를 만들려면 이야기가 달라집니다. 이 과제는 모델 API를 붙이는 것보다 현업의 예외 처리와 승인 경로를 바꾸는 일이 더 어렵습니다. FDE는 이 경계에서 제품과 운영을 함께 다루는 모델입니다.
반대로 다음 상황이라면 전통 SI 또는 인하우스가 더 적합할 수 있습니다.
- 법정 서식, 정해진 업무 규칙, 고정된 인터페이스를 구현하는 것이 주된 과제다.
- 고객사가 제품 책임자, 데이터 담당자, 플랫폼팀을 이미 갖추고 있어 외부의 상시 개입이 필요하지 않다.
- 외부 인력이 핵심 업무 권한이나 데이터에 장기간 접근하기 어려워 운영 개선을 함께 수행할 수 없다.
- 프로젝트의 성공 기준이 사용 성과가 아니라 특정 시스템의 교체, 연계, 이전 완료다.
- 해당 역량이 회사의 장기 경쟁력과 직접 연결되어 내부 채용·조직화가 더 타당하다.
인하우스팀은 가장 많은 맥락을 축적할 수 있지만, 채용만으로 해결되지는 않습니다. 사업 책임자와 개발 책임자가 같은 우선순위를 공유하고, 운영 데이터에 접근하며, 출시 뒤 개선 시간을 확보해야 합니다. 이 조건이 없으면 인하우스팀도 내부 SI처럼 요청을 처리하는 조직이 되기 쉽습니다.
이름보다 계약과 운영 리듬을 확인해야 한다
업체가 FDE를 제안할 때는 인력의 경력보다 책임 구조를 먼저 확인해야 합니다. 다음 질문에 구체적으로 답하지 못한다면, 상주형 개발 또는 인력 투입 계약일 가능성을 염두에 둘 만합니다.
-
배포 뒤 무엇을 성공으로 판단하는가?
기능 수, 화면 수, 개발 완료가 아니라 사용률, 처리시간, 오류율, 승인 지연, 전환율처럼 프로젝트에 맞는 운영 지표가 제시되어야 합니다. 다만 모든 지표를 외부 업체가 통제할 수는 없으므로, 업체 책임 지표와 고객사 책임 지표를 나눠야 합니다. -
현업의 요구가 바뀌면 누가 우선순위를 정하는가?
FDE 방식은 변경을 무제한으로 받아주는 방식이 아닙니다. 성과 목표를 유지하면서 무엇을 만들고 무엇을 미룰지 결정하는 회의체, 책임자, 주기가 있어야 합니다. -
모델 품질 저하와 업무 예외를 어떻게 발견하는가?
AI 프로젝트라면 정확도만 보지 말아야 합니다. 어떤 입력에서 실패했는지, 사람이 언제 개입했는지, 잘못된 결과가 어느 업무 단계로 흘렀는지 기록하고 검토하는 운영 설계가 필요합니다. -
현장 학습은 다음 고객과 다음 제품에 어떻게 반영되는가?
FDE 조직은 매 고객사 요구를 처음부터 맞춤 개발하는 데 머물지 않습니다. 공통 기능은 제품으로 흡수하고, 고객별 규칙은 설정·연동·운영 절차로 분리하려는 기준이 있어야 합니다. -
고객사 쪽에서 누가 매주 결정을 내리는가?
FDE가 성과를 내기 어려운 가장 이른 신호는 외부 팀이 기다리는 시간이 개발 시간보다 길어지는 경우입니다. 데이터 접근, 정책 승인, 현업 테스트, 예외 기준을 결정할 고객사 책임자가 정해지지 않으면 상주 인력만 늘어날 수 있습니다.
실패는 기술 부족보다 책임 공백에서 시작된다
FDE 도입이 실패하는 전형적인 모습은 “외부 팀이 현업을 대신 이해해주겠지”라는 기대에서 출발합니다. 고객사는 데이터와 의사결정권을 제공하지 않고, 업체는 결과 지표를 통제할 수 없으며, 양측은 기능 목록만 주고받습니다. 이 구조에서는 FDE도 결과적으로 SI와 같은 방식으로 움직일 수밖에 없습니다.
또 다른 위험은 성과 책임이라는 말을 무제한 범위의 약속으로 해석하는 것입니다. 매출, 비용, 생산성은 제품 외에도 가격 정책, 인력 운영, 영업 실행, 공급망 등 여러 요인의 영향을 받습니다. 따라서 계약과 운영 계획에서는 제품이 직접 바꿀 수 있는 선행 지표와 사업 결과 지표를 구분하는 편이 낫습니다. 예를 들어 “AI 기능을 만들었는가”보다 “담당자가 제안 결과를 검토하는 시간이 줄었는가”가 가까운 지표일 수 있고, 매출 변화는 그 뒤에 확인할 결과일 수 있습니다.
선정 전에 작은 운영 단위를 함께 시험하라
수행 모델을 고를 때는 대형 구축 계획보다 작은 운영 단위를 먼저 설계하는 편이 안전합니다. 한 업무 흐름을 정하고, 사용자 집단을 좁히고, 사람의 승인 지점을 남긴 뒤, 배포 후 어떤 행동과 결과를 볼지 합의합니다.
이 시험에서 봐야 할 것은 데모의 완성도가 아닙니다. 업체 또는 후보 팀이 다음 행동을 하는지 확인해야 합니다.
- 현업의 불만을 기능 목록으로 바로 번역하지 않고, 업무 흐름과 예외를 확인하는가
- 데이터 부족, 권한 문제, 책임자 부재를 개발 과제가 아닌 프로젝트 위험으로 올리는가
- 출시 후 수정 요청을 받아 적는 데 그치지 않고, 사용 로그와 운영 결과로 우선순위를 다시 정하는가
- 고객사 담당자가 빠져도 운영할 수 있도록 권한, 문서, 검토 절차를 남기는가
- 맞춤 개발 요구와 재사용 가능한 제품 기능을 구분해 설명하는가
FDE를 선택한다면 “몇 명이 몇 개월 투입되는가” 다음 질문을 붙여야 합니다. 그 기간이 끝났을 때 우리 조직은 어떤 업무 지표를 보고, 어떤 문제를 스스로 고치며, 어떤 개선은 계속 파트너와 함께할 것인가. 이 질문에 양측이 같은 답을 만들 수 있을 때, FDE는 이름만 바꾼 SI가 아니라 제품 성과를 함께 만드는 수행 모델이 될 수 있습니다.
