Skip to main content
지식 관리·옵시디언

옵시디언 Bases 백링크가 다를 때: 링크 방향·미연결 언급·갱신 점검

링크의 원문, 코어 Linked/Unlinked, Base의 file.backlinks 셀과 Sources 제한 역방향 뷰를 서로 다른 시각에 관측했습니다. 한 셀의 표시만으로 원본 링크가 사라졌다고 판단하지 않는 점검표입니다.

GTGem.tipsPublished
읽는 시간 : 약 7분 소요
중앙 문서로 들어오는 실선 링크와 밖으로 나가는 링크, 중앙에 닿지 않는 점선 이름 언급을 구분한 개념 그림

옵시디언의 코어 Backlinks에는 노트가 보이는데 Bases 표에는 없거나, 링크를 지운 뒤에도 file.backlinks 셀에 남아 있나요? 원본이 없어졌다고 판단하기 전에 링크 방향, 이름만 쓴 미연결 언급, Base의 행 범위, 표시가 갱신된 시점을 나눠 확인하세요. 아래에는 Obsidian 공식 문서와 별도 5개 노트 격리 볼트에서 실제 관측한 값을 구분해 적었습니다. 실험은 2026년 10월 25일 KST의 Obsidian 1.14.5·macOS 27.0.1에서 이뤄졌습니다.

같은 타깃을 실제로 가리키는 링크인가요?

코어 Backlinks에서 Linked mentions는 실제 내부 링크, Unlinked mentions는 파일 이름이 언급됐지만 링크는 아닌 경우입니다. Obsidian 공식 Backlinks 안내의 두 범주를 합쳐 실제 링크 수로 세지 마세요. 이번 격리 시험의 고정 원문은 다음과 같습니다. 경로와 값은 보존한 테스트 파일의 내용이며, 독자의 업무 볼트에서 얻은 값이 아닙니다.

파일 시험 원문의 핵심 줄 Target과의 관계
Targets/Target.md [[Sources/B]] Target에서 B로 나감
Sources/A.md [[Targets/Target]] A에서 Target으로 들어옴
Sources/B.md Target 이름만 적은 미연결 언급
Sources/C.md 연결 없음 시작 시 링크 없음
Other/D.md [[Targets/Target]] D에서 Target으로 들어옴; Sources 폴더 밖

Target 원문에서 B로 나가는 링크는 B가 Target을 가리킨다는 뜻이 아닙니다. 시작 화면에서 Target을 활성화한 코어 패널은 Linked에 A·D, Unlinked에 B를 표시했습니다. Base의 All files 뷰에서 Target 행의 file.links 셀은 Sources/B, file.backlinks 셀은 D·A로 관측됐습니다. 두 셀은 나가는 링크 / 들어오는 링크로 구별해 읽어야 합니다. 화면은 Target 코어 패널과 Base 뷰를 순차적으로 열어 수집했으므로 완전히 같은 순간의 스냅샷은 아닙니다.

코어 패널과 Base 표는 같은 범위를 보나요?

이번 Base 파일은 전역 조건 file.ext == "md"로 대상을 제한하고, 별도 Sources to Target 뷰에는 다음 두 조건을 함께 걸었습니다.

file.inFolder("Sources")
file.hasLink("Targets/Target.md")

file.hasLink(...)는 각 행의 파일에서 지정 파일로 향하는 링크를 검사합니다. Obsidian Functions 안내와 격리 Base 원본에 따른 방향입니다. 공식 Bases 구문 안내에 따르면 전역 필터와 뷰 필터는 AND로 결합합니다. 이번 고정 뷰에는 Target으로 가는 실제 링크 중 Sources 폴더 안의 A만 표시됐습니다(B2 실측). D는 Target을 가리키지만 폴더 밖에 있고, B는 미연결 언급이며 Target→B는 방향이 반대입니다. 코어 Target의 Linked A·D와 이 표의 A 한 행을 같은 범위로 비교하면 ‘D가 유실됐다’는 잘못된 결론이 나옵니다.

직접 확인할 때는 Target 노트를 활성화한 코어 패널의 검색어와 제외 설정, 선택한 Base 뷰 이름, 전역/뷰 필터, 활성 파일을 따로 적으세요. 이 시험에서 코어 패널의 검색어는 비어 있었고 격리 볼트에 별도 제외 파일을 설정하지 않았습니다. Base 탭을 활성화하면 코어 패널의 기준은 Target이 아니라 Config/Backlinks.base로 바뀝니다. Base 화면 옆 코어 0건을 Target의 코어 백링크 값으로 읽으면 안 됩니다.

