2007~2009년 Google에서 데이터센터를 크게 늘리던 시절, 특히 업무 외 시간에는 유휴 용량이 많았음
엔지니어라면 누구나 우선순위 0으로 원하는 만큼 작업을 돌릴 수 있었고, 더 중요한 작업이 자원을 필요로 하면 가장 먼저 죽는 방식이었음
밤새 도는 MapReduce 실험을 많이 했고, 한동안은 내부 서비스를 우선순위 0으로 돌려 사실상 “공짜”처럼 운영하기도 했음
사용량이 늘면서 그런 서비스는 점점 불안정해졌고, 결국 자원 사용을 정당화하거나 규모를 줄여야 했지만 그건 좋은 방향이었다고 봄
AI 토큰 사용도 비슷한 모델이 좋을 듯함. 대형 기술 기업은 자체 LLM 데이터센터를 두고 내부 수요를 처리한 뒤, 업무 외 유휴 용량은 직원 실험에 열어줄 수 있음
일상 업무에서는 토큰 수 자체보다 토큰 효율을 장려해야 함. 사람 노동 몇 시간을 매주 줄이는 자동화에 토큰을 많이 쓰는 건 좋은 사용이고, 손으로 고칠 수 있는 쉬운 프런트엔드 버그를 디버깅하느라 토큰을 많이 쓰고도 4시간 걸리는 건 낭비임

LLM 사용자들이 그렇게 논리적으로 굴 것 같지는 않음. 꽤 많은 사용자가 사소한 작업마다 Opus를 던져야 한다고 고집하는 듯함

대부분의 AI 프런트엔드는 대화형 작업에 맞춰져 있어서, 언젠가 처리되면 되는 우선순위 0 작업을 정의하기 어렵게 만듦
명세 기반 개발처럼 사람이 루프 안에 계속 들어가는 게 아니라 루프 위에서 확인하는 방식에는 이 접근이 훨씬 자연스러운데, 적어도 Google 프런트엔드 경험상 아직 잘 지원되는 곳을 보지 못함

쉬운 프런트엔드 버그에 토큰을 많이 쓰고도 4시간 걸리는 걸 막으라니, 쉽지 않을 것 같음
지금 벌어지는 일은 많은 사람에게 아주 뻔했음. 일부러 중독되길 바라며 만든 새 중독자에게 “조금 더 신중하게 소비하라”고 말하는 꼴이라 잘 안 먹힐 가능성이 큼

결국 모두가 10배 싼 중국 모델을 받아들이는 쪽이 더 그럴듯하지 않나 싶음

AI 쓰는 걸 좋아하지 않고, 별로 도움이 된다고 느끼지도 않음
그런데 회사가 사용을 강요하고 지표를 추적하니 매일 의미 없는 잡일을 던져서 사용한 것처럼 보이게 함
문제를 고치는 것보다 더 많이 만들더라도, 지표상으로는 AI를 쓰는 사람이 됨

어떤 회사든 토큰 소비량을 직원 성과 신호로 쓴다고 발표하면, 그 회사는 피해야 할 적신호에 가깝다고 봄
좋은 엔지니어링 리더십을 가진 회사라면 이걸 괜찮은 아이디어처럼 다뤄서는 안 됨

출장 식비 한도를 100달러 넘기면 매니저나 재무팀과 불편한 대화를 해야 함
그런데 AI 토큰 500달러를 비생산적으로 쓰면 최상위 AI 도입자로 인정받는다는 점을 회사에서 비꼬듯 말하곤 함

놀랄 수도 있겠지만, FAANG은 아니어도 누구나 아는 대형 기술 회사 개발자 몇 명을 알고 있는데 모두 어떤 형태로든 토큰 순위표가 있음
어떤 회사는 개발자에게 “이제 코드 한 줄도 직접 쓰지 않았으면 한다”고까지 말함
임원 관점은 아마 이럴 것 같음. 상위 20% 직원이 LLM으로 코드의 80%를 만들고 회사가 여전히 굴러가면, 하위 80% 개발자를 줄여 비용을 아낄 수 있다는 식임

과거에는 합리적인 리더십을 갖고 있던 회사들도 LLM AI가 등장한 뒤 서두르고 의심스러운 결정을 내리기 시작함
직원 성과 평가에 토큰 사용량을 쓰는 건 그중 하나일 뿐임

토큰은 새로운 엔지니어당 코드 줄 수임. 그래프로 그리기 쉽고 “관리”하기도 쉬움

Meta가 이걸 함. 최근 해고 기준 중 하나가 무엇이었을지 짐작해보면 됨

