H100 안 쓰고 0.44달러로 ML 실험 25회 — 바이브 코딩이 실험 파이프라인을 바꾼 방법

바이브 코딩 하면 웹 앱 프로토타이핑이나 CRUD 자동화를 먼저 떠올리잖아요. 로보코의 serverless-autoresearch 저장소는 그 프레임을 훨씬 넓혀요. Andrej Karpathy의 autoresearch가 전제하는 "H100 하나를 몇 시간 붙잡아 두는" 방식 대신, AWS SageMaker Spot 위에서 병렬 실험을 짧게 폭발적으로 실행하는 구조를 만들었거든요.

이 사례가 흥미로운 건 결과만 싸게 나왔기 때문이 아니에요. 저장소에 처음 아이디어를 다듬는 심층 인터뷰, 계획 중심의 아키텍처 설계, 클라우드 인프라 디버깅, 반복 실험의 자동화, 실패를 문서와 스킬로 환원하는 과정이 모두 남아 있어요. 특히 `docs/vibe-coding-tutorial`은 코드 설명서가 아니라 대화형 AI 코딩이 실제로 어떻게 엔지니어링 산출물로 굳어지는지 보여주는 로그에 가깝더라고요.

숫자부터 정리할게요. 튜토리얼 기준 2026년 3월 27-28일 초기 실행 구간에서 25회 실험, 총 비용 0.44달러, 최고 val_bpb 1.0643. 저장소 README는 이후 확장된 그림으로 83회 실험을 약 3.5시간, 약 1.33달러에 수행하는 방향을 제시하면서 원래의 순차 실행 대비 2.3배 빠르고 5-18배 저렴하다고 해요. "0.44달러"는 초기 검증 비용이고 "1.33달러"는 확장된 운영 모델의 비용. 충돌하는 숫자가 아니라 서로 다른 단계의 결과예요.

GPU를 오래 붙드는 대신 짧게 폭발시키는 HUGI 패턴

Karpathy의 원본 autoresearch는 한 번에 하나의 실험을 돌리며 H100 같은 고성능 GPU를 오래 점유하는 흐름이에요. serverless-autoresearch는 이 흐름을 병렬 진화(parallel evolution)로 바꿨어요.

핵심은 두 가지. 실험 하나를 오래 붙드는 대신 여러 후보를 동시에 짧게 실행한다. GPU를 24시간 켜 두는 대신 필요할 때만 Spot 인스턴스를 띄우고 끝나면 바로 내린다. 이 저장소는 이걸 HUGI(Hurry Up and Get Idle) 패턴이라고 불러요. 서버를 오래 유지하는 대신 짧게 몰아서 계산하고 곧바로 유휴 상태로 돌아가는 방식. 이 단순한 전환이 비용 구조를 완전히 바꿔요.

구체적으로 보면요. 초기 성공 실험에서 L40S Spot에서 첫 end-to-end 성공, 비용 $0.06. 배치 크기 함정 검증에서 4회 병렬 실험으로 잘못된 가설 제거, $0.07. 5세대 자율 진화에서 20회 실험으로 최적 파라미터 탐색, $0.31. 합계 25회 실험에 $0.44.

이 프로젝트의 포인트는 "저렴한 GPU로도 돌아간다"가 아니에요. 값싼 실패를 많이 살 수 있다는 데 있어요.

"autoresearch 재현하고 싶다"에서 시작된 심층 인터뷰

튜토리얼의 첫 장면은 코드가 아니라 질문이에요. 사용자가 "autoresearch 실험을 재현하고 싶다"는 요청과 함께 필요하면 심층 인터뷰를 하라고 지시했고, 그 결과 목표가 재정의됐어요. SageMaker Managed Spot Training 기반 서버리스 실행, OMC 기반 자율 반복 실험, 교육용/데모용으로 재사용 가능한 문서화.

작아 보이지만 매우 중요한 전환이에요. 막연한 "재현"은 종종 원본을 흉내 내는 데 그치거든요. 인터뷰를 거치면 "무엇을 배울 것인가", "무엇을 자동화할 것인가", "무엇을 남길 것인가"가 명확해져요. 바이브 코딩은 프롬프트를 길게 쓰는 기술이 아니라 좋은 문제 정의를 끌어내는 인터뷰 기술에 가깝다는 거죠.

두 번째 장에서 AI는 곧바로 코드를 쓰지 않아요. 상위 autoresearch 코드베이스와 기존 SageMaker 패턴을 탐색한 뒤, 후보 생성기, 배치 런처, 결과 수집기, 선택 모듈로 나뉜 파이프라인 구조를 계획해요. 중간에 사용자가 "클라우드의 장점인 병렬 실행과 HUGI를 적극 활용하라"는 조건을 추가하자 설계가 순차 실행에서 population-based parallel evolution으로 바뀌었고요. 이 세션에서 23개 파일이 만들어졌고 `make dry-run`으로 전체 경로를 검증. 중요한 건 생성 속도보다 생성 전에 구조가 합의됐다는 점이에요.

인프라 문제는 "코드 다 된 뒤에 해결할 일"이 아니다

세 번째 장이 이 프로젝트의 백미. 코드는 준비됐는데 AWS 인프라가 발목을 잡아요. GPU Spot 할당량은 기본값이 0이고, 리전마다 Spot 가용성도 극단적으로 달라요.

