▲

Go는 AI 에이전트를 위한 최고의 언어

 (getbruin.com)
1P by GN⁺ 3시간전 | ★ favorite | 댓글 1개
  • Go 언어의 단순성과 컴파일 특성이 AI 에이전트가 생성하는 코드의 안정성과 실행 효율을 높임
  • 정적 타이핑과 빠른 컴파일 속도 덕분에 에이전트가 코드 오류를 빠르게 검증하고 반복 작업을 효율적으로 수행할 수 있음
  • 언어 차원의 표준화된 도구(gofmt, 테스트, 빌드)가 에이전트의 일관된 코드 생성을 유도함
  • 크로스 플랫폼 바이너리 빌드가 기본 지원되어, 백그라운드 에이전트가 다양한 OS에서 동일한 코드를 분산 검증·실행 가능
  • 이러한 특성 덕분에 Go는 생산성, 단순성, 성능의 균형을 갖춘 언어로 평가되며, AI 에이전트 기반 개발시 유력한 선택지로 부상

Go가 컴파일 언어인 이점

  • 에이전트는 대량의 코드를 생성하며, 이 코드는 대부분 "그럴듯하게 보이는" 수준이므로 실제 동작 여부 검증이 핵심 과제
  • 컴파일 언어를 사용하면 강타입·정적 타입 시스템을 통해 잘못된 타입이나 인수 사용 등 특정 범주의 버그를 컴파일 시점에 배제 가능
  • 컴파일이 성공하면 언어 표준 범위 내에서 구문적으로 올바른 코드라는 보장을 얻게 됨
  • Rust와 비교 시 Go가 에이전트에 더 적합한 이유:
    • Go의 문법과 개념이 Rust보다 단순
    • Go의 타입 시스템이 Rust보다 덜 정교하여, 생성된 코드가 관용적 작성 방식에 더 가깝고 사람이 이해하기 쉬움
    • Go의 컴파일 속도가 Rust보다 빠르므로 에이전트의 피드백 루프가 단축
    • Rust보다 Go 코드가 학습 데이터에 더 많이 포함되어 있어 모델이 더 나은 Go 코드를 생성

Go의 단순성

  • 어떤 프로그래밍 언어에든 익숙하다면 Go 코드를 읽고 즉시 동작을 파악할 수 있을 정도로 언어 자체가 단순
  • 에이전트가 대량의 Go 코드를 생성하더라도 개발자가 코드를 따라가는 데 큰 어려움이 없음
  • 에이전트가 때때로 이상한 설계 결정을 내리고 그 방향으로 계속 진행하는 경우, 언어의 단순성 덕분에 에이전트가 어디로 향하는지 쉽게 파악 가능
  • 12개월 후에는 코드를 직접 읽는 일이 줄어들 가능성도 있어 가독성·단순성의 중요성이 감소할 수 있으나, 필요시 코드를 직접 확인할 수 있는 선택지는 여전히 가치 있음

Go의 표준화된 방식

  • Go는 명확한 가이드라인과 도구를 갖춘 의견이 강한(opinionated) 언어로, 테스트 실행·코드 포매팅·바이너리 빌드에 표준적인 방법이 존재
  • 에러 처리 방식도 호불호가 갈리지만 하나의 확립된 패턴을 제공하여 여러 사람과 에이전트가 함께 작업하기 용이한 관용적 코드 작성을 유도
  • JavaScript와 대비: JS 프로젝트마다 사용하는 도구가 다르고, 코드 포매팅·패키지 배포·라이브러리 임포트 방식에 대한 의견이 분산되어 있어 에이전트에게 비효율적
  • Go의 표준화 덕분에 모델이 학습 데이터 기반으로 관용적 Go 코드를 일관되게 생성 가능
    • 에이전트에 JS 코드 포매팅을 요청하면 새 도구를 설치하고 설정하려 하지만, Go에서는 단순히 gofmt를 실행하면 완료
    • 유닛 테스트 작성이나 바이너리 빌드도 동일하게 표준화

