JEFFREY'S PORTFOLIO

DEV PORTFOLIO

SEONGWON YANG

Software Engineer

데이터 정합성과 시스템 성능을 함께 고려하는 개발을 지향합니다.

About Me

  • 이름
    양성원
  • 생년월일
    1999.11.06
  • 학력
    제주대학교 컴퓨터공학과연계전공: 빅데이터융합전공
  • 위치
    서울, 대한민국
  • 직무
    Software Engineer
  • 이메일
    ysw991106@gmail.com

Skills

languages

  • Java
  • TypeScript

frameworks& libraries

  • Spring Boot
  • JPA
  • NestJS
  • Prisma
  • Next.js
  • React
  • Tailwind CSS
  • Astro

DB& cache

  • PostgreSQL
  • Oracle
  • Redis

test& performance

  • JUnit
  • k6

infra& tools

  • Docker
  • Git
  • Github
  • Jira

Experience

Projects

TicketLab

동시성 제어와 캐시 최적화를 통해 예약 정합성과 고동시성 조회 성능을 개선한 티켓 예매 시스템

  • …

  • 동일 좌석 중복 예약 9건 → 0건

  • 좌석 조회 p95 51.0% 단축

  • 측정 기반 최적화 전략 선정

Documentation

README

Project

TicketLab

동시성 제어와 캐시 최적화를 통해 예약 정합성과 고동시성 조회 성능을 개선한 티켓 예매 시스템

GitHub
Role
백엔드 설계·구현 및 성능 테스트
Type
개인프로젝트
Period

Tech Stack

  • Java
  • Spring Boot
  • JPA
  • PostgreSQL
  • Redis
  • Docker
  • k6

한눈에 보기

예약 좌석 조회
문제 같은 좌석에 예약 10건 생성 고동시성 p95 504.67ms
선택 Pessimistic Lock Redis Cache-Aside
결과 중복 9건 → 0건 p95 504.67ms → 247.32ms

1. 기존 시스템 - Baseline

모든 읽기와 쓰기가 PostgreSQL에 집중된 구조

문제 측정 결과
Lock 없는 좌석 예약 100개 동시 요청에서 중복 9건
DB 직접 좌석 조회 1,000 VU에서 평균 334.72ms / p95 504.67ms

2. 전략 적용

예약 — Pessimistic Lock

동일 좌석에 요청이 집중되는 환경이므로, 충돌 후 실패하는 Optimistic Lock보다 먼저 접근을 직렬화하는 방식을 선택

선택 이유: 중복 예약을 막으면서 Optimistic Lock보다 평균 응답이 32.3% 빠름

후보 결과 판단
Optimistic Locking 중복 방지, 충돌 시 지연 증가 충돌이 적은 환경에 적합
Pessimistic Locking 중복 방지, 고경쟁에서 더 낮은 지연 티켓 예약에 채택

동일 좌석 요청을 DB Row Lock으로 직렬화해 한 요청만 예약에 성공하도록 설계

조회 — Redis Cache-Aside

반복되는 좌석 조회를 Redis가 우선 처리하도록 읽기 경로를 단축

변경 반영: 예약 Commit 후 캐시를 제거하고, Redis 장애 시 DB로 Fallback

후보 결과
Indexing SQL 실행 시간 90.2% 감소, API 전체 개선은 제한적
Redis 고동시성 환경에서 평균 응답·p95 모두 최저
Indexing + Redis Baseline보다 개선되었지만 Redis 단독보다 느림

3. 적용 효과

예약

1,000개 요청이 하나의 좌석을 동시에 예약한 결과

전략 중복 평균 p95
Baseline 9건 108.34ms 165.67ms
Optimistic 0건 148.27ms 240.82ms
Pessimistic 0건 100.38ms 185.73ms

중복 예약 제거 · Optimistic 대비 평균 32.3%↓ · p95 22.9%↓

좌석 조회

1,000 VU, 총 10,000회 조회 결과

전략 평균 p95
Baseline 334.72ms 504.67ms
Indexing 308.73ms 415.00ms
Redis 209.42ms 247.32ms
Indexing + Redis 230.82ms 344.01ms

평균 37.4%↓ · p95 51.0%↓ · 10,000회 조회 성공

복합 인덱스는 SQL을 3.591ms에서 0.352ms로 줄였지만, API 전체에서는 Redis의 개선 폭이 가장 컸음

4. 최종 설계

경로 설계 목표 결과
Write DB Lock으로 정합성 보장 좌석당 예약 1건
Read Cache로 반복 조회 흡수 고동시성 p95 51% 단축
실험 조건 및 관련 문서

실험 조건

  • 예약 정합성: JUnit, 100개 동시 스레드
  • 예약 성능: k6, 100 / 500 / 1,000 VU
  • 조회 성능: 1,000 VU, VU당 10회 조회, 좌석 100개
  • 쿼리 분석: PostgreSQL EXPLAIN ANALYZE

관련 문서

DevBrew

멘토 탐색부터 커피챗 예약·승인·1:1 실시간 채팅까지 연결한 개발자 멘토링 플랫폼

  • …

  • 예약 데이터 일관성 확보

  • 예약과 채팅 흐름 연결

  • 실시간 채팅의 영속성 확보

  • 분리 배포 환경 연결 안정화

Demo

DevBrew demo 1
1/5

Documentation

README

Project

DevBrew

멘토 탐색부터 커피챗 예약·승인·1:1 실시간 채팅까지 연결한 개발자 멘토링 플랫폼

GitHub
Role
풀스택 개발
Type
개인프로젝트
Period

Tech Stack

  • Next.js
  • NestJS
  • TypeScript
  • Prisma
  • PostgreSQL
  • Socket.IO

예약부터 대화까지, 한 번에 이어지는 개발자 멘토링

기존 멘토링 서비스의 무거운 참여 방식에서 벗어난 커피챗 기반 멘토링 서비스 구현

핵심 결과

흩어져 있던 다섯 단계를 하나의 서비스 흐름으로 완성했습니다.

  • 예약 일관성 — 하나의 시간에는 하나의 예약만 연결
  • 자동 연결 — 승인된 커피챗에는 채팅방이 자동으로 생성
  • 대화 보존 — 메시지는 저장된 뒤 전달되어 다시 접속해도 유지
  • 서비스 배포 — 프론트엔드, API, 데이터베이스를 분리

문제 해결

01. 중복 예약 차단

문제

동일한 시간에 여러 신청이 들어오면 예약 상태가 어긋날 수 있음

해결

슬롯 점유와 커피챗 생성을 하나의 트랜잭션으로 처리하고, timeSlotId에 고유 제약을 적용

결과

1개 슬롯 : 1개 커피챗 규칙이 화면 상태와 관계없이 유지 거절된 슬롯은 자동으로 다시 예약 가능한 상태로 변경

02. 저장과 실시간 전달을 일치

문제

화면에 보낸 메시지가 데이터베이스에 남지 않으면 대화 기록을 신뢰할 수 없음

해결

JWT로 소켓 연결 사용자를 확인하고, 채팅방 참여자만 룸에 입장하도록 검증

결과

실시간으로 받은 메시지와 다시 불러온 대화 내역이 동일하게 유지

03. 배포 환경의 소켓 연결 안정화

문제

로컬에서 동작하던 WebSocket 연결이 Railway 프록시 환경에서는 불안정

해결

  • CORS 허용 주소를 환경 변수로 분리
  • polling으로 연결한 뒤 WebSocket으로 전환
  • 소켓 생성과 실제 연결 시점을 분리

결과

Vercel과 Railway로 분리된 환경에서도 양방향 채팅이 올바르게 동작

사용자 흐름

시스템 아키텍처

REST API와 Socket.IO가 같은 도메인 서비스를 사용하고, 모든 영속 데이터는 Prisma를 통해 PostgreSQL에 저장

ERD

timeSlotId와 coffeeChatId에 고유 제약을 적용해 슬롯–커피챗과 커피챗–채팅방의 1:1 관계를 보장

구현 범위

  • 서비스 기획과 멘토·멘티 사용자 흐름 설계
  • 5개 데이터 모델과 관계·고유 제약 정의
  • 인증·멘토·슬롯·예약·채팅 API 구현
  • 역할별 9개 화면과 실시간 채팅 UI 구현
  • 프론트엔드·백엔드·데이터베이스 배포
상세 설계 문서 보기

SignaHand

  • 브라우저 기반 PDF 전 페이지 편집

  • 페이지 전환 간 편집 상태 동기화

  • 다중 페이지 PDF 재구성 및 다운로드

Demo

SignaHand demo 1
1/7

Documentation

README

Project

SignaHand

손동작으로 만든 서명을 PDF 페이지에 적용하고 다중 페이지 PDF로 내려받는 브라우저 기반 서명 프로토타입

GitHub
Role
프론트 개발 - PDF 렌더링, 서명 데이터 연동, ...
Type
팀프로젝트(4명: Design 1, Front 3)
Period

Tech Stack

  • React
  • TypeScript
  • Tailwind CSS

1. 프로젝트 개요

  • 웹캠 손동작으로 생성한 서명을 로컬 PDF에 적용하는 브라우저 기반 편집 프로토타입
  • PDF 업로드부터 페이지 렌더링·서명 적용·다중 페이지 PDF 다운로드까지의 클라이언트 처리

2. 담당 역할

  • 개인 담당: PDF 입력·페이지 렌더링·편집 상태 관리·다중 페이지 PDF 출력
  • 기능 통합: Canvas 출력과 팀의 Base64 서명 데이터·미리보기 연결
  • 팀 담당: MediaPipe 기반 손동작 인식·서명 생성·배치

3. 시스템 구조

주요 데이터 흐름

4. 핵심 구현 1 — 로컬 PDF를 편집 가능한 페이지 데이터로 변환

문제와 선택

  • react-pdf 기반 뷰어의 페이지 픽셀 접근·편집 결과 추출 제약
  • 렌더링 결과를 직접 제어하는 PDF.js·Canvas 조합 선택

구현

  1. URL.createObjectURL()과 getDocument()를 통한 로컬 PDF 로드
  2. 전 페이지의 Canvas 렌더링과 JPEG Data URL 변환
  3. { page, url } 형식의 PageContext 저장

결과

  • 편집기·미리보기가 공유하는 페이지별 입력 데이터 구성

관련 코드: PdfUploader.tsx, PdfDisplay.tsx, Loading.tsx

5. 핵심 구현 2 — 페이지 이동 후에도 편집 결과 유지

문제와 선택

  • 페이지 전환 시 Canvas 교체로 인한 편집 결과 소실
  • 편집기·미리보기가 공유하는 페이지별 스냅샷 방식 선택

구현

  1. pages에 편집본, origin에 초기 이미지 저장
  2. 페이지 이동 전 Canvas 직렬화와 updatePage() 갱신
  3. 동일 Context 기반 미리보기 동기화·현재 페이지 초기화

결과

  • 페이지 이동 이후에도 유지되는 편집 결과와 미리보기 구성

관련 코드: PageContext.tsx, PreviewDisplay.tsx

6. 핵심 구현 3 — 단일 Canvas 저장을 다중 페이지 PDF 출력으로 확장

문제와 선택

  • 현재 Canvas를 PNG 한 장으로 저장하는 초기 출력 범위
  • 전체 페이지를 재구성하는 jsPDF 출력 방식 선택

구현

  1. 팀의 Base64 서명 이미지와 PDF Canvas 연결
  2. 편집 결과 직렬화와 전체 페이지 스냅샷 수집
  3. jsPDF addImage()·addPage() 기반 PDF 생성
  • 개인 구현: 서명 데이터 연결·페이지 상태·PDF 출력 통합
  • 팀 구현: 서명 위치 계산과 Canvas 배치

결과

  • 단일 페이지 PNG 저장에서 다중 페이지 PDF 다운로드로 확장

관련 코드: PdfDisplay.tsx

7. 프로젝트 결과

  • 로컬 PDF 입력부터 렌더링·편집 상태 유지·다중 페이지 PDF 출력까지의 브라우저 처리 흐름 구성
  • 팀의 손동작 서명 결과와 개인 담당 PDF 처리 파이프라인 통합

퍼스널TEA(SW공동해커톤)

  • …

  • 선택지 기반 5단계 허브 추천 흐름 설계

  • 7개 화면 라우팅 및 공통 UI 컴포넌트 구조화

Demo

퍼스널TEA(SW공동해커톤) demo 1
1/7

Documentation

README

Project

퍼스널TEA(SW공동해커톤)

날씨 기반 반려식물 케어와 커뮤니티, 허브 취향 추천을 연결한 웹 서비스

GitHub
Role
개발 리드, 프론트 개발
Type
팀프로젝트(5명: Design 1, Front 2, Back 2)
Period

Tech Stack

  • React
  • JavaScript
  • Tailwind CSS
  • daisyUI

1. 프로젝트 개요

  • 날씨 정보, 반려식물 커뮤니티, 허브 취향 추천을 결합한 3일 해커톤 웹 서비스
  • 일반·Q&A 게시글, 내 게시글, 로그인·회원가입, 날씨 정보, 5단계 허브 취향 테스트로 구성

2. 담당 역할

  • 개인 담당: React 초기 설정·홈 화면·공통 UI·라우팅·허브 취향 테스트
  • 화면 통합: 홈·마이피드·설문을 공통 Banner·Board·Card 컴포넌트로 연결
  • 팀 담당: 게시글·사용자 API 연동, Spring Boot API·JPA·PostgreSQL·Docker 구성

3. 구현 1 — 질문·점수·결과를 연결한 5단계 허브 추천

문제와 선택

  • 5개 질문, 질문별 4개 선택지, 허브별 누적 점수, 진행률, 결과 화면을 하나의 흐름으로 연결해야 하는 문제
  • 질문별 페이지를 분리하는 대신 단일 React 컴포넌트에서 단계와 점수를 관리하는 방식 선택

구현

  1. currentStep으로 현재 질문과 20% 단위 진행률 관리
  2. 선택한 열에 대응하는 민트·카모마일·로즈마리·라벤더 점수 누적
  3. 마지막 응답에서 최고 점수를 계산하고 추천 결과 화면으로 전환

결과

  • 5개 질문·20개 선택지·4종 추천 결과를 별도 API 없이 브라우저에서 처리

4. 구현 2 — 7개 화면을 연결한 라우팅·공통 UI 구조

문제와 선택

  • 짧은 기간에 홈·마이피드·글쓰기·소개·인증·설문 화면이 추가되며 공통 UI 중복과 통합 충돌이 커지는 문제
  • 화면은 containers, 재사용 UI는 components로 분리하고 React Router로 연결하는 구조 선택

구현

  1. BrowserRouter와 Routes를 이용해 7개 화면 경로 구성
  2. Banner·BannerButton·Board·Card를 페이지에서 조합할 수 있는 컴포넌트로 분리
  3. Router의 Link와 공통 스타일을 결합한 NavLink로 내비게이션 통합

결과

  • 홈·마이피드·설문이 공통 UI를 공유하고 팀원의 데이터 조회 로직을 연결할 수 있는 화면 구조 구성

5. 프로젝트 결과

  • 5단계 질문부터 허브 추천 결과까지 이어지는 클라이언트 처리 흐름 구현
  • 7개 화면과 공통 UI를 연결해 팀 기능을 통합할 수 있는 React 화면 구조 구성

제대로 먹젠(카카오 현장실습)

  • …

  • 지도 SDK·다중 마커 기반 위치 탐색

  • 공통 JSON 기반 무서버 추천 데이터 구축

  • Jira·Agit·GitHub 기반 협업 및 지식 관리

Demo

제대로 먹젠(카카오 현장실습) demo 1
1/4

Documentation

README

Project

제대로 먹젠(카카오 현장실습)

교내 위치와 이동 시간을 기준으로 음식 종류와 주변 식당을 추천하는 제주대학교 학생 대상 모바일 웹 서비스

GitHub
Role
팀장, 프론트 개발
Type
팀프로젝트(5명)
Period

Tech Stack

  • React
  • JavaScript
  • Kakao Maps JavaScript SDK
  • GitHub Pages
  • GitHub Wiki
  • Jira
  • Agit

1. 프로젝트 개요

  • 교내 위치와 이동 가능 시간을 입력하면 도보 범위의 식당을 지도에 표시하는 제주대학교 학생 대상 서비스
  • 음식 종류와 식당을 두 번의 룰렛으로 좁히고, 비선호 결과는 제외한 뒤 다시 추천하는 5단계 흐름
  • React SPA에서 지도·추천·결과 확인을 처리하고 GitHub Pages에 정적 배포

2. 담당 역할

  • 개인 담당: Kakao Maps SDK 초기 연동·지도 중심/줌 제어·다중 마커 원형·초기 식당/건물 데이터 구축
  • 협업 운영: Jira Kanban·Agit Daily Scrum·GitHub Wiki Ground Rule 및 회의 기록
  • 팀 통합: 개인 지도 원형과 팀의 거리 필터·룰렛·결과 화면 연결
  • 팀 담당: 최종 거리 계산·추천 상태 전이·룰렛·Kakao Share와 결과 화면

3. 시스템 구조

주요 데이터 흐름

data-flow

  • 별도 API 서버·DB 없이 건물·식당 JSON을 브라우저 번들에 포함
  • Kakao Maps JavaScript SDK로 지도·마커·인포윈도우 처리
  • MainPage의 단계 상태를 기준으로 지도와 룰렛 화면 전환

4. 핵심 구현 1 — React에서 Kakao Maps와 다중 마커 제어

문제와 선택

  • Kakao Maps SDK의 명령형 Map·LatLng·Marker 객체와 React의 선언형 렌더링 방식 차이
  • DOM 컨테이너가 준비된 이후 useEffect에서 지도와 마커를 생성하는 방식 선택

구현

  1. HTML 진입점에 Kakao Maps SDK를 연결하고 제주대 중심 좌표·지도 레벨 설정
  2. JSON 좌표를 kakao.maps.LatLng 객체로 변환
  3. 마커 이미지·위치·생성을 함수로 분리
  4. 교내 건물 좌표 배열을 순회해 다중 마커 렌더링

결과

  • 초기 74개 교내 건물 좌표를 지도에 표시하는 다중 마커 원형 구축
  • 지도 중심 이동·줌 레벨·마커 표현을 후속 조건별 지도 기능의 기반으로 제공

관련 코드: KaMap.jsx

5. 핵심 구현 2 — 서버·DB 없는 추천 데이터 기반 구축

문제와 선택

  • 지도·룰렛·결과 화면이 함께 사용할 식당명·주소·분류·좌표·Kakao Map 정보 필요
  • 4주 프로젝트에서 API 서버와 DB를 추가하기보다 검수한 JSON을 번들에 포함하는 방식 선택

구현

  1. 식당 조사 자료를 RES_ID·RES_NAME·RES_ADDR·RES_GB·RES_URL 구조로 변환
  2. 교내 건물을 building_id·building_name·building_lat·building_lng 구조로 정리
  3. 식당 48개·교내 건물 74개의 초기 데이터셋을 Git으로 관리
  4. 팀 통합 과정에서 식당 좌표를 추가해 거리 필터 입력으로 확장

결과

  • 동일한 입력에서 같은 추천 후보를 만드는 재현 가능한 클라이언트 데이터 기반 확보
  • 지도는 좌표, 룰렛은 분류·식당명, 결과 화면은 Kakao Map 정보를 같은 데이터 흐름에서 사용

관련 코드: restaurant.json, building.json

6. 핵심 구현 3 — 협업 과정을 추적 가능한 지식 자산으로 전환

문제와 선택

  • 5명이 짧은 기간에 기획 변경·역할 조정·기능 통합을 반복해 구두 합의만으로는 결정 배경이 소실
  • Jira는 작업 상태, Agit은 빠른 공유, GitHub Wiki는 규칙·회의·의사결정 보존에 사용

구현

  1. Jira에서 업무를 TODO→DOING→DONE으로 구분해 담당 업무와 팀 진척도 공유
  2. Daily Scrum 전 done·to do·share를 정리하고 Agit으로 일정·이슈 변경 전파
  3. GitHub Issue의 dev·bug·meeting 라벨과 브랜치·커밋 규칙 수립
  4. Ground Rule·Daily Meeting·Weekly Review·기획 변경 이력을 GitHub Wiki에 기록

결과

  • 기획부터 역할·회의·협업 규칙까지 다시 확인할 수 있는 프로젝트 기록 구축

관련 문서: Github Wiki

7. 프로젝트 결과

  • 현재 팀 데이터 기준 교내 위치 75개·식당 50개·음식 분류 13개를 활용한 5단계 추천 흐름 구성
  • Kakao Map의 위치 탐색과 음식·식당 룰렛을 결합해 선택지 탐색부터 최종 결과 확인까지 연결
  • 지도 SDK·초기 데이터·협업 문서라는 개인 담당 범위를 코드 커밋과 Wiki 이력으로 검증
  • 기존 카카오 ICT 인턴십 포트폴리오 PDF의 지도 제어·Jira·Agit·Wiki 역할을 현재 저장소 근거와 교차 확인

Career

SI 개발 · 프리랜서

제주은행 차세대 프로젝트 - 여신 파트

㈜인포마인드

  • 약 400개 여신 UI를 차세대 계정계 환경으로 전환

    • 기존 정보계 화면의 레이아웃과 JavaScript 로직을 차세대 표준에 맞게 재구성하고 오류·중복 코드를 개선해 기존 기능의 동일 동작 검증

  • 연동 진행 상황과 무관한 전체 화면 검증 환경 구성

    • 화면별 송수신 데이터 포맷을 MCI에 등록하고 실제 연동 데이터와 DB 임시 데이터를 활용해 전체 화면의 데이터 흐름과 이관 결과 검증

  • 화면부터 SQL까지 추적해 데이터 정합성 확보

    • AS-IS·TO-BE 조회 결과를 비교하고 JavaScript, MCI, C 서버 로직, Oracle SQL을 단계적으로 추적해 조회 조건과 데이터 처리 오류 수정

Documentation

README

Career

제주은행 차세대 프로젝트 - 여신 파트

㈜인포마인드

Role
SI 개발 · 프리랜서
Period

Tech Stack

  • JavaScript
  • Oracle
  • xFrame
  • C

약 400개 여신 UI를 정보계에서 계정계로 이관하고, 화면부터 SQL까지 추적해 데이터 정합성을 확보했습니다.

핵심 성과

결과 기여
약 400개 UI 이관 차세대 표준 가이드에 맞춰 레이아웃과 JavaScript 로직을 계정계 환경으로 전환
이관 데이터 정합성 확보 AS-IS·TO-BE 화면 데이터를 비교하고 불일치 원인을 분석해 수정
여신 서비스 안정화 JavaScript, MCI, C 서버 로직, Oracle SQL까지 전 구간을 추적해 오류 발생 지점을 식별

AS-IS → TO-BE: 정보계 화면을 계정계로 이관

기존 정보계 여신 화면 약 400개를 차세대 표준에 맞는 계정계 화면으로 전환하고, 이관 전·후 조회 결과가 같은지 검증했습니다.

구분 이관 작업 완료 기준
화면 차세대 표준 가이드에 맞춰 레이아웃 전환 계정계 화면에서 정상 동작
로직 JavaScript 오류 수정 및 중복 코드·반복문 개선 기존 기능과 동일하게 동작
인터페이스 화면별 송수신 데이터 포맷을 MCI에 등록 단말과 서버 간 데이터 송수신 확인
데이터 AS-IS·TO-BE 화면의 조회 결과 비교 이관 전·후 데이터 일치
대외 연동 완료 화면은 실제 연동, 미완료 화면은 DB 임시 데이터로 테스트 연동 상태와 관계없이 화면 검증

데이터 불일치 해결

화면 오류를 UI 문제로 한정하지 않고, 데이터 흐름 전체를 단계별로 좁혀 원인을 찾았습니다.

해결 결과

  • 데이터가 달라지는 지점을 화면·인터페이스·서버·DB 구간 중 하나로 특정
  • 서버 로그와 C 로직의 실행 흐름을 확인해 잘못된 분기 가능성 검토
  • 원장 조회 SQL을 분석해 조회 조건과 데이터 처리 오류 수정
  • 분석 내용을 관련 담당자에게 공유하고 해결 방법을 검토한 뒤 재검증

오류 유형별 점검 항목

구간 점검 항목
화면 JavaScript 코드, 입력값, 이벤트 처리
인터페이스 단말과 서버가 주고받는 MCI 데이터 포맷
서버 로그, C 로직의 분기와 데이터 처리 과정
DB 테스트 데이터 존재 여부, Oracle SQL과 조회 조건

Contact

Emailysw991106@gmail.com