유다현 프로필 사진

유다현

IT / AX

Contact

문제의 시작부터 해결의 끝까지따라가는 개발자

TALENT · HOW I WORK

  1. 자기주도성

    프로그래밍 스터디를 직접 기획·운영하며, 필요한 일을 찾아 실행했습니다.

  2. 문제해결 실행력

    결제 승인 뒤 저장이 실패하는 상황을 재현하고, 계약 복구까지 확인했습니다.

  3. 실험정신

    AI 요약의 순차·병렬 처리를 같은 조건에서 비교해 개선 효과를 확인했습니다.

  4. 학습민첩성

    React 화면 구현에서 Spring Boot API와 Redis 상태 처리까지 경험을 넓혔습니다.

  5. 전략적 협업능력

    프런트엔드 리드로 상품 선택·가입 화면과 백엔드 API의 연동 흐름을 연결했습니다.

01

SCROLL

02

MY JOURNEY

우성 IT/AX를 향한 여정

  1. 2021.03–2025.08

    동국대학교GPA 4.11 / 4.5

    경영정보학과 · 융합소프트웨어

  2. 2022.03–2022.12

    멋쟁이사자처럼 10기

    HTML · CSS · 자바스크립트 웹 프로젝트

  3. 2023.01–2023.02

    부스트코스 코칭스터디 9기

    인공지능 기초 다지기 · 6주 코칭스터디 수료

  4. 2023.03–2023.12

    IT 소모임장 'ProMIS'

    신입생 대상 프로그래밍 스터디 기획 및 운영

  5. 2023.03–2024.02

    GDSC(Google Developer Student Clubs) 1기

    앱 개발 프로젝트 · 팀 협업

  6. 2024.09–2025.02

    University of Lancashire

    영국 교환학생 · 최우수 성적

  7. 2025.03–2025.06

    구름톤 유니브 4기

    개발자 커뮤니케이션

  8. 2025.07–2026.06

    삼성청년SW·AI 아카데미 14기

    자바 · 스프링 기반 백엔드 개발

  9. 2026.08

    한화금융캠퍼스 15기

    금융 실무 교육 · 현직자 멘토링

우성

현장의 흐름을 이해하고,
업무에 쓰이는 변화로 이어가겠습니다.

03

Profile record

기능 구현에서 멈추지 않고, 처리 결과와 복구까지 확인했습니다.

프로젝트에서 결제 승인 후 저장 실패와 동시 요청 충돌을 재현하고, 처리 결과의 일관성과 복구 과정을 검증했습니다. AI 요약은 같은 입력으로 순차·병렬 처리를 비교해 개선 효과를 측정했습니다. 입사 후에는 사내 시스템과 인프라의 구조를 익히고, 현업의 요구를 파악해 안정적인 운영과 데이터·AI 기반 업무 개선에 기여하겠습니다.

Awards

  • AICompS 2025 Best Poster Award한국정보처리학회
    • 뇌졸중 위험 신호 확인 앱의 얼굴·음성 분석과 모바일 이용 흐름을 포스터로 발표
  • 2025년도 여름 종합설계 결과발표회 우수상동국대학교
    • 얼굴·음성 분석 결과를 자가 확인과 병원 탐색으로 연결한 모바일 앱

Certificates

  • 정보처리기사한국산업인력공단
  • ADsP(데이터분석 준전문가)한국데이터산업진흥원
  • SQL 개발자(SQLD)한국데이터산업진흥원
  • 컴퓨터활용능력 2급대한상공회의소
  • ITQ 한글엑셀 A등급한국생산성본부

Tech Stack

프로젝트 경험을 기준으로 한 상대적 자기평가입니다.

Backend

  • Java고급 · 5단계 중 4단계, 추정
  • Spring Boot고급 · 5단계 중 4단계, 추정

Frontend

  • React고급 · 5단계 중 4단계, 추정
  • Vue.js중급 · 5단계 중 3단계, 추정
  • Next.js초급 · 5단계 중 2단계, 추정
  • TypeScript중급 · 5단계 중 3단계, 추정

