요즘 저는 하루 내내 Claude Code와 같이 일합니다. 덕분에 이전이면 절대 하기 어려웠던 일을 해보고 있는데요, 그대신 묘하게 붕떠 있다는 느낌을 많이 받습니다. 그 느낌이 어디서 올까 찾다 보니, 프롬프트를 던지고 나서 답을 받기까지 2~10분이 그 감각을 주었다고 생각하게 되었습니다. 2~10분. 기다리기엔 길지만, 그렇다고 새 일을 열기엔 짧은 시간입니다. 메일을 열었다가 닫고 탭을 몇 개 넘기다 보면 어느새 결과가 나와 있죠. 문제는 그 애매한 시간 사이에 남는 게 별로 없다는 겁니다.

이런 상태, 작은 전환이 계속 쌓여 뇌가 지치는 현상을 부르는 신조어도 생겼습니다. 하버드 비즈니슈 리뷰(HBR)는 이를 Brain Fry라고 부릅니다. 이 현상이 생기는 이유는 화면을 옮기고, 맥락을 다시 잡고, 다시 돌아오는 데 드는 전환 비용이 생각보다 크기 때문입니다. 집중력은 깨지는데 성취감은 없으니 더 피곤해집니다.

해결책을 찾아보기로 했고, 찾아낸 방법은 거창한 생산성 설계와 무지막지한 전환이 아니었습니다. 이 애매한 시간을 무작정 그때그때 잘 써보자 하지 말고, 적당한 메뉴판으로 만들어 두기로 한 겁니다. 그래서 이 시간을 4개의 행동 카테고리로 나눠 미리 준비해 보기로 했습니다. 생각 확장, 지식 수집·소통, 보여주기, 회복. 딱 이 네 가지입니다.

에이전트 대기 시간은 왜 그렇게 애매할까?

Claude Code에 프롬프트를 던지고 기다리는 그 시간이 더 지치는 이유가 있습니다. 이 시간이 ‘짧아서’가 아니라 다시 몰입하는 비용이 생각보다 크기 때문입니다. 물론 짧을수록 특히 더 그렇습니다. 때로는 화면을 잠깐 닫았다가 다시 열고, 지금 어디까지 했는지 파악하고, 다시 집중 모드로 들어가는 워밍업이 2분보다 더 걸립니다. 2분짜리 쉬는 시간이 아니라 2분짜리 “열기 버튼”이 계속 눌리는 느낌입니다. 그래서 이 시간을 뭔가로 꽉 채우려 하면 남는 건 결과보다 피로입니다.

10분은 또 다르게 애매합니다. 막상 새 태스크에 발을 담그면, 중간에 끊기가 싫어집니다. “아, 이제 감 잡았는데” 싶은 순간이 오거든요. 그런데 에이전트가 돌아오면 다시 원래 일로 복귀해야 하고, 새 태스크는 미완성 스트레스로 남습니다.

Brain Fry의 메커니즘

이를 지칭하는 용어인 Brain Fry를 이해하려면 우리 뇌를 브라우저 탭으로 비유하면 이해가 쉽습니다. 탭 하나 여는 건 쉽지만, 탭을 열고 닫을 때마다 우리는 “어디까지 봤지?”를 다시 찾는 비용이 들죠. 이 비용이 쌓이면, 컴퓨터가 점점 렉 걸리듯 머리도 느려집니다.

대기 시간마다 탭을 무작위로 바꾸는 습관을 들이면 문제가 생깁니다. 2분마다 뉴스 탭, 메신저 탭, 문서 탭을 왔다 갔다 하면 뇌는 계속 새로고침을 합니다. 그러다 보면 어느 순간 RAM이 터지는 느낌이 납니다. 집중은 깨지는데 성취감은 없어 더 피곤해지는 겁니다. 그게 바로 Brain Fry입니다.

자투리 시간 운영 원칙

