AX Weekly AI Note — 2026년 10월 5주차

사내 장애 접수 시스템에 문제가 등록됐다고 가정해 보겠습니다. 담당자는 비슷한 장애가 있었는지 검색하고, 최근 변경된 설정을 확인한 뒤 처리 방법을 결정합니다. 개발팀의 수정이 필요하면 별도 이슈를 만들고 진행 상황을 확인해야 합니다.

이 과정을 AI에게 맡기려면 어떻게 해야 할까요?

이번 주 OpenAI와 ServiceNow는 장애 이력과 업무 처리 기능을 ChatGPT 안에서 사용할 수 있도록 협력을 확대했습니다. Oracle도 자사 업무 시스템을 ChatGPT와 연결하는 계획을 발표했습니다.

GitHub는 반복적인 개발 업무를 Agent가 실행하도록 하는 기능을 정식 제공했고, 여러 모델을 자동으로 선택하는 Copilot Fusion도 공개했습니다.

이번 주에는 기존 업무 시스템을 Agent와 연결하는 방식이 어떻게 달라지고 있는지, 그리고 기업에서 직접 구축할 부분과 기존 제품을 활용할 부분을 어떻게 구분해야 할지 살펴보겠습니다.

---

1. 지난주 주요 뉴스

• 2026.10.26 — GitHub Copilot, 위험도가 낮은 명령을 자동 승인하는 Assisted Permissions 정식 제공
  GitHub가 Copilot CLI, Copilot App, VS Code에서 Assisted Permissions를 정식 제공하기 시작했습니다. Agent가 명령어 실행, 파일 접근, URL 열기를 요청하면 별도의 언어 모델이 해당 작업을 평가합니다. 명확하게 안전하다고 판단한 작업은 자동으로 진행하고, 나머지는 사용자 승인을 받는 방식입니다. 기업 관리자는 모든 작업을 허용하는 모드를 제한하거나 Assisted Permissions 사용 여부를 정책으로 관리할 수 있습니다. 승인 요청 때문에 작업이 자주 중단되는 문제를 줄이려는 기능이지만, 모델의 위험 판단만으로 모든 보안 문제가 해결되는 것은 아닙니다. GitHub
• 2026.10.27 — OpenAI·Oracle, ChatGPT에서 기업 업무 애플리케이션을 사용하는 협력 확대
  OpenAI와 Oracle이 Oracle 애플리케이션과 데이터를 ChatGPT에 연결하기 위한 협력 확대를 발표했습니다. Oracle이 개발 중인 AI Workspace는 재무, 구매, 계획 등의 정보를 한곳에서 조회하고 승인된 업무를 처리하는 것을 목표로 합니다. Oracle AI Security Mesh와 App Composer도 함께 소개했습니다. 사용자가 여러 업무 시스템을 직접 오가는 대신 ChatGPT에서 필요한 정보를 찾고 작업을 요청하는 방식입니다. 다만 발표된 제품 중에는 개발 중이거나 출시 예정인 기능이 포함되어 있습니다. OpenAI
• 2026.10.28 — GitHub, Agentic Workflows 정식 제공…기존 GitHub Actions에서 AI 업무 자동화
  GitHub가 Agentic Workflows를 정식 제공하기 시작했습니다. 마크다운 파일에 자동화할 업무를 설명하면 이를 GitHub Actions 워크플로로 변환해 실행합니다. Issue 분류, CI 실패 분석, 문서 갱신, 테스트 작성처럼 반복되면서도 판단이 필요한 업무에 활용할 수 있습니다. 기존 Runner와 조직 정책을 재사용하고, Agent는 기본적으로 읽기 전용 권한을 사용합니다. 변경 결과에는 별도의 검증 과정도 적용됩니다. 새로운 Agent 플랫폼을 따로 구축하지 않고 기존 CI/CD 환경에서 자동화를 시작할 수 있다는 점이 눈에 띕니다. GitHub
