15년 차 개발자가 말하는 ‘개발자로 살아남는 법’
이 시대의 IT 개발자를 위한 핵심 지침서

아침에 눈을 떠서 잠자리에 들기까지, 회사에서, 가정에서, 여행지에서, 장소와 시간을 불문하고 우리는 디지털 기술을 만난다. 우리의 일상 곳곳을 디지털 기술이 채우고 있다. 그 디지털 세상을 만들어가는 사람들, 일명 프로그래머, 개발자의 세계에 대해 우리는 얼마나 알고 있을까?
개발자와 IT 기술에 대한 관심은 날로 높아지고 있다. 많은 사람들이 개발자로 향하는 길을 눈여겨보고 있다. 그러나 개발자의 삶이 어떤지 제대로 아는 사람은 많지 않다. 개발자의 길에는 많은 난관이 따른다. 그러나 어떻게 하면 인정받는 개발자로 자리 잡을 수 있는지 누구도 제대로 알려주지 않는다.

개발자를 꿈꾸는 사람들은 지금 무엇을 배워야 하는가?
대학의 해당 학과를 졸업하면 과연 개발자로 성공할 수 있을까?
몇 개월만 학원에서 코딩을 배우면 취업이 된다는데, 사실일까?
개발자로 일하면 도대체 얼마나 벌 수 있을까?
같이 일하는 개발자들은 왜 말이 통하지 않는 걸까?
IT 강국으로 알려진 우리나라에서는 왜 슈퍼 개발자가 탄생하지 않는 걸까?

이 책은 개발자가 마주하는 의문과 어려움, 그에 대한 돌파구를 담고 있다. 나아가 개발 업계의 현주소와 문제점, 해결책도 제시한다. 내용을 찬찬히 따라가다 보면 의문에 대한 답을 찾을 수 있을 것이다. 15년 차 선배의 자세하면서도 때로 따끔한 조언은 독자들이 자신에게 맞는 길을 발견할 수 있도록 이끌어줄 것이다. 상상하는 모든 것을 현실로 만드는 행복한 직업. 그저 이상적인 표현만은 아니다. 

출판사 리뷰

어디서도 듣지 못한 이 시대의 진짜 개발자 이야기

인공지능과 과학 기술의 발전으로 미래에는 전반적인 직업 패러다임이 크게 변화할 것이다. 그러나 이러한 혼란 속에도 IT 개발자는 전망이 밝은 직업이라고 사람들은 말하곤 한다. 많은 이들이 IT 개발자를 꿈꾸고, 개발 업계에서 일하기를 원한다. 과연 사람들은 개발 업계의 현황과 IT 개발자의 실무에 대해 얼마나 알고 있을까?
IT 업계에 본격적으로 진출하기 전부터 많은 난관이 닥친다. 관련 학과에 들어가도 실무와는 동떨어진 공부만 하게 되는 경우도 상당하다. 개발자로 일을 시작하고는 또 어떠한가. 신입 개발자에게 교육을 실시하는 기업은 거의 없다. 대부분 곧바로 업무를 안겨주거나 프로젝트에 투입해버린다. 개발자는 몸으로 부딪치고 실수하고 바로잡으며 홀로 개발일을 익혀나가야 한다. 프로젝트로 묶인 인간관계도 복잡하기는 마찬가지다. PM, PL, 각 부서, 현업과 효과적으로 의사소통하는 법은 아무리 연구해도 어려운 부분이다. 또한 임금 문제도 만만치 않다. 프로젝트 단가는 고정되고 납기는 늘 최대한 짧게 잡으며, 하청에 재하청이 끊이지 않는 여러 악습이 개발자들의 숨통을 조이고 있는 실정이다.
이 책은 이와 같은 국내 IT 업계의 상황과 문제점을 면밀히 분석하여 알려준다. 저자는 이러한 상황에서도 좌절하거나 용기를 잃지 말라고 끊임없이 말한다. 어떤 해결책이 존재하는지, 어떤 방식으로 이러한 문제점을 헤쳐나갈 수 있는지 차근차근 언급하고 있다. 전문가가 제시하는 분명한 해결책과 따스한 조언을 따라가다 보면 슈퍼 개발자로 향하는 길이 보일 것이다.


