Obsidian Dataview: 동적 대시보드와 쿼리를 위한 완벽 가이드 (2026)

Obsidian의 진정한 힘은 작성하는 노트에 있는 것이 아니라, 그 노트들이 서로 대화를 시작할 때 일어나는 일에 있습니다. Dataview는 그 스위치를 켜주는 플러그인입니다. 이것은 여러분의 보관소(vault)를 정적인 마크다운 파일 더미에서 필요할 때 쿼리하고 정렬하고 요약할 수 있는 살아있는 데이터베이스로 바꾸어 줍니다. 노트에 태그를 달고, 마감일을 추가하고, 프로젝트 상태를 설정하면, Dataview는 내용을 변경할 때마다 자동으로 업데이트되는 테이블, 리스트, 대시보드로 해당 정보를 조합해 냅니다.

“모든 진행 중인 프로젝트”나 “내가 누군가에게 빚지고 있는 모든 작업”을 찾기 위해 수십 개의 폴더를 스크롤해 본 적이 있다면, 이미 Dataview가 해결하는 문제를 이해하고 계신 것입니다. 인덱스 노트를 손으로 유지 관리하는 대신, 짧은 쿼리를 한 번 작성하면 플러그인이 영원히 최신 상태로 유지해 줍니다. 독서 기록, 작업 보드, 주간 검토 등 모든 것을 자동화할 수 있습니다.

이 가이드에서 다룰 내용은 다음과 같습니다: Dataview의 실제 개념, 설치 방법, 읽어들이는 메타데이터 추가법, 4가지 쿼리 유형, 소스 선택 및 필터링 방법, 인라인 쿼리, 복사하여 바로 쓸 수 있는 2개의 대시보드 예시, 그리고 쿼리가 아무것도 반환하지 않을 때의 문제 해결 체크리스트입니다. 이 글을 마칠 때쯤이면 여러분은 자신만의 대시보드를 구축할 수 있게 되거나, DQL을 전혀 작성하지 않고 준비된 템플릿에 맡길 수 있게 될 것입니다.

Obsidian Dataview란 무엇이며 왜 중요한가요?

Dataview는 보관소의 실시간 인덱스이자 노트의 메타데이터를 읽어 테이블, 리스트, 작업 보드, 달력으로 렌더링하는 쿼리 언어입니다. 데이터를 이동하거나 복제할 필요가 없습니다. “Projects 폴더에 있는 active 태그가 달린 모든 노트를 마감일 순으로 정렬해 줘”와 같이 원하는 바를 설명하기만 하면 Dataview가 뷰를 생성하고 보관소가 변경됨에 따라 자동으로 새로고침합니다.

이것이 중요한 이유는 수동 인덱스는 만드는 순간부터 썩기 시작하기 때문입니다. 손으로 쓴 “진행 중인 프로젝트” 노트는 다음 프로젝트를 완료하는 순간 오래된 정보가 됩니다. 하지만 Dataview 쿼리는 절대 그렇지 않습니다. 보관소가 커질수록 이점은 배가됩니다: 오늘 프로젝트 2개를 보여주는 3줄짜리 쿼리는 여러분이 아무런 추가 노력을 하지 않아도 내년에는 20개를 보여줄 것입니다.

모든 노트를 데이터베이스의 행으로, 모든 속성을 열로 생각해 보세요. Dataview는 명확하고 읽기 쉬운 구문으로 해당 데이터베이스에 질문을 던질 수 있게 해줍니다. 이것은 좋은 연결 습관의 자연스러운 동반자입니다 — 여전히 연결 습관을 기르는 중이라면 노트 연결 완벽 가이드가 여기서 배우는 내용과 완벽하게 어울립니다. 노트가 서로를 더 많이 참조할수록 Dataview가 활용할 수 있는 재료가 많아지기 때문입니다.

Dataview를 어떻게 설치하고 활성화하나요?