하늘의 거대한 핵융합로 아래 완전히 새로운 건 별로 없음
James Gleick의 “The Information”에서 전신 산업의 토큰맥싱 같은 내용을 읽었음
전보는 문자당 요금을 받았기 때문에, 전송 문자를 줄이는 코드북 시장이 컸음. 압축은 곧 돈이었고, 전신 회사들은 이를 싫어했지만 받아들일 수밖에 없었음
전신 코드 산업은 전신 상용화 초기부터 시작해 1920년대까지 이어졌음
다만 비용도 있었음. 코드는 중복성을 크게 줄였고, 아주 작은 오류가 큰 오해로 이어졌음
Gleick의 설명처럼 이는 아프리카 북 연주가 리듬과 북이 흉내 내는 언어 사이의 관계를 강화하려고 중복성을 더하는 방식과 정반대였음

그건 토큰맥싱과 정확히 반대 아닌가? 전신 비유라면 전신기사가 고객 처리량이 아니라 하루에 전신선을 얼마나 오래 점유했는지로 평가받는 상황이어야 함
즉 태운 토큰 수나 비용이 가장 큰 사람이 이기는 식이지, 기능을 납품한 프로그래머 기준이 아님
설명한 건 토큰 최대화가 아니라 토큰 최소화에 가까움

흥미롭지만 토큰맥싱은 토큰 사용 효율을 극대화하는 게 아니라, 사용량 자체를 극대화하는 것임

설명한 건 사실상 토큰맥싱의 반대임

LLM 이전부터 소프트웨어 스택에 대해 늘 궁금했던 점인데, 지금은 더 관련 있어 보임
Uber 같은 회사는 언제 “완성”될까? 16년 동안 소프트웨어를 만들어왔음
운전자와 승객을 매칭하는 회사고, 소프트웨어를 더 만든다고 내가 버스나 기차 대신 Uber를 찾을 가능성이 크게 늘지는 않음
20년 뒤면 소프트웨어가 끝날까? 80년 뒤일까?

코드베이스 대부분은 지역 시장별 맞춤 연동임. 일부는 체계화할 수 있지만, 복잡성의 대부분은 거기서 나옴

브라우저, Android, iOS가 16년 넘게 멈춰 있으면 좀 쉬워질지도 모름
바뀌는 규제 환경과 새 제품도 빼놓을 수 없음. Uber Eats가 언제 나왔는지만 봐도 됨
그 16년 동안 Covid-19가 등장했고, 실용적인 자율주행과 Waymo와의 제휴도 생겼음
네트워크로 연결된 대중 대상 앱은 완벽한 예지력이 없는 한 절대 “완성”될 수 없음
내부 기술 스택은 살아 있는 생물 같고, 겉보기에는 변하지 않는 서비스를 유지하는 데도 일이 아주 많음. 확장도 큰일이고, 확장과 유지보수는 서로를 계속 키움

국제 운영과 최적화가 얼마나 복잡한지 놓치고 있는 듯함
각 국가는 Uber가 할 수 있는 일과 없는 일에 대해 저마다 법이 있고, 이를 코드로 형식화해야 함
예를 들어 어떤 곳에서는 Uber 앱을 통해 실제로는 택시를 부르고, 요금도 사전 확정 금액이 아니라 마일당 계산일 수 있음
여기에 도시별 법까지 더해짐. 법이 다른 A 마을에서 B 마을로 Uber를 타고 가면 어떻게 해야 할까? 변호사는 답을 알겠지만 앱은 그걸 지켜야 함
게다가 법은 계속 바뀜
최적화도 끝이 없음. 속도, 비용, 경로 등 언제나 개선할 대상이 있음
소비자로서 접하는 부분은 그런 서비스가 만들고 운영해야 하는 복잡성의 아주 작은 조각이라고 봄

구현해야 할 새 기술과 기법은 항상 있음. 더 나은 알고리즘, 더 큰 배포, 더 높은 신뢰성도 필요함
거의 언제나 고쳐야 할 버그도 있음. 정말 많은 버그가 있음

Uber가 자체 자율주행도 하려고 하지 않았나?
막대한 투자를 받은 회사의 문제이기도 함. Uber의 가치는 지금 하는 일 자체보다, 자가용 소유나 대중교통 이용 같은 개념을 낡은 것으로 만들 거라는 기대에 기반함
과장이긴 하지만, 그래도 생각보다 덜 과장된 말임

토큰맥싱은 말이 안 됨. 가능한 한 많은 연산, 메모리, 입출력을 쓰려고 비효율적인 SQL/Spark 작업을 짜는 것과 비슷함
데카르트 곱, 극단적으로 치우친 데이터셋 같은 걸 일부러 잔뜩 넣는 꼴임
지표가 목표가 되면 항상 이런 일이 벌어짐. 회사는 AI를 가능한 한 효율적으로 쓰는 환경을 키워야 하고, 먼저 “이 일에 정말 에이전트가 필요한가”를 물어야 함
필요하다면 어떤 에이전트, 어떤 모델, 어떤 추론 수준이 필요한지 정해야 함
토큰 절약, 캐시 적중률 증가, 더 적은 문맥으로 정보를 쓸 수 있게 만드는 정보 구조화도 장려해야 함. 지식 그래프는 여기에 꽤 좋음

