디자인 패턴에 코드를 억지로 끼워 맞추는 개발자에게

by 그릿 | GROWTH_ESSAY | 2026-10-24

"선배님, 결제 모듈에 전략 패턴과 팩토리 패턴을 적용해봤는데 한번 봐주실 수 있나요?"

2년 차 백엔드 개발자 한 분이 코드 리뷰 요청과 함께 가져온 프로젝트를 열어보았습니다. 지원하는 결제 수단은 카카오페이 단 하나였습니다. 그런데 디렉터리 안에는 인터페이스 셋, 구현체 셋, 팩토리 클래스 둘, DTO 변환기가 겹겹이 쌓여 있었습니다. 결제 승인 API 하나를 호출하기 위해 대여섯 개의 파일을 타고 들어가야 했습니다.

왜 이런 코드가 나올까요? 코드를 잘 짜고 싶다는 욕심 때문입니다. 책에서 본 디자인 패턴을 내 손으로 구현해보고 싶다는 조급함이 앞선 것입니다. 좋은 설계의 모습과는 거리가 멉니다. 당면한 현실을 해결하기보다 상상 속 시나리오를 덧붙이며 스스로 복잡성을 키운 결과입니다.

오지 않을 미래를 위해 현재의 가독성을 버립니다

멘토링을 거쳐간 200명 넘는 주니어 개발자들에게 "왜 여기에 전략 패턴을 썼느냐"고 물으면 열에 아홉은 똑같이 답합니다. "나중에 네이버페이나 토스페이가 추가될 수도 있으니까요."

그럴듯하게 들리지만 착각입니다. 확장의 기회는 서비스가 시장에서 살아남았을 때 찾아옵니다. 다음 달에 비즈니스 모델이 바뀔 수도 있는 초기 단계에서, 오지 않을 미래를 대비하느라 동료가 읽어야 할 코드 난이도를 세 배로 올려놓았습니다. 변경 확률이 희박한 곳에 과도한 유연성을 심는 코드는 결국 관리 비용으로 돌아옵니다. 현재 가장 단순하고 명쾌하게 돌아가는 코드가 언제나 최선입니다.

패턴은 고통 끝에 만나는 결과입니다

디자인 패턴은 천재 개발자들이 책상에 앉아 미리 만들어둔 절대 공식이 아닙니다. 수많은 프로젝트에서 중복과 변경의 고통을 겪은 뒤 "이런 문제는 이렇게 푸니 다루기 수월했다"며 사후에 이름을 붙인 경험의 축적입니다.

복잡성을 경험하기도 전에 패턴부터 코드에 들이대는 것은, 열도 나지 않는 사람에게 독한 처방전을 안겨주는 격입니다. 중복이 실제로 두세 차례 누적되고 변경의 압력이 생길 때 리팩토링으로 도출해야 자연스럽습니다. 패턴이라는 틀을 먼저 세우고 도메인 로직을 구겨 넣으면 본질은 사라지고 껍데기만 남습니다.

단순함이야말로 가장 단단한 기본기입니다

경험 많은 시니어 개발자의 코드를 열어보면 화려한 패턴이 눈에 띄지 않습니다. 클래스 이름도 직관적이고 로직 흐름도 위에서 아래로 편안하게 읽힙니다. 패턴을 몰라서가 아닙니다. 불필요한 추상화가 시스템의 수명을 갉아먹는다는 사실을 수많은 야근과 장애를 겪으며 체득했기 때문입니다.

진짜 실력은 복잡한 패턴 없이도 비즈니스 요구사항을 명쾌하게 풀어내는 문제 해결력에 있습니다. 인터페이스를 만들고 싶은 충동이 일어날 때 한 번만 멈춰 서십시오. 단일 파일과 서너 개의 메서드로 충분한 작업에 무거운 아키텍처의 옷을 입히지 마십시오. 단순함이야말로 변화에 가장 빠르게 대응할 수 있는 가장 든든한 무기입니다.