Data

  • SQL중급 · 5단계 중 3단계, 추정
  • PostgreSQL중급 · 5단계 중 3단계, 추정
  • Redis고급 · 5단계 중 4단계, 추정

Infrastructure

  • AWS초급 · 5단계 중 2단계, 추정
  • Docker초급 · 5단계 중 2단계, 추정

Tools

  • Figma고급 · 5단계 중 4단계, 추정
  • Jira초급 · 5단계 중 2단계, 추정
  • Notion중급 · 5단계 중 3단계, 추정
  • Harness초급 · 5단계 중 2단계, 추정

04

Selected work

Project Store

서비스의 핵심 흐름과 제가 맡은 범위를 간략히 정리했습니다.

CapSure 월 보험료 입력과 캡슐 구성이 움직이는 애니메이션 화면
CapSure 대시보드가 표시되는 애니메이션 화면

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

CapSure
01 / 04

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

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

  • Java 21
  • Spring Boot 3.5.11
  • MyBatis 3.0.5
  • PostgreSQL
  • React 19
  • Toss Payments SDK 2
팀 구성
5명 · FE 1 · BE 3 · INFRA 1
담당 범위
FE Lead · BE / 상품 선택 UI와 결제·계약 복구 흐름
PROBLEM 01결제 복구 · 멱등성

오류가 났다고, 결제를 다시 승인하지 않습니다.

외부 승인과 내부 저장을 구분하고, 같은 주문의 결과를 확인해 계약까지 복구했습니다.

결제·계약 복구 흐름
PG 승인 완료 뒤 내부 저장이 실패했을 때 기존 주문을 대사해 계약과 이벤트까지 복구하는 시스템 흐름
복구의 기준승인은 반복하지 않고, 끊긴 내부 처리를 이어갑니다.

수납 오류의 복구 완료 기준을 응답 성공이 아니라 계약 반영까지 잡는 관점입니다.

Problem

  • PG 승인 직후 증권 저장에 예외가 나자 HTTP 500이 반환됐습니다.
  • 외부 승인은 DB 롤백으로 취소되지 않아, 실패 응답만 보고 재승인할 수 없었습니다.

Approach

  • 승인 후 내부 실패는 APPROVING으로 유지하고, 새 승인보다 기존 거래 조회·대사를 우선했습니다.
  • 같은 주문의 결제 상태를 확인해 계약 활성화, 증권과 Outbox를 이어서 복구했습니다.

Impact

  • 대사 후 결제는 PAID, 계약은 ACTIVE로 복구됐습니다.
  • 증권과 활성화 이벤트는 각각 1건이었고, 별도 동일 confirm 100회 시험에서도 외부 승인 호출은 1회였습니다.

합성 PG · 저장 예외 주입 · 기존 결제 통합 테스트 기록

PROBLEM 02계약 효력 · 시간 경계

배치가 늦어도, 계약 판단은 달라지지 않게.

입금 기록과 계약 효력을 분리하고, 수납 순간에도 같은 만료 규칙을 적용했습니다.

입금 시점으로 보는 동일 정책
유예 종료 시점을 기준으로 수납과 실효 배치가 동일한 계약 상태를 판단하는 시스템 흐름
변하지 않는 원칙입금은 기록하되, 계약을 자동으로 되살리지 않습니다.

배치 실행 순서와 무관하게 같은 업무 기준으로 계약 상태를 판단하는 관점입니다.

Problem

  • 유예 종료 다음 날 입금이 실효 배치보다 먼저 도착하면 DB에는 아직 GRACE가 남습니다.
  • 저장된 상태만 보고 수납하면 이미 만료된 계약이 다시 활성화될 수 있었습니다.

Approach

  • 수납 전에 계약을 잠그고 beforeSettlement로 만료 여부를 다시 판단했습니다.
  • 실효 후 입금은 수납 기록과 지연 검토로 남기되, 계약을 자동 활성화하지 않았습니다.

