이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
추천 시스템의 트래픽과 데이터 규모가 빠르게 증가할 때 저는 수평 확장과 캐싱 전략을 핵심으로 생각합니다. 단일 서버로는 한계가 있기 때문에 서버를 추가해서 부하를 분산하는 구조가 기본이 되어야 한다고 배웠습니다. 추천 결과가 실시간으로 바뀌지 않는 경우라면 미리 계산된 결과를 캐시에 올려두고 빠르게 응답하는 방식이 효율적이라고 알고 있습니다. 수업에서 캐시 히트율을 높이면 실제 연산 부하가 크게 줄어드는 사례를 분석했는데, 추천 시스템처럼 같은 사용자에게 비슷한 결과가 반복되는 경우에 캐싱이 효과적이라는 걸 이해했습니다. 개인 프로젝트에서 캐시 만료 시간을 너무 길게 잡았더니 오래된 결과가 계속 나오는 문제가 생겼는데, 신선도와 성능 사이 균형을 잡는 것도 설계의 일부라는 걸 배웠습니다. 실무에서 어떤 기준으로 이 균형을 잡는지 배우고 싶습니다.
추천 시스템에서 트래픽이 급증하면 실시간 계산과 배치 계산을 분리하는 구조가 중요하다고 배웠습니다. 모든 추천을 요청이 들어올 때마다 실시간으로 계산하면 응답 속도가 느려지고 서버 부담이 커집니다. 대신 추천 결과를 주기적으로 미리 계산해서 저장해두고, 요청이 들어오면 저장된 결과를 빠르게 반환하는 방식이 확장에 유리합니다. 수업에서 오프라인 배치 처리와 온라인 서빙 레이어를 분리한 아키텍처를 배울 때, 두 층이 각자의 부하를 따로 관리할 수 있다는 점이 인상적이었습니다. 팀 프로젝트에서 소규모로 비슷한 구조를 만들어봤는데, 배치 주기를 너무 길게 잡으면 추천 결과가 오래되는 문제가 생겼습니다.
얼마나 자주 갱신할지 설정이 결과 품질에 직결된다는 걸 알게 됐습니다. 실제 운영 환경에서의 기준이 궁금합니다.
추천 시스템에서 데이터 규모가 커질 때 저는 데이터 처리 파이프라인의 병목을 찾는 것이 먼저라고 생각합니다. 추천 품질이 아무리 좋아도 데이터가 제때 처리되지 않으면 실제 서비스에서 의미가 없습니다. 수업에서 스트리밍 처리와 배치 처리의 차이를 배울 때, 실시간성이 중요한 경우와 전체 분석이 중요한 경우에 적합한 처리 방식이 다르다는 걸 알게 됐습니다. 개인 프로젝트에서 데이터 양이 늘어나면서 전처리 시간이 급격히 늘어나는 상황을 경험했는데, 원인을 찾아보니 불필요한 전체 데이터 스캔이 반복되는 구조였습니다. 조건을 먼저 걸어서 처리 대상을 줄이는 방식으로 바꾸니 속도가 개선됐습니다.
처리 속도 개선은 알고리즘보다 불필요한 작업을 없애는 것에서 먼저 찾을 수 있다는 걸 배웠습니다. 실무에서 대규모 파이프라인이 어떻게 관리되는지 배우고 싶습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 당근마켓 ML 인프라 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.