2026년 10월 23일 AI 트렌드: OpenAI Decisions API, Agent Skills 표준, NVIDIA Minerva와 기업 AI 도입

오늘의 답부터 말씀드리겠습니다. AI가 긴 답변을 만드는 능력만으로는 실제 업무가 끝나지 않습니다. 어디로 요청을 보낼지, 어떤 자료를 읽을지, 장애를 누구에게 알릴지, 직원에게 어떤 도구를 허용할지처럼 작고 반복적인 결정이 운영 품질을 좌우합니다. 10월 22일 공개된 OpenAI Decisions API, Anthropic의 Agent Skills 표준 기증, NVIDIA Minerva, Uber의 ChatGPT Work 도입 발표는 각각 이 문제의 다른 면을 보여줍니다.

이번 글은 2026년 10월 22일 18시부터 23일 09시까지 한국 시간에 나온 공식 자료를 우선 확인했습니다. 공식 페이지가 날짜만 표시한 경우에는 정확한 공개 시각을 확정하지 않았습니다. 아래 네 발표는 모두 공식 페이지에 10월 22일 날짜가 표시되지만, 해당 시간 구간에 최초 공개됐는지까지 원문만으로 단정할 수는 없습니다. 발표 내용, 제공 상태, 기업이 직접 검증해야 할 일을 분리해 읽어 주세요.

오늘의 AI 뉴스 한눈에 보기

네 소식 중 제품 자체의 변화가 가장 선명한 것은 Decisions API입니다. 에이전트가 모든 일을 자유롭게 판단하도록 맡기기보다, 질문과 허용된 답을 먼저 정하는 방식입니다. 제가 기업 현장에서 더 중요하게 보는 변화는 공통 규칙과 운영 책임입니다. Agent Skills가 조직 간에 옮겨 다닐 수 있어도 보안 검토는 사라지지 않습니다. Minerva가 장애 원인을 제안해도 실제 수정 권한은 따로 정해야 합니다. 전 직원에게 AI 계정을 줬다는 발표 역시 전 직원이 같은 성과를 냈다는 뜻은 아닙니다.

1. OpenAI Decisions API: 에이전트의 작은 판단을 구조화한다

OpenAI는 10월 22일 Decisions API를 정식 제공한다고 발표했습니다. 공식 설명에 따르면 GPT-6 Luna를 바탕으로 하며, 개발자가 질문과 허용되는 답을 정의하면 텍스트·이미지·구조화된 입력을 보고 제한된 형태의 결과를 돌려줍니다. 공개 베타 이후 GPT-Live 연동, 반복 맥락을 위한 프롬프트 캐싱, 미국·유럽 추론 지역 설정 등이 추가됐습니다. OpenAI 공식 발표

핵심 사실: 답을 길게 쓰는 대신 선택·확률·점수를 반환

공식 문서가 제시한 결과 유형은 세 가지입니다. predicate는 조건이 참일 가능성을 0에서 1 사이의 확률로 추정합니다. choice는 개발자가 미리 준 보기 중 하나를 고르고 각 보기의 확률과 신뢰 정보를 포함합니다. score는 순서가 있는 평가 단계에 입력을 놓습니다. 예를 들어 문의를 어느 팀에 전달할지, 에이전트가 계속 진행할지 다시 시도할지, 이미지의 손상 정도를 어떤 단계로 평가할지 같은 일에 맞습니다.

이 차이는 사소해 보이지만 운영에서는 큽니다. 상담 문의 한 건에 자유 형식의 긴 답을 요청하면 다음 프로그램이 다시 문장을 해석해야 합니다. 선택지가 정해져 있으면 후속 시스템이 결과를 받아 처리하기 쉽습니다. 다만 구조화된 결과가 곧 정확한 결과는 아닙니다. 보기의 정의가 모호하거나 입력 자료가 부족하면 그럴듯한 숫자와 선택지라도 잘못된 결정으로 이어질 수 있습니다.

OpenAI는 Responses API에서 GPT-6 Luna를 쓰는 방식과 비교해 최대 10배 빠른 작은 결정을 제시합니다. 이는 공급자의 비교 조건에 따른 주장입니다. 우리 회사의 한국어 문서, 실제 응답 시간, 재시도, 네트워크 구간까지 포함한 속도를 보장하지 않습니다. 비용도 공식 페이지의 현재 가격을 고정 예산으로 옮기기보다 사용 전 가격표와 처리 지역 조건을 다시 확인해야 합니다.

