new approach

난 초반을 잡는 타입이다.
그리고 초반밖에 못 잡는 타입이기도 하다.

내가 초반에 러쉬를 하는 이유는 단순하다. 집중력이 무엇보다 중요하다고 생각하기 때문이다. 그리고 내가 자랑할 수 있는 것이 집중력 뿐이기 때문이기도 하다. 꽤 자연스럽게 이런 형태로 살아오다보면, 초반에 집중을 하는 것이 나중에 하는 것 보다 훨씬 큰 이득이 있다는 것을 알게된다.
당연히 집중하지 못했을 때에 흘러 들어오는 것을 이해할 수 있다는 데에서 이득이 되고,
무엇보다 중요한 신뢰를 얻은 상태로 있을 수 있다는 것이 이득이 된다.

내가 초반에 놀라운 것을 보여주면, 성실함이라도 보여주면,
상대방은 항상 내가 놀라운 것을 해 내거나, 적어도 성실할 것이라고 믿는 것이다.

물론 이것이 자만심을 부르게 되고, 내가 노력하지 않아도 얻는 것들이 많아 질수록 더 쉽게 집중력이 흩어지고는 한다.
이 집중력의 파도를 어떻게 타는가가 결국 문제가 되는 것일테다.
하지만, 적어도 내가 원하는 것을 발견했을 때에는 그 집중력은 끊임없이 올라가는 상태가 되는데, 이것은 flow보다도 훨씬 고차원 적으로, 거의 핵폭탄과 같은 폭발력을 보여줄 수 있다. 이런 상태를 사용하는 사용자(?) 측에서는 집중력에 대한 문제보다 더욱 심각한 "허무감"이라는 숙제를 안고 살아가야 하는것이 문제다.
자, 어마어마한 폭발력이 있는 뭔가를 쏟아 부었다면, 그것을 정복한 후 무엇을 해야할까?
결국 새로운 것을 찾아 찾아 떠나는 것이다. 뭔가 다시 핵폭탄과 같은 것을 쓸 수 있을 때 까지.

어쨌든, 나는 새로히 도전할 것을 찾았다.
그리고 퍼붓고 있다.
어쩌면 극한까지 닿을지 모른다.
나의 세상이 나의 파괴보다 더 빨리 넓어 지기를 기도해 본다.

재지말고 나가자.

사람이 생각대로 사는경우는 별로 없다는 것. 나도 알지만,
지금의 나는 뭔가 모자르다.
뭔가 재고있나?
낯을 가리나?
마치 아이를 바라보듯이 또 다시 자신을 바라봐도, 여전히 알 수 없다.
어쨌건, 내가 원하는 모습이 아니다.
얼마나 더 할 수 있느냐의 문제가 아니라, 뭔가 끝을 마주했는가의 문제이다. 어려운 문제는 항상 나를 기쁘게 할 수 있어도, 그것은 일종의 레크레이션인가의 문제일 뿐이다. 자신을 믿는다면, 더 현명하게 대처하자. 하루가 끝나면, 보다 자신에게 자랑스러울 수 있는 자신을 마주해 보자.
분명히 지금은 아니다.
뭔가 더 나은 내가 나를 기대하고 있다.
그리고, 자신이 가려는 방향을 항상 확인하자. 2009년은...
자신의 감각을 믿고 있는 동안에는 나의 기대는 언제나 무모하지 않다. 나는 그런 내가 필요하고, 충분히 그만한 능력을 가지고 있다. 왜 허둥대는가? 결국 앞으로 갈 수 밖에는 없지 않은가?

정상적인 생활?

