Lecture/77/02-STAGE2-FIND-PROBLEMS.md

# 2단계 · 문제를 숫자로 찾기

- 교시: 3교시 강의 (11:00~11:50) · 4교시 [Lab 02](../../Last3Mon/77/LAB-02-Q-FIND-PROBLEMS.md) 실습 5개 (12:00~12:50)
- 이 단계가 끝나면: 실패를 원인(노드 · 메시지)으로 묶어 고칠 일의 수와 순서를 정하고, 오류율에 안 잡히는 실패(답 못 함)를 따로 세고, 평소와 다른 시간대를 정의(묶기 · 비교 기준 · 문턱)로 찾고, 비교 기준이 판정을 바꾼다는 것을 재고, 수와 비율을 나눠 보고, LLM 요약의 숫자를 Code로 확인할 수 있다.
- 숫자: 모두 강사 노트북 실측입니다 (10/31, 정답 워크플로우를 학생 순서대로 1회). 두 주 기록의 숫자는 누가 세어도 같습니다. 출력 전부는 수업 뒤 공개되는 `Last3Mon/77/answers/LAB-TEST-RESULT.md`에 있습니다.
- 실습 가리키기: "Lab 02 예제 1"은 4교시 [Lab 02 문서](../../Last3Mon/77/LAB-02-Q-FIND-PROBLEMS.md)의 그 절입니다.

```mermaid
flowchart LR
  A["1. 원인으로 묶기"] --> B["2. 오류가 아닌 실패"] --> C["3. 이상 시간대"] --> D["4. 비교 기준"]
  D --> E["5. 수와 비율"] --> F["6. 글은 LLM ·<br/>숫자 확인은 Code"] --> G["7. 사건으로 엮기"] --> H["8. 요청문으로"]
```

## 0. 이 시간 (50분)

| 시간 | 절 · 개요 | 하는 일 |
| --- | --- | --- |
| 11:00~11:08 | 1 · 개요 15장 | 오류 21건 = 원인 둘, 묶기와 파레토 |
| 11:08~11:14 | 2 · 개요 16장 | 오류가 아닌 실패, 답 못 함 34건 |
| 11:14~11:24 | 3 · 4 · 개요 17~18장 | 이상 탐지의 세 가지, 비교 기준과 기간 |
| 11:24~11:30 | 5 · 개요 19장 | 수와 비율, 다시 묻는 주제 |
| 11:30~11:40 | 6 · 7 · 개요 20~21장 | LLM 요약과 숫자 확인, 사건 타임라인 |
| 11:40~11:50 | 8 · 9 · 확인 질문 | 요청문, 자주 하는 실수 |

### 4교시 Lab 02에서 이어서 하는 것

| 4교시 실습 (시각) | 이 강의의 절 | 실습에서 하는 일 | 쓰는 파일 · 명령 |
| --- | --- | --- | --- |
| Lab 02 예제 1 (12:00~12:12) | 1 · 2 | 실패 묶음 · 답 못 한 주제 | `my-work/log-report.json`에 더함, 테스트 `cases/lab02.json` (0/6 → 3/6) → `OPS.md` 3.1 |
| Lab 02 예제 2 (12:12~12:22) | 3 · 7 | 이상 시간대 | 테스트 `cases/lab02.json` 6/6, `call my-log-report requests/two-weeks.json` |
| Lab 02 예제 3 (12:22~12:28, 에이전트 없이) | 4 | 기간을 바꾸면 문턱 · 이상이 바뀐다 | `test cases/lab02-periods.json -v` → `OPS.md` 3.2 |
| Lab 02 과제 1 (12:28~12:38) | 5 | 답했는데 다시 묻는 주제 | 테스트 `cases/lab02-challenge.json` → `OPS.md` 3.3 |
| Lab 02 과제 2 (12:38~12:50) | 6 | LLM 세 문장 요약 · 숫자 확인 | `my-work/log-summary.json` (새로), 테스트 `cases/lab02-challenge2.json` → `OPS.md` 3.4 |

## 1. 문제 목록은 원인으로 묶는다 (4교시 Lab 02 예제 1)

### 일반 설명

> **생활 속 예 · 반품 사유표.** 가게에 반품이 21건 들어왔을 때 한 건씩 보면 21가지 일입니다. 사유로 묶으면 "사이즈가 안 맞음 16건, 불량 5건" — 고칠 일은 둘이고, 사이즈 표를 먼저 고치면 반품 대부분이 사라집니다. 고치는 단위는 "건"이 아니라 "사유(원인)"입니다.

