실전 가이드 · 4분 · 07.02

10만 줄 LLM 코드를 프로덕션급으로 만든 두 규율 — Sam Rose가 Kubernetes를 브라우저에 이식한 8주

loopy vibecoder

핵심 요약 (TL;DR)

ngrok의 Sam Rose가 8주 동안 약 10만 줄의 LLM 생성 코드로 Kubernetes를 브라우저에서 도는 시뮬레이터 Webernetes로 이식했습니다. API 비용 약 $4,300, 552 커밋, 629 파일, 2,059개 테스트(204 integration + 1,855 unit). 그가 코드 슬롭에 빠지지 않은 이유는 두 가지 규율입니다. "매 라인 리뷰"와 "실 클러스터와 동일 동작을 assert하는 하드 테스트".

무엇을 만들었나

Webernetes는 브라우저 안에서 Kubernetes가 완전히 도는 교육용 시뮬레이터입니다. 실제 컨테이너를 돌리는 게 아니라, 실 클러스터의 동작을 그대로 재현해서 학습자가 kubectl 명령을 실습할 수 있게 하는 목적이거든요. 이식된 컴포넌트는 무겁습니다. kubelet 바이너리 일부, pod scheduler, namespace controller, kube-proxy, deployment controller, CRI(container runtime interface), CNI(container network interface), Kubernetes API 클라이언트까지. Kubernetes 코어의 상당 부분이 웹 안에 들어간 겁니다.

숫자로 다시 보면 이렇습니다. 첫 커밋 4월 21일, 블로그 공개 6월 30일 — 정확히 8주. 552개 커밋, 629개 파일, 전체 파일 기준 약 126,642줄 중 LLM이 쓴 코드가 약 10만 줄. API 비용은 8주 총 약 $4,300, 마지막 주만 $1,811.64로 급증했어요. 도구는 Claude 세션과 Codex 세션을 병행했습니다.

규율 1: 매 라인 리뷰

Sam이 블로그에서 반복해서 강조한 문장이 있어요. "I reviewed every line of code." 10만 줄을 다 읽었다는 얘기입니다. 재밌는 건 그가 본업으로 풀타임 개발자가 아니라 Senior Developer Educator라는 점이에요. 개발자 교육 담당자가 인프라 소프트웨어 프로덕션급 코드를 리뷰했다는 뜻인 거죠.

같은 6월 30일 Godot Foundation이 AI 저자 코드 기여를 금지하면서 이런 말을 남겼습니다. "AI를 많이 쓰는 사람들이 자기 코드를 이해해서 고칠 만큼 신뢰할 수 없다." 이 말과 Sam의 "I reviewed every line"이 정확히 대칭입니다. 문제는 도구가 아니라 사용자가 리뷰 코스트를 감당할 의지가 있느냐인 거예요. Sam은 그 코스트를 자기 시간으로 정면 지불했고, 그 결과가 HN 325pts로 환영받은 이유입니다.

블로그의 유명해진 문장 하나 더. "My time was still the most expensive line item in the project." API 비용 $4,300이 아니라 본인 시간이 가장 비쌌다는 얘기예요. 반대로 말하면 시간을 진짜로 쓴다는 전제 아래서만 vibe coding이 프로덕션급으로 안착합니다.

규율 2: 실 동작을 assert하는 하드 테스트

두 번째 규율은 테스트예요. 최종 테스트 개수는 204 integration + 1,855 unit = 2,059개. 그런데 개수보다 종류가 중요합니다. Sam의 표현을 그대로 옮기면 "I created hundreds of tests that assert webernetes behaves the same as a real cluster." 실 Kubernetes 클러스터와 동일하게 동작하는지를 assert하는 테스트라는 거죠.

이게 왜 결정적일까요. LLM이 생성한 코드는 겉으론 그럴싸해도 semantic이 어긋나는 경우가 많거든요. 그런데 실 클러스터의 동작을 golden truth로 놓고 그것과 비교하는 테스트라면, LLM이 아무리 그럴싸한 코드를 뽑아도 semantic이 어긋나면 즉시 걸립니다. 다른 말로 LLM의 자유도를 실 시스템의 동작으로 옭아매는 거죠.

바이브코더가 지금 적용할 수 있는 것

첫째, 프로젝트 초반부터 "golden truth"를 정하세요. 무엇의 동작을 정답으로 놓을지. Sam에게는 실 Kubernetes 클러스터였어요. 웹앱이라면 기존 API 응답, 라이브러리 이식이라면 원본 라이브러리의 동작이 golden truth가 됩니다.

둘째, 테스트 개수보다 assert의 방향이 중요합니다. 2,059개 중 대부분(1,855개)이 유닛이었지만, 진짜 안전망은 204개 integration이었을 가능성이 큽니다. 클러스터 동작 assert가 여기서 나오거든요.

셋째, 리뷰 코스트를 예산에 반영하세요. Sam은 8주 내내 매 라인 리뷰에 시간을 썼습니다. 이걸 안 할 거면 LLM 사용량도 그만큼 줄여야 균형이 맞아요.

FAQ

Q. Webernetes는 실제로 컨테이너가 돌아가나요?
A. 아닙니다. 교육용 시뮬레이터라서 실 컨테이너 대신 Kubernetes 동작을 재현하는 방식이에요. 학습자가 kubectl 명령의 결과를 실 클러스터와 동일하게 관찰할 수 있는 게 목표입니다.

Q. $4,300으로 인프라 소프트웨어를 만들었다면 다른 프로젝트에서도 재현 가능한가요?
A. 조건이 붙습니다. 매 라인 리뷰할 시간이 있고, golden truth를 명확히 정의할 수 있는 도메인이면 가능성이 높아요. Sam도 본인 시간이 가장 비싼 항목이었다고 명시했습니다.

Q. Claude와 Codex를 왜 병행했을까요?
A. 정확한 이유는 공개되지 않았지만, 두 도구가 강한 영역이 조금씩 다르다는 게 실무자 사이의 공통된 관찰입니다. Sam은 토큰 사용 차트에 두 종류를 병기해 공개했어요.

마무리

Godot이 문을 닫은 것과 Sam이 성공한 것은 같은 코인의 앞뒷면입니다. 결국 리뷰 코스트를 누가 감당하느냐의 문제죠. 지금 LLM으로 큰 프로젝트를 굴리고 있다면 자신에게 물어보세요. 매 라인을 읽을 시간이 있는가, 그리고 무엇을 golden truth로 놓을 것인가.

소스 원문: Sam Rose의 ngrok 블로그 · Webernetes 저장소

0

댓글 0

아직 댓글이 없습니다