GPT-6.1 Sol 비용 최적화 가이드: cached input을 쓰는 에이전트 프롬프트 구조부터 바꿔라

GPT-6.1 Sol의 가격표에서 가장 실무적인 숫자는 cached input 100만 토큰당 0.10달러다. 입력 100만 토큰당 2달러, 출력 100만 토큰당 10달러도 중요하지만, 에이전트 제품에서는 반복되는 컨텍스트 비용이 전체 비용을 크게 만든다. 같은 시스템 지침, 도구 설명, 리포지토리 요약, 정책 문서를 매 요청마다 넣는 구조라면 cached input 적용률이 비용을 좌우한다.

많은 팀이 모델 비용 최적화를 “짧게 물어보기”로 이해한다. 하지만 코딩 에이전트나 업무 자동화 에이전트에서는 무작정 프롬프트를 줄이면 성능이 떨어진다. 더 나은 접근은 재사용 가능한 컨텍스트와 매번 바뀌는 컨텍스트를 분리하는 것이다. GPT-6.1 Sol 같은 가격 구조에서는 이 설계가 곧 제품 마진이다.

이 글은 OpenAI의 GPT-6.1 Sol 발표를 기준으로, 개발팀이 에이전트 워크플로우에서 cached input을 활용하기 위해 프롬프트와 라우팅을 어떻게 정리해야 하는지 다룬다. 특정 SDK 코드보다 구조와 체크리스트에 집중한다.

cached input이 중요한 이유

에이전트 요청은 일반 챗봇 요청보다 반복 정보가 많다. 예를 들어 코딩 에이전트는 시스템 정책, 코드 스타일, 도구 사용 규칙, 테스트 명령, 보안 금지사항, 리포지토리 구조, 최근 변경 내역을 계속 참조한다. 업무 자동화 에이전트는 회사 정책, 도구 목록, 승인 규칙, 고객 응대 톤, 예외 처리 기준을 반복해서 읽는다.

이 정보가 매번 일반 input으로 과금되면 비용이 빠르게 늘어난다. 반대로 모델 제공자가 같은 prefix나 컨텍스트를 cache로 처리할 수 있다면 같은 품질을 유지하면서 비용을 낮출 수 있다. GPT-6.1 Sol의 cached input 가격이 표준 input 대비 95% 낮다는 점은 이 구조를 적극 활용하라는 신호다.

중요한 것은 cache가 마법처럼 적용되지 않는다는 점이다. 요청마다 앞부분이 조금씩 바뀌거나, 사용자별 동적 정보를 시스템 프롬프트 앞에 끼워 넣거나, 도구 설명 순서를 매번 바꾸면 재사용성이 낮아진다. 캐시 친화적인 프롬프트 구조가 필요하다.

프롬프트를 세 층으로 나눈다

실무에서는 프롬프트를 세 층으로 나누는 편이 좋다. 첫 번째는 고정 계층이다. 제품 정책, 안전 규칙, 도구 사용 원칙, 출력 형식처럼 거의 바뀌지 않는 정보다. 두 번째는 세션 계층이다. 현재 프로젝트, 리포지토리 요약, 사용자 역할, 작업 목표처럼 일정 시간 동안 유지되는 정보다. 세 번째는 요청 계층이다. 이번 턴의 질문, 새 오류 로그, 수정 대상 파일, 최신 테스트 결과처럼 매번 바뀌는 정보다.

비용을 줄이려면 고정 계층과 세션 계층은 캐시가 잘 먹도록 안정적으로 유지해야 한다. 요청 계층만 뒤쪽에 붙인다. 도구 설명도 매번 임의 순서로 만들지 말고 고정된 순서와 이름을 유지한다. 사용하지 않는 도구를 모두 넣는 것도 피해야 한다. 도구가 많으면 입력 비용뿐 아니라 도구 선택 오류도 늘어난다.

예를 들어 코딩 에이전트라면 다음 순서가 낫다.

1. 고정 시스템 정책과 안전 규칙
2. 고정 도구 설명
3. 프로젝트별 코딩 컨벤션
4. 리포지토리 파일 맵과 요약
5. 현재 이슈 목표
6. 이번 턴의 로그와 요청

이 순서를 유지해야 캐시 재사용 가능성이 올라간다.

비용 측정 단위는 요청이 아니라 작업이어야 한다

모델 가격표만 보면 한 요청당 비용을 계산하기 쉽다. 하지만 에이전트 제품에서는 작업당 비용이 더 중요하다. 예를 들어 “테스트 실패 하나를 고친다”는 작업은 파일 검색, 원인 분석, 코드 수정, 테스트 실행, 재수정, 요약까지 여러 요청으로 구성된다. 요청당 비용이 낮아도 재시도가 많으면 전체 비용은 올라간다.

따라서 비용 로그에는 다음 항목이 필요하다.

• 작업 ID
• 모델명과 reasoning 설정
• 일반 input 토큰
• cached input 토큰
• output 토큰
• tool call 수
• 실패 후 재시도 횟수
• 최종 성공 여부
• 사람 리뷰에서 반려된 여부