Obsidian의 커뮤니티 플러그인 패널을 통해 1분 이내에 Dataview를 설치할 수 있습니다. 정확한 순서는 다음과 같습니다:

1. 설정 → 커뮤니티 플러그인을 엽니다.
2. “제한 모드”(Restricted mode)가 활성화되어 있다면 끄기로 변경합니다 (커뮤니티 플러그인이 실행되도록 허용).
3. 탐색(Browse)을 클릭한 후 Dataview를 검색합니다.
4. 설치(Install)를 클릭한 다음 활성화(Enable)를 클릭합니다.

활성화되면 Dataview가 백그라운드에서 보관소 인덱싱을 시작합니다. 작은 보관소에서는 즉시 완료되며, 큰 보관소에서는 처음에 몇 초 정도 걸릴 수 있습니다.

다음으로 플러그인 설정으로 이동하여 전체 기능을 해제하는 두 가지 토글을 확인합니다:

• 인라인 쿼리 활성화 (Enable Inline Queries) — 문장 중간에 단일 값을 표시할 수 있게 해줍니다 (뒤에서 설명).
• JavaScript 쿼리 활성화 (Enable JavaScript Queries) — 고급 사용자 지정 로직을 위해 DataviewJS를 사용할 계획인 경우에만 필요합니다. 처음 시작할 때는 꺼두세요.

팁: 수동으로 아무것도 “다시 작성”할 필요가 없습니다. 노트를 편집, 생성, 삭제함에 따라 Dataview가 자동으로 다시 인덱싱합니다. 유일한 예외는 끝부분의 문제 해결 섹션에서 다룹니다.

메타데이터는 어떻게 추가하나요: Frontmatter 속성 vs 인라인 필드?

Dataview는 두 가지 종류의 메타데이터를 읽습니다: YAML frontmatter(Obsidian에서는 속성 / Properties라고 부름)와 노트 본문에 작성된 인라인 필드입니다. 두 가지 모두 쿼리 가능한 열이 되며, 데이터가 자연스럽게 위치하는 곳에 따라 선택하면 됩니다.

Frontmatter(속성) 은 노트의 가장 위쪽 두 개의 --- 줄 사이에 위치하며 구조화된 노트 수준 데이터에 가장 적합합니다:

---
status: active
due: 2026-07-15
priority: 1
tags: [project, client]
---

인라인 필드는 이중 콜론을 사용하여 노트 중간에 데이터를 기록할 수 있게 해줍니다. 자체 줄에는 키:: 값을 사용하고, 문장 안에 필드를 내장하려면 [키:: 값]을 사용합니다:

Project kicked off today.
status:: in-progress
Budget is [budget:: 4500] for this quarter.

필드 유형은 자동으로 추론됩니다: 텍스트, 숫자, 날짜 (2026-07-15와 같은 ISO 형식), 리스트 (tags: [a, b]), 링크 ([[어떤 노트]]). 추가한 내용 외에도 모든 노트에는 아무것도 정의하지 않고도 쿼리할 수 있는 내장 file.* 필드가 함께 제공됩니다:

내장 필드	반환 내용
file.name	노트의 파일 이름
file.link	노트로 이동하는 클릭 가능한 링크
file.ctime / file.mtime	생성 / 최종 수정 시간
file.tags	노트 내의 모든 태그
file.inlinks / file.outlinks	들어오는 / 나가는 링크 노트
file.folder	폴더 경로

file.inlinks 필드는 숨겨진 강력한 기능입니다 — 노트가 어떻게 연결되어 있는지에 순수하게 기반하여 뷰를 작성할 수 있게 해주며, 이것이 의도적인 링크 연결이 결실을 맺는 이유입니다.

4가지 쿼리 유형은 무엇인가요: TABLE, LIST, TASK, CALENDAR?

Dataview는 4가지 쿼리 유형을 제공하며, 각 유형은 서로 다른 형태의 출력을 생성합니다. dataview라는 라벨이 붙은 코드 블록 안에 쿼리를 작성합니다.

