유승우 프로필

유승우

백엔드 개발

About

  • 수치 기반의 병목 개선: 병목은 기능 추가보다 수치와 로그로 먼저 확인합니다. 실제 배포 환경과 AWS 인프라를 함께 다루면서 굳어진 방식입니다.
  • 성능 및 아키텍처 최적화: '별볼일'에서는 Caffeine·Redis 이중 캐시로 추천 API 응답을 19초에서 4초까지, 78% 줄였습니다. 'EZCODE'에서는 QueryDSL 최적화로 조회 응답을 314ms → 134ms로 당겼고, ActiveMQ와 서킷 브레이커를 얹어 알림 DB에 장애가 나도 본 서비스는 멈추지 않도록 했습니다.
  • 안전한 인프라와 협업: Terraform으로 AWS 인프라를 코드화(IaC)하고, DB망을 공개망에서 분리했습니다. 막히는 지점이 생기면 코드 리뷰나 원인 분석 회의를 열어 재현 가능한 근거를 남겨 둡니다.
  • AI 활용 개발: AI에 맡길 범위와 직접 판단할 범위를 먼저 나눕니다. '별볼일' 프론트엔드가 그 사례로, 화면 명세와 API 계약을 직접 정의한 뒤 구현을 맡기고 동작을 하나씩 확인해 수정 반영했습니다. Vercel 배포까지 직접 처리했고, 실무에서는 n8n으로 업무 워크플로를 자동화한 경험이 있습니다.

기술 스택 및 역량

백엔드(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 — 메시징, 서킷 브레이커

AI 활용 개발(AI-Assisted Development)

  • Claude, Cursor — 명세 정의 후 구현 위임, 산출물 검증 및 수정 반영
  • n8n — 업무 워크플로 자동화

프로젝트

별볼일

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

기획 → 설계 → 백엔드 → 프론트엔드 → 인프라 → 배포까지 단독 수행

개요
위치 기반 별 관측 적합도 분석 및 추천을 제공하는 백엔드(개인 프로젝트)와 인프라 구축. 6주 안에 백엔드·인프라 검증에 집중하려고 프론트엔드는 화면 명세와 API 계약만 직접 정의한 뒤 구현을 생성형 AI에 위임. 산출물은 직접 써 보며 API 연동·에러 처리와 UX 동작을 점검해 수정 반영했고, 빌드·배포 설정을 다뤄 Vercel 배포까지 마무리.
주요 역할
실제 트래픽 규모를 가정해 외부 API 한도·수평 확장 관점에서 병목을 먼저 정의하고 해결.

핵심 성과

[트러블슈팅 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 기반 실시간 알림 시스템 구축을 주도. 프론트엔드 연동 예외(JSON 파싱)나 Git 머지 충돌이 생기면 직접 코드 리뷰·원인 분석 회의를 소집해 통합 일정을 확보.

핵심 성과

[트러블슈팅 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 장애나 트래픽 폭주 시에도 메인 서비스 로직은 정상 동작 (관련 블로그 글)

EZCODE 시스템 아키텍처

범례 — 다이어그램 내 담당 범위

  • 직접 구현 — Backend Server의 커뮤니티·알림 도메인, ActiveMQ 메시지 파이프라인·서킷 브레이커, Database 내 MongoDB 알림 저장

  • 팀 공동 / 타 팀원 담당 — Public/Private Subnet 분리 등 네트워크 구성, Compile Server(채점 서버), Monitoring(Prometheus·Grafana) 등

스케일 아웃 기반 인프라

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

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

  • 채점 부하·장애가 전체 서비스로 번지지 않도록 메인 백엔드와 네트워크·자원 분리

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

  • 외부 접근이 필요한 Frontend는 Public Subnet에, Backend·DB는 Private Subnet에 배치