[Kernel360] 커널팀의 협업 과정

서론

---

Kernel360에서 프로젝트를 진행하며, 기자단으로 활동하게 되었습니다.

본 포스트를 위해 E2E 프로젝트를 마무리하고, 총 6개 팀의 팀장들과 인터뷰를 통해 협업 과정에 대해 알아보는 시간을 가졌습니다.

누군가는 아쉬웠고, 누군가는 만족했고, 누군가는 열정이 넘쳤던 커널인들의 협업에 대해 알아보는 시간을 갖도록 하겠습니다.
편의상 팀장 A, B, C, D, E, F 로 칭하겠습니다.

팀장들의 의견을 얻기 위해 열심히 슬랙을 돌렸다.

본론

---

팀장들이 생각하는 협업이란?

---

A 팀장	팀원들이 거리낌 없이 의견을 내놓을 수 있는 환경에서 함께 일하는 것이라 생각합니다.
B 팀장	각자의 능력치에 맞는 task를 분담하고, 팀원에 대한 이해를 기반으로 서로 부족한 부분을 보완하며 같은 방향으로 나아가는 것으로 생각합니다.
C 팀장	같은 목적을 가지고 문제를 해결하기 위한 작업이라고 생각합니다. 해결하는 과정을 위한 규칙도 마찬가지입니다.
D 팀장	업무를 나누고 진행함에 있어 원활하게 각자의 의견을 주고 받고 서로의 진행사항 및 고충을 잘 이해하려는 노력 속에 협업이 있는 것 같습니다. 그런 과정을 기반으로 각자의 맡은 역할을 잘 수행하고 공유하며 시너지를 낼 수 있다면 좋은 협업이 아닐까 생각합니다.
E 팀장	제가 생각하는 협업이란, 모두가 자기 일에 집중할 수 있는 환경에서의 업무가 협업이라고 말할 수 있을 것 같습니다. 서로의 역할에 대해서 이해하고 공유하고 배려하면서 적극적으로 참여할 때에 그 가치가 실현될 수 있을 것이라고 생각합니다.
F 팀장	자유롭게 의견을 나누며, 사소한 것도 지나치지 않고 좋은 프로덕트를 위해 적극적으로 소통하며 상호 배려하는 것이 협업이라고 생각합니다.

커널 360에서 매우 중요하게 여겨지는 '협업'에 대해 커널 크루들의 의견은 대동소이 했습니다. 한마디로 정리하자면, "목표 달성을 위한 원활한 문제 해결 과정" 이라고 말할 수 있겠네요.

혼자 개발하는 시대는 지나고, 소통이 적극적으로 이뤄지는 개발의 시대가 도래했기 때문이지 싶습니다.

실제로 E2E를 하면서 협업이 잘 이뤄진 것 같나요?

---

