오늘의 AI Daily News

발행 기준과 읽는 법

이 글은 2026년 10월 28일 오전 11시 30분 KST까지 공개된 공식 자료를 기준으로 한다. 웹 검색 API에는 키가 없어 검색 결과를 얻지 못했다. 대신 OpenAI 뉴스 목록과 발표 원문, 연결된 OpenAI·Oracle 파트너 소개와 기존 고객 사례를 직접 확인했다. Google AI·개발자 블로그, GitHub 제품 뉴스, AWS 기계학습 블로그, Microsoft AI 블로그의 공식 목록도 확인했다. 이들 목록은 이번 호에서 최근 발표의 날짜와 본문을 함께 확실하게 검증할 만한 추가 주제를 제공하지 않았으므로, 확인되지 않은 ‘오늘의 업계 소식’을 채우지 않았다. 이번 호의 새 발표는 10월 27일자로 게시된 OpenAI·Oracle 협력 확대다. 10월 22일의 Decisions API와 10월 23일의 Habitat 기술 글은 새 뉴스로 포장하지 않고 아키텍처를 이해하는 배경으로만 사용한다.

오늘의 핵심은 ‘ChatGPT에서 Oracle을 쓸 수 있다’라는 짧은 제품 문구보다 넓다. 기업용 AI가 실제 업무 시스템에 들어가려면 자연어 질문을 데이터 조회로 바꾸고, 조회 결과를 정책에 맞는 작업으로 연결하며, 그 작업이 누구의 승인 아래 실행됐는지 기록해야 한다. OpenAI는 Oracle AI Workspace, AI Security Mesh, AI SMB Bundle, App Composer, Oracle Marketplace 경로를 한 발표에서 소개한다. 그러나 각 항목의 성격은 다르다. 일부는 개발·제공을 목표로 설명한 제품이고, Marketplace 구매 경로처럼 지역과 조달 조건이 제시된 항목도 있다. 비전, 발표, 구매 가능성, 특정 고객의 도입, 일반 고객의 실제 사용 가능성을 같은 단계로 보지 않아야 한다.

특히 ‘에이전트가 핵심 업무를 완료한다’는 말에는 기존 애플리케이션의 권한보다 더 정교한 통제가 필요하다. 자연어 인터페이스가 재무·구매·계획 자료를 하나의 대화에 모으는 일은 편리하지만, 데이터가 보이는 범위와 변경 가능한 범위를 혼합하기 쉽다. 승인받은 업무만 실행하는지, 권한이 연결되는 경로마다 유지되는지, 실패했을 때 중복 집행이 일어나지 않는지, 사후에 판단을 재구성할 수 있는지가 제품의 품질을 가른다. 이 글은 발표 사실을 먼저 분리한 뒤 개발·운영팀이 적용할 수 있는 검증 절차를 제시한다.

Top News — 공식 자료로 확인한 사실

1. OpenAI는 Oracle과 협력을 확대해 Oracle 애플리케이션과 데이터를 ChatGPT로 연결하고, Oracle 제품·서비스에도 OpenAI 모델과 도구를 활용한다고 10월 27일 발표했다. Oracle AI Workspace는 Oracle 업무 앱과 데이터에 연결해 정보 탐색과 승인된 워크플로를 한곳에서 수행하는 경험을 지향한다. 새 재무 담당자가 비용과 구매 결정을 조사하고 월말 마감의 남은 일을 확인하는 예시가 소개됐다. 이는 제시된 사용 사례이지 모든 조직에 이미 제공되는 기능 목록이나 가용성 보증이 아니다. 발표 원문
2. 발표는 네 가지 제품·서비스 경로를 나눠 설명한다. AI Security Mesh는 OpenAI의 사이버 모델로 애플리케이션·인프라의 취약점을 찾고 수정하는 관리형 서비스를, AI SMB Bundle은 ChatGPT Business·Codex·Oracle 애플리케이션과 반복 제공되는 OCI 크레딧의 묶음을, App Composer는 Codex 등의 AI 도구로 앱을 만들고 승인된 Oracle 데이터·업무 흐름에 연결해 OCI에서 배포하는 구성을 가리킨다. 각 제품의 구체적인 기능, 출시 시점, 계약 조건은 조직별 확인이 필요하다. 발표 · 파트너 소개
3. 미국 Oracle 고객은 Oracle Marketplace를 통해 OpenAI API·Codex·ChatGPT Work 접근권을 구매할 수 있다고 발표는 적는다. 적격 Oracle Universal Credits와 기존 구매 절차를 사용할 수 있다는 설명도 있다. 이 경로는 미국 지역을 명시한다. Marketplace에서 구매하는 것과 모델 추론이 어느 클라우드·리전에 처리되는지, 데이터 보존 조건이 무엇인지는 같은 질문이 아니다. 10월 27일 발표 · Marketplace 경로 설명
4. Oracle 내부 사용 규모와 생산성 사례는 고객 사례로 읽어야 한다. OpenAI 발표는 Oracle이 활동 중인 ChatGPT 사용자 13만 명, Codex 사용자 9만 5천 명 이상을 보고했다고 전한다. 채용팀의 시장조사 준비는 과거 2~4일 걸리던 작업을 15~20분 준비로 바꾼 사례를 든다. 이것은 외부 고객의 평균 절감률이나 독립 실험의 결과가 아니다. 수치의 모집단, 중복 사용 여부, 업무 범위, 품질 검증 비용이 공개돼 있지 않다. 발표 · Oracle 고객 사례
5. 기존 발표 두 건은 오늘의 설계 맥락을 준다. 10월 22일 일반 제공이 발표된 Decisions API는 제한된 답을 갖는 분류·선택·점수 결정을 빠르게 수행하도록 설계됐다. 10월 23일 Habitat 저장소 기술 글은 초대형 다중 테넌트 시스템에서 ‘노이즈가 많은 이웃’, 핫 키, 우선순위, 장애 격리를 어떻게 다루는지 설명한다. Oracle 협력의 직접 구성 요소라고 발표된 것은 아니지만, 에이전트의 의사결정과 업무 데이터 저장 경계를 설계할 때 대비되는 엔지니어링 사례다. Decisions API · Habitat Part II

배경: 기업용 AI의 병목이 모델에서 ‘업무 경계’로 이동한다

생성형 AI의 초기 도입은 문서 요약, 초안 작성, 코딩 보조처럼 결과물을 사람이 복사해 사용하거나 검토하는 방식이 많았다. 이때 중요한 성능은 답변 품질과 응답 속도였다. 업무 앱 연결이 늘면 모델의 답변이 곧 ERP의 구매 요청, 재무 마감의 확인 절차, 직원 데이터 조회, 보안 점검 지시 같은 상태 변경을 촉발할 수 있다. 자연어가 편해질수록 사용자가 자신이 어느 시스템에 어떤 권한으로 들어가 있는지 느끼기 어려워진다. 모델이 유창한 설명을 하더라도 그 권한이 없으면 해당 작업은 실행돼서는 안 된다.

Oracle AI Workspace가 제시하는 방향은 특정 화면의 ‘챗봇’보다 상위의 업무 진입점이다. 사용자는 여러 애플리케이션의 메뉴 구조를 기억하는 대신 원하는 결과를 말한다. AI는 필요한 앱과 자료를 찾고 연결한다. 이때 데이터 원본은 하나가 아니다. 비용, 구매, 계획 시스템은 업데이트 주기와 회계 기준, 접근 권한, 승인 단계가 서로 다르다. ‘월말 마감에서 무엇이 남았는가’라는 질문은 단순 검색이 아니라 서로 다른 시스템의 최신 상태를 맞춰 해석하는 작업이다. 잘못된 시점의 자료를 합치거나 아직 승인되지 않은 구매 건을 완료로 표시하면 답변이 문법적으로 완벽해도 업무적으로 틀리다.

