웹이 아닌 앱의 시대가 오고있다.

이 글은 링크없는 블로그: 반쪽짜리 블로그에서 출발하여, @minoci님, @pariscom님과의 대화를 통해 발전해서 쓰여졌습니다. 두 분께 감사드립니다. 🙂

웹은 HTTP프로토콜을 기반으로 HTML을 통한 유연한 링크를 이용해 정보사이의 소통이 가능한 길을 열었고, 이는 블로그와 위키를 만나면서 새로운 소통의 시대를 열었다고 해도 과언이 아니다. 하지만, 이 소통의 시대는 현대사회가 아직도 풀지 못하고 있는 장벽에 가로막혔다. 지정학적 혹은 정치학적 요인에 의해 갈라진 국가라는 개념이 인간사이를 막고 있는 것처럼, 이 소통의 시대는 호스트(서비스업체)라는 장벽에 가로막혀 버렸다. 무서울 정도로 국가의 개념과 호스트의 현실은 연계되는데, 현실세계에서 국가의 힘이 결국 국민의 수에 의존하는 것과 마찬가지로 호스트의 가치는 사용자의 수에 의존한다. 또한, 이민을 막는 최종적 발목이 인간관계라는 점을 비추어보아도, 웹에서 유사하게 작동한다. 호스트를 이동하는 것은 존재하던 관계를 버리고 새로운 관계를 생성해야 함을 의미한다. 게다가, 각 호스트에 모인 사람들의 특성은 국가가 제시하는 민족주의와 유사하게 사람들 사이의 집단의식을 이끌어낸다. 인간이 국가라는 틀에 갖혀있는 것처럼, 호스트 속에 갖혀버린다.

올블로그나 블로그코리아 같은 메타업체들이 힘을 쓰지 못하는 것도 마찬가지의 이유다. 대다수의 사람들은 외국과 교류하지 않는다. 지정학적으로 가까운 사람들과 소통하기 마련이며, 다른 문화의 사람들에게 배타적인 심리를 갖기도 한다. 호스트도 마찬가지다. 대다수의 웹이용자들은 자신이 사용하는 호스트내에서 제공하는 아쉬울 것 없는 기능들을 이용하여, 자신의 주변을 만들어간다. 저 멀리에 있는 다른 호스트로 찾아가서 애써 관계를 만들 이유는 없는 것이다.

초창기의 블로고스피어를 생각해보면, 이는 더욱 자명하다. 초창기의 호스트들은 사람들이 원하는 소통량을 달성할 만큼 이용자수를 갖고 있지 못했다. 따라서, 다른 호스트에 있는 사용자들과 소통할 필요를 느꼈고, 메타사이트의 출범과 함께 블로고스피어는 빅뱅을 맞이하는 듯 했다. 하지만, 이용자수가 증가하고 각각의 호스트들 내에서 원하는 소통량을 달성하게 된 사용자들은 점점 메타사이트에 가야할 이유를 잃었다. 이것이 이 블로그의 트래픽유입이 대부분 검색엔진과 RSS리더가 된 이유일 것이다.

하지만, 웹은 RSS/ATOM의 등장과 웹서비스의 발명을 통해 기능을 외부로 노출하는 가능성을 맞이한다. 일종의 국제협약이 생긴 것이다. 페이지를 표현presentation중심이 아닌 의미content중심으로 바라볼 수 있다는 가능성은, 웹을 기반으로 컨텐츠간의 융합을 가능케 했다. 하지만, 여전히 대다수의 사람들은 이 협약을 사용할 필요성을 느끼지 못한다. 여전히 그들은 만족하고 있으므로.

하지만, 쓰기 힘든 글을 기반으로 하는 블로그를 위시한 출판개념의 기존의 웹은 SNS를 맞이하며 변화를 시작한다. 고정된 의미가 아닌 흐르는 소통을 기반으로 하는 SNS들은 웹에서 발명된 것들을 차용하며, 서비스간의 교차점을 만들어냈다. 대표적인 사례가 Twitter인데, Twitter는 이미 플랫폼이란 이야기가 나올 정도로 수많은 파생물을 만들며 지금 이 시간에도 변화하고 있다. 정치적 위치와 물리적 한계가 소통을 제약하는 현실세계와는 달리 SNS는 기민함과 익명성을 무기로 소통의 흐름을 가속화하고 있다. SNS는 기존의 웹을 백엔드화 하고 있으며, 이러한 경향은 지속될 것으로 생각된다.

이런 긍정적인 변화에도 불구하고, SNS역시 국가란 개념에서 벗어나기는 힘들다. Twitter, 페이스북, 미투데이, 싸이월드 등의 SNS서비스들은 이전의 웹보다는 나아졌지만, 여전히 호스트라는 장벽에서 벗어나고 있지 못하다. 여기에서 가능성을 하나 찾을 수 있다면, 이전의 웹이 브라우져에 기반하여 제약되고 있었다면, 현대의 웹은 RSS와 웹서비스를 이용한 기능의 노출을 이용해 브라우져가 아닌 앱으로 이용이 가능해지고 있다는 사실이다. 모바일 정보처리장치들의 발전과 궤를 같이하는 것이지만, 단지 그것만은 아니다. 웹에서는 구현하기 어려운 것들이 앱에서는 손쉽게 구현이 가능하다. 실제로 웹이란 인터페이스상에서는 단순한 동기화만 가능하지만, 앱을 이용하게 되면 여러 호스트 사이의 유기적인 통합이 가능하다. FacebookTwitter를 통합한 TweetDeck이 좋은 사례가 될 것이다. (비록 현 시점에서는 좀 단순한 형태이긴 하지만)

