프로젝트와 작업 관리를 옵시디언에 통합하기

프로젝트는 폴더가 아니라 실행 단위다

프로젝트 관리는 할 일 목록을 많이 만드는 일이 아닙니다. 목표, 자료, 결정, 회의, 피드백, 다음 행동을 한곳에서 이어 보는 일입니다. 옵시디언은 생각을 보관하는 도구이지만, 잘 구성하면 결과물을 완성하는 작업 공간이 됩니다.

여기서 말하는 프로젝트는 끝나는 지점이 있는 단위입니다. 예를 들어 신규 서비스 제안서 작성, 졸업 논문 초안 완성, 가족 여행 준비, 강의 자료 제작은 프로젝트입니다. 반대로 건강 관리, 독서, 팀 운영처럼 계속 유지해야 하는 것은 프로젝트보다 Areas에 가깝습니다.

프로젝트를 옵시디언에 넣는 이유는 간단합니다. 일은 보통 할 일만으로 끝나지 않기 때문입니다. 참고 자료를 읽고, 회의를 하고, 결정을 내리고, 피드백을 받고, 다시 수정합니다. 이 흐름이 여러 앱에 흩어지면 나중에 "왜 이렇게 결정했지?"를 찾기 어렵습니다. 옵시디언에서는 그 맥락을 링크와 노트로 남길 수 있습니다.

AI 생성 이미지

프로젝트 폴더의 기본 구조

처음부터 복잡한 프로젝트 관리 시스템을 만들 필요는 없습니다. 프로젝트 하나마다 작은 작업 공간을 만든다고 생각하면 됩니다.

예를 들어 10_Projects/신규 서비스 제안서 폴더를 만들고 그 안에 다음 노트를 둘 수 있습니다.

10_Projects/
  신규 서비스 제안서/
    신규 서비스 제안서.md
    신규 서비스 제안서 - 자료 모음.md
    신규 서비스 제안서 - 회의록.md
    신규 서비스 제안서 - 피드백.md
    신규 서비스 제안서 - 다음 행동.md

파일 이름은 취향에 맞게 줄여도 됩니다. 다만 여러 프로젝트에 자료 모음.md, 회의록.md, 다음 행동.md 같은 이름이 반복되면 링크를 걸 때 헷갈릴 수 있습니다. 그래서 처음에는 프로젝트 이름을 앞에 붙여 두는 편이 안전합니다. 노트 안에서는 별칭을 사용해 [[신규 서비스 제안서 - 자료 모음|자료 모음]]처럼 짧게 보이게 만들 수 있습니다.

각 노트의 역할은 분명해야 합니다.

• 신규 서비스 제안서.md: 프로젝트의 개요 노트입니다. 목표, 완료 기준, 마감일, 관련 링크를 담습니다.

• 신규 서비스 제안서 - 자료 모음.md: 참고한 기사, 책, 내부 문서, 경쟁 서비스 링크를 모읍니다.

• 신규 서비스 제안서 - 회의록.md: 회의별 기록으로 이동하는 입구입니다. 모든 회의 내용을 한 노트에 길게 쌓기보다 날짜별 회의록을 링크해도 좋습니다.

• 신규 서비스 제안서 - 피드백.md: 받은 의견과 반영 여부를 기록합니다.

• 신규 서비스 제안서 - 다음 행동.md: 지금 실제로 해야 할 일을 모읍니다.

핵심은 모든 것을 한 노트에 넣는 것이 아니라, 자주 확인해야 하는 종류별로 입구를 나누는 것입니다. 프로젝트 개요 노트는 홈 노트나 업무 MOC에서 바로 연결해 두면 좋습니다.

프로젝트 개요 노트는 이렇게 시작할 수 있습니다.

---
type: project
status: 진행 중
due: 2026-07-10
area: 업무
---

## 목표
신규 서비스 제안서 초안을 완성해 7월 기획 회의에 제출한다.

## 완료 기준
- 제안 배경 정리
- 핵심 기능 3개 설명
- 예상 일정 작성
- 팀장 피드백 반영

## 관련 노트
- [[신규 서비스 제안서 - 자료 모음|자료 모음]]
- [[신규 서비스 제안서 - 회의록|회의록]]
- [[신규 서비스 제안서 - 피드백|피드백]]
- [[신규 서비스 제안서 - 다음 행동|다음 행동]]

