개요

마이크로소프트 CEO 사티아 나델라가 흥미로운 자기 고백을 했습니다. 팟캐스트 Hard Fork 인터뷰에서 그는 “토큰 맥싱(token-maxing)” — 모든 문제에 가장 비싼 프런티어 모델을 들이미는 습관 — 을 경계했습니다. 그러면서 곧바로 한마디 덧붙입니다. “나도 토큰 맥서 같다. 중독성이 있다.”

업계 1인자의 자기 비판처럼 들리지만, 자세히 들여다보면 그림이 더 복잡합니다. 같은 인터뷰에서 그는 또 다른 그림을 그리거든요. 앞으로 개발자는 코드를 직접 쓰지 않고 수백, 수천 개의 AI 에이전트를 지휘하게 될 거라는 얘기입니다. 토큰을 어마어마하게 태우는 시나리오죠. 한쪽에선 “그만 좀 태우자”, 다른 쪽에선 “이렇게 태우자” — 이 모순이 사실 이번 발언의 핵심입니다.

핵심 요약

  • 토큰 맥싱 경고 — 모든 작업에 가장 강한 모델을 무지성으로 쓰는 풍조를 나델라가 직접 비판했습니다. 이유는 단순합니다. “생산성 향상의 한계 비용이 토큰의 한계 비용을 따라잡지 못하면 경제가 안 굴러간다"는 겁니다.
  • 본인도 중독 — 그러면서 “나도 토큰 맥서 같다. 중독성이 있다"고 인정합니다. 가장 강한 모델을 쓰는 손맛을 한 번 보면 손이 잘 떨어지지 않는다는 얘기입니다.
  • 개발자 패러다임 전환 — 그러면서도 같은 자리에서 ‘코드는 에이전트가 쓰고, 사람은 그걸 이해한다’는 새 그림을 제시합니다. 한쪽에서는 절약을, 다른 쪽에서는 대규모 소비를 동시에 말한 셈입니다.
  • 인지 커버리지(cognitive coverage) — 그가 새로 던진 핵심 단어입니다. 에이전트가 짠 코드를 사람이 얼마나 깊이 따라잡고 있느냐, 그 비율이 새로운 개발자 역량이라는 주장입니다.
  • 컴공 전공은 여전히 필요 — 사람이 직접 키보드를 두드릴 일은 줄어도, 코드를 읽고 검증할 능력은 더 중요해진다는 입장을 분명히 했습니다.

“토큰 한계 비용 = 생산성 한계 비용” — 진짜로 말한 의미

나델라가 인터뷰에서 던진 첫 문장은 사실상 경제학 명제입니다.

“생산성 향상의 한계 비용이 토큰의 한계 비용과 맞아떨어져야 한다는 게 냉정한 진실이다.”

말이 좀 어렵지만 풀면 단순합니다. 어떤 작업에 강한 모델을 호출해 토큰 1만 개를 태웠다고 칩시다. 그래서 그 작업이 사람이 했을 때보다 얼마나 더 값어치 있게 끝났는지 — 그 차이가 토큰값보다 작으면 그 호출은 밑지는 장사입니다. 산업 전체가 이렇게 밑지는 호출을 누적하고 있으면, 아무리 생성형 AI 매출이 늘어도 매크로 단위 ‘경제 성장’으로는 잘 안 보인다는 얘기입니다.

여기에 그가 직접 꼭 집은 표현이 있습니다. “프런티어 모델을 일상 업무에 흩뿌리지 말라.” 회의록 요약, 짧은 이메일 답장, 슬랙 메시지 정리 같은 데에 Opus 4 / GPT-5 급을 들이미는 게 가장 흔한 낭비라는 거죠.

그런데 그가 같은 인터뷰에서 “나도 멈추기 힘들다"고 토로한 부분이 압권입니다. 본인의 손이 자꾸 가장 비싼 모델 쪽으로 간다는 자기 고백 — 이 한 줄이 사실 모든 직장인의 사정과 정확히 겹칩니다. 한국 개발자 단톡방에도 같은 얘기가 돌죠. “그냥 Opus 박는다”, “어차피 회사가 낸다”, “맞을 확률이 한 끗이라도 높으면 이긴다.”

이게 바로 그가 말한 중독의 정체입니다. 이성적 비용 계산이 아니라, ‘혹시’를 향한 손맛.

‘코드는 에이전트가, 사람은 인지 커버리지’

그런데 같은 인터뷰에서 나델라는 정반대로 보이는 그림을 또 하나 펼칩니다. 미래의 개발자는 더 이상 손으로 코드를 쓰지 않을 거라는 얘기입니다. 대신 수백~수천 개의 AI 에이전트를 동시에 굴리며, 그 에이전트들이 짜낸 코드를 검토·이해·승인하게 된다는 그림입니다. 토큰을 어마어마하게 태우는 시나리오죠.

