김용준의 '나는 프로그래머다' - 프로그래머는 어떻게 살까?

"프로그래머들은 어떤 삶을 사는 것일까?"

"프로그래머들은 어떤 사람들일까?"

이러한 궁금증을 해결하고 싶었다. 궁금증은 프로그래밍을 하는 친구가 추천해 준 '나는 프로그래머다' 를 통해서 

해소될 수 있었다.

이 책은 일곱 명의 프로그래머가 전해주는 이야기이다. 

두꺼운 책은 아니지만서도 더욱더 푸욱 빠져 읽을 수 있다. 벤처 투자자로서 앞서 말한 두 가지 궁금증을 가지게 되었고, 그런 입장에서 접하였는데도 재미있게 읽을 수 있었다.

그렇다. 나는 투자자로서 프로그래머를 대기 위해서 이 책을 읽어 내려갔다. 그렇기에 이 책에서 말하는 각종 프로그래머들의 언어는 외계어일 뿐이었다. 그저 프로그래머 사이에서도 주로 다루는 언어가 다르다는 정도를 인지했을 뿐이다. 하지만 이 책을 읽으면서 가슴이 두근거렸다. 그들의 삶이 그만큼 생생하게 다가왔다. 그만큼 그들의 삶은 열정적이었다.

투자자의 관점에서 읽어보면서, 세 가지로 프로그래머에 대해 정리해보았다.

1) 개인이 아니라 팀이 일을 한다.

2) 얼마나 아느냐 보다 얼마나 궁금해 하느냐가 중요하다.

3) 프로그래밍을 해보지 않으면, 그들을 모른다.

개인이 아무리 뛰어나더라도 팀이 중요한 직종이다. 시간에 쫒길 때 믿고 의지할 건 팀원 뿐이다. 팀원 마다 생각도 시각도 다르기에 '내'가 해결 못하는 문제를 '팀원'이 해결할 수도 있다. 이 외에도 다양한 이야기를 책에서 하고 있다. 자세히 기억은 못하지만, 이 한마디 만은 잊지 않을 것이다. 팀이 중요하다!!

프로그래머들이 일하는 직종은 빠르게 변한다. 역사가 오래되지 않았지만 확산 속도나 중요성은 급격이 증가하고 있다. 새로운 것 또한 수시로 올라온다. 그만큼 자기계발이 중요한 업이 프로그래머다. 계속해서 노력하지 않는다면 뒤에서 오는 후배들에게 뒤쳐지기란 시간 문제다. 뛰는 것을 멈추고 걷는다면 그 사람의 폐활량은 더이상 늘지 않을 것이다!!

프로그래머를 이해할 수 있을까. 솔직히 간접 경험을 했더라도 이해하기는 쉽지 않을 것이다. 간접 경험과 직접 경험에는 차이가 있기 때문이다. 그래서 그들에게 다가가고 그들과 이야기를 나누기 위해서는 한 가지를 유념해야 할 것이다. 우리는 그들을 모른다!!

이 책을 통해 이야기하는 프로그래머들은 한결같이 겸손하다. 그만큼 실패와 성공을 거듭하며 살아온 영향이다. 한편으로는 이 책에 나온 프로그래머들이 이 책을 통해 겨우 한 숨 돌리며 쉰 것은 아닐까 하는 생각도 지나간다.

프로그래머를 꿈꾸지 않는 사람도 이 책을 읽어보았으면 좋겠다. 적어도 한 사람의 이야기라도 읽어보았으면 좋겠다. 필자는 이 책을 통해서 '내가 그리 열정적이었던 것은 아니구나' 라는 것을 알 수 있었다.

마지막으로 이 책을 읽으며 얻은 기쁨과 행복, 열정을 책을 소개해준 친구 건일이에게 돌리고자 한다.

<글귀>

‘프로그래머’ 라는 존재는 하나지만 그 내용은 수많은 갈래로 나뉘어진다. C나 C++를 쓰는 사람과 자바(Java)를 이용하는 사람이 길을 달리하고, 데이터베이스를 관리하는 사람과 시스템을 관리하는 사람이 길을 달리한다. 길마다 겪는 경험의 결이 다르고 깊이가 다르기 때문에 이 모든 것을 묶어서 하나의 보편적인 길로 제시하기는 어렵다. … 하지만 이 모든 차이점 중에서 가장 중요한 것은 바로 프로그래밍에 대한 꿈과 열정이 있는가 아니면 없는가다. 그것은 ‘진짜’ 프로그래머와 ‘그냥’ 프로그래머를 가르는 결정적인 눈금이 된다.

