Stealth Innovation: Capital One이 직원 눈에 띄지 않는 AI로 업무 단계를 줄이고 가설로 실험하는 법

사내 AI의 성과는 몇 명이 접속했느냐보다 직원이 일하다 멈추는 횟수가 얼마나 줄었느냐로 봐야 합니다. Capital One은 AI를 업무 흐름 안에 숨겨 단계를 줄이고 그 설계를 가설 기반 실험과 직원의 직접 피드백으로 다듬습니다. 옮기려면 먼저 도메인 전문가와 함께 업무 단계를 지도로 그리고, 줄어든 멈춤을 잴 지표부터 정해야 합니다.

요약

Capital One의 엔터프라이즈 기술 부문 MVP(Managing Vice President)인 Maureen Jules-Perez가 VentureBeat에 쓴 후원 기고(Presented by Capital One)입니다. 저자는 전기공학에서 출발해 QA(품질 보증), 플랫폼·백엔드 엔지니어링, 대규모 기술 도입을 거쳤습니다. 그 과정에서 기술은 얼마나 눈에 띄느냐보다 사람이 무엇을 할 수 있게 되느냐로 평가해야 한다는 기준을 얻었다고 말합니다. 지금은 AI로 아이디어를 몇 분 만에 작동하는 프로토타입으로 만들 수 있습니다. 어려운 일은 그 앞뒤에 남습니다. 무엇을 만들지 고르는 일, 맥락을 넣는 일, 실제 업무에 붙이는 일, 사람이 믿고 써도 되는지 판단하는 일입니다.

저자가 문제로 보는 것은 도구가 늘수록 직원의 짐도 는다는 점입니다. 새 도구가 들어올 때마다 관리할 화면과 프롬프트, 익힐 흐름이 하나씩 붙습니다. 좋은 엔터프라이즈 기술은 이 짐을 덜어 주고 사람은 판단과 전문성, 사람 사이의 관계에 집중하게 됩니다. Capital One은 수만 명의 직원과 1억 명이 넘는 고객을 지원하며 복잡한 금융 인프라를 클라우드에서 키우는 동시에 직원용 지능형 플랫폼을 만들고 있습니다. 목표는 일의 흐름을 따라가며 불필요한 마찰을 없애는 것입니다. 아래에서는 이 주장을 받치는 다섯 가지 메커니즘과 실제로 옮길 때 필요한 기술·현업 디테일을 정리합니다.

핵심 메커니즘

Upstream Shift: 실행은 AI가, 엔지니어의 가치는 문제 정의로

무엇인가. 에이전트와 프레임워크가 반복 구현을 가져가면서 엔지니어가 책임지는 범위가 위쪽으로 옮겨 간다는 관찰입니다.

어떻게 작동하나. 정해진 요구사항을 코드로 옮기거나 흔한 부품을 조립하는 시간이 줄어듭니다. 대신 문제를 어떻게 정의할지, 아키텍처를 어떻게 짤지, 무엇을 실험할지, 무엇을 ‘좋다’고 볼지 정하는 데 시간이 몰립니다. 만드는 주기가 짧아지면 병목은 아키텍처, 통합, 테스트, 리뷰, 운영 준비(production readiness)로 옮겨 갑니다. 여기서 도메인 지식의 무게가 커집니다. 저자는 신용카드 운영 담당자를 예로 듭니다. 그 업무를 누구보다 잘 아는 사람이 없으면 AI는 실행을 도울 뿐 그 업무가 무엇을 이뤄야 하는지는 정하지 못합니다.

원문의 예. Capital One은 엔지니어에게 전략적 판단의 여지를 주고 네 가지를 묻게 합니다. 실제로 풀려는 고객 문제는 무엇인가, 직원 경험에 어떤 영향을 주나, 전체 시스템에는 무엇이 필요한가, 사람들이 AI와 일하도록 어떻게 준비시킬까.

언제 쓰나. 구현 속도는 빨라졌는데 배포 건수나 현업 체감이 따라오지 않을 때, 병목이 어디로 옮겨 갔는지 점검하는 틀로 씁니다.

Stealth Innovation: 직원이 AI를 의식하지 않게 만드는 설계

