📝 Key Trigger (1–3 lines)

1. 발단: 범정부 오피스라는 신세계

범정부 오피스라는 프로그램이 있었다. 그러니까 이걸 처음 접한 날짜가 언제였더라. 기록을 찾아보니 최초로 접한 것은 더 베러 단톡방에서 앤드류 | 지식노동자님이 올린 카톡과 링크 하나가 이 모든 프로젝트의 시작이었던 것 같다:

사용법 영상을 보고 난 첫 소감은 공문서에 시달리는 공무원의 분노가 가득찬 집념의 결정체라는 느낌이었다. 아래는 이 영상을 보자마자 달았던 내 카톡 답글이다:

처음에는 영상을 보고 나서 오... 꽤 많이 신기하다.. 정도였고, 기능이 굉장히 많이 있었기에 본격적으로 배울 생각을 하지 않았다. 그런데 2025년 8월 2일에 처음 범정부오피스를 접한 이후 제목: 사업계획서 당구장: I. 개요 하는 식으로 줄 바꿈을 하면서 '기호 표시자'를 텍스트로만 구분한 다음, 범정부오피스에서 매크로 버튼을 돌리면 약 25페이지에 걸쳐서 사업계획서가 눈앞에서 드르르륵 하고 실시간으로 눈에 편집이 되는게 보여지는 광경을 볼 수 있는 미친 자동 매크로 편집이 있었다. 아마 이 때부터였던 것 같다. 옵시디언용 플러그인을 내가 따로 개발하는 계기가 된 것은.

2025년 9월 2일, 그러니까 딱 한 달이 지났을 때 범정부오피스의 'G서식 변신봇'이라는 매크로 버튼과 연계해서 '굉장히 복잡한 사업 보고서 형식을 각 부서별로 내용에 맞춰서 기본 자동편집을 연계할 수 있는' 보조 프롬프트를 만들어서 더베러 단톡방에 올렸었다. 그러니까 내 옵시디언 폴더에 따로 노트도 있는 범정부오피스 G서식변신봇 - Gemini Gem 프롬프트같은 노트.

2025년 10월 14일. 범정부오피스의 'G서식 변신봇' 프롬프트를 연계해서 30-40페이지에 달하는 대량의 편집 보고서 초안을 순식간에 작성할 수 있는 워크플로우를 발견하고 나니 새로운 고민이 생겼다. 초안을 빛의 속도로 편집까지 해서 기본 틀을 잡아주는 것은 좋은데, 문제는 실제 중장문 보고서 편집은 I장의 1)절만 편집하거나, II장의 1)-1.의 가. 항목만 편집하는 등의 셀 수도 없이 많은 미세 작업이 산재해있다는 것이었다. 이게 무슨 말이냐면, 한글에서 30-40페이지에 해당하는 긴 보고서를 상하 스크롤링만으로 '어 I장의 어디쯤이었더라..' 하고 고치기엔 위아래로 계속 눈을 굴려야 한다. 편집본 초안을 빠르게 만들면 뭐에다 쓸건가. 진짜 편집의 시작은 그놈의 I장 1)절의 1-가. 항목의 셋째 줄의 단어 하나를 굳이 고치라는 상사의 요구를 수도 없이 반복하는 과정에서 시작된다. 이런 워크플로우에서 기존 한글 프로그램의 "상하 스크롤링"화면은 여전히 편집의 병목을 유발하기 딱 좋은 환경이었다. 그래서 2025-10-14일 내가 최초로 HTML 앱으로 한글 관련 앱을 바이브코딩해서 내놓았던 것이 바로 범정부 오피스 프리뷰 3콤보 앱이다.

이 앱은 지금 보면 굉장히 조악했지만 나름대로의 철학이 있었다:
Writing First. Formatting Later.
문서의 형식보다 내용의 논리 흐름 (flow)에 집중하세요.
편집은 나중에. 사고는 지금 바로.

