만약 터미널에서 Claude Code나 Codex를 사용해 보셨다면 이 상황을 아실 겁니다.
작업을 시작합니다. AI가 답변하는 데 시간이 걸리므로, 다른 작업을 하나 더 시작합니다. 그러자 첫 번째 작업의 답변이 오지만, 그 답변은 한 가지 명확화(clarification), 하나의 후속 조치(follow up), 그리고 하나의 부차적 작업(side task)이 필요하며, 각각이 별도의 탭을 요구합니다. 이어서 두 번째 탭의 답변이 들어옵니다. 당신은 여러 작업을 오가며 정신없이 처리하게 됩니다. 그러다 문득 자신도 모르게 20개의 스레드 사이를 뛰어다니며 그 모든 컨텍스트를 머릿속 RAM에 담으려고 애쓰고 있다는 것을 깨닫습니다.
결국 더 이상 할 수 없게 됩니다. 당신의 두뇌는 지치고, 집중력이 무너져 내리며, 자신이 무엇을 하고 있었는지, 어디서 시작했는지, 그리고 어디에서 끝내야 하는지조차 알 수 없게 됩니다.
많은 사람들이 휴식을 취하거나, 타이핑하기 전에 생각하고, 범위를 제한하는 방법을 제안합니다. 저는 저만의 실험을 했습니다.
저는 이러한 작업 방식에 두 가지 주요 문제점, 즉 시퀀싱(sequencing)과 컨텍스트(context)가 있다고 판단했습니다. 그래서 제 작업을 우선순위 큐(priority queue)와 비슷하게 정리했습니다.
실제 작동 방식은 이렇습니다.
이 큐는 Git에 존재합니다. 모든 티켓은 리포지토리 내의 마크다운 파일이며, 관련된 코드 바로 옆에 위치하고, 보드의 상태는 커밋된 스냅샷입니다. 중요한 것은 채팅 창이나 제 머릿속 어디에도 남겨두지 않습니다. 세션이 끊어져도 큐는 여전히 남아 있습니다.
한 에이전트(agent)가 이 보드를 주기적으로 작업합니다. 새로운 티켓을 조사하고, 사람이 안전하다고 태그한 티켓들을 빌드하며, 테스트와 브라우저 검사를 실행하고, 이미 배포된 것을 확인합니다. 민감한 코드를 건드리는 모든 것에 대해서는 별도의 브랜치에서 빌드하고 먼저 질문합니다. 프로덕션 환경에 배포하는 것은 절대 하지 않습니다. 그 부분은 제가 담당합니다.
이 시스템이 할 수 없는 것이 바로 '결정'입니다. 그래서 저에게 필요한 모든 것은 '나의 오너 인박스(owner inbox)'라고 부르는 한 곳으로 모입니다. 스크립트가 전체 보드를 읽어 들여, 제 판단을 기다리는 항목들—이 변경 사항 검토하기, 이 질문에 답하기, 이 트레이드오프(tradeoff) 결정하기—의 우선순위 목록을 저에게 전달해 줍니다.
이 읽기 표면은 Claude의 산출물입니다. 매 사이클마다 git으로 재구축되는 단일 페이지로, 전체 보드와 티켓당 검토 페이지를 반영합니다. 따라서 저는 터미널을 스크롤하며 변경 사항이 무엇을 하는지 재구성하려고 애쓰지 않습니다. 하나의 링크를 열고, 무엇이 구축되었는지 그리고 그 이유를 읽은 다음, 저의 판결(verdict)을 내립니다. 이 판결은 다시 git에, 카드 위에 기록됩니다. 이 페이지는 단지 뷰어일 뿐이며—기록은 git입니다.
그리고 가장 중요한 부분이 나옵니다.
저는 하나의 항목을 가져옵니다. 그 컨텍스트(context)를 로드합니다. 결정을 내리거나 조치를 요청합니다. 그리고 그것을 큐(queue)에 다시 넣음으로써 종료합니다.
그 '종료'가 핵심 트릭입니다. 티켓이 기억해야 할 대상으로 제 기억 속에 계속 매달려 있지 않습니다. 컨텍스트도 함께 종료됩니다. 그래서 큐에서 다음 항목을 선택할 때, 저는 실제로 집중할 수 있습니다. 한 번에 하나의 일만요.
여전히 지치기는 합니다. 하지만 산만하거나 길을 잃었다는 느낌은 들지 않습니다.
어려움은, 그리고 여전히 어려운 것은, 주변의 툴링(tooling)입니다. 컨텍스트를 소화하기 쉬운 방식으로 제공받는 것이 중요합니다. 그래서 티켓을 로드하는 데 20분이 아닌 1분밖에 걸리지 않게 해야 합니다. 또한 오직 제가 내릴 수 있는 판결을 기다리며 막혀서 끝없는 루프(endless loops)에 빠지는 것을 방지해야 합니다.
이것은 살아있는 유기체와 같아서 저는 계속 개선하고 있습니다. 하지만 AI 도구를 사용한 저의 생산성 측면에서 엄청난 진전처럼 느껴졌기 때문에 공유할 가치가 있다고 생각했습니다.