에이전트 창을 닫아도 AI는 계속 일한다 — AHP 1.0이 바꾸는 개발 환경
에이전트 창을 닫아도 AI는 계속 일한다 — AHP 1.0이 바꾸는 개발 환경
에디터에서 시작한 AI 작업을 스마트폰으로 이어간다 — GitHub Mobile부터 Swift 릴레이 앱까지
회사에서 AI 코딩 에이전트에게 꽤 복잡한 리팩터링을 맡겼다고 생각해보자.
프로젝트 구조를 분석하고, 여러 파일을 수정하고, 테스트까지 실행해야 하는 작업이다.
AI가 코드를 작성하는 속도는 빨라졌지만, 개발자는 여전히 작업이 실행되는 화면을 신경 써야 한다.
다른 프로젝트를 열어도 괜찮을까?
에이전트 창을 닫으면 작업이 중단되는 건 아닐까?
집으로 이동하는 동안 진행 상황을 확인할 수 있을까?
AI가 명령 실행 승인을 요청하면 다시 개발 머신 앞에 앉아야 할까?
이런 불편함은 AI 모델의 코딩 성능과 별개의 문제다.
AI가 더 오래, 더 복잡한 작업을 수행하게 됐다면 개발자가 그 작업을 확인하고 제어하는 방식도 바뀌어야 한다.
Microsoft와 VS Code가 공개한 AHP(Agent Host Protocol) 1.0은 바로 이 문제와 연결된다.
AHP는 실행 중인 에이전트 작업을 하나의 에디터 창에 종속시키지 않고, 별도로 실행되는 Agent Host와 여러 클라이언트 사이에서 세션 상태를 공유하기 위한 공개 프로토콜이다.
2026년 8월 Agent Host 아키텍처가 소개됐고, 10월 2일 AHP 1.0 명세와 Swift SDK가 공개됐다. 이후 10월 28일 VS Code 1.144에서 AHP 1.0을 공식적으로 소개하면서 모바일·웹·데스크톱을 넘나드는 작업 경험도 한층 구체화됐다.
여기서 흥미로운 부분은 스마트폰이다.
이제 개발자가 이동 중에도 AI 작업을 확인하고 추가 지시를 전달하는 구성이 가능해졌다.
이를 위해 반드시 모바일 앱을 직접 개발할 필요도 없다.
GitHub Mobile을 활용하는 방법이 있고, AHP Swift SDK로 나만의 모바일 릴레이 앱을 만드는 방법도 있다.
두 방식은 서로 다른 수준의 제어 기능을 제공한다.
이번 글에서는 AHP의 구조부터 세션 동기화, 재접속, 모바일 활용, Swift 앱 설계, 보안과 한계까지 살펴본다.
1. AI에게 일을 맡겼는데 왜 같은 창을 지키고 있어야 할까?
예전에는 AI 코딩 도구에 비교적 작은 작업을 맡기는 경우가 많았다.
함수를 작성하거나, 에러 메시지를 분석하거나, 코드 일부를 리팩터링하는 식이다.
하지만 최근에는 작업 범위가 훨씬 커졌다.
프로젝트 전체 분석
↓
수정 계획 작성
↓
여러 파일 변경
↓
빌드 실행
↓
테스트
↓
실패 원인 분석
↓
재수정 및 검증이런 작업은 짧게 끝나지 않을 수 있다.
특히 프로젝트가 크거나 테스트 실행 시간이 길다면 에이전트가 여러 단계의 작업을 수행하는 동안 개발자는 다른 일을 하게 된다.
문제는 작업이 특정 화면이나 애플리케이션의 수명에 묶여 있는 경우다.
프로젝트 창을 닫으면 세션이 사라지거나 작업이 중단될 수 있다.
다른 기기에서 진행 상황을 보려면 원격 데스크톱에 연결하거나 별도의 로그 시스템을 만들어야 할 수도 있다.
반면 개발자가 실제로 원하는 것은 비교적 단순하다.
- AI가 맡은 작업은 계속 진행된다.
- 필요할 때 다른 화면에서 현재 상태를 확인한다.
- 중요한 승인 요청이 발생하면 개입한다.
- 자리를 옮겼다가 돌아와도 같은 작업을 이어간다.
이를 구현하기 위해서는 작업을 실행하는 곳과 작업을 보여주는 화면이 분리돼야 한다.
Agent Host와 AHP가 해결하려는 문제가 바로 이것이다.
2. AHP 1.0이란 무엇일까?
AHP는 Agent Host Protocol의 약자다.
이름에서 중요한 것은 Agent보다 Host다.
AHP는 새로운 AI 모델이 아니다.
AI에게 프로젝트를 어떻게 개발하라고 지시하는 프롬프트도 아니다.
AI 코딩 에이전트를 여러 화면에서 확인하고 제어할 수 있도록 Host와 클라이언트 사이의 통신 방식을 정의한 프로토콜이다.
기존에는 특정 에디터가 에이전트의 UI와 실행 상태를 직접 관리하는 방식이 일반적이었다.
AHP에서는 역할을 나눈다.
기존 방식
에디터
├─ AI 대화 UI
├─ 에이전트 실행 상태
├─ 도구 실행
└─ 작업 세션
AHP 기반 구조
클라이언트 UI
│
│ AHP
▼
Agent Host
│
▼
Agent Harness
│
▼
모델 호출·파일 수정·명령 실행핵심은 Agent Host가 세션의 기준 상태를 소유한다는 점이다.
클라이언트는 그 상태를 받아 화면에 표시하고 사용자의 입력을 Host에 전달한다.
그래서 VS Code, 웹 클라이언트, 다른 데스크톱 앱, 직접 만든 모바일 앱이 같은 Host에 연결되는 구조를 만들 수 있다.
여기서 같은 Host의 세션에 접근하는 것과 서로 다른 AI 에이전트가 무조건 동일한 작업을 공유하는 것은 구분해야 한다.
AHP는 세션을 여러 화면에 제공하는 공통 인터페이스이며, 개별 에이전트의 내부 동작까지 통일하는 것은 아니다.
3. Agent Host, AHP, Harness는 어떻게 다를까?
이 세 가지를 이해하면 전체 구조가 비교적 명확해진다.
┌───────────────────────────────┐
│ Clients │
│ │
│ VS Code Web SwiftUI App │
└───────────────┬───────────────┘
│
AHP
│
┌───────────────▼───────────────┐
│ Agent Host │
│ │
│ 세션 관리 │
│ 상태 동기화 │
│ 클라이언트 연결 관리 │
│ 도구 실행 승인 전달 │
└───────────────┬───────────────┘
│
Agent Adapter / SDK
│
┌───────────────▼───────────────┐
│ Agent Harness │
│ │
│ 모델 호출 │
│ Tool Calling │
│ 파일 수정 │
│ 테스트 실행 │
└───────────────────────────────┘Agent Host
Agent Host는 에이전트 세션을 관리하는 실행 환경이다.
세션의 상태를 보관하고, 연결된 클라이언트에 변경 내용을 전달한다.
실제 VS Code 구현에서는 에이전트별 Adapter가 Host 내부에서 동작한다.
AHP
AHP는 Host와 클라이언트가 통신하기 위한 공통 규약이다.
세션 조회, 상태 구독, 변경 전달, 사용자 입력 등을 정의한다.
Harness
Harness는 실제 에이전트의 작업 수행을 담당한다.
모델을 호출하고, 도구를 실행하고, 파일을 수정하고, 테스트 결과를 읽는 등의 작업이 여기에 속한다.
예를 들어 Codex와 Claude가 서로 다른 Harness를 사용하더라도 Agent Host는 각각의 Adapter를 통해 공통 세션 UI를 제공할 수 있다.
다만 이것이 모든 에이전트가 동일한 도구, 플러그인, 권한을 가진다는 의미는 아니다.
AHP는 공통 화면을 만드는 문제를 해결하고, 실제 AI 작업의 능력과 방식은 Harness에 남아 있다.
4. VS Code를 닫아도 된다면 컴퓨터를 꺼도 될까?
AHP를 소개할 때 가장 많이 오해할 수 있는 부분이다.
'VS Code를 닫아도 AI가 계속 일한다'는 말은 실행 머신이 없어져도 작업이 계속된다는 뜻이 아니다.
핵심은 Agent Host가 어디에서 실행되는지다.
| 상황 | 작업 지속 조건 |
|---|---|
| VS Code 프로젝트 창 닫기 | Agent Host가 계속 실행되고 있어야 함 |
| 다른 에디터 창 열기 | 동일 Host 세션에 다시 접근 |
| 클라이언트 연결 종료 | Host와 작업 실행 환경이 유지돼야 함 |
| 로컬 컴퓨터 종료 | 해당 컴퓨터의 작업은 계속될 수 없음 |
| 원격 개발 머신 사용 | 원격 머신과 Host가 실행 중이어야 함 |
| GitHub 클라우드 세션 | GitHub 클라우드 환경에서 실행·재개 가능 |
예를 들어 집에 있는 Mac mini에서 Agent Host를 실행한다고 생각해보자.
Mac mini가 켜져 있고 Host가 살아 있다면 외부에서 접속해 작업을 확인할 수 있다.
하지만 Mac mini 자체를 종료하면 로컬 작업이 그대로 계속 실행되지는 않는다.
반면 GitHub에서 제공하는 클라우드 세션은 GitHub 인프라에서 작업하기 때문에 개발자의 노트북을 닫아도 계속 실행하거나 나중에 재개할 수 있다.
또 하나 주의해야 할 부분이 있다.
일부 도구는 연결된 에디터나 확장 프로그램이 제공할 수 있다.
그 경우 해당 클라이언트 연결이 끊기면 일부 도구를 사용할 수 없을 수도 있다.
따라서 오래 실행할 작업이라면 필요한 도구가 Host 측에서 제공되는지 확인해야 한다.
화면을 닫아도 작업이 이어지는 이유는 작업이 사라졌기 때문이 아니라, 실행을 담당하는 프로세스가 화면에서 분리됐기 때문이다.
5. AHP는 메시지보다 상태를 중심으로 동작한다
AHP에서 기술적으로 중요한 부분은 State 중심 설계다.
일반적인 채팅 시스템은 메시지를 주고받는 방식으로 생각하기 쉽다.
하지만 AI 코딩 에이전트는 단순히 텍스트만 출력하지 않는다.
작업 상태가 바뀌고, 도구를 실행하고, 파일을 변경하고, 사용자 승인을 요청한다.
따라서 현재 상태를 일관되게 유지하는 것이 중요하다.
AHP에서는 Host가 상태의 기준이 된다.
클라이언트가 특정 채널을 구독하면 처음에는 현재 상태의 Snapshot을 받는다.
이후 변경사항이 발생하면 순서가 있는 Action을 받는다.
클라이언트 연결
↓
현재 상태 Snapshot 수신
↓
Action 구독
↓
변경 이벤트 수신
↓
Reducer로 상태 갱신
↓
화면 다시 표시이 구조는 Redux나 단방향 상태 관리 패턴과 비슷하다.
SwiftUI에서 생각하면 다음과 같은 개념으로 이해할 수 있다.
struct AgentSessionState {
var title: String
var status: SessionStatus
}
enum SessionAction {
case titleChanged(String)
case statusChanged(SessionStatus)
}
func reduce(
state: inout AgentSessionState,
action: SessionAction
) {
switch action {
case .titleChanged(let title):
state.title = title
case .statusChanged(let status):
state.status = status
}
}위 코드는 AHP의 실제 SDK 타입이 아니라 상태 관리 원리를 설명하기 위한 예제다.
핵심은 현재 상태에 Action을 적용해 새로운 상태를 만든다는 점이다.
AHP는 이런 상태 변경을 공통 구조로 전달함으로써 여러 클라이언트가 일관된 화면을 유지할 수 있도록 한다.
6. 세션, 대화, 터미널, 코드 변경을 각각 구독한다
AHP에서는 Channel이라는 개념을 사용한다.
모든 정보를 한 번에 주고받는 대신 필요한 종류의 상태를 선택적으로 구독할 수 있다.
대표적으로 다음 정보가 있다.
| 채널 | 역할 |
|---|---|
| 세션 | 작업 목록과 실행 상태 |
| 대화 | 메시지와 에이전트 응답 |
| 터미널 | 명령 실행 관련 상태 |
| 변경사항 | 수정된 코드와 변경 집합 |
이 구조는 모바일에서 특히 유용하다.
예를 들어 스마트폰에서 확인하려는 정보가 현재 실행 중인 작업 목록뿐이라면 모든 파일 변경 내용과 터미널 로그를 한 번에 가져올 필요가 없다.
사용자가 특정 세션을 선택했을 때 필요한 정보를 구독할 수 있다.
모바일 앱 실행
↓
세션 목록 구독
↓
세션 선택
↓
대화 상태 구독
↓
변경사항 선택
↓
필요한 파일 내용 조회AHP는 URI로 식별되는 채널과 상태 기반 업데이트를 지원한다.
다만 채널마다 제공하는 기능이 같지는 않으며, 구현체가 지원하는 Capability를 확인해야 한다.
또 여기서 데이터를 필요한 만큼 가져오는 방식은 클라이언트의 네트워크와 메모리 사용을 줄이는 데 도움이 될 수 있지만, AI 모델의 입력 토큰이 자동으로 줄어드는 것은 아니다.
모델의 컨텍스트 관리와 클라이언트의 상태 구독은 다른 문제다.
7. 연결이 끊겨도 작업 상태를 다시 가져올 수 있다
모바일 환경에서는 연결이 끊기는 상황을 피할 수 없다.
지하철을 타거나, 와이파이에서 셀룰러 네트워크로 전환하거나, 앱이 백그라운드로 이동하면 연결이 종료될 수 있다.
중요한 것은 이런 상황에서도 Host가 관리하는 작업 상태가 사라지지 않는 것이다.
모바일 앱
↓
Host 연결
↓
진행 상황 확인
↓
네트워크 연결 해제
...
Agent Host
↓
작업 계속 실행
↓
상태 변경 기록
...
모바일 재접속
↓
누락된 Action 수신
또는 최신 Snapshot 수신
↓
현재 상태 복구AHP는 연결이 끊긴 뒤 누락된 상태 변경을 따라잡거나 새로운 Snapshot을 이용해 상태를 다시 맞추는 구조를 제공한다.
다만 모든 이벤트가 영구 보존되는 것은 아니다.
일시적인 알림과 영속적인 상태 변경은 구분해야 한다.
또 네트워크 재접속과 Host 프로세스 재시작은 전혀 다른 상황이다.
Host가 종료됐을 때 실제 에이전트 실행을 어디까지 복원할 수 있는지는 해당 Host 구현과 실행 환경에 따라 달라진다.
8. PC와 스마트폰에서 동시에 승인하면 어떻게 될까?
여러 클라이언트에서 같은 세션에 접근할 수 있게 되면 새로운 문제가 생긴다.
예를 들어 AI가 명령 실행 승인을 요청했다고 생각해보자.
개발자는 PC와 스마트폰에서 같은 요청을 확인할 수 있다.
PC에서 이미 승인했는데 스마트폰에서는 아직 승인 버튼이 표시될 수도 있다.
또는 스마트폰에서 작업 취소를 요청했지만 PC에서는 이전 작업 상태를 보여주고 있을 수 있다.
AHP에서는 Host가 최종 상태의 기준이 된다.
클라이언트가 사용자 동작을 먼저 반영하더라도 Host의 응답과 확정된 상태를 기준으로 화면을 다시 맞춰야 한다.
이때 세 가지를 구분해야 한다.
사용자가 승인 버튼을 누름
≠
Host가 승인 요청을 확정함
≠
실제 명령 실행이 성공함이 차이는 특히 모바일 앱을 만들 때 중요하다.
사용자가 승인 버튼을 누른 직후 연결이 끊어졌다면 실제 요청이 Host에 도달했는지 확인해야 한다.
같은 승인 요청을 무조건 다시 보내는 것도 위험할 수 있다.
따라서 승인 요청은 식별자와 현재 상태를 기준으로 처리해야 한다.
모바일 UI에도 '전송 중', '승인 확정', '실행 중', '실행 실패'를 구분해서 보여주는 것이 좋다.
9. MCP와 A2A가 있는데 AHP는 왜 필요할까?
AI 개발 환경에는 여러 프로토콜이 등장하고 있다.
대표적으로 MCP와 A2A가 있다.
여기에 ACP와 AHP까지 등장하면서 이름이 비슷한 기술이 많아졌다.
하지만 각각의 중심 목적은 다르다.
| 프로토콜 | 핵심 목적 |
|---|---|
| MCP | AI 애플리케이션과 외부 도구·데이터 연결 |
| A2A | 서로 다른 에이전트 간 협업과 작업 전달 |
| ACP | 에디터 등의 클라이언트와 코딩 에이전트 연결 |
| AHP | 여러 클라이언트와 Agent Host 사이의 세션 상태 동기화 |
예를 들어 AI가 GitHub 저장소의 정보를 가져오도록 MCP를 사용할 수 있다.
서로 다른 AI 에이전트가 작업을 전달해야 한다면 A2A 같은 접근을 활용할 수 있다.
반면 개발자가 PC와 스마트폰에서 같은 에이전트 세션을 확인하고 제어하는 것은 AHP가 해결하려는 문제다.
또 AHP와 ACP는 반드시 둘 중 하나만 사용해야 하는 관계가 아니다.
Agent Host 내부의 Adapter가 ACP나 별도 SDK를 통해 에이전트와 통신하고, 외부 클라이언트와는 AHP로 상태를 공유하는 구성이 가능하다.
이 구조에서 MCP나 A2A를 함께 사용할 수도 있다.
중요한 것은 프로토콜을 많이 연결하는 것이 아니라 각각이 어떤 문제를 해결하는지 이해하는 것이다.
10. Codex·Claude·Copilot도 같은 화면에서 관리할 수 있을까?
AHP 구조에서 흥미로운 부분은 Agent Host가 여러 종류의 에이전트 실행 환경을 연결할 수 있다는 것이다.
VS Code의 Agent Host 아키텍처는 Copilot, Claude, Codex 등의 에이전트를 Adapter를 통해 연결하는 구조를 설명한다.
여기서 공통화하려는 것은 세션을 보는 방식이다.
VS Code / Web / Mobile
↓
AHP
↓
Agent Host
↓
Agent별 Adapter
├─ Copilot
├─ Claude
└─ Codex하지만 모든 에이전트를 동일하게 다룰 수 있다는 뜻은 아니다.
모델별 사용량, 인증 방식, 제공 도구, 지원하는 권한, 작업 실행 방식은 서로 다르다.
또 AHP에 연결된 모든 에이전트의 실행 중인 세션을 자유롭게 다른 모델로 교체할 수 있는 것도 아니다.
같은 세션을 여러 화면에서 다루는 것과 하나의 작업을 서로 다른 모델 사이에서 자유롭게 이전하는 것은 별개의 문제다.
따라서 실제 개발 환경에서는 공통 세션 UI를 사용하되 에이전트별 Capability를 확인하는 방식이 적절하다.
11. VS Code에서 직접 Agent Host를 실행해보자
AHP의 개념을 이해했다면 실제 Agent Host를 확인해볼 차례다.
VS Code 1.144 이상을 기준으로 개발 환경과 CLI 명령을 확인한다.
code --version먼저 현재 설치된 버전이 Agent Host 관련 기능을 지원하는지 확인한다.
다음으로 명령어 도움말을 살펴본다.
code agent host --help독립적인 Agent Host를 실행하는 기본 명령은 다음과 같다.
code agent host현재 VS Code 에디터에서 실행 중인 Agent Host의 엔드포인트를 확인할 때는 다음 명령을 사용한다.
code agent endpoints여기서 두 명령은 목적이 다르다.
code agent host는 Host 실행과 관련되고, code agent endpoints는 에디터에서 실행 중인 Host의 연결 정보를 확인하는 데 사용한다.
AHP 1.0은 원격 클라이언트 통신을 위해 WebSocket 기반 연결을 지원한다.
VS Code에서는 Agents 화면의 Agents: Add Remote Agent Host... 명령을 통해 원격 Host를 추가할 수도 있다.
처음에는 로컬 환경에서 세션을 만들고, 다른 화면에서 연결해 현재 상태가 동기화되는지 확인하는 정도면 충분하다.
처음부터 외부 인터넷에 Host를 직접 공개할 필요는 없다.
실제 원격 접속이 필요하다면 인증된 연결과 네트워크 접근 제어를 먼저 준비해야 한다.
12. 스마트폰에서도 AI 작업을 이어가는 두 가지 방법
여기서부터 실제 활용 방식이 갈린다.
AHP를 사용한다고 해서 모든 개발자가 전용 모바일 앱을 만들어야 하는 것은 아니다.
이미 GitHub는 모바일에서 Copilot 에이전트 세션을 관리하는 기능을 제공하고 있다.
따라서 선택지는 크게 두 가지다.
방법 1. GitHub Mobile 사용
기존 GitHub Mobile 앱을 통해 지원되는 Copilot 세션을 시작하고, 진행 상황을 확인하고, 추가 지시를 전달한다.
별도로 모바일 앱을 만들 필요가 없다.
방법 2. Swift로 전용 모바일 릴레이 앱 개발
AHP Swift SDK를 이용해 직접 Host에 연결하는 앱을 만든다.
세션 목록, 작업 상태, 도구 승인, 변경사항 확인 같은 기능을 원하는 방식으로 구성할 수 있다.
두 방법을 비교하면 다음과 같다.
| 구분 | GitHub Mobile | 전용 Swift 릴레이 앱 |
|---|---|---|
| 모바일 앱 개발 | 필요 없음 | 직접 개발 |
| 기존 GitHub 연동 | 기본 제공 | 별도 구현 가능 |
| Copilot 세션 관리 | 지원 범위 내 제공 | Host 연결 방식에 따라 구현 |
| AHP 직접 연결 | 일반 앱 기능과 구분 | 직접 구현 가능 |
| 사용자 정의 UI | 제한적 | 자유롭게 설계 |
| 세션 상태 표현 | GitHub 제공 UI | 필요한 채널 직접 활용 |
| 승인·알림 | 지원 기능 활용 | 직접 설계 |
| 유지보수 | GitHub가 담당 | 개발자가 담당 |
중요한 것은 GitHub Mobile의 Copilot 세션 기능과 AHP SDK를 사용하는 커스텀 클라이언트를 같은 것으로 설명하지 않는 것이다.
둘 다 모바일에서 AI 작업을 제어할 수 있지만, 지원 범위와 구현 방식은 다르다.
일반적인 개발자라면 GitHub Mobile을 먼저 사용해보는 편이 간단하다.
반대로 여러 Host를 관리하거나 특정 작업 승인 UI를 별도로 만들고 싶다면 Swift 앱을 개발할 이유가 생긴다.
13. 방법 1 — GitHub Mobile만으로 AI 작업 이어가기
2026년 10월 28일 GitHub는 새로운 통합 Copilot 클라우드 경험을 발표했다.
핵심은 작업을 하나의 앱이나 디바이스에 묶어두지 않는다는 것이다.
GitHub Mobile에서 시작한 지원되는 클라우드 세션을 웹이나 VS Code, Copilot CLI 등에서 이어서 다룰 수 있다.
반대로 VS Code에서 시작한 지원 세션을 이동 중에 GitHub Mobile로 확인할 수도 있다.
클라우드 세션 사용
GitHub Mobile의 Copilot 탭에서 세션을 시작하거나, 저장소·Issue·PR 화면에서 New agent session을 선택할 수 있다.
예를 들어 다음과 같은 요청이다.
이 저장소의 로그인 오류를 분석해줘.
관련 코드를 확인하고,
문제를 수정한 뒤
테스트 결과를 정리해줘.작업은 GitHub가 제공하는 클라우드 실행 환경에서 진행될 수 있다.
이 경우 개발자의 노트북을 닫아도 클라우드의 작업이 계속 실행되거나 저장된 상태에서 재개될 수 있다.
스마트폰에서는 진행 상황을 살펴보고 필요한 지시를 추가하는 방식이다.
GitHub Mobile은 세션 로그 확인, 작업 중단, 완료된 작업에서 PR 생성, PR 검토 기능도 제공한다.
단, 2026년 10월 28일 발표된 새 통합 클라우드 세션 경험은 유료 Copilot 플랜을 대상으로 순차 제공되며, 조직 정책과 계정 권한에 따라 사용 가능한 기능이 달라질 수 있다.
내 개발 머신에서 실행하는 작업도 모바일로 제어할 수 있다
여기서 더 흥미로운 기능이 있다.
GitHub는 로컬 개발 머신을 에이전트 실행 환경으로 등록하고, GitHub Mobile에서 해당 머신의 지원되는 세션을 제어하는 기능도 소개했다.
VS Code CLI에서는 프로젝트 디렉터리에서 다음 명령을 사용할 수 있다.
code agent host --github-environment이 명령은 개발 머신을 GitHub의 원격 제어 환경과 연결하는 용도다.
구성은 다음과 같이 이해할 수 있다.
GitHub Mobile
↓
GitHub 세션 연결
↓
개발 머신의 Agent Host
↓
Copilot 실행
↓
프로젝트 파일·테스트스마트폰이 프로젝트 파일을 직접 빌드하는 것이 아니다.
실제 작업은 개발 머신에서 수행된다.
스마트폰은 진행 상황을 확인하고 필요한 지시를 전달하는 역할이다.
단, 해당 머신은 켜져 있어야 하며 Agent Host도 실행 중이어야 한다.
이 기능은 기존 GitHub Mobile만으로 모바일 릴레이에 가까운 경험을 사용할 수 있다는 점에서 의미가 크다.
모바일 앱을 별도로 개발하기 전에 먼저 검토할 만한 선택지다.
14. 방법 2 — Swift로 나만의 AI 모바일 릴레이 앱 만들기
GitHub Mobile이 제공하는 기능으로 충분하지 않다면 직접 앱을 만들 수도 있다.
예를 들어 다음 요구사항이 있다고 생각해보자.
- 집과 회사의 개발 머신을 함께 관리하고 싶다.
- 여러 Agent Host의 세션을 한 화면에서 확인하고 싶다.
- 특정 명령의 실행 승인을 별도로 표시하고 싶다.
- 진행 중인 작업을 프로젝트별로 분류하고 싶다.
- 중요한 상태 변경만 알림으로 받고 싶다.
이런 목적이라면 AHP Swift SDK를 활용한 전용 앱을 고려할 수 있다.
Microsoft는 공식 저장소에서 Swift Package Manager용 클라이언트 라이브러리를 제공한다.
주요 제품은 두 가지다.
| Swift 제품 | 역할 |
|---|---|
AgentHostProtocol | 프로토콜 타입, 명령, Action, Reducer |
AgentHostProtocolClient | 연결, 구독, 상태 동기화, 재접속 지원 |
여러 Host를 관리하는 MultiHostClient와 상태를 동기화하는 State Mirror 기능도 제공한다.
Swift Package Manager에 추가하기
공식 저장소를 Swift Package Manager 의존성으로 추가한다.
dependencies: [
.package(
url: "https://github.com/microsoft/agent-host-protocol.git",
from: "1.0.0"
)
]타깃에는 필요한 제품을 추가한다.
.target(
name: "AgentRelayApp",
dependencies: [
.product(
name: "AgentHostProtocol",
package: "agent-host-protocol"
),
.product(
name: "AgentHostProtocolClient",
package: "agent-host-protocol"
)
]
)위 예제는 공식 저장소의 제품 구성을 기준으로 작성한 Package.swift 구성 예시다. 실제 Xcode 프로젝트에서는 현재 배포 태그와 플랫폼 지원 범위를 확인해 의존성을 추가해야 한다.
또 AHP 프로토콜 버전과 Swift SDK의 패키지 버전은 별개의 개념이다. 프로젝트에서 사용할 SDK가 연결 대상 Host의 프로토콜 버전을 지원하는지도 확인해야 한다.
앱 구조 설계
전용 앱은 다음처럼 구성할 수 있다.
SwiftUI
↓
Session ViewModel
↓
App State Store
↓
AHP State Mirror
↓
AHPClient / MultiHostClient
↓
WebSocket Transport
↓
Agent HostSwiftUI에는 세션 목록과 진행 상태를 표시한다.
ViewModel은 사용자 입력을 전달하고 화면 상태를 관리한다.
AHP SDK는 Host 연결과 프로토콜 요청, 상태 구독을 처리한다.
앱 전체의 인증 정책과 저장 정책, 화면 전환, 알림은 별도로 구현한다.
연결 전송 계층
공식 Swift 클라이언트에는 WebSocket 기반 Transport가 제공된다.
일반적인 보안 WebSocket 연결에는 URLSessionWebSocketTransport를 활용할 수 있다.
로컬 네트워크나 일부 개발 환경에는 Network.framework 기반의 NWConnectionWebSocketTransport도 제공된다.
예를 들어 공식 문서에서는 다음과 같은 형태를 안내한다.
let transport = NWConnectionWebSocketTransport(
url: URL(
string: "ws://192.168.1.42:8080/ahp"
)!,
headers: [
"Authorization": "Bearer \(token)"
]
)이 코드는 Transport 생성 예제이며 인증된 AHP 세션을 완성하는 전체 구현은 아니다.
또 192.168.1.42는 예시 주소일 뿐 실제 Agent Host 주소가 아니다.
원격 운영 환경에서는 인증과 암호화된 연결을 우선해야 한다.
가장 작은 릴레이 앱의 기능
처음부터 모든 기능을 구현할 필요는 없다.
다음 정도로 시작할 수 있다.
Host 선택
↓
연결 및 인증
↓
세션 목록 표시
↓
세션 상세
↓
작업 진행 상태
↓
승인 요청 확인
↓
추가 지시iOS 앱에서 실제 파일 수정이나 빌드 명령을 수행할 필요도 없다.
모바일 릴레이 앱의 역할은 작업 실행이 아니라 작업 관찰과 제어이기 때문이다.
이렇게 범위를 제한하면 비교적 명확한 목적의 SwiftUI 앱으로 시작할 수 있다.
15. 앱보다 어려운 것은 재접속과 상태 일관성이다
모바일 릴레이 앱에서 가장 중요한 기능은 화면이 예쁘게 보이는 것이 아니다.
연결이 끊겼다가 돌아왔을 때 현재 작업 상태를 정확하게 복구하는 것이다.
AHP Swift 클라이언트는 initialize, reconnect, subscribe, unsubscribe, dispatch 등에 대한 헬퍼를 제공한다.
하지만 reconnect라는 API 하나가 모든 재접속 정책을 해결하지는 않는다.
실제 앱에서는 연결 실패 후 얼마나 기다릴지, 인증 만료를 어떻게 처리할지, 연결 중 어떤 화면을 보여줄지 결정해야 한다.
연결 실패
↓
오류 분류
↓
인증 오류인가?
├─ 예 → 재인증 요청
└─ 아니요 → 재연결 정책 적용
↓
재접속
↓
상태 다시 동기화특히 승인 명령은 재접속 후 무조건 다시 실행하면 안 된다.
승인 요청이 이미 처리됐는지 확인해야 하기 때문이다.
실제로 구현한다면 다음 테스트가 필요하다.
| 테스트 | 확인할 내용 |
|---|---|
| 앱 백그라운드 전환 | 상태 복구가 가능한가 |
| Wi-Fi에서 셀룰러 전환 | 연결을 다시 확립하는가 |
| Host 연결 종료 | 잘못된 완료 상태를 표시하지 않는가 |
| 승인 요청 중 연결 해제 | 중복 승인 방지 |
| 인증 토큰 만료 | 재인증 처리 |
| Host 재시작 | 지원 범위에 맞는 세션 복구 |
| 복수 Host 연결 | Host별 상태가 섞이지 않는가 |
또 iOS 앱이 백그라운드에 들어간 뒤 WebSocket 연결을 무제한 유지할 수 있다고 가정해서는 안 된다.
iOS의 백그라운드 실행 정책을 고려해야 한다.
중요한 변경사항을 푸시 알림으로 받고 싶다면 Host 측에서 별도의 푸시 전달 서버나 알림 인프라를 구성하는 방식도 고려할 수 있다.
이런 알림 서비스는 AHP Swift SDK를 추가했다고 자동으로 제공되는 기능은 아니다.
16. 스마트폰에서 승인할 수 있다면 보안도 더 중요해진다
AHP로 원격에서 에이전트 작업을 제어할 수 있다는 것은 편리하지만 동시에 새로운 보안 경계가 생긴다는 뜻이다.
스마트폰에서 명령 실행을 승인할 수 있다면 결국 개발 머신의 파일과 프로세스에 영향을 줄 수 있다.
따라서 모바일 앱에서는 단순히 '승인' 버튼만 보여주면 안 된다.
어느 Host에서 어떤 프로젝트를 대상으로 무슨 작업을 하려는지 충분한 정보를 보여줘야 한다.
예를 들어 다음과 같다.
Host: Office Mac mini
Repository: CommerceApp
작업: 테스트 실행
Command:
xcodebuild test ...
상태: 승인 대기반면 다음과 같은 작업은 더 높은 수준의 확인이 필요하다.
운영 서버 배포
보호 브랜치 Push
비밀정보 파일 접근
외부 API를 통한 데이터 전송AHP가 연결을 제공한다고 해서 모든 작업에 동일한 권한을 제공해야 하는 것은 아니다.
권한은 작업 유형에 따라 나누는 것이 좋다.
GitHub Mobile을 사용하는 경우에도 GitHub 계정 인증, 저장소 권한, 조직의 Copilot 정책, 승인 설정을 확인해야 한다.
직접 만든 Swift 앱에서는 Host 인증정보를 안전하게 관리하고, 외부 네트워크에 인증되지 않은 Agent Host를 공개하지 않아야 한다.
또 Git Worktree로 작업 공간을 분리했다고 해서 보안 샌드박스가 만들어지는 것은 아니다.
Worktree는 Git 작업 디렉터리를 분리하는 수단이고, 시스템 명령과 네트워크 권한 제한은 별도로 구현해야 한다.
원격으로 AI를 제어할 수 있는 만큼, 어떤 작업까지 원격에서 허용할 것인지 명확하게 구분하는 것이 중요하다.
17. AHP를 사용하면 모든 에이전트 문제가 해결될까?
AHP는 강력한 개념이지만 해결하려는 문제의 범위가 분명하다.
AHP를 적용한다고 AI 모델의 코드 품질이 갑자기 좋아지는 것은 아니다.
에이전트가 작업을 더 정확하게 수행하거나 테스트를 더 잘 통과하도록 보장하지도 않는다.
또 실행 중인 세션의 정보가 여러 화면에 동기화된다고 해서 모든 도구에서 작업을 자유롭게 이전할 수 있는 것도 아니다.
정리하면 다음과 같다.
| AHP가 다루는 문제 | 별도로 해결할 문제 |
|---|---|
| 다중 클라이언트 상태 동기화 | AI의 추론 품질 |
| 세션 관찰 및 제어 | 작업 결과 검증 |
| 연결 복구 시 상태 동기화 | Host 장애 후 프로세스 복구 |
| 공통 UI 및 상태 표현 | 에이전트별 도구 기능 |
| 원격 클라이언트 연결 | 배포·운영 권한 정책 |
| 세션 인터페이스 통일 | 모델 토큰 비용 관리 |
또 AHP가 공개 프로토콜이라고 해서 연결된 Copilot, Claude, Codex 등의 사용 요금이 없어지는 것도 아니다.
실제 모델 사용량과 구독 정책은 별도로 적용된다.
따라서 AHP의 가치는 AI 모델을 더 저렴하게 만드는 데 있는 것이 아니다.
이미 실행 중인 AI 작업을 개발자가 더 유연하게 관찰하고 제어할 수 있게 만든다는 점에 있다.
18. 기존 AI 오케스트라에 AHP를 연결한다면?
여러 AI에게 각각 역할을 나누는 오케스트라와 AHP는 해결하려는 문제가 다르다.
예를 들어 Claude에 설계를 맡기고, Codex에 구현을 맡기고, 다른 도구에 문서화를 맡기는 구조를 생각해보자.
이 구조의 핵심은 작업의 역할 분배다.
반면 AHP의 핵심은 실행 중인 작업을 여러 화면에서 관찰하고 제어하는 것이다.
AI 오케스트라
↓
작업 분배 및 실행
↓
Agent Harness
↓
Agent Host
↓
AHP
↓
VS Code / Web / Swift App여기서 중요한 것은 Agent Host의 세션 모델과 기존 오케스트라의 작업 상태를 연결하는 일이다.
기존 JSON 파일이나 데이터베이스에 저장한 작업 기록이 자동으로 AHP 세션으로 변환되는 것은 아니다.
필요하다면 별도의 Adapter나 Host 구현이 있어야 한다.
하지만 이런 연결이 가능해진다면 개발자는 AI가 어떤 역할로 작업하든 같은 모바일 화면에서 전체 진행 상황을 살펴보는 구조를 만들 수 있다.
예를 들어 개발 머신에서는 Codex가 코드 수정과 테스트를 진행하고, 모바일에서는 현재 작업 상태를 확인하는 방식이다.
여기에 작업 완료 조건이나 테스트 결과를 추가로 표시할 수도 있다.
이것은 AHP 자체의 기능이라기보다 AHP를 활용해 확장할 수 있는 애플리케이션 설계다.
19. 마치며 — 개발자는 이제 AI가 실행되는 화면에 묶일 필요가 없다
AI 코딩 도구는 이미 여러 파일을 수정하고, 테스트를 실행하고, 복잡한 작업을 수행하는 방향으로 발전하고 있다.
그런데 작업이 복잡해질수록 새로운 문제가 생긴다.
AI가 일하는 동안 개발자는 어디에서 그 작업을 확인하고, 언제 개입하고, 어떻게 같은 세션으로 돌아올 수 있을까?
AHP 1.0은 이런 문제를 해결하기 위한 기반이다.
Agent Host가 세션을 관리하고, 여러 클라이언트가 같은 작업 상태를 공유한다.
VS Code는 더 이상 에이전트 작업의 유일한 화면일 필요가 없다.
작업은 로컬 개발 머신이나 원격 서버, 클라우드에서 실행될 수 있다.
개발자는 필요한 화면에서 그 작업을 확인하고 제어한다.
그리고 이번 변화에서 특히 흥미로운 부분은 모바일이다.
직접 앱을 만들지 않아도 GitHub Mobile을 통해 지원되는 Copilot 세션을 시작하고, 진행 상황을 확인하고, 추가 지시를 전달할 수 있다.
개발 머신을 GitHub 환경으로 연결하면 스마트폰에서 로컬 실행 작업을 제어하는 구성도 가능하다.
더 세밀한 기능이 필요하다면 AHP Swift SDK로 전용 릴레이 앱을 만들 수 있다.
세션 목록, 실행 상태, 코드 변경, 승인 요청을 원하는 방식으로 보여주는 앱이다.
물론 앱이 화면에 표시하는 것과 실제 작업이 성공하는 것은 별개다.
Host의 생명주기, 재접속, 인증, 도구 권한, 승인 충돌 등을 함께 고려해야 한다.
AHP가 모든 에이전트 문제를 해결하는 것은 아니다.
하지만 AI 개발 환경에서 중요한 변화 하나를 보여주고 있다.
이제 개발자는 AI가 실행되는 프로그램을 계속 지켜보는 대신, 필요한 순간에 같은 작업으로 돌아와 상태를 확인하고 제어하는 방향으로 이동하고 있다.
AI 코딩의 다음 변화는 모델이 코드를 더 빠르게 작성하는 능력만이 아닐 수 있다.
AI가 작업을 계속 수행하는 동안 개발자는 화면을 바꾸고, 자리를 옮기고, 다시 돌아와도 같은 작업을 이어서 다룰 수 있는 환경. AHP는 그 변화를 위한 하나의 기반이다.
참고자료
Visual Studio Code 1.144 Release Notes
2026년 10월 28일 발표. AHP 1.0 공개와 Agent Host 연결, VS Code의 에이전트 경험 확장 내용을 확인할 수 있다.
Microsoft — Agent Host Architecture
Agent Host를 에디터와 분리하는 설계, 세션 유지, 상태 동기화와 에이전트 Adapter 구조를 설명한다.
Microsoft — Agent Host Protocol
AHP의 목적, 상태와 Action, 채널 구독, 클라이언트·Host의 통신 구조를 설명한다.
GitHub — GitHub Mobile 및 통합 Copilot 클라우드 경험
2026년 10월 28일 발표. GitHub Mobile에서 지원되는 클라우드 에이전트 세션을 시작하고 여러 클라이언트에서 이어가는 기능과 로컬 개발 머신 연결 방식을 설명한다.
Work from anywhere with a new, connected Copilot cloud experience
GitHub Copilot in VS Code — Universe Releases
GitHub — GitHub Mobile 세션 관리
GitHub Mobile에서 세션 로그를 확인하고, PR을 검토하고, 실행 중인 작업을 관리하는 기능을 소개한다.
GitHub Mobile: Refreshed Copilot Tab and Native Session Logs
Microsoft — AHP Swift 클라이언트
Swift Package Manager 의존성, AHPClient, MultiHostClient, State Mirror, WebSocket Transport와 재접속 관련 내용을 확인할 수 있다.
Microsoft — AHP 명세
채널 구독과 이벤트 전달, 초기 Snapshot, 재접속 및 상태 동기화의 구체적인 프로토콜 구조를 확인할 수 있다.
Agent Host Protocol Specification
MCP·A2A 공식 자료
AI 도구 연결과 에이전트 간 협업에 관한 프로토콜 문서. AHP와 목적을 비교할 때 참고할 수 있다.
