Hacker News 2026.06.22 26

중복이 잘못된 추상화보다 낫다 — DRY를 맹신하면 안 되는 이유

개발 공부를 하다 보면 가장 먼저 배우는 원칙 중 하나가 DRY(Don't Repeat Yourself, 반복하지 마라)예요. 같은 코드를 두 번 쓰지 말고 함수나 클래스로 묶어서 하나로 만들라는 거죠. 그런데 이 DRY를 너무 종교처럼 떠받들면 오히려 코드가 망가진다는, 살짝 반항적인 주장이 있어요. 루비 커뮤니티의 전설적인 개발자 Sandi Metz가 쓴 글인데요, 제목부터 도발적이에요. "잘못된 추상화를 만들 바엔 차라리 중복을 택하라".

어쩌다 코드가 망가지는가

Sandi가 들려주는 이야기는 우리 모두에게 너무나 익숙한 시나리오예요. 한번 따라가 볼게요.

처음에 개발자 A가 비슷해 보이는 코드를 발견해요. "어, 이거 중복이네?" 하고 착하게 공통 함수로 묶어요. 여기까지는 좋아요. 그런데 시간이 지나면서 요구사항이 바뀌어요. 개발자 B가 와서 보니, 이 공통 함수가 자기 케이스에서는 살짝 다르게 동작해야 하거든요. 함수를 처음부터 다시 쓰긴 부담스럽고, 이미 잘 돌아가는 코드를 깨기도 무서워요. 그래서 어떻게 하냐면, if 특수한_경우라면 이렇게, 아니면 저렇게 하는 조건문을 하나 슬쩍 끼워 넣어요. 매개변수(파라미터)도 하나 추가하고요.

그다음 개발자 C도 똑같이 해요. 조건문 또 하나, 파라미터 또 하나. 이렇게 몇 번 반복되면, 원래 깔끔했던 그 함수는 if와 else로 뒤덮인 괴물이 돼요. 아무도 이 함수가 정확히 뭘 하는지 이해하지 못하는 상태가 되는 거죠. 이게 바로 잘못된 추상화(the wrong abstraction)예요.

왜 사람들은 이 늪에서 못 빠져나올까

Sandi가 짚는 진짜 원인은 심리예요. 바로 매몰비용 오류(sunk cost fallacy)거든요. 이게 뭐냐면, '이미 들인 노력이 아까워서 잘못된 길을 계속 가는' 심리예요. 개발자들은 누군가 공들여 만든 추상화를 보면 이렇게 생각해요. "이만큼 잘 짜인 구조가 있는데, 이걸 버리고 새로 짜는 건 낭비 아닐까? 일단 여기에 맞춰서 끼워 넣자." 그래서 추상화를 부수는 대신 자꾸 조건문으로 땜질하는 거예요. 추상화가 잘못됐을수록, 역설적으로 사람들은 더 그걸 고치려 들지 않고 그 위에 짐을 쌓아요.

그래서 Sandi가 던지는 명언이 바로 이거예요. "중복은 잘못된 추상화보다 훨씬 싸다(duplication is far cheaper than the wrong abstraction)." 코드가 좀 중복되는 건 눈에 거슬릴 뿐 위험하진 않아요. 하지만 잘못된 추상화는 모든 호출하는 쪽을 인질로 잡고, 손댈 때마다 다른 곳을 터뜨리거든요.

그럼 어떻게 빠져나오나

Sandi의 처방은 의외로 시원해요. 잘못된 추상화를 발견하면, 다시 중복으로 되돌리라는 거예요. 조건문으로 뒤덮인 함수가 있으면, 그걸 호출하는 각 위치에 코드를 도로 복사해 넣어서(인라인화) 추상화를 해체해요. 그러면 각 케이스가 독립적으로 보이게 되죠. 이렇게 중복을 일부러 되살린 다음에, 진짜 올바른 추상화가 무엇인지 다시 발견하라는 거예요.

이건 우리가 흔히 듣는 격언과도 통해요. "성급한 최적화는 만악의 근원"이라는 말처럼, 성급한 추상화도 위험하다는 거죠. 추상화는 미래를 예측해서 미리 만드는 게 아니라, 충분한 사례가 쌓여서 패턴이 명확해졌을 때 발견하는 거예요. 'Rule of Three'(같은 코드가 세 번 나타나면 그때 묶어라)라는 경험칙도 같은 맥락이고요.

한국 개발자에게 주는 시사점

실무에서 코드 리뷰할 때 정말 자주 마주치는 상황이에요. 후배가 똑같은 코드 두 줄을 보고 "이거 중복이니 공통 함수로 빼주세요"라고 무조건 요청받는 경우가 많거든요. 하지만 이 글을 읽고 나면, "이 두 코드가 우연히 비슷한 건가, 본질적으로 같은 건가?"를 먼저 묻게 돼요. 모양만 비슷하고 변하는 이유가 다르다면, 섣불리 묶지 않는 게 오히려 정답이에요.

B 함수에 boolean 플래그 파라미터를 추가하고 싶은 충동이 들 때가 바로 위험 신호예요. 그 순간 "내가 지금 잘못된 추상화를 떠받치고 있는 건 아닐까?"를 의심해 보세요. 레거시 코드를 리팩터링할 때도, 무서워서 조건문을 더 끼워 넣기보다 과감하게 해체했다가 다시 묶는 용기가 필요하고요.