왜 중요한가: 자동화할 결정을 먼저 정의하게 만든다

많은 팀은 “AI가 알아서 분류해 줘”라는 요구로 시작합니다. 하지만 좋은 분류에는 먼저 사람이 정한 기준이 필요합니다. 고객 불만을 긴급으로 보는 기준, 환불 요청을 사람에게 넘기는 조건, 문서의 어떤 항목이 빠지면 접수를 멈추는지부터 써야 합니다. Decisions API처럼 답의 형태를 제한하는 도구는 이런 기준을 제품 설계의 앞쪽으로 끌어옵니다.

윤자동의 해석은 이렇습니다. 작은 결정을 잘 정의하면 모델을 바꾸거나 연결 시스템을 바꿀 때도 비교 기준이 남습니다. 반대로 “승인”이나 “지급”처럼 되돌리기 어려운 행동을 모델의 선택 하나에 바로 연결하면 위험합니다. 확률은 판단을 돕는 신호이지 조직의 승인 서명은 아닙니다. 사람이 검토해야 할 사례를 안전하게 골라내는 용도로 먼저 시험하는 편이 현실적입니다.

기업 실무 적용: 한 가지 분류부터 시험한다

예를 들어 사내 문의함에서 “일반 안내”, “담당자 확인”, “긴급 장애” 세 가지로만 나누는 실험을 해볼 수 있습니다. 먼저 과거 문의 중 개인정보를 제거한 사례를 모아 사람이 붙인 정답과 판단 근거를 적습니다. 세 선택지를 서로 겹치지 않게 설명하고, 모호한 사례에는 담당자 확인이라는 출구를 둡니다. 모델 결과가 기존 담당자의 판단과 어디서 다른지 살피고, 그 차이를 오류 유형별로 정리합니다.

운영에 연결할 때는 분류 결과와 원문, 적용된 규칙 버전, 사람이 최종 수정한 결과를 함께 남겨야 합니다. 낮은 확신 사례가 줄었다고 무조건 좋은 것은 아닙니다. 어려운 사례를 자신 있게 잘못 분류할 수도 있기 때문입니다. 처리 시간을 보는 시험과 함께, 잘못된 라우팅이 고객에게 어떤 영향을 주는지도 점검하십시오. 음성 서비스의 GPT-Live 연동은 발표된 기능이지만 실제 상담 흐름에 쓰려면 통화 기록, 연결 권한, 사람 상담 전환을 따로 설계해야 합니다.

2. Anthropic Agent Skills: 업무 지침을 공유하는 표준의 운영 책임

Anthropic은 10월 22일 Agent Skills를 Agentic AI Foundation(AAIF)에 기증한다고 발표했습니다. AAIF는 Linux Foundation 산하입니다. Anthropic은 표준의 이름과 로고, GitHub 조직, agentskills.io 도메인을 함께 기증하며, 앞으로 버전 관리·제안 절차·스킬 작성 및 설치 보안 지침을 논의하겠다고 설명합니다. 공식 글은 여러 에이전트 제품이 이미 Agent Skills를 통합했다고 밝히지만, 개별 제품에서 같은 스킬이 같은 결과를 낸다는 보증은 아닙니다. Anthropic 공식 발표

핵심 사실: SKILL.md는 에이전트가 읽는 작업 설명서

공식 설명에서 스킬은 SKILL.md와 필요한 스크립트·참고 자료를 담은 폴더입니다. 특정 업무를 할 때 어떤 순서로 확인하고 어떤 도구를 써야 하는지 알려줍니다. 이는 모델의 일반 지식과 다릅니다. 예를 들어 회사의 견적서 작성법, 숫자 검수 방식, 고객 자료 보관 위치는 외부 모델이 스스로 알 수 없습니다. 조직이 이를 문서로 정리해야 에이전트도 같은 절차를 반복할 수 있습니다.

