하시코프 공동창업자이자 터미널 고스티(Ghostty)를 만든 미첼 하시모토(Mitchell Hashimoto)가 10월 6일(현지시간) 프로그램이 자신의 상태를 터미널에 보고하는 이스케이프 시퀀스 규격 "Program Status Protocol(OSC 7501)"을 공개했다.
프로그램이 "작업 중", "끝남", "사용자 입력 필요", "오류" 같은 상태를 한 줄짜리 시퀀스로 내보내면 터미널이 이를 탭 표시나 알림으로 바꿔 보여 줄 수 있다. 여러 개의 코딩 에이전트를 동시에 돌려 놓고 어느 창이 나를 기다리는지 찾아 헤매던 문제를 겨냥한 제안이다.
- OSC 7501은
ESC ] 7501 ; state=… ESC \형태의 시퀀스로 idle·working·done·blocked·error 상태를 터미널에 보고하는 규격이다. - blocked 상태는 permission·question·auth 중 무엇이 필요한지 알릴 수 있고, 계층형 id로 여러 하위 작업의 상태를 동시에 보고할 수 있다.
- libghostty 구현이 고스티 저장소에 PR로 올라갔고, Terraform·Claude Code·Codex·Homebrew용 개념 증명 플러그인이 각각 10여 줄로 만들어졌다.
PART 01무슨 일이 있었나
하시모토는 개인 블로그에 "A Terminal Protocol for Program Status (OSC 7501)"라는 글을 올리고, 자신이 만들고 있는 터미널 렉스(Rex)의 문서 사이트에 전체 규격을 공개했다. OSC(Operating System Command)는 터미널 창 제목 변경 등에 오래 써 온 이스케이프 시퀀스 계열로, 이를 인식하지 못하는 터미널은 그냥 무시한다. 그래서 어떤 환경에 내보내도 화면이 깨지지 않는다는 것이 설계의 출발점이다.
글에서 그는 기존 방식의 한계를 짚었다. 지금 터미널은 포그라운드 프로세스를 지켜보거나 출력이 한동안 멈추면 "끝났나 보다"라고 추측한다. 여러 에이전트를 한 화면에 모아 보여 주는 이른바 "에이전트 인박스" 도구들(글에서는 Herdr, cmux, Agent Deck을 예로 들었다)은 화면이나 창 제목을 패턴 매칭하거나 프로그램별 전용 API를 붙인다. 앞의 방식은 프로그램 출력 형식이 바뀌면 깨지고, 뒤의 방식은 인박스마다 통합 작업이 필요한 데다 SSH나 컨테이너 너머에서는 잘 동작하지 않는다. OSC 7501은 프로그램이 직접, 표준 출력 한 줄로 상태를 말하게 하자는 해법이다.
PART 02규격 핵심
형식은 일부러 단순하게 잡았다. 본문은 콜론으로 이은 key=value 쌍이고, 값에 쓸 수 있는 문자가 제한돼 있어 이스케이프가 필요 없다. 사람이 읽는 문장은 base64로 감싼다. 각 보고는 해당 기록을 통째로 교체하므로, 빠뜨린 키는 지워진 것으로 처리된다. 아래는 규격 문서에 실린 예시로, cargo 빌드가 진행 중이라고 알렸다가 지우는 시퀀스다.
ESC ] 7501 ; state=working:app=cargo:msg=QnVpbGRpbmc= ESC \
ESC ] 7501 ; state=clear ESC \블로그는 쓰임새도 몇 가지 들었다. Terraform이 apply 확인을 기다릴 때 blocked 상태와 이유 메시지를 보내면 사용자는 다른 탭에서 일하다가도 승인이 필요하다는 것을 알 수 있다. 여러 리전에 배포하는 도구라면 계층형 id로 리전별 하위 작업을 따로 보고해, 한 리전은 완료, 다른 리전은 오류, 또 다른 리전은 진행 중인 상태를 동시에 보여 줄 수 있다. 설계 목표로는 특정 제품이나 AI 같은 특정 워크로드에 묶이지 않는 범용성을 명시했다.
기록의 수명 규칙도 정해 두었다. 타이머로 만료되지 않고 하트비트도 필요 없다. 대신 연결된 프로세스가 끝나거나 새 셸 프롬프트가 시작되면(OSC 133 A) 터미널은 working·blocked 기록을 지워야 한다. done과 error는 남는다. 사용자가 결과를 확인하기 전까지 "끝났다"는 표시가 유지되는 셈이다. 지원 여부는 OSC 7501 ; ? 질의로 확인하고, 응답을 무한정 기다리지 않도록 뒤에 장치 속성 질의(CSI c)를 붙이는 방식을 권한다.
PART 03보안과 한계
터미널 이스케이프 시퀀스는 과거 여러 번 공격 경로가 됐다. 이를 의식한 듯 규격은 방어 규칙을 꽤 촘촘히 넣었다. 디코딩한 msg와 title에 제어 문자가 있으면 보고 전체를 버려야 하고, 이 필드를 마크업으로 해석해서도 안 된다. 터미널이 프로그램에 돌려주는 데이터는 지원 여부 응답 하나뿐이라, 다른 프로그램이 남긴 기록을 읽어 갈 수 없다. 데스크톱 알림이나 소리 같은 외부 효과에는 속도 제한을 두라고 권하고, 표시할 때는 어느 터미널에서 온 기록인지 드러내라고 했다.
물론 이것은 아직 제안 단계다. 하시모토 본인이 만든 렉스와 libghostty 구현 PR이 있을 뿐, 다른 주요 터미널이 지원을 약속한 것은 아니다. 글도 피드백을 요청하고, 구현하는 쪽이 연락하면 목록에 올리겠다며 끝난다. 결국 확산 여부는 iTerm2, WezTerm, 윈도 터미널 같은 다른 터미널과, 상태를 내보낼 쪽인 CLI 도구들이 얼마나 따라오느냐에 달렸다.
PART 04개발자가 지금 해 볼 수 있는 것
state=blocked:kind=permission 등을 보내면, 지원 터미널에서 해당 탭이 "나를 기다리는 중"으로 표시될 수 있다.자주 묻는 질문
OSC 7501은 무엇인가요?
프로그램이 터미널에 자신의 상태(대기·작업 중·완료·사용자 조치 필요·오류)를 알리는 이스케이프 시퀀스 규격이다. 미첼 하시모토가 10월 6일 Program Status Protocol이라는 이름으로 공개했다. 이를 모르는 터미널은 시퀀스를 무시하므로 어디서든 안전하게 보낼 수 있다.
고스티(Ghostty)에서 바로 쓸 수 있나요?
공개 시점 기준으로는 libghostty 구현이 고스티 저장소에 PR로 올라간 단계다. 정식 릴리스에 들어갔다는 내용은 발표에 없었다. 하시모토의 다른 터미널 렉스(Rex)는 이미 구현을 갖고 있다.
코딩 에이전트와 무슨 관계가 있나요?
여러 코딩 에이전트를 동시에 돌리는 개발자는 어느 에이전트가 권한 승인이나 질문 답변을 기다리는지 알기 어렵다. OSC 7501의 blocked 상태와 kind 값으로 이를 터미널에 직접 알릴 수 있다. 하시모토는 Claude Code와 Codex용 개념 증명 플러그인도 만들었다고 밝혔다.
내 셸 스크립트에도 적용할 수 있나요?
가능하다. 하시모토는 rsync를 감싸 작업 중·완료·오류 상태를 보고하는 짧은 POSIX sh 함수를 예시로 보였다. printf로 시퀀스를 출력하기만 하면 되고 별도 라이브러리는 필요 없다.

댓글 0