테스트벤치 가이드

1. 오른쪽 위 DB 칩이 원본 앱 백엔드와 같은 DB 인지 봅니다. 이 도구는 그 DB 의 행을 직접 지우고 덮어씁니다.
2. 백엔드 칩 앞의 점이 초록이면 백엔드가 떠 있는 것입니다. 빨강이면 단계 시작 버튼이 동작하지 않습니다.
3. 자동 체크포인트 는 켜 두세요. 사건이 단계 사이에 멈출 때마다 알아서 저장해 주므로, 미리 저장하지 않았어도 되돌아갈 수 있습니다.

한 번 올린 서류는 테스트셋으로 남겨 두고, 그 뒤로는 복원 → 실행 → 비교 만 되풀이합니다. 서류를 다시 올리거나 DB 를 손으로 고칠 일이 없습니다.

예시 1 — 요약 프롬프트를 고친 뒤, 요약만 다시 돌려 전후 비교

1. 사건 목록에서 요약까지 끝난 사건(ANALYSIS_COMPLETED)을 엽니다.
2. 아래 「체크포인트」 목록에 요약 완료 시점이 「자동」 으로 저장돼 있는지 봅니다. 이것이 고치기 전 결과입니다.
3. 프롬프트(또는 백엔드 코드)를 고치고 백엔드를 다시 띄웁니다.
4. 단계 막대의 요약 칸에서 ↺ 다시 실행 을 누릅니다. 요약 조건은 지난번 것이 채워져 있으니 그대로 실행 합니다.
5. 끝나면 2번의 체크포인트에서 더보기 → 비교 를 누릅니다. 「고치기 전 ↔ 지금」 의 요약 문장 차이가 보입니다.

예시 2 — 사건 3건을 처음부터 끝까지 자동으로 돌려 소요 시간 재기

1. 「접수」 화면에서 사건 폴더 3개를 고르고, 접수가 끝나면 테스트셋으로 저장 을 켠 채 접수 합니다.
2. 「시나리오」 화면에서 그 테스트셋 3개에 체크합니다.
3. 어디까지 = 요약까지, 미분류 낱장 = 지정한 문서종으로 확정하고 계속, 지정 문서종 = ✓ 기타, 동시 실행 = 1건씩으로 둡니다.
4. 요약 조건 은 「계약 전 알릴의무」 에 체크하고 상품명만 적은 뒤 3건 실행 을 누릅니다.
5. 자리를 비워도 됩니다. 끝나면 사건별 분류·추출·요약 소요 시간이 표로 남습니다.

예시 3 — 잘못 눌렀을 때 되돌아가기

1. 사건 화면의 「체크포인트」 에서 자동·백업 포함 을 켭니다.
2. 맨 위의 「백업」 이 방금 누르기 직전 상태입니다. 그 줄의 복원 을 누릅니다.

서류 폴더가 어떻게 생겼는지에 따라 화면 위에서 방식을 고릅니다.

사건 폴더로 접수 — 폴더 1개가 사건 1건일 때

사건 폴더 / 하위 폴더 / 서류 모양이면 이 방식을 씁니다. 하위 폴더는 이미지시스템의 문서분류 폴더로 넘어갑니다.

1. 사건 폴더들이 들어 있는 폴더(또는 사건 폴더 하나)의 경로를 넣고 열기 를 누릅니다.
2. 표에서 올릴 사건에 체크합니다. 위탁사와 피보험자는 폴더 이름에서 읽어 채워 두며, 틀리면 표에서 바로 고칩니다.
3. 사건 이름을 누르면 하위 폴더가 펼쳐집니다. 뺄 폴더는 체크를 끄고, 새 분류 표시는 그 위탁사 문서분류에 없는 이름이라 새로 추가된다는 뜻입니다.
4. 가볍게 돌려 보려면 폴더별 최대 에 숫자를 넣습니다. 3 을 넣으면 하위 폴더마다 앞 3장만 올립니다.
5. 접수 를 누르면 고른 사건이 차례로 올라가고, 사건마다 READY_FOR_CONFIRM 이 뜨면 끝입니다.

