모바일 시대, 제품 디자인의 기본 원칙이 되는 UX 디자인

단순히 기술만을 승부하는 시대는 가고 디자인과 사용자경험까지 곁들여야 성공할 수 있는 시대가 도래했다. 이 책은 모바일을 위시해 스마트한 요소들이 득세하는 세상에서 디지털 제품과 애플리케이션을 만드는 데 필요한 UX 디자인에 대해 다룬다. 시대의 흐름을 반영한 예제와 설명으로 실질적인 아이디어를 구상해 볼 수 있도록 원리에서부터 실무적 경험까지 담고 있다. 특히 사용자에 따라 달라질 수 있는 UX 디자인의 변하지 않는 원칙을 다뤄 사람을 위한 제품을 만들 수 있는 방법을 체화할 수 있도록 돕는다.

한군과 빛녀의 상황이 공감이 되시나요?
새학기도 시작되겠다, 학구열이 부쩍 올라있는 대학생 여러분!
한빛미디어 MSE 시리즈와 함께 기초 탄탄히 다지시길 바랄게요 :)
이번학기 All A+로 미래 준비도 하시고, 성적이 좋으니 부모님 입가에도 미소가~ 자동 효도까지! ^_^
여러분은 대한민국 미래를 책임지실 인재라는거 잊지마세요!

<빛녀가 공부했던 바로 그 책>

> 미적분학 : Calculus
미적분학을 뻔하게 아닌 'Fun'하게 배울 수 있게 했다.
구체적인 사례로 개념을 명확하게 배울 수 있고,
다채로운 손그림으로 개념을 더욱 쉽고, 재미있게 이해할 수 있으며,
다양한 공학 및 실생활 예제로 문제 해결력과 응용력을 키울 수 있다.
 
> 기초 미분적분학 : Pre Calculus
고등학교에서 배운 수학 지식을 바탕으로 쉽게 계산 능력을 향상시킬 수 있도록 구성했다.
부족한 부분을 스스로 보완할 수 있도록 자세한 예제 풀이와 단계별로 연습문제를 제시하여
미분적분 계산 능력을 향상시키고자 하는 학생들에게 도움이 될 것이다.

> 창의적 공학설계 : Training How To Think Creatively
창의적 발상 도구를 활용한 창의적 공학 교수법을 도입하는 데 관심이 있는 교수 및
자신의 창의적 문제 해결 능력을 계발하는 데 관심이 많은 공학자에게도 유용하다.

> 기초수학 : Basic Mathematics
미분적분학 또는 대학수학을 공부하는 데 있어 어려움을 겪는 '수학 기초학력'이 부족한 학생을 위한 책으로,
중고등학교에서 학습한 내용을 토대로 대학에서 공부할 미분적분학의 내용을 총망라하였다.

> 수식이 보이는 공학수학 : Engineering Mathematics
수식의 의미와 전개 과정에 대한 친절한 설명과
 예제에 대한 상세한 풀이를 담아 '마침내' 수식이 보일 수 있도록 도와준다.

> MATLAB으로 배우는 공학수학 : Engineering Mathematics
MATLAB으로 이론이 전개되는 과정을  직접 보고 이해할 수 있도록 도와주며,
자연과학, 공학에 연관된 예제를 제시하여 공학도에게 필요한 응용력을 기를 수 있도록 한다.
 

국내 소셜마케팅 전문가 5인이 공개한 SNS 운영&관리 기법이 가득담긴  <100만 방문자와 소통하는 소셜마케팅 : 한국형 SNS의 모든 것>이 출간되었습니다. 저도 업무가 업무인지라 많이 기다렸던 책이기도 한데요. 사실 SNS가 주목받기 시작하면서 관련 도서들이 우후숙순 쏟아지기도 했죠. 아마 그래서 더 설명해 주실 이야기가 많지 않을까 하는 생각이 들어 100만 방문자와 소통하는 소셜마케팅의 기획자를 만나 책에 대한 이야기를 들어봤습니다.

저 한테도 몹시 필요했던 책이라 기다렸습니다! 그런데 저자가 5분이나 되시더라고요. 단일 저자가 아닌 공동 저자로 기획하신 특별한 이유가 있으신가요?

소셜미디어 플랫폼이 발전하면서 너도나도 소셜마케팅에 뛰어들고 있지만, 아직까지는 국내 소셜마케팅의 역사가 길지 않기 때문에 참고할 만한 사례나 시스템 등이 많지 않았던 것이 사실입니다. 책을 기획할 때도 단순히 소셜미디어 사용법만 따라 하기식으로 알려주는 책이 아니라 소셜마케팅 전반에 대한 기획, 운영, 분석 등의 이야기를 모두 다뤄주고 싶었습니다. 그런데 소셜마케팅은 워낙 내용이 방대하고 전문적인 분야이기 때문에 한 저자분께서 두루두루 작성하시는 것보다는 소셜마케팅 각 분야의 전문가들이 깊이 있게 관련 내용을 다뤄주는 것이 필요했습니다. 책의 구성을 보면 아시겠지만, 소셜마케팅의 기획과 구축, 블로그, 트위터, 페이스북으로 대변되는 실제 플랫폼 운영 방법, 성과 분석과 위기관리 등으로 내용을 세분화해 각 분야의 전문가들을 저자로 모시게 된 것이죠.

소셜마케팅 위기관리 전문가, 파워블로거, 국내 대기업 소셜마케팅 담당자 등 소셜마케팅계의 어벤져스와 같은 느낌입니다. 어떻게 이렇게 모여서 책을 내시게 된 건지 궁금합니다.

<100만 방문자와 소통하는> 시리즈가 파워블로그 만들기부터 페이스북 페이지 만들기까지 블로그와 페이스북 전문가 그룹을 저자로 섭외해 큰 성공을 거뒀잖아요. 이번 <100만 방문자와 소통하는 소셜마케팅> 역시 좋은 내용을 독자에게 전해줄 수 있는 저자 섭외가 가장 큰 관건이라고 생각했습니다. 조건이 있었죠, ‘현재 실무에서 소셜마케팅을 진행하는 담당자일 것’, ‘남다른 소셜마케팅 관련 노하우를 갖고 있을 것’. 저자 섭외 시에는 이 부분에 가장 중점을 두고 생각했습니다. 고객과 만나는 접점에서 실제로 소셜마케팅을 운영해본 실무자만이 진정한 소셜마케팅에 대한 노하우를 전해줄 수 있으리라고 본 거죠. <100만 방문자와 소통하는 파워블로그 만들기> 때도 도움을 주셨던 TNM(파워블로거들과 파트너십을 맺고 운영되고 있는 블로그 네트워크)쪽에서 이번에도 많이 도와주셨습니다. 섭외 조건에 딱 맞는 저자들이 이미 파워블로거로도 활동 중이었기 때문에 저자 섭외가 좀더 수월했던 것 같아요. 실제 다섯 분의 저자분들은 모두 현업에서 소셜마케팅을 성공적으로 운영해본 경험을 갖고 계신 분들이고, 업계에서는 이미 실력자로 정평이 나 있는 분들입니다. 서로 개인적인 친분은 없었다고 해도 이미 소셜마케팅계의 강자(?)로 서로를 접하셨던 분들이라 의견을 모으고 책의 방향성을 정하는 일이 크게 어렵지 않았답니다. 막상 ‘소셜마케팅계의 어벤져스’라는 말을 들으니 무척 뿌듯하네요! 저자분들께도 알려드려야겠어요. ^^

 공동 집필이다 보면 일정이나 의견 등에서 조율해야 할 부분이 많이 생길 것 같은데요. 책을 진행하면서 가장 힘들었던 부분은 무엇인지, 어떻게 해결하셨나요?