무엇인가. 직원이 기술을 신경 쓰지 않고 일을 끝내는 상태를 성공으로 보는 설계 원칙입니다. 저자는 자기 팀을 007 영화의 장비 담당 Q에 빗댑니다(원문 표현은 “I think about my team as Q from James Bond”). 현장 요원이 임무에 집중하도록 도구를 만들어 주고 요원은 그 안의 장치를 몰라도 됩니다.

어떻게 작동하나. 거꾸로 된 신호로 판정합니다. 직원이 일하다 멈추거나 다른 도구로 갈아타거나 복잡한 화면을 새로 익혀야 한다면 설계를 더 다듬을 여지가 있습니다. 프롬프트 엔지니어링 전문가가 되어야 하는 경우도 마찬가지입니다. 잘된 모습은 이렇습니다. 필요한 정보가 필요한 자리에 뜨고 다음 단계가 쉬워집니다. 복잡한 절차는 단순해지는데 직원이 일하는 방식은 그대로입니다.

원문의 예. 저자는 12단계였던 업무 흐름을 2단계로 줄인 경우와, 직원용 플랫폼에서 수동 프롬프트 작성을 직관적인 자동화로 바꾼 경우를 듭니다.

언제 쓰고 언제 안 쓰나. 반복 빈도가 높고 직원이 여러 시스템을 오가는 업무에 맞습니다. 직원이 AI의 판단을 따져 봐야 하는 고위험 결정에서는 AI가 무엇을 했는지 오히려 드러내야 합니다. 이 경계는 아래 기술 디테일에서 다룹니다.

Hypothesis-driven Experimentation: 결론을 정당화하지 않는 5단계 실험

무엇인가. 과학적 방법에 기댄 규율 있는 실험입니다. 병목이 통합과 운영 준비로 옮겨 가면 감으로 밀어붙이는 대신 실험으로 다음 단계를 정해야 한다는 것이 저자의 처방입니다.

어떻게 작동하나. 가설을 세운 뒤 작게 시도합니다. 무슨 일이 일어났는지 보여 주고 결과를 공유한 다음, 그 배움으로 다음에 할 일을 정합니다. 결과가 좋든 나쁘든 다음 단계를 고르는 근거로만 쓸 뿐, 이미 내린 결정을 정당화하는 데 쓰지 않습니다. 저자는 이 과정에 beginner’s mind(초심자의 마음)를 함께 둡니다. 경험 많은 기술자도 AI-native 빌더 곁에서 계속 배우며 깊은 도메인 경험과 학습을 합쳐야 한다는 뜻입니다.

작은 예시(가상). “고객 문의 분류 화면에 이전 상담 요약을 미리 띄우면 건당 처리 시간이 20% 줄어든다”는 가설을 세우고 한 팀에서 2주 돌립니다. 10%만 줄었다면 그 결과를 그대로 공유하고 요약 위치를 바꿀지 범위를 줄일지 정합니다.

Close Feedback Loop: 대시보드가 놓치는 문제를 듣는 통로

무엇인가. 직원이 문제를 바로 말할 수 있는 짧은 피드백 고리입니다. 직원은 메시지를 보내거나 복도에서 저자를 붙잡고 곧바로 문제를 알릴 수 있습니다.

어떻게 작동하나. 규모가 크면 작은 설계 결정 하나가 수천 번의 업무 순간에 되풀이됩니다. 직원의 한마디는 대시보드 숫자에 드러나지 않는 장애물을 보여 줍니다. 팀은 그 장애물을 찾아 설계를 고친 뒤 바뀐 경험이 여러 맥락에서 통하는지 확인합니다.

원문의 기준. 저자는 성공을 몇 명이 시스템에 접근할 수 있느냐만으로 재지 않습니다. 업무와 팀, 맥락이 달라져도 복잡함을 더하거나 새로 배울 것을 요구하지 않고 계속 쓸모 있는지를 함께 봅니다.

리더십 세 기둥: 실험을 계속 돌리게 하는 팀 문화

무엇인가. 지금의 AI 전환은 사람들이 새 기술을 배우고 전문성을 다시 정의하는 동안 모호함과 마찰을 만듭니다. 저자는 보이지 않는 AI를 만들려면 세 기둥 위에 선 리더십 문화가 필요하다고 봅니다.

