PROJECT

Team Personal

STUDY

Language Framework

PHOTO

itAbility

👨🏻‍💻 내가 기여한 부분

📚 사용 기술

🧩 System Architecture

내가 기여한 부분

•

OAuth2를 이용하여 Google, Naver, Kakao, GitHub 소셜 로그인 기능을 구현

•

각 서비스가 독립적으로 운영 될 수 있도록 마이크로 서비스 아키텍처(MSA) 적용

•

OpenWeatherMap API를 활용하여 사용자의 위치 기반 실시간 날씨 정보를 플랫폼에 띄워주는 기능을 구현

•

일관성과 협업의 효율성 그리고 충돌방지를 위해 Git Flow와 커밋 컨벤션 도입

•

프로젝트 기간에 차질이 생기지 않도록 서비스 기획 및 방향성 설정 부분에 대해 주도적으로 진행

사용 기술

•

DataBase

◦

MariaDB

•

BackEnd

◦

Java / Spring Boot / Spring Data JPA / Spring Security / Spring Cloud / Selenium / Chrome Driver / Google Storage

•

API

◦

Kakao Login / Google Login / GitHub Login / Naver Login / Swagger / OpenWeatherMap

•

Software Architecture Pattern

◦

Microservices Architecture(MSA)

•

FrontEnd

◦

HTML / CSS / JavaScript / Vue.js

•

Collaboration

◦

GitHub / Slack / Notion / Figma / Miro

System Architecture

itAbility System Architecture

트러블 슈팅 1

문제 배경

프로젝트에서 OAuth2 소셜 로그인 기능을 구현하면서, 다양한 OAuth2 제공자(Google, Kakao, GitHub, Naver)에서 반환하는 사용자 정보의 구조가 서로 다르다는 문제에 직면했습니다. 일부 제공자는 ID를 숫자 형태로 반환하는 반면, 다른 제공자는 문자열로 반환했습니다. 이로 인해 제공자별로 사용자 정보를 일관되게 처리하고 저장하는 데 어려움이 발생했습니다.

해결 방법

OAuth2Response 인터페이스 도입: 각 제공자별로 다른 구조의 사용자 정보를 처리하기 위해 OAuth2Response 인터페이스를 도입했습니다. 이를 통해 공통의 메서드(getProviderId(), getEmail() 등)를 정의하고, 각 제공자별로 해당 인터페이스를 구현하는 방식으로 통일된 처리가 가능하게 했습니다.

ID 변환 전략: 사용자 ID(Long)의 일관성을 유지하기 위해 MessageDigest를 사용하여 SHA-512 해시 알고리즘으로 ID를 변환했습니다. 특히, Naver(문자열)와 Google(구글은 ID값이 Long범위를 벗어났습니다)과 같이 문자열 ID를 반환하는 경우 이를 해시하여 숫자 형태로 변환하고, 음수로 변환될 가능성을 고려해 양수로 변환했습니다.

CustomOAuth2UserService 구현: 각 제공자에서 반환된 사용자 정보를 공통의 구조로 매핑하여 UserDTO 객체에 저장하고, 이 데이터를 기반으로 CustomOAuth2User 객체를 생성했습니다.

개선 결과

이 트러블슈팅 과정을 통해 다양한 OAuth2 제공자에서 반환된 사용자 정보를 일관되게 처리할 수 있었습니다. 결과적으로, 소셜 로그인 기능의 안정성과 유지 보수성이 크게 향상되었으며, 추후 GitHub 로그인을 도입하는데도 어려움이 있지 않았습니다.

해당 경험을 통해 알게 된 점

이번 경험을 통해 OAuth2와 같은 외부 인증 시스템을 다룰 때, 제공자별 데이터 형식의 차이를 미리 이해하고 통합할 수 있는 설계가 필요하다는 점을 배웠습니다. 특히, 이러한 차이를 고려하지 않으면 예상치 못한 문제에 직면할 수 있으며, 데이터 일관성을 유지하는 방법을 마련하는 것이 중요함을 느꼈습니다. 앞으로는 보다 철저한 사전 분석과 계획을 통해 이런 문제를 미리 방지하고, 더욱 유연한 대응이 가능하도록 해야겠다 생각했습니다.