사실 공저이다 보니 저자마다 집필 스타일, 마감 속도 등에도 차이가 컸습니다. 제일 먼저 마감하신 저자분과 가장 나중에 마감하신 저자분의 일정 차이가 몇 개월에 이를 정도였어요. 마감도 편집자의 능력이라는데... ㅜㅜ 받은 원고를 살펴보고 보강 요청을 드리고, 다시 받고 하는 과정은 크게 문제가 없었는데, 정작 원고가 없으면 이 과정 자체가 진행이 안 되잖아요. 원고 마감이 사실은 가장 큰 문제였죠. 저자분들 모두 소셜미디어를 적극 사용하고 계시기 때문에 보통은 페이스북 메신저의 다자간 대화를 이용해서 상의가 필요한 내용은 실시간으로 소통했고요, 마감 관련해서는 이미 누구누구 저자님은 마감이 완료되었다, 원고는 언제 주실 수 있느냐 등등을 여쭤보곤 했어요. 대화 내용도 다양했는데, 동점심에 호소(회사에서 혼난 척), 애원(눈물 이모티콘 적극 활용), 미안하게 만들기(원고만 기다리고 있다고 불쌍하게 연기ㅎㅎ), 금요일 저녁에 전화 드리기(주말에 원고 쓰시라고), 주말에 문자 보내기(주말에 원고 쓰고 계시는지 확인용 ^^;;) 등등을 활용했어요. 지나고 보니 책에 얽힌 재미난 추억이 되었네요.
저자분들 간의 집필 스타일 차이, 원구 구성 형태 등은 샘플 원고 작성 후 공유 과정을 거치면서 어느 정도 극복했다고 생각합니다. 그런데 개별 파트별 특성과 다루는 내용이 차이가 나다 보니 한 저자분이 집필하신 것과 같은 느낌을 아닐 것 같아 조금 아쉽긴 해요.

책의 내용에 대한 소개 부탁드립니다.

이 책은 단순한 소셜미디어 간의 통합 활용법에만 초점을 둔 것이 아닙니다. 실제 기업에서 소셜마케팅을 진행할 담당자들이 처음 소셜마케팅을 기획하고 플랫폼을 구축하거나 운영 및 관리할 때 필요한 전반적인 지식을 모두 담고 있어요. 대표적인 소셜미디어인 블로그, 트위터, 페이스북을 중심으로 각각의 플랫폼은 어떻게 연계할 것인지, 실질적인 소셜미디어 운영 및 관리에 필요한 노하우는 무엇인지 알려줍니다. 또 기업 실무자들이 가장 궁금해하는 소셜마케팅 이후 성과에 대한 분석 방법이나 위기 시 소셜미디어에서 제대로 대응하는 방법까지 모두 다뤄주고 있어요. 특히 대표적인 국내외 기업의 소셜마케팅 사례를 선별해 어떻게 하면 소셜마케팅에 성공할 수 있는지 구체적인 전략과 함께 조목조목 소개한 부분은 기업 실무 담당자들의 답답함을 풀어줄 수 있을 것으로 생각됩니다. 한마디로 소셜마케팅의 전반을 다뤄준 교과서, 바이블과 같은 책이라고 할 수 있겠죠.

이미 시중에 소셜 마케팅 관련 도서가 꽤나 나와 있는 것으로 알고 있습니다. 이 도서만의 차별점은 무엇인지, 어떤 독자가 읽으면 좋은 책일까요?

이 책이 제일 좋아요~ ㅎㅎㅎ (농담 아님!) 실무에서 소셜마케팅을 직접 진행하고 있는 분들이 얼마나 공감할 수 있을지, 또 고민하던 부분을 얼마나 합리적으로 해결해줄 수 있을지에 대한 고민을 풀어내기 위해 노력을 많이 한 책입니다. 그동안 소셜마케팅 실무자들이 국내 사례를 찾지 못해 외국 서적에 의존하고, 외국의 사례 찾기에 급급했다면, 또 식상한 소셜마케팅 이론에만 치중된 책에 지쳤다면, 이 책이 도움이 될 수 있을 거예요. 현업에서 성공적으로 소셜마케팅을 수행해온 저자들의 경험과 노하우가 듬뿍 들어 있는 책이기 때문입니다. 풍부한 국내외 사례를 바탕으로 실무자들이 자신의 업무에 바로 적용 가능한 해법을 제시한다는 것도 이 책만의 장점입니다. 이제 막 소셜마케팅을 시작하는 실무 담당자들, 이미 소셜마케팅을 운영하고 있지만 제대로된 소셜마케팅이 무엇인지 궁금한 분들, 자신이 다뤄보지 못한 소셜미디어 플랫폼의 특성과 운영 방법을 배우고 싶은 분들, 개인 사업자나 소상공인처럼 큰 마케팅 도구는 없지만 소셜마케팅 운영을 고민하고 계신 분들 등등에게 추천합니다! 

2012년의 막바지. 개발자로 올해도 열심히 일한 당신 고생 많으셨습니다!
2013년 1월초, 유지보수에 대부분의 시간과 비용을 쓰는, 거의 모든 개발자를 위한 '읽기 좋은 자바스크립트 코딩 기법 : 유지보수가 쉬운 코드로 팀의 생산성을 높이자'이 출간됩니다.
왠지 시작이 좋은 2013년이 될 것만 같지 않으세요? :)

한눈에 정체를 파악하기 힘든 저것들은 무엇에 쓰는 물건인고? 하는 호기심이 생긴다면, 움직이는 사물의 비밀과 함께 만들기에 도전해볼 모든 준비를 갖추셨습니다. 위의 사진들은 움직이는 사물의 비밀에 담고 있는 프로젝트에서 가지고 온 내용이랍니다. 맨 위의 사진을 시작으로 시계방향 루브 골드버그식 아침식사 기계, 고개를 끄덕이는 양, 쥐덫 동력 자동차, 풍력 랜턴,  직선형 모터를 이용한 신발 승강기입니다.