Impact

  • 유예 마지막 날 완납은 ACTIVE, 다음 날 배치 전 입금은 LAPSED와 검토 1건으로 확인했습니다.
  • 같은 실효 후 출금 결과를 두 번 반영한 시험에서도 수납과 지연 검토는 각각 1건이었습니다.

합성 상품 정책 · 시험 시계 제어 · 기존 미납 통합 테스트 기록

회원가입 과정에서 연애 목표와 데이트 스타일을 선택하는 Roundy 취향 분석 화면
01회원가입 취향 분석

등록 사진과 실시간 촬영을 대조한 뒤, 마스킹 대화와 상호 선택을 거쳐 얼굴을 공개합니다.

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

Roundy
02 / 04

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

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

  • 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
담당 범위
FE · BE / 매칭, 인증, 방 접근 권한 보강
PROBLEM 01동시 요청 · 상태 정합성

늦게 도착한 이전 방 정리 요청이 새 방까지 삭제했습니다.

늦은 이전 방 정리 요청에도 새 방 B가 유지되도록 했습니다.

새 방 B 배정과 늦은 이전 방 A 정리 요청이 Redis에서 만나, 현재 방 B와 정리 대상 A가 달라 B를 유지하는 흐름

Problem

  • 매칭 입장에서 늦은 poll이 이미 배정된 사용자를 다시 큐에 넣는 순서 충돌이 있었습니다.
  • 새 방 B를 배정한 뒤 이전 방 A의 정리 요청까지 늦게 도착하면, 조건 없는 삭제가 B를 유실시켰습니다.

Approach

  • 인증 소비·큐 등록·방 배정을 Redis Lua에서 원자적으로 처리했습니다.
  • 정리할 때 현재 방과 대상 roomId를 비교해, 일치할 때만 삭제했습니다.
  • 대상이 A이고 현재 방이 B라면 B를 유지합니다.

Impact

  • 늦은 poll로 인한 재큐잉이 100/100회에서 0/100회로 줄었습니다.
  • 원자적 입장만으로는 새 방 유실이 해결되지 않았지만, 조건부 정리를 추가한 뒤 재현되지 않았습니다.
  • 요청 순서를 제어한 로컬 시험으로 입장 처리와 이전 방 정리의 두 경계를 각각 검증했습니다.

격리 Redis 8.4.0 · 모의 JWT/DB · 조건별 100회 로컬 시험

PROBLEM 02인증 결과 · 소유권과 일회성

인증 성공은 본인만, 한 번만 사용할 수 있게.

성공 여부뿐 아니라 소유자·요청·상태를 묶고, 인증 결과 소비를 원자적으로 처리했습니다.

얼굴 인증 결과가 소비되기까지
  1. 1

    얼굴 인증 요청

    사용자가 얼굴을 촬영해 요청합니다.

    사용자 얼굴 촬영
    face-matching 요청
  2. 2

    Redis Gate

    요청 단위로 결과 상태를 관리합니다.

    Redis요청 상태 저장
    userId + requestId
  3. 3

    상태 전이

    하나의 요청은 정해진 순서로만 진행됩니다.

    PENDING요청 접수VERIFIED얼굴 일치 확인CONSUMED1회만 소비
  4. 4

    16개 중 1개만 성공

    동시에 16개 요청을 보냈고, 한 건만 통과했습니다.

    12345678910111213141516
    1개만 성공나머지 15개는 이미 소비됨

Problem

  • 성공 여부만 확인하면 타인이나 겹친 요청이 같은 인증 결과를 사용할 수 있었습니다.
  • 이미 소비한 결과를 늦게 도착한 완료 응답이 되살릴 위험도 있었습니다.

Approach

  • 결과를 verify:{userId}:{requestId}에 귀속하고 소유자와 요청을 함께 확인했습니다.
  • 완료는 PENDING에서만, 소비는 VERIFIED에서만 허용하는 Redis Lua 상태 전이를 적용했습니다.

Impact

  • 8개 워커가 보낸 동시 소비 요청 16개 중 1개만 성공했습니다.
  • 타인 소비와 재소비는 실패했고, 소비 뒤 늦은 완료 응답도 결과를 되살리지 못했습니다.

