교육으로 풀 문제인가, 코드로 풀 문제인가
AI 에이전트 파일럿을 운영한 기업은 78%였지만 전사 프로덕션에 도달한 곳은 14%에 그쳤다. 금융은 21%, 헬스케어는 8%로 업종별 차이도 컸다. 파일럿을 만드는 일과 운영 체계를 구축하는 일은 다르다.
PoC(개념 증명)는 정리된 데이터와 시험용 API에서 진행되지만, 실제 ERP와 인사 시스템은 사람의 화면 조작을 전제로 만들어졌고 권한과 예외 처리도 복잡하다. 시험에서는 보이지 않던 문제가 계약 뒤 드러나면서 연동은 임시방편에 머물고 시니어 엔지니어가 장애 대응에 매달린다.
IT, 보안 실무자 418명 중 82%는 조직이 몰랐던 에이전트를 발견했고 65%는 관련 사고를 겪었지만, 공식 폐기 절차가 있는 조직은 21% 에 불과했다. 권한과 수명주기를 설계하지 않은 에이전트는 운영 단계의 보안 검토를 통과하지 못한다.
연동, 권한, 운영 기능이 부족하다면 교육이 아니라 코드를 바꿔야 한다. 계약은 통제된 데모로 따내지만 갱신은 예외와 장애가 드러나는 운영 환경에서 결정된다.
Solutions Engineer vs. Forward Deployed Engineer
솔루션 엔지니어(SE)는 제품의 가능성과 고객 적합성을 입증해 계약을 돕는 역할이다. 반면 포워드 디플로이드 엔지니어(FDE)는 현장에서 드러나는 운영 문제를 코드로 풀고 반복되는 해법을 공통 제품으로 돌려보낸다. 둘의 차이는 현장에 있느냐가 아니라 메인 제품을 바꿀 책임과 권한이 있느냐다.
팔란티어는 2006년 초기 직원을 첫 FDE로 배치했다. FDE가 고객 사무실에서 문제를 풀면 제품개발 엔지니어가 결과를 일반화했다. 제품개발 엔지니어들이 반복되던 데이터 수집, 시각화, 앱 제작 업무를 도구로 제품화했다.
이처럼 FDE는 한 고객만을 위한 맞춤 납품이 아니라, 복잡한 첫 사례를 해결한 뒤 다음 고객이 설정만으로 같은 기능을 쓰게 만드는 일을 한다. 프리세일즈를 강화하면 데모는 좋아지지만 제품 결함은 고쳐지지 않는다. 일반 엔지니어를 임시 투입하면 고객별 예외 코드가 쌓이고 범위가 정해진 구현 서비스로는 현장 학습이 제품팀까지 돌아오기 어렵다.
복잡한 구축 5~10건당 FDE 한 명 이 스타트업의 참고 기준으로 제시된다. 정확한 비율보다, 고객이 늘 때 FDE가 같은 속도로 늘지 않는다는 사실이 더 문제다. 한 명이 분기 내내 한 고객만 맡는 일이 반복된다면 전담 개발 서비스에 가깝다.
FDE의 시간은 복제되지 않는다
FDE의 시간은 소프트웨어처럼 복제되지 않는다. 배포의 30~40% 이상에 큰 FDE 공수가 계속 필요하면 제품 설계를 점검해야 한다. 지원 기간과 마일스톤도 정하지 않으면 시니어 엔지니어가 상시 유지보수 인력이 된다.
계약 뒤 인력 비용은 소프트웨어 반복매출과 분리해 봐야 한다. 초기 총마진이 낮아도 첫 구현에서 만든 기능과 도구를 다음 고객에게 재사용해 비용을 낮춘다면 초기 투자는 그만큼 값어치를 한다. 반대로 고객마다 새 아키텍처와 같은 인력이 필요하다면 하나의 제품이 아니라 브랜드만 같은 컨설팅 프로젝트다.
OpenAI는 2026년 5월 FDE 약 150명을 둔 토모로를 인수해 별도 배포 조직의 기반으로 삼았다. 토모로는 슈퍼셀의 5개 게임, 1억1천만 이용자에게 지원 에이전트를 12주 만에 적용했다. 다만 배포 조직을 보유하는 것과 그 지식을 제품화하는 것은 다른 문제다.
제품화 규칙은 예를 들어 90일 안에 두 고객이 같은 우회로를 요청하면 제품화하고 통합이 2주를 넘으면 담당 제품팀을 정하며 분기 시간의 20%를 넘는 일회성 유지보수는 폐기 또는 제품화를 심사한다는 식 이다. 숫자는 회사에 맞게 조정하되 반복 문제를 현장팀에 계속 남겨두지 않아야 한다.
지표가 함께 안 움직이면 반복 배송비
깊은 통합이 필요한 엔터프라이즈 AI라면 PoC 뒤에 FDE가 필요하다. 단, 배포 인력이 아니라 빠진 제품 기능을 찾아 공통 코드로 되돌리는 엔지니어여야 한다. 따라서 FDE는 엔지니어링 조직에 속하고 코드를 소유하며 계정별 투입 종료 시점도 명확해야 한다.
현장에서 만든 코드는 메인 브랜치에 합치되 기능 플래그로 고객별 노출을 통제하고 일반 제품 코드와 같은 리뷰를 거친다. 성과는 네 가지로 측정한다.
- 계약부터 첫 성과가 나오기까지 걸린 시간
- 같은 결함의 재발 횟수
- 제품 변경으로 해결한 이슈의 비율
- 출시 뒤 계정당 주간 FDE 시간
첫 고객은 많은 사람을 투입해 성공시킨다. 정말 검증해야 할 대상은 두 번째와 세 번째 고객이다. 고객당 투입 시간과 인원이 줄면서 FDE당 매출이 올라야 현장 학습이 제품에 반영됐다는 신호다. 이 지표들이 함께 개선되지 않으면 반복 배송비를 내는 셈이다.
모든 제품에 FDE가 필요한 것은 아니다. 깊은 통합이 없는 셀프서비스 제품이거나 계약 규모가 엔지니어 투입비보다 작은 사업이라면 맞지 않는다. 구현이 이미 표준화됐거나 병목이 단순 온보딩인 경우도 마찬가지다.
도입 성과는 배포 고객 수보다 다음 고객에게 필요한 FDE 시간이 얼마나 줄었는지로 판단한다. 같은 문제를 세 번 풀었다면 네 번째에는 기본 기능이나 재사용 가능한 운영 도구로 제공한다. PoC 뒤 제품과 운영 체계에 아무것도 남지 않았다면 아직 고객의 현실을 학습하지 못했다는 뜻이다.