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

2026.10.05 ~ 2026.10.10

지난주에는 Agent가 단순한 요청을 처리하는 도구에서 지속적인 업무를 맡는 실행 주체로 바뀌고 있다는 이야기를 했다.

이번 주에는 그다음 단계가 보이기 시작했다.

Google은 기업 업무 전반에서 사용할 수 있는 범용 Agent를 발표했고, Atlassian은 사람과 Agent가 같은 공간에서 협업하는 구조를 공개했다. SAP는 Agent를 기존 ERP 업무 프로세스에 직접 결합하면서 실제 생산성 개선 사례를 제시했다.

서로 다른 발표지만 공통점이 있다.

Agent가 독립적으로 일을 잘하는 것보다, 조직이 이미 일하고 있는 방식 안에 어떻게 참여할 것인가에 초점이 맞춰지고 있다는 점이다.

⸻

1. 지난주 주요 뉴스

2026.10.06 — Atlassian, 사람과 AI Agent의 협업을 위한 ‘AMP’ 공개

Atlassian이 Team ’26 Europe에서 **Agentic Multiplayer Protocol(AMP)**을 발표했다.

AMP는 사람이 Agent와 일대일로 대화하는 방식에서 벗어나 Jira, Confluence, Loom 등 실제 협업 환경에서 사람과 Agent가 함께 작업하도록 설계한 체계다.

예를 들어 Jira 이슈에서 Agent에게 업무를 맡기거나, Confluence 문서에서 Agent를 멘션하고, Loom 영상으로 작업 내용을 전달할 수 있다.

특히 Agent의 작업 기록과 담당 업무를 기존 협업 공간에 연결하고, 사람의 검토와 승인 과정까지 포함한다는 점이 눈에 띈다.

MCP가 Agent와 Tool의 연결에 집중했다면, Atlassian의 AMP는 사람과 Agent가 동일한 업무 맥락을 공유하며 협업하는 문제를 다루고 있다.

다만 AMP는 Atlassian이 발표한 협업 체계로, 범용 산업 표준으로 확립된 것은 아니다. (Atlassian)

2026.10.06 — SAP, ‘Autonomous Enterprise’ 확대…11만 명이 사용하는 Joule

SAP는 SAP Connect 2026에서 Joule Work와 Joule Assistants를 기반으로 한 Autonomous Enterprise 전략을 구체화했다.

SAP 발표에 따르면 내부 직원 약 11만 명이 Joule을 사용하고 있으며, 재무·인사·구매 등 일부 업무에서 20% 이상의 생산성 향상을 관찰했다고 한다.

특히 흥미로운 점은 SAP가 Agent를 기존 업무 시스템에서 분리하지 않는다는 것이다.

Agent는 ERP가 사용하는 데이터, 권한, 비즈니스 규칙과 감사 기록을 활용하면서 실제 업무를 수행한다. 위험도가 높은 작업에는 사람의 승인을 남기고, 반복적인 업무는 자동화 수준을 높인다.

이는 기업이 새로운 Agent 플랫폼을 도입하는 것과 기존 업무 시스템 자체가 Agent를 지원하도록 바뀌는 것이 서로 다른 접근이라는 점을 보여준다.

Enterprise AX가 새로운 AI 제품의 도입을 넘어 기존 핵심 업무 시스템의 변화로 이어지고 있다.

다만 생산성 개선 수치는 SAP가 발표한 내부 성과이며, 전체 고객사의 평균 효과를 의미하지는 않는다. (SAP News Center)

2026.10.07 — GitHub Copilot, Local Sandboxing 정식 제공

GitHub가 Copilot CLI, Copilot App, VS Code Agent Host 환경에서 Local Sandboxing 기능을 정식 제공하기 시작했다.

이 기능은 Agent가 실행하는 명령어와 도구의 파일 접근, 네트워크 통신, Credential 사용 범위를 제한한다.

Microsoft eXecution Container(MXC)를 기반으로 Windows, macOS, Linux 환경에서 공통된 Sandbox 정책을 적용한다.

기업 관리자는 중앙 정책으로 Sandbox 사용을 강제하고 개발자가 해당 정책을 임의로 완화하지 못하도록 설정할 수도 있다.

특히 중요한 점은 모델의 판단을 제한하는 것이 아니라 실제 Tool 실행환경을 제한한다는 것이다.

