79일차 운영 데이터 기반 Ops Assistant: 실습 15개 · 강의(개요 30장 · 단계 문서 · 4단계 정리 · 05 바이브), 정답본 LAB-A · answers · VIBE-A · tops 포함
This commit is contained in:
mcchae committed
1 parent
9ce9aceba6
commit
6f0ecd59a9
156 files changed
+31640
No files matched your search
@@ -0,0 +1,446 @@
|
||||
# 79일차 개요 · 운영 데이터 기반 Workflow Ops Assistant
|
||||
|
||||
> 노코드 멀티 에이전트 워크플로우 설계 및 운영 · 2026-11-04
|
||||
> 30장 · 각 장은 가로줄(`---`)로 나뉩니다. 1교시에는 1~6장을 보고, 나머지 장은 각 단계 강의(1 · 3 · 5교시) 때 함께 띄웁니다.
|
||||
> 숫자는 모두 강사 노트북 실측입니다 (65일차 n8n 2.42.6, 79일차 판 데이터 API의 2026-11-04 08:30 운영 아침 상태 · 실행 기록 666건, OpenAI `gpt-4.1-mini`(답 · 라우터 · 요약, temperature 0), 11/01 정답 워크플로우를 학생 순서대로 1회).
|
||||
|
||||
| 장 | 범위 | 띄우는 때 |
|
||||
| --- | --- | --- |
|
||||
| 1~6 | 표지 · 목표 · 시간표 · 수요일 아침 08:30 · 일하는 순서 · 실습 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
|
||||
S[("출처 여섯<br/>실행 · 알림 · DLQ ·<br/>품질 · 비용 · 릴리스")] --> F["사실 · 상태<br/>Code"] --> A["질문 답변<br/>라우터 · 거절 · 숫자 확인"] --> B["브리핑 · 평가<br/>먼저 볼 것 · 골든 질문"]
|
||||
classDef d fill:#0F3D3E,stroke:#0F3D3E,color:#fff
|
||||
classDef o fill:#F2A541,stroke:#F2A541,color:#fff
|
||||
class S d
|
||||
class F,A,B o
|
||||
```
|
||||
|
||||
**79일차**
|
||||
|
||||
# 운영 데이터 기반 Workflow Ops Assistant
|
||||
|
||||
숫자 · 상태는 Code가 · 글은 LLM이 · 작업은 사람이
|
||||
|
||||
<sub>노코드 멀티 에이전트 워크플로우 설계 및 운영 · 2026-11-04</sub>
|
||||
|
||||
---
|
||||
|
||||
## 2 / 30 · 오늘 할 수 있게 될 세 가지
|
||||
|
||||
| | 목표 | 내용 |
|
||||
| --- | --- | --- |
|
||||
| 1 | **사실로 모은다** | 흩어진 출처 여섯을 정의가 정해진 사실 하나로, 기간과 지금을 나누고, 0과 `null`을 구분하고, 영역마다 색을 매기고, 출처가 멈춰도 나머지를 내놓는다 |
|
||||
| 2 | **답하고 막는다** | 질문을 영역 하나로 고르고 그 사실만으로 답하고, 운영 밖 · 작업 요청은 LLM 앞에서 거절하고, 숫자를 확인하고, 낱말이 모를 때만 LLM 라우터를, 감사 기록을 남긴다 |
|
||||
| 3 | **정리하고 시험한다** | 먼저 볼 것 · 할 일을 규칙으로 정한 브리핑, 덧붙이는 LLM 요약, 사람이 일한 뒤의 브리핑, 골든 질문 평가와 평가 관문 |
|
||||
|
||||
---
|
||||
|
||||
## 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개** · 브리핑 · LLM 요약 · 아침이 바뀌면 · 골든 질문 평가 · 평가 관문 |
|
||||
| 7 | 16:00~16:50 | 바이브 코딩 `tops`: 요청서 → TODO → SPEC → IMP-PLAN → 만들기 → 설치 |
|
||||
| 8 | 17:00~17:50 | 발표 · **4단계 정리** (의미 · 효과 · 회사에서 쓰는 법) · 80일차(단위 프로젝트) 예고 |
|
||||
|
||||
---
|
||||
|
||||
## 4 / 30 · 오늘의 출발점: 수요일 아침 08:30
|
||||
|
||||
운영 담당자가 출근했습니다. 72~78일차가 남긴 것이 여섯 군데에 흩어져 있습니다.
|
||||
|
||||
| 출처 | `morning` | 팀의 기준 대시보드 |
|
||||
| --- | --- | --- |
|
||||
| 실행 기록 | 지난주 357건 | **666건** · 3.153… (기간 무시 · 백분율) |
|
||||
| 알림 | 6 (높음 3) | 6 |
|
||||
| DLQ | 3, **parked 2** | 3 |
|
||||
| 품질 · 격리 | 4줄 · 격리 1 | **없음** |
|
||||
| 비용 | $0.073604 / $0.08 (92%) | 금액 둘 |
|
||||
| 릴리스 | 1.1.0 + **카나리 1.2.0 20%** | **없음** |
|
||||
|
||||
그리고 팀의 기준 챗봇에 "DLQ 1번 다시 돌려 줘"라고 하면: **"DLQ 1번 작업을 다시 실행해 드리겠습니다."** (아무것도 실행하지 않았음)
|
||||
|
||||
---
|
||||
|
||||
## 5 / 30 · 일하는 순서 (오늘은 "정의 → 요청문 → 사실 · 답 → 확인")
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A["① 먼저 보기<br/>morning · call · test(전)"] --> B["② 정의 · 기준 · 요청문"] --> C["③ 에이전트<br/>my-work · check"] --> D["④ 내가<br/>push · test -v · call"]
|
||||
D -->|"✘ 칸 = 실제 (expected 기대)"| C
|
||||
D -->|✔| E["⑤ OPS.md 한 줄"]
|
||||
```
|
||||
|
||||
| 누가 | 무엇을 |
|
||||
| --- | --- |
|
||||
| 나 | 무엇을 물을지 · 사실의 정의 · 색의 기준 · 도우미가 **하면 안 되는 것** · 골든 질문 정하기, 그리고 **작업하기** |
|
||||
| CLI 에이전트 | `AGENTS.md`대로 워크플로우 JSON, `check` |
|
||||
| `flow.py` | `test --webhook`(기준과 비교), `morning`(운영 아침 한눈에, `--reset`), `call` |
|
||||
|
||||
---
|
||||
|
||||
## 6 / 30 · 실습 15개 (Lab마다 예제 3 · 과제 2)
|
||||
|
||||
| | 예제 1 | 예제 2 | 예제 3 | 과제 1 | 과제 2 |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| Lab 01 | 출처 둘러보기 · 기준 대시보드 (에이전트 없이) | 운영 사실 | 기간을 바꾸면 (에이전트 없이) | 영역별 상태 | 출처가 멈추면 |
|
||||
| Lab 02 | 라우터 · 그 영역 사실 · 운영 밖 거절 | 작업 거절 · 숫자 확인 | 질문을 바꾸면 (에이전트 없이) | LLM 라우터 | 감사 기록 |
|
||||
| Lab 03 | 아침 브리핑 | LLM 요약 | 아침이 바뀌면 (에이전트 없이) | 골든 질문 평가 | 평가 관문 |
|
||||
|
||||
---
|
||||
|
||||
## 7 / 30 · 1단계 · 운영 도우미가 하는 일
|
||||
|
||||
> 생활 속 예: 병원 아침 인수인계 — 차트 열두 개를 다 읽지 않고, 정해진 항목을 정해진 순서로 넘긴다. "지금 괜찮나? 무엇부터 볼까?"
|
||||
|
||||
| 업계에서 쓰는 말 | 하는 일 |
|
||||
| --- | --- |
|
||||
| 운영 대시보드 (Grafana · Datadog) | 숫자 · 색을 한 화면에 |
|
||||
| ChatOps (Slack 봇 · PagerDuty 연동) | 대화창에서 묻고 답 받기 |
|
||||
| AIOps (Datadog Bits AI · Dynatrace Davis) | 운영 데이터에 AI (요약 · 분류 · 이상 탐지) |
|
||||
| 아침 브리핑 · 당번 인수인계 | 먼저 볼 것과 할 일 |
|
||||
|
||||
- 오늘의 원칙: **숫자 · 상태는 Code가, 글은 LLM이, 작업은 사람이.** 도우미는 읽기만.
|
||||
|
||||
---
|
||||
|
||||
## 8 / 30 · 출처 여섯 = 묻는 영역 여섯
|
||||
|
||||
> 생활 속 예: 인수인계 양식의 칸 — 체온 · 수액 · 투약 · 검사 · 식사 · 특이 사항.
|
||||
|
||||
| 영역 | 묻는 것 | 남긴 날 |
|
||||
| --- | --- | --- |
|
||||
| 실행 | 오류 · 느림 · 답 못 함 | 77일차 실행 기록 |
|
||||
| 알림 | 무엇이 울렸나 · 얼마나 급한가 | 76~78일차 |
|
||||
| DLQ | 사람이 볼 일이 남았나 | 76일차 |
|
||||
| 품질 | 데이터를 믿을 수 있나 | 78일차 |
|
||||
| 비용 | 한도 안인가 · 누가 쓰나 | 75일차 |
|
||||
| 릴리스 | 무슨 판이 나가나 · 카나리는 괜찮나 | 74일차 |
|
||||
|
||||
- SRE의 네 가지 황금 신호(지연 · 트래픽 · 오류 · 포화)에 **품질 · 비용 · 릴리스**가 더해진 것이 AI 워크플로우 운영.
|
||||
|
||||
---
|
||||
|
||||
## 9 / 30 · 없는 칸이 가장 위험하다 (Lab 01 예제 1)
|
||||
|
||||
> 생활 속 예: "모두 체온 정상"만 적힌 메모 — 거짓은 없지만 수액 칸이 없다.
|
||||
|
||||
| 대시보드의 실수 | 누가 알아채나 |
|
||||
| --- | --- |
|
||||
| 틀린 숫자 | 누군가 "이상한데?" |
|
||||
| **없는 칸** | 아무도 — "괜찮다"처럼 보임 |
|
||||
|
||||
- 기준 대시보드만 보면 오늘 가장 급한 둘(**parked 2건 · 카나리 1.2.0**)을 모름.
|
||||
- 그래서 먼저 정하는 것은 계산이 아니라 **무엇을 물어야 하나**.
|
||||
|
||||
---
|
||||
|
||||
## 10 / 30 · 사실 하나로 · 정의는 다시 만들지 않는다 (Lab 01 예제 2)
|
||||
|
||||
> 생활 속 예: 병원 공용 차트 양식 — "고열 = 38도 이상"을 양식에 박아 두고 모두 그것을 읽는다.
|
||||
|
||||
| 영역 | 내 `my-ops-facts`의 지난주 |
|
||||
| --- | --- |
|
||||
| 실행 | 357 · 0.0588 · p95 2598 · 답 못 함 0.0476 · 실패 1위 `Search FAQ` timeout 16 |
|
||||
| 알림 · DLQ | 6 · 높음 3, 3 · parked 2 · 대기 1 |
|
||||
| 품질 · 비용 | 평균 0.6583 · 격리 1, 0.9201 · 1위 `test-bot` 37% |
|
||||
| 릴리스 | 카나리 다시 묻기 **62.5%** 대 1.1.0 7.73% |
|
||||
|
||||
- 77일차 숫자와 **같음** — 시맨틱 레이어(dbt Semantic Layer · Cube). 출처 여덟 → Code 하나, 0.1초. `lab01` 0/5 → 5/5.
|
||||
|
||||
---
|
||||
|
||||
## 11 / 30 · 기간과 지금 · 0과 `null` (Lab 01 예제 3)
|
||||
|
||||
> 생활 속 예: "밤새 열이 두 번"(기간) · "지금 37.2도"(지금) · "소변량은 안 쟀음"(모름 ≠ 0).
|
||||
|
||||
| 기간 | 실행 | 다시 묻는 비율 | 지금 숫자 |
|
||||
| --- | --- | --- | --- |
|
||||
| 두 주 | 666 · 0.0315 | 7.73% · 62.5% | 그대로 |
|
||||
| 10/26 | 70 · 0.2286 | **`null`** (판이 10/28부터) | 그대로 |
|
||||
| 빈 주 | 0 · 오류율 0 · 실패 1위 **`null`** | `null` | 그대로 |
|
||||
|
||||
- 기간은 **실행 기록에만**. 0 = 셌고 없었다, `null` = 말할 수 없다.
|
||||
|
||||
---
|
||||
|
||||
## 12 / 30 · 상태는 규칙으로 (Lab 01 과제 1)
|
||||
|
||||
> 생활 속 예: 병동 현황판의 빨강 · 노랑 자석 — 간호사의 기분이 아니라 기준표로 붙인다.
|
||||
|
||||
| 영역 | 🔴 | 🟡 | 지난주 |
|
||||
| --- | --- | --- | --- |
|
||||
| 실행 | 오류율 > 0.01 | 답 못 함 > 0.02 | 🔴 |
|
||||
| 알림 | 높음 ≥ 5 | 1건 이상 | 🟡 |
|
||||
| DLQ | parked > 0 | 남음 | 🔴 |
|
||||
| 품질 | 마지막 < 0.8 | < 0.9 · 격리 | 🟡 |
|
||||
| 비용 | ≥ 100% | ≥ 80% | 🟡 |
|
||||
| 릴리스 | 카나리 > 2배 | 카나리 켜짐 | 🔴 |
|
||||
|
||||
- RAG 상태 · SLO 판정 (77일차). 비율이 `null`이면 빨강이 아니라 노랑 — "모르니 지켜보자".
|
||||
|
||||
---
|
||||
|
||||
## 13 / 30 · 출처가 멈추면 (Lab 01 과제 2)
|
||||
|
||||
> 생활 속 예: 검사실 전화가 안 되는 아침 — 나머지는 넘기고 "검사 결과: 받지 못함". "정상"이라고 적지 않는다.
|
||||
|
||||
| | 고치기 전 | 고친 뒤 |
|
||||
| --- | --- | --- |
|
||||
| 사용량 출처가 500 | 사실 전체가 **500** | 200 · 다섯 영역 그대로 |
|
||||
| 비용 | — | `null` · ⚪ `unknown` · `sources_down: ["cost"]` |
|
||||
| 전체 | — | 🔴 (빨강이 없어도 unknown이면 적어도 🟡) |
|
||||
|
||||
- 우아한 저하(graceful degradation). 비용을 0으로 적었다면 🟢 — 실제는 92%.
|
||||
|
||||
---
|
||||
|
||||
## 14 / 30 · 1단계 정리 · 사실
|
||||
|
||||
| 원칙 | 오늘 |
|
||||
| --- | --- |
|
||||
| 무엇을 물을지 먼저 | 영역 여섯 — 없는 칸이 가장 위험 |
|
||||
| 정의는 한 곳 | 77일차 숫자 그대로, 다음 단계는 사실만 읽음 |
|
||||
| 시간 종류 · 모름 | 기간은 실행에만, 0과 `null` |
|
||||
| 색은 기준표로 | 🔴 셋 · 🟡 셋, 비교 불가는 🟡 |
|
||||
| 부분 실패 | 출처 하나가 멈춰도 200 · `unknown` |
|
||||
|
||||
---
|
||||
|
||||
## 15 / 30 · 2단계 · 기준 챗봇의 세 실수
|
||||
|
||||
> 생활 속 예: 무엇이든 대답하는 새내기 간호사 — 맛집도 알려 주고, 권한도 없이 "약 바꿔 드릴게요".
|
||||
|
||||
| 질문 | 기준 챗봇 (`base-ops-ask`) | 위험 |
|
||||
| --- | --- | --- |
|
||||
| 점심 메뉴 추천해 줘 | 김치찌개 · 불고기 · 비빔밥 | 범위 밖 |
|
||||
| DLQ 1번 다시 돌려 줘 | "**다시 실행해 드리겠습니다**" | 하지 않은 일을 했다고 |
|
||||
| 카나리 버전 문제 있어? | 오류율 · 알림 · DLQ를 섞음 (62.5% 없음) | 원인을 잘못 짚음 |
|
||||
|
||||
- `lab02` **0/6**. 가드레일(NeMo Guardrails) · 범위 제한 · 근거 제한을 **워크플로우의 갈래**로.
|
||||
|
||||
---
|
||||
|
||||
## 16 / 30 · 라우터 · 그 영역 사실만 (Lab 02 예제 1)
|
||||
|
||||
> 생활 속 예: 병원 안내 데스크 — 진단하지 않고 어디로 보낼지만, 심장내과에 정형외과 차트는 주지 않는다.
|
||||
|
||||
| 방식 | 장점 | 단점 |
|
||||
| --- | --- | --- |
|
||||
| 낱말 목록 (Code) | 0초 · 공짜 · 늘 같음 | 목록에 없는 말은 모름 |
|
||||
| LLM 분류 | 처음 보는 말도 | 1~3초 · 비용 |
|
||||
|
||||
- 오류율 → `runs` 5.88% · 카나리 → `release` 62.5% 대 7.73% · 점심 → 거절 0.1초 (LLM 없음).
|
||||
- 그러나 "DLQ 1번 다시 돌려 줘" → `dlq`로 답 "**#1은 대기 중**" (틀림). `lab02` 3/6.
|
||||
|
||||
---
|
||||
|
||||
## 17 / 30 · 거절은 LLM 앞에서 · 읽기만 (Lab 02 예제 2)
|
||||
|
||||
> 생활 속 예: 처방은 의사만 — 간호사의 성격이 아니라 병원의 규칙. "전해 드릴게요"는 되고 "바꿔 드릴게요"는 안 된다.
|
||||
|
||||
| 막는 곳 | 확실한가 |
|
||||
| --- | --- |
|
||||
| 지시문 "작업은 거절해" | 대개 (LLM이 따를 때만) |
|
||||
| **라우터 앞 Code 갈래** | 늘 — 0초, LLM은 보지도 않음 |
|
||||
| 쓰는 API를 아예 안 부름 | 늘 — 할 수단이 없음 |
|
||||
|
||||
- "DLQ 1번 다시 돌려 줘" → `action` · `read_only` · **0.0초** · "런북에 따라 담당자가 직접". 최소 권한 · human-in-the-loop.
|
||||
|
||||
---
|
||||
|
||||
## 18 / 30 · 숫자 확인과 그 한계 (Lab 02 예제 2)
|
||||
|
||||
> 생활 속 예: 메모의 숫자를 차트와 맞춰 보기 — 없는 숫자는 잡지만, "2번 환자 39.1"을 3번으로 적은 것은 못 잡는다.
|
||||
|
||||
| 잡는 것 | 못 잡는 것 |
|
||||
| --- | --- |
|
||||
| 지어낸 숫자 · 계산 실수 | 사실에 있는 숫자를 **다른 뜻**으로 |
|
||||
| | 두 숫자를 **거꾸로** |
|
||||
|
||||
- 비용 92.01 (= 0.9201 × 100) · 릴리스 62.5 (`1.2.0`은 버전으로 통째로) → `numbers_ok: true`. `lab02` **6/6**.
|
||||
- 예제 1의 "#1은 대기 중"은 통과 (1은 사실에 있음) — 그래서 작업 요청은 **답하지 않고 막는다**.
|
||||
|
||||
---
|
||||
|
||||
## 19 / 30 · 질문을 바꾸면 (Lab 02 예제 3)
|
||||
|
||||
> 생활 속 예: 안내 데스크의 단어장 — "숨이 차요"는 없다. 짐작하지 않고 "모르겠습니다"는 불편하지만 안전.
|
||||
|
||||
| 질문 | 낱말 라우터 | 운영자에게 |
|
||||
| --- | --- | --- |
|
||||
| 에러 많이 났어? | runs | 좋음 |
|
||||
| 장애 났어? | 거절 | **불편** |
|
||||
| 알림이랑 DLQ | alerts (같으면 앞) | 반쪽 |
|
||||
| 카나리 꺼 줘 | 작업 거절 | 안전 |
|
||||
| AI 쓰는 데 얼마나 나갔어? | 거절 | **불편** |
|
||||
|
||||
- 6/6 = **규칙대로**. 실패의 방향이 "모르면 거절"이라 안전.
|
||||
|
||||
---
|
||||
|
||||
## 20 / 30 · LLM 라우터 · 낱말이 모를 때만 (Lab 02 과제 1)
|
||||
|
||||
> 생활 속 예: 단어장에 없을 때만 선배를 부른다 — 모든 질문마다 부르면 선배가 아무 일도 못 한다.
|
||||
|
||||
| 질문 | 영역 · 라우터 | 시간 |
|
||||
| --- | --- | --- |
|
||||
| AI 쓰는 데 얼마나 나갔어? | `cost` · `llm` · 92.01% | 4.9초 |
|
||||
| 어젯밤 접수 못 하고 남은 건 | `dlq` · `llm` · 3건 | 1.7초 |
|
||||
| 지난주 오류율 | `runs` · `keyword` (그대로) | 1.0초 |
|
||||
|
||||
- 모델 계단(cascade). 예제 3 다시 → **4/6** (장애 · AI 비용이 이제 답함 — 기대가 옛 규칙).
|
||||
- "2건은 대기 · 1건은 주차" — **거꾸로**인데 `numbers_ok: true`.
|
||||
|
||||
---
|
||||
|
||||
## 21 / 30 · 감사 기록 (Lab 02 과제 2)
|
||||
|
||||
> 생활 속 예: 간호사실 전화 기록부 — 몇 시 · 무엇을 · 어떻게 답했나. "약 바꿔 달라는 전화가 하루 열 번"이 보인다.
|
||||
|
||||
| 질문 | 기록 |
|
||||
| --- | --- |
|
||||
| DLQ 1번 다시 돌려 줘 | `action` · `keyword` · `read_only` |
|
||||
| 점심 메뉴 | `unknown` · **`llm`** · `out_of_scope` (비용이 든 거절) |
|
||||
| 지난주 오류율 | `runs` · `keyword` · `numbers_ok: true` |
|
||||
|
||||
- LLM 관측성 (Langfuse · LangSmith). 덧붙이기만 — 읽기 전용의 예외, 응답은 그대로. 질문 원문의 개인정보 주의.
|
||||
|
||||
---
|
||||
|
||||
## 22 / 30 · 3단계 · 브리핑 · 먼저 볼 것은 규칙으로 (Lab 03 예제 1)
|
||||
|
||||
> 생활 속 예: 인수인계는 병실 순서가 아니라 빨강 환자부터, 환자마다 다음 할 일이 정해져 있다.
|
||||
|
||||
| 먼저 볼 것 | 할 일 (런북) |
|
||||
| --- | --- |
|
||||
| 🔴 실행 | 오류 묶음 1위 확인 · 고치기 (77일차) |
|
||||
| 🔴 DLQ | parked 건 원인 확인 뒤 런북대로 재처리 (76일차) |
|
||||
| 🔴 릴리스 | 카나리 끄기 · 되돌리기 검토 (74일차) |
|
||||
|
||||
- red 다음 yellow의 앞 3개, 표의 색은 사실 그대로. LLM 없음, `lab03` 4/4.
|
||||
|
||||
---
|
||||
|
||||
## 23 / 30 · LLM 요약은 덧붙이는 말 (Lab 03 예제 2)
|
||||
|
||||
> 생활 속 예: 인수인계 끝의 한마디 "오늘은 3호실이 제일 걱정" — 기억에 남지만 표를 대신하면 다른 두 환자가 빠진다.
|
||||
|
||||
- 요약: "전체 시스템 상태는 빨간색으로, 오류율은 5.88% … 가장 긴급한 문제는 'Search FAQ' 노드 … 16건 …"
|
||||
- `numbers_ok: true`, 두 번 부르면 글이 조금 다름.
|
||||
- 먼저 볼 것 셋 중 **하나**만 말함 (DLQ · 카나리 없음) → 표 · 순서는 Code가.
|
||||
|
||||
---
|
||||
|
||||
## 24 / 30 · 아침이 바뀌면 (Lab 03 예제 3)
|
||||
|
||||
> 생활 속 예: 빨강 자석을 뗀 까닭 — 열이 내려서 · 다른 병동으로 옮겨서 · 기준을 바꿔서. 셋째를 "나았다"고 하면 큰일.
|
||||
|
||||
| 사람이 한 일 | 바뀐 것 | 뜻 |
|
||||
| --- | --- | --- |
|
||||
| parked 둘 처리 | DLQ 🔴 → 🟡 | 일을 끝냄 |
|
||||
| 카나리 끔 | 릴리스 🔴 → 🟢 | 위험을 멈춤 (1.2.0은 그대로) |
|
||||
| 예산 0.08 → 0.2 | 비용 🟡 → 🟢 | 한도를 바꿈 (쓴 돈은 그대로) |
|
||||
|
||||
- 남은 빨강은 실행 하나 (FAQ timeout). "초록입니다"가 아니라 **무엇을 했는지**를 말한다.
|
||||
|
||||
---
|
||||
|
||||
## 25 / 30 · 골든 질문 평가 (Lab 03 과제 1)
|
||||
|
||||
> 생활 속 예: 새 간호사의 모의 인수인계 시험 — 정해진 질문 여덟 개, 누가 채점해도 같다.
|
||||
|
||||
| 칸 | 묻는 것 |
|
||||
| --- | --- |
|
||||
| `area_ok` | 맞는 영역으로 |
|
||||
| `refused_ok` | 거절할 것을 거절 |
|
||||
| `number_ok` | 기대 숫자가 답에 |
|
||||
| `grounded` | 답의 숫자가 사실에 |
|
||||
|
||||
- 골든 8 → **8/8 · score 1** (3.9초). OpenAI Evals · promptfoo · RAGAS.
|
||||
|
||||
---
|
||||
|
||||
## 26 / 30 · 평가는 시험지도 시험한다 (Lab 03 과제 1)
|
||||
|
||||
| 케이스 | 결과 | 뜻 |
|
||||
| --- | --- | --- |
|
||||
| "알림이 몇 건?" 기대 영역 `cost` (일부러 틀림) | `area_ok: false`만 | 도우미는 맞고 **시험지가** 틀림 |
|
||||
| 빈 목록 | 400 | "0개 중 0개 = 100%"로 속지 않음 |
|
||||
|
||||
- 8/8이어도 "parked 2 · 대기 1을 거꾸로" 같은 답은 통과 → 골든 세트에 **틀리기 쉬운 질문**을 더해 간다.
|
||||
|
||||
---
|
||||
|
||||
## 27 / 30 · 평가 관문 (Lab 03 과제 2)
|
||||
|
||||
> 생활 속 예: 합격선 80점 — 없으면 50점도 병동에 나간다. 떨어지면 수간호사에게 알림.
|
||||
|
||||
| 평가 | score | 기준 | gate |
|
||||
| --- | --- | --- | --- |
|
||||
| 기준 없음 | 1 | 0.9 (기본) | pass |
|
||||
| 골든 8 | 1 | 0.8 | pass |
|
||||
| 틀린 기대 | 0 | 0.9 | **fail** → `eval_below` 알림 |
|
||||
|
||||
- 74일차 배포 게이트 · 78일차 품질 게이트와 같은 모양. LLMOps의 회귀 시험 (CI에서 평가).
|
||||
|
||||
---
|
||||
|
||||
## 28 / 30 · 병원 아침으로 본 오늘 하루
|
||||
|
||||
> 생활 속 예: 오늘 만든 것이 모두 병원 아침에 있다.
|
||||
|
||||
| 오늘 | 병원 |
|
||||
| --- | --- |
|
||||
| 출처 여섯 · 사실 · 정의 | 차트 여섯 · 인수인계 양식 · 공용 차트 기준 |
|
||||
| 기간 · 0과 `null` · 상태 | 밤새 · 지금 · "안 쟀음" · 빨강 · 노랑 자석 |
|
||||
| 출처가 멈추면 | 검사 결과 "받지 못함" |
|
||||
| 라우터 · 거절 · 숫자 확인 | 안내 데스크 · 처방은 의사만 · 차트와 맞춰 보기 |
|
||||
| LLM 라우터 · 감사 | 선배 간호사 · 전화 기록부 |
|
||||
| 브리핑 · 요약 · 아침이 바뀌면 | 빨강 환자부터 · 끝의 한마디 · 자석을 뗀 까닭 |
|
||||
| 평가 · 관문 · 평가가 바꾸는 것 | 모의 시험 · 합격선 · 시험 중 울린 호출벨 |
|
||||
|
||||
---
|
||||
|
||||
## 29 / 30 · 7교시 바이브 코딩 · `tops`
|
||||
|
||||
요청서(운영 당번 · 팀장의 말 ①~⑫) → `Doc/TODO.md` → `SPEC.md` → `IMP-PLAN.md` → 단계별로 → `uv tool install`.
|
||||
|
||||
| 오늘 n8n에서 | `tops`로 터미널에서 (당번의 아침) |
|
||||
| --- | --- |
|
||||
| `my-ops-facts` | `tops status` — **n8n이 정한 색 그대로**, 빨강이면 종료 코드 4 |
|
||||
| `my-ops-ask` | `tops ask "…"` — 영역 · 거절 · 숫자 확인 |
|
||||
| `my-ops-brief` · `my-ops-eval` | `tops brief` · `tops eval` (관문 실패면 4) |
|
||||
| 감사 · 지난 도구 | `tops audit` · `tops tools` (`tlog slo` · `tcheck`) |
|
||||
| (없음) | TUI 탭 다섯, 못 읽는 탭만 "not available", **읽기만** (주소 목록) |
|
||||
|
||||
- 강사 본: 실제 n8n에서 `tops status` 일곱 줄 · 종료 코드 4 · 0.19초, 테스트 27개 8.6초 (n8n 없이).
|
||||
|
||||
---
|
||||
|
||||
## 30 / 30 · 오늘의 정리 · 80일차 예고
|
||||
|
||||
| 단계 | 오늘 숫자 |
|
||||
| --- | --- |
|
||||
| 사실 | 기준 666 · 칸 없음 → 357 · 여섯 영역, 기간 넷, 🔴 셋 🟡 셋, 출처가 멈춰도 200 · `unknown` |
|
||||
| 질문 답변 | 기준 0/6 ("다시 실행해 드리겠습니다") → 3/6 → 6/6, 말투 여섯, LLM 라우터 5/5 (phrasing 4/6), 감사 3줄 |
|
||||
| 브리핑 · 평가 | 먼저 볼 것 셋 · 요약 세 문장, 사람이 일한 뒤 빨강 하나, 골든 8/8, 관문 fail → 알림 |
|
||||
|
||||
- 8교시 [4단계 정리](04-STAGE4-WRAPUP.md): 의미 · 효과 · 업계 이름 · 면접 · 최종 프로젝트 체크리스트.
|
||||
- 80~82일차: **단위 프로젝트** — 팀마다 64~79일차의 워크플로우를 묶어 하나의 서비스로. 오늘의 운영 도우미가 그 서비스의 운영 부분이 된다.
|
||||
@@ -0,0 +1,93 @@
|
||||
# 79일차 실습 준비 · 수업 전에 미리 해 두면 좋은 것
|
||||
|
||||
- 수업일: 2026-11-04 (79일차) · 운영 데이터 기반 Workflow Ops Assistant
|
||||
- 준비 시간: 약 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/>(79일차 판)"] --> B["2. morning ·<br/>doctor ready"] --> C["3. 미리 읽기"]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 1. n8n과 데이터 API 켜기 (전날 필수, 3분)
|
||||
|
||||
오늘은 **79일차 판 데이터 API**(78일차 + 운영 아침 상태)를 씁니다. 켜는 순간 알림 · DLQ · 품질 기록 · 사용량 · 예산 · 릴리스가 "수요일 아침 08:30" 상태로 채워집니다.
|
||||
|
||||
```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/79/data-api
|
||||
docker compose up -d --force-recreate
|
||||
curl -s localhost:8800/ops/seed-info # {"seeded_at": "2026-11-04T08:30:00", ... "counts": {"alerts": 6, ...
|
||||
```
|
||||
|
||||
- **66일차부터 LLM은 OpenAI API 키(`Last3Mon/.env`, Credential `OpenAI (.env)`)만 씁니다.** Ollama는 쓰지 않습니다.
|
||||
- `network day65-n8n_default not found` → n8n이 켜져 있지 않음. 위 n8n 부분부터 다시.
|
||||
|
||||
## 2. 상태 보기와 준비 확인 (전날 필수, 3분)
|
||||
|
||||
```bash
|
||||
cd ~/aio-01d4-stu/Last3Mon/79
|
||||
uv run tools/flow.py push reference/baseline-ops-facts.json reference/baseline-ops-ask.json # 팀의 기준 둘 (고치기 전에 비교할 상대)
|
||||
uv run tools/flow.py morning
|
||||
uv run tools/flow.py doctor
|
||||
```
|
||||
|
||||
```text
|
||||
seeded morning 2026-11-04T08:30:00 · {"alerts": 6, "dlq": 3, "quality_log": 4, "quarantine": 1, "usage": 192}
|
||||
alerts: 6 (high 3)
|
||||
[high] helpdesk/Search FAQ · timeout · timeout of 1000ms exceeded
|
||||
...
|
||||
DLQ: 3 (parked 2)
|
||||
quality log: 4 (scores [0, 0.8, 0.8333, 1]) · quarantine 1
|
||||
usage: 156 requests · 192 calls · $0.073604
|
||||
budget: used $0.073604 of $0.08
|
||||
release: active 1.1.0 · canary {"release": "1.2.0", "percent": 20}
|
||||
...
|
||||
✔ operations morning /ops/seed-info (day 79 data API)
|
||||
✔ credential 'OpenAI (.env)' (openAiCourse0001)
|
||||
ready
|
||||
```
|
||||
|
||||
| ✘ 항목 | 할 일 |
|
||||
| --- | --- |
|
||||
| n8n container · data API | 1절 |
|
||||
| operations morning | 데이터 API가 예전 판 → 1절 `--force-recreate` |
|
||||
| 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 "지금 괜찮아요?"
|
||||
|
||||
72~78일차에 운영 데이터를 많이 남겼습니다: 실행 기록 · 알림 · DLQ · 품질 기록 · 사용량 · 릴리스. 그런데 아침에 "지금 괜찮나?"에 답하려면 여섯 곳을 열어야 합니다. 오늘은 그것을 **한 번에 묻고 답하는** 운영 도우미를 만듭니다. `flow.py morning`을 보고 가장 먼저 볼 것 하나를 골라 오세요.
|
||||
|
||||
### 3.2 용어
|
||||
|
||||
| 용어 | 한 줄 설명 |
|
||||
| --- | --- |
|
||||
| 운영 사실 | 여러 출처를 정해진 정의로 모은 하나의 JSON (숫자는 Code가) |
|
||||
| 영역 상태 | 영역마다 🔴 · 🟡 · 🟢 (규칙으로) |
|
||||
| 라우터 | 질문을 보고 어느 영역의 사실을 쓸지 고르는 곳 |
|
||||
| 골든 질문 | 정답(영역 · 숫자)을 알고 있는 질문 — 도우미를 시험하는 데 씀 |
|
||||
| 평가 관문 | 골든 질문 점수가 기준(0.9)보다 낮으면 실패 · 알림 |
|
||||
| 감사 기록 | 질문마다 영역 · 거절 이유를 남기는 한 줄 |
|
||||
|
||||
## 4. 당일 준비물
|
||||
|
||||
- 충전된 노트북과 충전기, WSL의 Docker, Windows Terminal(WSL) 창 **두 개**, 웹 브라우저
|
||||
- 77 · 78일차 `~/vibe/tlog` · `~/vibe/tcheck` (7교시 `tops`에서 부품으로 부름, 없어도 됨)
|
||||
|
||||
## 확인
|
||||
|
||||
- [ ] `curl -s localhost:8800/ops/seed-info`에 `"alerts": 6`
|
||||
- [ ] `flow.py morning`이 알림 · DLQ · 예산 · 카나리를 보여 줌
|
||||
- [ ] `base-ops-facts` · `base-ops-ask` 게시
|
||||
- [ ] `uv run tools/flow.py doctor` → 마지막 줄 `ready`
|
||||
@@ -0,0 +1,269 @@
|
||||
# 1단계 · 운영 사실
|
||||
|
||||
- 교시: 1교시 강의 (09:00~09:50) · 2교시 [Lab 01](../../Last3Mon/79/LAB-01-Q-OPS-FACTS.md) 실습 5개 (10:00~10:50)
|
||||
- 이 단계가 끝나면: 운영 담당자가 아침에 묻는 것을 영역 여섯으로 나눠 말하고, 흩어진 출처를 **정의가 정해진 사실 하나**로 모으고, 기간에 따르는 숫자와 "지금" 숫자를 나누고, 0(없었음)과 `null`(모름)을 구분하고, 정해진 기준으로 영역마다 색을 매기고, 출처 하나가 멈춰도 나머지 사실을 내놓을 수 있다.
|
||||
- 숫자: 모두 강사 노트북 실측입니다 (65일차 n8n 2.42.6, 79일차 판 데이터 API — 2026-11-04 08:30 운영 아침 상태, 실행 기록 666건, 11/01 실습을 5개로 늘린 뒤 정답 워크플로우를 학생 순서대로 1회). 사실 · 상태는 Code라 누가 돌려도 같습니다. 출력 전부는 수업 뒤 공개되는 `Last3Mon/79/answers/LAB-TEST-RESULT.md`에 있습니다.
|
||||
- 실습 가리키기: 이 문서에서 "Lab 01 예제 1"은 2교시 [Lab 01 문서](../../Last3Mon/79/LAB-01-Q-OPS-FACTS.md)의 그 절입니다. 파일 경로(`cases/` · `requests/` · `my-work/` · `reference/`)는 실습 폴더 `~/aio-01d4-stu/Last3Mon/79` 기준입니다.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A["1. 운영 도우미"] --> B["2. 출처 여섯 ·<br/>없는 칸"] --> C["3. 사실 하나로"] --> D["4. 기간과 지금 ·<br/>0과 null"] --> E["5. 상태는 규칙으로"]
|
||||
E --> F["6. 출처가 멈추면"] --> G["7. 요청문으로"]
|
||||
```
|
||||
|
||||
## 0. 이 시간 (50분)
|
||||
|
||||
| 시간 | 절 · 개요 | 하는 일 |
|
||||
| --- | --- | --- |
|
||||
| 09:00~09:06 | 개요 1~6장 | 오늘 하루, 수요일 아침 08:30, 실습 15개 |
|
||||
| 09:06~09:13 | 1 · 개요 7장 | 운영 도우미가 하는 일 · 하지 않는 일 |
|
||||
| 09:13~09:20 | 2 · 개요 8~9장 | 출처 여섯, 기준 대시보드의 없는 칸 |
|
||||
| 09:20~09:28 | 3 · 개요 10장 | 사실 하나로 — 정의는 다시 만들지 않는다 |
|
||||
| 09:28~09:34 | 4 · 개요 11장 | 기간과 지금, 0과 `null` |
|
||||
| 09:34~09:43 | 5 · 6 · 개요 12~14장 | 상태는 규칙으로, 출처가 멈추면 |
|
||||
| 09:43~09:50 | 7 · 8 · 확인 질문 | 요청문, 자주 하는 실수 |
|
||||
|
||||
### 2교시 Lab 01에서 이어서 하는 것
|
||||
|
||||
| 2교시 실습 (시각) | 이 강의의 절 | 실습에서 하는 일 | 쓰는 파일 · 명령 |
|
||||
| --- | --- | --- | --- |
|
||||
| 시작 (10:00) | — | 운영 도우미 설계표 복사 | `cp templates/OPS-ASSISTANT-TEMPLATE.md my-work/OPS.md` (오늘의 사실 · 기준 · 거절을 모두 여기에) |
|
||||
| Lab 01 예제 1 (10:00~10:10, 에이전트 없이) | 1 · 2 | 출처를 `morning`으로 둘러보고 기준 대시보드와 비교 | `morning`, `call base-ops-facts requests/week2.json` → `OPS.md` 1절 |
|
||||
| Lab 01 예제 2 (10:10~10:25) | 3 | 운영 사실 `my-ops-facts` | `my-work/ops-facts.json` (새로), 테스트 `cases/lab01.json` (전: `--webhook base-ops-facts`) |
|
||||
| Lab 01 예제 3 (10:25~10:32, 에이전트 없이) | 4 | 기간을 바꾸면 | `test cases/lab01-period.json -v` → `OPS.md` 2절 |
|
||||
| Lab 01 과제 1 (10:32~10:42) | 5 | 영역별 상태 | 테스트 `cases/lab01-challenge.json` → `OPS.md` 3절 |
|
||||
| Lab 01 과제 2 (10:42~10:50) | 6 | 출처가 멈추면 | 테스트 `cases/lab01-challenge2.json` (사용량 출처를 멈춤) |
|
||||
|
||||
## 1. 운영 도우미: 아침 08:30에 묻는 것 (2교시 Lab 01 예제 1)
|
||||
|
||||
### 일반 설명
|
||||
|
||||
> **생활 속 예 · 병원 아침 인수인계.** 아침 8시 반, 밤 근무 간호사가 낮 근무에게 병동을 넘깁니다. "열이 오른 환자 둘, 수액이 끝나 가는 환자 하나, 검사 결과를 기다리는 환자 셋." 차트 열두 개를 처음부터 다 읽지 않고, **정해진 항목**을 **정해진 순서**로 말합니다. 넘겨받는 사람은 "지금 괜찮나? 무엇부터 볼까?"만 알면 됩니다. 오늘 만드는 운영 도우미가 이 인수인계입니다.
|
||||
|
||||
**운영 도우미(operations assistant)는 "지금 괜찮나? 무엇부터 볼까?"에 답하는 프로그램입니다.** 서비스를 운영하면 정보가 여러 곳에 흩어집니다 — 실행 기록, 울린 알림, 처리하지 못하고 쌓인 일, 데이터 품질, 쓴 비용, 지금 나가 있는 판(버전). 운영 담당자는 아침마다 이것을 하나씩 열어 봅니다. 업계에서는 이것을 한 화면 · 한 대화로 모으는 일을 이렇게 부릅니다.
|
||||
|
||||
| 이름 | 하는 일 | 예 |
|
||||
| --- | --- | --- |
|
||||
| 운영 대시보드 | 숫자 · 색을 한 화면에 | Grafana, Datadog 대시보드 |
|
||||
| ChatOps | 대화창에서 운영 상태를 묻고 답을 받음 | Slack 봇, PagerDuty · Opsgenie의 Slack 연동 |
|
||||
| AIOps | 운영 데이터에 AI(이상 탐지 · 요약 · 분류)를 씀 | Datadog Bits AI, Dynatrace Davis |
|
||||
| 아침 브리핑 · 스탠드업 리포트 | 정해진 시간에 먼저 볼 것을 정리 | 당번 인수인계 문서 |
|
||||
|
||||
원칙은 하나입니다: **숫자 · 상태는 Code(프로그램)가, 글은 LLM이, 작업은 사람이.** 숫자를 세고 색을 정하는 일은 언제나 같은 답이 나와야 해서 프로그램이 하고, 사람이 읽기 좋은 문장만 LLM이 씁니다. 그리고 운영 도우미는 **읽기만** 합니다. 실패한 일을 다시 돌리거나, 새 판을 끄거나, 예산을 바꾸는 **작업**은 사람이 **런북**(runbook, "이런 일이 생기면 이렇게 한다"를 미리 적어 둔 작업 안내서)대로 합니다 (2단계).
|
||||
|
||||
### 오늘 실습에서
|
||||
|
||||
`uv run tools/flow.py morning`으로 본 2026-11-04 08:30 (Lab 01 예제 1):
|
||||
|
||||
| 출처 | 지금 | 남긴 날 |
|
||||
| --- | --- | --- |
|
||||
| 알림 | 6건 (높음 3): FAQ timeout · 429 · B-1 거절 · 낮은 점수 둘 · 접수 API 503 | 76 · 77 · 78일차 |
|
||||
| DLQ | 3건, **parked 2** | 76일차 |
|
||||
| 품질 기록 · 격리함 | 4줄 (점수 0 · 0.8 · 0.8333 · 1) · 격리 1 | 78일차 |
|
||||
| 사용량 · 예산 | $0.073604 / $0.08 (약 92%) | 75일차 |
|
||||
| 릴리스 | 1.1.0 + **카나리 1.2.0 20%** | 74일차 |
|
||||
| 실행 기록 | 666건 (10/19~10/30) | 77일차 |
|
||||
|
||||
## 2. 출처 여섯과 기준 대시보드: 없는 칸이 가장 위험하다 (2교시 Lab 01 예제 1)
|
||||
|
||||
### 일반 설명
|
||||
|
||||
> **생활 속 예 · 체온만 적힌 인수인계 메모.** 밤 근무가 "모두 체온 정상"이라고만 적어 두었습니다. 거짓은 없습니다. 그런데 메모에 "수액" 칸이 없어서, 수액이 끝난 환자가 있다는 것을 낮 근무는 모릅니다. 틀린 숫자는 누군가 고치지만, **없는 칸**은 아무도 묻지 않습니다.
|
||||
|
||||
**대시보드의 실수는 두 가지입니다: 틀린 숫자와 없는 칸.** 틀린 숫자는 누군가 "이상한데?" 하고 알아챕니다. 없는 칸은 "그 영역은 괜찮다"처럼 보입니다. 그래서 운영 도우미를 만들 때는 먼저 **무엇을 물어야 하는지**(영역)를 정합니다.
|
||||
|
||||
| 영역 | 묻는 것 | 빠지면 |
|
||||
| --- | --- | --- |
|
||||
| 실행 | 오류가 늘었나, 느려졌나, 답을 못 하나 | 장애를 사용자가 먼저 앎 |
|
||||
| 알림 | 무엇이 울렸나, 얼마나 급한가 | 높은 알림이 묻힘 |
|
||||
| DLQ (처리하지 못한 일을 모아 두는 곳) | 사람이 볼 일이 남았나 | 접수 건이 사라짐 (76일차) |
|
||||
| 품질 | 들어온 데이터를 믿을 수 있나 | 틀린 FAQ로 답함 (78일차) |
|
||||
| 비용 | 한도 안인가, 누가 쓰나 | 오후에 서비스가 멈춤 (75일차) |
|
||||
| 릴리스 | 지금 무슨 판(버전)이 나가나, 새 판은 괜찮나 | 일부 사용자에게 먼저 내보낸 새 판(카나리)이 나쁜데 계속 나감 (74일차) |
|
||||
|
||||
Google SRE의 "네 가지 황금 신호"(지연 · 트래픽 · 오류 · 포화)가 서비스 하나의 영역이라면, 오늘의 여섯은 **AI 워크플로우 운영**의 영역입니다 — 품질 · 비용 · 릴리스가 더해집니다.
|
||||
|
||||
### 오늘 실습에서
|
||||
|
||||
팀의 기준 대시보드(`base-ops-facts`)에 지난주를 물으면 (Lab 01 예제 1):
|
||||
|
||||
| 출처 | `morning` | 기준 대시보드 |
|
||||
| --- | --- | --- |
|
||||
| 실행 | (지난주 357건) | **666건** · 오류율 3.153153… (기간 무시 · 백분율) |
|
||||
| 알림 · DLQ | 6 · 높음 3, 3 · parked 2 | 6, 3 (높음 · parked 없음) |
|
||||
| 품질 · 릴리스 | 4줄 · 격리 1, 카나리 1.2.0 20% | **칸 없음** |
|
||||
|
||||
- 기준만 보는 사람은 오늘 가장 급한 둘(**parked 2건 · 카나리**)을 모릅니다.
|
||||
|
||||
## 3. 사실 하나로: 정의는 다시 만들지 않는다 (2교시 Lab 01 예제 2)
|
||||
|
||||
### 일반 설명
|
||||
|
||||
> **생활 속 예 · 병원 공용 차트 양식.** 간호사마다 자기 공책에 "고열"을 다르게 적으면(37.5도? 38도?) 인수인계 때마다 다툽니다. 병원은 그래서 차트 양식 하나에 "고열 = 38도 이상"을 박아 두고 모두 그것을 씁니다. 새 화면을 만들 때도 양식을 새로 쓰지 않고 그 차트를 읽습니다.
|
||||
|
||||
**운영 사실(facts)은 여섯 출처를 정해진 정의로 모은 JSON 하나입니다.** 다음 단계(질문 답변 · 브리핑 · 평가 · 터미널 도구)는 모두 이 사실만 읽습니다. 정의가 사실 한 곳에 있으면, 질문 답변이 말하는 오류율과 브리핑 표의 오류율이 **같습니다.** 업계에서는 지표의 정의를 한 곳에 두는 층을 **시맨틱 레이어**(semantic layer, metrics layer — dbt Semantic Layer · Cube · LookML)라고 부릅니다.
|
||||
|
||||
| 원칙 | 까닭 |
|
||||
| --- | --- |
|
||||
| 77일차 정의 그대로 (오류율 · p95 · 답 못 함) | 정의가 두 벌이면 같은 날 다른 숫자 (77일차에 겪음) |
|
||||
| 비율은 0~1, 소수 4자리 | 백분율(3.15)과 비율(0.0315)을 섞으면 기준(0.01)과 비교가 틀림 |
|
||||
| 계산은 Code 하나 | LLM은 숫자를 세지 않음 — 세는 순간 날마다 달라짐 |
|
||||
| 출처는 읽기만 | 사실을 만드는 데 상태를 바꿀 까닭이 없음 |
|
||||
|
||||
### 오늘 실습에서
|
||||
|
||||
내 `my-ops-facts`의 지난주 (Lab 01 예제 2, `lab01` 5/5):
|
||||
|
||||
| 영역 | 사실 |
|
||||
| --- | --- |
|
||||
| 실행 | 357건 · 오류 21 · 0.0588 · p95 2598ms · 답 못 함 0.0476 · 실패 1위 `Search FAQ` timeout 16 |
|
||||
| 알림 · DLQ | 6 · 높음 3 · 이유별, 3 · parked 2 · 대기 1 |
|
||||
| 품질 | 4배치 · 평균 0.6583 · 마지막 1 · 거절 1 · 격리 1 |
|
||||
| 비용 | 156요청 · 192호출 · $0.073604 / $0.08 = 0.9201 · 1위 `test-bot` 37% |
|
||||
| 릴리스 | 1.1.0 · 카나리 1.2.0 20% · 다시 묻기 **7.73% 대 62.5%** |
|
||||
|
||||
- 357 · 0.0588 · 2598 · 16은 77일차 `my-log-report`의 둘째 주와 **같은 숫자**입니다. 출처 여덟을 읽어 Code 하나에서 0.1초.
|
||||
|
||||
## 4. 기간과 지금: 0과 `null`은 다르다 (2교시 Lab 01 예제 3)
|
||||
|
||||
### 일반 설명
|
||||
|
||||
> **생활 속 예 · "어젯밤 몇 번 열이 났나"와 "지금 체온".** 인수인계에는 두 가지 시간이 섞입니다. "밤새 열이 두 번" — 기간의 숫자. "지금 37.2도" — 지금의 숫자. 그리고 "어젯밤 소변량은 재지 않았음"은 "소변 0"과 전혀 다릅니다. 0이라고 적으면 큰일 납니다.
|
||||
|
||||
**숫자에는 시간의 종류가 있습니다.**
|
||||
|
||||
| 종류 | 뜻 | 흔한 예 |
|
||||
| --- | --- | --- |
|
||||
| 기간(window) 숫자 | 정한 기간에 일어난 일의 합 · 비율 | 지난주 주문 수, 지난달 오류율 |
|
||||
| 지금(point-in-time) 숫자 | 바로 이 순간의 상태 | 지금 쌓여 있는 문의 수, 지금 남은 예산 |
|
||||
|
||||
기간을 바꾸면 **기간 숫자만** 바뀌어야 합니다. "지난달을 보여 줘"라고 했는데 지금 쌓인 문의 수까지 지난달 값으로 바뀐다면 정의가 섞인 것입니다. 보고할 때도 "실행은 지난주, 나머지는 오늘 아침 지금"처럼 두 시간을 나눠 말합니다.
|
||||
|
||||
그리고 **"없었다"와 "모른다"를 나눕니다.**
|
||||
|
||||
| 값 | 뜻 | 예 |
|
||||
| --- | --- | --- |
|
||||
| 0 | 셀 것이 있었고, 그 결과가 0 | 주문이 0건인 날의 오류율 = 0 |
|
||||
| `null` (값 없음) | 셀 수 없었다 · 말할 수 없다 | 주문이 0건인 날의 "가장 많이 실패한 상품", 그 판이 한 번도 쓰이지 않은 날의 그 판 오류율 |
|
||||
|
||||
`null`을 0으로 바꾸면 "모른다"가 "좋다"로 보입니다. 다음 절의 색 판정에서 바로 문제가 됩니다. 데이터베이스의 `NULL`, 통계의 결측값(missing value)과 같은 생각입니다.
|
||||
|
||||
### 오늘 실습에서
|
||||
|
||||
같은 사실에 기간 넷 (Lab 01 예제 3, 5/5):
|
||||
|
||||
| 기간 | 실행 | 다시 묻는 비율 (1.1.0 · 1.2.0) | 지금 숫자 |
|
||||
| --- | --- | --- | --- |
|
||||
| 두 주 | 666 · 0.0315 | 7.73% · 62.5% | 그대로 |
|
||||
| 하루 (10/26) | 70 · 0.2286 | **`null` · `null`** — 두 판은 10/28부터 | 그대로 |
|
||||
| 빈 주 (11/02~) | 0 · 오류율 0 · p95 0 · 실패 1위 `null` | `null` · `null` | 그대로 |
|
||||
| 기간 없음 | 357 (지난주) | 7.73% · 62.5% | 그대로 |
|
||||
|
||||
## 5. 상태는 규칙으로: 숫자에 색을 매기기 (2교시 Lab 01 과제 1)
|
||||
|
||||
### 일반 설명
|
||||
|
||||
> **생활 속 예 · 병동 현황판의 빨강 · 노랑 자석.** 현황판에 환자마다 색 자석을 붙입니다. 빨강은 "지금 가서 봐야 함", 노랑은 "오늘 안에 봐야 함". 색은 간호사의 기분이 아니라 **기준표**로 붙입니다 — "체온 38.5도 이상이면 빨강". 그래야 누가 붙여도 같은 색입니다.
|
||||
|
||||
**상태(health)는 숫자에 정해진 기준을 대어 영역마다 색을 매긴 것입니다.** 업계에서는 RAG 상태(Red · Amber · Green), 헬스 체크(health check), SLO 판정(77일차)이라고 부릅니다. 사람이 숫자 여섯 개를 보고 매번 "괜찮은가"를 따지지 않아도, 색만 보면 무엇부터 볼지 알 수 있습니다.
|
||||
|
||||
| 색 | 뜻 | 기준을 정하는 법 (예) |
|
||||
| --- | --- | --- |
|
||||
| 🔴 빨강 | 지금 가서 봐야 함 | 약속(SLO)을 어김, 사람이 처리해야 할 일이 남음 |
|
||||
| 🟡 노랑 | 오늘 안에 봐야 함 | 약속에 가까워짐, 지켜볼 일이 생김 |
|
||||
| 🟢 초록 | 괜찮음 | 위 기준에 하나도 걸리지 않음 |
|
||||
|
||||
기준은 숫자의 **뜻**에서 나옵니다: 오류율은 팀이 정한 SLO, 비용은 예산의 몇 %, 쌓인 일은 "사람이 볼 일이 남았나". 그리고 기준표를 **프로그램이** 적용해야 누가 봐도 같은 색이 나옵니다. LLM에게 "괜찮은지 판단해 줘"라고 하면 같은 숫자에 날마다 다른 색이 나올 수 있습니다.
|
||||
|
||||
색은 숫자를 바꾸지 않습니다. 같은 숫자에 **기준**을 댄 것입니다. 그리고 비교할 수 없으면(앞 절의 `null`) 빨강이라 하지 않고 노랑으로 둡니다 — "모르니 지켜보자".
|
||||
|
||||
### 오늘 실습에서
|
||||
|
||||
지난주 사실의 상태 (Lab 01 과제 1, 5/5):
|
||||
|
||||
| 🔴 red | 🟡 yellow | 전체 |
|
||||
| --- | --- | --- |
|
||||
| runs (0.0588) · dlq (parked 2) · release (62.5% > 2 × 7.73%) | alerts · quality (격리 1) · cost (0.9201) | 🔴 |
|
||||
|
||||
- 첫 주: 오류 0이지만 답 못 함 5.5% → runs 🟡, 카나리 비율 `null` → release 🟡 (비교 불가). 예산을 $1로 올리면 비용 🟢, parked 둘을 처리하면 DLQ 🟡.
|
||||
|
||||
## 6. 출처가 멈추면: 부분 실패를 견디기 (2교시 Lab 01 과제 2)
|
||||
|
||||
### 일반 설명
|
||||
|
||||
> **생활 속 예 · 검사실 전화가 안 될 때.** 아침에 검사실 전화가 먹통이라 혈액 검사 결과를 못 받았습니다. 그렇다고 인수인계 전체를 미루지 않습니다. 체온 · 수액 · 투약은 그대로 넘기고, "검사 결과: **받지 못함**"이라고 적습니다. "검사 결과 정상"이라고 적으면 안 됩니다.
|
||||
|
||||
**출처 하나의 실패가 전체를 멈추게 두지 않습니다.** 정보를 여섯 곳에서 모으면, 언젠가는 그중 한 곳이 응답하지 않는 날이 옵니다. 분산 시스템에서는 이것을 **부분 실패**(partial failure)라고 부르고, 일부가 멈춰도 나머지 기능은 계속 주는 설계를 **우아한 저하**(graceful degradation)라고 부릅니다. 원칙은 셋입니다.
|
||||
|
||||
| 원칙 | 하는 일 | 하지 않으면 |
|
||||
| --- | --- | --- |
|
||||
| 나머지는 그대로 | 출처마다 실패를 따로 받아, 하나가 실패해도 다음 단계로 넘어감 | 한 곳 때문에 전체가 오류로 끝나 숫자가 하나도 없음 |
|
||||
| 모르는 것은 모른다고 | 그 영역의 값은 "값 없음", 상태는 "모름", 어느 출처가 멈췄는지 적음 | 0으로 적어 초록으로 보임 |
|
||||
| 전체는 좋게 말하지 않음 | 빨강이 없어도 "모름"이 하나라도 있으면 적어도 노랑 | 실제로는 위험한데 "모두 초록" |
|
||||
|
||||
이 셋을 지키면 대시보드를 보는 사람은 "무엇은 괜찮고, 무엇은 지금 확인할 수 없는지"를 정확히 압니다.
|
||||
|
||||
### 오늘 실습에서
|
||||
|
||||
테스트가 사용량 출처를 멈추고(`fault usage error`) 부르면 (Lab 01 과제 2):
|
||||
|
||||
| | 고치기 전 | 고친 뒤 |
|
||||
| --- | --- | --- |
|
||||
| 응답 | **500** — 다섯 영역의 사실도 없음 | 200 · `cost: null` · `sources_down: ["cost"]` |
|
||||
| 상태 | — | `health.cost: "unknown"`, 빨강 셋 그대로 · 전체 🔴 |
|
||||
| 출처가 돌아오면 | — | `[]` · 비용 🟡 0.9201 |
|
||||
|
||||
- 비용을 0으로 적었다면 🟢(예산의 0%)였을 것입니다. 실제로는 92%를 썼습니다.
|
||||
|
||||
## 7. 요청문(프롬프트)으로 에이전트에게 맡기기
|
||||
|
||||
사실 요청문은 "운영 대시보드 만들어 줘"가 아니라 **정의**를 적습니다 (AGENTS.md 1절: 에이전트는 먼저 "어느 출처의 무엇을 어떻게 세는지"를 표로 보여 줌).
|
||||
|
||||
| 넣을 것 | 예 |
|
||||
| --- | --- |
|
||||
| 파일 · 웹훅 · 이름 | "`my-work/ops-facts.json`, 웹훅 `my-ops-facts`, 이름 `79 Ops facts (my)`" |
|
||||
| 기간 | "`from` · `to`를 `/logs/query`에, 비면 2026-10-26 ~ 2026-10-30, 기간은 실행 기록에만" |
|
||||
| 정의 | "AGENTS.md 3절 사실 표 그대로, 실행은 77일차 정의, 비율은 0~1 소수 4자리" |
|
||||
| 0과 `null` | "0건이면 비율 · p95는 0, 실패 1위 · 다시 묻는 비율은 null" |
|
||||
| 하지 않을 것 | "LLM은 쓰지 않는다, 상태를 바꾸는 요청을 보내지 않는다" |
|
||||
| 기대 결과 | "`cases/lab01.json`, 앞의 테스트도 그대로" |
|
||||
|
||||
## 8. 자주 하는 실수
|
||||
|
||||
| 실수 | 결과 | 바로잡기 |
|
||||
| --- | --- | --- |
|
||||
| "대시보드 만들어 줘"만 씀 | 에이전트가 고른 칸만 (기준처럼) | 영역 여섯과 정의를 요청문에 |
|
||||
| 기간을 데이터 API에 안 넘김 | 무엇을 물어도 666건 | `from` · `to`를 그대로 |
|
||||
| 오류율을 백분율로 | 3.15 > 0.01 → 언제나 빨강 | 비율 0~1 |
|
||||
| 지금 숫자에도 기간을 댐 | 빈 주에 알림 0 | 기간은 실행 기록에만 |
|
||||
| `null`을 0으로 | 모르는데 🟢 | `null` 그대로, 상태는 비교 불가 |
|
||||
| 색을 LLM에게 정하게 | 같은 사실에 날마다 다른 색 | 기준표를 Code로 |
|
||||
| 출처 하나의 오류를 그대로 둠 | 사실 전체가 500 | `neverError` + 응답 모양으로 판단 |
|
||||
| 사실을 만들며 상태를 바꿈 | 볼 때마다 아침이 달라짐 | 읽는 요청만 |
|
||||
|
||||
## 확인 질문
|
||||
|
||||
<details><summary>1. 기준 대시보드는 숫자를 하나도 "틀리게" 계산하지 않았는데도 위험하다고 했습니다. 왜인가요?</summary>
|
||||
|
||||
계산이 맞아도 **칸이 없으면** 그 영역은 "괜찮다"처럼 보입니다. 기준에는 parked · 품질 · 릴리스 칸이 없어, 오늘 가장 급한 parked 2건과 카나리 1.2.0을 모릅니다. 대시보드를 만들 때 먼저 정하는 것은 계산이 아니라 **무엇을 물어야 하는가**(영역)입니다. (실행 666건은 기간을 무시한 것이라 지난주를 물은 사람에게는 틀린 답이기도 합니다.)
|
||||
</details>
|
||||
|
||||
<details><summary>2. 오늘 사실의 실행 숫자(357 · 0.0588 · 2598)가 77일차 숫자와 같다는 것이 왜 중요한가요?</summary>
|
||||
|
||||
정의를 다시 만들지 않았다는 증거입니다. 오늘 오류율을 새로 정의했다면 77일차 보고서와 오늘 도우미가 같은 주에 다른 오류율을 말했을 것입니다. 사실 한 곳에 정의를 두면 질문 답변 · 브리핑 · 터미널 도구가 모두 같은 숫자를 말합니다 (시맨틱 레이어).
|
||||
</details>
|
||||
|
||||
<details><summary>3. 빈 주에 오류율은 0인데 실패 1위는 `null`입니다. 둘 다 "없다"인데 왜 다르게 두나요?</summary>
|
||||
|
||||
오류율은 "실행 0건 중 오류 0건"이라 0이라고 말할 수 있습니다 (정의로 정함). 실패 1위는 셀 것이 없어 **말할 수 없습니다.** `null`로 두면 상태 판정이 "비교 불가 → 노랑"으로 갈 수 있고, 0이나 빈 문자열로 두면 "실패 없음 → 초록"으로 읽힙니다.
|
||||
</details>
|
||||
|
||||
<details><summary>4. 카나리의 다시 묻는 비율이 `null`이면 릴리스를 왜 빨강이 아니라 노랑으로 두나요?</summary>
|
||||
|
||||
빨강은 "카나리가 두 배 넘게 나쁘다"는 **증거**가 있을 때입니다. 비율이 없으면 증거도 없습니다. 그렇다고 초록도 아닙니다 — 카나리는 켜져 있고 아직 모릅니다. "켜져 있으니 지켜보자"가 노랑입니다.
|
||||
</details>
|
||||
|
||||
<details><summary>5. 사용량 출처가 멈췄을 때 비용을 0으로 두면 무엇이 문제인가요? 전체 상태는 어떻게 되어야 하나요?</summary>
|
||||
|
||||
비용 0 → 예산의 0% → 🟢로 보입니다. 실제로는 92%를 썼습니다. 모르는 것을 좋게 말하는 대시보드가 가장 위험합니다. 비용은 `null` · `unknown`으로 두고 `sources_down`에 적습니다. 전체는 빨강이 있으면 red, 없더라도 `unknown`이 있으면 적어도 yellow — "모두 초록"이라고 말하지 않습니다.
|
||||
</details>
|
||||
@@ -0,0 +1,247 @@
|
||||
# 2단계 · 질문 답변
|
||||
|
||||
- 교시: 3교시 강의 (11:00~11:50) · 4교시 [Lab 02](../../Last3Mon/79/LAB-02-Q-OPS-ASK.md) 실습 5개 (12:00~12:50)
|
||||
- 이 단계가 끝나면: 질문을 영역 하나로 고르고(라우터), 그 영역의 사실만 LLM에게 주어 답하게 하고, 운영 밖 질문과 작업 요청을 LLM 앞에서 거절하고, 답의 숫자가 사실에 있는지 Code로 확인하고, 낱말이 모르는 질문에만 LLM 라우터를 쓰고, 질문마다 감사 기록을 남길 수 있다.
|
||||
- 숫자: 모두 강사 노트북 실측입니다 (79일차 판 데이터 API, OpenAI `gpt-4.1-mini` · temperature 0, 11/01 정답 워크플로우 1회). 영역 · 거절 · 숫자 확인은 규칙이라 같고, LLM이 쓴 답 글은 실행마다 조금씩 다를 수 있습니다.
|
||||
- 실습 가리키기: 이 문서에서 "Lab 02 예제 1"은 4교시 [Lab 02 문서](../../Last3Mon/79/LAB-02-Q-OPS-ASK.md)의 그 절입니다.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A["1. 챗봇의 세 실수"] --> B["2. 라우터 ·<br/>그 영역만"] --> C["3. 거절은<br/>LLM 앞에서"] --> D["4. 숫자 확인"] --> E["5. 질문을 바꾸면"]
|
||||
E --> F["6. LLM 라우터"] --> G["7. 감사 기록"] --> H["8. 요청문으로"]
|
||||
```
|
||||
|
||||
## 0. 이 시간 (50분)
|
||||
|
||||
| 시간 | 절 · 개요 | 하는 일 |
|
||||
| --- | --- | --- |
|
||||
| 11:00~11:07 | 1 · 개요 15장 | 기준 챗봇의 세 실수 |
|
||||
| 11:07~11:15 | 2 · 개요 16장 | 라우터 · 그 영역의 사실만 |
|
||||
| 11:15~11:23 | 3 · 개요 17장 | 거절은 LLM 앞에서 — 읽기만 |
|
||||
| 11:23~11:30 | 4 · 개요 18장 | 숫자 확인과 그 한계 |
|
||||
| 11:30~11:38 | 5 · 6 · 개요 19~20장 | 질문을 바꾸면, LLM 라우터 |
|
||||
| 11:38~11:43 | 7 · 개요 21장 | 감사 기록 |
|
||||
| 11:43~11:50 | 8 · 9 · 확인 질문 | 요청문, 자주 하는 실수 |
|
||||
|
||||
### 4교시 Lab 02에서 이어서 하는 것
|
||||
|
||||
| 4교시 실습 (시각) | 이 강의의 절 | 실습에서 하는 일 | 쓰는 파일 · 명령 |
|
||||
| --- | --- | --- | --- |
|
||||
| Lab 02 예제 1 (12:00~12:12) | 1 · 2 | 낱말 라우터 · 그 영역 사실 · 운영 밖 거절 | `my-work/ops-ask.json` (새로), 테스트 `cases/lab02.json` (전: `--webhook base-ops-ask`) |
|
||||
| Lab 02 예제 2 (12:12~12:22) | 3 · 4 | 작업 요청 거절 · 숫자 확인 | 같은 파일, `lab02` 6/6 → `OPS.md` 4절 |
|
||||
| Lab 02 예제 3 (12:22~12:28, 에이전트 없이) | 5 | 질문을 바꾸면 | `test cases/lab02-phrasing.json -v` → `OPS.md` 5절 |
|
||||
| Lab 02 과제 1 (12:28~12:40) | 6 | LLM 라우터 | 테스트 `cases/lab02-challenge.json`, `lab02-phrasing` 다시 |
|
||||
| Lab 02 과제 2 (12:40~12:50) | 7 | 감사 기록 | 테스트 `cases/lab02-challenge2.json` → `OPS.md` 6절 |
|
||||
|
||||
## 1. 기준 챗봇의 세 실수 (4교시 Lab 02 예제 1)
|
||||
|
||||
### 일반 설명
|
||||
|
||||
> **생활 속 예 · 무엇이든 대답하는 새내기 간호사.** 의욕 넘치는 새내기가 간호사실 전화를 받습니다. 보호자가 "근처 맛집 있어요?" 하면 맛집을 알려 주고, "우리 아버지 약 좀 바꿔 주세요" 하면 "네, 바꿔 드릴게요"라고 합니다. 바꿀 권한도 없는데요. 질문마다 차트 전체를 읽어 주느라 정작 물은 것은 묻힙니다.
|
||||
|
||||
**사실 전부를 LLM에게 주고 "무엇이든 답해"라고 하면** 그럴듯한 답이 나옵니다. 그러나 운영 도우미로는 세 가지가 위험합니다.
|
||||
|
||||
| 실수 | 왜 위험한가 |
|
||||
| --- | --- |
|
||||
| 운영 밖 질문에 답함 | 사람들이 무엇이든 물어도 되는 줄 앎, 비용 · 책임 |
|
||||
| **작업을 한 것처럼** 답함 | "다시 실행해 드리겠습니다" — 아무것도 안 했는데 운영자는 된 줄 앎 |
|
||||
| 물은 것 밖의 숫자를 섞음 | 카나리 질문에 오류율을 섞어 원인을 잘못 짚음 |
|
||||
|
||||
업계의 RAG 챗봇에서도 같은 문제를 범위 제한(scope) · 가드레일(guardrails, 예: NeMo Guardrails · Guardrails AI) · 근거 제한(grounding)으로 다룹니다. 오늘은 이것을 **워크플로우의 갈래**로 만듭니다.
|
||||
|
||||
### 오늘 실습에서
|
||||
|
||||
기준 챗봇(`base-ops-ask`)에 같은 테스트 (Lab 02 예제 1, **0/6**):
|
||||
|
||||
| 질문 | 기준의 답 |
|
||||
| --- | --- |
|
||||
| 점심 메뉴 추천해 줘 | "김치찌개, 불고기, 비빔밥 중에서 …" |
|
||||
| DLQ 1번 다시 돌려 줘 | "**DLQ 1번 작업을 다시 실행해 드리겠습니다.** 잠시만 기다려 주세요." |
|
||||
| 카나리 버전 문제 있어? | "… 오류율은 약 5.88% … 알림도 6건 … DLQ 상태도 좋지 않고 …" (진짜 숫자 62.5%는 없음) |
|
||||
|
||||
## 2. 라우터: 질문을 영역 하나로, 사실은 그 영역만 (4교시 Lab 02 예제 1)
|
||||
|
||||
### 일반 설명
|
||||
|
||||
> **생활 속 예 · 병원 안내 데스크.** "가슴이 아파요"는 심장내과로, "다리가 부었어요"는 정형외과로 보냅니다. 안내 데스크는 진단하지 않고 **어디로 보낼지**만 정합니다. 그리고 심장내과 의사에게는 정형외과 차트까지 주지 않습니다.
|
||||
|
||||
**라우터(router)는 질문을 영역 하나로 고르는 단계입니다.** 업계에서는 의도 분류(intent classification) · 시맨틱 라우팅(semantic routing)이라고 부릅니다. 고른 뒤에는 **그 영역의 사실만** LLM에게 줍니다.
|
||||
|
||||
| 방식 | 장점 | 단점 |
|
||||
| --- | --- | --- |
|
||||
| 낱말 목록 (Code) | 0초 · 공짜 · 늘 같음 · 왜 그 영역인지 설명됨 | 목록에 없는 말은 모름 |
|
||||
| LLM 분류 | 처음 보는 말도 이해 | 1~3초 · 비용 · 가끔 다름 (6절) |
|
||||
| 임베딩 유사도 | 비슷한 뜻을 찾음 | 기준선 · 예문 관리 (66일차) |
|
||||
|
||||
그 영역 사실만 주는 까닭: 받은 숫자가 적을수록 LLM이 **엉뚱한 숫자를 섞을** 여지가 줄고, 토큰도 줄어듭니다. 답할 수 없으면 "제공된 사실에 없다"고 말하게 됩니다.
|
||||
|
||||
### 오늘 실습에서
|
||||
|
||||
낱말 라우터 + 그 영역 사실 + 운영 밖 거절 (Lab 02 예제 1, `lab02` **3/6**):
|
||||
|
||||
| 질문 | 영역 | 답 |
|
||||
| --- | --- | --- |
|
||||
| 지난주 오류율이 얼마야? | `runs` | "지난주 오류율은 5.88%였습니다. 총 357회 실행 중 21회 …" |
|
||||
| 점심 메뉴 | `unknown` → 거절 | 0.1초, LLM 없음 |
|
||||
| 카나리 버전 문제 있어? | `release` | "… 62.5%로 매우 높으며 … 1.1.0의 7.73%에 비해 …" |
|
||||
| DLQ 1번 다시 돌려 줘 | `dlq` (작업 거절이 아직 없음) | "DLQ 1번은 현재 **대기 중**" — 틀림 (#1은 parked) |
|
||||
|
||||
## 3. 거절은 LLM 앞에서: 읽기만 (4교시 Lab 02 예제 2)
|
||||
|
||||
### 일반 설명
|
||||
|
||||
> **생활 속 예 · 처방은 의사만.** 간호사실 전화로 "약을 바꿔 달라"는 요청이 오면, 간호사는 친절하게 거절하고 **누구에게 말해야 하는지** 알려 줍니다. "의사 선생님께 전해 드릴게요"는 되지만 "바꿔 드릴게요"는 안 됩니다. 이것은 간호사의 성격이 아니라 병원의 **규칙**입니다.
|
||||
|
||||
**하면 안 되는 것은 LLM에게 "하지 마"라고 부탁하지 않고, LLM에게 가기 전에 막습니다.** 지시문에 적은 "작업은 거절하라"는 대부분 지켜지지만 언제나는 아닙니다 (프롬프트 주입, 73일차). 프로그램의 갈래로 막으면 LLM은 그 질문을 **보지도 않습니다.** 업계에서는 이것을 최소 권한(least privilege), 읽기 전용 에이전트, "실행 버튼은 사람이 누른다"(human-in-the-loop)로 설계합니다.
|
||||
|
||||
| 막는 곳 | 확실한가 | 비용 |
|
||||
| --- | --- | --- |
|
||||
| 지시문 ("작업 요청은 거절해") | 대개 — LLM이 따를 때만 | LLM 한 번 |
|
||||
| **LLM 앞의 프로그램 갈래** | 늘 — 정한 낱말이 있으면 | 0초 |
|
||||
| 권한 (작업하는 기능을 아예 주지 않음) | 늘 — 할 수단이 없음 | — |
|
||||
|
||||
세 겹을 함께 쓰는 것이 흔합니다: 작업하는 기능을 주지 않고, 작업을 시키는 말은 프로그램이 먼저 거절하고, 지시문에도 적어 둡니다. 거절할 때는 "안 됩니다"로 끝내지 않고 **다음에 할 일**(누구에게 · 어떤 안내서대로)을 함께 알려 줍니다.
|
||||
|
||||
### 오늘 실습에서
|
||||
|
||||
작업 낱말("다시 돌려 · 재처리해 · 꺼 줘 · 롤백해 …")을 라우터보다 앞에 (Lab 02 예제 2, `lab02` **6/6**): "DLQ 1번 다시 돌려 줘" → `area: "action"` · `refused: true` · `reason: "read_only"` · **0.0초** · "운영 도우미는 읽기만 합니다. 재처리 · 삭제 · 배포 같은 작업은 런북에 따라 담당자가 직접 해 주세요."
|
||||
|
||||
## 4. 숫자 확인: 지어낸 숫자를 잡는다, 뜻은 못 잡는다 (4교시 Lab 02 예제 2)
|
||||
|
||||
### 일반 설명
|
||||
|
||||
> **생활 속 예 · 인수인계 메모를 차트와 맞춰 보기.** 수간호사가 메모의 숫자를 차트와 하나씩 맞춰 봅니다. "체온 39.1" — 차트에 없으면 빨간 펜. 그런데 "2번 환자 39.1"을 "3번 환자 39.1"로 잘못 적은 것은? 숫자는 차트에 있으니 통과합니다. 숫자 맞추기로는 **누구의** 숫자인지까지는 못 봅니다.
|
||||
|
||||
**숫자 확인(numbers check)은 LLM이 쓴 답의 숫자가 모두 받은 자료 안에 있는지 프로그램으로 보는 것입니다.** LLM은 그럴듯한 숫자를 지어낼 수 있습니다(환각). 답의 숫자를 하나씩 자료와 맞춰 보면 이것을 0원 · 0초로 잡을 수 있습니다. 업계에서는 근거 확인(groundedness · faithfulness check, 예: RAGAS faithfulness)의 가장 단순한 형태로 봅니다.
|
||||
|
||||
| 잡는 것 | 못 잡는 것 |
|
||||
| --- | --- |
|
||||
| 자료에 없는 숫자 (지어낸 "7%") | 자료에 있는 숫자를 **다른 뜻**으로 쓴 답 ("A가 3건"을 "B가 3건"으로) |
|
||||
| 계산 실수 (비율 0.92를 "9.2%"로) | 두 숫자를 **서로 바꿔** 쓴 답 ("성공 2 · 실패 1"을 "성공 1 · 실패 2"로) |
|
||||
| | 숫자 없이 틀린 말 ("문제없이 안정적입니다") |
|
||||
|
||||
어떤 형태를 같은 숫자로 볼지(값 그대로 · 백분율로 ×100 · 반올림 · 버전 번호 `1.2.0`은 하나의 값)도 정해 두어야 합니다. 정하지 않으면 맞는 답도 실패로 나옵니다. 그리고 숫자 확인을 통과했다고 답이 **맞다는** 뜻은 아닙니다 — 뜻까지는 평가(3단계)와 사람의 검토로 봅니다.
|
||||
|
||||
### 오늘 실습에서
|
||||
|
||||
비용 답 "… 예산의 92.01% … 0.08달러 … 0.9201" → `numbers_ok: true` (92.01 = 0.9201 × 100). 릴리스 답의 `1.2.0`은 버전으로 통째로 빼고 62.5 = 0.625 × 100 (Lab 02 예제 2). 예제 1의 "#1은 대기 중"은 1이 사실에 있어 **통과** — 숫자 확인의 빈틈입니다. 그래서 작업 요청은 답하지 않고 막습니다.
|
||||
|
||||
## 5. 질문을 바꾸면: 규칙대로 움직인다는 것 (4교시 Lab 02 예제 3)
|
||||
|
||||
### 일반 설명
|
||||
|
||||
> **생활 속 예 · 안내 데스크의 단어장.** 안내 데스크 직원이 단어장을 보고 과를 정합니다. "가슴" → 심장내과. 그런데 "숨이 차요"는 단어장에 없습니다. 똑똑한 척 짐작하지 않고 "어느 과인지 모르겠습니다"라고 하면 불편하지만 **안전**합니다. 엉뚱한 과로 보내는 것보다 낫습니다.
|
||||
|
||||
**규칙 기반 라우터는 규칙대로만 움직입니다.** 테스트가 통과했다는 것은 "규칙대로 움직였다"는 뜻이지 "운영자가 원하는 답"이라는 뜻이 아닙니다. 실패에도 방향이 있습니다.
|
||||
|
||||
| 실패의 방향 | 예 | 결과 |
|
||||
| --- | --- | --- |
|
||||
| 모르면 거절 (보수적) | "장애 났어?" → 거절 | 불편 — 다시 물어야 |
|
||||
| 모르면 짐작 (공격적) | 엉뚱한 영역으로 답 | 위험 — 틀린 답을 믿음 |
|
||||
|
||||
운영 도우미는 보수적인 쪽에서 시작해, 자주 거절되는 질문을 보고 낱말을 더하거나(가장 싸고 확실) LLM 라우터를 붙입니다(6절).
|
||||
|
||||
### 오늘 실습에서
|
||||
|
||||
여섯 가지 말투 (Lab 02 예제 3, 6/6 — 규칙대로):
|
||||
|
||||
| 질문 | 낱말 라우터 | 운영자에게는 |
|
||||
| --- | --- | --- |
|
||||
| 에러 많이 났어? | runs | 좋음 |
|
||||
| 장애 났어? | 거절 | 불편 |
|
||||
| 알림이랑 DLQ 둘 다 | alerts (같으면 앞) → "DLQ 정보는 사실에 없습니다" | 반쪽 (정직하지만) |
|
||||
| 카나리 꺼 줘 | 작업 거절 | 안전 |
|
||||
| 배포 상태 요약해 줘 | overview (상태 · 요약 2 > 배포 1) | 넓음 |
|
||||
| AI 쓰는 데 얼마나 나갔어? | 거절 | 불편 |
|
||||
|
||||
## 6. LLM 라우터: 낱말이 모를 때만 (4교시 Lab 02 과제 1)
|
||||
|
||||
### 일반 설명
|
||||
|
||||
> **생활 속 예 · 단어장에 없으면 선배 간호사에게.** 안내 데스크가 단어장에 없는 말을 들으면 그때만 선배를 부릅니다. 선배는 "숨이 차다면 호흡기내과"라고 알려 줍니다. 모든 질문마다 선배를 부르면 선배가 아무 일도 못 합니다.
|
||||
|
||||
**LLM 라우터는 낱말 라우터가 "모르겠음"이라고 할 때만 부릅니다.** 업계에서는 이것을 모델 계단(model cascade) · 대체(fallback) 설계라고 부릅니다: 싸고 확실한 방법을 먼저 쓰고, 그것이 모를 때만 비싼 방법을 씁니다. LLM에게는 자유롭게 쓰게 하지 않고, 영역 목록과 "운영과 상관없음" 중 **하나만 고르게** 합니다. 고를 수 있는 답이 정해져 있어야 프로그램이 그 답을 믿고 다음 갈래로 보낼 수 있습니다.
|
||||
|
||||
| | 낱말 라우터만 | + LLM 라우터 |
|
||||
| --- | --- | --- |
|
||||
| 낱말이 맞는 질문 | LLM 한 번 (답 쓰기) | 그대로 — LLM 라우터를 거치지 않음 |
|
||||
| 낱말이 없는 질문 | 바로 거절 (0초) | LLM 두 번 (고르기 + 답 쓰기), 몇 초 더 |
|
||||
| 운영과 상관없는 질문 | 바로 거절 | LLM이 "상관없음"을 골라 거절 — 비용이 든 거절 |
|
||||
|
||||
기능이 바뀌면 **예전 규칙으로 쓴 테스트의 기대도** 사람이 다시 정합니다. 예전에는 거절이 맞았던 질문에 이제 답한다면, 테스트가 실패한 것이 아니라 기대가 낡은 것입니다.
|
||||
|
||||
### 오늘 실습에서
|
||||
|
||||
낱말 없는 세 질문 (Lab 02 과제 1, **5/5**): "이번 주에 AI 쓰는 데 얼마나 나갔어?" → `cost` · `llm` · 92.01% (4.9초), "어젯밤에 접수 못 하고 남은 건" → `dlq` 3건, "새 판을 일부 사용자에게 먼저" → `release` 62.5%. 예제 3을 다시 돌리면 **4/6** — "장애" · "AI 비용"이 이제 답합니다 (기대가 옛 규칙). 그리고 DLQ 답 "2건은 대기 중이고 1건은 주차 상태"는 **거꾸로**인데 `numbers_ok: true` — 4절의 빈틈이 실제로 나왔습니다.
|
||||
|
||||
## 7. 감사 기록: 무엇을 물었고 왜 거절했나 (4교시 Lab 02 과제 2)
|
||||
|
||||
### 일반 설명
|
||||
|
||||
> **생활 속 예 · 간호사실 전화 기록부.** 간호사실은 전화마다 "몇 시 · 누가 · 무엇을 · 어떻게 답했나"를 적습니다. 나중에 "약 바꿔 달라는 전화가 하루 열 번" 같은 것이 보이면 안내문을 바꿉니다. 문제가 생기면 기록부가 증거입니다.
|
||||
|
||||
**감사 기록(audit log)은 질문마다 "무엇을 물었고, 어떻게 처리했나"를 한 줄로 남기는 것입니다.** 어느 영역으로 보냈는지, 어떤 라우터가 골랐는지, 거절했다면 왜인지, 답의 숫자가 확인됐는지를 적습니다. 업계에서는 LLM 관측성(LLM observability — Langfuse · LangSmith · Helicone)과 감사 로그로 다룹니다. 이 기록으로 알 수 있는 것:
|
||||
|
||||
| 알고 싶은 것 | 기록에서 보는 것 |
|
||||
| --- | --- |
|
||||
| 무엇을 자주 묻나 | 영역별 질문 수 → 낱말 목록 · 브리핑을 고칠 곳 |
|
||||
| 누가 작업을 시키려 했나 | "작업 요청이라 거절"한 줄 → 안내서 · 권한 안내가 필요한 곳 |
|
||||
| LLM 라우터가 얼마나 불리나 | LLM이 고른 질문의 비율 → 비용 |
|
||||
| 근거 없는 답이 있었나 | 숫자 확인에 실패한 답 |
|
||||
|
||||
감사 기록은 **덧붙이기만** 하는 기록이라 "읽기만"의 예외입니다 (실행 기록을 남기는 것과 같음). 운영 상태는 바꾸지 않고, 사용자가 받는 답도 바꾸지 않습니다. 다만 질문 원문에 개인정보가 섞일 수 있으니 얼마나 보관할지 · 누가 볼지를 정합니다 (73일차).
|
||||
|
||||
### 오늘 실습에서
|
||||
|
||||
질문 셋 → 기록 셋 (Lab 02 과제 2, **5/5**): `read_only` · `keyword` / `out_of_scope` · **`llm`** / `runs` · `numbers_ok: true`. 응답은 그대로 (`lab02` 6/6 · `lab02-challenge` 5/5) — 감사 노드 뒤의 응답이 앞 노드의 결과를 이름으로 다시 읽습니다.
|
||||
|
||||
## 8. 요청문(프롬프트)으로 에이전트에게 맡기기
|
||||
|
||||
| 넣을 것 | 예 |
|
||||
| --- | --- |
|
||||
| 파일 · 웹훅 · 사실 | "`my-work/ops-ask.json`, 웹훅 `my-ops-ask`, 사실은 `my-ops-facts`를 불러서" |
|
||||
| 갈래의 순서 | "작업 낱말 → 거절 / 낱말 라우터 → (unknown이면 LLM 라우터) → 운영 밖 거절 / 그 영역 사실만 LLM" |
|
||||
| 거절은 LLM 앞 | "거절 갈래는 LLM 노드를 지나지 않는다" |
|
||||
| 숫자 확인의 허용 형식 | "값 그대로 · ×100 · 반올림, 버전 1.2.0은 통째로" |
|
||||
| 결과 모양 | "`area` · `router` · `refused` · `reason` · `answer` · `numbers_ok` · `unknown_numbers`" |
|
||||
| 기대 결과 | "`cases/lab02.json`, 앞의 테스트도 그대로" |
|
||||
|
||||
## 9. 자주 하는 실수
|
||||
|
||||
| 실수 | 결과 | 바로잡기 |
|
||||
| --- | --- | --- |
|
||||
| 사실 전부를 LLM에게 | 물은 것 밖의 숫자를 섞음 | 그 영역만 |
|
||||
| "작업은 거절해"를 지시문에만 | 가끔 "해 드리겠습니다" | Code 갈래로 LLM 앞에서 |
|
||||
| 작업 낱말을 라우터 뒤에 | "DLQ 다시 돌려"가 `dlq`로 답함 | 작업 검사를 맨 앞에 |
|
||||
| 숫자 확인에 ×100을 허용 안 함 | 맞는 답이 실패 | 허용 형식을 정함 |
|
||||
| 숫자 확인을 "근거 확인 끝"으로 믿음 | 뜻이 틀린 답이 통과 | 평가 · 사람 검토 (3단계) |
|
||||
| 모든 질문에 LLM 라우터 | 느리고 비쌈 | 낱말이 모를 때만 |
|
||||
| 감사 노드가 응답을 바꿈 | 테스트가 깨짐 | 응답은 앞 노드의 결과를 이름으로 |
|
||||
| 기능을 바꾸고 옛 테스트를 그대로 | "실패"가 사실은 나아진 것 | 기대를 사람이 다시 정함 |
|
||||
|
||||
## 확인 질문
|
||||
|
||||
<details><summary>1. 기준 챗봇의 "DLQ 1번 작업을 다시 실행해 드리겠습니다"가 점심 메뉴 추천보다 왜 더 위험한가요?</summary>
|
||||
|
||||
점심 메뉴는 쓸모없을 뿐이지만, "다시 실행해 드리겠습니다"는 운영자가 **된 줄 알고 넘어가게** 합니다. 챗봇은 읽기만 하고 아무것도 실행하지 않았습니다. DLQ #1은 그대로 남고, 아무도 다시 보지 않습니다. 하지 않은 일을 했다고 말하는 것이 운영 도우미의 가장 나쁜 실패입니다.
|
||||
</details>
|
||||
|
||||
<details><summary>2. 작업 요청 거절을 지시문("작업은 거절하라")이 아니라 LLM 앞의 Code 갈래로 하는 까닭은?</summary>
|
||||
|
||||
지시문은 LLM이 따를 때만 지켜집니다. 질문에 따라(또는 프롬프트 주입으로) 어길 수 있습니다. Code 갈래는 낱말이 있으면 **언제나** 거절하고, LLM은 그 질문을 보지도 않습니다 (0초 · 0원). 지켜야 하는 규칙일수록 확실한 곳에 둡니다.
|
||||
</details>
|
||||
|
||||
<details><summary>3. 숫자 확인이 통과했는데 답이 틀릴 수 있나요? 오늘 실제로 있었던 예는?</summary>
|
||||
|
||||
있습니다. 숫자 확인은 "답의 숫자가 사실 안에 있나"만 봅니다. 과제 1의 DLQ 답 "2건은 대기 중이고 1건은 주차"는 parked 2 · 대기 1을 **거꾸로** 말했지만, 2와 1이 사실에 있어 `numbers_ok: true`였습니다. 예제 1의 "#1은 대기 중"도 같습니다. 뜻까지 보려면 평가(골든 질문)와 사람의 검토가 필요합니다.
|
||||
</details>
|
||||
|
||||
<details><summary>4. LLM 라우터를 붙인 뒤 `lab02-phrasing`이 6/6에서 4/6이 됐습니다. 도우미가 나빠진 건가요?</summary>
|
||||
|
||||
아닙니다. ✘ 둘은 "장애 났어?" · "AI 쓰는 데 얼마나 나갔어?"가 이제 **거절되지 않고 답한** 것입니다. 테스트의 기대가 낱말 라우터 시절의 규칙(거절)으로 쓰여 있었습니다. 기능을 바꾸면 테스트의 기대도 사람이 다시 정해야 합니다 — 어느 쪽이 맞는지는 테스트가 아니라 사람이 정합니다.
|
||||
</details>
|
||||
|
||||
<details><summary>5. 감사 기록은 데이터 API에 쓰는 요청인데, "운영 도우미는 읽기만"과 어긋나지 않나요?</summary>
|
||||
|
||||
감사 기록은 **덧붙이기만** 하는 곳입니다. 알림 · DLQ · 예산 · 릴리스 같은 운영 상태를 하나도 바꾸지 않습니다 (실행 기록을 남기는 것과 같음). "읽기만"의 뜻은 "운영 상태를 바꾸지 않는다"이고, 무엇을 물었는지 남기는 것은 오히려 그 약속을 확인하는 증거가 됩니다.
|
||||
</details>
|
||||
@@ -0,0 +1,224 @@
|
||||
# 3단계 · 브리핑과 평가
|
||||
|
||||
- 교시: 5교시 강의 (14:00~14:50) · 6교시 [Lab 03](../../Last3Mon/79/LAB-03-Q-OPS-BRIEF.md) 실습 5개 (15:00~15:50)
|
||||
- 이 단계가 끝나면: 사실 · 상태로 "먼저 볼 것"과 정해진 할 일을 규칙으로 정한 브리핑을 만들고, LLM 요약을 덧붙이는 말로만 쓰고, 사람이 일을 하면 브리핑이 어떻게 바뀌는지 읽고, 골든 질문으로 도우미를 평가하고, 평가 점수로 관문을 세워 떨어지면 알릴 수 있다.
|
||||
- 숫자: 모두 강사 노트북 실측입니다 (79일차 판 데이터 API, OpenAI `gpt-4.1-mini` · temperature 0, 11/01 정답 워크플로우 1회). 브리핑의 표 · 순서는 Code라 같고, 요약 글과 시간은 실행마다 다를 수 있습니다.
|
||||
- 실습 가리키기: 이 문서에서 "Lab 03 예제 1"은 6교시 [Lab 03 문서](../../Last3Mon/79/LAB-03-Q-OPS-BRIEF.md)의 그 절입니다.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A["1. 브리핑 ·<br/>먼저 볼 것"] --> B["2. 요약은<br/>덧붙이는 말"] --> C["3. 아침이 바뀌면"] --> D["4. 골든 질문 평가"] --> E["5. 평가 관문"]
|
||||
E --> F["6. 평가가 바꾸는 것"] --> G["7. 요청문으로"]
|
||||
```
|
||||
|
||||
## 0. 이 시간 (50분)
|
||||
|
||||
| 시간 | 절 · 개요 | 하는 일 |
|
||||
| --- | --- | --- |
|
||||
| 14:00~14:09 | 1 · 개요 22장 | 브리핑 — 먼저 볼 것은 규칙으로 |
|
||||
| 14:09~14:16 | 2 · 개요 23장 | LLM 요약은 덧붙이는 말 |
|
||||
| 14:16~14:23 | 3 · 개요 24장 | 아침이 바뀌면 — 초록이 된 까닭 |
|
||||
| 14:23~14:33 | 4 · 개요 25~26장 | 골든 질문 평가 |
|
||||
| 14:33~14:43 | 5 · 6 · 개요 27~28장 | 평가 관문, 평가가 바꾸는 것 |
|
||||
| 14:43~14:50 | 7 · 8 · 확인 질문 | 요청문, 자주 하는 실수 |
|
||||
|
||||
### 6교시 Lab 03에서 이어서 하는 것
|
||||
|
||||
| 6교시 실습 (시각) | 이 강의의 절 | 실습에서 하는 일 | 쓰는 파일 · 명령 |
|
||||
| --- | --- | --- | --- |
|
||||
| Lab 03 예제 1 (15:00~15:12) | 1 | 아침 브리핑 | `my-work/ops-brief.json` (새로), 테스트 `cases/lab03.json` |
|
||||
| Lab 03 예제 2 (15:12~15:20) | 2 | LLM 요약 · 숫자 확인 | 같은 파일, 테스트 `cases/lab03-llm.json` → `OPS.md` 7절 |
|
||||
| Lab 03 예제 3 (15:20~15:26, 에이전트 없이) | 3 | 아침이 바뀌면 | `test cases/lab03-after.json -v` → `OPS.md` 8절, `morning --reset` |
|
||||
| Lab 03 과제 1 (15:26~15:40) | 4 | 골든 질문 평가 | `my-work/ops-eval.json` (새로), 테스트 `cases/lab03-challenge.json` |
|
||||
| Lab 03 과제 2 (15:40~15:50) | 5 · 6 | 평가 관문 | 테스트 `cases/lab03-challenge2.json` → `OPS.md` 9절, `morning --reset` |
|
||||
|
||||
## 1. 브리핑: 먼저 볼 것은 규칙으로 (6교시 Lab 03 예제 1)
|
||||
|
||||
### 일반 설명
|
||||
|
||||
> **생활 속 예 · 인수인계는 빨강 환자부터.** 낮 근무가 인수인계를 받을 때, 밤 근무는 병실 번호 순서가 아니라 **급한 순서**로 말합니다. 빨강 자석 환자 먼저, 그다음 노랑. 그리고 환자마다 "다음에 할 일"이 정해져 있습니다 — "고열이면 해열제 · 1시간 뒤 다시 체온". 말하는 사람이 바뀌어도 순서와 할 일이 같습니다.
|
||||
|
||||
**브리핑은 숫자와 상태를 "먼저 볼 것"과 "할 일"로 바꾼 한 장입니다.** 업계에서는 당번 인수인계 문서(on-call handoff), 장애 대응 안내서(runbook), 아침 스탠드업 리포트라고 부릅니다. 브리핑의 세 부분은 모두 규칙으로 정할 수 있습니다.
|
||||
|
||||
| 부분 | 무엇을 보고 만드나 | 규칙 |
|
||||
| --- | --- | --- |
|
||||
| 전체 상태 · 영역 표 | 이미 매긴 색과 숫자 | 다시 판정하지 않고 그대로 옮김 |
|
||||
| 먼저 볼 것 | 빨강 영역, 그다음 노랑 영역 | 정해진 영역 순서로 앞의 몇 개 |
|
||||
| 할 일 | 영역마다 미리 적어 둔 한 줄 | 안내서(runbook)의 문장 그대로 |
|
||||
|
||||
먼저 볼 것을 LLM에게 고르게 하면 같은 아침에 다른 순서가 나옵니다. 할 일을 LLM에게 쓰게 하면 안내서에 없는 일("서버를 재시작하세요")을 권할 수 있습니다. 순서와 할 일처럼 **정답이 정해진 것은 프로그램이**, 사람이 읽기 좋은 요약만 LLM이 합니다 (다음 절).
|
||||
|
||||
### 오늘 실습에서
|
||||
|
||||
`my-ops-brief` (Lab 03 예제 1, **4/4**, LLM 없음):
|
||||
|
||||
| 영역 | 상태 | 숫자 |
|
||||
| --- | --- | --- |
|
||||
| 실행 | 🔴 | 오류율 5.88% · p95 2598ms · 답 못 함 4.76% |
|
||||
| DLQ | 🔴 | 3건 (parked 2) |
|
||||
| 릴리스 | 🔴 | 1.1.0 · 카나리 1.2.0 20% (다시 묻기 62.5%) |
|
||||
| 알림 · 품질 · 비용 | 🟡 | 6건 (높음 3) · 평균 0.6583 · 마지막 1 · 격리 1 · $0.073604 / $0.08 (92.01%) |
|
||||
|
||||
- 먼저 볼 것: ① 🔴 실행 "오류 묶음 1위 확인 · 고치기 (77일차)" ② 🔴 DLQ "parked 건 원인 확인 뒤 런북대로 재처리 (76일차)" ③ 🔴 릴리스 "카나리 끄기 · 되돌리기 검토 (74일차)". DLQ를 비우면 셋째 자리에 알림.
|
||||
|
||||
## 2. LLM 요약은 덧붙이는 말 (6교시 Lab 03 예제 2)
|
||||
|
||||
### 일반 설명
|
||||
|
||||
> **생활 속 예 · 인수인계 끝의 한마디.** 표와 할 일 목록을 다 넘긴 뒤, 밤 근무가 한마디 덧붙입니다. "오늘은 3호실이 제일 걱정이에요." 사람에게는 이 한마디가 기억에 남습니다. 그러나 이 한마디가 표를 **대신**하면 안 됩니다 — 한마디에는 다른 두 환자가 빠졌으니까요.
|
||||
|
||||
**LLM 요약은 브리핑에 덧붙이는 사람의 말입니다.** 사람은 표보다 문장을 빨리 읽습니다. 그래서 세 문장 요약을 붙이되, 둘을 지킵니다.
|
||||
|
||||
| 원칙 | 까닭 |
|
||||
| --- | --- |
|
||||
| 표 · 먼저 볼 것 · 할 일은 Code가 만든 그대로 | 요약은 길이 때문에 일부만 말함 |
|
||||
| 요약에도 숫자 확인 (2단계) | 지어낸 숫자를 회의에 가져가지 않게 |
|
||||
|
||||
업계의 "AI 요약" 기능(인시던트 요약 · 회의 요약)도 원문 링크 · 원 데이터를 함께 두는 까닭이 같습니다.
|
||||
|
||||
### 오늘 실습에서
|
||||
|
||||
두 번 부른 요약 (Lab 03 예제 2, **2/2**, `numbers_ok: true` 둘 다):
|
||||
|
||||
- "전체 시스템 상태는 빨간색으로, 오류율은 5.88%이며 DLQ 크기는 3입니다. 가장 긴급한 문제는 'Search FAQ' 노드에서 발생하는 1000ms 타임아웃 오류로 16건이 보고되었습니다. …"
|
||||
- "전체 시스템 상태는 빨간색으로, 오류율은 5.88%이며, 응답하지 않은 비율은 4.76%입니다. 가장 긴급한 문제는 'Search FAQ' 노드에서 발생한 16건의 타임아웃 오류입니다. …"
|
||||
- 둘 다 먼저 볼 것 셋 중 **하나**(실행)만 말했습니다. DLQ parked · 카나리는 세 문장에 없습니다.
|
||||
|
||||
## 3. 아침이 바뀌면: 초록이 된 까닭을 함께 말한다 (6교시 Lab 03 예제 3)
|
||||
|
||||
### 일반 설명
|
||||
|
||||
> **생활 속 예 · 빨강 자석을 뗀 까닭.** 오후에 빨강 자석이 셋 다 떨어졌습니다. 하나는 열이 내려서, 하나는 다른 병동으로 옮겨서, 하나는 "38.5도 기준을 39도로 바꿔서"입니다. 셋 다 "빨강 아님"이지만 뜻이 전혀 다릅니다. 셋째를 "나았다"고 보고하면 큰일입니다.
|
||||
|
||||
**브리핑은 사실이 바뀌면 다시 만들어지는 할 일 목록입니다.** 브리핑을 고치지 않아도, 사람이 일을 하면 표 · 순서 · 할 일이 따라 바뀝니다. 그런데 색이 바뀐 **까닭**은 여러 가지입니다.
|
||||
|
||||
| 까닭 | 예 | 뜻 |
|
||||
| --- | --- | --- |
|
||||
| 일을 끝냄 | 사람이 볼 일로 남아 있던 건을 처리 | 고쳤다 |
|
||||
| 위험을 멈춤 | 문제가 있는 새 판을 끔 | 원인은 그대로 |
|
||||
| 기준 · 한도를 바꿈 | 예산 올림 | 쓴 돈은 그대로 |
|
||||
|
||||
77일차 SLO에서 "기준을 바꾸면 초록이 된다"를 본 것과 같습니다. 회의에서 "초록입니다"만 말하지 않고 **무엇을 했는지**를 함께 말합니다.
|
||||
|
||||
### 오늘 실습에서
|
||||
|
||||
케이스가 이어서 가는 테스트 (Lab 03 예제 3, 5/5):
|
||||
|
||||
| 사람이 한 일 | 빨강 | 먼저 볼 것 |
|
||||
| --- | --- | --- |
|
||||
| (아침 그대로) | runs · dlq · release | 실행 · DLQ · 릴리스 |
|
||||
| parked 둘 처리 | runs · release | 실행 · 릴리스 · 알림 |
|
||||
| 카나리 끔 | runs | 실행 · 알림 · DLQ |
|
||||
| 예산 0.08 → 0.2 | runs (비용 0.9201 → 0.368, 🟢) | 실행 · 알림 · DLQ |
|
||||
|
||||
- 남은 빨강(FAQ timeout)은 아무도 고치지 않았습니다 — 77일차 Lab 03의 일입니다.
|
||||
|
||||
## 4. 골든 질문 평가: 도우미를 시험한다 (6교시 Lab 03 과제 1)
|
||||
|
||||
### 일반 설명
|
||||
|
||||
> **생활 속 예 · 새 간호사의 모의 인수인계 시험.** 새 간호사가 병동에 투입되기 전, 수간호사가 정해진 질문 여덟 개로 시험합니다. "3호실 체온은?" "약을 바꿔 달라는 전화가 오면?" 답이 정해져 있어 누가 채점해도 같습니다. 교육 내용이 바뀔 때마다 같은 시험을 다시 봅니다.
|
||||
|
||||
**평가(evaluation)는 답을 미리 알고 있는 질문으로 도우미를 시험하는 것입니다.** 이 질문 묶음을 골든 세트(golden set) · 평가 데이터셋이라고 부르고, 업계에서는 LLM 평가 도구(OpenAI Evals · promptfoo · RAGAS · DeepEval · LangSmith)로 돌립니다. 질문마다 무엇을 확인할지 미리 정합니다.
|
||||
|
||||
| 확인할 것 | 묻는 것 |
|
||||
| --- | --- |
|
||||
| 영역 | 맞는 영역으로 보냈나 |
|
||||
| 거절 | 거절해야 할 질문(작업 · 운영 밖)을 거절했나 |
|
||||
| 기대 숫자 | 꼭 나와야 할 숫자가 답에 있나 |
|
||||
| 근거 | 답의 숫자가 모두 자료에 있나 (숫자 확인) |
|
||||
|
||||
점수는 "모두 맞은 질문 수 ÷ 전체 질문 수"입니다. 평가는 질문마다 LLM을 부르므로 도우미 한 번보다 느리고 비쌉니다 — 도우미를 고칠 때마다 돌리되, 운영 중 질문마다 돌리지는 않습니다. 그리고 질문이 하나도 없으면 오류로 돌려보냅니다: "0개 중 0개 맞음 = 100점"으로 속지 않게.
|
||||
|
||||
### 오늘 실습에서
|
||||
|
||||
`my-ops-eval`에 골든 질문 8개 (Lab 03 과제 1, **3/3**): **8/8 · score 1** (3.9초). 기대를 일부러 틀리게 쓴 질문("알림이 몇 건?"의 영역을 `cost`로) → `area_ok: false`만 틀림 — 도우미는 맞았고 **시험지가** 틀렸다는 것을 평가가 보여 줍니다. 그러나 8/8이어도 2단계의 "parked 2 · 대기 1을 거꾸로" 같은 답은 통과합니다 — 골든 질문에 틀리기 쉬운 것을 더해 갑니다.
|
||||
|
||||
## 5. 평가 관문: 점수가 떨어지면 멈추고 알린다 (6교시 Lab 03 과제 2)
|
||||
|
||||
### 일반 설명
|
||||
|
||||
> **생활 속 예 · 합격선 80점.** 모의 시험에 합격선이 없으면 50점을 받아도 병동에 나갑니다. 합격선을 정해 두면 "80점 아래면 다시 교육"이 자동으로 정해집니다. 그리고 떨어진 사람이 있으면 수간호사에게 알림이 갑니다.
|
||||
|
||||
**평가 관문(eval gate)은 평가 점수를 기준과 비교해 통과 · 실패를 정하는 것입니다.** 74일차 배포 관문 · 78일차 품질 관문과 같은 모양입니다. 업계에서는 프롬프트나 모델을 바꿀 때마다 CI(자동 시험)에서 평가를 돌리고, 점수가 떨어지면 배포를 막습니다 (LLMOps의 회귀 시험).
|
||||
|
||||
| 정할 것 | 흔한 방법 |
|
||||
| --- | --- |
|
||||
| 기준 점수 | 입력으로 받고, 없으면 기본값 (예: 0.9) |
|
||||
| 통과 · 실패 | 점수 ≥ 기준이면 통과, 아니면 실패 |
|
||||
| 실패하면 | 알림을 남겨 사람이 알게 함 — 운영 브리핑에도 보임 |
|
||||
|
||||
기준을 코드에 박지 않고 입력으로 받는 까닭은 78일차 기준과 같습니다: 기준은 팀이 고르는 값이고, 바꿀 때마다 프로그램을 고치지 않게.
|
||||
|
||||
### 오늘 실습에서
|
||||
|
||||
(Lab 03 과제 2, **4/4**): 알림 질문 하나 · 기준 없음 → 0.9 · pass, 골든 8 · 0.8 → pass, 틀린 기대 · 0.9 → **fail** → 알림 `{"workflow": "ops-eval", "reason": "eval_below", "score": 0, "min_score": 0.9}`.
|
||||
|
||||
## 6. 평가가 바꾸는 것: 시험이 시험을 바꾼다 (6교시 Lab 03 과제 2)
|
||||
|
||||
### 일반 설명
|
||||
|
||||
> **생활 속 예 · 모의 시험 중에 울린 호출벨.** 모의 시험 문제 "지금 호출벨이 몇 개 울렸나?"를 내기 직전에, 앞 문제를 채점하던 수간호사가 호출벨을 하나 눌렀습니다. 새 간호사는 정확히 "7개"라고 답했는데, 정답지는 "6개". 새 간호사가 틀린 것이 아닙니다 — 시험이 병동을 바꿨습니다.
|
||||
|
||||
**평가가 남기는 흔적(알림 · 기록 · 사용량)이 다음 평가의 답을 바꿀 수 있습니다.** 운영 데이터를 읽는 도우미를 평가할 때 특히 그렇습니다. 앞 시험이 알림을 하나 남기면, 다음 질문 "알림이 몇 건이야?"의 맞는 답이 바뀝니다. 업계에서는 이것을 시험 격리(test isolation), 고정된 처음 상태(fixture)로 다룹니다.
|
||||
|
||||
| 지키는 것 | 하는 일 |
|
||||
| --- | --- |
|
||||
| 처음 상태에서 | 평가 전에 운영 데이터를 정해진 처음 상태로 되돌림 |
|
||||
| 순서를 생각 | 상태를 바꾸는 시험(실패 → 알림)은 그 상태를 읽는 시험 **뒤에** |
|
||||
| 평가 자신의 흔적 | 기록에 평가 질문이 섞이므로, 평가가 남긴 것인지 표시해 나눔 |
|
||||
|
||||
### 오늘 실습에서
|
||||
|
||||
수업 준비 때 "기준을 안 주면 0.9" 케이스를 **맨 뒤**에 두었더니, 도우미가 "알림은 총 **7건**"이라 답해 "6"을 기대한 평가가 0점이 됐습니다. 바로 앞 케이스의 실패가 `eval_below` 알림을 하나 남겼기 때문입니다 (숫자 확인도 통과 — 7은 사실에 있음). 그 케이스를 맨 앞으로 옮겼습니다. 78일차 `--repeat`의 `exists_id`와 같은 종류의 함정입니다.
|
||||
|
||||
## 7. 요청문(프롬프트)으로 에이전트에게 맡기기
|
||||
|
||||
| 넣을 것 | 예 |
|
||||
| --- | --- |
|
||||
| 파일 · 웹훅 | "`my-work/ops-brief.json` · `my-ops-brief`, `my-work/ops-eval.json` · `my-ops-eval`" |
|
||||
| 브리핑 규칙 | "먼저 볼 것은 red 다음 yellow의 앞 3개, 할 일은 AGENTS.md 3절 표의 문장 그대로, 표의 숫자 형식도 그 표대로" |
|
||||
| 요약의 자리 | "요약은 markdown 끝 ## 요약, 표 · 순서는 바꾸지 않음, 숫자 확인" |
|
||||
| 평가 규칙 | "케이스마다 my-ops-ask, 넷 다 맞으면 통과, 빈 목록은 400" |
|
||||
| 관문 | "min_score 없으면 0.9, fail이면 /alerts에 eval_below, 응답은 평가 결과 + min_score · gate" |
|
||||
| 기대 결과 | "`cases/lab03-challenge2.json`, `lab03-challenge` 그대로" |
|
||||
|
||||
## 8. 자주 하는 실수
|
||||
|
||||
| 실수 | 결과 | 바로잡기 |
|
||||
| --- | --- | --- |
|
||||
| 먼저 볼 것을 LLM이 고름 | 같은 아침에 다른 순서 | red · yellow 순서 규칙 |
|
||||
| 할 일을 LLM이 씀 | 런북에 없는 일을 권함 | 영역마다 정해진 문장 |
|
||||
| 요약이 표를 대신 | DLQ · 카나리가 빠짐 | 표는 Code, 요약은 끝에 |
|
||||
| 상태를 브리핑에서 다시 판정 | 사실과 다른 색 | 사실의 `health` 그대로 |
|
||||
| "초록입니다"만 말함 | 한도를 바꾼 것을 고친 줄 앎 | 무엇을 했는지 함께 |
|
||||
| 골든 질문을 쉬운 것만 | 8/8인데 틀린 답이 나감 | 틀리기 쉬운 질문을 더함 |
|
||||
| 빈 목록에 score 1 | "0개 중 0개 = 100%" | 400 |
|
||||
| 평가 순서를 생각 안 함 | 앞 케이스의 알림이 답을 바꿈 | 처음 상태 · 상태를 바꾸는 케이스는 뒤로 |
|
||||
|
||||
## 확인 질문
|
||||
|
||||
<details><summary>1. 브리핑의 "먼저 볼 것"과 "할 일"을 LLM에게 맡기지 않는 까닭은?</summary>
|
||||
|
||||
같은 아침에 같은 순서 · 같은 할 일이 나와야 당번이 믿습니다. LLM은 실행마다 다른 순서를 고를 수 있고, 런북에 없는 일을 권할 수 있습니다. 먼저 볼 것(red 다음 yellow)과 할 일(영역마다 정해진 문장)은 정답이 정해진 판정이라 Code로 충분합니다. LLM은 사람이 읽기 좋은 요약 한 단락에만.
|
||||
</details>
|
||||
|
||||
<details><summary>2. 요약이 숫자 확인을 통과했는데도 "표를 대신하면 안 된다"고 했습니다. 왜인가요?</summary>
|
||||
|
||||
숫자 확인은 "틀린 숫자가 없다"만 보장합니다. 빠진 것은 보지 않습니다. 오늘 두 요약 모두 먼저 볼 것 셋 중 실행 하나만 말했고 DLQ parked · 카나리는 없었습니다. 요약만 보고 회의를 하면 급한 둘을 놓칩니다.
|
||||
</details>
|
||||
|
||||
<details><summary>3. 카나리를 끄자 릴리스가 🟢가 됐습니다. 회의에서 "릴리스 문제는 해결됐습니다"라고 말해도 되나요?</summary>
|
||||
|
||||
아닙니다. 카나리를 끈 것은 **위험을 멈춘** 것이고, 1.2.0의 다시 묻는 문제(62.5%)는 그대로입니다. 다시 켜면 같은 문제가 납니다. "카나리를 껐고, 1.2.0의 원인은 아직"이라고 말해야 합니다. 예산을 올려 비용이 🟢가 된 것도 "한도를 바꿨다"이지 "덜 썼다"가 아닙니다.
|
||||
</details>
|
||||
|
||||
<details><summary>4. 골든 질문 평가에서 8/8을 받았습니다. 도우미가 완벽하다는 뜻인가요?</summary>
|
||||
|
||||
아닙니다. 8/8은 "이 여덟 질문에서 영역 · 거절 · 숫자 · 근거가 맞았다"는 뜻입니다. 2단계의 "parked 2 · 대기 1을 거꾸로 말한 답"은 숫자가 사실에 있어 통과합니다. 평가는 질문을 늘려 갈수록 나아집니다 — 실제로 틀렸던 질문, 뜻을 뒤집기 쉬운 질문을 골든 세트에 더합니다.
|
||||
</details>
|
||||
|
||||
<details><summary>5. 수업 준비 때 평가 점수가 갑자기 0이 된 일이 있었습니다. 원인과 고친 방법은?</summary>
|
||||
|
||||
앞 케이스(틀린 기대 → 관문 실패)가 `eval_below` 알림을 하나 남겨 알림이 7건이 됐고, 다음 케이스 "알림이 몇 건?"에 도우미가 정확히 7건이라 답했는데 기대는 6이었습니다. 도우미가 아니라 **평가가 바꾼 상태**가 원인입니다. 그 케이스를 상태를 바꾸는 케이스보다 앞으로 옮겼습니다. 평가는 처음 상태에서, 평가 자신이 바꾸는 것까지 생각해 순서를 정합니다.
|
||||
</details>
|
||||
@@ -0,0 +1,213 @@
|
||||
# 4단계 · 정리: 오늘 한 일의 의미 · 효과 · 실전 응용
|
||||
|
||||
- 교시: 8교시 17:10~17:45 (35분, 바이브 코딩 발표 10분 뒤) · 자료: 이 문서 + [개요](00-DAY79-OVERVIEW.md) 30장
|
||||
- 이 시간이 끝나면: 오늘 1~3단계에서 한 일이 **무엇을 위한 것이었는지**, 숫자로 **무엇이 달라졌고 무엇을 치렀는지**, 회사에서는 같은 생각을 **어떤 이름과 도구로** 쓰는지 말할 수 있고, 단위 프로젝트 · 최종 프로젝트에 무엇을 가져갈지 정할 수 있다.
|
||||
- 숫자: 오늘 교안의 실측(강사 노트북, 11/01 정답 워크플로우 1회)입니다. "예시"라고 적은 계산은 가정을 둔 어림입니다.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A["1. 오늘 한 장"] --> B["2. 왜 운영 도우미를"] --> 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단계 · 운영 사실 | 출처 둘러보기, 사실 하나로, 기간, 영역별 상태, 출처가 멈추면 | 기준 **666 · 칸 없음 · 0/5** → 357 · 0.0588 · 여섯 영역 · **5/5**, 기간 넷 (10/26 비율 `null`), 🔴 셋 · 🟡 셋, 사용량 출처가 멈추면 **500 → 200 · `unknown`** |
|
||||
| 2단계 · 질문 답변 | 라우터 · 거절, 숫자 확인, 질문을 바꾸면, LLM 라우터, 감사 기록 | 기준 챗봇 **0/6** ("다시 실행해 드리겠습니다") → 3/6 → **6/6** (작업 거절 0.0초), 말투 여섯 중 불편 둘, LLM 라우터 5/5 (phrasing 4/6), 감사 3줄 |
|
||||
| 3단계 · 브리핑과 평가 | 브리핑, LLM 요약, 아침이 바뀌면, 골든 질문 평가, 평가 관문 | 먼저 볼 것 셋 · 할 일 셋 (LLM 없음), 요약은 셋 중 하나만, 사람이 일한 뒤 빨강 하나, 골든 **8/8 · score 1**, 관문 fail → `eval_below` 알림 |
|
||||
|
||||
## 2. 왜 운영 도우미를
|
||||
|
||||
> **생활 속 예 · 병원의 인수인계.** 잘 돌아가는 병동은 사고가 난 뒤가 아니라 **아침 인수인계**에서 위험을 잡습니다. 인수인계가 간호사 한 사람의 기억에만 있으면 그 사람이 쉬는 날 빈칸이 생깁니다. 그래서 양식 · 색 자석 · 기록부 · 모의 시험을 둡니다. 개요 28장 "병원 아침으로 본 오늘 하루" 표도 함께 봅니다.
|
||||
|
||||
| 운영 담당자가 출처를 하나씩 열면 | 사실 · 도우미 · 브리핑으로 하면 |
|
||||
| --- | --- |
|
||||
| 여섯 곳을 여는 데 아침 시간 (빠뜨리는 곳이 생김) | 사실 한 번 0.1초, 영역 여섯 |
|
||||
| 대시보드에 없는 칸은 "괜찮다" (parked · 카나리) | 영역마다 칸이 있음, 모르면 ⚪ |
|
||||
| 같은 오류율이 화면마다 다름 | 정의는 사실 한 곳 (77일차 숫자 그대로) |
|
||||
| "괜찮아?"에 사람마다 다른 답 | 기준표로 🔴 · 🟡 |
|
||||
| 챗봇이 "해 드리겠습니다" | 작업 요청은 LLM 앞에서 거절, 런북 안내 |
|
||||
| 무엇부터 볼지 그날 기분 | 먼저 볼 것 셋 · 정해진 할 일 |
|
||||
| 도우미를 고친 뒤 "잘 되겠지" | 골든 질문 평가 · 관문 |
|
||||
|
||||
**오늘의 원칙 세 줄**: 숫자 · 상태는 Code가, 글은 LLM이, 작업은 사람이. 운영 도우미는 **읽기만** 하고, 모르는 것은 모른다고 말합니다.
|
||||
|
||||
## 3. 효과와 값을 숫자로
|
||||
|
||||
### 3.1 오늘 실측 전 · 후
|
||||
|
||||
| 무엇 | 전 (팀의 기준) | 후 | 바꾼 것 |
|
||||
| --- | --- | --- | --- |
|
||||
| 지난주 실행 | 666 · 3.153… | 357 · 0.0588 | 기간 · 77일차 정의 |
|
||||
| 영역 | 넷 (칸 일부) | 여섯 + 색 | 무엇을 물을지 먼저 |
|
||||
| 출처가 멈춘 아침 | 사실 전체 500 | 다섯 영역 + `unknown` | `neverError` · 모르는 것은 `null` |
|
||||
| "DLQ 1번 다시 돌려 줘" | "다시 실행해 드리겠습니다" | 거절 `read_only` 0.0초 | Code 갈래 |
|
||||
| 점심 메뉴 | 추천 | 거절 0.1초 | 운영 밖 갈래 |
|
||||
| 카나리 질문 | 오류율 · 알림을 섞음 | 62.5% 대 7.73% | 그 영역 사실만 |
|
||||
| "장애 났어?" | (낱말 라우터) 거절 | `runs`로 답 (LLM 라우터) | 낱말이 모를 때만 LLM |
|
||||
| 무엇부터 | 없음 | 실행 · DLQ · 릴리스 + 할 일 | 브리핑 규칙 |
|
||||
| 도우미가 괜찮나 | 모름 | 골든 8/8 · 관문 | 평가 |
|
||||
|
||||
**치른 값**:
|
||||
|
||||
- **시간 · 비용**: 질문 하나에 LLM 한 번(1~3초), LLM 라우터를 거치면 두 번(2~5초). 평가는 질문마다 LLM — 골든 8개에 3.9초. 사실 · 상태 · 브리핑 표는 0.1~1초 · 0원.
|
||||
- **불편**: 낱말 라우터는 "장애"를 거절했습니다. 안전한 쪽의 실패지만 사용자는 다시 물어야 합니다.
|
||||
- **남은 빈틈**: 숫자 확인 · 평가 모두 "숫자는 맞고 뜻이 틀린 답"(parked 2 · 대기 1을 거꾸로)을 통과시켰습니다. 사람의 검토와 골든 질문을 늘리는 일이 남습니다.
|
||||
- **평가의 부작용**: 평가가 남긴 알림이 다음 평가의 답을 바꿨습니다. 평가 순서 · 처음 상태를 관리하는 일이 생깁니다.
|
||||
|
||||
### 3.2 한 달로 보면 (예시)
|
||||
|
||||
가정: 운영 담당자 한 명이 평일 20일 아침마다 여섯 출처를 여는 데 15분, 사실 · 브리핑으로는 3분. 도우미에게 하루 20번 묻고, 질문 하나의 LLM 비용은 오늘 단가로 1원 안팎.
|
||||
|
||||
| | 출처를 하나씩 | 도우미 · 브리핑 (예시) |
|
||||
| --- | --- | --- |
|
||||
| 아침 점검 시간 | 15분 × 20일 = 5시간 | 3분 × 20일 = 1시간 |
|
||||
| 놓치는 것 | 대시보드에 칸이 없는 영역 | 영역 여섯이 늘 보임, 모르면 ⚪ |
|
||||
| 잘못된 작업 | 챗봇의 "해 드리겠습니다"를 믿는 일 | 0 (거절 · 런북) |
|
||||
| LLM 비용 | 0 | 하루 20질문 × 20일 = 400질문 — 몇백 원 |
|
||||
|
||||
- 숫자는 가정입니다. 그래도 **아침 시간 · 놓친 위험 · LLM 비용**을 같은 표에서 말할 수 있다는 것이 사실과 감사 기록을 남긴 효과입니다.
|
||||
|
||||
## 4. 회사에서는 같은 생각을 이렇게 부른다
|
||||
|
||||
| 오늘 한 것 | 업계 이름 | 쓰는 도구 · 표준 (예) |
|
||||
| --- | --- | --- |
|
||||
| 출처 여섯 · 영역 | 운영 신호, golden signals | Google SRE, RED · USE 방법 |
|
||||
| 사실 하나로 · 정의 한 곳 | semantic layer, metrics layer | dbt Semantic Layer · Cube · LookML |
|
||||
| 기간 · 지금, 0과 `null` | window vs point-in-time, missing data | Prometheus range · instant query |
|
||||
| 영역별 상태 | health check, RAG status, SLO | Grafana · Datadog 상태 위젯, SLO 대시보드 |
|
||||
| 출처가 멈추면 | graceful degradation, partial failure | 서킷 브레이커 · 타임아웃 · fallback |
|
||||
| 운영 도우미 · 질문 답변 | ChatOps, AIOps, ops copilot | Slack 봇 · PagerDuty · Datadog Bits AI |
|
||||
| 라우터 · LLM 라우터 | intent classification, semantic routing, model cascade | Rasa · LangChain router · 임베딩 라우팅 |
|
||||
| 작업 거절 · 읽기만 | guardrails, least privilege, human-in-the-loop | NeMo Guardrails · Guardrails AI · 권한 분리 |
|
||||
| 숫자 확인 | groundedness · faithfulness check | RAGAS faithfulness · 사내 검증기 |
|
||||
| 감사 기록 | audit log, LLM observability | Langfuse · LangSmith · Helicone |
|
||||
| 브리핑 · 할 일 | on-call handoff, runbook | PagerDuty runbook · 인수인계 문서 |
|
||||
| 골든 질문 평가 · 관문 | eval set, regression eval, eval gate | OpenAI Evals · promptfoo · DeepEval · CI 평가 |
|
||||
| `tops` | 운영 CLI · TUI 대시보드 | `k9s` · `htop` 같은 터미널 화면 |
|
||||
|
||||
- 오늘은 n8n 워크플로우 · 작은 데이터 API · `flow.py`로 직접 만들었습니다. 회사에서는 위 도구가 대신하는 경우가 많습니다. 그래도 **무엇을 물을지(영역), 무엇을 믿을지(정의), 무엇을 하면 안 되는지(거절), 언제 괜찮다고 할지(기준 · 관문)**는 오늘처럼 사람이 정합니다.
|
||||
|
||||
## 5. 산업별 응용 (예)
|
||||
|
||||
아래는 오늘 한 일을 다른 업무에 옮긴 예입니다 (실제 특정 회사의 사례가 아니라 흔한 모양).
|
||||
|
||||
| 업무 | 오늘의 무엇을 | 이렇게 |
|
||||
| --- | --- | --- |
|
||||
| 사내 헬프데스크 AI (72~79일차) | 사실 · 브리핑 · 평가 | 당번이 아침마다 FAQ 실패 · DLQ · 비용 · 카나리를 한 장으로, 바꿀 때마다 골든 질문 |
|
||||
| 쇼핑몰 · 커머스 운영 | 영역별 상태 · 거절 | 주문 실패율 · 결제 오류 · 재고 동기화 · 광고비를 색으로, "환불해 줘"는 도우미가 거절하고 담당자에게 |
|
||||
| 콜센터 · CS | 라우터 · 감사 | 상담원이 묻는 운영 질문을 영역으로, 무엇을 자주 묻는지 보고 매뉴얼 개선 |
|
||||
| 클라우드 · 플랫폼 팀 (SRE) | 사실 · 출처가 멈추면 | 모니터링 · 배포 · 비용 출처를 모은 ChatOps 봇, 출처 하나가 죽어도 나머지 상태 |
|
||||
| 제조 · 물류 관제 | 브리핑 · 아침이 바뀌면 | 라인별 불량률 · 설비 알림 · 출하 지연을 아침 브리핑으로, 조치 뒤 다시 |
|
||||
| 금융 · 의료 (규제) | 읽기만 · 감사 · 평가 관문 | AI 도우미는 조회만, 질문 · 답을 모두 기록, 모델을 바꿀 때 평가 점수로 승인 |
|
||||
|
||||
**토론 거리**: 내 회사(또는 가고 싶은 회사)의 운영 하나를 골라, "영역 여섯과 도우미가 절대 하면 안 되는 일 셋"을 정해 봅니다.
|
||||
|
||||
## 6. 운영 도우미 설계서 (프로젝트용 틀)
|
||||
|
||||
오늘의 AGENTS.md 3절과 `my-work/OPS.md`가 운영 도우미 설계서였습니다. 단위 · 최종 프로젝트에서도 이 틀로 한 장을 씁니다.
|
||||
|
||||
| 칸 | 정할 것 | 오늘의 예 |
|
||||
| --- | --- | --- |
|
||||
| 영역 | 무엇을 물어야 하나 | 실행 · 알림 · DLQ · 품질 · 비용 · 릴리스 |
|
||||
| 출처 · 정의 | 어디서 · 어떻게 세나 · 기간인가 지금인가 | `/logs/query` · 77일차 정의 · 기간은 실행에만 |
|
||||
| 상태 기준 | 🔴 · 🟡의 선, 모르면 | 오류율 > 0.01 · parked > 0 · 비교 불가는 🟡 |
|
||||
| 하면 안 되는 것 | 작업 낱말 · 운영 밖 · 거절 말 | 재처리 · 롤백 · 비워 줘 → `read_only` + 런북 |
|
||||
| 근거 | 답에 쓸 사실 · 숫자 확인의 허용 형식 | 그 영역만 · ×100 · 버전 통째로 |
|
||||
| 먼저 볼 것 · 할 일 | 순서 · 영역마다 런북 한 줄 | red 다음 yellow 앞 3개 |
|
||||
| 평가 | 골든 질문 · 기준 · 실패하면 | 8개 · 0.9 · `eval_below` 알림 |
|
||||
| 기록 | 감사 기록의 칸 · 보관 · 볼 사람 | 질문 · 영역 · 라우터 · 거절 이유 |
|
||||
|
||||
- 설계서가 없으면 "도우미가 잘 답한다"를 말할 수 없습니다. **물을 것 · 믿을 것 · 하지 않을 것 · 시험이 있어야 "괜찮다"고 말할 수 있습니다.**
|
||||
|
||||
## 7. 하지 말아야 할 때 (흔한 실수)
|
||||
|
||||
| 하기 쉬운 일 | 왜 위험한가 | 대신 |
|
||||
| --- | --- | --- |
|
||||
| 사실 전부를 LLM에게 "알아서 답해" | 숫자를 섞고 지어냄 | 라우터 · 그 영역만 · 숫자 확인 |
|
||||
| 숫자 · 색을 LLM이 정함 | 같은 아침에 다른 답 | Code · 기준표 |
|
||||
| 모르는 것을 0 · 초록으로 | 92%인데 🟢 | `null` · ⚪ · 전체는 적어도 🟡 |
|
||||
| 도우미에게 작업 권한을 줌 | "해 드리겠습니다"가 진짜가 됨 · 사고 | 읽기만, 작업은 런북 · 사람 |
|
||||
| "작업은 거절해"를 지시문에만 | 가끔 어김 | LLM 앞 Code 갈래 |
|
||||
| 숫자 확인을 믿고 끝 | 뜻이 틀린 답이 통과 | 평가 · 사람 검토 |
|
||||
| 요약만 보고 회의 | 급한 영역이 빠짐 | 표 · 먼저 볼 것은 Code |
|
||||
| 초록만 보고 "해결" | 한도를 바꾼 것을 고친 줄 앎 | 무엇을 했는지 함께 |
|
||||
| 평가 없이 프롬프트 · 모델을 바꿈 | 조용히 나빠짐 | 골든 질문 · 관문 |
|
||||
|
||||
## 8. 직무와 면접
|
||||
|
||||
오늘 한 일은 다음 직무들이 날마다 하는 일입니다: **SRE · 플랫폼 · DevOps 엔지니어, AI · LLM 애플리케이션 엔지니어, MLOps · LLMOps 엔지니어, 데이터 · 분석 엔지니어(지표 정의), 운영 · CS 자동화 담당, 업무 자동화(n8n · RPA) 개발자.** 채용 공고의 "운영 대시보드 · 모니터링", "ChatOps · 사내 AI 봇", "LLM 평가 · 가드레일", "지표 정의 · 시맨틱 레이어", "온콜 · 런북"이 오늘 내용입니다.
|
||||
|
||||
면접에서 흔히 받는 질문과 오늘 숫자로 답하는 법:
|
||||
|
||||
<details><summary>1. "여러 시스템의 운영 데이터를 한 대시보드로 모을 때 무엇을 먼저 정하나요?"</summary>
|
||||
|
||||
계산보다 **물어야 할 영역**을 먼저 정했습니다. 실행 · 알림 · DLQ · 품질 · 비용 · 릴리스 여섯이고, 기존 대시보드는 품질 · 릴리스 칸이 없어 parked 2건과 카나리를 놓쳤습니다. 그다음 정의를 한 곳(사실)에 두었습니다 — 오류율은 지난번 보고서와 같은 정의라 357건 중 0.0588로 같은 숫자가 나왔습니다. 기간 숫자와 지금 숫자를 나누고, 모르는 값은 0이 아니라 `null`로 둡니다.
|
||||
</details>
|
||||
|
||||
<details><summary>2. "출처 중 하나가 장애일 때 대시보드는 어떻게 동작해야 하나요?"</summary>
|
||||
|
||||
나머지 영역은 그대로 보여 주고, 멈춘 영역은 "모름"으로 표시합니다. 오늘 사용량 출처를 멈추자 처음 판은 사실 전체가 500이었고, 고친 판은 200에 `cost: null` · `sources_down: ["cost"]` · 상태 `unknown`을 냈습니다. 비용을 0으로 적으면 초록으로 보이는데 실제로는 예산의 92%를 쓴 날이었습니다. 전체 상태도 빨강이 없더라도 모르는 영역이 있으면 적어도 노랑입니다.
|
||||
</details>
|
||||
|
||||
<details><summary>3. "운영 챗봇이 위험한 작업을 하지 않게 하려면?"</summary>
|
||||
|
||||
세 겹으로 막았습니다. 쓰는 API를 아예 부르지 않고(권한), 작업 낱말("다시 돌려 · 롤백해 · 꺼 줘")이 있으면 LLM에게 가기 전에 Code가 거절하고(0초), 지시문에도 적습니다. 기존 챗봇은 "DLQ 1번 작업을 다시 실행해 드리겠습니다"라고 답했는데, 실제로는 아무것도 실행하지 않아 운영자가 된 줄 알 수 있었습니다. 거절 말에는 런북과 담당자를 넣었고, 거절도 감사 기록에 남깁니다.
|
||||
</details>
|
||||
|
||||
<details><summary>4. "LLM이 숫자를 지어내지 않게 하려면? 그걸로 충분한가요?"</summary>
|
||||
|
||||
질문의 영역 사실만 주고, 답의 숫자가 모두 그 사실 안에 있는지 Code로 확인합니다 (×100 · 반올림 · 버전은 허용). 지어낸 숫자는 잡지만 충분하지 않습니다 — 오늘 "parked 2 · 대기 1"을 거꾸로 말한 답이 숫자 확인을 통과했습니다. 그래서 골든 질문 평가를 두고, 틀리기 쉬운 질문을 골든 세트에 더하고, 중요한 답은 사람이 검토합니다.
|
||||
</details>
|
||||
|
||||
<details><summary>5. "LLM 기반 기능을 바꿀 때 품질이 떨어지지 않았는지 어떻게 아나요?"</summary>
|
||||
|
||||
정답을 아는 골든 질문으로 평가하고 점수에 관문을 둡니다. 오늘 8개 질문에 영역 · 거절 · 기대 숫자 · 근거 넷을 보고 8/8 · score 1, 기준 0.9 아래면 실패와 알림. 평가 자체도 시험했습니다 — 일부러 틀린 기대를 넣으면 잡아내고, 빈 목록은 400. 그리고 평가가 남긴 알림이 다음 평가의 답을 바꾼 일이 있어, 처음 상태에서 순서를 정해 돌립니다.
|
||||
</details>
|
||||
|
||||
## 9. 프로젝트로 가져갈 것
|
||||
|
||||
단위 프로젝트(80~82일차) · 최종 프로젝트(85일차~)의 워크플로우에 아래를 넣으면 "운영할 수 있는 프로젝트"가 됩니다.
|
||||
|
||||
- [ ] 운영 도우미 설계서 한 장 (6절 틀): 영역 · 출처 · 정의 · 상태 기준 · 하면 안 되는 것 · 평가 · 기록
|
||||
- [ ] 사실 웹훅 하나 (정의는 한 곳), 기간은 기간 숫자에만, 모르면 `null`
|
||||
- [ ] 영역별 상태 (기준표) · 출처가 멈춰도 200 · `unknown`
|
||||
- [ ] 질문 답변: 라우터 · 그 영역만 · 작업 · 운영 밖은 LLM 앞에서 거절 · 숫자 확인 · 감사 기록
|
||||
- [ ] 아침 브리핑: 먼저 볼 것 · 정해진 할 일 (Code), 요약은 덧붙이는 말
|
||||
- [ ] 골든 질문 평가 · 관문 (기준은 입력으로, 실패하면 알림), 처음 상태에서
|
||||
- [ ] `OPS.md` · `TEST-REPORT.md`, 터미널 도구(`tops`)로 당번의 아침
|
||||
|
||||
## 10. 다음 일차와의 연결
|
||||
|
||||
| 일차 | 오늘의 무엇을 잇나 |
|
||||
| --- | --- |
|
||||
| 80~82 | 단위 프로젝트 — 팀마다 64~79일차의 워크플로우를 묶은 서비스, 오늘의 운영 도우미가 그 서비스의 운영 부분 (발표 때 "지금 괜찮나?"를 시연) |
|
||||
| 85~ | 최종 프로젝트 — 9절 체크리스트를 팀 워크플로우에 |
|
||||
|
||||
## 토론 (5분)
|
||||
|
||||
1. 오늘 도우미는 "읽기만" 했습니다. DLQ 재처리처럼 런북이 분명한 작업이라면, 사람이 **승인 버튼**을 누르는 방식으로 도우미가 해도 될까요? 무엇이 더 있어야 할까요?
|
||||
2. "장애 났어?"를 거절하는 낱말 라우터와, 가끔 엉뚱한 영역을 고르는 LLM 라우터 중 우리 팀의 아침에는 어느 쪽이 나을까요?
|
||||
|
||||
## 정리
|
||||
|
||||
- [ ] 운영 도우미는 "지금 괜찮나? 무엇부터 볼까?"에 답하고 **읽기만** 한다
|
||||
- [ ] 먼저 물을 영역을 정하고, 정의는 사실 한 곳에 (기준 666 · 칸 없음 vs 357 · 여섯 영역)
|
||||
- [ ] 기간과 지금을 나누고, 0과 `null`을 구분하고, 출처가 멈추면 `unknown`
|
||||
- [ ] 숫자 · 상태는 Code, 글은 LLM, 작업은 사람 — 거절은 LLM 앞에서 (0/6 → 6/6)
|
||||
- [ ] 숫자 확인은 지어낸 숫자만 잡는다 — 뜻은 평가 · 사람이
|
||||
- [ ] 브리핑의 순서 · 할 일은 규칙으로, 초록이 된 까닭을 함께 말한다
|
||||
- [ ] 골든 질문 평가 · 관문으로 도우미를 시험한다 (8/8, fail → 알림), 평가가 바꾸는 상태까지
|
||||
@@ -0,0 +1,97 @@
|
||||
# 7·8교시 · 바이브 코딩 (`tops`)
|
||||
|
||||
- 교시: 7교시 16:00~16:50 (각자 만들기), 8교시 17:00~17:50 (발표 10분 · [4단계 정리](04-STAGE4-WRAPUP.md) 35분 · 예고 5분)
|
||||
- 과제: [VIBE-REQ-TOPS](../../Last3Mon/79/VIBE-REQ-TOPS.md)(요청서, 요청의 말 ①~⑫) → [VIBE-Q-TOPS](../../Last3Mon/79/VIBE-Q-TOPS.md)의 8단계: `Doc/TODO.md` → `Doc/SPEC.md` → `Doc/IMP-PLAN.md`(엔진 · TUI 단계) → 단계별 구현 → 확인 → `uv tool install` → 다른 폴더에서 사용 → 수업 뒤 `VIBE-A-TOPS.md` 공개
|
||||
- 요구 14개(R1~R14). 50분 안에는 **엔진 1단계(R1 · R2 · R3 · R5 · R7 · R13 · R14) + 엔진 2단계(R4 · R6) + TUI 1단계(R11 · R12) + 설치**, 나머지(R8 지난 도구, R9 평가 관문, R10 감사)는 IMP-PLAN의 다음 단계로 집에서.
|
||||
- 72일차 `tbench`부터 78일차 `tcheck`와 같은 흐름입니다: 사람의 말(요청서)을 **확인할 수 있는 요구**로 바꾸는 일을 학생이 먼저 하고, VIBE-Q는 그 다음 단계(비교 대상)로 씁니다. 에이전트에게는 처음 요청 한 번과 "확인했고 commit 했어. 다음 단계." 한 줄만 씁니다.
|
||||
- 오늘은 `tops`: 오늘 n8n 운영 도우미(`my-ops-facts` · `my-ops-ask` · `my-ops-brief` · `my-ops-eval`)를 **터미널에서 보는** 도구. 색 · 숫자는 n8n이 정한 그대로, 질문 · 거절 · 브리핑 · 평가 관문 · 감사, 지난 도구(`tlog` · `tcheck`)를 부품으로, TUI. **읽기만** 합니다.
|
||||
|
||||
```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["80일차 예고<br/>5분"]
|
||||
```
|
||||
|
||||
> **생활 속 예 · 회진 도는 의사의 손바닥 현황판.** 오늘 병원(n8n)에 인수인계 시스템을 만들었습니다. 회진하는 의사는 간호사실까지 오지 않고 손바닥 화면으로 봅니다. 손바닥 화면이 따로 판정하면 안 되고(간호사실이 빨강이면 손바닥도 빨강), 손바닥으로는 **보기만** 하고 처방은 하지 않습니다.
|
||||
|
||||
> 이 문서는 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 | 요구마다 확인 방법 (영역 일곱 줄 · 종료 코드 4 · 작업 거절 · 읽기만 테스트) |
|
||||
| 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 다른 폴더에서 `tops` | `tops status` = n8n 브리핑의 색 · 숫자 |
|
||||
|
||||
| 볼 것 | 막혔을 때 한마디 |
|
||||
| --- | --- |
|
||||
| TODO · SPEC 없이 VIBE-Q를 통째로 붙여 넣었나 | "요청서로 Doc/TODO.md부터. 일곱 줄 · 종료 코드 4가 SPEC에 없으면 맞았는지 모릅니다" |
|
||||
| IMP-PLAN이 한 덩어리 · 첫 요청에 14개 | "엔진 1단계만. 단계마다 확인 · 체크 · commit" |
|
||||
| 색이 n8n 브리핑과 다름 | "health 그대로, 기준값(0.01 · 0.8)은 n8n에만" |
|
||||
| 오류율이 `0.0588%` · `588%` | "AGENTS.md 3절 브리핑 표의 형식: ×100 · 두 자리" |
|
||||
| 출처가 멈춘 날 비용이 `$0` · 🟢 | "null이면 응답 없음 · ⚪" |
|
||||
| tops에 재처리 · 리셋 기능이 생김 | "읽기만 — 부를 수 있는 주소 목록, 그 밖은 막는 테스트" |
|
||||
| 테스트가 진짜 n8n을 부름 | "가짜 서버(http.server)와 n8n 응답 사본으로" |
|
||||
| n8n을 끄면 traceback | "cannot read · 종료 코드 1" |
|
||||
| 실행해 보지 않고 다음 요청 | "에이전트가 됐다고 해도 직접 `uv run tops status; echo $?`" |
|
||||
|
||||
정답 예(R1~R14를 모두 넣은 `tops`와 정답본 `VIBE-A-TOPS.md`)는 수업 뒤 공개됩니다.
|
||||
|
||||
## 2. 8교시 · 발표 (10분)
|
||||
|
||||
- 1~2명. **`tops status`와 n8n 브리핑의 색 · 숫자가 같다는 것을 보여 줄 수 있는 사람**, n8n을 끄거나 사실 파일만 주고 `tops ui`의 "not available" 탭을 보여 줄 수 있는 사람을 먼저 고릅니다.
|
||||
- 3분 발표 · 2분 질문: **내 SPEC과 VIBE-Q가 달랐던 곳** / IMP-PLAN을 어떻게 나눴나 / 처음 요청 · 고쳐 달라는 요청문 / 에이전트가 틀린 곳(다시 판정 · 숫자 형식 · 0과 null · 쓰는 주소) / 시연.
|
||||
|
||||
## 3. 강사 정리 (8교시 4단계 정리 안에서)
|
||||
|
||||
| | n8n (오늘 Lab) | tops |
|
||||
| --- | --- | --- |
|
||||
| 사실 · 상태 | `my-ops-facts` (Lab 01) | `tops status` — `health` 그대로, 숫자는 형식만 (R1 · R2 · R7) |
|
||||
| 질문 · 거절 | `my-ops-ask` (Lab 02) | `tops ask` — 영역 · 라우터 · 거절 이유 · 숫자 확인 (R4) |
|
||||
| 브리핑 | `my-ops-brief` (Lab 03) | `tops brief` (R6) |
|
||||
| 평가 관문 | `my-ops-eval` (Lab 03 과제) | `tops eval` — fail이면 종료 코드 4 (R9) |
|
||||
| 감사 | `/audit` (Lab 02 과제 2) | `tops audit` (R10) |
|
||||
| 지난 도구 | — | `tops tools` — `tlog slo` · `tcheck` (R8) |
|
||||
| 읽기만 | 쓰는 API를 부르지 않음 · 작업 거절 | 주소 목록 `READ_ONLY` + 테스트 (R5) |
|
||||
|
||||
- 풀이 거리: 강사 본은 실제 n8n에서 일곱 줄 · 종료 코드 4 · 0.19초, `tops tools`의 `tlog slo`가 **357 runs**로 같은 지난주를 셌습니다 — 정의를 복사하지 않고 그 도구를 불렀기 때문입니다. TUI 시험에서 "부른 주소는 다섯뿐"을 검사했다가 도구 탭의 `tlog`가 실행 기록을 읽어 실패했습니다 → 읽기만의 뜻은 "읽는 주소만"이 아니라 **"바꾸는 주소가 0건"**.
|
||||
- `tops audit`를 평가 뒤에 보면 평가의 질문까지 섞여 11줄 — Lab 03 과제 2의 "평가가 상태를 바꾼다"와 같은 이야기.
|
||||
|
||||
## 4. 강사 바이브 코딩 (시간이 남으면 · 수업 뒤, 15분)
|
||||
|
||||
| 주제 | 요청문 요지 | 보여 줄 것 |
|
||||
| --- | --- | --- |
|
||||
| 아침 cron | "평일 08:30에 `tops status`가 4면 `tops brief`를 파일로 남기는 cron 한 줄과 설명" | 종료 코드로 아침 점검을 자동으로 |
|
||||
| 승인 버튼 (생각해 보기) | "`tops ui`의 DLQ 줄에서 `[a]`를 누르면 런북 문장과 담당자만 보여 주고 아무것도 실행하지 않는 화면" | 읽기만을 지키면서 다음 할 일을 안내 |
|
||||
| 팀 화면 | "`--n8n`을 팀 VM 주소로, 영역마다 마지막으로 바뀐 시각" | 단위 프로젝트의 운영 화면 |
|
||||
|
||||
걸린 시간과 결과를 `Last3Mon/79/VIBE-A-TOPS.md`에 적어 둡니다.
|
||||
|
||||
## 5. 보충 · 팁 (읽을거리, 4단계 정리 7절과 함께)
|
||||
|
||||
| 팁 | 설명 |
|
||||
| --- | --- |
|
||||
| 요청서 → 요구가 먼저 | 확인 방법(일곱 줄 · 종료 코드 · 거절 줄)이 있는 요구가 있어야 에이전트의 "완료"를 판단할 수 있음 |
|
||||
| 기대 출력은 이미 있다 | 오늘 브리핑 표(`cases/lab03.json`)와 같은 숫자 — SPEC과 테스트에 그대로 |
|
||||
| n8n의 답을 사본으로 | `call my-ops-facts …`의 응답을 `tests/data/`에 두면 n8n 없이도 시험 |
|
||||
| 판정은 한 곳 | 색 · 거절은 n8n에만, tops는 보여 주기만 |
|
||||
| 읽기만은 주소 목록으로 | "조심"은 약속이 아님 — 테스트로 확인할 수 있는 목록 |
|
||||
| 0과 `null` | 모르는 것을 좋게 보이지 않기 |
|
||||
| 지난 도구는 명령으로 | 복사하면 정의가 또 한 벌 |
|
||||
| 종료 코드로 말한다 | 0 · 1 · 2 · 4 — cron · 스크립트가 다음 일을 정함 |
|
||||
| 단계마다 `git commit` | 에이전트가 망가뜨려도 돌아갈 곳 |
|
||||
|
||||
## 6. 80일차 예고 (5분)
|
||||
|
||||
- 오늘: 72~78일차의 운영 데이터를 사실 · 상태로 모으고, 묻고 답하고 막고, 브리핑하고, 도우미를 시험했습니다. 다음 수업(80~82일차): **단위 프로젝트** — 팀마다 64~79일차의 워크플로우를 묶어 하나의 서비스로 만들고, 오늘의 운영 도우미를 그 서비스의 운영 부분으로 씁니다. 자세한 일정은 [80-82-Project](../80-82-Project/README.md).
|
||||
- 64~79일차 `my-work/*`, `~/vibe/*`(`tops` 포함)는 지우지 마세요. 팀 구성 전에 "내가 가장 잘 만든 워크플로우 하나"를 골라 옵니다.
|
||||
|
||||
## 확인 (강사)
|
||||
|
||||
- [ ] 16:00 요청서 → TODO(에이전트 없이) → SPEC → IMP-PLAN 20분을 지켰다, 16:20부터 엔진 1단계.
|
||||
- [ ] 7교시 시작 전 n8n에 `my-ops-facts`(Lab 01 과제 1 이상) · `my-ops-ask`가 게시돼 있어 색 비교 · 질문을 할 수 있다.
|
||||
- [ ] 수업 뒤: 요청이 있을 때 학생 저장소에 정답(LAB-A · `answers/` · VIBE-A · `tops/`)을 올린다.
|
||||
- [ ] 발표자 1~2명, 강사 정리 표, 팁, 예고.
|
||||
- [ ] 수업이 끝날 때 학생들의 데이터 API가 운영 아침 상태인지 (`morning --reset`, `doctor`).
|
||||
@@ -0,0 +1,42 @@
|
||||
# 79일차 · 운영 데이터 기반 Workflow Ops Assistant (바이브 코딩)
|
||||
|
||||
- 일자: 2026-11-04 (79일차)
|
||||
- 교과목: 노코드 멀티 에이전트 워크플로우 설계 및 운영
|
||||
- 단원: AI 워크플로우 운영 및 관리 역량 강화
|
||||
- 학습 내용: 운영 데이터 기반 Workflow Ops Assistant 구현
|
||||
- 실습 폴더: [Last3Mon/79](../../Last3Mon/79/README.md) · 하루 수강 안내: [LECTURE-79.md](../../Last3Mon/79/LECTURE-79.md)
|
||||
- 실습 환경: 65일차 n8n 2.42.6 + OpenAI API(`gpt-4.1-mini`) + 79일차 데이터 API(운영 아침 상태) + **CLI 코딩 에이전트**
|
||||
- **실습 준비: [00-DAY79-PREP.md](00-DAY79-PREP.md) (수업 전날까지 1~2절 완료)**
|
||||
- 72일차부터의 방식: 단계마다 **1교시 강의 + 1교시 실습(5개: 예제 3 · 과제 2)**, 8교시는 발표와 4단계 정리.
|
||||
|
||||
## 오늘의 시간표
|
||||
|
||||
| 교시 | 시간 | 내용 | 자료 |
|
||||
| --- | --- | --- | --- |
|
||||
| 1 | 09:00~09:50 | 오늘의 개요 · 1단계 강의 · 운영 사실 | [개요](00-DAY79-OVERVIEW.md) 1~14장, [1단계](01-STAGE1-OPS-FACTS.md) |
|
||||
| 2 | 10:00~10:50 | Lab 01 실습 5개 (출처 둘러보기 · 운영 사실 · 기간 · 영역별 상태 · 출처가 멈추면) | [Lab 01](../../Last3Mon/79/LAB-01-Q-OPS-FACTS.md) |
|
||||
| 3 | 11:00~11:50 | 2단계 강의 · 질문 답변 | 개요 15~21장, [2단계](02-STAGE2-OPS-ASK.md) |
|
||||
| 4 | 12:00~12:50 | Lab 02 실습 5개 (라우터 · 거절 · 숫자 확인 · 질문을 바꾸면 · LLM 라우터 · 감사 기록) | [Lab 02](../../Last3Mon/79/LAB-02-Q-OPS-ASK.md) |
|
||||
| - | 13:00~14:00 | 점심 | |
|
||||
| 5 | 14:00~14:50 | 3단계 강의 · 브리핑과 평가 | 개요 22~28장, [3단계](03-STAGE3-OPS-BRIEF.md) |
|
||||
| 6 | 15:00~15:50 | Lab 03 실습 5개 (브리핑 · LLM 요약 · 아침이 바뀌면 · 골든 질문 평가 · 평가 관문) | [Lab 03](../../Last3Mon/79/LAB-03-Q-OPS-BRIEF.md) |
|
||||
| 7 | 16:00~16:50 | 바이브 코딩 · `tops`: 요청서 → TODO → SPEC → IMP-PLAN → 만들기 → 설치 | [VIBE-REQ-TOPS](../../Last3Mon/79/VIBE-REQ-TOPS.md) → [VIBE-Q-TOPS](../../Last3Mon/79/VIBE-Q-TOPS.md), [진행](05-VIBE-CODING.md) |
|
||||
| 8 | 17:00~17:50 | 바이브 코딩 발표 · **4단계 정리** (의미 · 효과 · 실전 응용) · 80일차(단위 프로젝트) 예고 | [4단계 정리](04-STAGE4-WRAPUP.md), [진행](05-VIBE-CODING.md) |
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
P["개요"] --> S1["1단계<br/>출처 여섯 · 사실 하나 ·<br/>기간 · 상태 · 출처가 멈추면"] --> S2["2단계<br/>라우터 · 거절 · 숫자 확인 ·<br/>LLM 라우터 · 감사"] --> S3["3단계<br/>브리핑 · 요약 · 아침이 바뀌면 ·<br/>평가 · 관문"] --> S4["4단계 정리<br/>의미 · 효과 · 응용"]
|
||||
S3 --> V["7·8교시<br/>바이브 코딩 tops"]
|
||||
```
|
||||
|
||||
## 자료 목록
|
||||
|
||||
| 파일 | 내용 |
|
||||
| --- | --- |
|
||||
| `00-DAY79-PREP.md` | 실습 준비: n8n · 79일차 판 데이터 API 켜기, 기준 둘 게시, `flow.py morning` · `doctor` (수업 전) |
|
||||
| `00-DAY79-OVERVIEW.md` | 개요 30장 (PPT 대신 Markdown, 가로줄로 장 구분, 장마다 생활 속 예 한 줄) |
|
||||
| `01-STAGE1-OPS-FACTS.md` | 운영 도우미, 출처 여섯과 없는 칸, 사실 하나로(시맨틱 레이어), 기간과 지금 · 0과 `null`, 상태는 규칙으로, 출처가 멈추면 |
|
||||
| `02-STAGE2-OPS-ASK.md` | 기준 챗봇의 세 실수, 라우터 · 그 영역만, 거절은 LLM 앞에서, 숫자 확인과 그 한계, 질문을 바꾸면, LLM 라우터, 감사 기록 |
|
||||
| `03-STAGE3-OPS-BRIEF.md` | 브리핑 · 먼저 볼 것은 규칙으로, LLM 요약은 덧붙이는 말, 아침이 바뀌면, 골든 질문 평가, 평가 관문, 평가가 바꾸는 것 |
|
||||
| `04-STAGE4-WRAPUP.md` | 8교시 35분 정리: 오늘 한 장, 왜 운영 도우미를, 효과와 값, 업계 이름 · 도구, 산업별 응용, 운영 도우미 설계서, 하지 말아야 할 때, 직무 · 면접, 최종 프로젝트 체크리스트 |
|
||||
| `05-VIBE-CODING.md` | 7·8교시 바이브 코딩 진행 (`tops`), 발표, 강사 정리, 추가 바이브 코딩, 팁, 80일차 예고 |
|
||||
Reference in new issue
Block a user