한 번의 학습을 위해 서버를 갖지 않기로 했다

대형 open model의 fine-tuning은 대개 모델을 다루는 일처럼 보이지만, 막상 손에 잡히는 문제는 거의 언제나 운영에서 시작된다. 학습을 한 번 돌려보려는 순간부터 GPU를 얼마나 오래 붙들어야 하는지, 체크포인트를 어디에 둘지, 재시도는 어떤 단위로 안전한지, 실험이 끝난 뒤 그 환경을 어떻게 치울지 같은 질문이 줄줄이 따라온다. Gemma 4 같은 최신 계열 모델이 등장할수록 이 간극은 더 또렷해진다. 모델은 더 강력해졌는데, 그 모델을 다루는 사람의 피로는 종종 더 커진다.

그래서 서버를 아예 갖지 않겠다는 선택은 단순한 편의의 언어가 아니다. Cloud Run Jobs와 서버리스 GPU 조합이 흥미로운 이유도 여기에 있다. 학습을 위한 인프라를 늘 상시 대기시키지 않고, 실험이 필요한 순간에만 GPU를 붙여 짧게 실행하고, 끝나면 없애버리는 방식은 미세조정을 연구실의 상시 설비가 아니라 사건 단위의 작업으로 바꾼다. 이 변화는 비용 절감이라는 익숙한 문장만으로는 설명되지 않는다. 더 중요한 변화는 의사결정의 위치다. 무엇을 학습할지보다, 어떤 실패를 감당할 구조로 학습을 설계할지가 먼저 앞으로 나온다.

모델보다 먼저 부딪히는 것

많은 팀이 fine-tuning을 어렵게 느끼는 이유는 모델 구조 자체보다 학습 시스템의 무게 때문이다. GPU 인스턴스를 잡고, 의존성을 맞추고, 데이터 접근 권한을 연결하고, 로그와 산출물을 저장할 위치를 정하는 동안 이미 작은 팀의 집중력은 크게 소모된다. 학습이 한 번 실패하면 더 지친다. 실패 원인이 모델 때문인지, 배치 크기 때문인지, 파일 마운트 때문인지, 이미지 디코딩 때문인지가 금방 분리되지 않기 때문이다.

상시 서버를 운영하는 방식은 이런 문제를 익숙하게 만들 수는 있어도 가볍게 만들지는 못한다. 오히려 “이미 서버가 있으니 더 써야 한다”는 방향으로 판단이 기울기 쉽다. 그러면 짧고 선명해야 할 실험이 길고 흐릿한 운영 과제로 바뀐다. 실험용 fine-tuning이 자꾸 플랫폼 프로젝트처럼 커지는 순간이다.

Cloud Run Jobs 같은 실행 모델은 이 습관을 정반대로 뒤집는다. 학습은 서비스가 아니라 배치다. 살아 있어야 하는 프로세스가 아니라 끝나야 하는 작업이다. 서버가 먼저 있고 학습을 올리는 구조가 아니라, 작업을 던지면 필요한 런타임이 잠깐 생겼다가 사라지는 구조다. 이 차이는 생각보다 크다. 운영의 기본 단위가 서버에서 잡으로 바뀌면, 가장 먼저 달라지는 것은 “실패를 어떻게 다룰 것인가”다.

서버리스 GPU가 편해 보일 때 생기는 오해

서버리스 GPU라는 표현은 쉽게 오해를 부른다. 서버를 안 본다는 뜻이지, 복잡성이 사라진다는 뜻은 아니다. 복잡성은 사라지지 않고 위치를 바꾼다. 이전에는 드라이버, 노드 관리, 스케줄러 설정에 퍼져 있던 문제가 이제는 컨테이너 이미지, 잡 정의, 입력 데이터 경계, 체크포인트 저장 방식으로 모인다.

특히 fine-tuning에서는 이 이동이 아주 선명하다. 인프라 층의 고민이 줄어든 대신, 잡 내부가 더 엄격해진다. 컨테이너는 항상 같은 방식으로 시작해야 하고, 입력은 재현 가능해야 하며, 출력은 중간 실패에도 일관되게 남아야 한다. 로컬 환경에서 “일단 한번 돌아갔음”이 주는 안도감이 거의 의미를 잃는다. 같은 잡이 며칠 뒤에도 같은 조건에서 다시 돌 수 있어야 비로소 실험 기록이 된다.

