2020년 8월 2일 일요일

인공지능이 개발자의 48%를 대체한다

 

인공지능(AI)이 무서운 속도로 발전하고 있다. 불과 4년 전에 바둑에서 구글의 알파고가 인간의 자존심을 깨트렸는데 지금은 점점 더 차이가 벌어져 AI가 인간의 대국을 평가하는 상황이 되었다. 자동차의 자율 주행도 완전 자동화 단계인 무인자동차가 시험주행 중이다. 테슬라는 올해 안에 무인자동차를 완성시키겠다고 한다. 머지 않아 운전면허증이 필요 없는 세상이 오고 미국에서만 500만 명이 실직될 것이라고 예측한다.


홍콩의 핸슨 로보틱스라는 회사가 인간 신경계 모델을 기반으로 해서 만든 인간형 로봇 소피아는 사우디아라비아에서 시민권까지 부여 받았다. 인터뷰 동영상을 보면 자아, , , 사랑 등 다양한 주제에 대해 보통 인간보다 더 성숙한 대화를 한다. 노래도 하고 농담도 한다.


그런 AI가 소프트웨어 산업에 속한 직업을 얼마나 대체할 수 있을까?

AI가 직업에 끼치는 영향에 관한 옥스퍼드 대학의 연구 미래의 직업(The future of Employment)” 보고서에 의하면 미국의 대표적인 702개 직종 중 47%가 일이십년 내에 자동화되어 인간을 대체할 수 있다고 한다. 그 중에 가장 위험성이 큰 직업이 98%의 대체율인 운전사이다. 반대로 가장 대체가 어려운 직종 중의 하나가 1.5%의 대체율인 CEO이다. 다른 대체율을 보면 내과의사는 0.4%, 학교선생은 1%, 변호사는 3.5%, 회계사는 94%, 건설노동자는 88%이다.

 

그럼 702개 직종 중 소프트웨어에 관한 직업만 추려서 보자.

 

대체율(%)

직종

0.65

시스템분석가

1.5  

컴퓨터과학자

3    

네트워크/시스템 관리자

3.5  

정보 시스템 관리자

4.2  

응용프로그램 개발자

13    

시스템 소프트웨어 개발자

21    

정보보안 분석가

21    

웹 개발자

21    

네트워크 아키텍트

48    

프로그래머

 

 이 결과를 보면 "시스템분석가" 0.65%의 대체율로 대체가 거의 불가능하다. 가장 대체하기 쉬운 "프로그래머" 48%로 반이 없어진다. 중간의 "웹 개발자"20%의 대체율을 보인다

 

그럼 "시스템분석가", "개발자" "프로그래머"의 차이는 무엇일까? 사실 국내에서는 이 차이를 정확하게 구별하고 채용하는 회사도 없거니와 실제 회사 안에서도 이렇게 나누어져 있지도 않다. 국내 소프트웨어 산업자체가 이런 구분을 정확하게 하고 있지도 않다. 경력기간으로 분류하는 것은 잘못이다. 사병은 평생가도 장교가 되지 못한다. 하는 업무가 다르기 때문이다.


 주로 국내 대기업에서 보듯이 수많은 템플릿의 거대한 방법론을 가져다 놓고 템플릿 채우는 방법을 교육시키는 상황에서는 AI가 대체하기 쉬운 기계적인 환경이다. 템플릿 채우는 사람을 분석가라고 이름을 붙이는 것은 진짜 분석가에 대한 모욕이나 다름 없다. 분석가는 템플릿이나 방법론과 상관 관계가 전혀 없다. 그런 것들은 결과로 나타나는 하나의 표현 방법인 것이다. 템플릿은 생각의 자유를 제한하지만 공유하기 위해 사용하는 규칙에 불과하다. 템플릿을 많이 강제화하면 할수록 훌륭한 분석가의 역량을 사용하는데 방해가 된다.


 분석가는 템플릿이나 방법론으로 규정할 수 없는 순수한 두뇌활동의 종합예술이다. 타이피스트와 소설가가 다른 것과 같다. 템플릿과 가깝게 일을 한다면 그건 프로그래머에 가까운 일을 한 것이다. CEO도 마찬가지로 종합적인 판단을 하는 면에서 분석가와 같다. 당연히 CEO가 사용할만한 템플릿이나 방법론이 있을 수가 없다.


 그럼 반대의 극단으로 방법론 같은 것 전혀 없이 벤처기업에 존재하는 1인 영웅개발자의 직종은 무엇인가? 일단 프로그램을 해서 소스코드라는 결과를 만들어 내니까 일부 프로그래머에는 틀림 없다. 분석가라고도 주장하려면 분석한 결과가 있어야 한다. 어떤 행위를 했는데 아무런 결과가 없으면 그런 행위자라고 할 수 없다. 결과가 머리 속에 있다고 얘기할 지 모르지만 그런 것은 자아도취의 몽상가이다. 결과를 모두 건너 뛰고 소스코드를 적어낸다면 그건 영원한 1인 영웅개발자이고 회사 초기에만 잠깐 필요할 뿐 회사가 발전하는 데는 심각한 장애가 된다.