**오류 묶기(error grouping).** 같은 원인의 실패는 한 번 고치면 함께 사라집니다. 그래서 운영 도구는 오류를 "지문(fingerprint)"으로 묶어 보여 줍니다 — Sentry는 스택 · 메시지로, Datadog · CloudWatch는 오류 종류 · 서비스로 묶습니다. 오늘은 (`error_node`, `error_message`) 두 칸이 지문입니다.

**파레토(80/20).** 현장의 문제는 대개 몇 개의 원인이 대부분을 차지합니다. 묶어서 많은 순으로 놓으면 맨 위 한두 줄이 대부분입니다. 그 줄부터 고치면 같은 노력으로 가장 많이 줄어듭니다.

| 보기 | 일의 수 | 순서 |
| --- | --- | --- |
| 건마다 | 21 | 정할 수 없음 |
| 원인마다 | 2 | 많은 순 (16 → 5) |

### 오늘 실습에서

(Lab 02 예제 1, 두 주)

| 묶음 | 건수 | 고칠 곳 |
| --- | --- | --- |
| `Search FAQ` · `timeout of 1000ms exceeded` | **16** | 워크플로우 (FAQ 검색 timeout · 재시도) |
| `Answer` · `429 Rate limit reached for requests` | 5 | LLM 사용량 한도 · 대체 경로 (75 · 72일차) |

- 오류 21건 = 원인 2개. 16건의 timeout이 76%입니다.

## 2. 오류가 아닌 실패: 답하지 못한 질문 (4교시 Lab 02 예제 1)

### 일반 설명

> **생활 속 예 · "찾는 물건 없음" 메모.** 손님이 "와이파이 공유기 있어요?" 하고 빈손으로 돌아간 일은 반품도 결제 오류도 아니라 장부의 어디에도 안 남습니다. 그런데 그런 손님이 34명이고 모두 같은 물건을 찾았다면, 그것을 들여놓는 것이 가장 큰 일입니다. 계산대 옆에 "찾는 물건 없음" 메모를 따로 모아야 보입니다.

**성공으로 끝난 실패.** 워크플로우는 정상적으로 "모르겠으니 사람에게 넘긴다"를 했습니다. `status`는 `success`라 오류율에 잡히지 않습니다. 하지만 사용자는 답을 못 받았고 담당자 일이 늘었습니다. 이런 실패는 **따로 정의하고 세야** 보입니다.

| 업계의 이름 | 뜻 | 오늘 |
| --- | --- | --- |
| 자동 해결률 (deflection rate, containment rate) | 사람 없이 끝난 비율 | `자동 답변` / 전체 |
| 상담원 이관율 (escalation · handoff rate) | 사람에게 넘긴 비율 | `담당자 연결` / 전체 = `unanswered_rate` (Lab 03) |
| 대체 응답 비율 (fallback rate) | "모르겠습니다"로 답한 비율 | `잠시 후` 등 |

챗봇 · 콜센터 · 헬프데스크에서는 오류율보다 이관율을 더 중요하게 봅니다. 사용자에게는 둘 다 실패이기 때문입니다.

**고칠 곳이 다르다.** 오류 묶음은 대개 워크플로우나 바깥 서비스를 고치고, 답 못 한 주제는 대개 **콘텐츠**(FAQ · 문서)를 고칩니다. 같은 문제 목록 안에서도 고칠 사람이 다릅니다 (3단계 2절).

### 오늘 실습에서

- 담당자 연결 34건이 **모두 와이파이** 주제였습니다 (Lab 02 예제 1). `curl -s 'localhost:8800/faq?q=와이파이'`의 `results`가 비어 있습니다 — FAQ에 와이파이 항목이 없습니다.
- 건수로는 오류(21)보다 많지만 오류율(3.15%)에는 하나도 안 잡혔습니다. 두 주 이관율은 34 / 666 = 5.11%입니다.

## 3. 이상 시간대: 평소와 크게 다른 시간 (4교시 Lab 02 예제 2)

### 일반 설명

> **생활 속 예 · 시간대별 매출표의 빈칸.** 평소 시간당 10건씩 팔리던 가게가 9시에만 0건이라면 그 시간에 무슨 일(카드 단말기 고장?)이 있었던 것입니다. 손님이 1명뿐인 새벽 시간의 0건은 이상하지 않습니다. "손님이 충분히 있었는데 평소보다 훨씬 나빴던 시간"만 골라야 진짜 사건입니다.

