TIL - 20260911

juni·2026년 9월 11일

목록 보기

454/468

0911 운영 자동화/AI 워크플로우 심화 (7/N): AI 자동화 실행 로그, 비용·성능 추적과 Observability

✅ 1. AI 자동화도 운영 시스템이다

AI/Codex 자동화를 만들기 시작하면 단순 CLI 스크립트를 넘어서 하나의 작은 운영 시스템이 됩니다.
Task 실행, Context 생성, LLM 호출, QA, 재작업, 보고서 생성까지 여러 단계가 연결되기 때문에 어디서 느려지고 실패했는지 확인할 수 있어야 합니다.
자동화가 실패했을 때 터미널에 Error 한 줄만 남는 구조로는 장기 운영이 어렵습니다.

Task 시작
  ↓
Context 생성
  ↓
AI 작업
  ↓
QA
  ↓
AI Review
  ↓
Report 생성

각 단계에서:
성공 / 실패 / 실행시간 / 원인 기록

➕ 1-1. 확인하고 싶은 질문

AI 작업은 평균 얼마나 걸리는가?
어떤 단계에서 가장 자주 실패하는가?
자동 재작업은 몇 번 발생하는가?
어떤 Task가 비용을 많이 쓰는가?
어떤 Context Pack이 너무 큰가?
AI Review가 실제 문제를 얼마나 발견하는가?
QA에서 가장 자주 막히는 이유는 무엇인가?

이런 정보를 알 수 있어야 자동화를 개선할 수 있습니다.

✅ 2. Observability란 무엇인가?

Observability는 시스템 내부에서 어떤 일이 일어나고 있는지를 외부 기록을 통해 파악할 수 있는 능력입니다.
일반적인 백엔드에서는 Log, Metric, Trace가 핵심이고, AI 자동화에서도 같은 개념을 적용할 수 있습니다.

Logs:
무슨 일이 발생했는가?

Metrics:
얼마나 자주/얼마나 오래 발생했는가?

Trace:
한 Task가 어떤 단계를 거쳤는가?

➕ 2-1. AI 자동화에 적용

Log:
Task #142 AI Review 시작

Metric:
평균 AI Review 시간 18초

Trace:
Task #142
→ Context
→ Codex
→ QA
→ Retry
→ QA
→ Review
→ Done

처음부터 복잡한 관측 플랫폼을 만들 필요는 없습니다.
JSON 로그와 Markdown Report만 잘 남겨도 충분히 시작할 수 있습니다.

✅ 3. 실행 단위는 Run으로 관리하기

하나의 Task가 여러 번 실행될 수 있으므로 Task와 Run을 구분하는 것이 좋습니다.

Task #142
  ├─ Run #1 → 실패
  ├─ Run #2 → QA 실패
  └─ Run #3 → 성공

➕ 3-1. Run ID

run_20260911_093210_a82f

➕ 3-2. Task와 Run 차이

구분	의미
Task	해결해야 하는 업무
Run	해당 Task를 실행한 한 번의 시도
Step	Run 내부의 개별 처리 단계

➕ 3-3. 구조

Task
  ↓
Run
  ↓
Steps

이렇게 나누면 재시도 기록을 덮어쓰지 않고 모두 남길 수 있습니다.

✅ 4. Run 상태 설계

CREATED
RUNNING
SUCCEEDED
FAILED
BLOCKED
CANCELED

➕ 4-1. Step 상태

PENDING
RUNNING
PASSED
FAILED
SKIPPED
WARNING

➕ 4-2. 예시

Task #142

Run:
SUCCEEDED

Steps:
Context      PASSED
AI_WORK      PASSED
TYPECHECK    PASSED
LINT         PASSED
UNIT_TEST    PASSED
INTEGRATION  PASSED
AI_REVIEW    WARNING
REPORT       PASSED

전체 성공 여부와 단계별 성공 여부를 따로 관리하는 것이 좋습니다.

✅ 5. Step 종류 표준화

TASK_LOAD
CONTEXT_BUILD
CONTEXT_SANITIZE

AI_WORK
AI_REWORK
AI_REVIEW

TYPECHECK
LINT
UNIT_TEST
INTEGRATION_TEST
E2E_TEST
BUILD
SECRET_SCAN

SCOPE_CHECK
MIGRATION_REVIEW
CONTRACT_REVIEW

TASK_REPORT
DAILY_REPORT
NOTION_UPLOAD

➕ 5-1. 왜 코드화할까?

"테스트 실패"
"Test fail"
"unit failed"

이렇게 제각각 남기기보다:

step=UNIT_TEST
status=FAILED

형태로 관리하면 집계하기 쉽습니다.

✅ 6. 실행 로그에 남길 필드

{
  "timestamp": "2026-09-11T00:32:15.125Z",
  "runId": "run_20260911_093210_a82f",
  "taskId": "142",
  "project": "togethermall",
  "step": "INTEGRATION_TEST",
  "status": "FAILED",
  "durationMs": 8421,
  "errorCode": "TEST_FAILED"
}

