본문으로 건너뛰기
피드

AI 바이브 코딩에 Go를 쓰는 이유 — Rust도 Python도 아닌

backend 약 6분

AI가 코드의 90%를 쓰는 바이브 코딩 시대에 Go가 최적의 언어라는 주장. Python은 안전장치가 없고, Rust는 언어 자체의 문제까지 인간에게 떠넘기지만, Go는 중요한 것만 잡고 비켜준다는 논리. 실제로 한 세션에 3도메인 풀스택 블로그를 7커밋으로 완성한 사례 제시.

  • 1

    Python은 타입 안전성 부재로 AI 생성 코드의 버그가 프로덕션까지 그대로 감

  • 2

    Rust는 빌림 검사기가 AI 코드와 충돌, 인간의 미적 감각 예산을 라이프타임 어노테이션에 낭비하게 만듦

  • 3

    Go의 5단계 필터(컴파일러→타입→에러처리→단순성→인간)로 인간은 최상위 판단에만 집중 가능

  • 4

    한 세션에 3도메인 블로그 완성: 7커밋, 테스트 실패 0건, 바이너리 1개, 배포 스크립트 30줄

Python: "실행된다"는 건 품질 기준이 아님

  • 타입 안전성이 사실상 없음. 타입 힌트는 선택사항이고, 선택사항이라는 건 없는 거나 마찬가지임
  • AI가 하루에 4,000줄 쓰면 전부 "실행"은 됨. 근데 그 안에 딕셔너리 키 오타, None이 함수 3개를 관통해서 전파되는 버그가 숨어 있음
  • 버그가 프로덕션에서 터짐. AI가 못 써서가 아니라, AI와 프로덕션 사이에서 "안 돼"라고 말해주는 게 아무것도 없기 때문임
  • mypy? strict 모드로 100% 커버되는 Python 프로젝트를 본 적이 없다는 거임. 대부분 20%만 커버하고 나머지 80%는 Any
  • 프로토타이핑이 빠른 것과 프로덕션 장애가 빠른 것은 같은 속성이라는 냉정한 지적

Rust: 맞는 말만 하는데 너무 많이 함

  • 빌림 검사기는 진짜 버그를 잡음. 타입 시스템도 엄격함. 컴파일러가 "안 돼"라고 할 때 틀린 적이 없음
  • 문제는 컴파일러가 너무 자주 "안 돼"라고 한다는 것
  • AI가 생성한 Rust 코드에 빌림 검사기가 싸움을 걸면, 인간의 "미적 감각 예산(taste budget)"을 아키텍처 대신 라이프타임 어노테이션에 써야 함
  • .clone() 추가, Arc<Mutex<>> 래핑 같은 건 언어가 만든 문제를 인간이 해결하는 꼴임

Rust의 비동기 세금

  • Go는 go func() 한 줄이면 끝. goroutine으로 HTTP 핸들러, NATS 컨슈머, 파일시스템 워처, SSE 스트림 전부 다 돌림
  • Rust는 tokio를 골라야 하고, 모든 크레이트가 tokio 호환인지 확인해야 함. 하나가 async-std 쓰면 런타임이 2개가 됨
  • Pin<Box<dyn Future>>, Arc<Mutex<>> 같은 걸 AI한테 설명하느라 인간의 주의력을 낭비하게 된다는 거임

Rust 생태계의 취약성

  • 3개월 뒤에 돌아와서 cargo update 돌리면 들어본 적도 없는 크레이트의 트레이트 바운드가 바뀌어서 빌드가 깨짐
  • Go의 하위 호환성 약속은 진짜임. 2024년에 고른 의존성이 2026년에도 컴파일됨. 언어, 표준 라이브러리, 생태계 문화 전반에서 하위 호환성을 진지하게 지킴

Go의 5단계 필터 프레임워크

저자가 제시하는 "기계와 프로덕션 사이의 5단계":

  1. 컴파일러: 타입 불일치, 미사용 임포트 등 명백한 오류 포착. 싸고 즉각적임
  2. 타입 시스템: 구조적 오류 포착. 함수가 WikiLinkResolver를 기대하는데 func(string) string을 넘기면 잡아냄
  3. 명시적 에러 처리: if err != nil을 파일당 400번 씀. Go에는 except: pass가 없으니 AI도 에러를 반드시 처리해야 함
  4. 강제된 단순성: 루프 방식 하나, 포맷 방식 하나. AI가 균일한 코드를 생성할 수밖에 없어서 인간이 한눈에 읽을 수 있음
  5. 인간: 가장 비싼 레이어. "다크 모드 대응해", "커버 상단이 잘렸어" 같은 다섯 단어짜리 교정만 하면 됨

