유다현

개발자

Contact

이메일: lyra0720@naver.com
깃허브: github.com/dahynn

고객의 금융 여정을끝까지 따라가는 개발자

끝까지 확인하는 개발
오류를 고치는 데서 멈추지 않고, 고객에게 어떤 상태로 돌아가는지까지 확인합니다.
더 나은 방식을 찾는 개발
반복되는 문제는 임시로 덮기보다, 다음 사람이 이해할 수 있는 구조로 다시 풀어냅니다.
고객의 다음 행동을 생각하는 개발
기능 하나보다 고객이 서비스를 믿고 다음 단계로 갈 수 있는 경험을 만듭니다.

Tech Stack

Java

Spring Boot

Spring Security

Redis

SQL

React

TypeScript

SCROLL

개발의 흐름

개발자로서의 여정

2021.03–2025.08
동국대학교
경영정보학과 · 융합소프트웨어
2022.03–2022.12
멋쟁이사자처럼 10기
HTML · CSS · 자바스크립트 웹 프로젝트
2023.01–2023.02
부스트코스 코칭스터디 9기
인공지능 기초 다지기 · 6주 코칭스터디 수료
2023.03–2023.12
IT 소모임장 'ProMIS'
신입생 대상 프로그래밍 스터디 기획 및 운영
2023.03–2024.02
GDSC(Google Developer Student Clubs) 1기
앱 개발 프로젝트 · 팀 협업
2024.09–2025.02
University of Lancashire
영국 교환학생 · 최우수 성적
2025.03–2025.06
구름톤 유니브 4기
개발자 커뮤니케이션
2025.07–2026.06
삼성청년SW·AI 아카데미 14기
자바 · 스프링 기반 백엔드 개발
2025.08
한화금융캠퍼스 15기
금융 실무 교육 · 현직자 멘토링

쌓아온 경험을,
한화생명에서 이어가겠습니다.

Selected work

Project Store

프로젝트를 선택하면 아래에서 문제를 풀어낸 과정을 볼 수 있습니다.

CapSure
필요한 보장을 고르고 월 단위로 구독하는 보험 시뮬레이터
기술 스택
- Java 21
- Spring Boot
- PostgreSQL
- React
팀 구성
5명BE 3, FE 1, INFRA 1
담당 범위
- 상품 선택과 가입 흐름
- 결제 결과와 구독 확정
- 반응형 화면 구현
프로젝트 과정 보기
Roundy
성향 퀴즈와 얼굴 인증으로 시작하는 온라인 로테이션 미팅
기술 스택
- Java 21
- Spring Boot
- Redis
- React
팀 구성
팀 프로젝트매칭과 인증 기능 담당
담당 범위
- 성향 퀴즈 흐름 연결
- 얼굴 인증과 방 접근
- 마스킹 미팅 화면 구현
프로젝트 과정 보기
SAN
크롬 확장 프로그램으로 저장한 자료를 다시 찾고 정리하는 서비스
기술 스택
- Java 21
- Spring Boot
- PostgreSQL
- React
팀 구성
7명BE 3, FE 1
담당 범위
- 서버 검색 기능 구현
- AI 입력 보호 설계
- 작업 상태 관리
프로젝트 과정 보기

구독형 보험 프로세스 시뮬레이터

CapSure

01 / 03

결제와 계약의 상태를 끝까지 맞추다.

월 단위로 보험을 구성하고 구독하는 서비스입니다. 납입, 청구, 지급, 계약 유지가 한 흐름으로 이어지도록 설계했습니다.

Java 21
Spring Boot 3.5.11
MyBatis 3.0.5
PostgreSQL
React 19
Toss Payments SDK 2

팀 구성: 5명, 백엔드 3명, 프론트엔드 1명, 인프라 1명
담당 범위: FE Lead. 상품 선택, 결제, 구독 확정

Case 01

응답이 끊겨도 결제와 계약이 어긋나지 않게 만든 과정

문제 상황

승인 요청 뒤 통신이 끊기면 PG의 결제 결과를 알 수 없습니다. 실패로 간주해 다시 승인하면 중복 결제가 발생할 수 있었습니다.

제가 정한 기준

타임아웃을 UNKNOWN으로 보존하고 계약 활성화를 보류했습니다. 같은 멱등 키의 요청은 기존 결과를 반환하고, 외부 승인 호출을 반복하지 않습니다. PG 조회 결과를 주문·금액과 대조해 상태를 확정합니다. 행 잠금으로 대사 대상을 선점하고, Outbox에 후속 이벤트를 남겨 중단된 작업도 추적할 수 있게 했습니다.

Case 02

납입 실패 뒤에도 계약 상태를 섣불리 바꾸지 않았습니다.

01문제 확인

납입 실패, 독촉, 유예 종료를 한 상태로 처리하면 청구 가능 여부가 잘못 판단될 수 있었습니다.

02조건 분리

확정 미수, 독촉 성공, 유예 종료를 각각 확인하고 청구는 사고일의 보장 상태를 기준으로 판단했습니다. 실효 뒤 입금도 자동 부활시키지 않고 검토 대상으로 남겼습니다.

