프로그래머가 되기 전에 알았더라면 좋았을 것들

서문_ 벤츠 타는 프로그래머와 커피 타는 프로그래머의 차이는 어디에 있는가?

제1장_기술력만으로는 프로그램이 완성되지 않는다
프로그래머의 기술 능력은 분명히 향상되었지만… | 기술을 이해해도 업무를 파악하지 못하면 소용없다 | 프로그래머의 업무는 요구를 이해하는 것에서 시작된다 | 아마 이럴 거야, 추측하면 문제가 생긴다 | 지나친 완벽함이 작업의 진척을 방해한다 | 현실은 진흙탕, 수많은 예외로 가득하다 | 할 수 있느냐 없느냐가 아니라 해결할 수 있느냐 없느냐가 중요하다 | 자신이 생각하는 완벽함과 타인이 생각하는 완벽함은 일치할 수 없다 | 시간이 갈수록 상대방의 기대 수준은 높아진다 | 상대방은 당신이 생각하는 만큼 신경 쓰지 않는다 | 매일 블로그를 작성하려면 시간이 얼마나 필요할까?

제2장_규칙이나 프로세스에 사로잡히지 말라
나는 어떻게 문서 체크 지옥에서 벗어날 수 있었나 | 골치 아픈 상대일수록 진지하게 교류하라 | 어떻게 해야 창조적으로 수고를 줄일 수 있을까 | 목적 달성을 위한 더 좋은 방법이 있다면 당당히 상대와 의논하라 | 고객은 왕이라고 생각하는 원청업체는 조심하라 | 견적 구상 단계에서 프로토타입을 만들어보라 | 도급 업무라도 지시받은 대로만 진행하겠다는 생각은 위험하다

제3장_고객은 기술적으로 완벽함을 추구하는 제품을 기뻐하지 않는다
완벽함을 추구했다. 하지만 완성되지 않는다면? | 모든 요구에 대응하는 것을 목표로 하면 일은 진행되지 않는다 | 자기만족을 위한 개발 | 저렴하기만 하면 그걸로 OK? | 고객 만족이 전부일까?

제4장_다른 사람과의 관계가 기술을 살린다
프로그래머라고 해서 사무실에만 틀어박혀있지는 말라 | 전문 분야 이외의 이벤트도 둘러보자 | 일방적으로 듣기만 하는 세미나는 재미없다 | 시간 들여 깊이 있게 교류해야만 얻을 수 있는 것이 있다 | 만나자는 제의를 받으면 바로 만나러가라 | 상대방에게 의존하고 부탁도 해보라 | 기술뿐만 아니라 정신적으로도 신뢰받는 존재가 돼라 | 원활한 커뮤니케이션을 진행하는 법 | 지시를 내린 배경을 명확히 하라 | 상대방을 자극하지 않는 일의 어려움 | 자존심을 버리는 간단한 방법 | 화내지 마라, 앞서가지 마라 | 화내지 않는 참 쉬운 방법 | 남들이 알아주지 않으면 결국 나만 손해다 | 인터넷이 홍보 개념을 파괴했다 | 무엇이든 도전해보자

제5장_부가가치 높은 업무를 맡는 법
다른 사람은 할 수 없는 어려운 업무에 도전하라 | 소스 수정이 어려워 처음부터 다시 만들다 | 3시간 만에 프로토타입을 작성했던 비결 | 프로토타입으로 시작할 부분과 처음부터 확실히 만들 부분을 명확하게! | 주변을 참여시켜 빡빡한 스케줄을 극복하라 | 본가동에서 발생할 트러블의 씨앗을 뽑아내라 | 신뢰성과 유지보수성을 높여라 | 애써 만든 것을 간단히 끝내버리지 말라 | 처음에는 실적을 알리는 것이 최고다 | 계속 계속 개량하라 | 기능을 확장할 때 조심해야 할 것 | 제품을 다각적인 사업으로 전개하라 | 부가가치 높은 업무를 위한 8가지 포인트

