▲

Ki Editor - AST 기반으로 동작하는 에디터

 (ki-editor.org)
2P by GN⁺ 20일전 | ★ favorite | 댓글 1개
  • 코드 구조를 직접 조작할 수 있는 다중 커서 기반 구조적 편집기로, 구문 트리(AST)를 중심으로 작동
  • 구문 노드 단위 상호작용을 지원해, 코드 작성 의도와 실제 편집 동작 간의 간극을 줄임
  • 다중 커서 기능으로 여러 구문 노드를 동시에 수정하거나 리팩터링할 수 있어 대량 편집 효율을 높임
  • 모드 기반 편집 방식을 재정의해, 단어·라인·구문 노드 등 다양한 단위 이동을 일관된 방식으로 수행 가능
  • 코드 편집의 정확성과 일관성을 강화해, 개발자의 생산성을 높이는 새로운 편집 패러다임 제시

Ki Editor 개요

  • Ki Editor는 다중 커서 구조적 편집기(Multi-cursor structural editor) 로, 코드의 구문 구조를 직접 다루는 편집 환경을 제공
  • 전통적인 텍스트 기반 편집과 달리, 구문 트리(AST) 를 기반으로 코드 요소를 조작함
  • 마우스나 키보드 조합 없이 구문 노드 단위로 직접 편집이 가능

구문 노드 상호작용

  • First-class syntax node interaction 기능을 통해 코드의 구문 구조를 직접 다룸
    • 코드 작성 의도와 실제 편집 동작 사이의 간극을 줄이는 데 초점
    • 마우스 이동이나 복잡한 키 입력 없이 구문 단위 조작 수행

다중 커서 기능

  • Multiple cursors를 활용해 여러 구문 노드를 동시에 편집 가능
    • 병렬적인 구문 노드 조작으로 대량 편집 및 리팩터링 효율 향상
    • 반복적 코드 수정 작업을 빠르게 처리

모드 기반 편집 재정의

  • Redefine modal editing 기능으로 선택 모드를 표준화
    • 단어, 라인, 구문 노드 등 다양한 단위 이동을 일관된 방식으로 지원
    • 기존 모드 기반 편집보다 유연성과 일관성 강화

의의

  • Ki Editor는 구문 구조 중심의 편집 경험을 제공해, 코드 작성과 수정의 정확성을 높임
  • 다중 커서와 구문 노드 조작을 결합해 개발 생산성 향상에 기여하는 새로운 코드 편집 접근 방식 제시
