저자: 김대곤
정보의 바다라던 인터넷은 점점 쓰레기의 바다임이 경험적으로 증명되고 있는 듯하다. 만약 인터넷이 정말 알찬 정보의 바다라면 웹 서핑은 분명 즐거운 일임에 틀림없을 것이다. 그래서 그런지 요즘은 몇몇 사이트만 접속하고 그냥 브라우저를 닫을 때가 많다. 그런데 몇 주전에 필자의 관심을 끄는 단어들만의 집합으로 이루어진 기사제목을 보게 되었다.
Architectural Design Patterns for XML Documents라는 기사로, XML Schema를 어떻게 설계할 것인가에 대한 내용이었다. 하지만 필자가 찾는 내용은 아니었다. 필자는 XML 데이터 바인딩(Binding) API를 사용하는 몇 가지 패턴을 찾고 있었다.
하지만 여기에서도 필자의 시선을 끄는 점이 있었는데, 디자인 패턴들(Design Patterns)을 묘사 또는 설명하는 방식이 그랬다. Dynamic Document, Composition, Self Documenting Files, Multipart Files 패턴을 설명하는데 동일한 소제목들이 쓰이고 있었다. (Abstract, Problem, Context, Forces, Solution, Discussion, Related Patterns, Known Uses) 대부분의 원서에서는 몇 가지 다른 제목들이 있긴 하지만 비슷한 템플릿으로 패턴을 묘사한다. 직관적으로 의미가 전달되는 제목들도 있고 그렇지 못한 것들도 있었다.
패턴에 대한 정의 중에 가장 마음에 들고, 어쩌면 가장 짧은 것은 패턴을 “특정 상황에서 반복되어 일어나는 문제에 대한 해결책”으로 정의한 것이다. 여기서도 알 수 있듯이, 패턴을 묘사하는데 있어서 필수적인 요소는 특정상황(Context), 문제(Problem), 해결책(Solution)이다. 이러한 원칙은 Alexander의 책
『The Timeless Way of Building』 (Oxford University Press, 1979)에 제시된 것이다. 직관적으로 이해되지 않았던 Context는 반복적으로 일어나는 특정 상황인 셈이다.
이제 "개요(Abstract)"를 제외하고, "Problem", "Context", "Solution"을 제외하면, 남는 것은 “Forces”, “Discussion”, “Related Patterns”, “Known Uses”이다. 여기서 “Related Patterns”은 “See also”이라고도 하면 관련된 패턴에 대한 참조를 제공한다. 또한 “Known Uses"는 실제 예를 제공하지 않고 사용된 곳만 지칭한다는 면에선 다르긴 하지만 ”Examples"라고도 하며 패턴이 사용된 예를 말하는 것이다.
직관적으로 이해되는 2개를 빼면 “Forces", "Discussion"이 남는다. 먼저 “Forces"는 얼핏보면 장점/강점을 뜻하는 것으로 보인다. 그러나 순서에서도 알 수 있듯이(“Solution” 전에 “Forces”가 나와 있음) "Solution"의 장점이 아니라 해결해야 하는 문제점들의 세부적인 리스트, 패턴이 만족시켜야 하는 요구사항, 패턴 사용의 동기, 이유 정도로 이해할 수 있다. "Problem"이 “Forces"들이 종합적으로 묘사된 것이라고 할 수 있다. ”Discussion"은 단어 자체만으로는 정말 알기 힘든 용어인데, 패턴을 적용할 때 제약사항을 설명하는 단락이라고 할 수 있다.
XML 관련 기사에 나온 것 뿐 아니라 “Name(패턴의 이름)", "Classification(패턴의 분류, 예 Structural Pattern, Behavioral Pattern, Architectural Pattern)", 패턴에서 참여 객체들(participants)과 협력 객체(collaborators)의 역할과 관계, 구조 등을 설명하는 "Description"도 있다. 뿐만 아니라 다양한 템플릿에서 사용하는 표제어들이 있지만, 대부분의 책들은 자신이 쓴 템플릿에 대해 자체적인 설명을 가지고 있고, 기사에서 특별히 설명하지 않는 한 자신만의 표제어를 사용하지는 않을 것이다.
이러한 용어 설명이 패턴(Pattern)을 이해하는데, 그리고 패턴에 관한 기사 작성에 도움이 되기를 바란다.