7개월 234커밋 바이브코딩 끝에 'Rust로 다시 짭니다' — k10s 개발자가 놓친 것, $350k ARR 개발자가 잡은 것

핵심 요약 (TL;DR)

GPU 대시보드 k10s 개발자가 7개월·234커밋 동안 Claude로 빌드한 코드를 전부 폐기하고 Rust로 다시 시작한다고 선언했습니다. 같은 도구로 솔로 SaaS $350k ARR을 굴리는 개발자도 있습니다. 차이는 도구가 아니라 가드레일이죠.

30주말의 청구서가 도착했다

5월 9일, blog.k10s.dev에 글 한 편이 올라왔습니다. 제목은 "I'm going back to writing code by hand". 작성자는 GPU 클러스터 운영자, 직업 자체가 시니어급인 사람입니다. 그가 2025년 9월 말부터 매주 주말마다 Claude로 빌드한 k10s — GPU-aware Kubernetes 대시보드. 234커밋, 30주말, 약 7개월의 작업이었습니다.

결과는 archive 처리. Rust로 처음부터 다시 쓴다는 결심이었죠. Hacker News 1면 1위에 올라 897점·557댓글이 달렸고, 같은 날 1면에 '바이브코딩 회의론'이 세 건 동시에 떴습니다. 우연이 아니라 7개월짜리 청구서가 한꺼번에 도착한 시점이었던 거예요. (원문: blog.k10s.dev/im-going-back-to-writing-code-by-hand)

그가 보여준 코드는 어떤 모습이었나

숫자만 봐도 충격적입니다. 단일 Model 구조체에 필드가 35개 이상. UI 위젯, K8s client 상태, view별 상태, navigation history, caching, mouse handling이 한 덩어리로 묶여 있었습니다. 메인 Update() 함수는 500줄, switch/case가 110개 이상. model.go 한 파일이 1,690줄이었죠.

상태 누수를 막으려고 코드 곳곳에 nil 할당이 9개 박혀 있었고, 그래도 1% 확률로 데이터 레이스가 나서 화면이 깨졌습니다. Fleet view를 추가하자 본인 표현으로 "the god object had consumed itself" — 빈 테이블이 렌더링되고, stale 데이터가 떠다니고, display state가 망가지기 시작했습니다.

그의 결론은 한 줄로 요약됩니다. "AI builds features, not architecture." AI에게 운전대를 넘기면 가장 저항이 적은 길로 간다. 그 길 끝에 god object가 있더라, 라는 진단이죠. 시니어 인프라 운영자가 보낸 자기 부고라서 더 무겁습니다.

같은 도구로 $350k ARR을 굴리는 사람

흥미로운 건 그 글에 달린 1위 댓글이었습니다. 닉네임 senordevnyc. "나는 같은 Claude로 솔로 SaaS를 $350k ARR로 운영 중이다." 자기진술이라 액수 검증은 불가능합니다. 하지만 그가 제시한 가드레일은 검증할 수 있는 종류죠.

네 가지였습니다. 첫째, plan mode — 코드를 짜기 전에 AI에게 계획부터 받아서 사람이 승인한다. 둘째, 태스크당 scope 제한 — 한 번에 한 변경, 컨텍스트가 부풀지 않게. 셋째, 중요도별 코드 리뷰 — 모든 라인을 똑같이 보지 않고, 위험한 영역은 사람이 직접. 넷째, 의도적 아키텍처 설계와 정기 리팩터 — 구조는 AI가 아니라 본인이 설계, 매 N주 한 번씩 정리.

k10s 개발자가 한 일과 비교해보면 정확히 반대입니다. plan mode 없이 바로 빌드, scope를 한 번에 풀어버린 god object, 리뷰 없이 머지된 234커밋, 아키텍처는 AI가 가장 저항이 적은 길로 결정. 같은 도구가 어떤 사람한테는 $350k ARR을 주고, 어떤 사람한테는 7개월짜리 archive 청구서를 내놓는 거예요.

가드레일은 의지가 아니라 시스템이다

여기에 두 가지 함정이 있습니다. 하나는 "vibe coding은 안 된다"는 결론. 다른 하나는 "나는 senordevnyc처럼 가드레일을 잘 지키니까 괜찮다"는 자신감. 둘 다 위험합니다.

k10s 개발자는 시니어 인프라 운영자였고, 자기가 god object를 만들고 있다는 걸 알면서도 7개월 동안 멈추지 못했습니다. "다음 주말에 정리하자"가 서른 번 반복됐을 거예요. AI가 빠르게 기능을 추가해줄수록 리팩터 부채는 더 빨리 쌓이고, 어느 순간 정리 비용보다 폐기 비용이 싸지는 변곡점이 옵니다.

가드레일은 의지가 아닙니다. 시스템이어야 합니다. 매 PR 전 plan mode 강제, 한 번에 변경되는 파일 수 제한, 1,500줄 넘어가면 자동 경고, 매 N커밋마다 아키텍처 리뷰 — 이런 식으로 본인의 의지가 약해지는 지점을 도구로 막아야 한다는 뜻이죠.

질문은 이겁니다. 지금 당신의 사이드프로젝트에서, AI가 가장 저항이 적은 길로 가는 걸 막아주는 시스템이 몇 개 켜져 있나요? 그 답이 0이라면, 당신은 7개월 안에 k10s 길에 들어설 가능성이 매우 높습니다.

FAQ

Q. 7개월 작업을 통째로 폐기하는 게 정말 합리적인가요?
A. 본인 판단입니다. k10s 개발자는 god object 위에 새 기능 하나 추가할 때마다 1% 데이터 레이스가 다른 곳에서 터지는 상태였습니다. 디버깅 시간이 빌드 시간을 넘어가는 변곡점이 오면, 폐기가 더 싼 선택이 되죠.

Q. AI 코딩을 그만두라는 결론인가요?
A. 아닙니다. senordevnyc는 같은 도구로 $350k ARR을 운영 중이라고 말합니다. 메시지는 "도구를 바꾸라"가 아니라 "가드레일을 시스템으로 만들어라"에 가깝습니다.

Q. 1인 개발자가 plan mode·scope 제한·정기 리팩터를 다 지키는 게 현실적인가요?
A. 다 지키지 않아도 됩니다. 네 가지 중 가장 약한 하나만 골라 이번 주에 도입해보세요. plan mode 강제가 도입 비용이 가장 낮은 편입니다. 한 줄짜리 prompt 템플릿으로도 시작할 수 있거든요.