(그러니까 이런식으로 생겼다. 지금도 내 하드에 있는데, 나름데로 제목과 소제목 단위로 접어지게까지 해놓았다. 오프라인으로 편집도 되고. 지금도 써먹으라면 잘 써먹을 수 있다. 나름대로.)

2. 문제의 시작: 범정부오피스 "G서식변신" 버튼은 한림대학교 표준 서식과 완전 정확히 일치하지 않는다

소제목 그대로다. 바로 여기서부터 모든 프로젝트의 시작이었다.
범정부 오피스는 지금도 공공기관에서 여전히 강력하게 쓸 수 있지만 문제는 이 프로그램을 만든 개발자가 매크로 서식변환을 행정 안전부 기본 서식에 맞춰놓았다는 점이었다. 이 매크로 서식 변환 버튼은 다음의 8가지만 지원하도록 매핑이 고정되어있다: "제목:", "배경:", "소제목:", "네모:", "원:", "바:", "당구장:", "별:". 그리고 그 8가지는 아래처럼 행정안전부 포맷으로만 나온다.

(범정부오피스 매크로변환으로 행정안전부 스타일로 변환된 텍스트.)

그런데 문제는 내가 속한 한림대학교의 표준 보고서 서식 등에는 완벽하게 제목 스타일이 매핑이 되지 않고, 이 프로그램은 보안상의 문제로 개발자가 .exe파일에 보안을 걸어놓아 프로그램을 뜯어서 공부할 길도 없다는 것이었다. 게다가 아래처럼 표가 들어갔는데 서식까지 다르면 그냥 이 프로그램으로는 아예 답이 없는 완전히 다른 상황이 펼쳐진다.

참고로 이 범정부오피스 개발자는 1200일 넘게 단 1인개발로 전국의 32개 중앙부처, 지방정부, 공기업, 출연기관 맞춤형 기능을 개발중이다. 그것도 단신으로. 개발자가 재능기부로 각 지자체나 작은 부서단위로 맞춤형 버전을 시간이 걸려서라도 만들어주던데, 그러면 혹시 요청하면 한림대학교 버전도 만들어달라고 요청할 수 있지 않을까? 혹시나 해서 개발자 유튜브에 지난 2025년 11월 25일에 범정부오피스 인천국제공항 버전 유튜브영상에 내가 직접 댓글을 달아보았다:

이 무슨 희소식이란 말인가! 드디어 나도 학교 행정문서 공문서 지옥 지긋지긋한 HWP 탈출이다!
...라는 생각을 했는데 문제는 따로 있었다. 바로 공문 을 요청해야 하는데 바로 그 공문을 학교차원에서 직접 개발자에게 요청해야 한다는 것이었다. 해당 건을 가지고 나는 AI융합연구원 분들이나 교무처장님 등을 단신으로 찾아뵈서 범정부 오피스를 보여드리고 제발 우리도 한림대학교 버전 만들게 요청을 해보아요라고 그냥 말로만 AI대학 혁신 할게 아니라 이런 게 진짜 혁신 아니냐고, 내부적으로 행정에 시달리는 교직원들을 위한 진짜 혁신 아니냐고 얘기하고 다녔다. 하지만, '오, 그러네요. 이건 당장 알아봐야겠네요' 라는 답변만 여러 번 들었을 뿐, 끝내 묻히고 바뀌는 것은 없었다.

3. 답답하면 내가 만들어보자 : 맨 땅에서 새로 만들기, 그리고 두 번의 첫 좌절

3.1 첫번째 시도: HWPX to MD 옵시디언 플러그인 (실패)

채팅 히스토리를 찾아보니 내가 HWPX to MD 혹은 MD to HWPX 관련 시도를 했던 것은 의외로 범정부 오피스를 처음 접한 지 얼마 되지 않은 시점, 그러니까 2025년 8월 11일까지 거슬러 올라간다. 아이디어의 핵심은 HWPX를 옵시디언 MD 노트 작업공간으로 드래그 앤 드롭 하면 자동 파싱 및 MD 변환 해주는 기술을 구현하는 것이었다. 그러니까 한마디로 지금의 HanMark 1.0에 탑재된 바로 그 기능. 당시 나는 1년 반 넘게 GPT를 써왔으면서도 CODEX라는 게 있는지도 모르고 GPT 웹 채팅창에서 바이브코딩을 하는 참 무식하면서도 용감한 짓을 했다. 그리고 그 결과는, 아래처럼 처절하게 실패했다.

