대학교 입학후 프로그램을 시작하고 한창 자신감이 쌓여 가던 대학교 3학년 시절...
프로그래밍 분야에서 한발 더 나아가고 싶은 맘에 "디자인 패턴" 에 대해 공부했던 때가 생각난다. 
사실 그 당시에는 디자인 패턴이라는 멋드러진 이름에 매료되어 "어떻게 요구사항을 잘 만족시킬까?"
보다는 "어떻게 디자인 패턴을 적용하여 구조를 이쁘게 만들까?" 라는 생각에 사로잡혀 있었다. 
인터페이스와 구현클래스를 조합하기에 따라 특정 상황(요구사항이 바뀌는 상황)에서 코드에 대한 수정을 
최소화 한채 구조를 변경할 수 있도록 하는 패턴들이 어찌나 대단해 보였는지...
(이해하기 힘든 클래스 다이어그램 때문에 더 대단해 보였다.)

그 시절에 비해 상대적으로 많은 시간(5년)이 흘렀지만 실무 개발을 시작한지는 이제 갓 1년 4개월....정도 
얼마나 실력이 향상 되었겠느냐마는...소프트웨어를 바라보는 시야는 그때에 비하면 크게 성장했다고 생각한다. 

"Head First Design Pattern" 을 교재로 사내 스터디를 시작했다. 첫장을 소개하는 발표자의 음성을 들으면서 문득
예전일이 생각났다.  디자인 패턴에 대한 글을 작성해보려다가 기본원칙 몇개와 책에 있는 패턴을 설명하는 글을 정리해서
올리다가 중간에 그만두었었던 때가 말이다. 그 때는 경험이 결핍된 지식으로는 어쩌면 당연한 결과인 것이다. 

그때를 떠올리며 이제는 내 생각으로 디자인 패턴에 대해 설명할 수 있지 않을까? 는 생각이 들었다. 
시간이 흐르면 많은 생각들이 또 변하겠지만 중간 점검으로는 적절한 때인듯 하다.

디자인 패턴을 구성하고 있는 패턴들에 대해 알아보기 앞서 디자인 패턴이란 무엇인지 알아보는 것은 당연한 일!!
소프트웨어를 하나 둘 개발하며 경험을 쌓다보면 늘 모든 일에서 그렇듯이 소프트웨어 개발에 있어서의 반복적으로
등장하는 상황이 발생하기 시작한다. 누구나 한 분야의 일에 대해 여러번의 경험을 반복하면 효율적으로 그일을 처리하는 Know-how가 쌓이기 마련이다. 소프트웨어 개발에 있어서 그러한 Know-how 중 Design 즉 설계에 있어서의 노하우를
디자인 패턴이라고 한다.
덧붙히자면 소프웨어 개발은 고객과 대화를 통해 요구사항을 추출해내고, 해당 분야에 대한 정보수집을 토대로 분석과정을
거쳐 설계에 이르고 실제 구현을 하게 된다. 이런 소프트웨어 모든 각 단계에 대한 노하우 즉 패턴이 존재한다.
(하지만 노하우 전달이 어려울뿐..) 요구사항 수집 패턴, 정보수집 패턴, 분석패턴, 설계패턴, 구현패턴 갖가지 패턴들이
존재할 수 있으며 디자인 패턴은 설계 단계에 있어서의 패턴에 특별히 주목하는 것이다. 

물론 이 디자인 패턴들은 먼저 소프트웨어 개발을 지긋이 했던 선배들 (GOF 선배들이라고 들어봤나?)이 경험을 통해
이름을 붙이고 알기쉽게 분류를 해놓았다. 개개의 노하우에 이름을 붙히고 언제 사용하면, 무엇이 좋은가에 대한 것을
기준으로 분류를 해놓아 책으로 엮은 것이 그 유명한 "GOF(Gang Of Four)의 디자인 패턴" 이다.
디자인 이름만 이야기해도 뭔가 뽀대가 나지만, 알맹이 없는 어중이 떠중이가 되고 싶지 않다면 적어도 하나의 패턴에 대해
이야기 할때는 "패턴의 이름", "패턴을 적용할 상황", "적용시 장점과 단점" 까지는 함께 이해하는 것이 좋으리라.... 

초보 운전자에게 베스트 드라이버께서 운전 노하우를 요목조목 설명해주면 어떻겠는가? 디자인 패턴은 소프트웨어 개발 중 
발생할 수 있는 여러 문제상황 속에서 검증된 해결책이다.  적어도 비슷한 상황속에서 이 패턴을 사용하면 더 적은 노력으로
원하고자 하는 답을 얻을 수 있다는 것이다.  하지만 각양각색의 상황 속에 완전히 일치하는 해결책이란 존재하지 않는다.
자신의 상황에 맞게 패턴을 변형해서 적용해야 하는 경우가 더 많을 것이다. 
책에서 자주 언급되는 디자인 패턴 적용의 장점 중 하나는 의사소통 비용의 감소이다. 디자인 패턴에 대해 잘 알고 있는
개발자 간에 대화시 패턴의 이름은 그 어떤 구구절절한 설명보다도 간단 명료하게 전달 될 것이다. 하지만 디자인 패턴을
잘 모르는 개발자가 있다면? ...

노하우란 경험을 통해서만 습득할 수 있는 것이다. 개발 경험이 부족한 초급 개발자들이 디자인 패턴을 이해하기 어려워하는
것은 당연한 일이다.  내가 예전에 그랬듯이 소프트웨어에 어떤 디자인 패턴을 적용할까 라는 고민은 잘못된 고민이다.
소프트웨어에 발생하는 이 문제를 해결하기에 이 패턴을 사용하면 이러이러한 장점이 생길 것 같은데...라는 자세가 옳다고
생각한다.  디자인 패턴은 목적이 아니라 다만 최선의 답을 위한 해결책 중 하나의 선택안이라는 것을 명심하길 바란다.