kyu_ios_dev.log

Paseo로 여러 AI 코딩 에이전트를 한 팀처럼 쓰는 방법

Mon, 21 Sep 2026 06:07:08 GMT

Paseo로 여러 AI 코딩 에이전트를 한 팀처럼 쓰는 방법

Claude는 설계하고, Codex는 구현하고, 다른 Agent는 리뷰하게 만들기

Codex를 쓰다가 Claude Code도 같이 쓰고 싶을 때가 있습니다.

단순히 두 터미널을 띄워 놓는 것은 어렵지 않습니다.

문제는 역할을 나누기 시작할 때입니다.

Claude
→ 설계

Codex
→ 구현

Claude
→ 코드 리뷰

Codex
→ 테스트

Gemini
→ 자료 조사

각 Agent에게 Context를 다시 전달하고, 어느 Agent가 무엇을 하고 있는지 확인하고, 결과를 다시 모아서 다음 Agent에게 넘겨줘야 합니다.

Agent가 두세 개를 넘어가면 사람이 AI 사이에서 메시지를 전달하는 역할을 하게 됩니다.

Paseo는 이 부분을 관리하기 위한 Multi-Agent Orchestration 도구입니다.

Paseo 자체가 새로운 AI 모델을 제공하는 것은 아닙니다.

이미 사용하고 있는:

Claude Code

Codex

OpenCode

Gemini CLI

GitHub Copilot

그 외 ACP Agent

를 하나의 Workspace에서 실행하고 관리합니다.

기존 CLI의 로그인 정보, 설정, Skill, MCP Server도 그대로 사용할 수 있습니다.

1. Paseo가 필요한 상황부터 보자

Agent를 하나만 쓴다면 Paseo가 꼭 필요한 것은 아닙니다.

예를 들어:

Codex

"이 프로젝트의 로그인 기능을 구현해줘."

정도로 충분하다면 Codex 자체가 더 간단합니다.

Paseo가 재미있어지는 것은 역할이 나뉘기 시작할 때입니다.

Main Agent
     │
     ├─ Architecture Agent
     │
     ├─ Implementation Agent
     │
     ├─ QA Agent
     │
     └─ Review Agent

그리고 이 Agent들이 꼭 같은 모델일 필요도 없습니다.

Architecture
→ Claude

Implementation
→ Codex

Research
→ Gemini

QA
→ Codex

처럼 Provider까지 나눌 수 있습니다.

Paseo 공식 Orchestration 기능도 서로 다른 Provider와 Model을 사용하는 Agent에게 작업을 위임하고, Agent끼리 메시지를 보내고, 진행상태를 확인하고, 결과를 다시 받아오는 구조를 지원합니다.

2. 먼저 이해해야 할 것 — Paseo는 AI 모델이 아니다

Paseo를 처음 보면 또 하나의 Coding Agent처럼 느껴질 수 있습니다.

하지만 구조는 이렇습니다.

             Paseo
               │
     ┌─────────┼─────────┐
     ↓         ↓         ↓
  Claude     Codex     Gemini
   Code                 CLI

Paseo가 직접 코드를 생각해서 만드는 것이 아니라,

각 Coding Agent를 실행하고 연결하고 관리하는 Control Layer입니다.

공식 문서에서도 Paseo는 기존 Agent CLI를 subprocess로 실행하며, 자체 Coding Agent를 제공하지 않는다고 설명합니다.

그래서 먼저 사용할 Agent가 설치되어 있어야 합니다.

3. 가장 쉬운 설치 방법은 Desktop App이다

처음 사용한다면 CLI보다 Desktop App부터 시작하는 것이 편합니다.

Paseo 공식 문서에서도 Desktop App을 권장 방식으로 안내하고 있습니다.

Desktop App에는 Paseo daemon이 포함되어 있어서 별도의 서버를 먼저 구성할 필요가 없습니다.

설치는 공식 다운로드 페이지에서 하면 됩니다.

Paseo를 실행하면 기본 구조는:

Paseo Desktop
      ↓
Local Daemon
      ↓
Claude / Codex / 기타 Agent

가 됩니다.

즉 Agent들은 자신의 Mac에서 실행됩니다.

4. CLI로 설치하고 싶다면

터미널 중심으로 사용한다면 Paseo CLI도 사용할 수 있습니다.

npm install -g @getpaseo/cli

설치 후:

paseo

를 실행합니다.

Paseo daemon이 로컬에서 시작됩니다.

Desktop App을 사용한다면 이 작업을 직접 할 필요가 없습니다.

5. Claude Code와 Codex를 먼저 설치한다

중요합니다.

Paseo를 설치했다고 Claude나 Codex가 설치되는 것은 아닙니다.

각 CLI를 별도로 설치하고 인증해야 합니다.

구조는:

Mac

├─ Claude Code
├─ Codex
└─ Paseo

입니다.

Paseo는 설치되어 있는 Native Provider를 찾아서 사용할 수 있습니다.

현재 Native 지원 Provider에는 Claude Code, Codex, OpenCode, Pi 등이 있으며 Gemini CLI나 GitHub Copilot 등은 ACP Catalog를 통해 추가할 수 있습니다.

6. 먼저 각 Agent가 독립적으로 동작하는지 확인한다

Paseo부터 설정하기 전에 각각의 CLI가 정상적으로 동작하는지 확인하는 게 좋습니다.

예를 들어:

claude

그리고:

codex

를 직접 실행합니다.

둘 다 프로젝트를 읽고 정상적으로 대답한다면 Paseo 쪽으로 넘어갑니다.

문제가 생겼을 때:

Paseo 문제인가?

Claude 인증 문제인가?

Codex 설정 문제인가?

를 구분하기 쉬워집니다.

7. 프로젝트를 Paseo Workspace로 연다

Paseo의 중요한 개념 중 하나가 Workspace입니다.

쉽게 말하면:

Agent들이 함께 작업할 프로젝트 공간

입니다.

예를 들어:

MyApp/
├─ Sources
├─ Tests
├─ Package.swift
└─ MyApp.xcodeproj

가 있다면 이 프로젝트 폴더를 하나의 Workspace로 엽니다.

CLI에서는 이런 식으로 만들 수 있습니다.

paseo workspace create \
  --isolation local \
  --path ~/Projects/MyApp \
  --title MyApp

이제 이 Workspace 안에 여러 Agent를 띄울 수 있습니다.

8. 처음에는 Worktree 없이 시작해도 된다

Paseo에는 Git Worktree 기능도 있습니다.

각 Agent가 독립적으로 코드를 수정해야 한다면:

Main Project

├─ Agent A Worktree
├─ Agent B Worktree
└─ Agent C Worktree

처럼 분리할 수 있습니다.

Paseo가 별도의 Branch와 Directory를 만들어 Agent끼리 같은 파일을 동시에 수정하면서 충돌하는 것을 줄여줍니다.

하지만 처음부터 사용할 필요는 없습니다.

처음에는:

하나의 Workspace
+
여러 Agent

정도로 시작하는 것이 이해하기 쉽습니다.

병렬 구현이 필요해졌을 때 Worktree를 추가하면 됩니다.

9. Paseo에서 가장 먼저 해야 할 것은 Agent Profile 만들기다

Paseo에서 개인적으로 가장 중요한 기능 중 하나가 Agent Profile입니다.

매번:

Claude 선택

모델 선택

Thinking 설정

Permission 설정

을 반복하는 대신 역할별 설정을 저장합니다.

예를 들어:

Planning

Provider
Claude

Reasoning
High

When to use
Architecture 설계, 문제 원인 분석,
구현 전에 방향을 정할 때 사용

Implementation

Provider
Codex

Reasoning
High

When to use
확정된 설계에 따라 실제 코드 수정,
Build와 Test까지 수행

Review

Provider
Claude

Reasoning
Medium

When to use
Diff Review,
Bug 가능성,
불필요한 복잡성,
누락된 테스트 확인

Paseo의 Agent Profile에는 Provider, Model, Mode, Thinking Level과 Feature 설정을 저장할 수 있으며 When to use 메모를 Orchestrator가 읽고 작업에 맞는 Profile을 선택할 수 있습니다.

10. 여기서 말하는 ‘토큰 분배’는 조금 다르다

Paseo가:

Claude 30%

Codex 40%

Gemini 30%

처럼 하나의 Token Pool을 비율로 잘라주는 것은 아닙니다.

대신 비싼 모델을 꼭 필요한 작업에만 사용하도록 역할을 분리하는 방식입니다.

예를 들면:

Architecture
→ Claude / High

Implementation
→ Codex / High

간단한 탐색
→ 저렴한 모델 / Low

Review
→ Claude / Medium

Test
→ Codex / Medium

입니다.

즉:

모든 작업
→ 가장 비싼 모델

이 아니라:

업무 난이도
       ↓
적절한 Agent
       ↓
적절한 Model
       ↓
적절한 Thinking

으로 나누는 겁니다.

실제로 이게 여러 AI 서비스를 같이 사용하는 팀에서 더 현실적인 비용 관리 방식입니다.

11. 이제 Paseo Tools를 켠다

Profile까지 만들었다면 Agent가 다른 Agent를 직접 실행할 수 있게 만듭니다.

Paseo에서:

Settings
→ Host
→ Agents
→ Enable Paseo tools

를 활성화합니다.

기본값은 Off입니다.

활성화한 뒤 새 Agent를 시작하거나 기존 Agent를 Reload하면 Paseo Tool을 사용할 수 있습니다.

이제 Main Agent에게 이렇게 요청할 수 있습니다.

Paseo Profile을 확인해.

이 기능의 Architecture는 Planning Agent에게 분석시키고,

설계가 끝나면 Implementation Agent에게
구현을 맡겨.

마지막으로 Review Agent에게
독립적인 코드 리뷰를 요청해.

모든 결과를 마지막에 하나로 정리해줘.

여기서부터 진짜 Multi-Agent Workflow가 시작됩니다.

12. Agent끼리 실제로 역할을 나눌 수 있다

예를 들어 Main Agent에게:

회원가입 기능을 추가해야 한다.

먼저 Architecture Agent에게
현재 인증 구조와 변경 범위를 분석하게 해.

파일은 수정하지 않는다.

분석이 끝나면 결과를 가져와서 나에게 보여줘.

라고 합니다.

그러면:

Main Agent
      ↓
Planning Agent
      ↓
Repository 분석
      ↓
Architecture 제안
      ↓
Main Agent로 결과 전달

이 됩니다.

그 다음:

승인된 설계를 Implementation Profile을 사용하는
Codex Agent에게 넘겨.

구현하고 관련 Unit Test를 실행해.

로 이어갑니다.

Paseo는 Agent 생성뿐 아니라 Agent에게 추가 Prompt를 보내거나 상태를 조회하고, 완료 결과를 확인하는 Tool을 제공합니다.

13. 병렬 작업은 독립적인 문제에만 사용한다

Multi-Agent라고 무조건 많이 띄우는 것은 좋지 않습니다.

좋은 병렬화:

Agent A
→ 현재 Network 구조 조사

Agent B
→ Test 구조 조사

Agent C
→ 관련 Regression 조사

세 작업은 서로 파일을 수정하지 않습니다.

동시에 실행해도 안전합니다.

Paseo 공식 예제에서도 하나는 Request Path를 추적하고, 하나는 Test를 조사하고, 하나는 Regression을 확인한 뒤 결과를 종합하는 Fan-out Workflow를 예로 들고 있습니다.

반대로:

Agent A
→ LoginViewModel 수정

Agent B
→ LoginViewModel 수정

을 같은 Directory에서 동시에 돌리면 좋지 않습니다.

이럴 때 Worktree를 씁니다.

14. 코드 수정이 병렬이라면 Worktree를 사용한다

예를 들어:

Agent A
→ Network Layer Migration

Agent B
→ SwiftUI 화면 Migration

Agent C
→ Unit Test 추가

를 동시에 진행하고 싶다면 각각 독립 Worktree를 만드는 편이 안전합니다.

구조는:

origin/main
     │
     ├─ feature/network
     │      └─ Codex
     │
     ├─ feature/ui
     │      └─ Codex
     │
     └─ feature/tests
            └─ Claude

처럼 됩니다.

Paseo가 Workspace를 생성할 때 Worktree Isolation을 지정하면 독립 Branch와 Directory를 만들어줍니다.

Git에 익숙하지 않다면 처음부터 이 기능을 사용할 필요는 없습니다.

여러 Agent가 실제 코드를 동시에 수정해야 할 시점에 추가하면 됩니다.

15. Paseo Skill도 있다

Agent에게 매번:

다른 Agent 띄워.

라고 설명할 필요도 없습니다.

Paseo에는 Orchestration Skill이 있습니다.

대표적으로:

/paseo

/paseo-handoff

/paseo-committee

/paseo-advisor

가 있습니다.

/paseo-handoff

현재 작업을
다른 Agent에게 넘기기

/paseo-committee

어려운 문제를
두 Agent에게 독립적으로 분석시키기

/paseo-advisor

현재 구현에 대한
Second Opinion 받기

정도로 이해하면 쉽습니다.

Paseo Settings의 Orchestration Skills에서 설치하거나 CLI에서 설치할 수도 있습니다.

여기까지가 Paseo의 기본 세팅이다

정리하면:

1. Claude / Codex 설치

2. Paseo 설치

3. Project Workspace 생성

4. Agent Profile 생성

5. Paseo Tools 활성화

6. Main Agent 실행

7. 역할별 Subagent 위임

이 정도만 해도 상당히 쓸 만합니다.

이제 실제 개발 Workflow를 만들어보겠습니다.

16. 일반적인 개발팀이라면 이렇게 구성해볼 수 있다

개인적으로 처음 구성한다면 Agent를 너무 많이 만들지 않고 세 개 정도로 시작하는 것이 좋습니다.

                 Main
                  │
        ┌─────────┼─────────┐
        ↓         ↓         ↓
     Planning   Coding    Review
      Claude    Codex      Claude

Planning Agent

역할:

Architecture 분석

영향 범위 조사

작업 계획

대안 비교

파일 수정은 하지 않습니다.

Coding Agent

역할:

실제 구현

Refactoring

Build

Unit Test

Review Agent

역할:

Diff Review

Bug 가능성

Regression

Test 누락

Architecture 위반

중요한 점은 Review Agent가 Implementation Agent와 다른 Context에서 독립적으로 보는 것입니다.

17. Main Agent는 코딩보다 지휘를 담당하게 한다

Main Agent까지 직접 코딩하면 Context가 빠르게 커집니다.

그래서 Main Agent는 가능하면:

요구사항 이해

Agent 선택

Task 분리

결과 수집

충돌 판단

최종 요약

역할에 집중하게 할 수 있습니다.

구조가 이런 형태가 됩니다.

                 Main Agent
                     │
              Task Breakdown
                     │
       ┌─────────────┼─────────────┐
       ↓             ↓             ↓
 Architecture    Implementation   Test
       │             │             │
       └─────────────┼─────────────┘
                     ↓
                   Review
                     ↓
                Main Agent
                     ↓
                 최종 결과

이렇게 하면 하나의 Agent Context가 모든 로그와 코드를 다 먹는 것도 어느 정도 줄일 수 있습니다.

18. iOS 개발에서는 Paseo가 특히 재미있다

iOS 개발 환경에 적용하면 역할을 더 분명하게 나눌 수 있습니다.

예를 들어:

                  Paseo
                    │
       ┌────────────┼────────────┐
       ↓            ↓            ↓
    Claude        Codex       Codex
 Architecture   Implementation   QA
       │            │            │
       │            │      XcodeBuildMCP
       │            │            │
       └────────────┼────────────┘
                    ↓
                 Claude
                  Review

여기서 역할은 이렇게 나눌 수 있습니다.

19. Claude = Architecture와 Review

Claude Agent에는:

현재 Feature 구조를 분석해.

변경이 필요한 Module과 Dependency를 정리해.

바로 코드를 수정하지 말고
구현 계획과 위험요소만 작성해.

를 맡깁니다.

구현이 끝난 뒤에는 별도의 Claude Review Agent를 띄웁니다.

현재 Diff를 독립적으로 Review해.

확인할 것:

- Architecture 위반
- Swift Concurrency 문제
- MainActor 사용
- Retain Cycle
- Error Handling
- 불필요한 복잡성
- Test 누락

파일은 수정하지 말고
문제와 수정 우선순위만 알려줘.

처럼 사용할 수 있습니다.

20. Codex = 실제 구현

Architecture가 확정되면 Codex로 넘깁니다.

Planning Agent의 설계를 기준으로 구현해.

요청한 범위를 벗어난 Refactoring은 하지 마.

기존 Architecture를 유지하고,

완료 후 Build와 관련 Unit Test를 실행해.

변경 파일과 Test 결과를 요약해.

구조는:

Claude
Architecture
    ↓
   Plan
    ↓
Codex
Implementation

입니다.

설계와 구현 Context를 일부러 나눈다는 것이 핵심입니다.

21. Codex + XcodeBuildMCP = Simulator / QA

여기서 iOS에서는 한 단계 더 갈 수 있습니다.

Codex Agent에 XcodeBuildMCP를 연결합니다.

XcodeBuildMCP는 Xcode Project Discovery, Build/Test, Simulator Boot, 앱 설치·실행, Log Capture, Screenshot, UI hierarchy와 UI Automation 같은 기능을 Agent에게 제공합니다. 최근 구현에서는 tap, swipe, type_text 같은 Simulator Interaction도 지원합니다.

그러면 QA Agent 역할을 따로 만들 수 있습니다.

QA Agent
  │
  └─ Codex
       │
       └─ XcodeBuildMCP
              │
              ├─ Build
              ├─ Simulator
              ├─ Launch
              ├─ UI Tree
              ├─ Tap
              ├─ Type
              ├─ Swipe
              ├─ Screenshot
              └─ Logs

이게 iOS 프로젝트에서는 상당히 재미있는 조합입니다.

22. QA Agent Profile을 별도로 만든다

Paseo에 다음 Profile을 추가합니다.

iOS QA

Provider
Codex

Thinking
Medium

When to use

iOS Simulator 실행,
Build/Test,
UI Interaction,
Screenshot,
Regression 확인이 필요한 작업.
XcodeBuildMCP를 우선 활용한다.

이제 Main Agent는:

구현이 끝났으면
iOS QA Profile을 사용해서
Simulator 검증을 실행해.

라고 위임할 수 있습니다.

23. 실제 iOS Workflow는 이렇게 된다

예를 들어 상품 상세 화면을 수정한다고 해보겠습니다.

1단계

Claude:

현재 ProductDetail 구조를 분석하고
변경 계획만 작성.

2단계

Codex:

승인된 Plan을 구현하고
Unit Test 실행.

3단계

QA Codex:

Simulator에서 앱을 실행.

상품 목록 진입.

첫 번째 상품 선택.

상세 화면 확인.

스크롤.

구매 버튼 확인.

Screenshot 저장.

Console Warning과 Crash 확인.

4단계

Claude:

Diff와 QA 결과를 같이 보고
최종 Review.

전체로 보면:

Requirement
    ↓
Claude
Architecture
    ↓
Codex
Implementation
    ↓
Codex + XcodeBuildMCP
Simulator QA
    ↓
Claude
Review
    ↓
Developer

입니다.

24. iPhone Duo QA에도 그대로 확장할 수 있다

최근 이야기했던 iPhone Duo처럼 화면 상태가 많아지는 환경에서는 더 유용합니다.

Closed

Open

Folded

Rotated

상태에서:

Layout

Navigation

Safe Area

ReservedRegion

Scroll

Button Interaction

을 반복해서 확인해야 하기 때문입니다.

Paseo 구조에서는:

Claude
→ Duo Migration 설계

Codex
→ UI Migration 구현

Codex + XcodeBuildMCP
→ Simulator QA

Claude
→ Diff + QA 결과 Review

처럼 역할을 분리할 수 있습니다.

즉 Paseo가 Simulator를 직접 제어하는 것이 아닙니다.

Paseo가 QA 담당 Codex를 관리하고, Codex가 XcodeBuildMCP를 이용해서 Simulator를 제어하는 구조입니다.

이 구분은 중요합니다.

25. QA 결과는 Agent에게 반드시 구조화해서 받는 게 좋다

QA Agent가:

테스트했습니다. 이상 없습니다.

라고 끝내면 의미가 없습니다.

처음부터 Output 형식을 지정합니다.

Scenario

Home → Product → Detail

Simulator

iPhone Duo / iOS 27.1

Result

PASS / FAIL

Checks

Layout
Navigation
Interaction
Warnings
Crash

Evidence

Screenshot Path

Finding

발견된 문제

Recommendation

수정 제안

이렇게 받으면 Main Agent가 결과를 다시 Review Agent에게 전달하기도 쉬워집니다.

26. Agent를 너무 많이 만들면 오히려 손해다

Multi-Agent 이야기를 하면:

Planning Agent

Research Agent

UI Agent

Network Agent

DB Agent

Test Agent

QA Agent

Review Agent

Security Agent

처럼 만들고 싶어집니다.

하지만 이렇게 시작하면 Agent 관리가 새로운 일이 됩니다.

처음에는:

Planning

Implementation

Review

세 개 정도면 충분합니다.

iOS라면:

Planning

Implementation

Simulator QA

Review

정도가 현실적입니다.

독립적인 Reasoning이 필요한 경우에만 Agent를 나누는 편이 좋습니다.

27. Agent보다 Skill이 더 적합한 작업도 있다

반복되는 절차라고 모두 Agent를 만들 필요는 없습니다.

예를 들어:

Release Checklist

Swift 6 Migration Rule

PR 작성 규칙

Lint 실행

Build 명령

같은 작업은 독립적인 Agent보다 Skill이나 Project Instruction이 더 적합할 수 있습니다.

반면:

Architecture 분석

독립 Code Review

Root Cause 조사

Simulator QA

처럼 별도의 Context에서 판단해야 하는 작업은 Agent로 분리할 가치가 있습니다.

기준은:

정해진 절차
→ Skill

독립적인 판단
→ Agent

정도로 시작하면 이해하기 쉽습니다.

28. 보안과 Permission도 Profile별로 나누는 게 좋다

모든 Agent에게 동일한 권한을 줄 필요도 없습니다.

예를 들어 Review Agent는:

Read
→ 허용

Code Write
→ 제한

할 수 있습니다.

Implementation Agent는:

Workspace Write
→ 허용

QA Agent는:

Build
Simulator
Test

정도만 필요할 수 있습니다.

Paseo는 Provider의 Native Sandbox나 Permission Option을 전달할 수 있지만, 공식 문서에서도 이 설정 자체가 Host Security Boundary를 대신하는 것은 아니라고 설명합니다. 민감한 작업이나 신뢰하지 않는 코드라면 Container나 별도 Machine을 사용하는 편이 안전합니다.

29. Paseo를 쓰면 Agent를 휴대폰에서도 확인할 수 있다

Paseo는 Desktop뿐 아니라 Mobile, Web, CLI Client를 제공합니다.

Desktop Agent가 긴 작업을 하고 있다면 휴대폰에서:

Agent 상태 확인

결과 확인

추가 Prompt

작업 중단

같은 작업을 할 수 있습니다.

Paseo는 Local Machine에서 Agent를 실행하고 Client가 daemon에 연결하는 구조이며 Mobile Device도 Pairing할 수 있습니다.

긴 Build나 Test를 많이 하는 개발자에게는 의외로 편한 부분입니다.

30. 처음 Paseo를 도입한다면 이 구성부터 추천한다

처음부터 복잡하게 만들 필요는 없습니다.

Profile 1 — Architect

Claude

High Reasoning

Architecture / Planning

Profile 2 — Developer

Codex

High Reasoning

Implementation

Profile 3 — Reviewer

Claude

Medium Reasoning

Independent Review

iOS라면 하나 더 추가합니다.

Profile 4 — iOS QA

Codex

Medium Reasoning

XcodeBuildMCP
Simulator
Test
Screenshot
Logs

그리고 Main Agent에게 이렇게 말합니다.

Paseo Agent Profile을 확인해.

먼저 Architect에게 이 작업을 분석시켜.

설계가 끝나면 Developer에게 구현을 맡겨.

구현 후 iOS QA Agent가
Build와 Simulator 검증을 수행하게 해.

마지막으로 Reviewer가
Diff와 QA 결과를 독립적으로 검토하게 해.

각 단계 결과를 마지막에 하나로 정리해.

이 정도면 Paseo를 쓰는 이유가 꽤 명확하게 느껴집니다.

31. 가장 중요한 건 Agent 숫자가 아니다

Paseo를 사용한다고 Agent를 많이 띄우는 것이 목적은 아닙니다.

중요한 것은:

누가 계획하는가

누가 구현하는가

누가 검증하는가

누가 최종적으로 책임지는가

를 분리할 수 있다는 점입니다.

특히 모델마다 장점이 조금씩 다르다면:

Claude의 장점
→ Architecture / Review

Codex의 장점
→ Implementation / Tool Execution

XcodeBuildMCP
→ Build / Simulator / QA

처럼 역할을 배치할 수 있습니다.

결국 Paseo의 가치는 새로운 AI 모델을 하나 더 쓰는 데 있는 것이 아니라,

이미 사용하는 여러 Coding Agent를 하나의 개발팀처럼 구성할 수 있다는 데 있습니다.

마치며

지금까지 Coding Agent를 사용하는 방식은 대부분:

Developer
    ↓
Agent

였습니다.

하지만 Agent가 여러 개가 되기 시작하면 구조가 달라집니다.

                    Developer
                        ↓
                      Paseo
                        ↓
          ┌─────────────┼─────────────┐
          ↓             ↓             ↓
       Claude         Codex         Codex
     Architecture  Implementation     QA
          │             │             │
          └─────────────┼─────────────┘
                        ↓
                     Claude
                      Review

특히 iOS 개발이라면:

Claude = 설계와 Review

Codex = 실제 구현

Codex + XcodeBuildMCP = Simulator와 QA

정도로 역할을 나누는 구성이 상당히 실용적입니다.

그리고 모든 작업에 가장 큰 모델을 사용하는 대신:

어려운 설계
→ 비싼 Reasoning

구현
→ Coding Agent

반복 QA
→ 적절한 Agent + Tool

간단한 조사
→ 저렴한 Model

처럼 분산하면 Agent를 여러 개 쓰는 이유가 훨씬 분명해집니다.

Multi-Agent의 핵심은 Agent를 많이 만드는 것이 아닙니다.

각 Agent에게 독립적으로 판단할 가치가 있는 일을 나누고, 그 결과를 다시 하나의 Workflow로 연결하는 것.

Paseo는 바로 그 연결부에 있는 도구입니다.

참고자료

Paseo — Getting Started
Desktop App, CLI, daemon, Mobile Pairing과 기본 설치 방법을 설명합니다.
Paseo 시작하기
Paseo — Providers
Claude Code, Codex 등 기존 Agent CLI를 Paseo가 어떻게 실행하고 관리하는지 설명합니다.
Paseo Providers
Paseo — Supported Providers
Claude Code, Codex 등의 Native Provider와 Gemini CLI, GitHub Copilot 등 ACP Catalog를 확인할 수 있습니다.
지원 Agent 목록
Paseo — Agent Profiles
Provider, Model, Mode, Thinking Level과 역할 설명을 Profile로 저장하는 방법입니다.
Agent Profiles
Paseo — Orchestration
한 Agent가 다른 Agent를 생성하고 작업을 위임하고 결과를 모으는 핵심 기능입니다.
Paseo Orchestration
Paseo — Common Orchestration Workflows
구현 위임, 독립 Review, Parallel Research 같은 실전 예제가 있습니다.
Orchestration Workflow
Paseo — Git Worktrees
여러 Agent가 병렬로 코드를 수정할 때 독립적인 Workspace를 구성하는 방법입니다.
Paseo Worktrees
Paseo — Orchestration Skills
Handoff, Committee, Advisor 등 반복 가능한 Multi-Agent Workflow를 제공합니다.
Paseo Skills
XcodeBuildMCP
Build, Test, Simulator, UI Automation, Screenshot, Log 등 iOS 개발을 AI Agent와 연결하기 위한 MCP Server입니다.
XcodeBuildMCP

공식 자료 기준으로 보면 Paseo의 핵심은 자체 모델이 아니라 Provider·Workspace·Agent Profile·Orchestration을 이용해 여러 Coding Agent를 하나의 작업 흐름으로 묶는 것입니다. 처음에는 Claude/Codex 두 Provider와 Planning·Implementation·Review 정도의 Profile만 만들어도 충분하고, iOS 프로젝트라면 그다음 단계로 XcodeBuildMCP 기반 Simulator QA Agent를 붙이는 방식이 가장 이해하기 쉽습니다.

클린 아키텍처가 뭐길래

Sun, 20 Sep 2026 06:17:00 GMT

클린 아키텍처가 뭐길래

AI가 코드를 만드는 시대에는 어떻게 설계하고 관리해야 할까

개발을 시작한 지 얼마 되지 않았을 때 Clean Architecture를 검색하면 이런 그림을 자주 만나게 됩니다.

Entities
   ↑
Use Cases
   ↑
Interface Adapters
   ↑
Frameworks & Drivers

동그라미가 여러 개 있고,

Domain, Repository, UseCase, Presentation 같은 단어가 등장합니다.

그래서 처음에는 이렇게 생각하기 쉽습니다.

폴더를 저렇게 나누면 클린 아키텍처인가?

하지만 클린 아키텍처의 핵심은 폴더 구조가 아닙니다.

더 단순하게 표현하면 이겁니다.

바뀌기 쉬운 코드가 중요한 코드를 흔들지 못하게 만드는 것.

그리고 AI가 코드를 빠르게 만들어주는 시대에는 오히려 이 원칙이 더 중요해지고 있습니다.

1. 클린 아키텍처는 왜 만들어졌을까

앱을 처음 만들 때는 구조가 단순합니다.

예를 들어 사용자 정보를 가져온다고 해보겠습니다.

final class ProfileViewModel {

    func loadProfile() async {
        let url = URL(string: "https://api.example.com/profile")!

        let (data, _) = try! await URLSession.shared.data(from: url)

        let user = try! JSONDecoder().decode(User.self, from: data)

        name = user.name
    }
}

작은 앱에서는 별 문제가 없습니다.

하지만 기능이 늘기 시작합니다.

ProfileViewModel
 ├─ API 호출
 ├─ JSON Parsing
 ├─ Cache
 ├─ 로그인 상태 확인
 ├─ Analytics
 ├─ Error 처리
 └─ 화면 상태 관리

어느 순간 ViewModel 하나가 모든 것을 알고 있습니다.

API가 바뀌어도 수정해야 하고,

Cache를 바꿔도 수정해야 하고,

테스트를 작성하려 해도 실제 Network가 필요합니다.

이때 생기는 질문이 있습니다.

화면 코드가 왜 서버 구현 방법까지 알아야 하지?

클린 아키텍처는 여기서 시작합니다.

2. 핵심은 Dependency Rule 하나다

클린 아키텍처에서 가장 중요한 규칙은 사실 복잡하지 않습니다.

의존성은 중요한 정책 쪽으로 향해야 합니다.

쉽게 그리면:

UI
 ↓
UseCase
 ↓
Domain

그리고 외부 시스템은 반대편에 있습니다.

API
Database
Firebase
Framework

Domain이 이런 것들을 직접 알게 만들지 않습니다.

즉:

Domain → Firebase

보다

Firebase
   ↓
Repository 구현
   ↓
Domain Interface

가 되는 구조입니다.

Robert C. Martin이 설명한 Clean Architecture 역시 UI, Database, Framework와 핵심 Business Rule을 분리하고 Source Code Dependency가 안쪽의 정책을 향하도록 하는 것이 중심입니다.

3. 처음부터 4개의 거대한 Layer를 만들 필요는 없다

주니어 개발자가 가장 많이 하는 실수 중 하나입니다.

클린 아키텍처를 배웠다고 바로:

Presentation

Domain

Data

Infrastructure

Core

Common

Shared

Network

Repository

를 만듭니다.

그리고 파일 하나를 추가하려고 해도:

DTO
Mapper
Entity
Repository
RepositoryImpl
UseCase
Protocol
ViewModel

이 필요해집니다.

이건 Clean한 것이 아니라 복잡한 것일 수 있습니다.

클린 아키텍처에서 중요한 것은 Layer 개수가 아닙니다.

실제로 원래 Clean Architecture에서도 정확히 네 개의 원을 반드시 사용해야 한다는 규칙은 없습니다.

중요한 것은:

무엇이 자주 바뀌는가?

무엇이 오래 유지되어야 하는가?

어느 쪽이 어느 쪽을 알아야 하는가?

입니다.

4. 주니어라면 세 덩어리부터 이해하면 된다

앱에서는 처음에 이 정도만 구분해도 충분합니다.

Presentation

Domain

Data

Presentation

화면과 사용자 Interaction입니다.

SwiftUI View
UIKit ViewController
ViewModel
UI State
Navigation

Domain

앱이 실제로 해야 하는 일입니다.

Entity
UseCase
Business Rule
Repository Protocol

Data

데이터를 실제로 가져오는 방법입니다.

API
Database
Cache
DTO
Repository Implementation

흐름은:

View
 ↓
ViewModel
 ↓
UseCase
 ↓
Repository Protocol
 ↑
Repository Implementation
 ↓
API / DB

정도면 됩니다.

5. 예제로 보면 훨씬 쉽다

쇼핑 앱에 상품을 가져오는 기능이 있다고 해보겠습니다.

먼저 Domain입니다.

struct Product {
    let id: String
    let name: String
    let price: Int
}

그리고 Repository의 역할만 정의합니다.

protocol ProductRepository {
    func fetchProducts() async throws -> [Product]
}

Domain은 상품이 어디에서 오는지 모릅니다.

REST API인지

GraphQL인지

Firebase인지

Local DB인지

알 필요가 없습니다.

6. 실제 API 구현은 Data Layer에 둔다

final class RemoteProductRepository: ProductRepository {

    private let apiClient: APIClient

    init(apiClient: APIClient) {
        self.apiClient = apiClient
    }

    func fetchProducts() async throws -> [Product] {

        let response: ProductResponse =
            try await apiClient.request("/products")

        return response.items.map {
            Product(
                id: $0.id,
                name: $0.title,
                price: $0.price
            )
        }
    }
}

여기에는:

APIClient

JSON

DTO

Endpoint

가 있어도 됩니다.

왜냐하면 이 영역 자체가 외부 시스템과 연결하는 영역이기 때문입니다.

7. UseCase에는 앱의 의도를 넣는다

struct FetchProductsUseCase {

    let repository: ProductRepository

    func execute() async throws -> [Product] {
        try await repository.fetchProducts()
    }
}

지금은 너무 단순해 보입니다.

그래서 이런 생각이 들 수 있습니다.

Repository를 그냥 ViewModel에서 부르면 안 되나?

물론 됩니다.

UseCase가 아무 역할도 하지 않는다면 굳이 만들 필요 없습니다.

하지만 나중에 요구사항이 이렇게 바뀐다면 이야기가 달라집니다.

판매 중인 상품만 노출

재고 없는 상품 제외

사용자 등급별 가격 계산

차단 상품 제거

추천순 정렬

이건 API의 책임도 아니고 UI의 책임도 아닙니다.

앱이 수행해야 할 Business Rule입니다.

이때 UseCase의 존재 이유가 생깁니다.

8. 클린 아키텍처는 코드 정리가 아니라 변경을 관리하는 방법이다

여기서 가장 중요한 부분입니다.

클린 아키텍처를:

코드를 예쁘게 정리하는 방법

으로 이해하면 계속 헷갈립니다.

실제로는:

변경의 영향 범위를 제한하는 방법

에 가깝습니다.

예를 들어 서버가:

REST
↓
GraphQL

로 변경됐다고 해봅시다.

잘 분리되어 있다면:

Data Layer

를 주로 수정하면 됩니다.

UI가:

UIKit
↓
SwiftUI

로 바뀌어도 Domain은 대부분 그대로 남을 수 있습니다.

Database가:

Core Data
↓
SwiftData

로 바뀌어도 Business Rule까지 같이 뜯어고칠 이유는 없습니다.

좋은 Architecture의 목적은 변화를 없애는 것이 아니라 변화가 퍼지는 것을 막는 것입니다.

그런데 AI 시대에는 무엇이 달라졌을까

여기부터가 지금 더 중요한 이야기입니다.

예전에는 개발자가 직접 대부분의 코드를 작성했습니다.

지금은 Codex, Claude Code 같은 Coding Agent에게:

로그인 기능 만들어줘.

Repository 추가해줘.

Unit Test 만들어줘.

이 화면 SwiftUI로 바꿔줘.

라고 요청할 수 있습니다.

앞으로 AI가 작성하는 코드의 비율은 더 높아질 가능성이 있습니다.

그런데 여기서 새로운 문제가 발생합니다.

9. AI는 코드를 빨리 만들지만 프로젝트의 의도까지 자동으로 알지는 못한다

예를 들어 프로젝트가 이렇게 되어 있다고 합시다.

Features/
Domain/
Data/
Core/

개발자에게는 암묵적인 규칙이 있습니다.

View에서 Repository 직접 호출 금지

Domain에서 UIKit import 금지

DTO를 Presentation으로 전달 금지

Feature끼리 직접 참조 금지

Network는 Data Layer에서만 사용

그런데 AI에게 아무 설명도 하지 않고:

상품 상세 화면 추가해줘.

라고 하면 AI가 가장 빠른 방법으로:

struct ProductDetailView: View {

    func load() async {
        URLSession.shared...
    }
}

를 만들 수도 있습니다.

코드는 동작합니다.

하지만 Architecture는 조금씩 무너지기 시작합니다.

AI 시대에는 이 문제가 더 빠르게 발생할 수 있습니다.

사람이 하루에 300줄을 만들던 프로젝트에서 Agent들이 훨씬 많은 코드를 생성하기 시작하면, 잘못된 설계 역시 더 빠르게 복제될 수 있기 때문입니다.

10. 그래서 Architecture를 사람 머릿속에만 두면 안 된다

예전에는 팀의 시니어 개발자가 알고 있으면 어느 정도 운영이 됐습니다.

"여기서는 그렇게 만들면 안 돼."

"Repository 하나 만들어야 해."

"Domain에서 UIKit 쓰면 안 돼."

PR Review에서 알려주면 됐습니다.

AI Agent에게는 이 방법이 잘 통하지 않습니다.

그래서 Architecture를 명시적인 프로젝트 규칙으로 만들어야 합니다.

예를 들어:

ARCHITECTURE.md

를 만듭니다.

# Architecture

Presentation
- SwiftUI / UIKit
- ViewModel
- UI State

Domain
- Entity
- UseCase
- Repository Protocol

Data
- Repository Implementation
- API / DB
- DTO

## Dependency Rules

Presentation → Domain 허용

Data → Domain 허용

Domain → Presentation 금지

Domain → Data 금지

사람에게도 좋은 문서지만 AI에게는 더 중요합니다.

11. AGENTS.md와 CLAUDE.md는 Architecture 문서가 아니다

Codex에서는 프로젝트에 AGENTS.md를 둘 수 있고, Claude Code에서는 CLAUDE.md 같은 프로젝트 지침을 사용할 수 있습니다.

여기에 Build, Test, Coding Convention, Repository 규칙 등을 넣어 Agent가 작업을 시작할 때 참고하게 할 수 있습니다.

하지만 중요한 점이 있습니다.

AGENTS.md에 Architecture 전체를 복사해 넣는 것이 좋은 방법은 아닙니다.

오히려:

AGENTS.md
      ↓
Architecture Map

ARCHITECTURE.md
      ↓
설계 원칙

docs/
      ↓
상세 설계

Tests / Lint
      ↓
규칙 검증

처럼 역할을 나누는 편이 좋습니다.

OpenAI도 현재 Codex 프로젝트 지침에서 AGENTS.md를 간결하게 유지하고 Build/Test/Review 규칙과 Repository별 관습을 명시하는 방식을 권장하며, 더 큰 프로젝트에서는 이를 상세 문서로 연결하는 일종의 목차처럼 사용하는 방식을 소개하고 있습니다.

Claude Code 역시 CLAUDE.md를 매 세션 읽는 Project Instruction으로 사용하고, 특정 작업용 규칙은 Rules나 Skills 등으로 분리할 수 있습니다.

즉 AI 시대의 Architecture는 이제:

코드 구조
+
문서
+
AI Instruction
+
자동 검증

까지 같이 봐야 합니다.

12. AI에게 가장 먼저 알려줘야 하는 것은 기술 스택이 아니다

이런 Instruction은 흔합니다.

Swift 6 사용

SwiftUI 사용

async/await 사용

MVVM 사용

물론 필요합니다.

하지만 Architecture를 유지하려면 더 중요한 규칙이 있습니다.

예를 들어:

## Architecture Rules

1. View는 UseCase만 호출한다.

2. Domain Layer에서는
   SwiftUI, UIKit, URLSession을 import하지 않는다.

3. API Response DTO는
   Presentation Layer까지 전달하지 않는다.

4. Repository Protocol은 Domain에 둔다.

5. Repository 구현은 Data에 둔다.

6. 새로운 Dependency를 추가하기 전에
   기존 구현으로 해결 가능한지 확인한다.

7. 새로운 Layer를 임의로 만들지 않는다.

8. Architecture 변경이 필요하면
   구현 전에 변경 이유를 먼저 설명한다.

이런 내용이 훨씬 중요합니다.

AI에게:

어떻게 코딩할 것인가

뿐 아니라

어디까지 변경해도 되는가

를 알려주는 것입니다.

13. Architecture Rule은 가능하면 코드로 검증해야 한다

문서만 있다고 Architecture가 유지되는 것은 아닙니다.

사람도 문서를 잊고 AI도 실수합니다.

그래서 가능하면 규칙을 자동화합니다.

예를 들어 Domain Module에:

import UIKit

이 들어가면 Build나 Lint 단계에서 잡도록 만들 수 있습니다.

Module Dependency도:

Presentation
    ↓
Domain
    ↑
Data

만 허용하도록 구성할 수 있습니다.

즉:

"이렇게 해주세요"

보다

"이렇게 하지 않으면 Build가 실패합니다"

가 훨씬 강합니다.

AI 시대에는 특히 그렇습니다.

좋은 구조는 AI가 매번 완벽한 판단을 해야 유지되는 구조가 아니라,

잘못된 코드를 만들어도 시스템이 잡아주는 구조입니다.

14. Unit Test의 의미도 조금 달라진다

예전에는 테스트를:

사람이 코드를 수정하다 실수하는 것을 막는다.

정도로 생각했습니다.

Agent가 코드를 직접 수정하는 환경에서는 테스트가 하나의 작업 경계가 됩니다.

AI 코드 수정
    ↓
Build
    ↓
Unit Test
    ↓
Architecture Test
    ↓
UI Test
    ↓
Review

AI에게:

로그인 로직 수정해줘.

라고 말할 때

기대하는 것은 단순히 코드가 생성되는 것이 아닙니다.

기존 Test 통과

새 Requirement Test 추가

Architecture Rule 유지

Regression 없음

까지 확인되는 것입니다.

그래서 앞으로는 테스트가 많은 프로젝트일수록 Agent에게 일을 맡기기 쉬운 프로젝트가 될 가능성이 큽니다.

15. AI에게 큰 기능을 한 번에 맡기지 않는다

예를 들어 이런 요청은 위험합니다.

쇼핑몰 앱 결제 기능 전체를 구현해줘.

범위가 너무 큽니다.

대신 Architecture Boundary를 기준으로 나눕니다.

1. 요구사항 분석

2. Domain Model 제안

3. UseCase 설계

4. Repository Protocol 설계

5. Data 구현

6. Presentation 연결

7. Unit Test

8. Integration Test

그리고 단계마다 확인합니다.

Plan
 ↓
Review
 ↓
Implement
 ↓
Test

이 방식의 장점은 AI가 잘못된 방향으로 20개의 파일을 만든 뒤 처음부터 되돌리는 일을 줄일 수 있다는 것입니다.

16. AI 시대에는 작은 Interface가 더 중요해진다

예를 들어:

protocol PaymentRepository {

    func payment(
        productID: String,
        amount: Int
    ) async throws -> PaymentResult
}

처럼 경계가 명확하면 AI에게:

PaymentRepository 구현을 Stripe에서 새로운 Payment API로 변경해줘.

라고 맡기기 쉽습니다.

AI가 수정해야 할 영역이 분명하기 때문입니다.

반대로:

Singleton

Global State

Massive ViewModel

거대한 Manager

숨겨진 Side Effect

가 많으면 AI도 전체 영향을 추적하기 어려워집니다.

사람에게 이해하기 어려운 코드는 AI에게도 안전하게 수정하기 어렵습니다.

그래서 AI 시대에 좋은 Architecture는:

Agent가 수정할 수 있는 범위를 명확하게 보여주는 Architecture

라고 볼 수도 있습니다.

17. Feature 단위 구조도 같이 생각하면 좋다

앱이 커지면 단순히:

Views/
ViewModels/
Repositories/
UseCases/

처럼 기술 종류별로 나누는 것보다 Feature가 보이는 구조가 관리하기 편할 때가 많습니다.

예를 들어:

Features/

├─ Login/
│  ├─ Presentation/
│  ├─ Domain/
│  └─ Data/
│
├─ Product/
│  ├─ Presentation/
│  ├─ Domain/
│  └─ Data/
│
└─ Payment/
   ├─ Presentation/
   ├─ Domain/
   └─ Data/

이렇게 하면 사람도 AI도:

결제 수정
→ Payment

로그인 수정
→ Login

처럼 변경 범위를 찾기 쉽습니다.

Architecture의 목적이 잘 드러나는 구조입니다.

18. 모든 Feature에 Clean Architecture를 적용할 필요는 없다

이것도 중요합니다.

예를 들어 단순한 설정 화면이 있습니다.

알림 ON/OFF

Dark Mode ON/OFF

이걸 위해:

SettingEntity

UpdateSettingUseCase

SettingRepository

SettingRepositoryImpl

SettingDTO

SettingMapper

를 모두 만들 필요는 없습니다.

Architecture에는 비용이 있습니다.

파일이 늘고 Interface가 늘고 개발자가 이동해야 하는 코드도 늘어납니다.

그래서 기준을 이렇게 잡는 편이 현실적입니다.

Business Rule이 복잡하다
→ 분리

외부 Dependency가 자주 바뀐다
→ 분리

Test가 중요하다
→ 분리

여러 화면에서 사용한다
→ 분리

단순 UI 상태다
→ 단순하게 유지

Clean Architecture의 목적은 Layer를 많이 만드는 것이 아니라 변경 비용을 줄이는 것입니다.

19. AI가 만든 코드도 같은 기준으로 Review한다

AI 코드라고 별도의 Review 기준이 필요한 것은 아닙니다.

오히려 기존 Architecture 기준을 그대로 적용합니다.

Dependency

잘못된 Layer를 참조하지 않는가?

Responsibility

ViewModel이 너무 많은 일을 하지 않는가?

Business Rule

Domain Rule이 UI에 들어가지 않았는가?

Boundary

DTO가 Domain이나 UI까지 새어 나오지 않는가?

Test

중요한 변경에 Test가 추가됐는가?

Scope

요청하지 않은 파일까지 수정하지 않았는가?

마지막 항목은 Agent 환경에서 특히 중요합니다.

20. AI가 반복해서 틀리면 프롬프트를 길게 쓰지 말고 규칙을 고친다

매번 이렇게 말하고 있다면:

Repository Protocol은 Domain에 만들어줘.

DTO를 ViewModel에 넘기지 마.

Test 꼭 추가해줘.

문제가 있습니다.

이건 사람이 AI에게 반복적으로 Code Review를 하고 있는 것입니다.

두 번 이상 반복되는 지적이라면:

AGENTS.md

CLAUDE.md

ARCHITECTURE.md

Lint Rule

Test

중 하나로 옮기는 것이 좋습니다.

OpenAI의 Codex 가이드도 반복되는 Review Feedback이나 Agent의 잘못된 가정을 Project Instruction으로 남기고, 가능한 경우 Linter나 Type Check처럼 강제 가능한 시스템과 함께 사용하는 방식을 권장합니다.

즉:

AI가 실수
   ↓
사람이 수정

으로 끝내지 않고:

AI가 실수
   ↓
원인 파악
   ↓
Architecture Rule 추가
   ↓
다음 작업부터 예방

으로 바꾸는 것입니다.

이것이 AI 시대의 중요한 프로젝트 관리 방식 중 하나입니다.

21. README 하나만으로는 부족하다

AI Agent와 같이 개발한다면 프로젝트 문서를 역할별로 나누는 것도 좋습니다.

예를 들면:

README.md

프로젝트 소개와 실행 방법.

ARCHITECTURE.md

전체 구조와 Dependency Rule.

AGENTS.md

Codex가 반드시 알아야 할 작업 규칙.

docs/
├─ architecture/
├─ features/
├─ decisions/
└─ migrations/

상세 설계와 변경 기록.

여기에 중요한 Architecture 변경은 간단한 ADR 형식으로 남길 수 있습니다.

Decision

왜 변경했는가

어떤 대안을 검토했는가

무엇을 선택했는가

어떤 영향이 있는가

이 문서는 사람을 위한 기록인 동시에 AI가 다음 작업에서 참고할 수 있는 Context가 됩니다.

22. 결국 중요한 건 Context Engineering이다

AI에게 많은 코드를 보여준다고 좋은 결과가 나오는 것은 아닙니다.

필요한 정보를 정확하게 제공하는 것이 중요합니다.

좋은 프로젝트라면 AI가 작업을 시작했을 때:

무슨 앱인지

어떤 Feature인지

Architecture가 무엇인지

Dependency Rule이 무엇인지

어떤 Test를 실행해야 하는지

어디까지 수정해도 되는지

를 빠르게 파악할 수 있어야 합니다.

그래서 앞으로 Architecture 문서는 단순한 개발 문서가 아니라 AI Agent에게 프로젝트의 Context를 제공하는 Infrastructure 역할도 하게 됩니다.

23. 주니어라면 이 정도부터 시작하면 충분하다

처음부터 거대한 Clean Architecture를 만들지 않아도 됩니다.

1단계

UI와 Network Code 분리

2단계

Business Logic을 ViewModel 밖으로 이동

3단계

Repository Protocol 도입

4단계

Domain이 외부 Framework를 모르도록 구성

5단계

Unit Test 추가

6단계

Architecture Rule 문서화

7단계

AI Agent Instruction 연결

이렇게 조금씩 만들어도 됩니다.

24. AI 시대의 Clean Architecture를 한 장으로 정리하면

예전에는 이렇게 생각했다면:

Presentation
     ↓
Domain
     ↑
Data

지금은 한 단계가 더 필요합니다.

          사람 / AI Agent
               ↓
       Project Instructions
               ↓
         Architecture
               ↓
┌────────────────────────────┐
│        Presentation        │
│             ↓              │
│           Domain           │
│             ↑              │
│            Data            │
└────────────────────────────┘
               ↓
     Test / Lint / Build
               ↓
           Verification

여기서 중요한 건 AI가 아닙니다.

가운데 있는 Architecture와 Verification입니다.

AI는 이 규칙 안에서 일하는 또 하나의 개발자에 가깝습니다.

25. 마무리

클린 아키텍처를 처음 배우면:

Entity

UseCase

Repository

Adapter

Dependency Inversion

같은 용어부터 외우기 쉽습니다.

하지만 가장 먼저 이해해야 할 것은 이것입니다.

중요한 코드를 자주 바뀌는 코드로부터 보호한다.

UI는 바뀝니다.

API도 바뀝니다.

Database도 바뀝니다.

Framework도 바뀝니다.

그리고 이제는 코드를 작성하는 주체도 바뀌고 있습니다.

사람이 작성하기도 하고 Codex나 Claude Code 같은 Agent가 작성하기도 합니다.

그래도 앱의 Business Rule과 Architecture 원칙은 쉽게 흔들려서는 안 됩니다.

그래서 AI 시대의 Clean Architecture는 단순히:

폴더를 잘 나누는 방법

이 아니라,

사람과 AI가
같은 규칙 아래에서
안전하게 코드를 변경하는 방법

으로 보는 편이 더 맞습니다.

코드를 만드는 속도가 빨라질수록 더 중요한 것은 코드를 많이 만드는 능력이 아닙니다.

어떤 코드는 어디에 있어야 하고, 무엇에 의존할 수 있으며, 어떤 변경은 허용하지 않을 것인지 명확하게 결정하는 능력입니다.

AI가 구현을 더 많이 맡게 될수록 Architecture의 역할은 줄어드는 것이 아니라 오히려 더 분명해질 가능성이 큽니다.

참고자료

Robert C. Martin — The Clean Architecture
Clean Architecture의 Layer, Dependency Rule, Entity, Use Case, Interface Adapter 개념을 설명한 원문입니다.
The Clean Architecture 원문
Robert C. Martin — Screaming Architecture
프로젝트 구조가 Framework보다 실제 Use Case와 Business Domain을 드러내야 한다는 관점을 설명합니다.
Screaming Architecture 원문
OpenAI — AGENTS.md를 활용한 프로젝트 지침
Codex에 Build/Test 명령, Review 기준, Repository별 규칙 등을 지속적으로 전달하는 방법을 설명합니다.
Codex AGENTS.md 공식 문서
OpenAI — Harness Engineering
AGENTS.md를 거대한 설명서가 아니라 프로젝트 지식으로 이동하기 위한 목차처럼 사용하고, Architecture와 Design Document를 별도로 관리하는 실제 Agent-first Repository 운영 방식을 소개합니다.
Harness Engineering 공식 글
Anthropic — Claude Code 프로젝트 디렉터리
CLAUDE.md, Rules, Skills, Subagents 등의 역할과 프로젝트 수준에서 Agent Context를 관리하는 방식을 설명합니다.
Claude Code 공식 문서

공식 자료와 Clean Architecture의 원래 취지를 같이 보면, AI 시대라고 해서 새로운 Architecture가 갑자기 필요한 것은 아닙니다. 오히려 기존의 Dependency Rule과 명확한 Boundary에 Project Instructions, 문서, Test, Lint 같은 Agent용 Guardrail을 추가하는 방향이 현실적입니다.

결국 좋은 AI 개발 환경은 Agent에게 모든 판단을 맡기는 환경이 아니라, Agent가 잘못된 방향으로 가기 어렵도록 프로젝트 자체에 의도와 규칙이 남아 있는 환경에 가깝습니다.

iPhone Duo UI 마이그레이션부터 자동 QA까지

Sun, 20 Sep 2026 06:14:32 GMT

iPhone Duo UI 마이그레이션부터 자동 QA까지

Xcode 27.1 + Codex로 화면 수정하고 시뮬레이터에서 다시 검증하기

iPhone Duo 대응에서 처음 눈에 들어오는 것은 화면 크기입니다.

접었을 때와 펼쳤을 때 화면 비율이 달라지고, 가운데 fold가 생기고, 기존 상단이나 하단에 있던 navigation과 toolbar가 세로 방향으로 이동할 수도 있습니다.

하지만 실제 개발에서 더 부담스러운 부분은 따로 있습니다.

수정해야 할 화면보다 확인해야 할 상태가 훨씬 많아진다는 점입니다.

Closed
Open
Folded
Rotated

×

Navigation 상태
Modal 상태
Keyboard
Scroll 위치
Dynamic Type
Dark Mode

화면 하나를 고쳐도 여러 상태에서 다시 확인해야 합니다.

그래서 iPhone Duo 대응에서는 UI Migration뿐 아니라 Simulator Automation과 QA Workflow가 같이 중요해집니다.

최근 Xcode 27.1의 Duo Simulator와 Codex의 iOS Simulator 제어 Workflow를 조합하면 이 반복작업을 꽤 많이 자동화할 수 있습니다. Apple은 Xcode 27.1에서 Duo를 열고, 닫고, 회전하고, 접은 상태를 Device Hub에서 테스트할 수 있도록 했고, OpenAI는 Codex가 XcodeBuildMCP를 통해 Simulator를 실행하고 UI tree를 읽고 tap·type·swipe하며 screenshot, log, LLDB까지 사용하는 Workflow를 공식적으로 문서화했습니다.

1. Duo 대응은 단순한 화면 리사이징이 아니다

기존 iPhone 앱은 보통 세로 화면을 중심으로 만들어졌습니다.

UIScreen.main.bounds.width

같은 값을 기준으로 UI를 계산하거나,

if width > 700 {
    // tablet layout
}

처럼 특정 화면 폭을 기준으로 분기한 코드도 적지 않습니다.

Duo에서는 이런 가정이 훨씬 위험해집니다.

앱이 실행되는 공간이:

닫힌 상태
→ 일반적인 iPhone 형태

펼친 상태
→ 넓어진 내부 화면

접은 상태
→ fold가 화면을 분할

회전
→ 또 다른 비율

로 계속 달라지기 때문입니다.

Apple도 Duo 대응에서 화면 크기를 직접 추측하기보다 Size Class, Trait Collection, 현재 Scene과 실제 Layout Environment를 사용하라고 권장하고 있습니다. UIScreen.main 같은 main-screen 기반 코드 역시 멀티 디스플레이 환경에서 줄이는 방향입니다.

예를 들어:

let scale = UIScreen.main.scale

보다:

let scale = traitCollection.displayScale

처럼 현재 UI가 실제로 놓여 있는 환경에서 값을 얻는 것이 안전합니다.

Duo Migration의 첫 번째 작업은 의외로 새로운 API를 추가하는 것이 아니라,

UIScreen.main

고정 width / height

orientation 기반 분기

device model 기반 분기

absolute frame

같은 기존 가정을 찾아내는 것입니다.

Duo에서 가장 먼저 다시 볼 부분은 Navigation입니다.

SwiftUI라면:

NavigationStack
NavigationSplitView
TabView

UIKit이라면:

UINavigationController
UISplitViewController
UITabBarController

같은 System Container를 사용하는 것이 중요합니다.

Apple은 Duo에서 표준 navigation container와 presentation이 각 pose에 맞게 적응하도록 설계했습니다.

예를 들어 Tab Bar는 내부 화면에서 상황에 따라 Sidebar 형태로 바뀔 수 있고 Navigation과 Toolbar도 세로 방향으로 이동할 수 있습니다.

그래서 문제가 되는 것은:

Custom UI

자체가 아닙니다.

문제는:

System Navigation과 완전히 분리된
Custom Navigation

입니다.

예를 들어:

VStack {
    CustomNavigationBar()

    ContentView()

    CustomTabBar()
}

처럼 모든 Navigation UI를 직접 배치했다면 Duo의 Vertical Bar나 새로운 Safe Area 변화가 자동으로 반영되지 않습니다.

3. 기존 Custom Tab Bar를 당장 버릴 필요는 없다

기존 서비스에서 Custom Tab Bar와 Custom Navigation을 전부 System Container로 한 번에 교체하는 것은 현실적으로 어렵습니다.

그래서 iOS 27.1에서는 ReservedRegion이 중요합니다.

SwiftUI에서는:

ReservedRegion

UIKit에서는:

UIViewReservedRegion

을 사용할 수 있습니다.

목적은 단순합니다.

Safe Area 밖까지 UI를 사용하면서도 시스템 UI나 하드웨어 영역과 충돌하지 않게 하는 것입니다.

따라서 마이그레이션은:

Custom UI 전부 삭제

보다

1. 기존 Custom UI 유지

2. ReservedRegion 대응

3. Navigation State와 UI 분리

4. System Container로 단계적 이동

이 현실적입니다.

4. 이제 fold 자체를 Layout 정보로 읽을 수 있다

이번 Duo 대응에서 꽤 중요한 변화입니다.

단순히:

Safe Area가 달라졌다

정도가 아닙니다.

앱이 어디에 fold가 있는지 직접 조회할 수 있습니다.

SwiftUI:

GeometryReader { proxy in
    let regions = proxy.reservedRegions(
        kind: .division
    )

    let frames = regions.map(\.frame)

    // layout
}

UIKit:

let regions = view.reservedRegions(
    kind: .division
)

let frames = regions.map(\.frame)

여기서 .division은 화면을 실제로 나누는 영역입니다.

Duo의 fold가 대표적입니다.

또:

.occlusion

도 존재합니다.

이건 카메라처럼 화면 일부를 가리는 영역을 의미합니다.

즉 이제 Layout은 단순히:

width = 1000

을 보고 판단하는 것이 아니라,

전체 화면
+
division
+
occlusion

을 같이 보고 결정할 수 있습니다.

5. fold가 펴져 있어도 미리 알 수 있다

조금 더 재미있는 API도 있습니다.

let regions = proxy.reservedRegions(
    kind: .division,
    options: .includeInactive
)

includeInactive를 사용하면 현재 fold가 활성화돼 있지 않은 상태에서도 해당 Region 정보를 확인할 수 있습니다.

Duo가 완전히 펼쳐져 있으면 fold의 division region은 inactive 상태이고 폭도 0이 될 수 있습니다.

하지만 앱은:

이 Device에는 division region이 존재한다

는 사실을 알 수 있습니다.

예를 들어 Grid UI라면:

Duo

→ Column을 짝수로 구성
→ 나중에 접혀도 자연스럽게 양쪽으로 분리

같은 선제적인 Layout 설계도 가능합니다.

6. ArrangementView가 꽤 중요해졌다

기존 Foldable 대응에서는 직접:

if folded {
    HStack { ... }
} else {
    VStack { ... }
}

같은 코드를 작성하기 쉽습니다.

Apple은 iOS 27.1에서 이 문제를 위해 ArrangementView라는 Layout Container를 제공합니다.

SwiftUI:

NavigationStack {
    ArrangementView {
        PlayerView()
    } secondary: {
        UpNextView()
    }
}

UIKit에서는:

UIArrangementViewController

를 사용할 수 있습니다.

Arrangement는 단순 Split View와 조금 다릅니다.

Size Class

Aspect Ratio

Division Region

현재 사용 가능한 공간

등을 기준으로 Primary와 Secondary Content를 배치합니다.

즉 Duo 대응의 핵심은:

크기 변경

에서 점점

Arrangement 변경

으로 이동합니다.

7. Center Layout도 다시 생각해야 한다

기존 앱에는 가운데 정렬 UI가 많습니다.

[       큰 이미지       ]

        제목

        버튼

Duo를 반쯤 접으면 가운데 fold가 그대로 콘텐츠를 지나갈 수 있습니다.

이때 단순하게 전체 View를 축소하는 것보다:

왼쪽
Image

       fold

오른쪽
Title
Button

처럼 콘텐츠를 이동시키는 편이 자연스러울 수 있습니다.

Apple은 이를 Displacement Pattern으로 설명하고 있습니다.

그래서 Duo Migration 시 다음 화면을 먼저 찾는 것이 좋습니다.

Center aligned Hero

Video Player

Camera Preview

Map

Large Chart

Two-pane editor

Media Player

이런 화면은 fold가 지나갈 가능성이 높습니다.

8. Vertical Bar 대응도 이제 단순한 Tab Bar 문제가 아니다

Duo 내부 화면에서는 Navigation, Toolbar, Tab Bar가 하나의 Vertical Region을 공유할 수 있습니다.

Apple은 이를 거의:

기존 Bar를
90도 돌려 배치한다

는 개념으로 설명합니다.

하지만 Custom Toolbar를 직접 만든 경우에는 자동으로 들어가지 않습니다.

SwiftUI에서는 가능한 한:

NavigationStack {
    ContentView()
        .toolbar {
            ToolbarItem {
                Button("Edit") { }
            }
        }
}

처럼 Navigation Container에 Toolbar를 연결하는 것이 좋습니다.

UIKit 역시:

UINavigationController
+
ViewController의 toolbarItems

방식이 권장됩니다.

직접 만든:

UIToolbar()
UINavigationBar()
UITabBar()

의 Content는 Duo의 시스템 Vertical Bar 구성에 자동 참여하지 않습니다.

9. 여기까지가 Migration, 문제는 QA다

여기까지 코드만 고쳤다고 해보겠습니다.

이제 확인해야 합니다.

Closed
✓

Open
?

Folded
?

Rotated Open
?

Rotated Folded
?

화면이 30개라면?

30 × pose 4

만 해도 120번입니다.

여기에:

Navigation

Modal

Keyboard

Scroll

Dynamic Type

Dark Mode

까지 들어갑니다.

그래서 Duo 대응에서는 시뮬레이터 QA 자동화의 가치가 커집니다.

10. Xcode 27.1에는 iPhone Duo Simulator가 있다

Xcode 27.1에서 iPhone Duo Simulator를 선택하면 Device Hub에서:

Open

Close

Rotate

Fold

상태를 직접 바꿔 테스트할 수 있습니다.

즉 예전처럼:

Preview width를 임의로 바꿔보기

가 아니라 실제 Duo 환경에서 UI를 확인할 수 있습니다.

이제 문제는:

누가 이걸 계속 눌러서 테스트할 것인가?

입니다.

여기서 Codex를 붙일 수 있습니다.

11. Codex는 이제 Simulator를 직접 조작할 수 있다

OpenAI는 Codex의 공식 iOS Use Case로:

Debug in iOS Simulator

를 제공하고 있습니다.

Codex와 XcodeBuildMCP를 연결하면:

Xcode Project 탐색
       ↓
Scheme 선택
       ↓
Simulator 선택
       ↓
Build
       ↓
Launch
       ↓
UI hierarchy 확인
       ↓
Tap
Type
Scroll
Swipe
       ↓
Screenshot
       ↓
Log
       ↓
LLDB

까지 진행할 수 있습니다.

즉 Codex가 단순히 Swift 코드를 작성하는 도구에서:

코드
+
실행 환경
+
UI
+
Debugger

를 같이 보는 형태로 바뀌고 있습니다.

12. 좌표를 찍는 매크로와는 조금 다르다

UI 자동화에서 흔한 방식은:

x: 320
y: 630

tap

입니다.

하지만 Layout이 조금만 바뀌어도 깨집니다.

OpenAI의 Codex Simulator Workflow에서는 가능하면 Accessibility Label이나 Element ID를 사용하고, 화면이 변경될 때 UI hierarchy를 다시 읽는 방식을 권장합니다.

예를 들어:

"로그인" 버튼 검색
       ↓
Tap
       ↓
화면 변경
       ↓
UI Tree 다시 조회
       ↓
"이메일" 입력창 검색
       ↓
Type

입니다.

Duo처럼 Layout이 pose에 따라 크게 달라지는 환경에서는 이 방식이 특히 중요합니다.

13. Duo QA Scenario를 자연어로 만들 수 있다

예를 들어 Codex에게 이런 작업을 줄 수 있습니다.

iPhone Duo Simulator에서 앱을 실행한다.

로그인 화면까지 이동한다.

테스트 계정으로 로그인한다.

홈 화면을 확인한다.

홈 → 상세 → 설정 화면까지 이동한다.

각 화면에서 스크린샷을 저장한다.

버튼이 잘리거나 다른 UI와 겹치는지 확인한다.

Navigation이 정상 동작하는지 확인한다.

로그에 constraint warning이나 crash가 있는지 확인한다.

문제가 있으면 원인을 찾고 최소한의 코드만 수정한다.

수정 후 같은 Flow를 다시 실행한다.

Codex가 담당할 수 있는 것은:

Reproduce

Observe

Diagnose

Fix

Verify

Loop입니다.

OpenAI도 공식 문서에서 이를 reproduce-fix-verify loop라고 설명합니다.

14. Duo에서는 QA Matrix를 먼저 만들어두는 것이 좋다

무작정 Agent에게:

전체 테스트해줘.

라고 하면 범위가 너무 큽니다.

Duo용 QA Matrix를 먼저 정의하는 것이 좋습니다.

예를 들어:

화면	Closed	Open	Folded	Rotate
Login	✓	✓	✓	✓
Home	✓	✓	✓	✓
Detail	✓	✓	✓	✓
Settings	✓	✓	✓	✓
Camera	✓	✓	✓	✓

그리고 각 화면에서:

Layout

Navigation

Interaction

Safe Area

ReservedRegion

Vertical Bar

Accessibility

Crash / Warning

을 검사합니다.

이렇게 하면 QA가 훨씬 명확해집니다.

15. Layout QA에서는 이것부터 찾으면 된다

Duo Migration에서 특히 잡아야 할 문제는 몇 가지가 반복됩니다.

Fixed Width

.frame(width: 390)

UIScreen.main

UIScreen.main.bounds

Orientation 의존성

UIDevice.current.orientation

Safe Area 무시

.ignoresSafeArea()

를 foreground control에 무분별하게 사용하는 경우.

Navigation Controller 밖에서
Tab / Toolbar / Navigation Bar 직접 배치

중앙 UI

fold와 겹치는
centered control

이 항목들을 먼저 Audit하면 전체 수정량을 빠르게 줄일 수 있습니다.

16. Safe Area QA는 네 방향을 따로 봐야 한다

기존 iPhone에서는:

left == right

라고 가정한 코드가 생각보다 많습니다.

Duo에서는 safe area나 layout margin이 비대칭일 수 있습니다.

따라서:

let insets = view.safeAreaInsets

print(insets.top)
print(insets.left)
print(insets.bottom)
print(insets.right)

처럼 각각 독립적인 값으로 취급해야 합니다.

Apple도 Duo에서 asymmetric safe area와 layout margin을 반드시 테스트하라고 강조합니다.

17. ReservedRegion QA도 별도로 만들어야 한다

Custom UI가 있다면:

Division Region

Occlusion Region

두 가지를 확인합니다.

예를 들어:

let divisions = view.reservedRegions(
    kind: .division
)

let occlusions = view.reservedRegions(
    kind: .occlusion
)

그리고 중요한 버튼이 해당 영역과 겹치는지 확인합니다.

QA 관점에서 보면:

Safe Area QA

와

Reserved Region QA

는 같은 것이 아닙니다.

Safe Area 안에만 넣으면 되는 일반 control도 있지만, edge-to-edge나 custom bar처럼 Reserved Region을 별도로 고려해야 하는 UI도 있습니다.

18. Screenshot QA도 꽤 유용해진다

Codex는 Simulator에서 screenshot을 캡처할 수 있습니다.

그래서 각 상태에서:

Home_Closed.png

Home_Open.png

Home_Folded.png

Home_Rotated.png

처럼 증거를 남길 수 있습니다.

다만 여기서 한 가지 구분해야 합니다.

Codex가 screenshot을 볼 수 있다는 것과 완전한 Visual Regression Test Framework가 있다는 것은 다릅니다.

진짜 픽셀 기반 회귀 테스트가 필요하다면:

SnapshotTesting
또는
사내 Snapshot Tool

같은 시스템과 결합하는 것이 더 안정적입니다.

구조는:

Codex
 ↓
Simulator Flow 실행
 ↓
Screenshot
 ↓
Snapshot Baseline
 ↓
Diff

형태가 됩니다.

Codex는 여기서 실행과 원인 분석을 담당하게 할 수 있습니다.

19. Accessibility QA도 같이 할 수 있다

Codex가 UI Tree를 읽을 수 있다는 점은 단순 자동 클릭보다 의미가 큽니다.

예를 들어:

Button인데 Label 없음

아이콘만 있고 의미 없음

동일한 Accessibility ID 중복

숨겨져야 할 요소가 노출

같은 문제도 QA 대상이 될 수 있습니다.

Duo에서 Layout이 재배치돼도:

화면상 위치

대신

Accessibility Identity

가 유지된다면 자동화 Script도 훨씬 안정적으로 동작합니다.

결국 Accessibility를 잘 만드는 것이 QA 자동화 품질도 높여줍니다.

20. Crash가 발생하면 LLDB까지 이어갈 수 있다

UI를 눌러보다 Crash가 발생하면 자동화가 끝나는 것이 아닙니다.

Codex 공식 Workflow는 필요할 경우 LLDB를 붙여:

Stack Frame

Variable

Backtrace

등을 확인하는 단계까지 포함합니다.

전체 흐름은:

Simulator
 ↓
Crash
 ↓
Log
 ↓
LLDB
 ↓
Root Cause
 ↓
Code 수정
 ↓
Build
 ↓
동일 Flow 재실행

입니다.

이 부분이 단순 XCTest 생성과 가장 큰 차이 중 하나입니다.

21. QA Agent에게 코드를 마음대로 고치게 하면 안 된다

자동화가 가능하다고:

문제 있으면 알아서 다 고쳐.

라고 맡기는 것은 추천하지 않습니다.

오히려 제한을 명확하게 주는 것이 좋습니다.

문제를 먼저 재현할 것

수정 전 screenshot과 log를 남길 것

Root Cause를 설명할 것

가장 작은 코드 변경만 할 것

Navigation Architecture는 변경하지 말 것

Public API는 변경하지 말 것

수정 후 동일 Scenario를 다시 실행할 것

같은 조건입니다.

OpenAI의 공식 Simulator 예제도 smallest code change 후 동일 Flow를 다시 실행해 검증하도록 안내합니다.

22. 실제 Codex Prompt는 이렇게 시작해볼 수 있다

예를 들어:

XcodeBuildMCP를 사용해서
현재 프로젝트를 iPhone Duo Simulator에서 QA해줘.

대상 화면:
- Login
- Home
- Detail
- Settings

확인 항목:
- UI clipping
- overlap
- asymmetric safe area
- reserved region 충돌
- navigation
- toolbar / tab bar
- scroll
- accessibility label
- Auto Layout warning
- crash

각 화면에서 screenshot을 남겨.

문제가 발견되면 바로 수정하지 말고
먼저 원인과 수정 계획을 정리해.

승인된 수정은 최소 범위로 적용하고,
수정 후 동일 Flow를 다시 실행해서 검증해.

여기에 Duo 전용 조건을 추가합니다.

Closed / Open / Folded / Rotated 상태를
모두 QA 대상으로 본다.

UIScreen.main,
고정 width / height,
orientation 기반 분기를 우선적으로 찾아본다.

Custom Tab Bar와 Custom Navigation은
현재 디자인을 유지하면서
ReservedRegion으로 대응 가능한지 먼저 검토한다.

System Container로의 마이그레이션은
별도 제안으로 분리한다.

이렇게 하면 기존 앱을 전부 갈아엎는 방향으로 흘러가는 것을 막을 수 있습니다.

23. Pose 변경 자체는 자동화 범위를 구분해서 봐야 한다

여기서는 한 가지 주의할 점이 있습니다.

Xcode 27.1의 Device Hub가:

Open
Close
Rotate
Fold

를 제공하는 것은 Apple이 공식적으로 확인한 기능입니다.

Codex + XcodeBuildMCP가 Simulator 내부의 UI를 자동으로 조작하는 것도 공식 Workflow입니다.

하지만 Duo의 모든 pose 변경을 XcodeBuildMCP가 자동 API로 제어할 수 있는지는 사용하는 XcodeBuildMCP 버전과 Tool 노출 범위를 확인해야 합니다.

그래서 현재 실무에서는:

앱 내부 UI QA
→ Codex 자동화

Pose 변경
→ Tool 지원 시 자동화

미지원 시
→ Device Hub에서 상태 전환

으로 나누는 것이 안전합니다.

이 부분까지 완전히 자동화된 것처럼 보는 것은 아직 이릅니다.

24. 자동 QA의 현실적인 1단계는 Smoke Test다

처음부터 모든 화면을 자동화할 필요는 없습니다.

가장 먼저:

앱 실행

로그인

홈 진입

핵심 화면 3개 이동

대표적인 Modal 열기

스크롤

주요 CTA Tap

정도를 자동화합니다.

그리고 이를:

Closed

Open

Folded

에서 반복합니다.

이것만으로도:

Navigation 깨짐

화면 잘림

Button 접근 불가

Modal 이상

Crash

같은 큰 문제를 상당수 잡을 수 있습니다.

25. 그다음 Regression QA로 확장한다

Smoke Test가 안정되면:

Critical User Flow

를 추가합니다.

예를 들어 쇼핑 앱이면:

Login
 ↓
Product
 ↓
Cart
 ↓
Payment

카메라 앱이면:

Camera
 ↓
Zoom
 ↓
Capture
 ↓
Preview
 ↓
Save

업무 앱이면:

Login
 ↓
List
 ↓
Detail
 ↓
Edit
 ↓
Submit

정도입니다.

그리고 Duo pose별로 돌립니다.

Critical Flow
      ×
Duo Pose

이게 실질적인 Duo Regression Suite가 됩니다.

26. QA 결과도 사람이 읽기 쉽게 남겨야 한다

Agent가:

테스트 완료했습니다.

라고 하면 의미가 없습니다.

최종 결과는 최소한 이렇게 받아야 합니다.

Simulator
iPhone Duo / iOS 27.1

Scheme
Production-Debug

Tested
12 scenarios

Passed
10

Failed
2

그리고 Failure마다:

Home / Folded

문제
Floating button이 division region과 겹침

Evidence
home_folded_before.png

원인
고정 trailing offset

수정
safeArea + reservedRegion 기반 위치 계산

검증
home_folded_after.png

형태로 남기는 것이 좋습니다.

이런 결과라면 개발자뿐 아니라 QA나 기획자도 이해할 수 있습니다.

27. Xcode의 App Resizability Skill도 같이 활용할 수 있다

Apple도 이 반복적인 Migration 작업을 AI 활용 영역으로 보고 있습니다.

WWDC26에서 소개됐던 App Modernization Skill은 Xcode 27.1에서 App Resizability로 이름이 변경됐고, SwiftUI와 iPhone Duo까지 지원 범위가 확장됐습니다.

즉:

Apple App Resizability Skill
→ Layout Migration Audit

Codex + XcodeBuildMCP
→ Simulator 실행 / 문제 재현 / 수정 / 검증

처럼 역할을 나누는 것도 가능합니다.

28. 앞으로 iOS QA Workflow가 조금 달라질 것 같다

기존에는:

Developer
 ↓
코드 작성
 ↓
Simulator 확인
 ↓
QA 전달
 ↓
Bug
 ↓
Developer 재현
 ↓
수정

이었다면,

Agent를 끼운 Workflow는:

Developer
 ↓
Codex
 ↓
Build
 ↓
Simulator
 ↓
Flow 실행
 ↓
Screenshot / Log
 ↓
문제 발견
 ↓
수정
 ↓
동일 Flow 재검증
 ↓
QA

가 됩니다.

사람 QA가 없어지는 이야기는 아닙니다.

오히려 사람이 반복적으로 확인하던:

앱 실행

로그인

버튼 누르기

화면 이동

스크린샷 찍기

로그 수집

수정 확인

을 Agent에게 넘기고,

QA는:

UX가 자연스러운가

실제 사용자 시나리오가 맞는가

예상하지 못한 문제가 있는가

에 더 집중하는 방향에 가깝습니다.

29. iPhone Duo가 이 변화를 더 빠르게 만들 수 있다

일반적인 iPhone 하나만 지원할 때는 직접 Simulator를 몇 번 눌러보는 것으로도 버틸 수 있었습니다.

하지만 Duo에서는:

Pose 증가

Resizable Layout

Vertical Navigation

Asymmetric Safe Area

Reserved Region

Multiple Display

Fold

가 동시에 들어옵니다.

검증 Matrix가 커집니다.

그래서 이번 Duo 대응의 중요한 변화는 단순히:

Foldable iPhone이 나왔다.

가 아닙니다.

개발 Workflow 관점에서는:

사람이 모든 UI 상태를 직접 확인하기 어려워지는 시점이 왔다.

는 쪽이 더 흥미롭습니다.

30. 정리

iPhone Duo Migration은 세 단계로 보는 것이 좋습니다.

1단계 — Architecture

UIScreen.main 제거

고정 Layout 제거

Size Class / Trait 사용

System Navigation 우선

2단계 — Duo Layout

Asymmetric Safe Area

ReservedRegion

Division / Occlusion

ArrangementView

Vertical Bar

3단계 — Automation & QA

Xcode 27.1 Duo Simulator

Codex

XcodeBuildMCP

UI Tree

Tap / Type / Swipe

Screenshot

Logs

LLDB

Regression

결국 중요한 것은 새로운 UI API를 몇 개 적용했느냐가 아닙니다.

Migration
      ↓
Run
      ↓
Observe
      ↓
QA
      ↓
Fix
      ↓
Verify

까지 반복할 수 있는 구조를 만드는 것입니다.

Codex의 iOS Simulator Workflow가 흥미로운 것도 이 때문입니다.

예전의 AI 코딩 도구가:

코드를 만들어주는 AI

였다면,

현재는 점점:

코드를 수정하고

직접 실행하고

화면을 누르고

문제를 재현하고

증거를 수집하고

수정한 뒤

다시 같은 화면을 확인하는 AI

쪽으로 이동하고 있습니다.

iPhone Duo처럼 UI 상태가 빠르게 늘어나는 환경에서는 단순 Code Generation보다 이 reproduce → fix → verify Loop가 훨씬 중요한 개발 기능이 될 가능성이 큽니다.

참고자료

Apple Developer — Prepare your app for iPhone Duo
iOS 27.1 SDK, Duo Simulator, flexible layout, asymmetric safe area, ReservedRegion, App Resizability를 설명합니다.
Apple 공식 Tech Talk 보기

Apple Developer — Strike a pose with adaptive layouts on iPhone Duo
Division/Occlusion Reserved Region, fold 대응, ArrangementView와 UIArrangementViewController를 다룹니다.
Apple 공식 Tech Talk 보기

Apple Developer — Raise the bar with iPhone Duo
Vertical Navigation, Toolbar, Tab Bar, Overflow와 Custom Bar 마이그레이션을 설명합니다.
Apple 공식 Tech Talk 보기

OpenAI — Debug in iOS Simulator
Codex + XcodeBuildMCP를 이용해 Simulator를 실행하고 UI Tree, Tap/Type/Swipe, Screenshot, Log, LLDB를 활용해 reproduce-fix-verify Loop를 만드는 공식 Workflow입니다.
OpenAI 공식 iOS Simulator Workflow 보기

공식 자료 기준으로 보면 Duo 대응의 중심은 더 이상 단순한 화면 크기 대응에 머물지 않습니다. Apple은 ReservedRegion, ArrangementView, Vertical Bar와 App Resizability까지 Layout 대응 범위를 넓혔고, 동시에 실제 Duo Simulator를 제공하고 있습니다.

여기에 Codex의 Simulator Automation을 붙이면 UI Migration → 실행 → 재현 → Screenshot/Log 수집 → 수정 → 재검증까지 하나의 Workflow로 연결할 수 있습니다.

다만 현재는 Duo Device Hub의 모든 pose 변경까지 Codex나 XcodeBuildMCP가 자동 제어한다고 단정하기보다는, Simulator 내부 앱 조작 자동화와 Device Pose Automation을 별개의 영역으로 보고 사용하는 Tool 버전에서 지원 여부를 확인하는 것이 안전합니다.

문서 작업을 위한 AI 업무 총괄

Sun, 20 Sep 2026 02:02:16 GMT

문서 작업을 위한 AI 업무 총괄

자료 수집부터 한국어 보고서·차트·이미지·PPT·PDF·Outlook 메일까지

AI 업무 도구를 비교할 때 흔히 모델 성능부터 이야기합니다.

하지만 실제 회사에서 보고서를 만들고 대표이사나 임원에게 발표해야 하는 사람에게 중요한 것은 조금 다릅니다.

파일을 쉽게 찾을 수 있는가?

PDF와 Excel 자료를 제대로 읽는가?

한국어 보고서를 자연스럽게 쓰는가?

차트가 보기 좋은가?

설명용 그림을 만들 수 있는가?

PPT가 실제 발표에 쓸 만한가?

수정본과 최종본을 관리하기 쉬운가?

마지막으로 메일까지 보낼 수 있는가?

이 기준으로 보면 비교 대상은 CLI나 Coding Agent가 아닙니다.

ChatGPT Work와 Gemini + Google Workspace처럼 문서 작업 전체를 맡길 수 있는 환경을 봐야 합니다.

특히 Git이나 Terminal을 모르는 비개발 직군이라면 더욱 그렇습니다.

이번 글에서는 하나의 업무를 처음 시작해서 최종 발표자료와 메일을 보내기까지 어떻게 구성하면 좋은지 정리해보겠습니다.

1. 먼저 업무 파일 구조부터 단순하게 만든다

AI를 쓰기 전에 가장 먼저 할 일은 파일을 정리하는 것입니다.

복잡할 필요는 없습니다.

Windows에 이런 폴더 하나만 만들어도 충분합니다.

신규사업_검토/
│
├─ 01_원본자료
├─ 02_시장자료
├─ 03_분석자료
├─ 04_보고서
├─ 05_발표자료
├─ 06_이미지
└─ 07_최종본

01_원본자료에는 받은 파일을 그대로 넣습니다.

예를 들면:

시장조사.pdf

경쟁사자료.pdf

매출자료.xlsx

기존회사소개.pptx

제품사진.jpg

입니다.

중요한 원칙은 원본을 직접 수정하지 않는 것입니다.

AI가 만든 자료와 원본자료를 분리하면 나중에 내용을 다시 확인하기 쉽습니다.

2. ChatGPT Work는 Windows 로컬 폴더에서 바로 시작할 수 있다

ChatGPT Work를 데스크톱 앱에서 사용하면 로컬 폴더나 프로젝트를 열고 필요한 파일에 접근 권한을 줄 수 있습니다.

즉 파일을 하나씩 매번 업로드할 필요 없이:

신규사업_검토

폴더를 기준으로 작업할 수 있습니다.

웹이나 모바일 Work가 컴퓨터의 파일에 직접 접근하는 방식은 아니고, 이 로컬 폴더 접근은 데스크톱 앱에서 사용하는 흐름입니다. ChatGPT Work 공식 안내

비개발자라면 여기서 Git이나 Repository 같은 것은 신경 쓸 필요가 없습니다.

그냥 Windows 탐색기 폴더라고 생각하면 됩니다.

예를 들어:

01_원본자료와 02_시장자료에 있는 파일들을 읽고 이번 사업의 시장성, 경쟁사, 리스크를 먼저 정리해줘.

정도로 시작하면 됩니다.

3. 중요한 자료는 Google Drive도 연결해둔다

회사 업무는 로컬 파일만 있는 경우가 드뭅니다.

공유받은 Google Docs나 Sheets, Slides가 있을 수 있고, 팀 전체가 Drive를 사용하는 경우도 많습니다.

ChatGPT에 Google Drive를 연결하면 이미 접근 권한을 가지고 있는 Drive의 Docs, Sheets, Slides와 파일을 찾아 활용할 수 있습니다. ChatGPT Google Drive 공식 안내

구조는 이렇게 생각하면 됩니다.

Windows 로컬 폴더
        +
Google Drive
        ↓
   ChatGPT Work

예를 들어:

로컬
- 공급사 PDF
- 내부 Excel

Drive
- 기존 사업계획서
- 회사소개 Slides
- 전년도 보고서

를 동시에 참고해서 새 자료를 만드는 식입니다.

이렇게 하면 매번 모든 자료를 다시 첨부하는 수고를 줄일 수 있습니다.

4. Gemini는 반대로 Google Drive에서 시작하는 게 가장 자연스럽다

Gemini를 사용할 때는 Windows 폴더보다 Google Drive 자체를 업무 시작점으로 잡는 편이 편합니다.

예를 들어 Drive에:

2026 신규사업/
│
├─ 원본
├─ 시장자료
├─ 분석
├─ 보고서
├─ Slides
└─ 최종본

폴더를 만듭니다.

그리고 Gemini in Drive에서 자료를 찾아 요약하거나 새로운 Docs, Sheets, Slides를 생성합니다.

Google은 현재 Drive에서 Gemini를 이용해 Docs 문서, Sheets, Slides 프레젠테이션과 이미지까지 생성하는 Workflow를 제공하고 있습니다. Gemini in Drive 공식 안내

따라서 파일관리 측면에서는:

Drive
 ↓
Gemini
 ↓
Docs
Sheets
Slides

구조가 상당히 자연스럽습니다.

5. 첫 번째 결과물은 바로 PPT가 아니라 ‘분석 메모’가 좋다

자료를 넣자마자:

PPT 15장 만들어줘.

라고 요청하는 것보다 먼저 분석을 시키는 편이 좋습니다.

예를 들어:

현재 자료를 기준으로

시장 규모

경쟁사

회사에 유리한 점

예상 리스크

추가 확인이 필요한 데이터
를 구분해서 정리해줘.
확인되지 않은 내용은 추정하지 말고 별도로 표시해줘.

처럼 요청합니다.

첫 단계에서는 디자인보다 내용이 맞는지 확인하는 것이 중요합니다.

구조는:

Raw Files
   ↓
AI Analysis
   ↓
Fact Check
   ↓
보고서
   ↓
Presentation

순서가 좋습니다.

6. 그다음 전문 한국어 보고서를 만든다

분석 내용이 맞으면 보고서로 바꿉니다.

여기서 Prompt를 조금 구체적으로 주는 것이 좋습니다.

예를 들면:

대표이사가 읽는 사업 검토 보고서로 작성해줘.
너무 AI가 쓴 것처럼 과장하지 말고 한국 회사의 실제 보고서처럼 작성해줘.
결론을 먼저 보여주고 근거를 뒤에 설명해줘.
전문용어는 유지하되 문장은 길지 않게 작성해줘.

이 정도만 해도 문체가 크게 달라집니다.

좋은 임원 보고서는 보통:

Executive Summary

시장 상황

기회

리스크

경제성

실행 방안

의사결정 사항

순서가 읽기 쉽습니다.

중요한 것은 자료를 많이 쓰는 것이 아니라 의사결정할 내용을 빨리 찾게 만드는 것입니다.

7. 숫자가 있으면 보고서보다 먼저 Sheets를 만든다

시장규모, 매출, 비용, 성장률 같은 데이터가 있다면 글에 바로 넣기보다 먼저 Spreadsheet로 정리하는 편이 좋습니다.

예를 들어:

회사
시장점유율
매출
성장률
가격
예상비용

을 표로 정리합니다.

그다음 차트를 만듭니다.

시장 성장률
→ Line Chart

경쟁사 비교
→ Bar Chart

시장 구성
→ Pie / Stacked Chart

매출 vs 비용
→ Bar / Line

이렇게 해야 PPT의 숫자가 보고서와 다르게 나오는 문제를 줄일 수 있습니다.

8. 차트는 Gemini + Sheets가 특히 편하다

Gemini in Sheets는 현재 데이터 분석뿐 아니라 차트와 그래프 생성을 직접 지원합니다.

예를 들어:

X축은 연도, Y축은 매출로 해서 성장 추이를 보여주는 차트를 만들어줘.

라고 요청할 수 있습니다.

또:

경쟁사별 시장점유율을 비교하기 가장 적합한 차트를 만들어줘.

처럼 차트 형태까지 맡길 수도 있습니다.

Gemini가 만든 차트는 Sheets에 넣고 다시 수정할 수 있습니다. Gemini in Sheets 차트 공식 안내

따라서 숫자 중심 보고서라면:

Source Data
    ↓
Google Sheets
    ↓
Gemini Analysis
    ↓
Chart
    ↓
Slides

흐름이 상당히 편합니다.

9. ChatGPT Work는 자료 분석부터 차트와 발표 논리를 같이 묶기 좋다

ChatGPT Work는 문서, Spreadsheet, Presentation을 하나의 작업 흐름 안에서 만들거나 편집할 수 있습니다.

원본 자료나 기존 회사 PPT를 Reference로 넣고 새 결과물을 만드는 것도 가능합니다. ChatGPT Work 문서·프레젠테이션 공식 안내

그래서:

시장자료
 ↓
분석
 ↓
차트
 ↓
해석
 ↓
Executive Summary
 ↓
PPT Storyline

를 한 흐름으로 이어가기 쉽습니다.

특히 차트를 만들 때 숫자만 보여주는 것보다:

이 차트에서 대표가 봐야 하는 핵심 메시지를 한 줄 제목으로 만들어줘.

처럼 요청하면 발표자료가 훨씬 좋아집니다.

예를 들어:

2026년 시장규모 15% 성장

보다

시장 성장보다 경쟁사 진입 속도가 더 빠르다

처럼 의미가 있는 제목을 만들 수 있습니다.

10. 차트 다음에는 설명용 이미지를 만든다

PPT에서 모든 내용을 표와 글자로만 설명하면 읽기 힘듭니다.

이럴 때 생성 이미지를 사용합니다.

예를 들어:

사업 구조

공급망

서비스 이용 흐름

고객 Journey

기술 개념

시장 구조

같은 내용입니다.

ChatGPT에서는 필요한 이미지나 설명용 일러스트를 직접 생성해 발표자료의 시각 자료로 활용하기 좋습니다.

구조는:

숫자
→ Chart

구조
→ Diagram

추상적인 개념
→ Illustration

제품
→ Product / Reference Image

처럼 나누는 편이 좋습니다.

모든 것을 생성 이미지로 만들 필요는 없습니다.

11. Gemini도 Slides 안에서 이미지를 생성할 수 있다

Gemini 역시 Google Slides 안에서 Gemini 3 Pro Image를 이용해 이미지를 생성하고 수정할 수 있습니다.

슬라이드를 열고 이미지가 필요한 위치에서 프롬프트를 이용해 이미지를 만드는 방식입니다. Gemini Slides 이미지 생성 공식 안내

따라서:

Google Slides
      ↓
Gemini
      ↓
Image 생성
      ↓
Slide에 바로 삽입

구조가 가능합니다.

Gemini의 장점은 이미지 자체보다 Slides 안에서 바로 이어서 수정할 수 있다는 것입니다.

12. 이제 PPT Storyline을 만든다

바로 슬라이드를 만들기 전에 먼저 목차만 만듭니다.

대표이사 보고자료라면 예를 들어:

01. 왜 지금 검토해야 하는가

02. 시장은 얼마나 큰가

03. 경쟁사는 어디까지 왔는가

04. 우리에게 어떤 기회가 있는가

05. 예상 수익은 얼마인가

06. 가장 큰 위험은 무엇인가

07. 어떻게 시작할 것인가

08. 오늘 결정해야 할 것은 무엇인가

정도로 잡을 수 있습니다.

이 단계에서 가장 중요한 것은 슬라이드 개수가 아니라 이야기 순서입니다.

13. PPT는 ‘한 장에 한 메시지’를 기본으로 한다

AI에게 PPT를 맡기면 흔히 한 장에 글을 너무 많이 넣습니다.

그래서 처음부터 조건을 주는 것이 좋습니다.

한 슬라이드에는 하나의 핵심 메시지만 넣어줘.
본문은 3~5줄 이내로 줄여줘.
숫자는 가능하면 차트로 표현하고, 구조는 다이어그램으로 바꿔줘.
대표가 5초 안에 핵심을 이해할 수 있게 해줘.

이런 조건을 줍니다.

예를 들어:

슬라이드 제목

한국 시장은 성장하고 있지만
경쟁사 진입 속도가 더 빠르다

그리고 아래에는 설명보다 차트 하나를 둡니다.

이런 형태가 발표자료에 더 적합합니다.

14. ChatGPT Work에서는 기존 회사 PPT를 템플릿으로 활용한다

회사에는 대부분 이미 사용하던 PPT가 있습니다.

회사소개.pptx

이사회보고.pptx

사업계획서.pptx

중 하나를 Reference나 Template로 넣어:

이 파일의 제목 위치, 글자 크기, 표 스타일, 차트 분위기, 페이지 구성을 유지하면서 새 사업자료를 만들어줘.

처럼 요청할 수 있습니다.

ChatGPT Work는 Word, Excel, PowerPoint 또는 Google Workspace 파일을 기반으로 재사용 가능한 Template를 만드는 Workflow를 지원합니다. ChatGPT Work 템플릿 공식 안내

시니어 직급에서는 이 기능이 꽤 중요합니다.

매번 예쁜 디자인을 새로 만드는 것보다 회사에서 이미 사용하는 양식을 유지하는 것이 실제 업무에서는 더 중요하기 때문입니다.

15. 단, Windows Work에서 PowerPoint 직접 편집은 구분해서 봐야 한다

현재 ChatGPT Work 공식 안내에서 중요한 제한이 하나 있습니다.

ChatGPT Work 전체는 Presentation 생성과 편집을 지원하지만, Windows/Desktop Work의 직접 Microsoft PowerPoint 통합은 현재 Excel처럼 포함된 형태가 아닙니다.

따라서 Windows 로컬 폴더에서 자료를 분석한 뒤:

ChatGPT Work Web에서 Presentation 작성

또는:

Google Slides Native 파일 생성

방식을 사용하는 것이 더 자연스럽습니다. ChatGPT Work 공식 안내

이 차이는 미리 알아두는 것이 좋습니다.

16. Gemini는 기존 Google Slides의 스타일을 재사용한다

Gemini에서도 기존 Slides를 Reference로 넣어 비슷한 스타일의 새 발표자료를 만들 수 있습니다.

Google Slides의 Gemini는 Drive의 다른 Presentation을 Reference로 추가하고 기존 Presentation Style을 맞추는 기능을 제공합니다. Gemini Slides 공식 안내

따라서 회사 자료가 이미 Google Slides 중심이라면 상당히 편합니다.

기존 임원보고 Slides
       ↓
Gemini
       ↓
새 보고자료

로 이어갈 수 있습니다.

17. Gemini의 한국어 PPT는 기능별 지원 범위를 확인해야 한다

한국어 자체로 Gemini를 사용하는 것은 문제가 없지만, 현재 Google 공식 문서에서는 일부 전체 Presentation Generation이나 신규 Slides 생성 기능이 데스크톱 영어 전용으로 표시되는 기능이 남아 있습니다.

따라서 한국어 발표자료를 핵심 Workflow로 사용할 경우 실제 회사 계정에서 해당 기능이 한국어로 어느 범위까지 열려 있는지 확인하는 것이 좋습니다. Gemini Slides 언어 지원 안내

한국어가 지원되는 범위에서는 기존 Slides 수정, 내용 작성, Drive 자료 참조, 이미지 생성 등을 조합해서 사용할 수 있습니다.

18. 완성된 PPT는 반드시 PDF로 한 번 확인한다

AI가 만든 Presentation을 최종본이라고 바로 보내지 않는 것이 좋습니다.

먼저 PDF로 변환해서 확인합니다.

확인할 것은:

글자가 잘리지 않았는가

표가 너무 작은가

차트 숫자가 맞는가

이미지가 깨지지 않았는가

페이지마다 제목 톤이 같은가

회사 로고 위치가 일정한가

출처가 빠지지 않았는가

입니다.

Presentation 편집 화면에서는 괜찮아 보여도 PDF에서 줄바꿈이나 레이아웃이 다르게 보일 수 있습니다.

따라서:

Presentation
 ↓
PDF
 ↓
최종 검토

를 마지막 Quality Check로 두는 것이 좋습니다.

19. 발표 대본도 같은 자료에서 같이 만든다

PPT가 완성되면 별도로 발표 Script를 만들 필요가 없습니다.

AI에게:

이 12장 발표자료를 기준으로 7분 발표 대본을 만들어줘.
슬라이드 내용을 그대로 읽지 말고, 각 슬라이드에서 말해야 할 핵심만 작성해줘.
대표이사 보고이므로 결론을 먼저 말하는 방식으로 작성해줘.

라고 요청합니다.

형식은:

Slide 1
30초

Slide 2
40초

Slide 3
30초

처럼 시간까지 붙이는 것이 좋습니다.

마지막에는 예상 질문도 만듭니다.

대표가 물을 질문 10개

재무팀 질문 5개

영업팀 질문 5개

각 질문의 답변

까지 만들어두면 실제 발표 준비가 훨씬 쉬워집니다.

20. 발표가 끝난 뒤에는 Outlook 메일까지 작성한다

최종 자료를 만들었다면 마지막 업무는 공유입니다.

ChatGPT에서는 Outlook Email 연결이 가능하면 Outlook 메일을 검색·읽고, 회신이나 새 메일 초안을 작성하는 Workflow까지 연결할 수 있습니다.

예를 들어:

오늘 대표이사 보고한 사업검토 자료를 임원들에게 보내는 메일을 작성해줘.
너무 딱딱하지 않게 하고, 결정된 내용 3개와 추가 검토사항 2개를 본문에 넣어줘.

처럼 요청합니다.

그러면:

제목

본문

첨부파일 안내

후속 일정

요청사항

까지 구성할 수 있습니다.

Outlook을 실제로 사용하는 환경이라면 위에 표시된 Outlook Email 연결을 해두면 이런 작업을 ChatGPT에서 직접 이어가기 편합니다.

21. Gemini를 쓸 경우 Outlook은 한 단계 떨어져 있다

Gemini Workspace의 Native Mail 환경은 Gmail입니다.

따라서 회사가 Outlook을 쓴다면:

Gemini
 ↓
메일 초안 작성
 ↓
Copy
 ↓
Outlook

방식으로 사용하는 것이 가장 단순합니다.

또는 Outlook 자체의 Copilot을 사용하는 방법도 있습니다.

Microsoft는 Outlook에서 Copilot을 이용해 이메일 Draft를 작성하는 기능을 공식적으로 지원합니다. Outlook Copilot 메일 작성 공식 안내

즉 회사 업무환경이:

Google Workspace + Gmail

이라면 Gemini가 자연스럽고,

Google Drive + Outlook

같은 혼합 환경이라면 ChatGPT Work 쪽이 상대적으로 연결하기 편할 수 있습니다.

22. 파일과 리소스는 AI 안에만 두지 않는다

AI 채팅만 믿고 파일을 관리하는 것은 추천하지 않습니다.

최종 자료는 반드시 회사 저장소에 보관합니다.

가장 단순한 방법은 Google Drive입니다.

2026 신규사업/
│
├─ 01_Source
├─ 02_Data
├─ 03_Report
├─ 04_Charts
├─ 05_Images
├─ 06_Presentation
└─ 07_Final

이 정도면 충분합니다.

Google Docs, Sheets, Slides는 변경 이력을 관리할 수 있고, Drive의 일반 PDF·이미지·기타 파일도 버전을 관리할 수 있습니다. Google Drive 파일 버전 관리 공식 안내

비개발 직군이라면 Git보다 이 방식이 훨씬 현실적입니다.

23. ChatGPT Library는 작업 자료를 다시 찾는 용도로 활용한다

ChatGPT도 업로드하거나 생성한 파일을 Library에서 다시 사용할 수 있습니다.

Google Drive 파일이 연결돼 있다면 Drive 원본과 연결된 상태로 활용할 수도 있습니다. ChatGPT Library 공식 안내

다만 회사의 최종 문서관리 체계는:

Drive
SharePoint
OneDrive

같은 회사 저장소에 두는 것이 좋습니다.

AI Library는 작업 공간, Drive나 회사 문서시스템은 공식 보관소라고 생각하면 이해하기 쉽습니다.

24. 한 번 만든 좋은 자료는 템플릿으로 저장한다

업무 효율을 가장 크게 높이는 것은 AI에게 매번 처음부터 설명하지 않는 것입니다.

한 번 좋은:

대표이사 보고서

신규사업 PPT

시장분석 보고서

주간회의 자료

가 만들어졌다면 그것을 다음 업무의 Template로 사용합니다.

예를 들어:

지난 신규사업 검토자료와 같은 구조로 이번 중국 제조사 검토자료를 만들어줘.

라고 요청할 수 있습니다.

그러면:

제목 구조

Executive Summary

표 디자인

차트 스타일

슬라이드 구성

문체

를 매번 다시 설명할 필요가 줄어듭니다.

25. 비개발 시니어에게 추천하는 ChatGPT Work Workflow

전체를 한 번에 정리하면 이렇습니다.

Windows 업무 폴더
        +
Google Drive
        ↓
ChatGPT Work
        ↓
자료 통합 분석
        ↓
한국어 전문 보고서
        ↓
Spreadsheet / Chart
        ↓
이미지 / Diagram
        ↓
PPT Storyline
        ↓
Presentation
        ↓
PDF 검토
        ↓
발표 Script
        ↓
Outlook Draft
        ↓
Google Drive 최종 보관

장점은 내용을 만들고 해석하고 시각화하는 작업을 하나의 대화 흐름에서 이어가기 쉽다는 점입니다.

26. 비개발 시니어에게 추천하는 Gemini Workflow

Gemini는 Drive 자체를 중심으로 시작합니다.

Google Drive
     ↓
Gemini
     ↓
Docs 보고서
     ↓
Sheets 분석
     ↓
Chart
     ↓
Slides
     ↓
Image
     ↓
PDF
     ↓
Drive Version History

회사 업무가 Google Workspace 중심이라면 상당히 자연스럽습니다.

특히:

자료 공유

공동 편집

댓글

Version History

파일 검색

은 Google Workspace의 강점입니다.

27. 그래서 무엇을 선택하는 것이 좋을까

한국어 전문자료의 내용 완성도, 차트, 이미지, PPT 스토리라인까지 AI에게 많이 맡기고 싶다면 ChatGPT Work를 중심으로 시작하는 편이 좋습니다.

그리고 파일은 Google Drive에 보관합니다.

ChatGPT Work
→ 만드는 곳

Google Drive
→ 관리하는 곳

이라고 생각하면 쉽습니다.

반대로:

회사가 Google Workspace를 중심으로 움직이고 있고 공동 편집과 파일관리가 가장 중요하다면 Gemini가 자연스럽습니다.

Gemini
+
Docs
+
Sheets
+
Slides
+
Drive

가 하나의 생태계 안에서 움직이기 때문입니다.

28. 가장 현실적인 방법은 둘 중 하나만 고집하지 않는 것이다

실제 업무에서는 이렇게 사용해도 됩니다.

자료 분석
한국어 보고서
PPT 스토리라인
이미지

→ ChatGPT Work

그리고:

Sheets
Slides
공동 편집
Version History
최종 파일 관리

→ Google Workspace

즉:

ChatGPT Work
     ↓
콘텐츠 제작
     ↓
Google Workspace
     ↓
회사 업무자산

으로 연결합니다.

현재 두 제품의 장점을 가장 현실적으로 가져가는 방식입니다.

마치며

비개발 시니어에게 AI 업무도구를 선택할 때 중요한 것은 모델의 Benchmark가 아닙니다.

실제 업무는:

자료를 찾고

읽고

판단하고

보고서를 만들고

숫자를 차트로 만들고

개념을 그림으로 설명하고

PPT로 설득하고

PDF로 검토하고

메일로 공유하고

다음 사람이 다시 찾을 수 있게 보관하는 것

까지 이어집니다.

그래서 좋은 AI 업무환경은 문장을 잘 쓰는 AI가 아니라 업무의 처음과 끝을 연결해주는 환경이어야 합니다.

현재 기준으로 가장 현실적인 조합은:

ChatGPT Work
+
Google Drive / Docs / Sheets / Slides
+
Outlook

입니다.

ChatGPT Work가 자료 분석과 전문 한국어 작성, 차트·이미지·프레젠테이션 제작의 중심 역할을 맡고,

Google Workspace가 파일과 공동작업, Version History를 담당하고,

Outlook이 최종 커뮤니케이션을 담당하는 구조입니다.

Gemini는 Google Workspace 안에서 이 과정을 더욱 자연스럽게 연결할 수 있다는 강점이 있습니다.

결국 선택 기준은 단순합니다.

잘 만드는 것이 가장 중요하면 ChatGPT Work 중심.

잘 관리하고 함께 수정하는 것이 가장 중요하면 Gemini + Workspace 중심.

그리고 둘을 같이 쓸 수 있다면,

ChatGPT Work에서 만들고 Google Workspace에서 관리하는 방식이 현재 비개발 시니어의 전문자료 업무에는 가장 실용적인 조합 중 하나입니다.

참고자료

OpenAI — ChatGPT Work 문서·스프레드시트·프레젠테이션
Work에서 문서, Spreadsheet, Presentation을 만들고 기존 PPT·Google Slides 등을 Template로 재사용하는 방법을 확인할 수 있습니다.
공식 자료 보기
OpenAI — ChatGPT Work와 로컬 파일
데스크톱 앱에서 로컬 폴더나 프로젝트에 접근 권한을 주고 작업하는 방식과 웹/모바일과의 차이를 확인할 수 있습니다.
공식 자료 보기
OpenAI — Google Drive 연결
ChatGPT에서 Drive, Docs, Sheets, Slides 자료를 검색하고 활용하는 방법을 확인할 수 있습니다.
공식 자료 보기
Google — Gemini in Drive
Drive에서 Gemini로 Docs, Sheets, Slides와 이미지를 생성하는 Workflow를 확인할 수 있습니다.
공식 자료 보기
Google — Gemini in Sheets
Gemini를 이용한 데이터 분석, 차트·그래프 생성과 Spreadsheet 자동화 기능을 확인할 수 있습니다.
공식 자료 보기
Google — Gemini in Slides
Slides 생성·편집, Drive 자료 참조와 현재 언어별 기능 지원 범위를 확인할 수 있습니다.
공식 자료 보기
Google — Slides 이미지 생성
Gemini 3 Pro Image를 이용해 Slides 내부에서 이미지를 생성하고 수정하는 기능을 확인할 수 있습니다.
공식 자료 보기
Google — Drive 버전 관리
Google 파일과 PDF·이미지 등 일반 Drive 파일의 버전 관리 방법을 확인할 수 있습니다.
공식 자료 보기
Microsoft — Outlook Copilot 메일 작성
Outlook에서 AI를 이용해 업무메일 Draft를 작성하는 공식 Workflow를 확인할 수 있습니다.
공식 자료 보기

공식 자료 기준으로 보면, ChatGPT Work는 Windows 데스크톱에서 로컬 폴더를 직접 활용할 수 있고 Google Drive를 연결하면 Docs·Sheets·Slides의 Native 파일까지 작업에 사용할 수 있습니다. 다만 Windows Work에서 Microsoft PowerPoint 자체를 Excel처럼 직접 조작하는 통합은 현재 별도로 구분되어 있으므로, Presentation 작업은 Work Web이나 Google Slides Workflow로 가져가는 편이 명확합니다.

Gemini는 Drive·Docs·Sheets·Slides가 한 제품군 안에 있기 때문에 파일관리와 공동편집, Version History에서 강점이 있습니다. 특히 Sheets의 Gemini는 차트 생성까지 직접 지원하고 Slides에서는 이미지 생성과 편집이 가능합니다. 다만 일부 신규 Presentation Generation 기능은 현재 공식 문서에서 영어 전용으로 안내되는 영역이 남아 있으므로 한국어 중심 업무에서는 실제 조직 계정에서 제공 범위를 확인하는 것이 좋습니다.

Jev가 뭐냐

Fri, 18 Sep 2026 23:25:12 GMT

Jev가 뭐냐

판단만 빠르게 하는 AI가 나온 이유

최근 AI 모델은 점점 더 많은 일을 할 수 있게 됐습니다.

코드를 작성하고, 웹을 검색하고, Tool을 호출하고, 여러 단계를 거쳐 문제를 해결합니다.

그런데 실제 서비스를 만들다 보면 모든 문제에 이런 큰 모델이 필요한 것은 아닙니다.

예를 들어 이런 판단이 있습니다.

이 문의는 결제 문제인가?

이 요청을 검색으로 보낼까,
DB 조회로 보낼까?

이 메시지는 위험한가?

이 결과를 자동 승인해도 되는가?

이 Agent의 응답을 다시 검토해야 하는가?

각각은 AI가 필요한 문제일 수 있습니다.

하지만 GPT나 Claude 같은 Frontier LLM에게 매번 긴 답변을 생성하게 하는 것은 꽤 비싼 방법이기도 합니다.

TypeSafe AI가 2026년 9월 14일 공개한 Jev는 바로 이 지점을 노립니다.

Jev는 대화를 잘하는 모델이 아닙니다.

코드를 길게 작성하는 모델도 아닙니다.

TypeSafe는 Jev를 새로운 System One Model이라고 부릅니다.

핵심은 단순합니다.

문장을 생성하는 대신, 소프트웨어가 바로 사용할 수 있는 판단을 빠르게 반환합니다.

1. Jev는 무엇이 다른가

일반적인 LLM은 기본적으로 문자열을 생성합니다.

Input
 ↓
LLM
 ↓
Token
 ↓
Token
 ↓
Token
 ↓
Text

결과가 JSON이더라도 기본적으로는 문자열 생성입니다.

{
  "category": "billing",
  "confidence": 0.96
}

Structured Output이나 JSON Schema를 사용하면 결과 형태를 강제할 수 있지만, 내부에서는 여전히 Token을 순차적으로 생성하는 Generative Model입니다.

Jev는 이 방향을 처음부터 다르게 잡았습니다.

Unstructured State
        ↓
       Jev
        ↓
Typed Probabilistic Decision

예를 들어:

사용자 메시지

"카드 결제가 두 번 됐어요."

를 넣고

billing
technical
account
other

중 하나를 판단하도록 하면 Jev는 긴 설명을 생성하는 대신 각 선택지에 대한 판단과 확률을 반환하는 구조입니다.

개념적으로는:

billing      0.96
technical    0.02
account      0.01
other        0.01

처럼 사용할 수 있습니다.

그래서 TypeSafe는 Jev를

“frontier-intelligence function call”

에 가깝다고 설명합니다.

2. 챗봇보다 `if`문에 가까운 AI다

Jev를 이해하기 가장 쉬운 방법은 챗봇보다 똑똑한 조건문이라고 생각하는 것입니다.

기존 코드라면 이런 식입니다.

if message.contains("결제") {
    route = .billing
} else if message.contains("비밀번호") {
    route = .account
}

문제는 현실의 언어가 이렇게 단순하지 않다는 것입니다.

"결제가 안 된 것 같은데 돈은 빠져나갔어요."

"카드는 정상인데 주문이 두 번 잡혔습니다."

"환불했다고 했는데 아직 입금이 안 됐어요."

Rule을 계속 늘리기 시작하면 유지하기 어려워집니다.

Jev가 노리는 영역은 이 사이입니다.

Hard-coded if

        ↓

Jev

        ↓

Full LLM Agent

규칙만으로 처리하기에는 애매하지만,

GPT나 Claude Agent까지 호출하기에는 과한 판단입니다.

3. TypeSafe는 이것을 System One Model이라고 부른다

이름은 Daniel Kahneman의 《Thinking, Fast and Slow》에서 가져왔습니다.

Kahneman은 인간의 사고를 크게 두 가지로 설명했습니다.

System 1

빠름
직관적
즉각적

그리고

System 2

느림
숙고
복잡한 추론

TypeSafe는 이 개념을 AI Model Architecture에 적용했습니다.

기존 Reasoning LLM이 상대적으로:

Input
 ↓
Reasoning
 ↓
Generation
 ↓
Answer

에 가깝다면,

Jev는:

Input
 ↓
Decision

에 집중합니다.

그래서 모델 이름도 System One Models입니다.

Jev라는 이름은 경제학자 William Stanley Jevons에서 가져왔습니다.

4. Jev는 작은 LLM이 아니다

여기서 가장 쉽게 오해할 부분입니다.

Jev를 단순히

작은 LLM

이라고 보면 정확하지 않습니다.

TypeSafe는 Jev를 기존 Language Model을 줄여 만든 모델이 아니라 결정이라는 다른 Task를 위해 새로 만든 Architecture라고 설명합니다.

학습 방식도 RLHF가 아닙니다.

TypeSafe는 자체 학습 방법을:

RLCD

라고 부릅니다.

Reinforcement Learning for Calibrated Decisions입니다.

기존 LLM이 주로:

사람이 좋아하는 답변

검증 가능한 정답

을 최적화한다면,

Jev는:

정확한 판단
+
그 판단이 얼마나 확실한지

를 함께 학습하는 방향입니다.

즉 목표 함수 자체가 다릅니다.

5. 가장 중요한 특징은 Confidence다

자동화 시스템에서 AI가 어려운 이유 중 하나는 AI가 틀릴 때 자신이 틀렸다는 사실을 모르는 것입니다.

예를 들어 실제 정확도가 95%인 모델이 있다고 해보겠습니다.

문제는 나머지 5%입니다.

모델이 모든 결과에:

confidence = 0.99

를 내놓는다면 자동화하기 어렵습니다.

반대로 모델의 Confidence가 실제 정확도와 잘 맞는다면 시스템을 이렇게 만들 수 있습니다.

Confidence > 0.95
       ↓
자동 처리

0.70 ~ 0.95
       ↓
큰 LLM으로 재검토

< 0.70
       ↓
사람에게 전달

TypeSafe가 Jev에서 특히 강조하는 것이 바로 이 Calibrated Probability입니다.

단순히 답을 반환하는 것이 아니라 불확실성도 같이 반환합니다.

6. 이게 Agent 시스템에서는 꽤 중요하다

최근 Agent Architecture에서 가장 자주 반복되는 작업 중 하나가 Routing입니다.

예를 들어:

User Request
     ↓
Router
     ↓
 ┌───┼─────────┐
Search DB   Coding Agent

Router도 LLM으로 만들 수 있습니다.

하지만 요청이 들어올 때마다 Frontier Model을 호출하면 비용과 Latency가 커집니다.

Jev 같은 모델을 Router로 넣으면 구조가 달라집니다.

User Request
       ↓
      Jev
       ↓
┌──────┼─────────┐
Search DB     Agent

그리고 Jev의 Confidence까지 사용합니다.

Search Agent     0.87
Database Tool    0.08
Human Review     0.05

가 나오면 Search Agent로 보냅니다.

Confidence가 낮다면:

Research Agent    0.42
Database Tool     0.38
Human Review      0.20

바로 실행하지 않고 큰 모델이나 사람에게 판단을 넘길 수 있습니다.

7. Multi-Agent에서도 Router 역할로 잘 맞는다

멀티에이전트 시스템을 생각해보면 더 이해하기 쉽습니다.

                    Main System
                         │
             ┌───────────┼───────────┐
             │           │           │
        Coding Agent  Research   Security
                       Agent      Agent

모든 요청을 Main LLM이 분석하고 적절한 Agent에게 전달할 수도 있습니다.

하지만 요청량이 많다면 Routing 자체가 상당한 비용이 됩니다.

중간에 Jev를 넣을 수 있습니다.

Request
   ↓
  Jev
   ↓
Agent Routing
   ↓
선택된 Agent만 호출

즉 Jev가 Agent를 대체하는 것이 아닙니다.

Agent가 필요한지를 먼저 판단하는 앞단의 Decision Layer가 되는 것입니다.

8. Skill + MCP 구조와도 잘 맞는다

최근 Agent Architecture는 모든 기능을 Agent로 만들기보다:

Skill
+
MCP Tool

을 활용하는 방향으로 가고 있습니다.

예를 들어 사용자의 요청이 들어왔을 때:

Swift Migration Skill

Release Skill

GitHub MCP

Research Agent

중 어디로 보낼지 결정해야 합니다.

구조는 이렇게 만들 수 있습니다.

Request
   ↓
  Jev
   ↓
 ┌──────┬────────┬────────────┐
Skill   MCP     Research Agent

즉 Jev는 Agent Orchestrator 전체를 대신하기보다 Orchestrator가 반복적으로 하는 작은 판단을 줄이는 역할에 가깝습니다.

9. Moderation과 Guardrail도 대표적인 사용처다

두 번째로 잘 맞는 영역은 Moderation입니다.

기존 구조는:

Input
 ↓
LLM
 ↓
위험 여부 판단

입니다.

하지만 서비스 요청마다 큰 모델을 호출한다면 부담이 됩니다.

Jev는 이런 형태의 판단에 맞게 설계됐습니다.

Safe          0.96
Harmful       0.03
Uncertain     0.01

또는:

Prompt Injection

Yes   0.91
No    0.09

처럼 사용할 수 있습니다.

특히 Agent 시스템에서는:

User Input
    ↓
Guardrail
    ↓
Agent
    ↓
Tool Call

구조에서 매우 낮은 Latency의 판단 모델이 유용할 수 있습니다.

10. Agent의 출력 검증에도 사용할 수 있다

Jev는 입력만 분류하는 모델로 볼 필요도 없습니다.

Agent가 생성한 결과를 평가하는 Layer로도 사용할 수 있습니다.

예를 들어 Coding Agent가 수정 결과를 만들었습니다.

Coding Agent
      ↓
Code Change
      ↓
Jev Verification

여기서:

요청을 충족했는가?

YES 0.94
NO  0.06

또는:

Security Risk

Low       0.82
Medium    0.15
High      0.03

같은 판단을 사용할 수 있습니다.

물론 실제 Build와 Test를 대체하는 것은 아닙니다.

Compiler
Test
Static Analysis

처럼 결정적인 검증이 가능한 부분은 코드로 검증해야 합니다.

Jev는 그 사이의 애매한 판단을 담당하는 것이 더 적합합니다.

11. 그래서 `검증 가능한 것은 코드로`가 중요하다

Jev를 쓴다고 모든 조건문을 AI로 바꿀 필요는 없습니다.

예를 들어:

HTTP Status == 200

은 코드로 판단하면 됩니다.

Build Success

도 Tool 결과를 보면 됩니다.

Unit Test Passed

역시 AI가 필요 없습니다.

반면:

이 리뷰 의견이 blocking issue인가?

이 고객 문의는 긴급한가?

이 검색 결과가 질문과 관련 있는가?

이 요청은 어느 Agent에게 보내야 하는가?

같은 것은 Rule로 만들기 어렵습니다.

그래서 좋은 구조는:

Hard Logic
→ Code

Ambiguous Decision
→ Jev

Deep Reasoning
→ LLM / Agent

입니다.

12. 일반 LLM의 Structured Output과는 뭐가 다를까

GPT나 Claude도 JSON Schema를 사용할 수 있습니다.

예를 들어:

{
  "route": "research",
  "confidence": 0.91
}

를 반환하도록 만들 수 있습니다.

그렇다면 굳이 Jev가 필요한가라는 질문이 생깁니다.

차이는 Structured Output을 지원하느냐가 아니라 모델이 무엇을 위해 설계됐느냐입니다.

일반 LLM은:

Generative Model
        ↓
Schema Constraint
        ↓
Structured Output

입니다.

Jev는:

Decision Model
       ↓
Typed Decision

자체가 목적입니다.

그리고 TypeSafe 설명에 따르면 Jev는 모든 결과를 순차 Token Generation이 아니라 병렬로 계산합니다.

문장을 생성하지 않기 때문에 Output Generation Cost도 거의 없습니다.

13. Type Safety라는 이름도 여기에서 나온다

TypeSafe가 특히 강조하는 부분이 Output Type입니다.

일반 LLM에서는 이런 문제가 생길 수 있습니다.

{
  "confidence": "very high"
}

원래 Double을 기대했는데 문자열이 올 수 있습니다.

또는:

{
  "route": "some_new_route"
}

처럼 Schema 밖의 값을 생성할 수도 있습니다.

Structured Output 기능을 사용하면 이런 문제를 상당히 줄일 수 있습니다.

Jev는 처음부터 가능한 Output Domain을 정하고 그 안에서 결정을 반환하도록 설계됐습니다.

TypeSafe는 이 특성 때문에 type error가 구조적으로 발생하지 않는다고 설명합니다.

이 부분과 의미적으로 잘못된 판단은 구분해야 합니다.

Wrong Type

과

Wrong Decision

은 다른 문제입니다.

Jev도 판단 자체는 틀릴 수 있습니다.

14. “Jev는 Hallucination이 없다”는 표현은 조심해서 봐야 한다

TypeSafe 공식 자료에는 Jev가 can't hallucinate, 홈페이지에는 Zero Hallucinations라는 강한 표현이 있습니다.

이건 그대로 받아들이기보다 어떤 의미인지 구분해서 보는 게 좋습니다.

Jev는 자유로운 문자열을 생성하지 않습니다.

따라서:

존재하지 않는 API 이름 생성

없는 Tool 이름 생성

Schema 밖 필드 생성

같은 Generative Hallucination Surface는 크게 줄어듭니다.

특히 Type Schema를 벗어나는 Output은 구조적으로 막을 수 있습니다.

하지만:

billing을 technical로 잘못 분류

하는 것은 여전히 가능합니다.

즉:

Type Error ❌

와

Decision Error 가능

을 구분해야 합니다.

이 때문에 Confidence Calibration이 중요합니다.

15. 속도는 Jev의 가장 눈에 띄는 부분이다

TypeSafe 공식 발표에 따르면 Jev의 End-to-end Response Time은 현재 대략:

70ms ~ 500ms

범위입니다.

회사는 같은 수준의 System One 작업에서 Frontier LLM 대비:

40x ~ 200x

빠를 수 있다고 설명합니다.

Workflow Evaluation에서는 최대:

193.6x faster

라는 수치도 제시합니다.

다만 이 숫자는 반드시 맥락을 같이 봐야 합니다.

TypeSafe도 직접 밝히고 있습니다.

해당 Workflow는 System One 형태에 적합한 작업이고, 이 수치가 실제 사용 사례에서 기대할 수 있는 효과 중 높은 편일 가능성이 있다고 설명합니다.

따라서:

Jev가 GPT보다 193배 빠르다

라고 일반화하면 안 됩니다.

정확한 표현은:

TypeSafe가 설계한 System One Workflow Evaluation에서는 최대 약 193배 빠른 결과가 나왔다.

정도가 적절합니다.

16. 비용도 같은 방식으로 봐야 한다

현재 공개 가격은:

Input

$0.042 / 1M tokens

입니다.

즉:

$42 / 1B input tokens

입니다.

TypeSafe는 Output Token은 별도로 과금하지 않는다고 설명합니다.

회사 Workflow Evaluation에서는 Frontier LLM 대비 최대:

444.6x cheaper

라는 결과도 공개했습니다.

하지만 이 역시 Jev에 유리한 Decision-oriented Workflow에서 측정된 회사 자체 Evaluation입니다.

실제 비용 효과는 자신의 서비스 Workflow에서 직접 측정하는 편이 안전합니다.

17. 왜 이렇게 빠를까

일반 LLM은 Autoregressive Generation을 사용합니다.

Token 1
 ↓
Token 2
 ↓
Token 3
 ↓
Token 4

앞 Token이 생성돼야 다음 Token을 만들 수 있습니다.

문장이 길어질수록 Latency도 늘어납니다.

Jev는 문자열을 생성하지 않습니다.

TypeSafe는 Parallel Sampler를 이용해 필요한 결정을 한 Query에서 병렬로 출력한다고 설명합니다.

예를 들어 질문이:

이 사용자는 이탈할 가능성이 높은가?

이 요청은 사기일 가능성이 있는가?

Human Review가 필요한가?

세 개라면 각각의 답변 문장을 순차적으로 만드는 것이 아니라 여러 판단을 동시에 계산하는 방향입니다.

자동화 시스템에서는 이 차이가 큽니다.

18. 실시간 서비스에는 꽤 흥미로운 구조다

100ms 안팎의 판단이 가능해진다면 LLM을 넣기 어려웠던 영역에도 AI를 사용할 수 있습니다.

예를 들어:

게임 상태 판단

실시간 추천

광고 Routing

Fraud Risk

Moderation

Search Ranking

Agent Routing

같은 영역입니다.

TypeSafe는 실제 Demo로 Doom 게임 상태를 Jev가 판단하면서 움직이는 사례도 공개했습니다.

이미지 자체를 보는 Vision Model은 아니고, 게임 상태를 구조화된 Text/Data로 전달한 뒤 판단하는 방식입니다.

19. 대량 데이터 처리에도 성격이 잘 맞는다

LLM으로 수백만 개의 Record를 하나씩 처리하면 비용과 시간이 빠르게 커집니다.

예를 들어:

10,000,000 고객

↓

각 고객의 churn 가능성 평가

를 Frontier LLM으로 처리하면 꽤 큰 작업입니다.

Jev가 노리는 영역은 이런 Map-style Decision Workload입니다.

Record 1 → Score
Record 2 → Score
Record 3 → Score
...

같은 작업입니다.

문장을 생성할 필요가 없기 때문에 Decision Model의 장점이 크게 나타날 수 있습니다.

20. 모든 작업에 Jev가 좋은 것은 아니다

Jev는 의도적으로 문자열 생성을 포기했습니다.

따라서 다음 작업에는 적합하지 않습니다.

코드 작성

문서 작성

이메일 작성

소설 작성

사용자와 긴 대화

복잡한 설명

새로운 설계 생성

이건 GPT, Claude, Gemini 같은 Generative Model이 훨씬 자연스럽습니다.

또:

Repository 전체 분석

장애 원인 탐색

Research

Architecture 설계

같이 장시간 Reasoning과 탐색이 필요한 작업도 Jev 하나로 해결하려는 문제는 아닙니다.

21. Jev와 LLM을 경쟁 관계로 볼 필요가 없다

실제 Architecture에서는 둘을 같이 쓰는 형태가 더 자연스럽습니다.

예를 들어:

User Request
      ↓
     Jev
      ↓
┌─────┼──────────┐
Tool  Skill     Agent
                ↓
            GPT / Claude

또는:

Agent Output
     ↓
    Jev
     ↓
Confidence High?
  │          │
 YES        NO
  ↓          ↓
사용       재검토

입니다.

Jev가 빠른 판단을 담당하고,

큰 LLM은 실제 Reasoning과 Generation을 담당합니다.

이렇게 보면 Jev의 포지션이 훨씬 명확해집니다.

22. 멀티에이전트 비용을 줄이는 앞단 Router로도 볼 수 있다

Agent가 많아질수록 Routing 자체도 중요한 문제가 됩니다.

Main Agent
 ├─ Coding Agent
 ├─ Security Agent
 ├─ Research Agent
 ├─ Data Agent
 └─ Release Agent

매번 Main LLM에게:

어느 Agent가 이걸 처리해야 하지?

라고 물어볼 수도 있습니다.

하지만 이 판단이 충분히 정형화됐다면 Jev가 앞에서 처리할 수 있습니다.

Request
 ↓
Jev Router
 ↓
Agent

이렇게 하면 모든 요청에 Main Reasoning Model을 먼저 호출하지 않아도 됩니다.

특히 Agent 요청량이 많아질수록 의미가 커질 수 있습니다.

23. Confidence Gate가 실무에서 핵심이 될 수 있다

Jev에서 가장 개발자다운 부분은 모델보다 Architecture Pattern일 수 있습니다.

예를 들어:

Jev
 ↓
Confidence

결과를 그대로 사용하는 것이 아니라 Threshold를 둡니다.

> 0.95

자동 실행

0.70 ~ 0.95

Frontier LLM 검토

< 0.70

Human Review

이렇게 구성하면 AI를 Binary Decision Maker가 아니라 Risk-aware Decision Component로 사용할 수 있습니다.

이 패턴은:

Agent Routing

Moderation

Fraud

Approval

Quality Gate

전부에 적용할 수 있습니다.

24. Jev가 정말 중요한 이유는 모델보다 인터페이스일 수도 있다

지금까지 AI API의 중심은 대부분 Text였습니다.

String In
 ↓
Model
 ↓
String Out

Software에서는 다시 이 문자열을 해석합니다.

String
 ↓
Parse
 ↓
Validate
 ↓
Business Logic

Jev가 제안하는 인터페이스는 다릅니다.

State
 ↓
Model
 ↓
Typed Decision
 ↓
Code

AI가 사람에게 말을 잘하는 Component가 아니라 프로그램 내부에서 호출되는 Decision Primitive에 가까워집니다.

이 방향이 실제로 자리 잡는다면 AI Architecture에도 꽤 큰 변화가 생길 수 있습니다.

25. 아직은 Early Access라는 점도 중요하다

현재 Jev는 Early Access입니다.

2026년 9월 14일 처음 공개됐고, TypeSafe는 Waitlist 사용자부터 순차적으로 Access를 제공하고 있습니다.

따라서 아직 확인해야 할 것이 많습니다.

실제 Production Reliability

Traffic이 늘었을 때 Latency

Pricing 지속 가능성

Domain별 Accuracy

Confidence Calibration

Long-term Stability

등입니다.

특히 현재 공개된 대부분의 성능 자료는 TypeSafe 자체 Evaluation입니다.

회사는 이 점을 상당히 솔직하게 밝히고 있습니다.

Workflow가 내부 Model Capabilities 팀에 의해 만들어졌기 때문에 Bias가 있을 가능성도 인정하고 있습니다.

26. Benchmark 숫자보다 실제 Workflow 평가가 더 중요하다

TypeSafe는 Standard Benchmark 중심 경쟁에도 비판적인 입장입니다.

공개 Benchmark에 맞춰 반복적으로 Model을 개선하면 결국 Benchmark 자체에 Overfit될 수 있다는 이유입니다.

그래서 Jev는 일반적인 Benchmark Table보다 실제 Automation Workflow를 평가 대상으로 삼고 있습니다.

이 접근 자체는 꽤 흥미롭습니다.

개발자 입장에서 중요한 것도 결국:

Benchmark Score

보다

우리 Workflow에서

얼마나 정확한가?

얼마나 빠른가?

얼마나 싼가?

Confidence가 실제로 믿을 만한가?

이기 때문입니다.

27. 실제 도입을 검토한다면 이렇게 보는 게 좋다

Jev를 적용할 후보를 찾을 때는 먼저 현재 시스템에서 Frontier LLM이 이런 작업을 하고 있는지 확인하면 됩니다.

분류

점수화

라우팅

검증

Filter

Guardrail

그리고 질문합니다.

이 작업에서 실제로 긴 Text Generation이 필요한가?

필요하지 않다면 Jev 같은 Decision Model을 검토할 가치가 있습니다.

반대로:

복잡한 추론

코드 생성

대화

문서 생성

이 필요하다면 기존 LLM을 유지하는 편이 맞습니다.

28. 개발자 입장에서 가장 현실적인 구조

현재 기준으로는 이런 Architecture가 가장 이해하기 쉽습니다.

                    Request
                       ↓
                      Jev
                       ↓
             ┌─────────┼─────────┐
             │         │         │
           Tool      Skill     Agent
                                 │
                           GPT / Claude

그리고 마지막에 다시 Jev를 붙일 수도 있습니다.

Agent Result
     ↓
    Jev
     ↓
Verification / Score
     ↓
Code

즉:

Jev
→ 빠른 판단

LLM
→ 깊은 추론과 생성

Code
→ 확실한 규칙

으로 역할을 나누는 것입니다.

마치며

Jev가 흥미로운 이유는 GPT나 Claude보다 더 똑똑한 새로운 Frontier Model이 나왔기 때문이 아닙니다.

애초에 목표가 다릅니다.

기존 LLM은:

생각하고
말하고
생성한다.

Jev는:

판단한다.

에 집중합니다.

TypeSafe가 강조하는 것도 바로 이 차이입니다.

긴 Text를 만들 필요가 없는 Software Decision에 매번 Generative LLM을 사용하는 것이 과한 것은 아닌가라는 질문입니다.

그래서 Jev를 가장 단순하게 표현하면:

빠르고 저렴한 AI 판단 함수

에 가깝습니다.

특히:

Routing
Classification
Scoring
Verification
Moderation
Guardrail

같은 영역에서 의미가 있습니다.

반대로:

Coding
Research
Writing
Long-running Reasoning

은 여전히 LLM과 Agent의 영역입니다.

결국 앞으로 AI 시스템이 이런 식으로 나뉠 가능성도 있습니다.

확실한 규칙
→ Code

애매하지만 빠른 판단
→ Jev

복잡한 추론
→ LLM

장기적인 작업
→ Agent

모든 문제에 가장 큰 LLM을 호출하는 방식에서 벗어나 문제의 성격에 맞는 Intelligence Layer를 선택하는 구조입니다.

Jev가 실제 Production 환경에서도 현재 공개된 속도와 Calibration을 유지할 수 있을지는 더 지켜봐야 합니다.

하지만 방향 자체는 꽤 흥미롭습니다.

AI를 더 크게 만드는 경쟁과 별개로,

AI를 더 작은 Software Primitive로 만드는 경쟁도 시작되고 있습니다.

참고자료

TypeSafe AI — Introducing System One Models and Jev
Jev의 Architecture, RLCD, Parallel Sampling, Structured Decision, Confidence, Pricing과 Workflow Evaluation을 설명한 공식 발표입니다.
TypeSafe AI 공식 발표
TypeSafe AI — Workflow Evals
Jev와 Frontier LLM을 실제 Decision Workflow에 넣어 Accuracy·Latency·Cost를 비교한 평가 방법과 Query를 확인할 수 있습니다.
TypeSafe Workflow Evals
TypeSafe AI — System One Models
Jev의 현재 가격, Typed Decision, Calibration과 Automation 중심 설계를 정리한 공식 제품 페이지입니다.
TypeSafe AI 공식 사이트
TypeSafe AI — Lies, Damned Lies, and Benchmarks
TypeSafe가 Standard Benchmark Table보다 Workflow Evaluation을 사용하는 이유와 Benchmark Overfitting에 대한 입장을 설명합니다.
TypeSafe AI Benchmark 관련 글

TypeSafe 공식 자료 기준으로 보면, Jev는 2026년 9월 14일 Early Access로 공개된 첫 System One Model입니다. 일반 LLM처럼 문자열을 생성하지 않고 미리 정의된 타입의 판단과 확률을 반환하도록 설계됐으며, 회사는 이를 위해 RLCD와 Parallel Sampler라는 별도 Training·Inference 방식을 사용한다고 설명합니다.

현재 공개 가격은 입력 100만 Token당 $0.042이며 Output Token은 별도 과금하지 않습니다. TypeSafe는 현재 서비스 Latency를 약 70~500ms라고 밝히고 있으며, 자체 Workflow Evaluation에서는 최대 193.6배 빠르고 444.6배 저렴한 결과를 공개했습니다. 다만 회사 역시 이 수치가 실제 효과 중 높은 편일 가능성이 있고 Evaluation 설계에 내부 Bias가 존재할 수 있다는 점을 명시하고 있습니다.

또 하나 주의할 부분은 TypeSafe가 사용하는 Zero Hallucinations 표현입니다. Jev의 Output Schema가 미리 정해져 있기 때문에 Schema 밖의 값이나 Type Error를 생성하지 않는다는 의미에서는 강한 구조적 보장이 가능합니다. 하지만 Model이 잘못된 선택지를 높은 확률로 고르는 Decision Error 자체가 불가능하다는 의미로 받아들이면 안 됩니다. 실제 Production 적용에서는 Calibration과 Confidence Threshold를 반드시 함께 평가하는 것이 중요합니다.

멀티에이전트는 이렇게 시작하면 된다 《3》

Fri, 18 Sep 2026 05:53:16 GMT

멀티에이전트는 이렇게 시작하면 된다

Codex와 Claude Code로 만드는 가장 단순한 구조

멀티에이전트를 처음 적용하려고 하면 구조부터 크게 그리기 쉽습니다.

Main Agent
 ├─ Coding Agent
 ├─ Test Agent
 ├─ Review Agent
 ├─ Security Agent
 └─ Research Agent

여기에 MCP Server를 붙이고 Skill을 만들고 Agent마다 Model과 권한까지 따로 설정합니다.

그런데 실제 Codex와 Claude Code에서는 처음부터 이렇게 만들 필요가 없습니다.

두 도구 모두 기본 Agent 자체가 이미

Repository 탐색
파일 수정
Shell 실행
Test
Git
Tool 호출

을 처리할 수 있습니다.

멀티에이전트의 시작점은 Agent를 여러 개 만드는 것이 아닙니다.

하나의 Agent로 시작하고, Main Context가 불필요하게 커지거나 독립적으로 처리할 작업이 생길 때만 Subagent를 분리하는 것이 훨씬 자연스럽습니다.

전체 흐름을 먼저 보면 이렇습니다.

Single Agent
     ↓
Project Instructions
     ↓
Skills
     ↓
Subagents
     ↓
MCP
     ↓
독립 Runtime이 필요하면 A2A

Codex와 Claude Code 모두 이 방향으로 구성할 수 있습니다.

1. 먼저 Single Agent로 시작한다

Codex라면 Repository에서 Codex를 시작하는 것만으로 기본적인 Agent 환경이 만들어집니다.

Codex

├─ 파일 읽기
├─ 코드 검색
├─ 파일 수정
├─ Shell 실행
├─ Build
└─ Test

Claude Code도 비슷합니다.

cd MyProject
claude

기본 구조는 다음과 같습니다.

Developer
    ↓
Coding Agent
    ↓
Repository
    ↓
Build / Test / Git

처음부터 Test Agent나 Review Agent를 만들 이유가 없습니다.

우선 Main Agent 하나에게 실제 작업을 맡겨봅니다.

이 프로젝트의 인증 구조를 분석하고
로그아웃 시 Token이 제대로 삭제되는지 확인해줘.

또는:

Swift 6 Concurrency Error를 확인하고
수정한 뒤 Test까지 실행해줘.

이 상태에서 잘 처리된다면 Agent를 더 추가할 필요가 없습니다.

2. 프로젝트 공통 규칙부터 Agent에게 알려준다

Agent를 추가하기 전에 먼저 해야 할 일이 있습니다.

프로젝트 규칙을 명확하게 만드는 것입니다.

Codex에서는 AGENTS.md를 사용할 수 있습니다.

예를 들어 Repository Root에:

AGENTS.md

를 두고 다음과 같은 규칙을 작성합니다.

# Project Rules

- Swift 6 strict concurrency를 유지한다.
- UI 변경은 SwiftUI를 우선한다.
- 새로운 Dependency 추가 전 반드시 확인한다.
- 수정 후 관련 Unit Test를 실행한다.
- UIKit 코드는 기존 모듈에서만 유지한다.

Codex는 작업을 시작하면서 이 파일을 읽고 프로젝트 지침으로 사용합니다.

Claude Code에는 같은 역할을 하는 CLAUDE.md가 있습니다.

CLAUDE.md

예를 들어:

# Development Rules

- 새로운 View는 SwiftUI로 작성한다.
- ViewModel은 @MainActor를 기본으로 한다.
- Repository Protocol은 Domain Module에 둔다.
- Test 없이 Business Logic을 변경하지 않는다.

이렇게 하면 Agent에게 매번 긴 Prompt를 반복할 필요가 없습니다.

Developer
    ↓
짧은 요청
    ↓
AGENTS.md / CLAUDE.md
    ↓
프로젝트 규칙 반영

멀티에이전트를 만들기 전에 먼저 이 단계부터 정리하는 것이 좋습니다.

3. 반복되는 작업은 Agent가 아니라 Skill로 만든다

개발하다 보면 계속 반복되는 요청이 생깁니다.

예를 들어:

Swift 6 Migration

Feature Module 생성

PR Review

Release 준비

Dependency Update

같은 작업입니다.

매번 Prompt로 절차를 설명할 필요는 없습니다.

Codex와 Claude Code 모두 SKILL.md 기반의 Custom Skill을 지원합니다.

예를 들어 Swift 6 Migration Skill을 만든다고 해보겠습니다.

swift6-migration/
 └─ SKILL.md

내용은 다음 정도가 될 수 있습니다.

---
name: swift6-migration
description: Swift 6 concurrency 오류를 분석하고 수정할 때 사용한다.
---

# Workflow

1. 먼저 프로젝트를 Build한다.
2. Concurrency Diagnostic을 수집한다.
3. Sendable 문제를 분류한다.
4. Actor Isolation을 확인한다.
5. @MainActor 적용 여부를 검토한다.
6. 최소 범위만 수정한다.
7. Build한다.
8. 관련 Test를 실행한다.

이제:

Swift 6 오류 고쳐줘.

라고 요청하면 Agent가 해당 Skill을 선택할 수 있습니다.

구조가:

Main Agent
     ↓
Swift 6 Migration Skill
     ↓
Build / Search / Edit / Test

이 됩니다.

별도의 SwiftMigrationAgent를 만들 필요가 없습니다.

4. Codex에서는 Skill을 프로젝트에 둘 수 있다

Codex는 Repository에서 Skill을 자동으로 찾을 수 있습니다.

프로젝트 전용 Skill이라면:

.agents/
 └─ skills/
     └─ swift6-migration/
         └─ SKILL.md

같은 식으로 둘 수 있습니다.

개인적으로 여러 프로젝트에서 사용하는 Skill이라면 사용자 범위에 둘 수도 있습니다.

Codex는 처음부터 모든 SKILL.md 내용을 Context에 넣지 않습니다.

먼저:

Skill Name
+
Description

정도만 확인하고,

실제 작업과 관련 있다고 판단되면 전체 Skill을 읽습니다.

즉:

100개의 Skill

이 있다고 해서 100개의 전체 Prompt가 모두 Context에 들어가는 구조는 아닙니다.

이 Progressive Disclosure가 Skill이 중요한 이유 중 하나입니다.

OpenAI 공식 문서에서도 Skill을 Codex와 ChatGPT에서 사용하는 재사용 가능한 Workflow 단위로 정의하고 있습니다.

5. Claude Code에서도 같은 방식으로 Skill을 만들 수 있다

Claude Code도 Custom Skill을 지원합니다.

프로젝트에서만 사용할 Skill은:

.claude/
 └─ skills/
     └─ ios-release/
         └─ SKILL.md

형태로 둘 수 있습니다.

사용자 전체에서 사용할 Skill은:

~/.claude/skills/

에 둘 수 있습니다.

예를 들어 Release Skill이라면:

---
name: ios-release
description: TestFlight 배포를 준비할 때 사용한다.
---

1. working tree가 clean인지 확인한다.
2. release branch인지 확인한다.
3. test를 실행한다.
4. version과 build number를 확인한다.
5. archive를 생성한다.
6. TestFlight upload 전 사용자 승인을 받는다.

구조는:

Claude Code
     ↓
Release Skill
     ↓
Git / Xcodebuild / Fastlane

정도가 됩니다.

여기까지는 아직 멀티에이전트가 아닙니다.

하지만 대부분의 반복적인 개발 업무는 여기까지만으로도 상당 부분 처리할 수 있습니다.

6. 언제 Subagent를 추가해야 할까

Agent를 추가하는 기준은 역할 이름이 아닙니다.

Main Agent의 Context에서 분리했을 때 이득이 있는가가 더 중요합니다.

예를 들어 이런 요청이 있다고 해보겠습니다.

이번 PR을 검토하고
Architecture 문제와
테스트 누락,
최신 Apple API 사용 여부까지 확인해줘.

Main Agent 하나가 전부 하면:

Repository 탐색
+
Architecture 분석
+
Test 분석
+
Apple 문서 조사
+
PR Diff

가 모두 하나의 Context에 쌓입니다.

이럴 때 작업을 나누는 것이 좋습니다.

Main Agent
   │
   ├─ Explorer
   │    └─ 코드 구조 조사
   │
   ├─ Test Reviewer
   │    └─ 테스트 누락 조사
   │
   └─ Docs Researcher
        └─ 최신 API 확인

각 Subagent는 자기 Context만 사용하고 결과만 Main Agent에게 돌려줍니다.

7. Codex는 이미 Subagent Workflow를 기본 지원한다

현재 Codex에서는 Subagent Workflow가 기본적으로 활성화되어 있습니다.

기본 Agent도 제공됩니다.

대표적으로:

default
worker
explorer

가 있습니다.

explorer는 읽기 중심 탐색에 적합하고,

worker는 구현과 수정 작업에 적합합니다.

예를 들어 이런 식으로 요청할 수 있습니다.

explorer agent를 사용해서
이 프로젝트의 인증 구조를 먼저 조사해줘.

동시에 다른 agent에게
관련 Unit Test가 어디까지 작성되어 있는지 확인시켜줘.

결과를 합쳐서 수정 계획만 만들어줘.

그러면:

Main Codex
   │
   ├─ Explorer #1
   │    └─ Auth Architecture
   │
   └─ Explorer #2
        └─ Tests

형태로 병렬 작업을 수행하고 Main Agent가 결과를 합칩니다.

8. Codex의 Custom Agent도 프로젝트 단위로 만들 수 있다

자주 사용하는 Specialist가 있다면 직접 정의할 수도 있습니다.

프로젝트 범위에서는:

.codex/
 └─ agents/
     └─ security-reviewer.toml

처럼 만듭니다.

개념적으로는:

name = "security_reviewer"
description = "Reviews code changes for security risks."

developer_instructions = """
Focus only on security issues.
Do not modify source files.
Inspect authentication, authorization,
secret handling, and network code.
Return evidence with file paths.
"""

sandbox_mode = "read-only"

같이 구성할 수 있습니다.

이게 중요한 이유는 단순히 Prompt를 따로 저장할 수 있어서가 아닙니다.

Agent별로:

Model

Reasoning Effort

Sandbox

MCP Servers

Skills

Permissions

를 다르게 구성할 수 있기 때문입니다.

9. Claude Code도 Custom Subagent를 만들 수 있다

Claude Code에서도 비슷한 구조를 사용할 수 있습니다.

가장 간단한 방법은:

/agents

명령을 사용하는 것입니다.

여기서 Project-level 또는 User-level Custom Agent를 생성할 수 있습니다.

예를 들어:

security-reviewer

Agent를 만들어:

Security 관련 코드만 분석한다.

Source Code는 수정하지 않는다.

Authentication
Authorization
Secret
Network Security
Dependency 위험만 확인한다.

같은 역할을 줄 수 있습니다.

Claude의 Subagent는 Main Session과 별도의 Context Window를 사용합니다.

즉:

Main Context
        │
        ├─ 구현 내용
        ├─ Conversation
        └─ Planning

Security Agent Context
        │
        ├─ Diff
        ├─ Security Files
        └─ Security Rules

처럼 Context를 분리할 수 있습니다.

Anthropic도 Subagent가 특히 유용한 영역으로 탐색, 코드 조사, 병렬 작업, Context Isolation을 강조하고 있습니다.

10. Subagent는 읽기 작업부터 병렬화하는 것이 좋다

처음 멀티에이전트를 쓰면서 흔히 하는 실수가 있습니다.

Agent 여러 개에게 동시에 코드를 수정시키는 것입니다.

Agent A
→ UserService.swift 수정

Agent B
→ UserService.swift 수정

Agent C
→ UserServiceTests.swift와
   UserService.swift 수정

이렇게 하면:

Merge Conflict

Context Mismatch

중복 구현

서로 다른 설계

가 발생하기 쉽습니다.

Codex 공식 문서도 병렬 Subagent는 우선

Exploration

Test 분석

Triage

Summary

같은 read-heavy 작업부터 사용하는 것을 권장합니다.

좋은 첫 번째 구조는:

Main Agent
   │
   ├─ Explorer
   ├─ Test Analyzer
   └─ Dependency Analyzer

입니다.

그 결과를 Main Agent가 받은 뒤 실제 수정은 하나의 Worker가 담당합니다.

Explore in Parallel
        ↓
Main Agent Plan
        ↓
Single Writer

구조가 충돌을 줄이기 쉽습니다.

11. Claude Code에서도 같은 원칙이 적용된다

Claude Code 역시 Subagent는 독립 Context를 사용합니다.

Anthropic은 큰 작업 중 발생하는 Side Task를 Subagent에게 보내는 방식을 대표적인 사용 사례로 설명합니다.

예를 들어 Main Claude가 Feature를 구현하고 있는데:

이 프로젝트에서 기존 OAuth Token Refresh는
어디서 처리하고 있지?

라는 조사가 필요해졌다고 해보겠습니다.

Main Context에서 직접 탐색하면 수십 개 파일을 읽은 내용까지 Context에 쌓입니다.

대신 Explorer Agent에게 맡깁니다.

Main Claude
    ↓
Explore Agent

"OAuth Refresh 흐름만 조사해줘."

Explorer는 독립적으로 파일을 읽고 최종적으로:

AuthService.swift
TokenRepository.swift
SessionManager.swift

Refresh 흐름은 ...

정도만 돌려줍니다.

Main Context에는 탐색 과정 전체가 아니라 결론만 남게 됩니다.

이게 Subagent를 쓰는 가장 큰 장점 중 하나입니다.

12. Skill과 Subagent는 역할이 다르다

둘을 혼동하기 쉽습니다.

Skill은:

이 작업을 어떻게 해야 하는가

를 정의합니다.

Subagent는:

이 작업을 누가 독립적으로 처리할 것인가

를 정의합니다.

예를 들어:

Swift 6 Migration Skill

은 절차입니다.

Swift 6 Migration Reviewer

는 독립적인 Reasoning Worker입니다.

그래서:

Main Agent
    ↓
Migration Skill
    ↓
Tools

로 충분하면 Agent를 추가하지 않습니다.

반대로 대규모 Repository를 먼저 분석해야 한다면:

Main Agent
    ↓
Migration Explorer Subagent
    ↓
Migration Skill

처럼 둘을 같이 사용할 수도 있습니다.

13. Codex에서 외부 Tool은 MCP로 연결한다

Repository 밖의 시스템을 Agent가 사용하기 시작하면 MCP가 유용합니다.

예를 들어:

GitHub

Linear

Figma

사내 API

문서 검색

Database

같은 시스템입니다.

Codex는 MCP Server를 직접 연결할 수 있습니다.

CLI에서는:

codex mcp

를 이용해 관리할 수 있습니다.

개념적인 구조는:

Codex
  │
  ├─ Local Tools
  │
  ├─ Skills
  │
  └─ MCP
       │
       ├─ GitHub
       ├─ Figma
       └─ Internal Docs

입니다.

MCP Server는 Tool뿐 아니라 Resource와 Prompt도 제공할 수 있습니다.

14. Claude Code 역시 MCP를 기본 지원한다

Claude Code에서도:

claude mcp

명령을 통해 MCP Server를 구성할 수 있습니다.

구조는 동일합니다.

Claude Code
    ↓
MCP
    ↓
GitHub
Slack
Database
Browser
Internal API

중요한 점은 Agent에게 외부 시스템 접근 권한을 줄 때 권한 범위를 명확하게 나누는 것입니다.

예를 들어:

GitHub Read
→ 자동 허용

PR Comment
→ 허용

Merge
→ 승인 필요

Production Deploy
→ 승인 필요

같은 방식입니다.

Claude Code는 Tool별 Allow / Deny 규칙과 Permission Mode를 제공합니다.

Codex 역시 Sandbox와 Approval 설정을 통해 작업 범위를 제한할 수 있습니다.

멀티에이전트에서는 Agent마다 이 권한을 다르게 주는 것이 중요합니다.

15. Agent마다 같은 권한을 줄 필요는 없다

예를 들어 다음 구조가 있다고 해보겠습니다.

Main Coding Agent

Explorer Agent

Security Reviewer

Implementation Worker

권한은 이렇게 나눌 수 있습니다.

Explorer

Read ⭕
Search ⭕
Edit ❌
Shell 제한

Security Reviewer

Read ⭕
Scanner ⭕
Edit ❌

Implementation Worker

Read ⭕
Edit ⭕
Build ⭕
Test ⭕

Main Agent가 모든 권한을 가진다고 Subagent까지 전부 같은 권한을 가져야 하는 것은 아닙니다.

오히려 Agent 역할이 좁아질수록 권한도 좁히는 것이 좋습니다.

16. 실제 iOS 프로젝트라면 이런 구조부터 시작하면 된다

예를 들어 Swift 프로젝트가 있다고 해보겠습니다.

처음에는:

Codex / Claude Code
       ↓
Repository
       ↓
Build / Test / Git

만 사용합니다.

반복적인 Swift 6 Migration이 생기면:

Main Agent
    ↓
Swift 6 Migration Skill

을 추가합니다.

코드베이스 탐색이 Main Context를 너무 많이 사용하기 시작하면:

Main Agent
   │
   └─ Explorer Subagent

를 추가합니다.

보안 리뷰를 독립적으로 하고 싶다면:

Main Agent
   │
   ├─ Explorer
   └─ Security Reviewer

가 됩니다.

GitHub나 사내 CI가 필요하면:

Main Agent
   │
   ├─ Skills
   ├─ Subagents
   └─ MCP
        ├─ GitHub
        └─ CI

까지 확장합니다.

이 정도면 대부분의 개발팀에서 충분히 강력한 Multi-Agent 구조입니다.

17. Codex와 Claude Code에서 추천하는 첫 Multi-Agent 구조

처음부터 Agent를 다섯 개 만들기보다 이 정도가 좋습니다.

                Main Coding Agent
                       │
         ┌─────────────┴─────────────┐
         │                           │
     Explorer                  Security Reviewer
    Read Only                     Read Only
         │                           │
         └─────────────┬─────────────┘
                       ↓
                  Main Agent
                       ↓
                 Worker / Edit
                       ↓
                Build + Test

핵심은:

탐색
→ 병렬

판단
→ Main

수정
→ 가능한 한 한 곳

검증
→ Build / Test

입니다.

이 구조가 생각보다 중요합니다.

멀티에이전트의 목적은 동시에 많이 수정하는 것이 아니라 Main Context에서 독립적인 사고를 분리하는 것에 더 가깝기 때문입니다.

18. Agent를 더 만들기 전에 Skill인지 확인한다

다음과 같은 작업은 대부분 Agent가 필요하지 않습니다.

Release 준비

Swift 6 Migration 절차

Dependency Update

Lint Fix

Feature Module 생성

PR Checklist

반복되는 절차가 있다면:

SKILL.md

부터 만드는 것이 좋습니다.

반대로:

Repository Architecture 분석

대규모 코드 탐색

보안 위험 조사

장애 원인 탐색

기술 조사

처럼 결과에 따라 다음 행동이 달라지는 작업은 Subagent 후보입니다.

기준은 간단합니다.

Procedure
    ↓
Skill

Independent Reasoning
    ↓
Subagent

19. 같은 Runtime을 넘어서면 그때 A2A를 생각한다

Codex 내부 Subagent와 Claude Code Subagent는 기본적으로 같은 Agent 환경 안의 분업입니다.

하지만 이런 구조라면 이야기가 달라집니다.

개발팀

Codex Coding Agent
        ↓
       ???
        ↓
보안팀

Claude Security Agent

보안팀 Agent는:

별도 Server

별도 Model

별도 Context

별도 Permission

별도 Deployment

를 가지고 있을 수 있습니다.

이 경우 Main Codex의 Subagent로 볼 수 없습니다.

독립된 Agent System입니다.

여기서 A2A 같은 Agent-to-Agent Protocol이 의미를 갖습니다.

Codex Agent
      ↓
     A2A
      ↓
Claude Security Agent

처럼 서로 다른 Agent Runtime을 연결할 수 있습니다.

즉:

Codex Subagent
Claude Subagent

→ 같은 Runtime 내부의 분업

과

A2A

→ 서로 독립된 Agent System 사이의 통신

은 다른 문제입니다.

20. 처음부터 A2A까지 넣지 않는 게 좋다

처음 Agent 시스템을 만들면서:

Skills

MCP

Subagents

A2A

Workflow Engine

Vector DB

Long-term Memory

를 모두 세팅하면 Architecture 자체가 개발 대상이 됩니다.

실제 Feature보다 Agent Infrastructure를 관리하는 일이 더 커질 수 있습니다.

그래서 다음 순서가 현실적입니다.

STEP 1

Codex / Claude Code
Single Agent

↓

STEP 2

AGENTS.md / CLAUDE.md

↓

STEP 3

반복 절차
→ Skills

↓

STEP 4

Context 분리 필요
→ Subagents

↓

STEP 5

외부 시스템
→ MCP

↓

STEP 6

독립 Runtime
→ A2A

이 순서면 필요하지 않은 복잡도를 미리 만들지 않아도 됩니다.

21. Codex와 Claude Code를 같이 쓰는 팀이라면 더 재미있어진다

실제 개발팀에서는 Codex와 Claude Code를 동시에 사용하는 경우도 있습니다.

예를 들면:

Codex

구현
Build
Test

에 강하게 사용하고,

Claude Code

Repository 조사
Architecture Review
Documentation

에 사용한다고 해보겠습니다.

처음에는 서로 독립적으로 써도 됩니다.

Developer
 ├─ Codex
 └─ Claude Code

굳이 둘을 서로 연결할 필요는 없습니다.

하지만 팀 수준에서 자동화를 만들기 시작하면:

Main Coding Workflow
       │
       ├─ Codex Worker
       │
       └─ Claude Reviewer

같은 구조가 생길 수 있습니다.

이 경우 중요한 것은 어떤 모델이 더 좋은가가 아닙니다.

각 Agent에게 어떤 Context와 권한, 역할을 줄 것인가가 중요합니다.

22. 멀티에이전트에서 가장 중요한 것은 Context 관리다

Agent가 하나일 때는 Context 문제가 덜 보입니다.

하지만 Subagent가 늘어나면 설계의 중심이 달라집니다.

나쁜 구조는:

Main Context

↓

Agent A 전체 전달
Agent B 전체 전달
Agent C 전체 전달

입니다.

좋은 구조는:

Main Context
    │
    ├─ Explorer
    │     → 탐색에 필요한 정보만
    │
    ├─ Reviewer
    │     → Diff + 관련 코드만
    │
    └─ Worker
          → 수정 대상 + 계획만

입니다.

그리고 Subagent가 돌아올 때도 전체 작업 로그를 반환하기보다:

결론

근거

파일 위치

추천 Action

정도만 Main Agent에 전달하는 편이 좋습니다.

Codex 공식 문서에서도 Subagent가 중간 출력 전체보다 요약 결과를 Parent에 반환하도록 하는 방식을 권장합니다.

23. 멀티에이전트를 쓰면 Observability도 필요해진다

Agent가 하나일 때는 실패 원인을 찾기 쉽습니다.

Agent가 여러 개가 되면:

Main
 ↓
Explorer
 ↓
Main
 ↓
Reviewer
 ↓
Main
 ↓
Worker

중 어디에서 문제가 생겼는지 확인해야 합니다.

최소한 다음 정보는 남기는 것이 좋습니다.

Agent

Task

Model

Duration

Tool Calls

Token

Result

Failure

그리고 가능하면 전체 작업을 하나의 Trace로 봅니다.

Task #123

├─ Main
├─ Explorer
├─ Docs Research
├─ Worker
└─ Test

Agent 수가 늘어날수록 Model 성능보다 운영 가능성이 중요해집니다.

24. 결국 설치보다 중요한 것은 어디서 나누느냐이다

Codex에서 Custom Agent를 만드는 것도 어렵지 않고,

Claude Code에서 /agents로 Subagent를 만드는 것도 어렵지 않습니다.

Skill 역시 SKILL.md 파일 하나로 시작할 수 있습니다.

MCP도 CLI에서 연결할 수 있습니다.

기술적인 설치 자체는 점점 쉬워지고 있습니다.

문제는 Architecture입니다.

왜 이 Agent가 따로 있어야 하는가?

왜 이 Context를 분리해야 하는가?

왜 이 Tool을 이 Agent만 사용해야 하는가?

왜 이 작업을 병렬로 실행해야 하는가?

에 답할 수 있어야 합니다.

답이 없다면 Agent를 분리하지 않는 편이 나을 가능성이 높습니다.

25. 처음 구성한다면 이 정도면 충분하다

Codex든 Claude Code든 처음에는 이 구조 정도면 충분합니다.

                 Main Coding Agent
                        │
          ┌─────────────┴─────────────┐
          │                           │
      Explorer                    Reviewer
      Read Only                  Read Only
          │                           │
          └─────────────┬─────────────┘
                        ↓
                      Main
                        ↓
                      Edit
                        ↓
                  Build + Test

여기에 프로젝트 규칙:

AGENTS.md

or

CLAUDE.md

를 둡니다.

반복 절차는:

SKILL.md

로 만듭니다.

외부 시스템이 필요해지면:

MCP

를 추가합니다.

Agent 자체가 독립 서비스가 될 때만:

A2A

를 고민합니다.

이 정도만 해도 상당히 탄탄한 멀티에이전트 환경을 만들 수 있습니다.

마치며

멀티에이전트를 시작한다고 해서 새로운 Agent Framework부터 설치할 필요는 없습니다.

이미 Codex나 Claude Code를 사용하고 있다면 그 환경에서 바로 시작할 수 있습니다.

처음에는:

1 Agent
+
Project Rules
+
Build / Test

면 충분합니다.

반복되는 작업이 생기면 Skill을 추가합니다.

1 Agent
+
Skills

Main Context가 커지기 시작하면 Subagent를 추가합니다.

Main
+
Explorer
+
Reviewer

외부 시스템이 필요하면 MCP를 연결합니다.

Agent
+
MCP

그리고 서로 다른 팀이나 Runtime의 Agent가 실제로 독립된 서비스가 됐을 때 A2A를 고려합니다.

Agent
 ↓
A2A
 ↓
Independent Agent

그래서 멀티에이전트 Architecture를 가장 단순하게 정리하면 다음과 같습니다.

Project Rules
      ↓
Single Agent
      ↓
Skills
      ↓
Subagents
      ↓
MCP
      ↓
A2A

복잡도를 한꺼번에 넣는 것이 아니라 문제가 생기는 순서대로 하나씩 추가하는 것입니다.

Codex와 Claude Code 모두 이미 이 흐름을 상당 부분 지원하고 있습니다.

결국 좋은 멀티에이전트 환경은 Agent가 많은 환경이 아닙니다.

Main Context에는 중요한 판단만 남기고, 반복 절차는 Skill로, 독립적인 탐색은 Subagent로, 외부 기능은 MCP로 분리한 환경에 가깝습니다.

그리고 마지막 경계가 생겼을 때 A2A가 들어옵니다.

앞선 두 글까지 연결하면 구조도 깔끔하게 정리됩니다.

1편

Agent를 꼭 만들어야 하나?
→ Skill + MCP

2편

Agent를 정말 분리해야 할 때는?
→ A2A

3편

실제로 어떻게 시작할까?
→ Codex / Claude Code
→ Skill + Subagent + MCP

이 세 편 정도면 멀티에이전트를 처음 구성할 때 필요한 개념부터 실제 운영 방향까지 한 번에 연결할 수 있습니다.

참고자료

OpenAI — Codex Subagents
Codex의 기본 worker, explorer Agent, Custom Agent 설정, 병렬 Subagent Workflow, Agent별 Model·Sandbox·MCP·Skill 설정 방법을 확인할 수 있습니다.
Codex Subagents 공식 문서
OpenAI — Agent Skills
Codex의 SKILL.md, Progressive Disclosure, 프로젝트 및 사용자 범위 Skill 설정 구조를 확인할 수 있습니다.
Codex Agent Skills 공식 문서
OpenAI — AGENTS.md
Repository와 사용자 범위에서 Codex에 지속적인 개발 규칙을 전달하는 방법을 확인할 수 있습니다.
Codex AGENTS.md 공식 문서
OpenAI — Codex MCP
Codex CLI·IDE·데스크톱에서 STDIO 및 Remote MCP Server를 연결하고 외부 Tool과 Context를 사용하는 방법을 확인할 수 있습니다.
Codex MCP 공식 문서
Anthropic — Claude Code Subagents
독립 Context를 사용하는 Claude Code Subagent의 사용 기준과 병렬 탐색, Context Isolation 전략을 확인할 수 있습니다.
Claude Code Subagent 공식 가이드
Anthropic — Claude Code Skills
.claude/skills/와 ~/.claude/skills/에 Custom Skill을 구성하는 방법을 확인할 수 있습니다.
Claude Agent Skills 공식 문서
Anthropic — Claude Code MCP
Claude Code와 외부 Tool 및 Data Source를 MCP로 연결하는 공식 구조를 확인할 수 있습니다.
Claude MCP 공식 문서

OpenAI 공식 문서 기준으로 보면, 현재 Codex는 Subagent Workflow가 기본 활성화되어 있으며 default, worker, explorer 같은 기본 Agent와 .codex/agents/ 기반 Custom Agent를 지원합니다. OpenAI는 특히 코드베이스 탐색, 테스트 분석, triage, summary처럼 읽기 비중이 높은 작업을 병렬 Subagent로 먼저 분리하고, 여러 Agent가 같은 코드를 동시에 수정하는 write-heavy 병렬 작업은 신중하게 사용할 것을 권장하고 있습니다.

Anthropic 역시 비슷한 기준을 제시합니다. Claude Code의 Subagent는 별도의 Context Window에서 작업하고 결과만 Main Conversation에 반환하기 때문에 코드 탐색이나 독립적인 조사 작업에서 특히 유용합니다. 반대로 단순하거나 Context 공유가 중요한 작업에서는 Subagent 생성 비용이 더 클 수 있습니다.

두 환경 모두 결국 같은 방향을 보여줍니다. 반복 절차는 Skill, 외부 기능은 MCP, 독립적인 Context가 필요한 작업은 Subagent로 분리하고, 서로 다른 Runtime과 조직 경계까지 넘어가는 순간에만 A2A 같은 분산 Agent Protocol을 고려하는 구조가 현재 가장 현실적인 멀티에이전트 시작점입니다.

MCP 다음은 A2A다 《2》

Fri, 18 Sep 2026 05:36:40 GMT

MCP 다음은 A2A다

Agent끼리 통신하는 아키텍처는 언제 필요한가

앞선 글에서는 Multi-Agent 구조를 만들 때 모든 전문 기능을 Agent로 분리할 필요는 없다는 이야기를 했습니다.

정해진 절차
+
명확한 Tool
        ↓
Skill + MCP

반대로 이런 작업은 조금 다릅니다.

탐색
+
가설
+
반복 판단
+
독립적인 Context
        ↓
Agent

그렇다면 실제로 Agent를 분리해야 할 때는 어떻게 연결해야 할까요?

같은 애플리케이션 안의 객체라면 직접 호출하면 됩니다.

하지만 Agent가

다른 서버에서 실행되고
다른 팀이 관리하고
다른 언어와 Framework로 만들어졌으며
서로 다른 모델과 Context를 사용하고
몇 분 또는 몇 시간 동안 독립적으로 작업한다면

단순한 Function Call로 보기 어려워집니다.

이때 등장하는 것이 A2A, Agent2Agent Protocol입니다.

현재 A2A 공식 사양은 0.3.0까지 발전했고, JSON-RPC뿐 아니라 HTTP+JSON, gRPC까지 Transport 범위가 확장됐습니다.

그리고 2026년 9월에는 Linux Foundation 산하 Agentic AI Foundation(AAIF)의 Hosted Project로 들어가면서 특정 Vendor의 Agent Protocol보다 산업 표준에 가까운 방향으로 움직이고 있습니다.

A2A를 한 문장으로 정리하면 이렇습니다.

MCP가 Agent에게 Tool을 연결하는 표준이라면, A2A는 독립된 Agent에게 일을 맡기는 표준에 가깝습니다.

1. MCP와 A2A는 경쟁 관계가 아니다

A2A 이야기가 나오면 가장 먼저 생기는 오해가 있습니다.

MCP
vs
A2A

둘 중 하나를 선택해야 한다는 생각입니다.

하지만 역할이 다릅니다.

MCP는 Agent가 사용할 Capability를 제공합니다.

Agent
   ↓
MCP
   ↓
GitHub
Database
Browser
CI

Agent가 직접 판단하고 Tool을 호출합니다.

반면 A2A는 다른 Agent에게 Task 자체를 위임합니다.

Main Agent
     ↓
    A2A
     ↓
Security Agent
     ↓
Security Tools

Main Agent는 Security Agent 내부 Tool을 직접 제어할 필요가 없습니다.

Security Agent가 자신의 Context와 Tool을 이용해 스스로 판단합니다.

정리하면:

MCP

"이 기능을 실행해줘."

에 가깝고,

A2A

"이 일을 맡아줘."

에 가깝습니다.

2. Tool과 Agent의 가장 큰 차이는 독립적인 판단이다

예를 들어 다음 Function이 있다고 해보겠습니다.

run_swiftlint()

Input과 Output이 명확합니다.

Input
→ Project

Output
→ Findings

이건 Tool입니다.

반면 이런 요청은 다릅니다.

이번 배포 이후 Crash가 늘어난 원인을 찾아줘.

이 작업에는 정해진 호출 순서가 없습니다.

Agent는 먼저 Crash 데이터를 확인할 수 있습니다.

Crash Rate
 ↓
특정 iOS Version인가?

그다음:

최근 Release 확인
 ↓
관련 Commit 검색

또는:

API Error 확인
 ↓
Backend 변경 확인

으로 갈 수도 있습니다.

중간 결과를 보고 새로운 가설을 세웁니다.

Observe
 ↓
Hypothesis
 ↓
Tool Call
 ↓
Verify
 ↓
Re-plan

이 정도가 되면 Function Call보다는 독립적인 Agent Task에 가깝습니다.

A2A는 바로 이런 Agent 사이의 경계를 표준화합니다.

3. 가장 현실적인 예 — Coding Agent와 Security Agent

개발팀에 Coding Agent가 있다고 해보겠습니다.

Coding Agent

Repository 분석
코드 생성
Refactoring
Test

보안팀에는 별도의 Security Agent가 있습니다.

Security Agent

SAST
Dependency Scan
Secret Scan
Threat Model
Security Policy

Coding Agent가 PR을 만든 뒤 보안 검토가 필요합니다.

여기서 Security Tool을 Coding Agent에게 전부 제공할 수도 있습니다.

Coding Agent

+
Security Tools
+
Security Prompt
+
Security Policy

하지만 시스템이 커질수록 문제가 생깁니다.

Coding Agent가 보안팀의 내부 규칙과 Tool까지 알아야 합니다.

Security Tool이 바뀌면 Coding Agent도 영향을 받습니다.

Security Context 역시 Main Agent Context에 들어옵니다.

대신 Security Agent를 독립적으로 두면:

Coding Agent
     ↓
    A2A
     ↓
Security Agent
     ↓
Security Tools

구조가 됩니다.

Coding Agent가 해야 할 일은 단순합니다.

"이 PR의 보안 위험을 검토해줘."

입니다.

Security Agent가 내부적으로 어떤 Scanner를 사용하는지는 Coding Agent가 몰라도 됩니다.

4. 다른 팀이 소유한 Agent라면 A2A가 더 자연스럽다

A2A가 특히 의미 있는 지점이 팀 경계입니다.

예를 들어 회사에 다음 Agent들이 있다고 해보겠습니다.

개발팀
Coding Agent

SRE팀
Incident Agent

보안팀
Security Agent

법무팀
Compliance Agent

각 Agent는 서로 다른 팀에서 운영합니다.

각 팀은 자신들의 Agent에 대해

Model
Prompt
Knowledge
Tools
Permission
Deploy Cycle

을 독립적으로 관리합니다.

Main Agent가 이 내부 구현까지 알 필요는 없습니다.

Coding Agent
     ↓
     A2A
     ↓
Compliance Agent

형태로 Task만 전달합니다.

이 경우 A2A는 단순 Agent 연결 기술이 아니라 조직의 Ownership Boundary를 유지하는 방법이 됩니다.

5. Agent Card는 Agent용 API 문서에 가깝다

독립적인 Agent끼리 연결하려면 먼저 알아야 할 것이 있습니다.

저 Agent가 뭘 할 수 있지?

A2A에서는 이를 Agent Card로 표현합니다.

Agent Card는 JSON 형태의 Metadata Document입니다.

대략 이런 정보를 갖습니다.

Agent Card

├─ name
├─ description
├─ version
├─ capabilities
├─ skills
├─ endpoint
├─ supported transports
└─ authentication requirements

예를 들어 Security Agent가 다음 Capability를 공개할 수 있습니다.

Security Review Agent

Skills

- dependency-security-review
- code-security-review
- secret-detection

Client Agent는 Agent Card를 보고 이 Agent가 자신의 Task를 처리할 수 있는지 판단합니다.

기본적인 Discovery 방식 중 하나는:

/.well-known/agent-card.json

입니다.

Enterprise 환경에서는 Agent Registry나 Catalog를 사용할 수도 있습니다.

개념적으로 보면 Agent Card는 Agent 세계의 OpenAPI Document와 비슷한 역할을 합니다.

6. 최신 A2A에서는 Transport도 하나로 고정되지 않는다

A2A 초기 버전은 JSON-RPC 중심이었습니다.

현재 0.3.0에서는 Core Transport로 다음 방식을 정의합니다.

JSON-RPC

gRPC

HTTP+JSON

Agent는 자신이 지원하는 Interface를 Agent Card에 공개할 수 있습니다.

예를 들어:

Security Agent

JSON-RPC
→ https://security.example.com/a2a

gRPC
→ grpc.security.example.com

HTTP+JSON
→ https://security.example.com/v1

같은 식입니다.

Client는 지원되는 Transport 중 적절한 것을 선택합니다.

이 변화는 A2A가 단순한 Agent SDK 기능에서 분산 시스템 Protocol로 발전하고 있다는 신호이기도 합니다.

7. A2A의 중심은 Message보다 Task다

일반적인 Chat 시스템에서는 Message가 중심입니다.

User Message
 ↓
Assistant Message

A2A에서는 Agent에게 긴 작업을 맡길 수 있기 때문에 Task라는 개념이 중요합니다.

예를 들어 Architecture Review Agent에게:

이 Repository 전체의
Architecture 문제를 분석해줘.

라고 요청했다고 해보겠습니다.

몇 초 안에 끝나지 않을 수 있습니다.

Task는 상태를 가집니다.

Submitted
   ↓
Working
   ↓
Input Required
   ↓
Working
   ↓
Completed

또는

Failed
Canceled
Rejected

로 종료될 수도 있습니다.

즉 A2A는 단순 RPC보다 비동기 Job Protocol에 더 가까운 부분이 있습니다.

8. 결과는 Message가 아니라 Artifact가 될 수 있다

Agent가 만드는 결과도 단순 Text Response만 있는 것이 아닙니다.

A2A에는 Artifact라는 개념이 있습니다.

예를 들어 Security Agent가 작업 결과로:

security-report.json

security-review.md

dependency-risk.csv

를 만들 수 있습니다.

Architecture Agent라면:

architecture-review.md

dependency-graph.json

을 반환할 수 있습니다.

구조는:

Task
 │
 ├─ Messages
 │
 └─ Artifacts

입니다.

Message는 Agent끼리 통신하는 내용이고,

Artifact는 실제 작업 결과물입니다.

이 구분은 Long-running Agent를 설계할 때 꽤 중요합니다.

9. Streaming도 Agent 협업에서는 중요하다

Agent 작업이 10분 걸린다고 생각해보겠습니다.

완료될 때까지 아무 응답이 없다면 Client에서는 장애인지 작업 중인지 알기 어렵습니다.

A2A는 Streaming을 지원합니다.

Main Agent
    ↓
Architecture Agent

"Repository 분석 시작"
        ↓
"Dependency 분석 완료"
        ↓
"순환 의존성 발견"
        ↓
"Report 생성 중"
        ↓
Artifact

현재 Protocol에서는 SSE를 이용한 Streaming뿐 아니라 Transport에 따라 Streaming 방식을 지원할 수 있습니다.

즉 Client Agent가 Remote Agent의 진행 상태를 실시간으로 받을 수 있습니다.

10. 몇 시간짜리 작업이라면 Push가 더 자연스럽다

모든 Agent가 Streaming Connection을 계속 유지할 필요는 없습니다.

예를 들어 Research Agent에게:

지난 6개월 경쟁사 기술 변화와
GitHub Release를 조사해서
보고서 만들어줘.

라고 요청했다고 해보겠습니다.

30분이 걸릴 수도 있습니다.

이 경우:

Request

↓

Connection 30분 유지

보다:

Task 생성
 ↓
Connection 종료
 ↓
Agent Background Processing
 ↓
완료
 ↓
Webhook

이 더 자연스럽습니다.

A2A는 Push Notification 방식도 정의합니다.

Long-running Task와 잘 맞는 이유입니다.

11. 다른 언어와 Framework를 연결할 때 A2A가 빛난다

Production 환경에서는 모든 Agent가 같은 Framework로 만들어지지 않습니다.

예를 들어:

Coding Agent

Python
LangGraph

보안팀은:

Security Agent

Go
Custom Runtime

법무팀은:

Compliance Agent

.NET
Microsoft Agent Framework

일 수 있습니다.

이 Agent들을 모두 하나의 Framework로 다시 만드는 것은 현실적이지 않습니다.

A2A에서는 Protocol만 맞으면 됩니다.

Python Agent
     ↓
    A2A
     ↓
Go Agent

Google도 2026년 실제 개발 예제로 Python 기반 Contract Extraction Agent와 Go 기반 Compliance Agent를 A2A로 연결하는 구조를 공개했습니다.

이게 A2A의 대표적인 장점입니다.

Agent Framework보다 Protocol Boundary를 기준으로 시스템을 연결할 수 있습니다.

12. 같은 애플리케이션 안의 Subagent라면 A2A는 과할 수 있다

여기서 중요한 점이 있습니다.

Agent가 두 개라고 무조건 A2A를 쓸 필요는 없습니다.

예를 들어 같은 Process 안에서:

Main Agent

├─ Planning Agent
├─ Coding Agent
└─ Test Agent

를 단순히 역할 분리용으로 사용하고 있다고 해보겠습니다.

모든 Agent가

같은 Runtime

같은 Deployment

같은 Team

같은 Model Provider

에 있다면 A2A는 오히려 복잡도를 늘릴 수 있습니다.

Network
Serialization
Timeout
Retry
Authentication
Versioning
Tracing

문제가 추가됩니다.

이런 경우에는 Framework 내부의

Subagent

Agent as Tool

Handoff

정도로 충분할 수 있습니다.

A2A는 Agent가 있다는 이유로 쓰는 것이 아니라 실제 시스템 경계가 있을 때 쓰는 것이 자연스럽습니다.

13. A2A를 쓰는 순간 분산 시스템 문제가 생긴다

A2A는 Agent Architecture 문제만이 아닙니다.

Network Boundary가 생깁니다.

그래서 기존 Backend와 비슷한 문제가 다시 나타납니다.

Timeout

Retry

Partial Failure

Authentication

Authorization

Version Compatibility

Observability

예를 들어 Main Agent가 Security Agent에게 Task를 보냈는데 응답이 없습니다.

요청 실패인가?

아직 작업 중인가?

Agent Process가 죽었나?

Network가 끊겼나?

를 구분해야 합니다.

Task ID와 상태가 중요한 이유입니다.

Agent 시스템도 결국 Production에 들어가면 분산 시스템 Engineering이 됩니다.

14. Retry도 단순히 다시 보내면 안 된다

이 부분은 실무에서 특히 중요합니다.

예를 들어:

"Production Deploy 실행해줘."

라는 Task를 Remote Agent에게 보냈습니다.

응답이 Timeout됐습니다.

Client가 그냥 다시 보내면:

Deploy #1

Deploy #2

가 실행될 수도 있습니다.

따라서 실제 Production A2A에서는:

Task ID

Operation ID

Idempotency

State Persistence

같은 설계가 필요합니다.

Protocol이 있다고 Distributed System Design이 사라지는 것은 아닙니다.

오히려 Agent가 실제 Action을 수행하기 시작하면 더 중요해집니다.

15. Authentication과 Authorization도 Agent Card와 연결된다

A2A Agent Card에는 해당 Agent가 어떤 인증 방식을 요구하는지 선언할 수 있습니다.

하지만:

Agent Card에
"OAuth 사용"

이라고 적는 것만으로 보안이 끝나는 것은 아닙니다.

실제 Agent Server에서는 매 요청마다 Authentication과 Authorization을 적용해야 합니다.

예를 들어 Security Agent가:

scan_repository

read_security_report

change_security_policy

Skill을 제공한다고 해도 사용자마다 권한은 다를 수 있습니다.

Developer

scan_repository ⭕

change_security_policy ❌

처럼 Service Layer에서 검증해야 합니다.

A2A 공식 사양 역시 서버가 각 요청을 인증하고 최소 권한 원칙을 적용하도록 요구합니다.

16. Agent Card도 공개 정보와 내부 정보를 나눌 수 있다

Agent Card에는 Capability 정보가 들어갑니다.

하지만 Enterprise Agent라면 모든 Capability를 외부에 공개하고 싶지 않을 수 있습니다.

현재 A2A 사양에는 Authenticated Extended Agent Card 개념도 있습니다.

처음에는 Public Agent Card만 제공합니다.

Public Agent Card

Security Review 가능

인증 이후에는:

Extended Agent Card

Dependency Scan
Source Scan
Internal Policy Review
Production Audit

처럼 더 상세한 Capability를 제공할 수 있습니다.

Agent Discovery 자체에도 Security Boundary가 생기는 것입니다.

17. MCP + Skill + A2A를 같이 쓰면 구조가 이렇게 된다

앞선 글과 연결하면 가장 현실적인 Agent Architecture는 이런 형태입니다.

                     Main Coding Agent
                            │
         ┌──────────────────┼──────────────────┐
         │                  │                  │
 Swift Migration       Release Skill      Security Agent
      Skill                 │                  │
         │                  │                 A2A
        MCP                MCP                 │
         │                  │           Security Runtime
   Compiler/Test            CI                  │
                                             MCP
                                              │
                                      Security Tools

여기서:

Skill
→ 작업 절차

MCP
→ Tool / Capability

A2A
→ 독립 Agent에게 Task 위임

을 담당합니다.

셋은 대체 관계가 아닙니다.

각자 다른 Layer입니다.

18. 실제 개발팀에서는 이런 구조가 가능하다

조금 더 현실적인 예를 만들어보겠습니다.

Developer
    ↓
Coding Agent

Coding Agent는 Swift 6 Migration을 수행합니다.

Coding Agent
    ↓
Swift 6 Migration Skill
    ↓
Compiler MCP

코드를 수정한 뒤 Security Review가 필요합니다.

Coding Agent
    ↓ A2A
Security Agent

Security Agent는 자기 Tool을 사용합니다.

Security Agent
    ↓
Security Skill
    ↓
MCP
    ↓
CodeQL
Dependency Scanner
Secret Scanner

그리고 Production에서 장애가 발생하면:

Main Agent
    ↓ A2A
Incident Agent

Incident Agent가 독립적으로:

Logs
Metrics
Tracing
Deploy History

를 분석합니다.

이 구조에서 Main Agent가 모든 Tool Schema와 Domain Prompt를 가질 필요가 없습니다.

19. A2A가 필요한지 판단하는 기준

Agent를 Remote Service로 분리하기 전에 다음 질문을 해보면 됩니다.

다른 팀이 소유하는가?

YES
→ A2A 후보

별도 Deployment Cycle이 필요한가?

YES
→ A2A 후보

다른 언어나 Framework로 구현됐는가?

YES
→ A2A 후보

독립적인 Context와 Memory가 필요한가?

YES
→ A2A 후보

몇 분 이상 장시간 작업하는가?

YES
→ A2A 후보

자체적으로 탐색하고 재계획하는가?

YES
→ A2A 후보

반대로:

같은 Process

같은 Team

정해진 Procedure

명확한 Tool

정도라면 A2A까지 갈 필요가 없을 가능성이 높습니다.

20. A2A의 최근 흐름도 달라지고 있다

A2A는 2025년 Google이 공개한 Protocol에서 시작했습니다.

하지만 지금은 Google 전용 Protocol로 보는 것도 조금 맞지 않습니다.

현재 A2A는 Linux Foundation의 Agentic AI Foundation에서 운영되는 Open Standard로 이동했고, 150개가 넘는 조직이 참여하는 생태계로 확대되고 있습니다.

공식 A2A 사양도 현재 0.3.0까지 발전했습니다.

특히 최근에는:

Agent Discovery

Multi Transport

Authentication

Streaming

Push Notification

Long-running Task

Artifact Exchange

처럼 실제 Production Agent를 운영하는 데 필요한 영역들이 구체화되고 있습니다.

즉 A2A가 단순한

Agent끼리 Chat한다.

수준에서

Distributed Agent Runtime을
어떻게 연결할 것인가.

라는 문제로 이동하고 있습니다.

21. 결국 A2A는 Agent용 HTTP에 가까워질 수 있다

HTTP가 등장했다고 모든 Function Call을 HTTP로 바꾸지는 않습니다.

같은 Process 안에서는 그냥 Function을 호출합니다.

function()

서비스 경계가 생겼을 때 HTTP가 의미를 갖습니다.

Service A
   ↓ HTTP
Service B

A2A도 비슷하게 볼 수 있습니다.

같은 Runtime

→ Subagent / Agent as Tool

Capability 호출

→ MCP

독립 Agent Runtime

→ A2A

입니다.

그래서 A2A를 Agent끼리 대화하는 새로운 기능 정도로 보기보다 Agent 시스템 사이의 Network Contract로 보는 편이 더 정확합니다.

마치며

앞선 글에서는 모든 전문 기능을 Agent로 만들 필요가 없다는 이야기를 했습니다.

정해진 절차
+
명확한 Tool
        ↓
Skill + MCP

가 더 단순한 경우가 많습니다.

하지만 Agent를 정말 분리해야 하는 순간도 있습니다.

독립적인 판단

별도 Context

별도 Runtime

별도 Team

장시간 Workflow

다른 언어 / Framework

가 필요하다면 Agent 자체가 하나의 독립 서비스가 됩니다.

그리고 그때 필요한 것이 A2A입니다.

정리하면 세 가지의 역할은 꽤 명확합니다.

Skill

"어떻게 일할 것인가"

MCP

"무엇을 실행할 수 있는가"

A2A

"어떤 Agent에게 일을 맡길 것인가"

이 세 가지를 같이 보면 최근 Agent Architecture의 방향도 조금 더 명확해집니다.

모든 기능을 하나의 거대한 Agent에 넣을 필요도 없고,

모든 기능을 Specialist Agent로 만들 필요도 없습니다.

Main Agent
    │
    ├─ Skill
    │    └─ MCP Tool
    │
    ├─ Skill
    │    └─ MCP Tool
    │
    └─ A2A
         ↓
    Independent Agent
         ↓
        MCP

형태의 Hybrid Architecture가 오히려 더 현실적입니다.

결국 Agent Architecture를 설계할 때 중요한 질문은 Agent가 몇 개인지가 아닙니다.

이 기능이 단순 Capability인가, 아니면 독립적으로 일을 맡길 수 있는 시스템인가.

A2A는 후자가 필요해지는 순간부터 의미가 생깁니다.

참고자료

A2A Protocol — Official Specification 0.3.0
Agent Card, Task, Message, Artifact, Streaming, Push Notification과 JSON-RPC·gRPC·HTTP+JSON Transport를 포함한 현재 공식 A2A 사양입니다.
A2A 0.3.0 공식 Specification 보기
A2A Protocol — Core Concepts
Agent Card, Task, Message, Part, Artifact 등 A2A의 핵심 Domain Model을 정리한 공식 문서입니다.
A2A Core Concepts 보기
Google Developers — Build Cross-Language Multi-Agent Team with ADK and A2A
Python으로 만든 Contract Extraction Agent와 Go 기반 Compliance Agent를 A2A로 연결하는 실무 예제를 확인할 수 있습니다.
Google A2A Cross-Language 사례 보기
Microsoft Agent Framework — A2A Agent Service
Agent Card Discovery, Remote Agent 연결, Streaming, Background Response와 Long-running Task를 Microsoft Agent Framework에서 사용하는 방법을 확인할 수 있습니다.
Microsoft A2A 공식 문서 보기
Linux Foundation — A2A / Agentic AI Foundation
A2A가 Linux Foundation 산하 Agentic AI Foundation의 Hosted Project로 운영되는 현재 생태계와 표준화 흐름을 확인할 수 있습니다.
Linux Foundation 공식 자료 보기

현재 공식 A2A 사양은 0.3.0이며, Agent Card를 통한 Discovery, 상태를 가지는 Task, 결과물인 Artifact, Streaming과 Push Notification을 중심으로 독립 Agent 간 장기 작업을 다룰 수 있도록 설계되어 있습니다. 0.3.0에서는 JSON-RPC, gRPC, HTTP+JSON을 핵심 Transport로 정의하고 있습니다.

또한 A2A는 현재 Linux Foundation 산하 AAIF의 Hosted Project로 운영되고 있으며, Linux Foundation은 2026년 9월 기준 150개가 넘는 조직이 A2A 생태계에 참여하고 있다고 설명하고 있습니다. 따라서 현재 흐름은 특정 Agent Framework의 내부 기능보다 서로 다른 Vendor·Language·Runtime의 Agent를 연결하기 위한 독립적인 Protocol Layer에 더 가깝습니다. :::

멀티에이전트가 항상 답은 아니다 《1》

Fri, 18 Sep 2026 05:31:59 GMT

멀티에이전트가 항상 답은 아니다

Agent를 Skill로 바꾸는 아키텍처

AI Agent 시스템을 만들기 시작하면 구조가 빠르게 커집니다.

처음에는 하나의 Agent가 여러 Tool을 사용합니다.

User
 ↓
Main Agent
 ↓
Tools

기능이 늘어나면 역할을 분리하기 시작합니다.

Main Agent
   │
   ├─ Release Agent
   ├─ Refactoring Agent
   ├─ Migration Agent
   └─ Research Agent

겉으로 보면 깔끔합니다.

각 Agent가 자기 역할만 담당하니 Microservice처럼 책임도 명확해 보입니다.

그런데 여기서 한 번 생각해볼 필요가 있습니다.

저 기능마다 정말 별도의 LLM Agent가 필요한가?

Microsoft가 9월 16일 공개한 Agent Framework 사례에서도 같은 질문을 던졌습니다.

기존에는 상위 Advisor가 여러 Specialist Agent를 A2A로 호출했지만, 일부 Specialist를 SKILL.md + MCP Tool 구조로 바꿨습니다.

서비스 자체를 합친 것은 아닙니다.

없어진 것은 Specialist마다 존재하던 별도의 Model Loop였습니다.

이 차이는 실제 개발 시스템에서 더 중요합니다.

1. Multi-Agent를 만들면 Agent 하나만 추가되는 것이 아니다

예를 들어 Release Agent를 하나 만든다고 생각해보겠습니다.

구조는 단순해 보입니다.

Main Agent
   ↓
Release Agent
   ↓
CI / Git / App Store

하지만 실제 Release Agent 안에는 이런 것들이 들어갑니다.

Release Agent

├─ System Prompt
├─ Model
├─ Context
├─ Tools
├─ Agent Loop
└─ Result Generation

Main Agent가 Release Agent에게 일을 넘기면 Release Agent는 다시 모델을 호출합니다.

Main Agent
   ↓
Model 판단
   ↓
Release Agent 호출
   ↓
Release Agent Model 판단
   ↓
Tool 호출
   ↓
Release Agent Model 정리
   ↓
Main Agent
   ↓
최종 응답

단순히 기능 하나가 추가된 것 같지만 실제로는 Reasoning Layer 하나가 더 생긴 것입니다.

Agent가 늘어날수록 함께 늘어나는 것도 있습니다.

Model Call
Context
Token
Latency
Failure Point
Observability
Permission

그래서 Multi-Agent는 역할을 나누는 좋은 방법이지만, 무조건 가벼운 구조는 아닙니다.

2. Microsoft는 Specialist Agent 일부를 Skill로 바꿨다

Microsoft 사례에서는 Weather, Safety, Lift Traffic 같은 Specialist가 각각 독립적인 Agent였습니다.

구조는 이런 형태였습니다.

Advisor
   ↓
Specialist Agent
   ↓
Domain Tool
   ↓
Domain Service

이 구조를 다음처럼 바꿨습니다.

Advisor
   ↓
Skill
   ↓
MCP Tool
   ↓
Domain Service

여기서 중요한 것은 Domain Service가 그대로 남아 있다는 점입니다.

Weather Service
Safety Service
Lift Service

는 계속 독립적으로 배포되고 관리됩니다.

달라진 것은 어디에서 판단하느냐입니다.

기존에는:

Advisor Reasoning
+
Specialist Reasoning

이었다면,

변경 후에는:

Advisor Reasoning

하나가 Domain Operation까지 선택합니다.

Specialist가 가지고 있던 절차와 지식은 SKILL.md로 이동합니다.

3. Agent를 없앤다고 Domain을 없애는 것은 아니다

이 구분이 중요합니다.

Microservice가 네 개 있다고 Agent도 네 개일 필요는 없습니다.

예를 들어 Backend가 이렇게 구성돼 있다고 해보겠습니다.

Release Service

Quality Service

Artifact Service

Notification Service

이걸 그대로

Release Agent

Quality Agent

Artifact Agent

Notification Agent

로 옮길 이유는 없습니다.

Service Boundary는 주로 이런 것을 위한 것입니다.

Business Logic
Data Ownership
Deployment
Scaling
Security
Team Ownership

Agent Boundary는 다릅니다.

Independent Reasoning
Private Context
Autonomy
Long-running Workflow
Specialized Model

즉

서비스가 분리돼 있다는 것과 Reasoning을 분리해야 한다는 것은 다른 문제입니다.

4. 가장 현실적인 예 — Release Agent가 정말 필요한가

iOS 앱 배포를 자동화한다고 해보겠습니다.

Release Agent를 따로 만들 수도 있습니다.

Main Agent
   ↓
Release Agent
   ↓
Git
CI
TestFlight
App Store

하지만 실제 업무를 보면 꽤 정형화돼 있습니다.

현재 Branch 확인

↓

변경사항 확인

↓

Version / Build Number 확인

↓

Test 실행

↓

Archive

↓

Upload

↓

Release Note 생성

이 정도라면 별도의 LLM Agent보다 Release Skill이 더 자연스러울 수 있습니다.

Release Skill

1. release branch를 확인한다.
2. working tree가 clean인지 확인한다.
3. test를 실행한다.
4. build number를 증가시킨다.
5. archive를 생성한다.
6. TestFlight에 업로드한다.

실행 기능은 MCP Tool이나 다른 Tool Interface로 제공합니다.

git_status

run_tests

increment_build_number

archive_app

upload_testflight

구조는 단순해집니다.

Main Agent
    ↓
Release Skill
    ↓
필요한 Tool 선택
    ↓
CI / App Store

Release를 수행하는 방법은 Skill이 알려주고,

실제 실행은 Tool이 담당합니다.

5. 그런데 “지금 배포해도 되는가?”라면 이야기가 달라진다

같은 Release 영역이라도 질문이 달라질 수 있습니다.

예를 들어:

지금 이 버전을 배포해도 괜찮을까?

라면 단순 절차가 아닙니다.

다음 정보를 확인해야 할 수도 있습니다.

QA 결과

Crash 증가 여부

최근 Production 장애

Backend 호환성

Feature Flag

Rollout 상태

최근 Commit 위험도

그리고 상황에 따라 추가 정보를 다시 조회할 수도 있습니다.

Crash 증가
 ↓
특정 OS인가?
 ↓
해당 Feature 변경 확인
 ↓
최근 Commit 확인
 ↓
Rollout 범위 판단

이 정도가 되면 별도의 Release/Deployment Agent가 의미를 가질 수 있습니다.

즉 같은 Domain이라도 기준은 기능 이름이 아닙니다.

독립적인 Reasoning이 필요한가가 기준입니다.

6. 코드 품질 작업도 대부분 Skill 후보가 될 수 있다

두 번째 예는 Code Quality입니다.

처음에는 이런 구조를 만들기 쉽습니다.

Main Coding Agent
        ↓
Refactoring Agent
        ↓
SwiftLint
Tests
CodeQL

하지만 Refactoring Agent가 하는 작업을 자세히 보면:

SwiftLint violation 수정

unused code 제거

deprecated API 교체

간단한 중복 제거

test 실행

정도일 수 있습니다.

이런 작업은 대부분 절차가 명확합니다.

Code Quality Skill

1. Analyzer를 실행한다.
2. Finding을 Rule별로 분류한다.
3. 작은 Batch로 묶는다.
4. 코드를 수정한다.
5. Build한다.
6. Test한다.
7. Finding이 사라졌는지 확인한다.

Tool은:

run_swiftlint

find_usages

apply_patch

run_build

run_tests

만 제공하면 됩니다.

구조는:

Coding Agent
     ↓
Code Quality Skill
     ↓
Analyzer / Build / Test

로 충분합니다.

굳이 Refactoring Agent라는 두 번째 Reasoning Loop가 필요하지 않을 수 있습니다.

7. Swift 6 Migration도 Agent 여러 개보다 Skill이 더 자연스러울 수 있다

iOS 프로젝트를 Swift 6으로 Migration한다고 해보겠습니다.

Multi-Agent 구조를 과하게 만들면 이런 모습도 가능합니다.

Main Agent
   │
   ├─ Concurrency Agent
   ├─ Sendable Agent
   ├─ Actor Agent
   ├─ Build Agent
   └─ Test Agent

기능 이름만 보면 역할이 잘 분리돼 보입니다.

하지만 실제 Migration 절차는 상당 부분 정형화돼 있습니다.

Compiler Warning 수집

↓

오류 유형 분류

↓

Sendable 문제 확인

↓

Actor Isolation 확인

↓

@MainActor 적용 여부 확인

↓

코드 수정

↓

Build

↓

Test

이것을 하나의 Skill로 만들 수 있습니다.

Swift 6 Migration Skill

그리고 Tool은:

run_build

search_symbol

find_concurrency_diagnostics

apply_patch

run_tests

를 제공합니다.

Main Coding Agent
        ↓
Swift 6 Migration Skill
        ↓
Compiler / Search / Test

이 정도 구조면 상당수 Migration 작업을 처리할 수 있습니다.

8. Skill이 좋은 영역의 특징은 꽤 분명하다

지금까지 예를 보면 공통점이 있습니다.

Release

Code Quality

Swift Migration

모두 일정한 절차가 있습니다.

그리고 사용할 Tool도 명확합니다.

정리하면 이런 특징을 가진 기능은 Skill 후보입니다.

Bounded Domain

명확한 Procedure

명확한 Input / Output

Typed Tool

Parent Agent가 판단 가능

이런 업무에 매번 별도의 Agent를 만들면 Reasoning Layer만 불필요하게 늘어날 수 있습니다.

9. 반대로 장애 대응은 Agent로 남기는 편이 자연스럽다

이번에는 반대 사례를 보겠습니다.

Production 장애가 발생했다고 해보겠습니다.

API Error Rate 급증

단순한 절차로 끝나지 않습니다.

Error Rate 확인
 ↓
최근 Deploy 확인
 ↓
특정 API인가?
 ↓
DB Latency 확인
 ↓
관련 Trace 확인
 ↓
최근 Commit 확인
 ↓
원인 가설 생성
 ↓
추가 로그 조회
 ↓
가설 수정

이 과정은 계속 달라집니다.

첫 번째 조사 결과에 따라 다음 Tool이 달라집니다.

Logs

Metrics

Tracing

Git

Deployment History

Feature Flag

를 어떤 순서로 사용할지도 미리 정하기 어렵습니다.

이런 작업은:

Explore
 ↓
Hypothesis
 ↓
Verify
 ↓
Re-plan

이 반복됩니다.

이 경우는 Skill보다 Incident Agent가 더 자연스럽습니다.

10. Research Agent도 같은 이유로 Agent로 남는다

Microsoft의 실제 사례에서도 모든 Specialist를 Skill로 바꾸지는 않았습니다.

Web Research 기능은 Agent로 유지했습니다.

Research는 보통:

검색
 ↓
결과 판단
 ↓
추가 검색
 ↓
출처 비교
 ↓
새로운 질문
 ↓
재검색
 ↓
정리

과정을 반복합니다.

미리 정해진 Tool 호출 순서가 없습니다.

독립적인 Reasoning이 필요합니다.

그래서:

Main Agent
   ↓
Research Agent
   ↓
Search Tools

구조가 자연스럽습니다.

이 부분이 중요한 이유는 Microsoft 사례의 메시지가

“Multi-Agent를 없애라”

가 아니기 때문입니다.

11. 실무에서 구분하는 기준은 생각보다 단순하다

Agent를 만들기 전에 다음 질문을 해보면 됩니다.

독립적으로 판단해야 하는가?

YES
→ Agent 후보

작업 중 새로운 가설을 만들고 재계획해야 하는가?

YES
→ Agent 후보

자체적으로 긴 Workflow를 수행하는가?

YES
→ Agent 후보

다른 모델이나 Private Context가 필요한가?

YES
→ Agent 후보

반대로:

절차가 명확한가?

YES
→ Skill 후보

Tool의 Input / Output이 명확한가?

YES
→ Skill 후보

Parent Agent가 Operation을 선택해도 되는가?

YES
→ Skill 후보

결국 이렇게 줄일 수 있습니다.

정해진 절차
+
명확한 Tool
        ↓
      Skill

탐색
+
가설
+
반복 판단
        ↓
      Agent

12. `SKILL.md`는 Agent의 System Prompt를 재사용 가능한 자산으로 만든다

Specialist Agent를 Skill로 바꿀 때 System Prompt가 사라지는 것은 아닙니다.

예를 들어 Release Agent에 이런 지침이 있었다고 해보겠습니다.

release branch에서만 배포한다.

working tree가 dirty면 중단한다.

test 실패 시 archive하지 않는다.

배포 후 build number를 기록한다.

기존에는 Release Agent의 System Prompt 안에 들어가 있습니다.

Release Agent
   ↓
System Prompt

Skill 구조에서는:

release/SKILL.md

로 이동합니다.

이 변화가 중요한 이유는 해당 지식이 더 이상 특정 Agent Runtime에 묶이지 않기 때문입니다.

Agent Prompt

가 아니라

Reusable Engineering Procedure

가 됩니다.

13. 팀의 개발 규칙도 Skill이 될 수 있다

이 구조를 한 단계 더 확장하면 팀 내부 Engineering Rule도 Skill로 만들 수 있습니다.

예를 들어:

ios-feature-development/SKILL.md

안에:

1. Feature Module 생성
2. Domain Interface 정의
3. Repository 연결
4. ViewModel 작성
5. SwiftUI View 작성
6. Unit Test 추가
7. Build 검증

을 정의합니다.

다른 Skill로는:

swift6-migration

ios-release

code-quality

dependency-update

를 둘 수 있습니다.

이렇게 되면 팀의 Engineering Knowledge가

Wiki
Confluence
README

에만 있는 것이 아니라 Agent가 실행할 수 있는 형태로도 존재하게 됩니다.

14. MCP Tool은 Skill과 역할이 다르다

여기서 Skill과 MCP를 하나로 생각하면 안 됩니다.

Skill은:

무엇을 해야 하는가?

어떤 순서로 해야 하는가?

어떤 기준을 따라야 하는가?

를 알려줍니다.

MCP Tool은:

무엇을 실행할 수 있는가?

를 제공합니다.

예를 들어:

Swift 6 Migration Skill

은 이런 절차를 설명합니다.

Concurrency Diagnostic을 먼저 분류한다.

MCP Tool은 실제 기능을 제공합니다.

run_build()

search_symbol()

apply_patch()

run_tests()

그리고 최종 판단은 Agent가 합니다.

Skill
 → Procedure

MCP
 → Capability

Agent
 → Reasoning

으로 나누면 이해하기 쉽습니다.

15. Tool을 처음부터 전부 Context에 넣을 필요도 없다

Agent 시스템이 커지면 Tool 수가 빠르게 늘어납니다.

예를 들어 개발 Agent에:

Git Tools             15개
CI Tools              10개
Xcode Tools           12개
GitHub Tools          20개
Monitoring Tools      18개
Database Tools        15개

가 있다면 이미 90개입니다.

모든 Tool Schema를 매 요청마다 모델에게 보여주는 것은 비효율적입니다.

Microsoft 사례에서는 Skill이 로드된 뒤 해당 Domain의 MCP Tool만 Context에 추가하는 방식을 사용했습니다.

처음

Release Skill
Migration Skill
Quality Skill
Incident Agent

정도만 보여줍니다.

사용자가:

Swift 6 Migration 진행해줘.

라고 하면:

load_skill("swift6-migration")

후에 관련 Tool만 추가합니다.

run_build
search_symbol
apply_patch
run_tests

나머지는 Context에 들어오지 않습니다.

이게 Progressive Disclosure의 핵심입니다.

16. Skill은 Context Engineering 수단이기도 하다

Tool이 많아지는 문제는 단순 UI 문제가 아닙니다.

각 Tool에는:

Name
Description
Input Schema
Output Schema

가 있습니다.

전부 Context에 들어가면 Token을 소비합니다.

그래서:

100 Tools

전체를 넣는 대신

10 Skill Summaries

만 먼저 제공하고,

선택된 Skill의 Tool만 뒤에서 추가하는 구조가 더 유리할 수 있습니다.

즉 Agent Skill은 단순한 Prompt 관리 기법이 아니라 Context Engineering 전략이기도 합니다.

17. Microsoft 사례에서는 Model Call이 절반 수준으로 줄었다

Microsoft는 동일한 Ski Resort 애플리케이션에서 기존 A2A Specialist 구조와 Skill + MCP 구조를 직접 비교했습니다.

A2A 구조에서는 세 번의 실행에서 Model Call이 각각:

6회
6회
7회

였습니다.

Skill + MCP 구조는 모두:

3회

였습니다.

Skill 방식에서는:

Model #1
→ 필요한 Skill 로드

Model #2
→ 필요한 MCP Operation 호출

Model #3
→ 최종 응답

으로 끝났습니다.

Specialist마다 별도의 Model Loop를 돌지 않았기 때문입니다.

18. 하지만 Token은 오히려 증가했다

여기서 중요한 결과가 하나 나옵니다.

Model Call이 줄었으니 Token도 줄었을 것 같지만 그렇지 않았습니다.

세 번의 실행을 합치면:

A2A

11,134 tokens

Skill 방식은:

13,533 tokens

이었습니다.

약 22% 많았습니다.

이유 중 하나는 Parent Agent의 Context가 계속 커졌기 때문입니다.

Skill Instruction
+
Tool Schema
+
Tool Result
+
Conversation Context

가 상위 Agent에 누적됩니다.

따라서

Model Call이 줄었다 = Token이 줄었다

는 공식은 성립하지 않습니다.

19. Multi-Agent의 Context Isolation은 여전히 장점이다

Specialist Agent를 유지하면 Context를 자연스럽게 분리할 수 있습니다.

예를 들어 Incident Agent는:

Logs
Metrics
Tracing

만 보면 됩니다.

Release Agent는:

Git
CI
App Store

만 봅니다.

Main Agent Context
≠
Incident Context
≠
Release Context

가 됩니다.

Skill 중심 구조에서는 Parent Agent가 더 많은 Domain Instruction과 Tool 정보를 가져가게 됩니다.

그래서 Agent를 줄이는 것이 항상 좋은 것도 아닙니다.

대규모 시스템에서는 Context Isolation 때문에 Agent를 분리하는 것이 더 나은 경우도 있습니다.

20. 보안 정책은 Skill에 맡기면 안 된다

예를 들어 Release Skill에:

Production 배포는 관리자만 가능하다.

라고 적었다고 해보겠습니다.

이것은 Security Policy가 아닙니다.

LLM Instruction일 뿐입니다.

실제 Tool이나 Service에서는 반드시 다시 검증해야 합니다.

Authentication

Authorization

Validation

Audit Log

를 코드에서 강제해야 합니다.

구조는 이렇게 보는 것이 맞습니다.

Skill

→ 어떻게 작업할지 설명

Tool

→ 실행 가능한 Operation 제공

Service

→ 실제 Business Rule과 Security 강제

Agent Architecture에서 이 경계를 흐리면 위험합니다.

21. 개발팀에서 가장 현실적인 구조는 Hybrid다

실제 개발 시스템에서는 다음 형태가 가장 현실적일 수 있습니다.

                   Main Coding Agent
                          │
          ┌───────────────┼───────────────┐
          │               │               │
    Release Skill   Migration Skill   Incident Agent
          │               │               │
      MCP Tools        MCP Tools       Agent Loop
          │               │               │
         CI            Compiler       Logs / Metrics

여기에:

Code Quality Skill

Dependency Update Skill

SPM Migration Skill

같은 것을 추가할 수 있습니다.

반면:

Incident Analysis

Research

Architecture Investigation

처럼 탐색과 판단이 필요한 작업은 Agent로 유지합니다.

22. 결국 중요한 건 Agent의 개수가 아니다

멀티에이전트 시스템을 설계하다 보면 Agent가 많을수록 역할이 명확하고 구조가 고도화된 것처럼 보이기도 합니다.

하지만 Agent 하나는 단순한 Class 하나가 아닙니다.

Model
Context
Reasoning
Tools
Lifecycle
Failure
Observability
Cost

를 가진 Runtime입니다.

그래서 기능 하나가 추가될 때마다 먼저 물어볼 질문은:

어떤 Agent를 만들까?

가 아니라

이 기능에
별도의 Reasoning Loop가 필요한가?

가 되어야 합니다.

필요 없다면:

Skill
+
Tool

이 더 단순합니다.

필요하다면:

Agent

가 맞습니다.

마치며

Multi-Agent Architecture가 잘못된 것은 아닙니다.

독립적인 판단과 긴 Workflow가 필요한 작업에서는 여전히 강력합니다.

하지만

Release

Code Quality

Migration

Dependency Update

처럼 절차가 비교적 명확한 기능까지 각각 Agent로 만드는 것은 과할 수 있습니다.

이런 영역은:

SKILL.md
+
MCP Tools

정도로도 충분히 구현할 수 있습니다.

반대로:

Incident Response

Research

Architecture Investigation

처럼

탐색
 ↓
가설
 ↓
검증
 ↓
재계획

이 반복되는 작업은 별도의 Agent가 자연스럽습니다.

Microsoft의 사례에서도 같은 결론이 나옵니다.

일부 Specialist Agent를 Skill + MCP로 바꾸면서 Model Call은 줄었지만 Token 사용량까지 자동으로 줄지는 않았고, Research처럼 독립성이 필요한 기능은 계속 Agent로 유지했습니다.

결국 기준은 간단합니다.

정해진 절차와 명확한 Tool이 있다면 Skill.

탐색하고 가설을 세우고 다시 판단해야 한다면 Agent.

그리고 Multi-Agent Architecture를 설계할 때는 Agent를 하나 더 만들기 전에 한 번쯤 물어볼 필요가 있습니다.

이 기능에 정말 또 하나의 LLM이 필요한가?

참고자료

Microsoft Agent Framework — From Specialist Agents to Distributed Skills over MCP
Specialist Agent 구조를 Skill + MCP Tool 구조로 변경하고 Model Call, Latency, Token 사용량을 직접 비교한 Microsoft 공식 사례입니다.
공식 글 보기
Microsoft Agent Framework — Discover Agent Skills from MCP servers in .NET
MCP Server에서 Skill을 중앙 배포하고, Agent가 필요한 Skill을 On-demand로 가져오는 구조와 Progressive Disclosure 방식을 확인할 수 있습니다.
공식 글 보기
Microsoft Agent Framework — Give Your Agents Domain Expertise with Agent Skills
SKILL.md를 중심으로 Domain Instruction, Reference, Script 등을 Agent에 필요할 때만 제공하는 기본 Agent Skills 구조를 설명합니다.
공식 글 보기
Microsoft Agent Framework — Agent Skills for .NET Is Now Released
Agent Skills for .NET의 Stable API와 Production 환경에서 Skill을 재사용·배포하는 방식을 확인할 수 있습니다.
공식 글 보기

Microsoft 공식 사례 기준으로 보면, 이번 Architecture 변경의 핵심은 Domain Service를 합치는 것이 아닙니다. Service와 Data, Deployment Boundary는 그대로 유지하고 Specialist가 갖고 있던 별도 Model Loop만 제거한 뒤, Domain Instruction은 Skill로, 실행 기능은 MCP Tool로 제공했습니다.

같은 질문을 비교한 세 번의 실행에서 A2A Specialist 방식은 6회·6회·7회의 Model Call이 발생했고 Skill + MCP 방식은 모두 3회였습니다. 반면 전체 Token 사용량은 Skill 방식이 13,533개로 A2A의 11,134개보다 약 22% 많았습니다. Microsoft 역시 이 결과를 통제된 성능 비교로 보지 말아야 한다고 명시하고 있습니다.

또한 Research Agent처럼 독립적인 탐색, 긴 Workflow, 별도 Context나 Specialized Model이 필요한 Component는 Agent로 유지했습니다. 실제 Production Architecture 역시 Agent 또는 Skill 중 하나를 고르는 구조보다, 둘을 역할에 따라 함께 사용하는 Hybrid 형태가 더 현실적입니다.

Swift 6.4, 빌드와 디버깅이 모듈 중심으로 바뀐다

Tue, 15 Sep 2026 09:29:20 GMT

Swift 6.4, 빌드와 디버깅이 모듈 중심으로 바뀐다

LLDB부터 dSYM, Bridging Header, Swift Build까지 한 번에 정리

Swift 6.4에서 꽤 큰 변화가 하나 들어옵니다.

새로운 문법이나 SwiftUI API가 아니라 Compiler, Build System, LLDB가 Swift Module을 다루는 방식입니다.

Swift.org가 9월 11일 공개한 내용을 보면 Swift 6.3부터 진행되던 Explicit Module Tracking이 Swift 6.4에서 Debugging까지 본격적으로 연결됩니다.

결과적으로 대부분의 Xcode와 SwiftPM 프로젝트에서는 별다른 코드 변경 없이

LLDB의 Module Lookup 안정성 개선
일부 Debugging 지연 감소
Bridging Header Import 속도 개선
dSYM 크기 감소
Build System의 Module 처리 단순화

효과를 받을 수 있습니다.

겉으로는 LLDB 개선처럼 보이지만 조금 더 넓게 보면 최근 Swift Toolchain이 움직이는 방향이 보입니다.

Implicit Dependency
        ↓
Explicit Module
        ↓
Precise Dependency Graph
        ↓
Compiler
Build System
Debugger

각 도구가 Module을 제각각 다시 찾는 구조에서, Build할 때 만들어진 정확한 Module Dependency를 공유하는 구조로 옮겨가고 있습니다.

1. LLDB에서 `po`가 유난히 느릴 때가 있었던 이유

Breakpoint에서 단순한 Local Variable을 확인하는 작업은 비교적 간단합니다.

p user

이 경우 LLDB는 Debug Info와 Reflection Metadata를 이용해서 변수의 위치와 타입을 알아낼 수 있습니다.

하지만 다음은 조금 다릅니다.

p user.displayName

displayName이 Computed Property라면 실제 Function Call이 필요합니다.

LLDB는 내부 Swift Compiler를 이용해 Expression을 JIT Compile하고 실행합니다.

개념적으로는 이런 작업입니다.

import MyFeature

func lldb_expr(...) {
    user.displayName
}

문제는 여기서 발생합니다.

LLDB가 정확한 MyFeature.swiftmodule을 찾아야 하기 때문입니다.

기존에는 Debug Info가 사실상

Module Name = MyFeature

정도만 가지고 있는 경우가 있었습니다.

그러면 LLDB는 Module 이름을 기준으로 적절한 파일을 다시 찾아야 합니다.

대형 프로젝트에서는 이것이 생각보다 단순하지 않습니다.

MyFeature.swiftmodule

├─ Debug
├─ Release
├─ macOS
├─ Mac Catalyst
├─ Private Module
└─ Public Interface

같은 이름의 서로 다른 Module Variant가 존재할 수 있기 때문입니다.

2. 기존에는 Module 이름을 찾고, 없으면 다시 Compile하기도 했다

과거 LLDB의 Module Import 흐름을 단순화하면 이렇습니다.

Breakpoint

↓

현재 Module 이름 확인

↓

Module Cache 검색

↓

정확한 Module이 없으면

↓

Implicit Module Import

↓

Dependency 재Compile 가능

Cold Module Cache에서는 이 비용이 특히 커질 수 있습니다.

그래서 첫 po나 Expression Evaluation이 유난히 느린 경험이 생기기도 했습니다.

특히

대형 프로젝트
Objective-C + Swift 혼합 프로젝트
Bridging Header가 큰 프로젝트
SDK Module Dependency가 많은 프로젝트

에서 체감될 수 있었습니다.

Swift 6.4가 해결하려는 핵심 문제는 바로 이것입니다.

Module을 이름으로 다시 찾지 말고 Build할 때 사용한 정확한 Module을 기억하자.

3. 시작점은 Explicit Modules다

이 변화는 Swift 6.4에서 갑자기 시작된 것은 아닙니다.

Xcode는 이미 Xcode 16부터 Explicit Module Dependency를 적극적으로 사용하고 있습니다.

기존 방식에서는 Source를 Compile하다 필요한 Module을 Compiler가 발견하면 Module Cache에서 찾거나 그 자리에서 Build할 수 있었습니다.

Source Compile
     ↓
Import 발견
     ↓
Module 필요
     ↓
Module Cache 검색
     ↓
없으면 Compile

Explicit Module 방식에서는 Build System이 먼저 Dependency를 Scan합니다.

Dependency Scan
      ↓
┌───────────────┐
│ Foundation    │
│ MyDomain      │
│ MyNetwork     │
│ FeatureA      │
└───────────────┘
      ↓
Module Build
      ↓
Source Compile

Module Dependency가 Build Graph에 명시적으로 나타납니다.

그러면 Build System은 어떤 Module을 먼저 만들어야 하는지 정확하게 알 수 있습니다.

병렬 Build도 더 효율적으로 Scheduling할 수 있고, Module Build가 실패했을 때 원인도 더 명확하게 확인할 수 있습니다.

4. Swift 6.3부터 Swift Module끼리 Dependency를 직접 기록한다

Explicit Swift Module은 예전부터 Clang Module Dependency를 알고 있었습니다.

하지만 Swift Module끼리의 Dependency Tracking은 충분하지 않았습니다.

Swift 6.3부터 이 부분이 달라졌습니다.

예를 들어

FeatureModule
     ↓
DomainModule
     ↓
NetworkModule
     ↓
Foundation

구조가 있다면 FeatureModule.swiftmodule이 자신이 어떤 Swift Module에 의존했는지 명시적으로 기록할 수 있습니다.

따라서 LLDB가 FeatureModule을 가져오면 그다음 Dependency를 이름으로 다시 찾아다닐 필요가 줄어듭니다.

FeatureModule

→ /path/DomainModule.swiftmodule

→ /path/NetworkModule.swiftmodule

정확한 Module Graph를 따라갈 수 있습니다.

5. `-debug-module-path`가 중요한 이유

LLDB가 Dependency를 정확하게 알고 있어도 시작점이 필요합니다.

Breakpoint가 걸린 Object File이

어떤 Swift Module에서 만들어진 것인가?

를 알아야 합니다.

Swift 6.3부터 Compiler는 이를 Debug Info에 저장할 수 있습니다.

이때 사용되는 것이

-debug-module-path

입니다.

개념적으로는

Foo.o

→ Foo.swiftmodule의 정확한 위치

를 Debug Info에 기록하는 것입니다.

Xcode나 SwiftPM을 사용한다면 직접 신경 쓸 필요가 없습니다.

Swift Driver가 자동으로 처리합니다.

반면

Bazel
Buck
CMake
Custom Build System

처럼 Swift Frontend를 직접 호출하는 Build System이라면 이 변화가 중요합니다.

6. Swift 6.4에서는 `modulewrap`과 `add_ast_path`가 사실상 사라진다

기존 Swift Debugging에는 Module을 Binary나 dSYM으로 전달하기 위한 별도의 과정이 있었습니다.

Darwin에서는 Linker에

-add_ast_path

를 넘겼습니다.

Linux나 Windows에서는

-modulewrap

을 사용했습니다.

예를 들어 Linux에서는

Foo.swiftmodule
      ↓
-modulewrap
      ↓
Foo.swiftmodule.o
      ↓
Link

방식으로 Swift Module 자체를 Object File에 집어넣었습니다.

Swift 6.4에서는 Precise Module Tracking 덕분에 이런 과정이 필요 없어집니다.

핵심 변화는 간단합니다.

기존

-modulewrap
-add_ast_path

에서

Swift 6.4

-debug-module-path

중심으로 바뀝니다.

Xcode나 SwiftPM 사용자는 대부분 자동으로 적용됩니다.

하지만 Bazel이나 자체 Build Infrastructure를 운영한다면 Build Rule을 확인할 필요가 있습니다.

7. dSYM에서 Swift Module도 빠진다

이번 변화에서 가장 눈에 띄는 부분 중 하나입니다.

기존 dSYM 안에는 Binary Swift Module이 포함될 수 있었습니다.

MyApp.dSYM

├─ DWARF
├─ Debug Info
└─ Swift Modules

Swift 6.4부터 dsymutil은 Binary Swift Module을 더 이상 dSYM에 포함하지 않습니다.

MyApp.dSYM

├─ DWARF
└─ Debug Info

그 결과 dSYM 크기가 줄어듭니다.

Swift.org에서는 Windows/Linux Binary와 Darwin의 dSYM 모두 크기가 크게 줄어들 수 있다고 설명하고 있습니다.

8. 그런데 Swift Module이 없으면 `po`는 어떻게 동작할까

여기서 자연스럽게 궁금해집니다.

Swift Module을 dSYM에서 뺐는데
Debugger가 Type을 어떻게 알지?

Swift 5.6 이후 LLDB는 Local Variable의 타입과 Object Description을 확인하는 데 필요한 정보를 Binary의 Reflection Metadata에서 읽을 수 있습니다.

따라서 이런 작업은 계속 가능합니다.

po user

Binary Swift Module이 필요한 것은 조금 더 복잡한 Expression입니다.

예를 들어

p user.computedProperty

또는 Function Call처럼 실제 Compile이 필요한 Expression입니다.

이 경우 LLDB는 Module을 원래 Build 위치에서 찾습니다.

새로운 Precise Module Tracking 덕분에 예전처럼 이름으로 추측하는 것이 아니라 정확한 Module Path를 따라갈 수 있습니다.

9. dSYM에 Binary Module을 보관하지 않는 게 오히려 자연스럽다

Binary Swift Module에는 특징이 하나 있습니다.

정확히 같은 Compiler Toolchain에 종속됩니다.

다른 Swift Compiler Version에서 만들어진 Binary Module을 그대로 읽을 수 있다고 보장할 수 없습니다.

반면 dSYM은 Crash Symbolication 등을 위해 장기간 보관하는 Artifact입니다.

App Release
   ↓
dSYM 보관
   ↓
6개월 후 Crash 분석

이런 용도입니다.

따라서 Toolchain Version에 강하게 종속되는 Binary Swift Module을 장기 보관용 dSYM 안에 넣는 구조 자체가 조금 어색했습니다.

Swift 6.4에서는 이 역할을 분리합니다.

dSYM
→ Long-term Debug Info

Swift Module
→ Build Artifact

Toolchain Architecture 측면에서도 더 깔끔한 구조입니다.

10. Bridging Header도 드디어 빨라진다

오래된 iOS 프로젝트라면 이번 변화에서 가장 체감할 부분일 수 있습니다.

Swift와 Objective-C가 섞여 있는 프로젝트에서는 Bridging Header가 흔합니다.

MyApp-Bridging-Header.h

Swift 6.3까지 LLDB는 Expression Evaluation 과정에서 Bridging Header를 다시 Source부터 Compile할 수 있었습니다.

LLDB

↓

Bridging Header

↓

Header Parsing

↓

Clang Compile

↓

Module Import

Header가 크거나 Objective-C Dependency가 많으면 첫 Debug Expression이 느려질 수 있습니다.

Swift 6.4에서는 Explicit Module 정보를 이용해서 Precompiled Bridging Header와 Dependency를 직접 Import할 수 있습니다.

LLDB
 ↓
Precompiled Bridging Header
 ↓
Explicit Module Dependencies

Fully Modularized Project에 가까운 Debugging 성능을 얻는 것이 목표입니다.

Obj-C와 Swift가 오래 공존한 대형 iOS 프로젝트에서는 상당히 반가운 변화입니다.

11. 결국 Compiler와 Debugger가 같은 Module Graph를 보게 된다

여기까지 정리하면 이번 변화의 핵심이 보입니다.

예전에는 각 단계가 Module을 조금씩 다르게 찾았습니다.

Compiler
   ↓
Module Cache

Build System
   ↓
Dependency Scan

Linker
   ↓
add_ast_path

dSYM
   ↓
Swift AST

LLDB
   ↓
Module Name Lookup

점점 이 구조가 단순해지고 있습니다.

        Explicit Module Graph
                 │
       ┌─────────┼─────────┐
       │         │         │
    Compiler   Build      LLDB
              System

Build할 때 결정된 Module Graph를 Toolchain 전체가 공유하는 방향입니다.

이번 Swift 6.4 변화에서 가장 중요한 부분입니다.

12. Swift가 최근 모듈 중심으로 움직이는 흐름은 이것만이 아니다

여기부터는 Swift 6.4 Debugging 자체와는 조금 다른 이야기지만 같은 방향에서 볼 만한 변화가 있습니다.

Swift 생태계에서는 최근 여러 기능을 보다 명확한 Module과 Toolchain Layer로 정리하는 작업이 계속되고 있습니다.

대표적인 것이 FilePath입니다.

13. `FilePath`가 swift-system에서 Swift Standard Library로 올라온다

그동안 Swift에서 File System Path를 제대로 표현하려면 swift-system의 FilePath를 사용하는 방법이 있었습니다.

import SystemPackage

let path: FilePath

문제는 FilePath가 외부 Package에 있다는 것입니다.

Foundation이나 Swift Runtime처럼 더 낮은 계층에서는 외부 Package를 쉽게 Dependency로 사용할 수 없습니다.

SE-0529에서는 FilePath를 Swift Standard Library의 Swift Module로 이동하는 방향이 승인됐습니다.

앞으로는 개념적으로

let path: FilePath = "/Users/dev/project"

처럼 Swift의 기본 Currency Type으로 사용할 수 있게 됩니다.

구조도

swift-system

FilePath

에서

Swift Standard Library

Swift.FilePath

로 이동합니다.

14. 왜 FilePath를 `Swift` Module에 넣는 게 중요할까

String이 Path를 표현하는 데 항상 좋은 타입은 아닙니다.

let path: String

은 이것이

URL인지
파일 경로인지
일반 Text인지

타입만 보고 구분할 수 없습니다.

FilePath는 File System Path 자체를 타입으로 표현합니다.

더 중요한 이유는 Dependency Layer입니다.

Swift Runtime
Foundation
Swift Testing
Build Tools

같은 Toolchain 구성요소가 공통으로 File Path를 다뤄야 합니다.

FilePath가 외부 Package에 있으면 이런 Core Library가 사용하기 어렵습니다.

Standard Library로 올라오면 공통 Currency Type으로 사용할 수 있습니다.

15. Foundation도 이미 하나의 거대한 Framework에서 나뉘고 있다

Foundation도 같은 맥락에서 볼 만합니다.

Swift 6에서는 주요 Foundation API의 Swift 구현이 여러 플랫폼에서 통합됐습니다.

그리고 전체 Foundation이 필요하지 않은 경우를 위해

import FoundationEssentials

도 사용할 수 있습니다.

FoundationEssentials는 Internationalization과 Localization Data 같은 무거운 부분을 제외하고 핵심 Foundation 기능을 제공합니다.

개념적으로는

Foundation

모든 기능

하나만 사용하는 구조에서

Foundation

├─ FoundationEssentials
├─ Internationalization
└─ 추가 Foundation 기능

처럼 필요한 Layer를 더 명확하게 가져갈 수 있는 방향입니다.

특히 Server Swift나 Embedded 환경에서는 Binary Size와 Dependency가 중요한 만큼 의미가 큽니다.

16. SwiftPM도 Swift Build로 통합되는 중이다

Build System 쪽에서도 비슷한 변화가 진행되고 있습니다.

Swift 6.3에서는 Swift Package Manager에서 Swift Build Integration Preview를 사용할 수 있게 됐습니다.

원래 SwiftPM과 Xcode는 완전히 같은 Build Engine을 사용하지 않았습니다.

Swift 프로젝트가 커질수록

Xcode Build

SwiftPM Build

CI Build

환경 차이가 문제가 될 수 있습니다.

Swift 프로젝트는 현재 Swift Build를 공통 Build Infrastructure로 가져오는 방향으로 움직이고 있습니다.

개념적으로는

Xcode
   ↓
Swift Build

그리고

SwiftPM
   ↓
Swift Build

구조에 가까워집니다.

Swift main branch 역시 Swift Build를 기본 Build System으로 사용하는 방향으로 전환됐습니다.

17. 결국 하나의 Dependency Graph로 수렴하고 있다

이 변화들을 하나씩 보면 서로 다른 기능처럼 보입니다.

Explicit Modules

LLDB Module Tracking

Smaller dSYM

Bridging Header 개선

Swift Build

FilePath

FoundationEssentials

하지만 Toolchain 관점에서는 공통된 방향이 있습니다.

과거에는

Compiler

Build System

Package Manager

Debugger

Core Libraries

각 영역이 어느 정도 독립적으로 Dependency를 관리했습니다.

앞으로는

        Module / Dependency Graph
                  │
     ┌────────────┼────────────┐
     │            │            │
 Compiler     Build System    LLDB
     │            │            │
     └────────────┼────────────┘
                  │
               SwiftPM

처럼 명시적인 Dependency를 공유하는 방향으로 움직이고 있습니다.

Swift 6.4의 LLDB 변화가 중요한 이유도 여기에 있습니다.

단순한 Debugger 최적화가 아니라 Toolchain 전체가 Explicit Module Graph를 신뢰하기 시작했다는 신호이기 때문입니다.

18. 일반적인 Xcode 프로젝트에서는 무엇을 해야 할까

대부분은 아무것도 하지 않아도 됩니다.

Xcode와 SwiftPM을 사용하고 있다면 Swift Driver와 Build System이 대부분 자동으로 처리합니다.

오히려 확인해볼 부분은 오래된 프로젝트입니다.

Objective-C + Swift 혼합

대형 Bridging Header

Custom Build Script

Static Library

Bazel / Buck / CMake

오래된 Module Setting

같은 환경입니다.

특히 자체 Build System을 운영한다면

-modulewrap

-add_ast_path

를 사용하는 Build Rule이 있는지 확인할 필요가 있습니다.

Swift 6.4에서는 이런 처리를 제거하고 -debug-module-path 방식으로 이동할 수 있습니다.

19. iOS 프로젝트에서 확인해볼 것

Swift 6.4 전환을 준비한다면 다음 정도는 확인할 만합니다.

□ Bridging Header가 지나치게 커져 있지 않은가?

□ Objective-C Header가 Module화되지 않은 채 남아 있지 않은가?

□ Static Library Debugging에서 별도 Swift Module 처리를 하고 있는가?

□ Bazel/Buck/CMake Build Rule에 -modulewrap이 남아 있는가?

□ Linker Option에 -add_ast_path를 직접 추가하고 있는가?

□ CI에서 dSYM 크기나 Upload 시간이 큰 편인가?

□ 첫 LLDB Expression Evaluation이 유난히 느린 프로젝트인가?

□ Explicit Modules가 비활성화된 오래된 Target이 있는가?

일반적인 앱에서는 코드 Migration보다 Build Infrastructure 점검에 가까운 변화입니다.

20. Swift 6.4의 변화가 중요한 이유

Swift 개발에서 Module은 예전부터 존재했습니다.

새로운 개념은 아닙니다.

달라지는 것은 Module이 Toolchain에서 갖는 역할입니다.

예전에는

import Foundation

처럼 Source Code의 Namespace와 Dependency 정도로 생각하기 쉬웠습니다.

지금은

Compilation Unit

Dependency Graph

Build Scheduling

Caching

Debugging

Symbol Resolution

까지 Module 정보가 관여합니다.

즉 Module은 단순한 코드 분리 단위가 아니라 Swift Toolchain을 연결하는 공통 단위가 되고 있습니다.

마치며

Swift 6.4에서 가장 눈에 띄는 변화 중 하나는 Debugger가 Module을 찾는 방식입니다.

예전에는 LLDB가 Module 이름을 보고 적절한 Module을 찾아야 했습니다.

이제는 Build할 때 사용한 정확한 Module Path와 Dependency Graph를 따라갈 수 있습니다.

그 결과

LLDB Import 안정성 ↑

Bridging Header Import 속도 ↑

dSYM 크기 ↓

불필요한 Module Compile ↓

Custom Build 단계 ↓

같은 변화가 가능해집니다.

그리고 이 흐름을 조금 넓게 보면 최근 Swift Toolchain의 방향도 보입니다.

Implicit
    ↓
Explicit

Name Lookup
    ↓
Precise Path

Hidden Dependency
    ↓
Dependency Graph

Tool별 Build 정보
    ↓
공유되는 Module 정보

FilePath가 Standard Library로 이동하고, Foundation이 세분화되고, SwiftPM이 Swift Build를 받아들이는 변화까지 같은 시기에 진행되고 있습니다.

모두 똑같은 프로젝트는 아니지만 방향은 비슷합니다.

Swift의 Compiler, Build System, Package Manager, Debugger가 명확한 Module과 Dependency를 중심으로 정리되고 있습니다.

Swift 6.4의 Module Tracking은 그중에서도 일반 iOS 개발자가 직접 체감할 가능성이 높은 변화입니다.

새로운 문법 하나보다 눈에 덜 띌 수 있지만 대형 프로젝트에서는 Build와 Debugging 경험을 꽤 크게 바꿀 수 있는 변화입니다.

참고자료

Swift.org — Module Tracking in Swift Debug Info
Swift 6.3부터 시작된 Precise Module Tracking과 Swift 6.4의 modulewrap, add_ast_path, dSYM, Bridging Header 변화를 설명한 공식 자료입니다.
Swift.org 공식 글 보기
Apple Developer — Building your project with explicit module dependencies
Xcode의 Explicit Module Dependency Scan과 Module Build Scheduling 구조를 확인할 수 있습니다.
Apple Explicit Module 공식 문서
Swift Evolution — SE-0529 Add FilePath to the Standard Library
swift-system의 FilePath를 Swift Module의 기본 타입으로 이동하는 배경과 Migration 방향을 확인할 수 있습니다.
SE-0529 공식 Proposal
Swift.org — What's new in Swift: March 2026
Swift 6.3의 SwiftPM + Swift Build Integration과 Build Infrastructure 통합 방향을 확인할 수 있습니다.
Swift Build 공식 업데이트
Swift.org — Swift Core Libraries
Swift Foundation의 통합 구현과 FoundationEssentials의 역할을 확인할 수 있습니다.
Swift Core Libraries 공식 문서

Swift 공식 자료 기준으로 보면, Swift 6.4의 핵심 변화는 LLDB가 Swift Module을 이름으로 추측해서 찾는 대신 Build 시점에 기록된 정확한 Module Path와 Explicit Dependency를 사용할 수 있게 되는 것입니다. 이에 따라 -modulewrap과 -add_ast_path를 제거할 수 있고, Binary Swift Module을 dSYM에 포함하지 않아도 되면서 Debug Artifact 크기도 줄어듭니다.

또 Swift 6.4에서는 LLDB가 Bridging Header를 Source부터 다시 Compile하는 대신 Precompiled Bridging Header와 Explicit Module Dependency를 직접 사용할 수 있게 됩니다. 일반적인 Xcode/SwiftPM 프로젝트는 별도 대응이 필요하지 않지만 Bazel·Buck·CMake 등 Custom Build System은 -debug-module-path 처리 여부를 확인할 필요가 있습니다.

현실적으로 이번 변화를 “새로운 Module 기능”이라기보다 Compiler → Build System → LLDB가 하나의 Explicit Module Graph를 공유하도록 정리되는 변화로 보는 것이 가장 정확합니다.

기술부채도 이제 AI에게 티켓처럼 던진다

Sat, 12 Sep 2026 09:30:51 GMT

기술부채도 이제 AI에게 티켓처럼 던진다

GitHub Agentic Autofix가 바꾸는 기술부채 처리 방식

프로젝트를 오래 운영하다 보면 이상하게 없어지지 않는 목록이 하나 있습니다.

Code Quality backlog입니다.

당장 장애를 만드는 버그는 아니지만 언젠가는 고쳐야 하는 코드들입니다.

중복 코드
불필요한 조건문
사용되지 않는 표현식
복잡도가 높은 함수
유지보수성이 떨어지는 코드
신뢰성 문제

CodeQL이나 각종 정적 분석 도구가 계속 문제를 찾아내지만 실제 프로젝트에서는 이런 finding이 빠르게 쌓입니다.

이유는 간단합니다.

급하지 않기 때문입니다.

신규 기능
   ↓
버그 수정
   ↓
긴급 배포
   ↓
성능 문제
   ↓
기술부채

항상 기술부채가 마지막으로 밀립니다.

그런데 GitHub가 9월 9일 공개한 Agentic Autofix는 이 오래된 흐름을 조금 다른 방식으로 바꾸기 시작했습니다.

이제 Code Quality 화면에서 최대 25개의 finding을 한꺼번에 선택해서 Copilot에게 작업으로 넘길 수 있습니다.

그리고 Copilot은 단순히 수정 코드를 제안하는 데서 끝나지 않습니다.

Finding 선택
     ↓
Assign to Copilot
     ↓
Branch 생성
     ↓
코드 탐색
     ↓
수정
     ↓
검증
     ↓
Pull Request 생성
     ↓
Developer Review

기술부채를 하나씩 직접 처리하는 것이 아니라,

backlog 자체를 Agent의 작업 큐처럼 사용하는 방식입니다.

기존 Autofix와 뭐가 다른가

GitHub에는 이미 Copilot Autofix가 있었습니다.

Code Quality나 Code Scanning에서 문제가 발견되면 수정안을 생성해주는 기능입니다.

흐름은 대략 이런 형태였습니다.

Finding
   ↓
Generate Fix
   ↓
Suggested Change
   ↓
Developer 확인
   ↓
Commit

개발자 입장에서는 꽤 편하지만 본질적으로는 코드 수정 제안 기능에 가깝습니다.

Finding 하나를 보고 수정안을 생성하고, 개발자가 그 결과를 확인해서 적용합니다.

이번 Agentic Autofix는 작업 단위가 조금 다릅니다.

Finding
   ↓
Fix suggestion

이 아니라

Finding 묶음
   ↓
Agent Task

이 됩니다.

GitHub Code Quality 화면에서 최대 25개의 standard finding을 선택하고 Assign to Copilot을 누르면 하나의 remediation 작업으로 넘길 수 있습니다.

예를 들어 프로젝트에 이런 finding이 있다고 해보겠습니다.

Overwritten property     12
Expression has no effect  8
Redundant condition       5

총 25개를 선택해서 Agent에게 넘깁니다.

그다음부터는 Copilot이 작업을 진행합니다.

중요한 차이는 Agent가 코드베이스를 본다는 것

기존 Autofix는 문제가 발생한 코드 주변에서 수정안을 만드는 방식에 가까웠습니다.

Agentic Autofix는 Copilot Cloud Agent를 사용합니다.

따라서 필요한 경우 해당 파일 하나만 보는 것이 아니라 관련된 코드까지 탐색할 수 있습니다.

예를 들어 이런 코드가 있다고 해보겠습니다.

final class UserRepository {

    private let apiClient: APIClient

    init(apiClient: APIClient) {
        self.apiClient = apiClient
    }

    func fetchUser() async throws -> User {
        let result = try await apiClient.fetchUser()
        return result
    }
}

정적 분석에서는 단순한 코드 하나가 문제로 잡혔더라도 실제 수정에는 다른 요소가 영향을 줄 수 있습니다.

Protocol
Dependency
Test
Caller
Configuration

기존의 단순 fix generator라면 finding 주변 코드만 수정하기 쉽습니다.

Agent는 필요하면 Repository를 탐색하면서

이 코드는 어디에서 호출되는가?
이 타입을 사용하는 테스트가 있는가?
수정하면 다른 코드가 깨지는가?
같은 패턴이 다른 파일에도 존재하는가?

를 확인할 수 있습니다.

이 차이가 Autofix와 Agentic Autofix를 구분하는 핵심입니다.

수정한 다음에는 스스로 검증한다

Agentic Autofix에서 더 중요한 부분은 Validation입니다.

코드 생성 AI의 가장 큰 문제는 코드를 만드는 것 자체가 아니었습니다.

그 코드가 정말 맞는지 확인해야 한다는 것이 문제였습니다.

예전 AI Coding Workflow는 흔히 이랬습니다.

Developer
   ↓
AI에게 수정 요청
   ↓
코드 생성
   ↓
Developer가 Build
   ↓
Error
   ↓
다시 AI

Agentic Workflow에서는 이 반복 일부를 Agent가 가져갑니다.

Agent
 ↓
Analyze
 ↓
Modify
 ↓
Validate
 ↓
Problem?
 ├─ Yes → 다시 수정
 │
 └─ No → Pull Request

GitHub의 Agentic Autofix는 변경한 내용을 검증한 뒤 Pull Request를 생성합니다.

Code scanning alert의 경우에는 원래 문제를 찾았던 분석을 다시 실행해서 실제로 alert가 사라졌는지 확인하는 방식도 사용됩니다.

즉 목표가

“코드를 수정했다.”

가 아니라

“finding을 해결했다.”

로 달라집니다.

이 차이는 생각보다 큽니다.

이제 finding 하나와 finding 25개의 Workflow가 같다

이번 변경에서 눈에 띄는 UI 변화도 있습니다.

기존의 개별 finding용 Generate fix 흐름이 Assign to Copilot으로 통합됐습니다.

따라서 하나의 finding을 처리하든 25개를 처리하든 기본 흐름은 같습니다.

1 Finding
    ↓
Assign to Copilot

또는

25 Findings
     ↓
Assign to Copilot

입니다.

이런 구조가 중요한 이유는 AI 기능을 별도의 도구처럼 사용하지 않아도 되기 때문입니다.

기존에는

Code Quality
      ↓
Finding 확인
      ↓
IDE 이동
      ↓
코드 찾기
      ↓
AI에게 설명
      ↓
수정

과정이 필요했다면,

이제 Finding 자체가 Agent Task가 됩니다.

Code Quality Finding
        =
   Agent Ticket

에 가까워지는 것입니다.

기술부채 관리에서 가장 비싼 것은 수정 코드가 아니다

기술부채를 직접 수정해보면 실제로 시간을 많이 쓰는 곳은 몇 줄의 코드를 변경하는 부분이 아닙니다.

오히려 이런 과정에서 시간이 많이 듭니다.

어떤 finding부터 고칠지 찾기

↓

관련 코드 확인

↓

영향 범위 파악

↓

수정

↓

테스트

↓

PR 작성

↓

리뷰

특히 오래된 Repository에서는 첫 번째와 두 번째 단계가 훨씬 어렵습니다.

몇 년 전에 작성된 코드의 warning 하나를 수정하려고 파일을 열었는데,

왜 이렇게 작성했지?

부터 시작하는 경우도 많습니다.

그리고 결국

나중에 하자

가 됩니다.

Agentic Autofix가 줄이려는 부분은 바로 이 작업 비용입니다.

Developer가 직접 finding마다 Context를 다시 만드는 대신,

Finding
+
Repository Context
+
Analysis Result

를 Agent에게 넘깁니다.

이게 반복되면 기술부채 처리 방식 자체가 달라질 수 있습니다.

Technical Debt Backlog가 Agent Queue로 바뀐다

기존 기술부채 관리 방식은 보통 이렇습니다.

Static Analysis
      ↓
Finding
      ↓
Jira Ticket
      ↓
Backlog
      ↓
Sprint 여유?
      ↓
Developer Assign
      ↓
Fix

문제는 Sprint 여유?에서 대부분 멈춘다는 것입니다.

Agent가 이 과정에 들어오면 흐름이 달라집니다.

Code Quality
     ↓
Finding
     ↓
Select
     ↓
Assign to Copilot
     ↓
Agent Fix
     ↓
Pull Request
     ↓
Human Review

즉 개발자의 시작점이

Issue

에서

Pull Request

쪽으로 이동합니다.

사람이 문제를 직접 수정하는 것이 아니라,

Agent가 만든 해결안을 검토하는 것부터 업무가 시작되는 구조입니다.

그렇다고 25개를 무조건 한꺼번에 넘기면 될까

여기서 실무적으로 중요한 부분이 있습니다.

25개를 처리할 수 있다고 해서 항상 25개를 한 번에 넘기는 것이 좋은 것은 아닙니다.

예를 들어 이런 두 묶음은 성격이 다릅니다.

Batch A

Expression has no effect
Redundant condition
Unused assignment

서로 비교적 독립적입니다.

반면

Batch B

Authentication
Session management
Database transaction
Concurrency

처럼 서로 다른 영역에 걸쳐 있는 finding은 하나의 PR로 묶으면 오히려 리뷰하기 어려워질 수 있습니다.

Agent가 많은 코드를 수정할수록 중요한 것은 결국 Reviewability입니다.

따라서 실제 팀에서는 finding을

Rule
Module
Feature
Risk

단위로 묶는 방식이 더 현실적일 수 있습니다.

예를 들어

Networking 관련 12개

또는

동일한 CodeQL Rule 20개

처럼 만드는 방식입니다.

AI가 많은 코드를 수정할 수 있게 될수록 PR을 작게 유지하는 원칙은 오히려 더 중요해질 수 있습니다.

이제 사람의 역할은 Fix보다 Policy 쪽으로 이동한다

Agentic Autofix가 흥미로운 이유는 단순히 개발 시간을 줄여주기 때문만은 아닙니다.

개발자의 역할이 조금 달라지기 때문입니다.

기존에는

Developer

Finding 확인
코드 분석
수정
테스트
PR 작성

을 했다면 Agent가 들어온 뒤에는

Agent

코드 분석
수정
검증
PR 작성

을 맡을 수 있습니다.

그렇다면 Developer가 더 많이 봐야 하는 것은 이런 부분입니다.

이 finding은 실제 문제인가?

이 수정 범위가 적절한가?

Architecture를 훼손하지 않았는가?

테스트가 충분한가?

이 PR을 Merge해도 되는가?

즉

Implementation

비중이 줄고

Review + Policy

비중이 올라갑니다.

Quality Gate가 더 중요해지는 이유

Agent가 많은 코드를 자동으로 수정하는 환경에서는 CI가 더욱 중요해집니다.

사람이 직접 작성한 코드라면 개발자가 어느 정도 변경 의도를 알고 있습니다.

하지만 Agent가 만든 PR은 다릅니다.

따라서 Merge 조건을 더 명확하게 만들어야 합니다.

Agent PR
   ↓
Build
   ↓
Unit Test
   ↓
Integration Test
   ↓
CodeQL
   ↓
Code Coverage
   ↓
Review
   ↓
Merge

앞으로 좋은 Agent Workflow를 만드는 핵심은 Agent에게

“코드를 잘 만들어.”

라고 하는 것이 아니라

“이 조건을 통과해야 작업이 완료된 것이다.”

라고 정의하는 데 있을 가능성이 큽니다.

AI Coding에서도 결국 중요한 것은 Done의 정의입니다.

Agent가 기술부채를 만들고 Agent가 기술부채를 갚는 구조

여기서 조금 재미있는 상황도 생깁니다.

AI Coding Agent가 빠르게 코드를 생성하면서 개발 속도가 올라가고 있습니다.

하지만 코드 생산량이 늘어나면 Quality Issue도 같이 증가할 가능성이 있습니다.

AI Code Generation ↑
        ↓
Code Volume ↑
        ↓
Quality Finding ↑

그러면 다시 AI가 이를 수정합니다.

AI가 코드 생성
      ↓
Code Quality 분석
      ↓
Finding 발생
      ↓
AI Agent가 수정

결국 이런 Loop가 만들어질 수 있습니다.

          ┌─────────────┐
          │ Coding Agent│
          └──────┬──────┘
                 ↓
               Code
                 ↓
        ┌────────────────┐
        │ Quality Analysis│
        └───────┬────────┘
                ↓
             Finding
                ↓
        ┌────────────────┐
        │ Remediation Agent│
        └───────┬────────┘
                ↓
               PR

그래서 앞으로 중요한 것은 AI가 코드를 얼마나 많이 작성하는지가 아닐 수 있습니다.

AI가 생성한 코드를 어떤 시스템으로 통제하느냐가 더 중요해집니다.

지금 당장 모든 프로젝트에서 쓸 수 있는 것은 아니다

이번 기능에는 몇 가지 조건이 있습니다.

GitHub Code Quality가 활성화된 Repository에서 사용할 수 있고, 현재 GitHub Team과 GitHub Enterprise Cloud 환경을 대상으로 제공됩니다.

또 Agentic Autofix로 Copilot에게 작업을 할당하면 AI Credit을 사용합니다.

현재 Code Quality backlog의 Agentic Autofix는 Public Preview이기 때문에 Workflow나 세부 동작은 이후 변경될 가능성도 있습니다.

따라서 당장 기존 정적 분석 시스템을 전부 대체한다고 보기보다는,

GitHub가 Code Quality와 Copilot Agent를 어떤 방향으로 결합하려는지 보여주는 기능

으로 보는 편이 맞습니다.

SonarQube 같은 기존 품질 도구가 없어지는 것은 아니다

이 기능을 보고

이제 SonarQube나 기존 정적 분석이 필요 없어지는 건가?

라고 생각할 수도 있습니다.

하지만 역할은 다릅니다.

정적 분석기의 역할은 계속 중요합니다.

Analyzer
    ↓
Problem Detection

Agent가 담당하는 것은 그다음입니다.

Problem
   ↓
Remediation

즉 경쟁 관계보다는 이런 구조에 가깝습니다.

Static Analysis
CodeQL
Quality Rule
      ↓
   Finding
      ↓
AI Remediation Agent
      ↓
 Pull Request

앞으로 중요한 변화는 Detection의 자동화보다 Remediation의 자동화일 가능성이 큽니다.

기술부채도 이제 사람이 직접 잡으러 다니지 않는다

지금까지 AI Coding 도구는 대부분 새 코드를 만드는 곳에 집중했습니다.

Feature 생성
Test 생성
Refactoring
Documentation

하지만 실제 프로젝트에서는 새 코드를 만드는 것만큼 오래된 코드를 관리하는 일이 중요합니다.

이번 Agentic Autofix는 AI Agent의 역할이

Create Code

에서

Maintain Code

로 확장되고 있다는 점에서 의미가 있습니다.

그리고 이 변화가 계속된다면 기술부채 관리도 지금과 상당히 다른 모습이 될 수 있습니다.

예전에는 backlog를 열고 개발자가 하나씩 가져갔습니다.

앞으로는

25 Findings 선택
        ↓
Assign to Copilot
        ↓
잠시 후 Pull Request

가 자연스러운 Workflow가 될 수도 있습니다.

그때 개발자가 해야 할 일은 코드를 한 줄씩 수정하는 것보다,

어떤 작업을 Agent에게 맡기고 어떤 기준을 통과해야 Merge할 것인지 결정하는 일에 더 가까워질 겁니다.

결국 Agentic Autofix에서 눈여겨볼 부분은 25개를 한꺼번에 고쳐준다는 기능 자체가 아닙니다.

더 큰 변화는 이것입니다.

기술부채가 개발자의 작업 목록에서 Agent의 작업 큐로 이동하기 시작했다.

AI Coding Agent가 코드 생성을 넘어 유지보수 영역까지 들어오기 시작했다는 신호로 볼 만합니다.

참고자료

GitHub Changelog — Remediate Code Quality findings with agentic autofix
2026년 9월 9일 공개된 Agentic Autofix 공식 발표입니다. Code Quality에서 최대 25개의 finding을 한 번에 Copilot에 할당하고, 별도 branch에서 수정·검증한 뒤 Pull Request를 생성하는 전체 흐름을 확인할 수 있습니다.
GitHub Agentic Autofix 공식 발표
GitHub Docs — Code Quality
Code Quality finding과 remediation workflow, Copilot을 이용한 수정 흐름을 확인할 수 있습니다.
GitHub Code Quality 공식 문서
GitHub Docs — Autofix for Code Scanning
Code Scanning Alert에서 Copilot Autofix와 Agentic Autofix가 어떻게 동작하는지 확인할 수 있습니다.
GitHub Code Scanning Autofix 공식 문서

공식 자료 기준으로 보면, 이번 변화의 핵심은 단순히 AI가 수정 코드를 추천하는 것이 아니라 finding 자체를 Copilot Agent의 작업으로 넘길 수 있게 됐다는 점입니다.

Code Quality에서는 최대 25개의 finding을 하나의 작업으로 묶어 Copilot에 할당할 수 있고, Agent가 별도 branch에서 수정과 검증을 수행한 뒤 사람이 검토할 Pull Request를 생성합니다.

기술부채 관리도 점점

Finding
   ↓
Developer Fix

에서

Finding
   ↓
Agent Remediation
   ↓
Pull Request
   ↓
Human Review

구조로 이동하고 있습니다.

따라서 실제 팀에서는 Agent에게 얼마나 많은 코드를 맡길 수 있는가보다 CI, Test, Review, Quality Gate를 어떻게 정의할 것인가가 더 중요해질 가능성이 큽니다.

Kotlin이 Swift 쪽으로 한 발 더 들어왔다

Sat, 12 Sep 2026 09:28:13 GMT

Kotlin이 Swift 쪽으로 한 발 더 들어왔다

Kotlin 2.4.20의 Swift Export, 그리고 iPhone Duo 시대의 KMP

Kotlin 2.4.20이 9월 7일 정식 출시됐습니다.

전체 변경사항을 보면 Standard Library, Kotlin/Wasm, Kotlin/JS, Gradle 등 여러 영역이 업데이트됐지만 iOS 개발자라면 Kotlin/Native 쪽 변화를 눈여겨볼 만합니다.

이번 버전에서 특히 볼 부분은 세 가지입니다.

Swift Export 기능 확대
SwiftPM 연동을 위한 Package.swift 생성 지원
Kotlin/Native Incremental Compilation 개선

각각만 보면 작은 개선처럼 보일 수도 있습니다.

하지만 방향은 꽤 명확합니다.

기존 KMP의 iOS 연동은 대체로

Kotlin
   ↓
Kotlin/Native
   ↓
Objective-C Interop
   ↓
Swift

구조였습니다.

Kotlin 2.4.20에서 계속 진행되고 있는 방향은 이 중간 단계를 줄여

Kotlin
   ↓
Swift

에 더 가까운 개발 경험을 만드는 것입니다.

그리고 최근 발표된 iPhone Duo까지 같이 보면 이 변화가 더 흥미로워집니다.

앞으로 KMP에서 중요한 질문은 단순히

얼마나 많은 코드를 공유할 수 있는가?

가 아니라

어디까지 공유하는 것이 Apple 플랫폼 변화에 가장 자연스럽게 대응할 수 있는가?

가 될 가능성이 높습니다.

KMP에서 항상 애매했던 iOS 쪽 경계

Kotlin Multiplatform을 사용하는 가장 현실적인 방식은 UI 전체를 공유하는 것보다 비즈니스 로직을 공유하는 구조입니다.

예를 들면 이런 형태입니다.

Android
   │
   ├─ Compose
   │
   └─────────┐
             │
        Shared KMP
             │
   ┌─────────┘
   │
iOS
   │
   └─ SwiftUI

공유 영역에는 보통

Network
Repository
Domain
Validation
Business Logic

이 들어갑니다.

iOS UI는 SwiftUI,

Android UI는 Compose로 만드는 방식입니다.

구조 자체는 상당히 자연스럽습니다.

문제는 Shared Module이 Swift와 만나는 지점이었습니다.

Kotlin/Native는 오랫동안 Objective-C compatibility를 기반으로 Swift에 API를 노출했습니다.

그래서 Kotlin에서는 자연스러운 타입도 Swift에 넘어오는 순간 조금 다른 모습이 됩니다.

대표적으로

Package
Nullable
Generic
Coroutine
Flow
Sealed Class

같은 부분입니다.

결국 Shared Logic을 만들고도 iOS 쪽에 Adapter나 Wrapper가 다시 생기는 경우가 많았습니다.

Kotlin Model
     ↓
Interop
     ↓
Swift Adapter
     ↓
SwiftUI

KMP를 사용하면서도 iOS 개발자가 계속 Interop 구조를 의식해야 했던 이유입니다.

Swift Export가 줄이려는 것이 바로 이 경계다

Swift Export의 목표는 단순합니다.

Kotlin API를 Swift에서 보다 Swift다운 형태로 사용할 수 있게 만드는 것.

기존 구조가

Kotlin
 ↓
Objective-C
 ↓
Swift

였다면,

Swift Export는

Kotlin
 ↓
Swift Module
 ↓
Swift

에 가까운 구조를 만듭니다.

Kotlin package 구조도 더 자연스럽게 Swift 쪽으로 전달할 수 있고, 여러 Kotlin Module을 각각 Swift Module 형태로 Export하는 것도 가능합니다.

예를 들어 KMP 프로젝트가

shared-domain
shared-network
shared-database

처럼 구성돼 있다면 Swift에서도 Module 경계를 더 명확하게 유지할 수 있습니다.

결국 목표는 하나입니다.

iOS 개발자가 KMP를 사용하면서 Kotlin/Native의 내부 사정을 최대한 덜 신경 쓰게 만드는 것.

2.4.20에서는 sealed class가 Swift에서 훨씬 자연스러워졌다

이번 버전에서 iOS 개발자가 체감하기 좋은 변화 중 하나가 sealed class와 sealed interface 지원입니다.

Kotlin에서는 상태를 표현할 때 sealed hierarchy를 자주 사용합니다.

sealed interface LoginState

data object Loading : LoginState

data class Success(
    val userName: String
) : LoginState

data class Failure(
    val message: String
) : LoginState

Kotlin에서는 when으로 모든 상태를 안전하게 처리할 수 있습니다.

when (state) {
    Loading -> showLoading()
    is Success -> showUser(state.userName)
    is Failure -> showError(state.message)
}

새로운 subtype이 추가되면 Compiler가 누락된 case를 알려줍니다.

Swift의 enum을 switch하는 것과 비슷합니다.

문제는 기존 Swift Interop이었습니다.

Swift에서는 Kotlin sealed hierarchy를 처리할 때 결국

default:
    break

같은 case를 넣어야 하는 경우가 있었습니다.

이렇게 되면 Kotlin에 새로운 상태가 추가돼도 Swift Compiler가 누락을 잡아주지 못할 수 있습니다.

이제 Swift에서도 exhaustive switch가 가능하다

Kotlin 2.4.20의 Swift Export에서는 sealed hierarchy를 Swift enum 형태로 연결할 수 있습니다.

sealedType()을 통해 Swift에서 exhaustive switch가 가능합니다.

예를 들어 Kotlin에

sealed interface Shape

class Circle : Shape
class Rectangle : Shape

가 있다면 Swift에서는 개념적으로 이런 식입니다.

switch shape.sealedType() {
case .circle(let circle):
    print(circle.value)

case .rectangle(let rectangle):
    print(rectangle.value)
}

default가 필요 없습니다.

Kotlin에 새로운 subtype이 추가되면 Swift Compiler도 처리되지 않은 case가 있다는 것을 알려줄 수 있습니다.

KMP에서 UI State를 공유한다면 꽤 의미가 큽니다.

예를 들어

Loading
Success
Empty
Failure
Expired

같은 상태를 Kotlin에서 정의하고 SwiftUI에서 그대로 처리하기가 훨씬 자연스러워집니다.

SwiftUI와 KMP 사이에 만들던 Adapter도 줄일 수 있다

기존 KMP + SwiftUI 프로젝트에서는 이런 구조가 자주 생깁니다.

Kotlin State
    ↓
Swift Adapter
    ↓
Swift Enum
    ↓
SwiftUI

Shared Logic을 만들었는데 iOS에서 다시 한번 Model 변환을 하는 셈입니다.

Swift Export가 발전하면 목표 구조는 훨씬 단순합니다.

Kotlin State
     ↓
Swift Export
     ↓
SwiftUI

실제 프로젝트에서 KMP 도입 비용을 높이는 것은 Kotlin 코드 자체보다 이런 Glue Code인 경우가 많습니다.

따라서 Swift Export 개선은 단순한 문법 편의보다 Architecture 관점에서 의미가 있습니다.

Swift가 Kotlin interface를 직접 구현할 수도 있다

2.4.20에서 또 하나 중요한 변화가 Cross-language inheritance입니다.

Kotlin에서 Contract를 정의하고 실제 구현을 Swift에서 제공할 수 있습니다.

예를 들어 Shared Module에서

interface SecureStorage {
    fun save(
        key: String,
        value: String
    )
}

라는 Interface를 정의했다고 해보겠습니다.

iOS에서는 실제 구현에 Keychain을 사용하고 싶습니다.

이 로직을 Kotlin으로 억지로 옮길 필요가 없습니다.

Swift가 구현하면 됩니다.

Shared Kotlin

SecureStorage
     ↑
     │
Swift Implementation
     │
  Keychain

CryptoKit처럼 Apple 전용 Framework를 사용하는 것도 같은 방식으로 생각할 수 있습니다.

이건 KMP Architecture에서 상당히 중요한 변화입니다.

KMP라고 해서 모든 코드를 공유할 필요는 없다

KMP를 처음 적용할 때 흔히 나오는 고민이 있습니다.

어디까지 Kotlin으로 만들 것인가?

공유할 수 있다는 이유로 모든 영역을 Shared Module로 올릴 필요는 없습니다.

예를 들어

Keychain
CryptoKit
LocalAuthentication
AVFoundation
HealthKit
StoreKit

같은 기능은 Apple Framework를 Native에서 직접 사용하는 편이 더 자연스러운 경우가 많습니다.

Shared Module에서는 Contract만 정의합니다.

Shared Kotlin

AuthenticationProvider
SecureStorage
CryptoProvider

그리고 각 플랫폼에서 구현합니다.

Android
 └─ Android implementation

iOS
 └─ Swift implementation

Cross-language inheritance가 좋아질수록 이런 구조의 비용이 줄어듭니다.

KMP의 방향도

모든 것을 Kotlin으로 만든다

보다

공유할 가치가 있는 것만 Kotlin으로 만든다

쪽이 더 현실적입니다.

SwiftPM 연결도 계속 자연스러워지고 있다

iOS 개발자 입장에서 또 중요한 부분이 Swift Package Manager입니다.

KMP Library를 iOS에서 사용하려면 일반적으로 XCFramework를 사용합니다.

Kotlin
   ↓
Kotlin/Native
   ↓
XCFramework
   ↓
iOS

SwiftPM으로 배포한다면 Package.swift 관리가 추가됩니다.

특히 해당 XCFramework가 다른 Swift Package에 의존하면 배포 과정이 더 복잡해집니다.

Kotlin 2.4.20에서는 SwiftPM dependency가 있는 XCFramework를 만들 때 assembleSharedXCFramework 작업이 필요한 Package.swift 파일을 자동 생성할 수 있게 됐습니다.

KMP
 ↓
Gradle
 ↓
XCFramework
 +
Package.swift
 ↓
SwiftPM
 ↓
Xcode

여기서 주의할 점도 있습니다.

모든 KMP 프로젝트에서 Package.swift가 자동으로 만들어진다는 의미는 아닙니다.

이번 기능은 특히 SwiftPM dependency가 포함된 XCFramework를 Swift Package 형태로 배포하는 과정을 단순화하는 변화입니다.

Native Build도 계속 줄이려 한다

KMP 프로젝트에서 실제 개발 경험을 좌우하는 부분 중 하나가 Build Time입니다.

순수 iOS 프로젝트와 다르게

Gradle
+
Kotlin Compiler
+
Kotlin/Native
+
Xcode

가 함께 움직입니다.

Shared Module이 커지면 Kotlin/Native Compile Time도 체감됩니다.

2.4.20에서는 .klib artifact를 대상으로 한 Incremental Compilation도 개선됐습니다.

현재는 Beta 기능이며

kotlin.incremental.native=true

를 통해 사용할 수 있습니다.

목표는 단순합니다.

작은 코드 변경
       ↓
Native 전체 재빌드

가 아니라

작은 코드 변경
       ↓
변경된 부분 중심 Compile

로 가는 것입니다.

Interop이 아무리 좋아져도 Build가 느리면 실제 개발 경험은 좋기 어렵습니다.

JetBrains가 Swift Export와 Native Build를 동시에 개선하고 있는 이유입니다.

그런데 iPhone Duo가 나오면서 새로운 질문이 생겼다

여기까지는 Kotlin 2.4.20 자체의 이야기입니다.

그런데 최근 발표된 iPhone Duo를 같이 보면 KMP UI 전략에도 재미있는 문제가 하나 생깁니다.

Apple은 Duo의 접힌 화면과 펼쳐진 내부 화면에서 표준 Navigation Container가 자동으로 적응하도록 설계했습니다.

대표적으로

TabView
NavigationSplitView

UITabBarController
UISplitViewController

입니다.

접힌 상태에서는 Compact한 Navigation으로 동작하고,

내부의 넓은 화면에서는 Sidebar나 Split 구조를 사용할 수 있습니다.

즉 같은 iPhone 앱이

Compact
   ↓
Tab Bar

에서

Expanded
   ↓
Sidebar

로 바뀔 수 있습니다.

여기서 KMP를 사용하는 앱도 UI를 어떻게 구성했느냐에 따라 차이가 생깁니다.

KMP + SwiftUI라면 사실 큰 문제가 없다

KMP로 비즈니스 로직만 공유하고 UI를 SwiftUI로 만든 앱이라면 Duo 대응 때문에 KMP 자체를 크게 걱정할 이유는 없습니다.

구조가 이런 식이기 때문입니다.

┌────────────────────────────┐
│            iOS             │
│                            │
│ SwiftUI                    │
│ TabView                    │
│ NavigationSplitView        │
│ Native Sidebar             │
│ Safe Area                  │
│ iPhone Duo Adaptivity      │
└─────────────┬──────────────┘
              │
         Swift Export
              │
┌─────────────▼──────────────┐
│         Shared KMP         │
│                            │
│ Domain                     │
│ Repository                 │
│ Network                    │
│ Validation                 │
│ Business Logic             │
└────────────────────────────┘

iOS Navigation은 Apple Framework가 담당합니다.

따라서 Apple이 새로운 Sidebar나 Window Adaptivity를 추가하면 SwiftUI 쪽에서 대응하면 됩니다.

KMP는 그 아래의 Business Logic을 계속 제공합니다.

이 구조에서는 KMP가 오히려 거의 보이지 않습니다.

꼭 SwiftUI여야 하는 것도 아닙니다.

UIKit에서도

UITabBarController
UINavigationController
UISplitViewController

같은 시스템 Navigation을 사용한다면 Apple이 제공하는 Adaptivity를 활용할 수 있습니다.

Compose Multiplatform 화면을 사용하더라도 ComposeUIViewController를 Native Navigation 아래에 넣는 구조가 가능합니다.

예를 들면

UITabBarController
        ↓
UINavigationController
        ↓
ComposeUIViewController
        ↓
Compose Screen

입니다.

JetBrains 공식 가이드에서도 이와 비슷하게 SwiftUI 또는 UIKit이 Navigation을 담당하고 Compose는 Screen Content를 그리는 Hybrid 구조를 안내하고 있습니다.

즉 중요한 것은

SwiftUI인가?
Compose인가?

만이 아닙니다.

더 중요한 것은

누가 Navigation을 소유하고 있느냐입니다.

iPhone Duo에서 더 신경 써야 할 쪽은 KMP가 아니라 오히려 이런 코드입니다.

Custom Tab Bar
Custom Navigation Bar
Custom Sidebar
Fixed Width Layout
Orientation 기반 Layout
UIScreen.main 기반 계산

예를 들어 SwiftUI에서 시스템 TabView 대신 이런 식으로 Tab Bar를 직접 만들었다고 해보겠습니다.

ZStack(alignment: .bottom) {
    content

    CustomTabBar()
        .frame(height: 64)
}

여기에

let width = UIScreen.main.bounds.width

같은 계산까지 들어가 있다면 Duo에서는 확인해야 할 부분이 많아집니다.

Apple의 표준 Navigation은 Duo에서

접힘
펼침
Sidebar
Split
Safe Area
Camera 영역

등을 시스템이 알고 처리합니다.

Custom Navigation은 그 정보를 직접 반영해야 합니다.

Duo에서는 Safe Area조차 좌우가 같다는 보장이 없다

이 부분도 중요합니다.

Apple은 iPhone Duo에서 Safe Area와 Layout Margin이 비대칭일 수 있다고 안내하고 있습니다.

따라서 이런 가정도 위험해집니다.

left inset == right inset

Custom Tab Bar나 Custom Navigation Bar에서 Safe Area를 직접 계산했다면 반드시 다시 확인해야 합니다.

특히

UIScreen.main.bounds

처럼 Main Screen을 직접 참조하는 방식도 Duo 같은 Multi-display Device에서는 모호해집니다.

Apple은 Layout 판단에

Environment
Trait Collection
Scene Bounds
Size Class

를 사용하는 방향을 권장하고 있습니다.

Orientation 기준 Layout도 다시 봐야 한다

오래된 iOS 앱에는 이런 코드도 많습니다.

if orientation.isLandscape {
    showExpandedLayout()
}

하지만 Duo 내부 Display에서는 기존 Orientation 가정을 그대로 사용할 수 없습니다.

따라서

Portrait
Landscape

보다

Compact
Regular
Available Width
Scene Bounds

를 기준으로 Layout을 판단하는 것이 중요해집니다.

이 문제 역시 KMP와 직접적인 관계가 없습니다.

Swift로 만들었더라도 Custom Layout을 오래된 방식으로 구성했다면 똑같이 문제가 됩니다.

Compose Multiplatform으로 UI 전체를 공유했다면?

여기에서는 조금 이야기가 달라집니다.

Compose Multiplatform 자체도 Adaptive Layout을 지원합니다.

WindowSizeClass나 Material 3 Adaptive API 등을 활용해서

Compact
Medium
Expanded

환경에 따라 다른 Layout을 만들 수 있습니다.

따라서

Duo 외부 화면

Bottom Navigation

Duo 내부 화면

Navigation Rail
또는
Sidebar 형태 UI

를 직접 구현하는 것은 가능합니다.

문제는 이게 Apple의 Native Sidebar와 동일한 것은 아니라는 점입니다.

Compose에서 직접 만든 Sidebar는 Compose Component입니다.

Apple의

TabView
NavigationSplitView
UITabBarController
UISplitViewController

가 제공하는 시스템 Navigation과는 다릅니다.

이미 Liquid Glass에서 같은 문제가 한번 드러났다

이 부분은 Duo만의 새로운 문제가 아닙니다.

iOS 26의 Liquid Glass에서도 같은 일이 있었습니다.

Compose Multiplatform으로 Tab Bar와 Navigation 전체를 직접 그리면 Apple의 Native Tab Bar에 자동으로 적용되는 Liquid Glass 효과를 그대로 받을 수 없습니다.

그래서 JetBrains 공식 가이드에서도 한 가지 현실적인 Architecture를 제시합니다.

SwiftUI

TabView
NavigationStack
      ↓
Compose
Screen Content

즉 Navigation은 Apple의 Native Component가 담당하고,

화면 Content는 Compose가 담당하는 방식입니다.

UIKit에서도 같은 구조가 가능합니다.

UITabBarController
UINavigationController
        ↓
ComposeUIViewController

Liquid Glass에서 나온 이 문제가 iPhone Duo에서도 똑같은 Architecture 질문으로 이어집니다.

Duo에서는 이 차이가 더 커질 수 있다

Liquid Glass는 주로 Visual Style의 문제였습니다.

하지만 Duo는 조금 다릅니다.

이번에는 Navigation 구조 자체가 바뀝니다.

Compact
   ↓
Tab Bar

에서

Expanded
   ↓
Sidebar
   ↓
Split Content

로 전환될 수 있습니다.

시스템 Navigation을 사용하면 이 변화에 Apple Framework가 적극적으로 참여합니다.

반면 Custom Navigation이나 Compose에서 직접 만든 Navigation이라면 이 Adaptive Behavior를 직접 구현해야 합니다.

그래서 앞으로 KMP UI를 설계할 때도 질문이 달라집니다.

Compose로 만들 수 있는가?

보다

Compose로 직접 만들어야 하는가?

가 더 중요해집니다.

결국 KMP보다 Custom UI가 더 큰 변수다

정리하면 iPhone Duo 대응에서 문제를 단순히

Native SwiftUI = 안전

KMP = 위험

으로 볼 수는 없습니다.

실제로는 이렇게 보는 편이 더 정확합니다.

KMP + SwiftUI Navigation
        ↓
대응 수월

KMP + UIKit System Navigation
        ↓
대응 수월

Compose Content
+ Native Navigation
        ↓
대응 수월

반면

Swift + Custom Tab Bar
        ↓
직접 대응 필요

Compose + Custom Navigation
        ↓
직접 대응 필요

UIScreen / Orientation
기반 Layout
        ↓
직접 대응 필요

입니다.

즉 문제의 기준은 언어가 아닙니다.

얼마나 시스템 UI와 Navigation을 활용하고 있는가가 더 중요합니다.

Swift Export가 좋아지는 것이 여기에서도 의미가 있다

이 지점에서 다시 Kotlin 2.4.20의 Swift Export로 돌아오면 이야기가 연결됩니다.

Swift Export가 좋아질수록

Business Logic
     ↓
Kotlin

과

Platform UI
     ↓
SwiftUI / UIKit

를 분리하는 비용이 낮아집니다.

예전에는 이 경계에서 Objective-C Interop과 Wrapper Code가 많이 필요했습니다.

그 비용이 줄어든다면 굳이 Apple 플랫폼 UI까지 Kotlin으로 공유할 이유도 줄어들 수 있습니다.

Shared

Domain
Repository
Network
Business Logic

──────────────

Native iOS

Tab Bar
Sidebar
Navigation
Safe Area
Liquid Glass
Duo Adaptivity

이런 구조가 더 매력적으로 보이는 이유입니다.

그렇다고 Compose UI 공유가 의미 없다는 것은 아니다

Compose Multiplatform UI를 공유하는 것도 분명 장점이 있습니다.

화면이 많은 앱에서 Android와 iOS UI를 동시에 개발해야 한다면 공유 효과가 큽니다.

다만 플랫폼 변화가 빠르게 들어오는 영역은 판단이 필요합니다.

대표적으로

Navigation
System Bar
Window Behavior
Platform Animation
Safe Area
New Form Factor

같은 부분입니다.

이 영역까지 Custom UI로 가져가면 공유 코드는 늘어납니다.

대신 Apple의 새로운 UI 변화에 대응해야 하는 책임도 App 쪽으로 넘어옵니다.

따라서 좋은 KMP Architecture는 공유율 자체를 최대화하는 것이 아니라

공유했을 때 이득이 큰 영역과 Native로 남겼을 때 이득이 큰 영역을 구분하는 것

에 가깝습니다.

Kotlin 2.4.20과 iPhone Duo를 같이 보면 이런 구조가 보인다

앞으로 상당히 현실적인 KMP Architecture는 이런 형태일 수 있습니다.

┌───────────────────────────────┐
│             iOS               │
│                               │
│ SwiftUI / UIKit               │
│                               │
│ TabView / UITabBarController  │
│ Sidebar                       │
│ NavigationSplitView           │
│ Safe Area                     │
│ Liquid Glass                  │
│ iPhone Duo                    │
└───────────────┬───────────────┘
                │
          Swift Export
                │
┌───────────────▼───────────────┐
│          Shared KMP           │
│                               │
│ Domain                        │
│ Repository                    │
│ Network                       │
│ Validation                    │
│ Business Rules                │
└───────────────┬───────────────┘
                │
┌───────────────▼───────────────┐
│           Android             │
│                               │
│ Compose                       │
└───────────────────────────────┘

여기서 중요한 것은 SwiftUI를 많이 사용한다는 것이 아닙니다.

플랫폼의 책임과 Shared Logic의 책임을 명확하게 나눈다는 것입니다.

Swift Export는 아직 Alpha다

물론 지금 바로 모든 KMP 프로젝트를 이 구조로 바꿔야 한다는 의미는 아닙니다.

Swift Export는 여전히 Alpha 단계입니다.

현재도 몇 가지 제한이 있습니다.

일부 Kotlin 타입 Export 제한
Generic Type Parameter의 Type Erasure
기존 Objective-C Interop 프로젝트 자동 Migration 부재
일부 기능에 별도 설정 필요
API와 동작이 변경될 가능성

따라서 Production Project에서는 전면 전환보다는 작은 Module부터 검증하는 방식이 현실적입니다.

다만 JetBrains가

Swift Export
SwiftPM
Cross-language inheritance
Incremental Compilation

을 계속 동시에 개선하고 있다는 것은 방향을 보여줍니다.

iOS 개발자가 KMP를 볼 때 질문도 달라져야 한다

예전에는 KMP를 검토할 때 주로 이런 질문을 했습니다.

몇 %까지 코드를 공유할 수 있는가?

하지만 앞으로는 이 질문이 더 중요할 수 있습니다.

어떤 코드를 공유해야
두 플랫폼 모두 자연스러운가?

예를 들어

Domain
Repository
API
Validation
Business Rule

은 공유 효과가 큽니다.

반면

Tab Bar
Navigation
Sidebar
Safe Area
Platform Interaction

은 플랫폼 변화의 영향을 직접 받습니다.

iPhone Duo처럼 새로운 Form Factor가 등장할수록 이 차이는 더 분명해집니다.

마치며

Kotlin 2.4.20의 Swift Export는 겉으로 보면 KMP의 Interop 개선입니다.

하지만 조금 넓게 보면 더 흥미로운 방향이 보입니다.

KMP가 iOS UI를 더 많이 가져가는 것이 아니라,

Kotlin과 Swift가 서로 잘하는 영역을 유지하면서 경계를 더 얇게 만드는 방향입니다.

그리고 iPhone Duo는 이 Architecture가 왜 중요한지를 보여주는 좋은 사례가 됐습니다.

Duo 대응에서 가장 걱정해야 할 것은 KMP 자체가 아닙니다.

오히려

Custom Tab Bar
Custom Navigation
UIScreen.main
Orientation 분기
고정 Width
Safe Area 수동 계산

같은 오래된 UI 코드가 더 큰 변수입니다.

Apple의 시스템 TabView, NavigationSplitView, UITabBarController, UISplitViewController를 사용하고 있다면 새로운 화면 형태와 Sidebar에 대응하기가 훨씬 수월합니다.

KMP 역시 마찬가지입니다.

Business Logic은 Kotlin으로 공유하고,

Navigation과 Apple 고유 UI는 SwiftUI나 UIKit에 맡길 수 있습니다.

Compose를 사용하더라도 Native Navigation 안에 Compose Screen을 넣는 Hybrid 구조가 가능합니다.

결국 Kotlin 2.4.20과 iPhone Duo를 같이 보면 하나의 결론으로 이어집니다.

KMP의 경쟁력은 UI까지 얼마나 많이 공유하느냐보다, 공유할 가치가 있는 로직을 얼마나 자연스럽게 Swift에 전달할 수 있느냐에 있다.

Swift Export가 발전하는 이유도 결국 그 경계를 줄이기 위해서입니다.

그리고 새로운 Apple Hardware가 등장할수록,

공유 코드와 플랫폼 코드의 경계를 어디에 둘 것인가

라는 질문은 더 중요해질 것 같습니다.

참고자료

Kotlin Documentation — What's new in Kotlin 2.4.20
Swift Export의 sealed class/interface 지원, cross-language inheritance, SwiftPM dependency용 Package.swift 생성, Kotlin/Native Incremental Compilation 개선을 확인할 수 있습니다.
Kotlin 2.4.20 공식 변경사항
Kotlin Documentation — Interoperability with Swift using Swift Export
Swift Export의 현재 지원 범위와 Alpha 상태, multi-module, package preservation 등 Swift와 Kotlin 사이의 새로운 Interop 방향을 확인할 수 있습니다.
Kotlin Swift Export 공식 문서
Kotlin Documentation — SwiftPM Export
Kotlin Multiplatform에서 XCFramework와 Swift Package Manager를 연결하는 방식을 확인할 수 있습니다.
Kotlin SwiftPM 공식 문서
Apple Developer — Prepare your app for iPhone Duo
iPhone Duo 내부 화면의 Size Class, Sidebar, Adaptive Layout, Safe Area와 시스템 Navigation의 동작을 확인할 수 있습니다.
Apple iPhone Duo 대응 공식 Tech Talk

공식 자료 기준으로 보면, Kotlin 2.4.20의 Swift Export는 Kotlin과 Swift 사이에서 필요했던 Objective-C 기반 Interop을 점점 줄이는 방향으로 발전하고 있습니다.

이번 버전에서는 sealed hierarchy를 Swift에서 더 자연스럽게 처리할 수 있고, Swift에서 Kotlin Interface를 구현하는 cross-language inheritance도 추가됐습니다. SwiftPM dependency가 포함된 XCFramework 배포 과정도 조금 더 단순해졌습니다.

다만 Swift Export 자체는 아직 Alpha이므로 기존 Production 프로젝트를 바로 전면 전환하기보다는 작은 Module부터 검증하는 방식이 현실적입니다.

iPhone Duo까지 연결해서 보면 더 중요한 기준은 KMP 자체가 아닙니다.

Shared KMP
Domain / Repository / Network
        ↓
Swift Export
        ↓
SwiftUI / UIKit
        ↓
TabView
NavigationSplitView
Sidebar
        ↓
iPhone Duo

이 구조라면 Apple의 새로운 Navigation과 Adaptive Layout을 그대로 활용할 수 있습니다.

반대로 KMP 여부와 관계없이 Custom Tab Bar, Custom Navigation, 고정 Width, UIScreen.main, Orientation 기반 Layout을 많이 사용했다면 Duo 대응을 직접 해야 하는 영역이 늘어납니다.

따라서 KMP의 현실적인 방향은 Business Logic은 공유하고 Apple 플랫폼의 Navigation과 System UI는 Native Framework에 맡기는 구조로 보는 것이 자연스럽습니다.

iOS 27.1 커스텀 탭바를 당장 버릴 필요는 없다

Sat, 12 Sep 2026 09:22:36 GMT

iOS 27.1 커스텀 탭바를 당장 버릴 필요는 없다

iPhone Duo가 공개되면서 오래 운영한 iOS 프로젝트라면 한 번쯤 확인해야 할 코드가 생겼습니다.

대표적인 것이 이런 UI입니다.

Custom Tab Bar
Custom Navigation Bar
Custom Toolbar
UIScreen.main 기반 레이아웃
Orientation 기반 분기
고정 Width / Height
Safe Area 직접 계산

최근 SwiftUI 프로젝트라면 TabView, NavigationStack, NavigationSplitView를 사용하는 경우가 많아 상대적으로 대응이 쉽습니다.

반면 몇 년 이상 운영한 UIKit 프로젝트나 디자인 요구가 강했던 앱에서는 Tab Bar와 Navigation Bar를 직접 만든 경우가 적지 않습니다.

예를 들면 이런 구조입니다.

final class MainViewController: UIViewController {

    private let contentView = UIView()
    private let customTabBar = CustomTabBar()

    override func viewDidLoad() {
        super.viewDidLoad()

        view.addSubview(contentView)
        view.addSubview(customTabBar)
    }
}

SwiftUI에서도 마찬가지입니다.

ZStack(alignment: .bottom) {
    currentContent

    CustomTabBar()
        .frame(height: 64)
}

이 코드들이 iOS 27.1에서 갑자기 사용할 수 없게 되는 것은 아닙니다.

커스텀 Tab Bar와 Navigation은 여전히 사용할 수 있습니다.

다만 iPhone Duo가 들어오면서 한 가지 차이가 커졌습니다.

시스템 Navigation을 사용하면 Apple이 새로운 화면 형태에 맞춰 상당 부분을 처리해주지만,

Custom Navigation은 그 책임이 앱으로 넘어옵니다.

먼저 결론부터 보면

앞으로의 대응은 크게 세 가지로 나눌 수 있습니다.

현재

Custom Tab / Navigation
        ↓

1단계
Custom UI 유지
+ Safe Area
+ Reserved Region
+ Adaptive Layout
        ↓

2단계
Navigation State와
UI 표현 분리
        ↓

3단계
UITabBarController / TabView
NavigationSplitView
System Toolbar
        ↓

Duo / Sidebar / Vertical Bar
자동 대응 범위 확대

즉 오래된 프로젝트를 한 번에 전부 다시 만들 필요는 없습니다.

Custom UI를 먼저 안전하게 만든 뒤, Navigation Container부터 단계적으로 시스템 쪽으로 이동하는 방식이 현실적입니다.

기존 iPhone은 화면 형태가 비교적 예측 가능했습니다.

물론 기기 크기는 계속 달라졌지만 기본적인 구조는 비슷했습니다.

┌──────────────────┐
│ Navigation Bar   │
│                  │
│                  │
│     Content      │
│                  │
│                  │
│ Tab Bar          │
└──────────────────┘

그래서 앱에서 Tab Bar를 직접 그려도 큰 문제가 없었습니다.

하지만 Duo에서는 화면이 펼쳐지면 이야기가 달라집니다.

Closed

┌──────────────┐
│              │
│   Content    │
│              │
│              │
│   Tab Bar    │
└──────────────┘

펼친 내부 화면에서는 사용 가능한 공간 자체가 크게 달라집니다.

Opened

┌───────────┬────────────────────┐
│           │                    │
│ Sidebar   │      Content       │
│           │                    │
│           │                    │
└───────────┴────────────────────┘

여기에 화면의 pose와 방향에 따라 System Bar가 아래쪽이 아니라 옆으로 이동할 수도 있습니다.

Apple은 Duo에서 Navigation, Toolbar, Tab Bar를 Vertical Axis로 배치할 수 있도록 시스템 UI를 바꿨습니다.

이제 화면 아래에 있던 컨트롤이 옆으로 이동할 수 있습니다.

기존

Navigation
────────────

Content

────────────
Tab Bar

에서

Duo

┌────┬───────────────────────┐
│Nav │                       │
│    │                       │
│Tool│       Content         │
│    │                       │
│Tab │                       │
└────┴───────────────────────┘

같은 형태가 가능해집니다.

시스템 Navigation을 사용한다면 이 이동을 Framework가 처리합니다.

하지만 직접 만든 Tab Bar라면 시스템이 그 내부 구조를 알지 못합니다.

Custom UITabBar를 만들었다고 시스템 Tab Bar가 되는 것은 아니다

UIKit에서 특히 주의할 부분입니다.

예를 들어 직접

let tabBar = UITabBar()

를 만들었다고 해서 Duo의 새로운 Adaptive Navigation이 자동 적용되는 것은 아닙니다.

Apple은 Duo의 Vertical Bar 대응에서 UINavigationController와 UITabBarController 같은 Navigation Container가 관리하는 Bar를 사용할 것을 권장하고 있습니다.

즉

UITabBar
UINavigationBar
UIToolbar

인스턴스를 직접 배치한 것과

UITabBarController
UINavigationController

가 관리하는 Bar는 다르게 봐야 합니다.

전자는 Custom UI에 가깝습니다.

후자는 시스템 Navigation 구조입니다.

그렇다고 Custom Tab Bar를 바로 없앨 필요는 없다

오래된 앱에서 Tab Bar를 시스템 Tab Bar로 교체하는 것은 생각보다 큰 작업일 수 있습니다.

커스텀 Tab Bar 안에

Animation
Badge
Floating Button
Custom Transition
Analytics
Deep Link
Selection State
Authentication Check
Special Gesture

같은 로직이 들어가 있기 때문입니다.

그래서 첫 단계는 교체가 아니라 Custom UI를 Adaptive하게 만드는 것입니다.

iOS 27.1에서는 이 작업을 위한 새로운 개념이 추가됐습니다.

Reserved Region

SwiftUI에서는 ReservedRegion,

UIKit에서는 UIViewReservedRegion을 사용할 수 있습니다.

Reserved Region은 쉽게 말하면

이 영역에는 앱의 Custom UI가 있으니 시스템 UI와 충돌하지 않도록 서로 공간을 조정하자.

라는 정보를 Layout System에 전달하는 방식입니다.

특히

Custom Tab Bar
Custom Floating Controls
Edge-to-edge UI
Custom Navigation

같은 화면에서 유용합니다.

예전에는 직접

Safe Area
+
Magic Number
+
Tab Bar Height
+
Device별 보정값

을 계산했다면,

iOS 27.1에서는 시스템이 알고 있는 Reserved Region 정보를 이용할 수 있습니다.

Custom UI를 당장 제거하기 어려운 앱이라면 첫 번째 마이그레이션 포인트가 여기입니다.

Safe Area 계산부터 다시 확인해야 한다

Duo에서 가장 쉽게 문제가 생길 수 있는 코드 중 하나가 이겁니다.

let width =
    view.bounds.width
    - view.safeAreaInsets.left * 2

이 코드는 암묵적으로

left == right

라고 가정하고 있습니다.

기존 iPhone에서는 우연히 잘 동작했을 수 있습니다.

Duo에서는 Safe Area와 Layout Margin이 좌우 대칭이라는 보장이 없습니다.

따라서 이렇게 계산하는 편이 안전합니다.

let availableBounds =
    view.bounds.inset(by: view.safeAreaInsets)

let width = availableBounds.width

이 차이는 작아 보이지만 앞으로 중요합니다.

❌ left inset × 2

⭕ left / right 각각 사용

Duo에서는 Camera와 Vertical System Controls, Split View 상태 등에 따라 사용 가능한 영역이 달라질 수 있기 때문입니다.

UIScreen.main도 이제 정말 줄여야 한다

오래된 프로젝트를 검색하면 이런 코드가 상당히 많이 나옵니다.

UIScreen.main.bounds.width

UIScreen.main.bounds.height

UIScreen.main.scale

Duo는 Display가 하나라는 가정을 깨는 기기입니다.

Apple 역시 Two-display Device에서는 main screen이라는 개념이 모호해지기 때문에 화면 정보를 Layout 판단에 직접 사용하는 방식을 피하도록 안내하고 있습니다.

예를 들어 Scale만 필요하다면

let scale = traitCollection.displayScale

처럼 현재 환경에서 가져오는 편이 낫습니다.

Layout은

UIScreen

보다

Environment
Trait Collection
Scene Bounds
Window

를 기준으로 판단해야 합니다.

Orientation 분기도 다시 봐야 한다

다음 코드 역시 오래된 프로젝트에서 흔합니다.

if orientation.isLandscape {
    showWideLayout()
} else {
    showCompactLayout()
}

Duo 내부 화면에서는 이런 접근이 더 이상 좋은 기준이 아닙니다.

Apple은 Duo 내부 Display가 기존 supportedInterfaceOrientations의 가정을 그대로 따르지 않기 때문에 Layout 결정에는 Size Class를 사용하라고 안내합니다.

SwiftUI라면

@Environment(\.horizontalSizeClass)
private var horizontalSizeClass

UIKit이라면

traitCollection.horizontalSizeClass

를 사용합니다.

즉

Portrait / Landscape

보다

Compact / Regular

그리고 궁극적으로는

현재 사용할 수 있는 공간

이 중요해집니다.

iPhone Duo 내부 화면은 horizontal과 vertical 모두 Regular Size Class를 제공합니다.

그래서 iPhone에서도 Sidebar Navigation을 본격적으로 사용할 수 있습니다.

SwiftUI에서는

TabView {
    Tab("Home", systemImage: "house") {
        HomeView()
    }

    Tab("Search", systemImage: "magnifyingglass") {
        SearchView()
    }

    Tab("Settings", systemImage: "gear") {
        SettingsView()
    }
}
.defaultTabBarPlacement(.sidebar)

처럼 Sidebar 배치를 선택할 수 있습니다.

UIKit에서는

tabBarController
    .sidebar
    .preferredPlacement = .sidebar

를 사용할 수 있습니다.

다만 Sidebar를 요청했다고 항상 Sidebar가 나타나는 것은 아닙니다.

현재 환경에서 Sidebar를 보여줄 공간이 있는지는 시스템이 판단합니다.

UIKit에서는

let available =
    tabBarController.sidebar.isAvailable

로 확인할 수 있습니다.

이제 하나의 앱에서

Compact

┌──────────────────┐
│                  │
│     Content      │
│                  │
├──────────────────┤
│ Home Search Me   │
└──────────────────┘

가

Regular

┌─────────┬─────────────────────┐
│ Home    │                     │
│ Search  │      Content        │
│ Profile │                     │
│ Setting │                     │
└─────────┴─────────────────────┘

로 바뀔 수 있습니다.

중요한 것은 Tab의 역할이 달라지는 것이 아니라 표현 방식만 달라진다는 점입니다.

그래서 앞으로 Navigation Architecture에서 중요한 것은

Tab Bar View

자체가 아니라

Navigation State

입니다.

커스텀 탭바 마이그레이션은 State부터 분리하면 쉽다

기존 Custom Tab Bar가 이런 식으로 돼 있다고 해보겠습니다.

struct CustomTabBar: View {

    @State
    private var selectedIndex = 0

    // UI + Navigation Logic
}

이 구조에서는 Tab Bar UI와 Navigation State가 붙어 있습니다.

시스템 TabView로 바꾸려면 전체 구조를 같이 건드려야 합니다.

먼저 Selection을 외부로 빼는 것이 좋습니다.

enum MainTab: Hashable {
    case home
    case search
    case profile
    case settings
}

그리고 상태를 별도로 관리합니다.

@Observable
final class MainNavigationState {

    var selectedTab: MainTab = .home
}

Custom Tab Bar에서는

MainNavigationState
        ↓
CustomTabBar

를 사용하고,

나중에는 같은 State를

MainNavigationState
        ↓
TabView

가 사용하도록 바꿉니다.

즉

Before

Custom Tab
   │
   ├─ UI
   └─ Navigation State

를

After

Navigation State
      │
 ┌────┴─────┐
 │          │
Custom    System
Tab       TabView

로 바꾸는 것입니다.

이렇게 하면 한 번에 UI 전체를 교체하지 않아도 됩니다.

오래된 UIKit 프로젝트라면 가장 현실적인 순서는 이렇습니다.

현재 구조가

RootViewController

├─ Content
└─ CustomTabBar

라면,

먼저

UITabBarController
        ↓
각 화면의 UINavigationController

구조로 Navigation Container를 바꿉니다.

디자인 때문에 Custom UI가 필요하다면 처음에는 일부 Appearance나 Content를 유지해도 됩니다.

핵심은 Navigation Ownership을 시스템에 돌려주는 것입니다.

이렇게 해두면 이후 Duo의

Vertical Bar
Sidebar
Overflow
Adaptive Navigation

같은 기능을 단계적으로 사용할 수 있습니다.

커스텀 Navigation Bar가 이런 구조라면

HStack {
    BackButton()
    Spacer()
    Text(title)
    Spacer()
    MoreButton()
}

장기적으로는 Action을 시스템 Toolbar Item으로 옮기는 것이 좋습니다.

SwiftUI에서는

.toolbar {
    ToolbarItem(placement: .cancellationAction) {
        Button("Back") {
            dismiss()
        }
    }

    ToolbarItem(placement: .topBarTrailing) {
        Button("More", systemImage: "ellipsis") {
            showMenu()
        }
    }
}

같은 구조입니다.

UIKit에서도

navigationItem
UIBarButtonItem

쪽으로 Action을 이동합니다.

이렇게 해야 시스템이

Horizontal Bar

↓

Vertical Bar

로 이동할 때 각 Action의 의미를 알 수 있습니다.

Duo에서는 Toolbar가 정말 세로가 된다

이 부분은 단순 Sidebar보다 더 중요한 변화일 수 있습니다.

Duo의 넓은 화면에서는 Navigation과 Toolbar Item이 옆쪽 Shared Bar Region에 배치될 수 있습니다.

대략 이런 느낌입니다.

┌──────┬───────────────────────┐
│  ←   │                       │
│      │                       │
│ Done │                       │
│      │       Content         │
│  +   │                       │
│      │                       │
│ ...  │                       │
└──────┴───────────────────────┘

그래서 Toolbar Item도 세로 배치를 고려해야 합니다.

Apple은 가능한 경우 Symbol 중심의 Toolbar Item을 권장합니다.

긴 텍스트 버튼은 Vertical Bar와 잘 맞지 않기 때문입니다.

System Toolbar 안에 Custom View를 넣는 것도 여전히 가능합니다.

예를 들어

.toolbar {
    ToolbarItem {
        ProfileView()
            .axisBehavior(.verticalPreferred)
    }
}

처럼 Vertical Representation을 지원한다고 알려줄 수 있습니다.

반대로 세로 UI로 만들기 어려운 컨트롤은

.axisBehavior(.horizontalOnly)

로 유지할 수 있습니다.

UIKit의 UIBarButtonItem에도 같은 방향의 axisBehavior가 제공됩니다.

즉 선택지가

System UI
or
Custom UI

두 개뿐인 것이 아닙니다.

가장 현실적인 형태는

System Container
       +
Custom Content

입니다.

이것이 기존 Custom UI의 좋은 마이그레이션 지점이다

예전에는

Custom Navigation Bar
    ├─ Back
    ├─ Title
    ├─ Profile View
    └─ Custom Action

전체를 직접 만들었다면,

앞으로는

UINavigationController
        │
        ├─ System Back
        ├─ System Toolbar Item
        ├─ Custom Profile View
        └─ Custom Action View

처럼 바꿀 수 있습니다.

디자인은 상당 부분 유지하면서도 Navigation Context를 시스템에 돌려주는 방식입니다.

이렇게 해야 Apple이 새로운 Form Factor를 만들 때 대응 비용이 줄어듭니다.

Toolbar가 세로로 갔는지도 확인할 수 있다

Custom Content가 Vertical Bar에서 Layout을 바꿔야 한다면 현재 Bar 위치를 확인할 수도 있습니다.

SwiftUI에서는

@Environment(\.toolbarVerticalEdge)
private var verticalEdge

UIKit에서는

traitCollection.verticalBarEdge

를 사용할 수 있습니다.

예를 들어 같은 Profile UI라도

Horizontal

[ Photo  Name ]

에서

Vertical

[Photo]

처럼 바꿀 수 있습니다.

시스템 Container 안에서 Custom View를 사용하면서도 새로운 Duo UI에 적응할 수 있는 방법입니다.

Overflow도 직접 만들지 않는 쪽이 좋아진다

오래된 Custom Toolbar를 보면 흔히

⋯

버튼을 직접 만들고 Menu를 띄우는 코드가 있습니다.

Duo에서는 Bar 공간이 화면 상태에 따라 계속 달라질 수 있습니다.

따라서 어떤 Action이 Overflow로 이동해야 하는지를 직접 계산하기보다 시스템에 맡기는 편이 낫습니다.

SwiftUI에는

ToolbarOverflowMenu {
    Button("Scan") {
        scan()
    }

    Button("Connect") {
        connect()
    }
}

같은 방식이 있습니다.

중요한 Action에는

.visibilityPriority(.high)

를 줄 수도 있습니다.

즉 앞으로 Toolbar 설계는

어디에 놓을 것인가

보다

무엇이 반드시 보여야 하는가

를 시스템에 알려주는 방향으로 바뀝니다.

그래도 Vertical Bar가 맞지 않는 앱도 있다

모든 앱이 Sidebar나 Vertical Toolbar를 사용해야 하는 것은 아닙니다.

예를 들어 Calculator처럼

화면 전체가 하나의 작업 공간
+
하단 Control이 중요한 앱

이라면 Vertical Bar가 오히려 Layout을 방해할 수도 있습니다.

SwiftUI에서는

.toolbarVerticalBehavior(.disabled)

로 Vertical Bar를 끌 수 있습니다.

UIKit에서도 View Controller의

override var preferredVerticalBarBehavior:
    UIVerticalBarBehavior {
    .disabled
}

처럼 Opt-out이 가능합니다.

중요한 것은 새 UI를 무조건 사용하는 것이 아닙니다.

시스템의 Adaptive Behavior를 이해한 뒤 앱에 맞게 선택하는 것입니다.

Resizable 대응은 Duo만 위한 작업이 아니다

Duo 때문에 Resizable이라는 단어가 더 눈에 띄지만 사실 이 문제는 이미 시작됐습니다.

iPhone 앱이

iPhone

iPhone Mirroring

iPad에서 실행

Duo

Split View

등 다양한 공간에서 실행될 수 있기 때문입니다.

그래서 이제

if UIDevice.current.userInterfaceIdiom == .phone

만으로 Layout을 판단하는 것은 부족합니다.

같은 .phone 환경에서도 사용 가능한 Width는 크게 달라질 수 있습니다.

앞으로는

Device Type

이 아니라

Available Space

를 봐야 합니다.

Resizable 대응에서 가장 먼저 없앨 코드

기존 프로젝트에서 아래 코드를 검색해보면 좋습니다.

UIScreen.main

UIDevice.current.userInterfaceIdiom

interfaceOrientation

그리고

.frame(width: 390)

같은 고정 Layout도 확인해야 합니다.

물론 모두 잘못된 코드는 아닙니다.

문제는 Layout 결정의 핵심 기준으로 사용했을 때입니다.

대신

Size Class
Container Size
Safe Area
Trait Collection
Scene

를 사용하도록 조금씩 옮기는 편이 좋습니다.

NavigationSplitView도 이제 iPad 전용 API처럼 보면 안 된다

예전에는

NavigationSplitView

를 보면 사실상

iPad / macOS

용이라고 생각하기 쉬웠습니다.

Duo에서는 상황이 달라졌습니다.

내부 화면은 충분한 공간을 제공하기 때문에

Sidebar
+
Detail

구조가 자연스럽습니다.

SwiftUI라면

NavigationSplitView {
    List {
        NavigationLink(
            "Home",
            value: Destination.home
        )

        NavigationLink(
            "Projects",
            value: Destination.projects
        )
    }
} detail: {
    DetailView()
}

같은 구조를 iPhone에서도 고려할 수 있습니다.

외부 화면에서는 Single Column으로 Collapse되고,

넓은 환경에서는 Split Navigation으로 확장됩니다.

결국 UI가 아니라 Information Architecture까지 바뀐다

Duo 대응을 단순히

390pt 화면

↓

큰 화면

으로 보면 부족합니다.

기존 iPhone에서는 화면 하단에

Home
Search
Profile
Settings

정도만 보여줬다면,

Sidebar에서는

Home

Projects
 ├─ Active
 ├─ Recent
 └─ Archived

Favorites

Team
 ├─ Members
 └─ Shared

Settings

같이 더 많은 Navigation Hierarchy를 보여줄 수 있습니다.

즉 문제는 Layout Resize만이 아닙니다.

화면이 넓어졌을 때 Information Architecture 자체를 확장할 것인지를 생각해야 합니다.

기존 앱이라면 이렇게 마이그레이션하는 게 현실적이다

한 번에 SwiftUI로 다시 만드는 방식은 대부분 현실적이지 않습니다.

다음 정도의 순서가 안전합니다.

1단계 — Custom UI를 Duo에서도 깨지지 않게 만든다

UIScreen.main 제거
Orientation 의존 제거
Safe Area 좌우 독립 처리
고정 Width 제거
Reserved Region 대응

이 단계에서는 기존 디자인을 유지합니다.

Selected Tab
Navigation Path
Deep Link
Presentation State

를 Custom View 내부에서 빼냅니다.

Navigation State
        ↓
Custom UI

구조로 만듭니다.

3단계 — System Container로 이동한다

UIKit이라면

UITabBarController
UINavigationController
UISplitViewController

SwiftUI라면

TabView
NavigationStack
NavigationSplitView

로 Container부터 교체합니다.

전체 Custom Navigation Bar를 유지하기보다 필요한 Custom UI만 남깁니다.

System Navigation
       +
Custom ToolbarItem

구조입니다.

Duo나 Regular Width 환경에서

.defaultTabBarPlacement(.sidebar)

또는

tabBarController
    .sidebar
    .preferredPlacement = .sidebar

를 적용합니다.

Toolbar Item도 Vertical Axis에서 정상적으로 보이는지 확인합니다.

Xcode 27.1에서는 DeviceHub로 반드시 확인하는 게 좋다

Duo는 Simulator를 한 번 띄우는 것으로 테스트가 끝나지 않습니다.

확인해야 할 상태가 많습니다.

Outer Display

Inner Display

Fully Open

Partially Folded

Portrait

Landscape

Split View

Xcode 27.1의 DeviceHub에서는 Duo를 열고 닫고, 회전하고, Fold 상태를 바꾸면서 Layout을 확인할 수 있습니다.

Apple은 기존 App Modernization Skill도 Xcode 27.1에서 App Resizability라는 이름으로 확장했습니다.

SwiftUI와 iPhone Duo까지 분석 대상으로 포함됩니다.

오래된 프로젝트라면 이런 자동 분석을 이용해

Fixed Layout
Screen Assumption
Adaptive Layout 문제

를 먼저 찾는 것도 좋은 시작점입니다.

지금 프로젝트에서 체크할 것

Duo 대응을 준비한다면 최소한 다음은 확인할 필요가 있습니다.

□ UIScreen.main으로 Layout을 계산하는가?

□ interfaceOrientation으로 UI 구조를 결정하는가?

□ Safe Area의 left/right가 같다고 가정하는가?

□ Custom Tab Bar가 화면 아래에 고정되어 있는가?

□ Custom Navigation Bar가 Safe Area를 직접 계산하는가?

□ Tab 선택 State가 Custom Tab Bar 내부에 묶여 있는가?

□ NavigationStack / UINavigationController로 옮길 수 있는가?

□ Regular Width에서 Sidebar가 더 자연스럽지 않은가?

□ Toolbar Custom View가 Vertical Axis에서도 사용할 수 있는가?

□ Overflow Menu를 직접 구현하고 있는가?

□ Duo Split View에서도 UI가 깨지지 않는가?

여기에서 많이 걸린다고 해서 앱을 전부 다시 만들어야 한다는 의미는 아닙니다.

오히려 마이그레이션 우선순위를 잡을 수 있다는 의미입니다.

커스텀 UI가 문제라기보다 시스템과 단절된 UI가 문제다

이번 변화에서 가장 중요한 부분은 이것입니다.

Custom UI 자체가 나쁜 것은 아닙니다.

브랜드 경험이나 복잡한 Interaction 때문에 Custom Control이 반드시 필요한 앱도 있습니다.

문제가 되는 것은

Custom UI
+
Device 가정
+
Magic Number
+
직접 Safe Area 계산
+
Navigation State까지 결합

된 구조입니다.

반대로

System Navigation Container
        +
Adaptive Layout
        +
Custom Content

구조라면 Custom UI를 상당히 많이 유지하면서도 새로운 플랫폼 변화에 대응할 수 있습니다.

마치며

iOS 27.1과 iPhone Duo가 나왔다고 해서 오래된 Custom Tab Bar와 Navigation을 당장 전부 버릴 필요는 없습니다.

Apple도 ReservedRegion과 UIViewReservedRegion을 추가하면서 Custom UI가 새로운 화면 환경에서 시스템 UI와 공존할 수 있는 방법을 제공하고 있습니다.

다만 앞으로의 방향은 분명합니다.

예전에는 앱이

화면 크기
Tab Bar 위치
Navigation 위치
Safe Area

를 상당 부분 직접 결정할 수 있었습니다.

앞으로는

System Container
       ↓
Adaptive Navigation
       ↓
현재 사용 가능한 공간
       ↓
App Content

구조가 훨씬 유리해집니다.

특히 Duo에서는

Bottom Tab Bar
        ↓
Sidebar

Horizontal Toolbar
        ↓
Vertical Toolbar

Single Column
        ↓
Split View

처럼 같은 앱의 Navigation 표현 자체가 바뀔 수 있습니다.

이걸 Custom UI로 전부 직접 구현하는 것도 가능합니다.

하지만 계속 직접 따라가는 비용은 점점 커집니다.

그래서 오래된 프로젝트라면 가장 현실적인 전략은 하나입니다.

디자인을 전부 버리는 것이 아니라 Navigation의 책임부터 시스템에 조금씩 돌려주는 것.

Custom Tab Bar를 유지해야 한다면 먼저 Resizable과 Reserved Region에 대응하고,

그다음 Navigation State를 분리하고,

마지막으로 TabView, UITabBarController, NavigationSplitView 같은 System Container로 이동하면 됩니다.

iPhone Duo가 던지는 질문도 결국 폴더블 대응 하나로 끝나지 않습니다.

다음에 또 다른 화면 형태가 나와도 지금의 Navigation 구조가 그대로 살아남을 수 있는가.

이번 iOS 27.1은 오래된 Navigation 코드를 한 번 점검하기 좋은 시점입니다.

참고자료

Apple Developer — Prepare your app for iPhone Duo
iPhone Duo의 Resizable Layout, Size Class, Safe Area, UIScreen.main 의존 문제, Sidebar와 표준 Navigation의 Adaptive 동작, Xcode 27.1 DeviceHub 테스트 방법 등을 확인할 수 있습니다.
Prepare your app for iPhone Duo
Apple Developer — Raise the bar with iPhone Duo
Duo의 Vertical Bar, Toolbar Item, Custom View, axisBehavior, Overflow, Visibility Priority 등 새로운 Navigation Bar 동작을 확인할 수 있습니다.
Raise the bar with iPhone Duo

Apple 공식 자료 기준으로 보면, iOS 27.1 SDK에서는 표준 Navigation과 Toolbar가 iPhone Duo의 새로운 화면 구조에 맞춰 더 적극적으로 적응합니다.

NavigationSplitView, UISplitViewController, TabView, UITabBarController 같은 System Navigation Container를 사용하면 Duo의 화면 상태와 사용할 수 있는 공간에 따라 Navigation 표현을 변경하기가 훨씬 수월합니다.

내부 화면은 horizontal·vertical Size Class가 모두 regular이기 때문에 Sidebar를 사용할 수 있는 공간도 확보됩니다.

반대로 기존 앱에서 직접 만든

Custom Tab Bar
Custom Navigation Bar
Custom Toolbar

는 같은 Adaptive Behavior를 자동으로 받을 수 있다고 가정하면 안 됩니다.

특히 다음 코드는 다시 확인할 필요가 있습니다.

UIScreen.main

interfaceOrientation

.frame(width: 390)

그리고

left Safe Area == right Safe Area

같은 가정도 Duo에서는 안전하지 않습니다.

iOS 27.1의 ReservedRegion과 UIViewReservedRegion은 Custom Bar나 edge-to-edge UI를 당장 제거하기 어려운 앱에서 시스템 UI와 충돌하지 않도록 만드는 중요한 중간 대응책입니다.

또한 Apple은 Vertical Bar 내부에서도 Custom View를 사용할 수 있도록 axisBehavior, Vertical Bar 환경 정보, Overflow와 Visibility Priority 관련 기능을 제공하고 있습니다.

따라서 현실적인 Migration 방향은

Custom UI 전부 제거

가 아니라

System Container
       +
필요한 Custom Content

에 가깝습니다.

기존 Custom Tab Bar와 Navigation을 유지하면서 먼저 Resizable과 Safe Area에 대응하고, Navigation State를 UI에서 분리한 뒤 TabView, UITabBarController, NavigationSplitView 같은 시스템 Container로 단계적으로 옮기는 것이 가장 현실적인 접근입니다.

AI Agent의 UI는 채팅창이 아닐지도 모른다

Sat, 12 Sep 2026 09:17:13 GMT

AI Agent의 UI는 채팅창이 아닐지도 모른다

AWS Pizza Bot이 보여주는 Long-running Agent의 새로운 UX

요즘 AI 앱을 열면 대부분 비슷한 화면이 나옵니다.

입력창이 있고, 메시지를 보내면 AI가 답합니다.

User
 ↓
Prompt
 ↓
AI
 ↓
Response

ChatGPT 이후 너무 익숙해진 구조입니다.

짧은 질문을 하고 바로 답을 받는다면 이 방식이 잘 맞습니다.

문제는 Agent가 실제 일을 하기 시작하면서 생깁니다.

예를 들어 이런 요청입니다.

오늘 중요한 메일을 확인하고
관련 Slack 메시지도 찾아서
해야 할 일을 정리한 다음
필요한 후속 메일까지 작성해줘.

Agent가 해야 할 일이 많습니다.

Email 확인
   ↓
Slack 확인
   ↓
Task 확인
   ↓
자료 분석
   ↓
결과 정리
   ↓
후속 작업 생성

몇 초가 아니라 몇 분이 걸릴 수도 있습니다.

중간에 이런 상황도 생깁니다.

Agent

"이 메일을 실제로 보내도 될까요?"

사용자의 승인이 필요합니다.

그동안 사람은 뭘 해야 할까요?

채팅창을 계속 보고 있어야 할까요?

AWS가 9월 10일 공개한 오픈소스 프로젝트 Pizza Bot은 바로 여기에서 시작합니다.

핵심 아이디어는 단순합니다.

Agent가 오래 일한다면 사용자가 채팅창에서 기다릴 이유가 없다.

그래서 Pizza Bot은 Agent UI를 Chat이 아니라 Email Inbox처럼 만들었습니다.

지금의 AI UI는 사람이 Agent를 기다리게 만든다

현재 대부분의 AI Agent UI는 기본적으로 synchronous interaction을 가정합니다.

User
 ↓
Request
 ↓
Wait
 ↓
Agent
 ↓
Response

개발 도구에서도 크게 다르지 않습니다.

Terminal에서 Agent를 실행하면 로그가 계속 올라옵니다.

Reading files...
Searching repository...
Running tests...
Fixing error...
Running tests again...

처음에는 재미있습니다.

AI가 실제로 일하는 모습이 보이기 때문입니다.

하지만 작업 시간이 길어질수록 문제가 생깁니다.

3초
10초
30초
2분
10분
30분

Agent가 정말 일을 대신해주는 것인지,

사람이 Agent가 일하는 모습을 지켜보는 것인지 애매해집니다.

AWS는 Pizza Bot 발표에서 이 상황을 상당히 직설적으로 표현했습니다.

이건 collaboration보다 babysitting에 가깝다는 것입니다.

Agent에게 일을 맡겼는데 계속 화면을 보고 있어야 한다면 자동화의 의미가 줄어듭니다.

Email에서는 답장이 올 때까지 Outbox를 보고 있지 않는다

Pizza Bot의 아이디어가 재미있는 이유는 새로운 UI를 발명하지 않았기 때문입니다.

이미 수십 년 동안 사용해온 Email의 작업 방식을 가져왔습니다.

메일을 보낼 때 이런 행동을 하지는 않습니다.

Send
 ↓
Outbox 열기
 ↓
계속 새로고침
 ↓
답장 기다리기

메일을 보낸 다음 다른 일을 합니다.

답장이 오면 알림을 받고 다시 확인합니다.

Pizza Bot은 Agent도 그렇게 사용해야 한다고 봅니다.

Task 전달
   ↓
Agent 작업 시작
   ↓
사용자는 다른 일
   ↓
완료 또는 승인 필요
   ↓
Inbox에 도착

즉 핵심 변화는 이것입니다.

Chat

Stay here

에서

Inbox

Come back later

로 바뀝니다.

Conversation 대신 Thread가 작업의 단위가 된다

일반적인 AI Chat에서는 Session이 중요합니다.

Chat Session

Message
Message
Message
Message

브라우저를 닫거나 Session이 끝나면 작업도 사실상 끝난다고 생각하기 쉽습니다.

Pizza Bot에서는 Thread 자체가 지속되는 작업 공간입니다.

Thread 안에는 단순 대화 내용만 있는 것이 아닙니다.

Thread

├─ Messages
├─ Agent State
├─ Tool Activity
├─ Checkpoints
├─ Attachments
└─ Approval State

가 함께 저장됩니다.

Agent가 중간까지 작업하다가 사람의 승인을 기다리는 상황도 Thread 상태에 포함됩니다.

Running
   ↓
Need Approval
   ↓
Paused
   ↓
User Approves
   ↓
Resume
   ↓
Completed

이 상태가 메모리에만 존재하지 않습니다.

Disk에 checkpoint가 저장됩니다.

그래서 한 시간 뒤 다시 돌아와도 작업을 이어갈 수 있습니다.

Pizza Bot의 Inbox는 세 가지 Queue로 나뉜다

Pizza Bot의 UI는 Email Client와 비슷합니다.

중심에는 세 가지 Queue가 있습니다.

All

전체 Thread

Unread

완료됐지만
아직 확인하지 않은 작업

Action

사람의 결정이나
승인을 기다리는 작업

여기서 가장 흥미로운 것은 Action입니다.

보통 Agent UI에서는 승인을 요청하면 현재 대화 중간에 이런 메시지가 나옵니다.

Agent:

메일을 보내려고 합니다.

Approve?

문제는 사람이 그 순간 자리에 없을 수도 있다는 것입니다.

Pizza Bot에서는 Agent가 멈춘 뒤 Action Queue로 들어갑니다.

Agent
 ↓
Tool 실행 필요
 ↓
Approval Required
 ↓
Action Queue

사용자는 나중에 Action Queue를 열어서 판단합니다.

Approve
Edit
Reject

그리고 Agent는 그 지점부터 다시 작업을 이어갑니다.

Agent UX에서는 Waiting도 정상적인 상태다

기존 Software에서는 작업이 멈추면 보통 문제라고 생각합니다.

Running
 ↓
Success

or

Running
 ↓
Failure

하지만 Agent 시스템에서는 상태가 하나 더 필요합니다.

Running
 ↓
Waiting for Human
 ↓
Running
 ↓
Completed

이게 중요합니다.

AI Agent에게 모든 권한을 주면 위험하고,

모든 작업마다 승인을 요구하면 자동화가 의미 없습니다.

그래서 Agent Workflow에서는 Human-in-the-loop가 어디에 들어갈지가 중요합니다.

예를 들어 이런 식입니다.

메일 읽기
   ↓
자동 허용

문서 요약
   ↓
자동 허용

CRM 정보 조회
   ↓
자동 허용

CRM 수정
   ↓
승인 필요

외부 메일 발송
   ↓
승인 필요

Pizza Bot의 Skill에서는 Tool별로 이런 Approval Policy를 지정할 수 있습니다.

Agent UX가 단순 Chat UX보다 Workflow Engine에 가까워지는 이유입니다.

거절만 있는 것이 아니라 Edit도 있다

Approval UX에서 눈여겨볼 부분이 하나 더 있습니다.

보통 Agent 승인 UI는 이렇습니다.

Approve

Reject

하지만 실제 업무에서는 둘 사이가 필요합니다.

예를 들어 Agent가 이런 메일을 보내려고 합니다.

To: client@example.com

Meeting confirmed for 3 PM.

시간만 4시로 바꾸고 싶다고 해보겠습니다.

기존 방식이라면

Reject
 ↓
Agent에게 다시 설명
 ↓
새 결과 생성
 ↓
다시 승인

해야 합니다.

Pizza Bot은 edit 결정을 지원합니다.

Approve
Edit
Reject

즉 Agent가 제안한 Action 자체를 사람이 수정해서 실행할 수 있습니다.

Long-running Agent에서 꽤 중요한 UX입니다.

사람은 Agent의 결과를 처음부터 다시 만들 필요 없이 마지막 판단만 수정하면 됩니다.

Agent는 Background에서 계속 실행된다

Pizza Bot은 Client와 Agent Runtime을 분리합니다.

구조는 대략 이렇습니다.

Electron App ─┐
Browser      ──┤
Mobile Web   ──┼── HTTP ── Pizza Bot Server
Terminal     ──┘
                        │
                        ↓
                 Agent Runtime
                        │
            ┌───────────┼───────────┐
            ↓           ↓           ↓
         SQLite       Files       MCP

Server가 Agent의 상태를 가지고 있습니다.

따라서 Browser를 닫거나 다른 Device로 이동해도 Server가 살아 있다면 Agent 작업은 계속됩니다.

Laptop

Task 시작
   ↓

Laptop 닫음
   ↓

Agent 계속 작업
   ↓

Phone

결과 확인

이런 구조가 가능합니다.

Agent가 UI 안에서 실행되는 것이 아니라 독립적인 Background Worker처럼 실행되는 것입니다.

모바일 앱에서는 이 구조가 더 자연스럽다

이 부분은 모바일 앱 개발자에게 특히 흥미롭습니다.

모바일에서는 사용자가 하나의 화면을 몇 분씩 보고 있는 경우가 많지 않습니다.

예를 들어 AI 여행 앱에서 이런 작업을 요청했다고 해보겠습니다.

서울에서 오사카로
다음 주말 여행할 건데

항공편 찾아보고
호텔 비교하고
동선까지 정리해줘.

현재 Chat 방식이라면

Prompt
 ↓
Loading
 ↓
Agent working...
 ↓
Agent working...
 ↓
Result

입니다.

하지만 모바일에 더 자연스러운 구조는 이럴 수 있습니다.

Task 생성
   ↓
앱 닫기
   ↓
Agent Background Processing
   ↓
Push Notification

"여행 계획이 준비됐습니다."
   ↓
결과 확인

중간에 승인이 필요하다면

Push Notification

"호텔 예약 전에 확인이 필요합니다."

이 옵니다.

그리고 앱을 열면

Action Required

화면으로 바로 이동합니다.

Pizza Bot의 Inbox 구조와 거의 같습니다.

Agent 앱은 Chat App보다 Task Manager에 가까워질 수 있다

지금 AI App 디자인을 보면 대부분 ChatGPT를 참고합니다.

Sidebar
Conversation
Input Field
Send Button

하지만 Agent가 실제 업무를 수행하기 시작하면 더 자연스러운 UI는 이런 형태일 수 있습니다.

Tasks

────────────────────

● 코드 리뷰 완료
  3분 전

● 여행 계획 완료
  12분 전

! 계약서 전송 승인 필요
  Action Required

○ 경쟁사 조사 중
  Running

○ 매일 오전 뉴스 요약
  Scheduled

Chat이라기보다

Inbox
+
Task Manager
+
Notification Center

에 가깝습니다.

여기에 Agent 상태가 붙습니다.

Queued
Running
Waiting
Completed
Failed

실제로 Agent 앱을 만든다면 Message보다 Task가 Domain Model의 중심이 될 수 있습니다.

앱 Architecture도 달라진다

Chat 기반 AI 앱의 상태는 비교적 단순합니다.

enum ChatState {
    case idle
    case generating
    case completed
    case failed
}

하지만 Long-running Agent를 앱에 넣는다면 상태가 훨씬 많아집니다.

개념적으로는 이런 모델이 필요할 수 있습니다.

enum AgentTaskState {
    case queued
    case running
    case waitingForApproval
    case completed
    case failed
}

그리고 Task 자체가 지속돼야 합니다.

struct AgentTask: Identifiable {
    let id: UUID
    let title: String
    let state: AgentTaskState
    let createdAt: Date
}

UI도 상태별로 달라집니다.

.running

Progress UI

.waitingForApproval

Approve / Edit / Reject

.completed

Result

이렇게 보면 Agent App은 Chat UI보다 State Machine UI에 더 가깝습니다.

Background Agent에는 Persistence가 필수다

Long-running Agent에서 중요한 것은 모델 성능만이 아닙니다.

Agent가 30분 동안 작업한다고 생각해보겠습니다.

Step 1 완료
Step 2 완료
Step 3 완료
Step 4 실행 중

여기서 Process가 죽으면 어떻게 될까요?

처음부터 다시 실행한다면 실용성이 떨어집니다.

그래서 Agent Runtime에는 Checkpoint가 필요합니다.

Pizza Bot도 이 부분을 중요하게 다룹니다.

내부적으로 DeepAgents와 LangGraph 기반의 stateful agent runtime을 사용하며 작업 과정이 계속 checkpoint됩니다.

Task

Step 1
 ↓
Checkpoint

Step 2
 ↓
Checkpoint

Approval
 ↓
Checkpoint

Step 3

Agent가 멈춰도 이전 상태부터 이어갈 수 있습니다.

이제 Agent Backend를 설계할 때 Database에 저장해야 하는 것이 단순 Chat History만은 아닙니다.

Conversation

+

Task State

+

Tool Calls

+

Checkpoint

+

Approval

+

Artifact

까지 포함됩니다.

Scheduled Agent가 되면 Chat UI는 더 어색해진다

Pizza Bot은 Task를 직접 만드는 것뿐 아니라 Schedule이나 Webhook으로 시작할 수 있습니다.

예를 들어

매일 08:00

메일 확인
 ↓
Slack 확인
 ↓
오늘 중요한 일 정리

를 실행할 수 있습니다.

사용자가 Prompt를 보내지 않았습니다.

그래도 Agent는 작업합니다.

Cron
 ↓
Agent
 ↓
Result
 ↓
Inbox

Webhook도 비슷합니다.

GitHub PR 생성
 ↓
Webhook
 ↓
Agent Code Review
 ↓
Inbox

이쯤 되면 Chat이라는 UI가 더 이상 중심이 아닙니다.

Agent를 시작하는 Trigger가

User Prompt
Schedule
Webhook
Event

로 늘어나기 때문입니다.

결과를 보여주는 곳도 자연스럽게 Inbox가 됩니다.

Notification이 Agent UX의 핵심이 될 수 있다

Background Agent가 일반화되면 Notification의 의미도 바뀝니다.

지금 Notification은 주로

새 메시지
새 댓글
배송 상태

를 알려줍니다.

Agent App에서는

작업 완료

뿐 아니라

사람의 판단 필요

도 알려줘야 합니다.

예를 들면 이런 Push가 가능합니다.

AI Assistant

경쟁사 분석이 완료됐습니다.

또는

AI Assistant

고객에게 메일을 보내기 전에
승인이 필요합니다.

Notification을 누르면 해당 Task의 정확한 상태로 Deep Link됩니다.

Push
 ↓
Task ID
 ↓
Action Screen

Agent 앱에서 Notification은 부가 기능이 아니라 주요 Interaction Channel이 될 가능성이 큽니다.

Pizza Bot도 Main Agent와 Specialist를 나눈다

Pizza Bot에서는 사용자가 이야기하는 Main Agent가 Generalist 역할을 합니다.

그리고 특정 작업은 Skill 기반 Specialist Worker에게 넘길 수 있습니다.

Main Agent
    │
    ├─ Meeting Specialist
    │
    ├─ Browser Specialist
    │
    └─ Research Specialist

각 Specialist는 별도 Instruction과 제한된 Tool 목록을 갖습니다.

예를 들어 Browser Automation Agent에는 Browser Tool만 주는 식입니다.

Browser Specialist

Allowed Tools

├─ navigate
├─ click
├─ type
└─ screenshot

CRM Agent라면

CRM Specialist

Allowed Tools

├─ readCustomer
├─ readDeal
└─ updateDeal

처럼 구성할 수 있습니다.

Agent마다 사용할 수 있는 Tool 범위를 줄이면 두 가지 장점이 있습니다.

Context ↓

Permission Surface ↓

Agent가 무엇을 할 수 있는지도 확인하기 쉬워집니다.

MCP와 Skill을 그대로 활용한다

Pizza Bot은 새로운 Tool Extension 규격을 따로 만들지 않았습니다.

외부 Tool은 MCP로 연결합니다.

Pizza Bot
    ↓
MCP
    ↓
Calendar
Slack
CRM
Browser
GitHub

Specialist의 동작 방식은 SKILL.md로 정의할 수 있습니다.

개념적으로 보면 이런 구조입니다.

skill
 ├─ instructions
 ├─ tools
 └─ approval policy

Agent가 새로운 기능을 필요로 할 때 Core Application을 계속 수정하는 방식보다,

Skill
+
MCP Server

를 추가하는 구조입니다.

최근 Agent 생태계에서 Plugin Architecture가 어느 방향으로 정리되고 있는지도 볼 수 있는 부분입니다.

Tool Permission도 Agent UX와 연결된다

Agent가 실제 업무를 하면 결국 권한 문제가 생깁니다.

Pizza Bot에서는 기본적으로 사용자의 Disk 전체에 바로 접근할 수 없습니다.

Folder 접근도 사용자가 직접 허용해야 합니다.

Folder

Read Only

or

Read + Write

MCP Tool도 마찬가지입니다.

특정 Skill에서 어떤 Tool을 사용할 수 있는지 제한할 수 있습니다.

그리고 위험한 작업에는 Approval을 붙일 수 있습니다.

Read

Auto

Write

Approval

Delete

Approval

즉 Agent Security와 Agent UX가 따로 존재하지 않습니다.

권한 정책이 UI에 그대로 나타납니다.

Action Queue가 그 대표적인 결과입니다.

Self-hosted라는 점도 의미가 있다

Pizza Bot은 AWS의 Hosted Service가 아닙니다.

오픈소스 Community Project이고 Self-hosted 방식입니다.

Telemetry도 없으며 데이터는 기본적으로 사용자가 관리하는 환경에 저장됩니다.

Model Provider도 선택할 수 있습니다.

Anthropic
Amazon Bedrock
Google Gemini
OpenAI
OpenRouter
Ollama

Local Model도 가능합니다.

구조적으로 보면 Agent Runtime과 Model Provider가 분리돼 있습니다.

Pizza Bot
     ↓
Agent Runtime
     ↓
Provider Interface
     ↓
┌────────┬────────┬────────┐
Claude  Gemini  OpenAI  Local

Agent Application이 특정 모델 하나에 종속될 필요가 없다는 의미입니다.

최근 Agent Architecture에서 계속 보이는 흐름이기도 합니다.

Model보다 Runtime과 Workflow가 위에 놓이기 시작하고 있습니다.

Amazon 내부에서는 이미 2,000명 이상이 사용했다

Pizza Bot은 갑자기 만들어진 실험 프로젝트는 아닙니다.

이전 버전은 Amazon 내부에서 사용됐고, AWS에 따르면 2,000명 이상이 사용했습니다.

활용 사례도 개발 업무에만 한정되지 않았습니다.

Meeting 준비

Follow-up

Email 작성

Slack 요약

CRM 기록

하루 업무 우선순위 정리

Web Research

같은 작업에 사용됐습니다.

즉 Pizza Bot이 해결하려는 문제는 Coding Agent만의 문제가 아닙니다.

시간이 오래 걸리는 모든 Agent Task의 Interaction 방식에 대한 실험에 가깝습니다.

모든 AI 앱에 Inbox가 필요한 것은 아니다

그렇다고 Chat UI가 잘못됐다는 이야기는 아닙니다.

질문의 성격에 따라 다릅니다.

짧은 Interaction이라면 Chat이 훨씬 좋습니다.

이 코드 설명해줘.

이 문장 번역해줘.

Swift Actor가 뭐야?

이런 요청은

Prompt
 ↓
Immediate Response

가 자연스럽습니다.

반면 이런 요청은 다릅니다.

Repository 전체를 분석해서
Architecture 문제를 찾아줘.

이번 주 경쟁사 뉴스를 조사하고
보고서 만들어줘.

메일과 Slack을 확인해서
오늘 해야 할 일을 정리해줘.

이런 작업은

Task
 ↓
Background Work
 ↓
Notification
 ↓
Result

구조가 더 자연스럽습니다.

결국 Agent App에서는 두 가지 UI가 같이 존재할 가능성이 큽니다.

Quick Interaction

Chat

Long-running Work

Inbox / Task

AI 앱을 만들 때 먼저 물어봐야 할 질문

최근 AI 기능을 앱에 넣을 때 가장 먼저 만드는 화면은 흔히 Chat입니다.

하지만 앞으로는 먼저 다른 질문을 해볼 필요가 있습니다.

이 작업은 몇 초 안에 끝나는가?

몇 초라면 Chat이 좋습니다.

사용자의 승인이 중간에 필요한가?

필요하다면 Task 상태 관리가 필요합니다.

앱을 닫아도 계속 실행돼야 하는가?

그렇다면 Backend Agent Runtime이 필요합니다.

Schedule이나 Event로 자동 실행되는가?

그렇다면 Chat보다 Inbox가 더 중요해집니다.

즉 UI를 결정하기 전에 Agent의 실행 모델부터 결정해야 합니다.

Long-running Agent의 구조는 이런 모습에 가까워진다

Pizza Bot의 아이디어를 일반적인 Agent 앱 Architecture로 바꿔보면 이런 형태입니다.

                 Trigger
                    │
        ┌───────────┼───────────┐
        │           │           │
      User       Schedule    Webhook
        │           │           │
        └───────────┼───────────┘
                    ↓
               Agent Task
                    ↓
               Agent Runtime
                    ↓
           ┌────────┴────────┐
           │                 │
       Tool Calls        Specialist
           │                 │
           └────────┬────────┘
                    ↓
                 State
                    ↓
       ┌────────────┼────────────┐
       │            │            │
    Running       Action      Completed
                     │            │
                     ↓            ↓
                 Approval       Unread

여기에서 Chat은 전체 시스템의 일부일 뿐입니다.

Agent Application의 중심은

Task
State
Trigger
Tool
Approval
Notification

입니다.

이 변화가 중요한 이유입니다.

모바일 Agent 앱이라면 더 고민해볼 만하다

iOS 앱으로 생각하면 구조가 더 명확해집니다.

사용자가 Agent Task를 생성합니다.

struct AgentTask: Identifiable, Codable {
    let id: UUID
    let title: String
    var state: State

    enum State: String, Codable {
        case queued
        case running
        case waitingForApproval
        case completed
        case failed
    }
}

Server에서는 Agent가 계속 작업합니다.

상태가 바뀌면 Push Notification을 보냅니다.

Server
 ↓
Task State Changed
 ↓
APNs
 ↓
iPhone

앱에서는 상태에 따라 다른 화면을 보여줍니다.

switch task.state {
case .running:
    ProgressView()

case .waitingForApproval:
    ApprovalView(task: task)

case .completed:
    ResultView(task: task)

default:
    EmptyView()
}

이렇게 보면 AI Agent 앱은 기존 Chat App보다 오히려

Background Job Management App

에 더 가까워집니다.

결국 Agent의 UX는 ‘대화’보다 ‘위임’에 가까워지고 있다

지금까지 AI는 주로 대화 상대였습니다.

Ask
 ↓
Answer

Agent는 조금 다릅니다.

Delegate
 ↓
Work
 ↓
Report

사람 사이에서도 이 두 방식은 다릅니다.

옆자리 동료에게 간단히 질문할 때는 바로 대화합니다.

하지만 몇 시간 걸리는 일을 맡길 때는 계속 옆에서 지켜보지 않습니다.

이거 조사해줘.

↓

다 되면 알려줘.

Agent도 실제 업무를 맡기기 시작하면 같은 UX가 필요해집니다.

그래서 Pizza Bot에서 가장 흥미로운 것은 어떤 모델을 사용하는지도, 새로운 Agent Algorithm도 아닙니다.

사용자가 Agent를 계속 보고 있지 않는다는 것을 처음부터 전제로 UI를 설계했다는 점입니다.

마치며

Chat은 AI 시대의 첫 번째 Interface였습니다.

빠르게 질문하고 빠르게 답을 받는 데는 여전히 가장 좋은 방식입니다.

하지만 Agent가

검색하고

파일을 읽고

여러 Tool을 호출하고

다른 Agent에게 일을 나누고

사람의 승인을 기다리고

몇 분 또는 몇 시간 동안 작업하고

Schedule에 따라 다시 실행되는

단계까지 오면 이야기가 달라집니다.

그런 작업을 작은 채팅창 안에서 계속 지켜보는 것은 자연스럽지 않습니다.

Pizza Bot이 제안하는 방식은 훨씬 단순합니다.

일을 맡긴다.

↓

다른 일을 한다.

↓

끝났거나
내 판단이 필요할 때
Agent가 다시 찾아온다.

결국 Long-running Agent에서 중요한 UI는 입력창이 아니라

Inbox, Task State, Approval, Notification

일 수 있습니다.

앞으로 AI 앱을 만들 때도

Chat 화면을 어떻게 만들까?

보다 먼저 물어볼 질문이 하나 생겼습니다.

이 작업을 사용자가 끝날 때까지 보고 있어야 할 이유가 있는가?

답이 아니오라면, 그 앱은 Chat보다 Inbox에 가까워지는 편이 더 자연스러울 수 있습니다.

참고자료

AWS Open Source Blog — Introducing Pizza Bot, an open source inbox for AI agents that work in the background
Pizza Bot의 Inbox 중심 UI, Background Agent, Unread/Action Queue, Schedule, Webhook, Self-hosted 구조를 설명한 공식 발표입니다.
AWS Pizza Bot 공식 발표
AWS Open Source Blog
Pizza Bot을 포함해 AWS가 공개하는 Agent, MCP, Open Source 관련 후속 자료를 확인할 수 있습니다.
AWS Open Source Blog

AWS 공식 자료 기준으로 보면, Pizza Bot에서 가장 중요한 것은 새로운 AI 모델이 아니라 Agent와 사용자가 상호작용하는 방법을 바꿨다는 점입니다.

사용자가 Agent에게 작업을 맡긴 뒤 Chat 화면에서 계속 기다리는 대신 Agent는 Background에서 작업합니다.

Task 생성
   ↓
Background Agent
   ↓
작업 완료
   ↓
Unread

사람의 판단이 필요하면

Agent
   ↓
Approval Required
   ↓
Action

으로 이동합니다.

또한 작업은 사용자가 직접 시작하는 것뿐 아니라 Schedule이나 Webhook으로 시작할 수 있습니다.

그래서 Agent Application의 중심도

Conversation

보다

Task
State
Approval
Notification
Trigger

에 가까워집니다.

Long-running Agent를 모바일 앱이나 업무 도구에 넣는다면 Chat UI를 그대로 복제하기보다 Inbox + Task Manager + Notification 구조가 더 자연스러운 경우가 많다는 것을 보여주는 사례입니다.

Apple 2026 이벤트 총정리

Wed, 09 Sep 2026 22:29:27 GMT

Apple 2026 이벤트 총정리

iPhone Duo부터 Siri AI까지, 그리고 개발자가 봐야 할 변화

Apple의 2026년 9월 이벤트가 끝났습니다.

이번 발표는 최근 몇 년의 iPhone 행사 중에서도 변화 폭이 꽤 큰 편입니다.

가장 큰 이유는 단연 Apple 최초의 폴더블 iPhone, iPhone Duo입니다.

여기에

iPhone 18 Pro / Pro Max
Apple Watch Series 12
Apple Watch Ultra 4
AirPods 5
새로운 Siri AI
Apple Intelligence 기반 Health 기능

까지 한꺼번에 공개됐습니다.

이번 발표를 한 문장으로 정리하면 이렇습니다.

하드웨어의 형태는 더 다양해지고, 그 위에서 Apple Intelligence가 사용자의 Context를 이해하기 시작했다.

먼저 이번 Apple Event에서 발표된 내용부터 정리해보겠습니다.

1. 가장 큰 발표 — Apple 최초의 폴더블 iPhone, iPhone Duo

이번 이벤트의 주인공은 사실상 iPhone Duo였습니다.

Apple 최초의 폴더블 iPhone입니다.

접었을 때는 5.4인치 외부 디스플레이, 펼쳤을 때는 7.6인치 내부 디스플레이를 사용합니다.

특히 내부 디스플레이는 Apple이 지금까지 만든 iPhone 중 가장 큰 화면입니다.

접었을 때는 비교적 작은 iPhone처럼 사용할 수 있고, 펼치면 콘텐츠 감상이나 게임, 멀티태스킹에 훨씬 넓은 화면을 제공합니다.

흥미로운 점은 두 디스플레이가 같은 화면 비율을 사용한다는 것입니다.

그래서 앱을 접힌 화면에서 사용하다가 펼쳐도 콘텐츠가 자연스럽게 확장됩니다.

단순히 화면 두 개가 붙어 있는 폴더블이 아니라, Apple답게 Hardware와 Software를 같이 설계한 형태입니다.

iPhone Duo의 핵심 사양

iPhone Duo는 새로운 A20 Pro를 사용합니다.

A20 Pro는 2nm 공정 기반이며,

6-core CPU
7-core GPU
Dual 16-core Neural Engine
향상된 Unified Memory Bandwidth

를 제공합니다.

특히 AI 처리 성능이 크게 강화됐습니다.

폴더블 구조에서 가장 걱정되는 부분인 발열도 별도로 대응했습니다.

iPhone Duo에는

Custom Vapor Chamber + Dual Battery Architecture

가 들어갑니다.

Apple은 이를 통해 멀티태스킹이나 게임, AI 연산 같은 지속적인 고성능 작업에서도 안정적인 성능을 유지하도록 설계했습니다.

2. 폴더블 구조를 활용한 새로운 Camera 경험

iPhone Duo는 폴더블 구조 자체를 Camera 기능에도 활용합니다.

기기를 펼치거나 접은 상태에 따라 상대방에게 Preview를 보여주거나, 기존 iPhone에서는 만들기 어려웠던 촬영 구도를 만들 수 있습니다.

그리고 Siri Camera Mode도 새롭게 등장합니다.

Camera Control을 통해 Siri Camera를 실행하면 Siri가 사용자가 보고 있는 장면을 이해하고 질문에 답하거나 관련 작업을 수행할 수 있습니다.

지금까지 Camera가

Camera
 ↓
Capture
 ↓
Photo

였다면 앞으로는

Camera
 ↓
Scene Understanding
 ↓
Siri AI
 ↓
Action

이라는 새로운 사용 방식이 추가되는 셈입니다.

3. iPhone Duo는 Apple Pencil도 지원한다

조금 의외였던 기능도 있습니다.

iPhone Duo가 Apple Pencil USB-C를 지원합니다.

Apple Pencil은 외부 화면과 내부 화면 모두에서 사용할 수 있습니다.

7.6인치 내부 화면을 펼치면 사실상 작은 iPad에 가까운 작업 공간이 만들어집니다.

따라서

메모
문서 Annotation
Sketch
PDF Markup

같은 작업이 가능해집니다.

iPhone과 iPad 사이의 경계가 점점 흐려지고 있다는 느낌을 주는 부분입니다.

4. iPhone 18 Pro — 이번에는 Camera가 많이 바뀌었다

iPhone 18 Pro와 Pro Max 역시 상당한 변화가 있습니다.

이번 Pro 모델의 핵심은

Camera + Performance + AI

세 가지입니다.

가장 눈에 띄는 변화는 메인 Camera입니다.

48MP Fusion Main Camera에 Variable Aperture, 즉 가변 조리개가 들어갔습니다.

기존 iPhone Camera는 Computational Photography를 통해 대부분의 결과를 자동으로 처리했습니다.

하지만 이번에는 Professional User를 위한 수동 제어 기능이 더 강화됐습니다.

새로운 Pro Control에서는

Aperture
Shutter Speed
White Balance
Histogram

등을 직접 제어할 수 있습니다.

iPhone이 점점 Mirrorless Camera에 가까운 촬영 경험을 제공하는 방향으로 가고 있습니다.

5. Dynamic Island도 다시 바뀐다

iPhone 18 Pro에서는 Dynamic Island가 더 작아졌습니다.

그런데 표시할 수 있는 정보는 오히려 늘어났습니다.

새로운 Dynamic Island에서는 최대 3개의 Live Activity를 동시에 표시할 수 있습니다.

예를 들어

Taxi 도착 시간
+
스포츠 경기 점수
+
음악 재생

같은 정보를 동시에 보여줄 수 있습니다.

Dynamic Island가 단순 Notification 영역이 아니라 점점 실시간 앱 상태를 보여주는 작은 Dashboard에 가까워지고 있습니다.

6. A20 Pro — AI를 위한 칩이라는 느낌이 더 강해졌다

iPhone 18 Pro와 iPhone Duo 모두 A20 Pro를 사용합니다.

CPU나 GPU 성능도 올라갔지만 이번 Apple의 설명을 보면 특히 AI에 상당히 많은 비중을 두고 있습니다.

구조는

6-core CPU
7-core GPU
Dual 16-core Neural Engine

입니다.

새로운 N1 Networking Chip을 통해

Wi-Fi 7
Bluetooth 6
Thread

를 지원합니다.

Cellular Modem 역시 Apple 자체 설계의 C2 Modem으로 변경됐습니다.

Apple이 iPhone의 핵심 Silicon을 점점 자체 설계로 가져오는 흐름이 더 명확해졌습니다.

7. Siri AI — 이번 이벤트에서 하드웨어만큼 중요한 변화

이번 발표에서 제품만큼 중요한 것이 새로운 Siri AI입니다.

기존 Siri와 가장 큰 차이는 사용자의 Personal Context를 이해한다는 점입니다.

예를 들어 Siri가

Messages
Mail
Photos
현재 화면

등의 정보를 바탕으로 사용자의 요청을 이해할 수 있습니다.

예전 Siri는

Command
 ↓
Action

에 가까웠습니다.

앞으로는

Context
 ↓
Understanding
 ↓
Reasoning
 ↓
Action

에 가까워집니다.

그리고 중요한 기능이 On-screen Awareness입니다.

사용자가 현재 화면에서 보고 있는 콘텐츠를 Siri가 이해할 수 있습니다.

예를 들어 화면에 어떤 장소 정보가 있다면

여기 일정에 추가해줘.

같은 식의 요청이 가능해집니다.

Siri가 단순 Voice Assistant가 아니라 OS 전체를 연결하는 AI Layer가 되어가는 모습입니다.

8. Siri AI는 단계적으로 제공된다

여기서 중요한 점도 있습니다.

이번에 공개된 Siri AI 전체 기능이 모든 국가와 언어에서 동시에 제공되는 것은 아닙니다.

초기에는 일부 언어와 지역부터 제공되고 이후 지원 범위가 확대됩니다.

따라서 Apple Intelligence와 Siri 기능을 사용하는 앱이라면 지역과 언어별 지원 범위를 별도로 확인할 필요가 있습니다.

9. Apple Watch Series 12 — 이번에는 Health가 중심

Apple Watch Series 12는 디자인보다 Health Sensing이 핵심입니다.

새로운 Health Sensing System과 S11 Chip을 중심으로 사용자의 상태를 더 자주, 더 정밀하게 측정합니다.

Apple Watch는 단순히 심박수나 활동량을 기록하는 기기에서

Sensor
 ↓
Data
 ↓
Interpretation

을 수행하는 방향으로 계속 확장되고 있습니다.

10. Readiness Score

Apple Watch Series 12에 새롭게 추가되는 대표 기능은 Readiness입니다.

Readiness는

최근 운동량
Training Load
Sleep
HRV
Vitals

등을 종합해서 사용자의 하루 컨디션을 계산합니다.

결과는

Recover
Pace Yourself
Ready
Go For It

같은 식으로 보여줍니다.

단순히 건강 데이터를 보여주는 것이 아니라

지금 운동을 해도 되는지, 쉬는 것이 좋은지

까지 해석해서 알려주는 방향입니다.

11. Health 앱도 데이터보다 Insight가 중심이 된다

iPhone의 Health 앱도 크게 바뀝니다.

새로운 Health 관련 화면에서는 사용자의 장기적인 건강 데이터와 여러 지표를 함께 분석합니다.

중요한 변화는 Health 앱이 점점

Heart Rate
Sleep
HRV
Exercise
Vitals

같은 숫자를 보여주는 앱에서

Data
 ↓
Pattern
 ↓
Insight
 ↓
Recommendation

을 제공하는 앱으로 바뀌고 있다는 점입니다.

Apple Intelligence가 Chat이나 Image Generation에만 사용되는 것이 아니라 Health Data Interpretation으로 확장되는 모습입니다.

12. Apple Watch Ultra 4

Apple Watch Ultra 4 역시 새로운 Health Sensing System과 S11을 사용합니다.

다만 Ultra답게 Outdoor와 Battery 사용 시간이 더 강화됐습니다.

일반 사용뿐 아니라 장시간 GPS Tracking이 필요한

Ultra Marathon
Hiking
Trail Running
Expedition

같은 환경을 더욱 적극적으로 고려하고 있습니다.

13. Apple Watch에도 Audio Intelligence가 들어간다

이번 Watch 발표에서 의외로 흥미로운 부분이 Audio Intelligence입니다.

주변 Sound를 감지하고, 사용자가 들었던 내용을 기반으로 정보를 제공하거나 Siri와 연결할 수 있는 기능이 확대됩니다.

Apple Watch가 단순 Health Sensor가 아니라

사용자 주변의 Context를 이해하는 AI Device

로 확장되는 모습입니다.

14. AirPods 5 — Open-ear ANC와 AI

AirPods 5도 새롭게 발표됐습니다.

이번 AirPods의 핵심은

Open-ear ANC + Adaptive EQ + Siri AI

입니다.

ANC 성능이 더 강화됐고 새로운 Acoustic Architecture와 Adaptive EQ가 적용됐습니다.

하지만 개발 관점에서 더 흥미로운 부분은 AI입니다.

15. AirPods에서 Live Translation

AI 관련 기능 중 가장 눈에 띄는 것이 Live Translation입니다.

AirPods를 착용한 상태에서 서로 다른 언어로 대화하면 Apple Intelligence가 실시간 Translation을 지원합니다.

AirPods는 점점

Audio Device

에서

Microphone
+
Speaker
+
Voice Interface
+
AI Interface

로 변하고 있습니다.

화면을 보지 않고 AI를 사용하는 경험이 점점 중요해지고 있다는 의미입니다.

이번 Apple Event를 한눈에 정리하면

이번 발표의 핵심은 크게 네 가지입니다.

① iPhone의 새로운 Form Factor

Phone
 ↓
Foldable
 ↓
Large Canvas

iPhone Duo가 등장하면서 iPhone과 iPad 사이에 새로운 영역이 생겼습니다.

② Pro Camera의 확장

Auto
+
Manual Control
+
Computational Photography

iPhone Camera가 단순 자동 촬영에서 더 전문적인 촬영 도구로 확장됩니다.

③ Apple Intelligence의 Device 확장

iPhone
Watch
AirPods
Camera
Health
Siri

AI가 하나의 앱이나 Siri 안에만 존재하지 않고 Apple Device 전체로 퍼지고 있습니다.

④ Sensor Data를 AI가 해석하기 시작

Sensor
 ↓
History
 ↓
Personal Baseline
 ↓
AI Interpretation
 ↓
Recommendation

Apple Watch와 Health 앱의 방향이 가장 대표적입니다.

여기부터는 개발자가 봐야 할 부분

여기까지가 이번 Apple Event 자체의 핵심 내용입니다.

그런데 iOS 개발자라면 이번 발표에서 몇 가지를 조금 다르게 봐야 합니다.

1. iPhone Duo — Adaptive Layout이 이제 iPhone의 문제다

폴더블 iPhone이 등장하면서 Adaptive Layout은 더 이상 iPad 개발에서만 중요한 문제가 아닙니다.

하나의 앱이 좁은 화면과 넓은 화면을 오갈 수 있기 때문입니다.

따라서 기존의

UIScreen.main.bounds.width

기반 분기나

UIDevice.current.userInterfaceIdiom

기반 Layout 결정은 점점 위험해질 수 있습니다.

앞으로 중요한 것은

Device

가 아니라

Available Space

입니다.

SwiftUI라면

@Environment(\.horizontalSizeClass)
private var horizontalSizeClass

또는

ViewThatFits {
    ExpandedView()
    CompactView()
}

같은 방식이 더 자연스러워집니다.

Resizable보다 개인적으로 더 흥미로운 변화는 iPhone에서도 Sidebar Navigation을 공식적으로 사용할 수 있게 됐다는 점입니다.

지금까지 iPhone의 대표적인 Navigation은 거의

Tab Bar

였습니다.

예를 들어

Home
Search
Favorites
Profile
Settings

를 화면 아래쪽에 두는 구조입니다.

하지만 iOS 27에서는 iPhone 앱도 Sidebar 표현을 선택할 수 있습니다.

UIKit에서는 다음과 같이 설정할 수 있습니다.

tabBarController.sidebar.preferredPlacement = .sidebar

그러면 앱이 Sidebar 표현을 선호한다는 것을 시스템에 알려줍니다.

다만 항상 Sidebar가 표시되는 것은 아닙니다.

실제로 Sidebar를 보여줄 만큼 공간이 있는지는 시스템이 판단합니다.

현재 환경에서 Sidebar가 사용 가능한지는 다음처럼 확인할 수 있습니다.

let available = tabBarController.sidebar.isAvailable

즉 구조는 이런 식입니다.

Compact Width
      ↓
   Tab Bar

Regular Width
      ↓
   Sidebar

iPhone Duo처럼 화면이 넓어지는 Device에서는 이 변화가 특히 중요합니다.

여기서 중요한 차이가 하나 있습니다.

iPad에서는 Tab Bar와 Sidebar가 환경에 따라 자연스럽게 전환되거나 사용자가 UI를 통해 전환할 수 있습니다.

하지만 iPhone에서는 Sidebar를 사용할지 앱이 선택합니다.

tabBarController.sidebar.preferredPlacement = .sidebar

를 설정했다면 시스템은 현재 공간이 충분할 때 Sidebar를 표시합니다.

사용자가 직접

Tab Bar ↔ Sidebar

를 토글하는 구조는 아닙니다.

즉 iPhone에서 Sidebar는 단순히 iPad UI를 가져온 것이 아니라 iPhone 환경에 맞게 다시 정의된 Navigation Pattern이라고 볼 수 있습니다.

Sidebar의 장점은 단순히 Menu 위치가 왼쪽으로 이동한다는 것이 아닙니다.

Navigation Hierarchy 자체가 더 풍부해질 수 있습니다.

기존 Tab Bar에서는 보통 Root Navigation이 제한적입니다.

Home
Search
Profile
Settings

하지만 Sidebar에서는

Home

Library
 ├─ Recent
 ├─ Favorites
 └─ Downloads

Projects
 ├─ Project A
 ├─ Project B
 └─ Project C

Settings

처럼 더 깊은 구조를 한 번에 보여줄 수 있습니다.

즉 iPhone Duo의 큰 화면을 단순히

기존 UI를 확대해서 보여주는 것

이 아니라

Information Architecture 자체를 바꾸는 것

까지 고려할 수 있습니다.

이 부분이 Adaptive Layout보다 한 단계 더 중요한 변화라고 생각합니다.

5. NavigationSplitView도 이제 iPhone에서 더 중요해진다

SwiftUI에서는 NavigationSplitView를 다시 볼 필요가 있습니다.

예전에는 사실상

iPad
macOS

중심 API라는 인식이 강했습니다.

하지만 넓은 iPhone 환경이 생기면서 이야기가 달라집니다.

예를 들어

NavigationSplitView {
    List {
        NavigationLink("Home", value: Destination.home)
        NavigationLink("Search", value: Destination.search)
        NavigationLink("Settings", value: Destination.settings)
    }
} detail: {
    DetailView()
}

같은 구조가 iPhone에서도 충분히 의미 있는 Layout이 될 수 있습니다.

즉 앞으로 Navigation을 설계할 때

iPhone = NavigationStack
iPad = NavigationSplitView

처럼 기기별로 구분하기보다는

Compact Space
   ↓
NavigationStack

Expanded Space
   ↓
NavigationSplitView

처럼 공간을 기준으로 설계하는 방식이 더 자연스럽습니다.

6. 중요한 Tab은 계속 살아남게 할 수 있다

iOS 27에서는 UITabBarController에 prominentTabIdentifier도 추가됐습니다.

예를 들어 쇼핑 앱의 Cart처럼 항상 중요한 Tab이 있다고 가정해봅시다.

tabBarController.prominentTabIdentifier = "cart"

처럼 지정할 수 있습니다.

이렇게 하면 지원되는 Layout에서 해당 Tab을 더 중요한 항목으로 표시할 수 있습니다.

예를 들어

Home
Search
Favorites
Cart ★
Profile

처럼 특정 기능을 Navigation 구조에서 강조할 수 있습니다.

검색 중심 앱이라면 Search,

음악 앱이라면 Now Playing,

쇼핑 앱이라면 Cart

같은 기능을 생각해볼 수 있습니다.

7. Dynamic Island / Live Activity도 다시 테스트해야 한다

iPhone 18 Pro에서는 여러 개의 Live Activity가 동시에 표시될 수 있습니다.

따라서 개발자는 자신의 Live Activity가 항상 넓은 공간을 사용할 수 있다고 가정하면 안 됩니다.

My Activity
+
Other Activity
+
Other Activity

환경에서도 핵심 정보가 살아남아야 합니다.

즉 Live Activity UI도

Full Space

가 아니라

Limited Space

를 기준으로 다시 테스트할 필요가 있습니다.

8. Camera 앱 개발자는 iPhone 18 Pro를 눈여겨볼 필요가 있다

가변 조리개와 새로운 Pro Control은 Apple Camera 앱의 기능처럼 보이지만, Camera 관련 앱을 만드는 개발자에게도 의미가 있습니다.

Camera Pipeline은 점점

AVCaptureSession
      ↓
Camera Frame
      ↓
Vision / Core ML
      ↓
On-device AI
      ↓
Real-time Result

구조로 발전하고 있습니다.

A20 Pro의 Neural Engine과 Memory Bandwidth 향상은

Real-time Filter
Object Detection
Video Analysis
OCR
Generative Camera

같은 기능에서 실제 의미가 있습니다.

9. Siri AI에서 개발자가 봐야 할 것은 App Intents다

이번 이벤트에서 Siri AI가 강조됐지만 개발자는 그 뒤에 있는 App Intents를 봐야 합니다.

서버 AI의 Tool Calling을 생각하면 이해하기 쉽습니다.

일반적인 AI Agent는

LLM
 ↓
Tool
 ↓
Function

구조입니다.

Apple 플랫폼에서는

Siri / Apple Intelligence
        ↓
App Intent
        ↓
App Feature

가 됩니다.

예를 들어

struct AddInventoryIntent: AppIntent {
    // ...
}

같은 Intent를 제공하면 AI가

우유 하나 재고에 추가해줘.

같은 자연어 요청을 실제 앱 기능으로 연결할 수 있습니다.

앞으로 App Intents는 단순 Shortcut API가 아니라

Apple Intelligence가 앱 기능을 호출하기 위한 Interface

에 가까워질 가능성이 큽니다.

10. On-device AI를 더 적극적으로 생각할 시점

A20 Pro가 Neural Engine을 강조하는 이유도 중요합니다.

앞으로 모든 AI 작업을 Server로 보내기보다는

On-device AI
+
Cloud AI

Hybrid 구조를 고민할 필요가 있습니다.

예를 들어

OCR
Barcode
Image Classification
Simple Text Processing

같은 작업은 Device에서 처리하고,

복잡한 Reasoning만 Cloud Model로 보내는 방식입니다.

Camera
 ↓
Vision / Local Model
 ↓
Simple?
 ├─ YES → Local Result
 │
 └─ NO → Cloud AI

이런 Architecture는

Latency
Privacy
Server Cost

를 동시에 줄일 수 있습니다.

11. HealthKit 앱도 데이터 표시에서 해석으로 넘어간다

이번 Apple Watch 발표에서 중요한 것은 Sensor 자체보다 Apple이 데이터를 해석하기 시작했다는 점입니다.

기존 HealthKit 앱은 대부분

HealthKit
 ↓
Data
 ↓
Chart

구조였습니다.

하지만 앞으로 사용자는

그래서 이 데이터가 무슨 의미인가?

까지 기대하게 됩니다.

따라서

HealthKit
 ↓
Historical Data
 ↓
Personal Baseline
 ↓
Analysis
 ↓
Insight

구조가 더 중요해질 가능성이 높습니다.

이번 발표 이후 기존 프로젝트에서 먼저 검색해볼 코드

기존 프로젝트가 있다면 개인적으로 아래부터 검색해볼 것 같습니다.

UIScreen.main

UIDevice.current.userInterfaceIdiom

interfaceOrientation

그리고

.frame(width:)

같은 고정 Width 코드도 확인해볼 필요가 있습니다.

Navigation에서는

Tab Bar가 항상 최선인가?

넓은 환경에서 Sidebar가 더 적합하지 않은가?

NavigationSplitView로 확장할 수 없는가?

중요한 Tab을 prominentTabIdentifier로 지정할 필요는 없는가?

를 검토해볼 수 있습니다.

마치며

이번 Apple Event의 가장 화려한 제품은 분명 iPhone Duo입니다.

하지만 개발자 입장에서 iPhone Duo의 의미는 단순히

“Apple도 폴더블을 만들었다.”

가 아닙니다.

진짜 변화는 iPhone 앱의 UI 구조 자체가 달라질 수 있다는 것입니다.

예전에는

iPhone
 ↓
Tab Bar
 ↓
NavigationStack

정도가 가장 일반적인 구조였다면,

앞으로는

Compact
   ↓
Tab Bar
   ↓
NavigationStack

과

Expanded
   ↓
Sidebar
   ↓
Split Navigation

을 하나의 앱 안에서 함께 생각해야 합니다.

즉 iPhone Duo의 핵심 개발자 변화는

화면이 커졌다는 것이 아니라, iPhone에서도 Sidebar와 Split Navigation이 본격적인 선택지가 됐다는 것

이라고 볼 수 있습니다.

그리고 여기에

Adaptive UI
App Intents
On-device AI
Live Activity
Health Data Interpretation

이 연결됩니다.

이번 Apple Event는 하드웨어 발표처럼 보이지만,

개발자 입장에서는 결국 한 가지 질문으로 이어집니다.

이제 우리 앱도 화면 크기만 바꾸는 것이 아니라, 화면이 넓어졌을 때 Navigation과 Information Architecture 자체를 바꿀 준비가 되어 있는가?

2026년 iOS 개발에서 꽤 중요한 체크포인트가 될 것 같습니다.

PR도 Agent가 끝낸다: Agent Merge 이후의 개발 워크플로우

Tue, 08 Sep 2026 21:32:01 GMT

PR도 Agent가 끝낸다: Agent Merge 이후의 개발 워크플로우

AI Coding Agent의 역할은 지금까지 주로 Pull Request를 만드는 것에 집중돼 있었다.

Issue
  ↓
Agent
  ↓
Repository 조사
  ↓
구현
  ↓
Test
  ↓
Pull Request
  ↓
Human Review

그런데 실제 개발에서는 PR을 만드는 순간 일이 끝나지 않는다.

오히려 그다음부터 일이 시작되는 경우가 많다.

Reviewer Comment 7개

CI 2개 실패

base branch 변경

Merge Conflict 발생

수정 후 다시 CI

새로운 Review Comment

또 수정

작은 기능 하나라도 PR이 Merge되기까지 몇 시간에서 며칠이 걸린다.

2026년 9월 2일 공개된 VS Code 1.136에는 이 마지막 구간을 Agent에게 맡기는 Agent Merge Preview가 추가됐다. VS Code는 Agent Merge를 “PR을 merge-ready 상태까지 가져가는 기능”으로 설명한다. Agent가 Review Feedback을 처리하고, Required CI 실패를 수정하고, Base Branch와 충돌하면 최신 상태로 맞추고 Merge Conflict를 해결한 뒤 필요한 Workflow를 다시 실행한다. 이 과정을 PR이 Merge 가능한 상태가 될 때까지 반복한다.

이건 생각보다 큰 변화다.

Coding Agent가:

코드를 만드는 Agent

에서:

Software Change를 끝내는 Agent

로 이동하고 있기 때문이다.

1. 개발에서 가장 긴 시간은 코딩이 아닐 수도 있다

예를 들어 Feature 구현 자체는 Agent가 20분 만에 끝냈다고 하자.

하지만 실제 흐름은 이렇게 된다.

20분
구현

↓

15분
CI

↓

2시간
Reviewer 확인 대기

↓

Review Comment

↓

20분
수정

↓

15분
CI

↓

Base Branch 변경

↓

Conflict

↓

다시 수정

↓

다시 Review

코드 작성 시간은 전체 Lead Time의 일부일 뿐이다.

AI Coding Agent가 구현 속도를 크게 올리면 오히려 새로운 병목이 생긴다.

Coding Throughput
↑↑↑

PR Merge Throughput
→

Agent는 PR을 빠르게 만들어내는데 사람이 Review하고 CI 실패를 정리하고 Conflict를 처리하는 속도는 그대로인 것이다.

Agent Merge는 정확히 이 지점을 노린다.

2. Agent Merge가 실제로 하는 일

현재 VS Code Agent Merge가 처리할 수 있는 영역은 크게 네 가지다.

Review Feedback

Failed Required Checks

Merge Conflicts

Final Merge / Merge Queue

구체적으로는 PR에서 해결되지 않은 Review Thread, changes requested Review, Repository Maintainer나 Copilot Reviewer가 남긴 새로운 Comment를 Agent가 읽고 대응할 수 있다. Required CI Check가 실패하면 원인을 조사해 수정하고 Workflow를 다시 실행할 수 있으며, Branch가 Base Branch보다 뒤처지면 업데이트하고 Conflict를 해결할 수도 있다. 설정에 따라 마지막 Merge 또는 Merge Queue 등록까지 가능하다.

즉 기존 구조:

Agent
  ↓
PR
  ↓
사람
  ↓
Review 대응
  ↓
CI 대응
  ↓
Conflict 해결
  ↓
Merge

가:

Agent
  ↓
PR
  ↓
Agent Merge
  │
  ├─ Review 대응
  ├─ CI 수정
  ├─ Conflict 해결
  ├─ Workflow 재실행
  └─ Merge-ready 확인
  ↓
Human Gate
  ↓
Merge

로 바뀐다.

3. 사실 완전히 새로운 기능 하나가 갑자기 생긴 것은 아니다

VS Code에서는 이전부터 PR의 Failed CI를 확인하고 Agent에게 Fix Checks를 요청하거나 새 Review Comment를 Address Comments로 넘기는 흐름이 발전해왔다.

1.136의 Agent Merge는 이 각각의 작업을 지속적인 Loop로 묶었다는 점이 중요하다.

예전:

CI 실패
→ 사람이 Fix Checks 클릭

Comment 도착
→ 사람이 Address Comments 클릭

Conflict 발생
→ 사람이 다시 Agent 호출

지금:

Agent Merge ON
       ↓
PR 상태 감시
       ↓
Blocker 발생
       ↓
Agent 실행
       ↓
수정
       ↓
Push
       ↓
Check
       ↓
새 Blocker?
       │
      YES
       ↓
다시 처리

Agent가 PR 상태를 지속적으로 관리하는 Worker가 된 것이다.

4. PR 자체가 하나의 장기 실행 Task가 된다

기존 Agent Task:

"로그인 버그 수정해."

Agent Merge 이후에는 실제 Task Boundary가 더 길어진다.

로그인 버그 수정

↓

PR 생성

↓

Reviewer 요청 반영

↓

CI 안정화

↓

Base Branch 최신화

↓

Conflict 해결

↓

최종 Required Checks 통과

이 전체가 하나의 작업이 된다.

즉 Agent가 다루는 단위가:

Code Change

에서:

Pull Request Lifecycle

로 올라간다.

그리고 이 변화는 상당히 중요하다.

5. 실제로 VS Code에서 사용하는 방법

현재 Agent Merge는 Preview 기능이다.

먼저 설정에서 활성화한다.

{
  "chat.agentMerge.enabled": true
}

PR과 연결된 Agent Session을 연 뒤 Agents Window에서 Agent Merge를 활성화한다.

Command Palette에서는:

Enable Agent Merge for Active Session

또는:

Configure Agent Merge for Active Session

을 사용할 수 있다.

Agent Merge 메뉴에서는 어느 작업까지 Agent에게 허용할지도 정할 수 있다.

6. 설정을 보면 Agent Merge의 설계가 더 잘 보인다

현재 관련 주요 설정은 다음과 같다.

{
  "chat.agentMerge.enabled": true,

  "chat.agentMerge.addressReviews": true,

  "chat.agentMerge.fixCI": true,

  "chat.agentMerge.resolveConflicts": true,

  "chat.agentMerge.mergePullRequest": "never",

  "chat.agentMerge.mergeMethod": "auto",

  "chat.agentMerge.replyAttribution": true
}

여기서 특히 중요한 것이:

mergePullRequest

다.

현재 선택지는:

always

ifUnchanged

never

다.

개발팀에서 처음 도입한다면 never부터 시작하는 편이 좋다.

Agent
→ Merge-ready까지

Human
→ 실제 Merge

경계를 유지하는 것이다.

7. 왜 처음부터 자동 Merge까지 켜지 않는 게 좋을까

Agent가 다음을 해결했다고 하자.

Review Comment
PASS

CI
PASS

Merge Conflict
해결

Required Checks
PASS

그러면 안전할까?

반드시 그렇지는 않다.

예를 들어 CI를 고친 방법이:

깨지는 테스트의 assertion 수정

일 수도 있다.

Reviewer의 Comment를 해결한 방법이:

원래 의도와 다른 우회 구현

일 수도 있다.

Conflict를 해결하면서:

Base Branch의 중요한 변경 삭제

가 발생할 수도 있다.

기계적으로는 모두 PASS인데 제품은 틀릴 수 있다.

8. Agent Merge에서 가장 위험한 것은 ‘Green 만들기’다

Agent에게:

PR을 Merge 가능한 상태로 만들어.

라는 Goal을 주면 모델은 자연스럽게:

Green CI

를 목표로 삼는다.

그런데:

Green CI
=
Correct Software

는 아니다.

대표적으로 이런 문제가 있다.

Test FAIL

↓

Agent

↓

Product Code 수정

이면 괜찮을 수 있다.

하지만:

Test FAIL

↓

Agent

↓

Test Expectation 수정

↓

PASS

라면 반드시 확인해야 한다.

9. 테스트 코드는 Specification이 될 수 있다

예를 들어 원래 요구사항이:

인증되지 않은 사용자는
HTTP 401을 받아야 한다.

라고 하자.

Test:

expect(response.status).toBe(401)

그런데 실제 구현이 403을 반환한다.

Agent Merge가 CI를 통과시키기 위해:

expect(response.status).toBe(403)

으로 바꿨다.

CI는 Green이다.

하지만 요구사항은 깨졌다.

이런 변경은:

CI Repair

가 아니라:

Specification Change

다.

둘을 반드시 분리해야 한다.

10. 그래서 Agent Merge에도 권한 경계가 필요하다

추천하는 정책은 이렇다.

자동 허용

Formatting

Lint 수정

명백한 Compile Error

단순 Import

Reviewer가 구체적으로 요구한 작은 수정

Mechanical Merge Conflict

확인 후 진행

Test Assertion 변경

Public API 변경

새 Dependency

Database Schema

Architecture 변경

Security 관련 코드

Auth / Payment

사람이 결정

요구사항 변경

보안 정책 변경

Production Migration

Test 삭제

Required Check 제거

Branch Protection 변경

즉 Agent Merge를 켠다고 Agent에게 PR에 관한 모든 결정 권한을 넘기는 것은 아니다.

11. Merge Conflict도 생각보다 위험하다

Conflict 해결은 Agent에게 굉장히 잘 맞는 작업처럼 보인다.

예:

<<<<<<< feature

새 구현

=======

main의 새 구현

>>>>>>> main

하지만 Conflict는 단순 문자열 충돌이 아니다.

두 Branch 모두 올바른 변경일 수 있다.

예:

feature
→ 새로운 Cache

main
→ Race Condition 수정

Agent가:

feature쪽 선택

해서 Conflict Marker를 없애면 Git은 정상이다.

하지만 main의 Race Condition 수정이 사라질 수 있다.

12. 좋은 Conflict Resolution은 ‘둘 다 이해’해야 한다

따라서 Agent에게:

Conflict marker 없애.

가 아니라:

Base branch의 변경 목적과
feature branch의 변경 목적을 모두 확인하고
두 요구사항을 보존하는 방향으로 해결해.

라고 해야 한다.

특히 다음 파일은 Conflict 자동 해결 Risk를 높게 보는 편이 좋다.

Authentication

Database

Concurrency

Build Configuration

Dependency Lock

Infrastructure

Security Policy

13. Agent Merge를 ‘PR 유지보수 Agent’로 보는 게 가장 정확하다

Agent Merge를:

Automatic Merger

라고 생각하는 것보다:

PR Maintenance Agent

라고 생각하면 이해하기 쉽다.

주요 역할:

Review Follow-up

CI Repair

Branch Sync

Conflict Resolution

Workflow Retry

이다.

즉 사람이 PR을 만든 뒤 매번 들어가서 관리하던 잔업을 Agent가 맡는다.

14. 개발자가 가장 자주 하는 PR 잔업이 사라질 수 있다

실제로 이런 상황이 많다.

Reviewer:

여기 optional 처리해주세요.

개발자:

수정
commit
push

30분 뒤 CI:

lint failure

개발자:

다시 수정
push

그 사이 main 변경:

branch behind

개발자:

pull
resolve
push

새 Review:

이 Test도 추가해주세요.

다시 개발자가 들어간다.

이 과정 하나하나는 어렵지 않다.

문제는 Attention을 계속 끊는다는 것이다.

15. Agent Merge의 진짜 가치는 Context Switching 감소다

개발자에게 PR 하나는 끝난 작업처럼 보여도 머릿속에는 계속 남는다.

PR #128
CI 기다리는 중

PR #131
Reviewer 답변 기다림

PR #133
Conflict 발생

PR #135
새 Comment

그러면 개발자는 다음 Feature를 개발하면서도 계속 Notification을 확인한다.

Agent Merge가 제대로 동작하면:

PR #128
Agent가 CI 처리

PR #131
Agent가 Comment 대응

PR #133
Agent가 Conflict 조사

가 된다.

사람은:

Decision Needed

Risk High

Merge Ready

일 때만 돌아오면 된다.

이게 훨씬 큰 생산성 변화일 수 있다.

16. 좋은 Agent는 모든 Comment를 무조건 받아들이면 안 된다

Reviewer가:

이거 Singleton으로 바꾸는 게 좋겠습니다.

라고 Comment를 남겼다고 하자.

Agent가 곧바로:

Singleton으로 변경

하면 안 될 수도 있다.

왜냐하면 Repository Architecture에서는 Singleton을 금지하고 있을 수 있기 때문이다.

좋은 Agent의 행동은:

Review Comment
      ↓
Repository Rule
      ↓
Architecture Context
      ↓
충돌?
   │       │
  NO      YES
   │       │
   ▼       ▼
수정    Decision Needed

이다.

즉 Comment는 명령이 아니라 입력이다.

17. 그래서 AGENTS.md와 Review Skill이 더 중요해진다

예를 들어 Repository에:

# Review Rules

- Singleton 추가 금지
- Public API 변경은 확인 필요
- 새로운 외부 Dependency는 자동 추가하지 않는다
- Test assertion 변경은 요구사항을 확인한다
- 기존 Security validation을 제거하지 않는다

가 있다면 Agent Merge도 이 기준을 따라야 한다.

Agent가 강해질수록 Repository의 규칙이 더 중요해진다.

18. PR Description도 Agent의 Context가 된다

좋은 PR에는 단순 변경 목록만 있는 것이 아니라:

왜 바꿨는가

무엇을 바꿨는가

무엇은 바꾸지 않았는가

어떻게 검증했는가

가 있어야 한다.

예:

## 목표

로그인 중 중복 요청 문제 해결.

## 원인

Loading 상태 반영 전에
버튼을 다시 누를 수 있었음.

## 변경

요청 시작 즉시 버튼을 disabled 처리.

## 변경하지 않은 것

Authentication API
Retry Policy

## 검증

Unit Test
E2E Login Flow

이 정보가 있으면 이후 Agent가 Reviewer Comment나 CI Failure를 처리할 때 원래 Goal을 잃을 가능성이 줄어든다.

19. Agent Merge는 ‘원래 Goal’을 계속 보존해야 한다

PR Lifecycle이 길어질수록 Agent가 원래 문제를 잊을 가능성이 있다.

예:

Goal
중복 Login Request 방지

그런데 세 번 수정하고 Conflict까지 해결한 뒤:

현재 코드
Login Button 항상 disabled

가 되어버릴 수도 있다.

CI만 보면 통과할 수 있다.

따라서 각 Repair Cycle마다:

Original Goal

Acceptance Criteria

Current Diff

New Blocker

를 같이 봐야 한다.

20. Review Feedback도 등급을 나누는 게 좋다

모든 Comment가 동일하지 않다.

예:

CRITICAL

Security
Data Loss
Incorrect Authorization

MAJOR

Logic Bug
Concurrency
Architecture
Regression

MINOR

Naming
Formatting
Small Refactor

Agent Merge가 처리할 때도:

MINOR
→ 자동

MAJOR
→ 수정 후 재검증

CRITICAL
→ Human Notify

처럼 다르게 가져갈 수 있다.

21. GitHub의 기존 보호장치를 없애면 안 된다

Agent Merge가 강해져도 GitHub Ruleset이나 Branch Protection이 더 중요해진다.

GitHub는 Protected Branch에서:

Pull Request Review
Required Status Checks
Conversation Resolution
Merge Queue
성공한 Deployment
Signed Commit
Force Push 제한

같은 조건을 강제할 수 있다.

즉:

Agent

를 신뢰하는 것이 아니라:

Agent
+
Repository Policy

를 신뢰하는 것이다.

22. 추천 Architecture는 이렇다

                    Feature / Bug
                         │
                         ▼
                    Coding Agent
                         │
                         ▼
                     Pull Request
                         │
                         ▼
                  Independent Review
                         │
                         ▼
                    Agent Merge
                         │
            ┌────────────┼────────────┐
            ▼            ▼            ▼
        Comments       CI Fail      Conflict
            │            │            │
            └────────────┼────────────┘
                         ▼
                     Agent Fix
                         │
                         ▼
                   Build / Tests
                         │
                         ▼
                    Re-review
                         │
                         ▼
                  GitHub Ruleset
                         │
                         ▼
                    Merge Queue
                         │
                         ▼
                     Human Gate
                         │
                         ▼
                       main

핵심은 Agent Merge가 GitHub Ruleset보다 위에 있지 않다는 것이다.

23. CI는 Agent의 상사가 되어야 한다

Agent가:

완료했습니다.

라고 해도 CI가 실패하면 완료가 아니다.

Agent Opinion
    ↓

상관없음

CI Result
    ↓

실제 Gate

라는 구조가 좋다.

Required Status Check를 Protected Branch에 설정하면 해당 Check가 통과해야 Merge할 수 있다.

Agent Merge 역시 Required Check가 Pending이면 기다리고, 실제 Merge 직전에 PR이 Ready 상태인지 다시 확인한다.

24. Security Check 역시 Required로 만드는 편이 좋다

예:

Unit Test

Integration Test

Lint

CodeQL

Dependency Review

Secret Scan

등을 Required Check로 둔다.

GitHub Ruleset은 Status Check뿐 아니라 Code Scanning 결과 등도 Merge 조건으로 사용할 수 있다.

그러면 Agent가:

Security Warning 무시하고 Merge

하기 어렵다.

25. Code Owner도 여전히 중요하다

예를 들어:

/auth/**
→ Security Team

/payment/**
→ Payment Team

/database/**
→ Backend Lead

처럼 특정 영역을 CODEOWNERS로 관리할 수 있다.

Agent가 Review Comment를 전부 해결하더라도:

Security Code Owner Approval

이 없으면 Merge되지 않게 할 수 있다.

Agent가 강해질수록 권한 경계가 더 중요해진다.

26. Copilot Review까지 완전히 자동화할 수도 있지만 주의가 필요하다

GitHub Copilot은 현재 PR Code Review를 수행하고 Severity 기반 Comment를 남길 수 있다. 기본적으로 Copilot Review는 Required Approval로 계산되지 않지만, 현재 Public Preview인 Copilot Approvals를 별도로 활성화하면 Repository의 Required Approval을 만족시키도록 구성할 수도 있다.

기술적으로는:

Coding Agent
     ↓
Copilot Review
     ↓
Agent Merge
     ↓
Copilot Approval
     ↓
Merge

처럼 거의 사람 없는 Flow도 가능해지고 있다.

하지만 모든 Repository에서 이걸 기본값으로 두는 것은 권하지 않는다.

27. 작성 Agent와 Reviewer가 같은 실패를 공유할 수 있기 때문이다

예를 들어 요구사항을 Agent가 잘못 이해했다.

Requirement
A

Agent 이해
B

Agent는 B를 구현한다.

AI Reviewer도 B라는 구현 자체는 훌륭하다고 평가한다.

Implementation
PASS

Architecture
PASS

Tests
PASS

하지만 실제 Product Requirement는 A다.

즉:

Wrong Requirement Interpretation
+
Good Implementation
+
Good AI Review
=
Wrong Software

가 가능하다.

그래서 고위험 변경에서는 사람의 Product/Architecture 판단이 여전히 필요하다.

28. 추천하는 도입 단계는 네 단계다

1단계 — Agent Merge는 관찰만

Review Feedback
CI Failure
Conflict

를 보고 어떤 행동을 할지 확인한다.

실제 Merge는 사람.

2단계 — 유지보수 자동화

addressReviews = true
fixCI = true
resolveConflicts = true

mergePullRequest = never

로 사용한다.

개인 프로젝트에서도 가장 현실적인 시작점이다.

3단계 — Low Risk PR 자동 Merge

예:

Documentation

Tests

Formatting

Dependency Patch

Internal Refactor

같은 변경만 자동 Merge 후보로 둔다.

4단계 — Risk-based Merge

LOW
→ Agent Merge 가능

MEDIUM
→ AI Review + Required Checks

HIGH
→ Code Owner + Human

CRITICAL
→ 자동 Merge 금지

로 발전시킨다.

29. `ifUnchanged` 옵션이 흥미로운 이유

Agent Merge 설정에는:

always

ifUnchanged

never

가 있다.

특히 ifUnchanged는 꽤 좋은 안전 장치다.

의미를 단순화하면:

Agent가 Repair를 위해
PR을 실제로 변경하지 않았다면

→ Merge 가능

하지만 Agent가 Repair Turn에서 코드를 변경했다면:

→ 자동 Merge하지 않음

으로 운영할 수 있다.

즉:

기존 PR 그대로 모든 Check PASS

와:

Agent가 방금 새 코드를 수정한 PR

을 동일하게 취급하지 않는 것이다.

실무적으로 꽤 합리적인 구분이다.

30. PR 수정 후 독립 Re-review를 넣는 게 좋다

가장 추천하는 구조는:

Human / AI Review
       ↓
Finding
       ↓
Agent Merge Fix
       ↓
새 Commit
       ↓
Independent Re-review

다.

특히:

Auth

Payment

Data

Concurrency

Infrastructure

같은 변경이라면 필수에 가깝다.

왜냐하면 Review Comment 하나를 해결하면서 다른 Bug를 만들 수 있기 때문이다.

31. Claude를 독립 Reviewer로 넣는 구조도 가능하다

최근 다뤘던 멀티에이전트 구조를 응용하면:

Codex
→ 구현

Claude
→ Review

Agent Merge
→ CI / Comment / Conflict 처리

Claude
→ Re-review

Runtime QA
→ 실제 검증

처럼 가져갈 수 있다.

중요한 것은 특정 모델 조합이 아니다.

작성

검토

수정

재검토

의 Context를 분리하는 것이다.

32. QA는 Merge 전에 한 번 더 필요하다

CI가 모두 Green이어도 UX가 깨질 수 있다.

Web이라면:

Playwright

Browser

Screenshot

Video

Console

Network

으로 Runtime QA를 할 수 있다.

iOS:

Simulator

Accessibility

Recording

Runtime Log

Android:

Emulator

Semantics

Logcat

같은 검증을 추가할 수 있다.

즉:

PR Ready

와:

Product Ready

를 구분한다.

33. Merge Queue와 Agent Merge는 상당히 잘 맞는다

GitHub Merge Queue는 여러 PR이 동시에 main으로 들어가는 환경에서 각 PR을 최신 Base 상태와 함께 검사하고 순서대로 Merge하도록 설계돼 있다.

Agent Merge가:

PR을 Merge-ready 상태까지 유지

하고,

Merge Queue가:

최신 main과 함께 최종 검증

을 하는 구조다.

Agent Merge
     ↓
Merge-ready
     ↓
Merge Queue
     ↓
Latest Base Integration
     ↓
Required Checks
     ↓
Merge

Agent가 많아져 PR 생성량이 늘수록 이런 구조의 가치가 커진다.

34. 결국 Agent Merge는 ‘Self-healing PR’에 가깝다

앞으로 PR은 정적인 변경 묶음이 아니라 조금 다른 형태가 될 수 있다.

PR 생성
  ↓
환경 변화
  ↓
스스로 수정
  ↓
Feedback 반영
  ↓
CI 복구
  ↓
Base Branch 동기화
  ↓
다시 검증

일종의:

Self-maintaining Change

다.

이건 상당히 큰 변화다.

35. 하지만 Self-healing과 Self-correcting은 다르다

Agent가:

Test를 Green으로 만들었다.

고 해서:

제품을 올바르게 만들었다.

는 뜻은 아니다.

Agent Merge는:

Operational Blocker

를 잘 처리할 수 있다.

그러나:

Product Intent
Architecture Trade-off
Security Risk Acceptance

까지 자동으로 결정하는 것은 다른 문제다.

여기에는 여전히 사람의 판단이 필요하다.

36. 그래서 가장 중요한 것은 Merge Policy다

Agent가 얼마나 똑똑한지보다:

무엇을 Agent에게 맡길 것인가?

를 정하는 것이 중요하다.

예를 들어:

agent_merge:

  review_feedback:
    auto: true

  ci_failure:
    auto: true

  merge_conflict:
    auto: true

  test_expectation_change:
    approval: required

  dependency_addition:
    approval: required

  auth_change:
    human_review: required

  production_config:
    auto_merge: false

이런 Policy가 있으면 Agent가 바뀌어도 Workflow는 유지된다.

37. 개인 개발자에게도 꽤 유용하다

혼자 개발하면 이런 일이 많다.

PR 만들었는데

CI 하나 깨짐

↓

나중에 고쳐야지

다른 작업 시작.

몇 시간 뒤:

아 맞다.

다시 돌아온다.

Agent Merge가 있으면:

PR
↓
CI Fail
↓
Agent Fix
↓
CI
↓
Merge Ready

까지 뒤에서 진행시킬 수 있다.

개인 개발자에게도 Attention 절약 효과가 꽤 클 수 있다.

38. 여러 Agent를 쓰면 더 중요해진다

Agent 1:

Feature A PR

Agent 2:

Bug Fix PR

Agent 3:

Refactor PR

가 동시에 생겼다고 하자.

이제 사람에게:

PR 3개 관리

업무가 생긴다.

그런데 각 PR마다 Agent Merge가 붙으면:

PR A → Agent 유지관리

PR B → Agent 유지관리

PR C → Agent 유지관리

를 할 수 있다.

사람은:

Needs Decision

Security Risk

Merge Ready

만 보는 방향으로 갈 수 있다.

39. Multi-Agent의 진짜 병목을 건드리는 기능이다

멀티에이전트가 발전하면서 가장 먼저 발생하는 문제가 있다.

Agent 생성 속도
>
Human 처리 속도

이다.

Agent Merge는 이것을:

Agent 생성

+

Agent 유지관리

로 확장한다.

즉 Agent가 만들어낸 PR을 다른 단계의 Agent가 끝까지 돌보는 구조다.

이게 Engineering Agent 시스템에 가까워지는 이유다.

40. 앞으로 Issue부터 Merge까지 하나의 Agent Graph가 될 수 있다

결국 이런 형태가 자연스럽다.

                        Issue
                          │
                          ▼
                     Planning Agent
                          │
                          ▼
                  Implementation Agent
                          │
                          ▼
                         PR
                          │
               ┌──────────┴──────────┐
               ▼                     ▼
          Review Agent             CI
               │                     │
               └──────────┬──────────┘
                          ▼
                     Agent Merge
                          │
             ┌────────────┼────────────┐
             ▼            ▼            ▼
        Feedback Fix   CI Recovery   Conflict
             │            │            │
             └────────────┼────────────┘
                          ▼
                      Re-review
                          │
                          ▼
                      Runtime QA
                          │
                          ▼
                     Merge Queue
                          │
                          ▼
                       Human Gate
                          │
                          ▼
                         main

이제 Agent의 작업 경계가:

Issue → Code

가 아니라:

Issue → Verified Merge

까지 늘어난다.

41. 개발자의 역할 역시 한 단계 올라간다

예전 개발자는:

코드를 작성하고

CI를 보고

Review Comment를 수정하고

Conflict를 해결하고

Merge했다.

Agent 환경에서는 점점:

Goal 설정

Architecture 결정

Risk 판단

Agent Policy 설정

Exception 승인

최종 결과 Review

를 맡게 된다.

구현의 세부 작업보다 Software Change 전체의 품질을 관리하는 역할로 이동하는 것이다.

42. Agent Merge를 쓰면서 측정해볼 지표

실제 도입했다면 단순:

Agent Merge 사용 횟수

를 볼 필요는 없다.

다음이 더 중요하다.

PR Lead Time

Review → Fix Time

CI Recovery Time

Conflict Resolution Time

Human Intervention Count

Agent Repair Count

Re-review Rejection Rate

Regression Rate

특히:

Human Intervention Count

가 재미있다.

Agent Merge를 넣었는데 사람이 여전히 PR마다 열 번씩 개입해야 한다면 큰 효과가 없는 것이다.

43. 좋은 Agent Merge는 사람을 많이 부르지 않는다

예:

PR 시작

Agent Review 대응

CI 수정

Conflict 해결

CI 재실행

↓

Human

"Merge 가능"

이면 성공적이다.

반대로:

Comment 1
→ 질문

CI
→ 질문

Conflict
→ 질문

Workflow
→ 질문

이라면 단순 Automation을 복잡하게 만든 것에 가깝다.

목표는:

Agent Activity ↑

가 아니라:

Human Attention ↓

이어야 한다.

44. Agent가 직접 Merge했다면 Provenance도 남겨야 한다

앞으로는:

누가 Merge했는가?

만으로 부족할 수 있다.

어떤 Agent가

어떤 Review Comment를 해결했고

어떤 CI를 고쳤고

어떤 Conflict를 해결했으며

마지막 변경 후 어떤 Test를 실행했는가

도 중요하다.

즉 Agent Merge가 발전할수록:

Agent Provenance

의 중요성도 커진다.

PR Timeline이 일종의 Agent 작업 감사 로그가 되는 것이다.

45. GitHub의 기존 Review/Ruleset이 사라지는 게 아니다

오히려 반대다.

Agent가 더 많은 변경을 만들수록:

Protected Branch

Required Review

Required Checks

Ruleset

Code Owner

Merge Queue

같은 기존 Engineering Control이 더 중요해진다.

GitHub도 Ruleset을 이용해 PR Review, Status Check, Code Scanning 같은 조건을 병합 전에 강제할 수 있도록 제공하고 있다.

Agent는 그 조건을 통과하도록 일하는 Worker다.

조건 자체를 결정하는 존재가 아니다.

46. 제가 처음 적용한다면 이렇게 시작한다

개인 프로젝트:

{
  "chat.agentMerge.enabled": true,
  "chat.agentMerge.addressReviews": true,
  "chat.agentMerge.fixCI": true,
  "chat.agentMerge.resolveConflicts": true,
  "chat.agentMerge.mergePullRequest": "never"
}

그리고 GitHub에서는:

Required Tests

Required Build

Code Scanning

Conversation Resolution

정도만 먼저 둔다.

Agent에게는 Merge-ready까지만 맡긴다.

실제 Merge는 직접 한다.

47. 익숙해지면 Low Risk만 자동화한다

예:

docs/**

tests/**

internal tooling

formatting

dependency patch

등은 자동화 범위를 늘린다.

반면:

auth/**

payment/**

database/**

infra/**

security/**

는 계속 Human Gate를 둔다.

즉 Repository Path 자체를 Risk Signal로 사용할 수도 있다.

48. Agent Merge가 의미하는 더 큰 변화

지금까지 AI Coding 경쟁은 대부분:

누가 코드를 더 잘 만드는가?

였다.

그런데 개발자가 실제 원하는 것은 코드가 아니다.

원하는 것은:

Issue 해결

이다.

그래서 Agent의 작업 범위는 자연스럽게:

Code Generation
        ↓
Repository Modification
        ↓
Build / Test
        ↓
Pull Request
        ↓
Review Response
        ↓
CI Recovery
        ↓
Merge

로 계속 확장된다.

Agent Merge는 이 흐름에서 꽤 상징적인 기능이다.

마무리

VS Code 1.136의 Agent Merge는 표면적으로 보면 작은 기능처럼 보인다.

Review Comment 처리

CI 수정

Conflict 해결

자동 Merge

정도다.

하지만 개발 Workflow 관점에서는 의미가 훨씬 크다.

Coding Agent의 완료 지점이:

"PR 만들었습니다."

에서:

"PR이 Merge 가능한 상태입니다."

로 이동하기 때문이다.

VS Code의 현재 Agent Merge는 PR을 지속적으로 감시하면서 unresolved review feedback, required CI failure, base branch update와 merge conflict 같은 Blocker를 처리하고, 설정에 따라 Merge 또는 Merge Queue까지 이어갈 수 있다. 기능은 아직 Preview이고 Agent Merge를 활성화하면 Session이 Autopilot + Assisted permissions로 바뀌며 모델 요청도 소비하므로 자동화 범위를 확인한 뒤 켜야 한다.

그리고 여기서 가장 중요한 것은:

AI가 Merge할 수 있다.

가 아니다.

더 중요한 것은:

AI에게 무엇까지 Merge 과정에서
스스로 판단하도록 허용할 것인가?

다.

Test가 깨졌다고 Test를 바꿔도 되는가.

Reviewer 의견이 Architecture Rule과 충돌하면 무엇을 따라야 하는가.

Merge Conflict를 해결하면서 Base Branch의 중요한 수정이 사라지지 않았는가.

새 Commit이 들어온 뒤 기존 Approval은 여전히 유효한가.

이런 문제는 단순 Automation으로 해결되지 않는다.

그래서 앞으로 좋은 PR Workflow는:

Agent
+
Repository Rules
+
Independent Review
+
CI
+
Runtime QA
+
Human Gate

의 조합이 될 가능성이 높다.

Agent Merge를 도입한다고 Branch Protection이나 Required Check가 필요 없어지는 게 아니다.

오히려 GitHub는 Protected Branch와 Ruleset을 이용해 Required Review, Required Status Check, Conversation Resolution, Merge Queue, Code Scanning 등의 조건을 강제할 수 있다. Agent가 강해질수록 이런 Agent가 임의로 우회할 수 없는 결정적 규칙이 더 중요해진다.

결국 Coding Agent 시대의 PR은 정적인 코드 묶음에서 조금씩 바뀌고 있다.

PR
=
변경된 코드

가 아니라:

PR
=
계속 관찰하고
피드백을 받고
실패를 복구하고
최신 Branch와 맞추고
검증을 반복하는
살아 있는 Software Change

에 가까워진다.

그리고 앞으로 Agent 경쟁의 중요한 기준도 바뀔 것이다.

누가 PR을 가장 빨리 만드는가가 아니라, 누가 개발자의 Attention을 가장 적게 사용하면서 PR을 안전하게 Merge-ready 상태까지 가져가는가.

Agent Merge가 흥미로운 이유가 바로 여기에 있다.

AI가 코드를 쓰기 시작한 다음 단계는 AI가 자신이 만든 Software Change의 생명주기를 관리하기 시작하는 것이다.

참고 자료

Visual Studio Code 1.136 — September 2, 2026
VS Code 1.136에서 Agent Merge Preview가 공개됐다. Review Feedback, Failed Checks, Merge Conflict를 Agent가 반복 처리해 PR을 Merge-ready 상태까지 가져가는 기능과 Multi-root Agent Session 등이 함께 추가됐다.

Visual Studio Code — Agents Window / Agent Merge
Agent Merge의 실제 동작, 활성화 방법, Review·CI·Conflict 처리와 Merge Queue/자동 Merge 옵션, Autopilot 및 Permission 관련 주의사항이 설명돼 있다.

Visual Studio Code — AI Settings Reference
addressReviews, fixCI, resolveConflicts, mergePullRequest, mergeMethod, replyAttribution 등 Agent Merge의 세부 설정을 확인할 수 있다.

GitHub — Protected Branches / Rulesets
Required Review, Required Status Check, Conversation Resolution, Merge Queue, Code Scanning 같은 Repository 수준의 병합 조건을 강제할 수 있다.

GitHub — Copilot Code Review
Copilot을 PR Reviewer로 활용하고 Review Comment를 Agent에게 다시 구현시키는 Workflow를 제공한다. Copilot Approval은 별도 설정 시 Required Approval에 포함할 수 있지만 현재 Public Preview다.

핵심 참고 포인트

Agent Merge의 핵심은 단순한 자동 Merge가 아니다. PR 생성 이후의 Review 대응 → CI 복구 → Branch 동기화 → Conflict 해결 → 재검증이라는 반복적인 유지보수 업무를 Agent가 지속적으로 맡는 것이다.

실무에서는 처음부터 mergePullRequest: always로 두기보다 Review·CI·Conflict 처리는 Agent에게 맡기고 실제 Merge는 사람이 수행하는 never 구성부터 시작하는 것이 안전하다. 이후 Low Risk 변경에 한해 ifUnchanged나 Merge Queue를 단계적으로 도입할 수 있다.

그리고 Agent가 강해질수록 CI Green을 Software Correct로 착각하지 않는 것이 중요하다. Agent Merge는 PR의 운영적 Blocker를 제거하는 데 강하지만 Product Intent와 Architecture·Security 판단까지 대체하는 시스템은 아니다. Agent는 PR을 고치고, Repository Policy와 Test가 검증하며, 중요한 결정은 사람에게 남기는 구조가 가장 현실적이다.

MCP 다음은 MHS다: AI Agent가 실제 기계를 움직이는 시대

Tue, 08 Sep 2026 21:29:41 GMT

MCP 다음은 MHS다: AI Agent가 실제 기계를 움직이는 시대

AI Agent가 지금까지 주로 다뤄온 세계는 소프트웨어였다.

Repository
Browser
Database
Slack
GitHub
Cloud
API

Agent는 MCP나 각종 Tool API를 통해 이 소프트웨어 세계를 점점 자유롭게 움직이기 시작했다.

그런데 다음 단계는 화면 안에 있지 않다.

현미경

로봇팔

카메라

액체 처리 장비

센서

레이저

공장 장비

같은 실제 물리 장비다.

2026년 8월 27일 Anthropic은 HHMI Janelia Research Campus와 함께 개발해온 Model Hardware Standard(MHS)의 Research Preview를 공개했다.

Anthropic의 설명을 단순화하면 MHS는:

AI Agent가 서로 다른 물리 장비를 발견하고, 상태를 읽고, 조작하고, 안전 한계를 이해할 수 있도록 만드는 공통 Hardware Interface

에 가깝다.

현재는 일부 과학 연구소와 첨단 제조사에 제공되는 제한된 Research Preview이며, 안전성 평가와 운영 Best Practice를 먼저 만든 뒤 향후 Open Source할 계획이다.

흥미로운 건 이것이 단순한 “로봇용 MCP”가 아니라는 점이다.

MCP와 MHS는 서로 경쟁하는 표준이라기보다 다른 Layer에 있다.

1. MCP가 Software Tool을 열었다면 MHS는 Physical Tool을 연다

MCP가 등장하면서 Agent는 다양한 Software Tool을 표준화된 방식으로 사용할 수 있게 됐다.

AI Agent

   ↓ MCP

GitHub
Database
Browser
Filesystem
Slack
Cloud

Hardware에서도 비슷한 문제가 존재한다.

예를 들어 연구실에 다음 장비가 있다고 해보자.

Microscope
Liquid Handler
Robot Arm
Plate Reader
Camera
Temperature Controller

문제는 대부분 서로 다른 제조사 제품이라는 것이다.

각 장비마다:

Vendor SDK

독자 API

전용 프로그램

자체 Protocol

전용 Driver

별도 GUI

가 존재한다.

결국 연구실이나 공장에서 여러 장비를 연결하려면 이런 코드를 만들어야 했다.

Microscope ↔ Custom Integration

Robot Arm ↔ Custom Integration

Camera ↔ Custom Integration

Liquid Handler ↔ Custom Integration

장비가 하나 늘어날 때마다 또 연결해야 한다.

Anthropic은 이런 통합에 일반적으로 몇 주에서 몇 달까지 걸릴 수 있다고 설명한다. MHS의 목표는 장비 하나를 공통 Driver 형태로 한 번 정의하고 여러 Agent와 Workflow가 다시 사용할 수 있게 만드는 것이다. 초기 적용에서는 이런 통합 작업을 시간 또는 분 단위까지 단축한 사례가 소개됐다.

2. MHS가 해결하려는 핵심 문제는 Hardware API가 아니다

장비에 API가 있는 것만으로 Agent가 장비를 안전하게 사용할 수 있는 것은 아니다.

예를 들어 로봇팔 API가 있다고 하자.

move(x, y, z)

Agent 입장에서는 호출 방법은 알 수 있다.

하지만 중요한 정보가 빠져 있다.

이 로봇의 최대 Payload는?

Arm 자체 무게는?

현재 Gripper에 무엇이 잡혀 있나?

이 좌표에 사람이 있는가?

어디까지 움직여도 되는가?

최대 속도는?

비상 정지 상태인가?

소프트웨어에서는 호출 실패가:

Exception

정도로 끝날 수 있다.

Physical Agent에서는 잘못된 호출이:

장비 파손

샘플 손실

실험 오염

충돌

사람의 부상

으로 이어질 수 있다.

따라서 Physical AI에는 단순 API보다 훨씬 많은 Context가 필요하다.

3. MHS Driver는 장비를 Agent가 이해할 수 있는 형태로 바꾼다

Anthropic이 공개한 MHS 구조의 중심에는 표준 Driver가 있다.

Driver는 장비 고유의 API와 Agent 사이에 위치한다.

                AI Agent
                   │
                   ▼
               MHS Driver
                   │
          ┌────────┼────────┐
          ▼        ▼        ▼
        read     write    metadata
          │        │
          ▼        ▼
              Vendor API
                   │
                   ▼
                Hardware

기본 Primitive는 상당히 단순하다.

예를 들어:

read

는:

현재 온도 읽기
현재 위치 읽기
센서 값 읽기
카메라 상태 읽기

같은 동작이다.

write

는:

온도 설정
로봇 위치 변경
레이저 출력 변경
밸브 열기

같은 제어다.

단순한 Primitive를 두는 이유는 여러 장비를 하나의 Agent Workflow 안에서 연결하기 쉽기 때문이다.

4. 하지만 read/write보다 더 중요한 것이 Device Description이다

Agent에게:

set_temperature(50)

라는 Tool만 보여주는 것은 위험하다.

50이:

섭씨 50도인가?

화씨 50도인가?

이 장비가 허용하는 범위인가?

샘플이 견딜 수 있는 값인가?

알 수 없기 때문이다.

그래서 MHS Driver에는 장비의 물리적 특성을 설명하는 Tag가 들어간다.

Anthropic 설명에 따르면 사용자는 자연어로 장비 정보를 작성할 수도 있고, Agent가 사용자에게 장비에 대해 질문하면서 필요한 정보를 수집할 수도 있다.

그 결과 Reference File이 만들어진다.

여기에는 대략:

무엇을 측정할 수 있는가

무엇을 조절할 수 있는가

장비의 일반 특성

어떤 Safety Limit이 적용되는가

같은 정보가 들어간다.

개념적으로 표현하면 이런 모습이다.

device:
  type: temperature_controller

capabilities:
  read:
    - temperature

  write:
    - target_temperature

limits:
  target_temperature:
    min: 4
    max: 40

safety:
  emergency_stop: true

이건 MHS 공식 공개 Schema가 아니라 구조를 설명하기 위한 예시다. 현재 핵심 Specification은 아직 제한된 Research Preview 단계다.

5. Agent에게 Hardware Manual을 읽히는 것과는 다르다

그렇다면 그냥 PDF Manual을 Agent에게 읽히면 되지 않을까?

문제는 Manual이:

비정형

장비마다 다름

버전이 다름

현재 상태를 알 수 없음

이라는 것이다.

MHS가 하려는 것은 Manual을 AI에게 검색시키는 게 아니다.

장비의:

Capabilities

State

Control

Physical Properties

Safety Limits

를 Machine-readable Interface로 만드는 것이다.

즉:

Manual
→ 사람 중심 설명

에서:

MHS Driver
→ Agent가 동작할 수 있는 Hardware Contract

로 바뀐다.

6. MHS에서 상당히 재미있는 부분이 Shared State다

여러 장비가 같이 일하려면 Agent만 장비 상태를 알아서는 부족하다.

장비끼리 상태를 공유해야 한다.

Anthropic이 소개한 구현에서는 각 장비의:

Variables

Controls

Sensor Values

를 하나의 공유 Dictionary에 기록한다.

이 Dictionary가 Shared Memory에 존재하고 여러 프로그램이나 장비가 접근할 수 있다.

구조를 단순화하면:

Microscope ───┐
Camera ───────┤
Robot Arm ────┤
Laser ────────┼─→ Shared State
Sensor ───────┤
              │
              ▼
           AI Agent

이게 중요한 이유가 있다.

7. Agent가 모든 상태를 직접 Polling할 필요가 없어진다

예를 들어 Camera가 Laser 위치를 측정한다.

Camera
→ beam_x = 128
→ beam_y = 245

Mirror Controller는 이 값을 보고 거울을 움직인다.

기존에는:

Camera API
↓
Custom Adapter
↓
Controller Program
↓
Mirror API

를 별도로 만들어야 했다.

공유 상태를 이용하면:

Camera
     ↓
Shared State
     ↓
Agent / Controller
     ↓
Mirror

형태가 된다.

새 장비가 들어와도 다른 장비와 Point-to-point Integration을 계속 만들 필요가 줄어든다.

8. Hardware Integration 비용의 구조 자체를 바꾸려는 것이다

장비가 세 개라면 연결 수가 적다.

하지만 장비가 계속 늘어나면 문제가 커진다.

A ↔ B
A ↔ C
A ↔ D
B ↔ C
B ↔ D
C ↔ D
...

MHS의 방향은:

Device A ─┐
Device B ─┤
Device C ─┼─→ Standard Interface
Device D ─┤
Device E ─┘

다.

즉 장비 하나를 추가할 때 전체 시스템을 다시 연결하는 대신 그 장비를 한 번 MHS에 연결하는 것에 집중한다.

Anthropic이 Hardware Integration 시간이 몇 주에서 시간·분 단위로 줄 수 있다고 강조하는 이유도 이 구조 때문이다.

9. 그렇다면 MCP와 MHS는 정확히 어떻게 연결될까

가장 헷갈리기 쉬운 부분이다.

MCP
vs
MHS

가 아니다.

MHS가 Physical Hardware를 표준화하고,

MCP는 Agent가 그것을 사용하는 접근 방식 중 하나가 될 수 있다.

Anthropic이 현재 공개한 MHS Control Mechanism은 세 가지다.

MCP

CLI

Code Files / API

즉:

Claude / GPT / 다른 Agent
             │
             ▼
            MCP
             │
             ▼
         MHS Driver
             │
             ▼
        Physical Device

도 가능하고,

Agent
  │
  ▼
CLI
  │
  ▼
MHS Driver

도 가능하다.

10. 그래서 MHS는 Model-agnostic이다

이름 때문에:

Claude 전용 Hardware Protocol

처럼 느껴질 수 있지만 그렇지 않다.

Anthropic은 MHS가 model-agnostic이고 일반적인 Agent Harness가 MCP 같은 표준 Protocol을 통해 접근할 수 있다고 설명한다.

즉 구조적으로는:

Claude
GPT
Gemini
Local Model
Other Agent
       │
       ▼
     MHS
       │
       ▼
   Hardware

를 목표로 한다.

이 점에서는 MCP가 가져온 방향과 꽤 비슷하다.

11. 그런데 Physical Agent에서는 MCP 호출만 반복하면 느릴 수도 있다

여기서 재미있는 문제가 하나 생긴다.

예를 들어 Laser를 미세 조정해야 한다.

값 읽기
↓
생각
↓
조금 이동
↓
값 읽기
↓
생각
↓
조금 이동
↓
값 읽기

이 작업을 LLM이 매번 추론하면서 수행하면 느리다.

Hardware는 밀리초 단위의 제어가 필요할 수도 있다.

그래서 MHS에는 Code File이라는 방식이 중요해진다.

12. Agent는 ‘생각’을 Code로 압축할 수 있다

Anthropic이 공개한 Laser Alignment 사례가 아주 재미있다.

처음 Claude는 사람처럼 탐색했다.

Laser 조절
↓
Camera 확인
↓
Beam 위치 관찰
↓
다시 조절
↓
다시 관찰

여러 번 반복하면서 관계를 파악했다.

그런데 충분히 이해한 뒤에는 그 행동을 Deterministic Script로 만들었다.

즉:

Agent Reasoning
        ↓
패턴 학습
        ↓
Code 생성
        ↓
Deterministic Controller

로 바뀐다.

이게 상당히 중요한 패턴이다.

13. AI는 모든 순간 생각할 필요가 없다

예를 들어 로봇팔의 반복 작업을 생각해보자.

나쁜 구조:

LLM
↓
Move 1
↓
LLM
↓
Move 2
↓
LLM
↓
Move 3

좋은 구조는:

LLM

Goal 이해
↓
작업 계획
↓
Controller Script 생성

          ↓

Deterministic Runtime

Move
Move
Move
Sensor
Adjust

일 수 있다.

Agent는 고수준의 판단을 하고 빠르고 반복적인 Physical Control은 코드가 수행한다.

14. 이것은 Software Agent에서도 이미 보던 패턴이다

Coding Agent에서도 비슷하다.

처음에는 Agent가:

파일 찾기
grep
검색
Test
Log

를 하나씩 호출한다.

같은 작업이 반복되면:

Script
Skill
Tool

로 만든다.

Physical Agent에서도:

Exploration
↓
Understanding
↓
Automation

이 반복된다.

AI Agent가 새로운 Hardware를 사용하면서 자신의 Tool을 스스로 만들어내는 구조다.

15. QuEra 사례가 이 구조를 잘 보여준다

Anthropic이 공개한 MHS 적용 사례 중 하나가 QuEra Computing의 Quantum Computer Laser System이다.

중성 원자를 이용하는 Quantum Computer에서는 Laser Frequency를 극도로 정밀하게 유지해야 한다.

문제가 생기면 숙련된 Engineer가 여러 계측 장비를 보면서 Laser Lock을 복구해야 한다.

기존에는 사람의 복구에 약 5~10분이 걸릴 수 있었다.

QuEra는 과거에도 이 작업을 자동화하려고 했고, Laser Engineer·Software Engineer·Algorithm Specialist·Tester가 몇 달 동안 만든 Bespoke Script가 있었다.

그 Script의 성공률은 약 58퍼센트였다고 Anthropic은 설명한다.

16. MHS를 통해 Claude에게 같은 문제를 맡겼다

QuEra는 Agent에게:

Goal:
Laser를 다시 Lock한다.

Success:
첫 시도에 Lock하고
30초 동안 유지한다.

라는 목표를 줬다.

그리고 의도적으로:

Beam Block

Instrument Power Cut

Frequency Disturbance

같은 장애를 만들었다.

MHS가 Claude에게 장비를 읽고 조절할 수 있는 Interface를 제공했다.

Anthropic이 공개한 결과에서는 Agent가 만든 Controller가 Laser Lock을 99.3퍼센트의 경우 사람 개입 없이 복구했다.

상당히 인상적인 숫자다.

다만 이 결과는 Anthropic이 발표한 특정 QuEra 환경의 사례이지, MHS를 적용하면 어떤 Hardware에서든 99퍼센트 자동복구가 된다는 의미는 아니다.

17. 중요한 것은 58 → 99.3이라는 숫자보다 Recovery 방식이다

기존 Script는 Linear Workflow에 가까웠다.

Step A
↓
Step B
↓
Step C
↓
Step D

그런데 중간에 온도나 압력 같은 환경 변화가 발생하면 이전 Step이 무효가 될 수 있었다.

그러면 처음부터 다시 해야 했다.

Agent는 조금 다르게 움직일 수 있다.

현재 Sensor State 확인
↓
어디가 틀어졌는지 판단
↓
필요한 Step만 다시 실행
↓
결과 관찰
↓
다시 조정

즉 State-aware Recovery다.

Software Agent에서 최근 중요해지고 있는:

실패
→ 동일 Retry

가 아니라:

실패
→ Re-observe
→ Re-plan
→ Recovery

구조가 Physical World에서도 똑같이 등장한다.

18. MHS가 진짜 흥미로운 이유는 ‘Hardware Agentic Loop’ 때문이다

소프트웨어 Agent Loop:

Observe

↓

Reason

↓

Act

↓

Observe

↓

Recover

Hardware에서도 그대로 적용된다.

Sensor

↓

AI

↓

Actuator

↓

Physical World 변화

↓

Sensor

↓

AI

이제 Agent가 다루는 State가 파일이나 Browser DOM이 아니라 현실 세계의 상태다.

이 차이는 엄청나게 크다.

19. Software에서는 Retry 비용이 비교적 낮다

예:

Build 실패

↓

다시 Build

큰 문제가 아닐 수 있다.

Hardware에서는:

액체 50ml 투입

↓

잘못됨

↓

다시 해볼게

가 불가능할 수도 있다.

샘플은 이미 오염됐다.

또:

Robot Arm 이동

↓

충돌

↓

Retry

도 말이 안 된다.

따라서 Physical Agent에서는 Irreversible Action이라는 개념이 훨씬 중요하다.

20. 그래서 Physical Agent의 권한은 단계적으로 나누는 게 좋다

개발환경에서 Agent Permission을:

AUTO
CONFIRM
DENY

로 나누듯 Hardware도 비슷하게 설계할 수 있다.

예를 들어:

AUTO

Sensor 읽기

Camera 촬영

장비 상태 확인

낮은 위험도의 미세 조정

CONFIRM

Sample 이동

고출력 Laser 변경

Robot Arm 큰 이동

실험 조건 변경

DENY

Safety Limit 해제

Emergency Stop 비활성화

위험 구역 진입

허가되지 않은 장비 제어

이다.

이것은 MHS 공식 권한 Schema를 의미하는 것이 아니라, Physical Agent 시스템을 설계할 때 필요한 현실적인 Control Layer의 예다.

21. Safety Limit은 Prompt에만 넣으면 안 된다

가장 위험한 구조:

System Prompt:

"로봇팔을 너무 빠르게 움직이지 마."

이다.

Agent가 잘못 판단하면 끝이다.

더 좋은 구조:

Agent

↓

move(speed = 200)

↓

Hardware Safety Layer

max_speed = 80

↓

DENY

즉 안전 규칙은 Agent 바깥에서 강제되어야 한다.

Anthropic도 MHS Reference 정보에 장비의 Safety Limit이 포함되고 Driver가 Agent가 장비를 안전하게 사용할 수 있도록 물리적 Context를 제공하는 구조를 설명한다.

22. Physical AI에서는 Defense in Depth가 더 중요하다

23. Emergency Stop은 AI가 판단하면 안 된다

예를 들어 로봇이 사람에게 접근한다.

이때:

Camera
↓
LLM
↓
사람인지 판단
↓
멈출까?

같은 구조는 위험하다.

E-Stop이나 Collision Safety는:

Hardware

PLC

Safety Controller

같은 결정적 시스템이 담당해야 한다.

AI는 그보다 위 Layer에 있는 것이 좋다.

24. Physical Agent에는 Digital Twin이 거의 필수에 가까워질 수 있다

새로운 행동을 실제 기계에서 바로 실행할 필요는 없다.

25. Shadow Mode도 굉장히 유용하다

Agent에게 실제 Control 권한을 주지 않는다.

대신:

현재 상태라면
무엇을 할 것인가?

만 기록한다.

Physical Hardware
      │
      ▼
   Sensor Data
      │
      ▼
     Agent
      │
      ▼
Proposed Actions

실제 작업자는 기존 Controller가 한다.

그리고:

Agent 선택

vs

Human 선택

을 비교한다.

충분히 안정적이면 권한을 단계적으로 올린다.

26. 처음부터 Autonomous Factory를 만들 필요는 없다

Physical AI 이야기가 나오면 금방:

무인 공장

으로 가기 쉽다.

현실적인 도입 순서는 오히려:

Level 0
관찰

↓

Level 1
추천

↓

Level 2
사람 승인 후 실행

↓

Level 3
저위험 작업 자동 실행

↓

Level 4
고수준 Goal 기반 Workflow

처럼 가는 편이 안전하다.

27. MHS가 제조업에서 흥미로운 이유도 여기에 있다

공장에는 이미 수많은 자동화 Protocol이 있다.

PLC

OPC UA

ROS

Vendor SDK

Industrial Ethernet

MHS가 이 모든 것을 없애는 것은 아니다.

오히려 위에 Agent Layer를 만들려는 접근에 가깝다.

                  AI Agent
                     │
                    MHS
                     │
        ┌────────────┼─────────────┐
        ▼            ▼             ▼
      ROS 2        OPC UA       Vendor SDK
        │            │             │
        ▼            ▼             ▼
      Robot       Machine        Sensor

기존 산업제어 Protocol을 대체하기보다 Agent가 그것들을 일관된 방식으로 사용할 수 있게 하는 쪽이다.

28. 즉 MHS는 Hardware OS가 아니다

MHS가:

Robot Operating System 대체

도 아니고:

PLC 대체

도 아니다.

정확히는:

Agent가 여러 종류의 Programmable Hardware를 발견하고 이해하고 안전하게 사용하는 데 필요한 공통 Interface Layer

에 가깝다.

현재 Anthropic도 MHS가 programmable interface를 가진 장비를 대상으로 한다고 설명한다.

29. 그럼 일반 개발자가 지금 MHS를 사용할 수 있을까?

현재는 제한적이다.

2026년 9월 기준 MHS는:

Research Preview

단계다.

공식 사이트에서 신청을 받고 있으며 초기 파트너와 과학·로봇·전자·제조 분야 조직을 대상으로 테스트가 진행되고 있다.

핵심 Specification도 아직 일반 Open Source 상태는 아니다.

Anthropic은 Safety Evaluation과 Best Practice를 더 만든 뒤 Open Source할 계획이라고 밝혔다.

따라서 지금 GitHub에서:

npm install mhs

하고 시작하는 일반 개발자용 표준이라고 생각하면 아직 이르다.

30. 하지만 지금 준비할 수 있는 것은 많다

MHS 자체를 사용하지 않더라도 Physical Agent Architecture를 비슷하게 설계해볼 수 있다.

예를 들어 Raspberry Pi + Camera + Motor가 있다고 하자.

기존:

Python Script
→ GPIO

대신:

Device Adapter

read_state()
read_camera()
move_motor()
stop_motor()

처럼 Capability를 분리한다.

그리고 별도로:

limits

permissions

device_state

safety

를 정의한다.

31. 작은 Physical Agent를 만든다면 이런 구조가 좋다

physical-agent/

├── devices/
│   ├── camera/
│   ├── motor/
│   └── temperature/
│
├── manifests/
│   ├── camera.yaml
│   ├── motor.yaml
│   └── temperature.yaml
│
├── policies/
│   └── safety.yaml
│
├── simulation/
│
├── logs/
│
└── agent/

Device Manifest:

device: motor

capabilities:
  - read_position
  - move
  - stop

limits:
  position:
    min: 0
    max: 100

  speed:
    max: 20

다시 말하지만 이것은 MHS 공식 Schema가 아니라 MHS의 설계 방향을 이해하기 위한 예시다.

32. 중요한 것은 Tool 이름보다 Capability다

Agent에게:

motor_move_x_140()

같은 저수준 Tool을 무수히 노출하기보다:

readPosition
move
stop

같은 안정된 Primitive를 제공한다.

그리고 Hardware별 차이는 Adapter가 처리한다.

                  Agent
                    │
            ┌───────┼───────┐
            ▼       ▼       ▼
           read    move    stop
                    │
                    ▼
                 Adapter
                    │
        ┌───────────┼────────────┐
        ▼           ▼            ▼
      Brand A     Brand B      Brand C

장비가 바뀌어도 Agent Workflow는 크게 바뀌지 않는다.

33. Physical Agent에서도 Skill 개념이 중요해질 수 있다

예를 들어:

laser-alignment

이라는 Skill이 있다고 하자.

처음에는 Agent가 여러 번 탐색해 알아낸다.

그리고:

1. Camera 상태 확인
2. Laser Power 확인
3. Beam 위치 측정
4. Mirror 조정
5. 다시 측정
6. 오차 이하까지 반복

같은 Workflow로 정리한다.

다음부터 Agent는 처음부터 다시 추론하지 않는다.

Agent
↓
Skill
↓
Deterministic Controller

형태가 된다.

Software Agent에서 발전한 Skill 개념과 매우 비슷하다.

34. Physical Agent의 로그는 더 중요하다

Coding Agent가 잘못된 코드를 만들었다면 Git Diff를 보면 된다.

Physical Agent는 작업이 지나가면 상태가 사라질 수도 있다.

따라서:

Timestamp

Device

Previous State

Command

Requested Value

Applied Value

Sensor Result

Agent Reason

Safety Decision

같은 기록이 중요하다.

예:

{
  "time": "14:21:03",
  "device": "motor-02",
  "action": "move",
  "requested": 18,
  "applied": 18,
  "position_before": 41,
  "position_after": 59,
  "result": "success"
}

이런 Event Log가 있어야 사고가 발생했을 때 무엇이 일어났는지 확인할 수 있다.

35. Agent Provenance가 Hardware에서도 중요해진다

앞으로 질문은:

누가 Robot Arm을 움직였는가?

만으로 끝나지 않을 수 있다.

어떤 Agent가

어떤 Goal을 받고

어떤 Sensor Data를 보고

어떤 Policy Version으로

어떤 Command를 실행했고

사람이 승인했는가?

까지 필요할 수 있다.

특히:

Manufacturing

Medical

Laboratory

Warehouse

Energy

같은 환경에서는 더욱 그렇다.

36. 그래서 Physical Agent Control Plane이 필요해진다

앞으로 이런 시스템을 상상할 수 있다.

                    Agent Control Plane
                           │
          ┌────────────────┼────────────────┐
          ▼                ▼                ▼
       Identity         Permission        Tasks
          │                │                │
          └────────────────┼────────────────┘
                           ▼
                          MHS
                           │
             ┌─────────────┼─────────────┐
             ▼             ▼             ▼
          Robot         Camera        Machine

여기에서:

Agent Identity

Device Permission

Action Budget

Safety Policy

Runtime Monitoring

Human Approval

Audit Log

를 관리한다.

37. Agent에게도 ‘작업 예산’이 필요하다

Software Agent에서:

Token Budget

Retry Budget

를 두는 것처럼,

Physical Agent에는:

Motion Budget

Time Budget

Energy Budget

Sample Budget

Retry Budget

같은 것도 필요할 수 있다.

예:

같은 Hardware Action
2회 실패

↓

STOP

↓

현재 상태 다시 읽기

↓

Human Notify

같은 정책이다.

앞서 Software QA Agent에서도 중요한 원칙이었던:

Retry

보다:

Re-observation

이 Hardware에서는 훨씬 더 중요하다.

38. Hardware Error Recovery는 AI Agent가 잘할 가능성이 있는 영역이다

전통 Automation은:

Error Code 103
→ Procedure 103 실행

형태가 많다.

하지만 실제 Hardware Failure는 복합적이다.

Sensor 변화

Temperature 변화

Motor 상태

Camera 결과

Power 상태

를 함께 봐야 할 수 있다.

Agent가 여러 상태를 종합해서:

가능성 A

가능성 B

가능성 C

를 판단하고 안전 범위 안에서 실험적으로 확인할 수 있다.

QuEra의 Laser 사례도 이 가능성을 보여준다.

39. 하지만 LLM의 Physical Intuition은 아직 제한적이다

이 부분은 반드시 같이 봐야 한다.

Anthropic도 이번 Research Preview를 바로 공개 표준으로 내놓지 않는 이유 중 하나로 AI Model이 실제 물리 세계를 충분히 이해하지 못한다는 점을 언급하고 있다.

텍스트와 이미지로 학습한 모델에게:

물체 질량

마찰

관성

기계 Backlash

Sensor Noise

온도 지연

Material Failure

같은 실제 물리현상은 매우 어렵다.

그래서 먼저 제한된 파트너 환경에서 Safety Evaluation과 Best Practice를 만들겠다는 것이다.

40. Physical AI에서는 ‘모델이 똑똑해질 때까지 기다린다’도 답은 아니다

모델이 모든 물리 현상을 이해하게 만드는 것만 기다릴 필요는 없다.

더 좋은 Architecture는:

AI

+

Sensors

+

Deterministic Controller

+

Physical Constraints

+

Safety Interlock

+

Simulation

+

Human

이다.

모델의 약점을 시스템으로 보완한다.

이건 최근 Software Agent Architecture와도 같은 방향이다.

41. MCP에서 배운 가장 중요한 교훈도 같다

MCP가 성공적으로 확산된 이유 중 하나는:

모든 Tool을 모델에 직접 구현

하지 않고:

Agent

↕

Standard Interface

↕

Tool

로 분리했기 때문이다.

MHS도 비슷한 질문을 Hardware에 던지고 있다.

Agent마다

Robot Driver를 만들 것인가?

아니면:

Hardware를 한 번 표준화해서

여러 Agent가 사용할 것인가?

이다.

42. 그래서 ‘MCP 다음은 MHS’라는 표현은 절반만 맞다

시간 순서상으로는 자연스럽다.

하지만 기술적으로:

MCP → MHS로 교체

되는 것은 아니다.

더 정확하게는:

                    AI Agent
                       │
              ┌────────┴────────┐
              ▼                 ▼
             MCP               CLI
              │                 │
              └────────┬────────┘
                       ▼
                      MHS
                       │
                       ▼
                    Hardware

같은 구조가 가능하다.

MHS는 MCP를 밀어내는 것이 아니라 Physical Hardware를 MCP가 접근할 수 있는 새로운 Layer로 만드는 쪽에 가깝다.

43. MHS가 열리면 개발자의 범위도 넓어질 수 있다

지금 Agent 개발이라고 하면:

Web

Backend

Cloud

Coding Agent

가 중심이다.

앞으로는:

Robotics

Smart Factory

Smart Home

Lab Automation

Warehouse

Agriculture

Energy

Medical Devices

쪽에서도 Agent Application이 크게 늘 수 있다.

특히 Software Developer가 과거에는 접근하기 어려웠던 Hardware System에 들어갈 진입 장벽을 줄일 가능성이 있다.

44. 개인 개발자에게 가장 가까운 분야는 Smart Home과 Robotics일 수 있다

예:

Agent

↓

Camera

Temperature Sensor

Robot

Matter Device

Home Assistant

를 연결한다.

다만 소비자 IoT와 MHS가 직접 연결된다고 발표된 것은 아니다.

여기서 중요한 것은 MHS가 제시하는 Architecture Pattern이다.

Hardware Capability Description

Standard Driver

Shared State

Agent

Safety Boundary

이 구조는 다양한 Physical Agent 시스템에서 참고할 만하다.

45. 결국 Agent의 세상이 화면 밖으로 나온다

최근 몇 년간 Agent는 빠르게 확장됐다.

Chat

↓

Code

↓

Browser

↓

Computer

↓

Cloud

그리고 이제:

Physical Hardware

까지 들어오기 시작했다.

Anthropic의 MHS Research Preview는 이 변화를 꽤 명확하게 보여준다.

46. 앞으로 개발자가 고민해야 할 질문도 달라진다

Software Agent에서는:

이 Agent에게 Git Write를 허용할까?

를 고민했다.

Physical Agent에서는:

이 Agent에게 Robot Arm을 얼마나 빠르게 움직일 권한을 줄까?

Sample을 폐기할 수 있게 할까?

몇 번까지 Retry하게 할까?

어떤 작업은 반드시 사람이 승인해야 할까?

를 고민해야 한다.

Agent Permission이 곧 물리적 권한이 된다.

47. Physical Agent에서 가장 중요한 것은 Intelligence보다 Boundaries일 수 있다

엄청나게 똑똑한 Agent보다:

무엇을 할 수 있고

무엇을 할 수 없으며

언제 멈춰야 하는지

가 명확한 Agent가 더 안전할 수 있다.

따라서 MHS 이후의 핵심은:

Agent Intelligence

만이 아니다.

Agent
+
Hardware Contract
+
Safety Boundary
+
Runtime Verification

이다.

48. 개발자가 지금 준비할 만한 Architecture

지금부터 Physical AI를 공부한다면 다음 구조를 추천할 수 있다.

                   Goal
                    │
                    ▼
                AI Agent
                    │
                    ▼
               Planner
                    │
                    ▼
                Simulator
                    │
                    ▼
              Safety Policy
                    │
                    ▼
              Device Adapter
                    │
                    ▼
                 Hardware
                    │
                    ▼
                  Sensor
                    │
                    └──────────→ Agent

그리고 모든 Action을 Log한다.

Observe
→ Plan
→ Validate
→ Act
→ Observe
→ Verify

이 Loop가 기본이 된다.

49. MHS가 Open Source되면 가장 먼저 보고 싶은 부분

현재 공개 자료만으로는 실제 Specification 전체를 볼 수 없다.

그래서 정식 Open Source 이후 특히 확인할 부분은:

Device Manifest Schema

Discovery

Authentication

Permission Model

Safety Limit 표현

Unit 표현

Failure / Recovery

State Synchronization

Network Protocol

Driver Conformance

Simulation Interface

Audit / Provenance

이다.

특히 Safety가 Prompt 수준인지 Driver 수준에서 얼마나 강하게 강제되는지가 중요하다.

50. 지금 단계에서 MHS를 과대평가해서도 안 된다

현재 MHS는:

Research Preview

다.

아직:

업계 표준으로 확정

된 것도 아니고,

모든 Robot 업체가 채택

한 것도 아니다.

또:

AI가 공장을 완전히 자율 운영

한다는 의미도 아니다.

Anthropic과 초기 파트너들이 AI Agent와 Physical Hardware를 연결하기 위한 공통 규격을 실험하기 시작했다고 보는 것이 정확하다.

마무리

MCP가 중요한 이유는 AI에게 새로운 지능을 준 것이 아니었다.

AI가 사용할 수 있는 Software Tool의 세계를 표준화된 방식으로 넓혔기 때문이다.

MHS가 흥미로운 이유도 같다.

단순히 Claude가 Robot Arm을 움직였다는 이야기가 아니다.

더 중요한 질문은:

AI Agent가
서로 다른 물리 장비를
어떻게 발견하고,

무엇을 할 수 있는지 이해하고,

현재 상태를 읽고,

안전한 범위 안에서 조작하고,

여러 장비를 하나의 Workflow로 묶을 것인가?

이다.

Anthropic이 공개한 구조에서는 MHS Driver가 장비별 API 차이를 표준화하고, Device Reference가 측정 가능 값·조절 가능한 값·물리적 특성과 안전 한계를 Agent에게 알려준다. MCP·CLI·Code File을 통해 Agent가 장비를 제어할 수 있고, 반복적이거나 빠른 작업은 Agent가 직접 매 순간 추론하지 않고 Deterministic Code로 내려보낼 수도 있다.

이 구조가 중요한 이유는 결국 Agent가 사용하는 Tool의 정의가 바뀌기 때문이다.

지금까지:

Tool
=
API
Database
Browser
Git

였다면,

앞으로는:

Tool
=
Robot
Microscope
Camera
Laser
Machine
Sensor

도 된다.

하지만 Software와 Physical World 사이에는 결정적인 차이가 있다.

Software는 잘못되면 Rollback할 수 있는 경우가 많다.

Physical World에는:

Undo

가 없는 작업이 많다.

그래서 Physical Agent 시대에는 모델의 Intelligence만큼이나:

Safety Limits

Permissions

Deterministic Controllers

Simulation

Retry Budget

Emergency Stop

Audit Log

Human Approval

이 중요해진다.

한 문장으로 정리하면:

MHS의 진짜 의미는 AI에게 기계를 움직일 권한을 주는 것이 아니라, AI가 실제 기계를 사용할 때 필요한 공통 언어와 안전 경계를 만들기 시작했다는 데 있다.

그리고 이 방향이 자리 잡는다면 Agent 개발의 범위도 크게 달라질 수 있다.

Software Agent

에서:

Physical Agent

로.

Coding Automation

에서:

Experiment Automation
Manufacturing Automation
Robotics Automation

으로.

AI Agent가 화면 밖으로 나오기 시작한 셈이다.

MCP가 Agent에게 Software World의 문을 열었다면,

MHS는 Physical World의 문을 열려는 첫 시도 중 하나다.

참고 자료

Anthropic — Previewing the Model Hardware Standard, 2026-08-27
MHS Research Preview의 공식 발표. MHS는 HHMI Janelia Research Campus와의 협력에서 시작됐으며 현미경·Liquid Handler·Robot Arm·Quantum Laser 등 Programmable Hardware를 AI Agent가 공통 Interface를 통해 제어하는 방향을 제시한다. Standardized Driver, read/write Primitive, Device Discovery, Natural-language Hardware Context, Safety Limits, MCP·CLI·Code File 기반 제어 구조를 설명한다.

Model Hardware Standard 공식 사이트
현재 MHS는 Limited Research Preview이며 과학·로봇·전자·제조 분야 파트너를 대상으로 신청을 받고 있다. Safety Evaluation과 Best Practice 개발 이후 Open Source할 계획이다.

Anthropic / QuEra MHS 사례
Quantum Computer Laser System의 Lock Recovery에 MHS 기반 Agent를 적용한 사례에서 기존 수작업·Bespoke Automation과 다른 Adaptive Recovery 접근을 보여준다. 공개 결과에서 MHS 기반 Controller는 실험 환경에서 99.3퍼센트의 Lock Recovery 성공률을 기록했다.

HHMI Janelia Research Campus
MHS는 Janelia의 연구 장비 통합 문제를 해결하려는 작업에서 출발했다. Janelia는 다양한 Custom Microscope와 연구용 Hardware를 개발·운영하는 연구기관으로, Open Science와 Hardware/Software 도구 공개도 지속하고 있다.

핵심 참고 포인트

MHS는 MCP의 대체물이 아니다. MHS가 Hardware를 공통 Driver와 Device Description으로 표준화하고 MCP는 Agent가 그 Hardware에 접근하는 방법 중 하나가 될 수 있다. Anthropic은 MCP 외에도 CLI와 Code File/API를 MHS 제어 방식으로 설명하고 있다.

또한 현재 MHS는 일반 개발자가 바로 설치해서 사용하는 완성형 Open Source 표준이 아니라 제한된 Research Preview다. 따라서 공개된 구조를 기반으로 Physical Agent Architecture를 연구할 수는 있지만, 실제 MHS 공식 Schema나 구현 세부사항을 임의로 가정해서는 안 된다.

가장 흥미로운 기술적 패턴은 Agent가 처음에는 Hardware를 탐색적으로 조작하고, 반복 가능한 관계를 학습한 뒤 그 행동을 Deterministic Code로 변환하는 방식이다. AI가 모든 제어 순간마다 추론하는 것이 아니라 AI Reasoning → Controller 생성 → 빠른 Runtime 실행으로 역할을 분리한다. Physical Agent가 실제 산업 환경으로 확장될수록 이 구조와 함께 Safety Boundary·Simulation·Hardware Interlock·Audit가 핵심이 될 가능성이 높다.

GPT-6 Astra 이후, Coding Agent는 Engineering Agent가 된다

Sat, 05 Sep 2026 07:56:45 GMT

GPT-6 Astra 이후, Coding Agent는 Engineering Agent가 된다

GPT-6 Astra가 나온 지금, 개발자 입장에서 가장 중요한 변화는 모델 점수 하나가 더 올라갔다는 사실이 아니다.

OpenAI는 Astra를 단순한 코딩 모델이 아니라 복잡한 추론·코딩·브라우징·컴퓨터 사용·전문 업무를 하나의 멀티스텝 작업으로 수행하는 모델로 소개하고 있다. 특히 코드, 브라우저, 전문 소프트웨어를 오가며 end-to-end 작업을 수행하는 능력을 전면에 내세웠다.

이 변화는 Coding Agent라는 말의 의미를 바꾼다.

지금까지의 Coding Agent가 대략 이런 역할이었다면,

요구사항
  ↓
Repository 조사
  ↓
코드 수정
  ↓
Build / Test

Astra 이후의 Agent는 점점 이런 형태에 가까워진다.

Goal
  ↓
Repository 조사
  ↓
관련 문서 조사
  ↓
Browser 사용
  ↓
전문 도구 실행
  ↓
구현
  ↓
Build / Test
  ↓
실패 원인 분석
  ↓
다른 방법으로 복구
  ↓
Runtime 확인
  ↓
결과물 생성
  ↓
Human Review

즉 Coding Agent에서 Engineering Agent로 이동하고 있다.

1. Astra의 핵심은 코드를 더 잘 쓰는 것이 아니다

GPT-6 Astra는 2026년 9월 3일 발표됐다.

OpenAI는 Astra를 “가장 어려운 end-to-end work”를 위한 모델이라고 설명하고 있으며, software engineering뿐 아니라 computer use, browsing, science, research, 문서·스프레드시트·프레젠테이션 제작까지 하나의 작업 흐름에서 다룰 수 있도록 설계했다고 밝히고 있다.

이 설명에서 중요한 단어는 coding보다 end-to-end다.

기존 Coding Agent의 성공 기준은 보통:

코드를 수정했는가?

였다.

Engineering Agent의 성공 기준은 다르다.

요청된 업무가
실제로 완료됐는가?

다.

예를 들어:

신규 결제 Flow를 만들고 실제 브라우저에서 검증한 뒤 QA 결과까지 정리해.

라는 Goal이 있다고 하자.

Coding Agent라면:

React 코드 작성
API 연결
Test 작성

정도까지 갈 수 있다.

Engineering Agent는:

기존 결제 구조 조사
        ↓
Backend API 확인
        ↓
Frontend 구현
        ↓
브라우저 실행
        ↓
결제 Flow 사용
        ↓
Console / Network 확인
        ↓
실패 발견
        ↓
코드 수정
        ↓
재검증
        ↓
결과 정리

까지가 하나의 Task다.

개발 단위 자체가 달라지는 것이다.

2. 코드가 아니라 ‘업무’를 맡기기 시작한다

예전 Prompt는 이런 식이었다.

이 함수 리팩터링해줘.

조금 지나서는:

이 Feature 구현하고 테스트까지 해줘.

였다.

앞으로는 점점 이렇게 바뀔 가능성이 크다.

회원가입 전환율이 떨어지는 원인을 조사하고,
관련 Frontend 문제를 수정한 뒤
실제 Browser에서 Flow를 검증해.

이 요청에는:

Data 조사
UI 분석
코드 탐색
구현
브라우저 조작
QA
결과 보고

가 동시에 들어 있다.

Astra가 강조하는 것도 이런 멀티스텝 Workflow다. OpenAI 공식 문서는 Astra가 코드, 브라우저, 전문 소프트웨어 사이를 오가며 복합적인 작업을 수행하도록 설계됐다고 설명한다.

이제 AI에게 맡기는 단위가:

Function

에서:

Feature

를 거쳐:

Engineering Goal

로 커지고 있다.

3. Async Tool Calling이 이 변화에서 상당히 중요하다

Astra에는 눈에 띄는 기능이 하나 있다.

Async Tool Calling이다.

기존 Agent Workflow는 흔히:

Agent
  ↓
Tool 호출
  ↓
기다림
  ↓
Tool 결과
  ↓
다음 작업

형태였다.

Build가 3분 걸리면 Agent도 사실상 기다렸다.

Astra에서는 Tool을 비동기로 호출한 상태에서도 다른 작업을 계속 수행할 수 있다. Application이 실제 Tool 실행과 Pending 상태를 관리하고, 결과가 준비되면 기존 call_id를 이용해 다시 전달하는 구조다.

개발 Workflow에 적용하면:

Agent
 ├─ Backend Test 실행 ───────────┐
 │                              │
 ├─ 기다리지 않고 Frontend 조사 │
 │                              │
 ├─ Docs 확인                    │
 │                              │
 └─ Test 결과 수신 ◀────────────┘

이런 형태가 가능해진다.

사람 개발자와 비슷하다.

개발자가:

빌드 돌려놓고

↓

다른 파일 확인하고

↓

문서 읽고

↓

빌드 끝나면 결과 확인

하는 것처럼 Agent도 Tool Waiting Time을 다른 작업에 사용할 수 있다.

이건 단순한 속도 개선 이상의 변화다.

Agent가 작업 Scheduler처럼 행동하기 시작한다.

4. Mid-turn Steering도 개발환경에서는 큰 변화다

Astra의 또 다른 새 기능은 Mid-turn Steering이다.

Agent가 긴 작업을 수행하는 도중 추가 지시를 넣을 수 있다.

예를 들어 Agent가 작업 중이다.

Repository 조사
↓
Architecture 분석
↓
Implementation 진행 중...

그때 개발자가:

잠깐.
기존 Public API는 절대 변경하지 마.

라고 추가한다.

예전에는 작업을 중단하고 다시 Prompt를 만들어야 하는 경우가 많았다.

Mid-turn Steering에서는:

기존 Goal
+
현재 Context
+
추가 Constraint

를 유지한 상태에서 방향을 바꿀 수 있다.

실제 개발팀에서 Tech Lead가:

그 방향 말고 기존 Interface 유지하면서 해주세요.

라고 중간에 이야기하는 것과 비슷하다.

Agent가 단순 명령 실행기가 아니라 계속 협업 중인 Worker에 가까워진다.

5. 그러면 개발자의 역할도 바뀐다

AI가 코드를 더 많이 작성한다고 개발자의 역할이 사라지는 것은 아니다.

오히려 개발자가 다뤄야 하는 추상화 수준이 올라간다.

기존:

Developer

코드 작성

Agent 시대:

Developer

Goal 정의
Constraint 정의
Architecture 판단
Agent 작업 분할
결과 검증

즉 개발자는:

어떻게 구현할까?

를 고민하는 시간 일부를 줄이고,

무엇을 맡길까?

어디까지 맡길까?

어떤 결과면 성공인가?

어떤 판단은 사람이 해야 하나?

를 더 많이 고민하게 된다.

최근 Coding Agent에서 이미 보이던 변화인데 Astra 같은 모델에서는 훨씬 명확해질 가능성이 크다.

6. 가장 중요한 것은 Goal을 제대로 만드는 능력이다

Engineering Agent에게:

이 앱 개선해줘.

라고 하면 너무 넓다.

반대로:

Button padding을 8에서 12로 바꿔.

라고 하면 Engineering Agent를 사용하는 의미가 줄어든다.

좋은 Goal은 이 중간이다.

예:

Goal:
신규 사용자의 가입 완료율을 떨어뜨리는
Frontend UX 문제를 조사하고 수정한다.

Scope:
signup 관련 React components만 수정 가능.

Constraints:
Backend API 변경 금지.
새 Dependency 추가 금지.

Validation:
Desktop + Mobile Browser에서
회원가입 Flow를 실제 수행한다.

Completion:
- Build PASS
- E2E PASS
- Console Error 없음
- 변경 내용과 발견된 UX 문제 보고

이 정도가 Engineering Agent에게 적절하다.

즉 Prompt Engineering보다 앞으로 더 중요한 것은 Goal Engineering일 수 있다.

7. AGENTS.md와 Skills가 오히려 더 중요해진다

모델이 강해질수록:

이제 세부 규칙 안 적어도 알아서 잘하겠지.

라고 생각하기 쉽다.

그런데 OpenAI의 Astra 가이드는 오히려 반대 방향을 주의시킨다.

Astra는 이전 모델보다 instruction following이 강하고, AGENTS.md나 Skills처럼 접근 가능한 파일의 지침에도 더 민감하게 반응할 수 있다. OpenAI는 여러 Skills와 instruction file을 사용하는 환경에서는 서로 충돌하거나 조용히 영향을 주는 지침을 감사할 것을 권장하고 있다.

즉 모델이 강할수록:

AGENTS.md
Skills
Architecture Docs
Security Policy
Testing Rules

의 품질이 더 중요해질 수 있다.

강한 Agent는 잘못된 지시도 더 충실히 수행할 가능성이 있기 때문이다.

8. AGENTS.md는 ‘설명서’보다 경계선이어야 한다

좋은 AGENTS.md는 모든 Architecture를 설명하는 2만 줄짜리 문서가 아니다.

예:

# Project Rules

- Public API 변경 전 확인한다.
- 새 Dependency를 임의로 추가하지 않는다.
- Production Credential을 읽지 않는다.
- 관련 테스트 없이 완료 처리하지 않는다.
- 테스트하지 못한 부분은 Not Verified로 보고한다.
- Architecture 변경은 먼저 계획을 제시한다.

이런 규칙이 더 중요하다.

Agent 입장에서:

무엇을 할 수 있는가?

보다:

무엇은 하면 안 되는가?

를 명확하게 만드는 것이다.

Engineering Agent의 자율성이 높아질수록 Boundaries가 중요해진다.

9. Skill은 ‘작업 방법’을 고정한다

예를 들어 iOS Bug Fix Skill을 만들 수 있다.

Goal 확인
↓
관련 코드 조사
↓
재현
↓
가설 작성
↓
수정
↓
Build
↓
관련 Test
↓
Simulator 확인
↓
완료 보고

Web QA Skill:

Scenario 확인
↓
Browser 실행
↓
실제 사용자 Flow 수행
↓
Console 확인
↓
Network 확인
↓
Screenshot / Trace
↓
UX Finding

Security Skill:

Git Diff
↓
Secret
↓
Auth
↓
Authorization
↓
PII
↓
Cloud Permission
↓
Dependency
↓
Risk 등급

Astra가 강해졌다고 Workflow가 사라지는 것이 아니다.

오히려 좋은 Workflow를 훨씬 더 안정적으로 수행할 수 있게 되는 것에 가깝다.

10. Engineering Agent에게 모든 권한을 주면 안 된다

여기서 중요한 문제가 발생한다.

Astra는 OpenAI가 지금까지 광범위하게 배포한 모델 가운데 처음으로 사이버보안 능력이 Preparedness Framework의 Critical 기준에 도달한 모델이다. OpenAI는 Astra가 적절한 도구와 접근권한이 있을 경우 새로운 보안 취약점을 찾고 활용하는 작업까지 매우 강해졌다고 설명한다.

이건 개발자에게도 중요한 신호다.

모델이 강해질수록:

Shell
Git
AWS
Production
Database
Browser
Credential

에 대한 접근을 더 신중하게 관리해야 한다.

Agent Capability가 올라갈수록 Permission 설계가 더 중요해진다.

11. 그래서 AUTO / CONFIRM / DENY가 필요하다

예를 들어:

AUTO

파일 검색
코드 수정
Unit Test 실행
Local Build
Formatting
Lint

CONFIRM

새 Dependency 추가
Public API 변경
Database Migration
새 Cloud Resource
외부 서비스 연결

DENY

Production Secret 읽기
Production DB 직접 수정
main 강제 Push
Security Policy 해제
Credential Export

이런 식으로 나눈다.

강한 Agent에게:

알아서 해.

가 아니라:

여기까지는 알아서 해.
그 이상은 물어봐.
여기는 절대 건드리지 마.

를 정의한다.

12. OpenAI가 Astra에 추가 Safety Monitoring을 넣은 이유도 여기 있다

OpenAI는 Astra가 사용자의 지시를 잘못 해석했을 가능성을 탐지하는 추가 Safety Monitoring을 도입했다고 밝혔다.

잠재적인 문제가 감지되면 Conversation이나 작업을 일시 중지하거나 종료하고 사용자가 검토하도록 할 수 있다.

이건 앞으로 Agent Runtime에 중요한 개념이 될 수 있다.

Agent
   ↓
Action
   ↓
Runtime Monitor
   ↓
Expected Boundary?
     │
 YES │ NO
     │
     ▼
 Continue   Pause
               ↓
            Human

즉 AI Model 자체만 강해지는 것이 아니라:

AI
+
Monitor
+
Policy
+
Human Gate

형태의 시스템이 중요해진다.

13. Coding Agent 하나가 모든 걸 할 필요도 없다

Astra가 매우 강한 모델이라고 해서 모든 작업을 Astra 하나에게 맡기는 것이 반드시 좋은 Architecture는 아니다.

오히려 역할을 나눌 수 있다.

Astra
= Planner / Complex Engineering

Codex Worker
= Implementation

Claude
= Independent Review

Playwright
= Web Runtime Verification

CI
= Deterministic Gate

또는 OpenAI 모델 안에서도:

Astra
= 어려운 판단

Sol
= 일반 구현

Terra
= 반복 작업

Luna
= 대량 저비용 작업

처럼 Routing할 수 있다.

OpenAI의 현재 모델 가이드에서도 Astra는 가장 어려운 end-to-end work를 위한 모델로, Terra는 intelligence와 cost의 균형, Luna는 비용 민감한 대량 작업에 적합한 모델로 분류하고 있다.

즉 Engineering Agent 시대에는 모델 하나보다 팀 구성이 중요해진다.

14. 개인 개발자도 작은 AI 개발팀을 만들 수 있다

예를 들어 Workspace가:

workspace/

├── ios-app/
├── android-app/
├── web/
└── backend/

처럼 여러 Git Repository로 나뉘어 있다고 하자.

상위 Orchestrator:

Codex / Astra

하위 작업:

ios-app
→ 구현 Agent

android-app
→ 조사 Agent

web
→ Browser QA Agent

backend
→ Test Agent

그리고 독립 Reviewer:

Claude Review

를 붙인다.

구조는:

                    Human
                      │
                      ▼
                Astra / Codex
                  Orchestrator
                      │
       ┌──────────────┼──────────────┐
       ▼              ▼              ▼
     iOS Agent    Android Agent   Web Agent
       │              │              │
       └──────────────┼──────────────┘
                      ▼
                 Build / Tests
                      │
                      ▼
                Claude Review
                      │
                      ▼
                  Runtime QA
                      │
                      ▼
                    Human

한 명의 개발자가 작은 개발조직을 운영하는 구조다.

15. 여기서 Astra는 ‘최고의 코더’보다 ‘상위 오케스트레이터’에 더 어울릴 수 있다

Astra는 API 기준 input 100만 토큰당 10달러, output 50달러다.

GPT-5.6 Sol은 input 4달러, output 20달러다. 두 모델 모두 1,050,000 token context와 최대 128,000 output token을 지원한다.

Astra는 Sol보다 토큰 단가가 2.5배 높다.

따라서 모든 작은 작업을 Astra에 맡기는 것은 비용 면에서 비효율적일 수 있다.

예:

Import 정리
→ Astra

Naming 수정
→ Astra

Unit Test Fixture
→ Astra

보다:

복잡한 Goal 분해
→ Astra

Repository-wide 설계 판단
→ Astra

일반 구현
→ Sol / Terra

반복적인 작업
→ Luna

가 훨씬 현실적이다.

16. 하지만 단순 Token 가격만 보면 안 된다

OpenAI는 Astra가 일부 평가에서 이전 모델보다 훨씬 적은 출력 토큰으로 더 높은 성능을 달성해, 높은 토큰 단가에도 불구하고 Task 단위 예상 비용을 낮출 수 있다고 설명한다.

이건 Coding Agent에서도 중요하다.

예:

Sol

3번 시도
+
긴 Log
+
Human Intervention

대:

Astra

1번 시도
+
완료

라면 Astra가 비싸더라도 전체 비용은 낮을 수 있다.

그래서 봐야 하는 것은:

Cost per Token

보다:

Cost per Successful Task

다.

17. Engineering Agent 시대의 진짜 KPI

이제 Agent 성능을:

Generated LOC

Token

PR Count

로 보면 안 된다.

더 중요한 지표는:

Successful Task Rate

Human Intervention Count

Retry Count

Recovery Success Rate

Review Time

Regression Rate

Cost per Successful Task

이다.

예를 들어:

Agent A

작업 성공 95%
사람 개입 1회
Review 10분

Agent B

작업 성공 95%
사람 개입 9회
Review 40분

같은 성공률이라도 실제 생산성은 완전히 다르다.

18. 특히 Human Attention이 핵심 자원이 된다

Agent는 동시에 여러 개 돌릴 수 있다.

사람은 그렇지 않다.

Agent 1
Agent 2
Agent 3
Agent 4

가 동시에 작업을 끝내면:

Review Queue

가 생긴다.

그래서 좋은 Engineering Agent는:

많은 일을 하는 Agent

보다:

사람이 쉽게 검토할 수 있는
완료된 결과를 가져오는 Agent

가 되어야 한다.

19. 그래서 완료 보고 형식도 바꿔야 한다

Agent가:

완료했습니다.

라고 하면 부족하다.

추천하는 완료 Report:

## 변경

관련 파일 4개 수정

## 이유

원인은 Task cancellation 이후
state update가 계속 발생한 것.

## 실제 검증

Build PASS
Unit Test 42/42 PASS

## Runtime

Simulator 정상

## 미검증

Physical Device

## Human Decision

없음

이런 결과가 훨씬 Review하기 쉽다.

Engineering Agent의 생산성을 높이려면 출력량이 아니라 Review 비용을 줄여야 한다.

20. Agent가 강해질수록 Test는 더 중요하다

역설적으로 AI가 더 똑똑해질수록 테스트가 덜 필요해지는 게 아니다.

오히려 더 중요해진다.

강한 Agent는 더 많은 코드를 더 빠르게 수정할 수 있기 때문이다.

Agent Capability ↑

↓

Change Surface ↑

좋은 방향이면 생산성이 빠르게 올라간다.

틀린 방향이면 잘못된 변경도 빠르게 확산된다.

그래서:

Agent Opinion

보다:

Compiler
Test
Runtime

를 우선해야 한다.

21. Agent가 만든 Test도 그대로 믿으면 안 된다

Agent가:

구현
+
Test

를 같이 작성했다.

그리고 Test가 통과했다.

끝일까?

아니다.

Agent가 요구사항을 잘못 이해했다면:

틀린 구현
+
틀린 테스트
=
PASS

가 가능하다.

그래서 중요한 기능에서는:

Acceptance Criteria

↓

독립 Reviewer

↓

Runtime Verification

을 분리해야 한다.

22. Review Agent와 Coding Agent를 분리하는 이유

예를 들어 Codex가 구현했다고 하자.

Claude에게 별도로 Review를 맡긴다.

Codex
→ Implementation

Claude
→ Review

서로 다른 모델을 반드시 써야 한다는 의미는 아니다.

중요한 것은 Context를 분리하는 것이다.

작성 과정의 가정

을 가진 Agent가 자기 코드를 평가하는 것보다:

Task
Diff
Architecture
Tests

만 받은 Reviewer가 독립적으로 보는 편이 좋다.

23. QA도 또 다른 Agent로 분리한다

Review:

Source
Diff
Architecture

QA:

Running Product
User Goal
Runtime

를 본다.

예:

Implementation
      ↓
Build/Test
      ↓
Code Review
      ↓
Runtime QA
      ↓
Human Gate

이 구조가 Engineering Agent 시대에 더 자연스럽다.

24. Web에서는 이미 상당 부분 가능하다

Web Frontend라면:

Goal
  ↓
Agent 구현
  ↓
Browser
  ↓
Playwright
  ↓
DOM / ARIA
  ↓
Click / Type / Scroll
  ↓
Console
  ↓
Network
  ↓
Screenshot / Video / Trace

까지 하나의 Workflow로 묶을 수 있다.

Astra가 Computer Use와 Browser Use에서 강해지는 방향은 결국 이런 Runtime Engineering을 더 자연스럽게 만들 가능성이 높다. OpenAI는 Astra를 browser와 computer use에서 새로운 frontier를 세운 모델로 소개하고 있다.

25. 모바일도 결국 같은 방향으로 갈 가능성이 높다

iOS:

Source
↓
Build
↓
Simulator
↓
Accessibility
↓
Interaction
↓
Recording
↓
Runtime Log

Android:

Source
↓
Gradle
↓
Emulator
↓
Semantics
↓
Interaction
↓
Logcat

현재는 Browser보다 연결이 복잡하다.

하지만 개발도구가 Agent에게 Semantic UI와 Runtime 상태를 더 많이 제공할수록 Web과 비슷한 구조가 될 가능성이 높다.

26. Engineering Agent는 코딩만 하는 개발자가 아니다

앞으로 Agent 역할을 개발팀 역할에 대응시키면 이렇게 볼 수 있다.

Research Agent
= 코드 조사

Architecture Agent
= 설계 검토

Implementation Agent
= 구현

Review Agent
= 코드 리뷰

QA Agent
= Runtime QA

Security Agent
= 보안 검토

그리고 상위에는:

Orchestrator

가 있다.

Astra가 흥미로운 이유는 이 상위 역할과 여러 역할 사이를 한 모델이 오갈 수 있는 능력이 크게 올라갔다는 점이다.

27. 하지만 ‘AI 개발자 한 명’보다는 ‘AI 개발팀’이 더 현실적이다

Astra 하나에게:

조사하고
설계하고
코딩하고
리뷰하고
QA하고
배포해.

라고 하는 것도 가능해질 수 있다.

하지만 좋은 개발 조직은 역할을 분리한다.

AI도 마찬가지다.

Astra
→ Goal / Planning

Sol
→ Implementation

Claude
→ Review

Playwright
→ QA

CI
→ Gate

처럼 구성할 수 있다.

중요한 것은 어떤 모델을 쓰느냐보다:

역할

권한

검증

완료 조건

이다.

28. 앞으로 개발 Architecture에는 AI Control Plane이 들어간다

지금까지 개발팀 Architecture를 생각하면:

GitHub
CI
Issue Tracker
Monitoring

정도가 중심이었다.

앞으로는:

Agent Tasks
Agent Permissions
Skills
Worktrees
Model Routing
Tool Access
Agent Logs
Human Gates

같은 것도 관리해야 한다.

즉:

Developer Control Plane

이 필요해진다.

Astra 같은 모델은 이 필요성을 더 빠르게 만든다.

29. 멀티에이전트의 목표는 Agent 숫자가 아니다

Agent가 강해지면:

10 Agent
20 Agent
50 Agent

를 돌리고 싶어질 수 있다.

하지만 Agent 숫자가 많을수록 좋은 것이 아니다.

중요한 건:

Human Cognitive Load ↓

Software Throughput ↑

이다.

Agent 20개가 동시에 질문을 던진다면 실패한 오케스트레이션이다.

좋은 Agent Team은:

조사
구현
검증

을 알아서 수행하고,

사람에게는:

Decision Needed

만 올린다.

30. 결국 좋은 Engineering Agent는 잠시 잊을 수 있는 Agent다

개발자가 Agent에게 작업을 맡긴다.

그리고 다른 일을 한다.

30분 뒤 돌아왔을 때:

Finding
Evidence
Result
Decision Needed

가 정리돼 있다.

이게 이상적인 형태다.

반대로:

3분마다 질문

5분마다 승인

같은 실패 반복

긴 설명

을 하면 Agent Capability가 높아도 실제 생산성은 낮다.

31. Astra가 보여주는 미래는 ‘더 좋은 Copilot’이 아니다

Copilot이라는 이름에는 기본적으로:

사람이 운전

AI가 보조

라는 의미가 있다.

Engineering Agent는 조금 다르다.

사람
→ 목적과 경계 결정

Agent
→ 실제 업무 수행

사람
→ 결과 판단

형태다.

즉 개발자는 항상 키보드를 잡고 있을 필요가 없다.

더 높은 수준에서:

Goal

Architecture

Trade-off

Risk

Approval

을 담당한다.

32. 그렇다면 개발자는 코딩을 덜 배워도 될까?

오히려 반대일 수 있다.

Agent 결과를 제대로 검증하려면:

Architecture

Concurrency

Networking

Database

Security

Runtime

Performance

를 이해해야 한다.

직접 작성하는 코드량이 줄어들어도 판단의 난도는 올라갈 수 있다.

특히 Senior Developer 역할은:

코드를 많이 쓰는 사람

에서:

좋은 변경인지 판단할 수 있는 사람

으로 더 이동할 가능성이 높다.

33. Junior 개발자에게는 다른 문제가 생긴다

기존 학습:

직접 구현
↓
실수
↓
Debug
↓
Review
↓
이해

Agent 시대:

Prompt
↓
Agent
↓
Merge

가 되면 중간 학습 단계가 줄어든다.

따라서 Junior에게는 일부 Task를:

Human Implementation
+
AI Review

로 남기는 방식도 필요하다.

모든 것을 Agent에게 위임하는 것이 반드시 좋은 Engineering 교육은 아니다.

34. Astra를 당장 모든 곳에 적용할 필요도 없다

Astra는 현재 가격과 토큰 소비량이 Sol보다 2.5배 가량 높다.

따라서 현실적인 도입은:

Hard Task
→ Astra

Normal Coding
→ Sol / Terra

High-volume
→ Luna

같은 구조가 낫다.

OpenAI도 현재 모델 선택 가이드에서 Astra는 가장 복잡한 reasoning과 coding용, Terra는 비용과 intelligence의 균형, Luna는 비용 민감한 대량 작업용으로 구분하고 있다.

35. 개발팀이 지금 준비해야 할 것은 Astra Prompt가 아니다

신규 모델이 나오면 흔히:

Astra용 Prompt Best Practice

부터 찾는다.

물론 필요하다.

하지만 더 중요한 것은:

Repository Structure

AGENTS.md

Skills

Tests

CI

Permissions

Security Policy

Runtime Evidence

Review Rules

다.

모델은 계속 바뀐다.

개발 시스템은 남는다.

36. 가장 좋은 구조는 Model-independent하다

오늘:

GPT-6 Astra

가 가장 강할 수 있다.

몇 달 뒤:

다음 GPT
다음 Claude
다른 Frontier Model

이 더 좋아질 수 있다.

그러므로:

Task
  ↓
Agent Runtime
  ↓
Model

을 분리한다.

Model은 교체 가능한 Worker다.

Astra
Fable
Sol
다음 모델

무엇이 들어와도:

Goal
→ Implementation
→ Validation
→ Review
→ QA
→ Human

Workflow는 유지한다.

37. 개인 개발자에게 가장 현실적인 구조

앞으로 개인 개발 환경은 이런 모습이 될 가능성이 높다.

                    Developer
                        │
                        ▼
                  Goal / Policy
                        │
                        ▼
                   Orchestrator
                        │
           ┌────────────┼────────────┐
           ▼            ▼            ▼
        Research     Implement       Test
         Agent         Agent         Agent
           │            │            │
           └────────────┼────────────┘
                        ▼
                  Automated Checks
                        │
                        ▼
                  Independent Review
                        │
                        ▼
                    Runtime QA
                        │
                        ▼
                      Human

그리고 Astra 같은 모델은 이 구조의:

Orchestrator

또는

가장 어려운 Worker

역할을 맡을 가능성이 크다.

38. 완료 기준도 바뀌어야 한다

예전 Coding Agent:

Code Generated

이 완료였다.

앞으로는:

Goal Achieved
+
Build PASS
+
Tests PASS
+
Runtime Verified
+
Critical Review 0
+
Not Verified 명시

정도가 되어야 한다.

Code Complete가 아니라 Engineering Complete다.

마무리

GPT-6 Astra의 가장 중요한 변화는 코드를 조금 더 잘 작성하게 된 것이 아니다.

OpenAI가 Astra를 설명할 때 반복해서 강조하는 것은:

Coding

Browsing

Computer Use

Professional Tools

Complex Multistep Work

를 하나의 end-to-end Workflow 안에서 수행하는 능력이다.

이건 Coding Agent의 역할을 근본적으로 바꾼다.

예전에는:

Developer
→ Agent
→ Code

였다.

앞으로는:

Developer
        ↓
Goal + Constraints
        ↓
Engineering Agent
        ↓
Research
        ↓
Implementation
        ↓
Tool Use
        ↓
Build / Test
        ↓
Recovery
        ↓
Runtime Verification
        ↓
Review-ready Result
        ↓
Developer

에 가까워진다.

그리고 이 변화가 커질수록 개발팀에서 가장 중요한 것은 모델 자체가 아닐 가능성이 높다.

오히려:

AGENTS.md

Skills

Permissions

Tests

CI

Runtime Evidence

Review Policy

Security Guardrails

같은 Agent가 일할 수 있는 Engineering Environment가 중요해진다.

Astra가 똑똑하다고 모든 권한을 넘겨주는 것도 좋은 설계가 아니다.

OpenAI가 Astra에 추가적인 안전 모니터링을 넣고, Astra가 최초로 Critical 수준의 사이버보안 Capability에 도달했다고 별도로 강조한 이유도 결국 같은 문제를 보여준다. Agent Capability가 높아질수록 Control Plane과 Permission Boundary가 더 중요해진다.

그래서 GPT-6 Astra 이후 개발팀이 준비해야 하는 질문은:

Astra로 코드를 얼마나 많이 만들 수 있을까?

가 아니다.

더 중요한 질문은:

이제 AI에게 어디까지 Engineering Goal을 맡길 수 있고, 그 결과를 어떤 시스템으로 검증할 것인가?

이다.

Coding Agent의 다음 단계는 더 좋은 자동완성이 아니다.

Engineering Agent다.

그리고 Engineering Agent 시대의 개발자는 코드를 가장 많이 작성하는 사람이 아니라, AI에게 올바른 목표와 경계를 주고, 결과가 실제 Software Change로 신뢰할 만한지 판단할 수 있는 사람에 더 가까워질 가능성이 크다.

참고 자료

OpenAI는 2026년 9월 3일 GPT-6 Astra를 발표하고 coding, research, computer use 및 복잡한 multi-step work가 크게 향상된 모델이라고 설명했다. Astra는 현재 제한된 조직부터 배포 중이며 API 및 Plus·Pro·Business·Enterprise 사용자로 확대될 예정이다.

OpenAI의 공식 개발자 가이드에서는 Astra를 코드·브라우저·전문 소프트웨어 사이를 오가는 복잡한 Workflow에 적합한 모델로 소개하며, Async Tool Calling과 Mid-turn Steering을 새 기능으로 제공한다. 또한 AGENTS.md와 Skills 등 외부 지침에 대한 instruction following이 더 강해졌기 때문에 접근 가능한 지침 파일을 점검할 것을 권장한다.

GPT-6 Astra API 모델은 1,050,000 token context, 최대 128,000 output token과 low·medium·high·xhigh·max reasoning effort를 지원한다. API 가격은 100만 input token당 10달러, output token당 50달러다.

OpenAI는 Astra가 Preparedness Framework에서 Critical 수준의 cybersecurity capability에 도달한 첫 모델이라고 밝히고 있으며, 이에 따라 추가적인 모니터링과 격리·안전 조치를 강화했다.

핵심 참고 포인트

GPT-6 Astra를 단순히 GPT-5.6 Sol보다 더 높은 성능의 Coding Model로 보는 것은 변화의 일부만 보는 것이다. OpenAI가 Astra에서 강조하는 핵심은 코딩과 Browser·Computer Use·Professional Tool을 하나의 긴 Workflow로 묶어 실제 업무 결과까지 도달하는 능력이다.

특히 Async Tool Calling은 Build나 Test처럼 오래 걸리는 작업 동안 Agent가 다른 일을 진행할 수 있게 하고, Mid-turn Steering은 긴 작업 중에도 사람이 새로운 요구사항이나 Constraint를 추가할 수 있게 한다. 이것은 Agent를 단발성 코드 생성기보다 지속적으로 일하는 Engineering Worker에 가깝게 만든다.

따라서 앞으로 개발환경의 핵심 경쟁력은 특정 Frontier Model 하나보다 Goal 설계 → Agent 작업 → 자동 검증 → 독립 Review → Runtime QA → Human Gate를 얼마나 안정적으로 운영할 수 있느냐에 있을 가능성이 높다.

AI Security Guardrail 설계: 개발팀의 보안 실수를 시스템으로 막는 법

Thu, 03 Sep 2026 13:36:39 GMT

AI Security Guardrail 설계: 개발팀의 보안 실수를 시스템으로 막는 법

2026년 9월 3일 공개된 티빙 침해사고 민관합동조사 결과는 개발자 입장에서 꽤 불편하게 읽힌다.

공격 기법이 특별히 새로운 것도 아니었기 때문이다.

조사 결과 공격자는 개발환경 접속키를 탈취해 내부 개발환경에 들어왔고, 이후 개발 프로젝트에서 운영환경 접속키를 추가 확보해 AWS 운영환경까지 침투했다. 소스코드를 포함한 기술자산은 361건, 약 30.35GB가 외부로 유출됐으며, 중복을 포함한 이용자 계정 약 3,954만 개가 영향을 받은 것으로 조사됐다.

더 충격적인 부분은 공격보다 그 전후다.

개발·운영환경 접속키가 소스코드에 노출되거나 사내 메신저로 공유됐고, 모든 개발자에게 전체 개발 프로젝트 접근 권한이 부여돼 있었다. 키의 발급·사용·변경·폐기와 정기점검 절차도 제대로 갖춰져 있지 않았다는 것이 조사 결과다. 2024년 모의해킹에서는 이미 소스코드 안 접속키 노출 문제가 발견됐지만 개선되지 않았다.

그리고 공격이 시작된 뒤에도 문제가 이어졌다.

실시간 네트워크·데이터 흐름을 탐지하고 차단하는 정보보호 체계 대신 CPU 부하 같은 시스템 모니터링에 주로 의존했고, 이상징후가 발생한 뒤 정보보호 조직에 공유되기까지 약 14시간이 걸렸다. 일부 접속기록은 약 6일만 보관됐으며, KISA 신고 역시 법정 시한을 넘긴 것으로 조사됐다.

이 사건을 단순히:

개발자가 키를 소스코드에 넣어서 사고가 났다.

정도로 정리하면 중요한 부분을 놓친다.

진짜 문제는 한 사람이 실수했을 때 그 실수가 Production 침해까지 그대로 이어질 수 있었던 시스템이다.

그리고 AI Coding Agent를 사용하는 지금은 이 문제를 조금 다르게 볼 필요가 있다.

사람이 보안을 놓칠 수 있다면 이제는 AI라도 한 번 더 보게 만들 수 있다.

다만 AI에게 보안을 “맡기는” 것이 아니다.

사람 → AI → 자동 보안 도구 → 권한 시스템 → Runtime 감시가 서로를 막아주는 구조를 만들어야 한다.

1. 이번 사고에서 가장 위험했던 건 Key 하나가 아니다

조사 결과를 개발 시스템 관점으로 단순화하면 이런 형태다.

개발자 Access Key 탈취
        ↓
개발환경 접근
        ↓
다수 프로젝트 접근
        ↓
Source Code 확보
        ↓
Source 안의 운영환경 Credential 확보
        ↓
Production 접근
        ↓
DB 접근
        ↓
데이터 대량 추출

문제는 첫 번째 Key가 탈취됐다는 사실만이 아니다.

첫 Credential이:

Developer
→ Development

에서 끝나지 않고,

Developer
→ Development
→ Source
→ Production Credential
→ Production
→ Database

까지 이어졌다는 것이 더 위험하다.

좋은 보안 Architecture라면 중간마다 끊겨야 한다.

Developer Credential 탈취

        ↓

Development 일부 접근

        X

또는:

Source 탈취

        ↓

Production Credential 없음

        X

또는:

Production 접근 시도

        ↓

권한 부족 / MFA / 단기 Credential

        X

또는:

DB 대량 조회

        ↓

Anomaly Detection

        ↓

Session Kill + Alert

        X

공격자는 여러 방어선을 연속으로 통과해야 한다.

이를 Defense in Depth라고 한다.

이번 조사 결과에서 드러난 가장 큰 문제도 각각의 방어선이 충분히 독립적으로 작동하지 않았다는 점이다.

2. 보안은 개발자의 기억에 맡기면 안 된다

현실적인 개발팀에서 이런 대화는 꽤 흔하다.

"이 Key는 나중에 Secrets Manager로 옮기죠."

"일단 개발 서버니까 넣어둘게요."

"테스트 끝나면 지우겠습니다."

"이 Repository private인데 괜찮지 않나요?"

문제는 대부분 악의가 없다는 것이다.

편해서 그렇게 한다.

일정이 급해서 그렇게 한다.

그리고 몇 달 뒤 아무도 기억하지 못한다.

그래서 보안 정책은:

개발자가 잘 지켜야 한다.

에서 끝나면 안 된다.

더 좋은 시스템은:

개발자가 실수해도
실수가 Repository에 들어가지 못한다.

여야 한다.

GitHub Push Protection이 대표적인 예다.

GitHub는 Push 과정에서 API Key나 Token 같은 Secret을 발견하면 Repository에 들어가기 전에 Push 자체를 차단할 수 있다. Secret Scanning은 Git History 전체에서도 Credential을 탐지할 수 있다.

즉:

개발자가 기억한다

보다:

Git이 막는다

가 강하다.

3. 이제 여기에 AI Security Reviewer를 하나 더 넣을 수 있다

2026년의 개발 환경에서는 한 단계 더 갈 수 있다.

Developer / Coding Agent
        ↓
Security Agent
        ↓
Deterministic Security Checks
        ↓
CI
        ↓
Runtime Security

예를 들어 Codex가 Feature를 구현했다고 하자.

바로 PR을 올리지 않는다.

먼저 별도의 Claude나 다른 Agent가 Security Reviewer 역할을 맡는다.

Codex
→ 구현

Claude Security Review
→ 보안 관점 검토

CodeQL / Secret Scanner
→ 기계적 검증

CI
→ 최종 Gate

중요한 것은 Claude가 작성한 코드를 Claude가 다시 고치는 구조가 아니라는 것이다.

Coding Agent
= 생산

Security Agent
= 의심

Security Tool
= 검출

Policy
= 차단

각자의 역할을 나눈다.

4. AI Security Agent에게 “보안 확인해줘”라고 하면 안 된다

나쁜 요청:

보안 문제 없는지 확인해줘.

이렇게 하면 결과가 모호하다.

대신 보안 계약을 고정한다.

이번 변경을 Security Reviewer 관점에서 검토한다.

반드시 확인:

Credential / Secret 노출
Authentication
Authorization
Privilege escalation
PII 접근
Logging
Network exposure
Dependency 변경
Encryption
Input validation
Production access
Cloud IAM
Data export 가능성

결과는:

CRITICAL
HIGH
MEDIUM
LOW
NOT VERIFIED

로 분리한다.

근거 없는 가능성은 취약점으로 단정하지 않는다.

코드를 수정하지 말고 Finding만 반환한다.

이 Prompt 자체를 매번 작성할 필요도 없다.

security-review Skill로 만들어 두면 된다.

5. 하지만 AI가 Secret Scanner를 대체하면 안 된다

이 부분이 중요하다.

LLM이:

AKIA...

같은 AWS Key를 발견할 수도 있다.

하지만 이런 건 AI가 할 일이 아니다.

GitHub Secret Scanning, Gitleaks, TruffleHog 같은 도구가 훨씬 적합하다.

현재 GitHub Secret Scanning은 알려진 Token뿐 아니라 Generic Secret 탐지에도 AI 기반 Detection을 일부 사용하며, Push Protection은 Credential이 Repository에 들어오기 전에 차단할 수 있다. GitHub MCP를 사용하는 AI 작업에서도 지원되는 환경에서는 Secret 노출을 차단하는 보호 기능이 적용된다.

따라서 역할은 이렇게 나누는 것이 좋다.

Secret Scanner
→ Secret 자체를 찾음

CodeQL / SAST
→ 알려진 코드 취약점 패턴 탐지

AI Security Reviewer
→ 여러 파일과 Architecture를 연결해 위험 판단

Human
→ 중요한 Architecture와 예외 승인

AI는 보안 Tool 위의 reasoning layer로 사용하는 것이 좋다.

6. Repository에 Secret이 존재할 이유부터 없앤다

가장 먼저 해야 할 것은:

secret = "..."

을 금지하는 것이다.

AWS도 Access Key를 Source Code나 Configuration에 넣는 방식을 명시적인 Anti-pattern으로 보고, 가능하면 IAM Role을 통한 Temporary Credential을 사용하고 장기간 보관해야 하는 Secret은 Secrets Manager 같은 전용 시스템에서 관리하도록 권장한다.

구조는:

Source Code
   │
   │ Secret 이름만 참조
   ▼
Runtime Identity
   │
   ▼
Secrets Manager
   │
   ▼
필요한 순간 Credential 획득

이런 형태가 되어야 한다.

반대로:

Git
↓
API_KEY
↓
Production

같은 연결이 존재하면 안 된다.

7. 가능하면 장기 Key 자체를 없앤다

더 좋은 방식은 Secret을 잘 숨기는 것이 아니라 없애는 것이다.

예를 들어 AWS 환경이라면:

Access Key
Secret Access Key

를 개발자 PC나 Repository에 저장하는 대신:

IAM Role

STS

Temporary Credentials

OIDC

같은 구조를 사용한다.

즉:

Permanent Credential

보다:

Short-lived Credential

이다.

만료 시간이 짧은 Credential은 탈취돼도 공격자의 활동 가능 시간을 줄인다.

AWS 역시 IAM Access Key가 필요할 때 가능하면 EC2·Lambda 등의 IAM Role과 단기 Credential을 사용하도록 권장한다.

8. 모든 개발자가 모든 Repository를 볼 필요도 없다

이번 티빙 조사 결과에서 상당히 눈에 띄는 부분이 모든 개발자에게 전체 개발 프로젝트 접근 권한이 부여돼 있었다는 것이다.

이건 공격자 입장에서 굉장히 좋다.

한 명만 뚫으면 된다.

Developer A Credential
        ↓
ALL PROJECTS

좋은 구조는 다르다.

Developer A
→ iOS

Developer B
→ Backend Payment

Developer C
→ Recommendation

Security Team
→ Security Project

그리고 필요할 때만 일시적으로 추가 권한을 준다.

이것이 Least Privilege다.

OWASP 역시 CI/CD와 개발 환경에서 개발자에게 필요한 기능만 허용하고 Project 관리 권한이나 불필요하게 높은 권한을 주지 않는 것을 권장한다.

9. 여기에서도 AI를 사용할 수 있다

재미있는 시스템을 하나 만들 수 있다.

Permission Review Agent다.

예를 들어 매일 새벽:

Security Agent

GitHub
AWS IAM
Secrets Manager
CI
Kubernetes

의 Metadata를 읽는다.

그리고:

Developer A

최근 60일:
ios-app만 작업

현재 권한:
ios-app
backend
billing
infra
data-pipeline

를 발견한다.

Agent가:

권한 과다 가능성

을 Security Queue에 올린다.

다만 AI가 직접 Permission을 제거하면 위험하다.

따라서:

AI
→ 과도한 권한 후보 탐지

Policy Engine
→ 규칙 확인

Security/Human
→ 승인

IAM
→ 실제 변경

형태가 적절하다.

10. Security Agent가 매 PR마다 보는 Architecture

11. Security Agent는 Diff만 보면 안 된다

예를 들어 PR에 이런 코드가 추가됐다고 하자.

logger.info("login user: \(user)")

컴파일도 된다.

Test도 통과한다.

Secret Scanner도 아무것도 못 찾는다.

하지만 user 안에:

email
phone
CI
birthDate

같은 개인정보가 들어 있다면 문제가 될 수 있다.

AI Reviewer가 Repository의 User 모델과 Logging 코드를 함께 보면:

PII Logging Risk

를 발견할 가능성이 있다.

이게 AI Security Review가 일반 정적 분석 위에서 할 수 있는 일이다.

12. PR에 새로운 권한이 생기면 Security Review를 자동 승격한다

모든 PR을 최고 수준으로 Review할 필요는 없다.

Risk를 분류한다.

LOW

UI
String
Layout
Test

MEDIUM

Network API
Local Storage
Dependency

HIGH

Authentication
Authorization
User Data
Encryption
Cloud IAM
Payment

CRITICAL

Production Credential
DB Migration
Admin Permission
Secret Management
Public Network Exposure

그리고:

LOW
→ 일반 CI

MEDIUM
→ AI Security Review

HIGH
→ AI + Security Tool + Human

CRITICAL
→ Human Approval 필수

로 간다.

13. GitHub Branch Protection과 결합한다

AI가 보안 경고를 했는데 개발자가:

일단 Merge하고 다음 Sprint에서 고치죠.

라고 할 수 있다.

그래서 Policy가 필요하다.

예:

CRITICAL
→ Merge Block

HIGH
→ Security Approval Required

MEDIUM
→ Warning

LOW
→ Advisory

CodeQL 역시 Repository 설정에 따라 Code Scanning Check를 Required Check로 만들어 문제가 해결되기 전 Merge를 막을 수 있다.

즉 중요한 것은:

AI가 말했다.

가 아니다.

Policy가 Merge를 막았다.

이다.

14. 이번 사고를 기준으로 가장 먼저 막아야 할 것은 Secret이다

추천 Pipeline의 첫 번째 Gate는 아주 단순하다.

Developer
   ↓
Local Commit
   ↓
Secret Scan
   ↓
Git Push
   ↓
Push Protection

Secret이 발견되면:

STOP

이다.

“다음에 고치기”가 없다.

GitHub Push Protection에서는 예외적으로 Bypass할 수도 있지만, 조직에서는 Delegated Bypass를 통해 별도 Reviewer 승인 절차를 둘 수 있다.

즉:

개발자가 스스로 우회

보다:

Security Reviewer 승인 필요

가 훨씬 안전하다.

15. Secret이 유출됐으면 삭제보다 Rotation이 먼저다

개발팀에서 의외로 자주 나오는 오해가 있다.

Git에서 Key 지웠습니다.

그러면 끝난 게 아니다.

이미 Commit History에 존재할 수도 있고 외부로 복제됐을 수도 있다.

Credential이 노출됐다고 판단되면:

Revoke

↓

Rotate

↓

사용처 변경

↓

Git History 정리

↓

Access Log 확인

순서가 더 중요하다.

AWS Secrets Manager도 Secret Rotation을 자동화할 수 있다.

AI Security Agent가 Secret 발견 시 바로 이런 Runbook을 생성하도록 할 수 있다.

16. AI에게 Incident Runbook도 맡길 수 있다

예를 들어 Security Agent가 Production Credential 노출을 발견했다.

그러면:

CRITICAL: AWS Credential exposed

만 남기지 않는다.

자동으로:

1. Credential revoke 후보
2. 영향을 받는 Service
3. 최근 사용 기록
4. 접근 가능한 Resource
5. Rotation 대상
6. 관련 Repository
7. 관련 Deployment

를 정리한다.

그리고 Security 담당자가:

EXECUTE

를 승인한다.

이런 것이 AI의 좋은 사용 방식이다.

17. Runtime까지 가면 AI의 역할이 더 커진다

티빙 사고에서는 공격자가 5월 30일 1차 데이터 유출을 시도했고 DB Server 과부하로 이상징후가 감지돼 차단됐지만, 다음 날 가상서버를 생성해 이용자 정보 약 24GB를 저장한 뒤 외부로 유출하고 가상서버를 삭제한 것으로 조사됐다.

여기에서 중요한 질문이 생긴다.

왜 CPU가 올라갔는지는 봤는데

누가

어떤 Credential로

어떤 DB에서

얼마나 많은 데이터를 읽어

어디로 전송했는지는

즉시 연결되지 않았는가?

Runtime Security는 CPU 그래프만 봐서는 부족하다.

18. AI Security Agent는 Runtime Event를 연결하는 데 유용하다

예를 들어 이런 Event가 동시에 발생한다.

03:11
새 VM 생성

03:14
DB SELECT 급증

03:16
Data Transfer 증가

03:18
평소 사용하지 않던 Credential 사용

03:21
해외 IP 연결

03:25
VM 삭제

각 이벤트 하나만 보면 정상일 수도 있다.

하지만 연결하면:

Possible Data Exfiltration

이다.

이런 Cross-system Correlation이 AI가 잘할 수 있는 영역이다.

CloudTrail
+
VPC Flow Log
+
DB Audit Log
+
IAM
+
Git Deployment
+
SIEM

을 연결해 설명한다.

19. 그렇다고 AI에게 실시간 차단권을 바로 주면 안 된다

예를 들어 AI가:

공격 같습니다.

라고 판단했다고 Production DB 전체를 끊으면 장애가 발생할 수 있다.

그래서 자동화 수준을 나눈다.

OBSERVE
→ 로그 분석

ALERT
→ Security Team 호출

CONTAIN
→ Session Kill / Key Disable 후보 제시

AUTO-CONTAIN
→ 명확한 규칙일 때만 자동 차단

예를 들어:

Retired Credential 사용

Revoked Key 사용

Impossible Travel

금지된 국가에서 Admin Token 사용

같은 명백한 상황은 자동 대응 가능성이 높다.

반면:

데이터 조회량이 조금 많음

같은 것은 Human Review가 필요하다.

20. 결국 AI보다 먼저 필요한 건 로그다

AI가 아무리 강해도 Logging이 없으면 못 본다.

이번 조사에서도 일부 시스템 기록이 약 6일만 보관됐고 신규 장비에 로그관리 정책이 제대로 적용되지 않은 문제가 확인됐다.

AI Security Agent에게:

지난달 공격자가 무엇을 했지?

라고 물어도 Log가 없으면 답할 수 없다.

따라서 먼저:

누가

언제

어떤 Credential로

어떤 Resource에

어떤 Action을 했고

얼마나 데이터를 읽었는가

가 남아야 한다.

AI는 그 위에 올라간다.

21. Security Agent가 매일 새벽에 자동 점검하게 한다

개발자가 Security Dashboard를 매일 확인하지 않을 수 있다.

AI는 할 수 있다.

예를 들어 매일 새벽:

Security Agent

01. Git Secret Alert 확인
02. IAM 신규 권한 확인
03. Admin 권한 증가 확인
04. 오래된 Access Key 확인
05. Rotation 안 된 Secret 확인
06. 새로운 Public Endpoint 확인
07. 새로운 Dependency 확인
08. 최근 Critical Code Scan 확인
09. 비정상 Production Access 확인
10. 미해결 Security Finding 확인

을 수행한다.

결과가 없으면 아무것도 하지 않는다.

문제가 있으면:

Security Inbox

에 올린다.

22. 특히 “발견됐지만 안 고친 문제”를 AI가 추적하게 한다

이번 조사 결과에서 가장 아픈 부분 중 하나는 2024년 모의해킹에서 접속키 노출 문제가 발견됐지만 개선되지 않았다는 것이다.

보안에서는 발견보다 Closure가 중요하다.

그래서 Security Finding에 상태를 둔다.

OPEN
↓
ASSIGNED
↓
FIXED
↓
VERIFIED
↓
CLOSED

그리고:

OPEN → 7일
HIGH

OPEN → 30일
CRITICAL ESCALATION

같은 규칙을 둔다.

AI가 매일:

90일째 열린 HIGH Finding 3건

을 찾아 Security Lead와 개발 책임자에게 올린다.

23. 모의해킹 보고서도 PDF로 끝나면 안 된다

흔한 구조:

Pentest
↓
PDF
↓
메일
↓
회의
↓
보관

좋은 구조:

Pentest
↓
Findings DB
↓
Owner
↓
Deadline
↓
Fix
↓
Automated Verification
↓
Retest
↓
Close

이다.

AI는 여기서 Pentest 보고서를 읽고 Finding을 Issue로 구조화하는 데 매우 유용하다.

24. 보안 전담인력이 적을수록 AI가 더 의미 있을 수 있다

이번 조사에서 티빙 임직원 265명 가운데 개발인력은 149명, 정보보호 전담인력은 약 4명 수준으로 조사됐다. 조사단은 이런 인력 규모로 상시 관제·취약점 점검·이상행위 모니터링 등에 한계가 있었다고 판단했다.

개발자 149명의:

PR

Dependency

IAM

Secret

Cloud

API

Database

Log

를 4명이 모두 수동으로 보는 것은 현실적으로 어렵다.

여기서 AI가 의미가 있다.

AI는 보안 전문가를 없애는 것이 아니라:

149명 개발자
       ↓
AI Security Layer
       ↓
중요한 20건
       ↓
Security Team

으로 Noise를 줄인다.

25. 추천하는 전체 Architecture

실제 개발팀이라면 이 구조가 가장 현실적이다.

                       Developer
                           │
                           ▼
                    Coding Agent
                           │
                           ▼
                       Git Commit
                           │
                           ▼
                Secret / Credential Scan
                           │
                     Secret 발견?
                    YES ───────→ BLOCK
                           │
                           ▼
                     Pull Request
                           │
          ┌────────────────┼────────────────┐
          ▼                ▼                ▼
       CodeQL         Dependency        AI Security
        SAST            Review            Review
          │                │                │
          └────────────────┼────────────────┘
                           ▼
                     Security Score
                           │
                ┌──────────┼──────────┐
                ▼          ▼          ▼
               LOW       HIGH      CRITICAL
                │          │          │
                ▼          ▼          ▼
               CI       Security    Human
                          Review    Approval
                           │
                           ▼
                        Deploy
                           │
                           ▼
                       Runtime
                           │
           ┌───────────────┼────────────────┐
           ▼               ▼                ▼
         IAM Log        DB Audit        Network Flow
           │               │                │
           └───────────────┼────────────────┘
                           ▼
                   AI Security Monitor
                           │
                이상 행동 Correlation
                           │
               ┌───────────┴───────────┐
               ▼                       ▼
             ALERT                 AUTO-CONTAIN
               │                 명확한 Rule만
               ▼
          Security Team

AI 하나가 모든 것을 지키는 구조가 아니다.

AI가 여러 기존 보안 시스템 사이에서 놓친 연결을 찾는 구조다.

26. Repository는 이렇게 구성할 수 있다

project/
├── AGENTS.md
├── SECURITY.md
│
├── .security/
│   ├── policy.yaml
│   ├── data-classification.yaml
│   ├── permissions.yaml
│   └── exceptions.yaml
│
├── skills/
│   ├── security-review/
│   ├── dependency-review/
│   └── incident-triage/
│
├── src/
└── tests/

SECURITY.md에는 인간이 읽을 원칙을 두고,

.security/policy.yaml에는 기계가 읽을 규칙을 둔다.

27. 예를 들어 Security Policy

secret:
  hardcoded: deny
  production_key_in_repo: deny

permissions:
  new_admin_permission: human_approval
  wildcard_resource: security_review

data:
  pii_logging: deny
  bulk_export: security_review

network:
  new_public_endpoint: security_review

dependencies:
  critical_vulnerability: deny

production:
  direct_developer_access: deny

이렇게 만들어 두면 AI Security Agent 역시 이 Policy를 기준으로 판단할 수 있다.

28. Coding Agent도 같은 규칙을 먼저 읽게 한다

이제 Codex나 Claude Code에게 기능을 구현시키기 전에:

AGENTS.md
SECURITY.md
.security/policy.yaml

을 읽게 한다.

그러면 구현 단계부터:

Secret을 어디에 둘 것인가

새 Permission이 필요한가

PII를 다루는가

Public Endpoint인가

Logging에 개인정보가 들어가는가

를 확인한다.

즉 Security Review가 PR 마지막에서만 발생하지 않는다.

Design
→ Implementation
→ Review
→ Runtime

전체에 들어간다.

29. AI가 개발자의 보안 습관까지 조금씩 바꿀 수 있다

예를 들어 Agent가 매번:

이 변경은 Production IAM 권한이 추가되므로
Security Review가 필요합니다.

라고 알려준다.

또:

이 Credential은 장기 Access Key 대신
Role 기반 Temporary Credential을 사용할 수 있습니다.

라고 제안한다.

이게 반복되면 개발자도 자연스럽게:

Credential
→ Secrets Manager

Permission
→ Least Privilege

Production
→ Temporary Role

PII
→ Redaction

을 기본값으로 생각하기 시작한다.

30. 하지만 AI가 보안 책임자가 되어서는 안 된다

이 글에서 가장 중요한 선이다.

AI가 있으니
보안팀이 없어도 된다.

가 아니다.

오히려 반대다.

AI가 필요한 이유는:

Security Team의 시간을
정말 중요한 판단에 사용하기 위해서

다.

AI Security Agent는:

찾기

분류

연결

요약

추적

을 잘한다.

사람은:

위험 수용

Architecture 결정

Incident 대응

법적 판단

Production 차단 결정

을 맡는다.

31. 티빙 사고에서 배울 가장 중요한 것은 “한 번의 실수”가 아니다

이번 사고는 개발자의 Credential 하나가 탈취된 것에서 시작했지만 조사 결과를 보면 그 뒤로 여러 방어선이 연속해서 제대로 작동하지 않았다.

Access Key 관리

Repository Secret

Project Permission

Production Credential

Network Access Control

DB Monitoring

Data Flow Detection

Log Retention

Incident Escalation

Vulnerability Closure

이 중 몇 개만 제대로 작동했어도 피해 규모는 달라졌을 가능성이 있다.

따라서 문제를:

개발자가 Key를 잘못 관리했다.

로 끝내면 다시 비슷한 사고가 난다.

보안에서 인간의 실수를 없앨 수는 없다.

대신 한 번의 인간 실수가 대규모 사고가 되지 못하도록 설계할 수 있다.

마무리

티빙 침해사고는 최신 Zero-day 하나 때문에 모든 것이 무너진 사건으로 보기는 어렵다.

2026년 9월 3일 공개된 민관합동조사 결과에서는 개발환경 접속키 관리, 전체 프로젝트 접근권한, 소스 내 운영환경 Credential, 미조치된 기존 취약점, 부족한 이상징후 탐지, 짧은 로그 보관, 사고 보고 지연까지 여러 문제가 함께 확인됐다.

그래서 개발팀이 얻어야 할 결론도:

개발자들에게 보안 교육을 더 하자.

에서 끝나면 부족하다.

교육은 필요하다.

하지만 사람은 다시 실수한다.

더 강한 구조는 이렇다.

Developer
   ↓
Coding Agent
   ↓
Secret Guard
   ↓
AI Security Review
   ↓
CodeQL / Dependency Scan
   ↓
Policy Gate
   ↓
CI
   ↓
Runtime Monitoring
   ↓
AI Correlation
   ↓
Security Team

즉 보안을:

사람이 잘 기억해야 하는 규칙

에서:

어기기 어려운 시스템의 기본값

으로 바꾸는 것이다.

그리고 AI가 들어가면서 한 가지 새로운 선택지가 생겼다.

기존 보안 Tool이:

Secret 발견

취약점 발견

Dependency 문제 발견

을 한다면 AI Security Agent는 그 위에서:

왜 위험한가

무엇과 연결되는가

어디까지 영향을 주는가

다음에 무엇을 해야 하는가

아직 해결되지 않은 문제는 무엇인가

를 계속 추적할 수 있다.

특히 보안 전담인력이 개발조직에 비해 작은 회사라면 의미가 크다.

AI가 보안 전문가를 대신하는 것이 아니다.

보안 전문가가 모든 PR과 모든 IAM 변경과 모든 로그를 직접 보지 않아도 되도록, AI가 먼저 의심하고 자동화된 시스템이 먼저 막게 만드는 것이다.

궁극적인 목표는:

AI가 보안을 잘한다.

가 아니다.

더 좋은 시스템은:

개발자가 실수하고

AI가 놓치고

Security Reviewer도 놓쳐도

마지막 Policy와 Runtime Control이
사고를 막는다.

이다.

보안은 사람의 주의력에 의존할수록 약해지고, 여러 독립된 시스템이 서로를 검증할수록 강해진다.

AI는 그 방어선 중 하나가 될 수 있다.

그리고 2026년의 개발환경이라면 이제는 그 방어선을 굳이 빼둘 이유도 없다.

참고 자료

2026년 9월 3일 과학기술정보통신부 민관합동조사 결과를 인용한 연합뉴스 보도에 따르면 티빙 사고에서는 약 3,954만 계정과 소스코드를 포함한 기술자산 361건이 유출됐으며, 개발·운영환경 Credential 관리, 프로젝트 접근권한, 이상징후 탐지·보고, 취약점 개선 등 여러 보안 통제가 함께 미흡했던 것으로 조사됐다. 개인정보보호위원회는 개인정보 유출 규모와 관련 법 위반 여부 등을 별도로 조사하고 있다.

GitHub의 Secret Scanning과 Push Protection은 Source와 Git History에서 Credential을 탐지하고, 지원되는 Secret이 Repository에 들어가기 전에 Push 자체를 차단할 수 있다. CodeQL과 Code Scanning은 Pull Request 단계에서 보안 취약점을 탐지하고 Required Check로 활용할 수 있다.

AWS Well-Architected Security guidance는 장기간 Access Key를 Source Code나 설정 파일에 넣는 방식을 피하고, 가능한 경우 IAM Role 기반의 단기 Credential을 사용하며 필요한 Secret은 전용 Secret 관리 시스템에서 관리·회전하도록 권고한다.

핵심 참고 포인트

이번 사고에서 가장 중요한 교훈은 특정 개발자의 실수 하나가 아니라 Credential → Repository → Production → Database로 이어지는 공격 경로를 중간에서 차단할 독립적인 보안 통제가 충분히 작동하지 않았다는 점이다.

따라서 AI Security Agent 역시 단독 방어책으로 두면 안 된다. 가장 현실적인 구조는 Secret 차단 → 최소권한 → AI Security Review → 정적 분석 → CI Policy → Runtime Monitoring → Incident Response를 겹쳐 놓고, AI는 그 사이에서 Context 분석·우선순위·미해결 Finding 추적을 담당하게 만드는 것이다.

Codex 멀티에이전트 구현 + Claude Review·QA 개발 환경

Wed, 02 Sep 2026 03:11:45 GMT

Codex 멀티에이전트 구현 + Claude Review·QA 개발 환경

AI Coding Agent를 처음 사용할 때는 대부분 한 명의 개발자를 하나의 Agent로 대체하는 형태에서 시작한다.

Developer
   ↓
Coding Agent
   ↓
Code

하지만 최근 Coding Agent가 긴 작업을 처리하고, 여러 Repository를 동시에 다루며, Build와 Test까지 수행하기 시작하면서 구조가 조금씩 달라지고 있다.

이제 개인 개발자도 이런 환경을 만들 수 있다.

                     나
                     │
                     ▼
              Codex Orchestrator
                     │
          ┌──────────┼──────────┐
          ▼          ▼          ▼
      조사 Agent   구현 Agent   테스트 Agent
          │          │          │
          └──────────┼──────────┘
                     ▼
                  변경 코드
                     │
                     ▼
               Claude Review
                     │
                     ▼
                 Codex 수정
                     │
                     ▼
                 Claude QA
                     │
                     ▼
              Runtime Evidence
                     │
                     ▼
                  Human Gate

여기서 핵심은 단순히 Agent를 여러 개 실행하는 것이 아니다.

Codex가 구현 조직을 관리하고 Claude를 독립적인 검증 계층으로 분리하는 것이다.

OpenAI는 현재 Codex를 여러 Agent를 동시에 관리하는 command center로 설명하고 있으며, 프로젝트별 Thread와 Git worktree를 이용해 여러 Agent가 같은 Repository에서도 서로 충돌하지 않고 병렬 작업할 수 있도록 지원한다. Skills를 이용해 팀이나 개인의 반복적인 작업 방식도 Codex에 정의할 수 있다.

이 기능들을 잘 조합하면 별도의 복잡한 Agent 플랫폼 없이도 꽤 강력한 개인용 AI 개발 조직을 만들 수 있다.

1. 개인 Workspace 자체를 하나의 작은 개발 조직으로 본다

예를 들어 개인 Workspace가 이렇게 되어 있다고 하자.

~/workspace/

├── ios-camera/
├── ios-pantry/
├── android-app/
├── web-dashboard/
├── backend/
├── automation/
└── novel-tools/

각 폴더는 독립된 Git Repository다.

기존에는 개발자가 직접 프로젝트를 옮겨 다녔다.

ios-camera
→ 작업

web-dashboard
→ 작업

backend
→ 작업

Agent 환경에서는 조금 다르게 생각할 수 있다.

                    Workspace
                        │
                        ▼
                     Codex
                        │
        ┌───────────────┼───────────────┐
        ▼               ▼               ▼
    ios-camera      web-dashboard     backend
        │               │               │
      Agent A          Agent B          Agent C

각 Agent는 자신의 Repository에서 독립적으로 작업한다.

그리고 각 프로젝트 안에는 해당 프로젝트만의 규칙을 둔다.

2. 프로젝트마다 AGENTS.md를 따로 둔다

예를 들어 iOS 프로젝트라면:

ios-camera/
├── .git/
├── AGENTS.md
├── Package.swift
├── Sources/
└── Tests/

AGENTS.md:

# 프로젝트 규칙

- Swift 6 기준
- iOS 18 이상
- Swift Concurrency 우선
- UI 상태 변경은 MainActor에서 수행
- 새 외부 라이브러리는 사용자 확인 없이 추가하지 않는다
- 기존 Public API 변경은 확인 후 진행한다
- 구현 후 반드시 Build한다
- 관련 Unit Test가 있으면 실행한다
- 테스트하지 않은 항목은 완료했다고 말하지 않는다

Android라면 전혀 다른 규칙을 둘 수 있다.

# 프로젝트 규칙

- Kotlin
- Jetpack Compose
- Coroutine Structured Concurrency 준수
- StateFlow 사용
- Gradle build 확인
- lint 실행
- 기존 Convention Plugin 규칙 유지

Web:

# 프로젝트 규칙

- Next.js
- TypeScript strict 유지
- 접근성 확인
- Playwright E2E 사용
- Console Error 확인
- Responsive Layout 검증

상위 Codex는 이 모든 세부 규칙을 기억할 필요가 없다.

Workspace Codex
= 어디에서 누가 일할지 결정

각 Repository
= 어떻게 일할지 결정

역할을 분리한다.

3. Codex 멀티에이전트는 ‘모두 코딩’하게 하지 않는다

멀티에이전트를 처음 쓰면 쉽게 이런 구조를 만들게 된다.

Agent A → 구현
Agent B → 구현
Agent C → 구현
Agent D → 구현

하지만 같은 Feature를 여러 Agent가 동시에 수정하면 오히려 관리가 어려워진다.

더 안정적인 구조는 역할을 나누는 것이다.

Research Agent
READ ONLY

Architecture Agent
READ ONLY

Implementation Agent
WRITE

Test Agent
READ + EXECUTE

즉:

병렬 조사
   ↓
결과 취합
   ↓
한 Agent가 구현

방식이다.

독립적인 작업만 병렬화한다.

4. 예를 들어 iOS Camera 버그 하나를 맡긴다면

Goal:

동영상 촬영 중 간헐적으로
AVAssetWriter append가 실패하는 원인을 찾아 수정한다.

상위 Codex가 바로 코드부터 수정하지 않는다.

먼저 작업을 나눈다.

Research Agent A
→ CaptureSession / Frame Pipeline 조사

Research Agent B
→ AVAssetWriter 사용 구조 조사

Research Agent C
→ 관련 Test / Log / Error Path 조사

세 Agent는 동시에 조사할 수 있다.

                 Codex
                   │
       ┌───────────┼───────────┐
       ▼           ▼           ▼
 Frame 조사    Writer 조사    Log 조사
       │           │           │
       └───────────┼───────────┘
                   ▼
              조사 결과 취합

그다음 Implementation Agent 하나가 실제 수정한다.

5. 같은 Repository에서는 Worktree를 이용한다

여러 Agent가 동일 Repository에서 작업할 때 가장 중요한 것이 Git 격리다.

Codex 앱은 Worktree를 기본 지원한다.

각 Agent가:

main repository

├── worktree-research-a
├── worktree-research-b
├── worktree-implementation
└── worktree-test

처럼 독립된 코드 복사본에서 작업할 수 있다.

OpenAI도 Codex 앱에서 여러 Agent가 동일 Repository를 동시에 작업할 때 각 Agent가 별도의 Worktree를 이용하기 때문에 로컬 Git 상태를 건드리지 않고 다양한 접근을 병렬로 시도할 수 있다고 설명한다.

이게 멀티에이전트에서 굉장히 중요하다.

6. Codex를 ‘코더’가 아니라 Tech Lead로 사용한다

상위 Codex 역할은 직접 모든 코드를 작성하는 것이 아니다.

다음에 더 가깝다.

Goal 분석

↓

작업 분해

↓

Agent 배치

↓

결과 수집

↓

구현 방향 선택

↓

Build / Test

↓

검증 Agent에게 전달

즉:

Codex Orchestrator
=
PM
+
Tech Lead

처럼 사용한다.

실제 수정은 하위 Agent가 담당한다.

7. Skills로 오케스트레이션 규칙을 고정한다

매번 Codex에게:

먼저 조사하고
병렬 Agent를 띄우고
한 Agent만 수정하고
테스트하고
Claude Review하고...

라고 설명할 필요는 없다.

Skill로 만든다.

예를 들어:

engineering-orchestrator

Skill의 핵심 Goal:

# 목표

독립적인 조사 작업은 Codex subagent로 병렬 수행한다.

실제 Repository 수정은 명확한 소유권을 가진
하나의 Implementation Agent가 담당한다.

구현 완료 후 자동 검증을 수행한다.

그 후 Claude를 독립 Reviewer로 사용한다.

Critical 또는 Major 문제가 발견되면
Codex가 수정하고 다시 Review한다.

Review를 통과한 뒤 Claude QA를 실행한다.

QA에서 문제가 발견되면 다시 Codex로 반환한다.

Critical / Major가 모두 해결되고
필수 Runtime 검증이 끝났을 때만 완료한다.

실행 순서:

1. Goal 확인
2. Repository 규칙 확인
3. 작업 분해
4. 조사 Agent 병렬 실행
5. 결과 취합
6. 구현
7. Build/Test
8. Claude Review
9. 수정
10. Re-review
11. Claude QA
12. 수정
13. Re-QA
14. 결과 보고

OpenAI는 Skills를 반복 가능한 작업 방법, 팀의 표준, 도구 사용 방법 등을 Codex에 제공하는 방식으로 설명하고 있다.

8. Codex만으로 구현과 테스트까지 처리한다

첫 번째 검증 계층은 AI Reviewer가 아니다.

Compiler
Test
Lint
Runtime

다.

예를 들어 iOS라면:

Implementation
      ↓
xcodebuild
      ↓
Unit Test
      ↓
필요한 Simulator 검증

Android:

Implementation
      ↓
Gradle
      ↓
Unit Test
      ↓
Lint
      ↓
Emulator

Web:

Implementation
      ↓
Type Check
      ↓
Unit Test
      ↓
Build
      ↓
Playwright

Agent가:

수정했습니다.
문제 없습니다.

라고 말하는 건 검증이 아니다.

9. 그다음에 Claude를 독립 Reviewer로 붙인다

여기서 Claude가 들어간다.

Codex가 구현했다면 Claude는 코드를 수정하지 않는다.

Codex
= 작성자

Claude
= Reviewer

로 분리한다.

Claude에게 전달할 것은:

Task 목표

Acceptance Criteria

Git Diff

관련 Architecture

관련 Test

프로젝트 규칙

정도다.

그리고 Reviewer Prompt를 고정한다.

이 변경을 독립 Reviewer 관점에서 검토해.

구현을 수정하지 마.

다음 항목에 대해서만
실제 근거가 있는 문제를 보고해.

- Correctness
- Concurrency
- State
- Architecture
- Error handling
- Regression 가능성
- Missing Test
- Security
- Accessibility

결과는:

Critical
Major
Minor
Missing Tests
Not Verified

로 분류해.

10. Claude에게 전체 작업 History를 주지 않는 것도 중요하다

Codex가 구현 과정에서:

왜 이 구조를 선택했는지
어떤 시행착오가 있었는지

를 모두 Claude에게 알려주면 Reviewer도 영향을 받을 수 있다.

독립 Review라면 오히려:

Task

Diff

현재 코드

검증 결과

중심으로 주는 것이 좋다.

그러면:

Codex
→ 구현 당시의 가정

Claude
→ 결과물 자체 평가

가 분리된다.

11. Review 결과는 다시 Codex로 반환한다

예:

Claude Review

CRITICAL
없음

MAJOR

1.
Task cancellation 이후에도
state mutation이 발생할 가능성이 있음.

2.
Error path에서 기존 retry state가 초기화되지 않음.

MINOR

Naming 1건.

상위 Codex는 이걸 받는다.

Claude Findings
       ↓
Codex 판단
       ↓
Implementation Agent 수정
       ↓
Build
       ↓
Tests

그리고 다시 Claude에게 보낸다.

12. Re-review를 반드시 한다

Workflow:

Claude Review
     ↓
문제 발견
     ↓
Codex Fix
     ↓
Claude Re-review

완료 조건:

Critical = 0
Major = 0

로 정할 수 있다.

Minor는 필요에 따라 처리한다.

이렇게 하면 Review Agent가 단순히 참고 의견만 주고 사라지는 구조가 아니다.

13. Review와 QA는 같은 Claude Session으로 하지 않는다

여기서 역할을 한 번 더 분리한다.

Claude Review Agent

Source
Diff
Architecture
Tests

를 본다.

반면:

Claude QA Agent

실행된 앱
User Goal
UI
Runtime
Recording
Logs

를 본다.

즉:

Review
= 코드에서 문제를 예측

QA
= 실제 실행해서 문제를 발견

이다.

14. iOS QA라면

현재 사용 가능한 도구를 기준으로 구성한다.

Claude QA
    │
    ▼
iOS Simulator
    │
    ├── UI Interaction
    ├── Accessibility
    ├── Screenshot
    ├── Screen Recording
    └── Runtime Log

예를 들어:

처음 사용하는 사용자가

1. 카메라 화면 진입
2. 필터 선택
3. 동영상 촬영
4. 촬영 종료
5. 저장

까지 수행한다.

단순히 기능이 되는지만 보는 것이 아니다.

Tap 실패

버튼 발견 시간

Retry

Backtrack

반응 지연

Keyboard/Overlay

잘못된 Navigation

도 확인한다.

15. Android QA도 같은 원칙이다

Claude QA
    │
    ▼
Android Emulator
    │
    ├── Semantics
    ├── UIAutomator
    ├── Screenshot
    ├── Recording
    └── Logcat

Element를 찾을 때도:

Semantic
↓
Accessibility
↓
Text
↓
Identifier
↓
Visual
↓
Coordinate

순서로 접근한다.

좌표 Tap부터 시작하지 않는다.

16. Web에서는 Playwright를 붙이기가 가장 좋다

현재 Web이 Agentic QA를 만들기 가장 좋은 환경이다.

Claude QA
   │
   ▼
Playwright
   │
   ├── DOM
   ├── ARIA
   ├── Browser Interaction
   ├── Video
   ├── Trace
   ├── Console
   └── Network

Playwright는 현재 공식적으로 Planner, Generator, Healer 형태의 Test Agent Workflow도 제공하고 있어 Agent가 앱을 탐색하고 테스트 계획을 만들거나 실패한 테스트를 다시 조사하는 구조를 만들 수 있다.

Claude QA와 결합하면:

User Scenario
     ↓
Browser 사용
     ↓
Problem
     ↓
Screenshot / Video / Trace
     ↓
Finding

형태가 된다.

17. QA에서 동일 실패를 반복하게 두지 않는다

Agent QA를 실제 돌리면 자주 발생하는 문제가 있다.

버튼 Tap
   ↓
실패
   ↓
같은 버튼 Tap
   ↓
실패
   ↓
다시 Tap

이건 좋은 QA가 아니다.

QA Skill에 규칙을 넣는다.

동일한 목표에서
동일하거나 실질적으로 동일한 행동이
2회 실패하면

세 번째 동일 행동을 실행하지 않는다.

대신:

STOP

↓

현재 화면 다시 관찰

↓

Semantic Tree 재확인

↓

Keyboard / Modal / Overlay 확인

↓

Navigation State 확인

↓

다른 탐색 전략

으로 간다.

18. Agent 실패와 Product 실패도 분리한다

Claude가 버튼을 못 찾았다고:

UX가 나쁘다.

고 바로 결론내리면 안 된다.

원인은 적어도 네 종류다.

PERCEPTION
화면을 잘못 이해

LOCALIZATION
Element 위치를 잘못 찾음

AUTOMATION
Tap 자체 실패

PRODUCT
실제 앱 문제

QA 결과에는 이 분류를 같이 남기게 한다.

19. QA Evidence를 남긴다

QA Agent의 결과가:

테스트했습니다.
정상입니다.

이면 부족하다.

예:

Scenario
영상 촬영 후 저장

Functional
PASS

Expected Actions
5

Actual Actions
6

Retry
1

Backtrack
0

Runtime
Crash 0

UX Finding
저장 처리 시작까지 약간의 피드백 지연 존재

Evidence
recording.mov
actions.jsonl
screenshots/005.png

Not Verified
Physical Device

정도가 되어야 한다.

20. QA Finding도 다시 Codex로 돌아간다

예를 들어 Claude QA가:

MAJOR

저장 버튼 Tap 후
약 2초간 Feedback이 없어
사용자가 다시 Tap할 가능성이 있음.

을 찾았다.

그럼:

Claude QA Finding
       ↓
Codex
       ↓
관련 State 조사
       ↓
Loading 표시 수정
       ↓
Build/Test
       ↓
Claude QA 2

를 돌린다.

21. 결국 전체 개발 Loop는 이렇게 된다

                         HUMAN
                           │
                           ▼
                   Codex Orchestrator
                           │
          ┌────────────────┼────────────────┐
          ▼                ▼                ▼
      Research         Architecture      Test Analysis
       Codex              Codex              Codex
          │                │                 │
          └────────────────┼─────────────────┘
                           ▼
                    Implementation
                         Codex
                           │
                           ▼
                   Build / Test / Lint
                           │
                           ▼
                    Claude Review
                           │
                    문제 발견?
                    │           │
                   YES         NO
                    │           │
                    ▼           ▼
                Codex Fix    Claude QA
                    │           │
                    ▼           ▼
               Build/Test   Runtime Test
                    │           │
                    └─────┐     │
                          ▼     ▼
                       Re-review
                           │
                           ▼
                        Re-QA
                           │
                           ▼
                    Final Evidence
                           │
                           ▼
                         HUMAN

개인 개발 환경에서도 충분히 현실적인 구조다.

22. 여러 프로젝트를 동시에 돌리면 더 재미있어진다

Workspace가:

workspace/

├── ios-camera/
├── ios-pantry/
├── android/
├── web/
└── backend/

라고 하자.

Codex에서는 서로 다른 Project Thread를 동시에 실행할 수 있다. OpenAI는 현재 Codex를 여러 Agent가 프로젝트를 넘나들며 병렬 작업하는 command center로 설명한다.

예:

                   Codex Workspace
                          │
        ┌─────────────────┼─────────────────┐
        ▼                 ▼                 ▼
    ios-camera           web             backend
        │                 │                 │
  Codex Agent Team   Codex Agent Team  Codex Agent
        │                 │                 │
   Claude Review      Claude Review     Tests
        │                 │
    Claude QA          Claude QA

한 프로젝트가 Build되는 동안 다른 프로젝트 Agent는 Repository 조사를 할 수 있다.

23. 상위 Workspace에는 얇은 규칙만 둔다

예:

# Workspace 운영 규칙

- 각 Agent는 지정된 Repository 안에서만 작업한다.
- Repository의 AGENTS.md를 최우선한다.
- 독립적인 조사 작업은 병렬화한다.
- 동일 파일을 수정하는 Agent를 동시에 실행하지 않는다.
- 구현 Agent와 Review Agent 역할을 분리한다.
- Build/Test 없이 완료 처리하지 않는다.
- Claude Review의 Critical/Major가 0일 때만 QA로 진행한다.
- QA의 주요 문제를 해결하지 않은 상태로 DONE 처리하지 않는다.

프로젝트 세부 규칙은 각 Repository에 둔다.

24. Workspace에는 Task Board 하나를 두면 편하다

예:

TASKS.md

내용:

RUNNING

IOS-114
동영상 저장 실패 조사

WEB-081
결제 Flow 개선


REVIEW

ANDROID-044
로그인 상태 처리


QA

IOS-110
필터 촬영 Flow


DONE

WEB-080
프로필 UI

상위 Codex는 이걸 보고 다음 작업을 선택한다.

개인 개발자에게도 상당히 유용하다.

25. Codex가 모든 결정을 하게 하지는 않는다

자동으로 처리해도 되는 것:

Formatting

작은 Refactor

Test 작성

Build 오류 수정

명확한 Bug Fix

확인이 필요한 것:

Public API 변경

Architecture 변경

새 Dependency

Database Schema

Auth 구조

사람에게 남길 것:

Production Deploy

Security Policy

중요 Product 결정

대규모 데이터 Migration

즉:

AUTO

CONFIRM

HUMAN ONLY

세 단계로 나눈다.

26. 최종 완료 조건도 명확하게 만든다

Agent가:

작업 완료했습니다.

라고 말한다고 완료가 아니다.

예를 들어:

Implementation 완료

Build PASS

Tests PASS

Claude Review
Critical 0
Major 0

Claude QA
Functional PASS

확인하지 못한 항목 명시

Git Diff 확인 가능

정도가 완료 조건이다.

27. 가장 중요한 목표는 Agent 숫자를 늘리는 게 아니다

멀티에이전트를 구축하다 보면 쉽게:

Agent 10개

Agent 20개

가 목표가 된다.

하지만 실제 병목은 사람이다.

Agent Throughput
↑↑↑

Human Review
→

Agent가 하루에 PR을 20개 만들어도 사람이 검토하지 못하면 아무 의미가 없다.

그래서 오케스트레이션의 목표는:

더 많은 Agent

가 아니라:

더 적은 Human Attention으로
더 신뢰할 수 있는 Change

를 만드는 것이다.

28. Codex + Claude 구조의 장점

이 구조에서 역할이 매우 명확하다.

Codex
= 생산

Claude
= 독립 검증

Build/Test/Runtime
= 증거

Human
= 최종 판단

특정 모델 하나의 자기 검증에 의존하지 않는다.

그리고 모델이 바뀌어도 Workflow 자체는 유지할 수 있다.

나중에:

Codex → 다른 구현 Agent

Claude → 다른 Review Agent

로 교체해도:

Goal
→ 구현
→ 검증
→ QA
→ Human

구조는 그대로 남는다.

29. 결국 개인 개발자도 작은 AI 개발팀을 운영하게 된다

예전 개인 개발:

나

기획
설계
개발
테스트
QA
Review

Agent 환경:

                  나
                  │
                  ▼
             Goal / 판단
                  │
                  ▼
               Codex
       ┌──────────┼──────────┐
       ▼          ▼          ▼
     조사        구현       테스트
                  │
                  ▼
                Claude
             Review / QA
                  │
                  ▼
              Evidence
                  │
                  ▼
                  나

개발자가 직접 모든 작업을 수행하는 것에서 AI 팀의 작업 경계를 설계하고 최종 결과를 판단하는 역할로 조금씩 이동한다.

30. 그렇다면 Orca는 필요 없을까?

꼭 그렇지는 않다.

Codex 안에서만 이런 환경을 구성하면 가장 단순하다는 장점이 있다.

Codex 자체가 이미:

Multi-agent
프로젝트별 Thread
Git Worktree
Skills
Background Work

를 지원하기 때문이다.

하지만 Agent 종류를 더 자유롭게 섞거나, Agent 실행 상태 자체를 별도 시스템에서 관리하고 싶다면 외부 오케스트레이션 계층이 의미가 있다.

대표적인 예가 Orca 계열이다.

31. Orca를 넣으면 구조는 이렇게 바뀐다

                    Human
                      │
                      ▼
                Orchestrator
                      │
                      ▼
                    Orca
        ┌─────────────┼─────────────┐
        ▼             ▼             ▼
      Codex       Claude Code     Cursor
        │             │             │
        └─────────────┼─────────────┘
                      ▼
              Isolated Worktrees

Orca 프로젝트들은 일반적으로 Agent마다 독립 Git worktree를 만들고 여러 Worker를 병렬 실행한 뒤 상태와 결과를 오케스트레이터에 전달하는 방식을 사용한다.

예를 들어 araa47/orca는 각 Worker를 독립 Git worktree와 tmux 환경에 실행하고 background daemon이 Worker 완료·막힘 상태 등을 감시해 상위 오케스트레이터에게 전달한다. Codex·Claude Code·Cursor를 Worker로 사용할 수 있다. 다만 해당 프로젝트 자체가 개인/Hobby 프로젝트라는 점은 감안해야 한다.

다른 orca-cli/orca 구현은 SQLite에 Run 상태를 저장하고, 각 Agent를 Worktree로 격리하며, MCP를 통해 Codex·Claude Code·Cursor·OpenCode 등의 Agent가 Orca를 제어할 수 있도록 설계돼 있다. 작업 의존성을 DAG로 구성하는 Pod 구조도 제공한다.

32. Orca가 Codex Native 방식보다 좋은 경우

다음 같은 상황이다.

Codex만 사용

이 아니라:

Codex

Claude Code

Cursor

OpenCode

다른 Agent

를 동시에 Worker로 사용하고 싶다.

또는:

Agent 상태

Run History

작업 DAG

완료 이벤트

Retry

Worker 교체

를 모델과 분리된 시스템에서 관리하고 싶을 수도 있다.

이런 경우 Orca 같은 별도 Orchestration Layer가 더 자연스럽다.

33. 반대로 개인 개발자라면 Codex Native부터 시작하는 게 좋다

처음부터:

Codex
+
Claude
+
Orca
+
MCP
+
tmux
+
Task DB

를 모두 구성할 필요는 없다.

관리해야 하는 시스템만 늘어난다.

현재 Codex가 제공하는 기능으로 먼저:

Codex Multi-Agent

+

Worktree

+

Skills

+

Claude Review/QA

를 구성해보는 편이 좋다.

필요한 순간이 오면 Orca를 추가한다.

34. 비슷한 효과를 내는 다른 방식도 있다

Orca만 유일한 방법은 아니다.

예를 들어 Orka Agents 계열 프로젝트는 Codex CLI·Claude Code CLI·GitHub Copilot CLI·OpenCode 같은 Repository 기반 Coding Agent Runtime을 하나의 Coordinator 아래에서 실행하고, 장시간 Goal Loop와 Multi-Agent Coordination을 제공하는 방향으로 개발되고 있다.

또 다른 Orca 계열 데스크톱 환경들은 여러 Codex·Claude Code·OpenCode Agent를 각각 Worktree에서 병렬 실행하고 결과를 한 화면에서 비교하는 구조를 제공한다.

그리고 꼭 별도 오케스트레이터를 사용할 필요도 없다.

Claude Code의 Subagent, Codex Multi-Agent, CI Workflow, Git Worktree와 간단한 Task Ledger를 조합해서 직접 작은 오케스트레이션 환경을 만들 수도 있다.

마무리

현재 개인 개발자에게 꽤 현실적인 시작점은 이 구조라고 생각한다.

                    HUMAN
                      │
                      ▼
              Codex Orchestrator
                      │
          ┌───────────┼───────────┐
          ▼           ▼           ▼
       Research    Architecture   Test
        Codex        Codex        Codex
          │           │           │
          └───────────┼───────────┘
                      ▼
               Codex Implementation
                      │
                      ▼
                Build / Test
                      │
                      ▼
                Claude Review
                      │
                 Codex Fix
                      │
                 Re-review
                      │
                      ▼
                  Claude QA
                      │
                Runtime Evidence
                      │
                      ▼
                    HUMAN

이 구조에서 Codex는 단순한 Coding Agent가 아니다.

여러 작업과 Agent를 관리하는 Engineering Orchestrator가 된다.

Claude도 두 번째 Coding Agent로 사용하지 않는다.

Claude Review
Claude Runtime QA

라는 독립 검증 계층으로 사용한다.

그리고 가장 중요한 판단은 AI가 아니라:

Compiler
Tests
Runtime
Git Diff
Human

에 남긴다.

OpenAI가 Codex를 여러 Agent를 병렬로 관리하는 command center로 확장하고 Worktree와 Skills를 기본 기능으로 넣은 것도 결국 개발 Workflow가 이런 방향으로 이동하고 있기 때문이다.

중요한 것은 Agent를 몇 명 띄웠느냐가 아니다.

개발자의 개입을 얼마나 줄이면서도 검증 가능한 Software Change를 만들어낼 수 있느냐다.

그래서 개인 Workspace가 이미 여러 Git Repository로 잘 나뉘어 있다면 굳이 거대한 Agent Platform부터 구축할 필요가 없다.

먼저:

Workspace
+
Codex Multi-Agent
+
프로젝트별 AGENTS.md
+
Skills
+
Git Worktree
+
Claude Review
+
Claude QA

로 시작해도 상당히 강력한 개인 AI 개발팀을 만들 수 있다.

그리고 프로젝트 수가 늘어나거나 서로 다른 Coding Agent를 동시에 운영하고 싶어질 때는 그 위에 Orca 같은 Agent Orchestrator, Orka Agents 계열, 또는 다른 Multi-Agent Runtime을 얹어 비슷한 구조를 더 명시적인 실행·상태 관리 시스템으로 확장할 수 있다.

즉 선택은 두 가지다.

가볍게 시작

Codex Native
+ Claude Review/QA

또는:

Agent 종류와 규모 확대

Orchestration Layer
+ Codex
+ Claude Code
+ 기타 Agent

어느 쪽이든 핵심 Architecture는 같다.

구현하는 Agent와 검증하는 Agent를 분리하고, Agent보다 Evidence를 신뢰하며, 사람은 가장 비싼 판단에만 개입하는 것.

앞으로 개인 개발 환경도 점점 IDE 하나를 사용하는 방식에서 작은 AI 개발 조직을 운영하는 방식으로 바뀔 가능성이 크다.

참고 자료

OpenAI는 Codex를 여러 Agent를 동시에 관리하고 프로젝트별로 병렬 작업을 수행하는 command center로 제공하고 있으며, 같은 Repository에서도 Git worktree를 통해 Agent 작업을 격리할 수 있다고 설명한다. Skills를 통해 반복적인 개발 Workflow와 팀 규칙을 Codex에 제공할 수도 있다.

Orca 계열 오픈소스 프로젝트들은 Codex·Claude Code·Cursor 같은 Coding Agent를 독립 Git worktree에 실행하고, Worker의 상태·완료·Retry·작업 의존성을 오케스트레이션 계층에서 관리하는 접근을 보여준다. 구현마다 기능과 성숙도는 다르므로 실제 도입 전 프로젝트 상태와 유지보수 수준을 확인할 필요가 있다.

핵심 참고 포인트

처음부터 외부 Orchestrator를 추가해야 하는 것은 아니다. 현재 Codex 자체가 Multi-Agent + Worktree + Skills + 프로젝트 단위 작업을 제공하기 때문에 개인 개발 환경에서는 먼저 Codex를 상위 오케스트레이터로 두고 Claude를 Review·QA 계층으로 분리하는 방식이 비교적 단순하다.

프로젝트와 Agent 수가 늘어나거나 Codex·Claude Code·Cursor 등 여러 Agent Runtime을 한 시스템에서 운영하고 싶어진다면 Orca나 Orka 같은 별도의 오케스트레이션 도구를 추가할 수 있다. 중요한 것은 특정 도구가 아니라 Goal → 병렬 조사 → 구현 → 자동 검증 → 독립 Review → Runtime QA → Human Gate라는 Workflow 자체다.

Claude Fable 5.1이 바꾼 Coding Agent 판도: GPT-5.6 Sol을 앞선 건 무엇인가

Wed, 02 Sep 2026 02:41:33 GMT

Claude Fable 5.1이 바꾼 Coding Agent 판도: GPT-5.6 Sol을 앞선 건 무엇인가

불과 두 달 전만 해도 Coding Agent 경쟁에서는 GPT-5.6 Sol의 존재감이 상당히 강했다.

OpenAI가 2026년 7월 GPT-5.6을 정식 공개했을 당시 Sol은 Artificial Analysis Coding Agent Index에서 80점을 기록했다. 당시 Claude Fable 5는 77.2점이었다. OpenAI는 Terminal-Bench 2.1과 DeepSWE에서도 Sol의 장기 Coding Agent 성능을 강조했다.

그런데 2026년 9월 1일 Anthropic이 Claude Fable 5.1을 공개하면서 분위기가 다시 달라졌다. Anthropic은 Fable 5.1을 현재 자사의 가장 강력한 Coding·Knowledge Work 모델로 소개하고 있다.

이번 변화에서 중요한 건 단순히 새로운 모델이 벤치마크 몇 개에서 GPT를 앞섰다는 사실이 아니다.

더 중요한 변화는 Coding Model 경쟁의 중심이 코드 생성 능력에서 실제 Engineering Task를 끝까지 수행하는 Agent 능력으로 이동하고 있다는 점이다.

1. 몇 달 만에 순위가 다시 뒤집혔다

GPT-5.6 Sol이 공개됐을 당시 OpenAI가 강조했던 지표 중 하나가 Artificial Analysis Coding Agent Index였다.

GPT-5.6 Sol     80.0
Claude Fable 5  77.2

Sol은 당시 Fable 5보다 2.8점 높았다.

특히 OpenAI가 강조한 것은 단순한 점수뿐만 아니었다.

Sol은 Fable 5와 비교했을 때 더 적은 출력 토큰과 더 짧은 작업 시간, 더 낮은 예상 비용으로 높은 Coding Agent 성능을 냈다는 것이 OpenAI의 설명이었다.

그런데 Fable 5.1이 나오면서 비교 대상 자체가 달라졌다.

Artificial Analysis의 출시 직후 비교에서는 Fable 5.1의 Adaptive Reasoning·Max Effort 구성이 GPT-5.6 Sol medium보다 Intelligence Index에서 상당히 높은 결과를 보이고 있다.

Artificial Analysis Intelligence Index

Claude Fable 5.1 Max    66
GPT-5.6 Sol Medium      56

다만 이 비교는 추론 설정이 동일하지 않다.

Fable은 Max Effort이고 Sol은 Medium이므로 이것만 보고 “10점 차이로 완전히 이겼다”고 말하면 안 된다. 반대로 현재 Fable 5.1이 이전 Fable 5보다 상당히 강해졌다는 신호로 보는 것은 충분히 가능하다.

2. 이번 변화는 일반 Coding보다 Agentic Coding에서 더 크게 보인다

요즘 Coding Agent가 수행하는 일은 예전의 코드 생성과 많이 다르다.

예전에는:

요구사항
  ↓
함수 작성
  ↓
결과

정도였다.

지금은 오히려 이런 형태다.

Repository 탐색
        ↓
관련 Architecture 파악
        ↓
문제 재현
        ↓
수정 계획
        ↓
여러 파일 수정
        ↓
Build
        ↓
Test
        ↓
실패
        ↓
원인 재분석
        ↓
수정
        ↓
재검증
        ↓
Review-ready 결과

이 흐름에서는 모델의 순수 Coding 능력만으로는 부족하다.

필요한 능력이 달라진다.

Repository Understanding

Planning

Tool Use

Long-horizon Reasoning

Failure Recovery

Verification

Context 유지

이번 Fable 5.1이 특히 노리는 부분이 이 영역이다.

Anthropic은 Fable 5.1을 대규모 코드베이스 작업, Code Review, 장시간 진행되는 Agent 작업, Tool 사용과 복잡한 Knowledge Work를 위한 모델로 소개하고 있다.

3. 좋은 Coding Agent는 코드를 잘 만드는 Agent가 아니다

실제 개발에서 더 중요한 질문은 이것이다.

한 번에 정답 코드를 만들었는가?

보다:

문제가 생겨도
사람을 계속 부르지 않고
끝까지 해결할 수 있는가?

다.

예를 들어 Agent에게 Build Error 하나를 맡긴다.

좋지 않은 Agent:

Build 실패
   ↓
A 수정
   ↓
Build 실패
   ↓
A' 수정
   ↓
Build 실패
   ↓
A'' 수정

겉으로 보면 계속 일하고 있다.

하지만 실제로는 같은 가설 안에서 빙빙 돌고 있다.

좋은 Agent는 두 번째 실패쯤에서 이렇게 움직여야 한다.

Build 실패
   ↓
기존 가설 폐기
   ↓
관련 코드 다시 조사
   ↓
새 가설 수립
   ↓
다른 증거 확인
   ↓
수정

이게 Recovery 능력이다.

장시간 Coding Agent에서는 이 차이가 굉장히 크다.

4. GPT-5.6 Sol 역시 바로 이 영역을 겨냥한 모델이다

그래서 Fable 5.1이 좋아졌다고 해서 Sol이 갑자기 구형 Coding Model이 된 것은 아니다.

OpenAI가 GPT-5.6 Sol을 출시하면서 가장 강하게 강조했던 것도 long-horizon agentic work였다.

Sol은 Terminal-Bench 2.1에서 88.8퍼센트, DeepSWE v1.1에서 72.7퍼센트를 기록했고, max 추론과 여러 하위 Agent를 병렬로 사용하는 ultra 구성까지 도입했다.

즉 두 회사 모두 같은 곳을 보고 있다.

Claude Fable 5.1
          ↘

        Long-running
        Engineering Agent

          ↗
GPT-5.6 Sol

경쟁은 더 이상 “누가 Python 함수를 더 잘 만드는가”가 아니다.

5. 벤치마크 숫자를 직접 비교할 때는 주의해야 한다

여기서 자주 발생하는 오류가 있다.

예를 들어 GPT-5.6 Sol 발표 자료에는:

Terminal-Bench 2.1
88.8%

이 나온다.

반면 최신 Claude 자료나 새로운 비교에서는 다른 버전의 Terminal-Bench나 다른 Harness를 사용하는 경우가 있다.

그래서:

88.8 vs 55.x

처럼 숫자만 직접 놓고:

Sol이 훨씬 강하다.

라고 결론 내리면 안 된다.

Benchmark 버전이 다르면 문제 집합도 다르고, Agent Harness나 Tool 환경도 달라질 수 있다.

Coding Agent에서는 특히:

Model
+
Harness
+
Tool
+
Reasoning 설정
+
Context

전체가 결과에 영향을 준다.

6. 이제 모델 이름보다 Harness가 더 중요해진다

같은 Fable 5.1이라도:

Claude App

에서 사용하는 것과:

Claude Code

로 Repository를 직접 수정하게 하는 것은 완전히 다른 경험이다.

Sol도 마찬가지다.

ChatGPT

와:

Codex

에서 동일한 모델을 사용해도 Agent의 행동 방식은 달라진다.

이제 실제 Coding Agent 성능은 대략 이런 식으로 보는 것이 맞다.

Agent 성능
=
Model
+
Harness
+
Repository Context
+
Tool Access
+
Project Rules
+
Validation

모델 하나의 IQ 점수만으로 설명하기 어렵다.

7. Fable 5.1에서 눈여겨볼 부분은 Code Review다

Coding Agent가 좋아지면서 새로운 병목이 하나 생겼다.

Review다.

Agent가 몇 분 만에 20개 파일을 수정할 수 있어도 사람은 그 20개 파일을 다시 읽어야 한다.

그래서 앞으로 강한 Coding Agent에게 필요한 능력은:

Code Generation

뿐만 아니다.

Code Review

Impact Analysis

Missing Test 발견

Architecture 위반 탐지

Risk 분류

가 점점 중요해진다.

Fable 5.1도 Anthropic이 Coding과 Knowledge Work를 핵심 용도로 내세우면서 이런 장시간 Repository 작업을 중심에 두고 있다.

8. 좋은 Reviewer는 Diff만 보면 안 된다

예를 들어 이런 변경이 있다고 하자.

func loadUser() async {
    user = try? await repository.load()
}

단순히 문법만 보면 이상하지 않을 수 있다.

하지만 실제 Review에서는:

이 메서드는 MainActor인가?

View가 사라졌을 때 Task는 취소되는가?

실패를 왜 무시하는가?

Repository 구현은 Actor-safe한가?

기존 Error State는 어떻게 되는가?

테스트는 있는가?

까지 봐야 한다.

즉:

Diff
↓
Call Graph
↓
State
↓
Architecture
↓
Runtime
↓
Test

를 연결해야 한다.

이런 작업은 작은 코드 생성 문제보다 훨씬 긴 Context와 추론을 필요로 한다.

9. 그래서 이번 경쟁은 ‘누가 더 똑똑하냐’보다 ‘누가 덜 귀찮게 하느냐’에 가깝다

Agent를 실제 사용하는 개발자 입장에서는 꽤 단순하다.

A Agent:

질문
질문
질문
승인
질문
실패
재시도

B Agent:

Task 시작

↓

조사

↓

구현

↓

Build

↓

실패

↓

스스로 복구

↓

Test

↓

결과 보고

두 모델의 Benchmark가 비슷하다면 실제로는 B가 훨씬 생산적이다.

그래서 앞으로 Coding Agent 지표에는 이런 것도 들어가야 한다.

Successful Task Rate

Human Intervention Count

Retry Count

Recovery Success Rate

Review Time

Unnecessary Diff

10. Sol과 Fable 5.1의 차이는 이제 성능만으로 보기 어렵다

현재 분위기를 단순화하면 대략 이런 식이다.

GPT-5.6 Sol

강점은 여전히 뚜렷하다.

강한 일반 추론

Agentic Coding

Codex 통합

Programmatic Tool Calling

큰 Context

빠른 처리

상대적으로 낮은 API 비용

OpenAI는 GPT-5.6이 Tool을 연결하고 중간 결과를 처리하며 다음 Action까지 결정하는 Programmatic Tool Calling을 지원하도록 설계했다고 설명한다.

Claude Fable 5.1

이번 세대에서 눈에 띄는 방향은:

장시간 Repository 작업

복잡한 Coding

Code Review

긴 Knowledge Work

Tool 기반 Agent 작업

이다.

특히 최신 독립 평가 초기 결과에서도 Fable 5.1의 추론 성능 상승이 확인되기 시작했다.

11. 가격은 Sol이 여전히 중요한 강점을 가진다

Coding Agent에서는 성능이 전부가 아니다.

Agent는 많은 Token을 소비한다.

Repository가 크다면:

Architecture 문서

Source

Tests

Build Log

Git Diff

Error Log

를 계속 읽는다.

그래서 가격 차이가 장시간 작업에서 크게 누적된다.

Artificial Analysis의 현재 비교에서도 Fable 5.1 Max 구성이 GPT-5.6 Sol medium보다 지능 점수는 높지만 Token 비용은 더 높은 것으로 나타난다.

즉:

가장 강한 모델

과:

가장 경제적인 Agent

는 반드시 같은 모델이 아니다.

12. 진짜 비교해야 할 것은 Cost per Successful Task다

예를 들어:

Fable 5.1

Task 성공
1회 실행
비용 6달러

와:

Sol

첫 번째 실패
두 번째 Retry
세 번째 성공
총 비용 4달러

라면 Sol이 더 저렴하다.

반대로:

Fable
1회 성공

Sol
4회 실패 후 Human Intervention

이라면 Fable이 비싸더라도 전체 비용은 더 낮을 수 있다.

실제 비용은:

Model Cost

+

Retry Cost

+

CI Cost

+

Human Review Time

+

Rework

이다.

그래서 결국 중요한 지표는:

Cost per Successful Task

가 된다.

13. 개발자가 직접 비교하려면 벤치마크보다 자기 Repository가 낫다

새 모델이 나왔을 때 LeetCode 같은 문제를 하나 던지는 것보다 실제 Repository에서 같은 일을 맡겨 보는 게 훨씬 낫다.

예를 들어 다섯 가지 정도면 충분하다.

오래된 버그

재현
↓
원인
↓
수정
↓
Regression Test

Repository 전체 Refactoring

영향 범위 조사
↓
계획
↓
수정
↓
Build
↓
Test

Code Review

PR Diff
↓
Critical/Major 문제
↓
Missing Test
↓
실제 영향

실패 Recovery

일부러 깨진 Test를 준다.

그리고:

같은 시도를 반복하는지

가설을 바꾸는지

다른 Evidence를 찾는지

본다.

장시간 작업

30분 이상 걸릴 일을 맡긴다.

그리고 결과를 이렇게 기록한다.

Task Success

Human Intervention

Retry

Runtime

Review Time

Unnecessary Changes

이게 실제 개발자에게는 훨씬 정확한 Benchmark다.

14. 모델을 하나로 고정할 이유도 점점 줄어들고 있다

불과 몇 달 사이에도 순위가 뒤집힌다.

GPT-5.6 Sol이 공개됐을 때는 Fable 5보다 강한 Coding Agent 성능을 강조했다.

그리고 두 달 뒤 Fable 5.1이 나왔다.

이 속도라면 특정 모델 하나를:

우리 팀의 영구 표준

으로 만드는 것은 점점 어려워진다.

오히려 Agent Workflow를 모델과 분리하는 게 낫다.

Task
  ↓
Agent
  ↓
Repository
  ↓
Build
  ↓
Test
  ↓
Review

그리고 Agent 자리에:

Fable 5.1

GPT-5.6 Sol

다음 세대 모델

을 교체할 수 있도록 한다.

15. 중요한 규칙은 모델 내부가 아니라 Repository에 남긴다

모델이 바뀌어도 유지돼야 할 것이 있다.

Architecture

Coding Rule

Build Command

Test Policy

Security Rule

Review Rule

이런 것들이다.

따라서:

AGENTS.md

CLAUDE.md

Skills

Architecture Docs

Tests

CI

같은 Repository 자산이 중요해진다.

좋은 Agent Workflow는 특정 모델의 기억에 의존하지 않는다.

16. 모델 Routing도 더 현실적인 선택이 된다

모든 작업에 Fable 5.1이나 Sol Max를 사용할 필요도 없다.

예:

단순 코드 조사
→ 빠른 모델

Boilerplate
→ 저렴한 모델

일반 Feature
→ 중간급 모델

복잡한 Debugging
→ Fable 5.1 / Sol

Architecture 변경
→ 최고 reasoning 구성

이렇게 Task별로 나누는 편이 전체 비용은 훨씬 낮아진다.

17. 특히 XHigh·Max를 항상 켜놓는 시대도 끝나갈 수 있다

강한 모델을 쓰는 것과 모든 Task에서 최대 추론을 사용하는 것은 다르다.

예를 들어:

파일 이름 변경

Import 수정

테스트 Fixture 생성

에 최고 Reasoning이 필요하지는 않다.

반대로:

Deadlock

Memory Corruption

Architecture Migration

희귀 Production Crash

같은 문제에는 강한 추론이 필요하다.

그래서:

Medium
↓
High
↓
XHigh / Max

처럼 필요한 경우에만 올리는 것이 효율적이다.

모델의 평균 성능이 올라갈수록 오히려 이런 Reasoning Routing이 더 중요해진다.

18. Coding Agent의 새로운 병목은 사람의 Review다

Agent 성능이 높아질수록 이상한 현상이 생긴다.

Agent Throughput
↑↑↑

Human Review Throughput
→

Agent 세 개를 동시에 돌리면 세 개의 PR이 나온다.

하지만 Developer 한 명은 세 개를 동시에 Review할 수 없다.

그래서 이제 중요한 Agent 능력은:

많이 수정

가 아니다.

Review하기 좋은 변경

이다.

예를 들어:

작은 Diff

명확한 변경 이유

실제 실행한 Test

검증하지 못한 부분

Risk 높은 파일

을 짧게 제공하는 Agent가 실무에서는 더 유용하다.

19. 결국 Fable 5.1에서 봐야 하는 건 ‘Attention Efficiency’다

앞으로 Coding Agent 경쟁에서 꽤 중요한 개념이 될 수 있다.

Token Efficiency

만이 아니다.

Human Attention Efficiency

다.

예를 들어:

Agent A

10달러
사람 개입 1회
Review 10분

Agent B

3달러
사람 개입 12회
Review 45분

어느 쪽이 실제로 더 싼지는 명확하지 않다.

Senior Developer의 35분이 API 비용 7달러보다 훨씬 비쌀 수도 있다.

20. 그래서 Fable 5.1의 진짜 경쟁 상대는 Sol의 Benchmark 점수가 아니다

더 근본적인 질문은 이것이다.

누가 더 높은 점수를 받았나?

보다는:

어떤 Agent에게 일을 맡겼을 때

개발자가 가장 적게 개입하고

가장 작은 Review 비용으로

신뢰할 수 있는 변경을 받는가?

이다.

이게 앞으로 실무 Agent 경쟁의 핵심에 더 가깝다.

21. GPT-5.6 Sol이 당장 밀려났다고 보기도 어렵다

이번 발표만 보고 Sol을 내려놓을 필요도 없다.

OpenAI의 Sol은 여전히:

Terminal 작업

Programmatic Tool Calling

긴 Context

Codex

Multi-Agent Ultra

라는 상당히 강한 Agent 환경을 가지고 있다.

특히 Sol은 모델 하나만이 아니라 Codex Harness와 함께 평가해야 한다.

Fable 5.1도 Claude Code와 함께 봐야 한다.

따라서 앞으로 비교는 사실:

Fable 5.1
vs
Sol

보다:

Claude Code + Fable 5.1

vs

Codex + GPT-5.6 Sol

쪽이 실제 개발자 경험에 더 가깝다.

22. 이번 발표가 보여준 가장 중요한 변화

Fable 5.1의 점수가 Sol보다 몇 점 높은지는 몇 달 뒤 다시 바뀔 수도 있다.

그보다 중요한 건 Frontier Model 경쟁의 속도다.

7월:

GPT-5.6 Sol 등장

→ Fable 5보다 높은 Coding Agent 지표

9월:

Fable 5.1 등장

→ 다시 Claude 쪽 성능 크게 상승

앞으로도 이런 식일 가능성이 높다.

즉 이제 모델 경쟁은 연 단위가 아니다.

몇 주, 몇 달 단위다.

23. 그래서 개발팀이 준비해야 할 것은 ‘최고 모델 선택’이 아니다

지금 최고인 모델을 찾아 영구적으로 고정하는 것보다:

모델을 쉽게 교체할 수 있는 Agent Workflow

가 더 중요하다.

예:

Task Specification
       ↓
Coding Agent
       ↓
Build
       ↓
Tests
       ↓
Static Checks
       ↓
Runtime Verification
       ↓
Human Review

여기서 Coding Agent만 교체하면 된다.

그러면 Fable이 좋아지면 Fable을 쓰고,

Sol이 다음 업데이트에서 다시 올라오면 Sol을 쓸 수 있다.

24. 앞으로 좋은 Coding Agent를 판단할 때 볼 숫자

개발팀이라면 다음 정도면 충분하다.

작업 성공률

평균 Retry 횟수

사람 개입 횟수

Build/Test 성공률

Review 시간

재작업 비율

불필요한 변경량

성공 작업당 비용

특히:

Benchmark Score

보다:

Successful Task Rate

를 보는 편이 좋다.

25. 개인 개발자도 아주 간단하게 비교할 수 있다

실제 사용하는 Repository 하나를 정한다.

같은 Task 다섯 개를 준비한다.

버그 수정

기능 추가

Refactoring

Code Review

Test 작성

Fable 5.1과 Sol에 각각 똑같이 맡긴다.

그리고 결과를 이렇게 적는다.

항목	Fable 5.1	GPT-5.6 Sol
완료 여부
사람 개입
Retry
Build
Test
Review 시간
불필요한 수정
비용

5개만 해도 자신의 실제 개발 환경에서는 어느 쪽이 맞는지 꽤 잘 보인다.

인터넷 Benchmark보다 훨씬 유용하다.

마무리

Claude Fable 5.1의 등장은 Coding Agent 경쟁이 얼마나 빠르게 움직이고 있는지를 다시 보여준다.

불과 두 달 전 GPT-5.6 Sol은 Artificial Analysis Coding Agent Index에서 80점을 기록하며 Fable 5를 앞섰고, Terminal-Bench 2.1과 DeepSWE 같은 장시간 Engineering Benchmark에서도 강한 결과를 보여줬다.

그리고 이제 Fable 5.1이 등장했다.

출시 직후 Artificial Analysis 평가에서도 Fable 5.1의 강한 추론 구성은 Sol의 일반적인 reasoning 구성보다 높은 Intelligence Index를 기록하기 시작했다. 다만 서로 reasoning 설정이 다르므로 이 수치를 그대로 모델 전체의 절대 순위로 해석해서는 안 된다.

이번 변화의 핵심은:

Claude가 GPT를 이겼다.

가 아니다.

더 중요한 변화는 이것이다.

Coding Model 경쟁
        ↓
Coding Agent 경쟁
        ↓
Engineering Agent 경쟁

코드를 생성하는 능력에서 Repository를 이해하고,

Tool을 사용하고,

실패하면 다시 조사하고,

Build와 Test를 거쳐,

사람이 Review할 수 있는 변경을 만들어내는 능력으로 경쟁의 중심이 이동하고 있다.

그래서 앞으로 모델을 평가할 때도 질문을 바꿔야 한다.

누가 코드를 더 잘 쓰는가?

보다:

누가 개발자의 Attention을 가장 적게 사용하면서 신뢰할 수 있는 Software Change를 끝까지 만들어주는가?

Fable 5.1과 GPT-5.6 Sol의 진짜 승부도 결국 여기서 갈릴 가능성이 크다.

그리고 이 속도라면 지금의 1등 모델이 몇 달 뒤에도 1등일 거라는 보장은 없다.

그래서 개발자에게 가장 중요한 자산은 특정 모델이 아니다.

AGENTS.md

Skills

Architecture

Tests

Build

CI

Review Policy

처럼 어떤 Frontier Model이 들어와도 그대로 사용할 수 있는 Engineering System이다.

모델은 계속 바뀐다.

좋은 개발 Workflow는 남는다.

참고 자료

Anthropic — Claude Fable
Anthropic은 2026년 9월 1일 Claude Fable 5.1을 발표하고 Coding과 Knowledge Work를 위한 자사의 가장 강력한 모델로 소개했다.
OpenAI — GPT-5.6
GPT-5.6 Sol은 Artificial Analysis Coding Agent Index 80점, Terminal-Bench 2.1 88.8퍼센트, DeepSWE v1.1 72.7퍼센트를 기록했으며 OpenAI는 긴 Coding·Tool Workflow를 핵심 역량으로 설명한다.
OpenAI — GPT-5.6 Engineering
OpenAI는 GPT-5.6에서 Context 관리, Prompt Caching, Agent Harness, Programmatic Tool Calling 등을 통해 긴 Agent 작업의 효율을 높이는 방향을 설명하고 있다.
Artificial Analysis — Claude Fable 5.1 vs GPT-5.6 Sol
출시 직후 비교에서 Fable 5.1의 강한 reasoning 설정이 Sol medium보다 높은 Intelligence Index를 기록하고 있지만 가격과 응답 지연에서는 Sol이 유리한 결과도 나타난다. 서로 reasoning 설정이 다르다는 점을 함께 봐야 한다.

핵심 참고 포인트

Fable 5.1이 나오면서 GPT-5.6 Sol이 모든 Coding 영역에서 명확히 패배했다고 단정할 단계는 아니다. 벤치마크 버전, Reasoning Effort, Harness가 서로 다르기 때문이다.

다만 Fable 5.1 출시 직후의 평가와 Anthropic의 제품 방향을 보면 Claude의 Coding·Long-running Agent 성능이 다시 크게 올라온 것은 분명하다.

따라서 이번 발표를 가장 정확하게 해석하면 “Coding Model의 새로운 절대 1등이 결정됐다”보다는 “Fable 5.1이 Agentic Coding 경쟁을 다시 매우 팽팽하게 만들었고, 이제 모델 비교는 단발 Benchmark보다 실제 Engineering Task 성공률과 사람의 개입 비용을 기준으로 해야 한다”에 가깝다.