OpenAI Decisions API로 에이전트 실행 경계 세우기 | Agent Execution Boundaries with Decisions API

핵심 답변: 10월 22일 OpenAI가 Decisions API를 일반 공개하면서, 에이전트가 매 단계에 큰 모델 응답을 만들지 않고도 “계속할지”, “사람에게 넘길지”, “어느 도구를 부를지” 같은 제한된 선택을 빠르게 처리할 길이 생겼습니다. 다만 이것은 에이전트에게 더 많은 일을 맡기라는 신호가 아니라, 실행 전에 판단을 좁히고 검증 가능하게 만들라는 변화에 가깝습니다. 운영 중인 AI 기능이 있다면 새 API를 붙이는 일보다 먼저, 지금의 분기와 권한을 목록으로 꺼내 보는 편이 낫습니다.

저는 에이전트를 붙인 뒤 가장 자주 만나는 문제를 “모델이 틀린 답을 했다”로만 보지 않습니다. 실제 장애는 대개 분류가 애매한 상태에서 쓰기 권한이 있는 도구를 고르거나, 재시도해야 할 오류를 성공처럼 넘기거나, 비용이 큰 모델 호출이 사소한 라우팅까지 먹는 데서 시작합니다. 이번 변화는 그 경계를 코드로 분리할 수 있게 해 줍니다. PR 설명 요약, 이슈 라우팅, 배포 승인 대기, 고객 문의의 담당 팀 선택처럼 답의 후보가 처음부터 정해진 작업이 우선 대상입니다.

결론부터 말하면, Decisions API는 문장을 만들어 내는 주 에이전트를 대체하지 않습니다. 대신 그 앞뒤에 있는 작은 판단을 별도의 계약으로 만들기 좋습니다. 선택지와 점수 기준을 서버 코드에 고정하고, 낮은 신뢰도는 사람 리뷰 큐로 보내며, 결과와 실제 후속 조치를 함께 저장해야 운영에서 의미가 생깁니다.

무슨 일이 있었나

OpenAI는 2026년 10월 22일 Decisions API의 일반 공개를 발표했습니다. 공식 발표에 따르면 GPT-6 Luna 기반의 전용 엔드포인트로, 텍스트·이미지·네이티브 JSON을 입력받아 predicate(참일 확률), choice(정해 둔 값 중 선택), score(루브릭 점수) 세 형태를 돌려줍니다. 한 요청에 최대 400개 질문을 넣을 수 있고, 공개 베타 뒤 프롬프트 캐시·미국/EU 처리 지역·GPT-Live 연동이 추가됐습니다. 비용과 처리 속도 수치는 워크로드에 따라 달라지므로, 발표의 “최대 10배”를 우리 서비스의 약속으로 옮기면 안 됩니다. OpenAI 공식 발표에서 지원 형태와 현재 가격을 확인할 수 있습니다.

같은 시점의 공식 문서는 에이전트를 Agents API, Agents SDK, Responses API 중 어디에서 돌릴지 구분합니다. 관리형 실행과 세션 저장이 필요하면 Agents API, 배포·승인·저장소를 애플리케이션이 통제해야 하면 SDK, 루프를 직접 설계하면 Responses API라는 선택입니다. Decisions는 이 셋을 대체하는 별도 오케스트레이터가 아니라, 그 안에서 작고 반복되는 결정을 맡길 수 있는 도구입니다. 에이전트 런타임 공식 가이드를 기준으로 현재 구조를 먼저 분류해 두는 이유입니다.

도구 호출의 범위도 더 중요해졌습니다. OpenAI의 도구 문서는 함수 호출, 웹 검색, 파일 검색, MCP, 도구 검색을 한 요청의 tools 설정으로 다루되, 실제 함수 실행은 애플리케이션이 책임진다고 설명합니다. 즉 “배포 실행”이라는 선택을 모델이 골랐다는 사실은 배포를 허가했다는 뜻이 아닙니다. 도구 사용 공식 문서는 이 경계를 구현할 출발점입니다.

왜 중요한가

에이전트 비용과 지연은 긴 답변을 만들 때만 발생하지 않습니다. 예를 들어 GitHub PR이 열릴 때마다 전체 코드 맥락을 넣어 “보안 리뷰가 필요한가”를 물으면, 대부분의 평범한 PR도 비싼 경로를 탑니다. 반대로 파일 경로, 변경 라인 수, 의존성 파일 변경 여부, 작성자 팀처럼 검증된 데이터를 JSON으로 만들고 결과를 review, normal, block으로 한정하면, 다음 단계가 예측 가능해집니다. 이때 중요한 성능 지표는 평균 응답 시간 하나가 아니라 라우팅 오류율, 에스컬레이션 비율, 사람 검토 후 뒤집힌 비율입니다.