오늘 발표가 중요한 이유는 기능 수의 증가만이 아니다. AI 플랫폼이 고객의 기존 업무 애플리케이션과 구매 경로에 들어가는 방식을 함께 보여 준다. API만 제공하는 것보다 고객 조직의 신원, 권한, 승인, 배포, 계약을 통과시키는 데 많은 조율이 필요하다. Oracle이 관리하는 배포 및 테스트 인프라, 기존 OCI 크레딧을 통한 구매, ChatGPT의 업무 인터페이스는 서로 다른 병목을 겨냥한다. 사용자는 모델 하나가 아니라 사용 가능한 경로 전체를 선택하게 된다.

그러나 발표만으로 ‘원클릭 자동화’가 완성됐다고 볼 수 없다. 제품별로 준비 상태와 지역, 데이터 연결 방식, 역할별 권한, 감사 로그, 장애 시 처리 방식이 다를 수 있다. 실제 구현은 테넌트 설정과 계약 조건에 의존한다. 발표 자료가 말하지 않는 사항은 빈칸으로 남겨야 한다. 특히 타사 앱과 모델 제공자를 거치는 데이터 흐름은 어느 사업자가 어떤 목적·기간·지역에서 정보를 처리하는지 계약과 기술 설정으로 확인해야 한다.

오늘의 분석은 네 개의 층으로 나뉜다. 첫째, Oracle 앱을 ChatGPT에서 다루는 사용자 경험과 권한 구조다. 둘째, App Composer와 Codex가 만드는 개발·배포 생명주기다. 셋째, Security Mesh의 보안 검사 범위와 안전한 검증 절차다. 넷째, Marketplace와 SMB Bundle의 조달·비용·운영 구조다. 네 층을 하나의 ‘파트너십’이라는 단어로만 부르면 도입 결정에 필요한 질문이 빠진다.

1. Oracle AI Workspace — 대화형 진입점은 권한 시스템의 앞단이다

발표가 설명한 사용자 흐름

OpenAI는 Oracle AI Workspace가 Oracle 애플리케이션과 데이터를 ChatGPT로 가져오는 구성을 개발 중이라고 썼다. 사용자는 수행하려는 일을 설명하고, 필요한 정보를 찾고, 승인된 업무 흐름을 한 곳에서 완료할 수 있다는 비전이다. 신입 재무 담당자의 비용 조사·구매 결정 파악·월말 마감 준비는 이해하기 쉬운 예시다. 하지만 예시는 계약상 제공 범위, 사전 구성 없이 가능한 기능, 특정 국가의 규제 적용 여부를 설명하지 않는다. ‘개발 중’과 ‘모든 고객이 현재 사용 가능’은 다르다. 먼저 파트너 발표와 제품 데모가 어느 단계인지 확인해야 한다.

이 흐름을 시스템 관점에서 펼치면 사용자 인증 → 업무 의도 해석 → 접근 가능한 앱·데이터 탐색 → 조회 계획 → 근거와 결과 제시 → 변경 작업 제안 → 승인 → 실행 → 사후 기록이라는 순서다. 실무에는 각 단계에서 다른 실패가 생긴다. 로그인은 성공했지만 연결 앱의 토큰이 만료될 수 있다. 사용자의 의도를 정확히 파악했지만 잘못된 회계 기간을 선택할 수 있다. 데이터는 맞지만 변경 권한이 없을 수 있다. 승인은 받았지만 실행 직전에 원본 상태가 변할 수 있다. 그래서 대화형 UI의 품질 평가는 ‘질문에 잘 답하는가’로 끝나지 않는다.

업무 앱 연결에는 읽기와 쓰기의 분리가 필요하다. 비용 현황을 보여 주는 권한과 지급 승인 권한은 다르다. 모델이 두 요청을 한 문장으로 받더라도 정책 엔진은 각각 평가해야 한다. ‘이번 달 예산을 확인하고 미승인 항목은 처리해 줘’라는 문장은 조회와 상태 변경을 동시에 요구한다. 조회에서 얻은 정보가 쓰기를 정당화하지 않는다. 승인 가능한 항목의 범위, 금액 제한, 두 사람 승인 규칙, 예외 처리 조건을 독립적인 업무 규칙으로 유지해야 한다.

신원과 권한을 연결할 때 생기는 질문

OpenAI는 조직의 권한과 승인, 간소화된 로그인, 관리 편의를 목표로 든다. 하지만 실제 구현에서는 사용자에게 보이는 ChatGPT 신원과 Oracle 앱의 역할이 어떻게 매핑되는지가 핵심이다. 한 사용자가 여러 법인·부서에 속할 수 있고, 직무와 프로젝트에 따라 접근 가능한 원가 센터가 다를 수 있다. 시스템 계정을 사용해 모든 데이터에 접속한 뒤 모델 프롬프트로 ‘이 사람은 여기까지 보세요’라고 제한하는 것은 권한 통제가 아니다. 데이터 소스 또는 중간 정책 계층에서 사용자 단위·행 단위·속성 단위 접근이 실제로 강제돼야 한다.

권한은 시간이 흐르며 바뀐다. 인사 이동으로 재무팀에서 다른 팀으로 옮긴 사용자는 어제의 대화 기록에 남아 있는 연결을 통해 다시 같은 데이터를 읽을 수 없어야 한다. 위임받은 결재 권한은 만료일이 있어야 하고, 퇴사자의 인증 토큰은 회수돼야 한다. 시스템이 지난주 권한을 캐시해 오늘의 업무를 실행하면 대화형 편의가 오히려 보안 사고의 경로가 된다. 따라서 권한 평가의 시점, 캐시 만료, 강제 회수, 세션 종료 후 토큰 처리, 기존 대화에서의 재사용 여부를 계약서가 아니라 실제 테스트로 검증해야 한다.

여러 시스템을 가로지르는 작업에서는 교차 권한이 특히 중요하다. 재무 앱에서 ‘구매 결정’을 볼 수 있어도 구매 앱의 담당자 메모까지 볼 권한은 없을 수 있다. 모델이 둘의 내용을 합쳐 요약하면 원본에서 따로 지켜지던 정보 경계가 무너진다. 조회 권한은 원본 시스템 기준의 최소 권한을 유지하고, 결합 결과에 추가 민감도가 생기는지 검토해야 한다. 예를 들어 공개 가능한 공급자명과 제한된 단가를 합친 보고서는 원래 어느 한 화면보다 더 민감할 수 있다.

검색 결과가 곧 업무 사실은 아니다

기업 데이터는 구조화돼 있어도 정의가 다양하다. ‘비용’에는 약정액, 발주액, 청구액, 지급액이 있고, ‘진행 중’에는 시스템별로 다른 상태가 있다. 월말 마감 전에 이 용어를 고정하지 않으면 동일한 질문에 앱마다 다른 숫자가 나온다. Oracle의 기존 고객 사례는 Applications Lab이 회사 객체·관계·규칙에 관한 온톨로지를 만들어 자연어 질문을 SQL 조회로 연결했다고 설명한다. 이 사례에서 중요한 것은 모델이 SQL을 작성할 수 있다는 사실보다 업무 개념을 명시하는 중간 의미 계층이 있었다는 점이다. 온톨로지가 부정확하거나 오래되면 자연어 인터페이스도 그 오류를 확대한다.

답변에는 숫자의 단위, 기준 시점, 원본 시스템, 필터, 접근 제한으로 제외된 범위를 함께 보여 주는 편이 좋다. 사용자에게 ‘총 비용 12억’만 보여 주면 그 금액이 어느 법인, 기간, 통화, 세금 포함 여부, 승인 상태를 뜻하는지 모른다. 대화형 화면은 설명을 길게 만들기 쉽지만 근거 필드를 빠뜨리기 쉽다. 재무 업무라면 사람이 기존 보고서와 대조할 수 있는 링크나 참조 ID도 제공해야 한다. 이것은 모델의 환각 방지를 넘어서 업무 감사 가능성을 위한 인터페이스 설계다.

