GPU 셋업 2시간이 30분으로: Ralphthon @ICML 팀들이 VESSL Cloud로 하루 만에 논문 리뷰 AI를 만든 방법

핵심 요약

• Ralphthon @ICML에서 39편의 논문과 30개의 리뷰 에이전트가 연결돼 284개의 리뷰가 나왔고, 생성 속도가 빨라지자 병목은 평가와 판단이 되었습니다.
• Team SAIL은 VESSL Cloud의 H100 네 장으로 Qwen3-8B를 약 2시간 30분 학습한 뒤, L40S 한 장에 vLLM 멀티 LoRA와 별도 스코어 헤드 서비스를 얹어 약 4시간 동안 데모를 서빙했습니다.
• HypeAudit은 VESSL Cloud A100에 Qwen2.5-14B-Instruct를 올려 약 3~4시간 퍼블릭 추론 엔드포인트를 운영했고, 문제 정의부터 제출까지 실제 작업 시간은 약 4시간이었습니다.
• Team SAIL의 이유찬님은 기존에 쓰던 RunPod에서 매번 최소 2시간이 걸리던 환경 셋업이 VESSL Cloud에서는 30분 내외로 줄었다고 했습니다.
• VESSL Cloud는 국내 리전, 선언형 환경 구성, vesslctl 기반 에이전트 스케줄링으로 하루짜리 해커톤에서 환경 구축 시간을 아끼고 실험에 집중할 수 있었습니다.

이 글은 정구봉(팀 어텐션) 님이 작성하고 VESSL AI 팀이 편집했습니다.

한 팀은 Qwen3-8B를 튜닝하기 위해 H100 네 장을 썼습니다. 다른 한 사람은 AI 코딩을 시작한 지 두 달 반 만에 A100 위에 공개 연구 서비스를 올렸어요.

같은 랄프톤 행사에서 나온 두 결과물입니다.

저는 이 대비가 꽤 상징적이라고 느꼈습니다. AI가 연구를 생성하는 속도는 이미 매우 빨라졌어요. 이제 더 어려운 문제는 무엇을 믿고, 어디를 고치고, 누가 마지막 판단을 소유할 것인가에 가까웠습니다.

이번 랄프톤에서 베슬 클라우드(VESSL Cloud)는 그 판단을 대신하지 않았습니다. 대신 서로 다른 두 팀이 자신의 평가 철학을 실제 모델과 엔드포인트로 돌려볼 수 있는 실행층이 되어줬어요.

논문을 만드는 AI 다음에는, 논문을 의심하는 AI가 필요했어요

저는 "AI가 코딩을 정복했고, 다음은 리서치"라고 생각해서 Ralphthon @ICML의 주제를 Auto Research로 잡았습니다.

토론만 하고 싶지는 않았어요. Track 1의 AI Scientist는 실제 논문을 만들고, Track 2의 리뷰 에이전트는 그것을 ICML 리뷰 형식으로 읽게 했습니다. 이후 사람의 포스터 세션과 구두 발표를 붙여, 생성과 평가를 같은 하루 안에 부딪혀봤어요.

7월 12일 오후 4시 30분, 39편의 논문과 30개의 리뷰 에이전트가 연결되기 시작했습니다. 300건의 리뷰 배정이 이루어졌고 284개의 리뷰가 돌아왔어요.

숫자보다 흥미로웠던 것은 그다음이었습니다.

논문을 만드는 속도가 빨라지자, 사람들은 더 빠르게 판단해야 했어요. 그럴듯한 문장을 믿어도 되는지, 지적한 약점이 원문에 실제로 있는지, 반박문을 읽은 뒤 결정을 바꿔야 하는지, 점수 하나가 어떤 근거에서 나왔는지를 확인해야 했습니다.

두 참가자는 이 문제에 전혀 다른 답을 만들었습니다.

Team SAIL은 '제출 전에 거절당하는 시스템'을 만들었습니다

Team SAIL의 프로젝트 이름은 How to Get Rejected Before You Submit입니다.

제출 전에 Area Chair(학회에서 최종 채택 여부를 판단하는 영역 심사위원장) 스타일의 거절을 먼저 받아보고, 반박하고, 수정하고, 다시 평가받는 루프를 만들었어요. 좋은 말만 해주는 리뷰어가 아니라 연구자가 실제 제출 전에 약점을 드러내는 시스템을 만들고 싶었던 겁니다.

