스케일링 의사결정 기준 확인
이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사이드 프로젝트에서 예상치 못한 트래픽이 몰렸을 때 재설계 여부를 어떤 지표로 판단할지 실제로 고민했던 경험이 있다. 처음에는 응답 속도가 느려졌다는 체감만으로 리팩터링을 시도했는데, 오히려 더 느려졌다. 문제의 원인을 제대로 몰랐기 때문이었다. 이후 APM 도구로 요청별 응답시간, 에러율, DB 커넥션 수를 먼저 수집했다. 지표를 보니 문제는 로직이 아니라 DB 쿼리 N+1이었다. ORM 쿼리를 join fetch로 교체한 뒤 p95가 800ms에서 150ms로 줄었다. 이 경험으로 '재설계가 필요한가'를 판단하는 기준이 생겼다. 체감이 아니라 지표가 특정 구간을 지목하고 있을 때, 그 구간이 현재 구조로는 개선 한계가 명확할 때 재설계를 검토한다. 단순 최적화로 해결될 수 있는데 구조를 갈아엎는 건 비용이 너무 크다.
먼저 측정, 그 다음 결정이 순서라고 생각한다.
트래픽이 급증했을 때 재설계 여부를 오류율과 TPS 기준으로 판단했습니다. 응답 지연보다 오류율이 올라가기 시작하면 일시적 부하가 아닌 구조적 한계에 가까워졌다는 신호로 봤습니다. TPS가 임계치를 넘으면서 DB 커넥션 풀이 고갈되는 지점이 확인됐고, 이 지점을 재설계 트리거로 삼았습니다. 설계 변경 방향은 DB 쓰기를 비동기 큐로 분리하고, 읽기 트래픽은 캐시 레이어로 흡수하는 방식이었습니다. 트랜잭션 일관성이 중요한 금융 흐름은 동기 처리로 남기고, 집계나 알림은 비동기로 분리했습니다.
오류율이 재설계 신호입니다. 일관성 요건에 따라 동기·비동기를 분리합니다. 지표가 재설계 타이밍을 결정합니다.
트래픽 증가 대응에서 바로 수평 확장을 선택하기 전에 단일 인스턴스 최적화 여지를 먼저 확인했습니다. 서버를 늘리는 것은 비용이 바로 발생하지만, 쿼리 최적화나 캐시 도입은 상대적으로 비용이 낮습니다. 슬로우 쿼리 로그에서 전체 응답 시간의 60%를 차지하는 쿼리 3개를 찾아 인덱스를 추가하는 것만으로 응답 시간이 절반 이하로 줄었습니다. 이 과정을 거친 뒤에도 TPS 한계가 오면 그때 수평 확장을 결정했습니다.
단계적 접근이 불필요한 비용을 막습니다. 최적화 후 확장이 순서입니다. 슬로우 쿼리가 첫 번째 최적화 대상입니다. 확장 전 최적화가 비용을 절약합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 채널톡 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.