AI가 코드를 짜는 시대, 언어 선택 기준이 바뀌고 있습니다

“어떤 언어를 배워야 하나요?” 지난 20년간 이 질문의 답은 크게 변하지 않았습니다. 취업이 잘 되는 언어, 라이브러리가 많은 언어, 팀이 쓰는 언어. 그런데 코딩 에이전트가 실제 프로덕션 코드를 짜기 시작하면서 아무도 예상 못 한 변수가 끼어들었습니다. 사람이 읽기 좋은 언어와 모델이 다루기 좋은 언어가 같지 않다는 겁니다.

미리 밝혀두면, 이 주제로 커뮤니티가 시끄러운 단계는 아직 아닙니다. 최근 한 달 레딧을 뒤져도 이 키워드로 볼 만한 스레드가 별로 없었습니다. 다만 실무에서 에이전트를 굴려본 사람들 사이에선 이미 체감되는 문제고, 조만간 제대로 붙을 논쟁이라고 봅니다. 그래서 데이터 몇 개와 구조적인 논리를 붙들고 미리 정리해봤습니다.

토큰은 곧 돈이고, 곧 컨텍스트 예산입니다

에이전트가 코드를 다룰 때 벌어지는 일은 단순합니다. 파일을 읽고, 고치고, 다시 읽습니다. 이 과정에서 나가는 건 전부 토큰입니다. 그리고 토큰은 두 가지 방식으로 비용이 됩니다.

첫째는 말 그대로 청구서입니다. 같은 기능을 짜는 데 A 언어가 B 언어보다 40% 많은 토큰을 쓴다면, 그 프로젝트의 에이전트 운영비는 그만큼 비쌉니다. 둘째가 더 중요합니다. 컨텍스트 윈도우는 유한합니다. 100만 토큰짜리 컨텍스트라도 코드베이스가 장황하면 모델이 한 번에 볼 수 있는 파일 수가 줄어듭니다. 파일 3개를 놓고 같이 판단해야 하는데 1개밖에 못 올린다면, 이건 비용 문제가 아니라 정확도 문제입니다.

여기서 흔한 오해 하나. 토큰 효율은 “코드 줄 수"와 다릅니다. 토크나이저는 문자를 조각으로 쪼갭니다. 영어 단어에 가까운 식별자는 1~2 토큰이지만, 언더스코어로 이어붙인 긴 이름이나 낯선 심볼 조합은 훨씬 잘게 갈립니다. 그래서 줄 수는 짧은데 토큰은 더 먹는 코드가 실제로 있습니다. 기호를 많이 쓰는 언어일수록 이 함정에 빠지기 쉽습니다.

장황함이 항상 나쁜 건 아닙니다

재밌는 건 여기부터입니다. 순수하게 토큰만 따지면 Python이 유리합니다. 문법이 짧고 영어에 가깝고, 학습 데이터에도 비교가 안 될 만큼 많습니다. 모델이 Python을 쓸 때 제일 편해 보이는 건 우연이 아닙니다.

그런데 에이전트가 코드를 쓸 때는 반대 힘이 작용합니다. 에이전트의 진짜 병목은 “코드를 생성하는 것"이 아니라 “자기가 쓴 코드가 맞는지 확인하는 것"입니다. 사람이 짤 땐 머릿속에 맥락이 있으니 어느 정도 감으로 압니다. 에이전트에겐 그 맥락이 없습니다. 컴파일러와 타입 체커, 테스트가 그 자리를 대신 메웁니다.

그렇게 보면 Rust의 장황함은 비용이 아니라 투자에 가깝습니다. 소유권과 타입 시스템이 잡아주는 오류는, 에이전트가 런타임에서 헤매며 태웠을 토큰을 미리 막아줍니다. 컴파일 에러 메시지 자체가 훌륭한 피드백입니다. Go가 유리한 이유는 좀 다릅니다. 문법 표면적이 좁아서 모델이 만들어낼 수 있는 코드 형태의 가짓수가 애초에 적습니다. 선택지가 적으면 헛발질도 적습니다.

구도는 이렇습니다. Python은 첫 시도의 토큰이 싸지만 검증이 비쌉니다. Rust는 첫 시도가 비싼 대신 재시도 횟수가 줄어듭니다. Go는 양쪽 다 중간인데 분산이 작습니다. 총비용에서 어느 쪽이 이기는지는 작업 성격에 따라 갈립니다.

진짜 지표는 “수정 한 번에 드는 총토큰"입니다

