brunch

매거진 레드윗 개발팀 이야기

라이킷 14 댓글 1

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 레드윗러 Jun 19. 2020

초기 스타트업 개발팀의 성장기

신입 개발자들이 모여 개발팀을 꾸려나가는 과정

레드윗에 합류하였을 때, 레드윗은 이제 막 법인이 설립된 따끈따끈한 팀이었다. 개발팀이라고 말할 것도 없이 개발자는 단 한 명이었고, 내가 들어오면서 두 명이 되었다. CTO 한 명과 개발자 한 명. 이것이 레드윗 초기 개발팀의 전부였다. 둘이서 밤늦게까지 작업하면서 겨우겨우 만든 알파 서비스는 다행히 제시간에 테스팅할 수 있었지만, 학교 과제보다도 못한 나의 코드를 볼 때면 한숨만 나왔다. 그리고 개발팀에 한 명이 더 들어왔다. 그렇게 CTO 한 명과 개발자 두 명. 또래로 구성되었던 그 세 명의 우리가 레드윗의 초기 개발팀이었다.

신입 개발자들(일명, 개린이- 개발 어린이) 답게 우리는 배우는 것에 두려움이 없었다. 처음 써 보는 react native임에도 밤을 새우면서 작업에 몰두하였다. 문제는, 배우기만 했을 뿐 이것을 어떻게 잘 쓰냐에 대한 고민이 없이 그저 만들기에 급급했다는 것이었다. 당시 레드윗은 두 번째 프로젝트인 브라보 프로젝트를 진행 중이었고(레드윗은 프로젝트 명을 나토 음성어로 작명한다.), 개발팀의 목표는 베타 서비스 출시였다. 처음 해보는 앱 개발과 처음 써보는 언어와 라이브러리들. 홍수와 같이 떠밀려 오는 수많은 할 일들 사이에서 모두들 열심히 했지만 결과물은 엉망진창이었다. (심지어는 듀도 제대로 못 맞추는 참사가 펼쳐졌다)

끝도 없이 쏟아지는 버그와 이슈들 사이에서 우리는 우리의 결과물이 얼마나 엉망진창인지를 몸소 느꼈다. 비단 결과물만 엉망진창이 된 것은 아니었다. 우리의 삶도 엉망진창이었다. 밤을 새우고 아침 동이 터오면 겨우 방으로 들어가 잠깐 눈을 붙이고 다시 나와서 코딩을 하고는 했다. 회사 한편에 마련된 소파에서 쪽잠을 청하거나, 책상에 엎드려 잠시 눈을 붙이는 방법으로 어떻게든 잠을 줄여서라도 마감을 맞추려 했으나 결과물은 딱 동작은 된다, 정도의 의의를 가졌다. (아직도, 부끄러움에 그때의 코드를 제대로 쳐다보지 못한다..) 우리는 우리의 일하는 방식을 바꿔야 한다는 생각이 들었다.

무엇이 문제일까?

우리는 우리의 일하는 방식을 바꾸기 전에 우리의 현 상태를 알아야만 했다. 무엇이 문제이고 어떤 점이 우리를 엉망진창으로 만들었는지 알아내야 했다. 그래서 우리는 자체적으로 Retro(Retrospective, 회고)를 진행하였다. 우리는 자체 회고를 통해 무엇이 좋았고, 어떤 점이 좋지 않았으며, 어떤 점을 배웠나에 대한 생각을 서로 나누기 시작했다.

실제로 우리 팀에서 진행했던 브라보 프로젝트에 대한 개발팀의 레트로 내용

이 과정에서 우리가 가장 먼저 생각한 것은 개발팀의 문화였다. 물론, 개개인의 역량과 서비스의 코드 퀄리티를 끌어올리는 것도 급하지만 가장 먼저 우리가 생각한 것은 우리 팀은 어떤 것을 지향할 것인가, 라는 방향성이었다. 이 과정에서 우리는 CTO인 Mini의 제안을 토대로 이야기하며 몇 가지의 문화를 만들고자 하였다.

개인의 성장과 팀의 성장이 동시에 될 수 있는 방향으로 일하기

