본문으로 건너뛰기
피드

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

backend 약 6분
vote
0
댓글
북마크

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

잘못된 추상화보다 중복이 낫다는 샌디 메츠의 고전 조언

샌디 메츠는 중복을 없애려다 잘못된 추상화를 만들면 코드가 조건문과 파라미터로 부풀어 더 위험해진다고 말한다. 이미 틀어진 추상화는 억지로 보존하지 말고, 다시 호출부에 인라인해서 중복을 되살린 뒤 현재 요구사항에 맞는 새 구조를 찾는 편이 빠르다는 주장이다.

backend

리눅스 커널, 6년·360개 넘는 패치 끝에 strncpy 제거

리눅스 커널이 오랫동안 버그의 원인이던 strncpy API 사용을 Linux 7.2에서 제거했어. NUL 종료 동작이 직관적이지 않고 불필요한 zero-fill로 성능 문제도 있던 API를 6년 동안 약 362개 커밋으로 걷어낸 작업임.

backend

덕디비는 왜 빠를까: 서버 없는 분석 엔진의 내부 구조 뜯어보기

DuckDB가 단일 바이너리, 인프로세스 실행, 컬럼형 저장, 최적화 패스, Parquet 푸시다운으로 빠른 분석 쿼리를 처리하는 방식을 깊게 설명한 글이다. 6GB Parquet 파일을 노트북에서 바로 SQL로 읽는 경험 뒤에 어떤 설계가 깔려 있는지 따라간다.

backend

피지독, 포스트그레스를 수평 확장시키겠다고 550만 달러 투자 유치

피지독은 포스트그레스 앞단에 프록시를 두고 샤딩과 라우팅을 처리해 수평 확장을 가능하게 하겠다는 오픈소스 프로젝트다. 이미 프로덕션에서 초당 200만 건이 넘는 쿼리를 처리하고, 확인된 규모만 20테라바이트 이상을 샤딩했다고 밝히며 550만 달러 투자를 공개했다.

backend

펜타시스템, EDB 포스트그레SQL로 국내 엔터프라이즈 DB 전환 시장 공략

펜타시스템테크놀러지가 EDB와 파트너 계약을 맺고 국내에 EDB 포스트그레SQL 기반 데이터 플랫폼을 공급한다. 기존 상용 DBMS 정책 변화로 비용 부담이 커진 기업들을 겨냥해, 오픈소스 기반 엔터프라이즈 데이터 플랫폼 전환 수요를 잡겠다는 전략이다. 금융, 공공, 제조, 유통, 클라우드, AI 데이터 분석 환경까지 적용 범위를 넓히려는 움직임이다.