➕ 6-1. 기본 필드

timestamp
runId
taskId
project
step
status
durationMs
errorCode

➕ 6-2. 선택 필드

branch
commit
model
attempt
risk
contextSize
testSuite

구조화된 JSON으로 남기면 나중에 통계와 검색이 쉬워집니다.

✅ 7. 로그에 남기지 않을 것

자동화 Observability를 만든다고 해서 모든 데이터를 기록하면 안 됩니다.

Prompt 전체
Git diff 전체
고객 개인정보
API Key
Token
DATABASE_URL
Authorization Header
운영 DB 결과
.env 내용

➕ 7-1. 대신 남길 것

promptHash
promptTemplateVersion
contextFileCount
contextSize
changedFileCount
errorCode

예:

{
  "promptTemplate": "backend-task-v3",
  "promptHash": "e91f...",
  "contextFiles": 6,
  "contextChars": 38214
}

원문이 아니라 메타데이터를 기록하는 것이 안전합니다.

✅ 8. Prompt Version 관리

자동화의 결과가 달라졌을 때 코드 때문인지 Prompt 때문인지 구분하려면 Prompt 버전을 기록해야 합니다.

backend-task-v1
backend-task-v2
backend-task-v3

➕ 8-1. 예시

prompt:
  name: backend-task
  version: 3

➕ 8-2. 변경 이유

v1:
기본 작업 요청

v2:
Scope 제한 추가

v3:
API Contract와 transaction 규칙 추가

Prompt도 사실상 자동화 코드의 일부입니다.

✅ 9. Context Version도 기록하기

0910에서 만든 Context 체계를 연결합니다.

Task #142

Context:
backend@4
database@2
security@5
api-contract@3

➕ 9-1. 간단하게는 Git Commit 사용

contextCommit:
8ae219f

➕ 9-2. 장점

과거 실행 당시 어떤 규칙이 적용됐는지 확인
Context 변경 이후 품질 비교
실패 원인 분석

같은 Task라도 Context가 바뀌면 AI 결과가 달라질 수 있습니다.

✅ 10. AI 모델 정보 기록

로컬 LLM과 외부 AI를 섞어 사용한다면 어떤 모델이 어떤 작업을 했는지 기록하면 좋습니다.

{
  "provider": "ollama",
  "model": "shn-coder",
  "operation": "DAILY_REPORT"
}

또는:

{
  "provider": "external",
  "model": "coding-model",
  "operation": "AI_REVIEW"
}

➕ 10-1. 기록 목적

어떤 모델이 특정 작업에 잘 맞는지 비교
실패율 비교
속도 비교
비용 비교

모델명 자체보다 역할과 결과를 연결하는 것이 중요합니다.

✅ 11. 실행시간 측정

모든 Step에는 startedAt, finishedAt, durationMs를 기록하면 좋습니다.

Context Build:
1.2초

AI Work:
38초

Typecheck:
5초

Integration:
14초

AI Review:
21초

➕ 11-1. 전체

Total:
79초

➕ 11-2. 병목 발견

AI Work:
48%

AI Review:
27%

Tests:
20%

이렇게 보면 어디를 최적화해야 하는지 판단할 수 있습니다.

✅ 12. 너무 느린 자동화의 문제

Task 하나 실행:
7분

간단한 수정:
직접 하면 3분

이런 경우 자동화가 오히려 방해가 될 수 있습니다.

➕ 12-1. 판단 기준

자동화 시간
vs
사람이 직접 처리하는 시간

자동화가 줄여주는 검토 시간
자동화가 방지하는 사고 비용

자동화는 무조건 빠를 필요는 없지만, 얻는 가치보다 비용이 크면 조정해야 합니다.

✅ 13. Local/CI/AI 시간을 분리하기

Local checks:
8초

CI:
61초

AI:
42초

➕ 13-1. 왜 구분할까?

CI가 느리다면 테스트 병렬화
AI가 느리다면 Context 축소
Local이 느리다면 Pre-commit 검사 축소

한 숫자로만 보면 원인을 파악하기 어렵습니다.

✅ 14. LLM Token/Context 사용량

외부 LLM을 사용할 경우 토큰 사용량은 비용과 성능에 직접 연결됩니다.
로컬 모델에서도 Context 크기를 추적하면 성능 최적화에 도움이 됩니다.

Input Tokens:
18,420

Output Tokens:
3,120

Total:
21,540

➕ 14-1. 단계별 기록

AI Work:
15,000 input

AI Review:
8,000 input

Report:
3,000 input

작업 하나에 같은 diff/context를 여러 번 전달하면 사용량이 크게 늘어날 수 있습니다.

✅ 15. Context 효율성 보기

Context 50,000 tokens
실제로 관련된 파일:
5개

