이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사이드 프로젝트에서 이벤트성 트래픽이 몰릴 때 응답 지연이 심해지는 문제를 겪었습니다. 분석해보니 광고 노출 로그를 `DB`에 실시간으로 쓰는 구조가 병목이었습니다. 초당 수백 건의 쓰기가 동시에 들어오면 DB 락이 걸려서 읽기 요청도 함께 느려졌습니다.
Redis를 앞에 두고 로그를 버퍼링한 뒤 배치로 DB에 쓰는 방식으로 바꿨더니, 응답 시간이 3배 이상 개선됐습니다. 트래픽이 많은 시스템에서 쓰기와 읽기 경로를 분리하는 게 왜 중요한지를 직접 수치로 확인한 경험이었습니다. 아키텍처 결정 하나가 체감 성능에 바로 영향을 준다는 걸 그때 처음으로 실감했습니다.
인턴 프로젝트에서 광고 클릭 집계 수치가 실제보다 2배 가까이 높게 나오는 현상이 보고됐습니다. 처음에는 클라이언트 측 재시도 로직 때문에 같은 요청이 여러 번 들어오는 것을 서버가 구분하지 못했던 게 원인이었습니다. 요청마다 고유 `event_id`를 발급하고, Redis에 해당 id가 이미 처리됐는지 확인하는 멱등성 처리를 추가했습니다. 적용 후 중복 집계율이 2% 이하로 떨어졌고, 광고주 리포트 신뢰도가 회복됐습니다. 대규모 트래픽에서는 재시도를 전제로 설계해야 한다는 걸 그때 배웠습니다.
클라이언트가 어떻게 동작하는지를 서버 설계 단계에서 같이 고려하는 게 중요하다는 시각도 생겼습니다.
대규모 광고 시스템을 직접 운영한 경험은 없지만, 트래픽 패턴이 예측 불가능하다는 점에서 광고 시스템이 일반 서비스와 다르다는 걸 이해합니다. 광고 노출은 이벤트나 시간대에 따라 급격하게 몰리고, 그 타이밍에 집계 오류나 지연이 생기면 광고주 신뢰에 직접 영향을 줍니다. 만약 제가 이 시스템을 담당한다면, 먼저 `Circuit Breaker` 패턴으로 특정 컴포넌트 장애가 전파되지 않게 하고, 집계는 실시간보다 약간의 지연을 허용하는 `Lambda` 아키텍처를 검토할 것 같습니다. 아직 경험이 짧아서 실무와 다를 수 있지만, 이 방향이 유효하다는 생각에서 출발해보겠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 당근마켓 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.