이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사이드 프로젝트에서 데이터 파이프라인 장애를 늦게 발견하는 문제가 있었습니다. 파이프라인이 조용히 실패해도 알 방법이 없었습니다. 관측성을 확보하려면 로그, 메트릭, 트레이싱이 모두 있어야 한다는 걸 공부하면서 배웠습니다. Airflow 태스크 실패 시 슬랙 알림을 붙이고, 처리 건수를 Prometheus로 수집해 예상 범위를 벗어나면 경보가 뜨도록 했습니다. 처음에는 너무 많은 알람을 설정해서 알람 피로가 생겼고, 핵심 지표 3개만 남기고 나머지는 대시보드로 이동했습니다. 관측성의 목표는 이상 징후를 빠르게 발견하는 것이지, 모든 것을 보는 게 아니라는 걸 그때 배웠습니다.
인턴 기간에 특정 테이블의 일별 행 수가 갑자기 절반으로 줄어든 것을 뒤늦게 발견한 적이 있었습니다. 업스트림 파이프라인 오류였는데, 이미 해당 데이터로 리포트가 발행된 후였습니다. 이후 dbt 테스트를 도입해서 행 수 변화율 임계값 초과, null 비율, 기대 범위 이탈을 매 실행마다 체크하도록 했습니다. 테스트가 실패하면 다음 파이프라인 단계가 실행되지 않도록 의존성을 걸었습니다. 데이터 시스템의 관측성은 인프라 수준뿐 아니라 데이터 수준의 검증도 포함해야 완성된다는 걸 그 경험에서 배웠습니다.
파이프라인이 돌아도 데이터가 이상하면 결과를 신뢰할 수 없다는 게 핵심이었습니다.
데이터 시스템 관측성을 직접 구축한 경험은 아직 많지 않지만, 수업과 스터디에서 배운 내용으로 접근해봤습니다. 관측성은 시스템이 왜 그렇게 동작하는지를 외부에서 파악할 수 있는 정도라고 이해합니다. 데이터 파이프라인에서는 각 단계의 처리량·지연·오류율을 추적하는 것이 핵심입니다.
Great Expectations나 dbt 테스트로 데이터 품질을 코드로 정의하고, Datadog이나 Grafana로 메트릭을 시각화하는 방식이 자주 쓰인다고 알고 있습니다. 아직 경험이 얕아서 실무와 다를 수 있지만, 장애가 났을 때 어디서 부터 봐야 하는지를 빠르게 찾을 수 있는 구조가 관측성의 목적이라고 생각합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 데이터·AI 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.