디자인패턴에 관한 개인적인 생각
군에서는 인사장교로 일했습니다. 아직도 소위 때 생각을 하면 눈 앞이 깜깜하네요. 모든게 생소하고 어려웠지요. 내가 읽어야 하는 문서는 무엇인지, 작성해야 하는 문서는 무엇인지, 그 문서는 어떻게 작성해야 하는지 제대로 가르쳐주는 사람 없이 여러 시행착오를 겪어가며 알아야 했으니까요.
그렇게 시행착오를 겪던 와중에 하나의 비법(?)을 습득했습니다. 바로 모든 문서에 패턴이 있다는 것을 깨달은 거죠. “2분기 XXX에 관한 XXX훈련 계획”은 1분기 문서를 참고하면 되고, “2019년 XXXX관련 OOOO지침”같은 문서도 2018년 문서를 참고해서 작성하면 문제가 없었습니다.
이 단순한 진리를 획득하고 제 업무속도는 아주 빠르게 향상되었습니다. 그 전에는 매일 매일 야근의 연속이었지만, 패턴을 활용하면서부터는 야근은 커녕 팀원들과 티타임을 즐길 수 있을 정도로 여유로워졌지요. 저는 어떤 업무도 두렵지 않았습니다.
하지만 이런 여유는 오래 가지 않았습니다. 어느 순간 부터 저는 “패턴을 활용하면 일을 쉽게 할 수 있다”를 “패턴을 활용하면 문서를 한 글자 한 글자 읽지 않아도 된다”는 식으로 받아들였고, 그 결과 아주 부끄러운 실수를 몇 차례 지적 받았습니다.
겉보기에는 2019년의 성폭력 예방교육은 2018년과 크게 달라질 것이 없을 것 같지만, 그건 겉보기만 그런 경우가 많았습니다. 패턴에 취해서 작년과 비슷한 내용일거라고 지레짐작하며 문서를 대충 훑게 되면 중요한 변경사항을 놓칠 수도 있게 된다는 걸 저는 나중에 알게 되었습니다.
물론 문서들에는 분명 패턴이 있습니다. 그런 패턴을 염두에 두고 문서를 작성하기도 하고, 읽을 때도 그런 패턴을 기반으로 읽을 경우에 더 빠른 독해가 가능해지기도 합니다.
하지만 패턴에는 무서운 부작용이 있습니다. 바로 문서의 사소한 디테일을 놓칠 확률이 올라간다는 점입니다. 패턴기반의 독해는 “불필요한 정보를 최대한 무시하기” 때문에 일의 효율을 높입니다. 따라서 정말 주의하지 않으면 “필요한 정보”도 무시해 버리게 될 수 있습니다.
개발자로 전직하고 나서도, 저는 “디자인 패턴”을 배웠을 때 어떤 안도감 같은 것을 느꼈습니다. “아, 저렇게만 작성하면 훌륭한 코드가 되는구나”라는 생각을 했던 것이죠. 어떤 코드가 좋은 코드인지 전혀 감이 오지 않을 시절에는 그런 “디자인 패턴”이 참고자료가 될 수도 있습니다. 하지만 마치 작년 문서에서 날짜만 수정한다고 올해 문서가 되지 않듯, 디자인패턴만 따라 한다고 누구나 읽기 좋은 훌륭한 코드가 될 일도 없습니다.
언제나 제품에 대한 고민을 기반으로 코드를 작성해야 합니다. 그 고민의 결과에서 어떤 패턴을 발견하게 될 수 도 있지만, 패턴을 바탕으로 제품에 대한 고민을 시작하면 패턴에 제품을 욱여넣는 결과를 초래 할 수도 있습니다. 프로그램은 절대로 레고블록을 조립하듯 만들어 질 수 없습니다.
저는 프로그래밍에 입문하는 사람이 디자인패턴에 대해 배우려 한다면, 말리고 싶은 생각이 듭니다. 디자인 패턴을 배운 뒤에 다른 코드들을 읽으면 그 코드들이 그 패턴들에 맞춰 짜여졌다는 생각을 하게 될 수 있기 때문입니다. 인간은 패턴을 너무나 잘 찾아내는 동물이어서, 패턴이 없는 곳에서도 패턴을 찾아내니까요.
하지만 본인이 직접 많은 코드들을 읽고, 그 코드들에서 스스로 어떤 패턴을 포착한 경지가 되었다면, 그 때 비로소 디자인패턴 공부가 도움이 되지 않을까 합니다. 내가 포착한 패턴을 다른 사람들은 어떻게 보는지, 혹은 어떤 이름으로 부르는지에 대해 아는 것은 반대로 시야를 넓히는데 도움이 될 거라고 생각합니다.
아!, 물론 MVC나 MVVM같은 중요한 패턴은 반드시 배워야 합니다. 아직 MVC에 대해 배우지 않은 분이라면, “MVC, 정말 제대로 알고 있나요?” 같은 포스팅이 도움이 될지 모르겠네요!