500달러로 파인튜닝한 9B가 프런티어를 이긴 조건 — 그리고 그 조건이 얼마나 좁은가

• 들어가며 — 336점짜리 글이 실제로 주장한 것
• 실험을 그대로 옮기면
• 이긴 것은 모델이 아니라 과제의 모양이다
• 재현되는 조건 체크리스트
• 500달러는 청구서에서 가장 싼 항목이다
• 손익분기 산수 — 가동률이 단가를 정한다
• 그냥 API를 쓰는 편이 맞는 경우, 그리고 검증되지 않은 것
• 마치며 — 좁은 과제의 승리는 좁은 결론만 지지한다

들어가며 — 336점짜리 글이 실제로 주장한 것

2026년 7월 28일 Hacker News에 올라온 글이 336점을 받았습니다. 요지는 9B짜리 오픈 모델을 약 500달러어치 GPU 시간으로 강화학습시켰더니 전자상거래 카탈로그 검수 과제에서 프런티어 모델들을 앞섰다는 것입니다. 원문은 Fermisense가 쓴 사례 연구이고, 제목은 "지능 소유권의 부상"에 가깝습니다.

먼저 이 글이 주장하지 않은 것부터 분명히 해야 합니다. 9B 모델이 프런티어보다 똑똑하다는 주장이 아닙니다. 특정 과제에 맞춰 학습한 전문가가, 그 전문가의 과제에서, 범용 모델을 이겼다는 주장입니다. 이 구분을 놓치면 결론이 정반대로 일반화됩니다. HN 스레드에서도 이 지점을 짚는 댓글이 상단에 여럿 있었습니다.

그리고 이 결과는 재현된 적이 없습니다. 채점기도, 데이터 파이프라인도, 학습 설정도 모두 한 조직 안에 있습니다. 아래에서 숫자를 그대로 옮기되, 어느 것도 독립 검증을 거치지 않았다는 사실을 전제로 읽어야 합니다. 참고로 저는 원문 페이지를 직접 가져오지 못했고(접근이 차단됩니다), 아래 수치는 원문을 인용한 2차 보도와 HN 스레드에서 교차 확인한 값입니다.

실험을 그대로 옮기면

표에서 가장 눈에 띄는 줄은 점수가 아니라 그 아래입니다. 다섯 개 프런티어 구성이 서로 0.1점 안쪽에서 평평해졌다는 보고입니다. 프롬프트를 다듬어도, 더 비싼 모델로 바꿔도 같은 천장에 부딪혔다는 뜻입니다. 이건 모델의 한계라기보다 과제의 모양에 관한 정보입니다. 뒤에서 다시 봅니다.

한 가지 불일치를 적어 둡니다. 2차 보도는 200개 에피소드 층화 홀드아웃을 명시하는데, HN 스레드에는 원문 어디에도 학습·검증·홀드아웃 분리 언급이 없어 과적합인지 알 수 없다는 지적이 있습니다. 둘 중 하나가 틀렸거나, 원문이 갱신됐거나, 보도가 다른 자료를 참조한 것입니다. 저는 어느 쪽인지 확인하지 못했습니다.

이긴 것은 모델이 아니라 과제의 모양이다

프런티어 다섯 구성이 0.1점 안에서 멈췄다는 사실이 이 실험의 진짜 결과입니다. 범용 모델이 천장에 부딪히는 이유는 대체로 정해져 있습니다 — 과제가 요구하는 것이 지능이 아니라 암묵적 규칙에 대한 순응일 때입니다.

카탈로그 검수가 정확히 그런 과제입니다. 어떤 상품명이 과장인지, 어떤 브랜드 표기가 위반인지, 어떤 카테고리 오배치가 심각하고 어떤 것이 사소한지는 세상의 상식이 아니라 그 회사의 정책입니다. 프롬프트로 정책을 다 적어 넣을 수는 없고, 적어 넣어도 수십 개 규칙이 서로 충돌하는 경계 사례에서 어떤 가중치를 쓸지는 문장으로 표현되지 않습니다. 그 가중치는 라벨에 들어 있습니다. 강화학습은 그 라벨을 가중치로 옮기는 일을 하고, 프롬프트 엔지니어링은 못 합니다.

여기서 이 결과의 진짜 조건이 드러납니다. 파인튜닝이 이기는 자리는 "모델이 모르는 지식"이 있는 자리가 아니라 정답 기준이 조직 내부에만 존재하고, 그 기준이 라벨로 대량 존재하는 자리입니다. 반대로 파인튜닝으로 새 지식을 주입하려는 시도는 여러 논문에서 반복해 실패로 측정됐습니다. 이 구분은 RAG · 파인튜닝 · 롱컨텍스트 중 뭘 써야 하나 편에서 논문 단위로 정리한 적이 있습니다.

