AX는 CoE보다 FDE가 필요하다
AX가 실험에서 현장 성과로 넘어가려면 중앙 CoE와 현장 FDE형 실행조직을 함께 설계해야 합니다. 역할 경계, 운영 구조, AI 에이전트 실행 기준을 정리합니다.
많은 기업이 AX를 이야기할 때 가장 먼저 떠올리는 것은 전담 조직입니다. AI 전략을 세우고, 표준을 만들고, 좋은 사례를 모아 전사로 확산하는 조직. 흔히 CoE, 즉 Center of Excellence라고 부르는 형태입니다.
CoE는 필요합니다. 하지만 AX가 실제 업무를 바꾸는 단계로 들어가면 CoE만으로는 부족합니다. AI는 슬라이드에 적힌 전략이 아니라 현장의 데이터, 시스템, 권한, 예외 상황 속에서 작동해야 하기 때문입니다.
그래서 AX를 제대로 보려면 CoE와 함께 FDE라는 관점을 봐야 합니다. FDE는 Forward Deployed Engineer의 약자로, 이 글에서는 현장 가까이에서 문제를 정의하고 기술 구현과 사용자 정착을 연결하는 실행 역할을 가리킵니다. 특정 기업의 고유 직무 체계를 그대로 옮긴 말이 아니라, AX 현장에서 필요한 역할 패턴으로 사용합니다.
한 줄 요약: AX의 성과는 중앙의 표준만으로 만들어지지 않습니다. CoE가 기준과 공통 기반을 만들고, FDE형 역할이 현장의 문제를 실제 시스템과 업무 흐름으로 연결할 때 비로소 작동합니다.
AX는 왜 조직 설계의 문제가 되는가
AX는 AI Transformation의 줄임말로 쓰이지만, 실제 의미는 단순한 AI 도입이 아닙니다. 챗봇 하나를 붙이거나 회의록 요약 도구를 배포하는 것만으로는 AX라고 부르기 어렵습니다.
AX의 본질은 업무가 AI를 전제로 다시 설계되는 데 있습니다. 보고서 작성 업무를 예로 들면, 데이터가 자동으로 들어와야 하는지, 어떤 판단은 AI가 제안하고 어떤 판단은 사람이 승인해야 하는지, 결과는 어느 시스템에 기록돼야 하는지까지 다시 정해야 합니다.
데이터 접근 권한이 없고, 최신 수치가 연결되지 않고, 결과 검증 기준이 없다면 AI는 결국 글을 잘 쓰는 보조 도구에 머뭅니다. 이 지점부터 AX는 기술 프로젝트만이 아니라 운영 모델의 문제가 됩니다.
가상 예시 — 중견 제조기업 A사는 전사 생성형 AI 라이선스와 사내 챗봇을 배포했지만 현업 사용은 낮았습니다. 영업팀에는 CRM 맥락이 연결되지 않았고, 물류팀에는 사람이 다시 확인해야 하는 예외가 많았습니다. 플랫폼은 있었지만 현장 업무와 연결하는 마지막 단계가 비어 있던 사례입니다.
이 예시가 보여주는 핵심은 명확합니다. 도구 배포와 업무 재설계 사이에는 간극이 있고, 그 간극을 메우는 일이 조직 설계입니다.
CoE가 잘하는 일과 한계
CoE는 AX 초기에 매우 유용합니다. 전사 AI 전략을 정리하고, 보안 기준을 만들고, 공통 플랫폼을 선정하고, 교육 프로그램을 운영할 수 있습니다. 여러 부서가 제각각 도구를 도입하면서 생기는 중복과 보안 위험도 줄일 수 있습니다.
IBM은 AI Center of Excellence를 전사 AI 채택, 최적화, 거버넌스를 지원하는 운영 구조로 설명합니다. 전략 수립, 거버넌스, 인재 양성, 우수 사례 확산이 핵심 기능입니다.
특히 기업 환경에서는 다음 역할이 중요합니다.
- AI 활용 원칙과 가이드라인 수립
- 공통 데이터·모델·플랫폼의 표준화
- 우수 사례 발굴과 확산
- 교육과 변화관리
- 보안, 법무, 컴플라이언스 기준 정리
문제는 CoE가 중앙 조직이라는 점입니다. 중앙 조직은 표준을 만들 수 있지만, 각 현장의 미묘한 업무 맥락을 모두 알기는 어렵습니다. 제조, 영업, 구매, 물류, 재무, 연구개발은 같은 회사 안에 있어도 데이터 구조와 의사결정 방식이 다릅니다.
그래서 CoE 중심 AX는 종종 좋은 플랫폼은 있지만 부서 데이터와 연결되지 않고, PoC는 통과했지만 실제 프로세스의 예외가 너무 많고, 배포 뒤 사용률이 낮은 장면에서 멈춥니다. 이것은 CoE의 실패가 아니라 CoE만으로 AX의 마지막 1마일을 채우기 어렵다는 뜻입니다.
FDE는 AX의 마지막 1마일을 담당한다
FDE형 역할은 중앙에서 만든 AI 플랫폼과 현장의 실제 업무 사이에 들어가 문제를 다시 정의하고 실행 가능한 형태로 바꿉니다. 단순 개발자와도, 일반적인 컨설턴트와도 다릅니다. 현업의 언어를 이해하는 동시에 데이터, API, 모델, 워크플로우를 다룰 수 있어야 합니다.
Palantir는 AIP를 사설 네트워크에서 LLM과 다른 AI 모델을 실행하고 통제할 수 있는 플랫폼으로 소개합니다. 이처럼 기업 AI를 현장에 안착시키려면 데이터 구조를 파악하고, 워크플로우를 설계하고, 사용자가 실제로 쓸 수 있는 형태로 맞추는 실행 역할이 필요합니다.
현업이 “AI로 보고서 자동화를 하고 싶다”고 말했을 때, FDE형 인력은 바로 화면을 만들기보다 질문을 바꿉니다.
- 보고서 작성에서 가장 시간이 많이 드는 단계는 무엇인가?
- 데이터는 어디에 있고, 누가 접근할 수 있는가?
- AI가 만든 결과를 누가 검증해야 하는가?
- 기존 시스템에는 어떤 형태로 기록돼야 하는가?
- 실패했을 때 사람이 개입하는 지점은 어디인가?
이 질문을 통해 단순 자동화 과제가 업무 재설계 과제로 바뀝니다.
CoE와 FDE, 무엇이 다른가
| 구분 | CoE (중앙 전문조직) | FDE (현장 배치형 실행 역할) |
|---|---|---|
| 주된 질문 | 전사 기준은 무엇인가? | 이 현장에서 무엇이 막혀 있는가? |
| 산출물 | 전략 문서, 표준, 플랫폼, 교육 과정 | 작동하는 프로토타입, 연동된 시스템, 사용자 피드백 |
| 시간 축 | 분기~연 단위 로드맵 | 주 단위 반복: 문제 정의 → 구현 → 피드백 |
| 성공 기준 | 전사 채택률, 보안 준수율 | 현장 사용률, 업무 시간 절감, 예외 처리 속도 |
| 한계 | 현장 맥락 부재, 마지막 1마일 공백 | 전사 표준과의 정합성, 확장성 |
이 표는 우열을 가리기 위한 것이 아닙니다. 두 역할의 시간 축과 산출물이 다르므로, 한쪽만으로 AX를 완성할 수 없다는 점을 보여줍니다.
AX 조직은 CoE와 FDE의 조합이어야 한다
AX를 조직 관점에서 보면 CoE와 FDE는 경쟁 관계가 아닙니다. CoE는 방향과 기준을 잡고, FDE는 현장에서 작동하는 해법을 만듭니다. CoE가 플랫폼, 거버넌스, 보안, 교육을 맡는다면 FDE는 현업 과제 발굴, 프로토타입 제작, 시스템 연동, 사용자 피드백 반영을 맡습니다.
좋은 AX 조직은 대략 다음 구조를 가질 수 있습니다.
- 중앙 CoE: 전략, 표준, 플랫폼, 보안, 교육
- 도메인 FDE: 사업부·현장별 문제 정의와 구현
- 현업 오너: 업무 기준, 성과 지표, 승인 책임
- 데이터·IT 조직: 데이터 파이프라인, 권한, 시스템 연동
- 변화관리 조직: 교육, 확산, 사용률 관리
FDE형 접근이 만능은 아닙니다. 특정 현장에 깊게 관여할수록 해당 부서 최적화에 갇혀 전사 표준·플랫폼과 충돌할 수 있습니다. 이 충돌을 조정하고 현장 결과를 전사 자산으로 환원하는 것이 CoE의 역할입니다.
지금 당장 확인할 5가지
- 현업과 가까운 곳에서 업무 흐름을 직접 관찰하는 AI 구현 인력이 있는가?
- 현업 요청을 그대로 구현하지 않고, 풀어야 할 문제를 다시 정의할 권한이 있는가?
- 도메인 데이터와 시스템에 안전하게 접근할 경로가 있는가?
- 프로토타입 → 피드백 → 수정의 반복 주기가 짧게 돌아가는가?
- 현장 결과물이 전사 표준·플랫폼에 반영되는 공식 경로가 있는가?
AI 에이전트 시대에는 FDE 역할이 더 중요해진다
생성형 AI가 문서 작성 도구에 머물 때는 CoE 중심 접근도 어느 정도 가능했습니다. 공통 도구를 선정하고, 사용 가이드를 배포하고, 교육을 하면 됐습니다.
하지만 AI 에이전트가 업무 안으로 들어오면 이야기가 달라집니다. 에이전트는 답변을 생성하는 데서 그치지 않고 도구를 호출하고, 데이터를 조회하고, 작업을 실행합니다. 이때 중요한 것은 모델 성능만이 아니라 업무 경계와 실행 권한의 설계입니다.
어떤 작업은 자동 실행해도 되는가. 어떤 작업은 사람 승인이 필요한가. 실패하면 어디까지 되돌릴 수 있는가. 로그는 어디에 남겨야 하는가. 민감 데이터는 어떻게 가려야 하는가. 이 질문은 중앙 정책만으로 풀리지 않습니다. 실제 업무 흐름을 아는 사람이 기술 구현과 함께 설계해야 합니다.
가상 예시 — 유통기업 B사는 고객 문의 AI 에이전트에 주문 조회, 배송 안내, 단순 환불을 맡겼습니다. 그러나 대량 주문 고객의 부분 취소 요청에는 별도 계약 조건이 있었고, 자동 취소가 영업팀의 후속 협상을 무력화했습니다. 문제는 모델 성능이 아니라 사람 승인이 필요한 조건을 업무 흐름에 넣지 않았다는 데 있었습니다.
현장에서 재현 가능한 AX 운영 원칙
아래 원칙은 특정 조직의 내부 운영 방식이 아니라, AX를 현장에서 실제로 굴릴 때 공통적으로 필요한 구조를 일반화한 것입니다.
- 주장과 근거를 분리합니다. AI가 만든 결과와 그 결과가 나온 데이터·로그를 구분해 사용자가 근거를 확인할 수 있게 합니다.
- 작성과 검증을 분리합니다. AI 산출물을 운영에 연결하는 주체와 정확성·보안을 확인하는 주체의 역할을 구분합니다.
- 운영 반영 전에는 결과 형식, 연결 상태, 민감 데이터 노출 여부를 점검합니다.
- 오류를 수정하면 무엇을 왜 바꿨는지 이력을 남기고 관련 사용자에게 알립니다.
결론: AX는 중앙의 표준과 현장의 실행력을 함께 봐야 한다
AX를 제대로 추진하려면 CoE는 필요합니다. 기준 없이 각 부서가 제각각 AI를 도입하면 보안, 비용, 품질 문제가 커질 수 있습니다.
하지만 CoE만으로는 부족합니다. AX의 성과는 실제 업무 프로세스 안에서 만들어지고, 그곳에는 데이터 연결, 시스템 연동, 사용자 습관, 예외 처리 같은 복잡한 문제가 있습니다.
그래서 다음 질문은 “우리 회사에 AI CoE가 있는가”에서 끝나면 안 됩니다. 현장의 문제를 AI로 다시 설계하고 실제 시스템까지 연결할 FDE형 인력이 있는가를 함께 물어야 합니다. CoE가 방향을 만들고 FDE가 실행을 붙일 때, AI는 도입된 기술을 넘어 일하는 방식의 변화가 됩니다.
참고: 이 글은 특정 기업의 제품·서비스에 대한 투자 판단이 아닌 AX 조직 설계 관점의 기술 해설입니다. IBM과 Palantir의 언급은 공개 자료 기반의 개념 설명 목적이며, 해당 기업의 성과·전망을 판단하지 않습니다.
확인한 출처 / 근거
- IBM, What is an AI center of excellence? — AI CoE의 역할과 운영 구조 설명.
- Palantir, Artificial Intelligence Platform (AIP) — 사설 네트워크에서 LLM과 AI 모델을 실행·통제하는 플랫폼 설명.
- Palantir Blog, A Day in the Life of a Forward Deployed Engineer (FDE) — FDE 역할을 이해하기 위한 참고 자료.
- 참고: 비교표와 5가지 점검 항목은 공개 자료를 바탕으로 정리한 저자 분석 프레임워크입니다. A사와 B사는 실제 기업이 아닌 가상 예시입니다.