AI를 조직에 붙일 때 실패하는 지점은 모델 성능이 아니라 측정·게이트·책임 설계다. 메타·아마존·앤트로픽이 2025~2026년에 실제로 겪고 스스로 되돌린 10가지 실패 패턴과 완화책을 근거 등급과 함께 정리했다.
AI 도입 실패를 다룬 글은 대부분 데이터 품질과 변화관리에서 끝난다. 그런데 지난 1년 사이 실제로 크게 터진 사고는 결이 다르다. 모델이 부족해서가 아니라, 조직이 AI를 붙이는 방식이 잘못돼서 터졌다. 아래 열 가지 중 여덟 가지는 가정이 아니다. 빅테크와 AI 랩이 스스로 겪고 인정하고 되돌린 일이다. 남은 두 가지는 사례 대신 구조적 위험으로 표시했다.
가장 비싼 실패는 세 가지였다. 사용량을 성과지표로 만든 것, 개인을 감시한 것, 사람 검토 없이 배포한 것.
요약 (Quick Answer)
가장 비싼 실패 세 가지
| # | 실패 | 실제로 벌어진 일 | 되돌린 방식 |
|---|---|---|---|
| 2 | 사용량을 KPI로 | 메타 토큰맥싱, 30일 73.7조 토큰 | 리더보드 폐지 |
| 3 | 개인 감시 | 키보드·클릭 수집, 1,600명 서명 | CEO 실수 인정 |
| 4 | 사람 검토 없는 배포 | 아마존 키로 13시간 장애 | 2인 리뷰 의무화 |
자동화의 반대말은 사람 검토가 아니다
메타 RADAR는 저·중위험 변경만 자동 승인했고, 그 변경의 리버트율은 나머지의 1/3, 운영 사고율은 1/50이었다. 아마존은 반대로 운영 배포에 2인 리뷰를 다시 걸었다. 두 사례의 공통점은 위험 등급에 따라 게이트를 달리 뒀다는 것이다. 자동화의 반대말은 사람 검토가 아니라 위험 구분 없는 게이트다.
버릴 지표 → 대체 지표
| 버릴 지표 | 대체 지표 |
|---|---|
| 토큰 사용량, AI 호출 수 | 리드타임(커밋→배포) |
| AI 도구 로그인·활성 사용자 | 변경 실패율, 롤백률 |
| AI 생성 코드 비중 | 결함 유출률, 운영 사고 건수 |
| 리더보드 순위 | 고객 지표(전환·이탈·응답시간) |
규모가 작으면 세 가지만
사용량 KPI 제거 · 변경 위험 등급표 한 장 · 결정 문서에 책임자 명시.
문서 세 장으로 시작할 수 있고, 나머지 일곱 개는 대부분 이 셋의 파생이다.
근거 등급: [1차] 회사·연구기관 직접 공개 / [보도] 언론 확인 / [증언] 개별 발언 한 건 / [추론] 구조적 예측 / [미확인] 공개 자료 미확인
사실 확인일: 2026-09-08
열 가지 실패 패턴 한눈에 보기
| # | 실패 패턴 | 실제로 벌어진 일 | 완화책 | 근거 |
|---|---|---|---|---|
| 1 | AI가 만든 관료제 | 문서·보고 생산이 쉬워지면서 읽고 고쳐야 할 산출물이 늘어남. 스탠퍼드·베터업 조사에서 응답자 41%가 한 달 안에 '워크슬롭'을 받았고, 한 건 정리에 평균 1시간 56분 | 푸시가 아닌 풀 우선, 요약의 요약(digest) 계층화, 원문 링크 의무 | [1차]+[보도] |
| 2 | 사용량 지표 최적화 | 메타가 AI 사용량을 인사평가 기대치로 걸자 결과 없이 토큰만 태우는 토큰맥싱이 나옴. 사내 리더보드 '클로드노믹스'는 30일 기준 60.2조에서 73.7조 토큰까지 오른 뒤 폐지 | 결과 지표(품질·속도·고객가치)만 사용, 사용률 자체의 KPI화 금지 | [보도] |
| 3 | 감시 문화 | 메타가 미국 직원의 키보드·클릭 입력을 AI 학습에 수집하자 1,600명 이상이 반대 서명. 강제 전배와 겹쳐 일부 직원이 자기 조직을 굴라크에 비유 | 팀·조직 단위 지표만 사용, 개인 단위 추적 금지, 목적을 코칭으로 명문화 | [보도] |
| 4 | 지나친 자동화 | 아마존 사내 AI 코딩 도구 키로가 운영 환경을 삭제·재생성해 13시간 장애. 이후 90일 안전 리셋과 운영 배포 2인 리뷰 의무화 | 위험 기반 차등 게이트 — 저위험만 자동, 고위험은 사람 필수 | [보도] |
| 5 | 매니저의 책임 회피 | 어려운 인사·기술 결정을 "AI가 그렇게 판단했다"로 미룰 여지 | 최종 책임은 항상 이름 있는 사람(DRI), 에이전트는 정보 제공자로만 문서화 | [추론] |
| 6 | AI 할루시네이션 | 의사결정 지원 도구가 틀린 과거 사례나 없는 데이터를 근거로 제시 | 응답마다 출처 추적, 중요 결정엔 사람 검증 게이트, 불확실성 명시 | [1차] |
| 7 | 정보 과잉 | 컨텍스트 레이어가 전부 노출하면 신호 대 잡음비가 나빠짐 | 역할 기반 관련성 필터링, digest 배포, 푸시 최소화 | [추론] |
| 8 | 스킬 퇴화 | 앤트로픽 자체 조사의 '감독의 역설' — Claude를 제대로 감독하려면 위임으로 퇴화할 바로 그 스킬이 필요 | 의도적 학습 시간 확보, 주니어 온보딩 구간에서 사용 제한, 리뷰에서 "왜"를 설명 | [1차] |
| 9 | 암묵지 손실 | 같은 조사에서 Claude가 동료에게 가던 질문의 첫 창구가 됐고, 시니어의 멘토링 기회가 줄었다는 응답이 나옴 | 페어링·멘토십 시간 별도 보장, AI 사용 후에도 사람 리뷰 세션 유지 | [1차]+[증언] |
| 10 | 조직 정치 도구화 | AI가 만든 데이터를 선택적으로 인용해 평가나 정치적 목적에 쓸 여지 | 데이터 접근·활용 투명성, 평가에 AI가 미친 영향을 문서화·감사 | [추론] |
측정을 잘못하면 조직이 먼저 망가진다
#2 사용량 지표 최적화 — 사용량을 성과지표로 삼으면 사용량만 늘어난다
메타는 AI 활용을 인사평가의 핵심 기대치로 걸었다. 결과는 토큰맥싱이었다. 이미 문서에 있는 내용을 굳이 AI에 물어 10배 느리게 답을 받고, 손댈 생각 없는 기능을 프로토타이핑하고, 에이전트를 여러 개 동시에 돌린다.
사내 리더보드 '클로드노믹스(Claudeonomics)'는 8만 5천 명 넘는 사용자의 토큰 사용량을 줄 세웠다. 상위 250명이 순위로 노출됐고 '토큰 레전드' 같은 칭호가 붙었다. 4월 대시보드 기준 30일 누적 사용량이 60조 2천억 토큰이었고, 이후 73조 7천억까지 오른 뒤 순위표가 폐지됐다. CTO 앤드루 보즈워스는 사내 메모에서 도구를 쓰기 위해 도구를 쓰는 일을 경계하며, 사용량만으로는 어떤 영향력도 측정할 수 없다고 못 박았다. 2026년 9월 초 메타는 평가 문구를 다시 손질해 AI 도입 대시보드나 토큰 수를 임팩트 평가에 쓰지 않는다는 방향을 명시했다.
아마존도 같은 길을 걸었다. 사내 AI 사용량 랭킹 '키로랭크'는 점수를 올리려는 불필요한 활동이 늘면서 폐지됐다. 우버와 서비스나우는 연간 AI 예산을 몇 달 만에 소진하고 사용량 모니터링과 상한을 도입했다.
도입 초기에 사용량을 보는 것 자체는 합리적이다. 채택률은 어차피 확인해야 한다. 문제는 그 숫자를 평가에 연결하는 순간이다. 관찰 지표와 평가 지표를 같은 대시보드에 두지 말자. 채택률은 팀 단위로 한 분기만 보고 접고, 평가에는 리드타임, 변경 실패율, 결함 유출, 고객 지표만 남긴다.
지표 교체표 — 사용량 지표를 결과 지표로 옮기는 최소 매핑이다.
| 버릴 지표 | 대체 지표 | 보는 단위 |
|---|---|---|
| 토큰 사용량, AI 호출 수 | 리드타임(커밋→배포) | 팀 |
| AI 도구 로그인·활성 사용자 | 변경 실패율, 롤백률 | 팀 |
| AI 생성 코드 비중 | 결함 유출률, 운영 사고 건수 | 서비스 |
| 리더보드 순위 | 고객 지표(전환·이탈·응답시간) | 제품 |
#3 감시 문화 — 개인 단위 감시는 신뢰를 먼저 태운다
메타는 미국 직원의 마우스 클릭과 키보드 입력을 수집해 AI 학습에 쓰는 프로그램을 돌렸고, 옵트아웃이 없었다. 1,600명 넘게 반대 서명을 했고, 회사는 최대 30분 일시정지와 개별 면제 신청을 열어주는 선에서 물러섰다. 같은 시기 약 6,500명이 사전 통보 없이 응용 AI 조직으로 전배됐고, 일부는 자기 처지를 굴라크에 비유했다. 마크 저커버그는 6월 12일 메모에서 회사가 실수했다고 인정했다.
주의할 점 하나. 굴라크라는 표현은 감시 도구 자체보다 강제 전배와 데이터 라벨링 업무를 향한 것이었다. 두 사건이 같은 분기에 겹쳐 신뢰를 함께 깎았다고 읽는 편이 정확하다.
감시가 만드는 건 성과가 아니라 연극이다. 감시 도구를 쓰는 회사에서 직원의 61%가 성과 연극을 했다고 답하고 감시받지 않는 쪽은 12%였다는 조사가 인용되는데, 이 수치는 원문 대조를 못 했다 [미확인]. 방향은 여러 조사가 같지만 숫자를 인용하려면 출처를 먼저 확인하는 게 맞다.
지표는 팀 단위로만 보고, 개인 화면에 뜨는 숫자는 본인만 보게 하고, 목적을 코칭으로 문서에 박아두는 편이 낫다.
자동화의 경계를 어디에 그을 것인가
#4 지나친 자동화 — 사람 검토 없는 배포는 결국 대형 장애로 돌아온다
2025년 12월 중순, AWS 엔지니어가 사내 에이전트형 코딩 도구 키로에 작은 버그를 맡겼다. 도구는 환경을 삭제하고 다시 만드는 쪽이 최선이라고 판단했고, 13시간 장애가 났다. 파이낸셜타임스가 2026년 2월 20일에 복수 소식통을 인용해 보도한 내용이다. 영향 범위는 보도마다 조금 다르게 적힌다. 고객용 비용 계산기가 멈췄다는 서술과 중국 리전 일부 서비스가 타격을 받았다는 서술이 함께 돈다. 정확한 대상 시스템은 회사가 공식 확인하지 않았다.
2026년 3월에는 소매 쪽에서 사고가 이어졌다. 3월 2일 사고는 사내 AI 어시스턴트와 연결된 것으로 보도됐고 약 160만 건의 오류와 12만 건 규모의 주문 손실이 언급됐다. 3월 5일에는 더 큰 중단이 발생해 630만 건대 주문 손실이 보도됐다. 회사는 AI 자율성 문제가 아니라 접근 권한과 절차 문제라는 입장이고, 내부 문서에는 공식 문서화·승인 절차 없이 배포된 운영 변경이 원인으로 적혔다고 보도됐다. 인과 해석은 지금도 회사 입장과 내부 문서가 엇갈린다.
대응은 이렇게 정리됐다. 90일 안전 리셋, 운영 배포 전 2인 리뷰 예외 없음, 주니어·미들 엔지니어의 AI 지원 운영 변경에는 시니어 사인오프, 공식 문서화와 승인 절차 준수, 배포 전 자동 검사 강화. 아마존 수석부사장 데이브 트레드웰은 생성형 AI 도구가 운영 변경을 보완하고 가속하면서 안전하지 않은 관행으로 이어졌다고 인정했고, 회사의 AI 안전장치가 아직 완전히 확립되지 않았다고 말했다.
초안에 있던 "티어1 시스템 약 335개"와 "통제된 마찰"이라는 표현은 공개 보도에서 확인하지 못했다 [미확인]. 대상 시스템 수와 인용구는 빼거나 확인 후 넣는 게 안전하다. 다만 마찰을 어디에 배치할지 고르는 것이 설계라는 논지는 그대로 성립한다. 마찰은 비용이고, 그 비용을 어디에 쓸지 정하는 일이 게이트 설계다.
그래서 게이트는 전부 사람이어야 하나
아니다. 메타의 RADAR는 반대 방향의 답을 보여준다. 메타에서 사람이 랜딩한 diff당 유효 코드 줄 수는 전년 대비 105.9% 늘고, 개발자당 월 diff 수는 51% 늘었다. 그 증가의 80% 이상이 에이전트형 AI였다. 같은 기간 24시간 내 리뷰 비율은 떨어졌다. 사람이 모든 diff를 읽는 워크플로는 이 속도를 못 받는다.
RADAR는 diff를 작성 주체와 출처로 분류하고, 자격 게이트와 정적 휴리스틱, 머신러닝 위험 점수(Diff Risk Score), LLM 코드리뷰, 결정론적 검증을 거쳐 저·중위험만 자동으로 랜딩시킨다. 논문 기준 성과는 이렇다.
| 항목 | 값 |
|---|---|
| 리뷰한 diff | 53.5만 건 이상 |
| 랜딩한 diff | 33.1만 건 이상 |
| 처리량 | 일 2.5만 건 이상 |
| 자동 승인률 | 60.31% (위험 점수 임계값을 25분위→50분위로 완화 후) |
| 검증(Verification) 통과율 | 26.31% |
| 리버트율 | RADAR 외 diff의 1/3 |
| 운영 사고율 | RADAR 외 diff의 1/50 |
| 중위 종료 시간 | 330% 이상 단축 |
| 중위 리뷰 대기 시간 | 35% 단축 |
주목할 설계는 임계값을 조직과 출처에 따라 다르게 잡는다는 점이다. 안전 이력이 검증된 허용 목록 런북에는 P50(가장 안전한 50%)을, 허용 목록에 없는 봇과 AI 도구에는 P20을 적용한다. 런북 하나가 자동화 자격을 얻으려면 60일 룩백 기간에 운영 사고 0건, 낮은 리버트율, 낮은 사람 반려율을 만족해야 한다. 임계값은 OrgRADARPolicyConfig로 조직마다 따로 잡는다 — 위험 감수 수준을 팀별로 다르게 가져갈 수 있다는 뜻이다. 자동화의 반대말은 사람 검토가 아니라 위험 구분 없는 게이트다.
논문의 한계도 같이 읽어야 한다. RADAR가 대체한 개별 사람 리뷰의 반사실적 가치를 측정한 연구가 아니고, 무작위 배정이 아닌 관찰 기반 이중차분 분석이다. 여러 변경이 근접한 시점에 랜딩하면 사고 귀속이 부정확할 수 있고, 일부 리버트는 실제 결함이 아니라 예방적 조치일 수 있다. 표준화된 테스트와 점진 배포가 갖춰진 대규모 모노레포 환경의 결과라 리포지토리 구조와 리뷰 관행이 다른 조직에서는 수치가 그대로 나오지 않는다.
작은 조직이라면 이렇게 옮길 수 있다. 변경 대상을 세 단계로 나눈다. 결제·인증·마이그레이션·인프라 삭제는 무조건 사람 2인. 일반 기능은 자동 검사 통과 후 1인. 문서·테스트·린트·명백한 리팩터링은 자동. 등급표를 리포지토리 루트에 두고 분기마다 사고 이력으로 갱신한다. RADAR의 60일 무사고 조건을 흉내내려면, 자동 통과 대상은 최근 한 분기 사고 이력이 없는 범주로 제한하면 된다.
#5 매니저의 책임 회피 — AI 판단을 방패로 쓰는 경우
이건 아직 공개 사례가 없는 구조적 위험이다. 그래도 예측은 쉽다. 성과 데이터가 대시보드로 정리되면 "AI가 이렇게 봤다"는 문장이 힘든 대화를 대신하기 시작한다. 저성과 대화, 조직 개편, 프로젝트 중단 같은 결정이 그렇다.
이 구조는 조직 마찰의 한 형태다. 결정권이 위원회나 도구로 흩어지면 아무도 결정하지 않는 상태가 된다 — 고성과 조직이 결정권을 이름 있는 한 사람에게 귀속시키는 이유를 AI-native 조직 설계 7가지 질문에 정리해뒀다.
막는 방법은 단순하다. 모든 결정 문서에 이름 있는 책임자를 한 명 적는다. 에이전트는 정보 제공자로만 기록하고, 결정 근거란에 AI 출력을 그대로 붙이지 못하게 한다. 사람이 그 출력을 어떻게 읽었는지 한 문단으로 써야 통과되는 양식이면 충분하다.
정보가 늘어난다고 판단이 좋아지지는 않는다
#1 AI가 만든 관료제
스탠퍼드 소셜미디어랩과 베터업이 미국 정규직 1,150명을 조사해 하버드비즈니스리뷰에 실은 결과를 보면, 41%가 최근 한 달 안에 워크슬롭을 받았다. 그럴듯해 보이지만 일을 진척시키지 못하는 AI 산출물이다. 한 건 처리에 평균 1시간 56분이 들고, 1인당 월 186달러 수준의 손실로 환산됐다. 절반 가까이가 그런 문서를 보낸 동료를 이전보다 덜 유능하고 덜 신뢰할 만하다고 봤다. 자기보고 기반 추정이라 금액 자체는 참고선으로만 보는 게 맞지만, 방향은 여러 조사가 같다.
읽는 사람에게 인지 부담을 넘기는 게 문제의 핵심이다. 그래서 푸시를 줄이고 풀을 늘린다. 주간보고를 전원에게 보내는 대신 조회 가능한 한 곳에 쌓고, 상위 계층에는 사람이 판단한 요약만 올린다. AI로 만든 문서에는 원문 링크와 검증 여부를 달게 한다.
#7 정보 과잉 — 컨텍스트 레이어와 신호 대 잡음비
사내 지식을 한 곳에 모으면 접근성은 좋아지지만 관련성은 나빠진다. 전부 노출하는 컨텍스트 레이어는 검색 결과를 늘리는 대신 판단을 흐린다. 역할별로 기본 노출 범위를 다르게 잡고, 알림은 digest로 묶고, 푸시는 마감·장애·승인 세 종류로 제한하는 편이 낫다. 이 항목도 사례보다 설계 원칙에 가깝다.
#6 AI 할루시네이션 — 잘못된 근거가 의사결정에 들어올 때
앤트로픽 사내 조사에서 한 보안 엔지니어는 Claude가 제안한 방식을 위험한 방향으로 똑똑했다고 표현했다. 재능 있는 주니어가 낼 만한 제안이었고, 문제를 알아채는 데는 경험이 필요했다. 코드에서도 이렇다면 의사결정 지원에서는 더하다.
세 가지를 요구하면 대부분 걸러진다. 응답마다 출처를 남기게 하고, 중요 결정에는 사람 검증 게이트를 두고, 확신 수준을 같이 출력하게 한다. 마지막 항목이 특히 값싸고 효과가 크다. 모른다고 말하지 않는 도구는 회의에서 가장 비싼 참석자가 된다.
사람과 지식은 조용히 빠져나간다
#8 스킬 퇴화 — 감독의 역설
앤트로픽은 2025년 8월 사내 엔지니어·연구자 132명을 설문하고 53명을 인터뷰했다(공개는 2025년 12월 2일). 거기서 나온 개념이 감독의 역설이다. Claude를 효과적으로 쓰려면 감독이 필요하고, 감독하려면 과도한 위임으로 퇴화하는 바로 그 코딩 스킬이 필요하다. 한 응답자는 스킬 자체보다 감독 문제를 더 걱정한다고 말했다. 어떤 엔지니어는 Claude가 충분히 풀 수 있는 문제도 일부러 직접 풀어 감각을 유지한다고 했다.
같은 조사에는 위임의 실제 폭도 나온다. 응답자의 절반 이상이 하루 업무 중 완전히 위임할 수 있는 범위를 0~20%로 답했다. 도구를 만든 회사의 엔지니어들이 그렇게 답했다. 한편 Claude가 보조한 작업의 27%는 원래 하지 않았을 일이었고, 코드 설계·아키텍처 용도는 1%에서 10%로, 기능 구현은 14%에서 37%로 늘었다. 범위는 넓어지는데 완전 위임은 여전히 제한적이라는 두 사실이 같은 조사에 함께 있다.
여기서 오해하기 쉬운 지점이 있다. 전문성이 무의미해진 게 아니라 더 벌어졌다. 앤트로픽이 2026년 6월 16일 공개한 후속 연구는 2025년 10월부터 2026년 4월까지 약 23만 5천 명의 클로드 코드 세션 약 40만 건을 분석했다. 가장 엄격한 검증 성공률이 초심자 15%, 중급 이상 2833%였다. 막힌 세션이 코드 한 줄 없이 버려지는 비율은 초심자 19%, 나머지 57%였다. 초심자와 중급의 격차가 중급과 전문가의 격차보다 크다.
같은 연구에서 협업의 모양도 드러난다. 사람이 계획 결정의 약 70%를 하고 Claude가 실행 결정의 약 80%를 한다. 프롬프트 하나당 전문가는 12개 액션과 3,200단어를 끌어내고 초심자는 5개 액션과 600단어를 끌어낸다. 직군 간 성공률 차이는 크지 않았고, 열 개 주요 직군이 7포인트 안에 들어왔다. 코딩 배경보다 도메인 이해가 성과를 만든다는 쪽으로 읽히는 결과다.
이 결과는 시니어의 정의와도 맞물린다. 실행량이 아니라 판단·감독·문제 정의로 레벨을 보는 관점을 나는 시니어 개발자인가?에 따로 적었다.
조직에 옮기면 이렇게 된다. 주니어 온보딩 첫 구간에는 자동 생성 범위를 제한하고, 코드리뷰에서 무엇을 고쳤는지가 아니라 왜 그렇게 고쳤는지를 설명하게 한다. 학습 시간을 캘린더에 넣지 않으면 그 시간은 생기지 않는다.
#9 암묵지 손실 — 멘토링 기회가 줄어든다
같은 조사에서 Claude는 예전에 동료에게 가던 질문의 첫 창구가 됐다. 한 직원은 질문의 80~90%가 Claude로 간다고 말했다. 조직 전체 통계가 아니라 인터뷰 한 사람의 발언이니 그렇게 인용하는 게 맞다. 다른 응답자는 팀 의존도가 80% 줄었지만 남은 20%가 결정적이라고 했다. 한 시니어는 주니어가 질문을 덜 들고 오는 게 아쉽다면서도, 그들이 답은 더 빠르게 얻는다고 덧붙였다.
절반 정도는 협업 패턴이 그대로라고 답했다. 그러니 붕괴로 부풀릴 일은 아니다. 다만 멘토링은 원래 우연한 질문에 얹혀 있던 활동이고, 그 우연이 사라지면 남는 건 일정에 박아둔 시간뿐이다. 페어링과 리뷰 세션을 별도 블록으로 잡고, AI로 해결한 문제도 사람 리뷰를 한 번 거치게 한다.
#10 조직 정치 도구화 — AI 데이터가 평가에 쓰일 때
평가 시즌에 AI 대시보드가 있으면 유리한 숫자만 골라 인용하는 일이 생긴다. 이것도 아직 사례가 아니라 위험이다. 접근 권한과 조회 로그를 남기고, 평가 문서에 AI 데이터가 어떤 판단에 어떻게 쓰였는지 적게 하고, 분기마다 표본 감사하면 대부분 억제된다.
규모별로 무엇부터 할 것인가
빅테크의 대응을 그대로 복사하면 작은 조직에서는 마찰만 남는다. 인원 규모별로 순서가 다르다.
| 개발 인원 | 먼저 할 것 | 아직 안 해도 되는 것 |
|---|---|---|
| ~15명 | 사용량 KPI 제거, 변경 위험 등급표 한 장, 결정 문서에 책임자 명시 | 자동 리뷰 파이프라인, 위험 점수 모델 |
| 15~50명 | 고위험 변경 2인 게이트, 저위험 자동 통과 범위 지정, 주간보고 풀 방식 전환 | 조직 단위 AI 대시보드 |
| 50명 이상 | 리스크 점수화와 자동 리뷰 도입 검토, 온보딩 학습 제한 설계, 평가 감사 절차 | — |
세 구간 모두에서 먼저 없애야 하는 것은 같다. 개인 단위 사용량 추적과 평가 연결이다.
도입 전 점검표
- 사용량 지표가 평가 문서에 들어가 있지 않은가
- 개인 단위 추적 데이터를 매니저가 볼 수 있는가
- 변경 위험 등급표가 문서로 존재하고 최근 사고 이력으로 갱신되는가
- 고위험 변경에 사람 2인 게이트가 예외 없이 걸리는가
- 저위험 변경은 사람 리뷰 없이 통과되는가
- 모든 결정 문서에 이름 있는 책임자가 적혀 있는가
- AI 응답에 출처와 확신 수준이 함께 남는가
- 문서는 푸시되는가 조회되는가
- 주니어 온보딩 구간에 학습용 제한과 학습 시간이 설계돼 있는가
- 페어링·멘토십 시간이 캘린더에 고정 블록으로 있는가
세 개 이상 아니오면 도구를 더 붙일 단계가 아니다.
초안에서 고친 사실 여섯 가지
검증 과정에서 걸러낸 부분을 남긴다. 이 글의 수치는 2026년 9월 8일 기준으로 대조했다.
메타 리더보드의 이름은 '클로드노믹스(Claudeonomics)'다. 초안의 '클로디노믹스'는 표기 오류였다. 30일 누적 사용량은 4월 대시보드 기준 60조 2천억 토큰이었고, 73조 7천억까지 오른 뒤 폐지됐다. 초안은 73.7조만 적어 상승 과정이 빠져 있었다.
메타의 굴라크 비유는 개인 감시 도구 도입 직후의 반응이 아니라, 강제 전배와 데이터 라벨링 업무에 대한 표현이었다. 키보드·클릭 수집 프로그램은 별개 사안이고, 1,600명 이상의 반대 서명은 그쪽에 붙는다.
질문의 80~90%가 Claude로 간다는 수치는 앤트로픽 조사의 집계값이 아니라 인터뷰 응답자 한 명의 발언이다.
아마존 키로 사고의 날짜는 12월 중순으로 보도됐고, 초안의 12월 15일은 특정 근거를 찾지 못했다. 영향받은 시스템도 보도마다 비용 계산기와 중국 리전 서비스로 갈린다.
아마존 장애의 인과는 확정되지 않았다. 회사는 접근 권한과 절차 문제로 보고, 내부 문서는 문서화·승인 절차 없이 배포된 AI 지원 변경을 원인으로 언급했다고 보도됐다. 90일 안전 리셋과 2인 리뷰 의무화라는 대응만 사실로 확정된다.
티어1 시스템 약 335개, '통제된 마찰'이라는 인용구, 감시 도구 사용 기업의 성과 연극 61% 대 12% 수치는 공개 자료에서 확인하지 못했다. 인용 전 원문 확인이 필요하다.
자주 묻는 질문
AI 사용량은 아예 측정하지 말아야 하나요?
도입 초기 채택률 확인용으로는 유효하다. 평가와 연결하지 않는 게 핵심이다. 메타와 아마존은 둘 다 사내 리더보드를 폐지했고, 메타는 대시보드와 토큰 수를 임팩트 평가에 쓰지 않는 방향으로 평가 문구를 고쳤다.
이미 사내 리더보드를 운영 중이면 어떻게 접어야 하나요?
발표 없이 조용히 끄는 것보다, 무엇을 대신 볼지 함께 공지하는 편이 낫다. 위 지표 교체표의 네 줄이면 공지 한 장이 된다. 메타·아마존 사례를 근거로 들면 "우리 회사만 후퇴한다"는 반응을 줄일 수 있다.
토큰맥싱은 정확히 무슨 뜻인가요?
평가나 승진에서 불이익을 피하려고 결과와 무관하게 AI 토큰 사용량을 의도적으로 늘리는 행동이다. 룩스맥싱에서 온 조어로, 2026년 초 메타·아마존·마이크로소프트 등에서 관찰됐다.
AI 코드리뷰를 자동화하면 위험하지 않나요?
위험 구분 없이 자동화하면 위험하다. 메타 RADAR는 저·중위험 diff만 자동 랜딩시켰고, 그 diff들의 리버트율은 나머지의 1/3, 운영 사고율은 1/50이었다. 아마존은 반대로 운영 배포에 2인 리뷰를 다시 걸었다. 두 사례의 공통점은 위험 등급에 따라 게이트를 달리 뒀다는 것이다.
RADAR를 작은 조직이 따라할 수 있나요?
모델과 파이프라인은 못 따라간다. 옮길 수 있는 건 세 가지다. 변경을 위험 등급으로 나누는 문서, 자동 통과 대상을 최근 사고 이력 없는 범주로 제한하는 규칙, 등급표를 분기마다 갱신하는 주기. 논문 결과도 표준화된 테스트와 점진 배포가 갖춰진 대규모 모노레포 환경 기준이라 그대로 이식되지 않는다.
감독의 역설은 무슨 뜻인가요?
AI 출력을 제대로 감독하려면 전문 스킬이 필요한데, 그 스킬은 AI에 위임할수록 퇴화한다는 구조를 가리킨다. 앤트로픽이 2025년 사내 조사에서 쓴 표현이다.
주니어에게 AI 사용을 제한하는 게 맞나요?
전면 금지가 아니라 온보딩 구간의 범위 제한이 현실적이다. 앤트로픽 후속 연구에서 초심자 세션의 검증 성공률은 15%, 중급 이상은 28~33%였고, 막힌 세션을 코드 없이 버리는 비율도 초심자가 19%로 가장 높았다. 도메인 이해가 성과를 만들고, 그 이해는 초기에 손으로 쌓인다.
AI 생성 코드 비중을 지표로 보면 안 되나요?
비중 자체는 결과와 연결되지 않는다. 메타 데이터에서 diff당 코드량과 개발자당 diff 수가 각각 105.9%, 51% 늘었지만 그 시기에 24시간 내 리뷰 비율은 떨어졌다. 생산량이 늘었다는 신호와 조직이 그걸 감당한다는 신호는 다른 지표다.
개발조직 규모가 작으면 이 중 무엇부터 봐야 하나요?
사용량 KPI 제거, 변경 위험 등급표, 결정 문서의 책임자 명시 세 가지다. 도구 없이 문서 세 장으로 시작할 수 있고, 나머지 일곱 개는 대부분 이 셋의 파생이다.
이 글의 핵심 메트릭
- 메타 클로드노믹스: 사용자 8.5만 명+, 30일 누적 60.2조 → 73.7조 토큰, 폐지
- 메타 감시 프로그램: 반대 서명 1,600명+, 전배 약 6,500명, CEO 실수 인정(6/12)
- 아마존 키로: 13시간 장애(2025-12 중순), 90일 안전 리셋, 운영 배포 2인 리뷰
- 아마존 3월 사고: 3/2 오류 160만 건·주문 손실 12만 건 / 3/5 주문 손실 630만 건대
- 메타 RADAR: 리뷰 53.5만+ · 랜딩 33.1만+ · 일 2.5만+ · 자동 승인 60.31% · 검증 통과 26.31%
- RADAR 안전 지표: 리버트율 1/3, 운영 사고율 1/50, 종료 시간 330%+ 단축, 리뷰 대기 35% 단축
- 메타 코드 증가: diff당 유효 코드 105.9%↑, 개발자당 diff 51%↑, 증가분의 80%+가 에이전트형 AI
- RADAR 자격 조건: 60일 룩백 · 운영 사고 0건 · 낮은 리버트율 · 낮은 사람 반려율
- 앤트로픽 1차 조사: 132명 설문 + 53명 인터뷰 (2025-08 조사, 2025-12-02 공개)
- 앤트로픽 후속 연구: 세션 약 40만 건 · 약 23.5만 명 (2025-10~2026-04, 2026-06-16 공개)
- 검증 성공률: 초심자 15% / 중급 이상 28
33%. 코드 없이 버린 세션 초심자 19% / 나머지 57% - 협업 분담: 계획 결정 사람 약 70% / 실행 결정 Claude 약 80%
- 프롬프트당 산출: 전문가 12액션·3,200단어 / 초심자 5액션·600단어
- 완전 위임 가능 범위: 응답자 절반 이상이 일과의 0~20%로 응답
- 워크슬롭: 정규직 1,150명 조사, 41%가 한 달 내 수신, 건당 1시간 56분, 1인당 월 $186
- 사실 확인일: 2026-09-08
함께 읽으면 좋은 글
- AI-native 조직 설계 7가지 질문 — 조직 마찰의 구조와 결정권 설계
- 나는 시니어 개발자인가? — 실행량이 아닌 판단·감독으로 보는 레벨
- 개발자 레벨 완벽 정리 — scope·ownership·impact 평가 기준
출처
- Anthropic, How AI is transforming work at Anthropic (2025-12-02, 2025년 8월 조사 132명·인터뷰 53명)
- Anthropic, Agentic coding and persistent returns to expertise (2026-06-16, 세션 약 40만 건·약 23.5만 명)
- Meta, Automating Low-Risk Code Review at Meta: RADAR (arXiv 2605.30208)
- HBR, AI-Generated "Workslop" Is Destroying Productivity (2025-09)
- The Pragmatic Engineer, The Pulse: 'Tokenmaxxing' as a weird new trend
- AI타임스, 메타, 사내 AI 비용 폭증에 '토큰 제한' (60.2조→73.7조·보즈워스 메모)
- 뉴스스페이스, 아마존 '키로랭크' 폐지 (클로드노믹스 8.5만 명·토큰 레전드)
- ITWorld, AI 프로그래밍의 한계를 절감하고 있는 아마존 (트레드웰 발언·90일 규칙)
- Fortune, Meta killed its employee AI token dashboard
- TNW, Inside the revolt at Meta's AI unit
- 요즘IT, '토큰 맥싱'의 시대는 끝났다: 메타·아마존·우버의 선택
'🔧 인프라 & 네트워크' 카테고리의 다른 글
| 트래픽 없는 로드밸런서 찾기 (2026) — LCU는 0인데 시간요금만 나가는 ALB·NLB (0) | 2026.09.23 |
|---|---|
| EC2를 껐는데 요금이 계속 나온다 (2026) — 중지 인스턴스에 남는 과금 3가지와 청구서에서 찾는 법 (0) | 2026.09.22 |
| FinOps(핀옵스) 시작하는 법 (2026) — AI 예산을 73%가 초과한 해, 도구 사기 전에 해야 할 일 (0) | 2026.09.14 |
| AWS 비용 계산기(Pricing Calculator) 제대로 쓰는 법 (2026) — 견적이 실제 청구서와 어긋나는 5가지 이유 (0) | 2026.09.11 |
| gp2 → gp3 전환 (2026) — 볼륨 1TB면 월 $20, 무중단으로 EBS 비용 20% 줄이는 법 (0) | 2026.09.10 |
댓글