팀 내 커뮤니케이션 문제 해결 위한 Wiki 도입

배경

문서화를 하고 중복적인 커뮤니케이션 비용을 줄이면 직접적으로 회사에 도움이 된다고 믿습니다. 커뮤니케이션 체계를 갖추면, 시간이 지나면 지날수록 새로운 기능을 개발하는 것 만큼 혹은 그 보다 더 많은 이윤을 남긴다고 생각합니다. 왜냐하면 그 비용에 절대적인 시간이 투여되고 업무 스트레스를 포함하기 때문입니다. 이번 글에서는 최근 팀 내에 위키를 도입하여 커뮤니케이션 방법을 개선한 이야기를 소개해드리려고 합니다.
 
데이터베이스 모니터링 제품들을 담당하는 저희 DB팀에서는 에이전트 개발팀과 많은 시간을 보냅니다. 다만, 대부분의 의사소통을 메신저를 통해 진행하기 때문에 원활한 의사소통이 되지 않는 경우가 많았는데요. 
 
제가 어려웠던 점은 데이터베이스별로 사용하는 데이터가 여러 형태로 이루어져 있었고, 수 많은 메트릭 이름들이 일관성이 없어서 혼란스러웠습니다. 문서로 가끔 정리된 것은 있습니다. 엑셀, 노션 등으로 여러가지 형태로 저장되어 있고, 찾기가 힘들었습니다. 찾으려는 정보가 없을 때가 대부분이었지만 찾았더라도 이미 오래되어 outdated 된 것이라 참고만 할 뿐이었습니다.
 
그래서 구두나 메신저로 같은 질문을 많이 하게 됐습니다. 이런 커뮤니케이션 방법의 문제점은 금방 질문들이 휘발된다는 점이에요. 각 개개인이 질문들을 정리할 수는 있지만, 보통 가볍게 넘기는 경우가 대다수 였던거 같습니다. 때문에 같은 확인 요청을 하는 경우가 많았습니다.  구두나 메신저로 이야기한 내용들을 개인이 정리하다보면 생각이나 문서들은 의미가 엇갈릴 수도 있다고 생각해요.
 
대화나 회의 후, 각자 나름대로 문서 관리를 합니다. 문서 관리를 하지 않는 사람은 "생각 관리"라고 표현해볼게요. 그런데, 만약에 갑자기 우리의 생각(문서)을 통합할 수 있는 신기한 서버가 나타났다고 가정해봅시다. 모든 구성원들의 생각(문서)를 그 신기한 서버에 push 하면 어떤 일이 발생할까요? 정말 수 많은 생각들이 conflict가 발생할거에요.
 

 
그래서 팀에 적응하면서, 개발 업무 외 자연스럽게 가장 관심이 가서 작업을 해야겠다고 생각한 건 이런 문서화 프로세스와 깃헙 리포지토리같은 생각과 문서를 통합할 수 있는 일종의 업스트림 저장소를 만드는 것이었습니다.
 

문제

에이전트 개발팀에서 모니터링하는 원본(raw) 데이터의 이름이나 타입 등을 포함한 중요한 메타 정보를 개발하기 때문에, 이런 raw 데이터들을 가지고 작업을 하는 서버 개발자인 저와, 그리고 프론트엔드에 직/간접적으로 연결되기 때문에, 커뮤니케이션은 개발 업무에서 정말 중요한 역할을 차지합니다.
 
이전에는 공유가 정말 필요한 문서의 형태가 필요했을 때는 개개인이 사용하기 편리한 툴을 이용해 팀원들끼리 링크를 던져준다던가 했는데요.
때로 메트릭 정보 같은 경우 이름, 설명, 단위 등 하나의 정보에 대한 메타 데이터가 주를 이루기 때문에, 표 형태로 정리하는게 편하다고 느껴 액셀에 정리를 하고요.
때로는 노션에서 관리하면 DB팀 외에 다른 팀들도 볼 수 있어 언급하기 좋기 때문에 노션에 정리하기도 했습니다.
때로는 기능 개발, 버그 히스토리 등은 지라에 작업을 하면서 생기는 부수적인 정보들이 생기기 마련인데, 공유 문서가 없으면 "왜 이렇게 되어있지?"라는 상황을 많이 연출하게 됩니다.
 
여러 곳에 분산된 정보는 동일한 질문을 반복하게 만들어요. 여러 소스들을 참고하며 찾아야 하는 비효율적인 상황을 만들게 되고요. 이로 인해 커뮤니케이션 비용이 크게 증가하고, 중요한 정보가 누락될 수 있습니다. 항상 개인이 기억했다거나 문서로 저장했다고 하더라도 교차로 확인하는 것은 아니기 때문에, 개개인이 정리한 지식 정보는 교차 검증이 필요하게 됩니다. 그렇지 않으면 오해가 발생할 수 있어요.
 
