얼마 전 한 HR 컨퍼런스에서 인상적인 내용을 들었다. ‘스타트업 채용 시장에서는 개발자와 비개발자로 구분된다’는 얘기였다. 그 외 직군의 중요도를 낮게 평가하는 것이 아니라 이직에 대한 개발직의 특수성이 반영된 내용으로, 타 직군 대비 이직 활동에 대한 적극성이 현저히 낮고, 개인 업무 환경 및 팀 핏에 대한 중요도가 특히 높더라는 설명이었다.
과연 그들은 어떻게 일하는 사람들일까. 개인자산관리(PFM) 서비스 브로콜리에서 개발유닛을 이끌고 있는 최재필 CTO의 이야기를 들어봤다.
최재필 브로콜리 CTO
팀 운영에 있어 가장 중요하게 생각하는 것은?
대원칙은 “신뢰 기반의 자율과 시스템 기반의 효율” 이 한마디로 설명할 수 있을 것 같다. 열 가지 정도의 업무 원칙을 내부적으로 갖고 있는데, 모두 이를 뒷받침하는 내용이다. 경력 있는 개발자라면 대부분 공감할 것들인데, 단순 개발업무를 할 때 뿐 아니라 함께 커뮤니케이션을 할 때, 업무 관리를 할 때, 회의를 할 때 등 일상 대부분에 적용될 수 있는 내용이다.
커뮤니케이션부터 이야기해보자. 개발자가 선호하는 커뮤니케이션 방식은 무엇인가?
개발자들은 개발 모드에서 비개발 모드로의 전환비용이 꽤 큰 편이다. 자는 사람을 깨우는 것과 같다는 극단적인 표현을 쓰기도 하다. 결국 각자의 몰입을 최대한 깨지 않는 상태에서 충분한 커뮤니케이션이 되도록 하기 위해 우리는 여러 툴들을 도입하고 그 우선순위를 정했다. 시스템 기반의 커뮤니케이션인 셈이다.
문서나 시스템을 기반으로 커뮤니케이션하면 업무 효율을 생각하는 것보다 훨씬 크게 높일 수 있다. 흔히 메일로 커뮤니케이션 하면 ‘어디에 어떤 문서의 어떤 부분에 대한 무슨 질문이 있다’는 식의 부가 설명에 많은 시간을 할애하지 않나. 그런데 트렐로나 구글 독스의 댓글 기능을 활용하면 이 시간을 현저히 줄일 수 있다. 논의가 필요한 위치에서 즉각적으로 의견을 교환하고 처리여부를 표기할 수 있기 때문이다. 현재 브로콜리는 트렐로 및 지라, 구글 독스를 0순위로 두고 있고, 슬랙과 메일을 그 다음, 대면을 마지막 순위로 두고 있고, 이는 타팀과의 협업 프로세스에도 동일하게 적용된다.
브로콜리 혁신개발 유닛 운영 시트 캡처
많은 협업 툴이 있는데, 그 활용법을 소개한다면? 예를 들어, 슬랙을 카카오톡 대체 용도로 활용하는 건 크게 유의미하지 않을 것 같다.
무엇을 쓰는지도 중요하지만 어떻게 쓰느냐가 더 중요한 문제다.
트렐로부터 말해보자. 트렐로는 개인 업무 관리에도 큰 도움이 되지만, 더 큰 목적은 협업에 있다. 각자가 자신의 업무 상황만 잘 업데이트 해두기만 하면, 내 동료가 나의 업무 상황을 알아야 할 때, 아무런 불편함없이 빠르게 파악할 수 있기 때문이다. 의견 교류도 즉각적으로 할 수 있고.
따라서 트렐로를 활용할 때는 카드 맨 상단 한 줄 설명의 가독성을 높이는 것과 카드의 생성 및 이동 기능을 적극적으로 활용하는 것이 무척 중요하다. 카드를 To-do에 넣는 순간 ‘나, 이 일을 언제까지 완료할 거야’, 이게 Doing으로 가는 순간, ‘나, 이 일을 하고 있어’, Reviewing에 던지면 ‘누군가 리뷰해줘’라는 메시지를 전하는 일이니까. 또 이를 접근성이 더 높은 슬랙에 연동해두면 이슈 등록 등의 업데이트 사항을 놓치지 않을 수 있다.
지라의 경우 전체 이슈 상황에 대해 누구나 매니저의 뷰로 볼 수 있게끔 대시보드를 구축해뒀다. 해결이슈가 몇 개 남았고, 누가 뭘 해결해야 하고 하는 등의 통계를 누군가 매번 내야 하는 작업들을 최소화하기 위함이다.
결국 툴 활용에 있어 1)툴 도입의 목적 및 기능에 대한 이해, 2)툴 간 유기성 확보, 3)최대한 자동화, 이 세 가지를 중요한 요소로 보고 있고, 이런 게 우리가 지향하는 시스템 기반의 커뮤니케이션 방식을 강화 시켜준다고 생각한다.
브로콜리 개발 업무 도구 목록
개발에 대한 이야기로 이어보자. 개발 업무에 있어 가장 중요하게 생각하는 거라면?
리뷰다. 프로덕트 품질을 높이는 가장 좋은 방법이라고 생각하기 때문이다.
이 리뷰를 개발팀 내에서 효율적으로 진행되게끔 하려면 변경된 코드가 너무 많아서는 안된다. 많아도 몇 십 줄이다. 그래서 ‘작게’와 ‘자주’가 무척 중요한 표현이다.
코드 수정 비용은 개발자의 손에서 떠나는 순간부터 기하급수적으로 커진다. 개발팀 동료가 한 시간 동안 리뷰해서 한 줄을 고치면 됐을 일이 QA나 전사 테스트로 넘어가 버리면 수십 배의 손실이다. 그래서 리뷰가 중요하다는 거고, 이게 효율적으로 진행되기 위해서는 PR(pull request·PR, 수정 제안)이 작아야 한다.
또 PR전 단위 테스트를 반드시 거치도록 하고 있는데, 이 부분은 젠킨스(CI(Continuous Integration, 지속적 통합)&CD(Continuous Delivery, 지속적 제공) 도구)를 활용해 최대한 자동화하고 커버리지를 높여 가는 게 목표다. 웬만한 수준의 퀄리티는 사람 손을 타지 않고도 검증되도록 하는 거다.
팀 회의는 어떤 식으로 진행하나?
현재 주간, 월간으로 전체 회고시간을 가지고 있다. 흔히 조직에서 전체회의를 하면, 각자 이번에 무슨 일 했고, 다음에 무슨 일 할지, 일정이 어떻게 되는 지 등을 이야기하는데, 우리는 오로지 회고에 집중한다. 업무 상 이야기는 일상에서 필요할 때 필요한 사람들이 그때그때 해야 하지, 이걸 일주일 혹은 한 달 동안 미뤄두면 안된다고 생각하기 때문이다. 실제로 내부에서는 업무 관련 이슈가 트렐로로 상시 공유되고 있어서, 이렇게 진행하는 게 훨씬 효과적인 것 같다.
회고에는 기록을 위해 저만 노트북을 들고 들어가고, 다른 분들은 다들 최대한 가벼운 마음으로 오실 수 있게 한다. 최대한 핸드폰을 보지 않기로 약속하고 이 시간만큼은 서로에게 집중하는 시간으로 만들고 있다. 정말 편한 마음으로 자신의 한 주를 돌아보고, 다음주는 어떠했으면 좋겠는지 이야기한다. 영화를 봤다거나, 컨디션 관리가 아쉬웠다와 같이 업무와 직접 연관이 없는 것도 좋다. 다만 이런 충분한 대화 사이사이에서 개선점들을 찾게 될 때가 있는데, 그걸 놓치지 않으려고 한다.
월간으로 진행하는 시간은 조금 더 진지함을 갖춰서, 프로세스 개선에 많이 집중하고 있다. 다가오는 회고부터는 지난 회고에서 나온 의견을 바탕으로 방식도 조금 바꿔보려고 한다. 첫 10분 간 각자 지난 시간 동안 힘들었던 것, 좋았던 것, 바뀌었으면 하는 것에 대해 쓰고 이를 함께 논의하는 거다.
이렇듯 정기적인 회의 방식을 개선한 것뿐 아니라, 유닛 서재를 만든다거나, 기획-개발 간, 개발-QA-CS 업무 프로세스들을 개선한다거나 하는 것들도 회고를 통해 나온 의견이었다.
회의에 대한 우리의 생각은, 단순히 이슈를 공유하는 게 아니라, 어제를 돌아보고 크든 작든 개선포인트를 찾아 내일은 조금이라도 더 진화한 팀이 될 수 있게 해야 한다는 거다. 회의 시간 역시 팀의 성장을 위해 다뤄져야 하니까.
팀 리더로서 자신의 역할을 어떻게 정의하고 있나?
리더로서와 매니저로서의 역할은 다르다고 생각한다. 매니지먼트는 이 두 역할을 모두 해야 한다고 보고. 리더가 최적의 의사결정을 하는 역할이라면, 매니저는 팀원이 끼와 재능을 충분히 발휘할 수 있도록, 업무 외에는 신경 쓰지 않을 수 있도록 해주는 역할이다. 비유하자면 연예인 매니저와 같은 느낌이겠다. 시간이 지나면 해외처럼 역할이 나눠질 수도 있겠지만, 현재 기준으로는 대부분의 시간을 매니저 모드로, 의사결정이 필요할 때 리더의 모드로 지내야 한다고 스스로 생각하고 있다.
이렇게 역할을 정의하니 조직 내 익숙했던 여러 절차에 의문을 던지게 되더라. 휴가 승인 절차를 예로 들어보자. 매니저가 왜 구성원의 휴가 여부를 승인해야 할까? 가장 큰 영향을 받는 사람은 내 동료인데 말이다. 매니저는 여부를 알기만 하면 되지 승인을 할 필요는 사실 없었던 거다.
실제로도 이게 효율적인 게, 어차피 매니저가 휴가를 승인하려면 그가 없을 때를 고려해 동료들의 상황을 확인해야 한다. 매니저 입장에서도 업무에 영향을 받는 동료들이 승인한 것을 확인하는 게 훨씬 효율적인 셈이다. 이런 작은 절차 하나, 의사결정 하나에서 리더십의 차이가 만들어지는 게 아닐까 생각한다. 브로콜리가 계속해서 중요한 것에 집중할 수 있도록 계속 고민해야 할 부분이다.
마지막으로 하고 싶은 말이 있다면?
비효율적인 팀이 만드는 제품이 효율적일 수 있을까. 제품은 팀을 반영한다고 생각한다. 극단적으로 표현하면 팀 또한 제품의 일부라 볼 수 있기 때문이다.
좋은 팀이 되기 위한 요소에 대해서는 세상에 정말 많은 이야기들이 있다. 우리는 그 중 “신뢰 기반의 자율, 자동화 기반의 효율”을 우리의 방향으로 찍은 거다. 이 곳을 향해 우리가 다 같이 한 발이라도 더 가까이 갈 수 있도록 지속 시도하는 거고. 아, 그리고 인재도 찾고 있다. 이 길을 함께 갈 좋은 분들을 더 많이 모실 수 있으면 좋겠다.
관련 기사
