LLM WikiAccess-protected knowledge portal

WIKI

OpenAI Presence: 정책·가드레일·Codex 개선 루프로 기업 AI 에이전트를 생산에 올리는 방법

왜 지금 이 이야기인가 2026년 상반기 동안 기업들이 AI 에이전트 파일럿을 마치고 프로덕션으로 옮기는 과정에서 공통된 벽에 부딪혔다. 모델은 좋아졌다. 비용도 내려갔다. 그런데 실제 서비스에 붙이면 예상치 못한 일이 일어났다. 에이전트가 허용되지 않은 데이터베이스를 조회했다. 고객에게 확인되지 않은 정보를 사실처럼 말했다. 정책이 바뀌었는데 에이전트는 몰랐다. 사람이 개입해야 하는 상황인데 혼자 결정했다. 이 문제는 모델

경로human/study/content/ai-frontier/47-openai-presence-enterprise-agent-policy-guardrails-codex.md
카테고리Study
태그#agent #ai-review #codex #enterprise #guardrails #infra #policy #study

왜 지금 이 이야기인가

2026년 상반기 동안 기업들이 AI 에이전트 파일럿을 마치고 프로덕션으로 옮기는 과정에서 공통된 벽에 부딪혔다. 모델은 좋아졌다. 비용도 내려갔다. 그런데 실제 서비스에 붙이면 예상치 못한 일이 일어났다. 에이전트가 허용되지 않은 데이터베이스를 조회했다. 고객에게 확인되지 않은 정보를 사실처럼 말했다. 정책이 바뀌었는데 에이전트는 몰랐다. 사람이 개입해야 하는 상황인데 혼자 결정했다.

이 문제는 모델 품질이 아니었다. 프로덕션 배포 레이어가 없었던 것이다.

2026년 5월 OpenAI는 기업 배포 전문 조직인 OpenAI Deployment Company를 출범시켰다. 40억 달러 이상의 초기 투자를 받았고, 150명 규모의 Forward Deployed Engineer를 보유한 Tomoro를 인수했다. 그리고 7월 22일, 이 조직이 만든 첫 번째 제품인 OpenAI Presence가 공개됐다.

OpenAI Presence가 무엇을 해결하는가

Presence는 모델에 대한 접근을 파는 것이 아니다. 기업이 음성과 채팅 채널에서 AI 에이전트를 안정적으로 운영할 수 있도록, 배포에 필요한 레이어 전체를 통합 플랫폼으로 제공한다.

구체적으로 다음 여섯 가지를 묶어서 제공한다.

레이어내용
정책·표준 절차에이전트가 무엇을 할 수 있고, 어떤 상황에서 에스컬레이션해야 하는지
지식 격리에이전트는 해당 역할에 필요한 데이터와 도구만 받는다
가드레일에이전트가 승인된 범위를 벗어나면 자동 개입
승인된 행동에이전트가 수행할 수 있는 시스템 작업 목록
시뮬레이션·평가배포 전 테스트 환경: 일반 케이스, 엣지 케이스, 고위험 시나리오
Codex 개선 루프프로덕션 세션과 에스컬레이션을 분석해 개선안을 제안, 팀 승인 후 적용

단독 API 접근과 달리, Presence는 이 구성 요소들을 처음부터 통합 설계한다. 기업이 파이프라인을 직접 조합할 필요가 없다.

OpenAI Presence: 배포 레이어가 에이전트와 기업 사이를 중개한다 음성 채널 gpt-realtime 2.1 채팅 채널 GPT-5.6 기반 OpenAI Presence 배포 플랫폼 정책·표준 절차 무엇을 할 수 있나 언제 에스컬레이션하나 지식 격리 역할에 필요한 DB만 불필요한 도구 접근 차단 가드레일 범위 이탈 시 자동 개입 에스컬레이션 트리거 에이전트 런타임 모델 추론 + 정책 적용 + 도구 실행 + 가드레일 검사 시뮬레이션·평가 (배포 전) 일반 케이스·엣지 케이스·고위험 시나리오 정책 준수·도구 사용·에스컬레이션 검증 Codex 개선 루프 (배포 후) 프로덕션 세션·에스컬레이션 분석 개선안 제안 → 팀 검토·승인 → 반영 기업 내부 시스템 역할 한정 DB / API 내부 지식베이스 승인된 행동 레지스트리 Forward Deployed Engineers (OpenAI Deployment Company) 진단 → 통합 → 정책 설계 → 운영 → 개선 루프 관리 | 셀프서비스 없음, FDE 주도 실측: OpenAI 자체 영어 전화 지원 → 75% 자동 해결, Codex 개선 루프 10일간 에스컬레이션 15%p 감소 | BBVA Mexico · SoftBank Corp · Retail Insurance Australia(IAG)
OpenAI Presence 아키텍처: 정책·격리·가드레일·Codex 개선 루프

