회사내 업무 처리를 위해 사용하고 있는 서비스들이 다 비슷하기 때문에 굳이 글로 남길 필요는 없었다. 다른 회사에서 사용하지 않는 도구를 쓰는 것도 아니고, 특정 도구를 더 깊이있게 사용해 본 것도 아니다. 그럼에도 이렇게 글로 남겨두는 것은 우리 회사에 지원하고자 하는 분들께 조금이라도 도움이 되는 정보를 제공하기 위함이고, 어떤 도구들을 어떤 이유로 채용하여 쓰는지 알게 되면 회사 문화를 파악할 수 있기 때문이다.
현재 우리 회사에서 사용하고 있는 서비스는 다음과 같다.
TrelloJira- Google Docs
- Bitbucket
- CircleCI
- Hangout Chat/Meet
이슈 트래커는 트렐로를 쓰고 있다. 관리해야될 프로젝트 수가 3개 미만이라면 충분히 사용하기 좋으나 그 이상에서는 사용 복잡도가 증가하는 경향이 있다. 이럴 때는 트렐로 보드를 여러개 만들어 사용할 수 있으나, 모든 프로젝트 현황을 타임라인에 맞춰 한눈에 볼 수 없다는 점이 아쉽다. 2019.04.25 현재 트렐로 사용은 중단하고 Jira 를 이슈트래커로 사용하고 있다. 동시에 다루는 프로젝트가 늘어나고, 배포 관리 등을 하다보니 트렐로로는 한계가 있다는 결론에 도달했다. 몇몇 이슈 트래커들을 비교해보고 빗버킷과 연동되는 점을 감안해서 일단 Jira 로 옮겨 탔다만 썩 만족스럽지는 않다.
문서 관리 는 구글 닥스로 한다. 여러 기능이나 지원 기기 측면, 거버넌스 등을 고려해보면 가장 좋은 도구 아닐까 싶다. 단점을 굳이 꼽자면 기본 프레젠테이션 템플릿이 별로 라는 점 정도다.
빗버킷은 풀리퀘스트 리뷰하기 위한 용도로 쓴다. 아틀라시안에서 만든 여러 개발 도구들이 있는데, 빗버킷만 쓰고 있다. 5인 이하에서만 무료다.
CI 시스템은 적은 인력으로 다양한 프로젝트를 수행해야 하는 우리 회사에겐 필수적인 시스템이다. 제품 개발과 관련된 자동화를 이루기 위한 토대다. 아래에서 다시 이야기하겠지만, 비동기적으로 일하게 되면 업무 처리를 즉각 처리하는 반사속도는 느려진다. 하지만 즉시성에서 잃어버린 생산성을 CI 시스템의 도움을 받아 결과적으로 더 높은 팀 생산성을 달성할 수 있다. 부분 최적화의 합이 전체 최적화에 부합되지 않는 것과 같다. 매 순간 즉각대응을 원칙으로 하고 살면, 어느 정도 생산성 향상은 이룰 수 있지만, 전체적인 측면에서 그것을 최적화라 부를 순 없을 것이다.
그 다음 가장 중요한 도구는 이메일이다. 이메일의 비동기성 덕분에 자기 시간을 본인의 결정하에 쓸 수 있게 된다. 앞 서 이야기했던 유연출퇴근제는 이 원칙 하에서 가능하다. 슬랙 도입에 대해서도 생각해 봤지만, 슬랙은 시간이 갈수록 다른 도구들을 내재화하는 성향이 있는 것 같다. 이메일, 이슈리포팅 등등이 모두 슬랙 안으로 빨려 들어간다. 나중에 기회가 있으면 자세히 써보도록 하겠다. 요약하자면 슬랙으로 커뮤니케이션 잘 한다고 해서 일 잘하는 사람은 아닐 수 있다. 하지만 이메일로 커뮤니케이션을 잘 하는 사람은 일도 잘하는 사람일 확률이 높다.
그렇다 하더라도, 이메일만 사용한 커뮤니케이션에 부족한 점이 있는 건 사실이다. 기록이 필요치 않고, 휘발성 대화를 빠르게 나눠야 하는 경우에 그렇다. 우리는 이런 경우에는 구글 행아웃 채팅을 사용하고 있다. 현재 주용도는 일일 미팅이다. 직접 한 자리에 모여서 하거나, 화상채팅 정도가 좋을거라 개인적으로 생각하지만, 팀원들의 여러 조건들을 감안하다보니 행아웃채팅으로 일일미팅을 진행하고 있다. 가끔 페어프로그래밍을 하는 경우도 있다. 이 때는 행아웃 미팅을 통해서 화면 공유를 하고 보이스챗으로 진행한다. 상황에 따라서 크롬 원격접속을 통해 함께 타이핑해가며 코딩하기도 한다.
이 정도가 매일 업무를 위해 우리가 사용하고 있는 서비스 들이다. 도구 도입에 있어 한가지 룰은 필요한 이유가 명확할 때만 도구 도입을 한다는 점이다. 도구들도 쉽게 유행을 타고, 다른 사람이 우리 회사는 이런 걸 사용해봤더니 좋았어요 라는 이야기를 들으면 괜히 도구 도입을 고민하는 경우가 있다. 아무리 좋은 도구라도 그 쓸모가 명확하지 않다면 빛좋은개살구 일 뿐이다. 반대로 도구를 도입하기로 결정하고 문제를 찾아다녀도 안된다. 망치를 손에 들면 무엇이든 못으로 보이게 마련이다.
도입 여부를 결정하기 전, 문제점을 직시하고 팀 전체에 공유한 다음, 근본원인을 파악한다. 그리고 현재 가지고 있는 방법으로 문제 해결을 시도해 보고 그 한계점등이 명확해지면 이 문제를 해결한 도구들을 검토한다. 여러 후보 중 가장 쉽게 도입할 수 있는 것, 우리 상황에 적절한 걸 선택하여 사용하게 된다. 도구 도입에 있어서도 시작은 아주 작게 꼭 필요한 부분만 이용한다. 도구는 사내 문화 등에도 변화를 요구하기 때문에 시작부터 도구도입으로 인한 변화가 크면, 그것은 실패할 가능성이 높다. 우선은 사용하는 사람들이 익숙해질때까지 꼭 필요한 기능만 반복해서 사용하는 게 좋다.
도구는 사용하기 위한 것이지 활용 가능성 여부로 다른 사람을 평가하거나 재단하기 위함이 아니라는 걸 명심해야 한다. 누구든 배우고 익히면 익숙해 질 수 있는 것이 도구라는 말이다.