어떤 어려움도 기회로 반전시킬 수 있다. - It's not Luck (The Goal 2)

위기는 위태로운 기회다라는 말과도 통하는 것 같다. 어떻게 보면 강한 제약조건이 있을 때 더 높은 수준의 창의성을 발휘할 수 있다는 이야기와도 통하는 듯. 워드 커닝햄이 프로그래밍 중에 문제를 발견했을 때 당황하거나 짜증을 내기보다 흥미로움을 표시하는 것으로 대응을 시작한다는 이야기도 비슷한 이야기일까?

하지만 누구나 이런 기회를 잡을 수 있는 것은 아니다. 다행스럽게도 우리 프로젝트팀도 한 번은 위기를 기회로 전환시키는데 성공했다. 나 개인적으로도 몇 번은 위기를 기회로 바꿔낸 경험이 있다. 반대로 위기에 좌절한 기억도 있다. 차이는 무엇일까?

내가 잠정적으로 내릴 수 있는 결론은 문제를 대하는 태도다. 단순히 긍정적인 자세만으로는 위기를 기회로 바꿀 수 없다. 문제를 비판적으로 생각할 줄도 알아야 한다. 물론 비판적인 것만으로도 안된다. 일견 모순적으로 보일 수도 있는 긍정적이면서도 비판적인 자세가 위기를 기회로 바꿀 수 있는 힘이다.

요즘 뭔가 내가 소모되고 있다는 느낌이 든다. 여러 모로 생각해본 결과 가장 큰 이유는 퇴근 시간인 것 같다. 회사가 분당으로 이사간 후 퇴근 시간이 확 늦어졌다. 퇴근 시간인 7시가 되면 무언가 아쉬운 느낌이 들어서 조금 뭉기적 거리다보면 밥 안 먹을 때는 7시 반에서 8시 사이에 퇴근하게 되는데 집에 도착하면 9시가 넘는다. 밥 먹기엔 너무 늦은 시간. 그렇다고 밥 먹고 퇴근하면 9시 반은 우습게 넘는다. 그러면 나에게 주어진 자유시간(?)은 3시간도 채 안되는 셈이다. 하루의 일과에서 일과 잠을 빼버리면 너무 초라해진다. 이것저것 문어발처럼 많던 관심사도 대부분 접었다. 일에서 성공하는 것도 중요하지만 내가 일하기 위해 사는 것은 아닐 텐데...

얼마 전 원일이를 만났다. 이제 내 친구가 의대생이 아니라 의사인 나이가 되었다. 술 마시면서 들어보는 의사의 삶은 솔직히 그닥 부럽지 않았다. 아니, 오히려 안쓰럽게 느껴지기도 했다. 주말은 그래도 쉬는 모양이지만 평일에 하루 10시간 이상 근무를 한다. 그래서 일은 재밌냐고 물어보니까 일도 재미 없댄다. 그 때는 그 이야기들을 들으면서 오히려 좀 애처로운 느낌마저 들었다. 일도 재미 없고 평일엔 자기 시간도 없고 그럼 삶의 낙이 무엇일까.

근데 지금 생각해보면 나랑 얼마나 큰 차이가 있는 걸까 하는 생각이 들기도 한다. 영주랑 같이 살면서도 정작 영주랑은 하루에 30분도 이야기하지 못한다. 예전엔 선화도 거의 매일 만났는데 요즘은 그러지도 못한다. 그러다보니 하루가 가는 게 아쉬워 일찍 자기가 싫어지고 이것저것 쓰잘데기 없는 것들을 하다가 늦게 자게 된다. 일이 아무리 재밌어도 내 가족, 내 친구와 함께 보낼 수 있는 시간이 이것 뿐이라면 정말 슬픈 일이다. 정말 이것이 직장인의 운명일까?

얼마 전 워크샵 때 실장님이 본인이 정말 즐겁게 일할 수 있다면 하루 4시간 근무하게 하는 것도 고려할 수 있다는 이야기를 하셨다. 물론 연봉도 반 깎고-_- 당시에는 내 이야기도 아닌지라 별 생각 없이 넘겼는데 지금은 웬지 끌리는 제안이다. 당장의 돈 몇 푼보다 SustainablePace가 더 중요한 것 아닐까. 이게 어쩌면 정말 내 퍼포먼스가 더 높게 나올 수 있는 방법일 것 같기도 하다.

근데 이제 내가 자기 전에 아쉬운 마음이 드는 건 알겠는데 회사에서 퇴근하기 전에 아쉬운 마음이 드는 건 또 왜일까. 단지 프로젝트의 진행이 느리기 때문에? 아니면 회사 컴터가 집 컴터보다 좋아서? 이 문제는 좀더 생각해봐야겠다. 어쨋든 당분간은 7시 땡하면 칼같이 퇴근하는 습관을 다시 찾는 것이 좋을 것 같다.

