Bumgeun Song’s Post
나는 Lint가 가장 저평가된 AI harness라고 생각한다.
지난번에 ‘자유도를 좁혀야 AI의 코드 퀄리티가 올라간다’는 말을 했다. 그걸 하는 가장 좋은 방법이 Lint다.
사실 나도 오랫동안 Lint를 별로 중요하게 생각하지 않았다.
미적인 부분을 정리해주는 수준이면 임팩트가 크지 않았고. 더 강한 규칙을 적용하자니, 오탐 확률이 높았다.
예를 들어 ‘useEffect 금지’라는 lint를 생각해보자. useEffect 남용에 동의하는 프론트엔드 개발자라도, 이 규칙 도입은 쉽지 않다.
구독, 서드파티 SDK 초기화, 포커스 관리, 타이머 정리. useEffect를 써도 크게 문제가 없는 케이스가 있다. 결정적인 rule은 문제없는 코드에도 오탐을 만들어낸다.
그래서 처음엔 컨벤션/스타일 가이드를 Skill로만 저장해뒀다. “이렇게 해줘”라고 알려주면 되는 거니까.
근데 Skill은 근본적으로 확률적이다.
AI가 계속 그 규칙에서 벗어나는 상황이 발생했다. 하나하나 수정하다 보니 비효율이다. 결정적인 방법으로 막아야겠다 생각이 들었다. lint를 직접 만들어 도입하기 시작했다.
생각보다 Lint로 막을 수 있는 게 굉장히 많아서 놀랐다. 처음엔 안 쓰는 변수 경고 이런 거 정도만 가능하겠지 싶었는데. 파일명, 의존성, handler 안에 들어가면 안 되는 코드.. 다 잡을 수 있다. 의도만 말하면 AI가 Lint 작성 되게 잘한다.
또 중요한 건 Lint를 자주 돌리게 해야한다. hook을 사용해서 Agent가 커밋하기 전에 Lint가 반드시 돌아가게 해둔다. Agent가 스스로 고치고 넘어간다. 피드백 루프가 쫀쫀해진다.
Lint 규칙은 남이 만든 걸 무조건 가져다 쓰기보다, 내 실수에서 뽑아내는 게 제일 좋다. 나는 AI 세션이 끝날 때마다 무엇을 놓쳤는지 회고를 돌린다. 나온 실수들을 기록해둔다. 주기적으로 Lint 규칙으로 만들 수 있는 게 있는지 찾는다.
이미 있던 코드베이스라면, 기존 코드 정리도 해줘야 한다. 분명 ‘아 고치기 애매한데’ 싶은 코드들이 있다. 이해한다. 하지만 어차피 AI가 코딩해주는 시대에, 자유도를 줄이기 위해선 할만한 투자다.
지금 내가 관리하는 코드베이스엔 커스텀 lint 규칙이 40개가 넘는다. Lint를 가꿔나갈수록 내가 생각하는 ‘좋은 코드’가 나오니까 열심히 하게 된다.
얼마 전 lint 규칙이 없는 코드베이스에서 작업할 일이 있었는데, AI가 자기 마음대로 막춤을 췄다.
덕분에 현업 개발자라면, Lint가 정말 중요한 harness라는 확신이 생겼다.
주변을 보면 Skill은 다들 100개씩 있는데, Lint는 거의 신경 안 쓴다. 나도 그랬다.
기본 harness 갖췄다면, 다음은 Lint다.