brunch

You can make anything
by writing

C.S.Lewis

by Peter Apr 08. 2017

기업 위키(Wiki)를 통한 공유 지식

학습 조직을 돕는 도구와 주의점

불특정 다수가 내용과 구조를 수정할 수 있는 위키(wiki)는 어떤 형태로든지 기업에서 반드시 사용하는 도구가 되었습니다. 그것을 웹에서 위키백과와 같은 형태로 운영하는 곳이 있는가하면 구조를 유저 마음대로 바꾸기는 어렵지만 손쉬운 관리를 위해 이와 같은 기능을 가진 어플리케이션을 통해 하기도 합니다. 그 형태와 방법은 다르지만 클라우드를 통한 아카이브부터 네이버 밴드에 이르기까지 이와 같은 목적으로 기업 내부에서 지식을 공유하고자 하는 움직임은 늘 있습니다.



중요한 것은 역시 방법보다는 내용입니다. 방법이 불편해서 위키를 사용하지 않는 경우는 별로 없습니다. 현재의 툴이 예전에 비하면은 모두 편리한 수준이 되었습니다. 다만 더 편리한 것이 있다는 정도입니다. 위키가, 공유 지식을 구현하는 툴이 활성화되지 않는 경우는 보통 거기서 얻을 게 없을 때입니다. 이런 경우게는 몇몇이 올리고 대부분은 방치되어 있습니다. 일정 기간 동안 그걸 열람하거나 다운로드 받은 사람의 수가 거의 없는 일이 벌어집니다. 초기에 이용하던 유저도 곧 방문이 급격히 줄어들게 되는 경우가 발생합니다. 이것은 기업에서 다루는 지식을 저장하고 공유, 열람하는 형태가 툴과 맞지 않아서 벌어지는 경우도 있지만 분위기와 내용, 적용 방안에 대한 고민이 부족할 때 나타나는 경우가 더 많습니다.



그런데 이런 부류의 일은 일반적으로 기업의 전략 기획자를 비롯한 기획자가 맡을 때가 많습니다. 사실 기획자는 이런 것을 기술적으로 구현하는 능력도 이것을 자주 활용하는 주체는 아닙니다. 하지만 기업의 경영관리 시스템에 속한다는 이유로 기획자의 과업으로 정의된 기업이 적지 않습니다. 사실 기획자는 이것을 사용하는 빈도가 낮아 현재 기업 위키의 문제점과 발전 방향에 대해 알지 못할 때가 더 많은데 말입니다. 



분명 기업 위키가 활성화 되면 기업 내부에서는 얻는 게 많아집니다. 조직의 규모가 커지면서 기업 내부에서 잦은 빈도로 '데모데이' 같은 것을 하지 않으면 옆 부서가 하는 일도 모르게 됩니다. 사실 기업에서 지나가다 인사말로 많이 물어보는 게 "요즘 어떤 일해?"인 경우가 많은데 그만큼 옆에서 무슨 일을 하는지 모른다는 방증이기도 합니다. 기업 내부에서 생성된 역량은 기업 내부에 필요한 곳에 적용되어 전사적인 효과를 극대화 시켜야할 의무가 있습니다. 개별 조직이 이것을 다 모르기에 결국 이 역량의 관리와 적용은 컨트롤타워인 전략기획자 혹은 이와 유사한 직무의 롤이 되는 것은 어쩌면 당연한 일일 것입니다. 이렇게 공유된 지식은 조직이라는 관리형 장벽을 허물고 내부에서 더 나은 단계의 기술과 지식을 더 빨리 만들어내는 역할을 합니다. 이 꽃과 저 꽃 사이에 꽃가루를 옮겨주는 벌과 같은 역할을 기업 내부에서 하게 되는 것입니다. 



하지만 이것이 강요되어서는 안됩니다. 이것 자체가 문화이기 때문입니다. 위키의 활용이 입력부터 공유, 적용에 대해 일정한 간섭과 가이드가 내려오면 그것은 곧 하나의 일로 바뀌고 본질과 맞지 않는 보여주기식 껍데기로 전락하기 때문입니다. 그러므로 위키를 운영하는 기획자는 주의해야 할 내용들이 있을 수 밖에 없습니다.






