노션을 떠나기 전에 나눠야 할 것, 노트와 데이터

노션을 떠나 옵시디언으로 이사하는 사람들의 글이 부쩍 많아졌습니다. 이번에 읽은 글은 그중에서도 정직한 편이에요. 노션을 거의 초창기부터 써왔고, 디자인 스튜디오를 운영할 때는 비즈니스 플랜을, 지금은 플러스 플랜을 쓰는 사람이 주말마다 산더미 같은 레거시를 옮기고 있다는 이야기입니다. 저는 이 글의 진단 하나에는 깊이 동의하고, 그 진단에서 나온 해법에는 조건을 하나 달고 싶습니다. 어떻게 옮겼는지는 다음 편으로 미룬다고 했으니, 이번엔 왜 떠나는지에 대한 판단만 놓고 보겠습니다.

독자가 한 명 늘었다는 진단

떠나는 첫 번째 이유는 AI였습니다. 이 사용자는 클로드를 거의 모든 업무에 쓰는데, 노션 MCP가 분명히 어딘가 적어둔 노트를 못 찾거나 엉뚱한 걸 가져오는 일이 잦았어요. 그때마다 손으로 관련 노트를 찾아 붙여주거나 마크다운으로 뽑아 넘기다 보니, 도와주는 도구를 쓰는데 오히려 자기가 도구를 떠먹여 주는 꼴이 됐다는 겁니다.

옮기면서 생각이 바뀐 지점이 이 글의 핵심입니다. 노션이 나빠진 게 아니라, 내 정리를 읽는 게 이제 사람만이 아니게 됐다는 것. 올해 4월 Andrej Karpathy가 LLM을 개인 지식 베이스를 만드는 데 쓰고 있다는 글을 올려 조회수 1,600만을 넘긴 일도 같은 맥락으로 소개돼요. 지금의 RAG 방식은 배고플 때마다 처음부터 요리하는 것과 같으니, 지식을 마크다운으로 차곡차곡 쌓아두고 AI가 그 위키를 참조하게 하자는 아이디어였죠.

저는 '독자가 한 명 더 늘었다'는 표현이 이 글에서 가장 좋은 문장이라고 봐요. 사람끼리는 정리를 느슨하게 해도 정리한 사람이 맥락을 기억하고 빈칸을 메웁니다. AI는 그 맥락을 같이 갖고 있지 않으니, 머릿속에만 있던 걸 한 번 더 밖으로 꺼내 적게 되죠. 표가 중구난방이어도, 네이밍이 제멋대로여도 "내가 알아보면 됐지" 하고 넘어가던 습관이 맥락을 공유하지 않는 독자 앞에서는 통하지 않는 겁니다. 정리가 편해진 게 아니라 정직해진 셈이에요. 그리고 그렇게 꺼낸 정리, 즉 일관된 메타데이터와 한 노트에 하나의 개념, 명확하게 연결된 링크는 결국 사람도 따라가기 쉬운 구조라는 결론에도 지식 노트에 한해서는 동의합니다.

막힌 곳은 포맷이었을까, 통로였을까

그런데 글에 구체적으로 적힌 불편을 다시 읽어보면, 상당수가 노션이라는 포맷이 아니라 클로드의 기본 노션 커넥터에서 나옵니다. 커넥터는 시맨틱 검색을 하는데 한 번에 가져오는 결과가 열 개 남짓이고 그마저 모호합니다. 상태나 날짜, 타입 같은 속성값으로 필터링하거나 정렬하거나, 큰 데이터베이스를 페이지를 넘겨가며 훑는 게 잘 안 되고, "이 데이터베이스에 있는 거 전부 보여줘" 같은 요청이 의외로 까다롭고, 큰 데이터베이스를 통째로 읽으면 토큰이 만 단위로 빠진다고요.

이건 표가 AI에게 나빠서 생긴 문제라기보다, 표를 표답게 읽지 못하는 통로의 문제에 가깝습니다. 구조화된 데이터는 원래 구조화된 질의로 읽어야 정확해요. 상태가 '진행 중'인 프로젝트만, 날짜순으로, 50개씩 넘겨가며. 이런 요청을 시맨틱 검색으로 처리하면 어느 도구든 헤맵니다. 1만 개가 넘는 노트를 몇 주에 걸쳐 옮기는 비용과, 필터와 정렬이 되는 통로를 붙이는 비용을 나란히 놓고 보면 계산이 달라질 수 있어요.

검색 이야기도 같은 갈래입니다. 노션의 파일 검색이 원래 답답했고, 관련 노트를 찾으려면 일일이 검색해야 하는데 그마저 원하는 대로 잡히지 않았다는 불만이 두 번째 이유였죠. 이건 사람에게도 AI에게도 똑같이 걸리는 문제라, 노트를 마크다운으로 옮겨 링크로 엮는 이사가 확실히 효과를 볼 영역입니다. 반대로 첫 번째 이유, AI가 데이터베이스를 못 읽는다는 불만은 이사보다 통로 교체로 풀릴 여지가 큽니다. 두 이유를 한 번의 이사로 묶으면, 효과가 큰 쪽의 성과가 비용이 큰 쪽의 손실을 가려버리기 쉬워요.

칸반은 사람의 것이다

이사하면서 잃는 것도 정직하게 적혀 있습니다. 모든 프로젝트를 노션 데이터베이스로 만들어 히스토리를 추적해왔고, 칸반 보드로 진행 상황을 보고 타임라인으로 흐름을 보는 시각화가 프로젝트를 끌고 갈 때 정말 강력했는데, 옵시디언은 이걸 노션만큼 매끄럽게 해주지 못한다고요. 데이터베이스를 나누면 연관 노트가 잘 안 이어지고, 한곳에 다 넣으면 정리가 감당이 안 된다는 고민도 덧붙였습니다.

제가 조건을 다는 지점이 바로 여기예요. 사람이 편한 구조와 AI가 편한 구조가 같다는 결론은 지식 노트에는 맞지만, 상태와 날짜와 담당자를 가진 운영 데이터에는 맞지 않습니다. 칸반과 타임라인은 사람이 한눈에 흐름을 보기 위한 것이고, AI가 그 데이터를 다룰 때 필요한 건 그림이 아니라 정확한 질의예요. 이 사용자가 아쉬워한 그 시각화가 바로 둘이 갈라지는 자리입니다.

그래서 저라면 이사를 시작하기 전에 먼저 나누겠습니다. 생각과 지식을 담은 노트는 마크다운으로 옮겨 AI가 위키처럼 참조하게 하고, 프로젝트와 할 일처럼 상태가 바뀌는 데이터는 표로 남겨두되 AI가 필터와 정렬로 읽을 수 있는 통로를 붙이는 쪽으로요. 본인도 일부는 노션에 그냥 둘지 모른다고 했는데, 저는 그 '일부'의 기준이 노트냐 데이터냐여야 한다고 봅니다.

글 마지막에 나온 디자인시스템 이야기도 이 구분과 잘 맞습니다. 토큰을 일관되게 정하고 컴포넌트를 나누고 네이밍 규칙을 잡는 일은 사람끼리 맥락을 맞추려는 정리였는데, 이제 AI가 참조할 레퍼런스이기도 하다는 것. 디자인 시스템은 지식에 가까워서 마크다운으로 꺼내 적기 좋고, 그 위에서 돌아가는 프로젝트 일정은 데이터에 가깝습니다. 정리를 바꾸는 시대라는 데는 동의하지만, 바꿔야 할 건 모든 것의 그릇이 아니라 각자의 성격에 맞는 그릇과 통로라고 생각해요.