20241112_엔티티 매핑 오류 및 JWT & Security 회고

엔티티 매핑 오류와 코드 리뷰

문제 발생

코드 리뷰를 잘 반영한 후 머지되었지만 CommandAcceptanceException 에러가 발생했다.

Error executing DDL references p_order" via JDBC [ERROR: relation "p_order" does not exist]

원인 분석

명명 규칙이 잘못된 것은 아닌지 확인
매핑 방식이 올바른지 점검
데이터 타입 설정이 잘못된 것은 아닌지 확인
어노테이션 설정에 오류가 있는지 검토

문제의 원인을 찾기 위해 여러가지를 팀원 각각 체크를 해보았다. 팀장님이 비어 있는 Enum 파일이 원인인 것 같다고 말씀 해주셨고, 실제로 Enum 필드가 참조된 테이블에 빈 상태로 설정되어 있는 것이 원인이었다.

참조 관계에서 Enum 값이 설정되지 않으면 오류가 발생할 수 있다는 점을 알게 되었다.

GitHub 특강과 Q&A

GitHub 관련 특강을 통해 프로젝트 관리와 협업 흐름에 대해 다시 살펴볼 수 있었다. 다른 분들의 질문과 답변을 통해 여러 가지 실용적인 팁도 얻었다.

Q1. GitHub 이슈를 잘 활용하는 방법이 있는지?
A1. GitHub 이슈는 간단한 프로젝트 관리에 유용하지만, 실제로 Jira와 같은 프로젝트 관리 도구가 더 널리 사용된다.

Q2. PR(풀 리퀘스트) 단위가 너무 작게 느껴지는데, 적절한 기준이 있는지?
A2. 1 PR 당 1 커밋을 지향하는 것이 권장되며, 이는 코드 리뷰를 간소화하고 변경 사항을 쉽게 추적할 수 있기 때문이다.

Q3. Slack과 GitHub 연동 팁이나 유용한 기능이 있는지?
A3. Slack에 GitHub 연동을 설정하면, PR 생성 또는 리뷰 요청 시 알림이 즉시 도착하여 팀원들이 작업을 빠르게 파악할 수 있다. 이는 협업 속도를 높이는 데 유리하다.

Q4. Git에서 switch와 checkout의 차이가 있는지?
A4. switch는 브랜치 전환에 좀 더 직관적인 명령어로, checkout보다 실수를 줄이고 사용자 경험을 개선한다.

팀 내 변경사항

브랜치 전략 변경
프로젝트의 진행 속도를 높이기 위해 도메인 단위를 거치지 않고 도메인별 Git 브랜치 전략을 단순화했다.
엔티티 수정
엔티티에 BaseEntity 상속이 누락된 것을 발견해 도메인 담당자가 수정.
주소 도메인 관련 기능 일시 보류
코드의 복잡성을 줄이기 위해 주소 도메인 관련 작업을 잠정 보류했다. 추후 논의 후 재개할 예정이다.

JWT와 Spring Security 설정 경험

Enum과 역할(Role) 설정 방식

사전 강의 영상에서는 권한 Enum 클래스를 내부 클래스로 구현했다. 이유가 궁금해서 더 찾아보았다. Spring Security에서 역할(Role)은 일반적으로 ROLE_로 시작하는 문자열로 정의하는 것이 관례라고 한다. 그렇게 실제 사용하는 개발자들이 직관적으로 사용할 수 있도록 내부 클래스로 구현한 것이었다.

API 접근 제한 설정

api 명세서에 따라, 접근 제한을 설정을 하는데 가독성이 너무 떨어지고 길어지는 문제가 발생했다. 그래서 http.authorizeHttpRequests.requestMatchers를 더 살펴보기로 했다.

Security 설정에서 SecurityFilterChain을 사용해 접근 제어를 설정했다.

http.authorizeHttpRequests.requestMatchers 메서드를 사용하여 HTTP 메소드와 경로별로 권한을 부여할 수 있었다.

authorizeHttpRequests.requestMatchers(HttpMethod.DELETE, "/api/**")
    .hasAnyAuthority(
        UserRoleEnum.MANAGER.getAuthority(), 
        UserRoleEnum.MASTER.getAuthority()
    );

여러 API 경로에 대한 권한을 한 번에 설정하거나, 특정 권한 그룹을 정의할 수도 있었다.

authorizeHttpRequests.requestMatchers("/api/order", "/api/order/**")
    .hasAnyAuthority(
        UserRoleEnum.CUSTOMER.getAuthority(), 
        UserRoleEnum.OWNER.getAuthority()
    );

메소드 체이닝 패턴이다 보니 가독성을 위해 끊어서 작성하는 것도 가능했다.

JWT 인증과 Security 설정 고민

사전 강의 영상을 참고하여 작업을 진행하다가 문제를 마주했다. 우리는 독립적인 API 서버이고 영상에서는 프론트 소스가 있다는 차이가 있었다. 그 차이로 인해 여러 고민을 하게 되었고 많은 시행착오가 발생했다.

필터단계의 세팅에서는 어떤 차이가 발생하게 되는지
JWT 토큰은 Cookie 방식과 헤더 방식 중에 어떤 것이 더 유리할지
로그인을 관리해주는 Security에서 어떻게 api 로직을 분기할지

예상치 못한 문제

조사와 설정 작업을 마치고 JWT 인증과 Security 설정을 회원가입과 로그인 기능을 구현해 테스트해보고 싶었다. 하지만 주소록과 주소 도메인에 문제가 있어 진행할 수 없었다.

ERD 설계 문제와 구조적 한계

프로젝트의 ERD 설계에서 유저와 주소록이 서로 FK 관계로 연결되며, 다대일과 일대일 관계가 복잡하게 얽혀있는 구조인 상황이다.
유저와 주소록이 서로의 식별자를 알아야 하는 순환 관계로 인해, 선 생성 후 참조가 어렵고 이상한 참조 구조가 발생한다.
주소 코드와 가게 주소 담당자가 밤에 안계시는 상황에서 혼자 문제를 해결하려고 하니 답답했다.

자정이 넘은 시간에 팀장님께 상황을 설명드린 후 조언을 구했다. 팀장님은 Security와 User 도메인이 다른 도메인에 미치는 영향이 큰 만큼, 주소 관련 부분을 일시적으로 보류하고 작업을 진행하자고 하셨다. 그래서 일단 주소 관련 부분을 주석 처리하고, API 개발을 진행한 후, 다음 날 팀원들과 함께 해결 방안을 논의하기로 했다.

최종 결과 및 남은 과제

회원가입 기능을 성공적으로 구현했고, JWT와 Security 설정도 정상적으로 작동하는 것을 확인했다. 로그인 API에서 필터를 통한 분기 처리 방식에 대해 한참을 해매다 마땅한 해결책을 찾지 못했다. 주소 및 주소록 엔티티에 관련해서는 내일 튜터님께 질문을 통해 추가 조언을 구해볼 계획이다.