RubyOnRails를 실무에 적용한지 한 달 남짓이 되었다. 써본 감상이 그리 좋지만은 않다. 우선 Ruby라는 언어. 순수 객체지향이면서 깔끔한 문법으로 보기 좋은 코드를 만들어낸다... 이게 Rubyist들의 주장인데 이제 이 주장은 동의할 수 없다. 오히려 Ruby로 만든 코드들을 보면 정말 읽기 난해한 코드가 많다. Rails와 Rails 플러그인의 코드 퀄리티도 만족스럽지 않았다. 오히려 괜찮은 자바 프레임웍의 코드 퀄리티가 더 높다고 느껴질 정도였으니까. 물론 코드 가독성을 결정짓는 가장 큰 요소는 프로그래머의 능력이지 프로그래밍 언어가 아니기 때문에 이런 문제는 Ruby 언어의 책임이 아니라고 할 수도 있다. 하지만 내가 보기엔 루비 코드를 읽기 어렵게 만드는, 그리고 agile language라고 불리면서도 초보자에게 어려운 언어로 남아 있는 이유가 몇 가지 있는 것 같다.

가장 문제가 되는 것은 유의미하게 사용하는 기호가 너무 많다는 것이다. 다른 언어에서는 키워드를 사용하는 것을 기호로 표현하기도 하고 단일 개념으로 쓰는 것을 분리해서 여러 개의 기호로 사용하기도 한다. 이를테면 this.을 @로 쓰고 static 멤버는 @@로, extends 대신 <를, isXXX 대신 XXX?를 사용한다. static 선언은 ClassName::methodName과 같은 형식으로 선언한한다. String이지만 key 역할을 할 때 사용하는 심볼은 :string과 같이 사용한다. 이런 기호들이 하나하나 뜯어보면 같은 내용을 함축적으로 간결하게 표현할 수 있기 때문에 좋은 점이 있고 개념적으로도 좋은 것들이 많지만 이런 것들이 하나 하나 늘어날수록 언어의 복잡성이 증가하고 코드의 많은 부분이 기호로 뒤덮이게 된다. 앞서 말한 것처럼 기호는 간결한 표현과 함축성이 장점이기도 하지만 반대로 기호를 모르는 사람과의 의사소통을 저해하고 학습 장벽으로 높이는 단점이기도 하다. 학습 장벽이 높다는 것은 그것만 넘어서면 편해지는 그런 게 아니다. 문법을 늘 기억하고 있어야만 쓸 수 있다는 것이다. vi 에디터와 같은 단점을 갖고 있는 것이다.

비슷한 역할에 여러 개의 개념을 사용하는 것이 많다는 것도 단점이다. 그 단적인 예가 클로저 역할을 하는 루비 블럭이다. 루비의 가장 큰 장점이라고들 이야기하지만 요즘 클로저 없는 언어도 별로 없는데 클로저 있는 언어 중에서는 제일 좋지 않은 방식으로 구현된 것 같다. 다른 언어들은 메소드나 함수의 문법과 거의 유사하게 구현이 되어 있고 클로저 자체도 객체로 메소드의 인자로 들어갈 수 있는데 루비에서는 인자도 아니면서 루비의 다른 문법들과 비교해도 예외적인 방식으로 전달되고 yield로 호출된다. 순수 OOP라고 주장하는 루비에서 루비의 가장 큰 장점이라는 루비 블럭이 객체가 아닌 것이다. 루비 블럭의 syntax sugar인 {} 때문에 실제로 클로저가 필요한 게 아니라 단순히 함수가 필요한 경우에도 클로저를 많이 쓰는데 그러다보니 이 클로저는 객체가 아닌지라 리팩토링하기가 좀더 어렵고 그래서 많은 루비 코드에 클로저의 중복이 심하게 나타난다.

사실 따지고 보면 이 두 가지 문제는 비슷한 이야기다. 하나하나의 개념은 좋지만 그런 개념들이 지나치게 잘게 나뉘어 있고 개수가 너무 많기 때문에 Ruby는 공식 스펙 문서조차 만들기 힘든 복잡한 언어가 되버린 것이다.

