옵스콘솔 — 배포 파이프라인 관찰 대시보드

PRD

섹션 구성 ↔ 업계 표준 PRD 템플릿 대응

프로젝트 개요

옵스콘솔은 5-20명 규모 개발팀이 배포 파이프라인 이벤트를 단일 대시보드로 관찰하고 이상 발생 시 온콜 담당자에게 즉시 라우팅되는 내부 운영 도구입니다. CI/CD 실행 횟수가 일 수백 건으로 늘어나면서 Slack 공용 채널이 시스템 로그로 포화되어 실제 장애 신호가 파묻히는 문제를 정면으로 겨냥합니다. 장애 감지부터 담당자 paging, 최초 응답까지의 MTTR을 5분 내로 끌어내리는 것이 제품 목표이며, 이를 위해 severity 판정·throttle·escalation 체계를 내장합니다. Vooster로 요구사항을 구조화하고 태스크를 스프린트 단위로 자동 분배하여, SRE 한두 명이 운영 가능한 수준의 내부 툴로 최소 복잡도를 유지합니다. 별도 관측 SaaS(Datadog·NewRelic) 없이도 파이프라인 가시성·알림 정합성 두 문제를 해결합니다. Vooster가 생성한 PRD·태스크 트리를 Claude Code에 그대로 전달해 webhook ingestion·throttle 엔진·Slack 템플릿을 각 2-3일 사이클로 구현했습니다. 내부 배포 완료 후 1개월간 MTTR 중앙값이 12분에서 4분 30초로 단축되어 "ROI가 가장 빨리 나오는 내부 툴" 카테고리로 정착했습니다.

문제 정의

성장 단계 스타트업의 운영팀은 배포 이벤트가 급증할 때 신호와 잡음을 분리하지 못해 장애 대응이 지연됩니다. 현재 대안은 세 가지 부족한 면이 있습니다. 첫째, Slack 채널에 webhook을 직연결하면 성공 빌드까지 모두 섞여 흘러 심각도 분별이 불가능합니다. 둘째, 유료 PagerDuty를 단독 사용하면 온콜은 울리지만 "무엇이, 어느 환경에서, 몇 번째 실패인지" 맥락을 대시보드에서 한눈에 볼 수 없습니다. 셋째, Grafana/Loki 같은 로그 뷰어는 파이프라인 이벤트 의미 분류(build/test/deploy)를 내장하지 않아 팀마다 대시보드를 다시 조립해야 합니다. 넷째, Slack App workflow만으로는 throttle·escalation 같은 상태를 축적·조회할 수 없어 사후 회고가 불가능합니다. 결과적으로 실제 장애 알림이 평균 7-10분 지연 도달하고, 동일 에러가 반복되면 알림 폭주로 오히려 담당자가 notification을 무시합니다. 옵스콘솔은 "이벤트 의미 분류 + severity 기반 throttle + 시간대별 라우팅"을 결합해 대시보드와 온콜을 단일 워크플로로 묶습니다. 장애 대응에서 '무엇이 지금 깨졌고 누구에게 가야 하는가'를 5초 내 답할 수 있는 것이 핵심 설계 원칙입니다. 동시에 "알림의 히스토리"가 영구 기록되어 주간 회고에서 bottleneck을 되짚을 수 있습니다.

타겟 페르소나

페르소나 A — 온콜 당번 SRE / 플랫폼 엔지니어 (가명: 정현우)

Role: 10-15명 규모 개발 조직의 플랫폼팀 엔지니어, 주 1회 야간 온콜 근무 업무 맥락: 근무시간 외 Slack 알림에 즉각 반응해야 하며, 최초 5분 안에 severity 판단이 필요 일상 Pain:

• staging/prod가 섞인 webhook 스트림에서 실제 prod 장애만 골라내는 데 시간 허비
• 동일 에러 반복 알림에 피로가 쌓여 중요한 새 신호를 놓치는 경험 반복
• 이전 배포와의 diff·커밋·작성자를 파악하려면 GitHub/GitLab 여러 탭을 오가야 함
• 사후 회고 시 타임라인 재구성을 위해 Slack 스크롤을 수십 분 반복
• 담당자 handoff 이력이 기록되지 않아 누가 언제 대응했는지 추적 불가 사용 맥락:
• 한밤중 Slack DM → 대시보드 링크 한 번에 pipeline 상태·로그·배포 diff 전부 확인
• 장애 초기 5분 안에 rollback 여부 판단
• 다음 날 아침 incident summary 페이지를 팀에 공유해 회고 자료로 활용 Current alternatives: Slack webhook + PagerDuty 기본 플랜, 직접 짠 log scraper 채택 트리거: 전 분기 야간 장애 대응 중 누락 알림으로 MTTR 22분을 기록하고 회고에서 요구 핵심 니즈: severity 기반 throttle + 환경별 시각 구분 + 최근 배포 diff 통합 뷰

페르소나 B — 배포 승인권 테크리드 (가명: 윤세영)

Role: 제품팀 테크리드, 40-70 PR/주 리뷰 및 prod 배포 승인 담당 업무 맥turing: 배포 직후 10분간 성공/실패 지표 확인 후 다음 작업으로 이동 일상 Pain:

• 여러 서비스 배포 파이프라인 상태를 별도 창으로 열어 확인하는 번거로움
• 팀원 배포 실패를 본인이 먼저 감지해 DM을 보내는 비효율 반복
• 승인 워크플로와 모니터링이 분리돼 있어 승인 후 눈에서 멀어지는 배포가 존재
• 릴리스 노트에 포함할 배포 성공률 수치를 매주 수기로 계산
• 신규 팀원 온보딩 때 "어디서 뭐가 돌아가는지" 구두로 설명해야 하는 소모 반복 사용 맥락:
• 대시보드에서 현재 진행 중 파이프라인 필터링, 실패 시 작성자에게 자동 멘션
• 주간 회고 시 이번 주 배포 성공률·MTTR 지표 추출
• 신규 팀원에게 대시보드 링크 공유로 서비스 지도 즉시 전달 Current alternatives: GitHub Actions 대시보드, Slack 개인 채널 채택 트리거: 서비스 개수가 5개 이상으로 증가해 탭 전환 비용이 임계치를 넘음 핵심 니즈: 서비스별 필터·역할 기반 접근·주간 리포트

페르소나 C — QA/릴리스 매니저 (가명: 한수민)

Role: 중견 B2B SaaS 팀의 릴리스 매니저, 주 2회 prod 릴리스 cadence 관리 업무 맥락: 릴리스 윈도우 전후 파이프라인 상태를 감시하고, 실패 시 hotfix 플로우를 조율 일상 Pain:

• 릴리스 직후 성공/실패 정보를 여러 채널(Slack, PR 댓글, 대시보드)에서 취합해야 함
• 주간 배포 성공률을 경영진 공유용 슬라이드에 수동 기입
• staging 사전 검증 실패와 prod 실패 구분이 Slack 메시지에서 약함 사용 맥락:
• 릴리스 윈도우 기준 24시간 필터로 이 기간의 모든 파이프라인 상태를 스냅샷 조회
• 주간 리포트를 CSV로 내려 분기 회고 자료로 통합 Current alternatives: 스프레드시트 수기 기록 + GitHub Actions 탭 병행 채택 트리거: 릴리스 규모가 확장되며 수기 기록이 한계를 드러냄 핵심 니즈: 시간 범위 필터·CSV export·환경별 성공률 분해

사용자 스토리