아키텍처 측면에서는 “판단”과 “행동” 사이에 얇지만 단단한 서버 경계를 두게 됩니다. 판단은 모델 호출 결과이고, 행동은 우리 코드가 권한·정책·승인을 확인한 뒤 수행합니다. 이 분리가 없으면 모델 교체나 프롬프트 변경이 곧바로 운영 정책 변경이 됩니다. 비용도 마찬가지입니다. 캐시가 되는 공통 기준과 요청별 민감 데이터를 분리해야 캐시 효율과 개인정보 노출 범위를 동시에 검토할 수 있습니다.

작은 분기를 먼저 찾고, 답의 공간을 닫습니다

가장 좋은 첫 후보는 “설명문이 필요한 일”이 아니라 “정답 후보가 이미 있는 일”입니다. 예컨대 지원 티켓을 billing, bug, account로 보내거나, CI 실패를 retry, investigate, rollback으로 나누는 일입니다. choice 결과를 받은 뒤에는 무조건 실행하지 말고, 서버가 선택값을 다시 검증해야 합니다. 허용되지 않은 값은 오류로 기록하고 기본적으로 사람 큐로 보냅니다.

const decision = await chooseNextAction({
  choices: ['retry', 'investigate', 'human_review'],
  context: { job: safeJobSummary, exitCode, retries }
})
if (decision.choice === 'retry' && retries < 2) await retryReadOnlyJob()
else await createReviewTask(decision)

여기서 safeJobSummary에는 토큰, 비밀번호, 고객 원문을 넣지 않습니다. 데이터는 필요한 최소 단위로 만들고, 실행 함수는 읽기 전용과 변경 작업을 분리합니다. “배포”나 “삭제”는 선택지에 넣지 않고 별도의 승인된 워크플로로 넘기는 편이 안전합니다.

에이전트 도입은 권한표와 함께 PR로 관리합니다

새 도구를 등록할 때는 설명문보다 권한표가 먼저입니다. 함수마다 읽기·쓰기·외부 전송·금전 영향 여부와 승인자를 tools-policy.yml 또는 코드 상수로 관리하고, PR에서 바뀐 권한을 리뷰합니다. 특히 MCP나 사내 도구 서버는 모델이 읽는 도구 설명도 입력 데이터가 될 수 있으므로, 검증된 서버만 연결하고 버전을 고정해야 합니다. OpenAI 문서도 도구 선택과 호출 처리를 런타임별로 구분합니다. “모델이 이 도구를 쓸 수 있다”와 “이 사용자가 이 작업을 승인했다”는 서로 다른 검사여야 합니다.

운영에서는 요청 ID 하나로 입력 요약, 선택값, 신뢰도, 실제 실행 함수, 승인자, 결과를 연결합니다. 원문 프롬프트를 통째로 로그에 쌓는 방식은 개인정보와 비밀을 늘리는 지름길입니다. 재현에 필요한 해시·정책 버전·도구 버전·요약된 오류 코드만 남기고, 민감한 원문은 기존의 접근 통제된 저장소에 둡니다.

모델과 도구 평가는 ‘좋아 보이는 데모’가 아니라 반례로 합니다

이번 API의 choice와 score에는 확률·신뢰도가 따라올 수 있지만, 그 숫자는 정답 보증서가 아닙니다. 실제 최근 2주 티켓, 실패한 CI 로그, 사람이 뒤집었던 과거 라우팅을 익명화한 고정 데이터셋으로 평가해야 합니다. 각 샘플에는 기대 선택, 절대 실행하면 안 되는 행동, 사람 검토가 필요한 조건을 함께 적습니다. OpenAI의 평가 문서도 모델이나 프롬프트를 바꾸기 전에 테스트 입력과 기준을 만들고 결과를 분석하는 순서를 권합니다. 평가 공식 가이드에서 평가 데이터와 채점 기준의 구조를 확인할 수 있습니다.

PR에는 단순 정확도뿐 아니라 거짓 자동화율을 넣으세요. 예를 들어 실제로는 사람이 봐야 할 티켓을 자동 처리한 비율이 핵심입니다. 낮은 신뢰도에서 사람 큐로 보내는 비율이 높아도, 초기에 그것은 실패가 아니라 안전장치가 작동한 신호일 수 있습니다. 기준선을 정하고, 모델·프롬프트·도구 스키마 중 하나만 바꿔 비교해야 원인을 알 수 있습니다.

프롬프트 인젝션과 승인 우회는 별도의 실패 경로로 둡니다