LIST는 가장 단순한 형태로, 노트의 글머리 기호 리스트입니다:

LIST
FROM "Projects"
WHERE status = "active"

TABLE은 가장 자주 쓰이는 일꾼으로, 지정한 필드에 대한 열을 추가합니다:

TABLE status, due, file.mtime AS "Last Edited"
FROM "Projects"
SORT due ASC

TASK는 노트 내의 개별 체크박스 항목(- [ ])을 해당 항목이 속한 노트별로 그룹화하여 가져옵니다 — 보관소 전체의 할 일 뷰에 완벽합니다:

TASK
WHERE !completed

CALENDAR는 선택한 날짜 필드를 사용하여 노트를 월별 그리드에 표시하므로 미팅이나 마감일을 시각화하는 데 편리합니다:

CALENDAR due
FROM "Projects"

almost 모든 작업에는 LIST와 TABLE을 사용하고, 여러 노트에 걸친 체크박스를 집계하고 싶을 때는 TASK를, 날짜 그리드 뷰가 행 형태보다 이야기를 더 잘 전달할 때는 CALENDAR를 사용하세요. 작업 관리가 주요 목표라면 Obsidian 작업 관리 완벽 가이드에서 이러한 쿼리 유형이 실제 워크플로에 어떻게 적용되는지 확인하실 수 있습니다.

FROM으로 소스는 어떻게 선택하나요?

FROM 절은 Dataview에 검토할 노트를 알려주며, 폴더, 태그, 링크를 타겟팅할 수 있습니다. 이 부분을 올바르게 설정하면 쿼리가 빠르고 집중적으로 유지됩니다.

• 폴더별: FROM "Projects" (경로는 항상 큰따옴표로 감싸세요. 하위 폴더는 "Areas/Health" 사용).
• 태그별: FROM #active (태그에는 따옴표 없음).
• 들어오는 링크별: FROM [[Project Alpha]] 해당 노트로 링크되는 모든 노트를 찾습니다.
• 나가는 링크별: FROM outgoing([[Project Alpha]]) Alpha가 링크하는 노트를 찾습니다.

AND 및 OR로 소스를 조합하고 마이너스 기호로 제외하세요. 이것이 실무에서 가장 유용한 패턴입니다 — 폴더를 가져오고, 태그로 범위를 줄이고, 템플릿을 제외합니다:

TABLE status, due
FROM "Projects" AND #active AND -"Templates"
SORT due ASC

이 쿼리는 Templates 폴더의 모든 항목을 제외하면서 #active 태그가 지정된 Projects 폴더의 모든 항목을 읽습니다.

참고: FROM으로 범위를 지정하는 것은 단순히 깔끔함 때문만이 아니라 성능을 위한 습관입니다. FROM "Projects"로 시작하는 쿼리는 해당 폴더만 스캔하지만, FROM이 없는 쿼리는 새로고침할 때마다 전체 보관소를 스캔합니다.

결과는 어떻게 필터링, 정렬 및 그룹화하나요?

소스를 선택하고 나면 WHERE, SORT, GROUP BY가 출력을 형성합니다. 이 절들은 여러분이 가장 자주 조정하게 될 부분입니다.

WHERE는 비교 및 함수를 사용하여 행을 필터링합니다:

• 비교: WHERE priority >= 2, WHERE status = "active", WHERE due < date(today).
• 함수: contains(file.name, "2026"), length(tags) > 0, 그리고 due <= date(today) + dur(7 days)와 같은 날짜 연산.

SORT는 결과를 정렬합니다: SORT due ASC 또는 SORT file.mtime DESC. LIMIT은 개수를 제한합니다: LIMIT 10.

GROUP BY는 공유 값을 기준으로 결과를 접습니다 — 상태별로 작업 그룹화, 폴더별로 노트 그룹화, 작성자별로 읽을거리 그룹화:

TABLE rows.file.link AS "Projects"
FROM "Projects"
GROUP BY status