모델이 어떤 명령을 생성하든 Sandbox가 허용하지 않는 자원에는 접근하지 못하도록 설계한 것이다.

Local Sandboxing은 기본 Copilot 구독에 추가 비용 없이 포함되지만, 실제 적용 범위와 활성화 상태는 사용 환경 및 정책에 따라 확인해야 한다. (The GitHub Blog)

2026.10.08 — Google, 기업 업무용 범용 ‘Gemini Agent’ 공개

Google Cloud가 Gemini at Work 2026에서 기업 업무를 수행하는 범용 Gemini Agent를 발표했다.

Gmail, Drive, Docs, Sheets, Calendar뿐 아니라 다양한 외부 업무 시스템과 연결하고, 사용자의 요청에 따라 여러 단계를 거쳐 결과물을 완성하도록 설계했다.

특히 Coworker Agent라는 개념이 흥미롭다.

Agent에 별도 계정과 이메일, Calendar, 저장 공간을 부여하고, 다른 직원들이 실제 팀원처럼 업무를 요청하거나 협업할 수 있도록 한다.

또한 하나의 Agent가 필요에 따라 하위 Agent를 생성해 병렬 또는 순차적으로 작업을 수행하고, 업무에 적합한 모델을 선택하는 Multi-model Orchestration도 제시했다.

Google은 Agent Identity, Agent Gateway, Sandbox, 비용 제한 등을 함께 강조했다.

Agent가 별도 Workspace 계정을 가지고 조직의 업무에 참여한다는 점에서, 지난주 등장했던 지속적인 Agent의 개념이 실제 협업 환경으로 확대되는 모습이다.

다만 새로운 범용 Gemini Agent는 발표 시점에 기업 고객을 대상으로 제한적인 프리뷰 단계이므로, 설명된 모든 기능이 일반 제공되는 것은 아니다. (Google Cloud)

2026.10.09 — Kore.ai, Agent를 지속적으로 평가·개선하는 ‘Autoloop’ 공개

Kore.ai가 Agent Platform의 자동 최적화 엔진 Autoloop을 정식 출시했다고 발표했다.

Autoloop은 Agent를 한 번 개발하고 배포하는 것으로 끝내지 않고, 실제 실행 결과를 바탕으로 성능을 지속적으로 평가하고 개선하도록 설계됐다.

업무 완료율, 정확도, 비즈니스 규칙 준수, 안전성, 사용자 경험, 비용 효율성 등을 평가한다.

특히 StateTrace를 통해 Agent의 실행 상태, Tool 호출, 다른 Agent로의 업무 전달 등을 추적하고, Agent Blueprint Language를 이용해 문제가 발생한 Workflow 영역을 수정하는 방식을 제시했다.

기존에는 Agent에 문제가 생기면 사람이 Prompt를 수정하고 다시 테스트하는 경우가 많았다.

Autoloop은 이런 과정을 지속적인 평가와 개선 체계로 연결하려는 시도다.

Agent 운영에도 기존 소프트웨어의 테스트·모니터링·지속적 개선과 비슷한 체계가 등장하고 있다는 점이 의미 있다.

다만 자동 최적화의 실제 효과와 안정성은 기업별 운영환경에서 검증이 필요하다. (Express Computer)

⸻

2. 이번 주에 남긴 메모

Agent에게 일을 맡기는 것과 조직의 구성원으로 참여시키는 것은 다르다

이번 주에는 Atlassian과 Google의 발표가 가장 눈에 들어왔다.

그동안 Agent를 생각할 때는 주로 어떤 업무를 대신 수행할 수 있는지에 관심이 많았다.

보고서를 작성하고, 메일을 정리하고, 코드를 수정하고, 서버 상태를 점검하는 것처럼 말이다.

그런데 이번 주 발표를 보면서 조금 다른 생각이 들었다.

Agent가 일을 잘하는 것만으로는 조직의 생산성이 높아지지 않을 수도 있겠다는 점이다.

예를 들어 개발 Agent가 코드를 작성했다고 하자.

코드가 완성됐다는 사실만으로 업무가 끝난 것은 아니다.

그 코드가 어떤 요구사항을 위한 것인지, 누가 검토해야 하는지, 어느 프로젝트에 반영해야 하는지, 배포 일정에 문제가 없는지까지 연결되어야 한다.

지금까지는 이 과정을 사람이 관리했다.

