🪄스마일게이트 윈터데브캠프 2기 최종발표 내용정리!

🧸 맡은 역할

• 유저, 인증/인가 개발
  Spring Security + JWT를 이용한 회원가입, 로그인, 정보 조회 및 수정, 로그아웃, 토큰 재발급 api 개발
  

🎢 목표 달성 정도

• 설계부터 개발까지 그 시기에 했던 고민들과 문제 해결 과정을 꾸준하게 블로그에 기록하여 비슷한 문제 발생 시에 활용했음.

• 개발 기간 이전에는 개발을 시작하기 위해 필요한 부분을 학습하고, 기초적인 케이스를 간단히 만들어가며 경험을 쌓고, 개발 기간에는 케이스를 바탕으로 백엔드 개발을 진행함.

• REST API를 설계하고 구현하며 무작정 프론트에 의존하는 것이 아닌 Postman과 같은 툴을 활용하여 팀에서 결정한 커스텀 응답을 받고, 잘못된 코드는 수정하는 방법을 사용할 수 있게 됨.

• 달성도 : 70%

  • 기능 구현 및 배포 완료(회원가입, 로그인, 정보 조회 등)
  • 성능 테스트 진행 X

📶 확장성을 고려한 설계

• 인증인가 서버:
  • 빈번하게 일어나는 인증인가 작업의 속도를 높이기 위해 MySQL과 Redis 함께 사용
    -> 사용자 정보는 중요하고 민감한 정보이기 때문에 유실을 방지하기 위해 완전히 MySQL을 걷어낼 수는 없다고 판단

⚙️ 변경된 아키텍처

• 로그인 서버 변경 이유
  • 이전 아키텍처
• 작은 범위에서의 MSA는 좋지 않은 방향 + 서버를 너무 잘개 쪼개면 배포 및 연동에 많은 어려움을 겪게 될 가능성이 크기 때문에 줄이기 위해
  • 주어진 시간 내에 서버가 작동하는 것에 집중하기 위해 많이 쪼개져있던 로직은 과감히 합치는 방식 사용 → 해당 수정 이후(코드리뷰 내용 반영) Auth Server와 User Server를 쪼개지 않고 하나의 서버로 생각하고 합치게 되었음.
    

❗문제 해결

• 설명 이외의 더 다양한 트러블 슈팅들의 해결 과정 상세는 블로그 참고

🎥 AccessToken payload에 닉네임 정보 추가 실패

• 목표 : 타 서버의 요청 시 AccessToken payload에 유저의 nickname 정보를 담아 전달
• 원인 : 타 서버에서의 유저 파악을 위해 AccessToken의 payload에 닉네임 정보를 넣어주어야 했으나 해당 코드의 수정만으로는 반영이 안됨.
• 해결 과정 :
  📍 Subject에 포함 → X
  📍 Claim 생성 및 닉네임 삽입 → X
  📍 payload 함수 생성 및 닉네임 삽입 → X
  📍 팀 슬랙에 질문 및 해결(Claim → Claims) → X
• 해결 : 닉네임 정보를 payload에 넣는 방법 대신 다른 방법을 사용
  → 토큰 payload의 user_id를 통해 닉네임 정보를 요청하여 받아오는 방식으로 변경
• 얻은 것 : 원인을 파악하기 위해 작성한 코드들의 유저 정보 연관 관계를 살피며 다양한 방법으로 닉네임 정보를 불러오려 시도한 것
  

🎥 별도 브랜치를 이용한 Pull Request 실패

https://velog.io/@dlgkdis801/현재-상황참고-링크
https://velog.io/@dlgkdis801/IntelliJ-Github-연동-다시

• 문제 : 팀 레포지터리에 Pull Request 시도 시 ‘There isn’t anything to compare.’ 에러 발생
  
