이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
캐시 문제 중 제가 가장 신경 쓰는 건 캐시가 한꺼번에 만료될 때입니다. 인기 데이터의 캐시가 동시에 만료되면, 그 순간 몰린 요청이 전부 원본으로 한꺼번에 쏟아져 원본이 휘청입니다. 원인은 단순합니다. 다들 같은 시각에 만료되게 둬서입니다. 그래서 대응도 거기 맞춥니다.
만료 시각에 약간씩 무작위 차이를 주어 한꺼번에 안 풀리게 하고, 원본을 새로 채우는 동안에는 하나만 채우게 막아 나머지가 줄 서지 않게 합니다. 다만 무작위 차이는 데이터가 의도보다 조금 더 오래 살아 있는 대가가 있어, 신선도가 덜 중요한 데이터에만 씁니다. 학부 프로젝트에서 조회가 몰리며 원본이 느려졌을 때, 캐시 자체보다 만료가 겹친 게 진짜 원인이었던 경험이 이 접근의 근거입니다. 지금도 캐시를 볼 땐 언제 동시에 비는가부터 봅니다.
제가 본 또 다른 캐시 문제는 없는 데이터를 계속 찾을 때입니다. 존재하지 않는 키를 반복 조회하면, 캐시에 없으니 매번 원본까지 가서 또 없다고 확인합니다. 캐시가 무용지물이 되는 셈입니다. 원인은 '없음'이라는 결과를 캐시하지 않아서입니다. 그래서 대응은 없다는 사실도 잠깐 캐시해, 같은 헛조회가 원본까지 안 가게 하는 것입니다. 다만 이 대응엔 대가가 있습니다.
나중에 그 데이터가 실제로 생겨도, 캐시된 '없음' 때문에 한동안 안 보이는 자리가 생깁니다. 그래서 '없음' 캐시는 아주 짧게만 둬야 합니다. 과제에서 잘못된 링크로 인한 헛조회가 원본 부하의 상당 부분이던 걸 보고 이 방식을 적용했는데, 만료를 너무 길게 잡아 새 데이터가 늦게 뜬 실수도 같이 겪었습니다. 지금은 '없음' 캐시는 짧게, 그리고 신선도가 중요한 데이터엔 더 조심해서 씁니다.
캐시 문제 대응을 저는 무엇을 내주는지로 정리합니다. 동시 만료로 원본이 몰리는 건 만료를 흩뜨려 풀지만, 그 대가로 데이터가 조금 더 오래 묵습니다. 없는 키를 계속 찾는 건 없음도 캐시해 풀지만, 그 대가로 새로 생긴 데이터가 잠시 안 보입니다. 즉 캐시 대응은 거의 다 부하를 줄이는 대신 신선도를 조금 내주는 거래입니다. 그래서 제 판단 기준은 하나입니다.
이 데이터가 잠깐 옛것이어도 괜찮은가. 괜찮으면 적극 캐시하고, 안 되면 캐시를 짧게 두거나 안 씁니다. 학부 때 신선도가 중요한 값을 길게 캐시했다가 옛 데이터가 보인 경험이 이 기준의 출발입니다. 지금도 캐시를 넣기 전에 옛것이 보여도 되는 데이터인지부터 가립니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 네이버 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.