필드에 리스트(여러 태그나 작성자 등)가 포함되어 있는 경우, 그룹화하기 전에 FLATTEN을 사용하여 값당 한 행으로 펼치세요 — 그렇지 않으면 리스트가 하나의 덩어리로 처리됩니다. 다음은 이러한 여러 절을 조합한 “최근 수정된 노트” 복사해서 붙여넣기 레시피입니다:

TABLE file.mtime AS "Modified"
FROM ""
SORT file.mtime DESC
LIMIT 10

그리고 깔끔한 보관소를 유지하는 데 유용한 “태그 없는 노트” 정리 쿼리입니다:

LIST
WHERE length(file.tags) = 0

인라인 DQL은 어떻게 작성하며 DataviewJS는 언제 사용해야 하나요?

인라인 DQL을 사용하면 전체 블록을 렌더링하는 대신 단일 계산값을 문장 중간에 직접 삭제할 수 있습니다. 백틱-등호 프prefix로 작성합니다. 예를 들어 = this.due는 현재 노트의 마감일을 인라인으로 출력하고, = dv.current().file.mtime은 이 노트가 마지막으로 편집된 시간을 출력하며 — 둘 다 실시간으로 업데이트됩니다.

이것은 템플릿과 일일 노트 내부에서 이상적입니다: “최종 검토일: = this.reviewed“라고 적힌 헤더는 여러분이 손대지 않고도 정확하게 유지됩니다. 인라인 쿼리는 설정에서 활성화되어 있어야 합니다 (설치 시 설정함).

DataviewJS는 고급 단계입니다. 이것은 읽기 쉬운 DQL 구문을 JavaScript 및 dv.* API로 교체하여 반복문, 조건문 및 임의의 사용자 지정 로직(예: dv.pages("#book").where(p => p.rating > 4))을 제공합니다. 절충안은 더 가파른 학습 곡선과 JavaScript 쿼리 활성화 토글입니다. DQL에 익숙해진 후의 다음 단계로 다루시고, 시작점으로 삼지 마세요. 대다수의 대시보드는 이것이 전혀 필요하지 않습니다.

팁: 간단한 작업을 수행하기 위해 DataviewJS를 찾고 있다면 보통 일반 DQL 방법이 존재합니다. JavaScript는 진정한 커스텀 렌더링을 위해 아껴두세요.

작업 및 프로젝트를 위한 실제 대시보드는 어떻게 구축하나요?

대시보드는 “무엇에 주의를 기울여야 하는가?“라는 질문에 함께 답하는 여러 쿼리를 담고 있는 노트일 뿐입니다. 노트에 붙여넣고 편집할 수 있는 두 가지 완전한 예시가 있습니다.

안내 1 — 작업 대시보드. 보관소 전체의 모든 열린 작업을 표면화하고, 기한이 지난 작업을 격리하고, 파일별로 그룹화하여 각 프로젝트가 어떤 작업을 갖고 있는지 보여줍니다:

TASK
WHERE !completed AND due AND due < date(today)
GROUP BY file.link

이번 주 마감인 모든 항목을 보려면 due < date(today)를 due <= date(today) + dur(7 days)로 교체하세요. 더 풍부한 마감일 및 반복 처리를 위해 Dataview를 Tasks 플러그인과 결합하세요: Tasks는 일정 관리, 반복, 매끄러운 체크박스 UI를 담당하고, Dataview는 노트 전체를 집계하고 보고합니다. Tasks 플러그인 활용 완벽 가이드에서 이 조합을 상세히 다루며, GTD 방식을 사용하는 경우 GTD 설정에도 완벽하게 들어맞습니다.

안내 2 — 프로젝트 대시보드. 상태, 다음 작업, 마지막으로 건드린 시간이 포함된 진행 중인 프로젝트의 단일 테이블입니다:

TABLE status AS "Status", next_action AS "Next Action", file.mtime AS "Last Modified"
FROM "Projects" AND -"Templates"
WHERE status != "done"
SORT file.mtime DESC