**이상 탐지(anomaly detection)의 세 가지.** 무엇으로 묶나(시간), 평소는 무엇인가(비교 기준, baseline), 얼마나 달라야 이상인가(문턱, threshold). 셋 다 사람이 정하는 정의입니다.

| 방법 | 평소 | 이상 | 쓰는 곳 |
| --- | --- | --- | --- |
| 배수 문턱 (오늘) | 기간 전체 오류율 | 그 3배 이상 · 5건 이상 · 오류 1건 이상 | 간단한 보고서 |
| 고정 문턱 | 정해 둔 값 (SLO) | 넘으면 | 알림 (3단계) |
| 통계 (z-점수 · 이동 평균 · EWMA) | 최근 평균과 흔들림 | 평균에서 크게 벗어남 | 모니터링 도구 |
| 계절성 모델 | 같은 요일 · 같은 시간 | 예측에서 벗어남 | Datadog · CloudWatch의 이상 탐지 |

**배수 문턱을 풀어 말하면: "평소의 3배 넘게 나빴던 시간, 단 실행이 너무 적은 시간은 빼고."**

1. **평소를 정한다** — 기간 전체 오류율. 두 주면 21 / 666 = 0.0315 (3.15%).
2. **문턱을 정한다** — 평소의 3배. 0.0315 × 3 = **0.0945 (9.45%)**. 평소의 "몇 배"로 선을 그어서 배수 문턱이라고 부릅니다.
3. **세 조건을 모두 맞는 시간만 이상으로 고른다.**

| 조건 | 없으면 생기는 일 |
| --- | --- |
| 오류율이 문턱(3배) 이상 | 기준선이 없어 어느 시간이 "나쁜지" 정할 수 없음 |
| 실행 5건 이상 (최소 건수) | 새벽에 1건 돌고 1건 실패한 시간도 100%로 잡힘 — 사건이 아니라 운 |
| 오류 1건 이상 | 오류 0인 기간(첫 주)은 문턱도 0이라 모든 시간이 "0 ≥ 0"으로 걸림 |

- 계산과 설명이 쉬워("평소의 3배") 주간 보고서 같은 **간단한 보고서**에 맞습니다. 대신 요일 · 시간대마다 원래 다른 평소(월요일 아침은 늘 바쁨)는 보지 못합니다 — 그것은 표 아래 칸의 통계 · 계절성 방법(모니터링 도구)이 합니다.

**최소 건수.** 1건 중 1건 실패도 오류율 100%입니다. 표본이 작은 시간을 빼야 진짜 이상이 남습니다 (1단계 6절의 표본 크기와 같은 질문).

### 오늘 실습에서

(Lab 02 예제 2, 두 주, 전체 오류율 0.0315 → 문턱 0.0945)

| 이상 시간대 | 실행 · 오류 | 오류율 |
| --- | --- | --- |
| 10/26 (월) 09시 | 16 · **16** | 100% |
| 10/29 (목) 15시 | 7 · 5 | 71.4% |

- 첫 주는 오류 0건이라 `[]`.

## 4. 비교 기준을 고르는 일 (4교시 Lab 02 예제 3)

### 일반 설명

> **생활 속 예 · "평소보다 많이 먹었다"의 평소.** 명절 연휴 동안 먹은 양을 기준으로 하면 오늘 저녁은 "적게" 먹은 것이고, 평일 기준이면 "많이" 먹은 것입니다. "평소보다"라는 말은 평소를 언제로 잡느냐에 달렸습니다.

**비교 기준이 판정을 바꾼다.** 같은 규칙("기간 전체 오류율의 3배")이라도 기간이 바뀌면 "전체"가 바뀌고 문턱도 바뀝니다. 특히 기간이 짧으면 그 안의 사건 하나가 기준 자체를 끌어올립니다 — 하루 오류의 대부분이 한 시간에 몰리면 그날 전체 오류율이 높아져 문턱도 높아집니다.

| 비교 기준 | 좋은 점 | 조심할 것 |
| --- | --- | --- |
| 그 기간 전체 (오늘) | 쉬움 | 기간에 따라 판정이 바뀜, 사건이 기준을 끌어올림 |
| 지난 기간 같은 시간 | 요일 · 시간대의 차이를 맞춤 | 지난 기간에도 사건이 있었으면 |
| 고정 기준 (SLO) | 늘 같은 잣대 | 정할 사람이 필요 (3단계) |

