Talk about Software with hani

시작 

2년 전 블로그를 시작한 것은 우연이었습니다. 굳이 블로그의 시작을 찾자면 ‘조엘 온 소프트웨어’입니다. IT 관련 서적을 많이 접했지만, ‘조엘’처럼 IT관련 글을 재미있게 풀어 놓은 사람은 처음이었죠(박재호님과 이혜영님이 번역을 잘 해주신 것도 한몫 했습니다). ‘조엘’의 맛깔난 글은 무척이나 신선했습니다. 한편으로 끝없는 부러움도 느껴졌습니다.

나도 재미난 글을 쓰고 싶다! 

‘조엘 온 소프트웨어’가 잠자고 있던 제 마음 속 ‘글을 쓰고픈 열정’을 깨웠습니다. 그래서 시작한 것이 지금의 ‘Talk about Software with hani’입니다. 물론 당시에는 html 페이지 달랑 하나 만들어 놓고 블로그라고 우겼지만, talk-with-hani.com의 시작은 첫사랑의 설레임처럼 상큼했습니다.

‘조엘 온 소프트웨어’를 접한 것은 일종의 ‘세렌디피티(Serendipity)’였습니다. 블로깅은 자연스럽게 다양한 사고와 경험을 정리하는 계기를 제공했으며, 동시에 새로운 세계로 안내해 주었습니다. 그 중에 하나가 Ruby on rails였습니다. 그리고 우연히 들린 루비 포럼, 그 곳에서 Agile Web Development with Rails 번역 프로젝트를 접했습니다. 번역이라는 새로운 세계로 발을 내딛기에는 낯설음과 약간의 두려움이 느껴졌습니다. 그러나 글을 쓰고픈 열정은 우연이라는 바람을 타고 어느덧 그 두번째 결실을 내놓게 되었습니다.

그리고 세렌디피티의 친구, Positive mind

긴 시간동안, 많은 분들이 고생한 결과가 드디어 3월에 출간됩니다. 인사이트에서 나오는 레일스와 함께하는 애자일 웹 개발(Agile Web Development With Rails)는 Web2.0 세계에 개발들에게 새로운 이정표를 알려주는 책이 되리라 자신합니다. 그만큼 이 책을 번역하면서, 루비의 단순함과 레일스의 강력함에 매료되었기 때문입니다. 물론 번역하면서, 힘듦도 많았지만 어려움을 견디고 이런 결실을 볼 수 있었던 것은 세렌디피티와 함께 다니는 긍정君 덕분입니다. 진짜 새해가 하루 남았습니다. 새해 복 많이 받으시고, 긍정의 힘이 충만한 한해 되세요!

* 2007.03.11 Update
역자 서문

Hanrss에서 제 블로그 이름으로 검색해 보면 6개 정도가 나옵니다. 블로그는 하나뿐인데, RSS 주소가 다양해서 그렇습니다(이름은 하나인데 별명은 서너개인 내 동생도 아닌데 말이죠). 트래픽을 줄여 보자는 차원에서 RSS 주소를 피드버너로 합칠 수 있는 방법을 찾기 위해서 검색했습니다.

당연하게도? FEEDBURNER PLUGIN이라는게 있네요. 설치 방법은 다른 워드 프레스 플러그인처럼 간단합니다. 저처럼 샴쌍둥이 RSS 주소 때문에 고민하신 분들은 꼭 써보시길요. 물론 피드버너를 사용하셔야 한다는 전제 조건이 있습니다.

http://orderedlist.com/wordpress-plugins/feedburner-plugin/

무려 3주를 기다렸던 DREAMING IN CODE를 드디어 손에 넣었습니다. 조엘이 손가락에 땀을 튀겨가며, 칭찬을 아끼지 않았던 책이죠. Post를 쓰기 전까지 2페이지 읽은 것이 전부지만, 흥미로울 것 같습니다. 그런데 문제는 이 책을 읽는 일이 아니라, 책을 지르는 버릇 때문에 책장에 쌓여 있는 책이 대략 스무권이 넘습니다. 우리나라 책은 시간 날 때 읽으면 되지만, 원서를 샀는데 쌓아 두었다가 읽기도 전에 번역서가 나오는 경우, 특히 좋은 역자가 번역한 책일 때는 안타깝습니다. 이 책도 某 출판사가 판권을 사들였다고 하니, 몇 달 안에 번역 출간되겠죠. 안타까움을 다시 겪기 전에 시간내서 읽어야겠습니다.

