대표 이미지 설명: 원본 노트, 선택한 뷰, 이미 내보낸 CSV는 서로 다른 범위와 시점의 자료입니다. 실제 Obsidian 화면이나 E1·E2 실험의 정확한 행 수를 묘사한 그림은 아닙니다.
Obsidian Bases에서 CSV를 내보내면 볼트 전체가 아니라 지금 선택한 뷰의 결과가 파일에 담깁니다. 받는 사람이 기대한 행과 열이 들어 있는지는 화면의 결과 수만 보고 판단하지 말고, 실제 CSV를 열어 헤더와 노트 식별자를 대조하세요. CSV는 원본 Markdown 본문이나 .base 설정의 백업도 아닙니다. Obsidian의 뷰·CSV 안내 · Bases 원본 구조
아래 결과는 운영팀이 2026년 10월 26일 격리 Obsidian 데스크톱 1.14.5의 코어 Bases Table에서 앱의 CSV 내보내기 메뉴로 만든 파일을 직접 대조한 사례입니다. 개인 볼트·플러그인·CLI 내보내기를 사용한 결과는 아닙니다. 앱이 만든 다운로드의 로컬 저장 위치만 CDP로 격리 폴더에 지정했으며 네이티브 저장 대화상자는 시험하지 않았습니다.
두 뷰의 범위를 어떻게 준비하나요?
격리 실습에는 Cases/A.md부터 D.md까지 네 노트를 만들고 case_id A/B/C/D를 각각 넣었습니다. status는 A·B가 ready, C·D가 hold입니다. 별도 Other/control.md에는 범위 밖임을 확인할 case_id: OUT을 두었습니다. .base의 공통 필터는 Cases 폴더와 Markdown 확장자를 대상으로 하고, All cases 뷰와 Ready only 뷰를 구분했습니다. 실제 전달 파일에 유일한 ID 열이 없다면 같은 이름의 노트가 섞일 수 있으니 대조 가능한 속성을 미리 표시 열에 넣는 편이 좋습니다.
앱에서 대상 .base의 뷰를 선택한 뒤 결과 수 메뉴의 ‘CSV 추출하기…’(이 시험의 한국어 UI)를 사용합니다. All cases 화면에는 네 행과 이름,case_id,status,group_label,amount,note_text 여섯 열이 보였고, 해당 CSV에도 A/B/C/D와 같은 여섯 헤더가 있었습니다. Ready only 화면과 CSV에는 A/B 두 행, 이름,case_id,status,amount 네 헤더가 있었습니다. OUT은 어느 파일에도 들어가지 않았습니다. 두 뷰를 하나의 파일로 합쳤다는 뜻이 아닙니다.
이미지 확대 보기
이미지 확대 보기내보내기 전부터 표의 범위가 다르다면 Bases 표에 다른 폴더 노트가 섞일 때 필터 점검을 참고하세요.
표시 열·정렬·결과 제한은 파일에서 어떻게 확인하나요?
같은 격리 원본에서 조건을 한 번에 하나씩 바꾸고 매번 새 CSV를 내보내 비교했습니다.
| 시험 조건 | 실제 CSV에서 확인한 결과 |
|---|---|
All cases의 group_label 표시를 숨김 |
네 행은 그대로, 해당 열만 빠진 다섯 헤더 |
amount 내림차순으로 정렬 |
D(40), A(30), C(20), B(10) 순 |
별도 Reordered columns 뷰를 선택 |
amount,이름,status,case_id,note_text 순서 |
| 내림차순 상태에서 Results limit 2 | D·A 두 행만 포함 |
이것은 Obsidian 1.14.5의 해당 코어 Table 실험 결과입니다. 열 순서가 다른 뷰는 격리 .base에 설정을 작성한 뒤 앱에서 선택해 내보냈지, 모든 열 순서를 앱 메뉴에서 조작했다고 주장하지 않습니다. 다른 버전·뷰 유형의 CSV 규칙까지 보증하지 않으므로 전달 전 파일을 직접 열어보세요. Obsidian 뷰 설정 설명
그룹이 접혀 있다면 CSV에서도 빠지나요?
이 실험의 Grouped status 화면은 hold 그룹의 C·D가 먼저, ready의 A·B가 나중에 보였습니다. 하지만 실제 CSV에서는 A/B/C/D 순서였습니다. 화면 순서를 파일 순서로 가정하지 마세요. ready 그룹 제목만 접었을 때는 화면에 C·D만 보여도 결과 수는 여전히 네 개였고 CSV에도 A/B/C/D가 모두 남았습니다.
별도로 격리 .base에 groupOrder: [ready]를 구성해 ready 그룹만 보이게 한 뷰에서는 화면과 CSV가 모두 A/B 두 행이었습니다. 단순 접힘과 그룹 자체를 숨기는 구성은 이 환경에서 달랐습니다. 두 그룹 뷰는 .base 설정을 만들어 앱에서 선택하고 코어 메뉴로 내보낸 것이며, 그룹 속성 선택을 UI에서 끝까지 저장한 사례는 아닙니다. 자신의 앱에서는 그룹 이름뿐 아니라 결과 수와 실제 CSV의 case_id 전체를 확인하세요. 그룹과 뷰 설명 · Bases 구문
화면 집계도 확인하려면 Bases 화면의 그룹별 합계와 빈값 검산을 참고하세요.
파일을 보내기 전에는 무엇을 대조하나요?
전달 기록에는 네 항목을 남기세요. ① 뷰 이름·필터·정렬·제한·그룹 조건, ② 원본 노트의 범위와 case_id, ③ 실제 CSV 헤더와 논리 레코드의 ID/값, ④ 내보낸 시각과 이후 원본 변경 여부입니다. CSV를 스프레드시트에서 열어 확인하되 쉼표나 셀 안의 줄바꿈이 있으면 텍스트 파일의 줄 수로 행을 세지 마세요. 이번 E1.csv는 물리적 여섯 줄이지만 CSV 파서로 읽으면 네 레코드입니다. 한글, 쉼표, 셀 안 줄바꿈, 빈 셀, 따옴표가 파싱 후에도 유지됐습니다.
격리 노트 A의 amount를 30에서 31로 수정해 다시 내보냈을 때, 이전 CSV의 A는 30으로 남고 새 CSV만 31이었습니다. 원본은 실험 뒤 이전 값으로 복원했습니다. 이미 보낸 CSV는 자동으로 바뀌지 않으니 원본을 고친 뒤에는 새 파일을 만들어 수신자에게 버전과 시각을 알려 주세요. 또 CSV에는 이 사례의 표시 속성과 이름이 들어갔지만 노트 본문의 body_marker는 없었습니다. 원본 Markdown의 보존이 목적이라면 CSV만 보관하지 말고 별도의 원본 백업 경로를 사용하세요. Bases의 데이터·뷰 구조
이미지 확대 보기
