2016년 Sandi Metz가 쓴 글 “The Wrong Abstraction“이 2026년 6월 21일 Hacker News 상단에 다시 올라왔습니다. 10년이 지난 글이 재조명된 배경은 단순합니다. AI 코드 보조 도구가 추상화를 더 빠르게 만드는 시대일수록, 잘못된 추상화의 누적 비용이 빠르게 드러나기 때문입니다.
본 글은 Metz 원문의 논지를 한국 개발 현장 맥락에서 재해석합니다. 대상 독자는 코드 리뷰와 리팩토링 판단을 일상적으로 내리는 미드~시니어 개발자입니다. 분석 기준 시점은 2026년 6월 22일이며, 원문 외 별도 도구 버전 의존성은 없습니다.
1. Sandi Metz의 결론을 한 줄로
Metz의 핵심 주장은 명확합니다. “duplication is far cheaper than the wrong abstraction” — 중복은 잘못된 추상화보다 훨씬 저렴하다는 뜻입니다. 더 정확히 풀어 쓰면, DRY 원칙을 기계적으로 따르다 만들어진 어설픈 공통 함수가, 같은 코드를 두세 군데 복사해 둔 상태보다 결합도와 변경 비용을 더 키운다는 의미입니다.
Prefer duplication over the wrong abstraction.
Sandi Metz, 2016
2. 추상화가 만들어지는 전형적 경로
Metz가 묘사한 시나리오는 어디서나 본 풍경입니다. 개발자 A가 비슷해 보이는 코드 두 곳을 보고 “공통 함수로 묶으면 깔끔하겠다”는 직관으로 함수를 추출합니다. 시간이 흐르면서 호출처가 늘어납니다. 이때부터 진짜 문제가 시작됩니다.
- 새 호출자의 요구가 기존 추상화와 약간만 다릅니다.
- 매개변수를 하나 추가하거나, 분기 로직을 함수 내부에 끼워 넣습니다.
- 다음 호출자도 같은 식으로 변형을 더합니다.
- 6개월 후 함수는 매개변수 다섯 개와 if-else 가지 일곱 개를 가진 괴물이 됩니다.
이 시점의 함수는 더 이상 공통점을 표현하지 않습니다. 호출자들의 차이점을 한 함수 안에 욱여넣은 결합도 폭탄에 가깝습니다.
3. 잘못된 추상화의 비용은 어디서 발생하는가
중복 코드는 시각적으로 “냄새”가 분명합니다. 정적 분석 도구도 잡아냅니다. 반면 잘못된 추상화는 한동안 정상 코드처럼 보입니다. 문제는 사용처가 늘어날수록 드러납니다.
3-1. 변경의 파급 효과
한 호출자의 요구에 맞춰 추상화를 수정하면, 의도하지 않은 다른 호출자가 함께 영향을 받습니다. 회귀 테스트가 빈약하면 사이드 이펙트가 늦게 발견되고, 운영 환경에서 야간 호출로 이어지는 사례가 적지 않습니다.
3-2. 신규 합류자의 학습 비용
매개변수 일곱 개에 분기 다섯 개인 함수를 처음 만난 주니어는 “이 함수가 무엇을 위해 존재하는지”부터 추론해야 합니다. 코드 리뷰 PR마다 같은 질문이 반복되고, 추상화는 점점 더 두꺼워집니다.
3-3. AI 코드 보조 도구의 가속 효과
2026년 현재 GitHub Copilot이나 Claude Code 같은 AI 보조 도구는 “유사 코드를 함수로 추출하라”는 제안을 빠르게 던집니다. 직관적 DRY 제안이 늘어날수록, 사람이 “이 추출은 정말 같은 개념을 표현하는가”를 판단하는 시간이 줄어듭니다. Metz의 글이 다시 회자되는 이유가 여기에 있다고 봅니다.
4. 실무 판단: 언제 분해(Inline)하고 언제 유지할 것인가
Metz가 제시한 처방은 “분해 후 재추상화”입니다. 잘못된 추상화를 만났을 때 그 위에 또 다른 추상화를 얹지 말고, 코드를 호출처로 되돌린 뒤(IDE의 Inline Function 리팩토링) 다시 패턴을 찾으라는 의미입니다.
판단 기준으로 다음 신호들을 활용할 수 있습니다.
- 매개변수 네 개 이상, boolean 플래그 두 개 이상 → 분해 후보
- 호출처마다 다른 매개변수 조합을 쓰고 있음 → 분해 후보
- 함수 내부에서 호출자 정체성을 검사하는 분기(
if (caller === 'A'))가 보임 → 강한 분해 신호 - 최근 6개월간 같은 함수에 세 차례 이상 매개변수 추가 PR이 들어옴 → 즉시 검토 대상
분해 절차 자체는 단순합니다. IDE의 Inline Function 리팩토링으로 각 호출처에 코드를 되돌리고, 정말 같은 개념을 공유하는 코드만 다시 묶습니다. 처음 한두 번은 중복이 늘어나는 것처럼 보이지만, 6개월 뒤 변경 속도가 회복됩니다. Martin Fowler의 Inline Function 리팩토링 카탈로그가 단계 설명을 제공합니다.
5. 한국 코드베이스에서 자주 보이는 함정
국내 코드 리뷰 문화에서는 “DRY 위반”이라는 코멘트가 비교적 가볍게 달립니다. 반면 “이 추상화는 너무 일찍 만들어졌다”는 지적은 드뭅니다. 그 결과 다음 두 패턴이 자주 관찰됩니다.
5-1. Util / Common 클래스의 누적
StringUtil, DateUtil, CommonService 같은 클래스에 시간이 갈수록 메서드가 누적됩니다. 메서드 사이에 의미적 공통점은 없고, 단지 “어딘가에 두기 애매한 함수”가 모여 있을 뿐입니다. Metz의 기준으로 보면 이런 클래스는 추상화가 아니라 디렉터리에 가깝습니다.
5-2. 도메인 모델을 가장한 ORM 매핑 계층
JPA Entity나 Mongoose Schema에 비즈니스 메서드가 누적되면서, 한 클래스가 다섯 개 이상의 유스케이스를 책임지는 경우가 흔합니다. “공통 도메인”으로 묶인 듯 보이지만, 실제로는 호출자별로 다른 로직이 같은 메서드 안에서 분기합니다. SRP(Single Responsibility Principle) 위반 사례로도 자주 인용되지만, Metz 관점에서는 “잘못된 추상화”의 전형입니다.
두 패턴 모두 분해 후 호출자별 클래스를 분리하는 편이 결과적으로 변경 비용이 낮습니다. 한 번에 정리하지 말고, 새 요구사항이 들어올 때마다 해당 호출자만 떼어내는 점진적 접근을 권장합니다.
6. 정리: 시니어가 챙길 체크리스트
Metz의 글은 짧지만, 시니어 개발자가 코드 리뷰에서 매일 사용할 수 있는 휴리스틱을 제공합니다. 다음 체크리스트로 압축할 수 있습니다.
- “DRY 위반” 코멘트를 달기 전에, “이 두 코드가 같은 개념을 표현하는가”를 먼저 묻기
- 추출 함수의 매개변수가 네 개 이상이면 추상화 자체를 재검토
- 호출자 정체성으로 분기하는 if 문이 보이면 분해 후보로 등록
- 중복은 가시적 비용, 잘못된 추상화는 잠복 비용임을 PR 설명에 명시
- AI 보조 도구의 “함수로 추출” 제안은 자동 승인하지 않고, 개념의 동일성부터 확인
10년 된 글이 다시 회자되는 시점은, 그 안의 원칙이 새 환경에서 재해석될 만큼 본질에 닿아 있다는 신호이기도 합니다. AI 보조 도구가 추상화를 더 빠르게 만드는 2026년 현재, 우리가 챙겨야 할 균형추는 여전히 Metz의 문장 한 줄로 충분합니다.
관련 글
코드베이스 관리와 도구 활용 측면에서 함께 읽을 만한 글을 정리했습니다.
- Git 파일 무시 방법 4가지 — .gitignore부터 skip-worktree까지 — 코드베이스 정리의 기본기로, 잘못된 추상화 분해 작업 중 임시 파일 관리에도 유용합니다.
- Gemini CLI 종료 D-1: Antigravity CLI 전환 체크리스트 — AI 보조 도구 환경이 빠르게 바뀌는 시점이므로, 추상화 의사결정도 도구 의존성 관점에서 점검할 필요가 있습니다.
- Kage로 웹사이트를 13MiB 단일 바이너리로 박제하기 — 오프라인 아카이브 가이드 — Metz의 원문처럼 오래 보존할 가치가 있는 글을 로컬에 보관해 두는 한 가지 방법입니다.
📌 함께 보시면 좋은 글
※ 본 글은 AI(Claude)의 초안을 기반으로 편집자 검수를 거쳐 발행되었습니다. (한국 AI기본법 대응 고지)
이직·퇴사, 지금 움직여도 될지 헷갈리시나요?
막연히 불안한 건지, 정말 시점이 온 건지 판단이 어려울 때가 있습니다.
5분 체크리스트로 지금 상태를 먼저 정리해보세요.
결론을 대신 내리기보다, 스스로 판단할 기준을 잡는 데 도움을 드립니다.
아직 확신이 없다면, 지금이 ‘고민 단계’인지부터 먼저 점검해보세요