Tractatus Logico-Philosophicus

지금까지 내 경험과 지식을 정리하여 네트워크 프레임워크를 하나 만들었다.
Neurasthenia 라고 이름붙이고 LGPL로 공개했다.
이런 이름을 붙인 이유는 comet 이란 것이 세상이 바뀌는 것을 하나도 놓치지 않으려고 귀를 기울이는 것처럼 보였고, 결국 신경쇠약에 걸려버린 사람 처럼 느껴졌기 때문이다.

회사를 옮기면서 면접을 보게 되었는데, 최종 면접관이 내게 물었다. 이직을 하면 무얼 하고 싶냐고. 망설임 없이 대답하기를

내가 지금까지 쌓은 대부분의 지식은 오픈소스에서 얻었습니다. 지금까지는 여유 자체가 없이 쫓기는 생활을 해 왔는데, 이젠 스스로를 돌아보고 정리한 후 내가 받은 지식과 그동안 내게 축적된 경험들을 잘 엮어 오픈소스 프로젝트에 참여함으로서 그동안의 이득을 돌려주고 싶습니다.

라고 했다.

그럭저럭 그 회사로 이직을 하게 되었고, 여유를 찾으려 했으나 안타깝게도 이직한 부서 자체가 매번 불이 나는 바람에 불끄느라 정신없이 8개월여가 지나갔다.
하지만 그 동안에도 조금씩이나마 Neurasthenia 에 대한 구상과 설계, 코드를 만들어갔다.
이제 해가 바뀌기 전에 지금까지의 결과물을 세상에 내 놓는다.
지금까지 구현된 내용을 짧게 정리하면 다음과 같다.

1. Servlet container 의 기능을 한다. 고로 servlet, jsp 를 만들어 동작시킬 수 있다.
2. Comet server 역할을 한다. 브라우저상에서 채팅이 가능하다.
3. 프로토콜에 독립적인 네트워크 서버 역할을 한다. 기본적으로 HTTP 와 STOMP 프로토콜을 지원한다.

늙은이 소리를 덧붙이자면, 소시적엔 이런 소스를 오픈하다니 참으로 대단하다 란 생각을 달고 살았다. 그리고 난 대체 언제쯤 이런 걸 해 볼수 있을까를 고민했었다.
몇번 이런 저런 프로젝트를 해 볼까 생각할 때 마다 어느정도 모양이 잡히기도 전에 내게 부족한 점이 튀어나와서 이 부분을 보완하고 다시 시작하자란 생각에 에둘러 추진할 생각을 접곤 했다.
어떻게 보면 neurasthenia 도 이런 저런 부족한 점이 무척 많다. 하지만 언제까지나 시작하지않는다면 결코 완성하지 못할것이기에 부끄러움을 무릅쓰고 세상에 내놓기로 했다.

자 주사위는 이미 내 손을 떠났고 이제 이 배가 신대륙을 발견할지, 망망대해를 영원히 떠도는 플라잉 더치맨이 될지 아니면 또다시 세이브조차 하지 않고 지워버릴지는 앞으로 내가 어떻게 neurasthenia 를 운영할지에 달렸다.

참고로 neurasthenia 를 사용한 채팅 서버가 돌고 있다.

Posted by eoh

사내 라이브러리를 쓸 일이 있어 문서를 보다 main class 가 아닌 것은 모두 빈즈 란 이름을 붙인 것을 보았다.

삽질계에 빈즈 란 용어가 쓰이기 시작한 것은 모델 1 (이라 쓰고 JSP 에 다 때려 박는다 라고 읽는다) 방식에서 웹에서의 MVC, 일명 모델 2 방식에 대해 갑론을박이 벌어지면서 라고 기억한다.
모델 2란 이름으로 봐선 일정한 방식을 특징지어 말하는 것 같지만, 실질적으로 JSP는 View 역할만으로 한정하고 Controller 와 Model 역할을 분리한 (혹은 분리할 수 있는 것처럼 보인) 수많은 방법론이 모델 2 라고 자칭했었다. 그중 당장 생각나는 것만 해도 커스텀 태그 라이브러리, 스트러츠, 웹 매크로, 티, 벨로서티 등등 그야말로 백가쟁명의 시대가 따로 없었다.
이렇게 딱히 이것이다 라고 정의된 것이 없다 보니 악화가 양화를 구축한다고 Beans 란 이름만 붙여서 클래스를 만들고 JSP 에서 호출하면 은근슬쩍 모델 2 입네 하는 것들도 있었고 사람들도 대충 뭉뚱그려 쳐 주는 현상이 있었다.