처음부터 이것들을 만드는 것은 배우기에 훌륭한 방법이지만 — 이미 완성된 상태를 원하신다면 바로 준비된 템플릿이 빛을 발하는 지점입니다. Obsibrain은 작업, 프로젝트, 일간/주간 검토를 위한 Dataview 기반 대시보드를 즉시 사용할 수 있도록 사전 설정하여 제공하므로 DQL 한 줄 쓰지 않고도 이점을 누릴 수 있습니다.

흔한 오류와 성능상의 함정은 무엇인가요?

대부분의 “고장난” Dataview 쿼리는 몇 가지 동일한 이유로 실패합니다. 플러그인 오류라고 단정 짓기 전에 이 체크리스트를 실행해 보세요.

• 인라인 필드 구문: 단일 콜론이 아닌 이중 콜론(status:: active)을 사용하세요. 단일 콜론은 frontmatter 밖에서는 아무 작업도 하지 않습니다.
• 대소문자 구분: Status와 status는 서로 다른 필드이며, WHERE에서 "Active"는 "active"와 일치하지 않습니다. 일관성을 유지하세요.
• 폴더 경로에 따옴표 붙이기: FROM "Projects"는 작동하지만, FROM Projects는 태그와 유사한 소스로 읽혀 실패합니다.
• 누락된 필드는 null 반환: priority로 필터링하는 쿼리는 priority 필드가 없는 모든 노트를 자동으로 제거합니다. 이 때문에 결과가 비어있기보다는 불완전해 보이는 경우가 많습니다.
• 필드 유형 혼용 금지: due가 일부 노트에서는 날짜이고 다른 노트에서는 일반 텍스트인 경우 비교 및 정렬이 깨집니다. 보관소 전체에서 필드 하나당 한 가지 유형을 유지하세요.

대형 보관소에서의 성능을 위한 규칙은 Dataview가 스캔할 양을 줄여주는 것입니다:

1. FROM "" 대신 FROM "Folder" 또는 FROM #tag로 모든 쿼리의 범위를 지정하세요.
2. 완전히 읽지 않는 긴 리스트에는 LIMIT을 추가하세요.
3. 자주 열어보는 노트에는 무거운 DataviewJS를 넣지 마세요.
4. 편집 후 결과가 오래되어 보이면 설정에서 플러그인을 껐다 켜거나(또는 Obsidian 재시작) 하여 강제로 다시 인덱싱하도록 하세요.

참고: 아무것도 반환하지 않는 쿼리는 Dataview 버그라기보다는 메타데이터 문제(필드 누락, 폴더 이름 오타, 대소문자 불일치)인 경우가 훨씬 많습니다. 구문이 아닌 필드부터 확인해 보세요.

Dataview vs Obsidian Bases: 2026년에는 무엇을 사용해야 할까요?

Obsidian은 2025년에 코어 기능으로 Bases를 출시했으며, Dataview와 기능이 충분히 겹쳐 새로 입문하는 사람들에게 혼란을 줍니다. Bases는 노코드 스프레드시트 스타일의 데이터베이스 뷰입니다: GUI를 통해 테이블과 필터를 만들고, Obsidian에 내장되어 있으며(플러그인 없음), 모바일에서 부드럽게 작동합니다. Dataview는 텍스트 기반 쿼리 언어입니다: 더 표현력이 풍부하고, 일반 마크다운으로서 휴대성이 뛰어나며, 작업을 추출하고 파생된 값을 계산하는 데 훨씬 뛰어납니다.

구문을 배울 필요 없이 빠른 시각적 테이블을 원하고 주로 모바일을 사용하는 경우 Bases를 사용하세요. TASK 쿼리, 본문 내 인라인 값, 복잡한 필터링, 일반 텍스트로 이동하는 대시보드가 필요한 경우 Dataview를 고르세요. 많은 파워 유저는 두 가지를 모두 실행합니다 — 탐색 가능한 데이터베이스에는 Bases를, 보고 및 작업 집계에는 Dataview를 사용합니다. 어느 것도 사라지지 않으므로 하나에만 전념하기보다는 사용 사례별로 선택하세요.

