역할을 세 층으로 다시 나눈다 — 도입 사례와 AX 실행 프레임워크

"AI를 도입하면 사람이 줄어드는가"는 도입 논의에서 가장 먼저 나오고 가장 늦게까지 남는 질문이다. 그런데 이 질문에 예·아니오로 답하는 순간 논의가 멈춘다. 자리가 없어지느냐가 아니라 자리에 담긴 일이 무엇으로 바뀌느냐가 실제로 결정해야 하는 것이기 때문이다.

이 글은 그 재구성을 두 방향에서 본다. 하나는 아래에서 위로 — 금융권이 실제로 무엇을 도입했고 어떤 숫자를 보고했는지. 다른 하나는 위에서 아래로 — 역할을 오케스트레이터·메이커·빌더 세 층으로 나눈 모델과, 그것을 적합 업무 선정부터 확산까지 네 단계로 옮긴 실행 프레임워크. 앞 편이 왜 지금인지를 거시 지표로 답했다면, 이 글은 그래서 조직이 무엇을 하는지에 답한다.

기술 구조 자체는 시리즈 첫 편에 있고, 이 글 다음의 두 편은 다시 실무로 내려간다.

이 글은 2026년 2월 자료를 정리한 것이다. 등장하는 도입 사례와 수치는 각 기업이 자사 사례로 발표한 값이며 제3자 검증을 거친 것이 아니다.

용어 정리

앞 편의 용어표에서 이 글이 쓰는 행만 추리고, 조직·역할 용어를 더했다.

금융권이 실제로 도입한 것

자료는 금융권을 고객경험·사내 혁신·리스크 세 축으로 나눈다.

세 축의 성격이 다르다. 첫째는 비용, 둘째는 시간, 셋째는 매출이다. 도입 논의가 대개 첫째에서 시작해 셋째까지 가지 못하는데, 아래 사례 중 정량 효과가 가장 큰 것은 셋째 축에 있다.

고객경험 — 세 사례

DNB의 챗 우선 전략은 접점 구조 자체를 바꾼 사례다.

흐름은 세 단계다 — 모든 문의를 채팅으로 접수하고, AI가 1차 처리하고, 미해결 건만 사람에게 이관한다.

Bank of America의 Erica는 묻기 전에 먼저 말을 거는 형태다. 거래 패턴·잔고·카드 사용 데이터를 분석해 "이번 달 구독료가 20% 늘었습니다", "3일 뒤 잔고 부족이 예상됩니다" 같은 행동 유도형 알림을 보낸다. 단순 FAQ 봇이 아니라 금융 코치로 인식되면서 **1,900만 명 이상의 활성 사용자(MAU)**를 확보했다.

Fifth Third Bank의 감정 인식은 사후 평가를 실시간 코칭으로 바꾼 사례다. 통화 중 음성 톤·피치·속도를 분석해 분노·좌절을 실시간 감지하고 상담사에게 알린다. 도입 후 18개월 만에 고객 감정 점수가 35% 향상됐고 상담 품질과 만족도가 동반 상승했다는 것이 발표 내용이다.

세 사례의 공통 구조는 "AI가 사람을 대체한 자리"가 아니라 "AI가 사람 앞에 붙은 자리"다.

DNB는 1차 응대를 앞에 붙였고, Erica는 문의 자체를 앞당겨 만들었고, 감정 인식은 통화 도중에 붙었다. 셋 다 사람의 작업을 없앤 것이 아니라 사람이 다루는 입력의 성격을 바꿨다. 상담사에게 도착하는 것이 "모든 문의"에서 "복잡한 문의"로 바뀌면 필요한 역량도 바뀌고, 이것이 뒤에 나오는 역할 재정의의 현장 버전이다.

사내 혁신 — 세 사례

Nubank의 AskNu는 문제 정의가 특히 명확하다.

각 팀이 위키에 독립적으로 문서를 관리했다. 직원들이 정보를 찾는 데 많은 시간을 썼고, 일부는 정보를 못 찾아 헬프데스크 티켓을 열어야 했다.

리더가 가져갈 문장은 "문서를 통합하지 않았다"는 것이다. 팀별로 흩어진 위키를 정리하는 대신 그 위에 검색 에이전트를 얹었고, 티켓이 96% 줄었다.