여기서 가장 어려운 것은 분석가, 개발자, 프로그래머의 역량을 구별하는 것이다. 물론 한 사람이 여러 역할을 하느냐 아니냐는 회사 규모와 처한 환경에 따라 다르지만 역량은 분명히 다르다. 요새 나온 신문기사 중에 대규모 외주 개발을 분할발주를 하는데 1단계 분석과 설계, 2단계 구현으로 나누어서 발주를 하겠다는 말이 있는데 이는 아직 분석, 설계, 구현을 전혀 이해하지 못해서 벌어지는 국내의 기이한 현상이다. 이런 식의 분할 발주는 국내를 제외하고는 전세계에 존재하지 않는다. 논리적으로도 존재할 수가 없다. 분할발주는 1단계 분석단계와 2단계 설계/구현 단계로 하는 것이 옳다. 분할발주에 대해서는 이전 기사들에서 누누이 설명했기 때문에 여기에서 또 설명하지는 않는다. 1단계 분석단계가 바로 분석가가 수행하는 작업이다. 2단계에는 개발자와 프로그래머가 섞여 있다. 분석가는 당연히 같은 경력기간의 프로그래머보다 연봉이 10배 정도 높을 수도 있다.


하여튼 국내 소프트웨어의 잘못된 관행이 빨리 없어지기 위해서는 먼저 본질에 대한 정확한 이해가 필요하다. 본질에 대한 정확한 이해 없이 표면적인 증상처방의 단세포적인 법규로 대응해야 과거 20년 이상 그랬듯이 점점 더 깊은 웅덩이로 빠질 뿐이다.


옥스포드의 결과에서 왜 AI가 프로그래머의 반을 대체하지만 분석가는 거의 없어지지 않는지의 이유를 심각하게 생각할 필요가 있다. 자신이 프로그래머라는 사실 자체도 인지하지 못하고 있을 수도 있다. 회사에 자기가 없으면 안된다는 생각도 대부분은 매우 위험한 착각이다. 하여튼 장기적으로 소프트웨어 관련 산업에 종사할 개인들로서는 자신의 직업의 본질과 그 위험성을 알고 현명하게 대처하는 것이 중요하다.


2020년 6월 29일 월요일

“SW 과업 변경 분쟁의 가장 큰 요인은 불명확한 RFP다” 는 거짓말이다




“SW 과업 변경 분쟁의 가장 큰 요인은 불명확한 RFP 는 기사가 요새 나와서 진실을 분석해 보려고 한다.

국내 소프트웨어 업계, 특히 SI 업체가 수십 년간 가지고 있는 고질적인 문제가 사양이 명확하지 않다 는 것이다. 법원에서 벌어지는 SW 소송의 99%가 바로 이 문제다. 한쪽은 사양이 추가되었기 때문에 돈을 더 달라고 하고 한쪽은 원래 계약에 다 포함되어 있는 내용이라는 주장이다. 그럼 모든 사람이 다 경험하고 잘 알고 있다고 생각하는 이 문제가 왜 몇 십 년간 해결되지 않고 있는 것일까? 소위 SW 전문가라는 사람들과 정부가 나서서 해결해 보겠다는 노력을 많이 했지만 SW산업진흥법 등 메뉴만 바꾸어 가면서 허송세월만 보내 왔다. 한 걸음도 더 나아가지 못하고 점점 더 엉뚱한 산으로 올라가고 있다.

먼저 전문가라는 그룹의 특성을 아는 것이 중요하다. SW가 아니더라도 모든 분야에서 전문가들 사이에서도 의견을 달리한다. 그리고 전문가는 자기가 주장하는 분야에서 사업이나 권력 등 경제적인 이권에 예외 없이 깊이 연관되어 있다. 즉 전문가의 발언은 자기의 이익을 대변하는 말일뿐 진실을 알건 모르건 자신에게 해로운 얘기를 하지는 않는다. 이런 곡학아세가 전문가의 본질이다. 모든 왜곡과 선동에는 전문가가 끼어든다. 전문가의 말이라고 믿는 것도 매우 위험한 것이다. 심각한 병에 걸렸을 때도 두번째 의견, 세번째 의견을 받아보고 결국은 스스로 결정해야 한다. SW 전문가라고 하는 사람들도 자신의 이익을 위해 편견을 주장한다. 이런 부도덕한 사람들이 생존력은 좋다는 것이 바로 리차드 도킨스의 이기적 유전자이다. 대중에게 좋은 것과 자신의 생존을 위해 좋은 것은 다르다.  암세포와 같은 이기적 유전자가 생존력은 가장 높다는 것이 인류가 걸어온 길이고 나 자신이 태어날 수 있었던 이유도 이기적 유전자의 후손이기 때문이다.

그럼 “SW 과업 변경 분쟁의 가장 큰 요인은 불명확한 RFP에 대해서 조금이라도 더 잘 이해하기 위해 거짓과 진실을 알아보자.

먼저 “RFP가 불명확하다는 문장이 있는데 이 것은 우주의 진리이다. RFP는 본질적으로 명확할 수도 없고 구체적일 수도 없다. 이런 우주의 진리를 기반으로 잘못 유추된 결론이 “SW 과업분쟁의 원인이다라는 것이다. RFP가 불명확해도 글로벌 회사들의 계약에서는 분쟁이 생기지 않는다. 국내에서 만연된 분쟁일 뿐 원인과 결론의 인과 관계가 성립하지 않는다. 즉 완전히 잘못된 결론이다. 다시 말하지만 명확한 RFP”는 필자의 SW 경험상 본 적도 없고 그럴 수도 없다. 그런 존재하지도 않는 것이 원인이라는 착각에서는 어떤 행동을 해도 문제 해결이 불가능하리라는 것을 추측할 수 있다.

