시스템 - 구축은 성공했는데, 왜 아무도 안 씁니까

현장의 질문들 - 2

1년 뒤에 가 보면

프로젝트는 성공적으로 끝났습니다. 일정을 지켰고, 예산도 맞췄고, 오픈 보고까지 마쳤습니다.

그런데 1년 뒤에 가 보면 이렇습니다. 화면은 마흔 개인데 실제로 쓰이는 건 대여섯 개입니다. 나머지는 비어 있거나, 형식적으로만 채워져 있습니다. 중요한 이야기는 여전히 회의에서 오갑니다.

담당자에게 물으면 대체로 이렇게 답합니다. "정착이 잘 안 됐습니다."

그리고 그 말 뒤에는 대체로 이런 해석이 붙습니다. 사람들이 안 따라줬다, 교육이 부족했다, 위에서 강하게 밀어붙이지 않았다.

저희는 조금 다르게 봅니다. 오늘은 그 이야기입니다.

원인은 사람이 아니라 접근 방식에 있습니다

정착이 안 되는 이유를 사람에게서 찾으면 답이 안 나옵니다. 교육을 늘리고 독려를 해도 같은 결과가 나오는 경우를 여러 번 봤습니다.

원인을 여섯 가지로 나눠 보겠습니다.

첫째, 예전 전산화와 같은 방식으로 접근했습니다

이게 가장 근본적인 원인이라고 봅니다.

우리가 지난 수십 년간 해온 전산화가 어떤 일이었는지 생각해 보겠습니다. 종이로 하던 것을 화면으로 옮기는 일이었습니다. 결재판이 결재 화면이 되고, 수기 장부가 입력 화면이 되고, 캐비닛의 서류철이 문서 목록이 됐습니다.

이 방식은 잘 통했습니다. 옮길 원본이 이미 있었기 때문입니다. 사람들은 이미 그 일을 하고 있었고, 하던 것을 어디에 하느냐만 바뀌었습니다.

그런데 지금 넣으려는 것은 성격이 다릅니다.

이 과제를 왜 하기로 했는지. 어떤 대안을 검토하다 접었는지. 무엇을 전제로 계획했는지. 이 일을 할 때 무엇을 확인해야 하는지.

이건 지금 하지 않는 일입니다. 종이에도 없고 엑셀에도 없습니다. 옮길 원본이 없습니다.

그래서 업무 구조화(PI)가 먼저입니다

화면을 만들기 전에 해야 할 일이 있습니다. 업무를 구조화하는 일입니다.

우리 회사가 반복적으로 수행하는 업무에 어떤 유형이 있는지 정리합니다. 유형별로 어떤 활동이 이루어지는지 나눕니다. 활동마다 무엇을 확인해야 하는지, 어떤 판단이 일어나는지를 뽑아냅니다.

이게 만만치 않은 작업입니다. 정직하게 말씀드려야 할 것 같습니다.

그 일을 하는 사람들이 직접 정리해야 합니다. 우리 회사에서 신규 과제를 검토할 때 실제로 무엇을 보는지는 그 일을 해본 사람만 압니다. 그리고 시간이 걸립니다. 유형이 몇 개만 돼도 짧게 끝나지 않습니다.

그런데 대부분 이 단계를 건너뜁니다. 눈에 안 보이고, 오래 걸리고, 중간 산출물을 성과로 보고하기 어렵기 때문입니다. 그래서 곧장 화면 설계로 갑니다. 요구사항 검토 회의를 하고, 화면 목록을 뽑고, 개발에 들어갑니다. 일정도 잡히고 진척도 보입니다.

그리고 1년 뒤에 아무도 안 씁니다.

그렇다고 혼자 하기도 어렵습니다

여기서 현실적인 문제가 하나 있습니다. 현업 담당자에게는 본업이 있습니다. 업무를 뜯어보고 정리하는 일을 스스로 굴리기는 어렵습니다.

그럼 외부에 맡기면 됩니까. 지금의 일반적인 방식으로는 안 됩니다. 요구사항 정의서를 받아 개발하고 검수받는 구조에서는 아무도 업무를 뜯어보지 않습니다. 계약 범위에 그게 없으니까요. 그래서 "지금 어떻게 하고 계십니까"를 묻고 받아 적는 데서 끝납니다.

이 지점에서 참고할 만한 방식이 하나 있습니다. 앞선 글에서 다룬 팔란티어의 인력 운영입니다.

그 회사에는 현장에 투입되어 고객사 실무자와 함께 일하는 엔지니어가 있습니다. 요구사항을 받아 적고 돌아가는 것이 아니라, 현업 옆에 앉아서 업무를 함께 뜯어보고 그 자리에서 설계까지 합니다. 며칠 방문하고 돌아가는 방식이 아닙니다.

