본문으로 건너뛰기
0
r/jeffnews HN 약 6분

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

backend

요약

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

기사 전체 정리

AI가 코드의 90%를 쓰는 시대, Go가 바이브 코딩 최적의 언어라는 주장

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는 중요한 것만 잡고 비켜줌

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

핵심 포인트

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

인사이트

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

댓글

댓글

댓글을 불러오는 중...

backend

Redis 8.0 출시 — I/O 스레딩 갈아엎고 처리량 3배, 2.1M ops/sec 달성

Redis 8.0이 I/O 스레딩 모델을 완전히 재설계해서 16코어 기준 2.1M ops/sec를 달성함 (7.4 대비 3배). Hash field expiration, Vector search HNSW, Client-side caching v2, Redis Functions 2.0 async 실행 등 굵직한 기능이 추가되고, jemalloc 통합으로 메모리 fragmentation도 25% 줄어듦.

backend

Go 1.26의 타입 생성(Type Construction)과 순환 감지(Cycle Detection) 개선

Go 1.26에서 타입 체커의 타입 생성 알고리즘을 개선해 재귀 타입과 배열 크기 계산 시 발생하던 순환 감지 문제를 체계적으로 해결했다. 불완전한 값이 다운스트림으로 퍼지기 전에 업스트림에서 차단하는 새로운 접근법으로 여러 컴파일러 패닉을 수정.

backend

Cloudflare Gen 13 서버: 캐시를 코어로 바꿔 성능 2배 달성한 이야기

Cloudflare가 AMD Turin 9965(192코어) 기반 Gen 13 서버를 배포함. 코어당 L3 캐시가 6배 줄어 레거시 NGINX 스택(FL1)으로는 레이턴시 50% 악화가 불가피했으나, Rust로 전면 재작성한 FL2로 전환해 Gen 12 대비 처리량 2배, 성능/와트 50% 개선을 달성함.

backend

칩셋 레이턴시를 측정해봤더니 — 쓸모는 없지만 재밌는 실험

Vulkan GPU 벤치마크로 여러 세대 마더보드 칩셋의 PCIe 레이턴시를 측정한 실험. CPU 직결 대비 칩셋 경유 시 수백 ns 레이턴시가 추가되며, 의외로 2012년 Skylake Z170이 가장 낮은 추가 레이턴시를 보임.

backend

ForgeKV — Rust로 만든 멀티코어 Redis 대체제

Rust로 만든 Redis 드롭인 대체제. 64-샤드 잠금 아키텍처로 멀티코어 스케일링 지원. 2코어 환경에서 Redis 7 대비 41% 빠른 SET 처리량(158K ops/s). 고동시성에서는 약점 있음. Source-available 라이선스.