"대용량 트래픽 질문, 어떻게 답해야 할까 (TPS·RPS 면접 대비)"

"초당 5만 건의 요청이 들어오면 어떻게 처리하시겠어요?" 이런 질문에 당황하는 이유는, 정답을 외워서 말하려고 하기 때문입니다. 면접관은 정답을 기대하지 않습니다. 어디가 먼저 터질지 가정하고, 하나씩 해소하는 사고를 봅니다.

먼저: 가정을 세운다

곧바로 "캐시를 쓰겠습니다"라고 답하면 깊이가 없어 보입니다. 좋은 시작은 되묻기입니다.

• "읽기가 많은가요, 쓰기가 많은가요?"
• "데이터 정합성이 얼마나 중요한가요?"
• "응답이 실시간이어야 하나요, 약간 지연돼도 되나요?"

이 질문 하나로 면접관은 "이 사람은 상황에 따라 다르게 설계한다는 걸 안다"고 판단합니다.

사고 흐름: 어디가 먼저 터지나

대용량 처리는 결국 병목을 찾아 하나씩 푸는 일입니다. 보통 이 순서로 생각하면 막히지 않습니다.

1. 읽기가 많다면 → 캐시 + 읽기 복제

같은 데이터를 반복 조회한다면 캐시(Redis 등)로 DB 부하를 덜고, 그래도 부족하면 읽기 전용 복제본(Read Replica)으로 읽기를 분산합니다. 대신 캐시 무효화와 복제 지연이라는 새 문제가 생긴다는 걸 함께 말하세요.

2. 쓰기가 많다면 → 비동기 + 큐

모든 쓰기를 실시간으로 DB에 꽂으면 DB가 먼저 죽습니다. 즉시 응답이 필요 없는 작업은 큐에 넣고 비동기로 처리해 순간 부하를 평탄화합니다. 대가는 결과 반영까지의 지연입니다.

3. 한 서버로 부족하면 → 수평 확장

서버를 여러 대로 늘리고 로드밸런서로 분산합니다. 이때 세션·상태를 어디에 둘지(무상태 설계, 세션 저장소 분리)가 핵심 포인트입니다.

4. DB가 한계면 → 분산

읽기 복제로도 부족하면 샤딩 등으로 데이터를 나눕니다. 다만 샤딩은 조인·트랜잭션·운영이 어려워지는 큰 결정이라, 면접에서는 "마지막 수단으로 고려한다"는 태도가 좋습니다.

자주 나오는 후속 질문

면접관은 보통 여기서 더 파고듭니다. 미리 준비해두면 좋습니다.

• "캐시를 도입하면 어떤 문제가 생기나요?" → 무효화, 캐시 스탬피드, 정합성
• "그 캐시가 동시에 만료되면?" → TTL 분산, 갱신 잠금
• "비동기로 처리하다 메시지가 유실되면?" → 재시도, 멱등성, 데드레터 큐
• "수평 확장했는데 특정 서버만 부하가 몰리면?" → 분산 키 설계, 일관 해싱

핵심: 트레이드오프를 말하라

대용량 처리 답변의 수준을 가르는 건 **"대가를 함께 말하느냐"**입니다.

• 캐시 → 빠르지만 정합성 관리 필요
• 비동기 → 부하 평탄화되지만 지연 발생
• 샤딩 → 확장되지만 복잡도 폭증

장점만 나열하면 외운 티가 나고, 대가까지 말하면 "실제로 운영해본 사람처럼" 보입니다.

준비하는 법

이 흐름은 글로 익힐 수 있지만, 면접은 압박 속에서 말로 풀어내는 일입니다. "그렇게 하면 이 경우엔 어떻게 되나요?"라는 꼬리 질문이 들어올 때 흔들리지 않으려면, 실제 면접관에게 한 번 답해보고 약한 고리를 찾는 것이 가장 빠릅니다. 어디서 가정을 빠뜨리는지, 어떤 후속 질문에 막히는지는 직접 겪어봐야 압니다.