SW 과업분쟁의 원인은 “RFP가 불명확한 것이 아니라 사양이 불명확하기 때문이다. RFP와 사양의 차이를 이해하기 쉽게 하기 위해 사양이라는 추상적인 단어 대신에 여기서부터는 Spec 혹은 Specification이라는 용어를 사용하기로 한다. RFP에는 Spec이 적히지도 않고 적힐 수도 없다. 필자가 다른 기사에서도 누누이 얘기했지만 이 차이를 진정으로 이해하고 있는 사람은 국내에 몇 명 밖에 안 되는 극히 소수에 불과하다. 글로벌 업체와 심각하게 과업분쟁을 직접 경험한 기회가 있었던 회사인 경우에만 진정한 자아인식(Meta-Cognition)이 생긴다. 지금까지 필자의 경험으로 자아인식을 한 회사는 하나 밖에 없다. 자아인식을 하면 반은 해결된 것으로 다행이다.

RFP를 보고 개발비용이 계산된 제안서를 낸다는 경우는 국내 SW 업계에서만 벌어지는 현상이다. 혹은 국내 SW업계가 관련된 국내 회사의 외국지사와 관련된 경우이다. 결국 표면적으로만 외국이지 모두 국내 SW 업계의 관행이다. 국내 회사의 외국지사에 SW를 판매하고 글로벌 매출이라고 주장하는 것도 업체들이 많이 사용하는 홍보수단이다. 반면에 글로벌 회사에의 매출이 대부분인 베트남의 FPT Software와 같은 SW 업체가 글로벌 고객을 상대로 사업을 하면서 몇 십 년간 글로벌 방식을 배워 왔다. 지금은 인도와 함께 전 세계 SW 개발 아웃소싱의 양대 축으로 성장했다. 글로벌 SW 개발 아웃소싱 시장 에서는 베트남이 아직 시작도 못한 국내 SW 업체보다 훨씬 앞서 있다.

RFP를 보고 제안서를 내는 국내 방식이 생겨난 이유는 소위 국내 SW전문가들이라는 사람들이 어디선가 비슷한 관행을 베껴왔을 때 가장 중요한 한 문장을 빼 먹었기 때문이다. 예를 들어 미국 정부의 SW 사업 신청 사이트에 보면 제안서에 SRS가 첨부되어 있거나 분할발주인 경우 SRS를 적기 위한 제안서를 낸다. SRS에서 Spec을 적어야 한다.  분할발주인 경우 SRS의 본질을 이해하지 못하는 상태에서 분할발주 흉내만 낸다고 제대로 될 수가 없다. 분할발주 정책도 산으로 가는데 그 이유에는 수 많은 요소들이 얽혀 있기 때문에 여기에서는 생략한다. “SRS를 누가 적는가?”의 추가 이슈도 책 한 권이 필요한 이슈이기 때문에  여기서는 생략한다.

SRS를 얘기하기 시작하면 국내에서는 SOW, 기능명세서, MRD, PRD 등 목적도 다른 문서들을 SRS와 동일하게 착각할 수 있으나 이는 SW 기획/개발 프로세스를 전혀 이해하지 못하는 무지의 소산일 뿐이다. 테니스를 얘기하는데 탁구라고 생각하는 경우와 비슷하다. 실제 필자가 부딪치는 많은 고참 개발자들이 그렇게 착각하고 있고 그들을 이해시키기는 많은 시간이 필요하고 그들의 생존에 관련된 이해관계까지 절충을 하는 것은 불가능에 가깝기도 하다. 자신들이 쌓아온 잘못된 경험이 환상의 매트릭스에서 전문가로 인정받으며 살아가는 핵심 자산인데 그를 포기한다는 것은 불가능하다. 바로 이기적 유전자에서 나오는 생존을 위한 자연스러운 행동일 뿐이다.

SRS에 관해서는 IEEE SWEBOK도 이 블로그에 이미 번역과 해설을 해 놓았고 책에서도 많이 얘기했기 때문에 여기서 반복할 필요는 없다. 확실하게는 적절한 SRS가 없이는 SW 과업 변경 분쟁은 국내에서 없어질 수 없다는 것이 진리이다. SW 개발 SI 계약이 회사와 회사 사이이면 계약과 소송으로 진행되겠지만 회사 내부에서 발생되는 경우는 그냥 일정 연기, 비효율성, 난잡한 개발 등으로 나타난다. 그러니까 또 이런 일정 문제를 해결하겠다고 프로젝트관리 기법을 도입하기도 하지만 이는 다 엉뚱한 데다 원인을 덮어씨우는 무지에 불과하며 결국 돈만 낭비하고 더 큰 비효율성을 만들어 낸다.

그럼 “SRS는 어느 정도 자세히 정확하게 적어야 하는가?” 가 다음의 주제인데 당연히 하나의 기준이 있는 것이 아니다. 거대한 방법론을 들고 나오는 사람도 있지만 방법론은 SRS를 이해하는 데에 가장 큰 방해물이다. 훌륭한 요리사가 못 되는 이유는 음식의 본질의 이해하는 것 대신에 레시피와 같은 방법론에 집착하기 때문이다.

홈페이지 만들 때와 비행기 SW 를 만들 때에 적는 Spec의 수준이 다를 수 밖에 없다. Spec은 변할 수 밖에 없다는 종교적인 믿음에 중독된 애자일 방법론도 매우 논쟁적인 이슈이다. 애자일 방법론도 사용할 수 있는 곳이 있고 비행기 SW와 같이 절대 사용하면 안 되는 곳도 있다. 결국은 자신의 이념이나 이익에 따라 주장하겠지만 받아들이는 사람들은 매우 조심해서 판단해야 한다. 이런 비이성적인 국내의 모든 현상들을 가짜 소프트웨어 공학이 춤추는 세상 으로 표현할 수 있다.

