요약 (TL;DR)

2026년 7월 5일, Alt+Tab 전환이 마치 야생 동물 다큐멘터리처럼 느껴질 정도로 복잡해지자, 저는 Codex에게 2x3 그리드 형태의 Git Bash 터미널을 포함하는 앱 하나를 만들어 달라고 요청했습니다. 첫 번째 시도는 Windows Terminal 창(panes)을 스크립트로 제어하는 방식이었으나, 모양이 어색하고 크기 조절이 제대로 되지 않았으며 제가 원하는 선택 및 입력 라우팅 (input-routing) 모델을 지원할 수 없었습니다. 그래서 저는 실제 가상 터미널 (pseudo-terminals)을 소유하고 하나의 프로세스 내에서 이를 렌더링하는 Rust 기반의 TUI로 방향을 전환했습니다.

"계획을 실행해 (Implement the plan)"라고 말한 지 약 12분 만에 첫 번째 Rust 커밋이 완료되었습니다. 저는 UTC 기준 22:17에 npm에 gridbash@0.1.0을 게시했고, 3분 뒤에 해당 창들이 아직 사용 가능한 터미널이 아니라는 사실을 발견했으며, 그로부터 29분 후에 GitHub 저장소를 생성했습니다. 이는 권장되는 순서는 아니지만, 실제로 일어난 순서입니다.

저장소는 7월 8일에 첫 번째 기록된 Star를 받았습니다. Star #100은 저장소 생성 후 9일 23시간 27분이 지난 7월 15일에 도달했고, Star #130은 12일 12시간 17분이 지난 7월 18일에 도달했습니다. 이 이정표에 도달했을 때, main 브랜치에는 391개의 커밋, 90개의 병합된 풀 리퀘스트 (merged pull requests), 145개의 오픈된 비-PR 이슈 (non-PR issues), 그리고 10개의 GitHub 릴리스 (releases)가 포함되어 있었습니다. 제 로컬 아카이브에는 동일한 시점까지 209개의 GridBash Codex 스레드가 저장되어 있으며, 이 중 86개는 명시적으로 서브에이전트 (subagent) 스레드로 표시되어 있습니다.

프로젝트를 이해하기 쉽고 설치하기 쉽게 만든 후 Star 곡선이 가속화되었습니다. README를 축소하고, Windows 전용 가정을 제거했으며, macOS 및 Linux 패키지를 배포했고, 실제 랜딩 페이지와 제품 영상을 제작했으며, v0.2.0을 통해 이러한 변경 사항들을 이름이 지정된 릴리스로 출시했습니다. GitHub의 집계된 유입 경로(referrers)에는 X와 LinkedIn이 나타나지만, 특정 마법 같은 게시물 하나를 식별할 수 있는 증거는 없습니다. 사실, 공식적인 홍보 계획과 Product Hunt/Hacker News 준비는 가장 많은 Star가 발생한 날들이 이미 지나간 후에 시작되었습니다.

타임스탬프가 찍힌 Star 데이터, 정확한 차트, 릴리스 목록 및 검증 스크립트를 포함하여 launch-history artifact를 조사하거나 다시 실행해 볼 수 있습니다. 여기서 얻을 수 있는 유용한 교훈은 "13일 동안 391개의 커밋을 하라"는 것이 아닙니다. 그것은 제정신이 아닌 행동이니까요. 진짜 교훈은 오픈 소스(Open-source)의 성장이 일상적인 사용, 눈에 보이는 수정(Fixes), 마찰이 적은 패키징(Low-friction packaging), 그리고 해당 제품이 존재한다는 공개적인 증명 사이의 긴밀한 루프(Tight loop)에서 비롯되었다는 점입니다.

A bad MS Paint drawing of six terminal windows feeding a heap of 130 stars.

그림 1. 6개의 터미널이 투입되었고, 130개의 Star와 놀라울 정도의 저장소 관리 업무가 결과로 나왔다. 부연 설명: 졸라맨은 법적으로 여전히 유지 관리자(Maintainer)로 분류됩니다. 출처: GPT Image 2로 생성.

목차

• 첫째, 숫자는 13일입니다
• 원래의 제품 개요는 짜증 섞인 한 단락이었습니다
• 첫 번째 아키텍처(Architecture)는 유용한 방식으로 틀렸습니다
• 터미널이 작동하기도 전에 패키지를 게시했습니다
• 도그푸딩(Dogfooding)이 로드맵보다 더 나은 요구사항을 만들어냈습니다
• 길을 잃은 R이 엔지니어링 프로세스를 설명합니다
• 저장소는 작은 소프트웨어 공장이 되었습니다
• Star 곡선이 꺾이기 전에 일어난 일들
• 아마도 급증의 원인이 아니었을 것들
• Star는 관심이지, 채택(Adoption)이 아닙니다
• 반복 가능한 부분
• 이 사례 연구가 증명하지 못하는 것
• 결론

