성장하는 조직에서 계속 애자일한 문화를 유지할 수 있을까?
안녕하세요. 아테나스랩 Otis입니다. 저는 현재 아테나스랩의 기획챕터 소속으로 스쿼드의 PO 를 담당하고 있습니다. 아테나스랩의 기획챕터원이자 PO로서 구성원들과 함께 어떻게 하면 더 좋은 제품을 만들 수 있을까에 대해 많은 고민을 하고 있습니다.
저는 PO를 담당하기 이전부터 팀의 멤버로서 애자일하게 일하는 것이 무엇인가에 대한 물음이 많았습니다. 최근 직장인 커뮤니티와 아티클을 보았을 때 저와 같이 애자일에 대한 관심을 가지고 있는 분들이 많아 보입니다. 워낙 시장과 수요자들의 상황 및 분위기가 빠르게 변화하기 때문에 애자일한 문화를 만들기 위해 노력하는 회사, 팀들이 늘어나고 있는 듯 합니다.
하지만 제가 종종 보고 듣는 이야기들이 ‘이게 애자일이 맞나?’라는 생각이 들기도 합니다. 정기 논의들을 스프린트에 맞춰 데일리스크럼, 플래닝, 데모라는 이름으로 대체했을 뿐, 애자일이 지향하고 있는 서로 간의 협력과 피드백, 학습을 통한 제품 개선과는 거리가 멀어보입니다.
그래서 팀원으로서 제가 경험했던 과정을 돌이켜 보며, 초기부터 현재까지 아테나스랩이라는 팀이 애자일의 핵심을 무엇으로 보고, 핵심적인 부분을 강화하기 위해 어떤 노력들을 해왔는지 이야기해보려고 합니다. 애자일하게 일하기 위해 중요한 것은 무엇일지를 고민하고 계신 분들께 이 글이 도움이 되면 좋겠습니다.
애자일한 조직을 만들기 위한 핵심
애자일이란?
먼저 애자일에 대한 개념을 짚고 넘어가자면, 애자일의 개념은 2001년 제창된 애자일 소프트웨어 개발 선언을 통해 확인을 할 수 있습니다. 애자일 프로세스를 보조하는 툴인 지라(Jira)의 제작사 아틀라시안(Atlassian)에서는 아래와 같이 애자일을 정의하고 있습니다.
애자일은 프로젝트 관리 및 소프트웨어 개발에 대한 반복적인 접근 방식으로, 팀은 고객에게 가치를 더 빠르게 덜 복잡한 방법으로 제공할 수 있습니다. 애자일을 통해 팀은 더 작은 공략 가능한 단위로 작업을 제공합니다. 지속적으로 요구사항, 계획 및 결과가 평가되며 팀은 변화에 신속하게 대응할 수 있는 자연스러운 매커니즘을 갖게 됩니다. — Atlassian
위의 내용과 같이 애자일은 작은 단위로 빠르게 적용, 학습하는 것이며 이 과정에서 ‘협력’과 ‘피드백’이 강조됩니다.
그렇다면 위에 나온 애자일 정의, 핵심에 대한 이해 만으로 현장에서 이를 잘 적용할 수 있을까요? 만약 그럴 수 있었다면 시중에 애자일에 대한 무수히 많은 글과 서적들이 나오지 않았을 겁니다. 애자일이 조직 안에 잘 정착하고 워킹(working)하기 위해선 그 밑바탕이 되는 많은 노력들이 필요하기 때문입니다. 그렇다면 애자일한 조직이 되기 위해 필요한 핵심은 무엇일까요?
애자일한 팀을 만들기 위해서는 ‘개인의 주도성’과 ‘활발한 피드백’을 위한 환경이 필요합니다.
과거 저의 경험 속에서 애자일을 잘 실천하기 위한 핵심이 무엇이라고 생각하는지를 물어본다면, 제 대답은 ‘1) 구성원 간 적극적인 정보 공유를 통한 맥락 일치와 2) 담당자 개인의 주도성이 밑바탕 되었을 때 비로소 구성원들이 애자일하게 움직일 수 있다’ 입니다.
변화의 속도가 빠르고, 민첩함이 필요한 조직에서는 유연함을 가지고 적절한 시점에 문제를 해결하는 것이 중요합니다. 왜냐하면 이런 환경에서는 문제들이 발생했을 때 특정 관리자의 결정 만을 기다리다가 타이밍을 놓칠 수 있기 때문입니다. 그렇기 때문에 담당자가 적절한 시점에 결정과 행동을 할 수 있도록 도와야 합니다. 그렇기 때문에 구성원 간 적극적인 정보 공유를 통한 맥락 일치와 담당자 개인의 주도성은 적절한 시점에 담당자가 결정을 하고 민첩하게 움직이기 위해 필요한 요소라고 할 수 있습니다. 이러한 요소들이 갖춰졌을 때 비로소 조직과 구성원이 애자일하게 움직일 수 있게 되고, 빠른 제품 개선과 문제해결이라는 결과를 얻을 수 있습니다.
하지만 처음 애자일을 도입하려는 일부 팀에서는 ‘작은 기능으로 빠르게 기능을 출시하고 개선한다’에만 매몰이 되어 이를 위해 필요한 문화, 환경을 조성하는 것을 간과하는 경향이 있다고 생각합니다. 애자일하게 움직일 수 있는 환경을 만들기 위한 노력 없다면 결국에는 이름만 바뀐 ‘K-애자일’의 방식으로 일하게 될 가능성이 큽니다.
- K-애자일: 이름만 애자일을 지향할 뿐 실제로는 Top-Down, 워터폴 방식의 업무가 진행되는 상황을 이르는 말입니다.
아테나스랩에서는 어떤 고민과 노력을 해왔을까?
아테나스랩은 애자일하게 움직일 수 있는 조직이 되기 위해, 매 성장 단계별로 ‘주도성’과 ‘가시성’을 높이기 위한 노력들을 해왔습니다.
Stage 1 (팀 초기: 6인) — Sprint의 도입
당시 팀의 상황
사실 이 정도 규모의 팀일 때는 애자일에 대한 많은 고민이 필요하다고 생각하지 않습니다. 이 시기에는 각 개인이 하나의 부서(챕터)이자 유일한 담당자로 역할을 하고 있을 가능성이 높기 때문입니다. 또한 소규모의 팀이기 때문에 별도의 공유나 명문화 과정 없이 만들고자 하는 서비스의 목적과 지향해야 하는 지점이 협업 과정에서 체화*할 수 있는 단계입니다. 따라서 ‘공개되고, 공유되는 정보’, ‘담당자 개인의 주도성’이 별도의 노력 없이도 확보가 될 수 있는 환경이었습니다.
*체화: 생각, 사상, 이론 따위가 몸에 배어서 자기 것이 됨.
Sprint: 빠른 기능 개발/개선에 집중하는 팀 분위기를 만들기
당시 팀의 규모는 작았지만, 더 애자일한 환경을 위해 아테나스랩은 ‘Sprint(스프린트)’를 도입하였습니다. 2주 단위로 개인과 팀의 목표를 다시 한번 확인하여 계획을 세우고 가능한 빠른 기능 개발에 집중하고자 했습니다.
실제로 스프린트를 통해 특정 기간 동안 리소스 집중하여 매 스프린트 단위로 작은 기능이더라도 업데이트를 진행할 수 있었습니다. 또한 스프린트는 2주 단위로 팀 전체가 함께 모여 다음 주기의 주요 업무, 목표를 함께 설정을 함으로써, 2주의 기간 동안 각 개인 별로 몰입이 필요한 것이 무엇인지에 대해 명확하게 확인할 수 있게 해주었습니다. 그렇기 때문에 각 개인은 2주 동안의 목표를 달성하기 위해 개인 스스로가 필요한 작업을 주도적으로 진행할 수 있었습니다. 또한 매 스프린트가 끝난 뒤에는 서로가 회고 과정을 거치며 성과와 과정에 대한 내용을 점검하고 지난 업무에 대해 함께 피드백을 나눌 수 있었습니다.
Stage 2 (팀 중반: 20인) — OKR과 Squad의 도입
당시 팀의 상황과 문제들
아테나스랩은 21년 7월 말 Pre-A 투자 유치 이후부터 ‘오늘학교’ 서비스의 성장을 가속화하기 위해서 빠르게 인원을 충원했습니다. 그 결과 1년이라는 짧은 기간 동안 기존 팀원 규모의 2배 수준으로 인원이 충원되어 20명 규모의 팀이 되었습니다.
하지만 빠른 성장에 따른 성장통이었을까요? 이전과는 다른 문제점들이 나타나기 나타나기 시작했습니다.
직면했던 문제점
1. 신규 팀원은 증가하고, 맥락을 유지해오던 기존 팀원들의 이탈이 생겼다.
2. 팀의 맥락과 정보를 잘 이해하고 있는 팀원들의 비중이 줄고, 팀 목표에 대한 전달이 잘 되지 않았다.
3. 기존의 부서(챕터) 단위로는 온전한 프로젝트 관리 및 애자일하게 서로가 의견을 나누고, 함께 고민하여 프로젝트를 진행하기 어려움이 생겼다.
⇒ 정보와 맥락의 흐름이 끊기고, 커뮤니케이션이 경직되기 시작함
각 구성원들이 주도적으로 움직이고 활발한 피드백을 주고 받기 위한 조건은 적극적인 정보와 맥락의 소통 및 교류, 이해입니다. 하지만 이 시기에는 맥락 공유와 일치된 인식의 부족으로 인해 오히려 팀 내 경직성이 높아지고 있었습니다.
대표적으로 각 부서(챕터) 단위로 자신의 업무만 담당하고, 어떤 기능이 만들어져도 이것이 어떤 문제를 해결하기 위함인지, 그리고 어떤 모습의 기능으로 탄생할 지에 대한 공유가 원활하게 이루어지지 못했습니다. 그로 인해 담당자 간에도 중요하게 생각하는 KPI가 다르거나, 완성된 서비스의 모습을 달리 생각하는 경우가 쉽게 발생했습니다. 이러한 동료 간 생각 차이는 미스 커뮤니케이션으로 이어졌으며, 제품 개발 속도 및 완성도에 있어 저하를 가져왔습니다.
애자일하게 우리가 움직이기 위한 주도성 및 구성원 간 활발한 피드백은 침체되었고 이전과 대비하여 유연함 및 신속함이 감소하는 모습으로 나타났습니다.
OKR: 중장기적인 팀의 목표와 방향에 대한 가시성을 높여주기
이 시기 가장 우선적으로 해결해야 하는 것은 팀과 개인 간의 목표를 정렬(align)하는 것이었습니다. 기존 2주 단위의 스프린트로는 위 문제를 해결하기에 충분하지 못했습니다. 스프린트의 경우 개인의 목표와 과업이 비교적 확실했지만, 중장기적으로 개개인이 기여해야 할 부분이 어디인지, 어떤 관점으로 판단을 해야 하는지를 전달하기에 충분한 방법은 아니었습니다. 그렇기 때문에 개인들의 판단과 결정, 행동에 있어 주도성이 낮아질 수 밖에는 없었습니다.
따라서 팀에서는 팀과 개인들의 중장기적인 목표를 맞추기 위한 방법으로 OKR을 도입하였습니다. OKR의 주요 목적은 팀의 중장기적인 목표와 방향성을 최대한 팀원들에게 공유하고 이를 인지할 수 있도록 하는 것이었습니다. 이를 토대로 개인이 판단하고 결정할 때 어떤 기준으로 바라봐야 하는가를 제시하기 위함이었습니다.
OKR 도입한 이후에는 기존에 명문화되지 않아 팀원들이 짐작했던 팀의 목표를 조금 더 명확하게 전달시킬 수 있게 되었습니다. 이는 현재 팀의 우선 순위가 무엇인지를 나타내는 역할을 하고 있습니다. 업무와 프로젝트의 우선순위를 정할 때, OKR은 팀의 목표와 우선 순위를 고려할 수 있게 하여 팀원들이 주도적으로 업무를 할 수 있게 긍정적인 영향을 주고 있습니다.
Squad: 각 부서 간 협력과 주도성을 만들기
OKR과 함께 도입된 것은 스쿼드(목적 단위 조직)입니다. 부서 간 소통과 피드백의 부재라는 문제점을 해결하기 위해 도입했습니다.
스쿼드의 도입으로 각 부서 별 전문성을 가진 팀원들이 모여 다각화된 시선으로 사용자와 프로덕트 관점에서 문제를 찾고 해결할 수 있게 되었습니다. 이 과정을 통해, 팀원들은 서로 맥락을 파악할 수 있게 되었고, 문제점에 대한 해결 방안에 대해 적극적으로 의견을 교류하고 피드백을 주고받을 수 있게 되었습니다.
초기의 아테나스랩의 스쿼드 구조
- 각 부서별 1인은 최소 1개의 스쿼드에 소속됩니다.
- 우리가 개발할 기능 중심으로 스쿼드를 구성하였습니다.
- ex)시간표 수정 기능 개발을 위한 ‘시간표 스쿼드’
팀에서 스쿼드를 시작할 때 생각한 장점들은 다음과 같습니다.
첫번째는, OKR이 잘 작동하도록 도와주는 조직 구조라는 점입니다. 부서(챕터) 단위만 존재하는 경우 팀의 목표와 실무를 연결하는 것은 어려울 수 있습니다. 왜냐하면 각 부서(챕터)에서 팀의 목표를 위해 노력하고 있지만, 그 방향이 부서(챕터) 간 상충할 수 있기 때문입니다.
‘사용자들의 만족도를 향상시키는 서비스를 만든다’라고 했을 때를 예로 들어보겠습니다. 기획 챕터의 경우 가능한 빠르게 기능 업데이트를 진행하고자 할 것입니다. 반면 디자인 챕터의 경우 사용자의 만족도를 높이기 위해 완성도 있는 UX를 만들고자 할 것입니다. 이 경우 서로가 팀의 목표를 위해 움직이는 것은 맞지만, 처리속도의 측면에서 기획 챕터와 디자인 챕터 간의 상충이 발생하게 됩니다. 하지만 스쿼드에서는 기획 챕터와 디자인 챕터가 함께 모여 공동의 목표와 타임라인을 설정하기 때문에 목표를 향해 공통된 방향으로 움직일 수 있습니다.
두번째는, 부서 간의 사일로 현상, 즉 부서 간 이기주의와 무관심을 줄일 수 있다는 점입니다. 스쿼드는 부서(챕터) 간의 의견을 교환하기에 좋은 조직 구조였기 때문에, 부서(챕터) 간의 무관심으로 피드백이 활발하지 못했던 문제점을 해결해 주었습니다.
끝으로, 모든 직군의 팀원이 모여 문제점과 해결 방안을 모색하는 일종의 미니 스타트업인 스쿼드는, 기존 챕터보다 독립적인 의사결정을 할 수 있습니다. 이러한 특징의 스쿼드는 구성원들의 주도성을 높이기 좋은 조직 구조입니다.
변화에 대한 시도, 하지만 어려움도 많았습니다.
팀의 문제점을 해결하기 위해 도입했던 OKR과 스쿼드가 처음부터 원래의 의도대로 잘 정착했을까요? 아닙니다. 팀의 업무 방식과 조직 구조를 바꾸고 정착시키는 과정은 결코 의사결정만으로 쉽게 되는 일이 아니었습니다.
처음에는 OKR이 익숙하지 않아 목표를 설정하고 평가하는 것은 어려웠지만, 팀의 상황에 맞춰 일부 방식을 변경하면서 적응해나갔습니다. 그리고 여전히 지난 OKR을 검토하고, 팀에 상황에 맞게 변화하려고 계속 노력하고 있습니다.
스쿼드 또한 처음에는 단순히 각 부서(챕터)의 인원을 모아놨다는 것만으로 의사소통의 개선과 피드백 증가가 드라마틱하게 나타나지 않았습니다. 지금 돌이켜보니, 협업을 위한 준비가 부족했다는 생각이 듭니다. 협업에 대한 프로세스가 부재했고, 팀원마다 어떤 방식의 의사소통을 선호하는지, 원활한 의사소통을 위해 무엇이 필요한 지에 대해 익숙하지 않는 상태였습니다.
팀에 시도했던 방법들이 정석처럼 딱 맞아 떨어지진 못했기에 이 시기에는 참 어려움이 많았습니다. 하지만 개선을 위한 노력들을 팀 차원에서 꾸준하게 지속해왔고 그 노력들을 이야기해보려고 합니다.
Stage 3 (현재) — 적극적인 정보 공유와 Squad (Ver.2)
팀의 상황
지난 과정에서 문제를 해결하기 위해 도입했던 OKR과 스쿼드를 팀에 잘 정착시키기 위한 노력이 필요한 시점이 있었습니다. 익숙하지 않은 방식이라 팀원들에게 어려움이 있기도 했고, 스쿼드를 우리가 의도한 방식으로 잘 운영할 수 있을 것인가에 대한 고민도 많았습니다. 이제 현 시점에서 저희 팀은 개개인의 주도성과 가시성을 높여주기 위해 어떤 노력을 하고 있는지 적어보도록 하겠습니다.
Squad ver.2: 주도성과 협업을 강화하기
기존의 아테나스랩에서의 스쿼드는 프로젝트 단위의 기능들로 구성이 되어 있었습니다. 가령 시간표 수정 기능을 위한 시간표 스쿼드와 같이 한정된 범위 내의 기능 개발을 위한 단위로서 스쿼드를 운영했습니다. 이러한 조직 구성에는 예상치 못한 문제점이 있었습니다.
목표 정의(ex. 기능의 개발)가 너무 명확하여 구성원들의 주도성이 떨어진다는 점이었습니다. 스쿼드는 팀의 목표에 맞춰 스쿼드 구성원들이 독립적으로 문제를 정의하고, 해결 방안에 대한 논의하는 주도성이 강한 조직입니다. 하지만 오히려 구성의 목적이 뚜렷하고 문제 상황이 이미 정해진 형태로 스쿼드 구성이 이루어지다 보니, 초기의 의도와는 달리 구성원들의 주도성이 제한이 되는 상황이 발생했습니다.
스쿼드의 원래 의도를 살리기 위해 저희는 새로운 스쿼드의 구성을 생각해야 했습니다. 주도성을 높이기 위해 현재 변화된 스쿼드는 스쿼드 당 인원을 더 확대하고, 기능보다는 Feature에 더 중점을 두고 있습니다. 또한 팀의 목표와 정렬(align)되는 스쿼드의 분기 OKR과 KPI를 중심으로 Feature 내의 개선 목표들을 스쿼드 내 구성원들이 함께 설정하고 있습니다.
이 과정에서 PO와 PM들은 스쿼드의 작업이 우리의 방향성에 정렬(align)이 되도록 노력하고 있으며, Maker(디자이너, 개발자)분들은 자신들의 전문성을 살려 더 나은 해결 방안에 대한 아이디어들을 내고 있습니다.
맥락과 정보가 잘 교류되는 팀 만들기
팀의 맥락과 방향, 문화를 이해하는 것은 담당자 개인이 주도성을 가지는데 있어 중요한 요소입니다. 따라서 팀 차원에서 이를 공유하고 정렬(align)하기 위한 노력들도 열심히 진행을 하고 있습니다. 특히 미니 워크샵을 통해 팀이 추구하고자 하는 방향을 공유하고, 방향성과 목표 설정의 바탕이 된 내외부의 맥락도 함께 공유를 하고 있습니다.
이와 더불어 팀의 문화적 가치에 대한 전파도 지속적으로 하고 있습니다. 팀의 문화는 팀원의 행동 방식과 사고 방식에 큰 영향을 줄 수 있는 요소입니다. 팀원이 판단을 하거나 행동을 할 때 팀의 문화가 기준으로서 작용할 수 있기에, 팀 온보딩, 팀 내 세션, 주기적인 360도 피드백 등을 통해 팀의 문화적 가치를 주기적으로 팀원들에게 공유를 하고 있습니다.
스쿼드 차원에서도 팀원들 간의 활발한 피드백, 협력을 위한 노력들을 하고 있습니다. PR과 키워드 논의라는 과정을 통해 함께 일하는 구성원들에게 우리가 만들 제품의 모습과 맥락을 수시로 공유하기 위해 노력하고 있습니다.
이러한 과정들은 각 구성원 간 같은 맥락의 형성과 향후의 완성이 되었을 때의 모습에 대한 이미지를 통일하는데 많은 도움을 줄 수 있었습니다. 이를 통해서 기획자 뿐만 아니라 디자이너, 개발자 모두 목표를 달성하기 위해 더 나은 아이디어와 피드백들을 활발히 교류하고 있습니다.
앞으로의 계획은?
저희 팀이 과거에 꾸준히 개선을 해온 것과 같이 앞으로도 더 개선할 예정입니다. 현재 시점의 팀 차원의 고민은 ‘구성원들이 높은 주도성을 가지기 위해 명확한 가시성(결정)이 필요할 거 같다’입니다. 기존에는 맥락을 공유하는 것으로 개인이 판단 또는 결정해야 하는 시점에 주도성을 가질 수 있을 것이라는 생각을 해왔습니다.
하지만 팀원들이 많아지고 생각들을 정렬(align)할 수 있는 기회가 줄어드는 상황에 접어들면서, 공유된 맥락을 개인 별로 다르게 해석할 가능성이 존재할 수도 있다는 생각을 하게 된 것 같습니다. 따라서 이후에는 명확한 목표 지점과 이후의 모습을 어떻게 팀원들에게 전달하여 개개인의 주도성을 발휘시킬 수 있을지를 팀과 스쿼드 차원에서 고민하고 있습니다.
마치며
스타트업이라는 조직에서는 잦은 환경의 변화가 발생할 수 밖에 없습니다. 즉 일회성의 노력으로만 애자일을 만들기 어렵습니다. 아테나스랩에서도 위 모든 과정과 변화들이 단시간에 이루어진 것은 아닙니다. 많은 시간이 필요하기도 했고, 예상치 못한 부작용이 나타날 때도 있었습니다. 그렇기 때문에 애자일한 환경을 만들기 위해서 주기적으로 ‘모든 팀원들이 주도성을 가지고 일을 할 수 있는가?’와 ‘적극적인 피드백, 협력을 위하여 우리가 해결하고, 추가해야 할 부분들이 있는가?’와 같은 질문들을 계속해서 해야 했고 개선해야 했습니다.
이 글을 정리하면서 제가 말씀드리고 싶은 것은 애자일에서 말하는 짧은 주기로 개발하고 개선하는 과정은 하나의 Output이라는 것입니다. 이를 잘 이끌어내기 위해서는 주도성과 협력, 피드백을 높이기 위한 팀 차원의 노력이라는 Input이 필요하다는 점입니다. 애자일한 환경은 결코 단시간에 만들어지지 않으며, 불변으로 유지되는 것이 아닙니다. 위에 언급한 저희 팀의 사례와 같이 꾸준히 팀의 상황을 파악하고 문제가 되는 부분들에 대해 개선하는 과정이 밑바탕이 되어야 합니다. 저희 팀의 사례들이 업무 현장에서 애자일을 고민하고 있는 분들에게 도움이 될 수 있으면 좋겠습니다.