크로스 플랫폼 바이너리 빌드

  • Go에서 크로스 플랫폼 지원은 일급 시민(first-class citizen)으로, CLI 도구처럼 실행 환경을 통제할 수 없는 소프트웨어에 특히 유리
  • 유닛 테스트와 통합 테스트를 여러 환경에서 동일한 명령으로 실행하여 기존 기능이 깨지지 않았는지 검증 가능
  • 백그라운드 에이전트 활용 시에도 이점이 극대화:
    • Cursor를 Slack 메시지로 트리거하거나 로컬 세션을 원격으로 넘기는 등, 코드 빌드·실행 환경에 대한 직접적 통제에서 점차 분리되는 추세
    • Go 코드는 Linux, Windows, macOS에서 동일하게 바이너리를 생성하고, 작업 프로세스 전체가 환경 간 표준화되어 있어 샌드박스 제공자의 개발 의존성 지원 여부에 신경 쓸 필요 없음

에이전트의 Go 코드 생성 품질

  • 2026년 초 기준으로 에이전트가 유효한 Go 코드를 한 번에 생성하는 비율이 약 95% (개인 경험 기반 수치, 공식 데이터는 아님)
  • Python보다 Go에서 에이전트 활용 시 어려움이 적은 체감
  • 모델이 Go의 라이브러리·패턴·모범 사례를 충분히 학습하여, 방향만 잡아주면 기능 구현이 거의 수월한 수준
  • Go 학습 데이터 총량은 Python보다 적을 수 있으나, Python은 동일한 작업에 20가지 다른 방식이 존재하여 특정 라이브러리 기준으로 보면 Go의 학습 데이터 밀도가 더 높은 효과
  • 모델 성능 향상과 학습 데이터 확대에 따라 이 이점은 시간이 지나면 사라질 가능성 있음

Bruin 프로젝트의 Go 선택 배경

  • Bruin은 오픈소스 ETL 도구로, 주로 Go로 작성된 CLI 도구
  • 데이터 생태계에서 Python이 주류였지만 Go를 선택한 주요 제약 조건:
    • 데이터 오케스트레이션 도구로서 동시성 처리가 핵심
    • 언어 런타임이나 데이터 플랫폼 외부 API 등 다양한 시스템과 상호작용해야 하므로 충분한 생태계 필요
    • CLI 도구로서 VS Code 확장이나 로컬 UI 백엔드로 활용하기 위한 충분한 성능 필수
    • 다양한 시스템 통합을 위한 예측 가능한 에러 처리 필요
    • 사용자 머신에서 실행되므로 다양한 OS·아키텍처 지원 용이성 요구
  • 주관적 요소로, 주요 기여자가 작업을 즐길 수 있는 언어여야 했으며, 소규모 팀에서 즐거움과 에너지는 가장 희소한 자원
  • Python 대비 특정 데이터 라이브러리 부족이라는 단점에도 불구하고 Go의 속도와 개발자 경험(DX) 이점이 장기적으로 더 큰 가치를 제공할 것이라는 직관으로 결정

결론: 에이전트 시대의 Go

  • 프로그래밍 언어는 인간이 직접 코드를 작성하지 않는 시대로 이동 중임
  • 이제 에이전트가 효과적으로 코드를 작성할 수 있게 지원하는 시스템이 필요
  • Go는 사용성, 성능, 보편성의 균형 덕분에 AI 에이전트가 코드를 작성하고 실행하기에 이상적인 환경을 제공함
  • 에이전트는 Go로 컴파일, 테스트, 포맷팅, 다양한 머신에 배포가 가능한 고성능 소프트웨어를 자동 생성할 수 있음
  • Go가 에이전트를 위한 궁극적 언어가 될지, 더 적합한 언어가 등장할지는 불확실하나,
    현재 팀은 생산성과 소프트웨어 품질에서 충분한 성과를 거두고 있음
