회의실에서는 에이전트가 잘 돈다. 샘플 문서도 읽고, 질의응답도 하고, 데모 화면도 그럴듯하다. 그런데 현장으로 내려가면 멈춘다. 권한이 다르고, 데이터 이름이 다르고, 예외가 많고, 최종 승인자가 매번 다르다. 이때 필요한 사람은 발표 자료를 고치는 컨설턴트가 아니다. 현장 옆자리에서 업무 규칙을 코드와 운영 절차로 바꾸는 엔지니어다.
FDE는 컨설턴트와 엔지니어의 분업을 끊는다
Forward Deployed Engineer, 즉 FDE 모델의 핵심은 단순한 상주 인력이 아니다. 고객사 현장에 들어가 문제 정의, 아키텍처, 통합, 권한, 평가, 운영 전환을 한 흐름으로 잡는 구조다.
전통적 딜리버리는 전략팀이 과제를 정의하고, 개발팀이 구현하고, 운영팀이 넘겨받는다. 이 방식은 SaaS 도입이나 대시보드 구축에는 버틴다. 에이전트에는 약하다. 에이전트는 업무 시스템을 읽고, 도구를 호출하고, 사람에게 승인을 요청하고, 실패 로그를 남겨야 한다. 전략과 구현 사이의 간격이 곧 리스크가 된다.
OpenAI도 Enterprise Frontier Program에서 forward deployed engineers가 고객팀과 함께 아키텍처를 설계하고, 거버넌스를 운영화하며, 에이전트를 프로덕션에서 운영한다고 설명한다. 이 표현이 중요하다. ‘설계 자문’이 아니라 ‘run agents in production’이다. (openai.com)
에이전트 딜리버리의 책임 단위는 PoC 산출물이 아니라 운영 중인 업무 흐름이다.
PoC 이후가 아니라 첫날부터 운영을 설계한다
에이전트는 모델 성능만으로 운영되지 않는다. 권한 경계, tool orchestration, context engineering, memory 전략, 예외 처리, human-in-the-loop, 감사 로그가 붙어야 업무가 된다. Anthropic과 Google Cloud의 2026년 세션도 프로덕션 에이전트에서 tool call마다 guardrail을 적용하고 trace와 audit event를 관측 체계로 보내는 문제를 다룬다. (anthropic.com)
현장에서 반복되는 실패는 비슷하다.
| 기존 접근 | FDE 접근 |
|---|---|
| PoC 성공 후 운영 논의 | 첫 주부터 운영 조건 정의 |
| 프롬프트 품질 중심 | 권한·도구·로그·평가까지 포함 |
| 개발 완료 후 현업 검수 | 현업 예외를 매일 설계에 반영 |
| 인수인계 문서로 종료 | 운영 패턴을 고객팀이 소유하게 전환 |
Deloitte의 2026 State of AI 발표는 AI 실험이 늘지만 production 전환과 agent governance가 병목임을 보여준다. 응답 기업 중 40% 이상 파일럿을 production으로 옮긴 곳은 25%였고, mature agent governance를 갖췄다고 답한 곳은 21%였다. 이 숫자는 현장에서 보는 감각과 맞다. 문제는 아이디어 부족이 아니라 운영 구조 부족이다. (deloitte.com)
AX 컨설팅의 FDE는 산출물이 아니라 책임 구조다
AX LABS가 말하는 FDE는 벤더 파견 개발자와 다르다. 특정 제품을 설치하러 가는 사람이 아니다. 고객사의 업무 책임자, IT, 보안, 데이터 오너, 현장 사용자를 연결해 에이전트가 실제 업무를 맡을 수 있는 조건을 만든다.
AX Ops 안에서 FDE의 책임은 네 가지다.
- 업무를 에이전트 단위로 자른다. 사람이 계속 해야 할 판단과 에이전트가 맡을 반복 실행을 분리한다.
- harness를 설계한다. context, memory, tool, policy, log, fallback을 한 묶음으로 잡는다.
- 평가를 운영에 붙인다. 정답률만 보지 않고 승인 반려, 재시도, 에스컬레이션, 사용자 개입을 본다.
- 고객팀으로 소유권을 넘긴다. 외부팀이 빠진 뒤에도 현업과 IT가 개선 루프를 돌릴 수 있어야 한다.
Palantir AIP 문서가 production-ready workflow, agents, functions, evals, observability를 한 플랫폼의 구성요소로 묶는 것도 같은 이유다. 에이전트는 데모 앱이 아니라 운영체계 위에서 굴러간다. (palantir.com)
참고와 다음 행동은 명확하다
FDE 모델은 유행하는 직무명이 아니다. AX 프로젝트의 책임 경계를 다시 긋는 방식이다. 고객사는 “어떤 에이전트를 만들 것인가”보다 먼저 “누가 현장에서 프로덕션까지 책임질 것인가”를 정해야 한다.
참고 자료:
- OpenAI, Frontier enterprise platform, 2026 현재 공식 페이지 — https://openai.com/business/frontier/
- Anthropic·Google Cloud, Monitoring and Securing Agents at Scale, 2026 — https://www.anthropic.com/webinars/claude-on-google-cloud-monitoring-and-securing-agents-at-scale
- Deloitte, State of AI in the Enterprise 2026 press release, 2026 — https://www.deloitte.com/us/en/about/press-room/state-of-ai-report-2026.html
- Palantir, AIP overview and observability documentation, 2026 현재 공식 문서 — https://www.palantir.com/docs/foundry/aip
- McKinsey, Building the foundations for agentic AI at scale, 2026 — https://www.mckinsey.com/capabilities/mckinsey-technology/our-insights/building-the-foundations-for-agentic-ai-at-scale
AX를 도입 과제가 아니라 운영 구조로 만들려면 FDE 역할을 프로젝트 맨 앞에 세워야 한다. AX LABS의 딜리버리 구조는 사업 영역 →에서 확인할 수 있다.