제품 자체는 앞선 글에서 정리한 대로 저희와 다루는 층이 다릅니다. 다만 사람을 현장에 넣는 방식은 참고할 만하다고 봅니다.

둘째, 정보가 다른 통로(이중 관리)로 새어 나갑니다

두 번째 원인이 실무적으로는 더 치명적입니다.

시스템에 과제 현황이 들어가 있습니다. 그런데 주간회의는 예전 그대로 합니다. 각자 구두로 보고하고, 논의하고, 거기서 결정이 납니다.

그러면 시스템에 있는 것은 회의를 위해 미리 채워두는 자료가 되고, 진짜 정보는 회의실에서 오갑니다.

그리고 말로 오간 것은 남지 않습니다. 무엇이 결정됐는지, 왜 그렇게 정했는지, 누가 무엇을 우려했는지, 어떤 대안이 언급됐다 넘어갔는지. 회의록에는 "논의 후 A안으로 결정" 한 줄이 남고 나머지는 사라집니다. 그 자리에 없었던 사람은 영원히 모릅니다.

아마존이 왜 그런 지시를 내렸는가

여기서 널리 알려진 사례를 하나 짚고 가겠습니다.

2000년대 초 아마존에서 제프 베이조스가 사내에 내린 지시가 있었습니다. 모든 팀은 정해진 통로를 통해서만 데이터와 기능을 주고받아라. 옆 팀에 가서 직접 부탁하거나 파일을 가져다 쓰는 것을 금지한 셈입니다.

당시 직원들에게는 대단히 불편한 지시였을 겁니다. 옆자리에 물어보면 5분이면 될 일을 정해진 절차로 요청하고 기다려야 했으니까요.

왜 그랬을까요.

옆자리에 물어보는 방식이 편하기 때문입니다. 편하기 때문에, 그냥 두면 모두가 그 방식을 씁니다. 그리고 그렇게 돌아가는 조직에는 아무것도 남지 않습니다. 누가 무엇을 어떻게 주고받았는지가 사람들 머릿속에만 있습니다.

사람이 바뀌면 그 통로가 통째로 사라집니다.

그래서 불편한 쪽을 강제한 것입니다. 당장은 손해입니다. 다만 그 불편함이 몇 년 쌓이면 구조가 됩니다.

우리 이야기로 돌아오면 이렇습니다. 회의에서 말로 공유하는 것이 편하기 때문에, 그냥 두면 계속 그렇게 합니다. 그리고 시스템은 껍데기로 남습니다.

회의를 없애자는 것이 전혀 아닙니다. 대화는 빠르고, 대화에서만 나오는 것이 있습니다. 다만 결정된 것과 요청한 것은 그 자리에 남아야 합니다.

셋째, 고참들이 반발합니다

이게 실제로 프로젝트를 가장 자주 멈추게 하는 원인입니다. 그리고 대체로 "변화를 싫어해서"로 잘못 해석됩니다.

기업의 업무는 상당 부분 문서화되지 않은 관행으로 돌아갑니다. 이 업체는 이런 조건을 조심해야 하고, 이 시험은 이 기관에 맡겨야 하고, 이 단계에서는 이걸 먼저 확인해야 합니다. 어디에도 안 적혀 있고, 그 일을 오래 한 사람 안에 있습니다.

업무를 구조화한다는 것은 그것을 밖으로 꺼내는 일입니다. 그리고 그 순간 몇 가지가 그 사람에게 일어납니다.

지금까지 물어봐야 알던 것을, 물어볼 필요가 없어집니다. 체크리스트에 적혀 있으니까요. 그 사람이 조직 안에서 갖고 있던 위치가 흔들립니다.

그리고 그것은 20년에 걸쳐 쌓은 것입니다. 실패하고 데이면서 알게 된 것들입니다. 그것을 정리해서 내놓으라는 요구는, 본인 입장에서 대단히 불편합니다.

이건 이기심이 아닙니다. 지금의 평가 구조에서는 합리적인 반응입니다. 자기가 아는 것을 자기가 써야 성과가 되는데, 그것을 남겨서 다른 사람이 쓰게 한 것은 아무 데도 잡히지 않습니다.

여기에 하나가 더 있습니다. 그 관행을 말로 꺼내는 것 자체가 어렵습니다. 왜 그렇게 하느냐고 물으면 "그냥 그렇게 하는 거야"라는 답이 나옵니다. 숨기는 것이 아니라 정말 설명되지 않는 형태로 있는 것인데, 옆에서 보기에는 협조하지 않는 것으로 보입니다.

그래서 독려나 설득으로는 안 됩니다. 두 가지가 필요합니다.

그 사람의 것으로 만듭니다. 체크리스트를 만들 때 그 사람의 검토와 승인을 거치게 합니다. 뺏기는 것이 아니라 자기 방식이 회사 표준이 되는 것으로요.

평가에 반영합니다. 자기가 아는 것을 남겨서 다른 사람이 쓸 수 있게 한 것이 성과로 잡혀야 합니다. 그것이 없으면 내놓을 이유가 없습니다.

넷째, 두 길이 다 열려 있습니다

엑셀로도 되고 시스템으로도 되면, 사람들은 익숙한 쪽을 씁니다.

의지의 문제가 아닙니다. 새 도구는 처음에 반드시 느립니다. 마감이 급한 상황에서 어느 쪽을 택할지는 정해져 있습니다.

병행 기간이 필요한 것은 맞습니다. 다만 그 기간에 끝이 없으면 영원히 병행합니다.

다섯째, 넣기만 하고 꺼낼 일이 없습니다

입력을 요구받는데 돌아오는 것이 없으면 안 씁니다.

오픈 시점에 시스템은 대체로 비어 있습니다. 조회할 것이 없으니 열어볼 이유가 없고, 열어보지 않으니 입력도 안 합니다. 과거 자료가 먼저 들어가 있어야 합니다.

여섯째, 경영진이 안 봅니다

가장 단순하면서 가장 강력한 원인입니다.

소장이나 임원이 시스템을 열지 않으면 실무자도 안 씁니다. 어차피 보고는 따로 해야 하니까요. 반대로 경영진이 회의에서 시스템 화면을 열어놓고 시작하면, 그날부터 다들 씁니다.

그리고 알아두셔야 할 것이 하나 더 있습니다

원인은 아닌데, 모르고 시작하면 중간에 흔들리게 되는 것이 있습니다. 부담의 곡선입니다.

초반에는 반드시 늘어납니다. 안 하던 것을 하게 되니 당연합니다. 게다가 병행 기간에는 두 번 하는 셈이기도 합니다. 오픈하고 한동안 "예전이 나았다"는 말이 나오는 것은 정상입니다.

그런데 여기서 구분해야 할 것이 있습니다. 개인의 부담과 조직 전체의 부담은 다릅니다.

지금 조직이 이미 지고 있는 부담을 세어보면 이렇습니다. 같은 것을 세 번 설명하는 시간. 자료를 어디 뒀는지 찾아 헤매는 시간. 담당자가 바뀌고 나서 후임자가 업무를 파악하는 기간. 이미 검토했던 것을 모른 채 다시 검토하는 시간. 회의 자료를 만드는 시간.

이것들은 어디에도 잡히지 않을 뿐, 실제로 지불되고 있습니다.

정착되면 이쪽이 줄어듭니다. 그리고 그 감소가 개인의 입력 증가보다 큽니다. 다만 입력 부담의 증가는 즉시 체감되고, 감소는 천천히 나타납니다. 그래서 이 일이 어렵습니다.

만드는 쪽의 책임도 있습니다

여기까지 도입하는 쪽 이야기를 했는데, 만드는 쪽 이야기도 해야 공평할 것 같습니다.

시스템 구축 계약은 대체로 오픈까지입니다. 안정화가 끝나면 프로젝트 조직이 해산합니다. 정착은 그때부터 시작되는데, 그 시점에는 책임질 주체가 없습니다.

업무 구조화도 마찬가지입니다. 고객사에 가서 "귀사의 업무 유형부터 정리해 봅시다"라고 말하는 것보다, 준비해 간 기능 목록을 펼치는 쪽이 훨씬 쉽습니다.

저희도 이 구조 안에 있습니다. 25년 동안 시스템을 만들어 온 회사로서, 이 문제에서 자유롭다고 말하기 어렵습니다.

정리하면

정착이 안 되는 것은 사람들이 안 따라줘서가 아닙니다.

하나, 예전 전산화와 같은 방식으로 접근했기 때문입니다. 옮길 원본이 없는 것을 화면부터 만들면 빈 칸이 됩니다. 업무 구조화가 먼저이고, 그 일에는 현장에 붙어서 함께 뜯어보는 사람이 필요합니다.

둘, 정보가 여전히 다른 통로로 흐르기 때문입니다. 말로 오간 것은 남지 않습니다.

셋, 오래 일한 사람들의 것을 꺼내는 일이기 때문입니다. 반발은 이기심이 아니라 지금 평가 구조에서의 합리적 반응입니다.

넷, 두 길이 다 열려 있고, 다섯, 꺼낼 것이 없고, 여섯, 경영진이 안 봅니다.

그리고 초반에는 반드시 부담이 늘어납니다. 그것을 모르고 시작하면 중간에 되돌리게 됩니다.

그럼 어떻게 해야 합니까. 다음 글에서 그 이야기를 하겠습니다. 어디서부터 손을 대야 하는지, 병행 기간을 어떻게 다뤄야 하는지, 그리고 자주 바뀌는 영역을 어떻게 설계해야 하는지에 대해서요.