본디 JavaBeans 스펙은 캡슐화를 지키면서 introspection 을 하지 않고 외부 클래스가 내부 속성에 대한 접근자를 알아내기 위한 규약을 정의하고 있다. 이때만 하더라도 세상은 모두 component 들의 조합으로 이루어 질 줄 알았고 (혹은 기대했고) 이를 위해서는 component 에 대한 조합을 (손으로 할 수는 없으니) 할 Tool 이 component 의 속성에 접근하는 것이 필요했기 때문이었다.
하지만 세상사가 다 그렇듯 자바 데스크탑 컴포넌트는 글자 그대로 쫄딱 망했고 JavaBeans 스펙도 묻히는 가 싶더니 (약간 생뚱맞게도) 웹에서의 MVC 에서 데이터 구조를 표현하는데 부활하게 되었다 라고 쓰고 싶었는데 사실은 그렇지 않다.

첫 문장에서 썼듯 원래의 의도와는 전혀 상관없게도 데이터 표현 (getter/setter 를 쓴다) 에 비즈니스 로직까지도 얼렁뚱땅 덧붙여진 클래스면 대충 Beans 란 이름을 붙여 쓰는 경우가 허다하다. 솔직히 말하자 당최 Beans 란 postfix 를 왜 붙이는지 모르겠다.
까 놓고 보면 getter/setter 는 있되 JavaBeans 스펙에서 말하는 규약도 따르지 않는다면 굳이 이름에다 Beans 를 붙일 아무런 이유가 없다.
나는 이것이야말로 누가 어떤 의도로 시작한 지는 모르지만 대충 이렇게 해 왔으니 따라 한다는 관습에 지나지 않는다고 생각한다.

지금 자신의 class 에 Beans 라는 이름이 붙은 클래스들이 있다면 다른 것으로 이름을 바꾸어 보면 좋겠다. 예를 들면 A4Beans, B4Beans 가 있다면 A4Adzuki, B4Adzuki 로 바꾸어 놓고 보자 - Adzuki 는 팥이다.
결론적으로 아무런 차이가 없다면 그저 Beans 를 클래스를 구분하기 위한 postfix 로 사용한 것이며 만약 PrinterBeans 까지 있었다면 구분자의 효과도 없었을 것이다.

다시 말하자.
Beans 라는 이름을 쓰고 싶다면 최대한 (그 의도대로 쓰는 사람이 드물다 할지라도) 스펙에서 정의된 형식을 유지하는 것이 좋겠다.
비즈니스 로직과 뒤엉키는 것이 불가피하다면 그냥 Beans 라는 postfix 를 붙이지 말고 절약된 5자를 좀 더 친절한 클래스명으로 하는데 시간을 들이는 것이 정신 건강에 좋을 성싶다.

Posted by eoh

예전 회사에서 JavaOne 에 갈 기회가 있었다. 여러 session 들을 들었지만, 내게 가장 Impact 있었던 것이 Intel 에서 온 사람이 발표한 (중국계 같았다) STM/HTM 관련 session 이었다. 그때는 분명히 흥미롭다고 생각하고 찾아봐야지 생각했는데, 그 후 일상에 쫓겨 망각의 강 너머로 밀려가 버렸다.

한달 전 즈음에 이 책 어떤가요? 란 질문이 내가 자주 가는 사이트의 포럼에 올라왔다.
일단 평소 관심이 있던 주제라서 목차를 훑어 보니 마지막 장에 TM (Transaction Memory)  가 있어서 "더헛" 이라는 감탄사와 함께 바로 질렀다.

학교를 다닐 때 친구가 한 말이 있다.

우리 학교가 왜 좋은 학교인가 - 그건 "저자 직강" 이 많기 때문이다.

이 책의 저자 (모리스 헐리히, 니르 샤비트) 들에 대해 잘 몰랐지만, 챕터의 끝 마다 있는 "일러두기"를 볼 때 마다  이 사람들이 책에서 설명하고 있는 바로 이 알고리즘을 발견한 사람들이구나 하는 감탄을 반복하게 된다.

물론 이 책에서 이야기 하는 선형화 가능 시점을 찾아내어 증명하고, 무잠금 알고리즘을 적용하는 것이 산업 현장에서 바로 적용하는 건 쉽지 않다. 왜냐면 이러한 무잠금 알고리즘은