이 지점에서 서버리스 GPU는 학습을 더 쉽게 해준다기보다 더 정직하게 만든다. 환경의 상태를 믿지 못하니, 데이터와 설정을 더 명시적으로 다뤄야 한다. 한 번 성공한 셸 세션이 아니라, 다시 실행 가능한 정의가 중요해진다. 작은 팀에는 이것이 오히려 이점이다. 사람의 기억에 의존하던 실험이 선언적인 실행 단위로 바뀌기 때문이다.

Gemma 4가 던지는 새로운 질문

Gemma 4 같은 최신 open model 계열을 다룰 때는 “학습이 되느냐”보다 “어디를 학습시켜야 하느냐”가 훨씬 중요해진다. 텍스트만 다루는 모델에 익숙한 감각으로 접근하면 멀티모달 구조에서 자주 헛발질한다. LoRA를 어디에 꽂아야 하는지, vision 쪽과 language 쪽 중 어느 쪽이 병목인지, projector 계층을 건드리는 편이 나은지, 또는 오히려 일부만 제한적으로 조정하는 편이 안정적인지가 모델마다 다르게 드러난다.

이건 단순한 하이퍼파라미터 조정 문제가 아니다. 모델이 입력을 어떻게 결합하는지에 대한 구조적 이해가 필요한 문제다. 텍스트 기반 instruction tuning에서 잘 먹히던 습관이 이미지가 끼는 순간 그대로 통하지 않는다. 특히 분류 문제라고 해서 더 단순할 것이라고 여기면 위험하다. 분류는 목표가 분명해서 쉬워 보이지만, 멀티모달 모델 입장에서는 무엇을 구분 단서로 삼아야 하는지가 매우 미묘해진다. 품종 분류는 배경, 각도, 조명, 털색 분포, 촬영 장치, 심지어 이미지 크롭 습관까지 라벨의 대리 신호로 흘러들어오기 쉽다.

그래서 Gemma 4를 fine-tuning할 때 흔한 실패는 성능이 낮다는 사실보다 성능이 무엇으로 만들어졌는지 모른다는 데 있다. validation accuracy가 올랐다고 안심하기 어려운 이유다. 모델이 정말 품종 특징을 본 것인지, 데이터셋의 반복되는 촬영 패턴을 외운 것인지 분리하기 어렵다. 멀티모달 미세조정은 늘 이 불편한 질문을 남긴다. 모델은 더 똑똑해졌지만, 해석은 더 어려워졌다.

왜 하필 반려동물 품종 분류인가

반려동물 품종 분류 같은 예시는 자주 가볍게 취급된다. 너무 귀엽고, 너무 단순해 보이고, 산업용 문제처럼 보이지 않기 때문이다. 그런데 이 종류의 과제는 멀티모달 fine-tuning을 검증하기에 꽤 까다로운 시험대다. 라벨은 명확하지만 시각적 경계는 흐리고, 클래스 간 유사도는 높으며, 데이터셋은 의외로 편향을 많이 품는다.

이런 과제는 모델의 실제 적응력을 보기 좋다. 단순히 텍스트 지시를 따르는지보다, 시각 특징과 언어 출력 사이의 연결이 얼마나 섬세하게 조정되는지 드러난다. 동시에 운영 측면에서도 장점이 있다. 입력 파이프라인이 비교적 직관적이어서, 학습 실패의 원인이 모델 구조인지 데이터 처리인지 빨리 분리하기 좋다. 이미지 전처리, 배치 구성, 메모리 사용량, 체크포인트 크기 같은 현실적인 문제를 다 보기에도 적당하다.

사소해 보이는 예제가 좋은 이유는, 오히려 과장이 적기 때문이다. 복잡한 도메인 지식이 끼어들기 전에 미세조정 시스템 자체의 성질이 먼저 보인다. 학습 파이프라인이 얼마나 예민한지, 멀티모달 입력이 얼마나 쉽게 메모리를 잡아먹는지, LoRA 대상 선택이 결과에 얼마나 큰 영향을 미치는지가 분명하게 드러난다.

