추상화는 신중하게: 잘못된 추상화는 중복보다 못하다는 교훈

개발자들이라면 한 번쯤은 들어봤을 법한 격언이 있다. “DRY(Don’t Repeat Yourself) 원칙을 지켜라.” 중복 코드를 극도로 경계하며 추상화를 통해 재사용 가능한 코드를 만들라는 조언이다. 하지만 정말 그럴까? 2016년에 올라온 Sandi Metz의 블로그 글이 최근 Hacker News에서 다시 화제가 되며, 이 오래된 논쟁에 불을 지피고 있다.

잘못된 추상화의 늪

이 글의 핵심 메시지는 간결하다. “잘못된 추상화는 중복 코드보다 더 나쁘다.” 개발자들은 보통 중복 코드를 보면 본능적으로 추상화를 떠올린다. 하지만 문제는 충분한 이해 없이, 혹은 미래에 대한 섣부른 예측으로 추상화를 시도할 때 발생한다. 이런 추상화는 대개 복잡한 계층 구조를 만들고, 쓸데없이 유연한 설계를 도입하며, 결국 코드의 가독성을 떨어뜨리고 변경을 어렵게 만든다.

예를 들어, 두 개의 클래스 Dog와 Cat이 있다고 치자. 이 둘의 공통점을 묶어 Animal이라는 추상 클래스를 만들었는데, 나중에 Fish 클래스를 추가하려니 Animal에 정의된 walk() 메서드가 문제가 되는 식이다. 억지로 Fish에 walk()를 구현하거나, Animal 클래스 자체를 뜯어고쳐야 하는 상황이 온다. 이런 사태는 처음부터 Dog와 Cat이 각자의 길을 갔다면 일어나지 않았을 일이다.

중복, 때로는 더 나은 선택

저자는 차라리 중복 코드가 낫다고 말한다. 중복 코드는 당장은 보기에 좋지 않을 수 있지만, 적어도 각 부분의 변경이 다른 부분에 영향을 주지 않는다. 즉, 결합도가 낮다. 반면 잘못된 추상화는 시스템 전체를 단단히 묶어버려, 한 부분을 고치려다 전체가 무너지는 끔찍한 결과를 낳기도 한다. 마치 실타래처럼 엉켜서 어디부터 풀어야 할지 모르는 상황이 되는 셈이다.

추상화는 충분한 패턴이 명확해지고, 변경 지점이 안정화된 후에 시도하는 것이 가장 좋다. 섣부른 최적화가 만악의 근원이듯, 섣부른 추상화도 마찬가지다. 처음에는 중복을 감수하고 코드를 작성한 뒤, 여러 번의 반복과 리팩토링을 통해 공통 패턴이 확실해졌을 때 비로소 추상화를 고려하는 게 현명한 접근법이다. 결국 개발자의 직관과 경험이 중요한 영역이다. 무조건적인 DRY 원칙 준수보다는, 상황에 맞는 유연한 사고가 필요하다는 교훈을 다시 한번 상기시켜주는 글이다. 개발자 다섯이면 의견은 일곱이라는 말처럼, 이 주제는 언제나 뜨거운 감자일 수밖에 없지만 말이다.