에이전트 프레임워크 스터디 Day 13: Trace는 로그가 아니라 다음 실행을 바꾸는 증거 사슬이다

Event 1: user_message
Event 2: tool_call
Event 3: tool_result
Event 4: assistant_message

Request
  -> Interpreted Goal
  -> Planned Scope
  -> Evidence Read
  -> Action Taken
  -> Verification Run
  -> Result Reported
  -> Reusable Learning Candidate

도구 호출 전 상태:
- 어떤 가정이 있었나?
- 어떤 파일/리소스를 확인해야 했나?
- 어떤 위험이 있었나?

도구 호출 후 상태:
- 무엇이 사실로 확인됐나?
- 무엇이 틀렸나?
- 다음 행동이 어떻게 바뀌었나?

event: verification_command
command: pnpm build
scope: SEOJing web app
reason: new MDX route and content tree generation must compile
exit_code: 0
result: pass
state_change:
  before: post written but route/build unverified
  after: local production build verified

1. 사용자 의도 증거
2. 외부/로컬 source 증거
3. 실행 증거
4. 검증 증거

사용자 요청:
- 04:00 run에서 agent-framework study post를 실제로 작성하고 push한다.
- backend series는 Day 12로 제한한다.
- LMS는 방학 중이므로 크롤링하지 않는다.
- 새 기술은 중복 상태를 갱신하고 반복 노출하지 않는다.

- repo status
- 기존 Day 12 글
- Agent Framework Evolution Standards
- briefing_seen.json
- package scripts
- ticket 상태

- apps/web/content/study/agent-framework/day13.mdx 생성
- cover metadata 삽입
- inline visual asset 추가
- git commit 생성
- origin main push

- prettier check
- lint
- build
- content tree generation
- git diff --check
- origin/main HEAD 일치 확인
- public route readback

{
  "task": "publish study post",
  "status": "success"
}

{
  "workflow_key": "seojing-agent-framework-study-publish",
  "outcome": "success",
  "scope": {
    "repo": "SEOJing",
    "branch": "main",
    "files": ["apps/web/content/study/agent-framework/day13.mdx"]
  },
  "verification": {
    "format": "pass",
    "lint": "pass",
    "build": "pass",
    "public_route": "pass"
  },
  "lessons": [
    "dirty canonical checkout requires isolated origin/main worktree",
    

1. 같은 workflow가 반복 성공했는지 센다.
2. 실패가 반복되는 지점을 찾는다.
3. skill/checklist/eval로 승격할 만한 절차를 고른다.

반복 trace
  -> checklist 개선
  -> skill/reference 강화
  -> 작은 eval set 생성
  -> 필요하면 local policy/router 데이터셋
  -> 훨씬 나중에 adapter/fine-tune 검토

- draft file
- patch
- screenshot
- generated image
- ticket report
- build log
- public URL
- review finding
- workflow trace

draft file
  -> reviewer가 읽을 입력

build log
  -> 실패 원인 분류의 입력

public URL
  -> 배포 검증의 입력

ticket report
  -> 다음 세션 handoff의 입력

workflow trace
  -> skill/eval 후보 판단의 입력

artifact_id
kind: draft | patch | image | report | log | url | trace
path_or_url
created_by
source_task
verification_status
freshness
safe_to_share

- 모든 tool call을 OTEL span으로 변환
- 비용/latency/token을 전부 수집
- UI 대시보드 제작
- replay 기능
- evaluation harness
- prompt diff viewer

workflow_trace
- key
- title
- source_ref
- loaded_skills
- input_contract
- changed_artifacts
- verification_json
- outcome
- failure_classification
- reusable_rule_candidate

- 04:00 publish가 몇 번 성공했나?
- 실패는 주로 install, lint, route probe, public deploy 중 어디서 났나?
- 어떤 workflow는 이미 skill로 승격할 만큼 반복됐나?
- 어떤 report style이 8AM briefing에서 중복을 줄였나?

memory:
- 오래 유지되는 사용자 선호
- 환경의 안정적 사실
- 반복적으로 필요한 규칙

trace:
- 특정 실행의 입력/출력/검증
- 특정 날짜의 실패/성공
- artifact와 로그
- 다음 개선 후보

2026-06-23에 Day 13을 push했다.
commit SHA는 ...
이번 build는 13초 걸렸다.
오늘 OCR이 unavailable이었다.

SEOJing scheduled publish는 canonical checkout이 dirty면 origin/main worktree에서 한다.
content-only MDX publish에서 OCR이 unsupported_ext면 content review gate로 대체한다.
새 글은 cover/inline visual suitability step을 명시적으로 보고한다.

trace many times
  -> repeated pattern confirmed
  -> skill/reference/memory candidate
  -> human-readable operating rule

failure_point:
- discovery
- tool execution
- dependency install
- verification
- external service
- permission/auth
- report/delivery

recoverability:
- retried and succeeded
- blocked on user/browser auth
- safe to retry later
- requires code/config change

blast_radius:
- no file changed
- local draft changed only
- committed but not pushed
- external side effect happened

route probe 404 immediately after push
  -> GitHub Actions deploy not complete yet일 수 있음
  -> CI run을 먼저 poll해야 함

old:
push -> curl route -> 404면 실패

new:
push -> GitHub Actions deploy 완료까지 poll -> browser-like GET -> title readback

Agent Runtime -> stdout -> log collector

LLM call span only

User Request
  -> Planner / Goal Interpreter
  -> Context Builder
  -> Tool Dispatcher
  -> Artifact Store
  -> Verification Gate
  -> Reporter
  -> Memory/Skill Candidate Extractor

           Trace Layer
  records: intent, evidence, actions, artifacts, verification, outcome

이 보고서의 “pass”는 어떤 command result에서 왔나?
이 ticket done은 어떤 artifact를 근거로 했나?
이 memory write는 어떤 반복 trace에서 승격됐나?
이 external publish는 어떤 standing approval 아래 실행됐나?

- sessions: 대화 흐름
- hermes-ticket: 작업 상태와 결과 보고
- cron output: scheduled run 결과
- work-ledger: spoke 계약과 artifact pointer
- git history: 코드/콘텐츠 변경
- workflow traces: 반복 workflow 후보
- skills: 검증된 절차의 압축본

1. 중요한 workflow마다 source_ref를 남긴다.
2. 결과 보고에 실제 검증 command를 붙인다.
3. 반복 성공/실패를 workflow trace로 기록한다.
4. trace가 쌓이면 skill/reference/eval로 승격한다.
5. memory에는 오래갈 규칙만 남긴다.

무슨 요청이었나?
어떤 증거를 읽었나?
무엇을 바꿨나?
어떻게 검증했나?
무엇을 다음 실행 규칙으로 흡수할까?

run_publish_workflow(task):
  trace.start(workflow_key="seojing-agent-framework-study-publish")

  trace.record_intent(task.standing_approval)

  repo_state = git.status()
  trace.record_source("repo_state", repo_state)

  if repo_state.has_unrelated_changes:
    worktree = create_worktree("origin/main")
    trace.record_decision("use isolated worktree", reason="protect unrelated local work")

  next_day = inspect_existing_posts()
  trace.record_source("latest_post", next_day - 1)

  draft = write_mdx(next_day)
  trace.record_artifact("draft", draft.path)

  visual = run_visual_suitability_check(draft)
  trace.record_decision("visual", visual.status)

  checks = run(["prettier", "format:check", "lint", "build"])
  trace.record_verification(checks)

  if checks.pass:
    commit = git.commit(scope=draft.files)
    push = git.push("origin", "HEAD:main")
    trace.record_artifact("commit", commit.id)
    trace.record_external_effect("push", push.status)
  else:
    trace.fail(classification="verification_failure")
    return

  route = probe_public_url(next_day)
  trace.record_verification("public_route", route.status)

  trace.finish(outcome="success")

로그:
- 어떤 일이 있었는지 보여준다.

trace:
- 왜 그 일이 필요했는지
- 무엇을 근거로 판단했는지
- 어떤 산출물이 생겼는지
- 검증은 실제로 무엇을 증명했는지
- 다음 실행 규칙이 어떻게 바뀌어야 하는지 보여준다.

Agent Card가 “맡길 수 있는 경계”라면,
Trace는 “맡긴 뒤 믿고 이어받을 수 있는 증거”다.