[yoo/개발] 슬랙으로 사이드 프로젝트 관리하기 - 공지, 이슈 트래킹, 스크럼, 출석 관리까지 한 번에

안녕하세요, 벌써 세번째 글입니다. 이번에는 사이드 프로젝트를 진행하며 어떤 툴을 사용했는지, 특히 그 중 슬랙을 어떻게 활용했는지를 가볍게 적어보려고 합니다. 포스팅을 위해 오랜만에 슬랙을 뒤져보다보니 너무 아기시절의 우리가 어떻게든 해내려고 머리싸매고 고군분투했던 흔적들과, 그때의 광기어린 열정이 느껴져서 기분이 묘한 새벽입니다.

 

저희 팀은 슬랙, 피그마, 깃허브, 지라 등 다양한 협업 툴을 사용했는데, 그 중 슬랙은 화면 작업을 진행했던 피그마를 제외하고 저희가 가장 많이 사용했던 툴입니다. 진행상황을 정리하고 소통하는 모든 커뮤니케이션은 슬랙으로 이루어졌습니다. 이번 글에서는, 각 채널의 활용 방법에 대해 소개하겠습니다.

 

#dev

트리브의 세 개발자인 저(안드로이드/서버), 희희(iOS), 밍글(iOS)이 주로 사용한 채널입니다. 클라이언트 개발자끼리 공유할 내용이나, 서버 관련 내용등을 전달할때 사용했습니다.

 

개발 채널을 다른 채널들과 분리한 이유는 개발자끼리만 필요한 얘기를 하는 곳이기 때문에 다른 팀원들에게 잦은 알림으로 인한 피로도를 낮추기 위함도 있고, 개발에 쓰이는 토큰을 적어두기도 했기 때문에 최소한의 인원에게 노출 되도록 하기 위해서였습니다. 따라서 처음에는 개발자끼리만 쓰다가 이후에는 기획자인 도키까지 초대하여 개발 진행 상황을 파악할 수 있게 했습니다.

 

#error

개발자에게 오류 제보를 하기 위해 사용했던 채널입니다. 누구든 앱을 사용하다가 에러를 발견하면 기기 정보와 오류를 재현하는 방법등을 적고 수정 담당자를 태그합니다. 담당자가 수정 후 댓글을 달면 제보자가 확인 후 게시글을 삭제하는 순서입니다. 이런 방식으로 운영을 하다보면 삭제 되지 않은 쓰레드가 한눈에 들어와서 간단하게 이슈 트랙킹을 할 수 있습니다.

 

하지만 이 방법은 수정이 완료된 에러를 삭제해버리기 때문에 히스토리를 관리하기 어렵고, 기능명이나 중요도와 같은 태그를 달아서 이슈를 세부적으로 관리하기에 부족해서 나중에는 지라로 이동했습니다.

 

#issue

같이 논의하고 싶은 내용들을 모아두는 곳으로 제가 가장 좋아하는 채널입니다. #error 채널이 주로 개발 오류나 즉시 수정 가능한 제보를 올리는 곳이라면, 이 채널은 함께 얘기해보고 결정해야 하는 문제들이 주로 올라옵니다. 문구 수정이 필요하거나 UX 플로우가 어색한 이슈들이 주로 다뤄집니다. 글로 쓴 내용이 이해되지 않거나 논의가 길어질것 같다면 회의에서 한번 더 설명하고 해결했습니다.  

 

 

또, 개발을 하기 전 완벽한 기획서와 디자인 가이드가 나오는 방식이 아니었기 때문에, 개발 과정 중에 궁금한 점이 생기면 즉시 질문을 하곤 했습니다. 주로 '만약에 이런 상황에서는 어떻게 하지?'와 같은 질문들이 많았고, 이로 인해 다양한 경우의 수를 고려하는 연습을 할 수 있었습니다. 이렇게 생긴 습관은 현업에서 일을 하는 지금도 세부 사항을 신경 쓰는데 큰 영향을 미치고 있습니다.

 

 

이 쓰레드는 트리브의 알림 기능에 관한 것입니다. 기획자가 각 경우별 메시지를 정해주고, maxLine = 1로 설정하여 문구가 한 줄을 넘어가지 않도록 설정했습니다. 하지만 개발을 진행하면서 문구가 종종 의도하지 않은 부분에서 잘리는 것을 알게되었습니다.

 

또한, "알찬 여행을 위해 미리 일정을 짜보는 건 어떨까"를 누르면 "알찬 여행을 위해 미리 일정을 짜보는 건 어떨까요?"와 같이 전체 문장을 확인할 수 있는게 아니라 일정 짜는 화면으로 연결되기 때문에, 메시지가 잘리면 유저는 전체 내용을 절대 확인할 수 없다는 문제점이 있었습니다.

 

