몇 일전 SI 개발자로 일하시는 한 분으로 부터 메일을 받았습니다. 과거 포스팅한 내가 IT를 떠나지 않는 이유(1) 라는 글을 읽으신 후 공감하신다는 의견을 주셨습니다. 다시 당시 쓴 글을 읽고 다시 한 번 S/W 개발자로서의 내 삶에 대해 생각해 봅니다.

학부때 부터 컴퓨터에 손을 대었으니 어느덧 컴퓨터와 함께 해 온 시간이 20년이 넘은 것 같습니다. 물론 학부때에는 컴퓨터 프로그램과 함께 인생을 살게되리라고는 전혀 생각하지 못했었는데  인생이 돌고 돌다 보니  여전히 컴퓨터  자판과 프로그램이 가장 친숙한 벗이 되어버렸네요.


S/W 개발자로서의 삶은 3단계의 허물을 벗는 과정을 거친다고 생각합니다.

첫번째는 요구사항에 맞춰 열심히 코딩하는 Just Doing 단계의 삶
다음으로,  그 과정을 지나면 요구사항을 풀기 위해 열심히 설계하고 이에 맞춰 코딩하는 Design & Coding 단계의 삶
그리고 마지막 단계로서 무엇을 만들어야 성공하고(What to do?) , 어떻게 만들어야 하는지의 (How to do?) , 그리고 가장 어렵고 중요한 개발 관리 단계의 삶



1999년 창업을 하기 전까지는 자의 반, 타의 반으로 Design & Coding 단계에서 웹과 객체지향 DBMS , CORBA 등의 기술을 사용해서 Design & Coding 을 행복하게 했었던 것 같습니다. 새로운 것을 좋아하는 강한 습성과 열정이 있었지 않았나 싶습니다. 그 후, 회사를 창업하고 하나의 시장을 놓고 경쟁해야 하는  냉혹한 현실에서 살아남기 위해  새로운 시장을 찾고(Planning /what to do), 경쟁 회사와 제품을 분석하고 새로운  제품을 설계하며(Design , How to do) 열정이 넘치는 개발자들과 밤낮을 새며 제품을 개발(Coding, Just doing)했었던 것 같습니다. 그 과정이 지금까지 지속되어 벌써 10년이 되어 버렸네요.

나는 행복한가?

대답하기 어려운 질문이지만 지난 10년 동안 S/W 개발자로서 삶을 후회해본 적은 없었던 것 같습니다.  CEO로서 직원들과의 이해관계에서 발생하는 여러 문제들, 매출과 수익에 대한 부담감, 투자가들에 대한 책임감 등은  너무도 많은 상처를 주었지만.....



왜 행복한가?

새로운 시장을 찾고 그 시장에서 경쟁할 제품과 서비스를 기획,설계하고 뜨거운 열정과 개발 과정을 통해 맛보는 성취감을 사랑했던 것 같습니다. 이러한 열정이 없다면 행복하지 않았을 텐데요.


앞으로도 행복한가?

마지막 단계에 와 있는 개발자로서, 초심같은 열정을  갖을 수 만 있다면 행복하지 않을까요?! 물론 현실을 무시할 순 없겠지만 열정을 갖고 미래를 준비하고 , 기회가 오면 그 기회를 잡는  결단을 통해 행복을 만들어야 하지 않을까 싶습니다.  아마 10년 후에도 소프트웨어 개발 분야에서 일을 하고 있겠지만 그 때도 행복하고 싶습니다.

미국 대기업에서 인력 개발 팀장과 부사장 등을 역임했던 신시아 샤피로의 "회사가 당신에게 알려주지 않는 50가지 비밀" 이란 책을 읽다보면 회사  생활에 대해 많은 생각을 하게 된다. 결론은 회사 생활이란게 그렇치! 라는 생각과 더불어..

내용 중 반복적으로 나오는 주요 대상 중 하나가 직원과 인사부의 관계와 매니저와 직원간의 관계에서 발생하는 이야기가 많다. 그 중, 직원과 인사부의 관계에서 저자는 인사부는 직원을 위해 존재하는 것이 아니라 회사를 위해 존재하며 ,  그 활동 목표도 회사에 피해가 안가도록 지원을 관리하는 데 있다고 규정한다. 맞는 이야기 일까?

매니저와 직원간의 관계에 있어서는 나의 생각과 동일한 것 같다. 매니저의 기본 역할은 담당자들이 본인의 업무를 잘 수행할 수 있도록 지원해서 전체의 목표를 달성하도록 만드는 것을 말한다라고 말한다. 여기에 전적으로 동의한다. What을 중심으로 담당자에게 How를 찾아가면서 목표를 달성하도록 하고 여기에 발생하는 위기 관리는 하는 것..

