생각하고 나누고 공감하기...

인터넷이 프로그래밍 환경에 많은 영향을 주고 있다. 오픈 소스가 지각 변동을 일으켰고 지금도 수 많은 아이디어가 어느 구석에서 튀어나와 즐거움을 줄지 늘 흥미롭다.

하지만 이런 활력 때문에 불편한 마음이 드는 면도 있다. 새로운 기술을 익히는 것에 익숙해져 있는 삶이지만 그래도 뭔가 새 것을 배운다는 것은 어렵다. 특히 일 때문에 한정된 시간 내에 성과를 내야 하는 상황에서는......

개발자로 살아오면서 자기가 잘났다고 하는 수 많은 기술들을 접했었고 관심을 보이다 아쉬워하며 흘려 보냈다. 돌이켜보면 이제 더 이상 의미 없는 시도들이 대부분 이였지만 당시에는 모두 익혀야 하는 기술들 같이 보여 그 기술들에 투자하지 못하는 내가 죄스럽기까지 했었다. 컴파일러를 만드는 기술에서부터 Ray Tracing까지 마소에 나오는 것들은 일단 다 관심을 보였었으니......

요즘처럼 이런 저런 기술들이 어지럽게 눈앞을 떠돌아 다니는 상황에서, 어떻게 하면 길을 잃지 않고 좋은 기술 쇼핑을 할 수 있을지에 대해 나 나름대로의 기준을 한번 정리해본다.

레이더 가동

예전부터 흔히들 하던 말이지만 Know How 만큼이나 Know Where이 중요하다. 매번 뭔가 새로운 도전에 직면해야 하는 프로그래머에게 관련 기술에 대한 인덱스가 머리에 없다면, 적어도 어디서 본 것 같은데...... 라고 할만한 기억조차 없다면 능력 없는 개발자로 낙인 찍히기 쉽다.

가끔 시간이 될 때 마다 인터넷을 돌아다니면서 새로운 용어나 토픽이 오가는지 살펴보면 좋다. 이런 얘기들이 빨리 거론되는 좋은 커뮤니티를 몇 군데 알아두는 게 도움이 된다. 동료들 사이에 정보를 교환하는 것도 좋다. 발 빠르게 정보를 전달해주는 좋은 잡지를 알고 있으면 좋지만 인터넷에 비해 인쇄매체는 너무 늦고 지면이 한정적이다.

그러나 새로운 것에 너무 시간을 들이지 않는 게 좋다. 그걸 다 살펴보다가는 일 할 시간도 인생을 즐길 시간도 없어지게 된다. 얼마나 새로운 아이디어가 넘쳐나는지...... 어쩌면 정신 분열증에 걸리게 될지도 모른다. 나한테 정말 필요한 기술이 그 새 아이디어들 중에서 1%나 될까? 물론 대부분은 얼마 안 가서 사라져버린다.

그냥 대충 어떤 것인지...... 개요 정도...... 관심이 있고 시간이 되면 간단한 샘플 정도만 살펴보고는 덮어라.

익숙함의 힘

기존의 기술을 대체하는 어떤 신기술이 좋다고 하더라도 당장 그 효과가 나타나는 것은 아니다. 요즘은 기술 발달이 빠르기 때문에 익숙해진다는 것을 느끼기 어려운 상황이다. 하지만 기술 자체가 주는 힘 보다 그 기술이 내 것이 되어서 내 수족처럼 다룰 수 있는 상황이 되었을 때 발휘 힘은 놀라운 것이다.

익숙함의 가장 중요한 이점은 안정감이나 자신감이다. 과제가 주어졌을 때 매뉴얼을 뒤져보지 않아도 그 기술의 언어로 해법이 머리에 그려지는 것만큼 일을 하는데 도움이 되는 것도 없다. 얼마나 많은 업무 시간을 어찌해야 할지 몰라서 궁리하면서...... 또는 익숙하지 않은 기술 때문에 실수를 반복하면서 보내는지......

그리고 어떤 기술에 익숙해지면 그 기술의 문제점이나 한계를 극복하는 방법도 나름대로 터득하게 된다. 소림사에서 아무리 좋은 무술을 익혔다 해도 길거리 싸움패에게 이긴다는 보장은 없다.

다음 그림에서 가로는 기술의 숙련도이고 세로는 그 기술의 효용성이다. 어떤 두 기술자가 각각 다른 기술을 가지고 있다고 했을 때 각 기술자의 능력은 원점에서 위치까지의 거리 아닐까?