A 팀장	저희 팀은 모든 부분을 팀원 별로 한번 씩은 맡도록 진행했습니다. 따라서 서로가 지금 하고 있는 일에 대한 이해도를 높여 한 사람이 프로젝트를 떠맡지 않아도 되고, 다른 팀원이 하고 있는 일을 알고 있기 때문에 자신의 일에 온전히 더 집중할 수 있었던 것 같습니다.
B 팀장	나름 그래도 잘 진행된 것 같아요. 제가 팀장이 되었을 때 가장 첫번째 목표가 팀원들이 팀에 대해서 만족도를 75% 이상 가지도록 하자였고, 그러기 위해서는 협업이 만족스럽게 이루어져야 한다고 생각했습니다.  팀원 모두 각자의 기술적인 성장에 대해 욕심이 있으셔서 그런 부분을 채울 수 있도록 task를 적당히 분배하려고 노력했습니다.
C 팀장	잘 안되었던 것 같습니다. 협업하기 위한 규칙들을 정해놓지 않고 구현에 빠르게 들어갔고 그 과정에서 마주친 문제를 해결하는데 시간을 많이 소모하였습니다. 뒤늦게 다른 팀들 처럼 스크럼, PR 템플릿, 리뷰어를 도입했지만 시간에 쫓겨 잘 지키지 못했습니다.
D 팀장	소통의 측면에서는 잘 된 것 같지만, 초반에 코드 리뷰 방식이나 상호 간에 코드 설명이 부족한 부분이 있어 진행 중인 내용에 대한 이해는 조금 떨어졌던 것 같습니다. 그래도 후반에는 멘토링 전 사전리뷰 및 코드 공유 시간을 가지며 협업 방식이 발전했다고 생각합니다.
E 팀장	e2e를 하면서는 협업을 하는데에 아무래도 다른 프로젝트를 진행했을 때에 비해 유리했다고 생각해요. 실제 현업에서는 프론트엔드부터 시작해서 기획자, 디자이너 등등 더 다양한 사람과의 협업이 필요한데에 비해 이번 프로젝트를 진행할 때엔 백엔드 개발자들 끼리 프로젝트를 진행했다보니 서로를 더 잘 이해할 수 있고 그런 부분에서 협업을 하는데에 순조로웠던 것 같아요.
F 팀장	팀원들의 적극성이 조금 떨어져서 일방적인 워터폴 방식으로 진행됐던 것 같습니다. 이러한 참여도를 이끌어 내는 것이 팀장의 몫이었는데, 제가 이 부분을 잘 해내지 못한 것 같아 많이 아쉬웠습니다. 또한 다른 팀들과 마찬가지로, 본인이 구현한 것 외의 로직은 이해도가 많이 떨어져서 제가 생각했던 협업의 기대치엔 못 미쳤던 것 같습니다.

의외로 의견이 갈렸던 질문이었습니다.
어떤 팀은 잘 된 것 같지만, 만족스럽지 못하다는 의견도 꽤 있었습니다.
커널360의 목표는 '분업'이 아닌 '협업' 이었기 때문에, 다소 생소한 분들이 많았던 것 같습니다.

분업 : 내가 맡은 일만 잘하기
협업 : 내가 한 일 외에도 다른 팀원이 작업한 내용도 알아야 하는 것

이라고 OT시간에 이민석 학장님이 말씀해주셨습니다.
대부분의 사람들은 분업에 익숙해져 있기 때문에, 시행착오를 겪지 않았을까 싶네요.

어떤 방식으로 협업을 진행했나요?

---