(해당 채팅 세션의 마지막 기록. 죽은 프로젝트로 고치다 만 AI 답변의 콜드 메시지만 남았다.)

3.2 두번째 시도: 한림대 버전 '범피스' EXE를 아예 새로 만들기 (실패)

두 번째 시도는 2026년 1월 25일, 그러니까 범피스를 처음 접한지 5개월이 지난 시점이었다. EXE가 보안상 막혀 있어서 뜯어볼 수도 없고, 정보과학대학 교수님들께 나름대로 자문을 구하며 물어도 봤는데 교수님들조차도 EXE로 띄워놓은게 저렇게 매크로 실행이 되는 걸 어떻게 구현한거죠? 저도 전혀 감이 안오네요. (당시 교무처장님 답변) 라는 반응들이었다.

그래 일단 뭐가 되든 내가 직접 EXE파일을 새로 만들어보자. 범정부 오피스의 'G서식 변신'을 다시 자세히 관찰해본 바로는, 위에서도 말했지만, 다음의 8가지만 지원하도록 매핑이 고정되어있다: "제목:", "배경:", "소제목:", "네모:", "원:", "바:", "당구장:", "별:".

"당구장"이라는 매크로 단어와, 그에 해당하는 기호를 출력하는 것으로 하드코딩이 되어있다. 그래 여기까지는 알겠어. 그러면, 마크다운 헤딩 기호, #, ##, ###에 각각 커스텀 매핑을 가능하게 하는 EXE를 윈도우 오토 핫키 식으로 만들어볼 수 있지 않을까? 라는 생각을 하고 바로 시도를 했다. 결과는 역시 실패. EXE를 만들고 실행하는데에는 성공했지만, 문제는 한글이 띄워져있는 상태에서 EXE에서 버튼을 누르면 자동으로 한글에서 편집 실행하도록 매크로를 injection 하는 것이 어떤 원리인지 전혀 감을 잡지 못했다는 것이 패착이었다.

4. 첫 관점의 전환: "굳이 한글 안에서" 작성을 해야되?

4.1. 프로젝트의 첫 번째 엑조디아 조각: pypandoc-hwpx 스크립트

처음부터 한글에서 초안도 쓰고, 편집까지 다 하는 흐름을 한글 프로그램 안에서만 모든 작업을 하면 EXE같은 방식으로 injection 매크로를 만드는 것 밖에 답이 없다. 하지만 마크다운에 해당하는 기호를 매핑해서, 마크다운으로 먼저 작업을 하고 파일 출력물만 HWPX로 바꾸는 방식이라면? 이에 대한 첫 힌트를 얻은 것이 바로 위의 '범피스' EXE 새로 만들기를 시도했다가 실패한 과정에서 처음 발견한 힌트였다. 그리고 이 과정에서 처음으로 pypandoc-hwpx를 알게 되었다.

Pypandoc-hwpx. 깃허브에서 최초로 등록된 날짜는 2025년 12월경. 작년에 온갖 시도를 나름대로 해봤을 때 나도 MD to HWPX 변환 시도를 생각을 아예 안 해본 것은 아니었다. 이미 시도를 하고 실패했다. 그게 바로 위의 3.2에서 서술한 '마크다운을 먼저 편집 방식을 매핑해서 - 결과물을 HWPX 형식으로 바꿔서 한글에 injection 하는' 방식의 시도였지. 그런데 KISTI의 msjang 님이 만든 이 플러그인은 파이썬 스크립트로 CLI 또는 Antigravity/Codex 등으로 간단히 변환 명령어를 파이썬 패키지 스크립트로 돌리는 방식이었다. 처음으로 Antigravity에서 파이썬을 돌리는 스크립트를 실행해서 한글로 바꿔줘 라는 명령어를 실행하게 해서 변환을 한 뒤 HWPX를 열어본 소감. 어... 이게 된다고? 이게 되네? 였다.

