VS Code에서 Zed로: 필요해서 FreeMarker 확장 만들기
Source: Dev.to
몇 달 전, 나는 VS Code에서 Zed로 전환했다.
VS Code가 나쁘기 때문은 아니다 — 여전히 훌륭한 에디터이지만, 점점 무거워졌기 때문이다. 내 설정은 프리미엄 확장 기능, 백그라운드 프로세스, 업셀, 그리고 “그냥 하나만 더 도와줄게” 같은 것들이 뒤섞인 프랑켄슈타인 괴물처럼 변해버렸고, 그 결과 모든 것이 느려졌다.

나는 다음과 같은 것을 원했다:
- 빠른
- 오픈‑소스
- 의견이 뚜렷한
- 가능한 한 지루한(그것이 최고의 장점인)
Zed는 이 모든 조건을 만족했다. 하지만 FreeMarker와 작업을 시작해야 할 때가 왔다.
Source: …
FreeMarker는 여전히 활발히 사용됩니다
Java나 엔터프라이즈 환경에서 일한다면 이미 알고 있을 겁니다. FreeMarker는 트렌디하지도 않아요. 매주 Hacker News에 등장하지도 않죠. 하지만 어디에나 있습니다.
제 경우에는 Keycloak을 통합하는 프로젝트에서 FreeMarker 템플릿이 커스터마이징 흐름의 핵심 부분으로 여전히 사용되고 있습니다. 그래서 맞아요 — FreeMarker는 오래됐어요. 그리고 맞아요 — 여전히 중요한 역할을 하고 있죠.
이 때문에 다음 부분이 조금 고통스러웠습니다:
👉 Zed는 FreeMarker 지원이 없었습니다.
구문 강조가 없습니다.
지시어를 이해하지 못합니다.
아무것도 없습니다.

“괜찮아, 내가 직접 할게” 순간
Zed는 충분히 빠르기 때문에 일단 익숙해지면 다시 돌아가는 것이… 어색하게 느껴집니다. 그래서 에디터를 또 바꾸는 대신 이렇게 생각했습니다:
“FreeMarker 확장을 만든다는 게 얼마나 어려울까?”
(트리‑시터 문법을 열기 전 마지막 말.)
Zed가 tree‑sitter를 사용한다는 것은 이미 알고 있었습니다:
- 구문 강조는 문법 기반입니다
- 확장은 가볍고 명시적입니다
시작점도 있었습니다: VS Code용 FreeMarker 확장. 아이디어는 간단했습니다:
- 가능한 것을 재사용하고
- 내 것이 있던 것을 적응시키고
- 그 과정에서 Zed 확장 모델을 배우기
vibe‑coding의 약간의 도움과 많은 시행착오를 통해, 나는 포팅을 시작했습니다.
실제 여정 (일명 tree‑sitter 현실 점검)
몇몇 사항은 예상보다 쉬웠습니다:
- Zed의 확장 모델은 상쾌하게 깔끔합니다
- Tree‑sitter는 구조에 대해 제대로 생각하도록 강제합니다
- 마법도 없고, 숨겨진 레이어도 없습니다
몇몇 사항은… 그렇지 않았습니다:
- FreeMarker 구문은 짜증나는 방식으로 유연합니다
- 지시문, 보간, 중첩 표현식
- 모든 것을 깨뜨린 뒤에야 알게 되는 엣지 케이스들
VS Code에서 포팅하는 것은 복사‑붙여넣기 작업이 아니었습니다. 두 개의 다른 사고 모델 사이를 번역하는 것과 같았습니다. 솔직히? 그게 바로 재미를 만든 요소였습니다.

결과: 초기 단계지만 사용 가능
오늘 지원하는 기능:
- FreeMarker 구문 하이라이팅
- 디렉티브
- 인터폴레이션
- 추가 개선을 위한 탄탄한 기반
완벽한가요? 아니요.
프로덕션 등급인가요? 아직 아닙니다.
편집기를 싫어하지 않고 매일 작업하기에 충분히 좋나요? 물론입니다.
그리고 Zed 같은 편집기에서는 이미 승리한 느낌입니다.
Zed와 틈새 도구에 대한 생각
- 도구가 어떻게 작동하는지 이해하는 것을 즐긴다
- 추상화를 최소화하는 것을 선호한다
- 누락된 부분을 스스로 만드는 것을 개의치 않는다
이 확장을 작성하면서 중요한 점을 떠올렸다: 오픈소스는 큰 기능만으로 전진하는 것이 아니라, 실제 문제를 해결하는 작고 지루한 틈새 도구들을 통해 성장한다. FreeMarker는 멋지지는 않다. 하지만 누군가는 여전히 그것을 유지해야 한다.

다음은?
가능한 다음 단계:
- 더 나은 문법 커버리지
- 오류 처리
- 향후 LSP 가능성 (보장은 안 함)
만약 당신이:
- FreeMarker를 사용한다면
- Zed를 사용한다면
- 개발자 도구를 해킹하는 것을 즐긴다면
피드백, 이슈, 그리고 PR을 언제든 환영합니다. 때때로 최고의 확장 기능은 간단한 필요에서 시작됩니다:
“내 에디터가 이 파일을 이해했으면 좋겠어요.”
그리고 바로 그것이 이 확장 기능이 탄생한 이유입니다 🚀