강소기업, 성장통을 넘다

강소기업, 성장통을 넘다

이용훈, 휴맥스 혁신실 지음

메디치미디어 / 2013년 4월 / 240쪽 / 14,000원





1부 혁신의 주요 원칙들 - 비즈니스와 오퍼레이션은 함께 성장해야 한다



제대로 돌아가고 있나? 이제는 아무것도 보이지 않는다

우리 회사 변대규 사장을 가리켜 다들 ‘훌륭한 CEO’라고 말한다. 시장이 앞으로 어떻게 움직일 것인지에 대한 선견지명과 추진력으로 휴맥스가 화려한 벤처 신화를 일구는 데 큰 몫을 했다. 초창기에는 회사 운영에서도 좋은 성과를 냈다. 그는 직원이 100명 정도일 때까지 회사 운영에 관련된 세부 사항을 속속들이 들여다보았다. 각종 프로젝트 진행 상황은 물론, 생산 상황을 훤히 파악하고 문제가 발생하지 않도록 관리했다. 그런데 직원이 150명 선에 이르면서 문제가 생기기 시작했다. 초창기 10년 동안 휴맥스의 직원 수는 100명 이내였는데, 2000년대 들어서는 1년 동안 무려 80명이 증가했다. 그렇다 보니 기존 직원과 새로 들어온 직원 간의 문화적 충돌이 생기고, 업무상 소통 문제가 발생했다.

그리고 성장 규모에 맞게 운영(이 책에서 운영, 즉 오퍼레이션은 개발ㆍ품질 영역과 SCM -Supply Chain Management; 공급망 관리- 영역의 업무를 말한다) 수준을 업그레이드해야 하는데 적절히 대응하지 못했고, 결과는 뼈아팠다. 자재를 잘못 발주해서 과잉이 되거나 공장이 멈추고, 잘못된 정보를 바탕으로 일을 진행했다가 나중에 되돌리는 건 기본이고, 누가 무슨 일을 하고 있는지, 프로젝트의 진행 상황은 어떤지, 제때 납품이 가능한지 알 수 없는 상황도 빈번히 발생했다. 직원들 역시 일을 하면서도 이런 차질 때문에 예전과는 달리 즐거움을 느끼지 못했다. 결국 그런 비효율을 잘나가는 매출로 커버하던 것도 한계에 이르렀다. 직원들 사이의 신뢰도는 그렇다 쳐도 고객의 신뢰도까지 떨어지기 시작했다. 2005년을 앞둔 겨울, 변 사장의 머릿속은 ‘혁신’이라는 말로 가득 찼다. 하지만 ‘어떻게 혁신할 것인가’를 두고 머릿속은 점점 복잡해졌다.

혁신, 그것만 고민하는 사람이 있어야 한다

2004년 12월, 혁신실이 설립되었다. 혁신실장은 휴맥스 초기 개발 엔지니어였다가 나중에 해외영업을 맡은 내게 주어졌다. 혁신실의 초기 인원은 4명이었다. 실원 3명은 그전에 연구소에서 자체적으로 개선활동을 하기 위해 입사한 프로세스 개선요원들이었는데, 전사조직화되면서 합류했다. 당시 사장은 어떤 일이든 중요한 것이라면 출근해서 퇴근할 때까지 그것만 하는 사람이나 조직이 있어야 성공할 수 있다고 생각했다. 지금껏 성공했던 일을 돌아보니 그런 일들에는 공통적으로 그것을 전담하는 누군가가 항상 있었다는 것이다. 이 원칙을 혁신활동에도 적용했고, 결과적으로 그 원칙이 성과를 거둔 가장 큰 이유로 보인다.

지식의 정도가 혁신 성패의 바로미터다