이 판단이 값을 하는 이유는 소요 기간의 차이에 있다. 정보구조 개편은 수년짜리 과제이고 도중에 조직이 바뀌면 다시 시작된다. 검색 레이어는 수 주짜리이고 문서 구조가 바뀌어도 살아남는다. 다만 정확도 74%라는 숫자를 함께 봐야 한다 — 네 번 중 한 번은 틀린다는 뜻이므로, 오답을 감수할 수 있는 질의 유형부터 열어야 한다.

글로벌 투자은행의 온보딩 어시스턴트는 사람의 시간이 어디로 재배치됐는지를 보여준다.

대형 보험사의 문서 검색 시스템은 이 절에서 절대 금액이 제시된 유일한 사례다.

두 표는 같은 사례의 서로 다른 절단면이다. 위는 경영 보고용 요약 셋, 아래는 그 요약을 만든 운영 지표 넷이다. 위 표만 보면 "$4.2M 절감"이 근거 없이 떠 있고, 아래 표만 보면 그것이 얼마짜리인지 알 수 없다. 그리고 아래 표의 첫 행 — 업무시간의 65%가 문서 검색이었다 — 이 나머지 셋을 전부 설명한다.

리스크 — 데이터로 신용을 다시 재는 사례

Tala는 전통 신용점수 대신 스마트폰 행동 데이터로 대출을 심사한다.

상환율 92%가 이 사례의 요점이다. 금융 소외 계층을 대상으로 하면서도 상환율이 유지됐다는 것이 대안 신용평가의 성립 근거이고, 그것을 뒷받침하는 것은 모델이 아니라 마지막 행 — 10년치 데이터다.

공통 성공 요인 넷

이 네 줄은 그대로 사내 AI 과제 승인 게이트로 쓸 수 있다. 넷 중 셋(1·2·3)이 품질과 신뢰에 관한 것이고, 네 번째만 채택률에 관한 것인데 — 실패 사례에서 가장 자주 지목되는 것은 네 번째다.

역할을 세 층으로 나눈다

이 절이 조직 관점에서 가장 인용 가치가 높다.

표는 세 행인데 도식은 다섯 노드다. 표의 Builder 한 행이 도식에서는 인프라·데이터·운영 셋으로 갈라지기 때문이고, 그것이 우연이 아니다. 위 두 층은 사람 한 명이 맡을 수 있는 역할이지만 아래 층은 기능 조직 여럿이라, 역할과 조직 단위가 층마다 다르게 대응한다. 3역할을 그대로 3팀으로 만들려는 시도가 실패하는 이유가 여기 있다.

이 계층에는 세로축이 하나 더 붙는다. 위로 갈수록 유연하고, 아래로 갈수록 결정론적이다.

상단은 유연해야 하고 하단은 결정론적이어야 한다. 이 두 성질을 한 레이어에 섞으면 시스템이 무너진다.

조직도 같다. 판단 레이어와 실행 레이어는 요구 속성 자체가 다르므로 품질 기준을 따로 세워야 한다. 실행 레이어에는 재현성 지표를 걸고, 판단 레이어에는 걸지 않는다. 반대로 하면 두 가지가 동시에 무너진다 — 판단이 경직되고, 실행이 임의로 변한다. 실무에서 흔한 실패는 후자다. 인프라와 운영에 "유연하게 대응하라"는 요구가 들어오는 순간 재현성이 사라지고, 그러면 장애 원인을 특정할 수 없게 된다.

자리와 일의 관계는 이렇게 정리된다.

자리(Position)는 유지된다. 하지만 일(Work)은 완전히 재구성된다. 단순 실행(Task)에서 오케스트레이션(Purpose)으로.

센토어 모델이 그 재구성의 원리다 — 인간 × AI 에이전트가 곱셈으로 작동한다는 것.

세 원리가 순환한다. 2번의 재조립 품질이 3번의 피드백 품질을 결정하고, 그것이 다시 1번의 분업선을 옮긴다. **"인간의 판단력 + AI의 처리 속도 = 기하급수적 생산성"**이라는 표현이 성립하려면 세 번째 원리가 실제로 도는지가 관건이다.

AI가 인간을 대체하지는 않을 것이다. 그러나 AI를 다룰 줄 아는 인간이 그렇지 못한 인간을 대체할 것이다. — Karim Lakhani, 하버드 비즈니스 스쿨

