이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
데이터 파이프라인에서 가장 중요하게 생각하는 요소는 데이터 신뢰성입니다. 아무리 빠르고 효율적인 파이프라인도, 중간에 데이터가 유실되거나 잘못 변환되면 하위 분석 전체가 틀려집니다. 사이드 프로젝트에서 Python으로 간단한 ETL 파이프라인을 만들었을 때, 소스 데이터에 null 값이 섞여 있는 걸 처리하지 않아서 집계 결과가 실제보다 20% 낮게 나온 걸 이틀 뒤에야 발견한 적이 있었습니다. 그 이후로 파이프라인 각 단계 끝에 예상 행 수와 실제 행 수를 비교하는 간단한 체크를 넣었습니다. 실시간 대시보드까지 연결된 파이프라인이었다면 이틀이 아니라 훨씬 오래 잘못된 숫자를 보고 있었을 겁니다. 확장성이나 처리 속도도 중요하지만, 신뢰할 수 없는 데이터를 빠르게 처리하는 건 오히려 더 위험하다고 생각합니다. 지금도 파이프라인을 설계할 때 검증 단계를 먼저 어디에 넣을지를 먼저 그립니다.
확장성과 지연시간 사이의 트레이드오프가 파이프라인 설계에서 가장 자주 마주치는 결정이라고 생각합니다. 실시간 처리를 선택하면 지연이 줄어드는 대신 시스템 구조가 복잡해지고 운영 비용이 올라갑니다. 반대로 배치 처리는 구조가 단순하고 비용이 낮지만, 대량 데이터가 한꺼번에 몰릴 때 파이프라인이 뒤처지는 상황이 생깁니다. 수업에서 Lambda Architecture를 배울 때, 배치와 스트리밍을 함께 두는 구조가 이 트레이드오프를 피하는 방법처럼 보였지만 두 경로를 모두 관리해야 한다는 복잡도가 생겼습니다.
비즈니스가 데이터를 얼마나 빠르게 필요로 하는지가 이 선택의 기준이 된다는 걸 그 과정에서 이해했습니다. 설계는 기술 선택보다 요구사항 파악이 먼저라는 원칙이 생겼습니다. 지연 요구사항이 파이프라인 구조 선택의 출발점입니다.
멱등성(Idempotency)이 파이프라인 설계에서 중요하다는 걸 장애 복구 케이스를 공부하면서 배웠습니다. 파이프라인이 중간에 멈췄다가 다시 시작할 때, 같은 데이터를 두 번 처리해도 결과가 달라지지 않아야 안전하게 재처리할 수 있습니다. 중복 처리가 발생하면 집계 숫자가 틀어지거나 이중 결제 같은 문제로 이어질 수 있습니다. 사이드 프로젝트에서 처리 중 오류가 나면 처음부터 다시 돌리도록 설계했는데, 멱등성을 보장하지 않아서 재처리할 때마다 숫자가 달라지는 버그가 생겼습니다.
입력을 여러 번 받아도 출력이 같아야 한다는 원칙을 설계 초기부터 반영하지 않으면 나중에 고치기 어렵다는 걸 배웠습니다. 재처리가 안전한 파이프라인이 장애에도 흔들리지 않습니다. 멱등성 설계가 파이프라인 신뢰성의 핵심입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 GS리테일 데이터 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.