웹 검색 결과, 첨부 문서, 이슈 본문에는 “이전 지시를 무시하라”는 식의 적대적 텍스트가 들어올 수 있습니다. 이를 모델의 친절함으로 해결하려 하지 말고, 외부 텍스트를 명령이 아닌 데이터로 표시하며 쓰기 작업에는 정책 검사를 둡니다. OpenAI의 안전 권고는 적대적 입력 테스트, 사람 검토, 입력·출력 범위 제한, 검증된 값 사용을 권합니다. 안전 모범 사례가 말하는 사람 검토는 특히 코드 생성과 고위험 동작에서 중요합니다.

실전에서는 “도구를 호출해도 되는가”뿐 아니라 “이 결과가 왜 이 도구로 이어졌는가”를 검토 화면에 보여 주세요. 배포 전에는 변경 파일, 환경, diff, 테스트 결과를 사람이 보고 승인하고, 에이전트의 score는 참고값으로만 둡니다. 승인이 없거나 정책 버전이 맞지 않으면 실행을 막고, 그 차단 자체를 관찰 지표로 남깁니다.

개발자 실행 계획

저장소에서 에이전트가 하는 분기 10개를 찾아, 후보 값이 닫힌 작업과 자유 서술 작업으로 나눕니다.
server/ai/decision-policy.ts에 선택값·최대 재시도·사람 검토 조건을 코드로 선언합니다.
쓰기 권한 도구를 읽기 전용 도구와 분리하고, 실행 전 정책·사용자·환경 승인 검사를 강제합니다.
최근 실제 사례로 50~100개의 평가 샘플을 만들고, 기대 선택과 금지 행동을 함께 기록합니다.
CI에서 선택 정확도, 거짓 자동화율, p95 지연, 호출당 비용, 리뷰 뒤집힘 비율을 이전 기준선과 비교합니다.
요청 ID로 판단·도구·승인·실행 결과를 잇되 민감 원문과 비밀값은 로그에서 제외합니다.
스테이징에서 선택 결과를 실제 실행 대신 리뷰 작업으로만 연결한 뒤, 좁은 팀과 읽기 전용 작업부터 켭니다.

리스크와 한계

Decisions API의 일반 공개는 모든 에이전트의 비용이나 지연이 자동으로 줄었다는 뜻이 아닙니다. 입력 정규화, 네트워크 왕복, 사람 승인 대기는 여전히 전체 시간을 좌우합니다. 공식 발표의 고객 사례와 수치는 각자의 데이터·평가 조건에 따른 것이므로, 내 저장소와 트래픽에서 재현 테스트가 필요합니다. API 요금, 지역 처리, 보존 옵션은 바뀔 수 있으니 배포 직전 공식 가격과 데이터 제어 문서를 다시 확인하세요.

롤백 조건도 미리 정합니다. 거짓 자동화율이 기준선을 넘거나, 정책 차단이 급증하거나, 승인 없는 쓰기 시도가 한 건이라도 나오면 Decisions 경로를 끄고 기존 사람 큐로 되돌립니다. 모델 출력 형식이 정상이어도 다운스트림 함수의 스키마가 달라질 수 있으므로, 선택지 변경은 하위 호환 기간과 통합 테스트를 거쳐야 합니다.

FAQ

Decisions API는 기존 에이전트나 Responses API를 바꿔야 하나요?

아닙니다. 공식 문서상 Decisions는 제한된 판단에 쓰는 전용 API이고, 에이전트의 세션·도구·실행 환경을 대신 관리하지 않습니다. 먼저 기존 런타임을 유지한 채 라우팅 한 곳에만 붙여 평가하세요.

AI 에이전트가 낮은 신뢰도를 내면 자동으로 재시도해도 되나요?

읽기 전용이고 재시도 비용이 작으며 횟수 제한이 있는 작업만 자동 재시도를 고려할 수 있습니다. 고객 데이터 변경, 배포, 결제, 권한 변경은 낮은 신뢰도일 때 사람 검토로 보내는 것이 기본값이어야 합니다.

AI 에이전트 권한 보안은 프롬프트만 잘 쓰면 되나요?

아닙니다. 프롬프트는 보조 장치입니다. 서버 쪽 허용 목록, 최소 권한 토큰, 승인 단계, 입력 검증, 감사 로그가 실제 보안 경계입니다. 적대적 문서와 권한 우회 사례를 평가 데이터에 넣어야 합니다.

출처 및 추가 읽기

더 깊게 읽기: 실전 가이드

이 리포트는 최근 흐름을 빠르게 파악하기 위한 요약입니다. 실제 프로젝트에 적용할 때는 아래의 기준 글과 함께 확인하면 더 안전합니다.