데이터베이스 벤더마다 수집되는 지표들이 굉장히 다양하고 많기 때문에 데이터 메타 관리에 대한 어려움도 있었습니다. 저희 팀장님의 경우에는 이런 다양한 정보들이 테크니컬 라이터나 다른 엔지니어들과 의사소통하면서 전달해야하는 경우가 많았는데, 여러 플랫폼에 혼재되어 있다보니 그것들을 찾고 전달하는 데에도 꽤 고생을 하셨습니다.
 
더 이상 이 문제를 곪게 놔둔다면 앞으로 지속적으로 성장할 프로덕트만큼 커뮤니케이션과 혼재된 정보들 속에서 더욱 고통받을 팀원이 그려졌기 때문에, 시기가 더 늦기전에 반드시 해결하고 지나가야하는 문제라고 생각어요. 다시 말해서, 통합적인 정보 관리 솔루션이 필요하다고 느꼈습니다.
 

문제 접근

먼저 메트릭 데이터가 다양하고 분류해야할 게 많아서 잘 분류할 수 있어야했습니다. 잘 분류해서 볼 수 있는게 가장 중요했습니다. 검색이 잘되어야 했고, 이것을 누가 어떻게 수정했는지도 볼 수 있어야 했습니다.
 

노션으로 해볼까요?

처음에는 노션을 통해 통합해보려고 고려해봤습니다. 노션은 문서를 다양한 형태로 관리할 수 있게 다양성을 제공하지만, 오히려 그 다양성 때문에 목적성에 맞게 템플릿과 데이터를 관리하는 체계를 구성하려면, 공을 많이 들여야했습니다. "블록"이라는 단위로 자율성을 많이 주다보니 중구난방이 되어버리지 않을까 생각했습니다. 뭔가 정보 관리를 위한 최소한의 제한된 틀이 있어야한다고 생각했거든요.
 
노션을 선택하지 않은 또다른 이유는 노션은 꽤 느립니다. 데이터베이스 같은 기능을 쓰면 더 그런거 같고요. 가끔 노션 서버가 먹통이라 접근이 안될 때도 있었던 경험이 몇번 있습니다. 별로 안정적이라는 느낌이 들지 않아요. 그리고 누가 무엇을 생성하고 수정하고 삭제했는지 기능은 제공하지만, 제한된 기능과 UI로 히스토리를 파악하기 조금 힘들다고 생각했습니다. 개인적으로 이 기능이 중요하다고 생각하는데, 문서 공유할 때 어떤 사람이 이런 내용을 작성한지 쉽게 파악이 가능하면, 틀리거나 다르게 알고 있는 내용 등을 빠르게 피드백 할 수 있기 때문입니다.
 

우리는 어떤 것이 필요했을까요?

정리를 하자면 아래와 같았습니다.

1. 잘 분류할 수 있어야 합니다.
2. 검색이 되어야합니다.
3. 누가 어떻게 수정했는지 확인 가능해야 합니다.
4. 안정적인 소프트웨어야 합니다.
5. 노션에서 "블록"같은 자유로움보단 어느정도 정해진 틀이 있어야합니다.
6. UI/UX가 깔끔하고 사용성이 좋아야 합니다. 

위 요구 사항은 위키라는 개념이 가장 적절히 만족시킨다고 봤습니다. 그래서 어떤 위키들이 있는지 살펴보고 괜찮은 오픈소스를 하나 선택했습니다.
 

문제 해결

어떤 위키들이 있을까요?

DokuWiki

Wiki.js

BookStack

왜 BookStack인가요?

이런 저런 오픈소스 위키를 찾아보던 와중에 BookStack이 가장 적절하다고 생각했습니다.
 
팀원들이 같이 사용하도록 설득하려면 첫인상이 가장 중요하다고 생각하는데요. 북스택의 첫인상은 너무 좋습니다. 너무 깔끔해서 위키의 투박함이 생각나지 않아요. 컨셉도 너무나 마음에 듭니다. 말그대로 책들이 쌓여있다는 Book이 Stack되어 있는 이미지를 상상하면 됩니다.
 
책이 있고, 그 안에서 챕터를 나눌 수 있고 페이지를 쓸 수 있습니다. 책들이 쌓이기 시작하면 책꽂이에 책을 넣으면 됩니다. 이런 서점과 같은 컨셉을 따르고 있기 때문에 굳이 설명하지 않아도 지식과 정보를 쉽게 분류할 수 있다는 큰 장점이 있습니다.
 
