연결강도
OOP revisited: #3를 통해 패러디와 디자인 패턴, 설계사이에 어떤 관계를 설정할 수 있을지 생각해보았다. 헌데, 패러디는 다른 각도에서 또다른 접점을 갖는다. 바로 연결강도다.
패러디는 원작을 알고있어야 그 결과물을 이해할 수 있다. 만약 원작에 대해 모른다면, 아무리 잘 만든 패러디라고 해도 웃음짓기는 힘들 것이다. 예를 들어, 개그우먼 조혜련씨가 했던 ‘골룸’ 패러디를 생각해보자. 반지의 제왕을 알고 있는 사람 혹은 영화를 한번이라도 본 사람은 쉽게 ‘골룸’ 패러디에서 웃음코드를 찾아낼 수 있다. 사실, ‘골룸’을 몰라도 분장 자체가 웃겨서 웃길 수 있다. 그러나, 그 효과가 과연 같을까?
만약, 영화에서 비중이 그리 크지 않았던 메리같은 캐릭터를 패러디했다고 생각해보자. 과연 골룸만큼 널리 사람들을 웃길 수 있을까? 인지도나 임팩트 같은 개념으로도 설명할 수 있겠지만, 그것을 다 포괄하는 개념으로 연결강도를 이야기하고자 한다. 즉, 골룸이란 캐릭터와 반지의 제왕이란 작품사이의 연결강도는 메리같은 캐릭터보다 느슨했던 것이다. 반지의 제왕이란 작품에서 골룸을 떼어내서 변형을 가하는 것은 비중이 적은 캐릭터에 대해 같은 작업을 수행할때보다 더 쉽고, 더 효과적이다.
물론, 느슨하다는 것이 반지의 제왕이란 전체 작품에서 골룸이 차지하는 비중이 작다는 것이 아니다. 반지의 제왕에서 골룸이란 캐릭터를 끄집어 내는 작업이 수월하다는 것이다. 패러디의 입장에서 보면 연결강도가 느슨하면, 쉽고 효과적이다. 그리고, 이는 소프트웨어에서도 마찬가지다.
Loose coupling
Loose coupling이란 원칙은 패러디와 접점을 갖는다. OOP revisited: #3에서는 실세계-소프트웨어 간의 패러디를 이야기했지만, 여기에선 소프트웨어 내부의 패러디에 대해 이야기하고자 한다.
코드의 재사용성은 기존에 있던 코드를 다른 코드와 연결시키는 것으로 새로운 의미를 만들어낼 수 있을때 유효한 가치를 갖는다. 즉, 기존의 코드를 비틀어 새로운 소프트웨어를 만들어내는 작업이다. 역시, 패러디의 메커니즘에 영향을 받는다. 이런 점에서 볼 때, 패러디해야하는 코드에 골룸같은 독특하고 임팩트가 강한 개성적인 코드가 있는 것과 기억나지 않는 조연같은 코드가 있는 것은 천차만별이다. 그리고, 코드의 개성은 그 코드 묶음-클래스-이 어떤 역할을 수행하는가, 무엇을 나타내고 있는가에 의해 결정된다.
이 지점에서, 프로그래머는 예술가와 차이를 갖게된다. 예술가는 자신의 작품이 패러디 될 것이라 생각하지 않고 작업하지만, 프로그래머는 패러디를 예상해야 한다. 누군가가 -본인이 되었든, 후임이 되었든- 수정하고 싶어할지도 모른다. 그리고, 이 사실은 중요한 지점을 낳게 된다.
Software cannot be finished
물론, 소프트웨어는 끝나기 마련이다. 회사가 망하기도 하고, 수익이 더 이상 나지 않아서 제품을 없애기도 하고, 쓰는 사람이 없어서 자연스래 사장되기도 한다. 하지만, 개발하고 있는 순간에는 그 가능성을 잊어야한다. 소프트웨어는 지속적으로 변하는 생물과 같아서, 성장을 계속 주시하고 있어야 한다. 그리고, 그 성장을 지속적으로 준비해야 한다.
나는 얼마 전까지 이 성장을 컴포넌트의 집합으로 이해하고 있었고, 그게 얼마나 큰 실수였는지 깨달았다. 소프트웨어는 단순한 컴포넌트의 집합체가 아니다. 일반적인 인간사회에 더 가깝다. 각 컴포넌트들에게 최대한의 자유를 제공해야 한다. 미리 규정된 규칙에 따라 컴포넌트들이 연동하는 것이 아니라, 컴포넌트들이 자유롭게 서로를 사용하고, 서로에게 제공할 수 있어야 한다. 패러디를 예상한다는 것은 이런 상황을 제공한다는 것이기도 하고, 이런 상황에 대비하는 것이기도 하지만, 이렇게 생각하고 있어야 한다는 것을 의미한다.
기억하라. 프로그래머는 결코 자신이 만드는 소프트웨어를 완성할 수 없다. 다만, 잠시 쉴 뿐이고, 요구사항을 기다리거나 찾고 있을 뿐이다. 현명한 프로그래머라면, 항상 스스로를 패러디할 준비를 해야할 것이다.
