최근 이런 질문을 받았다.  "앞으로 SaaS 분야의 전망은 어떻게 생각하는가?"
이렇게 대답하였다. "사용자들이 얻게 되는 이득과 개발업체들이 얻게되는 이득을 고려할 때 합리적 선택을 한다면 SaaS시장은 지속적으로 성장할 것이다."

"합리적 선택"은 경제학 분야에서 많이 사용하는 이론이다. 팀 하포트가 집필한 경제학 콘서트란 책은 "합리적 선택이론"에 근거하여 십대들의 구강성교가 늘어나는 이유를 설명하는 것을 비롯해 다양한 사회 현상을 설명한다. 합리적 선택은 다양한 상황하에서 발생한다. 가령, 서울에서 부산까지 출장을 가야 한다고 하자. 이 때 이용할 수 있는 교통편은 자가용과 고속버스만 있다고 생각해 보자. 만일 바로 부산에서 일을 마치고 돌아와야 한다면 정상적이라면 고속버스를 선택할 것이다. 그러나 중간에 대전에서 잠시 들려 고객을 만나고 부산에서 돌아오는 길에 대구에서 잠시 고객을 만나야 한다면 자가용을 선택할 것이다. 바로 이러한 선택이 합리적 선택이다.

합리적 선택에 근거해 국내 소프트웨어 시장을 생각해 보자. 왜 국내 소프트웨어 분야가 점점 활성화되지 못하는 것일까?

개발자 입장에서 생각해 보자. 대학에서 전공을 선택하는 학생 입장에서 소프트웨어 개발자는 노력에 비해 보수가 적은  3D분야로 알려져 있다. 따라서 전공선택에 있어서도 소프트웨어 개발에 특별한 사명감(?)을 갖고 있는 학생을 제외하고 우수한 학생들은 의대나 생명공학같은 학과를 선택한다. 이런 과정에서 전산을 선택한 학생들은 졸업 후 다시 한번 취업을 위해 합리적으로 선택을 해야 한다. 당연히 이 때 선택은 가급적 규모가 크고 안정적이며 대우가 좋은 대기업을 선택한다.  대기업에 선택받지 못한 예비 개발자는 벤처나 중소 기업을 선택할 수 밖에 없다. 물론 소프트웨어 분야를 포기하고 다른 업종을 선택할 수도 있다.

그런데 문제는 솔루션 개발 분야에서 많은 부분을 차지하고 있는 벤처나 중소기업들의 경우 먹이사슬의 가장 하단부에서 피를 빨리고 있다는 것이다. 대부분의 프로젝트들이 대형SI들이 수주를 하고 이들 업체에게 하청관계로 일을 할 수 밖에 없는 업체들은 울며겨자먹기 식으로 과다한 업무를 적은 대가를 받고 개발을 한다. 이런 상황에서 중소기업이 할 수 있는 유일한 방법은 개발자에게 적은 보수를 주고 과다한 개발 업무를 수행하는 방법밖에는 없다. 이런 상황에서 개발자가 선택할 수 있는 합리적인 선택은 일단 경력과 실무를 쌓고 대형SI나 다른 안정적인 기업으로 이직을 하는 것이다. 그나마 이렇게라도 이직을 하는 개발자는 능력과 경쟁력을 갖춘 개발자라 할 수 있다. 이러한 경쟁력도 없는 개발자는 더욱 열악해진 상황에서 개발을 해야 한다. 이 과정에서 그는 자신의 신세를 친구나 후배에게 직.간접적으로 이야기를 한다. 따라서 예비 개발자는 본인의 개발자로서 미래에 대해  불확실성을 느끼며 다시 악순환이 반복된다.

이제 다시 솔루션 분야의 개발자가 아니라 CEO의 입장에서 생각해 보자. 멋진 기술력을 바탕으로 솔루션을 개발하고 이 제품을 시장에 내놓는다. 초기 영업과 마케팅을 위해 많은 노력을 기울인다. 이러한 영업과 마케팅은 실제적으로 대부분의 프로젝트를 수주한 대기업에게 집중될 수 밖에 없다. 또한 이렇게해서 프로젝트가 성사가 되더라도 저가로 수주한 프로젝트로는 수익을 맞출 수가 없다. 따라서 회사를 운영하기 위해 할 수 있는 방법은 개발자에게 적은 임금을 주고 개발을 하거나 다시 재하청을 주는 수 밖에 없다.  이미 창업과 회사 운영을 위해 많은 부채를 안고 있는 CEO들은 무한 책임을 지기때문에 다른 선택도 할 수 없다. 유일하게 CEO들이 할 수 있는 선택은 회사를 지키면서 끝까지 함께하는 것이다.

