AI 요약
소프트웨어 개발 프로세스에서 중복 코드를 제거하는 것은 오랫동안 모범 사례로 여겨졌으나, 저자인 샌디 메츠(Sandi Metz)는 오히려 이 원칙이 독이 될 수 있음을 지적합니다. 그녀는 2014년 RailsConf 발표와 2016년 공식 블로그를 통해 "잘못된 추상화를 적용하느니 차라리 코드 중복이 훨씬 낫고 비용도 저렴하다"는 도발적인 메시지를 던졌습니다. 많은 개발자들이 중복을 발견하면 성급하게 새로운 메서드나 클래스로 추상화하지만, 새로운 요구사항이 추가될 때마다 이를 억지로 끼워 맞추기 위해 조건문과 매개변수를 덧붙이는 악순환에 빠지게 됩니다. 결국 코드는 가독성을 잃고 난해해지며, 개발자들은 공들여 만든 코드를 버리지 못하는 '매몰 비용 오류'에 갇혀 시스템을 더욱 망가뜨리게 됩니다. 이 글은 무조건적인 중복 제거보다 시스템의 진정한 도메인 아키텍처를 파악할 때까지 추상화를 늦추는 것이 장기적인 유지보수 관점에서 훨씬 현명함을 일깨워줍니다.
핵심 인사이트
- 2014년 RailsConf & 2016년 공식화: 소프트웨어 설계 분야의 권위자인 샌디 메츠(Sandi Metz)가 2014년 RailsConf 발표('all the little things')에서 처음 화두를 던진 후, 2016년 1월 20일 블로그 포스트를 통해 널리 확산시킨 소프트웨어 공학의 명언이다.
- "잘못된 추상화보다 중복이 싸다": 섣부른 DRY(Don't Repeat Yourself) 원칙 적용이 시스템 전체에 미치는 해악이 단순히 코드가 중복되는 문제보다 훨씬 크다는 점을 정량적·정성적 비용 관점에서 입증했다.
- 매몰 비용 오류(Sunk Cost Fallacy)의 작용: 코드가 복잡하고 난해할수록 개발자는 그 코드를 작성하기 위해 투입된 '노력의 가치'를 보존해야 한다는 무의식적인 압박을 느끼며, 이로 인해 잘못된 추상화를 폐기하지 못하고 억지로 유지하려 한다.
주요 디테일
- 잘못된 추상화의 악순환 패턴:
- 개발자 A가 중복을 발견하고 이를 분리해 새로운 추상화(메서드/클래스)를 만든다.
- 개발자 B가 미세하게 다른 새 요구사항을 맞추기 위해 기존 추상화에 매개변수를 추가하고 조건문 분기 처리를 한다.
- 개발자 X가 또 다른 요구사항을 반영하며 추가 조건문을 더해 코드가 완전히 이해 불가능한 상태가 된다.
- 업계의 폭발적인 반응: 샌디 메츠의 발표 이후 트위터 등 개발자 커뮤니티에서는 "이 주장에 백만 번 동의한다"며 격한 공감과 지지의 멘션이 쏟아졌고, 이는 전 세계 개발 팀들의 코드 리뷰 문화에 지대한 영향을 미쳤다.
- 비즈니스 생산성 저하: 조건문이 난무하는 잘못된 추상화 코드는 소프트웨어의 유연성을 극도로 떨어뜨려 향후 기능 추가 속도를 늦추고 버그 발생률을 비약적으로 증가시키는 비즈니스 리스크를 초래한다.
- 해결을 위한 개발자 행동 지침: 기존의 잘못된 추상화가 더 이상 하나의 명확한 역할을 수행하지 못할 때는, 무리해서 코드를 수정하기보다 추상화를 과감히 해체하여 원래의 '중복 코드 상태'로 되돌려놓고 도메인을 다시 분석하는 것이 훨씬 경제적이다.
향후 전망
- WET(Write Everything Twice) 관점의 부상: 무조건적인 DRY 원칙 맹신에서 벗어나, 도메인에 대한 이해가 충분히 무르익을 때까지 의도적으로 추상화를 지연시키는 'WET(We Enjoy Typing / 두 번까지는 중복을 허용한다)' 관점이 현대 애자일 설계의 표준 중 하나로 더욱 견고히 자리 잡을 것이다.
- 리팩토링 패러다임의 변화: 대규모 마이크로서비스 아키텍처(MSA) 및 클라우드 네이티브 환경에서 무리한 공유 라이브러리(Common Library) 구축 대신 서비스 간의 '의도된 중복과 격리'를 택하는 아키텍처 의사결정이 늘어날 것으로 예상된다.
출처:hackernews