AI를 열심히 쓰는 척, 이미 시작됐습니다.
요즘 기업에서 AI 도입을 담당하거나, 위에서 "AI를 활용해 업무에 도움이 되는 툴, 에이전트를 만들어봐라."라는 말을 들어본 분들이라면 공감하실 겁니다.
"도대체 어디에 쓰라는 거지?"
이 질문을 머릿속에서 지우지 못한 채 일주일이 지나고, 한 달이 지나고. 결국 뭔가 쓰고 있는 것처럼 보이기 위해 AI 챗봇에 "안녕"이라고 말을 거는 일이 반복되죠
ChatGPT가 처음 나온 직후의 우리의 모습같죠, 하지만 수년이 지나 AI가 우리 일상에 파고든 지금 아마존(Amazon)과 메타(Meta) 같은 글로벌 빅테크에서 실제로 벌어지고 있는 일입니다.
아마존에서 무슨 일이 있었나?
2026년 5월, 파이낸셜타임스(Financial Times)와 패스트컴퍼니(Fast Company) 보도로 꽤 충격적인 내용이 알려졌습니다.
아마존은 내부 AI 도구인 MeshClaw를 통해 직원들의 AI 토큰 소비량을 추적하기 시작했습니다. 그리고 일부 직원들은 정말로 생산성과 전혀 상관없는, 불필요한 AI 에이전트를 만드는 방식으로 사용량을 인위적으로 부풀리기 시작했습니다.
익명의 어떤 아마존 직원은 이렇게 말했습니다.
"이 도구들을 써야 한다는 압박이 너무 강하다. 어떤 사람들은 그냥 토큰 사용량을 최대로 끌어올리려고 MeshClaw를 돌리고 있다."
또 다른 직원은 이렇게도 말했습니다.
"사용량을 추적하면 역인센티브가 생긴다. 일부 사람들은 이 지표 경쟁에 매우 진심이다."
회사 측은 "AI 사용 통계가 성과 평가에 반영되지 않는다"고 공식 발표했지만, 직원들은 그 말을 믿지 않았습니다. 보도에 따르면 매주 개발자의 80%가 AI를 사용하도록 하는 목표와, 토큰 소비량이 내부 리더보드에서 집계된다는 이야기가 직원들 사이에 퍼져 있었거든요.
결과? 예상 하듯 퀄리티는 그대로, 사용량만 늘었습니다.
메타는 더 심각했습니다
아마존 이야기가 심각했다면, 메타(Meta) 이야기는 한 단계 더 나아갑니다.
메타는 78,000명의 전 직원을 대상으로 'AI Transformation(AX) Weeks' 를 실시했습니다. AI 코딩 도구와 에이전트 사용법을 교육하고, 프로덕트 디자이너에게는 AI로 코딩을, 소프트웨어 개발자에게는 AI로 디자인을 해보라고 지시했죠.
그리고 동시에, 직원들의 토큰 소비량을 추적하는 내부 대시보드를 도입하고, AI 도구 사용 여부를 성과 평가에 반영했습니다.
어떤 일이 벌어졌을까요?
"에이전트를 찾기 위한 에이전트, 에이전트를 평가하기 위한 에이전트까지 생겨났습니다."
에이전트가 너무 많아져서 그걸 관리하기 위한 에이전트를 또 만든 겁니다. AI로 AI를 다루는 메타 에이전트 인셉션이랄까요. 웃긴 동시에 슬프지만 사실입니다.
여기서 끝이 아닙니다. 메타는 직원들의 키보드 입력, 마우스 움직임, 클릭, 화면 내용까지 전면 추적하겠다고 공지했습니다. 목적은 AI 모델 학습용 데이터 확보였는데, 직원들은 즉각 반발했고 CTO인 앤드루 보즈워스(Andrew Bosworth)에게 "어떻게 옵트아웃 하냐"고 물었습니다.
돌아온 답변은 바로,
"업무용 노트북에는 옵트아웃 옵션이 없습니다."
이 답변에 직원들이 100개 이상의 분노·놀람 이모지로 반응했다는 사실이 모든 걸 말해줍니다.
그리고 5월 20일, 메타는 전체 인력의 10%인 약 8,000명을 해고했습니다. 직원들은 자신이 AI 대체 인력을 훈련시킨 게 아닌지 불안해하고 있습니다.
이 두 사례의 공통점
표면적으로는 "직원들이 AI를 열심히 안 쓴다"는 문제처럼 보입니다. 하지만 실제로는 완전히 다른 이야기입니다.
문제는 직원의 의지가 아니라, 구조입니다.
두 회사 모두 이렇게 했습니다.
"AI 써라"는 지시를 내린다
AI 사용량을 수치로 추적한다
그 수치가 평가에 영향을 미친다 (혹은 미친다는 인식이 퍼진다)
직원들은 수치를 채우기 위해 움직인다
실질적인 생산성 향상은 없고, 비용만 늘어난다
이걸 업계에서는 '토큰맥싱(Tokenmaxxing)' 이라고 부르기 시작했습니다. 품질과 무관하게 AI를 최대한 많이 쓰도록 장려하는 문화를 뜻하는 신조어죠.
워싱턴 대학교(University of Washington)의 레오 부시우(Leo Boussioux) 교수는 이 상황을 이렇게 표현했습니다.
"아직 직장에서의 AI 활용에 대한 플레이북이 없다."
딱 맞는 말입니다. 지시는 있지만, 방법이 없는 상태. 그게 지금 많은 기업의 현실입니다.
아 맞다! 에이전트 보안 이야기도 꼭 해야 합니다
아마존 직원들이 사용한 MeshClaw는 OpenClaw라는 도구에서 영감을 받아 만들어졌습니다. 두 도구의 공통점 중 하나는 사용자의 로컬 하드웨어에서 직접 실행된다는 점입니다.
이게 왜 중요하냐면, 로컬에서 실행된다는 건 그만큼 시스템 접근 권한이 높기 때문입니다. 코드 배포, 이메일 관리, 슬랙 접근까지 가능한 수준의 자율성을 가지고 있습니다.
실제로 올해 초, Meta Superintelligence Labs의 얼라인먼트(AI 안전성) 담당 디렉터가 OpenClaw를 사용하다가 이메일 받은편지함 전체가 거의 삭제될 뻔한 사건이 발생했습니다. AI 안전성 연구를 하는 사람이, 정작 AI 에이전트에게 접근 권한을 너무 많이 줬다가 일어난 아이러니한 사고입니다.
에이전트에게 자율성을 주기 전에, 거버넌스를 먼저 만들어야 합니다.
아마존의 한 직원도 MeshClaw에 대해 이렇게 말했습니다.
"기본 보안 설정이 공포스럽다. AI가 알아서 돌아다니게 두고 싶지 않다."
AI 에이전트가 할 수 있는 행동의 범위, 접근 가능한 데이터의 종류, 사람의 검토가 필요한 시점 등 이러한 것들이 정해지지 않은 상태에서 에이전트를 만들면 결국 이런 사고가 발생합니다.
해결법 : 실제로 작동하는 AI 도입의 순서
저는 기업들이 AI 도입에 실패하는 가장 큰 이유가 순서를 거꾸로 밟기 때문이라고 생각합니다.
현재 너무나 많은 기업들이 이렇게 시작합니다.
AI 도구 도입 → 직원들에게 써보라고 함 → 사용량 추적 → 뭔가 안 됨 → 탓
미래를 위한 올바른 순서는 반대입니다.
없애고 싶은 반복 업무 정의 → 워크플로우 설계 → 에이전트 구성 → 측정 → 확산
1단계: 가장 먼저 문제를 정의하기
"AI 도입"이 목표가 되면 안 됩니다. "월요일마다 수작업으로 만드는 보고서를 자동화한다", "하루에 50건씩 오는 반복 CS 문의를 분류한다" — 이렇게 구체적인 문제가 목표가 되어야 합니다.
2단계: 에이전트가 할 수 있는 일과 할 수 없는 일을 나누기
모든 작업을 에이전트에게 맡기는 게 아닙니다. "여기까지는 에이전트가, 이 지점에서는 사람이 확인"이라는 경계를 먼저 설계해야 합니다. 이걸 업계에서는 Human-in-the-Loop라고 부릅니다.
3단계: 접근 권한을 최소화하기
에이전트에게 필요한 것만 주세요. 이메일을 분류하는 에이전트가 코드 배포 권한까지 가질 필요는 없습니다. OpenClaw 사건의 교훈이 바로 이것입니다.
4단계: 토큰 사용량 말고 실질 지표를 측정하기
"주간 AI 사용자 비율"이나 "토큰 소비량"이 아니라, "자동화된 업무 건수", "절감된 시간", "에러 감소율" 같은 지표로 성과를 봐야 합니다. 수치가 보이면 직원들도 납득합니다.
5단계: 팀 단위 파일럿부터 시작하기
전사 강제 도입은 Amazon과 Meta가 이미 실패를 보여줬습니다. 한 팀에서 작게 시작해서 성공 사례를 만들고, 그걸 다른 팀에 퍼뜨리는 방식이 훨씬 지속 가능합니다.
직원들이 AI를 진짜로 쓰게 만들려면
직원들이 AI를 쓰는 척만 하는 건 그들의 잘못이라 보기 어렵습니다.
"왜 써야 하는지" 모르는 상태에서, "안 쓰면 평가에 불이익이 있을 수 있다"는 분위기만 조성되면 누구든 수치를 채우는 방향으로 움직입니다. 그건 어쩔 수 없는 인간의 합리적인 행동이고 사회적인 방법이니까요.
반대로 생각해보면, 직원이 AI를 진짜로 쓰게 만드는 건 어렵지 않습니다. 그 도구가 자신의 가장 귀찮은 업무를 실제로 줄여줄 때, 사람들은 자발적으로 씁니다. 그리고 주변 동료에게 자랑하듯 스스로 알립니다.
그게 진짜 AI 도입이고 우리가 이상하고 있는 AX의 정방향입니다.
Amazon과 Meta의 사례는 특이한 케이스가 아닙니다. 규모가 크다 보니 뉴스가 됐을 뿐, 비슷한 상황이 지금 수많은 기업에서 조용히 진행되고 있습니다.
"AI를 써라"는 지시보다 먼저 필요한 건, 어떤 문제를 풀 것인지에 대한 대화입니다.
에이전트를 만들기 전에 워크플로우를 설계하고, 자율성을 주기 전에 거버넌스를 갖추고, 사용량을 측정하기 전에 성과 기준을 정하는 것. 이 순서를 지키는 것만으로도 많은 것이 달라집니다.
AI 에이전트 도입을 고민 중이시라면, 지금 당장 이 질문부터 시작해보세요.
"우리 팀에서 가장 반복적이고 귀찮은 업무가 뭔가요?"
그 답이 나왔다면, 절반은 이미 시작된 겁니다.
아마존과 메타가 ONS와 Dify를 알았더라면?
조금 직설적으로 말하면, 이 두 회사는 AI를 모르지 않았을 겁니다. AX 과정에서 순서를 잘못 잡은 겁니다.
문제 1. 아마존 직원들은 왜 쓸모없는 에이전트를 만들었을까
에이전트를 만드는 데 아무런 진입 장벽이 없었기 때문입니다. "뭘 할 것인가"를 정하지 않아도 만들 수 있으니, 토큰 수치를 채우려는 사람들이 목적 없는 에이전트를 마구 만들기 시작한 겁니다.
Dify에서는 이게 구조적으로 불가능합니다. 워크플로우, 즉 에이전트가 어떤 흐름으로 움직일지를 먼저 설계하지 않으면 에이전트 자체를 시작할 수 없습니다. 어떤 데이터를 받아서 → 어떤 조건을 판단하고 → 어떤 결과를 내놓는지를 그림으로 그려야 비로소 작동합니다. 에이전트를 만드는 목적과 작은 아이디어를 그릴수만 있다면 쉽게 워크플로우에 구현해 낼 수 있습니다.
문제 2. 메타는 에이전트가 뭘 하고 있는지 아무도 몰랐다
에이전트를 만들고 나서 그게 실제로 어떻게 돌아가는지 볼 수 있는 방법이 없었습니다. 그러다 보니 "에이전트를 관리하기 위한 에이전트"가 생겨났고, 점점 통제가 안 되는 구조가 됐습니다.
Dify는 에이전트가 실행한 모든 단계를 로그로 기록합니다. 어떤 입력이 들어왔고, 어떤 판단을 했고, 어떤 결과를 냈는지를 노드 단위로 확인할 수 있습니다. "어제 에이전트가 뭘 했지?"라는 질문에 답할 수 있어야 제대로 운영하는 겁니다. 블랙박스가 아니라 물고기의 움직임을 보듯 수족관을 들여다 보는 것과 같다고 보면 되죠.
문제 3. OpenClaw 보안 사고 — 에이전트한테 너무 많은 걸 줬다
이메일 받은편지함이 통째로 날아갈 뻔한 사건, 기억하시죠. AI 안전성을 연구하는 사람도 당한 사고였습니다. 에이전트에게 처음부터 너무 넓은 접근 권한을 줬기 때문에 생긴 일입니다.
에이전트 권한을 생각할 때 이렇게 접근하면 쉽습니다. 이 에이전트를 사람 직원이라고 가정했을 때, 어느 직급에게 줄 수 있는 권한인가. 인턴한테 전사 이메일 발송 권한을 주지 않듯이, 에이전트도 필요한 것만 줘야 합니다.
Dify에서는 워크플로우를 설계하는 단계에서 각 노드가 어떤 도구에 접근할 수 있는지를 명시적으로 지정합니다. 이메일 분류 에이전트라면 이메일 읽기 권한만, 슬랙 알림 에이전트라면 메시지 전송 권한만. 나중에 "얘가 어디까지 건드렸지?" 하는 상황이 생기지 않는 이유입니다.
문제 4. 토큰 사용량이 성과 지표가 되면 생기는 일
라인 수로 개발자 생산성을 재는 것과 같습니다. 좋은 코드는 줄이 적고, 좋은 에이전트는 개입이 적습니다. 가장 잘 만들어진 에이전트는 사실 좀 심심합니다. 매일 같은 일을 조용히, 정확하게 반복합니다.
실제로 잘 운영되는 팀들을 보면 화려한 멀티에이전트 시스템보다, CS 팀에서 매일 반복되는 문의 유형을 분류하는 단순한 워크플로우 하나로 하루 두 시간씩 아끼는 경우가 훨씬 많습니다. 그게 직원이 팀장한테 먼저 자랑하게 되고, 다음 달엔 세 팀이 따라 만드는 방식으로 퍼집니다. 전사 도입 선언 없이도요
끝으로, AI에이전트 많이 만들었다는 사례에 현혹되지 말기
ONS 팀과 Dify가 기업에게 공통적으로 말하는 건 하나입니다. AI를 "많이" 쓴 게 아니라, "제대로 된 곳에" 썼다는 것.
아마존과 메타가 도구보다 구조를 먼저 찾았다면, 아마 이야기가 달랐을 겁니다.
오픈네트웍시스템 ㅣ 권태규