• US-001: As an on-call SRE, I want to see only critical-severity pipeline failures in my paging feed, so that I can focus on real incidents without alert fatigue. Acceptance Criteria:

  • severity critical 이벤트만 기본 뷰에 노출되며 info/warn은 접힘 상태
  • 동일 pipeline에서 10분 내 반복 발생 시 throttle되어 카운터만 증가
  • 각 critical 이벤트 카드에 환경(prod/staging) 뱃지가 색으로 구분됨
  • 카드 탭 시 최근 3개 배포 diff와 작성자 정보로 즉시 이동 가능
  • critical 이벤트가 없는 경우 empty state로 안전 상태임을 명시

• US-002: As an SRE, I want unacknowledged pages to escalate to a secondary on-call after 15 minutes, so that a single missed notification does not prolong downtime. Acceptance Criteria:

  • paging 후 15분간 ack이 없으면 2차 담당자에게 자동 라우팅
  • escalation 이벤트는 원본 알림 thread에 reply 형태로 연결되어 history 유지
  • escalation 규칙은 서비스별로 별도 설정 가능
  • escalation 발생 시 audit log에 타임스탬프·원본 담당자·최종 담당자가 기록
  • 30분 초과 시 admin 그룹에 broadcast, 1시간 초과 시 조직 owner 호출

• US-003: As a tech lead, I want to filter pipeline events by service name and environment, so that I can scope my review to the services I own. Acceptance Criteria:

  • 대시보드 상단 필터 bar에서 service, environment 다중 선택 가능
  • 필터 상태가 URL 쿼리에 반영되어 북마크·공유 가능
  • 필터 결과가 비어 있을 때 empty state UI로 오인 방지
  • 최근 필터 조합 5개가 quick-access chip으로 제공
  • 필터는 사용자별 preset으로 저장 가능 (기본/개인/팀 공유)

• US-004: As an on-call responder, I want the Slack alert message to include the last successful deploy's commit SHA, so that I can instantly compare what changed before rolling back. Acceptance Criteria:

  • Slack Block Kit 템플릿에 last-green SHA와 현재 실패 SHA의 short hash 포함
  • "View Diff" 버튼이 GitHub/GitLab diff 페이지로 딥링크
  • 동일 pipeline의 이전 성공이 24시간 이상 이전이면 경고 아이콘 표시
  • 메시지 footer에 throttle 활성 여부 및 누적 억제 건수 노출
  • 메시지에 "ack" / "silence 30m" / "escalate now" 3개 interactive 버튼 배치

• US-005: As an admin, I want to manage on-call rotation and routing rules through a UI, so that I do not need to edit JSON files manually for every schedule change. Acceptance Criteria:

  • 주간 rotation 편집 UI에서 사람·시간대 드래그 앤 드롭으로 변경
  • 변경 사항은 dry-run 모드로 다음 24시간 paging 결과를 미리 시뮬레이션
  • 저장 시 기존 규칙과의 충돌을 validation error로 차단
  • 감사 로그가 기존 저장본과의 diff로 자동 기록
  • 공휴일 override 설정 가능 (국가별 달력 기본값 + 커스텀 날짜)

• US-006: As a tech lead, I want a weekly summary of deploy success rate and MTTR, so that I can discuss operational health in team retros with data. Acceptance Criteria:

  • 매주 월요일 오전 9시 Slack 채널에 요약 메시지 자동 게시
  • 요약에 성공률·평균 MTTR·top 5 flaky pipeline 포함
  • CSV로 내보내기 버튼 제공
  • 전주 대비 증감률이 색상으로 표시
  • 메시지에는 대시보드 해당 주차로 직행하는 딥링크 포함
  • 휴일 주간에는 대체 리포트 시점이 자동 당겨짐

• US-007: As a viewer role team member, I want to browse the dashboard without modifying routing rules, so that I can stay informed without risk of accidental configuration changes. Acceptance Criteria:

  • viewer role에서는 routing·alert-template 편집 UI가 read-only
  • operator role부터 편집 가능, admin만 role 및 audit log 조회
  • 권한 범위를 벗어난 액션은 403 응답과 UI 배너로 안내
  • role 전환은 admin 페이지에서만 가능
  • role 부여 요청은 admin에게 in-app notification으로 라우팅

