무슨 일이 있었나요
자바 프레임워크 OfficeFloor를 만드는 팀이 ImpactGate라는 오픈소스 도구를 공개했어요. 한 줄로 설명하면 'AI가 코드베이스에 더하는 구조적 부패를 점수로 매겨서 머지를 막는 게이트'예요. 요즘 AI 코딩 도구 덕분에 PR 양이 엄청나게 늘었잖아요. 테스트는 다 초록불이고, 린트도 통과하고, 기능도 잘 동작해요. 그런데 몇 달 지나고 보면 코드베이스가 이상하게 손대기 어려워져 있어요. ImpactGate는 바로 그 '이상하게 어려워지는' 현상을 숫자로 잡아내겠다는 시도예요.
머지 게이트가 뭐냐면
머지 게이트는 PR을 메인 브랜치에 합치기 전에 반드시 통과해야 하는 관문이에요. 여러분이 매일 보는 CI 체크, 그러니까 '테스트 통과', '커버리지 80% 이상', '린트 에러 없음' 같은 것들이 다 머지 게이트예요. 하나라도 빨간불이면 머지 버튼이 비활성화되죠. ImpactGate는 여기에 '구조가 나빠지지 않았는가'라는 체크를 하나 더 추가하는 거예요.
구조적 부패, 이게 뭐냐면
동작은 맞는데 코드의 '모양'이 나빠지는 걸 말해요. 예를 들면 이런 것들이에요. 원래 서로 몰라야 할 모듈이 직접 호출하기 시작해서 결합도가 올라가고, A가 B를 쓰고 B가 다시 A를 쓰는 순환 의존이 생기고, 한 함수가 분기를 계속 끌어안아서 복잡도가 치솟고, 비슷한 유틸 함수가 세 군데에 복사돼요.
집에 비유하면 이래요. 방을 하나 늘릴 때마다 기존 배관을 정리하지 않고 벽을 뚫어서 새 파이프를 연결하는 거예요. 물은 잘 나와요. 그런데 나중에 화장실 하나 고치려고 벽을 열면 파이프 열 개가 엉켜 있어서 어디를 건드려야 할지 모르게 되죠. 그게 구조적 부패예요. 테스트는 '물이 나오는가'만 검사하니까 이걸 못 잡아요.
왜 AI 코드에서 특히 심해질까요
AI 코딩 어시스턴트는 '지금 열려 있는 파일과 주어진 맥락 안에서 가장 빠르게 문제를 해결하는' 방향으로 움직여요. 그러다 보니 프로젝트 어딘가에 이미 있는 헬퍼를 찾아 쓰기보다 그 자리에서 새로 하나 만들어요. 레이어 경계를 지키려면 인터페이스를 거쳐야 하는데, 그냥 아래 계층을 직접 임포트해서 호출하는 게 더 빨리 동작하니까 그렇게 해요. 각각의 선택은 그 순간에는 합리적이에요. 그런데 이게 하루에 PR 수십 개로 쌓이면, 사람이 하나하나 아키텍처 관점에서 리뷰하는 게 물리적으로 불가능해져요. 리뷰어도 결국 '테스트 통과했네, 승인'이 되기 쉽죠.
ImpactGate는 어떻게 접근하나요
핵심 아이디어는 '절대 점수'가 아니라 '변화량'을 본다는 거예요. 기존 코드베이스가 이미 좀 지저분할 수 있잖아요. 그건 일단 인정하고, 이 PR이 들어가면 구조가 얼마나 더 나빠지는지를 측정하는 거죠. 변경 전과 후의 의존성 그래프, 모듈 간 결합도, 복잡도 같은 구조 지표를 뽑아서 그 차이를 점수로 만들고, 정해둔 임계치를 넘으면 게이트가 닫혀요. PR 작성자가 AI든 사람이든 상관없이요. 다만 이름에서 드러나듯, 겨냥하는 건 AI가 대량으로 만들어내는 코드예요.
이 접근이 좋은 이유는 결정적(deterministic)이라는 점이에요. LLM한테 '이 코드 구조 괜찮아?'라고 물어보는 방식은 같은 코드에 대해 오늘과 내일 답이 다를 수 있는데, 그래프와 메트릭 기반 점수는 같은 입력이면 항상 같은 결과가 나오거든요. 게이트로 쓰려면 이게 중요해요.
비슷한 도구들과 비교하면
SonarQube나 CodeClimate 같은 정적 분석 도구에도 '품질 게이트'가 있어요. 다만 이쪽은 코드 스멜, 중복, 커버리지처럼 룰 기반 지표가 중심이고, 파일 단위로 보는 경향이 있어요. ArchUnit, jQAssistant, 자바스크립트 쪽의 dependency-cruiser 같은 도구는 '이 패키지는 저 패키지를 임포트하면 안 된다' 같은 아키텍처 규칙을 테스트로 강제하죠. 이건 규칙을 미리 명시해야 한다는 점에서 다르고요.
ImpactGate가 겨냥하는 빈 자리는 '규칙을 다 적어두지 않아도, 구조가 나빠지는 방향이면 잡아내는 델타 기반 게이트'예요. 그리고 CodeRabbit 같은 AI 코드 리뷰어와도 달라요. 그쪽은 LLM이 의견을 주는 거고, 이쪽은 숫자로 막는 거예요. 둘은 경쟁이라기보다 같이 쓰는 조합에 가까워요.
한국 개발자에게 주는 시사점
팀에서 Cursor나 Claude Code 같은 도구 사용률이 높은데 리뷰가 병목이라면 시도해볼 가치가 있어요. 자바 생태계라면 바로 붙여볼 수 있을 거고요. 다른 언어라도 개념은 그대로 가져올 수 있어요. dependency-cruiser나 madge로 의존성 그래프를 뽑고, 순환 의존 개수나 모듈 간 엣지 수를 PR 전후로 비교해서 늘어나면 실패시키는 간단한 CI 스크립트만으로도 비슷한 효과를 낼 수 있거든요. 핵심은 도구 자체보다 '구조 변화의 델타를 측정한다'는 습관이에요.
한 가지 주의점도 있어요. 리팩토링 PR은 일시적으로 지표가 나빠질 수 있어요. 그래서 게이트를 무조건 막는 용도보다는, 점수를 PR 코멘트로 보여주고 일정 이상이면 시니어 리뷰를 요구하는 식으로 시작하는 게 현실적이에요.
마무리
한 줄로 정리하면, 'AI가 만든 코드가 테스트를 통과하는 것'과 '코드베이스가 건강한 것'은 다른 문제이고, 그 간극을 CI에서 숫자로 잡으려는 도구가 나왔다는 이야기예요. 여러분 팀에서는 AI 코드의 구조 품질을 어떻게 관리하고 계세요? 그리고 구조 점수가 나쁘다는 이유로 잘 동작하는 PR을 막는 게 팀에서 받아들여질까요?
🔗 출처: Hacker News