파서 라이브러리 끝판왕인 줄 알았던 트리시터의 의외의 한계점

요약 구문 분석기(파서) 생성 툴킷인 '트리시터(tree-sitter)'가 모든 개발 환경에서 만능 해결책이 될 수 있는지에 대해 한 개발자가 실제 한계를 짚은 기술 분석 글입니다. 트리시터는 빠른 속도와 오류 복구(error-tolerant) 기능을 갖춘 파서를 쉽게 작성할 수 있도록 돕는 툴로, 깃허브(GitHub)의 코드 탐색이나 구문 강조(신택스 하이라이팅) 등 다양한 언어를 폭넓게 지원해야 하는 프로젝트에서는 매우 유용하게 쓰입니다. 예를 들어 특정 언어 문법에 사소한 버그가 있더라도 여러 언어를 두루 지원하는 것이 더 중요한 에디터 환경이나, CI 시스템에서 코드 포맷팅/주석 변경 시 불필요한 재리뷰를 건너뛰기 위해 구문 트리를 비교하는 용도로는 매우 훌륭합니다. 하지만 작성자는 파서의 품질 자체가 최우선이고 단 하나의 언어만을 완벽하게 다뤄야 하는 상황이라면 트리시터가 매력적이지 않다고 지적합니다. 특히 개발 도중 끊임없이 문법 에러가 발생하는 편집기 내 '자동완성(autocompletion)' 기능 구현이나, 문맥에 따라 상세하고 정교한 맞춤형 문법 에러 메시지를 제공해야 하는 작업에서는 선언적 DSL(도메인 특화 언어) 방식의 트리시터가 명확한 한계를 드러낸다고 설명합니다. 실제 루비(Ruby)나 자바스크립트(JavaScript)에서 사용자가 메서드 호출 도중 점(`.`)만 찍었거나 상수에 접근하려는 미완성 코드를 입력했을 때, 트리시터는 호출 노드를 유지하지 못하고 전체 블록을 단순 에러로 뭉개버려 자동완성에 필요한 리시버(receiver) 정보를 전달하지 못하는 문제를 예시로 들었습니다. 결국 복잡한 문제를 해결하기 위해 트리시터 문법 자체에 별도의 기교를 부려야 한다면, 차라리 프로젝트에 맞춤형 파서를 직접 구현하는 편이 나을 수 있다는 결론을 제시하고 있습니다.