‘정보를 찾았다’와 ‘업무를 완료했다’는 별도 상태다. 사용자가 월말 마감의 누락 문서를 찾는 것은 읽기 작업일 수 있다. 누락 건에 담당자를 지정하고 알림을 보내는 것은 쓰기 작업이다. 세금 코드나 회계 계정을 바꾸는 것은 더 높은 위험의 쓰기다. 작업 완료라는 표현을 쓰려면 어떤 앱에 어떤 레코드가 어떻게 바뀌었고, 어떤 승인자가 언제 승인했으며, 실패하거나 부분 완료된 것은 없는지 확인해야 한다. 대화 화면의 ‘완료했습니다’는 실제 거래 ID와 상태 조회에 의해 뒷받침돼야 한다.

개발자가 구현할 때의 기본 계약

첫 번째 계약은 도구 스키마다. 모델에 ‘구매 업무 수행’ 같은 넓은 도구 하나를 주기보다 get_purchase_order, list_pending_approvals, propose_change, approve_with_actor처럼 범위를 제한한다. 입력에는 법인, 대상 ID, 회계 기간, 예상 버전, 사유, 사용자 ID를 명시한다. 도구 응답은 자연어 문장만 반환하지 않고 상태 코드, 참조 ID, 기준 시점, 권한 오류, 중복 실행 여부를 구조화한다. 모델은 말을 바꿀 수 있지만 도구 계약은 테스트 가능해야 한다.

두 번째 계약은 승인 단계다. 승인 직전에 사용자에게 레코드와 변경 전·후 값, 영향 범위를 제시해야 한다. ‘예’ 한 번으로 여러 법인의 구매 승인과 지급 지시가 함께 실행되지 않도록 변경 묶음을 분리한다. 승인자의 권한은 클릭 시점에 다시 확인하고, 승인 내용의 해시나 요청 ID를 실행 요청과 결합한다. 화면에서 본 내용과 실제 API가 받은 내용이 다르면 승인은 무효다. 프롬프트에서 ‘승인받은 것으로 가정하라’는 문장을 추가하는 것은 승인 절차가 아니다.

세 번째 계약은 멱등성과 경쟁 상태다. 모델이나 네트워크가 재시도할 때 구매 요청이 두 번 생성돼서는 안 된다. 쓰기 도구는 멱등 키를 받고 동일한 요청이면 기존 결과를 돌려주는 편이 안전하다. 읽기 후 쓰기 사이에 원본 레코드가 바뀌었다면 버전 검사를 통해 새 확인을 요구한다. 여러 애플리케이션에 걸친 작업은 하나의 데이터베이스 트랜잭션으로 묶이지 않을 수 있으므로, 부분 실패를 보여 주고 보상 작업 또는 사람의 복구 절차를 정의해야 한다.

네 번째 계약은 관측 가능성이다. 사용자 요청, 모델이 선택한 도구, 정책 판단, 원본 앱의 응답, 승인, 실행 결과를 동일한 추적 ID로 묶는다. 보안 로그에는 비밀이나 민감한 원문을 무차별 저장하지 않되, 감사자가 어떤 권한으로 어떤 일이 일어났는지는 확인할 수 있어야 한다. 모델 설명과 실제 실행 로그가 충돌하면 로그의 시스템 기록을 기준으로 조사한다. 운영자가 재현하지 못하는 ‘에이전트가 알아서 했다’는 상태가 가장 위험하다.

최소 기능 파일럿의 범위

도입 초기에는 읽기 전용 질문 하나를 고른다. 예를 들어 특정 법인의 특정 월 비용과 미결 구매 건을 보여 주되, 승인이나 회계 마감은 하지 않는다. 업무 담당자가 정답이 있는 표본을 제공하고, 권한이 다른 사용자 계정 여러 개로 동일 질문을 시험한다. 정답률뿐 아니라 권한 밖 데이터가 노출되지 않는지, 원본 갱신 후 답변이 언제 바뀌는지, 근거 링크가 열리는지, 시스템 장애 때 오래된 값을 새 값처럼 말하지 않는지를 본다.

다음 단계에서 낮은 위험의 쓰기—담당자에게 검토 요청 초안을 만들기 등—를 별도 승인으로 시험한다. 비용 지급, 권한 부여, 법적 효력이 있는 결재는 마지막 단계다. 성공한 데모 하나가 모든 종류의 워크플로에 안전한 접근을 뜻하지 않는다. 파일럿의 범위와 미포함 항목을 명시하면 출시 후 기능이 늘 때마다 새 위험 검토를 요청할 수 있다.

2. Oracle App Composer와 Codex — ‘앱 생성’ 뒤의 소유권

발표가 말한 제품 구분

App Composer는 팀이 Codex와 다른 AI 도구로 애플리케이션을 만들고, 승인된 Oracle 데이터와 워크플로에 연결하고, 조직 안에서 공유하도록 설계됐다고 발표됐다. Oracle이 OCI 배포를 관리하고 회사의 권한·접근 제어를 내장한다는 설명이다. 이 문장은 분명한 방향을 보여 주지만, 생성 가능한 앱 유형, 지원 언어·프레임워크, 배포 승인 절차, 변경 관리의 구체적인 보장은 제시하지 않는다. 제품 담당자는 데모의 결과를 일반적인 운영 능력과 분리해 확인해야 한다.

AI가 만든 앱은 한 번의 프롬프트로 끝나지 않는다. 사용자 요구 → 데이터 모델 → 화면과 API → 권한 → 테스트 → 배포 → 변경 요청 → 보안 패치 → 소유자 교체까지 살아 있다. 코드를 빠르게 만드는 능력은 처음 두 단계의 시간을 줄일 수 있지만, 이후 단계가 약하면 조직 안에 유지보수되지 않는 작은 앱이 쌓인다. Oracle 고객 사례에서 Applications Lab 책임자도 Codex가 일을 더 많이 하더라도 기본 시스템 설계와 코드의 유지보수 책임은 사람이 진다고 설명한다. 이 지점이 App Composer의 가치를 평가하는 기준이어야 한다.

생성 앱이 접속하는 데이터의 경계

‘승인된 Oracle 데이터’라는 표현을 기술적 질문으로 바꾸면 세 가지다. 누가 어떤 테이블·뷰·API를 승인했는가. 실행 시 어떤 사용자 권한이 적용되는가. 앱이 가져온 데이터를 어디에 다시 저장하거나 전송할 수 있는가. 앱이 재무 데이터 조회 권한을 얻으면 그 앱을 쓰는 모든 사람이 동일 데이터를 볼 수 있는지, 각 사용자마다 원본 앱 권한이 다시 계산되는지 확인해야 한다. 생성 앱은 편의를 위해 공용 서비스 계정을 쓰기 쉽다. 이때 기존 원본 권한보다 넓은 권한을 앱 전체에 부여하면 ‘승인된 데이터 연결’이라도 잘못된 공개가 일어날 수 있다.

모델이 만든 SQL도 검토 대상이다. 조인 키가 맞지 않으면 숫자가 불어나고, 기간 필터가 누락되면 전년도 자료가 섞인다. 자연어 요구가 모호해도 생성된 SQL이 실행 가능하다는 사실은 업무적으로 올바르다는 뜻이 아니다. 읽기 전용 연결을 기본으로 하고, 데이터 카탈로그와 업무 용어 정의를 제공하며, 쿼리의 비용과 범위를 제한해야 한다. 특히 민감한 개인 정보나 급여 데이터가 있는 경우 접근 필드 제한과 출력 마스킹을 모델 설명이 아니라 데이터 계층에서 적용해야 한다.

배포가 관리된다는 말의 실무 의미

Oracle이 OCI 배포를 관리한다는 발표는 고객의 CI/CD와 운영 책임이 사라진다는 뜻이 아니다. 앱이 어느 계정과 리전에 배포되는지, 로그와 백업이 어디에 있는지, 장애를 누가 감지하고 복구하는지, 인프라 변경이 고객에게 어떻게 통지되는지 알아야 한다. 배포 버튼이 누르기 쉬워도 이전 버전으로 되돌릴 수 없다면 운영 위험이 높다. 생성 앱마다 소유 팀과 담당자, 운영 시간, 데이터 등급, 의존 서비스, 복구 목표를 등록해야 한다.

