[42GG] 3기 개발일지 1

기존 시스템 분석하면서 왜 이렇게 되어있나 싶은 로직과 DB를 마주하였다.

https://www.figma.com/file/uiJL8G0rKLp8ZIJc5Rj7Fy/42GG?node-id=0%3A1&t=MIs1LoNUqxts1I5o-1 

DB가 제일 심각했는데,

실제 DB와 ERD가 차이가 있기도 했고, user 테이블의 외래키를 id(INT) 를 거는 테이블과 intra id (VARCHAR)를 외래키로 거는 테이블의 공존하는 상황이었다.

원래 42gg 3기 프로젝트 진행 목적은 리팩토링이었다. 성능 개선이나 코드 가독성 향상을 목표로 하고 있었는데, 레거시 파악을 하다 보니 시스템 개선이 시급하다고 생각했다. 깔끔하지 않은 뼈대를 고치다보면 누더기가 될 뿐,,

 

하나의 외래키를 여러 테이블에서 가지고 있는 부분도 있고, 테이블 설계부터 중복되는 데이터가 있다보니 실제 DB에 어떤 컬럼은 다 NULL값만 들어가는 경우도 있었다.

또 고칠 필요성을 느꼈던 부분은 OAuth. spring security 를 통해 jwt 토큰을 만들어주지만, jwt 토큰을 체크해주는 곳에서 막혀 결국 db에 refresh token, access token 을 저장하고 db에 저장된 값과 요청으로 들어온 값을 비교하여 값이 같으면 로그인 성공으로 처리되고, jwt 토큰에는 role만 저장되어 role을 통해 권한을 체크하고, db 에 저장된 access token을 통해 user id 를 찾아 user를 찾는 로그인 방식이었다.

1기 코드에서는 role check 가 컨트롤러 메소드 하나하나 jwt 토큰 체크해서 가져오는 로직으로 되어있고, 2기 코드에서는 AOP 로 처리되어 있는 것을 볼 수 있었다.

 

이번에 팀장을 맡게 되면서 백엔드는 시스템을 갈아 엎기로 결정했다. 기존 코드에 사용하지 않는 클래스가 많아 구분이 어렵고, 기존 시스템에 있던 기능을 사용자 요구에 따라 변경할 경우, DB부터 변경해야 하기 때문에 처음부터 깔끔하게 하기로 했다.

Entity Class 에 있던 EnumType들이 다 int 타입이라 DB에서 알아보기 힘든데 또 그중에 딱 한개만 문자로 저장되게 되어있었다.

 

PK 인 id 는 int 타입으로 되어있어서 이것도 bigint 로 바꾸려고 했더니 다른곳에 외래키가 걸려있어 바로 바꿀 수 없었다. 어차피 현재 사용자가 int 타입을 넘을 위험은 없어서 다행이긴 하다. 연관된 외래키들을 삭제하고 타입을 변경해야한다.

(이번 경험을 계기로 특히 DB는 깔끔하고 간결하게,,외래키는 빼는 것이 운영 & 유지보수에는 편하다는 것을 느낌,,)

 

바로 기획회의에 들어가려다가 프론트는 아직 온보딩으로 기술스택 공부중이라 레거시 파악이 안된 상태여서 백엔드 팀원들에게는 테스트코드, DB(정규화, 인덱스, 트랜잭션, 락,,), 디자인패턴 공부하라고 하고 OAuth 만 미리 구현 중이다.