Back to Blog
| 46

많이 쓰는 사람만이 배우는 것들

많이 쓰는 사람만이 배우는 것들

AI 시대에 토큰을 많이 쓰는 사람을 낮게 평가할 이유는 없다


AI 코딩 에이전트를 얼마나 쓰는가.

나는 이것이 앞으로 개발자와 데이터 엔지니어, 자동화 담당자, 기획자, 분석가의 역량을 판단하는 데 꽤 유효한 지표가 된다고 생각한다.

단, 오해하지 않았으면 한다.

토큰 사용량이 곧 실력이라는 뜻은 아니다. 다만 토큰을 거의 쓰지 않는 사람이 AI 시대에 충분히 실험하고 있다고 보기도 어렵다.

이 둘은 완전히 다른 말이다.


토큰은 낭비가 아니라 사고 과정의 흔적이다


많은 사람들이 AI 토큰 사용량을 단순한 비용으로 본다.

"많이 쓰면 낭비 아닌가?" "결과물이 같다면 적게 쓰는 사람이 더 효율적인 것 아닌가?" "토큰 많이 썼다고 일을 잘했다는 증거가 되나?"

겉으로 보면 맞는 말처럼 들린다.

실제로 AI 코딩 에이전트를 많이 써본 사람이라면 안다. 토큰은 단순한 입력량이 아니다.

토큰은 다음과 같은 것들의 기록이다.

문제를 얼마나 다양한 방식으로 쪼개봤는지. 컨텍스트를 얼마나 정교하게 제공했는지. 실패한 접근을 얼마나 빨리 버렸는지. 테스트, 로그, 에러 메시지, 문서, 코드베이스를 얼마나 반복적으로 검증했는지. 사람 혼자라면 미뤘을 탐색을 얼마나 많이 수행했는지.

토큰 사용량은 "얼마나 AI를 불렀는가"의 숫자이기도 하지만, 동시에 "얼마나 많은 가설을 세우고, 실패하고, 수정하고, 검증했는가"의 흔적이기도 하다.

나는 이 차이가 중요하다고 본다.


"결과물이 같다면 토큰을 적게 쓴 사람이 효율적이다"라는 말의 함정


반대 입장에서 가장 자주 나오는 논리는 이것이다.

"결과물이 같다면 토큰을 적게 쓴 사람이 더 효율적인 것 아닌가?"

일부 상황에서는 맞다.

이미 답을 알고 있고, 요구사항도 명확하고, 구현 방법도 검증되어 있고, 단순 반복 작업이라면 적은 토큰으로 끝내는 사람이 효율적일 수 있다.

현실의 일은 대개 그렇지 않다.

특히 코딩 에이전트를 쓰는 업무는 단순히 코드를 생성하는 일이 아니다. 모호한 요구사항을 정리하고, 기존 시스템의 맥락을 파악하고, 장애 가능성을 줄이고, 배포 후 영향을 예측하고, 숨은 엣지 케이스를 찾는 과정이다.

여기서는 최종 결과물만 보면 보이지 않는 탐색 비용이 존재한다.

토큰을 적게 썼다는 것이 항상 효율을 뜻하지 않는다. 가끔은 충분히 검토하지 않았다는 뜻일 수도 있다. 충분히 비교하지 않았다는 뜻일 수도 있다. 실패할 수 있는 경로를 미리 밟아보지 않았다는 뜻일 수도 있다.

반대로 토큰을 많이 썼다는 것이 항상 낭비도 아니다. 많이 실패해봤고, 많이 물어봤고, 많이 검증했고, 많이 되돌아갔다는 뜻일 수 있다.

AI 시대의 효율은 단순히 "최종 산출물까지 토큰을 얼마나 적게 썼는가"로 측정할 수 없다.

더 중요한 질문은 이것이다.

그 토큰으로 사람이 혼자서는 하지 않았을 검증과 탐색을 했는가? 그 과정이 다음 작업의 속도와 품질을 높였는가? 실패가 재사용 가능한 지식으로 남았는가?

나는 이것이 진짜 효율이라고 본다.


토큰 사용량은 역량의 결과가 아니라 역량의 선행지표다


토큰 사용량을 평가 지표로 쓰는 것에 반대하는 사람들은 보통 이렇게 말한다.

"토큰은 input metric이다. output이 아니다."

맞다. 토큰은 결과물이 아니다.

그래서 무의미하다는 결론은 틀렸다.

실무에서 중요한 지표는 항상 output만으로 구성되지 않는다. 좋은 조직은 결과 지표와 선행 지표를 함께 본다.

매출만 보는 회사는 늦게 움직인다. 장애 건수만 보는 인프라팀은 이미 장애가 난 뒤에야 움직인다. 배포 성공률만 보는 팀은 개발 과정의 병목을 놓친다.

마찬가지로 AI 활용 역량도 결과물만 보면 늦다.

이미 좋은 결과물이 나온 뒤에는 누가 AI를 잘 활용했는지, 누가 우연히 성공했는지, 누가 재현 가능한 방식을 만들었는지 구분하기 어렵다.

토큰 사용량은 그런 면에서 선행지표다.

AI를 얼마나 자주 업무 흐름에 넣는지. 반복 가능한 프롬프트 패턴을 만들고 있는지. 코드 리뷰, 테스트 생성, 문서화, 리팩토링, 장애 분석, 비용 최적화에 AI를 실제로 붙이고 있는지. 혼자 일하는 사람이 아니라 여러 개의 에이전트를 지휘하는 방식으로 일하고 있는지.

이런 것들은 결과물이 나오기 전부터 관찰할 수 있다.

그래서 토큰 사용량은 단독 평가 지표로는 부족하지만, AI 시대의 업무 적응력과 실험량을 보여주는 유효한 보조지표가 된다.


"토큰 사용량은 조작 가능하다"는 반론에 대해


또 다른 반론은 이것이다.

"사람들이 평가받으려고 일부러 토큰을 많이 쓰면 어떡하나?"

당연히 가능하다.

AI 에이전트를 무의미하게 돌려놓거나, 같은 질문을 반복하거나, 실제 산출물 없이 사용량만 부풀리는 사람은 생길 수 있다.

이 반론은 너무 쉬운 반론이다.

똑똑한 사람들이 토큰 사용량을 보자고 말할 때, 그런 악용 가능성을 몰라서 말하는 것이 아니다. 오히려 그런 가능성을 알기 때문에 토큰 사용량만 보자는 것이 아니라, 토큰 사용량과 산출물을 함께 보자는 것이다.

모든 지표는 조작 가능하다.

커밋 수도 조작 가능하다. 코드 라인 수도 조작 가능하다. 회의 참석 횟수도 조작 가능하다. 업무 시간도 조작 가능하다. 티켓 처리 개수도 조작 가능하다.

그렇다고 아무것도 측정하지 않는가? 아니다.

좋은 평가는 하나의 숫자에 사람을 가두지 않는다. 여러 지표를 묶어서 본다.

토큰 사용량도 마찬가지다.

토큰 사용량만 보면 위험하다. 토큰 사용량을 아예 보지 않으면 더 위험하다.

AI를 전혀 쓰지 않는 사람과, AI를 깊게 써서 실패와 검증을 반복하는 사람을 구분할 수 없기 때문이다.


"많이 쓰는 사람"과 "잘 쓰는 사람"은 다르다. 잘 쓰려면 많이 써봐야 한다


나는 토큰을 많이 쓰는 사람이 무조건 뛰어나다고 말하고 싶지 않다.

많이 쓰고도 엉망으로 쓰는 사람은 있다. 질문을 던질 줄 모르고, 검증하지 않고, 결과를 그대로 믿고, 컨텍스트를 관리하지 못하는 사람도 있다.

반대로 말해야 한다.

적게 쓰면서 잘 쓰는 사람은 매우 드물다.

악기를 잘 치려면 많이 연주해야 한다. 운전을 잘하려면 많이 몰아봐야 한다. SQL을 잘하려면 쿼리를 많이 깨뜨려봐야 한다. Terraform을 잘하려면 플랜과 어플라이의 실패를 겪어봐야 한다. Airflow를 잘하려면 DAG가 깨지고, 스케줄이 꼬이고, 재시도 정책이 실패하는 경험을 해봐야 한다.

AI도 다르지 않다.

좋은 프롬프트는 머리로만 만들어지지 않는다. 좋은 에이전트 워크플로우는 한 번에 나오지 않는다. 좋은 자동화는 실패 로그를 많이 보고, 잘못된 출력을 많이 고치고, 쓸모없는 시도를 많이 버리는 과정에서 나온다.

나는 많이 써본 결과, 실패하는 양 자체가 중요하다고 느꼈다.

토큰을 많이 쓴다는 것은 단순히 AI에게 일을 떠넘기는 것이 아니다. 제대로 쓰는 사람에게는 그것이 실패를 압축해서 경험하는 방식이다.


실제 기업들도 이미 AI 사용량을 보고 있다


개인의 감상이 아니다.

최근 기업들은 AI 사용량을 점점 더 가시화하고 있다. Disney는 내부 AI Adoption Dashboard를 통해 Claude와 Cursor 사용자의 요청 수, 토큰 사용량, 활성 사용자 등을 추적한 것으로 보도되었다. 한 직원은 9근무일 동안 Claude를 약 46만 번 호출했고, Disney/ESPN의 약 4,800명 제품·기술 직원들이 같은 기간 Claude 31억 토큰, Cursor 133억 토큰을 사용했다는 보도도 있었다.

스타트업 업계에서도 일부 회사들은 엔지니어에게 AI 토큰 사용 목표를 두고 있으며, 이를 생산성 향상과 경쟁력 확보의 수단으로 본다. 동시에 비용 낭비와 지표 게임화를 우려하는 반대 의견도 존재한다.

Accenture도 AI 사용을 승진 요건과 연결하는 흐름을 보였고, Microsoft Copilot을 약 743,000명 규모로 확대 배포한다는 보도도 나왔다. AI 사용 여부가 단순한 개인 취향이 아니라 조직의 업무 방식과 평가 기준에 들어오고 있다는 신호다.

Nvidia의 Jensen Huang은 고연봉 엔지니어가 충분한 AI 토큰을 쓰지 않는다면 우려할 만하다는 취지의 발언을 하며, AI 토큰을 현대 엔지니어의 생산 도구로 봐야 한다는 관점을 제시했다.

이 사례들이 곧바로 "토큰을 많이 쓰면 무조건 고성과자"라는 뜻은 아니다. 최소한 업계의 방향은 분명하다.

AI를 얼마나, 어떻게, 어디에 쓰는지는 앞으로 점점 더 중요한 업무 역량으로 취급된다.


반대 근거로 자주 인용되는 연구도 오히려 이 논지를 강화한다


흥미롭게도 AI 코딩 도구가 항상 생산성을 높이는 것은 아니라는 연구도 있다.

METR의 2025년 연구에서는 경험 많은 오픈소스 개발자들이 익숙한 대형 코드베이스에서 AI 도구를 사용할 때, 오히려 작업 시간이 19% 늘어난 것으로 나타났다. 참가자들은 AI가 자신들을 빠르게 만들었다고 느꼈지만, 실제 측정값은 달랐다.

AI 반대론자들은 이 연구를 보고 이렇게 말한다.

"봐라. AI를 많이 써도 느려질 수 있다."

맞다. 여기서 얻어야 할 결론은 "AI를 쓰지 말자"가 아니다.

정확한 결론은 이것이다.

AI를 잘 쓰는 법을 측정하고 훈련해야 한다.

개발자가 AI를 썼다고 느끼는 생산성과 실제 생산성 사이에는 차이가 있을 수 있다. 그러니 사용량, 산출물, 리뷰 시간, 재작업률, 품질, 배포 안정성을 함께 봐야 한다.

토큰 사용량을 보지 말자는 결론은 너무 성급하다. 오히려 반대다.

AI 사용량과 실제 결과를 함께 보아야 누가 AI를 생산적으로 쓰는지, 누가 AI에 끌려다니는지 구분할 수 있다.

한편 GitHub Copilot에 대한 통제 실험에서는 Copilot을 사용한 그룹이 특정 JavaScript HTTP 서버 구현 과제를 55.8% 더 빠르게 완료했다는 결과도 있다.

AI의 효과는 단순하지 않다. 업무 종류, 코드베이스의 복잡도, 사용자의 숙련도, 검증 루틴에 따라 달라진다.

그래서 더더욱 "AI를 쓰는가", "얼마나 쓰는가", "어떤 결과를 냈는가"를 함께 봐야 한다.


토큰을 많이 쓰는 사람은 무엇을 배우는가


AI를 많이 쓰는 사람은 단순히 답변을 많이 받는 사람이 아니다.

제대로 쓰는 사람은 다음을 배운다.

어떤 질문이 좋은 질문인지. 어떤 컨텍스트가 AI의 성능을 끌어올리는지. 어디까지 맡기고 어디서 사람이 개입해야 하는지. AI가 자주 틀리는 지점이 어디인지. 코드 생성보다 테스트와 리뷰에 AI를 쓰는 편이 더 안전한 순간이 언제인지. 단발성 프롬프트보다 반복 가능한 워크플로우가 왜 중요한지. 비용을 줄여야 할 때와 더 써야 할 때를 어떻게 구분하는지.

책이나 강의만으로 얻기 어렵다.

많이 써봐야 한다. 많이 실패해봐야 한다. 많이 버려봐야 한다.

토큰을 많이 썼다는 것은 최소한 그 사람이 AI와 함께 일하는 새로운 방식을 몸으로 익히고 있다는 신호다.


나는 왜 이 말을 할 수 있는가


나는 AI를 많이 쓰는 사람이다.

그리고 그래서 이 말을 할 수 있다고 생각한다.

