1,000달러 GPU 실험이 답하지 못하는 질문: 자체 LLM 학습에 투자할 기준

3B~4B급 언어 모델을 수천 달러 이하의 GPU 비용으로 학습했다는 사례는 CTO와 개발 리드에게 매력적으로 들린다. “우리도 모델을 직접 만들 수 있지 않을까”라는 질문이 자연스럽게 나온다.

그 질문 자체는 타당하다. 다만 GPU 대여비가 낮아졌다는 사실과 자체 LLM 학습이 사업적으로 유리하다는 결론은 다르다. 학습 실행 비용은 전체 비용 중 눈에 잘 띄는 한 항목일 뿐이다. 조직이 비교해야 할 대상은 모델 파라미터 수나 단일 학습 런의 가격이 아니라, 업무에 필요한 성능을 원하는 기간 동안 안정적으로 유지하는 총비용이다.

먼저 구분할 말도 있다. 기존 오픈소스 모델을 업무 데이터로 미세조정하는 일, 특정 도메인에서 계속 학습하는 일, 무작위 가중치에서 기반 모델을 새로 사전학습하는 일은 필요한 역량과 위험이 크게 다르다. 이 셋을 모두 “자체 모델 개발”로 묶으면 예산과 일정 판단이 흐려진다.

GPU 가격은 출발점이지 사업성의 증거가 아니다

최근 공개된 한 개인 학습 실험에서는 38억여 개 파라미터의 디코더 전용 모델을 8대의 B200 GPU로 학습해, 약 43시간과 998달러의 실행 비용을 제시했다. 이 모델은 653억 토큰을 학습했고, 해당 실험에서 사용한 CORE 평가 기준으로 0.384를 기록했다.

이 수치는 중요한 가능성을 보여준다. 적절한 하드웨어, 정밀도 최적화, 데이터 공급 방식, 분산 학습 설정을 갖추면 소규모 팀이나 개인도 과거보다 훨씬 적은 비용으로 의미 있는 사전학습을 시도할 수 있다. 그러나 이 결과를 “38억 파라미터 모델은 998달러면 된다”는 구매 기준으로 읽어서는 곤란하다.

그 비용에는 적어도 다음 항목이 충분히 반영되지 않을 수 있다.

• 어떤 데이터를 넣을지 찾고, 정제하고, 중복·오염·민감정보 문제를 확인하는 비용
• 토크나이저, 학습 파이프라인, 체크포인트, 장애 복구 체계를 만드는 엔지니어링 시간
• 학습률, 데이터 혼합, 컨텍스트 길이, 모델 구조를 바꾸며 실패한 실험을 반복하는 비용
• 업무별 평가 세트와 사람 검토 기준을 설계하는 비용
• 추론 서버, 보안 통제, 모델 배포, 모니터링, 재학습을 지속하는 운영 비용
• 모델이 기대에 못 미쳤을 때 API나 다른 모델로 다시 전환하는 전환 비용

특히 공개 실험에서도 좋은 최종 결과 이전에 성능이 낮은 학습 시도가 있었다. 이는 실패가 특별한 예외가 아니라 학습 과정의 일부라는 뜻에 가깝다. 예산을 계산할 때는 최종 성공 런만 넣지 말고, 실패한 가설을 확인할 여유와 담당자의 시간을 함께 잡아야 한다.

먼저 “모델이 잘한다”의 업무 기준을 정한다

자체 학습을 검토하는 팀이 가장 먼저 만들 산출물은 학습 코드가 아니라 평가 명세다. 범용 벤치마크 점수가 높아도 자사 업무에서 원하는 답을 한다는 보장은 없다.

예를 들어 다음 질문에 수치나 판정 규칙으로 답할 수 있어야 한다.

• 모델이 처리할 입력은 짧은 문의인가, 긴 계약서·매뉴얼·로그인가
• 틀린 답을 내도 사람이 수정하면 되는가, 아니면 잘못된 자동 실행이 손실로 이어지는가
• 평균 품질보다 최악의 경우를 줄이는 일이 더 중요한가
• 한국어, 사내 약어, 전문 용어, 표 형식 문서에서 어느 수준까지 정확해야 하는가
• 답변 품질 외에 응답 시간, 처리량, 데이터 외부 전송 제한, 배포 위치가 핵심 조건인가
• 기준 모델보다 얼마나 좋아져야 전환 비용을 정당화할 수 있는가

이 기준 없이 자체 학습을 시작하면, 손실값은 내려가는데 사업 문제는 해결되지 않는 상황이 생긴다. 학습 손실은 다음 토큰을 예측하는 품질에 관한 신호다. 고객 응대의 정확성, 문서 판정의 재현성, 개발 지원의 생산성처럼 조직이 원하는 결과를 대신 측정하지는 않는다.

평가 세트는 운영 데이터의 복사본이 아니라 의사결정 도구로 설계하는 편이 낫다. 정상 사례뿐 아니라 애매한 입력, 정보가 부족한 질문, 긴 문맥, 금지된 행동, 사람이 넘겨받아야 하는 예외를 포함해야 한다. 모델을 바꿀 때마다 같은 조건에서 비교할 수 있어야 “좋아 보인다”는 인상 대신 전환 근거가 남는다.

세 가지 선택지는 경쟁 관계가 아니라 단계가 될 수 있다

대부분의 조직은 API에서 시작하는 편이 합리적이다. 요구사항이 아직 흔들리고, 어떤 업무가 가치가 있는지 검증하지 못했으며, 모델 운영 인력이 없다면 더 그렇다. 이 단계의 목표는 최저 토큰 단가가 아니라 업무 흐름과 평가 기준을 빠르게 찾는 일이다.

