feat(be) : WebSocket 설정 삭제 및 entity, repository 추가

[beekeeper24]

No description provided.

[github-actions]

🤖 AI 리뷰 - src/main/kotlin/com/back/koreaTravelGuide/common/config/websocket/JwtHandshakeInterceptor.kt

🟢 좋은점:

• Kotlin null safety가 잘 적용되어 있음 (e.g., 토큰 추출 시 ?: return false 사용으로 안전한 처리). 이는 옵셔널 처리의 모범 사례를 따름.
• ktlint 규칙 준수: 네이밍 컨벤션 (e.g., camelCase 메서드명, 클래스명)이 적절하고, 포맷팅 (들여쓰기, import 순서)이 일관됨. 불필요한 import (e.g., java.lang.Exception은 기본이므로 생략 가능하지만 문제 없음)가 없음.
• 파일 삭제 결정이 논리적: 주석에 명시된 대로 SockJS 우회 코드가 임시적이었고, 순수 WebSocket 전환 시 제거 예정이었으므로 코드베이스 정리 측면에서 긍정적. 글로벌 익셉션 처리나 ApiResponse 규칙은 WebSocket 핸드셰이크 컨텍스트에서 직접 적용되지 않으나, REST API와 분리되어 충돌 없음.

🟡 개선사항:

• Kotlin 최적화 측면에서 when 표현식이나 확장 함수를 활용할 여지가 있었음 (e.g., 토큰 검증 로직을 JwtUtil의 확장 함수로 분리하여 재사용성 높임). 하지만 WebSocket 전용이므로 큰 이슈는 아님.
• 삭제 후 WebSocket 인증 대체 방안 (e.g., HTTP 헤더 기반 토큰 전달이나 ChannelInterceptor로 이동)을 문서화하거나, 관련 WebSocketConfig에서 명확히 처리하는 것이 좋음. 현재는 인증 로직이 사라지므로 연결 시 보안 취약점이 발생할 수 있음.
• afterHandshake 메서드가 빈 구현이므로, 삭제 시 이 부분도 자연스럽게 제거되어 코드가 간결해짐. 다만, 예외 로깅 같은 후처리를 추가 고려할 수 있었음.

🔴 문제점:

• 파일 삭제로 인해 WebSocket 연결 시 JWT 인증이 완전히 사라짐. 만약 이 인터셉터가 사용자 인증의 핵심이었다면 (e.g., attributes["userId"]로 세션 관리), 대체 인증 메커니즘 (e.g., STOMP 헤더나 WebSocketHandler 내 검증)이 없

[github-actions]

🤖 AI 리뷰 - src/main/kotlin/com/back/koreaTravelGuide/common/config/websocket/WebSocketConfig.kt

🟢 좋은점:

• Kotlin 최적화 측면에서 원래 코드가 간결하게 작성되어 있었으며 (null safety 준수, 불필요한 복잡성 없음), 삭제로 인해 코드베이스가 불필요한 WebSocket 설정을 제거하여 유지보수성을 높임. ktlint 규칙(포맷팅, 네이밍 컨벤션)도 원래 코드에서 잘 준수되었음.

🟡 개선사항:

• WebSocket 기능이 프로젝트에서 더 이상 필요하지 않다면 삭제가 적절하지만, 삭제 이유(예: 기능 변경 또는 리팩토링)를 커밋 메시지나 문서에 명확히 기록하는 것이 좋음. 만약 부분적으로 WebSocket을 유지해야 한다면, 대체 설정(예: Spring Boot의 기본 WebSocket 지원 활용)을 고려.

🔴 문제점:

• 글로벌 익셉션 처리(@ControllerAdvice)와 ApiResponse 사용 규칙은 WebSocket 설정 파일이므로 직접 적용되지 않지만, 삭제로 인해 WebSocket 관련 에러(예: 연결 실패 시)가 표준 에러 응답으로 처리되지 않을 수 있음. 프로젝트에서 채팅이나 실시간 기능이 여전히 필요하다면 WebSocket 기능을 완전히 제거하는 것은 기능 손실로 이어질 수 있으니, 대체 구현(예: 다른 라이브러리나 REST 기반 폴링)을 반드시 검토해야 함.