결론적으로 왜 과업 변경문제가 벌어지는지 본질적인 문제를 모르는 상태에서는 어떤 법을 만들어도 성공할 수 없다. 문제를 진정으로 이해해도 해결하기는 쉽지 않다는 것은 그 다음 도전적인 과제이지만 시작이 반이다. 일단 진정으로 이해하면 가야 하는 방향은 잡을 수 있다.

이런 Spec과 관련된 문제가 단순해 보이지만 글로벌 SW를 만들지 못하는 가장 중요한 이유이다. 아무리 제품 기획이 좋다고 해도 그를 수행할 수 있는 역량이 부족하다면 비용도 올라가고 경쟁력도 떨어진다. 빈번한 재개발은 전형적인 현상이다. 인공지능, 4차 산업혁명 등 아무리 주장해도 우물안 개구리 국내 관행에서 벗어나려면 필수적인 역량이 무엇인지를 진정으로 이해하는 것이 필요하다.

2020년 5월 29일 금요일

명의 편작도 못 고치는 소프트웨어 회사의 6가지 불치병

500년의 중국 춘추전국시대에는 혼란스러운 시기이면서 제자백가를 비롯해서 영웅들도 많이 탄생했다. 중국에서 가장 병을 잘 고치는 명의인 편작도 그 중의 한 명이었는데 세상에 어떤 병이라도 그 병을 제대로 아는 의사를 불러 조기에 치료하게 한다면 병을 고칠 수 있다고 했다. 반대로 아무리 훌륭한 명의라도 도저히 고칠 수 없는 아래의 “6가지 불치병이 있다고 하였다.

첫 째. 환자가 교만, 방자하여 자신의 병은 자신이 안다고 주장하는 환자이다. 모든 병에는 원리가 있어 그 원리에 따라 치료해야 하는데, 자신의 주관적인 판단으로 의사의 진료와 처방을 따르지 않는 사람은 치료가 불가능하다.

둘 째, 재물이 아까워 자기 자신의 몸보다 우선시하여 치료하지 못하는 사람이다. 재물을 중시하여 몸을 혹사하거나 함부로 부리는 것이 불치병이라는 것이다. 건강을 잃으면 모든 것을 잃는 것임을 알아야 한다. 
 
셋 째먹고 입는 것에 적절함을 잃으면 건강의 균형이 깨어진다. 옷은 추위를 견딜 정도면 적당하고, 음식은 배고픔을 채울 정도면 적당하다. 음식을 탐하고 편안한 것만을 추구하는 습관을 가진 사람은 어떤 명의라도 고칠 수 없다.
 
넷 째, 음양의 평형이 깨어져 기가 불안정한 사람이다. 음양이 장기를 장악하여 혈맥의 소통이 단절되면 기가 불안정하게 되어 되돌릴 수 없는 상태로 진행하게 된다. 기력이 인간의 몸의 기간이 되는 것이므로 늘 일정하게 유지되야 한다. 
 
다섯 째, 어떤 명약이라도 그 약을 받아들일 만한 기초 체력이 없으면 고치기 힘든 병이 된다. 걸을 수 있고 약 먹을 힘만 있어도 살 수 있다. 

여섯 째, 무당의 말을 신뢰하고 의사를 믿지 못하는 것이다.

소프트웨어를 잘 개발하기 위한 깨달음을 얻기 위해 실리콘밸리까지도 갈 필요도 없다. 2,500년 전으로 돌아가서 편작도 잘 알고 있었고 소크라테스도 다 알고 있었다. 진리의 보편성이자 수렴성이다. 하나의 진리를 깨달으면 모든 진리를 깨닫는다. 그럼 편작이 말한 소프트웨어 회사의 여섯가지 불치병에 대해 분석해 보자.

첫 째의 교만이다.
필자가 컨설팅이 불가능한 회사를 꼽는 첫 째가 "나도 다 안다" 는 회사이다. 인간은 자기가 아는 한도 내에서는 모든 것을 다 안다고 착각한다. 바로 “I know what I know”의 현상이다. 이런 자만감을 깨뜨려주는 좋은 운동이 필자가 가장 좋아하는 태극권이다.  태극권은 10년을 해도 '이제 조금 할 줄 아는군요' 라는 말을 듣는다. 오묘하다고 밖에 표현할 수 없는데 수련하면 할 수록 내가 모자라는 것이 점점 더 많아진다는 것을 깨닫게 된다. 미래에도 계속 그럴 것이라는 결론을 쉽게 내릴 수 있다. 필자가 즐기는 바둑, 골프, 당구도 그렇다. 그러니 몇 년 수련했다고 잘난 척 할 수 없게 만드는 것이 이런 것들이다. 필자가 소프트웨어에서 경험이 30년이 이상이 되었지만 실리콘밸리에서의 과거 경험 때문에 내가 안다는 자만감을 가질 수가 없다. 너무 뛰어난 개발자도 많았고 서로 배우는 즐거움을 회상해 보면 항상 내가 모르는 것이 많다는 생각을 없앨 수가 없다. 한번 해 본 것을 깨달았다고 착각한다면 우주의 탄생도 깨달을 수 있다는 격언도 있다. 5, 10년 경험한 개발자들이 마치 모든 것을 깨달은 것처럼 확신을 하고 얘기할 때는 가르치는 것이 불가능하다.

둘 째의 재물을 몸보다 중요시하는 경우이다.
눈 앞의 재물에 눈이 멀어 매출을 올리겠다고 잡화상처럼 이것 저것 고객이 원하는 것을 다 만들어 주는 것이 국내회사의 성향이다. 분식집의 메뉴를 세어보니 100개가 넘는다. 이런 분식집 전략으로 당장 생존하기 위한 노력은 이해하지만 성장이 불가능한 극약 처방의 모델이다. 오랫동안 생존하기를 원한다면 단기적인 재물의 손실은 감안하고 장기적인 혜택을 중요시 해야 한다. 소프트웨어 회사의 이런 앵벌이 방식이 오래되면 나중에는 벗어나올 수 없다.