4.2 프로젝트의 두 번째 엑조디아 조각: markdown.kr

프로그램을 만들어서 EXE로 injection하는 것이 어렵다면, 편집은 HTML 웹 에디터에서 굉장히 빠르게 하고 사람이 수동으로 텍스트를 복붙을 빠르게 하도록하는 방식은 어떨까? 사실 대부분의 텍스트 편집은 반복 편집과 글의 흐름 수정 등이 오래 걸린다. 물로 줄간격 맞춤이나 페이지 조정 등도 은근히 시간이 걸리긴 하지만, 웹 에디터로 편집을 빠르게 해버릴 수 있다면 수동 ctrl+c/v라고 하더라도 문서작성 프로세스가 단축되지 않을까? 라는 방향도 있었다. 이 부분에서 내가 큰 힌트를 받은 것이 바로 markdown.kr 이다.

(인터페이스가 극도로 심플하고, 라이브 뷰 실시간 반응속도도 엄청난 수준이다.)

4.3 프로젝트의 세 번째 엑조디아 조각: 마크다운 ㅎ글

markdown.kr의 방식은 텍스트 내용은 굉장히 빠르게 쓸 수 있지만, 여전히 문제는 hwpx로 포맷 변환 및 내보내기를 할 수 없다는 문제가 남아있었다. 게다가 애초에 한글을 쓰는 대부분의 공무원, 교수, 사무직 등은 마크다운이라는 포맷 자체가 생소하다. 결국 한글이라는 컴퓨터 프로그램 문서작업과 '눈에 익숙한' 환경이면서도 + 어쨌든 '한글 HWPX 열어보기 더블클릭'이 가능하도록 파일 output을 줘야한다는 두 가지 문제가 여전히 해결되지 않았다. 이 부분에서 내가 또 다시 큰 힌트를 받은 것이 바로 마크다운 ㅎ글이라는 사이트였다.

(마크다운 ㅎ글의 웹 인터페이스. 한글 HWP 프로그램과 UX/UI가 굉장히 유사하다.)

UX/UI라는 것은 굉장히 중요하다. 아무리 마크다운 편하다고 딱 한번만 써보시라고 해도, '내 눈에' 익숙하지 않으면 "기능과 상관없이 내가 보기 싫으니까 아 어려워 싫어"라는 심리적 방어기제가 발동한다. 이것이 바로 심리적인 Heuristic이자 UX/UI의 핵심이다. 그런 면에서 마크다운 ㅎ글의 인터페이스는 나름대로 파격적이었다. 딱 보기에도 눈에 굉장히 익숙한 한글 프로그램의 인터페이스에, markdown.kr의 라이브 뷰 장점까지도 가져왔다. 말하자면 한글 편집 웹 에디터 방식의 관점에서는 markdown.kr의 상위 호환으로 보일 정도다. 그런데 여전히 문제는 있었다. 바로 내보내기가 여전히 HWPX가 되지 않는다는 것이었다. 내보내기가 HTML과 PDF만 된다.

기능적인 관점에서는 "그냥 PDF로 완벽하게 작성하면 굳이 HWPX 필요없지 않아요?"라고 할 수도 있다. 하지만 대부분의 한글 프로그램은 빌어먹을 이메일로 '첨부파일' 로 HWPX 포맷으로 내 의지와 상관 없이 이미 HWPX로 첨부되서 날아오는 상황이 문제다. 결국에는 파일을 열어서 봐야한다. 이 부분을 마크다운 ㅎ글은 할 수 없었다. 혹은, 이미 내가 하드에 잔뜩 쌓아놓은 HWP 파일 논문/보고서 100개를 열어서 보거나 하는 그런 작업류도.

5. 첫번째 breakthrough: "obsidian-hwp-writer"

핵심은 세 가지로 압축되었다:

• 첫 번째 : UX/UI 파트. 한글의 "툴바"를 구현해야 한다. 최대한 한글 색감과 비슷한 툴바로.
• 두 번째 : '라이브 뷰' 기능. "한글 형식의 미리보기"가 가능해야 아무리 옵시디언이 생소해도 심리적으로 '한글과 결과물이 비슷해 보여서' 심리적 저항감이 추가로 감소한다.
• 세 번째: 'Export' 기능. 어쨌든 결과물이 MD에서 HWPX로 변환이 되고, 그걸 다시 한글로 열어서 확인해서 볼 수 있어야 한다.

2026년부터 코덱스를 본격적으로 접한 나는 옵시디언의 Editing toolbar + markdown.kr + 마크다운 ㅎ글 + pypandoc-hwpx 4가지 소스를 바탕으로 위의 세 가지 조건을 동시에 만족하는 옵시디언 플러그인을 만들기로 했다. 그렇게해서 나온 내 obsidian-hwp-writer의 첫 버전이 나온 것은 2026년 2월 25일.

6. 두 번째 breakthrough: "Pypandoc-hwpx는 Pandoc이 있어야 돌아가잖아??"

초기 버전은 두 가지 기능이 핵심이었다:

• MD to HWPX 라이브 뷰
• MD to HWPX Export (pypandoc-hwpx 패키지 기반)

그런데 얼마 지나지 않아, pypandoc-hwpx를 제대로 구동하게 하기 위해선 pandoc이 필수다라는 사실을 알게 되었다. Pandoc이 어떤 소스인가. 바로 MD to DOCX 변환을 가능하게 해주는 파이썬 라이브러리다. 그것도 파싱 변환 로직이 한글 HWPX보다 비교도 안되게 무시무시하게 정확한 수준인 오픈소스 라이브러리.

6.1 작은 난관: 사용자에게 어떻게 '쉬운 설치'를 안내할 것인가

"사용자에게 설치를 어떻게 하라고 안내할까?"
개발 중간 단계에서 약간의 난제가 있었는데, 문제는

• 옵시디언 플러그인 자체에 Pandoc이나 Pypandoc-hwpx를 내장하면 개발이 굉장히 복잡해지고
• 설치를 사용자가 따로 하도록 하면 "아 귀찮아 안해" 라고 나가 떨어질 위험이 있었다.

결국은 "이 방법대로 설치 가이드대로 복붙하시면 컴퓨터 포맷 안하는 이상 두번 다시 하실 필요 없습니다" 라고 설치 가이드를 정리해서 옵시디언 플러그인을 최초에 설치할 때 안내하는 방식으로 해결했다. 바로 아래와 같이:

(이거 3단계가 '컴맹도 그대로 복붙하라는대로' 해도 통과되는 수준이 되는걸 확인하려고 패키지들 인스톨/언인스톨을 몇십번을 한거 같다..)

6.2 사용자 설치 가이드 추가 + Pandoc 기반 MD to DOCX 파이프라인 추가

2026년 3월 10일, 나는 깃허브에 obsidian-hwp-writer에서 HWP 파이프라인과 DOCX 파이프라인이 따로 돌아가도록 구현을 한 1.7.0 버전 을 깃허브에 업로드했다. 개발과정에서 알게 된 사실이 있었는데, 그것은 바로 Pandoc쪽 파이썬 패키지는 몇년치의 무시무시하게 정확한 파싱 로직이 있기 때문에 옵시디언 내부에서 워드 미리보기 설정창 정밀 컨트롤이 JSON방식으로 완벽하게 가능하다라는 사실이었다. 그래서 워드 템플릿을 정밀 컨트롤할 수 있는 설정을 집어넣었는데, 반응이 굉장히 좋았던 기억이 난다.

(이 때까지만 해도 몰랐지. 워드 템플릿 정밀 컨트롤 되는 게 또 다시 좌절을 가져다 줄줄은..)

7. 두 번째 큰 좌절: MD to HWPX 템플릿 컨트롤을 Pandoc 수준으로 업그레이드 하기 (실패)

