11. 디자인 패턴은 왜 반복되는가

카페에서 주문을 하면 진동벨을 하나 받는다. 자리로 돌아가 앉아 있어도 되고, 화장실에 다녀와도 되고, 잠깐 딴생각을 해도 된다. 커피가 준비되면 진동벨이 알아서 울린다. 손님은 카운터 앞에서 언제 나올지 모르는 커피를 하염없이 기다릴 필요가 없다.

이 장면을 조금 뜯어보면 세 가지 요소가 보인다. 손님은 “완성되면 알려 달라”고 미리 등록만 해 두고 자리를 뜬다. 바리스타는 커피가 완성되는 순간에만 진동벨을 울린다. 그리고 그 사이의 시간 동안 손님과 바리스타는 서로의 상황을 전혀 신경 쓰지 않는다. 손님이 어디에 있든 바리스타의 일에는 영향을 주지 않고, 바리스타가 어떤 순서로 커피를 만들고 있든 손님의 대기 방식도 달라지지 않는다.

프로그래밍에서도 이런 모습은 낯설지 않다. 버튼에 클릭 이벤트를 등록해 두면 코드는 사용자가 언제 버튼을 누를지 미리 알 필요 없이 그 순간에만 실행된다. 메신저를 계속 들여다보지 않아도 새 메시지가 오면 알림이 오고, 유튜브 채널을 구독해 두면 새 영상이 올라왔을 때만 알려 준다. 겉으로는 전혀 다른 서비스처럼 보이지만, “지금 등록해 두고 나중에 조건이 맞으면 통보받는다”는 구조는 모두 같다. 소프트웨어 공학에서는 이 구조에 **옵저버 패턴(Observer Pattern)**이라는 이름을 붙여 두었다.

흥미로운 점은 이 구조가 서로 다른 분야에서 비슷한 필요를 해결하는 과정에서 반복해서 등장한다는 사실이다. 카페 운영자는 손님의 대기 시간을 줄이기 위해 진동벨을 도입했고, GUI를 만든 사람은 사용자 입력에 효율적으로 반응하는 방법을 고민했고, 유튜브 개발자는 새 영상을 놓치지 않도록 알림 기능을 만들었다. 출발한 문제는 서로 달랐지만, 결국 같은 구조에 도달했다.

4장에서 살펴봤듯 이름을 붙이는 일은 서로 다른 대상을 하나의 손잡이 아래 묶는 일이었다. 디자인 패턴도 마찬가지다. 다만 이번에 묶이는 대상은 낱개의 값이 아니라 관계의 구조다. “누군가 조건을 등록해 두고, 조건이 충족되면 통보받는다”는 관계가 카페와 GUI와 동영상 서비스처럼 전혀 다른 재료 위에서 반복해서 나타났고, 프로그래머는 그 반복을 알아채고 옵저버라는 이름을 붙였다. 패턴은 새로운 발명이 아니라 반복해서 나타나는 구조에 붙인 이름이다.

이렇게 보면 왜 디자인 패턴이 계속해서 발견되는지도 설명이 된다. 세상의 문제는 셀 수 없이 많아 보이지만, 그 문제들이 요구하는 관계의 구조는 생각보다 많지 않다. 무언가를 순서대로 처리해야 하는 문제, 하나의 요청을 여러 후보 가운데 하나에게 넘겨야 하는 문제, 전체 절차는 유지한 채 일부 단계만 바꿔야 하는 문제. 이런 구조는 서로 다른 분야에서 계속 다른 모습으로 되풀이된다. 새로운 문제를 만났을 때 낯설게 느껴지는 이유는 재료가 낯설기 때문이지, 관계의 구조까지 매번 새로운 경우는 오히려 드물다.

그래서 디자인 패턴을 배운다는 것은 정답을 암기하는 일이 아니다. 눈앞의 새로운 문제가 이미 알고 있는 어떤 구조와 같은지를 알아보는 연습에 가깝다. 디자인 패턴은 천재들의 비밀 노트가 아니라, 여러 번 반복해서 나타난 구조를 사람들이 발견하고 이름 붙여 정리한 목록이다.

그런데 한 가지 궁금증이 남는다. 이렇게 반복되는 구조를 알아챘다면, 프로그래머는 그것을 매번 처음부터 다시 구현할까, 아니면 한 번 발견한 구조를 어딘가에 저장해 두고 필요할 때마다 꺼내 쓸까. 다음 화에서는 이 저장과 재사용이 어떤 방식으로 이루어지는지 살펴본다.