제6장_2인 공동 프로젝트에 도전하라
최고로 만든 나만의 제품이 실패하는 이유 | 잘 팔리는 IT제품을 만드는 비결 | 다른 회사에 다니는 두 사람이 한 팀이 돼라 | 인원이 너무 많을 때의 단점 | 진짜 난관은 프로그래밍이 아니다 | 말만 하는 것과 진짜 실행하는 것은 차원이 전혀 다르다 | 직접 과제를 해결하겠다는 마음을 유지하라 | 두 사람이 함께 문제를 극복하라 | 각자 회사의 압박에 어떻게 맞붙을 것인가? | 자기 전문 분야 이외의 전문가와 협력하는 법

제7장_수주 개발이냐 개발 및 판매냐 그것이 문제로다
수주 개발의 단점과 장점 | 제품 개발 및 판매가 즐거운 이유 | 수익이 날 때까지 어떻게 먹고살 것인가 | 이미 비슷한 것이 존재한다고 잘 팔리지 않는 것은 아니다 | 모두가 좋다고 평가한 제품에 독창성이 있을까? | 이해하기 힘든 것에 새로운 가능성이 숨어있다 | 가격을 어떻게 결정할 것인가? | 저렴한 제품은 완성도를 높여 많이 팔아야 | 고가 제품은 신뢰 관계 쌓기가 중요하다 | 그래서 어떻게 알릴 것인가? | 궤도에 오른 이후의 수고를 무시할 수 없다 | 저렴한 제품과 비싼 제품 중에서 어느 쪽이 사업하기 쉬울까? | 무지를 드러내는 것이 ‘성공의 지름길’이다

제8장_사업 부서를 세우고, 운영에 뛰어든다는 것
회사 방침에 불만을 품고 사장과 담판을 벌이다 | 참을 수 없는 책임량 미달성의 괴로움 | 수주 개발은 사업부 초보 리더에게 안성맞춤 | 월급의 3배는 벌어야 회사가 제대로 돌아간다 | 수주 개발은 성과급과 잘 어울린다 | 이제 성과급이 최선의 선택은 아니다 | 3년 동안 실패하며 파악한 것들

제9장_자신의 제품으로 세계를 움직여라
우리는 왜 수입 제품을 선호할까? | 담당자는 리스크를 회피하려고만 한다 | 자국 경쟁 때문에 외국 업체 배만 불릴 것인가? | 해외 체험을 하면, 비로소 보이는 것들 | 태국에서 환영받는 벤더는? | 태국은 라인(Line)을 좋아해 | 스마트폰 보급률이 일본보다 높은 태국, 동영상 시청률은 세계 2위 | 포화 직전의 모바일 회선이 기회다 | 100개의 매장에서 동일한 물건을 팔고 있다면 어떻게 차별화를 해야 할까? | 나라가 달라지면 요구 사항도 달라진다 | 좋은 제품을 만드는 것뿐만 아니라 좋은 인간관계를 쌓는 것이 중요하다

제10장_평생 프로그래머로 먹고살려면
만들기만 하면 된다고 생각하면 안 된다 | 비즈니스에 적극적으로 관여하라 | 자신 있는 분야를 사람들에게 알려라 | 불경기의 생존 무기는 결국 자신 있는 분야뿐 | 프로그래머의 자신 있는 분야란 자신 있는 프로그래밍 언어를 의미하는 것이 아니다 | 아무도 손대지 않은 업무야말로 찬스다!

기술적인 능력은 갖췄지만 업무적인 면에서는 불충분한 결과를 초래한 경우를 자주 보았습니다. 사양서를 기초로 코딩을 할 경우든 고객의 요구를 실현하는 경우든 처음부터 ‘무엇을 만들고 싶은가?’를 이해하지 못하면 아무 소용이 없습니다. 이해가 될 때까지 상대방과 의견을 교환하는 능력도 필요합니다. 프로그래머라는 업무 이전에 일반적인 회사원으로서의 능력도 매우 중요합니다. 기술적인 능력 이외의 프로그래머로서의 업무 능력은 진정한 프로그래머로서 활약할 수 있는 요소임과 동시에 프로그래머가 일에 대한 보람을 더욱 잘 느끼기 위한 직접적인 원동력으로 작용합니다. - 서문 중에서

