INTRODUCE
웹/앱 서비스의 백엔드 개발과 창업 경험을 바탕으로,
기획–개발–운영 전 과정을 직접 책임지며
고객을 먼저 생각하는 서비스를 만들어왔습니다.
누적 280명의 사용자를 확보한 서비스를 직접 개발하며
6,000만 원 이상의 투자 유치라는 성과를 만들었고,
서비스 운영 과정에서
성능 최적화·데이터 정합성·안정성을 중심으로 한
백엔드 설계를 경험했습니다.
카카오테크 부트캠프 수료를 통해
Spring 기반 백엔드 역량을 체계적으로 다졌으며,
대규모 트래픽과 동시성을 고려한 구조 설계와 성능 개선을
실제 프로젝트에 적용해 왔습니다.
개인의 성과에 그치지 않고,
팀과의 협업을 통해 문제를 공유하고 해결하며
기술적 선택이
서비스의 신뢰도와 지속 가능성으로 이어지도록 고민하는
개발자로 성장하고자 합니다.
PROJECT
인가 구조 재설계로 IDOR 취약점 제거 및 개인정보 유출 예방
2025.07 ~ 운영중
대학 이수 관리 및 졸업 설계 서비스, GRADU
-
학생별 리소스를 다루는 API에서
인가 우회 가능성을 점검하기 위해
OpenAPI 스펙 기준
10개 엔드포인트를 식별
-
“본인 / 타인 / 미인증 사용자” 조합으로
총 30개의 인가 테스트 시나리오를 설계하고
JUnit 통합 테스트로 자동화
-
일부 API에서
URL의 식별자만 변경해
타인 데이터 접근이 가능한
IDOR 취약점을 발견
-
AOP 기반
인가 어노테이션을 도입해
컨트롤러 진입 전
JWT와 PathVariable을 비교하도록 구조를 개선
-
DB 스키마를 재점검하며
학번·실명 등
직접 식별자 컬럼을 제거하고,
필수 이메일만
AES 암호화하여 저장하도록 리팩토링
-
인가 테스트 30/30 통과,
민감 컬럼 약 70% 감소,
IDOR 취약점 제거
Link:
https://gradu0420.notion.site/GRADU-2bdd4780dde180709bd6c3e868fa1360
GitHub:
https://github.com/KimGyeongLock/GRADU
감정별 대표 문서 체계 도입으로 일기 추천 성능 개선
2024.05 ~ 운영중
LLM 기반 일상 감정 관리 플랫폼, 반디
-
기존 키워드 매칭 방식이
전체 일기 탐색을 유발해
Read 병목이 발생함을 정의
-
LLM으로 추출한 감정 키워드를
5개 감정 카테고리로
정규화
-
각 카테고리에
대표 일기 4개를 유지하는
대표 문서 체계를 설계
-
신규 일기는
카테고리 매핑 후
해당 4개 문서만 비교하도록
추천 로직을 변경
-
조회 대상 O(N) → O(20)건,
DB Read 약 98% 절감
Store Link:
https://tosto.re/bandiApp
B2B 웹:
https://bandi-official.web.app
GitHub:
https://github.com/Nein-to-Sick/bandi_official
동시성 제어 및 Redis 오프로딩으로 중고거래 트래픽 안정화
2024.10 ~ 2024.12
사물함 기반 비대면 중고거래 커머스 서비스, 거래함
-
멀티 스레드 환경에서
구매 로직 동시 실행으로
데이터 정합성 이슈가 발생함을 정의
-
주문 충돌을 방지하기 위해
DB 레벨에
Pessimistic Lock을 적용해
동시성 문제를 차단
-
좋아요·조회수 등
고빈도 Write로 인한
DB 부하를 줄이기 위해
Redis 인메모리 캐시를 도입
-
Redis
원자 연산과
TTL 기반 동기화로
캐시–DB 간 정합성을 유지
-
멀티 스레드 환경에서도 데이터 정합성 확보,
DB Write 부하 감소 및 처리 성능 개선
GitHub:
https://github.com/TradeHam/TradeHam
실시간 음성 스트리밍 인코딩 오류 해결과 STT 지연 시간 단축
2024.09 ~ 2024.12
실시간 음성 텍스트 통화 서비스, 앵무말
-
스트리밍 오디오를
STT로 변환하는 과정에서
텍스트 응답이 null로 반환되는 문제를 정의
-
WebRTC 오디오 포맷과
AWS Transcribe 입력 규격 불일치가
문제의 원인임을 파악
-
오디오를
16bit PCM 포맷으로 변환하고
48kHz 샘플레이트로 재구성
-
스트리밍 오디오
chunk 처리 방식을 개선해
실시간 STT 파이프라인을 안정화
-
지연 시간 3~5분 → 20~30초 단축,
정확한 문장 단위 STT 결과 확보
GitHub:
https://github.com/Parrotalk
200만 건 대용량 데이터 덤프 DB 용량 및 조회 성능 최적화
2024.04 ~ 2024.06
검색엔지 서비스 KUBiC의 대규모 데이터 덤프를 대상으로 한 DB 구조 개선 프로젝트
-
문서·게시글·회원 정보를 포함한
200만 건 데이터 덤프로 인해
DB 용량 증가 및 조회 성능 저하 문제를 정의
-
대용량 처리 안정성을 위해
MySQL InnoDB 엔진을 채택하고
EXPLAIN·PROFILING으로 쿼리 병목을 분석
-
중복 인덱스 제거,
클러스터형 인덱스 도입,
필요 필드만 조회하는 구조로 정규화 및 비정규화 병행
-
조인 구조를 단순화하고
인덱스 재설계를 통해
비효율적인 쿼리를 단계적으로 개선
-
DB 용량 3,359MB → 32MB (99%↓),
평균 응답 2.7초 → 1초대로 성능 개선