많은 회사 개발자를 만나면서 느끼는 우리나라 소프트웨어 회사들의 가장 큰 문제 중 하나는 개발자간에 정보와 지식의 공유가 잘 안 되는 것이다. 회사가 크던 작던 거의 모든 회사가 동맥경화에 걸린 것처럼 정보와 지식이 공유되고 유통되지 않고 몇 사람만 알고 있다. 회사가 크면 클수록 이런 현상은 더욱 심해진다.
꽤 오래 전 어떤 개발자가 개발을 하면서 특정 라이브러리의 호환성 때문에 한 일주일 고생을 한 적이 있다. 인터넷도 검색하고 여러 시도를 해 보았지만 잘 해결이 안돼 여러 개발자가 고생을 하고 있었다. 수시로 사무실 통로에 서로 모여서 이와 관련된 짧은 토론을 여러차례 하면서 회사 내의 이슈가 되고 있었다.
그렇게 며칠이 지날 때쯤 한 개발자가 말하길 이것은 자신이 수개월전에 이미 시도를 해보고 다 조사를 해본 것이라고 한다. 그리고 이것은 불가능하다는 것의 증거를 가지고 있다고 했다. 진작에 이것 때문에 고생하고 있다는 것을 알았지만 개발자들이 일주일이 지나도 해결을 못하자 자랑스럽게 얘기를 해주는 것이었다. 회사가 크고 서로 사무실이 달랐다면 이 조차도 전달이 안되었을 것이다. 그나마 회사가 작으니까 나중에라도 얘기를 해줄 수 있었다.
이런 얘기를 들을 경우 개발자들은 그 개발자를 어떻게 생각할까? 남들이 모르는 것을 알고 있다고 존경심을 가질까? 아니면 왜 미리 알려주지 않았나 서운해할까? 아니면 이런 정보가 공유가 잘 안 되는 회사의 문화, 프로세스와 시스템을 탓할까?
이런 개발자는 회사의 중요한 사람일까? 없어야 하는 사람일까? 내 생각은 이렇게 중요한 정보를 본인만 알고 있고 고의로 공유를 안하는 개발자는 해고감이다. 개발자는 개발에 관련된 내용을 적절히 충분히 기록하고 공유를 해야 한다. 이것은 말은 쉽지만 매우 어려운 일이다. 개발 과정에서 효율적이고 자연스럽게 정보와 기록을 남기고 공유를 해야 한다.
이런 현상이 비단 개발자 탓만은 아니다. 공유가 잘 안되는 문화를 가진 회사에 입사를 해서 다른 사람과 자연스럽게 동화된 것 뿐이다. 공유를 할 마땅한 방법이 없기도 하고, 혼자서 열심히 공유를 하려고 해도 대부분의 개발자들이 자신의 업무에 바빠서 공유된 정보에는 관심도 없는 경우가 많다. 국내 많은 소프트웨어 회사들이 이와 비슷하다. 공유를 위해서 애쓰지만 대부분 성공적이지 않다. 공유에 실패하는 회사는 다음과 같은 특징이 있다.
첫째, 소수의 인원만 정보 공유에 애쓴다. 경영진을 비롯해서 대부분의 개발자는 공유에 별로 관심이 없다. 공유가 왜 중요한지 인식을 못하기도 한다. 개발자 혼자 공유 문화의 전도사처럼 나서지만 누구 하나 인정해주지도 않고 본인도 금방 지치게 된다.
둘째, 공유를 위한 시스템이 없거나 부족하다. 공유를 한다고 문서를 만들어도 문서가 버전관리도 안되고 여기저기 굴러다니고 정보를 찾기도 어렵다. 좋고 비싼 시스템이 있어도 제대로 사용하지 않는다. 이럴 때 비싼 시스템은 오히려 적절한 공유에 방해가 되기도 한다.
셋째, 개발과는 별도로 문서를 따로 만든다. 문서를 만들어도 많이 만든다. 게다가 문서를 만드는데 엄격한 규칙이 있다. 대부분의 대기업이 여기에 해당한다. 경영진이 공유의 의지를 가지고 밀어붙이는 경우도 대부분 이렇게 된다. 하지만 이렇게 별도로 문서를 많이 만든다고 공유가 잘되는 것은 아니다. 엄격한 프로세스로 비효율적으로 많은 문서를 만들기도 하고 이를 형식적으로 지키기도 하지만 이것으로 공유에 성공했다고 볼 수는 없다.
정작 중요한 정보는 공유가 안된다. 이런 회사의 특징은 대부분의 문서가 서로 정보가 안맞고 계속 업데이트가 안되서 쓸모가 없다. 게다가 쓸모 없는 문서와 쓸모 있는 문서가 섞여 있어서 올바른 정보를 구분하기 어렵다.
넷째, 기존의 지식을 문서로 만들려고 애쓰다가 실패한다. 기존의 지식과 정보를 모두 끄집어내서 문서화 하는 일은 거의 불가능한 일이다. 일할 당시 그때가 아니면 문서화는 어렵다. 하루가 지나면 기억 속의 정보는 50%가 사라지고 일주일이 지나면 90%가 사라진다. 지금이 아니면 나중에는 문서화 할 수 없다. 밀린 일기는 포기하고 오늘 일기부터라도 쓰는 것이 좋다.
다섯째, 항상 너무 바쁘다. 특히 고참일수록 더 바쁘다. 신입사원은 제대로 일하려면 수개월이 걸린다. 그러다 보니 고참이 더 바빠서 공유에는 신경 쓸 시간이 없는 악순환이 계속된다.
반대로 공유에 성공한 회사는 다음과 같은 특징이 있다.
첫째, 경영진을 비롯한 모든 개발자가 공유에 힘쓴다. 공유가 얼마나 중요한지 모두 잘 알고 있고 공유에 문화적으로 시스템적으로 투자를 한다.
둘째, 적절한 시스템이 구축되어 있다. 대부분 이슈관리시스템, Wiki등의 시스템이 잘 구축되어 있고 회사의 거의 모든 정보와 지식이 잘 저장되어 있다. 뿐만 아니라 휘발성 커뮤니케이션 수단인 전화, 메신저, 이메일 등은 보조수단으로 사용되며 중요 정보는 대부분 시스템을 통해서 전달되고 공유된다.
셋째, 문서는 최소로 만든다. 불필요한 문서를 만들지 않고, 꼭 필요한 문서 몇 개만 만든다. 문서의 형식도 꽤 자유롭다. 개발자들이 토론하면서 노트에 그린 그림을 사진을 찍어서 올리기도 하고, 온라인 그리기 도구를 쓰기도 하고 상황에 맞게 자유로운 도구를 활용한다.
넷째, 공유가 습관화 되어있다. 항상 일하는 과정에서 자연스럽게 공유를 한다. 별도로 문서를 만든다고 많은 시간을 소비하지 않는다. 자유롭게 필요한 만큼 알아서 효율적으로 공유를 한다. 항상 노트를 하고 즉각 정리해서 이슈관리시스템이나 Wiki에 등록하는 것이 일상화 되어 있다. 개발자가 수시로 하는 작은 조사, 개발도 모두 문서화되고 공식적으로 진행된다.
다섯째, 리뷰가 활성화 되어 있다. 모든 정보는 문서로 공유하기는 어렵다. 토론도 많이 하고 리뷰도 자주 있다. 리뷰과정을 거쳐서 문서는 꼼꼼히 검토가 되고 여러 직원들의 전문적인 의견이 반영된다. 고참일수록 리뷰에 많이 참석하며 자신의 경험과 지식을 리뷰를 통해서 전수한다.
공유는 소프트웨어에서는 가장 중요한 기업 문화이다. 소프트웨어가 창의적인 지식산업이기 때문에 더욱 그렇다. 하지만 대부분의 회사는 위에서 언급한 공유에 실패하는 증상들이 보이고 있다. 그렇다고 이제부터 공유를 열심히 하자고 마음만 먹는다고 공유가 잘되는 것은 아니다. 복잡한 프로세스를 도입하는 것보다 공유 문화 정착이 열 배는 어려운 일이다.
경영진의 의지가 가장 중요하지만 의지만 가지고 밀어붙이다가는 프로세스만 복잡해지는 함정에 빠지기가 매우 쉽다. 문화란 그만큼 바뀌거나 도입하기 어려운 것이다.
이글은 ZDNet Korea에 기고한 칼럼입니다.