그래서 짧은 시간에 큰 성과를 내는 법은 일부러 배제했습니다. 대신 전환 비용이 낮은 행동만 하자는 쪽입니다. 시작과 종료가 가볍고, 다시 돌아올 때 흔적이 남는 일들입니다. 대기 시간은 미니 프로젝트가 아니라 미니 동작으로 다뤄야 합니다.

또 하나의 원칙으로, 모든 일을 한쪽으로만 채우지 않았습니다. 결과물이 남는 것도 필요하지만 회복이 되는 것도 중요합니다. 생산성 나는 기록만 하다 보면 지치고, 쉬기만 하면 불안해지니까요. 둘을 같이 준비해두면 그날 컨디션에 맞춰 고르기 쉬워집니다.

마지막으로, 에이전트 주기에 맞춰 행동을 쪼갭니다. 타이머를 맞추란 말이 아니라 적당히 하고 돌아올 때 미련 없는 단위로 하는 겁니다. 이런 원칙으로 메뉴판을 만들어야 애매한 남는 시간이 덜 애매해집니다.

메뉴판 1. 코드는 맡겼으니, ‘코드 너머’를 스케치하기

코드를 에이전트에게 맡기고 많은 사람이 다시 코드로 돌아가려 합니다. 하지만 지금은 오히려 코드 너머를 보기 좋은 타이밍입니다. 이 구간의 활용법을 딱 하나로 줄이면 구조를 스케치하기입니다.

왜 지금이 ‘구조를 보는 타이밍’인가

에이전트는 개별 단위 최적화에 강합니다. 쉽게 말해 함수 하나를 더 깔끔하게, 에러 하나를 더 확실하게 같은 작업을 잘합니다. 여기에 코드 작성 자체는 속도도 빠르고 집중도도 흔들리지 않습니다. 사람이 옆에서 끼어들면 오히려 흐름이 깨질 때가 많습니다.

반대로 인간은 보다 넓은 단위 최적화에 강합니다. 전체 구조가 어떤 모양이어야 하는지, 데이터가 어디서 어디로 흘러야 하는지, 제품 의도가 무엇인지 같은 큰 그림을 잘 그린다는 겁니다. 그러니까 부품을 잘 깎는 것보다 어떤 제품을 만들지 정하는 것에 더 강합니다. 한편 이건 키보드를 두드리는 시간보다 잠깐 멈춰서 보는 시간이 필요합니다.

그래서 에이전트를 돌리는대기 시간은 둘의 역할이 충돌하지 않는 구간입니다. 에이전트가 코드를 짜는 동안, 내가 코드에 손대지 않으면 됩니다. 대신 나는 구조를 그리거나 다음 질문을 준비하면 됩니다. 둘이 같은 레일에서 달리지 않으니 서로 발을 걸 일이 없습니다.

2분짜리 산출물은 조감도 1장

여기서 목표는 거창한 아키텍처 문서가 아닙니다. 박스 5개 이내로 끝내는 조감도 1장입니다. 박스는 보통 컴포넌트(화면, API, DB 같은 덩어리)로 잡습니다. 그리고 화살표로 데이터 흐름을 그립니다. 마지막으로 이 박스는 저 박스에 의존한다 같은 의존성만 표시합니다.

조감도 옆에는 질문 정도만 적어봐도 충분합니다. 예를 들면 로그인은 어디서 검증하지?, 에러는 사용자에게 어떻게 보여주지?, 캐시는 어디에 둘까? 같은 질문입니다. 이 3개가 다음 프롬프트의 재료가 됩니다.

꼭 개발이 아니어도 됩니다. 화이트보드에 설계를 펼쳐놓는다는 개념이 중요합니다. 비개발자라면 무엇을 시킬지 자기 일의 흐름을 그려볼 수 있겠죠.

화이트보드 Excalidraw와 협업 캔버스 Miro

Excalidraw는 손그림 감성의 화이트보드입니다. 중요한 포인트는 예쁘게 그려야 한다는 압박이 없다는 겁니다. 선이 삐뚤어도 자연스럽고, 대충 그려도 어색하지 않습니다.

