개발팀 공유 문화 일구기(공동작업시간)
알고케어 개발팀 공유 문화 만들기
※ 글쓴이: Noah / 편집: Alto
왜 주기적으로 공유해야 할까?
세상을 혼자 사는 게 아니듯, 어떠한 조직에서 일을 할 때 혼자서 모든 걸 할 수 없다. 또한 모두가 각자 알아서 자신의 할 일을 척척 해낸다는 것은 매우 어려운 일이다.
개발을 하다 애를 먹거나 모르는 부분이 생기면 동료에게 도움을 청해야 하기도 하고, 중요한 공유 사항이 수시로 생기기도 하며 여럿이서 함께 토론을 하여 의사 결정을 해야 하는 일도 부지기수다.
이런 것들을 자주 공유하며 의견을 주고받는다면, 서로 더 빠르게 성장할 수 있고, 조직 내에 어떤 일이 벌어지고 있는지 모두가 알 수 있으며, 모두의 의견을 합치기에도 좋다.
하지만 아무런 합의나 맥락 없이 공유하기란 어려운 일이다. 상대방이 너무 바빠 보여서 망설이게 될 수도 있고, 하려던 말이 별거 아니란 생각이 들어 공유하지 않고 넘어가는 경우도 있을 수 있다.
그래서 우리는 초기부터 개발팀의 공유 문화를 만들기 위해서 노력해왔다.
공유하는 문화 만들기
내가 입사한 지 3개월째 되던 2020년 12월 즈음은 개발팀 내부에서 시시때때로 크고 작은 미팅이 이뤄지고 있었고, 불규칙적인 미팅 시간으로 인해 불편함을 느꼈다. 한창 집중하고 있을 때 업무 흐름이 끊기는 일이 빈번하게 일어났다. 서로 다른 업무 타임라인 안에서 생각날 때마다 체계 없이 회의를 하게 되니 모두의 업무 생산성이 낮아지는 결과를 낳았다.
지금은 구글에 계신 당시의 동료 개발자 분께서 이런 점을 해결하기 위해 시간을 정해두고 주기적으로 서로 궁금한 점, 공유 사항 등을 공유하자는 의견을 내주셨다. 개발팀이 같이 모여 의견을 빠르고 서슴없이 나누고, 능률을 높이자는 취지였다.
그리고 모두가 만장일치로 동의하여 공동 개발 시간, 혹은 “공동 작업 시간”이 만들어지게 되었다.
조직과 상황에 맞춰 문화 개선하기
� 매일매일 정해진 시간에 공유하기
처음에는 매일매일, 오후 4시 30분부터 오후 5시 30분까지 의견을 공유하며 함께 일하는 시간을 가지기로 했다. 당시 개발팀의 인원 구성이 시니어 백엔드 개발자 한 분과 주니어 프론트엔드 개발자 세 분이었기 때문에 모두가 모여 공유하는 시간에 ‘이런 이슈가 있는데 어떤 방식으로 해결하면 좋을까요?’ 라거나 ‘Git 을 더 잘 활용하는 방법을 고민해보고 싶어요’ 와 같이 많은 질문과 의견이 오갔고, 디자이너 한 분이 새로 합류하며 디자인과 관련된 의견도 주고받는 등 목적에 맞게 활용되었다.
공유할 것을 다 공유한 뒤에는 남은 시간 동안 같이 모여있으면서 자신의 일을 하고, 종료 시간이 되면 다시 사무실 자기 자리로 돌아갔다. 반응은 생각보다 더 좋았다. 서로 개발 영역이 다르더라도 따로 일하는 게 아니라 기술적인 고민들도 같이 털어놓다 보니까 토론하고 성장하는 느낌을 많이 받을 수 있었다. 업무적으로도 자연스럽게 프로젝트 현황을 알게 되니까 도움이 됐다.
하지만 이렇게 공유하는 시간을 매일 가지니, 초반에는 잘 활용되었지만 점점 단점이 나타나기 시작했다.
많은 것들을 결정하고 나니 막상 모여도 공유할 거리가 딱히 없었다.
혼자 앉아서 일하는 것이 더 집중이 잘 되는 인원도 있다.
미팅룸을 일정하게 잡기 힘들었다.
아무래도 너무 잦은 주기가 문제라고 생각해서 적절한 주기를 찾아 나서기로 했다.
�주 3회 정해진 시간에 공유하기
주 3회. 월요일, 수요일, 금요일날 기존과 같이 오후 4시 30분 ~ 5시 30분에 공유하는 시간을 갖기로 했다. 그리고 이 문화 혹은 미팅의 이름도 정했다. 공동작업시간(이하 공작시). 회사 내의 다른 팀원들도 알 수 있도록 캘린더에 월수금 4시 30분을 공동작업시간으로 올려두고, 기존처럼 모여서 질문이나 공유사항, 의견 공유, 의사 결정 등을 하였다.
*전사회의 때 개발팀의 공작시 문화를 공표하고 공용 캘린더에 등록했다. 우리 팀에서 작게 시작했던 문화가 알고케어 개발팀의 문화로 인정받는 순간이었다. 지금까지도 다른 팀들이 개발팀의 공작시 문화에 참관하고 벤치마킹한다.
시간이 4시 30분부터 5시 30분 인 것은 모두가 출근하여 일하고 있을 시간 중 하나이기 때문이다. 알고케어는 유연 근무제를 시행 중인데, 8시부터 10시 사이에 출근하여 점심시간 제외 8시간 근무 후 퇴근하는 제도였고, 모두가 모여있을 만한 코어 타임에 공동작업시간을 진행하는 게 좋을 것이란 판단이었다.
이 즈음 공작시뿐만 아니라 2주 간격으로 스프린트를 진행하는 업무 프로세스가 정착되었다. 새로 합류하신 시니어 개발자분의 주도로 스크럼 보드를 관리하고, 2주에 한 번씩 PMI 회고 (Plus - Minus - Interest) 를 진행했다. 삼성에서 개발자이자 애자일 코치로 15년 넘게 근무하신 분이었는데, 이전까지의 투박한 스프린트 방식이 정교해지는 계기가 되었다.
다만, 이로 인해 조그마한 문제가 생겼다. 스프린트의 2주는 첫 시작 때 ‘스프린트 플래닝’시간과 마지막 날 ‘스프린트 회고’ 시간을 갖는다. 때문에 보통 금요일에 진행되는 스프린트 회고 시간으로 인해 공동작업시간 중 하루를 스프린트 회고로 대체해야 했다. 또한 금요일에 공작시 하고 주말이 지나 월요일에 다시 공작시를 진행하면 별로 공유할 게 없는 상황이라는 의견이 나왔다.
그래서 이번에는 공동작업시간을 진행하는 요일을 변경해보기로 했다.
� 매주 정해진 시간에 공유하기
더 이상 무작정 주 3회 공동작업시간을 진행하지 않는다. 스프린트 회고를 피하여 첫째 주는 월수금, 둘째 주는 화 목에, 시간은 동일하게 진행하기로 하였다. 이렇게 변경된 후로는 둘째 주 금요일에 진행하는 스프린트 회고와 겹치지 않고, 금요일 - 월요일 연속으로 공동작업시간을 진행하여 낭비되는 시간도 없어졌다.
그리고 회사에 새로운 문화와 미팅들이 도입되며 공작시도 점점 더 제대로 된 모습을 갖춰가게 되었다. 각 팀의 리드들끼리 팀 단위에서 빠르게 논의할 아젠다들을 해결하는 ‘리드 미팅’ 이후, 리드 미팅 내용을 공작시 때 공유해서 싱크를 맞추게 되었고, BE와 FE가 서로 이슈를 공유하거나 특정 태스크에 대해 토론을 하기도 했으며 회사의 신규입사자분과 개발팀의 밋업도 공동작업시간에 진행하였다.
하지만 공동작업시간은 매번 정해진 날, 정해진 시간에 동일한 인원이 진행하여서 ‘회의록’을 따로 적지 않고 있었는데, 공유 내용이 많아지고, 그 내용의 중요도가 높아지면서 회의록의 필요성을 느끼는 인원이 많아졌다. 나 역시 개인적으로 공작시 내용을 노션에 정리를 하며 진행하고 있었다.
그리하여 팀에서 이제 회의록을 작성하자는 의견이 나왔고, 이 역시 받아들여졌다.
어떤 이야기들을 하는가?
주로 하는 것들은 중간관리자, 즉 리드들의 미팅인 리드미팅에서 나온 안건들 중 공유해야 할 것들을 공유하고, 의견을 주고받는다. 그리고 개발을 하다가 모르는 점이나 궁금한 점을 이해관계자에게 질문하거나, 팀 내에서 함께 고민을 하기도 한다. 개발 문화나 업무 방법론에 대해 피드백하고 개선하기 위한 고민도 함께 하며, 소개하고 싶은 기술이나 문화를 공유하기도 한다.
지금 당장 바로 생각나는 것은 [공작톡] 이란 문화와 브랜치 활용 전략인데, 공작톡은 팀 내의 FE개발자들 끼리 개발 관련하여 이런저런 것들을 주제로 자주 의견을 주고받고, 성장하고 싶은 욕구가 강하다 보니 공작시에서 의견을 주고받는 경우가 많았다. 이런 점을 조금이나마 해소하기 위해 도입된 문화다. 나중에 개별 포스트로 정리해 보려 한다.
[브랜치 활용 전략] 은 개발팀 내에서 BE와 FE가 아직 획일화되지 않은 규칙으로 브랜치를 활용하고 있었기 때문에 하나의 통일된 브랜치 전략을 사용하면 좋겠다고 생각하여 공작시에서 토론했던 기억이 있다. 관련 내용은 사내 개발팀 위키에 정리하여 공유하였다.
더 체계적으로, 더 효과적으로
정리하자면, 현재 내가 속한 개발팀의 공동작업시간은 다음과 같이 진행된다.
일시 : 스프린트 첫째 주 월수금, 둘째 주 화목 4시 30분 ~ 5시 30분
안건 : 리드미팅 내용 공유, 각자 현황 공유, 의견 공유, 의사 결정이 필요한 부분 논의.
참여 인원 : 개발팀 전원 (경우에 따라 안건의 이해관계자)
사실 나는 항상 변화를 주도하지는 않았다. 초반에는 주 3회보다 매일 하는 게 좋을 것 같다는 의견이었고, 월수금 - 화목으로 바뀔 때도 결국 공작시 자체는 2주 중 하루가 줄어드니 탐탁지 않았다. 그렇다고 그 의견들에 무작정 반대하지는 않았다. 일단 새로운 의견대로 변경하여 진행하여 보고, 효과가 별로 좋지 않다면 다시 되돌아가자는 의견이었다. 내가 거의 유일하게 바로 동의한 것은 회의록을 작성하자는 의견이었다. 묘하게도 이 시기와 내가 중요도가 어떠한 미팅이든 회의록을 적어야 한다고 생각하기 시작한 시기가 겹쳤던 것이 그 이유라고 생각된다.
이렇게 공동작업시간, 줄여서 공작시 라는 문화의 도입부터 개선시켜나가는 과정을 모두 함께 하며 ‘모든 조직과 모든 환경에 항상 정답이 되는 문화와 제도는 없다.’ 라는 생각을 하게 되었다.
내가 속한 회사와 조직은 초기 스타트업으로 굉장히 빠르게 조직이 변화되기도 하고, 처한 환경 역시 시시때때로 바뀐다. 그 과정에서 기존의 문화를 조직과 환경에 맞게 개선해나가지 않는다면 결국 의도는 좋았으나 성공적으로 유지하지 못한 문화가 될 뿐이다. 개발할 때도 그렇듯이 정답은 없는 것 같다. 더 효과적이고 정답에 가까워지기 위해 언제나 노력해야 한다.
※ 원문 : https://wdever.dev/development-team-culture-of-regular-sharing/
