Obsidian 지식 관리 구조 설계 정리

📌 Summary

이 문서는 Obsidian을 통한 개인 지식 관리 시스템의 구조와 운영 원칙을 정리한 것입니다.

🏗️ 기본 구조

최상위 폴더 구성

최상위 폴더 구성 예시: Top-Level Folder Structure

Projects (🏗️)
- 명확한 목표와 기한이 있는 프로젝트
- 완료 시 Archive로 이동, 핵심 지식은 추출하여 Areas/Resources에 저장
- 앱 개발, 연구 프로젝트, 기술 커스터마이징 등
Areas (💼)
- 지속적 관리가 필요한 영역
- 각 영역별 MOC 문서로 구조화
- Business, Development, Research, Writing 등
Resources (📚) → Resources Folder Guide
- 참고용 영구 지식 저장소
- 조직 정보, 도구 설명서, 참고자료 등
- 빠른 참조가 가능한 구조화
Archive (🗃️)
- 연도별 구조로 완료된 프로젝트 보관
- 원본 구조(Projects/Areas/Resources) 유지
- 메타데이터를 통한 문서 이력 관리

최상위 폴더 간 애매한 구분

Projects vs Areas

Projects: 명확한 완료 시점이 있는 활동
Areas: 지속적인 관리/발전이 필요한 영역

애매한 예시: 블로그 운영
/Areas/Blog/
  blog-moc.md
  content-calendar.md
  style-guide.md
  
/Projects/BlogRedesign/
  redesign-plan.md
  new-features.md
  migration-checklist.md

Resources vs Areas

Resources: 참고용 영구 지식, 변경이 적은 컨텐츠
Areas: 실천/실행 중심의 활용 지식

애매한 예시: 요리 레시피
/Resources/Cooking/
  basic-techniques.md
  standard-recipes/
 
/Areas/Cooking/
  cooking-moc.md
  meal-plans/
  recipe-experiments/
  shopping-lists/

📋 문서 관리 원칙

메타데이터 관리

---
title: 문서 제목
publish: true/false
category: business/development/research/writing
tags: [관련_태그들]
status: draft/in-progress/completed
created: YYYY-MM-DD
updated: YYYY-MM-DD
---

태그 체계

상태 태그
- draft review publish
영역 태그
- business dev research writing
프로젝트 태그
- app research tech
컨텐츠 타입
- tutorial review analysis diary creative

🔄 문서 이동 원칙

1. 유연성과 확장성의 예시

시나리오 A: 취미가 프로젝트화 되는 경우

초기: /Areas/Hobby/Painting/ 아래에 기본적인 그림 학습 노트들
전개: 개인전을 준비하기로 결정

/Areas/Hobby/Painting/
  painting-moc.md
  techniques.md
  inspiration.md
  
/Projects/FirstExhibition/
  exhibition-plan.md
  artwork-progress/
  venue-research.md

완료 후: 전시 관련 문서들은 /Archive/FirstExhibition/으로 이동
학습된 기술과 인사이트는 다시 /Areas/Hobby/Painting/에 영구 지식으로 통합

시나리오 B: 관심사가 확장되는 경우

/Resources/Programming/
  python-basics.md
  → 파이썬 학습 시작
 
/Areas/Programming/
  programming-moc.md
  python/
    projects/
    learning-path.md
  → 파이썬을 주력으로 사용하기 시작
 
/Projects/PythonAutomation/
  project-spec.md
  scripts/
  → 업무 자동화 프로젝트 시작

2. 문서 이동 원칙

문서 이동의 주요 패턴

Project → Archive

- 조건: 프로젝트 완료
- 이동 전: /Projects/BlogRedesign/
- 이동 후: /Archive/2024/BlogRedesign/
- 핵심 지식은 추출하여 Areas나 Resources로 이동

Areas → Projects

- 조건: 특정 목표나 기한이 생긴 경우
- 예시: 취미 → 프로젝트
/Areas/Writing/daily-practice/ 
  → /Projects/FirstNovel/

Projects → Resources

- 조건: 프로젝트에서 얻은 재사용 가능한 지식
- 예시: 프로젝트 회고, 기술 문서

아카이브 문서 이동 원칙

아카이브 구조화 원칙:

연도별 구분
원본 구조 유지 (Projects/Areas/Resources)
메타데이터 추가

Projects → Archive

프로젝트 완료 시 전체 이동
핵심 지식 추출 후 Areas/Resources에 재배치
연도별 폴더에 원본 구조 유지하며 저장

예시:
django-business-manager/ (완료)
→ Archive/2024/Projects/django-business-manager/
+ Areas/Development/python/django-best-practices.md (추출된 지식)

Areas → Archive

더 이상 유효하지 않은 프로세스/가이드
새 버전으로 대체된 문서
관련성이 떨어진 과거 자료

예시:
Areas/Business/old-pricing-strategy.md
→ Archive/2024/Areas/Business/old-pricing-strategy.md

Resources → Archive

오래된 참조 자료
더 이상 관련 없는 정보
업데이트된 새 버전이 있는 자료

예시:
Resources/Organizations/outdated-partner-list.md
→ Archive/2024/Resources/Organizations/outdated-partner-list.md

📚 MOC(Map of Content) 관리

MOC 구성 원칙

명확한 Overview 제공
논리적 계층 구조 설계
관련 문서 간 상호 연결
확장 가능한 구조 유지
시각적 구분을 위한 이모지 활용

주요 MOC 문서

business-moc.md
dev-moc.md
research-moc.md
writing-moc.md

💡 운영 팁

문서 작성 시
- 적절한 위치 선정 (Projects vs Areas vs Resources)
- 완전한 메타데이터 포함
- 관련 문서들과 연결 (링크/태그)
지식 관리 시
- 정기적인 리뷰와 정리
- MOC 문서 지속적 업데이트
- 태그 체계 일관성 유지
확장 시
- 기존 구조 활용 가능 여부 검토
- 필요시 새 카테고리 추가
- MOC 문서에 반영

🎯 기대 효과

체계적인 지식 관리
효율적인 정보 검색
지식의 진화 추적
퍼블리싱 용이성
유연한 확장성

📝 Notes

이 구조는 시작점이며, 사용하면서 필요에 따라 조정 가능
정기적인 리뷰를 통한 구조 최적화 필요
새로운 요구사항에 따른 유연한 확장 고려

Gurumii Lab

Explorer