OpenAI Presence 출시: 엔터프라이즈 AI 에이전트가 제품이 되는 방식

요약: OpenAI Presence는 “모델을 붙인 챗봇”이 아니라 정책, 승인, 에스컬레이션, 평가, 운영 개선 루프를 묶은 엔터프라이즈 에이전트 제품입니다. 실무 개발팀이 봐야 할 핵심은 모델 성능보다 운영 단위가 바뀌었다는 점입니다.

왜 지금 OpenAI Presence가 중요해졌나

AI 에이전트 PoC는 이제 흔합니다. 내부 문서를 검색하고, 티켓을 요약하고, 고객 질문에 답하는 데모는 하루 이틀이면 만들 수 있습니다. 문제는 프로덕션입니다. 실제 고객 계정에 접근하고, 환불 정책을 적용하고, 장애 티켓을 분류하고, 필요한 경우 사람에게 넘기는 순간부터 난이도가 달라집니다.

OpenAI가 공개한 Presence의 설명도 이 지점을 정확히 겨냥합니다. Presence는 음성·채팅 기반 에이전트가 회사 시스템을 사용하고, 승인된 액션을 수행하고, 정확도와 성과를 평가받고, 필요하면 사람에게 에스컬레이션하도록 설계된 배포형 제품입니다. 제한된 일반 공개 프로그램으로 제공되며, 셀프서브 API라기보다 Forward Deployed Engineer와 시스템 통합 파트너가 붙는 엔터프라이즈 구축 모델에 가깝습니다.

개발자 입장에서 이 뉴스의 의미는 분명합니다. 앞으로 “어떤 모델을 쓸까”보다 “에이전트가 어떤 업무 경계 안에서 어떤 행동을 할 수 있게 할까”가 더 중요한 설계 질문이 됩니다. 모델 호출 코드만 잘 짜는 팀보다 권한, 정책, 관측성, 품질 개선 루프를 같이 설계하는 팀이 더 빨리 프로덕션에 도달합니다.

Presence의 구조를 개발 관점으로 쪼개기

Presence는 하나의 거대한 모델이 아닙니다. 공개된 설명 기준으로 보면 여러 운영 요소가 붙어 있습니다.

• 업무 단위 정의: 청구 문제 해결, 보험 청구 지원, 사내 IT 요청 처리처럼 구체적인 job에서 시작합니다.
• 최소 권한 접근: 에이전트는 해당 업무에 필요한 지식과 시스템 접근만 받습니다.
• 정책과 승인 규칙: 어떤 액션은 자동 수행하고, 어떤 액션은 승인 후 수행하며, 어떤 경우에는 사람에게 넘길지 정합니다.
• 시뮬레이션과 평가: 일반 요청, 엣지 케이스, 고위험 시나리오를 사전에 테스트합니다.
• 운영 개선 루프: 프로덕션 세션과 에스컬레이션 로그에서 실패 패턴을 찾고, Codex가 수정안을 제안하며, 팀이 테스트 후 승인합니다.

이 구조는 기존 SaaS 개발의 배포 파이프라인과 닮았습니다. 코드 변경은 PR로 올라가고, 테스트를 통과하고, 리뷰를 받고, 점진적으로 배포됩니다. Presence가 흥미로운 이유는 에이전트의 지침과 정책도 비슷한 흐름으로 다루려 한다는 점입니다. 에이전트가 “스스로 바뀌는” 게 아니라, 운영 데이터를 보고 변경안을 제안하고 사람이 승인하는 구조입니다.

75% 자동 해결보다 중요한 숫자

OpenAI는 Presence가 자사의 영어 전화 지원 채널에서 인바운드 이슈의 75%를 사람 도움 없이 해결하고, Codex 기반 개선 루프가 10일 만에 사람 handoff를 15%p 줄였다고 밝혔습니다. 이 숫자는 마케팅 문구로만 보면 위험합니다. 모든 회사가 바로 75% 자동화를 얻는다는 뜻이 아니기 때문입니다.

