OpenAI Presence: 셀프서비스가 아닌 관리형 AI 에이전트 구축

OpenAI에 따르면 Presence는 현재 영어 전화 지원 채널로 들어오는 문의의 75%를 사람의 도움 없이 해결하며, 개선 루프를 통해 10일 만에 상담원 이관 비율을 15%포인트 낮췄습니다. 그러나 이 수치를 만든 제품은 누구나 가입해 쓰는 에이전트 빌더가 아닙니다. 에이전트와 정책, 평가, 시스템 통합, 지속적인 운영 업무를 하나로 묶은 관리형 엔터프라이즈 AI 에이전트 구축 서비스입니다.

결론: OpenAI Presence가 파는 것은 모델이 아니라 AI 에이전트 구축과 배포입니다

OpenAI Presence는 고객 대상 음성 또는 채팅 워크플로가 엄격한 정책 아래 실제 작업을 수행해야 하고, 도입 기업이 OpenAI와 배포 부담을 나누고 싶을 때 검토할 가치가 있습니다. 반대로 셀프서비스 에이전트 빌더가 필요한 소규모 팀, SDK를 찾는 개발자, 책임질 좁고 명확한 워크플로조차 정하지 못한 기업에는 출발점으로 맞지 않습니다.

출시 조건을 보면 제품의 성격이 유난히 선명하게 드러납니다. Presence는 제한적 정식 출시 형태로 자격을 갖춘 엔터프라이즈 고객에게만 제공됩니다. OpenAI Forward Deployed Engineers와 선정된 글로벌 시스템 통합 사업자가 배포를 주도하며, OpenAI도 이 제품이 셀프서비스가 아니라고 명시합니다. 출시 페이지와 현재 Frontier 페이지 어디에도 공개 정가가 없습니다.

결국 제공 방식 자체가 제품입니다. 최첨단 모델이라면 이미 고객 지원 요청의 뜻을 파악할 수 있습니다. 진짜 어려운 일은 올바른 계정 맥락을 제공하고, 권한을 제한하고, 환불 정책을 강제하고, 수행한 작업을 검증하는 것입니다. 언제 승인이 필수인지 판단하고, 위험한 사례를 사람에게 넘기고, 어제까지 잘되던 동작을 망가뜨리지 않으면서 시스템을 개선하는 일도 포함됩니다. Presence는 이 모든 업무를 하나의 관리형 도입 프로젝트로 묶습니다.

OpenAI Presence에는 무엇이 들어 있나

Presence는 범용 디지털 직원이 아니라, 하나의 명확한 업무를 프로덕션에서 수행하도록 감싼 시스템입니다. 모든 배포는 구체적인 워크플로 하나에서 시작합니다. 에이전트에는 그 업무에 필요한 지식과 시스템 접근 권한만 주어지고, 고객사는 정책과 승인 지점, 사람에게 이관하는 규칙을 정합니다.

가드레일이라는 말은 모델 응답 뒤에 붙이는 필터처럼 들릴 수 있습니다. 여기서는 입력, 툴, 작업, 권한, 에스컬레이션을 제약하는 더 넓은 통제 체계를 뜻합니다. Presence는 정책과 표준 운영 절차, 가드레일, 승인된 작업, 시뮬레이션, 평가 툴, 그리고 Codex를 활용한 개선 프로세스를 결합합니다.

1. 1

   업무 하나의 범위를 정합니다

   청구 문제 해결, 보험금 청구 지원, 직원 IT 요청 처리처럼 처음부터 끝까지 완결되는 성과를 고릅니다. “모든 고객을 도와라”처럼 범위가 넓은 지시는 유용한 평가 세트도, 방어 가능한 권한 경계도 만들 수 없습니다.

2. 2

   맥락과 접근 권한을 제한합니다

   해당 업무에 필요한 기록과 시스템만 연결합니다. 청구 담당 에이전트라면 신원, 계정, 청구서, 결제 맥락이 필요할 수 있습니다. 고객 데이터 전체에 제한 없이 접근할 이유는 없습니다.

3. 3

   정책과 승인 절차를 명문화합니다

   에이전트가 무엇에 답할 수 있는지, 어떤 작업을 수행할 수 있는지, 언제 승인을 요청해야 하는지, 언제 사람이 이어받는지를 정합니다. 문장이 정확해도 승인받지 않은 작업을 실행했다면 프로덕션 실패입니다.

4. 4

   출시 전에 시뮬레이션합니다

   일반적인 요청과 예외 상황, 위험도가 높은 시나리오를 평가기에 넣어 검증합니다. OpenAI에 따르면 결과의 품질, 정책 준수, 툴 사용, 에스컬레이션 동작을 확인합니다.

