2026-03-29-TIL: 키워드를 모를 때 지식을 구조화하는 방법

TIL

게시 2026/03/29

By August

조회 7 분읽는 시간

개발을 하다 보면 문제를 인지했는데도 검색어가 떠오르지 않아 탐색 자체가 막히는 순간이 있다. 이건 단순히 지식이 부족해서라기보다, 머릿속 지식이 연결 구조 없이 흩어져 있기 때문에 생기는 문제라고 느꼈다.

오늘은 이 문제를 줄이기 위한 방법으로 개인 지식 그래프와 위키 시스템을 어떻게 설계하면 좋은지 정리해봤다.

왜 키워드 문제가 생기는가

개발 지식은 리스트가 아니라 네트워크에 가깝다.

Cache
Redis
TTL
Eviction Policy
DB Load

이런 개념은 각각 따로 존재하지 않고 서로 연결돼 있다. 그런데 실제 학습은 강의, 블로그, 노트처럼 단편적인 입력 위주로 쌓이는 경우가 많다. 그러면 개념은 기억나는데 연결이 약해서, 문제를 봐도 어떤 키워드로 확장해야 할지 떠오르지 않는다.

문서 중심보다 그래프 중심이 낫다

기존 위키형 정리는 보통 문서 하나에 여러 개념을 묶는다. 이렇게 하면 문서는 늘어나지만 관계가 약하다.

반대로 그래프형 정리는:

개념을 노드로 보고
관계를 링크로 다루며
새 개념이 기존 구조 안에 들어오도록 만든다

핵심은 “무엇을 아는가”보다 “무엇이 무엇과 연결되는가”다.

실제로는 어떻게 보이게 되는가

예를 들면 이런 식이다.

Cache -> Redis
Cache -> Cache Miss -> DB Load 증가
Redis -> TTL -> Eviction Policy -> LRU

이 구조가 쌓이면 문제를 봤을 때 바로 정답을 떠올리지는 못하더라도, 어디서부터 탐색을 시작해야 하는지는 훨씬 빨리 잡힌다.

설계 원칙

1. 한 문서에 한 개념을 둔다

backend.md, database 정리.md처럼 큰 문서 하나에 여러 개념을 넣기보다, Cache, Redis, Index, Transaction처럼 개념 단위로 쪼개는 편이 낫다. 그래야 연결이 명확해진다.

2. 문서보다 연결을 먼저 생각한다

새 노드를 만들 때는 내용보다 먼저 관계를 정해야 한다.

이 개념은 어디에 속하는가
무엇과 연결되는가
어떤 문제를 설명하거나 해결하는가

3. 관계에 의미를 부여한다

단순 링크보다 관계의 성격을 생각하는 편이 좋다.

is-a
uses
causes
solves

이 단계가 있어야 위키가 문서 저장소를 넘어 그래프에 가까워진다.

4. 문제 중심 노드를 반드시 넣는다

개념만 정리하면 실제 문제 해결에는 약하다. 그래서 다음 같은 문제 노드를 별도로 두는 게 중요하다고 느꼈다.

N+1
Cache Stampede
Deadlock
Latency 증가

문제 -> 해결 -> 기술 흐름이 만들어져야 실전에서 잘 작동한다.

백엔드 기준으로 묶어보면

루트 카테고리는 이 정도면 충분해 보인다.

API / HTTP
Database
Cache
Messaging
Architecture
Performance
Reliability
Security

그리고 그 아래에서 Cache -> Redis -> TTL, Database -> Index -> Transaction, Problem -> Deadlock 같은 식으로 연결을 키워 나가면 된다.

운영 방법

입력 규칙

새로운 키워드를 발견하면 다음 세 가지만 지키면 된다.

노드를 만든다.
최소 두 개 이상 연결한다.
한 줄 정의를 남긴다.

이 정도만 지켜도 시스템이 계속 확장된다.

매일 확장

새 노드를 많이 만드는 것보다, 기존 노드 사이에 연결을 더 추가하는 쪽이 효과가 크다.

주간 리팩토링

중복 노드를 합치고, 연결을 보강하고, 구조를 조금씩 정리한다. 결국 지식 그래프도 코드처럼 리팩토링이 필요하다.

도구 선택

Obsidian: 로컬 기반, 링크와 그래프 보기가 강해서 가장 잘 맞는다.
Notion: 협업과 문서 정리에는 좋지만 그래프형 구조는 약하다.
Logseq: 블록 기반 정리에 강하고 자동 링크도 편하다.

내 기준에서는 그래프를 실제로 눈에 보이게 다루려면 Obsidian류 도구가 더 잘 맞아 보인다.

실패하는 패턴

정리만 하고 연결하지 않는다.
처음부터 완벽한 구조를 설계하려 한다.
예쁘게 꾸미는 데만 집착한다.

이렇게 가면 결국 위키가 아니라 문서 더미가 된다.

결국 얻는 것

지식 그래프가 쌓이면 검색 능력 자체보다, 문제를 기술 키워드로 번역하는 능력이 좋아진다.

키워드를 몰라도 연결을 따라 탐색할 수 있고
문제를 봤을 때 관련 기술이 더 빨리 떠오르며
설계할 때도 개념을 구조적으로 배치하기 쉬워진다

결국 중요한 건 많이 아는 것이 아니라, 아는 것들이 어떤 구조로 연결돼 있는가라는 생각이 들었다. 개인 위키를 만든다면 문서 수를 늘리는 것보다 연결을 늘리는 쪽이 더 중요하다.

TIL, 2026-TIL