새롭고 신선한 아이디어라고 생각하고 계신가요? 독자님이 마음만 먹는다면 더 신선한고 재미있는 아이디어로 만드실 수 있습니다.

나는 기계에 대한 기본 지식도 없는데 그냥 호기심만으로 가능한가요? 라고 물으시면 네 그렇습니다라고 대답하고 싶습니다. 움직이는 사물의 비밀은 기술 지식이 크게 필요하지 않은 설명, 예제, 그리고 DIY 프로젝트를 통해 움직이는 메커니즘을 제대로 만드는 방법을 담고 있습니다.

매커니즘과 기계 소개, 재료 선택법과 구입처, 부품 고정 및 결합, 힘/마찰력/토크를 비롯한 만들기 전에 알아야할 기본적인 지식을 담고 있으니 초보자라 할지라도 두려움 없이 시작할 수 있습니다.

주변의 사물에 새로운 역할을 부여하면서 세상을 바라보는 시각을 좀 더 넓혀 보시는 건 어떨까요? 기계란 처음에는 약간 무섭게 보이지만, 복잡한 프로젝트를 부분으로 나누어 보면 생각만큼 어렵지 않다는 사실을 결국 깨달으실 수 있을 꺼에요. 누구든지 약간만 연습하면 물체를 움직일 수 있습니다.

심심한 날~ 친구가 필요한 날~ 나는나는 친구를 만들죠~
추억의 만들기 시간처럼, 재미있는 만들기에 도전해보세요 :)

창의적인 사람은 타인의 부러움을 받기 마련이죠. 공학을 전공하는 공학자에게도 예외일 수는 없겠죠.
창의력 그 놈, 돈주고 살 수있는거면 돈이라도 모아보겠는데 그럴 수도 없고.

공학자에게 필요한 창의성의 핵심은 앞서 새로운 문제를 인식하는 능력, 근본 원인을 분석하여 문제를 정확히 정의하는 능력, 정의한 문제를 해결할 수 있는 참신한 아이디어를 도출하는 능력으로 정의해 볼 수 있을 텐데요.

창의적 공학 설계는 창의성과 공학 설계에 대한 설명, 다양한 창의성 발상 도구 소개, 실습의 전 프로세스를 담아 창의적 문제 해결 능력을 키울 수 있도록 구성되어 있습니다. 이러한 일련의 과정을 통해 아이디어를 실천에 옮겨 실용적인 결과를 도출할 수 있도록 하는 것이 창의적 공학설계의 목표가 되는 것이죠.

다양하고도 현명한, 창의적인 접근 방법을 통해서 21세기 핵심인재, 창의적 인재가 되어보는 것은 어떨까요?
재미있게 따라하다 보면 아이디어 퐝퐝!
창의적 공학설계이 그 초석을 다지는데 도움이 될 것입니다.

"한빛미디어가 경력 12년의 IT 개발자를 저자로 모셔 책을 출간했습니다."
"에이~ 한빛미디어면 IT 전문 출판사니까 전혀 새로울게 없는거 아닌가요?"
"그런가요? 근데 그 책이 그림 그리기 책인걸요."


그림 그리기 책이라고 하니까 오잉? 하셨죠? 공대 출신 개발자로 정신없이 앞만 보고 달려오던 마흔 살의 그에게 첫사랑처럼 찾아온 그림이 행복의 결과물이 되어주기까지, 무작정 노트와 펜을 들어 그리기 시작한 18개월간의 여정과 결과물, 그리고 그의 이야기가 담겨있는 철들고 그림그리기가 출간되었습니다.

저자는 그리기라는 활동을 통해서 삶과 나를 둘러싼 세상을 다르게 바라보는 힘을 기를 수 있었다고 합니다. 다르게 바라보는 시선은 새로운 의미를 찾을 수 있게 되었고 그것이 따뜻한 시선과 마음, 그리고 행복으로까지 이어진다고 하십니다.

그런 그는 원래 그리기에 재능이 있는 사람이 아니었을까? 라는 의문이 들었는데 그가 말하길 그리기는 재능이 아니라 습관과 꾸준함으로 완성될 수 있는 예술활동이라고 하시네요. 행복을 추구하는 그리기를 실천하는 그가 그 동안의 결과물을 모아 자리를 마련한 전시회에 다녀왔습니다.

명동 쇼핑거리에 위치한 바오로딸 명동서원 3층에 자리한 아담하면서 포근한 느낌의 공간이더라고요. 입구에 한빛미디어 사장님께서 보내신 화분도 보이더군요.


들어서니 싸인을 하고 계신 정진호 저자님. 사진으로 뵈었을때는 꽤나 덩치가 크고 그러신줄 알았는데 직접뵈니 자그마한 체구시더라고요. 새로운 일에서 행복을 발견하신 분이라 그런건지, 시즌이 시즌이라 그런건지 약간은 산타클로스의 인지한 이미지를 닮으신것도 같고. ^-^ 옆에 앉아있는 어린이는 저자님의 아드님인데요, 그림 선생님이자 함께 그림 활동을 즐기는 동반자이기도 하다네요. 공통의 취미를 함께하는 부자라 그런지 유대감이 남달라 보였어요.

관심분야의 세계 소식을 모아 볼 수 있는 인기 뉴스 리더 앱 Flipboard를 알고 계신가요?
저도 이번에 알게된 앱인데 다운 받고 보니 100만번 이상의 다운로드는 물론 평점까지 별 4개 반의 인기앱이더라고요. 사용자들의 평가를 봐도 양질의 정보와 편리성을 칭찬하는 분들이많더라고요.

이렇게 많은 분들께 인증받은 Flipboard(한국어판)에! Make : Korea 블로그가 '과학과 기술' 섹션에 등록되었습니다!

저기 자랑스럽게 자리한 모습 보이시죠? ^-^ 블로그를 구독하시게 됐을 경우 보이는 화면입니다. 일목요연하게 보기 깔끔하죠?


Make: Korea가 Tech DIY 매거진인 만큼 재미있으면서도 따라해볼 만한 흥미로운 프로젝트들이 가득담겨 있답니다.  Flipboard 유저시라면 Make: Korea 방문을, 아직 유저가 아니시라면 다운로드 받으셔서 다양한 정보와 함께 Make: Korea도 함께 만나보세요 :)

[Flipboard 앱 다운로드 받기]
아이튠즈 다운받기
구글 플레이