기업의 성장은 비즈니스 전략과 운영, 이 두 가지가 균형 있게 발전해야 가능하다. 우리 회사는 창업에서부터 성장에 비례하여 비즈니스 역량도 성장했다. 그런데 우리의 운영 수준은 옛날 그대로였다. 나는 바로 그 문제가 우리에게 위기를 가져왔다고 판단했다. 운영 수준을 끌어올리기 위해서는 혁신을 단행할 수밖에 없었다. 프로세스, 조직, 사람 모두 혁신해야 했다. 그렇다면 어떻게 혁신할 것인가? 나는 일단 품질경영학 관련 고전을 찾아 읽고, 때로는 책가방을 메고 교육을 받으며 운영 원리에 대해 집중적으로 파고들었다. 그 과정에서 나는 모든 회사는 시장 위험(Market Risk), 즉 제품이 시장에서 팔리지 않는 위험뿐 아니라, 운영 위험(Operation Risk), 즉 운영을 잘못한 내부 문제로도 좌초될 수 있음을 깨달았다. 당시 우리 회사는 한 해 불용재고로 버리는 돈만 무려 100억 원에 달했다. 이런 수준에서 만약 시장 매출이 뒷받침되지 않는다면 회사는 재기 불능 상태로 치달을 수도 있다. 매출로 비효율의 비용을 충당하며 영업이익을 깎아먹던 시절, 운영의 효율성을 어떻게 확보하느냐에 회사의 운명이 달려 있다 해도 과언이 아니었다.

그러던 중 SCM 분야의 국내 최고 전문가 중 한 명인 주요섭 대표에게 컨설팅을 받게 되었다. 이번에는 이전과는 달리 시간과 범위를 특정하는 단발성 프로젝트 방식이 아닌, 회사가 성숙하는 진도에 맞추어 꾸준히 지도 받는 방식을 택했다. 그 지도를 받은 3년과 그 이전의 혁신 프로젝트들의 가장 큰 차이점은 지식을 제대로 공급받아 활용했다는 것이다. 얻은 지식을 끊임없이 의심하고 현업에 적용하고 수정하는 과정을 통해 이해가 깊어졌고, 그런 뒤의 혁신은 점차 올바른 방향을 잡아갔다. 그 과정에서 나는 혁신이 성공하기 위해서는 인내가 필요하다는 것을 깨달았다.

나는 학생처럼 혁신에 대해 배우러 다녔고, 관련 서적도 닥치는 대로 독파했다. 그리고 그렇게 공부한 내용을 일주일에 한 번씩 사장에게 보고했다. 사장 역시 별도로 혁신에 관한 모색을 하며 지식을 쌓아나가고 있었던 만큼, 나의 보고를 받으면서 부족한 부분들을 도출하며 혁신의 개념 체계를 단단히 잡아나갔다. 아무튼 사장은 묵묵히 연구가 진척되는 것을 지켜보며 기다려줬다. 혁신의 성장곡선은 S자 곡선을 그린다. 어느 임계치까지는 아무 일도 일어나지 않는 것처럼 보이지만, 임계점을 벗어나는 순간 갑자기 성과가 나오기 시작한다. 이것은 회사 업무에 잃어버린 고리들이 다수 존재하기 때문이다. 고리를 한두 개 끼웠을 때는 별로 달라져 보이지 않지만, 어느 정도 끼워진 뒤에는 갑자기 프로세스들이 잘 돌아가기 시작한다. 채워진 고리를 타고 일이 제대로 흐르기 시작하는 것이다.

분산된 책임감의 함정, 악순환의 근원을 찾아라!

당시 우리 회사가 직면한 총체적 문제는 ‘사고’라는 형태로 그 증상을 드러냈다. 개발 일정에 차질이 생기고, 생산이 불안정한 상태가 지속됐고, 불용재고가 과하게 쌓이고 있었다. 나는 그 이유를 찾기 시작했다. 원인을 찾던 중 직원들이 공통적으로 하는 ‘바쁘다’는 말에 주목했다. 다들 사고가 나면 “정신없이 바빠서……”라는 말을 가장 먼저 했다. 맞는 말이었다. 그렇게 정신없는 상황에서 수행한 업무다 보니 당연히 실수가 생길 수밖에 없었다. 그러면 그것이 또 사고가 되어 그것을 해결하기 위해 매달려야 하는 악순환의 고리가 끊이지 않았다.

