운영 중 · 2021–26
이슈 트래킹·장애 추적 체계
작업과 장애의 유형, 원인, 조치 내용을 이슈와 문서에 기록해 다음 대응에 활용했습니다.
기간2021–2026 (상시)
소속래브라도랩스(LabradorLabs)
역할데이터 엔지니어
이슈 관리장애 추적RCA
작업 요약
작업·장애 이슈 1,000건+ 관리
이전 장애 기록을 다음 대응에 활용했습니다
5년 동안 1,000건 넘는 작업과 장애를 이슈로 기록했습니다. 비슷한 장애가 다시 발생하면 이전에 확인한 원인과 조치 내용을 찾아볼 수 있도록 했습니다.
RCA에는 증상, 발견 시각, 원인, 조치, 재발 방지 항목을 같은 순서로 기록해 다음 대응에서 이어서 확인할 수 있게 했습니다.
배경
데이터 수집·처리 파이프라인과 DB 운영은 정상 작업과 긴급 장애가 끊임없이 섞여 들어옵니다. 이슈가 흩어지면 무엇이 진행 중인지, 어떤 원인으로 발생했는지, 어떻게 막았는지가 기록에 없어 담당자에게 다시 물어야 합니다.
- 작업·장애·문서가 연결되지 않으면 장애 추적성과 재발 방지가 어려움
- 긴급(Emergency) 온콜 대응은 빠른 인지뿐 아니라 사후 원인 규명·증거 보존이 필요
- 복제 지연·데이터 정합성처럼 장기 추적이 필요한 이슈는 단발 티켓으로는 관리 불가
접근
- 업무 유형 태그 체계(예: 장애·개선·신규 개발)로 이슈와 문서를 1:1로 연결해 장애·작업의 작업과 문서 연결
- 장애 발생 시 표준 포맷의 원인 분석(RCA) 보고서를 직접 작성 — 장애 현황 · 발견 시각 · 원인 분석 · 조치 · 재발 방지
- 수집·처리 파이프라인의 상태 플래그(예:
processed)로 단계별 진행을 추적해 누락·재처리를 체계화 - 복제 지연·데이터 정합성처럼 장기 추적이 필요한 이슈는 별도 추적 단위로 묶어 지속 트래킹
- 장애 보고서를 위해
error.log·syslog등 증거 보존 원칙 수립 (해결 전 디렉터리 삭제 금지 등) — 원인 분석에 필요한 기록을 보존
예를 들어 Kubernetes CoreDNS·Airflow 스케줄러의 CrashLoopBackOff, 노드 Inode 고갈로 인한 Pod Eviction 같은 장애를 직접 원인 분석해 RCA로 정리했습니다.
결과
1,000건 이상5년간 작업·장애 이슈를 직접 관리, 완료율 약 85%
57건 이상긴급(Emergency) 온콜 이슈를 추적·대응
작업과 문서 연결업무 유형 태그로 이슈와 문서를 1:1 연결해 장애·작업을 끊김 없이 추적
장애 대응 절차장애 확인 → 원인 분석 → 재발 방지 순서로 대응 절차를 통일
역할
데이터 엔지니어로서 이슈 인입부터 RCA·재발 방지까지의 사이클을 단독으로 설계·운영하고 표준화했습니다. 업무 유형 태그·RCA 포맷·증거 보존 원칙을 세워 팀원이 이전 작업과 장애 조치를 찾아볼 수 있도록 했습니다.
개별 장애 사례(CoreDNS·Airflow CrashLoopBackOff, Inode 고갈 Pod Eviction 등)와 파이프라인 운영은 별도 항목으로 정리.
근거 자료
아래 기록에 근거해 정리했습니다. 내부 원문 경로를 표시하며, 비공개 원문 파일은 이 페이지에서 제공하지 않습니다.
ai/sources/career/interviews/2026-09-03-general-numbers-01.mdai/wiki/people/career-timeline.md