Sources 폴더 안 A는 Target으로 연결하고 B는 이름만 언급한다. 폴더 밖 D도 Target으로 연결하며 Target에서 B로 나가는 링크와 Sources 고정 결과 A를 별도로 표시한 개념도
초기 격리 예제의 방향과 폴더 조건을 단순화한 생성 개념도입니다. Sources/C.md는 처음부터 Sources 안에 있지만, 시작 시 링크가 없어 그림에서 생략했습니다. B의 이름 언급은 링크가 아니며 Target→B는 반대 방향입니다. 실제 앱 화면이나 관측 증거는 아닙니다.

그림을 누르면 크게 볼 수 있습니다.

C를 연결하고 A를 해제했을 때 무엇이 보였나요?

시험 담당자는 일반 작업 볼트를 수정하지 않고, 격리 볼트에서 Obsidian 앱 API app.vault.modify로 C의 연결 없음을 [[Targets/Target]]로 바꿔 저장했습니다. 이어 A의 [[Targets/Target]]을 연결 없음으로 바꿨습니다. 노트 자체를 삭제하지 않았고, 각 단계마다 변경 파일의 내용과 코어 Target 패널, Base All files의 Target 셀, Sources 고정 뷰를 순서대로 기록했습니다. 표의 시각은 KST이며 행 순서는 결과 집합의 순위를 뜻하지 않습니다.

단계·앱 저장 시각 원문상 Target으로 향하는 링크 All files의 Target file.backlinks 셀·관측 코어 Target Linked·관측 Sources to Target 뷰·관측
B1/B2 시작 A·D D·A / 00:47:46.745 A·D / 00:47:44.243 A / 00:47:48.686
B3 C 추가 / 00:47:56.709 A·C·D D·A / 00:47:57.912 A·C·D / 00:48:00.467 A·C / 00:48:02.747
B4 A 링크 제거 / 00:48:11.561 C·D D·A·C / 00:48:12.778 C·D / 00:48:15.335 C / 00:48:17.601

세 열은 각기 다른 화면을 연 시점의 관측입니다. B3의 셀에는 새 C가 아직 보이지 않았고, B4의 셀에는 링크를 제거한 A가 남았습니다. 이는 이번 버전·이 볼트·그 시점의 표시이며 어느 앱에서도 같은 지연이 재현된다는 뜻이 아닙니다. 원본과 고정 역방향 뷰는 바뀌었으므로 셀 하나만 보고 ‘링크가 추가되지 않았다’, ‘A가 아직 링크한다’고 결론 내리지 마세요. 코어 패널을 열 때 다른 파일을 활성화했다면 값이 달라질 수 있습니다. 캡처마다 어떤 파일을 대상으로 했는지 확인해야 합니다.

아래 여섯 화면은 2026년 10월 25일 KST에 순서대로 관측한 확대 캡처입니다. 각 이미지를 누르면 큰 크기로 볼 수 있습니다.

B3: C 링크 추가 후

C 링크를 추가한 뒤 All files의 Target 행에서 파일 링크 Sources/B, 파일 백링크 D와 A만 보이는 실제 격리 앱 캡처 부분
B3: C 추가 후 Target의 file.backlinks 셀은 D·A(2026-10-25 00:47:57.912 KST). 행 부분 확대이며 앞뒤의 코어·필터 뷰와 동시 화면은 아닙니다.
C 추가 후 Target을 활성화한 코어 Backlinks 실제 화면에서 Linked A C D 세 개와 Unlinked B 하나
B3: Target 코어 패널에서 Linked A·C·D와 Unlinked B를 관측(00:48:00.467 KST). 별도 시점·별도 화면입니다.
C 추가 후 Sources to Target 고정 뷰에서 Sources/A.md와 Sources/C.md 두 행이 보이는 실제 격리 앱 캡처
B3: Sources 폴더와 Target으로 향하는 링크를 함께 거른 뷰에는 A·C(00:48:02.747 KST). D는 폴더 밖입니다. Base 활성 중 오른쪽 코어 패널의 기준 파일은 Target이 아니라 Base입니다.

B4: A 링크 제거 후

A 링크 제거 후 All files의 Target 행에서 파일 백링크 D A C가 남아 있는 실제 격리 앱 화면 부분
B4: A의 링크를 제거한 뒤에도 Target의 file.backlinks 셀은 D·A·C(00:48:12.778 KST). 원본 링크와 표시의 차이를 보인 특정 시점의 관측입니다.
A 링크 제거 후 Target 코어 Backlinks에서 Linked C D와 Unlinked B를 보이는 실제 격리 앱 화면 부분
B4: Target 코어 패널은 Linked C·D, Unlinked B(00:48:15.335 KST). 이 화면은 셀 관측보다 나중에 열었습니다.
A 링크 제거 후 Sources to Target 고정 뷰에 Sources/C.md 한 행만 보이는 실제 격리 앱 화면 부분
B4: 고정 Sources to Target 뷰는 C 한 행(00:48:17.601 KST). Base 활성 시 오른쪽 코어 0은 Base를 기준으로 한 수치로, Target의 백링크 0을 뜻하지 않습니다.

