AI한테 린트 규칙 하나만 손봐달라고 했어요.
근데 코드를 열어보니, 요청한 적 없는 정교한 필터링 시스템이 통째로 들어와 있었죠. 넓은 범위로 잡아내던 걸 AI 마음대로 좁혀놓은 거예요.
테스트도 통과했고, 코드 리뷰도 통과했어요. 근데 이게 우리가 원하던 제품이 맞나요?
다들 버그만 잡으면 끝인 줄 알죠
AI 코드 리뷰 도구 시장은 이미 붐빕니다. CodeRabbit, Greptile, Qodo, Cursor BugBot까지 — 다들 하는 일은 비슷해요. PR의 diff를 훑어서 버그, 보안 취약점, 코드 스타일 문제를 잡아내는 거죠.
실제로 이 도구들끼리 성능 경쟁도 치열해요. 50개 오픈소스 PR을 대상으로 한 벤치마크에서 Greptile은 실제 버그의 82%를 캐치했고, CodeRabbit보다 버그를 50% 더 많이 찾아냈어요. 대신 오탐(false positive)도 더 많았고요(11건 vs 2건).
| 도구 | 초점 | 가격 |
|---|---|---|
| Greptile | 전체 코드베이스 인덱싱, 파일 간 버그 | $30/사용자/월 (50건 이후 과금) |
| CodeRabbit | diff 요약, 빠른 설정 | $24~48/사용자/월 |
| Qodo | Jira 티켓 규정 준수 검증 | 무료~$30/사용자/월 |
다 좋은 도구예요. 근데 이 도구들이 공통적으로 보는 건 "이 코드가 기술적으로 맞는가"예요. 버그가 없고, 스타일 가이드를 지켰고, 테스트를 통과했으면 합격이죠.
근데 버그 없는 코드가 더 위험할 수도 있어요
Prelint를 만든 팀의 문제의식은 여기서 시작돼요. Prelint 창업 계기 자체가 한 코드 변경 사건이었어요 — AI 에이전트가 팀의 이벤트 기반 아키텍처를 완전히 무시하고, 그걸 우회해서 기능을 구현해버린 거예요. 코드는 돌아갔어요. 근데 그건 팀이 원하던 방식이 아니었죠.
이 현상을 product drift라고 불러요. 기술 리뷰도 통과하고 CI도 통과하는데, 트랜잭셔널 아웃박스 패턴을 건너뛰거나, 승인 안 된 의존성을 넣거나, 권한 규칙을 바꾸거나, 존재하지 않는 비즈니스 요구사항을 지어내는 식이에요.
Stack Overflow 블로그는 이걸 "블랙박스 AI 드리프트"라고 표현해요. "프롬프트가 들어가고 결과물이 나오는데, 그 사이에 내려진 결정은 안 보인다"는 거죠. 위에서 말한 린트 규칙 사례가 바로 이 블로그에서 나온 거고요.
숫자로도 확인돼요. GitClear가 2023~2026년 코드베이스를 분석했더니, 블록 중복이 81% 증가(40.3 → 73.0)했고, 복사-붙여넣기 코드 비중이 9.4%에서 15.7%로 늘었어요. 반면 코드를 옮기며 정리하는 리팩토링 비중은 21%에서 3.8%로 급락했고요. AI가 코드를 빨리 짜는 대신, 그만큼 정리는 안 되고 있다는 뜻이에요.
주의
AI 에이전트는 하루 오후에 50개 파일을 만들어낼 수 있어요. 개별 파일은 다 맞아 보이는데, 합쳐놓으면 아키텍처 결정의 절반을 위반하는 경우가 있어요. 파일 단위 리뷰로는 이걸 못 잡아요.
그래서 나온 게 "결정 원장"이에요
Prelint의 포지셔닝은 명확해요. "코드 리뷰어가 아니라 decision ledger". 저장소에 있는 ADR(아키텍처 결정 기록), 문서, 과거 결정들을 모아서 하나의 "결정 원장"을 구성하고, 모든 PR을 여기에 대조해요.
작동 방식은 3단계예요. (1) 저장소에 마크다운/YAML로 제품 사양을 저장 (2) AI 에이전트가 평소처럼 PR을 생성 (3) Prelint가 수초 안에 사양 위반을 플래그하고 수정안을 제안해요.
실제로 331개 오픈소스 저장소의 PR 56,706건을 분석한 자체 리서치에서 흥미로운 결과가 나왔어요. 같은 PR을 문서 있이/없이 두 번씩 리뷰했더니, 문서가 있을 때 플래그율이 36.6%, 없을 때 13.3%였어요. Prelint 팀의 표현을 빌리면 "문서가 버그를 더 많이 찾아주는 게 아니라, 다른 버그를 찾아주는 것"이었죠.
| 기존 AI 코드 리뷰 | decision ledger 방식 | |
|---|---|---|
| 기준 | 버그·스타일·보안 | ADR·제품 사양·과거 결정 |
| 통과 조건 | 기술적으로 맞으면 OK | 제품 의도와 일치해야 OK |
| 검토 단위 | diff 하나씩 | 저장소 전체 결정 이력과 대조 |
| 병행 효과 | - | 타 리뷰어가 놓친 이슈 중 약 40% 추가 캐치 |
이건 다른 도구를 대체하는 게 아니라 레이어 하나를 추가하는 것에 가까워요. Greptile이나 CodeRabbit이 "이 코드가 안전한가"를 본다면, Prelint는 "이 코드가 우리가 결정한 제품이 맞는가"를 보는 거죠.
바로 적용하는 법
- 핵심 결정부터 문서화하기
모든 걸 ADR로 쓸 필요 없어요. 최근 3개월간 논쟁했던 아키텍처·권한·데이터 흐름 결정 5~10개만 마크다운으로 정리하세요. - 저장소에 연결하기
GitHub/GitLab 앱으로 붙이면 기존 PR 워크플로에 자동으로 활성화돼요. - 기존 리뷰어와 병행 실행
CodeRabbit·Greptile은 그대로 두고 Prelint를 추가하세요. 서로 다른 걸 보기 때문에 겹치지 않아요. - 첫 위반 케이스 확인하기
Prelint가 처음 플래그한 PR을 보면서, 팀의 결정 원장이 실제로 얼마나 정확한지 감을 잡으세요. - 결정 원장을 살아있는 문서로 관리
분기마다 오래된 결정을 검토하고, 더 이상 유효하지 않은 규칙은 걷어내세요. 원장이 낡으면 오탐만 늘어나요.
"코드 리뷰"에서 "의도 리뷰"로
국내 개발 블로그 Flowkater는 AI 시대 코드 리뷰의 방향을 이렇게 정리해요. "diff가 아니라 스펙을 검토하고, 수용 기준을 사전에 정의해야 한다"는 거예요. Prelint의 decision ledger는 이 아이디어를 제품 삼아 구현한 사례에 가까워요.