**보고의 규칙.** 이상을 말할 때는 "어느 기간을 기준으로 했나"를 함께 씁니다. 회의에서 누구는 "이번 주", 누구는 "어제"를 기준으로 말하면 같은 보고서로도 다른 결론이 나옵니다.

### 오늘 실습에서

(Lab 02 예제 3, `cases/lab02-periods.json` 5/5)

| 기간 | 전체 오류율 | 문턱 (× 3) | 이상 시간대 |
| --- | --- | --- | --- |
| 첫 주 | 0 | 0 | 없음 |
| 둘째 주 | 0.0588 | 0.1764 | 09시 · 15시 |
| 10/26 (월)만 | **0.2286** | **0.6858** | 09시 |
| 10/29 (목)만 | 0.0515 | 0.1545 | 15시 |
| 두 주 | 0.0315 | 0.0945 | 09시 · 15시 |

- 문턱이 0.0945에서 0.6858까지 일곱 배 넘게 달라졌습니다. 이번 기록은 두 사건이 워낙 뚜렷해(100% · 71%) 사라지지 않았지만, 오류율 30%쯤인 시간이 있었다면 두 주 기준으로는 이상, 월요일 기준으로는 아니었을 것입니다.

## 5. 수와 비율: 답했는데 다시 묻는 주제 (4교시 Lab 02 과제 1)

### 일반 설명

> **생활 속 예 · 교환하러 다시 온 손님.** 물건을 팔았는데 손님이 같은 날 다시 와서 "설명대로 했는데 안 돼요"라고 한다면, 판 것은 맞지만 설명서가 나쁜 것입니다. 많이 팔린 물건은 다시 오는 손님 **수**도 많으니, 몇 명 중 몇 명이 다시 왔는지 **비율**로 봐야 어느 설명서가 나쁜지 압니다.

**재문의율(repeat contact rate).** 같은 사람이 짧은 시간 안에 같은 주제를 다시 묻는 비율입니다. 콜센터 업계는 반대로 "한 번에 해결한 비율"(FCR, First Contact Resolution)을 핵심 지표로 씁니다. 답은 했지만 도움이 안 된 것을 잡아내는 지표입니다.

| 정렬 | 답하는 질문 | 고칠 사람 |
| --- | --- | --- |
| 수 (`repeats`) | 다시 물어서 생긴 일이 가장 많은 곳 | 담당자 · 운영 |
| 비율 (`repeat_rate`) | 답의 질이 가장 나쁜 곳 | FAQ · 콘텐츠 |

**세 가지 실패 목록.** 오늘 Lab 02에서 실패를 세 가지로 나눴습니다: 오류(`failures`), 답 못 함(`unanswered_topics`), 답했는데 도움이 안 됨(`repeat_topics`). 사용자에게는 셋 다 실패이고, 고칠 곳은 각각 다릅니다.

### 오늘 실습에서

(Lab 02 과제 1, 두 주)

| 주제 | 답 | 다시 물음 | 비율 |
| --- | --- | --- | --- |
| 프린터 | 81 | 8 | **9.88%** (1위) |
| 비밀번호 | 139 | **9** (수 1위) | 6.47% |
| VPN | 124 | 8 | 6.45% |
| 접수 현황 · 메일 · 설치 | 96 · 90 · 61 | 6 · 5 · 2 | 6.25% · 5.56% · 3.28% |

- 수로는 비밀번호, 비율로는 프린터. 답의 질을 고친다면 프린터 FAQ부터입니다. 와이파이는 답을 못 했으니 이 표에 없습니다.

## 6. 글은 LLM, 숫자 확인은 Code (4교시 Lab 02 과제 2)

### 일반 설명

> **생활 속 예 · 점장의 세 줄 보고와 계산기.** 점장이 본사에 "이번 주 반품 21건, 대부분 월요일 오전"이라고 세 줄로 보고합니다. 본사는 그 숫자를 장부와 계산기로 맞춰 봅니다. 말솜씨가 좋아도 숫자가 장부에 없으면 믿을 수 없습니다.

**LLM은 숫자를 지어낼 수 있습니다.** 그럴듯한 글을 쓰는 능력 때문에, 통계에 없는 숫자("약 20건", "6%")나 짐작한 원인("서버 과부하로")을 자연스럽게 섞을 수 있습니다 (환각, hallucination). 운영 보고에 들어가는 숫자는 틀리면 결정을 틀리게 합니다.

**근거 확인(grounding check).** LLM에게는 **계산된 통계만** 주고, 돌아온 글의 숫자를 Code가 통계와 대조합니다. 71일차 답 검사("답의 숫자가 규정에 있나")와 같은 생각입니다.

| 단계 | 누가 | 오늘 |
| --- | --- | --- |
| 통계 | Code | `my-log-report`를 **다시 불러** 받음 (정의는 한 곳) |
| 글 | LLM | 세 문장, 통계에 있는 숫자만, 원인 짐작 금지 |
| 대조 | Code | 글의 숫자 ⊂ 통계의 숫자 (값 · ×100 · 날짜 · 시간 · 메시지 속 숫자) → `numbers_ok` · `unknown_numbers` |

**표현이 다른 같은 숫자.** 0.0588은 글에서 5.88%로, `2026-10-26T09`는 "10월 26일 09시"로 쓰입니다. "있는 숫자" 목록에 비율의 ×100과 날짜 · 시간의 숫자를 넣어야 맞는 글이 틀렸다고 나오지 않습니다.

### 오늘 실습에서

둘째 주 요약 (Lab 02 과제 2, LLM 한 번, 1.7~3.4초):

> 가장 많은 미응답 주제는 와이파이로 17건입니다. 가장 흔한 장애는 Search FAQ 노드에서 발생한 "timeout of 1000ms exceeded" 메시지로 16건입니다. 이상 징후가 가장 심한 시간대는 10월 26일 09시로, 총 16건 중 16건이 오류입니다.

- 숫자 17 · 1000 · 16 · 10 · 26 · 09가 모두 통계(값 · 메시지 · 시간 글자)에 있어 `numbers_ok: true`, `unknown_numbers: []`. 둘째 주는 와이파이 17건입니다 (두 주로는 34).

## 7. 원인과 시간을 엮어 사건으로 (4교시 Lab 02 예제 2)

### 일반 설명

> **생활 속 예 · 사고 경위서.** 가게에 문제가 생기면 "몇 시에 · 무엇이 · 몇 건 · 왜"를 한 장에 적습니다. 반품 사유표(무엇)와 시간대별 매출표(언제)를 나란히 놓으면 "월요일 9시 단말기 고장으로 결제 16건 실패"라는 한 줄이 나옵니다.

**사건 타임라인.** 원인 묶음은 "무엇이", 이상 시간대는 "언제"를 말합니다. 둘을 맞춰 보면 문제가 기간 내내 조금씩인지, **한 번의 사건**인지가 보입니다. 장애 회고(postmortem)의 첫 장이 바로 이 타임라인입니다 (76일차 런북).

### 오늘 실습에서

| 사건 | 언제 | 무엇이 | 몇 건 |
| --- | --- | --- | --- |
| ① | 10/26 (월) 09시 | `Search FAQ` timeout (1초) | 16 / 16 |
| ② | 10/29 (목) 15시 | `Answer` 429 (사용량 한도) | 5 / 7 |
| (오류 아님) | 두 주 내내 | 와이파이 질문 → 담당자 연결 | 34 |

- 16 + 5 = 21 = 두 주 오류 전부. 오류는 **두 번의 사건**이었고, 답 못 함은 **기간 내내** 이어진 콘텐츠 문제입니다. 3단계에서 ①과 와이파이를 고칩니다.

## 8. 요청문(프롬프트)으로 에이전트에게 맡기기

문제 찾기 요청문은 "문제를 찾아 줘"가 아니라 **묶는 칸 · 조건 · 순서**를 적습니다.

| 넣을 것 | 예 |
| --- | --- |
| 무엇을 거르나 | "`status`가 `error`인 실행만", "`route`가 `담당자 연결`인 실행만" |
| 무엇으로 묶나 | "(`error_node`, `error_message`)", "`topic`", "`started_at` 앞 13자" |
| 문턱 | "5건 이상 · 그 기간 전체 오류율의 3배 이상 · 오류 1건 이상" |
| 순서 | "많은 순", "시간순", "`repeat_rate` 높은 순, 같으면 `repeats` 많은 순" |
| LLM에게 줄 것 · 하지 말 것 | "통계 중 다섯 칸만 JSON으로, 세 문장, 통계에 있는 숫자만, 원인 짐작 금지" |
| 확인 | "글의 숫자가 통계에 없으면 `unknown_numbers`에" |