이미 접수해 테스트셋이 있는 사건은 표의 테스트셋 칸에 ★ 와 접수번호가 보입니다. 접수번호를 누르면 그 사건으로 가고, 테스트셋 있는 N건 숨기기 로 아직 안 올린 사건만 볼 수 있습니다.

파일을 골라 접수 — 서류가 한 폴더에 섞여 있을 때

1. 폴더 경로를 넣고 열기 를 누른 뒤, 사건 묶음(파일명 앞 번호)과 문서종 으로 좁혀 올릴 서류에 체크합니다. 파일 이름을 누르면 미리 볼 수 있습니다.
2. 접수번호(자동 추천)와 위탁사를 확인하고 접수 를 누릅니다. 여러 묶음을 골랐다면 묶음마다 사건 1건으로 나눠 접수 를 켤 수 있습니다.

• 두 방식 모두 접수가 끝나면 테스트셋으로 저장 을 켜 두면 「분류 시작 전」 상태가 테스트셋으로 남습니다.
• 사건 폴더 방식은 접수 API 를 직접 호출하고, 파일 고르기 방식은 이미지시스템 데모 백엔드를 거칩니다(데모가 떠 있어야 합니다).

실제 업무에서는 이미지시스템(서류 스캔 이미지를 보관하는 시스템)이 사고조사 에이전트로 서류를 보내고, 순서 변경·삭제 같은 변경도 알려 줍니다. 이 화면은 그 이미지시스템 자리에 앉아 같은 연동을 직접 보내고 받아 봅니다. 따로 띄우던 이미지시스템 데모와 같은 기능이고, 데모는 그대로 쓸 수 있습니다.

계약이 바뀌면

호출의 주소와 요청 항목은 이 앱에 적어 두지 않고, 원본 앱의 연동 계약에서 읽어 옵니다. 보내는 호출(API-01~07)은 실행 중인 백엔드가 공개하는 계약을, 받는 호출(API-09·10)은 원본 리포의 계약 파일을 봅니다.

이미지 전송을 따라 하기

1. 접수번호 는 「오늘 날짜 + 순번」 으로 자동으로 채워져 있습니다. 한 번 쓴 번호는 다시 나오지 않고, 새 번호 를 누르면 다음 번호로 바뀝니다. 이미 있는 사건에 더 보내려면 그 번호를 적습니다.
2. 위탁사 를 버튼으로 고릅니다. 오른쪽의 문서분류 목록이 그 위탁사의 것으로 바뀝니다.
3. 낱장 파일 고르기 로 낱장을 여러 장 고릅니다(끌어다 놓아도 됩니다). 낱장마다 오른쪽 목록에서 문서분류를 따로 정할 수 있고, 기본 분류 를 고른 뒤 모두 이 분류로 를 누르면 한꺼번에 바뀝니다.
4. 전송 버튼을 누르면 「전송 진행」 에 단계가 차례로 초록으로 바뀌고, 끝나면 사건 상태가 READY_FOR_CONFIRM 으로 나옵니다.
5. 더 보낼 낱장이 없으면 분류·추출 확정 (API-05) 를 눌러 분류를 시작시킵니다. 원본 앱이나 사건 화면에서 시작해도 됩니다.

• 문서분류가 여러 개인 사건을 한 번에 접수하려면 「접수」 화면의 사건 폴더로 접수가 편합니다. 이 화면은 이미지시스템이 보내는 호출을 하나씩 확인하거나, 추가 전송·논리 변경을 시험할 때 씁니다.
• 분류체계 고치기 로 목록에서 분류를 빼고 보내면 그 위탁사에서 그 분류가 비활성으로 바뀝니다. 기본(지금 체계 그대로)으로 두면 바뀌지 않습니다.
• 추가 전송에서는 이미 있는 낱장과 이름·내용이 같은 파일은 다시 보내지 않고, 이름이 같고 내용이 다르면 그 자리의 낱장을 새 낱장으로 바꿉니다. 고른 낱장이 모두 이미 있는 것이면 보내지 않고 알려 줍니다 — 순서·삭제·분류 변경은 「낱장 편집」 에서 보냅니다.

