코드 공통화의 함정: 무조건적인 DRY가 위험한 이유

개발을 배우며 가장 먼저 접하는 원칙 중 하나는 "중복을 제거하라(Don't Repeat Yourself, DRY)"입니다. 중복 코드를 줄이고 공통 함수나 상수로 묶어내는 것은 분명 깔끔하고 효율적인 엔지니어링처럼 보입니다.

하지만 맥락과 도메인이 다른 코드를 겉모습이 비슷하다는 이유만으로 섣불리 공통화하면, 훗날 요구사항이 바뀔 때 예상치 못한 거대한 유지보수 리스크로 되돌아옵니다.

우리는 종종 코드 자체의 우아함을 추구하느라, 실제 제품을 안정적으로 운영하고 기민하게 변경해야 하는 궁극적인 목표를 잊곤 합니다.

1. 섣부른 공통화가 만드는 위험: 결합도 증가와 사이드 이펙트

공통화된 로직이나 상수는 변경이 일어날 때 강력한 양날의 검이 됩니다.

수십 군데에서 참조하는 공통 함수가 있다면, A 화면의 요구사항 변경 때문에 그 함수를 고쳤을 때 전혀 관계없는 B, C 화면까지 연쇄적으로 깨지는 사이드 이펙트가 발생합니다. 코드의 중복을 없애려다 시스템 전체의 결합도(Coupling) 를 극단적으로 높여버린 셈입니다.

반면, 적절히 분리되고 독립적인 코드는 수정 시 영향 범위가 해당 기능에만 국한되므로 훨씬 안전하고 과감한 수정이 가능합니다.

2. 공통화가 필요한 영역 vs 분리해야 할 영역

그렇다면 어떤 것을 공통화하고 어떤 것을 독립적으로 두어야 할까요?

• 공통화가 유리한 영역 (표준 및 인프라): 국가 코드, 통화 포맷, 날짜 파싱, 범용 암호화 유틸 등 도메인 변경과 무관한 표준 로직. 이러한 유틸리티는 가능하면 직접 바퀴를 발명하기보다 검증된 오픈소스 라이브러리를 활용하는 것이 현명합니다.
• 분리가 유리한 영역 (비즈니스 및 도메인 로직): 화면별 정책, 폼 검증 룰, 특정 비즈니스 흐름 등. 지금은 모양이 같아 보여도 기획이 달라지면 얼마든지 각자의 방향으로 분기할 가능성이 높은 코드들입니다.

3. "우연한 중복"과 "진짜 중복"을 구분하라

모양이 같다고 해서 모두 같은 개념인 것은 아닙니다. 서로 다른 비즈니스 이유로 변화하는 두 코드가 우연히 현재 형태만 같은 상태를 '우연한 중복(Accidental Duplication)'이라고 부릅니다.

이를 무리하게 하나의 함수로 합치면, 나중에 조건문(if-else)과 플래그 파라미터가 덕지덕지 붙어 누구도 손대기 두려운 괴물 함수가 탄생합니다.

조기 추상화(Premature Abstraction)보다는 약간의 코드 중복을 허용하는 편이 코드베이스를 훨씬 유연하게 유지해 줍니다.

4. 개발자의 본질적인 역할: 시스템 전체의 안정성 책임지기

엔지니어링의 목표는 코드 라인 수를 줄이는 것이 아니라, 비즈니스 요구사항을 결함 없이 안정적으로 사용자에게 전달하는 것입니다.

"코드가 중복되었으니 일단 합치자"라는 기계적인 접근에서 벗어나, "이 코드가 향후 각기 다른 이유로 변경될 가능성이 있는가?"를 먼저 고민해야 합니다.

핵심 요약

잘못된 공통화로 인한 결합도는 코드 중복보다 훨씬 더 치명적인 기술 부채가 됩니다.

변화의 이유와 주기가 다른 비즈니스 로직은 과감히 독립성을 유지하고, 검증된 도메인에 한해 신중하게 추상화하는 것이 건강한 소프트웨어를 만드는 비결입니다.