블로그의 출현이 만들어내고 SNS가 가속화하고 있는 RSS/ATOM와 웹서비스, 그리고 이를 잘 활용하여 유기적인 형태로 만들어지고 있는 앱. SNS가 더 널리 사용되고 지속적인 발전을 하게 된다면, 이에 따라 앱 역시 발전하게 될 것이다. 그리고, SNS사이의 표준적인 -dejure이든 defacto이든- 프로토콜이 성립한다면, 웹브라우져는 의미의 지반을 보는 뷰어의 역할을 하게 되고 앱은 그 지반들을 이어주는 소통의 혈관이 될 것이다. 그리고, 모바일의 발전은 소통의 순간을 키보드에서 독립시킬 것이다. 아니, 이미 독립 시키고 있다. 이러한 것들이 서로 만나면서, 결국 국가란 개념이 웹에 뿌리내린 호스트라는 현상은 소통을 제약하지 못하게 될 것이다.

물론, 이 글이 옛날에 쓰여진 허무맹랑한 소설이 될 가능성이 없는 것은 아니다. 하지만, 빅브라더가 이미 현실로 다가온 이 시점에서 정보기술이 사람들의 소통을 억압하는 것이 아니라 이를 가속화했으면 좋겠다는 작은 희망에서 출발한 생각이므로 이대로 되었으면 좋겠다. 물론, 소통이 발전하는 만큼 감시도 발전하겠지만.

ps1. 확정형의 표현을 피하는 편이지만, 왠지 오늘은 피할 길이 없다.
ps2. 여러분은 지금 마이크로네이션에서 글을 읽고 계시고, 저는 텀블러에 대사관을 건설한 게 되는군요. 으응?!
ps3. 이 참에 다른데도 대사관을 세워볼까.. (참앗!)

애플의 폐쇄구조

컴퓨터 하드웨어와 OS를 동시에 만드는 회사는 그리 흔하지 않다. 기억하기로는 애플, Sun, HP, SGI, IBM 정도 일텐데, 각자 특징을 가지고 있다. 이 와중에서, 폐쇄적인 설계구조로 욕먹는 회사는 아마 애플뿐이리라 생각된다. Sun의 Solaris는 x86계열의 CPU(특히, 옵테론)을 적용하기 위해 x86으로 포팅된게 아닌가 싶을 정도로 자사 플랫폼에서만 사용되던 OS였고, HP의 HP-UX나 IBM의 AIX등은 아예 자사 하드웨어 플랫폼에서만 돌아간다. (고 알고있다.)

애플의 폐쇄구조를 가지고 수많은 이야기들이 오고가지만, Mac OS의 핵심부분인 Kernel이 공개되어있다는 사실은 아는지 모르겠다. 2000년경 Darwin이란 이름으로 공개가 되었으며, 해킨토시(Mac OS X을 일반 PC에서 돌리기 위한 일련의 작업들)에서 많이 사용되는 부두커널같은 녀석도 결국은 Darwin의 소스코드를 이용하여 특정 플랫폼에 맞게 작업하는 것으로 알고 있다. 물론, Quartz나 Cocoa같은 커널 위에 올라가는 다른 부분들은 공개되지 않지만, 의외로 애플에서 공개적으로 개발하는 것은 많다.

현대 컴퓨팅 환경에서 가장 중요한 컴포넌트라면 웹브라우저의 렌더링엔진을 꼽을 수 있다. 애플의 Safari에서 사용하는 엔진은 WebKit인데, KDE 프로젝트에서 진행하던 KHTML+KJS 프로젝트의 분기branch로 시작한 공개 프로젝트다. WebKit Team에 가보면, 애플과 구글의 개발자들이 참가하고 있는 것을 알 수 있다. 반면, 전통적으로 소프트웨어 개발에서 가장 중요한 컴포넌트라면 소스코드를 번역하여 기계어 코드를 생산하는 컴파일러를 꼽을 수 있다. 애플은 주목받고 있는 오픈소스인 LLVM 프로젝트에 투자하고 있다. 역시, LLVM Developers를 살펴보면, (WebKit처럼 잘 나와있지는 않지만) 애플의 개발자가 있음을 알 수 있다.

물론, 이러한 사항들이 애플이 갖고 있는 폐쇄적인 구조에 대한 변명거리가 될 수는 없다. 하지만, 애플을 컴퓨터 제조업체가 아닌 가전제품 업체로 놓고 생각한다면, 이야기는 좀 달라진다. 삼성이나 LG가 자신들의 제품에 대해서 공개하는 범위와 애플이 자신들의 제품에 대해 공개하는 범위를 놓고 보면 답이 나온다. 휴대폰만 봐도 그렇다. 애플의 휴대폰에서 작동하는 소프트웨어를 만드는 것과 삼성이나 LG의 휴대폰에서 작동하는 소프트웨어를 만드는 것을 비교해보면 자명하다. 삼성이나 LG에는 공개된 SDK가 없다. 게다가, 이들이 공개적으로 개발하는 것도 없다. 그 내부에서 무엇이 일어나고 있는지는 아무도 모른다.

애플의 폐쇄적인 구조에 대한 비판은 Mac의 경우, 보통 성능에 비해 비싼 가격에서 출발하는데, 조립컴퓨터를 사용하던 사람들의 이야기가 아닐까 생각된다. 잘 구성된 하드웨어 위에 그 하드웨어의 성능을 잘 뽑아내는 OS를 얹고, 더불어 그 둘 사이가 잘 연계되어 별 문제없이 (즉, 하드웨어와 OS의 연계에 뇌를 낭비하지 않고) 쓸 수 있는 컴퓨터가 있다면, 성능은 기본만 해주면 크게 문제될 영역은 아니다. 남은 영역은 가격인데, 가격면에서 본다 하더라도 그렇게 많이 비싼편은 아니다. 안정적인 하드웨어 구성과 OS와의 연계에서 오는 장점을 생각해본다면, 사실 이득을 본다고 할 수 있다. 물론, 일반적으로 Windows를 사용하는 PC들에게서 얻은 복잡한 세팅문제에서 출발하는 이야기일 것이다. 하지만, 생각해보자. TV나 DVD 플레이어를 구입하고 세팅에 신경쓰는 사람은 없다. 컴퓨터도 매한가지 아닐까? Let me free. 그냥 컴퓨터로 할 일을 하게 해달라.

