루비콘은 뭐하는 사람들인가요?

August 27, 2019

이번 포스팅은 첫 포스팅이니만큼 루비콘이 어떤 팀인지, 뭐하는 팀인지에 대해서 한번 이야기해보려고 합니다. 사실 루비콘은 그냥 친구들끼리 모여서 재밌게 만들고 싶은 것을 만들고 노는 팀이기 때문에 지금까지 어떠한 홍보도 하지 않았었습니다.

그러나 멤버들의 경력에 루비콘에서 만들었던 프로젝트가 몇 개 들어가 있기도 하고 주변에서도 “그게 도대체 뭐하는 팀이냐”고 물어보는 사람들이 하도 많아서, 이제는 이 블로그를 통해 루비콘에 대해서 제대로 소개도 하고 단순한 개발을 벗어난 여러가지 재밌는 활동도 해보려고 계획 중 입니다 🚀

members 이 사진만 보면 왠지 아저씨들 등산 동호회같다

6명의 개성 넘치는 멤버들

루비콘은 일종의 토이 프로젝트 팀이자, 랩(Lab)이라고 할 수 있습니다. 루비콘에 속해있는 6명의 멤버들은 각자 웹 개발, UI/UX 디자인, 머신러닝 연구, 의료 영상 개발 등 각자 다른 전문 분야에서 일을 하고 있는 사람들로 구성되어 있으며, 멤버들은 같은 IT 업계에서 일하고 있는 동종 업계 종사자이면서 실제로도 친한 친구이기도 해요.

대부분의 멤버들은 O2O, 커머스, 금융 서비스를 만드는 일을 하고 있지만 두 명의 멤버는 머신러닝을 연구하는 분야에서 일을 하기 때문에, 각자의 전문 분야에 대해서 모르는 것이 있다면 해당 멤버에게 물어보기도 하고 서로 도움을 주기도 합니다. 네트워크를 잘 아는 사람은 다른 멤버들에게 네트워크에 대해서 알려주고, 머신러닝을 잘 아는 사람은 머신러닝을 알려주고 하는 식이죠.

가끔 씩은 주제를 정해놓고 스터디를 하기도 하는데, 자료 구조나 알고리즘과 같은 기초 지식부터 CNN과 같은 머신러닝까지 그때그때 공부하고 싶은 주제를 정해서 스터디를 진행하고 있어요. 이때 해당 기술에 가장 익숙한 사람이 스터디를 리딩하고 나머지 멤버는 그 멤버가 리딩하는대로 발표를 하거나 공부하는 방식으로 진행하고 있습니다.

루비콘의 시작

루비콘의 멤버들은 처음부터 뭔가를 만들기 위해 모인 사람들이었습니다. 초창기 멤버들 중 한명이 자신의 아이디어를 실현하기위해 주변의 인맥을 긁어모아서 웹 개발 조금 할 줄 아는 애, 디자인 조금 할 줄 아는 애 등을 불러모은 결과가 지금의 루비콘이 된 것이죠.

하지만 당시 웹 개발 조금 할 줄 아는 애는 웹 디자인 기능사 자격증 하나 가지고 있는 애였고, 디자인 조금 할 줄 아는 애는 다룰 줄 아는 툴이라고는 포토샵 밖에 없는 애였습니다. 진짜로 조금 밖에 할 줄 모르는 애들을 모아서 팀을 만든 것이죠. 심지어 그렇게 긁어모은 멤버 중 한명은 당시 전역도 하지않은 군인이었습니다.

결국 그렇게 모인 오합지졸들은 각자 프론트엔드, 백엔드, UI/UX 디자인의 롤을 맡기로 하고 어떻게든 서비스를 한번 개발해보기로 했고, 그게 루비콘이라는 팀의 시작입니다.

dongguk univ 카페 갈 돈도 없어서 매일 학교 강의실을 빌려서 썼었다는...

당시 루비콘의 멤버들은 대부분 학생이었고, 대학교나 학원에서 배운 약간의 지식만 있을 뿐 실제 서비스 개발에 대한 지식은 전무했기 때문에, 프로젝트를 진행한다는 것은 직접 부딫히며 공부하고 적용하는 과정의 반복이었습니다.

오합지졸들의 삽질 일기

맨 처음 사람들을 모으기 시작한 멤버의 아이디어는 바로 크리에이터들이 자신들이 만든 아트워크나 벡터 샘플, 3D 모델 등을 자유롭게 공유할 수 있는 플랫폼이었습니다. 하지만 문제는 이렇게 모인 6명의 오합지졸 중 아무도 실제 서비스를 구현해본적이 없었다는 것이었습니다.

결국 각자 자료조사를 통해서 어떤 기술을 공부해야할지, 인프라는 어떻게 구축해야할지 공부하기 시작하며 BehanceSketch Fab을 롤 모델로 잡고 개발을 시작했습니다.

