1. 이 가이드로 다시 정할 수 있는 운영 기준
OpenAI는 2026년 10월 2일 「GPT-6 제품군 모델 가이드」를 한국어판과 영문판으로 공개했습니다. 새 기능 발표는 아닙니다. GPT-6 제품군 모델을 업무에 배치하고 운영하는 방법을 정리한 공식 사용 지침이죠.
에이전트를 시범 운영하고 있는 팀이라면 이 가이드를 근거로 무엇을 잴지, 어떤 행동을 승인받게 할지, 어떤 업무에 어떤 모델과 추론 수준을 쓸지를 다시 정해볼 수 있습니다. 이 글은 운영 기준만 다룹니다. 모델별 단가와 비용 계산은 가이드 원문의 가격표에서 직접 확인해보세요. 모델 성능에 관한 표현은 모두 OpenAI의 자체 설명입니다.
2. 대표 작업으로 성공률과 지연 시간을 잽니다
가이드는 "대표적인 작업을 실행하고 작업 성공률, 지연 시간, 성공한 작업당 비용을 측정하세요"라고 씁니다. 다른 문장에서는 "작업 성공률과 지연 시간을 측정하고, 모니터링 및 데이터 제어 계획을 세우세요"라고 덧붙이죠. 무엇을 잴지는 정해 주지만, 성공률이나 지연 시간의 목표값은 가이드에 없습니다. 목표는 각 팀이 정해야 합니다.
그래서 측정 전에 무엇을 성공으로 볼지부터 적어 두세요. 예시로, 청구서에서 거래처·금액·지급일을 뽑는 에이전트라면 필드가 모두 맞고 사람이 고치지 않고 넘긴 건만 성공으로 셀 수 있습니다. 사람이 고친 건까지 성공으로 세면 성공률은 높게 나오지만 사람이 나중에 고치는 시간이 기록에서 사라집니다. 대표 작업도 쉬운 요청만 고르지 말고, 실제 요청 기록에서 까다로웠던 건을 함께 넣어야 운영 상태에 가까운 숫자가 나옵니다(작성자 해석).
3. 혼자 진행할 행동과 승인받을 행동을 나눠 적습니다
가이드는 "독자적으로 진행할 수 있는 행동과 승인이 필요한 행동을 명시하세요"라고 씁니다. 같은 항목에서 일괄적인 "항상 물어보기" 규칙을 명확한 기준으로 대체하라고도 적습니다. 다만 어떤 행동을 승인 대상으로 둘지까지는 가이드가 정해 주지 않습니다.
저는 행동마다 결과를 되돌릴 수 있는지, 그 결과가 회사 밖 사람이나 시스템에 닿는지를 따져 보기를 권합니다. 내부 초안 작성이나 자료 요약처럼 되돌릴 수 있고 회사 안에만 영향이 있는 행동은 혼자 진행하게 둡니다. 내부 기록 삭제나 취소할 수 있는 외부 공유 링크 생성처럼 둘 중 하나에 걸리는 행동은 승인 뒤에 실행하게 합니다. 고객 메일 발송이나 결제처럼 되돌릴 수 없고 회사 밖으로 나가는 행동은 승인 뒤에 실행하게 하고, 도구 쪽에서도 막아 둡니다.
목록을 에이전트 지시문에 적는 데서 멈추지 마세요. 지시문은 모델이 따르도록 쓴 문장이어서 실행 자체를 막지는 못합니다. 그래서 마지막 칸에 든 행동은 도구 쪽에서도 승인 없이는 실행되지 않게 막아 두는 편이 안전합니다(작성자 해석).
4. 작업 중 지시를 바꿀 때와 도구 결과를 기다릴 때
에이전트가 오래 걸리는 작업을 하는 중에 방향을 바꾸고 싶을 때가 있죠. 가이드는 Responses WebSocket API로 작업 도중 수정 지침을 보낼 때의 동작을 "업데이트는 대기열에 추가되며, 실행 중인 도구를 취소하거나 완료된 작업을 되돌리지 않습니다"라고 설명합니다. 다시 말해 중간에 보낸 수정 지시는 이미 시작한 도구 호출을 멈추지 못합니다.
그러니 방향을 바꾼 뒤에는 이미 끝난 작업 가운데 사람이 직접 취소하거나 정리할 것이 있는지 확인하는 절차를 두세요. 예시로, 에이전트가 거래처 10곳에 보낼 메일 초안을 만들다가 대상이 바뀌었다면 이미 만든 초안은 저장된 채로 있으니 따로 지워야 합니다.
비동기 도구(호출해 놓고 결과를 나중에 받는 도구)에 대해서는 "그 결과에 의존하는 작업은 결과가 나올 때까지 기다린 후 시작하세요"라고 적혀 있습니다. 결과가 오기 전에 다음 단계를 시작하면 빈 값이나 이전 값으로 작업이 이어질 수 있기 때문입니다(작성자 해석).
하위 에이전트에게 일을 나눠 맡기는 기능도 아직 시험 단계입니다. 가이드는 "멀티 에이전트는 현재 베타 버전으로 제공됩니다"라고 밝히고, OpenAI API 변경 기록의 2026년 9월 29일 항목도 GPT-6.1 Sol이 Responses API 요청 안에서 하위 에이전트에게 작업을 위임하는 멀티 에이전트 기능을 베타로 지원한다고 적고 있습니다. 운영 업무에 바로 넣기 전에, 위의 대기 규칙이 하위 에이전트 결과에도 지켜지는지 시험 환경에서 먼저 확인해보세요.
5. 업무 위험도에 맞춰 모델과 추론 수준을 배치합니다
가이드는 "모델과 추론 수준을 선택할 때는 지능과 가격 사이의 균형을 고려하세요"라고 씁니다. 업무별 배치도 제시하는데, Astra는 가장 어려운 추론에, Sol은 복잡한 코딩과 리서치에, Luna는 청구서 필드 추출·요청 분류·구조화된 요약처럼 범위가 분명하고 양이 많은 반복 작업에 둡니다. 추론 수준은 낮음, 중간, High, Extra High·Max 단계로 설명합니다.
이 배치를 라우팅 정책으로 옮길 때는 작업 난도와 함께 3번에서 나눈 승인 구분을 같이 보세요. 제 판단으로는 회사 밖으로 나가는 행동을 다루는 단계일수록 모델을 올리는 것보다 승인 단계와 모니터링을 갖추는 것이 먼저입니다. 모델을 바꿔도 이미 나간 메일 한 통을 되돌릴 수는 없기 때문입니다. 아래 표는 가이드 문장을 운영 정책 항목으로 옮겨 본 것입니다.
| 정책 항목 | 가이드 원문이 말하는 것 | 팀이 채울 것 |
|---|---|---|
| 측정 지표 | 작업 성공률, 지연 시간, 성공한 작업당 비용 측정 | 성공의 정의와 목표값 |
| 행동 권한 | 독자 진행 행동과 승인 필요 행동 명시 | 행동별 구분과 승인자 |
| 모델과 추론 수준 | 지능과 가격의 균형, 업무별 배치 예 | 업무별 기본 모델과 올리는 조건 |
| 모니터링과 데이터 | 모니터링 및 데이터 제어 계획 수립 | 기록 항목과 보관 기간 |
| 장시간 작업 | 업데이트는 대기열에 추가, 의존 작업은 결과 대기 | 방향 수정 뒤 정리 절차 |
| 멀티 에이전트 | 현재 베타 | 시험 환경에서 확인할 범위 |
6. 이번 주에 해볼 일
운영 중이거나 준비 중인 에이전트 하나를 골라 지난 요청 가운데 20건을 대표 작업으로 뽑아보세요. 건마다 성공 여부와 걸린 시간을 적고, 사람이 고친 건은 따로 표시합니다.
같은 표 옆에 그 에이전트가 쓰는 도구를 모두 적고, 도구마다 '혼자 진행' 또는 '승인 필요'를 붙여보세요. 승인 필요로 표시한 도구가 지금 승인 없이도 실행되는 구조라면, 그 도구부터 고치면 됩니다.