## 현재 결정
- 첫 버전은 모바일 기능 중심으로 작성한다.

속성은 많이 넣지 않아도 됩니다. 처음에는 type, status, due, area 정도면 충분합니다. 중요한 것은 이 프로젝트가 무엇인지, 지금 어떤 상태인지, 언제까지 끝내야 하는지를 빠르게 확인하는 것입니다.

노트 속 할 일을 놓치지 않는 방법

옵시디언에서 작업 관리는 체크박스에서 시작합니다. 체크박스는 Markdown 문법으로 만드는 간단한 할 일 표시입니다. 별도 앱이 없어도 노트 안에서 바로 쓸 수 있습니다.

- [ ] 경쟁 서비스 3개 조사하기
- [ ] 제안서 목차 작성하기
- [x] 지난 회의록 정리하기

체크박스가 필요한 이유는 기록과 실행이 자연스럽게 섞이기 때문입니다. 회의 중에 결정 사항을 적다가 바로 할 일이 생기고, 자료를 읽다가 확인할 질문이 생깁니다. 이때 할 일을 별도 앱으로 옮기는 과정이 번거로우면 놓치기 쉽습니다.

다만 모든 노트에 흩어진 체크박스를 매일 찾아다니면 피곤합니다. 그래서 규칙이 필요합니다.

첫째, 즉시 처리할 일은 그 자리에서 체크박스로 적습니다.

## 2026-06-15 회의

결정: 제안서 첫 장에는 시장 배경보다 사용자 문제를 먼저 제시한다.

- [ ] 사용자 인터뷰 인용문 2개 찾기
- [ ] 기존 목차에서 시장 분석 부분 뒤로 이동하기

둘째, 프로젝트 전체에서 관리해야 할 일은 다음 행동.md에도 모읍니다. 이때 할 일만 복사해 두면 나중에 맥락을 잃기 쉽습니다. 가능하면 원래 회의록이나 자료 노트 링크를 함께 남깁니다.

## 이번 주
- [ ] 제안서 1차 목차 완성하기
- [ ] [[2026-06-15 서비스 제안 회의]] 사용자 인터뷰 인용문 2개 찾기
- [ ] 팀장에게 방향성 확인받기

## 대기 중
- [ ] 디자인팀에서 화면 예시 받기

## 나중에
- [ ] 발표 자료로 전환할 때 사용할 이미지 후보 정리

셋째, 마감이 있는 일은 노트 속성이나 본문에 날짜를 남깁니다.

- [ ] 팀장 피드백 요청하기 📅 2026-06-20

이 날짜 표기는 기본 옵시디언에서도 검색할 수 있는 약속입니다. 특정 플러그인을 쓰면 날짜 기반으로 작업을 모아 볼 수도 있지만, 처음에는 플러그인보다 표기 방식을 통일하는 것이 더 중요합니다. 어떤 날은 6/20, 어떤 날은 다음 주 금요일, 어떤 날은 2026-06-20으로 쓰면 나중에 찾기 어렵습니다. 가능하면 YYYY-MM-DD 형식으로 맞추세요.

태그는 할 일의 성격을 빠르게 표시할 때 유용합니다.

- [ ] 예산 추정치 확인하기 #대기
- [ ] 제안서 요약문 다시 쓰기 #집중
- [ ] 회의 안건으로 올리기 #회의

단, 태그를 너무 많이 만들면 관리 대상이 늘어납니다. 프로젝트 작업에서는 #대기, #회의, #집중, #확인필요처럼 실제 행동을 바꾸는 태그만 남기는 편이 좋습니다.

결정 사항은 할 일보다 오래 남는다

프로젝트 노트에서 할 일만 관리하면 나중에 중요한 맥락이 사라집니다. 완료된 체크박스는 "무엇을 했는지"는 알려 주지만 "왜 그렇게 했는지"는 설명하지 못합니다.

그래서 프로젝트마다 현재 결정 또는 결정 기록 섹션을 두는 것이 좋습니다.

## 결정 기록

### 2026-06-15
- 제안서 첫 장은 시장 규모보다 사용자 문제를 먼저 다룬다.
- 이유: 기획 회의에서 설득해야 할 핵심은 시장성보다 문제의 선명도이기 때문이다.
- 관련: [[2026-06-15 서비스 제안 회의]]

이런 기록은 프로젝트가 끝난 뒤에도 재사용됩니다. 다음 프로젝트에서 비슷한 제안서를 쓸 때, 단순한 결과물보다 당시의 판단 기준이 더 큰 도움이 됩니다.

결정 기록은 길게 쓰지 않아도 됩니다. 날짜, 결정 내용, 이유, 관련 노트만 있으면 충분합니다. 중요한 것은 결정이 바뀌었을 때도 이전 기록을 지우지 않는 것입니다. 나중에 보면 "틀린 결정"처럼 보이는 것도 당시에는 이유가 있었을 수 있습니다. 그 이유가 남아 있어야 같은 실수를 줄일 수 있습니다.

Canvas로 복잡한 생각을 펼쳐 보기

Canvas는 노트, 카드, 이미지, 링크를 넓은 화면에 배치해 관계를 시각적으로 보는 기능입니다. 글로 정리하기 전에 생각이 복잡하게 얽혀 있을 때 유용합니다.

Canvas가 필요한 순간은 다음과 같습니다.

• 프로젝트 구조가 아직 정해지지 않았을 때

• 여러 아이디어의 관계를 한눈에 보고 싶을 때

• 발표 흐름, 제품 기능, 연구 주제를 묶어 보고 싶을 때

• 회의에서 나온 의견을 주제별로 재배치해야 할 때

예를 들어 제안서를 준비한다면 Canvas에 다음 카드를 놓을 수 있습니다.

• 사용자 문제

• 경쟁 서비스

• 핵심 기능

• 예상 일정

• 위험 요소

• 필요한 자료

그다음 관련 있는 카드끼리 선으로 연결합니다. 사용자 문제에서 핵심 기능으로, 위험 요소에서 예상 일정으로 연결해 보면 제안서의 빈틈이 보입니다. 아직 자료가 부족한 영역도 눈에 띕니다.

Canvas는 최종 문서가 아니라 생각을 펼치는 작업대에 가깝습니다. 그래서 너무 예쁘게 꾸미려고 애쓰지 않아도 됩니다. 한 번 정리한 뒤에는 중요한 카드만 실제 노트로 만들고, 프로젝트 개요 노트에 링크해 두면 충분합니다.

Kanban 보드는 흐름을 볼 때 쓴다

Kanban은 작업을 카드로 만들고 할 일, 진행 중, 완료 같은 단계에 배치하는 방식입니다. 옵시디언에서는 커뮤니티 플러그인을 통해 Kanban 보드를 사용할 수 있습니다.

여기서 중요한 원칙이 있습니다. Kanban은 모든 프로젝트에 필요한 기능이 아닙니다. 작업이 많고, 상태가 자주 바뀌며, 한눈에 흐름을 보고 싶을 때만 쓰면 됩니다.

간단한 보드는 이렇게 나눌 수 있습니다.

## 할 일
- 제안서 목차 작성
- 경쟁 서비스 조사
- 예상 일정 초안 작성

## 진행 중
- 사용자 문제 정리

## 대기
- 디자인팀 화면 예시 요청

## 완료
- 프로젝트 개요 작성

Kanban 보드의 장점은 병목을 보기 쉽다는 점입니다. 진행 중에 카드가 너무 많으면 집중이 분산된 것입니다. 대기에 카드가 오래 머물면 다른 사람의 답변이나 외부 자료가 막고 있는 것입니다.

반대로 작업이 5개 이하인 작은 프로젝트라면 다음 행동.md의 체크박스만으로 충분합니다. 플러그인은 문제를 해결하기 위해 쓰는 것이지, 시스템을 멋지게 보이게 하려고 쓰는 것이 아닙니다.

Daily Notes와 프로젝트 노트를 연결하기

하루의 업무는 Daily Notes에서 시작하고, 프로젝트의 맥락은 프로젝트 노트에 남기는 방식이 유지하기 쉽습니다.

아침에는 Daily Notes에 오늘 할 일을 적습니다.