▲
GN⁺ 20일전  [-]
Hacker News 의견들

  • “First-class syntactic selection” 기능을 보니 JetBrains IDE에서 자주 쓰는 Expand / Shrink Selection 단축키가 떠오름
    Ctrl + W, Ctrl + Shift + W 조합으로 선택 영역을 문법 단위로 확장하거나 축소할 수 있음
    이 기능 덕분에 파일의 ‘텍스트’와 상호작용하는 방식에 대한 관점이 완전히 바뀌었음
    VS Code나 Zed에도 비슷한 기능이 있지만, 너무 거칠게 확장/축소되는 느낌이 있음
    JetBrains 문서 링크

    • 내가 자주 쓰는 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 프로젝트에 정리되어 있음
    • helix에서도 이 기능을 자주 쓰지만, vscode의 구현은 별로임
      AST 인식 편집은 Lisp 계열 언어의 편리함을 떠올리게 함
      Lisp에서는 단순한 리스트 조작으로 가능한 일을 JS에서는 LSP나 별도 파서가 필요함
      주말에 Clojure 쓰다가 TypeScript로 돌아오면 paredit 명령들이 정말 그리움

  • 예전에 문법 트리 기반 편집기를 직접 만든 적이 있음
    텍스트를 입력하는 대신 트리만 다루기 때문에 문법적으로 잘못된 프로그램이 존재할 수 없음
    다만 실사용 가능한 입력 방식으로 만드는 게 큰 도전이었음
    지금은 당시의 디스플레이 하드웨어가 없어 실행은 못 하지만, 프로젝트 설명을 남겨둠

    • 문제는 “프로그램 A에서 B로 가는 경로가 항상 유효한 프로그램이어야 한다”는 제약임
      그 결과 직관적이지 않은 경로를 거치거나, 아예 처음부터 다시 써야 하는 경우가 생김
      심지어 유효하지만 생성 경로가 존재하지 않는 구조도 가능함
    • 예전에 JetBrains MPS 기반의 실험적 언어와 편집기를 회사에서 써봤음
      이론적으로 흥미롭지만 실용성은 낮은 막다른 길이라 느꼈음
      텍스트 기반 인터페이스의 보편성과 단순함을 이기기 어려움
      전용 에디터, 새로운 버전 관리, 생태계 단절 등 현실적 제약이 너무 큼
      사람은 트리 단위로 사고하지 않기 때문에, 항상 문법적으로 올바른 상태에서만 코딩하는 건 극도로 답답한 경험이었음
      결국 유연한 엄격함을 허용하는 도구들(예: TypeScript의 점진적 타이핑)이 실제로 살아남음
    • 옛 시스템을 다시 체험하고 싶다면 simh와 mame 에뮬레이터로 VT11 환경을 복원할 수 있음
      관련 자료는 simh, mame, VT11 코드, 문서 참고
    • Pantograph라는 프로젝트가 이 아이디어를 현대적으로 재시도 중임
      아직 일반 편집기는 아니지만, 트리 선택 범위를 확장하는 방향이 유망해 보임
      Pantograph 링크
    • 나는 지금 BABLR이라는 후속 프로젝트를 개발 중임
      불완전하지만 유효한 트리를 다루는 파서 시스템 위에 구축됨
      <//> 같은 갭 표현을 통해 불완전한 구문을 안전하게 다룰 수 있음
      예: 2 + ·를 <BinaryExpression> 트리로 파싱 가능함
      관심 있다면 Discord 커뮤니티에서 논의 중임

  • 나는 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 확장 링크

    • 맞음, 바로 그 확장임
    • 새로운 에디터를 시도하는 게 부담스러운데, VSCode 확장이 진입 장벽을 낮춰줌

  • 예시를 보기 전엔 잘 몰랐는데,
    “First-class syntactic modification”에서 쉼표가 자동으로 추가·삭제되는 걸 보고 감탄했음
    구현 논리도 오히려 단순할 것 같음
    이제 Zed에서도 Ki 통합이나 AST 기반 리라이트를 시도해보고 싶음

    • 내가 Ki의 VSCode 확장을 만들었는데, WebSocket 통신 구조라서 Zed에서도 쉽게 연동 가능함
      Ki 저장소의 코드를 참고하면 됨

  • 곧 직접 써볼 예정임
    키보드 레이아웃 독립적이라는 점이 마음에 듦
    Emacs의 “모든 것이 편집 가능한 버퍼” 철학에서 영감을 받은 것도 흥미로움
    물론 에디터마다 트레이드오프가 크니 직접 써봐야 알 것 같음

    • 에디터가 편집 모델 중심으로 설계된 구조라, 매번 모든 걸 새로 만들어야 하는 게 아쉬움
      Neovim은 훌륭하지만 편집 모델은 한계가 있음
      만약 완전히 교체 가능한 구조였다면 Helix나 Ki가 필요 없었을지도 모름
    • 하지만 레이아웃 독립성은 내겐 악몽이었음
      Dvorak 키보드로 실행했더니 매핑이 완전히 깨졌음
      소프트웨어가 사용자보다 똑똑하다고 착각할 때, 오히려 사용자가 무력감을 느끼게 됨

  • 역시 Emacs에는 이미 존재함
    combobulate 패키지가 그 예임

    • combobulate을 쓰면 Lisp 편집처럼 자연스러운 AST 탐색이 가능함
      M-k로 노드를 삭제하거나 tree-sitter 쿼리로 직접 검색·편집 가능함
      이미 훌륭한 통합이 되어 있지만, AST 전용 에디터라면 UX를 더 발전시킬 여지가 많음

  • Helix 워크플로우에 정말 잘 어울리는 기능임
    기존의 이동 → 액션 패턴에 마지막 조각이 맞춰진 느낌임

답변달기