나는 단순히 재미로 AI를 많이 쓰는 것이 아니다. 내가 해온 일은 콘텐츠 제작, 데이터 분석, 데이터 엔지니어링, DevOps, 인프라 코드화, 배포 자동화, 내부 분석 플랫폼 개선처럼 서로 다른 맥락을 계속 오가는 일이었다.

다양한 도구를 다루면서 느낀 것은 하나다.

현실의 문제는 교과서처럼 오지 않는다.

요구사항은 모호하고, 데이터는 깨져 있고, 권한은 꼬여 있고, 배포 환경은 다르고, 비용은 제한되어 있고, 사람마다 이해도가 다르다.

이런 환경에서 AI는 단순한 코드 생성기가 아니다. 나에게 AI는 두 번째 사고 회로에 가깝다.

내가 놓친 엣지 케이스를 찾게 해준다. 장애 원인을 다른 각도에서 보게 해준다. Terraform 변경의 위험을 미리 점검하게 해준다. Airflow DAG 설계의 병목을 다시 생각하게 해준다. SQL 쿼리의 비용과 성능을 비교하게 해준다. 비기술 동료에게 설명할 문서 구조를 더 명확하게 만든다.

이 과정은 토큰을 쓴다.

그리고 그 토큰은 낭비가 아니었다.

많은 경우 결과물 하나만 보면, 그 과정에서 얼마나 많은 실패와 검토가 있었는지 보이지 않는다. 실제로는 그 실패들이 결과물의 품질을 만든다.

나는 그래서 말하고 싶다.

AI를 많이 쓰는 사람은 단순히 많이 소비하는 사람이 아니다. 제대로 많이 쓰는 사람은 더 많이 실패하고, 더 빨리 배우고, 더 넓게 검증하는 사람이다.


토큰 사용량은 평가의 끝이 아니라 시작이어야 한다


나는 토큰 사용량 하나로 사람을 줄 세우자는 주장에는 동의하지 않는다.

그것은 위험하다. Goodhart의 법칙처럼, 어떤 지표든 목표가 되는 순간 왜곡될 수 있다. 실제로 "측정값이 목표가 되면 좋은 측정값이 아니게 된다"는 문제는 여러 평가 시스템에서 반복적으로 지적되어 왔다.

이 사실이 토큰 사용량을 보지 말아야 한다는 뜻은 아니다.

좋은 평가는 이렇게 가야 한다.

토큰 사용량을 본다. 그 사용량이 어떤 업무에 쓰였는지 본다. 그 결과 어떤 산출물이 나왔는지 본다. 재작업률이 줄었는지 본다. 리뷰 품질이 좋아졌는지 본다. 장애가 줄었는지 본다. 문서화와 지식 공유가 늘었는지 본다. 다음 사람이 재사용할 수 있는 워크플로우가 남았는지 본다.

토큰 사용량은 성과 그 자체가 아니라, 성과를 해석하기 위한 중요한 단서다.


AI 시대의 역량은 "정답을 아는 능력"보다 "많이 실험하는 능력"에 가까워진다


AI 이전의 업무에서는 아는 것이 중요했다. AI 이후의 업무에서는 묻는 것, 나누는 것, 검증하는 것, 실패를 빠르게 회수하는 것이 더 중요해지고 있다.

토큰을 많이 쓰는 사람을 무조건 높게 평가할 필요는 없다. 토큰을 거의 쓰지 않는 사람을 아무 문제 없는 사람처럼 보는 것도 이제는 위험하다.

AI를 많이 써본 사람은 안다.

토큰은 단순한 비용이 아니다. 토큰은 실험량이다. 토큰은 실패량이다. 토큰은 검증량이다. 토큰은 새로운 업무 방식에 몸을 적응시키는 훈련량이다.

최종 결과물까지 적은 토큰을 쓰는 것이 항상 효율적이지는 않다. 때로는 그 과정에서 많이 쓰고, 많이 실패하고, 많이 고쳐본 사람이 더 좋은 판단력을 갖는다.

나는 그래서 AI 토큰 사용량이 사람의 역량을 평가하는 데 유효한 지표가 된다고 본다.

단독 지표가 아니라, 강력한 선행지표로.

그리고 나는 이 말을, AI를 많이 써본 사람의 입장에서 말하고 싶다.

많이 써보지 않은 사람은 AI의 한계도 잘 모른다. 많이 실패해보지 않은 사람은 AI를 어디까지 믿어야 하는지도 모른다. 많이 검증해보지 않은 사람은 AI가 만들어낸 결과물을 책임질 수도 없다.

AI 시대의 진짜 역량은 "적게 쓰는 능력"이 아니라, "많이 실험하고, 많이 실패하고, 결국 더 나은 결과로 수렴시키는 능력"이다.

Related Posts