https://leejuno-portfolio-opcd240.gamma.site/ 에서 보시면 블록링크 기능을 이용하여 더 편하게 보실 수 있습니다!
이준오의 포트폴리오
Contact
- mail: [email protected]
- phone: 010-4663-6345
Site
- Github: https://github.com/junodevv
- Blog: https://junodevv.github.io
- Java, Spring, Docker, SQL, Git 활용에 자신이 있습니다.
- 가독성과 유지보수성을 고려한 코드를 작성해 나가는 것을 좋아하며 팀원들과의 의사소통에 적극적으로 참여합니다.
문제인식 → 해결방안 탐색 → 구현(적용) → 결과의 프로세스로 문제를 해결해 나가는 것을 좋아합니다.
🧑🎓 학력
- 2018.03 ~ 2025.02
가천대학교 경제학, 컴퓨터공학 학사 [3.87 / 4.5]
[컴퓨터공학 전공 관련 이수 현황] 평균학점 : 4.29
🏆 수상 및 자격
- 2024.06.18 정보처리기사 취득
- 2023.11.07 네트워크관리사 2급 필기합
- 2023.06.16 데이터분석준전문가(ADsP) 취득
- 2022.12.22 SQLD(SQL개발자) 취득
📚 기술 스택
Backend
- Java
- Spring
- Security
- MVC
- Data JPA
Infra
- Docker
- AWS
- EC2
- S3
- CodeDeploy
DB
- MySQL
- MariaDB
ETC
- Github Action
- Linux
- JavaScript
- CSS, HTML
- Notion
- GitHub
🍱 SsaGeMeogJa(싸게먹자)
👨💻 프로젝트 개요
고물가 시대에 합리적인 소비를 돕기위한 프로젝트.
높은 배달비와 물가가 부담스러워 마트를 방문하는 소비자들에게 각 마트별 가격과 거리를 비교할 수 있는 정보를 제공합니다.
사용자가 장바구니에 담은 상품을 기반으로 "주변 마트의 거리", "상품 가격 정보"를 제공하여 합리적인 소비를 할 수 있도록 돕습니다.
높은 배달비와 물가가 부담스러워 마트를 방문하는 소비자들에게 각 마트별 가격과 거리를 비교할 수 있는 정보를 제공합니다.
사용자가 장바구니에 담은 상품을 기반으로 "주변 마트의 거리", "상품 가격 정보"를 제공하여 합리적인 소비를 할 수 있도록 돕습니다.
핵심기능
- Auth2.0 로그인
- 카카오 맵을 이용한 사용자 위치 및 주변 마트 위치, 거리 제공
- 마트별 상세 데이터 및 상품 데이터 제공(공공데이터)
- 장바구니서비스 및 장바구니에 담긴 상품의 가격을 마트별로 제공
- 마트별 리뷰,평점 제공
1
🧺 장바구니 기능 상세
- 장바구니 상품 추가/수정/삭제 기능 구현
- 상품 검색 기능 구축
2
🧬 CI/CD 구축 및 배포 상세
- Jasypt 라이브러리, Github Secret을 활용한 application설정 파일 암호화
- Github Actions을 활용한 자동 빌드 및 배포 실행
- AWS S3, CodeDeploy, EC2를 이용한 자동 배포 및 운영
3
🎸 기타
- RESTful api 적용
- 예외처리 커스텀
- 도메인로직의 분리
- 항상 성공할 수 있는 TestCode 작성 (Mockito)
1. 환경, DB에 의존하지 않고 성공할 수 있는 테스트코드 작성
초기에 작성한 테스트코드가 개발 단계에서 사용중인 더미데이터에 의존하고 있어, 실제 배포시 테스트가 실패할 가능성이 있다는 문제를 발견했습니다. 또한 Spring Boot에 의존하고 있어 서버를 띄우는 과정에서 테스트 코드 실행에 보다 많은 시간이 걸린다는 것을 알게 되었습니다.
이를 개선하기 위해 더미데이터에 의존하지 않는 테스트코드를 작성할 방법을 고민한 끝에, SpringBoot에 대한 의존성도 줄여 효율성을 높일 수 있는 Mockito 테스트 프레임워크를 활용하기로 결정 했습니다.
Mockito를 활용하여 Service계층 단위 테스트를 진행할 때, Repository부분을 Mocking 하여 DB와 SpringBoot에 대한 의존성을 줄였으며, 이로 인해 테스트 실행시간이 감소했습니다.
추후에 진행한 속도 비교 결과 Mockito를 활용한 테스트코드의 테스트 실행 속도가 약 62.5% 감소했다는 것을 확인할 수 있었습니다.
1
문제 인식
더미데이터 의존성과 SpringBoot 의존성으로 인한
테스트 실패 가능성 및 긴 실행 시간
2
해결 방안
Mockito 테스트 프레임워크 도입
3
구현
Service 계층 단위 테스트에서 Repository Mocking
4
결과
테스트 실행 속도 약 62.5% 감소
2. 가독성과 유지보수성을 고려한 코드 작성
Enum 클래스를 이용하여 의미있는 네이밍의 응답 메시지를 사용함으로써 코드의 가독성을 향상시켰습니다.
또한 주요 로직의 메서드에 적절한 주석을 작성하여 누구나 코드를 쉽게 이해할 수 있도록 했습니다. 이러한 주석은 해당 메서드의 역할과 파라미터, 반환값을 명시하여 가독성을 높이는 데 기여했습니다.
👨🚒 트러블 슈팅
장바구니 상품 수량 수정 부분에서 초기에는 하나의 api로 수량증가, 수량감소, 직접입력 을 모두 처리하도록 코드를 작성했습니다. 하지만 하나의 메서드 내부에 많은 코드 라인과 조건문으로 인해 가독성이 떨어진다고 생각했습니다. 또한, 하나의 메서드에서 3가지의 역할을 하다보니, 향후 유지보수하는 데에 불리할 것이라 판단했습니다.
이 문제를 해결하기 위해 수량 증가, 감소, 직접입력을 각각의 API로 분리했습니다.
결과적으로 Service 계층에서는 35라인에서 36라인으로, Controller 계층에서는 7라인에서 22라인으로 증가하여, 전체 코드 라인은 42라인에서 58라인으로 12라인 증가했습니다. 그러나 이 과정에서 코드의 가독성, 유지보수성, 그리고 확장성을 확보할 수 있었습니다.
장바구니 상품 수량 수정 부분에서 초기에는 하나의 api로 수량증가, 수량감소, 직접입력 을 모두 처리하도록 코드를 작성했습니다. 하지만 하나의 메서드 내부에 많은 코드 라인과 조건문으로 인해 가독성이 떨어진다고 생각했습니다. 또한, 하나의 메서드에서 3가지의 역할을 하다보니, 향후 유지보수하는 데에 불리할 것이라 판단했습니다.
이 문제를 해결하기 위해 수량 증가, 감소, 직접입력을 각각의 API로 분리했습니다.
결과적으로 Service 계층에서는 35라인에서 36라인으로, Controller 계층에서는 7라인에서 22라인으로 증가하여, 전체 코드 라인은 42라인에서 58라인으로 12라인 증가했습니다. 그러나 이 과정에서 코드의 가독성, 유지보수성, 그리고 확장성을 확보할 수 있었습니다.
1
문제 인식
기존 상품수량 로직의 많은 역할과 조건문으로 인한 가독성 감소
2
해결 방안
수량 증가, 감소, 직접 입력의 로직을 각각의 API로 분리
3
구현
Controller 계층 7 → 22 line
Service계층 35 → 36 line
총 12라인 증가
Service계층 35 → 36 line
총 12라인 증가
4
결과
가독성, 유지보수성, 확장성 확보
⬆️ 기존 상품 수량 변경 API 순서도 - 하나의 API로 모든 기능을 처리하는 구조
⬆️ 리팩토링된 상품 수량 변경 API 순서도 - 분리된 API 구조
기존코드
리팩토링후 분리된 코드(증가)
리팩토링후 분리된 코드(감소)
리팩토링후 분리된 코드(직접입력)
3. Restful API 설계
이전에는 API 를 설계할 때, 어떤 방식으로 작성하는 것이 좋은 API인 것인지 명확히 알지 못한 채 설계를 진행했습니다. 그러나 프론트엔드 팀원들과의 협업 및 유지보수 측면에서, 지금까지 마음대로 해왔던 API설계를 개선해야겠다는 생각을 하게 되었습니다.
이번 프로젝트를 진행하면서, 보다 나은 API를 작성하기위해 여러 가이드를 참고하며 RESTful API에 대한 공부를 하게 되었습니다. 그 결과 작업에 따라 적절한 HTTP 메서드를 사용해 CRUD를 구분하고, 불필요하게 URI가 길어지지 않도록 하여 가독성이 좋은 API를 설계할 수 있었습니다.
또한, 위와 같이 설계한 API를 문서화 하여 개발과정에서 프론트엔드 팀원들과 원활하게 소통할 수 있었습니다.
4. IT 인프라 시스템 개선을 통한 배포 프로세스 소요 시간 70% 단축
기존의 IT 인프라는 잦은 에러, 수동 배포, 보안으로 인한 배포 자동화 불가 등의 문제점이 있었습니다. 이를 해결하기위해 배포자동화를 실현할 수 있는 IT 인프라에 대해서 학습하게 되었습니다.
아래의 과정을 통해 IT 인프라 시스템을 개선하게 되었고 배포 프로세스를 자동화 하였습니다. 그 결과 배포 프로세스 소요시간이 3~5분에서 1~1분30초로 약 70% 단축되었고 누구나 Github의 Actions 버튼을 통해 쉽게 배포할 수 있는 환경을 제공할 수 있었습니다.
제가 학습한 방식들에는
Docker + EC2 + Github Actions를 활용하는 방식과 AWS S3 + CodeDeploy + EC2 + Github Actions 인프라 만을 사용하는 방식이 있었습니다.- EC2를 프리티어로 운영하기 때문에 보다 완전한 복사를 하게되는 docker image를 dockerHub에 업로드하고 다운받기보다 S3에 어플리케이션 실행을 위한 필수 의존성들만 빌드되어있는 jar파일을 올리고 CodeDeploy로 배포하는 것이 리소스 절약에 적절하다고 판단하여 후자의 방식 선택했습니다.
- 또한 Docker에는 이미 자신이있어 AWS 인프라만을 사용하면서 AWS인프라에 대해서 공부해보고 싶었습니다.
👨🚒 트러블 슈팅
- EC2 프리티어를 사용하면서 초기에는 기본 1GB의 메모리만을 사용하였습니다. 여러번 배포를 하면서 DB와 SpringBoot 어플리케이션을 여러번 띄우고 내리기에는 메모리가 부족함을 알게되었고 메모리 스왑을 통해 EC2의 디스크의 일부(2GB)를 메모리로 사용할 수 있게끔 설정하여 총 3GB의 메모리를 사용할 수 있도록 설정했습니다.
- 사용 인프라: AWS S3, AWS CodeDeploy, AWS EC2, Github Actions
- CI/CD 파이프라인 구성도:
🌐 WEB-IDE
👨💻 프로젝트 개요
웹 환경에서 사용가능한 IDE를 구현해본 프로젝트
핵심기능
- 코드 편집기능
- 회원가입 로그인 기능
- 실시간 채팅 기능
1
👥 회원가입/로그인 기능
- Spring Validation 을 사용한 회원가입 form에 대한 검증 기능 구현
- Spring Security 를 이용하여 로그인 기능 구현 및 인증, 인가 로직 구현
- JWT토큰을 이용한 인증/인가 로직 구현
2
🧬 배포
- 카카오 사내에서 사용하는 도커, 쿠버네티스 기반 웹 어플리케이션인 "krampoline" 을 이용한 배포 진행
1
👨👩👧👧 예약 대기 인원 조회 기능
- 클라이언트에게 가게 ID를 매개변수로 받아 대기인원(”wait”상태인 인원)을 계산하여 반환해주는 기능 구현
2
🗓️ 날짜별 예약 상세 정보 조회 기능
- 가게 ID와 날짜를 입력받아 날짜별 손님들의 상세정보를 반환해주는 기능 구현
📼 시연영상
