앞으로 최종 프로젝트를 진행하면서 겪었던 일들을 기록하고자 한다
기능 구현 시작
드디어 업무를 분담하여 기능 구현을 시작하게 되었다.
우리팀의 백엔드 개발자는 총 3명이었는데, 그 중 한명이 취직을 하게되어 이제 2명이 백엔드 서버를 개발하게 되었다.
팀 인원이 줄어든 만큼, 각자 맡은 바 임무가 늘어나긴 했지만, 더 열심히 노력해서 프로젝트를 성공적으로 완수해보려 한다.
회원가입 구조
이메일, 닉네임에 유니크 설정을 적용하여 중복 검증 과정을 추가하였다. 또한 우리의 프로젝트는 users 테이블, userInfo 테이블, profilePhoto 테이블이 존재한다. 각각 1:1 관계로 설정되어 있는데, 사용자의 정보를 수정하기 위해 이메일과 비밀번호를 가져오는 것은 불필요하다라고 생각했고, 그래서 따로 사용자의 정보만 저장할 수 있는 테이블을 만들게 되었다.
그렇다보니 회원가입 시 각 테이블에 데이터를 생성해야 하는데, 생성 도중 예상치 못한 에러가 발생한다면, users 테이블에 데이터가 생성되었지만 userInfo 테이블에는 데이터가 생성되지 않는 상황이 발생할 수 있었다.
이러한 경우를 대비해 예상치 못한 에러가 발생한다면 모든 데이터가 롤백되도록 해야했고, 이렇게 하나의 작업 단위로 묶기 위해 트랜잭션을 적용하게 되었다.
로그인 구조
로그인 시 사용자의 정보를 서버에서 관리하는 세션 방식 대신, 사용자의 정보를 담은 JWT 토큰을 쿠키에 담아 클라이언트에게 보내도록 하였다. 세션 방식에서는 서버 측에서 세션 정보를 유지하기 위해 메모리나 데이터베이스를 사용해야 하기 때문이다.
하지만 쿠키에 JWT 토큰을 담아 보내는 경우, 쿠키가 탈취되면 만료될 때까지 사용될 수 있기 때문에 보안적으로 단점이 존재할 수 있는데, 이러한 문제를 어떻게 해결할 수 있을지 고민해봐야할 것 같다.
로그인 인증
로그인에 성공했을 때, 쿠키에 JWT 토큰을 담아 클라이언트에게 전달한다. 로그인이 필요한 기능에서는 받은 토큰을 다시 서버로 전달해 검증하고, 검증에 성공하면 JWT 토큰 안에 담긴 사용자 정보를 서버에서 전달받아 사용하도록 설계하였다.
NestJS에는 가드라는 것이 있는데, 이는 주로 사용자를 인증하거나 특정 권한을 요구하는 경우에 사용한다. 가든느 데코레이터를 사용하여 쉽게 구현할 수 있었다.
랭킹 조회 구조
랭킹 조회 기능에서는 사용자의 포인트를 기준으로 순위를 매기게 된다. 랭킹을 계산할 때 동점자를 고려해야 한다. 동점자가 여러 명인 경우, 동점자들은 같은 순위를 갖게 되고 다음 순위의 사용자는 그만큼 순위가 뒤로 밀리게 된다. 예를 들어, 포인트 점수가 10/9/9/9/8인 경우 순위는 1/2/2/2/5가 되는 것이다. 순위를 매긴 후, 사용자 정보에 순위 정보를 추가하여 클라이언트에게 보내줬다.
또한 고려해볼 것이 있는데, 현재 테스트에서는 이용자 수가 적기 때문에,67ms라는 시간dl 소요되어 데이터를 가져올 수 있었지만, 만약 사용자의 수가 10만명, 100만명이라면 사용자의 랭킹을 조회하기 위해서는 상당히 많은 시간이 소요될 것이다.
위와 같은 문제를 해결하기 위해 임의의 데이터를 삽입하여 테스트한 후, 최적화시킬 수 있는 방법을 확인해볼 생각이다.
팀원과의 소통 문제
기능을 구현하던 중 생각지도 못했던 문제가 발생했다. 데이터베이스 스키마에 제약 조건을 설정하는 부분이었는데, 나는 TypeORM의 synchronize라는 기능을 사용하면 자동으로 데이터베이스와 동기화된다는 것을 알고 있었기 때문에, 각 엔티티에 제약조건을 설정하였다.
하지만, 팀원은 MYSQLWorkbench와 같은 도구를 이용하여 미리 제약 조건을 설정한 후 작업을 진행하였다. 그 이유는 백엔드 코드에서 발생할 수 있는 실수나 오류를 사전에 방지할 수 있다라고 생각하셨던 것 같다.
이처럼 서로 소통이 부족한 채 작업을 진행하고 있었던 것이다. 따로 작업을 진행하게 되니 불필요하게 시간이 낭비되었고, 다시 작업해야하는 수고로움이 생겼다.
결국, 대화를 나눠본 결과 synchronize 기능을 사용하는 대신 TypeORM의 마이그레이션 기능을 사용하여 제약조건을 설정하게 되었지만, 다음부터는 이런 공통적으로 처리해야 할 부분에 대해서는 충분한 소통 후 작업을 진행해야 함을 깨닫게 되었다.
마무리
이번주도 쉽지만은 않았던 것 같다. 크고 작은 문제들도 있었는데, 갑작스럽게 팀원 한 분이 빠지기도 했고, 소통 부족으로 인한 문제도 있었다.
하지만, 기능 개발하는 것은 즐거웠고, 문제점을 개선해 나가는 과정 자체도 재미있었다.
다음주에 1차 스프린트가 종료되는데, 결과물이 어떻게 나올지 기대가 되고, 또한 제대로 결과물이 나오지 않더라도 그 문제들을 해결하는 과정속에서 많은 것을 배울 수 있을 것 같아 기대된다.