첫째, 숫자는 13일입니다

"며칠 만에 약 130개의 Star를 얻었습니다"라는 말은 재미있는 문장이지만 나쁜 측정 지표입니다. GitHub 보고에 따르면 GridBash 저장소는 2026-07-05T22:46:52Z에 생성되었습니다. 제가 7월 20일에 타임스탬프가 찍힌 현재 Star를 준 사람(Stargazer) 목록을 수집했을 때, 순서상 130번째 Star는 2026-07-18T11:03:46Z에 기록되었습니다.

그 결과 저장소-마일스톤 간격은 12일 12시간 16분 54초가 됩니다. 인간은 제목을 읽기 때문에 저는 이를 13일이라고 부르지만, 정확한 간격은 여기에 명시하여 누구도 제 느낌(vibes)에 대해 법의학적 산술(forensic arithmetic)을 수행할 필요가 없도록 했습니다.

또 다른 중요한 측정 세부 사항이 있습니다: GitHub는 모든 Star 및 Unstar 이벤트의 불변하는 기록을 제공하는 것이 아니라, 현재 저장소에 Star를 준 사람들에 대한 타임스탬프를 노출합니다. 초기에 Star를 준 사람이 나중에 Unstar를 할 수 있으며, 이는 재구성된 서수 마일스톤(ordinal milestone)을 이동시킬 수 있습니다. 따라서 collector는 7월 20일의 스냅샷을 저장하고, 이 한계점을 명시하며, 라이브 재구성 결과가 아카이브된 결과와 어긋날 경우 검증 단계에서 실패 처리합니다.

확인된 마일스톤은 다음과 같습니다:

이것이 출시를 기록할 때의 첫 번째 규칙입니다: 분자에서 인생의 교훈을 추출하기 전에 분모를 먼저 확정하십시오.

원래 제품 브리프는 짜증 섞인 한 단락이었습니다

첫 번째 GridBash 세션은 시장 지도(market map), 카테고리 테제(category thesis), 또는 우아한 RFC로 시작되지 않았습니다. 그것은 스크린샷과 다음과 같은 요청으로 시작되었습니다:

"Git Bash 터미널 그리드를 즉시 얻을 수 있는 앱 / exe 또는 실행 가능한 무언가를 만들어 줄 수 있나요?"

요구되는 동작은 이미 놀라울 정도로 구체적이었습니다: M x N을 요청하고, 공간을 균등하게 나누며, 모든 터미널을 하나의 애플리케이션에 유지하여 Alt+Tab을 눌렀을 때 한 가지만 보이게 하고, 동적으로 크기를 조정하는 것입니다. 첫 번째 시각적 결과가 도착했을 때, 저의 후속 질문은 훨씬 더 엄격했습니다:

"결국 이렇게 됐네요 ㅋㅋ."

그리고 실제 제품이 나타나기 시작했습니다. 저는 Ctrl+클릭 다중 선택(Ctrl+click multi-selection)을 원했고, 이를 통해 하나의 명령을 선택된 터미널에 브로드캐스트할 수 있기를 바랐습니다. 기존의 에이전트 멀티플렉서(agent multiplexers)보다 더 나은 느낌을 받고 싶었고, 모달 컨트롤(modal controls)은 원하지 않았습니다. 앱 내부에서 활성 셸(active shell)을 변경하고 싶었으며, 다음 세션까지는 별도의 인증 프로필(auth profiles), 프로젝트 디렉토리(project directories), 그리고 다중 에이전트 오케스트레이션(multi-agent orchestration) 기능을 갖추고 싶었습니다.

이러한 순서가 중요한 이유는 GridBash가 결코 진정한 의미의 '여섯 개의 터미널'이 아니었기 때문입니다. 여섯 개의 터미널은 단지 눈에 보이는 증상일 뿐이었습니다. 근본적인 작업은 데스크톱을 카지노 보안 벽처럼 만들지 않으면서, 여러 독립적인 코딩 에이전트 세션을 보이게 하고, 주소 지정 가능하게(addressable), 격리하고(isolated), 이해하기 쉽게 유지하는 것이었습니다.

첫 번째 아키텍처는 유용하지만 잘못되었습니다

