디자인 패턴에 대한 짧은 고찰

기술 면접을 다녀오면서 큰 깨달음을 얻고왔다.

기존에 나는 효율적인 코드를 위해 디자인 패턴을 따로 공부하고 있었다. 주로 내가 개발 중인 제품이 어떤 디자인으로 구성되어 있는지에 대해 생각해보거나 내 개인 프로젝트에 도입 해보는 방식으로 공부를 해왔는데 대부분은 책을 읽고 따라해보는 식으로 공부를 했다.

열심히 공부한 보람이 있는 건지 마침 기술 면접에서 디자인 패턴에 대해 어떻게 생각하는 지, 어떤 패턴을 써봤는 지 질문을 받았고 나름 잘 정리해서 답변했다.

그리고 내 공부관을 뒤바꾼 운명의 답변을 들었다.

"디자인 패턴을 쓰는 게 맞는 거 같나요? 아니면 안쓰는게 맞는 거 같나요?"

질문을 처음 받았을 때 디자인 패턴에 치중한 나머지 효율적이지 못하게 된 코드들이 생각났다. 오남용 되는 싱글톤 같이 오히려 디자인 패턴을 쓰지 않는 게 좋았을 코드들이 수두룩하지 않은가?

"상황에 따라 다르지만, 적당히 섞어 쓰는게 좋지 않을까요?
물론 공부는 계속 해야하구요 아는 것과 모르는 것은 차이가 크니까요"

솔직히 답변할 당시에는 정말 모범 답안이라고 생각했다. 당시 디자인 패턴 공부를 하며 패턴 오남용에 대한 글귀가 머리 속 깊숙히 남아있던 터라 더 그랬던 것 같다.

참 좋은 답변을 했다고 생각했는데 그 다음 면접관 님의 답변이 아직까지 잊혀지지 않는다.

"개발자 A 와 B가 있었어요"

"두 사람은 같은 문제를 해결한 코드를 자랑했죠"

"그런데 놀랍게도 둘의 코드 구조는 거의 비슷했어요"

솔직히 3초 정도는 이해하지 못했다. 무엇을 말씀하고 싶으셨던 걸까? 그러나 곧 이해가 되었다. 어쩌먼 내가 지금까지 잊고 있었던 작은 편린일 지도 모를 큰 깨달음

디자인 패턴은 뭘까?

싱글톤 패턴, 옵저버 패턴, 팩토리 패턴 블라블라...
이러한 패턴들은 애초에 누가 만든 걸까? 아니, 왜 만든 걸까?

솔직히 면접을 보기 전까지는 크게 궁금하지도 않았고 알고싶지도 않았다. 공부할 게 천지인데 하나하나 따지고 들기 시작하면 언제 놀고 자겠는가?

하지만, 면접관 님의 예시를 듣는 순간 솜털이 찌릿하게 닭살이 돋았다.

내가 그동안 깊게 생각하지 않았던, 어쩌면 개발자로서 역량이 부족해서 생각도 못해봤던 디자인 패턴에 대한 정의

애초에 디자인 패턴이 대체 뭐야?

누가 만들고 왜 만든 거야?

디자인 패턴은 개발자들이 겪어온 오답 노트 묶음이다.

프로그래밍을 하다보면 비슷한 문제나 구조를 계속 직면한다. 서버에서 이벤트가 발생해 처리한다던가,  UI 에서 입력을 받아 work thread에서 처리한다던가

우리는 이걸 왜 이렇게 사용하고 있는 걸까?

큰 제목에서 미리 알려줬지만 굳이 답변을 하자면, 우리보다 더 앞서 개발을 했던 사람들이 기록을 남겨놓았기 때문이 아닐까?

UI 처리에서 work thread가 없다먼 UI가 데이터 처리를 하느라 멈출 것이다. 서버에서 이벤트 처리를 할 때 적절한 구조 없이 무한 polling으로 진행하면 성능 이슈가 발생할 수 있다.

이는 누군가가 겪었던 오답인 것이고 그걸 묶어놓은 것이 디자인 패턴이다.

디자인 패턴을 공부한다는 것은 이러한 오답 노트를 미리 보고 정답에 가까운 코드를 짜기 위한 것 아닐까?

그동안 공부를 잘못하고 있었다.

나는 그동안 디자인 패턴에 대해 잘못 생각했던 것 같다. 이전까지는 "깔끔한 코드 구조"를 위해 디자인 패턴 책에 나오는 내용을 외우는 것에 가까웠는데 이는 별로 좋은 선택이 아니었던 것 같다.

무슨 문제의 오답인지도 모르는데 오답 노트는 왜 외운 단 말인가?

애초에 오답에 직면한 적도 없으면서 무엇이 옳고 그른 지를 판단하는 게 말이 되는가?

오답 노트를 가장 좋게 사용하는 방식은 일단 문제를 풀어보는 것 아닌가?

고로 내가 내린 결론은 다음과 같다.

디자인 패턴을 공부하는 가장 좋은 방법은 많이, 다양하게 코딩하는 것

물론 나는 아직 ㅈ밥 코드 몽키라서 정답이라고는 못할 것 같다. 애초에 내가 짠 코드 자체가 너무 별로고 구현도 똑바로 못하는 경우가 있기에 정답은 절대 아닐 것이다.

하지만

적어도 내가 부족한 식견으로 내린 판단은 이렇다. 오답 노트에 적힌 풀이를 외우는 건 공부가 되지 않는다. 적어도 그 풀이가 왜 맞는 지, 다른 풀이는 없는 지를 봐야하지 않겠는가?

물론 오답 노트를 바로 보면 안된다는 뜻은 아니다. 그저, 왜 그런 결과가 나왔는 지, 어떤 히스토리가 있었는 지에 대헌 생각을 조금이라도 해봐야 오답 노트 외우는 게 쉬워지지 않을까? 라는 생각이 들었을 뿐이다.

천천히라도 멀리갈 수 있도록

솔직히 디자인 패턴 공부를 시작하고 계속 흐지부지 미뤄만 뒀었다. 애초에 "외운다"라는 생각으로 눈에서 레이저 빔을 쏘아댔으니까 어찌보면 당연할 지도 모른다.

근데 앞으로는 디자인 패턴 공부가 조금은 쉬워질 것 같다는 생각이 든다.

내가 어떤 부분에서 잘못된 접근을 했었는 지, 이걸 왜 공부하는 것인지에 대한 정의가 명확해졌달까?

솔직히 남들 삽질하는 거 구경하는 게 재밌을 것 같기도 하다.

솔직히 내가 부지런한 성격은 아니라서 미친듯이 코딩을 하고 디자인 패턴을 적용해보지는 못하겠지만, 적어도 안티 패턴 부터라도 차근차근 내 코드에 녹여들어가는 식으로 공부를 계속할 수 있을 것 같다.

어느 코딩 학원에서 가르치는 것처럼 "몇 달 속성 강의!" 같은 식으로는 힘들어도 몇 년에 걸쳐 천천히 내 것으로 만들면 되지 않을까?

인생은 길고 코드도 기니까 하루에 한 두줄씩만 고쳐나가야지