[42GG] 시퀀스 다이어그램 - 로그인에 매칭을 살짝 곁들여

우리 프로젝트에 정식으로 멘토님이 배정되거나 한 것은 아니었지만, 오며가며 많은 조언을 주시고 도움을 아끼지 않아주신 이호준 멘토님이 계십니다. 저희 프로젝트 팀에 관심을 많이 가져주시고 도와주셔서, 그리고 좋은 기회까지 주셔서 이 자리를 빌어 크게 감사의 마음을 전하고 싶습니다. 이호준 멘토님 왕감사합니다!

시퀀스 다이어그램은 전적으로 멘토님께서 제안해주셔서 그려본 것입니다. 설계 단계에서 미리 그리고 시작했다면 더 좋았겠지만, 개발 단계에서 그렸는데도 큰 도움이 되었기에 포스팅을 하게 되었습니다.

로그인 시퀀스

우여곡절 끝에 개발된 로그인 시퀀스이다. 42서울 내부에서만 사용할 계획이었고, 구성원들만 이용할 수 있는 탁구대에 대한 서비스였기 때문에 42OAuth를 통한 로그인만 구현했다. 아직 구현되지 않은 부분도 있지만, 보안상 어디인지는 밝히지 않고 시퀀스를 설명해보려 한다.

크게 구분하면 다음과 같다.

1. 유저는 42GG 서비스에 접속해 로그인 버튼을 누른다.
2. 42로 리다이렉션된 유저는 42에 로그인해 OAuth 토큰을 발급받고 42GG 서버에 건네준다.
3. 42GG 서버는 OAuth 토큰을 갖고 42에 Access 토큰을 요청한다.
4. 42GG 서버는 반환받은 Access 토큰으로 42에 해당 유저의 정보를 조회를 요청한다.
5. 반환받은 유저 정보를 기반으로, 기존 유저라면 로그인을 시켜주고 신규 유저라면 유저를 생성한다.
6. JWT로 Access 토큰과 Refresh 토큰을 발급한다. Access 토큰은 반환해 LocalStorage에 저장하고, Refresh Token은 Cookie Storage에 저장하고 백엔드에선 DB에 저장한다.
7. 이제 해당 유저는 Access 토큰이 있으면 로그인하지 않아도 서비스를 이용할 수 있게 된다.
8. Access 토큰은 설정된 시간이 지나면 만료되는데, 만료되었지만 유저 정보가 정확하다면 유저의 Cookie와 백엔드 DB의 Refresh Token을 비교한다.
9. 일치한다면 별도의 로그인 절차 없이 새로 Access/Refresh 토큰 쌍을 발급하고, 아니라면 로그인 페이지로 보낸다.

로그인 부분은 팀원이 구현해 잘 모르는 부분이었지만, 시퀀스 다이어그램을 통해 코드를 쉽게 이해할 수 있었다. 구현이 부족한 부분을 채워나가는 데 있어서도 큰 도움이 됐다.

어떠한 문제가 생겼거나 보완할 점이 필요할 때 시퀀스 다이어그램을 보면 쉽게 어디를 어떻게 작업할지 알 수 있었다. 예컨대 현재는 42에 저장된 유저 정보가 바뀌어도 42GG에선 갱신되지 않는데, 20번 화살표가 들어있는 박스에서 42GG DB에 담긴 정보와 새로 받아온 정보가 일치하는지 확인하면 된다. 일치하면 넘어가고, 않는다면 정보를 갱신해주면 된다.

그 뿐 아니라, 리팩토링을 하거나 향후 확장을 할 경우에 어떻게 할지도 쉽게 파악할 수 있다. 예컨대 다른 OAuth 로그인을 추가하는 상황을 생각해보자. 5번부터 19번까지는 거의 일치할 것이다. 이부분을 추상 클래스나 인터페이스로 추출하고, 42 OAuth에 대한 구현체와 다른 OAuth에 대한 구현체를 만들 수 있을 것이다.