누구나 그저 프로그래머라고 부르지만 그 업무의 범위는 다양합니다. ‘상세설계서를 기초로 코딩을 하는 사람’도 프로그래머이고, ‘의뢰한 사람과 토론을 펼치면서 프로그램을 완성하는 사람’도 프로그래머입니다. 다만 어떠한 경우라도 의뢰한 사람이 무엇을 원하는가를 이해하는 것이 가장 중요한 업무라는 점에는 변함이 없습니다. 당연한 말이라고 느끼시겠지만 이 단계에서 실패하는 프로그래머가 매우 많습니다. 완벽한 설계서는 있을 수 없습니다. 그렇기에 어떠한 경우라도 의뢰한 사람과의 의사소통은 매우 중요합니다. - 1장 중에서

오타쿠 지수가 높은 프로그래머에게 업무를 부탁하면 ‘의외로 시간이 오래 걸린다’, ‘아무리 기다려도 완성이 되지 않는다’, ‘융통성이 없다’라고 느낄 때가 많습니다. 지식과 기술력 모두 뛰어난데 업무는 왜 원활하게 진행되지 않는 걸까요? 제 생각에는 ‘지나치게 높은 이상이 업무를 방해하기 때문’이 아닐까 합니다. 취미 수준의 프로그래밍에서는 프로그래머 본인만 이해할 수 있으면 OK인 경우가 대부분입니다. 업무적인 프로그래밍에서는 다른 사람이 소스 코드를 볼 경우가 많습니다. 기술적으로 공을 들인 점은 넘어가더라도 소스 코드가 너무 복잡하면 일반적으로 좋은 결과가 나오지 않습니다. - 1장 중에서

기본적으로 저는 ‘많은 사람들이 다가가기를 꺼려하는 사람’일수록 깊게 교류해야 한다고 생각했습니다. 일반적으로 ‘시비를 확실히 가리면서 어떤 일에나 깐깐한 사람’은 다가가기 어려운 법이지만 그런 사람일수록 일단 친해지면 도움을 받을 일이 많습니다. 저는, 흔히 말하는 ‘적으로 만들기엔 두려운 사람’과 더욱 친해지고 싶었습니다. 또 어떤 일에나 깐깐한 사람은 사실 친해지면 매우 부드러운 면을 가진 사람이 많았다는 생각을 해봅니다. - 2장 중에서

저는 ‘탁상공론’을 싫어하는 스타일이다보니 확실한 설계서를 만들기 전에 반드시 프로토타입을 만들어 확인하곤 합니다. 제가 작업했던 업무가 도전적인 것이 많아서 그렇기도 하지만 기본적으로 ‘견적을 생각하는 단계’에서 프로토타입을 제작합니다. 제작 여부가 불투명한 작업에 대해 견적을 낼 수도 없는 노릇이고, 어느 정도 기술적인 전망이 서지 않으면 전체적인 작업량도 파악할 수 없기 때문입니다. 물론, 프로토타입이나 시뮬레이터를 아주 단시간에 제작하려면 기술력이 필요합니다. 견적하는 데 반년이나 걸렸다가는 다른 곳 에서 일을 채가겠죠. - 2장 중에서

자신을 파악하기 위해서는 많은 사람으로부터 객관적인 평가를 받는 것이 가장 좋습니다. 다양한 사람과 이야기를 하다 보면 목표로 삼아야 할 주제가 보이게 됩니다. 방에 틀어박혀서 작업만 하고 있으면 그러한 힌트는 얻을 수 없죠. 하루 종일 회사에 틀어박혀서 계속 프로그래밍을 하는 것보다는 고객이나 판매 대리점 관계자 등과 자주 만나 다양한 정보를 얻거나 현장을 관찰하는 것이 훨씬 도움이 됩니다. 저는 기회만 있으면 밖으로 나갔습니다. 이메일이나 전화로 해결할 수 있는 안건이라도 가능하면 상대를 방문했습니다. - 4장 중에서

이왕 해야 한다면 다른 사람은 할 수 없는 어려운 과제에 도전해보는 것은 어떨까요? 일단 다른 곳과 비교되면서 단가가 깎일 염려도 없고, 작업을 완성하면 고객에게 큰 만족을 줄 수 있습니다. 만에 하나 실수가 있어도 어려운 업무를 했으니까 ‘그 정도 실수는 있을 수 있다’고 생각하고 심하게 질타하는 경우도 적습니다. 무엇보다도 일을 하는 보람을 통해 흥분을 맛볼 수 있으며 완수한다면 기술적으로나 정신적으로나 그만큼 성장할 수 있습니다 - 5장 중에서