연장선상에서 컴퓨터를 별세계의 이야기로 두지 않고, 그냥 가전제품이란 관점에서 보면, 삼성이나 LG가 불법복제 생산품들을 막으려고 애쓰는거나 별반 다를게 없다. 삼성이나 LG가 휴대폰이나 TV같은 제품들의 내부구조나 소프트웨어를 공개하지 않듯이, 애플도 마찬가지다. 그리고, Mac OS X은 애플입장에서는 자사의 제품들에서 작동시키기 위한 OS이지 소프트웨어로 판매하기 위한 OS는 아니다. 게다가, Mac OS X을 공개하거나 다른 플랫폼에 설치할 수 있도록 개방하게 된다면, 애플입장에서는 거기서 발생하는 수익보다 그걸 유지하기 위해서 들어가야하는 비용이 훨씬 커지기 마련이다. MS의 Hardware Compatibility Lab을 생각해보라. 생각만해도 머리아프다.

그리고, 최근에 애플의 폐쇄구조에 대한 이야기가 나오면, iTunes App Store에 대한 이야기가 따라나오기 마련이다. 허나, App Store가 폐쇄적이라는 이야기에 대해서는 동감하지 못하겠다. 애시당초 전혀 다른 Platform이다. 그러니까, 천문학적으로 말하자면 전혀 다른 행성이고, 생물학적으로 말하자면 전혀 다른 생태계다. 애시당초, 스마트폰이 무엇인지도 애매하다. 그리고, 클릭 몇번으로 소프트웨어를 찾아서 다운로드 받는 건, 기존의 휴대폰에도 있던 기능이다. 그 제어 권한이 통신사에서 애플로 넘어갔다는게 첫번째 차이이고, 개발자-컨텐츠 제공자-의 범위가 일반 개발자에게까지 확대 되었다는 점이 두번째 차이이다. 애플의 관리하에 있다는 것이 폐쇄적이란 이야기로 이어지는 것은 어불성설이다. 권한이 바뀌고, 영역이 넓어졌을 뿐이다. Auction이나 G마켓도 폐쇄적이란 말인가?

결론적으로 보자면, 가전업체로서의 애플은 생각보다 그리 폐쇄적이지 않고, 생각보다 많이 공개되어 있고, 개방되어 있다. 그렇다고 애플의 단점이 없는 것은 아니다. 하드웨어와 소프트웨어의 통합이라는 강점을 이용해 소비가전시장에서 돌풍을 일으켜 온 애플이지만, 하드웨어와 소프트웨어를 둘 다 한다는 것은 결국 양쪽에서 모두 경쟁해야 한다는 점이다. 현재는 연합전선의 형태로 단일전선을 유지하지만, 하드웨어 전선과 소프트웨어 전선이 분리되는 순간 애플의 위기는 다가오지 않을까 생각한다. 물론, 애플의 가장 큰 위기는 잡스의 건강이겠지만.

pipe-plant: blendmix

요즘, 트위터, 미투데이, 텀블러, 이 블로그까지 사용하는 네트워크 서비스가 무려 4개가 되었다. -_-; 그런 관계로 뭔가 연동을 시켰으면 하는데.. 그래서, 사용하기로 마음먹은게 프렌드피드를 이용해서 미투데이와 트위터를 연동하는 거였다. (결국 미투데이는 뺐다. 트위터 사람들이 별로 안좋아한데서..)

프렌드피드를 쓰다보니 참 괜찮긴 했는데. 이게, input은 여러종류를 받는데 (rss부터 각종 SNS서비스들) output이 프렌드피드와 트위터만 된다는 단점이 있다. 사실 지금 하고 싶은 작업은 다음과 같다.

  • 텀블러나 블로그에 새 글을 쓰면 미투데이와 트위터로 링크를 담아서 전송
  • 트위터에서 reply를 제외한 트윗을 미투데이로 전송

뭐, 이 외에도 많은 연결작업이 가능할 거다. 그래서 든 생각이.. 각 사이트들의 RSS를 이용해서 input을 받은 다음에 모종의 filter들을 연결시키고 나온 결과를 output으로 보내는 거다. 각각의 input과 output은 당연히 사이트별 혹은 필요에 따라 모듈화가 이루어져야 할거고, 데이터를 일반화 시켜서 가운데에서 사용하는 filter들은 자연스럽게 재사용이 가능해야 한다.

이런 연결기반의 작업을 위한 구조는 지금 회사일로 사용하고 있는 컨셉인 pipe-plant구조가 제격인데, 각각의 plant(모듈)이 pipe를 이용해 동적으로 연결되고 구성될 수 있기 때문에 적당한 UI만 받쳐주면 꽤나 쓸만할 것 같다. – 해봐야 알겠지만 –

비슷한 처리를 하고 있는게, 야후! 파이프인데, 이건 RSS를 받아서 RSS로만 나온다는 문제점이 있다. UI자체는 좋은데 – 사실 Quartz Composer와 거의 유사하다. – 참 아쉬움.

그런고로, 하나쯤 있었으면 좋겠다는게 생겼다. 언제할진 모르지만. 🙂

OOP: revisited #4

연결강도

