노트 수백 개를 AI가 빠르게 쓰게 만들기,
온톨로지를 시도하다 더 가벼운 걸 찾았다

노트를 몇 년 모으면 금방 수백 개가 된다. 그런데 막상 AI에게 "이 주제로 내가 했던 거 전부 모아줘"라고 시키면, AI는 파일을 하나씩 다 열어보느라 느리고, 비용도 많이 들고, 그러고도 절반은 놓친다. 거창한 '온톨로지'를 입히면 될 줄 알았다. 그런데 훨씬 가볍고 거의 공짜인 방법이 따로 있었다. 이건 그 방법을 찾아간 기록이다.

대상: 노트 많이 쌓인 사람 · AI로 일 빠르게 하려는 사람  ·  사례: Obsidian + Claude Code PKM 볼트  ·  2026-06-23

1한 고객사 일을 전부 모아달라니까, 시스템이 헤맸다

내 상황부터 보자. 나는 마케팅, 데이터 분석, 코드, 기획을 한다. 몇 년치 메모가 한 곳에 쌓였다. 노트를 모아두는 이런 묶음을 흔히 '볼트(vault)'라고 부른다. 정리해 둔 지식이 210개, 진행한 프로젝트 기록이 160개, 작업용 메모가 56개. 정리는 나름 잘 해뒀다고 생각했다. 주제별 폴더로 나누고, 파일마다 맨 위에 꼬리표(제목·태그·날짜 같은 정보를 적어두는 칸인데, 이걸 '머리말'이라 한다)를 붙이고, 목차까지 만들어 뒀으니까.

그런데 막상 AI에게 일을 시키자 허점이 드러났다. 예를 들어 내가 일하는 고객사 하나를 'A사'라고 하자. "A사 관련해서 했던 거 전부 모아줘"라고 부탁하면, AI는 노트 묶음 전체를 단어로 뒤지고, 걸리는 파일을 하나 열고, 또 하나 열고, 그렇게 수십 개를 헤맸다. 읽는 양이 많으니 비용(AI는 글을 읽고 쓰는 양에 비례해 요금이 드는데, 이 단위를 '토큰'이라 부른다)이 줄줄 샜다. 더 답답한 건, 그렇게 고생하고도 빠뜨리는 게 있었다는 거다. 어떤 파일은 본문에 'A사'라는 글자가 아예 없었고, 어떤 건 엉뚱한 폴더에 들어 있었기 때문이다.

규모를 숫자로 보면 이렇다. "A사 일이 지금 어디까지 왔는지 요약해줘" 한 번이면, AI는 관련 파일 12개를 통째로 다 읽어야 했다. 합치면 약 10만 자. 그걸 물어볼 때마다 매번 반복한다. 폴더로 분류는 돼 있는데, 정작 흩어진 것들을 한데 이어줄 연결이 없었던 것이다.

이미지: 분류는 돼 있는데 연결이 없는 상태. AI가 매번 헤집는다.

이 "연결이 없다"는 문제를 풀려고, 나는 그럴듯한 단어를 하나 떠올렸다. 온톨로지.

2'온톨로지'라는 단어는, 내가 원한 것보다 훨씬 무거웠다

온톨로지(ontology)는 거칠게 말하면 "무엇이 무엇과 어떻게 연결되는지를 미리 구조로 정해두는 것"이다. 우리가 흔히 하는 폴더 분류가 "이 파일은 어느 서랍에 넣지?"를 정하는 일이라면, 온톨로지는 "이 개념은 무엇과 이어지나?"를 정하는 일이다. 서랍이 아니라 거미줄 같은 연결망을 만드는 셈인데, 딱 내가 바라던 그림이었다.

원하는 조건은 분명했다. 늘리기 쉽고, 쓰기 편하고, 가볍고, 잘 연결되는 것. 그래서 비슷한 걸 만든 공개 프로젝트 몇 개를 찾아 나란히 놓고 봤다. 그랬더니 이것들은 서로 경쟁하는 도구가 아니라, 가벼운 것부터 무거운 것까지 줄을 선 '무게 사다리'로 보였다. 똑같이 "연결"을 한다는데, 들이는 품과 무게가 천차만별이었다.

여기서 첫 교훈을 얻었다. 나는 방향은 맞게 잡았는데, 그걸 부르는 단어를 너무 무거운 걸로 골랐던 거다. 내가 원한 "가볍게 연결"은 사다리의 왼쪽 끝인데, 막상 '온톨로지'라는 말은 보통 오른쪽 끝, 그러니까 사실을 논리로 일일이 검증하는 거창한 시스템을 가리켰다. 혼자 일하는 사람이 그런 걸 손으로 관리하기 시작하면 어떻게 될까. 그 관리 자체가 본업 못지않은 일거리가 되고, 결국 손이 안 가 방치되다 망가진다. 그래서 오른쪽 끝은 일찌감치 접었다.