실무적으로 봐야 할 포인트는 다른 데 있습니다. 첫째, 측정 단위가 “응답 품질”이 아니라 “문제 해결”입니다. 둘째, handoff 비율이라는 운영 지표가 개선 루프의 핵심 입력으로 사용됩니다. 셋째, 전화 지원처럼 실시간성과 책임 소재가 중요한 채널에서 테스트했다는 점입니다.

에이전트 제품을 만드는 팀이라면 다음 지표를 먼저 정의해야 합니다.

• 자동 해결률: 사람 개입 없이 실제 업무가 끝난 비율
• 에스컬레이션 적정률: 넘겨야 할 건 넘기고, 넘기지 않아도 될 건 처리했는지
• 정책 위반률: 승인 없이 하면 안 되는 행동을 시도했는지
• 재문의율: 사용자가 같은 문제로 다시 연락했는지
• 평균 처리 시간: 사람이 처리했을 때 대비 얼마나 줄었는지

이 지표 없이 “응답이 그럴듯하다”만 보면 프로덕션 운영에서 바로 막힙니다.

Aibase 독자가 적용할 수 있는 설계 기준

Presence를 그대로 쓰지 못해도 구조는 배울 수 있습니다. 특히 AI 고객지원, 사내 운영 자동화, 세일즈 보조, 데이터 리서치 에이전트를 만드는 팀은 다음처럼 쪼개는 게 안전합니다.

첫째, 업무를 한 문장으로 제한합니다. “고객 지원 에이전트”가 아니라 “구독 결제 실패 문의를 확인하고 재결제 링크를 안내하는 에이전트”처럼 좁혀야 합니다. 업무가 좁을수록 필요한 권한과 실패 기준도 명확해집니다.

둘째, 도구별 권한을 분리합니다. 읽기 도구, 쓰기 도구, 결제 도구, 메시지 발송 도구를 같은 레벨로 두면 안 됩니다. 읽기는 자동, 쓰기는 조건부, 결제·환불·외부 발송은 승인 필수처럼 나눠야 합니다.

셋째, 운영 로그를 “프롬프트 개선 재료”로 저장합니다. 실패한 대화 전문만 쌓아두면 나중에 분석이 어렵습니다. 요청 유형, 사용한 도구, 에스컬레이션 사유, 정책 판단, 최종 결과를 구조화해야 합니다.

넷째, 수정안은 런타임에서 바로 반영하지 않습니다. 에이전트가 새 지침을 제안하더라도 PR이나 리뷰 큐를 거치게 해야 합니다. 그래야 한 번의 실패 수정이 다른 업무를 망가뜨리는 일을 줄일 수 있습니다.

다섯째, 처음부터 전 채널 자동화를 목표로 잡지 않습니다. Presence도 특정 job에서 시작한다고 설명합니다. 한국 스타트업이 적용한다면 고객센터 전체 자동화보다 “환불 불가 사유 설명”, “계정 잠금 해제 안내”, “인보이스 재발송”처럼 결과 검증이 쉬운 업무부터 시작하는 편이 낫습니다. 작은 업무에서 완료율, 승인율, 에스컬레이션 사유가 안정적으로 쌓이면 그다음 업무로 확장할 근거가 생깁니다.

바로 실행할 체크리스트

• 에이전트 업무를 1개 job으로 줄였는가?
• 읽기, 쓰기, 외부 발송, 결제성 액션 권한을 분리했는가?
• 자동 처리와 사람 승인 기준을 문서화했는가?
• 에스컬레이션 사유를 구조화해서 저장하는가?
• “응답 점수”가 아니라 “업무 완료율”을 보고 있는가?
• 운영 로그에서 나온 개선안을 테스트와 리뷰 후 배포하는가?
• 고위험 시나리오를 최소 20개 이상 만들어 사전 시뮬레이션했는가?

Presence의 핵심은 OpenAI 브랜드가 아닙니다. 에이전트가 업무 시스템 안으로 들어갈 때 필요한 운영 단위입니다. 지금 에이전트를 만들고 있다면 모델 선택표보다 권한표, 에스컬레이션표, 평가표를 먼저 만들어야 합니다.