오잉? 일렉트론은 멀티쓰레드 기반일텐데요..(심지어 gpu 랜더링까지 지원하는..)

아마도 차트가 너무 방대한 자료를 이용해서 만드신거 아닐까 싶긴 합니다.

노드 기반 아니었나요? 제대로 된 멀티쓰레드는 구조상 불가능하고 worker로 우회하는걸로 알고있는데요..

별거 아니고 그냥 일년남짓 되는 저널에 태그로 입력해둔 숫자 긁어와서 라인차트로 보여주는, 별거 없는 그래프에요. 그런데 이 차트를 딱 두개만 띄워놔도 커서 움직임이 눈에 띄게 버벅거립니다. 디버깅을 안해봐서 모르겟는데 뭔가 엘리먼트가 바뀔때마다 매번 쫙쫙 다 검색해서 새로고침을 하고있는것같은 기분이 듭니다ㅎㅎ

버벅거릴때 스파이크치는 쓰레드가 안보이는걸 보면 그냥 렌더링에 문제가 있을 확률이 훨씬 높아보이네요. 상식적으로 차트 몇개로 cpu 헤비한 작업일리가 없는 환경인지라..

네.. 워커로 우회하는거 맞긴 합니다.

그래서 한 덩어리는 기본적으로 한 스레드에서 실행되죠..

Worker Thread, Web Worker, GPU 등처럼 별도 프로세스를 이용한 병렬 처리는 가능하다는 것이고
따라서 Electron 자체도 단일 프로세스·단일 스레드 프로그램은 아니기 때문에 문제가 안되는 것 아닌가해서 말씀드린겁니다.

네.. 그래서 램은 먹을지언정 병렬처리가 되긴 되야하는데 안되는 모습이 보여져서.. 음? 하고 있었던 것입니다ㅎㅎ

차트 라이브러리도 배틀테스트가 끝난, 아주 단순한거라 애드온탓은 아닌것같구.. 뭔가 옵시디안의 렌더링방식에 문제가 있는건가 싶어서 네이티브 프레임웍을 써보면 어떨까 싶었던거구요.

근데 개발팀이 워낙 작아서 기대하진 쉽지 않을듯하네요.. 로드맵도 새 기능 위주로만 보이고 딱히 생각이 없는것같더라구요 ㅠ,.ㅠ

처음 사용할때부터 싱크 구독 안하고 클라우드플레어 싱크로 우회해서 날로먹고 있는 입장에서 할 소리는 아니긴한데ㅎㅎ조금 아쉬워서 몇 자 적어봤습니다.

여러 방법이 있겠지만 저는 lm studio connect라는 애드온을 통해 모델을 로컬로 옵시디안에 연결해주고 옵시디안 내의 컨텍스트를 주는 방식으로 쓰고 있습니다. 젬마4 26b에 물려 쓰고 있는데 그냥저냥 쓸만하네요..

말씀하신 것처럼 왜 손이 노션으로 가는지 생각해보면,

옵시디언은 "정리를 내가 해야 하는" 도구거든요. 링크 걸고, 폴더 정하고, 관련 노트끼리 연결하고... 이 관리 부담이 쌓이니까 결국 방치하게 되죠. 노션은 그냥 던져넣기 편하고요. 근데 노션은 또 "쌓기만 하고 연결이 안 되는" 문제가 있고요.

제가 제시한 이 시스템은 그 관리 부담을 LLM한테 넘깁니다.

핵심은 이거예요 — 저는 소스를 던져넣고 질문만 하고, 요약·링크·정리는 LLM(Claude Code)이 다 해요.

구체적으로 이런 식이에요

1. 넣기 — 회의록이든 아티클이든 PDF든 raw/ 폴더에 넣고 "이거 정리해줘" 한마디.

→ LLM이 읽고 → 요약 페이지 만들고 → 관련된 기존 노트들 갱신하고 → 교차링크 걸고 → 인덱스까지 자동 정리. 제가 링크 하나 안 걸어요.

2. 묻기 — "지난주 회의 뭐였지?", "우리가 논의한 인증 방식 정리해줘" 같은 질문.

→ 위키에서 찾아서 출처 붙여 답해줍니다. 여러 노트에 흩어진 내용도 종합해서요.

3. 관리 — 가끔 "위키 점검해줘" 하면 → 모순되는 내용, 오래돼서 낡은 정보, 빠진 연결을 알아서 찾아줘요.

예를 들어 저는 요즘 회의록이랑 관심 있는 AI 아티클들을 그냥 넣기만 하는데, 어느새 "이 개념이 저 회의랑 연결되네?" 하는 걸 LLM이 알아서 이어놔요. 노션처럼 던져넣기는 쉬운데, 옵시디언처럼 연결은 자동으로 되는 셈이죠.

질문을 던진다는게 그럼 옵시디언 플러그인중에 llm 챗봇으로 이용할 수 있는 게 있나보군요.