3그런데 무서웠다, 미리 정해두면 새 생각이 옛 칸에 뭉개진다

오른쪽 끝(거창한 시스템)을 접고 나니, 더 근본적인 데서 걸리는 게 있었다. 나는 새로운 걸 끝없이 주워 담는 편이다. 오늘 배운 걸 적어두고, 내일 또 다른 걸 적는다. 머릿속엔 있지만 아직 글로 안 옮긴 것도 많고, 그 양은 계속 늘어난다. 그러니 "구조를 미리 정해둔다"는 온톨로지의 전제가 영 불안했다.

구조를 미리 못 박아두면, 나중에 들어온 새 개념을 억지로 옛 칸에 욱여넣게 되기 때문이다. 그러면 그 새로움이 죽는다. 비슷해 보이지만 사실은 다른 것을 하나로 뭉개버리니까. 예를 들어 '애플'은 회사고 '애플워치'는 그 회사가 만든 제품인데, "둘 다 애플이잖아" 하며 하나로 합쳐버리면 회사와 제품의 구분이 사라진다. 같은 단어를 다르게 적은 표기 차이가 아니라 뜻이 엄연히 다른 사이인데도 말이다. 실제로 내가 파일에 붙여 둔 주제 꼬리표('태그'라고 부른다)에도 그런 위험이 깔려 있었다.

미리 정해둔 칸에 새 생각을 욱여넣어 뭉개면, 정리하는 의미가 없는 거 아닌가?

이미지: 새 생각을 너무 빨리 옛 칸에 넣으면, 정리보다 손상이 먼저 온다.

이 걱정이 설계 전체의 방향을 갈랐다. 답은 의외로 단순했지만, 거기 닿는 데 한참 걸렸다. 핵심은 이거였다. 대부분의 새 개념은 애초에 구조에 넣지 않는다. 그냥 자유로운 메모로 두고, 필요할 때 검색으로 찾으면 된다. 다시 말해, 연결망은 "계속 불어나는 모든 것"을 다 떠받치려 하지 않는다. 이미 자리를 잡은 핵심 몇 개만 가볍게 묶어두고, 나머지는 검색에 맡긴다. 전부 따라잡으려 욕심내지 않는 것, 그게 비결이었다.

4새로 만들 게 아니라, 이미 적어둔 걸 뒤집기만 하면 됐다

그 깨달음에서 모든 게 풀렸다. 내게 부족했던 건 거창한 온톨로지가 아니라, 평범한 노트 위에 살짝 얹는 가벼운 '연결 지도'였다. 그리고 그 연결의 재료는, 놀랍게도 이미 내 파일마다 적혀 있었다.

무슨 말이냐면 이렇다. 내 프로젝트 기록은 파일마다 맨 위에 이런 꼬리표가 달려 있다. 코드처럼 보여도 겁먹지 말자. 그냥 "이건 누구 일이고, 무슨 주제인가"를 적어둔 메모일 뿐이다.

--- 'A사 광고 트래킹.md' 파일 맨 위의 꼬리표 ---
project: "A사 광고 트래킹"   # 어떤 프로젝트
client:  A사            # 어떤 고객
role:    [기획, 개발]      # 내 역할
tags:    [광고, 데이터, 추적]  # 주제 태그

여기 적힌 '고객', '프로젝트', '태그'가 바로 연결의 실마리다. 같은 'A사'라고 적힌 파일끼리는 이미 이어져 있는 셈이니까. 단지 그 표시가 200개 파일에 뿔뿔이 흩어져 있을 뿐이었다. 그러니 연결망을 새로 그릴 필요가 없었다. 이미 적어둔 꼬리표를 거꾸로 긁어모아, "'A사'라고 적힌 파일 전부"를 한 줄로 묶기만 하면 됐다. 그리고 이 긁어모으는 일은 AI가 아니라 평범한 프로그램이 한다.

# 꼬리표를 긁어모아 목록을 만든다 (AI 없이, 평범한 프로그램으로)
$ python3 build_all.py
→ 고객·프로젝트·태그별 목록 145개 묶음 생성 완료

그 결과로, "A사 관련 전부"가 아래 한 줄로 깔끔하게 정리된다. 이제 AI는 파일을 일일이 헤맬 필요 없이, 이 한 줄만 읽으면 끝이다.

{ 고객: "A사",  연결된 파일: 28개,
  분야: [기획, 마케팅, 개발],
  목록: [... 파일 28개 경로, 폴더 3곳에 흩어진 것까지 전부 ...] }

이미지: 빌드타임은 파이썬이 굽고, 리드타임에 AI는 한 줄만 집어 든다.