역시 규칙적인 회사 생활은 생각보다 만만치가 않다.
11시 인 것을 보고 빨리 자야겠다는 생각을 하는 것을 보면, 다시 세상의 시계가 돌아가기 시작한 듯한 느낌을 받는다.
뭔가 물고 늘어지는 즐거움은 없지만, 짧게 끊어서 하고자 하는 모든 것들을 하고자 하는 마음에 조금씩 이를 악물게 된다.
글을 쓰다가도 운동을 해야된다는 생각에 팔굽혀 펴기를 하고, 생각을 하다가도 일단 끝내야 하는 일에 다시 키보드를 두드린다.
한정된 시간속을 살아가는 것은 이런 것이겠지 하고 생각된다.

너무 극한의 것을 좋아해서인지, 균형을 맞추는 일이 낯설다.
물론 원하는 것은 극명. 균형을 맞춘 상태로 극한까지 가는 것이다.

하지만, 시간이 없으면 일을 정확하게 하지 못하고, 과연 정확하게 하는 것이 빠른 것인지, 빨리 보여주는 것이 빠른 것인지 헷깔리게 된다. 나는 보통 이런때에 자신의 감각을 믿고 맡기라고 말하지만, 실재로 하는 것은 감각을 철저히 배제하고, 이성이 모든것을 통제하도록 하고 만다. 그것이 불안감의 우리에게 주는 영향력이려니 생각한다.
이성을 기르자. 감각을 믿어주자.

어제보다 훨씬 더 나은 오늘을 만들어 가자.

개구간과 폐구간

수학에서는 개구간인가 폐구간인가가 중요하게 생각된다.
개구간이란 어떤 숫자 자체가 그 구간안에 포함되지 않는다는 것이고, 폐구간은 반대이다.
보다 쉽게 느끼기 위해서는, 개구간은 -2< x < 3 인 거고, 폐구간은 -2<= x <=3인 것이다.
여기에서 -2와 3이 이 구간 안에 포함되는가 되지 않는가의 숫자 하나의 문제일 뿐이지만, 수학적으로는 이 사실로 부터 많은 명확성을 가져갈 수 있기 때문에 중요하게 생각을 하고,
그에 따라서 명증할 수 있는 여러가지를 매우 많은 말들로 어렵게 써 놓고 있다.

-2와 3의 사이에는 수억조로도 표현하지 못하는 그야말로 무한한 숫자들이 있는데, 왜 이 숫자의 포함 여부가 그렇게 중요할까? 물론 수학적으로는 구간이 무한히 접근하는가의 문제와 어떤 부분으로 덮을 수 있는가의 문제 등이 있지만 천억에 천억을 천억번 곱한 것 보다 많은 -2와 3 사이의 수들이 무시당하는 수모를 당하는 동안 수학적이지 않은 어떤 의미를 이들이 과연 지니고 있다고 말할 수 있을 것인가?

chaos이론이나 complexity이론에서 나오는 혼돈의 가장자리 라는 개념을 들으면서 이 부분이 굉장히 궁금해 지게 되었다. 물론 두 이론 모두 수학적인 모델링이 강하게 들어간 이론이긴 하지만, 왠지 다른 이론에서 그 끝의 명확성이, 혹은 그 부분들이 항상 주목을 받는 이유가 나를 끌어들이는 것이다.
왜냐면 이런 것들은 삶의 시작과 끝만이 의미를 지니고, 마치 과정이 중요하지 않는 것처럼 느껴지기 때문이다.
극단의 것을 시도하는 것만이 의미가 있고, 그런 것들을 발전시켜 나간 헌신들이 의미없어 보이기 때문이다.
그리고 결국 중간을 채우고 있는 것들에 특별한 의미를 부여할 수 없는 나 자신을 보기 때문이다.