이 문제를 기획자인 몬몬에게 문의한 결과, 꼭 메시지가 한 줄일 필요는 없다고 판단하여 디자이너인 가르디에게 한 줄을 넘어갈 경우의 레이아웃을 요청했습니다. 그 후 최종적으로 변경된 디자인을 개발에 반영하여 문제를 해결했습니다.

 

하지만 항상 복잡한 얘기만 나눈건 아니고, 아래와 같이 서로에게 가벼운 요청을 하거나 리마인드를 할때도 사용했습니다. 

 

#notice

공지사항이 올라오는 채널입니다. 작성하는 사람을 따로 정해두지는 않고 모두가 기억해야하는 일이 있으면 정리해서 적어두었습니다.

 

모두가 확인해야하는 내용, 자주 찾는 문서의 링크, 도움이 필요한 요청들이 주로 올라왔습니다.

 

#progress

트리브는 회사처럼 모여서 같은 시간에 작업을 하는게 아니었기 때문에 각자의 작업 시간이 달랐습니다. 이런 상황에서 서로의 작업 진행 상황을 공유하기 위해, #progress 채널은 셀프 스크럼 형식으로 운영되었습니다. 

 

매일 올려야 하는 것은 아니고 무언가를 한 날만 올리면 됩니다. 주로 오늘 해낸 작업을 자랑겸으로 적어두는 것이며, 나의 진행 상황을 공유하여 다음 차례의 사람이 스케줄을 조정할 수 있도록 배려하는 용도로 사용되었습니다.

 

재밌는 것은 취업 이후 게시글을 올린 시간이 대부분 새벽이라는 점입니다. 아무래도 퇴근 후 작업을 시작하다 보니 자연스럽게 그렇게 될 수 밖에 없었습니다. 릴리즈 직전에는 팀원들이 하루의 마무리를 하는 시간이 점점 동기화되기도 했습니다.

 

 

다른 채널들중 가장 작성하는 형식이 정해진 채널이라는 느낌도 있지만 항상 그렇게만 적는것은 아닙니다. 원래의 목적인 '지금 하고있는것을 공유하는것'에만 맞다면 실컷 자랑을 하기도, 어렵다고 징징대기도, 쓰고싶은 짤을 쓰기도했습니다.

 

#random

여긴 정말 아무말이나 하는 공간입니다! 팀에 함께 하게됐을때 첫 인사를 나누기도 하고, 카카오톡이 터졌을때 소식도 올리고 그냥 놀리기도 했습니다.

 

#고민거리

여기부터 채널명이 한글인 이유는 영어로 마땅한 단어를 찾지 못했기 때문입니다. 고민거리 채널에서는 말 그래도 고민거리를 올립니다. 물론 개인적인 고민을 올리는건 아니고 아니고 작업을 하며 들었던 생각을 올리는데 #issue 채널과의 차이점은 당장 해결할 필요는 없다는 점입니다. 일단 함께 논의해보고 개선하면 좋을 것들을 적어두고, 적당한 시점에 반영할 수 있는 내용들이라는 점에서 결이 조금 다릅니다.

가장 대표적인 고민으로는 사진을 받는 방식이 있었습니다. 트리브는 여행을 가는 유저들이 사용하는 앱이기 때문에 장소에 대한 정보가 꼭 필요합니다. 그래서 어디서 장소별 사진을 불러올지에 대한 고민이 많았습니다. 하지만 국내 모든 장소의 사진을 직접 모으는 것은 현실적으로 불가능하고, 유저에게 업로드하게 하기에는 트래픽을 감당하기 어렵기 때문에 다른 방법을 찾아야 했습니다.

 

현식적으로 선택 할 수 있는 방법은 이미지 api를 사용하는것이었는데, 검색어를 통해서 사진을 불러오는 원리이기 때문에 가게이름이 고유하지 않은 경우 특이한 사진이 뜨기도 했습니다. 그래서 고민거리 채널에 여러 테스트 결과를 올렸고, 함께 논의 후 검색 키워드를 상황에 맞게 분기해서 쓰는 방법으로 결정했습니다.

 

회의에서 직접 논의할 수도 있었겠지만, 슬랙에 미리 고민거리를 올림으로써 팀원들이 충분한 시간을 갖고 생각해볼 수 있었고, 쓰레드를 통해 다양한 시도를 해본 후 결론을 도출할 수 있었습니다. 새 코드를 적용하고 나서도 100% 만족스러운 결과는 아니었지만 한정된 자원과 기존의 쿼리에 비해 제법 성능을 개선할 수 있었습니다.

 

