조치호 | 백엔드 개발자 포트폴리오

💼 프로젝트

CalmDesk 팀 프로젝트 이슈 관리자

2026.01.06 - 2026.02.27 · 5인 Full Stack · Code808

WebSocket·SSE 기반 실시간 데이터 스트리밍과 멀티테넌시 아키텍처를 통한 기업 간 완전한 데이터 격리를 구현한 기업용 B2B HR·웰빙 SaaS 통합 관리 플랫폼.

아키텍처 및 주요 API

Architecture
React ➡️ Nginx ➡️ Spring Boot API ➡️ Redis Cache ➡️ MySQL
Key API
GET /api/admin/team/members (관리자 팀 멤버 현황 조회 API)
PUB /pub/chat/message (WebSocket 실시간 그룹/개인 채팅 메시지 발송)

본인 담당 기능

실시간 채팅
WebSocket(STOMP) 기반 1:1 / 그룹 채팅 및 커스텀 인터셉터 활용 소켓 연결 JWT 인증 로직 적용
직원 대시보드
개인 업무 통계·정서 지수 요약 데이터 조회 및 실시간 현황 화면
출퇴근 로직
출근·퇴근 시 관리자 대시보드 통계 갱신 로직을 @Async 비동기 이벤트로 분리하여 직원용 출퇴근 API 응답 지연 방지
협업 체계 구축
Git 커밋 컨벤션(feat/fix/refactor 등) · 이슈 · PR 템플릿 도입으로 리뷰 소요 시간 30% 단축 및 병합 충돌 발생 빈도 감소. 팀 배포 주기 단축에 기여

주요 트러블슈팅

[근본 병목 개선] 애플리케이션 비효율로 인한 EC2 CPU 크레딧 고갈 대응 및 인프라 병목 해결

1) 문제의 발단 (현상 및 인프라 병목)

EC2 운영 환경에서 관리자 팀 멤버 현황 조회 API(GET /api/admin/team/members) 호출 시 25초의 심각한 지연 및 AWS EC2(T3 Micro) CPU 크레딧 고갈(스로틀링) 현상을 확인했습니다.

2) 해결 및 1차 결과 (단일 응답 최적화)

과부하 원인을 추적한 결과, 직원 데이터 조회 중 발생한 N+1 쿼리 구조(조회 시 150개의 추가 단건 쿼리 발생)를 확인했습니다. JPA의 @Query JOIN FETCH와 Bulk IN 쿼리를 활용해 150개의 단건 쿼리를 3회의 벌크 쿼리로 통합했고, 연산 부하를 줄여 EC2 인스턴스 지표 정상화 및 단일 응답 기준 0.9초 복구를 달성했습니다.

3) 최종 검증 (다중 접속 부하 테스트)

이러한 단일 응답 최적화 로직이 다중 접속 환경에서도 부하를 견딜 수 있는지 k6 부하 테스트(50 VUs)로 교차 검증했습니다. 그 결과, 동시 접속 환경에서도 응답 지연은 377ms에서 101ms로 73% 단축되었고, 초당 처리량(RPS)은 14% 향상된 것을 확인했습니다.

k6 Load Test Profile (50 VUs)

⏱️ 응답 지연 (P95)
377.19ms 101.01ms (73%↓)

🚀 초당 처리량 (RPS)
30.65 req/s 35.01 req/s (14%↑)

최적화 전 (Before)

최적화 후 (After)
JWT와 프론트엔드 통신 403 오류 해결

1) 문제점 및 원인 분석

부서·근태 내역 조회 시 403 오류가 반복 발생했습니다. 원인이 백엔드·프론트 양쪽에 분산되어 있어 특정하기 어려웠습니다.

2) 개선/해결 방안

프론트엔드 로컬 스토리지 키 불일치(token vs authToken)와 공통 Axios 인스턴스를 거치지 않고 Axios를 직접 import한 문제를 교차 분석해 원인을 특정했습니다.

3) 결과/성과

키 이름 통일 및 공통 Axios 인스턴스 사용으로 수정 후 403 오류를 해소했습니다.

기술 스택

Back-end

Java 17 Spring Boot Spring Security JPA WebSocket SSE

AI / External

Spring AI OpenAI API Google Cloud STT

Front-end

React 19 Zustand Axios

DB / Cache

MySQL Redis

Infra / DevOps

Docker GitHub Actions AWS EC2 Nginx

협업 및 개발 프로세스

GitHub Project 칸반보드를 활용한 이슈 기반 개발
Issue → Branch → PR 구조로 작업 관리
담당자 지정 및 작업 상태(이슈/PR 생성 / 작업 중 / 작업 완료 / 문제 발생) 관리로 팀원 간 개발 진행 상황을 한눈에 파악

