최근 Cursor나 Claude Code, Cline 같은 AI 에이전트 툴을 로컬 개발 환경에서 적극적으로 활용하고 있습니다.

제 운영 방식은 '프로젝트당 하나의 Claude Code를 구동한다'는 스타일이기 때문에, 여러 프로젝트나 레이어(프론트엔드, API, 인프라 등)를 병행 진행하게 되면 수많은 AI 세션이 동시에 작동하게 됩니다.

처음에는 '터미널에서 지시만 하면 코드를 작성해 준다! 최고!'라며 감동했지만, 숨 쉬는 것처럼 대량의 AI를 동시 구동하게 되면서 한 가지 고민에 빠지게 되었습니다.

바로 'AI 에이전트가 너무 많아 길을 잃는 문제'입니다.

백엔드 API 수정은 Claude Code에게 맡기고, 프론트엔드 컴포넌트는 Cursor로 구현하고, 뒤로는 다른 인프라 설정을 돌리는 식입니다. 이런 작업을 하다 보면 터미널 창이 여기저기 흩어집니다. 커피를 내려서 돌아왔더니 '아, 30분 전부터 파일 덮어쓰기 허용(Y/n)에서 멈춰 있네...' 같은 비극이 빈번하게 발생합니다.

터미널을 계속 전환하지 않으면 상황 파악이 불가능했고, AI의 힘을 끌어내야 하는데 오히려 터미널 관리에 시간을 쓰고 있다는 사실을 깨달았습니다.

이 이야기를 하면 'Tmux나 Zellij 같은 터미널 멀티플렉서를 사용하면 어때?', 'Warp나 Ghostty 같은 차세대 터미널이 있잖아', 'Lumbergh나 CliDeck, Cockpit으로 세션 관리를 하면 되지'라는 조언을 듣곤 합니다.

물론 이들 모두 훌륭한 도구입니다. 하지만 이는 경쟁이라기보다는 '해결하고 있는 과제' 자체가 완전히 다릅니다.

기존의 도구들은 **'터미널(Terminal)'**이나 **'AI 세션(AI Session)'**을 관리합니다.

하지만 제가 원했던 것은 **'프로젝트 전체의 상태 파악'**이었습니다.

알고 싶은 정보는 터미널이라는 검은 화면 그 자체가 아닙니다.

'지금 어떤 프로젝트가 돌아가고 있는지', '어떤 에이전트가 멈춰 있는지', '내가 기다리는 중인지', '리뷰 중인지', '다음으로 내가 무엇을 해야 하는지'와 같은 정보입니다.

화면의 주인공은 터미널이 아니라, **프로젝트(Project)**여야 합니다 (Project First).

저는 이 문제를 해결하기 위해 SwiftUI로 네이티브 macOS 앱인 'AI Control Center'를 직접 만들었습니다.

이 앱의 근간에는 Human First라는 사상이 깔려 있습니다.

AI 에이전트가 많아질수록, 인간이 전체 상황을 파악하는 비용은 급격히 높아집니다. 개발의 병목 현상은 더 이상 '코딩'이 아니라, **'상황 파악(状況把握)'과 '컨텍스트 스위치(Context Switch)'**로 이동한 것입니다.

그렇기에 '지금 내 차례인지? (Waiting User)'를 단 5초 만에 알 수 있다는 것은 엄청난 가치를 지닌다고 생각했습니다.

이 도구를 구현하면서 가장 먼저 포기했던 접근 방식은 '터미널의 표준 출력(stdout)을 감시하고 파싱하는(Terminal Parsing)' 것이었습니다. 에이전트마다 UI와 출력 방식이 다르고, 업데이트에 따라 쉽게 고장 나기 때문입니다.

그래서 발상을 전환하여, **'AI를 공통 상태 모델로 추상화하는 것'**으로 방향을 잡았습니다.

AI Control Center는 Claude Code 전용 뷰어만 아닙니다.

Claude Code, Cursor Agent, Gemini CLI, Aider, 그리고 미래에 등장할 미지의 에이전트까지 모두 공통의 **'상태 계약(Status Contract)'**으로 다루는 것을 목표로 합니다.

구체적으로는 각 프로젝트 루트에 .ai/agent-status.json을 배치한다는 규칙을 만들었습니다.

{
"schema_version": "1.0",
"agent": "claude-code",
...
}

대시보드 측은 에이전트를 직접 분석하는 것이 아니라, 이 Contract(JSON)만 읽습니다.

이것이 File-Based Status Architecture입니다.

장기적으로는 에이전트가 늘어나도 대시보드 측의 변경이 필요 없습니다. 새로운 에이전트는 이 Status Contract를 구현하는 어댑터만 준비하면 됩니다.

사실 제가 만들고 있는 진짜 가치는 Mac 앱 자체가 아니라, 바로 이 'AI 에이전트 간의 공통 상태 사양(Status Contract)'일지도 모릅니다.

이것이 안정된다면, AI 개발 도구 간을 연결하는 강력한 기반이 될 수 있을 것이라 확신합니다.

현재 구현 중인 MVP(Minimum Viable Product, 최소 기능 제품)는 다음과 같은 구성입니다.

실시간 상태 감지 (Real-time State Detection): 사고 중, 실행 중, 사용자 대기 중 등의 상황을 시각화

알림 기능 (Notification): 승인 대기 상태가 된 순간 macOS 네이티브 알림으로 안내

터미널 점프 (Terminal Jump): 리스트를 더블 클릭하여 대상 터미널(Terminal.app, iTerm2 등)로 즉시 이동

기술적으로는 다음과 같은 모던한 구성을 채택하고 있습니다.

Swift 6 & SwiftUI: Combine은 사용하지 않고, @Observable과 Actor 모델 (@MainActor)을 활용.

FSEvents (FSEventStream): 저수준(Low-level) API로 JSON 업데이트를 감지.

AsyncStream 브릿지 (AsyncStream Bridge): C 언어 기반의 콜백을 async/await로 안전하게 브릿지하여 초저부하로 모니터링.

이 프로젝트가 지향하는 것은 단순한 편리한 도구가 아니라, Mac 전체에서 동작하는 AI 개발의 사령탑, 즉 「AI Development Operating System (AI 개발용 OS)」 입니다.

머지않아 상태뿐만 아니라 개발의 「Workflow (워크플로우)」도 관리할 예정입니다.

Spec → Plan → Coding → Testing → Review → Done

이라는 흐름을 프로젝트 단위로 시각화하고, 앱 상에서 직접 AI의 채팅을 들여다보거나, 원클릭으로 승인(Approve)을 내릴 수 있도록 할 계획입니다.

이번에는 수많은 AI 에이전트를 하나로 묶기 위한 사상과, 공통 사양으로서의 「Status Contract (상태 계약)」에 대해 소개했습니다.

다음 시리즈에서는 「Swift 6에서 C 언어의 FSEvents를 AsyncStream으로 안전하게 브릿지하는 구현」 이나, 「알림과 터미널 점프를 AppleScript로 강제적이면서도 우아하게 해결한 이야기」 등 더욱 깊이 있는 기술적 토픽을 다뤄보려 합니다.