개발 협업의 중요성

Written by Sangmin on May 31, 2024

앨범 평점 사이트 하입합 을 리디자인한 이유에 대해

변경된 스택: React, Express, MongoDB, Mui-material, Spotify API

앨범 리뷰 사이트 하입합을 여러 커뮤니티에 공유한 후 가입한 유저는 당시 90명 가까이 되어갔고 자연스레 고민이 생겼다.

이제 어떻게 하지?

처음 런칭해보는 사이트이기도 하고 배포한 지 조금 지난 터라 솔직히 관심도 시들해져갔다. 내 고민은 간단했다. 사용자가 꾸준히 성장하기보다는 커뮤니티에 공유한 하루 혹은 이틀 간 확 올랐다가 정체되는 것이다. 유저들이 계속해서 리뷰를 작성하고 콘텐츠가 많아야 사람들이 자주 접속할 텐데 하는 고민과 추가하고 싶은 기능은 많은데 혼자서는 힘에 부치는 문제도 있었다. 또 가장 걸렸던 건 아무래도 디자인. 디자인이 너무 별론가 하는 생각이 들었다.

결국 혼자서는 계속할 수 없다는 결론이 났고 나는 커뮤니티에 글을 올렸다. “음악 리뷰 사이트 같이 개발할 분들 모십니다.” 생각보다 반응이 있었고 이야기하던 중 프론트엔드 개발자 두 분과 기획자 한 분을 모집했다. 그 후 디자인과 마케팅이 필요하다 생각해 사이드 프로젝트 팀원 모집 글을 올렸고 디자이너 두 분과 마케터 한 분을 더 모셔 7명의 팀이 만들어졌다.

우리의 우선적인 과제는 디자인이었는데, 개발을 하려던 중 조금 문제가 생겼다. 우선 내가 사용하고 있던 스택이 조금 생소하고 올드할 수 있다는 것이다. 당시 개발된 사이트는 Handlebars라는 템플릿 엔진을 사용하고 있었고 장점이 꽤 있었지만 단점이 많았다. 코드베이스를 바꿀 걸 생각하니 머리가 아팠지만 서버는 건드리지 않아도 될 것 같아서 (Express) 서버는 그대로 두고 프론트엔드만 바꾸기로 했다. Next.js와 React 두 가지가 옵션이었는데 React를 선택했다. 사실 그리 깊게 고민하지는 않았다.

리액트로 간 이유:

그러나 지금 와서 생각해보면 Next.js로 했어야 했나 하는 생각도 든다. SEO가 중요한 프로젝트일 듯한데 SSR이 아니라 React는 조금 한계가 있는 듯하다. 방법이 있는 것 같기는 한데 좀 더 조사를 해봐야겠다. 현재는 react-helmet-async로 동적 메타태그는 해결했지만 아직 부족한 게 조금 있는 듯하다. 앞으로는 스택을 정할 때도 고민을 많이 해봐야겠다.

아무튼 이 프로젝트를 진행하면서 협업을 처음 해보게 되었다. 나의 역할은 프론트엔드, 백엔드, 그리고 마케팅, 기획. 디자인을 제외하고는 거의 다 건드릴 수밖에 없었다.

이 협업을 통해 배운 점이 많다. 세세한 것부터 이야기하자면, GitHub을 제대로 쓰는 법을 익혔다고 할까. 그전에는 사실 브랜치를 만들 필요도 없었고 메인 브랜치에 그냥 다 때려 박는 식으로 개발했다. 작업한 코드에 대한 리뷰도 없고 어떤 코드를 썼는지 정리하지도 않았으며, 당연히 커밋을 쪼개지도 않았다. 혼자 작업을 하면 좋은 점이자 나쁜 점이다. 사실 커밋을 하나하나 쪼개고 기록하는 게 효율적이지 않다. 오히려 개발 흐름에 방해되기도 하고, 빠르게 완성시키는 게 중요하다고 생각하는 내 입장에서는 그렇게 귀찮은 일일 수 없다.

개발자 중 한 분이 상당히 디테일한 스타일이라 기록하고 정리하는 것의 좋은 점을 많이 받아들일 수 있었고, 그 결과 조금은 깔끔하게 코드 작업을 할 수 있었다고 생각한다.

또 타입스크립트를 처음으로 써봤는데 확실히 좋은 점이 많았다. 물론 타입스크립트를 아주 적극적으로 사용하지는 않았고 간단히 타입 지정 정도만 썼는데, 코드가 깔끔해지는 등 장점은 있었다.그동안 자바스크립트를 사용하며 더러운 코드에 익숙해진 탓인지 오히려 잘 적응이 되지 않았지만 개발을 하다보니 많은 장점이 있다는 것을 깨달았다.