인생에 있어서 도전이란 결코 입맛에 딱 맞는 방식으로 찾아오지 않는다. 그것은 언제나 두 발을 전부 땅에서 떼서 허공에 몸을 완전히 맡겨야 하는, 따라서 상당한 불편함과 두려움을 수반하는 방식으로 찾아온다. 어렵지만 마음에 쏙 드는 일자리를 만났을 때, 어렵지만 풀어 보고 싶은 문제를 만났을 때, 어렵지만 한 번 걸어 보고 싶은 길을 만났을 때, 어렵지만 한 번쯤 말을 꼭 걸어 보고 싶은 이성을 만났을 때, 필요한 것은 앞뒤를 재고 따지는 ‘계산’이 아니라 최선을 다해서 허공에 몸을 맡기는 ‘용기’다.

프로그래밍에서 치열한 ‘설계’ 의 과정이 단순한 ‘코딩’ 의 과정보다 중요하다는 사실을 깨달은 것은 아직 한참의 시간이 흐르고 난 다음이었다.

부지런히 공부하면서 새로움을 추구하는 그의 자세는 배울 점이 많았다.

프로그래밍이 결코 단순한 노동에 머무르지 않고 독창적인 창의성을 요구하는 창조적 활동이라는 점을 고려한다면 ‘영어 등급’ 이나 ‘신발 색깔’ 과 같은 여러 가지 일들을 고민할 수밖에 없는 현실은 서글픔을 자아냈다. 사소한 일들로 인해서 창의성이 억압받을 때마다 그림자 놀이를 하는 손가락이 잘려 나가는 듯한 아픔을 느끼곤 했다.

내가 항상 도전하고 항상 최선을 다하는 것은 물론 아니다. 때론 게으름을 부리고 때론 넓은 길을 골라서 기려고 애쓴다. 하지만 젊을수록 그리고 창창한 미래가 앞에 놓여 있을수록, ‘용기’ 와 ‘최선을 다하는 자세’ 가 중요하다.

아무리 기능이 뛰어난 코드라고 해도 가독성이 떨어지면 질이 낮은 프로그램이라는 사실을 그는 인정하지 않았다.

좋은 프로그래머가 되려는 사람은 참고서를 보면 누구나 쉽게 알 수 있는 단편적인 지식을 구하는 것이 아니라 도저한 논리와 지적 통합의 근본적인 능력을 키우려고 노력해야 한다. 그리고 그런 능력은 결코 두툼한 프로그래밍 참고서를 끼고 사는 것만으로 이루어지지 않는다. … 그러한 근본적인 능력은 바로 사람의 삶에 맞닿아 있기 때문이다.

정작 중요한 것은 안에 담겨 있는 내용이라는 점을 생각한다면 프레임워크나 언어의 선택은 유연하게 생각할 수 있어야 한다. 도구의 옳고 그름은 절대적으로 결정되는 것이 아니라 언제나 주어진 조건의 구체적인 내용에 따라서 달라진다는 점을 이해할 필요가 있다.

다른 사람의 의견에 쉽게 동의하지 않는 청개구리 근성으로 따지자면 정치인에 못지 않은 것이 바로 프로그래머일 것이다.

그들은 대충이라는 말을 아예 모르는 사람들 같았다. 한 번 회의를 하고 나면 (조금 과장해서) 한 권의 책 분량의 회의록이 작성되었다. 논쟁을 할 때에도 적당히 넘겨짚는 법이 없고 항상 정확한 근거와 자료를 동원했기 때문에 긴장을 늦출 수 없었다.

어느 정도 시간이 지나면 학부 과정에서 이론으로만 배웠던 지식들이 필요하고 그때 왜 그런 내용을 배웠는가를 깨닫는 순간이 올 것이다. 그때는 자신의 머리 속에 잠자던 지식들이 되살아나게 될 것이며, 그 지식들은 다른 관점에서 프로그래밍에 대한 생각을 하게 하는 원동력이 될 것이다. 경험적으로 다시 말하지만, “절대로 학교에서 배운 지식은 죽은 지식이 아니다!”

