AI 파인튜닝이 쉬워질 때 작은 팀이 버려야 할 것

접근성이 높아진다는 건 선택지가 늘어난다는 뜻이다. 그리고 작은 팀에게 선택지가 늘어나는 건 더 많이 할 수 있다는 신호가 아니라, 더 많이 버려야 한다는 신호다.

Trajectory라는 1년 된 스타트업이 4,500만 달러(약 620억 원)를 유치했다. 기업가치 3억 달러. 핵심 주장은 단순하다. ML 엔지니어 없이도 도메인 특화 AI 모델을 훈련할 수 있게 하겠다는 것. 비기술 전문가가 자기 데이터를 가져와 클릭 몇 번에 맞춤 모델을 만드는, 이른바 "AI 딸깍" 세상을 만들겠다는 그림이다.

작은 팀 입장에서 이 뉴스의 핵심은 "이제 우리도 파인튜닝을 해볼 수 있겠다"가 아니다. 오히려 그 반대다. 접근성이 낮아서 못 했던 것과 실제로 할 필요가 없는 것을, 이제 더 의식적으로 구분해야 한다. 그 경계가 흐릿해지기 시작하는 지금이 위험하다 — 그리고 그 기준을 세우는 게 생각보다 까다롭다.

Trajectory가 해결하려는 것, 그리고 여전히 남는 것

ML 엔지니어 한 명 인건비는 연 1억 5천~2억이다. GPU 인프라, 실험 추적 도구, 배포 파이프라인까지 붙으면 작은 팀 예산 한 분기가 증발한다. Trajectory는 이 진입 장벽 자체를 낮추겠다는 것이고, 투자자들이 3억 달러 밸류를 베팅한 건 그 시장 규모에 대한 확신이다.

실제로 의미 있는 문제 영역이 있다. 병원 EMR 데이터, 특정 업계 계약서 검토, 제조 현장 불량 분류 — 이런 도메인에서 범용 모델의 한계는 명확하다. 프롬프트 엔지니어링을 아무리 공들여도, 몇 년치 현장 데이터로 훈련한 작은 모델이 더 정확한 케이스가 분명히 있다. "딸깍보다 조금 더 쉽게" 그 격차를 메우겠다는 게 Trajectory의 포지션이다.

그런데 도구가 기술 장벽을 낮춰도 없애지 못하는 부분이 있다. 모델 훈련은 시작일 뿐이다. 데이터 정제, 라벨링, 평가 지표 설계, 모델 드리프트 모니터링, 재훈련 주기 관리 — 이건 GUI로 추상화되지 않는다. 훈련은 쉬워졌는데 운영이 따라오지 못하면, "왜 모델이 예전보다 나빠졌지?"라는 질문 앞에서 몇 달을 허비하게 된다.

숫자로 보면 선명해지는 착시

파인튜닝 비용을 직접 계산해보면 첫인상이 달라진다. OpenAI 파인튜닝 API 기준, gpt-4o-mini는 훈련 토큰 1M당 8달러, 추론 시 12달러다. 10만 건 예시 데이터를 3 에포크 돌리면 훈련 비용은 수십만 원 수준 — 여기까지는 의외로 싸다.

진짜 청구서는 그 다음에 온다. 데이터 준비에 드는 인건비, 평가 파이프라인 구축, 그리고 결정적으로 — 기대만큼 안 나왔을 때 디버깅하는 시간. 직접 파인튜닝 실험을 잠깐 건드려본 적이 있는데, 정작 시간이 제일 많이 든 건 "왜 이 케이스는 계속 틀리지?"를 추적하는 부분이었다. 그 시간에 프롬프트를 열 번 고쳤다면 훨씬 나았을 것이다.

Trajectory가 이 중간 과정을 얼마나 추상화해주느냐가 성패를 가른다. 3억 달러 밸류에이션은 그 가능성에 대한 베팅이다. 틀릴 수도 맞을 수도 있지만, 이게 지금 당장 우리 팀 의사결정을 흔들 근거가 될 수는 없다.

작은 팀의 의사결정: 선택보다 포기가 더 어렵다