#근태

팀 인원이 3~4명일 때는 '다음 주는 회의 언제 할까?' 하며 모두 가능한 시간을 매번 잡는 방식이었는데 인원이 많아지면서 고정된 회의 시간이 생겼습니다. 매주 같은 요일, 같은 시간에 회의가 정해지니, 자연스럽게 그 시간에 다른 일정을 잡지 않는 식으로 운영되었습니다. 불가피하게 참석하지 못하는 경우에는 저에게 카톡으로 알려주었고, 저는 '오늘 누구는 못 온대' 하고 모두에게 알리는 식이었습니다.

 

하지만 슬랙으로 출석 관리를 하게 되면서 모두에게 미리 공유가 되니 회의 전에 물어볼 것들을 정리하고 일정 조율을 하는 것이 편해졌습니다. 

 

이 채널에 글을 남길 때는 보통 빠지는 회의 날짜와 불참 사유를 적습니다. 저번 글에 썼듯이, 회의를 몇 번까지 빠질 수 있다는 규칙은 없으니 자유롭게 하되 최대한 알아서 잘하는 느낌으로 운영됐습니다. 

 

 

#회의록

저희 팀은 회의에서 매주 진행한 내용을 공유하고, 서로의 의견이 필요한 부분에 대해 논의한 만큼 회의록 작성이 아주 중요한 일이었습니다. 회의록 작성의 목적은 다음주까지 할일 적기(안해온사람 잡아내려고), 나중에 찾아볼 수 있게 오늘 고민했던것 적어두기 입니다. 효율적인 방법을 찾기 위해서 돌아가면서 작성해보기도 하고, 제일 늦게 들어오는 사람이 쓰기도 하고, 나름 팀을 나눠서 작성을 해보는등 많은 시도를 해봤습니다. 하지만 다양한 시도를 해봤음에도 불구하고 슬랙에서 사용했던 채널중 유일하게 회의록 채널은 결국 지라로 옮기게 됐는데요, 그 이유는 아래와 같습니다.

 

• 같이 편집할 수 없다

회의는 너무 길어지는 것을 방지하기 위해 미리 논의하고 싶은 내용을 요약해서 회의록에 적어오는 방식으로 운영이 됐습니다. 그러면 안건을 가져온 사람은 하고 싶은 말을 적으며 한 번 정리할 수 있는 기회가 되고, 나머지 팀원들은 적혀있는 안건에 대해 미리 고민해 보고 회의에 참석을 할 수 있어서 조금 더 효율적인 회의가 가능하기 때문입니다. 따라서 모두가 회의록에 편집 권한이 있어야했는데, 슬랙은 작성자만 수정이 가능하다는점이 아쉬웠습니다.

 

• 사진이나 파일을 첨부하면 원하는 위치에 삽입되지 않고 하단에 몰린다.

디자인 논의사항과 같이 이미지로 설명하면 빠르게 이해가 가능한 부분을 회의록에 첨부하는 경우가 많았는데, 슬랙은 모든 파일이 하단에 몰리게 됩니다. 그렇게 되면 이미지와 설명을 매치하기가 어려워지고 한눈에 들어오지 않습니다. 

 

• 글이 길어지면 가독성이 떨어진다

위와 비슷한 이유인데, 회의에서 논의한 사항을 자세히 기록하다보면 글이 길어져서 가독성이 떨어지는 문제가 있습니다. 슬랙은 볼드처리, 이탈릭처리, 코드블럭 처리 등 제한된 포맷팅만 가능하기 때문에 나중에 다시 찾아보려할때 읽히지 않는다는 문제가 제일 컸습니다. 

 

슬랙 활용 소개는 여기까지입니다. 이전 글들에 비해 조금 가볍게 적어봤습니다. 사이드 프로젝트를 진행하며 사용할 수 있는 다양한 협업 툴이 많지만, 필요 목적에 따라 채널을 다르게 운영하면 슬랙 하나로도 충분히 필요한 기능들을 관리 할 수 있어서 만족스러웠습니다. 

 

제가 소개할 다음 글은 타니의 공지 사항 UX 개선하다가 팀 노션을 만들었다는데요? 입니다. 이 글은 노션을 도입하게 된 이유와 노션을 활용해 트리브의 소개페이지를 어떻게 개선해 나갔는지의 과정을 담고 있습니다. 특히, 저희 팀만의 협업 방식과 문화에 대한 고민이 드러난 부분이 있어서 추천합니다.