이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
포트폴리오 프로젝트에서 메인 화면 로딩이 2초가 넘어가는 문제가 있었습니다. 분석해보니 화면마다 같은 집계 쿼리를 새로 실행하는 것이 원인이었습니다. Redis를 처음 사용해보았는데 TTL을 너무 길게 설정해서 데이터가 실시간으로 반영되지 않는 문제가 발생했습니다. 5분으로 줄였더니 실시간성과 성능의 균형이 맞았습니다. 캐시 적중률을 로그로 확인했는데 80% 이상이 캐시에서 응답되었습니다. 로딩 시간이 2초에서 0.3초로 줄어들었습니다. 처음에는 캐시 무효화 로직을 만들지 않아 데이터 수정 후에도 구버전이 보이는 버그가 발생했습니다. 이 경험을 통해 캐시는 도입보다 무효화 전략이 더 어렵다는 것을 배웠습니다.
사이드 프로젝트에서 데이터가 1만 건 쌓이자 검색 기능 응답이 갑자기 느려졌어요. 로컬에서 개발할 때는 수백 건이라 안 느꼈던 문제였어요. EXPLAIN ANALYZE로 쿼리 실행 계획을 처음 봤는데 Seq Scan이 전체 테이블을 훑고 있었어요. 검색 컬럼에 인덱스를 추가했더니 응답이 800ms에서 30ms로 줄었어요. 너무 신기해서 인덱스를 여러 컬럼에 막 추가했다가 쓰기 성능이 저하되는 걸 경험했어요.
인덱스는 읽기와 쓰기의 트레이드오프라는 걸 직접 느꼈어요. 데이터가 많아질수록 저장 설계가 성능에 직결된다는 걸 이때 배웠어요. 그 과정이 값진 배움이었습니다.
분산 시스템 개념을 공부하다가 CDN, 애플리케이션 캐시, DB 캐시가 각각 다른 계층에서 동작한다는 걸 이해했어요. 이론으로 알다가 사이드 프로젝트에서 정적 이미지가 느려서 CloudFront CDN을 붙였더니 해외에서 접속 속도가 확 빨라지는 걸 직접 경험했어요. 그때 처음으로 캐시 계층마다 역할이 다르다는 게 체감됐어요. 애플리케이션 캐시에서 리액트 쿼리를 써서 API 응답을 브라우저에서 캐싱하는 것도 같은 맥락이라는 걸 이해했어요.
데이터가 사용자에게 가까울수록 빠르다는 원칙으로 캐시 계층을 생각하게 됐어요. 분산 시스템은 거창한 것 같지만 결국 이 원칙의 구현이에요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 무신사 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.