AI 출력:
500 tokens

이런 경우 불필요한 Context가 너무 많을 가능성이 있습니다.

➕ 15-1. 볼 수 있는 지표

Context File Count
Context Token Count
Selected Pack Count
Retrieved Troubleshooting Count
Retrieved ADR Count

➕ 15-2. 개선

관련 없는 Pack 제거
Compact Context 활용
오래된 Troubleshooting 제외
중복 규칙 제거

0910에서 만든 Context Retrieval을 실제 데이터로 튜닝할 수 있습니다.

✅ 16. 외부 AI 비용 추적

외부 모델이 사용량 기반 과금이라면 비용도 Run에 연결할 수 있습니다.

Task #142

AI Work:
$0.18

AI Review:
$0.06

Report:
Local LLM → $0

Total:
$0.24

➕ 16-1. 저장 값

inputTokens
outputTokens
estimatedCost
currency

➕ 16-2. 중요한 점

비용 값은 추정치일 수 있음
Provider별 단가가 바뀔 수 있음
정확한 청구는 실제 Provider Billing 기준

자동화 내부에서는 비용을 대략적인 최적화 지표로 보면 됩니다.

✅ 17. Cost Guard

Task 하나가 비정상적으로 큰 AI 사용량을 만드는 것을 방지할 수 있습니다.

예상 Context:
90,000 tokens

설정 Limit:
50,000

결과:
WARNING

➕ 17-1. 정책 예시

LOW Risk:
20k

MEDIUM:
40k

HIGH:
60k

CRITICAL:
사람 확인 후 실행

실제 수치는 사용하는 모델과 프로젝트에 맞게 조정하면 됩니다.

✅ 18. AI 호출 횟수 추적

Task #142

AI_WORK:
1

AI_REWORK:
2

AI_REVIEW:
1

REPORT:
1

Total:
5 calls

➕ 18-1. 재작업이 많은 경우

평균:
0.3회

특정 Task:
3회

이 경우 확인:

Task Spec이 애매했는가?
Context가 부족했는가?
테스트가 부족했는가?
AI가 반복적으로 같은 실수를 했는가?

Retry 횟수 자체가 자동화 품질 지표가 됩니다.

✅ 19. 실패율 추적

➕ 19-1. 전체 성공률

최근 30 Runs

SUCCESS:
24

FAILED/BLOCKED:
6

Success Rate:
80%

➕ 19-2. Step별 실패율

TYPECHECK:
12%

UNIT_TEST:
4%

INTEGRATION:
18%

SCOPE_CHECK:
3%

SECRET_SCAN:
0%

가장 자주 실패하는 Step부터 개선하면 됩니다.

✅ 20. Failure Code 표준화

TYPECHECK_FAILED
LINT_FAILED
UNIT_TEST_FAILED
INTEGRATION_TEST_FAILED
BUILD_FAILED

SCOPE_VIOLATION
SECRET_DETECTED
CONTEXT_TOO_LARGE
CONTEXT_MISSING
REQUIREMENT_MISMATCH

AI_TIMEOUT
AI_RATE_LIMIT
AI_INVALID_OUTPUT

NOTION_UPLOAD_FAILED
REPORT_WRITE_FAILED

➕ 20-1. 장점

월별 실패 사유 집계
반복 문제 감지
Runbook 연결
자동 대응 분기

에러 메시지 문자열보다 Error Code를 기준으로 분석하는 것이 좋습니다.

✅ 21. 실패 종류별 대응

TYPECHECK_FAILED
→ 제한적 자동 재작업

SECRET_DETECTED
→ 즉시 BLOCK

CONTEXT_TOO_LARGE
→ Compact Context 재생성

AI_TIMEOUT
→ 제한적 Retry

MIGRATION 위험
→ Human Review

REQUIREMENT_MISMATCH
→ 사람 확인

Observability 데이터가 자동 복구 전략과 연결됩니다.

✅ 22. Retry 기록

{
  "runId": "run_x",
  "step": "AI_WORK",
  "attempt": 2,
  "previousError": "AI_TIMEOUT"
}

➕ 22-1. 확인할 수 있는 것

첫 시도 성공률
2회차 성공률
3회 이상 Retry 비율

자동 Retry가 실제 효과가 있는지도 데이터로 확인해야 합니다.

✅ 23. Quality Metric은 조심해서 사용하기

AI 결과 품질을 단일 숫자로 표현하기는 어렵습니다.
“AI 품질 점수 92점” 같은 임의의 점수는 크게 의미가 없을 수 있습니다.

➕ 23-1. 대신 볼 것

QA 첫 통과율
자동 Retry 횟수
Scope Violation 비율
Human Review 수정 횟수
Revert 발생 여부
배포 후 관련 Incident 발생 여부

실제 결과를 기반으로 한 지표가 훨씬 가치 있습니다.

✅ 24. First Pass Success Rate

