AX, Top-Down인가 Bottom-Up인가
AI 전환에서 전략·가드레일은 위에서 정하고, 실제 업무 적용과 개선 학습은 현장에서 넓히는 이중 운영체제를 정리합니다.
기업에서 AX, 즉 AI Transformation을 이야기할 때 자주 부딪히는 질문이 있습니다. “위에서 강하게 밀어야 할까, 아니면 현업이 먼저 실험하게 해야 할까?”
둘 다 필요합니다. 전사 데이터, 보안, 권한, 공통 플랫폼 같은 문제는 현업 팀 하나가 해결할 수 없습니다. 반대로 어떤 보고서가 반복되고 어떤 승인 문구가 매번 다시 쓰이며 어떤 업무 조합이 시간을 잡아먹는지는 현업이 가장 정확히 압니다.
한 줄 요약: 문제 선택과 운영 경계는 Top-Down으로 좁히고, 업무 적용과 개선 학습은 Bottom-Up으로 넓혀야 합니다. 좋은 사례는 다시 공통 표준으로 돌아와야 합니다.
그래서 질문은 “둘 중 무엇이 옳은가”가 아니라 “무엇을 위에서 정하고, 무엇을 아래에서 발견하게 할 것인가”로 바뀌어야 합니다. AX의 실패는 Top-Down이라서가 아니라 너무 추상적인 지시로 끝날 때 생깁니다. Bottom-Up도 마찬가지입니다. 통제 없는 도구 실험으로 흩어지면 조직의 역량으로 축적되지 않습니다.
Top-Down만으로는 왜 부족한가
Top-Down의 장점은 분명합니다. 예산과 우선순위를 정하고, 공통 플랫폼과 교육을 마련하며, 데이터 반출·개인정보·저작권·권한의 경계를 정할 수 있습니다. 생성형 AI처럼 업무 전반에 퍼지는 기술은 중앙의 기준 없이 안전하게 확산되기 어렵습니다.
하지만 “AI를 도입하라”는 문장만으로 업무가 바뀌지는 않습니다. 챗봇, 사내 LLM 포털, RAG 시스템을 열어도 현업 사용자는 내일 아침 무엇을 바꿔야 하는지 알 수 없습니다. 플랫폼 도입을 전환의 완료로 오해하거나, 초기부터 큰 ROI만 요구하면 실제 사용 패턴과 업무 예외를 배우기도 전에 과제가 멈춥니다.
Top-Down의 역할은 구호가 아닙니다. 어떤 업무 문제를 먼저 풀지, 어떤 위험은 허용하지 않을지, 공통 인프라와 권한 체계를 어디까지 제공할지를 정하는 일입니다. 현업에 “쓰라”고 말하는 대신, 이 범위 안에서는 안전하게 써도 된다는 신호와 실행 조건을 제공해야 합니다.
제가 직접 겪은 일입니다. 저희 회사도 전사 생성형 AI 플랫폼을 열었지만 한동안 현업 사용이 낮았습니다. 영업에는 고객 맥락이 연결되지 않았고, 운영 조직에는 사람이 다시 확인해야 할 예외가 많았습니다. 플랫폼은 있어도 업무와 만나는 마지막 단계가 비어 있던 셈입니다.
Bottom-Up만으로는 왜 위험한가
Bottom-Up은 AX의 학습 엔진입니다. 같은 모델이라도 기획자는 초안 작성에서, 개발자는 코드 검토에서, 구매 담당자는 계약서 비교에서, 설비 담당자는 이상 징후 설명에서 서로 다른 가치를 발견합니다. 이런 발견은 중앙 조직이 책상 위에서 모두 설계하기 어렵습니다.
문제는 현장 실험을 방치할 때입니다. 팀마다 다른 외부 도구를 쓰고 민감한 데이터를 복사해 넣으며, 비슷한 자동화를 중복 개발하면 “AI 활용”은 “도구 난립”으로 바뀝니다. 성공 사례도 개인 노하우로만 남습니다.
AI가 만든 결과를 누가 확인하는지, 오류가 생겼을 때 어떤 경로로 수정하는지, 어떤 데이터는 프롬프트에 넣어도 되는지 같은 기준도 필요합니다. NIST AI RMF는 인간 감독 프로세스와 이의 제기·재검토 메커니즘을 위험 관리의 중요한 구성 요소로 다룹니다. 현장 적용에서는 결과 확인과 예외 처리의 책임을 처음부터 업무 흐름 안에 넣어야 합니다.
Bottom-Up의 역할은 “마음대로 써 보라”가 아닙니다. 실제 업무 문제를 발견하고, 작은 자동화 단위를 만들고, 반복 사용 속에서 프롬프트·데이터·확인 절차를 개선하는 일입니다.
저희 회사도 1년 전이 딱 이 상황이었습니다. 여러 부서가 각자 문서 요약·문의 분류 자동화를 만들었지만 서로 다른 데이터 연결과 결과 형식을 썼습니다. 현장에서는 빠르게 성과가 났지만, 다른 팀이 재사용하기 어려웠습니다. 그래서 다음 단계는 새 도구를 더 사는 일이 아니라 공통 템플릿과 연결 규칙을 만드는 일이었습니다.
AX는 전략 과제보다 업무 재설계에 가깝다
AX를 어렵게 만드는 이유는 AI 모델 자체보다 업무 구조에 있습니다. 많은 업무는 문서, 메일, 메신저, 회의, 승인, 시스템 입력이 느슨하게 연결된 형태입니다. 사람은 그 사이의 빈틈을 기억과 맥락으로 메웁니다. 생성형 AI와 에이전트를 붙이려면 이 암묵지를 기계가 읽고 사람이 확인할 수 있는 단위로 바꿔야 합니다.
“회의록을 요약해 달라”는 과제도 실제로는 다음 질문으로 이어집니다.
- 어떤 회의가 공식 기록 대상인가?
- 민감한 발언은 어떻게 처리할 것인가?
- 결정 사항과 아이디어를 어떻게 구분할 것인가?
- 후속 과제는 어느 시스템에 등록할 것인가?
- AI 요약은 사람이 승인해야 하는가, 자동 배포해도 되는가?
이 문제는 모델 성능만으로 해결되지 않습니다. 업무 규칙, 권한, 책임, 시스템 연동의 문제입니다. Top-Down은 회의·문서·승인·데이터 사용의 공통 원칙을 정하고, Bottom-Up은 실제 업무에서 어디까지 자동화가 가능한지 배웁니다.
네 가지 층위로 나눠 보면 답이 보인다
AX를 한 덩어리로 보면 위와 아래 중 하나를 고르려는 논쟁이 반복됩니다. 네 가지 층위로 나누면 분업이 보입니다.
| 층위 | Top-Down이 정할 것 | Bottom-Up이 발견할 것 | 분업이 깨질 때 나타나는 증상 |
|---|---|---|---|
| 방향 | 우선 해결할 사업·기능 문제 | 실제로 시간이 새는 업무 | 전략은 있지만 현장 과제가 없음 |
| 경계 | 보안, 개인정보, 저작권, 승인 책임 | 현장에서 자주 만나는 예외 | 사용자는 불안해하고 도구만 늘어남 |
| 플랫폼 | 공통 LLM, RAG, 권한, 로그, 비용 관리 | 자주 쓰이는 템플릿과 워크플로 | 플랫폼은 있지만 업무 연결이 약함 |
| 확산 | 성과 기준, 재사용 방식, 교육 체계 | 좋은 프롬프트, 실패 사례, 개선 요구 | 개인의 요령이 조직에 남지 않음 |
이 표에서 중요한 점은 한쪽이 다른 쪽을 대체하지 않는다는 것입니다. Top-Down이 현업 문제를 모두 안다고 생각하면 공허해지고, Bottom-Up이 보안과 표준을 스스로 해결하려 하면 위험해집니다. 증상 열을 거꾸로 읽으면 지금 조직에서 먼저 보완할 인터페이스도 찾을 수 있습니다.
좋은 AX 과제는 큰 비전과 작은 반복을 함께 가진다
AX 초기에 좋은 과제는 거창한 완전자동화가 아닙니다. 다음 세 조건을 함께 갖춘 과제입니다.
- 현업이 반복해서 쓰는가
- 중앙 조직이 데이터·권한·결과 확인의 위험을 관리할 수 있는가
- 성과가 확인되면 다른 팀에 복제할 수 있는가
이 기준을 통과하지 못하는 과제는 가치가 없어서가 아니라, 아직 실행 가능한 단위로 충분히 쪼개지지 않았을 수 있습니다. 회의록에서 결정 사항과 액션 아이템을 분리해 업무 시스템에 등록하기, 긴 기술 문서를 역할별 요약본으로 바꾸기, 반복 보고서 초안에 근거 링크를 붙이기 같은 과제는 좋은 출발점이 될 수 있습니다.
작은 과제를 반복하면 조직은 AI가 잘하는 일과 사람이 계속 잡아야 하는 일을 구분하는 감각을 얻습니다. 데이터 접근 권한, 출처 추적, 사람의 결과 확인, 업무 시스템 연동, 비용 관리, 재사용 템플릿도 이 과정에서 구체화됩니다.
KPI도 Top-Down과 Bottom-Up을 나눠야 한다
Top-Down KPI와 Bottom-Up KPI를 섞으면 현업은 보여주기식 과제를 만들고, 중앙 조직은 실제로 사용되지 않는 플랫폼 지표만 보기 쉽습니다.
Top-Down KPI는 운영 기반의 성숙도를 봐야 합니다.
- 공통 AI 플랫폼의 활성 사용자와 재방문율
- 민감 데이터 차단·권한·로그 체계의 적용 범위
- 재사용 가능한 업무 템플릿 수
- 모델·API·인프라 비용의 가시성
- 정착된 사례가 다른 조직으로 확산된 횟수
Bottom-Up KPI는 업무 변화의 밀도를 봐야 합니다.
- 특정 업무의 처리 시간 변화
- 초안·요약·분류 결과의 재작업률
- 사람이 확인해야 하는 오류 유형의 변화
- 현업 사용자가 낸 개선 제안 수
- 반복 사용되는 프롬프트와 절차의 표준화 정도
호출량 자체는 가치 지표가 아닙니다. 호출량은 비용을 이해하는 단서일 뿐입니다. 중요한 것은 업무가 더 빨라졌는지, 더 안전해졌는지, 더 일관되게 재사용되는지입니다.
Citizen Developer는 해방이 아니라 가드레일이 필요하다
현업이 직접 작은 봇과 워크플로를 만들 수 있어야 AX의 속도가 납니다. 하지만 이것은 아무나 아무거나 만들 수 있다는 뜻이 아닙니다. 좋은 가드레일이 있을 때 현업 실험도 안전하게 늘어납니다.
- 승인된 데이터 커넥터
- 금지된 외부 전송 규칙
- 공통 프롬프트 템플릿
- 로그와 비용 한도
- 결과 확인 체크리스트
중앙 조직의 성숙도는 현업을 얼마나 강하게 통제하느냐보다, 현업이 안전하게 실험할 수 있는 좁고 단단한 길을 얼마나 잘 깔아 주느냐에서 드러납니다.
결론: 선언은 위에서, 발견은 아래에서, 표준은 다시 위로
AX는 Top-Down과 Bottom-Up 중 하나를 고르는 일이 아닙니다. 위에서 사업 우선순위와 위험 경계를 정하고, 아래에서 실제 업무 문제와 사용 패턴을 발견하며, 쓸모가 확인된 사례를 다시 공통 템플릿·플랫폼 기능·교육으로 바꾸는 순환 구조입니다.
시작 전에 다섯 가지를 물어볼 수 있습니다.
- 사업 우선순위와 현업의 반복 업무가 같은 문제를 가리키는가?
- 데이터·권한·결과 확인의 경계가 과제 시작 전에 정해졌는가?
- 현장 사례가 개인의 요령이 아니라 재사용 가능한 형태로 남는가?
- 공통 플랫폼이 실제 업무 맥락과 연결되는가?
- 개선 요청이 다시 표준을 바꾸는 경로가 있는가?
이 경로가 없다면 Top-Down은 구호가 되고 Bottom-Up은 산발적 실험으로 끝납니다. 반대로 이 경로가 있다면 작은 자동화 하나도 전사 역량으로 축적됩니다. AX의 성패를 가르는 것은 위와 아래 중 어느 쪽이 더 강한가가 아니라, 둘 사이의 인터페이스를 얼마나 잘 설계했는가입니다.
확인한 출처 / 근거
- NIST, AI Risk Management Framework
- IBM Institute for Business Value, The CEO’s guide to generative AI
- Deloitte Insights, State of AI in the Enterprise (PDF)
- McKinsey, The economic potential of generative AI: The next productivity frontier
- Microsoft Work Trend Index 2025, The year the Frontier Firm is born
- Microsoft Work Trend Index 2026, Agents, human agency, and the opportunity for every organization
이 글은 공개 자료를 바탕으로 AX의 운영 조건을 설명한 기술 해설입니다. 특정 기업의 도입 성과를 보장하거나 단일한 정답을 제시하지 않습니다.