Serverless Autoresearch는 언제 통하고 언제 과한가 2026 – GPU 실험 파이프라인을 cron보다 싸게 굴리는 조건 5가지

Posted on by

GPU 실험을 자동화하려고 하면 처음엔 다들 비슷한 길로 간다.

작은 서버 하나 띄우고, Docker 올리고, cron으로 매시간 돌리고, 결과를 파일이나 S3에 쌓는다.

익숙하다. 설명하기 쉽다. 장애가 나도 대충 어디를 봐야 할지 안다.

문제는 GPU다.

CPU 서버는 하루 종일 켜둬도 그럭저럭 마음이 버티는데, GPU는 유휴 시간도 돈 냄새가 난다. 가만히 있어도 청구서가 숨을 쉰다. 운영자 입장에선 약간 기계가 아니라 월세집 같다.

그래서 ROBOCO의 serverless-autoresearch 사례가 흥미롭다.

이 프로젝트는 Karpathy의 autoresearch 아이디어를 AWS SageMaker Spot 위에서 짧고 병렬적인 실험 파이프라인으로 바꿨다.

핵심은 GPU를 오래 붙들고 있는 대신, 필요할 때만 띄우고, 짧게 몰아서 계산하고, 끝나면 바로 내리는 쪽이다.

ROBOCO 글은 이 패턴을 HUGI, 즉 Hurry Up and Get Idle이라고 부른다.

이 글은 그 사례를 그냥 “오, 싸다”로 끝내지 않고, TECHTAEK식 운영 판단표로 바꿔보는 글이다.

언제 이 방식이 통하고, 언제는 계속 켜둔 GPU 박스와 cron이 더 단순한지, 그 경계선을 보자.

먼저 결론

Serverless Autoresearch가 cron보다 싸게 먹히는 조건은 실험이 짧고, 실패해도 다시 시작 가능하고, 측정 지표가 숫자로 고정되어 있고, Spot 용량을 미리 확인할 수 있고, 결과를 문서와 스킬로 남기는 팀 일 때다.

반대로 실험이 오래 걸리고, 중간 상태가 복잡하고, 항상 GPU가 따뜻하게 떠 있어야 하고, 평가 지표가 주관적이라면 서버리스화는 운영비 절약이 아니라 디버깅비 증액 이벤트가 될 수 있다.

돈 아끼려다 사람이 타는 경우다. 이건 클라우드 최적화가 아니라 캠프파이어다.

cron과 serverless를 정확히 나누자

먼저 용어를 정리하자.

cron 자체는 비싸거나 싼 기술이 아니다. cron은 그냥 정해진 시간에 명령을 실행하는 스케줄러다.

여기서 비교하는 건 cron과 serverless가 아니라, 더 정확히는 아래 두 운영 방식이다.

구분 계속 켜둔 GPU 박스 + cron Serverless/Spot GPU job
실행 방식 GPU 인스턴스를 켜두고 cron이 주기적으로 실험 실행 필요할 때 SageMaker Training Job 같은 단위로 GPU를 띄움
비용 구조 실험하지 않는 시간에도 인스턴스 비용 발생 실행 시간과 대기 정책 중심으로 비용 발생
장점 단순함, 디버깅 쉬움, warm 상태 유지 유휴 비용 감소, 병렬 실험에 유리, job 단위로 기록 남김
약점 GPU idle 비용, 확장성 낮음 Spot 용량, quota, startup overhead, checkpoint 필요
맞는 상황 긴 실험, 상시 서비스, 디버깅 잦은 초기 세팅 짧은 반복 실험, batch job, 가설 검증, 병렬 탐색

그러니까 “cron은 구식이고 serverless가 최신” 이런 이야기가 아니다.

GPU 실험이 상시 점유형인지, 폭발형인지가 먼저다.

폭발형이면 serverless가 강하다. 상시 점유형이면 cron이 더 단순할 수 있다.

ROBOCO 사례에서 확인된 숫자

ROBOCO의 공개 글과 GitHub 문서를 같이 보면 숫자가 두 단계로 나온다.

초기 튜토리얼 구간은 2026년 3월 27일에서 28일 사이의 실행을 중심으로 25회 실험, 총 비용 0.44달러, best val_bpb 1.0643을 기록했다.