• US-008: As a release manager, I want to filter deploy events within a specific release window and export success rate as CSV, so that I can include production data in executive release reports. Acceptance Criteria:

  • 대시보드 시간 범위 필터가 custom range 지원
  • 환경·서비스별 성공률·실패 건수를 집계한 summary 행 제공
  • CSV export는 operator 이상 role만 허용, admin audit log에 기록
  • 생성된 CSV 파일명에 조직·기간·세대 정보 포함
  • 대용량 export는 비동기 작업으로 큐잉되어 완료 시 Slack DM 알림

• US-009: As an on-call SRE, I want throttled suppression counts to be visible when the next real alert finally arrives, so that I understand the scale of the noise that was held back. Acceptance Criteria:

  • 억제 해제 후 첫 알림 메시지 footer에 억제 카운트 명시
  • 억제 기간과 해제 시각도 함께 노출
  • throttle 설정 변경 시 기존 억제 상태는 재평가되어 즉시 반영
  • 누적 억제 기록은 pipeline 상세 페이지에 timeline으로 제공
  • 억제 상세에 포함되는 원본 메시지 리스트는 pagination으로 조회

• US-010: As a responder, I want incident post-mortem summaries generated automatically, so that I can focus on writing what went wrong instead of compiling raw timestamps. Acceptance Criteria:

  • ack 완료된 critical 이벤트는 "incident summary" 페이지가 자동 생성
  • 타임라인에 detect → paging → ack → resolved 4 phase의 정확한 타임스탬프
  • 관련 배포 diff와 작성자·리뷰어가 자동 inline
  • 억제된 알림 카운트 및 재발 구간 그래프 포함
  • summary 페이지는 공개 URL로 공유 가능 (조직 내부로 scope 제한)

핵심 기능 명세

F1. Webhook 이벤트 ingestion & classification

목적: GitHub Actions/GitLab CI webhook을 수신해 build/test/deploy 이벤트와 환경(staging/prod)별로 자동 분류 동작:

• webhook endpoint에서 서명 검증 후 payload 파싱
• repository + workflow 이름과 branch pattern을 기반으로 service 이름 resolve
• 이벤트 타입을 build/test/deploy로 정규화 후 타임라인에 기록
• 중복 전송 detection을 위한 idempotency key로 재수신 이벤트 병합
• severity는 기본 info, prod deploy 실패는 critical로 승격
• 환경 분류 실패 payload는 dead-letter 큐로 이동하고 admin 알림 발송
• 신규 repository는 최초 수신 시 관리자 승인 대기 상태로 격리 우선순위: MUST 성공 신호: webhook → 대시보드 반영 지연 중앙값 3초 이하, 분류 정확도 98% 이상

F2. severity 기반 throttle & escalation engine

목적: 반복 알림 폭주를 억제하고 미응답 시 2차 담당자에게 자동 라우팅 동작:

• 동일 pipeline·severity 조합이 10분 내 재발생 시 카운터만 증가, 신규 알림 억제
• critical paging이 15분 이내 미ack이면 2차 담당자에게 escalation
• throttle window와 escalation 시간은 서비스별 override 가능
• escalation 이벤트는 원본 alert thread에 reply로 링크되어 history 연결
• 담당자별 누적 미응답 비율이 metrics로 집계
• throttle 설정 변경 시 기존 억제 상태를 즉시 재평가하여 반영
• 수동 "silence" 버튼으로 예정된 유지보수 윈도우 동안 알림 일시 정지 우선순위: MUST 성공 신호: 동일 에러 알림 억제율 80% 이상, escalation 발생률 5% 이하

F3. Slack alert template & deploy-diff context

