Show GN: LLM 기반의 코드 컨벤션 린터를 만들었습니다.
(github.com/DevSymphony)안녕하세요! 저희는 sym-cli를 개발하고 있는 대학생 팀 심포니입니다.
요즘 Cursor나 Claude Code 같은 도구를 써서 바이브 코딩을 많이 하시나요? 저희 팀도 개발 과정에서 LLM을 적극적으로 활용하고 있습니다. 그런데 쓰다 보니 한 가지 아쉬운 점이 있었습니다.
AI가 짜준 코드는 기능적으로는 잘 돌아가지만, 우리 팀만의 컨벤션(변수 명명법, 주석 스타일, 특정 라이브러리 사용 규칙 등)은 자꾸 무시한다는 것이었습니다. 매번 프롬프트에 규칙을 적어주자니 번거롭고 또 쓰다보면 점점 컨벤션을 까먹어가는 문제도 있었습니다.
그래서 "LLM이 코드를 짜기 전에, 혹은 짜는 도중에 스스로 컨벤션을 확인하게 할 수는 없을까?"라는 고민에서 sym-cli를 만들기 시작했습니다.
[sym-cli는 무엇인가요?]
sym-cli는 AI 코딩 도구를 위한 정책 기반 코드 컨벤션 린터입니다. 핵심은 MCP를 활용하여 LLM과 직접 소통한다는 점입니다.
기존 린터와 다른 점은 다음과 같습니다.
- (자연어 기반 설정) 복잡한 설정 파일 대신, "절대로 log를 print로 작성하지마"처럼 자연어로 규칙을 정의하면 LLM이 이를 이해하고 따릅니다.
- (Context 최적화)LLM이 프로젝트의 모든 규칙을 다 읽는 게 아니라, MCP 도구를 통해 현재 작업에 필요한 규칙만 똑똑하게 가져갑니다.
- (능동적 검사) validate_code 도구를 통해 LLM이 코드를 생성한 직후 스스로 규칙 준수 여부를 검사할 수 있습니다.
[어떻게 작동하나요?]
sym 명령어를 다운로드 후 sym init 명령을 실행하면 MCP 서버 설정이 자동으로 구성되어, MCP를 지원하는 IDE(Cursor 등)나 LLM 도구에서 바로 이 규칙들을 참조하기 시작합니다.
[피드백을 부탁드립니다!]
저희는 아직 대학생 팀이고, 프로젝트도 이제 막 뼈대를 갖춘 초기 단계입니다. 부족한 점이 많고 버그가 있을 수도 있습니다. 하지만 현업 개발자분들이나 LLM 도구에 관심 많은 분들의 응원과 피드백이 절실합니다.
"이런 기능이 있으면 좋겠다", "이 부분은 구조적으로 문제가 있어 보인다", "실제 현업에서는 이렇게 쓴다" 등 어떤 의견이든 감사하게 듣겠습니다. 오픈소스이므로 기여나 GitHub Star는 저희 팀에게 정말 큰 힘이 됩니다!
GitHub Repository: https://github.com/DevSymphony/sym-cli
npm: npm install -g @dev-symphony/sym
읽어주셔서 감사합니다.
opencode를 쓰시면 lint 기능까지 워크플로우에 포함시킬 수 있어요
https://news.hada.io/topic?id=21883
https://opencode.ai/docs/formatters/
공감합니다. 구문·타입 오류처럼 즉시 잡을 수 있는 건 LSP나 컴파일 단계가 가장 효율적이고, 토큰 사용량 면에서도 맞는 접근이라고 생각합니다. 저희도 LLM이 이를 대체하기보다는, 자연어로 작성된 규칙을 기존 lint/test 워크플로우에 자동으로 연결해주는 역할에 가깝게 보고 있습니다.
저도 t7vonn님처럼 컨벤션은 자동화 도구로 맞추는 게 맞다고 생각하는데요
LSP 기능은 꽤 차이가 느껴집니다 test나 컴파일 돌려봐야 잡히는 구문 오류들을 바로 잡아낼 수 있으니까 토큰 사용량이 줄더라고요
PR review agent에 컨벤션 문서랑 diff 쥐어주고 빠진 부분 찾는 정도는 지금도 이미 하고 있고.. 그 이상 쓰진 않을 것 같습니다
저랑 비슷한 의견을 가진 사람의 글을 첨부드립니다
Claude는 린터가 아님
- 코드 스타일 가이드라인을 CLAUDE.md에 포함하는 것은 비효율적임
- LLM은 비용이 높고 느리며, 린터보다 비결정적임
- 스타일 규칙은 기존 코드 패턴을 통해 자연스럽게 학습되므로 별도 지시 불필요
- 포맷팅은 자동 수정 가능한 린터(Biome 등) 를 활용하고, Claude에는 수정 결과만 전달
- 필요 시 Stop Hook이나 Slash Command를 사용해 포맷팅·검증을 자동화
말씀하신 사용 방식이 현재로선 가장 현실적인 접근이라고 생각합니다. 저희가 풀고 싶은 문제는 컨벤션 문서를 PR마다 쥐어주는 과정을 줄이고, 자연어로 정의된 규칙을 미리 린터·검증 규칙으로 변환해 PR/CI 단계에서 자동으로 돌게 만드는 쪽입니다.