brunch

매거진 근본적 한계에 대한 단상들

라이킷 18 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by Amang Kim Jul 06. 2016

8. 자아성찰에 관한 이야기

자아성찰을 가장한 책임 회피

오늘은 수학과는 거리가 먼, 그렇지만 한번즈음 다뤄보고 싶었던 이야기를 하고자 한다. 사실 이런한 이야기를 예전에 하고 싶었지만, 얼마전까지 여름학기를 진행하느라 정신이 없었던터라 이제야 글을 쓰게 되었다. 최근에 삼성에서 Software역량에 대해서 통렬한 자아성찰 혹은 셀프 회초리(?)를 들었다고 하여, 회자가 된적이 있다. 그리고, 오늘(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에 문제가 있다면, 코딩 패치를 해야하고, 조직에 문제가 있다면, 조직 변화를 위한 행동을 해야 한다. (행동이 없으면, 결과는 없다). 하지만,

문제를 정확하게 파악하지 못하면, 제대로 된 문제 해결을 할수가 없다.

뿐만 아니라, 문제 해결을 위한 일련의 실행(action)들은 아무 의미가 없어진다. 정확하게 문제를 파악(근본원인에 대한)을 하고 있다고 하더라도, 그에 맞는 실행계획을 짜는 것과 이것을 실제로 실행을 하는 것은 또 다른 문제 이다. 다만, 확실한 것은 이러한 조직 개편 활동을 크게 세가지 즉, 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. 마치며

그래서, 어쩌라는 거냐? 라고 하실 분들이 있을 것이다. 실제로 여러가지 제안 해볼만 시도들이 있기는 하지만, 어떤 방법이 성공할지에 대해서 확신할 수 없다. 따라서, 그에 대해서는 여기서 언급하지 않겠다. 하지만, 반드시 감안해야 할것과 해서는 안될 시도들은 확실하게 이야기 해 줄 수 있다:

[반드시 감안해야 할것]

1. Software Architect는 제대로 된 인력 소수면 된다 (1~3%이내).

2. 제대로 할려면 전권을 이양 해야한다. 하지만, 그럴 경우 권력 남용의 우려가 있다.

3. Software Architect"만" 한 인력은 수장이 될 수 없다.

4. 남의 떡(구글, 페이스북등)만 너무 부러워하지 말라.

5. 내(삼성)가 가지고 있는 패가 무엇인지 먼저 알아야 한다.

6. 여름엔 변화를 시도할 여유가 있지만, 겨울이 되면 시도 조차 못한다 (곧 겨울 온다).

[해서는 안되는 시도들]

1. 유명하다고 하는 아키텍트을 무턱대로 영입하는 것

2. 아키텍트 키운답시고, 무리하게 양적 팽창을 하는 것

3. 단기적인 성과 기대

4. 한꺼번에 모든걸 바꿀려는 시도