AI 생성 코드베이스에서의 회귀 두려움 — 왜 모든 PR이 도박처럼 느껴지는가
Source: Dev.to
“모든 PR은 도박이다. 우리는 그것이 무엇을 깨뜨릴지 모른다.”
팀이 금요일 — 또는 목요일 — 에 병합을 중단했다면, 여러분은 회귀 공포를 경험하고 있는 것이다. 심리적인 문제가 아니라 구조적인 문제다.
이 게시물은 그 메커니즘, 측정 방법, 그리고 해결책을 설명한다.
메커니즘: 무한 블라스트 반경
잘 구조화된 코드베이스에서는 모듈 A의 변경이 A와 그 직접적인 종속성에만 영향을 미칩니다. 블라스트 반경은 제한적이며 예측 가능합니다.
대부분의 AI‑생성 코드베이스(지난 3개월)에서는 블라스트 반경이 무한합니다:
BLAST RADIUS MAP
Change: update pricing display
PREDICTED impact: ACTUAL impact:
pricing/ui.tsx pricing/ui.tsx
payments/checkout.ts
users/dashboard.tsx
notifications/email.ts
predicted: 1 file actual: 4 files
blast radius: unbounded메커니즘: AI는 최단 경로를 이용해 작동하는 코드를 생성합니다. 그 최단 경로는 종종 암묵적 종속성을 만들게 되는데, 여기에는 공유 상태, 모듈 간 임포트, 예상치 못한 위치에 있는 비즈니스 로직 등이 포함됩니다. 각 암묵적 종속성은 앞으로 발생하는 모든 변경의 블라스트 반경을 확장시킵니다.
탐지: 세 가지 측정
1. 회귀 비율
# Total commits in last 30 days
TOTAL=$(git log --oneline --since="30 days ago" | wc -l)
# Fix/revert commits
FIXES=$(git log --oneline --since="30 days ago" \
--grep="fix\|revert\|hotfix\|broken\|rollback" | wc -l)
echo "Regression ratio: $(( FIXES * 100 / TOTAL ))%"숫자가 의미하는 바
| 비율 | 의미 |
|---|---|
| 0‑10 % | 정상 – 사소한 회귀가 초기에 포착됨 |
| 10‑20 % | 경고 – 결합도가 증가하고 있음 |
| 20 %+ | 치명적 – 5개 중 1개의 커밋이 이전 커밋이 깨뜨린 것을 수정함 |
2. 저주받은 파일
git log --since="90 days ago" --pretty=format: --name-only \
| sort | uniq -c | sort -rn | head -10이 파일들은 가장 많은 커밋에 나타나는 파일들입니다. AI 생성 코드베이스에서는 상위 3개의 파일이 보통 다음과 같습니다:
- 가장 큰 파일들 (500 줄 이상, 여러 도메인)
- 회귀가 발생하는 파일들
- 아무도 건드리고 싶어 하지 않는 파일들
3. 병합 속도 추세
# Commits per week for last 12 weeks
for i in $(seq 0 11); do
START=$(date -d "$((i+1)) weeks ago" +%Y-%m-%d)
END=$(date -d "$i weeks ago" +%Y-%m-%d)
COUNT=$(git log --oneline --since="$START" --until="$END" | wc -l)
echo "Week -$i: $COUNT commits"
done하락 추세는 팀이 병합 빈도가 줄어들고 있음을 의미합니다 — 작업량이 줄어서가 아니라, 각 병합이 더 위험해졌기 때문입니다.
왜 “더 많은 QA”가 해결되지 않는가
QA는 회귀를 발생 후에 잡아냅니다. 회귀를 일으키는 아키텍처적 조건을 방지하지 못합니다.
The regression cycle
- 개발자가 변경사항을 배포한다. 단위 테스트를 통과한다.
- QA가 무관한 영역에서 회귀를 발견한다.
- 개발자가 다시 컨텍스트‑스위치를 하고, 몇 시간 동안 디버깅한다.
- 수정이 새로운 부작용을 도입 → 사이클이 반복된다.
더 많은 QA 인원을 투입하면 사이클이 짧아지는 것이 아니라 빠르게 진행됩니다. 근본 원인은 그대로 남아 있습니다: unbounded blast radius.
비용
시간당 $150 / hour인 세 명의 개발자 팀이 작업했습니다:
- **30 %**의 기능이 회귀를 일으킴 → 2.4 / month
- 6 hours 평균 소요하여 각각을 찾고, 진단하고, 수정
$2,160 / month = $25,920 / year회귀 비용만으로도.
게다가 속도 감소:
| Month | Features / month |
|---|---|
| 3 | 8 (생산적) |
| 6 | 5 (두려움 + 오버헤드) |
| 9 | 3 (회귀 관리가 지배) |
구조적 수정: 제한된 폭발 반경
Step 1 – 저주받은 파일 식별
위의 저주받은 파일 탐지를 실행합니다. 상위 3개의 파일이 분해 대상이 됩니다.
Step 2 – 암시적 의존성 매핑
# Find all files that import from the cursed file
grep -rln "from.*cursedFile\|require.*cursedFile" \
--include="*.ts" --include="*.tsx" src/Step 3 – 도메인별 분해
저주받은 파일을 비즈니스 도메인별로 나눕니다. 각 새 파일은 하나의 책임과 명시적 import만을 가져야 합니다.
Step 4 – 단방향 의존성 강제
# Verify no circular dependencies exist
npx madge --circular --extensions ts,tsx src/분해 후 의존성 그래프는 웹이 아니라 트리 형태여야 합니다.
Step 5 – 경계에 대한 회귀 테스트 추가
// Test that pricing module doesn't depend on notification module
import { getPrice } from '@/modules/pricing';
test('getPrice returns number without side effects', () => {
const result = getPrice({ plan: 'pro', period: 'monthly' });
expect(typeof result).toBe('number');
// No notifications sent, no user state changed
});Step 6 – CI/CD 강제 적용
다음 조건을 만족하지 않으면 병합을 차단합니다:
- 순환 의존성 도입
- 파일 크기 임계값 초과
- 경계 계약에 대한 테스트 커버리지 누락
결과
구조적 강제 적용을 통해 모든 변경의 파급 범위가 제한되고 예측 가능해집니다. QA는 발견에서 검증으로 전환됩니다—제한된 변경이 기대대로 작동하는지를 확인하는 것이며, 관련 없는 파손을 찾아다니는 것이 아닙니다.
회귀에 대한 두려움이 사라집니다. 팀이 더 용감해졌기 때문이 아니라, 아키텍처가 작은 변경이 전체 시스템에 파장을 일으키지 않게 되었기 때문입니다.
모듈 누수가 구조적으로 불가능
이 내용은 AI Chaos 시리즈의 일부이며 — AI 생성 코드베이스에서의 실패 패턴에 대한 구조적 분석입니다. ASA (Atomic Slice Architecture) — AI 생성 소프트웨어를 위한 개방형 아키텍처 표준을 기반으로 합니다.
리소스
- ASA Standard — 오픈 사양
- GitHub — 소스, 예제, 문서
- Vibecodiq — AI 기반 앱을 위한 구조 진단