셋 째의 음식과 옷의 편안함만을 추구하는 경우이다.
만시간의 노력은 하기 싫고 편안한 비법을 찾는 경우이다. 수 많은 비법에 현혹된다. 방법론, 프로세스, 프로젝트관리등 도구 만능주의이다.  다이어트 한다고 먹을 것 다 먹고 운동은 안하면서 약으로 해결하려는 것과  같다. 아무리 돈이 많은 재벌도 땀흘려서 운동을 해야 건강을 유지할 수 있다. 편하게 해서 성공할 수 있는 것은 범죄의 경계선을 넘어가기 전에는 이 세상에 없다. 범죄에 가까우면 가까울수록 돈은 많이 번다. 소프트웨어에서도 진짜 중요한 분석이나 설계 기술은 일이년에 잘 할 수 있는 것이 아니다. 10, 20년을 배워가면서 서서히 향상되는 것이다. 애자일, 프로젝트관리, 프로세스 같은 획기적인 도구나 비법을 주장한다면 100% 사기니까 믿지 말기 바란다. 이미 소프트웨어 역사에서 수십년간 되풀이 되는 메뉴에 불과하다. 실제 필자가 근무했었던 실리콘밸리의 글로벌 회사를 보면 회사의 역량은 다른 곳에 있다.

넷 째의 평형이 깨진 주화입마의 상태인 회사이다.
무술(특히 내가권), 동양의학, 또는 종교에서 많이 인용되는 ()는 영어로는’ Internal Energy’,’Natual Energy’ 혹은 ‘Vital Energy’등으로 번역되는데 경험으로 느끼기 전에는 실체를 알 수 없는 추상적인 것이다. ‘주화입마는 몸 속의 기를 잘못 운용하여 맥을 타고 온 몸을 돌아야 할 기가 어느 한 곳에 뭉쳐서 순환되지 않는 부작용인데 불구가 될 수도 있다. 즉 생명을 위협하는 극단적인 불균형상태를 말한다. 믿거나 말거나 이지만 소프트웨어에서도 상징적인 비교는 가능하다. 소프트웨어 회사도 프로세스와 같이 어떤 것을 무리하게 추진하게 되면 한 곳이 막혀 전체가 망가지는 불구가 될 수 있다. 그런 무서운 주화입마는 조금 할 줄 안다는 자만심의 상황에서 생기지 초보 회사에게는 생기지 않는다는 다행스러운 점이 있다.

소프트웨어 회사에서 기가 잘 순환되는 평형상태는 소프트웨어 기반시스템, 기술, 조직, 프로세스, 문화가 조화롭게 이루어진 상태이다. 아래 세 그림에서 비교해 보자.


첫 번째 그림이 평형이 잘 이루어진 완벽한 상태이다. 언제든지 폭발적인 에너지가 나올수 있는 준비된 상태이다. 글로벌 회사에서는 오랜 역사를 거치면서 이런 조화로운 능력을 갖추고 있다. 그런 상태에서 준비된 힘을 언제 어디에 쓸 것인가를 결정하는 것은 제품기획팀의 역할이다.

두번째 그림과 세번째 그림이 국내 소프트웨어 회사들에서 가장 많이 보이는 유형인데 이런 상태에서는 힘을 낼 수가 없다. 평형이 되어 있지 않기 때문에 힘을 내려고 하면 뭔가 삐끗하는 부분이 있다. 그런데도 억지로 힘을 내려다가 망치는 경우가 바로 주화입마인 것이다. 열심히 하면 할수록 주화입마에 깊이 빠지므로 조심해야 한다. 성장하기 위해 잘못된 개혁을 시도할 때에 문제가 생긴다. 주화입마는 열심히 하는 중상급자들에게 많이 발생하는 문제이다. 제대로 하면 최고가 될 수도 있고 잘못하면 몸을 망칠 수도 있는 기로에서 스승없이 자신의 능력을 과신하고 무모하게 시도하다가 망가진 경우이다.

이미 고객도 어느 정도 있고 빠르게 성장하는 회사가 뭔가 해보려고 할 때가 주화입마에 빠지기 좋은 경우이다. 주화입마에 드는 대표적인 예를 몇 개만 들어보자.

l  어설픈 선진 개발방법론 흉내내기
l  역량을 넘어선 과도한 프로세스
l  문서도 만들지 않으면서 대규모 개발하기
l  미래를 보지 못하는 상태에서 아키텍처 흉내내기
l  일정에 쫓겨 급하게 하는 지저분한 코딩

능력이상으로 무리하게 추진하다가는 지금 잘하고 있는 것도 망칠 수가 있다. 그리고 회복하는 데 많은 비용이 든다. 갑자기 제품 출시가 중단되기도 한다. 회사에서의 시행착오는 시장에 제시간에 응답하지 못하는 기회비용의 손실이라는 점에서 주화입마는 막대한 손실이다. 무술세계나 소프트웨어 세계나 주화입마에 빠지지 않으려면 항상 옆에 자기 실력을 정확히 아는 스승의 가르침 아래 조화롭게 성장해 나가야 한다. 무협영화에서 주화입마에 빠진 제자를 위해 스승이 기를 불어 넣어주어 회복시키는 장면을 많이 보았을 것이다. 혼자서는 영원히 불구가 될 위험이 너무 많다.