OOP revisited: #3를 통해 패러디와 디자인 패턴, 설계사이에 어떤 관계를 설정할 수 있을지 생각해보았다. 헌데, 패러디는 다른 각도에서 또다른 접점을 갖는다. 바로 연결강도다.

패러디는 원작을 알고있어야 그 결과물을 이해할 수 있다. 만약 원작에 대해 모른다면, 아무리 잘 만든 패러디라고 해도 웃음짓기는 힘들 것이다. 예를 들어, 개그우먼 조혜련씨가 했던 ‘골룸’ 패러디를 생각해보자. 반지의 제왕을 알고 있는 사람 혹은 영화를 한번이라도 본 사람은 쉽게 ‘골룸’ 패러디에서 웃음코드를 찾아낼 수 있다. 사실, ‘골룸’을 몰라도 분장 자체가 웃겨서 웃길 수 있다. 그러나, 그 효과가 과연 같을까?

골룸!
다시 등장하신 골룸사마!

만약, 영화에서 비중이 그리 크지 않았던 메리같은 캐릭터를 패러디했다고 생각해보자. 과연 골룸만큼 널리 사람들을 웃길 수 있을까? 인지도나 임팩트 같은 개념으로도 설명할 수 있겠지만, 그것을 다 포괄하는 개념으로 연결강도를 이야기하고자 한다. 즉, 골룸이란 캐릭터와 반지의 제왕이란 작품사이의 연결강도는 메리같은 캐릭터보다 느슨했던 것이다. 반지의 제왕이란 작품에서 골룸을 떼어내서 변형을 가하는 것은 비중이 적은 캐릭터에 대해 같은 작업을 수행할때보다 더 쉽고, 더 효과적이다.

물론, 느슨하다는 것이 반지의 제왕이란 전체 작품에서 골룸이 차지하는 비중이 작다는 것이 아니다. 반지의 제왕에서 골룸이란 캐릭터를 끄집어 내는 작업이 수월하다는 것이다. 패러디의 입장에서 보면 연결강도가 느슨하면, 쉽고 효과적이다. 그리고, 이는 소프트웨어에서도 마찬가지다.

Loose coupling

Loose coupling이란 원칙은 패러디와 접점을 갖는다. OOP revisited: #3에서는 실세계-소프트웨어 간의 패러디를 이야기했지만, 여기에선 소프트웨어 내부의 패러디에 대해 이야기하고자 한다.

코드의 재사용성은 기존에 있던 코드를 다른 코드와 연결시키는 것으로 새로운 의미를 만들어낼 수 있을때 유효한 가치를 갖는다. 즉, 기존의 코드를 비틀어 새로운 소프트웨어를 만들어내는 작업이다. 역시, 패러디의 메커니즘에 영향을 받는다. 이런 점에서 볼 때, 패러디해야하는 코드에 골룸같은 독특하고 임팩트가 강한 개성적인 코드가 있는 것과 기억나지 않는 조연같은 코드가 있는 것은 천차만별이다. 그리고, 코드의 개성은 그 코드 묶음-클래스-이 어떤 역할을 수행하는가, 무엇을 나타내고 있는가에 의해 결정된다.

이 지점에서, 프로그래머는 예술가와 차이를 갖게된다. 예술가는 자신의 작품이 패러디 될 것이라 생각하지 않고 작업하지만, 프로그래머는 패러디를 예상해야 한다. 누군가가 -본인이 되었든, 후임이 되었든- 수정하고 싶어할지도 모른다. 그리고, 이 사실은 중요한 지점을 낳게 된다.

Software cannot be finished

물론, 소프트웨어는 끝나기 마련이다. 회사가 망하기도 하고, 수익이 더 이상 나지 않아서 제품을 없애기도 하고, 쓰는 사람이 없어서 자연스래 사장되기도 한다. 하지만, 개발하고 있는 순간에는 그 가능성을 잊어야한다. 소프트웨어는 지속적으로 변하는 생물과 같아서, 성장을 계속 주시하고 있어야 한다. 그리고, 그 성장을 지속적으로 준비해야 한다.

나는 얼마 전까지 이 성장을 컴포넌트의 집합으로 이해하고 있었고, 그게 얼마나 큰 실수였는지 깨달았다. 소프트웨어는 단순한 컴포넌트의 집합체가 아니다. 일반적인 인간사회에 더 가깝다. 각 컴포넌트들에게 최대한의 자유를 제공해야 한다. 미리 규정된 규칙에 따라 컴포넌트들이 연동하는 것이 아니라, 컴포넌트들이 자유롭게 서로를 사용하고, 서로에게 제공할 수 있어야 한다. 패러디를 예상한다는 것은 이런 상황을 제공한다는 것이기도 하고, 이런 상황에 대비하는 것이기도 하지만, 이렇게 생각하고 있어야 한다는 것을 의미한다.

기억하라. 프로그래머는 결코 자신이 만드는 소프트웨어를 완성할 수 없다. 다만, 잠시 쉴 뿐이고, 요구사항을 기다리거나 찾고 있을 뿐이다. 현명한 프로그래머라면, 항상 스스로를 패러디할 준비를 해야할 것이다.

OOP: revisited #3

패러디의 작동원리

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

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

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

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

골룸!
골룸!

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

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

디자인 패턴의 메커니즘

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

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

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

패러디 메커니즘의 의미

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

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

OOP: revisited #2

OOP: revisited #1를 통해서 이야기했던 내용을 정리하면 다음과 같다.

객체지향의 핵심은 ‘추상화’

