1.1.1 패턴의 유래와 필요성

유명한 4인방인 GoF(에리히 감마(Erich Gamma), 리처드 헬름(Richard Helm), 랠프 존슨(Ralph Johnson), 존 블리사이즈(John Vlissides))의 명저 <GoF의 디자인 패턴:재사용성을 지닌 객체지향 소프트웨어의 핵심 요소>(프로텍미디어, 2015) 출간 이후, 디자인 패턴은 세상의 뜨거운 관심을 받았고 전 세계 개발자들은 가장 흔한 소프트웨어 공학 문제부터 패턴을 적용하여 해결하기 시작했습니다. 보물 같은 이 책은 다양한 개발 기법과 함정을 소개하고 객체 지향 프로그래밍의 디자인 패턴을 23개로 나누어 설명합니다. 디자인 패턴은 크게 생성(creational), 구조(structural), 행위(behavioral) 패턴으로 분류합니다.

그런데 왜 사람들은 갑자기 디자인 패턴에 관심을 갖기 시작했을까요?

사실 그렇게 갑작스러운 일은 아니었습니다. 1980년대 들어 객체 지향 프로그래밍이 등장하고 이 새로운 패러다임에 기초한 몇몇 프로그래밍 언어가 탄생합니다(스몰토크(Smalltalk), C++, 오브젝티브(Objective C) 같은 언어는 지금도 씁니다). 하지만 과거 절차형 프로그래밍(procedural programming) 언어로 개발할 때와 달리 새로운 객체 지향형 프로그래밍은 그 자체로 문제가 있었고 세대교체를 너무 빨리하다 보니 무엇이 잘 돌아가고 무엇이 잘 안 돌아가는지조차 짚고 넘어갈 틈이 없었죠.

C, 코볼(COBOL) 등의 절차형 프로그래밍 언어로 개발할 때엔 디자인 패턴으로 스파게티 코드(spaghetti code) 같은 굵직한 이슈를 많이 해결했지만, 객체 지향 언어에는 문제점이 드러나지 않고 내재되어 있었습니다. C++는 급속히 발전했으나 언어 자체가 복잡해서 메모리 누수, 부실한 객체 설계, 안전하지 않은 메모리 사용, 관리하기 곤란한 레거시 코드 등으로 많은 개발자를 버그의 구렁텅이로 빠뜨렸습니다.

한데 이들을 고생시킨 문제는 대개 유사한 패턴을 띠고 있어서 개발자들은 혹여 누가 예전에 같은 문제를 이미 겪어보고 해결하진 않았을까 추측을 하기 시작합니다. 객체 지향 프로그래밍 개념이 처음 등장한 때는 인터넷이 없던 시절이라 자신의 경험을 다른 개발자와 나누는 데 한계가 있었죠. 그래서 잘 알려진 반복되는 문제들을 GoF가 패턴으로 묶어 틀을 정립하기까지 다소 시간이 걸렸습니다.