요구사항 분석(시퀀스 다이어그램, ERD, API 설계) - 항해 플러스 회고 (3주차)

 

 

 

들어가며

이번 주차는 마지막 10주까지 Develop할 시나리오를 선택하고, 해당 시나리오에 대한 요구사항에 대해 정리하는 한 주였다.

각 조마다 같은 시나리오를 선정해서 진행하는 것이 더 좋을 것이라는 조언을 듣고, 우리 조는 제일 난이도가 높은 주제인 "콘서트 예약 서비스"를 선택했다.

 

 

시나리오

콘서트 예약 서비스에서 제일 중요하게 구현해야 할 기술의 핵심은 바로 "대기열"이다.

서버의 한정된 자원을 가지고 트래픽이 급증했을 때, 대처할 수 있는 방법으로 대기열을 만들어서 서버의 처리율을 조절하는 방법이 있다.

- 서비스를 이용할 토큰을 발급받는 API를 작성합니다.
- 토큰은 유저의 UUID 와 해당 유저의 대기열을 관리할 수 있는 정보 ( 대기 순서 or 잔여 시간 등 ) 를 포함합니다.
- 이후 모든 API 는 위 토큰을 이용해 대기열 검증을 통과해야 이용 가능합니다.

 

위와 같은 구현 스펙이 정의되어 있었고, 우선 어떤 식으로 구현해야 할지 고민해 보았다.

 

1. JWT를 발급하여 해당 payload에 유저의 식별자, 대기 순서, 잔여 시간, 활성화 여부 등을 작성한다.

 

 -> 이 경우에 만약 대기 순서나, 활성화 여부가 바꾼다면 토큰 자체가 변형이 되거나 새로 발급받아야 한다. 또한 이 과제에서 유저에 대한 인증, 인가가 아닌 해당 콘서트 대기열에 대한 토큰이므로 대기열을 위한 검증 목적이라고 생각되었다. 따라서 JWT를 구현하는 것은 이번 과제에 바람직한 방향은 아니라 생각했다.

 

 

2. 콘서트, 유저 별 UUID를 발급하여 해당 값을 Key로 가지는 유저 대기열 토큰을 발급한다.

 

-> 결론은 이 방법을 채택했다. 고유 UUID를 발급한 유저가 해당 값을 가지고 조회를 하면 대기열에 대한 부가 정보를 조회할 수 있게끔 설계했다. 즉, 토큰의 key가 UUID가 될 것이고 부가 정보는 value가 되는 식이다.

 

 

 

목표

이번 과제에서 제출해야 할 것은 요구사항을 분석하여, 시퀀스 다이어그램, ER 다이어그램, API 명세, Mock API, 패키지 설계를 하는 것이었다. ERD는 그래도 자주 그려보았지만 시퀀스 다이어그램을 직접 그려보는 것은 처음이었다. 코치님들도 실무에서 설계 과정에 시퀀스 다이어그램을 그리는 것은 거의 필수적으로 한다는 얘기를 듣고 이번 기회에 시퀀스 다이어그램이 무엇인지, 어떻게 그리는 것이 보는 사람으로 하여금 시스템 흐름에 대해 잘 이해할 수 있는지 공부하는 시간을 가졌다.

 

 

새로 알게 된 것

요구사항을 정의하며 시퀀스 다이어그램을 처음 그려보았다. 확실히 내가 구현을 필요로 하는 API 동작에 대해 직관적으로 볼 수 있어 나중에 코드로 만들 때 전체 흐름에 대해 이해하고 만들 수 있어 생산성이 좋아질 것 같은 생각이 든다. 문서가 작성할 땐 너무 귀찮고 빨리 코드치고 싶지만, 이런 경험들을 가지고 설계 문서 작성이 얼마나 큰 힘이 되는 지를 직접 깨닫게 되었으면 좋겠다.

 

 

앞으로 개선할 것

이번주 코치님의 피드백 결과 내 설계에 문제가 되는 부분이 있었다.

 

1. 유저와 대기열의 강결합

기존에는 대기열 테이블에 userId를 포함해 두어, 토큰값을 가지고 어떤 유저인지 찾아가는 방식을 생각했었다. 하지만 코치님께서 아래와 같은 피드백을 주셨다.

 

저라면 유저와 토큰을 강결합 시키지 않을 것 같아요. 예를 들면, 세션 기반으로 대기열 토큰을 매핑하는 거죠. 우리가 은행에서 번호표를 뽑을 때, 우리의 신분증을 제출하지 않듯이, "순번이 된 번호표" ( 순번이 된 세션 ) 로 입장시키고, "신분증" ( 유저 인증 정보 ) 로 서비스를 이용하게 할 것 같습니다.

 

위의 예시를 듣고 깊은 깨달음을 얻었다. 지금까지 생각했던 건 대기열의 토큰을 통해 어떤 유저에게 발급되었는지를 알아가게 했는데, 토큰 성격 상 그런 역할까지 가지게 할 필요가 없던 것이다. 유저의 정보는 별도의 인증(JWT 같은)으로 체크를 하면 되는 것이고, 토큰은 대기열 그 자체에 대한 정보만 알면 되는 것이었다. 해당 피드백을 가지고 대기열 테이블의 userId 필드를 제거하여, 유저와 대기열의 강결합을 제거했다.

 

2. Restful한 API 설계

여기서 많은 감점 요인이 있었다. restful한 것이 무엇 일지에 대한 깊은 고민을 해본 적이 없었던 내 실수다. 단순히 '메서드만 잘 지키면 되겠지', '동사 형태로만 작성 안 하면 되겠지' 였는데, 그 이외에 지켜야 될 규칙들이나, 일관성 있는 설계가 이루어지지 않았었다. 특히나 uri에 표현되는 자원들에 대한 형태를 복수형태로 작성해야 된다는 것을 놓쳤고, 이 부분에 대해서 좀 더 공부하고 어떻게 작성할 지 더 고민해봐야겠다.

 

 

마치며

이번 주는 쉬어가는 한 주가 될 것이란 말을 들었는데, 오히려 코드 구현했던 1~2주보다 더 어렵고 고민이 많았던 것 같다. 이번 주 결과는 좋지 않았지만 피드백을 반영해서 문서를 수정하고, 다음 주부터는 실수 없이 잘 구현해야겠다.