사건 화면 맨 위의 네 칸(접수·분류·추출·요약)이 단계 막대입니다. 칸마다 지금 상태와 걸린 시간이 보이고, 할 수 있는 일이 버튼으로 나옵니다.

단계가 도는 동안에는 그 칸에 흐르는 경과 시간과 진행 막대, 지금 국면(준비 → AI 처리 → 결과 반영)이 보입니다. 분류는 서류를 몇 장 올렸는지, 같은 사건을 전에 돌린 적이 있으면 지난번 소요 시간을 기준으로 얼마나 왔는지를 보여 줍니다. 사건 목록에서도 도는 중인 사건 옆에 경과 시간이 흐릅니다.

• 요약을 시작하거나 다시 실행할 때는 확인 창에 요약 조건 입력 칸이 나옵니다. 전에 요청한 적이 있으면 그 조건이 채워져 있고, 바꿔 보고 싶으면 고쳐서 보냅니다. 무엇을 넣는지는 요약 조건에 넣는 것 을 보세요.
• 미분류 낱장이 남아 있으면 추출은 시작되지 않습니다. 원본 앱에서 문서종을 지정한 뒤 다시 누르세요.
• 버튼을 누르기 전 상태는 항상 「백업」 체크포인트로 남습니다.

체크포인트는 사건 1건의 DB 행 전부와 서류 파일을 통째로 저장한 것입니다. 사건 화면의 「체크포인트」 목록에서 복원 을 누르면 그 시점으로 돌아갑니다. 게임의 「세이브 파일」 이라고 생각하면 됩니다.

목록이 길면 자동·백업 포함 체크를 꺼서 직접 만든 것과 테스트셋만 봅니다. 이름 바꾸기·삭제 등은 더보기 에 있습니다.

테스트셋은 ★ 를 붙인 체크포인트입니다. 자동으로 지워지지 않고 「테스트셋」 화면에 모입니다. 어느 시점이든 될 수 있습니다.

• 접수 직후를 테스트셋으로 → 분류부터 전체를 반복해서 돌릴 때
• 추출 완료를 테스트셋으로 → 요약만 반복해서 돌릴 때 (분류·추출을 기다리지 않아도 됩니다)

1. 체크포인트 이름 앞의 ☆ 를 누르면 테스트셋이 됩니다. 더보기 → 이름 바꾸기 로 알아보기 쉬운 이름을 붙이세요.
2. 「테스트셋」 화면에서 체크하고 선택한 N건 복원 을 누르면 여러 사건이 한 번에 그 상태로 돌아갑니다.
3. 사건이 DB 에서 지워졌어도 복원하면 다시 만들어집니다.

같은 서류를 서로 다른 조건으로 나란히 돌리고 싶으면 더보기 → 복제 로 다른 접수번호의 사건을 여러 벌 만듭니다.

시나리오는 「테스트셋 복원 → 분류 → 추출 → 요약」 을 사람이 단계마다 버튼을 누르지 않아도 알아서 이어 돌리는 기능입니다. 왼쪽에서 돌릴 테스트셋을 고르고, 오른쪽 「실행 조건」 을 채운 뒤 실행을 누르면 됩니다.

실행하면 벌어지는 일

1. 고른 테스트셋을 저장 당시 상태로 복원합니다. 복원 전 상태는 「백업」 체크포인트로 남습니다.
2. 사건마다 다음 단계를 시작하고 끝날 때까지 기다리기를 「어디까지」 에 닿을 때까지 되풀이합니다. 이미 지난 단계는 건너뜁니다 (예: 추출 완료 시점의 테스트셋은 요약만 돕니다).
3. 화면을 닫거나 다른 화면으로 가도 계속 돕니다. 그만두려면 중단 을 누릅니다.

결과 읽기

요약 단계는 「이 사건을 어떤 관점으로 요약할지」 를 알려 줘야 시작됩니다. 원본 앱에서는 추출이 끝난 뒤 분석 요청 창에서 고르는 내용이고, 테스트벤치에서는 시나리오의 「요약 조건」 과 사건 화면 요약 칸의 확인 창에서 같은 것을 입력합니다.

위 예시처럼 입력하면 AI 에게는 아래와 같은 지시문이 넘어갑니다. 입력한 값이 그대로 들어간다고 보면 됩니다.