요즘 또 많이 사용하는 언어인 JavaScript와도 여러 면에서 비교가 되는데 내가 보기엔 JavaScript가 문법적으로는 좀더 깔끔하고 명쾌한 것 같다. 그러면서 Ruby에서 할 수 있는 건 거의 다 할 수 있고 개념 자체가 몇 개 안되서 배우기도 정말 쉽다. TDD할 때도 Ruby는 dynamic language치고는 MockObject 만들기가 좀 불편한데 JavaScript는 PrototypeBasedLanguage라서 이런 게 정말 편리하다. 파이썬과 비교해도 파이썬 쪽이 좀더 쉽고 간결한 것 같다. python 코드들은 실제 사용하는 라이브러리 코드를 봐도 정말 잘 만들었다고 감탄한 적이 많은데 루비는 예제로 나오는 코드들만 와~ 하게 만들 뿐, 오픈소스로 퍼져 있는 루비 라이브러리들은 그런 느낌이 드는 경우가 별로 없다.

그래도 루비의 장점을 몇 가지 꼽을 수는 있다. 가장 크게 다가오는 장점은 함수 호출 시 ambiguous하지 않을 때는 괄호를 생략할 수 있다는 것. 이것이 미려한 DSL을 만드는데 결정적인 역할을 하는 것 같다. 모든 메쏘드가 마지막 문장을 return 값으로 갖는다는 룰도 상당히 편리하다. statement 뒤에 if나 unless로 조건을 걸 수 있다는 것도 장점. 파이썬에도 이번에 비슷한 문법이 추가되었는데 괜찮은 것 같다.

루비 이야기만 하다가 길어져서 레일즈 이야기는 다음에...

