이 기록은 "구글 개발자는 이렇게 일한다"라는 책을 보고 느낀 점을 정리한 글입니다. 글쓴이의 주관적인 경험이 들어있음을 알려드립니다.
버스 지수
책에서는 버스 지수라는 개념에 대해서 소개한다.
버스 지수란 몇 명의 팀원이 버스에 치여서 일을 할 수 없을 때, 프로젝트가 망하게 되는지에 대한 지수를 의미한다.
결국 버스 지수가 낮으면 낮을수록, 적은 팀원들에게 정보가 집중되었다는 의미이고, 적으면 적을 수록 위험한 상황인 것이다.
팀원 중 누군가가 퇴사하거나, 휴가를 내는 경우 해당 인원이 없는 만큼 서비스가 정상적으로 작동하지 않을 가능성이 높아지는 것이고 담당자는 결국 업무 과다로 힘들어 할 것이다.
그렇다면 이것을 어떻게 버스 지수를 높여 안정적인 상황으로 만들 수 있을까?
방법은 여러가지가 있다.
요즘 IT 회사에서 많이 사용하는 "페어 프로그래밍"과 같은 방법이나, 문제점이나 어려웠던 점, 고민한 점을 공개적으로 다른 사람들과 공유하는 것이다.
페어 프로그래밍을 활용한다면 코드를 짤 때, 강제로 피드백을 주고 받으면서 코드안에 들어간 누군가의 생각을 2명이서 공유하게 된다.
따라서 기존에 버스에 1명이 치이면 해당 기능을 유지보수 할 수 없는 인원이 없어졌다면, 이제는 2명이 모두 치여야 해당 기능을 유지보수 할 수 없는 것이다.
다른 방법은 공개적으로 다른 사람과 공유하는 것이다.
구글의 지식 공유
구글에는 "메일링 리스트"라는 것이 존재한다고 한다.
특정한 주제에 대해서 구글 그룹스를 만들고, 누구든지 가입하고 메일을 보낼 수 있도록 하다는 것이다. 이를 통해 해당 주제에 대해서 답을 줄 수 있는 많은 사람들에게 전달되고, 모두가 해당 질문을 보면서 해당 개념을 잘 모르던 사람들도 지식이 공유될 수 있다는 것이다.
나는 이 기능이 정말 유용하다고 생각이 든다. 단순히 내가 어떤 문제를 맞닥뜨리게 되었을 때, 그것을 해결한 사람 혹은 고민한 사람들과 공유하고 더 좋은 방식에 대해서 고민하게 되는 선순환이 되기 때문이다.
내 경험
가장 인상 깊었던 기억은 게더링을 만들던 시절이었다.
당시에 게더링을 만들 때는 내가 서비스 개발을 처음 해보았을 때였다. (슬랙도 처음 써보았다..)
이 때는 어떤 것들을 물어볼 때, 개인 DM으로만 묻고 답하기를 좋아했다. 굳이 다른 사람들에게 알릴 필요가 있을까?라는 생각이었다.
하지만 PM의 생각은 달랐다. 자신이 어떤 어려운 점이 있고, 어떤 일들을 하는 것을 모두에게 공개해야한다는 것이었다. 그래서 DM 보다는 전체 채팅방에서 공유해달라고 하는 것이었다.
물론 PM 입장에서는 모든 사람들이 어떤 일을 하고 있는지에 대해서 트래킹이 되어야 정상적으로 서비스 운영이 되겠지만, 나에게는 크게 와닿지 않았다.
하지만 내가 2시간 동안 끙끙 앓고 어려웠던 문제를 공개적으로 모든 팀원한테 물어보니 10분만에 해결된 경험을 통해서 나도 자연스럽게 모든 팀원에게 공유하는 습관을 들이려고 노력했다.
물론 일을 하는 도중에 흐름이 끊기는 일이 있어서는 안되겠지만, 그게 아니라면 팀 전체의 생산성을 높이는데 크게 도움이 되는 것처럼 보인다.
적용하고 싶은 개념
나중에 시간이 된다면 Slack과 같은 메신저에 자유로운 질의응답을 받을 수 있는 채널을 하나 만들고 싶다.
내가 해결하다가 어려웠던 것들은 다른 누군가에게도 어려울 것이다. 만약 같은 문제를 겪는다면 어떻게 해결했다는 것을 기억하는 것보다 기록을 찾는 것이 훨씬 빠를 것이기 때문이다.
추후에 어려웠던 점을 해결한 방법에 대해서 팀단위로 기술 블로그를 작성하기에도 좋은 것 같고!
결과적으로 처음에 얘기했던 버스 지수를 낮추는데 크게 도움이 될 것이다.
여담
지금 회사에서는 데일리스크럼을 통해서 서로 어려웠던 점, 공유하고 싶은 점을 따로 시간을 내서 공유하고 있는데, 이건 생각보다 비효율이 많은 것 같다.
내가 어떤 것들을 했고, 어떤 일을 할 것이다라는 것은 공유되기 좋은데, 다른 사람이 어떤 일을 하고 있다는 걸 굳이 알 필요가 없다고 생각이 든다.
그래서 공유할 안건들만 딱딱 공유하면 좋을 것 같다.
위에서 얘기했던 자신이 경험한 어려운 점과 해결 방법 정도를 서로 공유하는 시간으로 활용하면 어떨까?