능력 있는 개발자는 어떻게 만들어지는가

개발 업계에 던져진 개발자는 주어진 일을 처리하는 데도 부담을 느낄 수 있을 것이다. 일 잘하는 개발자, 성공한 개발자. 인정받는 개발자가 되고 싶은 마음은 누구에게나 있지만, 그 방법을 몰라서 답답할 것이다. 능력 있는 개발자가 되기 위해서는 자신의 성향에 맞는 직군을 결정해야 한다. 어느 분야에서 개발을 하고 싶은지 알기 위해서는 먼저 업계를 잘 아는 것이 중요하다. 국내 IT 업계에서 예산을 가장 많이 집행하는 대표적인 산업군은 어디인지, 그 이유는 무엇인지 파악하는 일이 필요하다. IT 업계별로 사용되는 언어를 파악하는 것도 진로를 정할 때 도움이 될 것이다. 어떤 분야의 기술을 습득하면 어떤 조직에서 어떤 일을 할 수 있는지를 살펴서 명확한 진로 계획을 세워야 한다.
소프트웨어 개발자가 프로젝트를 훌륭하게 진행하는 데 다섯 가지 기술이 필요하다고 저자는 말한다. 개발 기술력과 커뮤니케이션 능력, 리더십, 개방성, 잉여성이 그 기술이다. 여기서 저자가 강조하는 것이 ‘잉여력’이다, 크게 성공을 거둔 앱의 경우, 개발자의 ‘딴짓’에 의한 결과물인 경우가 많다는 것이다. 자신의 상상과 취미, 여가시간, 그리고 기술력이 결합하면 뜻하지 않은 작품이 탄생한다. 그래서 개발자는 ‘기술력’은 기본이고 ‘꿈’이 더 중요하다는 얘기다.
능력 있는 개발자가 되기 위해서는 많은 노력이 필요하다. 가만히 앉아서 주어진 개발일만 하는 것으로는 충분하지 않을 수 있다. 주위를 잘 살펴야 하고, 영리하고 효율적으로 일해야 하며, 자신에게 주어진 기회를 효과적으로 사용할 수 있어야 한다. 이 책에서 저자는 꿈을 가진 개발자들을 독려하며, 나아갈 길을 제시한다. 개발을 본업으로 삼기로 결심한 사람이라면, 저자가 제공하는 정보와 조언에서 큰 도움을 얻을 수 있을 것이다.


책 속에서

소프트웨어 개발자는 말 그대로 소프트웨어를 만드는 사람을 뜻한다. 하나의 소프트웨어를 만든다는 것은 많은 역할과 작업 요소를 포함한다. 소프트웨어 개발에는 의미 있는 서비스를 발견하고 그 서비스를 사용하는 고객의 니즈를 파악해서 이를 제품으로 녹여낼 수 있는 능력이 요구된다. 결국 개발자의 가장 중요한 핵심 역량은 고객 서비스와 그 구현이라 할 수 있다. 하지만 많은 사람이 이 핵심 역량을 오해한다. 개발자에게 가장 중요하고 유일한 덕목은 ‘기술’이라고 믿는 데서 나오는 오해다. 개발자는 기술보다 올바른 가치관 정립을 우선으로 해야 한다. 개발자들이 만들어야 하는 것은 불편한데다가 못생긴 버튼 같은 쓸데없는 서비스가 아니라 사용자들이 하루에도 수십 번씩 누르고 싶은 매력적인 서비스이기 때문이다. (12쪽)