5. 5

   변경 통제 아래 개선합니다

   프로덕션 세션과 에스컬레이션, 품질 신호를 보면 빈틈이 드러납니다. Codex가 그 신호를 조사해 업데이트를 제안하면, 팀은 통제된 배포를 승인하기 전에 현재 프로덕션 버전을 기준으로 테스트할 수 있습니다.

데모보다 중요한 것은 이 루프입니다. 음성 AI 상담원이 출시일에는 자연스럽게 말하더라도, 제품이 바뀌거나 새로운 환불 예외가 생기거나 고객이 기존 테스트 세트에 없던 방식으로 요청하기 시작하면 실패할 수 있습니다. Presence는 프로덕션 동작에서 개선안을 찾아내되, 그 제안과 실제 시스템 사이에 테스트와 승인 절차를 둡니다.

AI 고객센터 책임자에게는 이것이 챗봇과 워크플로 운영 시스템을 가르는 실질적인 차이입니다. 챗봇은 답합니다. 프로덕션 에이전트는 검증하고 판단하며, 부여된 권한 안에서 행동하고, 결과를 기록한 뒤 위험이 권한 범위를 넘으면 사람에게 이관합니다.

성과는 유망하지만 증거 범위는 좁습니다

출시 자료는 Presence가 실제 지원 채널을 운영할 수 있음을 보여주지만, 기업 전반에 통용되는 수익성까지 입증하지는 않습니다. OpenAI가 제시한 결과는 자사의 영어 전화 지원 번호인 1-888-GPT-0090에서 나온 것이므로, 제품의 실사용 근거인 동시에 공급업체가 직접 보고한 근거이기도 합니다.

디자인 파트너 사례는 아직 초기 단계입니다. BBVA는 멕시코에서 일상적인 은행 업무를 지원하는 음성 서비스를 검토하고 있습니다. SoftBank는 자연스러운 일본어 고객 대화를 테스트하고 있습니다. IAG는 악천후처럼 수요가 급증하는 상황에서의 지원을 검토 중입니다. 언어와 규제 대상 워크플로 전반에 걸친 폭을 보여주는 프로그램이지만, OpenAI는 이를 동등한 수준의 프로덕션 성과로 제시하지 않습니다.

출시 자료에는 구매팀이 필요로 하는 숫자도 빠져 있습니다. 공개 가격, 구축 기간, 최소 사용량, 지원 모델, 작업별 오류율, 정확히 해결된 문의 한 건당 비용이 없습니다. 제한적 정식 출시 단계라는 점을 감안하면 이해할 수 있지만, 신뢰할 만한 공개 비용 비교가 아직 존재하지 않는다는 뜻이기도 합니다. 계약과 워크플로 기준선 없이 제시되는 정밀한 ROI 주장은 허구로 봐야 합니다.

OpenAI 에이전트 제품군에서 Presence의 위치

Presence는 ChatGPT Workspace Agents, OpenAI Agents SDK, Frontier까지 아우르는 제품군 안에서 관리형 워크플로를 맡는 경로입니다. 이 이름들을 서로 바꿔 써도 되는 제품처럼 취급하면 구매 과정이 어긋납니다. 제품마다 소유권이 놓이는 지점이 다르기 때문입니다.

ChatGPT Workspace Agents: 반복되는 내부 업무

ChatGPT Workspace Agents는 Business 또는 Enterprise 워크스페이스 안에서 이미 반복되는 업무를 처리하는 더 가벼운 경로입니다. 빌더에서 모델과 추론 강도를 선택하고, 앱과 툴을 연결하고, 동료에게 에이전트를 공개할 수 있습니다. Slack에서 사용하거나 일정을 설정하고 API로 실행하는 것도 가능합니다.

통제 기능은 의미가 있지만 실행 경계는 더 좁습니다. 앱과 커넥터의 쓰기 작업은 기본값이 Always ask입니다. Connector Action Constraints로 통합 기능이 할 수 있는 일을 제한할 수 있지만, OpenAI는 이 제약이 커넥터가 반환하는 데이터를 필터링하지는 않는다고 설명합니다. 파일은 각각 512 MB, 에이전트 하나당 총 10 GB로 제한됩니다.