03검증 기록

합성 계약 45건에서 23번째 예외를 주입한 뒤 같은 실행을 재개해 누락과 중복 없이 마쳤습니다.

문제 상황

납입 실패, 독촉, 유예 종료를 한 상태로 처리하면 청구 가능 여부가 잘못 판단될 수 있었습니다.

제가 정한 기준

Case 03

AI의 답변은 지급 판단이 아닌 검토 초안으로 남겼습니다.

01문제 확인

AI가 만든 문장이 근거 없이 보험금 지급 판단으로 이어지면 안 된다고 봤습니다.

02조건 분리

청구별 약관 ID, 버전, 증빙 유형만 전달하고 응답의 근거 ID를 다시 검사했습니다. 결과는 담당자가 확인하는 초안으로만 남겼습니다.

03검증 기록

민감 형식 차단, 근거 혼입 검사, 담당자 검토 상태를 서비스 테스트로 확인했습니다.

문제 상황

AI가 만든 문장이 근거 없이 보험금 지급 판단으로 이어지면 안 된다고 봤습니다.

제가 정한 기준

청구별 약관 ID, 버전, 증빙 유형만 전달하고 응답의 근거 ID를 다시 검사했습니다. 결과는 담당자가 확인하는 초안으로만 남겼습니다.

프로젝트 목록으로 ↑

얼굴 인증과 마스킹 기반 미팅

Roundy

02 / 03

얼굴 인증으로 신뢰를 더한 온라인 로테이션 매칭 서비스.

성향 퀴즈로 상대를 만나고, 실루엣으로 먼저 대화합니다. 서로 선택하면 시간이 흐를수록 마스킹이 풀리며 얼굴을 확인합니다.

Java 21
Spring Boot 3.5.9
Redis와 Lua
MySQL
React 19
TypeScript 5.9
OpenVidu 2.32

팀 구성: 팀 프로젝트
담당 범위: 매칭, 인증, 방 접근 권한 보강

Case 01

늦은 요청이 와도 한 사람을 한 번만 매칭하게 만든 과정

01인증 결과

VERIFIED만 소비

02Redis · Lua

큐 선택·방 매핑 원자 처리

03방 정리

현재 roomId 비교

04매핑 보존

새 방 연결 유지

문제 상황

요청마다 큐 확인과 삭제, 방 저장을 따로 처리하면 늦은 poll이 사용자를 다시 등록할 수 있었습니다. 이전 방의 정리 작업이 새 방 매핑을 지우는 문제도 있었습니다.

제가 정한 기준

인증 소비·큐 등록·참가자 선택·방 매핑을 Redis Lua에서 원자적으로 처리했습니다. 여러 요청이 같은 중간 상태를 보고 서로 다른 결정을 내리지 않도록 묶었습니다. cleanup-room.lua는 사용자의 현재 roomId가 정리 대상과 같은지 검사한 뒤 삭제합니다. 새로운 방에 들어간 사용자의 매핑은 그대로 보존합니다.

Case 02

인증 결과는 본인만 한 번 쓰게 했습니다.

01문제 확인

같은 인증 결과가 여러 요청에서 재사용되거나 다른 사람에게 쓰이면 안 됐습니다.

02조건 분리

사용자 ID에 귀속된 키로 인증 결과를 저장하고 VERIFIED만 조건부로 소비했습니다. PENDING을 지우지 않아 타인 사용과 재사용을 제한했습니다.

03검증 기록

실제 Redis에서 동시 16회 소비 요청 중 1회만 성공하고 타인 소비는 거절되는 것을 확인했습니다.

문제 상황

같은 인증 결과가 여러 요청에서 재사용되거나 다른 사람에게 쓰이면 안 됐습니다.

제가 정한 기준

사용자 ID에 귀속된 키로 인증 결과를 저장하고 VERIFIED만 조건부로 소비했습니다. PENDING을 지우지 않아 타인 사용과 재사용을 제한했습니다.

Case 03

로그인 후에도 현재 방 권한을 다시 확인했습니다.

01문제 확인

로그인 여부만으로 이전 방이나 다른 사용자의 방에 접근할 수 있으면 안 됐습니다.

02조건 분리

JWT 확인 뒤에도 현재 roomId와 멤버 정보를 다시 검사해 조회, 입장, 영상 토큰 발급의 권한을 맞췄습니다.

03검증 기록

HTTP, WebSocket, OpenVidu mock 관련 29개 테스트로 권한 흐름을 확인했습니다.

문제 상황

로그인 여부만으로 이전 방이나 다른 사용자의 방에 접근할 수 있으면 안 됐습니다.

제가 정한 기준

JWT 확인 뒤에도 현재 roomId와 멤버 정보를 다시 검사해 조회, 입장, 영상 토큰 발급의 권한을 맞췄습니다.

프로젝트 목록으로 ↑

크롬 확장 프로그램 기반 지식 관리

SAN

03 / 03

빨리 찾고, 근거를 확인하며 다시 쓰다.

