"프리토킹" 을 위한 자유로운 대화가 가능한 랜덤 화상채팅 서비스
6인 프로젝트의 첫 협업이었다. 쟁쟁한 능력을 가진 팀원이 모였고, 다들 기대 반, 설렘 반의 마음으로 기획을 진행했다. 다양한 아이디어들을 제시했는데, 모두가 만족하는 아이디어를 찾는게 결코 쉬운일이 아니었다. 모두가 2개 이상의 아이디어를 제시했고, 그 가운데 가장 득표 수가 높은 아이디어를 골랐음에도, 결국 매니저님에게 좋지 않은 피드백을 받곤 했다. 며칠을 고민 끝에 고안한 아이디어가 바로 랜덤매칭 언어교환 서비스인 HelloWorld였다.
계절학기를 포함하면, 공통 프로젝트까지의 사전학습 공부 기간은 1달여 정도 있었다. 나는 이 시간을 가장 필요했던 공부에 사용했다. 이 곳에 오기 전, 미쳐 끝내지 못했던 react
를 공부하기 시작했다. 400여가지의 강의를 모두 들었고, 이론을 정리했다. 벨로그도 그때 다시 시작했다. 지금와서 돌이켜 보면, 그때 react
를 공부했던 것이, 지금의 성장에 가장 큰 기여를 했다고 생각한다.
공통 팀에서 선택한 기술은 websocket
이었다. 유저 끼리 비디오, 오디오 데이터를 서로 공유하며 사용한다. 기존에 찾아놨던, 무료 websocket
강좌가 있어 이를 통해 채팅 및 비디오 데이터를 공유하는 기술에 대해 공부했다. 사용한 라이브러리는 openvidu
였고, websocket
기반 라이브러리이기 때문에 금방 적응할 수 있었다. 아직도 능숙하다고는 말할 정도는 아니지만, 7주간 서버를 경유하여, client
끼리 통신하는 로직을 직접 설계하고 구현한 경험이 해당 프로젝트에서 나의 가장 큰 역량이었다고 말할 수 있겠다.
프로젝트 시작 전, 대규모 눈치게임이 시작된다. 바로 팀원 모집 기간인데, 좋은 팀원은 바로바로 나가기 때문에, 고민하지 말고 적극적으로 팀을 모으거나 찾아다녀야 한다. 이전 팀은 운이 좋게 자리가 남아있어 들어가게 된 케이스 인데, 당시 망설이지 않고 직접 전화하여 들어갔던 걸 정말 잘했다고 생각한다.
이를 계기로, 다음 프로젝트 사전 기간 중에는 내가 직접 팀원을 모집했다. 해보고 싶었던 팀원 분들에게 먼저 연락을 취하고 응답을 기다렸다. 아쉽게 같이 하지 못한 분들, 함께 하신 분들 다양하지만 모두가 배려가 담긴 긍정적인 답변을 주었다. 몇 분 가운데는 먼저 연락주셔서 감사하다는 이야기도 들었다.
누구나 좋은 팀과 함께 하고 싶어하고, 다들 모르는 사이라면, 일단 먼저 연락을 권해보자. 의외로 모르는 데 연락한다고 싫어하는 사람은 없었다
frontend
의 경우, readme.md
파일을 생성하여, 그날 그날 프로젝트에서 했던 일을 기록하였다. 몇 분 걸리지 않는 일이지만, 의외로 크게 도움이 되었다. 동료들의 현재 진행상황을 알 수 있었고, 본인이 해왔던 작업 코드들을 빨리 찾을 수 있게 된다. 현재 벨로그에 쓰고 있는 회고나 개발일지를 쓰는데에도 큰 도움이 되었다.
공통 팀에서는 단순히 할 일만 정리했는데, 이번에는 에러나 이슈사항도 자세하게 작성해보려 한다.
공통 팀에서 한 것도 지금 껏 해온 것들 가운데, 제일 강하게 원칙을 정해서 했지만 그럼에도 실수나, 허점이 보였다. 시간에 점점 쫓겨질 수록 Git, Jira
전략을 소홀히 하게 되었고, 그러한 부분들이 팀원들의 작업 시간을 더 소모하게 되는 결과로 다가왔을 것이다.
주변의 전략을 들어보면, 모든 팀원의 피드백을 통과했을때만 병합이 진행된다던지, 서로 작성한 코드를 팀원들에게 공유한다던지, 항상 중요한 부분에 주석을 쓴다는 등, 다양한 전략들이 존재했다. 다음 프로젝트에서는 느꼈던 부족한 점을 좀 더 보완하여, 전략을 짜려고 한다.
프로젝트 진행 상황을 돌이켜보면, 같은 직무를 가진 동료들끼리도, 다른 직무를 가진 동료들끼리도 모두 커뮤니케이션이 부족했다는 생각을 했다. 동료들을 신뢰한다는 마음가짐에 상대방에게 일일이 이유를 묻는 것은 실례라는 생각을 했다. 어느정도는 좋은 부분이라고는 생각하는데, 예를 들어 코드를 수정했는데, 서로 정보를 공유하지 않거나, 그 코드는 내 권한이 아니니 알아서 팀원이 처리하겠지 등의 생각에 빠지기가 쉬웠다. 실제 프로젝트 진행상황 동안 그런식의 경우가 많았다.
프로젝트 기간이 점점 짧아질수록 개발에만 집중을 하게 되었고, 그만큼 소홀해지는 부분이 생기기 마련이다. 우리팀의 경우, 그 중 하나가 바로 스크럼이었다. 주변 팀 가운데, 팀 스크럼 문화를 공유 받았는데, 해당 날짜의 스크럼을 보고서화 하여 저장하는 방식을 사용한다고 한다.
스크럼이 뚜렷할수록 업무 상황이나, 진행 정도를 파악하기 쉬워지고 그만큼의 시간을 더욱 효율적으로 쓸 수 있게 된다. 다음 프로젝트에서는 확고한 스크럼 문화를 대입해보려고 한다.
위의 이야기와 이어지는 주제로, 우리 팀이 잘하기 위해서는 내가 열심히 하면 되는 거라고 생각했다. 물론 맞는 말이지만, 프로젝트 경쟁 팀은 무척 많고 그 가운데 팀원 모두가 협력하여 잘한 팀이 홀로 잘하는 팀 보다는 잘할 수 밖에 없다. 모든 것을 내 책임이라며 끌어안지 말고, 모두가 함께하면 쉽고 빠르게 혹은 더 나은 결과를 나타낼 것들이 있을 것이다. 가끔은 주변을 돌아보고 함께 나아가보자.
그동안 기획에서는, 동료와 대립하는 게 두려워서 의견을 존중하거나, 애써 단점을 찾으려 하지 않았다. 발표에서 다양한 팀의 프로젝트 기획을 들어보면 과정에선 대립하더라도, 모두가 긍정적으로 바라보는 기획을 하는게 좋다는 생각이 든다.
기획 부분에서 매니저님께 부정적인 피드백을 꾸준히 받아왔는데, 그냥 기술로 보완할 수 있다고 생각했다.
기획은 프로젝트에서 가장 중요한 부분이다. 모두가 호응하는 기획이 뒷받침 되어야, 모두의 개발 기술이 100% 적용될 수 있다. 행여 대립하거나, 서로 부딪히게 되더라도 팀의 미래를 위해 좋은 방향으로 나아가는 중이니까 5번 10번 시간 나는대로 틈틈히 회의하고 기획하자!
프로젝트에서 배포를 하고 안하고의 차이는 크다. 자동배포까지 완료가 되는 경우, 커밋만 하면 자동으로 코드가 다시 빌딩하여 배포가 이루어지기 때문에, 그 부분을 더이상 신경을 쓰지 않아도 되기 때문이다. 지난 프로젝트에서도 이러한 배포작업을 진행하는데, 많은 시간이 소모가 되었고, 나의 경우 프론트 업무라는 핑계로 배포작업에 대해 전혀 신경쓰지 못한 점이 아쉬웠다. 자동배포에도 결국 실패하게 되어서, 매번 최신 코드로 업데이트 하는데에 많은 시간을 소모하게 되었고, 이는 프로젝트 결과에 부정적인 요인으로 다가왔다.
다음에는 기회가 된다면 배포에 대해 공부하는 시간을 가져보려고 한다. 팀원 가운데 한명이라도 배포 관련 지식을 어느정도 가지고 있다면, 프로젝트에 큰 기여가 될 거라 생각한다.
그래서 개발자들이 devops
, devops
하나보다.
https://www.figma.com/file/OqoGzyfLCQ1rtuvCJvuIwr/HelloWorld?node-id=0%3A1