file.backlinks의 갱신 경고와 이번 화면은 어떻게 나누나요?

Obsidian의 Bases 구문 문서는 file.backlinks가 무거운 속성이며 볼트 변화에 따라 자동 갱신되지 않는다고 주의합니다. 가능한 경우 조회 방향을 뒤집어 행 파일의 file.links를 활용하라고 권합니다. 고정 타깃으로 찾는 이 예제에서는 file.hasLink("Targets/Target.md")를 각 후보 행→Target 방향에 적용했습니다. 두 방식이 언제나 같은 순간에 같은 화면값을 보인다고 보장할 수 없습니다.

B4의 원문을 유지하고 뷰를 전환했을 때 All files 셀은 D·C(00:48:27.412), Base를 닫았다 다시 열었을 때도 D·C(00:48:30.662)였습니다. 고정 뷰는 모두 C였습니다(전환 후 00:48:29.591, 재열기 후 00:48:32.428). 이번 시험에서 그렇게 보였을 뿐 뷰 전환이나 재열기가 모든 파일·버전에서 반드시 갱신을 해결한다는 근거는 아닙니다. 표시가 계속 다르면 셀 값을 무조건 ‘정답’으로 취급하지 말고 원문 링크·필터·기준 파일·관측 시각을 남겨 설명되지 않은 차이로 기록하세요. 일정한 갱신 시간이나 원인까지 이 시험으로 측정한 것은 아닙니다.

사이드바의 this.file이 달라지면 결과도 달라지나요?

고정 타깃 대신 file.hasLink(this.file)을 사용한 Sources to active 뷰를 오른쪽 사이드바에 두고, 메인 활성 파일만 Target → Sources/B → Target으로 바꿨습니다. B4의 원문인 C·D→Target, Target→B는 그대로였습니다. 사이드바 뷰의 Sources 행은 C → 없음 → C, 같은 단계의 코어 Linked/Unlinked는 Target에서 C·D/B, B에서 Target/없음, 돌아온 Target에서 C·D/B였습니다. 관측은 2026-10-25 KST 00:49:09.546, 00:49:12.320, 00:49:14.967입니다(B6). B로 향한 링크의 출발점인 Target 파일은 Sources 폴더 밖이므로 가운데 빈 표는 링크 손실이 아닙니다.

이번 시험의 Base 배치와 파일 전환은 앱 API로 이뤄졌고, 표·코어는 실제 렌더링 DOM과 화면 PNG로 읽었습니다. 수동으로 메뉴를 눌러 재현했다고 쓰지 않습니다. 사이드바의 기준 파일이 바뀌는 일반 원리는 Bases 구문에 있으며, 표시 위치에 따른 this의 더 넓은 차이는 기존 Bases this 안내를 참고하세요. 이 글은 새 링크 변경 전후의 방향 진단에만 집중합니다.

원본을 지우지 않고 다시 확인하려면 무엇을 적나요?

업무 볼트의 노트나 필터를 바로 삭제하지 마세요. 접근이 허용된 비민감 사본에서 타깃 파일을 하나로 정하고 다음 표를 채우세요. 링크가 보이지 않는다는 이유만으로 원본 노트가 없어졌다고 판단하지 않습니다.

대조 항목 기록할 내용
앱 버전·OS·타깃 경로·관측 시각
실제 링크가 적힌 원본 파일/줄/방향
코어 패널 활성 파일·검색어·제외 설정·Linked/Unlinked
Base 파일·뷰 이름·전역/뷰 필터·선택한 행 폴더
Target의 file.links / file.backlinks 셀과 관측 시각
고정 타깃 file.hasLink(...) 행과 관측 시각
변경 전후 원문·표·패널의 차이 / 설명 못 한 차이

격리 시험을 마친 뒤 A·C의 내용을 초기 바이트로 복원했고, 여섯 고정 입력 파일이 초기와 최종에 6/6 동일한 SHA-256임을 확인했습니다(B7). 앱 실험의 노트 원복 검산이지 사용자 볼트의 안전 보증은 아닙니다. 시험 초기 분리 프로필이 사용자의 기본 볼트를 잠시 자동으로 열어 테스트 쓰기 전에 종료한 이력이 있어, 그 볼트의 앱 내부 설정까지 아무 변화도 없었다고 확인한 것은 아닙니다. 결과는 이 다섯 노트·설정 Base·데스크톱 환경에 한정됩니다. Sync, 모바일, 큰 업무 볼트나 다른 플러그인에서는 시험하지 않았습니다.

In this article

Stay in the loop
Ready to think more clearly about the tools that matter?
New practical notes, no noise. Keep the useful ideas close.
Subscribe