창의적인 문제 해결과 효율적인 코드로
더 나은 서비스를 만들어갑니다
수학 전공을 통해 다진 논리적 사고력으로 복잡한 요구사항을 명확한 구조와 설계로 풀어내는 데 강점이 있습니다.
기술적 선택에는 항상 이유가 있어야 한다는 원칙 아래, 성능 개선과 시스템 안정성을 지속적으로 고민합니다.
깔끔하고 유지보수가 쉬운 코드를 작성하기 위해 노력합니다.
함께 일하고 싶은 개발자가 되는 것을 목표로 합니다.
다양한 기술을 활용하여 문제를 해결합니다
⚡ 입찰 핵심 로직을 DB에서 Redis로 분리
문제: 입찰가 읽기·쓰기 요청이 단일 DB에 집중되며 CPU 80~90% 급등 및 TPS 저하 발생. 트랜잭션 충돌 및 Race Condition 위험 존재
해결: Redis Write-Behind 패턴으로 입찰 가격 검증·갱신 로직 분리, Redisson 분산 락으로 동시 요청 직렬화
⚡ 변경 빈도 낮은 데이터 캐싱
문제: 변경이 거의 없는 카테고리 조회가 모두 DB에 전달되어 반복 Read I/O 누적, 트래픽 증가 시 병목 발생
해결: Redis 캐싱 도입으로 조회 요청을 캐시 계층에서 처리하고 DB 직접 접근 제거
⚡ 트랜잭션 전파 문제 해결
문제: 클래스 레벨 @Transactional(readOnly=true)로 인해 분산 락 내부의 쓰기 트랜잭션이 같은 컨텍스트를 공유하여 동시성 제어 무효화
해결: 입찰 로직에 REQUIRES_NEW 전파 속성 적용하여 독립된 쓰기 트랜잭션으로 분리
DB CPU 사용률 감소 (카테고리 API 기준)
약 80~90% 감소
조회수 처리 (5,000 동시 요청)
처리 시간 59% 감소, 100% 성공률
입찰 API TPS 향상
약 1.5배 증가
API 평균 응답시간 개선
약 36% 감소
⚡ 검색 성능 병목 해결
문제: MySQL LIKE 검색으로 인한 Full Table Scan 발생, 복합 조건 검색 시 평균 690ms 소요
해결: OpenSearch 도입 및 nori 형태소 분석기 적용, 역 인덱스 기반 검색 구조로 전환
⚡ 검색 엔진 선택과 성능 개선
문제: LIKE 기반 Full Scan 구조로 평균 690ms 지연 발생, Full-Text Search(N-gram) 적용 후에도 302ms 수준으로 목표 성능 미달
해결: Elasticsearch 도입 및 Nori 형태소 분석기 적용, 검색 엔진을 DB에서 분리
검색 성능 비교 (100만 건 데이터 기준)
약 13배 개선 (92% 감소)
MSA 기반 마이크로서비스 아키텍처 (Auction, Main, Batch 서비스 분리)
AWS ECS Fargate + RDS Aurora + ElastiCache + OpenSearch + RabbitMQ