앱을 공유하는 과정도 별도 설계 대상이다. 한 팀 내부의 프로토타입은 설명 없이도 쓰일 수 있지만 다른 부서가 쓰면 입력값의 의미와 권한, 예외 상황을 문서화해야 한다. 생성형 도구가 다듬어진 UI를 만들었다고 해서 회계 처리 기준이나 데이터 계약이 명확해지는 것은 아니다. 승인된 템플릿, 코드 리뷰, 정적 검사, 의존성 업데이트, 접근성 검사, 사용자 피드백, 사용 종료 정책까지 앱 카탈로그에 포함해야 한다. 생성 속도와 통제 속도가 다르면 그림자 IT가 새로운 이름으로 되돌아온다.

개발자에게 필요한 검증 기준

App Composer를 평가할 때는 ‘10분 안에 앱이 만들어졌는가’보다 같은 앱을 3개월 뒤 안전하게 수정할 수 있는가를 본다. 생성 코드와 설정을 내보낼 수 있는지, 버전 관리가 가능한지, 자동 테스트를 실행할 수 있는지, 데이터 연결 정책이 코드와 별도로 저장되는지, 다른 팀이 소유권을 넘겨받을 수 있는지 확인한다. 모델이 생성한 코드의 라이선스·의존성·비밀 처리 방식도 검토한다. 앱의 핵심 업무 규칙이 프롬프트 안에만 있다면 나중에 어떤 버전의 모델이 왜 다른 결과를 냈는지 설명하기 어렵다.

테스트는 세 층으로 구성할 수 있다. 단위 테스트는 날짜·통화·승인 규칙 같은 순수 로직을 검증한다. 통합 테스트는 Oracle API 권한, 응답 구조, 오류 처리를 검증한다. 업무 승인 테스트는 실제 담당자가 다양한 예외 데이터를 넣고 결과가 맞는지 확인한다. AI로 생성한 코드는 테스트 코드도 생성할 수 있지만, 둘이 같은 잘못된 가정을 공유할 수 있으므로 정답 예시는 도메인 담당자가 제공해야 한다. 테스트 통과율보다 누락된 업무 규칙을 찾는 능력이 중요하다.

파일럿 과제 예시

재무팀의 ‘미결 구매 건 설명 대시보드’를 만든다고 가정하자. 처음에는 조회만 허용하고 승인 버튼은 넣지 않는다. 화면에는 법인·기간·통화·마지막 동기화 시각·원본 링크를 보인다. 권한이 다른 계정에서 동일 결과가 보이지 않는지 검증한다. 다음에는 ‘담당자에게 문의 초안 작성’ 기능을 넣되, 보낼 대상과 내용을 사람이 확인한 뒤 실행한다. 세 번째 단계에서만 업무 시스템의 상태 변경을 고려한다. 각 단계는 서로 다른 위험을 다루므로 하나의 종합 데모로 합치지 않는 편이 낫다.

성공 지표도 구체적이어야 한다. 기존 보고서 작성 시간, 숫자 일치율, 권한 오류 건수, 사용자 정정 횟수, 배포 이후 변경 요청 처리 시간, 장애 복구 시간, 앱 소유자의 교체 가능성을 측정한다. ‘앱 생성 시간’은 첫날의 지표일 뿐이다. 업무 앱은 오래 사용될수록 데이터 정의와 규칙이 바뀌므로 유지보수 지표가 장기적인 생산성을 결정한다.

3. Oracle AI Security Mesh — 취약점 탐지와 검증 권한을 분리한다

발표에서 확인되는 범위

OpenAI 발표는 AI Security Mesh를 OpenAI 사이버 모델을 활용해 애플리케이션과 인프라의 취약점을 찾고 수정하도록 돕는 Oracle 관리형 서비스로 소개한다. Oracle이 테스트 인프라를 관리하며 고객이 권한을 준 범위 안에서 안전하게 사용하도록 한다는 취지다. 파트너 소개 페이지는 고객이 테스트가 어디서 어떻게 실행되는지 통제한다고 설명한다. 그러나 구체적인 탐지 범위, 지원 환경, 검증 성공률, 오탐률, 자동 수정 범위, 고객별 출시 일정은 확인한 원문에 없다. 오늘의 보도는 기능 방향의 발표이며 정량적 보안 성능 평가가 아니다.

AI가 보안 문제를 찾는다는 말은 여러 종류의 활동을 포함한다. 정적 코드 분석, 설정 검토, 의존성 조사, 실제 서비스의 동작 테스트, 격리 환경에서의 공격 경로 재현, 수정 PR 제안은 각각 권한과 위험이 다르다. 도구가 어떤 단계를 수행하는지 확인해야 한다. ‘취약점 수정’이 자동으로 운영 서비스에 패치를 배포한다는 뜻이라고 가정하면 안 된다. 보안 문제는 탐지되더라도 원인 판단, 영향 범위 확인, 패치 검토, 배포, 사후 검증을 거쳐야 닫힌다.

권한 범위는 문장보다 실행 환경에서 강제돼야 한다

보안 테스트에는 평소보다 강한 접근이 필요할 수 있다. 소스 코드와 인프라 설정을 읽고, 테스트 환경의 API를 호출하고, 특정 입력이 위험한지 확인한다. 이 권한은 대상 자산, 시간, 테스트 종류, 네트워크, 계정별로 제한해야 한다. 조직 전체의 관리자 키 하나를 에이전트에게 주고 프롬프트에 ‘허가된 영역만 검사’라고 적는 방식은 충분하지 않다. 연결된 저장소와 클라우드 계정 목록, 대상 URL, 제외할 생산 서비스, 비밀 접근 범위, 호출량 한도를 실행 시스템에서 강제해야 한다.

생산 시스템 테스트 여부는 명확히 해야 한다. 발표는 Oracle이 테스트 인프라를 관리한다고 설명하지만 모든 고객·모든 검사가 격리된 환경에서만 이루어진다는 보증을 원문에서 읽을 수는 없다. 실제 계약과 설정을 통해 생산 자산을 건드리는지, 합성 데이터와 실제 데이터 중 무엇을 쓰는지, 장애를 유발할 수 있는 입력은 어떻게 차단하는지 확인해야 한다. 보안 에이전트가 취약점을 찾기 위해 대량 요청을 보낼 때도 서비스 가용성에 영향이 생길 수 있다. 속도 제한과 즉시 중단 경로가 있어야 한다.

발견의 증거 사슬

경고 한 건은 최소한 대상 자산, 취약한 동작, 관찰된 증거, 재현 환경, 필요한 전제 조건, 예상 영향, 확신의 한계로 구성한다. ‘AI가 위험하다고 판단했다’는 문장은 조치 우선순위를 정하기 어렵다. 샌드박스에서 재현에 성공했다면 재현 절차와 로그를 남겨야 한다. 재현에 실패해도 위험이 없다는 뜻은 아니다. 운영 환경의 설정이 다르거나 필요한 조건을 모델이 만들지 못했을 수 있다. 반대로 샌드박스에서만 가능한 결함을 운영의 긴급 사고로 오인하지 않아야 한다.

수정 제안은 더 엄격히 본다. 패치가 경고를 없애는 것과 실제 공격 경로를 막는 것은 다르다. 회귀 테스트는 수정 전 실패하고 수정 후 통과해야 한다. 인증·인가 문제라면 정상 사용자의 접근도 보존해야 한다. 의존성 버전 변경이라면 호환성과 데이터 마이그레이션을 고려한다. 보안 도구가 수정안을 만들 수 있더라도 사람은 배포된 버전과 사업 영향까지 확인해야 한다. 발표의 ‘찾고 수정한다’는 표현을 운영팀의 자동 병합 정책으로 그대로 옮겨서는 안 된다.

