이 글은 박사연구용 Obsidian 시스템을 정리하는 시리즈의 3편이다. 1편에서는 전체 구조와 운영 원칙을, 2편에서는 문헌 DB와 질문 노드를 정리했다. 이번 글에서는 그 위에 올라가는 실행 레이어를 다룬다. 핵심은 PhD Dashboard, 각 프로젝트 허브, 그리고 Publications 데이터베이스를 어떻게 역할 분리해서 운영하느냐다.

내가 원했던 것은 예쁜 홈 화면이 아니다. 박사과정의 여러 층위를 매일 빠르게 복원할 수 있는 조종석이 필요했다. 어떤 프로젝트가 진행 중인지, 오늘 무엇을 먼저 해야 하는지, 읽어야 할 논문은 무엇인지, 이미 낸 성과는 어떻게 쌓이고 있는지를 여러 노트를 돌아다니지 않고 한 화면에서 확인할 수 있어야 했다.

왜 최상위 조종석이 따로 필요한가

문헌 대시보드만으로는 박사과정의 일상 운영이 완성되지 않는다. 실제 하루는 대체로 아래 질문들로 시작된다.

  • 지금 활성 프로젝트는 무엇인가
  • 오늘 바로 처리해야 할 작업은 무엇인가
  • 내가 지금까지 낸 성과는 어디에 정리되어 있는가
  • 읽어야 할 논문 큐는 어느 정도 쌓여 있는가

이 질문이 네 군데에 흩어져 있으면 구조는 있어도 실행 속도는 느려진다. 그래서 PhD Dashboard는 단순한 링크 모음이 아니라, 박사과정의 현재 상태를 매일 갱신하는 상위 운영 화면이어야 한다.

PhD Dashboard를 네 개의 블록으로 단순화했다

현재 PhD Dashboard는 아래 네 블록으로만 구성되어 있다.

  1. Active Projects
  2. Today's Todo
  3. Publications
  4. Reading Queue

네 블록만 남긴 이유는 각 블록의 질문이 분명하기 때문이다. Active Projects는 지금 무엇이 움직이는지 보여주고, Today's Todo는 오늘 무엇을 잡고 갈지 적게 하며, Publications는 이미 낸 성과를 축적하고, Reading Queue는 아직 읽지 않은 근거를 상위 화면에 올려준다. 이 네 가지가 함께 있어야 연구의 현재와 축적이 한 화면에 잡힌다.

Active Projects는 상태를 다시 입력하지 않고 모아 보여준다

Active Projects는 04_Projects 아래의 프로젝트 허브를 Dataview로 다시 읽는 섹션이다. 여기서 중요한 것은 프로젝트를 다시 설명하는 것이 아니라, 프로젝트 허브에 이미 들어 있는 정보를 모아서 보여주는 데 있다.

현재 프로젝트 허브는 보통 아래 필드를 가진다.

  • project_stage
  • health
  • priority
  • current_focus
  • next_review
  • target_date

즉, PhD Dashboard는 원본 데이터를 복제하지 않고, 각 프로젝트 허브의 최신 상태를 상위에서 다시 보여주는 뷰다. 이런 구조여야 대시보드 업데이트가 별도 업무가 되지 않는다.

Today’s Todo는 가장 단순한 입력 인터페이스로 둔다

Today's Todo는 일부러 자동화를 많이 넣지 않았다. 박사과정에서 중요한 것은 완벽한 태스크 시스템보다, 오늘 실제로 잡고 갈 일을 빠르게 적는 것이다. 체크리스트를 대시보드 안에 직접 두면, 하루를 시작할 때 다른 노트로 이동할 필요가 없다.

이 방식의 장점은 단순하다.

  1. 입력 비용이 낮다.
  2. 오늘의 우선순위를 직접 다시 쓰게 된다.
  3. 다른 시스템과의 억지 연동 없이 바로 실행으로 넘어갈 수 있다.

Publications는 읽는 논문과 분리된 성과 DB다

02_Sources/Papers는 읽기와 정리를 위한 DB이고, 02_Sources/Publications는 이미 낸 성과를 기록하는 DB다. 둘을 분리한 이유는 역할이 다르기 때문이다.

읽기용 paper note에는 아래 정보가 중요하다.

  • reading_status
  • summary
  • limitations
  • topics
  • questions

반면 publication note에는 아래 정보가 더 중요하다.

  • publication_year
  • venue_short
  • venue
  • authors
  • pdf_url
  • doi_url
  • code_url

즉, publication note는 읽기 메모가 아니라 실적 기록 노트다.

Reading Queue는 문헌 DB의 현재형 상위 뷰다

Reading Queue는 공용 Papers 데이터베이스에서 reading_status != "done"인 항목만 가져오는 섹션이다. Literature Dashboard가 문헌 작업 전용 화면이라면, Reading Queue는 그중 아직 닫히지 않은 항목만 끌어올린 상위 뷰다.

이 구성이 좋은 이유는 박사과정 전체 조종석에서도 문헌 큐가 계속 보이기 때문이다. 프로젝트를 보러 왔다가도, 지금 쌓여 있는 읽기 항목을 바로 확인할 수 있다.

[사진 삽입 위치 1] PhD Dashboard 전체 화면 캡처

캡션 예시: Active Projects, Today’s Todo, Publications, Reading Queue를 한 화면에 모은 박사과정 상위 조종석.

프로젝트 허브는 실행 단위의 DB 뷰다

최상위 조종석이 전체를 본다면, 실제 실행은 각 프로젝트 허브에서 이루어진다. 현재 활성 프로젝트는 MapOMOP, KG Agent, ToF, ECGFM 네 가지다. 참고로 Holter 관련 작업 축은 현재 ToF 프로젝트로 정리되어 있고, 허브에는 legacy alias로 Holter를 함께 유지하고 있다.