API의 결정적인 한계는 운영 방식에 있습니다. 트리거는 실행을 대기열에 넣고 응답 본문 없이 202 Accepted를 반환합니다. 실행 ID를 주지 않으며, 현재는 해당 API로 응답 결과를 다시 가져올 수도 없습니다. 결과를 기다리지 않는 내부 업무라면 쓸 수 있습니다. 그러나 동기식 상태와 재시도 로직, 추적 가능한 결과가 필요한 고객 대상 제품의 계약으로는 적합하지 않습니다.

OpenAI Agents SDK: 맞춤형 제품의 소유권

OpenAI Agents SDK 경로는 에이전트를 자사 제품이나 인프라 안에 넣으려는 기업에 맞습니다. OpenAI의 에이전트 구축 가이드는 아키텍처를 세 가지 핵심 요소로 정리합니다. 추론하는 모델, 정보를 읽거나 작업을 수행하는 툴, 동작을 정의하는 지시문입니다.

하지만 이 세 요소는 시스템의 중심일 뿐입니다. 구축 주체는 신원, 인가, 툴 계약, 평가 데이터, 모니터링, 대체 동작, 사고 대응, 비용까지 여전히 책임져야 합니다. OpenAI는 우선 가장 강력한 모델로 평가 기준선을 세운 뒤, 정확도를 유지할 수 있는 곳부터 더 작은 모델로 교체하라고 권합니다. 멀티 에이전트 아키텍처를 추가하기 전에 단일 에이전트의 성능을 최대한 끌어올리라는 조언도 합니다.

워크플로가 제품의 차별점이거나 배포 제약이 이례적일 때, 또는 모델과 툴 비용을 세밀하게 조정해야 할 때는 맞춤형 구축이 옳습니다. 공급업체 이동성이 중요하다면 특정 공급업체의 SDK보다 위 계층에 추상화를 설계해야 합니다. SDK를 고르는 것만으로 이동성이 생기지는 않습니다.

OpenAI Frontier: 조직 전체를 위한 플랫폼

OpenAI Frontier는 여러 부서와 시스템에서 다수의 에이전트를 운영하는 기업을 위한 폭넓은 플랫폼 경로입니다. 공개된 구성 계층은 Business Context, Agent Execution, evaluation and optimization, enterprise security and governance입니다.

Frontier는 고객사가 만든 에이전트, OpenAI 에이전트, 타사 에이전트를 한 플랫폼에서 관리하도록 설계됐습니다. OpenAI는 에이전트 신원 및 접근 관리, 명시적 권한, 감사 가능한 작업, 모니터링, 상세 로그를 설명합니다. Enterprise Frontier Program에서는 Forward Deployed Engineers가 고객사와 함께 아키텍처를 설계하고, 거버넌스를 운영 체계로 만들며, 프로덕션에서 에이전트를 실행합니다.

제품 구도는 단순합니다. Workspace Agents는 내부 에이전트 경험을 패키지로 제공하고, SDK는 구성 요소를, Presence는 배포된 워크플로를, Frontier는 엔터프라이즈 통제 계층을 제공합니다. OpenAI는 Presence 계약에 어떤 Frontier 구성 요소가 포함되는지 설명하는 공개 계약 지도를 내놓지 않았습니다. 구매자는 추정하지 말고 직접 확인해야 합니다.

OpenAI 밖의 시장까지 넓혀 보려면 2026년 최고의 AI 에이전트에서 엔터프라이즈 플랫폼과 운영상의 선택지를 비교해 보십시오.

누가 Presence를 도입하고, 누가 직접 구축해야 하나

워크플로의 범위가 좁고 가치가 크며 실제 작업을 수행하고, 실패 비용이 높다면 Presence를 구매하는 편이 맞습니다. 에이전트가 전략적 지식재산이거나 운영 제약이 특수하거나, 관리형 프로덕션 경로보다 장기 통제권이 더 중요하다면 직접 구축해야 합니다.

Presence는 특히 정책 비중이 큰 서비스 흐름에서 설득력이 있습니다. 악천후 중 보험금 청구 현황 전화를 처리하는 보험사를 예로 들어 보겠습니다. 에이전트는 전화를 건 사람의 신원을 확인하고, 올바른 보험 계약과 청구 건을 찾아야 합니다. 단순 현황 문의인지 변경 요청인지 구분하고, 권한 안에서만 행동하며, 위험이 커지면 사람에게 넘겨야 합니다. 자연어는 한 요소에 불과합니다. 이 워크플로가 안전한지는 접근 권한과 에스컬레이션이 결정합니다.