보안 파일럿의 좋은 분모

평가 데이터에는 과거에 실제로 수정한 취약점, 취약점이 없는 정상 변경, 다른 저장소의 공통 인증 라이브러리로 인한 문제, 배포 설정에서만 나타나는 문제를 함께 넣는다. 정답이 있는 소수의 유명 취약 사례만 넣으면 성능을 과대평가한다. 고유한 결함 단위의 탐지율, 오탐으로 인한 검토 시간, 심각도별 누락, 샌드박스 재현률, 수정안의 회귀 테스트 통과율, 실제 운영 반영까지 걸린 시간을 측정한다. 기존 정적 분석·의존성 검사·수동 리뷰가 켜진 상태와 비교해야 추가 가치가 보인다.

보안팀이 다룰 수 있는 경고량도 품질 지표다. 경고 100건 중 대부분이 오탐이면 고위험 경고가 묻힌다. 모델의 판단이 완전히 맞지 않아도 근거가 정확해 사람이 빨리 결론을 낼 수 있다면 가치가 있다. 반대로 잘 쓴 설명이 잘못된 코드 경로를 가리킨다면 신뢰를 떨어뜨린다. 실제 업무에서는 경고의 문장력보다 재현 가능한 근거와 처리 시간을 평가해야 한다.

발견 후 운영과 사고 대응

검사 도구가 취약점을 보고하면 누구에게 전달되는지 정해야 한다. 앱 소유자, 보안팀, 인프라팀, 제품 책임자가 서로 다를 수 있다. 긴급도는 모델의 점수만으로 정하지 않고 노출 여부, 대상 데이터, 악용 난이도, 배포 버전, 완화책을 결합한다. 패치가 병합돼도 아직 배포되지 않았으면 위험은 남는다. 배포 후에는 같은 입력으로 재검증하고, 경고가 단지 모델 버전 변경 때문에 사라진 것은 아닌지 확인한다. 사고 대응 과정에서는 모델의 입력·출력과 실제 도구 호출을 추적할 수 있어야 한다.

AI 보안 검사는 방어 시스템이면서 동시에 강한 접근권을 가진 새 구성요소다. 그 구성요소의 계정이 탈취되거나, 저장소 안의 악의적 문서가 검사 에이전트에게 지시처럼 해석되거나, 민감한 로그가 외부로 전송될 수 있다. 입력 콘텐츠는 업무 데이터로 취급하고 명령 권한을 주지 않아야 한다. 비밀은 가능한 한 주입하지 않고, 필요한 자격 증명은 짧은 수명과 최소 권한을 갖도록 한다. 보안 제품 자체의 운영 위험까지 포함해야 순효과를 평가할 수 있다.

4. AI SMB Bundle과 Oracle Marketplace — 제품의 접근 경로와 실행 경로는 다르다

SMB Bundle의 구조

발표에 따르면 AI SMB Bundle은 소규모 기업을 위해 ChatGPT Business와 Codex, Oracle 애플리케이션, 반복 제공되는 OCI 크레딧을 묶는다. 단일 구매와 도입 경로를 원하는 팀에는 매력적일 수 있다. 그러나 묶음의 실제 가치 판단에는 가격표뿐 아니라 사용자 수, 크레딧 사용 조건, 크레딧 만료, 초과 사용 과금, 각 제품의 관리 책임, 데이터 이전 비용을 봐야 한다. 공식 발표에서 모든 조건이 제시된 것은 아니다. ‘크레딧 포함’이라는 말이 모든 AI 추론 비용을 상쇄한다는 뜻은 아니다.

소규모 조직은 전담 보안·데이터 플랫폼팀이 없는 경우가 많다. 묶음으로 도구를 쉽게 쓰게 되는 것과 안전하게 운영할 수 있는 것은 다르다. 처음에는 직원용 초안·코드 보조와 읽기 전용 분석을 우선하고, 민감한 고객 데이터나 회계 상태 변경은 명확한 소유자와 승인 체계를 갖춘 뒤 연결해야 한다. 사업자들의 관리형 서비스가 일부 인프라 운영을 도와도 회사의 업무 정책과 고객에 대한 책임을 대신할 수는 없다.

Marketplace 경로의 정확한 의미

OpenAI는 미국 Oracle 고객이 Marketplace를 통해 OpenAI API, Codex, ChatGPT Work 접근권을 구매하고 적격 Oracle Universal Credits를 사용할 수 있다고 설명한다. 별도의 Marketplace 소개 글에는 이 경로가 미국에서 제공되며 추가 지역은 앞으로 예정이라고 적혀 있다. 따라서 한국 기업이 오늘 같은 방식으로 OCI 크레딧을 적용할 수 있다고 단정하면 안 된다. 지역·계약·크레딧 적격성은 구매 담당자와 공급자에게 확인해야 한다.

구매 경로와 서비스 처리 경로는 구별한다. Marketplace에서 청구된다는 사실만으로 모델이 고객의 OCI 테넌트 안에서 실행된다거나, 모든 입력 데이터가 Oracle 리전에만 머문다고 결론 내릴 수 없다. 데이터가 어느 서비스와 하위 처리자에 전달되는지, 저장·학습·로그 정책이 무엇인지, 기업용 계정과 API 계약이 어떻게 다를 수 있는지는 각 제품의 계약과 설정을 검토해야 한다. 클라우드 구매 약정이 있다고 해서 보안·개인정보·국외 이전 심사가 자동으로 끝나지 않는다.

총비용을 업무 단위로 계산하기

AI 도입의 총비용은 모델 단가와 다르다. 사용자가 질문하고 답을 검토하는 시간, 연결 앱 개발, 데이터 정리, 권한 설계, 감사 로그, 오류 복구, 보안 검토, 사용자 교육이 필요하다. Oracle 고객 사례의 채용 준비 시간 변화는 유용한 사례지만 모든 업무의 투자수익률 계산에 그대로 넣을 수 없다. 채용팀의 2~4일은 무엇을 포함한 기간인지, 15~20분은 어느 단계의 준비인지, 최종 채용 품질이나 법률 검토 시간은 어떻게 달라졌는지 알 수 없다. 사업 검토에는 자기 조직의 기준선을 먼저 측정해야 한다.

예를 들어 한 달에 100건의 재무 질의가 있고 기존 처리 시간이 건당 40분이라고 하자. 새 흐름이 답변 초안을 5분에 만든다 해도 담당자의 검토 10분, 잘못된 답의 수정 5분, 데이터 동기화 비용이 추가될 수 있다. 단순히 40분에서 5분으로 줄었다고 계산하면 도입 효과를 부풀린다. 반대로 찾기 힘든 자료를 빠르게 연결해 재작업을 크게 줄인다면 토큰 요금이 조금 높아도 전체 비용은 내려갈 수 있다. 업무별 완료율·검토 시간·재작업률·사고 비용을 같은 단위로 추적해야 한다.

공급자 결합과 이탈 비용

앱 생성, 데이터 연결, 모델 구매, 클라우드 크레딧을 한 묶음으로 쓰면 도입 마찰은 줄어든다. 동시에 모델과 데이터 연결 방식을 바꾸기 어려워질 수 있다. 도구 스키마, 업무 규칙, 감사 로그, 생성 앱 소스, 테스트 데이터를 표준적인 형식으로 내보낼 수 있는지 확인해야 한다. 이탈 계획이 반드시 다른 공급자로 즉시 옮긴다는 뜻은 아니다. 제품 장애, 가격 인상, 지역 정책 변경, 계약 종료가 생겼을 때 핵심 업무를 지속할 최소한의 선택지를 갖는다는 뜻이다.

도입 계약에서는 서비스 수준, 지원 범위, 장애 통지, 로그 반출, 백업·복구, 계정 삭제 시 데이터 처리, 사용자·앱별 비용 집계, 크레딧 소진 후 동작을 확인한다. 이 질문은 ‘AI를 쓸 것인가’보다 덜 흥미로워 보여도 실제 운영에서 중단을 좌우한다. 특히 자동화가 핵심 업무로 이동할수록 수동 절차로 돌아갈 수 있는 경로와 책임자를 미리 정해야 한다.