우리나라에서 IT 개발로 진로를 정한 학생들은 대학 과정을 이수하는 동안 구체적으로 어떤 방향으로 나아가야 하는지에 대한 명확한 가이드도 없이, IT 쪽으로 분류된 중소기업이나 대기업에 입사하게 될 것이라고 막연히 생각하기 마련이다. 개발에 뜻을 품어도 이 길이 맞는가에 대한 고민은 항상 따라다닌다. 보통 대학교에서 배우는 수준이라 함은 무작정 C언어로 짜는 기초적인 몇 가지 프로그램, 큰 필요도 없는 포토샵, 자바를 필요로 할 수 있다는 교수들의 말에 왜 만드는지도 모르고 만드는 자바 프로그램 정도일 것이다. 산학협력이나 공공 프로젝트를 진행하는 현실에 밝은 교수들도 없지는 않으나, 급변하는 IT 시장의 눈높이를 제대로 꿰뚫는 교수들은 많지 않다. 당연한 일이다. 국내 IT 시장은 근 15년 사이 급변했고, 현업에 종사한 경험이 있다고 하더라도 교수들은 실무를 접해본 지 10년이 넘었을 가능성이 높기 때문이다. 나이가 젊은 편이라도 교수라는 직책에 어울리는 학문 연구에 전념하느라 실무를 깊숙이 접해볼 기회가 없었을 확률이 더 높다. 이처럼 대학에서 기업이 요구하는 수준의 개발자를 양성하는 데는 구조적으로 문제가 많기 때문에, 미래의 젊은 개발자들은 확실한 정보나 구체적인 가이드가 없이 사회로 나오게 된다. (34쪽)

보통 업계에서 발주자가 수행 업체와 계약을 맺을 때는 턴키 계약(일괄수주계약) 방식을 선호한다. 계약관계에서 가장 중요한 요소는 프로젝트의 성패를 책임지는 주체이다. 일반적으로 ‘을’이 책임을 지고 프로젝트의 제반 사항을 관리하는 경우가 많은데 그런 경우 ‘을’ 업체를 턴키 업체라고 부른다. 하지만
기형적인 우리나라의 IT 시장에서는 ‘병’ 업체가 모든 책임의 소지를 지는 경우도 있다. 그때는 턴키 업체가 ‘병’이 되며 ‘을’ 업체는 큰 리스크 없이 프로젝트 수행 금액에서 영업이익만을 떼서 가져가고 ‘병’에게 나머지 금액을 넘기게 된다. 그럼에도 발주사인 ‘갑’이 굳이 없어도 되는 ‘을’ 업체를 끼는 이유는 관리상의 편의도 있지만 프로젝트가 위험해질 경우 프로젝트의 책임을 지는 업체 규모가 크지 않으면 발주 업체가 크게 손해를 볼 수도 있기 때문이다. (78쪽)

IT 기술력이란 무협지 주인공의 내공과 비슷한 면이 있다. 자신의 무공을 숨기고 세상을 돌아다니는 재야의 고수는 겉으로 봤을 때 그냥 일반인과 다를 바가 없다. 하지만 강력한 적을 만나면 무공으로 제압하는데, 적은 주인공의 강력한 무공에 속절없이 무너지기 일쑤다. 주인공은 피를 흘리며 쓰러진 적을 내려다보며 이렇게 말한다. “천하를 호령한다는 너의 무공은 알고 보면 잡스럽고 요사스러운 눈속임에 불과하구나.” 위의 이야기는 사실 대단한 실력을 가졌던 무협광 개발자분이 하신 우스갯소리다. 그분의 말대로 개발이라는 분야는 무공과 닮아있다. 상대방의 코딩 한 줄만 봐도 대략적인 기술력의 높고 낮음이 보인다. 그런데 나보다 높은 기술력을 가진 개발자를 보면, 기술력이 높다는 건 알겠는데 얼마나 높은지는 가늠이 되지 않는다. 게다가 기술력이란 같은 경력, 같은 나이의 개발자라고 하더라도 그 차이가 하늘과 땅만큼 나기도 한다. 잘 연마된 특급 개발자 한 사람이 능히 초급 100명의 몫을 한다고 하면 믿겠는가? 또 난이도가 몹시 난해하고 어려운 과제가 존재할 경우 실력이 뛰어난 개발자가 팀에 없다면, 그 프로젝트를 수행하지 못하는 상황도 얼마든지 발생한다. 이렇게 프로젝트를 수행하는 개발자들은 수치화할 수 없는 노동력의 격차를 가지고 있다. (110쪽)

