본문 바로가기
개발2026년 10월 7일10분 읽기

미첼 하시모토, 터미널 표준 OSC 7501 제안 — 코딩 에이전트가 "막혔다"를 직접 알린다

YS
김영삼
조회 5
미첼 하시모토, 터미널 표준 OSC 7501 제안 — 코딩 에이전트가 "막혔다"를 직접 알린다

하시코프 공동창업자이자 터미널 고스티(Ghostty)를 만든 미첼 하시모토(Mitchell Hashimoto)가 10월 6일(현지시간) 프로그램이 자신의 상태를 터미널에 보고하는 이스케이프 시퀀스 규격 "Program Status Protocol(OSC 7501)"을 공개했다.

프로그램이 "작업 중", "끝남", "사용자 입력 필요", "오류" 같은 상태를 한 줄짜리 시퀀스로 내보내면 터미널이 이를 탭 표시나 알림으로 바꿔 보여 줄 수 있다. 여러 개의 코딩 에이전트를 동시에 돌려 놓고 어느 창이 나를 기다리는지 찾아 헤매던 문제를 겨냥한 제안이다.

3줄 요약
  • 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규격 핵심

Rex 문서의 Program Status 규격 기준
키값설명
state (필수)idle · working · done · blocked · error · clear대기·실행 중·완료(결과 미확인)·사용자 조치 필요·실패. clear는 기록 삭제
kindpermission · question · authblocked일 때 무엇이 필요한지
progress0~100 정수working·blocked일 때 진행률. 없으면 불확정
id/로 구분한 경로하위 작업을 계층으로 보고(최대 8단계)
app프로그램 식별자자식 기록은 가까운 조상에서 상속
title, msgUTF-8 텍스트의 base64짧은 라벨과 한 줄 상태 메시지

형식은 일부러 단순하게 잡았다. 본문은 콜론으로 이은 key=value 쌍이고, 값에 쓸 수 있는 문자가 제한돼 있어 이스케이프가 필요 없다. 사람이 읽는 문장은 base64로 감싼다. 각 보고는 해당 기록을 통째로 교체하므로, 빠뜨린 키는 지워진 것으로 처리된다. 아래는 규격 문서에 실린 예시로, cargo 빌드가 진행 중이라고 알렸다가 지우는 시퀀스다.

msg의 QnVpbGRpbmc= 는 "Building"의 base64
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보안과 한계

4096바이트
시퀀스 하나의 최대 길이
256개
터미널당 최대 기록 수(최소 64개 지원 의무)
8단계
계층형 id의 최대 깊이

터미널 이스케이프 시퀀스는 과거 여러 번 공격 경로가 됐다. 이를 의식한 듯 규격은 방어 규칙을 꽤 촘촘히 넣었다. 디코딩한 msg와 title에 제어 문자가 있으면 보고 전체를 버려야 하고, 이 필드를 마크업으로 해석해서도 안 된다. 터미널이 프로그램에 돌려주는 데이터는 지원 여부 응답 하나뿐이라, 다른 프로그램이 남긴 기록을 읽어 갈 수 없다. 데스크톱 알림이나 소리 같은 외부 효과에는 속도 제한을 두라고 권하고, 표시할 때는 어느 터미널에서 온 기록인지 드러내라고 했다.

물론 이것은 아직 제안 단계다. 하시모토 본인이 만든 렉스와 libghostty 구현 PR이 있을 뿐, 다른 주요 터미널이 지원을 약속한 것은 아니다. 글도 피드백을 요청하고, 구현하는 쪽이 연락하면 목록에 올리겠다며 끝난다. 결국 확산 여부는 iTerm2, WezTerm, 윈도 터미널 같은 다른 터미널과, 상태를 내보낼 쪽인 CLI 도구들이 얼마나 따라오느냐에 달렸다.

영삼
영삼의 한마디
나는 이 제안이 꽤 잘 될 거라고 본다. 이유는 진입 비용이 거의 0이기 때문이다. 하시모토가 보여 준 예시처럼 POSIX sh 함수 몇 줄이면 rsync 같은 기존 명령도 상태를 보고할 수 있고, 지원하지 않는 터미널은 그냥 무시한다. SDK도 소켓도 환경 변수도 JSON도 필요 없다는 점이 핵심이다. 다만 이름에서 보듯 "또 하나의 OSC 번호"라는 점은 약점이다. 진행률 표시만 해도 이미 터미널마다 쓰는 시퀀스가 갈려 있는데, 여기서 표준을 하나 더 늘리는 결과가 되지 않으려면 큰 CLI 몇 개가 먼저 채택해 줘야 한다.

PART 04개발자가 지금 해 볼 수 있는 것

1
규격 문서 읽기
superlogical.com의 Rex 문서에 기록 수명, 기능 감지, terminfo, 크기 제한, 보안 규칙이 모두 정리돼 있다. 구현 전에 수명 규칙(프롬프트 시작 시 working 삭제)을 꼭 이해해야 한다.
2
내 CLI에 상태 보고 넣어 보기
긴 작업을 하는 사내 도구나 배포 스크립트가 있다면 시작 시 working, 끝나면 done, 실패하면 error를 내보내는 것만으로 충분하다. 지원하지 않는 터미널에서는 아무 일도 일어나지 않는다.
3
사용자 확인 대기 지점 표시
배포 승인, 비밀번호 입력, 질문 응답처럼 사람이 필요한 순간에 state=blocked:kind=permission 등을 보내면, 지원 터미널에서 해당 탭이 "나를 기다리는 중"으로 표시될 수 있다.
4
피드백 남기기
규격은 공개 피드백을 받고 있다. 터미널이나 에이전트 도구를 만든다면 구현 후 연락해 목록에 오르는 것도 방법이다.
주의 msg와 title은 반드시 base64로 인코딩해야 하고, 디코딩 결과에 제어 문자가 섞이면 보고 전체가 무시된다. 사용자 입력이나 파일 이름을 그대로 msg에 넣을 때는 줄바꿈 등을 먼저 제거하자.

자주 묻는 질문

OSC 7501은 무엇인가요?

프로그램이 터미널에 자신의 상태(대기·작업 중·완료·사용자 조치 필요·오류)를 알리는 이스케이프 시퀀스 규격이다. 미첼 하시모토가 10월 6일 Program Status Protocol이라는 이름으로 공개했다. 이를 모르는 터미널은 시퀀스를 무시하므로 어디서든 안전하게 보낼 수 있다.

고스티(Ghostty)에서 바로 쓸 수 있나요?

공개 시점 기준으로는 libghostty 구현이 고스티 저장소에 PR로 올라간 단계다. 정식 릴리스에 들어갔다는 내용은 발표에 없었다. 하시모토의 다른 터미널 렉스(Rex)는 이미 구현을 갖고 있다.

코딩 에이전트와 무슨 관계가 있나요?

여러 코딩 에이전트를 동시에 돌리는 개발자는 어느 에이전트가 권한 승인이나 질문 답변을 기다리는지 알기 어렵다. OSC 7501의 blocked 상태와 kind 값으로 이를 터미널에 직접 알릴 수 있다. 하시모토는 Claude Code와 Codex용 개념 증명 플러그인도 만들었다고 밝혔다.

내 셸 스크립트에도 적용할 수 있나요?

가능하다. 하시모토는 rsync를 감싸 작업 중·완료·오류 상태를 보고하는 짧은 POSIX sh 함수를 예시로 보였다. printf로 시퀀스를 출력하기만 하면 되고 별도 라이브러리는 필요 없다.

참고 자료

댓글 0

아직 댓글이 없습니다.
Ctrl+Enter로 등록