핵심은 Go가 1~4단계에서 걸러낼 건 다 걸러주니까, 인간은 5단계에만 집중하면 된다는 것. Python은 전부 인간한테 보내고, Rust는 인간의 문제 + 언어 자체의 문제까지 같이 보낸다는 비교임.

실전 증명: 한 세션에 풀스택 사이트 완성

  • 3개 도메인 라우팅, 애니메이션 비디오 커버, 오디오 플레이어, 다크 모드, RSS 피드, 소셜 카드, 라이트박스까지 갖춘 블로그
  • 7 커밋, 테스트 실패 0건, 바이너리 1개
  • 배포 스크립트 30줄: go buildscpsystemctl restart. 끝임
  • Python이면 virtualenv나 Docker 필요하고, Rust면 400개 크레이트 다운로드에 빌드 4분 걸림
  • Go는 바이너리 하나 복사하면 끝. COPY binary /usr/local/bin/ 한 줄임

결론: Go는 최고의 언어가 아니라 최고의 필터

"기계가 코드의 90%를 쓸 때, 언어는 쓰는 도구가 아니라 잡아내는 도구임"

  • Python은 아무것도 안 잡음
  • Rust는 문제가 아닌 것까지 전부 잡음
  • Go는 중요한 것만 잡고 비켜줌

컴파일러가 바닥, 인간이 미적 감각, 바이너리가 증거라는 깔끔한 정리임.

언어를 '쓰는 도구'가 아닌 '잡아내는 도구'로 재정의한 관점이 흥미로움. AI 코딩 시대에 언어 선택 기준이 표현력에서 필터링 능력으로 이동하고 있다는 시사점.

댓글

댓글

댓글을 불러오는 중...

backend

Cloudflare가 잡아낸 QUIC CUBIC 버그, ‘idle’ 한 줄 오판이 다운로드를 죽였다

Cloudflare의 QUIC 구현체 quiche에서 CUBIC 혼잡 제어가 최소 윈도우에 갇혀 회복하지 못하는 버그가 발견됐다. Linux 커널의 idle 최적화를 QUIC에 옮기는 과정에서 TCP와 QUIC의 이벤트 타이밍 차이를 놓쳤고, 결국 ACK 시점을 기준으로 idle 시간을 재도록 고쳐 100% 테스트 통과를 회복했다.

backend

삼성전자가 반도체 개발 조직에 오라클 자바를 공식 채택한 이유

삼성전자 DS 부문이 글로벌 반도체 개발 환경에 오라클 자바 SE 유니버설 서브스크립션을 공식 채택했다. 서로 다른 자바 배포판과 버전이 섞이면서 생길 수 있는 보안, 컴플라이언스, 라이선스 리스크를 줄이고 개발 환경을 표준화하려는 결정이다.

backend

네이버클라우드, 트래픽 따라 알아서 줄고 느는 서버리스 데이터베이스 출시

네이버클라우드가 사용량에 따라 CPU, 메모리, 스토리지를 자동 조절하는 완전관리형 서버리스 데이터베이스 서비스를 내놨다. 기존 가상머신 기반 관리형 데이터베이스처럼 피크 트래픽에 맞춰 서버를 과하게 잡아두는 방식에서 벗어나, 사용량 기반 과금과 오토스케일링으로 비용 낭비를 줄이겠다는 방향이다.

backend

네이버클라우드, 사용량 따라 늘고 줄어드는 서버리스 데이터베이스 출시

네이버클라우드가 완전관리형 서버리스 데이터베이스 서비스인 Cloud DB Serverless를 출시했다. VM 기반 관리형 데이터베이스의 고정 비용과 과잉 프로비저닝 문제를 줄이고, 트래픽에 따라 CPU·메모리·스토리지를 자동 조절하는 구조를 내세운다.

backend

네이버클라우드, 사용량 따라 자동 확장되는 서버리스 데이터베이스 출시

네이버클라우드가 사용량에 따라 컴퓨팅 자원을 자동 조절하는 서버리스 기반 클라우드 데이터베이스를 출시했음. 기존 가상머신 기반 관리형 데이터베이스의 고정 비용과 운영 부담을 줄이고, 국내 데이터 규제 요구까지 맞추겠다는 전략임.