5인 이하 팀에서 리소스 의사결정의 핵심은 무엇을 하느냐가 아니다. 무엇을 안 하기로 했느냐다. 진부하게 들리지만, Trajectory 같은 뉴스가 나올 때마다 이 원칙이 실제로 시험대에 오른다.

우리 팀은 현재 Claude API를 호출하는 봇이 10개 넘게 운영 중이다. 다이어트, 보험, 로또, 정부지원사업 등 도메인이 다양하다. 각 봇에서 프롬프트와 시스템 지시문을 잘 정제하면 품질이 충분히 나온다.

이 상태에서 파인튜닝을 검토할 기준점을 세운다면 두 가지로 압축된다. 프롬프트 엔지니어링으로 명확히 안 되는 케이스가 문서화됐는가. 그리고 그 케이스를 담당할 사람이 있는가 — 이름을 바로 댈 수 없다면, 팀이 가져갈 준비가 된 게 아니다.

담당자 없는 인프라는 반드시 사고가 난다. 이건 코드로 겪은 거라 확실히 말할 수 있다. 기술적으로 쉬워진 도구라도 관리 주체가 흐릿하면 어느 순간 아무도 모르는 상태로 돌아가게 된다.

우리 팀이라면: 검토할 것 하나, 포기할 것 하나

팀 맥락에서 파인튜닝을 진지하게 검토할 시나리오는 하나 있다. 콘텐츠 품질 검수 자동화다. 지금 발행 파이프라인에서 Claude Sonnet이 검수 판정을 담당하고 있는데, 우리 사이트별 기준에 특화된 더 작은 모델로 교체하면 API 비용을 의미 있게 줄일 수 있다.

이 케이스가 검토할 만한 이유는 세 조건이 동시에 갖춰져 있어서다. 도메인이 명확하다. 데이터가 쌓이고 있다. 평가 기준이 이미 정의돼 있다. 파인튜닝이 효과를 내는 조건의 교과서 같은 케이스다. Trajectory 같은 도구가 성숙하면 6~12개월 후 다시 볼 이유가 있다.

반면 바로 포기할 시나리오는 각 봇의 본문 생성 자체를 파인튜닝 모델로 교체하는 것이다. 지금 Haiku로 충분히 잘 돌아가고 있다. "더 좋을 것 같다"는 직관이 들어도, 측정 가능한 품질 델타 없이는 건드리지 않는다. 유지보수 복잡도가 올라가는 비용이 성능 개선 이득을 금방 넘어선다.

지금 바로 써먹을 판단 기준

이런 종류의 뉴스가 나올 때마다 팀 안에서 반복해야 할 질문이 있다. 순서가 중요하다.

가장 먼저 물어야 할 것은 "프롬프트 엔지니어링으로 막히는 케이스가 실제로 문서화돼 있는가"다. 막연히 더 잘할 것 같다는 감이 아니라, 구체적인 실패 패턴 목록이 있어야 ROI를 계산할 수 있다. 이 목록이 없는 상태에서 시작하면 어디서 멈춰야 할지 기준 자체가 없다.

그 다음은 데이터다. 해당 케이스에 라벨링된 예시가 100건 이상 쌓였는가. 없다면 어떤 도구를 써도 시작하지 마라. Trajectory가 클릭 몇 번으로 만들어주는 건 훈련 파이프라인이지, 데이터 품질이 아니다.

마지막은 비용 계산이다. 현재 월 API 비용이 정확히 얼마인지 알고 있는가. 수십만 원 수준이라면 파인튜닝 세팅에 투입할 엔지니어링 시간이 훨씬 더 비싸다. "비용 절감을 위한 파인튜닝"을 검토하기 전에, 절감 대상 비용부터 먼저 집계하라.

Trajectory가 약속하는 방향 — 비기술 전문가도 도메인 모델을 만들 수 있다 — 은 분명히 가치 있다. 다만 선택지가 많아질수록 버릴 것을 더 선명하게 골라야 한다. 리소스 제약 팀의 레버리지는 거기서 만들어진다.

원문: AI News & Artificial Intelligence | TechCrunch