어떻게 작동하나. 첫째는 보완 인재 키우기입니다. 도메인 전문가, AI-native 빌더, 업스킬한 기존 인력을 섞고 이들이 혁신하고 성장할 조건을 만듭니다. 둘째는 ego를 일에서 떼어 내기입니다. 리더가 답을 다 안다고 나서면 전환이 멈춥니다. 초심자의 자세가 있어야 대담한 실험과 가설 검증이 가능합니다. 셋째는 공감형 스튜어드십입니다. 빠른 변화 속에서 효과적인 리더는 가장 목소리 큰 사람이 아닙니다. 약한 모습을 숨기지 않고 귀 기울이며 다른 의견을 끌어올립니다. 장애물을 치워 팀이 정확하고 안전하게 일하게 합니다.

연결. 설계 규율과 공감형 리더십이 함께 갈 때 기술은 할 일 하나를 더 얹는 존재에서 매일 곁에 있는 조용한 동료가 됩니다.

통념과 다른 주장

저자가 든 사례

12단계 업무를 2단계로

상황	한 일	결과	연결
한 업무 흐름이 12단계로 이뤄져 있었음	AI를 흐름 안에 넣어 단계를 줄임	2단계만 남음	Stealth Innovation

저자는 이 경우를 잘된 AI 경험이 어떤 모습인지 보여 주는 예로 듭니다. 어떤 업무인지, 얼마나 걸렸는지, 무엇을 지표로 쟀는지는 원문에서 밝히지 않았습니다.

직원용 플랫폼의 프롬프트 자동화

상황	한 일	결과	연결
직원이 플랫폼에서 프롬프트를 직접 작성	직관적인 자동화로 대체	직원이 프롬프트 전문가가 될 필요가 없어짐	Stealth Innovation, 두 번째 통념

플랫폼 이름, 대상 직무, 성과 수치는 원문에서 밝히지 않았습니다.

복도에서 듣는 피드백

직원이 메시지나 복도에서 바로 문제를 알리면, 팀은 그 말을 실마리로 장애물을 찾아 설계를 고칩니다. Close Feedback Loop의 사례입니다. 처리 건수나 주기는 원문에서 밝히지 않았습니다.

기술 디테일: 보이지 않는 AI를 실제로 돌리려면

원문은 원칙과 예를 제시합니다. 아래는 같은 원칙을 우리 조직에서 돌릴 때 필요한 것을 새로 정리한 설계 예시입니다.

12단계를 2단계로 줄이려면(Stealth Innovation) 먼저 단계 지도를 데이터로 만듭니다. 도메인 전문가가 실제로 일하는 모습을 보며 단계마다 한 줄씩 기록합니다. 단계의 성격을 조회, 재입력·복사, 형식 변환, 확인, 판단, 승인으로 나누면 AI와 자동화가 흡수할 단계와 사람에게 남길 단계가 갈립니다. 판단과 승인은 남기고 나머지는 시스템이 미리 처리하게 하는 것이 기본 방향입니다.

{
  "workflow_id": "card-dispute-intake",
  "step_no": 5,
  "step_name": "거래 내역 조회",
  "actor": "상담원",
  "system": "core-banking-ui",
  "step_type": "lookup",
  "input": ["customer_id", "transaction_id"],
  "output": ["transaction_record"],
  "screen_switch": true,
  "median_seconds": 45,
  "absorb": "prefill",
  "keep_human": false
}

step_type은 lookup, reentry, transform, check, judgment, approval 여섯 값으로 고정합니다. keep_human이 true인 단계(judgment, approval)는 AI가 초안을 내더라도 사람이 결정합니다.

직원이 프롬프트를 쓰지 않게 하려면(직원용 플랫폼 사례) 화면 맥락으로 프롬프트를 조립합니다. 직원이 보고 있는 업무 유형과 건 ID를 받아 시스템 프롬프트 템플릿을 고르고 필요한 데이터를 조회해 채웁니다. 출력은 JSON 스키마로 고정하고 근거 필드(sources)를 반드시 넣게 합니다. 요약·분류처럼 결과가 매번 같아야 하는 작업은 temperature를 0~0.2로 둡니다. 스키마 검사나 업무 규칙 검사에 실패하면 결과를 숨기지 말고 기존 수동 화면으로 넘깁니다. 직원 화면에는 버튼 하나와 결과, 고치기·승인 동작만 남깁니다.