Agent가 만든 결과를 확인하고, 다른 사람에게 전달하고, 프로젝트 상태를 업데이트했다.

그런데 Atlassian은 Agent가 Jira와 Confluence 안에서 직접 협업하도록 만들고, Google은 Agent 자체에 계정과 업무 공간을 제공하기 시작했다.

이제 Agent의 역할이 조금 달라지는 것 같다.

사람에게 결과물을 전달하는 것에서, 사람이 일하는 공간 안에서 함께 업무를 진행하는 것으로.

업무 Context는 단순한 문서 검색 이상의 문제다

Enterprise RAG나 MCP를 생각하면 흔히 사내 문서와 시스템 데이터를 연결하는 것부터 떠올린다.

하지만 실제 업무에서는 데이터만으로 판단하기 어려운 경우가 많다.

프로젝트의 목적이 무엇인지, 누가 담당자인지, 이전에는 어떤 결정을 내렸는지, 현재 무엇이 지연되고 있는지 같은 정보가 필요하다.

같은 문서를 읽더라도 이런 Context에 따라 수행해야 할 일이 달라진다.

Atlassian이 Teamwork Graph를 강조하고, SAP가 Knowledge Graph와 Business Process를 강조하는 이유도 여기에 있는 것 같다.

데이터에 접근할 수 있다는 것과 업무를 이해할 수 있다는 것은 다르다.

앞으로 Agent가 실제 업무를 맡기 위해서는 단순한 검색 결과보다 조직의 관계와 업무 상태를 이해할 수 있는 구조가 필요해질 것 같다.

⸻

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

Agent의 경쟁이 업무 인터페이스로 이동하고 있다

지난 몇 주의 흐름을 다시 정리하면 다음과 같다.

시기 주요 변화 핵심 질문
9월 2주차 Execution Control Agent가 어디까지 실행할 수 있는가?
9월 3주차 Agent Identity 누가 실행했으며 어떤 권한을 갖는가?
9월 4주차 Agent Runtime 어떤 환경에서 안정적으로 실행할 것인가?
10월 1주차 Responsibility Agent에게 업무를 지속적으로 맡길 수 있는가?
10월 2주차 Collaboration & Context Agent가 조직의 업무 흐름에 어떻게 참여할 것인가?

이 흐름은 기술 발전이 반드시 순서대로 이루어진다는 의미는 아니다.

다만 최근 발표들의 관심사가 Agent 자체의 기능에서 실제 기업 업무와의 결합으로 확대되고 있다는 점은 분명해 보인다.

Google은 범용 Agent를 하나의 업무 인터페이스로 제시했고, SAP는 ERP 안에 Agent를 결합했으며, Atlassian은 기존 협업 시스템에 Agent를 참여시키는 방향을 택했다.

결국 접근 방식은 달라도 공통적으로 기존 업무 시스템과 Agent의 경계를 줄이려 하고 있다.

여기서 흥미로운 질문이 하나 생긴다.

앞으로 직원들은 ERP나 CRM, 그룹웨어를 지금처럼 직접 사용할까?

아니면 Agent에게 요청하고 Agent가 해당 시스템을 대신 사용하는 방식이 일반화될까?

아직 어느 한쪽으로 단정하기는 어렵다.

기업 업무에서는 승인, 감사, 예외 처리 때문에 전통적인 UI가 계속 필요할 수 있다.

하지만 반복적인 조회와 입력, 여러 시스템을 오가는 작업에서는 Agent가 새로운 업무 인터페이스가 될 가능성이 높아 보인다.

Multi-Agent도 기술적인 분업만으로는 부족하다

Google의 발표에서는 하나의 범용 Agent가 여러 하위 Agent를 생성하고 조율하는 구조가 제시됐다.

하지만 Enterprise에서 중요한 것은 Agent를 얼마나 많이 생성할 수 있는지가 아닐 것이다.

각 Agent가 사용하는 정보와 권한, 결과를 전달하는 방식, 검증 책임이 서로 연결되어야 한다.

예를 들어 Research Agent가 분석한 결과를 Execution Agent에게 전달했을 때, Execution Agent가 해당 결과를 그대로 신뢰해도 되는지부터 정해야 한다.

이 문제는 단순한 Agent 간 메시지 교환만으로 해결하기 어렵다.

