미리보기

패션스토리 공유 SNS 플랫폼 B2C 서비스 ‘패퍼하츠’

• 서비스의 초기 MVP 단계의 프로젝트 기획 참여 및 개발

• 클라우드(AWS) 환경에서의 인프라 관리 및 서버 운영

• OpenAI ChatGPT 모델 기반 유사 상품 추천 서비스 개발

• 유저 업로드 숏폼의 이미지 분석 및 스트리밍 시스템 설계

• Delivery-Tracker Open API GraphQL 통신을 통해 실시간 배송 조회 서비스 구현

• 외부 결제 API 연동을 통한 결제 프로세스 구현

• 유저 활동 및 이벤트에 따른 Push Notification 시스템 구현

• Spring Actuator, Prometheus, Grafana 프로그램을 활용한 백엔드 서버 모니터링 시스템 구축

상권 분석 및 창업 예상매출 분석 B2B 서비스 ‘머니뷰어’

• AI 상권분석 결과에 기반한 매장 매출 예측과 신규 출점 매장의 매출 추정 및 동향 정보를 제공하는 B2B 서비스 백엔드 서버 개발 및 고도화

• Java 17, SpringBoot 2.7.1, MySQL 8, 비동기 프로그래밍 기반 REST API 서버 개발

• Geometry 타입의 자료구조를 통해 지도 기반 서비스 개발 (반경 내의 상권 분석, 최소 거리 조회 등)

건축 설계 공모 플랫폼 팀

• 작품 투표 시스템 개발 (PROJECT SEOUL, 2021.05~2021.08)

• 경품 응모 등록 시스템 개발 (LH 설계공모, 2023.01~2023.03)

개발 행위 허가 플랫폼 팀

• 민원 신청 시스템 REST API 서버 개발 (IPSS 통합인허가, 2022.01~2022.07)

• 민원 신청 허가 시스템 REST API 서버 개발 (SUPIS, 2022.09~ 2022.12)

Push Notification 시스템 디자인 및 구현

• 서비스의 이벤트, 상품 주문, 배송, SNS 등 다양한 활동에 대한 SMS, 메일, Push 알림 서버를 설계. 각 서비스는 알림 서버를 비동기적으로 호출하고 알림 서버는 메타데이터를 저장한 후 이벤트를 발행하고 이벤트를 구독하는 작업 서버에서 각 역할에 맞는 실제 알림을 발송하며 Event Pub-Sub 방식을 통해 모듈간 결합도와 비동기적 처리를 가능하게 하였으며, 부하가 발생하는 작업 서버에 대한 수평적 확장이 가능하도록 설계

숏폼 업로드 및 이미지 프로세싱 시스템 설계

• 숏폼 업로드 전체 과정을 서버리스 아키텍처를 활용한 백엔드 서버 부하 최적화

• 파일의 메타데이터 데이터베이스 저장, 첫 프레임 썸네일 추출, AWS MediaConver를 이용한 스트리밍 파일 변환(HLS), 피드에 사용된 음원 로그 추출의 모든 프로세스를 비동기적으로 처리하여 로직의 결합도를 제거

백엔드 서버 모니터링 시스템 구축

• Spring Actuator를 통해 애플리케이션의 주요 지표(메모리 사용량, CPU 사용률, 요청 수, 응답 시간 등)를 수집하고, Prometheus로 이를 주기적으로 스크래핑하여 저장. 시계열 데이터를 기반으로 Grafana에서 실시간 대시보드를 구성하여 서버의 상태를 시각화하였으며, 요청 처리 지연, 비정상적인 메모리 증가, GC 동작 등 이상 패턴을 빠르게 감지하고 대응할 수 있도록 모니터링 시스템을 구축하여 프로덕션 환경의 안정성 확보 및 성능 이슈 사전 감지에 기여

소프트웨어 아키텍처 포트-어댑터 패턴 적용

• 기존 레거시 프로젝트의 모듈 간 순환참조나 레이어드 아키텍처 기반이지만, 정립되지 않은 형태의 코드작성으로 인해 유지보수 및 기능 확장의 어려움을 개선하기 위해 리팩터링 작업 진행. 스프링 DI를 활용하기 위해 포트-어댑터(Design Pattern) 방식의 아키텍처로 구조 변경 계층 간 의존성을 역전하는 설계 및 다형성(Interface)을 통해 변경에는 닫혀있고 확장에는 열려있는 (OCP) 프로젝트 구현

테스트 코드 작성을 통한 소프트웨어 설계와 품질 향상

• 비즈니스 로직 및 사용하는 프레임워크나 라이브러리의 의도된 동작을 검증하기 위해 테스트 코드를 작성하였으며, 테스트 코드를 통해 소프트웨어의 기능 변경이나 확장에 있어서 사이드 이펙트를 사전에 검수할 수 있게 되었으며, 이를 통해 개발자가 심리적 안정감을 갖고 개발을 진행할 수 있음 또한 테스트 코드를 작성하며 해당 객체가 가진 의존성을 커스텀하거나 모킹하여 주입을 하게 되는데, 이 과정에서 불필요한 의존성을 파악할 수 있고 객체의 단일 책임을 생각하며 설계할 수 있는 효과를 얻음