반복해서 읽을 때 마다 많은 생각을 하게 해준다....
아마 일생에 있어 회사 생활을 그만두는 순간까지 힘들때마다 한번씩 읽어 보게 될 것 같다...느끼는 사람에게만 좋은 책!

로버트 L.글래스의 우리가 미처 알지 못한 S/W공학의 사실과 오해(Facts and fallacies of software engineering)에서 ...

구매한지 몇 달이 지난 책인데 이제서야 정독을 하고 있습니다. 개발에 있어 참고할 만한 재미난 통계 정보들이 있어 정리해 봅니다. 이 책은 소프트웨어 개발에 있어 관리, 개발 생명 주기, 품질 그리고 각 과정상에 발생하는 오류에 대해 정리하고 있습니다 .특히, 가장 개발자들이 싫어하는 유지보수에 대해 참고할 의견들이 많은 것 같습니다.

1. 관리에 대해

- Al Davis , "뛰어난 관리가 뛰어난 기술보다 중요하다."

- 소프트웨어 개발에 있어 가장 중요한 요소는 프로그래머의 자질이다"
무척 중요한 사실입니다. 사람중심의 개발에 반대되는 것이 아마 프로세스 중심의 개발이라고 할 수 있습니다. 어떤 것이 중요할까요? 물론 사람중심이 정답일 것입니다. 그러나 만약 사람 중심의 시각에서 해당 개발자가 충분한 자질을 갖지 않는다면 어떻데 될까요? 결국 이러한 문제 상황에 봉착했을 때 할 수 있는 방법은 프로세스를 만들고 이를 규정화하는 것 입니다. 물론 프로세스 기반의 개발의 경우 이를 이해시키고 강제시키는 것이 가장 어려운 일이지만요.. 자질있는 프로그래머... 참 요즘은 찾아 보기 어렵죠..!

- 최상의 프로그래머는 최악의 프로그래머보다 28배 더 뛰어나다.
- 지체된 프로젝트에 사람을 추가 투입하면 프로젝트가 더 지체된다."
역설적으로 우리나라 SI의 경우 이러한 사실에 정반대로 프로젝트를 관리하죠. 납기일에 맞추기 위해 막판 개발자 추가 투입.... ^-^

2. 개발 생명 주기에 대해

- 개발 생명 주기의 비율은?
요구분석 20% , 설계 20% , 코딩 20% , 오류 제거 40%

- 위기의 프로젝트의 가장 흔한 원인 2가지 중 하나는 불안정한 요구사항이다.

3. 유지보수에 대해

전체 소프트웨어 공정 비용 중 60%가 유지보수 비용이고 그중 60%가 기능 강화(enhancement)에 드는 비용이랍니다.  나머지는 17% 오류 수정 , 18%는 다른 플랫폼 지원들을 위해 드는 적응성 유지(adaptive maintenance) 비용 , 그리고 마지막 5%는 리팩토링 비용이라고 합니다.

이러한 유지보수를 위해서는 기존 시스템을 이해하는 게 정말 중요합니다.  실제 기존 시스템을 이해하는 게 유지보수에서 가장 어려운 작업입니다. 다른 사람이 설계하고 개발된 시스템을 코드를 통해 역으로 이해해야 하기 때문입니다. 평균적으로 기존 시스템을 이해하는 데 걸리는 시간은 전체 유지보수 시간중 대략 30% 정도라고 합니다. 아마 이 경우 , 기존 시스템을 잘 이해할 수 있도록 문서나 코드 들이 잘 정리돼어 있어야 겠죠.  이렇치 않을 경우 제 경험한 전체 유지보수 시간이 기하급수적으로 늘고 결국 다시 짜야 합니다 라는 담당자의 보고를 받게 됩니다 ^-^.  참고로 Fjelstedz 와 Hamlen가 정의한 유지보수의 생명주기는 다음과 같습니다.
 
-수정 사항의 정의와 이해(15%) - 시스템 문서 검토(5%)-로직 추적(25%)-수정사항 구현(20%)-테스트와 디버깅(30%)-문서 업데이트(5%)

4. 품질에 대해

소프트웨어 품질의 7개 속성 - 이식성, 신뢰성, 효율,사용편의성, 테스트 용이성, 이해 용이성, 수정 용이성

