2019년 5월 26일 일요일

국제화 #1 - 유럽 개인정보보호법(GDPR)과 글로벌 소프트웨어


GDPR(General Data Protection Regulation)은 EU가 제정한 현존하는 가장 강력한 개인정보보호법이다. 2016년 5월부터 2년간의 유예를 거쳐 2018년 5월25일 발효되었다. 발효 즉시 몇 시간 지나지 않아 페이스북과 구글이 소송을 당했다. GDPR의 벌금액은 상상을 초월한다. 가벼운 위반 사항은 1000만 유로(125억)나 회사매출의 2%, 무거운 위반사항은 2000만유로(250억)나 회사매출의 4%중 큰 금액이 최대 벌금액일만큼 심각한 법이다. 지금까지는 적당히 개인 정보에 대한 법을 무시해 왔다면 지금부터는 장난이 아니다.

지금까지 대부분의 소프트웨어 회사들이 도덕적 해이로 혹은 기술상의 어려움으로 개인정보보호에 소홀히 해온 것이 사실이다. 그래서 개인 정보 DB가 해킹도 당하고 범죄자들에게 이용당하기도 했다. GDPR과 같은 강력한 법령은 당연히 장단점이 있기 마련이다. 불편성과 안전성의 트레이드오프이다. 근래에 웹에 접속할 때 매번 Cache 규정에 대한 응답을 하도록 귀찮게 구는 것이 바로 GDPR의 영향 때문이다. 사용자에게도 불편을 초래하지만 소프트웨어 개발사에게는 엄청난 부담이 된다.

이름이나 전화번호와 같은 개인정보는 물론이고 심지어는 서버에 개인 패스워드까지도 보관했던 과거도 있었다. 잊어버린 패스워드를 이메일로 보내주는 코미디 같은 시절도 오래 전의 얘기가 아니다. 그래서 필자는 조금이라도 위험성이 있거나 엉성한 사이트에는 모든 사람이 알아도 무방한 패스워드를 사용하거나 아예 회원 등록을 하지 않는다. 혹시 암호화 기술을 모르는 독자들을 위해 간단하게 설명하자면 로그인 패스워드는 해시(hash)라는 기술로 원복 불가능한 암호화 방식으로 저장하며 사용자가 입력한 패스워드와 값이 일치하는 지만 확인하여 접속을 허용한다. 이런 방식에서 DB에 패스워드가 직접 저장되지는 않지만 당연히 프로그래머라면 그 과정에서 아주 쉽게 한두 줄의 코딩으로 얼마든지 패스워드를 훔쳐낼 수가 있다. 그래서 필자의 패스워드는 몇 가지 등급으로 나누어 훔쳐가도 무방한 패스워드를 사용하는 사이트도 많다. 특히 중국의 사이트에서 그렇게 한다. 구글과 같은 글로벌 업체들의 경우 적어도 프로그래머가 장난을 치지는 않을 것이라는 믿음을 가지고 사용하는 수 밖에 없다.

가장 중요한 로그인 패스워드마저도 이런 기술의 무지나 의도적인 해킹에 노출되어 있는데 일반적인 개인 정보는 더욱 위험할 수 밖에 없다. 인터넷에 수집되는 정보에는 상상을 초월할 정도로 개인의 사생활 정보가 노출된다. 편리함을 위하여 필수적인 정보들이 수집되기 때문이다. 이런 모든 개인정보들을 보호하기 위한 것이 GDPR이다. GDPR 규정은 너무 방대하기 때문에 전문 컨설팅을 받아야 할 정도로 복잡하고, 조항도 많고, 이해하기도 힘들다. 그 중에는 당연히 입력된 개인정보를 암호화해서 숨기기 위한 Tokenization이나 Pseudonymisation과 같은 암호화 기술도 언급된다. 많은 소프트웨어 제품의 경우에 암호화에 필요한 패스워드를 프로그램에 포함하는 엉터리 암호화 흉내는 무지한 대중을 상대로 홍보용으로 사용되어 오기도 했지만 GDPR에는 당연히 허용될 수 없다. 이제는 더 이상 눈 가리고 아웅하는 식의 가짜 암호화 방식은 사용될 수 없는 상황이 된 것이다. 너무나 당연한 결과이다.

여기서는 GDPR 규정 자체를 설명하는 것은 불가능하고 각자 알아서 연구할 일이지만 GDPR로 인한 전세계 소프트웨어 회사들의 동향을 소개하려고 한다. 먼저 GDPR의 대상이 되는 경우는 EU 국가 중의 국민이 한 명 이라도 개인 정보를 입력하고 저장되는 소프트웨어 패키지나 웹사이트이다. 그러므로 기본적으로 글로벌 소프트웨어라고 말하는 모든 소프트웨어가 대상이 된다.

구글과 페이스북이 2년의 유예기간을 포함하여 수년간 준비를 했음에도 불구하고 발효 즉시 소송을 당할 정도로 준수하기 어렵다. 애플과 아마존도 추가적인 소송대상에서 벗어나지 못했다. 발효 후 1년이 지난 지금까지 10만개 정도의 소송이 생긴 것으로 보고되어 있다. 어떤 소프트웨어 회사들은 아예 EU에서의 접속을 차단하고 사업을 중지하기도 했다. 전세계 행동기반 온라인 광고 유럽 매출이 2018년 5월 25일 발효 즉시 25~40%가 감소했다. 벌금을 내느니 차라리 유럽고객을 차단하는 것이 좋다고 생각했기 때문이다.

GDPR은 이제 발효 후 1년이 지난 태동 단계인 만큼 지금은 거대 기업들부터 순차적으로 고발과 소송이 진행되고 있지만 언젠가는 EU 국가에 사용자가 있는 모든 소프트웨어 회사들이 소송의 대상이 될 것이다. 한 번에 완벽한 준수는 어렵지만 점진적으로 개발해 나가고 있는 것이 현실이다. 작은 회사의 경우일수록 조금 더 시간 여유가 있겠지만 언젠가 자기 차례가 돌아오기 전까지 준비를 해 놓아야 한다. 악의에 찬 고객 한 명이 고발을 할 정도로 쉬우니 피해갈 생각은 하지 않는 것이 좋다.

그런데 국내 회사들의 상황은 어떤가? 전세계에서 난리인 GDPR이라는 용어를 아는 사람도 국내에는 많지 않다. 전세계에 전자제품을 수출하는 대기업들은 이미 준비를 해서 대웅하고 있지만 대부분의 국내 소프트웨어 회사들에게는 GDPR은 관심의 대상이 아니다. 대부분 Active-X 사용, 주민등록 번호, 공인인증서, 은행과의 연계 등 국내인이 아니면 거의 사용 불가능한 국내용 소프트웨어이기 때문이다. 국내 온라인 사이트는 외국인 특히 유럽인을 상대로 사업을 하는 경우가 거의 없다. 이런 상황에서 글로벌 소프트웨어를 추구하겠다는 회사들에게는 GDPR은 생각지도 못했던 큰 짐이다..

GDPR은 소프트웨어 요구사항 분석 과정에서 명시된 소프트웨어 국제화(Internationalization)와 안전성(Security) 요구사항 중의 하나이면서 가장 중요한 항목으로 추가 되었다. 필자가 늘 얘기하듯이 영원히 국내에서만 판매하겠다는 소프트웨어라면 값비싼 국제화나 GDPR을 걱정할 필요가 없다. 하지만 나중에 필요한 때가 되면 국제화 개발이나 GDPR을 준수하겠다는 순진한 생각은 전략도 없이 아무 때나 조그만 기능하나 추가하면 되겠지 라는 큰 착각이다. 그렇게 간단하다면 구글이나 페이스북이 수년간 못했을 리 없다. 소프트웨어의 뼈대라고 하는 아키텍처의 중요성이 국제화와 GDPR 준수의 핵심이다. 아키텍처를 변경한다는 것은 재개발이나 마찬가지일 만큼 방대하고 어렵다. 대부분의 회사는 아키텍처가 중요하다는 인식을 했을 때는 이미 늦었다.

GDPR에 대한 국내 소프트웨어 회사들의 인지도나 관심 혹은 실제 행동여부로 보면 과연 글로벌 진출을 하겠다는 의지나 역량이 있는 것인지 의심이 간다. 그러지 않아도 어려운 소프트웨어의 글로벌화에 거대한 장벽이 하나 더 생긴 것이다. 전세계에서 몇 십 년 동안 연구되어온 소프트웨어 국제화라는 거대한 주제도 국내에서는 개발자들 한두 명의 머리에서 나온 자화자찬의 방식으로 진행해서는 글로벌에서 이미 이삼십 년 전에 버려진 경쟁력 없는 방식의 재현이 되기 쉽다. 자연 진화의 필연적인 시행착오의 결과이다.

필자가 경험한 거의 모든 국내 소프트웨어 회사들은 그런 자연진화론적 방식으로 진행되어 왔다. 이미 글로벌 기술보다 이십 년 이상 뒤떨어진 국제화 방식으로 글로벌 경쟁력이 생기기도 어려운데 GDPR이라는 거대한 장벽까지 생겼으니 소프트웨어의 글로벌 진출이 더 어려워진 것은 엄연한 사실이다. 국내에서만 사업을 하겠다면 이 복잡한 것 필요 없이 마음 편하다. 하지만 “진정으로 깨달았을 때는 관속에 들어가기 하루 전”이라는 속담도 있지만 글로벌화를 주장한다면 이제부터라도 과연 소프트웨어 글로벌화가 무엇인지 혹은 구체적으로 수십 개의 국가나 언어를 지원하기 위해 지금 충분한 아키텍처가 고려되어 있는지에 대한 심각한 고찰이 필요할 때다.

2019년 1월 10일 목요일

분석 #10. 잘못된 국내 Outsourcing 계약 방식과 글로벌 계약 방식


이 기사는 일전에 게재한 기사인 “분할발주의 허구와 진실” 과 바로 앞 기사인 베트남의 Outsourcing 회사에 관한 기사와 연관되어 있다. 국내 개발 Outsourcing 생태계의 도전적인 숙제이자 염원이기도 한 “분할 발주”도 하고 싶고 글로벌 고객을 상대로 개발 Outsourcing 비지니스도 하고 싶겠지만 열정과 의지만으로 되는 것은 아니고 그를 수행할 수 있는 기본 역량부터 있고 다양한 고객을 상대할 수 있는 경험도 있어야 한다.

대부분의 국내 회사는 거의 미신과 같은 국내의 기존 관행에 몇십년을 젖어 있었기 때문에 우물안 개구리의 문제점을 눈치 채기도 어렵다. 이 기사를 읽어도 눈치 챌 수 있는 사람은 극히 소수일 것이다. 꿈속에서 사는 삶이 있고 현실의 삶이 따로 있는데 이런 추상적인 문제에서는 계속 꿈속에서 사는 것이 통상적이다. 영화 매트릭스에서 얘기한 빨간 약을 먹으면 계속 행복한 환상의 세계에서 살고 파란 약을 먹으면 고통스러운 진실과 마주한다는 것과 같다. 현실에서는 진실을 모르는 것이 더 좋은 경우가 더 많다. 어느 쪽을 택할 지는 순전한 각자의 선택이다.