참, 얼마전에 학창시절 배웠던 기본적인 것부터 알쏭달쏭한 기계의 작용원리까지 차근차근 재미있게 담은,
<움직이는 사물의 비밀>이 출간되었답니다. 호기심 충만한 분이라면, 아이와 함께 창의력의 세계로 빠져보고 싶으신 분들이라면 주목해보세요!

[프로그래머로 사는 법 기획연재 10 : 우연히 시작한 개발자의 꿈, 아직도 진행형]

<프로그래머로 사는 법>

* 본 내용은 도서의 내용을 일부 발췌하여 작성한 것입니다. 도서에는 더 많은 이야기를 담고 있답니다 :)

사실 대학을 가면서 자신의 적성을 따져 전공을 택하는 학생들이 얼마나 될까 생각해보면 오히려 한국적인 상황을 제대로 고려한 제도라고 볼 수도 있었다. 아이러니컬하게도 그 교육과정 중에 전공인데도 탈락자가 생기기도 했다. 사실 교육과정에서 내 준태스크는 결과로는 프로그래밍이지만 그것을 완수하기 위한 요구분석 능력, 순발력, 지구력과 신중함까지 다 시험하고 있었다. 실제 개발자가 가져야 하는 가장 기본적인 것들을 10주 동안 시험해보면서 개발자로서의 적성인지 아닌지를 시험해보는 과정이었다.

에스티엠이 창립되면서 대형 IBM 메인프레임 두 대가 도입되었고, LG 그룹 내 각 전산실에서 각자 운영하던 애플리케이션들을 IBM으로 옮기는 마이그레이션 프로젝트를 하게 되었다. 그렇게 크고 작은 프로젝트를 수행하며 한동안은 프로그래머가 천직이라는 생각마저 들 정도로 푹 빠져 살았다. 프로그램에 한해서는 스스로 자부심도 느꼈고 프로그램으로 이 세상에 해결 못 할 문제는 없는 것 같았다. 퇴근을 해서 집에 가는 길에도 머릿속은 온통 코딩 중이었고, 아침에 일어나면 출근이 즐거웠다. 내가 만든 프로그램으로 리포트들이 쏟아져 나오고, 현업에서 가져다 일하는 걸 보면서 존재가치를 느끼며 살았던 시간이었다.

마이그레이션 프로젝트가 끝나갈 무렵 본사로 부서를 옮겼다. 새로 조직된 개발팀이었는데 경력사원으로 오신 여자 선배를 만나게 되었다. 처음 맞은 프로젝트는 에스티엠 내의 네트워크 장비를 관리하는 시스템을 개발하는 일이었다. 그 선배가 주로 분석, 설계를 맡았는데 처음으로 DFD 라는 다이어그램을 보게 되었다. 플로우차트와
는 좀 다른 방식의 다이어그램이었는데 관리해야 하는 데이터에 대해 좀 더 분명하게 보여주고 있었다. 일 년 남짓 예정된 시스템도 완성되어 현업에서 쓰기 시작할 즈음에 속해있던 부서가 CASE팀으로 합병되었다. 사실 CASE가 뭔지 금시초문이었고, 내겐 위기이자 기회가 찾아온 것이었다.

그 팀에 먼저 있던 직원들에게 책을 소개받아 매일 밤 원서들 틈에서 뜬 눈으로 밤을 새기 시작했다. 대학을 졸업하고 몇 년이 지나면서 IT 분야에 많은 변화가 있기도 했지만, 사실 나는 IT 분야의 프로그래머라는 데에 안주하고 살았던 것을 깨닫게 되었다. 살아남으려면 공부를 많이 해야겠다는 생각에 두려움과 설렘이 같이 찾아왔다.

원서는 한 번 슬쩍 읽고 나면 금세 잊혀졌다. 밑줄을 그어놔도 소용이 없었다. 결국, 중요한 부분은 직접 번역해서 요약본을 만들었다. 그렇게 6개월이 지나고 나니 팀 회의 중에 모르는 단어는 없어 보였다. 사실 그 당시 가장 매력적이었던 것은 코딩을 하기 전에 먼저 그림으로 시스템을 설계할 수 있다는 것이었다. 그 전 프로젝트에서 종이에 그리던 DFD를 컴퓨터로 그리고 수정도 쉽게 할 수 있었고, 무엇보다 ERD는 내게 쇼크를 가져오기에 충분했다. 사실 그전의 시스템 개발에서는 DB 구조를 왜 그렇게 가져가야 하는지는 모르고 다른 시스템의 흉내를 내고 있었던 상태였다. 정규화라는 것도 그때 알게 되었는데, 적어도 그 정도는 대학에서 배웠어야 하지 않았을까 약간의 원망도 하면서 ERD에 대해 공부해 나갔다. 내 관심의 포인트가 프로그램에서 시스템으로 완전히 옮겨가기도 했었고, 더는 코딩에는 관심이 없어졌다. 그즈음부터 나는 코딩을 더는 하지 않았다. 이상하게도 그동안 코딩을 하며 살아온 내 삶은 마치 그 새로운 개념들을 받아들이는데 초석이 된 정도로 역할을 다 한 것 같았고, 더 이상 코딩을 하면 그 변화를 역행하는 것 같았다.

그 시기에 투입된 프로젝트에서 내 역할은 모델러이면서 동시에 개발자들에게 모델링을 가르치고 그들의 머릿속에 있는 것들을 모델로 표현해 내는데 도움을 주는 것이었다. 그 작업을 하면서 비즈니스에 대해 많은 것을 배울 수가 있었고, 결국 모델은 아주 효과적인 의사소통의 수단이라는 결론에 도달하게 되었다. 그것은 개발자 간에도 역할을 하지만 개발자와 사용자 간에도 쓰일 수 있는 것이었다.

어떻게 보면 마치 건축에서 모델러는 건축설계가였고, 프로그래머는 직접 공사를 하는 업체였던 것이었다. 모델링 경험이 쌓이자 이제는 새로운 업무를 분석하는 시간이 짧아졌다. 하루 이틀이지만 초기 모델링이 가능해지면서 현업 실무자들과 인터뷰가 가능해졌다. 모델링의 효과를 느끼면서 점점 더 개발에 대해서는 관심을 잃어갔다. 프로젝트에서 모델링이 거의 끝나고 개발로 들어가게 되면 다른 프로젝트로 옮겨가며 모델링만으로 몇 년을 보냈다.

모델링을 하다 보니 이젠 “어떻게 하면 좋은 모델링을 할 수 있을까?“ 혹은 “좋은 모델이란 뭘까?“라는 의문이 들기 시작했고, 결국 요구분석의 과정이나 프로젝트 관리의 중요성도 알게 되었다.