여기서 그가 새로 던진 단어가 **‘인지 커버리지(cognitive coverage)’**입니다. 직역하면 ‘인지적 적용 범위’ 정도인데, 그가 쓴 뉘앙스는 분명합니다.

“에이전트들이 쓴 코드로 가득한 레포가 있다. 나는 그 코드에서 무슨 일이 벌어졌는지를 인지적으로 이해하고 있다.”

테스트 커버리지가 코드의 몇 퍼센트가 테스트에 의해 실행되느냐를 잰다면, 인지 커버리지는 그 코드의 몇 퍼센트를 사람이 머리로 따라잡고 있느냐를 잽니다. 에이전트가 100줄을 짰는데 사람이 30줄만 진짜로 이해하고 나머지는 그냥 ’looks fine’ 하고 통과시켰다면 인지 커버리지 30%인 셈이죠.

개발자 입장에서는 이게 의외로 까다로운 새 KPI입니다. 짠 코드를 모두 짚어보려면 시간이 많이 들고, 에이전트는 그 사이 다음 일감을 또 쏟아냅니다. 결국 ‘얼마나 빠르게 코드를 만드느냐’가 아니라 ‘쏟아지는 코드를 얼마나 안 놓치고 따라잡느냐‘가 핵심 역량이 된다는 얘기입니다.

컴공 교육 vs ‘바이브 코딩’

요즘 자주 듣는 다른 주장과도 묘하게 부딪힙니다. “AI가 다 해주니까 이제 컴공 안 배워도 된다”, 흔히 말하는 바이브 코딩(vibe coding) 류 얘기죠. 나델라는 여기에 분명한 입장을 그었습니다.

“사람이 직접 타자치는 일은 줄겠지만, 컴퓨터 과학 교육은 여전히 필요하다. 다만 일의 형태가 크게 바뀔 것이다.”

이유는 위와 그대로 이어집니다. 인지 커버리지를 유지하려면, 사람이 그 코드를 ‘읽을 수 있어야’ 합니다. 자료 구조, 시간 복잡도, 분산 시스템의 기본기, 동시성 제어 같은 걸 모르면 에이전트가 짜준 코드가 어디서 터질지를 모릅니다. 즉, 타이핑 능력은 사라지지만, 읽는 능력·검증 능력은 더 중요해진다는 그림입니다.

실무자가 볼 핵심 포인트

  • 모델은 작업 난이도로 골라라. 회의록 요약·짧은 답장에는 Haiku/소형 모델. 시스템 설계·복잡한 디버깅·다단 추론에만 프런티어 모델. 손이 자동으로 가장 비싼 모델로 간다면, 이미 나델라가 말한 그 ‘중독’ 상태입니다.
  • ‘인지 커버리지’를 PR 리뷰에 그대로 적용하라. 에이전트가 만든 PR을 머지하기 전에 “내가 이 변경의 모든 분기를 직접 설명할 수 있는가"를 자문하세요. 못한다면 그 부분은 아직 인지 커버리지 0%입니다.
  • 테스트 커버리지와 인지 커버리지는 다른 축. 테스트가 90%여도 사람이 코드 의도를 모르면, 운영 중에 처음 보는 사이드이펙트가 나옵니다. 두 지표를 따로 추적하세요.
  • ‘에이전트 오케스트레이터’ 역할이 일찍 굳어진다. 한 사람이 수십 개의 백그라운드 에이전트를 굴리는 워크플로(예: Codex CLI 멀티 세션, Claude Code 백그라운드 작업)는 1~2년 안에 표준이 됩니다. 지금부터 큐 관리·diff 리뷰·작업 분할 감각을 길러두는 게 유리합니다.
  • 컴공 기초는 더 중요해진다. 자료 구조·OS·네트워크·DB 기본기는 에이전트 코드를 검증하는 ‘진단 도구’가 됩니다. AI가 짜놓은 메모리 누수, 잘못된 인덱스, 어색한 락 패턴 — 이걸 잡아내는 건 결국 사람의 기본기입니다.

한 문장 정리

나델라의 메시지는 한 문장으로 줄일 수 있습니다. “비싼 모델은 함부로 쓰지 마라. 단, 어차피 쏟아지는 에이전트 코드는 네가 머리로 따라잡고 있어야 한다.” 절약과 폭발적 소비를 같은 자리에서 말한 이유가 여기에 있습니다. 청구서 관점에서는 두 메시지가 충돌하지만, 사람의 역량 관점에서는 같은 그림입니다 — 손은 쉬고, 머리는 더 바삐 돈다.

원문 출처