저장소 README의 확장된 운영 그림에서는 83회 실험을 약 3.5시간, 약 1.33달러에 수행하는 방향을 제시한다. 원래의 순차 실행 대비 더 빠르고 더 싸다는 메시지가 붙어 있다.

중요한 건 숫자 자랑이 아니다.

두 숫자는 서로 다른 단계다.

단계 실험 수 비용 읽는 방법
튜토리얼 검증 25회 약 $0.44 파이프라인이 실제로 돌아가는지 확인한 초기 실험
README 운영 모델 83회 약 $1.33 병렬 Spot job으로 확장했을 때의 비용 그림

이 사례의 진짜 메시지는 “무조건 0.44달러면 된다” 가 아니다.

싼 실패를 많이 살 수 있다 가 더 정확하다.

ML 실험에서 실패는 사라지지 않는다. 다만 실패 하나의 단가를 낮추면 더 많이, 더 빨리, 더 덜 아프게 배울 수 있다.

조건 1. 실험 하나가 짧고 재시작 가능해야 한다

Serverless Autoresearch의 첫 조건은 실험 단위가 짧아야 한다는 것이다.

ROBOCO 사례의 핵심 루프는 짧은 학습 예산 안에서 후보를 여러 개 띄워보고, 결과를 비교하고, 좋은 후보를 다음 baseline으로 넘기는 구조다.

AWS SageMaker Managed Spot Training 문서도 Spot은 중단될 수 있다고 설명한다. 그래서 긴 학습 job이라면 checkpoint를 쓰는 게 중요하다.

여기서 판단 기준이 나온다.

질문 예면 serverless 후보 아니면 주의
한 실험이 5분에서 15분 안에 의미 있는 결과를 내나? 좋음 startup overhead가 더 커질 수 있음
실패해도 같은 설정으로 다시 돌릴 수 있나? 좋음 state 복구가 어려우면 위험
결과가 파일/metric/job log로 남나? 좋음 사람 기억에 의존하면 안 됨
중단 시 checkpoint나 재시작 전략이 있나? 긴 job도 가능 없으면 Spot이 스트레스 제조기

짧고 stateless에 가까운 실험이면 GPU를 필요할 때만 깨우는 게 맞다.

하지만 8시간짜리 학습을 checkpoint 없이 Spot으로 던지는 건 절약이라기보다 운세 보기다.

조건 2. 평가지표가 하나 또는 두 개의 숫자로 닫혀야 한다

Autoresearch류 파이프라인은 측정 가능한 세계에서 강하다.

ROBOCO 예제도 val_bpb라는 숫자를 중심에 둔다. 각 실험 후보는 좋아졌는지, 나빠졌는지, timeout인지 표로 정리할 수 있다.

이건 단순해 보이지만 엄청 중요하다.

AI 에이전트가 실험을 반복하려면 비교 기준이 고정되어 있어야 한다. 기준이 흔들리면 자동화는 똑똑해지는 게 아니라 자신감 있는 랜덤 워크가 된다.

적합한 지표는 이런 것들이다.

도메인 좋은 지표 예시 애매한 지표 예시
LLM 학습 val loss, val_bpb, throughput “응답이 좋아 보임”
RAG recall@k, 정확도, latency “자료를 잘 찾는 느낌”
API 최적화 p95/p99 latency, error rate “좀 빨라진 듯함”
프롬프트 실험 eval score, pass rate “문장이 더 예쁨”

주관적 품질을 자동화하면 결국 사람이 다시 다 봐야 한다. 그럼 serverless가 아니라 server-more-work다.

말이 좀 짜증나지만 현실은 더 짜증난다.

조건 3. make dry-run 같은 검증 루프가 먼저 있어야 한다

ROBOCO 글에서 좋은 포인트는 단순히 23개 파일을 만들었다는 게 아니다.

그 뒤에 make dry-run으로 전체 경로를 먼저 검증했다는 점이다.

Serverless GPU job은 실행 실패의 위치가 넓다.

로컬 코드가 틀릴 수도 있고, Docker 이미지가 안 맞을 수도 있고, IAM role이 틀릴 수도 있고, S3 경로가 다를 수도 있고, quota가 없을 수도 있고, Spot 용량이 없을 수도 있다.

이 모든 걸 실제 GPU job에서 처음 발견하면 비용보다 시간이 더 아깝다.

그래서 최소한 아래 dry-run이 필요하다.

