이 글은 박사연구용 Obsidian 시스템을 정리하는 시리즈의 2편이다. 1편에서는 전체 구조와 운영 원칙을 정리했고, 이번 글에서는 그중에서도 핵심 데이터베이스인 02_Sources/Papers와 Literature Dashboard를 다룬다. 정확히는 “논문을 어떻게 저장하느냐”보다 “논문이 어떻게 질문 노드와 개념 노드로 이어지느냐”를 정리하려는 글이다.

내가 원하는 문헌 시스템은 “읽은 논문 목록”이 아니다. 논문을 프로젝트와 연결하고, 반복되는 연구 질문을 뽑아내고, 장기적으로는 개념 노트와 리뷰 노트까지 이어지는 연구 지식 레이어가 필요했다. 문헌 대시보드는 그 입구이고, 진짜 핵심은 논문 노트가 고립되지 않게 만드는 구조에 있다.

왜 논문 폴더만으로는 연구가 축적되지 않는가

논문 관리가 잘 안 되는 가장 큰 이유는 자료가 없어서가 아니라, 논문 노트가 다음 단계로 이동하지 않기 때문이다. PDF를 저장하고 한 줄 요약을 적는 것만으로는 연구 자산이 잘 쌓이지 않는다.

논문을 읽은 기록과 연구에 남는 지식은 다르다

논문을 읽고 나면 보통 세 가지가 남는다.

  • 특정 프로젝트에 왜 중요한지
  • 어떤 질문을 더 분명하게 만들었는지
  • 어떤 개념을 장기적으로 남겨야 하는지

그런데 논문 노트가 그냥 요약문 저장소에 머물면 이 세 가지가 분리되지 않는다. 그래서 공용 논문 DB를 만들더라도, 거기서 질문 노드와 개념 노드로 이어지는 후속 경로가 함께 설계되어야 한다.

논문은 프로젝트 폴더의 첨부물이 아니라 공용 근거 데이터여야 한다

현재 볼트에서는 모든 논문을 02_Sources/Papers 아래에서 관리한다. 프로젝트 폴더마다 논문을 복사하지 않고, projects 필드로 연결한다. 이 방식의 장점은 명확하다.

  1. 같은 논문이 여러 프로젝트에 동시에 연결될 수 있다.
  2. Literature Dashboard와 프로젝트 허브가 같은 데이터를 서로 다른 시점에서 볼 수 있다.
  3. 논문 노트가 특정 프로젝트 안에 갇히지 않으므로, 나중에 다른 연구 질문으로 재사용하기 쉽다.

공용 Papers DB를 먼저 만든다

문헌 정리의 핵심은 대시보드보다 paper note 스키마다. 노트 하나를 저장할 때 나중에 무엇으로 다시 조회할지를 함께 생각해야 한다.

paper note에서 반드시 남기는 항목

현재 paper note에서는 아래 항목을 핵심으로 쓴다.

title: "논문 제목"
type: paper
status: active
created: "2026-04-08"
updated: "2026-04-08"
paper_date: "2025.08"
journal: "NeurIPS"
url: "https://..."
projects:
  - "MapOMOP"
topics:
  - "Knowledge Graphs"
questions:
  - "임상 텍스트를 OMOP 표준 용어에 얼마나 안정적으로 매핑할 수 있는가?"
reading_status: todo
summary: "한 줄 요약"
limitations: "핵심 한계"

핵심은 필드를 많이 두는 것이 아니라, 나중에 다시 연결할 수 있는 필드를 남기는 것이다.

projects, topics, questions를 분리한 이유

세 필드를 분리해 두면 같은 논문을 서로 다른 관점으로 다시 볼 수 있다.

  • projects는 지금 어느 실행 단위와 연결되는지 보여준다.
  • topics는 이 논문이 어떤 개념 축에 속하는지 보여준다.
  • questions는 이 논문이 어떤 미지수에 기여하는지 보여준다.

이 구분을 해두면 문헌 DB는 단순한 읽기 기록이 아니라, 프로젝트 필터와 개념 축과 질문 축을 동시에 가진 근거 데이터베이스가 된다.

날짜와 상태는 쿼리를 단순하게 만들기 위해 통일한다

문헌 대시보드는 매일 열어보는 화면이기 때문에, 복잡한 예외 처리보다 데이터 정규화가 더 중요하다.

  • paper_date는 "YYYY.MM" 형식으로 통일한다.
  • reading_status는 todo, doing, done 세 값으로 유지한다.
  • summary와 limitations는 짧아도 반드시 적는다.

형식을 먼저 고정하면 Dataview 쿼리는 단순해지고, 단순한 쿼리는 오래 버틴다.

Literature Dashboard는 어떤 질문에 답해야 하는가

문헌 대시보드는 단순히 표를 예쁘게 만드는 페이지가 아니다. 내가 이 페이지에서 바로 답하고 싶은 질문은 다음과 같다.

  1. 지금 각 프로젝트와 직접 연결된 논문은 무엇인가
  2. 아직 특정 프로젝트에 묶이지 않은 논문은 무엇인가
  3. 지금 읽어야 할 문헌 큐는 어떤 상태인가
  4. 새 논문 노트를 가장 빨리 어디서 만들 수 있는가

프로젝트별 뷰와 전체 뷰를 함께 둔다

