🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Obsidian 대시보드는 정보를 새로 저장하는 공간이 아니라, 볼트 곳곳의 프로젝트·태스크·고객·일일 노트를 읽어 오늘 중요한 일을 한 화면에 자동으로 보여주는 업무 운영 레이어다.

📌 핵심 요약

• 저자의 핵심 주장은 아침마다 이메일, Slack, 캘린더, 프로젝트 폴더를 오가며 사람이 직접 정보를 통합하는 방식이 업무 시작을 늦춘다는 것이다.
• Obsidian 대시보드의 핵심 원칙은 “저장하지 않고 읽기”이며, Dataview와 일관된 속성 구조를 통해 관련 정보를 자동으로 끌어온다.
• 대시보드는 오늘의 우선순위, 활성 프로젝트, 7일 내 마감, 고객 상태, 전날의 열린 항목, 매출 흐름을 한 노트에 모아 보여준다.
• Claude Code와 Filesystem MCP를 연결하면 표 형태의 데이터를 자연어 아침 브리핑으로 요약하고, 완료 기록을 바탕으로 프로젝트 속성 업데이트까지 자동화할 수 있다.
• 단, 이 시스템의 정확도는 각 노트의 속성명, 날짜 형식, 상태값, OPEN: 같은 기록 규칙을 얼마나 꾸준히 유지하느냐에 달려 있다.

🧩 주요 포인트

1. 대시보드는 새로운 정보 저장소가 아니라 기존 노트의 구조화된 정보를 실시간으로 읽는 인터페이스다.
2. Dataview와 YAML properties가 핵심 기술 기반이며, 속성명이 정확히 일치해야 쿼리가 제대로 작동한다.
3. 업무 대시보드에는 오늘 해야 할 일, 프로젝트 진행률, 임박한 마감, 고객 건강도, 미해결 루프, MRR 흐름이 포함된다.
4. Claude Code를 연결하면 대시보드의 데이터가 “무엇을 의미하는지”를 300자 안팎의 아침 브리핑으로 받을 수 있다.
5. 장기적인 가치는 도구 자체보다 속성 업데이트, 일일 노트 규칙, 하루 종료 리뷰 같은 운영 습관에서 나온다.

🧠 상세 정리

1. 문제의식: 아침 업무의 병목은 정보 부족이 아니라 정보 통합이다

원문은 대부분의 사람들이 업무를 시작할 때 이메일을 열고, Slack을 확인하고, 프로젝트 폴더를 뒤지고, 캘린더와 태스크 목록을 보며 “오늘 무엇을 해야 하는지”를 머릿속에서 조립한다고 진단한다. 이 과정은 정보가 없어서 생기는 문제가 아니다. 프로젝트 노트, 고객 파일, 일일 노트, 태스크 목록, 캘린더에 정보는 이미 존재한다. 저자의 thesis는 분명하다. 문제는 사람이 이 모든 정보 사이의 통합 레이어가 되어야 한다는 점이다. 사용자가 직접 맥락을 연결하고 우선순위를 판단하는 동안 아침 45분이 사라지고, 하루의 시작은 이미 흔들린다. Obsidian 대시보드는 이 역할을 사람에게서 떼어내 한 개의 노트가 대신 수행하도록 만드는 장치로 제시된다.

2. 핵심 원칙: 대시보드는 “저장”하지 않고 “읽는다”

저자가 가장 강조하는 원칙은 “Read Not Store”다. Obsidian 대시보드는 또 하나의 입력 공간이 아니다. 새로운 정보를 별도로 기록하는 장소가 아니라, 볼트 안의 다른 노트에서 조건에 맞는 정보를 읽어와 지금 필요한 것만 보여주는 노트다. 이 차이는 중요하다. 대시보드가 자체 콘텐츠를 저장한다면 사용자는 프로젝트 파일도 업데이트하고 대시보드도 다시 고쳐야 한다. 반대로 대시보드가 쿼리로만 구성되어 있다면, 프로젝트 노트나 고객 노트의 속성을 한 번 업데이트하는 것만으로 대시보드가 자동 반영된다. 저자에게 대시보드의 가치는 “한 번 업데이트하면 여러 화면에서 최신 상태가 유지되는 구조”에 있다.

3. 기술 기반: Dataview와 일관된 properties가 시스템을 움직인다

원문에서 제시하는 기술 기반은 복잡하지 않다. 핵심은 Obsidian 커뮤니티 플러그인인 Dataview와 각 노트 상단의 YAML properties다. Dataview는 볼트 안의 노트를 쿼리하는 엔진처럼 작동하며, 속성·태그·본문 조건을 기준으로 결과를 노트 안에 렌더링한다. 하지만 단순한 설치보다 중요한 것은 구조의 일관성이다. 예를 들어 태스크 노트에는 type, status, priority, due 같은 속성이 필요하고, 프로젝트 노트에는 deadline, completion, next_action 같은 속성이 필요하다. 쿼리에서 참조하는 속성명과 실제 노트의 속성명이 정확히 일치하지 않으면 해당 노트는 결과에서 빠진다. 저자는 이 점을 통해 대시보드의 신뢰성이 도구보다 데이터 규율에 좌우된다고 본다.

