분석 #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 산업이 발전할 수 있는 핵심 필요조건이다. 그러기 위해서는 회사 문화뿐 아니라 분석 능력의 향상 그리고 조용한 개발환경에 필수불가결한 기반 시스템 구축이 우선되어야 한다.

분석 #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 개발자가 아니다.

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

분석 #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을 배우면서 추가로 소프트웨어 공학의 핵심을 저절로 배우는 기회를 위해 필자가 개발자들에게 꼭 추천하는 강좌이다.

분석 #4 잘못된 이름으로 인한 치명적인 착각

 필자가 미국에 처음 갔을 때 한국교포 2세와 얘기를 하다가 "잘못보았다" 란 말을 영어로 해야 하는데 도저히 생각이 나지 않아서 영어로 뭐라고 하느냐고 물어보니까 그 교포도 고개를 갸우뚱하더니 똑같은 말이 없다고 한다. 즉 "자동차로 잘못 보았다" 는 말은 "I thought it was a car" 라고 하는 표현으로 대체 된다. 즉 한 언어에서 다른 언어로 직역할 수 없는 것들이 많다. 그래서 외국어를 배울 때 분석하지 말고 그냥 외우는게 가장 빨리 배운다는 격언이 있다.

인간이 어떤 행위를 하면 결과물이 나온다. "분석" 이라는 행위를 하면 "SRS"라는 산출물이 나온다. 행위를 했는데 산출물이 나오지 않으면 다른 사람에게는 행위를 하지 않은 것으로 간주된다.  미국의 소프트웨어 회사에서 통상적으로 SRS 라고 하는 것이 "Software Requirements Specification" 의 줄인 말이다. 한국에서는 당연히 한글로 번역을 한다. 그런데 이 잘못된 번역 때문에 한국 소프트웨어 업계가 시작부터 잘못된 원인이 되었다. 직역할 수 없는 단어 하나 때문에 소프트웨어 개발에 대한 문화가 갈라파고스 섬으로 가버렸다. 일단 문자를 풀어서 해석하자면 "Software의 Requirements"를 "Specify" 한 것이라고 할 수 있다. 당연히 "Requirements" 와 "Specification"이 다르다는 것을 의미한다. 여기서 언어가 문제가 된다. Requirement와 Specification을 둘 다 "사양" 이라고 번역한다. 완전히 다른 것을 이름을 같이 붙여 놓으니 문제가 없을 수가 없다.

이런 번역의 오류가 생기는 예로 특허 문서에 사용하는 용어 중에 영어로는 Compise와 Consist가 있는데 완전히 다른 의미로 사용된다. 그런데 한글로 번역을 하면 둘 다 "구성하다"라는 똑같은 용어로 해석된다. 그래서 한국에서 특허를 내고 나중에 외국에서 특허를 내려고 할 때 문제가 된다. 중국어도 한글로 번역되지 않는 경우가 많이 있다. "해도 된다" 혹은 "할 수 있다"는 조동사가 "neng", "hui", "yinggai", "dei" 등과 같이 한글로는 다 똑같이 번역되지만 중국어에서는 다르게 사용되는 단어들이 있다.

한국에서는 SRS를 나름대로 추측해서 어떻게 부르는지 몇 개만 나열해 보자. "요구사항", "요구사항 명세서", "기능 명세서", "고객요구사항" 등이 있다. 이 모두 완전히 잘못된 번역이다. 지금 나열한 문서의 제목은 "Requirements" 에 가깝다. 즉 기능명세서를 적어 놓고 SRS를 작성했다고 주장하는 것은 착각이다. "요구사항 명세서"가  그래도 비슷한 편인데 요구사항을 적는 것이라고 생각한다면 잘못된 것이다. 정확하게 말하면 첫째로 요구사항을 적고 그 다음에 "Specify" 라는 행위를 하고 나서 그 결과물인 Specification 문서를 적는 것이다. Requirements 가 있고 나서 그것을 기반으로 Specify 해야 비롯 SRS가 작성되는 것인데 Requirements만 적었지 아직 Specify하는 행위는 시작하지도 않았다. 그런 이유로 SRS를 간단히 "Specification" 혹은 "Spec" 이라고 부른다.

그러면 그게 그거지 뭐 이렇게 문서를 많이 적어야 하는 지 짜증이 들지도 모르겠지만 그 것도 착각이다. 고객의 요구사항을 가져 오는 것은 개발자의 업무가 아니다. 즉 개발자들이 전문성도 없고 자기 업무도 아닌 엉뚱한 일을 하고 있었던 것이다. 고객의 Requirements를 정리하고 가져오는 것은 마케팅부서의 핵심 업무이다. 보통 마케팅부서의 업무를 "4P"라고 표현한다. Product, Price, Placement, Promotion 이라는 4개의 용어가 모두 P로 시작하기 때문에 붙여진 이름이다. 그 중의 Product이 바로 제품을 정의하는 업무이다. 즉 Requirements를 작성하는 것이다. 마지막에 Promotion이 "홍보" 인데 한국에서는 "마케팅" 이라고 하면 "홍보"를 의미할 정도로 완전히 잘못 사용하고 있는 용어이다. 미국에서는 Promotion을 담당하는 분서는 마케팅부서 중에서 "Marketing Communication"이라고 한다.

결국 개발자들이 "요구사항 명세서" 라는 것을 작성하는데 자기 일도 아닌 마케팅부서의 일을 하고 있는 것이고 그 것을 SRS 를 적었다고 착각하는 2가지 오류를 범하고 있는 것이다. 왜 그런 상황이 되었는지는 이유가 있지만 나중에 얘기하기로 하자. 그나마 개발방법론을 조금 안다고 주장하는 사람들이 뭔가를 적지만 아예 Requirements도 없이 추상적인 기획이나 비전만 가지고 코딩으로 뛰어드는 용감무쌍한 개발자들도 많이 있다.

