이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 프로젝트에서 이벤트 트래픽이 평소의 5배 이상 몰리는 상황을 맞은 적 있습니다. DB 조회 쿼리가 순차적으로 처리되면서 응답 지연이 7초를 넘었고, 일부 요청은 타임아웃으로 실패했습니다. 원인을 찾아보니 반복 조회되는 데이터에 캐시가 없어서 매번 DB에 직접 요청이 가고 있었습니다. Redis를 붙여서 자주 조회되는 결과를 TTL 5분으로 캐싱했더니 응답 시간이 1초 이하로 줄었습니다. 병목이 어디서 생기는지를 먼저 측정하고 나서 손대는 것이 가장 빠른 해결 경로였습니다.
병목이 어디인지 먼저 측정하지 않으면 최적화는 감으로 하는 것입니다. 캐시 하나로 응답이 7배 빨라진 경험이 저에게 성능 개선은 계측에서 시작한다는 원칙을 만들었습니다.
성능 이슈를 해결할 때 원인을 제대로 파악하는 것이 가장 먼저라는 걸 경험에서 배웠습니다. 처음에는 문제가 생기면 바로 코드를 수정하려 했는데, 그렇게 하면 근본 원인이 아닌 증상만 고치는 경우가 생겼습니다. 로그를 시간 순서로 보면서 어느 시점에서 지연이 시작됐는지를 먼저 확인하고, 그다음 슬로우 쿼리 로그로 어떤 쿼리가 문제인지를 좁혀갔습니다.
계측 없이 최적화하면 감으로 하는 것이라는 걸 그 과정에서 실감했습니다. 병목이 DB인지 네트워크인지 애플리케이션 로직인지를 구분하면 해결책도 달라집니다. 측정 → 원인 확인 → 수정 → 재측정 순서를 지키는 것이 가장 빠른 길이라는 걸 배웠습니다.
성능 개선은 계측에서 시작한다는 원칙이 생겼습니다. 슬로우 쿼리 로그가 DB 병목 진단의 시작입니다.
대규모 트래픽을 구조적으로 처리하는 방향에 대해서도 공부하면서 이해를 넓혔습니다. 단일 서버에서 처리 한계가 생기면, 캐싱만으로는 한계가 있고 수평 확장(Scale-out)이나 부하 분산이 필요합니다. 로드 밸런서를 통해 여러 서버에 요청을 분산하는 구조를 학습 프로젝트에서 실험해봤는데, 어떤 서버에 요청이 가더라도 같은 결과가 나와야 한다는 멱등성이 다시 한번 중요해졌습니다.
캐싱은 빠른 해결이지만 트래픽이 특정 패턴으로 증가할 때는 구조 자체를 바꿔야 한다는 걸 이해했습니다. 아직 실제 프로덕션 규모에서 직접 경험한 것은 없어서, 현장에서 배워야 할 부분이 많다는 걸 알고 있습니다. 하지만 병목 지점을 찾고 구조적으로 접근하는 방향은 현장에서도 유효한 원칙이라고 생각합니다.
수평 확장 설계가 트래픽 급증 대응의 기본 방향입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 크래프톤 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.