▲
GN⁺ 3시간전  [-]
Hacker News 의견들

  • 나는 9개월 넘게 컨설팅 업무를 하며 Go가 LLM 코드 생성에 매우 적합하다는 걸 계속 확인하고 있음
    Go는 일관된 빌드 시스템, 포매터, 정적 타이핑, 그리고 C++처럼 위험한 부분이 없는 CSP 기반 동시성을 제공함
    10년 넘게 호환성 깨지는 버전이 없고, 프레임워크 변화도 거의 없음
    내가 Sancho Studio에서 팀들에게 agentic coding workflow를 도입하도록 조언할 때, Go는 Claude나 Codex에서 매우 안정적인 결과를 냄
    반면 Python이나 TypeScript는 프레임워크와 타입 접근 방식이 너무 다양해서 LLM이 일관된 출력을 내기 어려움
    사실 Go를 싫어했던 이유 — 추상화의 한계 — 가 LLM에게는 장점으로 작용함
    Go 1.26의 새로운 go fix는 AST 수준의 자동 리팩터링을 지원해 코드베이스를 최신 상태로 유지함
    예전에 Zoom E2E Whitepaper 프로젝트에서 Go로 PKI를 구축했는데, 이제는 LLM이 반복적인 보일러플레이트를 대신 처리하니 Go의 단순함이 진가를 발휘함

    • 이런 이유 대부분은 Java에도 적용된다고 생각함
      Java는 더 많은 학습 데이터와 더 강력한 타입 시스템을 가지고 있어서 LLM 출력 검증에도 유리함
    • 완전 공감함. 20년 넘게 C++을 써왔지만, Golang은 실시간 제어나 임베디드가 아닌 대부분의 워크플로우에서 최고의 언어라고 생각함
    • “Go의 추상화 한계가 LLM에게는 장점”이라는 말에 깊이 공감함
      나는 로우레벨 환경을 선호하는데, Go의 얕은 추상화 스택과 예측 가능한 구조가 마음에 듦
      결국 단순함과 일관성이 LLM에게도, 나 같은 개발자에게도 잘 맞음
    • 최근 LLM들의 코드 품질을 보면 언어보다는 문제 정의의 복잡성이 더 큰 변수임
      Go처럼 표준화된 언어는 결과를 이해하기 쉽지만, Ruby나 C++도 꽤 괜찮은 편임
      Lisp이나 Bash는 자유도가 높아 결과가 들쭉날쭉함
    • 네가 Go에 편향돼 있을 수도 있겠지만, 나는 TypeScript 쪽 경험이 많아서 다르게 봄
      Python과 TypeScript를 같은 범주로 묶는 건 부정확함
      Python은 버전 단절과 느린 타입 도입 때문에 LLM이 혼란스러워하지만, TypeScript는 훨씬 일관적임
      기회가 된다면 Go vs TypeScript 라이브 코드 대결을 해보고 싶음

  • 에이전트 개발에서는 가능한 많은 검증을 컴파일 타임으로 옮기는 게 좋다고 생각함
    Go는 괜찮지만 타입 시스템이 다른 언어만큼 강력하지 않음
    Rust는 컴파일러 에러를 통과하면 런타임 에러가 거의 없다는 점에서 매우 유용함
    Haskell은 아마 더 좋을 것 같음

    • Rust가 좋은 이유 중 하나는 테스트 코드가 같은 파일에 존재한다는 점임
      에이전트가 소스 수정 시 테스트도 함께 갱신함
      다른 언어에서는 테스트를 잊어버리기 쉬움
    • Haskell도 훌륭하지만, LLM은 너무 많은 추상화를 쌓는 경향이 있음
      나는 Haskell 위에 의존 타입 기반 토이 언어를 만들고 있는데, 단순한 문법 덕분에 LLM이 다루기 쉬움
      내부적으로는 안전/비안전 Rust처럼 작동함
    • Rust에 한 표. 복잡성을 초기에 부담하고 운영 비용을 줄이는 전략이 맞다고 생각함
      우리가 직접 쓰는 게 아니니 약간 불편해도 괜찮음
    • 나도 Rust를 즐겨 쓰는데, 언어 간 상호운용성이 뛰어남
      TypeScript와 함께 SPA를 만들거나, Tauri로 멀티플랫폼 앱을 만들고, Python 사이드카를 붙이는 식으로 조합이 가능함
      Bevy로 게임도 실험 중인데, ECS 구조가 마음에 듦
      여러 언어의 장점을 모으면서 단점을 피할 수 있었음
    • Haskell이나 Prolog 같은 고수준 언어를 2025년 LLM과 함께 실험해본 사람이 있는지 궁금함

  • 며칠 동안 Gemini, Claude Code, Codex에게 “너희가 원하는 언어를 설계해봐”라고 시켜봤음
    결과는 Forth 스타일 언어인데, 강한 타입 시스템과 계약, 네이티브 테스트, fuzz 테스트, Z3 기반 제약 해결기를 갖춘 형태였음
    Elixir로 인터프리터를 구현했고, Cairn 프로젝트로 공개함
    150커밋 정도로 만든 언어가 런타임 에러 없이 작동했음
    이 실험은 컴파일 타임 분석과 테스트 도구의 중요성을 보여줌

    • 흥미로운 프로젝트지만, LLM이 자신에게 유리한 언어를 설계할 수 있다고 가정하는 건 잘못된 전제라고 생각함
      그런 정보는 학습 데이터에 없으면 알 수 없음
    • 내 이상적인 언어와 거의 일치해서 놀라웠음
      이런 언어의 툴링을 발전시키는 건 정말 즐거운 일일 것 같음
    • 혹시 BEAM 바이트코드로 직접 컴파일하도록 시켜봤는지 궁금함
    • 인상적임. 초보자 입장에서 다른 Forth 계열 언어보다 배우기 쉬운지도 궁금함

  • 나는 여전히 OCaml이 최고의 선택이라고 생각함
    강력한 타입 시스템(GADT 포함), 순수 함수 중심, 빠른 빌드 속도, WASM/JS 타깃 지원 등 장점이 많음
    코드가 파일 내 순서대로 평가되어 순환 의존성을 명시적으로 처리해야 하는 점도 안정적임
    무엇보다 사람이 쓰기에도 즐거운 언어임

    • 요즘 멀티코어와 비동기 처리는 어떤지 궁금함
      예전엔 F#이 그 부분에서 앞서 있었음
    • OCaml 컴파일러는 버그 탐지 능력이 탁월함
      에이전트가 실수로 버그를 넣어도 대부분 잡아냄
    • Go 대신 OCaml을 추천함. 표현력 있는 타입 시스템 덕분에 Go로는 불가능한 추상화를 만들 수 있음
    • 그런 점이라면 차라리 F# 을 쓰는 게 낫지 않을까 싶음

  • PHP, Go, JavaScript, Python 중에서라면 Go가 낫지만, 그게 “최고의 언어”라는 근거는 약함

    • 나는 Rust를 선호함. 컴파일러 피드백 루프가 훌륭하지만 문법이 장황함
      Go의 단순함과 충분한 타입 시스템도 매력적임
    • 네 언급 중 유일한 컴파일 언어가 Go라는 점이 중요함

  • 얼마 전 논의된 "Why Elixir is the best language for AI"를 참고할 만함
    BEAM의 런타임 인트로스펙션 기능이 에이전트 환경에서 흥미로운 포인트임

  • Go에는 코드와 바이너리의 취약점을 정적 분석하는 govulncheck 도구가 있음
    공식 튜토리얼처럼 Go 생태계에 깊이 통합되어 있고, 다른 언어보다 높은 수준의 통합성을 가짐

    • Rust의 cargo-audit와 어떤 차이가 있는지 잘 모르겠음
      govulncheck가 실제 코드 취약점을 분석하는지는 의문임
    • govulncheck는 코드 자체의 취약점을 찾는 게 아니라 의존 라이브러리의 취약 사용 여부를 분석함
      호출 경로까지 추적하는 점은 장점이지만, Coverity 같은 진짜 정적 분석 도구와는 다름
      Go에서는 golangci-lint 같은 커뮤니티 도구 묶음이 더 가깝다고 봄
    • 그래도 govulncheck의 통합 수준과 사용성은 다른 언어보다 뛰어나서 대규모 프로젝트 유지보수에 큰 도움이 됨

  • 여러 언어로 프로젝트를 재작성해봤는데, Python이 Claude에게 가장 잘 맞았음
    코드가 작고 이해하기 쉬워서 작업 속도가 훨씬 빨랐음
    Go, Kotlin, JavaScript도 시도했지만 결국 Python으로 정착했음

    • Python 코드에서 예외 처리나 pass 문을 제대로 다뤘는지 궁금함

  • Go는 나쁘지 않은 선택임. 학습 데이터가 풍부하고 API가 안정적이라 LLM이 다루기 쉬움
    하지만 Rust는 타입 시스템 덕분에 더 낫다고 생각함
    다만 Rust는 빠르게 변해서 LLM이 최신 API를 따라가기 어려움
    Haskell은 느린 변화 속도와 안전한 코드 덕분에 LLM에게 가장 유리함

    • Haskell로 생성된 코드는 Go보다 짧고 가독성이 높을 것 같음
      Python 스크립트도 비슷하게 읽기 쉬움

  • 매일 AI 코딩 에이전트와 일하는 입장에서, “최고의 언어”는 에이전트의 목적에 따라 달라짐
    Go의 단순성과 예측 가능성은 일반적인 작업에 좋지만, TypeScript는 웹 환경과의 연동에서 탁월함
    Python은 데이터/ML 영역에서 여전히 독보적임
    핵심은 LLM이 잘 다루는 언어보다, 에이전트의 도메인에 맞는 언어를 고르는 것임

답변달기