Table of Contents
매일 아침 받는 IT 뉴스레터에서 “If AI writes your code, why use Python?” 라는 글을 봤다. 주장이 머리에서 떠나지 않아서 좀 더 파봤다.
예전엔 언어를 고를 때 “얼마나 많은 사람이 쓰는가”, “생태계가 큰가”, “읽기 좋은가” 같은 기준이 꽤 중요하다고 생각했었다. 그런데 그 글을 읽고 나서 이런 기준이 이전만큼 중요한지 의문이 생겼다. AI가 코드를 직접 쓰는 시대에는 “사람이 쓰기 좋은 언어”와 “에이전트가 정확히 쓰는 언어”가 다를 수 있기 때문이다.
그 글이 짚은 핵심
저자(N Mitchem)는 Python 자체를 비판하지 않는다. 선택 이유가 흔들리고 있다고 말한다. 크게 세 가지다.
1. Python 생태계가 점점 Rust로 채워지고 있다
Pydantic, Polars, orjson 같은 핵심 패키지가 내부적으로 Rust로 구현되어 있다. 저자는 이걸 “Rust 에코시스템이 Python 모자를 쓴 형태”라고 표현했다. 사용자는 Python으로 호출하지만 진짜 일하는 건 Rust다.
2. 컴파일러 피드백이 AI 자가 수정의 무료 학습 신호다
타입 시스템과 빠른 컴파일러가 있으면 에이전트가 잘못 쓴 코드를 즉시 잡아낼 수 있다. 사람한테 “엄격한 컴파일러”는 학습 비용이기도 했지만 에이전트한테는 자기 검증 도구가 된다.
3. 인력 경제가 바뀌었다
저자가 인용한 사례 중 가장 인상적인 건 이거다.
C 컴파일러를 만드는 것은 대학원 논문 주제였다. 이제는 아니다.
Anthropic이 Claude 에이전트 16개를 병렬로 돌려서 약 $20,000에 10만 줄 규모 C 컴파일러를 만들었다는 사례. 예전엔 “사람이 쉽게 쓸 수 있는가”가 시간 = 비용이었지만 이제는 “에이전트가 잘 쓸 수 있는가”가 그 자리를 차지하고 있다.
저자의 결론도 단호하지는 않다. “다음 프로젝트는 Python을 기본값으로 택할 필요가 없다” 정도다. 패러다임 전환이 임계점에 도달했다는 진단으로 읽힌다.
에이전트가 정확히 쓰는 언어의 5가지 조건
저자의 주장을 받아서 어떤 언어가 에이전트와 잘 맞을지 정리해봤다. 5가지 조건이 떠올랐다.
- 학습 데이터 풍부 — 모델이 잘 아는 언어여야 코드 생성 품질이 안정적
- 타입 시스템 — 에이전트가 잘못 쓴 코드를 컴파일 시점에 잡아냄
- 컴파일러 피드백 속도 — 실수 → 수정의 루프가 빨라야 자가 교정 가능
- 패턴 일관성 — “정답이 하나”인 언어가 코드 생성 일관성이 높음
- 빠른 실행 검증 — 결과를 빨리 확인할 수 있어야 함
이 5가지로 언어별 적합도를 평가하면 흥미로운 그림이 나온다고 생각한다.
언어별 평가
| 언어 | 학습 데이터 | 타입 안전 | 컴파일 피드백 | 패턴 일관성 | 성능 | 에이전트 적합도 |
|---|---|---|---|---|---|---|
| Rust | 중간 | 최강 (소유권) | 최강 | 높음 | 최고 | ★★★★★ |
| Go | 많음 | 강함 | 강함 | 매우 높음 | 최고 | ★★★★★ |
| TypeScript | 매우 많음 | 중상 | 중상 (tsc) | 중간 | 중 | ★★★★ |
| Kotlin | 많음 | 강함 | 강함 | 중간 | 상 | ★★★★ |
| Java | 최다 | 강함 | 강함 | 중간 (보일러플레이트) | 상 | ★★★ |
| Python | 최다 | 약함 | 없음 | 낮음 | 하 | ★★★ |
예전 같으면 Python이 압도적이었을 표라고 본다. 학습 데이터 최다 + 빠른 프로토타이핑 + 거대 생태계로 “사람 기준”에서 최강이었으니까. 그런데 에이전트 기준으로 보면 타입 약함 + 컴파일 피드백 없음 + 패턴 일관성 낮음이 자주 발목을 잡는다.
Rust는 반대 케이스다. 사람한테는 “학습 곡선이 높다”는 약점이 컸지만 에이전트한테는 그 약점이 거의 의미가 없어진다. 강한 타입 + 강한 컴파일 피드백 + 좋은 성능이라는 장점만 남는다고 생각한다.
핵심 통찰 — 쓰기 어려운 언어의 약점이 사라진다
이 표에서 보이는 건 Rust나 Go가 좋다는 단순한 얘기가 아니라고 생각한다. 언어 선택의 기준 자체가 흔들리고 있다는 점에 가깝다.
예전에 언어를 평가할 때 “쓰기 어려움” “학습 곡선” “보일러플레이트”는 큰 비용으로 잡혔다. 사람이 시간을 들여서 익혀야 하고 그 시간이 곧 인건비였기 때문이다. 그런데 그 비용의 상당 부분을 에이전트가 가져가면서 가중치가 줄어든다.
반면 “엄격한 타입” “컴파일러가 강제하는 것들”은 원래도 시스템 안정성이라는 큰 가치가 있었다. 컴파일 시점에 에러를 잡고 리팩토링이 안전해지는 그 가치는 사람이 쓰던 시절에도 분명했다. 에이전트 시대엔 그 위에 한 가지가 더 붙는다. 에이전트가 잘못 쓴 코드를 도구가 자가 검증으로 잡아주는 신호로도 작동한다.
그래서 같은 언어가 다른 평가를 받게 된다. Rust는 5년 전 “프로토타이핑엔 부적합한 언어”였지만 지금은 “에이전트가 가장 잘 쓰는 언어 후보”로 다시 보인다.
에이전트는 코드만 쓰는 게 아니다
코드 생성만 보면 위 결론으로 충분하다고 본다. 그런데 요즘 코드 에이전트는 코드만 쓰지 않는다. 디버깅을 하고 테스트를 작성하고 실행하고 CI/CD 파이프라인까지 손댄다. 그러면 언어 선택 기준은 “AI가 코드 잘 쓰는가”에서 “AI가 SDLC 전반을 잘 다루기 좋은가”로 넓어진다.
각 영역에서 어떤 언어가 유리할지 생각해보면 몇 가지 갈래가 보인다.
- 테스트: 명시적 프레임워크(JUnit, Pytest, Jest 등)를 가진 언어가 유리하다. 결과 출력이 깔끔해야 에이전트가 파싱해서 다음 액션으로 이어가기 좋다
- 디버깅: 컴파일 언어 쪽이 스택 트레이스가 정확하다. JVM 예외 정보는 풍부해서 에이전트가 원인을 추적하기 좋고 Python은 런타임 에러라 컨텍스트가 적어서 추측 작업이 들어간다
- 빌드/배포: Go의 단일 바이너리 배포는 에이전트가 다루기 가장 단순하고 Spring + Gradle 같은 무거운 빌드는 컴파일 피드백이 느려서 자가 검증 루프가 늘어진다 (이건 직접 작업하면서 자주 체감하는 부분이다)
평가 도구 쪽도 흐름이 바뀌고 있다. 검색해보니 JetBrains가 다국어 SDLC 전반 평가용 DPAI Arena를 내놨고 Spring AI Bench 같은 엔터프라이즈 자바 전용 벤치마크도 등장했다고 한다. 단순 코드 생성 정확도가 아니라 SDLC 전반의 적합도가 평가 기준이 되는 흐름인 듯하다.
Python이 “사람한테 빠른 프로토타이핑”으로 강했다면 Go와 Rust는 “에이전트한테 빠른 SDLC 사이클”로 다른 결의 강점을 가진다고 생각한다.
개인 챗봇 프로젝트 케이스
내 개인 챗봇 프로젝트는 세 레포로 나뉜다.
| 레포 | 언어 | 선택 이유 |
|---|---|---|
| Agent | Python (Google ADK) | ADK가 Python부터 시작했고 LiteLLM 통한 다양한 모델 지원이 압도적 |
| Core | Kotlin (Spring WebFlux + R2DBC) | 기존 Spring 경험 + 강타입 + Reactive |
| Mobile | Kotlin Multiplatform (iOS/Android) | iOS와 Android 공통 로직 공유 |
이 조합은 1년 전 결정이고 그 시점엔 합리적이라고 봤다. 위에서 정리한 기준으로 다시 보면 각 레포가 다르게 평가된다고 생각한다.
Agent의 Python은 가장 마음에 걸린다. 에이전트가 Python 코드를 쓸 때 타입 힌트가 누락된 부분이 자주 생기고 런타임에야 발견되는 에러도 종종 본다. ADK 자체가 함수 시그니처에서 도구 스키마를 자동 생성하니까 Python의 강점이긴 한데 그 외 영역에서는 타입 약함이 자주 발목을 잡는다.
Core의 Kotlin은 양면이 있다고 본다. 강점은 명확한 편이다. @RestController @Service @Repository @Transactional 같은 명시적 annotation이 에이전트한테 가독성 있는 컨텍스트를 만들어준다. 강타입 + Reactive 패턴 위에서 에이전트가 비교적 일관된 코드를 생성하는 것을 자주 본다. 컴파일 시점에 에러를 잡아주는 덕분에 잘못 쓴 부분도 PR 직전에 발견되는 경우가 많다.
한편 마음에 걸리는 건 Spring 자체의 무게다. 단순 한 줄 변경에도 무거운 컴파일 사이클이 돌고 빌드 피드백이 빠르지 않다. 에이전트가 작은 실수를 빠르게 자가 수정하려면 컴파일 피드백 속도가 중요한데 Spring + Gradle 조합은 그 부분에서 Go나 Rust보다 한 박자 느리다.
Mobile의 KMM은 큰 문제는 없지만 활용 깊이가 아직 얕다.
다시 시작한다면
머리로만 비교하면 “다음엔 Agent는 TypeScript나 Go로 가야지” 같은 결론이 나오는데 막상 새 언어로 처음부터 짜기 시작하면 익숙한 패턴 없이 막히는 영역이 많다. 실제로 생각하는 것과 체감하는 것은 다르다고 생각한다.
그래서 다음에 비슷한 성격의 프로젝트를 한다면 같은 결과물을 다른 언어로 작성해보고 비교해보고 싶다. 효율적으로 작성되는지 테스트할 땐 어떤지 디버깅할 땐 어떤지 — 머리로 그린 표보다는 직접 굴려봐야 알 수 있다.
후보는 두 가지다.
- Agent 오케스트레이션을 TypeScript로 — JSON 네이티브 + SDK 생태계 + Anthropic/OpenAI/Vercel AI SDK가 first-class
- 백엔드를 Go로 — goroutine 동시성 + 단일 바이너리 배포 + 패턴 일관성
Rust는 매력적이지만 1인 환경에서 처음부터 가긴 부담이 있다고 본다. 다만 성능 크리티컬한 부분(임베딩, 벡터 검색)에서 부분 도입은 충분히 검토할 만하다.
Google ADK 언어별 현황
ADK가 4개 언어를 다 지원하니까 상황별로 다른 선택이 가능하다.
| 상황 | 추천 |
|---|---|
| Gemini 전용 + 대규모 동시 에이전트 | Go |
| 기존 Spring 인프라에 에이전트 통합 | Java |
| 풀스택 + 채팅 UI + 빠른 프로토타입 | TypeScript |
| 다양한 LLM + ML 연계 | Python |
Python의 “LiteLLM 내장으로 비-Gemini 모델 가장 쉽게”는 여전히 강점이고 한동안은 사라지지 않을 것이다. 다만 ADK가 4개 언어 모두 A2A 프로토콜을 지원하니까 “한 언어로 통일”의 압박은 많이 줄어든 듯하다. 도메인별로 다른 언어를 쓰고 에이전트끼리 통신하는 그림이 자연스러워졌다.
그래서 주력 언어인 Java/Kotlin은 어떨까
여기까지 정리하면서 가장 궁금했던 건 내가 주력으로 쓰고 있는 Java와 Kotlin이 앞으로 어떤 자리에 있을 것인가다.
다른 언어들의 흐름을 추측해보면 대략 이런 그림이지 않을까 싶다. 확신은 아니고 지금 보이는 흐름을 보고 생각한 정도다.
- Rust — 학습 곡선이 가장 큰 약점이었는데 그게 사라지는 흐름이라 한 단계 더 부상할 가능성이 있어 보인다
- Go — 단순함과 단일 바이너리 배포로 백엔드와 CLI에서 안정적인 자리를 유지할 가능성이 크다
- TypeScript — 풀스택과 AI SDK 생태계로 에이전트 오케스트레이션 영역에서 계속 확장 중인 듯
- Python — ML/파인튜닝/데이터 사이언스에서는 압도적으로 유지될 것이다. 다만 일반 백엔드와 에이전트 오케스트레이션에서는 점차 자리를 내주는 흐름
그 흐름 속에서 Java/Kotlin의 자리는 어디일까. 일단 강점은 살아있다고 본다. 위에서 정리한 “AI가 잘 쓰는 언어의 조건” 다섯 가지 중 학습 데이터 / 타입 / 컴파일러 / 패턴 일관성 네 가지에서 이미 상위권에 있다고 생각한다. 검색해보니 JVM 진영에서도 AI 에이전트 프레임워크가 새로 등장하고 있는 듯하다. JetBrains가 Koog라는 Kotlin AI 스택을 내놨고 Spring 생태계엔 Embabel 같은 게 있다고 한다. 직접 써본 건 아니지만 이런 흐름이 등장한다는 자체가 Java/Kotlin이 “AI 에이전트와 안 맞는 옛 언어”는 아니라는 신호로 읽힌다.
다만 한계도 보인다. 단순 프로토타이핑이나 가벼운 도구는 다른 언어가 더 빠르고 Spring + Gradle의 무거운 빌드 사이클은 에이전트 자가 검증 루프 속도를 떨어뜨린다 (이건 직접 작업하면서 자주 체감하는 부분이다). 신규 프로젝트의 첫 선택지로는 Go나 TypeScript가 더 자주 거론될 가능성도 있어 보인다.
종합하면 엔터프라이즈와 장기 운영이 필요한 영역에서는 1군 자리를 안정적으로 유지하지 않을까 싶다. 다만 새로 시작하는 작은 프로젝트의 첫 선택지에서는 점유율이 조금 줄어들 수도 있겠다.
내 입장에서는 Java/Kotlin이 익숙하고 검증된 도구라서 한동안은 계속 손에 잡힐 것이다. 다만 이번 정리를 하면서 다른 언어들도 한번 진지하게 써보고 싶다는 생각이 생겼다. 특히 Agent 오케스트레이션은 TypeScript나 Go 같은 결의 언어로 짜면 어떤 체감인지 직접 보고 싶다. 익숙한 게 정답이라고만 생각하기엔 흐름이 빠르게 바뀌고 있다.
마무리
“Python의 시대가 끝났다”는 단정은 과하다고 생각한다. ML/파인튜닝/데이터 사이언스에선 여전히 압도적이고 학습 데이터의 절대량도 다른 언어가 따라가기 어려운 수준이다. 다만 출처 글의 결론처럼 기본값으로 택할 필요가 없는 시점이 된 건 맞다.
뉴스레터에서 본 짧은 글 하나가 도화선이 됐다. 5년 전이라면 같은 표를 보고도 같은 결론이 안 나왔을 것이다. 그만큼 답이 바뀌는 질문인 듯하다.
다음 신규 프로젝트가 생기면 한 부분은 다른 언어로 짜보고 같이 굴려보면서 비교해볼 생각이다. 표는 표일 뿐이고 결국 직접 굴려봐야 보인다.
- #ai-agent
- #programming-language
- #rust
- #go
- #typescript
- #python
- #language-selection