1. 닥치고 synchronize 인 Coarse-grained 잠금 보다 이해하기 어려워 적용하기 쉽지 않고
2. 따라서 향후 유지보수가 쉽지 않으며
3. 환경 ( H/W support 여부, Application algorithm, 경쟁상황의 빈도) 에 따라 그 결과치가 매우 다를 수 있으므로

쉽게

복잡한 타이밍 기반 기술

로 생각되기 쉽다.
하지만, 이미 해당 이론을 적용한 결과 (java.util.concurrent.*) 들이 널리 쓰이고 있으니, 더이상 실용성 없는 이론가들의 이상세계에 대한 넋두리라고 치부할 일은 아니다.
그동안 Middleware 를 만드는 일을 해 왔으면서도 바쁘다는 핑게로 기반 이론에 대한 이해와 발전 상황에 대해 지나치게 피동적이고 방어적으로 행동하지 않았는가 라는 반성을 하게 된다.

자 이제 번역서의 질에 대해 듣기싫은 이야기를 좀 해야 되겠다.
일단 지금까지 읽은 부분에 대해 리스트업을 좀 하면

1. p53 무기아 상태와 무교착 상태에 대해 거꾸로 설명한다.
2. p54 오기가 있다. j = 1-i
3. p78 최대 n-1 개의 DOWN 과 DOWN <- RIGHT 의 오기
4. p249 클래스는 모니터가 클래스가 <- 중복
5. p288 각 노드에 Boolean 인 marked 필드를 추가하려 (추가하여 의 오기)
6. p298 만약 currA 의 키가 a 의 키와 갔다면 (어딜 가?)
7. p342 EliminationArray 를 사용하여 Stack 를 만들었는데 전체적으로 선형화 되지는 않으므로 (push/pop 이 성공한 경우와 실패한 경우 선형화 시점이 다르다) 선입 선출이 깨진 것이 아닌지. 그렇다면 이걸 Stack 이라고 부를 수 있을까?
8. p354 그림 12.6 결합 전단계 는 12.3 의 오기인듯
9. p369 Balancer.traverse() 는 인자가 없다고 해 놓고선 public synchronized int traverse(t) -> 응?
10. p367 입력 수열이 계단 속성을 지닌다. - 수열의 계단 속성에 대해서는 설명한 바 없음 -> 원서에도 이모양일까?
11. p369 half[] 는 width 의 반인 Merger 객체의 2차원 배열이다 -> element 가 2개인 1차원 배열이던데?
12. p409 크기를 변강?하는 중에는
13. p415 비트를 뒤집다 -> 일반적으로 1->0, 0->1 로 하는 걸 비트를 뒤집다 라고 표현하지 않는가?
14. p438 이런 종류의 성능을 무작위화 없이 만들어낼 방법을 -> 은 의 오기?

헥헥.
아... 너무 읽기 힘들어요...
2판에는 신경 좀 써 주세요.

Posted by eoh

콘솔에서 뭔가 할 때 사전 프로그램을 매번 띄우기도 뭣하고 그렇다고 브라우저에서 찾는 것도 귀찮아서 OPEN-API 를 이용하여 console 에서 동작하는 사전을 만들었다.
예전에도 비슷한 것을 만든 적이 있었는데, 한 1,2년 잘 쓰다가 갑자기 안 되서 이상하다 생각했다. 알고 보니 서비스 종료 켁.
.
OPEN 플랫폼이니 매쉬업이니 하는 것들이 서비스 제공자와 이용자에게 다 좋은 윈윈 이니뭐니 아무리 추켜세워도 결국 변하지 않는 것은 "돈이 안 된다 싶으면 언제든지 접을 수 있다" 란 것이니 지금은 문제 없다 할 지라도 결국 자기 것은 자기가 다 들고 있어야 한다는 건 피할 수 없는 진리인 것 같다.

이솝 우화에도 나오다시피 자기가 해야겠다 생각하지 않고 누구 시켜서 해야지 하면 종달새 어미한테도 무시당하는 건 예나 지금이나 다를 바 없나보다.

자 잡설은 그만두고,
UTF-8 locale 용 console dictionary주의사항