다섯 째가 체력이 다 소진된 경우이다.
의사로써 치료의 가능성이 없는 환자를 보는 심정은 안타까울 것이다. 필자도 컨설팅하다가 안타깝게도 이런 회사를 많이 보았다. 주화입마 처럼 조화가 망가진 상태를 넘어서 모든 것이 붕괴되기 직전인 상태이다. 이것 저것 잘못된 시도를 많이 하다가 모든 것이 소진된 상태라 더 이상 해볼 수 있는 상태이다. 돈도 떨어지고, 사람과 조직도 모두 다 망가졌다. 시간 문제일뿐 사라지고 만다. 이 상태가 되면 운명을 받아들이고 가라앉는 배에서 빨리 탈출하는 것이 좋다. 이렇게 되기 전에 미리 의사에게 가서 조치를 취하는 것이 유일한 방법이다.

여섯 째가 무당의 말에 빠진 경우이다.
의사와 무당을 구별하기가 쉽지는 않다. 건강식품과 같이 수 많은 무당이 소프트웨어 업체에도 판 친다. 달콤한 유혹, 편안한 방법, 획기적인 결과, 선진 방법론, 그럴듯한 이론 등이 그들이 사용하는 전략이다. 이런 장사꾼들의 전통적인 선전에는 실리콘밸리가 자주 등장한다. 그런 한두사례의 과대선전에 속아 넘어간다는 것이 안타깝지만 인간은 자신이 생각하는 것만큼 그렇게 논리적이지 않다. 미신은 원시인의 전유물이 아니다. 칼 세이건의 악령이 출몰하는 세상처럼 복잡해진 현대사회에 더 많은 미신들이 논리라는 이름으로 예쁘게 포장해서 돌아다닌다. 필자가 국내 소프트웨어 회사를 위해 할 일 중의 하나가 미신을 구별해 내는 것이다. 미신의 반증이 어려운 이유는 악마가 없다는 것을 증명해 보라는 악마의 증명이기 때문에 불가능하다. 브라질 버섯이 건강에 도움이 되지 않는 다는 것을 증명할 시간과 방법은 없다. 미국 FDA도 그런 승인은 할 수 없다. 자기 스스로 견문을 넓혀서 우물안 개구리가 되지 않도록 해야 한다.

편작이 지적한 이런 여섯가지 문제가 국내 소프트웨어 회사에 너무 잘 적용되는 것을 20년 이상 실제로 지켜보면서 현자들의 지혜에 감탄하지 않을 수 없다. 결과는 국제적인 경쟁력의 부재이다. 국내에서는 경쟁사도 다 같은 상태이니까 생존이 가능하지만 국제적인 경쟁은 차원이 다르다.

국내 소프트웨어 회사의 특징이 유행에 휩쓸려 너무 많은 것을 시도하려는 경향이 있다. 컨설팅 할 때 가장 어려운 점이 하지 않아야 할 것을 하고 있을 때 못하게 하는 것이다. 이런 경우 책임자들의 엄청난 반발과 자신의 업적에 대한 합리화의 격렬한 논쟁은 피할 수 없다. 특히 내부경쟁이 심한 대기업일수록 강하다. 진정으로 해야 하는 중요한 것들은 다 장기적이고 만 시간의 법칙이 필요한 것들이다. 힘든 노력 없이 돈으로 재미 있고 쉽게 해결해준다는 수 많은 유혹에 넘어가기는 쉽다. 하지만 그런 것은 존재하지 않는다는 진리를 기억하기 바란다.



2020년 3월 13일 금요일

코로나사태로 본 재택근무가 불가능한 옹기종기 개발문화




소프트웨어회사에서 재택근무를 할 수가 있는가?” 라는 필요조건에는 다양한 문제가 있다. 먼저 간단히 소개 정도만 할 주제는 보안이다. 보안이라고 하면 한 회사에서 습득한 지식, 설계문서, 소스코드 등 지적재산을 다른 회사에서 사용할 수 있는가에 대한 도덕적 혹은 법적인 주제이다.

구글의 전 개발자였던 Levandowski 가 구글의 비밀을 우버에 가져가 자율자동차에 기여를 한 것에 대한 구글의 소송에서 일주전인 34일에 최종판결이 났는데 Levandowski는 구글에게 2000억원, 우버는 구글에게 3000억원을 배상하게 되었다. Levandowski는 개인파산을 신청했지만 아직 형사소송은 진행 중인데 10년 형을 받을 것으로 예상하고 있다. 이런 경우를 보면 미국이 얼마나 파렴치범에 대해 준엄한 법의 심판이 있는지를 알 수 있다.

실리콘밸리에 있는 필자의 옛 동료나 주위에 있는 사람들이 지금도 재택근무를 할 때 소스코드를 비롯해서 많은 회사 정보가 개인에게 노출된다. 하지만 Levandowski 케이스와 같은 강력한 처벌이 있다는 것을 너무 잘 알고 있기 때문에 전 인생을 걸고 도박을 할 것이 아니라면 그런 생각은 할 수가 없다. 분위기가 그렇기 때문에 회사도 극히 조심하고 그런 직원은 미리 해고시키기 때문에 몰래 범죄를 저지르기도 어렵다. 국내 회사들의 경우는 Virtual Desktop 같은 방법을 이용하여 재택근무는 커녕, 회사 안에서도 정보유출을 막기 위한 많은 방법을 사용하지만 불편하기도 하고 비용도 들고 결국 생산성을 낮추는 큰 원인이다.

이런 지적재산권에 대한 범죄 행위를 법과 사회와 회사와 개인이 얼마나 심각하게 받아들이는가 하는 문제인데 이는 도덕성과 법에 관한 문제이니 여기까지만 얘기하고 진짜 중요한 문제는 다음에 있다.

