고칠 줄 몰라서가 아니라 불편한 줄 몰라서 — 기억해야 할 창구를 줄인 업무 환경 개선기#
2026-11-15
챙길 게 늘자 의욕이 줄었다#
필자는 회사 일과 별개로 Ted Factory라는 이름 아래 개인 서비스 몇 개와 이 블로그를 운영합니다. 전략을 코드로 짜서 대결하는 Code Battle, 웹 페이지를 읽고 대신 조작해 주는 크롬 확장 I am your AI, 아직 공개 전인 서비스 하나, 그리고 매주 AI 뉴스와 에세이를 싣는 이 블로그입니다. 앞으로도 앱을 하나씩 늘려 갈 생각입니다.
문제는 가짓수였습니다. 프로젝트마다 지금 어디까지 왔는지, 다음에 무엇을 해야 하는지, 필자가 직접 처리해야 할 일이 무엇인지를 머릿속에 들고 있어야 했습니다. 하나를 붙잡고 있으면 다른 것의 맥락이 흐려졌고, 오랜만에 다시 열면 “여기서 뭘 하고 있었더라"부터 시작했습니다. 그러다 보니 “오늘은 여기서 이걸 하고 저기서 저걸 하자"는 판단을 스스로 내리기가 어려워졌습니다. 무엇을 할지 정하는 일 자체가 짐이 되자, 일을 시작하고 싶은 마음도 함께 줄었습니다.
지난 7월 AI 에이전트 시대의 컨텍스트 스위칭에서는 여러 에이전트 세션 사이를 몇 분 단위로 오가는 문제를 다뤘습니다. 이번 문제는 단위가 다릅니다. 며칠, 몇 주에 걸친 여러 프로젝트의 맥락을 사람이 기억해야 하는 문제입니다. 그래서 이번에는 개인 업무 환경 전체를 손보기로 했습니다.
두 개의 업무 환경#
필자의 업무 환경은 회사 환경과 개인 환경으로 나뉩니다. 둘 다 Cursor에서 Claude Code 확장을 주로 쓰지만, 짜임새는 달랐습니다.
회사 환경은 작업 허브 저장소 하나를 중심으로 돌아갑니다. 백엔드, 프론트엔드, 배치 파이프라인, 에이전트 시스템 같은 저장소를 허브 안에 다른 위치에 있는 파일이나 폴더를 가리키는 일종의 바로가기입니다. 허브 안에 링크를 두면, 실제로는 각자 다른 곳에 있는 저장소들이 허브의 하위 폴더처럼 보입니다. 여러 프로젝트의 코드를 저장소 하나에 모아 관리하는 방식입니다. 필자의 회사 환경은 실제로 저장소를 합친 것은 아니고, 링크로 한곳에 모아 그렇게 보이게 만든 것입니다.
개인 환경은 반대였습니다. 저장소마다 Cursor 창을 따로 열고 그 안에서 작업했습니다. 저장소가 늘어날수록 창이 늘었고, 창이 늘수록 어느 창이 어느 저장소인지 찾는 일도 늘었습니다.
차이는 저장소 사이의 관계에 있었다#
처음에는 회사 방식을 그대로 가져오면 되지 않을까 생각했습니다. 그런데 두 환경을 나란히 놓고 보니 저장소 사이의 관계가 달랐습니다.
회사 저장소들은 서로 얽혀 있습니다. 백엔드를 고치면 프론트엔드가 따라 바뀌고, 파이프라인이 만든 데이터를 에이전트 시스템이 씁니다. 한 덩어리로 보는 편이 자연스럽습니다.
개인 저장소들은 서로 아무 관계가 없습니다. 코드 대결 게임과 크롬 확장은 공유하는 코드도 데이터도 없습니다. 개발할 때는 저장소별로 들어가는 편이 에이전트가 한 가지에 집중하기에 낫습니다. 예외가 하나 있었습니다. 블로그입니다. 블로그에는 다른 서비스의 개발 기록과 소개가 실리고, 서비스를 출시한 뒤 지표를 보고 분석하는 일도 블로그에서 하는 편이 편했습니다. 블로그만 다른 저장소에 관심이 있고, 다른 저장소는 블로그를 모릅니다. 한 방향 관계입니다.
그래서 개인 환경은 이렇게 나눴습니다. 개발은 저장소별로, 관찰과 기록은 블로그에서. 회사 환경을 흉내 내는 대신 관계의 모양에 맞추기로 했습니다.
문제는 기억해야 할 창구의 수였다#
구체적인 방법을 고르기 전에 문제를 다시 정의했습니다. 필자를 지치게 한 것은 일의 양이 아니었습니다. 일을 하려고 기억하고 들여다봐야 하는 창구가 너무 많았습니다. 여기서 창구는 넓은 뜻입니다. 저장소마다 떠 있는 에디터 창, 브라우저 프로필, 메신저, 프로젝트마다 흩어진 계획 문서와 지표 화면, 그리고 “다음에 뭘 하기로 했더라"를 붙들고 있는 머릿속 메모까지, 필자가 직접 상대해야 하는 인터페이스는 모두 창구입니다.
창구 하나하나는 가볍습니다. 하지만 개수가 늘면 비용은 일 자체가 아니라 “무엇이 어디에 있는지"라는 머릿속 지도를 유지하는 데서 생깁니다. 그 지도는 아무리 공들여도 시간이 지나면 낡습니다. 그래서 방향을 하나로 정했습니다. 필자가 직접 상대하는 창구의 수를 줄인다. 창구가 사라지는 것은 아닙니다. 그 많은 창구를 필자 대신 상대해 줄 창구 몇 개를 두는 것입니다. 이후에 만든 것들은 모두 이 원칙을 적용한 사례입니다.
줄이기 하나: 관찰은 블로그 한 곳에서#
첫 번째는 저장소를 오가는 일을 줄이는 것이었습니다. 블로그 저장소의 Claude Code 설정에 다른 서비스 저장소들을 추가 작업 디렉터리(additionalDirectories)로 등록했습니다. 이제 블로그 세션에서 서비스 저장소의 문서와 커밋 이력을 바로 읽을 수 있습니다. 서비스 지표도 같은 곳에서 봅니다. 블로그 분석에 쓰던 GA(Google Analytics) 조회 스크립트에 속성 ID를 받는 옵션 하나를 붙였더니, Code Battle의 지표도 같은 스크립트로 나왔습니다.
회사처럼 심볼릭 링크를 걸지 않은 이유는 집중력입니다. 추가 작업 디렉터리로 연결한 저장소의 규칙 파일(CLAUDE.md)은 따로 설정하지 않는 한 읽히지 않습니다. 새 세션을 띄워 확인해 보니, 연결한 저장소에 정의된 스킬도 블로그 세션의 스킬 목록에 나타나지 않았습니다. 블로그에서 글을 쓰는 동안 다른 서비스의 개발 규칙이 끼어들지 않습니다. 회사 환경에서 감수하던 단점을 개인 환경에서는 피한 셈입니다.
연결한 서비스 목록과 서비스마다 지표를 어디서 보는지는 블로그 저장소의 문서 한 장에 모았습니다. 서비스가 늘면 이 문서에 절 하나를 더하고, 설정에 경로 하나를 더하면 됩니다.
줄이기 둘: 창 찾기를 메뉴 하나로#
두 번째는 창이었습니다. 창이 여러 개 떠 있으면 어느 창이 어느 저장소인지 구분하기 어려웠습니다. 화면에 겹쳐 있는 창들은 이름을 보고 고르기가 힘들었고, Dock에 내려 두면 마우스를 올렸을 때 저장소 이름이 보여 구분은 쉬웠지만 매번 내렸다 올렸다 하는 것이 번거로웠습니다.
해법은 잠들지 않는 맥북 만들기에서 Sleep Guard를 만들 때 얻은 경험에서 나왔습니다. 그때 메뉴 막대에 아이콘을 띄우고, 누르면 메뉴가 나오게 하는 일이 생각보다 간단하다는 것을 알았습니다. 그렇다면 메뉴 막대 아이콘을 눌렀을 때 미리 정해 둔 저장소 목록이 나오고, 하나를 고르면 이미 열린 창은 앞으로 가져오고 열려 있지 않으면 새로 여는 작은 도구를 만들면 됩니다.
만들면서 범위를 넓혔습니다. 메뉴 항목을 “이름과 셸 명령 한 줄"로 정의하니, 터미널에서 실행할 수 있는 것이면 무엇이든 메뉴에 넣을 수 있었습니다. 에디터 창뿐 아니라 브라우저 프로필, 메신저, 코딩 에이전트 데스크톱 앱까지 한 메뉴에 들어갔습니다. 메뉴는 “개인"과 “회사” 구역으로 나눠 두 환경의 창구가 섞이지 않게 했습니다. 마우스로 열어도 되고, 단축키를 누르면 마우스 커서 자리에 바로 뜹니다. 메뉴 파일은 이런 모양입니다.
HOTKEY=ctrl+cmd+M
[개인]
blog = open -a Cursor ~/src/blog
code-battle = open -a Cursor ~/src/code-battle
Chrome 개인 = ~/.local/bin/chrome-profile "Profile 1"
---
[회사]
work-hub = open -a Cursor ~/work/hub
Chrome 회사 = ~/.local/bin/chrome-profile "Default"
Slack = open -a Slack“이미 열린 창이면 앞으로 가져오기"는 런처가 직접 구현하지 않고 각 명령에 맡겼습니다. 다만 확인해 보니 명령마다 사정이 달랐습니다. Cursor의 cursor <폴더> 명령은 Cursor가 이미 맨 앞에 있을 때만 해당 창으로 전환했고, 다른 앱이 앞에 있으면 Cursor를 앞으로 가져오지 못했습니다. macOS의 open -a Cursor <폴더>로 바꾸자 다른 앱이 앞에 있어도 해당 창이 맨 앞으로 왔습니다. 크롬은 프로필을 지정해 열면 누를 때마다 새 창이 생겼습니다. 그래서 크롬이 프로필 폴더에 남기는 세션 기록에서 그 프로필의 창을 찾아 앞으로 가져오고, 창이 없을 때만 새로 여는 작은 명령(chrome-profile)을 따로 만들었습니다.
이 도구는 menubar-launcher라는 이름으로 공개했습니다. 메뉴 파일을 고치면 앱을 다시 띄우지 않아도 다음에 메뉴를 열 때 바로 반영됩니다.
줄이기 셋: “오늘 뭐 하지"를 묻는 창구 하나#
세 번째가 가장 컸습니다. 창은 메뉴로 찾을 수 있게 됐지만, 어느 창을 열어 무엇을 할지는 여전히 필자가 기억해야 했습니다. 이 기억을 문서와 스킬로 옮겼습니다.
먼저 저장소마다 목표와 할 일을 적는 짧은 문서(.memory/goals.md)를 두었습니다. 칸은 몇 개뿐입니다. 이 프로젝트를 왜 하는지, 지금 단계의 목표와 판단 기준, “지금·다음·언젠가"로 나눈 할 일, 필자만 할 수 있는 일, 정기적으로 할 일입니다. 상세한 계획은 각 저장소의 계획 문서에 두고, 이 문서에는 한 줄 요약과 링크만 적습니다.
이 문서를 블로그가 아니라 각 저장소 안에 둔 것이 설계의 핵심입니다. 블로그에 모아 두면 개발 세션은 그 문서를 모르니 금방 낡습니다. 그래서 각 저장소의 에이전트 지침에 “작업을 마치거나 방향이 바뀌면 goals.md를 갱신한다"는 규칙을 한 줄 넣었습니다. 문서는 일하는 자리에서 갱신되고, 블로그는 읽기만 합니다. 앞에서 정한 한 방향 관계도 그대로 지켜집니다.
여러 저장소의 할 일 중 무엇을 먼저 할지는 문서가 정할 수 없습니다. 그래서 사업 우선순위를 한곳에 적어 두고, 그 순서만큼은 필자가 직접 정하기로 했습니다.
그리고 이것들을 모아 제안하는 스킬 /today를 만들었습니다. 블로그 세션에서 /today를 실행하면 작은 스크립트가 사실부터 모읍니다. 저장소별 최근 커밋, 커밋하지 않은 변경과 그 변경이 묵은 기간, 목표 문서가 마지막으로 갱신된 날, 매주 토요일 AI 뉴스나 월간 점검 같은 정기 일이 돌아왔는지입니다. 에이전트는 이 사실을 우선순위와 목표 문서에 대 보고 지금 할 일을 최대 세 개 고릅니다. 추천마다 해당 저장소 창에 그대로 붙여 넣으면 되는 질의가 함께 나오고, 그 창은 메뉴 막대 런처로 엽니다. 다시 떠올려야 했던 맥락은 그 질의 안에 들어 있습니다.
효과는 첫 실행 전에 먼저 나타났습니다. 기존 메모와 계획 문서를 모아 목표 문서 초안을 정리해 보니, 사업 문서에 우선순위 1위로 적혀 있던 프로젝트가 한 달째 멈춰 있었고 커밋하지 않은 변경이 수십 개 쌓여 있었습니다. 필자의 관심은 이미 다른 프로젝트로 옮겨 가 있었는데 문서는 그 변화를 따라오지 못하고 있었던 것입니다. 초안을 놓고 우선순위를 처음부터 다시 정했습니다. 문서로 꺼내 놓지 않았다면, 그 프로젝트는 “해야 하는데” 하는 막연한 부담으로만 계속 남아 있었을 겁니다.
첫 실행에서 /today가 맨 위로 올린 것은 2주째 비어 있던 Code Battle의 주간 마케팅 운영이었습니다. 매주 하기로 정해 놓고 잊고 있던 일입니다.
고칠 줄 아는가에서, 불편한 줄 아는가로#
이번 개선에 필자가 실제로 신경 쓴 시간은 한두 시간 남짓입니다. 저장소 연결, 목표 문서 정리, 메뉴 막대 런처 구현, /today 스킬 작성까지 손이 가는 일은 대부분 에이전트가 했고, 필자는 무엇이 불편한지 말하고 방향을 고르고 결과를 확인했습니다. 메뉴 막대 런처는 다른 Claude Code 세션에 요구사항을 넘겨 두고 이 작업과 나란히 진행했습니다.
예전에는 무언가를 개선하려면 개선할 줄 알아야 했습니다. 메뉴 막대 앱을 만들려면 macOS 앱 개발을, 여러 저장소의 상태를 모으려면 스크립트를 짤 줄 알아야 했습니다. 그걸 배우는 비용이 컸기 때문에 웬만한 불편은 그냥 참고 지냈습니다. 지금은 사정이 다릅니다. 해결 방법을 찾고 실제로 만드는 일은 에이전트에게 맡길 수 있습니다. 남은 병목은 개선할 필요가 있다는 것을 알아차리는 일입니다.
그런데 이 알아차림이 생각보다 어렵습니다. 이번에 고친 것들은 대부분 필자가 오래 불편해하면서도 불편이라고 부르지 않던 것들이었습니다. 저장소마다 창을 따로 열고, Dock에 내렸다 올리며 창을 찾고, 프로젝트마다 어디까지 했는지 기억해 내는 일은 너무 익숙해서 그냥 일의 일부처럼 느껴졌습니다. 사람은 불편에 빨리 적응합니다. 적응한 불편은 더 이상 불편으로 보이지 않고, 보이지 않는 불편은 고쳐지지 않습니다. 고칠 수 있는데도 참고 지내는 일이 아직 상당히 많을 거라고 필자는 생각합니다.
그래서 불편을 찾는 쪽에 의식적으로 신경을 쓰려고 합니다. 아직 정리된 방법이라고 하기는 어렵지만, 이번 경험에서 얻은 단서가 몇 가지 있습니다.
- 같은 손동작을 반복하고 있다면. 창을 내렸다 올리기, 같은 명령을 다시 치기, 같은 화면을 매일 열어 확인하기 같은 것입니다.
- “원래 그런 거지"라는 말이 나온다면. 이번에 고친 것 중 다수가 그렇게 넘기던 것이었습니다.
- 기억에 기대고 있다면. “다음에 이걸 해야지”, “그건 어디 있었더라"처럼 머릿속에만 있는 정보는 언젠가 잊힙니다. 잊지 않으려고 애쓰는 것 자체도 비용입니다.
- 의욕이 떨어졌다면. 이번에는 의욕이 줄어든 것이 출발점이었습니다. 하기 싫은 마음 뒤에 구조적인 불편이 숨어 있을 수 있습니다.
불편을 찾았다면 그다음은 어렵지 않습니다. 에이전트에게 지금 무엇이 불편한지 그대로 말해 보면 됩니다. 해결책을 미리 정해 갈 필요도 없습니다. 이번에도 필자가 처음 꺼낸 것은 “저장소마다 따로 들어가서 세션을 열고 작업하는 게 좀 불편하다"는 말 정도였고, 대화를 이어 가면서 메뉴 막대 런처와 /today라는 해법이 나왔습니다. 해법을 아는 것보다 불편을 말로 꺼낼 수 있는 것이 먼저였습니다.
맺으며#
이번에 만든 것들이 완성품은 아닙니다. 목표 문서가 일하는 자리에서 꾸준히 갱신될지, /today의 제안이 실제로 하루를 정하는 데 도움이 될지는 계속 써 봐야 압니다. 쓰면서 어긋나는 점이 보이면 그때그때 고쳐 나갈 생각입니다. 앱이 하나 늘 때마다 목표 문서 하나와 메뉴 항목 한 줄을 더하면 되도록 만들어 두었으니, 프로젝트의 가짓수가 늘어도 필자가 상대할 창구는 그대로입니다.