그리기 전에 멘토님께서, 리팩토링을 잘 하려면 이런 걸 그려야 좋다고 말씀하셨는데, 다 만들고 나서 멘토님께 조언까지 듣고 나니 어떤 말인지 감을 잡은 것도 같다.

매칭 시퀀스

다음은 우리 서비스의 가장 중요한 로직인 매칭에 대한 시퀀스 다이어그램이다. 서비스 쪽에서 단순하게 조회만 담당하는 부분들은 제외하고, 무언가 로직이 들어가는 것들을 위주로 그려보았다. 여기서는 비교적 복잡한 부분들을 부문별로 링크를 타고 들어가 볼 수 있게 되어있는데, 사진으로 가져왔기에 링크를 누를 순 없다. 그 친구들 사진은 다음 포스팅을 기대해주시라.
어떤 시퀀스인지 설명하는 것 보다는 다이어그램이 더 잘 말해주는 것 같아 설명은 생략한다. 링크로 달려있는 4개의 시퀀스가 중요한 부분이라 나머지 부분은 굉장히 간단하게 되어있다. 다만 이 다이어그램에서는 시퀀스보다 중요하다고 생각하는 부분이 있는데, 왼쪽 사이드에 있는 에러 코드들이다.
처음 개발할 때는 에러에 대한 큰 고민을 하지 않고 백엔드 내부적으로 분류해서 에러 반환을 했는데, 이게 엄청나게 큰 실수였다. 프론트와 연결하자 마자, 에러 모달을 띄워야 하는데 무슨 에러인지 구분이 안가버리는 대박적 문제가 났다… 여기서도 또 이호준 멘토님이 등장하시는데, 항상 프론트와 백이 에러에 대한 사항을 미리 정리하고 문서화해서 공유하라는 말씀을 해주셨다.

그래서 이렇게 함께 에러에 대한 처리를 약속하고 문서로 만들어 작업하게 됐다. 첫 프로젝트에서 이런 걸 잘 배워가서 참 다행이라고 생각한다.

오늘 가장 하고싶었던 얘기는 시퀀스 다이어그램을 쓰고 어떤 장점을 경험하고 느꼈는지인데, 요약해보자면 다음과 같다..

1. 시퀀스 다이어그램을 쓰면 인수인계가 편안해진다! 로그인 파트 코드로 볼때는 현기증이 살짝 났지만, 시퀀스를 알고나니 어떤 부분이 어떤 코드인지 보다 쉽게 이해할 수 있었다.
2. 장애 해결을 재빠르게! 로그와 시퀀스 다이어그램을 확인하면 어디서 장애가 생겼고 그 원인이 어디쯤에 있는지 쉽게 알 수 있다.
3. 리팩토링에도 좋아요. 시퀀스가 명확히 드러나고 공통되는 부분을 파악하기 쉽기 때문에, 향후 코드를 정리하거나 확장할 때 도움이 된다.

한편 멘토님께 보여드리고 알게 된 아쉬운 점이 있다면, 백엔드 시퀀스 다이어그램에는 어떤 데이터들이 오가는지 드러나야 한다는 점이다. 이 부분을 설명해주시며 '하나의 화살표가 어떤 데이터를 드리븐하는지가 시퀀스 다이어그램의 핵심이 되어야 한다'고 말씀해주셨는데, 뭔지 잘 모르지만(ㅠㅠ) 너무 멋있게 느껴졌다. 시퀀스 다이어그램도 starUML 사용해서 무작정 그렸는데, 툴을 어떻게 더 잘 사용할지, 어떻게 더 좋은 시퀀스 다이어그램을 그릴지에 대해서도 공부해야겠다.

To be continued…

글이 길어져서 매칭 시퀀스에 속하는 4개의 시퀀스에 대해서는 다음 포스팅에 적어보겠습니다. 아마도 시퀀스 다이어그램으로 뭘 할 수 있었다 보다는, 로직 구현을 어떻게 했는지에 초점을 맞출 것 같습니다.