가장 실전적인 교훈은 `aws ec2 get-spot-placement-scores`예요. 같은 g7e 계열 인스턴스도 us-west-2에서는 점수 1-2로 거의 잡히지 않지만 us-east-1에서는 점수 9로 빠르게 할당돼요. 많은 팀이 여기서 시간을 허비해요. 인프라 문제를 "코드가 다 된 뒤에 해결할 일"로 보니까. 근데 이 저장소는 반대로 말해요. 어느 리전을 쓸지, 어떤 인스턴스를 쓸지, 할당량이 얼마나 빨리 승인되는지가 곧 파이프라인 설계의 일부라고.

GPU 유형에 따른 승인 차이도 눈에 띄어요. g7e는 비교적 빠르게 승인되지만 p5나 p6는 수동 심사로 며칠씩 걸릴 수 있대요. 이런 지식은 코드 안에 드러나지 않거든요. 문서화와 운영 메모리가 중요해지는 이유.

DEVICE_BATCH_SIZE를 키우면 학습이 더 되는 게 아니다

네 번째와 다섯 번째 장은 "싼 실험"의 진짜 의미를 보여줘요. 첫 성공 실험에서 L40S는 Flash Attention 3를 제대로 지원하지 않아 런타임 CUDA 에러를 냈고, GPU capability를 명시적으로 체크해 PyTorch SDPA로 폴백하는 로직이 들어갔어요. 이 수정으로 돌아가긴 했는데 MFU는 H100 대비 절반 수준인 약 20.5%에 머물렀어요.

여기서 끝나지 않아요. 다음 실험에서 VRAM이 남아 있으니까 `DEVICE_BATCH_SIZE`를 키우면 좋아질 것 같았는데, 결과는 오히려 나빠졌어요. 이유는 총 토큰 수가 늘지 않은 채 gradient accumulation만 줄었기 때문. ML 팀이 실제로도 자주 헷갈리는 포인트예요. GPU 메모리를 더 썼다고 해서 학습이 더 많이 된 건 아니거든요. (솔직히 저도 한번쯤 같은 실수를 했어요.)

이 프로젝트는 그런 오해를 값싸게 검증해요. 큰 예산이 들어가는 H100 실험에서 같은 실수를 반복했다면 훨씬 비쌌을 거예요.

자율 진화 단계에서 가장 흥미로운 결과는 화려한 아키텍처 변경이 아니라 보수적인 학습률 조정이 가장 잘 먹혔다는 점. `EMBEDDING_LR`과 `SCALAR_LR`의 작은 변경은 개선으로 이어졌지만, `DEPTH` 증가, `TOTAL_BATCH_SIZE` 확대, `WINDOW_PATTERN` 변경 같은 중간 규모 이상의 개입은 대부분 악화되거나 타임아웃으로 끝났어요.

이 패턴이 중요한 이유가 있어요. 짧은 5분 훈련 예산에서는 복잡한 구조 변경이 수렴할 시간을 얻지 못하거든요. 이 환경에서의 AI 에이전트는 "대담한 발명가"보다 "작은 수치를 집요하게 조정하는 운영자"일 때 더 강해요. 바이브 코딩이 늘 창의적 도약을 만드는 게 아니라 짧은 피드백 루프 안에서 작은 개선을 빠르게 누적시키는 데 강하다는 뜻.

실패를 스킬로 환원하면 다음 세션의 품질이 올라간다

이 저장소가 특히 좋은 이유는 마지막 처리 방식이에요. 실험이 끝난 뒤 결과를 요약하는 데서 멈추지 않고, `docs/insights.md`에 12개 인사이트를 정리한 뒤 이를 Claude Code용 재사용 스킬로 연결해요.

담긴 내용이 단순 메모가 아니에요. 리전마다 Spot 점수가 극단적으로 다르다. 작은 인스턴스가 항상 더 싼 건 아니다. `DEVICE_BATCH_SIZE`는 처리량이 아니라 VRAM 사용량에 더 가깝다. 저렴한 Spot GPU는 비싼 H100 훈련 전 가설 검증용 프록시로 충분히 쓸 수 있다.

잠깐 딴 얘기인데, 많은 팀은 AI와의 세션이 끝나면 배운 걸 잊어버려요. 근데 잘하는 팀은 실패를 문서로 만들고, 문서를 다시 스킬과 규칙으로 바꿔요. 그러면 다음 세션의 품질이 올라가죠. 생산성의 원천이 모델 자체가 아니라 축적되는 운영 지식이 되는 거예요. 다시 본론으로 오면, 이게 바로 serverless-autoresearch가 보여주는 바이브 코딩의 성숙도예요.

결국 이 프로젝트의 핵심 메시지는 단순해요. 바이브 코딩은 엔지니어링을 대체하지 않아요. 대신 엔지니어링의 중심을 직접 타이핑하는 일에서 질문하고, 설계하고, 실험하고, 교훈을 축적하는 일로 옮겨요. 그 이동이 실제로 어떤 모습인지 — "AI가 코드를 써 줬다"보다 훨씬 흥미로운 장면이 이 저장소에 남아 있어요. AI와 함께 실험 시스템 자체를 설계한 과정이니까요.