4. 대시보드가 보여줘야 할 여섯 가지 업무 신호

저자는 완성된 비즈니스 대시보드가 여섯 가지 정보를 보여줘야 한다고 제안한다. 첫째는 오늘이거나 이미 지난 마감의 미완료 태스크다. 이 목록은 우선순위와 마감일 기준으로 정렬되고 10개로 제한된다. 저자는 40개의 지연 태스크를 보여주는 대시보드는 명확성보다 불안을 만든다고 본다. 둘째는 활성 프로젝트다. 각 프로젝트의 고객, 진행률, 마감일, 다음 행동을 한 표에서 확인하게 한다. 특히 next_action 속성을 가장 중요한 열로 본다. 프로젝트 파일을 열지 않아도 지금 무엇이 필요한지 알 수 있기 때문이다. 셋째는 향후 7일 내 마감이다. 프로젝트, 태스크, 고객 산출물 등 노트 유형을 가리지 않고 가까운 마감을 한 화면에 모아 사전 대응을 가능하게 한다.

5. 고객 관계와 매출 흐름을 업무 맥락 안에 포함한다

네 번째 섹션은 Client Health Monitor다. active 상태의 고객을 health, mrr, last_contact, next_touchpoint 기준으로 보여주고, 위험한 고객이 위에 오도록 정렬한다. 원문은 health 값을 healthy, attention, atrisk 세 가지로 유지하라고 제안한다. 이 방식은 CRM을 별도로 열어 수동 점검하는 시간을 줄이고, “지금 연락해야 할 고객”을 자동으로 드러내는 목적을 가진다. 여섯 번째 섹션인 Revenue Pulse는 활성 고객을 월 반복 매출 기여도 기준으로 보여주고 총 MRR을 인라인 계산으로 표시한다. 저자는 이를 스프레드시트나 수동 계산 없이 현재 매출 그림을 15초 안에 파악하는 방식으로 설명한다. 다만 이 기능이 작동하려면 mrr 값이 문자열이 아니라 숫자여야 한다는 전제가 있다.

6. OPEN: 규칙은 공식 태스크 밖의 미해결 항목을 붙잡는다

다섯 번째 섹션은 Open Loops다. 원문은 일일 노트에서 다음 날 다시 떠올려야 할 항목 앞에 OPEN: 접두어를 붙이는 간단한 규칙을 제안한다. 그러면 어제의 daily note에서 OPEN:이 붙은 항목을 Dataview가 찾아 오늘의 대시보드에 표시한다. 이 방식이 중요한 이유는 모든 중요한 일이 공식 태스크로 등록되지는 않기 때문이다. “제안서 후속 연락”, “콘텐츠 방향 결정”, “계약 조건 검토”처럼 중요하지만 별도 태스크 시스템에 넣기 애매한 항목들이 있다. 저자는 이런 항목이 기존 시스템에서 쉽게 누락된다고 보고, OPEN: 규칙을 통해 기억에 의존하지 않는 이월 장치를 만들자고 주장한다.

7. Claude Code 연결은 데이터를 브리핑으로 바꾼다

원문은 기본 대시보드만으로도 유용하지만, Claude Code와 Filesystem MCP를 연결하면 아침 경험이 바뀐다고 주장한다. 핵심은 표를 사람이 직접 해석하는 대신 Claude가 대시보드와 참조 파일을 읽고 자연어 브리핑을 생성하는 것이다. 브리핑은 오늘 가장 중요한 일, 정오 전 주의해야 할 일, 오늘 처리하지 않으면 위험한 것, 가장 신경 써야 할 고객 관계, 시작 전 결정해야 할 한 가지를 알려준다. 여기서 차이는 “데이터가 무엇을 보여주는가”가 아니라 “그 데이터가 오늘 무엇을 의미하는가”를 말하게 하는 데 있다. 저자는 N8N을 통해 매일 오전 6시에 이 브리핑이 자동 생성되어 일일 노트에 들어가는 흐름을 제안한다. 사용자는 노트북을 열기 전에 180단어 안팎의 요약으로 하루의 초점을 잡고, 이후 대시보드 표와 대조해 우선순위를 확인한다.

8. 자동화의 전제는 꾸준한 데이터 관리 습관이다