• 2026.10.28 — OpenAI·ServiceNow, IT 운영과 보안 업무를 ChatGPT에서 처리하도록 협력 확대
  OpenAI와 ServiceNow가 기존 협력을 확대했습니다. ServiceNow의 장애 이력과 업무 정보를 ChatGPT에서 조회하고, 변경 위험을 확인하거나 기록을 갱신하는 기능을 제공할 계획입니다. ServiceNow의 Action Fabric을 통해 기존 업무 규칙과 사용자 권한을 적용하는 방식입니다. 이를 통해 장애 대응이나 IT 요청 처리 과정에서 여러 시스템을 오가는 일을 줄이려 합니다. 대화 화면에서 업무를 처리하더라도 실제 실행에는 기존 ServiceNow의 승인과 권한 정책을 사용한다는 점이 중요합니다. 일부 기능은 아직 프리뷰 또는 제공 예정 단계입니다. OpenAI
• 2026.10.28 — GitHub Copilot Fusion 공개…업무에 따라 여러 AI 모델을 자동 선택
  GitHub가 Copilot Fusion을 정식 제공하기 시작했습니다. 사용자가 모델을 직접 선택하는 대신 작업의 난이도에 따라 적절한 모델을 사용하도록 구성한 기능입니다. 하나의 모델로 처리하거나, 가벼운 모델이 먼저 작업한 뒤 검증 결과에 따라 상위 모델로 넘기거나, 다른 모델이 결과를 검토하는 방식을 지원합니다. GitHub는 특정 코딩 평가에서 기존 상위 모델과 비슷한 성능을 더 낮은 비용과 짧은 시간으로 달성했다고 설명합니다. 실제 비용은 사용한 모델과 호출량에 따라 달라집니다. GitHub

---

2. 이번 주에 남긴 메모

새로운 Agent를 만드는 것보다 기존 시스템을 잘 연결하는 편이 나을 수도 있습니다

이번 주에는 Oracle과 ServiceNow의 발표가 가장 눈에 들어왔습니다.

그동안 AX를 추진한다고 하면 사내 데이터를 수집하고, MCP Server를 만들고, 별도의 Agent 플랫폼을 구성하는 방법부터 생각하기 쉬웠습니다.

그런데 기존 업무 시스템을 만드는 업체들이 직접 Agent 기능을 제공하기 시작했습니다.

ServiceNow는 장애 처리에 필요한 데이터와 업무 절차를 이미 가지고 있습니다. Oracle도 재무와 구매, 인사 같은 업무를 처리하는 시스템을 운영하고 있습니다.

이런 시스템에 Agent가 연결된다면 같은 기능을 처음부터 다시 만들 필요는 없을 것입니다.

물론 모든 업무를 기존 제품으로 해결할 수 있다는 뜻은 아닙니다. 회사마다 별도로 운영하는 시스템이나 내부 규칙이 있기 때문입니다.

그래도 이미 사용하고 있는 시스템이 어디까지 Agent 기능을 지원하는지 확인하는 것이 직접 개발보다 먼저일 수 있겠습니다.

사람에게 익숙한 UI가 Agent에게도 필요한 것은 아닙니다

기존 업무 시스템에서는 사람이 화면을 열고 메뉴를 찾아 작업합니다.

예를 들어 ServiceNow에서 장애를 처리하려면 장애 목록을 조회하고, 상세 화면에서 내용을 확인한 뒤 담당자를 지정하거나 상태를 변경합니다.

Agent는 같은 화면을 그대로 사용할 필요가 없습니다.

필요한 정보와 작업 기능이 API나 MCP를 통해 제공된다면 화면을 거치지 않고 업무를 처리할 수 있습니다.

그렇다고 기존 UI가 없어질 것이라고 보기는 어렵습니다.

사람이 직접 검토해야 하는 업무나 예외 상황에서는 여전히 화면이 필요합니다. Agent가 처리한 결과를 확인하고 변경 이력을 추적하는 데도 도움이 됩니다.