그 당시 놓치고 있던 가장 중요한 것은 결국 모든 과정은 좋은 프로그램을 만들기 위한 것이었다가는 점이었다. 나는 유행처럼 멋져 보이는 모델링이나 프로젝트 관리만 신경을 쓰고 정작 그것들이 어떻게 코딩에까지 접목이 되는지는 관심이 없었다. 내가 만든 모델이 실제 개발자들에 의해 쓰여졌는지 아닌지에는 관심이 없었고, 개발 과정 중에도 그 모델들은 언제나 변경될 수 있다는 것도 간과하고 있었다.

그렇게 방법론과 프로젝트 관리, 소프트웨어 공학에 심취한 몇 년 동안 다시 IT 시장은 객체 지향이라는 큰 패러다임의 변화를 맞이하게 되었고 인터넷의 보급과 더불어 웹 개발이 시작되고 있었다. 객체지향을 책을 통해 개념적으로 이해하고 나는 객체지향을 다 안다고 착각했다. 실제 코딩도 해보지 않고, 시스템 개발도 해보지 않은 상태에서 개념적으로만 이해하면서 사내 교육센터를 통해 강의까지 하게 되었다.

게다가 조직 내에서는 이미 관리직으로 옮겨간 다음이라 팀원들을 객체지향으로 재무장시키기는 해도 정작 나 자신은 책을 통한 이해만으로 충분하다고 생각하고 말았고, 사실 실무를 놓고 몇 개월의 부트 캠프에 몰두할 시간을 내기란 불가능했다(나중에 코딩을 다시 시작하고 알게 된 거지만, 그 당시 Java나 VB로 코딩을 좀 해본 사람들이 내 강의를 어떻게 들었을지 생각하면 지금도 얼굴이 화끈거린다).

결국, 개발자의 꿈은 완전히 접고 관리직으로 올인하기로 맘을 먹었고 읽던 책들도 IT서적에서 경영 서적으로 바뀌었다. 그즈음에 읽었던 책 중에서 “기술직 팀원들에 대한 관리는 사실 신뢰가 없으면 불가능하다.”는 대목에서 많은 생각을 하게 되었다. 사실프로그램을 작성하는 한 사람 한 사람과 붙어있지 않고서는 어떻게 일을 하는지에 일일이 알 수도 없으니 믿을 수밖에 없는데, 믿어주는 사람을 실망시키고 싶지 않은 것도 개발자의 특성이라는 것이었다. 그러니 과거의 상명하복 시스템인 조직에서 제대로 된 개발자가 살아남기 힘든 이유이기도 했다.

하지만 정작 관리직으로 올인하기로 한 내 결정을 번복하게 만든 건 팀원들이 아니었다. 조직 내 다른 부서의 장들과 경쟁을 하면서 다시 한번 좌절을 느끼고 내가 한 것이정말 잘한 선택이었을까에 대한 고민을 시작했다.
좀 더 조직을 이해하고 관리도 제대로 해보고 싶어 결국 대학원에 진학하기로 했다.

대학원을 다니면서 얻은 것 한 가지는 관리직이 내 적성이 아니라는 것이었다. 물론 비즈니스에 대해 좀 더 잘 알게 되었고, 조직 관리나 경영에 대해서도 좀 더 이해하게 되었지만, 지나간 시간을 통틀어 돌이켜볼 때 내가 가장 빛나고 행복했던 시간은 개발자로 살았던 시간이란 걸 깨닫게 되었다.

그즈음 남편을 따라 미국으로 오면서 그동안 쉼 없이 달려온 내게 휴가를 주기로 했다. 년 정도 쉬고 나니 다시 일하고 싶은 욕구가 스멀스멀 올라오고 어떤 커리어로 시작할지 고민하게 되었다. 다행히 미국의 IT는 한국보다는 변화에 민감하지 않아서 한국에서는 이미 십 년 전에 없어진 기술들을 여전히 쓰는 곳도 많았다. 영어도 충분히 준비되지 않은 내게 선택의 폭은 넓지 않았고, 1994년 LG 에너지 프로젝트에 참여하면서 개발자들의 어깨너머로 본 Crystal Reports를 혼자 공부해 Report 개발자로 미국 회사에 첫발을 디뎠다. 다행히 내가 만든 Reports 들로 곧바로 인정을 받게 되면서 다른 개발 프로젝트를 맡게 되었고 다시 개발자의 커리어를 시작할 수 있게 되
었다.

미국 회사에서 일을 시작해보니 예전 에스티엠의 인사체계가 대부분의 미국회사들의 체계라는 걸 알게 되었다. 실제 흰머리의 60대 프로그래머와 같이 일을 하기도 했지만 매니저들은 개발자들을 아랫사람으로 대하지 않았고 오히려 기술적인 의견을 구하고 방향을 결정하려고 노력했다. 만일 이런 인사 시스템이 한국에 정착했더라면
개발을 정말 좋아하는 재능 있는 개발자들이 자신의 커리어를 굳이 관리직으로 바꾸지 않았어도 되었을 것이고, 지금쯤 몇 명은 정말 세계적인 아키텍트가 되어 있지 않았을까 싶다.

실제 2000년대 초반에 잠시 주택은행 프로젝트에 있을 때, 스웨덴에서 초빙된 백발의 SE를 만난 적이 있었다. 그분과 프로젝트 라이프 사이클에 대해 의논을 하면서 “내가 저 나이에도 프로젝트를 할 수 있을까?”하는 의문이 들기도 했었다. 메인프레임의 시대인 80년대 중반부터 클라이언트 서버, 웹 개발까지 개발자로 살아오면서 그 변화를 가능하게 했던 힘 가운데 하나가 모델링을 알게 되어서가 아닌가 싶다. 코딩 경력이 없는 모델링은 사상누각이다. 하지만 충분히 코딩을 해본 개발자들이 모델링 경험을 겸비한다면 엄청난 힘을 발휘할 수 있다. 사실 프로그램 코딩보다 앞서 요구 분석이나 설계가 만들어낸 시스템의 품질에 더 큰 영향을 미칠 수 있기때문이다.

나는 지금도 미팅을 하면서 동료가 잘 이해할 수 없는 그림을 끄적거리면서 설계를 동시에 한다. 운 좋게 모델러로 일해본 경험이 만들어낸 습관인데 함축된 그림이 얼마나 많은 정보를 담아내는지는 모델링을 해본 경험이 있는 사람이라면 이해할 수 있을 것이다.

나는 지금도 습관처럼 애플리케이션을 만들 때는 “왜 이게 필요하지?”라는 질문을 끊임없이 한다. 그렇게 “Why?“를 서너 번쯤 하다 보면 정말 중요한 것을 발견하게 되고 설계의 방향이 180도 바뀌는 걸 경험하게 된다.
지금도 개발을 하면서 지난달에 마친 애플리케이션을 수정하고 싶은 생각이 든다. 개발자는 스스로 끊임없이 성장한다. 그래서 개발 경험 몇 년 차인가 하는 것이 어느 학교를 졸업했느냐는 것보다 더 중요하다.

