17 KiB
4단계 · 정리: 오늘 한 일의 의미 · 효과 · 실전 응용
- 교시: 8교시 17:10~17:45 (35분, 바이브 코딩 발표 10분 뒤) · 자료: 이 문서 + 개요 30장
- 이 시간이 끝나면: 오늘 1~3단계에서 한 일이 무엇을 위한 것이었는지, 숫자로 무엇이 달라졌고 무엇을 치렀는지, 회사에서는 같은 생각을 어떤 이름과 도구로 쓰는지 말할 수 있고, 최종 프로젝트에 무엇을 가져갈지 정할 수 있다.
- 숫자: 오늘 교안의 실측(강사 노트북, 10/31 정답 워크플로우 1회)입니다. "예시"라고 적은 계산은 가정을 둔 어림입니다.
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", "로그 분석", "지표 정의", "장애 분석 · 회고", "운영 리포트 자동화"가 오늘 내용입니다.
면접에서 흔히 받는 질문과 오늘 숫자로 답하는 법:
1. "두 보고서의 숫자가 다릅니다. 어떻게 하나요?"
먼저 정의를 맞춥니다. 오늘 팀의 보고서는 두 주를 602건, 제 보고서는 666건이라고 했는데, 차이 64가 마지막 날의 실행 수와 같았습니다. 팀 보고서가 started_at < to로 끝날을 빼고 있었습니다. 오류율도 백분율에 반올림이 없었습니다. 정의서를 한 곳에 두고, 하루 · 빈 기간 · 거르기 같은 경계 테스트로 확인했습니다.
2. "응답 시간을 어떻게 보고하나요? 평균이면 안 되나요?"
p50과 p95(필요하면 p99)를 씁니다. 평균은 느린 몇 건에 끌려가고 느린 사용자를 숨깁니다. 계산 방법(가장 가까운 순위인지 보간인지)도 정의에 적습니다. 오늘 둘째 주는 p50이 빨라졌지만 p95는 느려졌는데, 평균 하나로는 이렇게 나눠 말할 수 없습니다. 그리고 단계별로 나눠 어디가 느린지 봤습니다 — 평소엔 LLM, 월요일엔 FAQ 검색.
3. "장애를 어떻게 찾고 우선순위를 정하나요?"
오류를 원인(노드 · 메시지)으로 묶고 많은 순으로, 시간으로 나눠 평소보다 크게 나쁜 시간을 찾고, 둘을 맞춰 사건으로 만듭니다. 오늘 오류 21건은 원인 둘, 사건 둘(월 09시 FAQ timeout 16건, 목 15시 429 5건)이었습니다. 그리고 오류가 아닌 실패도 따로 셉니다 — 와이파이 질문 34건이 담당자에게 넘어갔는데 오류율엔 안 잡혔고, 사용자 피해로는 가장 컸습니다.
4. "LLM으로 운영 리포트를 만든다면 무엇을 조심하나요?"
숫자는 Code가 세고, LLM에게는 계산된 통계만 주고, 돌아온 글의 숫자가 통계에 있는지 Code가 확인합니다. 비율의 ×100이나 날짜 · 시간의 숫자도 "있는 숫자"에 넣어야 맞는 글이 틀렸다고 나오지 않습니다. 오늘 요약은 17 · 1000 · 16 · 10월 26일 09시가 모두 통계에 있어 numbers_ok: true였습니다. 할 일처럼 정해진 연결은 LLM이 아니라 규칙으로 씁니다.
5. "SLO를 정하고 운영해 본 경험이 있나요?"
오류율 1% · p95 3초 · 이관율 2%를 정하고, 보고서가 위반을 판정하게 했습니다. 둘째 주는 오류율과 이관율을 어겼고, 고친 뒤에는 그 둘을 지켰지만 p95가 3560ms로 새로 어겼습니다 — timeout을 늘려 느린 FAQ를 기다렸기 때문이고, 단계 시간으로 증명했습니다. 위반하면 high 알림을 남기되 같은 위반은 10분에 한 번만 보냈습니다.
9. 최종 프로젝트로 가져갈 것
최종 프로젝트(85일차~)의 워크플로우에 아래를 넣으면 "운영 데이터로 개선하는 프로젝트"가 됩니다.
- 실행마다 같은 모양의 기록 한 줄 (상태 · 갈래 · 시간 · 단계 시간 · 비용 · 실패한 노드 · 메시지 · 태그), 오류일 때도
- 지표 정의서 한 장 (6절 틀), 보고서 웹훅 하나 — 나머지는 다시 부름
- 경계 테스트 (하루 · 0건 · 거르기)
- 문제 목록: 원인 묶음 · 오류가 아닌 실패 · 이상 시간대, 고칠 곳 · 주인
- SLO 세 개와 위반 판정, 위반 알림 (같은 이유는 한 번)
- 고친 뒤 같은 조건으로 다시 재기 (태그), 새로 나빠진 것까지
- 주간 보고 (숫자는 Code, 요약은 LLM + 숫자 확인, 할 일은 규칙),
OPS.md
10. 다음 일차와의 연결
| 일차 | 오늘의 무엇을 잇나 |
|---|---|
| 78 | 데이터 품질 검증 — 오늘은 기록을 믿고 셌다. 들어오는 데이터 자체(빠진 칸 · 이상한 값 · 중복)를 규칙으로 검사하는 품질 관문 |
| 79 | 운영 대시보드 · Ops Assistant(tops) — 오늘의 지표 · SLO · 알림 · 주간 보고를 한 화면에, tlog와 76일차 tretry의 기록까지 |
| 80~82 | 단위 프로젝트 — 팀 워크플로우에 9절 체크리스트 |
토론 (5분)
- 오늘 "숫자가 다르면 먼저 정의를 의심한다"를 여러 번 했습니다. 내 업무(또는 수업)에서 같은 말로 다른 것을 세던 예가 있나요?
- 와이파이 34건(오류 아님)과 FAQ timeout 16건(오류) 중 무엇을 먼저 고치겠습니까? 무엇을 근거로?
정리
- 지표는 정의 + 계산, 정의는 한 곳에 (602 vs 666)
- 평균 대신 백분위, 비율 옆에 건수, 경계에서 시험
- 문제는 원인으로 묶고, 오류가 아닌 실패도 세고, 비교 기준을 함께 적는다
- 숫자는 Code, 글은 LLM, LLM의 숫자는 Code가 확인
- 고친 뒤 같은 조건으로 다시 재고, 새로 나빠진 것(대가)까지 본다 — SLO · 주간 보고 · SLO 알림
- 최종 프로젝트에 체크리스트 7개를 가져간다