소프트웨어 개발자는 말 그대로 소프트웨어를 만드는 사람을 뜻한다. 하나의 소프트웨어를 만든다는 것은 많은 역할과 작업 요소를 포함한다. 소프트웨어 개발에는 의미 있는 서비스를 발견하고 그 서비스를 사용하는 고객의 니즈를 파악해서 이를 제품으로 녹여낼 수 있는 능력이 요구된다. 결국 개발자의 가장 중요한 핵심 역량은 고객 서비스와 그 구현이라 할 수 있다. 하지만 많은 사람이 이 핵심 역량을 오해한다. 개발자에게 가장 중요하고 유일한 덕목은 ‘기술’이라고 믿는 데서 나오는 오해다. 개발자는 기술보다 올바른 가치관 정립을 우선으로 해야 한다. 개발자들이 만들어야 하는 것은 불편한데다가 못생긴 버튼 같은 쓸데없는 서비스가 아니라 사용자들이 하루에도 수십 번씩 누르고 싶은 매력적인 서비스이기 때문이다.
---p.12
우리나라에서 IT 개발로 진로를 정한 학생들은 대학 과정을 이수하는 동안 구체적으로 어떤 방향으로 나아가야 하는지에 대한 명확한 가이드도 없이, IT 쪽으로 분류된 중소기업이나 대기업에 입사하게 될 것이라고 막연히 생각하기 마련이다. 개발에 뜻을 품어도 이 길이 맞는가에 대한 고민은 항상 따라다닌다. 보통 대학교에서 배우는 수준이라 함은 무작정 C언어로 짜는 기초적인 몇 가지 프로그램, 큰 필요도 없는 포토샵, 자바를 필요로 할 수 있다는 교수들의 말에 왜 만드는지도 모르고 만드는 자바 프로그램 정도일 것이다. 산학협력이나 공공 프로젝트를 진행하는 현실에 밝은 교수들도 없지는 않으나, 급변하는 IT 시장의 눈높이를 제대로 꿰뚫는 교수들은 많지 않다. 당연한 일이다. 국내 IT 시장은 근 15년 사이 급변했고, 현업에 종사한 경험이 있다고 하더라도 교수들은 실무를 접해본 지 10년이 넘었을 가능성이 높기 때문이다. 나이가 젊은 편이라도 교수라는 직책에 어울리는 학문 연구에 전념하느라 실무를 깊숙이 접해볼 기회가 없었을 확률이 더 높다. 이처럼 대학에서 기업이 요구하는 수준의 개발자를 양성하는 데는 구조적으로 문제가 많기 때문에, 미래의 젊은 개발자들은 확실한 정보나 구체적인 가이드가 없이 사회로 나오게 된다.
---p.34
보통 업계에서 발주자가 수행 업체와 계약을 맺을 때는 턴키 계약(일괄수주계약) 방식을 선호한다. 계약관계에서 가장 중요한 요소는 프로젝트의 성패를 책임지는 주체이다. 일반적으로 ‘을’이 책임을 지고 프로젝트의 제반 사항을 관리하는 경우가 많은데 그런 경우 ‘을’ 업체를 턴키 업체라고 부른다. 하지만 기형적인 우리나라의 IT 시장에서는 ‘병’ 업체가 모든 책임의 소지를 지는 경우도 있다. 그때는 턴키 업체가 ‘병’이 되며 ‘을’ 업체는 큰 리스크 없이 프로젝트 수행 금액에서 영업이익만을 떼서 가져가고 ‘병’에게 나머지 금액을 넘기게 된다. 그럼에도 발주사인 ‘갑’이 굳이 없어도 되는 ‘을’ 업체를 끼는 이유는 관리상의 편의도 있지만 프로젝트가 위험해질 경우 프로젝트의 책임을 지는 업체 규모가 크지 않으면 발주 업체가 크게 손해를 볼 수도 있기 때문이다.
---p.78
IT 기술력이란 무협지 주인공의 내공과 비슷한 면이 있다. 자신의 무공을 숨기고 세상을 돌아다니는 재야의 고수는 겉으로 봤을 때 그냥 일반인과 다를 바가 없다. 하지만 강력한 적을 만나면 무공으로 제압하는데, 적은 주인공의 강력한 무공에 속절없이 무너지기 일쑤다. 주인공은 피를 흘리며 쓰러진 적을 내려다보며 이렇게 말한다. “천하를 호령한다는 너의 무공은 알고 보면 잡스럽고 요사스러운 눈속임에 불과하구나.” 위의 이야기는 사실 대단한 실력을 가졌던 무협광 개발자분이 하신 우스갯소리다. 그분의 말대로 개발이라는 분야는 무공과 닮아있다. 상대방의 코딩 한 줄만 봐도 대략적인 기술력의 높고 낮음이 보인다. 그런데 나보다 높은 기술력을 가진 개발자를 보면, 기술력이 높다는 건 알겠는데 얼마나 높은지는 가늠이 되지 않는다. 게다가 기술력이란 같은 경력, 같은 나이의 개발자라고 하더라도 그 차이가 하늘과 땅만큼 나기도 한다. 잘 연마된 특급 개발자 한 사람이 능히 초급 100명의 몫을 한다고 하면 믿겠는가? 또 난이도가 몹시 난해하고 어려운 과제가 존재할 경우 실력이 뛰어난 개발자가 팀에 없다면, 그 프로젝트를 수행하지 못하는 상황도 얼마든지 발생한다. 이렇게 프로젝트를 수행하는 개발자들은 수치화할 수 없는 노동력의 격차를 가지고 있다.
---p.110
우리나라의 순수한 청년들은 정말 열심히 일한다. 이렇게 비협조적인 조건에서도 어디가 어떻게 잘못되어 이렇게 힘든지 알지도 못한 채, 스크립트 한 줄도 체득한 적 없이 큰돈이 왔다 갔다 하는 은행 시스템의 깊숙한 부분의 버그를 열심히 디버깅한다. 자신의 실수로 수억 원의 돈이 잘못 이체될 수도 있는 금융 시스템을 만진다는 것부터가 심리적으로 큰 압박이었을 것이다. 또 소위 갑질로 대변되는 현업의 막말과 스트레스는 아무리 심지 굳은 사람이라도 견뎌내기가 쉽지 않다. 둘도 아닌 혼자서 이 업무와 스트레스를 감당하는 것 또한 말이 안 되는데 심지어 K는 사회초년생이다. 군대에서도 경험해보지 못한 막말이나 눈칫밥을 처음 경험해본 사람이라면 치를 떨 것이다. 근무 환경도 그다지 좋지 않았다. 작은 책상에 노트북 하나를 제공해주고 일거리를 던지면 도깨비방망이 마냥 뚝딱 결과가 나오길 기대하는 투였다. 보통 하청업체 직원의 근무환경을 살펴보면 부족한 자리를 이유로 좁고 작은 책상과 노트북 한 개를 내어주는 경우가 많다. 게다가 신입 개발자의 경우 제공받은 노트북 성능이 떨어지는 일도 종종 발생한다. 이런 환경에서 자신의 부족한 실력을 탓하며 밤 12시까지 근무를 하고 택시를 타고 퇴근하는 생활을 몇 달간 지속한다고 생각해보라. 개발자의 낮은 기술력을 핑계 삼아 온갖 열정 페이를 강요하는 현장이 이런 곳이다.
---p.134
IT 프로젝트의 규모는 M/M으로 계산되는 인건비가 사업비의 대부분이다. 인건비는 프로젝트 수행원에게 주어야 하는 금액인데 그렇다면 기업은 프로젝트 수익을 어떻게 남기는 것일까? 인건비의 삭감이 가장 쉬운 방법이다. 그렇다면 인건비를 높여서 프로젝트 규모도 키우고 수익도 남기면 되지 않냐고 생각할 수 있다. 하지만 앞서 살펴보았듯 우리나라에서는 소프트웨어 노임단가를 국가에서 발표하고 그것을 발주금액 표준으로 잡고 있다.
---p.138
재하청 구조의 악습을 조금 더 자세히 살펴보자. 이런 재하청 구조에서 가장 문제시되는 경우는 두 종류가 있다. 첫 번째는 정부의 대규모 프로젝트나 금융 프로젝트를 맡는 업체가 문제를 일으키는 경우다. 실제 수익성이 높은 프로젝트를 맡은 1차 수행 업체가 큰 자본력을 바탕으로 별 무리 없이 수주를 하고, 프로젝트에 큰 기여를 하지 않고도 전체 프로젝트 금액의 50%까지 가져가는 것이 현재 관행이다. 정부나 금융 기관 입장에서 프로젝트가 잘못되었을 경우 책임을 질만 한 큰 기업과 계약을 하는 것은 일견 당연해 보인다. 하지만 만약 프로젝트를 맡은 기업이 턴키로 재하청을 줄 경우에는 책임 소지 또한 재하청 업체에 넘기기 때문에 재하청 업체가 수익을 그에 상응해 가져가는 것이 마땅하다. 하지만 1차 수행업체가 M/M으로 정형화된 매우 낮은 수행 비용만을 재하청 수행비로 내려주는 중간마진 장사를 하고 있는 것이 실상이다.
---p.142
PM의 가장 큰 역할은 위험관리라고 했다. 각종 리스크에 대해서는 앞서 자세히 살펴본 바 있다. 그런 위험요소를 최대한 많이 알고, 각 대처 사항을 숙지하고 있다면 PM은 프로젝트를 수행할 때 안정적인 대처가 가능할 것이다. 프로젝트 도중 인원의 기술력에 문제가 있다고 판단되는 경우로 예를 들어 보자. 위험관리에 능한 PM은 1주일간 기술 테스트, 2주 차 실전 개발 퍼포먼스 테스트를 진행한 다음 개발자가 프로젝트를 진행하기에 부족하다는 판단이 들면 해당 개발자를 퇴출하는 미리 정립해둔 프로세스를 진행한다. PM이 미리 리스크를 대비해둔다면, 문제가 발생했을 때 이처럼 매뉴얼화된 대응을 할 수 있을 것이다.
---p.146
이런 학원 인력과 대학 4년제, 석사, 박사를 수료한 응용소프트웨어 개발자의 임금에 차별점이 없다는 것도 문제다. 개발자의 몸값이 단순히 초, 중, 고 등급으로 표기되고 일괄 단가로 지급되는 국내 특성상, 학원 수료 인력과 학사 이상의 수료자는 기본적으로 같은 등급이면 몸값이 같다. 이런 이유로 국내 응용 소프트웨어 석사, 박사는 찾아보기 힘들다. 날이 갈수록 시장에서 중요한 직종으로 평가받는 소프트웨어 기술자 중에 박사가 없다는 것은 우려스러운 일이 아닐 수 없다. 의사나 변호사를 양성하는 국비 지원 학원을 본 적이 있는가? 소프트웨어 개발자 역시 의사, 변호사 못지않게 수많은 공부를 해야 하는 전문성을 가진 직종이다. 학원의 존재 여부가 문제라는 말이 아니다. 사회적으로 고도화된 소프트웨어 시장으로 발전하려면 그에 맞는 고도화된 인력과 창의력 넘치는 열정적인 개발자를 길러내기 위한 고도의 교육 시스템이 필요하다는 말이다.
---p.151