이 프로덕트를 쓰는 진짜 목적은 도구 목적 그 자체가 아닙니다. 아키텍처 스케치를 2분에 끝내는 의식을 만드는 겁니다. 에이전트를 돌리면 자동으로 캔버스를 열고 박스 3~5개를 그려봅니다. 그리고 질문 3개를 적고 닫습니다. 이 리듬이 생기면 남는 시간이 덜 새어 나갑니다.

MCP 서버로 AI가 스케치를 자동 생성하는 방향이 가능한 것이 가장 큰 장점입니다. 내가 그릴 초안을 AI가 먼저 만들어주는 방식입니다. 요즘은 이런 거 없으면 쓰기 싫으니까요. 스케치 자체에 드는 시간을 더 줄이는 선택지입니다. 다만 핵심은 자동화가 아니라 내가 구조를 보는 습관을 놓치지 않는 것입니다.

비슷하지만, 좀 더 유명한 Miro는 팀 협업형 무한 캔버스에 가깝습니다. 개인 스케치보다 팀이 같이 보는 판이 필요할 때 좋습니다. 특히 스티커 노트로 다음 태스크를 던져두기 좋습니다. 에이전트가 끝났을 때, 할 일이 이미 캔버스에 줄 서 있게 만드는 도구라고도 볼 수 있습니다.

완성보다는 작은 보완

이 방식의 장점은 전환 비용이 줄어든다는 점입니다. 에이전트 종료 시점에 이제 뭐 하지?를 고민하지 않아도 됩니다. 다음 행동이 이미 준비돼 있으니 맥이 끊기지 않습니다. 짧은 대기 시간에서 가장 아까운 건 작업을 멈추는 것이 아니라 ‘다음 행동을 정하는 시간’이니까요.

그러니까 완성 대신 다음 프롬프트를 더 똑똑하게 만드는 재료를 생산하는 시간으로 봅시다. 조감도 1장과 질문 3개면 충분합니다.

메뉴판 2. 멍청하게 스크롤하지 말고 제대로 지식 쌓기

이때 흔히들 글을 읽거나 지식을 채우고는 합니다. 다만, 이 자투리 시간에 제대로 읽으려는 시도는 거의 실패합니다. 막 집중하려 해도 Claude Code가 일을 끝내면 다시 맥이 끊기기 때문입니다. 그래서 이 구간의 목표는 학습이 아니라 큐레이션(나중에 읽을 거리 정리)입니다.

재밌는 글을 북마크하고, 왜 저장했는지 한 줄 메모를 남기고, 나중에 찾기 쉽게 태그를 붙입니다. 이렇게만 해도 다음에 긴 시간을 잡았을 때, 뭘 읽지? 헤매지 않습니다.

적합한 지식 쌓는 사이트 3가지

습관을 바꾸는 가장 쉬운 방법은 들어가는 문을 바꾸는 겁니다. 트위터를 끊겠다고 결심하는 것보다, 새 탭을 열었을 때 보이는 화면을 바꾸는 편이 훨씬 쉽습니다. 아래 도구들은 그 진입점을 기술 지식 쪽으로 살짝 옮겨줍니다. 중요한 건 많이 읽는 게 아니라 좋은 글을 다음으로 넘기는 시스템을 만드는 겁니다.

daily.dev: 크롬 새 탭을 기술 뉴스 피드로 고정합니다. 그러면 무의식적으로 열던 새 탭이 곧바로 학습의 입구가 됩니다. 글은 하나만 읽고, 재밌으면 북마크만 남깁니다.

Hacker News: 여기서 얻는 건 도구 목록이 아니라 반복되는 “문제-해결” 패턴입니다. 포인트는 기사보다 댓글이 본체라는 점입니다. 실무자들이 어디서 막혔는지, 어떤 대안이 있는지가 댓글에 나옵니다.