A 팀장	프로젝트 전체 기능에는 다양한 Security, 기능 CRUD, 등등 세부 작업들로 나누고 해당 부분들을 한번씩 맡도록 하였습니다. 이로 인해 팀원들이 너무 한 작업에 몰두 하느라 작업에 대한 피로감을 느끼지 않도록 하였습니다. 너무 온전히 한 작업에만 집중하면 프로젝트를 큰 그림을 이해하는데 방해가 될 수 있기 때문에 이런 방식을 선택했습니다.
B 팀장	저희는 여러가지 장치를 짧고 굵게, 최대한 효율적으로 사용하려고 했는데요ㅎㅎ. 모두가 효율적인 걸을 아주 좋아하거든요. 스크럼, 정기 스프린트, KPT 팀 회고를 사용해서 전체적인 구조를 잡고 상세한 것은 github issue, milestone, github project 칸을 활용했습니다. 스크럼을 통해서 매일 러프하게 본인의 할 일을 상기하고, 정기 회의로 2-3일의 스프린트 기간동안 내가 할 일을 할당받고, KPT 팀 회고를 통해서 모두가 원하는 팀 분위기로 수렴시키고자 했어요. 그리고 내가 할 일에 대해서는 issue를 통해서 , 한 일에 대해서는 pr을 통해서 상세하게 전달하고자 했습니다.
C 팀장	협업에 필요한 기술은 위와 같이 사용하였으며 업무의 경우 맡은 역할을 분배 후 완료하면 도와주는 형식으로 진행하였고 소통은 문제가 생기는 즉시 팀원들에게 보고하는 형식으로 하였습니다.
D 팀장	매일 오전 스크럼 회의를 통해 맡은 업무에 대한 진척 및 진행예정 업무를 상호간에 공유하였고, 여러 조언을 통해 PR 리뷰에 대한 방식을 발전시켜왔습니다. 또한 멘토링 진행 전 질문에 대한 사전 리뷰 시간 및 코드 공유 시간을 통해 최대한 많은 정보를 공유하고 이해할 수 있도록 시간을 가졌던 것 같습니다. 추가로 업무 분담을 정할 때, 가능한 균등하고 흥미로운 주제를 나눠가질 수 있도록 남은 업무를 리스트업한 후 함께 분담했습니다.
E 팀장	저희는 우선 일단위 / 주단위로 스크럼 시간을 가져서 서로의 일을 나누고 또 문제나 해결점을 공유하는 시간을 가지는 것에 시간을 많이 쏟은 것 같아요. 이런 시간을 통해 서로 무슨 일을 하고 있는지, 내가 무슨 일을 해야할지를 알고 이를 통해서 어떻게 작업하는 것이 서로가 작업하는데에 더 편할 수 있을까를 알게 된 것 같아요. 그리고 무엇보다 주단위로 목표를 설정할 때, 일주일 동안 할 수 있을 것 같다고 판단한 목표 기준 50% 정도의 일을 목표로 잡고 일을 배분하도록 노력한 것 같아요. 이것을 통해 구현하는데에 모든 시간을 쓰기보다는 테스트를 통해 검증하고 리팩토링을 통해 더 좋은 코드로 만들기에 힘을 쓸 수 있었어요.
F 팀장	소통의 자율성에 최대한 집중했습니다. 매일 오전 일과 시작과 동시에 스크럼을 진행했고, 현재 작업 내용 및 진행도, 이슈가 발생하면 즉각 보고해서 작업자 뿐 아니라 다른 팀원들도 해당 이슈를 인지할 수 있도록 독려했습니다. 그리고 PR과 코드리뷰도 절대 대충 작성하지 않고, 클린한 코드를 위해 서로의 코드를 깐깐히 봐주고자 노력했습니다.

협업의 방식은 여러가지가 있었습니다. 특히 A 팀의 방식이 인상깊었는데요, 이렇게 직접 도메인을 번갈아가며 직접 작업을 수행하면 이해도가 훨씬 높아질 것 같았습니다.

기존에 개발되어 있던 내용에 대한 러닝커브에서 오는 피로감은 어쩔 수 없지만, 협업의 완성도를 위해서라면 불가피할 것 같습니다.

또한, 개인적으로 제가 생각하는 협업의 이상에 가장 근접한 팀이 있었는데요, 해당 팀은 PR에서 서로의 코드를 궁금해하고, 설명해주는 모습이 인상깊었습니다.

개인적으로 PR을 통한 소통과 협업이 가장 잘 이뤄진 팀이라고 생각했습니다.

B, D, F 팀은 스크럼을 통해 진행상황을 공유하면서 소통에 포커스를 맞춘 것이 특이점이라고 볼 수 있겠습니다. 

많은 사람들이 아쉬워 하는 것 중 하나가 '자신이 작업하지 않은 내용에 대한 낮은 이해도' 였는데요.
이걸 해결하기 위해 어떤 노력을 하셨나요?

---