AI가 첫 작업에서 QA를 바로 통과한 비율입니다.

총 Task:
20

첫 시도 PASS:
14

First Pass Success:
70%

➕ 24-1. 의미

Task Spec 품질
Context 품질
AI 작업 정확도
테스트 기준 적절성

이 지표가 점점 올라간다면 자동화 규칙이 개선되고 있다고 볼 수 있습니다.

✅ 25. Human Correction Rate

AI 작업이 QA를 통과했더라도 사람이 추가 수정한 비율을 기록할 수 있습니다.

AI 완료 Tasks:
20

사람 추가 수정:
8

Human Correction Rate:
40%

➕ 25-1. 분류

FUNCTIONAL
ARCHITECTURE
STYLE
SECURITY
REQUIREMENT

사람이 주로 어떤 영역을 수정하는지 보면 AI Rule을 개선할 수 있습니다.

✅ 26. Scope Violation Rate

Task 30개 중
범위 밖 파일 수정:
4개

Scope Violation:
13.3%

➕ 26-1. 높다면

Task Spec allowedPaths 개선
Prompt의 수정 범위 강조
대규모 Task 더 작게 분리

0909의 작업 단위 설계 품질을 검증하는 지표입니다.

✅ 27. Context Miss 추적

사람이 리뷰하면서 “AI가 이 규칙을 몰랐다”고 판단한 경우 기록할 수 있습니다.

failureCategory:
CONTEXT_MISSING

missingContext:
api-contract

➕ 27-1. 이후

Task type:
API DTO

api-contract pack 누락
  ↓
context-manifest 수정

0910의 Context 자동 개선 루프와 직접 연결됩니다.

✅ 28. Dashboard에서 보고 싶은 정보

처음에는 Markdown으로 충분하지만, 나중에는 간단한 Dashboard도 만들 수 있습니다.

최근 30일 Task
성공/실패율
평균 실행시간
AI 호출 횟수
평균 Retry
First Pass Success
Human Correction Rate
실패 Top 5
Domain별 Task 수

➕ 28-1. 꼭 필요한 것만

Tasks
Success Rate
Average Duration
Retry Rate
Top Failures

사용하지 않을 그래프를 많이 만드는 것은 의미가 없습니다.

✅ 29. 로컬 JSONL 로그

처음부터 DB를 만들 필요 없이 JSON Lines 형식으로 시작할 수 있습니다.

~/.llm-work/logs/
  runs/
    2026-09.jsonl

내용:

{"runId":"run_1","taskId":"142","step":"CONTEXT_BUILD","status":"PASSED","durationMs":810}
{"runId":"run_1","taskId":"142","step":"AI_WORK","status":"PASSED","durationMs":31521}
{"runId":"run_1","taskId":"142","step":"TYPECHECK","status":"FAILED","durationMs":4921}

➕ 29-1. 장점

구현 간단
append만 하면 됨
grep/jq 사용 가능
나중에 DB migration 가능

현재 자동화 규모에는 꽤 현실적인 시작 방식입니다.

✅ 30. Run Summary JSON

각 Run마다 하나의 Summary도 남길 수 있습니다.

{
  "runId": "run_20260911_093210_a82f",
  "taskId": "142",
  "project": "togethermall",
  "status": "SUCCEEDED",
  "risk": "HIGH",
  "durationMs": 82411,
  "aiCalls": 3,
  "retryCount": 1,
  "changedFiles": 5,
  "qaResult": "PASS_WITH_WARNINGS",
  "startedAt": "2026-09-11T00:32:10Z",
  "finishedAt": "2026-09-11T00:33:32Z"
}

Markdown은 사람이 보고 JSON은 자동화가 읽는 형태로 나누면 좋습니다.

✅ 31. 디렉터리 구조

~/.llm-work/
  logs/
    runs/
      2026-09.jsonl

  runs/
    run_20260911_093210_a82f/
      metadata.json
      steps.json
      qa-summary.json
      context.json
      report.md

➕ 31-1. 주의

Raw Prompt 저장 지양
Raw Diff 저장 지양
Secret 저장 금지

메타데이터 중심으로 저장하는 것이 안전합니다.

✅ 32. Task Report와 실행 지표 연결

0909의 Task Report에 추가:

## Automation

- Run ID: run_20260911_093210_a82f
- Total Duration: 82.4s
- AI Calls: 3
- Automatic Retries: 1
- QA: PASS_WITH_WARNINGS
- Scope Violation: No

작업 결과와 자동화 성능을 한 번에 볼 수 있습니다.

✅ 33. Daily Report에 자동화 기록 넣기

## AI/자동화 작업

- Task #142 완료
- QA 첫 실행에서 TypeScript 오류 발견
- Codex 자동 재작업 1회 후 정상 통과
- AI Review에서 API contract 확인 경고 발생
- 최종 수동 검토 후 완료

단순히 “AI 사용함”이 아니라 어떻게 검증했는지 기록하는 것이 좋습니다.

