# 티켓 응대를 학습 루프로 바꾼 OpenAI Support Agent Operating Model
개요
OpenAI는 2025년 9월 29일, 자사 support 조직이 AI를 이용해 티켓 응대를 운영 모델로 재설계한 사례를 공개했습니다.[1] 공개 사례의 핵심은 챗봇 하나를 붙인 것이 아니라, support surface, living knowledge, eval/classifier를 하나의 반복 개선 루프로 묶은 점입니다.[1] 이 글은 OpenAI 공식 사례를 출발점으로 삼되, Zendesk CX Trends 2026, Nubank의 100M+ 사용자 규모 support agent 연구, Alibaba Taobao 현장 실험, NIST와 OWASP의 생성형 AI 리스크 기준을 함께 검토합니다.[7][8][9][10][11] 따라서 결론도 “상담원을 대체합니다”가 아니라 “고객 접점, 지식, 평가, 권한, 사람 검토를 운영 시스템으로 묶어야 합니다”에 가깝습니다.
1. 사례의 핵심: 티켓 처리에서 운영 시스템으로
OpenAI가 공개한 support 사례는 먼저 규모 문제에서 출발합니다. OpenAI는 수억 명의 사용자를 대상으로 매년 수백만 건의 요청을 처리하고 있으며, 그 요청량도 빠르게 늘고 있다고 설명합니다.[1] 이런 환경에서는 queue를 더 효율적으로 비우는 방식만으로는 한계가 있습니다. 반복 질문, 정책 혼선, 제품 UX 문제, 장애 커뮤니케이션의 빈틈을 다시 제품과 운영 지식으로 되돌리는 구조가 필요합니다.
공개 사례에서 OpenAI가 제시한 핵심 building block은 세 가지입니다.[1]
| 구성 요소 | 공개 사례의 의미 | 운영 설계에서의 해석 | | --- | --- | --- | | Surfaces | Chat, email, phone, in-product support처럼 사용자가 도움을 요청하는 접점 | Support를 별도 목적지가 아니라 제품 경험 안의 action으로 배치합니다. | | Knowledge | 정적 문서가 아니라 실제 대화, 정책, 맥락에서 계속 개선되는 지식 | FAQ, 정책, resolved ticket, release note, incident postmortem을 운영 자산으로 관리합니다. | | Evals and classifiers | 품질 정의, 측정, 피드백을 사람과 소프트웨어가 함께 만드는 장치 | Tone, correctness, policy adherence, escalation, tool safety를 배포 전후로 평가합니다. |
이 구조가 중요한 이유는 AI support의 성과가 자동응답률 하나로 설명되지 않기 때문입니다. 단순 containment rate만 높이면 고객이 사람에게 도달하지 못할 수 있고, 응답 시간을 줄이는 데만 집중하면 잘못된 답변이 더 빠르게 나갈 수 있습니다. OpenAI 사례에서 더 주목할 점은 support rep의 역할 변화입니다. 공개 글은 rep가 테스트 케이스를 만들고, classifier를 제안하며, workflow gap을 자동화하는 식으로 시스템 개선에 참여한다고 설명합니다.[1] 즉 support 조직은 반복 응대 조직에서 knowledge, eval, classifier를 개선하는 운영 조직으로 이동합니다.
외부 자료도 이 방향을 보강합니다. Zendesk CX Trends 2026은 고객이 같은 설명을 반복하는 상황을 싫어하며, memory-rich AI가 상호작용 맥락을 유지해 개인화를 제공한다고 설명합니다.[7] 같은 보고서는 AI 때문에 24/7 고객지원 기대가 커졌고, multimodal support와 AI 의사결정 설명 가능성도 중요해졌다고 제시합니다.[7] 이 자료는 OpenAI의 성과를 입증하는 근거가 아니라, support surface와 context memory가 왜 단순 FAQ보다 중요한지 보여주는 시장 맥락입니다.
2. 사용된 AI 기술과 평가 루프
OpenAI 공개 사례는 support 운영에 Agents SDK, Responses API, Realtime API, Evals dashboard, dynamic actions를 사용한다고 설명합니다.[1] 각 기술의 역할은 다음처럼 나누어 볼 수 있습니다.
| 기술 | 공개 또는 공식 문서상 역할 | Support 업무에서의 적용 | | --- | --- | --- | | Agents SDK | 공개 사례는 step-level trace와 tool call 관찰성을 언급합니다.[1] 공식 문서에서도 Agents SDK는 orchestration, guardrail, state, observability, workflow evaluation 같은 agent 구성 요소를 제공합니다.[2] | Intent routing, knowledge search, tool call, approval, escalation을 하나의 agent run으로 추적합니다. | | Responses API | 공개 사례에서 tone, correctness, policy adherence classifier의 기반으로 언급됩니다.[1] | Billing, account, technical issue, abuse, enterprise escalation, policy-sensitive issue를 분류합니다. | | Function calling | 모델이 정의된 tool을 호출하고, 애플리케이션이 tool output을 다시 모델에 넘기는 흐름입니다.[3] | Invoice lookup, incident lookup, refund request처럼 내부 시스템과 연결되는 action을 제한적으로 수행합니다. | | Realtime API | Voice-agent session에서 audio/text, model response, tool call, session event를 처리합니다.[4] | 전화나 브라우저 음성 support를 만들 때 사용할 수 있습니다. 지연, 전사 품질, 통화 보관 정책은 별도 설계가 필요합니다. | | Evals | OpenAI 사례는 Evals dashboard로 품질을 측정한다고 설명합니다.[1] 2026년 7월 7일 현재 공식 문서는 기존 Evals platform이 2026년 10월 31일 read-only가 되고 2026년 11월 30일 종료될 예정이라고 안내합니다.[5] | 특정 dashboard보다 eval dataset, rubric, grader, production trace를 이식 가능한 자산으로 관리하는 편이 안전합니다. |
지원 업무에서는 답변 생성보다 “어떤 요청인지, 어떤 지식을 써야 하는지, 어떤 tool까지 허용되는지, 언제 멈춰야 하는지”가 더 중요합니다. 따라서 support agent는 대화 모델 하나가 아니라 classifier, retriever, tool gateway, human review, eval runner가 함께 움직이는 런타임으로 봐야 합니다.
Nubank의 customer support agent 연구는 이 판단을 뒷받침하는 독립 사례입니다. 이 논문은 100M+ 사용자 규모에서 structured context engineering, human-in-the-loop prompt iteration, LLM judge evaluation, online measurement를 하나의 production framework로 묶어야 한다고 설명합니다.[8] 특히 card delivery deployment에서는 이전 agent variant 대비 AI transactional NPS가 37 percentage points, self-service rate가 29 percentage points 개선됐다고 보고합니다.[8] 이 수치는 OpenAI의 성과가 아니라, eval-driven support agent가 실제 운영 지표와 연결될 수 있음을 보여주는 별도 근거입니다.
3. 공개 사례에서 확인되는 업무 흐름
OpenAI 내부 시스템의 세부 구현은 공개되지 않았습니다. 다만 공개 사례와 공식 API 문서를 기준으로 보면, 유사한 support agent의 업무 흐름은 다음과 같이 정리할 수 있습니다.
| 단계 | 설명 | 주요 통제 | | --- | --- | --- | | 문의 인입 | 고객이 chat, email, phone, in-product support 중 하나로 요청합니다. | 채널별 인증, rate limit, 개인정보 수집 범위 | | 유형과 위험도 분류 | Intent classifier가 billing, account, technical issue, abuse, enterprise escalation, policy-sensitive issue를 나눕니다. | 분류 confidence, fail-closed rule, escalation threshold | | 지식 검색과 상태 조회 | Agent가 help docs, policy, resolved tickets, account state, incident status를 검색합니다. | 권한 기반 검색, 최신성, 출처 표시 | | 답변 또는 action 제안 | 필요한 경우 Invoice lookup, incident lookup, refund request 같은 tool을 호출하거나 제안합니다.[1][3] | Read-only/action 분리, schema validation, approval policy | | 사람에게 escalation | 민감하거나 불확실한 케이스는 support rep 또는 specialist에게 넘깁니다. | Reviewer 권한, SLA, override reason | | 학습 루프로 환류 | Trace, tool call, classifier output, rep correction을 knowledge patch, eval item, classifier 개선으로 전환합니다. | Audit log, dataset versioning, regression test |
이 흐름에서 AI는 최종 책임자가 아니라 support 운영을 연결하는 레이어입니다. 특히 refund, account unlock, plan change, incident communication, enterprise 계약 조건처럼 고객·비용·신뢰에 영향을 주는 action은 자동 실행보다 승인, 감사, 재처리 절차를 먼저 설계해야 합니다.
Alibaba Taobao 현장 실험은 human-in-the-loop 설계에서 중요한 반례를 제공합니다. 해당 연구는 agentic AI가 평균 chat duration을 줄였지만 AI-eligible chat의 고객 rating은 낮출 수 있었고, 사람 개입의 효과도 실패 유형과 개입 시점에 따라 달라졌다고 보고합니다.[9] 따라서 “필요하면 사람에게 넘깁니다”라는 문장만으로는 부족합니다. 어떤 실패가 기술적 한계인지, 고객 불만이 이미 커진 정서적 escalation인지, 어느 시점에 사람이 개입해야 하는지까지 workflow에 들어가야 합니다.
4. 구현 가능한 시스템 아키텍처
아래 아키텍처는 OpenAI 내부 인프라를 묘사한 것이 아닙니다. 공개 사례와 OpenAI API 문서를 바탕으로, 유사 기업이 AWS에서 support agent를 구현할 때 검토할 수 있는 레퍼런스 구성입니다. 실제 구축에서는 기존 ticketing, CRM, billing, identity, incident system, data residency 요구에 맞춰 조정해야 합니다.
| 논리 단계 | AWS 서비스 예시 | 역할 | | --- | --- | --- | | Support surfaces | CloudFront, S3, API Gateway, SQS | Chat, email, voice webhook, 제품 내 support 요청을 받습니다. | | Agent runtime | ECS Fargate, Step Functions | Intent routing, policy check, tool orchestration, escalation을 제어합니다. | | Model and agent layer | OpenAI Responses API, Agents SDK, Realtime API | 분류, 답변 생성, tool call, voice support, trace 관찰성을 담당합니다.[1][2][4] | | Knowledge and context | OpenSearch, S3, DynamoDB | Help docs, policy, resolved tickets, release note, incident postmortem, account state를 검색·저장합니다. | | Dynamic action gateway | Lambda, API Gateway, private connector | Refund, invoice, incident lookup 같은 action을 billing, CRM, incident system에 연결합니다.[1][3] | | Human review | Cognito, ALB, ECS Fargate | 민감하거나 불확실한 케이스를 support rep에게 넘깁니다. | | Quality loop | Trace store, eval runner, dashboard | Conversation trace, tool call, classifier output, rep correction을 eval과 knowledge patch로 전환합니다.[1][5] |
핵심 경로는 surface → classifier → agent runtime → tool gateway → human review → eval loop입니다. 이때 tool gateway는 특히 중요합니다. 모델이 action을 제안할 수 있더라도, 실제 실행 권한은 별도 정책 엔진과 업무 시스템이 통제해야 합니다. support agent의 품질은 모델 성능뿐 아니라 “어떤 요청에서 멈추는가”와 “실패를 다음 평가 항목으로 남기는가”에 크게 좌우됩니다.
5. 프로덕션 설계에서 보완할 점
권한과 action 경계
가장 먼저 read-only action과 write action을 분리해야 합니다. account status, invoice, incident status 조회는 비교적 낮은 위험으로 시작할 수 있습니다. 반면 refund, plan change, account unlock, 데이터 삭제, 계약 조건 안내는 비용·법무·신뢰 리스크가 큽니다. 이런 action은 approval-required로 두고, 모델이 직접 실행하지 못하게 하는 편이 안전합니다.
OWASP Top 10 for Large Language Model Applications 2025는 support agent가 마주칠 수 있는 위험을 구체적으로 보여줍니다. prompt injection, sensitive information disclosure, improper output handling, excessive agency, misinformation, unbounded consumption은 고객-facing LLM application에서 바로 문제가 될 수 있습니다.[11] 따라서 action gateway에는 tool allowlist, input/output schema validation, 권한별 tool scope, rate limit, idempotency key, reviewer approval이 필요합니다.
정책 민감 케이스의 fail-closed 처리
abuse, safety, 개인정보, 보안 사고, 결제 분쟁, enterprise 계약 조건은 빠른 답변보다 안전한 중단이 중요합니다. OpenAI 사례도 빠르게 답하는 것만큼 모델이 답하면 안 되는 상황을 아는 것이 중요하다고 설명합니다.[1]
NIST Generative AI Profile은 생성형 AI 위험이 lifecycle stage, source, scope에 따라 달라진다고 설명하며, 고객-facing support agent와 연결되는 위험으로 confabulation, data privacy, human-AI configuration, information security 등을 다룹니다.[10] 이 기준으로 보면 fail-closed 정책은 단순 차단 규칙이 아닙니다. 고객 피해, 개인정보 노출, 잘못된 의사결정, 과도한 자동 실행으로 이어질 수 있는 요청을 식별하고 사람 검토로 넘기는 운영 통제입니다.
평가 데이터와 human-in-the-loop
평가 데이터는 최소 세 계층으로 나누는 편이 좋습니다. 첫째, offline eval은 intent, answer correctness, tone, policy adherence, tool safety를 배포 전에 검증합니다. 둘째, online measurement는 self-service rate, resolution time, reopened ticket rate, CSAT/NPS를 실제 운영에서 추적합니다. 셋째, human correction loop는 support rep가 수정한 답변과 escalation 판단을 knowledge patch와 eval item으로 되돌립니다.
여기서 중요한 점은 eval 점수와 고객 경험이 항상 같은 방향으로 움직이지 않는다는 점입니다. Nubank 연구는 offline simulation metric과 online outcome을 연결하는 것이 iteration velocity를 높인다고 설명합니다.[8] 반대로 Alibaba 실험은 처리 시간이 줄어도 AI-eligible chat rating이 낮아질 수 있음을 보여줍니다.[9] 따라서 eval은 “정답을 잘 맞췄는가”뿐 아니라 “사람에게 넘겨야 할 때 넘겼는가”, “고객이 납득할 수 있는 근거를 제공했는가”까지 포함해야 합니다.
감사 로그와 재처리
conversation ID, user 또는 organization ID, channel, policy version, model version, retrieved knowledge, tool call input/output, reviewer action, final disposition을 남겨야 합니다. tool action에는 idempotency key와 reversal workflow가 필요합니다. 같은 환불이 두 번 실행되거나, 오래된 incident status가 고객에게 나가거나, 권한 없는 사용자가 enterprise account 정보를 조회하는 상황을 막기 위해서입니다.
감사 로그는 사후 방어용 기록에 그치면 안 됩니다. support rep의 correction, 고객의 재문의, tool failure, escalation override를 다시 dataset과 policy update로 연결해야 합니다. 이 연결이 없으면 support AI는 시간이 지나도 같은 실패를 반복합니다.
6. 구축 및 운영 비용
OpenAI 내부 운영비, 모델 조합, 티켓당 토큰 사용량은 공개되지 않았습니다. 유사 기업이 10,000 tickets/month 파일럿을 설계한다면, 먼저 다음 가정을 명시해야 합니다.
- ticket당 1~4 agent turns
- turn당 4,000~10,000 input tokens
- turn당 500~1,500 output tokens
- 검색 context, 이전 대화, tool call 결과 포함 여부에 따른 token 변동
- 음성 채널의 Realtime API 사용 시간, 전사, 전화망 또는 WebRTC 인프라 비용 별도
예를 들어 10,000 tickets/month, ticket당 3 turns, turn당 8,000 input tokens와 1,000 output tokens를 사용하면 월 240M input tokens, 30M output tokens 규모가 됩니다. 2026년 7월 7일 접근 기준 OpenAI 가격표에서 표준 short context 단가를 적용하면, 캐시와 할인을 제외한 텍스트 모델 비용은 gpt-5.4-mini 약 $315/month, gpt-5.4 약 $1,050/month, gpt-5.5 약 $2,100/month 수준으로 계산됩니다.[6] 이 값은 planning estimate일 뿐이며, prompt caching, batch/flex 처리, long context, voice, web search tool, embedding, 검색 인프라, human review 인건비를 제외합니다.[6]
AWS 레퍼런스 아키텍처 자체의 월 인프라 하한도 별도로 잡아볼 수 있습니다. 아래 표는 blogs/assets/aws_cost_estimates.py의 support_agent_pilot_estimate() 산식으로 계산한 planning estimate입니다. 2026년 7월 7일 접근 기준 AWS Price List와 AWS Pricing Calculator 문서를 기준으로, us-east-1, On-Demand, 730시간/월, 10,000 tickets/month, ticket당 20개 Step Functions state transition, 항상 켜져 있는 Fargate task 2개, 단일 m5.large.search OpenSearch 도메인과 50GB gp3 스토리지를 가정했습니다.[12][13]
| AWS 항목 | 사용량 가정 | 월 추정액 | 단가 출처 | | --- | --- | ---: | --- | | ECS Fargate | 2 tasks × 0.5 vCPU × 1GB × 730시간 | 약 $36 | [14] | | OpenSearch Service | m5.large.search 1개 × 730시간 + gp3 50GB | 약 $110 | [15] | | Step Functions | 월 200,000 Standard transitions, free tier 제외 후 과금 | 약 $4.90 | [16] | | Lambda tool/eval runner | 200,000 requests + 25,000 GB-seconds | 약 $0.46 | [17] | | API Gateway + SQS | HTTP API 60,000 calls + SQS standard 60,000 requests | 약 $0.06 | [18][19] | | S3 document/log store | S3 Standard 50GB + 100,000 PUT + 500,000 GET | 약 $1.85 | [20] | | DynamoDB state store | 5GB + 100,000 writes + 300,000 eventually consistent reads | 약 $0.10 | [21] | | CloudWatch Logs | 50GB ingest + 30GB 보관 | 약 $25.90 | [22] | | Application Load Balancer | ALB 1개 + 평균 1 LCU × 730시간 | 약 $22.30 | [23] | | 소계 | OpenAI API, 음성, 인건비, NAT/WAF/KMS/데이터 전송 제외 | 약 $201/month | |
따라서 작은 파일럿의 AWS 인프라 하한은 모델 비용을 제외하고 월 약 $200부터 시작한다고 볼 수 있습니다. 다만 OpenSearch를 3노드 운영형 구성으로 바꾸고 로그·트래픽을 더 보수적으로 잡으면 AWS 인프라만 월 $450~$700 이상으로 올라갈 수 있습니다. 이 표에는 OpenAI API/model token, Realtime voice, 전화망/WebRTC 사업자 비용, human review 인건비, NAT Gateway, WAF, KMS API call, cross-AZ/cross-region data transfer, public IPv4, AWS Support, 세금, enterprise discount, Savings Plans, Reserved Instances, Spot 할인이 들어 있지 않습니다.
실제 총비용은 모델 호출보다 integration과 운영에서 더 커질 수 있습니다. ticketing, CRM, billing, incident system connector를 만들고, 권한과 감사 로그를 설계하고, eval dataset을 관리하고, support rep correction review를 운영해야 하기 때문입니다. billing이나 incident action을 붙이면 QA, 보안 리뷰, 장애 대응, rollback 절차도 비용에 포함됩니다.
7. 비즈니스 이익과 KPI
OpenAI 사례는 특정 절감률보다 운영 모델 전환을 강조합니다. 매 interaction이 knowledge, eval, classifier 개선 데이터가 되고, support rep는 반복 응대자가 아니라 시스템 개선자로 이동합니다.[1] 이 변화는 비용 절감만이 아니라 품질과 제품 개선까지 포함하는 KPI로 측정해야 합니다.
| KPI 묶음 | 예시 지표 | 해석 | | --- | --- | --- | | 고객 경험 | First response time, resolution time, reopened ticket rate, CSAT/NPS | 고객이 실제로 문제를 해결했는지 봅니다. | | 품질 | Policy violation rate, hallucinated answer rate, wrong escalation rate, tool action failure rate | 빠른 답변이 잘못된 답변으로 바뀌지 않았는지 봅니다. | | 운영 | Human escalation ratio, rep correction rate, knowledge patch lead time, eval pass rate | 사람이 어디서 개입하고, 수정이 얼마나 빨리 시스템에 반영되는지 봅니다. | | 제품 개선 | 반복 문의 감소, incident communication 개선, release note gap 발견 속도 | Support signal이 제품과 정책 개선으로 이어지는지 봅니다. | | 투명성 | AI 답변의 근거 표시율, explanation coverage, 사람 상담원 전환 가능성 | 고객이 AI 답변과 조치를 이해하고 이의를 제기할 수 있는지 봅니다.[7] |
이 모델의 장점은 support 조직의 지식이 문서팀이나 운영 리더의 수동 업데이트에만 의존하지 않는다는 점입니다. 현장의 반복 대화가 classifier, eval, FAQ, product backlog로 연결되면 support 조직은 비용 센터를 넘어 제품과 정책을 개선하는 센서가 될 수 있습니다.
반대로 단일 KPI에 매이면 실패를 늦게 발견합니다. Alibaba 현장 실험처럼 처리 시간 개선과 customer rating 저하가 동시에 나타날 수 있습니다.[9] 따라서 속도, 품질, 신뢰, 전환 가능성을 함께 봐야 합니다. Nubank 연구의 수치처럼 NPS와 self-service rate가 동시에 개선되는 경우도 있지만, 그 결과는 evaluation pipeline과 online measurement를 함께 운영한 특정 deployment의 결과로 해석해야 합니다.[8]
8. 제조·B2B 기업에 주는 시사점
제조·B2B 기업의 support는 일반 소비자 FAQ보다 복잡합니다. 장비 모델, 설치 환경, 보증 조건, 부품 재고, 현장 엔지니어 일정, 계약 SLA, 품질 이슈, 안전 규정이 함께 얽힙니다. 따라서 support agent는 단순 Q&A가 아니라 권한 기반 검색, 상태 조회, 업무 시스템 action, 사람 승인을 결합해야 합니다.
이 맥락에서는 multimodal support도 중요합니다. Zendesk CX Trends 2026은 소비자와 CX 리더가 text, image, video를 포함하는 일관된 support 경험을 기대한다고 제시합니다.[7] 제조 현장에서는 설비 사진, 경고등 영상, 검사 성적서, 작업 로그가 troubleshooting의 핵심 근거가 될 수 있습니다. 다만 사진과 영상에는 개인정보, 고객사 영업비밀, 설비 배치 정보가 포함될 수 있으므로 업로드 전 redaction, 저장 기간, 접근 권한을 따로 설계해야 합니다.
적용 가능한 영역은 다음과 같습니다.
- 설비 장애 문의에서는 장비 매뉴얼, 과거 장애 기록, 부품 교체 이력, 현장 사진을 함께 검색해 troubleshooting 후보를 제시합니다.
- 품질 클레임에서는 lot, 공정 조건, 검사 성적서, 반품 이력을 연결해 원인 후보와 필요한 증빙을 정리합니다.
- 파트너 지원에서는 계약 조건, 가격 정책, 납기, 재고 상태를 조회하되 할인·환불·계약 변경은 사람 승인 뒤에만 실행합니다.
- 현장서비스 요청에서는 장비 상태, 보증 조건, SLA, 엔지니어 배정 가능 시간을 함께 확인합니다.
- 릴리스나 장애 이후 반복 문의는 FAQ, incident communication, product backlog로 되돌리는 루프로 관리합니다.
도입 순서는 보수적으로 잡는 편이 좋습니다. 먼저 read-only answer와 incident lookup처럼 리스크가 낮은 영역에서 시작합니다. 다음으로 invoice 재발급, RMA 상태 조회, 현장 방문 예약처럼 제한된 action을 붙일 수 있습니다. 마지막으로 환불, 계정 변경, 계약 예외, 안전 관련 조치처럼 리스크가 큰 action은 human-in-the-loop approval과 감사 로그가 충분히 검증된 뒤에만 연결하는 것이 현실적입니다.
9. 도입 체크리스트
| 점검 항목 | 완료 기준 | | --- | --- | | 요청 분류 | Channel, intent, 위험도, 계정 권한 기준으로 support request를 분류할 수 있습니다. | | 지식 정본 | Policy, FAQ, resolved ticket, incident, release note의 소유자와 업데이트 SLA가 정해져 있습니다. | | 답변 금지 기준 | Abuse, safety, 개인정보, 결제 분쟁, 계약 조건처럼 모델이 멈춰야 할 요청 유형이 정의돼 있습니다. | | Action 경계 | Tool action이 read-only, approval-required, forbidden으로 나뉘어 있습니다. | | 실행 안전성 | Tool call마다 idempotency key, audit log, rollback 또는 reversal 절차가 있습니다. | | 사람 개입 | Escalation timing, failure type, reviewer 권한, override reason이 workflow에 들어 있습니다. | | 평가 체계 | Tone, correctness, policy adherence, tool safety, escalation quality를 offline/online으로 측정합니다. | | 보안 방어 | Prompt injection, sensitive information disclosure, excessive agency, unbounded consumption 방어가 action gateway에 반영돼 있습니다.[11] | | 음성 지원 | 전사 품질, 지연, 개인정보, 통화 보관 정책을 별도로 검증합니다.[4] | | 환류 루프 | Support rep correction이 knowledge patch, classifier 개선, eval item, product backlog로 남습니다. | | 투명성 | 고객에게 AI 답변의 근거와 사람 전환 경로를 설명할 수 있습니다.[7] | | 비용 관리 | 모델 token, voice, 검색 인프라, 로그, human review, connector 운영비를 분리해 추적합니다.[6][12][13] |
결론
OpenAI Support Agent Operating Model의 본질은 support chatbot이 아니라 support 조직을 학습 가능한 시스템으로 바꾼 운영 설계입니다. 공개 사례에서 확인되는 축은 Surfaces, Knowledge, Evals and classifiers이며, Agents SDK, Responses API, Realtime API, Evals dashboard, dynamic actions가 이를 기술적으로 받칩니다.[1] 독립 출처를 함께 보면 성공 조건은 더 분명해집니다. context memory와 transparency는 고객 기대의 축이고, evaluation pipeline은 실제 운영 성과와 연결돼야 하며, human-in-the-loop는 개입 시점과 실패 유형까지 설계해야 합니다.[7][8][9] 기업이 이 모델을 참고하려면 자동응답률보다 권한, 감사, 사람 승인, 평가 데이터, 지식 업데이트 루프, 보안 가드레일을 먼저 설계해야 합니다.[10][11] 제조·B2B 기업에서는 read-only 조회와 human escalation부터 시작해, 검증된 action만 단계적으로 연결하는 방식이 현실적입니다.
출처
- Improving support with every interaction at OpenAI. OpenAI. 2025-09-29. https://openai.com/index/openai-support-model/. 접근일: 2026-07-07.
- Agents SDK. OpenAI API Docs. 2026 access 기준. https://developers.openai.com/api/docs/guides/agents. 접근일: 2026-07-07.
- Function calling. OpenAI API Docs. 2026 access 기준. https://developers.openai.com/api/docs/guides/function-calling. 접근일: 2026-07-07.
- Realtime and audio. OpenAI API Docs. 2026 access 기준. https://developers.openai.com/api/docs/guides/realtime. 접근일: 2026-07-07.
- Working with evals. OpenAI API Docs. 2026 access 기준. https://developers.openai.com/api/docs/guides/evals. 접근일: 2026-07-07.
- Pricing. OpenAI API Docs. 2026 access 기준. https://developers.openai.com/api/docs/pricing. 접근일: 2026-07-07.
- Zendesk CX Trends 2026. Zendesk. 2026. https://cxtrends.zendesk.com/. 접근일: 2026-07-07.
- Building Customer Support AI Agents at 100M-User Scale: An Evaluation-Driven Framework. Aman Gupta et al. 2026-06-13. DOI: 10.48550/arXiv.2606.08867. https://doi.org/10.48550/arXiv.2606.08867. 접근일: 2026-07-07.
- Agentic AI and Human-in-the-Loop Interventions: Field Experimental Evidence from Alibaba's Customer Service Operations. Yiwei Wang et al. 2026-06-01. DOI: 10.48550/arXiv.2605.14830. https://doi.org/10.48550/arXiv.2605.14830. 접근일: 2026-07-07.
- Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. National Institute of Standards and Technology. 2024-07. NIST AI 600-1. DOI: 10.6028/NIST.AI.600-1. https://doi.org/10.6028/NIST.AI.600-1. 접근일: 2026-07-07.
- OWASP Top 10 for Large Language Model Applications 2025. OWASP Foundation. 2025. https://genai.owasp.org/llm-top-10/. 접근일: 2026-07-07.
- Calling AWS services and prices using the AWS Price List. AWS Billing and Cost Management. 2026 access 기준. https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/price-changes.html. 접근일: 2026-07-07.
- What is AWS Pricing Calculator? AWS Pricing Calculator User Guide. 2026 access 기준. https://docs.aws.amazon.com/pricing-calculator/latest/userguide/what-is-pricing-calculator.html. 접근일: 2026-07-07.
- AWS Fargate Pricing. AWS. 2026 access 기준. https://aws.amazon.com/fargate/pricing/. 접근일: 2026-07-07.
- Amazon OpenSearch Service Pricing. AWS. 2026 access 기준. https://aws.amazon.com/opensearch-service/pricing/. 접근일: 2026-07-07.
- AWS Step Functions Pricing. AWS. 2026 access 기준. https://aws.amazon.com/step-functions/pricing/. 접근일: 2026-07-07.
- AWS Lambda Pricing. AWS. 2026 access 기준. https://aws.amazon.com/lambda/pricing/. 접근일: 2026-07-07.
- Amazon API Gateway Pricing. AWS. 2026 access 기준. https://aws.amazon.com/api-gateway/pricing/. 접근일: 2026-07-07.
- Amazon SQS Pricing. AWS. 2026 access 기준. https://aws.amazon.com/sqs/pricing/. 접근일: 2026-07-07.
- Amazon S3 Pricing. AWS. 2026 access 기준. https://aws.amazon.com/s3/pricing/. 접근일: 2026-07-07.
- Amazon DynamoDB Pricing. AWS. 2026 access 기준. https://aws.amazon.com/dynamodb/pricing/. 접근일: 2026-07-07.
- Amazon CloudWatch Pricing. AWS. 2026 access 기준. https://aws.amazon.com/cloudwatch/pricing/. 접근일: 2026-07-07.
- Elastic Load Balancing Pricing. AWS. 2026 access 기준. https://aws.amazon.com/elasticloadbalancing/pricing/. 접근일: 2026-07-07.