관측성 도구로 실패 추적하기: 로그, 메트릭, 대시보드

개념

관측성(Observability)이란

시스템 안에서 무슨 일이 일어나고 있는지, 밖에서 들여다보지 않고도 남겨진 흔적(로그, 지표)만으로 알 수 있는 정도를 관측성이라 한다. CI/CD 파이프라인이 매일 수십~수백 번 돌아가는 조직에서는, 실패 하나하나를 사람이 눈으로 쫓는 게 불가능하다 — 관측성 도구가 이걸 대신한다.

로그(Logs) — 무슨 일이 있었는지의 기록

모듈 9(레슨 4)에서 배운 로그 파일 개념이 CI/CD에서도 그대로 쓰인다. 각 파이프라인 실행마다 어떤 명령이 실행됐고, 어떤 출력이 나왔는지 로그로 남는다. 실패했을 때 이 로그를 읽으면 정확히 어느 지점에서 무엇이 잘못됐는지 알 수 있다.

메트릭(Metrics) — 숫자로 된 추세

개별 로그를 하나씩 읽는 대신, 숫자로 집계된 지표를 보면 추세를 파악할 수 있다.

- 파이프라인 평균 실행 시간
- 일별 실패율
- 가장 자주 실패하는 테스트 Top 10
- 레슨 5에서 배운 격리된 테스트 개수 추이

이건 모듈 6(레슨 5)에서 배운 품질 지표를, CI/CD 파이프라인 운영이라는 영역에 적용한 것이다.

대시보드(Dashboard) — 한눈에 보는 현황판

로그와 메트릭을 시각화해서 한 화면에 모아둔 것이 대시보드다. "지난 일주일간 파이프라인 실패율이 계속 올라가고 있다"는 추세를 대시보드에서 발견하면, 개별 실패를 하나하나 조사하기 전에 **"뭔가 구조적인 문제가 생기고 있다"**는 신호를 먼저 알아챌 수 있다.

실패 패턴 읽어내기

관측성 도구의 진짜 가치는 개별 실패가 아니라 패턴을 보는 데 있다.

- 특정 요일·시간대에만 실패가 몰린다 → 배치 작업 등 외부 요인과 겹치는지 확인
- 특정 테스트 파일에서만 실패가 반복된다 → 그 영역의 코드나 테스트 설계에 문제
- 실행 시간이 점점 길어지고 있다 → 테스트 스위트가 비대해지고 있다는 신호(모듈 11 레슨 4의 자동화 부채)

이런 패턴은 모듈 5(레슨 8)에서 배운 "발견하며 그리는" 탐험적 접근과 비슷하다 — 정해진 질문에 답하는 게 아니라, 데이터를 계속 들여다보며 "이상한 게 없는지" 스스로 발견해나가는 과정이다.

이 모듈 전체를 종합하기

이 마지막 레슨은 모듈 14의 모든 레슨을 하나로 묶는다 — CI/CD의 기본 개념(레슨 1)을 GitHub Actions 워크플로(레슨 2)로 구현하고, Docker(레슨 3)로 환경을 일관되게 유지하고, 품질 게이트(레슨 4)로 무엇이 배포를 막을지 정하고, False Alarm(레슨 5)을 줄여 신호를 깨끗하게 만든 다음, 마지막으로 관측성 도구로 그 신호들을 지속적으로 관찰하고 개선하는 것까지가 "스스로 돌아가고, 스스로 신뢰받는" CI/CD 시스템의 완결된 그림이다.

실무에서 왜 필요한가

"이번 주에 CI가 유독 자주 실패하는 것 같은데, 왜 그런지 모르겠다"는 막연한 느낌을, 대시보드의 실패율 추이 그래프 하나로 "정말 그런지, 언제부터 그런지, 어느 영역인지" 객관적으로 확인할 수 있다. 관측성 도구를 활용하는 QA는 개별 버그를 잡는 것을 넘어, 파이프라인 자체의 건강 상태를 관리하는 역할로 성장할 수 있다.

실습 과제

과제 1 — 패턴 해석하기 (10분)

대시보드에서 "매주 월요일 오전에만 파이프라인 실패율이 유독 높다"는 패턴을 발견했다고 하자. 어떤 가설을 세워볼 수 있을지 2가지 적는다.

과제 2 — 추적할 지표 설계하기 (10분)

이 모듈 전체(레슨 1~6)에서 배운 내용을 바탕으로, 우리 팀의 CI/CD 파이프라인이 "건강한 상태"인지 판단하기 위해 대시보드에 넣고 싶은 지표 3가지를 선정하고 이유를 적는다.

자가 체크리스트

• 로그·메트릭·대시보드의 역할 차이를 설명할 수 있다
• 개별 실패를 보는 것과 패턴을 보는 것의 차이를 설명할 수 있다
• 실행 시간이 점점 길어지는 것이 왜 자동화 부채의 신호인지 설명할 수 있다
• 이 모듈의 레슨 1~6이 어떻게 하나의 완결된 시스템으로 이어지는지 설명할 수 있다

흔한 실수

• 실패가 날 때마다 로그만 각각 확인하고, 누적된 패턴은 보지 않는다. 구조적인 문제는 개별 로그가 아니라 추세에서 드러난다.
• 대시보드를 만들어놓고 정기적으로 들여다보지 않는다. 관측성 도구는 계속 관찰해야 가치가 생긴다.
• 모든 지표를 다 추적하려 한다. 이 모듈에서 배운 것처럼, 정말 중요한 신호(핵심 실패율, 자동화 부채 신호)에 집중하는 것이 낫다.

참고 자료

• GitHub Actions 공식 문서 — Monitoring workflows — 워크플로 실행 이력과 로그 확인의 공식 가이드
• Google SRE Book — Monitoring Distributed Systems — 관측성과 모니터링의 대표적 참고 자료