GPT-6 운영 가이드: 모델 선택·캐싱·컴팩션으로 작업당 비용 줄이는 법

OpenAI가 공개한 GPT-6 모델 가이드는 새 모델 홍보문보다 운영 매뉴얼에 가깝다. 핵심은 “가장 똑똑한 모델을 항상 쓰라”가 아니다. 작업 성격에 맞춰 모델, 추론 강도, 속도 모드, 캐싱, 컴팩션, 비동기 도구 호출을 조합하라는 내용이다.

LLM 기능을 운영하는 팀이 봐야 할 지표도 토큰 단가 하나가 아니다. 실제로는 성공한 작업 1건당 비용, 평균 지연시간, 실패 후 재시도율, 사람 검토 비용, 캐시 적중률이 더 중요하다. 토큰은 싸졌는데 실패율이 올라가면 총비용은 줄지 않는다. 반대로 비싼 모델이라도 한 번에 끝내면 더 저렴할 수 있다.

먼저 작업을 세 단계로 나눈다

모델 선택 전에 업무를 분류해야 한다. 대략 세 종류로 나누면 운영 판단이 쉬워진다.

첫째는 반복적이고 목표가 분명한 작업이다. 송장 필드 추출, 문의 분류, 짧은 요약, 포맷 변환, 라벨링처럼 정답 구조가 명확하다. 이런 작업은 낮은 추론 강도와 빠른 모델을 우선 검토한다. OpenAI 가이드에서는 GPT-6 Luna가 이런 스케일 작업에 맞는 모델로 언급된다.

둘째는 판단이 필요한 작업이다. 기능 기획 비교, PR 리뷰, 로그 원인 분석, 고객 문의 답변 초안처럼 맥락과 선택지가 있다. 이때는 중간 추론 강도와 더 강한 모델을 쓰되, 무조건 최고 옵션으로 올리기보다 실패 유형을 보고 조정한다.

셋째는 어려운 추론과 장시간 작업이다. 복잡한 디버깅, 여러 저장소를 넘나드는 변경, 리서치, 브라우저나 외부 API를 쓰는 작업이다. GPT-6.1 Sol이나 GPT-6 Astra 같은 모델을 후보로 두고, 필요할 때만 높은 추론 강도를 쓴다.

캐싱은 프롬프트 구조 문제다

OpenAI는 프롬프트 캐싱을 통해 캐시된 입력 토큰 비용을 모델에 따라 최대 95%까지 줄일 수 있다고 설명한다. 하지만 캐싱은 버튼 하나로 해결되지 않는다. 프롬프트 구조가 흔들리면 캐시가 깨진다.

안정적인 시스템 지침, 도구 정의, 회사 규칙, 긴 참고 자료는 앞쪽에 둔다. 매 요청마다 바뀌는 사용자 입력, 현재 티켓, 최근 로그, 임시 조건은 뒤쪽에 둔다. 도구 스키마를 매번 다른 순서로 만들거나, 날짜·요청 ID 같은 변동값을 앞쪽에 끼워 넣으면 캐시 효율이 떨어진다.

실무에서는 캐시 적중률을 비용 대시보드에 올려야 한다. 단순히 “이번 달 토큰 비용”만 보면 왜 비용이 튀었는지 모른다. 배포 후 캐시 적중률이 떨어졌다면 프롬프트 템플릿, 도구 정의, 컨텍스트 조립 순서를 먼저 확인해야 한다.

긴 대화는 컴팩션 기준을 정해야 한다

장시간 에이전트 작업에서는 컨텍스트가 계속 커진다. 모든 로그, 이전 대화, 파일 내용을 그대로 넣으면 지연시간과 비용이 같이 증가한다. 컴팩션은 긴 컨텍스트를 줄이면서 다음 행동에 필요한 상태를 보존하는 방식이다.

문제는 무엇을 버릴지 정하는 일이다. 단순 요약은 위험하다. 예를 들어 “사용자가 결제 관련 버그를 신고했다”는 요약만 남기고, 실제 에러 코드와 재현 조건을 버리면 다음 단계에서 엉뚱한 수정이 나온다.

좋은 컴팩션은 상태를 구조화한다. 현재 목표, 완료한 작업, 남은 작업, 검증된 사실, 불확실한 가설, 사용자 승인 필요 항목, 변경한 파일, 실패한 시도를 따로 남긴다. 로그 원문 전체는 버리더라도 핵심 스택트레이스와 재현 입력은 보존한다.

비동기 도구 호출과 병렬 작업은 비용보다 지연시간에 효과가 크다

