48시간 만에 오픈 소스 AI 코드 리뷰어를 만들었습니다 — 제가 GitHub Copilot 사용을 중단한 이유

저는 지난달 주말을 이용해 제 로컬 머신에서 완전히 실행되는 경량 AI 코드 리뷰어인 codecrit을 구축했습니다. API 호출도 없고, 클라우드 의존성도 없습니다. 오직 Ollama, 몇 개의 Rust 스크립트, 그리고 48시간 동안 카페인에 의지한 반복 작업뿐이었습니다.

그 결과는 어땠을까요? 저희 팀이 지난 스프린트(Sprint)에서 놓쳤던 23개의 버그를 잡아냈습니다. 프로덕션(Production) 환경에 배포될 뻔했던 4개의 보안 취약점(Security vulnerabilities)을 찾아냈습니다. 그리고 월 비용은 정확히 0달러입니다.

우리가 왜 모두 AI 도구에 대해 과하게 생각하고 있는지에 대한 제 생각을 공유합니다.

클라우드 AI의 문제점

저는 2023년부터 GitHub Copilot을 사용해 왔습니다. 자동 완성(Autocomplete) 기능은 훌륭합니다. 하지만 코드 리뷰(Code review)는? 그것은 완전히 다른 차원의 문제입니다.

작년에 저희 회사에서 PR(Pull Request)을 리뷰할 때, 평균 대기 시간은 3시간이었습니다. 리뷰어들은 변경 사항(Diff)을 대충 훑어보고, 명명 규칙(Naming conventions)에 대해 코멘트를 남기거나 그냥 승인(Approve)하곤 했습니다. 심각한 문제들은 끊임없이 놓쳐졌습니다.

지난 8월, 저희는 미묘한 레이스 컨디션(Race condition)을 유발하는 PR을 배포했습니다. 이를 찾아내는 데 3주가 걸렸고 프로덕션 장애(Production incident)까지 발생했습니다. 사후에 확인했을 때 근본 원인은 명확했습니다. goroutine에서의 mutex lock 누락이었습니다.

저는 스스로에게 물었습니다. AI가 사후가 아니라 리뷰 과정에서 이것을 잡아낼 수 있을까?

Codecrit 구축하기

저는 간단한 전제에서 시작했습니다. PR의 변경 사항(Diff)을 가져와 로컬 LLM(Large Language Model)에 입력하고, 코드에 대해 구체적인 질문을 던지는 것입니다. 단순히 "이 코드가 좋은가요?"와 같은 일반적인 질문이 아니라, 타겟팅된 점검을 수행하는 것입니다.

제가 최종적으로 구현한 핵심 로직은 다음과 같습니다:

