유다현

개발자

Contact

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

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

거래 상태를 끝까지 맞추는 개발
응답이 끊긴 뒤에도 데이터가 어긋나지 않도록 기록하고 복구합니다.
권한과 책임이 분명한 개발
인증 이후에도 사용자의 현재 권한과 처리 범위를 다시 확인합니다.
업무 흐름을 연결하는 개발
화면과 API, 외부 연동과 운영 상태를 하나의 흐름으로 이해합니다.

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
팀 구성
6명FE 1, BE 3, AI 1, INFRA 1
담당 범위
- 성향 퀴즈 흐름 연결
- 얼굴 인증과 방 접근
- 마스킹 미팅 화면 구현
프로젝트 과정 보기
SAN
크롬 확장 프로그램으로 저장한 자료를 다시 찾고 정리하는 서비스
기술 스택
- Java 21
- Spring Boot
- PostgreSQL
- React
팀 구성
7명FE 1, BE 3, AI 2, INFRA 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

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

CapSure

문제 상황

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

제가 정한 기준

타임아웃은 UNKNOWN으로 남기고, PG 조회 결과를 주문·금액과 대조한 뒤에만 계약을 확정했습니다.

제가 구현한 방식

PG 조회 결과를 주문·금액과 대조해 상태를 확정합니다. 행 잠금으로 대사 대상을 선점하고, Outbox에 후속 이벤트를 남겨 중단된 작업도 추적할 수 있게 했습니다.

Case 02

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

CapSure

01문제 확인

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

02조건 분리

미수, 독촉, 유예 종료를 따로 확인하고 청구는 사고일의 보장 상태로 판단했습니다.

03결과

납입과 계약 효력을 같은 상태로 뭉치지 않고, 판단에 필요한 조건을 나눠 관리했습니다.

문제 상황

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

제가 정한 기준

미수, 독촉, 유예 종료를 따로 확인하고 청구는 사고일의 보장 상태로 판단했습니다.

제가 구현한 방식

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

Case 03

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

CapSure

01문제 확인

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

02조건 분리

약관 ID와 증빙 유형만 전달하고, 응답의 근거를 다시 확인한 뒤 담당자 검토 초안으로 남겼습니다.

03결과

AI의 응답을 검토 초안으로 제한해 지급 판단과 분리했습니다.

문제 상황

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

제가 정한 기준

약관 ID와 증빙 유형만 전달하고, 응답의 근거를 다시 확인한 뒤 담당자 검토 초안으로 남겼습니다.

제가 구현한 방식

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

프로젝트 목록으로 ↑

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

Roundy

02 / 03

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

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

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

팀 구성: 6명 · FE 1 · BE 3 · AI 1 · INFRA 1
담당 범위: 매칭, 인증, 방 접근 권한 보강

Case 01

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

Roundy

문제 상황

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

제가 정한 기준

인증 소비부터 대기열, 방 매핑까지 Redis Lua에서 한 번에 처리하고, 오래된 정리는 현재 방인지 확인하게 했습니다.

제가 구현한 방식

cleanup-room.lua는 사용자의 현재 roomId가 정리 대상과 같은지 검사한 뒤 삭제합니다. 새로운 방에 들어간 사용자의 매핑은 그대로 보존합니다.

Case 02

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

Roundy

01문제 확인

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

02조건 분리

인증 결과를 사용자 ID에 귀속하고 VERIFIED 상태만 한 번 소비하도록 만들었습니다.

03결과

인증 결과를 사용자에게 귀속하고 한 번만 소비하도록 만들어 재사용을 막았습니다.

문제 상황

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

제가 정한 기준

인증 결과를 사용자 ID에 귀속하고 VERIFIED 상태만 한 번 소비하도록 만들었습니다.

제가 구현한 방식

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

Case 03

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

Roundy

01문제 확인

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

02조건 분리

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

03결과

로그인 여부가 아니라 현재 방의 멤버인지까지 확인하도록 접근 경계를 맞췄습니다.

문제 상황

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

제가 정한 기준

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

제가 구현한 방식

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명 · FE 1 · BE 3 · AI 2 · INFRA 1
담당 범위: 서버 검색, AI 입력 보호, 작업 상태 관리

Case 01

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

SAN

문제 상황

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

제가 정한 기준

검색어, 태그, 기간, 페이지 조건을 서버 요청으로 옮기고 사용자별 결과와 정렬을 함께 확인했습니다.

제가 구현한 방식

프런트는 서버 파라미터로 검색합니다. 복수 태그 AND, 기간 경계, LIKE 특수문자와 페이지 정렬을 검증하고, 인자 없는 기존 호출은 전체 목록 계약을 유지했습니다.

Case 02

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

SAN

01문제 확인

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

02조건 분리

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

03결과

AI가 읽은 원문과 생성 시점을 남겨 나중에도 근거를 확인할 수 있게 했습니다.

문제 상황

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

제가 정한 기준

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

제가 구현한 방식

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

Case 03

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

SAN

01문제 확인

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

02조건 분리

실패한 TIL만 새 작업으로 등록하고, 수정 뒤에는 기존 검토 상태를 초기화했습니다.

03결과

실패한 작업만 다시 시작하고 검토 상태를 분리해, 다음 행동이 흐려지지 않게 했습니다.

문제 상황

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

제가 정한 기준

실패한 TIL만 새 작업으로 등록하고, 수정 뒤에는 기존 검토 상태를 초기화했습니다.

제가 구현한 방식

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

프로젝트 목록으로 ↑

Contact

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

거래 상태를 끝까지 맞추는 개발

권한과 책임이 분명한 개발

업무 흐름을 연결하는 개발

Tech Stack

개발자로서의 여정

Project Store

CapSure

Roundy

SAN

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

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

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

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

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

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

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

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

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