✅ 34. Weekly Report 자동 집계

## AI 개발 자동화

- 처리 Task: 9건
- First Pass Success: 6건
- 자동 재작업: 3건
- 최종 BLOCK: 0건
- 주요 실패 원인: Typecheck 2건, Integration Test 1건

주간 단위로 보면 자동화가 실제 도움이 되는지 판단하기 쉬워집니다.

✅ 35. Monthly Automation Review

# 2026년 9월 AI 개발 자동화 리뷰

## 처리량
- 총 Task: 32
- AI 사용 Task: 24

## 품질
- First Pass Success: 71%
- Human Correction Rate: 29%
- Scope Violation: 8%

## 주요 실패
1. TYPECHECK_FAILED
2. CONTEXT_MISSING
3. INTEGRATION_TEST_FAILED

## 개선
- API 변경 Task에 api-contract Pack 강제
- Repository transaction 규칙 추가
- Integration Test 선택 기준 보강

이렇게 해야 자동화도 지속적으로 개선할 수 있습니다.

✅ 36. Metric을 성과로 과장하지 않기

AI Task 30건 처리

이 숫자 자체는 회사 성과가 아닙니다.

➕ 36-1. 더 중요한 질문

반복 작업 시간이 줄었는가?
리뷰 누락이 줄었는가?
배포 전 오류를 더 많이 발견했는가?
문서 누락이 줄었는가?

AI 사용량은 수단이고 운영 결과가 성과입니다.

✅ 37. 자동화 성공률 100%가 목표는 아니다

모든 Task를 완전 자동으로 통과시키는 것이 목표가 아닙니다.
위험한 작업이 제대로 BLOCK되는 것도 성공입니다.

Secret 감지 → BLOCK

결과:
Run FAILED?

운영 관점:
안전장치 성공

➕ 37-1. 구분

Task Outcome:
BLOCKED

Safety Outcome:
SUCCESS

자동화 품질을 볼 때 이런 차이를 이해해야 합니다.

✅ 38. Alert가 필요한 상황

초기에는 실시간 알림까지 만들 필요는 없지만 다음 상황은 나중에 경고 대상으로 볼 수 있습니다.

Secret 감지
CRITICAL Task QA 실패
같은 Step 3회 연속 실패
AI Retry Limit 초과
Context Size Limit 초과
CI 반복 실패

➕ 38-1. 로컬에서는

터미널 강조 메시지
exit code
Markdown Report

정도로 충분합니다.

✅ 39. 실패 Run을 Troubleshooting으로 연결

0907과 연결합니다.

같은 ErrorCode 3회 발생
  ↓
Troubleshooting 후보 생성

➕ 39-1. 예시

TYPECHECK_FAILED:
일반적으로 문서화 필요 없음

CONTEXT_MISSING 반복:
자동화 Troubleshooting 작성 가치 있음

SCOPE_VIOLATION 반복:
AI Rule 개선 필요

반복되는 자동화 실패도 기술 부채로 볼 수 있습니다.

✅ 40. Common Mistakes 자동 후보

최근 30일:
Repository tx 누락 3회

결과:

⚠️ 반복 실패 패턴 발견

common-mistakes.md에 추가할 후보:
"Transaction 내부 Repository는 반드시 전달된 tx를 사용한다."

자동으로 문서를 수정하기보다는 후보를 제시하고 사람이 승인하는 것이 좋습니다.

✅ 41. AI Rule 효과 측정

규칙을 추가했다면 실제 효과를 확인할 수 있습니다.

Rule 추가 전:
Transaction 관련 실패 5/20

Rule 추가 후:
1/20

이렇게 되면 Knowledge Base가 실제 품질에 도움 되는지 볼 수 있습니다.

✅ 42. Observability도 과하게 만들지 않기

현재 단계에서 필요 없는 것:

Prometheus
Grafana Cluster
분산 Trace 플랫폼
대규모 데이터 Warehouse
실시간 비용 Dashboard

➕ 42-1. 지금 필요한 것

JSONL Run Log
Task Report
주간 집계
실패 ErrorCode
durationMs
retryCount

본업보다 자동화 인프라 만드는 시간이 커지면 방향이 잘못된 것입니다.

✅ 43. 추천 초기 데이터 모델

type AutomationRun = {
  runId: string;
  taskId?: string;
  project: string;

  status:
    | 'CREATED'
    | 'RUNNING'
    | 'SUCCEEDED'
    | 'FAILED'
    | 'BLOCKED'
    | 'CANCELED';

  risk?: 'LOW' | 'MEDIUM' | 'HIGH' | 'CRITICAL';

  startedAt: string;
  finishedAt?: string;
  durationMs?: number;

  aiCalls: number;
  retryCount: number;

  changedFileCount?: number;
  contextSize?: number;

  qaResult?: 'PASS' | 'PASS_WITH_WARNINGS' | 'BLOCK';
};

