클로드 코드 데스크톱 리디자인 + Agent View, 안드로이드 PR 5개 동시에 굴려본 한 주

 

PR 전환에 평균 8초 걸리던 게 2초로 줄었습니다. 그런데 한 주 토큰 사용량은 2.3배 늘었더라구요. 새 데스크톱 앱으로 갈아탄 첫 주 성적표예요.

클로드 코드 데스크톱 리디자인, 무엇이 달라졌나

지난 4월에 풀린 클로드 코드(Claude Code) 데스크톱 앱 리디자인부터 짚어볼게요. 가장 크게 와닿은 건 세션 사이드바입니다. 프로젝트별 그룹화와 자동 아카이브가 들어가서, 제 경험상 PR 5개를 띄워놓고도 어느 게 어디인지 헷갈릴 일이 줄어들었어요. 저는 브랜치 이름이 라벨처럼 붙는 느낌으로 쓰고 있습니다.

 

격자 워크스페이스도 진짜 마음에 들어요. 터미널, diff, 프리뷰, 채팅창을 드래그 앤 드롭으로 배치할 수 있는데, 안드로이드 리소스 XML diff 와 코틀린(Kotlin) 파일을 옆에 띄워두고 작업하면 Cmd+Tab 누르는 횟수가 절반 이하로 줄더라구요.

 

인앱 터미널과 파일 에디터도 같이 들어왔습니다. lint 경고 한두 개 고치는 정도는 앱 안에서 끝납니다. 다만 제 환경에선 5분 넘어가는 그래들(Gradle) 빌드는 스크롤백 버퍼가 끊겨서 바깥 IDE 로 돌리는 편이 낫더라구요.

 

원격 빌드 머신에 SSH 로 붙는 기능도 들어왔는데, 무거운 빌드를 원격에서 돌리니까 노트북 배터리 소모가 체감상 30% 가까이 줄어드는 경우가 생깁니다.

 

 

Agent View 가 바꾼 '주의 큐' 관리 방식

5월에 풀린 리서치 프리뷰가 Agent View 예요. claude agents 로 띄우는 대시보드인데, 여러 세션 중 어느 PR 이 지금 내 입력을 기다리는지 한 화면에 모아줍니다. HITL(Human-in-the-Loop) 지점만 골라서 보여주는 셈이지요.

 

기능 자체는 단순해 보여도, 멀티 세션을 굴리다 보면 이게 진짜 효자입니다. 저 같은 경우엔 PR 한 개당 평균 15초씩 절약되는 느낌이에요. 다음과 같은 가벼운 컨펌은 인라인 응답으로 그 자리에서 처리하니까 세션 사이를 왔다 갔다 할 일이 줄어들었습니다.

yes, proceed

 

/goal 과 /bg 명령어가 같이 들어왔어요. /goal 은 완료 조건을 정의해두면 클로드가 자율적으로 작업을 끌고 가는 명령이고, /bg 는 현재 세션을 백그라운드로 내리는 명령입니다. 둘을 묶으면 "모든 모듈 빌드 통과" 같은 목표를 던져놓고 다른 PR 로 넘어갈 수 있게 되었네요.

 

 

git worktree 로 굴리는 안드로이드 PR 멀티 세션

한 주 동안 안드 PR 5개를 동시에 굴려보면서 깨달은 게 있어요. git worktree 없이 멀티 세션은 자해 행위입니다.

 

같은 디렉터리에서 브랜치만 바꿔가며 세션을 띄우면 그래들 캐시가 충돌해서 빌드가 산발적으로 깨집니다. worktree 로 디렉터리를 분리하면 각 세션이 독립된 빌드 환경을 가지니까 이 문제가 사라집니다.

 

PR 생성도 한결 매끄러워졌어요. 다음 명령을 세션 안에서 돌리면 현재 세션이 PR 에 자동으로 링크됩니다.

gh pr create

 

다음 날 출근해서 아래 한 줄만 치면 어제 작업하던 diff 위에서 그대로 이어집니다.

claude --from-pr 1247

 

체감상 절대 시간은 한 PR 만 잡고 있을 때보다 25% 정도 줄어들었어요. 한 PR 의 CI 가 6분 도는 동안 다른 PR 의 리뷰 코멘트를 반영하는 식으로 유휴 시간이 사라졌습니다.

 

모바일 원격 제어와 /goal 토큰 폭증 문제

데스크톱 세션에 원격으로 붙는 Remote Control 기능도 써봤습니다. 출근길에 카카오톡 알림으로 CI 실패가 떠도 다음 한 줄만 모바일로 던지면 데스크톱 세션이 알아서 처리해줍니다.

fix the lint warnings

 

근데 여기서 첫 문장으로 돌아갑니다. 토큰 사용량 2.3배 증가. 백그라운드 세션과 /goal 루프가 제가 안 보는 사이에 토큰을 야금야금 갉아먹습니다. 사용량 제한에 더 빨리 도달한다는 The New Stack 보도도 있었는데, 한 주 굴려본 입장에서 빈말이 아니더라구요.

 

해법은 /goal 의 종료 조건을 좁고 명확하게 잡고, Task Budgets 로 상한을 거는 것입니다. "빌드 통과" 같은 막연한 목표 말고, "app 모듈 unit test 통과 + lint 0 경고" 식으로 구체화해야 무한 루프를 막을 수 있어요.

 

멀티 세션 권장 여부, 켜는 자리와 끄는 자리

한 주 굴려보고 내린 결론은 이렇습니다.

1. PR 3개 이상 + 각 PR 의 빌드/CI 대기시간이 5분 넘는 워크플로 → 켜세요.
2. 한 PR 을 깊이 파고들어 디버깅하는 시간 → 끄세요. 단일 세션이 낫습니다.
3. View 모드는 평소엔 Normal, 디버깅할 때만 Verbose 로 전환하시는 게 인지 부하 관리에 도움이 됩니다.

개인적으로는 디버깅 모드일 때 다른 세션을 일부러 종료시키고 있어요. 멀티 세션이 쉬워졌다고 무조건 많이 띄우면 '주의 큐 관리' 자체가 새 업무가 되거든요.

 

 

마치며

다음 주 월요일 아침, Agent View 를 띄웠을 때 PR 4개 중 빨간 점이 깜빡이는 건 1개뿐이고 나머지 3개는 머지 대기 상태로 조용히 줄 서 있는 풍경 — 그 풍경을 한 번 본 이상 단일 세션으로 돌아가긴 어려울 것 같아요. 다만 사이드바 한쪽에 떠 있는 토큰 미터 숫자는 첫 주 내내 머릿속을 따라다녔습니다. 매끄러워진 만큼 그 매끄러움의 비용도 같이 카운트되고 있었다는 얘기지요.