앞으로는 사람이 사용하는 화면과 Agent가 사용하는 인터페이스를 함께 제공하는 업무 시스템이 늘어날 것으로 보입니다.

AI가 필요한 작업인지부터 구분할 필요가 있습니다

GitHub Agentic Workflows도 관심이 갔습니다.

기존 GitHub Actions는 정해진 규칙에 따라 빌드와 테스트, 배포를 수행합니다.

여기에 AI를 연결하면 오류 로그를 분석하거나 변경된 코드에 맞춰 문서를 수정하는 것처럼 판단이 필요한 작업도 자동화할 수 있습니다.

하지만 모든 단계에 Agent를 사용할 필요는 없습니다.

단순한 테스트 실행이나 파일 복사, 배포 조건 확인은 기존 스크립트가 더 정확하고 저렴할 수 있습니다.

반면 테스트가 실패했을 때 원인을 분석하고 수정 방향을 제안하는 작업에는 AI가 도움이 됩니다.

정해진 작업은 기존 자동화로 처리하고, 판단이 필요한 부분에 Agent를 사용하는 것이 운영과 비용 측면에서 합리적일 것 같습니다.

모델을 직접 고르는 일도 줄어들 수 있겠습니다

Copilot Fusion에서는 사용자가 매번 AI 모델을 선택할 필요가 없습니다.

간단한 작업은 비용이 낮은 모델로 처리하고, 복잡한 작업은 상위 모델로 넘기는 방식입니다.

이런 구조가 일반화된다면 기업에서도 모든 업무에 최고 성능 모델을 사용할 필요는 없을 것입니다.

다만 Model Routing 자체에도 비용이 발생합니다. 여러 모델을 호출하면 오히려 비용이 증가할 수도 있습니다.

따라서 실제 업무에서는 모델별 토큰 가격보다 작업 완료율과 총비용을 함께 비교해야 합니다.

---

3. 뉴스에서 드러난 핵심 변화에 대한 해석

Agent가 새로운 업무 화면이 될 수 있을까

Oracle과 ServiceNow의 발표에서 공통으로 보이는 것은 기존 업무 시스템을 ChatGPT 같은 Agent 환경에서 사용할 수 있도록 만들고 있다는 점입니다.

과거에는 AI를 사용하려면 필요한 데이터를 별도로 가져와야 했습니다.

문서를 업로드하거나 API를 개발하고, AI가 만든 결과를 다시 업무 시스템에 입력했습니다.

앞으로는 이 과정의 일부를 Agent가 직접 처리할 수 있을 것입니다.

예를 들어 장애 보고서를 작성할 때 관련 장애 이력과 변경 내역을 조회하고, 보고서를 만든 뒤 승인된 결과를 시스템에 기록하는 방식입니다.

그렇다면 기업은 AI 전용 업무 시스템을 새로 만드는 것보다 기존 시스템이 제공하는 연결 기능을 활용하는 편이 효율적일 수 있습니다.

다만 실제 제공 범위와 권한 관리 방법은 제품마다 확인해야 합니다.

MCP만으로 업무 자동화가 완성되지는 않습니다

MCP를 연결하면 Agent가 외부 시스템의 기능을 사용할 수 있습니다.

하지만 어떤 순서로 작업할지, 실패했을 때 어떻게 처리할지, 사람에게 언제 승인을 요청할지는 별도로 정해야 합니다.

GitHub Agentic Workflows는 이 문제에 대한 하나의 접근입니다.

기존 GitHub Actions가 실행 순서와 조건을 관리하고, Agent가 필요한 단계에서 판단하도록 구성합니다.

이런 방식이라면 기존 운영 체계를 유지하면서 AI 기능을 추가할 수 있습니다.

특히 이미 CI/CD와 모니터링 시스템이 구축된 기업에서는 모든 자동화 과정을 Agent 중심으로 다시 만들 필요가 없습니다.

