지식은 전달되는 것이 아니라 쌓이는 것입니다 — R&D 지식관리 이야기

지식관리 시리즈 1/3

들어가며

연구소에서 반복되는 장면이 하나 있습니다.

과제를 새로 맡은 연구원이 전임자의 폴더를 엽니다. 파일은 많습니다. 보고서, 시험 결과, 회의 자료, 참고 문헌. 없는 게 아닙니다.

그런데 알 수가 없습니다. 왜 이 방향으로 갔는지, 무엇을 시도했다가 접었는지, 이 결정에 어떤 근거가 있었는지.

그래서 처음부터 다시 시작합니다. 문헌을 다시 찾고, 대안을 다시 검토하고, 시험을 다시 설계합니다. 그리고 몇 달 뒤, 회사가 3년 전에 이미 도달했던 결론에 다시 도달합니다.

이 장면을 보통 인수인계가 부실했다고 해석합니다. 전임자가 정리를 안 하고 나갔다거나, 인계 기간이 짧았다거나.

저희는 다르게 봅니다. 인수인계의 문제가 아니라, 애초에 아무것도 축적되지 않았던 것입니다.

이 차이가 왜 중요한지, 오늘부터 세 편에 걸쳐 이야기해 보겠습니다.

1. 넘겨야 할 것이 왜 그렇게 많은가

먼저 사람이 나갈 때 실제로 무엇이 함께 나가는지 보겠습니다.

• 그 과제에서 시도했던 것과 접었던 것
• 어떤 원료가, 어떤 조건이, 어떤 조합이 안 되는지에 대한 감각
• 고객사나 협력기관과 주고받은 맥락
• 실패한 시험의 이유에 대한 추정
• 그리고 "왜 그렇게 결정했는가"에 대한 기억

관리자 입장에서는 사람 한 명이 아니라 몇 년치 개발 경험이 통째로 나가는 것입니다.

R&D에서 이 문제가 유독 큰 이유가 있습니다.

앞선 글에서 저희는 R&D Project의 산출물이 무형이라고 말씀드렸습니다. 생산 현장이라면 설비와 공정이 남습니다. 영업이라면 계약과 거래 이력이 남습니다. 그런데 R&D의 결과물은 지식, 데이터, 판단입니다. 형태가 없는 것은 사람 안에 머무르기 쉽습니다.

그리고 이것은 퇴사만의 문제가 아닙니다

담당자 교체를 이직 문제로만 보는 시각이 있습니다.

실제로는 훨씬 자주 일어납니다. 조직이 개편되고, 다른 과제로 옮겨가고, 승진해서 관리 업무로 빠집니다. 연구원이 한 과제를 처음부터 끝까지 붙들고 가는 경우가 오히려 드뭅니다.

특히 개발 주기가 긴 영역에서는 담당자 교체가 예외가 아니라 거의 확정된 사건입니다. 3년, 5년 걸리는 과제에서 담당자가 그대로 있을 확률이 얼마나 될까요.

여기서 질문을 바꿔야 합니다

지금까지의 접근은 "어떻게 하면 잘 넘길 것인가"였습니다. 인계 문서를 만들고, 인수인계 기간을 확보하고, 체크리스트를 돌립니다.

그런데 이 접근에는 근본적인 한계가 있습니다. 넘길 시점이 되어서야 정리를 시작하기 때문입니다.

몇 년간 쌓인 판단과 맥락을 떠나기 직전 2주 만에 정리할 수 있을까요. 게다가 떠나는 사람은 이미 다음 자리를 보고 있고, 정리를 잘해도 돌아오는 것이 없습니다. 구조적으로 잘 될 수가 없는 일입니다.

그래서 질문을 바꿔야 합니다.

이것이 이 글의 출발점입니다.

2. 지식관리가 대부분 실패한 이유

많은 조직이 이 문제를 이미 인식하고 있습니다. 그래서 시도해 봤습니다. 그리고 대부분 잘 되지 않았습니다.

실패의 양상은 대체로 비슷합니다.

• 노하우를 정리해서 올려달라고 요청합니다. 잘 올라오지 않습니다. 본인도 무엇이 노하우인지 모르고, 정리할 시간도 없고, 정리해서 올려도 돌아오는 것이 없습니다.
• 자료실을 만들어 둡니다. 폴더 체계를 잘 잡고 게시판을 열어두면 알아서 쌓일 것이라 기대합니다. 몇 달 뒤 그곳은 아무도 들어가지 않는 공간이 됩니다.
• 공유 문화를 만들자고 합니다. 캠페인을 하고 우수 사례를 시상합니다. 몇 달은 갑니다. 그리고 원래대로 돌아갑니다.

세 가지 시도의 공통점이 있습니다.

전부 "일이 끝난 뒤에 따로 정리하는" 방식입니다.

일은 일대로 하고, 그것과 별개로 지식을 추출해서 어딘가에 넣는 작업을 추가로 요구합니다. 그러면 두 가지 문제가 생깁니다.