요즘IT: 한국어 실무 콘텐츠를 빠르게 읽을 수 있습니다. 짧은 대기 시간엔 읽기 속도와 피로도가 특히 중요합니다. 영어 장문 아티클은 내용이 좋아도 진입 비용이 크니까요. (우리 사이트라서가 아니라요) 실제 북마크에 최적화된 컬렉션이나 형광펜 기능이 좋습니다.

읽었다고 알게 되었다 생각하지 말기

대기 시간의 정보 소비를 기분 전환으로 쓸 때는 남는 게 없습니다. 반대로 미래의 나를 위한 자료 정리일 때만 이득이 됩니다. 즉, 지금의 3분이 나중의 30분을 아껴주는 구조여야 합니다. 그게 남는 시간의 활용법에서 가장 중요한 기준입니다.

그래서 읽고 끝내지 말고 짧은 코멘트나 질문을 하나 남겨두는 걸 추천합니다. 예를 들어 “이건 우리 서비스의 로그인에도 적용될까?” 같은 한 줄이면 됩니다. 이 한 줄이 나중에 나를 돕는 검색 키워드가 됩니다. 대신 논쟁이나 긴 스레드는 금지입니다. 거기에 빠지는 순간 전환 비용이 폭발해서 원래 하려던 일을 놓치기 쉽습니다.

메뉴판 3. ‘완성된 코드’를 다른 사람도 알아보게 번역하기

코드가 완성되는 것과 그 가치가 전달되는 건 다른 문제입니다. Claude Code가 코드를 빨리 만들수록 팀의 병목은 자연스럽게 리뷰와 이해, 합의로 옮겨갑니다. 그러니 남는 시간의 활용법은 키보드가 아니라 맥락을 향해야 합니다. 생산성의 다음 레벨은 코드 작성이 아니라 왜 이렇게 만들었는지를 남이 알아보게 번역하는 일입니다.

에이전트가 만든 코드는 속도가 빠른 대신, 읽는 사람이 따라잡기 어렵습니다. 리뷰어는 로컬에서 돌려보고, 화면을 캡처하고 의도를 추측해야 합니다. 이 과정이 길어지면 결국 아무리 좋은 코드도 머지까지 오래 걸립니다. 쉽게 말해, 이제는 코드보다 제대로 설명할 수 있는 결과물이 더 희소해졌습니다.

리뷰와 공유를 빠르게 만드는 도구들

맥락을 설명하는 가장 좋은 방법 중 하나는 보여주는 겁니다. 요즘 가장 강력한 보여주기 방식은 영상이고요. mac 전용인 Screen Studio는 화면 녹화를 꽤나 그럴듯하게 만들어주는 도구입니다. 자동 줌인과 모션 블러 덕분에 편집을 거의 안 해도 데모 영상 퀄리티가 올라갑니다. PR에 30초 데모를 달아두면 리뷰어는 코드를 직접 안 돌려봐도 됩니다. 그 한 번의 절약이 리뷰 속도를 눈에 띄게 끌어올립니다.

영상은 허들이 있긴 하죠. 그러면 떠오르는 것, PPT입니다. Gamma는 발표 자료가 빈 문서로 시작하는 공포를 없애줍니다. 프롬프트 한 줄로 발표 자료 초안을 만들어 시작 시간을 확 줄여주거든요. 스프린트 리뷰나 공유 세션은 자료를 미루는 순간 망하기 쉽습니다. 남는 시간 10분에 초안을 뽑아두면 발표는 절반이 끝난 셈입니다.

마지막은 도구가 아니라 습관입니다. PPT든 영상이든 그 근본이 되는 문서가 있습니다. README죠. 그래서 그냥 README 한 줄 다듬기를 해도 됩니다. 2분이면 끝나는 일이지만 미루면 이상하게 영원히 안 하게 됩니다. 이 PR이 해결하는 문제 1줄 + 사용법 1줄만 추가해도 전달력이 달라집니다.

가볍게, 하지만 반복하기 좋게

그래서 설득할 만한 맥락과 결과를 남기는 걸 습관으로 만드는 게 최고입니다.

