AI 코딩 에이전트를 팀에 도입하고 나면 자연스럽게 이런 질문이 따라온다. "어떤 언어로 짜야 AI가 가장 잘 도와줄까?" 직관적으로는 '간결할수록 좋다'는 답이 떠오른다. AI가 처리하는 토큰이 적을수록 비용이 줄고 속도가 빨라질 것 같으니까. 그런데 실제 데이터는 이 직관을 정면으로 반박한다.
토큰 효율 가설은 왜 틀렸나
한때 꽤 설득력 있게 돌던 주장이 있었다. Clojure나 J 같은 동적·간결 언어가 '토큰 효율'이 높아서 AI 코딩에 유리하다는 것이다. 실제로 C와 Clojure 사이에 2.6배, C와 J 사이에는 거의 4배에 가까운 토큰 수 차이가 측정되기도 했다. 논리는 단순하다—같은 로직을 더 적은 토큰으로 표현하면 비용이 줄고 생성 속도도 빨라진다.
하지만 Dan Luu의 분석(dev.to)이 이 가설의 구조적 결함을 드러냈다. 문제는 평가에 쓰인 태스크가 너무 단순하다는 것이다. 사람이 30초면 푸는 수준의 문제에서 측정한 토큰 수 차이는, 실제 소프트웨어 엔지니어링 문제 앞에서 사실상 사라진다. Luu가 AI 에이전트에게 RFC 스펙을 주고 완전한 zstd 디코더를 구현하게 했을 때, 결과는 토큰 효율 가설의 예측과 정반대였다. Python, Go처럼 학습 데이터가 풍부한 언어에서 더 정확한 코드가 나왔고, 총 토큰 비용도 더 낮았다.
이유는 명확하다. LLM은 GitHub 리포지토리와 Stack Overflow 답변, 공식 문서의 방대한 코퍼스 위에서 학습된다. Python과 JavaScript에는 수억 줄의 코드와 수백만 개의 Q&A가 쌓여 있다. J 언어에는 그만한 데이터가 없다. 학습 데이터가 희박한 언어에서는 에이전트가 존재하지 않는 라이브러리 함수를 만들어내고, 미묘하게 틀린 문법을 쓰고, 엣지 케이스를 놓친다. 토큰을 50% 아껴도 수정 이터레이션이 두 배 늘어나면 총 비용은 오히려 높아진다.
정적 타입은 AI 에이전트의 안전망이다
언어 선택에서 두 번째로 중요한 축은 타입 시스템이다. AI 에이전트는 파일 간 타입 일관성을 자주 깨뜨린다. 존재하지 않는 필드를 참조하고, 없는 메서드를 호출하고, 슬그머니 타입을 어긴다. Python이나 JavaScript에서는 이런 오류가 런타임까지 숨어 있다가 프로덕션에서 터진다.
Go나 Rust에서는 컴파일러가 즉시 잡아낸다. AI가 환각(hallucination)으로 없는 구조체 필드를 참조하면, 그 순간 빌드가 실패한다. 이 자동화된 검증 루프가 AI 코딩 에이전트의 실질적인 품질 안전망이 된다. 토큰 수에는 잡히지 않지만, 검증 비용과 이터레이션 횟수를 줄이는 방식으로 총 개발 비용에 직접 영향을 미친다.
Go가 AI 협업 언어로 주목받는 이유
Google Developers Blog가 최근 Go가 AI 보조 소프트웨어 엔지니어링의 중심 언어로 자리잡고 있다는 분석을 내놓았다(dev.to). 핵심 논리는 이렇다. 인간이 모든 코드를 직접 타이핑하던 시대에는 '얼마나 빠르게 쓰느냐'가 언어 생산성의 척도였다. AI 에이전트가 초당 수백 줄을 생성하는 지금은 '얼마나 빠르게 읽고 검증하느냐'가 기준이 됐다.
Go는 처음부터 가독성 우선으로 설계됐다. gofmt는 스타일 논쟁 없이 생태계 전체의 포맷을 단일화한다. AI가 생성한 Go 코드든, 시니어 엔지니어가 쓴 코드든, 어떤 Go 개발자도 같은 방식으로 읽을 수 있다. AI 생성 JavaScript는 다양한 프레임워크와 스타일 컨벤션이 뒤섞여 검증 부담이 커지지만, Go에서는 그 문제가 원천적으로 없다.
공급망 보안도 중요한 포인트다. LLM은 학습 데이터에 포함된 오래되거나 관리가 끊긴 패키지를 추천하는 경향이 있다. Go의 'batteries-included' 표준 라이브러리는 HTTP, 암호화, 압축, 테스팅을 모두 커버해 외부 의존성 없이 대부분의 기능을 구현할 수 있다. 외부 패키지가 필요할 때도 go.sum의 체크섬 검증이 무결성을 보장한다.
테스트 생태계의 일관성도 실질적인 차별점이다. Go는 go test ./... 한 줄로 전체 테스트 스위트를 실행한다. 에이전트가 리팩토링 후 스스로 테스트를 돌려 검증하는 흐름이 자연스럽다. 다른 언어에서는 어떤 테스트 프레임워크를 쓰는지 파악하고 설정을 이해하는 것 자체가 에이전트에게 불필요한 맥락 부담이 된다.
코드 구조도 선택이다—Next.js 데이터 기반 UI 사례
언어 선택만큼이나 코드 구조와 아키텍처 결정도 AI 워크플로우에 영향을 준다. 흥미로운 실제 사례가 있다. Next.js 템플릿 스토어를 운영하는 개발자가 프로덕트 커버 이미지를 아예 없애고, 두 개의 숫자와 문자열 하나로 렌더 타임에 생성하는 방식을 택했다(dev.to).
구조는 단순하다. 각 제품의 시각 설정은 hues(OKLCH 색상각 두 개)와 motif(인터페이스 추상 패턴)로 끝난다. PNG도 WebP도 없다. 커버 아트는 DOM 노드와 인라인 스타일로 HTML과 함께 압축돼 전송된다. 네트워크 바이트 비용이 0이고, 레이아웃 시프트도 없다.
이 결정이 흥미로운 건 단순히 성능 최적화 사례라서가 아니다. 데이터에서 UI를 도출하는 구조는 AI 에이전트와 협업하기에도 훨씬 다루기 쉽다. 이미지 에셋 관리 대신 타입스크립트 객체 하나를 수정하면 된다. 새 제품을 추가할 때 디자인 작업이 필요 없다. 에이전트에게 "카탈로그 파일에 이 형식으로 항목 추가해줘"라는 명령 한 줄이면 충분하다.
색상 시스템에 OKLCH를 선택한 이유도 구조적 사고에서 나왔다. HSL은 같은 밝기 값이라도 색상에 따라 시각적 밝기가 달라서, 자동 생성된 카드마다 수작업 보정이 필요해진다. OKLCH의 지각적 균등성은 밝기와 채도를 한 번만 튜닝하면 모든 색상에 일관되게 적용된다는 뜻이다. 규칙을 한 번 설계해두면 이후는 데이터만 바꾸면 된다—AI 에이전트가 가장 잘 다루는 패턴이다.
실질적 선택 기준 정리
세 개의 분석을 엮으면 AI 에이전트 시대의 언어·코드 구조 선택 기준이 선명해진다.
첫째, 학습 데이터 규모가 토큰 효율보다 압도적으로 중요하다. Python, TypeScript, Go, Java, C#은 안전하다. 이론적으로 간결한 언어는 실전에서 더 많은 이터레이션 비용을 만든다.
둘째, 정적 타입 시스템은 AI 에이전트의 환각을 컴파일 타임에 차단하는 자동화 안전망이다. 타입 선언의 토큰 비용보다 런타임 오류의 수정 비용이 훨씬 크다.
셋째, 생태계 일관성—단일 포매터, 표준 테스트 도구, 명확한 컨벤션—이 에이전트의 맥락 부담을 줄이고 검증 루프를 빠르게 한다.
넷째, 데이터에서 UI를 도출하는 구조는 에이전트가 다루기 쉬운 패턴이다. 이미지 에셋 관리 대신 타입스크립트 객체를 다루게 하면, 에이전트의 작업 범위가 명확해지고 실수 가능성이 줄어든다.
결국 AI 에이전트와 잘 일하는 코드베이스는 사람이 읽기 좋은 코드베이스와 크게 다르지 않다. 명확한 타입, 일관된 포맷, 예측 가능한 구조—이것들은 팀 협업을 위해 설계된 원칙이고, AI라는 새 팀원도 정확히 같은 것을 필요로 한다. 에이전트를 도입할수록 코드 구조 설계의 중요성은 올라가지, 줄어들지 않는다.