개발할 때는 몰랐는데 이렇게 flow chart로 정리해보니 Reciper의 볼륨이 생각보다 많이 크다는 것을 알았습니다.
commit이나 issue의 갯수도 꽤 높은데 우리가 그만큼 열심히 달린 증거로 보여 뿌듯했습니다.
저는 우리가 이만큼 만들었다! 이런 기능을 구현하였다! 를 어필하기 위해 README나 WIKI의 내용을 작성할 때 많은 고민을 했었고 flow chart, 이미지를 제작하는 데도 많은 공을 들였습니다.
그만큼 Reciper의 크기를 더 잘 보여줄 수 있어서 기쁩니다.
Client Side Flow Chart
Server Side Flow Chart
Database Schema
함께 성장했습니다
Final Project를 진행하며 가장 좋았던 점은 4주동안 함께 성장했다는 것입니다.
매일 아침에 오늘은 어떤 작업을 할지 서로 공유하고 어떻게 진행할 것인지 토론을 했습니다.
그리고 저녁에는 오늘 했던 작업들에 대해 코드리뷰를 진행하고 기록을 남겼습니다.
코드리뷰를 통해 자신이 했던 작업 부분뿐만 아니라 다른 팀원이 어떻게 코드를 작성했는지 흐름을 알 수 있었습니다.
스스로 주도적으로 일을 하는 분위기였지만 서로에게 도움을 주기도 했습니다.
만약 작업 중 막히는 부분이 있다면 함께 모여서 고민하고 해결하는 시간을 가졌습니다.
내가 생각하지 못했던 참신한 방법을 알 때도 있었고 부족했던 이론적 개념을 다시 배우기도 했습니다.
혼자 앞서서 달려나가는 것이 아닌 서로 도와주고 으쌰으쌰하면서 함께 만들었기에 Reciper를 완성할 수 있었습니다.
시간이 조금만 더 있었더라면
한정된 시간 내에 Project를 완성해야했기에 개발과 공부를 동시에 진행해야 했습니다.
TypeScript는 First Project때 사용해보았기에 괜찮았지만 나머지 다른 기술들은 공부를 해야 했습니다.
공부가 깊게 되지 않은 상태에서 바로 코드를 작성하다보니 나중에 발견한 문제나 에러가 많습니다.
저희는 협업 툴을 개발할 때 실시간 협업을 고려하여 구현하였습니다.
클라이언트와 서버 간에 양방향으로 데이터를 실시간으로 주고받는 통신을 하기 위해 socket.io를 사용했습니다.
협업 툴에 채팅, 칸반보드, 캘린더 기능에 모두 socket.io를 사용했는데 채팅 메시지를 보내거나 마우스로 클릭하는 등의 사소한 동작에서도 이벤트 함수가 실행됩니다.
이 방법은 트래픽이 조금만 증가하더라도 바로 서버에 과부화가 걸린다는 문제점이 있습니다.
프로젝트 막바지에 이 문제를 발견하였지만 시간이 부족해 해결하지는 못했습니다.
시간 부족으로 단일 서버로 socket.io를 구현했지만, 시간이 조금만 더 있었더라면 cluster를 사용하여 다수의 프로세스에서 서버를 동작시켰을 것 입니다. 그리고 cluster 간에서 데이터 공유를 할 수 없는 문제를 해결하기 위해 redis를 사용했을 것 입니다.
이외에도 그당시 개발할 때는 몰랐던 코드의 문제점이나 보완해야하는 부분들이 많습니다.
코드를 어떻게 해야 더 효율적으로 짤 수 있는지도 보여서 아직 많이 부족하다는 것을 느꼈습니다.
앞으로도 계속 Reciper와 함께,
우리 기수에서 최고의 결과물을 만들어보자, 라는 마음으로 Final Project에 집중했고 그만큼 Reciper에 대한 애정도 큽니다.
단순히 구현을 했다는 것에 만족하지 않고 계속 Reciper를 업그레이드 시키고 싶습니다.
4주 기간동안은 구현에 최우선을 두었기에 우리가 생각하지 못한 에러, 이슈들이 많을 것 같습니다.
이러한 에러들을 고치거나 코드를 최적화/리펙토링을 진행해볼 예정입니다.
그리고 실제로 서비스 운영을 해보면서 거기서 발생하는 trouble issue를 찾아보고 해결해보고 싶습니다.
우리 구현해보고 싶었던 추가 기능들도 Reciper에 넣어보고 싶습니다.
회고를 쓰면서 제가 Reciper로 인해 정말 많이 성장했다는 것을 느꼈습니다.
좋은 팀원들을 만나서 좋았고 이런 플랫폼을 만든 제가 참 기특하기도 합니다.
앞으로도 Reciper와 같은 프로젝트를 만들어보며 계속 성장하는 개발자가 되고 싶습니다.