실제 Redis · 모의 DB · 8개 워커에 16개 소비 요청 제출

01 자료를 익스텐션에 넣고02 지식 나무로 모아보기
03 TIL로 정리하고04 유사 지식을 확인하며 지식 성장하기
텍스트, 이미지, 링크를 드래그해 지식을 저장하는 SAN 크롬 확장 프로그램 화면
저장한 자료가 카테고리별 지식 나무로 모인 SAN 화면

흩어진 자료가 하나의 지식 나무로

저장한 지식을 바탕으로 오늘의 학습을 정리하는 SAN TIL 화면

저장한 지식을 오늘의 TIL로

학습 기록과 활동을 한눈에 보는 SAN 마이페이지 화면

쌓인 기록을 마이페이지에서

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

SAN
03 / 04

흩어진 자료를, 다시 쓰는 지식으로.

크롬 확장 프로그램으로 저장한 자료를 검색, 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
담당 범위
FE · BE / 비동기 감사 추적, 로그인 브리지, AI 요약 병렬화
Chrome Web Store에서 SAN 보기
PROBLEM 01비동기 작업 · 감사 추적

비동기 작업이 요청 맥락을 잃지 않도록.

작업이 큐로 넘어가도 누가 요청했고 어떤 경로로 실행됐는지 남겨야 했습니다.요청 스냅샷을 워커에서 복원하고 시작·성공·실패를 같은 추적 흐름으로 기록했습니다.

Request Snapshot에서 Queue와 Worker Restore를 거쳐 Audit Log로 이어지고, 워커는 finally에서 이전 Context를 복원하는 비동기 감사 흐름

Problem

  • 비동기 작업이 요청 스레드를 벗어나면 actorUserId, traceId, IP와 User-Agent가 사라질 수 있었습니다.
  • 요청자와 워커의 시작·성공·실패 기록을 같은 작업으로 연결해야 했습니다.

Approach

  • 큐에 넣는 순간 감사에 필요한 요청 값을 스냅샷으로 고정했습니다.
  • 워커에서 컨텍스트를 복원해 같은 traceId로 기록하고, finally에서 이전 컨텍스트로 되돌렸습니다.

Impact

  • 요청 스냅샷 복원과 START·SUCCESS·FAILURE 감사 이벤트 기록을 코드와 단위 테스트에서 확인했습니다.
  • 워커 실행 후 이전 컨텍스트로 복귀하는 것도 검증했습니다.
PROBLEM 02로그인 브리지 · 토큰 노출

JWT를 URL에 남기지 않는 익스텐션 로그인 전환.

채널을 넘나드는 로그인에서 장기 토큰을 주소에 실어 보내지 않았습니다.짧게 살아 있는 1회용 티켓으로 교환하고 읽는 순간 소비되도록 제한했습니다.

Dashboardaccess token으로 Ticket 발급 요청
01 서버에서 토큰·출처 검증
Backend → Redis1회용 Ticket 저장 · TTL 2분
02 Dashboard에 Ticket 반환
1회용 Ticket
03 Dashboard가 메시지로 전달
Chrome ExtensionTicket으로 서버에 교환 요청
서버가 Redis getAndDelete로 1회 소비
로그인 성공유효 · 최초 소비
만료 거절유효 시간 경과
재사용 거절이미 소비한 Ticket
반대 방향 로그인은 Ticket TTL 30초를 적용합니다.

Problem

  • 대시보드와 익스텐션 사이에서 JWT를 URL로 전달하면 브라우저 기록과 리퍼러에 남을 수 있었습니다.
  • 오래 살아 있는 토큰을 채널 전환용 주소에 싣지 않아야 했습니다.

Approach

  • Dashboard에서 Extension으로는 메시지로, 역방향은 URL로 1회용 Ticket을 전달했습니다. 발급 시 access token과 출처 client type을 확인했습니다.
  • SecureRandom 32-byte 티켓을 Redis에 저장해 방향별 TTL을 적용하고 getAndDelete로 조회 즉시 소비했습니다.

