AX Weekly AI Note — 2026년 11월 1주차
기간: 2026.11.01 ~ 2026.11.07
Agent가 더 빠르게 일하기 시작하면, 그 결과물을 받아들이는 기존 시스템은 준비되어 있을까?
OpenAI는 Coding Agent가 만들어내는 동시 작업량을 감당하기 위해 Git Backend 자체를 새로 설계했다. Microsoft는 SharePoint의 업무 기능을 Agent가 직접 사용할 수 있는 MCP Tool로 제공하기 시작했고, Snowflake는 여러 Agent가 동일한 업무 정의와 정책을 공유하는 기반을 확대했다.
GitHub는 Copilot의 사용량을 넘어 실제 코드 리뷰 의견이 어떻게 처리됐는지 측정하는 기능을 추가했다.
서로 다른 뉴스지만 공통적인 문제를 다루고 있다.
Agent의 실행 능력이 커지면서 기존 시스템의 처리량과 업무 완료 과정이 새로운 병목으로 등장하고 있다는 것이다.
이번 주에는 이 변화를 중심으로 정리해 보려고 한다.
1. 지난주 주요 뉴스
2026.11.02 — OpenAI, Agent 규모의 병렬 개발을 위한 Git Backend 'Pando' 공개
OpenAI가 내부 Git 저장소 시스템을 확장하기 위해 개발한 Pando의 아키텍처와 운영 성과를 공개했다.
Pando는 Git 프로토콜과 기존 클라이언트의 호환성을 유지하면서, 서로 다른 Branch에 대한 동시 Push와 대규모 Fetch를 효율적으로 처리하도록 설계됐다. OpenAI에 따르면 Codex 활용이 늘어나면서 개발자 한 명이 동시에 여러 작업을 수행하고, 각각의 작업이 별도 Branch와 CI 실행을 생성하기 시작했다.
그 결과 기존 Monorepo 운영환경에서는 Push, Fetch, Merge 작업의 처리 지연과 실패가 발생했다.
OpenAI는 Pando를 적용한 이후 내부 운영환경에서 Push 지연시간의 중앙값을 기존 대비 약 5분의 1 수준으로 줄였으며, 현재 하루 약 1PB에 가까운 Git 데이터를 전송하고 있다고 설명했다.
Pando의 핵심 기술은 Branch 단위의 동시성 처리와 Git Packfile 재사용이다.특히 전체 Repository의 모든 Branch가 하나의 시점에서 일관된 상태를 보여야 한다는 강한 제약을 완화하고, 개별 Branch에서 필요한 일관성을 보존하는 방식으로 확장성을 확보했다.
이는 모든 기업이 Git 서버를 새로 구축해야 한다는 의미는 아니다. Pando는 OpenAI 내부에서 운영되는 특수한 규모의 시스템이다.
하지만 Agent가 만들어내는 개발 작업량이 늘어나면 코드 생성 속도가 아니라 Source Control, CI/CD, Merge 처리량이 생산성의 한계가 될 수도 있다는 점을 보여주는 사례다.
출처: OpenAI — Scaling Git at OpenAI
2026.11.03 — Microsoft, SharePoint 전용 MCP Tool 60개 이상 공개
Microsoft가 Work IQ의 SharePoint Tool을 Public Preview로 제공하기 시작했다.
Work IQ MCP Server를 통해 Agent가 SharePoint의 파일, 폴더, 목록, 승인, 버전 관리 등 60개 이상의 네이티브 작업을 수행할 수 있도록 지원한다. 흥미로운 부분은 Tool 설계 방식이다.
기존에는 범용 API를 연결한 후 Agent가 어떤 API를 어떤 순서로 호출해야 하는지 추론하는 경우가 많았다.
Microsoft는 SharePoint의 업무 기능 자체를 Agent 친화적인 Tool로 제공하고, 런타임에 필요한 경로와 Schema를 검색하도록 만들었다. 모든 Tool을 Model Context에 한꺼번에 넣는 방식이 아니라, 적은 수의 공통 동작과 실행 시 발견하는 경로를 조합한다.
Microsoft의 내부 평가에서는 기존 70.1%였던 Task Pass Rate가 84.6%로 개선됐고, Token 사용량은 16% 감소했다고 한다.
이는 특정 평가 시나리오의 결과이며 일반적인 운영환경의 성능을 보장하지는 않는다.
또한 WorkIQ.Read와 WorkIQ.Act를 분리해 조회와 변경 권한을 구분하고, 실제 실행은 사용자의 SharePoint 권한과 관리자 정책에 따르도록 설계했다. MCP Server의 수를 늘리는 것보다, 업무 기능을 Agent가 정확히 호출할 수 있도록 설계하는 것이 중요하다는 사례로 볼 수 있다.
출처: Microsoft — Introducing SharePoint tools in Work IQ
2026.11.03 — Snowflake, Business Ontology와 Cortex AI Gateway 확대 발표
Snowflake가 Expedition 2026에서 Business Ontology와 Cortex AI Gateway의 새로운 기능을 공개했다.
Business Ontology는 조직의 업무 용어와 공식적인 데이터 정의를 중앙에서 관리하고, Agent가 승인된 의미를 공통으로 사용하도록 설계한 기능이다.
예를 들어 영업팀과 재무팀이 동일한 매출 데이터를 사용하더라도 '순매출'의 계산 기준이 다르면 서로 다른 결과를 만들어낼 수 있다.
Agent가 각자 문서를 해석해 답을 만드는 방식에서는 이런 차이가 그대로 남는다.
Snowflake는 업무 용어의 정의와 담당자, 연결된 데이터 자산을 관리하고 Agent가 이를 참조하도록 하는 방향을 제시했다.
Cortex AI Gateway는 Agent가 사용하는 Model과 MCP Tool, 접근 정책, 실행 비용을 통합 관리한다.
발표된 기능들은 제공 단계가 서로 다르다. Gateway의 일부 관측·비용 관리 기능은 일반 제공 중이지만, MCP Governance는 Public Preview이며 Business Ontology와 일부 고급 실행 분석 기능은 출시 예정 또는 Private Preview 단계다.
여기서 중요한 것은 단순한 데이터 검색이 아니다.
Agent가 사용하는 업무 정보의 의미와 실행 정책을 조직이 공통으로 관리하려 한다는 점이다.
출처: Snowflake — Business Ontology & Cortex AI Gateway
2026.11.04 — OpenAI, Pierre 인수 계획 발표…Codex의 Git Workflow 강화
OpenAI가 개발자 도구 기업인 Pierre Computer Company의 인수 계획을 발표했다.
Pierre는 Code Storage와 오픈소스 개발자 도구인 Trees, Diffs 등을 개발한 기업이다.
흥미롭게도 Codex App에서 파일을 탐색하거나 코드 변경 사항을 리뷰할 때 사용하는 일부 기능에는 이미 Pierre의 라이브러리가 적용되어 있었다.
OpenAI는 이번 인수를 통해 단순한 코드 생성 기능을 넘어 Git 기반의 저장, 변경 이력, 리뷰 작업을 Codex에 더 깊이 결합하려는 방향을 제시했다. 특히 앞서 발표한 Pando와 연결해서 보면 의미가 있다.
Pando가 대규모 Agent가 생산한 코드를 저장하고 전달하는 Backend 문제를 해결한다면, Pierre의 도구는 그 코드를 사람이 이해하고 검토하는 Developer Experience 문제를 다룬다.
Agent가 코드를 많이 작성하는 것만으로는 개발 업무가 끝나지 않는다.
변경된 코드를 탐색하고, 비교하고, 충돌을 해결하고, 최종적으로 배포 가능한 상태까지 만들어야 한다.
OpenAI는 그 과정 전체를 Codex의 활용 범위 안으로 가져오려는 것으로 보인다.
다만 인수는 아직 완료된 거래가 아니며, 규제 승인 등 종료 조건이 남아 있다.
출처: OpenAI — OpenAI to acquire Pierre
2026.11.05 — GitHub, Copilot 코드 리뷰의 실제 반영률 측정 기능 추가
GitHub가 Copilot Usage Metrics API에 코드 리뷰 후속 처리 지표를 추가했다.
기존에는 Copilot이 얼마나 자주 코드 리뷰를 수행했는지, 제안된 수정 사항을 몇 번 적용했는지 같은 사용량 지표가 중심이었다.
이번에는 조금 다른 지표가 등장했다.
total_comments_evaluated와 total_comments_addressed를 통해 Copilot이 남긴 코드 리뷰 의견 중 개발자가 실제로 대응한 비율을 측정할 수 있다.
수정 제안을 직접 적용하거나, 코드를 수정하거나, Copilot에게 수정 작업을 요청하거나, 후속 PR에서 처리하겠다고 답변한 경우 등이 포함된다. 또한 Copilot 리뷰 이후 사람이 추가 변경을 요청하지 않고 Merge된 PR 수도 확인할 수 있다. 다만 Addressed Rate가 코드 품질 개선이나 문제 해결의 성공률을 의미하지는 않는다.
나중에 수정하겠다는 답변도 대응한 것으로 집계되며, Bot이 생성한 PR에 대해서는 평가 범위에 제한이 있다.
그럼에도 중요한 변화가 있다.
GitHub가 Agent의 사용 횟수에서 한 단계 나아가 Agent가 업무에 제공한 결과를 사람이 어떻게 받아들이고 처리했는지 측정하기 시작했다는 점이다. Enterprise AX에서 Agent의 기여도를 평가할 때 참고할 만한 방향이다.
출처: GitHub — Usage metrics API adds code review details and addressed rate
2. 이번 주에 남긴 메모
Agent가 빨라진 만큼 사람과 시스템도 빨라져야 할까?
이번 주에는 OpenAI의 Pando 발표를 보면서 이 질문이 가장 먼저 떠올랐다.
지금까지 Agent의 생산성을 높이는 방법을 생각할 때는 주로 Model 성능이나 Token 비용에 집중했다.
더 좋은 Model을 선택하고, Context를 정리하고, 불필요한 Tool Call을 줄이는 방식이다.
그런데 Agent가 실제로 빠르게 일을 처리하기 시작하면 다른 문제가 생긴다.
예를 들어 개발자 한 명이 하루에 두 개의 기능을 개발하던 조직이 있다고 하자.
Agent를 활용하면서 개발자는 동시에 다섯 개의 기능 개발을 진행할 수 있게 됐다.
처음에는 생산성이 크게 높아진 것처럼 보인다.
그런데 다섯 개의 Branch가 생성되고, 각각 CI를 실행하며, 코드 리뷰와 Merge를 기다리는 상황이 발생한다.
그중 일부는 같은 파일을 수정해 충돌이 발생할 수도 있다.
결국 개발자가 직접 코드를 작성하는 시간은 줄었지만 코드 변경을 검토하고 통합하는 시간이 늘어날 수 있다.
OpenAI의 Pando는 이런 현상이 대규모 운영환경에서 실제 인프라 문제로 이어질 수 있음을 보여준다.
Multi-Agent도 같은 문제를 가지고 있다
Multi-Agent를 구성하면 여러 Agent가 동시에 작업하므로 처리시간이 줄어들 것으로 기대하기 쉽다.
하지만 모든 업무가 병렬화에 적합한 것은 아니다.
Agent A가 만든 결과를 Agent B가 기다려야 한다면 병렬 실행의 이점은 제한된다.
여러 Agent가 동일한 Repository나 Database를 수정한다면 충돌과 재검증 비용이 증가할 수 있다.
Agent가 다섯 개라고 해서 처리량이 다섯 배가 되는 것은 아니다.
오히려 업무를 나누고 다시 통합하는 과정이 새로운 병목이 될 수 있다.
11월 초 Reddit의 r/LocalLLaMA에서도 여러 날에 걸쳐 개발·테스트·수정 과정을 반복할 수 있는 장기 실행 Agent Harness를 어떻게 선택할지 묻는 논의가 있었다.
댓글에서는 Codex, Claude Code, Pi, 지속적인 Terminal Session 관리 도구 등이 언급됐다. 개별 사용자들의 경험이므로 객관적인 성능 비교로 볼 수는 없지만, 관심사가 단일 모델의 응답 능력에서 장시간 실행 상태와 작업 관리로 옮겨가는 모습은 흥미롭다.
참고: Reddit — Long-running autonomous coding harness discussion
3. 뉴스에서 드러난 핵심 변화에 대한 해석
Agent 성능의 병목이 Model 밖으로 이동하고 있다
이번 주의 발표를 연결해 보면 흥미로운 점이 있다.
OpenAI는 Git 저장소의 처리량을 높이고 있다.
Microsoft는 Agent가 SharePoint 업무를 더 적은 시행착오로 수행하도록 Tool Interface를 개선했다.
Snowflake는 여러 Agent가 공통으로 사용하는 업무 정의와 정책을 관리한다.
GitHub는 Agent가 생성한 리뷰 의견이 실제 개발 과정에서 어떻게 처리됐는지 측정하기 시작했다.
서로 다른 영역이지만 공통적으로 Model 자체의 추론 능력을 개선하는 기술은 아니다.
오히려 Model이 일을 수행하는 주변 시스템을 개선하는 기술에 가깝다.
이를 구성요소별로 나눠 보면 다음과 같다.
| 구성요소 | 주요 과제 |
| Agent / Model | 업무를 판단하고 실행할 수 있는가 |
| MCP / Tool Interface | 필요한 업무 기능을 정확하게 호출하는가 |
| Business Context | 조직의 데이터와 업무 정의를 일관되게 이해하는가 |
| Execution Infrastructure | 많은 작업을 동시에 안정적으로 처리하는가 |
| Review / Integration | 생성된 결과를 검토하고 통합할 수 있는가 |
| Observability / Evaluation | 실제 성과와 병목을 확인할 수 있는가 |
지난주에는 Context와 Orchestration을 잘 설계하면 Agent의 실행 비용을 줄일 수 있다는 이야기를 했다.
이번 주에는 한 단계 더 나아가 Agent의 처리량과 조직의 처리량을 구분해야 한다는 생각이 들었다.
처리량이 늘어나면 새로운 대기열이 생긴다
이는 기존 시스템 설계에서 익숙한 문제다.
서버의 처리 속도를 높여도 Database가 병목이면 전체 서비스 성능은 일정 수준 이상 개선되지 않는다.
네트워크 대역폭을 높여도 Storage I/O가 부족하면 체감 성능이 크게 달라지지 않는다.
Agent 역시 비슷하다.
코드 생성 시간이 줄어들어도 CI 실행과 코드 리뷰가 느리다면 전체 개발 리드타임은 줄지 않을 수 있다.
문서를 작성하는 속도가 빨라져도 승인 대기 시간이 그대로라면 업무가 완료되는 시점은 크게 달라지지 않는다.
따라서 Agent 생산성을 평가할 때는 개별 실행 시간과 End-to-End 처리시간을 구분해야 한다.
Agent Execution Time과 Business Cycle Time은 같은 지표가 아니다.
Agent의 결과물도 결국 기존 시스템의 관리 대상이 된다
이번 GitHub와 OpenAI 발표를 보면 Agent가 생성한 결과물은 점점 기존의 소프트웨어 개발 생명주기 안에 들어오고 있다.
코드는 Git의 변경 이력으로 관리되고, PR을 통해 리뷰받고, CI/CD를 통과한 뒤 배포된다.
Agent가 만들었다고 해서 이러한 과정을 생략할 수는 없다.
오히려 작업량이 증가한다면 기존의 검증과 변경 관리 체계가 더 큰 부하를 받게 된다.
따라서 Agent를 기업 업무에 적용할수록 새로운 Agent 플랫폼뿐 아니라 기존 IT 시스템이 얼마나 많은 자동화 작업을 처리할 수 있는지도 함께 살펴봐야 할 것 같다.
4. 이번 주 결론
이번 주에는 Agent의 실행량이 증가하면서 기존 개발·업무 시스템에 새로운 부하가 발생하기 시작했다는 점이 눈에 들어왔다.
OpenAI는 Agent의 병렬 개발이 증가하자 Git Backend를 새로 설계했다.
Microsoft는 Agent가 더 정확하고 효율적으로 업무를 수행할 수 있도록 SharePoint 기능을 MCP Tool로 제공하기 시작했다.
Snowflake는 여러 Agent가 승인된 업무 정의와 정책을 공통으로 사용하도록 만들고 있다.
GitHub는 Agent가 남긴 코드 리뷰 의견이 실제로 어떻게 처리됐는지를 측정하기 시작했다.
OpenAI의 Pierre 인수 계획 역시 Agent가 생성한 코드의 저장과 리뷰, 통합 과정을 강화하려는 흐름으로 볼 수 있다.
이 발표들을 연결해 보면 하나의 질문이 남는다.
Agent가 생산하는 업무량을 조직이 실제로 처리할 수 있는가?
앞으로 AI Agent의 성능이 계속 좋아진다면 업무를 생성하거나 수행하는 데 필요한 시간은 더욱 줄어들 수 있다.
하지만 그 업무를 검증하고 승인하고 다음 시스템으로 전달하는 과정이 그대로라면 전체 생산성 향상에는 한계가 있을 것이다.
그래서 이번 주에는 이렇게 정리하고 싶다.
Agent가 만드는 생산성과 조직이 완성하는 생산성은 다르다. AX는 그 둘 사이의 병목을 없애는 일이다.
지난주에는 Agent가 더 효율적으로 일하도록 Context와 Orchestration을 설계하는 것이 중요하다고 생각했다.
이번 주에는 그 효율이 실제 조직의 처리량으로 이어지는지 확인해야 한다는 생각이 들었다.
Agent가 일을 빨리 끝내도 조직의 다음 단계에서 대기해야 한다면, 결국 자동화의 효과는 그 지점에서 멈춘다.
따라서 AX에서는 Agent의 성능뿐 아니라 기존 시스템의 처리량, 승인 구조, 변경 관리, 검증 과정까지 함께 살펴봐야 한다.
AI는 실행을 가속하지만, AX는 그 실행이 조직 전체의 성과로 이어지도록 만드는 일이다.
이번 주의 키워드는 Agent-scale Execution — 조직이 감당할 수 있는 실행과 처리량이다.