80열 터미널이 에이전트 기본 화면인 게 이상하다고 Stripe CEO가 썼습니다

Stripe CEO Patrick Collison이 트윗을 올렸습니다.

에이전틱 코딩 하네스를 좋아하지만, 기본 인터페이스가 터미널이어서는 안 된다. 동적 언어 REPL이 Jupyter로 나오는 데 오래 걸렸다. 하네스는 그만큼 기다리지 않았으면 한다.

콜리슨은 에이전트의 손과 사람의 눈을 같은 창에 가둔 설계를 범주 오류로 봅니다.

터미널의 어디가 부족한가요?

콜리슨은 두 가지를 문제 삼았고, 둘은 성격이 달라요.

정보 밀도는 한 화면에 얼마나 많은 상태를 동시에 볼 수 있느냐의 문제예요. 에이전트 세션에서 사람은 스크롤백 한 줄보다 훨씬 많은 걸 봐야 합니다. 멀티파일 diff, 테스트 실패 위치, 병렬 세션 상태, 트레이스, 스크린샷, 승인 대기 목록이에요.

80열 터미널은 이 중 대부분을 공간에 나란히 놓지 않고 시간 순으로 흘려보내요. 그만큼 사람은 한 화면에서 볼 수 있는 상태를 잃습니다.

UI 어포던스는 그 상태에서 무엇을 바로 할 수 있느냐의 문제입니다. hunk 하나만 되돌리기, 세션 세 개를 한눈에 전환하기, 실패한 테스트 줄로 점프하기, 스크린샷 위에 주석을 달고 에이전트에게 되돌려주기.

터미널에서도 키바인딩과 TUI로 흉내는 낼 수 있어요. 다만 숙련자만 그 우회를 씁니다. 콜리슨은 그 우회가 기본 경험이 된 점을 이상하다고 했어요.

TUI를 없애라는 말도 아닙니다. 터널 하나 열기 귀찮을 때, SSH로 원격 박스에 붙었을 때, 한 방 명령이 필요할 때는 터미널이 맞아요. 원문 그대로 "occasional use"죠. 콜리슨은 터미널이 기본 모달리티라는 점을 이상하게 봅니다.

왜 터미널이 기본값이 되었나요?

2025년 전후로 코딩 에이전트는 모델 점수보다 인터페이스를 옮기면서 돌파구를 찾았습니다. 브라우저 채팅창의 모델은 rm을 말할 수 있었지만 실행하지 못했어요. 터미널로 나오자 모델은 파일과 테스트와 git에 손을 뻗었습니다.

Claude Code, Codex CLI, OpenCode, Pi 같은 도구가 같은 방향으로 움직였어요. 셸은 이미 개발자 머신에 있었고, 배포 비용이 거의 없었습니다.

여기서 도구를 만든 팀들은 액추에이터와 뷰포트를 한 창에 묶었어요. 에이전트가 bash를 써야 하니, 사람도 bash가 보이는 창을 기본 화면으로 받게 된 겁니다. 손은 맞아요. 다만 사람들은 편해서 눈도 손을 따라 터미널에 뒀습니다.

터미널 네이티브 에이전트는 가드를 걷어낸 덕에 힘을 얻기도 했어요. 같은 이유로 사람은 그 창을 리뷰 콘솔로 쓰기 어렵습니다. 실행과 감독을 굳이 한 표면에서 할 필요는 없어요.

에디터를 만드는 팀들은 이미 반대 압력을 받고 있습니다. 에이전트가 액터가 되면 사람은 에디터에서 타이핑하기보다 에디터를 감독 콘솔로 쓰게 돼요. diff 승인, 에이전트 상태 스트림, 정책 훅, 터미널 출력의 기계적 판독.

플러그인 API가 사람을 위해 만든 표면으로는 이 목록을 다 받지 못합니다. 그래서 팀들은 제품을 포크하거나, 데스크톱 앱으로 만들거나, 클라우드 샌드박스 위에 별도 뷰를 얹어요. 콜리슨은 그 압력을 한 줄로 말한 셈이에요.

Jupyter 비유는 왜 정확한가요?

Jupyter는 파이썬 인터프리터를 죽이지 않았습니다. 계산은 그대로 두고 검사 표면만 바꿨어요. 셀, 그림, 표, 중간값, 공유 가능한 결과물. REPL은 그대로 두고 기본 화면에서만 내렸죠.

에이전틱 하네스에도 같은 분리가 필요합니다. 런타임은 헤드리스여도 돼요. 파일 읽기, 패치, 테스트, 샌드박스, 훅, 서브에이전트.

