Stop Overpaying for Intelligence

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Stop Overpaying for Intelligence를 중심으로, 저렴한 토큰 단가가 저렴한 작업 비용을 보장하지 않는다. 토큰 사용량이 늘거나 사람이 개입해야 한다면, 실제 작업 완료 비용은 더를 핵심 판단 포인트로 압축 정리한다.

📌 핵심 요점

1. 저렴한 토큰 단가가 저렴한 작업 비용을 보장하지 않는다. 토큰 사용량이 늘거나 사람이 개입해야 한다면, 실제 작업 완료 비용은 더 높아질 수 있다.
2. 작업과 요구 정확도를 먼저 정의하고 대표 평가셋을 구성해야 한다. 모델·설정·실행 구성을 비교해 정확도 기준을 충족하는 최소 비용 조합을 찾는 것이 모델 선택의 출발점이다.
3. 작은 모델도 충분한 성능을 낼 수 있다. 단순 분류·정보 추출에는 작은 모델을 일찍 시험하고, 복잡한 작업에는 높은 지능의 모델부터 시작해 비용과 정확도의 파레토 경계를 탐색하라는 제안이다.
4. 모델 선택 외에도 프롬프트 캐싱, 프로그램 기반 도구 호출, 추론 노력 조정, Batch·Flex 처리가 비용을 바꾼다. 반복 입력과 중간 데이터를 줄이고, 응답을 기다릴 수 있는 작업은 별도로 처리하는 방식이다.
5. 최적화는 한 번에 설정 하나를 바꾸고 평가를 반복하는 과정이다. 고객 사례의 절감률을 그대로 기대하기보다, 자신의 작업에서 품질·비용·지연 시간을 함께 측정해야 한다.

🧩 배경과 문제 정의

DevDay 2026의 이 패널은 OpenAI의 AI 배포 엔지니어링 담당자들이 고객 사례를 바탕으로 AI 비용 최적화를 설명하는 자리다. 논의는 비용을 측정하는 기준에서 시작해 작업에 맞는 모델 선택, 모델 외의 비용 조정 수단으로 이어진다.

핵심 문제는 입력·출력 토큰 단가만 보고 모델을 선택하면 실제 작업 완료 비용을 놓칠 수 있다는 점이다. 발표자들은 작업과 요구 정확도를 먼저 정하고, 모델 사용량과 사람의 개입을 함께 고려하면서 성공률·비용·지연 시간을 평가하자고 제안한다.

🕒 시간순 섹션별 상세정리

1. 비용 최적화의 출발점은 작업당 비용

• 진행자는 비용 측정 기준, 작업에 맞는 모델 크기, 모델 외의 최적화 수단을 고객 사례와 함께 다루겠다고 보여준다. [00:41]
• Mandeep은 토큰 단가가 낮은 모델도 더 많은 토큰을 쓰거나 작업을 끝내지 못할 수 있다고 보여준다. [01:39]
• 사람이 개입해야 하는 상황까지 고려하면, 개발자와 기업이 봐야 할 지표는 토큰당 비용보다 작업당 비용이라는 주장이다. [01:51]

2. 항공사 챗봇이 보여준 숨은 비용

• Mandeep은 항공편 변경 과정에서 야간 비행을 피하려는 요구를 챗봇이 이해하지 못해 사람 상담원을 요청했던 경험을 보여준다. [02:48]
• 상담원이 실제 예약 변경을 완료했으므로 총비용에는 토큰 사용료와 상담원의 작업 시간이 함께 들어간다. [03:22]

3. 고객 사례와 토큰 효율의 의미

• Perplexity는 연구 벤치마크에서 전사상 ‘six Astra’가 이전 모델보다 정확한 결과를 9% 더 내면서 비용은 절반이었다고 보고한 사례로 묶인다. [03:47]
• 발표자는 이 사례를 더 적은 토큰으로 작업을 마치는 효율의 예로 설명하고, Notion 역시 모델 전환 후 정확도 개선과 작업당 비용 절반을 보고했다고 덧붙인다. [04:16]
• 진행자는 작업의 성공 여부와 함께 토큰 효율이 비용에 영향을 준다는 점을 정리한다. [04:31]

4. 요구 정확도를 먼저 정하고 파레토 곡선을 그리기

• 모델 선택에 앞서 작업과 기대 정확도를 명확히 정의해야 한다. 항공사 문의의 80%를 챗봇이 해결한다는 목표는 가상의 예시로 드러난다. [05:22]
• 목표는 모델·실행 구성·설정의 조합 가운데 요구 정확도를 가장 낮은 비용으로 달성하는 구성을 찾는 것이다. [05:34]
• 여러 모델과 설정을 시험해 정확도와 비용을 비교하고, 정확도 기준을 충족하는 비용 효율적인 조합을 찾는 파레토 곡선 접근을 보여준다. [06:10]

5. 작업 난이도에 따른 모델 탐색 순서