프로젝트 허브는 무엇을 답해야 하는가

좋은 프로젝트 허브는 아래 질문에 답할 수 있어야 한다.

  • 이 프로젝트는 어떤 연구 질문을 다루는가
  • 지금 단계는 어디인가
  • 최근 어떤 회의와 자료가 쌓였는가
  • 어떤 논문이 직접적으로 연결되는가
  • 지금 막히는 지점은 무엇인가

그래서 각 허브에는 보통 아래 섹션이 들어간다.

  • Core Questions
  • Milestones
  • Meetings
  • Materials
  • Related Papers

이 구성이 좋은 이유는 프로젝트 허브가 “폴더 설명 페이지”가 아니라, 실행에 필요한 최소 정보가 모이는 운용 노트가 되기 때문이다.

프로젝트 허브도 데이터를 복제하지 않는다

프로젝트 허브에서 중요한 원칙은 상위 대시보드와 같다. 관련 논문은 02_Sources/Papers에서 필터링해 오고, 미팅은 meeting 노트에서, 자료는 material 노트에서, 마일스톤은 milestone 노트에서 다시 읽는다.

즉, 허브는 데이터를 새로 저장하는 장소가 아니라, 특정 프로젝트 맥락에서 다시 조합하는 장소다. 이 원칙을 지켜야 한 노트가 여러 맥락에서 재사용된다.

프로젝트 허브에는 질문 축이 반드시 있어야 한다

현재 구조를 더 좋아지게 만드는 포인트는 Core Questions 섹션이다. 프로젝트가 바쁘게 굴러갈수록 당장 할 일은 잘 보이지만, “이 프로젝트가 실제로 어떤 질문에 답하려고 하는가”는 흐려지기 쉽다.

그래서 프로젝트 허브에는 최소한 아래 문장이 들어가야 한다고 생각한다.

  • 이 프로젝트의 핵심 연구 질문은 무엇인가
  • 왜 이 질문이 지금 중요한가
  • 이 질문에 답하기 위해 지금 어떤 근거와 실험이 필요한가

이 축이 있어야 프로젝트 허브가 단순한 작업판이 아니라, 문헌 DB와 질문 노드와 실험 계획을 잇는 실행 노드가 된다.

[사진 삽입 위치 2] 프로젝트 허브 하나의 전체 화면 또는 Milestones/Meetings/Materials/Related Papers가 보이는 캡처

캡션 예시: 프로젝트 허브에서 마일스톤, 회의, 자료, 관련 논문을 한 번에 묶어 보는 실행 레이어.

실적 DB를 문헌 DB와 분리한 이유

박사과정에서는 읽는 논문과 낸 논문이 같은 “paper”라는 이름 아래 섞이기 쉽다. 하지만 두 데이터는 성격이 완전히 다르다. 읽는 논문은 질문과 근거를 위한 입력이고, publication은 이미 외부에 내보낸 결과물이다.

그래서 Publications를 따로 둔 효과는 크다.

첫째, 실적 아카이브가 문헌 큐와 섞이지 않는다.

둘째, project 기반으로 어떤 결과물이 나왔는지 추적하기 쉬워진다.

셋째, 나중에 CV, 발표 자료, 연구 소개 문서를 업데이트할 때도 publication note가 기준점이 된다.

즉, publication DB는 지식 축적만이 아니라 연구 이력 관리에도 직접적으로 연결된다.

주간 리뷰가 그래프를 살아 있게 만든다

구조만 만들어 두고 노트를 방치하면 볼트는 다시 창고가 된다. 실제로 시스템이 살아 있게 하려면 주간 리뷰가 필요하다. 지금 내가 중요하게 보는 리뷰 항목은 아래와 같다.

  1. 오래된 TODO를 닫거나 갱신한다.
  2. 데일리와 미팅 노트에서 살아남을 아이디어를 꺼낸다.
  3. 새로 읽은 논문을 Papers에 정리한다.
  4. 반복되는 미지수를 Questions로 승격한다.
  5. 반복해서 쓰는 이해를 Concepts로 올린다.
  6. 각 프로젝트 허브의 current_focus를 갱신한다.

이 과정을 거쳐야 Inbox와 Logs에 있던 정보가 장기 지식과 실행 단위로 이동한다.

박사과정 전체를 문서화하는 방식

지금의 구조를 한 문장으로 요약하면 이렇다.

문헌은 공용 데이터베이스에 두고, 질문과 개념은 장기 지식 레이어로 올리고, 프로젝트 허브와 PhD Dashboard는 그 지식을 실행 가능한 형태로 다시 보여준다.

이 방식이 좋은 이유는 박사과정의 여러 층위가 한 시스템 안에서 분리되면서도 연결되기 때문이다. 오늘의 할 일과 장기 연구 질문이 서로 끊어지지 않고, 읽는 논문과 이미 낸 성과도 같은 환경 안에서 관리된다.

마무리

이번 글에서는 PhD Dashboard, 프로젝트 허브, Publications 데이터베이스를 중심으로 실행 레이어를 정리했다. 정리해보면 이 시리즈의 구조는 다음과 같다.

  • 1편: 볼트 전체 구조와 운영 원칙
  • 2편: 문헌 DB, 질문 노드, 개념 노드
  • 3편: 상위 조종석과 프로젝트 실행 레이어

이제 남은 과제는 더 많은 대시보드를 만드는 것이 아니라, 질문 노드와 프로젝트 허브의 연결을 더 촘촘하게 만드는 것이다. 그렇게 해야 이 볼트가 단순한 정리 도구가 아니라, 박사연구 전체를 장기적으로 지탱하는 personal knowledge DB로 자리 잡을 수 있다.