5. Oracle 내부 활용 사례 — 숫자를 읽는 법과 재현 가능한 실험

OpenAI 발표는 Oracle이 13만 명의 활동 중인 ChatGPT 사용자와 9만 5천 명 이상의 활동 중인 Codex 사용자를 보고했다고 전한다. 두 집단은 서로 겹칠 수 있다. ‘활동 중’의 기준 기간도 이 발표 본문에서 상세히 정의되지 않는다. 따라서 두 숫자를 합쳐 22만 5천 명의 고유 사용자로 쓰면 안 된다. 사용자 수는 도입 규모의 신호지만, 각 사용자가 얼마나 자주 어떤 업무에 사용했는지, 성과가 어떠했는지를 알려 주지는 않는다.

채용팀 사례는 시장조사를 2~4일에서 15~20분의 준비로 바꿨다는 메시지로 소개된다. 원문은 직무 설명을 받아 유사 직무, 보상, 관련 지역의 인재 풀을 조사하는 도구를 말한다. 이 도구가 채용 의사결정 전체를 15분에 끝낸다는 뜻은 아니다. 보상 데이터의 출처와 갱신 주기, 지역별 법규, 후보자 개인정보, 편향 가능성을 따로 관리해야 한다. 내부 사례로서 작업 흐름이 유망하다는 점과 모든 고객 조직에서 동일한 절감률이 나온다는 주장은 다르다.

Applications Lab 사례에는 온톨로지를 통해 자연어 질문을 SQL과 내부 시스템 호출로 연결하는 설명이 있다. 한 사용자의 질문이 기존 수작업과 숫자까지 일치했다는 일화도 있다. 하나의 일치 사례는 시스템 전체의 정확도를 증명하지 않는다. 개발팀이 배울 점은 비즈니스 객체·관계·규칙을 명시하고, 사람이 대조 가능한 결과를 만들었다는 설계 구조다. 재현하려면 재무·인사·구매 팀의 데이터 정의를 먼저 합의하고, 정답을 알 수 있는 표본을 사용해야 한다.

SRE 사례는 사고 맥락과 플레이북을 자동으로 모아 간단한 사고의 처리 시간을 줄였다는 설명이다. ‘간단한 사고’라는 조건이 중요하다. 복잡한 장애에서는 에이전트가 잘못된 플레이북을 제시하거나 오래된 서비스 구성을 참조할 수 있다. 운영자에게 도움이 되는 것은 답을 대신 결정하는 기능보다 관련 로그, 변경 이력, 소유 팀, 최근 사고 기록을 빠르게 모으는 기능일 수 있다. 실제 평가에는 경보 인지부터 원인 확인·완화·복구까지 단계별 시간을 측정하고, 잘못된 조치 제안이 없었는지도 포함한다.

이 세 사례를 도입 검토의 근거로 쓰려면 각자의 업무에 대응하는 대조군 또는 기준선을 만든다. 기존 작업에 걸린 실제 시간, 산출물의 정확도, 수정 횟수, 사용자 만족도, 데이터 접근 위반 건수를 기록한다. AI 도구를 도입한 뒤에는 쉬운 건만 골라 비교하지 않는다. 동일 기간의 비슷한 난도와 데이터 품질을 가진 업무를 비교한다. 생산성 이득이 사용자에게 추가 검토 부담을 떠넘긴 것은 아닌지도 본다. 고객 사례는 좋은 가설을 제공하지만 조직별 효과는 내부 실험으로 확인해야 한다.

6. Decisions API와 Habitat가 주는 보조 관점 — 오늘의 신규 발표와 혼동하지 않기

작은 판단을 큰 모델 호출과 분리하기

10월 22일 발표된 Decisions API는 앱과 에이전트가 반복하는 제한된 선택을 빠르게 처리하도록 만든 별도 API다. 공식 글에 따르면 입력은 텍스트·이미지·구조화 데이터가 가능하고 답 유형은 조건의 확률을 돌려주는 predicate, 미리 정의된 값 중 선택하는 choice, 순서형 척도의 점수를 내는 score다. 최대 400개 질문을 요청에 포함할 수 있다고 설명한다. OpenAI는 GPT-6 Luna를 Responses API로 호출하는 것보다 최대 10배 빠른 경우를 말하지만, 이는 발표의 비교이며 모든 업무의 지연 시간 보장은 아니다. 비용·속도를 자기 워크로드에서 측정해야 한다.

Oracle 업무 앱 연결과 직접 통합된다고 발표된 것은 아니지만, 이 구분은 설계에 유용하다. ‘문의 유형은 비용·구매·계획 중 어디인가’처럼 가능한 답이 제한된 분류와, ‘이번 달의 비용 차이가 왜 발생했는가’처럼 근거를 종합해야 하는 분석은 다른 문제다. 단순 라우팅에 무거운 생성 모델을 계속 쓰면 비용과 대기 시간이 늘 수 있다. 반대로 제한된 선택 API의 확률값만으로 지급 승인이나 권한 부여를 자동화하면 오류의 비용이 크다. 결정 도구는 후보를 만들고, 높은 위험의 실행은 정책과 사람의 승인에 맡기는 편이 낫다.

확률은 설명 가능한 업무 기준과 연결해야 한다. choice가 0.92의 자신감으로 ‘구매’라고 분류해도 입력이 두 부서의 용어를 혼합했을 수 있다. 임계값을 넘겼다는 이유로 곧바로 구매 앱의 쓰기 권한을 쓰는 것은 잘못이다. 분류 오류의 비용을 업무별로 계산하고, 모호한 입력은 사용자에게 되묻거나 수동 처리로 넘긴다. 결정을 나중에 재평가할 수 있도록 질문 템플릿, 후보 값, 모델·API 버전, 입력 데이터의 기준 시점을 기록한다.

다중 테넌트 데이터의 운영 교훈

10월 23일 OpenAI의 Habitat 기술 글은 10억 명 이상이 사용하는 제품을 위한 온라인 저장소가 40개 지역에서 밀리초 단위로 응답해야 한다고 설명한다. Azure Cosmos DB 기반에서 공유 컨테이너와 단독 컨테이너 사이를 오가며, 핫 키와 노이즈가 많은 이웃, 물리 파티션의 처리량 제한, 용량 계획 문제를 겪었다. 최종적으로 핫 키 조절과 요청 우선순위, 개선된 서버리스 모드, 데이터 이동 능력을 활용해 다중 테넌트 기본값으로 되돌아갔다고 쓴다. 이는 Oracle 제품이 Habitat를 쓴다는 말이 아니라, 공유 플랫폼의 격리와 우선순위를 설계할 때 참고할 수 있는 공개 사례다.

기업용 AI Workspace에서도 비슷한 종류의 운영 질문이 생긴다. 한 부서가 대량 문서를 가져와 분석하는 작업과 재무 담당자가 월말 마감의 상태를 조회하는 작업이 같은 자원을 사용한다면 어떤 요청이 먼저 처리되는가. 대량 배치 작업이 로그인이나 승인 화면을 느리게 만들지 않도록 우선순위를 나눌 수 있는가. 테넌트별 사용 한도와 비용을 측정할 수 있는가. 원본 Oracle 앱의 API 한도에 도달하면 에이전트가 무엇을 말하고 어떻게 재시도하는가. 모델의 품질과 별개로 시스템의 응답성·가용성을 결정하는 질문이다.

Habitat 글의 또 다른 교훈은 규모가 커지면 ‘관리형 서비스’도 공동 운영의 대상이 된다는 점이다. OpenAI는 Azure와 공동 테스트·대시보드·직접 엔지니어링 연락 경로를 만들었다고 설명한다. 모든 고객이 같은 수준의 공동 설계를 요구할 필요는 없다. 그러나 핵심 업무에 AI 연동을 붙이는 기업은 공급자 지원 티켓만으로 충분한지, 장애 시 누구에게 어떤 데이터로 에스컬레이션할지 생각해야 한다. 월말 마감 같은 일정이 있는 업무에는 특히 장애 통지와 수동 처리 절차가 중요하다.

