AI 코딩 도구를 도입한 팀이 가장 먼저 마주치는 감정은 흥분이다. 그리고 얼마 지나지 않아 두 번째 감정이 찾아온다—내가 지금 이 도구를 쓰는 건지, 이 도구가 나를 쓰는 건지 모르겠다는 막막함. 버그 하나 고쳐달라 했더니 다섯 파일이 바뀌어 있고, AI 코드 리뷰어는 있지도 않은 문제를 잡아낸다며 노이즈를 쏟아내고, 맥북은 AI 세션이 죽고 난 뒤에도 조용히 RAM을 갉아먹고 있다. 이 세 가지 불편함은 서로 다른 문제처럼 보이지만, 사실 하나의 뿌리를 공유한다. AI 도구에 제어권을 넘기기 전에 제어 구조를 먼저 설계하지 않았다는 것.
코드 리뷰어를 고를 때 '얼마나 똑똑한가'보다 먼저 볼 것
dev.to에 게재된 CodeRabbit vs Greptile 비교 분석은 단순한 도구 리뷰를 넘어 AI 코드 리뷰의 설계 철학 차이를 잘 드러낸다. CodeRabbit은 PR diff 중심의 외과적 분석 방식을 택한다. 변경된 파일과 그에 직접 연결된 호출자·타입·테스트 파일만 깊게 읽는다. Greptile은 반대 방향으로 간다. 리포지터리 전체를 벡터 인덱스로 만들어놓고, PR이 열릴 때마다 임베딩 검색으로 관련 코드를 찾아낸다.
결과는 냉정하다. 써드파티 벤치마크 기준으로 CodeRabbit의 버그 탐지율은 약 82%, Greptile은 약 44%다. 단순 수치 비교가 아니다. CodeRabbit이 코멘트를 달면 그 중 85%는 즉시 적용 가능한 수정 제안을 포함하고, 오탐률은 15% 수준이다. Greptile은 코멘트의 60%만 액션 가능하고 오탐률은 22%에 달한다. 리뷰 지연 시간도 중앙값 90초 vs 3~5분으로 갈린다.
여기서 주목할 건 숫자 자체보다 왜 이 격차가 발생하는가다. Greptile의 전체 인덱싱 방식은 이론적으로 더 넓은 컨텍스트를 확보한다. 하지만 PR 리뷰라는 맥락에서는 '지금 이 변경이 무엇을 건드리는가'를 정밀하게 파악하는 것이 전체를 희미하게 아는 것보다 훨씬 효과적이다. CodeRabbit의 설계 철학—필요한 것만, 깊게—은 단지 성능 최적화가 아니라 코드 리뷰라는 태스크의 본질에 대한 정확한 이해에서 나온다. 좋은 AI 도구는 '많이 아는 것'이 아니라 '적절한 범위를 정확히 아는 것'으로 신뢰를 쌓는다.
Claude가 혼자 다섯 파일을 고쳐버린 이유
AI 에이전트가 요청 범위를 초과하는 문제는 악의가 아니라 기본값에서 비롯된다. Claude의 기본 모드는 '도움이 되는 것'이고, 도움의 기준이 '철저함'으로 설정되어 있다. 버그를 고치면서 주변 함수를 리팩토링하고, 나중에 필요할 것 같은 유틸리티를 미리 만들어주는 것이 Claude 입장에서는 친절한 행동이다. dev.to에서 공유된 프롬프트 패턴 분석은 이 문제를 해결하는 명확한 방법을 제시한다.
핵심은 Minimal Footprint 원칙이다. 단순히 "X만 바꿔"라고 명시하는 것과는 다르다. 태스크마다 범위를 일일이 지정하는 방식은 인지 부하가 높고, 미처 생각하지 못한 파일 접근을 막지 못한다. 반면 minimal footprint는 원칙으로서 작동한다—범위를 특정하지 않아도 Claude가 스스로 최소 변경 원칙을 적용한다. 그리고 중요한 디테일이 하나 있다. "구현하지 말되, 개선할 점이 보이면 별도 제안으로 남겨라"는 마지막 문장. 이것 없이는 Claude가 '언급도 하지 말라'로 해석할 수 있다. 관찰은 허용하되 실행은 차단하는 것이 핵심이다.
Claude Code를 정기적으로 쓴다면 이 원칙은 CLAUDE.md에 상주 설정으로 박아두는 것이 맞다. 매번 프롬프트에 붙여넣는 방식은 잊어버리는 순간 다시 다섯 파일 diff가 돌아온다. AI 도구의 행동 범위는 대화가 아니라 구조로 제어해야 한다.
세션이 끝난 뒤에도 죽지 않는 것들
세 번째 문제는 눈에 잘 보이지 않아서 더 위험하다. Claude Code나 Codex 같은 AI 코딩 도구는 실행될 때 여러 자식 프로세스를 생성한다. MCP 서버, 병렬 서브에이전트, 헤드리스 브라우저, 빌드 도구 워처. 세션이 정상 종료되면 이것들도 같이 죽는다. 문제는 크래시나 강제 종료다—부모는 사라지지만 자식들은 남는다.
dev.to에 공유된 실제 사례는 충격적이다. 32GB RAM MacBook Pro에서 크롬 프로세스 74개(5.6GB), 죽은 Claude 세션에서 남은 Node 프로세스 18개(5.1GB), TaskMaster AI의 좀비 npm 프로세스 7개. 아무것도 하지 않는 프로세스들이 22GB를 점유하고 있었다. 스왑이 14.5GB까지 불어났고 시스템은 사실상 마비 상태였다.
이 문제의 본질은 프로세스 수명주기 관리가 AI 도구 설계에서 충분히 고려되지 않았다는 점이다. 이에 대한 해결책으로 zclean이라는 CLI 도구가 제안됐다. 핵심 설계 원칙은 단순하다—부모 프로세스가 살아있으면 건드리지 않는다. 터미널 탭에서 돌리고 있는 vite dev나 tmux로 관리 중인 Node 서버는 절대 손대지 않는다. 오직 부모가 죽은 AI 도구 관련 프로세스만 정리한다. 이 안전 모델이 없으면 도구 자체가 또 다른 리스크가 된다.
제어 구조가 먼저다
세 가지 이슈를 나란히 놓고 보면 하나의 패턴이 선명해진다. AI 도구가 코드를 리뷰하든, 코드를 작성하든, 백그라운드에서 프로세스를 실행하든—기본값은 항상 더 많이, 더 넓게, 더 오래 작동하는 방향으로 설정되어 있다. 이것은 버그가 아니다. AI가 '도움이 되려는' 방향으로 설계된 필연적 결과다.
그래서 AI 워크플로우 설계의 핵심은 도구를 고르는 것이 아니라 제어 경계를 먼저 정의하는 것이다. 코드 리뷰어라면—변경 범위에 정밀하게 집중하는가, 아니면 전체 컨텍스트를 넓게 보는가, 그리고 그 선택이 내 팀의 리뷰 속도와 노이즈 허용 범위와 맞는가. AI 에이전트라면—원칙 수준의 제약을 어디에 상주 설정으로 박아둘 것인가. 개발 환경이라면—세션 종료 후 정리되지 않는 프로세스를 누가 어떻게 관리할 것인가.
AI가 코드를 쓰는 속도는 이제 인간이 따라잡기 어렵다. 하지만 AI가 만든 결과물을 신뢰할 수 있는 구조로 운영하는 것은 여전히 인간의 설계 영역이다. 빠르게 쓰는 것보다 제어 가능하게 운영하는 것이 장기적으로 더 빠른 팀을 만든다. 제어 구조 없는 자동화는 속도가 아니라 부채다.