표준을 재단에 맡기는 조치는 이 형식을 한 기업의 제품 기능으로만 다루지 않겠다는 방향을 보여줍니다. 여러 회사의 엔지니어가 개인 자격으로 유지 관리에 참여한다는 설명도 나왔습니다. 다만 “중립적 관리”는 앞으로의 거버넌스 방식에 관한 발표입니다. 버전 정책과 보안 지침은 로드맵의 제안 단계이므로, 아직 완성된 통제 체계처럼 받아들이면 안 됩니다.

왜 중요한가: 모델보다 업무 절차가 더 오래 남는다

기업은 AI 도구를 바꿔도 업무의 승인선, 자료의 위치, 고객에게 쓰는 표현을 유지해야 합니다. 절차가 사람의 머릿속이나 특정 대화창에만 있으면 다른 직원과 도구가 같은 품질을 내기 어렵습니다. 스킬 파일이 표준화되면 업무 지침을 읽고 수정하며 이력을 관리할 출발점이 생깁니다. 여기서 표준화의 장점은 ‘한 번 쓰면 어느 도구에서나 무조건 똑같이 작동한다’가 아닙니다. 다른 실행 환경에서도 같은 지침을 이해할 기회를 넓힌다는 의미에 가깝습니다.

윤자동의 실무 해석으로는, 스킬을 만드는 일보다 누가 고칠 수 있는지가 더 중요합니다. 파일 한 줄이 “고객 메일 발송 전 승인 확인”을 “바로 발송”으로 바꾸면 자동화의 위험도가 달라집니다. 외부에서 내려받은 스킬은 친절한 설명서처럼 보여도 실제로는 에이전트가 실행할 명령이나 참고 링크를 포함할 수 있습니다. 설치 전에 출처, 버전, 접근 권한, 외부 통신, 변경 이력을 검토하는 이유입니다.

기업 실무 적용: 스킬 파일에 최소한의 운영 정보를 붙인다

처음부터 모든 사내 업무를 스킬로 만들 필요는 없습니다. 반복되고 규칙이 분명한 업무 하나를 고르십시오. 예를 들어 주간 보고 초안이라면 입력 자료의 범위, 숫자 원천, 출력 형식, 검수 담당자, 발행 전 승인 조건을 적습니다. 새 직원에게 설명해도 헷갈리는 문장은 에이전트에게도 헷갈립니다. 실제 사례 두세 개로 지침을 실행해 보고 빠진 예외를 보완합니다.

공용 스킬에는 소유자와 마지막 검토일을 기록하고, 변경은 검토 가능한 저장소에서 다루는 편이 좋습니다. 비밀번호와 API 키를 지침 파일에 직접 넣지 말고 권한을 별도로 연결해야 합니다. 스킬이 모델에게 작업을 설명한다는 사실과 모델에 자료 접근 권한을 부여한다는 사실은 구분해야 합니다. 표준을 도입해도 고객 자료의 사용 동의와 사내 권한 설정은 조직이 책임집니다.

3. NVIDIA Minerva: AI 시스템의 장애를 작업 맥락에서 본다

NVIDIA는 10월 22일 Minerva를 AI 팩토리 운영을 위한 AIOps 플랫폼으로 소개했습니다. GPU, 네트워크, 저장장치, 작업 스케줄러와 실행 중인 작업의 운영 신호를 연결해 이상 징후를 찾고 관련 사건을 묶는다는 설명입니다. 자연어로 상태를 조사하고 수정 방안을 추천하는 AI 보조 기능도 소개했습니다. NVIDIA는 일부 파트너의 사용을 언급하고 다른 기업의 향후 배포 계획을 적었으므로, 이름이 나온 모든 기업이 이미 같은 규모로 운영 중이라고 해석하면 안 됩니다. NVIDIA 공식 발표

핵심 사실: 장비 경고와 실제 작업 지연을 연결

전통적인 감시 화면은 네트워크 팀, 서버 팀, 모델 운영 팀이 각각 다른 신호를 볼 수 있습니다. Minerva는 장비 구성과 실행 중인 작업의 관계를 동적인 지식 그래프로 묶어 느린 학습 작업이 어떤 구성 요소의 문제와 관련 있는지 추적하려고 합니다. 여러 경고를 하나의 사건으로 묶고 가능한 원인을 제안하는 기능도 발표했습니다. NVIDIA가 말하는 “예측”과 “선제 대응”은 제품 설계와 공급자의 설명입니다. 모든 장애가 사전에 발견된다는 약속으로 읽어서는 안 됩니다.