이유찬님은 전체 아키텍처와 Ralph 루프, 모델 학습을 이끌었습니다. 지훈님은 모델 학습과 디버깅, 아키텍처 보완과 서빙을 맡았고, 규현님은 OpenReview 데이터 수집과 정제, 데모 웹 인터페이스를 만들었어요. 역할은 나뉘었지만, 이유찬님의 표현을 빌리면 세 사람 모두 서로의 영역에 깊게 관여했습니다.

학습은 H100 네 장으로 2시간 30분, 서빙은 L40S 한 장으로 4시간

Team SAIL은 VESSL Cloud에서 Qwen3-8B를 파인튜닝했습니다.

데이터셋 전처리는 VESSL Cloud 밖에서 미리 끝내 Hugging Face에 올려두고, VESSL Cloud에서는 그 데이터셋과 모델을 불러와 학습에만 집중했어요. 짧은 시간 안에 결과를 보기 위해 H100 네 장을 사용했는데, 이미지 풀(pull)과 모델, 데이터셋 로드 같은 준비에 30분에서 1시간, 순수 학습에는 약 2시간 30분이 걸렸습니다.

데모 서빙은 전혀 다른 방식으로 압축했어요.

L40S 한 장에 Qwen3-8B 백본을 한 번만 올린 뒤, 요청마다 세 개의 LoRA 어댑터를 바꿔 끼웠습니다. 하나는 리뷰만 읽고 판정하고, 하나는 디스커션까지 읽고 판정하고, 다른 하나는 메타 리뷰를 생성했어요.

연속적인 랭킹 점수는 vLLM 안에서 만들지 않았습니다. 같은 GPU에 별도의 작은 스코어 헤드 서비스를 띄웠어요. 이 서빙은 학습 직후부터 행사 종료까지 약 4시간 동안 L40S 한 장으로 유지됐습니다.

결과적으로 /meta-review와 /score라는 두 엔드포인트가 데모에 연결됐습니다. 하나의 거대한 모델이 모든 역할을 흉내 낸 것이 아니라, 역할에 따라 어댑터와 서비스의 경계를 설계한 겁니다.

완벽하게 끝난 프로젝트는 아니었습니다.

히든 레이어의 피처를 사람이 이해할 수 있는 자연어 피드백으로 복원하려던 시도는 충분히 작동하지 않았고, 스코어 헤드도 원하는 만큼 활용하지 못했어요. 공개된 ICML 논문이 채택된 논문에 치우쳐 있어 점수 분포를 그대로 학습하기 어렵다는 문제도 남았습니다. 정규화와 스케일링이 다음 과제입니다.

저는 이 실패가 오히려 좋았습니다. 짧은 행사에서 만든 데모를 성공담으로 포장하는 대신, 무엇이 아직 연구 문제로 남았는지를 정확히 말해줬기 때문이에요.

왜 하루짜리 해커톤에서 셋업 시간이 승부를 갈랐을까요?

결론부터 말하면, 기존 클라우드에서 매번 최소 2시간 걸리던 환경 셋업이 VESSL Cloud에서는 30분 내외로 줄었습니다. 하루짜리 행사에서 이 차이는 실험을 한두 번 더 돌릴 수 있는 시간이에요.

이유찬님은 그동안 주로 쓰던 RunPod에서는 파드를 띄운 뒤 SSH로 접속해 의존성 설치, 모델과 데이터셋 다운로드, 환경변수 설정을 매번 수동으로 반복해야 했고, 작업을 시작할 때마다 셋업에만 최소 2시간이 걸렸다고 했어요.

VESSL Cloud에서는 이미지와 스토리지, 리소스를 한 번에 선언해 제출하는 방식이라 이 반복 작업 자체가 사라졌습니다. 같은 준비 과정이 30분 내외로 줄었어요.

가용성에서도 차이가 있었습니다. RunPod에는 국내 리전이 없어 필요한 GPU 사양을 한국에서 먼 리전에서, 그것도 물량이 빠듯한 상태로 찾아야 했어요. 새 파드를 띄울 때마다 데이터셋과 체크포인트를 옮기는 데만 최소 30분이 걸렸는데, 리전이 멀다 보니 이 전송 지연이 그대로 체감됐습니다. VESSL Cloud는 국내 리전을 쓸 수 있어 이 부담이 확실히 적었어요.