GPT-6 가이드는 비동기 도구 호출과 독립 작업 병렬화를 강조한다. 테스트 실행, 크롤링, 빌드, 외부 API 조회처럼 오래 걸리는 도구가 있을 때 모델이 멈춰 있지 않고 독립적인 작업을 계속 진행할 수 있게 하는 방식이다.

단, 의존성이 있는 작업까지 병렬화하면 오히려 사고가 난다. 예를 들어 데이터 마이그레이션 결과를 봐야 다음 쿼리를 만들 수 있는데, 결과를 기다리지 않고 추측으로 진행하면 복구 비용이 더 커진다. 병렬화 기준은 “서로 결과에 의존하지 않는가”다.

실무 예시는 간단하다. 코딩 에이전트가 버그를 고칠 때 한쪽에서는 테스트를 실행하고, 동시에 관련 문서를 읽고, 독립적으로 영향 파일을 정리할 수 있다. 하지만 테스트 결과가 필요한 수정은 결과가 돌아온 뒤 해야 한다.

운영 지표를 이렇게 잡는다

모델 라우팅을 감으로 하면 비용이 계속 샌다. 최소한 아래 지표를 모델·작업 유형별로 나눠 봐야 한다.

• 성공한 작업 1건당 총 비용
• 첫 응답까지 걸린 시간과 전체 완료 시간
• 재시도율과 사람 개입률
• 캐시 적중률
• 컴팩션 이후 오류율
• 추론 강도별 품질 개선 폭
• 도구 호출 실패율

특히 “비싼 모델을 썼으니 품질이 좋다”는 가정은 버려야 한다. 루틴 작업에서는 작은 모델이 더 빠르고 충분히 정확할 수 있다. 반대로 복잡한 작업에서 싼 모델을 여러 번 재시도하면 더 비싸다.

예산을 정할 때 빠뜨리기 쉬운 항목

예산표에는 입력 토큰과 출력 토큰만 넣기 쉽다. 실제 운영비에는 캐시 쓰기 비용, 긴 컨텍스트 요금, 도구 실행 비용, 벡터 검색 비용, 브라우저 자동화 인프라, 실패 후 재시도 비용이 같이 들어간다. 특히 장시간 에이전트는 한 번 실패하면 이전 단계의 도구 실행 비용까지 다시 쓰는 경우가 많다.

그래서 사전 견적은 “요청 1건 비용”이 아니라 “완료된 업무 1건 비용”으로 잡아야 한다. 예를 들어 고객 문의 자동 답변이 100원에 끝나도 20%가 사람에게 재배정되고, 그중 절반이 모델 재시도를 거친다면 실제 비용은 단순 토큰 계산보다 커진다. 반대로 캐싱이 잘 되는 반복 업무는 처음보다 두 번째 실행부터 급격히 싸질 수 있다.

작은 실험으로 라우팅 정책을 만든다

처음부터 복잡한 라우터를 만들 필요는 없다. 대표 작업 30~50개를 모아 작은 모델, 중간 모델, 강한 모델에 같은 입력을 넣고 성공률과 비용을 비교한다. 그 다음 실패한 케이스만 분류한다. 정보 부족 때문인지, 추론 부족 때문인지, 도구 오류 때문인지, 프롬프트 불명확 때문인지 나눠야 한다.

추론 부족이 아닌데 강한 모델로 올리면 비용만 늘어난다. 문서가 부족한 문제는 RAG를 고치고, 도구 오류는 스키마와 재시도 정책을 고쳐야 한다. 라우팅은 모델 선택 문제가 아니라 실패 원인 분류 문제에 더 가깝다.

바로 적용할 체크리스트

다음 순서로 점검하면 된다.

1. LLM 기능을 반복 작업, 판단 작업, 장시간 작업으로 분류한다.
2. 각 작업에 기본 모델과 예외 모델을 지정한다.
3. 프롬프트에서 고정 컨텍스트와 변동 컨텍스트를 분리한다.
4. 캐시 적중률을 비용 대시보드에 추가한다.
5. 긴 작업용 컴팩션 스키마를 만든다.
6. 독립 도구 호출만 비동기로 돌린다.
7. 성공 작업당 비용으로 모델 선택을 다시 평가한다.

GPT-6 운영의 핵심은 모델 이름이 아니라 운영 루프다. 어떤 작업에 어느 정도의 추론을 쓰고, 어떤 컨텍스트를 재사용하고, 어디서 줄이고, 어디서 사람을 부를지 정해야 비용과 품질이 같이 잡힌다.