‘실시간’과 ‘정합성’을 동시에 평가하기

빠른 응답이 항상 올바른 응답은 아니다. 캐시를 사용해 비용을 줄이면 오래된 상태를 보여 줄 수 있다. 원본 앱을 매번 조회하면 지연과 API 비용이 늘 수 있다. 업무마다 허용 가능한 지연과 데이터 신선도를 정해야 한다. 승인 전 미결 건 확인은 최신성이 매우 중요하지만, 지난 분기의 시장 분석은 일정 시간 캐시를 허용할 수 있다. 에이전트는 어느 답이 실시간이고 어느 답이 캐시인지 사용자에게 보여 줘야 한다.

모델 호출의 대기 시간, 데이터 소스의 대기 시간, 사람 승인 대기 시간을 따로 측정해야 병목을 찾을 수 있다. 모델을 더 빠르게 바꿨는데 원본 앱의 조회가 느리면 전체 시간이 거의 줄지 않는다. 반대로 모델이 빠른 대신 잘못된 도구를 선택해 재시도가 늘면 완료 시간은 길어진다. 운영 지표의 단위는 초당 토큰이 아니라 완료된 업무 건의 총 처리 시간과 오류율이어야 한다.

개발자에게 의미 — 발표를 설계 과제로 바꾸기

오늘 발표는 모델 API를 호출하는 개발자보다 업무 시스템과 AI 사이의 계약을 만드는 개발자에게 더 직접적이다. 대화형 업무 경험을 만들려면 모델의 문장 품질보다 도구의 입력·출력, 사용자별 접근, 상태 변경, 승인, 재시도, 감사가 핵심이다. 데이터베이스와 API가 이미 존재해도 자연어가 입력으로 들어오면 모호함이 시스템 경계로 이동한다. ‘이번 달’, ‘우리 팀’, ‘미결’, ‘큰 비용’ 같은 표현은 날짜·조직·상태·임계값으로 풀어야 한다. 한 번의 성공적인 데모는 이 모호함의 대부분을 시험하지 않는다.

실무적으로는 다음 순서를 권한다. 먼저 데이터 사전과 업무 용어를 고정한다. 다음으로 읽기 전용 도구를 만들고, 사용자별 권한을 원본 시스템과 비교한다. 그다음에 모델이 생성한 계획을 화면에 보여 주되 실제 상태 변경은 수행하지 않는 그림자 모드를 운영한다. 오류 사례를 모아 도구 스키마와 정책을 수정한 뒤, 제한된 쓰기를 승인 기반으로 연다. 마지막으로 고위험 업무의 자동화를 검토한다. 이 순서는 특정 모델이나 Oracle 제품의 기능을 전제로 하지 않으며, 어느 시스템을 쓰든 점검 가능한 개발 절차다.

도구 인터페이스의 예를 들면 읽기 도구는 entity_id, period, as_of, actor_id를 받고 source_system, source_record_id, fetched_at, permission_scope, data를 반환한다. 쓰기 도구는 여기에 expected_version, idempotency_key, approval_id를 요구한다. 모델이 이 필드를 모두 자연어에서 추론하게 두지 않는다. 누락되거나 모호하면 도구가 거부하고 사용자에게 확인을 요청한다. 높은 위험의 작업은 시스템이 승인 ID를 발급하고 검증해야 한다.

평가 세트는 정상 입력뿐 아니라 잘못된 입력을 포함해야 한다. 기간이 생략된 질문, 권한이 없는 레코드, 겹치는 법인 이름, 취소된 구매 건, 중복 요청, 중간에 만료된 승인, 오래된 캐시, 원본 앱 장애, 도구 응답에 악의적 지시가 포함된 경우를 시험한다. 모델이 ‘죄송합니다’라고 말하는 것만으로는 충분하지 않다. 어떤 상태가 변하지 않았는지 로그로 확인해야 한다. 오류 처리의 결과도 제품 기능이다.

또한 사용자의 최종 목표와 도구의 허용된 행동을 구별해야 한다. 사용자가 ‘마감을 끝내 줘’라고 해도 에이전트가 할 수 있는 작업은 필요한 자료 확인, 체크리스트 제시, 승인 가능한 항목 초안 작성 등으로 제한될 수 있다. 시스템은 허용되지 않은 업무를 그럴듯한 완료 문구로 덮지 않아야 한다. 불가능한 단계는 누가 왜 막았고 다음에 누가 해야 하는지 명확히 보여 줘야 한다. 이 정직성이 기업용 에이전트의 신뢰를 만든다.

운영 포인트 — 도입 전·파일럿·확장 단계에서 볼 것

도입 전: 계약과 경계 설정

• 제품 단계 확인: AI Workspace, Security Mesh, App Composer, SMB Bundle 각각의 현재 제공 지역, 대기 명단, 기능 범위, 지원 조건을 별도로 받는다. 발표의 모든 항목이 동일한 출시 상태라고 가정하지 않는다.
• 신원·권한 확인: ChatGPT 사용자와 Oracle 앱 역할을 어떻게 연결하는지, 역할 변경과 토큰 회수가 언제 적용되는지, 서비스 계정의 권한이 얼마나 넓은지 확인한다.
• 데이터 흐름 확인: 입력, 출력, 로그, 첨부 파일, 연결 앱 데이터가 어느 사업자·서비스·리전에서 처리·보관되는지 계약과 기술 문서로 확인한다. Marketplace 구매 경로와 데이터 처리 위치를 혼동하지 않는다.
• 업무 분류: 조회, 초안, 승인 요청, 승인 집행, 지급·권한 변경을 별도 위험 단계로 나누고 각 단계의 소유자와 허용 범위를 정한다.
• 복구 경로: 모델 또는 연결 앱이 장애를 겪을 때 월말 마감이나 구매 결재가 멈추지 않도록 수동 절차와 기록 보존 방식을 마련한다.

파일럿: 하나의 질문과 하나의 상태 변경을 분리

• 정답 세트: 업무 담당자가 원본 앱에서 확인한 정답과 근거를 표본으로 제공한다. 모델이 만든 답을 정답으로 재사용하지 않는다.
• 권한 경계 시험: 서로 다른 부서, 법인, 역할의 계정으로 같은 질문을 보내 접근 차이를 확인한다. 관리자의 성공 사례만으로 통과시키지 않는다.
• 신선도 시험: 원본 값을 갱신한 뒤 답변에 반영되는 시간과 오래된 캐시의 표시를 확인한다.
• 실패 시험: 토큰 만료, API 타임아웃, 중복 클릭, 부분 성공, 승인 직전 레코드 변경을 재현한다. ‘완료’ 문구와 실제 원본 상태가 일치해야 한다.
• 생산성 측정: 질문 시작부터 사람이 신뢰하고 업무에 반영할 수 있는 결과를 얻기까지의 시간을 측정한다. 프롬프트 응답 시간만 재지 않는다.

확장: 거버넌스와 비용

• 앱 카탈로그: App Composer로 만든 앱마다 소유자, 데이터 등급, 배포 리전, 의존성, 테스트, 버전, 종료 시점을 기록한다.
• 감사 연결: 대화 ID와 원본 Oracle 거래 ID, 승인 ID, 배포 변경 ID를 같은 추적 체계에서 조회할 수 있게 한다.
• 비용 분리: API·Codex·ChatGPT Work·OCI 비용과 크레딧 차감, 사람 검토 시간을 업무 단위로 나눈다. 비용이 보이지 않으면 최적화도 어렵다.
• 보안 성능: Security Mesh의 경고 수보다 진짜 결함 발견과 수정 반영까지의 시간, 오탐 검토 비용, 운영 영향도를 본다.
• 변경 검증: 모델 버전, 연결 앱 API, 업무 규칙, 권한 정책이 바뀔 때 동일 평가 세트를 다시 실행한다. 어제의 안전한 결과가 오늘의 정책 변경에도 유지된다고 가정하지 않는다.

