지난 주에 2년 전쯤 강의하던 대학원의 제자를 만났다. 그는 컨설팅하러 갔던 기업의 직원이 돼 있었다. 잠시 이야기를 나누면서 필자는 흥미로운 이야기를 들었다. 그는 가장 변화가 안되는 조직 세 개로 병원과 학교, 교회를 꼽았다. 일리있다는 생각이 들었다. 나중에 똑같은 질문을 다른 친구에게 했더니 그는 잠시 생각하더니 군대와 정부라고 답했다(이 이야기는 여기에 조직에 속한 구성원들을 깎아 내리려고 하는 것이 아니다). 어쨌든 당시 그 제자와 이야기를 나누면서 ‘그럴수도 있겠구나‘ 싶었는데, 그는 이어 자기가 속한 조직은 이 모든 것을 다 갖추고 있어서 변화가 늦다는 말을 덧붙였다. 그렇다면 독자가 속한 조직은 변화에 빠르게 대처하는가? 빠르게 대처한다는 것은 항상 좋은 것일까?
조직이 빨리 변화할 때 나타나는 문제 가운데 하나는 변화를 제대로 익히기도 전에 뭔가 일이 시작되고 끝난다는 것이다. 예를 들어 필자가 다루는 영역에서는 닷넷이라는 틀을 이용한 프로그래밍이 새로운 기법으로 떠오르고 있다. 닷넷은 그 고유의 특성상 프로그래밍시 좋지 않다고 알려진 사항들이 있는데, 일부 개발자 그룹은 이를 잘 알고 제대로 된 패턴으로 코드를 짜는 반면, 일부는 해서는 안될 패턴을 사용하고 있었다. 그런데 후자의 사례를 자세히 살펴보니 단지 앞서 프로그램을 개발한 몇 사람이 그렇게 했을 뿐이고 후임자는 이를 충분히 공부할 시간이 없었기 때문에 가장 일반적인 코드 짜기의 비법, 즉 ‘copy & paste’를 이용해 개발한 것이었다. 이렇다 보니 처음에 복사하는 코드가 어떤 것이냐에 따라 이후 코드의 품질이 결정됐다.
다 지은 집을 다시 때려 부순다?
필자 개인의 경험으로 어림해보면 1995년 당시 다국적 기업에 입사했을 때 우리나라 기업의 생산성은 미국 기업에 비해 3배 정도 떨어졌던 것 같다. 지금 동일한 비교를 한다면 1.5배 정도? 우리나라 기업이 사흘 밤샘해서 할 일을 미국 기업들은 단 하루 만에 마무리한다. 물론 반대의 경우도 있다. ‘빨리빨리’ 문화에 익숙한 우리는 미국 기업이 사흘에 할 일을 하루 만에 해 치우기도 한다. 그러나 더 심각한 문제가 뒤따른다. 시간에 쫓기다 보니 날림공사였고 마치 입주해 놓고 나서 사람들을 괴롭히는 것처럼 완료한 프로젝트를 다시 뜯어고치는 일이 비일비재했다. 차라리 사흘동안 해도 좋으니 제대로 만들어 완공 이후 때려 부수고 다시 만드는 일을 줄이는 것이 저렴할 정도다.
미국에 중요한 계약 서류를 보낼 때 우리나라 사람은 숫자 틀리는 일이 잦다고 한다. 정정해 달라고 요청하면 이번엔 다른 부분에서 또 틀리고, 겨우 계약이 되고 나면 다음 번에 다른 일로 계약서를 보낼 때 또 숫자가 틀린 일도 있다고 한다. 미국 사람들은 실수가 반복되면 실패이자 고의라고 받아들인다. 이런 문화적 특성을 알면서도 왜 같은 실수를 반복하는 것일까.
필자는 그 이유를 우리나라 기업들의 점검과정이 제대로 표준화되지 않았기 때문이라고 생각한다. 비행기를 타면 이륙 전 승무원들의 움직임이 부산하다. 관찰하기 좋아하는 필자는 여기서 한 가지 재밌는 사실을 발견했다. 그들의 업무 가운데 하나가 문이 잘 닫혔는지 확인하는 것인데 이 때 승무원들이 서로 위치를 바꿔 다시 한 번 점검하는 것이었다. ‘cross check’ 또는 ‘double check’라고 하는 이 시스템을 보면서 필자는 군대가 아닌 곳에서도 이런 일을 하는구나하고 감동을 받았다. 앞서 언급한 경우만 해도 6시그마 운운할 것도 없이 계약서를 보내기 전에 다른 직원이 double check하는 시스템만 갖고 있었다면 계약서의 중요한 숫자가 틀리는 일은 크게 줄지 않겠는가.
매뉴얼은 시간과 돈 낭비?
2주 전에는 필자가 속한 스터디 그룹의 정기 스터디가 있었다. 예정된 스터디를 하고 나서 시간이 약간 남았는데 이 때 구성원들의 호기심을 잡아 끄는 주제가 있었다. 실제 컨설팅 사례와 개발자들의 개발 패턴에 관한 이야기였는데, 지인을 통해 혹은 정식 컨설팅 요청을 통해 기업에 나가 ‘왜 이걸 이렇게 개발했지?’라는 질문을 해 보면 실제 돌아오는 대답은 너무나 단순했다는 사실이다.
"다른 사람이 그렇게 짰던 걸요……"
그랬다! 문제가 된 코드는 다른 사람의 것을 복사해서 개발했던 것이고 그전까지 해오던 것 그대로이니 큰 의심없이 몇 가지만 추가하면 된다는 생각으로 만들었던 것이다. 그러자 또 다른 사람이 자신의 경험을 이야기했다. 포스코의 경우 프로젝트가 시작되면 태스크포스팀이 구성되고 이들이 회사 자체의 프로젝트와 프로그램 코드 작성 매뉴얼을 책으로 제작해 배포한다고 한다. 전체 개발자가 이것을 따라야만 하는 것은 물론이다. 필자도 이와 비슷한 제안을 기업에 한 적이 있다. 그러나 의사 결정권자 혹은 개발자들의 반응은 대부분 부정적이다.
"포스코 같은 대기업이면 우리도 할 수 있지"
"지금 인력으로 언제 매뉴얼 만들고, 언제 프로젝트 시작해?"
"그런 거 만들어 봤자 지키지도 않아. 괜한 시간 낭비, 돈 낭비야."
"자유로움이 좋은 것이야. 편히 개발하게 놔둬. 그게 창의성이고 생산성이라구."
그러나 크게 생각할 필요가 없다. 예를 들어 disk full 오류가 발생했을 때는 어떻게 해야 할까. 독자들은 그 해결방안을 머리 속이 아닌 종이나 파일로 정리해 둔 것을 가지고 있는가. 만약 없다면 담당자가 병원에 입원했을 때는 어떻게 할 것인가. 다시 또 비행기 이야기로 돌아가보자. 여객기 조종사들은 조종 매뉴얼이 있고 이를 보면서 점검 사항을 하나하나 확인하고 이착륙을 한다. 초보 조종사들도 아니고 벌써 수천, 수만 시간 비행을 한 베테랑 조정사들도 한 사람이 매뉴얼을 펴고 읽으면 다른 사람이 따라 말하면서 실행에 옮긴다. 이유는 당연히 ‘안전’ 때문이다. 아주 작은 실수도 엄청난 사고로 연결될 수 있고 그 피해 규모는 상상을 초월한다.
필자도 이와 비슷한 경험을 한 적이 있다. 호주에서 온 컨설턴트와 같이 컨설팅을 하면서 ‘몸값이 저렇게 비싼데 대체 얼마나 잘 하나 보자’는 생각으로 함께 다니며 지켜본 적이 있는데 그는 어이없게도 노트 하나를 펴 놓고 하나하나 보면서 처리했다. ‘뭐 이런 사람이 다있어?’하는 반응이 우선이었지만 이유를 듣고 나니 절로 고개가 끄덕여졌다. 실수해서 소송을 당하거나 실수로 무언가를 놓쳐서 ‘누구에게 컨설팅받아도 별거 없더라’는 이야기를 듣는 것보다는 초보처럼 보여도 자신만의 매뉴얼을 펴 놓고 하나하나 짚어가며 하는 것이 더 효율적이라는 설명이었다.
프로가 프로다울 수 있는 이유
최근에 진료를 받은 치과에서도 비슷한 광경을 볼 수 있었다. 요즘 병원들은 경쟁이 심해져서 친절은 기본이고 다양한 고객 서비스를 하고 있다. 그러나 이를 고려해도 그 병원 직원들은 매우 분주하게 움직였다. 자초지정을 들어보니 그들은 업무 프로세스 매뉴얼을 만들고 이를 시스템화해 신입 직원들에게 교육을 하고 있었다. 예를 들어 치아 X레이 사진을 찍을 때는 「환자를 대기실에 안내한다｜X레이실에서 모든 준비를 마친다｜환자를 데려온다｜사진을 찍고 확인한다｜환자를 대기실로 다시 안내한다｜사진을 컴퓨터로 전송한다｜진료실에서 사진 준비를 마치고 환자를 데려온다……」처럼 절차를 정해두는 것이다. 교육을 받은 신입 직원은 팀장을 환자로 가정하고 실습을 하며 이 과정을 무사히 통과해야 실제 고객을 대할 수 있다. 자연스럽게 ‘프로는 아름다워’라는 구절이 떠올랐다.
전산(필자는 ‘IT’라고 하면 괜찮고 ‘전산’이라고 하면 하찮게 여기는 인식을 이해할 수 없다) 업계도 마찬가지다. 로그가 가득차거나 CPU 사용률이 90%를 넘어간다면, 혹은 특정 프로시저의 반응시간이 30초를 넘어가는 등의 경우를 대비해 미리 매뉴얼을 만들어 둔다면 담당자가 부재 중이거나 긴급 상황이 발생했을 때 피해를 미연에 방지하거나 크게 줄일 수 있을 것이다.
IT 업계는 매뉴얼 부재 중
표준화와 템플릿 만들기는 관리자가 해야 할 중요한 일 중 하나다. 직원들이 가야할 바, 해야할 바를 찾아서 제시해 주는 일이며, 반복된 업무에서 다소 자유로울 수 있는 방법이다. 매번 신입사원이 들어올 때마다 ‘백업은 이렇게 하는 거야’라고 그때그때 다른 방법으로 가르치는 것보다는 표준화된 백업 매뉴얼을 만들어 놓고 이를 따르게한다면 담당자가 입원을 하거나 휴가를 갔을 때 ‘어느 테이프가 진짜야?’라고 묻는 해프닝을 피할 수 있을 것이다. SAS 본사를 방문했을 때의 기억이 난다. 그들은 다음과 같은 백업 프로시저 매뉴얼을 가지고 있었다(물론 복원에 대해서도 별도의 매뉴얼이 있었다).
1. 1주차 월요일 07:00에는 테이프 A에 전체 백업을 한다. 이를 X에 보관한다.
2. 1주차 화, 수, 목, 금요일 07:00에는 테이프 B에 로그 백업을 한다. 이를 X에 보관한다.
3. 2주차에는 테이프 C와 D에 백업을 한다. <1>, <2>에서 백업한 것을 Y로 옮겨 보관한다
4. 이를 반복해 테이프 H와 G까지 사용하고 Y로 옮겨 보관한다. 이를 순환한다.
5. 매 15일에는 테이프의 10%를 무작위 추출하여 테스트 서버에서 복원하고 원본과 비교한다.
6. <5>에서 원본과 틀린 경우는 전수 조사를 한다.
7. <6>에서 불량이 발생한 테이프는 폐기하고 새 테이프로 대체한다.
다시 프로그램에 대한 이야기로 돌아가보자. 프로그램이 자유로운 창작과 예술의 영역에만 속한 일이라면 혼자 독립해 개발하는 것이 옳다. 그러나 팀웍으로 이루어지는 코딩에서는 철저하게 다른 사람들이 읽어 낼 수 있는 코드를 짜야 한다(헝가리식 표기법 같은 기법들은 이런 필요에 따라 나온 것이다!). 관계형 데이터베이스의 저장 프로시저를 예로 들어보면, 프로시저 생성 전에 SET ANSI_NULLS ON/SET QUOTED_IDENTIFIER ON 등 두 옵션을 설정해야만 불필요한 프로시저의 컴파일을 방지할 수 있으므로 모든 개발자들은 이를 설정하는 것이 좋다. 프로시저 내부에서는 가능하다면 먼저 SET NOCOUNT ON/SET LOCK_ TIMEOUT 60000/SET TRANSACTION ISOLATION LEVEL READ UN COMMITTED 등과 같이 설정해야 부담을 주지 않고 빠른 성능을 제공하는 프로시저를 개발할 수 있다.
이런 가이드 라인을 제공하는 것이 바로 매뉴얼이다. 대기업의 프로젝트 표준화 태스크포스팀처럼 책 한 권을 만들지는 못해도 상식적인 혹은 확인할 수 있는 범위 내에서만이라도 따라야 할 규칙과 표준을 만들고 이를 지키도록 하는 것이 관리자의 역할이다. 물론 자신이 기술적으로 이런 분야와 동떨어져 있다면 기술적으로 더 능숙한 직원에게 분담시킬 수도 있다.
표준의 천국, 군대?
이런 템플릿이나 표준을 매우 잘 만들어 둔 ‘엄청난’ 조직이 바로 군대다. 경계 수칙, 정비 수칙, 사격장 안전 수칙에 하다못해 졸병 수칙까지 엄청난 양의 수칙이 마련돼 있다. 그런데 어찌된 일인지 대부분의 남자들은 이런 이야기를 하면 웃기부터 한다. 이유는 잘 지켜지지 않기 때문이다. ‘FM’이라는 용어에서 느껴지는 냉소적인 어감은 뒤집어 말하면 군대에서 수칙이란 제대로 지켜지지 않는 것이 상식이라는 공감대인 것이다.
필자는 군에서 나타나는 이런 부작용은 세 가지 이유 때문이라고 생각한다. 첫째 템플릿을 만들때 책임을 회피하기 위한 용도로 만들었거나, 둘째 현실을 반영하지 못하고 오래도록 굳어진 경우, 마지막으로 대규모 군 인원 모두에게 적용될 만큼 범용적인 수칙에 머물렀기 때문이다. 모든 수칙은 현실을 반영해야 한다. 앞서 언급한 백업 매뉴얼의 경우 한 번 작성된 이후에도 새로운 하드웨어를 도입해 테이프 하나가 MB에서 GB로 늘었다면 매뉴얼을 갱신해야 한다. 중요치 않은 것이라면 이를 갱신하는데 시간들이지 말고 과감하게 폐기하는 것이 좋다. 마지막으로 범용적 수칙에 머물렀다는 의미는 예외사항을 지나치게 많이 만든 경우다. 차라리 그보다는 좁은 범위의 특정 목적에 맞는 수칙을 새로 만드는 것이 현실적이다. 대기업이 아니라 중소 규모 기업에서 표준화/템플릿 작업이 필요한 것도 이 때문이다.
무엇보다 표준화와 템플릿의 목적은 생산성을 높이기 위한 것이고 실수로 인한 불필요한 낭비와 손실을 줄이기 위한 것이다. 이것이 ‘수단’이 아닌 ‘목적’이 돼 직원들이 그것만 생각하면 숨이 답답해진다면 이미 그 가치를 상실한 것이다.
창작의 세계에서 공학의 세계로
능력 있는 관리자는 반복되는 실수를 점차 줄일 수 있도록 이끄는 사람이다. 같은 일을 100명이 다 새로 배우는 것보다는 10명이 먼저 배워서 나머지 90명에게 전수하도록 해 더 좋은 생산성을 낼 수 있도록 유도해야 한다. 날림공사로 일관한 프로젝트를 단기간에 끝내고 이와 동시에 다시 밤샘을 하며 보수작업을 하는 구습이 더 이상 되풀이돼서는 안된다. 이런 행태는 전산업을 오래 있기 힘든 업종으로 전락시키고 유능한 인재가 끝까지 남아있지 못하게 하는 요인이 된다. 더구나 우리나라의 코딩과 전산 기술이 창작의 세계가 아니라 수학적 검증을 거친 논리의 세계, 나아가 가능성을 논리적으로 입증하고 건축하는 공학의 세계로 진보하기 위해서는 필수적이다. [maso]