물론 신기술을 익히면 취직할 때 좋을지도 모르겠다. 하지만 실무에 투입 되보면 알겠지만 신기술이 실무에서 쓰이는 경우는 많지 않다.
의존성 문제

외부 기술을 도입하면 그 기술에 의존하게 되는 것이란 사실을 잊으면 안 된다. 당장 문제를 해결해 줄 수 있지만 장기적으로 튜닝의 어려움, 해결 안 되는 버그, 프로젝트 와해 등으로 어려움이 생길 수 있다. 잘 나가는 것 같아 보이던 프로젝트가 순간 잘못되어 없어지고 유지가 안되서 어려움을 격는 경우도 많다.

그리고 그 기술이 또 다른 기술에 의존하고 있다면 문제는 더 심각해진다. 아주 단순한 문제를 간편하게 해결하기 위해 도입한 라이브러리가 복잡한 의존성 때문에 문제가 되곤 한다. 어떤 버전에서는 잘 돌아가다가도 새 버전에서는 문제가 되기도 하고 통합해야 하는 다른 모듈이 해당 라이브러리와 충돌을 일으킬 수도 있다. 그렇지 않더라도 사용하지 않는 코드들이 내 코드에 덕지덕지 붙어 있는 것은 기분 나쁘다.

오라클 같은 DB로 작업하다 보면 종종 오라클 JDBC나 DB의 버그 때문에 당황한 적이 몇번 있다. 오라클을 선택하지 않을 수 있는 방법이 없으니 버그를 우회해서 처리하게 되지만 오라클도 그 정도인데 다른 기술들은 어떨지... 내가 너무 조심성 없게 쉽게 믿는 것은 아닌지 생각하게 된다.

필요할 때 = 적시

예전에 모시던 사장님이 미국에 출장을 가셨는데 돌아오시는 길에 S/W를 몇개 사시려고 Best Buy에 들어가셨단다. 당시는 windows 3.1을 주도 쓰던 때라서 그것을 사려고 하는데 진열장에 Windows for workgroup이라는 놈이 있었다고 한다. 이건 어떤 버전인가 몰라 궁금해 하다 직원에게 어떤 것인지 물어봤더니 그 직원이  말하길

'이것이 뭔지 모르는 것 보니 손님은 이 제품을 살 필요가 없는 것 같습니다.'

사람이 빵만 가지고 살 수 있는 것도 아니니 필요 없는 것을 지르는 것을 뭐라고 할 수는 없지만 합리적으로 생각했을 때 기존 기술이 아무런 문제도 없는데 새 기술을 도입해서 비용을 치르고 위험을 감수 하는데 동의 할 사람은 없다고 본다.

그림에서 구기술은 시스템이 복잡해지면서 그것을 처리하는데 비용이 늘어나게 되고 어느 시점에서는 한계상황에 이르게 된다. 반면에 이 문제를 해결하는 신기술은 초반에 도입비용이 들지만 시스템의 복잡한 문제를 잘 해결해준다. 당연히 도입의 적시는 기존기술보다 신기술이 이득이 되는 시점에서 기존 기술이 한계상황에 이르기 전인 어떤 시점이다.

사람의 중요성

늘 잊어서 안 되는 것은 이 기술을 사용 할 사람들이다. 팀원들이 소화할 수 없는 기술은 아무리 좋은 것이라 하더라도 도입하면 안 된다.

어려운 기술의 도입은 프로젝트에 소요되는 비용을 배가시키는 요인이 된다.

아키텍쳐의 욕심 때문에 프로젝트의 대부분을 개발자 교육에만 투입해야 하는 상황을 누가 이해할 수 있을까?

혁신

지금까지 좀 보수적인 기준을 제시했지만 항상 잊어서는 안 되는 것이 기술을 통한 혁신이다. 종종 진짜 혁신적인 기술이 나타나곤 한다. 그전의 어떤 것과도 비교 할 수도 없는.....

솔직히 기술의 이런 측면이 아니라면 개발자로 계속 살아가는 의미가 없다고 본다.

늘 보수적으로 판단하되 이 혁신의 기회를 놓치지 않도록 열린 마음을 갖는 것이 좋다.

그럼 혁신을 가져다 주는 기술은 어떻게 알 수 있는가?

그것은 직관이라 생각한다.

늘 합리적으로 생각하려 말고 번개가 내려치듯 갑자기 확신하게 된 그것을 믿고 나아가라. 그 길이 항상 성공한다는 보장은 없지만 이 길 말고 혁신에 이르는 길은 없다.

솔직히 인생에 한두 번은 이런 확신 때문에 회사를 뛰쳐나가는 것도 해 볼만하다고 생각한다.