생각해 보자. 눈이 소복하게 내린 곳에 발자욱을 내며 즐거워 하던 순수한 시절부터, 끝없이 새로운 것을 만들어 내려 자신을 황야로 내모는 우리들의 무모한 도전까지. 무엇이 중요한가?
우리는 근로자의 날 같은 때에만 우리네를 지탱해 주는 많은 사람들에게 가식적인 존경을 보내곤 한다. 창의 끝은 창의 몸체가 없다면 존재할 수 없다고. 묵묵히 자신의 일을 하는 사람들이 있기에 지금의 모든 것이 있다고. 물론 이런 말에 속아넘어가 주는 사람들이 50%정도는 있기에 세상이 온건히 카스트 제도를 유지할 수 있지만, 모두가 알고 있다. 우리가 364일 동안 99%정도의 사람들이 존경을 보내는 사람들은 극단에서 상대를 찔러 쓰러트리는 창의 끝과 같은자들 이라는 것을.

어린 시절부터 지금까지 우리는 우리를 끝없이 새로운 곳으로 내모는 잔인한 끝을 기대하고 있는 것이다. 한 발 옆에 파멸이 있는 혼돈의 가장자리가 우리가 있어야 할 곳이라고 느끼는 것이다. 안정을 원하는가? 나 역시 안정을 원한다. 하지만 그것이 자신이 가장자리에 있기 때문인가? 그렇다면 옳지만, 그렇지 않다면 이제 다시 물어봐야 할 시간이 왔다. 화장실로 급히 뛰어가서 거울을 보라. 여전히 눈이 살아있는가? 정말로 살아있는가?
이제 다시 저 극단으로, 저 가장자리로 가야 할 시간이다.
-2와 3 근방에서 compact한지 그렇지 않은지를 판별하는 사람들을 성가시게 할 시간이다.

결론은 이상하다.
체력을 길러야 한다. 이것이 전제이다. -2와 3 사이에서 어중간하게 1.414... 같은 위치에서 헤메이며 안정되어서는 안된다. 어떤 구간인지가 중요할 때가 있을때도 있지만, 어떠한 경우라도 우리는 그 극단에 존재해야 하는 것이다. 그들의 의미를 위해서건, 우리가 초라하게 받을 성적표에 대해서건, 그 극단으로 가야 하는 것이다. 다시 힘을 내어 저 폭풍치는 곳으로 가자.

Component + Controller = ?

Composite Model은 물론 어디나 쓰이고 편리한 것으로 생각되지만,
특성을 자주 지워버리는 문제가 있다.

보통 glype와 같은 곳에서 부터 발전해 나아가는 모습을 보고 있으면,
물론 처음에는 하나 하나의 단위를 부여하면서 하나의 멋지게 정리된 분류를 생성해 낸다.
그렇지만, 나중에 그것들이 하나 하나 발전하게 되면서 제약적인 부분이 생긴다.

특히 Modeling에 익숙하지 않은 개발자가 사용하게 되면,
발에 맞지 앉는 구두를 신은 것 처럼 계속해서 거슬리는 규칙들을 달고가게 되고,
수많은 메모리를 낭비한 후에 버리고 마는 것이다.

잠시 머리속에 web programing에서 controller와 component를 하나가 되게 개발을 하면 어떨까 생각해 보았다.
물론, ActionScript의 경우(라기보다는 flash등), 처음부터 movie와 sprite등이 모두 compositable하게 만들어 졌고, 잘 만들어진 계층적 구조를 가진 object들이 되었긴 하다.
하지만, 개인이 이런 클래스들을 당장의 편의성 때문에 시도해 보면, 메모리나 지나친 단계가 많아지는 composite object를 적절히 처리할 수 있을지 의문이다.

물론, 의문이 생겼으니 시도해 보는 것이 순서이긴 하겠지만 말이다.

현재, component가 요구하는 사항은 post나 get 방식의 데이터이다.
controller가 요구하는 것은 현재 없다. Front Controller만이 URL을 요구하고 있다.
그러므로, controller 가 Front Controller와 상당히 분리된다면,
contoller는 그대로 component가 될 수 있다.
다만 여러가지 이유로 불편함을 초래할 수 있다.
그것은 일단 controller로서는 의미없는 hooking을 하게 되는 점이 있고,
component로서는 의미없는 Controller라는 이름을 달고 있어야 한다는 것이다.
(물론 반대로 Controller라는 이름을 없애도 되지만, Front를 건드려야 되는 부담이 있다.)