1. 배포 갭이 왜 생겼나

API 접근만 있으면 에이전트를 만들 수 있다. 그런데 실제 기업 서비스에는 API 접근으로는 채울 수 없는 영역이 있다.

첫째, 정책 관리다. 서비스 약관, 환불 규정, 에스컬레이션 기준은 제품이 바뀔 때마다 업데이트돼야 한다. 이 정책을 시스템 프롬프트에 넣는 방식은 관리 비용이 크고 에이전트가 정책을 무시하는 edge case를 막기 어렵다.

둘째, 지식 격리다. 고객 서비스 에이전트가 내부 인사 데이터나 다른 고객 데이터에 접근해서는 안 된다. RAG 파이프라인을 구성할 때 어떤 지식이 에이전트에게 허용되는지를 역할별로 정의하는 작업이 필요하다.

셋째, 운영 중 드리프트다. 모델 행동은 시스템 프롬프트가 바뀌지 않아도 달라질 수 있다. 고객 문의 패턴이 바뀌고, 신제품이 출시되고, 새로운 엣지 케이스가 나타난다. 이것을 조기에 감지하고 수정하는 루프가 없으면 에이전트는 시간이 지날수록 성능이 떨어진다.

2. OpenAI Deployment Company와 FDE 모델

Presence가 셀프서비스로 제공되지 않는 이유는 이 문제들이 소프트웨어 구독으로 해결되지 않기 때문이다.

OpenAI는 2026년 5월 OpenAI Deployment Company를 출범시켰다. 약 40억 달러 이상의 초기 투자를 유치했고(TPG 주도, BBVA·Goldman Sachs·SoftBank 등 참여), 적용형 AI 컨설팅 기업 Tomoro를 인수해 약 150명의 Forward Deployed Engineer(FDE) 조직을 확보했다.

FDE 모델은 Palantir가 정착시킨 방식이다. 엔지니어가 고객 내부에 들어가서 진단부터 통합, 운영까지 함께 진행한다. 모델을 내부 데이터, 도구, 통제 체계, 비즈니스 프로세스에 연결하는 작업은 외부에서 API 설명서만으로는 할 수 없다.

Presence는 이 FDE 조직이 배포하는 플랫폼이다. 기업은 OpenAI 계정팀을 통해 참여한다.

3. 핵심 구성 요소 심화

정책과 표준 절차 (SOP)

에이전트가 응답할 수 있는 범위, 에스컬레이션 조건, 사용할 수 없는 표현을 정의한 레이어다. 기업의 실제 운영 매뉴얼을 기계가 실행할 수 있는 형식으로 변환한다. 정책이 바뀌면 시스템 프롬프트 전체를 재작성하지 않고 정책 레이어만 업데이트한다.

지식 격리

에이전트는 해당 역할에 필요한 지식과 도구만 받는다. 소매 보험 에이전트는 고객이 가입한 보험 상품 데이터베이스를 조회할 수 있지만, 다른 고객의 청구 이력이나 내부 운영 문서에는 접근할 수 없다. 이 격리는 RAG 파이프라인 수준이 아니라 배포 구성 레벨에서 강제된다.

가드레일

에이전트가 승인된 범위를 벗어났을 때 자동으로 개입하는 시스템이다. 예를 들어 고객이 환불 정책에 없는 예외를 요구할 경우, 에이전트가 스스로 결정하지 않고 담당자에게 전달하도록 구성한다. 가드레일은 단순한 키워드 필터가 아니라 대화 맥락과 정책을 결합해 판단한다.

시뮬레이션과 사전 평가

배포 전에 에이전트를 실제 운영 조건과 유사한 시나리오로 테스트한다. 평가 기준은 네 가지다. 정확한 결과를 도출했는가, 정책을 준수했는가, 도구를 적절히 사용했는가, 에스컬레이션이 필요한 상황에서 에스컬레이션했는가. 고위험 시나리오(허위 정보 유도, 정책 우회 시도 등)를 사전에 실행하고 통과한 에이전트만 프로덕션으로 간다.