그래서 저는 “어떤 언어가 토큰을 적게 쓰나"라는 질문 자체가 절반짜리라고 봅니다. 제대로 된 질문은 이겁니다. 기능 하나를 정확하게 완성할 때까지 쓴 총토큰이 얼마인가.

여기엔 최소 네 항목이 들어갑니다. 코드를 읽는 비용, 쓰는 비용, 검증 루프를 도는 횟수, 실패했을 때 되돌리는 비용. 무서운 건 세 번째입니다. 에이전트가 같은 버그를 세 번 반복해서 고치려 들면, 문법이 아무리 간결해도 절약분은 순식간에 날아갑니다.

그런데 언어 자체보다 더 큰 변수가 하나 있습니다. 도구 체인의 품질입니다. 에러 메시지가 친절한지, 타입 정보가 정적으로 드러나는지, 테스트가 몇 초 만에 끝나는지, 포매터가 결과를 결정적으로 만들어주는지. Rust와 Go가 에이전트 친화적이라는 평을 듣는 이유는 상당 부분 문법이 아니라 이 도구 체인 쪽에 있습니다. 거꾸로 Python도 타입 힌트에 mypy, ruff까지 제대로 붙이면 얘기가 꽤 달라집니다.

그렇다면 언어를 갈아타야 할까요

결론을 서두르기 전에 짚을 반론이 몇 개 있습니다.

가장 센 건 학습 데이터의 비대칭입니다. 모델은 세상에 있는 코드를 학습했고, 그 분포는 Python과 JavaScript에 심하게 쏠려 있습니다. 이론적으로 검증하기 좋은 언어라도 모델이 그 언어의 관용구를 덜 알고 있다면 실전 성능은 떨어집니다. 니치한 함수형 언어가 “타입이 강력하니 에이전트에 최적"이라는 주장이 현장에서 잘 안 먹히는 이유입니다.

또 하나. 언어를 바꾸는 비용은 토큰 몇 % 절약으로 회수되지 않습니다. 팀의 숙련도, 라이브러리 생태계, 채용, 운영 경험이 전부 언어에 묶여 있습니다. 에이전트 비용은 시간이 지나면 내려가지만 마이그레이션 비용은 그대로입니다.

지금 실무자가 당장 할 수 있는 건 언어 교체가 아니라 쓰던 언어를 에이전트 친화적으로 만드는 쪽입니다. 타입 힌트를 붙이고, 린터를 세게 걸고, 테스트를 빠르게 만들고, 에러 메시지를 읽을 만하게 손보는 겁니다. 파일을 적당한 크기로 쪼개는 것만으로도 컨텍스트 효율이 눈에 띄게 좋아집니다.

언어 설계의 관객이 늘었습니다

한 발짝 물러나 보면 더 흥미로운 변화가 보입니다. 지금까지 프로그래밍 언어는 사람을 위해 설계됐습니다. 읽기 쉬운 문법과 기억하기 좋은 키워드, 직관적인 개념을 놓고 고민했습니다. 그런데 이제 코드를 가장 많이 읽고 쓰는 쪽이 사람이 아닐 수도 있게 됐습니다.

앞으로 나올 언어나 표준 라이브러리 설계에 “토크나이저 친화성"이나 “에이전트가 오해하기 어려운 API"가 평가 항목으로 들어간다면, 꽤 낯선 광경이 될 겁니다. 이미 일부 프레임워크는 에이전트가 읽을 문서를 따로 내놓기 시작했습니다. 방향이야 이미 보입니다.

물론 함정도 있습니다. 사람이 읽기 어려운 코드를 에이전트가 잘 다룬다는 이유로 그냥 두면, 문제가 터졌을 때 아무도 손댈 수 없는 코드베이스가 남습니다. 에이전트 최적화와 사람이 이해할 수 있는 코드 사이 어디에 선을 그을지는 팀마다 직접 정할 수밖에 없습니다.

마무리

언어 선택의 기준이 바뀌는 건 맞지만, 답이 정해진 단계는 아닙니다. 확실한 건 “총토큰 대비 정확도"라는 축이 새로 생겼다는 것, 그리고 이 축에서는 짧은 문법보다 강한 검증 루프가 더 큰 무기라는 겁니다.

당장 쓰는 코드베이스가 에이전트에게 친절한지부터 확인해보는 게 낫습니다. 타입이 붙어 있는지, 테스트가 몇 초 만에 끝나는지, 에러 메시지가 읽을 만한지. 언어를 갈아엎는 것보다 이쪽이 훨씬 빠를 겁니다.