이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
졸업 프로젝트에서 공공 데이터 3개 출처를 합쳐 분석 파이프라인을 만들었습니다. 처음에는 데이터를 받는 대로 바로 모델에 넣었는데, 어느 날 갑자기 결과가 완전히 달라졌습니다. 원인을 찾아보니 출처 중 하나가 포맷을 바꿨는데 제가 모르고 있었습니다.
그 경험에서 파이프라인에서 가장 중요한 건 데이터 신뢰성이라는 걸 배웠습니다. 모델이 아무리 좋아도 입력 데이터가 바뀌면 결과를 믿을 수 없습니다. 그 이후에는 각 단계마다 데이터 검증을 넣었습니다. 컬럼 수가 맞는지, 값 범위가 이상하지 않은지를 체크하고, 문제가 생기면 바로 알림이 오도록 했습니다.
작은 프로젝트라 Airflow 같은 도구는 쓰지 못했고 Python 스크립트에 직접 넣었습니다. 나중에 보니 그 검증 코드가 파이프라인 전체 길이의 30%를 차지했는데, 그게 맞는 비중이라는 걸 지금도 생각합니다.
인턴 때 사내 리포트 자동화 파이프라인 유지 업무를 잠깐 맡았습니다. 매일 아침 전날 데이터를 집계해서 메신저로 보내는 구조였는데, 제가 맡은 첫 날 리포트가 아예 오지 않았습니다.
로그를 보니 DB 연결 타임아웃이었습니다. 원인은 전날 야간 배치가 오래 걸려서 새벽에도 DB 부하가 남아 있었던 것이었습니다. 처음에는 파이프라인 코드 문제라고만 생각했는데, 외부 의존성이 문제였습니다. 재시도 로직이 없어서 한 번 실패하면 그냥 끝나는 구조였습니다.
재시도를 3회 추가하고 대기 시간을 주도록 수정했더니 이후에는 같은 문제가 없었습니다. 파이프라인은 자기 코드만 잘 짜면 되는 게 아니라, 의존하는 시스템이 늦거나 실패할 때를 대비해야 한다는 걸 그때 배웠습니다.
학부 데이터 분석 수업에서 팀 4명이 각자 데이터를 처리하고 결과를 합치는 작업을 했습니다. 처음에는 각자 스크립트를 따로 돌렸는데, 같은 원본 데이터를 쓰면서 전처리 방식이 달라서 결과가 맞지 않았습니다.
그 경험에서 파이프라인은 재현 가능해야 한다는 걸 배웠습니다. 누가 언제 돌려도 같은 입력에서 같은 결과가 나와야 합니다. 이후에는 전처리 단계를 함수로 묶고 공유 저장소에 올려서 모두 같은 코드를 쓰도록 했습니다.
아직 대규모 파이프라인 경험은 없지만, "데이터가 변환되는 각 단계에서 무엇이 달라지는지를 기록해두는 것"이 핵심이라고 생각합니다. 그래야 나중에 결과가 이상할 때 어느 단계에서 문제가 생겼는지 찾을 수 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넛지헬스케어 데이터 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.