Skip to content
Published on

100배 싸다는 주장은 과제를 좁혔을 때만 참입니다 — 검증과 손익분기

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
필사 모드✨Start Quiz
공유하기
Authors

제목에 100배가 들어간 글을 받았을 때

팀 채널에 링크가 하나 올라옵니다. 오픈 모델을 후학습해서 프론티어 모델을 검색 과제에서 이겼고 비용은 100배 싸다는 내용입니다. 그리고 곧바로 질문이 따라옵니다. 우리도 이렇게 하면 되지 않나요.

이 질문에 "해 봅시다"나 "그건 마케팅입니다"로 답하는 대신, 원문에서 확인 가능한 것과 그렇지 않은 것을 분리해 보는 편이 훨씬 유용합니다. 대개 결론은 둘 중 하나가 아니라 조건부로 참이기 때문입니다.

원문이 실제로 한 일

문제의 글은 2026년 8월 5일에 공개된 Beating GPT-5.6 Sol on retrieval with 100x cheaper open models입니다. Castform과 Neon 쪽 인력이 함께 쓴 사례 보고이고, 요약하면 이렇습니다.

40억 파라미터급 오픈 모델을 검색 과제에 맞춰 강화학습으로 후학습했습니다. 학습 데이터는 자체 코퍼스에서 합성해서 만들었고, 검색은 키워드 점수와 벡터 유사도를 함께 쓰는 하이브리드 방식입니다. 보상 함수는 검색 품질, 인용 정확도, 최종 답의 정확도를 각각 점수로 매깁니다. 학습 중에는 수천 개의 병렬 롤아웃이 각각 수십 번의 호출을 일으키는 매우 들쭉날쭉한 부하가 발생합니다.

원문의 핵심 문장은 이것입니다. 검색 같은 특정 과제에서는 후학습된 오픈소스 모델이 프론티어 모델과 맞먹거나 이기면서 요청당 비용은 자릿수 단위로 적을 수 있다는 것입니다. 여기서 특정 과제라는 한정어가 문장의 절반을 차지합니다.

왜 검색이 이 방식에 잘 맞는가

이 결과가 검색에서 나온 것은 우연이 아닙니다. 좁은 과제로 만들기에 좋은 조건을 세 가지 갖추고 있습니다.

첫째, 성공을 코드로 판정할 수 있습니다. 검색된 문서에 정답 근거가 들어 있는지, 인용이 실제 문서를 가리키는지는 사람 없이 채점 가능합니다. 보상 함수를 만들 수 있다는 뜻이고, 이게 후학습의 전제 조건입니다.

둘째, 출력 공간이 좁습니다. 질의를 만들고, 결과를 고르고, 근거를 붙이는 일에는 자유 서술이 거의 필요 없습니다.

셋째, 도메인 코퍼스가 고정되어 있습니다. 프론티어 모델의 강점인 광범위한 세계 지식이 여기서는 별 이점이 아닙니다. 필요한 지식은 검색 대상 문서 안에 있습니다.

이 세 조건 중 하나라도 빠지면 같은 전략의 성공 확률이 크게 떨어집니다. 우리 과제를 대입해 볼 때 첫 번째 조건부터 확인하는 것이 순서입니다.

반대 예를 하나 들면 감이 잡힙니다. 고객 문의에 답하는 상담 도우미는 세 조건 중 어느 것도 깔끔하게 만족하지 않습니다. 좋은 답의 기준이 코드로 판정되지 않고, 출력이 자유 서술이며, 회사 정책 바깥의 상식이 계속 필요합니다. 같은 방법을 여기에 그대로 옮기면 보상 함수를 만드는 단계에서 이미 막힙니다.

확인되는 숫자와 확인되지 않는 숫자

여기서 정직하게 구분해야 할 부분이 있습니다. 원문에서 제가 확인할 수 있었던 구체적 수치는 비교 대상 쪽입니다. 다중 턴 검색 요청 하나가 프론티어 모델 기준으로 10초가 넘게 걸리고 종단 간 비용이 대략 0.03달러 수준이라는 서술입니다.

반대로 후학습 모델의 정확도가 몇 퍼센트인지, 어떤 평가셋에서 어떤 방식으로 쟀는지에 대한 독립적으로 검증 가능한 수치는 제가 원문에서 확인하지 못했습니다. 성능이 대등하다는 서술은 있지만 제3자가 재현할 수 있는 형태의 표는 없습니다.

그리고 이 글은 데이터베이스 제품과 학습 플랫폼을 파는 두 회사가 함께 쓴 글입니다. 결과가 거짓이라는 뜻은 전혀 아니지만, 과제 선정과 비교 조건이 자기 쪽에 유리하게 잡혔을 가능성은 감안하고 읽어야 합니다. 그래서 이 글에서 가져갈 것은 숫자가 아니라 방법과 조건입니다.

후학습이 라우팅보다 유리해지는 지점

방법을 가져왔다면 다음은 계산입니다. 후학습은 고정비가 크고 변동비가 작은 선택이고, 라우팅과 프롬프트 최적화는 고정비가 작고 변동비가 큰 선택입니다. 어느 쪽이 나은지는 물량이 결정합니다.