baldman 당시 jQuery로 만들던 3D 모델 에디터

그러나 당시 루비콘은 이렇게 큰 프로젝트에 대한 개발 경험이 없었기 때문에, 코드 레벨부터 협업까지 굉장히 많은 문제를 겪었습니다.

당시 백엔드의 경우, Apache, MySQL, PHP를 통합 설치 해주는 MAMPWAMP를 사용하여 개발을 진행했었고, 프론트엔드 또한 jQueryThreeJS로 모든 것을 해결했습니다. 물론 이런 기술 스택으로도 올바른 설계를 통해 어플리케이션을 개발했다면 그나마 나았겠지만, 당시 멤버들은 제대로 된 어플리케이션의 설계에 대한 개념도 없었기 때문에 코드 또한 중구난방으로 작성될 수 밖에 없었죠.

비록 1년 간의 엄청난 삽질 끝에 결국 이 서비스들의 에디터가 제공하는 대부분 기능을 구현할 수 있었지만, 문제는 제대로 된 설계없이 작성된 어플리케이션이 뿜어내는 무수한 버그들이었습니다.

버그는 대부분 코드 레벨에서의 논리적인 오류 때문에 발생합니다. 그러나 간혹 콘솔에는 에러가 출력되지 않지만 그렇다고 기대했던대로 작동하지도 않는, 개발자의 추리력으로 찾아내야 하는 버그도 있습니다.

당시 루비콘 멤버들이 고생했던 것은 이런 종류의 버그들이었습니다. 일반적으로 이런 버그를 디버깅 할 때는 몇 가지 가설을 세우고 하나씩 검증해가면서 접근해나가는 방법을 사용하는데, 가설을 세우는 데는 개발자의 경험이 적지 않은 영향을 미칩니다. 그러나 당시 멤버들은 이러한 경험이 없었기 때문에 이런 버그를 하나 잡아내는데 많은 시간을 소모할 수 밖에 없었습니다.

하지만 이 프로젝트가 망한 진짜 이유는 버그 자체가 아니라 MVP(Minimun Viable Product)에 대한 개념이 없이 무조건 끝까지 완성한 후 배포를 하려고 했기 때문입니다. 개발을 계속 해나가면서 어플리케이션은 점점 거대해졌지만, 배포를 할 필요가 없으니 중간 중간 테스트를 하지도 않았고 그저 쭉 기능만 개발했던 것이죠.

그리고 개발을 오랜 기간 동안 하다보면 자연스럽게 요구 사항이 변경되기 마련인데, 당연히 이런 요구 사항 변경을 고려한 설계를 하지 않았기 때문에 요구 사항이 변경될 때마다 코드 퀄리티가 급격하게 저하되었습니다. 결국 개발 일정은 점점 늘어지고 버그는 점점 늘어나는 상황에 다들 지쳐가기 시작했고, 결국 프로젝트가 드랍되었죠.

mvp MVP가 제대로 정의되지 않은 프로젝트는 점점 늘어지게 될 확률이 높다

결국 루비콘 첫 번째 프로젝트는 1년 간의 개발 끝에, 계속해서 터져나오는 버그를 감당하지 못하고 폐기 처분되었습니다. 이후 이 프로젝트를 살리기 위해 LaravelAngularJS로 포팅하여 다시 진행했지만, 프로젝트의 규모 자체가 너무 거대해서 6명의 인원으로 유지보수가 불가능한 것이 근본적인 원인이었기 때문에 결국 비슷한 문제를 겪고 포기하게 되었습니다.

그나마 다행인 것은 Git을 사용해서 버전 관리를 했다는 것인데, 그 덕분에 현재도 Github과 Bitbucket에서 이 눈물나는 삽질의 역사를 다시 볼 수 있습니다. 루비콘 깃허브의 lubycon-frontend 레파지토리와 lubycon-rest-api 레파지토리를 보시면 루비콘 멤버들이 어떤 삽질을 했었는지 직접 화깅ㄴ해 보실 수 있습니다 😢

하지만 이런 삽질 끝에 멤버들이 얻었던 가장 큰 성과는 실제로 어플리케이션을 개발하는 과정을 한번 경험해봤다는 것입니다.

대학교에서는 어플리케이션을 어떻게 개발하는지, 버전 관리는 어떻게 해야하는지, 또 협업은 어떻게 진행하는지 알려주지 않습니다. 이런 경험은 실제로 회사에 입사하거나 토이 프로젝트를 통해 비즈니스를 개발해보는 과정을 통해서만 얻을 수 있기 때문에, 대학생 시절에 1년 동안 이런 경험을 해볼 수 있었다는 것 자체가 멤버들이 성장할 수 있는 기회였던 것이죠.