목적: 환경·severity별 Block Kit 메시지 템플릿과 이전 성공 대비 변경점을 즉시 확인 가능한 컨텍스트 제공 동작:

• 환경(staging/prod) × severity(info/warn/critical) 키 조합별 Block Kit 템플릿
• 메시지에 last-green commit SHA, 현재 실패 SHA, diff 링크 포함
• 담당자 멘션은 현재 rotation 결과로 동적 치환
• 메시지 footer에 throttle 현황과 dashboard 딥링크
• Template 변경은 admin UI에서 preview 후 저장
• 템플릿 버전 관리로 롤백 가능
• 다국어(ko/en) 템플릿 동시 유지, 채널 설정으로 선택 우선순위: MUST 성공 신호: 메시지 내 "View Diff" 클릭률 40% 이상

F4. 역할 기반 대시보드 & 주간 리포트

목적: viewer/operator/admin 세 역할별 UI 접근 제어와 주간 집계 리포트로 운영 투명성 확보 동작:

• 역할별 라우트 접근 제어 미들웨어 및 UI element 가시성 분기
• 대시보드 필터·북마크 URL 쿼리 반영
• 매주 자동 집계 리포트를 Slack·이메일로 발송
• CSV 내보내기는 operator role 이상만 허용
• 모든 state 변경은 audit log에 기록
• role 전환은 admin 페이지에서만 가능하며 2-factor 재인증 요구
• 주간 리포트에는 top 5 flaky pipeline 하이라이트 포함 우선순위: SHOULD 성공 신호: 팀당 주간 리포트 오픈률 70% 이상

F5. audit log & 변경 이력 뷰어

목적: routing·alert-template·rotation 변경을 diff로 영구 기록하고 admin이 retrospectively 조회 가능하게 함 동작:

• 모든 admin·operator 쓰기 작업을 author·timestamp·diff 형태로 저장
• admin 페이지에서 시간 범위·작업자·대상 객체별로 필터 조회
• 각 레코드에 "이 시점 상태로 복원" 버튼 제공 (preview 후 확정)
• 90일 이상 레코드는 cold storage로 이관되어 비용 최적화
• 외부 SIEM으로 JSON-L 로그 내보내기 지원
• 검색 필터 조합을 저장 preset으로 관리
• 주요 이벤트(권한 부여·rotation 변경)에는 조직 owner 알림 자동 발송 우선순위: COULD 성공 신호: 사후 장애 회고에서 audit 조회 사용 건수 월 5건 이상

성공 지표

각 지표는 내부 대시보드에 실시간 집계되어 주간 회고 자료로 자동 export됩니다.

• MTTR 중앙값: prod critical 이벤트 발생 ~ 최초 ack 시간. 목표 5분 이하, 현재 추정 12분 → 58% 단축.
• acknowledge rate: critical paging 15분 이내 ack 비율. 목표 95% 이상, baseline 74%.
• 10분당 알림 노이즈 차단률: throttle로 억제된 중복 알림 비율. 목표 80% 이상.
• incident → Slack lag: webhook 수신 ~ Slack 메시지 전송 지연. 목표 p95 3초 이하.
• 주간 false-positive 알림 건수: 실제 action이 없는 critical 알림 수. 목표 주당 5건 이하.
• dashboard TTI(time-to-interactive): 대시보드 첫 진입 2초 이내 인터랙션 가능. p95 기준.
• 배포 성공률 가시성 커버리지: 전체 서비스의 95% 이상이 자동 분류되어 대시보드에 노출.

비기능 요구사항

