주문/어드민 성능 문제를 어떻게 분석하고 튜닝했는가

주문과 어드민 영역의 성능 문제를 다루다 보면, 단순히 느린 쿼리 하나를 고치는 식으로는 끝나지 않는 경우가 많았습니다. 이 글은 운영하며 정리한 메모와 판단 기준을 바탕으로, 어떤 흐름에서 병목을 찾고 어떤 방식으로 분석하고 튜닝했는지 정리한 기록입니다.

수치보다 중요한 것은 흐름이었다

메모에는 개선 전후 수치가 일부 남아 있습니다. 이런 수치는 분명 중요합니다. 다만 더 중요했던 건 “왜 이 수치가 줄었는가”를 설명할 수 있는 구조를 갖는 일이었습니다.

같은 성능 문제라도 원인은 달랐습니다.

• 트랜잭션 경계가 너무 넓은 경우
• 조회와 가공이 한 흐름에 과하게 몰린 경우
• 관리자 기능이 대량 데이터를 직접 다루는 경우
• 병목이 DB인지 애플리케이션인지 혼동되는 경우

이런 것들을 분리해서 보지 않으면 수치를 낮춰도 다시 같은 문제가 반복되기 쉽습니다.

즉 핵심은 “예전에 무엇을 빨리 했는가”가 아니라, 어떤 식으로 문제를 분류했고 무엇을 우선순위에 올려 분석과 튜닝을 진행했는가에 있습니다.

트랜잭션을 분석해보면 보이는 것

트랜잭션을 실제로 따라가며 분석해보면, 운영 중 성능 이슈를 볼 때 왜 코드만 봐서는 부족한지가 분명해집니다. 주문과 어드민 영역의 성능 문제를 정리할 때도 결국 트랜잭션 경계와 쿼리 흐름을 같이 봐야 했습니다.

이 기준이 중요한 이유는, 느린 쿼리나 큰 응답 시간이 보여도 그것이 원인인지 결과인지는 따로 판단해야 하기 때문입니다. 트랜잭션 경계와 흐름을 같이 봐야 병목의 앞뒤를 구분할 수 있습니다.

즉 이 글의 핵심은 “무슨 쿼리를 튜닝했는가”보다 “무엇을 병목으로 판단했는가”에 있습니다.

당시 수행 항목을 다시 보면 이 판단 기준이 더 선명합니다. 실제로는 Admin console 성능 향상, 주문 조회 성능 향상처럼 운영자와 CS가 바로 체감하는 구간이 따로 있었고, 그 옆에서는 Read/Write 분리, 트랜잭션 설정 조정처럼 더 구조적인 개선이 함께 진행됐습니다. 즉 성능 개선은 한 번의 쿼리 수정이 아니라, 운영자 UI와 주문 흐름, DB 경계 설정을 같이 손보는 작업이었습니다.

특히 주문 쪽은 재고 차감 트랜잭션이 핵심 병목으로 연결되기 쉬웠습니다. 단순히 쿼리가 느린 문제가 아니라, 같은 상품에 요청이 몰릴 때 DB 락 경합이 구조적으로 커지는 문제였습니다. 그중에서도 range lock 성격의 경쟁은 히트 상품 상황에서 훨씬 민감하게 드러났습니다.

이런 상황에서 ProxySQL 기반 Read/Write 분리는 꽤 현실적인 완화책이었습니다. 읽기 부하를 분산하면서 전체 경합을 조금 더 버틸 수 있게 만들었기 때문입니다. 반면 queue를 도입해 차감 경쟁 자체를 비동기적으로 완화하는 방향은 당시에도 필요했지만, 실제 구현까지 이어지지 못한 미래 계획에 가까웠습니다.

시리즈 2를 마치며

이 시리즈는 결국 하나의 흐름으로 이어집니다.

• 주문 안정화의 핵심은 재고 구조를 이해하는 것이었고
• 대량 트래픽에서는 병목을 흐름으로 봐야 했고
• 부분반품은 비즈니스 규칙과 정산 구조를 함께 봐야 했고
• 성능 개선은 수치보다 해석 기준이 더 중요했습니다

다음 시리즈에서는 구현과 정산을 넘어, 배치 스케줄러, 운영 로그, 세션 관리, 운영 도구화 같은 Operations / Tooling 영역으로 넘어갑니다. 시작점은 배치 스케줄러를 운영 문서 관점에서 다시 정리해보기입니다.

결국 성능 문제도 운영 문제의 일부였습니다. 그래서 이 글은 Series 3로 넘어가는 연결점이기도 합니다.