우리나라의 순수한 청년들은 정말 열심히 일한다. 이렇게 비협조적인 조건에서도 어디가 어떻게 잘못되어 이렇게 힘든지 알지도 못한 채, 스크립트 한 줄도 체득한 적 없이 큰돈이 왔다 갔다 하는 은행 시스템의 깊숙한 부분의 버그를 열심히 디버깅한다. 자신의 실수로 수억 원의 돈이 잘못 이체될 수도 있는 금융 시스템을 만진다는 것부터가 심리적으로 큰 압박이었을 것이다. 또 소위 갑질로 대변되는 현업의 막말과 스트레스는 아무리 심지 굳은 사람이라도 견뎌내기가 쉽지 않다. 둘도 아닌 혼자서 이 업무와 스트레스를 감당하는 것 또한 말이 안 되는데 심지어 K는 사회초년생이다. 군대에서도 경험해보지 못한 막말이나 눈칫밥을 처음 경험해본 사람이라면 치를 떨 것이다. 근무 환경도 그다지 좋지 않았다. 작은 책상에 노트북 하나를 제공해주고 일거리를 던지면 도깨비방망이 마냥 뚝딱 결과가 나오길 기대하는 투였다. 보통 하청업체 직원의 근무환경을 살펴보면 부족한 자리를 이유로 좁고 작은 책상과 노트북 한 개를 내어주는 경우가 많다. 게다가 신입 개발자의 경우 제공받은 노트북 성능이 떨어지는 일도 종종 발생한다. 이런 환경에서 자신의 부족한 실력을 탓하며 밤 12시까지 근무를 하고 택시를 타고 퇴근하는 생활을 몇 달간 지속한다고 생각해보라. 개발자의 낮은 기술력을 핑계 삼아 온갖 열정 페이를 강요하는 현장이 이런 곳이다. (134쪽)


IT 프로젝트의 규모는 M/M으로 계산되는 인건비가 사업비의 대부분이다. 인건비는 프로젝트 수행원에게 주어야 하는 금액인데 그렇다면 기업은 프로젝트 수익을 어떻게 남기는 것일까? 인건비의 삭감이 가장 쉬운 방법이다. 그렇다면 인건비를 높여서 프로젝트 규모도 키우고 수익도 남기면 되지 않냐고 생각할 수 있다. 하지만 앞서 살펴보았듯 우리나라에서는 소프트웨어 노임단가를 국가에서 발표하고 그것을 발주금액 표준으로 잡고 있다. (138쪽)

재하청 구조의 악습을 조금 더 자세히 살펴보자. 이런 재하청 구조에서 가장 문제시되는 경우는 두 종류가 있다. 첫 번째는 정부의 대규모 프로젝트나 금융 프로젝트를 맡는 업체가 문제를 일으키는 경우다. 실제 수익성이 높은 프로젝트를 맡은 1차 수행 업체가 큰 자본력을 바탕으로 별 무리 없이 수주를 하고, 프로젝트에 큰 기여를 하지 않고도 전체 프로젝트 금액의 50%까지 가져가는 것이 현재 관행이다. 정부나 금융 기관 입장에서 프로젝트가 잘못되었을 경우 책임을 질만 한 큰 기업과 계약을 하는 것은 일견 당연해 보인다. 하지만 만약 프로젝트를 맡은 기업이 턴키로 재하청을 줄 경우에는 책임 소지 또한 재하청 업체에 넘기기 때문에 재하청 업체가 수익을 그에 상응해 가져가는 것이 마땅하다. 하지만 1차 수행업체가 M/M으로 정형화된 매우 낮은 수행 비용만을 재하청 수행비로 내려주는 중간마진 장사를 하고 있는 것이 실상이다. (142쪽)