Multi-Agent가 반드시 여러 개의 독립 Agent를 의미하지는 않습니다

이번 Copilot Fusion 발표에서는 하나의 모델이 작업을 처리하거나, 다른 모델이 검토하거나, 필요할 때 더 강력한 모델로 넘기는 방식을 지원합니다.

서로 다른 모델을 활용하지만 모든 모델이 독립적인 업무 Agent로 실행되는 것은 아닙니다.

이 구분은 중요해 보입니다.

여러 모델을 사용하는 것과 여러 Agent에게 업무를 나누어 맡기는 것은 다른 문제입니다.

예를 들어 코드 생성에는 빠른 모델을 사용하고, 복잡한 오류 분석에는 상위 모델을 사용할 수 있습니다.

반면 개발 Agent와 보안 검토 Agent를 나누려면 작업 결과의 전달 방법과 권한, 실패 처리까지 설계해야 합니다.

처음부터 복잡한 Multi-Agent 구조를 만들기보다 필요한 단계에서 모델을 바꾸는 것만으로도 충분한 경우가 있을 것입니다.

---

4. AX 관점 분석

기존 업무 시스템을 활용한 AX부터 검토해 볼 만합니다

사내 IT 운영 업무를 예로 들어보겠습니다.

직원이 VPN 연결 문제를 문의했습니다.

현재 방식에서는 담당자가 사용자 정보를 확인하고, VPN 서버 로그를 조회한 뒤, 필요하면 네트워크 장비 설정과 최근 장애 이력을 확인합니다.

Agent를 활용하면 일부 과정을 줄일 수 있습니다.

먼저 사용자에게 필요한 정보를 확인하고, 읽기 권한으로 VPN 상태와 최근 로그를 조회합니다. 기존 장애 사례와 비교한 뒤 예상 원인과 조치 방법을 정리합니다.

문제가 단순한 클라이언트 설정이라면 사용자가 직접 확인할 방법을 안내할 수 있습니다.

하지만 계정을 초기화하거나 방화벽 정책을 변경해야 한다면 별도 승인을 받도록 해야 합니다.

이런 업무에 필요한 구성은 다음 정도부터 생각해 볼 수 있습니다.

직원 문의
    │
    ▼
IT 지원 Agent
    │
    ├─ 사용자·장비 정보 조회
    ├─ VPN / 네트워크 로그 조회
    ├─ 기존 장애 이력 검색
    │
    ▼
원인 분석 및 조치 제안
    │
    ├─ 일반 안내 → 사용자 전달
    │
    └─ 시스템 변경 → 담당자 승인
                         │
                         ▼
                      API 실행
                         │
                         ▼
                      결과 확인

여기서 중요한 것은 별도의 AI 전용 시스템을 모두 구축하는 것이 아닙니다.

이미 사용하고 있는 VPN 관리 시스템, 로그 서버, IT 자산 관리 시스템을 필요한 범위에서 연결하면 됩니다.

GitHub Agentic Workflows를 개발 운영에 적용한다면

개발 프로젝트에서는 비교적 적용하기 쉬운 업무부터 시작할 수 있습니다.

예를 들어 다음과 같은 작업입니다.

업무	기존 도구	Agent 역할
정기 빌드	GitHub Actions	불필요
테스트 실행	CI / 테스트 도구	불필요
테스트 실패 분석	로그·테스트 결과	원인 분석
코드 수정 제안	Git / PR	수정안 작성
변경 검증	CI / 정적 분석	결과 설명
문서 갱신	Repository	문서 수정
병합 승인	Branch Protection	사람의 검토 유지

이렇게 나누면 기존 CI/CD 체계 안에서 Agent를 활용할 수 있습니다.

특히 GitHub Actions를 이미 운영하고 있다면 새로운 Orchestrator를 도입하지 않고도 일부 Agent Workflow를 시험해 볼 수 있습니다.

