왜 이걸 시작했나
취업 준비를 하면서 이력서를 다듬다 보니 이런 고민이 생겼습니다.
“내가 뭘 만들었는지는 쓸 수 있는데… 내가 뭘 개선했는지, 숫자로 증명할 수 있을까?”
채용 공고나 기술 블로그를 보면 성과를 수치화해서 보여주는 사례가 많습니다.
- API 응답 속도 80% 단축
- 트래픽 5배 증가에도 안정적 서비스 유지
이런 문구들은 이력서에서 단번에 눈에 들어옵니다.
그래서 저도 단순히 “서비스를 만들었다”가 아니라,
서비스를 개선하고, 개선 폭을 수치로 증명한다는 경험을 직접 쌓아보기로 했습니다.
내가 만든 서비스
제가 운영하는 건 작은 사이드 프로젝트입니다.
- 팝업스토어를 소개하는 커뮤니티 플랫폼
- 글, 댓글, 좋아요 기능이 있음
- AWS EC2 프리티어(t2.micro, 1vCPU + 1GB 메모리)에서 구동
실제 트래픽은 많지 않지만 늘 이런 의문이 있었습니다.
“실제 사용자가 늘어나면 어디서 병목이 터질까?”
이 궁금증을 단순히 상상으로 끝내지 않고, 모니터링 → 부하 테스트 → 병목 확인 → 개선이라는 루프를 직접 경험해보기로 했습니다.
성능 개선의 4가지 축
무작정 튜닝하는 대신, 네 가지 큰 축을 잡고 개선해 나갈 계획입니다.
- DB 인덱스 & 트리 구조 – 슬로우 쿼리 분석 및 최적화
- 트랜잭션 처리 – 데이터 정합성과 성능 사이의 균형점 찾기
- 서버 최적화 – JVM, 커넥션 풀, GC 튜닝
- Redis 활용 – 캐시와 세션 관리로 응답 속도 개선
앞으로의 작성 계획
Part 2: 모니터링 & Observability 구축기
성능 개선의 출발점은 현재 상태를 제대로 보는 것입니다. 초기 연재에서는 모니터링 환경을 어떻게 구축하고 발전시켰는지 다룹니다.
- [1편] OTEL 도입 배경과 모니터링 환경 구축
- [2편] Spring Boot + Prometheus + Loki 기본 구축
- [3편] Grafana 대시보드 개선
- [4편] OTEL Agent + Tempo + 슬로우 쿼리 통합
- [5편] 운영은 감지, 로컬은 분석 — Pinup 대시보드 설계
Part 3 이후: 성능 튜닝 4개 축
모니터링으로 병목을 확인한 뒤 본격적인 개선 과정을 기록합니다.
-
[6편] DB 인덱스와 JPQL
-
[7편] 트랜잭션 처리와 동시성 문제 해결>단일 글로 다루기엔 방대하여, 실제 개선 과정을 6개의 글로 나누어 정리했습니다.
- [7-1][트랜잭션 전파 개념]
- [7-2][트랜잭션 전파 실제 적용기 — Pinup 최적화 기록]
- [7-3][트랜잭션 격리 수준 & MVCC — PostgreSQL 내부 동작 이해]
- [7-4][락의 개념 — MVCC vs Lock의 원리와 구현 비교]
- [7-5][비관적 vs 낙관적 락]
- [7-6][재시도 정책과 ExponentialBackOffPolicy 설계]
- [7-7][ExponentialRandomBackOffPolicy 적용 및 내부 구조 분석]
-
[8편] 캐쉬 활용 (로컬 캐쉬, Caffeine)> 읽기 중심 트래픽에서 로컬(L1) 캐시로 체감 성능을 끌어올린 과정과 운영 원칙을 정리했습니다.
- [8-1][Cache 개념·선택 배경과 운영 원칙 — Per-Cache 정책 & Strict]
- [8-2][Spring Boot Cache 설계: Caffeine + AFTER_COMMIT 이벤트 기반 — L1(Local)]
-
[9편] 서버 최적화 (JVM, GC, 커넥션 풀)
마무리
이번 연재는 단순히 기술만 정리하려는 글이 아닙니다.
-
왜 이걸 시작했는지, 어떤 고민과 삽질을 거쳤는지 솔직하게 담으려고 했습니다.
-
단순히 됐다 가 아니라, Before & After 지표를 통해 개선이 실제로 어떻게 보였는지도 보여주고 싶었습니다.
-
다른 개발자가 비슷한 상황에서 참고할 수 있도록 적용 방법과 경험을 정리했습니다
결국 이 글은 제 경험을 기록하고, 누군가에게는 시행착오를 줄여줄 수 있으면 좋겠다는 마음에서 쓴 글입니다.
