회사들이 직원이 AI를 얼마나 쓰는지 재기 시작했습니다. 메타는 Checkpoint라는 성과 추적기로 엔지니어가 AI로 짠 코드와 직접 짠 코드의 비율까지 봅니다. 코인베이스는 AI가 작성한 코드 비율을 33%에서 50%까지 올리겠다는 목표를 세웠고, 도입에 응하지 않은 엔지니어를 해고했습니다. 마이크로소프트는 AI 사용 시간을 인사평가에 넣으라고 매니저들에게 지시했습니다.
이런 측정을 보는 시선은 대체로 곱지 않습니다. 얼마나 많이 썼는지로 사람을 평가하는 건 예전에 이미 실패한 방식이기 때문입니다.
코드 줄 수를 재던 시절
예전에 개발자의 생산성을 코드 줄 수(lines of code, 이하 LOC)로 쟀습니다. 많이 짜면 일을 많이 한 것으로 봤습니다. IBM을 비롯한 회사들이 이 방식으로 개발자를 평가했습니다.
결과는 반대로 나왔습니다. 줄 수가 점수가 되자, 사람들은 짧게 끝낼 일도 길게 늘여 썼습니다. 애플의 빌 앳킨슨은 그래픽 코드를 다시 짜서 여섯 배 가까이 빠르게 만들면서 2천 줄을 걷어냈는데, 회사가 주간 보고서에 "작성한 코드 줄 수"를 적으라고 하자 거기에 -2000이라고 적었습니다. 좋은 일을 했는데 장부로는 마이너스였습니다. 빌 게이츠는 "코드 줄 수로 프로그래밍 진척을 재는 것은 무게로 항공기 제작 진척을 재는 것과 같다"고 했고, 다익스트라는 그렇게 재면 맹탕 같은 코드를 쓰도록 부추긴다고 지적했습니다.
이걸 굿하트의 법칙(Goodhart's law)이 한 줄로 정리합니다. 측정이 목표가 되는 순간, 그 측정은 좋은 척도이길 멈춥니다. 토큰 사용량을 재는 것도 같은 실수처럼 보입니다. 투입을 재면 투입을 부풀릴 테니까요.
그런데 AI는 그때와 다르다
여기서 저는 되묻고 싶습니다. 토큰을 재는 게 정말 그때 LOC와 같은 상황인지입니다.
LOC를 재던 시절, 코딩은 이미 성숙한 일이었습니다. 무엇이 좋은 코드인지 다들 알았고, 줄 수는 그 가치와 무관했습니다. AI는 다릅니다. 아직 아무도 이걸 어떻게 써야 제일 좋은지 모릅니다.
조직학습을 연구한 제임스 마치는 1991년에, 사람과 조직이 자원을 탐색(exploration)과 활용(exploitation)에 나눠 쓴다고 정리했습니다. 탐색은 새로운 걸 시도해 보는 쪽, 활용은 아는 걸 다듬어 효율을 짜내는 쪽입니다. 어느 슬롯머신이 좋은지 모를 때 여러 개를 당겨보는 게 탐색이고, 제일 좋았던 하나만 당기는 게 활용입니다.
잘 쓰려면 더 써야 한다
마치는 사람이 구조적으로 활용 쪽에 너무 일찍 기운다고 경고했습니다. 활용의 보상은 가깝고 눈에 보이지만, 탐색의 보상은 멀고 흐릿하기 때문입니다.
제 생각에 지금 AI는 활용의 단계가 아니라 탐색의 단계입니다. 사람들은 토큰을 잘 활용하지 못한다고, 낭비한다고 말합니다. 그런데 잘 활용하려면 더 많이 탐색해야 하고, 더 많은 탐색은 더 많은 토큰을 뜻합니다. 지금 토큰을 많이 쓰는 것이 곧 잘 쓰는 법을 찾아가는 과정입니다. 효율은 탐색이 끝난 뒤에 오는 것이지, 앞당겨 요구할 수 있는 게 아닙니다.
비용이 가짜라는 말은 아닙니다. 토큰은 공짜가 아니고, 규모가 커지면 청구서도 무겁습니다. 다만 토큰 값은 빠르게 떨어지고 있습니다. 곧 싸질 것을 아끼느라 지금만 살 수 있는 배움을 미루는 건 손해입니다.
많이 쓴다고 저절로 늘지는 않는다
물론 많이 쓴다고 실력이 저절로 늘지는 않습니다. 탐색이 곧 배움은 아니기 때문입니다. 실력은 반복이 아니라 되돌아보는 반복에서 자랍니다. 저는 예전에 취향은 삽질로 자란다고 쓴 적이 있습니다. 많이 만들어 보고 왜 망했는지 들여다본 사람만 무엇이 좋은지 가려내는 눈이 생긴다는 이야기였습니다. 생각 없이 떠넘기기만 하면 오히려 판단이 무뎌집니다. 사용량은 탐색하고 있다는 신호까지입니다. 거기서 배우는 건 각자의 몫입니다.
마치며
지금은 탐색 단계입니다. 토큰 사용량은 재도 됩니다. 오히려 지금은 봐야 할 숫자이고, 끌어올릴 숫자입니다. 최적화는 그다음입니다. 켄트 벡은 좋은 코드의 순서를 돌아가게, 바르게, 그다음 빠르게라고 정리했습니다. 우리는 아직 첫 단계에 있습니다.