AI 도입은 교육이 아니라 운영체계다

AI 도입은 교육 프로그램으로 끝나지 않는다. 사람들이 실제 업무에서 쓰게 만드는 운영 레일, 점수판, 권한, 반복 의식이 필요하다.

Lenny’s Newsletter의 How I AI에 올라온 John Kim 인터뷰를 읽었다. 제목은 Quests, token leaderboards, and a skills marketplace: The elite AI adoption playbook. Sendbird/Delight.ai가 회사 안에서 AI를 어떻게 퍼뜨렸는지 다룬 글이다.

처음 보면 흔한 AI adoption 사례처럼 보인다. 마케팅팀이 엔지니어 없이 Stripe 연동 swag store를 만들었다. 세일즈팀이 자기 CRM 도구를 만들었다. 채용팀이 워크플로우를 자동화했다. 토큰 사용량 대시보드도 있고, 리더보드도 있고, 사내 스킬 마켓도 있다.

그런데 이 사례의 진짜 핵심은 “AI를 많이 쓰게 했다”가 아니다.

핵심은 AI 도입을 교육 프로그램이 아니라 사내 제품으로 만들었다는 점이다.

많은 회사가 AI 도입을 이렇게 접근한다.

• ChatGPT 계정을 지급한다.
• 프롬프트 교육을 한다.
• 부서별 use case를 모은다.
• 사내 가이드 문서를 만든다.
• 리더가 “AI를 적극적으로 활용합시다”라고 말한다.

이 방식은 나쁘지 않다. 하지만 대부분 금방 식는다. 왜냐하면 직원 입장에서 AI는 여전히 “각자 알아서 써야 하는 도구”이기 때문이다. 오늘 내가 뭘 해야 하는지, 어디까지 안전한지, 결과물을 어디에 남겨야 하는지, 누가 승인해야 하는지, 다음 반복 때 무엇이 더 쉬워지는지가 연결되지 않는다.

Sendbird 사례가 다른 지점은 여기에 있다.

그들은 AI 사용을 개인의 열정이나 프롬프트 능력에 맡기지 않았다. 대신 Automators라는 내부 플랫폼으로 바꿨다. 누구나 필요한 AI 도구를 요청할 수 있고, 엔지니어나 AI agent가 그것을 만들 수 있고, 회사 전체가 어떤 업무 스킬이 생겼는지 볼 수 있다. 사용량도 본다. 퀘스트도 있다. 리더보드도 있다.

다시 말해 AI를 “소프트웨어 구매”가 아니라 “조직의 운영 레이어”로 다룬 것이다.

퀘스트가 중요한 이유

AI 도입에서 “써보세요”는 약한 문장이다. 사람은 도구를 쓰고 싶은 게 아니라 일을 끝내고 싶다.

그래서 퀘스트가 중요하다. 퀘스트는 사용법 설명이 아니라 행동 단위다.

예를 들어 “Claude Code를 써보세요”는 약하다. 반면 “이번 주 안에 반복되는 보고서 1개를 AI로 초안화하고, 사람이 최종 검토한 뒤 템플릿으로 저장하세요”는 강하다.

“시장 조사를 해보세요”도 약하다. “이번 주 경쟁사 3곳을 같은 기준으로 비교하고, 다음 액션 1개를 정하세요”는 강하다.

“월마감 자료를 확인하세요”도 약하다. “이번 달 월마감 전에 증빙 누락 예외를 0건으로 줄이세요”는 강하다.

퀘스트는 게임화라서 중요한 게 아니다. 퀘스트는 일을 쪼개서 조직이 반복할 수 있는 행동 단위로 바꾸기 때문에 중요하다.

스킬 마켓은 사내 SaaS의 다음 형태다

인터뷰에서 흥미로웠던 표현은 회사 안의 skills marketplace다. 이건 단순히 agent 모음집이 아니다.

사내 업무를 스킬로 등록한다는 것은, 어떤 업무에 대해 최소한 다음 질문에 답한다는 뜻이다.

• 이 업무는 무엇을 입력으로 받는가?
• 어떤 산출물을 만드는가?
• 어느 시스템에 기록되는가?
• 읽기 전용인가, 쓰기 작업인가?
• Owner 승인이 필요한가?
• 반복될수록 무엇이 더 자동화되는가?

이 질문에 답하지 못하면 AI 도구는 그냥 장난감이 된다. 반대로 이 질문에 답하면 작은 내부 SaaS가 된다.

여기서 중요한 변화가 있다. 과거에는 사내 SaaS를 만들려면 엔지니어의 roadmap에 올라가야 했다. 그래서 “재미있지만 우선순위는 낮은” 업무 도구들은 늘 밀렸다. 이제는 그 사이에 새로운 층이 생긴다. non-engineer가 AI로 초안을 만들고, 엔지니어는 안전한 템플릿과 배포 경로를 만든다. 완성된 업무 능력은 사내 스킬로 등록된다.