현재 Literature Dashboard는 MapOMOP, KG Agent, ToF, ECGFM, Unassigned / Other Papers, All Papers 섹션으로 구성되어 있다. 이 구조가 좋은 이유는 문헌을 너무 좁게만 보지도, 너무 넓게만 보지도 않게 해주기 때문이다.

  • 프로젝트별 섹션은 지금 당장 필요한 근거를 빠르게 찾게 해준다.
  • Unassigned 섹션은 아직 맥락이 확정되지 않은 논문을 잊지 않게 해준다.
  • All Papers는 전체 흐름과 중복을 한 번에 점검하게 해준다.

새 논문 노트는 대시보드에서 바로 만든다

문헌 시스템은 입력 마찰이 높아지는 순간 무너진다. 그래서 대시보드 상단에 New Paper Note 버튼을 두고, 곧바로 02_Sources/Papers에 템플릿이 적용된 새 노트를 만들 수 있게 해두었다.

대시보드가 보기 전용 화면이면 결국 입력이 늦어진다. 반대로 입력과 조회가 같은 화면에서 이어지면, 논문이 인박스에 오래 머물지 않는다.

Dataview JS보다 plain Dataview를 우선한다

문헌 대시보드는 자주 여는 화면이기 때문에 화려함보다 안정성이 중요하다. 그래서 가능한 한 dataviewjs보다 plain dataview 쿼리로 유지하고 있다. 설정 문제나 디버깅 비용을 줄이고, 데이터 정규화에 집중하는 편이 실제 운영에는 더 유리했다.

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

캡션 예시: 프로젝트별 논문, 미분류 논문, 전체 논문을 한 화면에서 보는 문헌 대시보드.

논문을 질문 노드와 개념 노드로 승격하는 방법

문헌 DB가 personal knowledge DB로 바뀌는 순간은 논문을 저장했을 때가 아니라, 저장된 논문이 다른 노드로 연결될 때다.

같은 미지수가 반복되면 question note를 만든다

03_Concepts/Questions는 이번 볼트 구조에서 가장 중요한 추가 레이어다. 같은 의문이 여러 논문, 여러 회의, 여러 아이디어 노트에서 반복되면 그 질문을 하나의 노드로 만든다.

질문 노트는 해결책 이름이 아니라 미지수의 형태로 써야 한다. 예를 들면 아래처럼 정리하는 편이 좋다.

  • 결측 모달리티가 있는 biosignal 환경에서 표현 학습은 어떻게 안정화할 수 있는가?
  • 임상 의사결정 지원에서 retrieval은 direct generation보다 언제 실제로 이득을 주는가?
  • EHR 텍스트와 OMOP 표준 용어 매핑은 어떤 근거에서 신뢰할 수 있는가?

질문을 노드로 만들어 두면, 서로 다른 프로젝트의 문헌도 같은 질문 축에서 묶어 읽을 수 있다.

반복해서 쓰는 이해는 concept note로 올린다

모든 통찰을 개념 노트로 만들 필요는 없지만, 여러 문헌과 프로젝트를 거치며 반복해서 쓰는 이해는 03_Concepts로 승격하는 편이 낫다. 예를 들어 Knowledge Graphs, Foundation Models, ECG, RAG, Verification 같은 항목은 특정 논문 한 편의 메모가 아니라 장기적으로 참조할 개념 축이다.

이렇게 하면 논문 노트는 근거, 질문 노트는 미지수, 개념 노트는 재사용 가능한 이해라는 식으로 역할이 분리된다.

review note는 문헌 합성 레이어다

논문 한 편과 개념 노트 사이에는 종종 중간 단계가 필요하다. 여러 근거를 묶어 비교하고 정리하는 review 노트가 그 역할을 한다. 특정 주제, 방법, 데이터셋을 비교 정리해야 할 때는 02_Sources/Reviews에서 합성 노트를 만들어 두는 편이 훨씬 낫다.

즉, 문헌 레이어의 흐름은 아래처럼 정리할 수 있다.

  1. paper note에 근거를 저장한다.
  2. 같은 미지수가 반복되면 question note를 만든다.
  3. 반복해서 쓰는 이해는 concept note로 올린다.
  4. 여러 근거를 비교해야 하면 review note로 묶는다.
  5. 그 결과를 아이디어나 프로젝트 실행으로 넘긴다.

[사진 삽입 위치 2] paper note, question note, concept note가 연결된 그래프 뷰 또는 예시 노트 캡처

캡션 예시: 논문이 요약에서 끝나지 않고 질문 노드와 개념 노드로 연결되는 문헌 그래프.

문헌 정리가 personal knowledge DB가 되는 순간

내가 문헌 시스템에서 가장 중요하게 보는 것은 “많이 저장했는가”가 아니라 “다시 꺼내 쓸 수 있는가”다. 논문을 읽는 이유는 요약을 모으기 위해서가 아니라, 연구 질문을 더 선명하게 만들고 프로젝트 판단에 근거를 공급하기 위해서다.

그래서 좋은 문헌 DB는 아래 조건을 만족해야 한다.

  • 프로젝트와 연결된다.
  • 질문 노드와 연결된다.
  • 개념 노드와 연결된다.
  • 다시 읽어야 할 큐와 이미 읽은 근거를 함께 보여준다.
  • 입력 마찰이 낮아 꾸준히 유지된다.

지금의 Literature Dashboard와 paper note 구조는 이 조건을 만족시키기 위한 최소 설계다.

마무리

이번 글에서는 Literature Dashboard를 단순한 논문 표가 아니라, 논문에서 질문 노드와 개념 노드로 이어지는 연구 데이터베이스의 입구로 정리해봤다.

다음 글에서는 이 문헌 레이어 위에 올라가는 PhD Dashboard, 프로젝트 허브, publications 데이터베이스를 중심으로, 실행 레이어를 어떻게 설계했는지 정리해보려 한다.