이후 아트워크, 벡터 샘플, 3D 모델을 전부 다뤄야 했던 첫 번째 프로젝트에서 아트워크 부분만 떼어내서 Pixelstairs라는 프로젝트를 만들었고, 이 프로젝트는 철저하게 MVP를 정의하고 제작되었기 때문에 큰 요구 사항의 변경없이 몇 개월만에 개발을 끝낼 수 있었고, 실제로 서비스를 배포하고 운영도 해볼 수 있었습니다.

pixelstairs main Pixelstairs의 단촐한 디자인은 당시 멤버들의 MVP에 대한 집착에서 비롯되었다

그러나 당시 멤버들이 모두 첫 직장을 다닐 때 쯤이라 시간적인 여유가 많이 없었고, Pixelstairs 서비스의 핵심 컨텐츠인 아트워크를 충분히 확보하기가 힘들었습니다. 몇 명의 크리에이터들이 아트워크를 업로드하기는 했지만 다른 크리에이터들의 구미를 당기기에는 아트워크의 절대적인 양 자체가 너무 적었던 것이 문제였습니다.

그래서 모자란 컨텐츠는 루비콘 내에서 자체적으로 아트워크를 제작해서 업로드해서 충당했지만, 당시 루비콘의 크리에이터들도 결국은 회사에서 디자이너로 일을 하는 멤버들이었기 때문에 직장 생활과 아트워크 제작을 병행하기에는 여러모로 힘든 환경이었습니다.

결국 Pixelstairs는 두 달 정도 운영된 끝에 컨텐츠 부족으로 폐기처분되었습니다.

이 이후에도 몇 개의 프로젝트를 더 진행했지만, 결국 비슷한 과정을 거치면서 서비스 운영을 종료하게 되었습니다. 이러한 과정들을 거치면서 루비콘 멤버들은 회사 생활과 서비스 운영을 병행하기는 너무 힘들다라는 의견으로 모아지게 되었고, 지금 현재는 예전처럼 큰 프로젝트를 함께 만드는 것이 아니라 작은 토이 프로젝트를 만들거나 함께 스터디를 하고 지식을 공유하는 방향으로 변하고 있습니다.

현재 루비콘의 모습

사실 처음 루비콘을 시작할 때는 멤버들이 개발이나 디자인에 대한 지식이 거의 없는 상태였기 때문에 그저 서비스 개발만으로도 충분히 실력을 성장시킬 수 있었습니다. 그러나 지금은 다들 4~5년차에 접어든 만큼, 단순한 서비스 개발로는 각자의 지식욕을 충족시킬 수 없다는 이야기가 멤버들 사이에서 나오게 되었죠.

프로젝트를 할 때마다 최대한 새로운 기술을 도입해서 사용하기는 하지만, 근본적인 기술 자체는 변하지 않기 때문에 어느 정도의 한계는 있다고 생각하는 것입니다.

또한 연차가 쌓이며 멤버들의 관심 분야가 단순히 프레임워크나 언어가 아니라 대용량 데이터 처리나 이미지 프로세싱과 같이 어느 정도 기반 데이터나 인프라가 필요한 분야로 넘어가기 시작했기 때문에 오히려 루비콘에서 하는 개발보다는 회사에서 업무를 하며 자신의 지식욕을 충족시키는 경우가 더 많아지기도 했습니다.

게다가 각자의 분야에서 전문성이 점점 쌓이며 서로 관심있는 분야의 갭도 점점 커지고 있기 때문에 모든 멤버가 성장한다는 느낌을 받으면서 같이 서비스를 개발하기는 힘들다는 결론을 내리게 되었죠.

그런 이유로 현재 루비콘은 예전처럼 함께 서비스를 개발하지는 않습니다. 가끔 멤버 중 한 명이 작은 토이 프로젝트에 대한 아이디어를 발제하면 관심있는 멤버들이 달라붙어서 개발을 하는 경우는 있지만 예전처럼 다 함께 뭔가를 개발하지는 않죠.

대신 각자 공부를 하거나 블로그를 쓰거나 하는 등 자기 계발의 시간을 가지고, 그렇게 공부한 지식을 스터디를 통해 다른 멤버들과 공유하는 것에 초점을 맞추고 있습니다.

study 멤버들끼리 스터디 겸 작은 발표회를 진행하기도 한다

사실 대학생때부터 5년이라는 긴 시간 동안 한 팀을 이뤄서 뭔가를 함께 만들면서 성장했다는 경험 자체가 드문 경험이기 때문에, 최근에는 이런 경험을 다른 사람들과도 나눠보고 싶다는 의견도 있었습니다.

이제 루비콘은 단순히 뭔가를 함께 개발하는 팀이 아니라 멤버들이 서로의 성장에 도움을 주고, 더 나아가 루비콘 외부에 있는 사람들의 성장도 함께 도와줄 수 있는 목표를 가진 팀이 되었습니다.

© 2020, Built with Lubycon