문제는 이 추상화라는 것이 자연스러운 것이긴 한데, 쉬운 것은 아니라는 점이다. 그리고, 문제가 복잡해지기 시작하면 실제 세계를 모델링해서 나온 객체 이외에 다른 종류의 객체들이 필요해진다. 인간이 실제 세계를 파악하는데 있어서 실제 사물들을 추상화한 개념concept만 사용하는 것은 아니기 때문이다. 굉장히 거칠게 말하면, 개념들을 연결하는 개념이 추가적으로 필요하기 마련이다. 집합, 접속사, 거리, 대화, 연결 등등 수많은 개념들이 실제 사물에서 파생된 개념이 아닌 개념과 개념을 연결해주는 역할을 한다. 이 개념들은 실제세계의 관계에 기반하기도 하지만, 재미있게도 사물의 기능에 기반하기도 한다. 연애소설에나 나올 법한 표현이지만, 사람사이의 관계를 ‘다리’라고 표현하는 경우가 있다. 이는 다리가 갖는 ‘연결’이라는 기능에 기반해서 의미를 포획하는 경우로 볼 수 있다.

디자인 패턴은 관계의 모방

객체지향 프로그래밍을 실제세계의 모방mimesis이란 관점에서 생각해보면, 자연스럽게 위와 같은 의미포획이 수행되리라는 사실을 짐작할 수 있다. 개념에 해당하는 객체를 만드는 것 뿐만 아니라, 그 객체들의 연결관계를 개념화하여 활용한다. 이런 류의 움직임을 가장 잘 포착할 수 있는 결과물은 ‘디자인 패턴’이다. ‘디자인 패턴’은 객체지향 소프트웨어를 작성하면서 자주 등장하는 패턴을 정리해둔 것인데, 널리 알려진 디자인 패턴들은 팩토리factory, 비지터visitor, 옵저버observer 등 실제세계에 존재하는 관계들의 ‘연결’을 모방하고 있다. 이미 디자인 패턴이란 말 자체에 객체간의 구성관계라는 의미를 내포하고 있다.

객체지향은 모방에서 출발하며, 그 모방은 범주를 가리지 않는다.

객체지향의 핵심이라고 지칭했던 ‘추상화’를 생각해보자. 추상화과정을 거쳐 프로그래머가 얻어낸 개념, 즉 클래스는 무엇일까? 실제세계의 객체를 반영하고 있는 것이겠지만, 과연 완벽한 “투사”의 결과물인가? 아니면 적당히 왜곡된 “모방”의 결과물인가? 아마, 투사의 결과물이라고 말할 수 있는 사람은 드물 것이다. 프로그래머가 작성한 클래스는 소프트웨어 시스템에서 필요한 만큼만 특징을 추출해서 만든 “모방”의 결과물이기 때문이다.

이처럼, 객체지향 프로그래밍은 거의 모든 부분에 있어서 -그 핵심인 ‘추상화’마저도- 모방을 실행한다. 그리고, 객체지향 프로그래밍 외부의 것을 모방할 뿐만 아니라, 그 내부의 것도 모방한다. 디자인 패턴을 활용하는 행위조차 디자인 패턴을 모방하여 자신의 코드를 작성하는 모방행위를 벗어나지 못한다. 이렇게 이야기하면 창의성이 없는 행위처럼 보일 수 있겠지만, 주어진 상황과 기존의 해법을 연결시키는 모방자체가 창의적인 행동이라고 보아야할 것이다. 디자인 패턴을 적용해보면 알겠지만, 종종 원래 패턴의 의미를 왜곡시켜 적용해야할 경우도 많다. 모방은 투사가 아니기 때문이다.

그리고, 이 모방들이 모여 결국은 소프트웨어란 이름의 세상을 만든다.

모방의 의미와 프로그래밍의 재미

이 글을 읽으시면서, 아마 눈치채신 분들도 있으리라 생각되지만, 핵심 개념인 모방은 미학에서 빌려온 개념이다. 그리고, 미학은 예술을 다룬다. 모방은 객체지향 프로그래밍을 가득 채우고 있다. 이 관점을 따라간다면, 객체지향 프로그래밍은 일종의 예술로 읽힐 수 있다. 실제로 그런 속성을 많이 가지고 있는 것도 사실이다. 하지만, 객체지향 프로그래밍에는 감정을 찾아볼 수 없다. 단지, 프로그래머의 이성적인 논리만 코드사이를 질주할 뿐이다. 따라서, 예술이라고 생각하는 것은 힘들지 않을까 싶다.

미학에서 빌려온 모방이 의미를 갖는 곳은 예술과 객체지향 프로그래밍의 접점이다. 이 접점은 철학과 객체지향 프로그래밍의 접점과 연결되면서, 화학적 결합을 낳는다. 객체지향 프로그래밍은 예술도 아니고 철학도 아니지만, 그 둘과 닮아있다. 이 오묘한 결합이 객체지향 프로그래밍이 재미있는 이유가 아닐까싶다.

예술가가 세상을 느끼고, 철학자가 세상을 판단한다면, 프로그래머는 세상을 만든다.

.. 이후는 패러디와 함께 다음 기회에 ..

OOP: revisited #1

프로그래밍이란 무엇일까? 이 질문에 답하는 것은 당황스러운 일이지만, 답은 매우 간단하다.

소프트웨어를 작성하는 것.

그렇다면, 소프트웨어를 작성하는 것은 무엇을 의미하는 것일까? 이 질문에 답하는 것은 어려운 일이지만, 내가 내린 답은 다음과 같다.

실세계에 존재하는 시스템을 모방하여 이를 컴퓨터 시스템위에서 구동시키는 일련의 과정

다시 한번! 그렇다면, 소프트웨어란 무엇일까?

소프트웨어는 당연히 하드웨어의 작동방식일테지만, 소프트웨어를 어떤 식으로 해부하느냐 혹은 바라보느냐(즉, 어떻게 모방하느냐)에 따라 그 패러다임은 심하게 달라질 수 있다. 그리고, 그 패러다임은 소프트웨어의 설계 및 구현은 설계에서 유지보수까지 소프트웨어 생명주기에 막대한 영향을 미치곤 한다.