에이전트 자체가 경쟁 우위를 만든다면 맞춤형 구축이 유리합니다. 버티컬 소프트웨어 회사에는 독자적인 툴, 도메인 전용 평가 세트, 차별화된 사용자 경험, 여러 모델 공급업체 지원, 또는 관리형 서비스가 맞출 수 없는 환경에 배포하는 능력이 필요할 수 있습니다. 이때 운영 루프를 외부에 맡기면 제품팀 안에 남아야 할 학습까지 함께 외주화할 수 있습니다.

운영자의 관점에서는 답이 달라집니다. 정책 비중이 큰 지원 대기열을 운영하지만 상설 에이전트 운영 조직을 꾸릴 생각이 없는 중견기업 CTO라면 Presence를 파일럿할 이유가 충분합니다. 제품 자체가 에이전트인 투자를 유치한 창업자는 대체로 아키텍처와 평가 데이터를 직접 소유해야 합니다. 내부 승인 업무를 자동화하는 시니어 운영자는 Workspace Agents나 결정형 워크플로부터 시작하는 편이 낫습니다. 혼자 일하는 기술 개발자에게는 SDK 경로가 더 적합합니다. Presence는 셀프서비스도, 가벼운 실험을 위한 제품도 아니기 때문입니다.

LLM이 입력을 이해할 수 있다는 이유만으로 에이전트를 만들지는 마십시오. 규칙 엔진이 안정적으로 판단할 수 있고 언어 계층은 구조화된 필드만 수집하면 된다면, 의사결정은 결정형으로 유지해야 합니다. 확률적 추론은 실제로 모호성을 풀어야 하는 곳에만 사용합니다.

계약 전에 AI 에이전트 구축 성과표를 요구하십시오

파일럿은 대화가 얼마나 사람처럼 들리는지가 아니라, 올바른 결과와 통제된 실패로 평가해야 합니다. 75% 해결률은 시선을 끄는 유용한 수치지만, 계약서에는 재무·위험·운영 조직의 검증을 견딜 정의가 필요합니다.

최소한 다음 지표를 추적해야 합니다.

• 정확한 해결률: 단순히 사람의 개입 없이 종료된 비율이 아니라, 처리 대상 문의를 정확하게 완료한 비율입니다.
• 오해결률: 틀린 답변이나 잘못된 작업, 해결되지 않은 요구가 있는데도 완료로 표시된 문의의 비율입니다.
• 정책 준수: 해당 시점에 적용되는 규칙과 승인 경로를 에이전트가 따랐는지 봅니다.
• 툴 실행 품질: 읽기와 쓰기가 올바른 레코드와 매개변수를 대상으로 했고, 의도한 상태 변경을 만들었는지 확인합니다.
• 에스컬레이션 품질: 위험하거나 불확실한 사례가 업무를 이어갈 수 있는 맥락과 함께 적절한 담당자에게 전달됐는지 봅니다.
• 정확히 해결된 문의 한 건당 비용: 계약, 모델, 통합, 검토, 지원 비용을 검증된 성공 건수로 나눕니다.
• 지연 시간과 이탈: 정상 및 최대 수요에서 응답 시간이 어떻게 변하고, 해결 전에 전화를 끊는 고객이 있는지 측정합니다.
• 변경 안전성: 정책이나 프롬프트 업데이트 제안이 기존에 검증된 사례를 퇴행시키지 않으면서 목표 사례를 개선하는지 확인합니다.

분모가 중요합니다. 시스템이 쉬운 문의만 맡고 비용이 큰 요청은 모두 넘기는 방식으로 자체 해결률을 높일 수 있습니다. 나중에 다시 접수되는 대화를 종결 처리해 해결률을 부풀릴 수도 있습니다. 의도, 작업 유형, 위험 등급, 언어, 채널별로 결과를 나눠야 전체 수치가 비용이 큰 실패를 숨기지 못합니다.

1. 1

   완결된 성과 하나를 고릅니다

   업무가 어디서 시작하는지, 올바른 종료 상태가 무엇인지, 어떤 작업을 할 수 있는지, 무엇을 반드시 사람에게 넘겨야 하는지까지 비즈니스 용어로 정의합니다.

2. 2

   평가 세트를 만듭니다

   실제 정책 문서와 비식별화한 과거 패턴을 사용해 일반 요청, 모호한 상황, 정보 누락, 적대적 표현, 변경된 정책, 고위험 예외 사례를 다룹니다.

3. 3

   권한 매트릭스를 정합니다

   모든 툴 작업을 나열하고 가역성, 권한, 재무 영향, 고객 피해에 따라 분류합니다. 증거가 더 넓은 권한 경계를 뒷받침할 때까지 위험도가 높거나 되돌릴 수 없는 작업에는 사람의 감독을 둡니다.

