이 문서를 어디에 둘지, 더는 고민하지 않기로 했다

새로 익힌 기술을 정리한 노트 하나를 저장하려다, 폴더 목록 앞에서 잠깐 멈췄다. 이걸 어디에 둬야 나중에 다시 찾을 수 있을까. docs 밑인가, 프로젝트 폴더 안인가, 아니면 따로 notes 를 팔까. 1초쯤 망설이다 대충 한 곳에 넣는다. 그리고 두 달 뒤, 그 문서를 어디에 뒀는지 기억하지 못한다.

별것 아닌 망설임이다. 그런데 이 순간은 무언가를 자산으로 남기려 할 때마다 돌아온다. 새로 도입한 기술을 정리할 때, 인수인계의 포인트가 될 주요 작업을 끝냈을 때, 신규 개발에 앞서 모은 조사 자료를 갈무리할 때. 기록해 둘 만한 것이 생길 때마다 같은 마찰이 반복되고, 여러 프로젝트를 혼자 굴리다 보면 이 사소한 결정이 곳곳에 쌓인다. 더 나쁜 것은, 그때그때 기분으로 분류하면 규칙이 흐트러져 나중에 검색조차 어려워진다는 점이다.

문제는 분명했다. 나는 ‘이 문서를 어디에 둘지’ 를 매번 결정하고, 그 결정을 기억하고 있어야 했다. 둘 다 하고 싶지 않았다.

주제로 나누면 끝없이 갈라진다

문서를 분류하는 가장 흔한 방식은 주제별이다. frontend, backend, 인프라, 리서치… 그런데 주제 분류는 무한히 갈라진다. 한 문서가 두세 주제에 걸치는 일도 흔하다. ‘메시지 큐 도입 검토 노트’ 는 메시지큐 인가 아키텍처 인가 리서치 인가. 정답이 없으니 매번 새로 고민하게 된다.

주제는 분류의 기준으로 삼기에 너무 미끄럽다.

PARA — 주제가 아니라 행동으로 나눈다

Tiago Forte 가 제안한 PARA 는 이 문제를 다른 축으로 푼다. 모든 문서를 단 네 칸으로 나눈다.

• Projects — 마감과 목표가 있는 능동적 작업
• Areas — 끝나지 않는, 지속적으로 책임지는 영역
• Resources — 언젠가 참고할 자료
• Archives — 끝났거나 비활성이 된 것

핵심은 분류 기준이 ‘무엇에 관한 글인가(주제)’ 가 아니라 ‘지금 내 행동에 얼마나 가까운가(행동 가능성)’ 라는 데 있다. 같은 API 문서라도, 이번 분기에 끝내야 할 기능에 딸린 것이면 Projects 고, 상시 유지하는 시스템의 참고용이면 Resources 다. 글의 주제가 아니라 내가 그것으로 지금 무엇을 하느냐가 자리를 정한다.

이 전환이 우아한 이유는, 무한히 갈라지던 분류가 네 칸으로 수렴하기 때문이다. 주제는 셀 수 없지만, ‘행동과의 거리’ 는 Projects → Areas → Resources → Archives 라는 한 줄로 줄세울 수 있다.

다만 PARA 도 한 가지는 사람에게 남겨둔다. ‘이 문서가 Project 냐 Area 냐’ 라는 판단이다. 규칙은 명확하고 유한해졌지만, 그 규칙을 매 문서에 적용하는 일은 여전히 내 몫이었다.

명확한 규칙은 위임할 수 있다

여기서 생각이 한 칸 움직였다. PARA 의 미덕은 규칙이 분명하고 유한하다는 것이다. 그리고 분명하고 유한한 규칙은 — 위임할 수 있다.

판단의 기준이 “마감이 있으면 Projects, 끝이 없으면 Areas” 처럼 몇 줄로 적힌다면, 그 판단을 꼭 내가 할 이유가 없다. 규칙을 또렷이 적어 건네줄 상대만 있으면 된다. 마침 그런 상대가 생겼다. 코드를 읽고, 판단하고, 파일을 쓰는 에이전트.

규칙을 스킬로 굳히다

그래서 PARA 분류 규칙을 Claude Code 스킬로 만들었다. 이름은 para-docs. 스킬은 문서를 만들 때 몇 가지 질문으로 자리를 정한다.

