[레벨 3 회고] 하루스터디 7주차 회고

버그 리포팅 🐞

월요일은 버그 리포팅을 진행했습니다. 다른 팀들의 서비스를 사용해보고 어떤 버그가 있는지를 확인하는 방식이었습니다. 저희 팀도 다른 팀들로부터 버그 리포팅을 받았는데, 생각보다 버그가 많아서 놀랐습니다...ㅋㅋ

 

버그 리포팅이 1시간정도 진행되었던 걸로 기억하는데, 짧은 기간에 짧은 인원이 진행했음에도 불구하고 버그 관련 이슈가 10개 정도 생겼던 것 같습니다. 실제 사용자가 사용하면 더욱 버그가 많을텐데, 테스트 서버 및 QA의 중요성을 느끼는 계기가 되었습니다.

 

인증 플로우 구현(feat. Oauth2, JWT)

이번주는 기능 개발에만 집중했었습니다. 원래 하루스터디 백엔드 팀원들은 몹 프로그래밍을 자주 했었는데, 이번에는 시간이 부족할 것 같아서 페어 프로그래밍을 진행하게 되었습니다.

 

저랑 마코가 인증 관련 기능을 맡고, 모디랑 히이로가 로깅 / 메트릭 시각화를 맡았습니다. 인증 관련 기능은 처음 만들어보는 거라 처음에 플로우를 이해하는데 어려움을 겪었지만, 마코랑 코드 한 줄 한 줄의 의미를 분석해가며 인증 기능을 구현한 결과 지금은 어느정도 플로우가 머리속에서 그려지는 것 같습니다.

 

JWT의 경우에는 access token 발급용으로만 사용하고 있고, refresh token의 경우에는 UUID로 refresh token rotation 방식을 적용했습니다. 토큰 발행 및 로그인 기능까지는 구현이 되어서 이제 비즈니스 로직을 사용하기 위한 실질적인 인증 및 인가 기능만 구현하면 되는데, 다음주 월요일이나 화요일 내로 완성될 것 같습니다.🥸

 

 

커스텀 어노테이션으로 예외까지 자동 문서화하기

금요일에 프론트엔드 크루들이 '예외 상황까지 문서화가 되면 좋겠다' 라고 이야기해줘서, 마코랑 제가 예외 상황들을 어떻게 문서화할지 고민하게 되었습니다.

 

단순히 노션이나 Wiki에 작성하면 되기는 하지만, 이미 '문서가 코드를 따라가지 못하는 상황'을 많이 겪었기 때문에 손수 문서를 작성하는 방식은 지양하고 싶었습니다. 

 

현재 하루스터디팀은 Swagger를 통해 API 명세를 생성합니다. 따라서 예외 상황까지 Swagger로 자동화하면 어떨까? 와 같은 생각이 들었습니다.

 

하루스터디팀은 아래와 같이 예외에 대한 상태코드, 메세지, 에러코드를 한 곳에서 관리하고 있습니다.

public class ExceptionMapper {

    private static final Map<Class<? extends Exception>, ExceptionSituation> mapper = new HashMap<>();

    static {
        setupMemberException();
        setupPomodoroContentException();
        setupPomodoroProgressException();
        setupRoomException();
        setupAuthException();
    }

    private static void setupMemberException() {
        mapper.put(MemberNotParticipatedException.class,
                ExceptionSituation.of("멤버가 해당 스터디에 참여하지 않았습니다.", NOT_FOUND, 1000));
        mapper.put(MemberNameLengthException.class,
                ExceptionSituation.of("멤버의 닉네임 길이가 유효하지 않습니다.", BAD_REQUEST, 1001));
        mapper.put(MemberNotFoundException.class,
                ExceptionSituation.of("해당하는 멤버가 없습니다.", NOT_FOUND, 1002));
    }
    
    // 생략
}

이런 정보를 이용해 Swagger를 커스터마이징한다면 예외까지 자동으로 문서화가 가능해보였습니다. 따라서 커스텀 어노테이션을 만들어 아래처럼 처리가 가능하도록 구현했습니다. (회고이기에 자세한 구현 과정은 생략하겠습니다)

    @Operation(summary = "스터디 진행도 조회")
    @SwaggerExceptionResponse({
            RoomNotFoundException.class,
            MemberNotFoundException.class,
            MemberNotParticipatedException.class})
    @GetMapping("/api/v2/studies/{studyId}/progresses")
    public ResponseEntity<PomodoroProgressResponseV2> findProgress(@PathVariable("studyId") Long studyId,
            @RequestParam("memberId") Long memberId) {
        PomodoroProgressResponseV2 response = pomodoroProgressServiceV2.findProgress(studyId,
                memberId);
        return ResponseEntity.ok(response);
    }

이제 위처럼 커스텀 어노테이션에 예외만 명시해주면 내부적으로 상태코드, 메세지, 에러코드를 자동으로 파싱해 명세로 전환합니다.

물론 이 방식도 예외가 많아지면 핸들러가 지저분해지는 건 매한가지고, 매번 서비스, 도메인 로직에서 던져지는 예외를 찾아 붙여줘야 하기 때문에 불편한 점이 있지만, 적어도 지금의 상황에서는 유용하게 써먹을 수 있기에 나름 뿌듯한 것 같습니다!

 

기타

• 개발서버와 운영서버를 분리했습니다.
• DB 마이그레이션 스크립트를 작성했습니다(DML)