이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
개인 프로젝트에서 데이터 파이프라인을 cron 대신 Airflow로 관리해보려고 처음 설치하였습니다. 도커로 띄우는 공식 예제를 따라했으나, 환경 변수 설정이 맞지 않아서 웹서버가 올라오지 않았습니다. 에러 로그를 읽는 데만 두 시간이 걸렸고, AIRFLOW__DATABASE__SQL_ALCHEMY_CONN 형식이 버전마다 다르다는 것을 몰라서 구버전 예제를 따라한 것이 원인이었습니다. 해결 후 DAG를 처음 만들었으나, 파이썬 임포트 경로가 컨테이너 안과 로컬이 달라서 task가 실패하였습니다.
로컬 개발 환경과 컨테이너 환경의 차이를 의식해야 한다는 것을 이때 처음 배웠습니다. 경험을 통해 배웠습니다. 앞으로도 이 방향으로 성장하겠습니다.
스터디에서 공동으로 Airflow로 매일 아침 9시에 리포트를 생성하는 파이프라인을 만들었어요. 그런데 실제로는 오전 12시에 실행됐어요. Airflow가 UTC 기준이라는 걸 몰랐던 거예요. cron 표현식에 0 0 * * *를 쓰면 UTC 자정, 즉 한국 기준 오전 9시라는 걸 뒤늦게 이해했어요. 이 경험 이후로 스케줄 설정할 때 타임존 기준을 꼭 먼저 확인하게 됐어요. 또 DAG를 처음 등록하면 과거 실행분을 소급해서 한꺼번에 돌리는 catchup 기본값 때문에 태스크가 갑자기 수십 개 쌓인 경험도 했어요.
catchup=False를 설정해야 한다는 걸 이때 알았어요.
공부용으로 만든 Airflow 파이프라인에서 특정 태스크가 일주일에 두세 번씩 실패했는데 원인을 찾기 어려웠어요. 외부 API를 호출하는 태스크였는데, 로그를 보면 타임아웃 에러였어요. retry 설정을 추가했더니 대부분 두 번째 시도에서 성공했어요. 근데 세 번 다 실패하는 경우가 있어서 이메일 알림을 붙였어요. 이때 처음으로 안정적인 파이프라인은 실패를 가정하고 설계해야 한다는 걸 배웠어요. Airflow를 개인 프로젝트에서만 써봐서 실무 규모는 모르지만, 실패 감지와 재시도 전략이 운영의 핵심이라는 걸 느꼈어요.
이 경험 덕분에 한 단계 성장할 수 있었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 카카오 SRE 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.