240612 백오피스 프로젝트- 본격적인 협업 시작

노재원·2024년 6월 12일
0

내일배움캠프

목록 보기
59/90
post-custom-banner

어제 하루종일 기획과 프로젝트 초기 설정, 규칙에 대한 설정을 진행했으니 오늘부터는 본격적인 작성의 시작이다.

특히 협업이 아직 어색하신 분들도 있고 익숙하더라도 이번처럼 많은 규칙과 구체적인 내용을 정하고 시작한건 처음일 수도 있어 걱정이 됐는데 오히려 이런 프로세스에 대해 호평을 들어 기분이 좋았던 것 같다.

실무 경험이 있어 이런 초기설정을 많이 해주신 팀원분께 감사하다. 나는 실무 경험은 있는데 혼자 일했으니 모르는게 솔직히 많았다.

회원 테스트하기 쉽게 API 작성하기

JWT 인증과 기본 필터를 구현해서 User Id와 Role을 담고있는 Principal 생성까지는 무사히 완료했다. 사실 구현체의 구분이 어려운거지 한 번 진행하고 나면 Authentication 객체만 무사히 잘 만들어지고 무난하게 쓸만한 것 같다. 다만 처음부터 직접 하는건 문제의 소지가 있다.

이렇게 userId 기반의 API들을 기본적으로 사용하기엔 충분한 환경이 마련되었는데 이제 문제는 테스트를 어떻게 할 것이냐다.

우선 공유 DB를 위해 계속 써오던 Supabase는 이번엔 잠시 묻어두기로 했다. 개발단계부터 DB에 의미있는 레코드를 쌓아올리기 힘들고 미숙한 설계 능력으로 DDL이 수시로 바뀌는 단계이기 때문에 각자 H2 DB에서 테스트하기로 했고 콘솔 이용법이나 기초 설정은 진행해서 스크럼때 공유드렸다.

이제 이 H2 DB를 이용하기 위해 Swagger 켜서 회원가입하고 로그인하고 건드리고 하는 작업을 수도 없이 반복하는 건 어불성설이다. 그렇기에 GET token-test-generate 와 GET token-check api를 만들어서 Token에 대해 초고속 인증이 가능하도록 만들었다.

내부적으로는 그냥 바로 1번 유저 조회하거나 없으면 유저를 생성해버리는 간단한 로직이고 일단 만든 나는 테스트할 때 초신속으로 1번 유저를 만들어서 바로 테스트를 진행하고 있다.

공통적인 로직의 인가 핸들링하기

Entity를 조회하고 나서 Entity의 작성자가 인증 유저가 맞는지 체크하는 로직은 결국 서비스에서 진행해야했다. 이 방법을 많이 찾아봤는데 결국 로직의 역할이 맞다고 봤다.

그러면 로직의 흐름을 방해하지 않게 로직을 단순화하고 코드의 중복도 줄여야했는데 어떻게 할까 고민하면서 팀원분들과 의견을 나눴다.

Github discussions를 처음 써봐서 기념으로 스샷도 남겼고 나름 의사결정이 된 것 같아 내가 맡은 User domain의 CRUD를 구현할 때 바로 적용해보기로 했다.

// util
object PermissionChecker {
    fun check(entityOwnerId: Long, principal: UserPrincipal) {
        val hasPermission = entityOwnerId == principal.id || principal.isAdmin()
        check(hasPermission) { "Permission denied" }
    }
}

// service
return userRepository.findByIdOrNull(userId)
            ?.also { PermissionChecker.check(it.id!!, principal) }
            ?.let { UserResponse.from(it) }
            ?: throw ModelNotFoundException("User not found with id", userId)

이걸 뭐라고 해야할 지는 모르겠지만 코드의 단순화 측면에선 굉장히 좋게 된 것 같다. 다만 PermissionCheck의 반복적인 사용도 줄일 수 있는 방법이 있나 싶지만 영 쉽게 떠오르지 않아 이번엔 이게 최선인 것 같다.

추가로 조사하다가 check의 존재를 깨달았는데 false가 나오면 자동으로 IllegalStateException을 발생시킨다고 해서 꽤 코드가 단순해져서 좋은 것 같다.

물론 세부적인 Exception 처리가 필요하다면 throw를 쓰는게 당연히 좋을 것이다.


오늘은 협업 과정에서 불협화음, 잡음이 전혀 없었던게 마음에 들었다. 기본적인 CRUD까지 작성하면서 굉장히 소통이 원활했고 어제 하루종일 이거저거 소통한 결과가 나왔다고 생각한다.

다른 분들도 아직 이 프로세스가 어색하실 수는 있어도 편하다는 느낌을 받으셨으면 좋겠다.

post-custom-banner

0개의 댓글