dry-run 항목 확인할 것
설정 파일 region, instance type, role ARN, S3 path가 비어 있지 않은가
데이터 경로 학습/검증 데이터가 같은 region에 준비되어 있는가
이미지/런타임 CUDA, PyTorch, driver, package version이 맞는가
job submit 실제 training job을 만들기 직전까지 API 호출이 가능한가
결과 수집 CloudWatch/S3/artifact에서 metric을 읽을 수 있는가

GPU job은 코드가 되나? 보다 경로가 이어져 있나? 가 더 먼저다.

경로가 끊기면 모델은 학습도 못 하고 사람은 분노만 학습한다.

조건 4. Spot 용량과 quota를 코드보다 먼저 봐야 한다

이 사례에서 가장 실전적인 부분은 Spot placement score다.

ROBOCO 문서에 따르면 같은 g7e 계열도 region에 따라 체감이 크게 달랐다. us-west-2에서는 job이 오래 걸렸고, us-east-1에서는 allocation이 훨씬 빨랐다는 식이다.

AWS CLI의 get-spot-placement-scores 문서도 Spot capacity request가 성공할 가능성을 1에서 10 사이 점수로 보여준다고 설명한다. 다만 이 점수는 보장값이 아니라 추천값이다.

여기서 운영 기준이 나온다.

코드를 다 짠 뒤에 region을 고르면 늦다.

처음부터 아래 순서로 봐야 한다.

  1. 후보 instance family를 정한다.
  2. 필요한 vCPU/GPU quota를 확인한다.
  3. Spot placement score를 region별로 본다.
  4. 데이터가 저장될 S3 region을 맞춘다.
  5. job이 stuck 되었을 때 넘길 fallback region을 정한다.

특히 새 GPU instance type은 기본 quota가 0인 경우가 있다.

이걸 모르고 파이프라인을 예쁘게 만들면 발행 전날 알게 된다.

코드는 완성됐고, 클라우드는 “권한 없는데요?”라고 한다. 이 순간 엔지니어의 표정은 대체로 모니터보다 어둡다.

조건 5. 실패를 문서와 스킬로 환원해야 한다

Serverless Autoresearch가 그냥 싸게 끝나는 실험이면 한 번 보고 지나갈 수 있다.

하지만 이 사례의 더 중요한 점은 실패가 문서로 남았다는 데 있다.

GPU capability 문제, Flash Attention fallback, batch size 착각, Spot region 문제, quota 문제, 학습률 조정의 효과 같은 것들이 docs와 insight로 정리됐다.

TECHTAEK 관점에서 이건 거의 핵심이다.

자동화는 반복 실행보다 반복 학습이 더 중요하다.

한 번의 싸구려 실험이 다음 실험을 더 싸게 만들려면 아래 산출물이 남아야 한다.

산출물 이유
results.tsv 어떤 변경이 이겼고 졌는지 보존
cost_report 실험당 비용과 대기 시간을 분리
insights.md 삽질을 다음 사람의 체크리스트로 변환
runbook.md region/quota/rollback 절차를 운영 문서화
skill 또는 agent rule 다음 AI 세션이 같은 실수를 반복하지 않게 함

이게 없으면 serverless 실험은 싸게 날린 불꽃놀이가 된다.

예쁘긴 한데, 다음 주에 아무것도 남지 않는다.

언제 cron 박스가 더 낫나

반대로 계속 켜둔 GPU 박스와 cron이 더 나은 경우도 있다.

이걸 인정해야 글이 쓸모 있다. 새로운 방식이 항상 이기는 척하면 그건 기술 글이 아니라 제품 광고다.

상황 serverless가 과한 이유
긴 학습 job이 대부분이다 startup, checkpoint, interruption 처리가 더 복잡해짐
항상 warm GPU가 필요하다 job 단위 cold start가 사용자 경험을 해칠 수 있음
실시간 inference와 training이 섞여 있다 training job abstraction이 맞지 않을 수 있음
데이터 이동량이 크다 S3 upload/download와 region migration 비용이 커짐
평가 지표가 주관적이다 자동 selection이 위험해짐
팀에 AWS/SageMaker 운영 경험이 없다 IAM, quota, logs, billing 디버깅 비용이 커짐

이런 경우엔 작은 GPU 서버 하나를 켜두고 cron으로 얌전히 돌리는 편이 낫다.

단순함도 성능이다.