➕ 43-1. Step

type AutomationStep = {
  runId: string;
  type: string;
  status:
    | 'PENDING'
    | 'RUNNING'
    | 'PASSED'
    | 'FAILED'
    | 'WARNING'
    | 'SKIPPED';

  attempt: number;

  startedAt: string;
  finishedAt?: string;
  durationMs?: number;

  errorCode?: string;
};

처음에는 이 정도면 충분합니다.

✅ 44. CLI 명령어

llm-work stats
llm-work stats --month 2026-09
llm-work stats --project togethermall
llm-work runs
llm-work runs --failed
llm-work show-run <run-id>

➕ 44-1. 출력 예시

September 2026

Runs               18
Succeeded          14
Blocked             2
Failed              2

First Pass         72%
Avg Duration        68s
Avg AI Calls        2.4
Avg Retry           0.4

Top Failure
1. TYPECHECK_FAILED       4
2. CONTEXT_MISSING        2
3. SCOPE_VIOLATION        1

터미널 통계만 있어도 상당히 유용합니다.

✅ 45. `show-run`

llm-work show-run run_20260911_093210_a82f

출력:

Task #142
Status: SUCCEEDED
Risk: HIGH
Duration: 82.4s

Steps
✓ Context Build      1.2s
✓ AI Work           31.5s
✗ Typecheck          4.9s
✓ AI Rework         18.2s
✓ Typecheck          4.7s
✓ Integration       13.8s
! AI Review          8.1s

Warnings:
- API contract 수동 확인 권장

장애 분석뿐 아니라 자동화 자체의 디버깅에도 좋습니다.

✅ 46. Run Retention

실행 로그도 무한정 보관할 필요는 없습니다.

Run Metadata:
장기 보관 가능

상세 Step Logs:
3~6개월

임시 AI 응답:
작업 완료 후 삭제 가능

Raw Diff/Prompt:
기본 미보관

➕ 46-1. 이유

저장공간
보안
불필요한 오래된 데이터

메타데이터만 장기 보관하는 것이 현실적입니다.

✅ 47. 로컬 LLM 자동화 상태 확인

기존 Ollama 기반 보고 자동화에도 활용할 수 있습니다.

Model:
shn-coder

평균 생성시간:
12.8초

최근 성공률:
96%

실패:
Ollama not running 2회

➕ 47-1. 확인 가능한 것

모델 교체 효과
Prompt 변경 효과
입력 크기 증가 영향

모델 변경을 느낌이 아니라 결과로 비교할 수 있습니다.

✅ 48. 모델 비교 시 기준

속도
첫 QA 통과율
Human Correction
Retry 횟수
Context 처리 능력
비용

➕ 48-1. 단순 벤치마크보다

실제 Togethermall Task 10개

같은 고정된 내부 평가 세트를 만들어 비교하는 것이 더 실용적입니다.

다만 실제 고객 데이터나 Secret은 평가 데이터에서 제외해야 합니다.

✅ 49. Regression Task Set

자동화나 모델을 바꿀 때 다시 실행해볼 대표 Task 목록을 둘 수 있습니다.

TASK-TEST-01:
상담 상태 변경 구조 리뷰

TASK-TEST-02:
Permission 누락 찾기

TASK-TEST-03:
Prisma migration 위험 분석

TASK-TEST-04:
알림톡 retry 코드 리뷰

TASK-TEST-05:
일일 보고서 생성

➕ 49-1. 확인

모델 변경 전
vs
모델 변경 후

AI 시스템 자체에도 회귀 테스트 개념을 적용할 수 있습니다.

✅ 50. 현재 프로젝트 적용 우선순위

➕ 50-1. 1순위: Run/Step Log

runId
taskId
step
status
duration
errorCode

완료 기준:

어떤 작업이 어느 단계에서 실패했는지 확인 가능

➕ 50-2. 2순위: 기본 통계

Run 수
성공률
평균 실행시간
Retry
실패 ErrorCode

완료 기준:

llm-work stats로 최근 자동화 상태 확인

➕ 50-3. 3순위: Context/AI 메타데이터

Context Size
Context Packs
Prompt Version
Model
AI Calls

완료 기준:

Context와 Prompt 변경이 결과에 미치는 영향 추적 가능

➕ 50-4. 4순위: 품질 지표

First Pass Success
Human Correction Rate
Scope Violation Rate
Context Missing

완료 기준:

AI 자동화가 실제로 점점 나아지는지 판단 가능

➕ 50-5. 5순위: 자동 개선 후보

반복 실패
  ↓
Troubleshooting/Common Mistakes 후보

완료 기준:

실패 데이터가 AI Rule 개선으로 연결

지금은 Dashboard보다 데이터부터 잘 쌓는 것이 우선입니다.

✅ 51. Codex에게 Observability 기능을 맡길 때 규칙