하지만, 이 둘을 통합하면 component와 controller의 구분 없이 제작 후 가져다 붙이기가 가능해 진다.
무엇보다 테스트를 따로이 controller에서 만들어서 할 필요가 없어진다.
(하지만 여전히 test는 만들어야 할테니 그리 큰 장점은 되지 않는다.)

그렇다면 시도해 볼 것은 단순하다.
아직 이름이 비어있는 Component시리즈를 만들면 되는 것이다.
빠르게 난관에 봉착해야만 포기할 수 있을텐데... 하는 생각을 해 본다.

개발속도의 문제

생각없이 자판을 두드려 대는 것도 가끔씩은 재미있다.
게다가 추가보너스로 diff가 길어져서 뭔가 많은 일을 해 낸 것 같은 느낌마저 든다.
그렇지만, 고민없는 개발은 왠지 생각으로 자동화 할 부분을 노가다로 대체한 것 같은 느낌이 께름칙하다.

반면에 Methodology나 Modeling을 열심히 고민하며 최선의 방법을 찾고 있다보면,
이쪽은 '자주' 재미있게 느껴지지만,
생산된 것은 없고 앞으로 해야 할 것들만 아득하게 느껴진다.

뭐, 결국 답은 '중도'같이 시원찮은 것이겠고,
남은 문제는 어디까지인가? 하는 부분이다.
어디가 적절한 Mid 값이 되는 것일까?

agile 진영을 보면, 경험주의적인 방법론이 소프트웨어 개발에 적합하다는 판정을 내린다.
하지만, 여전히 제시해야 할 개발시간을 비슷하게라도 측정해야 하고,
사소하고 반복되는 문제를 처리하기 위해 개발환경을 계속 자동화 해야 한다.
결국 Mid값을 알기 위한 경험주의적인 방법론은 일단 찍고봐야 하는 것이라는 결론이다.
(이 부분에서 왠지 agile 방법론이 직접적인 도움을 안준다는 느낌이 들곤한다.)

일단 찍고, 짧은 사이클로 반복하고 교정하고 나아가는 것이 역시 항상 정답이다.
계속 하다보면 개발속도가 빨라지는 지는 것도 당연지사이고.
그렇다면 지금 고민할 필요가 없다.
개발속도가 늦는 것 같으면, 다시 고민하고 다시 계획하고 다시 실천한다.

그리고 시간이 나면 금강경이나 바가바드 기타를 한 번 더 읽어준다.

model화된 view가 필요하다.

언제까지 view단이 designer의 몫이 될 수는 없다.
같은 패턴의 view가 수백, 수천이 될 동안도, 그것이 패턴화된 모델이 되지 않는다는 것은,
프로그래머가 미리 나눠놓은 디자이너와의 경계 때문일 것이다.

물론 그래서 dream weaver같은 곳에서 쓰이는 멀티탭의 구조라든지 하는 곳에는,
디자이너용 '템플릿'이라고 불리울 수 있는 녀석들이 즐비하다.
그리고 그것들은 js파일과 잘 연동 되어서 디자이너든, 프로그래머든 신경쓰지 않고 사용할 수 있다.

하지만 이런 copy & taste 형식의 많은 코드들은 그것이 같은 template의 형태를 하고 있다고 해도 코드를 읽는데 불편함을 준다.
그리고 당연히 한꺼번에 어떠한 변화를 주기 힘들다.
find 와 egrep등의 정규표현식을 이용한 방법이 머리속에 지나가지만, 여전히 좋은 구조라고 말하기는 힘들다.
역시 component화 된 프로그램이 사용할 수 있는 skin으로서 패턴화된 html 모델이 답이 아닐까 생각해 본다.