Go는 AI 에이전트를 위한 최적의 언어인가
getbruin.com 글 + Hacker News 반응 정리 — Rubyist 관점에서 읽어보기
getbruin.com이 "Go Is the Best Language for AI Agents"라는 글을 올렸고, HN에서 300개 넘는 댓글이 달렸다. 핵심 주장과 반론을 Rubyist 관점에서 정리한다.
원글의 핵심 주장
AI 에이전트가 코드를 대량 생성하는 시대다. 에이전트가 만든 코드는 대부분 "그럴듯하게 보이는" 수준이라 실제 동작 검증이 핵심이다.
Go는 이 검증에 유리하다는 게 원글의 요지다:
컴파일 언어의 이점 — 정적 타이핑으로 잘못된 타입/인수 사용을 컴파일 시점에 걸러낸다. 컴파일이 통과하면 최소한 구문적으로 올바른 코드라는 보장이 있다. Ruby에서 "프로덕션에서 TypeError 발견"하는 일이 없어진다.
Rust 대비 Go가 낫다는 이유 — Go 문법이 Rust보다 단순해서 LLM이 더 관용적인 코드를 생성한다. Go 컴파일이 Rust보다 빨라서 에이전트의 피드백 루프가 짧다. 학습 데이터에 Go 코드가 더 많다.
표준화된 도구 — gofmt, go test, go build가 표준이다. JS처럼 "이 프로젝트는 Prettier를 쓰고, 저 프로젝트는 ESLint를 쓰고" 같은 혼란이 없다. 에이전트에게 "포맷팅 해줘"라고 하면 gofmt 한 방이다.
크로스 플랫폼 바이너리 — GOOS=linux go build 하면 끝. Ruby처럼 "이 gem은 Windows에서 안 돌아가요" 같은 문제가 없다.
Rubyist가 읽으면 찔리는 부분
Ruby의 약점이 정확하게 지적된다.
Python과 Ruby의 문제: 동일한 작업에 20가지 다른 방식이 존재한다. Net::HTTP vs Faraday vs HTTParty vs RestClient. 에이전트가 어떤 라이브러리를 쓸지 예측할 수 없다. Go는 net/http 하나로 대부분 해결된다.
에이전트가 Go 코드를 한 번에 유효하게 생성하는 비율이 약 95%(원저자 체감). Ruby/Python은 런타임에서야 에러를 발견한다. 이 차이는 에이전트 워크플로우에서 크다.
HN에서 나온 반론들
"Java도 같은 이유로 적합하다" — 맞다. 더 많은 학습 데이터, 더 강력한 타입 시스템. 원글이 Java를 언급하지 않은 건 약간 편향적이다.
"Rust가 더 낫다" — 컴파일러 에러를 통과하면 런타임 에러가 거의 없다는 점에서 맞다. 다만 Rust는 언어가 빠르게 변해서 LLM이 최신 API를 따라가기 어렵다는 반론도 있다. Rust의 테스트가 소스 파일 안에 있어서 에이전트가 수정 시 테스트도 함께 갱신한다는 건 좋은 지적이다.
"OCaml/Haskell이 최고" — 강력한 타입 시스템(GADT 포함), 순수 함수, 빠른 빌드. 이론적으로 맞지만 학습 데이터가 부족하다.
"Python이 더 좋았다" — 여러 언어로 프로젝트를 재작성해본 사람이 Python이 Claude에게 가장 잘 맞았다고 주장. 코드가 짧고 이해하기 쉬워서.
"언어보다 도메인이 중요하다" — 이게 가장 현실적인 의견이다. TypeScript는 웹, Python은 데이터/ML, Go는 CLI/인프라. 에이전트에게 "최고의 언어"는 에이전트가 뭘 하느냐에 따라 달라진다.
그래서 Rubyist는 어떻게 해야 하나
Ruby가 에이전트 코드 생성에 불리한 건 사실이다. 동적 타이핑, 프레임워크 파편화, 런타임 에러 의존. 이건 Ruby의 구조적 약점이다.
근데 Rails 앱을 Go로 재작성해야 하나? 아니다. 원글도 인정하듯 "12개월 후에는 코드를 직접 읽는 일이 줄어들 가능성"이 있다. 지금의 언어별 장단점은 LLM 성능 향상과 함께 의미가 줄어들 수 있다.
실용적인 접근: Ruby로 비즈니스 로직, Go로 성능 크리티컬한 부분. Sidekiq 워커를 Go로 전환하거나, CLI 도구를 Go로 만드는 식. 이미 많은 팀이 이렇게 한다.
이 글에서 진짜 배울 점은 "Go가 최고다"가 아니라, 컴파일 타임 검증 + 표준화된 도구 + 단순한 문법이 에이전트 시대에 가치가 올라간다는 것이다. Ruby가 이 방향으로 진화할 수 있는지가 Rubyist에게는 더 중요한 질문이다.
원글 핵심 주장 vs HN 반론
| 원글 주장 | HN 반론 | Rubyist 관점 |
|---|---|---|
| Go 컴파일로 에이전트 코드 즉시 검증 | Java, Rust, OCaml도 동일 | Ruby는 런타임 의존 — 이건 진짜 약점 |
| Go가 Rust보다 단순 | Rust는 컴파일 통과 = 런타임 안전 | Ruby도 단순하지만 타입 안전성 없음 |
| 표준 도구 (gofmt, go test) | TS도 tsc+vitest로 충분히 표준화 | Ruby: RuboCop+RSpec+Bundler 조합 필요 |
| 에이전트 유효 코드 생성률 95% | Python이 Claude에게 더 맞았다는 의견도 | Ruby 수치 없음 — 체감상 더 낮을 것 |
| 크로스 플랫폼 바이너리 | Rust의 cargo도 동일 지원 | Ruby gem OS 호환 문제는 현실적 고통 |
HN에서 언급된 대안 언어들
Rust
컴파일 통과 = 런타임 안전. 테스트가 소스 파일 안에 있어 에이전트 수정 시 자동 갱신. 다만 언어 변화 속도가 빨라 LLM이 최신 API를 못 따라갈 수 있음.
Java
Go보다 많은 학습 데이터, 더 강력한 타입 시스템. 원글이 무시한 건 편향적. 다만 보일러플레이트가 많아 에이전트 생성 코드가 장황.
OCaml / Haskell
이론적 최강. GADT, 순수 함수, 빠른 빌드. 하지만 학습 데이터 부족이 치명적. OCaml은 \"사람이 쓰기에도 즐거운 언어\"라는 팬이 많음.
Python
실전에서 Claude와 가장 잘 맞았다는 반론. 코드가 짧고 가독성 높음. 데이터/ML 분야는 대체 불가. \"20가지 방법\" 파편화가 문제.
Rubyist를 위한 핵심 요약
인정할 것: 정적 타이핑 + 빠른 컴파일 + 표준 도구가 에이전트 시대에 가치가 올라간다. Ruby는 이 세 가지가 전부 약하다.
과대 해석하지 말 것: \"최고의 언어\"는 도메인에 따라 다르다. Rails 앱을 Go로 재작성할 이유는 없다.
실용적 접근: Ruby로 비즈니스 로직, Go로 성능 크리티컬 부분. Sidekiq 워커, CLI, 배치 처리를 Go로 분리하는 하이브리드가 현실적.
Ruby에서 Go로
에이전트가 코드를 생성하면 컴파일로 즉시 검증 — Ruby는 런타임까지 에러를 모른다
gofmt/go test/go build 표준 도구 — Ruby의 RuboCop/RSpec/Bundler 파편화와 대비
Go의 net/http 하나 vs Ruby의 Net::HTTP/Faraday/HTTParty/RestClient 파편화
크로스 플랫폼 바이너리 기본 지원 — Ruby gem의 OS 호환 문제 없음
실용적 접근: Ruby(비즈니스 로직) + Go(성능 크리티컬) 조합
장점
- ✓ 컴파일 타임 검증으로 에이전트 생성 코드의 95%가 첫 시도에 유효 (Ruby는 런타임 의존)
- ✓ gofmt 하나로 포맷 통일 — 에이전트가 Prettier vs ESLint 고민할 필요 없음
- ✓ 10년 넘게 호환성 깨지는 버전 없음 — LLM 학습 데이터가 오래돼도 유효
- ✓ 크로스 플랫폼 바이너리로 에이전트가 다양한 OS에서 동일한 코드를 검증·실행 가능
단점
- ✗ Ruby/Python 대비 라이브러리 생태계가 빈약 — 특히 데이터/ML 분야
- ✗ HN 반론: Rust는 컴파일 통과 시 런타임 에러 거의 제로 — Go보다 안전
- ✗ HN 반론: Python이 Claude에게 가장 잘 맞았다는 실전 경험도 존재
- ✗ \"최고의 언어\"는 도메인에 따라 다르다 — 웹은 TS, 데이터는 Python, CLI/인프라만 Go