기존 llm-work CLI에 AI 자동화 실행 Observability 기능을 추가해줘.

목표:
Task → Context → AI Work → QA → AI Review → Report 전체 실행 과정의 성공/실패와 실행시간을 추적하고 싶다.

조건:
1. Task 실행마다 고유 runId를 생성해줘
2. 하나의 Task가 여러 번 실행될 수 있으므로 Task와 Run을 분리해줘
3. Run 내부에는 Step을 기록해줘
4. Run 상태는 CREATED, RUNNING, SUCCEEDED, FAILED, BLOCKED, CANCELED를 사용해줘
5. Step 상태는 PENDING, RUNNING, PASSED, FAILED, WARNING, SKIPPED를 지원해줘
6. Step에는 startedAt, finishedAt, durationMs, attempt, errorCode를 기록해줘
7. CONTEXT_BUILD, AI_WORK, AI_REWORK, AI_REVIEW, TYPECHECK, LINT, UNIT_TEST, INTEGRATION_TEST, E2E_TEST, SECRET_SCAN, SCOPE_CHECK, TASK_REPORT 등의 Step type을 정의해줘
8. 로그는 구조화된 JSONL 형식으로 ~/.llm-work/logs/runs/<YYYY-MM>.jsonl에 저장해줘
9. 각 Run은 ~/.llm-work/runs/<runId>/metadata.json에도 Summary를 저장해줘
10. 실제 Prompt 전체, Git diff 전체, Secret, 전화번호, DATABASE_URL, Authorization header는 로그에 저장하지 마
11. 대신 promptTemplateVersion, promptHash, contextSize, contextFileCount, contextPacks 정도만 저장해줘
12. AI 호출 시 model/provider/operation과 사용 가능하면 input/output token 정보를 기록해줘
13. 외부 모델은 estimatedCost를 저장할 수 있게 하되 추정값임을 구분해줘
14. QA first-pass success 여부와 retryCount를 저장해줘
15. TYPECHECK_FAILED, TEST_FAILED, SCOPE_VIOLATION, SECRET_DETECTED, CONTEXT_MISSING, AI_TIMEOUT 등 ErrorCode를 표준화해줘
16. llm-work runs, llm-work runs --failed, llm-work show-run <runId>, llm-work stats 명령을 추가해줘
17. stats에는 총 Runs, 성공/실패/Blocked, 평균 실행시간, 평균 Retry, First Pass Success, 실패 ErrorCode Top 목록을 보여줘
18. Task Report에 Run ID, Duration, AI Calls, Retry Count, QA 결과를 자동 추가해줘
19. 반복 실패 패턴을 발견하면 Troubleshooting 또는 common-mistakes 후보를 제안할 수 있게 구조를 열어줘
20. 로그 Retention 정책을 설정 가능하게 해줘
21. 테스트와 사용 방법을 문서화해줘

➕ 51-1. 리뷰 기준

Task와 Run을 구분하는가?
Step 단위 실행시간을 확인할 수 있는가?
로그가 구조화되어 있는가?
민감한 Prompt/Diff를 저장하지 않는가?
실패 ErrorCode가 표준화되어 있는가?
Retry 기록을 덮어쓰지 않는가?
통계가 실제 Run 데이터를 기반으로 하는가?
Dashboard 같은 과한 구조부터 만들지 않는가?

✅ 52. 실무 체크리스트

➕ 52-1. Run Logging

모든 실행에 runId가 있는가?
taskId와 runId가 구분되는가?
Step별 상태가 기록되는가?
실행시간이 기록되는가?
Retry attempt가 기록되는가?
실패 ErrorCode가 기록되는가?
로그 저장 실패가 본 작업을 무조건 망치지 않는가?
시간대 기준이 일관적인가?

➕ 52-2. AI Metadata

사용하는 모델이 기록되는가?
Prompt 버전이 기록되는가?
Context Pack이 기록되는가?
Context 크기가 기록되는가?
AI 호출 횟수가 기록되는가?
Retry 횟수가 기록되는가?
가능하면 token 사용량을 기록하는가?
Prompt 원문은 불필요하게 저장하지 않는가?

➕ 52-3. 품질 지표

First Pass Success를 계산할 수 있는가?
Human Correction 여부를 남길 수 있는가?
Scope Violation을 집계할 수 있는가?
Context Missing 사례를 기록할 수 있는가?
반복 실패 유형을 찾을 수 있는가?
Prompt/Rule 변경 전후를 비교할 수 있는가?
모델 변경 전후를 비교할 수 있는가?
단순 AI 사용량을 성과로 착각하지 않는가?

➕ 52-4. 보안

Raw Prompt를 기본 저장하지 않는가?
Git Diff 전체를 저장하지 않는가?
실제 고객 데이터가 로그에 없는가?
전화번호가 없는가?
Authorization/JWT가 없는가?
DATABASE_URL이 없는가?
API Key/Secret이 없는가?
Log Retention 기준이 있는가?