참여 소감

잘된 점 커밋 컨벤션·이슈 템플릿 등 협업 체계를 직접 설계해 팀 전체에 적용한 점, N+1 구조적 결함을 데이터 흐름 관점에서 근본적으로 분석하고 리팩토링으로 해결한 점

아쉬운 점 헤더 채팅 알림 기능에 단방향 SSE가 아닌 상대적으로 무거운 WebSocket을 사용한 점

보완할 점 경량 SSE 방식으로 단방향 알림 구조를 분리해 서버 자원 효율을 높이는 방향으로 개선 예정

Cubing Hub 개인 프로젝트 1인 풀스택 · 배포 완료

2026.03.23 - 2026.04.24 · 1인 Full Stack

큐빙 기록·학습·랭킹·커뮤니티·피드백을 하나의 서비스 흐름으로 통합한 스피드큐빙 풀스택 웹 플랫폼.
화면 구현에 그치지 않고 인증, API 계약, DB 모델, 테스트 자동화, REST Docs, 성능 비교, AWS 배포와 운영 검증까지 서비스 단위로 완성했습니다.

아키텍처 및 운영 URL

Frontend
React ➡️ Vite ➡️ AWS S3 ➡️ CloudFront
Backend
Nginx ➡️ Spring Boot API ➡️ Redis / RDS MySQL
Production
www.cubing-hub.com / api.cubing-hub.com

구현 기능 및 기술적 결정

인증/인가 메모리 Access Token, HttpOnly Refresh Cookie, Redis Refresh Token Rotation, Access Token blacklist로 세션 무효화 흐름 구현
기록/랭킹 타이머 기록 저장, PB/Ao5/Ao12 계산, penalty 수정/삭제, Redis ZSET 기반 랭킹 읽기 모델 구현
서비스 기능 홈 대시보드, 마이페이지, CFOP 학습, 커뮤니티 CRUD, 공개 Q&A, 관리자 피드백 답변/공개 전환 구현
품질 기준 JUnit 5/MockMvc API 검증, Testcontainers 통합 테스트, Spring REST Docs, JaCoCo/Vitest 커버리지 검증, backend/frontend 분리 CI 구성

주요 트러블슈팅

[성능 개선] MySQL 랭킹 조회 병목을 Redis ZSET 읽기 모델로 분리

1) 문제점 및 원인 분석

PB 랭킹을 MySQL user_pbs 기준으로 직접 조회하는 V1 구조에서 대량 데이터 기준 응답 시간이 길어졌다. 300,000 PB 기준으로 GET /api/rankings 평균 응답 시간이 7,245.23ms, p95가 12,429.58ms까지 증가했다.

2) 개선/해결 방안

MySQL의 records, user_pbs를 기준 데이터로 유지하되, 기본 랭킹 조회는 Redis ZSET 읽기 모델로 분리했다. 기록 생성/수정/삭제로 PB가 바뀌면 Redis 랭킹도 함께 동기화하고, 닉네임 검색이나 Redis가 준비되지 않은 상태에서는 MySQL 대체 경로를 사용하도록 구성했다.

3) 결과/성과

동일 k6 시나리오에서 평균 응답 시간은 7,245.23ms → 21.10ms, p95는 12,429.58ms → 36.94ms로 감소했다. 요청 처리율은 4.21 req/s → 1,502.77 req/s로 증가했고, 개선 전후 모두 실패율은 0.00%였습니다.
[운영 품질] 테스트, 문서화, 배포 검증을 프로젝트 완성 기준으로 고정

1) 문제점 및 원인 분석

개인 프로젝트가 화면 구현에만 머무르면 API 계약, 인증 실패 흐름, 외부 연동, 배포 후 동작 검증이 포트폴리오에서 설명 가능한 수준으로 남지 않는다.

2) 개선/해결 방안

JUnit 5/MockMvc 기반 API 검증, Testcontainers 통합 테스트와 Spring REST Docs를 연결하고, backend/frontend CI를 분리했다. SMTP, S3, 관리자 화면, 공개 Q&A 같은 운영 경로도 테스트와 수동 QA로 확인했다.

3) 결과/성과

최종 검증에서 backend JaCoCo instruction/branch 기준 누락 0건, frontend Vitest statements/branches/functions/lines 100%를 확인했다. 운영 환경에서는 실제 SMTP 송수신, S3 업로드/삭제, 핵심 사용자 기능과 관리자 기능 수동 검증을 완료했다.

기술 스택

Back-end

Java 17 Spring Boot 3.5.12 Spring Security JPA QueryDSL

Front-end

React 19 Vite 8 React Router 7 Axios Recharts

DB / Cache

MySQL 8 Redis 7

Infra / DevOps

