Code Muri

소프트웨어 분야에는 많은 요소 기술이 있다. J2EE, 닷넷, 웹 서비스 등등. 이러한 요소 기술 전문가라는 뜻으로 아키텍트라는 명칭을 붙이기도 한다. 요소 기술 아키텍트는 상대적으로 양성하기가 쉽다. 경험보다는 지식적인 부분이 더 많기 때문에 교육으로도 쉽게 양성할 수 있다. 반면 이러한 요소 기술 아키텍트보다는 전체 개발 프로세스를 이해하고 어떠한 제품도 처음부터 끝까지 개발할 수 있는 체계와 정책을 수립할 수 있는 경험과 지식을 균형 있게 소유한 넓은 의미의 '지휘자 아키텍트'가 바로 최고의 개발자며 또 이들이 절실하게 필요한 것이 한국 소프트웨어 업계의 현실이다. 

 기술이야 말로 개발자의 고유 영역에 속한다. 아무리 지나쳐도 직접적인 해가 되지는 않는다. 하지만 기술은 시대에 따라 변한다. 수많은 기술이 생겨났다 없어진다. ... 기술은 단기적으로 필요한 만큼만 배우면서 사는 것이 효율적이다. 배고플 때 슈퍼에 가지 말라는 말이 있다. 슈퍼에 가서 먹거리를 왕창 사서 오면 결국은 안 먹고 썩어서 버리게 되는 데서 비롯된 말이다. 기술에 관한 한 당장 먹을 만큼만 사오는 것이 효율적이다.

 실제로 이슈를 정확하게 등록한다는 것은 매우 어렵고 초기에는 그럴 필요가 없다. 이슈를 정확히 판단해야 하는 문제는 이슈관리시스템과는 근본적으로 관계가 없는 문제다. 누군가가 해야 하는 문제인데 이슈관리 시스템을 대화의 도구로 사용하는 것이 효율적인 것이다. 이슈관리시스템은 각자 아는 정보만큼만 입력하고, 진행하면서 저절로 데이터가 추가되고 정리되고, 대화를 통해 모든 정보가 투명하게 기록에 남는 것이 핵심이다.

"이슈 등록으로 이슈에 대한 논의를 시작한다" 는 것을 이해하는 것이 중요하다.

 미리 문서를 작성하고 설계를 하는 것인데 실제 전체 개발 기간이 줄어든다. 이것을 진정 믿어야 한다. 이 믿음이 없으면 문서를 작성하라는 말은 공허한 외침밖에는 안 된다. 

코딩은 아르바이트생도 할 수 있다고 필자가 말하면 개발자를 무시한다고 반론을 제기하는 개발자가 많다. 코딩의 정의가 다르기 때문이다. 그들의 주장은 코딩이 어렵다는 것이다. 그런데 이렇게 말하는 개발자가 있다면 그는 SRS 와 설계문서 없이 개발하고 있는 것이다. 필자 경험상 거의 100%다. 코딩한다는 이름 아래 동시에 분석도 하고 설계도 하고 있는 것이다. 그것을 코딩이라고 한다면 그의 주장대로 그건 세상에서 가장 어려운 일일 것이다. IEEE가 SRS를 작성하는 것이 개발에서 가장 어려운 작업이라고 했으니 SRS도 없이 코딩하는 것은 얼마나 어렵겠는가? 어렵게 느껴지는 건 그것이 코딩이 아니기 때문이다. 코딩이라는 이름으로 포장된 분석, 설계가 어려운 것이다. 

간혹 연구소장, 개발실장, R&D 부사장 등의 직함이 CTO와 혼란을 일으킨다. 이들과 CTO를 구별 짓는 가장 중요한 기준은 CTO는 인사관리를 안 한다는 것이다. 연구소장처럼 '장'자가 붙는 사람은 부서원을 관리해야 한다. '장'의 권위를 즐기는 대신 사람관리를 위한 시간이 엄청나게 들어간다. 역시 CTO가 되기에는 시간상으로 모자란다.

 구글의 CEO인 에릭 슈미트도 필자가 썬마이크로시스템즈에 근무하고 있었을 때 CTO를 했었다. 그는 Unix의 유명한 구문분석기인 lex를 개발한 대단한 개발자다. 에릭 슈미트처럼 CTO가 비즈니스 감각을 배우고 CEO로 전향한 경우도 많다. 하지만 그 순간부터 CTO로부터는 멀어져 간다. 빌 게이츠나 에릭 슈미트처럼 소프트웨어를 이해하는 CEO 아래서 일을 한다는 것은 개발자에겐 행운이다.

 "과거를 자랑하지 마라. 자랑할 과거밖에 소유한 것이 없을 때 처량해 진다" 셰익스피어

