Faultline은 운영자의 질문에 대한 집중적인 답변으로 시작되었습니다: 어떤 에이전트 실행이 잘못되었는가, 무엇을 결정했는가, 그리고 SigNoz의 증거는 어디에 있는가?

이는 유용하지만, 조사만으로는 운영자에게 브라우저 가득한 증거만 남길 뿐 제어된 행동 방식은 제공하지 못합니다. 이번 후속 릴리스에서는 Recovery Studio를 추가합니다: 실패했거나 위험한 에이전트를 선택하고, 가장 유용한 최소한의 입력을 변경한 뒤, 파이프라인의 영향을 받은 부분만 다시 실행하고, 새로운 트레이스 (trace)를 기존 것과 비교할 수 있습니다.

중요한 제약 사항은 이것이 두 번째 관측성 (observability) 대시보드가 아니라는 점입니다. 셀프 호스팅되는 SigNoz는 여전히 트레이스 (traces), 로그 (logs), 메트릭 (metrics) 및 알림 (alerts)을 위한 기록 시스템 (system of record)으로 남습니다. Faultline은 특정 에이전트 실행을 중심으로 하는 운영자 워크플로우 (workflow)입니다.

복구 루프 (The Recovery Loop)

운영자는 세 가지 필드를 변경할 수 있습니다:

• 선택된 에이전트를 위한 태스크 프롬프트 (task prompt).
• OpenAI 호환 모델 식별자 (model identifier).
• 복구를 위한 토큰 예산 (token budget).

시스템 프롬프트 (system prompt)와 상위 아티팩트 (upstream artifacts)는 불변 (immutable) 상태로 유지됩니다. 이를 통해 복구 과정의 비교가 가능해집니다. 즉, 변경 사항이 원래 워크로드 (workload)의 숨겨진 재작성이 아니라 명시적으로 이루어집니다.

범위는 제품 결정 사항입니다

다음과 같은 파이프라인의 경우:

Planner -> Architecture -> Design system -> Primary screen -> Expo preview

Architecture에서 시작하는 복구는 Planner를 다시 실행하지 않습니다. Faultline은 Planner를 reused로 표시하고, 해당 아티팩트를 읽기 전용 컨텍스트 (read-only context)로 보존하며, 새로운 트레이스 (trace) 상에서 Architecture부터 Preview까지 실행합니다.

러너 (runner)는 명시적인 계보 (lineage)를 가진 자식 실행 (child run)을 생성합니다:

type RecoveryConfig = {
  taskPrompt: string;
  model: string;
...

이는 세 가지 유용한 보장을 제공합니다:

1. 소스 실행 (source run)은 절대 변형되지 않습니다.
2. 운영자는 이미 검증된 상위 작업(upstream work)을 재생성하는 데 비용을 지불하지 않습니다.
3. 복구 트레이스 (recovery trace)는 SigNoz에서 조사를 위해 명확한 부모 관계 (parent relationship)를 가집니다.

SigNoz를 중복 생성하지 않는 SigNoz 상관관계 (Correlation)

각 복구 (recovery)는 별도의 agent.run 트레이스 (trace)를 방출하며 계보 (lineage) 속성을 추가합니다:

await inSpan("agent.run", {
  "faultline.run_id": run.id,
  "faultline.parent_run_id": run.parentRunId,
...

Faultline은 OTLP를 통해 프롬프트 (prompts), 출력 (outputs), 재시도 (retries), 아티팩트 (artifacts) 및 실패 (failures)를 계속해서 기록합니다. 콘솔은 SigNoz의 쿼리 빌더 (query builder)나 일반적인 대시보드 (dashboards)를 복제하는 대신, 세 개의 압축된 증거 캡슐 (evidence capsules)과 네이티브 SigNoz 링크를 렌더링합니다.

운영자는 다음과 같은 집중된 전/후 차이 (before/after delta)를 확인할 수 있습니다:

• 상태 (status) 및 실패 원인 (failure reason)
• 지속 시간 (duration), 토큰 (tokens) 및 재시도 (retries)
• 아티팩트 (artifact) 및 모델 출력 상태 (model output state)
• 직접적인 소스 (source) 및 복구 트레이스 (recovery trace) 링크
• 사용 가능한 경우 소스 (source) 및 복구 Expo 미리보기 (preview) 링크

예산 및 제공자 가드레일 (Budget and Provider Guardrails)

복구는 초기 데모 시나리오보다 의도적으로 더 제어된 방식으로 이루어집니다. 각 복구 단계의 요청 전에, Faultline은 남은 복구 예산 (recovery budget)을 확인하고 그에 따라 max_tokens를 제한합니다. 예산이 남아있지 않으면, 또 다른 다운스트림 에이전트 (downstream agent)를 시작하기 전에 중단합니다.

제공자 실패 (Provider failures)는 별도의 모델 호출 없이 분류됩니다:

function classifyIncident(error?: string) {
  const message = (error || "").toLowerCase();
  if (message.includes("429") || message.includes("rate limit")) {
...

이는 실무에서 중요합니다. 개발 중에 OpenRouter는 무료 모델 일일 허용량이 소진된 후 429를 반환했습니다. Faultline은 이제 이를 도움이 되지 않는 LLM 429로 뭉뚱그리는 대신, 안전한 제공자 사유 (safe provider reason)와 재시도 안내 (retry guidance)를 에이전트 도시에 (agent dossier) 및 상관관계가 있는 로그 (correlated logs)에 기록합니다.

내구성 있고 의존성 없는 히스토리 (Durable, Dependency-Free History)

Faultline은 여전히 로컬의 단일 운영자 워크플로우 (local, single-operator workflow)에 최적화되어 있습니다. 이제 최신 100개의 실행 (runs)을 .faultline/runs.json에 영구 저장하며, 이는 Git에서 제외됩니다. 저널 (journal)은 임시 파일을 사용한 후 이름을 변경하는 방식으로 원자적 (atomically)으로 작성되며, 러너 (runner)가 시작될 때 로드됩니다.

await mkdir(dirname(journalPath), { recursive: true });
await writeFile(temporary, snapshot, "utf8");
await rename(temporary, journalPath);

이것은 의도적으로 다중 사용자 데이터베이스 (multi-user database)로 설계되지 않았습니다. 로컬 스택 (local stack)을 재시작한 후 조사를 다시 열거나, 데모 중에 소스/복구 (source/recovery) 관계를 보존하기에는 충분합니다.

API Surface (API 표면)

POST /api/runs
POST /api/runs/:runId/recoveries
GET  /api/runs
...

복구 요청 예시:

{
  "agentId": "architecture",
  "taskPrompt": "Design a pragmatic Expo architecture. Keep it concise.",
...

복구 시나리오 테스트 (Testing the Recovery Story)

이 프로젝트는 내장된 Node 테스트 러너 (test runner)를 사용하여 복구 프리미티브 (recovery primitives)를 검증하므로, 이번 릴리스를 위해 추가된 의존성 (dependency)은 없습니다:

npm run build
npm test

테스트는 업스트림 아티팩트 재사용 (upstream artifact reuse), 인시던트 분류 (incident classification), 안정적인 핑거프린트 (stable fingerprints), 그리고 복구 예산 경계 (recovery-budget boundaries)를 다룹니다. 전체 로컬 데모는 다음과 같습니다:

npm run signoz:up
npm run dev

그 다음 콘솔에서 주입된 인시던트 (injected incident)를 실행하고, Architecture를 선택한 뒤, Start recovery를 사용하여 소스 (source)와 복구 (recovery) 트레이스 (traces)를 비교하세요.

제품의 변경 사항

Faultline은 더 이상 단순한 플라이트 레코더 (flight recorder)가 아닙니다. 이제 증거와 행동 사이의 루프를 완성합니다:

관찰 (Observe) -> 설명 (Explain) -> 조정 (Adjust) -> 재실행 (Rerun) -> 비교 (Compare) -> SigNoz로 에스컬레이션 (Escalate to SigNoz)

이것이 텔레메트리 (telemetry)의 좋은 데모와 유용한 운영 도구 (operator tool)를 가르는 차이점입니다.

코드 및 기타 정보: https://www.dailybuild.xyz/project/202-faultline