Obsidian + LLM + Bases로 구축하는 「개발 프로젝트의 외부 뇌」: 프로퍼티 주도형 안건 관리술

「특정한 툴은 사용하지 않고 있습니다. 팀원이 몇 명 안 돼서 지금까지는 사람의 역량에 의존해 어떻게든 해결해 왔습니다.」

SI 안건을 맡고 있는 PM이라면 비슷한 상황에 공감할지도 모릅니다. 상담에서 시작하여 견적·수발주·요건 정의·설계·구현·테스트·검수·유지보수까지, 11개 공정에 걸친 안건 라이프사이클(Lifecycle)을 Excel이나 메모, 그리고 멤버들의 머릿속에서 돌리고 있는 상태입니다.

이를 AI와 연계하여 효율화할 수 없을까—— 그렇게 생각하며 Obsidian을 시도해 본 결과, 생각보다 깊은 수준까지 실용화할 수 있었습니다. 포인트는 2025년에 Obsidian 코어에 추가된 신기능 「Bases」입니다.

이 기사에서는 실제로 구축한 Vault의 설계 사상과 Dataview·AI (Claude)와의 역할 분담, 그리고 시행착오의 과정을 정리합니다.

툴	버전 기준
Obsidian	1.8 이후 (Bases 대응)
...
SI 안건에는 고객명·금액·미공개 사양과 같은 기밀 정보가 자연스럽게 포함됩니다. SaaS 프로젝트 관리 툴에 그대로 던져 넣는 것은 리스크가 있습니다.

Obsidian은 **로컬 퍼스트 (Local-first)**입니다. 모든 데이터는 PC 위의 Markdown 파일로 저장됩니다. Claude를 사용할 때도, Cowork (데스크톱 앱)의 로컬 에이전트 모드로 동작시키면 파일을 클라우드에 올리지 않고도 AI가 읽고 쓰게 할 수 있습니다.

Obsidian의 노트는 .md 파일입니다. AI에게 이것은 그대로 읽고 쓸 수 있는 플랫한 텍스트입니다.

특히 중요한 것이 **YAML 프론트매터 (YAML Frontmatter)**입니다.

---
type: project
status: in_progress
...

이 프로퍼티(Property) 정보가 있다면, AI는 「어떤 프로젝트가, 지금 어느 페이즈(Phase)에 있고, 담당자는 누구이며, 기한은 언제인지」를 순식간에 파악할 수 있습니다. 자연어 본문을 읽기 전에 메타데이터만으로 컨텍스트(Context)를 파악할 수 있는 것이 강점입니다.

Obsidian은 「무엇이든 Obsidian으로 옮기는」 툴이 아니라, 색인·상태 관리·AI 입력 측면으로 사용합니다.

툴	역할
Google Drive	계약서·사양서 PDF·견적 Excel 등의 Master 정본
SVN / Git	소스 코드 관리 (변함없음)
Obsidian	상태 추적·회의록·과제·유지보수 티켓·AI를 위한 문맥 허브

Drive와 SVN은 그대로 남겨둡니다. Obsidian은 그곳으로의 링크와 상태를 YAML로 가집니다. 이 역할 분담을 처음에 결정하는 것이 중요합니다.

실제로 구축한 폴더 구성은 다음과 같습니다.

프로젝트 관리/
├── 00_Index/ ← MOC・Base 파일 (조망용)
│ ├── 안건MOC.md
...

설계의 포인트는 「안건 폴더 = 서브 폴더 10개」의 고정 구조입니다. 모든 안건이 동일한 구조를 가짐으로써, Claude가 「이 Vault의 패턴」을 학습하여 처음 보는 안건이라도 올바른 경로에 기록할 수 있습니다.

03_Projects/_예시_안건A_수발주시스템/은 샘플 안건입니다. 신규 안건 생성 시의 참조처로서 남겨둡니다.

안건의 「상태 (Status)」는 두 축으로 관리합니다.

• status: 수주 프로세스상의 상태 (상담 중인지, 진행 중인지, 완료되었는지)
• phase: 개발 공정 (요건 정의 중인지, 구현 중인지)

이 두 축을 분리함으로써, 「수주 확정(status: in_progress)이지만 요건 정의 페이즈(phase: requirement)」라는 실태를 정확하게 표현할 수 있습니다.

---
type: project
status: in_progress # 수주 프로세스의 상태
...

status가 가질 수 있는 값은 다음과 같습니다.