고객 입장에서의 합리적 선택을 생각해 보자. 프로젝트를 발주하는 고객 입장에서 현재 구조라면 당연히 대형SI회사에게 발주하는 것이 합리적인 선택이다. 왜냐하면 해당 프로젝트에 대한 책임을 질 수 있기 때문이다. 작은 회사에 발주를 했다 해당 회사에 문제가 생겨 어려움에 빠지는 것을 결코 바라지 않기 때문이다.

지금까지 상황은 실제 우리 소프트웨어 업계의 모습이다. 과연 이런 상황에서 어떤 합리적인 선택을 해야 할까? 

Why software sucks... and what you can do about it

이 책에서 주장하는 것을 간략히 정리하면 ,
S/W에 있어 사용성은 무척 중요하다. 그런데 괴짜들인 개발자는 사용자를 위한 사용성에 크게 신경쓰지 않는다. 자기가 만족하면 OK다. 사용성 개선을 위해 사용자들은 개발자와 회사에 무엇이 불편한지 이야기를 해야 한다고 시종일관 강조하고 있다. 심지어 자신이 만든 suckbusters.com에 의견을 모아 집단적으로 의견을 전달하자고 말하고 있다. 

책을 한마디로 평가하면 제목만큼 올해 읽은 책중 가장 개떡(?,책의 제목을 인용한 것이니 오해마세요^-^)같은 IT 관련 서적이 아닌가 싶다. 일반 사용자들이 읽기에는 다소 전문적인 반면, 개발자들과 관련자들이 읽기에는 너무 평이한 내용이 아닌가 싶다. 아니 기대했던 내용을 전달받지 못했다. 이러한 생각이 들기까지 책을 정독하고 나중에 다시 한번 읽으면서 내가 잘못 이해하는 부분이 있나? 라고 반문을 했었다.

처음 책을 접하고 기대했던 내용은 말 그대로 S/W와 서비스들중 개떡같이 만든 것들을 좀 열심히 비판(내지 비난)하고 많은 생각을 하게 만드는 것을 기대했는데 원하는 것은 접할 수 없었던 것 같다. 물론 책의 초반부에 언급된 개떡같은 소프트웨어들의 사용성에 대한 문제에 대해서는 동의한다. 당연하고 일반적인 이야기이기 때문이다. 그러나 중반 이후 저자는 소프트웨어 개발자가 괴짜고 그러하기 때문에 이러하다라는 것을 시종일관 말하고 있다.  두서없는 전개에 주제에 집중할 수 없는 복잡한 내용들이 무척 혼란스럽다.

가십과 관심을 끌기위한 책인가 ? 아니면 숨어있는 어떤 통찰력이 뛰어난 멋진 서술인가? 라는 판단을 좀 더 하기 위해 블로그를 뒤져 보았다. 여러 평가들이 보인다.

긍정적인 평가
http://inuit.co.kr/1457
http://www.buggymind.com/127
http://dobiho.com/?p=945
http://ggaman.com/tt/900

부정적인 평가
http://www.cozydev.com/51, 행복한 개발을 위한 블러그
http://wisefree.tistory.com , ^-^

아마 나도 부정적인 평가를 내린 사람중의 하나인 것 같다.

과거 죠엘의 블러그를 읽으면서 그의 해박한 경험을 전달받으며 느꼈던 감정을 기대했었는데 좀 아쉽다.  혹 , 개발자로서 사용성에 대한 경험이 필요한 분들은 죠엘의 블러그를 참고하길 바란다. 그리고 사용성에 대한 정보가 필요한 개발자나 기획자는 Jakob Nielsen의 블러그가 많은 도움이 될 것이다. 그리고 번역서로는 스티브 크룩의 『Don't Make Me Think 2/e』의 한글판인 상식이 통하는 웹사이트가 성공한다(2판) 상세보기 가 많은 도움이 될 것이다. 출판된 책보다는 온라인 블러그가 보다 현실적인 정보를 제공하는 것 같다. 아마도 이 책이 나오기까지의 시간동안 웹이 너무도 빨리 변하는 듯하다.

그리고 나는 소프트웨어 개발자를 괴짜라 생각하지 않는다. 그저 평범한 사람이다. 물론 개중에는 본인이 특별하다고 생각하는 개발자가 있을 수 있지만 소수라고 생각한다. 단지 새로운 것을 좋아하고 이를 받아들이는 데 일반인보다 적극적인 사람들이 개발자가 아닌가 생각한다.  힘들어도 평생 새로운 기술을 접해야만 먹고 살 수 있는게 바로 개발자란 직업이다. 오히려 이 책의 저자가 지적한 사용성의 문제는 개발자들의 문제가 아니라 소프트웨어를 포함한 모든 재화(commoditization)에 해당하는 것 같다. 항상 최초의 재화는 부족하고 모자라다. 문제는 얼마나 빨리 이것을 채우는 것인가가 경쟁력이고 이러한 회사들 만이 살아남는다.

