'회원 가입' 화면을 통해 유저 정보(이메일, 이름, 패스워드)를 입력받아 신규 회원 가입 처리를 수행하고 회원 정보를 DB에 저장. 유저는 '가입 준비' 단계에 있게 됩니다.
회원 가입 과정에서 입력받은 이메일로 회원 가입 확인 이메일을 전송합니다. 유저는 이메일을 확인하고 회원 가입 인증을 요청합니다. 이메일 본문에는 회원 가입 검증 요청 링크가 포함괴어 있습니다. 이 링크를 통해 회원 가입 인증 요청이 들어오면 가입 준비 단계에서 승인 완료 상태롤 변경됩니다. 이때 이메일 인증의 응답으로 바로 액세스 토큰을 전달하여 로그인 상태로 바꿉니다(사용자가 인증 후 다시 로그인 과정을 거칠 필요가 없도록).
회원 가입이 완료된 사용자가 이메일과 비밀번호로 로그인 요청을 보낼 경우 이를 처리. 로그인 기능은 사실 사용자 에이전트(브라우저, 모바일 앱 등)에 액세스 토큰을 발급하는 일입니다.
로그인한 사용자는 자신의 정보를 조회할 수 있습니다.
서비스 개발을 위해 부가적으로 해야할 일
환경 변수 설정: 서버는 여러 환경에서 실행됩니다. 개발자의 로컬 개발환경, 개발된 기능을 실제 사용자에게 배포하는 스테이지 환경, 그리고 실제 운영하는 프로덕션 환경으로 보통 구성합니다. 각 환경에서 사용되는 변수가 달라지는 것들이 있다면 환경 변수를 다르게 구성할 수 있어야 합니다.
요청 유효성 검사: 프론트엔드에서 들어오는 요청은 잘못된 값을 가지는 경우가 빈번합니다. 사용자가 값을 잘못 입력하기도 하고 프론트엔드에서 걸러지지 않은 잘못된 값이 유입되는 경우도 있습니다. 이 경우 서버에서는 핵심 로직을 수행하기 전에, 값이 제대로 전달되었는지 판단하여 잘못 전달된 경우라면 400 Bad Request 에러러 응답해야합니다.예를 들어 로그인 요청에서 이메일을 넣어야 하는데 이메일 형식이 아닌 문자열이 전달되면 에러로 처리해야 합니다.
인증: 사용자의 리소스에 접근하기 위해서는 권한이 필요하고 로그인 과정을 거쳐야합니다. 로그인을 거친 유저는 요청마다 로그인을 할 필요는 없고 인증 과정을 거친 다음 후속 동작을 수행할 수 있습니다. 인증을 처리하는 방법은 여러가지가 있습니다. 현재 만들 서비스는 토큰 방식, 그중에서도 JSON 웹 토큰을 이용하는 방식을 사용합니다.
로깅: 서버를 운용하기 위해서는 로그를 잘 기록해야합니다. 특히 이슈가 발생했을 때 원인을 빠르고 정확하게 파악하는 데에 로그는 매우 유용하게 사용됩니다. 사내 사용자가 무슨 동작을 수행했는지 감사 로그를 남겨 외부에 기록을 제출해야하는 경우도 있습니다.
헬스 체크: 서버의 심장이 잘 뛰고 있는지, 즉 서버의 상태가 양호한지 주기적으로 검사합니다. 만약에 서버 상태가 좋지 않다면 경골르 울려서 개발자가 빠르게 대응할 수 있게 방안을 마련해야 합니다.
CQRS: 복잡한 소프트웨어를 만들다 보면 소스 코드가 스파게티처럼 얽히게 되는 경우가 생깁니다. 예를 들어 데이터베이스에 변형을 가하는 명령과 데이터 읽기 요청을 처리하는 로직을 분리함으로써 성능, 확장성, 보완을 강화할 수 있습니다.
클린 아키텍처: 양파 아키텍처, 육각형 아키텍처에서 발전한 클린 아키텍처는 SW의 계층을 분리하고 저수준의 계층이 고수준의 계층에 의존하도록 합니다. 의존의 방향이 바뀌는 경우가 있다면, 의존관계 역정 원칙을 활용하여 안정적인 소프틀웨어를 작성할 수 있어야합니다.
단위 테스트: 소프트웨어에 변경이 생긴다면 반드시 테스트를 해야합니다. 단위 테스트는 유저의 입장에서 수행하는 테스트가 아닌 개발자가 테스트 코드를 이용하여 수행하는 최소단위의 테스트 기법입니다. 내가 만든 코드 조각이 동작하는 조건을 기술하고, 주어진 입력에 대해 원하는 결과가 나오느지 검사합니다.