여기에 대한 반론으로 [http://myruby.net 강모씨]가 보내온 코드. 참고로 [http://myruby.net 강모씨]는 언젠가 "그래, 자바스크립트가 루비보다 문법은 명확하고 쉬워서 좋긴 하지."라는 발언을 한 바가 있다는...

>> def test_method
>>   yield
>> end

>> test_method { puts 1 }
1

>> p = lambda { puts 1 }
=> #<Proc:0x00546dc0@(irb):11>
>> test_method &p
1

>> def test_method2 p
>>   p.call
>> end

>> test_method2 p
1
>> test_method2 lambda { puts 1 }
1

• 아마도 블럭도 객체로 사용할 수 있다..라는 반론을 하고자 한 듯. 그러나 여전히 p를 넘겨야 하나 &p를 넘겨야 하나, yield를 해야 하나 p.call을 해야 하나.. 개개의 feature는 그럴 듯하지만 feature의 개수가 쌓이면서 문법의 복잡도가 증가하는 문제는 여전히 남은...

그리고 Symbol과 String에 대해서도 다음과 같은 코드를 보내왔는데...

>> hash = {}
=> {}
>> hash['test'] = 'val'
=> "val"
>> hash[:test] = :val
=> :val
>> hash.inspect
=> "{:test=>:val, "test"=>"val"}"

오류 정정이라 하는데 무슨 오류인지 설명 안해줘서 잘 모르겠삼. Symbol과 String이 equavalent 하지 않고 다르다는 말을 하고 싶었던 것일까. What I meant is there are two similar ways - but not so different - to do the same thing.

내 MBTI가 ENTP에서 ESTP로 바뀌었다. 김창준씨의 설명에 의하면 N은 사물을 볼 때 숲을 먼저 보고 추상적인 사고 방식에 능한 것이고 S는 나무를 먼저 보고 실체에 접근하는데 능한 것이라고 한다. 생각해보면 정말 그렇게 바뀐 것 같다. 예전에 나는 머릿속으로 큰 그림을 그리는 걸 좋아했다. 무언가를 할 때는 늘 머리 속으로 다 그려놓고 시작하곤 했다. 그러다가 성향이 변하기 시작한 것은 XP를 하면서부터. 꼭 XP가 N보다 S랑 친하다고는 할 수 없겠으나 N에 치우쳐 있는 기존의 개발방법론에 비교하면 상대적으로 S에 가까운 느낌이다. Just Do It!의 느낌이랄까. 그래서 언젠가부터 멋진 설계를 해내는 것보다 좀 허접하더라도 실제로 무언가 만들어 내는 것이 중요하다고 생각하기 시작했다. 그러면서 그런 생각에 따라 성향도 바뀌기 시작한 것 같다.

근데 생각해보면 이 방식이 나한테 맞는 것 같다. 생각해보면 내가 무언가에 성공적이었을 때는 S적인 방법으로 시도했을 때였다. 고등학교 때 프로그래밍 동아리에 들었을 때도 그랬다. recursion을 처음 배우면서 선배가 하노이탑 문제를 내줬을 때 나 이외의 다른 애들은 전부 알고리즘 자체에 집중했다. 그래서 그냥 숫자만 입력 받고 결과도 숫자로 뿌려주는 걸로 문제를 풀어냈다. 근데 나는 알고리즘은 제쳐두고 일단 문제를 눈에 보이게 만들었다. 파스칼의 그래픽 라이브러리를 익힌 다음 세 개의 고리를 그리고 원판을 그려넣었다. 그러고 나서 알고리즘 구현을 시작했다. 미로찾기를 풀 때도 마찬가지였다. 다른 애들은 모두 미로찾기의 풀이를 좌표 순서로만 찍어냈는데 나는 화면에 그렸다. 괘선의 방향까지 맞춰가면서. 열역학을 처음 배울 때도 그랬다. 처음 몇 시간을 졸아버린 탓에 선생님이 떠드는 이야기는 전혀 알아먹을 수가 없었고 책을 봐도 이론은 머리에 들어오지 않았다. 그래서 내가 선택한 것은 무작정 문제를 푸는 거였다. 풀다보니 어느 새 개념이 머리 속에 들어와 있었다.

그런데도 N의 방식으로 살아왔던 것은 이런 S적인 방법이 몇 번 실패했기 때문인 듯하다. 올림피아드에서는 제한된 시간 안에 문제를 풀어야 하는데 시간이 적다보니 조급한 마음에 평소처럼 시각화에 여유 있게 시간을 쓰지 못하고 어정쩡하게 하다가 이도 저도 아닌 결과가 나왔고 결국 국내에서도 입상하지 못했다. 대학에 가서도 라인 트레이서 만들 때 알고리즘을 그래픽 시뮬레이션으로 먼저 만들어서 알고리즘을 확인하고 만들었는데 정작 그 알고리즘을 기계와 연결시켰을 때는 생각처럼 동작하지 않았었다. 생각해보면 납땜 실수거나 회로 연결 찾오일 수도 있는데 그 때 난 엉뚱하게 시뮬레이션과 현실의 괴리 따위의 생각이나 했었다. 사실은 좀더 S적인 방법으로 나갔다면 더 좋은 결과가 나올 수도 있었을 텐데.

그리고 약간의 착각도 작용했다. 중학교 때 어렵다는 수학 문제를 머리로만 풀면서 내가 그런 걸 잘한다고 생각했었던 적이 있었다. 하지만 지금 생각해보면 그건 중학교 수준이었기 때문에 가능했던 것이지 내가 원래 머리 속으로만 문제를 푸는 걸 잘하는 스타일은 아니었다. 생각해보면 복잡한 수식이 나오는 단원은 맨날 헤맸지만 그래프나 도형 같은 게 나오는 단원은 잘 따라갔었으니 나에게 맞는 방식은 원래부터 S였을 것이다.

어쨋든 결과적으로는 S에서 시작해서 N을 거쳐 S로 돌아온 지금이 좋은 것 같다. 어떻게보면 XP에서 말하는 design enough to get going이랑도 비슷하지 않을까.

강모씨와 송모씨가 겜하다가 망가뜨린 내 알육이의 액정을 드디어 A/S 받았다. 예비군 하는 날이 오후 시간이 남아서 좋은 점도 있긴 하군. 신림동 LG 서비스 센터에 자전거 타고 갔는데 참 친절하다. 무상 A/S 기간 약간 지났는데 그냥 액정 무상 교환 해주니 기분이 좋다. 직원들도 친절하고. A/S 하는 동안 매장 둘러보니까 마침 새로 출시된 A1이 눈에 띈다. C1이 없는 게 좀 아쉬웠지만 A1, 정말 괜찮다. 전에 삼성 Q30 봤을 때랑 비슷한 느낌이다. 물론 그 때보다 세월이 많이 지났으니 훨씬 좋다. C1도 써보고 싶었는데 하필 그건 매장에 진열되어 있지 않았다. 이 정도 이슈 거리가 되는 제품은 좀 매장에 진열해놔야 하는 거 아닐까. 소니 매장 갔을 때도 UMPC 진열 안되어 있어서 좀 실망했는데 LG도 이게 오늘 옥에 티였다. C1은 딱 내가 원하는 사양인데 가격이 좀 부담스럽다. A1으로 미루어볼 때 발열도 좀 심할 것 같고.

우분투에 beryl을 설치했다. 전에 잠깐 봤던 compiz보다 훨씬 좋아졌다. 회사 컴에도 설치해야지. 리눅스의 GUI가 이제 Mac, 윈도우를 앞지르려 하는 것 같다. 실험적인 시도도 많이 이루어지는 것 같고. 집에서도 컴터 좀 업해서 리눅스를 메인으로 쓰고 VMWare로 윈도우 돌릴까나.