AI 인프라를 직접 운영하지 않는 기업에는 먼 이야기처럼 보일 수 있습니다. 하지만 원리는 일반 업무 자동화에도 적용됩니다. 상담 챗봇의 응답이 느려졌을 때 모델만 의심하면 원인을 놓칩니다. 검색 인덱스 갱신, 연결 문서 권한, 외부 API 지연, 사용량 제한 중 어디에서 막혔는지 함께 봐야 합니다. 좋은 관측은 경고 건수를 늘리는 것이 아니라 업무에 영향을 주는 원인을 빨리 좁히는 일입니다.

왜 중요한가: AI 운영의 성과는 사용 가능한 시간으로 드러난다

NVIDIA는 인프라가 만든 유효 작업량을 GPU 시간, 작업 처리 효율, 클러스터 가동 시간, 토큰 생산 등으로 설명합니다. 이 수치는 장비 운영 기업의 지표입니다. 일반 기업이 그대로 KPI로 가져올 필요는 없습니다. 고객 상담이라면 질문을 해결한 비율과 사람에게 적절히 넘긴 비율, 문서 처리라면 재검토가 필요한 건수와 처리 지연을 볼 수 있습니다. 무엇을 관측할지는 AI를 도입한 업무 목적에 따라 달라집니다.

제가 특히 주의해서 보는 부분은 자동 복구의 경계입니다. 장애 원인을 제안하는 기능과 인프라 설정을 실제로 바꾸는 권한은 다릅니다. 발표는 사람이 직접 수정할 수도, 외부 시스템과 연결해 자동화할 수도 있다고 설명합니다. 기업은 먼저 읽기 전용 상태 조사와 수정 제안을 운영한 뒤, 변경 명령의 승인자·되돌리기 절차·작업 기록을 정해야 합니다. 진단이 틀렸을 때 피해가 어디까지 퍼지는지도 시험해야 합니다.

기업 실무 적용: 알림 하나를 끝까지 추적한다

운영 팀은 최근 발생한 장애 한 건을 골라 보십시오. 첫 증상이 무엇이었고 어느 화면에 나타났는지, 누가 언제 알아챘고 어떤 자료를 보고 원인을 찾았는지 시간순으로 적습니다. 경고는 많았는데 담당자가 일을 시작할 수 없었다면, 경고 자체보다 맥락 연결이 부족한 것입니다. 반대로 원인을 빠르게 알았지만 권한 때문에 조치가 지연됐다면 기술 문제가 아니라 승인 흐름의 문제일 수 있습니다.

새 AIOps 도구를 검토할 때도 공급자 데모의 복구 시간을 그대로 예상하지 마십시오. 우리 장비와 작업 로그를 연결할 수 있는지, 데이터가 어디에 저장되는지, 접근 권한을 세분화할 수 있는지, 오탐을 현업이 어떻게 정정하는지 확인해야 합니다. 외부 서비스만 쓰는 팀이라면 우선 서비스별 상태 페이지와 내부 장애 기록을 연결하는 작은 운영표부터 만들어도 도움이 됩니다.

4. Uber의 ChatGPT Work 확대: 계정 수보다 교육과 통제가 먼저다

OpenAI는 10월 22일 Uber가 ChatGPT Work를 전사적으로 확대 도입한다고 발표했습니다. 공식 글은 직원 1,000명을 대상으로 한 초기 시범 운영을 넘어 전 세계 직원 3만 명 이상이 이용할 수 있게 된다고 설명합니다. ChatGPT Work는 ChatGPT Enterprise 안에서 다단계 업무를 돕는 에이전트로 소개됐고, Uber는 사내 AI 스킬 라이브러리, 승인된 연동 기능, 직원 교육을 도입 지원책으로 제시했습니다. OpenAI 공식 발표

핵심 사실: 발표된 것은 확대 계획과 이용 범위

“3만 명 이상”은 공식 발표가 말하는 이용 대상 규모입니다. 모두가 이미 사용하고 있거나 생산성이 특정 비율만큼 올랐다는 뜻이 아닙니다. OpenAI는 운영, 재무, 마케팅, 제품 부서의 활용을 기대한다고 적었고, 실제 사용 현황과 측정 가능한 성과는 도입이 진행되면서 추가로 공유할 계획이라고 밝혔습니다. 현재 공개 자료에서 성과 수치를 만들거나 타사에 같은 효과를 약속할 수는 없습니다.