여기서 효율이란 S/W가 실행 시간과 사용 공간에 있어 얼마나 효율적인지를 의미하는 것이며 이해 용이성과 수정 용의성은 유지보수 담당자가 얼마나 쉽게 이해하고 수정을 할 수 있는지를 말하는 것입니다.  어차피 정답은 없지만 개발자로서 내가 개발하고 있는 소프트웨어가 얼마나 높은 품질을 갖고 있는 가는 의미있는 일 입니다. 물론, 생각해 보면 좌절할 수도 있겠지만요^-^.

오류의 발견 위치
- 오류의 반이 모듈의 15%에서 발견된다.
- 오류의 80%가 단지 모듈의 2% 이내에서 발견된다.
- 대락 80%의 결함이 모듈의 20%에서 나오고 모듈의 절반정도는 오류가 없다.

결국 소프트웨어는 여러 개발자가 모듈을 나눠서 개발하기 때문에 특정 모듈을 맡은 개발자에 의해서 대다수의 오류가 만들어진다고 생각할 수 있습니다. 결국 오류를 완벽하게 제거할 수 없기 때문에 모듈 개발시 난위도를 조절하여 개발 역할을 나누고 , 오류 수정은 심각한 것을 수정하는 전략이 필요하겠죠...

5, 후기
소프트웨어 분야에 있어 관리자가 아니라 개발자로 오래 남는 다는 것은 결국 자신이 그 일에 매우 능숙하게 된다는 것과 동시에 다른 부분의 사람들이 갖지 못하는 권력(?)을 갖는 것이기도 합니다. 이를 악용하는 사례들도 많이 있지만 대다수의 개발자들은 오래 동안 개발자로 남길 원할 것 입니다. 정말 코드로 승부하려는 개발자들 에게 다시 한번 격려를 보냅니다.  요즘은 그런 생각이 드네요 CTO라는 직업으로 뭘 해야 하나? ^-^. 관리자인가 개발자인가..직원인가 임원인가..

씽크프리는 업무 특성상 메일로 의견 교환이 많습니다. 특히, 저의 경우 외국 파트너나 엔지니어와의 의견 교환이 많을 뿐만 아니라 내부에서도 무척 많은 편입니다. 간혹, 메일을 주고 받는 과정에서 오해가 많이 발생해서 난처한 일이 발생한 적이 있었습니다. 특히, CC를 말그대로 참고로 넣었는데 CC로 받는 분중에서 오해가 많이 생기더군요..^-^ 이럴 때마다 항상  나름대로 주의해서 메일을 써야 겠다라는 생각을 했었습니다. 우연히 블루문님의 블러그에서 이와 관련된 좋은 글이 있어 소개합니다.

1. 제목은 상대방 입장에서 쓸 것
- 이메일의 제목은 상대방이 쉽게 알아 볼 수 있는 제목으로 작성할 것
- 보낸 이메일은 자신의 것이 아니라 "상대방의 것"임을 명심할 것
- 연속으로 메일을 보낼 경우 비교 관리하기 쉽도록 제목을 정할 것
- 내부 소통을 위한 이메일과 외부 전달을 위한 이메일의 제목을 혼용하지 말 것

>> 추가 하고 싶은 내용
CC를 추가할 경우에도 해당 받는 사람의 입장을 고려해서 작성하는 것이 좋다. 특히, 조직에서는 다른 부서의 상관이나 특정 이해관계에 있는 분들이 오해를 할 수 있는 단서가 될 수 있다.
 
2. 적절한 호칭을 사용할 것
- 상대방 조직에서 사용하는 정식 호칭을 거명할 것
- 호칭에 맞는 상대 존칭을 사용할 것
- '압존법'을 극단적으로 사용하지 말 것
- 그러나 '압존법'을 분명히, 경우에 맞게 사용할 것
 
3. 이메일 본문 작성의 핵심
- 제목에서 언급한 내용으로 먼저 시작할 것
- 문장은 항상 두괄식으로 작성할 것
- 불필요한 문장으로 이메일의 핵심을 흩뜨리지 말 것
- 달리 해석할 수 있는 함축적인 문장과 단어를 사용하지 말 것
- 상대방을 앞에 두고 이야기한다고 상상하며 이메일을 쓸 것
- 민감한 사안이라면 반드시 '구두로 먼저 이야기'하고 이메일을 쓸 것
 
>> 최대한 핵심을 간단하에 정리해서 보내는 것이 좋다.

4. 다른 기억해야 할 것들
- 보낸 이메일은 반드시 다른 사람에게 공개 된다
- 사적인 내용조차 반드시 공개 된다
- 이메일의 법률적 효력은 약하나 법정에서 참조 자료가 된다
- 한 번 보낸 이메일은 회수할 수 없으니 교정하고 또 교정해도 부족함이 없다
- 첨부 파일이 포함되었는 지 반드시 확인하라
- 이메일은 보조 커뮤니케이션 수단임을 명심하라, 진정한 커뮤니케이션은 면대면 대화다.

                                                                        출처 : http://i-guacu.com/1623

