대한민국 개발자 희망보고서
오병곤 지음 | 한빛미디어
대한민국 개발자 희망보고서
오병곤 지음
한빛미디어 / 2007년 2월 / 408쪽 / 16,000원
불타는 갑판
월화수목금금금'월화수목금금금'은 주말에도 평일처럼 열심히 일한다는 뜻으로 일주일 내내 일해야 하는 서글픈 현실을 빗대어 표현하는 말이다. 이 말은 원래 제조업 쪽에서 생겨난 말이지만, 비단 이런 현상은 제조업뿐만 아니라 소프트웨어 개발 현실에서도 크게 다르지는 않다. A사의 물류 시스템 개발 프로젝트를 하던 때였다. 당시 시스템 오픈이 얼마 남지 않아 프로젝트 팀원들은 계속되는 초과근무로 인해 심신이 지쳐 있었다. 내 아내는 첫 아이의 출산을 앞두고 있었는데 그런 아내에게조차 마음을 쓰지 못해 미안했다. 새해 첫 날 밤 아내가 출산했을 때도 밤늦게까지 일을 해야만 했다. 나는 아이의 아빠가 된다는 기쁨을 누릴 새도 없이 프로젝트에 전념해야만 하는 현실에 비애와 함께 분노를 느꼈다. 또 얼마 전 아주 성실한 직원 하나가 프로젝트를 진행하던 중에 퇴사를 했다. 개발자의 길을 천직처럼 여겼던 그가 갑자기 퇴사를 결정한 이유는 의외로 간단했다. 노총각인 그는 어렵게 만난 애인과 결혼하고 싶어했지만 알콩달콩 데이트할 시간이 없어서 애인과의 관계가 소원해진 것이다. 그는 적잖은 고민을 했고 급기야 다른 일을 해야겠다고 결심했던 것이다. 물론 우리 주위에는 불철주야 자발적으로 열심히 일하는 경우도 많다. 그러나 동기야 어찌 되었든 간에 기계가 아닌 이상 휴식은 필요하다. 또한 우리는 일 이외에도 가족, 친구, 애인, 자기계발, 취미 등에 충분한 관심을 가져주어야 한다. 일과 일 이외의 것에서 양자택일하는 방식으로 살아가는 것은 바람직하지 못한 행동이다.
그렇다면 초과근무를 가능한 줄이면서도 동시에 생산성을 높일 수 있는 방법은 무엇이 있을까? 이 물음에 대한 대답은 일에 대한 인식의 전환을 수반한다. 첫째, 이제는 열심히 일하기(Work Hard)에서 현명하게 일하기(Work Smart)로 변화하고 있다. 특히 소프트웨어 개발과 같은 지적 노동의 경우에는 일의 질과 시간이 비례하지 않는다. 둘째, 직원들이 일을 통해 성취감을 느끼고 일 자체를 즐길 수 있도록 다양한 방법들이 모색되어야 한다. 일에 대한 생산성을 획기적으로 높일 수 있는 유일한 방법은 동기부여라는 것을 명심해야 한다. 직원들의 강점과 연결된 직무를 배치하고, 다양한 경로를 통해 성장할 수 있는 경력개발이 보장되고, 성과위주로 평가 보상하는 등의 제도가 실행되어야 한다. 셋째, 일에 대한 재충전의 시간이 반드시 필요하다. 아무리 바쁘고 힘들어도 자신을 천천히 되돌아 볼 시간을 갖고 주기적인 휴식을 취해야만, 신선한 아이디어와 창의성을 재충전하고 일의 가속도를 높일 수 있다. '월화수목금금금'의 방식보다는 직원들의 창의성과 협력을 최대한 북돋우면서 성장하는 그런 회사를 꿈꿔 본다.
레드 오션(Red Ocean)우리나라 IT 서비스 시장은 크게 대기업의 그룹 계열사를 대상으로 하는 시장(Captive Market), 공공 시장, 기타 시장 등 크게 3가지로 구분되는데 그중에서 계열사 시장의 점유율이 가장 크다. 계열사 시장은 경쟁이 극히 제한되어 있어 서비스 제공사는 안정적으로 높은 수익을 보장받고 있으나, 계열사 시장 너머에 있는 대외 IT 서비스 시장은 한마디로 출혈경쟁이 난무하는 레드오션(Red Ocean)이다. 매출 수백억 원대의 포털업체 영업이익이 매출 1조 원을 상회하는 굴지의 대기업 IT 서비스 업체의 영업이익보다 많은 것이 현실이다. 그렇다면 왜 IT 서비스 산업은 저부가가치의 사업으로 진행되는 것일까? 업체간의 과당 경쟁과 저가 입찰이 주범이다. 업체간의 치열한 생존 경쟁은 단돈 '1원 입찰'이라는 웃지 못 할 해프닝을 종종 보여주곤 했다. 실제 예정가격보다 훨씬 낮은 가격으로 입찰이 결정되는 관행은 업계의 고질적인 병폐다. 보통 수행 예정 가격의 70~80%로 입찰에 참여하며, 우선협상자로 선정된 이후에도 재협상을 통해 입찰 가격의 70~80%로 최종 가격이 결정되는 것이 일반적인 일로 알려져 있다. 그렇다 보니 이익을 보전하기 어렵게 되고 자사인력보다 외주인력을 더 많이 활용하여 손익을 충당하려 하고 자연생태계의 먹이사슬과 비슷하게 하청, 재하청의 복잡한 하도급 구조로 진행된다. 이렇다 보니 외주업체는 영세성을 면하기 어렵고, '월화수목금금금'의 무리한 야근에 의해 프로젝트가 수행될 수밖에 없다. 뿌린 대로 거둔다. 개발자로서의 자부심과 만족도는 땅으로 떨어지고 고품질은 전혀 기대할 수 없다. 이는 결국 경쟁력 약화로 이어진다. 단언컨대, 지금 IT 서비스 업계의 원죄는 바로 저가수주다.
이제는 IT 서비스 산업의 경쟁력을 확보한다는 기본 원칙에서 출발하여 다양한 방안이 마련되어야 한다. 제일 먼저 IT 업체의 수익성을 제고할 수 있도록 산업구조를 구축하고 법과 제도를 정비하는 방안이 제시되어야 한다. IT 서비스 업체도 시스템 구축이라는 일회성 사업에만 초점을 두는 근시안적 형태에서 벗어나 선제안에서 컨설팅, 구축, 운영에 이르기까지 제반 IT 서비스를 제공하는 'Full IT 서비스'를 통해 평생고객을 확보하는 전략을 다각적으로 모색해야 한다.
동굴의 우상
실패하는 프로젝트의 7가지 습관실패하는 프로젝트는 다음의 7가지 특징을 갖고 있다. 첫째, 사람이 무시된다. 도구와 기술, 프로세스보다 사람이 더 중요하다고 말하면서도 정작 사람은 뒷전으로 밀려난다. 심지어는 사람을 자동차의 부속품처럼 취급하기도 한다. 둘째, 추정이 모호하고 비현실적이다. 잘못된 소프트웨어 규모 산정의 원인은 두 가지로 구분해 볼 수 있다. 하나는 산정 시점이 소프트웨어 개발 생명주기(Software Development Life Cycle)의 초기 시점에 이루어진다는 점이다. 즉, 무엇을 개발할 것인가에 대한 명확한 정의가 없이 일정과 비용을 결정해야 하는 황당한 현실에 서 있는 것이다. 규모 산정 오류의 두 번째 원인은 산정하는 사람 때문이다. 발주자의 무리한 요구에 대해 수주자의 입장에서는 도저히 일정과 비용에 맞출 수 없음에도 불구하고 영업 실적과 전략적 수주라는 논리에 밀려, 울며 겨자 먹기 식으로 프로젝트를 수행할 수밖에 없고 프로젝트는 처음부터 위험을 안고 시작된다. 셋째, 요구사항이 불안정하다. 요구사항은 해결해야 할 문제를 정의한 명세이다. 프로젝트가 진행될수록 요구사항이 요동을 친다면 정해진 기한 내에 프로젝트를 끝내기는 거의 불가능에 가깝다.
넷째, 계획 수립이 엉성하다. 소프트웨어 프로젝트는 일의 80% 이상이 지적인 작업이 요구되는 복잡한 작업이다. 그런데도 계획을 대충 세운다면 프로젝트가 제대로 진행될 리가 없다. 계획은 합리적이면서도 구체적으로 세워야 한다. 프로젝트의 개발 범위와 투입 자원, 그리고 일정에 대해 세부적으로 실현 가능하게 수립해야 한다. 엉성하게 세운 계획은 아무런 결과도 가져오지 못한다. 다섯째, 프로젝트 진행 상황을 파악하지 못한다. 프로젝트가 제대로 진행되고 있는지 정기적으로 추적하고 모니터링 하는 활동이 없다. 프로젝트 진행 상황이 제대로 파악되지 않는 프로젝트의 대부분은 시스템 오픈이 임박해서야 심각한 문제가 도출된다. 적절히 통제할 수 있어야 프로젝트가 폭주하지 않고 내 의지대로 움직일 수 있다. 여섯째, 위험을 관리하는 활동이 없다. 소프트웨어 프로젝트는 본질적으로 위험하다. 따라서 위험 요소를 식별하고 적절한 예방 활동을 취하는 활동이 없다면 지금 발생한 문제에만 매달리게 된다. 일곱째, 품질보증 활동이 미흡하다. 프로젝트 전 기간 동안 품질보증 활동이 전혀 없거나 테스트에 집중된다. 안타깝게도 납기 준수라는 지상 명제를 달성하기 위해 품질을 높이는(또는 결함을 줄이는) 활동이 기꺼이 희생되는 사례를 많이 보게 된다. 간혹 고객을 속일 수는 있지만 이는 스스로 무덤을 파는 결과를 낳게 된다. 요즘 고객은 영리하다. 또한 품질의 개념도 제품의 무결점에서 고객의 요구사항과 가치 충족이라는 방향으로 변화하고 있다.
개발 생산성 혁신
요구사항을 개발하라소프트웨어 시스템을 구축하는 데 있어서 가장 어려운 부분 중의 하나는 무엇을 구축할 것인지를 고객으로부터 정확하게 도출하는 것이다. 즉, 요구사항을 정확히 발견하여 구현해야 고객이 당명한 문제점을 해결하고 비즈니스 목적을 달성할 수 있는 것이다. 그럼에도 불구하고 보통 인터뷰 등을 통해 고객이 공식적으로 요구한 사항만 제품 개발에 반영하는 경향이 강하다. 요구사항은 고객이 요구한 사항만을 의미하는 것이 아니다. 요구사항은 고객이 베푸는 시혜가 아니라 정 끝으로 원석을 쪼아서 보석을 캐내는 작업이다. 수동적으로 주어지는 것이 아니라 능동적으로 개발해야 하는 것이다. 프로그램만 개발하는 것이 아니라 고객의 요구사항도 개발해야 한다(Requirements Development).
요구사항 개발에서 주의해야 할 일은 첫째, 요구사항이 빠지지 않고 정의되어야 한다는 점이다. 누락이란 개발 범위에서 제외된다는 뜻이며, 평상시에는 수면 속에 조용히 가라앉아 있다가 프로젝트 후반부에 수면 위로 떠오르는 경우가 많다. 특히 업무 기능적인 요구사항 이외의 품질특성, 인터페이스, 데이터 전환, 제약조건, 비즈니스 규칙 등 비기능 요구사항에 대한 누락은 빈번하게 발생한다. 불충분하고 누락된 요구사항은 영화세트를 만들 듯이 미리 사전에 시연(프로토타입)을 만들거나 요구사항을 테스트하는 케이스를 만들어 보는 방법 등 다양한 요구사항 개발 활동을 통해서 정리해 나가야 한다. 둘째, 요구사항의 명확한 합의 도출을 위해서 요구사항을 제시하고 결정하는 사용자 계층을 정확히 파악해야 한다. 셋째, 요구사항은 고객이 명시하지 않더라도 고객이 기대하는 것, 원하는 것, 필요한 것을 포함해야 한다. 고객 참여가 불충분한 프로젝트는 뒤늦은 요구사항 추가로 프로젝트 완료를 지연시킨다. 프로젝트의 모든 단계에 걸쳐 고객과 프로젝트 팀의 직접적인 협력보다 더 좋은 성공요인은 없다. 넷째, 고객의 요구사항이 애매하고 복잡하다면 눈으로 보여주는 활동을 통해 이해시켜야 한다. 이미 업계에서 관행처럼 사용하고 있는 프로토타입, Use Case, ERD 작성은 물론이고, 고객과 프로젝트 팀을 이해시킬 수 있는 모든 비주얼한 수단을 강구해야 한다. 다섯째, 수집된 요구사항에 대해 우선순위를 부여하라. 그리고 우선순위를 염두에 두고 일을 추진하라. 여섯째, 요구사항 검토 및 승인활동을 반드시 실시하라. 프로젝트 초기부터 고객 승인 활동을 실시해야 프로젝트를 진행하는 모든 기간 동안 원활히 이루어질 수 있다.
지금은 스타일 시대흔히 소프트웨어 개발 과정에서 UI(User Interface)는 단순히 디자이너가 예쁜 화면을 만드는 '화장빨'에 불과하다는 생각을 하곤 한다. 그러나 UI는 단순한 화면 디자인 차원을 넘어선다. 사용자와 컴퓨터와의 정보채널, 상호작용(Human-Computer Interface)이며, 역사상 그 어느 시기보다 현재 중요하게 인식되고 있다. 그 이유는 '고객(또는 사용자)'과 '스타일'이라는 두 가지의 중요한 키워드 때문이다. 마케팅 전문가 세스 고딘의 말처럼 '디자인이 세상을 지배하는' 트렌드가 형성되고 있다. 이는 하루에도 수많은 제품이 쏟아져 나오지만 주목할 만(remarkable)하지 않으면 바로 사장되는 현실에 기초한다. 여기서 주목할 만한 것의 핵심은 바로 디자인이다. IT 측면에서도 개발 환경이 클라이언트/서버에서 웹으로 이동하면서 메시지 전달 방식이 단순 텍스트에서 그래픽으로 변화되고 있다. 또한 시스템의 대형화와 신기술의 출현으로 시스템 개발이 개발자가 전체를 관장하는 방식이 아니라 비즈니스 설계자, 품질 관리자, 디자이너, 테스터 등 여러 개의 역할로 세분화되는 추세도 독립적인 UI 설계의 필연성을 내포하고 있다. 이제 기능은 보편적이자, 기본이고 스타일은 우월과 매력인 시대가 되었다. 좋은 디자인은 기능을 뛰어 넘어 사람과 컴퓨터의 상호작용을 우선시하는 디자인이다. UI는 개발 과정에서 또 하나 주어진 귀찮은 과업이 아닌 U(You)와 I를 잇는 가교이며 커뮤니케이션이다.
연금술
프로그래머와 글쓰기글쓰기가 경쟁력인 시대가 되었다. 그러한 분위기 속에서 기술분야에서 일하는 사람들의 글쓰기 수준이 형편없다는 이야기가 심심찮게 들린다. 이공계 출신은 글쓰기 능력이 떨어져 커뮤니케이션 능력이 부족하기 때문에 푸대접을 받는다는 주장도 나온다. 왜 이런 현상이 발생하는가? 문과, 이과를 나누는 잘못된 풍토도 한몫을 한다. 그렇지만 가장 근본적인 이유는 글쓰기를 제대로 배운 적이 없기 때문이다. 그러다 보니 당연히 문서작업에 대한 거부감이 생긴다. 계산과 공식은 익숙하지만 표현에는 서툴다. 글쓰기를 배워야 하는 이유는 단순하다. 어떤 분야의 전문가가 되고자 한다면 글쓰기는 전문가의 필수 조건이기 때문이다. 전문가는 커뮤니케이션 능력이 있어야 한다. 어떤 분야의 전문가라면 비전문가에게도 알아들을 수 있도록 간단하고 명쾌하게 말할 수 있어야 한다. 둘째, 기록은 기억보다 강하기 때문이다. 중국 속담에 아무리 흐린 먹물이라도 가장 훌륭한 기억력보다 낫다는 말이 있다. 기록을 하지 않으면 유실된다. 보고 배운 것을 글로써 정리해야 온전히 내 것으로 만들 수 있다. 셋째, 업무의 절반이 글쓰기와 관련이 있는 까닭이다. 아침에 출근해서 제일 먼저 이메일에 대한 답변으로 일을 시작한다. 회의결과를 정리하고, 보고서를 만들고, 프로젝트 산출물을 작성한다.
기술분야에 종사하고 있는 사람들이 써야 하는 글의 대부분은 실용적인 글이다. 테크니컬 라이팅(Technical Writing)이다. 기술적, 사무적인 글은 약도 그리듯이 쉽게 접근해야 한다. '핵심을 쉽고 간결하게' 전달하는 실용문을 작성해야 한다. 먼저 문서작업에 대한 알레르기 의식을 버려야 한다. 문서화 작업을 소프트웨어 개발의 일부로 여기는 인식의 변화가 필요하다. 대부분 프로그래밍에 얼마나 많은 시간을 쏟는지를 중요하게 생각하는데 문서와 코드는 동전의 앞뒷면이다. 같은 대상에 대한 서로 다른 뷰일 뿐이다. 한국어도 하나의 프로그래밍 언어로 바라보기를 바란다. 그 다음 당신이 경험했던 프로젝트에서 얻었던 교훈, 새로운 개발 기법, 테스트 기법, 품질 향상 기법 등을 글로 써보기바란다. 글은 누구나 쓸 수 있는 것이다. 당신의 용기가 소프트웨어 업계의 발전을 앞당긴다는 사실을 잊지 말기를 바란다. 늘 기록하라. 프로젝트를 하면서 나만의 테크 노트를 써라. 반드시 알아야 할 팁이나 시행착오를 겪으면서 얻게 된 노하우 등을 노트에 정리해 놓으면 매우 유용하게 사용할 수 있다. 왜냐하면 사람은 대부분 같은 실수를 반복하는 경향이 있는데 이럴 때 적절하게 대처할 수 있기 때문이다. 블로그나 홈페이지에 프로젝트 일지를 기록하는 것도 좋다. 글쓰기는 타고나는 것이 아니다. 훈련이다. 멈추지 말고 뼛속까지 내려가서 써라.
프로세스 혁신
프로젝트의 원죄, 추정나비효과는 중국 북경에 있는 나비의 날갯짓이 다음 달 미국 뉴욕에서 폭풍을 발생시킬 수도 있다는 과학이론이다. 흔히 '초기 조건에의 민감한 의존성'으로 표현되는데 초기의 작은 변화가 결과적으로 엄청난 변화를 초래할 수 있는 경우를 지칭하는 말이다. 프로젝트 초기에 프로젝트 규모와 비용, 기간, 자원 등이 얼마나 걸릴 것인지를 추정(Estimation)하는 작업은 나비효과와 비슷하다. 잘못 추정된 작업 하나가 프로젝트 후반의 대규모 작업을 유발할 수 있다. 프로젝트 초기, 기능 하나의 불확실성