회사가 잘 되려면 좋은 퀄리티의 서비스가 개발되어야 한다. 좋은 퀄리티의 서비스가 개발되려면 개발팀의 역량이 좋아야 한다. 개발팀의 역량이 좋으려면 개개인의 성장이 필수적이다. 그저 서비스를 만드는 것에 급급한 것이 아니라 하나라도 배워갈 수 있고, 개인이 성장할 수 있는 계기가 될 수 있게 하는 방향으로 우리는 개발을 진행하기로 했다. 개발 기간이 조금 길더라도 엉망진창인 코드 대신에 우리의 최선이 담긴, 우리가 충분히 생각하고 배울 수 있는 코드를 작성하기로 했다. 이 과정에서 필요하면 서로의 정보를 공유할 수 있는 세미나도 열고, 배운 내용을 잘 정리해서 서로 공유하며 우리 만의 최선을 만들어나갔다.

내부적으로 공유하기 위해 우리끼리 만든 문서

사실 이러한 개발팀의 생각은 회사의 입장과 안 맞을 가능성이 높다. 서비스가 빨리 런칭되는 것이 가장 급한 회사의 입장에서는 제품 퀄리티만 어느 정도 보장되면 코드 퀄리티에 대해 굳이 신경 쓰지 않는다. 다른 팀은 어떠한지 모르지만, 우리는 이에 대한 생각을 대표님과 나누었고 감사하게도 우리의 이런 생각을 공감해주시고 이해해주셨다. 그리하여 우리는 베타 서비스의 코드를 모두 지우고, 다시 새롭게 개발을 시작하는 리팩토링 대공사를 진행하였다.

넓고 적당히 아는 정도를 추구하기

넓고 얕게 아는 것과 좁고 깊게 아는 것 사이에서 늘 우리는 어떤 쪽이 맞나에 대해서 고민한다. 우리 팀이 추구하는 방향은 "넓고 적당히 아는 정도"로 결정하였다. 우리는 서비스를 만드는 회사이기에 아주 깊게 알 필요도, 한 분야에 대해서만 좁게 아는 방향도 맞지 않는다는 생각을 했다. 우리의 서비스 퀄리티를 위한 어느 정도 선에서의 (물론, 깊게 알면 알수록 더 좋기는 할 것이다.) 넓은 영역을 다룰 수 있게 하자, 이것이 우리가 추구하는 방향이다. 프론트엔드 개발자/ 백엔드 개발자가 나뉘어 있지만, 서로의 영역을 모르지는 않게 하는 것이 우리가 추구하는 방향으로 잡았다. 그리고 지금도 내부적인 세미나와 코드 리뷰를 통해서 모든 영역을 다 배울 수 있고, 다룰 수 있는 문화를 구축하고 있다.

협업의 가치를 중요시하고 책임을 분산시키기

혼자서 개발을 하면 아무리 최선을 다해 생각하더라도 실수를 하기 마련이다. 협업을 하면 좋은 점 중 하나는 내가 놓치고 가는 실수에 대해 다른 개발자가 발견할 가능성이 있다는 것이다. 우리는 이러한 협업의 가치를 조금 더 중요하게 다루고 싶었다. 그래서 개발되는 코드에 대한 책임이 그 코드를 작성한 개인이 아닌 모두의 책임으로 인식하는 문화를 만들고 싶었다. 그래서 도입한 방법이 바로 코드 리뷰이다.

코드 리뷰에 대한 정보는 구글에 치면 많이 나오지만, 실제로 도입한 사례에 대한 정보는 한정적이다. 우리는 어떤 방식이 우리와 가장 잘 맞을까에 대해 많이 고민하였다. 그 과정 중에 시행착오도 많이 겪었다. 그리고 마침내 우리만의 코드 리뷰 문화를 만들어갔다. 물론, 지금도 코드 리뷰가 완벽하게 정착되었다고 생각하지 않는다. 우리는 우리의 방식대로 지속적으로 문제를 제안하고 발전시키려고 노력하고 있다.

우리가 나누는 실제 코드 리뷰, github을 이용해 자유롭게 피드백을 주고받는다

물론, 아직도 우리는 발전해야 할 점이 많고, 발전 가능성이 많은 작은 개발팀이다. 새로운 사람들이 합류하면서 개발팀이 조금씩 커질 때마다 문제를 겪기도 하고, 아직도 우리의 코드 퀄리티에 만족하지 못한다. 우리는 그림에도 성장하는 개발팀을 만들기 위해서 자체 회고(Retro)를 통해서 문제를 인지한다. 그리고 어떻게 발전시킬 수 있을지에 대해 생각하고 논의한다. 이런 과정을 통해서 우리만의, 레드윗러만의 개발 문화를 구축하고 또 이에 안주하지 않고 지속적으로 성장하는 것이 우리 개발팀 문화의 진정한 방향이다.