AI 분석 APIProblem
- PG 승인 직후 증권 저장에 예외가 나자 HTTP 500이 반환됐습니다.
- 외부 승인은 DB 롤백으로 취소되지 않아, 실패 응답만 보고 재승인할 수 없었습니다.
데이터의 흐름을 이해하고,업무에 맞는 결과를 만드는 개발자
- 더 나은 방법을 찾습니다검색이 느린 이유를 찾고, 처리 구조를 바꿔 비교했습니다.
- 기준을 함께 맞춥니다화면과 API의 연결 조건을 정리하고, 팀과 수정 범위를 조율했습니다.
- 배운 것은 직접 써봅니다Python 비동기 처리를 익히고, AI 요약 요청을 병렬화했습니다.
- 결과까지 확인합니다중단과 중복 요청을 재현하고, 복구 뒤 데이터까지 확인했습니다.
01
SCROLL02
Web & App · Service development
오브젠을 향한 여정
2021.03–2025.08
동국대학교GPA 4.11 / 4.5경영정보학과 · 융합소프트웨어연계전공
2022.03–2022.11
멋쟁이사자처럼 10기HTML · CSS · 자바스크립트 웹 프로젝트
2023.01–2023.02
부스트코스 코칭스터디 9기인공지능 기초 다지기 · 6주 코칭스터디 수료
2023.03–2023.12.11
IT 소모임장 'ProMIS'50명 규모 · 프로그래밍 스터디 기획 및 운영
2023.09–2024.08
GDSC(Google Developer Student Clubs) 1기앱 개발 프로젝트 · 팀 협업
2024.09–2025.02
University of Central Lancashire영국 교환학생 · 최우수 성적
2025.03–2025.06
구름톤 유니브 4기개발자 커뮤니케이션
2025.07–2026.06
삼성청년SW·AI 아카데미 14기자바 · 스프링 기반 백엔드 개발
2026.08
한화금융캠퍼스 15기금융 도메인 이해 · 현직자 멘토링으로 서비스 관점 확장
쌓아온 경험을 살려,
오브젠의 데이터·AI 플랫폼 구축으로 이어가겠습니다.
03
Profile record
데이터 처리의 성능과 결과를 함께 확인합니다.
SQL 조건 검색과 집계 구조를 개선하고, 변경 전후의 결과를 비교했습니다.
Python AI 요약을 병렬화하고, 비동기 작업의 요청자와 처리 결과를 추적했습니다.
Awards
- AICompS 2025 Best Poster Award한국정보처리학회
- 2025년도 여름 종합설계 결과발표회 우수상동국대학교 SW교육원
Certificates
- 정보처리기사한국산업인력공단
- ADsP(데이터분석 준전문가)한국데이터산업진흥원
- SQL 개발자(SQLD)한국데이터산업진흥원
- 컴퓨터활용능력 2급대한상공회의소
- ITQ 한글엑셀 A등급한국생산성본부
Tech Stack
Backend
- Java고급 · 5단계 중 4단계, 추정
- Spring Boot고급 · 5단계 중 4단계, 추정
- JSP고급 · 5단계 중 4단계, 추정
Frontend
- React고급 · 5단계 중 4단계, 추정
- Vue.js중급 · 5단계 중 3단계, 추정
- Next.js초급 · 5단계 중 2단계, 추정
- TypeScript중급 · 5단계 중 3단계, 추정
Data
- Python중급 · 5단계 중 3단계, 추정
- SQL고급 · 5단계 중 4단계, 추정
- PostgreSQL중급 · 5단계 중 3단계, 추정
- Redis고급 · 5단계 중 4단계, 추정
Infrastructure
- AWS중급 · 5단계 중 3단계, 추정
- Docker중급 · 5단계 중 3단계, 추정
Tools
- Jira중급 · 5단계 중 3단계, 추정
- Notion고급 · 5단계 중 4단계, 추정
- Harness초급 · 5단계 중 2단계, 추정
- Figma고급 · 5단계 중 4단계, 추정
숙련도 기준
- 1 기초튜토리얼 수행
- 2 초급예제 참고 구현
- 3 중급문서 참고·독립 개발
- 4 고급프로젝트 주도 활용
- 5 전문가코드 리뷰·멘토링
04
Selected work
Project Portfolio
데이터 조회·가공과 시스템 연계를 구현하고 검증한 프로젝트입니다.
CapSure
필요한 보장을 고르고 월 단위로 구독하는 보험 시뮬레이션 서비스
기술 스택
- Java 21
- Spring Boot
- PostgreSQL
- React
팀 구성
5명FE 1 · BE 3 · INFRA 15–7페이지담당 범위
FE Lead · BE- 상품 선택과 가입 흐름
- 결제 결과와 구독 확정
- 반응형 화면 구현
Roundy
성향 퀴즈와 얼굴 인증으로 시작하는 온라인 로테이션 미팅 서비스
기술 스택
- Java 21
- Spring Boot
- Redis
- React
팀 구성
6명FE 1 · BE 3 · AI 1 · INFRA 18–10페이지담당 범위
FE · BE- 성향 퀴즈 흐름 연결
- 얼굴 인증과 방 접근
- 마스킹 미팅 화면 구현
SAN
크롬 확장 프로그램으로 저장한 자료를 다시 찾고 정리하는 서비스
기술 스택
- Java 21
- Spring Boot
- PostgreSQL
- React
팀 구성
7명FE 1 · BE 3 · AI 2 · INFRA 111–14페이지담당 범위
FE 주요 화면·사용자 흐름 구현 · BE 검색 API·로그인 브리지·비동기 감사 추적·AI 요약 병렬화- 서버 검색 기능 구현
- 로그인 티켓 설계
- 비동기 작업 상태 관리
Project brief다시봄
얼굴·음성 결과를 먼저 보고, 필요 시 설문으로 이어지는 모바일 서비스
기술 스택
- React Native
- Spring Boot
- AI 분석 API
- MySQL
팀 구성
4명FE 1 · BE 1 · AI 215–16페이지담당 범위
FE · PM · UI/UX 디자인- 서비스 기획과 UI/UX
- 카메라·음성 입력 연결
- 지도·차트 화면 구현
구독형 보험 프로세스 시뮬레이터
CapSure결제와 계약의 상태를 끝까지 맞추다.
보장을 선택해 월 단위로 구독하는 보험 시뮬레이션 서비스입니다. 보장 변경의 승인일과 적용일을 구분하고, 청구월에 유효한 계약 버전으로 보험료를 계산했습니다.
Java 21
Spring Boot 3.5.11- MyBatis 3.0.5
PostgreSQL
React 19- Toss Payments SDK 2
등록 사진과 실시간 촬영을 대조한 뒤, 마스킹 대화와 상호 선택을 거쳐 얼굴을 공개합니다.
얼굴 인증과 마스킹 기반 미팅
Roundy얼굴 인증으로 신뢰를 더한 실시간 로테이션 매칭 서비스.
실시간으로 상대를 만나고, 실루엣으로 먼저 대화합니다. 서로 선택하면 시간이 흐를수록 마스킹이 풀리며 얼굴을 확인합니다.
- Java 21
- Spring Boot 3.5.9
Redis와 Lua- MySQL
- React 19
TypeScript 5.9- OpenVidu 2.32
PROBLEM 01동시 요청 · 상태 정합성
늦게 도착한 이전 방 정리 요청이 새 방까지 삭제했습니다.
늦은 이전 방 정리 요청에도 새 방 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
얼굴 인증 요청
사용자가 얼굴을 촬영해 요청합니다.
사용자 얼굴 촬영
face-matching 요청 - 2
Redis Gate
요청 단위로 결과 상태를 관리합니다.
요청 상태 저장
userId + requestId - 3
상태 전이
하나의 요청은 정해진 순서로만 진행됩니다.
PENDING요청 접수VERIFIED얼굴 일치 확인CONSUMED1회만 소비 - 4
16개 중 1개만 성공
동시에 16개 요청을 보냈고, 한 건만 통과했습니다.
123456789101112131415161개만 성공나머지 15개는 이미 소비됨
Problem
- 성공 여부만 확인하면 타인이나 겹친 요청이 같은 인증 결과를 사용할 수 있었습니다.
- 이미 소비한 결과를 늦게 도착한 완료 응답이 되살릴 위험도 있었습니다.
Approach
- 결과를 verify:{userId}:{requestId}에 귀속하고 소유자와 요청을 함께 확인했습니다.
- 완료는 PENDING에서만, 소비는 VERIFIED에서만 허용하는 Redis Lua 상태 전이를 적용했습니다.
Impact
- 8개 워커가 보낸 동시 소비 요청 16개 중 1개만 성공했습니다.
- 타인 소비와 재소비는 실패했고, 소비 뒤 늦은 완료 응답도 결과를 되살리지 못했습니다.
실제 Redis · 모의 DB · 8개 워커에 16개 소비 요청 제출
01 자료를 익스텐션에 넣고02 지식 나무로 모아보기
03 TIL로 정리하고04 유사 지식을 확인하며 지식 성장하기
흩어진 자료가 하나의 지식 나무로
저장한 지식을 오늘의 TIL로
쌓인 기록을 마이페이지에서
크롬 확장 프로그램 기반 지식 관리
SAN흩어진 자료를, 다시 쓰는 지식으로.
크롬 확장 프로그램으로 저장한 자료를 검색, TIL, 지식 카드로 연결하는 서비스입니다. AI 정리 기능도 원문 근거를 남긴 상태에서 검토할 수 있도록 설계했습니다.
- Java 21
- Spring Boot 3.5.14
- Spring Data JPA
- PostgreSQL
- Redis
- React 18.3
- TypeScript 5.9
PROBLEM 01검색 API · 조건 조회 · 페이지 처리
전체 자료 대신 필요한 결과만, 서버 검색으로 전환했습니다.
검색을 서버로 옮기고 반복되던 집계를 줄였습니다.응답 시간뿐 아니라 검색 결과, 사용자별 접근 범위와 페이지 순서도 함께 확인했습니다.
BEFORE전체 목록 전송브라우저에서 필터링
AFTERDB 조건 검색필요한 페이지만 반환
검색 첫 페이지 p95
로컬 합성 10,000건기존133.67ms
개선 85% 이상 단축19.04ms
100%동일 조건 · 개선 전후 조회 결과 일치
사용자 격리태그 AND 조건안정적인 페이지 정렬
Problem
- 전체 자료를 내려받아 브라우저에서 검색·필터링했습니다.
- 자료별 태그 집계도 반복돼, 불필요한 전송과 쿼리 처리 부담이 함께 생겼습니다.
Approach
- 서버에서 검색 조건을 적용한 뒤, 필요한 페이지만 반환했습니다.
- 자료별 태그 집계를 한 번 계산해 조인하고, 실행계획으로 반복 처리가 줄었는지 확인했습니다.
Impact
- 로컬 합성 1만 건에서 검색 첫 50건 처리 p95가 133.67ms에서 19.04ms로 줄었습니다.
- 동일 조건의 조회 결과가 개선 전후 일치했고, 페이지 중복·누락과 사용자 격리도 확인했습니다.
PROBLEM 02비동기 작업 · 감사 추적
비동기 작업이 요청 맥락을 잃지 않도록.
작업이 큐로 넘어가도 누가 요청했고 어떤 경로로 실행됐는지 남겨야 했습니다.요청 스냅샷을 워커에서 복원하고 시작·성공·실패를 같은 추적 흐름으로 기록했습니다.
Problem
- 비동기 작업이 요청 스레드를 벗어나면 actorUserId, traceId, IP와 User-Agent가 사라질 수 있었습니다.
- 요청자와 워커의 시작·성공·실패 기록을 같은 작업으로 연결해야 했습니다.
Approach
- 큐에 넣는 순간 감사에 필요한 요청 값을 스냅샷으로 고정했습니다.
- 워커에서 컨텍스트를 복원해 같은 traceId로 기록하고, finally에서 이전 컨텍스트로 되돌렸습니다.
Impact
- 요청 스냅샷 복원과 START·SUCCESS·FAILURE 감사 이벤트 기록을 코드와 단위 테스트에서 확인했습니다.
- 워커 실행 후 이전 컨텍스트로 복귀하는 것도 검증했습니다.
PROBLEM 03로그인 브리지 · 토큰 노출
JWT를 URL에 남기지 않는 익스텐션 로그인 전환.
채널을 넘나드는 로그인에서 장기 토큰을 주소에 실어 보내지 않았습니다.짧게 살아 있는 1회용 티켓으로 교환하고 읽는 순간 소비되도록 제한했습니다.
Dashboardaccess token으로 Ticket 발급 요청
01 서버에서 토큰·출처 검증
Backend → Redis1회용 Ticket 저장 · TTL 2분
02 Dashboard에 Ticket 반환
03 Dashboard가 메시지로 전달
Chrome ExtensionTicket으로 서버에 교환 요청
서버가 Redis getAndDelete로 1회 소비
로그인 성공유효 · 최초 소비
만료 거절유효 시간 경과
재사용 거절이미 소비한 Ticket
Problem
- 대시보드와 익스텐션 사이에서 JWT를 URL로 전달하면 브라우저 기록과 리퍼러에 남을 수 있었습니다.
- 오래 살아 있는 토큰을 채널 전환용 주소에 싣지 않아야 했습니다.
Approach
- Dashboard에서 Extension으로는 메시지로, 역방향은 URL로 1회용 Ticket을 전달했습니다. 발급 시 access token과 출처 client type을 확인했습니다.
- SecureRandom 32-byte 티켓을 Redis에 저장해 방향별 TTL을 적용하고 getAndDelete로 조회 즉시 소비했습니다.
Impact
- 유효한 Ticket은 한 번만 소비되고, 만료·재사용 Ticket은 거절됐습니다.
- 발급·교환·일회성 소비는 코드와 단위 테스트로 확인했습니다.
AI 기반 뇌졸중 위험 신호 확인 앱
다시봄AI로 뇌졸중 위험 신호를 확인하는 간편한 자가 확인 서비스.
얼굴·음성 결과를 먼저 확인하고, 필요할 때 CG-FAST 기준 설문과 병원 탐색으로 이어지는 모바일 앱입니다.
- React Native
- Spring Boot
- MySQL
- AI 분석 API
PROJECT BRIEF다시봄
얼굴·음성 확인에서 병원 탐색까지
먼저 얼굴·음성 결과를 보고, 추가 확인이 필요할 때 CG-FAST 기준 설문으로 이어집니다.
01얼굴 확인카메라 앞에서 표정과 눈 움직임을 안내합니다. 
02음성 확인화면의 문장을 읽고 음성을 녹음합니다. 
03중간 결과얼굴·음성 확인 뒤 먼저 결과를 확인합니다. 
04추가 설문필요할 때만 CG-FAST 기준 문항으로 이어집니다. 
05설문 결과문항 응답 뒤 최종 결과와 안내를 봅니다. 
06병원 정보가까운 병원의 위치와 상세 정보를 봅니다.