• 단순 라우팅에는 Luna, 복잡한 계획에는 Astra를 고려하는 예가 나오며, 적합한 모델이 미리 분명하지 않을 때의 접근법을 묻는다. [06:29]
• 단순 분류나 문서의 몇 개 필드 추출은 작은 모델을 일찍 시험하고, 높은 지능이 필요한 작업은 ‘six Astra’부터 시작하라는 제안이다. [07:18]
• 평가셋에서 요구 정확도를 만족하는 모델을 찾고, 이후 비용을 최적화하는 순서로 압축된다. [07:43]

6. Luna의 추론 설정과 작은 모델의 가능성

• ‘Luna maxing’은 Luna의 추론 노력을 높게 설정해 이전 세대의 더 큰 모델 등에 필적하거나 앞서는 성능을 얻는 접근으로 드러난다. [08:15]
• 일부 고객은 코딩의 기본 모델로 Luna를 사용하고 더 높은 지능이 필요할 때 다른 모델로 전환하며, 고객 워크플로의 80~90%에서 잘 작동한다는 경험담이 묶인다. [08:34]
• 작은 모델의 가능성을 직접 시험하라는 권고와 함께, 단순 작업을 위한 Decisions API 발표가 짧게 나온다. [08:44]

7. 모델 외의 네 가지 수단과 프롬프트 캐싱

• Sapto는 같은 모델 계열도 처리하는 정보량과 원하는 출력에 따라 비용이 달라진다고 보여준다. [09:23]
• 비용 조정 수단으로 프롬프트 캐싱, 프로그램 기반 도구 호출, 추론 노력, Batch·Flex 처리를 제시한다. [09:40]
• 회사 정책과 문서를 반복 사용하는 고객지원 사례에서, 캐싱은 공통 입력의 전처리를 재사용하면서 새로운 정보와 응답은 매번 처리하는 방식으로 드러난다. [10:17]

8. 도구 결과를 코드로 처리해 모델의 부담 줄이기

• 주문 처리 에이전트가 여러 도구로 재고와 입고 정보를 조회하는 예를 통해, 모델이 모든 결과를 직접 읽고 비교할 필요가 있는지 묻는다. [11:13]
• 프로그램 기반 도구 호출에서는 모델이 작은 프로그램을 실행하고, 프로그램이 도구 호출과 결과 처리를 조정한 뒤 정리된 보고를 모델에 전달한다. [12:01]
• 모든 중간 데이터를 모델에 다시 보내는 과정을 줄이고, 워크플로의 단계마다 발생하는 모델 호출도 줄일 수 있다고 보여준다. [12:17]

9. Clio의 다단계 문서 분석 사례

• 법률 분야 소프트웨어 기업 Clio가 프로그램 기반 도구 호출을 사용한 고객 사례로 묶인다. [12:32]
• Clio는 다단계 문서 분석에서 품질 손실 없이 전사상 ‘PROM tokens’를 38% 줄였다고 보고했다. 발표자는 애플리케이션과 모델의 상호작용 방식을 바꾼 효과로 보여준다. [12:52]

10. 추론 노력과 대기 가능한 작업의 비용 조정

• 추론 노력은 답변 길이와 다른 설정이며, 짧은 답변도 많은 추론을 요구할 수 있다. 라우팅은 낮은 추론 노력부터 시작하고 평가로 품질을 확인하라는 권고다. [13:28]
• 어려운 작업에서는 추가 토큰 비용이 가치 있을 수 있으므로, 반복 평가로 설정을 결정해야 한다고 강조한다. [13:42]
• 대량 문서 처리처럼 기다릴 수 있는 작업에는 Batch를 보여준다. 영상에서는 24시간 처리 창과 표준 동기 요청 대비 50% 낮은 토큰 가격을 제시한다. [14:20]

11. 작업 전체를 추적하고 성공 결과를 기준으로 개선하기

• 작업 하나를 끝까지 따라가며 입력·출력, 반복 처리, 도구 호출 수를 살펴보고, 설정 하나를 바꾼 뒤 평가를 반복하라는 제안이다. [15:14]
• 최적화의 목표를 낮은 비용과 허용 가능한 지연 시간으로 성공적인 결과를 얻는 것으로 정리한다. [15:28]
• 진행자는 캐시 입력의 비용이 최대 90% 낮아질 수 있다는 설명과 함께, 코드로 데이터 처리를 옮기기, 추론 노력 조정, 긴급하지 않은 요청의 지연 처리를 다시 요약한다. [16:38]

12. 캐시 재사용을 높이는 프롬프트 구조와 Blitzy 사례

• 캐싱은 기본 활성화되어 있지만 충분히 활용되지 않는 경우가 있다며, 프롬프트 앞부분을 가능한 한 일관되게 유지하라고 권고한다. [17:34]
• 공통 지침의 전처리를 재사용하고 새 정보는 새로 처리하는 구조가 비용과 지연 시간을 줄인다고 보여준다. [18:02]
• Blitzy는 단일 구조화 출력 호출에서 Luna의 도구 호출 루프로 전환한 뒤 캐시 재사용률 24%→90%, 전사상 ‘output prompt tokens’ 8.5배 감소, 비교 모델 대비 비용 87% 감소, 처리 컨텍스트 2.2배 확대를 보고한 사례로 묶인다. [18:40]

