이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
확장성 관리 도구를 개발할 때 가장 먼저 설계한 것은 어떤 신호로 확장 여부를 판단할 것인가였습니다. CPU·메모리·요청 큐 깊이 같은 지표를 기준으로 임계값을 넘으면 인스턴스를 늘리고 내려가면 줄이는 정책을 정의하고, 그 기준이 실제 부하 패턴과 맞는지 실험으로 검증했습니다.
확장 지연을 줄이는 것도 중요했습니다. 부하가 올라온 뒤 인스턴스가 준비되기까지의 시간이 사용자 경험에 영향을 줬기 때문에, 예상 부하 증가 전에 선제적으로 확장하는 예측 기반 전략을 병행했습니다.
도구의 신뢰성 검증도 중요한 작업이었습니다. 부하 테스트로 확장 동작을 시뮬레이션해 정책대로 인스턴스가 늘고 줄어드는지 확인했고, 예외 케이스에서도 오작동 없이 동작하는지 체계적으로 검증했습니다. 확장 이벤트 로그도 남겨 나중에 정책 튜닝에 활용했습니다.
인턴 중에 클라우드 서비스가 트래픽 급증 때마다 수동으로 인스턴스를 늘리던 과정을 자동화하는 과제를 맡았습니다. 처음에는 CPU 사용률 하나만 보는 정책을 짰는데, CPU가 낮아도 응답 지연이 심한 경우가 있었습니다. 메트릭 하나로는 부족하다는 걸 깨닫고, 응답 시간 p95와 요청 큐 길이를 함께 보는 복합 트리거로 바꿨습니다. 그 뒤 트래픽이 두 배로 튀는 부하 테스트에서도 응답 지연이 기존 대비 40% 줄었습니다. 스케일링 정책을 바꿀 때마다 직접 부하 테스트를 돌려 수치로 확인하는 습관이 그때 생겼습니다. 지금도 확장 정책을 짤 때는 단일 메트릭보다 복합 신호를 먼저 검토합니다.
학부 캡스톤에서 k6로 직접 부하 테스트를 설계하며 확장성 문제를 처음 손으로 만진 경험이 있습니다. 처음에 100명 동시 접속 시나리오를 짰는데, 응답 시간이 예상보다 3배 느렸습니다. 병목이 어디인지 몰라서 당황했는데, 프로파일링 결과 DB 커넥션 풀이 소진되는 게 원인이었습니다. 커넥션 풀 크기를 조정하고 읽기 전용 쿼리를 레플리카로 분리하니 응답 시간이 정상으로 돌아왔습니다. 수직 확장(인스턴스 크기 올리기)을 먼저 시도했다가 비용 대비 효과가 낮다는 걸 확인하고 나서야 읽기·쓰기 분리가 더 근본적인 해결이라는 걸 배웠습니다. 측정 없이 직관으로 확장하면 돈만 쓰고 해결이 안 된다는 걸 그때 몸으로 확인했습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 무신사 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.