• 성능: webhook 수신 → 대시보드 반영 지연 p95 3초 이하, Slack 메시지 발송 p95 5초 이하
• 신뢰성: webhook 중복 수신 시 idempotency key로 동일 이벤트 1회만 처리, at-least-once 배송에서 exactly-once 처리 보장
• 권한: viewer/operator/admin 3단계 역할, 모든 쓰기 작업은 operator 이상 + audit log 필수
• 감사: routing rule·alert template 변경은 diff 형태로 audit log 영구 보관, 최소 90일 조회 가능
• 관측: 내부 지표(Prometheus)로 throttle 누적·escalation 발생률·Slack 전송 지연 모두 수집
• 다국어: ko/en UI 동시 지원, 알림 메시지 언어는 채널 설정으로 선택
• 보안: webhook 서명 검증(HMAC-SHA256) 필수, admin 토큰은 조직별 rotation 매 90일
• 재해 복구: DB 일 1회 스냅샷 + 트랜잭션 로그 보관, RPO 15분·RTO 2시간 목표

온콜 플로우 & 알림 라우팅

옵스콘솔의 온콜·라우팅 체계는 "severity 판정 → throttle 윈도우 → rotation 매칭 → escalation"의 4단계 파이프라인으로 동작합니다. 각 단계는 독립적으로 설정 가능하며, 변경 시 audit log에 diff 형태로 기록되어 운영 회고 시 추적 가능합니다.

• severity 분류 기준:
  • info: 성공 빌드, staging 실패, feature flag 변경 이벤트
  • warn: prod test 실패, 동일 에러 3회 이상 반복, slow query 임계 초과
  • critical: prod deploy 실패, 헬스체크 실패, 수동 critical 플래그, 커넥션 풀 고갈
• throttle window: 동일 pipeline·severity 조합이 10분 이내 재발하면 신규 알림을 억제하고 카운터만 증가. 억제 해제 후 첫 이벤트에는 억제 누계를 표기하여 침묵 기간 동안의 규모를 즉시 인지.
• 시간대별 rotation: 근무시간(KST 09:00-18:00)은 1차 담당 테크리드, 야간·주말은 1차 온콜 SRE. 각 서비스별로 별도 rotation 설정 가능하며, 공휴일은 관리자가 override 지정.
• escalation 규칙: critical paging이 발송된 뒤 15분 이내 ack이 없으면 2차 담당자에게 자동 라우팅. 30분 초과 시 admin 그룹 전체에 broadcast. 1시간 초과 시 조직 owner에게 SMS fallback까지 확장.
• Slack Block Kit template: 환경(staging/prod) × severity(info/warn/critical) 6개 키 조합별 메시지 포맷을 admin UI에서 preview 후 저장. 템플릿은 버전 관리되어 롤백 가능.
• 이벤트 흐름: webhook 수신 → 서명 검증 → severity 분류 → throttle 체크 → rotation 담당자 resolve → Block Kit 렌더 → Slack 전송 → ack 대기 → 미ack 시 escalation. 각 단계는 독립 로그로 남아 사후 분석 가능.
• ack 방식: Slack 메시지의 interactive button, 대시보드 ack 버튼, API 엔드포인트 세 가지 경로 모두 허용. 어느 경로로 ack해도 동일 이벤트 state가 전파됨.
• 미응답 안전장치: escalation chain 끝까지 도달해도 미ack이면 대시보드 상단에 배너가 뜨고, 다음 근무 rotation에게 자동 hand-off.
• post-incident 리뷰: ack 완료된 이벤트에 자동 생성되는 "incident summary" 페이지에서 타임라인·관련 배포 diff·억제된 알림 카운트가 한 데 모인다.

스코프 경계

V1에서는 다음 범위를 제외합니다.

• ML 기반 이상 탐지(anomaly detection) — 규칙 기반 severity로 MVP 검증 후 추후 도입
• 자동 rollback action — paging까지만 하고 실제 되돌리기는 수동 승인 유지
• 고객 대면 status page — 내부 운영 초점, 외부 status는 별도 SaaS(StatusPage)에 위임
• 인프라 비용·리소스 분석 — 파이프라인 이벤트 중심, 과금 metric은 scope 밖
• 장기 로그 aggregation — 90일 이상 보관은 기존 로그 플랫폼에 위임
• Kubernetes/인프라 헬스체크 — 파이프라인 이벤트만 관심, 런타임 상태는 별도 도구에 위임
• SSO/SAML 연동 — MVP는 Clerk 기본 인증, 엔터프라이즈 SSO는 PMF 이후 검토