패러다임을 이해하기 위해 그림 명화 두장을 준비했다. 왠 뜬금없는 미술이야기냐 라고 불평하실 분도 계시겠지만, 모방mimesis을 가장 극명하게 표현해내는 예술이 미술이므로 가져온 것이다. 일단 그림을 보면서 이야기해보자.

Las Meninas by Velazquez
Las Meninas by Velazquez

왼쪽의 그림은 디에고 벨라스케스Diego Rodríguez의 “시녀들”이라는 작품이다. 이 그림에 대한 자세한 내용은 위키백과를 통해서 확인하실수 있다.

1656년에 완성된 작품으로, 이 시기의 미술화풍을 잘 반영이라도 하듯 섬세한 표현이 두드러진다. 이 작품 내부에는 해석할만한 텍스트가 넘쳐나는 재미있는 작품이지만, 우리가 지금 이 작품에서 읽어야 할 것은 “텍스트”가 아니라 화풍이므로 자세한 것은 잊고 넘어가자.

Las Meninas - Picasso
Las Meninas - Picasso

오른쪽의 작품은 파블로 피카소 Pablo Picasso의 “시녀들”이다. 1957년에 그린 연작중 하나를 가져왔다. 흥미로운 점은 위의 “시녀들”을 파블로 피카소가 재해석해서 그린 그림이라는 점이다. 벨라스케스의 그림과는 엄청난 차이를 보인다. 이 차이는 어디에서 오는 것일까?

비록 벨라스케스의 시녀들을 보고 그린 그림이지만, 같은 이미지를 두고 두 사람의 해석이 다르다는 점을 알 수 있다. 사실, 같은 물건을 보고 그린 두 화가의 그림(사조도 다른!)을 비교하는 것이 가장 좋겠지만, 이 두 그림을 가지고도 충분히 모방에 있어서 사람의 생각 혹은 패러다임이 얼마나 작용하는지를 보여주는 사례라고 볼 수 있다.

그리고, 미술에서 나타나는 이 차이는 소프트웨어의 세계에도 그대로 적용된다.

미술의 사조가 화가가 받아들인 이미지를 어떤 식으로 그려내는가에 중점이 있다면, 프로그래밍의 패러다임은 프로그래머가 소프트웨어를 구성하는 기본 단위와 그 구성방식을 무엇으로 생각하느냐에 중점이 있다고 할 수 있다. 미술에 인상파, 고전주의, 낭만주의, 사실주의, 입체파, 추상파, 다다이즘등의 수많은 사조가 있다면, 프로그래밍에는 순차적 프로그래밍Procedual Programming, 객체지향 프로그래밍Object-Oriented Programming, 함수 프로그래밍Functional Programming, 관점지향 프로그래밍Aspect-Oriented Programming등이 존재한다.

순차적 프로그래밍은 소프트웨어를 일종의 시방서로 보는 패러다임으로 인간에 대한 배려보다는 컴퓨터라는 하드웨어를 어떻게 작동시킬 것인가에 초점을 맞추고 있다. (일반적인) C언어가 대표적인 사례라고 할 수 있으며, 대부분의 OS커널에서 제공하는 시스템 콜들이 이 패러다임을 따르고 있다. OS커널에서 제공하는 시스템 콜들을 기준으로 생각해본다면, 시스템 전체를 어찌 구성할 것인가 보다는, 하드웨어/커널이 가진 기능의 리스트에 가깝다. 또한, 하드웨어가 할 수 있는 일들을 목록으로 작성하고, 그 목록에 있는 일들을 어떤 순서로 실행할 것인가에 초점을 맞추고 있다.

함수 프로그래밍은 (수학적인) 함수들의 연결관계로 소프트웨어를 작성하는 방법론이다. 굉장히 유연하고, 직관적인 프로그래밍 방식이지만 인간이 기본적으로 세상을 인식하는 방식과는 차이가 있으며, 특수한 분야에서만 주로 사용되는 결과를 낳았다. 개인적으로는 상당히 관심이 가는 분야이며, 함수 프로그래밍분야에서 등장한 functor(함수자)의 개념은 C++에 도입되어 tr1::function과 같은 템플릿을 낳기도 하였으며, LISP나 scheme등의 언어적 기능들은 다른 객체지향 언어에 지대한 영향을 주었다.

마지막으로 오늘의 주제인 객체지향 프로그래밍이 있다. 객체지향 프로그래밍은 소프트웨어를 상태와 행동으로 정의되는 객체들의 상호연동을 이용해 소프트웨어를 표현한다. 객체지향 프로그래밍이 널리 사용되는 이유는 다름이 아니라, 객체지향 프로그래밍 패러다임이 제공하는 생각의 방식이 인간의 기본적인 사고방식과 유사하기 때문이다. 그리고, 그 유사성의 핵심은 추상화abstraction에 있다.

철학의 주제 중 하나인 인식론에서 그 유래를 찾아볼 수 있는 추상화는 다음과 같이 정리할 수 있다.

  1. 세상의 모든 사물은 다르다. 서로 같은 것은 존재하지 않는다.
  2. 그럼에도 인간은 사물을 구분짓는다. (Classification)
  3. 즉, 인간은 각 사물이 존재하는 공통된 성분을 추출하여 이를 토대로 세상을 인식한다.

이렇게 정리해놓으면 알쏭달쏭하지만, 쉽게보면 다음과 같다.

네모 두개