경력이 많은 개발자가 더욱 많아져야 한다. 그래서 개발자들이 아키텍트로 성장할 수 있어야 하고 비로소 우리도 세계 시장에 내놓을 수 있는 제품을 만들 수 있을 것이다. 미국에 와서 느낀 점은 인하우스 개발을 결정하기 전에 시장에 나와 있는 패키지를 도입해서 쓰는 경우가 많다는 것이다. 일단 패키지를 들여놓고 그걸 보완하는 애플리케이션을 만드는 것이다. 패키지를 사용하다 보면 애플리케이션을 어떻게 범용성 있게 완성도를 높이면서 만드는가에 대해서도 알 수 있고, 개발자에게는 다른 개발팀이 만든 시스템을 깊숙이 들여다볼 수 있는 기회가 되기도 한다. 실제 미국은 시장의 규모가 그만큼 받쳐주기도 하니 선택 가능한 패키지도 많은 편이다.

몇 년 전에 회사를 옮기면서 HR 매니저와 인터뷰하면서 “네가 가장 동기부여가 되는게 뭐냐?“라는 질문을 받았다. 그날의 대답은 형식적으로 짧게 마쳤지만, 내내 그 질문이 머릿속에 맴돌았다.

적어도 나는 내가 만든 애플리케이션을 좀 더 많은 사람이 사용하게 되기를 늘 희망했다. 나는 내 애플리케이션을 사용하는 사람들이 나로 인해 더 나은 삶을 살게 되기를 희망한다. 나는 키보드를 두드릴 힘이 남아 있는 동안에는 애플리케이션을 개발하고 싶다.

[프로그래머로 사는 법 기획연재 09 : 어떻게 프로그래머로 살까?]

<프로그래머로 사는 법>

* 본 내용은 도서의 내용을 일부 발췌하여 작성한 것입니다. 도서에는 더 많은 이야기를 담고 있답니다 :)

> 학생들이여 미래를 위한 공부를 하자

프로그래머로 살아오면서 가장 즐거우면서 힘든 점은 어떤 다른 분야보다도 그 발달의 속도가 빠르다는 것입니다. 빠르게 달라지는 트렌드를 이해하고 먹고 살기 위해서라도 빠르게 지식을 습득하고 현업에 사용해야 합니다. 이것은 프로그래머를 선택한 순간부터 지고 가는 업보가 아닐까요?

이렇게 빠르게 달라지고 쏟아지는 지식의 홍보 속에 가장 힘들게 보이는 것이 학교에서 프로그래머를 꿈꾸며 공부하는 대학생입니다. 왜냐하면, 대학생의 신분이라는 것이 졸업 후 현업에 필요한 지식을 습득하는 단계이고, 자신의 직업으로서의 전공 분야가 확실하게 정해지지 않은 상태로 4년 동안 필요한 지식을 습득해야 하기 때문입니다. 더구나 대학생이면 자신의 전공뿐만 아니라 영어나 수학과 같은 기본 수양 과목도 공부해야 하기에, 인생에서 가장 많은 자유의 시간을 가지면서도 가장 시간이 없는 때이기도 합니다.

제 개인적인 생각으로 대학생들에게 필요한 것은 두 가지라고 생각합니다.

첫 번째는 프로그래머가 가져야 할 공통 부분의 학습입니다. 이 학습의 목표는 프로그래머로서의 사고하는 방법에 대한 것들입니다. 알고리즘을 생각하는 방법, 아키텍처를 상상할 수 있는 방법 같은 것입니다. 이것은 기술적 트렌드와 상관없이 인간이 가진 기본적인 사고의 확장입니다.

두 번째는 미래에 예상되는 기술에 대한 학습입니다. 지금 당장 필요한 기술이 아니라 10년 이후에 통용될 만한 분야의 기술을 말하는 것입니다. 이것은 그리 쉽지 않겠지만, 학생들이 학습해야 하는 것은 바로바로 쓸 수 있는 기술은 아니므로 시간에 따로 조금씩 바꾸어 나가도 되겠죠. 사실 이것이 이루어져야 대학교를 아카데미라고 말
한 것에 근접해 가는 것이 아닐까 생각합니다. 어찌 되었든 이 부분은 학교와 학생들이 계속 고민해야 할 문제이기도 합니다.

정말 세상을 위해서 무언가를 기여할 프로그래머가 되고 싶다면, 대학생들은 기본적인 프로그래머에 필요한 공부가 무엇인가를 고민해야 하고 자신이 하고 싶고 10년 뒤에 통용될 지식은 어떤 것 일지를 항상 고민하고 그에 투자해야 합니다. 현재 유행하는 공부보다 미래를 위한 공부를 했으면 하는 것이 제 바램입니다.


> 큰 프로그램을 짜자

그렇다면 처음 프로그래머가 되려는 사람들은 어떻게 해야 할까요?

결론부터 말씀드리면 자신이 생각하기에도 어이없을 정도로 큰 프로그램을 작성하라는 것입니다. 프로그래머들은 처음 학습 단계에서는 아무것도 모르므로 아는 범위 안에서 문제를 해결하려고 합니다. 그래서 아주 간단한 프로그램만을 주로 작성합니다. 이런 프로그램을 위해 직접 작성하는 소스 라인은 1,000줄 이하가 될 게 뻔합니다. 이정도 프로그램을 백날 많이 짜 봤자 복잡도는 1,000줄 한계에서 벗어나지 못합니다. 이런 프로그램을 작성하면서 앞에서 이야기한 다양한 스킬을 얻기는 불가능합니다.

그래서 큰 프로그램을 작성해 보라고 하는 것입니다. 자신이 생각해도 어이없을 정도로 큰 프로그램에 도전해 보라는 것입니다. 실패해도 회사생활을 하는 것도 아닌데 어떻습니까? 학생 때는 실패해도 됩니다. 회사에서 잘릴 염려가 없습니다. 이런 부담감이 없는 것만 해도 엄청난 혜택입니다.

혹자는 프로그램을 제대로 작성하지도 못하는 사람에게 그런 식으로 욕심내서 정작 하나도 진행하지 못하면 어떻게 하라고 그런 식으로 말한다고 투덜댈지도 모르겠습니다. 제 경험상 그건 걱정할 것이 못 됩니다. 인간의 능력은 생각보다 좋습니다. 태어나면서 아무것도 모르는 것으로 시작하는 사람들로 가득 찬 지구상에서, 인간은 잘 살아갑니다. 회사 직원이나 학생을 대상으로 교육하면서 실험해본 경험에 의하면 잘 가르쳐 주는 것보다 무리한 요구로 조이고 알아서 해오라고 요구하는 방식의 진행일 경우가 더 실력 향상이 잘 됩니다.

