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

기간: 2026.09.27 ~ 2026.10.03

이번 주는 지난 몇 주의 흐름에서 한 단계 더 넘어갔다. 이전에는 Agent의 연결(MCP), Identity, Runtime이 중심이었다면, 이번 주에는 Agent가 아예 ‘계속 맡아서 처리하는 업무 주체’로 제품화되는 모습이 선명해졌다.

1. 지난주 주요 뉴스

• 2026.09.29 — OpenAI, 24/7 상시 동작 Agent ‘Dots’ 공개
  OpenAI가 DevDay 2026에서 Dots를 공개했다. Dots는 대화를 한 번 처리하고 종료되는 Agent가 아니라 자체 Cloud Computer와 Browser를 가지고 계속 업무를 수행하는 Always-on Agent다. 연결된 4,000개 이상의 앱을 활용해 여러 프로젝트를 동시에 진행하고, 사람이 요청하지 않은 시간에도 읽기 전용 범위에서 필요한 정보를 확인하며 작업을 준비할 수 있다. 기업용 Specialist Dot에는 별도 Identity·Credential·System Access를 부여하는 구조도 제시됐다. OpenAI가 이를 단순한 Assistant가 아니라 “ongoing responsibility를 맡는 Agent”로 정의했다는 점이 특히 눈에 띈다. OpenAI
• 2026.09.29 — OpenAI, GPT-6.1 Sol 공개…Agent 경쟁에 ‘Cost per Task’ 본격 등장
  GPT-6.1 Sol은 Agentic Coding, Computer Use, Professional Work에서 Astra에 가까운 성능을 제공하면서 표준 입출력 Token 가격은 Astra의 약 1/5 수준으로 설계됐다. OpenAI는 이번 발표에서 단순 Token 가격보다 AutomationBench나 Agents’ Last Exam 같은 장기 업무 평가에서 Task 하나를 끝내는 비용을 적극적으로 제시했다. Coding Agent가 복잡하고 오래 걸리는 작업을 수행하기 시작하면서 모델 경쟁도 최고 Benchmark 점수보다는 “업무 하나를 얼마에 완료할 수 있는가” 쪽으로 이동하는 모습이다. OpenAI
• 2026.09.30 — Google, Gemini 4 Argon 공개…1M Output Token으로 ‘한 번의 긴 실행’ 확대
  Google은 장시간 Software Engineering, 금융·법률 업무, Cyber Defense를 겨냥한 Gemini 4 Argon을 발표했다. 최대 Output Token을 기존 64K에서 1M으로 크게 늘렸고, Google 내부에서는 Agent들이 대규모 코드 Migration과 Data Center Memory Optimization 같은 장시간 작업에 사용되고 있다고 밝혔다. 다만 Cybersecurity 능력이 강한 만큼 현재는 신뢰된 Defender를 중심으로 제한 제공하고 있다. Context가 길어진다는 의미를 넘어 하나의 Agent trajectory 자체가 훨씬 길어지고 있다는 변화로 볼 수 있다. blog.google
• 2026.10.01 — GitHub Copilot, Agent에게 ‘반복 업무’와 Merge까지 맡기기 시작
  GitHub는 September Copilot 업데이트에서 Agent Automations를 통해 시간·일·주 단위 반복 작업을 예약할 수 있도록 하고, Agent Merge를 이용해 Review Feedback, Failed Check, Merge Conflict, Workflow Rerun까지 처리하도록 했다. Agent가 필요에 따라 새로운 Session을 생성하고 계층적으로 관리하는 기능도 추가됐다. Coding Agent가 “코드를 작성하는 Tool”에서 개발 Workflow의 일부를 계속 책임지는 Worker로 변하는 모습이다. The GitHub Blog
• 2026.10.01 — DigitalOcean, Agent Runtime을 월 구독 상품 ‘Agent Droplets’로 패키징
  DigitalOcean은 Agent 실행에 필요한 MicroVM Sandbox, Inference, Persistent Memory, Session Storage, 16,000개 이상의 Tool 접근을 하나의 Agent Droplet 상품으로 묶었다. Pro는 월 50달러, Team은 월 200달러이며 Agent 수나 Seat 수가 아니라 실제 Runtime Resource를 기준으로 비용을 관리한다. Agent Infrastructure가 더 이상 별도로 조립해야 하는 특수 Architecture가 아니라 일반 Cloud 상품처럼 구매 가능한 단위가 되기 시작했다는 점이 의미 있다. 디지털오션 투자자 관계

---

2. 이번 주에 남긴 메모

Agent의 단위가 ‘요청’에서 ‘책임’으로 바뀌고 있다

이번 주에는 이 변화가 가장 크게 느껴졌다.

