공대생들 사이에서 빛이 되어준 디자이너 바리 님이 만든 이번 서비스 로고 이미지.

오늘 “소규모 학원&과외 선생님을 위한 학생 성적 관리 서비스” Great 의 첫번째 베타 버전이 개발 완료되어 배포되었다. 아직 프로젝트가 완전히 종료된 것은 아니지만 중간정리가 필요할거 같아서, 이렇게 글을 써 본다. 프로젝트를 진행하면서 발생한 여러가지 이슈와 이를 해결하면서 얻은 교훈 등을 정리하고, 끝으로 앞으로 해결해야할 점들을 적어보았다.

이게 왜 됨? 이게 왜 안됨? : 프로젝트는 이슈와 함께

이번 프로젝트에서도, 여러가지 이슈가 있었고 그것들을 해결하면서 여러가지를 배울 수 있었다.

만능 클래스 : 클래스에게 어떤 책임을 부여해야 하는가?

이번 프로젝트의 핵심 도메인에는 “선생님”, “학생”, “시험”, “성적” 이 있다. 따라서, 이들 도메인을 표현하는 클래스들은 여러 기능들에서 등장한다. 그 중 선생님을 표현하는 Teacher 클래스를 예를 들어 살펴보자.

아래는 Teacher 클래스의 코드다.

package com.example.demo.model;

import lombok.Builder;
import lombok.Getter;

@Builder
@Getter
public class Teacher {
    private int id;
    private Email email;
    private Subject subject;
    private String nickName;
    private Password password;
}

이 클래스는 아래 사진에서 보이는 것 처럼 여러 클래스에서 사용중이다.

Teacher 클래스 사용위치. Teacher의 변경은 잠재적으로 저 모든 클래스들의 변경을 가져올 수 있다.

선생님은 회원가입 시 이메일, 담당 과목, 닉네임, 비밀번호를 입력해야 한다. 이 데이터들은 여러가지 상황에서 사용된다. 이메일과 비밀번호는 로그인을 할 때 사용되고, 담당 과목은 학생을 추가할때 사용된다. 닉네임은 당장은 사용되지 않지만 추후 프로젝트를 확장할때 사용될 예정이다.

그렇다. 이들 정보들은 모두 선생님에 속한 데이터이나, 선생님과 관련된 여러 기능을 수행할 때 항상 필요한 데이터는 아니다. 즉, Teacher 클래스는 회원가입에 사용하기에는 적합하지만, 로그인, 회원정보 수정, 회원정보 조회 등에서 사용하기에는 불필요한 정보들이 포함되기에 적합하지 않다. 따라서 이런 기능들을 구현할때 Teacher 클래스를 사용하는 것은 적합하지 않다.

“적절한 책임” 에 따라 분리되어야 할 클래스라는 뜻이다.

결론적으로 다음 원칙에 따라 클래스들을 분리하였다.

<aside> 💡 하나의 DTO 는 오직 하나의 API 에서만 사용한다.

</aside>

또한 패키지 구조를 변경하여, dto 패키지의 하위 패키지로 request, response 패키지를 추가해 각각 클라이언트의 요청 body, 서버의 응답 body 를 표현하는 클래스들을 담도록 하였다.

이 변경을 통해 각 기능들의 상세 스팩 변경이 발생할 시 무엇을 변경해야 하는지 확실하면서도, Side-Effect 를 최소화 할 수 있게 되었다.

인증&인가 : 토큰과 쿠키 그리고 CORS

REST API를 제공하기 때문에 JWT 기반의 AccessToken 과 RefreshToken 2가지 토큰을 이용한 인증방식을 채택했다. 이 인증 방식은 토큰들을 어디에 저장하는지, 토큰에 무었을 저장하는지, 토큰의 유효기간은 어떻게 하는지 등에 따라 많은 차이가 생기게 된다. 이번 프로젝트에선 로그인 시 응답의 body에 AccessToken을, HttpOnly 쿠키에 RefreshToken을 저장하는 방식을 채택하였다. HttpOnly 쿠키는 브라우저를 통해 JavaScript로 접근할 수 없기때문에 리프레쉬 토큰이 탈취될 일이 없으면서도 쿠키는 기본적으로 모든 요청에 자동으로 포함되기에 엑세스 토큰이 만료되어 갱신요청을 보낼때에도 아무 문제가 없기 때문이다. 그렇게 비극은 시작되었다.