첫째, 시간이 안 납니다. 앞선 글에서 저희는 R&D에 관리를 전담하는 인력이 없다는 이야기를 했습니다. 연구원이 연구도 하고 관리도 한다고요. 지식관리도 정확히 같은 제약을 받습니다. 연구 시간을 쪼개서 해야 하는 일이라면, 아무리 취지가 옳아도 오래가지 못합니다.

둘째, 나중에 쓰면 이미 흐릿합니다. 판단은 그 순간에 이유가 명확합니다. 몇 달 뒤 정리하려고 앉으면 왜 그랬는지 본인도 기억이 안 납니다. 남는 것은 결론뿐이고, 결론만 남은 기록은 다음 사람에게 쓸모가 없습니다.

3. 지식은 남기는 것이 아니라 남는 것입니다

여기서 접근을 근본적으로 바꿔야 합니다.

지금까지의 모델은 이렇습니다. 사람이 일하면서 지식을 갖게 되고, 그것을 어떻게든 꺼내서 조직에 옮긴다. 개인이 지식의 그릇이고, 조직은 그것을 받는 쪽입니다. 그래서 인수인계라는 이벤트가 필요하고, 지식 추출이라는 별도 작업이 필요합니다.

저희가 제안하는 모델은 다릅니다.

지식이 개인에게 갔다가 조직으로 오는 것이 아닙니다. 처음부터 조직에 쌓입니다. 그러면 넘길 것이 없습니다. 이미 거기 있으니까요.

'족적'이라는 말을 쓰는 이유가 있습니다. 남기려고 남긴 것이 아니라, 걸어가서 생긴 흔적이기 때문입니다. 발자국을 남기려고 걷는 사람은 없습니다. 걸으면 남습니다.

구체적으로는 이런 모습입니다.

• 과제 계획을 세우면 → 그 시점의 판단이 남습니다
• 시험 결과를 입력하면 → 근거 데이터가 됩니다
• 회의에서 정한 것을 그 자리에 적으면 → 결정 이력이 됩니다
• 후보에서 뺀 이유를 그때 적으면 → 다음 사람에게 전달됩니다

핵심 원칙은 하나입니다. 기록이 목적이 되면 안 됩니다.

기록을 위한 별도 업무가 생기는 순간, 그 업무는 우선순위에서 밀립니다. 바쁘면 건너뛰고, 나중에 몰아서 쓰고, 결국 형식적인 문서만 남습니다.

다만 조건이 있습니다

정직하게 말씀드려야 할 부분이 있습니다. 이 모델이 성립하려면 전제가 필요합니다.

업무가 시스템 안에서 이루어져야 합니다.

시스템 밖에서 일하고 결과만 올리는 구조에서는 족적이 남지 않습니다. 엑셀로 검토하고 메일로 협의하고 시스템에는 완료 보고만 등록한다면, 남는 것은 결론뿐입니다. 과정이 없으니 축적도 없습니다.

그리고 업무가 시스템 안에서 이루어지려면, 시스템 안에서 일하는 것이 밖에서 일하는 것보다 편해야 합니다.

여기서 앞선 글들과 연결됩니다. 입력 부담이 낮아야 하고, 입력 부담을 낮추려면 과제 유형별로 요구 수준이 달라야 하고, 유형을 나누려면 그 회사의 업무를 이해해야 합니다. 지식관리는 별개의 주제가 아니라, 관리체계 설계가 제대로 되었을 때 따라오는 결과입니다.

거꾸로 말하면, 지식관리만 따로 떼어내서 시스템을 하나 더 도입하는 방식으로는 잘 되지 않습니다. 실패한 사례들이 대개 그런 형태였습니다.

4. 무엇이 남아야 하는가

그렇다면 어떤 족적이 남아야 할까요. 대부분의 조직은 결과물을 남깁니다. 최종 보고서, 완성된 처방, 확정된 사양. 그런데 정작 필요한 것은 다른 쪽에 있습니다.

① 결과가 아니라 판단의 과정

최종 결론이 무엇인지는 문서에 있습니다. 그런데 왜 그 결론으로 갔는지는 어디에도 없습니다. 새로 맡은 사람이 알아야 하는 것은 후자입니다. 그래야 상황이 바뀌었을 때 판단을 수정할 수 있습니다.

② 채택한 것만이 아니라 기각한 것

이게 실무에서 가장 값어치가 큽니다.

무엇을 하기로 했는지만큼 무엇을 안 하기로 했는지가 중요합니다. 기각 이유가 남아 있지 않으면, 다음 사람이 같은 길로 다시 들어갑니다. 그리고 같은 지점에서 같은 결론에 도달합니다.

기각안을 남긴다는 것은 회사가 이미 지불한 수업료를 자산으로 바꾸는 일입니다.

③ 성공만이 아니라 실패