입력 - 모두가 항상 자질구레하게



위키의 활성화가 가장 중요한 미션입니다. 구성원들이 위키를 사랑하게 해야 합니다. 그렇지 않으면 위키는 또 하나의 과제가 됩니다. 그러기 위해서는 유저당 사용하는 위키가 적을수록 좋습니다. 이왕이면 하나의 위키 도구로 모든 것을 다 할 수 있는 게 좋습니다. 이를 위해서는 위키의 입력과 열람의 권한과 범위를 최대한 많은 구성원에게 주는 것이 좋습니다. 위키의 게시물을 몇 명의 파워유저만 올린다면 그것은 진정한 위키가 아닌 '전시회'가 됩니다. 위키는 모두가 네이머 어플 들어가서 보듯이 보겠지만 전시회가 되는 순간 가끔 시간이 날 때만 찾아가는 것이 되어 버립니다. 물론 전시회가 되지 않으려면 위키에 게시물이 올라오고 수정되고 구조가 바뀌는 빈도도 정기적인 간격을 두는 게 아닌 리얼타임으로 언제든지 이루어질 수 있어야 합니다. 좋은 위키는 정제된 지식을 기다리면서 한동안 정지된 것이 아니라 늘 역동성 있게 모두의 참여와 관심으로 만들어지기 때문입니다. 정제된 지식을 특별히 만들고 싶다면 그것을 어디 다른 구조로 보여주면 될 일입니다. 하지만 조직 지식 공유의 출발이 되는 위키는 모두가 자질구레한 것까지 항상 사용할 수 있어야 합니다.



마치 '나무위키'나 '위키백과'와 '0000 사전'의 차이와 같은 것입니다. 밀레니엄 전후만 해도 '000 사전' 등 권위를 인정받은 대상이 정제된 지식을 버전이 바뀔 때마다 업데이트를 하는 게 우리가 알 수 있는 지식의 전부였습니다. 실시간은 당연히 아니었으며 변화 속도와 맞지 않았습니다. 하지만 지나간 경험에 대한 기록은 정확했고 개념에 대한 권위가 필요했으므로 역사와 철학과 미학 등을 설명하는 데에는 이런 방법이 적절했습니다. 누가 어떤 견해를 밝혀도 이런 것은 권위가 더 존중 받았습니다. 지금도 이런 형태의 지식 공유를 하는 기업들이 있습니다. 하지만 이것은 리얼타임으로 시장이 바뀌는 기업의 업무와 맞지는 않습니다. 다만 기술적 레퍼런스를 이런 방법으로 확보할 수는 있을 것입니다. 도서관의 형태로 말입니다. 그러나 업무 작업의 방법의 진보한 프로세스나 마케팅과 재무 관리의 기법은 늘 변화하는 것이고 권위자라고 누군가를 만들면 그 사람이 다 알 수 있는 폭이 아니므로 이런 형태는 곧 정지되고 맙니다. 반면 '나무위키' 같은 형식의 입력과 관리는 귀납적인 지식 공유에 적합합니다. 아이돌 가수의 어제 일이나 스포츠 구단의 이번 주 경기 결과가 나무 위키 같은 곳에서는 거의 하루 이내로 수정되어 바뀝니다. 물론 인기에 따라서 페이지가 없거나 업데이트가 늦은 경우가 있지만 기업 내부에서도 이런 컨텐츠 수정의 빈도는 곧 중요성을 보여주는 방법이므로 이것은 그렇게 맡기면 됩니다. 아주 업무의 바닥 정보와 해결 방안은 모두에게 기회가 제공된 공유 방법으로만 알려질 수 있으므로 이런 것은 일전에 언급한 직무별 KPI 셋업과 이것을 토대로 한 큰 규모의 방향 설정에도 도움이 됩니다.





내용 - 결과가 아닌 방법을