## 오늘의 우선순위
- [ ] [[신규 서비스 제안서]] 목차 초안 작성
- [ ] [[신규 서비스 제안서]] 관련 회의 준비

업무 중 생긴 세부 기록은 Daily Notes에 빠르게 적어도 됩니다.

## 업무 로그
- 제안서 첫 장은 사용자 문제 중심으로 바꾸는 편이 좋겠다.
- 팀장은 일정표보다 핵심 기능 정의를 먼저 보고 싶어 한다.

하루가 끝날 때 중요한 내용만 프로젝트 노트로 옮기거나 링크합니다. 모든 기록을 복사할 필요는 없습니다. 결정, 피드백, 다음 행동처럼 나중에 다시 볼 가능성이 높은 것만 남기면 됩니다.

예를 들어 Daily Notes에 떠오른 생각이 프로젝트 방향을 바꾸는 내용이라면, 프로젝트 개요 노트의 현재 결정이나 결정 기록에 옮깁니다. 단순한 업무 로그라면 Daily Notes에 그대로 두고 프로젝트 노트에서 해당 날짜만 링크해도 충분합니다.

이렇게 하면 Daily Notes는 하루의 흐름을 보존하고, 프로젝트 노트는 결과물을 완성하는 데 필요한 맥락을 보존합니다.

완료된 프로젝트를 Archives로 옮기기

프로젝트가 끝나면 폴더를 그대로 두지 말고 정리합니다. 완료된 프로젝트가 10_Projects에 계속 남아 있으면 현재 진행 중인 일과 섞여 집중을 방해합니다.

완료 처리의 기본 순서는 간단합니다.

1. 프로젝트 개요 노트에 최종 상태를 적습니다.

2. 결과물 링크를 남깁니다.

3. 다시 쓸 지식과 단순 보관 자료를 구분합니다.

4. 프로젝트 폴더를 90_Archive로 옮깁니다.

예시는 다음과 같습니다.

---
type: project
status: 완료
due: 2026-07-10
completed: 2026-07-08
---

## 최종 결과
- 제안서 1차 제출 완료
- 기획 회의에서 기능 범위 축소 결정

## 배운 점
- 초안 단계에서는 시장 분석보다 사용자 문제 정의가 먼저 필요했다.
- 피드백을 받을 때는 목차보다 핵심 주장 3개를 먼저 보여 주는 편이 효과적이었다.

## 재사용할 노트
- [[제안서 작성 체크리스트]]
- [[사용자 문제를 먼저 설명하는 방식]]

여기서 중요한 기준은 "나중에 다시 쓸 수 있는가?"입니다. 회의 일정, 임시 파일, 중간 버전은 Archives에 보관해도 됩니다. 하지만 제안서 작성법, 의사결정 기준, 자주 쓰는 체크리스트는 Resources나 관련 MOC에 연결해 두는 편이 좋습니다.

프로젝트는 끝나도 지식은 남습니다. 옵시디언의 장점은 바로 이 지점에 있습니다. 실행의 흔적을 단순히 보관하는 데서 끝내지 않고, 다음 실행에 쓸 수 있는 지식으로 바꿀 수 있습니다.

작게 시작하는 프로젝트 운영 규칙

처음부터 완벽한 프로젝트 대시보드를 만들려고 하지 마세요. 다음 네 가지 규칙이면 충분합니다.

• 진행 중인 프로젝트마다 개요 노트를 하나 만든다.

• 할 일은 체크박스로 쓰고, 중요한 일은 다음 행동.md에 모은다.

• 다음 행동에는 가능하면 원래 회의록이나 자료 노트 링크를 함께 남긴다.

• 결정 사항은 날짜와 이유를 함께 남긴다.

• 완료된 프로젝트는 Archives로 옮기고, 재사용할 지식은 Resources에 연결한다.

옵시디언의 프로젝트 관리는 빠른 실행과 긴 기억을 함께 다루는 방식입니다. 오늘 해야 할 일을 놓치지 않으면서, 왜 그런 선택을 했는지도 남깁니다. 이 균형이 잡히면 노트는 단순한 기록장이 아니라 일을 끝까지 밀고 가는 작업 공간이 됩니다.