[보고서 양식] PRE_CONTRACT_DISCLOSURE

[계약 1] 계약일자: 2023-05-10 · 상품명: 무배당 건강보험

[기타 요청]
2022년 이후 내원 이력만 정리해 주세요

• 직전 요청이 우선합니다. 그 사건에 전에 요약을 요청한 기록이 남아 있으면(요약까지 돌린 뒤 저장한 테스트셋 등) 시나리오는 그 조건을 그대로 다시 쓰고, 기록이 없을 때만 화면에 적은 조건을 씁니다. 사건 화면의 확인 창에서는 직전 조건이 채워진 채로 열리므로 고쳐서 보낼 수 있습니다.
• 폼에 없는 항목(청약서 질문·고지사항, 지식컬렉션)을 넣어야 하면 JSON 으로 직접 고치기 를 눌러 본문을 직접 고칩니다. 평소에는 쓸 일이 없습니다.
• 분석 항목 목록은 원본 앱 DB 의 보고서 양식에서 읽어 옵니다. 괄호 안 글자는 그 양식을 쓰는 위탁사입니다.

시나리오에서 여러 사건을 골랐을 때 한 번에 몇 건을 같이 돌릴지입니다. 사건 3건을 돌린다고 하면 이렇게 다릅니다.

숫자는 「같이 도는 사건 수의 상한」 입니다. 3건씩을 골라도 사건이 2건뿐이면 2건만 같이 돕니다.

A 와 B 를 고르면 분류 라벨·추출값·요약 문장이 어디서 달라졌는지 보여 줍니다. A·B 는 체크포인트일 수도, 사건의 현재 상태일 수도 있습니다.

• 다시 돌린 전후 비교 — 체크포인트의 더보기 → 비교 를 누르면 「그 체크포인트 ↔ 지금」 이 바로 열립니다.
• 조건별 비교 — 복제한 사건들을 서로 다른 조건으로 돌린 뒤 A·B 에 각 사건의 「현재 상태」 를 고릅니다.
• 신뢰도처럼 돌릴 때마다 조금씩 흔들리는 값만 다른 줄은 「달라짐」 으로 세지 않습니다. 전부 보려면 달라진 것만 을 끕니다.
• 사건 화면의 「실행 이력」 에서는 같은 사건을 여러 번 돌린 소요 시간·건수 추이를 봅니다.

단계 막대의 칸이 실패 로 보이면 그 단계에서 멈춘 것입니다. 원본 앱에서는 「…중」 상태로 계속 돌아가는 것처럼 보입니다.

1. 실패한 칸 안의 빨간 글씨로 원인을 봅니다.
2. 일시적인 문제(플랫폼 응답 지연 등)면 그 칸의 ↺ 다시 실행 을 누릅니다.
3. 화면 위에 「수동 지정한 문서종이 Studio 분류 스키마에 없습니다」 가 떠 있으면 다시 실행해도 또 실패합니다. 분류 완료 시점의 체크포인트를 복원한 뒤, 안내에 나온 문서종 중 하나로 다시 지정하고 추출을 시작하세요.
4. Studio 가 무엇이라고 답했는지 보려면 「AI 작업」 표의 외부 작업 id 를 누릅니다.

원본 앱이 실패·지연을 어떻게 보여 주는지 확인할 때 씁니다. 백엔드가 실제 오류 처리 경로를 타므로 꾸며 낸 화면이 아닙니다.

1. 단계 막대에서 ▶ 시작 또는 ↺ 다시 실행 을 누르고, 확인 창의 실패 주입 에서 종류를 고릅니다.
2. 작업 시간 초과·플랫폼 변경·플랫폼 작업 유실 은 단계가 실패로 끝납니다. 응답 지연 은 사건이 「…중」 에 머뭅니다.
3. 원본 앱에서 화면을 확인한 뒤, 지연이면 사건 화면 「작업」 의 지연 해제 를, 실패면 그 단계의 ↺ 다시 실행 을 누릅니다.

