모델 최적화보다 오래가는 자산은 Eval-Driven 시스템이다
회사 AI팀이 자주 착각하는 게 있습니다.
오픈소스 모델을 더 잘 만지고, 프롬프트를 더 정교하게 짜고, 출력을 더 예쁘게 다듬으면 경쟁력이 쌓인다고 믿는 일입니다.
물론 그런 최적화도 필요합니다. 문제는 그 자산이 생각보다 오래 가지 않는다는 점입니다.
모델은 계속 바뀝니다.
- 속도가 바뀌고
- 가격이 바뀌고
- 품질 우위가 뒤집히고
- 프롬프트 민감도도 다시 흔들립니다
그래서 많은 팀이 계속 일은 하는데 자산은 많이 안 쌓입니다.
왜 최적화 자체는 빨리 증발하는가
특정 모델에 맞춘 튜닝은 대체로 세 가지에 묶입니다.
- 그 모델의 출력 성향
- 그 모델의 컨텍스트 처리 특성
- 그 모델의 비용과 속도 구조
그런데 이 셋은 다음 모델이 나오면 금방 달라집니다.
오늘 잘 먹히던 프롬프트가 내일은 덜 먹히고, 이전에 비용이 안 맞던 작업이 새 모델에선 갑자기 가능한 일이 됩니다.
이때 중요한 건 "우리가 예전에 얼마나 잘 튜닝했는가"가 아닙니다.
새 모델이 나왔을 때 얼마나 빨리 다시 비교하고, 다시 맞추고, 다시 실전에 넣을 수 있는가가 훨씬 중요합니다.
그때 남는 자산이 Eval-Driven 시스템이다
제가 말하는 Eval-Driven 시스템은 거창한 플랫폼만 뜻하지 않습니다.
핵심은 단순합니다.
- 같은 문제를 여러 모델에 반복해서 돌려본다
- 무엇이 좋아졌고 무엇이 망가졌는지 기록한다
- 품질, 속도, 비용 기준으로 비교한다
- 기준을 통과한 것만 실전에 넣는다
- 결과가 흔들리면 다시 돌린다
이 루프가 있으면 모델이 바뀌어도 팀이 무너지지 않습니다.
반대로 이 루프가 없으면 팀은 늘 감으로 판단하게 됩니다.
새 모델이 나올 때마다 내부에서는 이런 대화가 반복됩니다.
- "이게 더 좋은 것 같긴 한데요"
- "체감상 빨라진 것 같아요"
- "프롬프트 조금만 바꾸면 될 것 같아요"
이런 조직은 속도는 있어 보여도 재현성이 없습니다.
실무에서는 무엇부터 만들면 되는가
처음부터 복잡한 플랫폼을 만들 필요는 없습니다.
제가 먼저 권하는 건 아래 다섯 가지입니다.
- 자주 반복되는 실제 입력 30개에서 100개를 모은다
- 좋은 출력의 기준을 팀 안에서 먼저 합의한다
- 품질, 속도, 비용을 한 번에 비교한다
- 모델 교체 때마다 같은 세트로 다시 돌린다
- 결과를 짧은 메모라도 남긴다
이렇게만 해도 감 의존도가 확 줄어듭니다.
결국 귀한 사람은 무엇을 만든 사람인가
앞으로 더 귀해질 사람은 특정 모델의 마법 같은 프롬프트를 아는 사람이 아닙니다.
모델이 바뀌어도 성능을 다시 끌어올리는 시스템을 만든 사람입니다.
그 차이는 큽니다.
전자는 모델의 우위를 빌려옵니다. 후자는 조직의 학습 속도를 직접 만듭니다.
AI 시대의 경쟁력은 점점 후자 쪽으로 이동할 가능성이 높습니다.