몇 일전 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년 후에도 소프트웨어 개발 분야에서 일을 하고 있겠지만 그 때도 행복하고 싶습니다.

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

성탄전 연휴 사이에 읽은 "초난감 기업의 조건"이란 책에서 소개한 많은  IT 기업의 실패한 여러 사례를 들을 보면서 , 소프트웨어 라는 분야의 사업에 대해 다시 한번 많은 생각을 하게 되었습니다. 소프트웨어 개발사가 망하는 주요한 원인 제공처가 크게는 소프트웨어 기술을 이해못하는  난감한 CEO , 아둔한 개발진 , 띨방한 마케팅 부서 등을 볼 수 있는 것 같습니다.  최소한 난감한  CEO와 띨빵한 마케팅 부서를 제외하고 개발과 관련된 사안들에 대해 다음과 같은 실수는 피해야 하지 않을까 싶습니다.

- 제품을 처음부터 다시 개발해야 한다는 개발팀의 의견은?
심정은 이해하지만 절대 다시 개발해서는 안됩니다. 이미 경쟁자는 신규 개발 기간의 몇배는 빨리 시장에서 자리를 잡게 됩니다. 또한 안정화되기까지 엄청 많은 시간을 요하게 됩니다. 개인적으로도 유사한 상황에 빠진 경험이 몇 번 있었는데 구조적으로 문제가 있고 , 처음 시도하고 적용한 기술 등을 인해 많은 문제가 있어 다시 처음부터 시작해야 하는 상황이라면 어쩔수가 없습니다. 그러나  이미 시장에 출시되어 경쟁이 되는 제품이라면 현재의 상황을 점진적으로 개선해 나가는 것이 당연히 유리합니다. 유명한 사례지만 넷스케이프사가 전제 제품을 다시 개발하는 데 4년이 걸렸고 그 사이는 빌게이츠는 익스플로러로 인터넷 분야의 판세를 뒤집었죠.

- 개발 목표가 모듈화 라는 개발팀의 의견은?
모듈화의 필요성과 기존 모듈의 문제점, 투입 비용 및 기간 등 여러 요소를 비교하여 그 활용성을 세밀하게 살퍄보고 결정해야 합니다.

- 개발 환경을 변경하겠다는 개발팀의 의견은?
런타임 업그레이드 등을 통해 개발 환경이 손쉽게 변경된다면 큰 문제가 없지만 개발 언어를 다른 언어로 바꾼다거나 개발 환경을 바꾸면서 대대적인 변경이 생긴다면 투입 비용 대 효과에 대해 신중하게 판단하여 결정해야 합니다. 큰 효과가 없다면 변경하지 않는 게 유리합니다.

- 제품을 개발 일정이 부정확한 경우는?
일정 관리는 개발에 있어 가장 중요합니다. 주간 단위의 일정이 지켜지지 않으면 일단위, 일단위가 지켜지지 않으면 시간단위로 라도  일정을 수립하고 이를 지켜내는 프로세스가 있어야만 성공합니다.

- 의도적으로 개발을 거부하거나 태업을 하는 우수한 개발자는?
가슴 아프지만 집으로 돌려보내야 합니다. 결코 소프트웨어는 혼자 개발하는 것이 아닙니다.  여러가지 이유로 자신의 입장만을 고려하는 개발자는 반드시 전체 개발 조직에게 유익하게 작용하지 않습니다.

- 제품 관리(기획)팀의 80:20 법칙을 주장할 때는?
경력이 많은 기획자가 이렇게 말하면 내공을 의심하고 , 신입 기획자가 말하면 팔레토 법칙에 따라 80% 사용자가 20% 기능만을 사용한다고 생각하고 개발을 하면 반드시 망한다는 이야기를 해줘야 합니다.

마지막으로 제 경험상 우수한 QA 팀이 반드시 갖춰져야 고품질의 제품을 안정적으로 출시할 수 있습니다.  실제 위와 같이 하다보면 개발자가 오해를 할 수 있습니다. 그러나 결코, 그렇치 않습니다. 함께 개발로서의 제품이 아니라 , 비지니스로서의 제품으로 이해하는 과정을 통해 모두 이러한 현실을 이해하게 만드는 것이 반드시 병행돼야 합니다.