2008년에는 메일도 잘쓰고 오타도 없애는 한해를 만들어 보겠습니다.

모두 즐거운 구정 연휴 잘 보내세요!!

나는 딴따라다
태어났을때도 지금도 앞으로도
그리고 그게 자랑스럽다

가수 아니 프로듀서 , CEO인 박진영씨의 "딴따라브루스"라는 노래에 나오는 가사입니다. 아침부터 눈꼽도 떼기전에 주간업무 정리부터 밀린 일들을 하다 문득 TV 를 트는 순간 저 노래가 나왔습니다.  순간적으로 자신의 일에 대한 그의 열정을 느낄 수 있었습니다.  날 떠나지마! 란 노래가 기억나는 그에 대해 생각해 봤습니다.

얼굴도 그리 잘나지 않고 노래도 최고의 가창력을 갖추지 못한 그가 왜  딴따라가 되었는지? 그리고  한창 잘나가던때 미국으로 건너가 고생을 하며 미국 시장에 진출을 했는지..그리고 왜 지금에도 국내 인재들을 해외에서 계속해서 키우고 있는지?....왜 그가 이럴까요? 

과거 우리나라에선 연예인을 딴따라라고 다소 낮춰 부르는 경향이 있었습니다.지금도 나이든 어르신들은 그런 분위기가 지배적이죠. 우리가 공돌이(공대출신)니 푸돌이(프로그래머)니 하는 것과 같은 맥락인 것 같습니다.

과연 , 다음과 같이 자신있게 외치며 살 수 있을까요?

나는 개발자다
태어났을때도 지금도 앞으로도
그리고 그게 자랑스럽다

2008년 , 제가 개발자를 직업으로 갖은 지 15년째가 됩니다.  그 사이 크고 작은 시스템 개발에  환희와 좌절도 느껴봤고 의사나 변호사처럼 사회적으로 선호되는 직업을 갖고 있는 친구들과 만나면서도 항상 새로운 것을 배우며 만들어 내는 나의 직업 자체에 대해 후회해 본 적은 없는 것 같습니다. 창업과 대박(^^)내지 못한 경력은 있지만 나름대로 그 과정에서 많은 것들을 배웠기도 합니다. 그 중 하나가 국내 현실에서는 창의적이고 글로벌한 일등 벤처가 나오기 힘들다(불가능하다)라는 경험과 이유없이 잘해주는 넘은 절대 없다라는 것입니다.  아마 딴따라 박진영씨가 미국에서 과감히 도전한 것이 이러한 이유가 아닐까 합니다. 개인적으로 2008년 , 개발자 15년차에는 모든 일에서 은퇴를 하고 그 간 일한 성공을 바탕으로 새롭고 자유롭운 일을 해보는 것이 꿈이었습니다. 올해 곰곰히 생각해 보니 꿈은 이뤄지지 않은 것 같습니다. 그래도 포기할 수는 없겠죠....

특히, 박진영의 딴따라론을 보면서 딴따라와 개발자의 공통점을 생각해 보니더욱 그러한 것 같습니다. ^-^


개발자와 딴따라는 한끗차이다.

-개발자와 딴따라는 모두 새로운 변화를 갈망하여 변화를 두려워 하지 않는다.
 변화를 두려워해서는 절대 성공할 수 없다.

-개발자와 딴따라는 모두 세상물정을 잘 모른다.
 자기 일에 자부심을 느끼며 자신 만의 세상이 있다. 그러다 보니 주변에서 나쁜 사람들이 자기를 이용하는 경우에도 잘 모른다. 항상 피해를 보고 나중에 알게 된다. 절대 그냥 잘해주는 경우와 사람은 없다.

-개발자와 딴따라는 항상 꿈을 꾼다.
 항상 새로운 생각을 하며 자신의 꿈을 꾸며 행복해 한다.

- 유능한 개발자와 딴따라는 모두 할 줄 안다.
  노래(코딩)만 잘 하는 것으로 성공하지 못한다. 노래(코딩)도 잘하고 작곡(설계)도 하며 앨범(사업기획)도 만들 줄 한다.

- 개발자와 딴따라 모두 대박나려면 운이 필요하다.
 아무리 해도 운이 터야 성공한다. 대박은 운짱이 돼야 한다.

그냥 10년 뒤에도 개발자로 자부심을 느끼고 싶다는 간절한 소망에서 주절주절 해 봤습니다.