SNA와 ACP
SNA와 Zed Agent Client Protocol의 역할 차이를 정리합니다.
ACP는 에디터와 코딩 에이전트 사이의 상호운용 프로토콜입니다. Zed는 ACP를 ACP 호환 에디터 환경에 어떤 ACP-speaking 에이전트든 연결할 수 있게 하는 표준으로 정의합니다. 이 구조에서는 에디터가 UI를 제공하고, 에이전트가 공통 프로토콜로 응답합니다.
SNA가 푸는 문제는 다릅니다. SNA는 앱이 네이티브 에이전트 CLI를 백엔드처럼 임베드할 수 있게 하는 런타임 서버입니다. 앱이 SNA를 호스트하고, SNA가 에이전트 런타임을 spawn하고 관리합니다. 그 위에 세션 라이프사이클, 정규화 히스토리, 권한, HTTP/WebSocket API, React 바인딩을 제공합니다.
| 축 | ACP | SNA |
|---|---|---|
| 주 계층 | 에디터-에이전트 wire protocol | 런타임 서버와 SDK |
| 주 호스트 | 에디터 또는 IDE | 앱, Electron 앱, 서비스 |
| 핵심 목표 | 하나의 프로토콜로 에디터가 여러 에이전트를 지원 | 앱이 에이전트 런타임을 백엔드처럼 임베드하고 제어 |
| 상태 모델 | 프로토콜 수준의 세션과 업데이트 | SessionManager, SQLite 히스토리, runtime chain, 이벤트 버퍼 |
| 런타임 전략 | 에이전트가 ACP를 노출하며, 보통 어댑터를 거침 | SNA는 고충실도 네이티브 런타임 어댑터를 우선하고, ACP 호환성은 이후 확장 가능 |
| UI 대상 | 에디터 네이티브 agent panel | 앱이 정의한 UI, React 컴포넌트, 커스텀 클라이언트 |
왜 ACP가 SNA를 대체하지 않는가
ACP는 에디터와 에이전트 사이의 N×M 통합 비용을 줄인다는 점에서 중요합니다. 하지만 SNA의 런타임 제어면을 대체하지는 않습니다. SNA는 wire protocol 주변의 제품 문제를 직접 소유해야 합니다.
- 멀티 세션 라이프사이클과 세션별 런타임 설정.
- 재시작과 런타임 교체를 견디는 정규화 히스토리.
- Claude Code, Codex, OpenCode를 위한 런타임 네이티브 replay 어댑터.
- 서로 다른 네이티브 승인 시스템을 관통하는 권한 정규화.
- 자식 프로세스 라이프사이클과 네이티브 SQLite 바인딩 해석 같은 Electron 임베딩 세부 사항.
- Web, Node, React 앱을 위한 SDK 표면.
SNA가 너무 이른 시점에 ACP만을 런타임 계층으로 삼으면, 네이티브 제어면에 접근하지 못하거나 ACP 래퍼가 필요한 기능을 노출하기를 기다려야 합니다. 이는 SNA의 철학과 맞지 않습니다. SNA는 먼저 네이티브 에이전트의 기능을 최대한 사용하고, 앱이 의존해야 하는 경계만 정규화합니다.
어떻게 함께 쓸 수 있는가
ACP는 여전히 SNA에 유용합니다. 핵심 철학을 바꾸지 않고도 두 경계에 붙일 수 있습니다.
- SNA가 ACP를 노출할 수 있습니다. ACP 호환 에디터가 SNA에 연결하면 SNA의 세션 관리, 정규화 히스토리, 런타임 교체, 권한 모델을 그대로 활용할 수 있습니다.
- SNA가 ACP를 소비할 수 있습니다. generic ACP runtime adapter를 추가하면 지원 가능한 에이전트 폭을 넓힐 수 있습니다. 다만 깊은 제어가 필요한 런타임에서는 네이티브 런타임 어댑터가 고충실도 경로로 남습니다.
따라서 의도한 관계는 "ACP 대 SNA"가 아닙니다. ACP는 표준 호환성 표면이고, SNA는 네이티브 에이전트 동작을 보존하면서 앱이 사용할 durable state를 소유하는 런타임 계층입니다. SNA는 필요할 때 경계에서 ACP를 말할 수 있습니다.