처음엔 그냥 또 하나의 임베딩 실험인 줄 알았다. 요즘 이런 거 많잖아. 붙이는 순간 세상이 바뀐다고 하는데, 막상 내 작업 흐름은 그대로인 경우.
근데 이번엔 조금 달랐다. 옵시디언에서 “분명 적어뒀는데 어디 있지?”가 줄기 시작했다. 이 차이가 생각보다 컸다.
2026년 3월 10일 Google은 gemini-embedding-2-preview를 Public Preview로 공개했고, 텍스트·이미지·비디오·오디오·PDF를 하나의 임베딩 공간에 매핑하는 멀티모달 임베딩 모델이라고 설명했다. 참고로 기존 안정판 문서에는 gemini-embedding-001도 함께 남아 있어서, 지금 시점은 안정판과 프리뷰 실험판이 같이 보이는 과도기라고 보는 게 맞다.
이 글은 그 발표를 보고 신나서 이론만 떠든 글은 아니다. 내 옵시디언 볼트 일부에 실제로 붙여보고, 뭐가 좋아졌는지, 뭐는 아직 별로인지, 그리고 지금 시점에서 어디까지를 PoC로 인정할지 적어보는 사용기다.
먼저 하나는 분명히 하고 갈게. 내가 이번에 붙여본 건 제미나이 생성 모델이 아니라 임베딩 모델이다. 그리고 전 볼트 전체를 갈아엎은 것도 아니다. 00.Inbox, 일부 프로젝트 노트, 코드 파일, 차트 자산, PDF 몇 개 정도를 대상으로 의미 기반 회수를 시험해본 수준이다.
그런데도 체감은 있었다. 이게 좀 웃긴 포인트다. 거창한 운영 시스템도 아니고, 샘플셋 기반 PoC인데, 이미 “찾아내는 힘”은 달라졌다.
왜 굳이 옵시디언에 임베딩을 붙였냐
내 옵시디언이 문제였던 건 저장이 아니었다. 저장은 잘 된다. 문제는 회수였다.
노트는 계속 쌓인다. 요약 노트도 쌓이고, 프로젝트 메모도 쌓이고, 코드 파일 경로도 적어두고, PDF도 넣고, 트레이딩 차트 같은 자산도 옆에 둔다.
근데 나중에 찾으려 하면 꼭 이런 일이 생긴다.
- 제목은 정확히 기억 안 남
- 태그도 애매함
- 비슷한 얘기를 다른 표현으로 적어둠
- 구현 파일은 노트랑 따로 놈
- PDF나 차트는 더 숨어버림
기존 검색은 정확한 문자열 찾기에는 좋다. 이건 지금도 좋다. 파일명 아는 경우, 특정 문장 찾는 경우, 숫자 하나 찍어 찾는 경우, 이럴 땐 일반 검색이 여전히 빠르고 강하다.
근데 내가 진짜 자주 겪는 문제는 그게 아니었다.
“그 검색 실험 관련해서 예전에 적어둔 거 뭐 있었지?”
“이 노트랑 이어지는 구현 파일 뭐였더라?”
“가족관계증명서 PDF 어디에 뒀지?”
“BTC 차트랑 연결되는 메모를 예전에 남겼던 것 같은데?”
이런 건 문자열보다 맥락이다. 그래서 임베딩을 붙여봤다.
이번에 실제로 뭘 만들었냐
거창하게 플랫폼 만들었다고 하면 거짓말이고, 실제로는 작게 세 가지를 만들었다.
1. 스모크 인덱스
먼저 샘플셋을 모아서 인덱스를 만들었다.
00.Inbox최근 노트02.Areas/trading/charts일부 차트 자산- 일부 PDF
- 관련 코드 파일
이 인덱스는 “지금 이 방향이 먹히는지”를 보는 테스트판이다. 처음부터 전 볼트 다 넣으면 멋있어 보이긴 하는데, 보통 그건 멋있게 망하는 지름길이다.
2. 개별 semantic recall 리포트
노트 하나를 넣으면:
- 관련 노트
- 관련 자산
- 연결 제안
- 다음 액션
을 뽑는 리포트를 만들었다.
예를 들어 옵시디언에 Omni식 통합검색 적용하기 노트를 넣었을 때, 관련 노트로 에이전트 검색 운영 도구 비교, Gemini Embedding 2 네이티브 멀티모달 임베딩 공개가 상위에 같이 잡혔다.
그리고 관련 자산으로는 memory_service.py, memory_retriever.py 같은 실제 구현 파일이 같이 올라왔다.
이게 좋았던 이유는 단순하다. 예전에는 내가 머릿속으로 하던 연결 작업을, 이제는 리포트 초안이 먼저 해준다.
3. 배치 semantic 리포트
노트 하나만 보는 걸로는 오늘의 흐름이 안 보일 때가 있다.
그래서 최근 인박스 여러 개를 한 번에 돌려서:
- 반복해서 걸리는 관련 노트
- 반복해서 걸리는 자산
- 공통 패턴
- 다음 액션
을 뽑는 배치 리포트도 만들었다.
이건 생각보다 실용적이었다. 개별 노트는 “이 메모는 어디에 연결되지?”를 보여주고, 배치 리포트는 “요즘 내 인박스가 결국 어디로 수렴하지?”를 보여준다.
노트가 많아질수록 후자가 은근 효자다.
써보니 뭐가 좋아졌냐
여기서부터가 진짜 사용기다. 공식 발표 요약은 멋있지만, 내가 궁금한 건 언제나 그거다.
“그래서 내 작업이 뭐가 달라졌는데?”
1. 비슷한 말을 안 써도 관련 노트가 붙기 시작했다
이게 제일 체감이 컸다.
예전에는 제목이나 키워드가 좀 맞아야 잘 걸렸다. 지금은 표현이 달라도 주제가 비슷하면 따라온다.
예를 들어 검색 실험, 회수 구조, 에이전트 검색 비교, Omni식 통합검색 같은 메모들이 서로 조금 더 자연스럽게 엮인다.
이건 화려하지 않다. 근데 실무에서 진짜 중요하다. 사람은 제목을 정확히 기억하지 못하니까.
옵시디언이 갑자기 천재가 된 건 아니다. 하지만 적어도 “내가 적어둔 걸 내가 못 찾는” 상황은 줄여준다.
2. 노트만 보지 않고 코드, PDF, 차트까지 같은 후보군으로 보기 시작했다
이번 PoC에서 좋았던 두 번째 포인트는 이거였다.
관련 노트만 띄우는 수준이면 사실 기존 링크나 태그로도 어느 정도 버틴다. 근데 실제 작업은 노트만으로 안 끝난다.
노트 옆에는 늘 이런 게 있다.
- 구현 코드
- 실험 스크립트
- PDF 문서
- 차트 HTML/JSON/PNG
이번에는 이런 자산도 검색 후보군에 같이 올렸다.
그래서 “이 메모와 연결되는 구현 파일 뭐였지?” 같은 질문에 노트만 던져주는 게 아니라 코드 파일도 같이 보인다.
체감상 옵시디언이 책장만 뒤지던 상태에서, 서랍까지 열어보기 시작한 느낌이었다.
3. intelligence-hub랑 붙였을 때 연결 초안이 빨라졌다
이건 개인적으로 꽤 만족스러웠다.
나는 노트를 그냥 쌓아두는 것보다, 나중에 묶고 연결하고 행동으로 바꾸는 쪽이 더 중요하다고 본다. 근데 이 과정이 은근 귀찮다.
semantic recall 리포트를 intelligence-hub 쪽에 붙이니까, 적어도 아래 네 가지는 자동 초안이 된다.
- 관련 노트
- 관련 자산
- 연결 제안
- 행동 추천
즉, 메모를 보고 나서 “이거랑 저거도 묶어야 하나?” “구현 파일은 뭐였지?” “다음 작업은 뭘로 이어가야 하지?” 이런 걸 전부 처음부터 사람이 손으로 생각하지 않아도 된다.
완전 자동 비서까지는 아니다. 근데 초안 보조로는 이미 유용했다.
4. 배치로 돌리면 최근 인박스의 공통 축이 보였다
이건 예상보다 더 좋았다.
개별 노트 리포트는 한 건씩 볼 때 좋다. 반면 배치 리포트는 최근 인박스 여러 개를 훑고 반복해서 나오는 허브 노트나 구현 자산을 보여준다.
실제로 돌려보니 Gemini Embedding 2 관련 요약 노트와 옵시디언에 Omni식 통합검색 적용하기 같은 노트가 반복해서 잡혔다.
즉, 최근 인박스의 중심축이 어디인지 빨리 보였다.
이건 정리 습관이 약한 사람일수록 좋다. 나 같은 사람 말이다. 정리하려고 노트 쓰는 건데, 노트가 많아질수록 더 정리할 게 늘어나는 그 아이러니. 아주 아름답게 귀찮다.
생각보다 별로였던 점도 있다
좋아진 점만 쓰면 광고문 같다. 그래서 별로였던 것도 적어야 한다.
1. 지금 당장 전 볼트에 깔 정도는 아니다
이번 결과가 좋긴 했지만, 아직은 PoC가 먹힌다에 가깝다.
샘플셋 기준으로는 쓸만했다. 그렇다고 지금 전 볼트 전체를 재인덱싱하고, 자동 링크 넣고, 상시 운영 자동화까지 걸고 싶냐고 하면 그건 아니다.
이 단계에서 그렇게 가면 거의 집수리다. 신기술 테스트하다가 집 구조를 바꾸는 느낌. 보통은 그쯤부터 피곤해진다.
2. 내가 이번에 쓴 건 로컬 모델이 아니다
이 부분은 생각보다 중요하다.
나는 이번에 모델을 다운로드해서 로컬에서 돌린 게 아니다. GEMINI_API_KEY로 Gemini API를 호출해서 임베딩을 받는 방식으로 붙였다.
그래서 이 사용기는 “내 맥북에서 제미나이 모델을 직접 굴려봤다” 가 아니라, “Gemini API 기반 임베딩 PoC를 옵시디언 회수 흐름에 붙여봤다” 에 더 가깝다.
이건 장점도 있고 단점도 있다.
장점은 빠르게 실험하기 좋다는 거다. 단점은 비용, 한도, API 변경, 프리뷰 상태 영향을 받는다는 거다.
3. 차트와 PDF는 아직 가끔 얼탄다
솔직히 이건 있다.
특히 PDF 쪽은 텍스트 추출 품질과 문서 특성 영향을 좀 받는다. 차트 자산도 문맥 가중치가 덜 맞으면 엉뚱하게 상위에 낄 수 있다.
그래서 나는 이번 결과를 “완성형 멀티모달 검색” 이라고 부르지 않는다.
정확히는 “멀티모달 확장 가능성이 있는 semantic recall PoC” 정도가 맞다.
실제로 이번 PoC에서도 이미지와 문서 파일을 무조건 그대로 던져 넣어서 마법처럼 해결한 게 아니라, 주변 메타데이터와 텍스트 문맥을 함께 써서 회수력을 끌어올린 부분이 있다.
이건 오히려 장점일 수도 있다. 허세 없이 지금 가능한 범위를 정확히 보게 해주니까.
4. 프리뷰 모델이라 갈아탈 때 재임베딩 이슈를 봐야 한다
공식 문서에서 명확하게 말하는 부분이 하나 있다.
gemini-embedding-001과 gemini-embedding-2-preview의 임베딩 공간은 서로 호환되지 않는다. 즉, 기존 임베딩을 새 모델 임베딩과 직접 비교하면 안 되고, 업그레이드하려면 데이터를 다시 임베딩해야 한다는 뜻이다.
이건 꽤 현실적인 포인트다. PoC 단계에서는 괜찮다. 근데 운영으로 가면 재인덱싱 비용과 시간을 생각해야 한다.
그래서 나는 지금 이걸 전면 도입이 아니라 PoC로만 잡고 있다. 좋아서 막 달리기엔 아직 프리뷰 냄새가 난다. 새 신발은 예뻐도 하루 종일 신고 나가기 전엔 물집 체크를 해야 하니까.
그래서 나는 지금 어떻게 쓰고 있냐
지금 내 사용 루틴은 복잡하지 않다. 세 가지로 나눠 쓴다.
1. 노트 하나를 깊게 볼 때
이럴 땐 개별 semantic recall을 돌린다.
./.claude/scripts/intelligence-hub-semantic.sh "00.Inbox/260311_옵시디언에 Omni식 통합검색 적용하기.md"
이 명령은 노트 하나 기준으로 관련 노트와 자산을 추천해준다. 어디에 붙여야 할지 막막할 때 꽤 좋다.
2. 최근 인박스 흐름을 볼 때
이럴 땐 배치 semantic 리포트를 돌린다.
./.claude/scripts/intelligence-hub-semantic-batch.sh --limit 5 --folder "00.Inbox"
이건 최근 들어온 메모들이 결국 어떤 축으로 모이는지 보는 데 좋다. 정리 우선순위 잡을 때 유용했다.
3. 정확한 문자열만 찾을 때
이건 그냥 일반 검색 쓴다.
파일명 정확히 알 때, 특정 숫자 찾을 때, 티커나 함수명처럼 정확 문자열 찾을 때는 여전히 일반 검색이 빠르다.
즉 지금 내 기준은 이렇다.
- 정확한 문자열 찾기: 일반 검색
- 관련 맥락 찾기: semantic recall
- 최근 인박스 흐름 보기: 배치 semantic recall
이 정도만 나눠도 꽤 덜 헤맨다.
내가 느낀 점
이번에 가장 크게 느낀 건, 임베딩의 진짜 가치는 “대단한 답변 생성”보다 “잊은 걸 다시 끌어오는 능력”에 있다는 점이었다.
사람은 생각보다 많이 잊는다. 노트가 많아질수록 더 잊는다. 그리고 재밌는 건, 열심히 기록하는 사람일수록 더 잘 잊는다. 기록해뒀다는 안도감 때문에 기억을 외주 주기 때문이다.
그래서 나한테 이번 PoC의 핵심 가치는 말빨이 아니었다. 회수력이었다.
옵시디언이 갑자기 초능력을 얻은 건 아니다. 하지만 분명히 덜 따로 놀기 시작했다.
노트, 코드, PDF, 차트, 이런 것들이 아주 조금 더 같은 세계에 살게 됐다.
이건 생각보다 큰 변화다.
솔직한 마음
처음엔 나도 좀 경계했다. 이런 실험은 보통 시연은 멋있고, 실사용은 피곤한 경우가 많기 때문이다.
그리고 솔직히 말하면 아직도 완전히 믿진 않는다. 특히 프리뷰 모델이고, 샘플셋 기반이고, 차트나 PDF도 아직 완벽하지 않다.
그래서 지금 단계에서 “이제 옵시디언 검색 끝났다” 같은 말은 못 하겠다.
대신 이 말은 할 수 있다.
“이 방향은 진짜 가능성이 있다.”
그리고 그 가능성이 단순한 데모가 아니라, 내 실제 작업 흐름 안에서 이미 조금 작동했다.
그 정도면 PoC로는 충분히 의미 있다.
앞으로 할 것들
지금은 여기서 멈출 생각이다.
이상하게 들릴 수도 있는데, 이번엔 더 안 하는 게 오히려 맞다.
왜냐하면 지금 필요한 건 기능 추가가 아니라 관찰이기 때문이다.
앞으로는 이 세 가지만 볼 생각이다.
- 내가 실제로 자주 쓰는가
- 결과가 계속 유용한가
- 비용과 속도가 감당되는가
이 세 가지가 계속 괜찮으면, 그때 범위를 넓혀도 늦지 않다.
전 볼트 전체 인덱싱, 자동 링크 삽입, 상시 스케줄링, 완전 운영형 시스템화 같은 건 그 다음 이야기다.
지금은 딱 좋다. 된다. 근데 아직 크게 벌리진 않는다.
가끔은 이 정도 브레이크가 필요하다. 안 그러면 “실험”이 어느새 “유지보수 직업”이 되어버린다.
FAQ
Q1. Gemini Embedding 2를 쓰면 옵시디언 검색이 완전히 대체되나?
아니다. 정확한 문자열 검색은 여전히 일반 검색이 낫다. Gemini Embedding 2는 관련 맥락과 의미 기반 회수에서 더 빛난다.
Q2. 이번 사용기는 제미나이 생성 모델 후기인가?
아니다. 생성 모델이 아니라 임베딩 모델 사용기다. 정확히는 semantic recall용 PoC 후기다.
Q3. 모델을 다운로드해서 로컬에서 돌린 거야?
아니다. 이번 실험은 GEMINI_API_KEY 기반 Gemini API 호출 방식이다. 로컬 모델 서빙 후기와는 다르다.
Q4. 이미지와 PDF도 진짜 바로 검색된 거야?
공식 발표 기준으로 Gemini Embedding 2 Preview는 멀티모달 입력을 지원한다. 다만 내 PoC는 모든 파일을 완벽하게 순수 멀티모달 방식으로 처리한 운영 시스템이 아니라, 메타데이터와 텍스트 문맥을 함께 활용한 실험 흐름이다.
Q5. 지금 당장 전 볼트에 적용해도 될까?
내 기준에선 아직 아니다. 지금은 PoC 범위에서 충분히 의미 있고, 전면 적용은 실제 사용 빈도와 품질을 좀 더 본 뒤 결정하는 게 맞다.
Q6. 제일 좋았던 변화 하나만 꼽으면 뭐야?
“분명 적어둔 게 있는데 못 찾는 상황”이 줄어든 거다. 이 한 가지가 생각보다 크다.
결론
Gemini Embedding 2를 옵시디언에 붙여보니, 내 노트 시스템이 갑자기 만능 비서가 되진 않았다.
대신 확실히 덜 멍청해졌다.
비슷한 의미의 노트를 더 잘 붙여주고, 코드나 PDF 같은 자산도 조금 더 같은 문맥으로 데려오고, 최근 인박스의 흐름도 더 빨리 보여준다.
즉, 이번 변화의 본질은 “생성”이 아니라 “회수”였다.
나는 이 차이가 꽤 크다고 느꼈다. AI 툴은 뭔가 새로 만들어내는 순간보다, 내가 이미 가지고 있는 걸 제때 다시 꺼내주는 순간 더 쓸모 있을 때가 많다.
그리고 이번엔 그 가능성을 꽤 선명하게 봤다.
아직은 PoC다. 하지만 오랜만에, “이건 진짜 내 워크플로우를 조금 바꾸겠다” 싶었던 실험이었다.