이유찬님은 안정성과 vesslctl을 통한 에이전트 스케줄링도 특히 좋게 봤다고 했습니다. AI 에이전트가 코드를 쓰는 데서 멈추지 않고 학습과 서빙 잡의 스케줄링까지 맡을 수 있었고, 셋업 과정 대부분을 터미널에서 바로 처리할 수 있었다는 거예요. 반면 모바일에서 로그를 확인하는 UI는 불편했다고 솔직하게 알려줬습니다. 제품을 실제 연구 흐름에 넣었기 때문에 나온, 꽤 유용한 피드백입니다.

"VESSL Cloud는 상당히 안정적이었고, 무엇보다 vesslctl로 에이전트에게 스케줄링을 맡길 수 있다는 점이 특장점으로 느껴졌습니다." — 이유찬, Team SAIL

HypeAudit은 네 시간의 실작업을, 탈락 뒤에도 계속 만들었습니다

정석원님은 컴퓨터공학 전공자가 아닙니다. 경영과 국제관계, 사업기획과 투자, 프로젝트 운영에 가까운 일을 해왔어요. Ralphthon 당시 직접 코드를 다룬 지는 약 두 달 반이었지만, 이미 Bluetron AI를 운영하며 모델을 서비스에 연결하는 일에는 익숙한 상태였습니다.

그런데 저는 이 배경보다 그가 맡은 역할이 더 흥미로웠습니다.

정석원님은 문제 정의, 평가 기준, 결과 검토, 실패 조건과 최종 의사결정을 직접 소유했습니다. ChatGPT와 Claude Code를 교차로 사용했지만, 무엇을 좋은 리뷰라고 부를지는 도구에 넘기지 않았어요.

HypeAudit의 출발점은 단순했습니다. LLM 리뷰어가 날카로워 보이기 위해 논문에 없는 결함을 만들어내면 안 된다는 것이었어요. 핵심 주장을 찾고, 비판을 원문의 근거에 다시 연결하고, 근거가 부족하다는 사실을 반대 주장이 참이라는 결론으로 바꾸지 않게 했습니다.

'약 네 시간'은 GPU 가동시간이 아니라 실작업 시간이었습니다

정석원님은 오후 1시 직전에 도착해 1차 제출까지 약 세 시간을 집중해서 작업했고, 이후 행사 진행이 지연된 시간에 PDF 처리와 완성도를 더 다듬었습니다.

식사와 휴식, 발표 대기 시간을 빼면 문제 정의부터 구현, 모델 서빙, 데모 연결, 리뷰 수행과 제출까지 실제 작업 시간은 약 네 시간이었어요. GPU 가동시간이 아니라, 결과물에 집중해서 쓴 실작업 시간입니다.

행사 버전은 VESSL Cloud A100에 Qwen2.5-14B-Instruct를 올리고 vLLM으로 서빙했습니다. 사용자가 PDF를 올리면 브라우저에서 리뷰를 받아볼 수 있는 퍼블릭 추론 엔드포인트를 만든 거예요. 오후 3시 전후에 모델을 올려 엔드포인트를 연결한 뒤, 오후 7시 전후 2차 선발 발표까지 약 3~4시간 동안 데모를 확인하고 개선했어요.

상세 검증 코어와 공개 데모의 경계는 의도적으로 나눴어요.

정석원님은 이미 Bluetron AI에서 DGX Spark 환경으로 Qwen 계열 모델을 다뤄온 터라 서빙 자체에는 익숙했습니다. 이번에도 VESSL Cloud에서 만든 엔드포인트를 Claude Code로 작업하던 애플리케이션에 연결했는데, 별다른 시행착오 없이 바로 정상 동작했어요.

"기존의 Qwen 모델 운영 경험 덕분에 시행착오를 줄일 수 있었고, VESSL Cloud에서 Qwen2.5-14B-Instruct를 vLLM으로 서빙한 뒤 퍼블릭 엔드포인트를 애플리케이션에 연결하는 과정도 빠르고 매끄럽게 진행됐습니다." — 정석원, HypeAudit

2차 선발에는 되들지 못했습니다.

하지만 정석원님은 집에 돌아가 다시 노트북을 열었어요. 행사 시간 안에 충분히 통합하지 못했던 PDF 원문, 인용, 페이지 위치 확인을 보완해 HypeAudit을 기존에 운영하던 Bluetron AI의 공개 실험 서비스로 계속 발전시켰습니다.

저는 이 장면이 Ralphthon의 결과를 꽤 잘 설명한다고 생각합니다. 선발은 하루 안에 끝나지만, 좋은 문제는 거기서 끝나지 않아요.

