1차 프로젝트가 예선이라면 2차 프로젝트는 본선이었다. 배운 내용을 최대한 사용해서 가능한 많은 기능을 구현하고 싶었기에 그에 따라 작업량도 많았고 스트레스도 많이 받았지만 결과는 달콤했다. 이번 회고는 기획, 데이터베이스 모델링, 웹소켓, 테스트 코드, 느낀 점으로 나누어 회고를 작성했다.
기획
2차 프로젝트는 직접 기획을 했다는 점에서 1차 프로젝트와 큰 차이가 있다. 단순히 나이키를 바탕으로 한국 10~20대 소비자 타켓으로 기획한 1차 프로젝트와 달리 KREAM의 한정판 판매와 경매라는 특징을 뽑아내 국내 예술품을 판매하는 경매 사이트라는 기획으로 녹여냈다. 사실 기획은 개발자의 영역이 아닌데 굳이 따로 기획을 만들어서 귀찮게 할 필요가 있을까라는 생각이 들었다. 하지만 지금 생각해보면 기획은 참신했고 그로 인해서 우리의 프로젝트가 다른 팀들의 프로젝트보다 더 돋보였던 것 같다.
데이터베이스 모델링
1차 프로젝트와 마찬가지로 데이터베이스 모델링은 역시나 힘들었다. 경매라는 개념을 구체적으로 생각한 적이 없기에 필요한 테이블을 만들고 관계를 설정하는데 많은 시간을 소비했고 완벽까지는 아니더라도 필수적인 부분을 고려했다고 생각했지만 이 역시 착각에 불과했다. 프로젝트를 진행하면서 필요한 컬럼 추가, 제약 조건 설정 및 해제 등 문제들이 터져나왔다... 팀원분과의 의논을 통해서 수정했지만 1차 프로젝트의 실수가 다시 그대로 표출되서 너무 아쉬웠다. 단순히 이론을 안다고 되는 것이 아니라 수많은 연습과 시행착오를 거쳐 경험이 중요한 역할을 하는 작업인 것 같다.
웹소켓
프로젝트의 핵심 중의 핵심인 웹소켓! 기획에 따라 경매는 실시간으로 진행되어야 한다. 이를 보자마자 소켓 통신이 바로 생각이 났지만 사실 2주라는 시간 내에 제대로 구현할 수 있을지 확신이 들지 않았다. 멘토들에게 기획을 설명하는 세션에서 멘토님 한 분이 실시간이면 두 가지 방법이 있는데 그 중 하나가 웹소켓 프로토콜이었다. 하지만 그 멘토님도 시간이 많지 않고 어려울 수 있기 때문에 프론트엔드에서 setInterval 함수를 사용하는 방안을 제시하셨다. 이 경우 실제 실시간은 아니지만 1초마다 페이지를 갱신해서 경매가 실시간이라는 착시를 줄 수 있다. 하지만 개인적으로 네트워크에 관심이 많고 새로운 기술을 적용하고 싶었기에 주말 동안 과연 구현할 수 있을지에 대해서 연구했다. 그리고 웹소켓으로 구현하기로 결정내렸다!
공식 문서와 블로그를 보면서 코드를 작성했는데 구현 자체는 크게 어렵지 않았지만 문제가 발생했다. 상품마다 오직 하나의 경매방을 만들어야 하는데 경매방을 하나만 생성되도록 구현한 것이었다. 이 문제는 공식 문서의 HTTP/HTTPS를 공유하는 다수의 웹 소켓 서버를 만드는 코드를 참조해서 이를 수정할 수 있었지만 지금 생각해도 많이 허술하기 때문에 리팩토링 시 많은 수정이 필요할 것 같다. 이렇게 해서 구현이 완료될 줄 알았는데 또 다른 문제가 남아있었다. 바로 MVC에 패턴에 맞게 웹 소켓 코드를 분해하는 것이었다. 하지만 이는 프로젝트 발표 전까지도 해결할 수 없었다. 여러 시도를 했지만 해결할 수 없었고 검색을 계속 한 끝에 ExpressJS와 함께 사용되는 웹 소켓 패키지가 있었는데 그 패키지가 2019년 이후부터 업데이트가 되어있지 않아 사용하지 않았다(내가 사용한 패키지는 ws 패키지이다.).
발표날 하루 전 시연 연습을 하는데 큰 문제가 발생했다. 바로 상품의 경매방에 모든 참가자들이 이상하게 같은 식별자를 할당받아서 데이터베이스에서 항상 같은 튜플에 값이 갱신되었다. 아쉽게도 오류의 원인을 몰라서 코드 수정없이 시연을 했는데 겉으로 보기에 문제는 없어서 깔끔하게 끝났다. 발표 이후 공식 문서를 꼼꼼히 읽은 결과 handleUpgrade 메소드에서 참가자 아이디를 할당해야 한다는 것을 알게 되었고 문제를 해결했다. 공식 문서는 어렵지만 역시 답은 공식 문서에 있는 것 같다.
테스트 코드
1차 프로젝트에서 예외 조건에 대해서 적었는데 2차 프로젝트에서는 이를 방지하기 위해 테스트 코드 작성법을 배웠다. API를 만들고 Postman으로 단순히 몇 개의 케이스를 테스트하는 것은 소프트웨어가 정상적으로 작동하는지 검증하는데 결코 충분하지 않다. 테스트는 크게 단위 테스트, 통합 테스트, 인수 테스트로 구성되는데 주로 이 중에서 클래스와 함수를 테스트하는 단위 테스트 코드를 중점적으로 작성했다. Jest 패키지를 사용해서 단위 테스트 코드를 작성했는데 생각보다 시간도 많이 걸렸고 상당히 어려웠다. 세션을 진행하신 멘토님이 API 코드 작성보다 테스트 코드 작성이 더 많은 시간이 걸리고 어렵다고 하셨는데 그 말이 무슨 말인지 이해할 수 있었다. 카카오 로그인, 웹 소켓과 같은 기능은 테스트 코드 작성 방법도 몰랐고 시간이 많지 않아서 테스트 코드를 작성할 수 없었다. 리팩토링에는 모든 API에 대해서 테스트 코드를 작성할 것이다.
느낀 점
1차 프로젝트에서는 PM(Project Manager)를 맡았고 2차 프로젝트는 PM(Product Manager)를 맡았다. 이름 그대로 프로젝트 관리가 아니라 제품/서비스에 대해서 분석하고 파악해서 기획안을 제시하고 프로젝트 시연을 하는 역할이다. KREAM을 분석한 후 경매와 한정판 판매라는 특성을 기반으로 국내 예술품 경매라는 기획을 도출하게 되었다고 멘토님들에게 말했는데 이 점을 높이 평가하셨다. 발표날 아침부터 긴장했지만 이상하게 발표 시작 5분 전부터 마음이 편해졌다. 더 이상한 것은 발표를 하는데 내가 이거를 즐기고 있다는 느낌을 받았다. 이번 프로젝트에서 느낀 점은 하기 싫은 것 혹은 어렵다고 느끼는 작업이 있으며 도전 정신을 가지고 해야 한다는 것이다. 영어 회화 공부를 위해서 구독한 라이브 아카데미의 빨모 선생님이 자기는 하기 싫다는 느낌을 받으면 오히려 한다고 말씀하셨는데 나도 그게 무슨 말인지 이해할 수 있는 프로젝트였다.
댓글 없음:
댓글 쓰기