13. 명시적 캐시 경계와 관측 도구

• 명시적 경계는 안정적인 코딩 지침 뒤와 매번 바뀌는 작업 앞에 캐시 경계를 두는 방식으로 드러난다. ‘explicit only mode’는 재사용할 특정 부분을 선택하는 기능으로 묶인다. [20:10]
• 전사상 ‘GPD 6 Astra’에서는 대화 중 추론 노력을 바꿔도 캐시를 유지할 수 있다고 보여준다. 진행자는 허용 도구 등의 매개변수로 도구 구성을 바꾸면서 캐시를 유지하는 기능도 언급한다. [20:47]
• 관리자 페이지의 캐싱 대시보드로 적중률을 추적하고, 진단 API로 두 요청 사이의 캐시 미스 발생 지점을 파악할 수 있다고 보여준다. [21:17]

14. 마무리 실행 지침과 반복 평가

• 마지막 정리에서도 가격표보다 작업 완료 비용을 보고, 작업에 맞는 모델과 캐싱·도구 호출·추론 설정·지연 처리 수단을 함께 검토하라고 강조한다. [21:43]
• Mandeep은 작업과 정확도 기준을 정의하고 대표 평가셋에서 여러 모델·설정·프롬프트를 시험한 뒤, 파레토 경계에서 적합한 실행 구성을 찾으라고 권고한다. [22:30]
• Sapto는 한 번에 한 가지 변경을 시험해 개선된 설정을 유지하고, 애플리케이션과 모델이 발전할 때마다 평가를 반복하라고 드러낸다. 감사 인사와 현장 질문 안내로 패널이 끝난다. [22:49]

🧾 결론

• 비용 지표에는 모델 사용료뿐 아니라 작업을 마무리하는 데 들어간 사람의 시간도 포함해야 한다.
• 목표 정확도를 만족하는 모델과 실행 구성을 선택하고, 캐싱·도구 호출·추론 설정으로 추가 비용을 조정하는 순서가 제시된다.
• 모델에 모든 원본 데이터와 중간 결과를 읽히기보다, 코드로 처리할 수 있는 부분을 정리해 필요한 판단만 맡기는 설계가 유효하다.
• 최종 목표는 낮은 비용과 허용 가능한 지연 시간으로 성공적인 결과를 얻는 것이다. 애플리케이션과 모델이 바뀌면 같은 기준으로 다시 평가해야 한다.

📈 투자·시사 포인트

• AI 서비스의 단위 경제성을 판단할 때 토큰 가격표만으로는 부족하다. 자동 해결률과 사람에게 넘어가는 작업량이 실제 운영 비용을 좌우할 수 있다.
• 모델 교체와 애플리케이션 설계 개선은 모두 비용 경쟁력의 원천이 될 수 있다. 영상에서는 Perplexity·Notion의 모델 전환 사례와 Clio·Blitzy의 실행 방식 변경 사례가 함께 제시된다.
• 캐시 재사용률, 도구 호출 구조, 추론 설정을 측정하고 개선하는 역량은 AI 제품의 운영 효율을 평가하는 단서가 된다.
• 즉시 응답이 필요한 서비스와 대기 가능한 대량 처리는 비용 구조가 다르다. 영상에서 소개한 Batch의 할인은 처리 시간을 기다릴 수 있다는 조건과 함께 해석해야 한다.

⚠️ 불확실하거나 확인이 필요한 부분

• 고객 성과는 발표자가 소개한 보고 수치다. Perplexity의 정확도 9% 개선·비용 절반, Notion의 작업당 비용 절반 등이 어떤 평가셋과 비용 범위에서 측정됐는지는 전사문에 충분히 설명되지 않는다.
• 모델·제품 명칭에 전사 오류로 보이는 표기가 섞여 있다. ‘six Astra’, ‘5.6 sold’, ‘GPD’ 등의 정확한 공식 명칭은 이 자료만으로 확정하기 어렵다.
• Clio 사례의 ‘PROM tokens’와 Blitzy 사례의 ‘output prompt tokens’는 표현이 불명확하다. 각각 어떤 토큰 지표를 뜻하는지 확인하기 전에는 입력·출력 토큰 절감으로 단정하지 않는 편이 적절하다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 대표 작업 하나를 정하고 성공 조건, 요구 정확도, 허용 지연 시간을 명시한다.
• 실제 사용을 대표하는 평가셋을 만들고, 모델 비용과 사람의 개입 시간을 함께 기록한다.
• 여러 모델·추론 설정·실행 구성을 비교해 정확도와 작업당 비용의 파레토 경계를 그린다.
• 반복되는 지침과 문서를 프롬프트 앞부분에 안정적으로 배치하고 캐시 재사용률을 측정한다.

❓ 열린 질문

• 우리 서비스에서 사람이 개입하는 비용까지 포함하면, 현재 가장 저렴한 모델은 무엇인가?
• 정확도 기준을 유지하면서 작은 모델이나 낮은 추론 노력으로 처리할 수 있는 작업은 어느 범위인가?
• 캐시 재사용을 막는 변동 입력은 어디에 있으며, 안정적인 지침과 분리할 수 있는가?