2026년 4월 21일. 모든 커뮤니티를 뜨겁게 달군 아주 핫한 오픈소스 두 가지가 올라왔다.
바로 RHWP와 HOP. 이름하여 한글 HWP의 맥 버전.

사실 obsidian-hwp-writer 1.7.0에 들어간 pypandoc-hwpx는 pandoc엔진 수준으로 무시무시하게 정확한 수준은 아니다. 물론 여기에는 한글 HWPX라는 포맷 자체가 파싱이 지랄같이 까다로운 이유도 한 몫한다. Pandoc의 개발기간과 노하우가 훨씬 더 풍부한 것도 있긴 하지만. 그런데 마침 맥 버전 한글 오픈소스 프로그램이 나왔는데, 한글 공식 버전 수준으로 프로그램의 완성도 수준이 높다고 하니, 그러면 이 참에 이 두 가지 소스를 리버스 엔지니어링 해서 pandoc 수준의 파싱/컴파일러 엔진 파이선 라이브러리를 완전히 새로 만들 수 있지 않을까? 라는 생각을 했었다. 그리고 여기에서 또 다시 지옥을 맛보고 처절하게 실패했다.

2026년 4월 22일부터 5월 7일 까지 약 2주간에 걸쳐 GPT-Pro에서 계획/PRD를 정리하고 - CODEX에서 코딩/백엔드 개발을 실행하고 - GPT-Pro에서 다시 리뷰하는 과정을 무수히 많이 반복했다. 그러나 결과물은 매우 형편없었다. hwp-compiler-core라고 명명한 새 엔진은 '분명 이전 버전보다 확실히 좋아졌습니다'라고 '코드 분석상으로' 말하는데, 라이브 뷰에서는 글자가 겹쳐서 출력되고, 종이 margin공간에 테이블이 나오고, HWPX output이 가로 landscape 모드로 강제로 고정되는 등, 버그의 작렬인데도 아무리 새 채팅창을 파서 온갖 방법으로 fresh review를 해도 전혀 나아질 기미가 보이지 않았다.

...그렇게 'pypandoc-hwpx를 pandoc 수준으로 업그레이드 해보자'라는 내 계획은,
처절하게 실패했다. 그리고 나는 이 프로젝트를 방치했다. 한 달이 넘도록.

8. 재 도전: Claude Code Opus 4.8

사실 중간 단계에서 1.7.0에서 1.8.0으로 버전이 넘어갈때는 괜찮아 보였다. 문제는 2.0.0 버전이 될때쯤 심각하게 망가지고 False Positive가 작렬했지. 다행히 나는 바이브 코딩 할때는 무조건 버전별로 폴더를 몇십개씩이라도 나눠서 만들고 수시로 깃허브에 따로따로 업로드 해라라는 교훈을 잊지 않고 있었기 때문에, 1.7.0 버전과 1.8.0 버전, 그리고 망가진 2.0.0 버전 등을 다 따로 가지고 있었고, rhwp와 HOP 등의 참고 소스도 폴더별로 다 따로 폴더로 나눠놓았다.

그래서 2026년 6월 초부터 다시 재도전해보기로 했다:
"프로젝트 폴더의 파일들을 보고, obsidian-hwp-writer는 내가 개발한 플러그인인데 1.7.0은 stable 버전이고, 여기에 들어간 hwpx 엔진을 pypandoc-hwpx기반에서 새 엔진으로 바꿔보려다가 개발에 실패해서 2.0.0에서 심각하게 false positive가 작렬하면서 망가졌는데 각각 크로스로 참조해서 분석해봐 (ultratink)"

솔직히 기대를 약간 해봤다. 그냥 아무런 근거는 없지만, 이유는 딱 하나였다.
여태까지 개발은 CODEX로만 했었지만, 이번엔 클로드 MAX 200불짜리를 들고 왔기 때문에.
그리고 클로드는 '설계'를 잘하는 편인 것 같아서.