글로벌 회사에 관련된 필자의 강연에서 꼭 빠지지 않는 주제가 있다. 소프트웨어 회사는 전화, 메신저, 대면 미팅, 이메일대화 4가지가 없는 상태에서도 업무를 진행할 수 있어야 한다는 것이다. 4가지는 있으면 편리하지만 이것이 없을 때 업무를 진행하기 어렵다면 원천적으로 큰 Risk를 가지고 있는 것이다. 바로 옹기종기 개발문화이다. 있으면 편리한 도구이긴 하지만 없으면 안 되는 필수적인 도구로 변화되어 버린 옹기종기 개발문화인 것이다. 항상 옆에 사람이 있어야 하고 즉각적으로 접근이 가능한 상태의 환경에 중독되어 있는 것이다. 

재택근무를 꼭 할 수 밖에 없는 환경이 자주 오지는 않겠지만 코로나 바이러스 사태가 그럴 수도 있다는 것을 보여준다. 미국과 같이 거리의 개념이 한국의 몇 배 정도 되는 곳에서는 꼭 모여서 업무를 해야 한다는 강제성을 부여하기가 어렵다. 그런 식으로는 직원 채용하기도 어렵다. 더 나아가 인도, 베트남, 브라질, 러시아 등을 비롯한 많은 외국의 인력들과 개발을 같이 해야 하는데 시공간의 차이 때문이라도 전화, 메신저, 대면미팅, 이메일대화는 어렵다. 필자가 근무했던 모든 글로벌회사에서도 출근은 하지만 며칠씩 아무하고도 업무에 대한 얘기는 하지 않은 적도 많다. 시공간의 문제는 아닌 것이다. 옆에 두고 옹기종기 개발하는 문화가 아닌 것이다.

4개의 공통점은 모두 사적인 대화이다. 어떤 주제에 대한 대화가 시작될 때부터 모든 사람에게 투명하게 공개되지 않는 사적인 공간에서의 대화이다. 소수의 사람들이 의논해서 결과를 도출하고 그 결과를 모두 공개한다고 해서 투명한 것은 절대 아니다. 결과는 회사에서 어차피 공개되게 되지만 중간에 벌어진 과정이나 배경 등은 다른 사람들이 알 길이 없고 좋은 의견을 제시할 기회 자체가 없다.

4개의 사적 대화방식에 대한 의존도가 얼마나 큰 정도가 소프트웨어회사의 수준이 아마추어인지 프로인지를 구별하는 가장 명확한 잣대이다. 이런 근본 이유는 소프트웨어는 지식산업이기 때문이다. 반면에 관리자와 같이 Daily Operation을 해야 하는 사람들은 재택근무가 어렵다.

그런 면에서 스크럼 애자일과 같은 옹기종기 개발방식이 얼마나 제한된 조건에서만 사용 가능한 지를 추측할 수 있다. 버클리대학의 전산학 교수가 소프트웨어공학 강의에서 한 말이 자기는 개발을 시작할 때면 항상 이메일과 휴대폰을 꺼놓는다고 한다.

그럼 소프트웨어 개발자로 범위를 좁혀서 생각해 보자. 4개가 없이는 개발 활동이 불가능한 것으로 보이는데 반대로 개발이 가능하려면 무엇이 필요할까? 다음 3가지가 필요하다. “소스코드관리시스템, 이슈관리 시스템, 정확한 Specification” 이 절대적으로 필요하다. 필자가 3개를 나열한 순서에 중요한 의미가 숨어 있다. 이 3개의 공통점은 모두 투명한 협업의 방법이다. 소스코드, 이슈 진행 상황, 해야 할 업무에 대한 투명한 정보를 모두에게 실시간으로 제공한다.

먼저 소스코드관리시스템을 보자. 국내에서 약 10년 전만 해도 소스코드관리시스템이 왜 필요한지를 이해하는 개발자들이 많지 않았다. 자기 나름대로 소스코드 버전 관리를 하는 Know-how가 있다고 주장하는 것을 많이 봤지만 그들의 사고방식을 깨뜨리기는 어려웠다. 경험하지 않은 사람에게 그 가치를 설명하는 것은 원천적으로 불가능하기 때문이다. 하지만 세월이 흘러서 자연 진화라도 하다 보니 지금은 거의 모든 개발자가 소스코드관리시스템이 없이는 개발이 불가능하다는 것을 깨달은 시기가 되었다.

Git를 사용하는 것이 무슨 대단한 역량으로 생각되던 웃기는 상황이 지금은 자랑거리도 안 되는 너무나 당연한 것으로 되었다. 소프트웨어의 역사와 같이 해온 소스관리시스템의 개념만 알면 모든 소스코드관리시스템은 다 유사한 제품에 불과하다. 구글에서는 자체 제품을 사용한다. 국내에서 소스코드관리시스템에 대한 인식수준과 실리콘밸리에서 30년 전에 필자가 있었던 환경과 비교하면 적어도 30년 이상의 갭이 존재한다.

두번째로 이슈관리시스템을 보자. 국내에서 아직 왜 이슈관리시스템이 절대적으로 필요한지를 이해하는 회사는 많지 않다. 10년 전의 소스코드관리시스템의 상황과 비슷하다. 나름대로 이슈관리시스템이 없이도 개인의 극히 제한된 Know-how 방식으로도 업무가 가능하다고 생각하는 경우가 많다. 이런 사고방식에서 깨어나는 것이 일단 도전적인 과제이다. 역시 경험해보지 못한 상태에서 깨달아야 하는 어려움이 있다.