status	의미
consultation	상담 중·개략 견적 전 (수주 미확정)
backlog	수주 확정되었으나 착수 전
in_progress	진행 중
review	고객·사내 리뷰 대기
blocked	고객 답변 대기 등으로 정지
done	검수 완료
lost	실주
cancelled	중지
archived	아카이브됨

phase가 가질 수 있는 값은 estimate / requirement / design / implementation 입니다.

/ test

/ acceptance

/ maintenance

입니다.

안건 노트 이외에도 type 필드로 구분합니다.

# 과제 노트
type: issue
status: open # open / in_progress / review / done
...

이 type 필드가 후술할 Bases 쿼리의 기점이 됩니다. 모든 노트가 frontmatter라는 "공통 언어"를 갖는 것이 이 시스템 전체의 핵심입니다.

이 부분이 본 기사의 핵심 부분입니다.

Dataview는 오랫동안 Obsidian의 데팩토 표준(de facto standard)이었던 쿼리 플러그인입니다. frontmatter를 읽어 들여 조건에 따라 필터링, 집계, 테이블 표시를 할 수 있습니다.

-- 案件MOC.md 에 작성하는 Dataview 쿼리 예시
TABLE client AS "클라이언트", phase AS "페이즈", due AS "기한"
FROM "03_Projects"
...

강점: 표시 커스터마이징이 유연하며, 집계 및 GROUP BY가 가능함

약점: 읽기 전용(Read-only). 상태를 변경하려면 해당 노트를 열어 frontmatter를 직접 수동으로 수정해야 함

Bases는 2025년에 Obsidian 코어에 포함된 표준 기능입니다. Dataview와 마찬가지로 frontmatter를 쿼리하지만, 결정적인 차이가 있습니다.

Bases는 GUI를 통해 직접 frontmatter를 편집할 수 있습니다.

테이블의 셀을 클릭하여 status를 수정하거나, 카드 뷰에서 열 사이를 드래그하는 것만으로 노트의 frontmatter가 업데이트됩니다. Claude를 거칠 필요도 없고, 파일을 열 필요도 없습니다.

Bases는 YAML로 기술합니다. 실제 안건 보드는 다음과 같습니다.

# 00_Index/案件ボード.base
filters:
and:
...

주의사항: Bases의 필터 식은 == (Dataview는 =)입니다. 이 부분을 틀리면 뷰가 비어 있게 됩니다. 실제로 제가 빠졌던 함정입니다.

용도	사용하는 것
일상적인 상태 변경	Bases
...	둘 다 (동일한 frontmatter를 참조하기 때문)

Bases에서 상태를 업데이트하면 Dataview의 MOC에도 자동으로 반영됩니다. 데이터 소스가 동일한 frontmatter이기 때문입니다.

안건별 00_案件サマリ.md는 다음과 같은 구성으로 하고 있습니다.

---
type: project
status: in_progress
...
```dataview
TABLE ... WHERE type = "issue" AND contains(project, this.file.link) AND status != "done"

TABLE ... WHERE type = "maintenance" AND contains(project, this.file.link)

TABLE ... FROM "03_Projects" WHERE contains(project, this.file.link) SORT file.mtime DESC LIMIT 10

• 2026-05-01: 킥오프. 스코프 확정.
• 2026-05-15: 기본 설계 리뷰 완료.
  ...

**포인트는 "자동 집계 섹션"입니다.** 이 노트를 여는 것만으로 안건에 연결된 과제, 유지보수 티켓, 최근 동향이 일람됩니다. Claude에게 "안건 A의 현황을 알려줘"라고 요청할 때, 이 요약 노트를 읽게 하면 충분한 컨텍스트(Context)를 전달할 수 있습니다.

## CLAUDE.md가 "시스템 프롬프트"가 된다
Vault 직하에 둔 `CLAUDE.md`는 Claude가 이 폴더를 열 때마다 자동으로 읽힙니다. 여기에 운영 규칙을 적어둠으로써 매번 설명할 필요가 없어집니다.
가장 효과적이었던 것은 **자연어 → frontmatter 매핑 표**입니다.

```markdown
## 자연어 → frontmatter 매핑 (안건)
| 자연어 표현 | status | phase | 비고 |
|---|---|---|---|
...

이것이 있으면 「고객 A가 발주를 확정했다」라는 문장을 받은 Claude가 status: in_progress, phase: requirement로 자동 변환하여 frontmatter를 업데이트해 줍니다.