VRAM은 숫자가 아니라 설계 압력이다

NVIDIA RTX 6000 Pro 같은 고용량 GPU가 붙는다는 말은 많은 사람에게 곧바로 안도감을 준다. 하지만 실전에서 VRAM은 넉넉함의 상징이라기보다 설계 압력의 형태로 작동한다. 메모리가 많으면 분명 선택지가 늘어난다. 더 큰 배치, 더 긴 시퀀스, 더 많은 vision token, 더 두꺼운 optimizer state를 시도할 수 있다. 문제는 사람의 욕심도 함께 커진다는 점이다.

fine-tuning이 자주 터지는 지점은 정확히 여기다. 들어갈 수 있는 만큼 다 넣고 나면, 작은 변동에도 학습이 흔들린다. 데이터 샘플 길이가 예상보다 길거나, 이미지 해상도가 조금만 커지거나, mixed precision 경계에서 메모리 단편화가 일어나도 갑자기 OOM이 난다. 서버리스 환경에서는 이런 실패가 더 성가시다. 상시 떠 있는 세션에서 즉석 조정하는 방식보다, 잡 정의를 다시 만들어 재실행해야 하기 때문이다.

그래서 큰 VRAM을 볼 때 중요한 질문은 “얼마나 많이 넣을 수 있는가”가 아니라 “얼마나 안정적으로 반복할 수 있는가”다. QLoRA가 여전히 매력적인 이유도 여기에 있다. 4-bit quantization과 LoRA 조합은 단순히 더 작은 장비에서도 돌아가게 해주는 기술이 아니다. 실험 공간을 예측 가능한 범위 안에 가두는 방법이기도 하다. Full fine-tuning이 이론적으로 더 높은 상한을 가질 수 있어도, 반복 가능한 실험이라는 기준에서는 QLoRA가 훨씬 더 현실적인 선택이 되는 경우가 많다.

LoRA는 가벼운 기법이 아니라 선택의 기술이다

LoRA를 “메모리를 덜 먹는 미세조정” 정도로만 이해하면 중요한 절반을 놓친다. LoRA의 핵심은 무엇을 바꾸지 않을지 정하는 데 있다. 모델 전체를 다시 쓰는 대신, 제한된 경로에 적응력을 부여하는 방식이기 때문이다. 이 선택은 비용과 속도뿐 아니라 일반화의 성질까지 바꾼다.

멀티모달 모델에서는 이 판단이 더 예민하다. 텍스트 부분에만 LoRA를 적용했을 때와, vision 관련 투영 계층이나 cross-modal 결합 지점까지 포함했을 때의 결과는 꽤 다를 수 있다. 문제는 후자가 늘 더 낫지 않다는 점이다. 더 많은 계층을 건드리면 표현력은 늘지만, 작은 데이터셋에서는 과적합도 빨라진다. 특히 이미지 분류처럼 라벨 체계가 단순한 작업에서는 모델이 “진짜 특징”보다 데이터셋 버릇을 더 빨리 집어들 수 있다.

rank를 높이는 일도 비슷하다. rank는 성능 레버이면서 동시에 비용 레버다. 너무 낮으면 적응력이 부족하고, 너무 높으면 학습 안정성이나 저장 비용, 추론 시 배포 복잡도가 따라온다. 서버리스 GPU 환경에서는 이 비용 감각이 더 직접적으로 느껴진다. 실험 하나의 길이, 체크포인트 크기, 재시도 빈도, 저장소 I/O까지 모두 금액과 대기 시간으로 환산되기 때문이다. LoRA는 값싼 타협이 아니라, 어떤 종류의 변화만 허용할 것인지 정하는 운영적 설계다.

잡으로 학습한다는 것의 진짜 의미

Cloud Run Jobs 같은 배치형 런타임에서 학습을 돌린다는 말은 그냥 “노트북 대신 잡”이라는 뜻이 아니다. 학습 생애주기를 서비스 생애주기와 분리한다는 뜻이다. 이 분리는 생각보다 중요하다. 모델 학습은 대개 오래 걸리고 자주 실패하며, 중간 상태가 많다. 반면 서비스 런타임은 짧은 응답과 예측 가능한 상태를 선호한다. 두 성질은 잘 맞지 않는다.

