이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
졸업 프로젝트에서 공공 데이터를 주기적으로 수집하는 파이프라인이 필요했습니다. 처음엔 크론잡으로 시작했는데 실패 시 알림이 없고 로그도 불편해서 Airflow를 써보기로 했습니다. 처음 셋업에 이틀이 걸렸는데, 가장 어려웠던 건 의존성 버전이 맞지 않아서 계속 에러가 나는 상황이었습니다. 공식 문서와 깃허브 이슈를 뒤지면서 해결했고, 그 과정에서 오히려 내부 구조를 더 깊이 이해하게 됐습니다. 결국 7일 단위 수집 DAG를 만들어서 실패 시 슬랙 알림이 오도록 설정했고, 교수님께 시연할 때 파이프라인이 자동으로 돌아가는 걸 보여드렸습니다. 어려움은 초반 셋업 외에도 DAG 파일 오류가 조용히 넘어가는 경우가 있어서 로그 확인을 습관화하게 됐습니다.
직접 셋업하고 실패하는 과정이 튜토리얼보다 훨씬 빠른 학습이었습니다. 경험을 통해 배웠습니다. 앞으로도 이 방향으로 성장하겠습니다.
인턴 때 매주 수작업으로 엑셀 파일을 정제하는 업무가 있었습니다. 30분씩 걸리는 작업이었는데, 담당자분이 매번 하시는 걸 보고 '이거 스크립트로 자동화할 수 있을 것 같다'고 말씀드렸습니다. 허락을 받고 판다스로 2일 만에 스크립트를 만들었고, 30분짜리 작업이 1분으로 줄었습니다. 담당자분이 '이제 다른 일 할 시간이 생겼다'고 하셨는데, 작은 자동화가 사람의 시간을 돌려주는 걸 처음으로 체감했습니다. 어려움은 예외 케이스 처리였는데, 처음 만든 스크립트가 특수문자가 들어간 행에서 오류를 냈습니다. 나중에 예외 케이스를 10개 더 찾아서 처리했고, 그때부터 항상 엣지 케이스를 먼저 생각하는 습관이 생겼습니다.
자동화는 완성이 아니라 계속 보완하는 것이라는 걸 그때 배웠습니다. 경험을 통해 배웠습니다. 앞으로도 이 방향으로 성장하겠습니다.
데이터 파이프라인 개인 프로젝트에서 수집 → 정제 → 적재 3단계를 Airflow DAG로 만들었습니다. 처음엔 3개를 하나의 태스크로 합쳤는데, 정제 단계에서 오류가 나면 어디서 난 건지 알 수 없었습니다. 각 단계를 별도 태스크로 나누고 의존성을 설정하니, 실패한 지점만 재실행할 수 있게 됐습니다. 전체 파이프라인을 재실행하는 시간이 크게 줄었고, 오류 원인도 즉시 확인할 수 있었습니다. 어려움은 태스크 간에 데이터를 어떻게 전달할지였는데, 처음엔 Xcom을 썼다가 데이터가 크면 성능 문제가 생긴다는 걸 알고 중간 파일로 바꿨습니다. 결과 측면에서는 파이프라인이 3주 동안 큰 오류 없이 돌았습니다.
작게 나눌수록 디버깅이 쉬워진다는 게 파이프라인 설계에서 배운 가장 중요한 원칙입니다. 경험을 통해 배웠습니다. 앞으로도 이 방향으로 성장하겠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 데이터·AI 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.