이 발표를 읽을 때는 계정 제공과 업무 정착을 분리해야 합니다. 구성원에게 도구를 열어 주는 것은 첫 단계입니다. 어떤 자료를 넣어도 되는지, 어떤 연동이 승인됐는지, 산출물을 누가 확인할지 알아야 실제 업무에 사용합니다. 스킬 라이브러리와 교육을 함께 언급한 대목이 그래서 눈에 띕니다. 직원이 각자 다른 프롬프트를 쓰더라도 조직이 허용하는 일의 범위는 공통으로 설명할 수 있습니다.

왜 중요한가: 전사 도입의 성패를 로그인 수로 볼 수 없다

AI 서비스 도입 보고서에는 종종 계정 수와 접속 횟수가 먼저 나옵니다. 이 숫자는 배포가 됐는지는 보여 주지만 고객 답변의 정확성, 자료 유출 위험, 업무 재작업이 줄었는지는 설명하지 못합니다. 윤자동의 해석으로는, 업무 단위를 정해 도입 전후를 비교하는 편이 낫습니다. 예컨대 회의 요약 초안의 작성 시간만 보지 말고 누락된 결정 사항, 잘못 적힌 담당자, 검수에 걸린 시간까지 함께 봐야 합니다.

대규모 조직의 발표를 작은 회사가 그대로 따라 할 필요는 없습니다. 오히려 소규모 팀은 업무 하나를 바꾸는 실험을 더 빠르게 할 수 있습니다. 부서별로 같은 도구를 배포하기 전에 하나의 문서 처리 또는 문의 응대 흐름을 고르고, 접근 자료와 승인선을 정한 뒤, 실제 담당자의 피드백을 받으십시오. 사용자가 불편해하는 지점이 모델 성능인지 자료 정리인지 권한 설정인지 구분해야 다음 투자가 보입니다.

기업 실무 적용: 시범 운영의 종료 조건을 먼저 정한다

시범 운영을 시작하기 전에 “언제 확대할지”를 글로 남겨 두십시오. 업무 담당자가 결과를 이해하고 고칠 수 있는가, 금지 자료가 입력되지 않았는가, 실패했을 때 원래 방식으로 돌아갈 수 있는가, 책임자가 지정됐는가가 최소 조건입니다. 교육은 사용법만 알려 주는 시간이 아닙니다. 정확하지 않은 결과를 발견했을 때 신고하는 방법과 사람이 승인해야 하는 행동을 함께 익혀야 합니다.

연동 기능은 특히 단계적으로 여는 편이 좋습니다. 읽기 전용 검색과 외부 발송·수정은 위험도가 다릅니다. “AI가 일을 끝냈다”는 표현을 쓸 때도 초안을 만들었는지, 시스템을 수정했는지, 고객에게 보냈는지 명확히 구분하십시오. Uber 사례에서 확인되는 것은 큰 규모의 배포 방향과 지원 체계입니다. 우리 조직에 맞는 성과와 비용은 별도 시험으로 판단해야 합니다.

네 발표를 함께 보면: 결정, 지침, 관측, 조직 운영

Decisions API는 에이전트가 내리는 작은 판단의 형식을 다룹니다. Agent Skills는 일을 수행하는 절차와 참고 자료의 형식을 다룹니다. Minerva는 실행 중 생기는 운영 신호와 장애의 연결을 보여 줍니다. Uber 사례는 기술을 직원의 일상 업무에 넣을 때 필요한 교육과 승인된 연결을 드러냅니다. 각 제품이 서로 바로 호환된다는 뜻은 아닙니다. 서로 다른 발표에서 공통으로 보이는 운영 질문을 묶은 윤자동의 해석입니다.

AI 프로젝트를 시작할 때 네 층을 따로 적어 보면 도움이 됩니다. 첫째, 어떤 판단을 자동화할지와 예외를 정의합니다. 둘째, 작업 절차를 사람이 검토할 수 있는 문서로 남깁니다. 셋째, 시스템이 무엇을 읽고 실행했는지 기록합니다. 넷째, 누가 바꿀 수 있고 누가 결과를 승인하는지 정합니다. 모델 이름만 바꾸어도 이 네 층이 정리되지 않으면 같은 문제가 반복될 수 있습니다.