그래도 거대방법론을 도입한 회사(주로 대기업)들은 방법론이 요구하는 문서를 보고 적다 보면 그 와중에 형식적으로는 Specify 라는 행위의 결과물을 적는 흉내를 내게 된다. 하지만 본질을 모르는 상태에서 템플릿에 적는 방식으로는 한계가 있다. 제대로 충실한 내용이 적힐 수가 없다. 어떤 방법론을 사용해도 마찬가지이다. 나중에 설명하겠지만 "일체성(Integrity)"이라는 핵심 특성이 있다. 진정한 SRS가 완성되기 위해 꼭 고려되어야 하는 특성이다.

도대체 SRS가 무엇인지 궁금증을 약간 해소하기 위해 여기서는 매우 간단히 SRS에 적어야 하는 대표적이고 핵심적인 일부 항목들만 나열해 보자. IEEE에서 SRS에 대해 전세계 전문가들이 만들어 놓은 바이블과 같은 Template에서 가져온 것이다. 혼란을 피하기 위해 영어를 같이 사용한다.

- Purpose (목적)

- Prodcut Scope (범위)

- Product Perspective (제품조망)

- Overall System Onfiguration (전체 시스템 구성)

- Overall Operation (전체 동작방식)

- Product Functions (제품주요기능)

- Assumptions and Dependencies (가정과 종속관계)

- Apportioning Requirements (단계별 요구사항)

- Backwards Compatibility (하위호환성)

- Operating Environment (운영환경)

- Development Environment (개발환경)

- Test Environment (테스트 환경)

- Configuration Management (형상관리)

- External Interface (외부 인터페이스)

- User Interface (유저 인터페이스)

- Peformance Requirements (성능요구사항)

- Non-functional Requirements (비기능요구사항)

- Functional Requirements (기능요구사항)

- Change Management Process (변경관리 프로세스)

어떤 방법론을 사용하든 이와 비슷한 용어들은 많이 들어 보게 된다. 모든 방법론이 나온 근원이고 여기에 포장만 입혀 놓은 것이기 때문에 너무 당연하다. 이것을 다 작성한다고 생각하면 기겁을 할 수도 있다. 실리콘밸리나 한국이나 개발자의 성향은 같다. 재미없는 일을 하는 것은 인간이면 다 싫어한다. 그런데 재미를 모르는 것이지 재미 없는 것은 아니다. 분석을 하고 이런 문서를 적는 것이 코딩보다 더 재미있는 일이라는 것을 인식하게 될 때 바로 훌륭한 개발자가 되었다고 자부해도 된다. 이렇게 많은 문서를 다 적는 것이 아니다. 그렇게 해왔다면 SRS의 본질을 이해하지 못하고 있다는 것을 증명한다. SRS의 본질은 가장 빠르게 개발하는 것이 목적이다. 그레서 SRS가 적히는 방법은 모든 프로젝트가 다 다르다. 학교숙제를 할 때도 이 모든 문서를 일단 다 생각해 본다. 생각하는 시간은 1분이면 충분하다. 그 1분 동안 무슨 문서를 얼마나 작성할 것인가를 직감적으로 결정한다. 별로 작성할 문서가 많지 않다는 것을 알게 된다. 학교숙제의 경우 이 중에서 한두개만 작성할 수도 있다. 학교숙제가 아니고 한 달 짜리 프로젝트라고 해 보자. 그러면 어떤 문서를 얼마나 작성할 지를 결정하는데 역시 1분 이면 충분하다. 문서 2-3개 쯤 될 것이다. 필자가 일했던 General Electiric의 원자력 발전소 소프트웨어를 개발한다고 해 보자. 그러면 모든 문서를 작성해야 한다는 것을 1분 안에 직감으로 결정할 수 있다. 단 어떤 문서를 얼마나 적어야 할지는 모든 프로젝트마다 다르다. 필자가 해 본 수백개의 프로젝트도 다 달랐다. 즉 어떤 규칙으로서 적용할 수 없는 예술적인 판단이다. 그래서 소프트웨어가 극단적인 지적산업인 것이다. 주어진 템플릿보고 채워나가는 일을 하고 있다면 "개발 노동"을 하고 있는 것이다.

위에 나열한 것 중에서 전체 작성하는 문서의 양 중에서 어떤 경우는 'Functional Requirements'가 90%를 차지하기도 하고 " User Interface (유저 인터페이스)"가 90%를 차지하기도 하고, External Interface (외부 인터페이스)가 90%를 차지하기도 한다. 그를 조절하는 것 역시 어려운 판단이며 예술의 영역이다. 다시 한 번 강조하지만 어렵기 때문에 연봉을 많이 받는 것이다. 템플릿이나 채우고 있는 개발 노동자들에게 높은 연봉을 주는 바보 경영진은 없다.

다시 정리하자면 Requirements와 Specification은 완전히 다른 영역이며 Requirements는 마케팅의 업무이고 개발자의 업무가 아니다. 통상적으로 개발자가 수행해왔는데 비효율적인 것은 말할 것도 없거니와 그것을 SRS를 적었다고 착각하는 것도 큰 착각이다. 결론적으로 한국에서 벌어지는 거의 모든 프로젝트는 SRS가 제대로 적히지 않은 상태에서 개발을 해 왔다. 주먹구구식이거나 혹은 대형 방법론의 경우 형식적으로 적힌 가치가 없는 문서가 대부분이었다. 경험자들은 이런 사실을 잘 알고 있다. 애자일 방법론은 미국에서는 이미 유행이 지나갔지만 그냥 방법론의 하나일 뿐이지 개발의 원칙을 벗어난 예외가 될 수는 없다. 

또 다른 관점에서 볼 때 가치있는 문서를 적었다면 오래동안 생존해야 한다. 나중에 보지 않는 문서라면 당연히 가치가 없는 문서이다. SRS는 제품이 단종이 될 때까지 살아남는 문서이다. 앞으로 진행하면서 SRS의 다양한 실체를 보게 되겠지만 소프트웨어 개발에서 가장 정교하고 어려운 행위라는 것을 명심하기 바란다.