실패한 시험의 데이터는 버려지기 쉽습니다. 보고할 것이 없다고 여기기 때문입니다.

하지만 R&D에서 실패는 유효한 결과입니다. 이 조건에서는 안 된다는 사실을 확인한 것이니까요. 그 데이터를 버리면 확인 작업을 다시 해야 합니다.

④ 결론만이 아니라 전제

모든 판단은 어떤 가정 위에서 이루어집니다. 시장이 이럴 것이다, 규제가 이대로 갈 것이다, 이 원료는 계속 공급될 것이다.

그 전제가 바뀌면 판단도 다시 봐야 합니다. 그런데 전제가 기록되어 있지 않으면, 무엇이 바뀌었을 때 무엇을 다시 봐야 하는지 알 수 없습니다. 이 이야기는 3편에서 자세히 다루겠습니다.

⑤ 문서만이 아니라 맥락

같은 보고서라도 그것이 왜 만들어졌고 어떤 결정에 쓰였는지가 붙어 있어야 합니다. 맥락 없는 문서는 파일 하나일 뿐입니다.

5. 시스템이 할 수 있는 것과 할 수 없는 것

여기서 정직하게 말씀드릴 부분이 있습니다.

시스템이 20년 경력자의 감각까지 담아내지는 못합니다. 제형을 보는 눈, 데이터에서 이상을 알아채는 직관, 사람과의 관계. 이런 것을 시스템에 넣을 수 있다고 말하면 거짓말입니다.

시스템이 하는 일은 다른 쪽입니다.

저희는 이것을 "천장을 씌우는 게 아니라 바닥을 까는 일"이라고 표현합니다.

시스템이 뛰어난 연구원을 만들어 주지는 않습니다. 다만 누가 그 자리에 오든 회사가 이미 아는 것 아래로 떨어지지 않게 받쳐줍니다. 이미 확인된 것을 다시 확인하지 않게, 이미 접은 길로 다시 들어가지 않게.

달라지는 것은 인수인계의 품질이 아닙니다

여기서 흔한 오해를 짚고 싶습니다.

지식관리 시스템을 두면 인수인계가 잘 될 거라고 기대합니다. 인계 문서를 잘 만들 수 있게 되거나, 인계 기간이 짧아지거나.

저희가 말하는 것은 그게 아닙니다.

축적이 제대로 되어 있으면, 인수인계라는 이벤트 자체가 흐려집니다. 새로 맡은 사람이 특별히 무언가를 인계받는 게 아니라, 그냥 그 과제를 열어보는 것입니다. 지금까지 무슨 일이 있었고 어떤 판단이 있었는지가 거기 있으니까요.

그리고 이 차이가 결정적으로 드러나는 순간이 있습니다. 인계해 줄 사람이 이미 없을 때입니다.

전달 모델에서는 이 상황이 재난입니다. 넘겨줄 사람이 없으면 넘어갈 것도 없으니까요. 축적 모델에서는 특별한 상황이 아닙니다. 원래 사람이 아니라 시스템에 있었던 것이니까요.

6. 이것은 결국 자산의 문제입니다

마지막으로 이 이야기가 어디로 이어지는지 정리하겠습니다.

앞선 글에서 저희는 기업 안에 바뀔 수 있는 것과 바뀌지 않아야 하는 것이 있다고 말씀드렸습니다.

이사회, 경영진, 임원, 종업원. 사람은 언젠가 바뀝니다. 프로세스, 규칙, 데이터베이스, 축적된 판단의 이력. 이것은 남아야 합니다.

축적 모델은 이 원칙을 지식에 적용한 것입니다.

지식이 개인에게 쌓였다가 조직으로 넘어오는 구조에서는, 넘어오지 못한 것이 매번 사라집니다. 사람이 바뀔 때마다 조금씩 유실됩니다.

지식이 처음부터 조직에 쌓이는 구조에서는 다릅니다. 개인은 지식의 그릇이 아니라 사용자가 됩니다. 쌓인 것을 꺼내 쓰고, 자기 판단을 더하고, 다음 사람에게 그 상태로 남깁니다.

그래서 지식관리는 인사 문제가 아닙니다. 이직률을 낮추면 해결되는 문제도 아닙니다. 기업 자산을 어디에 둘 것인가의 문제입니다.

저희가 25년간 "시스템이 아닌 기업 자산을 만듭니다"라고 말해 온 것의 실제 의미가 여기 있습니다. 화면과 기능은 몇 년 뒤 바뀔 수 있습니다. 다만 그 안에 쌓인 판단과 이력은 회사에 남습니다.

다음 편 예고

그런데 쌓는 것만으로는 부족합니다.

많은 조직에서 실제로 벌어지는 상황은 "문서는 다 있는데 아무도 못 찾는 것"입니다. 축적은 되었는데 꺼내 쓰지를 못합니다.

왜 검색만으로는 부족한지, 그리고 무엇이 더 필요한지. 다음 편에서 이어가겠습니다.