AWS S3 AWS CloudFront AWS EC2 AWS RDS Nginx Docker Compose GitHub Actions

Testing / Quality

JUnit 5 MockMvc Spring REST Docs Testcontainers k6 JaCoCo Vitest

External / Ops

SMTP Discord Webhook Spring Boot Actuator

Observability

Prometheus Grafana

참여 소감

잘된 점 1인 프로젝트지만 인증, DB, Redis, 테스트, 문서화, 배포, 운영 검증까지 실제 서비스 단위의 마감 기준을 세우고 끝까지 마무리한 점

아쉬운 점 랭킹 닉네임 검색은 아직 MySQL 대체 경로를 사용해 Redis secondary index 확장 여지가 남아 있는 점

보완할 점 운영 Redis 재구축 정책과 실서비스 스모크 검증 자동화를 후속 운영 과제로 분리

MediFlow 팀 프로젝트 DB 관리자

2025.10.23 - 2025.11.19 · 6인 Full Stack · W3C

수기·엑셀 기반 병원 관리의 비효율을 해결하기 위한 통합 병원 ERP 시스템.
예약, 진료, 근태 관리를 포함한 병원 운영 전 영역을 디지털화한 프로젝트입니다.

아키텍처

Architecture
JSP / JSTL ➡️ Spring Boot API ➡️ Oracle DB

본인 담당 기능

DB 모델링 및 설계
ERD 설계부터 CONSTRAINT FK_..., CONSTRAINT CHK_STATUS CHECK (STATUS IN ('Y', 'N', 'R')) 등 데이터베이스 단의 무결성 검증 설정 주도
쿼리 최적화
Oracle LISTAGG(name, ',') WITHIN GROUP (ORDER BY id) 및 서브쿼리 활용으로 데이터 병합 과정의 N+1 문제 해결. View 도입으로 비즈니스별 복잡한 Join 성능 향상 및 SQL 복잡도 감소
근태 자동화
LocalTime API로 출결 상태(정상/지각/조퇴/결근) 자동 판별 로직 구현

주요 트러블슈팅

[리팩토링] 데이터 무결성 확보 및 DB 병합 충돌 해결

1) 문제점 및 원인 분석

로컬 환경 개발 시 상태값 검증 기준(A 개발자는 '1,2,3', B 개발자는 'Y,N,R' 기반)이 통일되지 않아 DB 병합 시 지속적인 데이터 충돌 및 정합성 오류가 발생했습니다. 문제 원인이 단순 문서 부재가 아닌 명시적 DB 제약조건 적용 누락에 있음을 파악했습니다.

2) 개선/해결 방안

상태 컬럼 타입을 통일한 뒤 CONSTRAINT CHK_STATUS CHECK (STATUS IN ('Y', 'N', 'R'))와 같은 DB 단 CHECK 제약조건을 적용했습니다. 이후 공통 더미 데이터를 배포해 팀 전체 개발 환경을 동기화하고, 설계 단계부터 데이터 무결성 기준을 확립해 구조적 품질을 높였습니다.

3) 결과/성과

팀 전체 개발 환경을 동기화하고, 데이터 무결성이 훼손될 가능성을 사전에 차단했습니다. 이후 DB 병합 충돌은 0건으로 유지됐습니다.

기술 스택

Back-end

Java Spring Boot MyBatis Gradle

Front-end

JSP JSTL jQuery Axios

Oracle

Tool

Git GitHub Notion

참여 소감

잘된 점 DB 관리자로서 ERD 설계부터 제약조건 강제까지 데이터 무결성 전 과정을 주도하고, Oracle의 LISTAGG와 View 도입으로 복잡한 쿼리 성능을 구조적으로 개선한 점

아쉬운 점 JSP 기반 렌더링이다 보니 UI/UX 측면에서 동적 인터랙션 구현에 한계가 있었던 점

보완할 점 다음 프로젝트에서 React 등 SPA 프레임워크로 전환하여 사용자 경험을 개선하는 방향으로 발전 예정

N+1 병목을 해소하여 EC2 스로틀링
장애를 해결한 백엔드 개발자 조치호

N+1 쿼리로 발생한 인프라 병목을 애플리케이션 구조 개선으로 해결했습니다.

🛠 기술 스택

💼 프로젝트

🎓 학력 · 교육 · 자격증

📄 이력서

N+1 병목을 해소하여 EC2 스로틀링장애를 해결한 백엔드 개발자 조치호

N+1 쿼리로 발생한 인프라 병목을 애플리케이션 구조 개선으로 해결했습니다.

🛠 기술 스택

💼 프로젝트

🎓 학력 · 교육 · 자격증

📄 이력서

N+1 병목을 해소하여 EC2 스로틀링
장애를 해결한 백엔드 개발자 조치호