오픈소스 모델을 자체 환경에 배포하거나 미세조정하는 선택은 그다음에 검토할 수 있다. 외부 API보다 데이터 경계, 지연 시간, 모델 제어권이 중요하거나, 좁은 도메인에서 일관된 형식과 용어를 맞춰야 할 때 후보가 된다. 다만 오픈소스 모델은 라이선스 확인만으로 끝나지 않는다. 배포 환경, 취약점 대응, 모델 업데이트, 입력·출력 로그 처리, 품질 저하 감지가 운영 과제가 된다.

처음부터 사전학습하는 선택은 조건이 더 엄격하다. 다음 중 여러 항목이 동시에 맞을 때 검토할 이유가 생긴다.

1. 기존 모델이 반복해서 해결하지 못하는 핵심 과제가 있고, 프롬프트·검색증강·미세조정으로도 격차가 남아 있다.
2. 조직이 장기간 사용할 고유 데이터 또는 데이터 혼합 전략을 보유하고 있으며, 그 데이터가 모델 품질 차이로 이어질 가능성을 검증할 수 있다.
3. 학습 후에도 모델을 계속 개선하고 운영할 팀, 평가 체계, 컴퓨팅 조달 경로가 있다.
4. 품질, 비용, 데이터 통제, 지연 시간 가운데 하나 이상에서 자체 모델이 장기적으로 우위를 가질 가설이 있다.
5. 학습이 실패하거나 모델 성능이 기대에 못 미칠 때 쓸 대안 경로가 준비돼 있다.

여기서 핵심은 “우리 데이터가 많다”가 아니다. 그 데이터가 합법적으로 사용 가능한지와 별개로, 모델이 배워야 할 신호를 담고 있는지, 품질이 일정한지, 경쟁 모델과 구별되는 결과를 만들 수 있는지가 더 중요하다.

조기 신호가 나쁘면 학습 규모를 키우지 않는다

사전학습 프로젝트는 큰 GPU 클러스터를 예약한 뒤 판단하면 늦다. 작은 실험에서 다음 신호를 먼저 확인하는 편이 낫다.

첫째, 데이터가 바뀌었을 때 업무 평가가 개선되는지 본다. 학습 손실만 좋아지고 목표 업무 점수가 움직이지 않는다면 데이터 혼합이나 평가 설계가 잘못됐을 수 있다.

둘째, 컨텍스트 길이가 실제 업무 성능에 미치는 영향을 확인한다. 공개된 실험에서도 1,024 토큰과 2,048 토큰 설정의 평가 결과 차이가 있었고, 일부 과제는 긴 문맥에 민감했다. 긴 문서 이해가 핵심인 서비스라면 짧은 컨텍스트에서 얻은 저렴한 처리량을 그대로 사업 성과로 환산하면 안 된다.

셋째, 동일 조건에서 재현되는지 본다. 한 번의 좋은 점수보다 데이터 버전, 코드 버전, 하이퍼파라미터, 난수 시드, 평가 방식이 기록돼 있는지가 중요하다. 재현할 수 없는 모델은 개선도, 장애 분석도 어렵다.

넷째, 학습 속도보다 운영 속도를 점검한다. GPU 사용률이 높고 처리량이 좋아도, 데이터 로딩 지연이나 체크포인트 복구 실패, 평가 대기, 배포 파이프라인 병목이 반복되면 총 일정은 늘어난다. 학습 인프라를 구성 가능한 부품과 설정으로 분리하는 이유도 여기에 있다. 실험 조건을 코드 수정 없이 바꿀 수 있어야 원인을 추적하기 쉽다.

투자안은 모델 예산이 아니라 비교 가능한 서비스 예산으로 만든다

의사결정 문서에는 “학습 GPU 비용” 대신 세 개의 시나리오를 같은 형식으로 놓는 편이 좋다.

비교 항목	API 활용	오픈소스 모델 활용	자체 사전학습
초기 검증 속도	빠른 편	환경 구성 후 가능	학습·평가 기반부터 필요
모델 제어 범위	제한적	비교적 넓음	가장 넓음
핵심 비용	사용량, 연동, 검증	인프라, 운영, 튜닝	데이터, 실험, 컴퓨팅, 운영
주요 실패 방식	공급자 변경, 사용량 증가	배포·성능·운영 부담	품질 미달, 재현 실패, 일정 초과
적합한 단계	문제 탐색	요구사항 구체화 이후	차별화 가설 검증 이후

표의 평가는 조직마다 달라진다. 예를 들어 호출량이 적고 요구사항이 자주 바뀌는 제품은 API 비용이 높아 보여도 총비용이 낮을 수 있다. 반대로 안정적인 대량 추론, 엄격한 배포 경계, 지속적으로 축적되는 고유 도메인 데이터가 있는 서비스는 자체 배포나 학습의 가치를 더 크게 볼 여지가 있다.

지금 자체 학습을 검토한다면, 먼저 기반 모델을 만들 예산을 승인받으려 하지 말고 하나의 업무 평가 세트와 기준선 모델을 정하라. API 또는 오픈소스 모델로 기준 성능을 측정한 뒤, 데이터 처리나 미세조정으로도 넘기 어려운 격차가 확인될 때 사전학습 실험을 작게 시작하는 편이 안전하다. GPU를 싸게 빌릴 수 있는가보다, 그 실험이 다음 투자 결정을 더 명확하게 만드는가를 기준으로 삼아야 한다.