Codex 개선 루프

배포 후 운영이 시작되면 실제 대화와 에스컬레이션 로그가 누적된다. OpenAI의 코딩 에이전트인 Codex가 이 데이터를 분석하고 개선안을 제안한다. 예를 들어 특정 유형의 질문에서 반복적으로 에스컬레이션이 발생하면 SOP를 수정하거나, 해당 케이스를 처리하는 추가 응답 패턴을 제안한다. 팀이 제안을 검토하고 승인하면 에이전트에 반영된다. 인간 승인이 모든 변경에 필요하다는 점에서 완전 자동화와는 다르다.

OpenAI 자체 영어 전화 지원에서 이 루프를 적용한 결과, 10일 만에 에스컬레이션이 15%포인트 감소했다.

4. gpt-realtime 2.1과 음성 채널

Presence의 음성 채널은 2026년 7월 6일 출시된 gpt-realtime 2.1을 기반으로 한다.

gpt-realtime 2.1의 주요 특징은 두 가지다. 첫째, 실시간 음성 대화에 추론(reasoning) 능력과 도구 호출(tool use)이 추가됐다. 이전 버전은 단순 음성 응답에 가까웠지만, 2.1은 복잡한 질문에 단계적으로 생각하고 내부 시스템을 호출해 답할 수 있다. 둘째, p95 레이턴시가 최소 25% 감소했다. WebRTC 트랜스포트 기반의 Realtime API 2.0과 결합해 음성-to-음성 레이턴시가 300ms 미만에 도달했다.

Presence 음성 채널은 이 모델 위에서 정책·가드레일·Codex 루프를 동일하게 적용한다. SoftBank Corp.가 일본어 음성 에이전트에서 Presence를 사용하는 이유가 이 구조 덕분이다.

5. 초기 배포 사례

BBVA Mexico: OpenAI Deployment Company의 창립 파트너이자 첫 배포 고객. 빠르고 개인화된 고객 응대에 Presence를 활용한다. BBVA는 OpenAI Deployment Company에 전략적 투자도 병행했다.

SoftBank Corp.: 일본어 음성 에이전트를 Presence로 배포. 자연스럽고 정확한 대화를 제공하는 것이 목표다. SoftBank의 OpenAI에 대한 대규모 투자(40조 엔 브리지 론 포함)와 연계된 파트너십이다.

Retail Insurance Australia (IAG): 고객 지원에 Presence를 적용. Open question: 구체적인 성과 지표는 아직 공개되지 않았다.

6. DIY 배포와의 비교

Presence가 아닌 방식으로 유사한 시스템을 구축할 수도 있다. 그러나 구성 요소들을 직접 만들면 해결해야 하는 문제들이 있다.

항목DIYPresence
정책 관리시스템 프롬프트 수동 관리정책 레이어 별도 운영
지식 격리RAG 파이프라인에서 직접 필터링배포 구성 레벨 격리
가드레일외부 라이브러리 조합 또는 직접 구현플랫폼 내장
사전 평가CI/CD에 평가 파이프라인 직접 구성통합된 시뮬레이션 환경
개선 루프수동 로그 분석 또는 별도 평가 시스템 구축Codex 제안 + 인간 승인 내장
운영내부 ML Ops 팀 필요FDE 주도 운영

DIY 방식이 틀린 것은 아니다. 충분한 ML Ops 역량과 긴 구축 기간을 감수한다면 더 많은 통제권을 가질 수 있다. Presence의 장점은 검증된 레이어들을 초기부터 통합 운영한다는 점이다. 단점은 셀프서비스가 아니라는 것, 그리고 OpenAI 생태계에 깊이 의존하게 된다는 것이다.

7. 운영자가 확인해야 할 것

Presence 배포를 검토하는 팀이 미리 생각해야 할 체크리스트다.

마무리

OpenAI Presence는 AI 에이전트 시장에서 새로운 역할을 정의한다. 모델을 API로 파는 것이 아니라, 배포에 필요한 모든 레이어를 FDE와 함께 운영 가능한 상태로 만들어주는 것이다.

이 방향이 맞다면, AI 에이전트 운영의 경쟁은 모델 품질이 아니라 정책 관리·가드레일·운영 루프의 수준으로 이동한다. Presence는 그 경쟁에서 OpenAI가 어디에 서고 싶은지를 보여주는 첫 번째 제품이다.

References