A 팀장	위와 같습니다.
B 팀장	저희도 겪었던 문제인데요. 물론 기술적 성장에 대한 욕심이 있기도 했지만 코드 리뷰를 하려면 해당 코드의 전반적인 기술 지식을 알아야했기 때문입니다. 그래서 저희는 일주일에 한 번 정도, 새로운 feature를 붙일 때는 팀 내 세미나를 통해서 기술적 동기화를 하려고 했어요. 그리고 코드리뷰를 하면서 이해가 안간다! 싶으면 팀원에게 양해를 구하고 질문을 하기도 했습니다.
C 팀장	저희팀의 경우 코드 리뷰, 기능 명세서의 부재로 낮은 이해도는 당연한 결과였습니다. 이것을 극복하기 위해 자신의 작업한 분량을 서비스 흐름대로 설명하였습니다. 내용은 입력값, 출력값 어떤 역할을 하는지 화면과는 어떻게 상호작용하는지 등등 그동안 소통의 부재를 해소하기 위해 하루종일 리뷰만 하였습니다. 결과적으로 완벽하게 해결되지 않았지만 가장 효과가 있었습니다.
D 팀장	초반에는 PR 코드 리뷰 및 간단한 구두 설명을 통해 내용을 이해하고자 했으나, 단편적인 부분이 있고 자리에서 진행되다보니 전체 공유가 어려운 경우도 있어 코드 공유를 하는 시간을 별도로 가졌습니다. 전체 흐름에 대한 설명을 듣고 이해가 안 가거나 설명이 필요한 부분에 대해 질문할 수 있고, 코드를 작성한 당사자도 피드백을 듣거나 다른 방식에 대한 지식을 얻어갈 수 있어서 좋았다고 생각합니다.
E 팀장	무엇보다 제가 잘 알려고 노력했던것 같아요. 팀장으로써 모든 프로젝트에 대해 파악을 하고 있다면 각 팀원에게도 프로젝트의 전반적인 진행 사항에 대해 설명을 할 수 있고 일을 나누고 일의 우선순위를 정하는데에 도움이 될 것이라고 생각했어요. 이를 통해 모든 팀원들이 각자가 각자에게 물어보기보단, 저를 통해서 스크럼 시간을 통해서 서로 공유를 하다보니 모두가 빠르게 습득할 수 있었던 것 같아요. 물론 이게 정답이라곤 생각하지 않아요. 팀장이 부재하거나 팀장이 파악을 못하는 문제가 생겼을 때에 대처할 수 없다는 단점 또한 존재했거든요.
F 팀장	이 부분은 많이 아쉬웠던 것 같아요. 기능 구현에 급급해서 플로우만 공유하고 넘어갔던 것 같습니다. 백은 시간을 핑계로 저희가 소홀했던 것도 있지만, 프론트의 경우 사전지식이 거의 없는 경우가 대부분이라서 잘 이뤄지지 않았습니다.

많은 크루분들이 가장 문제삼았던 내용입니다.

비단 저희 커널360 크루뿐만 아니라, 다른 프로젝트를 진행하는 개발자들분들, 그리고 제가 회사에서 업무를 진행하며 느꼈던 점들이었는데요, 본인의 작업사항 외엔 잘 알지 못하는 것이었습니다.

이러한 문제 해결을 위해 크루들이 선택한 방법은 "시간 내서 소통하기" 라고 볼 수 있겠네요.

알고리즘과 마찬가지로, 프로젝트를 하면서 이러한 팀원 간의 로직 공유 부재는 시간을 따로 내서 해결해야만 하는 것 같습니다.

파이널 프로젝트 때는 어떤식으로 협업을 업그레이드 하고 싶으신가요?

---