처음에는 읽기 전용 분석과 문서 수정 정도로 시작하고, 실제 코드 변경은 Draft PR을 생성하도록 제한하는 편이 좋겠습니다.

어떤 모델을 사용할지는 업무에 따라 결정하면 됩니다

Copilot Fusion과 같은 Model Routing 방식은 비용을 줄이는 데 도움이 될 수 있습니다.

기업에서 자체 Agent를 운영한다면 비슷한 구조를 구현할 수도 있습니다.

예를 들어 단순한 로그 분류나 문서 검색에는 작은 모델을 사용하고, 복잡한 장애 원인 분석에는 상위 모델을 사용하는 방식입니다.

하지만 모든 요청을 작은 모델로 먼저 처리하는 것이 항상 유리한 것은 아닙니다.

작은 모델이 실패하고 상위 모델을 다시 호출하면 응답 시간이 길어지고 비용도 중복될 수 있습니다.

따라서 실제로는 다음 항목을 비교해야 합니다.

• 작업별 성공률과 재시도 횟수
• 결과 검증에 필요한 시간
• 전체 모델 및 도구 실행 비용
• 평균 업무 처리시간
• 사람이 수정하거나 다시 처리한 비율

단순한 Token Cost보다 실제 업무 처리 비용을 기준으로 판단하는 편이 좋겠습니다.

기존 시스템과 연결할 때 확인할 부분

Oracle이나 ServiceNow처럼 기업 업무 시스템을 Agent와 연결할 수 있게 되더라도 바로 운영환경에 적용하기는 어렵습니다.

기존 시스템에서 사용하는 권한과 Agent의 권한이 어떻게 연결되는지 확인해야 합니다.

업무 기록을 조회하는 기능과 데이터를 변경하는 기능은 분리하는 편이 좋습니다. Agent가 사용하는 계정의 권한도 사람의 관리자 계정을 그대로 공유하기보다 작업에 필요한 범위로 제한해야 합니다.

특히 장애 대응과 보안 운영처럼 운영 시스템에 직접 영향을 주는 업무에서는 사후 로그만으로 충분하지 않을 수 있습니다.

중요한 변경에는 승인 절차를 두고, 변경 후 실제 시스템 상태를 확인하는 과정도 필요합니다.

기존 보안 정책을 우회하면서 AI를 연결하는 방식은 피해야 합니다.

---

5. 이번 주 결론

이번 주에는 Agent를 실제 업무 시스템에 적용하는 방법이 조금 더 구체적으로 보였습니다.

OpenAI와 Oracle, ServiceNow는 기업이 이미 사용하고 있는 업무 시스템을 ChatGPT와 연결하는 방향을 제시했습니다.

GitHub는 기존 GitHub Actions 안에서 Agent를 실행하도록 만들었고, 여러 모델을 자동으로 선택하는 기능도 정식 제공했습니다.

기업에서는 이런 변화가 반가울 수 있습니다.

새로운 Agent 플랫폼을 처음부터 구축하지 않아도 기존 시스템의 일부 업무에 AI를 적용할 수 있기 때문입니다.

하지만 어떤 기능이 연결된다고 해서 업무 전체가 자동화되는 것은 아닙니다.

업무를 시작하는 조건과 실행 순서, 승인 기준, 완료 여부를 확인하는 방법이 필요합니다.

따라서 AX를 추진한다면 기존 업무를 먼저 살펴보는 편이 좋겠습니다.

어떤 작업은 이미 API나 스크립트로 자동화할 수 있습니다. 어떤 작업은 사람이 판단해야 합니다. 그리고 그 사이에 AI가 도와줄 수 있는 부분이 있습니다.

모든 업무를 Agent로 다시 만드는 것보다, 기존 업무에서 사람이 반복적으로 판단하고 전달하던 부분을 찾아 개선하는 것이 현실적인 출발점일 수 있습니다.

이번 주의 키워드는 Enterprise Workflow Integration — 기존 업무 시스템과의 연결입니다.