웹에서 찾은 자료를 크롬 확장 프로그램으로 저장하고 TIL과 지식 카드로 정리하는 프로젝트입니다. 검색 속도와 결과의 완결성, AI 입력 근거와 재시도 조건을 함께 다뤘습니다.

Java 21
Spring Boot 3.5.14
Spring Data JPA
PostgreSQL
Redis
React 18.3
TypeScript 5.9

팀 구성: 7명
담당 범위: 서버 검색, AI 입력 보호, 작업 상태 관리

Case 01

자료가 많아져도 빠르고 빠짐없이 찾게 만든 과정

01대시보드

검색어·필터·페이지

02검색 API

조건을 서버로 전달

03데이터 조회

사용자 격리·정렬

04결과 검증

59건 집합 일치

문제 상황

전체 카드 목록을 받은 뒤 브라우저에서 검색·필터하면 불필요한 데이터 전송이 늘어납니다. 검색·페이지·사용자 격리가 따로 움직이면 결과 누락이나 노출 오류도 생길 수 있었습니다.

제가 정한 기준

검색어·태그·카테고리·기간·페이지 조건을 서버 요청 계약으로 옮겼습니다. 전후 검색 결과가 같고 사용자별 데이터가 섞이지 않는 것을 완료 조건으로 잡았습니다. 프런트는 서버 파라미터로 검색합니다. 복수 태그 AND, 기간 경계, LIKE 특수문자와 페이지 정렬을 검증하고, 인자 없는 기존 호출은 전체 목록 계약을 유지했습니다.

Case 02

AI가 읽은 원문을 나중에도 확인할 수 있게 남겼습니다.

01문제 확인

카드 내용이 바뀐 뒤에는 AI가 어떤 원문을 바탕으로 정리했는지 혼동될 수 있었습니다.

02조건 분리

생성 시점의 입력을 스냅샷으로 고정하고 개인정보 패턴 마스킹, 입력 상한, 작업 소유자 검사를 적용했습니다.

03검증 기록

Mock 모델과 합성 fixture로 관련 AI 테스트 42개를 통과했습니다. 외부 네트워크 2개는 제외했습니다.

문제 상황

카드 내용이 바뀐 뒤에는 AI가 어떤 원문을 바탕으로 정리했는지 혼동될 수 있었습니다.

제가 정한 기준

생성 시점의 입력을 스냅샷으로 고정하고 개인정보 패턴 마스킹, 입력 상한, 작업 소유자 검사를 적용했습니다.

Case 03

재시도와 검토에도 순서를 만들었습니다.

01문제 확인

실패 중인 작업이 여러 번 생성되거나 원시 오류가 그대로 보이면 학습 기록을 믿기 어려웠습니다.

02조건 분리

FAILED인 TIL 생성만 새 작업으로 등록하고 활성 작업의 중복 요청은 거절했습니다. 본문을 수정하면 기존 검토 표시도 초기화했습니다.

03검증 기록

작업 재시도, 원시 오류 비노출, 소유자 검토 저장을 단위 테스트로 확인했습니다.

문제 상황

실패 중인 작업이 여러 번 생성되거나 원시 오류가 그대로 보이면 학습 기록을 믿기 어려웠습니다.

제가 정한 기준

FAILED인 TIL 생성만 새 작업으로 등록하고 활성 작업의 중복 요청은 거절했습니다. 본문을 수정하면 기존 검토 표시도 초기화했습니다.

프로젝트 목록으로 ↑

Contact

고객의 금융 여정을끝까지 따라가는 개발자

끝까지 확인하는 개발

더 나은 방식을 찾는 개발

고객의 다음 행동을 생각하는 개발

Tech Stack

개발자로서의 여정

Project Store

CapSure

Roundy

SAN

승인 요청 뒤 통신이 끊기면 PG의 결제 결과를 알 수 없습니다. 실패로 간주해 다시 승인하면 중복 결제가 발생할 수 있었습니다.

납입 실패, 독촉, 유예 종료를 한 상태로 처리하면 청구 가능 여부가 잘못 판단될 수 있었습니다.

AI가 만든 문장이 근거 없이 보험금 지급 판단으로 이어지면 안 된다고 봤습니다.

요청마다 큐 확인과 삭제, 방 저장을 따로 처리하면 늦은 poll이 사용자를 다시 등록할 수 있었습니다. 이전 방의 정리 작업이 새 방 매핑을 지우는 문제도 있었습니다.

같은 인증 결과가 여러 요청에서 재사용되거나 다른 사람에게 쓰이면 안 됐습니다.

로그인 여부만으로 이전 방이나 다른 사용자의 방에 접근할 수 있으면 안 됐습니다.

전체 카드 목록을 받은 뒤 브라우저에서 검색·필터하면 불필요한 데이터 전송이 늘어납니다. 검색·페이지·사용자 격리가 따로 움직이면 결과 누락이나 노출 오류도 생길 수 있었습니다.

카드 내용이 바뀐 뒤에는 AI가 어떤 원문을 바탕으로 정리했는지 혼동될 수 있었습니다.

실패 중인 작업이 여러 번 생성되거나 원시 오류가 그대로 보이면 학습 기록을 믿기 어려웠습니다.