Head Story · 에이전트코리아

옵시디언은 벡터DB가 아니다 — 위키 논쟁 뒤에 이어진 홍보 릴레이

🕐 2026-07-06에이전트코리아
본 기사는 여러 오픈카톡방 대화를 완전 익명(발화자 식별 정보 전면 제거) 처리해 병합한 것입니다.

옵시디언을 벡터DB로 오해한 질문에서 시작된 정정 논쟁이 임베딩 인코딩 효율 얘기로 번진 뒤, 잦아들 무렵 각자 만든 오픈소스 도구를 소개하는 릴레이로 자연스럽게 이어졌다.


옵시디언은 벡터DB가 아니다 — 위키 논쟁 뒤에 이어진 홍보 릴레이

오전 11시, 클로드 코드와 코덱스를 옵시디언에 어떻게 연결하는지 묻는 질문 하나가 방을 채웠다.

"옵시디언이랑 LLM 같이하는거야 다들 하는데, 어디서 보니까 클로드 코드+코덱스+옵시디언을 쓴다고 하던데...이게 정확히 어떤 방식으로 클코랑 코덱스를 연결한다는 걸까요? 그냥 옵시디언 db에 따로 연결을 해서 쓰는건가요 아니면 뭔가 유기적으로 두 LLM을 합쳐쓰는게 있는 건가요?"

답이 곧바로 정정으로 이어졌다. 한 참여자는 "옵시디언은 벡터DB가아닌데 임베딩된 상태에요? Markdown 기반지식관리잔아요"라며 전제부터 바로잡았다. 이 정정을 계기로 대화는 잠시 곁가지로 새, "아녕 바이트를 base64 때리면 무조건 4/3 이상 늘어납니다"라는 인코딩 효율 코멘트까지 붙었다가 다시 본론으로 돌아왔다.

방향을 다시 잡은 것은 뒤이어 나온 정리였다. 한 참여자는 옵시디언 자체는 단순 문서 저장소지만, LLM 위키라는 맥락에서는 정제할 데이터 초안을 모으는 창구로 쓰인다고 설명했다.

"옵시디언 자체는 원래 단순 문서 저장소 이지만 LLM WIKI 의 일반적 개념에서의 옵시디언은 정제할 데이터 초안을 모으고, LLM을 이용해 정제한 문서 처리 결과를 자동으로 관리하는 데이터베이스 처럼 쓰더라구요. LLM은 저 과정에서 문서를 정제하고, 기존 맥락과의 연결성을 파악해 링크(키워드, 태그, 백링크 등)를 추가해서 wiki 문서로 만들어주고 사용자가 원하는 내용을 검색할다 이 wiki 기반으로 검색을 하는데 이때도 LLM이 보조적인 역활을 수행해 줍니다. 라고 저는 이해중이네요."

즉 옵시디언 자체가 벡터를 저장하는 게 아니라, LLM이 문서를 정제하고 링크를 붙이는 과정에서 옵시디언이 그 결과물을 쌓아두는 창고 역할을 한다는 정리였다.

이어진 오픈소스 홍보 릴레이

옵시디언 논쟁이 잦아들 무렵, 화제는 자연스럽게 각자 만든 오픈소스 프로젝트 소개로 넘어갔다. 지식 그래프 기반 메모리 시스템을 만든 참여자가 먼저 자기 작업물을 설명했다.

"이 memory-bank 프로젝트는 다음과 같은 하나의 거대한 순환 시스템을 가진 세 개념의 결정체입니다. LangGraph식 워크플로우(AI)가 나포한 대화 속에서, 온톨로지 규칙 규칙(설계도)에 따라 의미 관계를 명확히 쪼갠 뒤, 옵시디언처럼 연결된 지식 그래프(창고) 형태로 SQLite에 저장하여 AI의 영구적인 기억 장치로 쓰는 시스템"

뒤이어 다른 참여자가 "대강 gguf 처럼 메모리도 양식 만드는중"이라며 메모리 포맷 실험을 언급했고, 보안 취약점 점검 툴을 만든 참여자도 도움을 요청하며 소개에 합류했다.

"엇 그럼 저도 하나 홍보 및 도움요청이.. https://github.com/jhny-kor/sec-chk 소스취약점 분석+보안 예방 md파일+웹사이트 취약점 점검 툴인데, 윈도우는 exe로 설치하시면 되고, 맥은 앱스토어에도 옳려두었습니다..! 근데 저희 회사 웹사이트로 확인했을때 취약점으로 뜨는게 틀린 소리는 아니긴한데… 이게 일반사용자들에게 실제로 쓸만한지 확인해주십셔!"

옵시디언을 벡터DB로 오해하지 말라는 개념 정정에서 시작한 대화가, 결국 각자 지식관리·보안 도구를 직접 만들어 보여주는 자리로 흘러간 하루였다. 개념을 따지는 논쟁과 실제로 만들어본 결과물을 나누는 릴레이가 한 방 안에서 순서대로 이어졌다는 점은, 이 커뮤니티 참여자들이 단순한 사용자를 넘어 스스로 도구를 짜보는 제작자층을 두텁게 이루고 있음을 시사한다.