제약이 있는 환경에서 운영 비용이 낮은 구조를 설계하는 데 관심이 많습니다.

학과 시스템도서위원회에서 4년간 학부생 1,400명이 쓰는 내부 서비스를 개발·운영하며,
좋은 기술을 먼저 고르기보다 주어진 제약에 맞는 실용적인 아키텍처를 설계했습니다.

기술 선택은 가능한 한 공개된 기록으로 남깁니다. 아래 프로젝트의 대안 비교와 의사결정 과정은
GitHub Discussions와 PR 리뷰에 그대로 남아 있습니다.

📬 wlgns12370@gmail.com

Backend   Java Spring Boot Spring Data JPA
Database   MySQL Redis
DevOps    Docker Kubernetes(K3s)
Infra   EC2 · RDS · S3

오프라인 배부 대기열의 온라인 전환 · 대상 1400명 · 2026.04 – | Java 21, Spring Boot, MySQL, Docker, k6

• 매 회 30~60분씩 줄을 서던 현장 배부를 모바일 선착순 신청으로 전환, 정원 100~150명에 약 400명이 경쟁하는 스파이크에서 초과 발급 0건
• SkipLocked, Redis cache, WAS cache 세 방식을 비교한 뒤 MySQL 원자적 UPDATE 채택
• 의사결정 근거를 얻기 위해 페르소나 기반 400명 인원에 대한 k6 부하 테스트 및 의사결정 (약 400 RPS, p95 474ms)
• 신청 자격 검증에서 외부 재정 서비스 의존성을 제거
  • 납부자 명단을 로컬 스냅샷으로 관리해, 신청이 집중되는 시간대에 외부 지연 및 장애가 신청 실패로 전파되지 않도록 격리
• 전체 정원의 10%를 배부 인력 전용 물량으로 자원 자체를 분리해, 일반 신청자가 예약분을 침범하는 코드 경로를 제거하고 물량 부족에 따른 추가 구매 0회

🔗 의사결정 기록
  · [디스커션1] 데이터 모델 및 동시성 전략 설계 과정 → MySQL 원자적 UPDATE 합의
  · [PR1] 관리자 수동 오픈 의존성 제거

베트남 다낭 FPT IS 과제 · 2026.07 – 2026.08 | Java 21, Spring Boot, MySQL, K3s, Stripe

• 30분 단위 타임 슬롯의 선점 기준을 슬롯 선택 시점으로 확정하고 신청·결제 API를 분리해, 결제 실패·재시도 중에도 예약 기회가 유실되지 않는 흐름 구현
• 신청과 Stripe 결제가 하나의 트랜잭션으로 묶이지 않는 구조에서, 만료 스케줄러와 사용자 취소가 동일 예약을 동시에 처리해 재고가 이중 복원되는 경쟁 상태를 발견하고 낙관적 락으로 제어
  • 충돌 빈도가 낮은 워크로드로 판단해 비관적 락 대신 낙관적 락을 선택 — 락 대기로 인한 처리량 저하를 피하는 것이 목적
• 동시성 제어에만 의존하지 않도록 재고 정합성 검사와 Discord 알림·복구 스크립트를 별도 운영 장치로 구성

🔗 의사결정 기록
  · [디스커션1]취소·만료 스케줄러가 동일 예약을 처리해 재고가 이중 복원되는 문제 -> 낙관적 락으로 해결
  · [디스커션2]좌석 선점 동시성 전략 —> Row Lock
  · [디스커션3]결제 API 통합 vs 분리 -> 분리 선택
  · [PR1]K3s 배포 및 환경별 매니페스트 구성

• 경북대학교 컴퓨터학부 · 전공 2021.03 – 2027.02 (졸업 예정)
• 정보처리산업기사 2022.08  ·  SQLD 2022.12