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

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

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


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

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


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

전국적으로 폭설이 있을꺼라는 뉴스가 있었던 12월 6일 오전, 사우회장님께 한통의 메일을 받았습니다.

메일이 도착한지 얼마되지 않아서 눈이 막 내리기 시작하더라고요.
조금 이른감이 있는 많은 양의 눈이었지만 여전히 눈은 사람을 기분좋게 해주긴 하는거 같아요. 회사 건물에도 눈이 소복히 쌓였답니다.

눈 소식에 바빠지신 사우회장님. 완제품을 사다가 나눠 주시는건가 했는데 따끈따끈 정성가득 만난 파전이어야 한다며 점심시간을 이용해 한빛미디어 직원을 위한 재료를 한아름 구입해 오셨습니다.



순식간에 1층 세미나실이 부엌으로 변신~ 사우회장님을 도와 파전굽기를 도와주실 일명 핑크레이디들과 함께
일사천리 준비에 들어갔죠. 기혼자가 많기로 유명한 한빛미디어라 그런지 남자분들도 척척, 오히려 미혼의 여성직원분들보다 더 잘하시더라고요.


새우, 오징어, 굴 등 싱싱한 해산물을 비롯해 술집에서 파는 파전 부럽지 않은 파전을 만들기 위한  재료 준비 완료! 평소에 캠핑을 좋아하시는 이사님께서 보유하고 계신 캠핑 도구를 대여해 파전을 목놓아 기다리고 계신 직원들을 위해 빠르게 부치기 작업 돌입.  노릇노릇 맛있게 구워지고 있는 파전


짠! 완성된 파전입니다. 때깔이며 기름기가 좌르르르 한것이 참 맛나보이죠?  완성된 아이들은 열심히 일하고 계신 각 층으로 신속하게 배달~


열심히 일하다가 출출한 시간 반갑게, 그리고 맛있게 파전을 즐기시는 한빛미디어 가족의 모습입니다. 너무 맛있다며 맛나게 드시는 분들을 보니 제가 다 뿌듯하더라고요. 남은 일마무리를 위해 막걸리는 입가심 정도로 간단하게.


자칫 지루해지기 쉬운 업무와 일상에 직원들의 재미와 사기 진작을 위한 의도로 진행된 사우회의 '회사에서 먹는 파전&막걸리' 이벤트는 준비를 하는 사람도, 먹는 사람도 모두 기분 좋은 이벤트였습니다. 독자님도 초대해서 함께 즐기는 기회가 되면 좋겠다 싶은 마음이 들어서 좀 아쉬웠답니다. (정말이에요~) 보충한 파전&막걸리 파워는 더 좋은 책을 만드는데 쏟아 붓는 것이 독자님께 돌려드리는 방법이라 믿고 열심히 정진하겠습니다.
꽁꽁언 도로 조심하시고, 춥지만 마음은 따뜻한 즐거운 겨울 보내세요 :

10월 9일 한글날을 이웃한 10월 11일이 책의 날인거 알고 계셨나요? 활자의 지식으로의 환골탈태, 책과 한글의 인접함이 적절히 잘 어울리는 느낌이네요. 제 26회 책의 날을 기념한 출판문화 발전 유공자 시상식이 11월 마지막날 국립중앙도서관에서 개최되었습니다. 본 행사는 추천과 검증이라는 엄격한 절차를 통해 거쳐 책에 대한 열정으로 묵묵히 한 길을 걸어오신 분들께 상을 전달하는 자리였습니다.  

이날 한빛미디어 김태헌 사장님께서도 문화체육관광부 표창장을 수상하셔서 사장님의 수상을 축하드리고자 예쁘게 포장한 꽃다발을 들고 찾아갔습니다.


행사에서 대통령 표창을 포함하여 총 36분이 상을 받으셨는데요, IT업계는 한빛미디어가 유일해서 더욱 어깨가 으쓱해지는 순간이었습니다. 가슴에 꽃을 달고 수상자석에 앉아 계신 사장님의 모습. 긴장과 떨림보다는 여유가 보이는 모습에서 19년 출판의 관록이 느껴지네요.


식순에 따라 대한출판문화협회장님의 기념사와 문화체육관광부장관님의 축사가 이어지고 드디어 시상! 사장님의 성함이 불리는데 제가 다 흥분되더라고요. 단상위에 서서 순서를 기다리시는 사장님의 모습. 요때는 살짝 긴장을 하신것도 같네요 ^^


수상자분들의 직장동료 및 가족분들이 많이 참석하셔서 단상 앞은 사진으려는 분들로 인산인해. 높은 굽에 탑승하여 기회를 노리고 있었는데도 사장님의 수상 장면을 찍을 만한 공간을 찾기가 어렵더라고요. 겨우 겨우 자리를 잡은 순간 사장님의 성함이 호명되고 앞자리로 나오신 사장님.



뭐니뭐니해도 수상 사진은 상패를 건네는 그 장면이지. 레디하고 표창장이 건네지는 순간을 기다려 셔터를 찰칵 눌렀죠. 나이스 캐치를 속으로 외치려는데 뭔가 함께 빛이 터지는 느낌.


'뭐지?' 하고 사진을 확인하니 뒤에 있던 플래시까지 장착한 카메라에 묻혀 사진이 그만 이렇게 ㅠ 중요한 순간을 아쉽게 놓치고 말았죠. 오늘 이 장면 찍으려고 노리고 있었는데 ㅠ  그래도 사장님이신거 티나니까 이 사진이라도 킵하는 걸로!


수상식이 끝나고 내려오신 사장님께 직원을 대표하여 축하와 존경의 마음을 담아 꽃다발을 전달해 드렸습니다.
환하게 웃으시는 저희 사장님, 참 인상 좋으시죠? 올바른 신념과 원칙으로 회사를 이끌어 가시는 한빛미디어의 얼굴이시랍니다.

상을 받는다는 것. 성과와 타인으로부터의 인정이라는 관점에서 기분 좋은 일이기도 하지만 책임감과 사명감의 또다른 이름이 아닐까요? 어떤 일이든 하루 3시간씩 10년을 연습하면 전문가가 된다는 1만 시간의 법칙. 19년 전 한빛미디어를 창립하고 하루 24시간 책과 독자만을 생각하신 사장님은 이미 출판계의 달인이 아닐까하는 생각이 들었습니다. 한빛미디어 김태헌 사장님의 수상을 함께 축하해 주시고 올해로 19살, 내년에 성인이 되는 한빛미디어의 성장을 앞으로도 지켜봐주세요.




P.S 블로그에 사장님 이야기를 쓰는 날이 오면 이야기를 하고 싶었던 사장님도 직장인

1. 사장님은 다른 건 몰라도 개그콘서트는 본방 사수를 하려고 노력하신다고 하는데요, 일요일 저녁 개그 콘서트를 보고 나시면 "주말 다갔어 아 내일 월요일.." 하고 굉장히 우울해지신다고 합니다. 아마도 요런 느낌?


2. 사업계획이다, 기획회의다 회의가 잔뜩 잡혀있던 날 또 다른 회의 참석길에 엘레베이터에서 마주친 사장님의 독백 "아, 진짜 집에 가고싶다"

아, 그냥 저희 사장님 진짜 인간적이시라고요 :)

 

[프로그래머로 사는 법 기획연재 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 정도 이내가 될 것입니다.

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

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