PM의 가장 큰 역할은 위험관리라고 했다. 각종 리스크에 대해서는 앞서 자세히 살펴본 바 있다. 그런 위험요소를 최대한 많이 알고, 각 대처 사항을 숙지하고 있다면 PM은 프로젝트를 수행할 때 안정적인
대처가 가능할 것이다. 프로젝트 도중 인원의 기술력에 문제가 있다고 판단되는 경우로 예를 들어 보자. 위험관리에 능한 PM은 1주일간 기술 테스트, 2주 차 실전 개발 퍼포먼스 테스트를 진행한 다음 개발자가 프로젝트를 진행하기에 부족하다는 판단이 들면 해당 개발자를 퇴출하는 미리 정립해둔 프로세스를 진행한다. PM이 미리 리스크를 대비해둔다면, 문제가 발생했을 때 이처럼 매뉴얼화된 대응을 할 수 있을 것이다. (146쪽)

이런 학원 인력과 대학 4년제, 석사, 박사를 수료한 응용소프트웨어 개발자의 임금에 차별점이 없다는 것도 문제다. 개발자의 몸값이 단순히 초·중·고 등급으로 표기되고 일괄 단가로 지급되는 국내 특성상, 학원 수료 인력과 학사 이상의 수료자는 기본적으로 같은 등급이면 몸값이 같다. 이런 이유로 국내 응용 소프트웨어 석사, 박사는 찾아보기 힘들다. 날이 갈수록 시장에서 중요한 직종으로 평가받는 소프트웨어 기술자 중에 박사가 없다는 것은 우려스러운 일이 아닐 수 없다. 의사나 변호사를 양성하는 국비 지원 학원을 본 적이 있는가? 소프트웨어 개발자 역시 의사, 변호사 못지않게 수많은 공부를 해야 하는 전문성을 가진 직종이다. 학원의 존재 여부가 문제라는 말이 아니다. 사회적으로 고도화된 소프트웨어 시장으로 발전하려면 그에 맞는 고도화된 인력과 창의력 넘치는 열정적인 개발자를 길러내기 위한 고도의 교육 시스템이 필요하다는 말이다. (151쪽)

소프트웨어 개발자는 말 그대로 소프트웨어를 만드는 사람을 뜻한다. 하나의 소프트웨어를 만든다는 것은 많은 역할과 작업 요소를 포함한다. 소프트웨어 개발에는 의미 있는 서비스를 발견하고 그 서비스를 사용하는 고객의 니즈를 파악해서 이를 제품으로 녹여낼 수 있는 능력이 요구된다. 결국 개발자의 가장 중요한 핵심 역량은 고객 서비스와 그 구현이라 할 수 있다. 하지만 많은 사람이 이 핵심 역량을 오해한다. 개발자에게 가장 중요하고 유일한 덕목은 ‘기술’이라고 믿는 데서 나오는 오해다. 개발자는 기술보다 올바른 가치관 정립을 우선으로 해야 한다. 개발자들이 만들어야 하는 것은 불편한데다가 못생긴 버튼 같은 쓸데없는 서비스가 아니라 사용자들이 하루에도 수십 번씩 누르고 싶은 매력적인 서비스이기 때문이다. (12쪽)