이번 주 기업 실무 실행 체크리스트

1. 반복 결정 하나 고르기: 문의 분류나 자료 누락 확인처럼 결과 유형을 세 가지 안팎으로 정의할 수 있는 일을 찾습니다.
2. 사람이 정답을 붙인 사례 만들기: 성공 사례뿐 아니라 애매한 사례와 잘못 분류하면 피해가 큰 사례를 포함합니다.
3. 업무 지침의 소유자 정하기: 스킬이나 프롬프트 파일의 수정 권한, 마지막 검토일, 승인 절차를 기록합니다.
4. 읽기와 실행 권한 나누기: 자료 검색, 초안 작성, 실제 변경·발송을 서로 다른 단계로 취급합니다.
5. 운영 신호 연결하기: 오류 알림이 어느 업무와 고객에게 영향을 주는지 추적할 수 있게 기록합니다.
6. 도입 성과 다시 정의하기: 계정 수와 접속 횟수 외에 정확성, 재작업, 사람 검토 시간, 사고 대응 시간을 봅니다.
7. 제공 상태 확인하기: 발표된 기능의 사용 가능 지역, 계약·요금, 데이터 처리 조건은 도입 직전에 공식 문서에서 다시 확인합니다.

FAQ

Q1. Decisions API가 사람이 하던 승인까지 대신할 수 있나요?

정해진 보기에서 결과를 고르는 기술과 회사의 승인 권한은 다릅니다. 분류·라우팅처럼 되돌릴 수 있는 작업부터 시험하고, 지급·삭제·외부 발송처럼 영향이 큰 행동은 별도 권한과 사람 검토를 두는 편이 안전합니다.

Q2. Agent Skills를 쓰면 도구를 바꿔도 그대로 실행되나요?

표준 형식은 지침을 옮기기 쉽게 하지만, 각 제품의 지원 범위와 도구 연결, 파일 접근 권한은 다릅니다. 같은 스킬이라도 새 실행 환경에서 테스트하고 설치 출처를 확인해야 합니다. Anthropic 발표의 향후 보안 지침은 제안 단계입니다.

Q3. Minerva는 일반 사무실에서도 필요한가요?

Minerva는 AI 팩토리 운영을 대상으로 한 제품입니다. 자체 GPU 인프라가 없다면 바로 도입할 이유는 약합니다. 다만 “인프라 경고가 어떤 업무 지연으로 이어졌는지 연결한다”는 원칙은 일반 기업의 AI 서비스 운영에도 쓸 수 있습니다.

Q4. Uber 사례에서 확인된 성과는 무엇인가요?

공개된 것은 직원 1,000명의 시범 운영 이후 3만 명 넘는 직원으로 확대한다는 발표와 교육·스킬·승인된 연동 계획입니다. 전사 생산성 향상 수치가 공개됐다고 해석하면 안 됩니다. OpenAI는 이용 현황과 측정 가능한 성과를 추후 공유할 계획이라고 했습니다.

Q5. 오늘 발표 중 우리 회사가 가장 먼저 시험할 것은 무엇인가요?

제품을 고르기 전에 반복되는 결정 한 가지를 명확히 적어 보십시오. 허용되는 결과, 사람이 확인할 예외, 입력 자료의 권한, 실패 시 되돌리는 방법이 정리되면 어떤 제품이 필요한지도 판단하기 쉬워집니다.

공식 출처

• OpenAI, Build more responsive apps with the Decisions API — 공식 페이지 표시일 2026-10-22.
• Anthropic, Donating Agent Skills to the Agentic AI Foundation — 공식 페이지 표시일 2026-10-22.
• NVIDIA, NVIDIA Unveils Minerva to Bring End-to-End Observability for AI Factories — 공식 페이지 표시일 2026-10-22.
• OpenAI, Uber brings ChatGPT Work to all employees with OpenAI — 공식 페이지 표시일 2026-10-22.

기준: 2026년 10월 23일 09시, Asia/Seoul. 각 기업의 발표 내용과 제공 상태는 이후 바뀔 수 있습니다.