안녕하세요 ~ 오늘은 알티모빌리티의 개발자들이 역량 개발을 위해 어떤 방식으로 교류하고, 공부하는지 소개해보려 합니다.
지난 상반기, 주야불철 개발하는 와중에도 공부를 손에서 놓지 않기 위해 사내 스터디를 연 팀이 있는데요!
바로 B2B 커뮤니티 카셰어링 서비스 ‘카플랫 비즈’를 개발하는 서비스개발 1팀입니다. 서비스개발 1팀은 포지션마다 다른 언어로 개발을 하는데, 이번 스터디는 javascript (& node.js) 와 typescript 를 사용하는 웹 프론트와 서버 개발자들이 모여서 진행했다고 합니다.
그럼 기술적인 내용으로 들어가기 전에, 이들이 무엇을 위해 스터디를 시작하게 되었는지, 그 계기부터 한 번 알아볼까요?
스터디가 필요했던 이유
지난 1월, 서비스개발1팀은 큰 프로젝트를 앞두고 이것저것 분주하게 준비하게 되었습니다.
카플랫 비즈의 기반이 되는 플랫폼인 알티모빌리티의 라이디어 (RAiDEA) 버전 마이그레이션과 더불어 앱 전체 리뉴얼을 앞두고 있었기에, 프론트 뷰 (view) 와 서버 API 를 전부 뜯어 고쳐기 위한 사전 준비 작업이 한창이었죠. 기존 코드를 검토하며 버릴 부분과, 수정/개선될 부분, 아예 새로 만들 부분을 분류하기도 하고, 신규 서비스에서 로직이 유실되지 않도록 주요 로직들을 도식화하기도 했습니다.
그런데 말입니다. 기존 코드를 뜯어볼수록 한숨이 점점 깊어졌습니다.
의미를 알 수 없는 변수들, 급한대로 덧입혀 쓴 정리되지 않은 코드, 주석조차 달려 있지 않은 수백줄 단위의 함수들, 기획팀의 정책 문서와 맞지 않는 세부 로직들... 한 마디로 '혼돈의 카오스' 였달까요. 오랜 시간 쌓이다 보니 결국엔 흔히 말하는 '스파게티 코드' 가 점점 많아졌고, 이를 어디서부터 어떻게 정리해야할지 감이 잡히지 않았습니다.
그래서 프로젝트 준비 기간 동안 팀원들 모두가 자료 조사를 하고 공부하며 기존 코드를 잘 정리하고, 개선하기 위한 방법들을 고민하게 되었습니다. 시간이 여유로울 때는 서로를 등지고 있던 의자를 빙그르르 돌려 마주보며 수다를 가볍게 나누곤 했는데, 수다를 떨다 보니 각자의 고민의 중심에는 "더 좋은 코드를 쓰기 위한 리팩토링 (refactoring)" 이라는 공통 주제 있다는 것을 알게 되었습니다. 함께 "더 좋은 코드" 가 무엇일지 논하는 일이 즐거웠던 개발자들은 이참에 이 대화를 주기적으로 나누기로 했고, 이왕이면 가이드로 삼을 만할 책도 옆에 펴두고 같이 보자며 함께 읽을 책을 골랐습니다.
그렇게 자연스럽게, 개발자들의 고민어린 대화는 팀내 스터디가 되었습니다.
1권의 책, 5명의 팀원, 10번의 모임
스터디를 위해 선정된 책은 리팩토링 계의 거장이라고도 불리는 마틴 파울러의 <리팩토링> 이었습니다.
20년 전에 출간되었던 1판은 자바 기반이었지만, 최근에 나온 2판은 자바스크립트 기반이라 프론트/백엔드 개발자들이 함께 읽기에 적합한 책입니다. 앞서 언급한대로 이번 스터디는 웹 프론트엔드 개발자 2명과 서버 개발자 2명, 그리고 팀내 프론트/백엔드 서포트를 다 해주었던 인턴 개발자 1명까지 하여 총 5명으로 구성되었습니다.
포지션은 각각 다르지만, 모두 자바스크립트에 대한 이해도가 어느 정도 있었기 때문에 언어와 긴밀히 연관된 개발 방법론을 공유할 수 있기도 했죠.
리팩토링 스터디는 스터디원들의 합의를 통해 아래와 같이 진행되었습니다.
- 스터디 주기는 주 1회로 한다.
- 스터디 전까지는 사전에 협의한 분량 만큼을 읽은 뒤, 각자 토론 주제 하나씩 선정한다.
- 스터디 당일에는 읽었던 내용 중 인상깊었던 부분과, 본인이 선정한 토론 주제를 자세히 공유한다. 이후 스터디원들이 가장 공감하는 토론 주제 1-2개를 선정하여, 1시간 가량의 토론을 진행한다.
처음에는 "다같이 똑같은 범위를 읽는데, 토론 주제가 다양하게 나올까?" 하는 의구심이 들기도 했으나, 첫 스터디 회차부터 이는 기우였음을 깨달았습니다. 각자의 성향이 다른 것처럼 개개인의 개발 스타일이 전부 달랐고, 이는 토론 주제를 뽑을 때부터 드러났습니다. 덕분에 단조롭기보다 열정적이고 치열한 토론이 이루어지기도 했었습니다.
위의 방식으로 진행하니 정확히 10회 정도의 모임을 가지게 되었습니다. 추운 겨울에 시작했던 스터디였는데, 옷 두께가 얇아지기 시작할 즈음 마무리하게 되었지요.
Before & After
스터디에서는 어떤 이야기들이 오갔을까요? 스터디원들에게 인상깊었던 주제를 몇 개만 짚어봅시다.
우선 가장 큰 논의 중 하나는 바로 "테스트 코드의 필요성" 이었습니다.
테스트를 작성하기 가장 좋은 시점은 프로그래밍을 시작하기 전이다.
나는 기능을 추가해야 할 때 테스트부터 작성한다. (...)
게다가 코딩이 완료되는 시점을 정확하게 판단할 수 있다.
테스트를 모두 통과한 시점이 바로 코드를 완성하는 시점이다.
- 마틴 파울러, 리팩터링,
Chapter 04: 테스트 구축하기 p135 -
스터디를 진행할 당시에만 해도 웹 프론트/웹 서버/앱 서버의 테스트 코드 커버리지는 거의 0에 수렴했습니다.
이전 개발자들도, 그 이전 개발자들도 테스트 코드를 작성하지 않았다는 이유로 관성적으로 테스트 코드를 외면하기도 했지만, 개발자들이 테스트 코드에 거부감을 가지고 있었던 점이 가장 주요한 원인이었습니다.
책을 읽으며 리팩토링과 테스트 코드는 떼어 놓을 수 없는 존재임을 모두가 인지하자, 스터디 내에서도 테스트 코드의 필요성과 적용 방법을 더 활발히 논의할 수 있었습니다. 비교적 로직이 단순하고 Read 위주인 웹 서버 파트에는 테스트 코드가 불필요할 것이라는 의견도 있었으며, 프론트엔드에는 테스트 코드를 어떻게 적용해야 하는지 감이 잡히지 않는다는 의견도 있었습니다 (DOM 엘리먼트를 직접 트랙킹하여 테스트할지, 이벤트를 mocking 할지 등의 논의가 이루어지기도 했었죠).
반면 앱 서버는 한시라도 빨리 테스트 코드 커버리지를 늘려 나가야 한다는 강경 도입파들의 의견이 보이기도 했습니다.
또 하나의 큰 토론거리는 바로 "객체지향을 올바르게 적용하는 방법" 이었습니다.
슈퍼클래스 추출하기의 대안으로는 클래스 추출하기가 있다.
어느 것을 선택하느냐는 중복 동작을 상속으로 해결하느냐
위임으로 해결하느냐에 달렸다.
슈퍼클래스 추출하기 방법이 더 간단한 경우가 많으니
이 리팩터링을 먼저 시도해보길 권한다.
나중에라도 필요해지면 슈퍼클래스를 위임으로 바꾸기는 어렵지 않다.
- 마틴 파울러, 리팩터링,
Chapter 12: 상속 다루기 p502 -
클래스를 사용하곤 했지만 의존성, 합성, 상속 등의 세부 특징들을 정확히 이해하지 못한 스터디원들도, 위의 내용을 읽을 때 여러 자료들을 찾아보며 구체적인 공부를 하게 되었다고 합니다. 특히 함수 기반의 프레임워크인 리액트 (React) 를 사용하는 웹 프론트엔드와는 달리, 앱/웹 서버는 클래스 기반 프레임워크인 Nest.js 를 사용하고 있기 때문에, 무책임한 클래스 상속의 위험에 더 노출되어 있었습니다. 그런데 리팩토링 책을 기반으로 논의하며, 객체지향의 기초부터 다시 짚어나갔으며, 클래스를 활용하는 적절한 방법들을 배울 수 있었습니다.
이외에도 <8.1 함수 옮기기> 장을 읽으면서는 DDD (도메인 주도 개발) 에 대한 토론을 했고,
<8.8 반복문을 파이프라인으로 바꾸기> 을 읽으면서 함수형 프로그래밍과 객체지향형 프로그래밍의 패러다임 차이를 논하기도 했습니다.
위의 모든 논의들이 "논의"로만 그쳤다면 자칫 허무할 수 있었겠지만, 매주 토론 끝에 스터디원들이 각자 적용할 수 있을 점들을 찾아 공유하고, 다짐하는 시간을 가지며 리팩토링에 대한 의욕을 고취했습니다. (실제로 테스트 코드에 대한 열띤 토론 직후에는 각자 "한 줄이라도, 다음 스터디 전까지 테스트 코드를 작성해보고 다시 모이자" 는 결의를 다지고 실무에 적용해보기도 했었죠.)
스터디의 가장 큰 장점은 이렇게 개개인이 코드에서 개선할 수 있는 점들을 함께 논의하고, 실제로 적용해볼 수 있다는 점일 것 같습니다.
스터디의 오해와 진실
스터디는 동료들과 함께 공부하며 개발 역량을 기를 수 있는 좋은 매개체입니다.
그러나 대부분이 스터디가 좋은 것을 알면서도 선뜻 시작하지 못하는데,
아마 스터디에 대한 여러 가지 오해와 선입견이 있기 때문이지 않을까 싶습니다. 그 중 대표적인 것 몇 가지만 짚어볼까 합니다.
1. 스터디 때문에 업무 시간을 뺐겨 업무 효율이 떨어진다?
스터디를 위해서는 업무 시간의 일부를 할애하여야 합니다.
비단 스터디 운영을 업무 시간 중에 하지 않더라도, 스터디를 준비하고 고민하는 모든 시간을 고려하면 업무 시간의 일정 부분이 스터디에 뺐긴다고 생각할 수 있죠. 하지만 그것은 더더욱 "좋은 스터디" 를 운영하기 위한 동기부여가 되기도 합니다. 어떻게든 유의미한 시간으로 만들기 위해, 팀원들이 더 열심히 참여할 수 있는 방안을 고민하게 되고, 스터디에서 얻은 내용을 업무에서 활용할 수 있는 방법들을 공유하게 됩니다. 이의 선작용으로, 팀 내 "업무를 더 잘하기 위한 공부"를 하는 분위기를 고양할 수도 있습니다.
무엇보다 업무 외적인 개발 얘기를 나누면서 스트레스를 해소하여, 오히려 리프레시된 마음으로 업무에 즐겁게 임할 수 있습니다. 우아한 형제들의 일하는 문화 중 <잡담을 많이 나누는 것이 경쟁력이다> 라는 문구처럼, 팀원들과 교류하는 즐거움을 느끼는 것은 조직이 건강하게 성장하고 팀원들이 즐겁게 일할 수 있는 원동력이 됩니다.
2. 흐지부지 되기 십상이다?
중심을 잡아주는 사람이 없다면, 어떤 모임이든 쉽게 와해되기 마련입니다.
반대로 말하면 중심을 잡아주는 사람 한 명 덕분에 모임이 오래오래 유지될 수 있기도 하다는 의미입니다.
스터디도 마찬가지로, 중심이 되는 인물 한 명만 있어도 서로와의 약속을 꾸준히 지킬 수 있는 동력이 생깁니다. 그래서 '스터디장' 의 역할은 꽤나 중요하다고 생각됩니다. 스터디장은 스터디를 먼저 하자고 제안한 사람일 수도 있고, 연장자일수도, 연차가 높은 사람일수도 있습니다. 막내이거나 신입이어도 열정만 많다면 물론 스터디장을 할 수 있습니다. 중요한 것은 스터디장이 책임감을 가지고 스터디 운영을 성실히 해주는 것과, 스터디원들이 스터디장을 적극적인 자세로 잘 따라주는 것입니다.
이 두 요소가 결합되어야 스터디가 비로소 잘 굴러가고, 끝까지 완주할 수 있겠죠!
3. 여럿의 의견이 대립하면 감정이 상한다?
스터디가 원활히 진행되기 위해서는 스터디원들이 각자의 의견이 옳음을 피력하기보다, 함께 더 좋은 해결안을 도출하기 위한 건강한 토론의 장임을 인지하고 열린 마음으로 임하는 자세가 중요합니다. 여러 의견을 수용하고 소통하고자 하는 의지가 없다면 그것은 스터디가 아니라 법정에서 열리는 재판에 가깝겠죠! 대부분의 분야가 그렇겠지만 개발에는 100% '맞는' 의견은 없습니다. 언제나 상황과 여건에 맞는 '최선'의 선택을 해나갈 뿐입니다. 너도나도 자신의 생각이 '맞다'고 판단하여 상대 의견의 흠을 잡는다면 감정 상할 일이 많겠으나, 경청하는 자세를 갖추고 함께 '최선'의 선택을 내리고자 한다면 스터디에서 공유되는 내용이 공격이 아닌 교류로 받아들여질 수 있습니다.
함께해서 즐거웠고...
몇 개월에 걸친 스터디를 함께하고, 큰 프로젝트도 잘 마친 스터디원들은 이제 휴가 기간에 접어들어 각자 휴식을 취하고 있습니다. 지난 스터디를 톺아보며 스터디원들은 각자 아래와 같이 소감을 남겼습니다.
하은 👩🏻💻
처음 스터디를 제안했을 때 사실 이렇게 한 권을 끝까지 완독할 수 있을 것이라 생각하지 않았습니다. 스터디를 하다 보면 으레 해이해지기도 하니까요. 하지만 팀원분들과 같이 매주 즐겁게 토론을 하고 코드가 좋아지는 과정을 생생히 지켜보니까 스터디를 준비하고 참여하는 모든 과정이 즐겁기만 하더군요. 좋은 시간을 만들어준 팀원분들께 정말 감사드리며, 다음에도 좋은 기회가 된다면 새로운 스터디를 통해 또 한 번의 성장의 기회를 도모해보면 좋겠습니다~
연진 👨🏻💻
시작하기 전에는 필요하나 귀찮고, 과연 도움이 될까 의문이 컸지만 실제로 스터디를 진행해 보니 생각 이상으로 큰 도움이 된것 같습니다. 리팩터링이라는 책이 이론과 실전 코드가 같이 들어가 있어 스터디가 회사의 프로젝트에 바로 연결이 되어 도움되는 것이 매우 좋았습니다!
강현 👨🏻💻
어느 한 선택에는 득과 실이 있듯이 리팩토링 책의 주제들도 모든 것을 해결해 주는 은탄환이 아닌 모두 장단점이 뚜렷한 전략들이었습니다. 만약에 스터디를 다같이 책을 읽기만 하는 형태로 진행되었다면 내용을 그저 맹목적으로 받아드리기만 하였을 것 같았는데 비판적인 토론 형태로 진행하게 되면서 각 주제의 장 단점을 확실하게 짚고 넘어 갈 수 있었습니다. 특히나 저는 레거시 코드의 반복되고 중첩되는 조건문이 너무나도 눈에 거슬렸었는데요 이를 10.4장 "조건부 로직을 다형성으로 바꾸기" 을 통해 OOP 형태로 탈바꿈 할 수 있었습니다. 정리하자면, 책을 통해서 코드 관리의 부채를 줄일 수 있었고 토론 형태의 스터디를 통해 리팩토링 전략들을 저희 프로젝트 상황에 적재적소로 적용 할 수 있었습니다.
한솔 👩🏻💻
입사하고 적응기간동안 업무와 병행할 수 있을지 욕심이 과한건 아닌지 고민을 했습니다. 하지만 업무시간에 스터디를 진행하고 같이 고민을 나눌 수 있다는 것이 적응하는데 도움이 될 것 같다는 생각에 도전했습니다.
팀원들이 어떤 부분에 중점을 두어 책을 읽고있는지 배웠습니다. 더불어 습득한 지식을 현재업무에 적용하는지를 보면서 사용하는 언어 및 업무에 대한 고민을 알 수 있었습니다. 그 결과 업무적 소통을 효과적으로 하는 방법 또한 습득할 수 있었습니다. 더불어 챕터들을 차근차근 읽다보니 왜 이러한 코드를 작성하고 있는지 논리적으로 설명할 수 있게되었고 팀원들과 같이 성장하는 것을 느꼈습니다.
규민 👩🏻💻
늘 컴퓨터 전공 관련 책을 읽으며 독학하고 싶은 마음은 있었지만 지금까지 다른 일들 때문에 미루어 한 번도 전공 책을 끝까지 완주한 적이 없었습니다. 그런데 운이 좋게도 사내에서 스터디를 제안 받았습니다. 저보다 훨씬 실력이 높고 경험이 많은 개발자 분들과 스터디를 할 수 있다면 더없이 좋은 기회라 생각했습니다. 하지만 스터디를 시작하기 앞서 약간의 걱정은 있었습니다. 업무 시간도 바쁜데 다같이 시간을 내서 스터디를 잘 이어나갈 수 있을지 확신이 강하지 않았습니다. 하지만 열정 가득한 팀원들과 함께한 스터디여서 한 번도 지치지 않고 책 끝까지 읽을 수 있었습니다. 특히 팀원 중 한 분이 처음 시작할 때 “매일 10분씩 유튜브 보는 시간에 책 읽다보면 다 읽을 수 있어요.” 라고 하신 말씀이 정확했고 무리없이 진행되었던 것 같습니다.
또 다른 걱정은 제 실력 부족이었습니다. 인턴을 시작하면서 새로 배운 “java script” 언어에 갓 적응하기 시작한 무렵이었고 무엇보다 실무에서 적용되는 이 언어만의 장단점, 그리고 java script 기반의 새로운 기술 등에 대한 지식이 얕았기 때문입니다. 책의 범위를 벗어난 토론에서 의견을 쉽게 낼 수 있을지에 대한 고민거리가 있었지만, 감사하게도 모두들 자신이 알고 있는 지식들을 최선을 다해 알려주었습니다. 그에 대한 생각을 공유하고 새롭게 받아들이며 오히려 지식을 크게 확장시킬 수 있었습니다.
특히 리팩토링 스터디를 진행하면서 백엔드 쪽 API 별 리팩토링 업무에 직접적으로 큰 도움을 받았습니다. 리팩토링 작업을 협업하는 팀원들과 스터디 토론 중에 컨벤션에 대해서 얘기를 자주 했던 것으로 기억합니다. 기존 코드에는 일관성이 부족하다고 느꼈는데, 스터디에서 오갔던 대화를 기반으로 일관성을 최대한 유지하고자 했고 코드리뷰할 때에도 쉽고 더 빠르게 고민들을 결정할 수 있었습니다.
리팩토링 업무의 범위도 넓힐 수 있었습니다. 스터디를 하기 이전에 리팩토링이란 단순히 원래 기존의 코드를 로직적으로 수월하게 수정하거나 쓰지않는 부분을 제거하는 정도로 이해하고 있었습니다. 하지만 그것을 넘어 가독성을 위해 변수, 함수, 파일의 이름을 잘 정리하는 것부터 코드의 위치에 대한 의미도 다시 한번 생각해 보고, 함수의 존재 유무를 따질 수 있는 것 까지도 포함할 수 있었습니다. 즉, 코드 전반적으로 바라보는 관점과 코드 한줄 한줄 섬세하게 바라보는 관점을 번갈아 오가며 코드의 많은 부분에 리팩토링을 적용하기 위해 더 노력할 수 있었습니다.
이렇게 매주 1시간 이상씩 팀원들과 얼굴을 마주보고 대화하는 시간이 저에겐 매우 유익했습니다. 각자 바라보는 관점과 선호도에 대해 더 잘 이해할 수 있었고 서로 유대감을 느낄 수 있었습니다. 팀 내에서도 특별한 활동을 공유하는 사이라는 느낌에 인턴 활동에서 활기를 불어넣어 주었습니다. 때론 맛있는 디저트를 함께 나눠먹으며 즐겁게 스터디 토론을 했던 추억이 좋게 남았습니다. 독학했을때보다 몇 배의 좋은 결과를 얻을 수 있었다는 강한 확신이 듭니다. 스터디를 진행했던 팀원들 모두에게 감사의 인사를 드립니다!
쉽지 않은 여정이었지만 함께 일하는 동료들과 같이 공부를 하고, 서로를 통해 한 층 더 성장할 수 있었던 기회라 다들 만족했던 것 같습니다. 서비스개발 1팀 팀원들을 비롯한 모든 알티모빌리티 사람들이 더욱 성장하기를 기원하겠습니다~!
댓글