요즘 문법 검사 도구는 기능이 많아질수록 무거워지고, 클라우드 의존성도 커지는 경우가 많습니다. Harper는 정반대 방향에 서 있습니다. README는 비용, 과도한 제안, 프라이버시 문제, 무거운 메모리 사용량에 대한 불만을 꽤 직접적으로 적고 있는데, 이 솔직함이 저장소의 설계 방향을 잘 설명합니다.
해당 Repository의 접속 URL 및 version. Commit 빈도수에 따른 업데이트 수준.
- 저장소: https://github.com/Automattic/harper
- 최신 release:
v1.12.0 - 최신 commitSha:
ecc6db924dfb374dff7257b114e91d48367b0c9f - 업데이트 수준: 2026년 4월 6일 기준 최근 푸시가 확인되고 릴리스도 계속 이어져, 실험적 장난감이 아니라 실제 제품화를 지속하는 프로젝트로 보입니다.
무엇을 하는 저장소인가
Harper는 영어 문법 검사를 수행하는 경량 도구입니다. 핵심은 로컬에서 빠르게 실행되고, 작성 내용을 외부 서버로 보내지 않으며, WebAssembly와 Language Server 형태로도 배포 가능하다는 점입니다. 즉, 단일 앱이라기보다 에디터와 워크플로에 들어갈 수 있는 언어 품질 엔진에 가깝습니다.
핵심 특징
첫째는 성능 중심 설계입니다. README는 milliseconds 단위 lint와 낮은 메모리 사용량을 반복해서 강조합니다. 이 덕분에 에디터 플러그인이나 실시간 검사 도구에 넣기 좋은 성격을 갖습니다.
둘째는 프라이버시 우선 접근입니다. 클라우드 서버로 텍스트를 보내지 않는다는 점은 기업 환경이나 민감한 문서 작업에서 큰 장점이 됩니다. 요즘에는 이것만으로도 충분한 차별점이 됩니다.
셋째는 배포 형태의 유연성입니다. Language Server, JavaScript 패키지, WebAssembly 등으로 접근할 수 있어 다양한 편집 환경에 붙이기 좋습니다.
- 빠른 실행 속도와 낮은 메모리 사용량을 지향합니다.
- 텍스트를 외부 서버로 보내지 않는 로컬 중심 구조입니다.
- Language Server와 WebAssembly로 통합 범위를 넓힙니다.
실무에서 기대할 수 있는 효과
문서 품질을 높이고 싶지만, 상용 문법 검사기를 전사 도입하기 부담스러운 팀에 현실적인 선택지가 될 수 있습니다. 개발 문서, 블로그 초안, 제품 설명문 같은 작업에서 기본 문법 오류를 빠르게 줄여 줍니다.
또한 사내 에디터 환경에 붙이기 쉽다는 점도 장점입니다. VS Code, Neovim, Helix, Zed 같은 에디터 통합 경로가 이미 보이기 때문에, 개인 생산성 도구로도 도입 장벽이 낮습니다.
실제로 볼 만한 예시
- 영문 기술 문서를 자주 쓰는 개발 조직이 CI 전 단계 또는 에디터 내 검사 도구로 Harper를 사용해 기본 품질을 일정 수준 이상으로 유지할 수 있습니다.
- 외부 SaaS로 텍스트를 보내기 어려운 보안 민감 조직에서 로컬 문법 검사기를 표준 도구로 삼는 장면도 충분히 상상할 수 있습니다.
장점과 한계
장점은 선명합니다. 빠르고 가볍고 사적인 도구라는 정체성이 매우 분명합니다. 기능 범위를 과도하게 넓히지 않으면서 핵심 경험을 단단하게 만드는 방식이 인상적입니다.
한계는 언어 범위입니다. 현재는 영어 중심이기 때문에 다국어 팀에는 제한이 큽니다. 또한 스타일 제안과 문맥적 재작성까지 기대한다면, 생성형 AI 기반 도구보다 덜 화려하게 느껴질 수 있습니다.
어떤 팀이나 개발자에게 맞는가
영문 문서를 자주 쓰는 개발자, 프라이버시를 중시하는 조직, 가벼운 에디터 통합을 원하는 도구 제작자에게 잘 맞습니다. 반면 다국어 교정이나 적극적인 문장 재작성을 원한다면 다른 계열 도구가 더 맞을 수 있습니다.
결론
Harper는 문법 검사기의 과잉을 덜어내고 핵심만 남기려는 저장소입니다. 속도와 프라이버시를 중시하는 팀이라면 계속 주목할 가치가 있습니다.