"""후학습 손익분기: 절감률이 아니라 회수 시점으로 판단한다."""
from dataclasses import dataclass


@dataclass
class Option:
    name: str
    fixed_cost: float      # 학습, 데이터 구축, 평가셋 제작 (1회)
    monthly_ops: float     # 서빙 인프라, 재학습, 당직
    per_request: float     # 요청당 비용

    def total(self, monthly_requests: int, months: int) -> float:
        return (
            self.fixed_cost
            + self.monthly_ops * months
            + self.per_request * monthly_requests * months
        )


def break_even(a: Option, b: Option, monthly_requests: int, horizon: int = 36):
    """a가 b보다 싸지는 첫 달을 찾는다. 없으면 None."""
    for m in range(1, horizon + 1):
        if a.total(monthly_requests, m) < b.total(monthly_requests, m):
            return m
    return None


frontier = Option("프론티어 API", fixed_cost=0, monthly_ops=0, per_request=0.03)
tuned = Option("후학습 4B", fixed_cost=60_000, monthly_ops=4_000, per_request=0.0003)

for volume in (50_000, 500_000, 5_000_000):
    m = break_even(tuned, frontier, volume)
    print(f"월 {volume:>9,}건 → 회수 시점: {m if m else '36개월 내 없음'}")

이 코드에서 중요한 것은 monthly_ops입니다. 요청당 단가만 비교하면 후학습이 언제나 압도적으로 보이는데, 실제로는 서빙 인프라와 재학습과 당직이 매달 나갑니다. 이 항목을 0으로 두고 계산한 제안서가 실무에서 가장 자주 보이는 오류입니다.

좁힌 과제의 경계를 재는 법

또 하나 계산에 들어가지 않는 비용이 있습니다. 후학습 모델은 경계 밖에서 조용히 나빠집니다. 프론티어 모델은 낯선 요청에도 그럭저럭 대응하지만, 좁게 학습된 모델은 학습 분포를 벗어나면 자신 있게 틀립니다.

그래서 도입할 때 필요한 것이 경계 감지입니다. 실무에서 쓸 만한 최소 구성은 세 가지입니다. 입력 임베딩과 학습 분포 중심의 거리, 모델이 낸 결과에 대한 자체 신뢰도, 그리고 하이브리드 검색에서 키워드 점수와 벡터 점수가 크게 엇갈리는지 여부입니다. 셋 중 하나라도 임계를 넘으면 그 요청은 프론티어 모델로 올려 보냅니다.

이 폴백 비율은 처음에 20퍼센트 정도로 넉넉히 잡고, 실제 데이터를 보면서 줄여 가는 편이 안전합니다. 그리고 이 비율이 손익분기 계산에 그대로 들어가야 합니다.

진짜 비용은 유지보수 쪽에 있습니다

원문이 학습 중 부하 이야기를 길게 하는 데는 이유가 있습니다. 후학습은 한 번 하고 끝나는 작업이 아닙니다. 코퍼스가 바뀌면 다시, 사용자 질의 분포가 이동하면 다시, 보상 함수의 허점이 드러나면 다시 돌려야 합니다.

즉 이 선택은 모델을 바꾸는 결정이 아니라 팀에 새 운영 대상이 하나 생기는 결정입니다. 학습 파이프라인, 합성 데이터 생성기, 평가셋, 서빙 스택, 그리고 이 모두를 아는 사람이 필요합니다. 인원이 적은 팀에서 이 비용은 요청당 단가 차이를 쉽게 압도합니다.

특히 보상 함수는 한 번 쓰고 끝나지 않습니다. 검색 품질을 문서 적중으로 정의하면 모델은 적중률이 높은 넓은 질의를 만들도록 학습되고, 인용 정확도를 강하게 걸면 안전하게 원문을 길게 복사하는 쪽으로 기울 수 있습니다. 이런 편향은 학습이 끝난 뒤 실사용 로그에서야 드러나므로, 보상 함수 수정과 재학습을 정기 작업으로 잡아 두는 편이 현실적입니다.

도입 전에 통과시켜야 할 체크리스트

정리하면 이렇습니다. 아래 다섯 개에 모두 그렇다고 답할 수 있을 때만 다음 단계로 갑니다.

항목확인 질문
판정 가능성성공을 사람 없이 코드로 채점할 수 있는가
출력 폭자유 서술이 아니라 정해진 형태로 답이 나오는가
물량손익분기 계산에서 회수 시점이 12개월 안에 오는가
경계학습 분포를 벗어난 요청을 감지해 올려 보낼 수 있는가
인력학습과 서빙과 평가를 계속 굴릴 사람이 있는가

그리고 마지막으로 하나 더. 이 다섯 개를 통과했더라도, 먼저 해야 할 일은 후학습이 아니라 프롬프트와 컨텍스트를 줄여 보는 것입니다. 요청당 비용의 상당 부분은 모델 단가가 아니라 입력 크기에서 나오고, 그쪽은 며칠이면 시도해 볼 수 있습니다. 100배라는 숫자에 끌려 몇 달짜리 프로젝트를 먼저 여는 것이 가장 비싼 실수입니다.

참고 자료

Discuss on Twitter • View on GitHub