유승우 프로필

유승우

백엔드 개발

About

  • 수치 기반의 병목 개선: 실서비스와 AWS 인프라를 함께 다루며, 병목은 기능 추가보다 수치·로그로 먼저 확인하고 개선합니다.
  • 성능 및 아키텍처 최적화: '별볼일' 프로젝트에서 Caffeine·Redis 이중 캐시를 도입해 외부 API 응답을 19초에서 4초(78% 단축)로 줄였으며, 'EZCODE'에서는 QueryDSL 최적화(314ms → 134ms) 및 ActiveMQ·서킷 브레이커로 알림 파이프라인의 고가용성을 확보했습니다.
  • 안전한 인프라와 협업: Terraform으로 AWS 인프라를 코드화(IaC)하고 DB망 분리 구조를 설계했습니다. 또한, 코드 리뷰와 장애 원인 분석 회의를 주도하며 재현 가능한 근거를 남기는 협업을 지향합니다.

기술 스택 및 역량

백엔드(Backend)

  • Java, Spring Boot — REST API, 계층형 구조·도메인 분리, 이벤트·비동기 처리

데이터베이스 및 캐시(DB / Cache)

  • MySQL, QueryDSL — 복잡 조회·Spatial, 실행 계획 기반 튜닝
  • Redis, Caffeine — L1–L2 캐시, 인스턴스 간 정합성
  • MongoDB — 알림 등 실시간 데이터, 멱등 처리

인프라 및 데브옵스(Infra & DevOps)

  • AWS: EC2, RDS, ElastiCache / Terraform(IaC) — 망 분리·보안 그룹
  • ActiveMQ — 메시징, 서킷 브레이커

프로젝트

별볼일

위치 기반 별 관측 적합도 분석 및 북마크 추천 백엔드 서비스

개요
위치 기반 별 관측 적합도 분석 및 추천을 제공하는 백엔드 (개인 프로젝트, 기여도 100%) 및 인프라 구축
주요 역할
실제 트래픽 규모를 가정해 외부 API 한도·수평 확장 관점에서 병목을 먼저 정의하고, 이중 캐시·트래픽 제어·병렬 처리로 해결. Terraform 기반 AWS 인프라 자동화 및 보안 망 분리 설계

핵심 성과

[트러블슈팅 1] 외부 날씨 API 한도 제한 및 응답 지연 극복
문제

관측지 점수 계산 시 외부 날씨 API(OpenWeatherMap)의 분당 60회 호출 제한으로 인해, 북마크가 많아질수록 API 병목 및 한도 초과 오류(Rate Limit) 발생 위험.

접근

불필요한 API 호출을 원천 차단하는 캐싱과, 불가피한 호출을 안전하게 제어하는 병렬 처리 전략을 동시 적용.

해결

이중 캐시(Dual Cache) 아키텍처: L1(Caffeine, 5분) + L2(Redis, 1시간) 조합으로 구성해, 동일 위치 조회 시 API 호출을 막고 인스턴스 간 데이터 정합성 유지. 트래픽 제어 및 병렬 처리: Bucket4j로 분당 토큰 소비를 제어하고, CompletableFuture와 스레드 풀을 활용해 허용된 한도 내에서 점수 계산 로직을 병렬로 수행.

결과

추천 API 100회 호출 기준 응답 시간 19초 → 4초 (78% 단축). API 한도 초과 상황에서도 메인 서비스가 중단되지 않는 견고한 아키텍처 확보.

[인프라 자동화 및 보안 격리 주도]

Terraform으로 AWS(EC2, RDS, ElastiCache) IaC 구축. RDS·Redis는 EC2에서만 접근 가능하도록 보안 그룹을 제한해 공개망으로부터 DB·캐시 격리.

EZCODE

AI 코드 리뷰와 캐릭터 성장 시스템을 포함한 코딩 테스트 서비스

개요
코딩 테스트 문제별 커뮤니티와 실시간 알림 시스템을 포함한 웹 서비스 개발 (6인 팀 프로젝트)
주요 역할
커뮤니티 및 알림 도메인의 백엔드를 전담하여, 쿼리 튜닝을 통한 조회 성능 개선 및 MQ 기반 실시간 알림 시스템 구축을 주도함.

핵심 성과

[트러블슈팅 1] 다중 집계 쿼리 최적화 및 N+1 문제 원천 차단
문제

토론글 목록 페이징 조회 시 다수의 집계/조인이 발생해 실행 계획이 비효율적이었음. 특히 IN 절 조회 시 기존 정렬(베스트/추천순)이 깨지고 N+1 문제가 동반됨.

접근

페이징을 위한 식별자(ID) 조회와 상세 데이터 조회의 책임을 2단계로 분리하고, 애플리케이션 메모리 단에서 정렬 재배치 수행.

해결

QueryDSL 쿼리 분리: 정렬 및 페이징 조건이 적용된 ‘ID 목록’을 선행 조회한 후, 해당 ID로 ‘상세 집계 데이터’를 JOIN과 GROUP BY로 한 번에 조회. 메모리 재정렬: 조회된 데이터(Map 구조)를 처음 추출했던 ID 순서에 맞춰 애플리케이션 단에서 안전하게 매핑 및 재배치.

결과

복잡한 쿼리 실행 계획을 단순화하여 N+1 문제 해결. API 응답 속도 314ms → 134ms (57% 향상) 달성.

[트러블슈팅 2] 알림 파이프라인 연쇄 장애 방지 및 내구성 확보
문제

Spring Event 기반 알림은 서버 다운 시 메시지 유실 위험이 있고, 알림 DB(MongoDB) 장애 시 메인 비즈니스(게시글 작성 등)까지 롤백되는 연쇄 장애 가능성 존재.

접근

메인 비즈니스와 알림 처리 간 결합도를 낮추고, 서킷 브레이커를 통한 장애 물리적 격리(Isolation) 적용.

해결

MQ 전환 및 트랜잭션 분리: ActiveMQ로 이벤트 비동기 발행. 알림 트랜잭션을 REQUIRES_NEW로 분리해 실패 시에도 메인 로직은 커밋되도록 결합도 차단. 서킷 브레이커 및 재처리: Resilience4j로 DB 장애 시 Fast-Fail 유도. 실패 내역은 별도 로그로 남기고 스케줄러로 큐에 재발행하는 멱등 보장 로직 구현.

결과

알림 DB 장애나 트래픽 폭주 시에도 메인 서비스 로직이 영향을 받지 않는 고가용성 메시징 파이프라인 완성. (관련 블로그 글)

[문제 해결 주도 및 협업]

프론트엔드 연동 예외(JSON 파싱 등)·Git 머지 충돌 시 코드 리뷰·원인 분석 회의를 주도해 통합 일정을 맞춤.

EZCODE 시스템 아키텍처

스케일 아웃 기반 인프라

  • Amazon ELB + Auto Scaling Group 구성
  • 트래픽 급증 시 EC2 인스턴스를 자동으로 증설

채점 서버 분리 (AWS Lightsail 배치)

  • 메인 백엔드와 네트워크·자원 면에서 완전히 분리하여, 채점 부하나 장애가 전체 서비스에 영향을 주지 않도록 설계

네트워크 분리를 통한 보안 강화

  • 외부 사용자의 직접적인 접근이 필요한 Frontend 서버는 Public Subnet에 배치
  • Backend 서버와 데이터베이스는 Private Subnet에 배치