유아 수준의 논리임. “X를 쓰면 좋은 결과가 나올 수 있다. 그러니 좋은 결과를 최대화하려면 X를 최대한 많이 써야 한다”는 식임
경주에서 이기려고 주유소에 불을 지르는 것과 비슷함

토큰맥싱이 존재하는 이유는 임원들이 직원들이 변화에 저항한다고 생각하기 때문임
모든 직원이 새 기술을 실험하도록 유도하거나 강제하는 방식일 뿐임
모두가 AI를 활용한다고 판단하면 토큰맥싱 같은 건 당연히 끝날 것임

토큰맥싱을 옹호하는 논리는 보통 직원들이 AI 기반 업무 흐름이라는 넓고 새로운 공간을 자유롭게 탐색할 여지를 만든다는 것임
가치가 만들어지는지 의심스러운 사용 사례도 많이 봤지만, 비용 검토 위원회 앞에서는 정당화하기 어려웠을 에이전트형 업무 흐름으로 오래된 문제를 해결한 팀들도 봤음
토큰 절약, 캐시 적중률 증가, 적은 문맥 사용을 위한 정보 구조화 작업은 큰 토큰맥싱 회사들 대부분이 뒤에서 따로 팀을 두고 하는 것으로 이해하고 있음

회사들이 AI 보조 개발에 돈을 태우는 건 알겠음. 그런데 전체 투자수익률은 어떨까? 주장하는 효율 향상만큼 가치가 있었나?
AI 열풍에서 실제로 흥미로운 지점은 이것뿐인데 왜 아무도 이야기하지 않는지 모르겠음

제대로 측정할 줄 아는 사람이 많지 않아서라고 봄
Claude로 하루에 쓸모없거나 나쁜 기능 5개를 만들 수도 있고, 이틀에 유용한 기능 1개를 만들 수도 있음. 어느 쪽이 투자수익률에 더 나은 영향을 줄까?
예시만 보면 쉬운 답처럼 보이지만, 현실에서는 훨씬 미묘하고 측정도 훨씬 어려움
그래서 많은 회사가 측정을 포기하고 과대광고를 따라가는 단순한 선택을 하는 듯함

코드 리뷰까지 포함해 제대로 운용할 때 AI 사용으로 지속 가능한 최대 향상 폭은, 적절한 숙련도를 가진 시니어 엔지니어 기준으로 대략 20% 라고 확신함
어떤 엔지니어의 토큰 예산도 그 이상을 넘지 않아야 함
토큰맥싱을 하는 엔지니어가 정말 생산적이라고 믿지 않고, 그런 증거도 전혀 보지 못했음. 오히려 반대에 가까울 수 있음
올바른 흐름과 코드베이스 지식이 있으면, 지속 가능한 노력 수준으로 그 정도는 가능하다고 직접 느꼈음

엔지니어링 생산성을 위한 AI가, 같은 결과를 더 빠르고 싸게 내는 마법 버튼으로 널리 오해되는 듯함
그런 논리라면 직원에게 토큰맥싱을 강제하고 싶어지는 것도 당연함. 더 많은 결과를 더 빠르고 싸게 얻을 수 있는데 왜 안 하겠나?
더 미묘하게 보면 이렇음. AI는 로드맵을 어느 정도 더 빨리 달성하게 해주지만, 임시 개발자를 고용해 기능을 만든 것과 비슷한 기술 부채가 생김
팀 안에 새 코드를 이해하는 사람이 꼭 생기는 것도 아님
마찬가지로 주니어 팀원의 숙련도 향상도 덜 일어남. 예전만큼 숙련도와 임금 차이의 차익을 얻기 어려움
제품도 복잡해질 수 있음. P2 기능이 P2인 데는 이유가 있는데, AI 때문에 낮은 한계 이익의 기능까지 포함되어 제품을 복잡하게 만들 수 있음

토큰맥싱이 좋은 생각이라고 믿은 사람이 있었다는 게 충격적임
AI 극대주의자들은 이 기술을 전기에 비유하곤 함. 전기화 초기에 CEO가 직원들에게 사업 성과를 내는 전기 활용법을 찾기보다 전기 소비량 증가를 보상했다고 상상해보면 됨
그 시절에는 정신질환 징후를 보이는 사람을 시설에 수용하는 일이 흔했고, 아마 그런 결말이었을 것 같음