옵시디언 Bases 목록 필터: 원소 일치와 부분 문자열을 구별하기

대표 이미지 설명: 목록 원소 전체 일치와 원소 내부의 부분 문자열 일치를 구분한 개념도입니다. 실제 Obsidian 화면이나 시험 결과는 아닙니다.

옵시디언 Bases의 목록 속성에 디자인 검수가 있는데 contains("디자인")으로는 행이 보이지 않나요? 목록의 contains는 글자 일부가 아니라 원소 전체를 찾습니다. 원소 안의 글자를 찾으려면 목록의 각 원소에 문자열 contains를 적용하는 필터가 필요합니다. 다만 그러면 재디자인처럼 원하지 않은 원소도 걸릴 수 있습니다. 어떤 일치를 원하는지 먼저 정하세요. 아래 행 결과는 일반 문자열 다섯 노트를 넣은 격리 볼트의 Obsidian 1.13.7/macOS 시험에 한정합니다. 실제 사용자 볼트나 모바일에서 시험한 결과는 아닙니다. Obsidian 함수 설명

목록에 ‘디자인’이 있는데 왜 행이 빠지나요?

Obsidian의 Bases 함수 문서는 목록의 contains(value)를 해당 원소가 목록에 있는지 확인하는 함수로, 문자열의 contains(value)를 부분 문자열을 포함하는지 확인하는 함수로 구별합니다. 속성이 Text인지 List인지에 따라 같은 contains라는 이름도 비교 대상이 달라집니다.

예를 들어 demo_labels가 디자인 검수, 배포라는 두 원소를 가진 List라면 note.demo_labels.contains("디자인")은 디자인 검수를 통째로 디자인과 같은 원소로 보지 않습니다. 목록에 디자인이라는 원소가 따로 있을 때 찾는 조건입니다. 여기까지는 함수 정의에 따른 설명입니다. 아래 표에서는 같은 입력을 앱에서 확인한 행을 보여드립니다.

어떤 원본과 범위에서 시험했나요?

2026년 10월 11일, 비민감 격리 볼트의 Samples/ 폴더에 Markdown 노트 다섯 개를 넣었습니다. demo_labels는 List, demo_text는 별도의 Text 속성으로 설정했습니다. Obsidian 도움말은 속성 타입을 구별하고 동일한 속성 이름의 타입이 볼트 전체에 적용된다고 설명합니다. 그래서 한 속성의 타입을 도중에 바꿔 비교하지 않았습니다. 속성 도움말

A.md의 실제 frontmatter는 다음과 같습니다. demo_text의 쉼표는 단지 설명용 문자열입니다. List를 문자열로 합친 뒤 검색한 것이 아닙니다.

---
demo_labels:
  - 디자인 검수
  - 배포
demo_text: "디자인 검수, 배포"
---

같은 범위에 속하는 Markdown 파일만 보려고 .base의 전역 조건을 file.inFolder("Samples")와 file.ext == "md"로 고정했습니다. 표시 열은 파일 이름·두 속성입니다. Bases 구문 문서는 전역 필터와 뷰 필터, 노트 속성의 note. 참조를 설명합니다. 아래는 이번 시험의 원소별 부분 문자열 조건을 넣은 최소 .base 예시입니다. 파일과 폴더 이름은 자신의 시험 볼트에 맞춰 바꾸세요.

filters:
  and:
    - file.inFolder("Samples")
    - file.ext == "md"
views:
  - type: table
    name: List match
    filters:
      and:
        - note.demo_labels.filter(value.contains("디자인")).length > 0
    order:
      - file.name
      - note.demo_labels
      - note.demo_text

이 코드는 시험에서 저장한 L4 조건의 사본입니다. 표시 열을 앱에서 열고 필터 팝오버를 다룬 뒤 최종 .base는 order의 두 note. 접두사를 제거한 표기로 다시 저장됐습니다. 그러므로 시험 파일의 최초·최종 바이트가 같았다고 주장하지 않습니다. 본문 비교의 핵심은 같은 다섯 원본·전역 범위에서 뷰 조건만 바꿨다는 점입니다.

