이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 기간에 AWS 기반 로그 수집 파이프라인을 운영한 경험이 있습니다. 서비스 로그가 S3에 쌓이는데 6시간 이상 지연이 발생해 분석팀이 전날 데이터로만 작업하는 상황이었습니다. 원인을 추적하니 Lambda 함수가 대용량 파일을 청크 없이 통째로 읽으면서 타임아웃이 걸리는 패턴이었습니다.
파일을 `10MB` 단위 청크로 나눠 처리하도록 함수를 수정하고, SQS 큐를 앞에 붙여 실패 시 재처리 경로를 만들었습니다. 수정 후 평균 지연이 20분 이내로 줄었고, 분석팀이 당일 데이터를 쓸 수 있게 됐습니다. 이 경험으로 클라우드 파이프라인에서 병목은 코드보다 데이터 크기와 타임아웃 설정의 미스매치에서 자주 온다는 걸 몸으로 익혔습니다.
데이터 파이프라인을 운영하면서 가장 예상치 못한 병목은 코드가 아니라 비용 구조였습니다. 실시간 로그 처리 환경을 구성했을 때 초기 설정값을 그대로 유지했다가, 트래픽이 줄었는데도 비용이 그대로였던 걸 한 달 후에야 발견했습니다. 지표를 주기적으로 보지 않았던 것이 원인이었습니다. 이후 처리량 지표에 알람을 설정하고 사용량이 임계 이하로 떨어지면 리포트가 오도록 만들었습니다.
운영 비용은 초기 설계보다 모니터링 루틴에서 결정된다는 걸 그 경험으로 배웠습니다. 파이프라인이 정상 동작하는 것과 효율적으로 동작하는 것은 다른 문제였고, 그 차이를 보는 눈이 운영 경험을 통해 생겼습니다. 이후 구성하는 파이프라인에는 알람 설정을 배포 항목에 반드시 포함했습니다.
사이드 프로젝트에서 외부 데이터를 일 단위로 적재하고 쿼리하는 분석 파이프라인을 구성한 경험이 있습니다. 오브젝트 스토리지에 적재한 뒤 크롤러가 스키마를 자동 감지하도록 설정했는데, 쿼리 비용이 예측 범위를 크게 벗어났습니다. 원인을 추적해 보니 파티셔닝 없이 전체 파일을 매번 스캔하고 있었던 것이었습니다. 날짜 파티션을 추가한 뒤 같은 쿼리의 스캔 범위가 90% 이상 줄었습니다. AWS 스택은 각 서비스가 독립적으로 잘 작동해도 연결 방식과 데이터 구조 설계에서 성능과 비용이 갈린다는 걸 직접 확인했습니다. 그 이후 파이프라인을 설계할 때 쿼리 패턴을 먼저 정의하고 파티션 전략을 역방향으로 결정하는 순서를 따르게 됐습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 데이터 사이언티스트 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.