또한 CLAUDE.md에는 Claude의 **비용 절감 규칙 (Cost Reduction Rules)**도 작성해 두었습니다.

## Claude의 작업 원칙 (비용·품질)
1. 템플릿을 매번 읽지 않는다. CLAUDE.md의 규약에 따라 직접 작성한다.
2. 상태 변경(Status change)만 요청하는 경우에는 파일 전체를 읽지 않고 편집한다.
...

이렇게 작성하는 것만으로도 상태 변경 1건당 소모되는 토큰(Token) 양이 대폭 줄어듭니다.

Vault를 구축할 때, Cowork(Claude의 데스크톱 AI 에이전트)에게 "이 폴더에 작성해 줘"라고 지시했습니다. 그런데 잠시 작업한 후 확인해 보니, 파일이 프로젝트 관리 (1)라는 폴더에 작성되어 있었습니다.

프로젝트 관리와 프로젝트 관리 (1)라는, 미묘하게 다른 이름의 두 폴더가 나란히 놓여 있는 상태였습니다. 원인은 Cowork의 폴더 연결 시 잘못된 경로(Path)로 권한을 허용했기 때문이었습니다.

교훈: Cowork에서 폴더를 연결할 때는 경로를 터미널에서 확인한 후 허용할 것. 연결 후에도 처음 몇 개의 파일이 올바른 위치에 작성되고 있는지 확인할 것.

처음에는 Dataview만으로 운용하며 상태 변경도 Claude에게 요청했습니다. 안건을 1건 등록할 때마다 Claude는 템플릿을 읽고 → 기존 안건의 폴더 구조를 읽고 → 요약(Summary)을 쓰고 → 관련 파일도 업데이트하는 등 대량의 파일을 읽어 들입니다.

체감상 안건 1건 등록 시 입력 토큰(Input Token) 1020k, 출력 토큰(Output Token) 23k 정도를 소비했습니다. 안건이 늘어나면 상태 변경을 할 때마다 매번 이 정도의 양이 발생합니다.

"이 Vault를 Claude로 계속 돌리다가는 비용이 감당 안 되지 않을까?"라고 느낀 시점에, Bases로의 전환을 검토했습니다.

해결: 일상적인 상태 변경은 Bases의 GUI에서 직접 수행한다. Claude에게 요청하는 것은 "템플릿 전개만으로는 끝나지 않는 작업" (신규 안건 기안, 회의록 정리, 주간 보고서 작성 등)으로 한정한다.

이렇게 역할 분담을 한 이후로 Claude 이용은 일주일에 몇 번 정도의 집중적인 작업으로 줄어들었고, 비용이 안정되었습니다.

Bases의 필터 식(Filter expression)에 Dataview 습관대로 =를 쓰면 뷰(View)가 비어 있게 됩니다.

# ❌ Dataview 습관대로 써버리는 패턴
filters:
- status = "in_progress"
...

또한, Bases는 카드 뷰(Card view)의 그룹화(Grouping)에 Dataview와 다른 키(Key) 이름을 사용합니다. groupBy.property에 frontmatter의 키 이름을 그대로 지정하기만 하면 됩니다.

Dataview+Claude의 고비용 문제를 겪은 후, CLAUDE.md에 토큰 절약 규칙을 명시했더니 Claude 스스로가 그에 따라 "이 상태 변경은 1행만 교체하겠습니다"라고 판단하여 움직이게 되었습니다.

인간이 규칙을 써두면 AI가 자율적으로 비용 최적화된 움직임을 보인다—이러한 감각은 CLAUDE.md를 키워나가는 동기부여가 됩니다.

Obsidian을 실행하고, 설정(Settings) → 커뮤니티 플러그인(Community plugins)에서 다음을 설치 및 활성화합니다.

플러그인	용도	필수도
Dataview	MOC 쿼리 표시	필수
Templater	템플릿으로부터 노트 생성	권장
Kanban Bases View	Bases에 Kanban 뷰 추가	권장

Bases는 버전 1.8 이후의 Obsidian에 표준 탑재되어 있습니다. 커뮤니티 플러그인 설치가 필요 없습니다.

Obsidian의 "New folder"로 폴더를 생성합니다. 명명 규칙은 숫자 접두사(00_ ~ 06_)를 사용하여 정렬 순서를 고정합니다.

Vault 직하단에 CLAUDE.md를 생성합니다. 최소한 아래 내용을 작성해 둡니다.