9. 세 번째 좌절 : "클로드로 다시 각각 분석을 시켜서 설계를 다시 해보자" (실패)

결론부터 말하자면 이쪽도 다시 실패했다.
어쩌면 pandoc급의 hwpx 파싱 스크립트 오픈소스 라이브러리는 최소 몇년은 나오지 않을 지도 모르겠다. 혹시나 해서 .docx를 .hwpx로 변환하는 라이브러리도 있지 않을까 해서 찾아봤는데 이쪽도 없기는 마찬가지였다. 아, 한글이 이렇게 지랄맞은 포맷이란 말인가. 이러니까 다들 한글의 늪에서 못 빠져나왔구나.

10. 발상의 전환: "그런데 MD to HWPX말고 HWPX to MD는요?"

클로드로 시도하다가 실패한 와중에 최근 며칠간 눈에 띄는 버튼이 있었다.
바로 마크다운 ㅎ글을 참조해서 개발해놓은 과정에서 기능상 아무런 쓸모가 없고 그냥 "불러오기" 모양만 있는 조그마한 "불러오기" 버튼 하나.

10.1 이렇게까지 개발을 해놨는데, 근데 왜 아직도 안 써요?

한글만 쓰는 교수님들의 입장에서 다시 생각도 해보고, 최근에 학과 회의가 끝난 후 다른 교수님들과 회식을 하면서 알게 되었는데, 한 교수님의 경우 십 년에 걸쳐서 신문에 본인이 칼럼을 싣은 것이 한글 파일로 120편이 넘는다고 했다. 다른 교수님은 80편이 넘게 칼럼을 연재한 것을 HWP로 가지고 있다고 했다. 그런데 이 분들도 작년부터 옵시디언에 매우 관심을 가져서 쓰기 시작한 분들이었다.

**"내가 놓치고 있던 다른 한 부분은, MD to HWPX를 더 정교하게 하는게 아니라 'HWPX to MD'가 일단 가능하긴 하냐'가 아닐까?"

문득 이런 생각이 번개처럼 내 뇌리를 강타했다. 그리고 동시에 이런 생각을 했다:

**"아무 쓸모 없는 저 '불러오기' 버튼에 파일을 HWPX를 선택해서 - 더블클릭하는 단순한 동작으로 - 한글을 MD로 변환해서 새 노트로 만들어주는 거까지 하는 스크립트를 내장해버린다면, HWPX to MD가 되지 않을까?"

... 이런 생각을 하던 찰나에 깃허브를 뒤져보니 아주 타이밍 적절하게도 소스가 있었다.
바로 chrisryugj님이 만든 kordoc이라는 파싱 스크립트 패키지.

"대한민국에서 둘째가라면 서러울 문서지옥. 거기서 7년 버틴 공무원이 만들었습니다."
이 한 줄이면 내겐 설명이 충분했다. 그래 일단 해보자.
다행히 Claude Opus의 분석으로는 "불러오기" 버튼에 kordoc 스크립트를 내장해버리는 것 자체는 코딩 난이도가 높지 않았고, 실제로 금방 작업이 완료되었다.

...그리고 그렇게 "불러오기" 버튼에 내장된 kordoc은 믿을 수 없을 정도로 강력했다.
굉장히 단순하게 불러오기 - 더블클릭 액션으로 PDF/HWPX/DOCX를 불러오는데 내 옵시디언 볼트로 새 MD 문서가 '생성되면서' 파싱까지 동시에 되는 파이프라인이 가능해진 것이다.
옵시디언 web scrapper를 처음 개발한 사람이 이런 심정이었겠구나.

('불러오기'에 kordoc을 내장해서 사용하는 화면. obsidian-web-scrapper 수준의 반응 속도를 보여주었다.)

11. 마지막 난관: "오 이정도면 써볼거 같아요 그런데 '인스톨'버튼은 어디에 있어요?"

"...해치웠나?"
모든 웹툰이나 드라마나 히어로 물에서 가장 무서운 대사 중 하나다. 이 말을 하면 귀신같이 부활한단 말이야. "해치웠나?"라고 하기엔 아직 마지막 난관이 남아 있었다. 그러면 이제 '컴맹' 교수님들도 이걸 설치할 수 있게 해드리려면 어떻게 해야하는가.

컴맹도 이 플러그인을 설치하게 하려면 방법은 딱 하나다.
내 플러그인을 공식 커뮤니티 플러그인으로 발행한다.
그런데 내 플러그인에는 코드상에 obsidian 이라는 단어가 51번이 넘게 코드 본문에 반복되어 있었고,
커뮤니티 플러그인에 등록되기 위한 규칙 중 하나는 플러그인 명칭/코드 본문 네이밍에 '옵시디언'이라는 고유명사를 탑재하지 말것이라는 규칙도 있었다.

아... 이것 때문에 리팩토링 및 새 리포지토리 생성, 커뮤니티 플러그인 자동 리뷰 등록 과정을 번거롭게 또 거쳐야 한단 말인가. 하지만 여기서 포기하면 마라톤 풀코스 완주를 딱 1km 놔두고 두 다리 멀쩡하게 느리게라도 충분히 뛸 수 있으면서 힘들다고 걸으면서 엄살피우거나 포기하는 꼬락서니밖에 되지 않는다. 완주해야 한다. 그리고 마지막 피니시 라인은 바로 "커뮤니티 플러그인 등록"이다.

그리고 나는 끝내 '커뮤니티 플러그인 공식 등록'이라는 나만의 피니시라인을 넘었다.
이렇게 해서 세상에 공식 플러그인으로 빛을 보게 된 것이 바로 'HanMark (Hangul + Markdown)'이다. 범정부 오피스에서 HanMark까지, 총 283일 간의 대장정이 그렇게 일차로 막을 내렸다.

(옵시디언 공식 플러그인 커뮤니티 페이지에 등록한 HanMark의 소개 페이지)

(꽤 힘들었지만... 이렇게까지 해서라도 옵시디언에 끌어들일 수 있다면.. 나름대로 꽤 보람차지 않은가..)

솔직하게 미리 말하지만, HanMark는 아직 완벽하지 않다.
HWPX 템플릿 편집도 여전히 Pandoc 수준에 비해 멀었고,
Kordoc이라는 오픈소스의 힘을 빌어 비로소 실사용이 강력하게 되었지만 kordoc의 파싱로직이 절대만능인 것은 아니다.
툴바에 자잘한 버그들도 여전히 있고, 그 밖에 내가 놓친 부족한 것들이 많다.

그러나 중요한 것은 항상 "내가 이렇게까지 했는데!"라는 보상심리를 즉시 버리고
여태까지의 노력이 헛수고로 돌아가더라도 다시 초심으로 돌아가 사용자의 관점에서 다시 생각해볼 수 있는 용기를 택하는 것이다.

이렇게까지 해도 여전히 별로 관심이 없을지도 모른다.
어쩌면 이렇게까지 해도 여전히 별로 사용하지 않을지도 모른다.

그러나, 그럼에도 불구하고, 끝까지 나는 포기하지 않았고,
비로소 뭔가 꽤 쓸만한 것을 만들어냈다.
개발자가 아니어도 좋다.
바이브 코더든 뭐든 좋다.
중요한 것은 사용자의 관점을 생각하는 마음가짐과,
내 욕심과 좌절조차도 빨리 버리고 다시 끊임없이 도전하는 실천의 자세다.

최소한 이 정도면 나는 일반적인 '바이브 코더'라고 하기엔 정말 진짜로 '바이브 코딩'을 시작하는 사람들의 입장에선 나를 기겁하고 바라볼 정도가 되었다. 그럼에도, 그런 것은 중요하지 않다. 별로 칭찬받고 싶어서가 아니다. 그보다 이제서야, 이렇게까지 해본 나는 비로소 다른 사람들에게 되물을 수 있는 경험을 가지게 되었다.

당신은, 이렇게까지 무언가 집념을 가지고 프로젝트를 해본 것이 있습니까, 라고.