A 팀장	위와 같은 방식을 채택했다 하더라도 여전히 모든 팀원들이 모든 작업에 관여하게 할 수는 없었습니다. 따라서 이 부분을 조금 보완하여 파이널 때는 가능하다면 더 많은 작업을 팀원들이 경험하여 온전히 자신의 것으로 만들게끔 하고 싶습니다.
B 팀장	파이널 프로젝트 때는 코드리뷰를 좀 더 자세히해서 코드에 대한 책임을 더 많이 나눠가지도록 하고 싶고요. 그리고 github project 말고도 다른 협업툴을 한번 만져보고 싶네요! 그리고 그동안은 촉박해서 한 기능에 대해서 혼자 개발했는데 파이널 때는 시간이 된다면 하나의 (큰) 기능에 대해서 팀원과 같이 고민하면서 더 좋은 방향을 선택하서 구현하는 협업을 해보고 싶습니다.
C 팀장	협업 방식에 정답은 없지만 e2e처럼 진행되지 않았으면 좋겠습니다. 개인적으로 하나의 서비스가 도출되기까지 시간대별 역할이 분명하다고 생각합니다.    ex) 기획(기능 명세서) -> 디자인(서비스 브랜딩), 설계(DB 설계), 개발 환경 구축 -> 확정된 기획부터 개발 창업의 목적이 아니라면 회사에 속한 협업방식을 사용해야 하기 때문에 협업 방식에 리소스를 투자하는 것보다는 각 단계별로 해야할 일에 집중했으면 좋겠고 그렇게 하고 싶습니다.
D 팀장	파이널 프로젝트 때는 프로젝트 기간 및 개발할 양이 더 방대하기 때문에 코드 공유 방식, 컨벤션 등 각종 논의 사항을 초반에 잘 자리 잡을 수 있도록 한다면 개발과 협업에 모두 도움이 될 것 같다고 생각합니다. 추가로 E2E보다는 긴 흐름으로 돌아가고 실제 운영을 해볼 수 있으니 좀 더 스프린트 단위를 잘 나눠서 애자일하게 협업을 경험하고 싶습니다.
E 팀장	파이널 프로젝트에는 무엇보다 코드 리뷰에 조금 더 힘을 쓸 것 같아요. 프로젝트를 마무리하고 보니 남는건 그것 뿐이더라고요. 코드리뷰 하는 시간이 물론 프로젝트를 진행하는 과정에 있어서는 많이 낭비되는 시간 같고 답답하기도 했는데, 그렇게 리뷰를 하고 잘못된 점을 파악하면 서로의 코드를 더 이해하게 될 뿐더러 리뷰를 받고 그 사람이 성장하게 되면서 결국에는 생산성 증가라는 결과를 가져오게 되더라구요. 그리고 글로써 남기는 습관을 가지도록 노력할 것 같아요. 스크럼을 통해서 나누는 시간을 자주 가졌지만 말로써 전달한 것은 결국 잊혀지기 마련이라고 생각해요. 까먹더라도 다시 확인할 수 있도록 글로써 공유하는 문화를 가진 팀이 되었으면 좋겠어요.
F 팀장	엄격한 코드리뷰와 PR이 초반엔 잘 지켜졌지만, 중후반부터는 흐지부지 된 것 같습니다. 코드리뷰를 '평가'의 자리보다는 자신이 개발한 내용을 PR로 '설명'하는 문화를 형성함으로써, 다른사람들이 내 코드와 PR에 적힌 설명을 보고 "이렇게 개발했구나!" 를 직관적으로 알 수 있게끔 하는 협업 문화를 구성하고자 합니다. 이렇게 되면 따로 시간을 내서 설명하는 시간도 줄일 수 있고, 다른 사람이 읽기 쉽게 고민하면서 글을 쓰기 때문에, 담당자 본인도 이해도가 한층 더 높아질 것이라고 생각합니다.

개발자로서의 협업의 '이상'에 다가가고자 하는 의견도 있는 반면, 현실적인 문제(대부분 시간이겠죠?)로 회의적인 시선으로 바라보는 팀도 존재했습니다.

항상 더 나은 개발 문화 형성을 위해 고찰하는 팀장님들의 의견을 들을 수 있는 뜻깊은 시간이었습니다.

마치며

---

이렇게 커널360 크루들의 협업 과정에 대해서 알아봤습니다.

개발이란게 그런 것 같습니다.

늘 우리는 '성장'에 목말라있고, 기술적인 한계를 뚫고 '이상'에 다가가려고 합니다.
하지만 여러 이해관계가 얽힌 현실에서 이러한 기술적인 이상에 근접하기란 여간 쉬운 일이 아닙니다.
그렇기 때문에 회사에서도 신기술이라고 무작정 도입하지 않고, 기술 도입을 신중하게 항상 고려하는 것이겠지요.

커널360 크루 뿐만 아니라, 모든 개발자 분들이 이상을 좇되, 현실적인 Trade-Off를 고려해 합리적인 판단을 내리는 개발자가 되길 희망합니다. 저 또한 그렇게 되고싶구요 :)

커널360 크루의 성장은 앞으로도 계속됩니다!