• 해결 방법 : 질의 응답 질문 & 원인 파악
  - 에러문을 살펴보면, 연결하려는 브랜치가 같은 커밋 기록을 가지고 있지 않아 연결에 실패했다고 판단할 수 있음.
  - fork한 레포지터리 내의 main 브랜치와 AI-33 브랜치의 커밋 기록이 일치하지 않으며, 그로 인해 팀 레포지터리의 main에 pr을 올릴 수 없는 것으로 파악.
• 원인 : fork한 레포지터리 내에서 main과 별도의 브랜치인 “AI-33”의 커밋 기록을 연동하지 않고 브랜치를 생성하여 연결이 끊긴 것이 원인.
• 해결 : 프로젝트 백업 후, 새로 생성했던 브랜치를 삭제 & 다시 생성
• ‘New Branch from main..’을 통한 새로운 브랜치 생성으로 커밋 기록을 이어주어야 함.
  

🎥 AWS EC2 배포 중 DB 연동 실패로 인한 에러

https://velog.io/@dlgkdis801/SpringBoot-프로젝트-AWS에-배포하기

• 문제 : AWS의 EC2 서버에 인증인가서버의 jar파일을 올렸으며, 빌드는 되지만 로그에 에러가 남는 상태
  
• 원인 : DB와 JPA를 사용하지 못하는 에러로 판단하고 해결책을 찾아봄.
• 해결과정

1. RDS를 이용해 해결해보려 했으나, 발급 과정에서 문제가 생겨 해당 EC2 서버에서 불러오지 못하는 문제가 발생
2. EC2 서버 역시 하나의 컴퓨터와 같기 때문에 서버 내의 환경을 로컬과 동일하게 만드는 것을 시도해볼 수 있겠다고 판단함.

• 해결

1. EC2 서버 내에 Apach2(http.d 활성 위함), MySQL(MariaDB)를 설치

2. 프로젝트의 aplication.yml에 EC2 서버 내의 설정을 추가 + build.gradle runtimeOnly 추가

• 주의 : 우분투 서버에는 mariadb 관련 서버와 클라이언트를 설치했기 때문에 driver class name이 mariaDB 관련이어야함!
  
  

3. 재배포

🎞️ 이번 프로젝트 회고

ver.1

• 좋았던 점

• 성공한 부분

  • Spring Framwork, Spring Security를 사용한 프로젝트
  • REST API 설계
  • 인증/인가 서버의 구축 및 정상 작동
  • JWT 도입 및 AccessToken과 RefreshToken의 사용
  • MySQL과 Redis의 혼용을 통한 사용자 인증
  • AWS EC2를 이용한 배포 및 배포 실패 가능성을 대비한 포트포워딩 환경 구성

• 부족한 부분

  • 빈번하게 일어나는 작업(ex.토큰 재발급)에 대한 속도와 편의성을 고려하지 못한 설계
  • 소셜 로그인 추가(OAuth 2.0)
  • Gateway 차원에서의 인증

• 다양한 리뷰와 피드백

  • PMP, 아키텍처, 코드리뷰 과정을 거치며 미처 고려하지 못한 부분에 대한 질문과 답변을 하는 과정을 통해 내가 하고자 하는 것이 무엇인지, 해야하는 것과 하지 말아야한 것에 대한 결정을 명확히 할 수 있었고, 캠프 기간 동안 어려움을 겪는 부분에 대한 도움과 내가 보지 못한 부분을 피드백받으며 완성도 있는 문서와 코드를 구성할 수 있었음.

• 아쉬운 점