1. 보내는 쪽 — 체크포인트의 더보기 → 내보내기 로 ZIP 파일 하나를 내려받아 전달합니다.
2. 받는 쪽 — 「테스트셋」 화면의 가져오기 로 그 ZIP 을 고릅니다. 목록에 「다른 DB」 표시와 함께 나타납니다.
3. 복원 을 누르면 받는 쪽 DB 에 사건이 만들어집니다.

위탁사·문서분류·사용자 같은 기초데이터는 함께 가지 않으므로 받는 쪽 DB 에 같은 것이 있어야 합니다. 접수 직후 상태의 테스트셋이 가장 잘 옮겨집니다.

환경은 「어느 DB · 어느 백엔드 · 어느 서류 폴더에 붙을지」 의 묶음입니다. 여러 개를 등록해 두고 바꿔 붙습니다. 파일을 따로 만들 필요 없이 화면에서 추가합니다.

1. ＋ 환경 추가 를 누르고 id 와 이름을 적습니다.
2. 접속 정보 를 어떻게 줄지 고릅니다.
   • 백엔드 env 파일에서 읽기 — 그 백엔드를 띄울 때 쓰는 env 파일의 경로만 적습니다. DB·폴더가 백엔드와 저절로 맞습니다.
   • 직접 입력 — env 파일이 없을 때 DB 주소·계정·비밀번호와 수신·처리 폴더를 직접 적습니다. 지금 환경 값으로 채우기 를 누르고 달라지는 것만 고치면 쉽습니다.
3. 연결 시험 으로 DB·백엔드·폴더에 닿는지 확인한 뒤 저장 합니다.
4. 목록에서 이 환경으로 를 누르면 서버를 다시 띄우지 않고 그 DB 로 붙습니다. 오른쪽 위 칩에 지금 환경이 표시됩니다.

• 화면에서 저장한 환경은 기본 환경의 DB(testbench.profiles)에 남습니다. 어느 환경에 붙어 있든 같은 목록이 보이고, 목록의 DB 표시가 그것입니다.
• 앱 폴더의 profiles.local.json 에 손으로 적어 둔 환경도 함께 쓸 수 있습니다(파일). 기본 은 .env.local 의 환경입니다.
• 직접 입력한 비밀번호는 DB 에 암호화 없이 저장됩니다(화면으로는 다시 보여 주지 않습니다). 남기고 싶지 않으면 env 파일 방식을 쓰세요.

접수·이미지시스템·시나리오 화면은 피보험자, 조사자 사번, 실행 조건 같은 칸을 예시 값으로 채워 둡니다. 이 값을 한 번 고치면 DB 에 저장되어, 다음에 화면을 열 때도(새로고침·다른 브라우저 포함) 고친 값으로 채워집니다.

• 같은 뜻의 칸은 화면끼리 값을 함께 씁니다. 예: 조사자 사번을 이미지시스템 화면에서 고치면 접수 화면에도 그 값이 나옵니다.
• 시나리오의 요약 조건 도 고치면 남습니다. 직전 요청이 없는 사건에서 요약을 시작할 때 이 조건이 기본으로 채워집니다.
• 저장된 값은 「환경」 화면 아래 저장해 둔 입력값 에서 보고, 항목별 또는 한꺼번에 예시 값으로 되돌립니다. 칸을 비워도 다음에는 예시 값으로 돌아옵니다.
• 값은 지금 붙어 있는 DB 의 testbench.preferences 에 저장됩니다(원본 앱의 테이블과 섞이지 않는 전용 스키마). 그래서 환경(DB)마다 따로 기억합니다.

백엔드를 거치지 않고 Studio 에 요청을 그대로 보냅니다. 업스테이지가 아직 바꾸고 있는 흐름을 백엔드 코드로 옮기기 전에 이 판이 이 요청을 받는지, 응답이 어떤 모양인지 를 확인하는 자리입니다. 사건·DB 와는 무관합니다.

1. 맨 위에서 대상 을 고릅니다. 백엔드 env 파일에 적힌 Studio 가 대상으로 나옵니다 (온프레미스·SaaS). 둘을 함께 고르면 같은 요청을 양쪽에 보냅니다.
2. 요청 에서 미리 만들어 둔 요청을 누르거나 메서드·경로·본문을 직접 적습니다. 경로는 /v2 뒤부터 적습니다.
3. 보내기 를 누르면 오른쪽에 대상별 응답이 나옵니다. 대상이 둘이면 맨 위 응답 견주기 가 상태 코드와 응답 모양의 차이(한쪽에만 있는 자리, 값의 종류가 다른 자리)를 표로 보여 줍니다.