여기까지가 큰 그림이다. 이제 왜 이게 그렇게 싸고, 정말 효과가 있었는지 한 겹씩 들춰보자.

왜 싼가: 일하는 주체가 다르다

핵심은 "누가 일하느냐"다. 이 목록을 AI가 직접 만들면 토큰(앞에서 말한 그 비용)이 든다. 하지만 평범한 프로그램이 만들면 AI 비용은 0이다. 똑같은 결과물인데, 드는 비용의 종류가 다른 것이다. 내가 아끼고 싶었던 건 AI 비용인데, 목록을 다시 만드는 데 드는 건 그저 내 컴퓨터가 2초 동안 도는 것뿐이다. 그쪽은 사실상 공짜다. 그래서 "바뀔 때마다 목록을 통째로 다시 만든다"고 하면 비효율처럼 들리지만, 실은 가장 싼 방법이었다.

정말 줄었나: 직접 재봤다

"A사 일이 어디까지 왔는지 요약" 같은 작업에서, 파일을 전부 여는 옛 방식과 짧은 목록만 읽는 새 방식이 각각 얼마나 읽는지 글자 수로 직접 비교했다.

A사가 13.3배까지 줄어든 건 그 프로젝트 기록이 유독 길어서다(파일 하나가 평균 8,700자). 문서가 길수록 절감 폭이 커진다. 어림짐작이 아니라 글자 수로 직접 잰 값이다. 다만 정직하게 짚어두자. 이 절감은 "찾고 요약하는" 작업에만 해당한다. 문서 본문을 통째로 읽어야 하는 일이라면 결국 파일을 열어야 하니, 거기엔 이득이 없다.

그런데 두 번 속았다

여기까지만 보면 깔끔한 성공담이다. 그런데 이 그림에는, 만드는 과정에서 나를 두 번이나 속인 함정이 숨어 있었다. 그 얘기를 빼면 정직하지 않다.

5두 번 속았다: 압축 형식이 더 컸고, 목록은 절반만 봤다

첫 번째: "압축이니 작겠지"가 실측 앞에서 무너졌다

나는 처음에 확신했다. 사람이 보기 좋은 표 형식 대신, 기계가 읽기 좋은 압축 형식으로 목록을 만들면 분량이 줄어 AI 비용도 줄 거라고. 압축이니까 당연히 더 작겠지 싶었다. 그래서 만들어 놓고 크기를 재봤다.

이유는 단순했다. 기계용 압축 형식은 줄마다 '제목:', '설명:' 같은 항목 이름을 매번 다시 적는다. 사람용 표는 그걸 맨 위에 딱 한 번만 적는다. 그러니 압축 쪽이 오히려 더 커졌다. 아무리 군더더기를 빼도 표보다 컸다. "압축이니 당연히 작다"던 내 직관이, 직접 재보니 그냥 틀렸던 거다. 그래서 그 부분은 통째로 접었다. 자존심은 상했지만, 덜 만드는 게 정답이었다. 만드는 게 줄면 나중에 어긋날 위험도 같이 줄어드니, 결과적으론 오히려 이득이었다.

두 번째: 목록이 나에게 거짓말을 했다

두 번째 함정이 더 아찔했다. 목록을 다 만들고, 잘 돌아간다고 결론까지 내린 뒤였다. 그런데 다른 작업을 하다가, 점검용 프로그램 하나가 이상한 걸 뱉었다. 분명히 정리를 끝냈는데, 정리 안 된 항목이 한 무더기 남아 있는 게 아닌가.

원인은 어이없게도 한 줄이었다. 목록을 만드는 프로그램이 폴더를 훑을 때, 맨 바깥 폴더만 보고 그 안쪽 하위 폴더는 들여다보지 않고 있었던 것이다. 하필 내 지식의 대부분은 그 하위 폴더에 들어 있었다. 즉 가장 큰 덩어리인 210개 파일을 통째로 못 보고도 "다 했다"고 한 셈이다. 실제로 살펴본 건 전체 432개 중 156개뿐이었다.

이미지: 비어 보이지 않는 인덱스가 가장 위험하다.

여기서 교훈을 둘 얻었다. 하나, '비어 보이지 않는' 목록이 가장 위험하다. 아예 텅 빈 목록은 그래도 의심이라도 하는데, 절반만 채워진 목록은 "뭔가 있으니 맞겠지" 하고 그냥 믿어버린다. 그게 더 위험하다. 둘, 이걸 잡아낸 건 내 눈이 아니라 자동 점검 프로그램이었다. 눈으로 대충 훑었으면 절대 못 잡았다. 시스템이 나에게 거짓말을 하고 있지 않은지 스스로 따져 묻는 장치, 그게 꼭 있어야 한다는 걸 배웠다.

