10 분 소요

팀을 “잘” 운영하기란 쉽지가 않네요

우리 셀, 우리 팀… 회사에서 업무를 수행하는 가장 기본적인 단위다. 가화만사성 처럼, 이 작은 단위에서 어떻게 업무를 효율적으로 추진하느냐에 따라 상위 조직 나아가 전체 회사의 성공 여부가 달려있다고 해도 과언이 아니다. 이 세상 많은 팀장님들께서 각자의 노하우로 이를 터득해 가고 계실지언데, 나 역시 어떻게 하면 우리 팀이 잘 굴러갈 수 있을까 항상 고민해 오고 있다(정답은 영원히 찾지 못할 것 같다). 팀을 운영하는 toolkit 여러가지 중에, 오늘은 실험 적용해 봤던 주간 회의 방식에 대해 정리해 보고자 한다.

주간회의가 없는 회사는 아마 찾아보기 힘들 것이지만, 많은 개발팀의 구성원들이 고통스러워 하는 것을 보거나 들어왔다. 이를 테면 (1) 팀장 혼자 업무 지시를 하고 나머지는 받아 적기만 한다라던가, (2) 각자 업무 내용을 보고하고 있으니 내용이 너무 많아 2~3시간을 넘기게 된다라던가(사실 30분만 뺏겨도 개발자들은 흐름이 끊겨 괴로워 한다), (3) 보고를 위한 보고로 점철 되어, 도대체 지난주 보고와 이번주 보고의 상관 관계를 모르겠다던가 등이다.

팀의 회의 주제도 명확하게 하고, 시간도 효율적으로 사용할 수 있는 방법이 없을까 계속 고민해 오다 마침 18년도 9월 경에 상위 조직장께서 구글에서 적용하고 있다는 OKR을 도입하셨고, SM(Scrum Master)께서 관련하여 추천해 주신 OKR책의 내용을 조금 변형하여, 올해(2019) 초부터 약 6개월간 팀의 주간 회의에 적용해 보았다. 초기에는 생소한 부분이 있었지만, 점차 진행하면서 여러 장점이 있음을 느꼈고, 또한 좀더 생각해 볼 부분도 있었기에 여기 정리해 보고자 한다.

OKR “책” 의 간략 설명

Objective and Key Results (OKR)에 대한 설명을 자세히 옮기지는 않을 것이다. 위키 뿐만 아니라, 다양한 검색 결과에서 OKR의 상세를 확인할 수 있다. 아주 간략하게 정리해 보자면, Objective는 달성하고자 하는 목표 문장(mission statement)이다. 기억하기 쉽고, 짧게 쓴다(개인적으로는 자극적이어도 좋다고 생각한다). Key Results는 해당 Objective를 달성하는 데에 있어 측정할 수 있는 지표이다. 예를 들자면 아래와 같이 생각할 수 있다.

  • Objective: 지성미 넘치는 휴가를 보낸다
  • Key Results 1: 서재에 쌓아놓은 안 읽은 책 13권을 모두 읽는다
  • Key Results 2: 13권 각각의 주요 요점을 5항목씩 정리한다

KR은 측정할 수 있으면서도, 양적인 부분과 질적인 부분을 모두 측정해 볼 수 있도록 잡는다. 위 예에서는 책을 읽기만 하는 것에 그치지 말고, 내용도 숙지하자는 의지가 들어 있다. 자칫 Key Performance Indicator (KPI) 와 혼동할 수 있는데, 개인적으로 생각하는 주요한 차이라면, (1) 개인과 조직간의 연동, (2) 진취적인 지표 (70% 달성이 성공인 수준), (3) 개인 평가와의 비연동, (4) 월별 혹은 분기마다의 변경이다.

  • 개인과 조직간의 연동: 실제 OKR을 사용하는 구글에서는 CEO가 큰 목표를 정하면, 각 조직에서 이를 나눠 가져가고 그 하위 조직에서 또 이를 나눠가지며, 개인의 OKR까지 쪼개진다고 한다. 개인들은 자신의 OKR을 작성하면서 말이 안되는 목표라면 수정해서 다시 위로 올려 합치게 되고, 이렇게 위에서 아래로, 아래에서 위로의 검토 과정을 지루하게 반복하면서 목표를 잡는다고 한다. 또한 OKR이 정해지고 나면 서로 OKR의 링크를 타고 상위에서 하위, 다시 하위에서 상위로 탐색을 투명하게 할 수 있다고 한다(주1). 이것은 전사적으로 목표를 합의하는 것을 의미하고, 상호 업무 협조를 할 때 혹은 업무에 대해 거부를 할 때 중요한 근거로 활용할 수 있다.

  • 진취적인 지표: SK그룹에서는 SUPEX라는 개념이 있다. Super Excellent라는 최고의 이상적 상태를 의미하는데, 목표를 SUPEX로 잡아서 노력하다 보면 당장 달성은 못하더라도 벡터의 방향은 맞아 들어가는 것으로, 목표는 CbA(Challenging but Achievable)로 좀 높게 잡고 가면 현재 보다 나은 to-be model을 달성할 수 있다는 것이다(교육 받은지 오래 되서 기억이 정확한지 확신은 없음). OKR에서 말하는 KR도 약간 비슷한 느낌을 받았다. 100% 달성은 조금 어렵더라도 약간 진취적으로 목표를 잡는 다는 것이다. 만약 기간 내에 KR을 너무 빨리 달성했다면 뭔가 지표를 잘 못 잡았다고 보면 된다. 정상적으로 수행했을 경우 약 70%가 달성되도록 난이도를 조정하라는 것이다.

  • 개인 평가와의 비연동: 개인 평가와의 비연동은 정말 중요한 부분이다. 만약 OKR 달성을 개인 평가와 연동 시킨다면 아무도 목표를 진취적으로 잡지 않을 것이다. 목표를 개인의 평가를 위한 수동적인 내용으로 작성하는 것이 아니라, 개인이 서비스를 위해 능동적으로 설정하도록 하는 것이 핵심인데 이것이 정말 어려운 부분이다. 팀원과 리더의 신뢰가 반드시 필요하며, 업무에 대해 Ownership을 각자 가지는 팀의 문화가 반드시 뒷받침 되어야 한다. 월별 혹은 분기마다의 변경: 한번 잡은 목표는 정해진 기간동안은 유지한다. 중간에 새로운 업무가 생기더라도, 이미 정해진 OKR과 연동되지 않는 업무라면 과감히 버린다. 꼭 필요한 업무라면 다음 기간에 산정할 OKR에 반영한다(개인적으로는 Agile에서 sprint 내에 추가적인 backlog가 들어온 경우와 유사하다고 생각했다).

OKR의 개념에 공감하면서도 이를 팀 주간회의에 어떻게 활용해야 하는지는 고민이 많았으나, 아래 책이 큰 도움이 되었다.

okr book

크리스티나 워드케 지음, 박수성 옮김, “구글이 목표를 달성하는 방식 OKR”, 한국경제신문, 2018.

okr

책에서는 위와 같은 4분면을 주간회의에 활용하는 것을 소개해 주고 있다. 먼저 (1)목표의 경우, OKR의 KR을 나열하고, 각각의 KR별로 달성 가능성을 5/10 (50%)로 시작하여 매주 이것이 상승하였는지 감소하였는지를 체크한다. (2)건전성 항목은 팀이 목표를 실행하는 동안 지켜야 하는 것들로 매주 팀원들이 잘 지켜지고 있는지 토론을 할 내용이다. (3) 이번주 항목은 P1, P2로 나뉘는데 P1은 P2보다 좀더 우선 순위의 업무이다. (4) 4주 내 향후 중요 활동은 일종의 알림으로서, 앞으로 문제 없이 업무가 진행된다면 향후 일어날 일들을 적어 두는 것이다. 이렇게 함으로써 유관 부서가 미리 대응을 할 수 있도록 해 둔다. (1)~(4) 항목 모두 전체 내용을 적을 필요는 없고, 중요한 일만 적는 것이다. 책에서 위 내용을 소개 해 주고 있는 라파엘은 이렇게 얘기한다.

“이건 누가 제일 바쁘게 일하는지를 보여주는 대결이 아니에요. 당신이 하는 모든 일을 목록에 올리는 게 아니라, 반드시 실행해야 하는 일들만 적는 거예요. 우리 모두 언제나 할 일이 많죠. 핵심은 중요한 일들을 잊지 않는 거예요.”

OKR을 활용한 주간 회의 실제

먼저, 팀에 위 내용을 소개 하기 전에 OKR은 합의한 상태였다. 또한, OKR의 달성은 개인 고과와 전혀 연동되지 않는 것 역시 설명 하였다(우리 조직은 개인 평가는 연말 peer 평가로 이루어 지며, 팀장이 순서를 바꿀 수 있는 권한은 있으나 두가지를 약속하였다. (1) 평가할 peer는 전체 팀원과 과제의 외부 PO로 통일한다. (2) peer 평가의 결과는 투명하게 공개하고, 팀장은 임의로 순위 변경을 하지 않는다). 여기에 더해서 주간 회의의 이름을 “월요 모임” 으로 변경하고, 이 월요 모임은 팀원 각자 뭘 하고 있는지 체크하는 자리가 아니라 우리팀이 바른 방향으로 집중하고 있는지에 대해 체크하는 자리로 생각하기로 하였다.

팀 회의를 위해서, 4분면을 공유 문서 (Google docs 혹은 office365)에 매주 한장씩 추가하는 방식을 사용하였고, 기본적으로 지난주 슬라이드를 이번주에 카피를 해 놓고 변경되는 부분만 수정을 하여 시간을 최대한 단축하였다. 4분면은 책에서의 내용과는 조금 달리 필요에 의해 조금씩 수정하여 사용했다. 아래는 기존 4분면의 각 항목을 실제로 어떻게 활용했는지 정리해 본 것이다.

목표

OKR을 그대로 기입하고 실적을 매주 업데이트 하였다. 책에서는 5/10 처럼 KR별로 달성 가능성을 매주 업데이트 하는 방식이었는데, 우리는 달성 가능성에 대한 수치화가 조금 애매하다고 생각하여 실제 수치를 업데이트 하도록 하였다. 예를 들어 KR이 순증 거래액 50억이고 지난주 까지 15억을 달성한 경우 15/50 (30%) 와 같이 기입하였다. 우리팀에서 OKR로 잡은 수치들은 항상 Tableau를 통해 dashboard를 만들어 놓고 시작하였기 때문에 OKR 수치를 업데이트 하는 것은 시간이 많이 소요되지 않았다. 그러나 가장 문제였던 것은 그룹에서 OKR을 정하는 것은 분기 단위(3개월 마다) 였는데, 분기 초 사업조직과 함께 shared goal을 잡았음에도 불구하고, 3개월 내 이를 달성하기가 매우 어렵거나 혹은 매우 쉬운 경우가 생겼던 것이다. 사실 새로운 서비스를 만들 때 이 서비스의 비즈니스 효과를 정확히 예측하기란 참 어려운 일인 것도 사실이다. 뿐만 아니라, 비즈니스 적인 효과를 지표로 선정하더라도 개발 기간이 많이 소요된다면, 그 개발 기간 동안은 비즈니스 지표는 항상 0으로 고정되어 있는 것이다. 이 모든 걸 고려해 볼 때, OKR의 갱신 주기는 우리 처럼 단일 팀 내에서만 진행할 때(전사적으로 OKR을 사용하지 않아 갱신에 리소스가 적게 소요될 때)는 1달 정도로 빠르게 가져가서 정확한 목표로 빨리 변경할 수 있도록 하는게 좋다고 생각한다.

개발팀에서 비즈니스 목표(예를 들어 순증 거래액 X억)를 잡는 것이 맞느냐에 대한 팀원들의 의문이 초기에 있었으나, 추후에 우리 개발 내용이 실제 얼마의 효과가 있는지 항상 눈으로 확인할 수 있어 동기부여가 되었다는 의견들이 있었고, 또한 목표를 달성하지 못할 것 같은 경우 반대로 사업팀의 PO에게 또다른 서비스 아이디어를 스스로 제시하는 등 각자 능동적으로 업무를 진행하게 되는 효과가 있다고 피드백을 주었다.

건정성

이 항목은 “우리가 지킬 가치”로 이름을 변경했고, 지난주 우리가 업무를 수행하면서 이 가치가 지켜지지 않은 사례가 있는지 얘기하기로 했다. 예를 들어 우리 팀이 지난 2분기 동안 합의했던 가치는 아래와 같다.

  • 우리는 완전한 권한 이양을 추구한다​
  • 우리는 데이터 기반의 의사 결정을 한다​
  • 우리는 해야 할 일보다 하지 말아야 할 일을 먼저 찾는다​
  • 우리는 업무와 개인의 발전을 동시에 추구한다

실제로 사업쪽과 과제를 진행하면서, 팀 내에서 데이터를 조사하였는데 사실이긴 하지만 약간 오해할 수 있는 내용이 나왔고 이를 상위에 보고하는데 있어 사업팀의 의견에 따라 제외한 적이 있었다. 그 다음 주 월요 모임에서 이게 데이터 기반의 의사 결정에 맞냐며 팀원들의 신랄한 비판을 온몸으로 받았다. 이런 토론이 개인적으로는 매우 유용했고, 우리가 업무를 수행하는데에 있어 일관성을 유지하게 만들어 줬다.

완전한 권한 이양의 경우, 요즘처럼 직급 없이 모두가 “님”으로 통일되는 수평한 환경에서 자칫 의사 결정이 계속 미뤄지고 팀장에게 집중되지 않도록 업무를 진행하는 각자가 의사 결정을 하기 위해 선정하였다. 이때 팀장은 조언자 혹은 서포터(외부 조직과의 협업등)의 역할을 한다. 이것이 가능하기 위해선, 반드시 기본 가치에 대한 합의가 팀 내에 공고하게 체결되어 있어야 한다고 생각한다. 결국, 완전한 권한 이양은 “이 의사 결정은 팀장에게 물어보나 마나 이렇게 하라고 할꺼야” 또는 “이 부분에 대해 팀장이 좀 우려할 것 같은데, 내가 이렇게 설명하면 당연히 이해 할꺼야” 라는 것이기 때문에 가능한 것이 아닐까.

월요 모임을 진행하는 동안 우리가 지킬 가치는 자유롭게 추가 혹은 삭제할 수 있게 하였다. 그러나, 실제 6개월간 진행해 본 결과 최초 정한 가치가 변경되진 않았다.

이번주

책의 설명과 같이 우리 역시 P1(반드시 할일), P2(시간이 되면 추가로 할일)로 나누어 기록하였다. 다만, 전체 팀이 할일을 합쳐서 적기 보다는 개인별로 작성하였다. 팀 내에서 진행하는 과제의 성격이 완전히 단일하면 모르겠지만, 동시에 진행하는 과제가 3~4개씩 되고, 또 그들간의 상관관계도 적은 경우 어쩔 수 없이 개인별 아이템을 적을 수 밖에 없었다. 다만, 업무의 due date는 기입하지 않기로 한 대신 자연히 그 주의 금요일까지로 하기로 하였다. 만약 업무가 한주 안에 끝나지 않는 크기인 경우, 업무를 한주 정도의 크기로 분리하도록 하였다.

기록은 월요 모임 사전에 적는 것이 아니라, 월요 모임이 시작하고 나면 지난주 슬라이드를 복사해서 이번주용 슬라이드를 만들고, 각자 자기가 지난 주에 적었던 “이번주” 항목의 결과를 공유해 주면서 지우고 새롭게 업데이트 하는 방식으로 진행했다(서기가 따로 있지 않았다. 각자가 다른 팀원에게 설명하면서 기록하였다. 당연히 팀장도 예외 없이 자기 업무 내용을 적었다. 우리팀은 항상 팀장이 가장 먼저 할일을 적었다). 업데이트 도중 다른 팀원들은 그 팀원의 이번주 업무 내용이 우리의 OKR 달성과 관련이 있는지를 생각하며 리뷰한다.

이렇게 매주 월요일 각자가 할일을 적으면서 본인이 무엇을 이번주에 할지를 생각하고, 한주 동안 업무를 진행하는 것을 반복 하면서 약 3~4개월 후에 우리팀은 이 한주의 리듬을 자연스럽게 체득하게 되었다. 매주 월요일에 한주 할일은 결정하고, 주중에 열심히 해서 목요일 쯤에 서로 공유하고, 금요일에 나머지 보충할 부분 보충하고 조금 일찍 퇴근하는. 팀장은 이 리듬을 깨는 외부의 업무 지시를 한주 이후로 막아주기만 하면 되었다.

4주내 향후 주요 활동

책에서는 이 항목을 향후 한달간 일어날 예상 업무 내용으로, 유관 부서에게 미리 준비를 할 수 있도록 하는 목적으로 사용했다. 우리 팀의 경우는 이 부분을 “차주” 로 변경했고, 만약 “이번주” 업무가 잘 수행된다면 다음주에는 어떤 일을 할지를 각자 기록하였다. 이에, 개인별로 작성하였고 “이번주”와 마찬가지로 P1, P2로 우선 순위를 구분하였다. 매주 월요 모임에서는 각자 지난주의 이 항목을 보고, 이것이 “이번주”에 넣기에 적절한 경우는 그대로 copy and paste를 하면 되었고, 만약 변경이 필요한 경우는 자연스럽게 안된 이유에 대한 토론을 할 수 있었다(주로 이슈가 있을 때 이부분이 차이가 났다).

