이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 사용자 행동 이벤트를 실시간으로 수집하는 파이프라인을 Kafka로 구성하였습니다. 프로듀서가 이벤트를 토픽에 발행하면, 컨슈머가 이를 읽어서 데이터베이스에 적재하는 구조였습니다. 처음에는 컨슈머 그룹 설정을 잘못하여 같은 메시지가 중복 처리되는 문제가 발생하였습니다. 파티션과 오프셋 개념을 다시 정리한 후에 해결하였고, 이론으로 아는 것과 실제로 디버깅하는 것은 전혀 다르다는 것을 그때 배웠습니다. 이후에는 멱등성 처리를 설계 단계에서 미리 고려하는 습관이 생겼습니다.
멱등성을 설계 단계에서 고려하는 것이 스트림 파이프라인의 기본이라는 것을 배웠습니다. 실제로 돌려봐야 이해되는 개념이 있다는 것을 그때 깨달았습니다.
클라우드 실습에서 GCP Pub/Sub를 이용해 센서 데이터를 수집하고 `BigQuery`에 적재하는 파이프라인을 구성했어요. 직접 서버를 운영하지 않아도 토픽을 구독하는 구조로 확장이 쉬웠어요. 다만 처음에 구독 만료 시간 설정을 빠뜨려서 데이터가 유실된 경험이 있었어요. 운영에서는 설정 하나가 데이터 전체에 영향을 줄 수 있다는 걸 그때 배웠고, 이후엔 파이프라인 설정값을 문서화하는 습관이 생겼어요.
클라우드 관리형 서비스는 편리하지만 설정 관리가 핵심이라는 걸 직접 경험했습니다. 설정값 하나가 전체 데이터에 영향을 준다는 걸, 유실 경험에서 직접 배웠어요.
Kafka와 Pub/Sub를 같이 검토하면서, 두 도구 사이의 선택 기준을 직접 정리해본 경험이 있어요. Kafka는 온프레미스 환경이나 세밀한 제어가 필요할 때 유리하고, Pub/Sub는 클라우드 환경에서 빠르게 시작할 때 적합해요. 스트림 파이프라인에서 처리량, 지연, 순서 보장, 재처리 가능성을 모두 따져야 하는데, 도구가 다르면 그 중 어느 축을 포기하느냐도 달라져요.
도구를 먼저 선택하기보다 어떤 요구사항이 있는지를 먼저 정리하는 것이 파이프라인 설계의 시작이라는 걸 배웠습니다. 요구사항이 먼저이고 도구는 그다음이라는 걸, 설계 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 당근마켓 ML 인프라 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.