회원 인증·세션 — 정적 웹과 API를 한 애플리케이션이 같이 내보내는 구조라 토큰 대신 세션을 택했습니다. 콘서트 등록처럼 되돌리기 어려운 작업은 관리자 권한으로 갈랐습니다.
Redis 대기열 — 등록과 순번 조회, 입장 허용을 한 흐름으로 묶었습니다. 조건은 하나였습니다. 순번을 몇 번 다시 조회하든 자기 자리를 잃지 않을 것. 나머지는 여기에 맞췄습니다.
좌석 선점 락 고도화 — 만료된 선점을 스케줄러가 주기마다 훑어 푸는 방식이었는데, 그러면 나중에 잡은 좌석까지 같은 주기에 끌려 나갑니다. 좌석마다 독립된 TTL을 주는 쪽을 택해 해제 스케줄러를 없앴습니다. 대신 결제 직전에 락의 소유자를 다시 확인합니다. 화면에 남은 시간이 보여도 서버 기준으로는 이미 만료됐을 수 있다고 봤습니다.
마이페이지와 화면 — 예매 내역·포인트 조회와 공연 시작 전 환불을 맡았습니다. 남의 예매가 열리면 안 되니 조회 조건에 예매 ID와 회원 ID를 함께 걸었습니다. 화면도 직접 붙여 흩어져 있던 페이지를 main.html 중심 SPA로 모았습니다.
대기열: 재요청해도 순번이 유지되도록 시나리오
상황
예매 오픈 직후 접속이 예매 화면으로 그대로 들어오면, 좌석 조회와 선점 요청이 한꺼번에 DB로 내려갑니다.
원인
입장 인원을 제어하는 장치가 없었고 사용자가 순번을 다시 조회할 때마다 대기열에 재등록되어 순번이 뒤로 밀렸습니다.
조치
queue:wait:concert:{concertId} Sorted Set에 진입 시각을 score로 저장하고 순번은 ZRANK로 조회했습니다.
이미 등록된 사용자는 다시 넣지 않으므로 재요청해도 같은 순번을 유지합니다.
1초 주기 스케줄러가 콘서트별 활성 인원을 확인해 최대 50명까지 입장을 허용하고
입장자는 queue:active:concert:{concertId} Set으로 옮겨 5분 TTL을 부여했습니다.
결과
예매 화면에 동시에 들어오는 인원이 50명으로 고정되고 결제 완료·이탈 시 즉시 자리를 회수하도록 정리했습니다.
남은 과제
k6 스크립트(가상 사용자 10명 / 100초)로 중복 요청 응답 코드까지만 확인했습니다. 결과 파일을 남기지 않아 처리량·지연 개선 수치는 제시하지 않습니다.
입장 허용 인원 50명도 서버 여력을 측정해서 정한 값이 아니라 시나리오상 정한 값입니다.
인증 주체가 둘로 늘어나며 생긴 NPE 시나리오
상황
제가 세션 기반 로그인을 올린 뒤, 팀원이 Kakao OAuth2 로그인을 추가했습니다. 그 직후 제가 만든 마이페이지 API들에서 NPE가 발생했습니다.
원인
로그인 경로가 두 개로 갈라지면서 인증 주체의 형태가 달라졌는데, 기존 API는 한쪽 형태만 가정하고 인증 정보를 꺼냈습니다.
조치
인증 정보를 꺼내는 지점을 한 곳으로 모아, 어느 경로로 로그인했는지와 무관하게 회원을 식별하도록 바꿨습니다. 콘서트 등록·포스터 업로드는 관리자 권한으로 제한했습니다.
결과
두 로그인 경로가 같은 API를 공유할 수 있게 되었습니다.
2026.07 · 실시간 모의투자TOCKTALKS
같은 시드머니로 방을 만들어 정해진 시간 동안 수익률을 겨루고 인증된 투자 카드를 커뮤니티에 공유하는 서비스입니다. 실시간 주가는 KIS Open API에서 받아옵니다.
기간
2026.07.16 ~ 2026.07.27 (2주)
팀
5명 (백엔드)
내 역할
Auth, Room, Ranking, 시세 연동 — 인증 전 구간, 방 생명주기, 실시간 랭킹, KIS 호출 성능 (커밋 139건, 최다)
스택
Java 21 · Spring Boot 4.1 · Spring Security · JWT · Redis · MySQL · WebSocket/STOMP
인증 전 구간 — 자체 로그인(BCrypt)과 Kakao OAuth2, Access·Refresh 토큰의 발급부터 폐기, WebSocket 연결 시점 검증까지 맡았습니다. 앞선 프로젝트에서 로그인 경로가 둘로 갈라지며 API가 깨진 일이 있어 인증 주체를 꺼내는 통로를 처음부터 하나로 두고 시작했습니다.
방 생명주기 — 참가와 탈퇴를 언제까지 허용할지가 문제였습니다. 모집 중에만 열어두고 시작된 방은 나가면 그 시점 순위가 그대로 기록되며 재입장을 막는 쪽으로 정했습니다. 중간에 빠져나가 손실을 지우는 길을 남기지 않으려는 것이었습니다.
실시간 랭킹 — 랭킹 계산을 Redis로 옮겼습니다. 끝난 방의 순위까지 실시간 경로에 두면 계속 쌓이기만 합니다. 방이 끝나면 최종 순위를 아카이브에 따로 남기는 쪽으로 갈랐습니다.
KIS 시세 연동 성능 — 보유종목 시세를 배치 조회로 바꾸고 다중 시세 캐시를 MGET·파이프라인으로 전환했습니다. 호출 제한은 Redis 분산 조율까지 갔다가 실익보다 복잡도가 크다고 보고 로컬 페이싱으로 되돌렸습니다.
장애 격리 — 외부 API와 캐시에 기대는 서비스라 그쪽이 흔들릴 때를 기준으로 잡았습니다. 시세 조회가 실패하면 마지막 성공 응답을 내주고 Redis·DB가 잠깐 죽어도 서비스 전체가 같이 멈추지는 않게 막았습니다. 틀린 값을 잠깐 보여주는 쪽이 아무것도 못 보는 쪽보다 낫다고 판단했습니다.
Refresh 토큰을 1회용으로 회전시키고 재사용을 탈취 신호로 처리 시나리오
상황
Access 토큰은 만료되면 재발급해야 합니다. 그런데 Refresh 토큰을 유효기간 내내 그대로 쓰면, 한 번 유출된 토큰이 14일 동안 살아 있습니다.
조치
Access는 1시간, Refresh는 14일로 두고 Refresh를 Redis에 저장했습니다.
재발급 때마다 Refresh를 1회용으로 회전시키고 이미 회전된 토큰이 다시 들어오면
해당 계정의 토큰을 모두 선제적으로 무효화하도록 했습니다.
결과
탈취가 의심되는 상황을 "이미 쓴 토큰이 또 들어왔다"는 시점에 잡아 차단합니다. 로그아웃·회원 탈퇴 시에도 즉시 전체 폐기합니다.
남은 과제
정상 사용자가 네트워크 재시도로 같은 Refresh를 두 번 보내면 전체 무효화로 이어질 수 있습니다. 재시도와 실제 탈취를 구분하는 유예 처리는 넣지 못했습니다.
로그인 실패 잠금과, Redis가 죽어도 로그인은 막히지 않게 시나리오
상황
비밀번호 대입 시도를 막아야 하지만 잠금 카운터를 서버 메모리에 두면 재시작 때 초기화되고 인스턴스마다 값이 갈립니다.
조치
실패 횟수를 Redis 공용 카운터로 관리해 5회 실패 시 5분 잠금을 적용했습니다. 동시에 인증 검사에는 fail-open을 적용해, Redis 장애 시 잠금 검사를 건너뛰고 로그인 자체는 되도록 했습니다.
결과
인스턴스 재시작에도 잠금 상태가 유지되고 캐시 장애가 로그인 전면 차단으로 번지지 않습니다.
남은 과제
fail-open은 가용성을 택한 대신 장애 중에는 대입 방어가 열립니다. 어느 쪽을 택할지는 서비스 성격에 따라 다시 판단해야 한다고 봅니다.
JWT 시크릿 기본값 제거 측정됨
상황
개발 편의로 넣어둔 JWT 시크릿 기본값이 설정에 남아 있었습니다. 환경변수를 안 넣어도 서버가 떠버리는 상태였습니다.
조치
기본값을 제거하고 JWT_SECRET 환경변수를 필수로 바꿔, 값이 없으면 서버 부팅이 실패하도록 했습니다.
결과
플레이스홀더 시크릿이 그대로 배포될 경로를 막았습니다. 설정 누락은 런타임이 아니라 부팅 시점에 드러납니다.
방 참여 경합: 락을 잡고 나서 다시 검사 시나리오
상황
정원이 찬 방이나 이미 시작된 방에 여러 사용자가 동시에 참여 요청을 보내면, 검사와 반영 사이에 상태가 바뀔 수 있습니다.
조치
방 상태 변경 구간에 비관적 락을 적용하고 락을 획득한 뒤 참여 조건을 다시 검사했습니다.
결과
락을 기다린 요청은 바뀐 상태를 보고 판단하므로, 정원을 넘겨 참여하는 경로가 막혔습니다.
남은 과제
방 단위 락이라 같은 방의 참여 요청은 직렬화됩니다. 대규모 인원을 받는 방이 생기면 참여 큐 분리를 고민해야 합니다.
2026.08 · 선착순 쿠폰Mealiver-IT
배달앱의 매일 오전 11시 선착순 쿠폰 발급을 가정한 시스템입니다. 재고 1만 개에 동시 요청 2만 건이 들어와도 초과 발급 0과 1인 1매를 지키는 것이 목표였습니다.
기간
2026.08.06 ~ 2026.08.31 (약 4주)
팀
6명
내 역할
설계 문서 관리, 정합성 검증, 데이터 파이프라인, 등급 배치
스택
Java 21 · Spring Boot · MySQL 8.0 · Flyway · JDBC 배치 · Docker
설계 문서 관리 — 초과 발급을 막는 전략이 회의와 멘토링을 거치며 계속 바뀌었습니다. 그때마다 결정과 그 이유를 아키텍처 문서와 버전 사다리 문서에 반영해 팀이 같은 기준을 보게 했습니다.
시더와 대량 적재 — 발급 조건이 등급과 주문 이력에 걸려 있어 회원만 만들어서는 조건 분기를 태울 수 없었습니다. 의존성 순서대로 채우는 5단계 시더를 만들었습니다. 수백만 건을 넣다 끊기면 처음부터 다시 돌려야 하니 재개 기능을 먼저 넣었습니다. 적재는 청크 단위로 끊고 JDBC 배치 옵션으로 왕복을 줄였습니다.
정합성 검증 체계 — 초과 발급·중복 발급을 잡는 검증 SQL 6종을 만들었습니다. 그런데 위반이 없는 데이터에서는 쿼리가 통과해도 아무것도 증명하지 못합니다. 일부러 틀린 데이터를 넣고 지우는 API를 붙여 검증 쿼리 자체를 먼저 검증했습니다.
등급 산정 배치 — 주문 이력으로 회원 등급을 매기는 배치 잡을 구현했고 한 건씩 UPDATE하던 것을 CASE WHEN 청크 방식으로 바꿨습니다.
제 작업의 목표는 팀 전원이 같은 규모·같은 분포의 데이터 위에서 검증하게 만드는 것이었습니다. 부하 테스트 실행 자체는 다른 팀원이 맡았고 제가 만든 데이터셋과 검증 쿼리 위에서 돌아갔습니다.
전략이 하루에도 두 번 바뀌는 동안 문서를 따라가게 했습니다
상황
6인이 2주를 쓰는 프로젝트였고 초과 발급을 막는 전략이 회의와 멘토링마다 바뀌었습니다. 버전 사다리가 V1~V4에서 V1~V3으로 줄었다가 같은 날 저녁에 다시 V4가 붙은 적도 있습니다.
원인
결정은 회의에서 나는데 그 결정이 문서에 안 들어가면 각자 다른 시점의 요구사항을 보고 만들게 됩니다. 이미 접은 설계를 누가 계속 붙잡고 있어도 아무도 모릅니다.
조치
회의와 멘토링에서 나온 결정을 그날 아키텍처 문서와 버전 사다리 문서에 반영했습니다.
바꾼 내용만 적지 않고 날짜와 함께 왜 바꿨는지를 남겼습니다.
접은 설계도 지우지 않고 git 이력에 남겨, 나중에 "왜 그건 안 썼냐"는 질문에 답할 수 있게 뒀습니다.
결과
팀이 한 문서를 보고 움직였습니다. 구현 담당자가 그 문서만 읽어도 각 버전이 무엇을 증명해야 하는지 알 수 있는 상태를 유지하는 것이 목표였습니다.
내 범위
설계 자체는 팀 회의와 멘토링에서 나온 결과입니다. 저는 그것을 종합해 문서로 유지했습니다. 재고 샤딩 구현과 부하 테스트 실행은 다른 팀원이 맡았습니다.
부하 테스트가 의미를 가지려면 데이터가 먼저 있어야 했습니다 측정됨
상황
초과 발급과 중복 발급은 데이터가 쌓인 상태에서만 드러납니다. 빈 테이블에 요청을 쏘면 인덱스도 락 경합도 실제와 다르게 동작합니다.
원인
등급·주문 이력에 의존하는 발급 조건이 있어, 회원만 만들어서는 조건 분기를 태울 수 없었습니다.
조치
회원 → 주문 → 등급 → 캠페인 → 발급 이력 순서로 의존성을 따라가는 5단계 시더 체인을 만들었습니다.
전체를 한 트랜잭션에 담지 않고 청크 단위 배치 인서트로 끊었습니다.
네트워크 왕복은 rewriteBatchedStatements=true로 줄였습니다.
결과
가상 회원 100만, 주문 1,000만, 발급 이력 약 300만 건의 데이터셋을 구성해,
팀원 전원이 같은 규모·같은 분포 위에서 검증을 돌릴 수 있게 했습니다.
남은 과제
시더 실행 시간을 단계별로 기록해두지 않아 배치 옵션이 얼마나 기여했는지는 수치로 말할 수 없습니다. 다음에는 단계별 소요 시간부터 남기겠습니다.
이 데이터로 팀이 확인한 것 측정됨
범위
아래 부하 테스트는 팀원(부하 테스트 담당)이 수행했고 제가 만든 데이터셋 위에서 돌아갔습니다.
결과
재고 100개에 동시 요청 50건 리허설에서 초과 발급 0, 요청 50건 모두 정상 발급.
동일 Idempotency-Key로 같은 요청을 100회 보냈을 때 신규 발급 1건 + 이미 처리됨 99건.
남은 과제
2만 유저 스케일 테스트는 로컬 TCP 소켓 한계로 재실행 대기 상태입니다. 목표 수치(2만 동시 요청)는 아직 달성 기록이 아니라 시나리오입니다.
2024.03 – 06 · 세종대 캡스톤AI-BASED-ETA
한국도로교통공사 공공데이터의 VDS 데이터로 학습한 모델을 써서, 출발 시각에 따라 달라지는 도착 시간과 최단 시간 경로를 계산하는 서비스입니다.
GCP 서버 구축·배포 — 학습 환경은 Python 3.6인데 Ubuntu 20.04 기본은 3.8이라 모델 로딩부터 실패했습니다. 버전을 맞추고 공용 디렉터리와 가상환경 권한을 정리해 네 명이 같은 경로에서 같은 모델을 돌리게 했습니다.
모델 연동 — 경로 요청이 들어오면 모델 추론을 호출해 속도 시간표를 받습니다. 그 값으로 경로를 계산해 돌려주는 흐름까지 붙였습니다.
카카오맵 화면 — 출발지·도착지 자동완성, 경로 그리기, 마커 토글, 로딩 상태를 만들었습니다. 여기에 카카오모빌리티 미래운행 길찾기로 같은 구간을 조회해 겹쳐 그리는 화면을 넣어 저희 예측과 상용 서비스를 나란히 비교할 수 있게 했습니다.
동적 가중치 A* — 팀이 매일 모여 회의하며 함께 설계했고 저는 그 논의에 참여했습니다. 제가 코드를 전부 쓴 것은 아니지만 왜 그렇게 정했는지는 지금도 설명할 수 있습니다.
모델이 60분까지만 예측하는데, 경로는 4시간이었습니다 측정됨
상황
서울→부산처럼 긴 경로는 이동 중에 도로 상황이 바뀝니다. 출발 시각의 속도로 끝까지 계산하면 뒤쪽 구간이 전부 틀어집니다.
원인
사용한 Graph WaveNet은 5분 간격 12스텝, 60분까지만 예측합니다. 그 뒤 구간의 속도는 아예 데이터가 없었습니다.
조치
경로를 따라가며 누적 시각을 계산하고 누적 시각이 마지막 예측 요청 시점으로부터 1시간 5분을 넘어가면
그 시점을 기준으로 속도 예측을 다시 요청하는 Sliding Window 방식을 넣었습니다.
A*의 휴리스틱은 목적지까지의 위경도 유클리드 거리, 간선 비용은 그 시각의 예측 속도로 계산한 소요 시간(거리÷속도)입니다.
가중치가 고정된 그래프가 아니라, 탐색이 진행돼 시각이 흐르면 같은 간선의 비용도 달라지는 구조입니다.
예측 지평이 길어질수록 정확도가 떨어집니다. 교통 예측 모델의 공통 한계이고 저희도 해결하지 못했습니다. 검증은 같은 구간을 카카오모빌리티 미래운행 길찾기로 조회해 경로와 소요시간을 눈으로 비교하는 수준이었고 오차를 지표로 집계하지는 않았습니다.
협업 방식
Collaboration
인증 규칙 통합MINGPARK
제가 세션 로그인을 올린 뒤 팀원이 Kakao 로그인을 추가하면서 제 마이페이지 API들이 한꺼번에 깨졌습니다.
각 API를 고쳐 막을 수도 있었지만 인증 경로가 또 늘면 같은 일이 반복될 자리였습니다.
인증 정보를 꺼내는 지점을 한 곳으로 모아 두 로그인 경로가 같은 API를 쓰도록 정리했습니다.
다음 프로젝트인 TOCKTALKS에서는 이 통로를 처음부터 하나로 두고 시작했습니다.
AI 참조 규칙TOCKTALKS
코드베이스를 그래프로 만들어 두고 질문은 전체 리포트나 grep이 아니라 그래프에 먼저 던지도록
규칙을 적어 레포에 커밋했습니다. 팀원마다 각자 물어보면 참조 범위가 제각각이 되니
규칙 파일 자체를 공유물로 두는 쪽을 택했습니다. 넓게 훑어야 할 때만 전체 리포트를 보게
단계를 나눠, 한 번에 읽어 들이는 맥락의 크기를 줄였습니다.
남이 쓸 데이터MEALIVER-IT
제가 만든 더미 데이터셋 위에서 다른 팀원이 부하 테스트를 돌렸습니다.
그래서 제 작업의 완료 기준은 "내가 돌려봤다"가 아니라 "팀원 전원이 같은 규모·같은 분포로 재현할 수 있다"였습니다.
발급 조건이 등급과 주문 이력에 걸려 있어서 어느 단계까지 채워야 검증이 의미를 갖는지를 먼저 맞춰야 했습니다.
환경 통일AI-BASED-ETA
팀원마다 각자 환경을 만들다 보니 모델이 재현되지 않았습니다.
인스턴스의 Python을 학습 환경과 같은 버전으로 맞추고 공용 디렉터리와 가상환경 권한을 정리해,
네 명이 같은 경로에서 같은 모델을 돌리게 했습니다.
"내 로컬에서는 됩니다"가 사라진 것이 이 작업의 성과였습니다.
경력 · 학력 · 자격
Record
2026.04 – 10진행 중
[LG유플러스] 유레카 SW교육과정 4기부트캠프
백엔드 과정 (2026.04.06 ~ 2026.10.28). MINGPARK · TOCKTALKS · Mealiver-IT 세 개의 팀 프로젝트를 연속으로 수행했습니다.
2019.02 – 2026.02졸업
세종대학교 컴퓨터공학과
학점 3.68 / 4.5
2020.09 – 2025.043년 3개월
클라우드시큐리티 주식회사경영지원
헬프데스크 운영 관리 보조, 사내 지원 요청 대응
IT 유·무형 자산 관리와 전산 자산 내부 컴플라이언스 대응
신규 입사자 온보딩 지원, 공용 공간·비품 관리
2024 – 2026자격·어학
SQLD · 정보처리기사 · TOEIC
SQLD (SQL 개발자) · 2026.09 합격 · 한국데이터산업진흥원
정보처리기사 · 2025.06 · 한국산업인력공단
TOEIC 745 · 2024.11
2021.05입대 전
세종대학교 중앙동아리 인터페이스코딩 동아리
기장을 맡아 프로그래밍 전시회에 참여했고 비전공자·문과생을 위한 정기 스터디를 개설해 운영했습니다.