이 지표가 있어야 GPT-6.1 Sol이 실제로 저렴한지 판단할 수 있다. 단순히 토큰 단가가 낮아도 품질이 낮아 재시도가 늘면 손해다. 반대로 비싼 모델이 한 번에 끝내면 더 싸게 끝날 수 있다.

도구 설명과 정책 문서는 짧지만 안정적으로

도구 설명은 캐시 대상이 되기 쉽지만, 너무 길면 비용과 선택 오류를 만든다. 각 도구 description은 “무엇을 하는가”보다 “언제 써야 하는가”와 “언제 쓰면 안 되는가”를 담아야 한다. 그러나 모든 예외를 장황하게 넣으면 모델이 읽기 어렵다.

좋은 도구 설명은 보통 다음 구조를 가진다.

• 사용 의도: 어떤 사용자 요청에서 쓰는가
• 입력 조건: 필요한 식별자와 형식
• 금지 상황: 이 도구로 처리하면 안 되는 경우
• 출력 의미: 핵심 필드가 무엇을 뜻하는가

정책 문서도 마찬가지다. “항상 안전하게 행동하라” 같은 추상문은 비용만 쓰고 효과가 낮다. “결제, 삭제, 권한 변경, 외부 발송은 preview 후 사용자 승인 없이는 실행하지 않는다”처럼 구체적이어야 한다.

컨텍스트 압축을 cache와 섞지 않는다

긴 작업에서는 컨텍스트 압축이 필요하다. 하지만 압축 요약을 고정 계층 앞에 자주 삽입하면 cache 효율이 떨어질 수 있다. 압축 요약은 세션 계층 뒤쪽이나 요청 계층 앞쪽에 배치하는 편이 낫다. 고정 정책과 도구 설명은 가능한 한 변하지 않게 둔다.

또한 요약은 비용 절감과 품질 저하 사이의 타협이다. 무조건 짧게 만들면 중요한 제약이 사라진다. 특히 코딩 에이전트에서는 최근 실패한 테스트, 수정한 파일, 사용자가 금지한 접근법, 남은 TODO가 요약에서 빠지면 재작업이 늘어난다. 재작업은 output 토큰과 tool call을 늘려 비용을 다시 올린다.

압축 요약에는 최소한 마지막 결정, 변경 파일, 실패한 시도, 검증 결과, 다음 액션을 포함해야 한다. 이 정보는 캐시보다 작업 성공률에 더 중요하다.

모델 라우팅으로 Sol의 위치를 정한다

GPT-6.1 Sol은 모든 작업의 기본값이 될 수도 있지만, 더 좋은 방식은 작업 유형별 라우팅이다. 반복적이고 컨텍스트 재사용이 많은 작업은 Sol에 적합하다. 예를 들어 코드 리뷰 초안, 테스트 실패 분석, 내부 문서 질의응답, 도구 호출형 업무 자동화, PDF 요약 후 표 추출 등이 있다.

반대로 고위험 설계 결정, 보안 취약점 판정, 법률·의료·재무의 최종 판단, 되돌리기 어려운 외부 실행은 더 강한 모델 또는 사람 검토로 승격해야 한다. 이 승격 기준을 명시하지 않으면 낮은 비용 때문에 모든 작업이 Sol로 몰릴 수 있다.

좋은 라우팅 정책은 비용만 보지 않는다. 작업 난도, 실패 비용, 검증 가능성, 재사용 컨텍스트 비율을 함께 본다. 테스트로 검증 가능한 코딩 작업은 Sol이 잘 맞을 수 있다. 근거 확인이 어려운 전략 판단은 더 신중해야 한다.

실행 체크리스트

• 프롬프트를 고정 계층, 세션 계층, 요청 계층으로 나눈다.
• 고정 계층의 순서와 문구를 요청마다 바꾸지 않는다.
• 도구 설명 순서를 안정적으로 유지하고 사용하지 않는 도구는 빼라.
• 사용자별 동적 정보를 시스템 프롬프트 앞에 넣지 않는다.
• cached input 적용률을 작업 ID별로 측정한다.
• 요청당 비용이 아니라 작업당 성공 비용을 본다.
• 재시도 횟수와 사람 반려율을 비용 로그에 포함한다.
• 컨텍스트 압축 요약은 고정 계층을 깨지 않는 위치에 둔다.
• 위험도가 높은 작업은 Sol에서 끝내지 말고 승격 정책을 둔다.
• 모델 변경 후 기존 회귀 테스트와 안전 테스트를 다시 실행한다.

GPT-6.1 Sol의 장점은 단순히 싸다는 데 있지 않다. 반복 컨텍스트를 많이 쓰는 에이전트 제품에서 비용 구조를 다시 설계할 기회를 준다는 데 있다. 캐시 친화적인 프롬프트 구조를 먼저 만들지 않으면 이 장점을 제대로 쓰기 어렵다.