# para-docs picks the category from a few yes/no questions
- Has a deadline or a specific goal?      → Projects
- An ongoing responsibility, no end date? → Areas
- Reference material for later?           → Resources

이제 흐름은 단순하다. “방금 정리한 기술, 문서로 남겨줘” 라고 하면, 에이전트가 내용을 읽고 위 규칙으로 분류를 정한 뒤, 알맞은 칸에 kebab-case 파일명으로 저장한다. 어디에 둘지, 무슨 이름으로 둘지를 내가 정하지 않는다.

한 가지 더 손봐서, 이 스킬을 모든 프로젝트에서 똑같이 쓸 수 있게 했다. 저장소마다 폴더 관습이 다르기 때문이다. 어떤 저장소는 루트에 projects/, areas/ 를 바로 두고, 어떤 저장소는 para/ 아래에 모은다. 스킬이 시작할 때 루트를 살펴 그 저장소가 어느 방식인지 스스로 감지해 맞춘다. 덕분에 새 프로젝트에 들어가도 설정 없이 곧장 같은 방식으로 문서가 정리된다.

커밋 로그가 문서가 되는 순간

실제로 내가 가장 자주 쓰는 흐름은 이렇다. 하루 이틀 무언가를 만들고 커밋을 몇 개 쌓은 뒤, 그 작업을 기록으로 남기고 싶을 때가 있다. 그러면 작업이 끝난 자리에서 이렇게 말한다.

“지난 사흘 커밋 로그를 훑어서, 이 기술을 이런 관점으로 문서로 남겨줘.”

그러면 에이전트가 그 기간의 커밋 로그를 읽어 무엇을 했는지 추려내고, 내용을 문서로 정리한 뒤, PARA 규칙에 따라 알맞은 자리에 저장한다. 나는 어떤 커밋이 있었는지 일일이 떠올리지 않아도 되고, 그 글을 어느 폴더에 둘지도 정하지 않는다. 기록의 재료(커밋)와 분류의 규칙(PARA)이 이미 있으니, 사람이 할 일은 ‘무엇을, 어떤 관점으로’ 한 줄 일러주는 것뿐이다.

문서화가 자꾸 미뤄지는 진짜 이유는 글을 쓰는 일 자체보다, 무엇을 했는지 되짚고 어디에 둘지 정하는 앞뒤의 마찰에 있다. 그 앞뒤를 에이전트가 가져가니, 기록은 일이 아니라 한 마디가 된다.

사라진 고민

바뀐 것은 작아 보이지만 결정적이다. 이제 문서를 만들 때 ‘이걸 어디에 둬야 나중에 찾지’ 를 고민하지 않는다. 그 질문에 답하는 일은 에이전트의 몫이고, 에이전트는 늘 같은 규칙으로 답한다.

사람과 자동화의 분담이 자연스럽게 갈렸다. 무엇을 쓸지, 그 내용은 사람이 정한다. 어디에 둘지, 그 자리는 규칙이 정한다. 일관성이 사람의 의지력이 아니라 규칙에서 나오므로, 두 달 뒤에 그 문서를 어디서 찾을지도 고민할 필요가 없다. 규칙이 일정하면 찾는 길도 일정하다.

직접 써보려면

이 스킬은 공개 마켓플레이스 poorants/ant-skills 에 있다. Claude Code 에 마켓플레이스를 등록하고 설치하면 된다.

claude plugin marketplace add poorants/ant-skills
claude plugin install ant-project-kit@ant-agent-skills

설치한 뒤 프로젝트에서 “문서 정리해줘” 또는 위처럼 “커밋 로그 보고 문서로 남겨줘” 라고 말하면 된다. 루트에 PARA 폴더가 이미 있으면 그 구조를 그대로 따르고, 없으면 만들어 시작한다.

마무리

PARA 는 원래 사람의 결정 피로를 줄이려고 만들어진 방법이다. 거기에 에이전트를 한 겹 얹으니, 줄어들 뿐이던 결정이 아예 사라졌다.

요즘 말로 하면 이것은 에이전틱 워크플로우의 아주 작은 실천이다. 거창한 자동화가 아니라, 규칙이 분명한 일 하나를 골라 에이전트에게 넘긴 것뿐이다. 다만 그 하나가 매일 반복되던 사소한 마찰이었다는 점에서, 체감은 작지 않다. 분류는 규칙에게 맡기고, 나는 쓰는 일에만 머문다.