우리나라에서 IT 개발로 진로를 정한 학생들은 대학 과정을 이수하는 동안 구체적으로 어떤 방향으로 나아가야 하는지에 대한 명확한 가이드도 없이, IT 쪽으로 분류된 중소기업이나 대기업에 입사하게 될 것이라고 막연히 생각하기 마련이다. 개발에 뜻을 품어도 이 길이 맞는가에 대한 고민은 항상 따라다닌다. 보통 대학교에서 배우는 수준이라 함은 무작정 C언어로 짜는 기초적인 몇 가지 프로그램, 큰 필요도 없는 포토샵, 자바를 필요로 할 수 있다는 교수들의 말에 왜 만드는지도 모르고 만드는 자바 프로그램 정도일 것이다. 산학협력이나 공공 프로젝트를 진행하는 현실에 밝은 교수들도 없지는 않으나, 급변하는 IT 시장의 눈높이를 제대로 꿰뚫는 교수들은 많지 않다. 당연한 일이다. 국내 IT 시장은 근 15년 사이 급변했고, 현업에 종사한 경험이 있다고 하더라도 교수들은 실무를 접해본 지 10년이 넘었을 가능성이 높기 때문이다. 나이가 젊은 편이라도 교수라는 직책에 어울리는 학문 연구에 전념하느라 실무를 깊숙이 접해볼 기회가 없었을 확률이 더 높다. 이처럼 대학에서 기업이 요구하는 수준의 개발자를 양성하는 데는 구조적으로 문제가 많기 때문에, 미래의 젊은 개발자들은 확실한 정보나 구체적인 가이드가 없이 사회로 나오게 된다. (34쪽)

보통 업계에서 발주자가 수행 업체와 계약을 맺을 때는 턴키 계약(일괄수주계약) 방식을 선호한다. 계약관계에서 가장 중요한 요소는 프로젝트의 성패를 책임지는 주체이다. 일반적으로 ‘을’이 책임을 지고 프로젝트의 제반 사항을 관리하는 경우가 많은데 그런 경우 ‘을’ 업체를 턴키 업체라고 부른다. 하지만
기형적인 우리나라의 IT 시장에서는 ‘병’ 업체가 모든 책임의 소지를 지는 경우도 있다. 그때는 턴키 업체가 ‘병’이 되며 ‘을’ 업체는 큰 리스크 없이 프로젝트 수행 금액에서 영업이익만을 떼서 가져가고 ‘병’에게 나머지 금액을 넘기게 된다. 그럼에도 발주사인 ‘갑’이 굳이 없어도 되는 ‘을’ 업체를 끼는 이유는 관리상의 편의도 있지만 프로젝트가 위험해질 경우 프로젝트의 책임을 지는 업체 규모가 크지 않으면 발주 업체가 크게 손해를 볼 수도 있기 때문이다. (78쪽)

IT 기술력이란 무협지 주인공의 내공과 비슷한 면이 있다. 자신의 무공을 숨기고 세상을 돌아다니는 재야의 고수는 겉으로 봤을 때 그냥 일반인과 다를 바가 없다. 하지만 강력한 적을 만나면 무공으로 제압하는데, 적은 주인공의 강력한 무공에 속절없이 무너지기 일쑤다. 주인공은 피를 흘리며 쓰러진 적을 내려다보며 이렇게 말한다. “천하를 호령한다는 너의 무공은 알고 보면 잡스럽고 요사스러운 눈속임에 불과하구나.” 위의 이야기는 사실 대단한 실력을 가졌던 무협광 개발자분이 하신 우스갯소리다. 그분의 말대로 개발이라는 분야는 무공과 닮아있다. 상대방의 코딩 한 줄만 봐도 대략적인 기술력의 높고 낮음이 보인다. 그런데 나보다 높은 기술력을 가진 개발자를 보면, 기술력이 높다는 건 알겠는데 얼마나 높은지는 가늠이 되지 않는다. 게다가 기술력이란 같은 경력, 같은 나이의 개발자라고 하더라도 그 차이가 하늘과 땅만큼 나기도 한다. 잘 연마된 특급 개발자 한 사람이 능히 초급 100명의 몫을 한다고 하면 믿겠는가? 또 난이도가 몹시 난해하고 어려운 과제가 존재할 경우 실력이 뛰어난 개발자가 팀에 없다면, 그 프로젝트를 수행하지 못하는 상황도 얼마든지 발생한다. 이렇게 프로젝트를 수행하는 개발자들은 수치화할 수 없는 노동력의 격차를 가지고 있다. (110쪽)