• {{이름}} 은 보낼 때 대상마다 다른 값으로 바뀝니다. 에이전트·지시서·Collection id 는 그 대상의 env 파일에서 오고, files·jobId 는 이 화면에서 올린 파일·방금 만든 작업에서 옵니다. 그래서 같은 요청을 두 Studio 에 그대로 보낼 수 있습니다. 값이 없는 변수가 있으면 보내기 전에 알려 줍니다.
• 작업을 실행하려면 먼저 파일 올리기 로 로컬 파일을 올립니다. 파일 id 는 올린 Studio 안에서만 쓸 수 있어 대상마다 따로 올립니다. 사내망 밖의 대상(SaaS)은 사외 전송 확인 을 켜야 올라갑니다 — 마스킹된 자료만 올리세요.
• 실행 요청(POST /responses)이 성공하면 받은 작업 id 가 그 대상의 jobId 에 들어갑니다. 이어서 작업 조회 나 이어 실행 요청을 그대로 보낼 수 있습니다.
• 응답 견주기는 값이 아니라 모양만 봅니다. 배열은 원소들을 합쳐 [] 로, JSON 을 문자열로 한 번 더 감싼 값은 풀어서 ⟨json⟩ 로 표시합니다.
• Studio 만 더 붙이려면(DB 없이) .env.local 의 TESTBENCH_STUDIO_ENV_FILES 에 env 파일 경로를 적습니다. API 키는 서버에만 있고 화면으로 내려오지 않습니다.
• 여기서 보낸 요청은 실제로 반영됩니다 — 지시서를 만들면 생기고, DELETE 는 지워집니다. 남이 쓰는 에이전트는 건드리지 마세요. 파일 묶음(multipart)으로 보내는 검수 결과 올리기는 아직 지원하지 않습니다.

백엔드가 접수 한 건을 처리하며 Studio 에 보내는 호출을 같은 순서·같은 본문으로 단계별로 보냅니다. 백엔드와 DB 를 거치지 않으므로 사건이 생기지 않고, 이 Studio 에서 우리 흐름이 끝까지 도는지와 어느 단계에서 무엇이 달라지는지를 볼 수 있습니다.

1. 대상 을 고르고 낱장 파일 에 올릴 파일 경로를 접수 건의 낱장 순서대로 한 줄에 하나씩 적습니다. 대상을 둘 고르면 나란히 돌립니다.
2. 처음부터 끝까지 실행 을 누르거나, 단계마다 실행(그 단계만)·여기부터(그 단계부터 끝까지)를 누릅니다.
3. 단계 칸에 결과가 표로 나옵니다 — 올린 파일 id, 문서별 분류 라벨, Export Collection, 추출 항목, 요약 카드. Studio 호출 N건 을 펼치면 그 단계가 보낸 요청과 받은 응답 원문이 있습니다.

