이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 응답이 느리다는 사용자 불만이 접수된 기능을 개선하는 업무를 맡았습니다. 먼저 어느 구간이 느린지 측정했습니다. DB 쿼리 시간이 전체의 70% 이상이었고, 그중 특정 조회에 인덱스가 없는 것이 원인이었습니다. 인덱스를 추가했더니 해당 쿼리 속도가 크게 개선됐습니다. 그런데 인덱스 추가 후 쓰기 작업이 약간 느려졌다는 팀원 보고가 들어왔습니다. 인덱스가 쓰기 비용을 높이는 특성을 몰랐던 것이 실수였습니다. 쓰기와 읽기 비율을 확인하고 쓰기가 많은 테이블에는 인덱스를 최소화하는 방향으로 조정했습니다. 성능 개선이 다른 지점에 영향을 줄 수 있다는 것을, 직접 겪으면서 배웠습니다.
졸업 프로젝트에서 같은 데이터를 반복 조회하는 요청이 많아 서버 부하가 높아지는 문제가 생겼습니다. 조회마다 DB를 거치고 있어서였습니다. 캐싱을 도입하기로 했습니다. 어떤 데이터를 캐시할지가 먼저였는데, 자주 조회되지만 자주 바뀌지 않는 데이터를 우선 대상으로 정했습니다. 캐시 유효 시간을 처음엔 너무 길게 잡아서 데이터가 변경됐는데 오래된 값이 보이는 문제가 생겼습니다. 시간을 줄이고 데이터 변경 시 캐시를 직접 비우는 방식을 추가했습니다. 이 구조로 바꾼 뒤 DB 조회 횟수가 약 40% 줄었고 응답 속도도 개선됐습니다. 캐싱은 빠르게 해주는 만능 도구가 아니라 일관성과 속도를 저울질해야 한다는 걸 배웠습니다.
사이드 프로젝트에서 서비스 핵심 기능이 외부 API 하나에 의존하는 구조로 되어 있었습니다. 외부 API가 잠깐 느려지면 서비스 전체가 응답하지 않는 상황이 생겼습니다. 원인을 보니 외부 호출에 타임아웃이 설정되지 않아 요청이 무기한 대기하는 구조였습니다. 타임아웃을 추가하고 타임아웃이 발생하면 캐시된 이전 결과를 보여주는 폴백을 만들었습니다. 처음엔 폴백 데이터가 너무 오래된 경우에도 그대로 보여주는 문제가 생겼습니다.
폴백을 쓸 수 있는 최대 시간을 제한하는 방식을 추가했습니다. 가용성을 유지하려면 외부 의존성이 실패했을 때 서비스가 어떻게 동작할지를 미리 설계해야 한다는 걸 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.