[github-actions]

🤖 AI 리뷰 - src/main/kotlin/com/back/koreaTravelGuide/common/util/JwtUtil.kt

🟢 좋은점:

• 임시 테스트용 코드(JwtUtil.kt)를 완전히 삭제하여 프로덕션 코드의 청결성을 유지하고, 불필요한 테스트 로직을 제거한 점이 우수합니다. 이는 Kotlin 프로젝트의 유지보수성을 높이고, 실제 JWT 구현으로 대체된 것으로 보아 적절한 리팩토링입니다. ktlint 규칙(포맷팅, 네이밍 컨벤션) 측면에서도 더 이상 검토할 코드가 없어 불필요한 이슈를 방지합니다.

🟡 개선사항:

• 삭제된 JwtUtil의 기능을 대체하는 실제 JWT 구현(예: JJWT 라이브러리나 Spring Security 통합)이 프로젝트 다른 부분에 추가되었는지 확인하세요. 만약 대체 로직이 없다면, 토큰 검증 및 사용자 ID 추출 기능이 누락될 수 있으므로 테스트 케이스를 통해 검증하는 것을 추천합니다. Kotlin 최적화 측면에서, 대체 구현 시 null safety(예: token?.let {})를 활용해 더 안전하게 작성할 수 있습니다.

🔴 문제점:

• 없음. 이 변경은 임시 코드를 제거하는 안전한 작업으로 보이며, 필수 검토 항목(글로벌 익셉션 처리, ApiResponse 사용 등)과 직접 관련되지 않습니다. 다만, JWT 관련 API에서 이 유틸리티를 사용 중이었다면 해당 API의 동작이 깨질 수 있으니, 전체 프로젝트 빌드 및 테스트를 통해 확인하세요.

[github-actions]

🤖 AI 리뷰 - src/main/kotlin/com/back/koreaTravelGuide/common/config/websocket/JwtHandshakeInterceptor.kt

🟢 좋은점:

• Kotlin null safety가 잘 적용되어 있음 (e.g., 토큰 추출 시 ?: return false 사용으로 안전한 처리).
• 불필요한 SockJS 우회 로직이 명시적으로 주석 처리되어 있어, 추후 WebSocket 전환 시 유지보수가 용이함.
• ktlint 규칙 준수: 네이밍 컨벤션 (e.g., camelCase 메서드명)과 포맷팅이 일관적임.

🟡 개선사항:

• when 표현식을 활용해 메서드 비교 (e.g., method == HttpMethod.OPTIONS || uri.path.endsWith("/info"))를 더 명확하게 리팩토링할 수 있음 (현재 if 조건문은 간단하지만, 복잡해질 경우 when이 적합).
• JwtUtil 호출을 확장 함수로 추출하면 (e.g., String.validateAndExtractUserId()), 코드 재사용성과 가독성이 높아질 수 있음.
• 파일 삭제 시, WebSocket 인증 대체 로직 (e.g., ChannelInterceptor나 다른 핸들러로 이동)을 문서화하거나 커밋 메시지에 명시하면 좋음.

🔴 문제점:

• 파일 전체 삭제로 WebSocket 핸드셰이크 시 JWT 인증 로직이 완전히 사라짐. 이는 보안 취약점(인증 우회 가능)을 초래할 수 있으므로, 대체 인증 메커니즘 (e.g., STOMP 헤더 기반 검증)을 즉시 구현해야 함. 글로벌 익셉션 처리나 ApiResponse 규칙은 WebSocket 컨텍스트에서 직접 적용되지 않으나, 인증 실패 시 표준 에러 응답을 위한 @ControllerAdvice 확장이 필요할 수 있음.

[github-actions]

🤖 AI 리뷰 - src/main/kotlin/com/back/koreaTravelGuide/common/config/websocket/WebSocketConfig.kt

🟢 좋은점:

• Kotlin 최적화 측면에서 원본 코드가 data class나 null safety를 직접적으로 사용하지 않지만, 클래스 구조와 확장함수 미사용이 간결하게 유지되어 불필요한 복잡성을 피함. 삭제로 인해 코드베이스가 더 슬림해짐.
• ktlint 규칙 준수: 원본 코드의 포맷팅(들여쓰기, 네이밍 컨벤션)이 표준적이었으나, 삭제로 인해 관련 규칙 위반 가능성이 완전히 제거됨.

🟡 개선사항:

• 글로벌 익셉션 처리: WebSocket 설정이므로 @ControllerAdvice와 직접 관련 없으나, 삭제 후 WebSocket 관련 에러(예: 연결 실패)가 발생할 경우 표준 에러 응답 메커니즘(예: 커스텀 핸들러 추가)을 별도로 고려할 수 있음. 만약 WebSocket 기능이 완전히 제거된 것이 아니라면, 대체 설정(예: 최소한의 인터셉터 로직)을 검토.
• Kotlin 최적화: 삭제가 의도된 변경이라면 좋으나, WebSocket 기능이 여전히 필요하다면 when 표현식이나 확장함수를 활용한 더 모듈화된 설정(예: 인터셉터를 별도 컴포넌트로 분리)으로 대체하는 방안을 제안.
• ktlint 규칙: 삭제로 인한 영향 없으나, 관련 import나 참조(예: JwtHandshakeInterceptor)가 다른 파일에 남아있다면 클린업(예: unused import 제거)을 추가로 수행.

🔴 문제점:

• ApiResponse 사용: WebSocket은 REST API와 달리 비동기 메시징을 사용하므로 ApiResponse 래퍼가 적용되지 않음. 그러나 삭제로 WebSocket 엔드포인트(/ws/chat)가 사라지면, 클라이언트 측에서 이를 사용하는 API 호출이 실패할 수 있음. 만약 WebSocket이 프로젝트의 핵심 기능이라면 삭제 전에 대체 구현(예: REST 기반 폴링)이나 마이그레이션 계획을 반드시 문서화해야 함.
• 글로벌 익셉션 처리: WebSocket 연결 시 JWT 검증 실패(예: JwtHandshakeInterceptor 에러)가 발생할 때 표

[github-actions]

🤖 AI 리뷰 - src/main/kotlin/com/back/koreaTravelGuide/common/util/JwtUtil.kt

🟢 좋은점:

• 이 파일이 임시 테스트용으로 명시되어 있으며, 주석에 따라 완성 후 삭제하라는 지침을 준수하여 제거된 점이 적절합니다. 이는 프로덕션 환경으로의 전환을 위한 청소 작업으로, 코드베이스의 불필요한 테스트 코드를 제거하여 유지보수성을 높입니다.
• Kotlin 최적화 측면에서, 삭제로 인해 null safety나 when 표현식 등의 규칙 위반 가능성이 제거되어 전체 코드 품질에 기여합니다.
• ktlint 규칙 준수: 파일 자체가 삭제되어 포맷팅이나 네이밍 이슈가 더 이상 발생하지 않습니다.

🟡 개선사항:

• JwtUtil의 실제 구현(예: JWT 라이브러리如 JJWT나 Spring Security JWT 통합)이 별도의 파일로 대체되었는지 확인하세요. 만약 대체가 아직이라면, validateToken과 getUserIdFromToken 메서드를 실제 JWT 로직으로 옮겨 null safety(예: token?.let { ... })와 확장 함수(예: String 확장으로 토큰 파싱)를 활용해 Kotlin적으로 최적화하는 것을 추천합니다.
• 글로벌 익셉션 처리와 ApiResponse 사용은 이 유틸리티 파일과 직접 관련 없으나, JWT 검증 실패 시 @ControllerAdvice에서 표준 에러 응답(예: UnauthorizedException 핸들링)을 통해 ApiResponse 형식으로 응답하도록 연계하는 것이 좋습니다.

🔴 문제점:

• 없음. 이 삭제는 의도된 작업으로 보이며, 규칙 위반이 없습니다. 다만, JWT 관련 기능이 완전히 대체되지 않았다면(예: 토큰 검증 로직이 어딘가에서 여전히 이 임시 코드를 참조 중이라면) 즉시 수정하세요.