저자는 대시보드의 즉각적인 효용을 강조하지만, 동시에 정확도는 밑바탕 데이터에 달려 있다고 말한다. 프로젝트가 완료되면 status를 바로 바꾸고, 고객 상태가 달라지면 health를 그날 업데이트해야 한다. 속성이 낡으면 대시보드도 낡은 현실을 보여준다. 또한 OPEN: 규칙을 꾸준히 쓰고, 하루 시작뿐 아니라 하루 끝에도 3분 정도 대시보드를 점검하라고 제안한다. 오후 5시에 다섯 개의 속성을 업데이트해 두면 다음 날 오전 6시 브리핑이 더 정확해진다는 설명이다. 즉 이 시스템의 본질은 한 번 만든 템플릿이 아니라, 매일 조금씩 현실과 노트를 맞추는 운영 리듬에 있다.

9. 기존 방식과의 차이: 여러 도구를 확인하는 아침에서 한 노트로 시작하는 아침으로

기존 방식에서는 사용자가 이메일, Slack, 캘린더, 프로젝트 폴더, 태스크 목록을 오가며 오늘의 맥락을 복원한다. 정보는 흩어져 있고, 우선순위 판단은 매일 아침 새로 수행된다. 저자는 이 과정을 “사람이 통합 레이어가 되는 상태”로 본다. Obsidian 대시보드 방식은 반대다. 사용자는 한 개의 Dashboard.md를 열고, 그 안에서 프로젝트·태스크·고객·일일 노트·매출 정보를 함께 본다. Claude Code까지 연결되면 표를 읽기 전 자연어 브리핑이 먼저 도착한다. 이 변화의 핵심은 생산성 도구를 하나 더 추가하는 것이 아니라, 업무 판단에 필요한 신호를 한 곳으로 모아 아침의 방향 설정 비용을 줄이는 데 있다.

10. 반론 가능성: 자동 대시보드는 구조화된 노트 습관이 없으면 쉽게 무너진다

원문은 대시보드의 장점을 강하게 말하지만, 그 안에는 몇 가지 전제가 있다. 우선 사용자의 Obsidian 볼트가 프로젝트, 태스크, 고객, 일일 노트처럼 구분되어 있어야 한다. 또한 각 노트가 YAML properties를 갖고 있어야 하며, 속성명과 값 형식이 일관되어야 한다. 이런 기반이 없는 상태에서는 대시보드 구축보다 먼저 노트 구조 정리가 필요하다. 또 다른 한계는 자동화가 잘못된 데이터를 더 빠르게 보여줄 수도 있다는 점이다. 오래된 status, 잘못된 due date, 문자열로 입력된 mrr, 형식이 어긋난 날짜는 결과를 비우거나 왜곡한다. 따라서 이 방식은 “설정만 하면 끝나는 자동화”라기보다, 구조화된 기록을 이미 하거나 앞으로 할 의지가 있는 사람에게 더 적합한 시스템으로 해석할 수 있다.

🧾 핵심 주장 / 시사점

• Obsidian 대시보드의 본질은 정보를 한 곳에 복사하는 것이 아니라, 기존 노트를 쿼리해 오늘 중요한 신호만 보여주는 것이다.
• 업무 시작 시간을 줄이려면 더 많은 앱이 아니라, 흩어진 정보를 자동으로 연결하는 읽기 중심 인터페이스가 필요하다.
• Dataview 기반 대시보드는 단순하지만, 속성명·날짜 형식·상태값의 일관성이 없으면 신뢰성을 잃는다.
• Claude Code와 MCP 연결은 대시보드를 표 중심 관리 화면에서 의미 중심 아침 브리핑 시스템으로 확장한다.
• 장기 효과는 도구 설치보다 매일 속성을 갱신하고 열린 항목을 이월하는 운영 습관에서 나온다.

✅ 액션 아이템

• Obsidian에 Dataview 플러그인을 설치하고, Dashboard.md를 볼트 루트에 생성할지 검토한다.
• 프로젝트, 태스크, 고객, 일일 노트에 사용할 type, status, priority, due, deadline, health, mrr 같은 공통 properties 목록을 먼저 정의한다.
• 일일 노트에 다음 날 다시 확인해야 할 항목을 OPEN: 접두어로 남기는 규칙을 도입한다.
• Claude Code와 Filesystem MCP를 사용할 경우, 대시보드와 참조 파일을 읽어 300단어 이하 아침 브리핑을 생성하는 프롬프트를 별도로 준비한다.

❓ 열린 질문

• 현재 Obsidian 볼트의 노트 구조가 Dataview 쿼리를 안정적으로 실행할 만큼 일관된 properties를 갖추고 있는가?
• 저자가 제안한 여섯 섹션 중 실제 업무에 꼭 필요한 항목과 제외해도 되는 항목은 무엇인가?
• Claude Code가 프로젝트 속성을 자동 업데이트하도록 할 때, 잘못된 파일 수정이나 상태 오판을 막기 위한 검토 절차는 어떻게 둘 것인가?