수작업으로 이전중이므로 시간이 조금 걸릴 것 같습니다. 양해 부탁드리겠습니다.

아래 보이는 글들은 아주 오래전에 쓴 것들입니다. 하나씩 손으로 이전하다 보니 훑어보게 되는데, 그땐 내가 이랬구나 돌이켜 보게 되네요. 비록 유치하고 서투른 글들이지만 글이 모두 이전될 때까지 재미삼아 봐 주세요.

나이를 들면 나쁜 점과 좋은 점이 있다. 나쁜 점부터 말하면 머리가 나빠진다. 기억력, 순발력, 새로운 지식의 습득 능력이 떨어지는 것이다. 좋은 점이라면 경험이 많아진다는 것이다. 많은 것들을 놀라지 않고 받아들일 수 있기 때문에 좀 더 행복에 가까워질 수 있을 것 같다.

하지만 나이가 들어 고지식하다는 소리를 듣는 것은 참 불쾌한 일일 것이다. 보통 고지식한 사고나 행동은 자신이 쌓은 경험의 틀 안에서 모든 것을 해석하려고 할 때 생긴다. 시간이 흐르면서 최신의 경향과 나의 경험 사이의 간극이 벌어지기 때문이다. 따라서 우리는 나이를 먹어 갈 수록 새로운 것을 경험의 틀에 가두기보다는 그 틀이 새로운 것을 포용해 새로운 모습으로 단장할 수 있도록 노력해야 한다. (물론 그게 가능하다면)

곧 스리랑카에서 있을 ApacheCon Asia 2006 발표를 위해 내일 스리랑카로 떠난다. 규모는 유럽이나 미국에 비해 작지만 ApacheCon 최초의 아시아 컨퍼런스에 발표자로 참석한다는 사실이 기쁘다. 최초라는 건 정말 멋지다. 모든 좋은 일의 최초가 되고 싶다.

그런데, 우리 나라 뉴스에서는 언급이 되고 있지 않은 듯 하지만 현재 스리랑카 정부와 타밀 반군과의 휴전이 깨질 기미를 보이고 있어 정국이 매우 불안한 상태라 한다. 혹시 테러나 당하지 않을까 걱정스럽다. 하지만 가야 한다면 가는 수 밖에는 없다. 단 이틀만 머무니까 큰 위험은 아닐 것 같다.

1 Comment

1. 영회 said,

   August 14, 2006 at 12:35 pm

   축하드립니다.

복잡도를 다루기 위해 복잡도를 추가하는 오류는 세상 곳곳에서 행해지고 있는 문제입니다. 이는 대부분 탄성을 자아내는 무지와 게으름, 아집에서 옵니다.

제가 일하던 팀에서는 이런 일이 있었습니다.

당시 C3P0 커넥션 풀을 사용하고 있었는데, 풀 스레드 덤프를 떴을 때 디비 부하로 인해 커넥션을 획득하는 부분에서 대기상태로 있는 스레드들이 아주 많았습니다. 그도 아니면 만에 하나 스레드 풀이 데드락에 걸렸었을 수도 있죠.

팀장은 저에게 커넥션 풀 100줄이면 짤 것을 갖다 써가지고 이런 일이 생긴다고 저를 나무랐고 저는 말도 안되는 이야기 하지 말라고 맞받아 쳤습니다.

커넥션 풀, 100줄이면 짤 수 있습니다. 하지만 javax.sql.DataSource 인터페이스 준수하고 앞으로 있을 몇 가지 기능 추가하다 보면 결국엔 남들이 힘들게 걸어온 길을 별 의미도 없이 다시 걷는 셈이 됩니다. 물론 100줄 짜리 풀을 이야기하는 사람이 그런 표준 인터페이스가 안중에 있겠습니까. 결국 자가당착에 이르러 vendor lock-in 도 아닌 쪽팔린 self lock-in 에 빠질 수 있습니다. 100줄짜리 커넥션 풀에는 버그가 없답니까? 시간이 흐르면서 결국에는 남들이 겪었던 버그를 다시 겪을 수 밖에 없습니다.

