클린 코드를 지킬수록 내 코드는 안 깔끔해졌다

동료가 올린 PR을 열었다. 기능은 딱 한 줄, "결제가 실패하면 한 번만 재시도한다"였다. 그런데 새로 생긴 파일이 일곱 개였다. 인터페이스 하나, 그 구현체 하나, 구현체를 만드는 팩토리 하나, 팩토리를 주입받는 서비스 하나. 정작 "재시도"라는 로직이 박힌 줄을 찾으려고 파일을 다섯 번 넘겨야 했다. 리뷰 코멘트를 달다가 손이 멈췄다. 이거, 나도 반년 전에 똑같이 짰던 코드다. 그때 나는 "이게 확장에 열려 있는 구조"라고 뿌듯해했다.

원칙을 교리처럼 외우자 코드가 오히려 무거워졌다

SOLID은 다섯 글자다. 단일 책임(SRP), 개방-폐쇄(OCP), 리스코프 치환(LSP), 인터페이스 분리(ISP), 의존성 역전(DIP). 로버트 마틴이 정리한 이 다섯 개, 거기에 DRY와 KISS까지 처음 배웠을 때는 세상이 정돈되는 기분이었다. 함수는 짧게, 클래스는 한 가지 일만, 중복은 보이는 즉시 제거. 규칙이 명확하니 지키기만 하면 좋은 코드가 저절로 나올 줄 알았다.

문제는 그다음이었다. "한 클래스는 한 가지 일만"을 지키겠다고 클래스를 계속 쪼갰다. 스무 줄짜리 로직이 작은 클래스 다섯 개로 흩어졌다. 하나하나는 분명히 한 가지 일만 한다. 그런데 그 다섯 개를 머릿속에서 다시 조립해야 전체 흐름이 보였다. 파일 사이를 점프하는 시간이 정작 로직을 읽는 시간보다 길어졌다. 중복을 없애겠다고 비슷한 두 함수를 공통 함수로 묶은 적도 있다. 알고 보니 둘은 그냥 우연히 닮았을 뿐이었고, 한쪽 요구사항이 바뀌자 그 공통 함수는 파라미터와 if 분기로 누더기가 됐다. 중복을 지우려다 결합을 만든 셈이다.

원칙은 목적을 위한 수단인데, 어느새 수단이 목적이 됐다

원칙이 존재하는 이유는 하나다. 코드를 바꾸기 쉽게, 읽기 쉽게 만들기 위해서. SRP도 OCP도 결국 "나중에 고칠 때 덜 아프자"는 이야기다. 그런데 언젠가부터 나는 그 목적을 잊고 규칙 통과 여부만 봤다. 이 클래스가 두 가지 일을 하나? 그럼 나눠야지. 이 함수가 스무 줄이 넘나? 그럼 쪼개야지. 정작 "이렇게 나누면 다음 사람이 읽기 편해지나?"는 한 번도 묻지 않았다.

수단이 목적이 되면 판단이 사라진다. YAGNI(지금 안 쓸 거면 만들지 마라)를 알면서도, 언젠가 확장할지 모른다는 막연한 이유로 인터페이스부터 팠다. 그 "언젠가"는 대개 오지 않았고, 남은 건 아무도 두 번째 구현을 넣지 않는 텅 빈 추상화 계층뿐이었다. 규칙은 다 지켰는데, 코드는 처음보다 읽기 어려워져 있었다. 리뷰어가 "이거 왜 이렇게 복잡해요?"라고 물으면, 나는 원칙 이름을 방패처럼 댔다.

지난달에 오래 묵은 백엔드 서비스 코드를 전수 점검할 일이 있었다. 거기서 걷어낸 것의 상당수가 바로 이런 흔적이었다. 두 번째 구현이 끝내 오지 않은 인터페이스, 어디서도 참조하지 않는 DTO 계층, "나중을 위해" 갈라둔 채 한쪽만 쓰이는 분기. 처음 만든 사람은 분명 확장을 대비했을 텐데, 몇 년이 지나 남은 건 로직을 찾으려면 파일을 몇 번씩 건너뛰어야 하는 이동 경로뿐이었다. 지우고 나니 코드 줄 수는 줄었는데 읽기는 오히려 쉬워졌다. 추상화를 더해서가 아니라 덜어내서 깔끔해지는 경험은, 원칙을 외우던 시절의 나로서는 상상하지 못한 방향이었다.

규칙을 적용하기 전에 먼저 던지는 질문 하나

요즘은 규칙을 대기 전에 딱 하나를 먼저 묻는다. "이 변경이 코드를 실제로 읽기 쉽게 만드나, 아니면 규칙 하나를 만족시킬 뿐인가?" 답이 후자면 안 나눈다. 중복도 세 번째 마주칠 때까지는 그냥 둔다. 두 번 겹친 건 우연일 때가 많고, 성급하게 묶은 추상화를 나중에 되돌리는 비용이 중복 몇 줄을 참는 비용보다 훨씬 크다는 걸 몇 번 데이고 나서 알았다.

최근 HN에서도 "SOLID가 한 번도 solid하게 느껴진 적 없다"는 식의 글이 돌며 갑론을박이 있었다. 원칙 자체가 낡았다는 쪽과, 오용해 놓고 원칙 탓을 한다는 쪽. 나는 후자에 가깝다. 요즘은 AI가 짠 코드에서 과잉설계를 대신 걷어내는 도구까지 나오는데, 결국 화두는 덜어낼 줄 아느냐다. SOLID도 클린 코드도 좋은 도구다. 다만 도구를 신앙으로 바꾸는 순간, 그 도구가 원래 지키려던 것을 도구 스스로 부순다. 코드의 깔끔함은 지킨 규칙의 개수가 아니라, 반년 뒤의 내가 이 코드를 얼마나 덜 저주하느냐로 판가름 난다.

---

참고: It's probably time to stop recommending Clean Code (qntm) · Clean Code: The Good, the Bad and the Ugly (Daniel Gerlach)