• DAUM open api 를 사용한다. (따라서 네트워크 연결된 상태에서만 동작한다.)
• Perl 로 구현하였다.
• XML::DOM 모듈을 사용한다. 없는 경우 cpan install XML::DOM 으로 설치.
• n 은 다음 목록, p 는 이전 목록을 보여준다. 종료는 Enter.
• Windows 에서 동작시키려면
• 일단 perl 을 설치 (http://www.perl.org)
• 가장 아래쪽 부분의 두 서브루틴을 조절한다.
• sub set_environment{
      ${$_[0]} = "d3b3c8fe22566e904b1b0b759c190736fe16e843";
      ${$_[1]} = "WORD";
      ${$_[2]} = 5;
      #binmode STDOUT, ":utf8";
  }
  sub change_enc{
      #return $_[0];
      return encode("euc-kr", $_[0]);
  }
• *nix 계열에서는 XML::DOM 설치만 하면 잘 돌아가는 듯 싶다.
  

Posted by eoh

하나의 프로그래밍 언어에 어느 정도 익숙해 지면 필요없이 번잡하다고 느껴지는 API 들이 눈에 거슬리기 마련이다. 그래서 특정한 작업을 수행하는데 있어 제공되는 API 들을 사용하여 일일히 나열하기보다 스스로 작성한 서브루틴들을 사용해 깔끔함을 추구하게 된다.
하지만 조금 더 경험을 쌓다 보면 결국 서브루틴으로 묶는 것으로는 한계에 부딛치는데, 대표적으로는 약간 다른 일들을 하는 여러 비슷한 서브루틴들을 만들어야 하는 상황이 닥치는 것이다.
단순하게는 서브루틴들을 더 잘게 쪼갠 원자적 서브루틴들의 조합으로 만들면 되겠지 란 생각이 들겠지만, 이를 직접 해 보면 결국은 언어의 문법과 거진 1:1 로 매치해야 된다는 것을 알아채곤 바로 포기하게 된다.
이 정도에 다다르면 해당 언어에서 제공되는 문법 자체가 자연스럽게 느껴지지 않게 되어 내가 문법을 설계한다면 더 "자연스러운" 문법을 만들어낼수 있을 것이라고 생각한다.

프로그래밍 언어에서 자연스러움이란 무엇일지 생각해보았다.
먼저 내가 가지고 있는 책의 한 부분을 인용한다면

Ruby에 관한 오래된 문구 중에는 '놀라운 최소의 법칙' 이라는 게 있다. Ruby 커뮤니티에서 막연히 공유되고 있는 Ruby다운 사고방식으로, Ruby는 이 생각에 비추어 자연스럽게 행동해야 한다는 것이다.

- 출처 입문자를 위한 루비 - 유구이 저

라고 말하고 있다.
자연스럽다는데 막연하다니. 내가 느끼기엔 아무래도 왜? 자연스러운지에 대한 해답은 되지 않을 것 같고 따라서 자연스럽지 않다고 생각하는 사람에게 이렇기 때문에 자연스럽다 라고 주장할 수는 있어도 설득하기엔 근거가 약해 보인다.

(2..100).each do |candidate|
  sqrt = Math.sqrt(candidate)
  factor_found = (2..sqrt).any? {|i| candidate%i == 0}

  if factor_found then
    print "#{candidate}는 합성수\n"
  else
    print "#{candidate}는 소수\n"
  end
end
코드를 처음부터 읽어 내려가며 의미가 통하는 것에 주목하기 바란다.

- 출처 입문자를 위한 루비 - 유구이 저

라고 말하면서 "알고리즘이나 소프트웨어 개발의 보편적인 개념을 설명하는 사람들은 코드 예문으로 Ruby를 이용하게 되었다." 라고 쓰고 있다.
그런데 내겐

1. 일단 아무런 사전 예고 (선언) 없이 나온 변수 sqrt 와 Math.sqrt 가 좀 헷갈린다.
2. (2..sqrt).any?{..} 의 모습을 보건대 2 부터 sqrt 까지 돌면서 {..} 을 수행하고 그 결과가 any? 인지 - 즉 참인 것이 있는지 여부를 따지는 것으로 겨우 짐작할수는 있겠는데, 이게 자연스러운것과 무슨 관련이 있는 건지는 모르겠다.
   
3. if factor_found then ... 를 보고 나서야 factor_found 가 boolean 값이구나 라고 짐작이 가능했다. 솔직히 말하면 if 조건 으로 factor_found 가 쓰인 것 을 보고서야 (2..sqrt).any?{..} 문장이 boolean 을 반환하는지 짐작할 수 있었다. 물론 ? 가 끝에 붙은 메써드는 boolean 을 반환하도록 미리 약속되어있다 라고 알고 있다면 쉽게 이해 되겠지만 어쨋든 한번에 이해하지 못한 내겐 결국 자연스럽지 않았다는 결론에 이르게 된다.
   

자. 자연스러운가?
루비 문법을 아는 사람에게는 아주 자연스러울 것이다.
하지만 내겐 그렇게까지 자연스럽지는 않다. 왜냐면 나는 루비 문법에 익숙하지 않으니까.
그러면 루비 문법에 익숙하면 자연스러워질 것인가?
까놓고 말해보자. 익숙하면 뭐든 다 자연스럽게 느껴진다. ;-)
다시 말하자면 자연스럽다는 것은 너무나 개인적인 감정인 것이다.

