작성자 황경찬
AX 실행 역량은 결국 누가 보유해야 하는가
임원 교육에서 AX를 설득하는 일은 이제 어렵지 않습니다. 문제는 그다음입니다. AX 담당자에 관해 현업, 외주사, 절충안을 차례로 검토하면 질문은 글의 제목처럼 하나로 좁혀집니다.
임원 교육에서 반복해서 보는 장면
2026년 1월부터 임원과 리더를 대상으로 AI 전환(AX) 교육을 여러 곳에서 진행해 왔습니다. 최근 6개월, AI 필요성을 설득하는 일은 점점 쉬워졌습니다.
임원들이 직접 AI를 써보면 반응은 대체로 비슷합니다. 이 정도까지 되는구나 하는 효능감을 느끼고, 그럼 우리 업무에도 적용해보자로 넘어갑니다. 교육이 끝날 때쯤이면 경영진 차원의 방향은 대개 정해져 있습니다.
그런데 몇 달 뒤 같은 회사 소식을 들어보면 진행된 것이 거의 없습니다. 의지는 있는데 실행이 되지 않은 상태입니다.
처음에는 현업의 관성이나 AI 역량 부족으로 여겼습니다. 그런데 여러 회사가 비슷한 상황을 반복해서 겪는걸 발견 했습니다. 그제서야 진짜 문제가 무엇일까 파헤쳐 보았고, AX라는 일의 성격 자체가 진짜 원인임을 찾아냈습니다.
AX는 업무 시스템을 다시 만드는 일입니다
실제 업무는 프롬프트 하나로 끝나지 않습니다. 예로 구매 업무를 보면 요청, 자료 조회, 비교, 판단, 승인, ERP 입력, 사후 관리라는 단계가 이어집니다.
이 업무에 AI를 넣으려면 단계마다 구체화 할 것이 생깁니다. 무엇을 AI에게 맡기고 무엇을 자동화할지, 어떤 데이터를 어디서 가져올지, 기존 시스템과 어떻게 연결할지, 사람이 승인하는 지점을 어디에 둘지, 실패했을 때 누가 책임질지를 전부 다시 설계해야 합니다.
%%{init: {"flowchart": {"subGraphTitleMargin": {"top": 12, "bottom": 12}}}}%%
flowchart TB
subgraph FLOW["기존 구매 업무"]
direction LR
F1["요청"] --> F2["자료 조회"] --> F3["비교"] --> F4["판단"] --> F5["승인"] --> F6["ERP 입력"] --> F7["사후 관리"]
end
subgraph DECIDE["단계마다 새로 설계해야 하는 것"]
direction TB
D1["무엇을 AI 에게 맡길 것인가"]
D2["어떤 데이터를 어디서 가져올 것인가"]
D3["기존 시스템과 어떻게 연결할 것인가"]
D4["사람이 승인하는 지점을 어디에 둘 것인가"]
D5["실패했을 때 누가 책임질 것인가"]
end
FLOW --> DECIDE
DECIDE --> CAP["AX 실행 역량<br/>업무 이해 · AI 이해 · 소프트웨어 구현<br/>· 사내 시스템 이해 · 조직 변화"]
style F1 fill:#f3f4f6,stroke:#6b7280,color:#1f2937
style F2 fill:#f3f4f6,stroke:#6b7280,color:#1f2937
style F3 fill:#f3f4f6,stroke:#6b7280,color:#1f2937
style F4 fill:#f3f4f6,stroke:#6b7280,color:#1f2937
style F5 fill:#f3f4f6,stroke:#6b7280,color:#1f2937
style F6 fill:#f3f4f6,stroke:#6b7280,color:#1f2937
style F7 fill:#f3f4f6,stroke:#6b7280,color:#1f2937
style D1 fill:#fef3c7,stroke:#f59e0b,color:#1f2937
style D2 fill:#fef3c7,stroke:#f59e0b,color:#1f2937
style D3 fill:#fef3c7,stroke:#f59e0b,color:#1f2937
style D4 fill:#fef3c7,stroke:#f59e0b,color:#1f2937
style D5 fill:#fef3c7,stroke:#f59e0b,color:#1f2937
style CAP fill:#dbeafe,stroke:#3b82f6,color:#111827
그래서 AX를 제대로 하려면 다음 다섯 가지가 같이 움직여야 합니다. 업무 이해, AI 이해, 소프트웨어 구현, 사내 시스템 이해, 조직 변화입니다. 이 다섯 가지를 묶어 이 글에서는 **AX 실행 역량**이라고 부르겠습니다.
그렇다면 회사 안에서 이 일을 누구에게 맡길 수 있을까요. 실제로 최근 기업이 검토하는 선택지는 크게 셋입니다. 현업, 외주사, 그리고 둘을 섞은 절충안입니다.
첫 번째 선택지, 현업에게 맡깁니다
가장 자연스러운 접근입니다. 각 부서에서 AI 과제를 발굴해 직접 해보라고 요청합니다. 업무를 가장 잘 아는 사람이 업무를 바꾸는 것이니 논리적으로도 맞습니다.
그런데 잘 진행되지 않습니다. 현업은 업무를 잘 알지만 AI 아키텍처를 설계하고, 사내 시스템에 연결하고, 프로토타입을 만들고, 운영 가능한 수준까지 구현하는 역량을 갖춘 경우가 드뭅니다.
더 중요한 것은 성과 지표입니다. 현업에는 이미 매출, 프로젝트, 운영 같은 기존 KPI가 있습니다. AX를 하려면 기존 일을 그대로 하면서 자기 업무를 바꾸는 프로젝트를 하나 더 해야 합니다.
그래서 현업이 움직이지 않는 것을 단순히 관성에 의한 저항이나 의지 부족으로만 읽으면 진짜 원인을 놓칩니다. 크게는 조직 구조의 제한과 기술 역량의 한계 두가지로 정리할 수 있습니다. 이 문제는 담당 부서를 세 번 바꿔도 AX가 시작되지 않는 이유에서 자세히 다뤘습니다.
두 번째 선택지, AX 외주사에 맡깁니다
현업에서 진행이 안되면 외부 전문가를 부릅니다. 최근 이 역할을 맡는 인력을 Forward Deployed Engineer(FDE)라고 부릅니다. 고객 현장에 직접 들어가 문제를 발굴하고 해결책을 직접 구현하는 엔지니어를 뜻하며, 국내에서도 2026년 들어 이 직무를 도입하는 기업이 늘고 있습니다.
외주 FDE에는 분명한 장점이 있습니다. 숙련된 인력을 빠르게 투입할 수 있고, 다른 기업에서 검증된 성공 패턴을 가져오며, 초기 개념 증명(PoC)을 짧은 기간에 만들어냅니다.
다만, AX는 일반적인 시스템 구축(SI) 프로젝트와 성격이 다릅니다.
일반적인 SI는 요구사항이 어느 정도 정의된 상태에서 시작합니다. 이 시스템을 만들어달라는 요청이 있고, 그래서 프로젝트의 시작과 끝을 비교적 명확하게 정의할 수 있습니다.
AX는 무엇을 만들어야 하는지부터 모르는 경우가 많습니다. 현장에 들어가서 왜 이 일을 이렇게 하고 있는지부터 물어야 합니다. 그리고 첫 번째 자동화를 만들면 업무 방식이 바뀌고, 바뀐 업무를 보면서 두 번째 문제가 발견됩니다.
발견, 구현, 사용, 새로운 문제 발견, 재설계가 계속 반복됩니다. AX는 프로젝트라기보다 지속적인 업무 개선 활동에 가깝습니다.
%%{init: {"flowchart": {"subGraphTitleMargin": {"top": 12, "bottom": 12}}}}%%
flowchart LR
subgraph SI["일반 SI: 끝이 정의된다"]
direction TB
S1["요구사항이 정의된<br/>상태로 시작"] --> S2["회사가 시스템을 구축"] --> S3["프로젝트 종료"]
end
subgraph AXW["AX: 끝이 정의되지 않는다"]
direction TB
A1["현장에서 문제를 발견"] --> A2["FDE 가 구현"] --> A3["현업이 사용"] --> A4["바뀐 업무에서<br/>새로운 문제를 발견"] --> A5["FDE 가 재설계"] --> A1
end
SI ~~~ AXW
style S1 fill:#f3f4f6,stroke:#6b7280,color:#1f2937
style S2 fill:#f3f4f6,stroke:#6b7280,color:#1f2937
style S3 fill:#f3f4f6,stroke:#6b7280,color:#1f2937
style A1 fill:#dbeafe,stroke:#3b82f6,color:#1f2937
style A2 fill:#dbeafe,stroke:#3b82f6,color:#1f2937
style A3 fill:#dbeafe,stroke:#3b82f6,color:#1f2937
style A4 fill:#dbeafe,stroke:#3b82f6,color:#1f2937
style A5 fill:#dbeafe,stroke:#3b82f6,color:#1f2937
외주 AX가 구조적으로 불리한 네 가지 이유
AX가 반복되는 활동이라는 관점에서 보면, 외주사 AX의 네 가지 한계가 드러납니다.
가장 중요한 정보는 문서가 아니라 현장에 있습니다
AX에 필요한 것은 정리된 요구사항이 아닙니다. 시스템이 있는데도 왜 엑셀을 따로 만들고 있는지, 왜 시스템 데이터를 다시 복사하는지, 결재선에 없는 실제 승인자는 누구인지, 공식 프로세스와 실제 프로세스가 왜 다른지, 어떤 예외 케이스가 존재하는지 같은 암묵지입니다.
외주사도 프로젝트 기간 동안 이것을 배울 수 있습니다. 다만 내부 인력이 수년 동안 축적한 조직 맥락과는 차이가 납니다.
깊이 들어갈수록 보안과 권한이 걸립니다
AX를 성공적으로 진행할수록 다루는 대상은 사내 데이터, ERP, 고객 정보, 재무 정보, 생산 정보, 내부 API, 권한 체계 같은 핵심 시스템으로 옮겨갑니다.
단순 챗봇 PoC와 달리 실제 업무를 바꾸는 단계로 갈수록 내부 시스템 접근 권한과 조직 신뢰가 전제 조건이 됩니다. 외부 인력에게 이 조건을 열어주는 데는 한계가 있습니다.
외주의 계약 단위는 프로젝트가 되기 쉽습니다
위 2가지 벽을 모두 넘어도, 결국 외부 사업자는 계약 범위를 정해야 합니다. 그런데 좋은 FDE는 요청받은 것을 만드는 대신 다른 문제를 먼저 풀어야 한다고 말할 수 있어야 합니다.
때로는 3개월짜리 프로젝트 하나보다 이틀짜리 자동화 20개를 계속 만드는 편이 회사에 훨씬 이롭습니다. 지금까지 해오던 방식의 외주 계약 구조와 다릅니다. 고객의 편에 서야 하고, 그것이 실제 금전적 이득으로 연결되는 구조여야 합니다.
AX 실행 역량이 회사가 아니라 외부에 축적됩니다
외주사 A가 재무팀을, B가 HR을, C가 영업을 자동화한다고 해보겠습니다. 각 프로젝트는 성공할 수 있습니다.
그런데 회사 안에는 우리 회사의 업무를 AI로 바꾸는 능력, 즉 AX 실행 역량이 쌓이지 않습니다. 다음 과제마다 새로운 외부 업체가 들어와 회사를 처음부터 다시 공부합니다.
| 한계 | 현장에서 나타나는 모습 | 결과 |
|---|---|---|
| 암묵지가 문서에 없다 | 시스템이 있는데도 엑셀을 따로 만든다, 결재선에 없는 실제 승인자가 있다 | 요구사항은 받아도 진짜 문제를 찾지 못한다 |
| 보안과 권한이 걸린다 | ERP, 고객 정보, 재무 정보, 내부 API, 권한 체계 | 가치가 큰 과제일수록 외부 인력이 접근하지 못한다 |
| 경제 단위가 프로젝트다 | 3개월 프로젝트 1건과 이틀짜리 자동화 20건 | 계약 범위 밖의 더 나은 제안을 하기 어렵다 |
| AX 실행 역량이 외부에 축적된다 | 재무는 A사, HR은 B사, 영업은 C사가 맡는다 | 과제마다 새 업체가 회사를 처음부터 다시 공부한다 |
절충안, 외부 FDE가 만들고 내부 관리자를 양성합니다
앞의 두 선택지보다 나은 접근이고, 실제로 많은 기업이 여기에 도달합니다. 외부의 숙련된 FDE가 들어와 발굴, 설계, 구축, 전환까지 진행한 뒤 내부 담당자에게 넘깁니다.
그런데 관리자를 양성하는 것으로는 부족합니다. FDE의 핵심 역량은 외부 인력을 관리하는 역량이 아니라 문제를 발견하고 해결책을 직접 만드는 역량이기 때문입니다.
외부 FDE가 떠난 뒤 새로운 업무가 생깁니다. 이때 내부 담당자가 새 업무를 분석하고, AI 적용 가능성을 판단하고, 데이터 구조를 확인하고, 프로토타입을 직접 만들고, 실패 원인을 디버깅하고, 아키텍처를 수정하고, 현업과 다시 업무를 설계할 수 없다면 어떻게 될까요.
결국 다시 외부 업체를 부릅니다. 완성된 솔루션은 회사 안에 남았지만 AX 실행 역량은 남지 않은 것입니다.
%%{init: {"flowchart": {"subGraphTitleMargin": {"top": 12, "bottom": 12}}}}%%
flowchart TB
subgraph ONLY["솔루션만 이전한 경우"]
direction LR
O1["외부 FDE 가 구축"] --> O2["내부 관리자에게 인계"] --> O3["새로운 문제가 발생"] --> O4["다시 외부 업체를 부른다"]
O4 --> O1
end
subgraph BOTH["AX 실행 역량까지 이전한 경우"]
direction LR
B1["외부 FDE 가 구축하고<br/>내부 인력이 발굴부터 동행"] --> B2["새로운 문제가 발생"] --> B3["내부 FDE 가 직접<br/>발견 · 설계 · 구현"]
end
ONLY ~~~ BOTH
style O1 fill:#fee2e2,stroke:#ef4444,color:#1f2937
style O2 fill:#fee2e2,stroke:#ef4444,color:#1f2937
style O3 fill:#fee2e2,stroke:#ef4444,color:#1f2937
style O4 fill:#fecaca,stroke:#ef4444,color:#111827
style B1 fill:#dcfce7,stroke:#22c55e,color:#1f2937
style B2 fill:#dcfce7,stroke:#22c55e,color:#1f2937
style B3 fill:#bbf7d0,stroke:#22c55e,color:#111827
그래서 외부 FDE와 내부 담당자를 함께 두는 모델은 한계가 있습니다. 이를 극복하기 위해서는 내부 담당자가 결국 내부 FDE가 되어야 합니다. 제대로 AX를 하려면 외부 FDE에서 시작해, 외부 FDE와 내부 견습이 함께 일하는 단계를 거쳐, 내부 FDE로 끝나야 합니다.
논쟁은 외주냐 내부냐가 아닙니다. AX 실행 역량을 최종적으로 누가 보유할 것인가입니다.
외부 FDE는 AX를 시작하게 해줄 수 있습니다. 다만 AX를 지속하는 조직을 만들어주지는 못합니다.
대기업일수록 내부에 보유할 경제적 이유가 커집니다
AX 과제가 한두 개라면 외주가 합리적입니다. 필요한 시점에 전문 인력을 사는 편이 조직을 만드는 것보다 저렴합니다.
직원 5,000명, 10,000명 규모의 기업이라면 계산이 달라집니다. 재무에도, HR에도, 영업에도, 생산에도, 구매에도, 개발에도, 법무에도 과제가 있습니다. 그리고 AI 모델과 도구가 계속 발전하기 때문에 한 번 재설계한 업무도 다시 설계해야 합니다.
AX 수요는 프로젝트 하나가 끝나면 사라지는게 아니라, 과제 1, 2, 3에서 50, 100까지 계속 발생합니다. 이 지점부터 AX는 구매해야 할 서비스가 아니라 회사가 보유해야 할 역량이 됩니다.
AX 를 담당하는 FDE 를 내부에 두면 경험이 쌓입니다. 내부 FDE 한 명이 재무팀 과제를 하면서 사내 인증 방법, 데이터 접근 방법, 보안 가이드, AI 에이전트 패턴, ERP 연결 방법, 배포 환경, ROI 측정 방법을 만듭니다.
다음에 구매팀을 맡으면 그것을 그대로 재사용합니다. 혹은 한걸음 더 나아가 팀별 FDE를 둘 수도 있습니다. 외부에서는 과제가 비용으로 끝나지만, 내부에서는 과제가 AI 자산과 AX 실행 역량으로 남아 다음 과제 해결을 가속합니다.
%%{init: {"flowchart": {"subGraphTitleMargin": {"top": 12, "bottom": 12}}}}%%
flowchart TB
subgraph OUT["외주 반복: 과제마다 비용이 같다"]
direction LR
U1["과제 1<br/>외부 업체가 회사를 공부하고 구축"] --> U1E["종료"]
U2["과제 2<br/>새 업체가 회사를 다시 공부하고 구축"] --> U2E["종료"]
U3["과제 3<br/>새 업체가 회사를 다시 공부하고 구축"] --> U3E["종료"]
end
subgraph INN["내부 축적: 다음 과제가 빨라진다"]
direction LR
I1["과제 1 재무팀<br/>내부 FDE 가 구축하며<br/>재사용 자산을 만든다"] -->|"자산 이월"| I2["과제 2 구매팀<br/>자산을 재사용하고<br/>부족한 것만 구축"] -->|"자산 이월"| I3["과제 3 영업팀<br/>더 빠르게 완료"]
end
OUT ~~~ INN
INN --> ASSET["재사용 자산<br/>사내 인증 · 데이터 접근 · 보안 가이드 · AI 에이전트 패턴<br/>· ERP 연결 · 배포 환경 · ROI 측정 방법"]
style U1 fill:#f3f4f6,stroke:#6b7280,color:#1f2937
style U2 fill:#f3f4f6,stroke:#6b7280,color:#1f2937
style U3 fill:#f3f4f6,stroke:#6b7280,color:#1f2937
style U1E fill:#e5e7eb,stroke:#6b7280,color:#1f2937
style U2E fill:#e5e7eb,stroke:#6b7280,color:#1f2937
style U3E fill:#e5e7eb,stroke:#6b7280,color:#1f2937
style I1 fill:#dbeafe,stroke:#3b82f6,color:#1f2937
style I2 fill:#dbeafe,stroke:#3b82f6,color:#1f2937
style I3 fill:#dbeafe,stroke:#3b82f6,color:#1f2937
style ASSET fill:#e0e7ff,stroke:#6366f1,color:#111827
이미 움직이고 있는 기업들
카카오는 2026년 4월 사내 AX를 지원하는 FDE 조직을 신설했습니다. 기존 AI 네이티브 조직의 시니어 엔지니어 일부를 이 팀으로 옮겨, 개발과 비개발 조직을 돌며 업무를 분석하고 AI 에이전트와 자동화를 지원하게 했습니다. 크래프톤은 같은 해 3월 AI FDE를 10명 이상 규모로 채용하면서 경력과 학력을 보지 않았습니다 (디지털투데이).
크래프톤의 FDE 채용 공고는 역할 정의가 특히 구체적입니다. AI Transformation 부서 소속으로 현업의 과제를 분석해 AI 적용 전략을 수립하고, 비개발 직군의 요구사항을 AI 기반 아키텍처로 구현하며, 며칠에서 몇 주 안에 에이전트와 자동화 앱을 프로토타이핑하고, 도입 효과를 정량적으로 분석합니다. AI 개발팀도 PM 조직도 아닙니다.
GS리테일은 2026년 7월 AX 사례 공유 세션에서 개인 단위의 AI 활용을 조직 역량으로 전환하겠다고 밝히면서, 검증용 샌드박스와 데이터 축적 환경과 함께 FDE 훈련 프로그램을 제시했습니다. 각 조직의 AX 과제를 식별하고 실행까지 이끌 인력을 내부에서 기르겠다는 것입니다 (서울경제).
| 기업 | 시점 | 형태 | 하는 일 |
|---|---|---|---|
| 카카오 | 2026년 4월 | 사내 FDE 조직 신설 | 시니어 엔지니어를 이동시켜 개발·비개발 조직을 순회 |
| 크래프톤 | 2026년 3월 | FDE 10명 이상 채용 (경력·학력 무관) | 전략 수립, 아키텍처 설계, 프로토타이핑, ROI 분석 |
| GS리테일 | 2026년 7월 | FDE 훈련 프로그램 (내부 육성) | 각 조직의 AX 과제를 식별하고 실행할 인력을 내부에서 양성 |
Microsoft의 AI 전문 조직 구축 가이드도 같은 방향입니다. 이 문서는 AI 전문 조직을 외부 인력을 관리하는 기능이 아니라 내부 전문가 팀으로 정의하고, 경영진 후원과 전담 리더, 비즈니스와 기술이 결합된 내부 팀을 요구합니다.
다만 이 가이드는 주의점을 함께 제시합니다. 기존 클라우드 전문 조직이 있다면 거기에 통합하고, 현재 조직으로 감당할 수 없거나 중대한 리스크가 있을 때만 독립 조직을 만들라고 권고합니다. 조직을 새로 만드는 것 자체가 목적은 아니라는 뜻입니다.
따라서 대기업이 모든 상황에서 외주보다 내부 FDE를 해야한다고 말하면 과장일 수 있습니다. 다만, AX가 파일럿을 넘어 반복적이고 핵심적인 업무 혁신 활동이 될수록, 외부 FDE만 쓰는 대신 AX 실행 역량을 내부에 함께 구축할 필요가 있습니다.
대기업이 지금 해야 할 네 가지
지금까지의 내용을 네가지 단계별 실행안으로 정리하겠습니다.
첫째, 첫 과제부터 외부 FDE와 내부 전담 인력을 한 팀으로 붙입니다. AX 실행 역량은 프로젝트가 끝난 뒤 문서를 넘겨받는 방식으로는 이전되지 않습니다. 내부 전담 인력이 문제 발굴 단계부터 함께 해야 합니다.
둘째, 계약 산출물에 완성된 결과물뿐 아니라 재사용 자산을 함께 명시합니다. 시스템만 받으면 다음 과제는 다시 처음부터 시작합니다. 사내 인증 방법, 데이터 접근 절차, 배포 환경, ROI 측정 방법을 문서와 코드로 함께 받아야 합니다.
셋째, 내부 FDE 후보를 외부를 관리할 사람이 아니라 직접 해결책을 만들 수 있는 사람으로 선발합니다. 성과를 확인하기 위해서는 결과물을 만드는 역량이 중요합니다. 판단 기준은 이력이 아니라 직접 만들어본 결과물입니다.
넷째, AX 성과를 그 인력의 성과 지표에 반영합니다. 조직을 새로 만들어도 평가 기준이 그대로면 결과는 같습니다. 새로운 포지션도 마찬가지입니다. 특히 AX 관련 진행 시간을 확보해 주어야 합니다.
| 단계 | 실행 주체 | 회사가 확보하는 것 | 확인 질문 |
|---|---|---|---|
| 1. 시작 | 외부 FDE + 내부 인력 동행 | 첫 성공 사례 | 내부 인력이 발굴 단계부터 같은 자리에 있었는가 |
| 2. 이전 | 외부 FDE + 내부 견습 | 재사용 자산 (문서와 코드) | 사내 인증, 데이터 접근, 배포 환경, ROI 측정 방법을 함께 받았는가 |
| 3. 내부화 | 내부 FDE (외부는 자문) | AX 실행 역량 | 새로운 문제를 외부 없이 풀 수 있는가 |
마치며
임원 교육에서 확인하는 것은 이제 AI 로 효율화가 되는지 여부가 아닙니다. AX 가 된 다음, 회사 안에서 누가 그 일을 이어받느냐입니다.
외부의 도움을 받는 것은 좋은 선택입니다. 다만 우리 회사의 업무를 AI로 바꾸는 능력 자체는 회사 안에 남아야 합니다. 첫 과제를 외주로 시작하더라도, 그 과제에 내부 전담 인력을 처음부터 붙이는 것이 가장 먼저 할 수 있는 시작점입니다.