처음에는 다소 복잡해 보이기도 했으나, 시간이 지나면서 차츰 속도가 났고 6월 정도에는 월요 모임이 다 끝나는데 30분도 소요되지 않았다. 우리팀은 앞에서 설명했던 것처럼 OKR을 합의해서 만들었기 때문에 각자 최대한 지표를 외우고 있었고, dashboard를 통하여 매일 확인할 수 있었다. 또한 좀 구시대적이긴 하지만, 큰 종이(전지)에 OKR 지표를 적어 벽면에 붙혀 놓고, 진행 정도를 매직으로 업데이트 했다(개발팀에서 왜 이런걸 하느냐고 물을 수도 있겠지만 효과가 꽤 좋았다. 각자 자기 지표를 매일 출근하면서 보고 외우고, 그걸 계속 고민한다).

책에서는 매주 금요일에는 간식거리를 가져 두고, 모두 모여서 각자 한주에 한일을 공유하고 자랑하는 자리를 가지라고 했다. 그러나, 주중에 열심히 하고 금요일은 조금 일찍 퇴근하는 요즘 문화에서는 적절치 않다고 생각해서 차용하지 않았다. 주중에 업무가 완료된 경우, 완료된 시점에 팀원들에게 보여주고 자랑하는 것으로 충분했다.

월요 모임에서는 심각한 토론은 이루어 지지 않았다. 이슈와 토론은 필요할 때마다 평소에 따로 진행 했다. 또한 팀원들은 매주 1차례 팀장과 1:1을 하면서(약 30분간 야외를 걷거나, 사내 까페에서 수다를 떨거나, 아이디어룸에서 얘기를 하거나) 좀더 개인적인 차원의 얘기를 했다. 그렇게 때문에 월요 모임에서는 좀더 업무 항목에 대한 검토에만 집중할 수 있었다.

방법론은 방법론일 뿐

다양한 개발 방법론 혹은 협업론이 있고, 이를 코칭하는 클래스도 많이 있는 것으로 알고 있지만 기본적으로 중요하다고 생각 하고 있는 것은 구성원의 성향과 서로간의 믿음이다. 실력이 우수하고, 겸손한 구성원들끼리 서로 투명하게 할일을 공유하고 필요할 때는 도와주기까지 한다면 워터폴이건 애자일이건 방법론에 상관 없이 업무는 잘 돌아갈 수 밖에 없다고 생각한다. 그러나 어렵다. 이것이 정말 현실에서 가능한 상황이던가. 운 좋게 7~8명 정도의 조직 단위(셀장, PL, 혹은 팀장) 리더를 맡아 오면서 언제나 개인적인 역량의 한계를 느껴왔다(앞으로도 정답은 찾지 못할 것 같다).

팀 운영을 위해 가장 본질이라고 생각하는 것은 무엇보다도 팀원 누구나 말을 할 수 있게 분위기를 만들어 주는 것이다. 뭔가 근엄함과는 조금 거리가 있는 내 자신의 성향탓도 있었겠지만, 인복이 있었던 탓에 뛰어난 구성원들을 많이 만나 왔었고, 자연스럽게 어떻게 하면 그 능력을 내가 방해 하지 않을까를 고민해 왔던 것 같다. 많이 듣고, 토론해 주고, 스스로 의사 결정 할 수 있게 해 주고, 책임져 주고, 윗분께 자주 노출 시켜 주고…

팀의 리더급이라면, 교육도 많이 들었고 또 본인이 리더쉽에 대한 글도 많이 읽어, 이미 머리로는 다 아는 내용일 것이다. 그러나 슬프게도, 어디 좋은 리더가 교육으로 만들어 질 수 있는가. 그나마 훌륭한 리더들이 좋다고 정리한 내용을 어설프게 나마 따라 함으로써, 지금보다는 약간 나아지기를 기대하는 것이겠지. 이미, 좋은 리더로 성공하신 분들은 어떤 이유에선지 그것을 본능적으로 타고 나신 것일지어다. 하지만, 좌절하고 있을 수 만은 없다. 그런 타고난 리더는 극히 소수일 것이라고 믿고, 우리는 또 우리 나름대로 실험하고 노력해 갈 수 밖에.

주1: 당시에는 몰랐지만, 구글에서 실제로 아주 빡세게 OKR을 관리하지 못한다. 매우 많은 임직원의 입퇴사가 반복되는 탓에 실제 매니저가 OKR을 제대로 이해하지 못하는 경우도 파다하다. 다만 좀 오래된 조직일 수록 어느정도는 잘 돌아가고 있다. 직원 각각의 프로파일 페이지에 OKR을 기입하여 서로 확인하는 것도 가능하지만, 강제하지 않는 조직이 많아 일반화 하긴 어렵다. (2024 작성)