발표와 추론을 구분하는 확인표

항목	공식 자료에서 확인한 내용	이번 글의 분석·확인할 부분
Oracle AI Workspace	Oracle 앱·데이터를 ChatGPT와 연결해 승인된 업무 흐름을 수행하는 목표	사용자별 권한 전달, 쓰기 승인, 실패 복구의 실제 구현과 제공 범위
AI Security Mesh	Oracle 관리형 테스트 인프라와 OpenAI 사이버 모델을 활용한다는 발표	탐지 정확도, 시험 환경, 실제 패치·배포 책임, 생산 영향
App Composer	Codex 등의 도구로 앱을 만들고 승인된 데이터에 연결하며 OCI 배포를 Oracle이 관리한다는 구상	소스·설정 반출, 테스트, 유지보수 소유권, 배포·롤백 절차
AI SMB Bundle	ChatGPT Business·Codex·Oracle 앱과 반복 OCI 크레딧 묶음	정확한 가격·크레딧 조건·사용 가능 지역·초과 사용 비용
Oracle Marketplace	미국 고객의 OpenAI API·Codex·ChatGPT Work 구매 경로와 적격 크레딧 사용	한국 고객 가용성, 계약별 처리 위치, 기존 구매 약정과 데이터 정책
Oracle 내부 사례	활동 사용자 수와 채용·업무 분석·SRE 활용 사례	전체 조직의 인과적 생산성 효과와 다른 고객으로의 일반화

표의 세 번째 열은 발표의 누락을 메우기 위해 지어낸 사실이 아니라, 도입 시 고객 조직이 검증해야 할 질문이다. 기능의 이름이 같은 경우에도 서비스 지역과 계약, 계정 종류에 따라 실제 조건은 달라질 수 있다. 공식 자료가 제시하지 않은 숫자를 임의로 추정하지 않았다.

오늘의 실행안 — 30일 안에 무엇을 검증할 것인가

첫 주: 재무·구매·IT 담당자가 한 회의에서 ‘한 가지 질문’을 정의한다. 예를 들어 ‘우리 법인의 지난달 미결 구매 건은 무엇인가’다. ‘우리’와 ‘지난달’의 정의, 상태 코드, 포함할 시스템, 권한별 제외 범위를 문서로 고정한다. 기존 시스템에서 정답 30~50건을 추출하고, 접근 가능한 계정과 불가능한 계정을 준비한다. 동시에 각 제품의 실제 가용성과 계약 조건을 공급자에게 확인한다.

둘째 주: 읽기 전용 연결을 만들고 정답 세트로 평가한다. 질문을 조금씩 바꿔도 같은 의미의 답이 나오는지, 근거 레코드와 시각이 표시되는지 본다. 오답을 유형별로 나눈다. 용어 정의가 틀렸는지, 원본 데이터가 낡았는지, 권한 필터가 빠졌는지, 모델의 도구 선택이 잘못됐는지에 따라 책임 팀이 달라진다. 오답 전체를 ‘모델이 가끔 환각한다’로 뭉개지 않는다.

셋째 주: 상태 변경 없이 승인 요청의 미리보기만 만든다. 모델이 어떤 건에 어떤 변경을 제안하는지 사람에게 보여 주고, 실제 업무 시스템의 정답 처리와 비교한다. 모호한 질문과 권한 오류, API 장애, 중복 요청을 일부러 섞는다. 감사 로그에서 사용자 요청·도구 계획·정책 판단·제안 결과를 하나의 추적 ID로 재구성할 수 있어야 한다. 운영자는 오류를 보고 어느 시스템을 고쳐야 하는지 알아야 한다.

넷째 주: 위험이 낮은 변경 하나를 별도 승인과 멱등 키 아래에서 허용한다. 실행 전후 원본 레코드를 비교하고, 중복 클릭과 타임아웃 재시도를 시험한다. 지급 승인이나 마감 확정 같은 고위험 작업은 이 파일럿에 넣지 않는다. 파일럿 후에는 완료율, 사람이 검토한 시간, 오류·권한 위반 건수, 데이터 신선도, 총비용을 기준선과 비교한다. 근거가 충분하지 않으면 기능 범위를 유지하고 오류를 고친다. 확대 여부는 데모의 인상보다 측정된 업무 결과로 결정한다.

30일은 모든 제품을 도입하는 일정이 아니라 한 가지 업무 흐름의 핵심 위험을 발견하는 제한된 실험 기간이다. 실제 제품의 출시 단계가 맞지 않으면 동일한 절차를 내부 프로토타입이나 기존 API 연결에 적용할 수 있다. 목적은 특정 공급자를 조기에 선택하는 것이 아니라 도입 의사결정에 필요한 증거를 만드는 것이다.

소스 링크와 확인 범위

이번 호의 뉴스 사실은 아래 공식 원문을 바탕으로 한다. 직접 확인한 페이지와 발행일이 다른 배경 자료를 구분했다. 외부 보도, 익명 게시물, 소문은 사용하지 않았다.

• OpenAI 뉴스 목록 — 10월 27일 Oracle 협력 확대 발표의 목록·날짜 확인.
• OpenAI·Oracle 협력 확대 발표 — 오늘의 중심 자료. 제품별 설명, 내부 사용 규모, 미국 Marketplace 경로 확인.
• OpenAI·Oracle 파트너 소개 — AI Workspace·Security Mesh·App Composer·SMB Bundle의 요약과 목표 확인.
• Oracle Marketplace를 통한 OpenAI 접근 — 미국 제공 범위와 적격 Oracle Universal Credits 설명. 이전 발표의 업데이트 문구를 포함한다.
• Oracle의 ChatGPT·Codex 내부 활용 사례 — 채용팀, Applications Lab, SRE의 고객 사례. 독립 효과 평가가 아닌 공급자 게시 사례로 취급.
• Decisions API 공식 발표 — 10월 22일 발표된 제한된 선택 API의 답 유형과 사용 맥락. 오늘 새 발표가 아니라 설계 비교 자료.
• Habitat 저장소 확장 기술 글 Part II — 10월 23일 발표된 다중 테넌트 운영 기술 사례. Oracle 협력의 구현 설명으로 해석하지 않음.
• 확인한 공식 목록: Google AI · Google 개발자 · GitHub 제품 뉴스 · AWS AI 블로그 · Microsoft AI 블로그. 이 목록에서 확인되지 않은 항목을 이번 호의 속보로 추가하지 않았다.

맺음말

오늘의 발표는 모델이 더 똑똑해졌다는 소식보다, 기업용 AI가 실제 업무 애플리케이션의 권한·데이터·승인·구매 체계 안으로 들어가는 방식을 보여 준다. Oracle AI Workspace는 대화형 진입점을, App Composer는 앱을 만드는 경로를, Security Mesh는 보안 검사의 경로를, SMB Bundle과 Marketplace는 조달의 경로를 제시한다. 각각의 제품 단계와 계약 조건은 따로 확인해야 한다. 한 문장으로 ‘Oracle 앱을 AI가 자동으로 운영한다’고 요약하면 기술적·업무적 경계가 사라진다.

개발팀의 다음 행동은 더 큰 프롬프트를 만드는 일이 아니다. 한 가지 읽기 전용 업무를 골라 원본 데이터와 권한을 대조하고, 상태 변경을 제안과 실행으로 분리하며, 승인·멱등성·감사·복구를 도구 계약에 넣는 일이다. 운영팀은 누구의 권한으로 어느 데이터가 처리되고 어느 비용이 발생했는지를 확인해야 한다. 공급자의 발표는 방향과 가능성을 제시한다. 실제 신뢰성은 고객 조직이 만든 업무 경계와 검증 가능한 운영 기록에서 나온다.