분석 #3 분할 발주의 허구와 진실

소프트웨어는 이론적인 개발 단계가 있다. 이론이라고 무시하려고 할지 모르지만 이론이 아닌 실전에서 가장 중요한 개념이다, 단계적인 개발 방식을 외부의 개발사와 계약으로 할 때 분할 발주가 된다. 이 용어는 다 이해하겠지만 제대로  따라하지는 않는다. 역량 때문일 수도 있고 의지 때문일 수도 있다. 여기서는 외주 개발사를 가정하고 분할 발주로 얘기하자. 하지만 개발단계의 핵심은 동일하다. 먼저 분할 발주의 목적을 알아야 한다. 목적도 모르고 무조건 분할 발주를 하겠다는 것은 방향도 모르고 눈 감고 길을 가는 것과 같다. 분할 발주의 목적 중의 하나는 개발 단계를 나누어서 각 단계의 발주를 다른 회사에게도 줄 수 있게 하는 것이다.

분할발주를 하려면 당연히 분할을 해야 한다. 잠깐 여기서 IEEE의 SWEBOK (SW 지식체계)에서 세계 최고의 실전 전문가 수백명들이 말하는 분할의 첫 단계인 분석의 목적을 몇 개만 나열해 보자.

- 개발에 드는 비용을 정확하게 산정하기 위함이다.

- 정확한 개발 일정을 알고 싶다.

- 설계를 위한 기초가 된다.

여기서 보면 분할 발주의 목적이나 분석의 목적이 같다는 것을 알 수 있다. 결국 분할 발주의 목적을 이루기 위해서는 분석을 잘해야 한다. 프로세스도 아니고 오직 분석이다. 진리는 가까운 곳에 있다. 반면에 지옥으로 가는 길은 매력적으로 포장되어 있다는 격언이 있다. 유행따라 멋있어 보이는 프로세스, 기법, 방법론들이 매력적으로 보이지만 결국은 대부분 사라지고 분석이라는 추상적인 원칙 만이 영원히 살아남는다. 대부분의 새로운 것들은 마케팅 천재들이 만들어 낸 멋진 마케팅 패션용어에 불과했다는 것을 나중에 깨닫게 된다. Big Data, IOT, Machine Learning등도 갑자기 생겨난 기적이 아니고 과거에 있었던 것들이 환경에 맞게 필요해 진 것 뿐이다. 때에 맞추어  새로운 이름을 붙이니 매력적으로 보이는 것 뿐이다.

국내에서 늦은 감이 있지만 분할 발주가 중요하다는 것을 깨달았다고 하고 법으로까지 만든다는 것은 나쁘지 않다. 하지만 법으로는 충분하지 않다. 법을 바꾸는 것은 쉽지만 사람들의 마음 속에서 편견을 없애는 것이 훨씬 어렵다. 전세계에서 인종에 대한 차별이 법으로는 거의 다 없어졌다. 하지만 사람들의 마음 속에는 아직도 뿌리 깊은 편견이 남아 있고 행동에서도 나타난다. 법은 한계가 있고 마음속으로 받아 들여야만 진정한 변화가 올 수 있다.

지금까지는 신도 얼마짜리 인지 알 수 없는 몇백억짜리 계약을 용감하게 해 왔다. 그렇게 하는 방식 외에는 본 적이 없으니 그런 방식이 인생인 줄 안다. 마치 처음 알에서 깨어난 오리새끼가 최초에 본 물체가 자기 어미인줄 알고 평생을 따라 다니는 것과 같다.  한국에서 벌어지고 있는 갈라파고스 신드럼 중의 하나이다. 필자가 실리콘밸리에 있었을 때 한국회사가 와서 이런 방식으로 미국회사와 계약하고 사업을 하려다 소송 당하고 철수한 적도 있었다. 필자가 아직도 의아하게 생각하는 것은 미국회사가 어떻게 애초부터 그런 계약을 했을가 하는 것이다. 정상적인 미국 회사라면 그런 비상식적인 계약을 했을 리가 없다. 아마도 한국 회사의 브랜드와 파격적인 약속을 믿고 계약했을지 모르지만 결국 두 회사 모두 피해를 입었다. 실리콘밸리에서는 한국처럼 엉터리 계약후 적당히 넘어가는 것은 문화적으로 불가능하다.

게약은 외부 회사와의 계약서만 계약이 아니다. 내부에서 개발 프로젝트를 하겠다고 하는 것도 똑같은 계약이다. 내부라고 계약 없이 대충하는 것은 주먹구구식으로 일하는 회사라는 것을 증명한다. 혹시나 친구끼리 시작한 신생업체인 경우 개발 계획도 없이 열정으로 열심히 해 볼 수는 있다. 운이 좋아 한탕은 가능할 지 모르겠지만 지속적인 성장은 불가능하다. 혼자서 열심히 연습해서 세계적인 피아니스트가 되겠다는 것과 다를 바 없다.

그러면 구체적으로 정상적인 경우에 어떻게 계약이 진행되는 지를 살펴보자. 가장 먼저 확실히 인식해야 할  진리는 개발시작 당시에는 소프트웨어를 개발하는 데 드는 일정과 비용을 신도 모른다는 것이다. 전지전능한 신도 모르니 아는 척 하지 말기 바란다. 그러면 결국 단 하나 남은 선택은 얼마를 줄테니까 알아서 개발해 달라는 것이다. 그래서 소위 우선협상대상자라는 것을 선정하고 정해진 계약비용안에서 무엇을 해 줄 것인가를 협상한다. 아주 그럴듯하게 보이지만 역시 엉터리이다. 이런 방법 외에 어떤 방법도 없어 보이지만 실리콘밸리에서 계약은 그렇게 진행되지 않는다. 오리새끼처럼 처음부터 잘못된 길에 들어서 한국에 뿌리깊게 자리잡은 잘못된 방법일 뿐이다.