SaaS가 죽는 게 아니라, 회사 안에서 더 작은 단위로 재조립되는 것이다.

토큰 리더보드는 평가 도구가 아니다

토큰 사용량을 보는 것도 오해하기 쉽다. “누가 AI를 많이 썼나”로 줄 세우면 바로 망한다. 그러면 사람들은 보여주기식 사용량을 늘리거나, 반대로 감시받는다고 느낀다.

Sendbird 사례에서 더 중요한 관점은 사용량의 절대값보다 곡선이다. 조직 전체가 부드럽게 올라오고 있는지, 특정 소수에게만 몰려 있는지, 어느 팀이 아직 손도 못 대고 있는지를 보는 것이다.

좋은 adoption dashboard는 성과 평가표가 아니라 병목 지도다.

이 팀은 왜 못 쓰고 있는가?
권한이 없어서인가?
데이터가 흩어져서인가?
실패했을 때 되돌릴 방법이 없어서인가?
승인자가 불명확해서인가?
업무를 쪼갠 퀘스트가 없어서인가?

이 질문을 보게 해준다면 토큰 대시보드는 쓸모 있다. 그렇지 않으면 그냥 숫자놀이가 된다.

작게 시작하려면 무엇이 필요한가

이 글을 읽고 얻은 실무적 결론은 단순하다. 새 AI 챗봇을 하나 더 붙이는 것보다, 기존 반복 업무를 스킬과 퀘스트로 재분류하는 일이 먼저다.

대부분의 조직에는 이미 여러 도구가 있다. 문서 도구, 채팅, 스프레드시트, CRM, 회계 시스템, 프로젝트 관리 도구, 내부 admin이 있다. 문제는 도구가 없는 것이 아니라, 도구들이 업무 생애주기로 묶여 있지 않다는 점이다.

그래서 필요한 다음 층은 Automators류의 상위 운영 레이어다.

각 도구를 “앱”이 아니라 “업무 스킬”로 등록해야 한다. 예를 들면 이렇다.

• 캠페인 문안 리스크 점검
• 경쟁사 가격·포지셔닝 조사
• 주간 고객 문의 패턴 요약
• 외부 공유 채널 감사
• 월마감 증빙 누락 확인
• 정본 문서 변경 요청

그리고 각 스킬에는 실행 등급이 있어야 한다.

• read_only: 보기만 한다.
• draft: 초안을 만든다.
• requires_owner_approval: Owner 승인 후 실행한다.
• external_write: 외부 시스템에 쓰기 때문에 강한 gate가 필요하다.

이 구조가 있으면 AI 도입은 갑자기 현실적인 문제가 된다. “AI를 쓰자”가 아니라 “이 업무는 어디까지 자동화할 수 있고, 어디서 사람이 승인해야 하는가”가 보이기 때문이다.

좋은 AI-native 조직의 정의

내 결론은 이렇다.

AI-native 조직은 AI를 많이 쓰는 조직이 아니다. AI-native 조직은 반복 업무가 발견될 때마다 그것을 스킬, 퀘스트, 템플릿, 승인 경로, 정본 기록으로 바꾸는 조직이다.

여기서 프롬프트는 작은 일부다. 더 중요한 것은 업무의 생애주기다.

요청이 들어온다.
증거를 모은다.
초안을 만든다.
승인을 받는다.
정본에 반영한다.
다음 반복 때 더 쉽게 실행된다.

이 흐름을 만들지 못하면 AI는 개인 생산성 도구에 머문다. 이 흐름을 만들면 AI는 조직의 operating system이 된다.

Sendbird의 Automators 사례가 좋은 이유는 바로 이것이다. 그들은 AI를 신기한 도구로 팔지 않았다. 사내 반복 업무가 소프트웨어로 졸업하는 길을 만들었다.

한국 회사들에 필요한 것도 거창한 AI transformation 구호가 아니다. 부서별 GPT 교육도 첫걸음일 뿐이다. 진짜 변화는 훨씬 작고 구체적인 곳에서 시작된다.

이번 주에 반복 업무 하나를 고른다.
그 업무를 퀘스트로 만든다.
입력과 산출물을 정한다.
위험 등급을 붙인다.
결과가 남을 정본 위치를 정한다.
다음 주에 다시 실행한다.

이것이 쌓이면 회사 안에 작은 스킬 마켓이 생긴다. 그리고 어느 순간 사람들은 “AI를 쓴다”고 말하지 않게 된다. 그냥 일이 그렇게 돌아간다.

그때부터가 진짜 AI 도입이다.