지난 글 마지막에 슬쩍 언급했다.
"이후에 옵시디언 플러그인을 4개 만들었다. 사람들이 실제로 쓰고 있고, 반응도 좋다."
그냥 지나치기엔 할 말이 너무 많다. 오늘은 그 이야기다.
왜 만들었냐면 — 회사에서 쓸 게 없었다
요즘 IT 업계에서 문서를 마크다운으로 쓰는 건 거의 표준이 되어가고 있다. 이유는 간단하다. AI가 마크다운을 제일 잘 읽는다. Word나 HWP 파일을 AI한테 던져줘도 잘 못 씹는다. 마크다운으로 쓰면 Claude든 GPT든 바로 이해하고 분석하고 요약한다.
나는 회사에서 기획 문서를 많이 쓴다. ERD, API 명세, 아키텍처 다이어그램, WBS... 이런 것들을 옵시디언에서 마크다운으로 관리하고 싶었다. 근데 현실은 이렇다.
- 이슈 관리는 Jira에 있고
- 팀 문서는 Confluence에 있고
- 공유 문서는 Word, PDF, HWP로 날아온다
- 정작 내 두뇌인 옵시디언은 그 어디와도 연결이 안 된다
갭이 너무 컸다. 그래서 직접 만들기로 했다.
4개의 플러그인
점수는 옵시디언 커뮤니티 플러그인 등록 심사 결과다. 생각보다 잘 나왔다.
DocFlow — IT 문서를 제대로 보여줘라
ERD 파일을 마크다운으로 작성해놓으면 그냥 텍스트로 보인다. 아키텍처 다이어그램도 마찬가지다. 이걸 실제로 다이어그램으로 렌더링해서 보여주는 플러그인이 DocFlow다.
ERD는 ERD로, API 명세는 Swagger UI로, WBS는 계층 구조로 — 파일 타입을 자동 감지해서 맞는 뷰로 보여준다. 사이드바에 Artifact Explorer를 달아서 프로젝트 문서를 한눈에 관리할 수도 있다.
한국어 지원도 챙겼다. 영어만 되는 플러그인에 질린 적이 한두 번이 아니어서.
Jira Weaver — Jira 이슈를 내 두뇌로
Jira에 이슈가 수십 개다. 스프린트마다 업데이트되고, 코멘트 달리고, 상태 바뀐다. 이걸 따로 옵시디언에 정리하는 건 너무 비효율적이다.
그래서 원클릭으로 Jira 이슈를 Obsidian Vault에 마크다운 파일로 동기화하는 플러그인을 만들었다. JQL 쿼리 프로필을 여러 개 저장해두면 각자 다른 조건으로 자동 동기화된다. 내가 담당한 이슈, 우리 팀 이슈, 이번 스프린트 이슈 — 각각 다른 폴더에 자동으로 정리된다.
Jira Server, Cloud, Data Center 모두 지원한다. 한국어, 일본어, 중국어도 된다.
Confluence Weaver — 팀 문서를 내 두뇌로
Jira Weaver를 만들고 나니 자연스럽게 Confluence도 하고 싶어졌다. Confluence에 팀 위키가 쌓여있는데, 검색하러 매번 브라우저 열기 귀찮았다.
Confluence Weaver는 CQL 쿼리로 원하는 페이지만 골라서 Obsidian으로 동기화한다. 변경된 페이지만 다시 가져오니 효율적이다. 표, 코드 블록, 이미지도 마크다운으로 변환된다. Jira Weaver와 연동하면 Confluence 안의 Jira 링크가 자동으로 Obsidian 내부 링크로 바뀐다.
개인 메모 보호 마커도 넣었다. 동기화할 때 내가 추가로 써둔 메모는 덮어쓰지 않는다.
Document Weaver — 파일을 마크다운으로
이게 지금 제일 반응이 좋은 플러그인이다.
회사에서 Word 파일, PDF, PPT, Excel이 계속 날아온다. 이걸 일일이 복붙해서 마크다운으로 옮기는 건 시간 낭비다. Document Weaver는 드래그앤드롭 하나로 변환한다.
Word 파일을 Obsidian 창에 드롭하면 마크다운 파일이 생긴다. 제목, 본문, 표, 이미지가 모두 변환된다. PDF는 텍스트 레이어를 추출하고 자동으로 제목을 감지한다. PPT는 슬라이드별로 쪼갤 수도 있고, 긴 문서 하나로 합칠 수도 있다.
API 키 없다. 클라우드 없다. 완전히 오프라인이다.
그리고 HWP 지원을 넣었다.
한국 사무실에서 HWP 파일은 아직도 현역이다. 공문서, 기안서, 계획서 — 전부 HWP로 온다. 해외 플러그인들은 HWP를 모른다. 한국 사용자들을 위해 직접 넣었다. 아직 베타지만, 어쨌든 된다.
로봇끼리 싸움을 목격했다
이 이야기를 안 하면 서운하다.
옵시디언 커뮤니티 플러그인으로 등록하려면 GitHub에 PR을 올려야 한다. 심사 과정이 꽤 까다롭다. 코드 품질 기준이 있고, 자동화된 리뷰가 돌아간다.
PR을 올렸더니 GitHub Copilot이 달려들었다.
경고. 또 경고. 또 경고.
"이 부분은 타입 안전하지 않습니다." "이 패턴은 권장하지 않습니다." "이 API는 곧 deprecated됩니다."
봇이 자동으로 코드 리뷰를 달기 시작했다. 수십 개.
나는 Claude Code를 켰다.
"GitHub Copilot이 이런 경고를 달았어. 뭐가 문제야?"
Claude Code가 분석하고, 코드를 수정하고, 다시 커밋한다. 그러면 Copilot이 또 다른 경고를 단다. Claude Code가 또 대응한다.
로봇이 로봇을 공격하고, 다른 로봇이 방어하는 장면을 나는 그냥 지켜봤다.
나는 심판이었다. 아니, 사령관이었다. 양쪽 로봇에게 명령을 내리는.
한 라운드, 두 라운드, 세 라운드.
결국 모든 경고가 해소됐다. PR이 머지됐다. 플러그인이 등록됐다.
내가 이겼다.
아니, 내 Claude Code가 이겼다. 어쨌든 우리 팀이 이겼다.
며칠 만에 230명이 쓰기 시작했다
Document Weaver가 등록되고 며칠이 지났다. 다운로드 수를 확인했다.
230이 넘어 있었다.
솔직히 말하면 조금 멍했다.
코딩을 못 한다고 생각했던 사람이. 개발자한테 요청서를 써왔던 사람이. 만든 플러그인을 230명이 설치해서 실제로 쓰고 있다는 게.
Jira Weaver는 리뷰 점수가 99점이다. 커뮤니티 심사에서 거의 만점이다.
이게 뭔가 싶다가도, 생각해보면 당연한 것 같기도 하다. 내가 실제로 필요해서 만든 것들이니까. 나처럼 옵시디언을 쓰면서 Jira, Confluence, Word 파일에 치이는 사람들이 있으니까. 그 갭을 메우고 싶었던 사람이 나 혼자가 아니었던 거다.
비개발자가 플러그인을 만든다는 것
예전엔 상상도 못 했다. 플러그인을 만드는 건 개발자의 영역이라고 생각했다.
지금은 안다. 도구보다 중요한 건 무엇이 필요한지 아는 것이다. 나는 회사에서 매일 이 불편함을 겪었다. 개발자보다 이 갭을 더 잘 아는 사람이 나였다. 그리고 그걸 만들 수 있는 도구가 생겼다.
Claude Code는 내 생각을 코드로 바꿔주는 통역사다. 나는 업무 언어로 설명하고, Claude Code는 코드로 만든다. GitHub Copilot이 트집을 잡으면 Claude Code가 방어한다.
나는 사령관이다.
4개 플러그인 모두 옵시디언 커뮤니티 플러그인에서 찾을 수 있다. DocFlow, Jira Weaver, Confluence Weaver, Document Weaver.
다음 편: Claude로 옵시디언 플러그인을 처음부터 만드는 방법 — 아이디어에서 커뮤니티 등록까지