입력을 모두에게 열어주면 출발은 많은 관심 안에서 할 수 있습니다. 하지만 위키의 수명은 내용의 품질을 어떻게 정의하느냐에 달려 있습니다. 먹을 게 없는 식당에 굳이 갈 필요가 없는 것 처럼 말입니다. 중요한 것은 일의 결과만 공유하는 게 아니라 일의 과정과 사용한 방법을 모두 위키에 올려야 한다는 것입니다. 일부 기업에서는 보안을 이유로 이것을 공유하지 않습니다. 또 내부 경쟁을 이유로 정말 중요한 노하우는 공유되지 않기도 합니다. 또 어디서는 이것을 기준으로 개인의 고과를 판정하므로 실체보다 과장하거나 사실상 허위에 가까운 것이 올라오기도 합니다. 이런 부작용을 없애기 위해 일을 마치거나 일의 중간 단계에서 일에 쓰인 것 외에 어떤 것도 추가 자료를 작성해서 공유되는 일은 없어야 합니다. 다만 '이것을 보면 이렇게 하겠구나' 알 수 있는 방법 그 자체가 필요합니다. 시스템 설계에 대한 내용이면 쿼리문을 다 올려 버립니다. 모델링을 해서 마케팅 방법을 새로 설정한 경우에는 모델링에 사용한 모든 중간 파일을 다 올립니다. 보안은 열람에 있지 않고 반출방법에 있습니다. 반출방법인 파일의 개별 서버로의 출력이나 스크린샷 등의 방법들만 제어하면 됩니다. 다만 열람은 모두에게 있어야 합니다. 애플에 출근한 첫 날 애플의 중요 파일을 볼 수 있어서 놀랐다는 한 블로거가 써서 얼마 전에 이슈가 되었던 내용도 보안을 이유로 정치와 지식의 단절과 소통의 부재가 낳는 손해가 보안 유출의 피해보다 잠재적으로 더 큼을 말하는 단적인 예이기도 합니다. 보안에 관심이 없는 기업일수록 유저의 접속을 차단하여 활성화 시키지 못하는 방법으로 보안을 유지하려고 합니다.



이렇게 모두에게 열람되는 방법은 세부 파일부터 최종 보고서까지 최대한의 자유도를 가지고 이것을 보면 우리 사업, 우리 팀에도 바로 실체를 알 수 있는 형태와 내용으로 되어야 합니다. 한참 보고나서 이게 무엇일까, 어떻게 작동되는 것인가 궁금하다면 위키의 역할은 없는 거나 마찬가지입니다. 이것이 가능하기 위해서는 당연히 팀간 사업부간 부서간 상대평가가 없어야 합니다. 등수로 자리가 판가름되는 사회에서는 절대 자신의 답안지를 남에게 보여주지 않습니다. 지식의 공유를 주장하는 기업에서 상대평가로 줄 세우기를 한다는 것 자체가 전략이 없는 것입니다. 전략이 한 방향을 전사적으로 향해 가듯이 기업 내부의 유틸리티도 한 방향을 바라보고 가는 게 당연하지만 경영 시스템은 성역과 같이 이런 것 바깥에 있는 경우가 종종 있습니다.





적용 - 전체적인 강요가 아닌 개별과 자유 



위키를 만들 때는 목적이 있었을 것입니다. 이것이 활성화 되면 뭐가 좋아진다.. 그러면 숫자로 말할 수 있는 성과가 얼만큼 나올 것이다.. 하지만 이것은 보고를 위한 가설에 불과합니다. 노트를 산다고 성적이 몇 점 올라간다는 게 보장되지도 측정되어질수도 없는 것과 마찬가지입니다. 기업은 대부분 모든 적용에는 측정할 수 있는 성과를 내야 된다고 하지만 측정이 당장 안되는 장기적인 인프라는 이런 이유로 외면해서 전체적인 역량의 수준을 방치하는 경우가 종종 있습니다. 위키도 이런 경우입니다. 경영진이나 기획팀장의 혜안과 추진력이 없으면 이것도 역시 도입부터 활용까지 취지에 맞지 않게 왜곡되는 일이 벌어집니다.



