개발팀을 운영하는 입장에서 어떻게 하면 좀 더 팀을 효율적으로 변화시킬수 있을까에 대한 고민을 끊임없이 하시는 분들이 많을 것이다. 그러기 위해서는 현재 구조에서는 더 이상 변화가 힘들것 같다고 판단을 하는 경우도 있을 것이다. 그래서 어떻게든 변화를 주기 위해서 현재 팀 구조를 개편하는 것으로 결정을 할 수 있다. 현재는 기능단위 조직 (eg. 개발팀, 기획팀, 디자인팀 // 또는 개발팀 내에서도 서버팀, 웹팀, 모바일팀)이므로, 서비스단위 조직 (eg. 블로그 서비스팀, 쇼핑몰 서비스팀 등…)으로 개편해보면 어떨까 라고 고민을 할 수 있다. 아직은 가보지 않은 길이기에 이 결과에 대해서는 현재 판단이 불가능하다. 일단 해보는거고 안되면 다시 돌아오면 된다고 생각할 수 있겠지만, 그게 돌아오지 못하는 강이 될 수도 있다고 생각된다. 단순히 조직을 바꾸는것이 아니라, 구성원의 회사생활 전반적인 것에 영향을 미칠 것이며, 그 사람의 인사평가에도 영향을 미칠 수 있고, 결과적으로 그 사람의 연봉에도 영향을 미칠 수 있다. 그 과정에서 이것을 견디지 못하고 이탈을 하는 (이직을 하는) 사람도 생길 수 있다.

이 글은 그동안 필자가 겪은 것, 읽은 것, 들은 것들에 대해서 나름대로 정리한 필자의 개인적인 의견이다. 실제로는 다양한 배경을 가진 곳에서 다양한 일이 일어날수 있으므로 이 글과 상황이 맞지 않을 수 있다. 특히 개발팀 규모가 몇백명이 넘는 큰 회사의 경우에는 전혀 맞지 않을 것이라 생각된다. 이 글은 조직의 규모가 비교적 작은 스타트업의 개발팀의 경우라 생각하고 쓴 글이다.

이 글에서 다룰 내용은 다음과 같다.

1. 기능단위 조직 vs 서비스 단위 조직에 대한 필자의 의견
2. Agile 한 조직이 되기 위해서 어떤 노력을 해야 할까 ?

1. 조직은 long term의 기간동안 함께 공유할 가치가 있으면 좋다.

조직원 (팀 단위라 가정) 들은 긴 시간동안 같은 가치를 공유하고 있는게 도움이 된다고 생각한다. 기능단위 조직 중 Backend Server 팀을 예로 들면, 그 조직원들은 모두 같은 기술스택 (개발 언어, 프레임워크 등)을 사용하고 있을 경우가 많다. 팀원 중 다른 기능단위 (web frontend, android 등)에 관심을 가지는 경우도 더러 있지만, 주력 업무를 그쪽으로 옮기는 경우는 많지 않다. 대부분 이직을 하기 전에는 해당 팀을 이동하는 경우가 많지 않다. 그래서 회사 생활을 하는 동안 팀원들과 기술스택에 관해서, 업무를 진행하다가 기술적으로 여러움을 겪을때 서로 도움을 주는 경우에 대해서 서로 이야기를 할 기회가 많을 것이다.

반면 서비스단위 조직은 상대적으로 기능단위 조직에 비해서 팀이 지속될 수 있는 기간이 짧을 것이라 생각한다. 회사의 캐시카우가 되는 서비스의 경우는 쉽게 없에지 못하겠지만, 그게 아닌 경우에는 회사의 방향, 사회적인 변화, 비지니스 모델의 변경 등 내부 조직원의 판단이 아닌 외부적인 요인에 의해서 팀이 해체 될 수도 있고, 조직원이 이동이 자주 일어날 수 있다. 이 경우 조직원들은 해당 서비스에 필요한 기획자, 디자이너, 서버 개발자, 클라이언트 개발자 등으로 서로 다른 능력을 가진 사람들로 이루어져 있다. 서비스에 대한 이해도는 기능단위 조직보다 더 긴밀할 수 있겠지만, 업무중 만나는 기술적인 문제에서는 스스로 해결이 안 될 경우 다른 팀 내의 같은 기술스택을 가진 분의 도움을 얻어야 한다.

업무 중 기술적으로 어려움을 만났을 경우, 기능단위 조직일 경우에는 다른 팀원들의 도움을 비교적 받기 쉬운데, 서비스단위 조직에서는 그게 힘들수도 있다. 조직구성과 도움을 받는건 별게라서 차이가 없을 것이라고 생각할 수 있지만, 필자가 실제로 겪어본 바로는 그러지 않았다. A팀에서는 1달째 매일 야근을 하며, 집에도 제대로 못가면서 일을 하는데 B팀은 비교적 업무의 강도가 높지 않아서 제 시간에 퇴근을 할 뿐만 아니라 업무시간의 절반 이상을 업무를 하지 않고 보내도 일정에 지장이 없을 수 있다. 이 경우 B팀원이 A팀에서 같은 기술스택을 가진 사람을 도와주려하는데 B팀 PO(project owner) 입장에서는 이게 달갑지 않을 수 있다. 다음주부터 새롭게 시작해야하는 업무가 있는데, 지금 저렇게 도와주는것이 그 전에 끝나지 않으면 본인이 계획한 것에 차질을 끼칠수 있기때문에 차라리 그냥 놀고 있더라도 A팀을 도와주지 않는 것을 더 원할 수도 있다.

그래서 이 둘의 절충안 으로는 T/F를 생각할 수 있겠다. 기능단위 조직으로 팀을 구성한 뒤, 서비스 project별로 비교적 short term 조직인 T/F를 구성한다. 일시적으로 자리를 T/F 단위로 옮길 수도 있다. 모든 스케줄은 T/F에 맞춰서 움직인다. 그러더라도 원래의 기능단위 조직원으로서의 자격은 그대로 유지한다. 주 1회 또는 스프린트 단위별로 1회씩은 기능단위 조직의 회의에 참가하여 본인의 진행사항, 어려운 점 등을 팀원들과 공유를 한다. 팀 매니저는 여유가 있는 팀원들 중 일부를 T/F에 도움을 주도록 할 수도 있다. T/F에 속한 팀원이 너무 힘들어하면 다른 팀원으로 교체를 해줄수도 있다.

• 참조 링크 : 스포티파이 조직 구조 https://congruentagile.com/2013/02/27/spotify

이런식으로 하면 좀 더 업무를 기민하게 (agile하게) 할 수 있을 것으로 생각한다.

2. Agile한 조직이 될려면…

필자가 생각하기에는 조직을 Agile하게 변화시키기 위해서는 다음과 같은 것들이 요구된다.

• 조직 간의 벽을 없에야 한다.
• 개인평가를 하지 않아야 한다.
• 그럼 어떻게 agile한 팀으로 바꿀까 ?

이것들에 대해서 하나하나 이야기를 해 보겠다.

2.1 조직 간의 벽을 없에야 한다.

이 말은 조직간의 문턱을 낮춰야 한다는 것과도 같은 말이다. 즉, 다른 팀의 업무라도 할 수 있는 융통성이 필요하다. 이건 다음에 이야기할 개인평가 제도가 없어져야지만 가능한 일이기도 하다.

예를 들어서 나는 backend 개발자이다. MSA로 시스템이 이루어져 있다. 내가 책임지고 있는 server가 다른 server를 호출하여 데이터를 가져오는 경우가 있으며, D/B를 직접 조작할 수 없다. web frontend, android, IOS에 서비스를 제공해주고 있다. 이 경우 QA 팀으로부터 버그가 리포팅 되었다. 디버깅을 하다가 버그의 원인을 발견하였다. 내가 작업한 server 뿐 아니라 client 와 내가 호출하는 다른 server의 로직도 일부 수정되어야 한다. 이 일을 어떻게 처리하면 좋을까 ?

나에게는 어느 정도 web front, mobile 쪽 개발경험도 있으며, 다른 server도 내가 작업한 server와 기술스택이 같아서 모두 내가 직접 수정이 가능하다. 하지만 다른 팀의 소스코드를 직접 수정하는건 금지되어 있다. 먼저 버그 카드를 내가 맡아서 내 server 코드 수정을 완료하였다. 그럼 이 카드를 어떻게 해야할까 ? 그래도 다른 server 개발자나 client 개발자분에게 전달을 할 수는 없다. 왜냐면 개발팀내에서 평가를 할 때 얼마나 많은 jira ticket을 처리했는지로 하기 때문이다. 그럼 각각 ticket을 추가로 만들어서 내가 맡은 버그 카드의 blocker로 등록하여 각 팀 매니저에게 전달을 한 후 적절한 담당자에게 assign을 부탁한다고 전달하였다. 이 경우 해당 매니저가 그 ticket을 보고 담당자를 배정하고 해당 담당자는 ticket을 보고 그 원인을 다시 파악해서 수정한 뒤 나에게 완료 요청을 해야한다. 이 과정이 최대한 빨리 진행된다 하더라도 내가 직접한 것보다는 느릴것이다. 더군다나 이미 하고 있는 다른 작업이 더 바쁘다고 판단하여 며칠또는 몇주까지 미뤄질 수도 있다. 전혀 기민하지 (agile하지) 못하게 된다.

다른 팀의 코드를 직접 수정하는 것에 반대하는 의견도 분명 있을 것이다. 이 경우에는 코드리뷰라는 도구를 활용하면 되지 않을까 ? 우리팀 정책상 이러이러한 것에 대해서 테스트 케이스가 작성되어야 합니다. 라고 피드백을 하면 될 것이다. 다른 팀원이 본인팀 코드에 기여하는 것이 해당 팀 평가에 안좋게 작용할 수 있다고 생각할 수도 있다. 이 경우에는 개별적인 평가를 하지 않으면 된다. 개인별 평가 보다는 팀 평가를 우선으로, 팀 평가보다는 개발팀 전체의 평가를 우선으로 하면 해결 될 수 있는 문제라 생각한다.

Jira ticket으로 평가를 하지 않는 경우라면 ? 굳이 추가로 ticket을 생성할 필요없이 현재 진행중인 버그 카드에 현재까지의 진행사항, 앞으로 해주길 바라는 것들에 대해서 이력을 남긴 뒤 다음 담당자에게 assign 하는 방법도 있다. 이러면 좀 더 기민하게 작업이 진행될 것이다.

물론 가장 기민하게 진행되는건 내가 할 수 있는 일일 경우, 내가 다른 팀 코드를 수정하여 일을 해결하는 것이라 생각한다. 이렇게 여러 팀에서 코드를 수정하는게 one time으로 해결 안될수도 있다. 몇번의 ping pong 오고가며 수정을 해야 하는 경우라면 시간이 훨씬 더 오래 걸릴 것이다.

조직의 효율적인 관리를 위해서 기능적으로 내부 팀을 나눌 수는 있어도, 그것이 너무나도 높은 벽이 되어서 다른 팀이 무엇을 하는지 알 수 없다던지, 그 팀에서 하는 일은 다른 팀원이 도와줄 수 없다던지 이런 식의 문화가 지속된다면 agile하게 일하기에는 힘들 것이라 생각한다.

2.2 개인평가를 하지 않아야 한다.

개인평가를 없애거나 최소화 해야한다. 개인평가를 하려면 상대평가를 하지 말고 절대평가를 해야한다.
아니면, 개인평가의 기준을 다르게 정해야 한다.

하지만, 매니저 입장에서는 어쩔수 없는거라 생각할 수 있다. 매년 연봉협상을 해야하는데, 그러기 위해서는 정해진 budget 안에서 구성원들을 보상해야하며, 그럴려면 상대평가를 해서 연봉상승분을 나눌 수 밖에 없다고 생각하는 것에 대해서는 충분히 이해가 된다. 하지만, 이로 인해서 팀을 agile하게 움직이게 하는데는 크게 방해가 된다.

단순히 생각을 하더라도 개인평가가 이루어지면, 평가기준에 부합되지 않는 일은 모두가 하기 싫을 것이다. 그럼 어쩔수 없이 본인을 돋보이게 하지 않는 grey zone의 업무는 팀원 모두가 히기 싫어하는데, 이걸 하지 않으면 업무가 제대로 돌아 가지 않으므로, 매니저가 직접해야 한다. 해당 팀이 제대로 돌아가지 않으면 매니저의 평가가 안좋게 되기 때문이다.

개인평가의 단점은 알겠고, 그럼 개인평가를 없애면 어떤 장점이 생길까 ?

Sprint 기간동안 개인별로 ticket을 할당 받을 것이다. 나에게 할당받은 ticket을 다 한 경우 나는 뭘 해야할까 ? 다음 sprint 에 할 ticket이나 백로그의 ticket을 하는 방법도 있고, 현재 sprint의 동료가 아직 못한 ticket을 대신해 줄수도 있다. 개인평가가 있을 경우 자신이 해야할 ticket을 다른 누군가가 도와주는 것에 대해서 내 일을 빼았아가고, 내 평가점수를 빼았긴다 라고 생각할 수가 있다. 비지니스 적으로도 다음 sprint나 백로그의 ticket보다는 이번 sprint 내의 모든 ticket들이 모두 해결되기를 더 원할 것이다.

모두의 책임은 어느 누구의 책임도 아니다 라는 말도 있다. 그 측면에서 봤을때는 위에 예로 든것이 굉장히 안좋은 케이스로 보여 질 수도 있다. 그래서 agile한 조직이 되기 위해서는 도구, 규정 같은것 보다는 문화, 공감대가 중요하다 생각한다. 제도적으로 우리는 개인평가를 하지 않을거야라고 하는것에 선행되어서 우리 모두는 각자 최선을 다해 업무에 임한다라는 믿음이 필요하다. 만약 개인평가를 하더라도 개인평가의 기준이 정량적으로 얼마나 일을 열심히 했나가 아니라 얼마나 조직의 공통의 목표를 위해서 노력해 주었나로 하는 방법도 있겠지만, 이보다는 모든 구성원이 서로 신뢰를 하는 문화를 구축하는게 더 중요하다 생각한다. 뒤에 이야기 하겠지만, 그렇다고 갑자기 전혀 그렇지 않은 문화에서 갑자기 이렇게 바꾸는건 힘들다. 그래서 단계별로 진행함에 있어서는 이렇게 평가기준을 바꾸는 것도 좋은 방법이라 생각한다.

꼰대스러운 표현일지는 모르겠지만, 이게 요즘 젋은 친구들에게는 안먹힐 수도 있다. 개인의 커리어가 굉장히 중요하며, 내가 좀 더 좋은 커리어패스를 가지기 위해서는 좀 더 돋보이는 일을 해야한다고 생각하는 젊은 친구들이 많을 것이다. 이건 비단 젋은 친구들 뿐아니라 이렇게 생각하는 사람이 많을 것이다. 이 생각을 고치는 것이 쉽지는 않다. 매니저들은 어떻게 팀의 가치를 높이는 것이 본인의 커리어패스에도 도움이 되는 것이라고 설득해야 할까 ? 이건 사실 나도 아직 해답을 모르겠다. 좀 더 깊이 생각해야할 문제인것 같다.

박계홍님의 피드백이 있어서 아래 부분을 추가했다.

애자일한 조직이 되기 위한 개인평가 관련 문제는 소시오크라시에 흥미로운 평가 방법이 있다. 애자일에서 추구하는 것과 연결되어 있다. 마침 비상 교육의 value-up 평가 시스템에 대한 영상이 있어서 소개하겠다.

• 참고로 2020년 5월 현재 소시오크라시 국대 전파교육 및 기업컨실팅을 하는 유일한 기관은 링크컨설팅 (http://liink.co.kr)이다.

2.3 그럼 어떻게 agile한 팀으로 바꿀까 ?

Agile한 팀으로 바꾸기 위해서는 굳은 결심이 필요하다. 그래서 여러가지 도구, 법칙들을 정하고 팀원들이 모두 따르도록 강제화 해야한다.

이런식으로 접근을 해서는 성공하기 힘들다. Agile은 문화다. 라는 말이 괜히 있는게 아니다.

최종적으로 우리팀의 모습은 이러이러할 것이다 라고 최종목표를 설정하는 건 굉장히 중요하다. 하지만 이걸 한번에 하려고 한다면 거기에 반발하는 구성원이 있을 것이며, 이들을 설득하면서 진행하는건 여간 힘든 일이 아닐 것이다.

최종목표를 설정했으면, 그 최종목표에 해당하는 세부 사항들에 대해서 현재의 상황과 비교를 해보아야 한다. 그래서 그 사이에 거쳐야 할 단계를 비교적 세분하게 설정을 한다. 그래서 그걸 한 단계씩 변화를 주면서 충분히 구성원 대부분이 따라왔다 생각되면 그 다음 단계를 진행하고, 이런식으로 기간을 길게두고 차츰차츰 진행해야 성공률이 높을 것이라 생각한다.

매니저 혼자만의 생각으로 진행하는 것도 쉬운일이 아니다. 팀내 조력자를 충분히 만들수록 성공률이 높아질 것이다. 본인이 생각하는 가치, 앞으로 변화시키고자 하는 방향 등에 대해서 모든 팀원과의 공유가 아니더라도 믿을 만하고 본인을 도와줄 수 있는 사람들과 먼저 공유를 하고, 그들의 의견을 듣고 수정한다. 그 뒤 구성원 모두에게 공유하고 그들의 피드백을 듣고, 진행하면 좋을 것이다.

외부 전문가의 도움을 얻거나, 교육을 받는 방법도 충분히 검토해 볼만하다. 이렇게 외부 전문가의 도움을 받더라도 100% 성공한다 장담을 못한다. 그런데, 외부 전문가의 도움없이 진행하는 것이 과연 성공률이 얼마나 높을 수 있을까 ? 이게 성공하지 못한 경우 어떻게 될까 ? 팀내 부적응자, 반대하는 사람들의 업무효율은 어떨까 ? 마음에 안들어서 떠나는 사람은 생기지 않을까 ? 그 모든 경우를 다 고려한다면, 비용을 지불하라도 전문가에게 교육을 듣고, 컨설팅을 받는게 가장 저렴한 비용으로 성공률을 높일 수 있는 방법이 아닐까 생각한다.

마치며…

최근 이직을 했는데, 이전 팀에서 굉장히 agile하게 일하는 경험을 겪었다. 나에게 있어서는 정말 소중한 경험이다. 대부분의 스타트업 개발팀은 해결하지 못하는 뭔가 모르는 비효율성이 있다 생각할 것이며, 이걸 해결하기 위해서 뭔가를 해야겠다고 생각하는 매니저분들이 많을 것이라 생각한다. 그 분들에게 작으나마 나의 의견을 전달하고 싶어서 이 글을 적었다. 내 글이 그들의 마음을 움직이기에 충분히 설득력있다고 생각하지는 않지만, 그냥 이런 의견이 있으니깐 한 번만이라도 이런 측면도 생각을 해 줬으면 하는 맘에 이 글을 적었다.

p.s. 사실 이 글은 굉장히 전문적이지 못한 아마추어적인 글이라 생각합니다. 혹시 이 글을 보시는 해당 분야 전문가분들 중 잘못된 내용에 대해서 피드백이나, 다른 의견에 대해서 피드백은 언제나 환영합니다. 저도 아직 배울게 많다 생각하기에 많은 가르침 부탁드립니다.

이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :)