AI 분석 APIProblem
- PG 승인 직후 증권 저장에 예외가 나자 HTTP 500이 반환됐습니다.
- 외부 승인은 DB 롤백으로 취소되지 않아, 실패 응답만 보고 재승인할 수 없었습니다.
사용자의요구사항부터운영 결과까지 확인하는 개발자
운영 상태를 끝까지 확인
오류를 고치는 데서 멈추지 않고, 사용자에게 어떤 결과로 돌아가는지까지 확인합니다.
요구를 구현 가능한 과제로 전환
사용자의 불편을 재현하고, 기능 개선과 검증 기준으로 구체화합니다.
데이터로 결과를 검증
SQL 조회와 상태 기록을 대조해, 개선 전후의 결과가 정확한지 확인합니다.
01
SCROLL02
Development journey
개발자로서의 여정
2021.03–2025.08
동국대학교GPA 4.11 / 4.5경영정보학과 · 융합소프트웨어
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기자바 · 스프링 기반 백엔드 개발
2026.08
한화금융캠퍼스 15기금융 실무 교육 · 현직자 멘토링
쌓아온 경험을,
한국콜마의 안정적인 IT 운영과 개선으로 이어가겠습니다.
03
Profile record
사용자의 요청을 기능으로 옮기고, 운영 결과까지 확인했습니다.
React로 사용자가 이해하기 쉬운 화면을 만들고 Spring Boot로 요구사항을 API와 기능 개선으로 연결했습니다. SQL 조회 결과를 원본과 대조하고, Redis와 외부 연동에서 요청이 겹치거나 응답이 끊기는 상황을 재현해 상태가 복구되는지 확인했습니다. 한국콜마에서도 임직원과 고객사의 요청을 정확한 개선 과제로 바꾸고, 시스템과 데이터를 믿을 수 있게 운영하고 싶습니다.
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
- Jira초급 · 5단계 중 2단계, 추정
- Notion중급 · 5단계 중 3단계, 추정
- Harness초급 · 5단계 중 2단계, 추정
04
Selected work
Project Store
서비스의 핵심 흐름과 제가 맡은 범위를 간략히 정리했습니다.
CapSure
필요한 보장을 고르고 월 단위로 구독하는 보험 시뮬레이터
기술 스택
- Java 21
- Spring Boot
- PostgreSQL
- React
팀 구성
5명FE 1 · BE 3 · INFRA 1자세히 보기담당 범위
FE Lead · BE- 상품 선택과 가입 흐름
- 결제 결과와 구독 확정
- 반응형 화면 구현
Roundy
성향 퀴즈와 얼굴 인증으로 시작하는 온라인 로테이션 미팅
기술 스택
- Java 21
- Spring Boot
- Redis
- React
팀 구성
6명FE 1 · BE 3 · AI 1 · INFRA 1자세히 보기담당 범위
FE · BE- 성향 퀴즈 흐름 연결
- 얼굴 인증과 방 접근
- 마스킹 미팅 화면 구현
SAN
크롬 확장 프로그램으로 저장한 자료를 다시 찾고 정리하는 서비스
기술 스택
- Java 21
- Spring Boot
- PostgreSQL
- React
팀 구성
7명FE 1 · BE 3 · AI 2 · INFRA 1자세히 보기담당 범위
FE · BE- 서버 검색 기능 구현
- AI 입력 보호 설계
- 작업 상태 관리
Project brief다시봄
얼굴·음성 결과를 먼저 보고, 필요 시 설문으로 이어지는 모바일 앱
기술 스택
- React Native
- Spring Boot
- AI 분석 API
- MySQL
팀 구성
4명FE 1 · BE 1 · AI 2자세히 보기담당 범위
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비동기 작업 · 감사 추적
비동기 작업이 요청 맥락을 잃지 않도록.
작업이 큐로 넘어가도 누가 요청했고 어떤 경로로 실행됐는지 남겨야 했습니다.요청 스냅샷을 워커에서 복원하고 시작·성공·실패를 같은 추적 흐름으로 기록했습니다.
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 반환
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은 거절됐습니다.
- 발급·교환·일회성 소비는 코드와 단위 테스트로 확인했습니다.
PROBLEM 03AI 요약 · 지연 측정
실제 AI 카드 요약을 병렬화해 중앙값 기준 약 59% 단축했습니다.
같은 모델과 같은 입력으로 순차 처리와 병렬 처리를 짝지어 비교했습니다.평균과 p95가 함께 줄어드는지 확인해 카드 요약 단계의 개선만 증명했습니다.
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 응답 시간
AI 기반 뇌졸중 위험 신호 확인 앱
다시봄AI 분석 뒤, 결과와 가까운 병원 정보를 바로 확인합니다.
얼굴·음성 결과를 먼저 확인하고, 필요할 때 CG-FAST 기준 설문과 병원 탐색으로 이어지는 모바일 앱입니다.
- React Native
- Spring Boot
- MySQL
- AI 분석 API
PROJECT BRIEF다시봄
얼굴·음성 확인에서 병원 탐색까지
먼저 얼굴·음성 결과를 보고, 추가 확인이 필요할 때 CG-FAST 기준 설문으로 이어집니다.
01얼굴 확인카메라 앞에서 표정과 눈 움직임을 안내합니다. 
02음성 확인화면의 문장을 읽고 음성을 녹음합니다. 
03중간 결과얼굴·음성 확인 뒤 먼저 결과를 확인합니다. 
04추가 설문필요할 때만 CG-FAST 기준 문항으로 이어집니다. 
05설문 결과문항 응답 뒤 최종 결과와 안내를 봅니다. 
06병원 정보가까운 병원의 위치와 상세 정보를 봅니다.