무리할 정도로 큰 프로그램은 완성되지 않고 좌절될 가능성도 높지만 어찌 되었든 작성하려고 독한 마음 먹고 하면 그 과정에서 남는 것이 더 많습니다. 시쳇말로 삽질을 통해서 배우는 것이 더 많다고들 하지 않습니까? 큰 프로그램은 아무래도 여러 가지 상황이 복합적으로 엮이게 됩니다. 프로그래머로서 처음 배워야 하는 것 중 하나는 복잡한 문제에 대한 분해 능력입니다. 결국, 복잡한 문제를 작게 잘라서 프로그램 툴이 제공하는 단위까지 도달시켜야만 프로그램이 되는 것 아닙니까? 이렇게 분해했더라도 서로 연관관계와 처리 흐름도 생각하면 수없이 생각하고 많은 오류를 만나게 됩니다. 이런 것을 하나씩 해결하다 보면 어느새 자신도 모르게 유능한 프로그래머가 갖추어야 할 능력을 하나씩 갖추게 되는 것이죠.

결국, 많은 경험을 얻고 복잡한 문제에 대한 해결 능력을 확보하려면 큰 프로그램을 짜야지 작고 간단한 시험용 프로그램만 가지고는 어렵습니다. 큰 프로그램 작성에 욕심내면 그 안에서 수많은 시험용 코드도 자연스럽게 짜게 됩니다. 그래서 강조하고 싶습니다. 훌륭한 프로그래머가 되려면 시작부터 욕심내서 큰 프로그램을 짜세요.

> 프로그래머가 사업하면 좋은 점

프로그래머는 무언가 만드는 것을 좋아하는 부류의 사람들입니다. 굳이 돈이 안 되더라도 호기심을 충족시키고 자신이 만들고 싶은 무언가를 만들어 내기만 해도 즐거워합니다. 그래서 버틸 수 있는 사람들입니다. 내가 만든 것을 다른 사람들이 써 주고 좋아하면 그 자체로도 즐거울 수 있는 사람들이 개발자입니다.

이런 사람들에게 돈이란 그다음의 목표입니다. 내가 하고 싶은 것을 개발하기 위해서 필요한 돈을 벌고 싶은 것이고, 자신이 개발하고 싶은 시간을 확보하고 싶어서 이에 필요한 돈을 벌고 싶은 것입니다. 그러면서 좀 더 인간답게 살 수 있는, 남보다 더 부유하게 살 수 있는 욕심도 내 보는 것이죠.

저는 이런 프로그래머들에게 한 번쯤 사업을 꿈꾸는 것을 권하고 싶습니다. 사업을 한다고 해서 꼭 사장이 될 필요는 없습니다. 뜻이 맞고 미래를 공유할 수 있는 사람들이 모여서 창업하고, 그러면서 하고 싶은 개발을 하며 살 수 있다면 그 자체로도 매우 행복한 삶을 살 수 있으리라 봅니다. 프로그래머가 사업하면 좋은 점이 많습니다. 그 많은 점을 일일이 열거하기는 지면이 부족한 관계로 여기서는 대표적인 몇 가지만 이야기하고자 합니다.

자신이 정말 하고 싶은 것을 할 수 있다.

결론적으로 말하면 회사에 종속되어 있다면 자신이 하고 싶은 것이나 자신의 개발을 위한 투자를 하는 것에는 한계가 있습니다. 그렇지만 자신이 하고 싶은 개발을 하고 싶고 끊임없이 자신을 계발하고 싶은 욕구가 매우 강하다면 사업을 직접 하는 것이 가장 좋은 해결책이라고 봅니다.

사업을 하게 되면 하고 싶은 분야의 제품이나 서비스를 기획하고 이를 상업화하면 됩니다. 굳이 상업화하지 않더라도 기술 축적의 목적으로 이용할 수도 있습니다. 또 사업은 자영업과 다르게 반드시 조직을 갖게 됩니다. 조직이 형성된다는 것은 내가 가진 능력 이외의 구성원이 생긴다는 것이고 이는 내가 하고 싶지만 부족했던 부분을 보충해서 하고 싶은 것이 반드시 될 수 있도록 도와주는 시너지 효과가 있습니다. 즉 사업을 하면 내가 하고 싶은 것을 확실하게 할 수 있습니다.

자신이 정말 하고 싶지 않은 것을 하지 않아도 된다.

프로그래머가 직장인으로 생활하면서 한 번쯤 정말 하기 싫은 프로그램을 억지로 짜가야 하는 경우를 만나보지 못했다면 그건 행운아일 겁니다. 아무리 좋은 환경의 근무처라도 한 번쯤은 죽도록 하기 싫은 프로그램을 해야 할 경우가 있습니다. 왜? 앞에서 이야기했지만, 회사라는 곳은 이익 집단이고 회사 생존이 가장 우선이기 때문에 생존을 위해서라면 어떤 것이든 해야 할 때가 있습니다. 그것이 설령 직원이 싫어하는 것이라 하더라도 해야만 합니다.

프로그래머가 사업을 하면 어떤 일을 할지 말지를 선택할 수 있습니다. 물론 깊이 들어가 보면 생존을 위해서 어쩔 수 없이 해야 할 수도 있지만 정말 정말 싫다면 안 해도됩니다. 다른 대안을 스스로 선택할 수 있기 때문입니다. 그리고 대부분의 경우 프로그래머가 사업가가 되면 적당히 자신이 싫어하는 분야는 회피하게 되고 이런 분야의 일을 맡을 가능성도 적어집니다. 프로그래머가 사업가가 되면 좋은 점으로 두 번째를 제시하라면 자신이 정말 하고 싶지 않은 일을 하지 않을 자유를 얻게 되는 점을 들고 싶습니다.

자신의 시간을 얻게 된다.

세 번째로 사업을 하면 얻는 좋은 점을 든다면 개발 과정에서 여유 없이 항상 시간에 쫓기며 사는 프로그래머가, 자신이 노력한다면 자신의 시간을 만들 가능성을 가진다는 점을 들겠습니다.

정년이 없다.

회사는 냉정한 조직입니다. 회사 입장에서 보면 똑같은 일을 하는데 많은 비용이 들어가는 프로그래머는 골치 아픈 존재입니다. 그래서 어느 정도 이상의 비용을 지불하게 되면 더 싼 개발자를 찾게 됩니다. 문제는 더 싸고 체력 좋고 학습 능력도 좋은 신규 개발자는 계속 나온다는 것이죠. 물론 경험이나 문제 해결 능력은 떨어지지만 좀 더 싼 개발자가 회사 운영에 유리해지면 오래된 개발자는 바로 미운 오리 새끼가 됩니다. 슬픈 현실이지요.