오래된 개념을 고집하면 어느새 도태되어 버리는 것이 프로그래머의 세계다.

이런 후배들과 지내보면 학습하는 시간이 정말 짧다는 것을 느낀다. 내가 3년에 걸쳐 배웠던 지식을 짧게는 6개월에서 1년이면 습득해 버린다. 이렇게 빠르게 쫓아오는 후배들을 보면 기가 질린다. 그래서 나는 후배들이 무섭다.

위대한 프로그래머들 역시 버그가 있는 프로그램을 만든다. 단지 최선을 다해서 발견할 수 있는 상황에서 발견된 버그들을 제거할 뿐이다. 그래서 하는 말이다. “초보 단계를 넘어서는 프로그래머들이여! 걱정하지 마라!”

프로젝트를 성공적으로 수행하기 위해서는 많은 필요 조건이 있다. 하지만 팀워크만큼 중요한 것은 없을 것이다. 팀워크는 그냥 이루어지지 않는다. 서로 믿고 의지할 때만 생기는 것이다. 팀워크가 있으면 그외의 난관은 별 문제가 되지 않는다. 사람은 문제를 해결할 수 있는 능력이 있고 그 능력은 혼자보다 여럿이 의지할 때 더 큰 힘이 발휘되는 것이다. 또한 성공의 기쁨은 혼자일 때보다 여럿이 나눌 때 더 배가 된다. 난 정말 행복하게도 이런 결론을 직접 겪으면서 느꼈다. 그래서 자신 있게 말할 수 있다. “프로젝트의 성공은 팀워크에 달려 있다.”

언젠가는 터진다. 절대로 졸면서 프로그래밍을 하면 안 된다. 졸음 버그에 당한 사람만이 그 쓴맛을 안다. 졸음 버그를 막으려면 효과도 없는 밤샘 작업을 하지 않는 것이 상책이고 차선책으로는 소스 버전 관리를 잘 하는 수밖에 없다.

한 번 동작했던 기계는 절대로 거짓말을 하지 않는다. 모든 버그는 자기 자신에게서 나온다.

지금은 주로 기계를 상대로 하는 프로그램을 상대한다. 이 분야를 다른 사람들은 시스템 프로그래머라고도 하고 임베디드 프로그래머라고도 한다.

다른 사람이 보기에 별것도 아닌 수정사항이 프로그래머 입장에서는 많을 수도 있다.

프로그래머라는 직업은 프로그래밍 자체를 무척 좋아하던 사람들이 많이 택한다. 그냥 먹고사는 방법으로 프로그래머라는 직업을 택했던 사람들이 오래가는 것을 나는 보지 못했다.

자기가 사업을 하지 않는 이상 실력은 대우를 받기 위한 최우선의 조건이다. 능력 있는 사람은 항상 주위에서 필요로 하기 때문에 취업 때문에 고민도 하지 않는다.

특히 프로그램 관련 아이템을 가지고 시작하는 분들은 아이디어 하나만을 가지고 꿈을 이루어 가기 위해 노력하는 것을 종종 볼 수 있다.

이제는 그야말로 “성공은 성적순이 아니잖아요” 라고 말할 수 있는 시대가 온 것이다. 그럼 무엇이 성공하게 하는가? 바로 내가 좋아서 미칠 수 있는 영역을 가지고 있느냐 없느냐 하는 것이라고 나는 생각한다.

우선 컨설턴트를 먼저 살펴보자. 컨설턴트는 우선 말을 잘해야하고 논리적인 사고가 가능해야 한다. 이들의 특성을 보면 평소 꼬치꼬치 따지는 사람이라든가 남에게 같은 말을 해도 설득력 있게 표현하는 사람들이다. 또한 탐구 정신이 있어서 기존의 업무 절차에 만족하기보다는 무언가 새롭고 좋은 것을 갈망하는 열정이 있다. 그래야 고객의 업무를 조금이나마 업그레이드해서 설계해 줄 수 있다.

개략적인 프로젝트의 라이프 사이클을 보면, 고객의 요청 단계, 제안서 작성 단계, 프로젝트 착수 단계, 프로젝트 수행 단계, 프로젝트 종료 단계 등 5단계의 생명 주기를 거치게 된다.