사실 이런 일이 세상 여기 저기서 끊임없이 일어나고 있습니다. Logging API부터 시작해서 각종 라이브러리, 그리고 프레임워크까지. 사람들은 사용하는 외부 구성 요소의 내부를 잘 모르기 때문에 그 안에서 문제가 발생했을 때의 어려움을 두려워합니다.

그 두려움을 이해하지 못하는 것은 아닙니다. 또 그 프레임워크를 선택하지 않는 것이 현명할 수도 있습니다. 하지만 그 판단히 단순한 두려움이나 무지에 의한 것이라면 가던 길을 멈추고 ‘생각’을 할 필요가 있습니다.

가끔은 생각보다 많은 사람들이 ‘생각’을 하지 않고 경험을 통한 직관을 가장한 아집으로 문제를 해결하는 모습을 봅니다. 씁쓸하지 않을 수 없습니다. 이런 아집이 관철될 수록 조직은 경직되고 소프트웨어의 복잡도는 끊임없이 증가합니다. 이런 조직에서 잘 나오는 말이, ‘이 소프트웨어는 낡아서 처음부터 다시 짜는게 낫다’ 죠. 한마디로 웃기는 이야깁니다.

물론 우리가 처한 업무 환경이 그런 깊은 생각을 할 만한 시간적 여유를 주지 않고 있는 것도 사실입니다. 그 부분에 대해서는 각자가 현명하게 판단하고 선택해야 겠죠.

4 Comments

1. 짱가 said,

   August 11, 2006 at 5:40 pm

   현명한 분석입니다. ^^
   가슴 깊이 공감이 가네요.

2. 영회 said,

   August 11, 2006 at 6:10 pm

   오랜만에 올라온 글이네요.
   낮에 있던 일로 더욱 공감할만한 글입니다.
   후배 녀석이 프로그램을 잘 짜놓고도…
   처음부터 다시 짜려고 하더군요.
   그 이유는 코드가 허접하다는.. ^^

   스스로도 자주 기존 코드를 버리고 새로 짜왔으니 충분히 이해 하죠.
   하지만, 스스로에 대한 믿음도 없이 하루 하루 살아가는 모습에서 비롯된게 아닌가 하여… 반성하게 되었죠.
   진정한 리팩토링이란 자신과 자신의 일에 대한 믿음에서 한발씩 나아가는 것이 아닌가 생각됩니다.
   그것이 타인에 대한 믿음으로 확장되었을 때, 희승씨가 지적하신 것처럼 중복 코드를 만들어내지 않고, 진정한 협업을 할 수 있겠죠.

3. charlz said,

   August 11, 2006 at 9:12 pm

   소 프트웨어로 한 목표지점에 가는 방법은 여러가지일 겁니다. 그래서 다양한 라이브러리나 프레임웍등이 계속 나오는 것이겠죠. 새로 짜는 것이 일반적으로 나쁘다는 것과 새로 짜면 100줄이면 된다는 것은 다른 목표지점으로 가는 용도와 상황을 따져서 타협점을 찾아야 하는 것이지 한쪽을 고수하는 것은 답이 나오지 않는 이데올로기의 싸움같은 것이라고 생각합니다. 새로 짜더라도 엔지니어링 프랙티스로 어느정도 타임투퀄리티를 줄일 수 있고, 표준이 용도에 맞지 않은 (목표로 가는 방향과는 좀 다른 방향)일 수도 있을 것입니다. “Been there done that”도 위험하고, context를 따지지않는 말씀하신 lock-in도 위험한 것이겠죠.

   갖다 쓴 것이 문제라는 말은 당연히 맞지 않는 말이겠지만, 새로 짜면 이미 다른 사람들이 겪은 것을 다시 겪어 좋지 않다는 것도 단순하게 참인 명제는 아니라고 생각합니다.

   그 일로 화가 나셨나봅니다. 글이 무섭군요.^^

4. ricky said,

   August 22, 2006 at 5:38 pm

   하지만, 100줄 짜리 코드로도 완벽한 컨넥션 풀이 나오면 어쩌죠?