디자인 패턴과 나의 잘못된 사랑 이야기

PenguinGod·2023년 2월 22일
8
post-custom-banner

첫 만남

기존에 만든 싱글 게임을 멀티 플레이가 가능하도록 포팅하면서 저는 기존 클래스의 80%를 버리고 새로운 코드를 작성했었죠. 똑같은 방식으로 코드를 작성하면 다음에 올 후폭풍은 도저히 예상이 안되서 코드의 재사용성, 더 나아가서 소프트웨어 설계의 바닷속으로 힘차게 들어갔어요. 저는 여러 책을 읽으면서 떠돌고 있었죠. 광할한 바다 속에서 허우적거리면서 숨도 제대로 쉬지 못하고 있던 그때 패턴을 접하게 됐죠.

당신은 아름다웠죠. 제가 겪었던 끔찍한 문제에 대한 훌륭한 해법을 제시하고 있었죠. 조금만 더 일찍 만났더라면 더 행복했을거라 생각했죠. 당신의 사전 설계는 너무나 매력적이라서 앞으로 만날 모든 시련을 극복할 수 있을 거라고 생각했죠. 실제로 해결한 문제는 하나도 없지만, 모든 문제에서 해방되었다고 생각했죠. 그리고 그건 착각이었죠.

균열

저는 당신과 조금이라도 더 함께하고 싶어서 무조건 패턴을 사용하려고 하기 시작했죠. "이 문제를 어떻게 해결할까?"가 아니라, "이 문제에 어떤 패턴을 사용할까?"라고 생각했죠. 처음에는 행복했어요. 이제는 끔찍한 설계 속에서 살지 않아도 된다는 기대감은 이미 저의 이성을 파괴했거든요. 그래요, 2시간 동안 코드 한 줄도 작성하지 못하기 전까지는요

무조건 패턴을 사용해야 하고, 완벽한 설계를 만들어야 한다는 저의 강박은 아무런 설계도 만들지 못하게 했죠. 저는 그렇게 정체되어 있었어요. 당신을 의심하기 시작했고, 관계는 파국으로 향하기 시작했죠.

리팩터링

그러다가 친구들끼리 리팩터링 스터디를 하기로 해서 <리팩터링 2판>을 오랜만에 펼치게 되었죠. 예전에 읽었을 때는 디자인 패턴에 대한 지식이 없었어요. 그래서 그 때 당시에는 그냥 넘겼지만 다시 읽어보니 인상적인 문장들이 몇 개 있었죠. 특히 <Gof의 디자인 패턴>의 공동 저자 중 한 명인 에릭 감마의 말이 기억에 남았죠.

<GoF의 디자인 패턴>을 집필하면서 나와 공동 저자들은 디자인 패턴이 '리팩터링을 수행하여 도달하려는 목표'를 제시한다고 얘기했다.
-[리팩터링, 4p]

이해는 되지 않았지만 계속 머릿속을 겉돌았죠. 디자인 패턴이 리팩터링의 목표를 제시한다니, 패턴은 기본적으로 사전 설계를 위한 것이 아닌가? 고민하던 저에게 마틴 파울러는 <패턴을 활용한 리팩터링>이라는 책을 추천했어요. 제목부터 제가 원하던 내용이 있을 것 같아서 바로 읽기 시작했죠.

잘못된 사랑

책에서는 패턴을 사용하는 2가지 방법이 제시해요. 첫 번째는 코드를 작성하기 전 사전적 설계를 하는 것. 두 번째는 이미 작성된 코드를 개선하기 위해서. 즉, 리팩터링을 위해 패턴을 사용하는 것이죠.

저는 오직 전자의 방식으로만 패턴을 바라봤죠. 그리고 모든 문제를 사전적 설계로 해결하려고 했죠. 망치를 들면 모든게 못으로 보인다고 어떤 상황에서든 패턴을 끼워넣으려고 했죠.왜나면, 그 망할 망치하고 사랑에 빠졌으니까요.

하지만 그 사랑은 잘못됐어요. 디자인 패턴은 사랑할 대상이 아니라 사용할 대상이었고, 그저 도구일 뿐이었죠. 당연한 이야기이지만 도구를 사용할 때는 도구를 능숙하게 다루는 것만큼이나 언제 그 도구를 사용할지를 결정하는 것도 굉장히 중요하죠. 저는 그걸 몰랐어요.

패턴과 리팩터링

이 문제를 해결하는 방법은 패턴을 활용하는 두 번째 접근 방법을 취하는 거에요. 리팩터링을 위해 패턴을 쓰는 거죠. 이렇게 하면 뭐가 좋을까요? 간단해요. 패턴이 정말 필요할 때만 패턴을 쓸 수 있죠. <테스트 주도 개발>에서 켄트 백이 말했던 것처럼, 제가 설계를 하는 것이 아니라 설계가 그 곳에 있게 하는 거죠.

그냥 시스템이 무슨 일을 할지 생각하고 나중에 설계가 알아서 정해지도록 하는 것이 더 낫다.
[테스트 주도 개발, 322p]

열심히 코딩을 하다 보면 어느 순간 코드에서 문제가 보이기 시작할 거에요. 리팩터링에서 '냄새'라고 표현하는 것이죠. 꾸밈 기능이 너무 많아져서 생성 함수에 flag 매개변수가 너무 많아졌다거나, 형제 클래스들이 특정 부분만 다르고 같은 순서로 작업을 하고 있어서 중복이 너무 많아질 수도 있죠.

이렇게 냄새가 나기 시작하면 그때 패턴을 적용하는 것이죠. flag 변수는 데코레이터 패턴으로 없앨 수 있고 동시에 새로운 꾸밈 기능을 추가하기 쉬워질 수 있죠. 그리고, 템플릿 매서드 패턴으로 형제 클래스 간의 중복을 제거할 수도 있죠.

물론 이렇게 하려면 코드에서 문제점을 발견해내는 능력이 필요하고 이건 연습과 경험이 필요한 영역이죠. 하지만 이러면 더 이상 설계를 예측할 필요가 없죠. 제가 할 일은 그저 이미 있는 설계의 의도를 더 명확하게 하거나 중복을 없애거나 앞으로의 작업을 더 쉽게 하는 단순한 리팩터링이 되죠.

생각보다 멋이 없죠. 처음 디자인 패턴을 봤을 때는 혁신적인 설계를 해야 한다거나 우아하고 아름다운 것을 만들어야 한다고 생각했는데 말이죠. 하지만 패턴이라는 것은 사실 그렇게 이상적이고 멀리 있는게 아니라 조금 더 우리에게 와닿는 것이었죠. 사실 저도 그 목표를 이루기 위해 패턴을 공부했던 건데 어느 순간 잊고 말았죠. 그래도 다행히 이 책이 다시 생각나게 해줬네요.

진짜 목표는 패턴을 구현하는 것이 아니라 더 좋은 설계를 얻는 것임을 명심하기 바란다.
[패턴을 활용한 리팩터링, 66p]

profile
수강신청 망친 새내기 개발자
post-custom-banner

2개의 댓글

comment-user-thumbnail
2023년 2월 22일

오랜만에 보네요!
자주 써주세요!

답글 달기
comment-user-thumbnail
2023년 2월 27일

very nice post.
www.benefitscal.org

답글 달기