feat(be): security 기본 설정

[jungdongha]

close #22

[github-actions]

🤖 AI 리뷰 - build.gradle.kts

🟢 좋은점:

• ktlint 규칙 준수: 의존성 추가 부분의 포맷팅(들여쓰기, 주석 위치)이 일관되며, 네이밍 컨벤션(주석 "// jwt"가 간결하고 명확함)을 잘 따름. Gradle Kotlin DSL의 표준 스타일에 맞춰 작성되어 읽기 쉽다.

🟡 개선사항:

• Kotlin 최적화: 이 파일은 빌드 스크립트이므로 data class나 null safety 같은 Kotlin 언어 기능은 직접 적용되지 않지만, 의존성 버전(0.12.6)을 하드코딩하는 대신 Gradle의 버전 카탈로그나 properties 파일로 관리하면 유지보수성이 높아질 수 있다. (예: versionCatalogs 사용 추천)

🔴 문제점:

• 없음. 이 변경은 글로벌 익셉션 처리나 ApiResponse 같은 런타임 규칙과 무관하며, JWT 의존성 추가 자체는 표준적이고 안전하다. 다만, JWT 사용 시 보안 취약점(예: 키 관리)을 코드 구현 단계에서 반드시 검토해야 함.

[github-actions]

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

🟢 좋은점:

• 없음. 이 변경사항은 SecurityConfig 파일의 완전 삭제로, 기존 코드의 Kotlin 스타일(예: data class, null safety 등)이나 ktlint 규칙 준수 여부를 평가할 수 있는 코드가 남아 있지 않습니다. 다만, 불필요한 개발용 설정 파일을 정리한 점은 코드베이스 청결성 측면에서 긍정적일 수 있습니다.

🟡 개선사항:

• 보안 설정을 완전히 삭제하는 대신, 프로파일(예: @Profile("dev"))을 사용해 개발 환경에서는 기존의 허용 설정을 유지하고, 운영 환경(production)에서는 강화된 설정(예: JWT 인증, 역할 기반 접근 제어)을 별도로 구성하는 것이 좋습니다. 이렇게 하면 개발 편의성과 보안성을 모두 고려할 수 있습니다.
• Kotlin 최적화 측면에서, 만약 이 설정을 재구현한다면 람다 표현식과 체이닝을 더 활용해 코드를 간결하게 유지하세요 (기존 코드가 이미 잘 되어 있음).

🔴 문제점:

• SecurityConfig 파일 삭제로 인해 Spring Security의 기본 동작(예: 모든 엔드포인트 인증 요구)이 적용되거나, 보안 설정이 전혀 없어 애플리케이션이 완전히 노출될 위험이 있습니다. 개발용이라도 최소한의 CSRF 비활성화나 CORS 설정을 유지해야 하며, 운영 환경에서 보안 취약점이 발생할 수 있습니다. 반드시 대체 보안 설정(예: 새로운 SecurityConfig 클래스 추가)을 구현하세요.
• 글로벌 익셉션 처리나 ApiResponse 사용 규칙과 직접 관련은 없으나, 보안 설정 부재로 인해 인증/인가 실패 시 표준 에러 응답(@ControllerAdvice 기반)이 제대로 처리되지 않을 수 있습니다.

[github-actions]

🤖 AI 리뷰 - src/main/kotlin/com/back/koreaTravelGuide/common/security/CustomOAuth2LoginSuccessHandler.kt

🟢 좋은점:

• Kotlin의 기본 기능을 잘 활용하여 간결한 코드 구조를 유지하고 있습니다. 예를 들어, 클래스 상속(SimpleUrlAuthenticationSuccessHandler)과 의존성 주입(@component, 생성자 주입)이 적절히 적용되어 보입니다.
• @transactional 어노테이션을 사용하여 데이터베이스 작업 시 트랜잭션 관리를 명시적으로 처리한 점이 좋습니다. 이는 잠재적인 데이터 일관성 문제를 방지합니다.
• ktlint 규칙 측면에서 포맷팅(들여쓰기, 줄바꿈)이 일관되며, 네이밍 컨벤션(예: camelCase 메서드명, 클래스명)이 표준을 따릅니다.

🟡 개선사항:

• Kotlin 최적화 측면에서 if-else 구문을 when 표현식으로 대체하면 더 idiomatic하게 작성할 수 있습니다. 예: when (user.role) { UserRole.PENDING -> { ... } else -> { ... } }. 이는 코드 가독성을 높이고, 확장성을 고려한 선택입니다.
• 하드코딩된 리다이렉트 URL("http://localhost:3000/...")을 application.properties나 환경 변수(예: @value("${frontend.url}"))로 외부화하면 배포 환경(로컬 vs 프로덕션) 유연성이 향상됩니다.
• oAuth2User.attributes["email"] 추출 시 as String 캐스팅 대신 getOrElse나 Elvis 연산자(?:)를 사용해 null-safe하게 처리하면 더 안전합니다. 예: val email = oAuth2User.attributes["email"]?.toString() ?: throw IllegalArgumentException("Email not found").

🔴 문제점:

• Kotlin null safety 위반: userRepository.findByEmail(email)!!와 user.id!!에서 비안전한 !! 연산자를 사용하고 있습니다. findByEmail이 null을 반환할 수 있으므로, Optional 처리나 예외 던지기로 변경해야 합니다. 예: val user = userRepository.findByEmail(email) ?: throw UserNotFoundException("User not found for email: $email"). 이는 런타임 NullPointerException을 유발할 수 있습니다.
• 글로벌 익셉션 처리 미적용: 이 핸들러에서 발생할