영업팀은 프로젝트를 수주하고 나면 개발팀의 업무가 으레 늦어질 것을 예상하고 납기일을 당기거나 희망치가 담긴 부풀려진 수량을 보고했다. 구매팀은 필요한 자재보다 더 많은 양을 주문했다. 자재가 부족해서 라인이 멈추는 것을 방지하려는 의도였지만 그 결과는 결국 과잉 재고 급증으로 나타났다. 그런데 사실 내가 파악한 회사의 진짜 문제는, 직원들이 바빠서 중요한 업무를 놓치고 있는 것이 아니라 ‘바쁘다는 이유를 그대로 수용하는 회사의 분위기’에 있었다. 실수를 해놓고도 “바빠서 그만……”이라고 하면 “그래, 바빠서 그랬으니 할 수 없지”라며 넘어가는 게 예사였다.

즉 사고를 대하는 회사의 태도가 문제였다. 이것이 바로 악순환의 근원이었다. 여러 사람이 있을 때, 그리고 그 책임을 공유하고 있을 때는 자발적 행동이 나오기 힘들다. ‘분산된 책임감의 함정’이라고 할까? 길거리에서 누군가 어려움을 당하고 있는데, 주변에 아무리 사람이 많아도 쉽게 나서서 도와주는 사람이 없는 경우가 있다. 다들 무심결에 ‘굳이 내가 아니더라도 누군가 나서겠지’ 하고 생각하는 것이다. 하지만 특정인을 지목해서 도와달라고 하면 그제야, 하지만 기꺼이 도와준다. 즉 누군가에게 무엇을 요구할 때는 구체적으로 요구해야 행동을 유발할 수 있다. 이런 식으로 행동을 유발하는 책임은 회사에 있다. 여기까지를 비판적 사고(Critical Thinking, 인과관계를 밝혀 그에 따라 판단을 얻고 행동하는 것. ‘왜’를 여러 번 묻는 방식으로 근본 원인을 추구한다) 방식으로 정리하면, 증상은 사고와 바쁨(정신없음)의 악순환이고, 그 원인은 과정(프로세스)을 개선하는 체계적 활동이 없었음이며, 다시 그에 대한 근본 원인은 회사가 체계적 개선을 명시적으로 요구하지 않았다는 것이다. 나는 근본 원인을 알아냄과 동시에 개발과 SCM 영역에 대해 혁신의 방향을 담은 혁신전략을 수립하여 향후 세부 방안들이 잘 정렬되도록 하는 일을 시작했다. 그런데 또 다른 근본적이고 구조적인 문제가 있었다.

프로세스란 무엇인가?

혁신활동 초기, 내가 많은 시간을 할애해 고민한 것은 ‘프로세스란 무엇인가, 어디에 쓰는 물건인가’였다. 수많은 텍스트를 바탕으로 토론하고 숙고한 결과 프로세스는 ‘반복적인 업무에 대해 그 성과를 개선할 수 있도록 해주는 장치’라는 결론을 얻었다. 반복되는 상황은 인과관계의 규명을 가능하게 하고 이를 통해 프로세스를 개선하면 그 결과로 성과의 개선이 나타날 수 있음을 의미한다. 즉 프로세스를 의도적으로 바꾸어 성과의 개선을 의도할 수 있다는 것이다.

프로세스의 핵심은 ‘반복’이라는 속성에 있다. 반복하면 ‘인과관계’가 보인다. 즉 어떤 방식으로 일을 하면 어떤 결과가 나온다는 것을 예상할 수 있다. 가령, 출근하는 장면을 보자. 경력 10년차는 출근을 2,000번 정도 했다고 유추할 수 있다. 아침에 눈을 떠서 하는 행동이 매일 반복된다. 눈을 뜨자마자 욕실에 가서 얼굴과 몸을 씻고 나와 옷을 입은 뒤, 간단히 아침 식사를 하고 집에서 나와 자가용이나 대중교통을 이용해 회사에 도착한다. 이때 바라는 바는 가능하면 빠른 시간에 집을 나서는 것일 것이다. 시간이 흐를수록 동시에 할 수 있는 일을 가급적 많이 찾아 하거나 준비할 것을 최대한 어제 저녁에 미리 준비해놓는 식으로 아침에 쓰는 시간을 줄일 수 있을 것이다. 이처럼 어떤 방식이 출근 준비 시간을 줄이고 더 효율적으로 만들 수 있는지를 찾는 과정에서 최적의 프로세스가 형성된다.