보이지 않게 하되 틀린 결과까지 숨기지는 않습니다. AI가 흐름 안에 숨으면 직원이 오류를 알아채기 어렵습니다. 그래서 장치를 셋 둡니다. 결과 옆에 근거를 한 줄로 보여 줍니다. 모델의 확신이 낮거나 근거를 못 찾으면 자동 채움 대신 “확인 필요” 표시를 띄웁니다. 직원이 고친 값은 로그로 남겨 다음 실험의 입력으로 씁니다. 고위험 결정(한도, 거절, 규제 보고)은 처음부터 keep_human: true로 둡니다.

5단계 실험을 돌리려면(Hypothesis-driven Experimentation) 가설 카드를 먼저 고정합니다. 시작 전에 지표와 기준선, 판정선을 적어 두어야 결과를 사후 해석으로 바꾸지 않습니다.

{
  "hypothesis": "거래 조회 자동 채움으로 접수 건당 처리 시간이 20% 줄어든다",
  "metric": "median_handle_seconds",
  "baseline": 410,
  "threshold": "-20%",
  "cohort": "분쟁 접수팀 A (12명)",
  "period_days": 14,
  "result": null,
  "decision": null,
  "shared_at": null
}

result와 decision은 실험이 끝난 뒤에 채우고, 결과가 판정선에 못 미쳐도 shared_at은 반드시 채웁니다.

섀도 운영에서 편차부터 잽니다. 과거 처리 건 50건을 골라 같은 입력으로 3회씩 돌려 결과가 회차마다 달라지는 비율을 셉니다. 10%를 넘으면 실사용 전에 프롬프트와 스키마를 고칩니다. 모델은 작업 단위로 고릅니다. 조회 결과 정리나 분류·추출처럼 짧고 정해진 작업은 작고 빠른 모델에 맡기고 여러 문서를 읽고 요약하는 작업에만 큰 모델을 씁니다. 판단 단계에 올릴 초안은 다른 모델로 한 번 더 뽑아 두 결과가 다르면 “확인 필요”로 돌립니다.

줄어든 멈춤을 재려면(Close Feedback Loop) 사용량 대신 마찰 지표를 로그로 남깁니다. 건당 단계 수, 화면 전환 횟수, AI 결과를 버리고 수동 경로로 간 비율, 흐름 단절 신고 건수를 같은 화면 이벤트에서 뽑습니다. 피드백 버튼은 누른 순간의 단계 번호, 건 ID, 모델·프롬프트 버전을 자동으로 붙여 보냅니다. 복도에서 들은 말도 같은 양식으로 받아 적어 한 목록에서 분류합니다(버그, 오답, 흐름 단절, 기능 요청).

현업 실행 디테일: 누가, 언제, 무엇을

저자가 말한 보완 인재 구성을 파일럿 팀 하나로 옮기면 다음과 같습니다(예시).

역할	담당	하는 일
스폰서	업무 부서장 1명	대상 업무 선정, 판정 회의 주재, 실패 결과 공유 보장
도메인 전문가	그 업무 경력이 가장 긴 실무자 1~2명	단계 지도 검수, ‘좋음’의 기준 정의, 판단 단계 확정
AI-native 빌더	엔지니어 1~2명	프롬프트 조립, 구조화 출력, 자동 채움 구현
업스킬 엔지니어	기존 시스템 담당 1명	레거시 연동, 테스트, 운영 준비
리스크·준법	1명	keep_human 단계 확정, 근거 표시 기준 승인

시작 전에 모을 것. 대상 업무 하나의 절차서, 최근 1개월 처리 건수와 처리 시간, 그 업무에 쓰이는 화면 목록, 지난 분기 현업 불만·요청 기록입니다.

6주 일정(예시).

기간	할 일	산출물
1주	실무자 옆에서 업무 관찰, 단계 지도 작성	단계 지도(JSON), 기준선 지표
2주	흡수할 단계 고르기, 가설 카드 작성	가설 카드, 판정선
3주	섀도 운영: AI 결과를 보여 주지 않고 사람 처리와 비교	일치율, 편차, 오류 유형
4주	실사용: 한 팀에서 자동 채움 켜기, 피드백 버튼 운영	마찰 지표, 피드백 목록
5주	결과 시연과 공유(좋든 나쁘든)	1쪽 결과 보고
6주	확대, 수정, 중단 가운데 결정	결정 기록, 다음 가설

도메인 전문가에게 물을 것.