## 9. 자주 하는 실수

| 실수 | 결과 | 바로잡기 |
| --- | --- | --- |
| 오류를 건마다 봄 | 고칠 순서를 못 정함 | 원인으로 묶고 많은 순 |
| 오류율만 봄 | 답 못 함 34건을 놓침 | 오류가 아닌 실패를 따로 정의 |
| 이상의 최소 건수를 안 둠 | 1건짜리 시간이 100%로 뜸 | 5건 이상 |
| 비교 기준을 안 적음 | 같은 보고서로 다른 결론 | 기간을 함께 보고 |
| 수로만 정렬 | 인기 주제가 "나쁜 주제"로 보임 | 비율과 건수를 나란히 |
| LLM에게 기록을 줌 | 비싸고 틀림 | 계산된 통계만 |
| 요약이 지표를 다시 계산 | 정의가 두 벌, 숫자가 어긋남 | `my-log-report`를 다시 부름 |
| 숫자 확인에 ×100 · 날짜를 안 넣음 | 맞는 글도 `numbers_ok: false` | "있는 숫자"를 넓게 |

## 확인 질문

<details><summary>1. 오류 21건을 원인으로 묶었더니 둘이었습니다. 묶는 칸을 `error_node` 하나로만 하면 무엇을 놓칠 수 있나요?</summary>

같은 노드에서 다른 까닭으로 실패한 것(예: `Answer`의 429와 timeout)이 한 묶음이 됩니다. 고칠 방법이 다른데 같은 문제로 보입니다. 그래서 노드와 메시지를 함께 지문으로 씁니다. 반대로 메시지에 매번 바뀌는 값(요청 id 등)이 들어 있으면 묶음이 쪼개지므로, 그럴 때는 메시지를 다듬어 묶습니다.
</details>

<details><summary>2. 와이파이 34건은 오류율에 하나도 안 잡혔습니다. 그런데 왜 문제 목록 1위로 둘 수 있나요?</summary>

사용자에게는 답을 못 받은 실패이고, 건수로는 오류(21)보다 많으며, 담당자의 일을 늘립니다. 그리고 FAQ에 항목이 없다는 분명한 원인이 있어 고치기도 쉽습니다. 오류율은 "워크플로우가 고장 났나"를, 이관율은 "사용자가 답을 받았나"를 말합니다.
</details>

<details><summary>3. 같은 보고서인데 "월요일만" 물으면 문턱이 0.6858, "두 주"로 물으면 0.0945입니다. 어느 쪽이 맞나요?</summary>

둘 다 정의대로입니다. 비교 기준(그 기간 전체 오류율)이 기간마다 다를 뿐입니다. 짧은 기간은 사건 하나가 기준을 끌어올려 이상을 덜 잡습니다. 그래서 이상을 보고할 때 기준 기간을 함께 쓰고, 늘 같은 잣대가 필요하면 고정 기준(SLO, 3단계)을 씁니다.
</details>

<details><summary>4. LLM 요약이 "와이파이 질문이 약 20건"이라고 썼습니다. 숫자 확인은 어떻게 되고, 어떻게 고치나요?</summary>

20은 통계에 없으므로 `unknown_numbers: ["20"]`, `numbers_ok: false`가 됩니다. 지시문에 "통계에 있는 숫자만, 다른 숫자를 더하지 말 것"을 더하고, LLM에게 주는 통계를 필요한 칸으로 줄이고, `temperature`를 0으로 둡니다. 그래도 틀리면 그 요약은 쓰지 않고 표만 보냅니다 — 확인을 통과하지 못한 숫자는 보고에 넣지 않습니다.
</details>

<details><summary>5. 오류 21건이 09시 16건 · 15시 5건으로 나뉜다는 것은 무엇을 뜻하나요?</summary>

오류가 두 주 내내 조금씩 난 것이 아니라 두 번의 사건이었다는 뜻입니다. 원인 묶음과 맞추면 09시는 FAQ 검색 timeout, 15시는 LLM 429입니다. 사건마다 원인이 하나라 고칠 곳이 분명하고, 다음에 같은 시간대에 같은 일이 생기는지 지켜볼 수 있습니다.
</details>