통상적인 회사에서는 수 많은 회의로 시간을 보내면서 그렇게 하는 것이 열심히 일하는 것으로 인정 받을 수 있을 지 모르지만 효율성이 지극히 낮은 어수선한 방법이다. 다행히 어떤 선각자가 통찰력이 있어서 이미 이슈관리시스템을 도입해서 사용하고 있다고 해도 사적 대화방식을 대체할 만큼 효율적으로 사용하기는 어렵다. 골프채를 샀다고 골프를 잘 치는 것은 아닌 것과 같다. 사용하기 시작한 다음부터도 Know-How가 축적되기 위해서는 많은 경험과 지혜가 필요하다. 많은 경우에 원숭이가 표면적으로 인간 흉내 내듯이 하다 보면 배가 산으로 가기도 한다.

하여튼 Jira라고 하는 이슈관리시스템을 성공적으로 개발한 호주의 Atlassian이란 회사는 호주의 Microsoft라 불릴 정도로 세계적으로도 가장 성공한 회사가 되었다. 필자의 경험으로 봐도 기존의 수 많은 이슈관리시스템보다 잘 만든 것은 사실이다. 지금은 무조건 Jira를 사용하라고 추천한다. 국내 소프트웨어 산업계에서의 유행은 대부분은 소수에만 적용되는 위험하고 낭비적인 유행이었는데 Jira는 잘못된 선택이 될 수 없는 유일한 좋은 유행이다.

세번째는 정확한 Specification이다. 필자의 많은 다른 기사에서 언급했듯이 Specification SRS(Software Requirement Specification)이라고도 한다. 이 단계는 아직 국내에서 극히 몇 안 되는 회사만이 조금 이해하고 있거나 현재 자신의 상태에 대한 자아인식(Meta-Cognition)을 하고 있는 상황이다. 자아 인식을 하고 있다는 것은 이미 반은 진행된 것과 같으니 희망적인 회사이다. SRS는 문서이지만 중요한 것은 분석이라는 행위이다. 국내의 거의 모든 회사는 아직 이슈관리시스템이 없이 개발이 불가능하다는 두번째 단계 조차도 깨닫지 못하고 있는 수준이고 그냥 유행 따라 사치품 정도로 사용하고 있는 것이 현실이다. SRS는 더 갈 길이 멀다. 물론 SRS도 원숭이흉내 수준에서 스스로 자아도취 하면서 실제로는 재택근무도 불가능하고 생산성을 높여 주지도 않는 상태가 대부분이다.

SRS라고 하면 거창한 행위나 Template을 연상하는데 이론적인 소프트웨어 공학자들이 퍼트려 놓은 잘못된 개념이다. 사실 진정한 소프트웨어 공학자는 이론적이면 안 된다. 공학은 현실을 다루는 것이기 때문에 이론과 공학은 상충되는 개념이며 이론적인 공학자는 그냥 자체모순인 용어다. 실용적인 분석을 학교에서 가르친다는 것 자체가 모순에 가깝다.  학교에서 배울 것이 있고 회사에서 배울 것이 있다.  이론으로 무장한 가짜 소프트웨어공학자가 많은 것이 국내의 상황이다. 이는 실리콘밸리의 스탠포드 대학이나 버클리 대학에서 소프트웨어 공학을 어떤 식으로 가르치는 지를 비교해 보면 이해할 수 있다

SRS는 위에서 언급한 4개의 사적인 Communication이 없이도 재택근무를 하기 위해 개발할 제품에 대한 충분한 정보를 적어 놓은 것이다. 물론 그렇게 만든 행위는 분석행위이다. 어떤 경우는 한두 페이지 일 수도 있고 어떤 경우는 수천 페이지 일 경우도 있다. 이런 추상적인 개념을 이해하는 것은  정형적인 Template과 방법론에 익숙한 개발자들에게는 매우 도전적인 과제이다. 한번 미신에 빠지면 그 습관과 생각에서 헤어나오기 힘들다.

결론은 소스코드관리시스템, 이슈관리시스템과 SRS 3개가 재택근무를 가능하게 하는 필요충분 조건이다. 4개의 사적인 Communication은 응급시에 사용하는 사치품 정도로 생각하면 된다. 이제 소스코드관리시스템의 필요성에 대해 이해를 했다면 아직 2단계가 더 남아 있는 것이 통상적인 국내의 수준이다. 미래를 예측해 보면 약 10년 후에는 이슈관리시스템이 없이는 개발이 불가능하다라고 대다수의 개발자들이 인식할 수 있을 것으로 예상한다. 그 다음에는 차원을 달리하는 SRS라는 분석행위가 기다리고 있다.

마지막으로 필자가 이 3개가 없으면 개발이 불가능하다고 했는데 100% 사실은 아니다. 가능한 경우도 있다. 이런 경우를 열심히 부자가 되기 위한 방법을 설명했는데 그런 노력을 하지 않고도 부자가 되는 방법이 있다. 로토에 당첨되는 것이다. 이 말은 미국의 소프트웨어 컨설턴트인 Robert Japenga한 말이다. 미신에 현혹되어 기적을 바라는 어리석은 인생을 살지 말라는 교훈이다.

과연 국내에서 재택근무가 가능할까? 회의적이다. 하루 이틀은 가능하겠지만 그 다음부터는 어떤 현상이 일어날지는 눈에 선하다.  코로나 바이러스 때문에 생긴 천재지변이 아니더라도 지금도 효율적으로 개발하기 위해서는 재택근무가 가능한 3개의 역량을 가지고 있어야 한다.