첫 번째 구현은 Windows Terminal 외부에서 이를 오케스트레이션하려고 시도했습니다. PowerShell 런처를 사용하면 창을 열고 wt split-pane을 반복적으로 호출할 수 있었습니다. 충분한 포커스 이동과 비율 산술(ratio arithmetic)을 통해 격자처럼 보이게 만들 수는 있었습니다. 이는 프로토타이핑하기는 빨랐지만, 추상화가 제품 자체와 충돌하고 있었습니다.

Windows Terminal은 자체적인 페인 트리(pane tree)와 상호 작용 모델(interaction model)을 소유합니다. 외부 런처가 분할(splits)을 요청할 수는 있지만, 스프레드시트 같은 셀 집합, 부분 선택 상태(subset-selection state), 브로드캐스트 라우팅(broadcast routing), 페인 메타데이터(pane metadata), 에이전트 생명 주기(agent lifecycle), 또는 일관된 다시 그리기 루프(consistent redraw loop)를 자연스럽게 소유하지는 못합니다. 정확한 M x N 기하학도 어색해지는데, 이는 순차적인 분할이 트리(tree)의 현재 포커스된 브랜치에 작동하는 반면, 원하는 인터페이스는 행과 열로 생각하기 때문입니다.

UTC 기준 20:39분, 저는 Codex에게 심각한 에이전트 멀티플렉서들을 살펴보고 GridBash를 '무한히 더 좋게' 만들도록 요청했습니다. 20:46분에는 어려운 방향을 선택했고, 21:31분에는

Cargo.toml에 여전히 남아 있는 초기 스택은 터미널 이벤트와 백엔드를 위해 Crossterm을, 레이아웃과 렌더링(rendering)을 위해 Ratatui를, 자식 의사 터미널(child pseudo-terminals)을 위해 portable-pty를, 그리고 각 자식의 이스케이프 시퀀스(escape sequences)를 화면 상태로 파싱하기 위해 vt100을 사용했습니다. 이것은 올바른 소유권 경계(ownership boundary)였습니다. 이제 GridBash는 어떤 창(pane)이 입력을 받을지, 창의 크기가 어떻게 조정될지, 창 주변에 어떤 메타데이터가 표시될지, 그리고 실제 터미널 프로그램의 출력이 어떻게 화면상의 셀(cells)이 될지를 결정할 수 있게 되었습니다.

첫 번째 Rust 커밋은 구현이 시작된 지 약 12분 후인 UTC 기준 21:43분경에 이루어졌습니다. 그 숫자는 그날 밤의 나머지 시간까지 포함한다면 초인적으로 들리겠지만, 포함하자마자 그렇게 느껴졌습니다.

터미널이 작동하기도 전에 패키지를 배포했습니다

UTC 기준 21:55분까지, 저는 이 프로그램이 자신이 관리하는 에이전트 CLI(Command Line Interface)들처럼 설치되기를 원했습니다. npm을 배포 래퍼(distribution wrapper)로 사용하되, 실제 애플리케이션은 네이티브 Rust 실행 파일로 유지하는 방식이었습니다. gridbash@0.1.0은 UTC 기준 22:17분에 배포되었습니다.

22:20분, 저는 셀들이 실제로 사용 가능한 터미널을 생성하지 못하고 있다고 보고했습니다.

A terrible MS Paint rocket labeled npm 0.1.0 launching while six broken terminal windows dangle below it.

그림 2. 패키지가 화물(cargo)을 터미널 입력에 도달시키기도 전에 탈출 속도(escape velocity)를 달성했습니다. 부제: 유의적 버전 관리(Semantic versioning)는 화면을 직접 확인하는 것을 대신할 수 없습니다. 출처: GPT Image 2로 생성됨.

실패에는 두 가지 유형이 있었습니다. 첫째, npm 런처(launcher)가 모든 프로필을 직접 실행 가능한 네이티브 바이너리(native binary)로 취급하는 대신, .cmd 파일과 같은 Windows 커맨드 심(command shims)을 올바르게 해결(resolve)해야 했습니다. 둘째, 페인(pane)에는 완전한 PTY 루프가 필요했습니다. 즉, 자식 프로세스를 생성(spawn)하고, 출력을 지속적으로 읽으며, VT 파서(parser)를 통해 바이트를 전달하고, 결과 화면을 렌더링(render)하며, 키 입력을 전달하고, 사각형 크기가 변경될 때 에뮬레이션된 화면과 하부 PTY의 크기를 모두 조정해야 했습니다.

GitHub 리포지토리(repository) 자체는 npm 패키지 출시 이후인 UTC 22:46에 생성되었습니다. 이후 또 다른 세션 메시지에서 이 프로젝트의 야망을 "이것을 놀라울 정도로 트렌디한 리포(repo)로 만들자"라고 요약했으나, 곧이어 터미널 출력과 입력이 여전히 일반적인 셸(shell)처럼 작동하지 않는다는 보고들이 뒤따랐습니다.

