1+1은 Opus가 풀어도 Haiku가 풀어도 2다

비용을 줄이겠다고 Opus를 Haiku로 갈아 끼우면 대부분 무너진다. 그런데 재밌는 건, 비싼 모델을 싸게 바꾸는 게 문제인 게 아니라는 점이다. 문제는 모델에 넘긴 일의 크기다. 1+1은 Opus가 풀어도 Haiku가 풀어도 2다. 연산이 충분히 정의되면 누가 풀어도 답은 같다. 결국 비용 최적화는 모델을 내리는 게 아니라 작업을 쪼개는 일이다.

가격표부터 보면 답이 안 나온다

Anthropic 기준으로 Haiku를 1배라고 치면 Sonnet은 대략 3배, Opus는 15배 가까이 간다. 숫자만 보면 결론은 단순해 보인다. “Haiku로 바꾸자.” 그래서 엔지니어가 제일 먼저 시도하는 게 모델 티어를 내리는 작업이다. 프롬프트는 그대로 둔 채, 모델 이름만 opus에서 haiku로 바꾼다.

그리고 거의 항상 품질이 무너진다. 무너지면 다시 Opus로 돌린다. 비용은 그대로고, 시간만 날린다.

대부분은 여기서 “역시 싼 모델은 못 쓰겠네”라고 결론을 낸다. 반대로 생각해야 한다. 싼 모델이 못 푸는 게 아니라, 넘긴 문제가 싼 모델이 풀기엔 너무 뭉쳐 있었던 거다.

고성능 모델이 하던 일은 사실 여러 일이다

Opus에 던지는 프롬프트를 열어보면 대부분 이런 덩어리다. “문맥을 이해하고, 규칙에 맞는지 판단하고, 예외를 골라내고, 톤에 맞게 다듬어서, 마지막에 JSON으로 내놔라.” 문장 하나에 네다섯 가지 일이 섞여 있다. Opus는 이걸 한 호흡에 해낸다. 그래서 Opus를 쓰는 거다.

Haiku에 같은 걸 던지면 당연히 무너진다. 5인분짜리 식판을 초등학생한테 통째로 주는 꼴이다. 못 먹는 게 아니라, 애초에 혼자 먹으라고 만든 구성이 아닌 거다.

여기서 멈추면 영영 Opus를 벗어나지 못한다. 반대로 가야 한다. 식판을 쪼개야 한다. 밥, 국, 반찬, 후식. 각각은 초등학생도 먹는다.

만들 때와 돌릴 때, 모델이 달라야 한다

모델 선택을 한 번에 정하려고 하면 답이 안 나온다. 두 국면을 분리하는 게 먼저다.

만드는 국면은 사람과 AI의 티키타카다. 요구사항이 흐릿하고, 예외가 튀어나오고, 구조가 매일 바뀐다. 이 단계는 Opus가 맞다. 비싸도 쓴다. 왜냐하면 이 단계에서 나오는 건 결과물이 아니라 다음 단계에서 쓸 시스템이기 때문이다. 프롬프트, 검증 로직, 예외 처리, 출력 스키마. 이게 설계 자산이 된다. 이때 돈을 아끼면 평생 Opus를 끼고 살아야 한다.

돌리는 국면은 다르다. 이미 정의된 파이프라인에 입력을 넣고 출력을 받는 반복 작업이다. 여긴 구조가 고정돼 있다. 이 단계에서 Opus를 쓰고 있으면 거의 확실히 낭비다. 잘 쪼개고 잘 조립하면 Haiku와 Sonnet 몇 번의 호출로 같은 품질이 나온다.

정리하면 이렇다. 만들 때는 비싸게, 돌릴 때는 싸게. 그리고 이 둘을 연결하는 게 작업 분해다.

작업 분해의 원칙은 “밖으로 뺀다”

쪼개라는 말은 추상적이다. 구체적으로는 세 가지를 모델 밖으로 빼는 작업이다.

룰은 프롬프트가 아니라 코드로. “이런 경우엔 이렇게 하라”는 조건문이 프롬프트에 쌓이면 저성능 모델이 놓치기 시작한다. if-else로 뺄 수 있는 건 코드로 빼라. 모델은 자연어 판단만 하게 남겨라.

템플릿은 출력이 아니라 입력으로. 출력 형식을 매번 설명하지 말고, 채워 넣을 자리만 비워놓은 템플릿을 쥐여줘라. 모델이 자유 형식으로 작문하지 않으면, 품질 편차가 절반으로 준다.

검증은 모델이 아니라 파이프라인으로. 출력이 맞는지 모델한테 다시 물어보는 건 비싸고 불안정하다. 스키마 검증, 길이 체크, 금칙어 필터 같은 건 결정적 로직으로 밖에서 건다. 이렇게 하면 저성능 모델의 실수를 파이프라인이 잡아준다.

이 세 가지를 빼고 나면 남은 일은 아주 좁다. 좁아진 일이라면 Haiku로도 충분하다. 그리고 그때부터 비용은 몇 분의 일로 떨어진다.

모델을 바꾸는 게 아니라 일의 크기를 바꾼다

흥미로운 건 이렇게 쪼개놓고 나면, 나중에 더 좋은 모델이 나와도 시스템을 안 바꿔도 된다는 점이다. 작업이 충분히 정의돼 있으니까. 반대로 뭉쳐 있는 시스템은 모델이 바뀔 때마다 다시 맞춰야 한다. 이 둘의 장기 비용 차이는 복리로 벌어진다.

그래서 진짜 질문은 “어떤 모델을 쓸까”가 아니다. “이 작업이 Haiku가 풀 수 있을 만큼 충분히 쪼개져 있나”다. 쪼개져 있으면 모델은 부품이다. 안 쪼개져 있으면 모델이 시스템 전체다. 이 차이가 크다.

마무리

비용 최적화라는 말은 오해를 부른다. 비용은 결과지, 목적이 아니다. 진짜 하는 일은 시스템을 단순하게 만드는 일이다. 시스템이 단순해지면 자연히 싼 모델로 돌아간다. 반대로 시스템이 복잡한 채 모델만 바꾸는 건, 5인분 식판을 초등학생에게 넘기고 왜 못 먹냐고 묻는 것과 같다.

1+1은 Opus가 풀어도 Haiku가 풀어도 2다. 문제는 당신이 모델한테 1+1을 주고 있는지, 고차방정식을 주고 있는지다.