1. 이 업무에서 손이 멈추는 순간은 어디이고, 그때 어떤 화면을 새로 여나요?
2. 같은 정보를 두 번 이상 입력하는 단계가 있나요?
3. 이 업무가 ‘잘 끝났다’는 것은 무엇으로 아나요?
4. AI가 대신해도 되는 판단과 절대 안 되는 판단은 무엇인가요?

진행 판정 기준(예시). 4주차 실사용에서 건당 단계 수가 기준선의 절반 이하, 화면 전환이 건당 1회 이하이고 수동 경로 비율이 주마다 줄면 확대합니다. 판단·승인 단계에서 근거 없이 자동 처리된 건이 1건이라도 나오면 확대하지 않고 설계를 고칩니다. 판정선은 2주차 가설 카드에 미리 적어 둡니다.

AX 적용 제언. 고객사가 사내 AI 성과를 라이선스 수나 활성 사용자로 보고하고 있다면, 그 지표 옆에 건당 단계 수와 화면 전환 횟수를 함께 올리게 하는 것부터 시작합니다. 대상은 직원이 여러 시스템을 오가며 같은 정보를 다시 입력하는 고빈도 업무 하나가 좋습니다(카드 분쟁 접수, 여신 서류 확인, 구매 요청 검토 등). 리더에게는 결과가 나쁜 실험도 공유하는 자리를 정례화하게 하고 파일럿 팀에는 도메인 전문가를 빌더와 같은 비중으로 넣습니다. 사용 교육을 늘리기보다 교육이 필요 없는 화면을 목표로 잡으면 확산 속도가 달라집니다.

원문 사례

항목	내용
글	VentureBeat, 2026.10.23, Capital One 후원 콘텐츠(Presented by Capital One)
저자	Maureen Jules-Perez, Capital One 엔터프라이즈 기술 MVP
핵심 주장	가장 좋은 엔터프라이즈 AI는 직원이 거의 의식하지 못하는 AI
엔지니어 역할 변화	구현에서 문제 정의·아키텍처·실험·‘좋음’의 정의로, 병목은 통합·테스트·리뷰·운영 준비로
엔지니어에게 던지는 질문	고객 문제, 직원 경험, 전체 시스템의 필요, 사람의 AI 준비
실험	가설 → 시도 → 시연 → 공유 → 다음 단계 결정
예	12단계 → 2단계 업무, 수동 프롬프트를 자동화로 바꾼 직원용 플랫폼, 복도 피드백
규모	직원 수만 명, 고객 1억 명 이상, 클라우드 기반 금융 인프라
리더십	보완 인재, ego 분리, 공감형 스튜어드십

핵심 개념

MVP (Managing Vice President)

Capital One의 임원 직급. 이 글에서는 엔터프라이즈 기술 부문을 맡은 저자의 직함입니다.

AI-native 빌더

처음부터 AI 도구로 만들고 일하는 방식이 몸에 밴 개발자. 도메인 전문가와 짝을 이룰 때 힘을 냅니다.

Production readiness

만든 것을 실제 운영에 올려도 되는 상태. 보안, 테스트, 모니터링, 장애 대응까지 갖춘 수준을 말합니다.

Beginner's mind

경험이 많아도 처음 배우는 사람처럼 가정을 내려놓고 실험하는 태도입니다.

Q

007 영화에서 요원의 장비를 만드는 담당. 저자가 자기 팀의 역할을 설명할 때 쓴 비유입니다.

프롬프트 엔지니어링

원하는 결과가 나오도록 모델에 주는 지시문을 다듬는 일. 저자는 직원이 이 일을 떠안지 않게 하라고 봅니다.

내 메모

TODO: 내 생각 추가

원문: Maureen Jules-Perez, 「The best enterprise AI is the AI employees barely notice」(VentureBeat, 2026.10.23). Capital One이 후원한 콘텐츠(Presented by Capital One)이며, 사례와 규모는 저자와 Capital One의 설명입니다. 요약·핵심 메커니즘·통념과 다른 주장·저자가 든 사례·원문 사례 표는 원문 내용을 AX Review가 다시 정리했습니다. 기술·현업 디테일, JSON 예시, 일정·판정 기준, 인포그래픽은 새로 작성했으며 그 안의 업무 이름, 필드명, 숫자는 가상 예시입니다. 원문 전체는 VentureBeat에서 볼 수 있습니다.