'클라우드 기반 AI 코드 리뷰는 안 됩니다.' 보안 담당자의 대답은 단호했다. 분류된 코드베이스, 에어갭 네트워크, 데이터 외부 반출 금지. 한 방산 계약업체 개발팀이 맞닥뜨린 현실이다. 12명이 연간 20만 줄 이상을 작성하는데 리뷰 품질은 무너지고 있었고, AI 코드 리뷰가 정확히 그 문제를 풀어줄 도구였지만 클라우드 옵션은 처음부터 막혀 있었다. dev.to에 공개된 DextraLabs의 온프레미스 배포 가이드는 이 팀이 실제로 시스템을 구축한 과정을 담고 있다. 이 사례가 흥미로운 이유는 단순히 '로컬에 모델을 올렸다'는 기술 스택 선택 때문이 아니다. 클라우드 AI 코드 리뷰의 가장 큰 심리적 장벽—보안과 컴플라이언스—을 정면으로 돌파한 실행 경로를 보여주기 때문이다.
온프레미스 배포의 핵심 판단은 하드웨어에서 시작된다. DextraLabs 가이드는 25인 이하 팀 기준으로 NVIDIA A100 80GB GPU 2장을 장착한 단일 서버에 70B 파라미터 모델을 4-bit 양자화해 운영하는 구성을 권장한다. PR당 리뷰 레이턴시는 30~60초, 하루 15~25건 처리가 가능하다. 서버 초기 비용은 3,000~4,500만 원 수준이지만 3년 상각 시 연간 비용이 클라우드 라이선싱과 비슷해진다는 게 이들의 주장이다. 여기서 내가 주목하는 수치는 레이턴시다. CPU 전용 추론(llama.cpp 기반)을 실험했다가 팀원들이 리뷰를 기다리지 않고 그냥 머지하기 시작했다는 대목이 나온다. 3~5분 대기는 워크플로우를 끊는다. 도구가 느리면 사람들은 우회로를 만든다. 이건 AI 도구 도입 일반에 적용되는 법칙이다.
모델 선택은 목적에 따라 분리하는 것이 실용적이다. 가이드는 코드 특화 리뷰에는 DeepSeek Coder V3(33B), 아키텍처 수준의 '왜 문제인가'를 설명하는 리뷰에는 Llama 3.3 70B를 추천한다. 두 노드를 vLLM으로 운영하되 로드밸런서 뒤에 두어 한 노드가 내려가도 리뷰가 멈추지 않는 구조다. OpenAI 호환 API 엔드포인트를 제공하기 때문에 기존 GitLab CI/CD 파이프라인과 연결이 간단하다는 점도 실용적이다. 에어갭 환경의 진짜 복잡성은 외부 연결이 없다는 것 자체가 아니라, 모델 배포·업데이트·모니터링까지 전체 스택을 자체적으로 책임져야 한다는 데 있다. 클라우드가 대신해주던 운영 부담이 고스란히 팀 안으로 들어온다.
그런데 AI 코드 리뷰 시스템을 갖춘다고 해서 실제 코드 품질이 보장되는 건 아니다. 더 근본적인 질문이 있다. AI가 '통과'라고 말할 때 진짜 통과인가? dev.to에 공개된 개발자 Karthik Rathod의 워크플로우 에세이는 이 질문을 정면으로 다룬다. 그는 AI 에이전트와 함께 일하면서 가장 중요하게 설계한 것이 '마일스톤 게이트'라고 말한다. 규칙은 단순하다. 어떤 마일스톤도 자신이 직접 수동으로 테스트하기 전까지는 완료로 인정하지 않는다. AI가 테스트 통과를 보고해도, 에이전트가 '됐다'고 말해도, 본인이 직접 클릭하기 전까지는 사실이 아니다.
이 원칙의 근거로 그가 인용하는 건 METR의 통제 실험 데이터다. AI 도구를 사용한 숙련 개발자들이 실제로는 19% 느렸지만 자신은 20% 빨라졌다고 느꼈다는 결과다. 속도 감각이 보정되지 않는다는 증거다. 그래서 그는 '게이트에서 잡힌 버그는 사실'이라는 기준을 고수한다. AI 워크플로우에서 수동 검증을 없애는 방향으로 최적화하려는 유혹이 있는데, 이 데이터를 보면 그 유혹을 경계해야 할 이유가 명확해진다. 물론 수동 클릭이 인젝션 취약점을 잡지는 못한다는 한계도 그는 솔직하게 인정한다. 마일스톤 게이트는 행동 오류를 잡는 장치이지 보안 감사 대체제가 아니다.
또 하나의 함정은 모델의 동의 편향이다. Karthik은 에이전트가 자신이 선호하는 방향으로 질문을 프레이밍하면 모델이 거기에 맞춰 동의한다는 것을 반복적으로 경험했다. 그의 대응 전략은 의도적인 반론 요청이다. '이 접근법의 문제점은?', '반대 논거를 만들어봐', 그리고 의도적으로 틀린 반론을 던져서 모델이 쉽게 굴복하는지 테스트한다. AI 코드 리뷰 도구를 팀에 배포할 때도 같은 원칙이 적용된다. 리뷰어 모델이 PR 작성자의 코멘트 패턴에 편향되거나 팀의 기존 코드 스타일을 무비판적으로 강화하는 방향으로 흐를 수 있다. 검증 설계는 도구 선택보다 중요하다.
세 번째 레이어는 AI 시스템 자체를 AI로 수정할 때 발생하는 메모리 무결성 문제다. 코딩 에이전트를 활용해 퍼시스턴트 메모리를 가진 AI 어시스턴트를 개선하는 팀이라면, dev.to에 공개된 Aleksandr Kossarev의 실전 가이드가 중요한 참조점이다. 그는 11개 배포 AI 어시스턴트와 15개 이상의 스펙을 운영하면서 도출한 원칙을 공개했다. 핵심은 코딩 에이전트가 메모리 기반 AI 시스템을 일반 소프트웨어처럼 다룬다는 데 있다. 그렇지 않다. 메모리 테이블의 레코드는 트랜잭션 데이터가 아니라 시스템의 행동적 연속성을 담은 상태다.
그가 제시하는 원칙은 'Do No Harm'이다. 기억이 오래됐거나 관련성이 낮아 보여도 DELETE FROM이 아니라 중요도 스코어를 낮추는 방식으로 처리한다. 오늘 불필요해 보이는 레코드가 몇 달 전 상호작용의 유일한 연결 고리일 수 있기 때문이다. 신규 기능은 메인 메모리 데이터베이스에 테이블을 추가하는 대신 독립된 데이터베이스로 분리하고, 브릿지를 통해 컨텍스트 조립 파이프라인에 연결한다. 신규 기능이 실패해도 메인 메모리는 온전히 유지된다. AI 코드 리뷰 파이프라인에 메모리 기반 컨텍스트를 붙이는 팀이라면 이 격리 원칙은 아키텍처 설계 단계부터 반영해야 한다.
세 가지 흐름이 가리키는 결론은 하나다. AI 코드 리뷰는 도구를 배포하는 순간이 아니라 검증 구조를 설계하는 순간부터 실무에 안착한다. 에어갭 온프레미스 배포는 '클라우드가 안 되는 환경에서도 가능하다'는 실행 경로를 열어주지만, 동시에 전체 스택 운영 책임을 팀이 떠안는다는 뜻이기도 하다. 마일스톤 게이트는 AI 리뷰 결과를 인간이 어느 지점에서 직접 확인해야 하는지 명확히 정의한다. 메모리 무결성 원칙은 AI 시스템을 AI로 수정할 때 숨어있는 리스크를 사전에 통제하는 프레임이다. 팀이 AI 코드 리뷰를 도입하려 한다면 이 세 레이어를 순서대로 설계해야 한다. 도구는 이미 충분히 성숙해 있다. 부족한 건 구조 설계다.