기술 스택 & 아키텍처 개요

• Frontend: Next.js + React, Tailwind CSS, shadcn/ui 기반 컴포넌트. 대시보드 SSR + 실시간 갱신은 SSE.
• API: tRPC (타입 안전 서버-클라이언트 통신)로 routing·rule·audit API 전부 type-safe.
• DB: PostgreSQL (Prisma ORM). 이벤트 테이블은 timestamp + service 복합 인덱스.
• Queue: 웹훅 ingestion은 Vercel Edge Function + Postgres Listen/Notify 조합으로 별도 MQ 없이 스케일.
• 외부 연동: Slack Web API(Block Kit), PagerDuty(optional, 상위 escalation), GitHub/GitLab Webhooks.
• 배포: Vercel(앱) + Supabase(DB), Vercel Cron으로 주간 리포트 스케줄.
• 관측: OpenTelemetry로 tRPC·webhook 처리 구간 trace 수집, Grafana Cloud로 export.

주요 제약은 "내부 운영 툴" 포지셔닝 — 단일 조직 내 사용을 전제로 멀티테넌시 분리는 하지 않고 조직 ID로만 파티셔닝. 외부 SaaS 제공 시에는 별도 아키텍처 재설계 필요. 또한 장애 대응 자체의 자동화(auto-rollback, 자동 복구 playbook)는 현 phase의 scope를 벗어나며, 옵스콘솔은 '관찰·라우팅·기록'의 세 축에 집중합니다.

태스크 트리

Sprint 1 — 수신·관측 기본

파이프라인 이벤트 수신과 기본 대시보드 구현

• [TASK-001] 파이프라인 이벤트 수신 엔드포인트 DONE (complexity: 3, urgency: 5, importance: MUST)

  GitHub Actions 및 GitLab CI webhook을 수신하여 이벤트 타입·환경별로 분류·저장하는 API 엔드포인트 구현.

  • ST-001-1: Webhook 수신 라우터 구현 DONE
  • ST-001-2: 이벤트 타입·환경별 분류 로직 DONE

• [TASK-002] 배포 상태 대시보드 기본 뷰 IN_PROGRESS (complexity: 4, urgency: 4, importance: MUST)

  파이프라인 이벤트를 실시간으로 시각화하는 대시보드 기본 화면 구현.

  • ST-002-1: 파이프라인 목록 컴포넌트 DONE
  • ST-002-2: 실시간 폴링 또는 SSE 연동 IN_PROGRESS

Sprint 2 — 온콜·알림

온콜 라우팅 룰 엔진과 슬랙 알림 템플릿 구현

• [TASK-003] 온콜 라우팅 룰 엔진 BACKLOG (complexity: 5, urgency: 3, importance: MUST)

  서비스명·시간대·심각도를 조합한 조건 트리로 온콜 담당자를 자동 배정하는 룰 엔진 구현. 룰 매칭은 우선순위가 높은 조건부터 평가하는 결정 테이블(JSON 배열) 구조를 사용하며, 동일 조건 충돌 시 먼저 등록된 룰이 우선한다.

• [TASK-004] 슬랙 알림 템플릿 엔진 BACKLOG (complexity: 4, urgency: 3, importance: SHOULD)

  환경(staging/prod)과 심각도(info/warn/critical)를 키로 매핑된 Slack Block Kit 템플릿을 런타임에 조합·발송하는 엔진 구현. 알림 throttle 로직과 연동하여 중복 발송을 억제한다.

  • ST-004-1: Block Kit 템플릿 정의 파일 BACKLOG