가장 쉬운 건 PR 템플릿에 변경 전/후를 한 줄로 적는 겁니다. 리뷰어는 코드를 보기 전에, 무엇이 달라졌는지부터 알고 싶어합니다. 한 줄만 있어도 리뷰의 방향이 잡힙니다. 합의가 필요한 지점도 더 빨리 드러납니다. 스크린샷 1장 + 캡션 1줄도 좋습니다. 말로 설명하면 길어지는 걸, 이미지가 한 번에 끝냅니다. 캡션은 거창할 필요가 없습니다. “이 버튼을 누르면 토스트가 뜹니다” 정도면 충분합니다. 마지막은 테스트 방법을 적는 겁니다. 예를 들어 “A 화면에서 B를 누른다 → C가 보인다”처럼요. 이 두 줄이 있으면 리뷰어는 재현에 시간을 쓰지 않습니다.

메뉴판 4. 에이전트는 안 쉬니까, 내가 쉬기

에이전트가 일하는 동안 꼭 일해야 할 필요도 없습니다. 맡겼으니 쉬세요.

그 대신 쉬는 것도 설계도가 있으면 훨씬 좋습니다. 그래야 다시 돌아오기가 쉽거든요. “언제 끝나지?”가 없는 휴식은 오히려 불안을 줍니다. 그래서 원칙은 하나입니다. 끝나는 조건이 있는 휴식만 고릅니다.

괜찮은 휴식 방법 찾아보기

2~3분: 스트레칭

짧을수록 몸을 먼저 리셋하는 게 이득입니다. 스트레칭을 에이전트 주기에 맞추면 좋겠죠. 눈과 목, 어깨를 한 번씩 초기화하는 시간입니다. 화면을 오래 보는 날일수록 효과가 큽니다.

5분: 커피 내리기

커피는 왜인지 일하는 사람의 양식 같은 느낌이 있으니까요. 좀 눈치가 덜 보입니다. 이 5분 정도가 또 마침 짧은 리팩토링과 타이밍이 같습니다. 다시 자리로 돌아왔을 때, 뇌가 자연스럽게 다음 맥락을 잡습니다. 남는 시간 활용법으로 가장 무난한 선택입니다.

15분 이상: 산책

대기 시간이 길어질 때만 꺼내는 카드입니다. 돌아오면 PR이 올라와 있고, 머리는 확실히 맑아집니다. 핵심은 “걷는 동안 아무것도 안 하기”입니다. 그래야 진짜 회복이 됩니다.

에이전트는 안 쉬니까, 내가 쉬기

에이전트의 장점은 단순합니다. “내가 안 해도 된다”는 점입니다. 그런데도 손이 계속 뭔가를 찾으면, 결국 머리는 쉬지 못합니다.

그래서 정말로 안 하는 시간을 따로 설계해야 합니다. 이걸 안 하면 피로는 조용히 누적됩니다. 남는 시간의 활용법이 꼭 생산성 메뉴일 필요는 없습니다. 때로는 죄책감 없이 쉬는 것이 다음 작업에 낫습니다.

마치며

Claude Code가 일하며 만들어 준 그 시간, 이 빈 시간들은 애매한 공백입니다. 기다리기엔 길고, 새 일을 시작하자니 짧습니다. 이 구간은 생각보다 전환 비용이 큰 시간입니다. 무작위로 쓰면 머리가 엉망으로 깨져요. 그래서 필요한 게 남는 시간의 활용법을 미리 정해두는 겁니다.

다음 대기 시간이 오면 멍하니 창밖을 일단 바라보기 전에, 먼저 질문 하나만 던져봅시다. 지금 나는 뭘 하면 끝나고 나서 덜 후회할까? 생각해 보는 거죠.

글에서 추천한 방식 그대로일 필요는 없습니다. 중요한 건 이 시간을 쓰고 난 다음, 내가 나를 에이전트보다 무가치하게 느끼지 않는 겁니다. 그 시간에 우울해하지 말고, 나에게 맞는 메뉴를 정해 시간을 써봅시다.