• 한계점

  • 설계가 여러번 바뀌는 과정 → 구현 성공 여부만 과도하게 집중해 구현 방향을 바꾸려 했던 점
    • 시간 부족으로 구현하지 못한 설계의 경우, 다시 구현 진행
      • 시간이 부족해 설계를 변경한 부분에 대해서는 포기했던 설계를 바탕으로 캠프 이후 다시 구현해볼 예정.
  • RDBMS에서 크게 벗어나지 못한 DB 설계로 인해 새로 도입된 Redis의 속도 측면 이점은 크게 활용 X
    • MySQL → Redis 이용
      • 인증인가의 경우 빈번하게 일어나는 작업이기 때문에 Redis를 중점적으로 사용하는 사례가 많음 → Redis의 단순 기능 이용이 아닌 DB로서의 사용으로 발전시키고 싶음.
  • Spring의 SpringBoot, JPA, Spring Security 등에만 의존한 개발 + 인증 방식의 아쉬움
    • Gateway 측면에서의 인증
      • 캠프 이후, 아쉬웠던 해당 부분을 시도해봄으로서 서비스 내의 다른 서버에 더 빠르게 접근하는 경험을 하고 싶음.
  • 테스트 코드의 작성이 미흡한 상태로 개발 진행
    • 테스트 코드 작성법 익히기
      • 테스트 코드 작성 경험이 적음 → 무작정 구현부터 진행하고 에러를 잡는 습관을 버리지 못함 → 해당 습관의 개선으로 잘 작성된 테스트 코드를 적용하며 검증하고 싶음.
  • 에러 또는 서버에 대한 새로운 요구사항이 추가되었을 때의 대처 시야가 좁아 시간 대비 유연한 대응을 하지 못한 부분
    • 캠프 기간 중 작성한 개발 기록과 더 많은 개발 경험을 통해 캠프가 끝나더라도 문제가 생겼던 부분들을 계속해서 해결해 나가며 개선하고 싶음.
  • Github 사용에 미숙 → 연동 과정에서 발생하는 에러 해결에 오랜 시간이 걸리고 실수도 잦았음
    • 깃허브 사용 방법 숙지
      • 깃허브의 기본 사용법이 미숙했기 때문에, 이 캠프를 계기로 협업을 위해 깃허브에 대해서 충분한 학습을 통해 깃허브를 이전보다 어렵지 않게 사용하고 싶음.

  ---

ver.2

• 개발
  • 인증인가 과정에서 PHP와 Session 방식 사용 → Spring Framwork와 JWT 방식 도입
    • AccessToken payload에 필요한 사용자 정보를 커스텀하여 넣는 과정에서의 어려움
      • 닉네임 정보를 넣기 위해 여러 가지 방법(Subject 포함, Claim& Claims 삽입, payload 함수 작성 등)으로 해결 시도 → 실패
      • 유저 id값을 통해 닉네임 정보를 요청하는 방법 사용
      • 아쉬운 점 : 토큰에 닉네임 정보 포함 → 사용자에 대한 요청 시 속도 측면에서 큰 이점이 있었을 것
      • Spring 프레임워크의 첫 도입 + 토큰 방식에 대한 전반적 이해 부족이 근본적 원인이었다고 생각.
• 연동
  • 깃허브의 개인 레포지터리만 사용 → fork한 레포지터리 내 별도 브랜치 생성 및 PR & Approve 받아 팀 레포지터리 main에 Merge하는 방식
    • fork한 레포지터리의 main과 별도 브랜치의 끊어진 commit 기록으로 인해 연동 불가 문제가 발생해 시행착오를 겪음.
      • 프로젝트 백업 → 브랜치 재성성 및 연동으로 해결 (IntelliJ를 통한 깃 브랜치 생성 시 ‘New Branch from main..’을 이용해야 commit 기록 연동)
        
      • 아쉬운 점 : 깃에 프로젝트를 연동하는 과정에서 많은 시간 낭비 → 깃허브를 좀 더 공부했었다면 겪을 시행착오가 훨씬 적었을 것
      • 깃허브 사용 미숙 + 무작정 연동부터 시도한 것이 원인 → 확실하지 않은 것은 미리 질문하자!

→ 이 외에도 리뷰와 피드백 과정을 거치며 다양한 고민을 할 수 있었고, 어려움을 겪는 부분에 대해 많은 도움을 받을 수 있었음.

• 시간 분배에 실패하여 계획을 많이 변경하게 되면서 개발 단계에서 끝이 나게 되었음.
• 앞으로의 프로젝트에서는 시간 분배와 계획의 중요성을 염두하며 테스트와 개선까지 할 수 있도록 하자!