좋은 추상화에는 '숨겨진 비용'이 있습니다 — 코드를 깔끔하게 만들수록 잃는 것들

추상화는 왜 양날의 검일까

프로그래밍을 배우다 보면 어느 순간부터 "중복 코드는 죄악이다", "DRY 원칙(Don't Repeat Yourself)을 지켜라", "공통 로직은 함수로 빼라" 같은 가르침을 듣게 돼요. 그래서 비슷한 코드가 두세 번 나오면 본능적으로 손이 간질거리죠. 함수로 묶고, 클래스로 추상화하고, 인터페이스로 다듬고요.

그런데 jdgr.net에 올라온 "The Hidden Costs of Great Abstractions"라는 글은 이 본능에 살짝 제동을 걸어요. 추상화 자체는 좋은 도구지만, 우리가 흔히 "멋있다"고 칭찬하는 잘 만든 추상화일수록 오히려 눈에 잘 띄지 않는 비용을 데리고 온다는 거예요.

추상화가 데려오는 세 가지 숨은 비용

첫 번째 비용은 인지 부담(cognitive load)이에요. 잘 만든 추상화는 사용하기 쉬워요. db.users.find({ active: true }) 한 줄이면 끝나니까요. 그런데 그 한 줄이 어떻게 동작하는지 진짜로 이해하려면 ORM 레이어, 쿼리 빌더, 커넥션 풀, 캐싱 로직, 직렬화까지 들여다봐야 해요. 평소엔 몰라도 되지만, 성능 문제가 터지거나 이상한 버그가 났을 때 갑자기 그 모든 층을 한꺼번에 머리에 올려야 해요. 추상화가 깊을수록 "평소엔 편하지만 문제 생기면 지옥"인 패턴이 되는 거죠.

두 번째 비용은 유연성의 상실이에요. 이게 좀 역설적인데요. 추상화는 흔히 "미래의 변화에 대응하기 위해" 만든다고 하잖아요. 그런데 실제로는 처음 추상화를 설계할 때 상상한 변화에만 잘 대응해요. 예측 못한 방향의 변화가 오면 오히려 추상화가 발목을 잡아요. 예를 들어 데이터베이스를 추상화한 Repository 패턴을 만들었는데, 새로운 요구사항이 "두 테이블을 조인해서 부분 컬럼만 가져오는 복잡한 통계"라면? 추상화 레이어가 이걸 못 받아주거나, 받아주려면 추상화를 망가뜨려야 해요. 결국 "raw SQL 탈출구"를 뚫게 되고, 그 순간부터 추상화는 일관성을 잃죠.

세 번째 비용은 디버깅의 어려움이에요. 추상화 레이어가 많을수록 스택 트레이스가 길어지고, 어디서 진짜 문제가 났는지 추적하기 힘들어져요. "내 코드는 한 줄밖에 안 되는데 에러는 라이브러리 깊은 곳에서 났다"는 상황이 자주 벌어지죠. 특히 메타프로그래밍이나 데코레이터, 미들웨어 체인이 끼면 흐름을 따라가는 것 자체가 수사극이 돼요.

그럼 추상화하지 말라는 건가요

절대 그런 얘기는 아니에요. 글의 핵심은 "추상화의 비용을 인식하고, 그 비용을 지불할 만큼 가치가 있을 때만 도입하라"는 거예요.

좋은 판단 기준 몇 가지가 있어요. 우선 "세 번 반복되기 전엔 추상화하지 말라"는 경험칙(Rule of Three)이에요. 두 번 정도 비슷한 코드가 나왔다고 바로 함수로 빼면, 사실 두 코드의 진짜 공통점이 뭔지 파악이 덜 된 상태에서 잘못된 추상화가 만들어지기 쉬워요. 세 번째 사례가 등장하면 그제서야 "아, 이 셋의 공통 패턴은 X구나" 하고 더 정확한 추상화를 만들 수 있어요.

또 하나는 "성급한 추상화보다 중복이 낫다(Duplication is far cheaper than the wrong abstraction)"는 Sandi Metz의 유명한 말이에요. 잘못된 추상화를 되돌리는 건 중복을 합치는 것보다 훨씬 어려워요. 일단 사람들이 그 추상화에 의존하기 시작하면, 고치는 데 드는 비용이 기하급수로 커지거든요.

업계 흐름 속에서

이런 논의는 사실 새로운 게 아니에요. DHH(Ruby on Rails 창시자)도 "Conceptual Compression"이라는 표현으로 비슷한 얘기를 했고, John Carmack은 인라인 코드의 가치를 옹호하는 메모로 유명하죠. 마이크로서비스 열풍이 한참 지난 뒤에 "우리가 모놀리스에서 마이크로서비스로 갈라놓은 게 진짜 이득이었나?"를 되묻는 흐름도 같은 맥락이에요. 분리·추상화가 항상 정답은 아니라는 거죠.

최근에는 Locality of Behavior라는 개념도 자주 언급돼요. HTMX 진영에서 많이 쓰는 표현인데, "한 화면의 동작을 이해하기 위해 여러 파일·여러 레이어를 뒤지지 않아도 되게 만들자"는 철학이에요. 추상화로 분리할수록 코드는 깔끔해 보이지만, 동작 하나를 이해하려면 더 많은 곳을 읽어야 한다는 트레이드오프가 분명하거든요.

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

주니어 시절엔 "우와, 이 코드 진짜 추상화 잘 됐다"는 코드를 보면 무작정 따라 하고 싶어져요. 디자인 패턴 책 한 권 읽고 나면 모든 문제에 패턴을 끼워 맞추고 싶어지죠. 그런데 시니어가 될수록 오히려 "이건 굳이 추상화 안 해도 되겠다"는 판단을 더 자주 하게 되는 것 같아요.

실무에서 적용해볼 만한 룰을 몇 가지 정리하면요. 첫째, 새로운 추상화를 만들기 전에 "이걸 도입했을 때 6개월 뒤에 새 팀원이 코드를 읽기 더 쉬워지는가, 어려워지는가?"를 자문해보세요. 둘째, 한 번 추상화를 만들면 "탈출구"도 함께 설계하세요. ORM이 못하는 쿼리를 위해 raw SQL 인터페이스를 같이 노출하는 식으로요. 셋째, 코드 리뷰에서 "이거 함수로 빼는 게 어때요?"라는 코멘트를 받았을 때, 무조건 따르기보다 "왜 빼야 할까, 빼면 뭘 잃을까"를 같이 생각해보세요.