택소노미에서 온톨로지로

난이도 — 입문

블로그를 만들 때 가장 먼저 고민한 건 디자인이 아니라 "나중에 글이 100개가 되면 어떻게 찾지?"였다. 글이 열 개일 땐 아무 문제가 없다. 문제는 항상 나중에 온다.

이런 고민을 다루는 분야를 정보 구조(IA, Information Architecture)라고 부른다. 거창해 보이지만 뜻은 단순하다.

무엇을 어디에 두고, 사람들이 어떻게 찾게 할 것인가.

앞 글에서 구조를 보는 세 가지 관점을 정리했다. 옷장 서랍(택소노미), 지하철 노선도(토폴로지), 가족관계도(온톨로지). 그 눈으로 이 블로그를 다시 보니, 세 가지를 이미 조금씩 다 쓰고 있었다.

이 글은 그 세 단계를 순서대로 짚는다. 각 단계가 무슨 문제를 풀었고, 무엇을 여전히 못 푸는지를 본다.

1단계 — 카테고리 (옷장 서랍)

이 블로그의 모든 글은 카테고리를 하나씩 갖는다. Frontend, Network, React / Next.js 같은 것들이다. 앞 글의 옷장 서랍, 곧 택소노미다. 글 하나가 서랍 하나에 들어간다.

푼 문제 — 직관적이다. 폴더처럼 머릿속에 잘 들어오고, "네트워크 글 보고 싶다"가 바로 된다.

못 푼 문제 — 글이 쌓이면 곧바로 막힌다. 예를 들어 이 블로그에는 "SSE를 Next.js 프록시로 중계한" 글이 있다. 이건 Network일까 React / Next.js일까?

둘 다인데, 하나만 골라야 한다. 앞 글에서 본 "양털 후드집업" 문제가 그대로 재현된다. 결국 다른 쪽으로 찾아온 독자는 이 글을 놓친다.

2단계 — 태그와 관련 글 (지하철 노선도)

그래서 태그가 필요하다. 카테고리는 하나만 고르지만, 태그는 여러 개를 붙일 수 있다.

아까 그 글에 SSE, Next.js, Network를 전부 붙이면, 이 글은 더 이상 서랍 하나에 갇힌 물건이 아니다. 여러 글과 옆으로 이어진 정거장이 된다. 앞 글의 지하철 노선도, 곧 토폴로지다.

이 블로그의 "관련 글" 추천도 이 위에서 돌아간다. 실제 코드(getRelatedPosts)는 이렇게 점수를 매긴다.

겹치는 태그 1개당      +1점
카테고리까지 같으면    +2점
→ 점수가 높은 순으로 관련 글로 보여준다

말로 풀면 이렇다. "태그를 많이 공유할수록 가까운 글이다." 특별한 알고리즘이 아니라 겹치는 개수를 세는 것이다.

푼 문제 — 카테고리가 못 잡던 가로지르는 길이 생겼다. 서랍을 건너뛰어 글끼리 이어진다.

못 푼 문제 — 이 그물은 연결의 종류를 모른다. A와 B가 이어졌다는 것만 알 뿐, 어떻게 이어졌는지는 모른다.

카테고리로 큰 줄기를 세우고, 태그로 가로 연결을 깐다. 대부분의 블로그가 여기까지 온다. 이 블로그도 지금 여기 있다.

3단계 — 관계에 이름 붙이기 (가족관계도)

여기서 한 걸음 더 갈 수 있다.

지금의 "관련 글"은 전부 똑같이 생겼다. 그냥 "관련 글"이다. 그런데 실제 글 사이의 관계는 종류가 다르다.

• HTTP 기초는 TCP/UDP/QUIC을 읽기 전에 읽어야 하는 글이다
• SSE 실전은 SSE 개념의 응용편이다
• 네트워크 토폴로지는 이 글과 개념을 나눠 쓴다

이렇게 선마다 이름표를 달면 그게 앞 글에서 본 가족관계도, 곧 온톨로지다. 위 그림의 3단계 탭이 그 모습이다.

무엇이 좋아질까. 독자에게 이렇게 보여줄 수 있다.

• "이 글을 읽기 전에 이것부터" — 선행 지식
• "다음 단계는 이것" — 심화

즉 학습 순서가 데이터에서 저절로 나온다. 지금은 사람이 글 안에 손으로 링크를 적어야 하는 일이다.

거창한 시스템이 필요한 것도 아니다. 글 맨 위 설정(프론트매터, frontmatter)에 한 줄만 더 적으면 시작할 수 있다.

related:
  - slug: tcp-udp-quic
    relation: 먼저-읽을-글

남는 문제 — 이건 공짜가 아니다. 글을 쓸 때마다 관계를 사람이 직접 적어야 한다. 글이 적을 땐 할 만하지만, 많아지면 부담이 된다. 그래서 이 블로그는 아직 여기까지 오지 않았다.

세 단계를 한 장으로

중요한 건 셋이 경쟁 관계가 아니라는 점이다. 아래 순서가 자연스럽다.

카테고리로 줄기를 세우고 → 태그로 가로 연결을 깔고 → 꼭 필요한 곳에만 관계 이름표를 붙인다.

처음부터 3단계로 시작할 필요는 전혀 없다. 오히려 글이 몇 개 없을 때 정교한 관계를 설계하면, 관리되지 않는 설정만 남는다.

정리

• 정보 구조는 글이 쌓인 뒤에 고치기 가장 어려운 것 중 하나다. 그래서 미리 생각해 둘 값어치가 있다.
• 다만 미리 정할 것은 완벽한 구조가 아니라, 어디까지 갈지다.
• 이 블로그는 지금 2단계(태그·관련 글)에 있다. 3단계는 글이 더 쌓였을 때의 숙제로 남겨 둔다.

다음 글에서는 이 "관계 이름표"가 실제 데이터로는 어떻게 생겼는지 — 지식 그래프와 RDF에서 이어서 본다.