지난 글까지 이야기한 것은 「무엇이 더 좋은가」를 판정하는 방법이었다. 그런데 운영에서 내리는 결정은 대개 그 모양이 아니다. 더 좋은 쪽은 이미 알고 있고, 문제는 그것이 세 배 비싸다는 것이다. 품질 2점을 얻으려고 비용을 세 배 쓸 것인가가 실제 질문이다.
이 질문에 답하려면 품질과 비용을 같은 표에 놓고 봐야 한다. 그런데 대부분의 평가 파이프라인은 품질만 기록하고 비용은 청구서로만 만난다. 그래서 둘을 맞대 볼 자료가 애초에 없다.
두 축을 한 그림에 놓는다
평가를 돌릴 때 점수와 함께 요청당 토큰과 지연을 기록해 두면 그림 하나가 나온다.
여기서 초록 선이 파레토 프론티어다. 「이보다 싸면서 이보다 좋은 구성이 없는 점들」을 이은 선이고, 고를 만한 후보는 전부 이 선 위에 있다. 선 아래에 있는 붉은 점은 더 싸고 더 좋은 대안이 존재하므로 고를 이유가 없다 — 열등하다고 말한다.
프론티어를 그리는 것만으로 후보가 크게 준다. 대여섯 가지 구성을 놓고 회의하다 보면 각자 다른 이유로 다른 것을 밀게 되는데, 열등한 구성을 먼저 지워 버리면 남는 것은 진짜 저울질뿐이다.
그리고 프론티어의 기울기가 두 번째 정보를 준다. 왼쪽 구간은 가파르다 — 조금 더 쓰면 품질이 많이 오른다. 오른쪽으로 갈수록 눕는다. 위 그림에서 중형에서 「중형 + 자기검증」으로 가는 데 비용 2.1배에 품질 4점을 얻지만, 거기서 대형 최고 구성까지 가면 비용을 두 배 더 쓰고 3점을 얻는다. 같은 돈으로 얻는 품질이 절반 이하로 떨어지는 지점이 어디인지가 결정의 근거가 된다.
품질 하한선을 먼저 못 박는다
프론티어 위에서 어느 점을 고를지는 순수하게 사업 판단이고, 여기서 흔히 순서를 거꾸로 밟는다. 예산을 먼저 정하고 그 안에서 가장 좋은 것을 고르는 방식이다. 이렇게 하면 예산이 빠듯한 시기에 서비스 품질이 조용히 무너진다.
반대로 한다. 「이 아래로는 내려갈 수 없다」는 품질 선을 먼저 정하고, 그 선을 넘는 구성 중 가장 싼 것을 고른다. 하한선은 지난 글의 가드레일 지표처럼 실험마다 새로 정하지 말고 서비스 단위로 한 번 정해 둔다.
하한선을 정할 때 평균 점수로 정하면 안 된다. 평균 82점인 구성과 평균 82점인 다른 구성이 있어도, 한쪽은 60점 아래가 2%이고 다른 쪽은 12%일 수 있다. 사용자가 겪는 것은 평균이 아니라 자기가 받은 그 한 건이다. 하한선은 「하위 5% 점수가 몇 점 이상」이나 「60점 미만 비율이 몇 % 이하」처럼 꼬리 쪽으로 적는 편이 낫다.
비용을 움직이는 레버들
품질을 거의 안 깎으면서 비용을 줄이는 자리가 여럿 있고, 값이 싼 것부터 손대는 것이 순서다.
| 레버 | 비용 영향 | 품질 영향 | 손대는 난이도 |
|---|---|---|---|
| 프롬프트 캐시 | 반복되는 앞부분 비용이 크게 준다 | 없다 | 낮음 |
| 시스템 프롬프트 다이어트 | 매 요청 입력 토큰이 준다 | 줄인 만큼 지시가 사라진다 | 낮음 |
| 출력 길이 제한 | 출력 토큰이 준다 | 잘리면 품질이 급락한다 | 낮음 |
| 컨텍스트 문서 수 줄이기 | 입력 토큰이 비례해 준다 | Recall이 떨어지는 만큼 | 중간 |
| 추론 예산 줄이기 | 추론 모델에서 가장 크다 | 어려운 문제에서만 떨어진다 | 중간 |
| 모델 등급 낮추기 | 가장 크다 | 과제에 따라 천차만별 | 중간 |
| 계단식 라우팅 | 크다 | 검증이 정확하면 거의 없다 | 높음 |
| 증류 · 미세조정 | 아주 크다 | 잘하면 오히려 오른다 | 높음 |
캐시부터 본다. 품질을 전혀 건드리지 않으면서 줄어드는 유일한 레버이고, 시스템 프롬프트와 도구 정의가 긴 에이전트에서 특히 크다. 캐시가 잘 맞으려면 요청의 앞부분이 매번 똑같아야 하므로, 자주 바뀌는 값을 프롬프트 앞쪽에 두지 않는 것이 조건이다.
출력 길이 제한은 함정이 있다. 토큰 상한을 낮추면 비용은 확실히 주는데, 상한에 걸려 잘린 답은 품질이 낮은 정도가 아니라 아예 못 쓰는 답이 된다. 잘린 비율을 따로 세지 않으면 평균 점수가 조금 떨어진 것처럼 보이고 실제로는 몇 %의 사용자가 쓸모없는 답을 받고 있다.
계단식 라우팅이 실제로 아끼는 것
가장 많이 쓰이는 구조는 작은 모델이 먼저 답하고 미덥지 못한 것만 큰 모델로 올리는 방식이다.
숫자를 따라가 보면 이 구조의 성질이 보인다. 전부 대형으로 돌리면 600, 계단식이면 268이다. 그런데 작은 모델을 거친 28건은 두 번 돈을 낸다. 그래서 통과율이 낮아지면 절감이 빠르게 사라지고, 통과율이 아주 낮으면 그냥 전부 대형으로 돌리는 것보다 비싸질 수도 있다.
손익분기를 계산하면 이렇다. 소형 비용 , 대형 비용 , 통과율 일 때 계단식 비용은 이고, 이것이 보다 작으려면
이어야 한다. 위 예에서 이므로 통과율이 17%만 넘으면 이익이다. 여유가 커 보이지만, 이 계산은 검증 비용이 0일 때의 이야기다. 검증을 모델로 한다면 그 비용이 쪽에 더해지고 손익분기가 올라간다.
그래서 실제로 중요한 것은 검증기다. 검증기는 두 가지를 다 틀릴 수 있다.
- 통과시키면 안 될 것을 통과시킨다. 나쁜 답이 사용자에게 간다. 품질 하락이 여기서 나온다
- 통과시켜도 될 것을 막는다. 비용만 더 든다. 품질은 안 떨어진다
둘의 무게가 다르므로 검증기의 임계값은 막는 쪽으로 치우치게 잡는 것이 보통이다. 그리고 이 임계값이 곧 비용과 품질을 잇는 손잡이라서, 임계값을 몇 단계로 바꿔 가며 위의 프론티어 그림을 다시 그려 보면 어디가 좋은 자리인지 눈으로 보인다.
값싼 검증기부터 시도해 볼 만하다. 형식 검사, 필수 필드 존재, 근거 인용 여부, 모델이 낸 확신도 같은 것들은 거의 공짜다. 이것들로 걸러지지 않는 것만 모델 검증에 보낸다.
무엇을 단위로 셀 것인가
비용을 기록하기 시작하면 곧 「무엇으로 나눌 것인가」 문제가 생긴다. 단위를 잘못 잡으면 개선이 개선으로 안 보인다.
요청당 비용은 가장 흔하지만 실패한 요청도 세므로, 실패를 늘리면서 싸지는 변경이 좋아 보인다. 성공한 요청당 비용으로 세면 이 함정이 사라진다. 재시도가 있는 시스템에서는 이쪽이 거의 항상 맞다.
에이전트처럼 한 과제에 여러 요청이 들어가는 시스템은 과제당 비용으로 센다. 요청당으로 세면 걸음을 잘게 쪼개는 변경이 저렴해 보인다.
그리고 사람 비용을 빼고 세지 않는다. 자동 검증을 못 믿어서 사람이 검수하는 단계가 있다면 그것이 전체 비용의 대부분인 경우가 많다. 모델 비용을 30% 줄이는 것보다 검수 비율을 절반으로 줄이는 편이 훨씬 큰데, 모델 비용만 기록하고 있으면 그 사실이 안 보인다.
정리
비용과 품질은 하나를 고르는 문제가 아니라 곡선 위에서 자리를 고르는 문제다. 그러려면 곡선이 있어야 하고, 곡선을 그리려면 평가를 돌릴 때 점수 옆에 토큰과 지연을 같이 적어 두기만 하면 된다. 이 한 줄이 없어서 대부분의 팀이 저울질을 감으로 한다.
순서를 정리하면 이렇다. 품질 하한선을 꼬리 쪽 지표로 못 박고, 프론티어를 그려 열등한 구성을 지우고, 값싼 레버부터 당긴다. 그러고도 모자라면 그때 계단식과 미세조정 같은 비싼 작업으로 간다.
읽어주셔서 감사합니다. 😊