좋은 개발 문화를 위한 노력 - 스탠드업

시드 라운드 직후에 입사해서 시리즈 B가 마무리 된 지금, 저희 개발팀은 1명(본인)에서 10명까지 늘어났습니다. 회사 성장 과정에서 좋은 개발문화를 만들기위해 같이 노력했던 경험을 나누고자 합니다. 입사 초반에는 CS 팀이 만들어지기 전이어서, 직접 클라이언트를 만나서 피드백을 받고, 반영하는 식으로 개발했습니다. 피드백도 혼자 받고, 개발도 혼자하니 동료들과 협의할 필요가 없었습니다. 피드백을 반영하는 feature의 기획은 모두 제 머리속에서 이루어졌기 때문에, 문서화에 시간을 할애하지 않고(문서화도 나중에 진행했습니다), 우선순위대로 빠르게 개발하고 배포하는 사이클을 매주 반복했습니다. 그러다 3개월 뒤에 개발자 한 분이 합류했습니다. 파이썬을 위주로 개발하시던 분이었는데, 다행히(?) 저희는 파이썬으로 서버와 클라이언트를 모두 만들고 있었기 때문에, 풀스택으로 바로 투입됐습니다. 그러면서 자연스럽게 "업무분장"을 해야했습니다. 혼자 하던 일을 나누기 시작했고, 둘이서 개발할 때 까지는 괜찮았지만, 팀 규모가 점점 커지면서 담당 업무를 "기록"하지 않으면 같은 기능을 동시에 개발하는 불상사가 발생할 수도 있었습니다. 그래서 스탠드업을 도입하기로 했습니다. 스탠드업 미팅은 영어 그대로 하면 stand-up meeting인데, 일어서서 하는 회의이기 때문에 다리 아프기 전에 빠르게 끝난다는 장점이 있습니다. 주요 내용은 1. 나는 어제 A를 작업했고, 2. 오늘은 B를 할 예정인데 3. 내가 B를 하려면 누군가 C를 먼저 해줘야한다. 입니다. 자연스럽게 어떤 feature가 마무리 됐고, 누가 어떤 feature를 작업할 예정인지를 알 수 있습니다. 그리고 업무 내용을 공유하면서 내가 B를 하기위해 C를 처리해줄 가장 적합한 사람이 누군지도 파악할 수 있습니다. 덕분에 개발자들 끼리 소통하기도 수월해졌습니다. 스탠드업도 다양한 방식을 시도했는데요, 사무실로 출근할 때는 다같이 모여서 했지만, 재택근무를 시작하고서는 새로운 방식을 찾아야 했습니다. 처음에는 zoom에서 모였습니다. 당일 업무 내용 확인은 됐지만, 전원 재택근무를 시작하고도 개발자가 충원되면서 점차 기록의 필요성을 느꼈습니다. zoom으로 하더라도 기록은 할 수 있었을텐데 왜 그런 생각은 못했을까요... 글로 남기자는 생각에 슬랙에 있는 workflow를 사용했습니다. 10:30에 workflow가 스탠드업 내용을 올려주면, thread에 댓글을 다는 식으로 진행했습니다. 필요 시 업무 중에 zoom으로 이야기 하는 시간을 가졌는데요, 재택근무 중 슬랙으로만 업무 내용을 나누다 보니 "혼자 일하는 것 같다"는 느낌을 받는다는 피드백이 있었습니다. 그래서 다시 zoom으로 스탠드업을 진행하기로 했습니다. 기록의 필요성이 있으니 스탠드업 내용을 노션에 기록했습니다. 10:30에 울리던 workflow는 시간을 10:15로 변경하고, 15분뒤에 스탠드업을 시작한다는 알림으로 대체했습니다. 이제 기획팀이 만들어져서 위의 3가지 질문에 4. 기획팀에 전달/질문 사항 까지 나누고 있습니다. 그리고 요즘엔 링크를 생성해서 전송하는 zoom 대신 슬랙의 허들을 사용하고 있습니다. 저희는 이런 방식으로 스탠드업을 진행하고 있습니다! 자료를 찾던 중 스탠드업을 효율적으로 할 수 있는 방법이라는 글이 있어 공유 드립니다. 이 글을 읽고, 저희가 스탠드업을 개선할 수 있는 방안을 댓글에 남겨주시면 저희가 좋은 개발 문화를 만드는데 도움이 될 것 같습니다. 다음 포스트는 코드리뷰에 대해 작성할 예정입니다.