지금까지 AI를 사용할 때 기본 단위는 Request였다.

질문을 하면 답하고,
코드를 요청하면 만들고,
문서를 요청하면 작성했다.

그런데 이번 주 발표들을 보면 조금 다르다.

Dots는 프로젝트를 계속 지켜본다.
GitHub Agent는 반복 업무를 예약하고 PR이 Merge될 때까지 따라간다.
Gemini Argon은 한 번의 Workflow를 훨씬 길게 수행한다.

사용자가 매번

“이것 좀 해줘.”

라고 요청하는 것이 아니라,

“이 업무를 네가 맡아.”

라고 말하는 방향이다.

이 둘은 생각보다 큰 차이가 있다.

Task를 실행하는 AI와 Responsibility를 가지는 Agent는 운영 방식이 완전히 다르다.

책임을 맡기기 시작하면 State가 필요하고, Context가 필요하고, 권한과 예산이 필요하고, 실패했을 때 언제 사람에게 넘길지도 정의해야 한다.

그래서 지난주까지 계속 이야기했던 Runtime, Identity, Approval 같은 요소들이 갑자기 하나로 연결되는 느낌이다.

일부 OpenAI 커뮤니티 반응에서도 Dots의 능력 자체보다는 장시간 Agent의 사용량 제한, 비용, 그리고 기존 자동화 시스템 대신 Agent에게 어느 정도까지 맡길 수 있는지가 바로 논쟁거리로 등장했다. 아직 초기 사용자 반응이라 대표성은 제한적이지만, 관심사가 단순 Benchmark보다 운영 통제와 경제성으로 이동하고 있다는 신호로는 흥미롭다. Reddit

---

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

지난 몇 주의 흐름을 연결하면 Agent Stack이 조금씩 완성되어 가는 모습이 보인다.

처음에는 Tool 연결이 중요했다.

그래서 MCP가 빠르게 확산됐다.

그다음에는

Agent Identity → Permission → Sandbox → Runtime

문제가 앞으로 나왔다.

그리고 이번 주에는 그 인프라 위에서 돌아가는 Agent가 지속적인 업무 주체로 제품화되기 시작했다.

흐름을 단순화하면 이렇게 볼 수 있다.

Model → Agent → Tool/MCP → Runtime → Persistent Agent → Responsibility

여기서 중요한 변화가 하나 있다.

MCP 자체는 점점 차별화 요소가 아니라 기반 배관(Plumbing)에 가까워지고 있다.

Tool 연결이 가능하다는 사실 자체보다

• 얼마나 오래 실행할 수 있는가
• Context를 얼마나 유지할 수 있는가
• 여러 업무를 병렬로 관리할 수 있는가
• 비용을 어디까지 허용할 것인가
• 언제 사람이 개입할 것인가

가 더 중요한 경쟁 요소가 되어간다.

DigitalOcean의 Agent Droplets도 그래서 흥미롭다. Sandbox, Memory, Session Storage, Tool Access를 하나의 상품으로 묶었다는 것은 시장이 Agent Runtime의 기본 구성요소에 대해 어느 정도 합의하기 시작했다는 뜻으로 볼 수 있다. 디지털오션 투자자 관계

---

4. AX 관점 분석

AI와 AX의 차이가 더 분명해지고 있다

이번 주 흐름을 보면 AI와 AX를 이렇게 구분해볼 수 있을 것 같다.

AI는 일을 잘하는 능력이고,
Agent는 일을 실행하는 주체이며,
AX는 일을 맡길 수 있도록 조직을 설계하는 것이다.

Dots 같은 Agent가 실제 회사 업무를 맡는다고 생각하면 바로 여러 문제가 생긴다.

예를 들어 매주 월요일 영업 현황 보고서를 만드는 Agent가 있다고 하자.

단순 AI라면 사람이 데이터를 주고 보고서를 요청하면 된다.

Agent라면 조금 다르다.

CRM을 읽고,
매주 정해진 시간에 실행하고,
지난주 데이터를 기억하고,
이상치를 발견하면 추가 조사를 하고,
보고서를 작성하고,
필요하면 담당자에게 질문하고,
완료 결과를 전달해야 한다.

그 순간 Architecture는 자연스럽게 다음처럼 변한다.

Business Responsibility
        │
        ▼
      Agent
        │
 ┌──────┼────────┐
 ▼      ▼        ▼
State  Policy   Budget
 │       │        │
 └───────┼────────┘
         ▼
      Runtime
         │
  ┌──────┼───────┐
  ▼      ▼       ▼
 MCP    API   Computer

여기서 Model은 중요한 요소지만 전체 구조 중 하나일 뿐이다.

 

MCP는 ‘연결’ 역할에 집중하게 될 가능성이 높다

