이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사이드 프로젝트로 주식 관심 종목 알람 앱을 만들면서 시세 데이터를 어떻게 다룰지 고민이 많았습니다. 1분마다 갱신하면 최신성이 부족하고, 너무 자주 요청하면 외부 API 비용이 커졌습니다.
폴링 방식과 웹소켓 방식을 비교해 봤습니다. 관심 종목 5개 이하일 때는 폴링으로 충분했지만, 종목이 늘수록 연결이 분산되는 웹소켓이 효율적이었습니다. 관심 종목 수 기준으로 방식을 전환하는 로직을 만들었는데, 그 자체가 복잡성을 키운다는 걸 나중에 깨달았습니다.
처음부터 단순하게 웹소켓만 쓰면 됐을 것을 불필요한 분기로 만들었던 실패였습니다. 시세 데이터에서 중요한 건 데이터 신선도와 누락 감지라는 것도 배웠습니다. 연결이 끊겼을 때 마지막 수신 시각을 사용자에게 보여주는 것이 핵심 기능이라는 걸 그때부터 인식했습니다.
팀 프로젝트에서 외부 시세 피드를 수신해 화면에 표시하는 기능을 맡았는데, 외부 피드가 간헐적으로 끊기면 사용자는 오래된 데이터를 최신으로 착각할 수 있었습니다.
마지막 수신 시각을 화면 우측 상단에 표시하고, 30초 이상 갱신이 없으면 '데이터 지연 중' 배너를 띄우는 방식을 제안했습니다. 처음엔 30초 기준이 너무 민감하다는 의견이 나와 실제 피드 지연 분포를 1주일 치 로그로 분석해 95퍼센타일 기준이 12초임을 확인하고 기준을 20초로 조정했습니다.
그 과정에서 기준값을 직관이 아니라 데이터로 정하는 방식을 처음 써봤습니다. 시세 데이터 기능에서 중요한 건 빠른 갱신만큼이나 지연 상태를 투명하게 알리는 것이라는 걸 배웠습니다.
졸업 작품에서 코인 시세 조회 API에 Redis 캐시를 붙였는데, 외부 시세 소스가 변경됐을 때 캐시가 5분 동안 이전 소스 데이터를 반환했습니다. 특정 코인의 시세가 두 배로 뛰었는데 5분간 앱에선 오래된 가격이 표시됐습니다.
이벤트 기반 캐시 무효화를 추가했습니다. 시세 소스 변경 이벤트가 발생하면 관련 캐시 키를 즉시 삭제하도록 연결했습니다. 처음엔 무효화 이벤트가 누락될 경우를 고려하지 않아서 소스가 변경됐는데 이벤트가 안 오면 오래된 캐시가 영구히 남는 문제가 있었습니다. 최대 TTL을 30초로 두어 이벤트 누락 상황에서도 결국 갱신되도록 했습니다.
시세처럼 시간 민감도가 높은 데이터의 캐시는 TTL과 이벤트 무효화를 꼭 함께 설계해야 한다는 것이 그때 배운 교훈입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.