결국 Multi-Agent가 업무에 깊숙이 들어갈수록 Shared Context, Validation, Delegation, Audit의 중요성이 커질 것 같다.

⸻

4. AX 관점 분석

AI는 개인의 생산성을 높이고, AX는 조직의 업무 방식을 바꾼다

이번 주 뉴스를 통해 AI 도입과 AX의 차이를 조금 더 구체적으로 생각해 볼 수 있었다.

AI를 도입하면 개인이 기존 업무를 더 빠르게 처리할 수 있다.

하지만 조직의 업무 방식 자체가 바뀌지는 않을 수도 있다.

예를 들어 AI를 이용해 보고서를 10분 만에 작성하더라도, 보고서를 검토하고 승인하고 다시 시스템에 입력하는 과정이 그대로라면 전체 업무의 생산성 향상은 제한적이다.

반면 AX는 조금 다른 접근이 필요하다.

보고서 작성부터 검증, 승인 요청, 시스템 반영까지 하나의 Workflow로 연결하는 것이다.

따라서 다음과 같은 구분이 가능할 것 같다.

구분 AI 도입 AX
목표 개별 작업의 생산성 향상 전체 업무 프로세스 개선
중심 모델과 사용자 업무와 실행 주체
연결 데이터 검색, 문서 작성 업무 시스템, 권한, 승인
실행 사람의 요청 중심 이벤트와 Workflow 중심
평가 응답 품질, 사용량 업무 완료율, 처리시간, 비용
운영 AI 서비스 관리 Agent와 Business Process 운영

AI가 개인을 빠르게 만든다면, AX는 개인과 조직 사이의 업무 전달 비용까지 줄이는 일에 더 가까울 것 같다.

MCP는 Tool Interface, 협업에는 그 이상의 구조가 필요하다

이번 Atlassian 발표는 MCP의 역할을 다시 생각하게 한다.

MCP는 Agent가 외부 시스템의 기능과 데이터를 이용하기 위한 표준 인터페이스다.

하지만 MCP가 있다고 해서 Agent가 업무 전체를 이해하거나 조직 구성원과 협업할 수 있는 것은 아니다.

예를 들어 Jira MCP를 연결하면 Agent가 이슈를 조회하고 변경할 수 있다.

하지만 그 이슈가 왜 만들어졌는지, 현재 어떤 의사결정이 필요한지, 누가 최종 승인을 해야 하는지는 별도의 업무 Context와 Workflow가 필요하다.

그래서 Enterprise Agent Architecture에서는 다음과 같은 계층을 구분할 필요가 있어 보인다.

MCP는 여전히 중요한 구성요소다.

하지만 Agent의 업무를 관리하는 Orchestration, 업무의 맥락을 제공하는 Context, 실제 행동을 제한하는 Policy는 서로 구분해야 한다.

MCP 연결이 곧 AX가 되는 것은 아니다.

Multi-Agent보다 먼저 Workflow를 설계해야 한다

이번 주 SAP 사례가 현실적으로 와닿았다.

SAP는 Agent가 기존 비즈니스 규칙과 데이터, 감사 체계를 활용하도록 설계하고 있다.

이는 AI가 모든 결정을 자유롭게 내리도록 하기보다 이미 검증된 업무 프로세스 안에서 필요한 판단을 수행하도록 만드는 방식이다.

이 접근은 Multi-Agent 설계에서도 중요할 것 같다.

예를 들어 구매 업무를 자동화한다고 가정해 보자.

구매 요청을 확인하고, 예산을 조회하고, 공급업체를 비교한 뒤, 최종 발주를 진행해야 한다.

이 과정에서 모든 단계를 별도 Agent로 구성할 필요는 없다.

예산 조회나 승인 상태 확인은 기존 API와 Workflow로 처리할 수 있다.

반면 복수 공급업체의 조건을 비교하고 예외 상황을 분석하는 작업에는 Agent의 판단이 유용할 수 있다.

즉 판단이 필요한 곳에는 Agent를 사용하고, 규칙이 명확한 곳에는 Deterministic Workflow를 유지하는 방식이 더 현실적이다.

Enterprise에서는 Agent의 운영 품질도 계속 측정해야 한다

Kore.ai의 Autoloop은 이러한 구조를 운영한 이후의 문제를 보여준다.

Agent를 배포했다고 해서 업무 자동화가 완성되는 것은 아니다.