그러면 과연 어떻게 진행되는 지 진실을 보자. 실제 경험 없이는 지금은 이해할 수 없는 미묘한 것들이 있지만 먼저 설명할 수 밖에 없다. 1인 회사나 글로벌 대기업이나 마찬가지로 소프트웨어 개발은 (1) 비전 -> (2) 기획 -> (3) 분석 -> (4) 설계 -> (5) 구현 으로 진행된다. 아니 진행되어야 한다. 이는 폭포수 이론처럼 들릴지 모르지만 극히 현실적인 방법이다. 폭포수에 대한 이해를 잘못하고 있는 사람들이 많지만 실리콘밸리는 그렇게 한가하고 이론적인 곳이 아니다. 실리콘밸리는 경쟁이 극심한 곳이고 가장 현실적인 방법론을 사용하는 곳이다. 이 중에서 통상적으로 비전은 경영진의 역할이고 기획은 기획부서 혹은 마케팅부서의 업무이다. 여기서 첫 단추가 잘못 끼워지면 뒷 부분에서 제대로 되기는 힘들다. 한국에서 필자가 본 기획은 대부분 비전에 가까운 추상적인 문서이다. 즉 분석을 수행할 만한 충분한 정보가 없다는 이야기이다.

일단 제대로 된 기획이 있다는 가정하에서 진행해 보자. 그러면 개발팀이 "분석+설계+구현" 을 해야 한다. 외부냐 내부냐에 상관 없이 얼마에 계약을 해야 하는 문제가 생긴다. 이게 비로 불가능한 일이다. 그래서 먼저 계약후 우선협상대상자를 선정해서 개발범위를 얘기해 봐야 역시 무지에서의 토론일 뿐이다. 무지에서의 토론이니 어떤 협상도 신빙성이 없다. 그것은 절대적으로 잘못된 방법이다.

그러면 옳은 방법을 보자. 개발 일정은 전지전능한 신도 모르지만 희망하는 목표 일정은 있다. 그 목표 일정의 30% 정도를 나누어서 "분석" 업무에 관한 계약을 한다. 그러면 다음과 같은 질문이 생긴다.

- 분석에 대한 계약 금액은 얼마로 할까?

- 어떤 결과를 원할까?

- 분석의 결과물 (총칭해서 SRS라고 한다)의 내용과 품질은 어떻게 장담할 수 있을까?

이 문제들은 분할 없이 전체를 계약할 때 생기는 문제와 동일해 보인다. 하지만 큰 차이가 있다. 해법도 단순하다. 이 계약은 결과물을 정하는 것이 아니라 분석에 소비하는 시간에 대한 비용으로 계약을 한다. 이를 "Time and Material" 이라고 한다. 즉 계약한 시간 동안 일을 하는 것이다. 나중에 얘기할 다른 방식은 "Turn-key"라고 한다. 목표 일정이 완전히 엉터리가 아니라면 약 30% 정도의 시간을 들여서 분석의 목적은 이룰 수 있다. 20%를 하든 30%를 하든 40%를 하든 그 목적을 이룰 수 있게 진행하는 것이다. 목적은 다음 단계인 설계와 구현에 필요한 일정과 비용을 정하기에 충분한 정보를 명시하는 것이다. 제품 개발을 완성하는 것이 아니기 때문에 30%이건 40%이건 목적에 맞게 분석을 완성할 수 있다. 분석의 결과는 유연하게 조절이 가능하다는 것이다. 얼마나 자세하게 명시하는 가에 따라 시간을 조절할 수 있다. 분석가로서의 경험이 있다면 당연히 그 정도는 조정할 줄 알아야 한다.

이 분석의 결과물의 논리적인 이름은 총칭해서 SRS라고 한다. 물리적인 문서 이름은 천차만별이고 회사마다 다르다. 문서의 종류와 갯수도 다르다. 하지만 똑 같은 원칙에 의해서 작성된다. 필자가 몇십년동안 수행했던 크고 작은 수백개의 프로젝트가 똑같은 형식의 결과물이 나온 적은 한번도 없었다. 여기서는 아직 어떤 결과물이 나오는 지 궁금해 할 수는 있지만 나중으로 미룬다. 하여튼 분석이 완료된 이 시점에서는 "설계+구현" 단계에서 해야 할 일이 얼마나 되는지 알 수 있다. 즉 "설계+구현"을 얼마에 계약을 할 지를 비로서 아는 시점이 온 것이다. 여기에서의 계약은 Turn-key 게약이다. 몇 명의 개발자가 일을 하는 가는 전혀 신경쓰지 않는다. SRS에 명시된 대로 개발해 주는지 아닌지가 핵심이다. 이미 개발내용이 명시된 상태에서 하기 때문에 우선협상 같은 것은 당연히 필요 없다.

즉 분할 발주를 한다면 계약은 (1) "분석"과 (2) "설계+구현"의 두단계로 나눈다. 또 분석의 중요한 목적의 하나인 이 프로젝트를 계속할 것인다 포기할 것인가도 여기서 결정할 수 있다. 30%의 비용을 들여서 분석을 했다고 해도 과감히 매몰비용(Sunken Cost)으로 버리는 것이다. 30%의 투자가 아까와서 안해야 할 프로젝트에 남은 70%를 투자하는 것은 바보같은 직이다.

설계와 구현 단계는 계약에서는 나누지 않는다. 연속성이 훨씬 더 중요하기 때문이다. 그리고 설계와 구현의 경계선을 긋는다는 것은 거의 불가능하다. 설계에 참여하지 않은 상태에서 코딩을 할 수 있게 하려면 엄청난 양의 문서가 필요하다. 설계와 구현을 분할하겠다는 생각은 그럴듯해 보이지만 현실과는 거리가 멀고 착각에 불과하다. 단계는 나눌지 모르지만 대부분의 개발자는 연속적으로 투입된다. 설계와 구현을 나누어 계약하는 경우는 필자의 실리콘밸리 경험상 본 적도 없을 뿐더러 가능하다고 해도 엄청난 시간의 낭비이다. 설계까지 나간다는 것은 이미 개발을 포기하지는 않는다는 전제를 가지고 있다. 즉 어차피 구현까지 계속 한다는 가정인 것이다. 설계까지 했다면 거의 70%를 진행한 것인데 이제 와서 포기한다는 것은 애초부터 계획이 심각하게 잘못되었다는 것을 의미한다. 여기까지 오다 보면 마치 거대한 프로젝트를 대상으로 얘기하는 것 같지만 이 원칙은 학교숙제할 때도 적용된다. 규모에 상관 없이 가장 빨리 그리고 효율적으로 개발하기 위한 원칙은 동일하다. 단 같은 원칙하에서 프로젝트에 따라 응용법은 달라지며 이 응용역량이 높은 연봉을 받는 진정한 분석 역량인 것이다.

