미리보기
기본 정보
"자바 플레이그라운드 with TDD, 클린 코드"라는 NEXTSTEP 강의를 수강하며 백엔드 엔 지니어링에 대한 깊은 흥미를 발견하고, 이 분야로의 전향을 결심했습니다. 이 과정에서의 몰입과 프로젝트 참여는 백엔드 개발에 대한 저의 열정을 확인시켜 주었으며, 지속적인 학 습과 개선을 통해 이 분야에서 전문성을 쌓아가고 있습니다.
기술 스택
Java, Spring Boot, JPA, MySQL, Oracle, MongoDB, Terraform, Jenkins, Docker, nginx, React, IntelliJ IDEA, Git, JIRA, Slack
프로젝트
DependenciesVersionHelper
기타
2024.01. ~ 진행 중
개요 : Spring Boot는 관리하는 의존성에 대해 버전 명시를 자동으로 처리할 수 있음에도 불구하고 이 사실을 인지하지 못해 수동으로 버전을 기입하거나, 해당 의존성이 자동 관리되는지 확인하는 데 시간을 소모하고 있습니다. 이러한 문제를 해결하고 개발자들의 업무 효율성을 향상시키기 위해, Spring Boot가 관리하는 의존성의 버전을 자동으로 식별하여 필요 없는 경우 제거해주는 IntelliJ 플러그인을 개발하였습니다. 개발 과정에서 불필요한 시간 낭비를 줄이고, 보다 직관적이고 효율적인 개발 환경을 제공하는 것을 목표로 합니다.
기술 스택 : Java, IntelliJ Platform Plugin SDK
주요 기능
- 프로젝트 내의 모든 Gradle 파일 파싱
- 해당 Gradle 파일의 의존성 중 Spring Boot가 관리하는 의존성에 해당하고 버전이
기입되어 있다면 버전을 제거
- 해당 Gradle 파일의 의존성 중 Spring Boot가 관리하는 의존성에 해당하지 않고
버전이 기입되지 않다면 버전 확인 및 기입을 지원
성과
- Spring Boot 의존성 관리 프로세스 자동화
역할
- 멀티 Gradle 파일 조회 및 수정 기능 개발
- Spring Boot가 관리하지 않고 버전이 기입되지 않는 의존성 처리 관련 개발
- Kotlin Dsl으로 작성된 gradle 파일도 동작하도록 개발
개선 및 문제 해결
- Spring Boot Version 파싱
문제 : Spring Boot Version을 build.gradle이 아닌 다른 파일에서 관리 시 파싱 불가.
원인 : build.gradle의 내용 확인하여 Spring Boot 버전을 파싱.
대안- 모든 파일에 Spring Boot 버전이 있는지 확인.
- 사용자가 사용하는 버전을 기입.
- IntelliJ의 Libraries를 읽어 버전 확인.
연구 : IntelliJ Platform Plugin SDK
검토 - 모든 파일 검색
- 프로젝트의 복잡성에 비례하여 소요 시간이 증가
- 버전 정보가 저장된 파일의 형식이 다양할 수 있어 타입별 로직이 필요
- 사용자 입력
- 사용상 불편함 발생
- IntelliJ의 Libraries 정보 활용
- 일관된 로직으로 버전 정보를 파싱 가능
해결- IntelliJ 프로젝트의 모든 Libraries 정보를 파싱.
- Libraries 중 Spring Boot의 버전을 식별 및 추출.
고찰 : 서비스 로직의 설계와 사용자 편의성을 고민하며, 가장 적합한 로직을 선별할 수 있는 기회였습니다. 플랫폼의 특정 API를 이해하고 활용하는 데 여러 어려움을 겪었으나, 새로운 기술을 배우고 적용하는 데 있어 큰 동기부여가 되었습니다.
상품 조회 및 구매 API 개발
개인
2023.12. ~ 2024.01.
개요 : 개인 프로젝트로 레이어드 아키텍처를 기반으로 하여 CI/CD 파이프라인 구축부터 실제 서비스 배포까지 모든 과정을 직접 수행하며, 전체 소프트웨어 개발 주기에 대한 깊이 있는 학습을 목표로 했습니다.
기술 스택 : Java, Spring Boot, MySQL, JPA, Redis
주요 기능
- 잔액 충전 / 잔액 조회
- 상품 조회(전체 상품 / 인기 상품)
- 주문 / 결제
성과
- 동시성 이슈 해결 방안에 대한 고찰
- CI/CD 구축 및 모니터링까지 다양한 키워드에 대한 고찰
개선 및 문제 해결
- 재고 관리 동시성 문제
문제 : 동시에 재고 차감 API를 호출할 때, 재고 수량의 차감이 원활하지 않음
원인 : 하나의 프로세스가 재고를 변경하기 전, 다른 프로세스가 동시에 같은 재고에 접근하여 변경을 시도
대안- DB를 이용한 비관적락
- Redis를 이용한 분산락
연구 : 동시성 이슈 해결을 위한 락킹 메커니즘
검토 - DB를 이용한 비관적락
- 기존 DB에서 지원하여 별도의 도구 추가 불필요
- 처리 속도가 느림
- Redis를 이용한 분산락
- Redis 추가로 관리 포인트 및 비용 증가
- 처리 속도가 빠름
※ 실제 사용하지 않는 API로 관리 포인트가 늘지 않는 1번으로 하는게 맞아 보이나,
사용자가 많고 처리 속도가 중요하다고 가정하여 2번으로 진행
해결
- @Transactional이 붙은 메서드 내에서 재고 차감 시 마다 key가 product에 대한
값의 존재 여부를 확인하는 락킹 처리 구현 - Transactional commit이 되기전 언락되어 다른 프로세스에서 재고에 접근 가능한
이슈 발생 - 처리 순서를 Locking > Transactional start > Business logic > Transactional commit > Unlocking 로 변경하여 해결
- 단일 차감 시 모든 차감 로직을 블록하여 productId를 기준으로 락킹 로직 변경
- productId가 (1, 2, 4)와 (2, 1, 4) 같이 역순으로 두개의 차감 API 호출 시 데드락
문제 발생 - productId 기반 정렬 후 락 걸기로 데드락 문제 해결
고찰 : 분산 락과 비관적 락 같은 다양한 동시성 제어 기술을 비교 분석하고 적용해보면서, 기술적 선택이 실제 서비스 성능과 사용자 경험에 미치는 영향을 고민할 수 있는 경험이었습니다. 또한, 프로젝트를 진행하면서 발생하는 예기치 않은 문제들을 해결하기 위해 다양한 기술 문서를 참고하고, 커뮤니티의 지식을 활용하는 등 지속적인 학습의 중요성을 체감할 수 있었습니다.