레벨 4는 프로젝트가 주가 아니라는 생각에 레벨 4 초반에는 프로젝트보다는 개인 공부에 집중했었다. 백엔드 쪽 요구사항으로 인덱스와 스레드 설정이 주어졌었는데, 오히려 잘 모르다 보니 오래 고민하고 오래 테스트 해봐야 한다는 것을 몰라서 쉽게 끝낼 수 있을 거라고 착각했다. (결과적으로 마지막 주에 피봤다.)
인증 인가 방식 변경
백엔드 요구사항이 따로 나오기는 했지만, 프론트엔드와 백엔드가 합쳐서 부족한 기능을 채워넣는 것도 소홀히 해서는 안되는 부분이었다. 이번 스프린트에 이야기가 나온 것은 인증, 인가에 관련된 내용이었다. 우리 팀은 인증 인가에 JWT를 활용한 방식을 사용하고 있었는데, 보통 토큰 방식의 단점을 보완하기 위해 Refresh Token도 함께 사용하는 편이지만 레벨 3 때는 그닥 필요성을 못느껴서 Access Token만 사용했었다. 그러다가 이번 스프린트 들어
- Access Token만 사용하면 로그인이 너무 자주 풀린다.
- 현재 우리가 Access Token을 사용하고 있는 방식은 공격에 취약할 수 있다.
의 이유로 Refresh Token을 사용하자는 의견이 나왔다. 하지만 Access Token과 Refresh Token을 어디에 저장해서 사용할지를 정하는 과정이 쉽지 않았다. 특히나 사용성 뿐 아니라 보안 측면에서도 함께 접근했기 때문에 더더욱 그랬다.
Access Token과 Refresh Token에 대한 논의는 Access Token과 Refresh Token을 어디에 저장해야 할까?를 참고하자.
인덱스 설정 및 스레드 설정
원래 나는 이번 스프린트에 어드민 페이지를 만들기로 했었다. 이유는 3레벨 방학식 때 DB를 날려먹은 죄로 다시는 DB를 날려먹지 않기 위해 그래서 열심히 어드민 페이지를 만들고 있었는데, 데모 데이를 일주일 남기고 사건이 터졌다.
이번 스프린트에 위와 같은 요구사항이 주어져서, 적절한 설정 값을 정하기 위해 성능 테스트를 진행했는데, 더미 데이터를 넣어주고 vUSER 값이 늘어나니 수십 초가 걸리는 요청도 있었고 아예 응답이 돌아오지 않는 요청도 있었다. 우리 도메인 자체가 조회 및 정렬 측면에서 복잡한 도메인이다보니 조회 성능을 챙기는 것이 무엇보다 중요했는데, 그런 부분을 전혀 생각하지 않은 설계가 이루어졌던 탓이다. (애플리케이션 레벨의 설계 보다는 데이터베이스 테이블 설계나 인덱스를 설정하는 부분이 잘못된 탓이 컸다.) 때문에 장장 일주일을 MySQL 콘솔과 책만 보면서 쿼리를 튜닝하고 인덱스를 설정하는 시간을 가졌다.
참고로 결국 인덱스 설정하느라 어드민 페이지는 못 만들었다. 스프린트 6에 들어가서 만들 듯 싶다.
스프린트 5가 준 교훈
레벨 3 스프린트 4개를 하면서 단 한번도 시간이 엄청 촉박했다거나, 발표 당일까지 발표 자료도 완성되지 않은 경우는 없었다. 하지만 이번에 처음으로 그런 상황을 맞이했다. 레벨 4의 스프린트는 레벨 3의 스프린트와 다르게 한 달짜리였는데, 요구 사항 볼륨 자체는 비슷하다 보니 이번에도 2주면 되겠지 하고 앞의 2주를 프로젝트에 전혀 투자하지 않은 탓이 크다. 확실히 미리미리 해두는 것의 중요성을 느낀 스프린트인 것 같다. 정말 마지막 한 주는 새벽에도 잠을 포기해가며 데이터베이스 자료를 조사하고 코드를 짰던 것 같다. 당연히 건강에도 치명타
그래서 우리 팀원들 모두 스프린트 5 회고 시간에 스프린트 6에서는 미리미리 요구 사항 및 우리가 구현하고 싶은 부분들을 계획을 세워서 진행하자고 합의했다. 개인적으로는 미션도 중요하지만 프로젝트에도 적용해보고 싶은 부분들이 많아서 미리미리 프로젝트에 시간을 좀 투자할 것 같다.
잘읽었어요