이제 두 단계로 계약을 하는 목적과 그 단계의 경계는 절대적으로 "분석"이 끝나는 시점이 되어야 한다는 것을 이해할 수 있을 것이다. 이런 진리를 확실히 이해했다면 그 목적에 적합한 역량을 키우는 것이 다음에 해야 할 일이다. 분석을 수행하면서도 항상 기억해야 하는 것이 분석의 목적이다.  

분석 #2 개발자가 분석을 잘해야 하는 극히 세속적인 이유

TV 프로그램 중에 동물농장이라는 프로가 있다. 외국 TV에서도 "위험한 구출("Dangerous Resque")라는 프로그램을 방영한다. 위험에 닥친 동물을 구조하려는 것인데 구조에 협조하는 동물은 보지 못했다. 도망가려고 기를 쓰고 심지어는 구출대원을 공격하기도 한다. 자신을 위한 일인데도 이해를 하지 못하니 그럴 수 밖에 없다. 인간도 그렇게 다르지 않다. 소크라테스가 "유일한 악은 무지이다" (The only evil is ignorance)라는 말을 했고 아인슈타인도 "너 자신의 무지를 과소평가하지 말라"고 했다. 소크라테스가 살던 2500년 전이나 지금이나 인간은 무지에 관한한 개선되지 않았다. 찬란한 과학문명의 발전에 비하면 생각하는 방식은 진화하지 않았다. 과학의 발전에 상관 없이 무지와의 싸움은 영원히 끝나지 않을 것이다. 언젠가는 지구를 떠나 우주로 날아가서 살 정도로 과학이 발전하겠지만 그렇다고 인간의 생각이 바뀌기는 어려울 것이다. 무지가 좋은 점은 현명한 자는 무지에서 벗어나 다른 사람들과 차별화할 수 있는 기회가 있다는 것이다.

어떤 행동을 유도하기 위해 이론적이나 추상적으로 좋은 이유를 말하기 보다는 현실적으로 왜 분석이 중요할 까 하는 얘기를 세속적으로 돈과 관련해서 해 보려고 한다. 가치를 돈과 연결하는 것이 세속적이기는 하지만 인간의 속성상 설득하기에 가장 좋은 방법이 아닐까 한다. 사실 필자가 국내에서 가치를 가질 수 있었던 것도 세속적인 차이점을 부각시킬 수 있었기 때문이다. 분석을 이해하기도 전에 먼저 왜 중요한지 그리고 왜 해야하는 지에 대해 동기를 부여해 보도록 한다.

소프트웨어의 모든 용어는 건축에서 시작되었다. 설계라는 말을 가장 쉽게 이해할 수 있는 분야가 건축이다.  건물을 건축하려면 두 단계가 있다. 설계와 시공이다. 그런데 건축과 소프트웨어와는 용어가 약간 다르다. 건축은 두 단계가 있지만 소프트웨어에서 말하는 설계는 시공 쪽에 가깝다. 즉 소프트웨어에서는 분석, 설계, 구현의 3 단계가 있다.  소프트웨어의 분석은 건축에서의 설계와 같고 설계와 구현을 합쳐서 건축에서의 시공과 비슷하다.  이 점이 이상스럽게 생각될지 모르지만 2단계와 3단계를 매핑하려니 그렇게 보는 것이 가장 가깝다. 나중에 그 이유를 잘 알 게 될 것이다. 소프트웨어에서 규모에 따라 비효율성을 피하기 위해 한 단계를 없애고 두 단계로 축소한다면 "분석"과 "구현" 이다. 지금은 추상적인 단계이니 현실적으로 분석이 왜 중요한가는 이해하기가 어렵다. 세속적으로 돌아와서 건축에서 설계를 담당하는 설계가와 시공하는 인부중 누가 더 임금을 많이 받겠는가? 나의 가치를 올리자면  다른 사람들과 차별화된 기술을 가져야지만 임금을 많이 줄 것이다. 이것은 세상의 진리이다. 차별화된 가치가 없으면 누구도 돈을 많이 주지 않는다. 차별화된 가치를 가지고 있으면 누군가가 그 가치에 해당하는 비용을 지불하고 사용할 것이다. 반대의 입장이 되어서 생각해 보면 너무 당연하다. 손자병법에서도 나를 알고 적을 알아야 한다고 했다. 소프트웨어 개발자의 임금을 올려야 한다고 근거 없이 주장할 것이 아니라 내가 다른 사람이 인정하는 그만한 가치를 가지고 있으면 저절로 올라간다.  