소프트웨어 유지보수는 해결책이지 골칫거리가 아니다.

소프트웨어 컨플릭트 2.0, 로버트 L. 글래스, 위키북스

요구사항을 제대로 반영하지 못해서 생기는 문제나 품질 문제 때문에 발생하는 유지보수를 제외하더라도, 소프트웨어에서 유지보수는 필연적으로 발생한다.

시간을 X 축으로 두고 사업 환경, 비즈니스 모델, 고객의 눈높이를 그려보면 이 모든 Y의 그래프는 X축을 따라서 변한다. 따라서 변하는 요구사항을 반영하기 위하여 소프트웨어는 반드시 개선되어야 한다. 즉 유지보수는 변하는 요구사항을 반영하기 위한 해결책이지 골칫거리가 아닌 셈이다.

때로는 골칫거리다.

지금으로부터 몇 년전 이야기다. A라는 SI회사가 있었다. 일반적인 SI회사의 주요한 수입원은 SM이지만, A회사는 특이하게도 SI 프로젝트를 수행해서 성장했다. A회사가 클 수 있었던 이유는 SM을 무상으로 1년간 해주었기 때문이다. 즉 계약서 상에는 1년간 무상 유지보수라는 사항이 명기되었지만, A회사는 새로운 SI 계약을 따내기 위해서 무상 유지보수 기간이 끝났어도 개발자에게 무상 유지보수를 해주라고 암묵적으로 지시했다.

따라서 프로젝트가 끝날 때마다, 개발을 담당한 개발자의 유지보수 목록에는 유지보수를 해야하는 새로운 SW가 추가되었다. 운 좋게도 자신이 만든 SW가 잘 사용되지 않는다면 개발자는 구렁이 담 넘어 가듯이 SM에서 벗어날 수 있었지만, 시스템이 대박나는 날에는 유지보수 요청이(새로운 기능 추가 포함) 하루에도 몇 건씩 고객으로부터 나왔다. 즉 어떤 개발자가 대박 프로젝트를 3번 정도 겪고, 현재 참여하는 프로젝트가 하나 정도 된다면, 이 개발자는 보이지 않는 유지보수 프로젝트를 포함하여 총 4개의 프로젝트에 참여하는 셈이다. 따라서 숨겨진 프로젝트를 고려하지 않는다면, 프로젝트 관리 시스템에 표시되는 이 개발자의 생산성은(자발적인 초과 근무를 제외하면) 평균 이하였다. 이 개발자는 낮은 생산성때문에 상관으로부터 좋은 평가를 받지 못했다. 이런 힘든 현실 때문에 가끔은 프로 의식으로 처철히 무장한 개발자라도 자신이 만든 SW가 잘 사용되지 않기를 바라곤 했다.

회사의 정책

극단적인 예이기 하지만, 이런 이야기를 놓고 본다면 소프트웨어 유지보수는 분명히 골칫거리가 맞다. 그러나 긍정적인 관점에서 바라본다면 글래스씨가 지적하였듯이 유지보수는 해결책이기도 하다. 갑돌이도 옳고 개똥이도 옳다는 황희 정승식 논리는 아니다. 다만 유지보수가 진정한 의미의 해결책이 되기 위해서, 경영층이 혹은 관리층이 유지보수를 비즈니스 모델의 어디에 두는지 살펴 봐야 한다. A회사처럼 일종의 돈 안 쓰는 마케팅의 수단으로 생각한다면 유지보수는 골칫거리를 넘어 회사를 공중 분해 시켜 버리는 시한폭탄일 뿐이다.

A회사는 어떻게 됐을까? 유지보수 시한폭탄 때문에 지구 상에서 사라졌다고 한다.