위키는 재미로 하는 겁니다. 노하우건 지식이건 아무말 대잔치건 재미가 없으면 위키 같은 것은 하지 않습니다. 자발적으로 해야 될까말까한 게 위키같은 것입니다. 업무 오덕을 만들어 내야 할 수 있는 것입니다. 자원봉사자 같은 마음이 있어야 겨우 하는 것입니다. 하지만 기업은 이것을 재미 없게 만들기도 합니다. 대표적인 것이 활용 점수 같은 것입니다. 몇 개 의무적으로 입력을 하고 몇 개를 일정 기간 동안 업무에 적용한 것을 보고하고 그것의 성과를 측정해서 보포상 하고 부진하면 인사고과에 반영하는 매우 관리를 위한 방법 말입니다. 그러면 다들 하기는 할 겁니다. 그렇지만 이런 기업에서는 진정 자신의 지식을 거기 올리는 사람도 없을 것이고 그런 규제가 끝나는 순간 그 위키도 함께 사라질 것입니다. 이런 것은 시스템이 아닙니다. 어떤 규제가 마치면 동시에 사라지는 것은 유저가 이것을 관리하는 관리자 한 사람일 경우에만 가능한 것입니다. 위키의 유저는 모두입니다. 



특히 적용에서 주의를 기울여야 합니다. 하나의 성공한 사례를 전 분야에 걸쳐 적용하는 것은 아주 위험합니다. 사례 자체가 과거이기에 하나의 레퍼런스에 불과합니다. 정반합에 의해 반드시 더 현실에 맞는 방법으로 바뀌어야 합니다. 그것은 더 정교할수도 덜 정교할수도 있습니다. 있어야 합니다. 일괄적인 전역적인 적용은 브랜딩을 해치고 각각 다른 사업 모델을 하나의 표준화된 블랙홀 속으로 빨아들여서 나중에는 기존의 우수한 것도 다 망쳐 버릴 수 있습니다. 위키의 활용은 해도되고 안해도 그만입니다. 평가는 사업의 결과로 하는 것이지 이런 것을 활용하는 것으로 하는 게 아니기 때문입니다. 단, 필요하면 살아남기 위해 할 것입니다. 활용이 없다면 위키의 수준이 그렇다는 것입니다. 이런 수준이 공유되느냐 안되느냐는 기업의 문화입니다. 누가 먼저 올려도 되고 늘 토론해도 되고 언급한 것처럼 평가와 승진 제도의 문제일 수도 있습니다. 채찍질을 한다고 되는 일이 아닙니다.






변화하는 시장 속에서 조직은 필연적으로 자신의 롤을 바꿔나가야만 합니다. 이름이 과거와 같은 조직도 하는 일은 과거와 바뀌는 게 맞습니다. 그러기에 기업 아카이브를 위키와 같은 형태로 관리하는 것은 그동안의 히스토리 변화에 따라 전사적인 조직과 미션을 수정하는 데 도움이 됩니다. 이것은 기업 내부의 역량이나 비전을 정이하는데 귀납적인 근거로 활용될 수 있습니다. 기업 외부의 환경으로만 비전과 미션, 조직을 구축하기에는 각각이 처해 있는 상황과 보유하는 자원에 따른 비교우위가 다릅니다. 그러기에 내부에 대한 진단은 이런 실무적인 근거가 어느 정도 있어야 정확하게 평가될 수 있습니다. 예전처럼 책상에서 아이디어나 재무적 수치의 변화로만 설명하기에는 역량의 본질을 파악하기 너무 어려워졌습니다. 물론 기업의 규모와 산업군에 따라 이런 방법론은 다를 수 있지만 최근 경험한 내용들을 보면서 아카이브와 클라우드, 위키에 대한 활용에서 기획자의 컨트롤 방향을 생각하는 팁으로 봐 주시면 좋을 것 같습니다.




작가의 다른 콘텐츠


브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari