예시 답변 1
약 78초
구체적인 프로젝트 경험 한 가지로 시작해 상황·본인 역할·판단·결과 순으로 푸는 결
학부 캡스톤에서 4명이서 중고거래 알림 서비스를 만들 때, 제가 백엔드에서 Redis와 Kafka를 맡았습니다. 처음엔 주문 상태를 DB만으로 조회했는데, 알림이 몰리는 시간대에 응답이 느려졌습니다. 그래서 자주 읽는 사용자 알림은 Redis에 5분짜리 캐시로 두고, 결제 완료나 채팅 수신 같은 이벤트는 Kafka로 분리해 비동기로 처리했습니다. 다만 처음에는 캐시 만료를 너무 짧게 잡아 같은 요청이 다시 DB로 가는 문제를 겪었습니다. 그 뒤엔 조회 패턴을 먼저 보고 TTL을 조정하는 방식으로 바꿨습니다. 지금도 새 기능을 맡으면 먼저 조회 빈도와 비동기 분리 지점부터 확인하고 있습니다.
이 결의 특징
한 번의 프로젝트 경험 안에서 Redis와 Kafka를 각각 어디에 썼는지가 드러나는 결입니다. 기술 나열보다 본인 판단의 흐름이 앞에 오기 때문에, 듣는 쪽에서는 도구를 아는지보다 어떤 문제를 어떤 기준으로 나눠 풀었는지가 보이는 편입니다. 마지막에 현재 원칙으로 닫혀서 경험이 일회성으로 끝나지 않는 흔적도 나타납니다.
이 결이 통하는 자리
백엔드 직무에서 캐시와 메시지 큐를 실제로 써 본 흔적을 보고 싶을 때 잘 맞는 자리입니다. 특히 트래픽 분산, 응답 지연, 비동기 처리처럼 운영 감각이 필요한 질문에서 작동하는 편입니다. 기술 스택을 얼마나 넓게 아는지보다, 상황을 보고 Redis와 Kafka를 어떻게 나눠 썼는지가 보이면 설득력이 생깁니다.