워드프레스.. 멋진데?

워드프레스로 바꾼지도 꽤나 오래되었는데.. 2006년 1월로 기억하니.. 3년이 넘었군요.
사실 설치형 블로그를 사용한다는게 상당히 귀찮긴 합니다. 업데이트도 해줘야했고 플러그인도 직접 찾아다가 깔아야했고…

그런데… 워드프레스가 언젠가부터 자동 업데이트부터 플러그인 자동설치까지 지원이 되는군요. 이건 뭐. 데비안/우분투를 쓰는 기분이랄까요. 🙂

설치형을 쓰고 있는건지, 서비스형을 쓰고 있는건지 모르겠습니다. -_-b

ps. 시험삼아 이쪽에서 export해서 wordpress.com에 import시켜봤는데 완벽하게 작동하는군요! 멋진데요. (당연한거지만!)

메모: Sonic Birth

우연히 “재발견”한 소프트웨어 Sonic Birth!!!

이걸 처음 만나게 된 계기는, 밴드 음반 작업하면서 쓸 무료 플러그인을 찾으면서였다. 깔아보고, 몇 번 써먹고는 까먹고 있었는데.. 우연히 다시 열어보고 테스트해본 결과 생각보다 가능성이 무궁무진하다는 사실을 깨닫고 기뻐하는 중.

Sonic Birth AU 디자인 화면

위의 화면을 보고 아- 하실 분들이 계실지 모르겠다. 요는 오디오 시그널 프로세싱에 사용되는 연산들을 미리 준비해두고 이 연산들을 조합해서 “회로”를 짜는거다. 진짜 전기적인 “회로”와는 다르지만, 이 정도면 어지간한 플러그인은 직접 만들 수 있다.

이 소프트웨어를 이렇게 메모에 남겨두는 이유는 흐름에 무게중심을 놓는 개발방식에 대한 예제 중 하나이기 때문이다. 🙂

ps. 첫 데모음반인 homemade#0 믹스를 1곡 남겨두고 있다. (정말 힘들었다..)

UML 클래스 다이어그램에서 아이콘 붙이는 방향에 관한 간단한 팁

이상하게 UML 다이어그램을 작성하다보면 화살표에 붙는 아이콘의 방향이 헷갈리는 경우가 많습니다.

main

너무 정치적인가.. -_-;

매번 헷갈리는 것도 짜증나고 어찌 기억할까 생각을 해보았는데.. 두가지가 나오더군요.

1. 주어법.

Citizen generalizes President and Proletariat.
Citizen owns Power.

주어쪽에 아이콘을 붙입니다.

2. 관계상 상위법.

Citizen은 President와 Proletariat의 상위개념이죠. 상위개념에 아이콘!
Citizen이 Power를 소유하고 있으므로 더 큰거죠. 더 큰거니 아이콘!

ps. 와 오랜만인데 이런 날림이라니!

시간, 포스팅

사람에 따라 다르겠지만, 이 블로그는 포스트하나를 작성하고 “공개하기”버튼을 누르기까지 상당히 많은 시간이 걸립니다. 하나 작성하는데 3 Man-Day(MD)정도 걸리니까요. 집중해서 쓴다면 좀 줄어들긴 하겠지만, 조각조각난 시간테이블에서 긴 집중의 여유는 요원한듯 합니다.

사실, 연애도 끝장났고, 게임도 접은지라 시간이 남을 것만 같았는데, 이건 뭐. 집중이 잘 안되네요. 그 빈자리들을 다른 것들이 채우는… 아마 OOP revisited의 다음 주제는 ‘언어’ 혹은 ‘글쓰기’가 될 예정인데 공부가 모자란지라 좀 더 생각을 해보아야 할 것 같습니다.

너무 meta-development(?) 한 이야기만 하는 것 같아서, 필드로 돌아갈 생각도 있습니다. 몇 년간 손에서 놓고 있던 boost관련 글들도 써야할 것 같고, C++ template meta programming에 대한 내용도 어서 정리해서 다뤄야겠죠. 하악.

어느 것이 되든, 글 하나에 3MD. 그러니까 24시간은 필요한데.. 아주 글을 쓰는 시간을 정해놓고 지켜버릴 생각입니다. 연애-게임을 하던 시절처럼 불쑥 튀어나오진 않을 듯 싶군요. 🙂

– 이렇게 해놓고 밴드 데모음반 작업한다고 잠수탈지도 모르겠습니다. 흐흣. –

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와 거의 유사하다. – 참 아쉬움.

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

쉬운 글.

철학책을 읽다보면 원전과 2차저작의 엄청난 갭을 느끼게 된다. 아무래도, 자신의 생각을 직접 말하는 원전은 그 사람의 생각의 흐름에만 맞추게 되기 때문에 읽는 것이 난해한 경우가 많은 듯 하다. – 물론, 시쳇말로 ‘간지나게’ 써야 좀 쓴거 같은 것도 없지는 않을 듯. –

이런 이유로 고민을 하고 있는데, 철학은 아니지만 OOP: revisited시리즈나 Zero-configuration시리즈 같은 글들은 일종의 ‘원전’이다. 게다가, 아이디어 스케치 수준의 뼈대만 존재하는 글이기 때문에 내용도 빈약하고 여러모로 좀 안타까운 면이 많다. 살붙이기 연습 겸, 독자층 확보를 위해, 좀 쉬운 안내서를 써야하지 않을까 싶다.

‘코드 속을 여행하는 히치하이커를 위한 안내서’ 정도면 괜찮지 않을까 싶은데, 무슨 이야기를 해야할지 모르겠다. 전통적인 방식대로 나열형 소개를 하는게 나을지, 아니면 21일 완성처럼 실제 코드를 작성하는 형태로 가야할지. 그것도 아니라면, 프로그래밍 언어 서적을 읽기 위해 필요한 제반사항을 쌓는 형태로 가야할지. 모르겠다는 거다. 사실 소프트웨어 개발을 시작하려면 기본적인 하드웨어에 대한 이해가 있어야 하는 것도 사실이고, 으아악 막상 쓰려고 보니 어디서 부터 써야할지 모르겠다. 일단 생각나는 가장 유력한 방향은 언어에서 출발하는 것인데, 이건 언어학 공부가 모자란 관계로 좀 공부를 더 해야할 듯.

그래도 시작이 반이라고 이름은 정했으니 다행이려나. 🙂

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패턴을 만들어 낸 것이다.

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

패러디 메커니즘의 의미

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

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

글들을 정리했습니다.

이 곳에는 IT와 소프트웨어 개발에 관련된 글들만 올릴 생각입니다.
감정적인 글들은 Crow’s Transparent Mind Gallary로,
일상에 관한 것들은 까막의 미투데이로,

올라갑니다.

음악과 관련된 블로그는 만들지 안만들지, 만들면 어디에 만들지 아직 모르겠습니다. 🙂

기존의 글들은 저 혼자 보다가 마음에 든다 싶으면, 현재의 상태에 맞춰서 해당하는 곳으로 올라갈 계획입니다.
– 아마 텀블러블로그인 Crow’s Transparent Mind Gallary가 대부분일겁니다.

🙂

ps. 이름도 바꿨습니다.

OOP: revisited #2

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

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

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

디자인 패턴은 관계의 모방

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

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

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

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

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

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

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

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

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

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