“패턴을 좀더 쉽게 학습하고 실제 프로젝트에 잘 적용할 방법이 없을까요?” 필자가 강의를 마치고 종종 듣는 질문이다. 부족하지만 필자가 공부한 패턴 지식들과 경험들을 합쳐, 독자 여러분에게 패턴을 학습, 활용하기 위한 시행착오를 조금이나마 줄일 수 있는 지름길을 안내하고자 한다.
손 영수 arload@live.com | 데브피아 Architecture 시삽과 Microsoft MVP로 활동 중이며, 데브피아 소프트웨어 공학 스터디인 Eva팀의 리더이다. 부족한 실력이지만 지식을 나눌 때는 누구보다 ‘부자’라는 자부심을 가지고 지식 나눔에 힘쓰고 있다. Pattern 전도사를 꿈꾸고 있으며, PLoP와 같은 Pattern 학회를 국내에 만들기 위해 힘 쏟고 있다.
요즘은 대학교 학부생의 교과 과정으로 들어갈 정도로 패턴은 많은 이들에게 알려져있다.. 하지만 필자 주위에는 패턴을 잘 활용하여, 성공적으로 프로젝트를 마무리 했다거나 좋은 결과를 보았다는 말보다는, 오히려 많은 불신들과 하소연을 들었다. 왜 이런 상황이 발생했을까? 이 글을 통해 독자들이 패턴에 오해를 풀고, 올바른 시선을 가지길 바라며 글을 적는다.
패턴을 대하기 이전에 마음가짐 – 유연성, 확장성
많은 분들과 패턴을 주제로 애기하다 보면, 패턴에 대한 잘못된 관점을 가진 분들을 종종 만난다. 패턴을 통해, 비약적인 성능 향상, 생산성이 증대 될거라 생각하는 분도 있고 심지어 Silver Bullet (은총알)로 생각하는 분도 있다. 물론 제한적인 도메인 안에서 성능, 생산성 향상을 가져 올 수 있는 패턴도 있지만, 패턴 자체의 목적은 유연성과 확장성에 초점을 맞추고 있다.
초창기 객체 지향(80년대)의 가장 중요시 여기는 패러다임은 “Reuse (재사용)” 이였다. 그래서 Component와 같은 이상적인 패러다임이 나오기도 했다. 마치 Lego와 같이 조립만 하면 만들어지는 Legoware를 꿈꾸어 오면서…
하지만 현재 소프트웨어는 어떠한가? 빈번하게 바뀌는 고객의 요구사항, 몇 명 이서 만들 수가 없을 정도로 거대해진 규모, 길어진 소프트웨어 생명주기를 가진 녀석들이 대부분이다. 그렇기 때문에 소프트웨어가 가져야 할 중요한 설계 방향이 재 사용성 보다는 쉽게 변화를 수용할 수 있는 유연성(Flexibility)과 확장성(Extensibility)이 대두되게 되었다. 만약 여러분이 유연성과 확장성에 초점을 맞춘 설계에 관심이 있다면, 패턴은 좋은 도구가 된다. 하지만, 최적화나 성능 개선이 목적이시라면 패턴보다는 알고리즘을 공부하는 것이 더 낫다.
그리고 패턴을 쉽사리 적용하지 못하는 여러 가지 장벽들이 곳곳에 존재한다. 패턴에 대한 불신들이다. 지면상의 제약으로 이 모든 내용을 언급하기가 한계가 있으니 예전에 필자가 마소 2007년 8월호에 기고한 “미워도 다시 보는 패턴 이야기”를 꼭 읽어보길 권한다. 패턴의 정의, 원칙, 참고할만한 설계구조도 설명하고 있다.