OOP: revisited #3

패러디의 작동원리

지금까지 OOP: revisited #1OOP: revisited #2를 통해 철학과 미학의 개념을 빌려와서 객체지향 프로그래밍을 되밟아보았다. 이번에는 패러디를 빌려와서 객체지향 프로그래밍을 되밟아보기로 한다.

다음 커뮤니케이션즈에서 제공하는 백과 서비스를 이용해 찾은 패러디에 대한 정의는 다음과 같다.

문학에서 특정 작가의 약점이나 특정 문학유파의 과도한 상투성을 강조해보이기 위해 그들의 문체나 수법을 흉내내는 일종의 풍자적 비평이나 익살스러운 조롱조의 글. via 다음백과

위의 정의는 문학에 한정지어서 이야기하고 있다. 하지만, 일상에서 알 수 있듯이 패러디는 본연의 의미/형태를 비틀어서 웃음을 유발한다. 패러디 과정에서 발생하는 비틈의 메커니즘은 상당히 흥미로운데, 기존의 작품에 존재하는 사건의 구성요소-이하 요소-들을 반전시키기도 하고, 요소간의 연결관계를 뒤집거나 전혀 엉뚱한 곳에 연결지어 의외성을 노리는 것이다. 그리고, 그 비틈의 경우 비틈을 수행하는 사람이 가진 의도에 따라 정치적 혹은 색다른 의미를 내포하게 된다.

골룸!
골룸!

한국에서 유명한 패러디인 골룸을 생각해보자. 조혜련씨나 안영미씨가 즐겨하는 이 골룸 패러디는, 골룸이 가진 역사성이나 배경은 무시하고, 절대반지에 대한 탐욕과 그 외모만을 뽑아내서 자신의 분장과 연결시킨 후에, 이를 개그코너 혹은 무대와 연결짓는다. 골룸이 등장한 순간, 사람들은 코미디언이 비틀어놓은 골룸에서 웃음을 짓는다. 생략, 변형, 연결. 이 3가지가 패러디 메커니즘의 핵심이라고 할 수 있다.

패러디는 단순히 흉내를 내는 것이 아니라 일련의 생략/변형/연결을 통한 재창조과정이다. 콜라주나 리메이크/커버와도 일맥상통한다. (사실 결과를 제외하고 메커니즘만 본다면 동일하다고 할 수 있다.) 중요한 사실은, 요소와 요소사이의 관계에 변형을 가해서 새로운 것을 만들어 낸다는 것이다.

디자인 패턴의 메커니즘

디자인 패턴은 OOP: revisited #2에서 설명한 바와 같이 관계의 모방이다. 그러나, 그 모방을 위한 메커니즘은 일반적인 모사라기 보단, 패러디의 모사에 가깝다. 현실세계의 실체를 모방하여 개념을 만들고, 그 개념사이의 연결관계도 현실세계의 연결관계를 모사하지만, 굉장한 생략과 비틈이 존재한다.

생각해보자, 우리가 흔히 사용하는 Factory패턴의 경우만 해도 실제 공장에서 존재하는 노동자나 수많은 기계들, 운반을 위한 시스템 같은 것들은 전부 생략된다. 그리고, 공장의 특성인 물건을 만들어내는 공간이란 특성만을 뽑아내어 이를 객체를 만들어내는 객체로 비틀어 개념화한다. 그리고, 이를 만들어야 하는 객체와 연결시킴으로써 Factory패턴을 완성한다. 생략, 비틈, 연결의 조합이 Factory패턴을 만들어 낸 것이다.

이처럼 디자인 패턴은, 현실에 존재하는 관계 혹은 실체에 대해서 생략, 비틈, 연결을 수행한다. 그리고, 대상이 현실에 익숙한 관계/실체 이기 때문에 프로그래머가 인식/이해하는데 훨씬 편하다. 디자인 패턴은 제목만 이해하면 된다. 제목을 이해했고 관계/실체가 익숙한 것이라면, 이해는 그냥 따라오기 마련이다. 마치, 패러디가 웃음을 유발하는 것처럼 말이다.

패러디 메커니즘의 의미

익숙한 것을 끌어와서 변형하여 사용하면 여러모로 유익한 점이 많다는 것은 자명하다. 이해하기 쉬운 코드를 작성하기 위해, 혹은 간결한 설계를 하기 위해 패러디의 메커니즘을 적극적으로 사용할 필요가 있다고 생각한다. 읽는 사람이 이미 잘 알고 있는 것을 끌어온다면, 설명은 더욱 쉬워지기 마련이니 말이다.

패러디 메커니즘을 가져오자는 것이 단순히 이름을 빌려오자는 것은 아니다. 충분히 생각하고, 그 이름에 걸맞는 행동을 하는 설계를 해야한다는 점이다. 그리고, 그 실제 관계나 실체에 얽매이지 않기 위해 생략, 비틈, 연결을 수행해야 한다. 프로그래머/설계자는 기억해야한다. 자신은 결코 그림을 그리는 것이 아니라, 소프트웨어를 작성하고 있는 것임을.

글쓴이: crowmania

Chief Developer in Somansa Guitar/Vocal in Tonics Member of Justice Party

“OOP: revisited #3”의 한가지 생각

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다