4. 4

   현행 프로세스와 나란히 실행합니다

   에이전트가 실제 레코드를 바꾸도록 허용하기 전에 제안한 답변, 작업, 에스컬레이션을 현재 운영 결과와 비교합니다. 불일치를 평균으로 지우지 말고 원인을 조사합니다.

5. 5

   검증된 의도부터 확대합니다

   입증된 요청 유형을 통제된 그룹 단위로 프로덕션에 투입합니다. 즉시 롤백할 경로를 유지하고, 정책·툴·지시문 변경을 배포하기 전에 회귀 테스트를 의무화합니다.

출시 전에 소유권도 확정해야 합니다. 누군가는 정책 변경을 승인하고, 사고를 검토하고, 통합을 유지하고, 평가 세트를 소유하며, 언제 에이전트 권한을 넓힐지 결정해야 합니다. Presence는 기술과 배포 전문성을 제공할 수 있습니다. 그러나 해당 워크플로에 대한 기업의 책임까지 없애 주지는 못합니다.

전략적 의미

OpenAI Presence가 중요한 이유는 엔터프라이즈 에이전트 판매의 중심을 모델 접근권에서 운영 책임으로 옮겼기 때문입니다. 이제 약속은 “우리의 지능을 사용하십시오”가 아닙니다. “통제된 워크플로를 함께 운영하고 출시 후에도 개선하겠습니다”에 가깝습니다.

이는 또 하나의 범용 에이전트 빌더보다 강한 제품 구조입니다. 동시에 OpenAI의 배포팀, 모델, 개선 프로세스, 계약에 더 깊이 의존하게 됩니다. 관리형 속도와 공동 운영 전문성이 시스템 소유의 가치보다 클 때는 합리적인 거래입니다. 반대로 워크플로가 독자 역량이 되어야 한다면 값비싼 의존입니다.

따라서 핵심 구매 질문은 Presence가 얼마나 똑똑해 보이는지가 아닙니다. 결과를 누가 책임지는지, 각 작업을 누가 통제하는지, 업데이트가 안전하다는 사실을 누가 입증하는지, 에이전트가 실패했을 때 누가 워크플로를 떠받치는지 물어야 합니다. 계약이 이 질문들에 답하고 파일럿이 경제성을 증명한다면 Presence는 엔터프라이즈 AI 에이전트 도입에서 가장 어려운 구간을 단축할 수 있습니다. 그렇지 않다면 직접 측정하고 소유할 수 있는 더 좁은 시스템을 구축하는 편이 낫습니다.

OpenAI Presence는 셀프서비스 제품인가요?

아닙니다. OpenAI에 따르면 Presence는 제한적 정식 출시 형태로 자격을 갖춘 엔터프라이즈 고객에게 제공됩니다. Forward Deployed Engineers와 선정된 글로벌 시스템 통합 사업자가 배포를 주도하며, 출시 페이지는 구매 문의를 각 고객의 OpenAI 담당 팀으로 안내합니다.

OpenAI Presence와 ChatGPT Workspace Agents는 어떻게 다른가요?

Workspace Agents는 앱, 툴, Slack, 일정, API 트리거를 활용해 반복 업무를 처리하도록 ChatGPT 안에서 만들고 공유하는 에이전트입니다. Presence는 기업 시스템을 사용해 통제된 작업을 수행하고 사람에게 에스컬레이션하는 실시간 음성·채팅 워크플로를 위한 관리형 프로덕션 배포입니다.

OpenAI는 Presence 가격을 공개했나요?

2026년 7월 22일 출시 페이지와 현재 Frontier 제품 페이지 어디에도 공개 정가가 없습니다. 유의미한 견적을 받으려면 하나의 구체적인 워크플로와 처리량, 통합 범위, 지원 모델, 측정 가능한 성공 기준을 함께 정해야 합니다.

기업은 Presence를 구매해야 하나요, 자체 에이전트를 구축해야 하나요?

정책 비중이 큰 음성 또는 채팅 워크플로 하나에 관리형 배포가 필요하고 기업이 OpenAI를 긴밀한 운영 파트너로 받아들인다면 구매하는 편이 맞습니다. 에이전트가 제품의 차별점이거나 아키텍처 통제가 전략적으로 중요할 때, 배포 제약이 특수할 때, 또는 모델 이동성과 단위 경제성이 관리형 속도보다 중요할 때는 직접 구축해야 합니다.

관리형 에이전트를 구매할지 시스템을 직접 소유할지 결정하는 단계라면, 구축 전에 워크플로와 위험 경계를 먼저 설계하십시오.