JSON을 쓰지 않는다는 결정이 정말 답답함. 앞으로도 새 이스케이프 시퀀스는 계속 나올 텐데, 저마다 독자적인 직렬화 형식을 쓰면 도입이 느려지고 버그의 원인이 됨. 널리 쓰이고 쉽게 구할 수 있는 직렬화 형식을 요구하는 건 무리한 요구가 아님.
꼭 JSON일 필요는 없지만, 지금은 사실상 JSON이 승리한 셈임. 명세에 나온 모든 예제 프로그램이 이미 JSON을 다루고 있고, base64가 있는 셸 환경이라면 대부분 jq도 있을 것임. 도구 개발자에게 별도 구현을 떠넘기면서 대체 무엇을 아끼는지 모르겠고, 통합 과정만 더 고통스러워짐.
명세를 작성한 입장에서 설명하자면, 지난 몇 년간 거의 모든 터미널 명세를 구현해 볼 기회가 있었고, 이 형식은 여러 애플리케이션이 이미 구현한 Kitty 프로토콜과 매우 비슷하도록 의도적으로 선택했음. JSON을 쓰는 터미널 명세는 당장 하나도 떠오르지 않으며, Ghostty에서는 기존 Kitty 프로토콜용 보조 코드를 재사용할 수 있었음.
애플리케이션 쪽에서도 여러 터미널 명세를 구현해 봤는데, 이 키/값 형식은 printf로 다루기 편함. 이 명세도 대부분 printf만 쓰면 됨. 요약하면 익숙한 형식이고, 적어도 현대적인 터미널의 관행에 더 잘 맞음.
20년 전에는 XML이 승리했음. 어디에나 XML이 있었음. JSON에도 성가신 면이 있으니, 20년 뒤 다른 직렬화 형식이 그 자리를 차지하더라도 놀랍지 않을 것임.
사실상 터미널 안에서 사는 입장이지만, 터미널의 브라우저화가 반갑지만은 않음. 데스크톱 세션과 상호작용할 방법은 이미 있고, 터미널 자체에 기능을 너무 많이 넣으면 그 안에서 프로그램을 실행해 할 수 있는 멋진 발상이 오히려 줄어들 수 있음.
주의를 끌어야 한다면 notify-send, spd-say, curl ntfy.sh 등에서 골라 쓰는 것으로 충분히 만족함. 필요하다면 수없이 나오는 에이전트 실행 도구에 “나를 호출하려면 이 명령을 실행하라”는 옵션만 추가하면 됨.
이 부분은 철학적인 차이가 있는 듯함. 브라우저보다 기능 범위는 훨씬 작아야 한다는 전제 아래, 터미널이 지향할 모델로 브라우저를 여러 번 공개적으로 칭찬해 왔음. 브라우저는 과도한 애플리케이션 플랫폼 쪽으로, 터미널은 정체된 애플리케이션 플랫폼 쪽으로 너무 치우쳤다고 봄.
처음부터 내 터미널 프로젝트의 목표는 이 정체를 깨는 것이었음. 3년 전 첫 Ghostty 발표에서도 브라우저가 매년 수백 가지 기능을 내놓는다면 터미널은 연간 10개 정도를 내놓았으면 한다고 했던 것 같음.
동의하지 않아도 괜찮음. 내 프로젝트 대신 xterm 같은 것을 쓰면 됨. xterm은 훌륭하며, 우리도 과거 명세의 동작을 확인하는 기준으로 삼고 있음.
그러라고 stdout과 stderr가 따로 있는 것 아닌가?
그렇지는 않음. 진행률 표시줄을 보여 주는 TUI 형태의 애플리케이션을 생각해 보면, stdout과 stderr가 따로 있어도 터미널이 작업 완료를 아는 것은 해결되지 않음. 오히려 둘을 함께 쓰면 텍스트가 뒤섞여 사용자 입장에서 더 나빠질 수 있음.
명세에서 이를 명시적으로 다루고 있음. 기존 시퀀스는 필요한 기능의 일부만 제공하며, OSC 9;4는 작업 중인지 여부는 알릴 수 있어도 프로그램이 사용자 입력을 기다리는지, 무슨 작업을 하는지는 알릴 수 없음.
에이전트용으로 탭 기반 실행 도구를 쓰고 싶지 않아서, 상태를 추론하는 플러그인을 직접 만들었음. 서버에서 노트북으로 상태를 전달하고, 에이전트 세션 이름과 niri 작업 공간 이름이 일치하면 알림을 통해 해당 작업 공간으로 이동하도록 구현함.
꽤 지저분한 임시방편이라, 에이전트 실행 도구와 터미널이 기본으로 지원해 주면 좋겠음.