먼저 소프트웨어 외주 개발 계약의 방식부터 간단히 살펴보자. 필자의 저서와 블로그에서 여러 번 언급했듯이 계약에는 Time and Material(T&M)과 Turn-key 의 두 가지 방식이 있다.

T&M은 인력의 노동시간(Time)으로 비용을 지불하는 방식이다. 발주자나 인력 업체나 간단하다. 인력을 어떻게 사용할지는 발주자가 알아서 관리한다. 계약한 숫자의 인력만 제대로 공급해주면 법적인 소송의 여지도 없다. 주로 개발 앞쪽의 분석 단계에서 사용된다. 산출물에 대한 객관적인 기준을 정할 수 없는 경우에는 T&M 방식이 가장 좋다. 정확하게 말하면 인력의 시간외에 실제 들어가는 장비나 물품((Material)이 포함한다.

반면에 Turn-key 방식은 서로 약속한 제품을 미리 정해진 가격(Fixed Price)과 일정에 개발해 주기로 하는 것이다. 즉 한 사람이 개발하건 10명이 개발해 주건 상관할 필요가 없다. 예를 들어 책상을 주문했는데 몇 명이 만들 건 상관이 없다. 원하는 제품을 만들어 주면 되는 것이다. 자동차를 주문해도 마찬가지이다. 몇 명이 만들었는지도 모르고 알 필요도 없다. 그런 자유가 있는 반면에 책임도 크다. Turn-key 방식은 약속한 물품을 제 일정에 배달하지 못하면 당연히 피해 보상등 법적 소송의 문제가 발생한다.

소송에서 시시비비를 판단하려면 제품에 대한 정확한 스펙(SRS)이 있어야만 가능하다. 정확한 스펙을 작성하는 것이 얼마나 어려운 지는 그 동안 필자가 누누히 설명했다. 정밀도의 문제와 같다. 1센티를 따지는 스펙과 1밀리미터를 따지는 스펙은 양과 질에서 차이가 난다. 소프트웨어도 홈페이지 만드는 정밀도와 금융 소프트웨어를 만드는 정밀도가 다르다. 간단한 홈페이지 프로젝트는 적당한 계약에 애자일 방법론도 좋고 주먹구구식으로 개발해도 큰 문제가 없다. 문제가 있으면 별 피해 없이 고치면 된다. 금융 소프트웨어는 1분만 다운되어도 피해보상 소송이 빗발치니 처음부터 문제 없도록 개발해야 한다.

스펙에 대해서는 여러 곳에서 충분히 설명했기 때문에 여기서 생략하고 Turn-Key 계약에 스펙보다 더 핵심인 인수테스트(Acceptance Test Plan, ATP)를 추가로 소개한다. 회사마다 용어가 약간 다를 수 있으나 가장 혼란 없이 이해하는 용어인 ATP를 사용하기로 한다.

위에서 말한 T&M 방식의 계약에는 인력 공급 내용만 있지 산출물은 정해지지 않았기 때문에 검증할 인수 조건이 없다. 쉽게 말해 일당으로 비용이 계산되는 일용직 고급 근로자라고 보면 적절하다. 통상적으로 분석이나 설계 작업과 같이 하루에 수천불 가격인 매우 비싼 직업이다. 개발의 첫 단계에서는 계약에 명시할 스펙도 없고 인수 조건도 나올 수 없다. 이런 비싼 고급 전문가를 잘 사용하고 관리하는 것은 전적으로 발주자의 역할이다. 전문성이 높은 분석가나 아키텍트인 만큼 대부분은 발주자를 리드하고 주도해서 일을 할 수 있는 능력이 있다. 그런 능력 때문에 비싼 값을 지불한다.

Turn-Key 방식의 핵심이 스펙이라고 이전에 필자가 계속 말해 왔는데 일부만 사실이다. 진짜 핵심은 인수조건이다. 인수테스트로 대표되는 인수조건이 핵심이다. 하지만 인수테스트만 가지고는 개발을 할 수 없기 때문에 개발할 내용을 설명하는 스펙이 필요한 것이지 법적인 상황에서는 스펙보다는 ATP로 시비를 가린다. 근본적으로 ATP를 통과하면 계약은 종료된 것이고 ATP 중에 하나라도 실패하면 계약이 종료되지 않은 것이다. 개발사가 폭포수 모델로 개발하건, 애자일방식으로 개발하건 반복적모델로 개발하건 상관이 없다. 100개가 넘는 시중의 개발방법론, 또 수만개는 되는 다양한 종류의 템플릿 중에 어떤 것을 사용하건 상관할 필요가 없다. 그냥 약속한 일정에 ATP를 통과한 물품을 배달하기만 하면 된다. 이상적인 상황이라면 중간에 서로 대화를 할 필요도 없다. 배달 날자까지 기다렸다가 인수를 하든지 피해보상 소송을 하든지 둘 중의 하나이다. 이 부분은 명백한 흑백논리가 적용된다. 예를 들어 ATP에 포함된 10,000개의 테스트 케이스 중에서 1개라도 실패하면 실패한 것이다.

Turn-key 계약의 인수조건은 아주 명백하지만 아무나 이렇게 하기 어려운 두가지 이유가 있다. ATP에 포함되는 테스트 케이스를 만들기 어렵다. 국내에서 ATP를 이용해서 계약을 한 회사는 필자는 본 적이 없다. 대부분은 엉성한 스펙만으로도 몇 백억짜리 프로젝트도 계약 한다. 성공하면 기적이다.

누가 테스트 하느냐에 따라서 ATP에 들어가는 테스트 케이스의 개수는 10배도 더 차이가 난다. 회사의 내부에서 제품도 잘 알고 늘 테스트 해 오던 사람들이 하는 경우와 외부의 인력이 테스트 할 경우에 테스트 케이스의 숫자가 10배 정도의 차이가 날 수 있다. 전혀 모르는 사람에게 스펙을 적어 줄 때도 마찬가지이다. 내부 인력이라면 10 페이지 적으면 되는 양을 외주 계약을 위해서는 100 페이지를 적어야 하는 경우가 전혀 이상한 것이 아니다. 필자에게 “스펙이나 ATP를 얼마나 자세히 적어야 됩니까?” 라는 질문을 많이 하는데 고객과 상황에 따라 다르다는 답 밖에 없다. 이런 상황에 따른 유연성이 진정한 소프트웨어 공학의 영역이다. 건강에 좋은 음식이 사람에 따라 다른 것과 마찬가지이다. 만약 누가 정형화된 답을 준다면 그것은 이론이며 가짜 소프트웨어 공학인 것이다.

우여 곡절 끝에 많은 시간을 들여서 외부 사람들을 위한 방대한 ATP 테스트 케이스를 작성했다고 가정하자. 그렇다고 개발업체만 믿고 계약 마지막 날에 완성이 될 것이라고 기다리기에는 불안하다. 100만원에 1주일짜리 프로젝트라면 그렇게 해도 괜찮겠지만 100억에 1년 걸리는 프로젝트를 하는데 그렇게 할 수는 없다. 그래서 ATP는 완료 평가의 척도는 되지만 중간에 개발이 제대로 진행되는지 확인하기 위해서는 다른 방법이 필요하다. 그래서 Design Review, Integration Test, 몇 번의 Iteration등 중간 중간에 진행 상황을 검증할 수 있어야 한다. 물론 여기에서도 몇 명이 개발하는지는 중요하지 않다. 천재 1명이 개발하든 초급개발자 100명이 개발하든 그건 개발업체의 선택이다.

정확한 스펙과 ATP도 없이 수행하는 Turn-key 계약은 근본적으로 거대한 위험성을 내포하고 있다. 성공할 가능성은 없다고 보면 된다. 나중에 그냥 서로 눈감고 대충 넘어가거나 소송으로 가거나 둘 중의 하나이다. 거대한 제품을 개발했는데 인수를 거절해서 소송이 벌어진 경우도 있다. 정확한 스펙과 ATP 없이 계약하려고 하니까 뭔가 안전장치를 만들어야 하고 담당자는 책임도 회피해야 하니 투입할 인력을 명시하게 된다. 더군다나 발주자가 확인할 수 있는 장소에 상주하도록 요구한다. 그러다 보니 Turn-key 계약에 액수, 일정, 인력까지 명시하는 것이다. 상식적으로 말이 안되지만 담당자가 책임을 회피하기 위해서는 가장 쉬운 방법이 인력이다. 그러니 원래 어려운 원격 개발은 이래저래 더 어렵다.

그래서 T&M 방식도 아니고 Turn-key 방식도 아닌 비상식적인 계약이 그동안 국내에서 멀쩡하게 사용되어 왔다. 그럴 수 밖에 없는 근본적인 원인은 스펙의 부정확성, ATP의 부족이나 부재, 그리고 중간에 Monitoring 할 수 있는 역량이 부족하기 때문이다. 국내에서는 이런 식의 계약에도 거부감을 느끼지 못하겠지만 이런 비상식적인 계약은 소프트웨어 선진국의 정상적인 상황에서는 존재할 수 없다. 발주자인 갑의 역량부족으로 인해서 생긴 계약의 횡포일 뿐이다. 이 모든 문제를 해결하려면 ATP를 작성할 수 있는 역량이 있어야 하는데 ATP를 만들기 위해서는 정확한 스펙이 있다는 가정하에서만 가능하다.

진정한 Turn-key로 계약하고 관리할 수 없는 회사에서 과연 훌륭한 소프트웨어를 만들어 낼 수 있을까? 없다고 생각한다. 전략 없는 숙련공들의 혼란스러운 개발이 될 수 밖에 없다. 스펙을 개발 도중에 변경하는 일도 빈번하고 따라서 회의나 번잡스러운 일이 많아지고 관리비용이 엄청나게 추가된다. 개발보다는 관리에 더 집중하기 쉽다. 그래서 관리를 잘해 보겠다고 또 새로운 시스템을 도입하거나 PMO니 하는 얘기가 나오는데 방향을 잘못 잡는 것이다. 합리화 하기 위한 방법으로 실리콘밸리의 영웅담 같은 얘기는 꼭 인용한다. 악순환이 계속된다. 대부분의 문제는 관리로 해결될 수 있는 문제가 아니기 때문이다. 좌절한 개발자가 중간에 사라지는 것도 늘 보는 현상이고 납기 지연은 너무 당연하다. 종종 나오는 뉴스가 알만한 큰 프로젝트들이 지연되었다는 기사이다.

국내는 인간 관계로 적당히 실패를 덮어 버릴 수 있다. 그러나 그럴 수 없는 국제간의 심각한 계약을 한다고 생각해 보면 ATP를 작성할 수 있는 역량이 없으면 T&M 방식으로 계약하는 방법 밖에 없다. 글로벌 회사에서는 발주자나 개발업체나 둘 다 엉성한 Turn-key 계약은 할 수 있는 근거도 없고 그런 위험하고 무책임한 계약은 하지도 않는다.

거의 모든 국내 소프트웨어 관련 소송은 이 부류에 속한다. 소송 당사자들은 국내 관행대로 했는데 왜 소송을 당했는지를 이해하지 못한다. ATP와 같은 객관적인 평가 기준이 없으니 자신들 유리한 대로 해석하고 서로 상대방만 비난한다. 개발업체는 몰상식한 악덕 발주자를 만나서 억울하다고 하고 발주자는 회사에 손해를 끼친 엉터리 개발업체라고 분에 차있다. 처음부터 사기를 치려고 하지 않았다면 대부분의 경우 둘 다 50% 씩 잘못이다. 이 모두 ATP만 있었다면 소송에 갈 필요도 없다.

분할 발주, 원격 개발, 탄력있는 근무 시간등 아주 듣기 좋은 말들이다. 정부가 강제로 계약에 관련된 이런 정책을 법제화 하려고 하는 것은 좋지만 생태계가 준비되지 않은 상태에서는 더 큰 문제를 불러 올 수 있다. 근본적인 이해 없이 눈 앞의 증상만을 치료해 보고자 하는 단세포적인 정책은 또 다른 문제를 불러온다. 극히 조심해야 한다.

스펙이나 ATP 작성 역량은 계약을 위한 역량뿐은 아니고 소프트웨어를 제대로 개발하기 위해 꼭 필요한 역량이다. 이런 기초 체력 없이 소프트웨어 강국이 되려는 생각은 허황된 망상에 불과하다. 그냥 국내에서 국내 고객을 위해 국내용 소프트웨어를 개발하는 정도로 만족해야 한다. 그것도 하나의 훌륭한 성공이다. 많은 시간과 경험이 필요한 이런 역량을 교육으로 해결하겠다는 생각을 하는 사람들도 많이 봤는데 태권도를 이론 교육으로 가르치려는 것과 같다. 이는 학교에서는 절대 가르칠 수 없는 현실의 문제이고 바로 진정한 소프트웨어 공학 역량이다.

2018년 11월 10일 토요일

분석 #9. 글로벌 SW Outsourcing 시장, 분석과 영어 역량


필자가 15년 전에 "대한민국에는 소프트웨어가 없다" 라는 책을 썼다. 그동안 여기저기 사람들을 만나다 보면 "지금은 소프트웨어가 있습니까?" 하고 나에게 물어본다. 변한 것이 없다고 대답한다. 마치 엄청난 발전을 이룬 것 같지만 잘 보면 하나도 잘 된 것이 없다. 마치 "15년 전보다 세상이 행복해 졌습니까?" 라고 묻는 것과 같다. 문명은 엄청난 발전을 했지만 정신적인 행복은 변한 것이 없다. 아마 더 불행해 졌을지도 모른다. SW도 마찬가지이다. 수 많은 새로운 도구와 기술이 생겨났지만 그런 것은 이 세상 누구나가 다 사용하는 것이다. 즉 경쟁력에서 도움이 되지도 않고 그냥 모든 사람들에게 편리한 도구가 생긴 것 뿐이다. 그런 것을 사용한다고 더 경쟁력이 생기는 것도 아니고 당연히 때에 따라 편리하니까 사용하는 것일 뿐이다. 유행에 따라 잠깐 생겼다가 없어지는 것이 대부분이다. 동서고금을 통해 진짜 중요한 도구들은 이미 필자가 경험한 40년 전부터 존재해 왔다. 예를 들어 소스코드관리 시스템이나 이슈관리 시스템 같은 것이다. 많은 진화를 거듭해서 편리한 점이 많아 졌지만 그 사상에는 큰 차이는 없다. Git이나 Jira가 없었던 과거에도 다른 도구들이 있어 왔고 똑같이 사용해 왔다. 글로벌 대기업들은 내부적으로 그런 도구들을 자체 개발해서 사용하기도 한다. 하지만 사상은 변하지 않았다.

SW 역량을 평가할 때 여러가지 관점이 있지만 여기서는 SW Outsourcing 중에서도 SW 개발 Outsourcing 역량에 대해서 얘기하기로 한다. SW 개발 Outsourcing,은 국내에서는 소프트웨어 개발의 약 70%를 차지한다는 통계가 있다. 30%는 자체 제품이나 인프라 개발이다. 그 만큼 무시할 수 없는 비중을 차지하고 있기도 하고 SW 산업이 3D 업종이라고 불리는 중요한 원인이기도 하다. SW에서 생기는 모든 문제는 결국은 분석역량이 최초의 원인으로 도달하게 된다. 그 다음은 설계 역량이 중요할 텐데 궁금해 하는 사람들을 위해 숫자로 표현하자면 분석에 비해 1/10 정도의 중요성이다. 숫자는 상징적인 의미를 위해 사용했지 컨설팅업체라면 만들어 내는 재주가 있을지 모르지만 어디에도 이런 근거는 있을 수 없다. 그러니 설계를 귀신같이 한다고 해도 10% 밖에 안되는 것을 잘하는 것이다. 난이도도 1/10 정도이다. 바둑을 두는데 프로가 되는 것이 아마추어의 최고가 되는 것과는 열 배 이상 더 어렵다. 분석을 잘하는 것과 설계를 잘하는 것은 프로와 아마추어의 관계라고 비교할 수 있다.

전세계 SW 개발 Outsourcing business는 몇십년 전부터 cross-border라고 국가의 경계를 넘어 진행되어 왔다. 거리가 먼 나라인 경우 Offshore, 몇시간 정도 거리를 near-shore, 바다를 넘어기지 않고 가까운 경우 on-shore라고 부르기도 한다. 현재 전 세계 SW 개발 Outsourcing business에서 인도와 베트남이 가장 중요한 나라이다. 인도는 미국에게서 배웠고 베트남은 인도에게 배워서 따라 하는 상황이기 때문에 베트남이 인도에 비해 10년 이상은 뒤떨어져 있다고 본다. TCS나 Wipro같은 인도의 글로벌 Outsourcing회사는 인건비도 비싸지만 이제는 지저분한 고객과는 상대를 하지 않는다. 그런 인도 회사들이 떠나는 자리를 베트남이 메꾸기 시작해 결과적으로 인도와 베트남이 이제는 전 세계 Outsourcing 시장의 양대 산맥이 되었다.

인터넷에서 "Software Outsourcing India", "Software outsourcing Vietnam"과 "Software Outsourcing Korea"로 비교해 보기 바란다. 국내 SW의 70%를 차지한다고 하는 국내 개발 회사들은 글로벌에는 존재가 전무하다. 반대로 Vietnam에 관한 자료는 연구논문이 있을 정도로 수를 셀수 없이 많다. 베트남에서 가장 큰 SW 회사라고 하면 FPT Software인데 개발인력만 만명이 넘는다. 고객의 대부분이 미국, 일본, 유럽의 글로벌 회사들이다. FPT 이외에도 규모는 작지만 수천명의 개발인력을 가진 회사들이 수십개가 넘는다. 제조업이 많지 않은 베트남의 국내 사정상 국내 고객은 극히 적다. 모두 처음부터 외국의 고객들을 대상으로 생겨났다. 글로벌 회사들을 상대로 10년 이상을 개발해 왔기 때문에 엄청난 기술과 함께 소프트웨어 공학 역량도 축적이 되었다. 베트남의 중요한 외화벌이 산업이기도 한다.

위에서 말한 인도의 회사들이 피하는 "지저분한 고객"은 바로 주먹구구식으로 계약을 하는 회사들이다. "주먹구구식"과 똑같은 단어가 "분석역량이 없다"는 것이다. 국내 회사가 10페이지 짜리 스펙을 적을 때 글로벌 회사들은 100페이지 짜리 스펙을 적는다. 그런 두 회사가 계약을 하거나 파트너십을 얘기할 때 잘 되지 않을 것은 너무 당연하다. 프로와 아마추어의 차이이다. 프로는 프로를 찾아서 놀기 마련이다. 그래서 인도의 회사들이 국내 회사들을 상대하지 않는 이유이기도 하다. 그런 국내 회사들을 베트남 회사들은 지금은 기꺼이 고객으로 상대해 준다. 워낙 인건비가 저렴하니 위험을 감수해도 이익을 창출할 수 있다고 생각한다. 소위 갑질이라고 하는 "고객의 사양 변경하기"를 당해도 자존심 버리고 저비용으로 버틸 수 있다. 자존심이 없거나 몰라서 당하는 것이 아니다. 하지만 인건비 비싸고 마진이 작은 국내 SI 회사들은 버티기 어렵다.

베트남의 Outsourcing 회사들은 미국, 일본, 유럽의 고객들과 경험이 있기 때문에 당연히 국내 회사들의 차이와 문제점을 잘 알고 있다. 또 베트남이 글로벌시장에서 성공할 수 있었던 가장 중요한 이유중의 하나가 영어 역량이다. 내가 만났던 베트남회사의 모든 임원들은 영어를 실리콘밸리에서 만나서 회의하는 것과 같은 정도로 편안하게 구사한다. FPT Software의 경우 모든 직원들이 email과 문서는 영어로 적는 것으로 규정하고 있다. 또 일년에 한 번씩 모든 임직원이 예외 없이 TOEIC 시험을 봐서 점수를 공개한다. 또 FPT가 설립한 베트남의 최고 기술대학 중의 하나인 FPT University의 입학 조건이 TOEIC 800점이다. 국내에서 직원의 TOEIC 평균이 800 점을 넘는 회사는 아마 한두 군데 뿐일 것이다. 일본의 대기업들도 영어만 사용하도록 규정을 바꾼 회사들이 점점 더 많이 생기고 있다. 일본의 최대 인터넷 쇼핑몰 회사인 라쿠텐이 2010년에 회사의 공식 내부 언어는 영어로 한다고 해서 직원들을 쇼크상태로 몰아가기도 했다. 하지만 지금은 감사해 하는 직원들이 많다. 언어에 관한 한 가장 폐쇄적인 나라였던 일본 회사들도 글로벌 환경에 적응하기 위해 그만큼 변하고 있다.

베트남의 소프트웨어 산업은 이런 소프트웨어 공학과 영어의 역량을 기반으로 글로벌 회사들과 같이 일을 하면서 빠르게 성장하고 있다. 반면에 국내의 상황은 암울하다. 앞으로 10년이 지나도 오늘 현재 베트남이 글로벌에서 가지고 있는 수준을 넘어가지 못할 것이다. 그냥 국내용 숙련공들만 많이 생기는 생태계이다. 필자가 볼 때 20년 전의 상황이나 지금 상황이나 소프트웨어공학 역량이나 영어역량은 변한 것이 없다. 그냥 보호무역적이고 폐쇄적인 상황에서 국내용으로 안주해 왔을 뿐이다. 국내의 온라인 쇼핑몰 중에 외국인이 구매할 수 있는 곳은 없다. 필자가 늘 얘기하듯이 국내에서만 살아가겠다면 식당을 하든, 술집을 하든, 소프트웨어 회사를 하든 참견할 일은 아니다. 하지만 식당을 열어 놓고 외국고객을 상대로 장사를 하겠다고 주장한다면 변해야 한다.

지난 20년 이상 그랬듯이 지금도 국내에서 정부, 산업계, 학계, 연구소에서 수 많은 탁상공론들이 얘기되고 있다. 아직도 무엇이 핵심인지도 모르고 이론과 용어만 가지고 메뉴만 바꾼 시행착오를 하고 있다. 진정한 분석이 무엇인지 본 적도 없으니 100페이지를 10페이지로 적고 껍데기에 불과한 방법론이나 운운하며 자아도취에 빠져서는 앞으로 영원히 발전할 수도 없고 베트남에게도 점점 더 뒤떨어 질 것이다. 세계에 내 세울만한 소프트웨어는 하나도 없고 외국 대학 수업의 숙제 수준의 소프트웨어를 만들어 정부 보조금 받아 생존하며 자화자찬 하면서 세계적인 소프트웨어를 만들었다고 주장하는 상황이 20년 전이나 신기할 정도로 전혀 변한 것이 없다. 마치 데자뷰를 보는 것 같다. 베트남이 많은 글로벌 회사들을 고객으로 개발을 하면서 성장했다는 사실도 모르는 우물안 개구리로 살고 있다. 자아도취와 자화자찬이 현재의 국내 상황이다. 그러면서 글로벌 흉내를 낸다고 국내 실정에 맞지도 않는 것을 따라 하려고 하는 것도 20년 동안 전혀 변하지 않았다. 바로 "아니면 말고"이다. 장님 코끼리 만지듯 주워들은 실리콘밸리의 영웅담 얘기는 모든 사람이 빼놓지 않고 한다. 서울 안가본 사람이 서울을 더 잘아는 척하는 얘기와 같다.

차라리 가짜 소프트웨어 공학으로 그동안 시행착오 했을 동안에 영어공부라도 했으면 국내 사이트의 가짜 정보 대신에 글로벌 사이트에서 영어로 된 정보를 접하는 것이 더 좋았을 수도 있다. 소프트웨어 개발은 단순하다. 분석->설계->구현->테스트 이다. 하지만 단순하지만 어렵다. 노래를 잘하려면 음정과 박자를 맞추면 된다는 것과 비슷하다. 단순하지만 혼자서 배우기는 어렵다. 누군가에게 배워야 한다. 철학자인 니체가 "세상에는 진짜보다 가짜가 더 많다"라고 했다. 국내에서 진짜를 거의 찾아보기 힘든 분야가 소프트웨어 공학분야이다.

적어도 20년 이상을 이런 생태계로 지내면서 이해 집단도 많아져 진짜가 살아가기 어려운 생태계가 되어버렸다. 먼저 개발자들이 더 이상 속아 넘어가지 않는 것이 중요하다. 그러는 순간 길이 보이기 시작할 것이다. 적어도 20년 이상을 반복해 온 역사에서 배울 것이 있다. 또 "촘스키처럼 생각하는 법"이라는 책에서 말하는 것 처럼 남에게 이용 당하지 않으려면 가짜로부터의 지적인 자기방어가 필요하다.

필자의 경우에도 이제는 웬만하면 베트남 개발 인력을 사용하려고 하고 있다. 베트남이 SW Outsourcing에서 성공할 수 있었던 이유는 도메인 지식도 아니고 영어를 기반으로 인도에게서 배운 소프트웨어 공학 역량이었다. 그 중에서도 계약을 가능하게 하는 것은 바로 분석 역량이다. 혹은 Software Requirements Specification(스펙)을 작성할 수 있는 능력이다. 인도는 똑같이 미국에게서 배웠다. 베트남에게서 배워야 한다는 것을 인정하기 힘들겠지만 너무 수준 차이가 나는 미국이나 인도보다도 베트남에게서 배울 점이 있다는 것을 쉽게 인지할 수 있다.

2017년 7월 15일 토요일

분석 #8 애자일은 죽었다

"애자일"이라고 하면 국내 소프트웨어 업계에서는 보통 "스크럼"으로 알고 있다. 여기서 스크럼을 자세히 설명하는 것은 의미가 없고 대충 설명하자면 10명 정도의 한 팀에서 스프린트라고 불리는 2주일 개발주기로 개발하면서 매일 아침 서서 회의를 한다는 것이다. 필자는 이 말을 듣고 농담하는줄 알았다고 책에서 적은 적이 있다.

하여튼 형식과 체계를 싫어하는 자유로운 영혼의 개발자들에게는 무척 희소식이다. 어차피 아무런 체계없이 주먹구구식으로 계속 개발할 수는 없다. 명분도 없고 어딘가 찜찜할 수 밖에 없다. 그런 와중에 아주 쉽게 적용할 수 있는 애자일이라는 방법이 있으니 반가울 수 밖에 없다. 이제는 자랑스럽게 방법론에 의해서 개발을 하고 있다고 말할 수가 있게 되었다. 일단 주먹구구식에서 벗어났다고는 할 수 있다. 그 길이 옳은지 아닌지는 별개의 문제이다.

"애자일"은 추상적인 단어이고 그 종류가 많지만 이 글에서는 애자일이라는 단어를 방법론 중에서 가장 자유로운 스크럼 방법론이라고 가정하고 진행한다. 그 반대 극단은 한번 결정한 것을 변경하지 않는다는 가장 엄격한 방법론인 폭포수모델이다. 요구사항의 변경을 수용하기 위한 반복적인 개발모델의 필요성이 의논된 것은 소프트웨어의 탄생 얼마 후인 1957년이었다. 지금부터 60년 전이다. 그리고 폭포수모델의 병폐와 애자일 방법론의 필요성에 대한 본격적인 논쟁은 거의 30년 전인 1990년에 출간된 "Wicked Problems and Righteous Solution" 이라는 책에서 벌어졌다. 마치 애자일방법론이라는 비법을 최근에 발견한 것 처럼 착각하는데 스크럼이 탄생한 1995년에도 애자일은 이미 퀘퀘묵은 논쟁이었다. 폭포수모델이 필요한 곳에서는 폭포수모델을 계속 사용할테고 절대 폭포수모델을 사용하지 않는 곳도 있고 너무 당연한 종교적인 논쟁일 뿐이다. 중요한 것은 어떤 방법론이 우리가 개발하는 제품에 적당할 것인가이다.

필자가 실리콘밸리에서 20년 동안 사용한 방법론은 방위산업체에서의 수년간의 폭포수모델과 그 나머지는 애자일 방법론이었다. 물론 애자일이라는 용어가 생겨나기도 전이었기 때문에 스크럼은 당연히 아니고 "빨리 개발하는 방법론" 이라는 의미에서의 애자일방법론이다. 회사마다 빨리 개발하는 방법이 다 달랐다. 당연할 수 밖에 없다. 프로젝트가 다른데 폭포수나 스크럼이 만병통치약이 안되듯이 한 가지 방법론으로 다 통할 수가 없다. 경직도로 봤을 때 폭포수와 애자일 중간에는 수십개의 알려졌던 방법론이 있고 비공식적으로는 회사마다 다른 수만개의 방법론이 있다.

애자일의 공식적인 생애는 1995년 ~ 2014년까지 20년이다. 그래도 다른 방법론에 비하면 오래 생존한 편이다. 애자일을 창시한 사람들이 애자일은 잘못되었다고 선언했다. 인터넷에서 'Agile is dead"를 검색하면 많은 기사들이 많이 나온다. 그렇다고 애자일을 창시한 사람들이 소프트웨어 개발의 근본 원칙을 부정한 것이 아니라 간단한 규칙을 만들어 준 것이었다. 그 규칙을 누가 어떻게 해석하고 이용하는 가에 따라 좋은 것이 될 수도 있고 나쁜 것이 될 수도 있는데 대부분은 애자일을 만든 사람의 의도와는 다르게 사용되었기 때문에 실패했다고 공식적으로 선언한 것이다. 수 많은 방법론의 역사에서 보면 심각한 일도 아니고 하나의 해프닝으로 볼 수 있다.

결국 애자일이 되었던 폭포수가 되었던 수 많은 실리콘밸리회사들이 사용하는 방법론의 원칙을 이해하는 것이 중요하다. 그 진리는 분석, 설계, 구현이다. 이 단계를 잘 이해하고 적용하는 것이 중요하지 방법론의 규칙이 중요한 것이 아니다. 어차피 극히 소수만 사용하는 폭포수방법론이 아닌 경우에는 모두 반복적인 방법론이다. 이미 몇십년 전에 공식적으로 반복적인 방법론이 나왔기 때문에 새로운 것이 아니다. 스크럼이 하나의 방법론으로 눈에 띄기 위해서는 어떤 매력적인 규칙을 정해야 하는데 그 중에 하나가 2주 주기 개발이다. 기존의 방법론과 차별화가 안되니 2주를 강조했다. 거기에다가 Sprint라고 멋진 이름을 붙였다. 또 Daily Standing Meeting이라는 용어를 만들어 냈다. 앉아서 회의를 하면 기존의 방식과 전혀 다를 것이 없으니까 일어서서해야 한다는 것을 강조했다. 결국 스크럼방법론은 이미 기존의 회사들이 하고 있었던 방법과 별로 다를 것이 없는 것이다. 새로운 것도 아니고 나쁜 것도 아니다. 마케팅의 성공일 뿐이다. 그 덕택에 20년간 인기를 누리면서 혜택을 받은 사람들이 있었다.

지금도 어떤 프로젝트에서는 폭포수가 적절할 수도 있고 스크럼이 적절할 수도 있다. 그럼 분석이라는 측면에서 보면 어떤 것이 더 적당할까? 완벽을 추구하는 폭포수나 2주일 만의 기능을 명시하는 스크럼이나 필자가 볼때는 대부분의 프로젝트에서는 적절하지 않다. 그럼 무슨 방법론이 적절할까? 방법론을 찾아서 떠도는 순간 영원히 방법론을 찾지 못할 것이다. 왜냐하면 그런 방법론은 없기 때문이다. 마치 나에게 가장 좋은 음식이 무엇일까를 찾는 것과 같다. 좋은 음식이 사람마다 다른 것 같이 프로젝트마다 다르다. 한 회사 안에서도 프로젝트 마다 다르다. 하나의 틀에 억매이지 않고 원칙을 알고 잘 응용하는 것이 중요하다.

소프트웨어는 외부 고객이건 내부 고객이건 혹은 자기 자신이건 누군가의 요구에 의해서 개발하는 것이다. 이런 고객요구사항이 변하는 것은 소프트웨어 탄생부터 있어 왔던 변하지 않는 현상이다. 이 현상 때문에 폭포수가 잘못되었다고 말할 수는 없다. 그런 환경까지 고려해서 만들어진 것이 폭포수이기 때문이다. 핵심은 고객요구사항이 변하는 상황에서 컨트롤할 수 있어야 한다는 것이다. 그 방법이 한번에 완벽히 작성해서 확인하는 방법일 수도 있고 매일 고객과 물어보면서 작성할 수도 있고 2주일에 한번씩 보여주면서 얘기할 수도 있다. 같은 프로젝트 안에서도 어떤 경우는 매일 의논이 필요하고 어떤 경우는 1달 동안 얘기할 필요가 없는 경우도 있다. 현실에서 벌어지는 모든 프로젝트는 비규칙적이고 반복적인 협의를 필요로 한다.

결국 모든 방법론의 형식은 항상 변화해 왔지만 그 내용이 중요하다. 어떤 방법론에서도 결국 성공하려면 코딩을 잘 해야 하는 것처럼 설계도 잘 해야하고 분석도 잘 해야 한다. "잘" 이라는 용어가 "완벽하게"를 의미하지도 않고 "2주일마다"를 의미하지도 않는다.

드디어 가장 중요한 결론이 나온다. 자연의 불변하는 진리인 열역학 제2의 법칙은 "자연계에서 자발적인 진화방향은 혼란도(엔트로피)가 증가하는 방향으로 진화한다"는 것이다. 즉 열은 뜨거운 곳에서 낮은 곳으로 흐르고 흐르고 반대방향은 일어나지 않는다. 이를 비가역성이라고 한다. 최초에 열을 높은 곳으로 올려 놓는 것은 자연적이 아니라 인위적으로 해야 한다. 폭포수가 가장 안정된 상태이고 주먹구구식이 가장 엔트로피가 높은 상태이다. 자신이 최초에 원하는 수준에 가려면 그 수준을 가진 회사에 가서 배워야 한다. 폭포수를 해 본 사람은 그 아래의 어떤 방법론도 응용해서 할 수가 있다. 할 수 있는 것을 안하는 선택만 하면 된다. 하지만 애자일만 해 본 사람은 폭포수를 절대 할 수가 없다. 해 본 적이 없는 것을 할 수는 없다. 혼란한 곳에서 안정된 곳으로 갈 수 없는 자연의 진리 때문이다.

모든 규칙을 다 터득한 사람은 모든 규칙에서 벗어나 완전한 자유를 누릴 수 있다. 어려운 육체적인 고통의 수행을 거쳐 진리를 깨달은 사람을 해탈했다고 하는 것이 혼란하지 않은 마음의 안정을 얻었기 때문이다. 엔트로피가 가장 낮은 안정된 상태를 만드는 것은 어려울 수 밖에 없고 그래서 가치가 있다. 엔트로피가 가장 높은 방법론인 애자일을 배웠다면 움직일 수 있는 선택의 폭은 그 보다 다 자유로운 주먹구구식방법 밖에 없다. 물은 절대로 거꾸로 흐리지 않는다. 누가 인위적으로 올려다 주기 전에는 아래로만 갈 수 있다.

어떤 프로젝트에도 응용할 수 있는 방법론을 배우려면 가장 엔트로피가 낮은 폭포수모델을 배우는 것이다. 이런 방식이 미국의 60여년의 소프트웨어 역사가 지나온 방향이다. 그렇기 때문에 실리콘밸리에는 다양한 엔트로피를 가진 회사들이 다 존재하고 자신이 일했던 회사보다 엔트로피가 높은 프로젝트는 모두 일할 수 있다. 반면에 한국에는 엔트로피가 안정된 회사들이 없다. 내용은 없고 형식만 흉내내는 혼란스러운 회사가 있을 뿐이다.

소프트웨어 개발을 잘 하기 위해 애자일방법론이 전혀 중요한 것도 아니고 가치도 제한적이라는 것을 이해하는 것이 미래 발전을 위한 첫 걸음이다. 지금 나에게 적절하다고 확신한다면 사용하면 된다. 하지만 맹목적으로 사용하는 것은 파괴적이라고 애자일의 창시자들이 말을 하니 "해봐서 손해 볼 것 없다"는 생각은 금물이다. 엄청난 기회비용을 상실하게 되니 신중하게 결정할 일이다.

애자일로 인해 역사가 되풀이 된다는 것도 알게 되었고 유행에 민감한 국내 개발 환경이 잘못된 리더들에 의해 핵심을 놓치고 미신에 빠져 국내 소프트웨어 발전에 큰 피해가 올 수 있다는 것은 항상 조심할 일이다.

2016년 7월 31일 일요일

분석 #7 회사가 문제다 - Monotasker 와 Multitasker



SW는 인류 역사상 가장 복잡한 지식산업이다. 반대로 말하면 노동산업적인 요소가 가장 적다는 것이다. 지식산업의 특성상 인해전술이나 열정만으로는 성공하기 어렵다는 것이 문제이다. 한국회사의 경영관리체계는 과거의 노동산업적인 요소가 뿌리깊게 내려 있고 이는 한국 소프트웨어 발전의 가장 큰 장애물이다.

얼마 전에 삼성전자가 "삼성 소프트웨어 경쟁력 백서" 라는 프로그램에서 자사의 역량을 평가했다. “자사의 SW 개발자 중에서 구글의 SW 개발자 역량을 가진 사람이 1-2% 밖에 안 된다”는 내용과 "30층 짜리 건물을 지어야 하는데 삼성은 지금 초가집 짓는 수준이다." 라는 놀랄만한 내용이지만 사실이다. 10여년 전에 “대한민국에는 소프트웨어가 없다” 라는 책을 발간했고 지금도 상황이 전혀 변하지 않았다는 필자의 생각과 정확하게 일치한다. 이는 전문성 위주인 미국 SW 회사와 달리 관리 중심인 한국 SW 회사의 필연적인 결과이다. 그런데 이 문제는 증상이 개발자의 역량에서 나타났을 뿐 개발자의 잘못이 아니고 전적으로 회사와 경영진의 책임이다.

지금까지는 막연하게 SW 선진국과의 형상 비교만으로 근거 없이 한국 SW회사의 관리자나 경영진의 문제점을 지적하고 비판하는 내용이 많았는데 과학적인 근거가 나왔다. 스탠포드 대학에서 연구한 결과인데 다중작업자(Multitasker) 와 단일작업자(Monotasker) 의 차이점에 대한 연구이다. 다중작업자는 여러 가지 일을 동시에 하는 사람을 말하고 단일작업자는 한가지 일을 집중해서 하는 사람을 말한다. 다중작업자들은 자신이 다른 사람들을 인터럽트 하기도 하고 자신도 인터럽트를 당한다. MRI 조사 결과 다중작업자는 다른 일이 끼어들 때마다 흥분과 쾌락의 호르몬인 도파민이 나오고 그 쾌락에 서서히 중독되어 간다는 것이다. 중독이 심해지면서 간섭 받기를 즐기며 또 기다린다. 더 놀라운 결과는 그렇게 중독이 되면 뇌세포가 손상을 입고 IQ가 낮아져 다시는 단일작업자로 다시는 돌아갈 수 없는 불치의 상태가 된다. 결국은 간섭하고 간섭 받는 것을 즐기다 보면 집중력이 필요한 일을 하는 전문 능력은 영원히 없어진다.

한국회사의 임원이나 관리자는 하루 종일 수 많은 회의와 보고에 시간을 보내는 전형적인 다중작업자들이다. 또 개발자도 경력이 몇 년만 되면 팀장과 같은 관리 업무를 하게 된다. 이는 다중작업자가 되기 시작하는 출발점이다. 어차피 관리자들은 이미 전문 능력이 없어진 다중작업자이기 때문에 다중작업자가 되어도 상관이 없다. 하지만 개발자들은 한 번 관리를 하게 되면 영원히 개발 전문가로 되돌아 오기 힘들다. 도파민과 권력욕의 쾌락에 빠져 회사생활을 즐기며 산다. 여기까지는 문제가 없다. 어차피 관리자도 필요하기 때문이다. 하지만 관리자들의 본연의 업무가 전문가들이 제대로 전문가의 길로 갈 수 있게 환경을 만드는 일이며 다행히도 그런 작업에는 집중력이 필요하지 않다. 하지만 그런 본연의 업무보다는 표면적인 지식으로 전문성 있는 일에 쓸데없는 간섭을 하고 잘못된 결정을 내리는 것이 한국 관리자의 고질적인 문제이며 개발자들의 의욕을 감소시킨다.

지식산업인 SW 개발은 집중이 필요하다. 특히 초기단계인 분석과 설계 단계는 고도의 집중력을 필요로 한다. 이미 오래 전에 SW 개발자가 가장 많이 보는 블로그를 가지고 있고 마이크로소프트의 엑셀팀장이기도 했던 Joel Spolsky가 자신의 책에서 얘기 했다. 한 번 전화로 인터럽트를 당하면 다시 집중하기까지 30분의 시간이 소요된다고 했다. 모차르트가 음악을 작곡할 때나 작가가 글을 쓸 때 30분 마다 전화가 온다면 일을 제대로 할 수 없다. 바둑에서도 수를 읽고 있는 중에 누가 말을 걸면 처음부터 다시 시작해야 한다. 전체를 보는 일체성이 중요하기 때문이다. 그래서 버클리대의 전산학과 교수가 자기는 프로그래밍을 할 때 휴대폰, 이메일, 메신저 등 모든 통신수단을 다 꺼놓는다고 한다. 학생들에게도 수업시간에 학생들 자신을 위해 휴대폰을 꺼놓으라고 지시한다. 필자도 일주일에 이틀 정도는 아무에게도 간섭 받지 않는 조용한 환경에서 일을 하도록 노력한다. 나의 전문성을 지속적으로 유지할 수 있는 최소한의 귀중한 시간이다.

반면에 삽질, 망치질과 같은 단순 노동작업 일은 중간에 인터럽트를 당해도 다시 시작하는 데 문제가 없다. 일체성과 연속성이 없기 때문이다. 그래서 개발 중에 인터럽트의 영향이 가장 심각한 부분이 분석이고 그 다음이 설계이다. 가장 영향을 적게 받는 부분이 코딩이다. 코딩 단계는 국지적이고 설계한 결과가 있기 때문에 언제든지 코딩이 중단되어도 다시 시작하는 데 문제가 없다. 이런 얘기를 하면 코딩을 우습게 본다고 반론을 제기하는 국내 개발자들이 많은데 그 이유는 분석과 설계 없이 코딩을 하기 때문이다. 혹은 애자일 방법론을 잘못 이해하고 생각 없이 코딩으로 뛰어들어가는 애자일을 빙자한 무모한 방식이기 때문이다. 애자일의 미신 문화에 대해서는 다음에 자세히 얘기하겠지만 분석, 설계, 그리고 코딩을 동시에 하고 있다면 어려울 수 밖에 없다.

참고로 필자는 개발 시에 분석과 설계에 비해 코딩 단계에 극히 일부분의 시간만을 소비한다. 이는 1시간 짜리 프로젝트나 1일 프로젝트나 1개월짜리 프로젝트나 같다. 코딩은 거의 타이핑하는 수준이다. 그러니 단순한 오타 외에는 고칠 것도 없다. 코드를 적으면서 설계를 하는 것은 공사를 먼저 시작하고 빌딩 디자인을 하는 것과 같다. 이러한 방식은 개 집 만들 때나 가능한 방식이다. 모차르트가 작곡할 때 악보에 고친 흔적이 없다는 전설적인 얘기도 같은 맥락이다. 분석이 가장 극단적인 지식산업이고 코딩은 가장 노동 산업에 가깝다. 그 중간에 설계단계가 있다. "분석"은 모든 요소를 한번에 다 고려해서 일체성 있게 생각을 해야 하기 어렵다. 머리가 복잡해져서 아파오기 시작해도 중지할 수가 없다. 그만 두면 어차피 처음부터 다시 시작해야 하기 때문이다. 그래서 여러 명이 할 수 도 없다. 여러 명이 나누어서 할 수 있는 일은 노동산업 쪽에 가깝다.

번잡하게 일하면 열심히 일하는 것처럼 인정을 받는 한국 회사에서는 점점 더 많은 인터럽트가 발생하게 된다. 미국회사에서는 심지어 관리자마저도 자기 시간의 50% 이상 회의를 하고 있으면 도대체 언제 일하냐고 농담의 대상이 되는데 한국은 거의 80 - 90% 를 회의로 보낸다. 대부분이 계획과 분석 없이 정리가 되지 않은 상태에서 다중작업으로 인해 뇌 손상이 되고 기억력이 감퇴되니 묻고 또 묻고 하는 중복적인 보고가 벌어진다. 전문성이 없으니 근무 시간이 고과 평가에서 중요시 될 수 밖에 없다. "넓고 얕은 지식" 으로 무장한 한국의 관리자나 경영진들이 전문성이 없기 때문에 평가도 제대로 하지 못하는 상황에서 필연적인 결과이다. 소프트웨어 용어나 표면 지식으로는 전 세계의 어느 누구한테도 뒤지지 않는 것이 한국의 관리자나 경영진들이다. 용어에 관한 한은 박사 수준이다. 지식으로는 모를 것이 없겠지만 선수나 코치가 될 수 있는 것은 아니다. 그냥 관중 수준일 뿐이다. CTO라는 명함을 가지고 있어도 마찬가지다.

한국이 자랑하는 인천대교와 영종대교의 핵심 설계를 한국이 하지 못하고 일본의 조다이(長大)라는 업체가 맡았다. 한국의 토목 설계 전문가는 "이 회사의 하마지라는 기술자 한 명이 보유한 경험과 기술이 우리나라 교량 설계업체 전체를 합친 것 이상이라고 해도 과언이 아닐 것"이라고 했다. 이런 고부가가치 전문가는 다중작업자 환경에서는 절대 나올 수 없다. 그래서 페이스북의 창업자인 주커버그가 "개발자 한 명이 백 명보다 가치가 있다"라고 했다.

한국 회사의 근무환경은 수 많은 회의와 보고로 인해 단일작업자의 환경이 원천적으로 불가능하고 당연히 전문가는 나오기 어렵다. 그래서 한국 회사에서는 40세가 넘으면 연구결과대로 뇌가 손상을 입고 전문성 역량은 없어져 감원 우선순위가 되는 반면에 단일작업자인 실리콘밸리의 SW 개발자는 40세가 넘으면 회사의 핵심 인력이 된다. 회사에서의 감원 대상은 도파민에 중독된 "넓고 얕은 지식"의 다중작업자이다. 그렇게 된 데는 다중작업 환경을 만든 회사의 시스템과 그런 시스템을 만든 경영진이 전적으로 책임을 져야 한다. 실리콘밸리와 같이 백발이 성성한 개발자인 전문가가 존재하고 그들의 의견을 존중하고 전적으로 따르는 관리자들의 문화와는 전혀 다른 한국회사의 문화는 SW와 같은 극단적인 지식산업과는 궁합이 맞지 않는다.

조용한 환경에서만 생겨날 수 있는 단일작업자만이 진정한 SW 전문가가 될 수 있고 그런 근무환경을 만드는 것이 경영진이 해야 할 일이며 한국 SW 산업이 발전할 수 있는 핵심 필요조건이다. 그러기 위해서는 회사 문화뿐 아니라 분석 능력의 향상 그리고 조용한 개발환경에 필수불가결한 기반 시스템 구축이 우선되어야 한다.

2016년 6월 26일 일요일

분석 #6 왜 삼성개발자의 1-2%만 구글 개발자의 역량에 불과한가?



요새 삼성전자에서 SW 개발자 역량에 대한 자기 성찰의 기사가 나와서 화제거리가 되었다. 지금쯤이면 다 읽어 보았겠지만

"삼성전자 SW 엔지니어는 문제해결 능력에 대한 훈련을 많이 한 것 같지 않다. 지금 당장 문제해결 평가 방식으로 구글 입사를 시도 한다면 1~2%만 제외하고는 어렵지 않을까 생각한다." 라는 기사이다.

이는 너무 당연한 결론이며 삼성전자가 아닌 한국 소프트웨어 전체의 현상을 보여주는 것이다. 지금까지는 자아도취에 동키호테식 열정으로 진실을 외면하고 살아왔다면 이제 심각한 상황이 되면서 조금 눈치는 챘다고 볼 수 있다. 이는 개발자 자신들의 책임은 절대 아니다. 대부분은 회사와 경영진의 책임이긴 하지만 개발자들도 조금만 더 현명하게 기득권층과 선동가들에게 현혹되지 않았다면 지금보다는 나아질 수 있었다.

미국 SW 회사에서는 어려워져서 개발자 감원을 시킬 때 경력이 적은 사람부터 시킨다. 이름하여 오랜 경력자를 지키겠다는 정책으로 "Seniority"라고 한다. 그 이유는 상식적으로 너무 당연하다. 실력이 있기 때문이다. 회사에 오래 있었으니까 충성심을 고려해서 그런다고 생각하면 세상을 너무 모르는 순진한 생각이다. 그런 순수성은 존경할 만 하지만 세상 살아가는 요령은 약하다. CEO의 입장으로 바꾸어 놓고 생각하면 쉽게 이해가 갈 것이다. 어렵게 CEO가 되어서 자기도 실적을 내어야 살아남는데 실력없는 개발자를 단순히 회사에 오래 있었기 때문에 불쌍해서 살려주겠다고 생각할 CEO는 세상에 없다. 여기서 다양한 인사 정책을 논할 수는 없지만 기본적으로 핵심은 실력이다. 그 이외의 모든 인사 정책은 극히 작은 부분을 차지한다.

상황을 이해하기 쉽도록 인사 정책을 흑백논리로 생각해 보자. 모든 개발자를 40대 이후의 그룹과 40대 이전의 그룹으로 나누어 보자. 회사가 어려워져서 두 그룹 중 한 그룹을 감원시켜야 한다고 가정하자. 미국에서는 당연히 40 이전의 젊은 그룹을 감원시킨다. 40대 이후의 개발자가 다 없어지면 회사는 망한다. 한국 SW 회사에서는 40대 이후를 감원시키는 것이 옳다. 한국에서 40대 이후면 개발자가 아니고 거의 개발자의 탈을 쓴 관리자이다. 그러니 더욱 더 감원해도 문제가 안된다. 상식적으로 그렇고 사실이 그렇다. 그래서 필자가 개발자를 채용할 때도 대기업의 고참 개발자는 조심해서 본다. 개발자도 아닌 직원을 뽑아서는 할 일이 없을 뿐만 아니라 방해만 된다. 실제로 한국 회사에서 대부분의 젊은 개발자들은 위의 관리자나 임원들이 회사에 가치가 있다고 보지 않는다. 그들 만의 국지적인 관점일 수도 있지만 전세계 회사 평가 사이트인 glassdoor.com 에서 외국인들이 내린 평가를 보아도 한국회사들의 임원이나 관리자들에 대한 평가는 최악이다. 무지한 상태에서 엉뚱한 지시만 내린다는 평이다. 또 CEO를 인정하는가를 묻는 "Approve CEO"는 대부분 부정적이다. 이것은 필자의 추측도 아니고 부정할 수 없는 엄연한 사실이다. 전문성보다는 관리위주로 경영할 수 밖에 없는 최고경영진부터 회사가 그렇게 설정되어 있기 때문이다. 어떤 경우는 개발을 해 본 적도 없는 사람이 연구소장이나 CTO라는 직함을 가지고 있기도 하다. 외국에 나가서 어떻게 상대방과 대화를 할 수 있을지 의문이다.

필자도 지금까지 미국과 한국에서 기술자 경로에 있어 왔지만 미국 회사에서 개발자 경로에 있다보면 자기보다 나은 고수들의 공력을 느끼고 감탄하며 배운다. 반대로 30대가 되면 20대 신입이었을 때가 세상모르고 열정과 자신감으로 보낸 젊음의 시절이고, 40대가 되면 30대를 보고 이제 조금 SW를 알겠구나 하는 생각을 하게 되고, 50대가 되면 40대를 보고 이제 조금만 가이드해주면 일을 믿고 맡길 수가 있겠구나 하는 생각이 든다. 그래도 1,000명이 개발하는 거대한 제품은 백발이 성성한 개발자가 지휘해야 할 것이다. 한국이 자랑하는 인천대교와 영종대교의 핵심 설계를 일본의 조다이(長大)라는 업체가 맡았다. 1968년에 설립된 이래 전 세계적으로 20여개의 대형 교량을 설계한 경험이 있는 회사다. 한 토목 설계 전문가는 "이 회사의 하마지라는 기술자 한 명이 보유한 경험과 기술이 우리나라 교량 설계 업체 전체를 합친 것 이상이라고 해도 과언이 아닐 것"이라고 했다. 이런 기술자를 회사가 어렵다고 감원시키겠는가? 절대 아니다. 이게 바로 백발이 성성한 개발자의 실력에서 나오는 Power인 것이다. 애플 창업자인 스티브 워즈니악, 전 마이크로소프트의 Chief Scientist였던 레이 오지, 하둡의 창시자인 더그 커팅등 기술로는 전세계에서 누구도 따라갈 수 없는 기술자들이다. 다 60대 전후이지만 실리콘밸리에 가보면 이런 사람들이 수도 없이 많다. 그들이 바로 실리콘밸리의 숨은 힘이다. 요새 알파고로 갑자기 유행이 된 인공지능 분야에서도 세계적인 대가인 Geoffrey Hinton, Ray Kurzweil, Yann Lecun도 다 백발이 성성한 상태에서 구글과 페이스북의 인공지능 기술을 이끌어 가고 있다. 관리자가 아니다. 한국의 관료중심과 정치적인 환경에서는 절대 생겨날 수 없는 사람들이다. 조금만 유명해 지면 이런 저런 정부회의나 프로젝트등에 기웃기웃해서는 일단 시간이 모자란다. 기술은 멀어지고 점점 더 정치꾼으로 변해간다.

실리콘밸리의 기술자들은 서로 많은 기술 정보를 공유하고 협력하면서 실력이 급속히 늘어간다. 백발이 되어가면서 그들의 실력은 임계치를 넘은 폭발력으로 점점 더 가파르게 증가한다. 물론 육체적인 능력은 떨어지지만 종합적인 판단력이나 기술적인 결정은 회사의 운명을 좌우한다. 타이핑하는 속도는 20대를 따라갈 수 없다. 생각하는 시간이 많아지고 타이핑하는 시간이 줄어들기 때문이다. 그에 반해 한국은 조금만 경력이 생기면 팀장이라든가 해서 기술력의 전문성은 떨어지기 시작한다. 바로 죽도 밥도 아닌 Generalist가 탄생하는 순간이며 팀장이나 관리자의 권위를 즐기며 살아가는 것도 잠깐일 뿐 조금만 지나면 생존을 염려해야 한다. 회사가 관리위주의 경영을 하기 위해 개발자를 관리직으로 내몰면서 가치를 감소시켜 놓고 연봉은 높아지고 그러니까 감원의 첫째 대상이 된다. 이렇게 된 원인은 최고경영진부터 임원 등 그 위에 있는 사람들이 역시 비슷한 사람들이기 때문에 그들에게 업무 보고하고 지시 받기 위해서는 상대가 같이 "무지한" 수준이어야 하기 때문이다. 깊이가 없으니 똑같은 얘기를 반복적으로 하기도 하고 답하기도 한다. 그러니 보고가 많아지게 된다. 필자가 누누이 얘기 하지만 보고가 많다는 것은 망가진 회사의 전형적인 증상 중의 하나이다.

기술자가 일하는 환경은 번잡스러운 회의가 없는 조용하고 집중할 수 있는 환경이어야 한다. 이 점을 또 오해하는 경우가 많은데 고립해서 일하는 것은 절대 아니다. 개발자들이 마음대로 개발하는 환경을 만들어 주었다고 자랑하는 한국 회사들도 있는데 대부분의 그런 회사는 관리위주의 회사보다 더 빨리 망한다. 공유와 협업을 조용하게 할 수 있는 기반 시스템이 마련되어 있지 않은 상태에서는 일인회사에서나 적합한 방식이기 때문이다.

한국회사의 두가지 문제인 관리위주 혹은 고립된 연구 스타일 모두 글로벌 개발자가 생겨나기에는 열악한 환경이다. 구글로 대변되는 글로벌 회사에서의 "문제해결(Problem Solving) 능력"이라는 것은 한국에서 생각하는 코딩 능력도 아니고, 프로그래밍 언어를 많이 아는 것도 아니고, 프로세스도 아니고, MVC와 같은 Framework를 많이 아는 것도 아니고, 많은 도구를 사용한 경험도 아니고, Agile과 같은 개발방법론을 아는 것도 아니다. 이런 잡다한 기법들이 이력서에 잔뜩 적혀 있는 것이 한국 개발자들의 통상적인 이력서인데 그런 것들은 놀랍게도 미국회사의 인터뷰시에 물어보지도 않는다. 그런 것들은 어차피 수시로 생겨나고 없어지고 하는 것이기 때문에 가치도 없고 신경도 쓰지 않는다. 진정으로 필요한 장기적이고 영속적인 문제해결 능력을 보는 것이다. 한국에서 그토록 맹신하는 Agile 방식도 이미 "Agile is dead" 라고 Agile을 창시한 사람들 조차도 문제점을 지적하면서 죽었다고 선언한다. 그런 것들은 필요에 따라 혹은 유행따라 어차피 순식간에 배워서 사용하다가 생명이 다하면 버리고 하는 것이 개발자의 인생이기 때문에 핵심 가치는 절대 아니다. "문제해결능력"에는 핵심은 아니지만 그런 것들을 순식간에 배워서 사용할 수 있는 능력이 당연히 포함되어 있다. 어떤 컴퓨터 과목에서는 한 학기에 전혀 모르는 여러가지 언어를 사용해서 숙제를 해야 하는 경우도 많다. 초보때나 기본적인 개념을 배우기 위해 프로그래밍 언어를 한 과목에서 배우지 그 다음에는 하루 이틀안에 배워서 교과 과정을 따라가야 한다. 필자도 Coursera에서 Machine Learning 코스를 들었을때 Matlab 프로그래밍을 처음 접했지만 몇시간 교육 후에 전혀 문제없이 교과 과정을 따라갔다. 물론 경험자보다는 약간 시간이 더 걸리겠지만 그 정도는 역량의 차별화가 되지 않는다. 삽들고 땅파는 능력이 중요한 것이 아닌 지식산업이기 때문이다.

그럼 그런 국지적인 기법이 실력의 차이가 아니라면 그렇게 글로벌 회사들이 주장하는 "문제해결능력"이란 무엇인가? 여기서 글로 답을 주기는 쉽지 않다. 불가지론이나 형이상학과 같이 차원이 다른 것을 이해하기가 어렵기 때문이다. 모든 사람들에게 쉽게 이해시킬 수 있었다면 한국 소프트웨어가 과거 20년을 이렇게까지 열악한 환경이 되도록 허송세월 하지는 않았을 것이다. 바로 베스트셀러였던 칩 히스의 "지식의 저주" 이다. 먼저 깨달은 사람이 깨닫지 못한 사람에게 설명하는 것은 너무 어렵다는 것이다. 예를 들어 5년전 만 해도 SVN이나 Git와 같은 소스코드관리시스템을 사용하지 않고도 개발하는데 전혀 문제가 없다고 주장하는 개발자들이 많았다. 지금은 개발자들이 거의 깨달았겠지만 소스코드관리시스템 없이 개발한다는 것은 불가능하다. 너무 어처구니 상황이지만 깨닫지 못한 본인들은 전혀 눈치를 못채고 있었을 뿐이다. 그런데 지금도 이슈만 바뀌었지 똑같은 상황이 계속되고 있다.

"문제해결 능력" 이라는 것은 해결해야 할 문제가 주어졌을 때 종합적으로 여러가지 관점에서 생각하고 또 생각해서 가장 좋고 빠른 방법을 찾아내서 개발하는 것이다. 즉 Top-down으로 생각하는 능력이 기본이다. 이것을 바로 분석역량이라고 한다. 분석을 잘하기 위해서는 수 많은 기법을 동원해서 할 수도 있고 전혀 기법이 없이 수행할 수도 있다. 기법을 몰라서 분석을 못하거나 문제해결을 못하겠다면 그건 Technician이다. 템플릿이나 형식과 같은 기법으로 생각하는 순간 분석은 물 건너 갔다. 시간만 낭비하고 그냥 잘 되어야 숙련공일 뿐이다.

문제해결 능력을 테스트하는데 프로그래밍 언어 테스트는 당연히 하지 않는다. 사실 프로그래밍은 개발에서 마지막 단계에 위치해 있는 시공 능력이다. 필자는 학교숙제를 비롯해 어떤 개발을 하더라도 코딩 시간을 20% 이상 할애하지 않으려고 한다. 가끔 전혀 모르는 언어를 사용해서 개발하거나 생소한 분야의 개발을 해야 할때는 50% 까지도 코딩 시간이 늘어날 수 있지만 기본적으로 대부분의 시간을 분석, 그 다음에 설계에 시간을 들인다. 이 방법이 가장 빠르고 품질 좋은 제품을 만들어 낼 뿐 아니라 1,000명의 개발자가 같이 개발을 해야 하는 경우에는 필수적이기 떄문이다. 한국에 Agile이 소개되었을 때 Top-Down에 대한 악영향을 걱정했었는데 역시 Top-Down 방식에 대한 반론을 위한 합리화에 많이 사용되고 결국은 한국 소프트웨어 역사에서 좋은 결과를 가져오지는 않았다. 그런 면에서 실리콘밸리에서는 대부분의 개발자들이 용어조차도 모르는 CMMI도 한국에 와서 좋은 점 보다는 나쁜 영향을 주었다. 1% 도 아니고 0.1% 의 회사에서나 필요한 것을 모든 회사에 적용할 수는 없다. 시금치가 건강에 좋다고 온 국민 식단에 시금치를 사용한 것과 다를 바 없다.

이런 문제해결 능력은 좋은 환경에서 지식을 공유하면서 점점 더 성장하게 되는데 소프트웨어에 관한한 "구경꾼" 수준에 불과한 Generalist 경영진들과 그런 회사에서 성장한 개발자들이 그런 능력을 가지기는 어렵다. 그래서 "1-2% 밖에 없다" 라는 평가가 나오는 것은 너무나 당연한데 필자가 보기에는 현재 상태에서는 1-2%도 발견하기 어렵다. 차라리 문제해결 능력은 관리와 기법위주의 대기업보다는 벤처기업에서 아직 물들지 않은 개발자 중에서 찾기가 더 쉽다. 스스로가 아키텍트이며 고급 개발자라는 것을 증명하려면 Coursera 같은 곳에서 자기가 관심있는 분야의 강좌를 다른 개발자보다 몇 배 빨리 끝낼 수 있어야 한다. 한국 회사에서 "팀장", "부서장" 등 "장'이라는 직함을 가지고 있는 사람들은 관리자이지 SW 개발자가 아니다.

소프트웨어 개발자의 최고 능력은 바로 분석능력이며 그게 바로 글로벌 회사에서 가장 중요한 가치인 '문제해결 능력" 이다. 경험하기 전에는 이해하기도 어렵고 교육으로 가르치기는 불가능한 형이상학의 영역이다. 삼성이 고맙게도 자체평가를 통해 공식적으로 이슈를 알게 했으니 이 기회에 깨닫고 실천하는 중요한 계기가 되기를 바란다.


2016년 5월 5일 목요일

분석 #5 Coursera에서 소프트웨어 공학 최고의 스승을 만나보자


요즈음 교육 방법으로 매우 편리한 MOOC(Massive Open Online Course) 라는 방식이 있다. 언제 어디서나 원하는 강의를 들을 수 있는 온라인 강좌서비스인데 강좌 자료만 올려 놓는 가장 원시적인 것부터 실제 전세계 최고의 대학 강좌와 거의 비슷하게 체험할 수 있는 것까지 다양한 수준이 있다.

전세계 MOOC중에서 가장 유명한 사이트가 Coursera (https://www.coursera.org) 이다. Coursera 에서 가장 많이 듣는 강좌가 Stanford 교수인 Andrew Ng의 기계학습(Machine Learning) 코스이다. Andrew Ng 교수는 Coursera의 창시자이기도 하고 인공지능 분야의 대가 중의 한 명인데 얼마 전에 구글에서 바이두로 옮겨 인공지능의 책임자인 Chief Scientist로 있다. 이 강좌는 Stanford 대학원의 정규 코스이기도 하다.

필자가 수년 전에 Market Segmentation으로 Machine Learning을 했었는데 알파고의 홍보효과로 한국에서는 갑자기 대중에게 유행이 되었지만 이미 전세계에서 미래의 핵심 기술로 자리 잡은지 오래이다. 구글, 페이스북, 마이크로소프트, 애플, 바이두 등 전세계 모든 기업들이 사운을 걸고 엄청나게 투자를 하는 분야이다. 필자가 Stanford에 입학할 당시에는 인공지능의 실현 가능성에 문제가 제기되던 시절이라 전공으로 선택하지는 않았는데 그 후 30년이 흐르면서 많은 변화가 있었다. 특히 Geoffrey Hinton 교수의 획기적인 발견과 GPU 연산능력의 발전으로 과거의 문제들이 해결되면서 이제는 의심의 여지없이 미래 모든 산업의 핵심기술이 되었다.

필자도 이 기회에 여러가지 목적으로 Andrew Ng 교수의 Machine Learning 강좌를 들었다. 가장 큰 목적은 한국의 개발자들이 이 코스를 들을 때 직면할 문제점을 발견하고 조언을 하기 위해서 였다. 이전에 학생이었을 때 듣던 거의 유사한 교육 방식의 코스이기 때문에 필자는 전혀 거부감이나 당황감 없이 들을 수 있었다. 주중에는 시간이 없으므로 주말에 밤새우다시피 하면서 11주 코스를 6주만에 빨리 끝냈다. 하지만 쉽게 통과하기 쉽지 않은 코스라는 것을 밝혀둔다.

이 강좌의 가치는  Machine Learning을 배우는 것 이외에도 다음과 같은 3가지 혜택이 있다.

첫째, 대학 교육방법의 Role Model을 보여준다.
둘째, 실리콘밸리 회사에서 어떻게 일하는 지를 가르쳐 준다.
셋째, 분석이 무엇인지를 몸에서 느끼게 저절로 가르쳐 준다.

이 강좌를 듣는 방법에는 3가지가 있는데 첫째로 그냥 동영상 강의만 듣는 것이다. 즉 청강이다. Class당 1시간 20분 정도의 동영상 11개 이니까 동영상만 듣는다면 대충 15시간이면 끝난다. 둘째 방식은 가끔 나오는 Quiz를 이해하고 풀면서 듣는 것인데 강좌을 다시 듣고 잘 이해해야 하는 부분이 있으므로 조금 시간이 더 걸린다. 20시간으로 잡자. 거의 모든 개발자가 기초만 있으면 통과할 수 있는 수준이다. 마지막 셋째는 프로그래밍 숙제를 해야 하는 방식이다. 숙제를 모두 끝내야 Course Certificate을 발행해 준다. Certificate만 받지 않으면 모두 무료 강좌이다. 개발자의 수준에 따라 다르겠지만 필자의 경우에는 약 100시간 걸렸다. 시간으로 보면 Quiz까지 푸는 방식과 숙제까지 하는 방식에서 5배의 차이가 난다. 하지만 배우는 역량은 5배가 아니라 10배, 100배의 가치가 있다. 청강이나 Quiz를 푸는 방식으로는 진정으로 개발자가 배워야 하는 것은 전혀 배울 수 없다. 그냥 얉은 표면적인 지식만 임시적으로 쌓일 뿐이다. 즉 골프는 쳐보지도 않고 골프 동영상 강좌만 들은 것과 같다.

그럼 이 강좌의 Certificate을 받기 위한 과정에서 개발자들에게 어떤 중요한 가르침을 줄 수 있는지 보자. 핵심은 프로그래밍 숙제이다. 프로그래밍 숙제를 모두 통과하지 못한다면 이 코스를 완성했다고 인정할 수 없다. 훈수나 두는 잡다한 지식 수준이다. 그럼 프로그래밍 숙제가 어떻게 나오는 지를 살펴보자. 한국의 대학교수들이 꼭 배워야 할 점이기도 하다.

첫째, 모든 숙제의 설명이 양적으로 작은 책자처럼 나온다. 그것을 다 읽고 완전히 이해해야 한다. 한 부분이라도 이해하지 못한 상태에서 대충 어떻게 되겠지하고 숙제를 하려고 시작하면 고생은 고생대로 하고 시간이 더 든다. 여기서 개발자가 배워야 할 기본 원칙이 나온다. "무엇을 할 지를 모르면서는 코딩을 시작하지 말라"는 것이다. 백가지 이유를 들면서 일찌감치 코딩에 뛰어드는 한국의 통상적인 개발자는 아무리 얘기해도 실감하기 어려운 것인데 강좌를 들어보고 경험해 보면 백문이 불여일견이라고 이해가 갈 것이다. 즉 "코딩을 일찍 시작하면 개발시간이 더 걸린다" 는 소프트웨어 공학의 #1 원칙을 배울 기회이다. 폭포수모델이니 애자일 방법론과는 전혀 상관이 없는 기본 원칙이니 방법론과 착각하지 말기 바란다.

숙제가 정의되어 있는 상세함을 보면 무엇을 프로그램해야 하는 지 정확하게 정의되어 있다. 숙제 설명 중에 쓸데 없는 단어도 없고 모든 단어가 필요한 만큼 잘 사용되어 있다. 바로 "완벽한 SRS"인 것이다. SRS의 형식이 중요한 것이 아니라 문제를 정확히 정의하는 것을 확실히 볼 수 있다. 이 숙제 설명 중에 한 부분이라도 이해 없이 넘어가면 꼭 문제가 되고 결국 다시 와서 이해하기 전에는 숙제를 완성할 수 없다. 이런 식으로 매 과목마다 완벽한 SRS를 기반으로 숙제를 하고 교육을 받다 보면 SRS를 어떻게 작성해야 하는 것을 저절로 배우게 된다. 자신이 다른 사람에게 어떤 일을 부탁할 때나 개발 프로젝트 발주를 할 때도 그렇게 적어야 한다는 것이 몸에 배게 되는 것이다. 자신도 모르는 사이에 문제를 정의하는 방법, 즉 "분석" 능력을 배우게 된다.

문제를 정확히 정의하는 것과 창의성과는 전혀 별개의 문제이고 둘 다 모두 가장 중요한 개발자의 역량이지만 여기서는 창의성을 설명하지는 않는다. 정확히 정의된 문제 안에서 창의성을 발휘하는 것 정도로 알아 두자.. 불행히도 한국에는 이런 수준의 숙제를 디자인하고 만들수 있는 교수가 거의 없다. 학교에서 잘 가르쳐야 한다고 요구해야 정치교수, 관리교수들 처럼 실무 역량을 상실한 교수들에게는 이런 코스 디자인 역량이 있을 수 없고 공허한 메아리만 될 뿐이다.

또 중요한 것이 숙제를 채점하는 방식이다. 온라인 사이트로 숙제를 프로그램 채점기에 제출하면 즉시 자동으로 채점이 되어 나온다. 채점은 항목별로 Pass/Fail (통과/실패)로 나온다. 모든 항목을 100% Pass 해야만 숙제가 통과된다. 여기서 소프트웨어 개발 프로세스에서 나오는 Acceptance Test Plan(ATP, 인수테스트) 라고 하는 핵심 개념이 나온다. ATP만 통과하면 개발이 완료되고 계약은 종료된다. 발주시 미리 약속한 ATP만 통과하면 발주자가 어떤 트집도 잡을 수 없다. 이런 정교한 ATP가 없는 한국에서는 절대 경험해 볼 수 없는 것이다. 대학의 과목에서도 따라하는 소프트웨어 개발의 기본을 한국의 소프트웨어 업계에서는 한 번도 경험해 본 적이 없다는 것은 슬픈 현실이다. 그러면서 소프트웨어 공학을 논할 자격이 있는지도 의문이다.

프로그래밍 숙제의 내용에 대해 정확히 정의되어 있고, 채점도 Pass와 Fail이 자동으로 나온다. 무슨 편법을 사용하더라도 채점 프로그램만 통과하면 통과한 것이다. 하지만 하드코딩을 한다거나 편법으로 채점기를 속이는 것은 불가능하게 디자인 되어 있다. 프로그램을 제대로 하지 않는 이상은 절대 채점기를 통과할 수 없게 만들어져 있으니 시간 낭비 하지 말고 처음부터 제대로 하는 것이 현명하다. 여기서 주지할 것은 채점기가 얼마나 정교하게 잘 되어있는지도 중요하지만 더 중요한 것은 숙제 설명과 함께 동시에 채점기가 나온다는 것이다. 이것을 소프트웨어 산업에서 비교하자면 숙제의 정의는 SRS이고 채점기는 ATP (인수테스트)인 것이다. 소프트웨어 공학에서 당연하게 SRS와 ATP(인수 테스트)가 동시에 나오는 기본 원칙을 보여주는 것이다. SRS와 ATP 있어야만 합리적이고 정상적인 개발 계약이 가능하다. 이런 기본적인 프로세스를 한 번도 해 본 적이 없다는 것은 한국 소프트웨어 업계의 실체와 수준을 적나라하게 보여준다.

한국에서의 프로젝트 발주와 수주의 기본 프로세스인 "RFP (제안 요청서) -> Proposal(제안서) -> 우선협상대상자 계약 -> 개발범위 논의 -> 등등" 의 어디에서 과연 내가 돈을 주고 발주를 하든 돈을 받고 수주계약을 하던 계약 전에 무엇을 개발하는 지와 인수테스트를 정확히 알 수 있는 시점이 없다는 점이다. 무슨 근거로 애초에 이런 개발방식이 생겨났는지는 안타까운 과거의 행위이지만 앞으로 한국 소프트웨어 업계가 넘어가야할 가장 큰 장애물이다. 하여튼 이 잘못된 관행은 프로젝트 규모의 문제가 아니라 기본이 안 되어 있기 때문인 것이다. 규모가 크기 때문에 학교의 과목보다도 더 정확히 하지 않으면 재앙은 더 커진다.

마지막으로 말하고 싶은 것은 이 과목에서는 Matlab 이라는 프로그래밍 언어를 사용한다. 필자는 이 전에 한 번도 Matlab을 사용해 본 적이 없다. 하지만 배워서 이 숙제를 해야 한다. 강좌에서도 한 30분 정도 가르쳐 준다. 다른 과목에서는 Python으로 숙제를 해야 한다. 이 역시 학생들이 알아서 배워야 한다. 이런 프로그래밍 언어는 학원에서는 가르칠지 모르지만 학교에서 귀중한 학점을 낭비하면서 따로 가르치지는 않는다. 중요한 것은 문제해결 능력이지 프로그래밍 언어의 Syntax가 아니기 때문이다. 이런 Syntax를 가르칠 만큼 한가한 학교라면 그 학교에서는 많은 것을 배우지 못할 것이다. 한국 개발자의 이력서에 빼곡히 적힌 프로그래밍 언어 목록에 대해 필자는 그렇게 가치를 두지 않는다. 실리콘밸리에서 개발자를 뽑을 때도 그랬고 지금도 그렇다. 이런 모든 상황 때문에 한 학기에 프로그래밍이 숙제로 있는 코스를 1개 이상 수강한다는 것은 거의 사생활을 포기한 것이나 다름 없다. 그래서 전산학을 하면서 Full-time 학점인 학기당 12학점 이상을 듣는다는 것도 거의 불가능하다.


이 강좌 하나에 한국의 정부, 학교, 회사, 개발자등 소프트웨어 업계가 배워야 하는 Role Model이 모두 들어 있다. 과연 이런 강좌를 한국에서 언제 보게 될 수 있을 지가 궁금하다. 그 때가 아마 한국의 소프트웨어 업계가 진정으로 소프트웨어를 이해하는 시점이고 글로벌 소프트웨어를 위해 나갈 수 있는 시작점이라고 본다. 그 때까지는 한국의 갈라파고스 섬에서 자화자찬하며 살아갈 것이다.

미래의 핵심 역량인 Machine Learning을 배우면서 추가로 소프트웨어 공학의 핵심을 저절로 배우는 기회를 위해 필자가 개발자들에게 꼭 추천하는 강좌이다.