고스트티(Ghostty) 터미널의 개발자 미첼 하시모토가 'OSC 7501', 이른바 프로그램 상태 프로토콜(Program Status Protocol)이라는 새로운 터미널 이스케이프 시퀀스 명세를 공개했다. 핵심 아이디어는 단순하다. 터미널에서 실행되는 프로그램이 자신의 상태를 터미널에 직접 보고하도록 하자는 것이다. 상태 값은 유휴(idle), 작업 중(working), 사용자 입력 대기, 완료, 실패의 다섯 가지이며, 여기에 사유를 덧붙일 수 있다. 예를 들어 테라폼은 'Apply 3 to add, 1 to change, 0 to destroy?'라는 메시지를 Base64로 인코딩해 '사용자 입력을 기다리며 멈춰 있다'는 상태를 터미널에 전달할 수 있다. 터미널이나 테라폼을 감싸 실행하는 다른 도구는 이 정보를 알림, 받은편지함, 상태 아이콘 등 원하는 방식으로 표현하면 된다.
왜 지금 이 문제가 커졌나
빌드, 배포, 패키지 업그레이드, 데이터 처리처럼 오래 걸리는 작업은 터미널에서 늘 있어 왔다. 이런 작업은 스스로 돌아가다가, 사용자를 기다리다가, 끝나는 상태를 오간다. 그사이 사용자는 다른 일을 하러 자리를 뜨고, 작업이 끝났거나 자신을 필요로 할 때 알고 싶어 한다. 과거에도 터미널은 포그라운드 프로세스의 변화를 감지하거나, 일정 시간 출력이 '조용해지면' 알림을 주는 식으로 이 문제의 일부를 다뤄 왔다. 하지만 하시모토는 진행 상황, 차단(blocking), 완료, 그리고 여러 작업이 이루는 트리 구조까지 일관되게 전달하는 범용 해법은 없었다고 본다. 기존 시퀀스를 짜깁기해서 안정적으로 구현하기도 어려웠다는 것이다.
이 문제가 특히 고약해진 계기는 코딩 에이전트의 확산이다. 사람들이 배경 리서치, 이슈 모니터링, 버그 수정, 대형 기능 구현 등을 위해 여러 개의 장시간 에이전트를 동시에 돌리는 일이 흔해졌다. 각 에이전트는 한동안 일하다가 권한을 묻거나, 질문을 하거나, 완료를 보고하려고 멈춘다. 그 결과 실행 중인 모든 에이전트를 한 화면에서 보여주는 '에이전트 받은편지함(agentic inbox)'이라는 새로운 도구 범주가 생겨났다. Herdr, cmux, Agent Deck 등 수백 개가 이에 해당한다.
지금의 우회책, 추측과 별도 API
전용 프로토콜이 없는 상황에서 이들 도구는 두 가지 방식으로 상태를 파악한다. 첫째는 화면이나 창 제목을 읽어 알려진 패턴과 대조해 '추측'하는 것이다. 하시모토가 모범 사례로 꼽은 Herdr은 TOML 규칙으로 에이전트를 유휴·작업 중·차단으로 분류한다. 예컨대 클로드 코드는 창 제목이 점자(Braille) 스피너 문자로 시작하면, 그리고 2.1.228 버전부터는 반원 문자로 시작하면 '작업 중'으로 간주한다. 클로드 코드 한 종류만을 위한 규칙이 16개에 이르고, 해당 파일은 석 달 동안 열 번이나 바뀌었다. 이는 Herdr에 대한 비판이 아니라, 주어진 도구로 할 수 있는 최선을 다하고 있음에도 통합 프로토콜이 필요하다는 방증이다.
둘째는 프로그램이 받은편지함 전용 API, 이를테면 Herdr의 소켓 API나 cmux의 notify를 통해 자기 상태를 직접 보고하는 방식이다. 상태를 실제로 아는 당사자가 보고한다는 점에서 추측보다 낫지만, 모든 프로그램이 모든 받은편지함과 개별적으로 연동해야 한다. 게다가 로컬 소켓은 SSH 너머나 컨테이너 안에서는 별도 브리지 없이는 동작하지 않는다. 반면 의사 터미널(pty)은 이 모든 경계를 이미 넘나든다.
명세는 어떻게 생겼나
OSC 7501은 바로 이 pty를 활용한 터미널 네이티브 해법이다. 프로그램은 언제나 갖고 있는 pty를 통해 자기 상태를 직접 보고하며, 어디로 보내도 안전한 형식을 쓴다. 제대로 만들어진 터미널은 모르는 OSC 시퀀스를 무시하기 때문이다. 시퀀스 본문은 콜론(:)으로 구분된 key=value 쌍의 목록이고, 필수 키는 다섯 상태 중 하나를 담는 state뿐이다. 선택 키로는 cargo나 claude-code처럼 안정적인 기계 판독용 이름을 담는 app, 그리고 Base64로 인코딩한 한 줄짜리 사람용 메시지 msg가 있다. 여러 작업을 동시에 돌리는 프로그램은 계층적 id로 여러 레코드를 보고할 수 있다. 배포 도구가 루트에서는 작업 중이면서, us-east는 이미지를 40%까지 푸시하고, eu-west는 운영 배포 승인을 기다리며 차단된 상태를 동시에 표현하는 식이다. 상태를 비우면 해당 레코드는 제거된다.
실무자 입장에서 눈여겨볼 대목은 진입 장벽이 낮다는 점이다. rsync를 감싸 이 프로토콜에 참여시키는 전체 통합을 평범한 POSIX sh 스크립트로 작성할 수 있다. SDK도, 소켓도, 환경 변수도, JSON도 필요 없다. 특정 GUI 표현이나 AI 같은 특정 워크로드에 치우치지도 않는다. 하시모토는 명세가 애플리케이션 개발자가 내보내기 쉽고 터미널 에뮬레이터가 소비·파싱하기 쉽도록 설계됐다고 밝혔다. 레코드 수명, 기능 탐지, terminfo, 크기 제한, 보안 등 나머지 세부는 짧은 전체 명세에 담겨 있다.
이 프로토콜은 이미 두 번 구현됐다. libghostty에 하나, Rex에 병행 구현이 하나 있으며, 테라폼·클로드 코드·Codex·Homebrew에는 플러그인이나 포크 형태의 개념 증명이 들어갔다. 각 경우 구현은 열 줄을 넘지 않았다고 한다. 여러 터미널 프로그램과 에뮬레이터 유지보수자들이 검토에 참여했다는 점도 표준으로서의 현실성을 높인다. 다만 아직은 제안 단계이며, 폭넓은 채택과 상호운용성은 터미널·에뮬레이터·애플리케이션 생태계가 실제로 이 시퀀스를 내보내고 받아들이느냐에 달려 있다. 화면이나 프로세스 트리를 읽어 프로그램의 상태를 추측하는 대신, 상태를 아는 당사자가 직접 말하게 하자는 발상이 얼마나 넓게 퍼질지가 관건이다.