이러한 순서는 무모했지만, 유용한 압력 구배(pressure gradient)를 만들어냈습니다. 프로젝트는 이미 공개적인 설치 접점(install surface)을 가지고 있었기에, 모든 로컬 버그는 다른 누군가의 첫 실행을 위협하는 요소가 되었습니다. 핵심적인 터미널의 정확성은 무기한의 프라이빗 베타(private-beta) 라벨 뒤에 숨을 수 없었습니다. 여기서 얻을 수 있는 합리적인 교훈은 "고장 난 패키지를 배포하라"가 아닙니다. 구현, 배포 가능한 아티팩트(artifact), 클린 머신 테스트(clean-machine test), 그리고 관찰된 동작 사이의 거리를, 무언가가 작동하는 척하는 것이 어려워질 때까지 단축하라는 것입니다.

로드맵보다 더 나은 요구사항을 만들어낸 도그푸딩(Dogfooding)

GridBash가 실제 PTY를 호스팅할 수 있게 되자, 나는 GridBash를 구축하기 위해 GridBash를 사용하기 시작했습니다. 이는 제품이 유년기의 대부분을 자신의 리포지토리를 편집하는 에이전트(agent)들을 감독하며 보내는 것을 의미했습니다. 이는 위험할 정도로 순환적이지만 매우 효과적입니다.

세션 기록을 보면 제품 요구사항이 실제 마찰(friction)로부터 발생하고 있음을 알 수 있습니다:

• 7월 6일, 셸 프로필 (shell profiles)이 에이전트 프로필 (agent profiles), 인증 선택 (auth selection), 에이전트별 디렉토리 (per-agent directories), 그리고 오케스트레이션 (orchestration)으로 변모했습니다.
• 7월 7일, 병렬 작업 (parallel work)을 통해 창(pane)별 git 워크트리 (git worktrees), 세션 재개 (session resume), 재시작 가능한 창 (restartable panes), 탭 (tabs), 더 명확한 활동 상태 (activity state), 그리고 더 안전한 선택된 창 입력 (selected-pane input)의 필요성이 드러났습니다.
• 7월 10일, 많은 수의 터미널을 실행하면서 다시 그리기 (redraw) 및 입력 지연 (input latency) 문제가 노출되었습니다. 같은 날, "이게 Mac에서도 작동하나요?"라는 질문은 Windows, Linux x64/arm64, 그리고 macOS arm64/x64를 위한 공유 크로스 플랫폼 릴리스 디자인 (cross-platform release design)으로 확장되었습니다.
• 7월 15일, 10~12개의 활성 터미널이 또 다른 고부하 프로파일링 (high-load profiling) 및 스케줄링 (scheduling) 단계를 트리거할 만큼 느려졌습니다. 이어 백그라운드 작업 (background jobs), 지속성 창 (persistent panes), 명령 검색 (command discovery), 그리고 워크스페이스 수준의 요약 (workspace-level summaries) 기능이 추가되었습니다.

이는 빈 기획 문서에서 50개의 기능을 발명해내는 것보다 훨씬 낫습니다. 왜냐하면 모든 요청에는 재현 조건 (reproduction condition)이 포함되어 있기 때문입니다. "20개의 창을 띄우면 입력이 느리게 느껴진다"는 테스트가 가능하지만, "오케스트레이션을 즐겁게 만들어라"는 향초(scented candle, 실체가 없는 모호한 요구사항)에 불과합니다.

위험 요소 또한 명확합니다. 창업자-사용자 (founder-user)는 단 한 명의 창업자-사용자에게 완벽하게 적응된 제품을 만들 수 있으며, 에이전트 속도의 구현 (agent-speed implementation)은 모든 짜증 나는 요소를 영구적인 인터페이스 표면 (interface surface)으로 바꿔버릴 수 있습니다. GridBash는 방대한 기능 세트를 빠르게 축적했기 때문에, 이후의 작업은 온보딩 (onboarding)을 단순화하고, 컨트롤을 커맨드 팔레트 (command palette)로 통합하며, 원시 터미널 그리드 (raw terminal grids)를 보조 모드로 재배치하고, 어떤 기능이 안정적인지를 정확히 명시해야 했습니다.

엉뚱한 R 문자가 설명하는 엔지니어링 프로세스

제가 가장 좋아했던 초기 버그는 새로운 터미널이 요청하지도 않았는데 대문자 R을 입력하는 것이었습니다. 이는 애플리케이션이 독자적인 의견을 갖게 된 것이 아니라, 터미널 쿼리 처리 (terminal query handling) 과정에서 발생한 문제였습니다.