자주 묻는 질문 (FAQ)

Dataview 플러그인은 무료인가요? 2026년에도 여전히 유지 관리되고 신뢰할 수 있나요? 네. Dataview는 무료 오픈 소스이며 Obsidian 생태계에서 가장 많이 설치된 커뮤니티 플러그인 중 하나입니다. 안정적이고 널리 의존되고 있습니다. 다만 커뮤니티 플러그인이므로(코어 아님) 중요한 설정의 경우 데이터를 일반 마크다운으로 유지하는 것이 현명합니다 — Dataview는 노트를 읽기만 하고 절대 변경하지 않으므로 설계상 이를 잘 지키고 있습니다.

Dataview와 Tasks 플러그인의 차이점은 무엇인가요 — 둘 다 필요한가요? 서로 다른 문제를 해결하며 잘 어울립니다. Tasks 플러그인은 개별 작업을 관리합니다: 마감일, 반복, 일정 관리 및 세련된 체크박스 인터페이스. Dataview는 전체 보관소에 걸쳐 테이블과 리스트를 작성하여 집계하고 보고합니다. 진지한 작업 관리를 위해 대부분의 사람들은 두 가지를 모두 실행하여 Tasks가 작업 수명 주기를 처리하게 하고 Dataview가 대시보드를 구동하게 합니다.

내 Dataview 쿼리가 작동하지 않거나 결과가 나오지 않는 이유는 무엇인가요? 90%의 경우 쿼리가 아니라 메타데이터 문제입니다. 인라인 필드에 이중 콜론 대신 단일 콜론을 썼는지, 대소문자 불일치(Status vs status), 따옴표 없는 폴더 경로, 또는 예상했던 노트에 필드가 존재하지 않는지 확인하세요. 누락된 필드를 필터링하는 WHERE 절은 해당 노트를 자동으로 제거합니다. 구문보다 필드를 먼저 수정하세요.

Dataview가 대형 보관소에서 Obsidian을 느리게 만드나요? 그리고 쿼리가 모바일과 Obsidian Publish에서 작동하나요? 매우 큰 보관소에서는 범위를 지정하지 않은 쿼리로 인해 지연이 발생할 수 있습니다 — FROM 폴더/태그와 LIMIT을 추가하여 해결하세요. 쿼리는 모바일에서도 실행되며(전화기에서는 무거운 쿼리가 더 느림) 노트 내부에 살기 때문에 일반 텍스트로 장치 간에 동기화됩니다. 단, Dataview는 Obsidian Publish에서 렌더링되지 않으므로 게시된 페이지에는 테이블 대신 원본 쿼리가 표시됩니다.

작게 시작하여 키워나가기

이번 주에 모든 절을 마스터할 필요는 없습니다. 몇몇 프로젝트 노트에 status 속성을 추가하고, 최근 수정된 테이블을 붙여넣고, 채워지는 것을 지켜보세요 — 그 단 한 번의 성공으로도 시스템을 이해하기에 충분합니다. 거기서부터 작업 대시보드를 구축하고, 프로젝트 뷰, 주간 검토를 추가하며 실제 필요성이 나타날 때마다 한 번에 하나씩 쿼리를 늘려가세요.

결과는 마음에 들지만 유지 관리가 부담스럽다면 직접 만들지 않아도 됩니다. Obsibrain은 이러한 Dataview 대시보드(작업, 프로젝트, 주기적 검토)를 첫날부터 사용할 수 있도록 사전 설정하여 제공하므로 쿼리를 작성하는 대신 생각하는 데 시간을 쓸 수 있습니다. 직접 구축하든 가져와서 쓰든 목표는 동일합니다: 중요한 작업에 집중하는 동안 스스로 정리되는 보관소를 만드는 것입니다.