사람이 머무는 화면은 상태와 증거와 개입 지점을 보여줘야 합니다. 런타임 로그를 읽는 창과는 다른 표면이에요.

분리하지 않으면 에이전트와 사람 둘 다 손해를 봅니다. 에이전트는 사람이 읽기 좋은 로그를 남기느라 도구 출력을 덜 압축하고, 사람은 스크롤백을 따라가느라 병렬 작업과 시각 검증을 포기해요.

터미널 탓은 아니에요. 한 창에 두 역할을 맡기면 사람도 에이전트도 어중간하게 일하게 됩니다.

콜리슨이 "오래 기다리지 말자"고 한 대목도 기술 비관으로 읽을 필요는 없어요. REPL이 노트북으로 나오는 데 걸린 시간을 하네스에서 되풀이하지 말자는 말에 가까워요.

다른 팀들은 어느 쪽으로 가고 있나요?

원 글 아래 답글에서 두 방향을 볼 수 있어요. OpenAI 개발자 경험 담당 Romain Huet(전 Stripe)은 같은 날 이렇게 받았어요. "새로운 종류의 코딩 하네스에는 새로운 종류의 인터페이스가 필요하다."

Codex 앱을 만든 이유로 computer use, 브라우저 안 주석, 에이전트와 붙는 더 밀도 높은 표면을 들었습니다.

반대편에는 터미널을 최소 코어로 남기려는 줄이 있어요. Pi 같은 하네스는 도구를 네 개로 줄이고 확장은 패키지에 맡깁니다. 이쪽은 투명성과 소유권을 챙깁니다. 시스템 프롬프트와 컨텍스트를 제품이 삼키지 않게 막는 쪽입니다.

콜리슨의 문장과 모순되지 않아요. 런타임을 작게 유지하는 일과, 사람 화면을 터미널에 가두는 일은 다른 결정입니다.

Cursor와 클라우드 에이전트, Claude Cowork, 데스크톱 세션 관리기가 같은 공백을 다른 각도에서 메우고 있어요. 공통점은 하나입니다. 실행은 계속 셸과 파일시스템 위에서 일어나고, 사람은 점점 그 로그 바깥에서 감독합니다.

지금 무엇부터 나눌 수 있나요?

에이전트의 손은 그대로 둡니다. bash, 파일 도구, 테스트 러너, git. 여기를 GUI로 포장한다고 모델이 잘하지는 않아요. 학습 데이터와 조합 가능성이 있는 쪽은 여전히 커맨드입니다.

사람의 눈은 빼냅니다. 리뷰는 diff 뷰어에서 하고, 병렬 작업은 세션 목록에서 봐요. 시각 검증은 브라우저나 스크린샷에서 하고, 실패는 테스트 패널에서 점프합니다.

"에이전트가 뭐 했는지"는 커밋, 로그 인용, 테스트 결과물로 남겨요.

TUI를 기본값으로 둬도 되는 경우는 분명합니다. 원격 한 대, 작업 하나, 출력이 텍스트, 사람이 한 명. SSH 터널이 전부인 밤의 핫픽스가 여기 해당해요.

아래 중 두 개 이상이면 터미널은 병목이에요.

• 세션이 동시에 둘 이상이다
• 결과가 화면을 보고 판단해야 한다
• 승인이나 거절이 hunk 단위여야 한다
• 산출물을 다른 사람에게 공유해야 한다
• 에이전트가 길어서 중간 상태를 공간으로 봐야 한다

새 제품을 살 필요는 없어요. 이미 하고 있는 분할을 인정하면 됩니다. 에이전트는 CLI로 돌리고, 리뷰는 IDE diff로 하고, 긴 작업은 이슈/PR에 증거를 남깁니다.

많은 팀이 이미 그렇게 해요. 다만 여전히 그걸 "아직 TUI가 기본이고, 나머지는 보조"라고 부르곤 해요. 콜리슨이 이상하다고 한 지점은 그 습관이에요.

남는 생각

그동안 사람들은 하네스를 얘기할 때 주로 프롬프트, 스킬, 서브에이전트, 컨텍스트 윈도우를 다뤘습니다. 그 층은 중요해요. 다만 사람이 하루 종일 보는 표면이 80열 로그라면, 그 위의 오케스트레이션은 보기 어렵습니다. 안 보이면 감독하기 어렵고, 감독을 못 하면 병렬 작업도 검증도 덜 하게 되죠.

저는 콜리슨의 한 줄을 기본 화면을 액추에이터에서 뷰포트로 옮기라는 요구로 읽습니다. 터미널은 남습니다. 손으로서.

---