• 왼쪽 열은 그 단계에서 백엔드가 하는 일과 보내는 호출입니다. 단계는 접수(올리기·준비 확인) → 분류(요청·대기·Export Collection) → 추출 → 요약 순서이고, 분류·추출 뒤에 각각 검수 보정 왕복이 있습니다.
• 검수 보정 왕복 은 고친 것이 있을 때만 돕니다. 분류 결과가 나온 뒤 그 칸에서 문서 라벨을 고치고(추출은 항목 키와 새 값을 적고) 여기부터 를 누르면, 결과를 내려받아 덮어쓰고 원본 Collection 을 제자리 교체한 뒤 새로 발급된 작업으로 다음 단계를 잇습니다. 고친 것이 없으면 건너뜁니다 — 백엔드도 그렇습니다.
• 지시문 전달 은 요약 단계의 방식입니다. 백엔드 기본은 지시서를 본뜬 버전을 실행마다 만드는 것이고, input_text 로 보내는 방식은 판에 따라 거절됩니다. 「input_text 먼저」 를 고르면 거절될 때 지시서 버전으로 넘어가는 것까지 보입니다.
• 한 구간만 되풀이하기 — 구간 머리의 이 구간 실행 은 그 구간의 단계만 돌리고 멈춥니다. 맨 위 저장 지점 에서 지금 상태 저장 으로 진행 상황(올린 파일·작업 id)을 이름 붙여 남겨 두면, 나중에 불러오기 로 그 지점에서 다시 시작합니다. 예: 분류까지 저장해 두고 추출 구간만 여러 번. 보정 왕복을 돌리면 Studio 가 작업 id 를 새로 발급하므로, 왕복 전에 남긴 저장 지점은 그 뒤로 이어받지 못할 수 있습니다.
• 실제 사건에서 시작하기 — 저장 지점 칸의 사건에서 불러오기 는 지금 붙어 있는 환경의 DB 에서 그 사건의 Studio 작업·파일 id 를 읽어 옵니다. 낱장을 다시 올리지 않고, 「결과 읽기」 단계로 그 작업의 결과를 다시 보거나 「이어 실행 요청」 으로 그 작업에서 새로 이어 돌립니다. 그 사건을 돌린 Studio 를 대상으로 골라야 합니다(다르면 알려 줍니다).
• 지시서를 바꿔 돌리기 — 넘기는 값 보기·고치기 에 "overrides": {"extractionConfigId": "cfg_…"} 를 적으면 그 단계가 env 파일의 지시서 대신 그 지시서로 돕니다. 직접 호출 화면에서 지시서 버전을 만든 뒤 여기서 그 구간만 돌려 견줄 수 있습니다.
• 작업을 새로 만드는 단계(올리기·요청·보정 왕복)를 다시 돌리면 뒤 단계의 결과는 지워집니다(작업 id 가 달라지므로). 조회만 하는 단계(대기·결과 읽기·Collection 확인)는 다시 돌려도 뒤를 건드리지 않습니다. 진행 상황은 저장돼 새로고침해도 남고, 호출 원문은 화면을 떠나면 사라집니다.
• 여기서 만든 작업은 그 에이전트의 Export Collection 에 실제로 쌓입니다. 사내망 밖 대상은 사외 전송 확인 을 켜야 올라갑니다 — 마스킹된 자료만 쓰세요.
• 단계 구성은 백엔드 코드를 옮겨 적은 것이라, 백엔드의 호출 순서가 바뀌면 이 화면도 고쳐야 합니다. 새 흐름은 흐름 정의를 하나 더 두는 식으로 더합니다.

• 사건 화면 아래 「데이터」 에서 테이블 이름을 누르면 그 사건에 속한 행이 그대로 보입니다.
• SQL 화면은 기본이 읽기 전용입니다. 고치려면 쓰기 허용 (커밋) 을 켭니다. $1 을 쓰면 아래 칸에 넣은 접수번호가 들어갑니다.
• 사건 화면 「작업」 의 사건 삭제 는 DB 행과 파일을 모두 지워, 같은 접수번호로 다시 접수할 수 있게 합니다.

• 백엔드가 처리 중일 때는 복원·되돌리기를 누르지 마세요. 처리 중인 결과가 뒤늦게 덮어쓸 수 있습니다. 사건 화면에 노란 경고가 뜹니다.
• 원본 앱은 새로고침해야 바뀐 상태가 보입니다. 테스트벤치에서 되돌려도 원본 앱 화면은 스스로 갱신되지 않습니다.
• Studio 쪽 상태는 되돌릴 수 없습니다. 예전 체크포인트로 복원한 뒤 추출·요약이 실패하면, 분류 칸의 ↺ 다시 실행 으로 처음부터 돌리세요.
• 미분류 낱장은 스키마에 있는 문서종으로 지정하세요. 그렇지 않으면 추출이 실패합니다. 지정할 수 있는 문서종은 경고 문구와 시나리오 화면의 ✓ 표시로 알려 줍니다.
• 복제한 사건은 원본과 같은 Studio 작업을 가리킵니다. 한쪽에서 분류를 보정하면 다른 쪽에 영향을 줄 수 있습니다.