코드 소모품론의 조건 — 교체 가능한 경계가 핵심이다

출발점

DIO(스페이스 Y)의 김지훈은 하네스 엔지니어링의 맥락에서 이렇게 말했다:

"버그가 있으면 리팩토링 대신 파일을 지우고 새로 생성하라"

이 주장은 하네스가 충분히 좋으면 — 린터, 네이밍 규칙, 아키텍처 설계가 모델의 선택지를 하나로 좁히면 — 코드를 지워도 같은 결과가 나온다는 논리다. 매력적이지만, 적용 범위를 한정하지 않으면 위험한 주장이다.

반박: 중소형 이상에서는 성립하지 않는다

DIO의 시나리오는 다음 전제를 가진다:

신규 프로젝트 (zero-to-one POC)

프론트엔드 UI 컴포넌트 수준의 단위

역할과 인터페이스가 명확히 정의된 파일

디자인 시스템 + 린터가 출력을 완전히 제약하는 환경

중소형 이상의 코드에서 "지우고 재생성"은 더 큰 사이드 이펙트를 낳는다:

수년간 쌓인 edge case 처리가 사라진다

테스트에 잡히지 않는 암묵적 행동(implicit behavior)이 달라진다

다른 모듈이 삭제된 코드의 부수 효과에 의존하고 있을 수 있다

재생성된 코드가 같은 인터페이스를 지켜도 내부 동작이 미묘하게 달라진다

APoSD Ch.8 "Pull Complexity Downwards"의 관점: 코드를 지우는 것은 그 코드가 아래로 끌어내린 복잡성까지 함께 버리는 것이다.

대안 검토: MSA로 해결 가능한가?

MSA(Microservices Architecture)에서 각 서비스는 본질적으로 소형 프로젝트다. API 계약이 린터 역할을 하고, bounded context가 독립성을 보장한다. 이론상 서비스 단위로 "지우고 재생성"이 가능하다.

그러나 MSA는 코드 복잡도를 인프라 복잡도로 이전할 뿐이다:

서비스 간 통신, 분산 데이터, 서비스별 CI/CD, 분산 추적

"코드를 소모품화"하는 이점 하나를 위해 치르는 비용이 과다

AI가 이 복잡도를 커버할 수 있다는 기대도 있지만, AI가 잘하는 것(결정된 것을 구현)과 못하는 것(서비스 경계 설계, 분산 시스템 장애 시나리오 예측)은 다르다.

결론: 교체 가능한 경계(Replaceable Boundary)

코드 소모품화의 열쇠는 MSA가 아니라 "교체 가능한 경계"의 존재다. 그 경계를 만드는 방법은 여러 가지이며, MSA는 가장 비싼 방법일 뿐이다.

Modulith와 Vertical Slicing이 현실적 최적해다. 단일 배포 단위이면서도 모듈/기능 간 경계가 명확하여, 해당 단위를 "지우고 재생성"해도 다른 부분에 영향이 없다. MSA의 인프라 비용 없이 코드 소모품화의 이점을 얻는다.

적용 범위 정리

1. 소형, 파일 단위           → 항상 가능 (DIO 원래 맥락)
2. 중소형+ 모놀리스 (무구조)   → 위험 ❌
3. 중소형+ MSA               → 가능하지만 비용 과다 ⚠️
4. 중소형+ Modulith/VS       → 현실적 최적해 ✅