Claude Code를 처음 켜고 두 명령어를 입력했을 뿐인데 컨텍스트 창이 이미 3분의 1이 찼다. pnpm install 출력 전체, git log 200커밋, 스택 트레이스까지—정작 내가 요청한 작업은 아직 한 줄도 안 썼는데. 에이전트를 실무에 붙여본 개발자라면 누구나 겪는 순간이다. 그런데 이 불편함은 단순히 '컨텍스트 창이 작아서'가 아니다. 비용, 지속성, 품질—이 세 가지 마찰이 동시에 쌓이는 구조적 문제다. 최근 등장한 세 가지 도구는 각각 이 마찰의 서로 다른 지점을 겨냥한다.
마찰 1. 토큰이 너무 빨리 닳는다
dev.to의 기고(Save 60-90% of Your Claude Code Tokens With Two Tools)는 컨텍스트 창을 '책상'에 비유한다. 책상 위에 올라간 것은 매 턴마다 다시 읽힌다. 문제는 정작 중요한 추론이 아니라 의존성 설치 로그, 긴 git 히스토리, 장황한 테스트 결과 같은 '지루한 출력'이 공간을 먼저 점령한다는 것이다.
여기 두 가지 레이어 해법이 있다. RTK는 셸 프록시로, Claude가 실행하는 모든 Bash 명령의 출력을 컨텍스트에 도달하기 전에 압축한다. git status가 내부적으로 rtk git status로 바뀌지만 사용 방식은 동일하다. 실제 사용 데이터에서는 1,539개 명령 실행 후 입력 토큰 130만 개 중 80%인 100만 개를 절감했다. rtk gain 명령으로 내 실제 절감률을 직접 확인할 수 있다는 점이 신뢰를 준다—광고성 수치가 아니라 검증 가능한 숫자다.
context-mode는 다른 방향에서 접근한다. MCP 서버 플러그인으로, 10,000줄짜리 로그나 거대한 JSON 같은 무거운 작업을 샌드박스에서 처리하고 결과값만 돌려준다. 원본 데이터가 컨텍스트 창에 아예 올라오지 않는다. "에러 몇 개야?"라고 물으면 "47개, 분류는 이렇습니다"만 돌아온다. 두 도구를 함께 쓰면 서로 다른 레이어에서 토큰 낭비를 동시에 잡는다.
마찰 2. 맥북을 닫으면 에이전트가 멈춘다
'AI 코딩 열풍에 노트북을 닫지 못한 채 이동하는 개발자들'—이 밈이 등장할 만큼 현실적인 문제가 됐다. 에이전트에게 작업을 맡기고 자리를 뜨려 맥북을 닫는 순간, 클램쉘 모드로 잠들어 작업이 끊긴다. caffeinate를 걸어도 외장 모니터 없이 덮개를 닫으면 막을 수 없다.
Electronic Clam(GitHub)은 이 문제를 직접 겨냥해 만든 macOS 메뉴바 앱이다. Swift + AppKit으로 구현되었고, IOKit SPI를 통해 시스템 전원 설정을 직접 제어한다. 단순히 '절전 방지'에 그치지 않고 몇 가지 설계 결정이 눈에 띈다.
첫째, 작업을 감지한다. 에이전트 프로세스가 살아있는지가 아니라 실제로 작업 중인지를 판단한다—transcript 파일의 수정 시각만 읽는다(내용은 읽지 않는다). 작업이 끝나면 자동으로 유휴 상태로 전환해 불필요한 발열과 방전을 막는다. 둘째, 온도와 배터리를 함께 본다. 가방 안에서 과열되거나 방전되는 상황을 막기 위해 설정값을 넘으면 작업을 잠시 쉬게 한다. 셋째, Claude Code·Cursor·Codex 등 주요 에이전트 5종을 기본 인식하며, glob 패턴으로 커스텀 추가도 가능하다. 원격 접속(SSH, Tailscale) 중에는 별도로 깨어있는 상태를 유지한다.
마찰 3. AI에게 넘기기 전 기획이 부실하다
토큰을 아끼고, 세션을 끊기지 않게 유지하는 것만으로 충분할까? 사실 더 앞선 단계에 마찰이 있다. "AI가 틀렸다기보다, 내가 건넨 입력에 빈칸이 많았다"—velog 기고(AI에게 코딩을 맡기기 전에, 기획의 빈칸부터 구조화해 봤다)의 핵심 진단이다.
orot은 아이디어 → 문제·고객 → 핵심 가치·요구사항 → 기능·동작 규칙 → 화면·컴포넌트 → 기획서·AI 패킷으로 이어지는 연결 구조를 그래프로 관리한다. REQ1이 FEAT1을 실현하고, FEAT1이 CMP1으로 구현되며, CMP1이 SCR1에 속한다는 식의 관계가 데이터로 보존된다. 요구사항을 수정하면 기능 정의서와 화면 설계서가 같은 원본을 기준으로 자동 재생성된다.
주목할 설계 원칙은 AI가 기획의 정본을 소유하지 않는다는 것이다. 프로젝트 데이터를 orot/packet@1 형식의 JSON으로 직렬화해 ChatGPT·Claude·Gemini 중 원하는 AI에 보내고, 응답은 즉시 반영하는 것이 아니라 '추가·교체 제안'으로 검토 후 수락한다. AI를 기획의 자동화 도구가 아니라 빈칸을 채우는 협력자로 위치시키는 구조다.
세 마찰이 가리키는 하나의 패턴
세 도구가 해결하는 문제는 표면적으로 다르지만 같은 구조적 질문을 공유한다—에이전트와 긴 시간 함께 일하려면 무엇을 설계해야 하는가?
RTK와 context-mode는 컨텍스트 창의 경제학을 다룬다. 에이전트가 매 턴마다 읽는 정보의 밀도를 높이는 것이 곧 비용과 성능을 동시에 개선하는 길이다. Electronic Clam은 물리적 지속성 문제를 다룬다. 에이전트에게 장시간 작업을 위임하는 것이 일상이 되면서, 세션이 끊기지 않는 환경을 만드는 것 자체가 인프라가 됐다. orot은 입력 품질 문제를 다룬다. 빠른 프로토타이핑이 가능해질수록 '무엇을 만들 것인가'의 구조가 더 중요해진다—모호한 입력은 빠른 속도로 잘못된 방향을 향한다.
워크플로우에 실제로 붙이려면
세 도구 모두 설치와 진입 장벽이 낮게 설계됐다는 점은 긍정적이다. RTK는 바이너리 설치 후 rtk init -g 한 줄로 기존 워크플로우에 투명하게 올라탄다. context-mode는 플러그인 두 줄이면 된다. Electronic Clam은 토글 하나로 작동하며 터미널 명령도, 재인증도 필요 없다. orot은 오픈 베타로 로그인 없이도 예시 프로젝트로 흐름을 먼저 확인할 수 있다.
실무 적용 순서를 제안하자면: 먼저 orot으로 기획 구조를 잡고 AI 패킷을 만든다. 그 패킷을 Claude Code에 넘기기 전에 RTK와 context-mode를 세팅해 컨텍스트 창 낭비를 줄인다. 장시간 작업이 필요하다면 Electronic Clam을 켜고 맥북을 닫는다. 이 흐름이 바로 '빠른 프로토타이핑 → 검증 → 고도화'의 각 단계에 에이전트를 실제로 통합하는 구체적인 경로다.
전망: 에이전트 지속성이 새로운 인프라가 된다
이 도구들이 등장했다는 것 자체가 시장 신호다. Claude Code를 단발성 질문 도구가 아니라 장시간 협력하는 에이전트로 쓰는 개발자가 충분히 많아졌고, 그 과정의 마찰이 충분히 뚜렷해졌다는 뜻이다. 앞으로는 '어떤 AI 모델을 쓸 것인가'보다 '에이전트가 얼마나 오래, 얼마나 효율적으로, 얼마나 올바른 방향으로 작동하게 할 것인가'의 설계가 개발자 역량의 변별점이 될 것이다. 토큰 최적화, 세션 지속성, 기획 구조화—이 세 가지는 그 설계의 가장 실용적인 출발점이다.