디자인 패턴과 4인방

걸리버 개발기

한창 개발자로 취업 준비를 할 때의 일이다. 코딩 테스트와 프로젝트 코드, 그리고 면접을 위한 지식을 정리하고 있었다. 그런데 해도해도 너무나 넓고 깊었다. 어떻게든 컴퓨터 공학 지식들에 우선순위를 정하는 일로 취업 준비를 시작했다. 정리의 기준은 과연 지금 취업에 필요하느냐였다.

그런데 시험(혹은 면접)을 앞두고 공부하다 보면 항상 그런 순간이 찾아온다. 당장의 시험에는 필요가 없을 것 같은데 묘하게 재미있는 지식들에 사로잡히는 순간이 찾아온다. 이런 지식들에 홀려 찾아보고 있으면 아까운 시간이 잘도 흘러간다. 지루하던 공부가 이런 때는 흥미롭고, 시험이 다가올수록 그 지식에 몰입되는 마법이 벌어진다.

취업을 앞둔 나에게는 "디자인 패턴"이 바로 그런 것이었다. 코딩을 잘하게 해주는 패턴을 배울 수 있다니 군침이 돌았다. 디자인 패턴에 관한 가장 유명한 책을 쓴 사람들을 4인방(Gang of Four)이라고 부른다는 사실을 알고난 이후에는 이유없는 친밀감마저 생겨났다. 물론 내가 알고 있던 4인방은 문화 대혁명 기간 중국 공산당의 핵심 인물들 이었다. 나처럼 정치외교학을 전공하지 않고 컴퓨터 공학만을 전공했던 취업 준비생들은 알 수 없는 연결고리여서 혼자만의 비밀같이 느껴지기도 했다.

반면 컴퓨터 공학에서의 4인방은 1995년 소프트웨어 공학에서 사용되는 23가지의 디자인 패턴을 소개한 이 책의 저자들을 말한다.

디자인 패턴이란 프로그램 구현 중에 자주 발생하는 문제들을 해결할 때 도움이 되는 코드들의 패턴을 말한다. 디자인 패턴을 다루는 이 책은 코드를 쓰는 목적은 단순히 오류 없음이나 기능의 동작에 머물지 않는다고 주장한다. 다시 말해, 같은 동작을 하는 코드라도 더 나은 코드가 있고 조금 못난 코드도 있다는 것이다. 더 나은 코드들에는 반복적으로 몇가지 패턴들이 발견되곤 한다. 이 책은 그러한 패턴들을 모아서 소개하는 책이다.

물론 그렇다고 해서 코드가 자연어처럼 허구의 세계를 창조하고 인간의 감정을 표현하는 목적을 가지는 것은 아닐 것이다. 코드의 또다른 목적은 프로그래밍에 필수적인 효율적인 협업을 전제로 한다. 현대 사회의 소프트웨어는 한 인간 속 뇌의 비루한 용량에 비해서 너무나 거대해진지 오래다. 이 소프트웨어들은 인터넷을 통하여 공유되고 네트워크를 통하여 연결되어 있기도 하다. 코드 작성의 목적이 기능의 실현을 넘어서 독자의 효율적인 이해로 확장되는 이유도 이 때문이다. 코드는 길고 인지는 짧기에, 프로그래머는 읽기 좋은 코드를 작성해야한다.

4인방의 디자인 패턴이라는 책은 읽기 좋은 코드를 작성하는 방식들을 소개한다. 마치 스티븐 킹이 쓴 "유혹하는 글쓰기"의 코드 버전을 보는 것과 같달까. 그러나 신입 개발자로서 취업 준비를 한다는 것은 더 좋은 코드를 작성하는 일과는 거리가 있었다. 오히려 최소한의 기준을 넘은 코드들을 빠르고 정확하게 작성하는 일에 가까웠다. 디자인 패턴을 공부하는 일은 더 좋은 코드를 작성하는 일에 해당했기에, 당시 나는 입맛을 다시며 디자인 패턴에 대한 호기심을 마음 속 한켠에 고이 접어 두었었다.

디자인 패턴을 다시 떠올릴 때가 되었다.

어느덧 개발자로서 일을 한지도 3년이 지났고 디자인 패턴을 다시 펼쳐보아도 문제가 없는 시간이 왔다고 느껴진다. 주위를 살펴보니 저년차 프로그래머들이 종종 이 책을 가지고 스터디를 하는 모습을 볼 수 있었다. 현업에서 다른 개발자들이 적용한 디자인 패턴을 실제로 접한 뒤 찾아보게 되니 더욱 자연스럽기도 하다. 사실 취업 준비를 하던 시절에 본 디자인 패턴에 관한 코드들은 머리로도 잘 이해가 가지 않았고 생경한 지점들이 많았다. 신기하게도 이제는 디자인 패턴에 대한 코드를 읽다보면 그 필요성에 공감하는 마음이 우러나는 경우가 있다. 특히 각 디자인 패턴을 사용할 때의 단점과 사용하지 말아야 할 상황들에 대한 언급에 고개를 끄덕이게 된다.

자신의 코드에 디자인 패턴을 적용해보고 싶은 욕구를 가진 개발자들은 적지 않을 것이다. 나도 현업에서 디자인 패턴이 적용된 코드들을 어렵지 않게 찾아볼 수 있었다. 문제의 상황에 적절한 디자인 패턴을 적용한 아름다운 코드에 속으로 감탄한적도, 무리하게 디자인 패턴을 끼워넣은 듯한 코드에 고개를 갸우뚱한 적도 있었다. 이 글을 쓰게된 계기는 사실 디자인 패턴을 사용한 코드의 빛 보다는 어두움 때문이다. 커맨드 패턴, 템플릿 메서드 패턴, 옵서버 패턴 등 디자인 패턴에는 아주 다양한 종류가 있다. 그리고 이것은 디자인 패턴들이 매우 구체적인 문제 상황에 개별적으로 적용되어야 함을 내포한다. 디자인 패턴은 내 눈 앞에 놓인 문제적 코드의 매듭을 단칼에 잘라낼 수 있는 알렉산드로스 대왕의 칼이 아닌 것이다.

앞서간 개발자들로부터 전해내려오는 전설적인 비급을 사용해보고 싶은 마음은 공감하지만, 주화입마에 빠지지 않도록 조심해야 한다. 프로그래밍의 세계에서 주화입마의 대상은 "디자인 패턴"이라는 비급을 사용한 내가 아니라, 그 코드를 받아 리뷰하고 유지 보수해야 하는 누군가이기 때문이다. 이는 독자의 효율적인 이해라는 디자인 패턴의 목적에 벗어나는 결과를 낳는다. 디자인 패턴도 다 코드로 먹고살자고 쓰는 것이다. 코드로 먹고 살기 위해서는 먼저 쉽게 쓰고 쉽게 읽혀야 한다.