엔지니어를 위한 PARA 방법론: 행동을 중심으로 지식 조직하기
주제가 아니라 행위에 따라 노트를 정리하세요.
주제별로 노트를 정리하는 것은 논리적으로 들리지만, PostgreSQL에 대한 노트가 다섯 개의 다른 폴더에 흩어져 있어 오늘 해결해야 할 문제에 도움이 되는 노트를 찾을 수 없게 된다면 이야기가 달라집니다.
문제는 의지력이 아닙니다. 문제는 주제 기반 조직화가 잘못된 질문을 한다는 것입니다. “이것의 주제는 무엇인가?“라는 질문은 도서관에는 유용합니다. 하지만 엔지니어들에게 더 나은 질문은 “이것을 어떻게 활용하는가?“입니다. 이것이 바로 PARA의 전제입니다.
PARA는 Tiago Forte가 그의 두 번째 뇌(Second Brain) 프레임워크의 조직적 골격으로 만든 간단한 4개의 바구니(bucket) 시스템입니다. 모든 정보는 프로젝트(Projects), 영역(Areas), 리소스(Resources), 보관함(Archives)이라는 네 가지 범주로 분류할 수 있다는 아이디어입니다. 각 범주는 서로 다른 수준의 실행 가능성(actionability)을 나타내며, 이 구분이 각 노트의 위치를 결정합니다.
이 가이드는 PARA를 엔지니어링 작업, 특히 코드베이스, 문서화, 학습 자료, 그리고 활발한 프로젝트 작업과 장기적인 참조 사이의 긴장 관계에 특별히 적용하는 방법을 다룹니다.
주제 기반 조직화의 문제점
대부분의 엔지니어는 코드를 조직화하는 방식, 즉 도메인별로 지식을 조직화합니다.
databases/
postgresql/
redis/
api/
rest/
graphql/
devops/
kubernetes/
terraform/
이 구조는 탐색할 때는 의미가 있습니다. 하지만 특정 작업을 위해 무언가가 필요할 때는 붕괴됩니다. 데이터베이스 마이그레이션 안전성에 대한 유용한 노트를 기억하지만, 그것이 databases/postgresql/, devops/deployments/, api/versioning/에 있는지, 아니면 임시로 저장했으므로 어딘가에 있는지 알 수 없습니다.
주제 폴더는 컨텍스트를 이해하기 전에 지식이 어디에 속해야 하는지 결정하도록 강요합니다. PARA는 이 결정을 미룹니다. 무언가가 무엇에 관한 것인지 묻는 대신, 현재 그것을 어떻게 활용하는지 묻습니다.
네 개의 바구니
프로젝트(Projects)
프로젝트는 정의된 결과물을 가진 활발하고 시간 제한이 있는 작업입니다.
엔지니어에게 프로젝트는 다음과 같은 것들입니다.
빌링 서비스를 큐 v2로 마이그레이션
PostgreSQL을 14에서 16으로 업그레이드
인증 서비스 재설계를 위한 아키텍처 결정 기록(ADR) 작성
공개 API에 속도 제한 구현
분산 추적에 대한 기사 게시
모든 프로젝트는 완료 상태가 있습니다. 작업을 마치면 프로젝트는 보관함(Archives)으로 이동합니다. 활발하게 작업하지 않는다면 그것은 프로젝트가 아닙니다.
핵심 제약 조건: 프로젝트 노트에는 해당 프로젝트에 필요한 것만 포함되어야 합니다. 참조 자료는 리소스(Resources)에 속합니다. 재사용 가능한 개념은 제텔카스텐(Zettelkasten)이나 개인 노트에 속합니다. 프로젝트 노트는 지식 저장소가 아닌 작업 문서입니다.
영역(Areas)
영역은 마감일이 없는 지속적인 책임입니다.
엔지니어의 영역에는 다음이 포함됩니다.
시스템 아키텍처
인프라 안정성
코드 리뷰 품질
전문적 개발
API 설계 표준
보안 태세
온콜(on-call) 책임
멘토링
영역은 끝나지 않습니다. 당신은 항상 인프라 안정성에 책임이 있습니다. 항상 전문적 개발에 관심을 가집니다. 프로젝트와 영역의 차이는 영역에는 종료 기준(exit criteria)이 없다는 것입니다. 완료해야 할 것이 아니라 유지해야 할 것입니다.
유용한 규칙: 배포하거나 티켓을 닫을 수 있다고 상상할 수 있다면 그것은 프로젝트입니다. 역할의 의미의 일부일 뿐이라면 그것은 영역입니다.
리소스(Resources)
리소스는 나중에 유용할 수 있을 것이라고 기대하여 수집한 참조 자료입니다.
엔지니어의 경우:
API 문서 북마크
치트 시트(Cheat sheets)
벤치마크 결과
서드 파티 시스템의 아키텍처 다이어그램
다시 보고 싶은 컨퍼런스 강연
라이브러리 문서
연구 논문
흥미로운 블로그 기사
리소스에는 현재 작업에서 활발한 집이 없습니다. 결국 필요할 것이라고 기대하여 수집됩니다. 여기서 중요한 규율은 리소스가 프로젝트로 위장해서는 안 된다는 것입니다. Kubernetes 문서 모음은 리소스입니다. “플랫폼 마이그레이션을 위해 Kubernetes를 배우기” 위한 진행 중인 작업은 프로젝트입니다.
보관함(Archives)
보관함에는 더 이상 활발하지 않은 모든 것이 포함됩니다.
아이템은 다음과 같은 경우에 보관함으로 이동합니다.
- 프로젝트가 완료되거나 취소된 경우
- 책임 영역이 다른 사람에게 넘어간 경우
- 자료 자료가 너무 오래되어 유용하지 않은 경우
- 무언가를 보존하고 싶지만 활발한 바구니에서 필요하지 않은 경우
보관함은 삭제하지 않습니다. 활발한 수명을 마친 것들을 위한 저마찰 저장소입니다. 규칙은 간단합니다. 무언가가 보관함에 있는지 궁금해한다면 괜찮습니다. 보관함 콘텐츠를 긴급하게 필요로 하는 경우는 드뭅니다.
엔지니어를 위한 PARA의 실제 적용
Obsidian에서 엔지니어의 PARA 구조가 어떻게 보일 수 있는 구체적인 예는 다음과 같습니다.
Projects/
billing-queue-migration/
postgresql-16-upgrade/
rate-limiting-rfc/
blog-distributed-tracing/
Areas/
architecture-standards/
infrastructure/
on-call-runbooks/
career-development/
Resources/
api-references/
database-cheatsheets/
benchmark-results/
conference-notes/
Archives/
2025-q4-projects/
deprecated-services/
old-runbooks/
폴더 구조 자체는 신성하지 않습니다. 중요한 것은 현재 작업과의 관계에 따라 노트를 올바른 범주에 배치하는 규율입니다.
전형적인 엔지니어의 지식 매핑
많은 엔지니어는 미분화된 노트 더미로 시작합니다. PARA로 마이그레이션하려면 단일 감사 패스가 필요합니다.
프로젝트 — 현재 작업 중인 티켓, 마감일, 또는 결과물이 있는 것.
영역 — 역할을 정의하는 반복적인 책임.
리소스 — 특정 프로젝트를 염두에 두지 않고 수집한 참조 자료.
보관함 — 기타 모든 것.
실용적인 규칙: 의심스러우면 보관하세요. 나중에 언제든지 검색할 수 있습니다. 과잉 채워진 프로젝트 폴더는 덜 사용된 보관함보다 더 해롭습니다.
PARA와 제텔카스텐: 실용적인 하이브리드
PARA와 제텔카스텐은 종종 경쟁하는 시스템으로 비교됩니다. 그들은 경쟁하지 않습니다. 서로 다른 문제를 해결합니다.
제텔카스텐은 아이디어를 위한 것입니다. 원자적 개념을 포착하고 의미에 따라 연결하며, 연결에서 이해가 떠오르게 합니다. 제텔카스텐 노트는 프로젝트에 묶여 있지 않습니다 — 활발한 바구니에 속하지 않습니다. 멱등성(idempotency)에 대한 노트는 과거와 미래의 10가지 다른 프로젝트에 적용됩니다.
PARA는 행동을 위한 것입니다. 활발하게 하고 있거나, 책임이 있거나, 나중에 사용하기 위해 수집하고 있는 것 주변에 작업 컨텍스트를 조직화합니다.
실용적인 하이브리드:
Projects/
billing-queue-migration/
migration-plan.md
open-questions.md
→ links to Zettelkasten: [[Idempotency keys turn retries into safe operations]]
→ links to Zettelkasten: [[Outbox pattern separates persistence from delivery]]
Areas/
architecture-standards/
current-adr-index.md
→ links to Zettelkasten: [[Database constraints are concurrency control]]
Resources/
benchmark-results/
q1-2026-postgres-benchmarks.md
이 모델에서 PARA 폴더는 작업 문서와 컨텍스트를 보유합니다. 제텔카스텐 노트는 재사용 가능한 지식을 보유합니다. 프로젝트 노트는 제텔카스텐 개념을 링크합니다 — 프로젝트는 개념을 소유하지 않고 사용합니다.
이는 PARA에 제텔카스텐의 역할을 수행하게 하려는 시도보다 더 내구성이 있습니다. 프로젝트는 끝납니다. 개념은 남습니다.
일반적인 실패 사례
과도한 아카이빙
일부 엔지니어는 보관함을 삭제하는 것에 죄책감을 느끼는任何东西을 위한 덤프로 사용합니다. 보관함이 커지고 정렬되지 않으면 그 가치를 잃습니다. 보관함에는 정돈되지 않은 노트의 묘지가 아니라 합리적인 상태의 완료된 작업이 포함되어야 합니다.
정기적인 보관함 정리(분기별이 좋습니다)는 이를 관리 가능하게 유지합니다. 중복을 삭제하고 통합합니다. 보관하기 전에 오래된 프로젝트 노트가 리소스 또는 제텔카스텐 노트로 유지할 만한 가치가 있는 것이 여전히 포함되어 있는지 물어봅니다.
영역이 덤프장으로 변하는 것
영역이 가지치기 없이 성장하면 주제 기반 폴더 시스템처럼 보이기 시작합니다. 3년 동안 정렬되지 않은 노트가 포함된 databases/라는 영역은 책임이 아닙니다. 그것은 더미입니다.
각 영역을 타이트하게 유지합니다. 영역은 광범위하게 관심 있는 주제가 아니라 활발하게 책임져야 할 무언가를 나타내야 합니다. 관심사는 리소스로, 책임은 영역으로 갑니다.
검토 없이 리소스가 성장하는 것
리소스는 수집하기 쉽고 잊기 쉽습니다. 400개의 정렬되지 않은 링크가 있는 Resources/의 북마크 덤프는 북마크 관리자보다 사용하기 어렵습니다. 리소스는 가볍게 큐레이션되어야 합니다 — 오래된 자료를 제거하고 신호를 유지합니다.
주간 검토 건너뛰기
PARA는 프로젝트 폴더의 10분 주간 검토와 함께 가장 잘 작동합니다. 각 활성 프로젝트에 대해:
- 이것이 여전히 활발합니까?
- 다음 구체적인 작업은 무엇입니까?
- 보관함으로 이동해야 할 것이 있습니까?
그 검토 없이 프로젝트는 구식 항목을 누적하고 시스템은 작업의 현재 뷰로서의 가치를 잃습니다.
Obsidian에서의 구현
Obsidian은 폴더가 네 바구니로 직접 매핑되고 Dataview 쿼리가 자동으로 프로젝트 상태를 표시할 수 있기 때문에 PARA에 자연스러운 적합성입니다.
기본 설정:
vault/
├── Projects/
├── Areas/
├── Resources/
├── Archives/
└── Zettelkasten/ ← 개념 노트, 자유롭게 연결
활성 프로젝트 노트를 표시하기 위한 간단한 Dataview 쿼리:
LIST FROM "Projects"
WHERE !contains(file.path, "Archives")
SORT file.mtime DESC
태그는 파일을 이동하지 않고 상태를 표시할 수 있습니다:
tags: [project, active]
tags: [project, paused]
tags: [project, done]
프로젝트가 완료되면 done으로 태그를 붙이고 폴더를 Archives/YEAR-QN/로 이동합니다. 간단하고 감사 가능하며 역방향 가능합니다.
일반 파일에서의 구현
Obsidian이 필요하지 않습니다. PARA는 일반 Markdown이 있는 Git 저장소에서同等하게 잘 작동합니다.
knowledge/
projects/
2026-billing-migration/
README.md
migration-plan.md
decisions.md
areas/
architecture/
adr-index.md
resources/
databases/
postgres-16-release-notes.md
archives/
2025/
feature-x-launch/
Git는 히스토리, diff, 검색, 이식성을 제공합니다. 개인 시스템에 대해 종종 충분합니다.
PARA가 의미 있는 경우
PARA는 다음과 같은 경우에 적합합니다.
- 동시에 여러 활성 프로젝트를 다루는 경우
- 오늘 작업과 관련 있는 것을 빠르게 찾아야 하는 경우
- 폴더 친화적이고 도구 독립적인 시스템을 원하는 경우
- 재사용 가능한 아이디어를 위해 제텔카스텐 또는 개념 노트 레이어와 결합하는 경우
PARA는 다음과 같은 경우에 덜 유용합니다.
- 명확한 바구니가 없는 단일 장기 프로젝트로 작업하는 경우
- 활성 결과물이 없는 연구 중심 작업을 주로 수행하는 경우
- 명시적 분류보다 자연스럽게 형성되는 구조를 선호하는 경우
활발한 프로젝트 작업과 장기 학습을 혼합하는 엔지니어에게 PARA와 제텔카스텐은 대부분의 경우를 커버합니다: 컨텍스트를 위한 PARA, 사고를 위한 제텔카스텐.
의사 결정 프레임워크
새로운 노트가 도착하면 다음 질문을 순서대로 물어봅니다.
- 이것은 활발하게 노력하고 있는 무언가와 연결되어 있습니까? → 프로젝트
- 이것은 내가 소유하고 있는 지속적인 책임의 일부입니까? → 영역
- 이것은 나중에 필요할 수 있는 참조 자료입니까? → 리소스
- 이것은 완료되었거나 비활성 상태입니까? → 보관함
- 이것은 어떤 프로젝트에도 묶이지 않은 재사용 가능한 개념 또는 아이디어입니까? → 제텔카스텐
그것이 전체 의사 결정 트리입니다. 5가지 옵션. 옵션당 하나의 규칙. 노트당 약 10초가 걸립니다.
최종 생각
PARA가 작동하는 이유는 엔지니어가 실제로 지식을 사용하는 방식, 즉 탐색이 아닌 행동을 위해 매치하기 때문입니다. databases/에 무엇이 있는지 보려고 노트를 열지 않습니다. 지금 특정 문제를 해결하고 있고 관련 자료를 빠르게 표면화해야 하기 때문에 엽니다.
활발한 프로젝트를 참조 자료와 분리하고, 둘 다 완료된 작업과 분리하는 규율은 개인 지식 기반을 유지하는 인지적 오버헤드를 줄입니다. 개인 지식 관리의 기초와 개념 수준의 노트를 위한 제텔카스텐과 결합하여, PARA는 중요한 순간에 모든 것을 찾을 수 있게 해주는 조직적 골격을 제공합니다.
바구니당 하나의 폴더로 시작합니다. 기존 노트를 분류하기 위해 한 번의 감사를 실행합니다. 매주 프로젝트를 검토합니다. 나머지는 자연스럽게 따릅니다.