내가 이 코드 조각이 생각난 것은 "간만에 세미나를 가서 CUDA 에 관한 발표를 들었다" 는 아는 사람의 글을 보고 나도 시간을 내서 CUDA 를 사용해 보고 싶은데 왠지 CUDA 를 이용해 소수 찾기 알고리즘을 구현해 볼까 란 생각을 했기 때문이다.

모든 일들이 다 그렇듯 어른의 사정은 복잡하고도 미묘하다.
소수 찾기도 위에서 인용한 "자연스러운" 방법으로 접근하면 당연히 경쟁력이 없다.
그러면 루비로 어른스러운 알고리즘을 사용하여 소수찾기를 해 보면 어떨까?
과연 그 어른스러운 알고리즘도 "자연" 스러울까?
굳이 소수 찾기 같은 오덕스러운 분야는 제외한다면, 일반적인 프로그래밍이 얼마나 "자연" 스러울지는 내가 아직 루비 경험이 일천하여 판단하기 어렵다.

Posted by eoh

언제부터인가 개발자 라는 말이 자연스레 프로그래머가 자신을 지칭하는 말이 되어버렸다.
일단 놈 者 자가 붙은 직종 치고 대우받는 게 드물다는 것을 한탄하는 어느 기자 의 말은 차지하고서라도, 나는 왠지 이 개발자 란 어휘가 마음에 들지 않는다.

20세기 말 업계에는 패턴 광풍이 불어친다.
1920년대 시카고도 아닐진대 누구나 갱들의 전설적인 이야기를 했다.
그들의 총구 앞에 모든 문제들은 손을 들 수 밖에 없으며 클라이언트들은 돈을 창구 앞에 쌓아놓고 있으니, 패턴을 따라 그 돈을 가져가기만 하면 되는 것 처럼 보였다.
물론 대부분의 추종자들은 전설의 갱들처럼 그렇게 쉽게 문제들을 털진 못했지만 이건 단순히 패턴을 잘못 적용했기 때문이므로 문제들에게 사로잡힌 불운한 추종자들은 죽음의 행진 중에서도 패턴에 대한 믿음은 깊어져만 갔다.

그때 일련의 쾌락주의자들이 나타났다.
갱들이 그들의 문제 해결을 위해 패턴이란 기관총으로 클라이언트들에게 너희 문제는 이것이고 또한 이것이라야 한다 라고 윽박질렀던 것에 반하여, 클라이언트를 행복하게 해 주어야 문제가 해결된다고 믿는 그들은 클라이언트들이란 자신이 무엇을 원하는지 조차 모르므로 그들과 계속 대화하면서 그들이 진정으로 원하는 것을 알아차릴 때 까지 계속 입안의 혀 처럼 살살 굴러주다 보면 모두가 행복해지는 날이 오고 따라서 문제는 자연스럽게 해결된것과 같다고 주장했다.
모든 문제는 바로 클라이언트가 만족하지 않는다는 한 가지만 중요했던 것이다.
그렇다. 모두가 만족해하고 일정도 맞추고 돈도 챙겨서 떠나갈 수 있으니 흠잡을 곳 없이 좋다.
하지만 마음 깊숙히 왠지 이렇게 사는 것이, 다른 이의 욕망을 채워주는 것을 자신의 목적으로 사는 삶에 대한 왠지모를 불안감은 가시지 않는다.

프로그램이란 특정한 입력값을 받아 해당하는 동작을 하는 일련의 작업을 의미한다고 할 때, 프로그램을 만드는 프로그래머는 자신의 설계대로 자기손으로 만들어진 하나의 창조물이 자신의 의도대로 동작하는 것을 보며 만족감을 느낀다.
개발자 란 말을 들을 때 마다 무엇이 어떻게 되어야 한다 라는 목적에 대한 결정권을 다른 사람에게 맡기고 그저 부여받은 책무에 대해 처리하면 된다는 의기소침한 소시민의 이미지가 떠오른다.

회사를 옮기고 여러 종류의 회의에 참석하게 되면서 알게 모르게 개발자 란 언급을 직 간접적으로 받으며 내가 진정 원하는 것에 대해 한번 더 생각해보게 된다.

Posted by eoh