잡 기반 접근은 이 충돌을 피한다. 실패해도 프로세스 하나가 끝난 것으로 간주할 수 있고, 성공하면 산출물만 남기면 된다. 대신 이 구조는 학습 파이프라인에 더 엄격한 기록성을 요구한다. 어떤 데이터 버전을 썼는지, 어떤 rank와 learning rate를 썼는지, 어느 시점 체크포인트를 남겼는지, 재시작 시 어디서 이어붙일 수 있는지가 모두 명시되어야 한다. 상시 서버가 주던 모호한 유연성이 사라지는 대신, 실험 노트의 품질이 올라간다.

운영에서 자주 보는 좋은 신호는 GPU utilization이 높다는 사실이 아니다. 오히려 재실행했을 때 같은 결과 패턴이 다시 나오고, 실패 원인이 로그에서 한 단계 안쪽으로 좁혀지며, 체크포인트 손실 없이 잡을 종료할 수 있다는 종류의 신호가 더 중요하다. 학습을 “끝까지 한 번 돌렸다”보다 “같은 성질의 잡을 여러 번 안전하게 돌릴 수 있다”로 판단하는 감각이 필요하다.

자주 터지는 문제는 학습 루프 바깥에서 시작된다

현장에서 더 자주 만나는 문제는 optimizer보다 입력 경계에 있다. 이미지 파일이 부분 손상되어 있거나, 전처리 단계에서 크기 비율이 일관되지 않거나, 텍스트 라벨 정규화가 미묘하게 달라져 클래스 수가 엇갈리는 식이다. 서버리스 환경에서는 로컬 캐시의 우연한 도움을 기대할 수 없기 때문에 이런 문제가 더 빨리 드러난다.

또 하나의 함정은 저장소 I/O다. 모델 체크포인트, 데이터 샤드, 로그를 원격 저장소에 계속 쓰고 읽는 구조에서는 GPU 성능보다 I/O 패턴이 병목이 되는 순간이 있다. 이때 사람들은 GPU를 더 큰 것으로 바꾸려는 생각을 먼저 하지만, 실제로는 체크포인트 주기나 데이터 스트리밍 방식이 문제인 경우가 많다. 학습이 느리다고 해서 언제나 계산이 느린 것은 아니다. 대기 시간이 계산 시간보다 길어지는 순간, 가장 비싼 자원이 놀고 있게 된다.

멀티모달 입력은 이 병목을 더 악화시킨다. 이미지 디코딩과 텐서 변환은 생각보다 비싸고, 배치마다 샘플 크기 편차가 큰 경우 메모리 사용량도 들쭉날쭉해진다. 그래서 학습 코드가 잘 돌아가도 잡 전체는 불안정할 수 있다. 컨테이너 안에서 학습 루프만 보는 습관으로는 이 문제를 놓치기 쉽다. 실제 병목은 데이터 로더, 네트워크 스토리지, 또는 체크포인트 flush에 숨어 있기 때문이다.

정확도보다 먼저 봐야 하는 신호들

fine-tuning 실험을 운영 관점에서 볼 때, 마지막 accuracy만 기다리는 태도는 위험하다. 오히려 초반 수십 분 안에 보이는 신호가 더 가치 있다. 스텝 시간이 일정한지, GPU 메모리 사용량이 배치마다 과도하게 튀는지, loss가 내려가면서도 validation 샘플에 대한 예측 문장이 이상하게 짧아지거나 과도하게 확신에 찬 형태로 수렴하는지 같은 것들이다. 멀티모달 모델은 학습이 망가지기 직전까지도 겉보기에는 멀쩡한 로그를 보여줄 때가 많다.

예를 들어 품종 분류 같은 과제에서 모델이 지나치게 빠르게 높은 학습 성능을 보이면 좋은 소식일 수도 있지만, 데이터 누수나 배경 편향의 신호일 수도 있다. 반대로 loss가 예쁘게 떨어지지 않아도 예측의 질은 좋아질 수 있다. 분류를 생성형 출력으로 다루는 구조에서는 토큰 분포가 바뀌는 방식이 단순한 softmax 분류기와 다르게 나타날 수 있기 때문이다. 이때 중요한 것은 지표를 하나 더 붙이는 일이 아니라, 모델이 어떤 입력에 흔들리는지를 계속 관찰하는 일이다.

