DEVHUB ⭐
프로젝트 형상관리 기능을 활용하기 어려워하는 초보 개발자들을 위한 프로젝트 형상관리 서비스
기간 : 2024/07~2024/10
팀 구성 : Front-end 2, Backe-end 3
사용 기술 & 라이브러리 : Spring Boot, JPA, Spring Security, JWT, MySQL, Redis, Nginx, Docker, AWS
팀에서의 역할
1. PL을 맡아, 팀원들의 코드를 피드백하고 깃허브를 활용하여 코드를 병합하는 업무를 담당했습니다.
2. 프로젝트의 핵심 서비스인 형상관리 기능을 설계하고 구현하는 부분을 담당했습니다.
담당한 부분
1. 프로젝트 글로벌 세팅 (글로벌 예외처리 관련 클래스, SecurityConfig 클래스 등)
3. 개인 프로젝트 도메인 관련 기능 설계 및 구현
4. 팀 프로젝트 도메인 관련 기능 설계 및 구현
개선한 부분
1. 이메일 발신 기능 성능 개선
• 이메일 발신 기능이 동기 방식으로 처리되는 것은 실제 서비스에서 치명적인 문제가 될 것이라고 판단했습니다.
• 비동기 방식으로 처리되도록 바꾸고나서 결과적으로 1초 동안 각 요청으로부터 소요된 응답 시간을 평균 4.159초(4159ms) → 0.017초(17ms)로 개선하였습니다.
• 이메일 발신 기능의 성능 개선 과정에 대한 자세한 내용을 기술 블로그에 기록해 두었습니다.
이메일 발신 기능 성능 개선 과정 - Tistory
고민한&학습한 부분
1. 형상관리 전략 (”snapshot” VS “Git”)
• 프로젝트 형상관리 기능을 제공하기 위해 서버에서 어떤 방식으로 유저의 프로젝트를 저장하고 형상관리 해야할지에 대해서 많은 고민이 있었습니다.
◦ 디스크 용량 부족 문제 : 유저가 업로드하는 프로젝트 파일을 서버 디스크에 그대로 저장할 경우, 매번 새로운 버전을 업로드할 때마다 동일하거나 비슷한 용량의 파일이 반복적으로 저장되게 됩니다. 이런식으로 파일이 계속 저장된다면 서버의 디스크 용량이 빠르게 소진되어 결국 저장 공간 부족 문제가 발생할 것이라고 생각했습니다.
• 초기에는 “snapshot“ 기법을 활용하여 형상관리 전략을 설계 했지만 문제가 존재하여 결론적으로 Git 시스템을 이용하게 되었습니다.
• 형상관리 전략을 결정하기까지의 자세한 과정을 노션에 기록해 두었습니다.
형상관리 전략 결정 과정 - Notion
2. 팀 저장소 내에서 여러 팀원이 동시에 파일을 업로드할 경우
• 처음에는 하나의 프로젝트를 관리하는 팀 저장소 내에서 여러 팀원이 동시에 파일을 업로드했을 때 서버에는 최초 한 팀원의 파일만이 저장되는 것을 의도했습니다.
• 하지만 의도와 달리 여러 팀원이 동시에 업로드한 파일이 서버에 모두 저장되었고 이 부분을 어떻게 해결할지 많은 고민이 있었습니다.
• 결론적으로 DB 락을 걸어 우회적인 방법으로 해결하였으며 그 과정을 기술 블로그에 기록해 두었습니다.
파일 저장 로직의 동시 요청에 의한 동시 저장을 방지하는 방법 - Tistory
3. AWS + Docker를 이용한 프로젝트 배포 과정
• 이전에 AWS EC2 서버에 스프링부트 프로젝트를 배포해 본 적이 있지만 이번 프로젝트에서는 Docker를 이용하여 EC2 서버에서 스프링부트 프로젝트를 배포한다는 점에서 차이가 있습니다.
• RDS에 데이터베이스 생성하고 연동하는 과정을 기술 블로그에 기록해 두었습니다.
스프링부트 프로젝트와 AWS RDS를 연동하는 과정 - Tistory
• 또한, EC2에 Docker로 프로젝트를 배포하는 과정을 기술 블로그에 기록해 두었습니다.
AWS EC2에 Docker로 스프링부트 프로젝트를 배포하는 과정 - Tistory
배움
이번 프로젝트에서 PL을 맡아 팀원들의 코드를 피드백하고 병합하는 일을 담당하며, 이러한 책임을 맡은 것이 많은 경험치가 되었습니다. 특히, 코드를 병합하는 과정에서 충돌이 날 때마다 직접 해결해 봄으로써 코드가 충돌 났을 때 대처하는 능력을 키울 수 있었습니다.
프로젝트 개발을 위해서 형상관리 시스템에 대한 깊이 있는 지식이 필요했고 이를 계기로 Git 시스템에 대해 공부했던 부분과 협업 과정에서 프로젝트 형상관리의 총책임을 맡았던 경험을 통해 Git 시스템에 대한 이해도가 많이 높아진 부분이 굉장히 뜻깊습니다.
또한 새로운 기술을 시도해 본 덕분에 다양한 지식을 습득할 수 있었으며 그 과정에서 CI/CD 구축을 통해 배포를 자동화하는 것에 대해 처음 알게 되었고 흥미가 생겨, 또다른 무언가를 공부해 보고 싶은 목표가 생긴 것이 이번 프로젝트에서 가장 큰 수확인 것 같습니다.
게시판 프로젝트
다양한 기술 활용과 코드 디자인, 코드 리뷰를 통한 서비스 최적화 과정으로 실무 프로젝트 수준의 개발을 목표로 진행한 프로젝트
기간 : 2023/03~2023/05
팀 구성 : Leader 1, Back-end 2
사용 기술 & 라이브러리 : Spring Boot, JPA, Querydsl, H2, Redis
담당한 부분
2. Pagination 처리하여 게시글 조회 API 최적화
트러블 슈팅
1. JPA N+1 문제
• 게시글 조회 시, 연관관계 설정된 태그 엔티티 객체를 사용하려는 과정에서 태그 엔티티에 대한 N만큼의 추가 쿼리가 발생하는 현상을 발견했습니다.
• @Query 어노테이션과 JDBC 쿼리문을 구현해서 태그 엔티티를 Fetch Join 하여 해당 문제를 해결하였습니다.
• 다음에도 학습한 과정을 복습할 수 있도록 트러블 슈팅 과정을 기술 블로그에 기록해 두었습니다.
N+1 문제 트러블 슈팅 - Tistory
2. 게시글 좋아요 기능 동시성 문제
• 게시글 좋아요 기능에서 여러 Thread가 동시에 API 요청을 보냈을 때 예상한 결과와 다르다는 것을 파악했습니다.
• JMeter 부하 테스트 도구를 이용하여 동시성 문제가 발생한 것을 발견했고 문제가 발생하는 레코드에 베타락을 거는 방식으로 문제를 해결하였습니다.
• 다음에도 학습한 과정을 복습할 수 있도록 동시성 문제를 트러블 슈팅한 과정을 기술 블로그에 기록해 두었습니다.
좋아요 기능 동시성 문제 트러블 슈팅 - Tistory
배움
스프링부트 프레임워크를 체계적인 구조에 따라서 개발해 볼 수 있었습니다. 또한 예외처리의 흐름과 처리 방식에 대해 학습할 수 있었습니다.
개발을 하면서 발생한 트러블에 대해 직접 원인을 찾고 문제를 해결해나가는 과정이 좋은 경험치가 되었습니다.
무엇보다 Git-flow 방식을 활용하여 팀원과 협업해 볼 수 있었던 부분이 가장 뜻깊은 경험이라고 생각합니다.
다만 개발 기간이 시간적으로 촉박한 상황에서 스프링에 대한 이해도가 부족하여 깊이있게 생각하지 못하고 구현만을 목적으로 디테일한 부분을 신경쓰지 못하고 넘어간 부분에 대해서는 아쉬움이 남습니다.
이번 프로젝트를 계기로 기본적인 지식을 탄탄히 학습하고 기록하는 습관을 들여서 디테일한 부분까지도 신경쓸 수 있는 역량을 갖춰 준비해두어야 겠다는 생각이 들었습니다.
FYB(Fit Your Balence)
모든 사용자의 앱 내 활동을 수집한 데이터를 기반으로 각 사용자에게 맞춤 쇼핑몰을 추천해 주는 서비스 (2022년도에 진행한 학부 졸업작품입니다)
기간 : 2022/03~2022/11
팀 구성 : Back-end 1, Android 1, Design 2
사용 기술 & 라이브러리 : Anoroid, JAVA, Retrofit2, OkHttp3, Gson
담당한 부분
안드로이드 애플리케이션 전체 구현
배움
프로그래밍을 배우고나서 거의 처음 만들어 본 규모 있는 프로젝트였기 때문에 성취감이 컸고 기대한 것 보다 결과가 완성도 있게 나온 것 같아 뿌듯했습니다.
또한 이번 프로젝트에서 클라이언트와 서버가 HTTP 통신으로 데이터를 주고 받아 서비스를 제공한다는 개념 자체를 처음 알게 되었고 그 과정을 직접 구현 해볼 수 있었던 부분이 너무 좋은 경험이 되었습니다.
이번 프로젝트에서 팀원 간 의사소통의 부재가 프로젝트의 진행과 팀의 사기를 떨어뜨릴 수 있다는 것을 느꼈고 앞으로의 팀 활동에서는 더 적극적으로 팀원과 소통해야겠다 다짐하게 된 계기가 됐습니다.