태그보다 위키링크를 먼저 쓰는 이유

이 글은 옵시디언을 쓰면서 생긴 생각이다. 다른 노트 도구에도 비슷하게 적용될 수는 있지만, aliases, 링크되지 않은 언급, 문맥에 맞춘 링크 이름처럼 옵시디언이 제공하는 기능을 전제로 한다.

나는 한동안 태그를 노트 정리의 기본 도구로 생각했다. Node.js에 관한 글에는 #nodejs, 쿠버네티스에 관한 글에는 #kubernetes를 붙였다. 짧고 눈에 잘 띄고, 누르면 관련 노트를 한꺼번에 볼 수 있으니 편했다.

그런데 노트가 늘어날수록 태그가 답하지 못하는 질문도 함께 늘었다.

• 이 태그는 정확히 무엇을 뜻하는가?
• 이 노트에는 왜 이 태그를 붙였는가?
• 이 태그는 다른 개념과 어떤 관계인가?

태그는 노트를 모으는 데는 능숙하지만, 그 이유를 말해 주지는 못한다. 그래서 지금은 태그를 붙이기 전에 위키링크로 표현할 수 있는지 먼저 생각한다.

태그에는 설명을 적을 자리가 없다

#kubernetes를 누르면 쿠버네티스와 관련된 노트를 모아 볼 수 있다. 하지만 태그 자체에는 내용을 적을 수 없다. 내가 쿠버네티스를 어떻게 정의하고 있는지 설명할 자리가 없다.

위키링크는 다르다. [[kubernetes]]라는 노트를 만들면 그 안에 현재의 정의와 판단 기준을 적을 수 있다.

# Kubernetes

오픈소스 컨테이너 오케스트레이션 시스템이다.

- [[pod|Pod]]는 하나 이상의 컨테이너를 담는, 배포 가능한 가장 작은 단위다.
- [[node|Node]]는 [[pod|Pod]]가 실행되는 물리 또는 가상 워커 머신이다.

이제 Kubernetes는 목록을 여는 표지가 아니라, 계속 고칠 수 있는 하나의 노트가 된다. 다른 노트에서 [[kubernetes]]를 가리키면 링크를 따라 정의를 읽을 수 있고, 쿠버네티스 노트에서는 백링크를 통해 이 생각이 쓰인 맥락을 거꾸로 볼 수 있다.

많아질수록 선택이 어려워진다

태그가 열 개일 때는 별문제가 없다. 백 개가 되면 새 노트를 쓸 때마다 이미 있는 태그를 기억해야 한다. #infrastructure와 #kubernetes, #observable과 #observability 그리고 #monitoring 중 무엇을 썼는지 확인하는 일이 생긴다. 다시 찾을 때도 비슷한 태그를 하나씩 열어 봐야 한다.

물론 이것은 태그만의 잘못은 아니다. 모든 단어를 위키링크로 만들면 똑같은 문제가 링크에서 반복된다. 내용 없는 노트 백 개를 만들어 놓고 태그 백 개를 없앴다고 해도 시스템은 단순해지지 않는다.

차이는 링크 대상에 내용을 쌓을 수 있다는 데 있다. 반복해서 설명하거나 다른 이름으로 자주 부르거나, 여러 생각의 기준점이 될 개념만 노트로 만든다. 그렇게 할 가치가 없는 말이라면 링크도 태그도 만들지 않는다.

계층보다 관계가 필요하다

옵시디언은 #infrastructure/kubernetes처럼 계층 태그를 지원한다. 그래서 태그끼리 전혀 연결할 수 없다고 말하면 정확하지 않다. 다만 중첩 태그가 표현하는 것은 주로 상위·하위의 분류 관계다.

내가 노트에서 남기고 싶은 관계는 그보다 다양하다.

[[kubernetes|쿠버네티스]]를 사용할 때 [[infra|인프라]]를 어떻게 가져갈지 먼저 고민해야 한다.

[[pod|Pod]]는 [[node|Node]]에서 실행되는 더 작은 단위이므로 리소스 분배를 고려해야 한다.

첫 문장은 조건과 우선순위를, 둘째 문장은 두 개념을 나누는 기준을 말한다. #infrastructure/kubernetes 같은 계층으로는 이 관계를 자연스럽게 남기기 어렵다. 위키링크가 관계를 자동으로 만들어 주는 것은 아니지만, 적어도 문장이 관계를 설명할 자리를 준다.

같은 대상을 다른 이름으로 부를 수 있다

같은 개념도 맥락이나 언어에 따라 이름이 달라진다. kubernetes, k8s, 쿠버네티스를 각각 태그로 만들면 하나의 대상을 세 갈래로 나누게 된다.

옵시디언에서는 정본 노트 하나에 aliases를 적을 수 있다.

---
aliases:
  - k8s
  - 쿠버네티스
  - 쿠버
---

이후 쿠버라는 별칭으로 링크하고 싶다면 옵시디언은 [[kubernetes|쿠버]]처럼 같은 노트를 가리키는 링크를 만든다. Backlinks의 링크되지 않은 언급에서도 파일 이름과 별칭이 쓰인 곳을 찾아볼 수 있다. 이미 본문에 kubernetes라고 적어 둔 노트를 발견한 뒤, 필요한 것만 실제 링크로 바꾸는 식으로 쓸 수 있다. 링크를 잊었더라도 관계를 발견할 수 있다는 뜻이다.

한 문장에서만 표현을 바꾸고 싶다면 별칭을 추가할 필요도 없다.

요즘은 [[kubernetes|오픈소스로 컨테이너를 오케스트레이션하는 방법]]을 다시 생각하고 있다.

링크 대상은 kubernetes로 유지하면서도 문장은 원래 흐름대로 읽힌다. 노트 제목에 문장을 억지로 맞추지 않아도 된다.

그래도 태그가 더 나은 때가 있다

여기까지 쓰면 태그를 전부 없애도 될 것 같다. 하지만 실제로는 그렇지 않았다.

태그는 같은 주제의 노트를 즉시 모으고 필터링하는 데 여전히 단순하다. 예를 들어 개발, 투자, 일상 기록에 모두 걸쳐 있는 security 노트를 한 번에 찾고 싶다면 태그 하나가 편하다. 그 결과를 얻기 위해 내용이 거의 없는 [[Security]] 노트를 만들고 모든 글에 링크하는 것은 오히려 돌아가는 방법일 수 있다.

그래서 현재 기준은 이렇다.

• 그 자체로 설명할 내용이 있는 개념이나 대상이면 위키링크를 쓴다. 특히 고유명사는 위키링크를 우선한다.
• 두 생각의 관계를 문장으로 말할 수 있으면 위키링크를 쓴다.
• 여러 맥락을 가로질러 같은 주제로 반복해서 필터할 때만 태그를 쓴다.
• 다시 찾을 구체적인 이유가 없다면 둘 다 쓰지 않는다.

결국 내게 위키링크는 태그의 완전한 대체재라기보다 먼저 검토할 기본값에 가깝다. 태그가 목록을 만든다면 위키링크는 설명할 장소와 관계를 만든다. 노트를 다시 읽을 때 필요한 것은 비슷한 글의 목록만이 아니라, 왜 이어 놓았는지 이해할 수 있는 문맥이기 때문이다.