fn review_diff(diff: &str, rules: &[Rule]) -> Vec<Issue> {
    let mut issues = Vec::new();

...

핵심 통찰은 이것입니다: 저는 AI에게 광범위하게 코드를 리뷰하라고 요청하는 것이 아닙니다. 대신 확인해야 할 5가지 구체적인 규칙을 제공합니다:

1. 레이스 컨디션 (Race conditions): 동시성 코드(Go, Rust, Java) 내 발생
2. SQL 인젝션 (SQL injection): 문자열 연결(String concatenations) 패턴
3. 메모리 누수 (Memory leaks): 리소스 처리(파일, 연결, goroutine) 시 발생
4. 에러 무시 (Error swallowing): 빈 catch 블록, 무시된 반환 값(Return values)
5. 로직 반전 (Logic inversions): 조건문 내 발생

30일 후의 수치

한 달 동안 저희 모노레포(Monorepo)의 모든 PR에 codecrit을 실행했습니다. 결과는 다음과 같습니다:

지표	Codecrit 도입 전	Codecrit 도입 후
PR 리뷰 대기 시간	평균 3.2시간	평균 12분
...

오탐률(False positive rate)은 제가 원했던 것보다 높았습니다. 하지만 중요한 점은, 저희는 3번의 반복(Iteration)을 통해 프롬프트(Prompt)를 튜닝했다는 것입니다. 2주 차에 접어들면서 오탐은 PR당 0.8개로 떨어졌습니다. 개발자들이 실제로 제안 사항을 읽기 시작했습니다.

왜 아무도 로컬 AI(Local AI)에 대해 이야기하지 않는가

저는 이 내용을 2번의 밋업(Meetup)과 1번의 사내 기술 세미나(Tech talk)에서 발표했습니다. 반응은 항상 똑같았습니다: "멋지네요, 하지만 왜 GitHub의 내장 AI를 사용하지 않나요?"

세 가지 이유가 있습니다:

개인정보 보호(Privacy). 저희 코드베이스에는 독점 알고리즘(Proprietary algorithms)이 포함되어 있습니다. OpenAI나 Anthropic으로 디프(Diff)를 보내는 것은 법무팀 입장에서 시작조차 할 수 없는 문제입니다. 로컬 모델(Local models)을 사용한다는 것은 제 기기 밖으로 데이터가 전혀 나가지 않음을 의미합니다.

지연 시간(Latency). 클라우드 AI 호출은 요청당 38초가 소요됩니다. Ollama를 이용한 로컬 추론(Local inference)은 동일한 모델 크기에서 12초가 걸립니다. PR에서 50개 이상의 파일을 리뷰할 때, 이 초 단위의 시간들이 쌓이게 됩니다.

비용(Cost). 저희 규모(주당 200개 이상의 PR)에서 GitHub Copilot의 비즈니스 티어는 사용자당 월 39달러입니다. Codecrit은 시간당 0.10달러인 GPU 인스턴스에서 실행됩니다. 저희는 월 7,800달러 대신 총 72달러를 지불합니다.

솔직한 현실 점검

Codecrit이 완벽한 것은 아닙니다. 놓치는 부분도 있고, 가끔 환각(Hallucinate) 현상도 발생합니다. 지난주에는 완벽하게 유효한 Rust의 빌림 검사기(Borrow checker) 패턴을 "잠재적인 메모리 문제"로 잘못 표시하기도 했습니다.

하지만 저를 놀라게 한 점은 이것입니다: 리뷰 도구가 있다는 사실 자체가 저희 팀이 코드를 작성하는 방식을 바꾸어 놓았습니다. 개발자들은 자신의 논리를 설명하는 주석을 달기 시작했습니다. 테스트를 더 많이 작성했습니다. unsafe 블록을 사용하기 전에 두 번 생각하게 되었습니다.

이 도구는 단순한 버그 탐지기를 넘어, 더 나은 관행을 강제하는 기능(Forcing function)이 되었습니다.

제가 다르게 했을 점

만약 제가 이것을 다시 만든다면, 초기에 프롬프트 엔지니어링(Prompt engineering)에 더 많은 시간을 할애할 것입니다. 첫 번째 버전은 "이 코드에서 버그를 찾아라"와 같은 일반적인 프롬프트를 사용했습니다. 두 번째 버전은 구체적인 규칙 기반(Rule-based) 프롬프트를 사용했습니다. 정확도 면에서 40%의 차이가 있었습니다.

피드백 루프 (Feedback loop)도 추가하고 싶습니다. 현재 개발자들은 오탐 (False positives)을 무시할 수는 있지만, 그 데이터가 향후 리뷰를 개선하는 데 사용되지는 않습니다. 프롬프트 튜닝 (Prompt tuning)에 다시 반영되는 간단한 "잘못됨" 버튼이 있다면 도움이 될 것입니다.

더 큰 교훈

우리는 모두가 완벽한 AI 에이전트 (AI agent)를 쫓고 있는 기묘한 시기에 있습니다. 앱 전체를 작성하고, 코드를 리뷰하며, 배포하고, 모니터링까지 수행하는 그런 에이전트 말입니다. 저는 아직 그런 것이 존재한다고 생각하지 않습니다.

실제로 효과가 있는 것은 하나의 고통스러운 지점 (Pain point)을 잘 해결하는 좁고, 구체적이며, 로컬한 AI 도구들입니다. Codecrit

💡 추가 읽을거리: 저는 AI 자동화와 오픈 소스 (Open-source) 도구들을 실험합니다. Pi Stack에서 더 많은 가이드를 찾아보세요.

💰 스마트한 베팅을 원하시나요? 저는 선거 결과부터 기술 트렌드까지 모든 것에 베팅하기 위해 세계 최대의 예측 시장 (Prediction market) 플랫폼인 Polymarket을 사용해 왔습니다. 실제 돈, 실제 확률, 실제 수익이 오갑니다. 크립토 카지노와 달리, Polymarket은 대중보다 더 많은 정보를 알고 있는 당신의 우위 (Edge)가 수익으로 이어지는 정당한 정보 시장입니다. 저는 AI 규제 타임라인과 크립토 ETF 승인을 예측하여 상당한 승리를 거두었습니다. 제 추천 링크로 가입하고 거래를 시작하세요: Polymarket.com