CEO가 요청을 하지 않더라도 최종테스트에서 결함이 발견되어 고칠 것인지 말 것인지를 결정하는 프로세스도 같은 맥락이다. 통상적으로 그런 마지막 회의를 "Go-Live 회의"라고 하는데 결함이 있는 상태로 출시할 것인지 말 것인지를 결정하는 회의다. 

돈은 안 벌고 낚시만 하고 있는 사람을 옆에서 지켜보던 구경꾼이 불쌍하게 생각한 나머지 이렇게 물었다.

"그렇게 낚시만 하지 말고 돈도 좀 벌어야 하지 않겠습니까?" 

낚시꾼이 되묻는다.

"왜 돈을  벌어야 하지요?"

"나중에 하고 싶은 일을 하려면 돈이 있어야 하지 않을까요?"

구경꾼이 또 물었다.

"나는 지금 바로 내가 하고 싶은 일을 하고 있습니다."

낚시꾼의 대답이다.

분할발주는 분석이 끝난 후에 설계/구현 단계를 다른 사람이 하는 것이 통상적이다. 거기에는 심오한 이유가 있다. 한국에서는 분석/설계/구현을 통으로 발주한다. 발주를 하기 전에 RFP(제안요청서)와 Proposal(제안서)라는 단계를 거쳐서 나름대로 비용과 일정을 산정하고 계약한다. 그런데 계약을 하는 시점에서 일정과 비용을 산정한다는 것은 불가능하다. 그러니 나중에 얼마나 문제가 많을지 짐작이 간다. 사실은 이 문제가 국내 소프트웨어의 중소 하청업체가 고생하는 이유다.

현재 개발하는 관행을 보면 분석단계에는 업무를 잘 아는 사람이 투입된다. 바로 업무전문가다. 이 단계에서는 전문적인 소프트웨어를 분석가라고 해도 그 사람이 업무를 모른다면 끼지도 못한다. 여기부터가 잘못됬다. 업무를 알아야 분석이 가능하다는 믿음이 오해라는 것을 모르기 때문이다. 

만약 시간이 없어서 스펙을 적지 않고 코딩하는 개발자라면 지금 당장 시간을 투자하여 악순환의 고리를 끊길 바란다. 지금 못하면 시간이 가면 갈수록 점점 더 어려워진다. 

 첫 번째 개발자가 "지금 코딩하고 있어요."

두 번째 개발자가 "연봉 5,000만 원짜리 일을 하고 있어요."

세 번째 개발자가 "세상 사람이 사용할 소프트웨어를 만들고 있어요."

미래에 누가 소프트웨어 전문가가 되어 있을지 자명하다. 세상 사람이 사용할 소프트웨어를 만든다고 생각하는 사람이 대충 만들려고 하지는 않을 것이다. 

자신이 시도하기 전에 모든 것을 이해해야 한다고 하는 태도 역시 폐쇄적인 태도다. 

개발자 평가

1) 스펙은 적는가?

2) 동료검토는 자주 하는가?

3) 자기 관련 문서를 제대로 업데이트하는가?

4) 소스코드를 체크인할 때 주석을 제대로 남기는가?

5) 모든 버그나 기능 추가사항은 이슈관리시스템에 등록하고 일하는가?

인터넷 세상은 표면적인 전문가를 양산하여 역작용을 일으키기도 한다. 자기가 그 지식을 사용하여 혜택을 얻는 것은 어렵지만 남을 비판하는 데는 아주 쉽게 사용할 수 있기 때문이다. 결국 할 줄도 모르는 헛똑똑이가 아는 척하는 일이 과거에 비해 훨씬 더 많아졌기 때문에 지식과 경험의 차이가 점점 더 커지는 세상이 되었다.