운영 중에는 데이터가 바뀌고, 업무 규칙이 변경되고, 새로운 예외 상황이 발생한다.

기존 소프트웨어처럼 Agent 역시 지속적인 검증과 개선이 필요하다.

특히 기업에서는 Agent의 성능을 단순한 응답 정확도로만 평가하기 어렵다.

실제 업무가 성공적으로 완료됐는지, 규칙을 위반하지 않았는지, 사람이 얼마나 개입했는지까지 확인해야 한다.

AX 관점에서 앞으로 중요해질 지표는 다음과 같을 것이다.

지표 평가 목적
Task Completion Rate 실제 업무 완료율
Human Intervention Rate 사람의 개입 필요 수준
End-to-End Cycle Time 전체 업무 처리시간
Rework / Rollback Rate 오류 수정 및 재처리 비율
Cost per Completed Task 완료 업무당 총비용
Policy Violation Rate 정책 위반 발생 수준

이 지표들이 있어야 Agent가 단순히 많이 사용되는 것인지, 실제로 조직에 가치를 만들고 있는지를 구분할 수 있다.

IT 인프라 관점에서도 준비할 부분이 생긴다

이번 주 GitHub 발표는 Enterprise Agent 운영환경에 대한 현실적인 시사점을 준다.

Agent가 Shell Command를 실행하거나 파일을 수정하기 시작하면 기존 개발자 계정의 권한을 그대로 사용하는 방식에는 위험이 따른다.

따라서 기업 내부에 Agent 실행환경을 구축한다면 최소한 다음 사항은 분리하는 편이 좋을 것 같다.

* Execution Environment: Docker 또는 격리된 VM 기반 실행환경
* Identity & Permission: Agent별 최소 권한과 단기 Credential
* MCP / API Access: Gateway를 통한 접근 통제
* Logging & Trace: Tool 호출 및 변경 이력 기록
* Evaluation: 업무 완료율과 실패 원인 분석
* Cost Control: 모델·GPU·Tool 실행 비용 추적

Docker는 운영과 배포에 효율적이지만, 고위험 코드를 실행하는 Agent라면 컨테이너만으로 충분한 격리가 되는지는 별도로 검토해야 한다.

특히 외부에서 생성된 코드를 직접 실행하는 경우에는 MicroVM이나 격리된 VM까지 고려할 필요가 있다.

결국 Enterprise Agent가 확산될수록 기존 IT Infrastructure와 AI Infrastructure를 완전히 별개의 영역으로 운영하기는 어려워질 것 같다.

⸻

5. 이번 주 결론

이번 주에는 Agent가 독립적인 도구에서 조직의 업무에 참여하는 방향으로 이동하고 있다는 점이 가장 눈에 들어왔다.

Google은 Agent를 팀원처럼 사용할 수 있는 구조를 제시했고, Atlassian은 사람과 Agent의 협업 공간을 연결했다.

SAP는 기존 ERP의 업무 규칙과 데이터 안에서 Agent가 실행되도록 만들고 있으며, GitHub와 Kore.ai는 이러한 Agent를 안전하게 실행하고 지속적으로 개선하는 기반 기술을 강화하고 있다.

이 발표들을 연결해 보면 하나의 방향이 보인다.

Agent의 가치는 혼자 얼마나 많은 일을 할 수 있는지가 아니라, 조직의 업무를 얼마나 자연스럽게 이어갈 수 있는가에서 결정될 수도 있다.

그래서 이번 주에는 이렇게 정리하고 싶다.

AI는 개인의 업무를 빠르게 만들지만, AX는 사람과 Agent가 함께 일할 수 있도록 조직의 업무 구조를 바꾸는 일이다.

좋은 Agent를 도입한다고 해서 조직의 생산성이 자동으로 높아지는 것은 아니다.

Agent가 사용할 데이터와 Tool을 연결하고, 필요한 Context를 제공하고, 승인과 책임의 경계를 정리해야 한다.

그리고 Agent의 결과가 다음 업무로 자연스럽게 이어질 수 있어야 한다.

지난주에는 Agent에게 업무를 맡기는 것이 중요하다고 생각했다.

이번 주에는 그보다 한 가지 더 중요한 조건이 보였다.

Agent에게 일을 맡길 준비뿐 아니라, Agent와 함께 일할 준비가 조직에도 필요하다는 것이다.

이번 주의 키워드는 Collaboration & Business Context다.