위의 그림을 놓고 “저 둘은 뭐죠?” 라는 질문을 던진다면, 보통 “네모 두개” 혹은 “직사각형 두개”라는 답변이 나올 것이다. 크기도 다르고 색깔도 다르지만, 자연스럽게 두 도형의 공통된 특징을 추출하여 개념화하는 것이다. 이 과정이 인식론적 추상화의 시작점이다. 인식론 혹은 일반철학에서 이런 추상화의 결과로 나온 것을 흔히 개념concept이라고 부른다. 실제 사물이 인식되어 인간의 사고속에 담겨지는 그 “무언가”를 개념이라고 호칭한다. 물론, 이 개념은 실제 사물과 연결되는 것도 있고, 아닌 것도 있지만 이 글에서 논하는 것은 범주를 넘어서므로 딱히 논하지는 않겠다.

객체지향 프로그래밍은 이 추상화의 과정을 거쳐 생성된 개념들을 코드로 옮긴다. 이때 작성된 코드가 객체의 설계도라고 볼 수 있는 클래스class인지, 아니면 객체의 첫 상태라고 볼 수 있는 프로토타입prototype인지에 따라 세부적인 형태는 달라질 수 있겠지만, 어쨌든 개념을 코드로 옮긴다는 점에서는 동일하다고 볼 수 있다.

다시 살짝 인식론으로 돌아가서 본다면, 인간이 하는 일이 사물을 통해 개념을 만들어내는 추상화의 작업만 있는 것은 아니다. 알고 있는 개념을 이용해 그에 부합하는 사물을 만들어내거나 모사하는 구체화의 작업도 존재한다. 객체지향 프로그래밍에서는 이 과정이 코드 실행단계라고 이야기할 수 있다. 코드로 옮겨진 개념들이 컴퓨터라는 기계를 통해 실행되면서, 실제로 객체가 생성되고 상호작용을 시작하는 것이다. 그리고, 이 상호작용을 통해 프로그래머의 의도를 표현하게 된다.

물론, 인간이 추상화를 어떤 방식으로 수행하는지와 그 결과물인 개념이 어떤 구성요소로 이루어져 있는지에 관해서는 이견이 많을 수 있겠지만, 객체지향 프로그래밍에서는 명확하게 정의되어 있다. 객체는 상태와 행위로 구성된다. 따라서, 그 객체를 개념화한 클래스 혹은 프로토타입 역시 상태와 행위로 구성된다. 이론적으로 본다면, 객체지향 프로그래밍 패러다임은 인간의 자연스러운 추상화에 의해 생성된 개념을 코드라는 형태로 써내려가기만 하면 손쉽고 자연스러운 소프트웨어 작성을 도모할 수 있다.

이론은 어디까지나 이론이다. 인간이 생각해낸 개념을 상태와 행위로 구성되는 개념만으로 표현이 힘든 것도 있거니와, A라는 프로그래머가 만든 개념이 불필요하게 복잡하고 이해하기 어려운 형태일 수도 있고, 또는 지나치게 단순하거나 한 개념에 너무 많은 것을 뭉뚱 그려놓은 (흔히 말하는 -스파게티-) 형태일 수도 있다. 이런 이론과 현실의 갭이 프로그래머의 능력을 나타내는 지표가 될 수 도 있겠지만, 객체지향 프로그래밍의 단점으로 바라볼 수 도 있다.

이 갭을 줄일 수 있는 가장 좋은 방법은 아마도 논리적-철학적 사고방식의 습관화가 아닐까 생각해본다. 어쩌면, 소프트웨어 개발자/프로그래머에게 가장 필요한 지식은 수학이라기 보다는 철학일 수 도 있을 것이다.

.. 이후는 다음 기회에 (우왕 길다)

ps. 꼴랑 이거 쓰는데 한달 걸렸어요. 쳇.
ps2. 레이아웃 깨지는 문제로 다시 엽니다. 🙂

Zero-configuration: automatic lookup

Zero Configuration: Simple is best는 어렵다.에서 언급한 바와 같이, 현재 제작중인 소프트웨어의 모듈/시스템수는 엄청나게 증가해버렸다. 서로 연동해야하는 모듈이 많으니 이리저리 입력해야하는 네트워크 정보(각 노드의 IP와 Port)가 매우 많다. (제어UI에는 8개정도지만, 세밀하게 조정에 들어가면 셀수 없이 많다.) 이런 상황에서 각 노드들을 효율적으로 관리하려면 어찌해야 할까?

각 노드마다 설정을 전부 해야한다고 생각하면, 그 복잡도는 노드가 추가될 때마다 선형적으로 증가하며, 각 노드에서 필요한 기능-설정이 추가될 때 마다 기하급수적으로 증가한다. 언제까지 이런 설정을 반복하고 있을 수는 없다. 쉽게 생각할 수 있는 해결책은 중앙집중관리노드를 도입해서 실제로 기능을 수행하는 각 노드들이 중앙 노드를 바라보고 있는 Star형 토폴로지를 구현하는 것이다. 이러면, 문제가 해결될 것 같지만 크게 2가지 관점에서 결정적인 단점을 가지고 있다.

  1. 전체 시스템의 복잡도는 전혀 줄어들지 않으며, 다만 중앙 노드로 압축될 뿐이다.
  2. 중앙 노드에 장애가 발생할 경우, 전체 시스템이 동작하지 않는다.

이런 단점을 최소화하는 모델이라면, 전화번호부 모델이 있다. Java Jini나 Web Service에서 활용하는 Naming 서비스 혹은 Directory서비스가 대표적인 사례인데, 필요한 노드(서비스)의 위치를 관리하는 Naming 서비스를 도입하여, 각 노드간 통신을 위해 필요한 위치정보를 URL 혹은 그와 유사한 형태로 저장하여 서로 Lookup을 하게 하는 것이다. Respository나 Directory 서비스의 복잡도는 상대적으로 낮은 편이다. 권한이나 인증같은 부분을 제외하고 생각하면, 등록과 조회만 있으면 된다. TCP/IP네트워크에 익숙하다면, DNS를 생각하면 된다.