✅ 53. AI에게 AI 자동화 Observability를 물어볼 때 좋은 질문법

Node.js CLI 기반 AI 개발 작업 자동화 시스템의 Observability를 설계하려고 해.

현재 구조:
1. Task Spec을 기반으로 Codex 작업을 실행함
2. Task마다 Context Pack과 ADR/Troubleshooting을 자동으로 선택함
3. 이후 typecheck, lint, unit/integration test, scope check, AI Review를 실행함
4. 일부 명확한 오류는 최대 2회 정도 AI 재작업을 수행함
5. 마지막에 Task Report와 Daily Report를 생성함
6. 모든 코드는 1인 개발 환경에서 운영하고 있으므로 과한 인프라는 피하고 싶음

추적하고 싶은 것:
- Task/Run 상태
- 각 Step 실행시간
- 실패 단계와 ErrorCode
- AI 호출 횟수
- Retry 횟수
- Context 크기와 사용 Pack
- Prompt Version
- Model
- Token/비용이 제공되면 해당 값
- First Pass Success
- Human Correction
- Scope Violation
- Context Missing 사례

보안:
- Raw Prompt 전체 저장 금지
- Git diff 전체 저장 금지
- Secret/API Key/JWT/DATABASE_URL 저장 금지
- 고객 개인정보 저장 금지

요청:
- Task/Run/Step 데이터 모델
- JSONL 기반 로컬 로그 구조
- ErrorCode 표준
- duration/retry 기록 방식
- Prompt/Context version 추적
- Token/비용 추적 기준
- First Pass Success/Human Correction 같은 품질 지표
- llm-work runs/stats/show-run CLI 구조
- Task/Daily/Weekly Report 연결
- 반복 실패를 Knowledge Rule 개선으로 연결하는 방법
- Retention 정책
- 구현 우선순위
를 실무적으로 정리해줘.

➕ 53-1. AI 답변 검증 기준

Task와 Run을 구분하는가?
Step 단위 추적을 제안하는가?
단순 성공률만 품질로 보지 않는가?
First Pass/Human Correction 같은 실제 결과 지표를 사용하는가?
Prompt와 Context Version을 추적하는가?
Raw Prompt/Diff 저장 위험을 지적하는가?
처음부터 대규모 Observability Stack을 요구하지 않는가?
기존 QA/Context/Report 흐름과 연결하는가?

📌 요약

AI 개발 자동화가 Task → Context → Codex → QA → Review → Report까지 확장되면 자동화 자체도 하나의 운영 시스템으로 보고 관측 가능하게 만드는 것이 좋습니다.
Task는 해야 할 업무이고 Run은 해당 Task를 실제로 실행한 한 번의 시도이므로 서로 분리해야 하며, 하나의 Run 내부에 Context Build, AI Work, QA, Review 같은 Step을 기록하면 좋습니다.
각 Step에는 상태, 실행시간, attempt, errorCode를 남겨 어떤 단계가 느리거나 자주 실패하는지 파악할 수 있어야 합니다.
로그에는 실제 Prompt, Git diff, 고객 개인정보, Secret을 그대로 저장하기보다 Prompt Version, Hash, Context 크기, Pack, 모델, 실행시간 같은 메타데이터를 저장하는 것이 안전합니다.
Prompt와 Context도 코드처럼 버전이 바뀌므로 실행 당시 어떤 버전이 적용됐는지 기록하면 AI 작업 결과가 달라진 원인을 분석하기 쉬워집니다.
AI 호출 횟수, Retry 횟수, Context 크기와 외부 모델의 token/추정 비용을 Task별로 기록하면 불필요하게 비싼 자동화 흐름을 찾을 수 있습니다.
자동화 품질은 단순 AI 호출 수보다 First Pass Success, Human Correction Rate, Scope Violation Rate, 반복 실패, 배포 후 회귀 여부 같은 실제 결과를 기준으로 보는 것이 좋습니다.
자동화가 Task를 BLOCK했다고 해서 반드시 실패한 것은 아니며, Secret이나 위험한 Migration을 차단했다면 안전장치로서는 성공입니다.
초기에는 Prometheus/Grafana 같은 큰 관측 시스템보다 JSONL Run Log + Run Summary + llm-work stats 정도로 시작하는 것이 1인 개발 환경에 더 적합합니다.
반복되는 ErrorCode와 Context Missing 사례를 Troubleshooting → Common Mistakes → AI Rule/Context Manifest 개선으로 연결하면 자동화가 실제 경험을 바탕으로 점점 안정화되는 구조를 만들 수 있습니다.
현재 적용 순서는 Run/Step Log → 기본 통계 → Prompt/Context/Model 메타데이터 → 품질 지표 → 반복 실패 기반 Knowledge 개선 정도가 현실적입니다.

juni

이전 포스트

TIL - 20260910

다음 포스트