"하루짜리 행사에서는 환경 구축으로 잃는 한 시간이 실험 한 번과 같기 때문에, 바로 사용할 수 있는 GPU와 크레딧이 실제 완주에 도움이 됐습니다." — 정석원, HypeAudit

같은 GPU 클라우드로 얼마나 다른 연구가 가능할까요?

Team SAIL은 VESSL Cloud를 연구 시스템의 모델 레이어에 깊게 연결했습니다. 학습과 서빙을 나누고, 공유 백본과 여러 어댑터, 별도 스코어 서비스를 한 워크플로우 안에 맞췄어요.

HypeAudit은 다르게 선택했습니다. 감사 가능한 핵심 흐름은 분리해두고, 사람들이 결과를 직접 만져볼 수 있는 퍼블릭 추론 엔드포인트를 VESSL Cloud A100에 올렸어요.

한쪽은 복잡한 평가 루프를 실제로 돌리는 데 VESSL Cloud를 썼고, 다른 한쪽은 자신의 평가 철학을 다른 사람이 체험할 수 있는 엔드포인트로 바꾸는 데 썼습니다.

좋은 AI 인프라는 모든 연구를 같은 방식으로 만들지 않는다고 생각해요. 각 연구자가 자신의 문제에 맞는 경계를 선택할 수 있게 해야 합니다.

이번 행사를 위해 VESSL AI는 100개의 $15 크레딧과 별도의 A100 접근 경로를 준비했습니다. 행사를 운영한 제 입장에서 크레딧은 넉넉했고, 실제 연구와 모델 서빙에 잘 사용됐어요. 운영진이 "크레딧이 모자라니 실험을 줄여달라"고 말하지 않아도 됐다는 사실이 정말 컸습니다.

좋은 후원은 로고를 거는 일이 아니라고 생각합니다. 참가자가 가장 비싸게 치르는 제약을 없애는 일이에요. 하루짜리 연구에서 그 제약은 GPU 한 장의 가격만이 아니라, 환경을 붙잡고 있다가 잃어버리는 시간이었습니다. Team SAIL이 다른 클라우드에서 매번 셋업에 쓰던 두 시간이 30분으로 줄었다는 건, 하루 안에 실험을 한두 번 더 돌릴 수 있다는 뜻이기도 해요.

VESSL Cloud는 연구의 정답을 만들지 않았습니다. Team SAIL의 점수가 옳은지, HypeAudit의 비판이 공정한지는 결국 사람이 계속 검증해야 해요.

대신 사람의 판단이 노트북 안에 머물지 않고, 학습되고, 서빙되고, 다른 사람이 호출할 수 있는 상태까지 가는 거리를 줄였습니다.

더 많이 만드는 것 다음에는, 더 잘 판단하는 일이 남습니다

AI가 코딩을 정복했고, 다음은 리서치라고 생각했습니다.

Ralphthon을 마치고 나니 그 문장 뒤에 한 줄을 더 붙이고 싶어졌어요.

AI가 연구를 더 빨리 만들기 시작하면, 다음 병목은 생성량이 아닙니다. 무엇을 믿을지, 무엇을 다시 실험할지, 마지막 판단을 누가 책임질지를 설계하는 일입니다.

Team SAIL은 제출 전에 거절을 연습하는 루프를 만들었습니다. 정석원님은 날카로운 비판을 근거에 묶고, 탈락 뒤에도 서비스를 계속 만들었어요. 두 결과물은 달랐지만 공통점이 하나 있었습니다.

AI가 판단을 대신하게 두지 않고, 사람이 더 좋은 판단을 내릴 수 있는 구조를 만들었습니다.

저는 그게 Auto Research의 다음 단계라고 생각합니다. 그리고 좋은 컴퓨트 인프라의 역할은 바로 그 구조를 실제로 돌려볼 수 있게 만드는 일입니다.

VESSL Cloud에서 다음 실험을 시작해보세요

하루짜리 해커톤이든 몇 달짜리 연구든, 환경 구축에 쓰는 시간은 실험에 쓰는 시간에서 빠져나갑니다. VESSL Cloud에서 다음 실험을 시작해보세요. GPU 사양과 시간당 단가는 가격 페이지에서 먼저 확인할 수 있어요. 해커톤이나 연구 행사 GPU 후원이 필요하다면 biz-kr@vessl.ai로 편하게 알려주세요.

VESSL Cloud 시작하기

자주 묻는 질문