야, 이거 봤어? 요즘 AI 비용 이야기가 장난 아니잖아. 그런데 Ramp에서 흥미로운 걸 지적했더라고. 기업들이 AI 지출을 "10분의 1"로 줄일 수 있다고 말이야. 이거 우리한테도 되게 와닿는 얘기다.

생각해 보면 우리도 개발할 때나 뭐 테스트할 때 최신 모델, 제일 좋은 설정부터 쓰는 경우가 많잖아? "프론티어를 샀다고 잘린 사람은 없으니까"라는 말처럼, 괜히 문제 생길까 봐 제일 비싸고 좋은 거부터 깔고 가는 거지. 그런데 이게 사실은 회사 돈을 조용히 태우는 방식이래.

무조건 최신 모델? 그게 더 비효율적일 때가 많다

최근에 나온 Claude Fable 5 모델도 그렇더라. 벤치마크 점수는 압도적이야. SWBench Pro 같은 데선 Opus 4.8이나 GPT-4.5를 훨씬 뛰어넘는대. 처음엔 "와, 이거 물건이다!" 싶었지. 근데 실제 제품 작업에 써보니 이야기가 좀 달라.

Fable 5는 비싸. Opus보다 훨씬 비싸고, 토큰 소모량도 두 배 정도 된다고 하더라. 얘가 마치 '노련한 엔지니어'처럼 문제를 진짜 철저하게 파고들어. 120% 확신할 때까지 모든 구석을 조사하려 든대. 이게 어떤 문제에는 엄청난 강점이지. 복잡한 기술 문제나 긴 호라이즌 작업, 아니면 문서 포맷팅이나 PDF 파싱 같은 비전 작업에는 탁월한 성능을 보여줘. 특히 손글씨 연습지 같은 거 만들 때 기가 막히게 레이아웃을 잡아냈다고 하더라고.

근데 반대로, 스펙 문서나 PRD(Product Requirements Document) 작성 같은 걸 시키면 오히려 답답해져. 너무 상세하고 기술적으로 완벽하긴 한데, 읽기가 너무 힘들대. 디테일에 너무 파묻혀서 전체적인 맥락을 놓치게 만든다는 거야. 심지어 디자인 작업은 "끔찍하게 나빴다"고 평가절하하기도 했어. 회색, 검정, 빨강의 단순한 윤곽선만 내놓더라는 거지.

이게 뭘 의미하냐면, 무조건 최고 성능의 모델이 모든 태스크에 최고는 아니라는 거야. Ramp가 이야기한 "프론티어 문제에만 프론티어 모델"이라는 원칙이 딱 여기에 맞아떨어진다. 복잡하고 어려운 문제에는 Fable 5 같은 비싼 모델이 값을 하지만, 일상적인 루틴 업무나 특정 영역에서는 오히려 다른 저렴한 모델이 더 빠르고 효율적이라는 거지. 이미 맞은 답을 두 번 확인하느라 두 배의 비용을 내는 셈이 될 때도 있다.

AI 비용 효율은 이제 '회사 전략'이다

Ramp는 이런 비용 문제를 해결하려면 '기본값(default setting)'을 잘 정하는 게 중요하다고 강조한다.

  1. 모델 선택: 루틴 업무는 품질 기준을 넘는 가장 싼 모델에서 시작하고, 태스크가 정말 요구할 때만 더 비싼 모델로 올려. 어제의 프론티어 모델도 충분할 때가 많아.
  2. 추론 깊이: 공급자들이 보통 최고 추론을 기본값으로 두는데, 이걸 'medium'으로 낮춰보라는 거야. 한 단계 올릴 때마다 토큰이 두 배씩 늘어나는데, 대부분의 경우 미디엄으로도 충분하대.
  3. 속도 모드: 'fast mode'도 필요할 때만 써. 몇 초 먼저 답 받으려다 두 배를 내는 건 대부분의 경우 나쁜 거래지. 사람이 직접 답을 기다리는 상황이 아니라면, 지연을 허용하는 'flex'나 'batch' 모드가 더 효율적이다.

이렇게 기본값만 제대로 잡아도 같은 결과를 10분의 1 가격에 낼 수 있다니, 솔깃하지 않아? 그리고 이걸 가능하게 하는 건 결국 '문화'의 문제라고 Ramp는 지적한다. 엔지니어는 청구서를 보지 않으니, 가장 큰 모델을 가장 높은 설정으로 쓰는 게 가장 안전한 커리어 선택이 될 수 있다는 거야. 이걸 회사 차원에서 "효율을 제약이 아니라 엔지니어링 성취로 대접"하는 문화로 바꿔야 한다는 거지.

더 나아가, 이경훈 님도 비슷한 이야기를 하는데, AI 시대에는 소프트웨어 회사가 점점 '무거워지고 있다'고 말한다. 예전에는 서버, 네트워크 같은 인프라는 클라우드에 맡기고 애플리케이션만 잘 만들면 됐잖아? 근데 AI 소프트웨어는 답변 하나, 요약 하나, 코드 수정 하나마다 실제 컴퓨트가 들어가. 고객이 많이 쓸수록 매출도 늘지만, 동시에 회사가 처리해야 할 작업량과 원가도 같이 늘어난다는 거야.

제품의 병목이 이제 모델 API 바깥, 즉 compute capacity, latency, 모델 라우팅, fallback 같은 인프라 계층에서 생기는 경우가 많아진다는 거지. 어떤 요청을 더 비싼 모델로 보낼지, 더 빠른 모델로 보낼지, 장애 시 우회 경로는 어떻게 할지 같은 것들이 비용과 속도, 품질을 결정하는 '제품 이슈'가 된다는 거야. 과거엔 인프라팀의 운영 이슈였던 게 이제는 소프트웨어 회사의 핵심 전략이 되어버린 거지.

그러니까 단순히 어떤 모델을 쓸지 고르는 걸 넘어, '우리 회사가 어디까지 인프라 스택을 직접 관리할 것인가', '어떤 계층을 빌리고, 어떤 계층을 직접 설계할 것인가' 같은 전략적 질문을 던져야 할 때가 된 거다. 소프트웨어의 미덕이 오랫동안 '가벼움'이었는데, AI 시대에는 '어디서부터 무거워질지 아는 것'이 강점이 될 수 있다는 말이 되게 와닿는다.

결국 AI를 잘 쓴다는 건, 단순히 최신 모델을 많이 쓰고 비싼 돈을 내는 게 아니라, 태스크 성공률을 높이면서도 가장 효율적인 비용으로 목적을 달성하는 게 중요하다는 이야기다. 그리고 그 효율성은 모델 선택부터 시작해서 인프라 전략까지 연결되는 넓은 시야를 요구하고.

우리 회사 AI 워크플로우는 어때? 지금 어떤 모델을 어떤 설정으로 쓰고 있어? 혹시 아무 생각 없이 '최신', '최고'만 고집하고 있지는 않나?

참고