# Ki Editor - AST 기반으로 동작하는 에디터 > Clean Markdown view of GeekNews topic #27298. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=27298](https://news.hada.io/topic?id=27298) - GeekNews Markdown: [https://news.hada.io/topic/27298.md](https://news.hada.io/topic/27298.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-03-08T09:48:05+09:00 - Updated: 2026-03-08T09:48:05+09:00 - Original source: [ki-editor.org](https://ki-editor.org/) - Points: 2 - Comments: 1 ## Topic Body - **코드 구조를 직접 조작**할 수 있는 다중 커서 기반 **구조적 편집기**로, 구문 트리(AST)를 중심으로 작동 - **구문 노드 단위 상호작용**을 지원해, 코드 작성 의도와 실제 편집 동작 간의 간극을 줄임 - **다중 커서 기능**으로 여러 구문 노드를 동시에 수정하거나 리팩터링할 수 있어 대량 편집 효율을 높임 - **모드 기반 편집 방식**을 재정의해, 단어·라인·구문 노드 등 다양한 단위 이동을 일관된 방식으로 수행 가능 - 코드 편집의 **정확성과 일관성**을 강화해, 개발자의 생산성을 높이는 새로운 편집 패러다임 제시 --- ### Ki Editor 개요 - Ki Editor는 **다중 커서 구조적 편집기(Multi-cursor structural editor)** 로, 코드의 구문 구조를 직접 다루는 편집 환경을 제공 - 전통적인 텍스트 기반 편집과 달리, **구문 트리(AST)** 를 기반으로 코드 요소를 조작함 - 마우스나 키보드 조합 없이 **구문 노드 단위로 직접 편집**이 가능 ### 구문 노드 상호작용 - **First-class syntax node interaction** 기능을 통해 코드의 구문 구조를 직접 다룸 - 코드 작성 의도와 실제 편집 동작 사이의 간극을 줄이는 데 초점 - 마우스 이동이나 복잡한 키 입력 없이 **구문 단위 조작** 수행 ### 다중 커서 기능 - **Multiple cursors**를 활용해 여러 구문 노드를 동시에 편집 가능 - 병렬적인 구문 노드 조작으로 **대량 편집 및 리팩터링 효율** 향상 - 반복적 코드 수정 작업을 빠르게 처리 ### 모드 기반 편집 재정의 - **Redefine modal editing** 기능으로 선택 모드를 표준화 - 단어, 라인, 구문 노드 등 다양한 단위 이동을 **일관된 방식**으로 지원 - 기존 모드 기반 편집보다 **유연성과 일관성** 강화 ### 의의 - Ki Editor는 **구문 구조 중심의 편집 경험**을 제공해, 코드 작성과 수정의 정확성을 높임 - 다중 커서와 구문 노드 조작을 결합해 **개발 생산성 향상**에 기여하는 새로운 코드 편집 접근 방식 제시 ## Comments ### Comment 52587 - Author: neo - Created: 2026-03-08T09:48:05+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47286311) - “**First-class syntactic selection**” 기능을 보니 JetBrains IDE에서 자주 쓰는 **Expand / Shrink Selection** 단축키가 떠오름 `Ctrl + W`, `Ctrl + Shift + W` 조합으로 선택 영역을 문법 단위로 확장하거나 축소할 수 있음 이 기능 덕분에 파일의 ‘텍스트’와 상호작용하는 방식에 대한 관점이 완전히 바뀌었음 VS Code나 Zed에도 비슷한 기능이 있지만, 너무 **거칠게 확장/축소**되는 느낌이 있음 [JetBrains 문서 링크](https://www.jetbrains.com/help/idea/working-with-source-code.html#editor_code_selection) - 내가 자주 쓰는 JetBrains 단축키는 다음과 같음 **Cmd+Shift+V**로 스택 클립보드를 열어 과거 복사 내역을 검색하거나 선택 가능함 **Cmd+Shift+E**는 최근 위치 목록을 보여주고, **Cmd+Shift+A**는 액션 팔레트를 열어 모든 명령을 퍼지 검색할 수 있음 또 **Local History** 기능으로 Git보다 훨씬 세밀하게 파일 변경 이력을 추적할 수 있음 이런 기능들은 “검색 결과 버퍼에서 바로 편집”할 수 있는 개념으로 이어짐 - Neovim에서도 tree-sitter 기반의 `incremental selection`으로 같은 기능을 쓸 수 있음 - Mathematica는 90년대 초부터 Alt+.로 선택 확장 기능을 제공했음 더블클릭은 단어, 트리플클릭은 함수 인자 전체, 4번 클릭은 f(a,r,g,s) 전체를 선택하는 식으로 **클릭 횟수에 따라 문법 단위가 커지는 구조**였음 아직도 그 근육 기억이 남아 있음 - 나는 **AST 기반 버전 관리**를 연구 중임 커밋이나 diff, cherry-pick에서도 Ctrl+W처럼 문법 단위로 작동하게 하는 아이디어를 실험 중임 관련 내용은 [librdx 프로젝트](https://github.com/gritzko/librdx/tree/master/be#readme)에 정리되어 있음 - helix에서도 이 기능을 자주 쓰지만, vscode의 구현은 별로임 AST 인식 편집은 **Lisp 계열 언어의 편리함**을 떠올리게 함 Lisp에서는 단순한 리스트 조작으로 가능한 일을 JS에서는 LSP나 별도 파서가 필요함 주말에 Clojure 쓰다가 TypeScript로 돌아오면 paredit 명령들이 정말 그리움 - 예전에 **문법 트리 기반 편집기**를 직접 만든 적이 있음 텍스트를 입력하는 대신 트리만 다루기 때문에 **문법적으로 잘못된 프로그램이 존재할 수 없음** 다만 실사용 가능한 입력 방식으로 만드는 게 큰 도전이었음 지금은 당시의 디스플레이 하드웨어가 없어 실행은 못 하지만, [프로젝트 설명](https://ucalgary.scholaris.ca/items/da8b823b-c344-4ffb-aa37-baf3f37c3fd7)을 남겨둠 - 문제는 “프로그램 A에서 B로 가는 경로가 항상 유효한 프로그램이어야 한다”는 제약임 그 결과 **직관적이지 않은 경로**를 거치거나, 아예 처음부터 다시 써야 하는 경우가 생김 심지어 유효하지만 생성 경로가 존재하지 않는 구조도 가능함 - 예전에 JetBrains **MPS** 기반의 실험적 언어와 편집기를 회사에서 써봤음 이론적으로 흥미롭지만 **실용성은 낮은 막다른 길**이라 느꼈음 텍스트 기반 인터페이스의 **보편성과 단순함**을 이기기 어려움 전용 에디터, 새로운 버전 관리, 생태계 단절 등 현실적 제약이 너무 큼 사람은 트리 단위로 사고하지 않기 때문에, 항상 문법적으로 올바른 상태에서만 코딩하는 건 **극도로 답답한 경험**이었음 결국 **유연한 엄격함**을 허용하는 도구들(예: TypeScript의 점진적 타이핑)이 실제로 살아남음 - 옛 시스템을 다시 체험하고 싶다면 **simh**와 **mame** 에뮬레이터로 VT11 환경을 복원할 수 있음 관련 자료는 [simh](https://simh.trailing-edge.com/), [mame](https://www.mamedev.org/), [VT11 코드](https://github.com/simh/simh/blob/master/PDP11/pdp11_vt.c), [문서](https://wiki.mamedev.org/index.php/MAME_and_SIMH) 참고 - **Pantograph**라는 프로젝트가 이 아이디어를 현대적으로 재시도 중임 아직 일반 편집기는 아니지만, 트리 선택 범위를 확장하는 방향이 유망해 보임 [Pantograph 링크](https://pantographeditor.github.io/Pantograph/) - 나는 지금 **BABLR**이라는 후속 프로젝트를 개발 중임 불완전하지만 유효한 트리를 다루는 파서 시스템 위에 구축됨 `` 같은 **갭 표현**을 통해 불완전한 구문을 안전하게 다룰 수 있음 예: `2 + ·`를 `<BinaryExpression>` 트리로 파싱 가능함 관심 있다면 [Discord 커뮤니티](https://discord.gg/NfMNyYN6cX)에서 논의 중임 - 나는 AST 편집에 익숙하지 않음 함수 인자나 arglist를 다루는 **텍스트 객체** 정도만 사용함 LSP 기능은 정의로 이동과 이름 변경 정도만 씀 결국 **에디터 실력을 더 키워야겠다는 자극**을 받음 - 이런 경우 **ast-grep** 같은 도구가 유용함 코드와 거의 같은 문법으로 패턴을 작성해 변환을 눈앞에서 볼 수 있음 예를 들어 `ast-grep -pattern '$A && $A.$B' --rewrite '$A?.$B' -lang ts` 식으로 **옵셔널 체이닝 변환** 가능함 메타변수 `$X`, `$A` 등은 동일 노드 매칭을 강제함 아직 AI 코딩 에이전트가 이런 패턴을 잘 못 쓰지만, 도구 자체는 매우 탄탄함 - 실제로는 AST 구조를 깊이 이해하지 않아도 됨 대부분은 **문법 노드 단위로 선택 후 삭제·복사·치환**만 하면 충분함 - 사람마다 업무가 달라서 AST 편집의 필요성도 다름 나는 대규모 리팩터링을 자주 하지 않기 때문에 굳이 배울 필요를 못 느낌 하지만 대형 서비스 개발자라면 완전히 다른 의견일 수 있음 - 나도 비슷한 입장임 Elixir에서 **매크로 작성**을 배우며 많은 통찰을 얻었고, Lisp도 같은 맥락임 언어마다 접근법은 달라도 결국 같은 목적지로 향함 - 내가 보는 에디터 분류는 다음과 같음 1) **정통형(Orthodox)** — UI와 통합성 중심 2) **모달형(Vim 개선)** — 기존 키바인딩 유지 3) **모달형(새 접근)** — Vim 철학을 재해석 Ki는 세 번째 부류에 속하며, 나는 이런 프로젝트를 꾸준히 주시함 - 4번째 분류도 있음 — **모두를 포괄하는 Emacs** - 나도 같은 생각임. 도전자는 많았지만 여전히 **챔피언은 하나**라고 느낌 - 나도 AST 기반 모달 코드 에디터를 개발 중임 UI 노드가 일반 텍스트처럼 보이지만 실제로는 트리 구조임 초기 피드백을 받고 싶다면 프로필의 이메일로 연락 바람 - Vim 개선이라면, 결국 “**Ed Visual Mode Improved Improved**”라는 농담이 나올 정도임 - AST 편집의 어려움은 **발견 가능성(discoverability)** 임 화면에 보이긴 하지만 그 노드의 이름을 모를 때가 많음 그래서 커서 주변을 색상으로 감싸 각 **스코프를 시각화**하는 플러그인을 구상 중임 “다음 함수로 이동” 대신 “다음 파란색으로 이동” 같은 식으로 생각하는 방식임 - Ki에서는 노드 이름을 몰라도 `d m`을 누르면 **현재 보이는 모든 문법 노드의 라벨**을 표시해 바로 이동할 수 있음 - 그래도 **일반적인 AST 수준의 선택/축소 기능**은 여전히 가치가 있음 현재 노드 안쪽 혹은 바깥쪽을 선택하는 식의 조작이 유용함 - 나는 **VSCode용 Ki 통합**을 만들었음 이후 기여를 많이 못 해 아쉽지만, 이런 **기초 도구 혁신**은 매우 중요하다고 생각함 [Ki VSCode 확장 링크](https://marketplace.visualstudio.com/items?itemName=ki-editor.ki-editor-vscode) - 맞음, 바로 그 확장임 - 새로운 에디터를 시도하는 게 부담스러운데, VSCode 확장이 **진입 장벽을 낮춰줌** - 예시를 보기 전엔 잘 몰랐는데, “**First-class syntactic modification**”에서 쉼표가 자동으로 추가·삭제되는 걸 보고 감탄했음 구현 논리도 오히려 단순할 것 같음 이제 Zed에서도 Ki 통합이나 **AST 기반 리라이트**를 시도해보고 싶음 - 내가 Ki의 VSCode 확장을 만들었는데, **WebSocket 통신 구조**라서 Zed에서도 쉽게 연동 가능함 Ki 저장소의 코드를 참고하면 됨 - 곧 직접 써볼 예정임 **키보드 레이아웃 독립적**이라는 점이 마음에 듦 Emacs의 “모든 것이 편집 가능한 버퍼” 철학에서 영감을 받은 것도 흥미로움 물론 에디터마다 **트레이드오프**가 크니 직접 써봐야 알 것 같음 - 에디터가 **편집 모델 중심으로 설계된 구조**라, 매번 모든 걸 새로 만들어야 하는 게 아쉬움 Neovim은 훌륭하지만 편집 모델은 한계가 있음 만약 완전히 교체 가능한 구조였다면 Helix나 Ki가 필요 없었을지도 모름 - 하지만 **레이아웃 독립성**은 내겐 악몽이었음 Dvorak 키보드로 실행했더니 매핑이 완전히 깨졌음 소프트웨어가 사용자보다 똑똑하다고 착각할 때, 오히려 사용자가 **무력감을 느끼게 됨** - 역시 **Emacs에는 이미 존재함** [combobulate](https://github.com/mickeynp/combobulate) 패키지가 그 예임 - combobulate을 쓰면 **Lisp 편집처럼 자연스러운 AST 탐색**이 가능함 M-k로 노드를 삭제하거나 tree-sitter 쿼리로 직접 검색·편집 가능함 이미 훌륭한 통합이 되어 있지만, **AST 전용 에디터**라면 UX를 더 발전시킬 여지가 많음 - Helix 워크플로우에 정말 잘 어울리는 기능임 기존의 **이동 → 액션** 패턴에 마지막 조각이 맞춰진 느낌임