---
title: "AI 바이브 코딩에 Go를 쓰는 이유 — Rust도 Python도 아닌"
published: 2026-03-22T23:16:13.000Z
canonical: https://jeff.news/article/893
---
# AI 바이브 코딩에 Go를 쓰는 이유 — Rust도 Python도 아닌

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

## 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 build` → `scp` → `systemctl restart`. 끝임
- Python이면 virtualenv나 Docker 필요하고, Rust면 400개 크레이트 다운로드에 빌드 4분 걸림
- Go는 바이너리 하나 복사하면 끝. `COPY binary /usr/local/bin/` 한 줄임

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

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

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

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

## 핵심 포인트

- Python은 타입 안전성 부재로 AI 생성 코드의 버그가 프로덕션까지 그대로 감
- Rust는 빌림 검사기가 AI 코드와 충돌, 인간의 미적 감각 예산을 라이프타임 어노테이션에 낭비하게 만듦
- Go의 5단계 필터(컴파일러→타입→에러처리→단순성→인간)로 인간은 최상위 판단에만 집중 가능
- 한 세션에 3도메인 블로그 완성: 7커밋, 테스트 실패 0건, 바이너리 1개, 배포 스크립트 30줄

## 인사이트

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