오늘은 수학과는 거리가 먼, 그렇지만 한번 즈음 다뤄보고 싶었던 이야기를 하고자 한다. 사실 이러한 이야기를 예전에 하고 싶었지만, 얼마 전까지 여름학기를 진행하느라 정신이 없었던 터라 이제야 글을 쓰게 되었다.
최근에 삼성에서 Software 역량에 대해서 통렬한 자아 성찰 혹은 셀프 회초리를 들었다고 하여, 회자가 된 적이 있다. 그리고, 오늘(2016년 7월 6일)에도 한 차례 더 신랄 자기 성찰을 했다 하여, 페이스북 친구분들이 피딩을 해주셨다. 혹시라도, 해당 기사들이 궁금하시다면 다음 링크를 참고하시라:
[중앙일보 6월22일자] “SW 역량 구글의 100분의 1”…셀프 회초리 든 삼성
[머니투데이 7월5일자] 삼성 또 자기반성, “구글은 알파고 만들었는데…”
이 기사들의 골자는 이렇다. 첫 번째 기사에서는 삼성개발자 역량이 세계수준(“구글”이라 콕 짚어 이야기했다)의 1/100에 못 미친다. 그리고, 어제 기사를 보면, 아키텍쳐 역량을 강화해야 한다고 이야기하고 있다. 이게 통렬한 자아 성찰이었노라고 자화자찬하면서 말이다.
즉, 한마디로 이야기하면, 삼성의 지금 위기는 개발자들이 아키텍쳐적 역량이 세계 수준이 미치지 못하기 때문이라는 건데 요약하자면, 삼성의 지금 위기는 개발자들이 구글보다 실력이 딸(?)려서, 그중에서도
아키텍쳐 역량 부족 때문에,
지금의 위기를 맞은 근본적인 원인이라고 결론을 맺었다. 오늘 하려고 하는 이야기는 수학 이야기는 아니지만, 과연 위의 원인 분석 타당한 것인지에 대해서 논해보고자 한다.
1. 과연 아키텍트의 부재가 원인인가?
위의 명제에 대한 본격적인 논리를 시작하기 전에, 나와 나름 친한 페이스북 친구분께서 언급하신 것 때문에 이 부분을 먼저 이야기 해야 할 것 같다.
우선, 삼성 내에서는 다수의 Software Architect들이 있다. 내가 몸담고 있던 부서에도 있었다. 그리고, 이러한 육성체계가 엄연히 존재한다. 최소한 SW아키텍 과정을 최소한 10년 이상 운영해왔었고, 이 육성체계는 삼성에서 진행하고 있는 많은 전문가 육성체계중에서도 굉장히 까다로운 쪽에 속한다.
우선, 선발 조건 자체도 까다롭다. 2년 연속 상위 고과를 받아야 하고, 그쪽 계통 일(Software 개발)을 하고 있어야 한다. 설령, 선발이 되었다 하더라도, 1년 이상 상시 교육을 완료하고 프로젝트를 완료해야 인증을 받을 수 있으므로, 선발되었더라도, 인증을 받은 인력은 훨씬 더 적다.
그리고, 초장기에는 교육과정 중에 미국에서 CS로 유명한 C대학에서 직접 교육을 받는 것이 포함되어 있어서, 교육과정중 치르는 시험에서 특정 점수 이상을 획득해야 했었다. 참고로, 지금은 이러한 상시 교육과정을 국내에서 진행하고 있다.
물론, 외형적으로 보이는 교과과정만으로 해당 과정의 질을 보장할 수는 없다. 더구나, 내가 컴맹인지라, 질 자체에 대한 평가를 할 수조차 없을 것이다. 하지만, (정황상 증거로 봤을 때) 나쁘지 않은 SW아키텍트 육성체계가 존재했었고, 지금도 운영되고 있다는 것은 확실하다.
삼성에는 소프트웨어 아키텍을 포함한 “전문가”과정이 다수 존재한다. 이렇게 많은 전문가 과정들 가운데 지역 전문가 과정처럼 여전히 인기가 있고, 잘 운영되고 있는 전문가 과정들도 있지만, 소프트웨어 아키텍트같은 기술 전문가 과정이나, MBB(Six-Sigma Master Black Belt) 와 TRIZ Level 3과 같은 혁신 전문가 과정들처럼 “실패한” 전문가 과정들도 있다.
위에 언급된 기술이나 혁신 전문가 과정들은 지금도 명맥은 유지하고 있지만, 틀림없이 “실패한” 육성 체계이다.
적어도 이러한 전문가 육성체계는 틀림없이 운영되고 있으며, (적어도 시작은) 체계화 잘 되어 있다. 하지만, 가장 근본적인 문제 중 하나는 이렇게 힘들게 양성한 인력들을 제대로 활용하지 못한다는 점이다. 다시 말해서, 해당 과정을 마치고,
전문가가 되어서도 이전과 똑같은 일을 할 수 밖에 없는 구조
라는 것이다. 이것이 구조적인 이유일 수 밖에 없는 이유는 선발 과정에서부터 찾을 수 있는데, 선발하는 인력이 우선 상위 고과자이어야 한다.
상위 고과자라는 의미는 (적어도 무선사업부에서는) 모델 개발에 직접 관여하는 인력이라는 의미이고, 이러한 인력은 바로 윗분(해당 부서 팀장) 입장에서는 핵심인력(윗분들 고과에 직접적인 영향을 미치는)이다.
그러므로, 우선 이런 인력들을 이러한 교육과정에 보내는 것 자체를 꺼리는 경우도 많다. 하지만, 괜찮은 팀장분들은 이러한 핵심인력들의 역량개발을 위해 흔쾌히 보내주기도 한다. 단, 전문가 과정을 마치고 “돌아오는” 것을 전제로.
이게 무슨 이기적인 발상이냐고 하실 분들도 계시겠지만, 본인이 팀장이나 부서장이라면 조금은 이해가 될 것이다. 생각을 해보라. 자기 고과에 가장 영향을 미치는 핵심인력이 6개월~1년 동안 (상시이긴 하지만) 자리를 비우고, 이후 과정 이후에는 다른 부서에 빼앗겨야 할 상황이라면, 어느 부서장이, 팀장이 자기 핵심인력을 그러한 교육과정에 보내주겠느냐는 말이다.
설령, 우여곡절 끝에 인증을 받았다 하더라도, 이렇게 예전 자리로 돌아온 전문가들은 전문가로서의 역량을 발휘할 수 있는 새로운 일을 하기에는 큰 무리가 따른다. 또 하나의 큰 문제점은
양적 팽창이 질적 저하를 만든다
는 점이다. 난 소프트웨어 아키텍트는 아니지만, TRIZ Level 3 전문가 과정을 초창기에 이수했었다. TRIZ는 한국에서는 포스코와 삼성이 주도적으로 추진했던, 혁신적 문제 해결 방법론이다 (TRIZ가 무엇인지 궁금하신 분들은 Wikipedia를 참고하시라).
Level 1~5까지가 존재하며, Level 인증은 MATRIZ라는 공인 단체를 통해서 받게 되어 있다. 2009년 즈음, 이 방법론이 윗분들의 주목을 받기 시작하면서, 인기를 끌기 시작했는데, 이때부터 TRIZ Level 1은 온라인 과정으로 Level 2는 교육과정으로 전사원들이 인증을 받도록 했었다.
즉, 윗분들이 혁신적 문제 해결론이 핵심역량이라 생각하셨으리라. 이러한 공격적인 전사 활동에 가장 큰 폐해가 있었으니, 양적 팽창을 하게 되면서 실질적으로 인증받은 인력들이 인증을 받을 만큼의 실력을 갖추지 못한 것.
인증 후에도 꾸준히 공부하지 않으니 가뜩이나 없던 실력에 시간이 갈수록 없던 실력조차도 더 없는 그런 전문가들이 배출되었다. 당연히, 그렇게 나온 인증자들이 자기 분야에 이러한 혁신 방법론을 적용할 리 만무하다.
이러한 TRIZ Level 2 과정이 처음부터 이렇게 엉망이 되었느냐 하면, 그건 아니다. 적어도 내가 TRIZ Level 2를 인증을 받을 땐, 엄청 까다로웠었다. 교육 과정 또한 서울까지 와서(참고로, 내 근무지는 구미였다는 점을 감안하시라) 교육을 받았었다.
처음 선발이 될 당시에도 내 고과가 바닥이었던 지라, 처음 신청했을 때는 퇴짜, 두 번째 신청했을 때도 당시 팀장님의 도움으로 간신히 선발되었었다. 그리고, 이 당시에 이 바닥에 발을 들인 나는, 지금도 이걸로 먹고살고 있다.
물론, 계보 상으로는 TRIZ를 가르치는 것은 아니지만, Sytematic Innovation (혹은 Practical Innovation)이라는 이름으로 TRIZ를 기반으로 한 혁신 방법론을 가르치고 있다 (혹시, 이게 무엇인지 궁금한 분들이 계신다면, Innovative Design Guidebook for Game Changers란 책(e-Book)을 참고하시면 되겠다-공짜임). TRIZ Level 2의 다음 단계인, Level 3은 (적어도 2007년 당시에는) 소프트웨어 아키텍트 만큼 가치가 있었던 인증이었었다. 물론, 이후에는 개털이 되었지만 말이다.
소프트웨어 아키텍트과정도 초장기에는 인증과정이 굉장히 까다로웠었다고 한다. 더구나, 시간제한도 있어, 교육 이수 후에 몇년 내에 프로젝트를 완료하지 못하면, 처음부터 다시 시작해야 했었다.
교육과정 중 몇 달은 미국에 가서 직접 수업을 들어야 했었고, 교육을 마치더라도 프로젝트를 일정 내에 끝내지 못해 인증을 포기했던 사람들도 부지기수였다. 사실, 윗분들께서 SW아키텍트들에 대해서 관심을 가지기 시작한 시점은 2011년 언저리부터였다.
이후 여전히 절대적은 숫자는 작아도, (기존 인증 인력대비) 어마어마한 양적 팽창을 했었다. 미국 가서 듣는 과정은 국내 집합 과정으로 대체 되었고, 최종 프로젝트 심사도 내부전문가들이 한다(이게 무얼 의미하는지 아는 사람은 알겠지).
그리고는 6년이 흘렸다. 삼성이 말하는 소위 “아키텍트 부재”라는 원인 명제가 이전에 삼성에서 윗분들이 강하게 추진했던, 그러다 개박살난 전문가 과정들(Six-Sigma BB, MBB, TRIZ Level 2, Level 3)과 겹쳐 보이는 건 나만의 편견일까?
2. 보다 근본적인 원인
삼성이 가지고 있는 가장 큰 문제는 문제에 대해서, 정확한 근본 원인을 찾으려 하지 않는다. 더 정확하게 이야기하자면,
근본적인 문제 찾는 것을 너무나 만만하게 본다
는 것이다. 일전에 언급되었던 수평적 조직 문화를 위해 호칭을 없앤다고 했던 것도 그렇고, 이번 건도 그렇고, 찾아낸 원인이라는 것이 정말 지금의 문제를 유발하는 근본적인 원인인지, (어떤 원인에 의한) 결과인에 대한 진지한 고민이 없다.
문제를 해결하기 위해서는 문제 해결을 위한 일련의 활동들, 즉, Action을 취해야 한다. 그래서, Operation에 있어서, 계획만큼 중요한 것이 실행력이다. Software에 문제가 있다면, 코딩 패치를 해야 하고, 조직에 문제가 있다면, 조직 변화를 위한 행동을 해야 한다. (행동이 없으면, 결과는 없다). 하지만,
문제를 정확하게 파악하지 못하면, 제대로 된 문제 해결을 할 수가 없다.
뿐만 아니라, 문제 해결을 위한 일련의 실행들은 아무 의미가 없어진다. 정확하게 문제를 파악(근본 원인에 대한)하고 있다고 하더라도, 그에 맞는 실행계획을 짜는 것과 이것을 실제로 실행을 하는 것은 또 다른 문제이다.
다만, 확실한 것은 이러한 조직 개편 활동을 크게 세가지 즉, 1) 근본원인 분석, 2) 실행계획 3) 실행으로 나눈다고 했을 때, 들어가는 시간과 공(Resource)의 양은 반드시:
문제원인 분석 >> 실행계획 > 실행
의 순이라는 것이다 (부등호 표시에 유의하시라). 물론, 양이 많다는 것이 양질을 의미하지는 않지만, 위의 세 과정 모두 치열하게 해당 활동을 수행했다는 것을 전제로 한다. 문제 원인분석이 얼마나 중요한지는 아인슈타인 할배께서도 아주 극단적으로 다음과 같이 언급하셨다:
“If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.”
예를 들자면, 이런 거다. 어떤 기업이 조직 개편을 한다고 하자. 이 회사가 조직 개편 완료를 시작일로부터 6개월 내에 성공적인 조직 개편을 하기 위해서는, 최소한 6개월 이상의 세부적인 실행계획을 세워야 하고, 근본적인 원인을 파악을 하는 데는 그보다 훨씬 더 많은 시간과 공을 들여야 한다.
3. 마치며
그래서, 어쩌라는 거냐? 라고 하실 분들이 있을 것이다. 실제로 여러 가지 제안 해볼 만 한 시도들이 있기는 하지만, 어떤 방법이 성공할지에 대해서 확신할 수 없다. 따라서, 그에 대해서는 여기서 언급하지 않겠다. 하지만, 반드시 감안해야 할 것과 해서는 안 될 시도들은 확실하게 이야기해 줄 수 있다:
[반드시 감안해야 할것]
- Software Architect는 제대로 된 인력 소수면 된다 (1~3%이내).
- 제대로 할려면 전권을 이양 해야한다. 하지만, 그럴 경우 권력 남용의 우려가 있다.
- Software Architect”만” 한 인력은 수장이 될 수 없다.
- 남의 떡(구글, 페이스북등)만 너무 부러워하지 말라.
- 내(삼성)가 가지고 있는 패가 무엇인지 먼저 알아야 한다.
- 여름엔 변화를 시도할 여유가 있지만, 겨울이 되면 시도 조차 못한다 (곧 겨울 온다).
[해서는 안되는 시도들]
- 유명하다고 하는 아키텍트을 무턱대로 영입하는 것
- 아키텍트 키운답시고, 무리하게 양적 팽창을 하는 것
- 단기적인 성과 기대
- 한꺼번에 모든걸 바꿀려는 시도
- 회사에 위기가 닥쳤다고 실무자들을 까는 것
조직 혹은 회사에서의 자아 성찰이라는 것은 두루뭉술한 원인을 가지고 누군가의 면피를 위해 다른 누군가를 까는 것이 아니라, 정말 무엇이 중요한지를 치열하게 알아 가는 과정이 아닐는지?
원문: Amang Kim 의 브런치