공사장의 인부가 30년 경험이 있으니까 임금을 많이 달라고 해야 한계가 있다. 노동 산업이기 때문에 육체적으로 절정에 있고 숙련된 기술이 있을 때 가장 가치가 높다. 아마 30대가 전성기일 가능성이 많다. 바로 소프트웨어에서 코딩이 그렇다. 물론 코딩도 수준이 있다. 하지만 그건 숙련도이다. 구글에서 나이 많은 나이 많은 50,60대의 개발자가 밤도 못 세우는데 왜 임금을 많이 받으면서 일을 할 수 있을까를 생각해 보아야 한다. 바로 건축에서의 설계이다. 설계시에는 시공은 시작도 하지 않았다. 시공은 나중에 누가 하든 할 사람이 많다. 새벽시장의 인부도 얼마든지 구할 수 있다. 소프트웨어 개발자로서 새벽시장의 인부가 되기를 원하는 사람은 없을 것이다. 그런데 새벽 인부시장에서 구출하는 방법을 가르쳐 주어도 절대 나오려고 하지 않는다. 인부들에게 설계를 할 줄 알아야 한다고 말해야 현실적이 아니다. 오랜시간이 걸리고 지금와서 공부를 시작할 수도 없고 너무 어렵다. 그렇게 때문에 조금이라도 일찍 인부가 아닌 설계가가 되도록 노력해야 한다. 옷을 만들 때도 디자이너가 디자인을 하고 수공작업은 중국과 같이 값싼 인부를 사용한다. 소프트웨어라고 다르다고 생각하면 거대한 착각이며 스스로의 가치를 결정짓는 데 엄청난 잘못을 하게 된다. 일단은 소프트웨어나 하드웨어나 옷 만드는 것이나 다 같다라는 관점에서 생각해야 한다. 다른 점은 나중에 발견하도록 한다.

여기서 요새 유행하는 애자일 방법론으로 시공을 미화하고 합리화하지 않기 바란다. 애자일을 잘못 해석하여 영원히 인부의 길로 확실히 자리매김하는 불행한 경우를 많이 보았다. 모짜르트는 곡을 쓸 때 머리로 작곡하고 실제 종이에 적는 것은 순식간에 했다. 생각없이 처음부터 종이에 적어야 좋은 곡이 나올 수 없다. 다른 산업에서의 설계는 소프트웨어에서의 분석단계와 같으니 여기서부터는 분석이라는 용어를 사용할 때 다른 산업에서의 설계를 연상하면 된다.

분석해서 나온 결과를 다른 사람에게 보여 줄수 있어야 한다. 모든 지식산업에서는 머리로 생각을 해야 하고 생각의 결과가 기록되는 문서가 있어야 한다. 생각만 하고 문서를 적지 않고 공사를 해야 한다면 생각의 가치가 없이 또 인부로 전락하고 많다. 역시 임금을 많이 받을 수 없다. 보여줄 수 없으면 사기꾼이나 다름 없다. 모짜르트가 생각만 하고 악보를 적지 않았자면 무슨 가치가 있는가?

소프트웨어 개발자로서의 가치를 높이고 임금을 많이 받으려면 그에 해당하는 기술을 가져야 한다. 그것이 코딩은 아니다. 그렇다면 분석이다. 현실에서는 분석의 결과가 너무 다양한 상태로 나타나기 때문에 운이 좋아 분석의 결과물을 본 적이 있다고 해도 별 것 아닌 것 같이 보이기도 하고 언제든지 따라할 수 있을 것 같지만 착각이다. 손자병법이 A4 용지에 가득 적으면 두 장 밖에 안되는 6천여자에 불과 하지만 어떻게 응용하는 가에 따라 손자병법이 될 수도 있고 그냥 평범한 글자의 집합이 될 수도 있다. 대부분의 사람들에게는 후자가 될 것이다. 추상적인 것에서 원칙을 지키면서 현실에서 응용하는 것이 가장 어렵다. 천재라면 혼자서 그 원리를 파악할 수도 있지만 배우는 것이 효율적이다. 춘추전국시대 때 6천자에 불과한 손자병법만을 보고 손자를 오나라의 대장군에 임명한 오나라 왕 합려도 대단한 통찰력을 가진 사람이다. 천재는 천재를 알아보는 것이다. 그 후에 모든 사람이 손자 병법을 읽었지만 읽은 장군이나 안 읽은 장군이나 적군인 초나라는 3배나 많은 군사를 가지고도 모든 전쟁에서 다 패했다. 손자가 병졸들 같이 칼을 잘 쓴 것은 아니다. 병졸보다 칼 싸움은 못하지만 대장군으로서 인정받아 부귀와 영화를 누리면서 살았다. 병졸들이 칼 싸움을 아무리 잘한다고 한들 한계가 있다. 숙련된 인부도 인부의 한계를 벗어나지 못한다.  

내가 개발자로서 차별화 할 수 있는 가치가 무엇인지를 상식적으로 생각해 보아야 한다. 수 많은 인부 중의 한 사람으로 살겠다면 그건 너무 쉽다. 옆에 있는 수 많은 개발자들이 하는 것과 똑같이 하면 된다. 그러면 모든 개발자는 똑 같은 대우를 받을 것이다. 자신은 머리가 좋다고 생각할지 모르지만 인부세계에서 조금 기술이 더 좋다고 해서 숙련공으로 인정받을 뿐이지 10배, 100배의 가치가 생기지는 않는다. 그 사람이 없더라도 더 싼 숙련공을 여러명 투입해도 된다. 손자는 여러 명의 병졸로 대체할 수 있는 사람이 아니다. 그렇기 때문에 가치가 있는 것이다. 어렵지 않으면 차별화 하기 어려운 인부에 불과하다. 보기에 쉬워 보인다면 다른 사람도 마찬가지이고  차별화 할 수 있는 가치는 아닌 것이 분명하다. 일단 어려워야 한다. 그리고 역설적으로 왜 그런 식으로 시작해야 하는지 이해가 되지 않아야 한다. 모든 사람이 쉽게 설득되어서 시작하게 된다면 또 가치가 작아진다. 오나라와 합려와 손자를 추천한 오자서 두 사람만이 손자병법을 이해했다. 그 후에도 다른 사람들은 대부분 손자를 시기하고 방해했다.