외국계 SI 업체에와 합작사였던 L사에 다닐 때 받은 또 하나의 충격은 외국 SI 업체에서 온 문서들을 보면 대부분 어떤 개념을 반드시 그림으로 표현한다는 것이다.

결국 유능한 IT인이 되기 위해서는 프로그램 코딩 작업 못지 않게 현재의 상황을 기술하고 문제점을 찾아내고 미래에 구축될 시스템을 그려내어 고객으로 하여금 중간중간에 IT 인력들이 수행하고 있는 업무 내용을 이해하도록 하는 문서화 작업도 필요하다. … 또한 업계에서는 유능한 컨설턴트의 조건으로 얼마나 논리적이고 설득력 있는 문서를 만들어 내는가를 주요 항목으로 꼽기도 한다.

이제까지 여러 프로젝트를 수행해 오면서 보람을 느꼈던 순간들을 떠올려 보았다. 1) 고객이 자기 업무밖에 몰랐는데 전체 업무를 분석하면서 새로운 시각을 갖게 되었다고 말할 때 2) 공공 프로젝트의 경우 서비스 개시하고 나서 많은 시민들이 그 서비스를 이용하는 모습을 볼 때 3) 우리가 구축한 시스템 때문에 고객이 승진할 때 4) 프로젝트 팀원들이 작성한 산출물들이 수십 권의 바인더로 돌변할 때 5) 고객이 원하는 조회 화면이 오류 없이 화면에 들 때 6) 내가 작성해서 배포한 전체 일정에 따라 팀원들이 잘 따라와 줄 때 7) 몰랐던 분야를 업무 분석을 통해 알게 되었을 때 8) 고객이 아직 가지 않은 길을 우리가 닦고 있다고 느꼈을 때

“처음의 고생을 불평하지 마라. 평생 밑천이 된다.”

불평하는 고객이 진정 시스템에 이로운 고객이라는 것은 업종을 불문하고 진리라는 것은 다음의 조사를 보더라도 알 수 있다.

개발자가 가장 경계해야 될 것이 바로 이 익숙해짐과 익숙함으로부터 오는 편안함에 안주하는 것이다.

프로그램 로직을 처리하다 보면 자기가 예상하지 못한 문제가 항상 도사리고 있으며 언제 그 문제가 발생할지 모른다.

하룻밤 날 코딩하여 개발했던 프로그램이 가장 많이 사용하는 핵심적인 프로그램이 된 걸 보면 우습기도 하고 업무를 정확히 이해하고 구축하는 것이 얼마나 중요한지를 알게 해주었다.

문제는 Knowing about 이 아니라 Knowing을 해야 한다. Knowing은 지식으로 알고 경험하여 마음까지 느껴져 그에 대해 행동으로 나올 수 있는 참 지식의 단계로 설명할 수 있다. 요약하면, 설명을 위한 지식이 아니라 느끼고 적용을 위한 지식이 되어야 하는 것이다.

끊임없이 자신의 기술에 대해 생각하고 다른 사람과 기꺼이 이야기하며 상대방의 관점과 주위 상황 등에 대해 열려 있는 생각을 가지는 것이 자신의 발전을 위해 중요한 요소가 된다.

스페셜리스트가 되기 위해서 제너럴리스트를 포기했지만, 스페셜리스트로서 지식이 깊어갈수록 결과적으로 일정 수준을 갖춘 제너럴리스트가 되어가는 것을 느꼈다.

개발할 프로그램이 어떻게 사용되는지, 주목적이 무엇인지, 자기가 사용자의 입장에서 그 프로그램을 사용한다면 지금 개발하는 기능이 정말 효율적인지에 대해서 생각해 봐야 된다. 프로그램 자체가 중요한 것이 아니고, 그 프로그램을 통해서 얻을 효과에 대해서 얼마나 많이 보장할 수 있는지가 중요하다.

장황하게 메뉴얼을 볼 필요성에 대해서 말하는 것은 정말 개발자가 갖춰야 할 덕목 중에 호기심이 있다는 것을 알려주고 싶어서이다.

제도적으로 정착된 사업이 아니기 때문에 수입의 편차가 큰 직종이다.