Impact

  • 유효한 Ticket은 한 번만 소비되고, 만료·재사용 Ticket은 거절됐습니다.
  • 발급·교환·일회성 소비는 코드와 단위 테스트로 확인했습니다.
PROBLEM 03AI 요약 · 지연 측정

실제 AI 카드 요약을 병렬화해 중앙값 기준 약 59% 단축했습니다.

같은 모델과 같은 입력으로 순차 처리와 병렬 처리를 짝지어 비교했습니다.평균과 p95가 함께 줄어드는지 확인해 카드 요약 단계의 개선만 증명했습니다.

같은 카드 3개의 순차 처리 17.68초와 동시 처리 6.92초를 비교한 흐름도

Problem

  • 카드 3개의 AI 요약을 순차 호출하면서 각 응답 대기가 누적됐습니다.
  • 같은 카드 요약 단계의 평균 소요 시간이 17.68초였습니다.

Approach

  • 서로 독립적인 카드 요약 3건을 Python의 asyncio.gather로 동시에 실행했습니다.
  • 모델·입력·카드 수를 고정하고 AB/BA 순서를 균형 배치한 10쌍의 paired benchmark로 비교했습니다.

Impact

  • 평균은 17.68초에서 6.92초, p95는 21.30초에서 8.59초로 줄었습니다.
  • 중앙값 기준 59.45% 단축을 확인했으며, 측정 범위는 카드 요약 단계에 한정됩니다.

측정: 동일 합성 카드 3개 · 10쌍 · 카드 요약 단계만 / 제외: 전체 TIL·UI 응답 시간

하루 한 번 자가 진단을 시작하는 다시봄 iPhone 목업 화면다시봄 앱의 최종 진단 결과와 가까운 병원 안내 화면가까운 병원 정보를 지도에 표시한 다시봄 iPhone 목업 화면

AI 기반 뇌졸중 위험 신호 확인 앱

다시봄
04 / 04

AI로 뇌졸중 위험 신호를 확인하는 간편한 자가 확인 서비스.

얼굴·음성 결과를 먼저 확인하고, 필요할 때 CG-FAST 기준 설문과 병원 탐색으로 이어지는 모바일 앱입니다.

  • React Native
  • Spring Boot
  • MySQL
  • AI 분석 API
팀 구성
4명 · FE 1 · BE 1 · AI 2
담당 범위
FE · PM · UI/UX 디자인 / React Native 화면과 카메라·음성·지도·차트 연동

PROJECT BRIEF다시봄

얼굴·음성 확인에서 병원 탐색까지

먼저 얼굴·음성 결과를 보고, 추가 확인이 필요할 때 CG-FAST 기준 설문으로 이어집니다.
  1. 정면을 바라보고 눈을 감았다 뜨도록 안내하는 다시봄 얼굴 확인 화면
    01얼굴 확인카메라 앞에서 표정과 눈 움직임을 안내합니다.
  2. 문장을 읽고 녹음하도록 안내하는 다시봄 음성 확인 화면
    02음성 확인화면의 문장을 읽고 음성을 녹음합니다.
  3. 얼굴과 음성 확인 뒤 정상 범위라는 중간 결과와 자가 확인 진입 버튼을 보여주는 다시봄 화면
    03중간 결과얼굴·음성 확인 뒤 먼저 결과를 확인합니다.
  4. 팔마비 여부를 묻는 CG-FAST 자가 확인 문항 화면
    04추가 설문필요할 때만 CG-FAST 기준 문항으로 이어집니다.
  5. 자가 확인 점수와 결과 안내를 보여주는 다시봄 화면 목업의 첫 화면
    05설문 결과문항 응답 뒤 최종 결과와 안내를 봅니다.
  6. 가까운 병원의 거리와 상세 정보를 표시한 다시봄 화면 목업
    06병원 정보가까운 병원의 위치와 상세 정보를 봅니다.
기술 구성과 처리 흐름얼굴·음성 → 중간 결과 → 필요 시 설문