스텝 250, 즉 하루 만에 프런티어 대역을 넘었다는 관측도 같은 이야기를 합니다. 모델이 새로운 능력을 획득한 것이 아니라, 이미 가진 능력을 이 채점기가 원하는 방향으로 정렬하는 데 그 정도면 충분했다는 뜻입니다.

재현되는 조건 체크리스트

그래서 어떤 과제에서 이 결과가 되풀이될까요. 아래 다섯 개가 모두 참일 때만입니다. 하나라도 어긋나면 500달러는 회수되지 않습니다.

• 과제가 좁고 출력 형식이 고정된다. 카탈로그 한 건을 보고 정해진 필드를 채우는 일은 되고, "고객 문의에 잘 답해 줘"는 안 됩니다.
• 자동 채점이 가능하다. 강화학습은 보상 신호가 필요하고, 사람이 매번 채점해야 하는 과제에서는 스텝 1,000회를 돌릴 수 없습니다. 이 실험이 성립한 이유의 절반은 채점기가 프로그램이었다는 점입니다.
• 라벨이 이미 대량으로 있거나 합성할 수 있다. 여기서는 공개 데이터셋에서 17만 7천 건을 합성했습니다. 자연 발생 데이터로 이 규모를 모으려면 학습 비용보다 데이터 비용이 먼저 커집니다.
• 정답 기준이 조직 안에 있다. 세상의 상식으로 풀리는 과제라면 범용 모델이 이미 천장 근처에 있고, 파인튜닝이 넘을 여지가 없습니다.
• 물량이 크고 오래간다. 뒤에서 계산하겠지만, 물량이 작으면 산수가 성립하지 않습니다.

여기에 조건 아닌 함정이 하나 더 붙습니다. 채점기를 직접 만든 조직이 그 채점기로 자기 모델을 평가하면, 보상 해킹을 감지할 외부 기준이 없습니다. Fermisense 스스로도 채점기가 자사 카탈로그 정책과 도메인별 감점 가중치를 인코딩한 것이라고 밝히고 있습니다. 87.3%라는 숫자는 "이 채점기 기준 87.3%"이지 "카탈로그 검수를 87.3% 잘한다"가 아닙니다. 프런티어 모델들도 같은 채점기로 쟀으니 비교 자체는 공정하지만, 그 채점기가 실제 사업 성과와 얼마나 상관 있는지는 별개 문제입니다.

500달러는 청구서에서 가장 싼 항목이다

HN 스레드에서 가장 자주 반복된 지적이 이것이었습니다. 500달러는 실제 비용의 목록에서 가장 아래 줄입니다. 위에 있는 것들을 나열하면:

• 데이터 구축. 17만 7천 건의 학습 에피소드를 합성하는 파이프라인, 그 파이프라인이 실제 카탈로그 분포를 닮았는지 검증하는 작업.
• 보상 설계. 채점기 자체를 만들고, 그 채점기가 보상 해킹에 어떻게 뚫리는지 찾아 막는 반복. 강화학습 프로젝트에서 시간이 가장 많이 드는 구간이 대체로 여기입니다.
• 하이퍼파라미터 탐색. 어느 댓글은 성공한 1회 학습 뒤에 숨은 실패 실행들의 비용을 5,000달러 이상으로 추정했습니다. 이건 추정이지 보고된 값이 아닙니다.
• 평가 체계. 배포 후 품질이 유지되는지 상시로 재려면 별도의 평가 세트와 하네스가 필요합니다. 이게 없으면 문제가 생겼을 때 원인을 모릅니다.
• 분포 이동 대응. 카탈로그의 상품 구성, 브랜드 목록, 정책은 계속 바뀝니다. 좁은 과제에 특화된 모델일수록 이동에 취약합니다. 재학습 주기가 분기라면 연 2,000달러의 GPU 비용이 아니라 연 4회의 엔지니어링 이벤트가 생기는 것입니다.
• 서빙. 다음 절에서 계산합니다.

이 항목들을 다 합치면 초기 투자 T가 나옵니다. 500달러가 T의 몇 퍼센트인지가 이 프로젝트의 진짜 성격을 말해 줍니다.

손익분기 산수 — 가동률이 단가를 정한다

두 개의 손익분기를 계산해야 합니다. 첫 번째는 초기 투자 회수입니다.

프런티어 대비 절감액 (가장 싼 구성 기준)
  19.00 - 0.50 = 18.50 달러 / 1,000건  ->  0.0185 달러 / 건

초기 투자 T를 회수하는 데 필요한 물량:
  T =    500 달러 (GPU만)                 ->     27,000 건
  T =  5,500 달러 (GPU + 실패한 탐색)     ->    297,000 건
  T = 30,000 달러 (엔지니어 시간 포함)    ->  1,620,000 건

