77일차 실행 기록 분석: 실습 15개 · 강의(개요 30장 · 단계 문서 · 4단계 정리 · 05 바이브), 정답본 LAB-A · answers · VIBE-A · tlog 포함
This commit is contained in:
mcchae committed
1 parent
036eae1c6a
commit
dcd4cdd66b
148 files changed
+40344
No files matched your search
@@ -0,0 +1,448 @@
|
||||
# 77일차 개요 · 실행 로그 분석과 운영 데이터 기반 Workflow 개선
|
||||
|
||||
> 노코드 멀티 에이전트 워크플로우 설계 및 운영 · 2026-11-02
|
||||
> 30장 · 각 장은 가로줄(`---`)로 나뉩니다. 1교시에는 1~6장을 보고, 나머지 장은 각 단계 강의(1 · 3 · 5교시) 때 함께 띄웁니다.
|
||||
> 숫자는 모두 강사 노트북 실측입니다 (65일차 n8n 2.42.6, 77일차 판 데이터 API의 두 주 실행 기록 666줄, OpenAI `gpt-4.1-mini`(요약 · 헬프데스크 답), 10/31 정답 워크플로우를 학생 순서대로 1회).
|
||||
|
||||
| 장 | 범위 | 띄우는 때 |
|
||||
| --- | --- | --- |
|
||||
| 1~6 | 표지 · 목표 · 시간표 · 숫자가 다른 두 보고서 · 일하는 순서 · 실습 15개 | 1교시 시작 |
|
||||
| 7~14 | 1단계 · 실행 기록 읽기와 지표 | 1교시 강의 |
|
||||
| 15~21 | 2단계 · 문제를 숫자로 찾기 | 3교시 강의 |
|
||||
| 22~28 | 3단계 · 고치고 다시 재기 | 5교시 강의 |
|
||||
| 29~30 | 바이브 코딩 · 정리와 예고 (8교시 35분 정리는 [04-STAGE4-WRAPUP](04-STAGE4-WRAPUP.md)) | 7교시 · 8교시 |
|
||||
|
||||
---
|
||||
|
||||
## 1 / 30 · 표지
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
L[("실행 기록")] --> M["재기<br/>정의된 지표"] --> F["찾기<br/>묶음 · 이상 · 비율"] --> X["고치기<br/>워크플로우 · 콘텐츠"] --> R["다시 재기<br/>SLO · 대가 · 보고"]
|
||||
classDef d fill:#0F3D3E,stroke:#0F3D3E,color:#fff
|
||||
classDef o fill:#F2A541,stroke:#F2A541,color:#fff
|
||||
class L d
|
||||
class M,F,X,R o
|
||||
```
|
||||
|
||||
**77일차**
|
||||
|
||||
# 실행 로그 분석과 운영 데이터 기반 Workflow 개선
|
||||
|
||||
감으로 말하지 않고 · 정의된 숫자로 찾고 · 고친 뒤 다시 잰다
|
||||
|
||||
<sub>노코드 멀티 에이전트 워크플로우 설계 및 운영 · 2026-11-02</sub>
|
||||
|
||||
---
|
||||
|
||||
## 2 / 30 · 오늘 할 수 있게 될 세 가지
|
||||
|
||||
| | 목표 | 내용 |
|
||||
| --- | --- | --- |
|
||||
| 1 | **잰다** | 실행 기록을 읽고, 정의대로 세는 보고서(실행 · 오류율 · p50 · p95 · 갈래)를 만들고, 경계에서 시험하고, 날짜 · 릴리스 · 단계 · 비용으로 나눈다 |
|
||||
| 2 | **찾는다** | 실패를 원인으로 묶고, 오류가 아닌 실패를 세고, 이상 시간대와 비교 기준을 정하고, 수와 비율을 나누고, LLM 요약의 숫자를 Code로 확인한다 |
|
||||
| 3 | **고치고 다시 잰다** | 고칠 곳과 사람을 나눠 고치고, 같은 조건으로 다시 돌리고, SLO로 판정하고, 고친 것의 대가를 찾고, 주간 보고 · SLO 알림을 만든다 |
|
||||
|
||||
---
|
||||
|
||||
## 3 / 30 · 오늘의 시간표
|
||||
|
||||
| 교시 | 시간 | 내용 |
|
||||
| --- | --- | --- |
|
||||
| 1 | 09:00~09:50 | 개요 · **1단계 강의** · 실행 기록 읽기와 지표 |
|
||||
| 2 | 10:00~10:50 | **Lab 01 실습 5개** · 기준 보고서 비교 · 지표 보고서 · 경계 · 날짜별 · 릴리스별 · 단계 · 비용 |
|
||||
| 3 | 11:00~11:50 | **2단계 강의** · 문제를 숫자로 찾기 |
|
||||
| 4 | 12:00~12:50 | **Lab 02 실습 5개** · 실패 묶음 · 답 못 한 주제 · 이상 시간대 · 기간 · 다시 묻는 주제 · LLM 요약 |
|
||||
| - | 13:00~14:00 | 점심 |
|
||||
| 5 | 14:00~14:50 | **3단계 강의** · 고치고 다시 재기 |
|
||||
| 6 | 15:00~15:50 | **Lab 03 실습 5개** · 고치기 전 · 후 · SLO · 고친 것의 대가 · 주간 보고 · SLO 알림 |
|
||||
| 7 | 16:00~16:50 | 바이브 코딩 `tlog`: 요청서 → TODO → SPEC → IMP-PLAN → 만들기 → 설치 |
|
||||
| 8 | 17:00~17:50 | 발표 · **4단계 정리** (의미 · 효과 · 회사에서 쓰는 법) · 78일차 예고 |
|
||||
|
||||
---
|
||||
|
||||
## 4 / 30 · 오늘의 출발점: 같은 기록, 다른 숫자
|
||||
|
||||
헬프데스크 두 주(10/19~10/30) 실행 기록 666줄과, 팀이 지난달 만든 보고서 `base-report`.
|
||||
|
||||
| 질문 | `logs` (그대로 셈) | 팀의 보고서 |
|
||||
| --- | --- | --- |
|
||||
| 두 주에 몇 번? | 666 | **602** |
|
||||
| 오류율? | 0.0315 | **3.488…** |
|
||||
| 10/26 하루는? | 70 · 오류 16 | **0** · `null` |
|
||||
| 느린 정도? | p95 2537ms | 평균 1249ms |
|
||||
|
||||
그리고 아직 아무도 세지 않은 것: 담당자에게 넘긴 질문 **34건이 모두 와이파이**.
|
||||
|
||||
---
|
||||
|
||||
## 5 / 30 · 일하는 순서 (오늘은 "재기 → 정의 → 고치기 → 다시 재기")
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A["① 먼저 재기<br/>logs · call · test(전)"] --> B["② 정의 · 요청문"] --> C["③ 에이전트<br/>my-work · check"] --> D["④ 내가<br/>push · test -v"]
|
||||
D -->|"✘ 칸 = 실제 (expected 기대)"| C
|
||||
D -->|✔| E["⑤ OPS.md 한 줄"]
|
||||
```
|
||||
|
||||
| 누가 | 무엇을 |
|
||||
| --- | --- |
|
||||
| 나 | 기록을 읽고 질문, 정의 정하기, 기준과 비교, 문제의 순서, FAQ(콘텐츠) 고치기 |
|
||||
| CLI 에이전트 | `AGENTS.md`대로 워크플로우 JSON, `check` |
|
||||
| `flow.py` | `logs`(기록 훑기), `test --webhook`(기준과 비교), `ops`(오늘 기록 · 더한 FAQ · 알림), `diff` |
|
||||
|
||||
---
|
||||
|
||||
## 6 / 30 · 실습 15개 (Lab마다 예제 3 · 과제 2)
|
||||
|
||||
| | 예제 1 | 예제 2 | 예제 3 | 과제 1 | 과제 2 |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| Lab 01 | 손으로 읽기 · 기준 보고서 (에이전트 없이) | 지표 보고서 | 경계에서 재 보기 (에이전트 없이) | 날짜별 · 릴리스별 | 단계별 · 비용 |
|
||||
| Lab 02 | 실패 묶음 · 답 못 한 주제 | 이상 시간대 | 기간을 바꾸면 (에이전트 없이) | 다시 묻는 주제 | LLM 요약 · 숫자 확인 |
|
||||
| Lab 03 | 고치기 전 → 고치기 → 고친 뒤 | SLO 판정 | 고친 것의 대가 (에이전트 없이) | 주간 보고 | SLO 알림 |
|
||||
|
||||
---
|
||||
|
||||
## 7 / 30 · 1단계 · 실행 기록: 운영의 영수증
|
||||
|
||||
> 생활 속 예: 계산대 옆 상자에 쌓인 두 주 치 영수증 — 세면 "요즘 장사가 어떤지"를 숫자로 답할 수 있다.
|
||||
|
||||
| 관측의 세 가지 | 무엇 | 오늘 |
|
||||
| --- | --- | --- |
|
||||
| 로그 | 일어난 일 하나하나 | 실행 기록 666줄 (실행 한 번에 한 줄, 칸이 정해진 JSON) |
|
||||
| 지표 | 로그를 세고 나눈 숫자 | 실행 · 오류율 · p95 · 답 못 함 |
|
||||
| 추적 | 한 요청의 단계마다 시간 | `steps.faq_ms` · `steps.answer_ms` |
|
||||
|
||||
- 두 주 666건 · 오류 21 (3.2%), 그런데 10/26 하루에 **16건** (22.9%).
|
||||
|
||||
---
|
||||
|
||||
## 8 / 30 · 지표는 정의다
|
||||
|
||||
> 생활 속 예: 알바생 둘이 같은 영수증을 세었는데 답이 다름 — 한 사람은 마지막 날을 빼고 셌다.
|
||||
|
||||
| 정해야 할 것 | 오늘의 정의 (AGENTS.md 3절) | 팀의 보고서 |
|
||||
| --- | --- | --- |
|
||||
| 기간의 경계 | `from ≤ 날짜 ≤ to` (끝날 포함) | `started_at < to` (끝날 64건 빠짐) |
|
||||
| 표현 | 비율, 소수 4자리 | 백분율, 끊지 않음 |
|
||||
| 0건일 때 | 0 | `null` |
|
||||
| 오류 갈래 | `null` → `"오류"` | 건너뜀 |
|
||||
|
||||
- 기준에 오늘 테스트 **0/5**, 정의대로 세는 내 보고서 **5/5** (Lab 01 예제 2). 정의는 한 곳에 — 나머지는 다시 부른다.
|
||||
|
||||
---
|
||||
|
||||
## 9 / 30 · 백분위: 평균이 숨기는 것
|
||||
|
||||
> 생활 속 예: "버스가 평균 10분마다"보다 "열 번 중 아홉 번은 8분 안"이 기다리는 사람에게 쓸모 있다.
|
||||
|
||||
| 같은 기록 | 평균 | p50 | p95 |
|
||||
| --- | --- | --- | --- |
|
||||
| 1초 × 9 + 10초 × 1 | 1.9초 | 1초 | 10초 |
|
||||
|
||||
- 오늘 정의: 오름차순 **`ceil(p × n)`번째** (가장 가까운 순위), 오류 실행 포함. 666건이면 p95 = 633번째.
|
||||
- 두 주 p50 1205 · p95 2537ms. 둘째 주는 p50이 빨라지고(1252 → 1171) p95는 느려짐(2525 → 2598).
|
||||
|
||||
---
|
||||
|
||||
## 10 / 30 · 숫자는 Code가 센다
|
||||
|
||||
> 생활 속 예: 손님에게 설명은 점원이, 하루 매출 합계는 포스기가.
|
||||
|
||||
| 일 | 누가 |
|
||||
| --- | --- |
|
||||
| 거르기 · 세기 · 나누기 · 백분위 | Code (거르기는 데이터 API `/logs/query`) |
|
||||
| 센 결과를 사람의 말로 | LLM (Lab 02 과제 2) |
|
||||
| LLM 글의 숫자 확인 | Code |
|
||||
|
||||
- 내 보고서: `Get logs` → `Compute metrics`(Code 하나) → 응답. 666줄에 **0.1초 안팎**, LLM 없음.
|
||||
- 갈래의 합 = 실행 수로 자기 검산 (21 + 299 + 17 + 20 = 357).
|
||||
|
||||
---
|
||||
|
||||
## 11 / 30 · 경계와 0 (Lab 01 예제 3)
|
||||
|
||||
> 생활 속 예: 줄자의 끝 눈금 한 칸 — 1m를 잴 땐 상관없어도 1cm를 잴 땐 전부다.
|
||||
|
||||
| 경계 | 내 보고서 | 팀의 보고서 |
|
||||
| --- | --- | --- |
|
||||
| 하루 (from = to) | ✔ 70 | ✘ 0 |
|
||||
| 빈 기간 | ✔ 0 · 0 · 0 | ✘ `null` (0 / 0) |
|
||||
| 주말 · 기간 없음 | ✔ | ✔ (우연히) |
|
||||
| `source: live` | ✔ 0 | ✘ **666** (거르기를 무시) |
|
||||
|
||||
- 6/6 대 2/6. 경계가 문제를 **가려** 우연히 맞는 테스트도 있다.
|
||||
|
||||
---
|
||||
|
||||
## 12 / 30 · 묶어서 세기 · 표본 크기 (Lab 01 과제 1)
|
||||
|
||||
> 생활 속 예: 가계부의 날짜별 칸 — "15일에 한 번 크게 썼다"가 보인다. 새 앱으로 산 날이 이틀뿐이면 아직 모른다.
|
||||
|
||||
| 묶음 | 결과 |
|
||||
| --- | --- |
|
||||
| 10/26 (월) | 70 · 오류 **16** |
|
||||
| 10/29 (목) | 97 · 오류 5 |
|
||||
| 1.0.0 · 1.1.0 | 다시 묻기 4.73% · 7.73% |
|
||||
| 1.2.0 (카나리) | 62.5%, 그러나 답 **8건** |
|
||||
|
||||
- 비율 옆에 늘 건수. 분모는 "답을 준 실행" (402 + 181 + 8 = 591 = 자동 답변).
|
||||
|
||||
---
|
||||
|
||||
## 13 / 30 · 단계 시간: 어디가 느린가 (Lab 01 과제 2)
|
||||
|
||||
> 생활 속 예: 택배 배송 조회의 구간별 시간 — 허브에서 하루를 묵었다면 기사님을 재촉해도 소용없다.
|
||||
|
||||
| 단계 p95 | 두 주 | 10/26만 |
|
||||
| --- | --- | --- |
|
||||
| FAQ 검색 | **39ms** (646건) | **1000ms** |
|
||||
| LLM 답 | 2509ms (596건) | 2482ms |
|
||||
|
||||
- 평소 느린 것은 LLM, 월요일에는 FAQ 검색 (timeout 1초에 걸림). 거치지 않은 단계(0ms)는 뺀다 — `runs`를 함께.
|
||||
|
||||
---
|
||||
|
||||
## 14 / 30 · 비용: 질문 하나에 얼마 (Lab 01 과제 2)
|
||||
|
||||
> 생활 속 예: 택배비를 상자마다 알아야 한 달 운송비를 잡는다.
|
||||
|
||||
| 두 주 | 값 |
|
||||
| --- | --- |
|
||||
| LLM 비용 | 0.07836달러 |
|
||||
| 실행당 | 0.000118달러 |
|
||||
| LLM 호출 | 596번 (답한 실행마다 한 번) |
|
||||
|
||||
- 합계는 예산(75일차), 실행당 비용은 "질문 하나에 얼마". 빈 기간은 0 (나누지 않음).
|
||||
|
||||
---
|
||||
|
||||
## 15 / 30 · 2단계 · 문제 목록은 원인으로 (Lab 02 예제 1)
|
||||
|
||||
> 생활 속 예: 반품 21건을 사유로 묶으면 "사이즈 16 · 불량 5" — 고칠 일은 둘.
|
||||
|
||||
| 원인 (노드 · 메시지) | 건수 |
|
||||
| --- | --- |
|
||||
| `Search FAQ` · timeout of 1000ms exceeded | **16** |
|
||||
| `Answer` · 429 Rate limit reached | 5 |
|
||||
|
||||
- 오류 21건 = 원인 2개, 맨 위 하나가 76% (파레토). 업계: Sentry 지문 · 오류 묶기.
|
||||
|
||||
---
|
||||
|
||||
## 16 / 30 · 오류가 아닌 실패 (Lab 02 예제 1)
|
||||
|
||||
> 생활 속 예: "찾는 물건 없음" 메모 34장이 모두 같은 물건 — 반품도 결제 오류도 아니라 장부엔 안 남는다.
|
||||
|
||||
| | 오류 | 담당자 연결 |
|
||||
| --- | --- | --- |
|
||||
| `status` | error | **success** |
|
||||
| 오류율에 | 잡힘 | 안 잡힘 |
|
||||
| 두 주 | 21 | **34 — 모두 와이파이** |
|
||||
| 고칠 곳 | 워크플로우 · 바깥 서비스 | **콘텐츠** (FAQ에 항목이 없음) |
|
||||
|
||||
- 업계: 이관율(escalation rate) · 자동 해결률(deflection). 두 주 이관율 5.11%.
|
||||
|
||||
---
|
||||
|
||||
## 17 / 30 · 이상 시간대 (Lab 02 예제 2)
|
||||
|
||||
> 생활 속 예: 시간대별 매출표에서 손님이 충분했는데 9시에만 0건 — 그 시간에 무슨 일이 있었다.
|
||||
|
||||
| 묶기 | 비교 기준 | 문턱 |
|
||||
| --- | --- | --- |
|
||||
| 시간 (`2026-10-26T09`) | 그 기간 전체 오류율 | 3배 이상 · 5건 이상 · 오류 1건 이상 |
|
||||
|
||||
| 이상 시간대 (두 주, 문턱 0.0945) | 실행 · 오류 |
|
||||
| --- | --- |
|
||||
| 10/26 (월) 09시 | 16 · **16** |
|
||||
| 10/29 (목) 15시 | 7 · 5 |
|
||||
|
||||
---
|
||||
|
||||
## 18 / 30 · 비교 기준이 판정을 바꾼다 (Lab 02 예제 3)
|
||||
|
||||
> 생활 속 예: "평소보다 많이 먹었다"의 평소 — 명절 기준이면 적게, 평일 기준이면 많이.
|
||||
|
||||
| 기간 | 전체 오류율 | 문턱 (× 3) | 이상 |
|
||||
| --- | --- | --- | --- |
|
||||
| 첫 주 | 0 | 0 | 없음 |
|
||||
| 두 주 | 0.0315 | 0.0945 | 09시 · 15시 |
|
||||
| 10/26만 | 0.2286 | **0.6858** | 09시 |
|
||||
|
||||
- 문턱이 일곱 배 넘게 달라짐. 사건이 기준을 끌어올림 → 보고에 **기준 기간**을 함께.
|
||||
|
||||
---
|
||||
|
||||
## 19 / 30 · 수와 비율 (Lab 02 과제 1)
|
||||
|
||||
> 생활 속 예: 교환하러 다시 온 손님 — 많이 팔린 물건은 다시 오는 수도 많으니 비율로 봐야 나쁜 설명서가 보인다.
|
||||
|
||||
| 주제 | 답 | 다시 물음 | 비율 |
|
||||
| --- | --- | --- | --- |
|
||||
| 프린터 | 81 | 8 | **9.88%** |
|
||||
| 비밀번호 | 139 | **9** | 6.47% |
|
||||
|
||||
- 실패 목록 셋: 오류 · 답 못 함 · 답했는데 도움 안 됨. 업계: 재문의율 · FCR(한 번에 해결).
|
||||
|
||||
---
|
||||
|
||||
## 20 / 30 · 글은 LLM, 숫자 확인은 Code (Lab 02 과제 2)
|
||||
|
||||
> 생활 속 예: 점장의 세 줄 보고를 본사가 장부 · 계산기로 맞춰 본다.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
R["my-log-report<br/>다시 부르기"] --> L{{"LLM 세 문장"}} --> C["Code: 글의 숫자 ⊂ 통계?"] --> O(["numbers_ok ·<br/>unknown_numbers"])
|
||||
```
|
||||
|
||||
> 가장 많은 미응답 주제는 와이파이로 17건입니다. 가장 흔한 장애는 Search FAQ 노드에서 발생한 "timeout of 1000ms exceeded" 메시지로 16건입니다. 이상 징후가 가장 심한 시간대는 10월 26일 09시로, 총 16건 중 16건이 오류입니다.
|
||||
|
||||
- `numbers_ok: true` — 17 · 1000 · 16 · 10 · 26 · 09 모두 통계에 있음 (×100 · 날짜 · 메시지 속 숫자까지).
|
||||
|
||||
---
|
||||
|
||||
## 21 / 30 · 원인 × 시간 = 사건 (Lab 02 예제 2)
|
||||
|
||||
> 생활 속 예: 사고 경위서 — "월요일 9시 단말기 고장으로 결제 16건 실패" 한 줄.
|
||||
|
||||
| 사건 | 언제 | 무엇 | 몇 건 |
|
||||
| --- | --- | --- | --- |
|
||||
| ① | 10/26 09시 | FAQ 검색 timeout | 16 / 16 |
|
||||
| ② | 10/29 15시 | LLM 429 | 5 / 7 |
|
||||
| (오류 아님) | 두 주 내내 | 와이파이 → 담당자 연결 | 34 |
|
||||
|
||||
- 16 + 5 = 21 = 오류 전부 → **두 번의 사건** + 기간 내내의 콘텐츠 문제.
|
||||
|
||||
---
|
||||
|
||||
## 22 / 30 · 3단계 · 같은 조건으로 다시 돌려 잰다 (Lab 03 예제 1)
|
||||
|
||||
> 생활 속 예: 단말기를 고친 뒤 그날과 같은 상황에서 같은 손님 열 명을 다시 받아 본다.
|
||||
|
||||
| FAQ 1.2초 느림 · 같은 10개 | 오류 | 갈래 | 한 건 |
|
||||
| --- | --- | --- | --- |
|
||||
| `before` (timeout 1초, 와이파이 FAQ 없음) | **10** | 오류 10 | 1.1~2.1초 |
|
||||
| `after` (timeout 3초 · 재시도 + FAQ-007) | **0** | 자동 답변 10 | 2.3~4.5초 |
|
||||
|
||||
| 고칠 곳 | 누가 |
|
||||
| --- | --- |
|
||||
| Search FAQ timeout · 재시도 | 에이전트 (워크플로우) |
|
||||
| 와이파이 FAQ | 나 (`faq/add`, 콘텐츠) |
|
||||
|
||||
---
|
||||
|
||||
## 23 / 30 · SLO: 숫자로 한 약속 (Lab 03 예제 2)
|
||||
|
||||
> 생활 속 예: "빠르게 배달" 대신 "30분 안에, 아니면 할인".
|
||||
|
||||
| SLI | SLO | 둘째 주 | 고친 뒤 |
|
||||
| --- | --- | --- | --- |
|
||||
| 오류율 | 0.01 | **0.0588** ✘ | 0 |
|
||||
| p95 | 3000ms | 2598 | **3560** ✘ |
|
||||
| 답 못 함 | 0.02 | **0.0476** ✘ | 0 |
|
||||
|
||||
- 기준은 본문 `slo`로 바꿀 수 있게. 에러 예산 = 목표까지 남은 여유.
|
||||
|
||||
---
|
||||
|
||||
## 24 / 30 · 고친 것의 대가 (Lab 03 예제 3)
|
||||
|
||||
> 생활 속 예: 단말기 대기 시간을 늘려 결제 실패는 사라졌지만 줄이 길어졌다.
|
||||
|
||||
| 같은 10개 | FAQ | 오류 | FAQ 단계 p50 | 답 단계 p50 | p95 |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| `after` | 느림 | 0 | **1238ms** | 1103ms | 3560ms |
|
||||
| `normal` | 평소 | 0 | **17ms** | 997ms | 2147ms |
|
||||
|
||||
- 늘어난 시간은 모두 FAQ 단계 → timeout은 **완화**(견디기), 근본 해결은 FAQ 검색이 느려지는 원인.
|
||||
|
||||
---
|
||||
|
||||
## 25 / 30 · 주간 보고: 조립 (Lab 03 과제 1)
|
||||
|
||||
> 생활 속 예: 매주 같은 칸으로 채우는 주간 매출 보고서 — 할 일은 정해진 규칙대로.
|
||||
|
||||
| 절 | 누가 | 이번 주 |
|
||||
| --- | --- | --- |
|
||||
| 숫자 | Code (보고서 두 번) | 요청 309 → 357, 오류율 0% → 5.88% |
|
||||
| 문제 | Code | 실패 16 · 5, 와이파이 17, 이상 09시 · 15시 |
|
||||
| 요약 | LLM + 숫자 확인 | 통과 |
|
||||
| 다음 할 일 | **규칙** | 와이파이 FAQ · timeout · 사용량 한도 |
|
||||
|
||||
---
|
||||
|
||||
## 26 / 30 · SLO 알림 · 같은 알림은 한 번 (Lab 03 과제 2)
|
||||
|
||||
> 생활 속 예: 냉장고 온도 경보 — 한 번 울리고, 10분 안에는 다시 울리지 않되 기록은 남긴다.
|
||||
|
||||
| 물은 것 | 결과 |
|
||||
| --- | --- |
|
||||
| 둘째 주 | `sent` — `SLO breach: error_rate 0.0588 > 0.01, unanswered_rate 0.0476 > 0.02` |
|
||||
| 10분 안 다시 | `suppressed` (알림 1개 그대로) |
|
||||
| 기준 안 | `none` |
|
||||
|
||||
---
|
||||
|
||||
## 27 / 30 · 개선의 고리
|
||||
|
||||
> 생활 속 예: 다이어트 — 같은 체중계 · 같은 시각에 재고, 늘어난 날을 찾고, 줄이고, 다시 잰다.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
M["재기"] --> F["찾기"] --> X["고치기"] --> R["다시 재기"] --> M
|
||||
R --> P["보고 · 알림"]
|
||||
```
|
||||
|
||||
| 규칙 | 오늘 |
|
||||
| --- | --- |
|
||||
| 정의는 한 곳 | `my-log-report`, 나머지는 다시 부름 |
|
||||
| 같은 조건으로 다시 | 고장 스위치 · 같은 질문 · `tag` |
|
||||
| 고친 것 말고도 다시 | p95 새 위반 |
|
||||
| 건수 · 기준 기간을 함께 | 1.2.0 8건, 문턱의 기간 |
|
||||
|
||||
---
|
||||
|
||||
## 28 / 30 · 가게 장부로 본 오늘 하루
|
||||
|
||||
> 생활 속 예: 오늘 만든 것이 모두 동네 가게에 있다 (3단계 8절 표).
|
||||
|
||||
| 오늘 | 가게 |
|
||||
| --- | --- |
|
||||
| 실행 기록 · 지표 정의 | 영수증 더미 · 장부 쓰는 법 |
|
||||
| p95 · 경계 | 버스 도착 시간 · 줄자 끝 눈금 |
|
||||
| 실패 묶음 · 답 못 함 · 다시 묻기 | 반품 사유표 · "찾는 물건 없음" · 교환 손님 |
|
||||
| 이상 시간대 · 비교 기준 | 매출표의 빈칸 · "평소"의 기준 |
|
||||
| 요약 + 숫자 확인 | 점장 보고 + 계산기 |
|
||||
| 다시 돌리기 · SLO · 대가 | 같은 손님 열 명 · 30분 배달 약속 · 길어진 줄 |
|
||||
| 주간 보고 · SLO 알림 | 주간 매출 보고서 · 냉장고 경보 |
|
||||
|
||||
---
|
||||
|
||||
## 29 / 30 · 7교시 바이브 코딩 · `tlog`
|
||||
|
||||
요청서(운영 담당의 말 ①~⑫) → `Doc/TODO.md` → `SPEC.md` → `IMP-PLAN.md` → 단계별로 → `uv tool install`.
|
||||
|
||||
| 오늘 n8n에서 | `tlog`로 터미널에서 |
|
||||
| --- | --- |
|
||||
| `my-log-report` (정의 3절) | `tlog summary` — **같은 기간이면 같은 숫자** |
|
||||
| 실패 묶음 · 이상 시간대 | `tlog problems` |
|
||||
| SLO 판정 | `tlog slo` — 위반이면 종료 코드 4 (cron · CI에서) |
|
||||
| 주간 보고 | `tlog weekly --md` (나중 단계) |
|
||||
| (없음) | 파일 · 데이터 API 둘 다 읽기, 76일차 `tretry` 기록도 |
|
||||
| (없음) | TUI: 묶음을 고르면 그 실행들 |
|
||||
|
||||
- 강사 본: 두 주 · 둘째 주 · 10/26 · 빈 기간에 `tlog summary --json`과 `my-log-report` 응답을 칸마다 비교 → **18칸 중 다른 칸 0개**. 둘째 주 `tlog slo` → 종료 코드 4. 테스트 23개 1.7초 (n8n 없이).
|
||||
|
||||
---
|
||||
|
||||
## 30 / 30 · 오늘의 정리 · 78일차 예고
|
||||
|
||||
| 단계 | 오늘 숫자 |
|
||||
| --- | --- |
|
||||
| 재기 | 기준 602 · 0/5 → 정의대로 666 · 5/5, 경계 6/6 대 2/6, 월요일 FAQ p95 1000ms |
|
||||
| 찾기 | 오류 21 = 원인 2 = 사건 2, 와이파이 34, 문턱 0.0945 ~ 0.6858, 프린터 9.88%, 요약 `numbers_ok` |
|
||||
| 고치고 다시 재기 | 오류 10 → 0, 대신 p95 3560 > 3000 (FAQ 단계 1238ms · 평소 17ms), 주간 보고 7/7, SLO 알림 `sent` → `suppressed` |
|
||||
|
||||
- 8교시 [4단계 정리](04-STAGE4-WRAPUP.md): 의미 · 효과 · 업계 이름 · 면접 · 최종 프로젝트 체크리스트.
|
||||
- 78일차 (11/3): **데이터 품질 검증 자동화 및 품질 관리 Workflow** — 오늘은 기록을 "믿고" 셌다. 내일은 들어오는 데이터 자체가 맞는지(빠진 칸 · 이상한 값 · 중복)를 규칙으로 검사하고 품질 관문을 세운다.
|
||||
@@ -0,0 +1,101 @@
|
||||
# 77일차 실습 준비 · 수업 전에 미리 해 두면 좋은 것
|
||||
|
||||
- 수업일: 2026-11-02 (77일차) · 실행 로그 분석과 운영 데이터 기반 Workflow 개선
|
||||
- 준비 시간: 약 10분
|
||||
- 먼저 WSL에서 `cd ~/aio-01d4-stu && git pull`로 오늘 자료를 받습니다 (수강생 저장소: https://gl.isitsoft.kr/publicproj/aio-01d4-stu).
|
||||
- **수업 전날까지** 1~2절을 끝내 주세요.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A["1. n8n · 데이터 API 켜기<br/>(77일차 판)"] --> B["2. 기준 보고서 게시 ·<br/>기록 훑기 · doctor ready"] --> C["3. 미리 읽기"]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 1. n8n과 데이터 API 켜기 (전날 필수, 3분)
|
||||
|
||||
오늘은 **77일차 판 데이터 API**(76일차 + 두 주 실행 기록 666줄 · 오늘 실습 기록 · FAQ 더하기)를 씁니다. 같은 이름이라 이 폴더에서 다시 만들면 바뀝니다.
|
||||
|
||||
```bash
|
||||
sudo systemctl disable --now ollama 2>/dev/null # WSL에 설치한 Ollama가 있으면 끄고 자동 시작도 끔
|
||||
cd ~/aio-01d4-stu/Last3Mon/65/n8n
|
||||
docker compose rm -sf ollama # Ollama 컨테이너가 있으면 지움 (없으면 그냥 지나감)
|
||||
docker compose start
|
||||
cd ~/aio-01d4-stu/Last3Mon/77/data-api
|
||||
docker compose up -d --force-recreate
|
||||
sleep 3 # 데이터 API가 뜰 때까지
|
||||
curl -s 'localhost:8800/logs?limit=1' # {"count": 666, "logs": [ { "execution_id": 5001, … } ]}
|
||||
```
|
||||
|
||||
- **66일차부터 LLM은 OpenAI API 키(`Last3Mon/.env`, Credential `OpenAI (.env)`)만 씁니다.** 오늘 LLM은 Lab 02 과제 2의 요약과 Lab 03 헬프데스크의 답에만 씁니다 (`gpt-4.1-mini`). 지표는 모두 Code가 셉니다. Ollama는 쓰지 않습니다.
|
||||
- 76일차의 접수 건 · DLQ · 알림 · 고장 스위치는 데이터 API를 새로 띄우면 처음으로 돌아갑니다. 두 주 실행 기록은 늘 그대로입니다.
|
||||
- 오늘 실습에서 남기는 기록은 한국 시간으로 찍힙니다 (`TZ=KST-9`). 두 주 기록(10/19~10/30)과 날짜가 겹치지 않습니다.
|
||||
- `network day65-n8n_default not found` → n8n이 켜져 있지 않음. 위 n8n 부분부터 다시.
|
||||
|
||||
## 2. 기준 보고서 게시 · 기록 훑기 · 준비 확인 (전날 필수, 3분)
|
||||
|
||||
오늘 비교할 **팀의 기준 보고서**를 게시해 둡니다 (만들지 않고 게시만).
|
||||
|
||||
```bash
|
||||
cd ~/aio-01d4-stu/Last3Mon/77
|
||||
uv run tools/flow.py push reference/baseline-report.json
|
||||
uv run tools/flow.py logs --from 2026-10-26 --to 2026-10-26 --last 3 # 70 run(s) · errors 16 (22.9%)
|
||||
uv run tools/flow.py ops --reset
|
||||
uv run tools/flow.py doctor
|
||||
```
|
||||
|
||||
```text
|
||||
✔ n8n container day65-n8n-n8n-1
|
||||
✔ n8n http://localhost:5678
|
||||
✔ data API http://localhost:8800
|
||||
✔ dead letter queue /dlq · alerts · fault switch dlq (day 76 data API)
|
||||
✔ run logs /logs (666 seeded runs) · FAQ additions /faq-extra (day 77 data API)
|
||||
✔ n8n → http://data-api:8800
|
||||
✔ credential 'OpenAI (.env)' (openAiCourse0001)
|
||||
✔ node catalog (for check)
|
||||
✔ CLI coding agent: codex, claude, agy
|
||||
ready
|
||||
```
|
||||
|
||||
| ✘ 항목 | 할 일 |
|
||||
| --- | --- |
|
||||
| n8n container · data API | 1절 |
|
||||
| run logs `/logs` | 데이터 API가 예전 판 → 1절 `--force-recreate` · `sleep 3` |
|
||||
| `! live run log(s) left` · `! FAQ entr(ies) added` · `! fault switch is on` | `uv run tools/flow.py ops --reset` |
|
||||
| credential | `cd ~/aio-01d4-stu/Last3Mon/65/n8n && bash register-credentials.sh` |
|
||||
| CLI coding agent | [67일차 준비](../67/00-DAY67-PREP.md) 2절 |
|
||||
|
||||
---
|
||||
|
||||
## 3. 미리 읽어 오면 좋은 내용 (선택, 약 5분)
|
||||
|
||||
### 3.1 같은 기록인데 숫자가 다르다면
|
||||
|
||||
"두 주 동안 헬프데스크가 몇 번 실패했나?"를 옆 사람과 각자 세었는데 답이 다르다면, 누가 틀린 걸까요? 마지막 날을 넣었나, 백분율로 썼나, 어디서 반올림했나 — 오늘 첫 실습에서 팀이 쓰던 보고서와 직접 비교합니다.
|
||||
|
||||
### 3.2 용어
|
||||
|
||||
| 용어 | 한 줄 설명 |
|
||||
| --- | --- |
|
||||
| 실행 기록 (run log) | 워크플로우가 한 번 돌 때마다 남기는 한 줄 (언제 · 결과 · 갈래 · 시간 · 실패한 노드) |
|
||||
| 지표 (metric) · 정의 | 기록을 세고 나눈 숫자 · 무엇을 세고 무엇으로 나누고 몇 자리로 쓰는지 정한 것 |
|
||||
| p50 · p95 | 짧은 것부터 줄 세웠을 때 절반째 · 95%째 시간 ("100명 중 95명은 이 안") |
|
||||
| 이관율 | 답을 못 해 사람(담당자)에게 넘긴 비율 |
|
||||
| 이상 시간대 | 평소(비교 기준)보다 크게 나빴던 시간 |
|
||||
| SLO | "오류율 1% 이하"처럼 숫자로 정한 서비스 약속 |
|
||||
| 다시 돌려 보기 (replay) | 고친 뒤 같은 조건 · 같은 질문으로 다시 재기 |
|
||||
|
||||
### 3.3 7교시 요청서
|
||||
|
||||
[VIBE-REQ-TLOG](../../Last3Mon/77/VIBE-REQ-TLOG.md)를 한 번 읽어 옵니다. 운영 담당이 원하는 것 열두 가지 중 "꼭"은 무엇일까요? 그리고 "n8n 보고서와 같은 숫자"가 왜 중요할까요?
|
||||
|
||||
## 4. 당일 준비물
|
||||
|
||||
- 충전된 노트북과 충전기, WSL의 Docker, Windows Terminal(WSL) 창 **두 개**, 웹 브라우저
|
||||
- 숫자를 적을 `my-work/OPS.md` (`cp templates/OPS-ANALYSIS-TEMPLATE.md my-work/OPS.md`)
|
||||
|
||||
## 확인
|
||||
|
||||
- [ ] `curl -s 'localhost:8800/logs?limit=1'`이 `count 666`
|
||||
- [ ] `logs --from 2026-10-26 --to 2026-10-26`이 `70 run(s) · errors 16`
|
||||
- [ ] `uv run tools/flow.py doctor` → 마지막 줄 `ready`
|
||||
@@ -0,0 +1,280 @@
|
||||
# 1단계 · 실행 기록 읽기와 지표
|
||||
|
||||
- 교시: 1교시 강의 (09:00~09:50) · 2교시 [Lab 01](../../Last3Mon/77/LAB-01-Q-READ-AND-MEASURE.md) 실습 5개 (10:00~10:50)
|
||||
- 이 단계가 끝나면: 실행 기록 한 줄에 무엇이 있는지 읽고, 같은 기록에서 숫자가 달라지는 까닭을 **정의**로 설명하고, 정의대로 세는 보고서(실행 · 오류율 · p50 · p95 · 갈래)를 Code로 만들고, 경계(하루 · 0건 · 거르기)에서 재 보고, 날짜 · 릴리스 · 단계 · 비용으로 나눠 볼 수 있다.
|
||||
- 숫자: 모두 강사 노트북 실측입니다 (65일차 n8n 2.42.6, 77일차 판 데이터 API의 두 주 실행 기록 666줄, 10/31 실습을 5개로 늘린 뒤 정답 워크플로우를 학생 순서대로 1회). 두 주 기록의 지표는 누가 세어도 같습니다. 출력 전부는 수업 뒤 공개되는 `Last3Mon/77/answers/LAB-TEST-RESULT.md`에 있습니다.
|
||||
- 실습 가리키기: 이 문서에서 "Lab 01 예제 1"은 2교시 [Lab 01 문서](../../Last3Mon/77/LAB-01-Q-READ-AND-MEASURE.md)의 그 절입니다. 파일 경로(`cases/` · `requests/` · `my-work/` · `reference/`)는 실습 폴더 `~/aio-01d4-stu/Last3Mon/77` 기준입니다.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A["1. 실행 기록"] --> B["2. 지표는 정의"] --> C["3. 백분위"] --> D["4. 숫자는 Code"] --> E["5. 경계와 0"]
|
||||
E --> F["6. 묶어서 세기"] --> G["7. 단계 시간과 비용"] --> H["8. 요청문으로"]
|
||||
```
|
||||
|
||||
## 0. 이 시간 (50분)
|
||||
|
||||
| 시간 | 절 · 개요 | 하는 일 |
|
||||
| --- | --- | --- |
|
||||
| 09:00~09:06 | 개요 1~6장 | 오늘 하루, 두 주 기록 666줄과 팀의 보고서, 실습 15개 |
|
||||
| 09:06~09:13 | 1 · 개요 7장 | 실행 기록, 로그 · 지표 · 추적 |
|
||||
| 09:13~09:20 | 2 · 개요 8장 | 같은 기록 다른 숫자, 지표의 정의 |
|
||||
| 09:20~09:27 | 3 · 4 · 개요 9~10장 | 평균과 p95, 숫자는 Code가 |
|
||||
| 09:27~09:33 | 5 · 개요 11장 | 경계와 0 |
|
||||
| 09:33~09:43 | 6 · 7 · 개요 12~14장 | 날짜별 · 릴리스별 · 표본 크기, 단계 시간 · 비용 |
|
||||
| 09:43~09:50 | 8 · 9 · 확인 질문 | 요청문, 자주 하는 실수 |
|
||||
|
||||
### 2교시 Lab 01에서 이어서 하는 것
|
||||
|
||||
| 2교시 실습 (시각) | 이 강의의 절 | 실습에서 하는 일 | 쓰는 파일 · 명령 |
|
||||
| --- | --- | --- | --- |
|
||||
| 시작 (10:00) | — | 운영 분석표 복사 | `cp templates/OPS-ANALYSIS-TEMPLATE.md my-work/OPS.md` (오늘의 숫자를 모두 여기에) |
|
||||
| Lab 01 예제 1 (10:00~10:10, 에이전트 없이) | 1 · 2 | 두 주 · 하루를 훑고, 같은 기간을 기준 보고서에 | `logs --from … --to …`, `call base-report requests/two-weeks.json` · `monday.json` → `OPS.md` 1.1 |
|
||||
| Lab 01 예제 2 (10:10~10:25) | 2 · 3 · 4 | 정의대로 세는 내 보고서 | `my-work/log-report.json` (새로), 테스트 `cases/lab01.json` |
|
||||
| Lab 01 예제 3 (10:25~10:32, 에이전트 없이) | 5 | 경계에서 두 보고서를 재 보기 | `test cases/lab01-edges.json -v` · `--webhook base-report` → `OPS.md` 1.2 |
|
||||
| Lab 01 과제 1 (10:32~10:40) | 6 | 날짜별 · 릴리스별 | 테스트 `cases/lab01-challenge.json` |
|
||||
| Lab 01 과제 2 (10:40~10:50) | 7 | 단계별 p50 · p95 · 비용 | 테스트 `cases/lab01-challenge2.json` |
|
||||
|
||||
## 1. 실행 기록: 운영의 영수증 (2교시 Lab 01 예제 1)
|
||||
|
||||
### 일반 설명
|
||||
|
||||
> **생활 속 예 · 가게의 영수증 더미.** 동네 가게 계산대 옆 상자에 두 주 치 영수증이 쌓여 있습니다. 한 장 한 장에는 언제 · 무엇을 · 얼마에 · 카드였는지 현금이었는지가 적혀 있습니다. "요즘 장사가 어때?"라는 물음에 감으로 답할 수도 있지만, 영수증을 세면 숫자로 답할 수 있습니다. 워크플로우의 **실행 기록**이 이 영수증이고, 오늘은 영수증 더미를 장부(지표)로 만드는 날입니다.
|
||||
|
||||
**실행 기록(run log)은 실행 한 번에 한 줄입니다.** 워크플로우가 한 번 돌 때마다 언제 시작했고, 무엇을 받았고, 어느 갈래로 끝났고, 얼마나 걸렸고, 실패했다면 어느 노드에서 무슨 말로 실패했는지를 남깁니다. 사람이 읽는 문장(`"검색 실패"`)이 아니라 **칸이 정해진 JSON**으로 남기는 것을 구조화 로그(structured logging)라고 부릅니다. 칸이 정해져 있어야 셀 수 있습니다.
|
||||
|
||||
| 관측의 세 가지 (observability) | 무엇 | 오늘 |
|
||||
| --- | --- | --- |
|
||||
| 로그 (logs) | 일어난 일 하나하나의 기록 | 실행 기록 666줄 |
|
||||
| 지표 (metrics) | 로그를 세고 나눈 숫자 | 실행 · 오류율 · p95 · 답 못 함 |
|
||||
| 추적 (traces) | 한 요청이 거친 단계마다의 시간 | `steps.faq_ms` · `steps.answer_ms` (7절) |
|
||||
|
||||
업계 도구로는 로그를 모으는 Elasticsearch · Loki · CloudWatch Logs, 지표를 그리는 Prometheus · Grafana · Datadog, 추적의 표준인 OpenTelemetry가 있습니다. n8n도 실행마다 Executions 화면에 기록을 남기고, 공개 API(`/api/v1/executions`)로 가져올 수 있습니다. 오늘은 그 기록을 헬프데스크가 직접 남긴 모양으로 데이터 API에 모아 두었습니다.
|
||||
|
||||
**기록을 남기는 쪽의 규칙.** 칸 이름과 뜻이 바뀌면 보고서가 깨집니다. 그래서 기록의 모양은 **계약**입니다 (AGENTS.md 2절 "실행 기록 한 줄"). 오류일 때도 같은 모양으로, 갈래마다 같은 칸으로 남깁니다 (Lab 03의 헬프데스크).
|
||||
|
||||
### 오늘 실습에서
|
||||
|
||||
두 주(10/19~10/30, 평일 10일) 헬프데스크 기록 666줄. 한 줄의 칸은 `started_at` · `status` · `route` · `duration_ms` · `error_node` · `error_message` · `topic` · `release` · `repeat` · `steps` · `cost_usd` · `llm_calls` 등입니다. `logs`로 훑으면 (Lab 01 예제 1):
|
||||
|
||||
| 기간 | 실행 | 오류 | 갈래 |
|
||||
| --- | --- | --- | --- |
|
||||
| 두 주 | 666 | 21 (3.2%) | 자동 답변 591 · 담당자 연결 34 · 오류 21 · 잠시 후 20 |
|
||||
| 10/26 (월) 하루 | 70 | **16** (22.9%) | 자동 답변 50 · 오류 16 · 담당자 연결 4 |
|
||||
|
||||
- 두 주 오류 21건 중 16건이 하루에 몰려 있습니다. "두 주 오류율 3%"라는 숫자 하나로는 이것이 보이지 않습니다 (6절 · Lab 02).
|
||||
|
||||
## 2. 지표는 정의다: 같은 기록, 다른 숫자 (2교시 Lab 01 예제 1 · 2)
|
||||
|
||||
### 일반 설명
|
||||
|
||||
> **생활 속 예 · 알바생 둘의 다른 장부.** 사장님이 "두 주 동안 몇 건 팔았지?"라고 물었더니 알바생 둘의 답이 다릅니다. 한 사람은 마지막 날 영수증을 빼고 셌고, 다른 사람은 넣고 셌습니다. 둘 다 계산은 정확합니다. **세는 법**이 달랐을 뿐입니다. 그래서 가게는 "마감일도 넣는다, 금액은 원 단위까지" 같은 장부 쓰는 법을 벽에 붙여 둡니다. 그것이 지표의 정의입니다.
|
||||
|
||||
**지표 = 정의 + 계산.** "오류율"이라는 이름만으로는 숫자가 하나로 정해지지 않습니다. 정의는 적어도 다섯 가지를 정해야 합니다.
|
||||
|
||||
| 정해야 할 것 | 예 | 정하지 않으면 |
|
||||
| --- | --- | --- |
|
||||
| 무엇을 세나 (분자) | `status`가 `error`인 실행 | 담당자 연결도 실패로 셀지 사람마다 다름 |
|
||||
| 무엇으로 나누나 (분모) | 그 기간의 모든 실행 | 답한 것만 · 오류 아닌 것만… |
|
||||
| 기간의 경계 | `from ≤ 날짜 ≤ to` (끝날 포함) | 끝날이 빠지거나 겹침 |
|
||||
| 표현 | 비율, 소수 4자리 (0.0315) | 3.15 · 3.149… · 3% |
|
||||
| 0건일 때 | 0 | `0 / 0` → `NaN` · `null` |
|
||||
|
||||
**하나의 출처(single source of truth).** 회사에서 같은 지표가 보고서마다 다르면 회의가 "어느 숫자가 맞나"로 끝납니다. 그래서 데이터 팀은 지표 정의서(metric definitions, 요즘은 "시맨틱 레이어"라고도 부름)를 한 곳에 두고, 모든 보고서가 그 정의를 쓰게 합니다. 오늘 정의서는 AGENTS.md 3절이고, 계산은 `my-log-report` 한 곳입니다. 요약 · 주간 보고 · SLO 알림은 모두 이 보고서를 **다시 불러** 씁니다 (Lab 02 과제 2 · Lab 03 과제).
|
||||
|
||||
### 오늘 실습에서
|
||||
|
||||
팀이 지난달 만든 기준 보고서 `base-report`와 `logs`를 같은 기간으로 비교했습니다 (Lab 01 예제 1).
|
||||
|
||||
| 칸 | `logs` | 기준 보고서 | 정의의 차이 |
|
||||
| --- | --- | --- | --- |
|
||||
| 두 주 실행 | 666 | **602** | 기준은 `started_at < to` → 끝날(10/30, 64건)을 뺌 |
|
||||
| 오류율 | 0.0315 | **3.488…** | 백분율 · 반올림 없음 · 분모 602 |
|
||||
| 10/26 하루 | 70 · 16 | **0 · `null`** | 끝날을 빼니 하루가 통째로 빠짐, 0 / 0 |
|
||||
| 느린 정도 | p95 2537ms | 평균 1249.2ms | 평균만 |
|
||||
| 오류 갈래 | 21 | 없음 | `route: null`을 건너뜀 |
|
||||
|
||||
- 기준에 오늘 테스트를 돌리면 **0/5**, 정의대로 세는 내 보고서는 **5/5**입니다 (Lab 01 예제 2). 기준이 "고장"이 아니라 **정의가 다른** 것이라는 점이 중요합니다. 운영 회의에서는 그동안 "두 주 602건"이라고 말해 왔습니다.
|
||||
|
||||
## 3. 백분위: 평균이 숨기는 것 (2교시 Lab 01 예제 2)
|
||||
|
||||
### 일반 설명
|
||||
|
||||
> **생활 속 예 · 버스 도착 시간.** "이 버스는 평균 10분마다 와요"라는 말은, 9번은 5분 만에 오고 1번은 55분 만에 와도 맞습니다. 그 55분을 기다린 사람에게 평균은 아무 의미가 없습니다. "열 번 중 아홉 번은 8분 안에 와요"가 기다리는 사람에게 쓸모 있는 말입니다. 그것이 백분위입니다.
|
||||
|
||||
**백분위(percentile).** 값을 작은 것부터 줄 세웠을 때 p%째에 있는 값입니다. p50(중앙값)은 "절반이 이 안", p95는 "100명 중 95명이 이 안", p99는 "100명 중 99명이 이 안"입니다. 응답 시간에서는 평균보다 p95 · p99를 봅니다. 가장 느린 몇 %(꼬리 지연, tail latency)를 겪는 사용자가 불만을 말하기 때문입니다.
|
||||
|
||||
| 같은 기록 | 평균 | p50 | p95 |
|
||||
| --- | --- | --- | --- |
|
||||
| 1초 × 9건 + 10초 × 1건 | 1.9초 | 1초 | 10초 |
|
||||
|
||||
**백분위도 정의가 여럿입니다.** 엑셀의 `PERCENTILE.INC`, NumPy의 기본값은 두 값 사이를 **보간**합니다. 오늘은 가장 가까운 순위(nearest-rank)입니다: n개를 오름차순으로 놓고 `ceil(p × n)`번째 값. 666건이면 p95는 `ceil(632.7)` = 633번째입니다. 보간하면 소수가 나오고, 다른 도구와 1~2ms씩 다릅니다. 그래서 정의서에 **어느 방법**인지까지 씁니다.
|
||||
|
||||
**오류 실행도 넣나.** 오늘 정의는 "오류 포함"입니다. 오류로 끝난 실행도 사용자는 그만큼 기다렸기 때문입니다. 성공한 실행만 재는 회사도 있습니다 — 어느 쪽이든 **적어 두는 것**이 중요합니다.
|
||||
|
||||
### 오늘 실습에서
|
||||
|
||||
| 기간 | p50 | p95 |
|
||||
| --- | --- | --- |
|
||||
| 두 주 | 1205ms | 2537ms |
|
||||
| 첫 주 | 1252ms | 2525ms |
|
||||
| 둘째 주 | 1171ms | 2598ms |
|
||||
|
||||
- 둘째 주는 절반은 더 빨라졌지만(p50 1252 → 1171) 느린 쪽은 더 느려졌습니다(p95 2525 → 2598). 평균 하나로는 이렇게 나눠 말할 수 없습니다.
|
||||
|
||||
## 4. 숫자는 Code가 센다 (2교시 Lab 01 예제 2)
|
||||
|
||||
### 일반 설명
|
||||
|
||||
> **생활 속 예 · 계산기와 점원.** 손님에게 물건을 설명하는 일은 말 잘하는 점원이 잘합니다. 하지만 하루 매출 합계를 점원의 암산에 맡기지는 않습니다. 계산기(포스기)가 셉니다. 점원은 계산기가 낸 숫자를 손님에게 **설명**합니다.
|
||||
|
||||
**LLM은 세는 일에 약합니다.** 언어 모델은 다음 글자를 그럴듯하게 이어 쓰는 방식이라, 수백 줄에서 조건에 맞는 줄을 정확히 세거나 나눗셈을 하는 일에서 틀릴 수 있습니다. 그리고 줄이 많을수록 입력 토큰이 늘어 비쌉니다 (75일차). 집계는 Code(또는 SQL)가 정확하게 · 빠르게 · 늘 같게 합니다.
|
||||
|
||||
| 일 | 누가 | 까닭 |
|
||||
| --- | --- | --- |
|
||||
| 거르기 · 세기 · 나누기 · 백분위 | Code (또는 데이터베이스) | 정확 · 빠름 · 재현 가능 |
|
||||
| 센 결과를 사람의 말로 | LLM | 문장 · 요약 (Lab 02 과제 2) |
|
||||
| LLM 글의 숫자가 맞는지 | Code | 지어낸 숫자 찾기 (Lab 02 과제 2) |
|
||||
|
||||
**거르기는 데이터 쪽에서.** 기간 · `tag` · `source`로 거르는 일은 데이터 API(`POST /logs/query`)가 합니다. 워크플로우가 전부 가져와 직접 거르면 정의가 두 곳에 생기고(기준 보고서처럼), 기록이 많아지면 느려집니다. 데이터베이스에서 `WHERE`로 거르고 가져오는 것과 같은 원칙입니다.
|
||||
|
||||
### 오늘 실습에서
|
||||
|
||||
- 내 보고서는 `Get logs`(HTTP, 본문 그대로 넘김) → `Compute metrics`(Code 하나) → 응답, 노드 셋입니다. 666줄을 세는 데 **0.1초 안팎**, LLM은 부르지 않습니다 (Lab 01 예제 2).
|
||||
- 둘째 주 응답: 357건 · 오류 21 · 0.0588 · p50 1171 · p95 2598, 갈래 21 + 299 + 17 + 20 = 357. 갈래의 합이 `total`과 맞는지 보는 것은 간단한 **자기 검산**입니다 (기준 보고서는 581 ≠ 602).
|
||||
|
||||
## 5. 경계와 0: 정의는 끝에서 시험받는다 (2교시 Lab 01 예제 3)
|
||||
|
||||
### 일반 설명
|
||||
|
||||
> **생활 속 예 · 줄자의 끝 눈금.** 줄자로 1m를 잴 때 끝 눈금 한 칸은 상관없어 보입니다. 하지만 1cm짜리를 재면 그 한 칸이 전부입니다. 장부도 그렇습니다. 두 주를 셀 때는 그럴듯하던 장부가 "오늘 하루만" · "손님이 없던 날"을 물으면 0이나 오류를 냅니다.
|
||||
|
||||
**경계값 검사(boundary testing).** 소프트웨어 테스트의 오래된 원칙: 실수는 범위의 **끝**에서 나옵니다. 그래서 테스트에는 보통 경우와 함께 경계 경우를 넣습니다.
|
||||
|
||||
| 경계 | 오늘의 질문 | 정의가 없으면 |
|
||||
| --- | --- | --- |
|
||||
| 끝날 | from = to (하루) | `<`와 `≤`의 차이로 하루가 통째로 빠짐 |
|
||||
| 0건 | 기록이 없는 기간 · 주말 | `0 / 0` = `NaN` → JSON `null`, 화면에 빈칸 |
|
||||
| 거르기 | `source: live`, `tag` | 무시하면 늘 전체 |
|
||||
| 거를 것 없음 | 기간 비우기 | (보통 우연히 맞음) |
|
||||
|
||||
**우연히 맞는 테스트.** 경계가 문제를 **가려서** 맞는 경우가 있습니다. 실행이 없는 주말에는 끝날을 빼든 넣든 0입니다. 그래서 "통과했다"보다 "어느 케이스가 무엇을 시험하나"를 봅니다.
|
||||
|
||||
### 오늘 실습에서
|
||||
|
||||
같은 케이스 `cases/lab01-edges.json`을 두 보고서에 (Lab 01 예제 3):
|
||||
|
||||
| 경계 | 내 보고서 | 기준 보고서 |
|
||||
| --- | --- | --- |
|
||||
| 하루 | ✔ 70 · 16 | ✘ 0 |
|
||||
| 빈 기간 | ✔ 0 · 0 · 0 | ✘ 오류율 · p95 `null` |
|
||||
| 주말 | ✔ 0 | ✔ 0 (우연) |
|
||||
| 기간 없음 | ✔ 666 | ✔ 666 (우연) |
|
||||
| `source: seed` | ✔ 666 | ✘ 602 |
|
||||
| `source: live` | ✔ 0 | ✘ **666** (`source`를 무시) |
|
||||
|
||||
- 내 보고서 6/6, 기준 2/6. `source: live`에 666을 내는 보고서는 Lab 03에서 "오늘 고친 뒤 기록만" 보려 할 때 두 주 전체를 보여 줍니다.
|
||||
|
||||
## 6. 묶어서 세기: 날짜별 · 릴리스별, 그리고 표본 크기 (2교시 Lab 01 과제 1)
|
||||
|
||||
### 일반 설명
|
||||
|
||||
> **생활 속 예 · 가계부의 날짜별 칸.** 한 달 지출이 늘었다는 것만으로는 무엇을 줄일지 모릅니다. 날짜별 칸을 보면 "15일에 한 번 크게 썼다"가 보입니다. 새로 바꾼 장보기 앱도 "그 앱으로 산 날만" 따로 봐야 좋아졌는지 압니다. 그런데 그 앱으로 산 날이 이틀뿐이라면? 아직 판단하기 이릅니다.
|
||||
|
||||
**묶어서 세기(group by).** 같은 칸의 값이 같은 줄끼리 모아 각각 셉니다. 지표 대부분은 "무엇으로 묶고 · 무엇을 세고 · 무엇으로 나누나" 세 가지로 정해집니다. SQL의 `GROUP BY`, 엑셀의 피벗 테이블, 대시보드의 "차원(dimension)으로 나누기"가 모두 같은 일입니다.
|
||||
|
||||
**분모를 고르기.** "다시 묻는 비율"을 버전의 **답의 질**로 쓰려면 분모는 "답을 준 실행"이어야 합니다. 답을 못 한 실행(담당자 연결 · 오류)을 넣으면 답의 질과 상관없는 것이 섞입니다.
|
||||
|
||||
**표본 크기(sample size).** 8건 중 5건은 62.5%지만, 한두 건만 달라도 크게 바뀝니다. 카나리 배포(74일차)처럼 일부 사용자만 받은 버전은 건수가 작습니다. 비율 옆에는 늘 **건수**를 씁니다. 통계에서는 신뢰구간으로 "이 비율이 얼마나 흔들릴 수 있나"를 말하지만, 운영 보고에서는 "건수를 같이 쓰고, 너무 적으면 판단을 미룬다"가 첫걸음입니다.
|
||||
|
||||
### 오늘 실습에서
|
||||
|
||||
(Lab 01 과제 1)
|
||||
|
||||
| 묶음 | 결과 |
|
||||
| --- | --- |
|
||||
| 10/26 (월) | 70건 · 오류 16 · 0.2286 |
|
||||
| 10/29 (목) | 97건 · 오류 5 |
|
||||
| 그 밖의 날 | 오류 0 (평일 10일, 주말 없음) |
|
||||
| 1.0.0 | 답 402 · 다시 물음 19 · 4.73% |
|
||||
| 1.1.0 | 답 181 · 다시 물음 14 · 7.73% |
|
||||
| 1.2.0 (카나리) | 답 **8** · 다시 물음 5 · 62.5% |
|
||||
|
||||
- 둘째 주에 "오류가 늘었다"는 말의 실제는 **월요일 · 목요일 이틀**입니다. 1.2.0의 62.5%는 8건이라 판단을 미룹니다. 402 + 181 + 8 = 591 = 두 주 `자동 답변` 수 (분모가 맞는지 검산).
|
||||
|
||||
## 7. 단계 시간과 비용: 어디가 느리고 얼마 들었나 (2교시 Lab 01 과제 2)
|
||||
|
||||
### 일반 설명
|
||||
|
||||
> **생활 속 예 · 택배의 구간별 시간.** 택배가 늦었을 때 배송 조회를 보면 "집하 → 허브 → 배송" 구간마다 시간이 찍혀 있습니다. 허브에서 하루를 묵었다면 기사님을 재촉해도 소용없습니다. 그리고 택배비가 상자마다 얼마인지 알아야 한 달 운송비를 잡습니다.
|
||||
|
||||
**단계(span) 시간.** 한 실행의 전체 시간은 단계 시간의 합입니다. 추적(tracing) 도구는 한 요청이 거친 단계마다 시작 · 끝을 기록해, "전체 2.5초 중 LLM 2.4초"처럼 나눠 보여 줍니다 (OpenTelemetry의 span, Jaeger · Zipkin · Langfuse 같은 LLM 추적 도구). 전체 p95가 나빠졌을 때 **어느 단계가** 늘었는지 보면 고칠 곳이 정해집니다.
|
||||
|
||||
**거치지 않은 단계는 뺀다.** 그 단계를 거치지 않은 실행은 0ms로 남습니다. 0을 넣고 백분위를 구하면 단계가 실제보다 빨라 보입니다. 단계마다 "값이 있는 실행만"과 그 수(`runs`)를 함께 씁니다.
|
||||
|
||||
**요청당 비용.** LLM은 쓰는 만큼 돈이 듭니다 (75일차). 합계는 예산을, 실행당 비용은 "질문 하나에 얼마"를 말합니다. 클라우드 비용을 팀 · 기능 · 요청 단위로 나눠 보는 일을 업계에서는 FinOps라고 부릅니다.
|
||||
|
||||
### 오늘 실습에서
|
||||
|
||||
(Lab 01 과제 2)
|
||||
|
||||
| 볼 것 | 두 주 | 10/26 (월)만 |
|
||||
| --- | --- | --- |
|
||||
| FAQ 단계 p95 | **39ms** (646건) | **1000ms** |
|
||||
| 답 단계 p50 · p95 | 1179 · 2509ms (596건) | p95 2482ms |
|
||||
| 비용 · LLM 호출 | 0.07836달러 (실행당 0.000118달러) · 596번 | 0.00645달러 · 50번 |
|
||||
|
||||
- 평소 느린 것은 **LLM 답 단계**입니다. 그런데 월요일만 떼어 보면 FAQ 단계 p95가 1000ms — FAQ 검색의 timeout(1초)에 걸린 실행이 p95를 차지했습니다. 같은 지표도 **기간을 나누면 다른 고칠 곳**이 보입니다 (Lab 02 · 03).
|
||||
- `runs` 646 = 666 − `잠시 후` 20, 596 = 답한 591 + 답 도중 실패 5. 0을 넣었다면 단계 p50이 작게 나왔을 것입니다.
|
||||
|
||||
## 8. 요청문(프롬프트)으로 에이전트에게 맡기기
|
||||
|
||||
지표 요청문은 "보고서 만들어 줘"가 아니라 **정의**를 적습니다 (AGENTS.md 1절: 에이전트는 먼저 "무엇을 세고 무엇으로 나누는지"를 보여 줌).
|
||||
|
||||
| 넣을 것 | 예 |
|
||||
| --- | --- |
|
||||
| 파일 · 웹훅 · 이름 | "`my-work/log-report.json`, 웹훅 `my-log-report`, 이름 `77 Log report (my)`" |
|
||||
| 거르기는 누가 | "웹훅 본문의 `from` · `to` · `tag` · `source`를 `/logs/query`에 그대로, `source` 기본 `all`" |
|
||||
| 지표와 정의 | "`error_rate` = `errors / total`, 소수 4자리, 0건이면 0" |
|
||||
| 백분위 방법 | "오름차순 `ceil(p × n)`번째, 오류 실행 포함" |
|
||||
| 하지 않을 것 | "LLM은 쓰지 않는다" |
|
||||
| 기대 결과 | "`cases/lab01.json`, 앞의 테스트도 그대로" |
|
||||
|
||||
## 9. 자주 하는 실수
|
||||
|
||||
| 실수 | 결과 | 바로잡기 |
|
||||
| --- | --- | --- |
|
||||
| "p95 구해 줘"만 씀 | 에이전트마다 보간 · 평균 · 다른 순위 | 정의를 요청문에 (`ceil(p × n)`번째) |
|
||||
| 워크플로우가 직접 날짜를 거름 | `<` · `≤` 실수, 정의가 두 곳 | 데이터 API에 맡김 |
|
||||
| 백분율로 내고 끊지 않음 | 3.488372…, 다른 보고서와 비교 불가 | 비율, 소수 4자리 |
|
||||
| 0건을 생각하지 않음 | `null` · `NaN`, 다음 계산이 깨짐 | 0건이면 0 |
|
||||
| 오류를 갈래에서 빼먹음 | 갈래의 합 ≠ 실행 수 | `null` → `"오류"`, 합으로 검산 |
|
||||
| 비율만 보고 건수를 안 봄 | 8건의 62.5%로 버전을 판단 | 건수를 함께 |
|
||||
| 단계 값 0을 그대로 넣음 | 단계가 빨라 보임 | 값이 있는 실행만, `runs`를 함께 |
|
||||
| LLM에게 기록을 주고 세게 함 | 틀리고 비쌈 | 세는 일은 Code |
|
||||
|
||||
## 확인 질문
|
||||
|
||||
<details><summary>1. 기준 보고서는 두 주를 602건, 내 보고서는 666건이라고 합니다. 어느 쪽이 "맞나요"?</summary>
|
||||
|
||||
둘 다 자기 정의로는 정확합니다. 기준은 `started_at < to`로 끝날을 뺐고(64건), 내 보고서는 끝날을 포함합니다. "맞는 숫자"는 팀이 합의한 정의(AGENTS.md 3절)를 따른 숫자이고, 그래서 정의서를 한 곳에 두고 모든 보고서가 그것을 씁니다. 회의에서 숫자가 다르면 먼저 정의를 맞춥니다.
|
||||
</details>
|
||||
|
||||
<details><summary>2. 응답 시간을 평균 대신 p95로 보는 까닭은? p95를 "구해 줘"라고만 요청하면 무엇이 문제인가요?</summary>
|
||||
|
||||
평균은 아주 느린 몇 건에 끌려가고, 대부분이 겪는 시간과 가장 느린 쪽을 나눠 말하지 못합니다. p95는 "100명 중 95명은 이 안"이라 사용자 경험에 가깝습니다. 다만 백분위는 계산 방법(가장 가까운 순위 · 보간)이 여럿이라, 방법을 정하지 않으면 도구마다 값이 1~2ms씩 다릅니다.
|
||||
</details>
|
||||
|
||||
<details><summary>3. 경계 테스트에서 기준 보고서가 주말 · 기간 없음 케이스를 통과했습니다. 그러면 그 부분은 맞게 만든 것인가요?</summary>
|
||||
|
||||
아닙니다. 실행이 없는 주말은 끝날을 넣든 빼든 0이고, 기간이 없으면 거를 것이 없어 끝날 문제가 드러나지 않습니다. 경계가 문제를 가려서 **우연히** 맞은 것입니다. 하루 · 빈 기간 · `source` 케이스가 같은 정의를 시험해 ✘를 냈습니다.
|
||||
</details>
|
||||
|
||||
<details><summary>4. 1.2.0의 다시 묻는 비율이 62.5%입니다. 1.2.0을 바로 되돌려야 하나요?</summary>
|
||||
|
||||
8건으로는 판단하기 이릅니다. 한두 건만 달라도 비율이 크게 바뀝니다. 비율과 함께 건수를 보고하고, 카나리 비율을 늘려 건수를 모으거나, 다시 물은 다섯 건의 내용을 직접 읽어 봅니다. 분모를 "답을 준 실행"으로 정한 것도 함께 말합니다.
|
||||
</details>
|
||||
|
||||
<details><summary>5. 두 주 전체 p95 2537ms 중 FAQ 단계는 39ms입니다. 그런데 Lab 02 · 03에서는 FAQ 검색을 고칩니다. 왜인가요?</summary>
|
||||
|
||||
평소에는 LLM 답 단계가 느리지만, **월요일만** 보면 FAQ 단계 p95가 1000ms입니다 — FAQ 검색이 느려 timeout에 걸린 실행이 그날 오류 16건이었습니다. 두 주 전체의 숫자가 하루의 사건을 가렸습니다. 고칠 곳은 기간을 나눠 보고 정합니다.
|
||||
</details>
|
||||
@@ -0,0 +1,279 @@
|
||||
# 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>
|
||||
@@ -0,0 +1,317 @@
|
||||
# 3단계 · 고치고 다시 재기
|
||||
|
||||
- 교시: 5교시 강의 (14:00~14:50) · 6교시 [Lab 03](../../Last3Mon/77/LAB-03-Q-IMPROVE-AND-REMEASURE.md) 실습 5개 (15:00~15:50)
|
||||
- 이 단계가 끝나면: 찾은 문제를 고칠 곳(워크플로우 · 콘텐츠)과 사람으로 나누고, 같은 조건 · 같은 질문으로 다시 돌려 고친 효과를 재고, SLO로 "약속을 지켰나"를 판정하고, 고친 것의 대가(새로 나빠진 지표)를 단계 시간으로 찾고, 만든 보고서를 조립해 주간 보고를 만들고, SLO를 어기면 알림을 남기되 같은 알림을 되풀이하지 않을 수 있다.
|
||||
- 숫자: 모두 강사 노트북 실측입니다 (10/31, 정답 워크플로우를 학생 순서대로 1회). 오늘 실습에서 새로 남긴 기록(`source: live`)의 시간은 실행마다 조금씩 다릅니다. 출력 전부는 수업 뒤 공개되는 `Last3Mon/77/answers/LAB-TEST-RESULT.md`에 있습니다.
|
||||
- 실습 가리키기: "Lab 03 예제 1"은 6교시 [Lab 03 문서](../../Last3Mon/77/LAB-03-Q-IMPROVE-AND-REMEASURE.md)의 그 절입니다.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A["1. 다시 돌려 재기"] --> B["2. 고칠 곳과 사람"] --> C["3. SLO"] --> D["4. 고친 것의 대가"]
|
||||
D --> E["5. 주간 보고"] --> F["6. SLO 알림"] --> G["7. 개선의 고리"] --> H["8. 오늘 하루 한 장"] --> I["9. 요청문으로"]
|
||||
```
|
||||
|
||||
## 0. 이 시간 (50분)
|
||||
|
||||
| 시간 | 절 · 개요 | 하는 일 |
|
||||
| --- | --- | --- |
|
||||
| 14:00~14:09 | 1 · 2 · 개요 22장 | 다시 돌려 재기, 워크플로우와 콘텐츠 |
|
||||
| 14:09~14:17 | 3 · 개요 23장 | SLI · SLO · 위반, 에러 예산 |
|
||||
| 14:17~14:24 | 4 · 개요 24장 | 고친 것의 대가: 오류 0 대신 p95 3560 |
|
||||
| 14:24~14:32 | 5 · 6 · 개요 25~26장 | 주간 보고 조립, SLO 알림과 알림 피로 |
|
||||
| 14:32~14:42 | 7 · 8 · 개요 27~28장 | 재기 → 찾기 → 고치기 → 다시 재기, 오늘 하루 한 장 |
|
||||
| 14:42~14:50 | 9 · 10 · 확인 질문 | 요청문, 자주 하는 실수 |
|
||||
|
||||
### 6교시 Lab 03에서 이어서 하는 것
|
||||
|
||||
| 6교시 실습 (시각) | 이 강의의 절 | 실습에서 하는 일 | 쓰는 파일 · 명령 |
|
||||
| --- | --- | --- | --- |
|
||||
| Lab 03 예제 1 (15:00~15:14) | 1 · 2 | 고치기 전(`before`) → timeout · 재시도 + 와이파이 FAQ → 고친 뒤(`after`) | `my-work/helpdesk.json` (제공 파일을 복사), `requests/faq-wifi.json`, 테스트 `replay-before` · `replay-after` · `lab03` → `OPS.md` 4.1 |
|
||||
| Lab 03 예제 2 (15:14~15:22) | 3 | SLO 판정 | `my-work/log-report.json`에 더함, 테스트 `cases/lab03-slo.json` → `OPS.md` 5절 |
|
||||
| Lab 03 예제 3 (15:22~15:28, 에이전트 없이) | 4 | 평소 FAQ로 같은 10개(`normal`), 단계 시간으로 비교 | `test cases/replay-normal.json -v`, `test cases/lab03-cost.json -v` → `OPS.md` 4.2 |
|
||||
| Lab 03 과제 1 (15:28~15:40) | 5 | 주간 보고 | `my-work/weekly.json` (새로), 테스트 `cases/lab03-challenge.json` → `OPS.md` 6절 |
|
||||
| Lab 03 과제 2 (15:40~15:50) | 6 | SLO를 어기면 알림 · 10분 안 같은 알림은 `suppressed` | `my-work/slo-alert.json` (새로), 테스트 `cases/lab03-challenge2.json`, `ops --reset` |
|
||||
|
||||
## 1. 고친 효과는 다시 돌려 재야 안다 (6교시 Lab 03 예제 1)
|
||||
|
||||
### 일반 설명
|
||||
|
||||
> **생활 속 예 · 같은 손님 열 명으로 다시.** 월요일 아침 카드 단말기가 느려 결제가 줄줄이 실패했습니다. 단말기 설정을 바꾼 뒤 "이제 됐겠지"가 아니라, 그날과 **같은 상황**(단말기가 느림)에서 **같은 손님 열 명**을 다시 받아 봐야 정말 나아졌는지 압니다. 단말기가 멀쩡한 날 재면 고친 덕인지 운인지 모릅니다.
|
||||
|
||||
**다시 돌려 보기(replay).** 운영 기록으로 문제를 찾았다면, 그 상황을 다시 만들어 고치기 전과 후를 **같은 조건 · 같은 입력**으로 잽니다. 조건이 하나라도 다르면 차이가 고친 덕인지 알 수 없습니다.
|
||||
|
||||
| 방법 | 무엇을 같게 | 쓰는 곳 |
|
||||
| --- | --- | --- |
|
||||
| 다시 돌리기 (오늘) | 상황(고장 스위치) · 질문 10개 | 고친 직후 확인, 회귀 테스트 |
|
||||
| 기록 재생 (traffic replay) | 실제로 들어왔던 요청 | 큰 변경 전 (GoReplay 등) |
|
||||
| A/B · 카나리 | 같은 시간대의 사용자를 나눔 | 실제 효과 (74일차) |
|
||||
|
||||
**태그로 나누기.** 고치기 전 · 후 기록을 `tag`(`before` · `after`)로 나눠 남기면, 같은 보고서에 `tag`만 바꿔 물어 비교합니다. 두 주 기록(`seed`)과 섞이지 않게 `source: live`도 함께.
|
||||
|
||||
**"200이 왔다"와 "됐다"는 다르다.** 헬프데스크는 실패해도 "담당자에게 연결합니다"로 200을 줍니다. 그래서 고치기 전 테스트(`replay-before`)는 200만 보고 10/10입니다. 됐는지는 **기록**과 **보고서**로 봅니다 (76일차: 사용자가 본 것과 실제로 일어난 일).
|
||||
|
||||
### 오늘 실습에서
|
||||
|
||||
(Lab 03 예제 1, FAQ 1.2초 느림, 같은 질문 10개)
|
||||
|
||||
| 기록 | 헬프데스크 | 오류 | 갈래 | 한 건 시간 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| `before` | 제공 (timeout 1초, 와이파이 FAQ 없음) | **10** / 10 | 오류 10 | 1.1~2.1초 |
|
||||
| `after` | 고친 뒤 (timeout 3초 · 재시도 + FAQ-007) | **0** / 10 | 자동 답변 10 | **2.3~4.5초** |
|
||||
|
||||
- `cases/lab03.json`: 고치기 전 3/4 → 고친 뒤 4/4. 고치기 전 "답하지 못한 주제 없음"은 고친 뒤 기록이 0건이라 **우연히** ✔였습니다 (1단계 5절의 경계).
|
||||
|
||||
## 2. 고칠 곳과 고칠 사람이 다르다 (6교시 Lab 03 예제 1)
|
||||
|
||||
### 일반 설명
|
||||
|
||||
> **생활 속 예 · 단말기 설정과 들여놓을 물건.** 단말기의 "기다리는 시간" 설정은 매장 직원이 바꾸고, 손님이 계속 찾던 와이파이 공유기는 구매 담당이 들여놓습니다. 둘 중 하나만 하면 문제의 절반이 남습니다. 문제 목록에는 "누가 고치나"가 함께 있어야 합니다.
|
||||
|
||||
**문제마다 주인(owner).** 운영 데이터로 찾은 문제는 대개 여러 팀에 걸칩니다. 워크플로우 설정(개발 · 운영), 콘텐츠(FAQ · 문서 담당), 바깥 서비스(데이터 API · LLM 공급자), 사용량 한도(예산 담당). 문제 목록의 "고칠 곳 · 누가" 칸이 이것을 정합니다 (Lab 02 예제 1의 `OPS.md` 3.1).
|
||||
|
||||
| 문제 (Lab 02) | 고칠 곳 | 누가 | 오늘 |
|
||||
| --- | --- | --- | --- |
|
||||
| FAQ 검색 timeout (16건) | 워크플로우 Search FAQ | 에이전트 (요청문) | timeout 3000 · 재시도 2 |
|
||||
| 와이파이 FAQ 없음 (34건) | 데이터 (FAQ) | 사람 (`faq/add`) | FAQ-007 더하기 |
|
||||
| LLM 429 (5건) | 사용량 한도 · 대체 경로 | 예산 · 운영 (75 · 72일차) | 오늘은 보고서의 "다음 할 일"로 |
|
||||
|
||||
**워크플로우가 콘텐츠를 고치지 않는다.** 워크플로우 안에서 FAQ를 더하지 않습니다 (AGENTS.md 9절). 무엇을 답할지 정하는 것은 사람의 결정이고, 기록(누가 · 언제 더했나)이 남아야 합니다.
|
||||
|
||||
### 오늘 실습에서
|
||||
|
||||
- 두 고침이 다 필요했습니다: timeout만 늘렸다면 와이파이 질문 5개는 FAQ에 없어 `담당자 연결`, FAQ만 더했다면 1초에 끊겨 10개 모두 오류였을 것입니다 (Lab 03 예제 1).
|
||||
|
||||
## 3. SLO: 숫자로 한 약속 (6교시 Lab 03 예제 2)
|
||||
|
||||
### 일반 설명
|
||||
|
||||
> **생활 속 예 · "30분 안에 배달" 약속.** 피자 가게가 "빠르게 배달합니다"라고만 하면 늦어도 할 말이 없습니다. "30분 안에, 아니면 할인"이라고 **숫자로 약속**하면 매일 지켰는지가 분명해집니다. 그리고 "한 달에 몇 번까지는 늦어도 된다"는 여유도 정할 수 있습니다.
|
||||
|
||||
**SLI · SLO · SLA.** 구글의 SRE(Site Reliability Engineering)가 널리 퍼뜨린 말입니다.
|
||||
|
||||
| 말 | 뜻 | 오늘 |
|
||||
| --- | --- | --- |
|
||||
| SLI (지표) | 사용자가 겪는 품질을 재는 숫자 | `error_rate` · `p95_ms` · `unanswered_rate` |
|
||||
| SLO (목표) | 지표마다 지킬 값 | 0.01 · 3000ms · 0.02 |
|
||||
| SLA (계약) | 못 지키면 보상하는 바깥 약속 | (오늘은 없음) |
|
||||
| 에러 예산 (error budget) | 목표까지 남은 여유 (1 − 0.99 = 1%) | 예산을 다 쓰면 새 기능보다 안정을 먼저 |
|
||||
|
||||
**셋을 다시 풀어 보면.** 세 말 모두 "서비스 수준(Service Level)"으로 시작하고, 끝 글자만 다릅니다.
|
||||
|
||||
| 약자 | 풀이 | 우리말 | 묻는 것 | 피자 가게로 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| **SLI** | Service Level **Indicator** | 서비스 수준 **지표** | 무엇을 재나? | 주문부터 도착까지 걸린 시간 (분) |
|
||||
| **SLO** | Service Level **Objective** | 서비스 수준 **목표** | 얼마면 잘한 것인가? | "주문의 99%는 30분 안에" |
|
||||
| **SLA** | Service Level **Agreement** | 서비스 수준 **협약(계약)** | 못 지키면 어떻게 하나? | "30분이 넘으면 다음 주문 할인" |
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
I["SLI · 지표<br/>재는 숫자<br/>(오류율 0.0588)"] --> O{"SLO · 목표<br/>지킬 값<br/>(≤ 0.01)"}
|
||||
O -->|지킴| OK["그대로"]
|
||||
O -->|어김| B["위반 · 알림<br/>어긴 지표부터 고침"]
|
||||
O -.->|"더 느슨한 선으로<br/>바깥에 약속"| A["SLA · 계약<br/>어기면 보상"]
|
||||
```
|
||||
|
||||
- **SLI는 숫자, SLO는 선, SLA는 약속서.** SLI가 없으면 SLO를 확인할 수 없고, SLO 없이 SLA를 맺으면 지킬 수 있는지 모른 채 약속하는 셈입니다. 순서는 늘 SLI → SLO → (필요하면) SLA입니다.
|
||||
- **누구와의 약속인가.** SLO는 **팀 안**의 목표라, 어기면 고칠 일이 생깁니다. SLA는 고객 · 다른 회사 같은 **바깥**과의 계약이라, 어기면 돈 · 할인 같은 보상이 따릅니다. 그래서 SLA는 SLO보다 **느슨하게** 잡습니다 (예: 팀 목표 99.9%, 고객 계약 99.5%). SLO를 먼저 어기면 SLA를 어기기 전에 고칠 시간이 생깁니다.
|
||||
- **SLI는 사용자가 겪는 것으로.** 서버의 CPU 사용률보다 "답을 받았나(오류율) · 얼마나 기다렸나(p95) · 쓸모 있는 답이었나(답 못 함)"가 좋은 SLI입니다. 오늘의 세 지표가 모두 그렇습니다. 평균 대신 p95를 쓰는 까닭은 1단계 3절과 같습니다.
|
||||
- **에러 예산은 SLO의 뒷면.** "오류율 1% 이하"는 "100건 중 1건까지는 실패해도 된다"와 같은 말입니다. 그 1건이 에러 예산이고, 다 쓰면 새 기능보다 안정을 먼저 합니다.
|
||||
- 사내 헬프데스크인 오늘 실습에는 SLA가 없습니다 (돈을 받는 바깥 고객이 없음). 80~82일차 단위 프로젝트 · 최종 프로젝트에서 "고객에게 약속한다면 얼마로?"를 정해 볼 수 있습니다.
|
||||
|
||||
**SLO가 바꾸는 것.** 지표만 있으면 "오류율 5.88%, 나쁜가?"를 매번 토론합니다. SLO가 있으면 "1% 약속을 어겼다, 어긴 지표부터 고친다"로 정해집니다. 기준은 사용자 · 팀장 · 비용(75일차)이 함께 정하고, 바뀔 수 있게 본문으로 덮어쓸 수 있게 둡니다.
|
||||
|
||||
### 오늘 실습에서
|
||||
|
||||
(Lab 03 예제 2, `cases/lab03-slo.json` 0/4 → 4/4)
|
||||
|
||||
| 기간 · 기록 | 오류율 | p95 | 답 못 함 | `breaches` |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 첫 주 | 0 | 2525 | 0.055 | `unanswered_rate` |
|
||||
| 첫 주 · 답 못 함 기준 0.06 | 0 | 2525 | 0.055 | 없음 (`ok: true`) |
|
||||
| 둘째 주 | 0.0588 | 2598 | 0.0476 | `error_rate`, `unanswered_rate` |
|
||||
| 고친 뒤 (`after`) | 0 | **3560** | 0 | **`p95_ms`** |
|
||||
|
||||
- 둘째 주의 위반 둘은 Lab 02의 문제 둘(timeout · 와이파이)과 맞습니다. 고친 뒤 두 약속은 지켰지만 **새 약속(p95)을 어겼습니다** (4절).
|
||||
|
||||
## 4. 고친 것의 대가 (6교시 Lab 03 예제 3)
|
||||
|
||||
### 일반 설명
|
||||
|
||||
> **생활 속 예 · 단말기 대기 시간을 늘린 대가.** 단말기가 느린 날 "기다리는 시간"을 늘렸더니 결제 실패는 사라졌지만, 손님마다 계산이 1초씩 길어져 줄이 늘었습니다. 단말기가 정상인 날에는 기다릴 일이 없어 빠릅니다. 고친 것이 문제를 **없앤** 것인지, 다른 곳으로 **옮긴** 것인지 구분해야 합니다.
|
||||
|
||||
**모든 고침에는 대가(trade-off)가 있습니다.** timeout을 늘리면 실패는 줄지만 느린 날 사용자는 더 기다립니다 (72일차). 재시도를 늘리면 성공은 늘지만 부하와 시간이 늘고 (76일차), 캐시는 빠르지만 낡은 답을 줄 수 있습니다 (75일차). 그래서 고친 뒤에는 고친 지표만이 아니라 **다른 지표도** 다시 봅니다.
|
||||
|
||||
| 조치 | 무엇을 하나 | 이름 |
|
||||
| --- | --- | --- |
|
||||
| timeout을 늘림 (오늘) | 느린 바깥을 **견딤** | 완화 (mitigation) |
|
||||
| FAQ 검색을 빠르게 | 느려지는 **원인**을 없앰 | 근본 해결 (fix) |
|
||||
|
||||
장애 대응에서는 먼저 완화로 사용자 피해를 줄이고, 원인 해결은 담당 팀의 일로 넘겨 추적합니다 (76일차 런북). 보고서에는 둘을 나눠 적습니다.
|
||||
|
||||
**단계 시간으로 증명.** "느려진 것은 FAQ를 기다렸기 때문"이라는 말은 짐작입니다. 단계 시간(1단계 7절)으로 FAQ 단계만 늘었고 답 단계는 그대로인 것을 보이면 증명이 됩니다.
|
||||
|
||||
### 오늘 실습에서
|
||||
|
||||
(Lab 03 예제 3, 같은 질문 10개, `-v` 응답에서 읽은 값)
|
||||
|
||||
| 기록 | FAQ | 오류 | FAQ 단계 p50 | 답 단계 p50 | 전체 p95 | SLO |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| `before` | 느림 | 10 | 1043ms | — | 1098ms | `error_rate` 어김 |
|
||||
| `after` | 느림 | 0 | **1238ms** | 1103ms | **3560ms** | `p95_ms` 어김 |
|
||||
| `normal` | 평소 | 0 | **17ms** | 997ms | 2147ms | 지킴 |
|
||||
|
||||
- 늘어난 시간은 모두 FAQ 단계입니다 (답 단계 1103 · 997ms로 비슷). FAQ가 평소대로면 같은 헬프데스크가 SLO를 지킵니다. 진짜 고칠 곳은 FAQ 검색이 느려지는 원인입니다.
|
||||
|
||||
## 5. 주간 보고: 만든 것을 조립한다 (6교시 Lab 03 과제 1)
|
||||
|
||||
### 일반 설명
|
||||
|
||||
> **생활 속 예 · 주간 매출 보고서.** 가게 점장은 매주 "지난주 · 이번 주 매출표, 문제 세 가지, 세 줄 요약, 다음 주 할 일"을 본사에 보냅니다. 매주 같은 칸에 같은 방식으로 채우니 본사는 표만 보고도 비교합니다. "할 일"은 정해진 규칙(재고가 없으면 주문, 단말기 고장이면 수리 요청)대로 씁니다.
|
||||
|
||||
**운영 리뷰(operations review).** 많은 회사가 매주 같은 모양의 지표 보고로 회의를 합니다 (아마존의 WBR, Weekly Business Review가 잘 알려져 있습니다). 핵심은 **같은 모양 · 같은 정의 · 지난 기간과 나란히**입니다. 매주 다른 모양이면 비교가 안 됩니다.
|
||||
|
||||
**조립(composition).** 주간 보고는 새로 계산하지 않고 테스트로 확인한 부품(이번 주 보고서 · 지난주 보고서 · 요약)을 부릅니다. 정의는 늘 한 곳이고, 보고서를 고치면 주간 보고도 함께 바뀝니다.
|
||||
|
||||
| 절 | 누가 쓰나 | 까닭 |
|
||||
| --- | --- | --- |
|
||||
| 숫자 표 | Code | 보고서 그대로, 사람이 읽게 `5.88%` |
|
||||
| 문제 | Code | 실패 · 답 못 한 주제 · 이상 시간대 |
|
||||
| 요약 | LLM (+ 숫자 확인) | 사람의 말로, 확인 결과를 함께 |
|
||||
| 다음 할 일 | 규칙 | "답 못 함 1위 주제 → FAQ 추가"처럼 정해진 연결은 늘 같게 |
|
||||
|
||||
### 오늘 실습에서
|
||||
|
||||
(Lab 03 과제 1, `cases/lab03-challenge.json` 7/7, 2~4초)
|
||||
|
||||
| 지표 | 지난주 | 이번 주 |
|
||||
| --- | --- | --- |
|
||||
| 요청 | 309 | 357 |
|
||||
| 오류율 | 0% | 5.88% |
|
||||
| p95 | 2525ms | 2598ms |
|
||||
| 답 못 함 | 5.5% | 4.76% |
|
||||
| SLO | 못 지킴 unanswered_rate | 못 지킴 error_rate, unanswered_rate |
|
||||
|
||||
- 문제 다섯 줄(실패 16 · 5, 와이파이 17, 이상 시간대 둘), 숫자 확인을 통과한 요약, 규칙이 쓴 할 일 셋(와이파이 FAQ · timeout · 사용량 한도). 할 일 셋이 바로 Lab 03 예제 1에서 한 일과 남은 일입니다.
|
||||
|
||||
## 6. SLO를 어기면 알린다, 같은 알림은 한 번 (6교시 Lab 03 과제 2)
|
||||
|
||||
### 일반 설명
|
||||
|
||||
> **생활 속 예 · 냉장고 온도 경보.** 가게 냉장고가 기준 온도를 넘으면 경보가 울려야 합니다. 하지만 1분마다 계속 울리면 직원은 곧 꺼 버립니다. 그래서 "한 번 울리고, 10분 안에는 다시 울리지 않되, 기록에는 남긴다"로 정합니다.
|
||||
|
||||
**지표 → 판정 → 알림.** 보고서는 "얼마나", SLO는 "지켰나", 알림은 "누가 지금 알아야 하나"입니다. 셋을 이으면 매주 보고서를 열지 않아도 약속이 깨진 순간 압니다. 모니터링 도구(Prometheus Alertmanager · Grafana · Datadog)의 알림 규칙이 같은 모양입니다: 조건(위반) → 같은 알림 묶기 · 반복 간격(repeat interval) → 보냄.
|
||||
|
||||
**알림 피로와 억제.** 같은 원인으로 알림이 계속 오면 사람은 알림을 읽지 않게 됩니다 (76일차). 같은 이유의 알림이 정해진 시간 안에 있으면 보내지 않고(`suppressed`), 보내지 않았다는 사실은 결과에 남깁니다. 더 나아가면 SRE 책의 **소진율 알림**(burn-rate alert: 에러 예산을 빨리 쓰고 있을 때만 알림)이 있습니다.
|
||||
|
||||
**메시지에 숫자를.** "SLO 위반"만으로는 할 일을 모릅니다. 어느 지표가 · 얼마로 · 기준이 얼마인데 넘었는지를 한 줄에 씁니다.
|
||||
|
||||
### 오늘 실습에서
|
||||
|
||||
(Lab 03 과제 2, `cases/lab03-challenge2.json` 6/6)
|
||||
|
||||
| 순서 | 물은 것 | 결과 |
|
||||
| --- | --- | --- |
|
||||
| 1 | 둘째 주 | `sent` — `[high] slo · SLO breach: error_rate 0.0588 > 0.01, unanswered_rate 0.0476 > 0.02` |
|
||||
| 2 | 둘째 주 다시 (10분 안) | `suppressed`, 알림은 1개 그대로 |
|
||||
| 3 | 첫 주 · 답 못 함 기준 0.06 | `none` |
|
||||
|
||||
- 1.0초 · 0.3초로 빠릅니다 (보고서 0.1초 + 알림 읽고 쓰기). 정기 실행(Schedule 트리거)으로 10분마다 돌려도 부담이 없습니다 — 79일차 Ops Assistant로 이어집니다.
|
||||
|
||||
## 7. 개선의 고리: 재기 → 찾기 → 고치기 → 다시 재기
|
||||
|
||||
### 일반 설명
|
||||
|
||||
> **생활 속 예 · 다이어트 기록.** 체중계에 매일 오르고(재기), 늘어난 날의 식단을 보고(찾기), 야식을 줄이고(고치기), 다음 주에 같은 체중계 · 같은 시각에 다시 잽니다(다시 재기). 다른 체중계로 재거나 재지 않으면 줄인 효과를 모릅니다.
|
||||
|
||||
**PDCA · 데이터 기반 개선.** 품질 관리의 오래된 고리 Plan → Do → Check → Act, SRE의 "측정할 수 없으면 개선할 수 없다", 제품 팀의 "만들기 → 재기 → 배우기"(Build-Measure-Learn)는 모두 같은 모양입니다. 오늘 하루가 이 고리 한 바퀴였습니다.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
M["재기<br/>정의된 지표 (1단계)"] --> F["찾기<br/>묶음 · 이상 · 비율 (2단계)"] --> X["고치기<br/>워크플로우 · 콘텐츠 (3단계)"] --> R["다시 재기<br/>같은 조건 · SLO · 대가 (3단계)"] --> M
|
||||
R --> P["보고 · 알림<br/>주간 보고 · SLO 알림"]
|
||||
```
|
||||
|
||||
**고리를 지키는 규칙.**
|
||||
|
||||
| 규칙 | 오늘 |
|
||||
| --- | --- |
|
||||
| 정의는 한 곳 | `my-log-report` · AGENTS.md 3절, 나머지는 다시 부름 |
|
||||
| 같은 조건으로 다시 | 고장 스위치 · 같은 질문 10개 · `tag` |
|
||||
| 고친 것 말고도 다시 본다 | p95가 새로 어김 |
|
||||
| 숫자에 건수 · 기준 기간을 함께 | 1.2.0 8건, 문턱의 기간 |
|
||||
| 사람에게 가는 것은 줄이되 기록은 남긴다 | `suppressed` |
|
||||
|
||||
## 8. 가게 장부로 본 오늘 하루
|
||||
|
||||
| 오늘 만든 것 | 가게에서는 | 이 문서 |
|
||||
| --- | --- | --- |
|
||||
| 실행 기록 666줄 | 계산대 옆 영수증 더미 | 1단계 1절 |
|
||||
| 지표 정의 (AGENTS.md 3절) | 벽에 붙인 장부 쓰는 법 | 1단계 2절 |
|
||||
| p50 · p95 | "열 번 중 아홉 번은 8분 안" 버스 시간 | 1단계 3절 |
|
||||
| 경계 테스트 | 줄자의 끝 눈금 | 1단계 5절 |
|
||||
| 날짜별 · 릴리스별 · 단계별 | 가계부 날짜별 칸 · 택배 구간별 시간 | 1단계 6 · 7절 |
|
||||
| 실패 묶음 | 반품 사유표 | 2단계 1절 |
|
||||
| 답 못 한 주제 | "찾는 물건 없음" 메모 | 2단계 2절 |
|
||||
| 이상 시간대 · 비교 기준 | 시간대별 매출표의 빈칸 · "평소"의 기준 | 2단계 3 · 4절 |
|
||||
| 다시 묻는 주제 | 교환하러 다시 온 손님 | 2단계 5절 |
|
||||
| LLM 요약 + 숫자 확인 | 점장의 세 줄 보고와 계산기 | 2단계 6절 |
|
||||
| 고치기 전 · 후 다시 돌리기 | 같은 손님 열 명으로 다시 | 3단계 1절 |
|
||||
| timeout + FAQ 더하기 | 단말기 설정 + 들여놓을 물건 | 3단계 2절 |
|
||||
| SLO | "30분 안에 배달" 약속 | 3단계 3절 |
|
||||
| 고친 것의 대가 | 단말기 대기 시간을 늘려 길어진 줄 | 3단계 4절 |
|
||||
| 주간 보고 | 주간 매출 보고서 | 3단계 5절 |
|
||||
| SLO 알림 | 냉장고 온도 경보 | 3단계 6절 |
|
||||
|
||||
## 9. 요청문(프롬프트)으로 에이전트에게 맡기기
|
||||
|
||||
고치기 · 판정 · 보고 요청문은 **바꿀 곳만 · 기준 · 조립할 부품**을 적습니다.
|
||||
|
||||
| 넣을 것 | 예 |
|
||||
| --- | --- |
|
||||
| 바꿀 곳만 | "Search FAQ 노드만, 다른 노드와 로그 모양은 그대로" |
|
||||
| 설정의 자리 | "`retryOnFail` · `maxTries` · `waitBetweenTries`는 `parameters` 밖, 노드 바로 아래" |
|
||||
| 기준과 덮어쓰기 | "기본 limits, 본문 `slo`가 있으면 그 값으로", "지표가 기준보다 크면 위반" |
|
||||
| 부품을 부르기 | "`my-log-report`를 두 번(이번 주 · 지난주), `my-log-summary`를 한 번 부른다" |
|
||||
| 누가 무엇을 | "할 일은 LLM이 아니라 규칙으로" |
|
||||
| 알림의 양 | "10분(600초) 안 같은 `reason`이 있으면 `suppressed`" |
|
||||
| 기대 결과 | "`cases/replay-after.json` · `lab03.json`, 앞의 테스트도 그대로" |
|
||||
|
||||
## 10. 자주 하는 실수
|
||||
|
||||
| 실수 | 결과 | 바로잡기 |
|
||||
| --- | --- | --- |
|
||||
| 고친 뒤를 다른 조건에서 잼 | 고친 덕인지 운인지 모름 | 같은 고장 스위치 · 같은 질문 · `tag` |
|
||||
| "200이 왔다"를 "됐다"로 | 실패 10건을 놓침 | 기록 · 보고서로 확인 |
|
||||
| 워크플로우로 콘텐츠를 고치려 함 | FAQ에 없는 답은 못 함 | 고칠 곳 · 사람을 나눔 |
|
||||
| 고친 지표만 다시 봄 | p95 위반을 놓침 | SLO 전체를 다시 |
|
||||
| timeout을 늘린 것을 "해결"로 보고 | 원인이 남음 | 완화와 근본 해결을 나눠 적음 |
|
||||
| 주간 보고에서 지표를 다시 계산 | 정의가 두 벌 | 부품을 부름 |
|
||||
| 할 일까지 LLM에게 | 매주 다른 말 | 정해진 연결은 규칙 |
|
||||
| 알림을 매번 보냄 | 알림 피로 | 같은 이유는 10분에 한 번, `suppressed`를 기록 |
|
||||
|
||||
## 확인 질문
|
||||
|
||||
<details><summary>1. 고치기 전 테스트(`replay-before`)가 10/10인데, 왜 "10건 모두 실패"라고 하나요?</summary>
|
||||
|
||||
헬프데스크는 실패해도 "담당자에게 연결합니다"로 200을 줍니다. 테스트는 200만 확인했고, 실제로 무슨 일이 있었는지는 기록에 남았습니다: 10건 모두 `error` · `Search FAQ` · 약 1030ms. 사용자에게 보인 것(200)과 실제(오류)를 나눠 보는 까닭입니다. 고친 뒤 테스트(`replay-after`)는 `route: 자동 답변`까지 확인합니다.
|
||||
</details>
|
||||
|
||||
<details><summary>2. timeout을 3초로 늘렸더니 오류는 0이 되었는데 SLO를 어겼습니다. 고친 것이 잘못인가요?</summary>
|
||||
|
||||
잘못이 아니라 대가입니다. 실패 대신 늦은 답을 주는 **완화**였고, 그 대가로 느린 날 p95가 3560ms가 되었습니다. 단계 시간으로 보면 늘어난 시간은 모두 FAQ 단계(1238ms)이고, FAQ가 평소대로면 같은 헬프데스크가 SLO를 지킵니다(p95 2147ms). 보고서에 "완화함 · 원인(FAQ 검색이 느려짐)은 담당 팀에"를 나눠 적습니다.
|
||||
</details>
|
||||
|
||||
<details><summary>3. 첫 주의 답 못 함(5.5%)이 SLO를 어겼는데, 기준을 6%로 바꾸면 지킨 것이 됩니다. 기준을 바꾸면 되지 않나요?</summary>
|
||||
|
||||
숫자 하나를 바꾸는 일이지만 약속을 바꾸는 일입니다. 누가(사용자 · 팀장) · 왜(사람 손이 남는다 · 비용) 바꾸는지가 기록돼야 합니다. 오늘 보고서는 본문 `slo`로 기준을 바꿔 "새 기준이면?"을 물을 수 있게 했지만, 문제(와이파이 FAQ 없음)를 고치지 않고 기준만 올리면 사용자의 실패는 그대로입니다.
|
||||
</details>
|
||||
|
||||
<details><summary>4. 주간 보고의 "다음 할 일"을 LLM에게 맡기지 않은 까닭은?</summary>
|
||||
|
||||
"답 못 함 1위 주제 → FAQ에 추가", "Search FAQ 실패 → timeout 점검"처럼 문제에서 할 일로 가는 연결이 정해져 있으면 규칙이 매주 같게 씁니다. LLM은 같은 문제에도 매주 다른 말을 쓸 수 있고, 없는 할 일을 지어낼 수 있습니다. LLM은 요약처럼 사람의 말이 필요한 곳에만, 숫자 확인과 함께 씁니다.
|
||||
</details>
|
||||
|
||||
<details><summary>5. SLO 알림이 같은 기간을 10분 안에 다시 확인했을 때 `suppressed`를 돌려줍니다. 그냥 아무것도 안 하면 안 되나요?</summary>
|
||||
|
||||
확인했다는 사실과 왜 보내지 않았는지가 남아야 합니다. 나중에 "그때 알림이 왜 안 왔나"를 물었을 때 `suppressed`(10분 안 같은 알림이 있었음)가 답이 됩니다. 사람에게 가는 알림은 줄이되 기록은 줄이지 않습니다 (76일차 알림 폭주 막기와 같음).
|
||||
</details>
|
||||
@@ -0,0 +1,210 @@
|
||||
# 4단계 · 정리: 오늘 한 일의 의미 · 효과 · 실전 응용
|
||||
|
||||
- 교시: 8교시 17:10~17:45 (35분, 바이브 코딩 발표 10분 뒤) · 자료: 이 문서 + [개요](00-DAY77-OVERVIEW.md) 30장
|
||||
- 이 시간이 끝나면: 오늘 1~3단계에서 한 일이 **무엇을 위한 것이었는지**, 숫자로 **무엇이 달라졌고 무엇을 치렀는지**, 회사에서는 같은 생각을 **어떤 이름과 도구로** 쓰는지 말할 수 있고, 최종 프로젝트에 무엇을 가져갈지 정할 수 있다.
|
||||
- 숫자: 오늘 교안의 실측(강사 노트북, 10/31 정답 워크플로우 1회)입니다. "예시"라고 적은 계산은 가정을 둔 어림입니다.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A["1. 오늘 한 장"] --> B["2. 왜 숫자로<br/>운영하나"] --> C["3. 효과와 값을 숫자로"] --> D["4. 회사에서 부르는 이름"]
|
||||
D --> E["5. 산업별 응용"] --> F["6. 운영 지표 정의서"] --> G["7. 하지 말아야 할 때"] --> H["8. 직무 · 면접"] --> I["9. 최종 프로젝트로"]
|
||||
```
|
||||
|
||||
## 0. 이 시간 (35분)
|
||||
|
||||
| 시간 | 절 | 하는 일 |
|
||||
| --- | --- | --- |
|
||||
| 17:10~17:15 | 1 · 2 | 오늘 한 장, 왜 숫자로 운영하나 |
|
||||
| 17:15~17:20 | 3 | 오늘 숫자로 본 효과와 값, 한 달로 보면 (예시) |
|
||||
| 17:20~17:28 | 4 · 5 | 같은 생각의 업계 이름 · 도구, 산업별 응용 예 |
|
||||
| 17:28~17:33 | 6 · 7 | 운영 지표 정의서, 하지 말아야 할 때 |
|
||||
| 17:33~17:40 | 8 · 9 | 직무와 면접 질문, 최종 프로젝트 체크리스트 |
|
||||
| 17:40~17:45 | 10 · 토론 | 다음 일차와의 연결, 질문 둘 |
|
||||
|
||||
## 1. 오늘 한 장
|
||||
|
||||
| 단계 | 한 일 | 오늘 숫자 |
|
||||
| --- | --- | --- |
|
||||
| 1단계 · 실행 기록 읽기와 지표 | 기준 보고서와 비교, 정의대로 세는 보고서, 경계, 날짜별 · 릴리스별, 단계 · 비용 | 기준 **602건 · 0/5** → 정의대로 **666건 · 5/5**, 경계 6/6 대 2/6, 1.2.0은 8건이라 판단 보류, 월요일 FAQ 단계 p95 **1000ms** |
|
||||
| 2단계 · 문제를 숫자로 찾기 | 실패 묶음 · 답 못 한 주제, 이상 시간대, 비교 기준, 다시 묻는 주제, LLM 요약 + 숫자 확인 | 오류 21 = **원인 2 = 사건 2** (09시 16/16 · 15시 5/7), 와이파이 **34** (오류율엔 0), 문턱 0.0945~0.6858, 프린터 9.88%, 요약 `numbers_ok: true` |
|
||||
| 3단계 · 고치고 다시 재기 | 고치기 전 · 후 다시 돌리기, SLO, 고친 것의 대가, 주간 보고, SLO 알림 | 오류 **10 → 0**, 대신 p95 **3560 > 3000** (FAQ 단계 1238ms · 평소 17ms), 주간 보고 7/7, 알림 `sent` → `suppressed` |
|
||||
|
||||
## 2. 왜 숫자로 운영하나
|
||||
|
||||
> **생활 속 예 · 단골 가게 사장님의 장부.** 장사가 잘되는 가게 사장님은 "요즘 손님이 줄었어"라고 느끼면 장부부터 펼칩니다. 언제부터 · 어느 시간대에 · 어떤 손님이 줄었는지 보고, 그 시간대의 문제(단말기 고장, 없는 물건)를 고치고, 다음 주 장부로 다시 확인합니다. 느낌으로 고치면 엉뚱한 곳을 고치고, 고친 뒤에도 나아졌는지 모릅니다. 3단계 8절의 "가게 장부로 본 오늘 하루" 표도 함께 봅니다.
|
||||
|
||||
| 감으로 운영하면 | 숫자로 운영하면 |
|
||||
| --- | --- |
|
||||
| "요즘 오류가 많대요" — 몇 건? 언제? | 오류 21건, 두 번의 사건 (월 09시 · 목 15시) |
|
||||
| 회의가 "어느 숫자가 맞나"로 끝남 | 정의서 한 곳, 모든 보고가 다시 부름 |
|
||||
| 가장 시끄러운 문제부터 고침 | 가장 큰 묶음 · 사용자 피해가 큰 것부터 (와이파이 34) |
|
||||
| 고친 뒤 "괜찮아진 것 같다" | 같은 조건으로 다시: 오류 10 → 0 |
|
||||
| 고친 것만 봄 | 새로 나빠진 것도: p95 3560 |
|
||||
| 매주 다른 보고 | 같은 모양의 주간 보고 · SLO 알림 |
|
||||
|
||||
**오늘 하루가 개선의 고리 한 바퀴였습니다**: 재기(정의된 지표) → 찾기(묶음 · 이상 · 비율) → 고치기(워크플로우 · 콘텐츠) → 다시 재기(같은 조건 · SLO · 대가).
|
||||
|
||||
## 3. 효과와 값을 숫자로
|
||||
|
||||
### 3.1 오늘 실측 전 · 후
|
||||
|
||||
| 무엇 | 전 | 후 | 바꾼 것 |
|
||||
| --- | --- | --- | --- |
|
||||
| 두 주 실행 수 | 602 (끝날 빠짐) | 666 | 정의 · 거르기를 데이터 API에 |
|
||||
| 하루를 물으면 | 0 · `null` | 70 · 오류 16 | 끝날 포함 · 0건이면 0 |
|
||||
| `source: live`를 물으면 | 666 (무시) | 0 | 본문을 그대로 넘김 |
|
||||
| 오류 21건 | 21개의 일 | 원인 2 · 사건 2 | 묶기 · 이상 시간대 |
|
||||
| 답 못 한 질문 | 오류율에 안 보임 | 와이파이 34 → FAQ 더하기 | 오류가 아닌 실패를 따로 |
|
||||
| 느린 FAQ에서 같은 10개 | 오류 10 | 오류 0 | timeout 3초 · 재시도 + FAQ |
|
||||
| 팀장 보고 | 손으로 | 주간 보고 2~4초 · 숫자 확인 통과 | 부품을 조립 |
|
||||
| SLO 위반 | 월요일 회의 때 앎 | 바로 high 알림, 10분 안엔 한 번 | 판정 → 알림 |
|
||||
|
||||
**치른 값**:
|
||||
|
||||
- **느려짐**: 오류를 없앤 대가로 느린 FAQ에서 p95가 3560ms(SLO 3000 위반). timeout은 완화이고, FAQ 검색이 느려지는 원인은 남아 있습니다.
|
||||
- **정의를 지키는 일**: 지표를 바꾸면 모든 보고가 바뀝니다. 정의서를 고칠 때는 누가 · 왜를 남기고 테스트(경계 포함)를 함께 고쳐야 합니다.
|
||||
- **LLM 비용 · 확인**: 요약 한 번에 1.7~3.4초와 LLM 한 번. 숫자 확인을 통과하지 못하면 그 요약은 쓰지 않습니다.
|
||||
- **기록의 양**: 실행마다 한 줄, 단계 · 비용까지 남기면 저장 공간과 개인정보(질문 글) 관리가 필요합니다.
|
||||
|
||||
### 3.2 한 달로 보면 (예시)
|
||||
|
||||
가정: 하루 실행 70건(오늘 기록과 비슷), 한 달 평일 20일 = 1,400건, 와이파이 같은 "FAQ에 없는 주제"가 이관의 대부분, 이관 한 건에 담당자 5분.
|
||||
|
||||
| | 오늘 아침 (두 주 기록의 비율) | FAQ를 더한 뒤 (예시) |
|
||||
| --- | --- | --- |
|
||||
| 이관율 | 5.11% → 한 달 약 72건 | 와이파이가 빠지면 크게 줄어듦 |
|
||||
| 담당자 시간 | 약 72 × 5분 = 6시간 | 줄어든 만큼 다른 일에 |
|
||||
| LLM 비용 | 실행당 0.000118달러 → 한 달 약 0.17달러 | 답한 실행이 늘면 조금 늘어남 |
|
||||
|
||||
- 숫자는 가정입니다. 그래도 **사람의 시간과 LLM 비용을 같은 표에서 말할 수 있다**는 것이 오늘 만든 지표의 효과입니다. FAQ 하나를 더하는 결정이 비용보다 사람 시간을 훨씬 많이 아낀다는 것이 보입니다.
|
||||
|
||||
## 4. 회사에서는 같은 생각을 이렇게 부른다
|
||||
|
||||
| 오늘 한 것 | 업계 이름 | 쓰는 도구 · 표준 (예) |
|
||||
| --- | --- | --- |
|
||||
| 실행 기록 | 구조화 로그, 관측 가능성(observability) | Elasticsearch · Loki · CloudWatch Logs, OpenTelemetry |
|
||||
| 지표 정의서 · 다시 부르기 | 메트릭 정의, 시맨틱 레이어, single source of truth | dbt metrics · Looker LookML · 사내 지표 사전 |
|
||||
| p50 · p95 | 백분위 지연, tail latency | Prometheus histogram · Grafana · Datadog APM |
|
||||
| 경계 테스트 | boundary value testing | 단위 테스트, 데이터 테스트(Great Expectations, 78일차) |
|
||||
| 단계 시간 | 분산 추적, span | Jaeger · Zipkin · Langfuse(LLM) |
|
||||
| 비용 · 실행당 비용 | FinOps, unit economics | 클라우드 비용 대시보드, LLM 사용량 대시보드 |
|
||||
| 실패 묶음 | error grouping · fingerprint | Sentry · Datadog Error Tracking |
|
||||
| 이관율 · 재문의율 | escalation · deflection rate, FCR | 콜센터 · 챗봇 분석 (Zendesk · Intercom 리포트) |
|
||||
| 이상 시간대 | anomaly detection, baseline · threshold | CloudWatch · Datadog 이상 탐지 |
|
||||
| LLM 요약 + 숫자 확인 | grounding check, LLM 평가 | 사내 리포트 봇, LLM 평가 도구 |
|
||||
| 다시 돌리기 · 태그 | replay test, before/after | 회귀 테스트, 트래픽 재생 |
|
||||
| SLO · 위반 · 에러 예산 | SRE의 SLI · SLO · error budget | Google SRE, Nobl9 · Datadog SLO |
|
||||
| 주간 보고 | 운영 리뷰 (WBR) | 주간 지표 회의, 자동 리포트 |
|
||||
| SLO 알림 · 억제 | burn-rate alert, 반복 간격 · 묶기 | Prometheus Alertmanager · PagerDuty |
|
||||
| `tlog` | 로그 분석 CLI | `jq` · `lnav` · 사내 운영 도구 |
|
||||
|
||||
- 오늘은 n8n 워크플로우 · 작은 데이터 API · `flow.py`로 직접 만들었습니다. 회사에서는 로그 저장소 · 대시보드 · 알림 도구가 대신하는 경우가 많습니다. 그래도 **무엇을 어떻게 셀지(정의), 무엇을 이상으로 볼지(기준), 어떤 약속을 지킬지(SLO), 누가 고칠지(주인)**는 오늘처럼 사람이 정합니다.
|
||||
|
||||
## 5. 산업별 응용 (예)
|
||||
|
||||
아래는 오늘 한 일을 다른 업무에 옮긴 예입니다 (실제 특정 회사의 사례가 아니라 흔한 모양).
|
||||
|
||||
| 업무 | 오늘의 무엇을 | 이렇게 |
|
||||
| --- | --- | --- |
|
||||
| 쇼핑몰 · 결제 | 이상 시간대 · SLO 알림 | 시간대별 결제 실패율이 평소의 3배면 알림, p95 결제 시간 SLO |
|
||||
| 고객센터 챗봇 (오늘) | 이관율 · 답 못 한 주제 · 재문의율 | 매주 "FAQ에 없는 주제 상위 5"를 콘텐츠 팀에, 재문의율 높은 답을 고침 |
|
||||
| 사내 업무 자동화 (n8n · RPA) | 실패 묶음 · 주간 보고 | 모든 워크플로우의 실행 기록을 모아 "가장 자주 실패하는 노드" 주간 보고 |
|
||||
| 데이터 파이프라인 · ETL | 경계 · 정의서 · 단계 시간 | 하루 · 0건 · 늦게 온 데이터 테스트, 단계마다 걸린 시간으로 병목 찾기 |
|
||||
| LLM 애플리케이션 | 단계 · 비용 · 숫자 확인 | 요청당 토큰 · 비용, 검색 vs 생성 단계 시간, 답의 숫자 근거 확인 |
|
||||
| 물류 · 배송 | 구간별 시간 · SLO | 구간마다 p95, "당일 배송 95%" 약속과 위반 알림 |
|
||||
|
||||
**토론 거리**: 내 회사(또는 가고 싶은 회사)의 서비스 하나를 골라, "SLO 세 개를 정한다면 무엇을, 얼마로?"를 정해 봅니다.
|
||||
|
||||
## 6. 운영 지표 정의서 (최종 프로젝트용 틀)
|
||||
|
||||
오늘의 AGENTS.md 3절이 지표 정의서였습니다. 최종 프로젝트에서도 이 틀로 한 장을 씁니다.
|
||||
|
||||
| 지표 | 정의 (분자 / 분모 · 거르기) | 표현 · 0건 | 기준 (SLO) | 어디서 세나 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 실행 수 | 기간 안 실행 (`from ≤ 날짜 ≤ to`) | 정수 | — | 보고서 웹훅 |
|
||||
| 오류율 | `status = error` / 실행 | 소수 4자리, 0 | 0.01 | 〃 |
|
||||
| p95 | `duration_ms` 오름차순 `ceil(0.95n)`번째 (오류 포함) | ms, 0 | 3000 | 〃 |
|
||||
| 이관율 | `담당자 연결` / 실행 | 소수 4자리, 0 | 0.02 | 〃 |
|
||||
| 재문의율 | `repeat` / `자동 답변` (주제 · 버전별) | 소수 4자리 + 건수 | — | 〃 |
|
||||
| 실행당 비용 | `cost_usd` 합 / 실행 | 소수 6자리, 0 | 예산 | 〃 |
|
||||
|
||||
- 정의가 없으면 지표가 아닙니다. **센 수와 그 정의가 있어야 개선했는지 말할 수 있습니다.**
|
||||
|
||||
## 7. 하지 말아야 할 때 (흔한 실수)
|
||||
|
||||
| 하기 쉬운 일 | 왜 위험한가 | 대신 |
|
||||
| --- | --- | --- |
|
||||
| 정의 없이 "오류율 보여 줘" | 보고서마다 숫자가 다름 | 정의서 한 곳 |
|
||||
| 평균만 봄 | 느린 사용자를 놓침 | p50 · p95 |
|
||||
| 비율만 봄 | 8건의 62.5%로 판단 | 건수를 함께 |
|
||||
| 오류율만 봄 | 답 못 함 34건을 놓침 | 오류가 아닌 실패도 정의 |
|
||||
| LLM에게 기록을 주고 세게 함 | 틀리고 비쌈 | Code가 세고 LLM은 설명만, 숫자 확인 |
|
||||
| 고친 뒤 다른 조건에서 잼 | 효과인지 운인지 모름 | 같은 조건 · 같은 입력 · 태그 |
|
||||
| 고친 지표만 다시 봄 | 새로 나빠진 것을 놓침 | SLO 전체를 다시 |
|
||||
| 기준(SLO)을 낮춰 "지킴"으로 | 사용자 피해는 그대로 | 문제를 고치고, 기준을 바꾸면 까닭을 남김 |
|
||||
| 알림을 매번 보냄 | 알림 피로 | 같은 이유는 한 번, 기록은 남김 |
|
||||
|
||||
## 8. 직무와 면접
|
||||
|
||||
오늘 한 일은 다음 직무들이 날마다 하는 일입니다: **SRE · 운영 엔지니어, 데이터 분석가 · 데이터 엔지니어, 백엔드 · 플랫폼 엔지니어, AI · LLM 애플리케이션 엔지니어, CS 운영 · 챗봇 운영, 업무 자동화(n8n · RPA) 개발자.** 채용 공고의 "모니터링 · 대시보드", "SLO · SLI", "로그 분석", "지표 정의", "장애 분석 · 회고", "운영 리포트 자동화"가 오늘 내용입니다.
|
||||
|
||||
면접에서 흔히 받는 질문과 오늘 숫자로 답하는 법:
|
||||
|
||||
<details><summary>1. "두 보고서의 숫자가 다릅니다. 어떻게 하나요?"</summary>
|
||||
|
||||
먼저 정의를 맞춥니다. 오늘 팀의 보고서는 두 주를 602건, 제 보고서는 666건이라고 했는데, 차이 64가 마지막 날의 실행 수와 같았습니다. 팀 보고서가 `started_at < to`로 끝날을 빼고 있었습니다. 오류율도 백분율에 반올림이 없었습니다. 정의서를 한 곳에 두고, 하루 · 빈 기간 · 거르기 같은 경계 테스트로 확인했습니다.
|
||||
</details>
|
||||
|
||||
<details><summary>2. "응답 시간을 어떻게 보고하나요? 평균이면 안 되나요?"</summary>
|
||||
|
||||
p50과 p95(필요하면 p99)를 씁니다. 평균은 느린 몇 건에 끌려가고 느린 사용자를 숨깁니다. 계산 방법(가장 가까운 순위인지 보간인지)도 정의에 적습니다. 오늘 둘째 주는 p50이 빨라졌지만 p95는 느려졌는데, 평균 하나로는 이렇게 나눠 말할 수 없습니다. 그리고 단계별로 나눠 어디가 느린지 봤습니다 — 평소엔 LLM, 월요일엔 FAQ 검색.
|
||||
</details>
|
||||
|
||||
<details><summary>3. "장애를 어떻게 찾고 우선순위를 정하나요?"</summary>
|
||||
|
||||
오류를 원인(노드 · 메시지)으로 묶고 많은 순으로, 시간으로 나눠 평소보다 크게 나쁜 시간을 찾고, 둘을 맞춰 사건으로 만듭니다. 오늘 오류 21건은 원인 둘, 사건 둘(월 09시 FAQ timeout 16건, 목 15시 429 5건)이었습니다. 그리고 오류가 아닌 실패도 따로 셉니다 — 와이파이 질문 34건이 담당자에게 넘어갔는데 오류율엔 안 잡혔고, 사용자 피해로는 가장 컸습니다.
|
||||
</details>
|
||||
|
||||
<details><summary>4. "LLM으로 운영 리포트를 만든다면 무엇을 조심하나요?"</summary>
|
||||
|
||||
숫자는 Code가 세고, LLM에게는 계산된 통계만 주고, 돌아온 글의 숫자가 통계에 있는지 Code가 확인합니다. 비율의 ×100이나 날짜 · 시간의 숫자도 "있는 숫자"에 넣어야 맞는 글이 틀렸다고 나오지 않습니다. 오늘 요약은 17 · 1000 · 16 · 10월 26일 09시가 모두 통계에 있어 `numbers_ok: true`였습니다. 할 일처럼 정해진 연결은 LLM이 아니라 규칙으로 씁니다.
|
||||
</details>
|
||||
|
||||
<details><summary>5. "SLO를 정하고 운영해 본 경험이 있나요?"</summary>
|
||||
|
||||
오류율 1% · p95 3초 · 이관율 2%를 정하고, 보고서가 위반을 판정하게 했습니다. 둘째 주는 오류율과 이관율을 어겼고, 고친 뒤에는 그 둘을 지켰지만 p95가 3560ms로 새로 어겼습니다 — timeout을 늘려 느린 FAQ를 기다렸기 때문이고, 단계 시간으로 증명했습니다. 위반하면 high 알림을 남기되 같은 위반은 10분에 한 번만 보냈습니다.
|
||||
</details>
|
||||
|
||||
## 9. 최종 프로젝트로 가져갈 것
|
||||
|
||||
최종 프로젝트(85일차~)의 워크플로우에 아래를 넣으면 "운영 데이터로 개선하는 프로젝트"가 됩니다.
|
||||
|
||||
- [ ] 실행마다 같은 모양의 기록 한 줄 (상태 · 갈래 · 시간 · 단계 시간 · 비용 · 실패한 노드 · 메시지 · 태그), 오류일 때도
|
||||
- [ ] 지표 정의서 한 장 (6절 틀), 보고서 웹훅 하나 — 나머지는 다시 부름
|
||||
- [ ] 경계 테스트 (하루 · 0건 · 거르기)
|
||||
- [ ] 문제 목록: 원인 묶음 · 오류가 아닌 실패 · 이상 시간대, 고칠 곳 · 주인
|
||||
- [ ] SLO 세 개와 위반 판정, 위반 알림 (같은 이유는 한 번)
|
||||
- [ ] 고친 뒤 같은 조건으로 다시 재기 (태그), 새로 나빠진 것까지
|
||||
- [ ] 주간 보고 (숫자는 Code, 요약은 LLM + 숫자 확인, 할 일은 규칙), `OPS.md`
|
||||
|
||||
## 10. 다음 일차와의 연결
|
||||
|
||||
| 일차 | 오늘의 무엇을 잇나 |
|
||||
| --- | --- |
|
||||
| 78 | 데이터 품질 검증 — 오늘은 기록을 믿고 셌다. 들어오는 데이터 자체(빠진 칸 · 이상한 값 · 중복)를 규칙으로 검사하는 품질 관문 |
|
||||
| 79 | 운영 대시보드 · Ops Assistant(`tops`) — 오늘의 지표 · SLO · 알림 · 주간 보고를 한 화면에, `tlog`와 76일차 `tretry`의 기록까지 |
|
||||
| 80~82 | 단위 프로젝트 — 팀 워크플로우에 9절 체크리스트 |
|
||||
|
||||
## 토론 (5분)
|
||||
|
||||
1. 오늘 "숫자가 다르면 먼저 정의를 의심한다"를 여러 번 했습니다. 내 업무(또는 수업)에서 같은 말로 다른 것을 세던 예가 있나요?
|
||||
2. 와이파이 34건(오류 아님)과 FAQ timeout 16건(오류) 중 무엇을 먼저 고치겠습니까? 무엇을 근거로?
|
||||
|
||||
## 정리
|
||||
|
||||
- [ ] 지표는 **정의 + 계산**, 정의는 한 곳에 (602 vs 666)
|
||||
- [ ] 평균 대신 백분위, 비율 옆에 건수, 경계에서 시험
|
||||
- [ ] 문제는 원인으로 묶고, 오류가 아닌 실패도 세고, 비교 기준을 함께 적는다
|
||||
- [ ] 숫자는 Code, 글은 LLM, LLM의 숫자는 Code가 확인
|
||||
- [ ] 고친 뒤 같은 조건으로 다시 재고, 새로 나빠진 것(대가)까지 본다 — SLO · 주간 보고 · SLO 알림
|
||||
- [ ] 최종 프로젝트에 체크리스트 7개를 가져간다
|
||||
@@ -0,0 +1,94 @@
|
||||
# 7·8교시 · 바이브 코딩 (`tlog`)
|
||||
|
||||
- 교시: 7교시 16:00~16:50 (각자 만들기), 8교시 17:00~17:50 (발표 10분 · [4단계 정리](04-STAGE4-WRAPUP.md) 35분 · 예고 5분)
|
||||
- 과제: [VIBE-REQ-TLOG](../../Last3Mon/77/VIBE-REQ-TLOG.md)(요청서, 요청의 말 ①~⑫) → [VIBE-Q-TLOG](../../Last3Mon/77/VIBE-Q-TLOG.md)의 8단계: `Doc/TODO.md` → `Doc/SPEC.md` → `Doc/IMP-PLAN.md`(엔진 · TUI 단계) → 단계별 구현 → 확인 → `uv tool install` → 다른 폴더에서 사용 → 수업 뒤 `VIBE-A-TLOG.md` 공개
|
||||
- 요구 14개(R1~R14). 50분 안에는 **엔진 1단계(R1 · R2 · R5 · R12 · R13) + 엔진 2단계(R3 · R4 · R7) + TUI 1단계(R11) + 설치(R14)**, 나머지(R6 단계 · 비용, R8 비교, R9 tretry 기록, R10 주간 보고)는 IMP-PLAN의 다음 단계로 집에서.
|
||||
- 72일차 `tbench`부터 76일차 `tretry`와 같은 흐름입니다: 사람의 말(요청서)을 **확인할 수 있는 요구**로 바꾸는 일을 학생이 먼저 하고, VIBE-Q는 그 다음 단계(비교 대상)로 씁니다. 에이전트에게는 처음 요청 한 번과 "확인했고 commit 했어. 다음 단계." 한 줄만 씁니다.
|
||||
- 오늘은 `tlog`: 실행 기록(파일 · 데이터 API)을 오늘 Lab의 정의 그대로 세어 **n8n `my-log-report`와 같은 숫자**를 내고, 실패 묶음 · 이상 시간대 · SLO 판정(종료 코드)을 보여 주고, TUI로 묶음을 골라 그 실행들을 보는 도구. 오늘 n8n 워크플로우로 한 일을 **터미널 어디서나.**
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
R["요청서 → TODO · SPEC ·<br/>IMP-PLAN 20분"] --> A["7교시<br/>엔진 1 · 2 · TUI · 설치 30분"] --> B["발표<br/>10분"] --> C["4단계 정리<br/>35분"] --> F["78일차 예고<br/>5분"]
|
||||
```
|
||||
|
||||
> **생활 속 예 · 주머니 속 계산기와 장부.** 오늘 가게 장부(n8n 보고서)를 만들었습니다. 사장님이 밤에 집에서 "어제 몇 시에 문제가 있었지?"를 보려면 가게 컴퓨터를 켜야 합니다. 같은 장부 쓰는 법으로 **주머니 속 계산기**에서도 같은 숫자가 나오면 어디서든 볼 수 있습니다. `tlog`는 그 계산기이고, 핵심은 "같은 숫자"입니다.
|
||||
|
||||
> 이 문서는 7 · 8교시 진행 문서입니다. 8교시의 정리 35분은 [04-STAGE4-WRAPUP](04-STAGE4-WRAPUP.md)으로 합니다.
|
||||
|
||||
## 1. 7교시 · 각자 만들기 (50분)
|
||||
|
||||
| 시간 | 단계 | 확인 |
|
||||
| --- | --- | --- |
|
||||
| 16:00~16:09 | 0 준비 · 1 요청서 → `Doc/TODO.md` (에이전트 없이) | 할 일 ①~⑫ · 꼭 / 나중 |
|
||||
| 16:09~16:15 | 2 `Doc/SPEC.md` → VIBE-Q 요구 표(R1~R14)와 비교 · commit | 요구마다 확인 방법 (두 주 666 · 21 · 0.0315 · 1205 · 2537, 종료 코드) |
|
||||
| 16:15~16:20 | 3 `Doc/IMP-PLAN.md` (엔진 1~3단계 · TUI 1단계 · 설치) · commit | 단계마다 체크리스트 |
|
||||
| 16:20~16:44 | 4 구현: 엔진 1단계 → 엔진 2단계 → TUI 1단계, 막히면 5 문제 해결 팁 | 단계마다 `pytest` · 직접 실행 · commit |
|
||||
| 16:44~16:50 | 6 확인 · 7 `uv tool install --editable .` · 8 다른 폴더에서 `tlog` | `tlog summary --url http://localhost:8800 --from 2026-10-26 --to 2026-10-30` = `my-log-report`의 숫자 |
|
||||
|
||||
| 볼 것 | 막혔을 때 한마디 |
|
||||
| --- | --- |
|
||||
| TODO · SPEC 없이 VIBE-Q를 통째로 붙여 넣었나 | "요청서로 Doc/TODO.md부터. 666이 SPEC에 없으면 맞았는지 모릅니다" |
|
||||
| IMP-PLAN이 한 덩어리 · 첫 요청에 14개 | "엔진 1단계만. 단계마다 확인 · 체크 · commit" |
|
||||
| 숫자가 n8n과 다름 | "어느 칸이 얼마로 다른지 붙여 주고, AGENTS.md 3절 정의 그대로 (끝날 포함 · `ceil(p × n)` · 4자리)" |
|
||||
| 두 주가 602 | "끝날 포함" — 오늘 Lab 01 예제 1의 팀 보고서와 같은 실수 |
|
||||
| 빈 기간에 오류 · `null` | "0건이면 0" |
|
||||
| 세는 코드가 cli · 화면에 흩어짐 | "metrics.py 한 곳, 나머지는 부르기만" |
|
||||
| 테스트가 진짜 API를 부름 | "가짜 서버(http.server)와 두 주 사본으로" |
|
||||
| `slo`가 늘 0 | "크면 위반, 위반이면 종료 코드 4" |
|
||||
| 실행해 보지 않고 다음 요청 | "에이전트가 됐다고 해도 직접 `uv run tlog …; echo $?`" |
|
||||
|
||||
정답 예(R1~R14를 모두 넣은 `tlog`와 정답본 `VIBE-A-TLOG.md`)는 수업 뒤 공개됩니다.
|
||||
|
||||
## 2. 8교시 · 발표 (10분)
|
||||
|
||||
- 1~2명. **`tlog summary --json`과 `my-log-report`의 숫자가 같다는 것을 보여 줄 수 있는 사람**, `tlog slo`의 종료 코드 4를 보여 줄 수 있는 사람을 먼저 고릅니다.
|
||||
- 3분 발표 · 2분 질문: **내 SPEC과 VIBE-Q가 달랐던 곳** / IMP-PLAN을 어떻게 나눴나 / 처음 요청 · 고쳐 달라는 요청문 / 에이전트가 틀린 곳(숫자가 달랐던 칸) / 시연.
|
||||
|
||||
## 3. 강사 정리 (8교시 4단계 정리 안에서)
|
||||
|
||||
| | n8n (오늘 Lab) | tlog |
|
||||
| --- | --- | --- |
|
||||
| 읽기 | `Get logs` → `POST /logs/query` | `--url` (같은 API) · `--file` (같은 규칙으로 거름) (R1) |
|
||||
| 지표 | `my-log-report` Code 노드 | `metrics.summary` — 같은 정의, 같은 반올림 (R2 · R5) |
|
||||
| 문제 찾기 | `failures` · `unanswered_topics` · `anomalies` · `repeat_topics` | `tlog problems` (R3 · R4) |
|
||||
| 단계 · 비용 | Lab 01 과제 2 | `steps` · `cost_usd` (R6) |
|
||||
| SLO | Lab 03 예제 2 · 과제 2 (알림) | `tlog slo` · 종료 코드 4 (R7) |
|
||||
| 주간 보고 | `my-weekly` (+ LLM 요약) | `tlog weekly` (LLM 없음) (R10) |
|
||||
| 다른 기록 | — | 76일차 tretry 기록 (R9) |
|
||||
|
||||
- 풀이 거리: 강사 본은 두 주 · 둘째 주 · 10/26 · 빈 기간 네 번 모두 `my-log-report`와 **18칸 중 다른 칸 0개**였습니다. 반올림을 Python `round`로 했다면 정확히 반에 걸린 값에서 달라질 수 있었고, 끝날을 빼면 602가 나옵니다. "같은 정의를 두 곳에 쓰면 반드시 어긋난다 — 그래서 n8n 안에서는 다시 부르고, 밖에서는 테스트로 같은 숫자를 확인한다."
|
||||
|
||||
## 4. 강사 바이브 코딩 (시간이 남으면 · 수업 뒤, 15분)
|
||||
|
||||
| 주제 | 요청문 요지 | 보여 줄 것 |
|
||||
| --- | --- | --- |
|
||||
| n8n 실행 기록 읽기 | "n8n 공개 API `/api/v1/executions`에서 실행 기록을 가져와 같은 모양으로 바꾸는 읽기 층을 하나 더. 키는 환경 변수 `N8N_API_KEY`" | 읽는 층만 늘고 세는 곳은 그대로 |
|
||||
| 기준 기간 이상 탐지 | "anomalies의 평소를 '지난주 같은 시간'으로 바꾸는 `--baseline last-week` 옵션" | Lab 02 예제 3의 다른 비교 기준 |
|
||||
| cron SLO | "tlog slo 를 매일 03:00에, 종료 코드 4면 76일차 알림 API에 high 알림" | n8n 밖의 SLO 알림 (Lab 03 과제 2와 같은 모양) |
|
||||
|
||||
걸린 시간과 결과를 `Last3Mon/77/VIBE-A-TLOG.md`에 적어 둡니다.
|
||||
|
||||
## 5. 보충 · 팁 (읽을거리, 4단계 정리 7절과 함께)
|
||||
|
||||
| 팁 | 설명 |
|
||||
| --- | --- |
|
||||
| 요청서 → 요구가 먼저 | 확인 방법(기대 숫자 · 종료 코드 · JSON 칸)이 있는 요구가 있어야 에이전트의 "완료"를 판단할 수 있음 |
|
||||
| 기대 숫자는 이미 있다 | 오늘 `cases/*.json`의 숫자를 SPEC과 테스트에 그대로 |
|
||||
| 정의는 한 곳 | 세는 함수는 `metrics.py`에만, 화면 · JSON · SLO는 부르기만 |
|
||||
| 읽는 층을 나눈다 | 기록 모양이 늘어도(tretry · n8n API) 세는 곳은 그대로 |
|
||||
| 반올림도 정의 | 다른 언어와 숫자를 맞출 때는 반올림 방법까지 |
|
||||
| 종료 코드로 말한다 | 0 · 1 · 2 · 4 — cron · CI가 다음 일을 정함 |
|
||||
| 단계마다 `git commit` | 에이전트가 망가뜨려도 돌아갈 곳 |
|
||||
|
||||
## 6. 78일차 예고 (5분)
|
||||
|
||||
- 오늘: 실행 기록을 정의대로 세고 · 문제를 찾고 · 고친 뒤 다시 쟀습니다. 다음 수업(78일차, 11/3): **데이터 품질 검증 자동화 및 품질 관리 Workflow** — 오늘은 기록을 "믿고" 셌습니다. 내일은 들어오는 데이터 자체가 맞는지(빠진 칸 · 이상한 값 · 중복)를 규칙으로 검사하고 품질 관문을 세웁니다.
|
||||
- 바이브 코딩: 오늘 `tlog`는 지우지 마세요. 79일차 `tops`에서 씁니다.
|
||||
|
||||
## 확인 (강사)
|
||||
|
||||
- [ ] 16:00 요청서 → TODO(에이전트 없이) → SPEC → IMP-PLAN 20분을 지켰다, 16:20부터 엔진 1단계.
|
||||
- [ ] 7교시 시작 전 n8n에 `my-log-report`(Lab 03 예제 2까지)가 게시돼 있어 숫자 비교를 할 수 있다.
|
||||
- [ ] 수업 뒤: 요청이 있을 때 학생 저장소에 정답(LAB-A · `answers/` · VIBE-A · `tlog/`)을 올린다.
|
||||
- [ ] 발표자 1~2명, 강사 정리 표, 팁, 예고.
|
||||
- [ ] 수업이 끝날 때 학생들의 데이터 API가 처음 상태인지 (`ops --reset`, `doctor`).
|
||||
@@ -0,0 +1,41 @@
|
||||
# 77일차 · 실행 로그 분석과 운영 데이터 기반 Workflow 개선 (바이브 코딩)
|
||||
|
||||
- 일자: 2026-11-02 (77일차)
|
||||
- 교과목: 노코드 멀티 에이전트 워크플로우 설계 및 운영
|
||||
- 단원: AI 워크플로우 운영 및 관리 역량 강화
|
||||
- 학습 내용: 실행 로그 분석, 운영 데이터 기반 Workflow 개선
|
||||
- 실습 폴더: [Last3Mon/77](../../Last3Mon/77/README.md)
|
||||
- 실습 환경: 65일차 n8n 2.42.6 + OpenAI API(`gpt-4.1-mini`, 요약 · 헬프데스크 답) + 77일차 데이터 API(76일차 + 두 주 실행 기록 666줄 · 오늘 실습 기록 · FAQ 더하기) + **CLI 코딩 에이전트**
|
||||
- **실습 준비: [00-DAY77-PREP.md](00-DAY77-PREP.md) (수업 전날까지 1~2절 완료)**
|
||||
- 수업 형식: 1 · 3 · 5교시 강의, 2 · 4 · 6교시 실습 5개씩 (예제 3 · 과제 2), 7교시 바이브 코딩, 8교시 발표 · 4단계 정리
|
||||
|
||||
## 오늘의 시간표
|
||||
|
||||
| 교시 | 시간 | 내용 | 자료 |
|
||||
| --- | --- | --- | --- |
|
||||
| 1 | 09:00~09:50 | 개요 · 1단계 강의 · 실행 기록 읽기와 지표 | [개요](00-DAY77-OVERVIEW.md) 1~14장, [1단계](01-STAGE1-READ-THE-LOG.md) |
|
||||
| 2 | 10:00~10:50 | Lab 01 실습 5개 (기준 보고서 비교 · 지표 보고서 · 경계 · 날짜별 · 릴리스별 · 단계 · 비용) | [Lab 01](../../Last3Mon/77/LAB-01-Q-READ-AND-MEASURE.md) |
|
||||
| 3 | 11:00~11:50 | 2단계 강의 · 문제를 숫자로 찾기 | 개요 15~21장, [2단계](02-STAGE2-FIND-PROBLEMS.md) |
|
||||
| 4 | 12:00~12:50 | Lab 02 실습 5개 (실패 묶음 · 답 못 한 주제 · 이상 시간대 · 기간 · 다시 묻는 주제 · LLM 요약) | [Lab 02](../../Last3Mon/77/LAB-02-Q-FIND-PROBLEMS.md) |
|
||||
| - | 13:00~14:00 | 점심 | |
|
||||
| 5 | 14:00~14:50 | 3단계 강의 · 고치고 다시 재기 | 개요 22~28장, [3단계](03-STAGE3-IMPROVE-AND-REMEASURE.md) |
|
||||
| 6 | 15:00~15:50 | Lab 03 실습 5개 (고치기 전 · 후 · SLO · 고친 것의 대가 · 주간 보고 · SLO 알림) | [Lab 03](../../Last3Mon/77/LAB-03-Q-IMPROVE-AND-REMEASURE.md) |
|
||||
| 7 | 16:00~16:50 | 바이브 코딩 `tlog`: 요청서 → TODO → SPEC → IMP-PLAN → 만들기 → 설치 | [VIBE-REQ-TLOG](../../Last3Mon/77/VIBE-REQ-TLOG.md), [진행](05-VIBE-CODING.md) |
|
||||
| 8 | 17:00~17:50 | 발표 · **4단계 정리** (의미 · 효과 · 회사에서 쓰는 법) · 78일차 예고 | [4단계 정리](04-STAGE4-WRAPUP.md), [진행](05-VIBE-CODING.md) |
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
P["개요"] --> S1["1단계<br/>실행 기록 · 지표 정의<br/>p95 · 경계 · 단계 · 비용"] --> S2["2단계<br/>원인 묶음 · 답 못 함<br/>이상 시간대 · 숫자 확인"] --> S3["3단계<br/>다시 돌리기 · SLO<br/>대가 · 주간 보고 · 알림"] --> V["7교시<br/>tlog"] --> W["8교시<br/>4단계 정리"]
|
||||
```
|
||||
|
||||
## 자료 목록
|
||||
|
||||
| 파일 | 내용 |
|
||||
| --- | --- |
|
||||
| `00-DAY77-PREP.md` | 실습 준비: n8n · 77일차 판 데이터 API 켜기, 기준 보고서(`base-report`) 게시, 기록 훑기, `flow.py doctor` (수업 전) |
|
||||
| `00-DAY77-OVERVIEW.md` | 개요 30장 (PPT 대신 Markdown, 가로줄로 장 구분) |
|
||||
| `01-STAGE1-READ-THE-LOG.md` | 실행 기록 · 관측의 세 가지, 지표는 정의, 백분위, 숫자는 Code, 경계와 0, 묶어서 세기 · 표본 크기, 단계 시간 · 비용 |
|
||||
| `02-STAGE2-FIND-PROBLEMS.md` | 원인으로 묶기 · 파레토, 오류가 아닌 실패(이관율), 이상 탐지, 비교 기준, 수와 비율(재문의율), LLM 요약과 숫자 확인, 사건 타임라인 |
|
||||
| `03-STAGE3-IMPROVE-AND-REMEASURE.md` | 다시 돌려 재기, 고칠 곳과 주인, SLI · SLO · 에러 예산, 고친 것의 대가(완화와 근본 해결), 주간 보고 조립, SLO 알림, 개선의 고리, 가게 장부로 본 하루 |
|
||||
| `04-STAGE4-WRAPUP.md` | 8교시 35분: 오늘의 의미 · 효과 숫자 · 업계 이름 · 산업별 응용 · 지표 정의서 · 면접 · 최종 프로젝트 체크리스트 |
|
||||
| `05-VIBE-CODING.md` | 7 · 8교시 바이브 코딩 진행 (tlog), 발표, 강사 정리, 강사 바이브 코딩, 팁, 예고 |
|
||||
Reference in new issue
Block a user