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

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