자신의 가치를 극대화 해서 돈을 많이 받기 위해서는 세 단계가 어려워야 한다. 먼저 왜 해야하는 지를 이해하기가 어려워야 하고, 이해했다고 하더라도 원칙을 잘 이해해야 하고, 그랬다고 해도 실전에 응용하기가 어려워야 한다. 그래야만 최고의 가치가 있는 것이고 쉽게 할 수 있다고 한다면 이론적인 방법론에 불과하거나 착각일 뿐이다. 실리콘밸리는 회사에서 그런 환경을 만들어 주어 자신도 모르는 사이에 그런 기술을 쌓아간다. 그러면서 오랜 경험과 함께 어렵게 습득한 가치로 인해 실리콘밸리의 백발이 성성한 개발자들이 많은 임금을 받으면서 회사에서 중요한 사람으로 인정을 받으며 절대 감원시키지 않은 안전한 직업으로 미국에서 가장 인기 있는 직종으로 꼽히는 것이다. 코딩만 열심히 해서는 차별화가 불가능하고 그런 대접을 절대 받을 수 없다. 무엇인가로 차별화를 해야 하는데 그것은 분석 밖에 없다. 분석을 잘하기 위해 첫 단계가 먼저 설계를 잘하는 것이라는 개념만 알려주고 나중에 현실에서 벌어지는 분석과 설계의 미묘하고 애매모호한 경계에 대해서 자세히 설명하겠다. 

분석 #1 소프트웨어의 분석의 본질은 무엇인가?

이 포스트는 필자가 이제 시작하려는 실전 소프트웨어 "분석" 시리즈의 첫 번째 포스트이다. 이전에 포스트한 SWEBOK의 분석단계에 대한 번역을 하면서 소개를 했지만 이 시리즈에서는 현실에 더 가깝고 실리콘밸리에서의 경험을 바탕으로 실무에서 도움이 될 자세한 내용을 적으려고 한다.

소프트웨어는 인류역사상 가장 복잡한 지식산업이다. 지식산업의 특징은 한 사람이 여러 사람을 모은 것 보다도 뛰어날 수 있다. 페이스북의 주커버그가 개발자 1명이 100명보다 더 뛰어날 수 있다고 했다. 바둑이나 체스와 같은 지식 활동에서도 상급자 한 명이 하급자 100명이 합한 것을 이길 수 있다. 이런 지적차이가 없이 백명을 합해서 한명을 이길 수 있다면 노동산업일 것이다. 그럼 소프트웨어의 어떤 부분이 이렇게 큰 차이를 만들어 낼까를 항상 염두에 두면서 지적인 생각을 많이 해야 하는 단계가 언제일까 하는 답을 스스로 찾기 바란다.

   

소프트웨어를 개발할 때 분석, 설계, 구현 단계가 있다는 것은 누구나 다 들어 보았을 것이다.. 그런데 현실에서 제대로 행하기는 쉽지 않다. 분석이라는 단어가 너무 추상적이기 때문이다. 분석을 항상 하면서도 자기는 분석을 안한다고 생각하는 실리콘밸리의 개발자도 있고 분석이 무엇인지도 모르면서 자기는 분석 잘한다고 하는 국내의  개발자도 있다. 마치 야구선수에게 만류인력법칙을 아냐고 물어보면 모른다고 할 것이다. 하지만 공이 떨어지는 궤도를 가장 잘 파악해서 잡아내는 것을 보면 만류인력을 몸으로 잘 실행하고 있는 것이다. 실행면에서 는 물리학교수보다 더 잘한다. 증기기관차를 발명한 사람들도 열역학이 생기기도 전에 발명했다. 그 만큼 분석이라는 단어는 극히 추상적인데다 이론과 현실의 착각에서 부터 모든 사람들이 다르게 해석하고 평가할 수 있는 위험한 단어이기도 하다. 각자 생각하는 분석의 정확한 정의가 다를 수 밖에 없지만 여기서는 실리콘밸리에서 행하는 통상적인 분석을 가정하고 진행한다.

분석을 제대로 하지 않고도 지금까지 소프트웨어 개발자로서 개발하는 데 지장이 없다면 분석이 꼭 필요한 것인가? 이는 내가 인생을 살아가는데 있어서 학교는 꼭 가야하는가? 라는 질문과 비슷하다. 학교를 가지 않아도 생존하는 데는 문제가 없었고 가끔 크게 성공하기도 한다. 결국은 필수냐 아니냐의 문제가 아니고 선택의 문제라고 할 수도 있다. 그런데 경쟁을 해야 한다면 얘기가 다르다. 취미생활이라면 적당히 해도 되고 잘하든 안하든 문제가 없지만 다른 사람과 경쟁을 해서 이겨야 한다면 최선의 방법을 택해야 한다. 필요하다 아니다의 문제가 아니고 경쟁에서는 최선의 방법이 필수가 된다.

소프트웨어를 개발한다는 것은 지적산업이라는 점에서 자동차를 만드는 것이나 그림을 그리는 것과 같다.하는데 그렇다면 개발하는데 지식산업다운 모습을 가져야 한다. 그림을 그리기 전에 스케치를 해야 한다거나 자동차를 만들기 전에 설계를 해야 한다거나 심지어는 옷을 만들기 위해서도 디자인을 해야 한다면 아무도 이의를 제기하지 않는다. 너무 당연하기 때문이다. 그런데 소프트웨어에서 분석을 해야 한다고 하면 안하기 위해 핑계를 대며 노력하는 것이 국내의 현실이다. 억지로 시켜야 할 수 없이 대충 한다. 물론 제대로 잘 하고 있는 가는 나중에 얘기할 또 다른 큰 이슈이기 때문에 여기서는 넘어간다. TV를 보다보면 동물농장이라는 프로에서 가끔 위험에 처한 동물을 구조하려는 경우가 있다. 그런데 동물들이 자신을 위한 것인데도 순순히 구조를 받아들이는 것이 아니라 구조를 당하지 않으려고 갖은 발악을 한다. 이 경우와 비슷하다.