나이 든 개발자들에 대한 사회적 고정 관념도 문제입니다. 나이 지긋한 분이 현장에서 키보드를 만지작거리고 개발을 하고 있으면 어쩐지 불쌍해 보입니다. 밑에 직원 시킬 일을 나이 든 양반이 하고 있으면 그리 좋게 보지 않습니다. 사회적 체면도 서지 않죠. 젊은 친구들 사이에 끼어 있는 나이 든 개발자를 진심으로 존경하는 것은 대한민국에서는 사회적으로 허용하지 않고 있는 것이 현실입니다. 그래서 일정 나이가 된 개발자는 관리나 영업 분야로 빠져나갑니다. 최근에야 개발자가 귀해지다 보니 어느 정도 인정해 주기 시작하고 있지만, 사회 전체적으로 보면 아직까지는 아닌 것이 현실입니다.

그런데 개발자가 사업을 하면 개발을 계속할 수 있습니다. 물론 사장이면 개발을 하는 것 자체를 주위에서 말리기도 하지만 본인이 직접 하겠다면 진짜로 말릴 사람은 아무도 없습니다. 사실 제가 그렇습니다. 전 지금도 하고 싶은 프로그램은 직접 작성해 가면서 대표이사직도 수행하고 있습니다. 개발 이사직급을 가지고 사업을 하면 더 확실하게 개발 일을 할 수 있습니다. 더구나 아무리 회사가 어려워도 사업가가 자신을 자르지는 않습니다. 더구나 사업가 자신은 정년도 없습니다. 진짜로 늙어서 죽을 때까지 프로그램을 할 수 있습니다.

사업 초기의 생존에 가장 유리하다.

회사라는 조직은 그 크기가 커질수록 제품이나 서비스를 만드는 데 필요한 인력을 유지하기 위한 비용 이외에 부가적인 비용이 필요합니다. 영업 활동을 위한 비용, 기술 확보를 위한 연구 비용, 조직을 관리하기 위한 비용, 회수가 불투명한 사전 사업 투자 비용 등등이 있습니다. 사업 초기에는 이러한 비용 지출이 별로 필요 없습니다. 대부분의 경우 1인이나 아주 소규모의 인력만 창업에 참여하고 운영되며 이들 역시 회사를 키우기 위해서 자기희생이 준비된 사람들입니다. 더구나 처음에는 영업 활동의 시작 시기여서 영업에 관련된 비용 지출이 적습니다. 또 조직도 작아서 관리 비용도 거의 발생하지 않습니다. 그저 제품이나 서비스 작성에 필요한 인력이 필요할 뿐입니다.

이미 개발 경력을 갖고 있던 사람들이 사업을 시작하면 고비용의 경력자를 채용하고 유지하는 비용은 필요 없게 됩니다. 이것은 다른 분야에 종사하던 사람이 창업하는 것에 비하면 엄청난 장점입니다. 독자적인 기술 우수성을 확보하기도 쉽고, 용역 형태로라도 생존에 필요한 매출을 달성하기가 쉽습니다. 물론 용역 형태로 지속해서 사업을 이끌어 가는 것은 역시 말리고 싶습니다. 그러나 생존 초기에는 이보다 쉬운 매출 형태는 드뭅니다.

영업적인 부분에서도 개발자가 창업하면 좋은 점이 많습니다. 영업적으로 계약에 관련된 부분을 이야기할 때, 순수 영업 부분만 이야기하는 경우는 없습니다. 제품이나 서비스와 관련된 기술적 질문을 하게 되고 이에 대한 솔루션을 알려 주어야 합니다. 개발자는 의외로 아는 것이 많습니다. 단지 그게 얼마만 한 가치를 가지고 있는가에대한 지식이 조금 부족할 뿐입니다. 이런 것은 사업을 해가면서 알아가면 그만입니다. 기술적인 자신감은 고객에게 신뢰감을 주고 매출로 손쉽게 이어 가게 해 줍니다. 초기에 흔히 생존 전략으로 선택하는 용역에서는 이런 기술적 신뢰감은 무척 중요합니다. 외부나 국가에서 투자를 받더라도 가장 중요한 것은 기술 확보입니다. 국책 과제를 수행할 때 기술적인 검사는 무척 중요합니다. 이때 개발자가 사업을 하면 이런 부분은 그리 크게 문제가 되지 않습니다. 도리어 가장 강한 분야이기도 합니다.

자유에는 책임이 따른다.

개발자가 사업하면 좋은 점은 위에 열거한 것 말고도 정말 많습니다. 어찌 되었든 사업을 하면 선택의 자유를 얻을 수 있습니다. 그렇지만 세상사가 항상 그렇듯이 자유를 얻는다는 것은 그에 따른 책임이 따르게 됩니다. 그 책임으로 불릴만한 것 중 하나가 개발자가 사업하면 나쁜 점 역시 존재하는 것입니다. 여기서는 이와 관련된 것은 이야기하지 않겠습니다. 단지 사업을 하는 순간 그 책임은 온전히 사업가가 가져간다는 것만 기억했으면 합니다. 사업을 시작한 순간 다른 누군가에게 넘길 방법이 없습니다. 회사의 직장인으로 생활할 때는 이 책임을 동료나 직장 상사나 임원이나 사장에게 넘길 수 있습니다. 하지만 사업가는 그런 행위 자체가 불가능합니다. 사업을 했더라도 생존 확률은 아주 낮습니다. 보통 살아남을 확률이 1/10이라고 합니다. 이 확률도 생존 확률이지 잘 될 확률이 아니라는 것입니다. 이렇게 살아남은 회사에서 약간의 성장이나 안정 상태로 들어갈 확률은 다시 1/10 정도라고 합니다. 이중 크게 잘 나아갈 확률은 다시 1/10이라고 합니다. 뭐 보통 사업가들 간에 회자되는 이야기라서 완벽하게 신뢰할 수 있는 것은 아니지만, 주위에 사업해 가는 것을 보면 아주 틀린 이야기도 아닙니다.

결론적으로 자신이 꿈꾸는 회사가 될 확률은 1/1000 정도 이내가 될 것입니다.

그렇지만, 프로그래머들이여! 사업을 하고 싶은가? 그렇다면 그냥 시작하십시오. 일단 사업을 시작했다면 수단과 방법을 가리지 말고 망하지 않게 하십시오. 그래야 당신이 하고 싶은 일을 할 수 있습니다. 저는 창업하는 프로그래머들에게 이렇게 이야기하고 싶습니다.

결정은 감성으로! 실행은 이성으로!