6자동화가 새 개념을 안 뭉개게: 안전장치

이제 3장에서 품었던 두려움으로 돌아가자. "정리를 자동화하면, 새로 떠오른 생각이 옛 칸에 뭉개지지 않을까?" 답부터 말하면, 기계가 알아서 합치는 건 딱 하나, 같은 단어를 다르게 쓴 표기 차이뿐이다. 그것도 원래 표기를 지우는 게 아니라 따로 살려두는 방식이라, 잃는 게 없다.

그리고 가장 중요한 장치가 하나 더 있다. 새로 생긴 주제 태그는 최소 네 번은 등장해야 정식 항목으로 올라간다. 그 전까지는 자유로운 메모 상태로 남아 검색으로만 찾힌다. 새 생각이 옛것에 흡수당하는 게 아니라, 충분히 반복돼서 "이건 진짜 자주 쓰는 개념이구나" 싶을 때 비로소 제 자리를 얻는 것이다. 끝없이 새 걸 주워 담는 나 같은 사람을 위한 안전장치인 셈이다.

7아직 남은 흉터

전부 깔끔하게 풀었다고 하면 거짓말이다. 끝내 못 풀었거나 어설프게 메운 것 몇 개는 그냥 남았다.

우선 되돌리기 안전장치가 통째로 빠져 있었다. 작업 이력을 시점별로 저장해 언제든 되돌리게 해주는 도구가 있는데, 내 컴퓨터 환경의 호환 문제로 그게 작동하지 않았다. 그래서 작업 내내 제대로 된 백업이 없었고, 수정할 때마다 사본을 하나씩 따로 남긴 게 유일한 되돌림 수단이었다. 더 곤란한 건 한참 뒤에야 알았다는 점이다. "변경된 게 없다"던 내 점검 결과가, 사실은 그 도구가 소리 없이 실패하고 있던 탓이었다. 이것 역시 조용히 숨어 있던 오류였다.

다음으로, 한 고객의 파일 묶음에서 셋이 빠질 뻔했다. 파일 이름이 들쭉날쭉했던 데다, 어떤 건 프로젝트명 칸이 아예 비어 있어서 자동 규칙이 그 셋을 못 잡았다. 이번에도 자동 점검이 잡아줬기에 망정이지, 아니었으면 "A사 일 전부"라고 물었을 때 조용히 셋을 빠뜨렸을 것이다. 결국 예외 목록에 손으로 적어 메웠다. 깔끔하진 않아도 정직한 해법이었다.

마지막으로, 파일 맨 위 꼬리표의 문법이 깨진 파일 다섯 개가 모든 목록에서 조용히 빠져 있었다. 내가 만든 버그도 아니고 원래 그랬다. 꼬리표에 따옴표를 빠뜨린 탓에, 프로그램이 그 파일들을 통째로 건너뛰고 있었던 것이다. 발견하자마자 고쳐 되살렸지만, 결국 '소리 없이 빠지는 것'이야말로 이 시스템의 공통된 적이라는 걸 다시 한번 확인한 셈이다.

8가져갈 것: 가볍고 연결되는 지식 시스템 체크리스트

온톨로지라는 단어에 끌렸다면, 먼저 이걸 물어보자. 내가 원하는 게 "논리로 답을 증명하는 시스템"인가, 아니면 그냥 "연결되고 빨리 찾히는 것"인가. 후자라면, 무거운 온톨로지는 필요 없다. 다음 순서로 가벼운 걸 만들면 된다.

결국 내가 만든 건 거창한 온톨로지가 아니었다. 이미 적어둔 걸 기계가 공짜로 거꾸로 긁어모아, 작은 목록으로 묶어둔 것. 그게 전부다. 새 생각은 자유롭게 떠다니다 충분히 반복되면 제 자리를 얻고, 시스템은 정비할 때마다 조금씩 더 정직해진다. 빠른 일처리는 그 정직함이 따라온 결과였다. 그러니 "점점 발전하는 나"라기보다는, 점점 덜 거짓말하는 시스템이 나를 빠르게 만들어 준 것에 가깝다.

근거·출처: 비용 절감(2.9~13.3배)·실제로 본 파일 수(156→432)·목록 크기 비교는 모두 직접 실행해 측정한 값이다. 무게 사다리의 세 참고 구현은 godstale/LLM-WiKi(글끼리 링크), hang-in/seCall(관계에 이름표 + 검색), 그리고 추론 엔진을 붙이는 온톨로지 기반 강의다. 사례는 개인 지식 노트 묶음을 AI가 다루기 좋게 정비한 기록(2026-06)이며, 등장하는 고객명(A사 등)은 일반화한 가명이다.