이 문장이 조직 커뮤니케이션에서 값을 하는 이유는 위협의 방향을 바꾸기 때문이다. 대체의 주체가 AI가 아니라 동료가 되면 논의가 "막을 것인가"에서 "누가 먼저 배울 것인가"로 옮겨간다. 다만 이 문장이 덮는 범위는 좁다 — 개인의 학습을 다루지 조직의 재배치를 다루지 않는다. 조직 차원의 답은 아래 실행 프레임워크 쪽에 있다.

플랫폼과 확산 — 한 조직의 6개월

한 AI 솔루션 조직이 2025년 8월에 구축한 사내 에이전트 플랫폼의 구성이다.

표는 여섯 행이고 도식도 여섯 노드지만 배치가 다르다. 표는 구성요소 목록이고 도식은 데이터가 흐르는 순서인데, 도식에서 드러나는 것은 사람(Forward Deployed Engineer)이 파이프라인의 중간 — 지식관리 계층 — 에 꽂힌다는 점이다. 도구 목록만 보면 자동화된 파이프라인처럼 보이지만, 실제로는 사람이 현업 지식을 지식 계층에 밀어 넣는 것이 전제다.

이 플랫폼의 6개월 성과로 제시된 값은 하나다 — 임직원 주도 에이전트 확산 1,200개 이상. 상향식 확산이 실제로 일어난다는 증거로 인용되는 숫자다.

확산의 1단계는 개별 에이전트 활용이다.

2단계는 오케스트레이션이며, 자료는 이것을 달성이 아니라 비전으로 표시한다.

1단계와 2단계 사이의 간격이 이 절의 진짜 정보다. 1단계는 실측값이 있고 2단계는 없다.

개별 에이전트 1,200개가 만들어졌는데도 오케스트레이션은 아직 비전인 이유는 기술이 아니라 작업 경계 정의에 있다. 법률·재무·디자인 에이전트를 각각 만드는 것과 셋의 산출물을 하나의 제안 패키지로 합치는 것은 난이도가 다르다. 후자는 어느 산출물이 어느 산출물에 의존하는지, 충돌하면 누가 판정하는지를 정해야 하고, 그것은 도구 문제가 아니라 업무 규약 문제다. 멀티 에이전트를 먼저 도입하지 말라는 권고가 나오는 자리가 여기다.

실행 — 다섯 묶음과 네 단계

핵심 액션 아이템은 다섯 묶음, 열다섯 항목이다.

다섯 묶음 중 앞의 둘은 엔지니어링, 셋째는 사람, 넷째와 다섯째는 프로세스다. 열다섯 항목 중 순수 기술 항목이 여섯뿐이라는 비율이 이 표의 메시지다.

AX 실행 프레임워크는 그 열다섯을 순서로 옮긴다.

도식은 네 마디인데 표는 열두 행이다. 도식이 순서를, 표가 각 단계의 판정 기준을 담는다. 세 번째 단계에서 나오는 2주 + 4주 = 과제당 6주 사이클이 이 프레임워크의 실질적 운영 단위이고, 첫 단계의 세 조건 — 월 10시간 이상 반복 / 문서화된 지식 존재 / 사람 검토 가능 — 이 착수 여부를 가르는 게이트다.

조직에 옮기면 무엇이 되는가

열두 행의 세 번째 열을 세로로 읽으면 30일 다섯, 60일 다섯, 90일 둘이다. 30일 항목이 전부 "측정하거나 문서화한다"이고 구축은 하나도 없다. 기준선 없이 착수한 파일럿은 성과를 증명할 수 없다는 것이 이 배치의 이유다.

여기까지가 조직 쪽이다. 역할은 세 층으로 나뉘고, 실행은 6주 사이클로 돌고, 첫 30일은 측정으로 채운다.

그런데 하나가 남는다. Maker가 "서브에이전트를 정의·설계한다"고 할 때 실제로 무엇을 만드는가. 메모리인가 스킬인가 커맨드인가, 그리고 그 선택은 무엇을 근거로 하는가. 다음 편에서 하네스를 구성하는 다섯 가지 — 메모리·스킬·에이전트·커맨드·훅 — 을 하나씩 열고, 세션 시작 비용을 만드는 고정 지식 일곱 종을 토큰 단위로 분해한다.