# 이 Vault의 Claude 규칙
## 폴더 규약
- 00_Index/: MOC·Base 파일
...

02_Templates/안건_템플릿.md를 생성합니다. Templater를 사용하는 경우의 형식은 다음과 같습니다.

<%*
const today = tp.date.now("YYYY-MM-DD");
-%>
...

TABLE WITHOUT ID file.link AS "과제", severity AS "중요도", due AS "기한"
FROM "03_Projects"
WHERE type = "issue" AND contains(project, this.file.link) AND status != "done"
SORT severity ASC, due ASC

## 단계 5: Base 파일 만들기
`00_Index/案件ボード.base`를 생성하고 앞서 언급한 YAML을 붙여넣습니다. Obsidian에서 열면 뷰(View)가 자동으로 생성됩니다.
Kanban Bases View를 설치한 경우, 「+ Add view」에서 Kanban 뷰를 추가하고 `groupBy`에 `status`를 지정하면 드래그로 상태를 변경할 수 있는 칸반(Kanban) 보드가 됩니다.
---
# 8. 정형 프롬프트 모음: AI를 효과적으로 사용하기
CLAUDE.md를 정비한 후에 유효했던 정형 프롬프트를 소개합니다.
**안건의 현황 요약 (주간 리뷰 전)**

03_Projects/[안건명]/ 하위를 읽고, 현재 상태를 A4 1페이지 분량으로 요약해줘.

...

**회의 메모를 요구사항 정의 노트로 정형화**

05_Inbox/[날짜]_요건_히어링.md의 내용을 읽고,

...

**유지보수 티켓 트리아지 (Triage)**

04_Maintenance/ 하위의 status: backlog 또는 in_progress인 티켓을 읽고,

...

---
# 9. 이 시스템의 한계와 다음 단계
## 적합하지 않은 케이스
- **일 단위·시간 단위로 상태가 변하는 태스크 관리**: 본 시스템은 수 주~수개월 단위로 움직이는 SI 안건에 최적화되어 있습니다. 스프린트(Sprint) 태스크 보드에는 적합하지 않습니다.
- **10인 이상의 팀 공유**: Obsidian은 로컬 퍼스트(Local-first) 방식이므로 Git 동기화 등이 필요하며, 충돌(Conflict) 관리 비용이 상승합니다.
## 다음 단계
**Templater를 통한 자동 기표**: `Ctrl+Shift+N`으로 안건명만 입력하면, 템플릿으로부터 10개의 하위 폴더와 요약 노트가 한꺼번에 전개되는 구조를 만들 수 있습니다.
**Claude MCP를 통한 깊은 연동**: Obsidian의 MCP 서버를 사용하면 Claude가 파일 시스템에 직접 접근할 수 있어, Cowork보다 더욱 저비용으로 동작합니다.
**주간 리포트 자동화**: CLAUDE.md에 "매주 금요일 17시에 주간 리포트를 생성한다"라고 스케줄 지시를 작성하면 정기 실행을 설정할 수 있습니다 (Claude Cowork의 스케줄 태스크 기능).
---
# 마치며
Obsidian + Bases + Dataview + Claude.md의 조합으로 실현한 것은, **AI가 다루기 쉬운 형태로 안건 정보가 구조화된 시스템**입니다.
중요한 것은 "무엇을 AI에게 맡길 것인가"라는 역할 설계입니다.
- **Bases**: 상태 변경 등의 일상적인 조작 (AI 미사용 · 제로 토큰)
- **Dataview MOC**: 주간 조망 · 읽기용 자료 (AI 미사용)
- **Claude**: 회의 메모 정형화 · 주간 리포트 · 유사 안건 검색 등, 템플릿 전개만으로는 해결되지 않는 작업
처음부터 모든 것을 AI에게 맡기려 하면 비용이 많이 들어 지속하기 어렵습니다. "AI를 사용하지 않아도 되는 조작은 AI를 사용하지 않는다"라는 설계가, 오래 지속되는 외부 뇌의 조건이라고 느낍니다.
Vault 전체 파일 수는 현재 40개 정도로, 안건 2건과 유지보수 티켓 수 건을 등록한 상태입니다. 작게 시작하여 사용하면서 규칙을 키워나가는 것이 현실적인 접근법입니다.
CLAUDE.md에 작성한 규칙을 AI 스스로 지키며 동작하는 경험은, "우리만의 AI 에이전트"를 키우고 있다는 감각을 줍니다. 관심이 있다면 꼭 시도해 보시기 바랍니다.