Backend 중심 구현
단순 CRUD보다 상태 전환·이력 추적·권한 경계·외부 API 실패 가능성을 먼저 봅니다. QueryDSL 조회·트랜잭션 경계·금융 API 검증을 분리해 서비스 코드가 도메인 흐름에 집중하도록 구현합니다.
YJ
Technical Portfolio · 2026
01 / 26
Backend · Fullstack · AI Product
문제를 서비스 흐름으로
문제를 서비스 흐름으로
번역하는 개발자, 김용준입니다.
금융 도메인 백엔드, AI QA 자동화, 실시간 WebRTC 게임,
현장 운영형 포토부스까지 끝까지 만들어 본 경험이 있습니다.
Java · Spring Boot
JPA · QueryDSL · MyBatis
React · Vue · Electron
LLM Fine-tuning · Playwright
PM · Architecture · UX Flow
Backend 중심
상태·이력·권한·외부 API를 서비스 흐름으로 설계
E2E 구현
입력부터 결과 확인·실패
복구까지 화면/API 구현
복구까지 화면/API 구현
AI 제품화
실제 시스템에서 검증·실행되는 구조 구축
PM 경험
기능 우선순위·협업 문서·
화면 흐름·배포까지 조율
화면 흐름·배포까지 조율
AboutProfile · Education · Awards
02 / 26
About Me
제 강점은 구현 범위와 제품 맥락을 함께 잡는 것입니다.
AI 제품화 경험
모델 출력이 제품 안에서 검증되고·실패 시 회복되며·실제 실행까지 이어지는 구조를 중요하게 봅니다.
JSON contract·validator·retry/fixer로 학습 결과가 실행 가능한 시나리오로 이어지게 만듭니다.
PM과 UX 흐름
문제 정의·기능 우선순위·API 계약·화면 흐름·WBS·정책 문서를 정리합니다. 사용자가 지금 무엇을 해야 하는지를 화면 상태로 드러내고, FE/BE가 병렬로 움직이도록 조율합니다.
교육 / Education
인천대학교 임베디드시스템공학과
공학사 · 데이터구조 · 알고리즘 · 운영체제 · DB · 임베디드 기반
KB IT's Your Life 5기
Java · Spring · Vue · 금융 프로젝트 수행
SSAFY 14기
Java · Spring · Vue · AI 실전 개발
수상 · 자격 · 경험 / Awards
- KB IT's Your Life 종합실무 최우수상 : BeBig
- SSAFY 1학기 성적우수상 · 프로젝트 우수상 : Newstagram
- SSAFY 공통프로젝트 우수상 : A601
- SSAFY 자율프로젝트 우수상 : AutoQA
- Google Analytics Certification · OPIc IM3
- 양천구청 행정인턴 · INU 학습멘토링 봉사활동
6+대표 프로젝트
960hKB IT's Your Life 응용SW 교육
925hSSAFY 1학기 코딩 집중과정
5+수상 내역
Projects6 Project Index
03 / 26
Project Index
총 6개 프로젝트 · 백엔드 · 프론트엔드 · AI · 인프라 · PM
BeBig
금융 자산관리 서비스
GBCamera
현장 운영형 포토부스 자동화
Newstagram
AI 뉴스 큐레이션 서비스
Project A601
실시간 WebRTC 마피아 게임
용돈농장
청소년 금융 교육 백엔드
AutoQA
AI 기반 웹 QA 자동화 SaaS
Project 01BeBig · 금융 자산관리 서비스
04 / 26
01 · BeBig
실제 계좌 데이터를 소비 습관 개선 행동으로 연결한 금융 자산관리 서비스
BeBig은 사용자의 실제 계좌와 거래내역을 기반으로 총자산, 소비 흐름, 금융 성향, 미션을 제공하는 금융 자산관리 서비스입니다. 단순히 잔액과 거래 목록을 보여주는 데서 끝나지 않고, CODEF로 가져온 금융 데이터를 사용자가 오늘 수행할 수 있는 저축/소비 행동으로 번역하는 것을 목표로 했습니다. 저는 PM과 Frontend를 맡아 계좌 연결 UX, 대시보드, 거래내역 조회, 미션 흐름을 설계·구현하고 Backend의 CODEF 수집 구조를 함께 정리했습니다.
Vue 3
Pinia
Axios
Spring Boot
MyBatis
CODEF API
Chart UX
- Work 1CODEF 금융 데이터 활용 구조 설계
- Work 2사용자 친화적 UX 구현
01 BeBigWork 1 of 2
06 / 27
01 BeBig · Work 1
CODEF 금융 데이터 활용 구조 설계
Tech Stack
Vue 3 · Axios · Spring Boot · CODEF API · RSA 암호화 · 토큰 캐싱 · 금융 데이터 정규화 · MyBatis batch insert · 거래내역 중복 방지
상황 · Situation
실제 마이데이터 활용 기획 & CODEF API 도입
- BeBig은 Mock이 아니라 사용자의 실제 계좌·거래내역으로 자산을 분석하는 것을 목표로 기획했습니다.
- 이를 위해 마이데이터 연동이 가능한 CODEF API로 실제 금융 데이터를 끌어오기로 했습니다.
과제 · Task
복잡한 인증 파이프라인 & 제각각 응답 포맷 정리 필요
- 계좌 연결은 은행별 아이디·비밀번호 입력 → CODEF 연결 ID(토큰) 발급 → 그 토큰으로 다시 계좌·거래내역 요청으로 이어지는 다단계 흐름이었고, 필요한 정보가 API 명세서
곳곳에 흩어져 있었습니다. - 게다가 은행마다 응답 컬럼·날짜 형식·존재하는 필드가 모두 달라, 받은 데이터를 그대로는 자산 분석에 쓸 수 없었습니다.
행동 · Action
흩어진 연동 흐름 단일 파이프라인화 & 응답 표준 모델 정규화
- 흩어진 API 명세를 분석해 '은행 인증 → 연결 ID 발급 → 계좌 목록 조회 → 거래내역 조회'를 하나의 순차 파이프라인으로 정리했습니다.
- 연결 ID 보유 여부에 따라 신규 발급과 기존 ID에 은행 추가로 분기해 중복 발급을 막았습니다.
- 은행 비밀번호는 CODEF RSA 공개키로 암호화해 전달하고, 발급한 토큰은 만료시간과 함께 캐싱해 재사용했습니다.
- 은행마다 다른 응답에서 은행코드·계좌번호·계좌명·잔액·통화·계좌상태 등 필요한 필드만 추려 내부 계좌 모델로 변환했습니다.
- 거래내역은 거래일시·거래처·입출금·금액·잔액 기준으로 형식과 컬럼을 통일해 대시보드와 상세가 같은 의미의 데이터를 쓰게 했습니다.
- 거래일자+금액 기준 중복 판단과 batch insert로 같은 거래의 반복 저장을 막고, 거래내역 없는 계좌는 잔액 스냅샷을 생성해 빈 화면을 방지했습니다.
결과 · Result
- 은행마다 다르던 마이데이터를 서비스 표준 금융 데이터로 정규화해, 총자산·계좌 상세·소비 분석·미션 추천이 같은 데이터를 재사용하는 기반을 만들었습니다.
- 복잡한 외부 연동을 화면 전용이 아닌 서비스 전반에서 재사용 가능한 구조로 추상화했습니다.
01 BeBigWork 2 of 2
07 / 27
01 BeBig · Work 2
사용자 친화적 UX 구현
Tech Stack
Vue 3 · Pinia · Axios interceptor · computed grouping · infinite scroll · loading state · dashboard UX
상황 · Situation
정규화한 데이터도 이해 못 하면 행동으로 미연결
- 계좌·거래내역·금융 성향·미션·커뮤니티가 모두 모여 화면 정보량이 커질 위험이 있었습니다.
- 특히 계좌 연결은 외부 인증과 로딩이 길어 사용자가 진행 상태를 놓치기 쉬웠습니다.
과제 · Task
데이터를 즉시 판단·행동 가능한 화면으로 전환 필요
- 홈에서는 핵심 자산을 빠르게 보여주고, 상세에서는 긴 거래내역을 끊김 없이
탐색할 수 있어야 했습니다. - 계좌 연결·자산 확인·미션 수행이 따로 노는 기능이 아니라 하나의 행동 흐름으로
이어져야 했습니다.
행동 · Action
금융 상태와 사용자 행동 분리 & '현재 상태+다음 행동' 동시 노출
- 대시보드·은행 추가·인증·계좌 목록·상세·설문·미션을 목적별 페이지로 나누고 라우팅을 단순화했습니다.
- Pinia는 사용자·선택 은행·계좌 연결 진행 상태를, Axios 모듈은 서버 통신과 인증 헤더 처리를 담당하도록 분리했습니다.
- 계좌 연결 중에는 '계좌 확인 중 → 거래내역 요청 중 → 자산 분석 중' 단계별 로딩 메시지와
오류 횟수 안내로 긴 대기의 불안을 줄였습니다. - 홈 대시보드는 총자산·대표 계좌·계좌 연결 CTA·미션 요약을 한 화면에 배치해 현재 상태와
다음 행동이 같이 보이게 했습니다. - 계좌 상세는 현재 페이지·요청 중 상태·추가 데이터 여부를 분리해 무한 스크롤과 중복 요청 방지를 함께 처리했습니다.
- 거래내역은 computed 기반 날짜 그룹핑으로 묶고, 새로고침은 CODEF 재조회 후
최신 거래부터 다시 보여줘 갱신 감각을 제공했습니다.
결과 · Result
- 실제 금융 데이터가 총자산 인식 → 소비 확인 → 미션 수행으로 이어지는 핵심 UX를 완성했습니다.
- KB IT's Your Life 종합실무프로젝트에서 BeBig이 최우수상을 수상했습니다.
Project 02GBCamera · 포토부스 자동화
07 / 26
02 · GBCamera
촬영부터 무인 출력과 QR 공유까지 자동화한
촬영부터 무인 출력과 QR 공유까지 자동화한
현장 운영형 포토부스
GBCamera는 행사 현장에서 참가자가 직접 촬영·사진 선택·프레임 적용·출력·QR 다운로드까지 진행할 수 있도록 만든 포토부스 자동화 서비스입니다. 웹캠과 프린터를 제어해야 하는 운영 앱은 Electron으로 구성하고,
참가자 결과 확인은 모바일 웹으로 분리했습니다. 저는 기획·Frontend·Backend·Electron·배포·현장 운영을
모두 담당하며 브라우저 UI와 로컬 장치 제어·서버 저장·모바일 QR 공유 흐름을 하나로 연결했습니다.
React
Zustand
Canvas API
Electron
Spring Boot
MySQL BLOB
Vercel
EC2
- Work 1배포 운영
- Work 2Electron 무인 프린트
- Work 3수동 포토부스 자동화 기획
02 GBCameraWork 1 of 3
09 / 27
02 GBCamera · Work 1
배포 운영
Tech Stack
EC2 · Docker · Vercel Serverless Proxy · Spring Boot · MySQL LONGBLOB · SecureRandom index · QR · CORS/Mixed Content 대응
상황 · Situation
데스크톱 촬영 앱 & 사용자 모바일 조회의 환경 분리
- 현장 데스크톱 앱은 카메라·프린터 같은 로컬 장치를 제어하고, 참가자는 각자 휴대폰에서 결과 사진을 받아봐야 했습니다.
- 즉 하나의 촬영 결과가 데스크톱 → 서버 → 모바일로 안정적으로 이어지는 배포·연결 구조가 필요했습니다.
과제 · Task
앱·웹·서버 분리 배포 & 촬영 결과의 모바일 연결
- 중앙 서버·DB와 결과 조회 웹의 실행 환경을 나누고, 촬영 세션마다 고유 키로 저장·조회·QR을 묶어야 했습니다.
- HTTPS 모바일 웹이 HTTP 서버에 직접 접근하며 생기는 Mixed Content·CORS 문제를 운영 중 장애 없이 풀어야 했습니다.
행동 · Action
EC2·Vercel·프록시 역할 분리 배포 & QR 기반 결과 연결
- 중앙 서버와 DB는 EC2에서 Docker로 컨테이너화해 배포하고, 결과 조회 웹은 Vercel에 배포해 모바일 접근성과 서버 제어를 분리했습니다.
- HTTPS 결과 페이지가 HTTP EC2 백엔드와 통신할 때 생기는 Mixed Content·CORS는 Vercel Serverless 프록시를 두어 우회했습니다.
- 촬영 세션마다 SecureRandom 기반 URL-safe 식별자(index)를 생성하고 기본키 충돌 시 재시도하도록 했습니다.
- 이 index를 결과 페이지 URL로 만들어 QR로 변환하고, 최종 합성 이미지와 함께 DB에 저장해 저장·QR·조회의 공통 키로 사용했습니다.
- 결과 저장은 Base64를 바이너리로 변환해 MySQL LONGBLOB에 넣고, 조회 시 다시 Base64로 변환했습니다.
- 운영 앱과 모바일 웹은 환경에 따라 API base URL을 다르게 두어 로컬 테스트와 실제 운영을 분리했습니다.
결과 · Result
- 데스크톱 앱이 만든 촬영 결과가 서버에 저장되고, 참가자가 QR로 자기 모바일에서 바로 확인하는 배포·운영 흐름을 완성했습니다.
- 현장 네트워크와 배포 프로토콜 차이로 인한 모바일 조회 실패 가능성을 줄여 실제 부스 운영을 검증했습니다.
02 GBCameraWork 2 of 3
10 / 27
02 GBCamera · Work 2
Electron 무인 프린트
Tech Stack
Electron IPC · Preload bridge · BrowserWindow · silent print · deviceName · localStorage · Canvas image data URL
상황 · Situation
운영자 개입 없는 자동 출력 & 인쇄 다이얼로그 제거 필요
- 참가자가 촬영을 마치면 별도 조작 없이 출력까지 자연스럽게 이어져야 했습니다.
- 하지만 브라우저 기본 인쇄는 프린터 선택·매수·확인 다이얼로그가 떠 운영자 개입이 필요했습니다.
과제 · Task
다이얼로그 없는 자동 출력 & 웹 UI 내 프린터 제어
- 웹은 보안 정책상 로컬 프린터를 직접 silent 제어할 수 없었습니다.
- 최종 합성 이미지가 저장된 뒤 지정 프린터·매수로 조용히 출력되어야 했습니다.
행동 · Action
웹 UI의 Electron 앱 변형 & IPC로 UI·OS 인쇄 계층 분리
- 로컬 장치 제어가 가능한 Electron으로 기존 React 웹을 데스크톱 앱으로 패키징했습니다.
- Renderer는 Context Bridge로 노출된 electronAPI만 호출하고, Main Process가
프린터 목록 조회·인쇄 실행을 담당하도록 보안 경계를 나눴습니다. - IPC 채널로 프린터 목록 조회·이미지 인쇄 요청·결과 응답을 주고받았습니다.
- 선택한 프린터는 localStorage에 저장해 앱을 다시 열어도 설정을 재사용하게 했습니다.
- 최종 JPEG는 data URL 문서로 변환해 숨겨진 BrowserWindow에 로드하고, 로딩 완료 시점에 silent print·deviceName·copies 옵션으로 다이얼로그 없이 출력했습니다.
- Electron 환경이 아니거나 프린터가 없으면 출력만 건너뛰고 QR 공유는 유지해
부스가 멈추지 않게 했습니다.
결과 · Result
- 촬영 완료 후 참가자가 별도 조작 없이 인화물을 받는 무인 출력 흐름을 구현했습니다.
- 웹 UI의 편의성과 데스크톱 앱의 로컬 장치 제어 능력을 함께 활용했습니다.
02 GBCameraWork 3 of 3
11 / 27
02 GBCamera · Work 3
수동 포토부스 자동화 기획
Tech Stack
React Router · Zustand · MediaStream · Canvas crop · JPEG Blob · QR flow · photobooth service design
상황 · Situation
운영자 직접 촬영 → 품질 편차 & 인력 낭비
- 촬영을 사람이 직접 하다 보니 촬영자마다 결과물 품질 차이가 발생했습니다.
- 촬영·선택·편집·출력·공유 단계마다 운영자의 손이 필요해 인력 낭비가 심했습니다.
과제 · Task
촬영~QR 공유 셀프 자동화 여정 설계 필요
- 단순 촬영 자동화를 넘어, 진행 과정을 사용자가 실시간으로 확인할 수 있어야 했습니다.
- 출력물과 별개로 공유용 사진 데이터까지 본인 휴대폰으로 쉽게 받아갈 수 있어야 했습니다.
- 카메라 비율과 프레임 비율이 달라 결과물이 찌그러지지 않아야 했습니다.
행동 · Action
React 상태 흐름 & Canvas 합성 규칙 기반 셀프 자동 촬영
- React Router로 설정·촬영·선택·프레임·결과 화면을 나누고, Zustand에 스트림·이미지·프레임·세션 식별자를 저장했습니다.
- MediaStream을 video에 연결하고 6초 간격 타이머로 6장을 자동 캡처해 촬영 버튼 반복 입력을 없앴습니다.
- 촬영 중 미리보기를 실시간으로 보여줘 사용자가 진행 상태를 직접 확인하게 했습니다.
- Canvas에 object-fit cover 방식의 비율 계산을 적용해 다양한 웹캠 해상도에서도 프레임에 맞게 중앙 크롭했습니다.
- 전면 카메라는 캡처 단계에서 좌우 반전을 반영해 미리보기와 저장 결과의 방향을 맞췄습니다.
- 완성 이미지는 JPEG Blob·Base64로 변환해 서버 저장·Electron 출력·QR 조회가 같은 결과물을 쓰게 하고, QR로 본인 휴대폰 다운로드를 제공했습니다.
결과 · Result
- 약 50명을 대상으로 부스를 운영하며 자동 촬영·실시간 확인·프레임 합성·출력·QR 공유 흐름을 검증했습니다.
- 운영자 설명 의존도를 낮추고, 촬영자에 따른 품질 차이 없이 참가자가 스스로 촬영을 마칠 수 있게 했습니다.
Project 03Newstagram · AI 뉴스 큐레이션
11 / 26
03 · Newstagram
RSS 수집과 기사 임베딩으로 관심사 기반 뉴스를 제공한 AI 큐레이션 서비스
Newstagram은 여러 언론사의 RSS 기사를 자동 수집하고, 기사 임베딩과 클러스터링을 통해 실시간/일간/주간 이슈와 개인화 추천을 제공하는 뉴스 서비스입니다. 단순 키워드가 아니라 의미 기반 벡터를 사용해 비슷한 이슈와 사용자의 관심사를 연결했습니다. 저는 PM·Backend·Frontend를 담당하며 RSS 수집·Spring Batch/Quartz 자동화·기사 임베딩 저장·추천/검색 화면 연결까지 이어지는 데이터 파이프라인을 설계했습니다.
Spring Batch
Quartz
Rome RSS
Jsoup
PostgreSQL
pgvector
OpenAI Embedding
Kafka
- Work 1Batch · Quartz 자동화
- Work 2RSS 기사 수집
- Work 3기사 임베딩 파이프라인
03 NewstagramWork 1 of 3
13 / 27
03 Newstagram · Work 1
Batch · Quartz 자동화
Tech Stack
Spring Batch · Quartz · ThreadPoolTaskExecutor · chunk processing · Asia/Seoul scheduler · clustering trigger
상황 · Situation
지속 유입되는 뉴스 & 수동 수집의 신선도 한계
- RSS 수집·기사 임베딩·기간별 클러스터링이 정해진 시간에 자동으로 이어져야 했습니다.
- 외부 RSS와 임베딩 API는 실패 가능성이 있어 실행 결과를 추적할 수 있어야 했습니다.
과제 · Task
무거운 데이터 작업의 API 분리 & 일정 기반 안정 실행
- 수집과 임베딩을 한 작업으로 묶되 단계별 성공·실패를 따로 볼 수 있어야 했습니다.
- REALTIME·DAILY·WEEKLY 클러스터링은 실행 시점에 따라 다른 주기로 호출되어야 했습니다.
행동 · Action
Spring Batch 단계 분리 & Quartz 실행 시점 제어
- Batch Job을 RSS 수집 Step과 미임베딩 기사 처리 Step으로 분리해 수집 실패와 임베딩 실패를 독립 추적했습니다.
- ThreadPoolTaskExecutor로 언론사 source 단위를 병렬 처리하고, chunk를 source 단위로 잡아 한 언론사 실패가 다른 곳으로 번지지 않게 했습니다.
- Quartz는 Asia/Seoul 기준 실행과 중복 실행 방지로 이전 배치가 끝나기 전 같은 작업이
겹치지 않게 했습니다. - 수집·임베딩 완료마다 REALTIME 클러스터링을 호출하고, 0시에는 DAILY, 월요일 0시에는 WEEKLY를 추가 실행하도록 분기했습니다.
- 실행 상태·처리 건수·retry·error message를 로그로 남겨 어떤 단계에서 실패했는지 좁힐 수 있게 했습니다.
- 사용자 API와 배치 모듈의 책임을 분리해 뉴스 조회 요청이 대량 작업의 영향을 받지 않게 했습니다.
결과 · Result
- RSS 수집 → 기사 임베딩 → 기간별 핫 이슈 생성이 자동 실행되는 데이터 파이프라인을 구축했습니다.
- 실패 가능성이 높은 외부 데이터 작업을 사용자 기능과 분리해 서비스 안정성을 높였습니다.
03 NewstagramWork 2 of 3
14 / 27
03 Newstagram · Work 2
RSS 기사 수집
Tech Stack
Rome RSS · Jsoup · 언론사별 정규화 · URL unique constraint · ON CONFLICT DO NOTHING · 썸네일 추출
상황 · Situation
8개 언론사 RSS의 카테고리·품질 제각각
- 언론사마다 카테고리 체계와 본문·날짜·작성자 형식이 달랐고, 비어 있는 기사·중복 URL·추적용 이미지도 섞여 있었습니다.
- 수집 품질이 낮으면 이후 임베딩·클러스터링 품질, 나아가 서비스 품질까지
함께 떨어졌습니다.
과제 · Task
수집 단계 정규화로 저품질 원본 차단 필요
- 한 언론사 feed의 실패가 전체 수집을 멈추지 않도록 독립적으로 처리해야 했습니다.
- 모든 언론사를 똑같이 정규화하면 서로 다른 카테고리·형식 때문에 오히려 품질이 떨어지는 문제가 있었습니다.
행동 · Action
언론사별 맞춤 정규화 & 중복 방지 결합
- Rome으로 RSS XML을 feed·entry 단위로 파싱하고 각 feed를 독립 처리해 특정 언론사 실패가 전체로 번지지 않게 했습니다.
- 제목·설명·본문·URL·썸네일·작성자·발행일·언론사·카테고리를 내부 기사 모델로 변환했습니다.
- 공통 정규화 대신 언론사별로 불필요 문구·카테고리 매핑·본문 형식을 다르게 처리해 정규화 품질을 높였습니다.
- 썸네일은 enclosure → media RSS → 본문 img 순으로 탐색하고 pixel·beacon·tracking 이미지는 제외했습니다.
- Jsoup으로 HTML 태그를 제거하고 공백을 정리해 임베딩 입력 품질을 끌어올렸습니다.
- URL unique 제약과 conflict ignore로 이미 저장된 기사는 skip하고, inserted·skipped·errors로 결과를 기록했습니다.
결과 · Result
- RSS 원본을 서비스 내부에서 일관되게 쓸 수 있는 기사 데이터로 정리했습니다.
- 중복 URL과 품질 낮은 본문·이미지가 임베딩 단계로 넘어가는 비율을 줄여 이후 클러스터링 품질을 확보했습니다.
03 NewstagramWork 3 of 3
15 / 27
03 Newstagram · Work 3
기사 임베딩 파이프라인
Tech Stack
text-embedding-3-large · dimensions=1536 · pgvector vector(1536) · 모델 교체 호환 · batch embedding · response validation
상황 · Situation
의미 기반 클러스터링 위한 기사 임베딩 필요
- 수집한 기사를 의미적으로 묶어 클러스터링하기 위해 기사 임베딩을 도입했습니다.
- 사용자의 자연어 검색과 추천도 의미적으로 가까운 기사를 찾을 수 있어야 했습니다.
과제 · Task
임베딩 품질 향상 & 모델 교체 시 데이터 호환 문제 해결
- 초기 text-embedding-3-small은 성능이 부족해 더 나은 모델로 교체가 필요했습니다.
- 하지만 기존 기사들은 PostgreSQL vector(1536)로 저장돼 있어, 차원이 다른 모델로 바꾸면 불일치 에러가 났고, DB를 바꾸면 수집한 데이터를 전부 삭제해야 했습니다.
행동 · Action
모델 비교 후 large 교체 & 출력 차원 1536 고정으로 호환
- 여러 임베딩 모델을 테스트해 최종적으로 text-embedding-3-large로 교체했습니다.
- large의 기본 차원이 기존 vector(1536) 컬럼과 달라 발생하는 불일치를, dimensions=1536 옵션으로 출력 차원을 맞춰 해결했습니다.
- 덕분에 기존 수집 데이터를 삭제하지 않고도 모델을 교체하면서 임베딩 성능까지 끌어올렸습니다.
- embedding이 비어 있는 기사만 조회해 이미 처리한 기사에 대한 중복 비용을 줄였습니다.
- 정규화한 제목·본문을 결합하고 본문 길이를 제한해 API 입력 크기를 관리하며
batch로 묶어 호출했습니다. - 응답 개수와 입력 개수가 일치하는지 검증한 뒤 float 배열을 pgvector literal로 변환해 vector(1536) 컬럼에 저장했습니다.
결과 · Result
- 데이터 마이그레이션 없이 모델을 small → large로 교체하며 임베딩 품질을 개선했습니다.
- 1536차원 기사 임베딩을 pgvector에 저장해 의미 검색·자연어 검색·기간별 클러스터링의 핵심 데이터로 재사용했습니다.
Project 04Project A601 · 실시간 WebRTC 마피아
15 / 26
04 · Project A601
WebRTC와 WebSocket을 결합한
WebRTC와 WebSocket을 결합한
AI 판결 기반 실시간 마피아 게임
Project A601은 SF 세계관의 실시간 마피아 게임입니다. LiveKit WebRTC로 영상/음성 대화를 제공하고, STOMP WebSocket으로 방 상태·게임 페이즈·직업 능력·사망·AI 판결 결과를 동기화했습니다.
저는 PM과 Frontend를 맡아 게임 루프·반응형 인게임 UX·LiveKit 권한 제어·STOMP 이벤트 상태 관리를 설계했고, 특히 게임이 처음부터 끝까지 끊기지 않도록 서버 이벤트와 클라이언트 연출 사이의 완충 구조를 만들었습니다.
React
TypeScript
Zustand
LiveKit
WebRTC
STOMP
SockJS
Responsive Game UX
- Work 1PM·게임 루프 설계 및 몰입형 반응형 UX
- Work 2LiveKit WebRTC 권한 제어
- Work 3STOMP WebSocket · 상태관리
04 A601Work 1 of 3
17 / 27
04 Project A601 · Work 1
PM · 게임 루프 설계 및 몰입형 반응형 UX
Tech Stack
React · TypeScript · Zustand · state machine · ResizeObserver · responsive game board · stage transition UX
상황 · Situation
단계 전환 한 박자 어긋나면 몰입 붕괴
- 대기방·역할 공개·낮 토론·AI 판결·밤 능력·결과·엔딩이 서버 페이즈에 맞춰 진행되어야 했습니다.
- 모바일과 데스크톱에서 영상 타일·채팅·타이머·버튼·모달이 한 화면에 동시에 보여야 했습니다.
과제 · Task
서버 이벤트를 사용자 이해 가능한 단계 전환으로 번역
- 서버 페이즈는 즉시 바뀌지만, 클라이언트는 역할 공개·결과 연출 같은 완충 화면이 필요했습니다.
- 게임 상태와 UI 연출 상태를 분리해 갑작스러운 전환과 중복 렌더링을 막아야 했습니다.
행동 · Action
게임 단계의 상태 머신 모델링 & 반응형 스테이지 UX
- 전체 게임을 기획·설계하고, 단계를 lobby·role·morning·ai·judgment·night·result·ending으로 나눠 각 단계의 UI와 가능한 행동을 분리했습니다.
- 서버 GAME_PHASE 이벤트를 현재 stage·대기 stage·timerEnd·currentTurn 상태로 변환해 화면이 서버 이벤트를 직접 해석하지 않게 했습니다.
- GAME_START 직후 역할 공개 인트로를 먼저 보여주고 짧은 타이머 후 다음 stage로 넘겨 역할 확인 없이 게임이 시작되는 문제를 막았습니다.
- 역할별 색상·설명·능력 안내·생존/사망 상태를 UI variant로 분리해 같은 화면에서도 상태가 명확히 보이게 했습니다.
- 고정 기준 캔버스와 ResizeObserver 스케일링으로 모바일에서도 영상 타일·판결문·버튼이 겹치지 않게 했습니다.
- BGM·효과음·AI 판결 연출·타이핑 자막·글리치 효과를 stage 전환과 연결해 SF 세계관 몰입감을 강화했습니다.
결과 · Result
- 대기방부터 엔딩까지 끊김 없이 완주하는 게임 루프를 만들고, 서버 이벤트와 사용자 연출 사이 충돌을 줄였습니다.
- SSAFY 공통프로젝트에서 A601이 우수상을 수상했습니다.
04 A601Work 2 of 3
18 / 27
04 Project A601 · Work 2
LiveKit WebRTC 권한 제어
Tech Stack
LiveKit · WebRTC · local publish control · media publication · deviceId switching · remote audio subscription · dead-user guard
상황 · Situation
생존 여부·낮/밤 단계별로 달라지는 발화 권한
- LiveKit으로 영상·음성·채팅을 실시간 공유했지만, 대기방과 달리 인게임에서는 권한이 상황마다 달라야 했습니다.
- 밤이나 사망 상태에서는 특정 사용자만 서로의 영상·음성을 공유받을 수 있어야 했습니다.
과제 · Task
미디어 권한의 게임 규칙 일치 & 조작 우회 차단
- 프론트 화면 제어만으로 권한을 막으면 사용자가 조작으로 설정을 바꿀 수 있었습니다.
- 직업·생존 상태·페이즈에 따라 카메라·마이크·원격 오디오 구독을 다르게 제어해야 했습니다.
행동 · Action
LiveKit 미디어 전용 계층 & 서버 상태 기반 권한 제어
- 권한 제어를 프론트가 아닌 서버단에서 수행해 사용자가 클라이언트 조작으로 발화 권한을 바꿀 수 없게 했습니다.
- 입장 시 백엔드가 발급한 LiveKit URL·token으로 room에 join하고, 영상·음성 송수신은 LiveKit이 전담하게 했습니다.
- 직업·사망 상태·낮/밤 단계 조합으로 각 사용자가 서로 다른 미디어 환경에서 게임하도록 권한을 계산했습니다.
- 사망자가 되면 camera·microphone·screen share publish를 즉시 중단하고, 대기방·종료 시 복구했습니다.
- 원격 오디오 구독은 대화가 허용되는 stage에서만 활성화해 AI 판결·결과 연출 중 불필요한 음성이 섞이지 않게 했습니다.
- 영상 타일에 mute·speaking·ready·dead·role badge를 결합해 미디어 상태와 게임 상태가 한눈에 보이게 했습니다.
결과 · Result
- 영상·음성은 LiveKit으로 안정화하고, 게임 규칙에 따른 권한은 서버 상태 기반으로 제어하는 구조를 만들었습니다.
- 사망자 관전·밤 페이즈·AI 판결처럼 복잡한 상황에서도 미디어 권한이 게임 규칙과 일치하게 동작했습니다.
04 A601Work 3 of 3
19 / 27
04 Project A601 · Work 3
STOMP WebSocket · 상태관리
Tech Stack
STOMP · SockJS · topic subscription Map · Zustand slice · reconnect delay · event-driven UI · role action publish
상황 · Situation
전체 메시지 & 개인 메시지가 섞인 게임 이벤트
- 방 입장·준비·게임 시작·페이즈 변경·직업 능력·AI 결과·사망 처리가 실시간으로 동기화되어야 했습니다.
- 실시간성이 중요해 WebSocket으로 게임 상태·직업 정보를 받고 사용자 동작을 서버로 전송했습니다.
과제 · Task
직업별 수신 정보 구분 & 안정적 동기화
- 역할 정보와 밤 능력 결과는 개인에게만 전달되어야 해 전체 room 메시지와 분리할 필요가 있었습니다.
- 중복 구독·재연결·메시지 순서 차이로 인한 stage 꼬임을 줄여야 했습니다.
행동 · Action
전체·개인 토픽 분리 구독 & STOMP↔Zustand 해석 계층
- 직업별 정보 차이를 제어하기 위해 room 전체 topic과 개인 topic을 각각 구독해 받아야 할 정보만 받게 했습니다.
- SockJS 기반 STOMP 연결에 Authorization·roomId·입장 검증 정보를 header로 전달하고 reconnect delay로 일시 끊김에 대응했습니다.
- 구독 정보를 Map으로 관리해 같은 topic 중복 구독을 막았습니다.
- publish destination을 준비·게임 시작·AI 변론·직업 능력·방어·CCTV·처형 선택처럼 행동별로 나눠 서버 계약이 UI에 흩어지지 않게 했습니다.
- 수신 메시지는 GAME_PHASE·AI_RESULT·PLAYER_DEATH·ROLE_ASSIGNED 등 타입별로 상태를 갱신하되, GAME_PHASE는 stage·timer·turn을, AI_RESULT는 결과만 저장해 표시 시점은 stage 전환이 담당하게 했습니다.
- PLAYER_DEATH는 사망자 목록과 결과 상태를 갱신하고 LiveKit 권한 제어와 연결해 미디어 권한까지 반영했습니다.
결과 · Result
- WebRTC 미디어와 WebSocket 게임 이벤트를 분리하면서도 하나의 인게임 UX로 연결했습니다.
- 방 상태·개인 역할·페이즈·직업 능력 결과가 각 플레이어 화면에 맞게 반영되었습니다.
Project 05용돈농장 · 청소년 금융 교육 백엔드
19 / 26
05 · 용돈농장
부모와 자녀가 함께 금융 행동을 경험하는
부모와 자녀가 함께 금융 행동을 경험하는
청소년 금융 교육 백엔드
용돈농장은 부모가 관리하는 환경에서 자녀가 용돈·예금·적금·대출·일과 보상·신용점수를 경험하는 금융 교육 서비스입니다. 금융 행동이 단순 화면 상태가 아니라 거래 장부·상품 가입 상태·신용점수 이력으로 남도록 설계하는 것이 중요했습니다. 저는 Backend를 담당하며 DB 설계·도메인 모델링·QueryDSL 복잡 조회 API를 구현했고, 특히 부모-자녀 관계·상품 가입 가능 여부·신용점수·대출 상환 상태처럼 조건이 많은 도메인을 JPA와 QueryDSL로 정리했습니다.
Spring Boot
JPA
QueryDSL
PostgreSQL
JWT
OAuth2
Redis
SSAFY 금융 API
- Work 1DB 설계 · 도메인 모델링
- Work 2QueryDSL 복잡 조회 API 구현
05 용돈농장Work 1 of 2
21 / 27
05 용돈농장 · Work 1
DB 설계 · 도메인 모델링
Tech Stack
Spring Data JPA · @MapsId · @OneToOne · @ManyToOne · aggregate modeling · domain method · state transition
상황 · Situation
한 번의 행동이 여러 도메인 상태·이력에 영향
- 예금 가입·적금 납입·대출 승인·상환·일과 보상이 자녀 자산·신용점수·거래 이력에 함께 반영되어야 했습니다.
- 부모와 자녀는 같은 데이터를 봐도 권한과 행동 범위가 달라 관계 기반 설계가 필요했습니다.
과제 · Task
상태·이력·권한의 정규화 분리 필요
- 인증 정보와 자녀 금융 속성을 한 테이블에 섞으면 권한·도메인 정책이 복잡해질 수 있었습니다.
- 상품 마스터와 가입 상태를 분리해 상품 정책 변경과 가입 이력을 독립적으로 관리해야 했습니다.
행동 · Action
정규화 기반 연관관계 설계 & 도메인 메서드 캡슐화
- 공통 사용자 모델에 인증·프로필·역할을 두고, 자녀 모델은 같은 식별자를 공유하는
one-to-one으로 분리했습니다. - @MapsId로 사용자와 자녀 프로필의 식별자를 맞춰 인증 계층과 금융 도메인의 책임을 나눴습니다.
- 자녀는 부모와 many-to-one 관계를 갖고 용돈·지급일·신용점수·리뷰 점수·대출 금리 같은
금융 속성을 별도로 보유했습니다. - 예금/적금은 상품 마스터와 자녀 가입 엔티티를 분리해 조건·가입 상태·기간·금액·서명을
따로 관리했습니다. - 대출은 원금·금리·잔액·상태 모델과 상환 이력을 분리하고, 신용점수 변경 이력 테이블을
별도로 두어 추적 가능하게 했습니다. - 신용점수 보정·상환 검증·잔액 0원 완료 처리 등 상태 변경 규칙을 도메인 메서드로 캡슐화했습니다.
결과 · Result
- 부모-자녀 관계·상품·가입 상태·대출 상환·신용점수 이력을 추적 가능한 정규화된 모델로 구성했습니다.
- 금융 이벤트가 단순 상태 변경이 아니라 장부와 이력으로 남는 기반을 만들었습니다.
05 용돈농장Work 2 of 2
22 / 27
05 용돈농장 · Work 2
QueryDSL 복잡 조회 API 구현
Tech Stack
QueryDSL · JPAQueryFactory · Projection DTO · CaseBuilder · not exists subquery · composite cursor · fetch join
상황 · Situation
백엔드 CRUD 전반 담당 & 단순 CRUD로 풀기 어려운 조회
- 자녀 신용점수에 따라 상품 가입 가능 여부가 달라지고, 이미 가입 중인 상품은 목록에서 제외되어야 했습니다.
- 신용점수 이력·대출 거래 내역은 커서 페이지네이션과 동적 조건이 필요했습니다.
과제 · Task
복합 조건·정렬 처리 & 화면이 바로 쓸 응답 구성
- 메서드 이름 쿼리는 메서드가 과도하게 늘고, JPQL 문자열은 타입 안정성이 떨어졌습니다.
- 가입 가능 여부와 상품 ID로 정렬 기준이 복합이라 단순 ID 커서만으로는 안정적인 페이지 조회가 어려웠습니다.
행동 · Action
QueryDSL Custom Repository 분리 & 복합 커서·서브쿼리·Projection 설계
- 전체 백엔드 CRUD API를 구현하면서, 복잡 조회는 JPAQueryFactory 기반
Custom Repository로 단순 CRUD와 분리했습니다. - 상품 목록은 Projection DTO로 바로 조회하고, 자녀 신용점수와 상품 최소 신용점수를 비교하는 subquery로 가입 가능 여부를 계산했습니다.
- CaseBuilder로 가입 가능 상품을 우선 정렬하고 같은 그룹은 최신순으로 보여줬습니다.
- 현재 ACTIVE로 가입 중인 상품은 not exists subquery로 제외해 중복 가입을 막았습니다.
- 가입 가능 여부 커서와 상품 ID 커서를 함께 써 available → unavailable 그룹으로 넘어갈 때도 누락·중복을 줄였습니다.
- 신용점수 이력은 createdAt+ID 복합 커서를 쓰고 자녀 연관 정보를 fetch join해 N+1을 줄였습니다.
결과 · Result
- 가입 가능 상품 우선 정렬·중복 제외·커서 페이지네이션·이력 조회를 안정적으로 구현했습니다.
- 조회 책임을 QueryDSL로 분리해 화면 요구가 복잡해져도 API 응답 구조를 유지할 수 있게 했습니다.
Project 06AutoQA · AI 웹 QA 자동화
22 / 26
06 · AutoQA
웹 분석 결과를 실행 가능한 QA 시나리오로
웹 분석 결과를 실행 가능한 QA 시나리오로
바꾸는 AI 테스트 자동화 플랫폼
AutoQA는 URL을 분석해 웹 페이지의 액션 후보와 흐름을 추출하고, AI가 Playwright로 실행 가능한 QA suite JSON을 생성하며, 실제 브라우저 실행 결과를 리포트로 제공하는 플랫폼입니다. 핵심은 "그럴듯한 테스트 설명"이 아니라 validator와 실행기가 통과할 수 있는 구조화 JSON을 만드는 것이었습니다. 저는 PM과 AI 파트를 맡아 학습용 데이터셋 구축·SFT/DPO 학습·Qwen3-8B 기반 모델 개선·vLLM 추론 환경과 JSON 검증 구조를 설계했습니다.
Qwen3-8B
LoRA
SFT
DPO
vLLM
Guided JSON
Playwright
Validator
- Work 1AI 모델 학습용 데이터셋 구축
- Work 2SFT · DPO 학습 & 모델 개선
- Work 3추론 환경 개선
06 AutoQAWork 1 of 3
24 / 27
06 AutoQA · Work 1
AI 모델 학습용 데이터셋 구축
Tech Stack
SFT dataset · DPO negative pair · QA contract · strict JSON · nodeId whitelist · Playwright executable scenario
상황 · Situation
범용 LLM의 과도한 입출력 & Playwright 실행 구조 불일치
- 웹 분석 결과를 그대로 넣으면 입력 토큰이 너무 커지고 생성 출력도 길어, 실제 서비스 운영에서 토큰 비용을 감당하기 어려웠습니다.
- 생성된 결과도 Playwright가 바로 실행하기에는 구조에 차이가 있었습니다.
과제 · Task
직접 파인튜닝 결정 & 핵심 학습 데이터셋 구축
- 모델이 설명문이 아니라 정해진 실행 계약(contract)을 만족하는 JSON을 출력하도록 입력·출력 형식을 고정해야 했습니다.
- 좋은 예제뿐 아니라 실패 유형을 담은 negative pair도 필요했습니다.
행동 · Action
Playwright 양식 확정 & 실제 분석 결과의 실행 가능 데이터셋화
- 토큰·구조 문제를 풀기 위해 범용 LLM 대신 직접 파인튜닝하기로 결정하고, 가장 중요한 학습 데이터 생성에 집중했습니다.
- 먼저 Playwright 실행기가 소비할 QA suite JSON 양식(contract)을 확정해 정답 출력의 기준을 고정했습니다.
- 실제 페이지 분석을 수행해 site summary·analysis summary·action candidate·QA suite JSON을 모델 입력과 정답 출력으로 연결했습니다.
- self-generated·수작업 보강·teacher 모델 데이터를 합쳐 다양한 사이트·시나리오 유형을 포함하도록 구성했습니다.
- 시나리오 수·step type 다양성·unique nodeId 비율·reasoning 중복도·contract 위반 여부로 데이터 품질을 필터링했습니다.
- DPO rejected는 hallucinated nodeId·invalid click target·whitelist violation·
mode collapse처럼 실행 실패와 직결되는 유형으로 만들었습니다.
결과 · Result
- 139개 사이트에서 수집한 원본 QA 시나리오를 정제해 clean scenario와 DPO negative pair를 구축했습니다.
- 학습 기준을 자연어 품질이 아니라 validator 통과·실행 가능성으로 전환했습니다.
06 AutoQAWork 2 of 3
25 / 27
06 AutoQA · Work 2
SFT · DPO 학습 & AI 모델 개선
Tech Stack
Qwen3-8B · LoRA · QLoRA · SFT · DPO · gradient checkpointing · contract validation · mode collapse analysis
상황 · Situation
긴 입력·구조화 JSON 출력의 일반 호출 한계
- 초기 실험에서 긴 context로 인한 OOM·device map 문제·JSON truncation·특정 사이트 mode collapse가 발생했습니다.
- 모델은 nodeId·action type을 정확히 따라야 해 창의성보다 계약 준수가 중요했습니다.
과제 · Task
제한된 GPU 학습 & 실행 가능 QA JSON 성능 개선
- LoRA/QLoRA로 학습 비용을 줄이면서 JSON 구조와 QA 정책을 모델에 주입해야 했습니다.
- SFT 이후에도 반복되는 실패 유형은 DPO로 선호 방향을 조정해야 했습니다.
행동 · Action
모델 전환·LoRA 조정·SFT/DPO 학습·실행 중심 평가 반복
- Gemma 계열 LoRA 실험에서 긴 context OOM·multimodal device-map 리스크를 확인하고, 구조화 JSON에 더 적합한 Qwen3-8B로 전환했습니다.
- LoRA target을 language model projection 중심으로 제한하고 gradient checkpointing·KV cache off·sequence length 조정으로 메모리를 낮췄습니다.
- SFT에서는 scenarioId·category·priority·preconditions·steps·targetRef·expectedSignals 같은
QA contract 필드를 반복 학습시켰습니다. - DPO에서는 없는 nodeId·클릭 불가 대상·whitelist 위반·reasoning 중복·mode collapse를 rejected로 구성했습니다.
- validator pass rate·step 다양성·unique nodeId 비율·contract violation·parse 실패·truncation을 함께 평가했습니다.
- 추론 실패 사례를 다시 데이터셋으로 되돌리고 self-generated positive·수작업 예제를 보강하는 루프를 만들었습니다.
결과 · Result
- Qwen3-8B 기반 SFT/DPO 파이프라인과 실행 가능한 QA JSON 생성에 맞춘 개선 루프를 구축했습니다.
- Stage A SFT train loss 0.6776, Stage C DPO train loss 0.1680으로 수렴을 추적하고 실행 중심 지표로 품질을 관리했습니다.
06 AutoQAWork 3 of 3
26 / 27
06 AutoQA · Work 3
추론 환경 개선
Tech Stack
vLLM · LoRA adapter · prefix caching · guided JSON schema · token clamp · nodeId whitelist · validation fallback
상황 · Situation
운영 추론의 입력 길이·JSON 깨짐·잘못된 target 재발
- 웹 분석 요약은 사이트마다 크기가 달라 prompt token이 크게 흔들렸습니다.
- 한 번에 많은 시나리오를 만들게 하면 출력이 잘리거나 schema를 벗어났습니다.
과제 · Task
vLLM 추론 안정화 & validator 통과 suite 정규화
- 입력은 학습 때 형식과 맞추되 운영 환경의 길이 제한을 넘지 않아야 했습니다.
- 출력은 guided JSON으로 제한하고 후처리에서 nodeId·action target을
다시 검증해야 했습니다.
행동 · Action
전처리·vLLM 런타임·생성 오케스트레이션·검증 후처리 분리
- site/analysis summary를 학습 입력과 같은 구조로 압축하고 page·action candidate 수를 제한해 prompt 길이를 안정화했습니다.
- autoScenarioEligible·importance·confidence로 후보 우선순위를 정하고 form·container처럼 클릭이 항상 실패하는 후보는 입력 단계에서 제외했습니다.
- vLLM은 Qwen3-8B와 LoRA adapter를 로드하고 prefix caching·길이 기반 max token clamp로 처리량과 안정성을 조정했습니다.
- 생성은 category별 round로 나누고 한 round에 scenario 하나만 만들도록 guided JSON의 maxItems를 제한해 truncation을 줄였습니다.
- 출력 후 단일 scenario 추출·nodeId whitelist 검증·step 검증·matcher/signal 정규화·
중복 제거로 최종 suite를 조립했습니다. - 검증 실패 시 전체 실패 대신 재생성·보정·drop fallback을 적용해 남은 유효 scenario라도 제공했습니다.
결과 · Result
- 추론을 단순 텍스트 생성이 아니라 전처리·guided JSON·검증·fallback이 포함된 운영 파이프라인으로 개선했습니다.
- AI 생성 결과가 Backend validator와 Playwright 실행기로 넘어갈 수 있는 구조적 안정성을 확보했습니다.
Closing김용준 · 마무리
26 / 26
Closing
제가 반복해서 해온 일은
제가 반복해서 해온 일은
복잡한 흐름을 사용 가능한 제품으로
정리하는 것입니다.
BeBig에서는 금융 데이터를 행동으로, GBCamera에서는 현장 운영을 자동 흐름으로, Newstagram에서는 뉴스 데이터를 추천 파이프라인으로,
A601에서는 실시간 통신을 게임 규칙으로, 용돈농장에서는 금융 이벤트를 백엔드 도메인으로,
AutoQA에서는 AI 출력을 실행 가능한 QA 시스템으로 연결했습니다.
Backend 설계와 구현
Frontend UX 구현
AI 데이터/모델 파이프라인
PM 의사결정
제품 완성 경험