트러블 슈팅 2

문제 배경

프로젝트에서 MSA(Microservices Architecture) 아키텍처를 도입한 이후, Spring Gateway를 통해 프론트엔드(Vue.js 기반의 SPA)와 백엔드 간의 통신을 처리했습니다. 그러나 이 과정에서 CORS(Cross-Origin Resource Sharing) 문제가 발생했습니다. 문제의 원인은 이렇게하면 더 잘 동작하겠지 하는 마음에SecurityConfig 클래스에서의 CORS 설정과 application.yml 파일 내에서의 CORS 설정이 중복되었기 때문입니다. 이러한 중복 설정은 통신이 차단되는 문제를 일으켜 프로젝트 진행에 있어 어려움을 겪었습니다.

해결 방법

CORS 설정 재구성:

SecurityConfig 클래스 내에서만 CORS 설정을 처리하도록 변경했습니다. application.yml 파일 내의 CORS 설정을 제거하고, Spring Gateway에서의 CORS 설정만 사용하도록 조정했습니다.

Spring Security의 CorsConfigurationSource를 활용하여 특정 도메인에서의 요청을 허용하도록 설정하였으며, http.cors() 설정을 통해 프론트엔드와 백엔드 간의 통신을 허용했습니다.

개선 결과

CORS 문제를 해결한 후, 프론트엔드와 백엔드 간의 통신이 원활하게 이루어졌으며 특히, MSA 환경에서 발생할 수 있는 CORS 문제를 해결한 경험은 프로젝트의 안정성을 높이는 데 기여했습니다. 이를 통해 서비스 간의 연결성이 개선되었고, CORS 문제를 해결한 경험은 향후 유사한 문제를 해결하는 데 중요한 참고 자료가 되었습니다.

해당 경험을 통해 알게 된 점

이번 경험을 통해 프로젝트 진행 시 설정 간의 충돌을 예방하는 것이 얼마나 중요한지 깨달았습니다. 특히, MSA 환경에서는 설정이 일관되게 적용되어야 하며, 불필요한 중복 설정이 문제를 야기할 수 있다는 점을 배웠습니다. 이를 통해, 설정 관리의 중요성을 재인식하고, 시스템 전체의 안정성을 유지하는 방법을 습득했습니다.

어려움을 극복하고자

스프링의 어려움과 자바의 어려움 때문에 해당 이슈를 극복하고자 팀원끼리 기초부터 다지자 시작한 Java 스터디를 진행하였습니다.

🫡 회고

“헤어 나올 수 없는 미로 속에서 길을 찾는 여정"

프로젝트를 마무리하면서, 여러 도전을 통해 많은 것을 배웠습니다. 특히 Vue.js를 사용한 SPA 구축에서 CORS 문제는 가장 큰 과제 중 하나였습니다. Spring Gateway와의 연동 과정에서 발생한 통신 문제를 해결하기 위해 수많은 설정을 반복했고, 그 결과 원활한 통신을 구현할 수 있었습니다. 처음에는 복잡하고 난해하게 느껴졌던 문제들이 시간이 지나면서 점차 이해되고, 해결되는 과정을 통해 기술적으로도 개인적으로도 성장할 수 있었습니다. 이 프로젝트는 단순히 기술적인 성취뿐만 아니라, 문제를 해결하는 과정에서 얻는 성취감과 자신감을 더해주었습니다. 이러한 경험들은 앞으로의 프로젝트에서도 저에게 큰 도움이 될 것입니다. 새로운 기술과 개념을 배우는 과정이 비록 어렵고 혼란스러울 수 있지만, 그 과정을 통해 성장하는 것이 진정한 가치라는 것을 깨달았습니다. 이 프로젝트에서 얻은 기술적 역량과 교훈은 앞으로의 도전에서 저를 더 강하게 만들어줄 것이라 믿습니다.

GitHubGitHub - beyond-sw-camp/be04-3rd-3team-itAbility

itAbility

트러블 슈팅 2

문제 배경

해결 방법

개선 결과

해당 경험을 통해 알게 된 점

.css-hopgjw{font-family:var(--emoji-font-family);white-space:nowrap;}🫡 회고

🫡 회고