실제 데이터를 주고 받기 위한 통신 채널은 각 노드사이에서 형성되므로 Naming 서비스는 단지 ‘전화번호부’의 역할만을 수행한다. 각 노드들 역시 Naming 서비스의 위치만 설정해주면 되므로, 설정은 더더욱 간편해진다.

중앙 노드로 압축되는 복잡도의 문제는 어느정도 해소가 가능해졌지만, 중앙 노드의 장애에 대한 문제점은 아직 남아있다. Naming 서비스의 이중화로 해결할 수 있는 문제일 수도 있겠지만, Naming 서비스의 조회결과를 로컬에 캐쉬하는 방법도 있다. 노드들이 급격하게 위치를 변경하는 시스템이라면 독이 될 수 있지만, 위치가 그렇게 급격하게 변하지 않는 다소 정적인 시스템이라면 충분히 위력을 발휘할 것으로 생각된다.

멋져 보이지만, 마지막 결정타가 하나 남아있다. 이건 ‘Zero-Configuration’ 이 아니다. 여전히 사용자는 Naming 서비스의 위치를 ‘설정’해주어야 한다. TCP/IP에는 Broadcasting이라는 멋진 방법이 존재한다. 각 노드들에 Naming 서비스를 설정하지 않아도 Broadcasting으로 Naming 서비스를 찾아낼 수 있다. 물론, 수동 설정도 가능해야 하겠지만 말이다. 🙂

Zero-configuration: Simple is Best는 어렵다.

Zero-configuration이란 말을 처음 접했던 건, 한국에서 널리 사용되는 자막 파일인 SMI에 대한 지원을 Mac OS X용 통합 코덱(?)인 Perian에 넣을 수 없다는 애플포럼의 한 쓰레드 때문이었다. 요지는, SMI를 지원하기 위해서 자막의 인코딩 셋업같은 별도의 세팅이 필요하기 마련인데, 이게 Zero-configuration에 위배되기 때문에 SMI에 대한 지원을 넣을 수 없다는 내용이었다. (물론 이유가 이것만 있는 것은 아니었다.)

Zero-configuration은 말 그대로 설치 이후 설정이 필요없는 소프트웨어의 특성을 의미한다. 더 보기 “Zero-configuration: Simple is Best는 어렵다.”

XML에 대한… 고찰?!!

XML을 처음 접하고 사용하기 시작한게 2000년 경이었을테니, 얼추 7년정도 사용한듯 하다. 2000년에는 XML문서버젼관리 시스템 프로젝트를 했었고, 그 뒤에는 PlayAction이란 사이트 겸 CMS를 만드는데도 사용했었고, 회사다니면서는 각종 설정파일, 유틸리티, 메타정보등을 생성/관리하는데 사용해왔다. 그리고, C++로 xml pulling parser방식의 인터페이스를 가진 라이브러리도 고민했었다. (libxml을 이용한 DOM라이브러리로 전환하긴 했지만..) 이렇듯 프로그래머로서의 삶에 깊숙하게 침투하신 이 분을 어떻게 요리할까라는 생각이 재개된건, 졸업프로젝트로 고려중인 Simulation Engine제작 때문인게 크긴 하다.

각설하고, XML을 분석하는 관점은 크게 Well-formed Document와 Valid Document라고 볼 수 있다. Well-formed는 XML의 기본 문법에 맞는지의 여부이고, Vaild는 문서정의 (DTD나 XML Schema)에 맞는지의 여부다. 이 두가지 관점을 항상 같이 고민하다보니 문제가 어려워졌던 것 같다. 오랜만에 다가온 Eureka!!는 실로 반갑다. 자 그럼 그 Eureka!!가 무엇이냐 하면.. (사실 별거 아니다)

XML을 가장 간단하게 분석하는 방법은 <와 >로 묶인 태그라는 점이다. XML의 가장 기본적인 요소인 Element외에도 DocType(<!DOCTYPE >)이나 Processing Instruction(<? ?>), Comment(<!– –>), CDATA(<![CDATA[ ]]>)등도 결국은 <와 >로 묶인 태그였다. 이렇게 관점을 바꿔놓고 보니 몇가지 재미있는 속성들이 발견되었다.

  1. <![ 로 시작되는 태그들은 ]]>로 닫힌다.
  2. <! 로 시작되는 태그들은 >로 닫힌다.
  3. <? 로 시작되는 태그들은 ?>로 닫힌다.
  4. <로 시작되는 태그들은 >로 닫힌다.

이런걸 왜 이제야 생각했는지 모르겠다. -_-

XML의 전체 스펙을 생각하고 파서를 작성하려고 들면, 일이 복잡해진다. 하지만, 위의 4가지 속성만 고려하고 작성한다면, 규모가 작아지고 작성이 간단해질 것 같다. – 기존에 사용하던 state_machine클래스를 사용하면 더욱더 간단히 🙂 –

또한, 각 태그들을 Event로 간주한다면, 트리기반의 DOM이나 콜백기반의 SAX와는 달리, XML문서를 Event의 리스트로 관리할 수 있게 된다. SAX의 단점이라면, 역시 수정이 불가능하다는 것이고, DOM의 문제라면 메모리를 많이 차지한다는 점일텐데, 이 두 문제점 사이에서 적절히 타협할 수 있는 안이 되지 않을까 라는 생각이 들었다. 그리고, Event의 리스트로 관리하게 되면 복잡하긴 하겠지만, 트리형태의 Access도 불가능한 것은 아닐거라 생각한다.

남은 일은, 구현하는 일이지만… 회사일과 졸업논문, 각종 시험과 과제가 발목을 잡고 있는 현실이 안타까울 따름….. 응??