타입스크립트도 그렇고, ESLint 규칙을 적용하고 Prettier를 사용하는 등 평소에 혼자 개발할 때보다 엄격한 룰을 세팅해놓고 작업을 해서 색다른 느낌도 있었다. 하지만 다시 한번 느낀 건, 이런 작업 방식이 조금 성가시기도 하다는 점이다. 하지만 역시 장점을 파악하니 이런 작업 방식에 익숙해져갔다.

또 하나 느낀 점은, 사람이 많다고 빨리 진행되는 게 아니라는 점이다. 어떻게 보면 당연한 건데, 개발자가 3명이니까 세 배로 빨라진다는 생각은 세상일이 그렇게 간단하지 않다는 걸 알게 해준다. 사실 혼자 개발할 때보다 더 오래 걸린 듯하다. 아무래도 코드를 올리고 소통하는 과정에서 시간이 걸리고 코드 리뷰, 충돌 해결 등, 그리고 디자인이 될 때까지 기다려야 하고, 어떤 결정을 내릴 때 팀원들과 함께 내리려고 하니 그만큼 시간이 더 걸린 건 어쩔 수 없다.

중요한 점은, 협업하는 팀원 중 한 명이라도 속도가 늦춰지면 전체적으로 느려질 수밖에 없다는 것이다. 이 부분을 크게 느꼈다.

하지만 프로젝트는 속도만 중요한 것은 아니다. 훨씬 더 중요한 것들이 있고, 협업을 통해 그런 것들을 얻을 수 있다고 생각한다. 프로덕트와 코드의 퀄리티가 올라가는 것은 당연하고, 재미가 있다. 이게 제일 중요하다고 생각하는데, 혼자서 고민하던 것들을 다 같이 고민하면서 생각지 못했던 아이디어가 떠오르기도 하고, 미처 신경 쓰지 못하는 부분들을 누군가 신경 써주기도 한다. 나의 단점을 커버해 줄 수 있는 사람이 있고, 나도 다른 사람의 단점을 커버해 줄 수 있다.

또 한 가지, 협업의 가장 큰 장점은 길게 갈 수 있다는 것이다. “빨리 가려면 혼자가고 멀리 가려면 같이 가라”라는 말을 나는 상당히 좋아한다. 이 말은 협업의 장점을 딱 설명하는 말이다.

혼자 고군분투하며 개발했더라면 아마 이미 이 프로젝트는 손을 놓고 다른 프로젝트로 넘어가지 않았을까 싶다. 하나의 아이디어에 이렇게 깊은 고민과 많은 시간을 할애하기는 힘들다. 하지만 같이 하기 때문에 재미있고 책임감도 느껴서 오랫동안 한 프로젝트에 기여할 수 있다.

이렇게 깔끔한 디자인의 사이트로 거듭난 것도 물론 협업의 결과다. 앞으로도 더 많은 기능 개발과 마케팅 캠페인을 진행할 것이고, 꽤 기대가 된다.

마지막으로 협업의 중요성과 이를 통해 배운 점을 다시 한번 정리해본다.

정리

• 다양한 관점과 아이디어:

여러 사람이 모이면 다양한 배경과 경험을 가진 사람들의 아이디어가 모인다. 이는 문제 해결 시 더 창의적이고 혁신적인 접근을 가능하게 한다.

• 상호 보완과 학습:

각자의 강점을 살려 서로의 약점을 보완할 수 있었다. 팀원들로부터 새로운 기술이나 방법론을 배울 수 있는 기회였다. 타입스크립트나 Git 사용법 등을 실제 프로젝트에 적용하며 배웠다.

• 코드 품질 향상:

코드 리뷰를 통해 버그를 조기에 발견하고 수정할 수 있었다. 더 나은 코딩 관행과 패턴을 공유하고 적용할 수 있었다..ESLint, Prettier 등의 도구를 사용해 일관된 코드 스타일을 유지하고 이의 장점을 알게되었다.

• 책임감과 동기부여:

팀에 대한 책임감으로 더 열심히 하게 된다. 다른 팀원들의 열정과 노력을 보며 동기부여를 받을 수 있었다.혼자일 때보다 프로젝트에 대한 헌신도가 높아지는 것을 느꼈다.

• 지속가능성:

협업은 프로젝트의 장기적인 성공으로 이어진다. 한 사람이 지치거나 어려움을 겪을 때 다른 팀원들이 지원할 수 있고 지속적인 개선과 발전이 가능해진다.

• 종합적인 결과물:

디자인, 개발, 기획 등 다양한 분야의 전문가들이 모여 더 완성도 높은 결과물을 만들 수 있다.

• 문제 해결 능력 향상:

다양한 의견 충돌과 기술적 문제들을 해결하면서 문제 해결 능력이 향상되었다. 예를 들어, Git 충돌을 해결하며 많은 점을 배웠다.

• 커뮤니케이션 스킬 개선:

아이디어를 명확히 전달하고, 다른 사람의 의견을 경청하는 능력을 키웠다.기술적인 내용을 비기술적인 팀원에게 설명하는 것도 하나의 배운점이다.