MCP가 처음 등장했을 때는 Agent Architecture의 중심처럼 보였다.

하지만 최근 흐름을 보면 역할이 조금 명확해지고 있다.

MCP는

“Agent가 어떤 기능을 사용할 수 있는가”

를 해결한다.

반면 기업에서 실제로 더 어려운 문제는

“언제, 어떤 Identity로, 어떤 비용 범위에서, 몇 번까지 실행할 수 있는가”

다.

즉 Enterprise Agent Architecture에서는

MCP = Tool Interface

이고,

그 위에

Policy / Runtime / Workflow / Observability

가 올라가는 구조가 자연스러워 보인다.

MCP가 덜 중요해진 것이 아니라, 오히려 성공적으로 표준화되면서 Infrastructure의 한 계층으로 내려가고 있는 것에 가깝다.

 

Multi-Agent도 ‘Agent 수’보다 업무 분해가 중요해진다

OpenAI는 장기적으로 여러 Dots가 함께 일하는 구조를 이야기하고 있고, GitHub에서는 Agent가 필요에 따라 새로운 Session을 만들고 계층적으로 관리할 수 있게 했다. OpenAI

이 흐름을 보면 Multi-Agent 역시 조금 현실적으로 봐야 할 것 같다.

예전에는 구조를 먼저 만들었다.

Planner
 ├─ Research Agent
 ├─ Coding Agent
 └─ Review Agent

하지만 실제 기업 업무에서는 반대로 접근하는 편이 맞아 보인다.

먼저 Responsibility를 분리하고, 그 책임을 별도의 Agent가 맡을 이유가 있을 때 Agent를 분리하는 것이다.

예를 들어

고객 VOC 감시
      ↓
수정 범위 판단
      ↓
개발
      ↓
테스트
      ↓
PR 생성

이 Workflow에서 모든 단계가 하나의 Context 안에서 충분히 처리된다면 Single Agent가 더 단순하다.

반대로 보안 권한이나 업무 책임이 완전히 다르다면 Agent를 분리할 이유가 생긴다.

그래서 Multi-Agent Architecture의 기준도

“Agent를 몇 개 둘까?”

보다

“책임을 어디에서 나눠야 할까?”

가 되어야 할 것 같다.

 

Agent 비용의 기준도 Token에서 ‘업무’로 바뀌고 있다

GPT-6.1 Sol 발표에서 특히 눈에 띈 부분이다.

OpenAI는 Token 가격뿐 아니라 Cost per Task를 적극적으로 비교하기 시작했다. OpenAI

이것은 Enterprise 입장에서 훨씬 현실적인 지표다.

예를 들어 보고서 하나를 완성하는데

• Model Call 25회
• Web Search 10회
• MCP Tool Call 40회
• Sandbox 실행 30분
• Human Review 10분

이 필요했다면

Token 비용만 계산해서는 실제 ROI를 알기 어렵다.

결국 AX에서 중요해질 지표는

Cost per Completed Task

그리고 한 단계 더 나아가

Cost per Business Outcome

에 가까워질 것이다.

DigitalOcean이 Runtime·Inference·Memory·Tool을 한 가격 체계로 묶으려는 것도 이런 변화와 연결된다. 디지털오션 투자자 관계

 

---

5. 이번 주 결론

지난 몇 주 동안 Agent 기술의 기반이 빠르게 만들어졌다.

MCP로 연결하고,
Identity로 실행 주체를 구분하고,
Sandbox와 Runtime으로 행동 범위를 통제했다.

이번 주에는 그 위에서 한 단계 더 나아갔다.

Agent가 단순히 명령을 수행하는 것이 아니라 업무를 계속 맡는 존재로 바뀌기 시작했다.

OpenAI는 이를 Always-on Agent로 제품화했고, GitHub는 반복적인 개발 업무를 Agent에게 넘기기 시작했다. Google은 한 번의 Agent 실행 자체를 훨씬 길게 만들고 있으며, Cloud 사업자들은 Agent Runtime을 하나의 표준 상품처럼 패키징하기 시작했다. OpenAI

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

Agent 시대의 다음 경쟁 단위는 ‘누가 더 좋은 답을 만드는가’가 아니라, ‘누가 업무를 끝까지 맡아 처리할 수 있는가’가 될 것 같다.

그리고 AX에서는 한 단계 더 생각해야 한다.

Agent에게 일을 맡기는 순간 조직은 그 Agent에게 책임 범위, 권한, 예산, 완료 조건, 사람에게 돌려보내는 조건까지 함께 정의해야 한다.

AI를 사용하는 것과
AI에게 일을 맡기는 것은 꽤 다른 문제다.

이번 주의 키워드는 Responsibility다.