우리나라의 순수한 청년들은 정말 열심히 일한다. 이렇게 비협조적인 조건에서도 어디가 어떻게 잘못되어 이렇게 힘든지 알지도 못한 채, 스크립트 한 줄도 체득한 적 없이 큰돈이 왔다 갔다 하는 은행 시스템의 깊숙한 부분의 버그를 열심히 디버깅한다. 자신의 실수로 수억 원의 돈이 잘못 이체될 수도 있는 금융 시스템을 만진다는 것부터가 심리적으로 큰 압박이었을 것이다. 또 소위 갑질로 대변되는 현업의 막말과 스트레스는 아무리 심지 굳은 사람이라도 견뎌내기가 쉽지 않다. 둘도 아닌 혼자서 이 업무와 스트레스를 감당하는 것 또한 말이 안 되는데 심지어 K는 사회초년생이다. 군대에서도 경험해보지 못한 막말이나 눈칫밥을 처음 경험해본 사람이라면 치를 떨 것이다. 근무 환경도 그다지 좋지 않았다. 작은 책상에 노트북 하나를 제공해주고 일거리를 던지면 도깨비방망이 마냥 뚝딱 결과가 나오길 기대하는 투였다. 보통 하청업체 직원의 근무환경을 살펴보면 부족한 자리를 이유로 좁고 작은 책상과 노트북 한 개를 내어주는 경우가 많다. 게다가 신입 개발자의 경우 제공받은 노트북 성능이 떨어지는 일도 종종 발생한다. 이런 환경에서 자신의 부족한 실력을 탓하며 밤 12시까지 근무를 하고 택시를 타고 퇴근하는 생활을 몇 달간 지속한다고 생각해보라. 개발자의 낮은 기술력을 핑계 삼아 온갖 열정 페이를 강요하는 현장이 이런 곳이다. (134쪽)


IT 프로젝트의 규모는 M/M으로 계산되는 인건비가 사업비의 대부분이다. 인건비는 프로젝트 수행원에게 주어야 하는 금액인데 그렇다면 기업은 프로젝트 수익을 어떻게 남기는 것일까? 인건비의 삭감이 가장 쉬운 방법이다. 그렇다면 인건비를 높여서 프로젝트 규모도 키우고 수익도 남기면 되지 않냐고 생각할 수 있다. 하지만 앞서 살펴보았듯 우리나라에서는 소프트웨어 노임단가를 국가에서 발표하고 그것을 발주금액 표준으로 잡고 있다. (138쪽)

재하청 구조의 악습을 조금 더 자세히 살펴보자. 이런 재하청 구조에서 가장 문제시되는 경우는 두 종류가 있다. 첫 번째는 정부의 대규모 프로젝트나 금융 프로젝트를 맡는 업체가 문제를 일으키는 경우다. 실제 수익성이 높은 프로젝트를 맡은 1차 수행 업체가 큰 자본력을 바탕으로 별 무리 없이 수주를 하고, 프로젝트에 큰 기여를 하지 않고도 전체 프로젝트 금액의 50%까지 가져가는 것이 현재 관행이다. 정부나 금융 기관 입장에서 프로젝트가 잘못되었을 경우 책임을 질만 한 큰 기업과 계약을 하는 것은 일견 당연해 보인다. 하지만 만약 프로젝트를 맡은 기업이 턴키로 재하청을 줄 경우에는 책임 소지 또한 재하청 업체에 넘기기 때문에 재하청 업체가 수익을 그에 상응해 가져가는 것이 마땅하다. 하지만 1차 수행업체가 M/M으로 정형화된 매우 낮은 수행 비용만을 재하청 수행비로 내려주는 중간마진 장사를 하고 있는 것이 실상이다. (142쪽)

