Situation
AI 코딩 도구(DevX Code, Amazon Q) 도입으로 팀의 코드 생성 속도가 급증했습니다. 하지만 AI 생성 코드의 품질 저하(Slop) 문제가 발생하여, as any 남용, 아키텍처 경계 위반, 과도한 함수 길이 등이 리뷰에서 반복적으로 발견되었습니다.
Problem
AI가 생성하는 코드에 any 타입과 @ts-ignore 등 타입 우회가 빈번했습니다. Core에서 Product 방향의 import가 감지 없이 허용되어 아키텍처 레이어가 오염되고 있었고, 배럴 인덱스(index.ts)를 우회하는 직접 import로 인해 리팩토링 시 대량 파일 수정이 유발되었습니다. PR 리뷰에서 같은 피드백이 반복되면서 리뷰어 피로가 누적되는 상황이었습니다.
Approach
반복되는 리뷰 피드백을 자동화 가능한 규칙으로 전환하는 방향을 설정했습니다. 사람의 리뷰 부담을 줄이되, 규칙이 개발 속도를 꺾지 않도록 PR 전용 게이트로 한정하는 것이 핵심 원칙이었습니다.
- ESLint (코드 레벨)
- dependency-cruiser (아키텍처 레벨)
- CI 파이프라인 (프로세스 레벨)
AI 코드 품질을 정량 측정하는 SPI(Slop Probability Index) 점수도 도입했습니다.
Implementation
ESLint 규칙 12개 추가
no-explicit-any, ban-ts-comment, func-style, max-lines-per-function, import/order 등.
커스텀 룰 no-deep-import-into-barrel 자체 개발 (103 lines) — AST 탐색으로 배럴 우회 감지.
dependency-cruiser 아키텍처 경계 규칙 7개
Core→Product 금지, 순환 의존 감지, utils/ 정책 등. 규칙 자체가 아키텍처 문서 역할 — 강제와 문서화 동시 해결.
PR 전용 품질 게이트 파이프라인
azure-pipelines-pr.yml — main CI와 분리. 개발 중 DX를 해치지 않으면서 PR 머지 시점에만 품질 검증.
SPI 자동 점수 계산
any 사용, ts-ignore, 긴 함수, 미사용 import 등 가중 합산. 60점 이상 시 CI 실패 — AI 생성 코드 품질 정량 관리.
AI 리뷰 프롬프트 자동 생성
ai-review.sh — diff 기반 맥락 주입. 리뷰어가 수동으로 컨텍스트를 설명할 필요 없이 자동화.
추가로 기존 코드에서 as any 4건을 발굴하여 타입 안전성을 복원했습니다.
Result
| 항목 | 비교 | 값 (건/월) |
|---|---|---|
| Before | 15 건/월 | |
| After | 0 건/월 |
아키텍처 위반 0건
import 즉시 감지로 위반 유지율 0%
AI 코드 품질 가이드라인
SPI 기준 팀 내 공유 및 적용
신규 인력 자동 유도
입사자/외주 개발자도 규칙 준수
리뷰어 피로 해소
타입/스타일 피드백을 CI가 선차단
Learnings
"AI 코드 품질" 문제는 AI를 못 쓰게 하는 것이 아니라, 출력을 걸러내는 시스템으로 해결해야 한다는 점을 확인했습니다. 커스텀 ESLint 룰은 AST 이해만 있으면 반나절이면 작성 가능하여 ROI가 매우 높았습니다.
dependency-cruiser는 아키텍처 문서화와 강제를 동시에 해결해 주었습니다. 규칙 자체가 곧 문서였습니다. CI 게이트는 PR에만 적용해야 개발 중 DX를 해치지 않는다는 점도 중요한 교훈이었습니다.