멀티스레딩을 통해 예비 창업 보고서 생성 시간 단축

• 예비 창업 매출 보고서 생성 시 상권 분석, 유동인구 분석, 매출 분석, 결제 내역 분석 등의 여러 통계 데이터를 멀티스레드를 활용하여 병렬적으로 조회하여 생성 시간을 단축 (주로 I/O Bound 작업임을 고려하여 해당 서버의 물리적인 코어의 수보다 더 많은 스레드를 생성, ThreadPoolTaskExecutor 객체를 커스텀하고 스프링 빈으로 등록하여 스레드를 관리)

• (보고서 1회 생성 시 응답시간 18,233ms → 4,288ms)

반경 기반 상권 분석 기능 개발 및 캐싱, 공간 인덱스를 통한 조회 성능 향상

• 상권 분석 서비스를 위해 사용자가 지정한 지점을 중심으로 반경 내

  유동 인구, 연령별 인구 통계, 프랜차이즈 매출 데이터 등을 조회하는 기능을 개발함

  초기에는 단순 거리 계산을 통한 필터링 방식(ST_Distance)을 사용하여 조회 성능이 느려지는 문제가 발생하였고,

  반경이 넓어지거나 데이터량이 많아질수록 응답 시간이 급격히 증가하였음

  위치 컬럼(Point)에 대해 공간 인덱스를 생성하여, 범위 필터링 속도를 개선

  자주 조회되는 상권 내에 반경 데이터를 Redis 기반 캐싱을 적용하여 데이터베이스 I/O를 줄이고 조회 성능 향상

• (평균 응답 속도 500m 반경 기준 3600ms -> 110ms)

JPA N+1 쿼리 문제 개선을 통해 처리 성능 개선

• 기존 프로젝트에서 DBMS 연동 기술로써 JPA(Hibernate)를 사용 중이었고, 오랜 시간 개발자의 편의를 위해 습관적으로 방치되고 있던 엔티티 연관관계 즉시로딩(FetchType.EAGAR)을 지연로딩(FetchType.LAZY)으로 수정. 필요한 경우 Fetch Join 쿼리 또는 BatchSize 조절을 통해 불필요한 쿼리 발생 빈도를 낮추고 트랜잭션 처리 성능을 개선

• (API 1회 호출 시 12건의 SQL 실행 → 3건의 SQL 실행)

프로젝트 도메인 개념 확립 및 모듈화 작업

• 프로젝트의 전체 서비스를 이루고 있는 개념을 도메인 단위로 분류하여 시스템의 이해도를 높이고 도메인 간 역할과 협력을 정의하여 공통 클래스 정의를 통해 코드의 재사용성을 증가. 컴포넌트 간 순환참조 등 불필요한 의존성을 제거하고 응집도를 높였으며 패키지 또는 클래스의 인스턴스 멤버의 접근제어자 지정을 통한 캡슐화를 통해 사이드 이펙트 감소

대용량 테이블 인덱스 적용을 통한 조회 성능 개선

• 약 9만 건의 데이터를 보유한 테이블에서 특정 조건으로 데이터 조회 시
  지속적으로 느린 응답 시간이 발생. 해당 컬럼에 적절한 인덱스가 설정되어 있지 않음을 확인하고,
  자주 조회되는 검색 조건 컬럼에 복합 인덱스를 적용하고 검색 필터링의 인덱스 사용을 유도함으로써 쿼리 성능을 개선
  (기존 평균 응답 시간과 인덱스 적용 후 1200ms → 50ms)

프로세스 컨테이너 배포 및 무중단 시스템 구축

• 중단 없는 서비스를 위해 Docker 컨테이너를 사용하여 격리된 프로세스로 실행 및 Blue-Green 배포 방식으로 무중단 서비스 구현, 데이터베이스를 통하여 사용자의 로그인 세션을 유지하는 방식 사용 (서비스 특성상 데이터베이스를 통해 세션을 유지해도 서버에 부담이 적을 것으로 판단)

외부 API 연동 비동기 프로세스로 응답 속도 개선

• 서비스의 한 개의 기능에서 유저의 요청을 처리한 후 연계되어 있는 외부 서버에 작업 결과에 대한 데이터를 보내줘야 하는 상황에서 해당 작업 스레드를 Non-Blocking I/O 방식으로 동작하게 하여 유저 응답 속도를 개선 (작업 큐와 실패 큐 등을 구현하여 트랜잭션의 원자성을 보장하기 위해 노력)

• (API 1회 호출 시 응답 대기 시간 5,880ms → 442ms)

Pagination 변경을 통한 조회 성능 개선

• 기존 데이터 조회 시 오프셋(offset) 기반의 페이지네이션을 통해 데이터를 조회하였는데,

  
  이는 매번 데이터베이스 테이블의 풀스캔을 수행하므로 성능 저하 이슈를 발생시킴.
  조회 성능 개선을 위해 커서(key) 기반 페이지네이션을 적용하고 데이터베이스 테이블의
  풀스캔을 제거함으로써 속도와 메모리 사용량 측면에서의 성능 저하를 개선.
  대량의 데이터 페이지 조회 시에도 일정한 응답속도를 유지할 수 있게 됨.

• (페이지 요청 시 평균 응답 시간 3400ms → 150ms)