문제를 발견하면 기준을 세우고, 작동하는 결과로 완성합니다.
한 번의 해결에 머물지 않고, 다음 개선의 단서까지 남깁니다.
역할과 진행 상황을 투명하게 공유하며 함께 답을 찾습니다.
기능이 아닌 고객의 다음 행동까지 생각해 경험을 설계합니다.
Java
Spring Boot
Spring Security
Redis
SQL
React
TypeScript
01
SCROLL02
개발의 흐름
2021.03–2025.08
경영정보학과 · 융합소프트웨어
2022.03–2022.12
HTML · CSS · 자바스크립트 웹 프로젝트
2023.01–2023.02
인공지능 기초 다지기 · 6주 코칭스터디 수료
2023.03–2023.12
신입생 대상 프로그래밍 스터디 기획 및 운영
2023.03–2024.02
앱 개발 프로젝트 · 팀 협업
2024.09–2025.02
영국 교환학생 · 최우수 성적
2025.03–2025.06
개발자 커뮤니케이션
2025.07–2026.06
자바 · 스프링 기반 백엔드 개발
2026.08
금융 실무 교육 · 현직자 멘토링
쌓아온 경험을,
에이피알에서 이어가겠습니다.
03
Selected work
서비스의 핵심 흐름과 제가 맡은 범위를 간략히 정리했습니다.
필요한 보장을 고르고 월 단위로 구독하는 보험 시뮬레이터
기술 스택
팀 구성
5명BE 3, FE 1, INFRA 1담당 범위
성향 퀴즈와 얼굴 인증으로 시작하는 온라인 로테이션 미팅
기술 스택
팀 구성
6명FE 1, BE 3, AI 1, INFRA 1담당 범위
크롬 확장 프로그램으로 저장한 자료를 다시 찾고 정리하는 서비스
기술 스택
팀 구성
7명FE 1, BE 3, AI 2, INFRA 1담당 범위
얼굴·음성·설문으로 뇌졸중 위험 신호를 확인하는 모바일 앱
기술 스택
팀 구성
4명FE 1, BE 1, AI 2담당 범위
구독형 보험 프로세스 시뮬레이터
CapSure월 단위로 보험을 구성하고 구독하는 서비스입니다. 납입, 청구, 지급, 계약 유지가 한 흐름으로 이어지도록 설계했습니다.
Java 21
Spring Boot 3.5.11
PostgreSQL
React 19CapSure / PROBLEM 01결제 복구 · 멱등성외부 승인과 내부 저장을 구분하고, 같은 주문의 결과를 확인해 계약까지 복구했습니다.
PG에서는 이미 승인된 주문
승인 결과 존재증권 저장 예외 → HTTP 500
APPROVING · 증권 0건새 승인이 아닌 기존 주문 대사
PAID / ACTIVE · 증권 1건PG 승인 직후 증권 저장에 예외를 주입하자 HTTP 500이 반환됐습니다. 하지만 이미 끝난 외부 승인은 DB 롤백으로 취소되지 않았습니다.
오류 응답을 결제 실패로 단정하지 않고, 새 승인보다 기존 거래 확인을 우선했습니다.
승인 후 내부 실패는 APPROVING으로 유지합니다. 같은 주문을 조회·대사해 결제 상태, 계약 활성화, 증권과 Outbox를 함께 복구합니다.
2026-09-13 PaymentPolicyIntegrationTest 10건 통과. 예외 직후 APPROVING / PENDING_INITIAL_PREMIUM / 증권 0건, 대사 후 PAID / ACTIVE / 증권 1건을 확인했습니다. 별도 동일 confirm 100회 시험에서도 외부 승인 호출·결제 시도·증권·활성화 이벤트는 각각 1회/1건이었습니다. 승인 여부를 모르는 timeout은 UNKNOWN으로 따로 처리합니다.
CapSure / PROBLEM 02계약 효력 · 시간 경계입금 기록과 계약 효력을 분리하고, 수납 순간에도 같은 만료 규칙을 적용했습니다.
모든 미납 회차 해소
ACTIVE계약 활성 상태수납 직전 만료 기준 재확인
LAPSED입금 기록 + 지연 검토 1건같은 실효 후 출금 결과를 2번 반영한 별도 시험에서도 수납·검토는 각각 1건.
유예 종료 다음 날, 실효 배치보다 입금이 먼저 도착하면 DB에는 아직 GRACE가 남습니다. 이 값만 보면 지난 계약이 다시 활성화될 수 있습니다.
“돈이 들어왔다”와 “보장이 유효하다”를 같은 조건으로 처리하지 않았습니다.
수납 전에 계약을 잠그고 beforeSettlement로 만료 여부를 다시 판단합니다. 실효 후 입금은 수납 기록과 지연 검토로 남기고 자동 활성화하지 않습니다.
2026-09-13 미납 통합 테스트 18건 통과. 합성 상품의 유예 종료 기준과 시험 시계를 사용했습니다. 이미 실효된 계약에 같은 UNKNOWN 출금 결과를 두 번 반영해도 수납·지연 검토는 각각 1건이었습니다.
얼굴 인증과 마스킹 기반 미팅
Roundy성향 퀴즈로 상대를 만나고, 실루엣으로 먼저 대화합니다. 서로 선택하면 시간이 흐를수록 마스킹이 풀리며 얼굴을 확인합니다.
Java 21Spring Boot 3.5.9
Redis와 LuaReact 19
TypeScript 5.9Roundy / PROBLEM 01동시 요청 · 상태 정합성입장을 원자화하는 것만으로는 부족했습니다. 정리할 때도 현재 방과 대상 방을 비교했습니다.
인증 소비 → 큐 등록 → 방 배정은 하나의 Lua 실행으로. 정리에는 roomId 비교 조건을 추가했습니다.
매칭 뒤 늦은 poll이 사용자를 다시 대기열에 넣고, 이전 방의 정리 요청이 새 currentRoom을 삭제하는 순서 문제를 재현했습니다.
입장 과정은 한 번에 처리하되, 삭제에는 “지금도 그 방인가?”라는 조건이 별도로 필요했습니다.
Redis Lua로 인증 소비·큐 등록·방 배정을 묶었습니다. cleanup-room.lua는 현재 매핑이 정리 대상 roomId와 같을 때만 삭제합니다.
기존 → 원자적 입장만 적용 → 조건부 정리까지 적용한 세 버전을 비교했습니다. 재큐잉은 100/100 → 0/100 → 0/100, 새 배정 유실은 100/100 → 100/100 → 0/100이었습니다. 격리 Redis와 모의 JWT·DB를 사용해 Controller 수준에서 요청 순서를 제어한 시험입니다.
Roundy / PROBLEM 02인증 결과 · 소유권과 일회성성공 여부뿐 아니라 소유자·요청·상태를 묶고, 인증 결과 소비를 원자적으로 처리했습니다.
성공 여부만 검사하면 타인의 요청이나 겹친 요청이 같은 결과를 사용할 위험이 있습니다. 소비 후 늦은 완료 응답이 결과를 되살리는 조건도 점검했습니다.
PENDING은 소비하지 않고, VERIFIED만 한 번 사용하도록 제한했습니다.
verify:{userId}:{requestId}에 결과를 귀속시켰습니다. 완료는 PENDING에서만, 소비는 VERIFIED에서만 허용하는 Lua 전이로 재사용을 막았습니다.
VerificationRedisTest 6건 통과. 실제 Redis와 모의 DB 조건에서 소유자의 최초 소비 성공, 타인·재소비 실패, 소비 뒤 늦은 완료 결과의 재생성 차단을 확인했습니다. 8개 워커에 제출한 16개 소비 요청 중 1개만 성공했습니다.
흩어진 자료가 하나의 지식 나무로
저장한 지식을 오늘의 TIL로
쌓인 기록을 마이페이지에서
크롬 확장 프로그램 기반 지식 관리
SAN크롬 확장 프로그램으로 저장한 자료를 검색, TIL, 지식 카드로 연결하는 서비스입니다. AI 정리 기능도 원문 근거를 남긴 상태에서 검토할 수 있도록 설계했습니다.
Java 21Spring Boot 3.5.14Spring Data JPAPostgreSQLRedisReact 18.3TypeScript 5.9SAN / PROBLEM 01검색 성능 · 조회 범위브라우저의 전체 목록 필터를 서버 검색으로 옮기고, 태그 집계와 정렬 기준을 정리했습니다.
전체 다운로드 대신 필요한 페이지를 반환합니다.
카드가 늘수록 전체 목록 전송·파싱·브라우저 필터 비용이 함께 커졌습니다. 검색을 서버로 옮겨도 태그 집계 경로를 함께 점검해야 했습니다.
응답 속도뿐 아니라 소유자 격리, 검색 조건, 페이지 순서도 유지하는 기준을 잡았습니다.
카드 ID별 태그를 집계하고 HAVING COUNT(DISTINCT tag)로 조건을 적용했습니다. createdAt과 cardId를 함께 정렬해 페이지 순서를 고정했습니다.
개발 브랜치에서 HTTP 수신·JSON 파싱·기준선 클라이언트 필터를 포함해 측정했습니다. 최신 50건 p95는 128.15 → 28.50ms, 응답은 5,085,664 → 26,903B입니다. 작은 100건 조건에서는 최신 조회가 18.97 → 23.67ms로 느려져 데이터 규모에 따른 차이도 확인했습니다.
SAN / PROBLEM 02ASYNC AI · SOURCE SNAPSHOT생성 요청 시 원문과 AI 전달문을 고정해, 비동기 작업이 나중의 수정본을 읽지 않도록 했습니다.
카드·스크랩 ID
제목 · 원문 · URL · AI 입력
DailySummary에 보존
저장된 aiInput 사용
현재 카드 재조회 없음
요청과 AI 실행 사이에 원문을 수정하면, 생성에 쓴 내용과 나중에 확인하는 근거가 달라질 수 있습니다.
항상 최신 내용을 읽는 대신 “이번 생성에 무엇을 전달했는가”를 재현할 수 있게 했습니다.
captureSnapshots에 카드·스크랩 ID, 제목, 원문, URL과 AI 입력을 저장합니다. toAiContents는 현재 카드가 아니라 저장된 스냅샷으로 AI 요청을 구성합니다.
TilSourceService와 TilSourceServiceTest에서 원문·정제 입력 보존과 저장된 입력 반환 로직을 확인했습니다. 검증 범위는 코드와 테스트 검증문 확인이며, SRC 식별자로 생성에 사용한 입력을 연결합니다.
AI 기반 뇌졸중 위험 신호 확인 앱
다시봄얼굴·음성·설문으로 뇌졸중 위험 신호를 확인하고, 결과와 병원 탐색으로 이어지는 모바일 앱입니다.
React NativeSpring Boot다시봄 / PROBLEM 01민감한 입력 · AI 응답 검증프로젝트에서 원본 업로드 경로를 제거하고, 입력과 AI 응답을 각각 검사하는 경계를 검증했습니다.
영상 ≤ 50MB / 음성 ≤ 20MB
형식·용량 검사요청 메모리에서 원본 전달
판정값·확률 검사서비스 저장소에 원본 업로드 안 함
허용된 응답만 저장기존 진단 경로는 AI 호출 전 얼굴·음성 파일을 S3에 올렸습니다. 분석 뒤에도 원본을 보관해야 하는 이유는 확인되지 않았습니다.
원본은 분석에 전달하되 서비스 저장소에는 남기지 않고, 허용 범위의 판정값·확률만 기록하는 기준입니다.
S3 업로드 의존을 제거했습니다. 형식·용량은 AI 호출 전에, 판정값 0/1과 유한한 확률 0~1은 저장 전에 검사합니다. 외부 오류는 일반화된 코드로 반환합니다.
2026-09-19 백엔드 테스트를 강제 재실행해 5개 클래스의 11건이 실패·오류·스킵 없이 통과했습니다. 영상 mp4/mov 최대 50MB, 음성 wav/pcm/m4a 최대 20MB, 전체 multipart 요청 75MB 기준으로 검사합니다. 검증 대상은 서비스의 입력·응답 처리와 저장 경로입니다.
다시봄 / PROBLEM 02기록 조회 · 소유권 검사진단 ID만 찾던 조회를 사용자 ID까지 함께 확인하도록 바꾸고, 타인 요청의 차단 범위를 검증했습니다.
결과와 연관 정보로 연결
연관 병원 조회도 중단
진단 ID만 조회하면 요청자와 기록 소유자가 연결되지 않습니다. 다른 사람의 ID를 아는 요청이 상세 기록으로 이어질 여지가 있었습니다.
기록의 존재 여부보다 소유권을 먼저 확인합니다. 일치하지 않으면 연관 병원 정보 조회도 진행하지 않습니다.
인증 사용자 ID를 컨트롤러에서 서비스로 전달합니다. findByIdAndUserId로 기록을 조회하고, 일치하지 않으면 DIAGNOSIS_NOT_FOUND로 처리합니다.
DiagnosisQueryServiceTest에서 타인 진단 ID 요청의 404 응답과 병원 저장소 미호출을 확인했습니다. DiagnosisControllerTest에서는 인증 사용자 ID가 서비스로 전달되는지 검사했습니다. 서비스·컨트롤러 단위의 검증입니다.
AI 분석 API
MySQL