상태 가이드

VOC 한 건은 접수 → 분석 → 재현 → 검증 → 종료 5단계 파이프라인을 따라 흐릅니다. 각 단계에서 잡이 갖는 상태(JobStatus)를 단계 안에 겹쳐 설명합니다. 색·라벨은 대시보드·상세 화면의 배지와 동일합니다(§5.3).

🗺 아키텍처 다이어그램 보기

전체 워크플로우 · 잡 상태 머신 · 처리 시퀀스(락·보충질문·적대 루프)를 Mermaid 다이어그램으로. 새 탭에서 열립니다.

파이프라인 한눈에

정상 처리 경로

대기분석 중재현 대기재현 중검증 중완료

1. 단계별 프로세스와 상태

5단계 · 상태 10종

  1. 접수 단계

    1선 상담원

    VOC 를 등록하면 잡이 생성되어 큐에 들어간다. 단, HTTP 500 제보는 분석 큐를 건너뛰고 즉시 에스컬레이션한다(§5.2).

    이 단계의 상태

    • 대기접수 직후 큐에 적재된 초기 상태. run_job 이 곧바로 분석으로 넘긴다.
    분기 → ESCALATED_500·500 제보는 여기서 곧장 종료로 직행(슬랙 알림·태스크 미생성).

  2. 분석 단계

    서브 에이전트

    코드를 정적 분석(grep·파일 확인)해 근본 원인 가설과 트리아지 예비치를 증거 기반으로 세운다.

    이 단계의 상태

    • 분석 중서브 에이전트가 코드를 정적 분석해 근본 원인 가설·트리아지 예비치를 도출한다(§5.4 A).

  3. 재현 단계

    서브 에이전트

    회사(테넌트) 단위 직렬 락을 잡고 실제 환경에서 동적 재현한 뒤, 제보와 현실의 차이를 교차검증한다. 회사 간은 병렬, 회사 내는 직렬.

    이 단계의 상태

    • 재현 대기회사(테넌트) 단위 직렬 락을 확보하려 대기. 같은 회사의 다른 잡이 재현 중이면 여기서 줄을 선다(회사 간은 병렬).
    • 재현 중락을 쥔 채 실제 환경에서 동적 재현하고, 제보와 현실의 차이를 교차검증한다(§5.4 B·C).
    분기 → BLOCKED·재현 실패(재현 안 됨·차단)면 태스크 없이 BLOCKED 로 종료 → 사람 개입(§5.6).

  4. 검증 단계

    검증 에이전트

    컨텍스트를 공유하지 않는 분리 세션이 결론을 적대적으로 반박한다. 통과하면 종료로, 반박에 성공하면 반려한다.

    이 단계의 상태

    • 검증 중분리된 세션의 검증 에이전트가 결론을 반박하려 시도한다. 무할루시네이션 위반이 1순위 반려 사유(§5.5).
    • 반려검증 반려. 분석 단계로 회귀하며 rejection_rounds 를 올린다.
    분기 → ANALYZING·반려 시 분석(2단계)으로 회귀. 반려 상한 3회 도달 시 BLOCKED(§5.5).

  5. 종료 단계

    오케스트레이터

    검증을 통과한 잡만 tasks.json 으로 직렬화하고 Linear 로 내보낸다. 그 외 종료는 사람 개입(UI)·슬랙으로 마무리된다. 종료 상태는 더 이상 전이하지 않는다.

    이 단계의 상태

    • 완료검증 통과 — tasks.json 으로 직렬화하고 Linear 로 내보낸 정상 종료.
    • 차단재현 실패·반려 상한 도달 등으로 막힌 종료 — 사람 개입(UI) 대기.
    • 실패치명적 오류로 더 진행할 수 없는 종료.
    • 500 에스컬레이션500 에러 제보의 직행 종료 — 큐를 거치지 않고 슬랙으로 알리며 태스크를 만들지 않는다.