원소 전체와 부분 글자 조건의 실제 결과는 어떻게 달랐나요?

공식 함수 정의를 먼저 확인하고, 앱 창·파일 링크·실제 화면을 격리 시험에서 대조했습니다. 노트는 같은 다섯 개이며 뷰 이름은 List match입니다. 조건은 .base 뷰 필터에 하나씩 적용했습니다.

L2와 L4는 이 시험의 실제 Obsidian 창에서 파일 링크와 화면을 확인했습니다. list.filter는 각 원소를 value로 평가한 목록을 돌려주므로, length > 0은 ‘부분 글자를 포함한 원소가 적어도 하나’라는 조건입니다(함수 설명). 이번 자료에서 L5가 L4와 같은 행을 반환했어도 List와 Text가 같은 타입은 아닙니다. D의 빈 두 값은 기준 표에서 빈 셀로 보였고 이번 조건들에서 선택된 행은 없었습니다. 누락 속성이나 null까지 시험한 것은 아닙니다.

위 시험은 사람이 메뉴에서 매번 식을 입력한 실습이 아닙니다. 담당자가 격리 볼트의 Markdown·.base 파일을 만들고 앱 내부 API/CDP로 필터를 바꾸며 실제 앱 DOM의 행과 PNG 캡처를 대조했습니다.

‘재디자인’까지 나오면 어떤 조건을 택해야 하나요?

‘디자인’이라는 독립 분류만 찾는다면 L2의 목록 원소 일치를 선택하세요. 디자인 검수처럼 원소 속 글자도 찾으려면 L4의 부분 문자열 조건을 선택하세요. L4는 재디자인도 포함합니다. 이 값이 필요한지 여부는 사용 목적에 달려 있으며 무조건 오류가 아닙니다. 부분 문자열은 단어 경계나 의미 유사도를 이해하는 검색이 아닙니다.

디자인 검수 한 원소를 정확히 찾는다면 L3처럼 그 전체 값을 조건에 넣을 수도 있습니다. 업무 볼트의 기존 속성을 Text로 일괄 변경해서 결과를 맞추지는 마세요. 이 시험은 별도 이름의 Text 대조 속성을 썼습니다.

표가 비어도 원본 파일이 사라진 건가요?

이번 격리 시험에서 L6 조건은 0행이었지만 A~E 파일은 그대로 남아 있었고, 조건을 L2로 되돌려 뷰를 다시 열자 B가 재표시됐습니다. 노트 원본 다섯 개의 최종 해시는 고정 입력과 일치했습니다. 다만 .base의 최종 바이트는 앱이 표시 열을 재직렬화해서 L2 저장 직후 사본과 달랐습니다. 그래서 ‘파일을 모두 바이트 단위로 원복했다’고 표현하지 않습니다.

자신의 표가 비면 먼저 선택된 폴더·확장자와 전역/뷰 조건을 확인하고, 속성 타입이 List인지 Text인지, YAML에 실제 어떤 원소가 들어 있는지 확인하세요. 지금 찾는 것이 원소 전체인지 일부 글자인지도 비교해야 합니다. 기존 자료를 삭제하거나 타입을 한꺼번에 바꾸기 전, 비민감 복사본에서 조건을 하나씩 조정해 실제 행을 대조하는 편이 좋습니다. 이 결과는 Obsidian 1.13.7/macOS의 일반 문자열·다섯 노트에 한정하며 모바일, 다른 버전, 링크/숫자 혼합 목록, 누락·null, 대소문자, 유니코드 정규화와 성능은 확인하지 않았습니다. 범위·뷰 조건 자체가 문제라면 Bases 파일 범위 점검을 함께 참고하세요.