PM의 가장 큰 역할은 위험관리라고 했다. 각종 리스크에 대해서는 앞서 자세히 살펴본 바 있다. 그런 위험요소를 최대한 많이 알고, 각 대처 사항을 숙지하고 있다면 PM은 프로젝트를 수행할 때 안정적인
대처가 가능할 것이다. 프로젝트 도중 인원의 기술력에 문제가 있다고 판단되는 경우로 예를 들어 보자. 위험관리에 능한 PM은 1주일간 기술 테스트, 2주 차 실전 개발 퍼포먼스 테스트를 진행한 다음 개발자가 프로젝트를 진행하기에 부족하다는 판단이 들면 해당 개발자를 퇴출하는 미리 정립해둔 프로세스를 진행한다. PM이 미리 리스크를 대비해둔다면, 문제가 발생했을 때 이처럼 매뉴얼화된 대응을 할 수 있을 것이다. (146쪽)

이런 학원 인력과 대학 4년제, 석사, 박사를 수료한 응용소프트웨어 개발자의 임금에 차별점이 없다는 것도 문제다. 개발자의 몸값이 단순히 초・중・고 등급으로 표기되고 일괄 단가로 지급되는 국내 특성상, 학원 수료 인력과 학사 이상의 수료자는 기본적으로 같은 등급이면 몸값이 같다. 이런 이유로 국내 응용 소프트웨어 석사, 박사는 찾아보기 힘들다. 날이 갈수록 시장에서 중요한 직종으로 평가받는 소프트웨어 기술자 중에 박사가 없다는 것은 우려스러운 일이 아닐 수 없다. 의사나 변호사를 양성하는 국비 지원 학원을 본 적이 있는가? 소프트웨어 개발자 역시 의사, 변호사 못지않게 수많은 공부를 해야 하는 전문성을 가진 직종이다. 학원의 존재 여부가 문제라는 말이 아니다. 사회적으로 고도화된 소프트웨어 시장으로 발전하려면 그에 맞는 고도화된 인력과 창의력 넘치는 열정적인 개발자를 길러내기 위한 고도의 교육 시스템이 필요하다는 말이다. (151쪽)

저자의 말

프롤로그

Part 1 … 입문편

1. 개발자로 살아남기
- 프로젝트의 성공이란
- “대학에서 배운 것은 다 쓸모없어”
- ‘기술’보다 더 중요한 것은 ‘꿈’
- 개발자의 성장 그래프
- 한 발짝 더 나아가기 위한 다섯 가지 기술
- 시간 쪼개기

2. 프로젝트의 이해
- 별에서 온 IT
- 프로젝트에 따른 기술 정체성
- IT 프로젝트의 시작과 끝
- 프로젝트 위험관리
- 프로젝트의 리스크

3. 프로그래밍 작업의 가치
- SW 개발자 노임단가
- 프리랜서로 활동하기
- 창업에 도전하기

4. IT 업계의 사회병리학
- 신입 직원을 죽음으로 내몬 하청문화
- 산업발전을 저해하는 가장 큰 악습
- 프로젝트의 꽃, PM 양성 교육의 부재
- 유지보수 프로세스 정립
- 개발자 양성의 국비 지원 문제점
- 포괄임금제 폐지

Part 2 … 심화편

5. IT 시장의 현황 및 자본 흐름
- IT 업계의 자본 흐름
- 게임업계에서 빠질 수 없는 언어 C++

6. 다양한 IT 기술직군
- 나의 성향에 맞는 직군 고르기
- 사례 1 : 게임 개발
- 사례 2 : 웹 개발
- 사례 3 : 하드웨어 제품 개발

7. 내 손으로 구현하는 상상 속의 기술
- 가장 각력한 구현 도구, HTTP 웹 서비스
- 실시간 인터랙션을 위한 유일한 대안, TCP-IP 소켓 통신
- 하이브리드 앱
- 융합하면 가능성이 열린다
- 날아라, 드론
- 개발자라면 인공지능과 친해질 것
- 물건이 점점 똑똑해진다
- 빅데이터가 주도하는 세상
- 개발자는 상상을 현실로 만든다

에필로그