2. 교차 상태 (어느 단계서든)

상태 1종 + 비상 종료

특정 단계에 묶이지 않고, 진행 중 어느 단계에서나 끼어들 수 있는 상태입니다.

  • 보충질문 대기정보가 부족해 보충질문을 발행하고 1선 답변을 기다린다(재현 중이었다면 테넌트 락을 풀고 대기, §5.12).

비상 종료 — 비종료 상태 어디서든, 치명 오류는 FAILED, 진행 불가·상한 도달은 BLOCKED 로 빠집니다. 보충질문은 답변 후 직전 단계로 복귀합니다(재현 발은 락 해제로 재현 대기 경유, §5.12).

3. 단계가 남기는 판정값 (voc_evidence)

6종

각 단계는 결과를 증거(meta.voc_evidence)에 정직하게 기록합니다. 아래는 그 값들이며, 어느 단계에서 채워지는지 함께 표기했습니다. 상세 화면의 배지로 그대로 노출됩니다.

재현 상태

3 재현 단계reproduced.status

동적 재현 결과. 못 했으면 못 했다고 정직하게 남긴다(무할루시네이션).

  • 재현됨reproduced—제보된 증상을 그대로 재현했다.
  • 부분 재현partially—일부 조건/증상만 재현했다.
  • 재현 안 됨not_reproduced—재현을 시도했으나 증상이 나타나지 않았다 → BLOCKED 종료.
  • 재현 차단blocked—환경·권한·설정 미비로 재현 자체가 불가능했다 → BLOCKED 종료.

제보 vs 현실 차이

3 재현(교차검증) 단계divergence.level

제보 내용과 실제 재현·분석 결과의 차이를 분류한다.

  • 일치matches—제보와 현실이 일치한다.
  • 더 광범위broader—실제 영향이 제보보다 더 광범위하다.
  • 더 협소narrower—실제 영향이 제보보다 더 좁다.
  • 상이different—제보와 다른 원인/증상으로 드러났다.
  • 재현 불가unreproducible—현실에서 재현되지 않아 차이를 판정할 수 없다.

범위 평가

3 재현(교차검증) 단계scope_assessment.level

이슈를 하나의 태스크로 둘지, 분할할지 결정하는 근거.

  • 단순simple—단일 태스크로 처리 가능한 단순 범위.
  • 연쇄 가능cascading_possible—연쇄 영향 가능성이 있어 주의가 필요하다.
  • 분할 필요needs_decomposition—여러 태스크로 분할해야 하는 복합 범위.

심각도

2 분석 단계triage.severity

트리아지 심각도. tasks.json 의 우선순위(priority)로 매핑된다.

  • 치명critical—서비스 중단·데이터 손상 등 즉시 대응이 필요한 수준.
  • 높음high—핵심 기능 장애로 우선 처리가 필요한 수준.
  • 보통medium—기능 일부 불편이나 우회 가능한 수준.
  • 낮음low—경미하거나 미관 수준의 이슈.

검증 판정

4 검증 단계verification.verdict

분리 검증 세션의 최종 판정.

  • 통과passed—검증 통과 — 결과를 신뢰할 수 있다 → COMPLETED.
  • 반려rejected—검증 반려 — 분석으로 회귀한다 → REJECTED.

부수효과 복구

종료 후(사후) 단계side_effect.remediation / remediation.side_effects_remediated

재현 과정에서 생긴 부수효과(결제·메일·삭제 등)의 복구 상태.

  • 해당 없음none—복구할 부수효과가 없다.
  • 복구 대기pending—복구가 필요하나 아직 처리 전이다.
  • 부분 복구partial—일부만 복구되었다.
  • 복구 완료done—해당 부수효과를 복구 완료했다.
  • 전체 복구complete—모든 부수효과를 전부 복구했다.
  • 복구 불가irreversible—되돌릴 수 없는 부수효과다.