안녕하세요, 오늘은 커리어톤 3주차 내용을 정리해보았습니다.
오늘의 목표 : 프로젝트 파트를 완성하고, 이력서 초안 만들기
- 2주차의 내용을 바탕으로, 프로젝트 파트를 완성합니다.
- 내용이 잘 채워져 있다면, 이력서 형태로 멋지게 다듬어봅시다!
프로젝트 내용 구성
- 설득력 있는 트러블 슈팅
- 기술적 의사 결정
- 수치/정량화된 성과
구문 다이어트
- 문장 나누기
- 불필요한 단어 제거
- 불필요한 정보 제거
- 본인과 팀을 지칭하는 단어 제거
- 수동태, 번역체, 구어체 제거
- 하나의 문장에는 하나의 내용만 담기
3줄요약
- 길게 쓰여진 문장을 줄이기
- 내가 쓴 문장에 핵심 키워드가 있는지 점검
- 두괄식으로 제목을 정리
Before
- ADMIN 권한 부여 방법 프로젝트에서 서비스 및 유저를 관리할 관리자 계정의 필요성을 인지했고, 어떤 방식으로 관리자 권한을 부여할지에 대해 고민을 하였습니다. DB에서 권한을 직접 바꿔주는 방법을 고민해보았으나, 실무에서 부서간 거쳐야 할 요인이 한단계 더 추가되기 때문에 기각하였고, 이를 보완하기 위해 회원가입시 ADMIN Token 을 입력하고 검증되면 관리자 계정으로 회원가입이 되는 방법으로 구현하였습니다. ADMIN Token을 해당 부서에서 직접 관리할 수 있도록 하여 부서간 업무협조의 불필요한 과정을 줄일 수 있을 거란 결론을 얻었습니다. 단, 해당 부서 모든 인원에게 ADMIN Token 이 공개되어 있으면 보안에 취약할 수 있으므로, 해당 부서 관리자급만 ADMIN Token을 관리하게 해서 이를 방지해야 한다는 점도 깨달을 수 있었습니다.
After
- ADMIN Token을 통한 관리자 권한 부여 관리자 권한 DB에 직접 바꿔주는 방법 고려, 보안 취약점이 생기고 권한 관리 추적 어려움. 회원가입시 ADMIN Token을 입력하여 관리자 권한 부여되도록 구현.
Before
- ADMIN 권한 설정 범위 ADMIN의 역할 및 권한을 어디까지 설정해줘야 할 지에 대해 고민을 하였습니다. 기본적인 챌린지 생성 및 수정, 삭제까지는 권한 부여에 어려움이 없었으나, 유저정보를 다룰 수 있는 권한을 부여시에 개인정보가 노출되고 보안이 취약해지는 문제가 충분히 발생할 수 있다고 인지했습니다. 따라서, 유저정보 관련 ADMIN 계정의 수정 권한은 point 관련 문제 발생을 대비한 point 수정 권한, 악성 유저를 필터링해야 할 경우를 대비한 유저 차단 권한으로 최소화하였습니다. 유저 테스트를 진행하고, 피드백을 수렴하는 과정에서 ADMIN의 권한과 개인정보 노출에 대한 질의를 받았고, 이에 대해 과정을 응답하였을 때, 서비스에 대한 유저의 신뢰를 얻을 수 있었습니다.
After
- 유저정보 ADMIN 수정 권한 최소화 개인정보 노출 위험 방지, 서비스에 대한 유저 신뢰도 상승을 목표. 유저정보 관련 ADMIN 수정 권한 최소화.
Before
- 동시성 제어 방법 챌린지에 참여 인원 제한을 두었고, 이 때, 발생하는 동시성 제어 상황에 어떤 동시성 제어 방법을 구현할 지에 대해 고민을 하였습니다. 우선, 동시성 제어 대상의 특징을 파악하였습니다. 챌린지 참여 인원 제한은 쇼핑몰의 상품 재고와 같은 개념이고, 충돌 가능성이 높으며 데이터 일관성이 가장 중요했습니다. 이러한 특징을 염두해 두고, 각각의 동시성 제어 방법을 비교해 보았습니다. 분산 락의 경우, 여러 노드에서 접근할 때 안전한 동시성 제어 기능을 제공하는 특징이 있으나, 현재 구조에서는 MySQL이 동시성 제어를 담당하여 어울리지 않았습니다. 낙관적 락의 경우, DB에 락을 걸지 않아 동시성을 최대한 활용 가능하다는 특징이 있으나, 충돌 빈도가 높은 현재 구조에서는 오히려 성능 저하 현상이 발생한 가능성이 높았습니다. 이러한 결과로, 데이터의 일관성을 강력하게 보장하며, 충돌 가능성이 높은 환경에서 안정적으로 동작하는 비관적 락을 선택하여 구현하였습니다. 이 때, 비관적 락의 성능 저하 이슈를 대비하기 위해서, 락 범위와 락 소유 시간을 최소화하였습니다.
After
- 비관적 락을 통한 동시성 제어 챌린지 참여 인원 제한에 동시성 제어, 쇼핑몰의 상품 재고와 같은 개념, 충돌 가능성이 높으며 데이터 일관성이 중요. 제어 대상 특성에 적합한 비관적 락 구현, 성능 저하 이슈 대비하기 위해 락 범위와 락 소유 시간을 최소화.
Before
- CORS 에러 백엔드 API 를 프론트엔드 연결하는 과정에서 CORS 에러를 마주하였고, 해당 에러를 해결 및 방지하기 위한 방법을 고민하였습니다. 여러번의 시행착오를 겪은 결과, CORS 에러는 크게 3가지 사항을 체크해야 한다는 점을 알 수 있었습니다. 백엔드에서는 CORS 설정을 확인해야했습니다. WebMvcConfigurer의 프론트엔드 오리진이 허용되어 있는지를 체크해야 했습니다. 프론트엔드에서는 API 요청 경로를 확인해야 했습니다. Vue.js 로 구현하였는데 axios.js의 요청 URL 및 포트번호를 체크해야 했습니다. 도커 컨테이너 네트워크 설정을 확인해야 했습니다. docker-compose.yml 파일에 해당 설정을 체크해야 했습니다. CORS 에러 발생시에는 각각 해당되는 부분을 크로스 체크해줘야 한다는 결과를 얻을 수 있었습니다.
After
- CORS 에러 방지 크로스 체크 백엔드 API 프론트엔드 연결과정에서 CORS 에러 방지하기 위한 크로스 체크 필요 . 백엔드 CORS 설정 확인, 프론트엔드 API 요청 경로 확인, 도커 컨테이너 네트워크 설정 확인.
프로젝트 내용 완성하기
1. CHALLENGERS - B.O.D (최종 프로젝트)
- 프로젝트 소개 : 다양한 챌린지를 제공하는 동기부여 서비스
- 사용 스킬 : JDK 17, Spring Boot 3.3.0, Spring Security, MySQL 8.0.39, Redis 7.4.0, AWS (IAM, EC2, 로드밸런서, S3, Route 53), Docker (27.1.1) & Docker-Compose (2.29.1), NginX (1.24.0)
- ADMIN Token을 통한 관리자 권한 부여
- 관리자 권한 DB에 직접 바꿔주는 방법 고려, 보안 취약점이 생기고 권한 관리 추적 어려움.
- 회원가입시 ADMIN Token을 입력하여 관리자 권한 부여되도록 구현.
- 유저정보 ADMIN 수정 권한 최소화
- 개인정보 노출 위험 방지, 서비스에 대한 유저 신뢰도 상승을 목표.
- 유저정보 관련 ADMIN 수정 권한 최소화.
- 비관적 락을 통한 동시성 제어
- 챌린지 참여 인원 제한에 동시성 제어, 쇼핑몰의 상품 재고와 같은 개념, 충돌 가능성이 높으며 데이터 일관성이 중요.
- 제어 대상 특성에 적합한 비관적 락 구현, 성능 저하 이슈 대비하기 위해 락 범위와 락 소유 시간을 최소화.
- CORS 에러 방지 크로스 체크
- 백엔드 API 프론트엔드 연결과정에서 CORS 에러 방지하기 위한 크로스 체크 필요 .
- 백엔드 CORS 설정 확인, 프론트엔드 API 요청 경로 확인, 도커 컨테이너 네트워크 설정 확인.
- 서비스 환경 테스트를 위한 스테이징 환경 구축
- 로컬 테스트 뿐만 아니라, 실제 서버 테스트를 위해 스테이징 서버 구축.
- Dev 브랜치로 스테이징 서버 테스트 이후, Main 브랜치 서비스 서버로 전송.
- Redis 활용을 통한 응답속도 개선
- 포인트 랭킹 조회시 QueryDSL 평균 응답속도 1,547ms 로 성능 개선 필요.
- Redis 활용 로컬 평균 응답속도 885ms 로 42.8% 향상, 스테이징 서버에선 24.6% 향상
새로운 시작~!