폭포수방법론이니 애자일 방법론이니등 방법론과 분석의 필요성을 연관지어서 생각하는 것은 원칙과 방법론을 혼동해서이다. 폭포수나 애자일 벙법론이 좋다 나쁘다 할 수 있는 것은 아니다. 잘못 해석하면 해악을 끼칠 수가 있다.  애자일 경우에는 분석을 하지 않아도 된다는 착각을 심어주기 딱 좋은 사상을 가지고 있다. 마크 트웨인의 말처럼 건강에 관한 책은 오타로 인해 죽을 수도 있다는 말처럼 착각을 불러 일으켜 해를 끼치기 좋게 되어 있다. 분석의 본질을 이해하기 위해서는 당분간 방법론에 대한 생각을 하지 않는 것이 좋다. "Unteach" 라고 생각을 비워보자. 어렵지만 방법론을 배웠더라도 잠시 안 배운 것처럼 머리에서 지우도록 하자. 구글에서도 분석작업을 하지 않고 설계부터 하는 경우도 많다. 많다기 보다는 겉으로 그렇게 보인다. 필자도 이전에 그랬었다. 그래서 겉으로 보기에 분석작업을 하지 않는다고 생각한다면  착각이다. 하기는 하되 경우에 따라 방법이 다른 것이다. 지금까지 필자가 평생동안 수 백번의 프로젝트를 해 왔지만 똑같은 정형화돤 기법으로 분석을 하는 경우는 없었다. 즉 어떤 샘플이나 템플릿을 보고 작성할 수 는 없다는 것이다. 원칙을 이해해야 하기 때문에 추상적이고 혼란이 생긴다.

분석의 본질은 무엇인가를 실행하기 전에 전체적으로 생각해 보는 것이다. 방법은 그 다음 문제이다. 학교숙제와 같이 한번만 하고 끝날 프로젝트는 굳이 분석에 많은 투자를 하지 않아도 규모가 작기 때문에 큰 피해가 없다. 구동만 되면 된다는 사상이다. 하지만 피해는 크지 않지만 비효율적인 것은 사실이다. 필자는 학교숙제를 비롯헤 간단한 문제를 풀 때로 분석을 하고 설계를 한다. 형식은 때에 따라 다르다. 하지만 아무리 간단해도 분석을 해야 더 빠르다는 것을 몸으로 알고 있다. 국내 개발은 대부분 한탕주의 식으로 진행한다. 미래에 대한 고려를 할 필요가 없는 "이번만 끝내면 된다"는 환경에서는 당연할 수도 있다. 이 세상 모든 일에는 좋은 점과 나쁜 점이 있다. 외국 속담에 어떤 남자가 마음에 드는 예쁜 여자와 결혼을 하고 싶은데 그 여자와 결혼을 하려면 추한 쌍동이 자매를 같이 데려가야 한다는 조건이 있다. 국내에서 문화적으로 성행하게 된 한탕주의 개발이 좋은 점은 다음 차세대 프로젝트를 금방 다시 할 수 있기 때문이다. 개발자들의 수요가 더 많이 필요하고 돈이 잘 도니 경제가 잘 돌아간다고 미화할 수 있다. 그러나 그런 모순적인 방법은 곧 냉혹하고 무서운 현실에 부딪치게 된다. 바로 국제 경쟁력이다.

국내 경쟁력은 별 문제가 없다. 잘못한다고 해도 회사가 개발비용이 조금 많이 들고 품질이 나빠서 고객이 떨어져 나갈 것이다. 하지만 경쟁자도 그렇다면 큰 문제가 아니다. 도토리 키재기이기 때문이다. 그렇지만 치명적인 한계가 온다. 그 한계는 바로 글로벌 경쟁애서 뒤떨어지는 것이다. 그러다 보면 소프트웨어 산업이 황폐화 되고 장기적으로 개발자나 회사나 국가나 모두 피해를 입는다. 그 이유도 모르니 문제를 엉뚱한 데서 찾고 많은 노력을 기울여도 한계가 있다. 지적산업의 특성을 모르기 때문이다.

구글 같은 글로벌 기업에 가 보면 젊은 개발자나 5,60대의 나이 많은 개발자가 똑같이 많다. 감원을 시킬때는 Seniority 라는 방식으로 젊은 사람부터 내보내는 것이 통상적이다. 젊은 사람들은 다시 구할 수 있지만 경력자는 다시 구하기가 어렵고 회사에서 리더가 없어지는 것이기 때문에 타격이 크다. 경력이 많을 수록 전체를 보는 통찰력이 있고 오랜 경험으로 시행착오를 줄인다. 젊은 병졸이 힘이 좋을 지는 모르지만 전쟁을 수행할 수는 없다.

백발이 성성할 때 까지 오래 일하고 연봉이 높아지려면 코딩을 줄이고 전체를 보는 지적인 분석과 설계를 해야 한다. 코딩하는 인력은 나이가 들면 젊은 개발자들에게 떨어질 수 밖에 없다. 믿기 싫더라도 인간의 신체가 그렇게 되어 있다. 젊었을 때 잘 할 수 있는 것이 있고 나이가 들어 잘 할 수 있는 것이 있다. 젊은 사람의 기술만으로는 그 가치가 오래 가지 않는다. 지적으로 성숙해 지고 전체를 볼 수 있는 역량이 바로 백발 개발자의 가치이다.

분석을 "요구사항 분석"등과 같은 단편적인 용어로 표현하면 100% 잘못된 상상을 하게 된다. 분석은 절대로 남을 따라하거나 어떤 것을 흉내 내서 되는 것이 아니다. 대충해서도 안된다. 바둑을 대충 두면서 이기기를 바란다면 망상이다. 목적에 따라 적절한 수준으로 해야 중요한 가치가 있다. "적절히"와 "적당히"는 다르다. "적절히"는 현실을 고려한 유연성을 의미하지만 "적당히"는 소프트웨어에서 만병의 근원이다. "행동하기 전에 충분히 생각하고 적어서 정확히 표현해라." 하는 것이 지금의 추상적인 수준에서 분석의 본질에 대해 말할 수 있는 표현이다. 

여기서는 지식산업의 핵심과 소프트웨어에서의 어떤 부분이 지식산업의 핵심일까 하는 것을 생각해 보는 기회로 하자. 앞으로의 포스트에서는 여러 관점에서 구체적으로 들어가 보자.