깔때기 구조로 일하기
한 번에 한 가지씩
걱정
케타포에 출근한 지 이제 3달이 되었다.
처음 입사했을 때는 지난 15여 년 동안 다녔던 Daum, SK(11번가)과 너무 달라서 내가 잘할 수 있을까?라는 걱정이 많이 들었었다. 자신감이 최하였을 때 스스로 "나는 할 수 있다"는 최면을 걸고, 먼 미래보다는 매일매일 조금씩 나아지게 만들자는 생각으로 생활을 했다.
5명이 5가지 일을 동시 수행
입사 당시 개발본부는 인원은 매우 적은데 팀은 꽤 여럿으로 나눠져 있었고, 일도 동시에 진행되는 것이 꽤 있었다. 많은 일을 동시 진행하는 것은 경영진이나 현업(운영, 영업, 물류 등)에서 요청한 일이 많아서였던 것 같다. 나도 입사한 지 얼마 안 되었을 때라 뭘 못하겠다는 말을 하기 어려웠다. 아마 내게 일을 요청하시는 분들도 이 정도는 내가 할 수 있으리라 생각하시고 요청하셨을 수도 있다.
[그림 1]. 병렬 수행(세로 선: 업무)이렇게 병렬 수행을 하게 되면 한 사람이 n개의 일을 하므로, 진행 중이던 업무를 멈추고 다른 업무로 전환 때 콘텍스트 스위칭(context switching)으로 쓰래싱이 발생해서 효율이 저하된다. 그리고 내가 다른 어떤 일을 하고 있을 때 다른 사람이 내게 뭔가를 요청하면 나는 내 일을 마치고 그 일을 도와주는 경우가 발생할 텐데 이때 다른 사람에게는 대기가 발생한다.
또 조직 문화를 고려해 보면 과거의 경험상 이런 경우 업무의 품질이 낮아지고 팀워크가 없어져서 소속감이 떨어지고 구성원 이탈이 많았던 문제가 있었다. 서로 다른 일을 하고 있고, 다른 팀원이 무슨 일을 하는지 잘 모르고, 그래서 그 팀원에게 미안한 마음(관심이 없는 것 같아서)이 생기고... 우린 왜 같은 팀일까? 서로 함께하는 것이 없는데. 이런 생각은 우리 팀의 미션은 뭔가? 존재 이유는 뭔가? 이런 생각으로 발전하여 조직을 위태롭게 할 수 있었다.
전환점
답을 찾지 못하고 어떻게 할까를 고민하고 있었다. 그러다 NCT 신보가 나와서 3일 연속으로 이벤트를 할 때 트래픽을 못 받아서 장애가 났었다. 이때 이 장애 소식이 웨이보 실검 8위에 오를 정도로 케타포의 장애는 영향력이 있었다.
그런데 장애를 해소할 수 있는 방법이 없어서 그저 트래픽이 빠지기를 기다리는 것뿐이었다. 이때 개발본부 구성원들 중의 일부는 현업들이 장애에 민감하니 우리가 좀 더 조심하자는 글을 게시판(팀즈)에 작성했다. 나는 그 글을 보고 "외발 자전거로 피자를 배달하다 떨어뜨린 배달원은 잘못이 없다"는 답글을 달면서 죄책감을 갖지 말자고 했었다.
이후 대표님과 우리가 지금 새로운 기능 추가에 열중하기보다 안정화에 힘을 써야 할 것 같다고 말씀을 드렸고, 동의를 얻었다. 내가 올해 읽은 책 중에 최고로 꼽는 "프로젝트에서 제품으로"에 있는 내용 중에 초기에 사업의 가능성을 입증하기 위해 많은 기능을 추가해야 하지만 품질, 기술 부채 관리를 등한히 하면 곧 결함이 생기고, 계속 방치하면 위험해지고, 심지도 회사가 망할 수도 있다는 부분을 잘 정리해서 대표님에게 보여드려 동의를 얻을 수 있었다.
이후에 나는 "깔때기 구조로 일하기"라는 방식을 경영진과 구성원들에게 설명하고 그렇게 일하기 시작했다. 이 방식은 내 생각에는 애자일의 스쿼드와 크게 다르지 않다. 다만 우리가 충분히 애자일 하게 멋지지 않기 때문에 스쿼드, 챕터, 트라이브 이런 얘기로 풀기는 부족했다고 생각했다.
[그림 2]. n개의 일을 한 번에 하나씩 m명이 수행(협업/협력)"깔때기 구조로 일하기"로 일하기의 핵심은
n개의 일을 m명이 할 때 가장 중요한 일부터 m명이 한 가지씩 함께 하기
일에 사람을 할당하는 것이 아니라 조직(사람)에 일을 할당하는 것
이였다.
이를 통해 각자 따로 일하는 것이 아니라 함께 일하고, 조직(사람)에게 유사한 업무를 계속 수행하게 하여 전문성, 역량을 축적하자는 것이었다. 또 함께 일하며 팀워크를 높이고 한 번에 한 가지씩 일하면서 몰입을 통한 행복을 느끼고, 모두가 한 가지 일에 몰입하여 대기를 없애고자 했다. "[그림 1]. 병렬 수행(세로 선: 업무)" 방식으로 일 할 때는 n%로 완료된 m개의 일을 관리해야 해서 뭔가 마무리되지 않은 느낌으로 일하게 된다. 이로 인해 개발이 완료되어 배포되지 전까지 해당 업무의 기획, 개발자 등은 성취감을 느끼기 어렵다. 하지만 "[그림 2]"와 같은 방식으로 일 할 때는 100% 완료된 p개의 일은 배포는 후에 되더라도 서로 동작하는 것을 확인할 수 있어서 성취감을 느끼며 새로운 일에 몰입할 수 있는 장점도 있다.
특히 케타포에는 오래 다녔던 개발자분들은 많이들 이직을 하셨고, 업무 지식이 적은 신규 입사 개발자들이 많았기에 혼자 일하기 어려운 분들이 많았다. 이 방식은 꽤 성공적이었다. 업무 지식, 개발 역량이 부족한 분들이 좀 더 나은 분들과 협업을 하며 성장하고 작게라도 기여할 수 있게 되었다. 그 전에는 실질적인 기여가 없는 일들만 하면서 자존감이 떨어져서 눈치만 보고 있던 것 같은 분들의 표정에 미소가 보이고, 사소한 일이지만 본인들이 기여하고자 적극적으로 참여하는 모습들이 보였다. 또 업무 지식이 있는 분들은 이제 좀 쉬운 일들은 신규 입사자들이 처리하게 되어 좀 더 난이도가 있는 일에 전념할 수 있었다.
주니어(혹은 신규 입사) 기획자분들도 깔때기 구조로 같이 일하면서 개발자들과의 협업이 증가하면서 도메인 지식, 개발 지식이 증가하기 시작했고, 본인들이 회사에 가치로 기여한다는 것을 느끼며 성취감이 늘었고, 개발 관련 지식이 늘어나는 것에 만족을 보이기 시작했다. 그전에 여러 팀으로 나눠 일을 할 때는 "기획이 부족해서 개발을 할 수가 없다"는 등 기획자에게 공격적인 언사를 해 기획자들이 위축되었었다고 한다. 그래서 주니어/신규 기획자들은 자존감이 떨어져 눈치를 보여 어렵게 회사 생활을 했었던 것 같다.
속도
이렇게 일할 때 속도가 문제가 될 수 있을 것 같다. 하지만 깔때기에 일이 들어왔을 때 모든 구성원이 깔때기에서 지금 수행하고 있는 한 가지 일에 집중한다면 대기를 없애서 속도를 개선할 수 있다고 생각한다. 기획자들이 기획서를 개발자들에게 전달한 후에 다른 업무를 기획하는 경우를 종종 봐 왔다. 이럴 경우 개발자들이 개발을 하면서 궁금증이 생겨서 기획자에서 문의를 하면 기획자는 다른 기획을 하고 있기 때문에 개발자들은 대기에 빠진다. 최근의 모든 회사에서 가장 큰 병목 자원인 개발자가 대기를 하게 되는 것이다. 하지만 깔때기 구조에서는 관련 기획자들이 기획을 완료했다고 하더라도 깔때기에서 수행 중인 업무에 자신들이 도울 일을 찾으려 노력하여 기여한다면 대기가 사라져 속도가 증대될 것이다.
칸반 보드
마지막으로 스크럼이 아니라 칸반 방식으로 업무를 진행하여 효과를 보고 있다. 아직 케타포의 개발 조직은 일정 추정에 익숙하지 못하다고 생각한다. 기술 역량이 아니라 도메인 지식이나 회사의 업무 방식에 익숙지 않아서... 몇 차례 반복을 해야 추정 값이 의미 있어질 것으로 여겨진다.
그래서 우리는 칸반 방식으로 업무를 진행하고 있다. 이를 통해 중요한 업무가 대기하고 있지는 않은지, 완료된 업무가 배포가 느려지고 있지는 않은지 등을 관리하고 있다(잘 가요 스크럼, 반가워요 칸반 참고). 이 방식 또한 우리가 확신을 가지고 점점 나아지는데 도움이 되고 있다.
마치며
나는 지난 15년 정도를
개발 역량 증대를 위해 교육, 리뷰 등을 하고
회사의 주요 개발 관련 방향성을 수립하고
구성원들과 소통하여 한 방향으로 나아가게 하고
경영진과 개발자들 간의 가교 역할을 통해 회사의 개별 관련 업무에 기여
해 왔다. 좀 상위의 일, 추상적인 일 들만 해 왔다.
지금 케타포에서는 SQL도 작성하고(주로 Zeppelin에서), 코드도 작성하고, 커밋도 하고, PR도 생성하고, 배포도 하고, 장애 대응도 하고 있다(Java만 하다고 aws, sql, python, react 등도 보고 있다).
이런 나의 생활이 다소 힘들 때는 있지만 뭔가 실질적인 일로 기여하고, 또 향후 나의 커리어에도 도움이 된다고 생각이 되어 즐겁게 생활하고 있다.
이렇게 즐겁게 된 이유 중에 가장 큰 하나를 꼽자면 아마 각자 알아서 일하는 것이 아닌 함께 서로 배움을 주고받으며 일하는 "깔때기 방식으로 일하기"가 일 것이라고 생각하여 이 글을 작성한다.
