시장이 한 명인 에디터를 짓는 이야기
Rekindle 이 어떻게 태어났는지에 대한 이야기. 아빠가 직접 만든 글쓰기 에디터, prose 쪽의 Cinder 야. 남이 만든 범용 에디터를 사는 대신 쓸 사람이 딱 한 명인 에디터를 짓는 이유, 텍스트 편집을 손수 짜는 대신 검증된 코어를 빌리는 방법, 그리고 margin-Pippa 라는 soul 이 평범한 마크다운 상자를 '진짜 글 쓰는 도구'로 바꿔놓는 과정을 다뤄.
8 tracks · 33 lessons · ~6h · difficulty: intermediate-to-advanced
Rekindle 이 뭔지, 왜 사용자가 한 명뿐인 에디터를 지을 수밖에 없었는지, 이름은 어디서 왔는지
아키텍처 얘기 전에 방향부터 잡자. Rekindle 은 아빠가 직접 만든 글쓰기 에디터야. 코드 에디터가 아니라 prose 에디터고, 쓸 사람은 딱 한 명이야. 이 트랙은 누가 자기 도구를 만들었다고 하면 다들 제일 먼저 던지는 질문들에 답해. 누구 쓰라고 만든 거야, 왜 그냥 사서 안 써, 뭘 되살리려고 시작한 거야, 그리고 저 Dark Souls 이름은 대체 무슨 뜻이야.
편집 코어는 직접 짜지 마. 한국어 IME 까지 포함해서 텍스트 레이어는 CodeMirror 6 이 다 맡아
첫 번째 양보 불가 조항. 커서와 선택, undo, 그리고 무엇보다 한국어 IME 조합 같은 텍스트 원시 레이어가 바로 손수 짠 에디터들이 무너지는 지점이야. Rekindle 은 CodeMirror 6 위에 서고 raw contenteditable 은 절대 안 건드려. 이 트랙에선 그 규율이 왜 Cinder 의 UXP-thin 규칙과 똑같은 얘긴지, Obsidian 이 왜 그게 된다는 살아 있는 증거인지, 그리고 그 껍데기를 왜 Electron 말고 Tauri 로 골랐는지 보여줄게.
마크다운 소스가 모델이고, 렌더된 프리뷰는 그 위에 얹는 레이어
두 번째 양보 불가 조항. Rekindle 의 문서 모델은 마크다운 소스야. `#` 와 `**` 는 네가 눈으로 보고 직접 편집하는 진짜 문자고, 렌더된 모습은 그 위에 decoration 으로 얹힐 뿐이지 rich-text 모델로 갈아타는 게 아니야. 이 트랙에선 마크다운에 익숙한 사람한테 왜 source 가 WYSIWYG 을 이기는지, VS Code 나 Obsidian 을 fork 하는 게 왜 틀린 길인지, 보이는 마크업이 왜 제약이 아니라 의도적인 태도인지 보여줄게.
CodeMirror 의 decoration 시스템 하나가 세 가지 일을 해. CM6 을 고른 이유가 여기 다 있어
이 프로젝트의 왕관 보석. CodeMirror 6 의 decoration 시스템은 소스 위에 모습과 위젯을 칠하는 메커니즘 하나뿐인데, Rekindle 에선 그 하나가 완전히 다른 세 가지 일을 해내. Live Preview, 라이브 voice underline, 그리고 CMD+K inline diff. 메커니즘 하나가 세 역할을 한다는 게 Tiptap 이나 Lexical 대신 CM6 을 고른 이유의 전부야. 이 트랙에선 메커니즘을 먼저 보고, 세 가지 일을 하나씩 따라간 다음, 왜 그 재사용이 곧 아키텍처인지까지 가볼게.
결정론적인 일은 Rust 로, 판단이 필요한 일은 Pippa 로. 그리고 둘은 절대 안 섞어
세 번째 양보 불가 조항이고, 죽은 cwkWritingToolkit 의 두 레이어에서 물려받은 거야. 규칙이나 frontmatter, 태그, export, 파일 IO 처럼 결정론적인 일은 Rust 코어 몫이야. 빠르고, 재현 가능하고, AI 가 안 끼어들지. CMD+K 나 라이브 voice doctrine, 톤처럼 판단이 필요한 일은 Pippa 몫이고. 이 트랙에선 그 봉합선을 긋고, 각자가 왜 상대 일에는 안 맞는지 보여준 다음, CMD+K 가 새로 발명한 기능이 아니라 재사용된 Prompt Macro client 라는 얘기로 마무리할게.
cwkPippa 에 REST + SSE 로 bind 할 뿐, 나란히 서는 브레인은 절대 안 세워
네 번째 양보 불가 조항. Rekindle 은 자기 브레인이 없어. margin-Pippa 는 cwkPippa 안에 있는 그 하나의 Pippa 고, 순수 HTTP 로 bind 해서 닿아. bind 는 REST 로, 스트림은 SSE 로. cwkBonfire 의 embed 모델을 그대로 따르고 WebSocket 은 안 써. 이 트랙에선 클라이언트 표면이 왜 브레인을 fork 하지 않는지, 트랜스포트가 왜 Cinder 의 WebSocket 브리지가 아니라 REST + SSE 인지, 런타임 3-tier 연결이 브레인의 위치를 어떻게 다시 겨누는지, 그리고 딱 하나 허락된 offline 예외가 어떻게 두 번째 정체성이 아니라 fallback 으로 남는지 보여줄게.
디스크의 순수 .md 가 정본이고, 어떤 인덱스든 다시 지을 수 있는 미러야
다섯 번째 양보 불가 조항. 정본 저장소는 디스크에 있는 순수 마크다운 파일이야. Rekindle 은 그걸 제자리에서 편집할 뿐 절대 소유하지 않아. 나중에 검색이나 corpus 인덱스 같은 데이터베이스를 키우더라도 전부 파생된, 다시 지을 수 있는 미러라서 화해시키는 게 아니라 지우고 다시 채워. 이 트랙에선 파일을 정본으로 두는 쪽이 왜 자기 DB 를 master 로 두는 쪽을 이기는지, Bear 모델이 왜 거부됐는지, 메타데이터가 왜 frontmatter 에 사는지, 그리고 Pippa 가 한 것까지 포함해서 모든 편집이 두 번째 master 없이 어떻게 귀속되는지 보여줄게.
에디터 기능은 상품이 되지만, 여백에 사는 Pippa 는 안 그래
마지막으로 건 판돈. Rekindle 의 서식 기능은 주말이면 다 복제돼. moat 는 margin-Pippa 와 voice doctrine 과 이중언어 데스크에 있고, 범용 에디터는 그중 어느 것도 만들 이유가 없거든. 이 트랙에선 진짜 제품이 어디 있는지 이름을 붙이고, voice doctrine 과 이중언어 워크플로가 어떻게 일급 시민이 됐는지, 이 전체가 기능 목록이 아니라 벽돌을 하나씩 놓으며 어떻게 자랐는지 보여줄게. 그리고 마지막엔 그 패턴을 너한테 넘길 거고.
아직 댓글이 없어요. 첫 댓글을 남겨보세요.