서버리스 GPU 환경은 이런 관찰을 더 체계적으로 강제한다. 잡 단위 실행에서는 각 실험을 하나의 사건으로 남기기 쉽고, 사건 간 비교도 상대적으로 명확하다. 상시 서버 위에서 이것저것 덧대며 돌릴 때보다, 어느 시점에 무엇이 달라졌는지가 분명해진다. 운영 관찰성과 실험 통제가 같은 방향으로 맞물리는 셈이다.

한 번의 학습이 남기는 조직의 변화

이 방식의 가장 큰 변화는 기술 스택보다 팀의 습관에 있다. GPU 서버를 한 대 오래 붙들고 있는 문화에서는, 학습이 자연스럽게 특정 인프라 담당자나 연구자에게 집중된다. 환경을 아는 사람이 사실상 실험의 관문이 된다. 반면 잡 기반 서버리스 학습은 그 관문을 낮춘다. 정확한 잡 정의와 데이터 규약만 공유되면, 특정 머신의 상태를 아는 사람이 아니어도 실험을 시작할 수 있다.

이것이 곧바로 미세조정의 민주화를 의미하는 것은 아니다. 오히려 반대에 가깝다. 누구나 돌릴 수 있게 되는 순간, 어떤 실험을 돌려야 하는지의 기준이 더 중요해진다. 서버 관리 지식이 줄어든 자리를 실험 설계 감각이 채운다. LoRA 대상을 어디에 둘지, QLoRA로 충분한지, 멀티모달 입력에서 무엇을 통제해야 하는지, 어떤 실패를 정상 범위로 볼지 같은 판단이 중심으로 이동한다.

결국 서버를 갖지 않기로 한 결정은 인프라를 포기하는 결정이 아니다. 인프라의 의미를 바꾸는 결정이다. 늘 켜져 있는 GPU보다 더 중요한 것은, 학습을 반복 가능한 사건으로 만들 수 있는 구조다. Gemma 4 같은 모델은 그 구조 위에서 더 빠르게 실험하게 해주지만, 동시에 그 구조의 허술함도 더 빨리 드러낸다.

끝내 남는 질문

대형 open model의 fine-tuning이 가벼워졌다는 말은 절반만 맞다. 접근 장벽은 분명 낮아졌다. 서버리스 GPU와 Cloud Run Jobs 조합은 작은 팀에게도 꽤 현실적인 출발점을 준다. RTX 6000 Pro 급 자원은 한 번의 실험을 충분히 진지하게 만들어준다. LoRA와 QLoRA는 모델 전체를 다시 쓰지 않고도 적절한 적응을 시도할 길을 열어준다.

하지만 병목은 사라지지 않는다. 단지 모델 바깥으로 옮겨간다. 멀티모달 구조를 이해하지 못한 LoRA 선택, VRAM을 과신한 설정, 잡 기반 실행을 서비스처럼 다루는 습관, 입력 경계를 느슨하게 본 데이터 파이프라인은 여전히 같은 방식으로 실험을 망가뜨린다. 그래서 이 흐름이 던지는 가장 중요한 교훈은 “이제 누구나 학습할 수 있다”가 아니다. 더 정확한 문장은 아마 이쪽일 것이다. 이제는 학습을 돌릴 수 있는지보다, 어떤 단위로 실패를 설계할 것인지가 더 중요해졌다.

그 질문에 제대로 답하는 팀이라면, 서버가 없는 편이 오히려 더 많은 것을 갖게 된다. 상시 떠 있는 자원보다 선명한 실험 경계, 장비 친화적인 관성보다 기록 친화적인 실행, 한 번의 성공보다 여러 번의 재현을 우선하는 태도 말이다. Gemma 4와 서버리스 GPU의 조합이 흥미로운 이유는 최신 모델을 더 싸게 돌릴 수 있어서가 아니다. 한 번의 학습조차 운영의 사건으로 정확히 바라보게 만든다는 점, 바로 그 사실이 더 오래 남는다.

댓글

댓글을 읽어오는 중입니다.