운영에서 단순함은 꽤 자주 비용 절감보다 더 강하다.

5가지 조건을 한 장으로 정리하면

Serverless Autoresearch를 검토할 때는 아래 표를 먼저 보면 된다.

조건 통과 기준 실패 신호
1. 짧은 실험 5~15분 단위로 의미 있는 metric 발생 2시간 이상 돌려야 결과가 보임
2. 숫자 지표 val_bpb, loss, pass rate처럼 자동 비교 가능 사람이 매번 품질을 읽어야 함
3. dry-run make dry-run으로 데이터/권한/job submit 경로 확인 첫 GPU job에서 처음 디버깅
4. Spot/Quota placement score, quota, fallback region 사전 확인 region 정하지 않고 코드부터 작성
5. 지식 환원 results, cost, insights, runbook이 남음 실험 끝나고 슬랙 감탄만 남음

3개 이상 통과하면 serverless화 후보로 볼 만하다.

5개를 모두 통과하면 꽤 적극적으로 검토해도 된다.

2개 이하라면 일단 cron 박스가 나을 가능성이 높다.

내가 팀에서 바로 적용한다면

내가 이 패턴을 팀에 바로 붙인다면 처음부터 완전 자동화로 가지는 않을 것 같다.

첫 주에는 아래처럼 작은 파일럿으로 시작한다.

  1. 실험 대상 파일을 하나로 제한한다.
  2. metric을 하나로 고정한다.
  3. make dry-run을 먼저 만든다.
  4. Spot placement score를 3개 region에서 비교한다.
  5. 10회 실험만 돌리고 cost report를 만든다.
  6. 실패 3개를 insights.md에 남긴다.

이 정도만 해도 팀이 얻을 게 많다.

우리는 보통 “이 자동화가 가능한가?” 를 먼저 묻는다.

하지만 진짜 질문은 이거다.

이 자동화가 실패했을 때, 다음 실행이 더 똑똑해지는가?

Serverless Autoresearch는 이 질문에 꽤 좋은 답을 준다.

GPU를 싸게 쓰는 방법이기도 하지만, 실험 실패를 운영 지식으로 바꾸는 방법이기도 하다.

그래서 이 주제는 단순한 ML 인프라 글이 아니라 AI 개발 워크플로우 글이다.

함께 보면 좋은 글

FAQ

Q1. Serverless Autoresearch는 AWS SageMaker를 꼭 써야 하나?

꼭 그렇지는 않다.

핵심은 SageMaker라는 제품명이 아니라 짧은 job 단위, 자동 submit, 결과 수집, 비용 리포트, 유휴 GPU 비용 제거라는 운영 패턴이다.

다만 ROBOCO 사례는 SageMaker Managed Spot Training을 사용했기 때문에 그 문맥에서는 SageMaker와 AWS Spot score가 중요한 검증 포인트다.

Q2. cron으로도 GPU를 껐다 켰다 하면 비슷하지 않나?

일부는 비슷하게 만들 수 있다.

하지만 단순 cron은 job orchestration, result collection, retry, quota, artifact 정리, metric selection을 직접 구현해야 한다.

작은 팀에서는 그 직접 구현이 더 단순할 수도 있고, 반대로 실험 수가 늘면 managed training job 구조가 더 편할 수도 있다.

Q3. Spot은 중간에 끊길 수 있는데 실험용으로 괜찮나?

짧고 재시작 가능한 실험이면 괜찮은 편이다.

AWS 문서도 Spot training에서는 중단 가능성을 전제로 설명하고, 긴 job은 checkpoint를 쓰라고 안내한다.

그래서 5분짜리 후보 검증은 잘 맞지만, checkpoint 없는 긴 학습은 조심해야 한다.

Q4. 이 방식이 H100 학습을 대체할 수 있나?

대체라기보다 프록시에 가깝다.

L40S 같은 싼 Spot GPU에서 가설과 ranking을 먼저 좁히고, 최종 후보를 더 비싼 H100에서 확인하는 식이다.

싼 실험은 비싼 실험을 없애는 게 아니라 비싼 실험의 낭비를 줄인다.

Q5. 내 팀은 어디서부터 시작하면 되나?

가장 작은 시작점은 make dry-run, results.tsv, cost_report, insights.md 네 개다.

이 네 개가 없으면 serverless든 cron이든 실험 자동화가 지식으로 남기 어렵다.

공식 출처