업무도 마찬가지다. 더 좋은 결과를 얻기 위해 어떤 인풋을 넣어야 하는지를 찾기까지는 안정된 반복이 필요하다. 이상과 같이 프로세스를 갖추는 첫 번째 목적은 개선방안을 찾을 수 있는 일정한 틀을 갖는 데 있다. 두 번째는 회사 업무는 많은 사람들의 협업인 만큼, 각자 언제 어느 지점, 어느 순간에 투입되어 어떤 일을 할지를 알도록 하여 일사불란하게 돌아갈 수 있게 하기 위함이다. 세 번째는 품질의 향상이다. 프로세스가 향상되면 그 결과물인 제품의 품질도 향상된다. 보이지 않는 무형의 자산을 다루는 지식 기반 산업에서는 특히 더 그렇다. 나는 이러한 연구결과를 바탕으로 프로세스를 보다 효율적으로, 그리고 탄탄하게 만드는 것이 혁신의 핵심이라는 사실을 확신했다.

프로세스의 확립과 동시에 수립되어야 하는 건 R&R(Roles & Responsibilities)이다. 어떤 직무가 필요한지, 그 직무가 언제 어떻게 들어와서 무슨 일을 하는지를 프로세스의 흐름에 따라 표시해야 한다. 프로세스 없이 R&R을 정하면 업무가 조직의 형태나 특정 개인에 의존하는 의존성이 생긴다. 이렇게 의존성이 생기면 회사의 역량 발전에 발목이 잡힐 수 있다. 그리고 R&R을 영업ㆍ개발ㆍ생산 식으로 조직구조 단위로만 정의하면, 프로세스의 개선이 원활하게 이뤄지지 않는 문제가 발생한다. 일이 진행되는 흐름을 기준으로 프로세스를 먼저 그리고, 그에 맞춰서 어느 지점에 누가 들어와 어떤 일을 한다는 식으로 직무를 정의해서 R&R을 명확히 세워야 한다.



2부 개발 혁신 - 보이지 않던 것을 보이게 하라



구조적인 문제는 구조적으로 풀어라

회사가 혁신에 돌입한 2005년, 당시 회사의 모든 직원들은 지칠 대로 지쳐 있었다. 원인은 끊이지 않는 사고와 수습으로 늘어지는 일정에 있었다. 사고 수습도, 원래 계획된 일도 늘어지는 중에 잘잘못을 탓하는 일로 언성이 높아지기 일쑤였다. 진짜 큰 문제는 비슷한 문제가 여기저기서 같은 모습으로 나타나고 있었다는 점이다. 당시에는 개발자들이 각 사업부마다 나누어 일을 했는데, 8층에서 헤매는 내용과 똑같은 문제로 9층에서도 헤매고 있었다. 심지어 9층에서는 해결한 문제를 8층은 아직 해결하지 못해 밤새 머리를 쥐어짜는 경우도 있었다. 이를 안타까워하던 사장이 용단을 내렸다. 개발자들을 일단 편하게 해주고 격려하자는 것이었다. 수요일은 무조건 정시퇴근이라는 지시가 내려졌다. 그렇게 몇 달이 흘렀지만 눈에 보이는 변화는 없었다.

당연한 결과였다. 우리가 범한 실수는, 당시 문제가 구조적인 데 있는데도 불구하고 이를 정면으로 풀지 않고 단편적인 방법으로 해결하려고 했던 데 있다. 소프트웨어 개발자의 업무는 최종적으로 소스코드를 짜는 형태로 나타난다. 소스코드(Source Code)란, 기계를 작동시키는 명령어 코드를 원천적인 프로그램에서 추출하여 사람이 읽고 다룰 수 있게 한 것이다. 소스코드는 글자 하나하나가 엄청나게 중요하다.

소스코드에 오류가 있으면 기계는 그것대로 작동한다. 실제로 해외에서는 소스코드에 ‘.’이 들어가야 할 자리에 ‘,’가 잘못 들어갔다는 이유로 엑스레이 기계가 오작동하여 사람이 죽은 경우도 있다. 셋톱박스 한 대가 제대로 작동하기 위해 필요한 소스코드는 무려 수백만 줄에 이른다. 그런데 소프트웨어 개발을 관리하는 것은 쉬운 일이 아니다. 몇 년 전까지 우리 회사도 그랬다. 이유가 무엇일까? 내가 생각하는 가장 큰 이유는 이 일이 ‘보이지 않기’ 때문이다. 지금 무슨 일을 하고 있는지, 일의 진도가 어디까지 나갔는지 당사자가 아니면 알 수 없다. 사실 당사자라고 해도 잘 모를 수 있다.

문제는 구조적인 데 있었다. 하지만 보이지 않는다는 이유로 회사는 관리에 철저하지 못했고, 상식적인 수준에서 생각할 수 있는 몇 가지 조치를 시도했을 뿐이다. 고름이 깊은 상처에 반창고 정도를 붙인 격이었다. 그렇다면 이 문제를 어떻게 풀어야 하나? 일에 어떤 속성이 있다면 그 속성에 맞춰 프로세스를 혁신해야 한다. 즉, 보이지 않는 것을 보이게 해주는 방법으로 프로세스를 혁신해야 한다.

프로세스, 새로 짜고 반복하라, 개선하고 또 반복하라

우리 회사의 운영은 크게 개발 영역과 SCM 영역으로 나뉜다. SCM도 그렇지만 개발 영역에서 가장 큰 어려움은 이것이 보이지 않는다는 점이다. 여기서 보이게 한다는 것을 좀 더 구체화하면 ‘어디까지 진척됐는지’와 ‘잘됐는지’라고 할 수 있다. 이에 따라 우리가 단행한 개발 프로세스 혁신의 최종 목표 또한 ‘업무 가시성 확보’와 ‘퀄리티 보장’이 되었다. 그런데 업무에 프로세스가 중요하다는 것은 보이는 일이든 보이지 않는 일이든 상관없이 적용되는 명제다. 보이지 않는 업무도 반복적일 것이기 때문이다. 그렇다면 그 논리를 가시성과 품질을 확보하는 데도 적용해야 한다는 것 또한 타당한 명제가 된다.

그렇다면 프로세스는 어떻게 짜야 할까? 우리는 일단 현재의 프로세스부터 명확화ㆍ정형화하기 시작했다. 먼저 현업에서 각 담당자들을 만나 하는 일을 순서대로 자세히 설명하도록 했다. 업무상 필요한 정보는 무엇이고 그것은 누구에게 받는다, 내가 맡은 단계에서의 일이 끝나면 누구에게 넘긴다, 자주 발생하는 문제는 어떤 것들이 있고 어떤 경로를 통해 해결한다, 프로젝트는 이런 정도가 되면 끝난 것이라고 선언한다, 이런 설명을 자세히 하게 했다. 이런 인터뷰는 소규모의 워크숍을 여러 번 하는 형태로 진행했다. 그렇게 한 사람이 이야기하는 동안 다른 사람들 반응은 “아니야, 난 그렇게 안 해”, “다르게 하는 경우도 많아” 등 매우 다양하게 나왔다.

이렇게 파악한 내용을 종합하여 우리는 가장 공통된 모습을 그렸고, 그 모습에 대한 합의를 거쳐 버전 1.0의 프로세스를 론치했다. 최초로 가시화된 개발 프로세스였다. 현재 개발 프로세스에 비하면 정교함의 수준이 20%에도 이르지 않는 수준이었지만 당시로서는 중구난방으로 일하던 방식(이런 수준을 ad-hoc 수준이라고 말한다)을 최초로 통일하고 모든 개발자가 공통된 프로세스로 움직이게 했다는 점에서 의의가 컸다. 그리고 그것대로 반복하게 했다. 그리고 반복의 결과를 지켜봤다. 이렇게 안정적으로 반복되는 상태가 되면 이에 대한 개선의 목소리는 상당히 효과적으로 발전한다. 그중 하나가 하드웨어와 소프트웨어 개발 간 업무 특성의 차이를 감안해야 하지 않느냐는 것이었다.