문서 버전 관리, 태그 기능, 문서 내 검색 등 다양한 기능을 통해 효율적인 정보 관리를 지원합니다. 특히, 노션보다 체계적인 버전 관리와 사용자 행위 추적이 용이하며, 알림 기능을 통해 중요한 업데이트를 놓치지 않도록 합니다. 커스터마이징이 용이하고, 필요에 따라 기능을 추가하거나 수정할 수 있습니다. 이외에도 제공하는 필수 기능과 편리한 기능이 많습니다.
 
BookStack은 9년동안 유지보수가 된 오래된 오픈소스입니다. 메인테이너가 풀타임으로 유지보수합니다. 커뮤니티도 활발합니다. 심지어 정식 릴리즈에 포함되지 않는 여러 사용자들의 요구사항들도 BookStack Hacks 페이지를 통해 제공하고 있습니다. 그만큼 주요 메인테이너가 정성을 쏟고 있다는 반증이라고 생각했습니다.
 

어떤 방법으로 배포했나요?

위에 언급한 이런 저런 이유들로 BookStack에 매료되어 팀 내부에서 뿐만이 아니라, 최근에는 저만의 위키도 구축하여 운영하고 있습니다. BookStack에서는 다양한 환경에서 쉽게 설치할 수 있도록 가이드하고 있는데요. 사내 서버와 개인 서버에서 서로 다른 방법으로 배포했기 때문에 구분해서 소개해드리겠습니다.

사내 서버

먼저 사내 서버에서는 Docker Compose를 사용해 쉽게 배포할 수 있도록 했습니다. 이런 추가 인프라 관리가 필요한 것은 쉽고 편하게 관리하는 것이 가장 중요하다고 생각합니다. 그렇지 않다면, 여의치 않아 팀이나 회사를 옮기게 됐을 때, 여태까지 공들여온 정보 창고가 분명히 흐지부지 무용지물될 거라고 생각하기 때문입니다. 따라서, 제가 없더라도 다른 사람이 이 위키 인프라를 관리하게 된다면, 여타 배경지식 없이 정말 최소한의 노력으로 관리가 가능한 상태여야한다고 생각했습니다.
 
그래서 docker를 사용해 `docker-compose up -d` 커맨드만 입력하면 바로 서버 구축이 가능하도록 했습니다. 주기적인 백업 프로세스도 마련했습니다. 사용하던 bookstack 서버가 갑자기 폭파되거나 하더라도 언제든지 새로운 서버에서 간단하게 구축할 수 있게 했습니다. 코드는 궁금하시면 dusrnth/bookstack에서 확인할 수 있습니다.

개인 서버

개인 서버에는 사내 서버처럼 서버를 옮기기 편하게 하기 보다는 서버 자체를 커스터마이징할 수도 있겠다는 생각에 컨테이너 보다는 그냥 호스팅 서버에 설치하도록 했습니다. 참고로 서버는 AWS LightSail 을 사용했는데요. AWS 가 편하기도 하고 처음 DigitalOcean에서 호스팅 했었는데 거기보다 제공하는 콘솔도 더 편리하고, 쌌던거 같습니다. 제 개인 위키가 궁금하시면 https://kyupid.wiki 에서 확인하실 수 있습니다.
 

결론

결국 문제는 정리되지 않은 문서로 인한 커뮤니케이션 문제였습니다. 이 문제를 곪게 놔둔다면 앞으로 지속적으로 성장할 프로덕트만큼 커뮤니케이션과 정보의 홍수속에서 더욱 고통받을 팀원이 그려졌기 때문에, 통합적인 정보 관리 솔루션 구축이 필요했던 것이었습니다.
 
팀원들 모두가 이런 문제점에 공감을 해주었습니다. 이에 대한 해결책으로 위키를 사용하기로 하고 BookStack을 간략하게 구축하여 소개해드리면서 사용하기를 설득했을 때, 다행히 반응이 좋아서 빠르게 도입을 할 수 있었습니다.
 
아직은 적용한지 한달 밖에 지나지 않았지만, 제가 바로 느낄 수 있었던 장점은 심리적으로 정보들이 모두 위키에 저장되고 있다는 안정감과 궁금한 정보를 찾거나 공유할때 해당 위키 플랫폼에만 접속하면 된다는 쉬운 접근성입니다.
 
앞으로 구축한 위키는 인프라가 안정적으로 정착할 수 있도록 팀원 분들을 계속 독려하고, 지속적으로 작은 것이라고 위키 문서로 올려 공유하면서 업무 중에 자연스러운 하나의 플로우로 가져갈 수 있게 하는 것이 목표입니다.

의식적으로 계속 위키 URL 공유하면서, 커뮤니케이션 방법을 변경

사용중인 화면1

사용중인 화면2