01익숙한 장면 하나
“김 과장 다음 달에 나간대.”
“…그럼 그 발주 건은 누가 하지?”
— 어느 회사에서나 한 번쯤 오간 대화이 질문이 나오는 순간, 회사는 이미 답을 알고 있습니다. 그 일은 그 사람에게 묶여 있었다는 것을요. 인수인계 문서를 급히 만들고, 옆자리 직원이 한 달쯤 따라다니며 배우고, 그러고도 몇 달간은 “예전엔 어떻게 했더라” 하는 질문이 반복됩니다.
이것은 그 사람이 문서를 게을리해서 생긴 일이 아닙니다. 애초에 적기 어려운 종류의 앎이었기 때문입니다.
02우리는 말할 수 있는 것보다 더 많이 안다
철학자 마이클 폴라니는 이렇게 말했습니다 — “우리는 말할 수 있는 것보다 더 많이 안다.” 자전거를 탈 줄 아는 사람도 그 방법을 글로 정확히 옮기지는 못합니다. 몸이 아는 것과 말로 옮길 수 있는 것 사이에는 늘 간격이 있습니다.
회사의 일도 마찬가지입니다. 20년 차 담당자는 어느 거래처가 언제 예민한지, 어떤 서류는 먼저 돌려야 하는지, 어느 공정에서 문제가 잘 터지는지를 압니다. 그러나 그것을 정리해 달라고 하면 대개 이런 답이 돌아옵니다 — “그냥… 하다 보면 알게 돼요.”
이렇게 사람에게 붙어 있는 앎을 암묵지(暗默知), 밖으로 꺼내 남이 읽을 수 있게 된 앎을 명시지(明示知)라 부릅니다. 지식경영을 정립한 노나카 이쿠지로는 조직의 지식이 이 둘 사이를 돌며 자라난다고 보았는데, 그중 가장 어려운 고리가 암묵지를 명시지로 꺼내는 단계였습니다.
본인은 자기가 무엇을 아는지 모르기 때문입니다.
이것은 어제오늘의 관찰이 아닙니다. 1990년대에 미 국방부의 조직 개편에 쓰인 프로세스 분석 실무서는 이 사정을 한 문장으로 못 박아 두었습니다.
“한 조직이 어떻게 돌아가는지는 대개 회사 매뉴얼이 아니라, 그 조직을 운영하는 전문가들의 머릿속에만 기록되어 있다. 그러므로 문서화는 필수적이다.”
— The Practical Guide to Business Process Reengineering Using IDEF0
03600만 달러짜리 전화 한 통
같은 책에 이런 사례가 나옵니다. 한 대형 제조기업이 새로 생긴 정부 규제에 맞추려고 부품 추적 시스템을 만들었습니다. 1년 넘게, 600만 달러를 들여 개발을 마치고 가동을 앞둔 시점이었습니다.
그런데 가동해 보니 시스템이 현실과 맞지 않았습니다. 원인을 파고들어 보니 이런 것이었습니다 — 생산 일정 담당자와 현장 사이에 매일 한 통의 전화가 오갔고, 그 통화로 중요한 정보가 전달되고 있었습니다.
그 전화는 회사 매뉴얼 어디에도 적혀 있지 않았습니다. 현행 업무를 그려 보는 절차 없이 새 시스템을 설계했으니 개발자들이 알 도리가 없었고, 결국 그 정보 경로는 통째로 빠졌습니다. 시스템은 폐기됐습니다.
아무도 적어 두지 않은 전화 한 통 때문이었습니다.
이런 전화는 어느 회사에나 있습니다. 매뉴얼에 없고, 조직도에 없고, 시스템에도 없지만 그것이 없으면 일이 돌아가지 않는 연결들 말입니다. 대개는 “그건 그냥 김 과장이 챙기던 건데요”라는 말로 존재가 확인됩니다 — 대체로 일이 잘못된 뒤에.
04매뉴얼을 써 두어도 왜 남지 않는가
많은 회사가 이 문제를 매뉴얼로 풀려고 합니다. 업무 절차서를 만들고 위키에 정리합니다. 그런데도 몇 년 뒤 같은 질문이 다시 나옵니다. 이유는 세 가지쯤 됩니다.
첫째, 글은 위성사진과 같습니다. 정보는 다 들어 있는데 길이 보이지 않습니다. 수백 페이지를 다 읽어야 겨우 전체 그림이 잡히고, 부서 사이의 연결은 문장 속에 숨어 있습니다. 지도는 땅 위의 모든 것을 담지 않습니다 — 길을 찾는 데 필요한 것만 남깁니다. 매뉴얼에는 그 덜어내기가 없습니다.
이것은 취향의 문제가 아닙니다. 앞의 실무서는 “한 줄로 늘어놓는 글로는 조직의 복잡함을 담을 수 없고, 2차원의 그림이 필요하다”고 단언합니다. 나아가 소프트웨어 업계의 통계를 근거로 이렇게 전합니다 — 글로만 요구사항과 설계를 적은 시스템은, 도해 언어를 함께 쓴 시스템보다 오류와 누락이 두 배 이상 많았다. 어떤 도해 언어를 썼는지는 별로 중요하지 않았습니다. 그림을 그렸는가 아닌가가 갈랐습니다.
둘째, 매뉴얼은 각자의 일을 적을 뿐 ‘사이’를 적지 않습니다. 영업팀 매뉴얼에는 영업팀이 하는 일이, 생산팀 매뉴얼에는 생산팀이 하는 일이 적혀 있습니다. 그런데 정작 문제가 터지는 곳은 그 둘 사이입니다. 누가 무엇을 언제 넘겨주기로 했는지는 어느 매뉴얼에도 없습니다.
셋째, 쓰는 순간부터 낡습니다. 형식이 자유로우면 고치기도 어렵습니다. 어디를 고쳐야 앞뒤가 맞는지 알 수 없으니, 결국 아무도 고치지 않고 서랍 속에 남습니다.
한 회사 안에도 여러 문화가 있습니다. 생산의 언어와 전산의 언어가 다르고, 영업의 언어가 또 다릅니다. 각자의 매뉴얼은 각자의 말로 쓰여 있어서, 정작 서로를 지원해야 할 때 말이 통하지 않습니다. 회사 전체를 하나의 문법으로 그려야 하는 이유가 여기 있습니다.
05진짜 자산은 사람이 아니라 ‘사이’에 있다
조직이 남겨야 할 것은 개인의 솜씨가 아닙니다. 솜씨는 원래 그 사람의 것이고, 새 사람은 새 솜씨를 가져옵니다. 남겨야 할 것은 맞물림입니다 — 누구의 산출이 누구의 입력이 되는가.
오케스트라를 생각해 보면 분명해집니다. 훌륭한 연주자를 모아 놓는다고 교향곡이 되지 않습니다. 언제 누가 어느 마디를 맡는지에 대한 약속, 곧 악보가 있어야 합니다. 악보가 있으면 연주자가 바뀌어도 곡은 그대로 이어집니다.
그래서 유명소프트는 업무를 적을 때 늘 네 가지를 함께 묻습니다. 무엇이 들어오는가(입력), 무엇의 규율을 받는가(통제), 무엇이 나오는가(산출), 누가·무엇으로 하는가(수단). 이 네 가지가 활동마다 채워지면, 한 사람의 산출이 다음 사람의 입력으로 이어지는 연계 구조가 저절로 드러납니다. 개인의 일이 아니라 사이의 약속이 기록되는 것입니다.
06꺼내는 방법 — 묻지 않으면 나오지 않는다
“정리해서 주세요”라고 하면 대개 아무것도 나오지 않습니다. 본인은 자기가 무엇을 아는지 모르기 때문입니다. 암묵지는 질문을 받아야 밖으로 나옵니다.
잘 안 되는 방식“매뉴얼로 정리해 주세요”
무엇을 어느 수준까지 적어야 할지 알 수 없어 막막합니다. 결국 아는 것의 일부만, 그것도 자기에게 익숙한 순서로 적게 됩니다.
되는 방식“그 일 시작할 때 뭐가 손에 들어옵니까?”
구체적인 질문에는 답이 나옵니다. 빈칸이 정해져 있으니 무엇이 빠졌는지도 드러납니다 — “통제가 없네요, 그럼 기준 없이 판단하시는 건가요?”
이 대화가 바로 저희가 말하는 인터뷰입니다. 예전에는 컨설턴트가 며칠씩 현장에 머물며 물었고, 지금은 AI가 그 질문을 대신합니다. 그래서 업무 절차서가 없는 회사도 시작할 수 있습니다 — 설명만 하시면 됩니다.
07명시지가 되면 달라지는 것
-
01
사람이 떠나도 일하는 방식은 남습니다
인수인계가 ‘한 달간 따라다니기’에서 ‘그림 몇 장 읽기’로 바뀝니다. 새로 온 사람이 자기 자리가 전체에서 어디쯤인지부터 알고 시작합니다.
-
02
엉킨 곳이 그림 위에 드러납니다
산출은 있는데 받는 곳이 없는 활동, 같은 문서를 세 부서가 따로 만드는 자리, 기준 없이 사람 판단에만 기대는 지점 — 말로는 뭉개지던 것들이 빈칸으로 보입니다. 경영진이 보고받아 온 “다 잘 돌아가고 있습니다”라는 그림 대신, 실제로 어떻게 돌아가는지를 보게 되는 것이기도 합니다.
-
03
그 위에 AI를 근거를 갖고 올릴 수 있습니다
어느 업무에 무엇을 적용할지 짐작으로 고르지 않습니다. 구조를 보고 정합니다. 이 이야기는 왜 프로세스가 먼저인가에서 따로 다룹니다.
유명소프트는 자사 발주관리시스템(OMS)을 이 방법으로 직접 설계·개발했습니다. 남에게 악보를 권하기 전에, 저희가 먼저 그 악보로 연주해 봤습니다.
08기록되지 않은 것은 결국 사라진다
회사가 오래 쌓아 온 앎은 대차대조표에 오르지 않습니다. 그래서 잃어버려도 손실로 잡히지 않고, 잃어버렸다는 사실조차 한참 뒤에야 알게 됩니다. 대개는 누군가 떠난 다음입니다.
말은 문자로, 음악은 악보로 남았기에 세대를 넘었습니다. 회사가 일하는 방식도 마찬가지입니다. 적어 두면 자산이 되고, 머릿속에만 두면 언젠가 사라집니다.
우리 회사의 일하는 방식은 지금 어디에 적혀 있습니까.
문서가 없어도 괜찮습니다 — 설명만 하시면 AI가 받아 적습니다.
참고 문헌
-
Clarence G. Feldmann, The Practical Guide to Business Process Reengineering Using IDEF0 1998년. 저자는 SofTech에서 Douglas T. Ross와 함께 일하며 IDEF0 정립에 참여했고, 이후 미 국방부의 조직 개편에 이 방법을 적용한 당사자입니다. 이 글에서 — 본문에 인용한 문장(“조직이 어떻게 돌아가는지는 대개 회사 매뉴얼이 아니라 그것을 운영하는 전문가들의 머릿속에만 기록되어 있다”), 600만 달러 부품 추적 시스템 사례, 글로만 설계한 시스템의 오류·누락이 두 배라는 관찰, 한 회사 안의 여러 문화와 전문용어 격차.
-
Michael Polanyi, The Tacit Dimension 1966년. 이 글에서 — “우리는 말할 수 있는 것보다 더 많이 안다”는 명제와 암묵지 개념.
-
Ikujiro Nonaka · Hirotaka Takeuchi, The Knowledge-Creating Company Oxford University Press, 1995년. 이 글에서 — 조직의 지식이 암묵지와 명시지 사이를 돌며 자란다는 관점, 그중 암묵지를 꺼내는 단계가 가장 어렵다는 진단.