500달러만 세면 2만 7천 건이면 본전인데, 현실적인 초기 투자를 넣으면 백만 건 단위가 됩니다. 카탈로그가 수백만 개인 마켓플레이스에는 쉬운 숫자이고, 상품 수만 개짜리 서비스에는 절대 도달하지 않는 숫자입니다. 같은 실험 결과가 조직 규모에 따라 정반대 결론을 냅니다.

두 번째 손익분기가 더 자주 간과됩니다. 1,000건당 0.50달러라는 단가는 GPU가 놀지 않는다는 가정에서 나옵니다. 자체 서빙의 비용 구조는 사용량에 비례하지 않고 시간에 비례합니다.

가정: 추론용 GPU 1장을 시간당 2달러에 상시 가동 (assumption, 실제 요율은 확인 필요)
  월 고정비 = 2 x 24 x 30 = 1,440 달러

월 X건을 처리할 때
  자체 서빙 총비용 = 1,440 + 0.0005 X
  프런티어 API     = 0.019 X          (1,000건당 19달러)

  같아지는 지점:  1,440 = 0.0185 X   ->   X = 약 77,800 건 / 월

월 7만 8천 건 아래에서는, 파인튜닝이 아무리 잘 됐어도 가장 싼 프런티어 API가 총비용에서 이깁니다. 놀고 있는 GPU가 토큰 단가의 우위를 통째로 먹기 때문입니다. 월 1만 건짜리 워크로드의 실질 단가는 1,000건당 약 144달러로, 표에서 가장 비싼 프런티어 구성과 같은 자릿수가 됩니다.

이 계산에서 벗어나는 방법은 두 가지뿐입니다. GPU를 다른 작업과 공유해 가동률을 올리거나, 서버리스 추론으로 고정비를 변동비로 바꾸는 것입니다. 후자를 택하면 1,000건당 0.50달러라는 숫자는 더 이상 성립하지 않으니 다시 계산해야 합니다.

그냥 API를 쓰는 편이 맞는 경우, 그리고 검증되지 않은 것

위 조건들을 뒤집으면 결정 규칙이 나옵니다. 다음 중 하나라도 해당하면 파인튜닝을 시작하지 말고 API를 쓰세요.

• 월 처리량이 손익분기 물량의 절반에 못 미친다.
• 자동 채점기를 만들 수 없다. 품질 판단이 사람의 눈에만 있다.
• 과제 정의가 아직 움직이고 있다. 3개월마다 요구사항이 바뀌면 그때마다 재학습이 아니라 프롬프트 한 줄 수정으로 끝나는 편이 낫습니다.
• 프런티어 모델이 이미 90% 이상 잘한다. 남은 10%가 라벨로 표현되지 않는 종류라면 파인튜닝도 못 넘습니다.
• 팀에 강화학습 실행·디버깅을 해 본 사람이 없다. 이 프로젝트의 어려운 부분은 학습이 아니라 보상 설계와 실패 진단입니다.

마지막으로, 이 사례에서 검증되지 않은 것들을 정리합니다. 독립 재현이 없습니다. 채점기가 공개되지 않았으므로 보상 해킹 여부를 외부에서 확인할 수 없습니다. 학습·홀드아웃 분리에 대한 서술이 자료마다 다릅니다. 학습 데이터가 공개 데이터셋에서 합성된 것이라 실제 운영 카탈로그의 분포와 얼마나 닮았는지 알 수 없습니다. 프런티어 구성들이 각 벤더의 권장 스캐폴딩을 썼는지, 배포 시점에 더 나은 모델이 나오면 격차가 어떻게 되는지도 다뤄지지 않았습니다. 그리고 배포 후 6개월이 지난 시점의 품질 — 즉 분포 이동을 겪은 뒤의 숫자 — 는 애초에 존재하지 않습니다. 파인튜닝 프로젝트의 진짜 성적표는 그 숫자입니다.

마치며 — 좁은 과제의 승리는 좁은 결론만 지지한다

이 실험이 보여 준 것은 명확합니다. 정답 기준이 조직 내부에 있고, 자동 채점이 가능하고, 라벨이 대량으로 있고, 물량이 큰 과제라면, 9B 모델을 며칠 학습시켜 프런티어를 넘길 수 있습니다. 그리고 그런 과제는 사람들이 파인튜닝을 시도하는 과제 중 아주 얇은 한 층입니다.

숫자를 하나만 기억한다면 500달러가 아니라 7만 8천 건이면 좋겠습니다. 학습 비용은 한 번이고 서빙 비용은 매달인데, 파인튜닝 논의의 대부분은 전자만 이야기합니다. 그리고 500달러 아래에 깔린 데이터·보상·평가·재학습 항목들은, 성공한 프로젝트의 글에는 거의 등장하지 않지만 실패한 프로젝트에서는 항상 원인이었습니다.