docs(stage2): plan efficient S2_10 wave processing
This commit is contained in:
+162
@@ -0,0 +1,162 @@
|
||||
# S2_10 작업명세서 개정 전략 v.1
|
||||
|
||||
작성일: 2026-10-04
|
||||
대상: `Stage_2_S2_10.yml`
|
||||
상태: **개정 전략 — YAML 미수정, 백엔드 실행·성능 검증 전**
|
||||
|
||||
## 1. 목표와 판단 기준
|
||||
|
||||
S2_10의 목적은 S2_00이 제공한 사건 cluster와 원본 자료를 바탕으로 LLM이 법률관계·청구권·구제수단 후보를 판단하고, deterministic reducer가 참조·차단 사유·후보 연결 등을 검증하여 후속 작업용 결과를 발행하는 것이다. 이 목적과 원본 자료의 의미를 유지하면서, 입력의 중복 저장과 대형 map source 전달을 줄이고 **한 번의 실행에서 최대 8개 cluster를 선택하여, 최대 8개를 동시에 추론**하도록 개정한다. 전체 사건 cluster를 새로 만들거나 S2_00의 결과물을 다시 작성하지 않는다.
|
||||
|
||||
핵심 설계는 ① 판단 자료의 공통 영역·사전 정규화, ② reducer 전용 정보 분리, ③ 작은 map 인덱스와 cluster별 완전한 입력의 전달, ④ 동일한 논리적 wave를 여러 실행 배치로 나누는 누적 처리이다. 자료를 손실 없이 복원한다면 개별 LLM이 읽는 법률 자료의 토큰 수는 원칙적으로 그대로다. 따라서 **저장·MCP 전달량 감소, 실행당 최대 입력량 감소, 실제 LLM 토큰 감소를 구별**하며, 사실·증거·불리한 사정의 삭제나 추가 LLM 요약으로 토큰을 줄이지 않는다.
|
||||
|
||||
## 2. 확인한 현행 구현과 개정 범위
|
||||
|
||||
근거 문서는 [현행 YAML](Stage_2_S2_10.yml), [입력 구조 평가서](S2_10_wave_revision.md), [YAML 작성 가이드](../../../../../SKILL.md), [Python 실행 기준 노트북](../../../test_code_executor.ipynb)이다. 분석 기준 YAML의 SHA-256은 `3d8616c2e2a1c3a5f405ba9806718b9ac519843ddc02c80ff4d51a67c42e8c50`이다.
|
||||
|
||||
- 현행 `S2_10_prepare`가 `work/wave_input.json`을 작성하고, map이 `items`를 추출하며, reducer가 같은 파일의 판단 입력과 검증 자료를 다시 읽는다.
|
||||
- 현행 map에도 이미 `max_concurrency: 8`이 있다. 그러나 준비 단계는 현재 논리적 wave의 미처리 cluster 전체를 담으므로, 이 설정만으로 전체 source 크기나 실행당 처리량이 제한되지는 않는다.
|
||||
- LLM task는 `preflight: false`이고 추가 파일 읽기 도구가 없다. 현재 `payload_json`·`repair_json`은 JSON 문자열이며, 프롬프트에 직접 삽입된다. 사전 참조만 넣는 변경은 LLM에 원문을 전달하지 못한다.
|
||||
- 현행 reducer는 payload 해시, 허용 참조, 검증된 법적 근거, 차단 review, 후보 연결, 기존 결과와 입력의 동일성 등을 검증한다. 이 책임은 유지한다.
|
||||
- 과거 실행에서 보고된 대형 `read_docs` 실패와 binary 저장의 응답 envelope 문제를 분리해서 다룬다. 이 문서는 해당 백엔드의 정확한 응답 크기 상한이나 내부 예외 원인이 확정되었다고 전제하지 않는다.
|
||||
|
||||
개정 대상은 향후 S2_10의 prepare·map 입력 계약·reducer·관련 입출력 설명이다. S2_00, 원본 사건 자료, 기존 S2_20~40 YAML, 모델의 법률판단 목적은 변경하지 않는다. 이 문서 작성 단계에서는 실제 YAML이나 백엔드 파일을 수정하지 않는다.
|
||||
|
||||
## 3. 입력 필드와 저장 책임 재배치
|
||||
|
||||
### 3.1 제거할 최상위 10개 필드
|
||||
|
||||
다음 값은 `wave_input.json`에서 모두 제거한다. 다른 파일로 그대로 열 개를 복제하는 대신, 필요한 시점에 아래 기준으로 확보한다. prepare stdout의 작은 경로 안내나 최종 결과의 추적 필드까지 일괄 삭제하라는 의미는 아니다.
|
||||
|
||||
| 제거 필드 | 개정 후 확보 방법과 조건 |
|
||||
|---|---|
|
||||
| `algorithm_version` | 코드의 `ALGORITHM`과 해시로 결속된 `input_binding.contract.algorithm`을 대조한다. |
|
||||
| `upstream_root` | 코드의 `UPSTREAM_ROOT`를 사용한다. |
|
||||
| `output_root` | 공통 경로 함수로 `UPSTREAM_ROOT`와 출력 계약 버전에서 계산한다. prepare stdout에는 Stage 간 바인딩용으로 유지할 수 있다. |
|
||||
| `input_fingerprint` | 동일한 canonical JSON 규칙으로 `input_binding`을 해시한다. |
|
||||
| `expected_clusters` | 원래 논리적 `waves`를 펼쳐 계산하고 중복·누락을 검사한다. |
|
||||
| `prior_artifacts` | 준비 시점의 해시로 고정한 기존 `s2_10_status.json`에서 읽고 실제 artifact 해시도 검증한다. |
|
||||
| `previous_wave_sha256` | 위 status가 가리키는 현재 논리적 wave artifact의 해시를 사용한다. 최초 실행은 부재를 명시적으로 확인한다. |
|
||||
| `execution_mode` | `input_binding`의 upstream 해시와 일치하는 `ingress_status.json`에서 읽는다. |
|
||||
| `source_policy_release_class` | 같은 upstream 상태 파일에서 읽는다. |
|
||||
| `upstream_status` | 같은 파일의 `status`를 사용한다. |
|
||||
|
||||
최신 파일이라는 이유만으로 다시 읽은 값을 신뢰하지 않는다. 기존 status와 upstream 파일이 준비 시점과 달라졌으면 새 입력을 섞어 발행하지 않고 해당 실행을 중단한다.
|
||||
|
||||
### 3.2 판단용 파일과 reducer용 파일
|
||||
|
||||
`work/wave_input.json`의 물리적 최상위 구조는 `shared`, `dictionaries`, `items`로 한다. `items`는 이번 실행에 실제 호출할 최대 8개 항목만 담는다. `payload_json`이라는 기존 필드명을 유지하되 **저장 시에는 JSON 문자열이 아닌 compact object**로 바꾸고, 모델 입력을 만들 때 완전한 객체로 복원한다. 이 타입 변경에 따라 `json.loads`·해시 계산·프롬프트 삽입 지점을 함께 수정한다.
|
||||
|
||||
| 파일 | 저장 내용과 소비자 |
|
||||
|---|---|
|
||||
| `work/wave_input.json` | 이번 배치의 공통 판단 자료, 실제 사용되는 사전 객체, cluster별 compact payload와 repair. prepare의 복원 및 reducer의 동일성 확인에 사용한다. |
|
||||
| `work/wave_control.json` | `input_binding`, 원래 `waves`, 논리적 `wave_ordinal`, 이번 `batch_cluster_refs`, 해당 cluster의 `validation`, `previous_status_sha256`, `base_summary`, `source_issues`, `reused_complete`, 판단 파일·map 인덱스·호출용 파일의 해시를 둔다. LLM에는 전달하지 않는다. |
|
||||
| `work/map_index.json` | 최대 8개 작은 descriptor로 된 `items` 배열. 각 descriptor는 `cluster_ref`, `input_path`, `input_sha256`을 가진다. 실제 map source이다. |
|
||||
| `work/llm_input/slot-00.json` ~ `slot-07.json` | 현재 배치에 한정한 완전한 `payload_json` 객체와 `repair_json` 객체 또는 null. cluster별 모델 호출 전 백엔드가 읽는 임시 입력이다. |
|
||||
|
||||
검증 정보는 없애지 않고 `wave_control.json`으로 옮긴다. 전체 wave의 검증 객체를 매번 복제하지 않으며, 이미 검증된 cluster 결과는 기존 wave artifact에서 확인한다. 최종 downstream handoff는 계속 `waves/wave-NNNN.json`과 `s2_10_status.json`이고, 위 `work/` 파일들은 내부 작업용이다.
|
||||
|
||||
### 3.3 보존할 논리적 payload
|
||||
|
||||
복원된 각 payload는 `cluster_ref`와 다음 14개 자료 항목을 유지한다: `members`, `signals`, `reviews`, `goal`, `profiles`, `profile_catalog`, `authorities`, `relations`, `predecessor_candidates`, `scc_neighbour_members`, `source_gaps`, `unbound_domain_material_counts`, `evidence_scope`, `dependency_scope`. 원본 참조·partition·차단 상태·검증 여부 및 미평가 자료의 취급 원칙을 객체 내부에서 보존한다. `cluster_ref`는 기존 cluster 식별·결과 연결에 필요한 값이며 새 `request_id`를 도입하지 않는다. `repair_json`도 구조 보정에 필요하므로 별도로 유지한다.
|
||||
|
||||
물리적 compact payload에는 `goal`·`profile_catalog`의 공통 영역 참조, `reviews`·`profiles`의 사전 참조가 들어갈 수 있다. 그러나 **LLM에 전달되는 논리적 payload에는 원래 필드명과 전체 값이 복원되어 있어야 한다.** 모델에게 사전 키를 해석하거나 누락된 자료를 찾아 읽도록 요구하지 않는다.
|
||||
|
||||
## 4. 공통 자료·사전의 무손실 구성
|
||||
|
||||
prepare는 이번 배치의 모든 대상 payload를 구성한 뒤 `goal` 및 `profile_catalog`의 canonical 값이 실제로 같은지 확인한다. 모두 같을 때만 공통 영역에 한 번 저장한다. 다르면 해당 필드를 cluster별로 유지하며, 임의의 대표값을 선택하지 않는다. 서로 다른 배치 간 공통성도 추정하지 않고 각 배치에서 확인한다.
|
||||
|
||||
review·profile은 본문이 아니라 **원본 참조 목록, partition, 차단·검증 상태를 포함한 전체 객체의 동일성**으로만 사전화한다. 키는 canonical 객체의 digest처럼 deterministic하게 정하고, 같은 키에 다른 객체가 대응하면 실패시킨다. cluster별 참조 배열은 원래 순서·출현 횟수를 유지한다. 동일 본문이라도 다른 원본 참조나 상태이면 별도 객체이며, 중복 저장 제거가 원본 발생 건수나 근거의 삭제로 이어져서는 안 된다. 사전에는 이번 배치에서 사용하는 객체만 포함한다.
|
||||
|
||||
준비 시 한 프로세스가 공통 영역과 사전을 한 번 읽고, 각 cluster를 차례로 복원한다. 복원 전의 원래 논리적 payload와 복원 후 객체의 canonical byte 및 digest가 같아야 한다. 배열 정렬, 텍스트 축약, 숫자·null·boolean의 문자열 변환, review ref 소거 같은 의미 변경을 금지한다. 이 검증은 실제 LLM 호출 전에 끝낸다.
|
||||
|
||||
## 5. 실행 DAG와 입력 전달 방식
|
||||
|
||||
```text
|
||||
S2_00의 기존 handoff + 검증된 이전 S2_10 status/artifacts
|
||||
→ prepare: 가장 이른 미완료 논리적 wave에서 최대 8개 선택
|
||||
→ compact wave_input + reducer control 구성
|
||||
→ 공통 자료 1회 로드, cluster별 payload 복원·텍스트 입력 저장
|
||||
→ 작은 map_index 게시 및 모든 입력 read-back 확인
|
||||
→ map: 최대 8개 동시 실행, 각 호출에 해당 slot 입력만 preflight
|
||||
→ reducer: 이번 배치 검증, 기존 논리적 wave 결과에 누적
|
||||
→ wave read-back 후 s2_10_status를 마지막에 저장
|
||||
→ 미처리 cluster가 있으면 같은 Agent를 순차 재호출
|
||||
```
|
||||
|
||||
### 5.1 prepare와 파일 저장
|
||||
|
||||
한 번의 prepare에서 compact 자료를 만들고 읽어 검증한 후, 최대 8개의 slot 파일을 **하나씩** 복원·저장한다. 모든 cluster의 확장된 입력을 다시 모아 대형 map source를 만들지 않는다. slot은 독립적인 최종 자산이 아니라 다음 배치에서 재사용하는 고정 작업 공간이다. 이미 시작한 map/reducer가 끝나기 전에 덮어쓰지 않으며, 사용하지 않는 slot은 현재 인덱스에 포함하지 않는다.
|
||||
|
||||
JSON 입력은 `write_file`을 통한 UTF-8 텍스트로 저장하고 실제 `read_docs` 응답에서 원래 JSON 본문을 얻는지 확인한다. 단순히 확장자가 `.json`인 binary envelope를 map source로 사용하지 않는다. MCP 외부 응답의 `results`/`content` 구조와 본문 JSON의 구분은 실제 응답 계약대로 처리한다. 파일 크기, JSON 완전성, 읽은 본문의 해시를 검사하며 임의의 앞부분 추출이나 잘린 JSON 허용은 하지 않는다.
|
||||
|
||||
prepare stdout에는 `output_root`, 준비 완료 상태, 선택 개수, control/input/index digest 등 작은 바인딩 값만 출력한다. 본문·전체 사전·전체 payload를 출력하지 않는다. control은 다른 작업 파일의 해시를 포함하고, control 자신의 해시는 stdout에서 전달하여 순환 해시를 만들지 않는다.
|
||||
|
||||
### 5.2 map의 모델 입력
|
||||
|
||||
map source를 `work/map_index.json`의 `items`로 바꾸고 `max_concurrency: 8`을 유지한다. `Task_S2_10_resolve_cluster`는 여전히 cluster당 한 번의 LLM 추론만 수행한다. SKILL에 명시된 `preflight_files`의 동적 item 경로를 사용하여 해당 descriptor의 `input_path`만 백엔드가 미리 읽도록 한다. 이때 현행 `preflight: false`를 그대로 둘 수 없으므로, **백엔드의 지정 파일 자동 읽기는 허용하고 LLM의 임의 도구 호출은 허용하지 않는 입력 정책**으로 명시적으로 바꾼다. 프롬프트는 이미 로드된 cluster 입력을 판단 자료로 사용하고, 기존 `{{item.payload_json}}`·`{{item.repair_json}}` 직접 삽입에 의존하지 않도록 수정한다.
|
||||
|
||||
이 경로는 가이드상 기능에 근거한 채택안이다. 실제 map 실행에서 동적 `preflight_files`가 정확히 한 개의 본문을 모델에 전달하는지, 불필요한 경로 스캔·중복 삽입이 없는지는 **구현 채택 전 백엔드 검증 조건**이다. 지원이 확인되지 않으면 참조 키만 LLM에 넘기는 식으로 진행하지 않는다. `shared_context` 지원만으로 임의의 Python 복원 hook이나 사전의 동적 역참조가 지원된다고 가정하지 않는다.
|
||||
|
||||
복원을 별도의 map Code Executor task로 추가하고 전체 payload를 stdout으로 반환하는 방식을 기본안으로 삼지 않는다. 가이드의 `map_results`에는 각 item과 task 결과가 포함되므로, 이런 방식은 reducer로 넘기는 envelope에 대형 입력을 다시 실을 수 있다. 작은 descriptor와 단일 LLM task를 유지하면 이 중복을 피할 수 있다. 임시 slot의 추가 쓰기·읽기 비용은 발생하지만, cluster별 추가 Python 실행 환경 초기화와 전체 payload의 task 결과 반송은 발생시키지 않는다.
|
||||
|
||||
### 5.3 reducer의 검증 경계
|
||||
|
||||
reducer는 control hash를 prepare stdout과 대조하고, 연결된 compact input·인덱스·slot 본문 및 upstream/이전 status의 해시를 확인한다. 각 복원 payload의 digest는 기존 `validation.payload_sha256`과 일치해야 한다. map 결과는 이번 descriptor의 item_index·cluster_ref·item 전체 및 기대 task 결과와 결속하고, 기존의 인용 가능 참조·검증된 authority·차단 review·법률영역·후보 연결 검사를 유지한다. 입력 파일에 경로만 있었다는 이유로 해시 확인을 생략하지 않는다.
|
||||
|
||||
reducer의 법률 자료 검증 기준은 준비 단계의 원본과 복원한 동일 자료에 근거한다. 검증 정보 자체를 모델 출력에서 재구성하거나 모델의 자체 선언으로 대체하지 않는다. 파일 분리 후에도 오래된 slot과 새 control의 혼용, 다른 배치 결과의 섞임, 모델 결과 누락·중복을 거부한다. 실행 중 동일 작업 폴더에 대한 writer는 하나로 제한하며, 이 설계를 서버의 원자적 잠금이나 compare-and-swap 보장으로 과장하지 않는다.
|
||||
|
||||
## 6. 최대 8개 배치와 논리적 wave 보존
|
||||
|
||||
S2_00의 원래 `scheduling_waves`와 SCC 구성을 **논리적 wave**로 유지한다. `wave_ordinal`과 `waves/wave-NNNN.json`의 번호도 계속 이 논리적 wave를 뜻한다. 실행 배치는 그 안에서 이번에 선택한 최대 8개의 집합이며 별도 사건 식별자를 만들지 않는다. 가장 이른 미완료 논리적 wave의 원래 순서에서 미처리 항목을 선택하고, 개수·크기 예산에 따라 8개보다 적게 선택할 수 있다. 다음 논리적 wave는 앞 wave의 모든 cluster가 검증된 뒤에만 시작한다.
|
||||
|
||||
예를 들어 같은 논리적 wave에 46개가 있고 다른 제한이 없다면 8·8·8·8·8·6개로 나누어 최소 6회 실행한다. 각 실행의 map은 최대 8개가 동시 실행된다. 법률판단은 총 46회로 유지되며, 6회 호출만으로 46개를 공동 추론하는 구조가 아니다. 호출자는 status를 확인하여 같은 Agent를 순차 재호출한다. 현행 YAML에 확인되지 않은 자동 반복 문법을 도입하지 않으며, 단 한 번의 Agent 요청이 모든 배치를 자동 소진한다고 설명하지 않는다.
|
||||
|
||||
**같은 논리적 wave의 먼저 처리된 배치 결과를 뒤 배치의 `predecessor_candidates`로 추가하지 않는다.** 선행 후보의 의미는 기존처럼 앞선 논리적 wave에서 검증된 관련 후보로 유지한다. SCC가 8개를 넘어서 분할되더라도 `scc_neighbour_members`는 원래 SCC 범위의 원본 정보를 유지한다. 배치 분할이 법률적 의존성이나 판단 자료를 바꾸어서는 안 된다.
|
||||
|
||||
### 누적 wave 발행과 이어 실행
|
||||
|
||||
각 배치 후 기존 논리적 wave 파일에 새로 검증한 cluster 결과를 누적한다. `expected_clusters`는 그 논리적 wave 전체, `clusters`는 실제 시도한 항목들의 누적 결과로 정의하고, 아직 선택하지 않은 항목은 pending으로 계산한다. 이 때문에 현행의 “저장된 cluster 집합이 wave 전체와 항상 같아야 한다”는 검사를 **집합 포함·중복 없음·누적 coverage 검사**로 개정해야 한다. 성공한 8개 외 나머지를 모델 출력 누락이나 기술 실패로 오분류하지 않는다.
|
||||
|
||||
완료하지 않은 wave 파일은 준비 시점의 기존 해시가 동일한 경우에만 미처리 결과 추가 또는 기존에 허용된 한 번의 실패 항목 구조 보정으로 갱신한다. 이미 `VALIDATED`인 항목은 바꾸거나 다시 호출하지 않는다. 같은 입력 binding에서 완료한 wave는 불변이다. `complete`는 전체 기대 cluster가 모두 `VALIDATED`일 때만 true이며, status의 기술 실패와 pending은 분리한다. 선택된 항목의 누락·검증 실패는 `TECHNICAL_INCOMPLETE`, 실패 없이 미처리 항목만 남으면 `NEXT_WAVE_PENDING`이다. 최종 법률상 미해결은 기존처럼 기술 실패와 구분하여 보존한다.
|
||||
|
||||
wave read-back을 확인한 뒤 status를 마지막에 저장한다. wave 저장 후 status 저장 전에 중단되었다면 기존 해시가 맞지 않는 파일을 조용히 덮어쓰지 않는다. 입력 binding과 기존 검증 항목의 보존을 확인하여 고아 결과를 재조정하는 경로가 검증된 경우에만 복구하며, 그렇지 않으면 충돌로 중단한다. 부분 wave를 정상 진행 상태로 허용하는 변경은 출력 schema/알고리즘 버전에 반영하고, 후속 소비자는 최종 status의 전체 coverage를 기준으로 handoff 완료를 판단해야 한다.
|
||||
|
||||
## 7. 크기·토큰·실행 한도의 관리
|
||||
|
||||
| 한도 | 적용 지점과 초과 시 처리 |
|
||||
|---|---|
|
||||
| 배치 항목 수 | prepare와 map 모두 최대 8개. retry도 같은 상한을 적용한다. |
|
||||
| 공통 자료 포함 전체 source 크기 | `wave_input.json`의 shared·사전·items 전체 직렬화 크기와 실제 `map_index.json` 응답 크기를 각각 제한한다. 단순 items 합계만 검사하지 않는다. |
|
||||
| cluster별 실제 입력 | 복원된 본문, system/user prompt, repair, 출력 여유를 합친 모델 입력 예산을 확인한다. 바이트 제한을 모델 토큰 제한과 동일시하지 않는다. |
|
||||
| preflight 응답 크기 | 각 slot의 텍스트 JSON과 MCP envelope를 포함하여 확인한다. 한 cluster가 상한을 넘으면 배치 개수 감소만으로 해결되지 않는다. |
|
||||
| map 결과·reducer 전달 | 모델 결과와 descriptor가 포함된 실제 envelope 및 base64 팽창을 고려한다. 지원이 확인된 모델 출력 상한과 배치 크기 정책을 함께 적용한다. |
|
||||
| 동시 토큰·시간 | 8개 동시 호출의 요청/토큰 rate limit, task timeout, Agent 전체 실행 제한을 별도로 확인한다. 필요하면 개수·동시성을 낮춘다. |
|
||||
|
||||
상한은 실제 배포 백엔드와 사용 모델의 확인된 설정을 바탕으로 정한다. 현행 `MAX_PAYLOAD_BYTES=768000`이나 `MAX_FILE_BYTES=32 MiB`를 MCP·모델·Agent의 안전 상한으로 간주하지 않는다. 확인되지 않은 수치나 SKILL에 없는 YAML 옵션을 확정 계약으로 쓰지 않는다. 모델 토큰 측정과 출력 제한이 실행 경로에서 실제 적용되는지도 검증한다. 후처리에서 결과가 너무 컸음을 발견하는 검사만으로 전송 단계의 실패를 예방했다고 주장할 수 없다.
|
||||
|
||||
전체 source 예산 초과 시에는 결정된 순서를 유지하면서 배치를 줄여 다시 사전화한다. 단일 cluster가 여전히 초과하면 원문을 자르거나 review·SCC 자료를 버리지 않고, 해당 cluster를 미완료로 남긴 명시적 크기 초과 결과를 반환한다. 이 경우의 추가 자료 분할 추론은 별도 의미 보존 설계가 필요하며 본 전략의 성공으로 계산하지 않는다. 따라서 “8개 이하이면 어떤 입력도 limit에 걸리지 않는다”는 보장은 하지 않는다.
|
||||
|
||||
효율의 예상 효과는 대형 source 반복 반송 제거, nested JSON 문자열의 중복 escaping 감소, 이번 배치와 관련된 공통 객체만 저장, 검증 완료 cluster 재호출 방지이다. 반면 slot 최대 8개 쓰기·읽기, 배치마다 reducer 검증·status 발행, 여러 번의 Agent 호출 비용이 생긴다. 저장소 전체 사용량에는 확장된 임시 slot도 포함되므로 canonical 입력의 절감률을 총 저장량 절감률로 제시하지 않는다. 실제 지연과 비용은 동일한 사건 자료로 측정해야 하며, 무손실 복원만으로 개별 모델 입력 토큰의 큰 감소를 기대해서는 안 된다.
|
||||
|
||||
## 8. 구현 순서와 버전 전환
|
||||
|
||||
1. prepare·map·reducer에서 기존 19개 필드의 모든 참조를 조사하고, 위 파일별 소유권과 파생 규칙으로 변경한다. upstream root 및 출력 경로 함수는 양쪽 Python에서 동일하게 유지한다.
|
||||
2. lossless pack/unpack과 전체 source admission을 먼저 구현한다. 객체 단위 동등성·참조 보존을 확인한 뒤 slot과 map 인덱스를 생성한다.
|
||||
3. 텍스트 저장·`read_docs`·동적 preflight 경로를 작은 실제 입력으로 확인한 후 map을 연결한다. 추가 LLM 요약·조회 task, 전체 복원 결과를 담은 대형 map source, 불필요한 실행 ID는 만들지 않는다.
|
||||
4. reducer를 control 기반으로 바꾸고, 동일 논리적 wave의 부분 누적·pending·실패 보정·status-last 계약을 함께 변경한다. map 결과의 item 구조가 바뀐 부분도 수정한다.
|
||||
5. 알고리즘·입력/출력 schema·프롬프트 계약을 새 버전으로 구분한다. 현행 완료 결과를 덮어쓰거나 새 binding과 섞지 않도록 새 출력 버전 경로를 사용하고, 기존 결과는 보존한다. 경로 변경을 모든 task와 설명에 일관되게 반영한다.
|
||||
6. S2_00 입력 계약은 유지한다. downstream에 부분 wave를 완료 결과처럼 전달하지 않도록 새 출력 계약의 완료 판정과 호환 범위를 명시한다. 기존 S2_20~40 코드가 자동 호환된다고 선언하지 않는다.
|
||||
|
||||
Python은 지정 notebook의 Code Executor 요청·stdout JSON·MCP 세션 계약을 따른다. `requirements`는 패키지별 줄바꿈을 유지하며, 기존 `httpx`·`jsonschema` 의존성에 대한 설치 task를 추가하지 않는다. Code Executor 호출 간 메모리 공유를 가정하지 않고, 공통 자료의 1회 로드는 단일 prepare 프로세스 내부에서 수행한다. 사건 원문을 Python 소스 문자열에 직접 삽입하지 않고 JSON 파일로 읽는다. 인증 정보는 전략서·출력 파일·진단 로그에 기록하지 않는다.
|
||||
|
||||
## 9. 구현 후 완료 판정과 검증 계획
|
||||
|
||||
- **무손실성:** 모든 대상 cluster의 기존 논리적 payload와 pack/unpack 결과가 동일하다. 같은 본문·다른 ref/partition/차단 상태, 반복 객체, null, 빈 배열, 한글·따옴표를 포함한 자료를 보존한다. 공통 값이 다르면 공통화하지 않는다.
|
||||
- **실제 모델 입력:** 사전 참조가 모두 원문으로 복원되고, 해당 cluster 입력과 repair만 전달되며, 다른 slot이나 전체 사전이 추가 삽입되지 않는다. map source는 최대 8개 descriptor이고 LLM 도구·요약 호출이 늘지 않는다.
|
||||
- **배치 의미:** 0·1·8·9개 및 여러 배치 사례에서 누락·중복 없이 진행한다. 8개 초과 SCC도 원래 이웃 자료를 유지하며, 같은 wave의 앞 배치 결과가 뒤 배치의 선행 후보로 유입되지 않는다.
|
||||
- **검증·복구:** payload·control·slot·이전 status 해시 변조, stale map, 누락/중복 결과, 잘못된 authority/ref/후보 연결, 차단 review 미반영을 거부한다. 유효 결과는 재호출하지 않고 실패 항목 보정 횟수를 유지한다. 중단 시점별 파일 충돌을 성공으로 표시하지 않는다.
|
||||
- **크기·성능:** canonical 입력, 임시 slot 총량, 각 `read_docs` 응답, 실제 프롬프트 토큰, map 결과/base64, peak 동시성, 전체 호출 횟수·처리 시간을 구분하여 측정한다. 크기 초과 단일 cluster도 검증한다.
|
||||
- **완료:** task와 저장 결과를 확인하고, 전체 expected cluster의 검증 완료 및 status-last 정합성으로 판단한다. 세션 `completed`나 한 배치 성공만으로 전체 S2_10 완료를 선언하지 않는다.
|
||||
|
||||
현재 확인된 것은 현행 코드와 지정 가이드에 근거한 설계 적합성이다. 실제 preflight 바인딩, 새 부분 wave 계약, 운영 한도 충족, 성능 향상은 향후 구현·실행 검증 대상이며, 본 문서 작성으로 달성되었다고 보고하지 않는다.
|
||||
+254
@@ -0,0 +1,254 @@
|
||||
# S2_10 작업명세서 개정 전략 v.2
|
||||
|
||||
작성일: 2026-10-04
|
||||
대상: `Stage_2_S2_10.yml`
|
||||
상태: **전략서 작성 완료 — YAML 구현·workspace 실행·모델 품질 및 성능 검증 전**
|
||||
|
||||
## 1. 결론과 유지할 목표
|
||||
|
||||
v1의 최대 8개 배치·검증 정보 분리를 유지하되, **저장 표현과 모델 입력 표현을 따로 설계**한다. 저장 중복을 제거한 뒤 모델 호출 때 모두 확장하는 데서 그치지 않고, 모델에 실제 전달하는 한 cluster의 입력에서도 반복 본문과 긴 기술적 참조를 줄인다. 법률 자료를 버리는 요약보다 **같은 자료를 더 짧게 읽을 수 있는 자기완결적 입력**을 우선하며, prepare의 반복 검색과 Schema 설명의 중복도 줄인다. 개별 cluster를 하나의 법률판단 단위로 유지하고, 전체 검증된 결과의 의미와 후속 handoff는 현행 수준을 충족하도록 한다.
|
||||
|
||||
S2_10은 사건 cluster별 법률관계·청구권·구제수단 후보, 요건·항변/재항변, 지지·반대 자료, 부담 주체·근거, 양립·중복회복·기간 쟁점, 의뢰인 지시와 미해결 사항을 판단하는 작업이다. cluster를 최종 청구군으로 확정하지 않는다. authority가 없거나 검증되지 않으면 확정적 법률판단을 유보하고, 원본 review 및 미평가 자료를 보존한다. 이러한 요구를 속도나 토큰 절감과 교환하지 않는다.
|
||||
|
||||
**채택 우선순위:** ① 모델 입력의 무손실 단축, ② prepare 인덱스 재사용과 불필요한 전달 제거, ③ 크기·예상시간을 고려한 최대 8개 병렬 배치이다. 사실의 법률적 중요도를 추정해 삭제하는 방법, 여러 cluster를 한 번의 LLM 판단으로 합치는 방법, reasoning 수준·모델 교체는 기본 개정안에서 제외한다. 동일 정보의 다른 표현도 모델의 해석 부담을 바꿀 수 있으므로, 무손실 복원만으로 판단 품질 유지가 입증되었다고 주장하지 않는다.
|
||||
|
||||
## 2. 근거·범위·완료 상태
|
||||
|
||||
| 자료 | 이번 전략의 근거 |
|
||||
|---|---|
|
||||
| [v1 전략서](S2_10_revision_strategy_v.1.md) | 10개 필드 제거, 공통 사전, 작은 map 인덱스, slot 입력, 최대 8개 배치, 부분 wave 발행 |
|
||||
| [현행 YAML](Stage_2_S2_10.yml) | `prepare`, `compact_goal`, `validate_result`, map prompt·Schema, `coverage_status`, `publish`의 실제 책임 |
|
||||
| [입력 구조 평가서](S2_10_wave_revision.md) | 저장·전송 개선과 실제 LLM 토큰 개선의 구분; 과거 메모리 실험의 범위 |
|
||||
| [YAML 작성 가이드](../../../../../SKILL.md) | MapReduce, `item_json`, `preflight_files`, `shared_context`, `map_results_b64`의 문서화된 기능 |
|
||||
| [Code Executor 노트북](../../../test_code_executor.ipynb) | `run_code` 인자, requirements, network, timeout, stdout와 MCP 세션의 실행 계약 |
|
||||
|
||||
분석 기준 YAML SHA-256은 `3d8616c2e2a1c3a5f405ba9806718b9ac519843ddc02c80ff4d51a67c42e8c50`이다. v1 SHA-256은 `272e1a261736033770547fc80115db56fe8dffdb80ef5a448a298b1e117b12a3`이다. 이전 S2_10 분석서는 의존성 형식 수정 전 해시를 기록하고 있으므로 현재 구현 판단은 직접 읽은 YAML을 우선한다.
|
||||
|
||||
산출물은 이 전략서와 지정 MEMORY 기록이다. S2_00·S2_10 YAML, 기존 전략서, 배포 자산, 백엔드 결과를 수정하지 않는다. 모델·백엔드의 새로운 지원 여부를 외부 조사로 확정하지 않으며, 가이드에 없는 기능은 구현 전 확인 조건으로 둔다.
|
||||
|
||||
## 3. v1의 비용과 v2의 변경 결정
|
||||
|
||||
| v1 설계의 비용 또는 한계 | v2 결정 | 달라지는 효율과 조건 |
|
||||
|---|---|---|
|
||||
| 사전 저장 후 각 slot에는 원래 payload 전체를 확장 | 한 cluster 입력 안의 반복 본문도 사전화하고, 모든 필요한 값이 들어 있는 compact model packet을 전달 | 실제 모델 입력을 줄일 수 있다. 별도 파일 조회가 필요 없는 표현이어야 한다. |
|
||||
| 긴 원본 ref와 여러 review ref를 반복 입력·출력 | 인용 가능한 참조에만 짧은 임시 별칭을 부여하고 reducer가 복원 | 입력과 출력 양쪽의 기술 문자열 감소. occurrence·인용 경계는 보존한다. |
|
||||
| 매 호출에 길고 반복적인 JSON Schema 삽입 | 동일한 Schema 하위 정의를 `$defs`로 공통화 | 출력 계약을 유지하면서 고정 prompt를 단축한다. |
|
||||
| cluster별 전체 signal·review·관계 재검색 | 단일 prepare 프로세스에서 한 번 인덱스 구성 | Python 검색량 감소. 원래 선택·차단 규칙과 결과는 같아야 한다. |
|
||||
| 작은 입력에도 최대 8개 slot 저장·사전 읽기 | 기본 파일 전달을 유지하되, 검증된 소형 입력에 한해 직접 map 전달을 대안으로 비교 | 빠른 경로는 추가 파일 I/O를 줄이지만 item 반송 크기를 계산해야 한다. 두 경로를 무조건 모두 구현하지 않는다. |
|
||||
| 항상 원래 순서로 8개씩 선택 | 같은 논리적 wave 안에서 예상시간·입력 크기를 고려해 선택 | 배치 종료 대기 시간을 줄일 가능성. 논리적 의존성은 바꾸지 않는다. |
|
||||
| 배치가 바뀔 때 검증과 발행 비용 반복 | 프로세스 내 재사용을 먼저 적용하고, 디스크 cache는 필요성이 측정된 경우에만 추가 | 확인되지 않은 원본 불변성을 전제로 검사를 생략하지 않는다. |
|
||||
|
||||
v1의 “호출 전 완전한 논리적 payload 복원”은 **Python 검증 과정에서 유지**한다. 변경점은 그 확장본을 그대로 모델에 보내는 대신, 검증된 짧은 표현을 보내는 것이다. 이 문서의 사전 참조는 같은 호출 본문에 포함된 값에 대한 참조이며, 다른 파일에 있는 자료를 모델이 알아서 찾아 읽도록 하는 방식이 아니다.
|
||||
|
||||
## 4. 세 가지 입력 표현과 보존 계약
|
||||
|
||||
### 4.1 원래 논리적 payload
|
||||
|
||||
기존 `cluster_ref` 및 다음 14개 자료 항목을 유지한다: `members`, `signals`, `reviews`, `goal`, `profiles`, `profile_catalog`, `authorities`, `relations`, `predecessor_candidates`, `scc_neighbour_members`, `source_gaps`, `unbound_domain_material_counts`, `evidence_scope`, `dependency_scope`. `repair_json`은 첫 실행에 null, 허용된 보정에만 구조·참조 오류와 기존 출력 자료를 제공한다.
|
||||
|
||||
당사자·객체·시점·금액·행위·증거·불리한 사실·항변·모순·추론과 관측의 차이·의뢰인 제약·적격·authority 검증 상태·차단 review·SCC/의존성 공백은 보호 대상이다. 현재 `compact_goal`과 profile 선택이 이미 일부 축약을 수행한다는 점을 고려하여, 같은 축약을 새로운 효과로 계산하지 않는다.
|
||||
|
||||
### 4.2 저장용 compact input
|
||||
|
||||
`work/wave_input.json`은 `shared`, `dictionaries`, `items`를 최상위 필드로 두고, 이번 실행의 최대 8개 항목만 담는다. 공통 `goal`·`profile_catalog`는 대상 cluster에서 값이 실제로 같을 때만 한 번 저장한다. review·profile 객체는 원본 ref·partition·차단 상태를 포함한 전체 객체가 동일할 때만 공유한다. 원래 배열 순서와 출현 횟수, 서로 다른 occurrence의 정체성은 보존한다.
|
||||
|
||||
`payload_json`은 nested JSON 문자열에서 객체로 바꾼다. Python에서 `unpack(storage)`를 수행했을 때 원래 논리적 payload의 canonical byte·hash와 같아야 한다. 저장 구조를 작게 만든 것만으로 모델 입력이 작아졌다고 계산하지 않는다.
|
||||
|
||||
### 4.3 실제 모델용 compact packet
|
||||
|
||||
Python에서 복원·검증한 payload에 별도의 deterministic 표현 변환을 적용한다. 개념적 구조는 다음과 같다. 실제 필드명과 마커는 구현 시 고정하고 입력 계약 버전에 반영한다.
|
||||
|
||||
```text
|
||||
cluster_ref
|
||||
materials: 원래 14개 자료 항목; 필요한 곳에만 본문 사전·인용 별칭 사용
|
||||
bodies: 이 cluster에서 반복되는 완전히 같은 본문을 한 번씩 저장
|
||||
reference_roles: 별칭별 자료 종류·필드 의미 등 모델의 인용 선택에 필요한 정보
|
||||
repair: null 또는 허용된 구조 보정 자료
|
||||
```
|
||||
|
||||
`bodies`는 해당 cluster에 필요한 객체만 담는다. 짧거나 한 번만 등장하는 객체는 그대로 두어 사전 관리용 토큰을 늘리지 않는다. 원본 객체 안의 ref·상태·내용을 분리하더라도 occurrence별 행은 유지한다. 같은 본문이라는 이유로 두 사실을 동일 사건으로 합치거나 review를 소거하지 않는다. 원본 자료가 사용하는 키와 compiler 마커가 충돌하지 않도록 별도의 문법을 정하며, 모든 마커에 대응하는 본문이 같은 packet 안에 있어야 한다.
|
||||
|
||||
예를 들어 member와 signal에 긴 사실 본문이 완전히 동일하게 반복될 때 본문을 `B1`에 한 번 저장하고 각 행이 이를 명시적으로 참조할 수 있다. 각 행의 source·signal ID·판단 상태는 따로 유지한다. 이를 “두 개의 근거가 동일한 증거이므로 합쳐도 된다”는 법률적 판단으로 해석하지 않는다. 실제 값이 다른 유사 문장은 묶지 않는다.
|
||||
|
||||
이 packet의 모든 법률 값과 구조는 `decode(packet, control의 원본 참조 대응)`로 기존 payload에 돌아와야 한다. 모델이 의미를 읽는 데 필요한 출처 종류·필드 명칭은 packet에 남긴다. 긴 기술적 저장 경로와 원본 ref의 역변환 표는 reducer control에 둘 수 있지만, 경로 자체에 법률적으로 필요한 정보가 담겨 있다면 그 정보까지 숨기지 않는다. JSON 문자열 escaping을 줄이는 것에 더해 **모델에게 반복 본문을 실제로 한 번만 전달**하는 것이 v2의 핵심이다.
|
||||
|
||||
## 5. 긴 참조의 단축과 출력 복원
|
||||
|
||||
### 5.1 별칭 범위
|
||||
|
||||
`M1`, `S1`, `R1`, `A1` 같은 짧은 별칭은 한 모델 호출 안에서만 사용하는 표현이다. 새로운 사건·요청·실행 ID를 생성하지 않으며, downstream 결과에는 원래 ref를 저장한다. 서로 다른 원본 ref에는 서로 다른 별칭을 부여한다. 원본 fact ID·party ID·증거번호·cluster_ref·법률영역 코드 및 사실 본문의 숫자·날짜·명칭은 임의로 바꾸지 않는다.
|
||||
|
||||
원본 ref가 기술적으로 긴 인용 위치임이 계약상 확인되는 필드만 변환한다. 자유 서술 속 유사 문자열을 전역 치환하지 않는다. member 필드 참조는 별칭과 JSON pointer로 표현할 수 있으나, 실제 제공된 필드 및 기존 `allowed_refs`에 포함된 경로만 복원한다. pointer의 escape·중첩 경로·허용 여부를 검사한다.
|
||||
|
||||
review가 이미 같은 내용·partition·blocking으로 묶여 있을 때, 다수 ref의 반복을 줄이는 **명시적 review 그룹 인용**도 비교할 수 있다. 이 경우 그룹이 포함하는 occurrence와 각 ref를 reducer가 정확히 복원하고, 모델이 그룹 전체를 평가했다는 선언이 있는 인용 필드에서만 확장한다. 서로 다른 partition·차단 상태나 평가가 필요한 review를 하나의 그룹으로 합치지 않는다. 이 최적화가 모호한 부분 인용을 만들면 개별 review 별칭으로 되돌린다.
|
||||
|
||||
### 5.2 reducer 처리 순서
|
||||
|
||||
모델 출력의 wire 형식은 기존 결과 필드와 법률판단 항목을 유지하면서 ref 위치에만 별칭을 허용한다. reducer는 ① wire 구조 확인, ② 정해진 인용 필드에서만 별칭·허용 그룹 복원, ③ 기존 전체 `OUTPUT_SCHEMA` 검사, ④ 기존 `validate_result` 검사를 수행한다. 알려지지 않은 별칭·다른 cluster 별칭·금지된 pointer·허용되지 않은 authority·중복 또는 잘못된 후보 endpoint를 거부한다. 복원 후 길이 제한도 기존 기준대로 검사한다.
|
||||
|
||||
근거 문장 안에 별칭을 인용하는 경우도 표현 계약을 정하고 원래 출처를 표시할 수 있게 하되, 본문의 임의 텍스트를 일괄 치환하지 않는다. 안정적으로 파싱할 수 없는 별칭은 ref 전용 필드에만 사용한다. 후보의 설명·법률효과·부담·요건·항변 검토는 LLM이 작성한다. reducer가 빈 항변 배열을 임의로 채우거나 source_gaps를 모델의 판단으로 꾸며 넣지 않는다.
|
||||
|
||||
차단 review를 출력에 모두 반영해야 한다는 기존 요구를 유지한다. 그룹 별칭을 복원하여 coverage를 검사할 수 있지만, **모델이 평가하지 않은 review를 reducer가 자동으로 평가 완료 처리하지 않는다.** 원본 원장은 불변이고 sparse patch는 여전히 제안이다.
|
||||
|
||||
## 6. 고정 prompt·Schema와 출력 토큰
|
||||
|
||||
이번 작업에서 현행 prompt의 JSON Schema를 메모리에서 변환해 확인했다. 반복되는 `string(minLength=1, maxLength=1600)`, 그 문자열의 unique array, 네 종류 decision 정의를 공통 `$defs`로 치환한 결과, minified UTF-8 표현이 **7,668 → 5,443바이트(2,225바이트, 29.02% 감소)**였다. 새 참조를 역확장하여 원래 Schema 객체와 정확히 같음을 확인했다. 이 수치는 **Schema 표현만의 로컬 실험**이며 실제 모델 토큰·전체 payload·실행 속도 절감률이 아니다.
|
||||
|
||||
이 방법을 prompt 계약에 적용하되, 모델에 필요한 모든 필드·타입·enum·required·배열 최소 개수·추가 필드 금지 규칙을 유지한다. reducer의 원래 정본 Schema는 보존한다. 공통화한 prompt Schema와 정본의 관계는 생성 과정과 역확장 검사로 확인한다. 백엔드가 지원한다고 확인되지 않은 provider-native structured output 옵션을 YAML에 새로 가정하지 않는다.
|
||||
|
||||
시스템 지시는 불변 규칙을 한 번씩 정리하고, 같은 주의 문장을 여러 절에 반복하지 않는다. 요건·항변/재항변·부담·불리한 사실·기간·구제·의뢰인 지시·미확인 근거에 대한 요구는 남긴다. 출력은 기존대로 JSON 한 개와 sparse review patch이고, 원문·hash·원장 전체를 재출력하지 않는다. 이미 현행 prompt에 있는 “짧은 근거, 반복 설명 억제, sparse patch”를 새 토큰 절감 효과로 중복 계산하지 않는다.
|
||||
|
||||
v2는 우선 모델과 추론 설정을 유지한다. 가이드는 `llm_reasoning` 적용을 Google native SDK로 설명하는 반면 현행 YAML은 OpenAI task에 `xhigh`를 지정하므로, 실제 adapter 적용 여부는 확인 대상이다. 단순히 값을 낮추면 속도가 빨라지고 품질이 유지된다고 단정하지 않는다. 모델 교체·reasoning 하향·cache 옵션은 별도 비교를 통과한 뒤 고려하며, 현재 가이드의 다른 provider cache 지원을 현행 모델에 그대로 적용하지 않는다. cache 비용 할인과 실제 입력/추론 토큰 감소도 구분한다.
|
||||
|
||||
## 7. prepare의 반복 계산과 I/O 줄이기
|
||||
|
||||
### 7.1 한 프로세스에서 한 번 계산할 자료
|
||||
|
||||
현행 코드는 cluster마다 전체 signal·review를 순회하여 global blocking과 domain coincidence를 확인하고, 관계·SCC·선행 후보를 검색한다. prepare 시작 시 아래 인덱스를 한 번 구성하고 batch의 각 cluster에서 재사용한다.
|
||||
|
||||
- member·cluster·review ref별 lookup, review 원본 인덱스, 전체 blocking signal·review 집합.
|
||||
- signal/review별 domain hints와 domain별 원본 인덱스 집합.
|
||||
- member별 관계·후보 의존 edge, cluster별 SCC와 원래 논리적 wave.
|
||||
- 이전 검증 후보의 cluster별 lookup와 관련 endpoint.
|
||||
- 필요한 profile·authority 조회, 같은 프로세스에서 검증한 원본·schema 결과.
|
||||
|
||||
선택 결과는 기존과 같아야 한다. domain이 같다는 이유만으로 unbound 자료를 전부 broadcast하거나, blocking 자료를 특정 domain에만 가두지 않는다. unbound counts는 기존 집합 차이와 같은 값으로 계산하고, 공백 표시도 유지한다. 이미 있는 `SealedSources.cache`와 `selected_schema_cache`는 유지하며, 이 기존 동작을 새 개선으로 보고하지 않는다.
|
||||
|
||||
구조 검증에는 원래 선택 집합과 인덱스 방식의 선택 집합 동등성을 포함한다. 프로세스 사이 Python 메모리 공유를 가정하지 않는다. 디스크 cache를 넣는다면 원본 byte hash·schema hash·authority seals·compiler 버전별로 결속하며, 해당 실행에서 확인해야 하는 원본 변경 검사를 생략하지 않는다. 먼저 추가 파일 없이 프로세스 내 인덱싱을 적용하고, cache의 비용 대비 이익이 측정된 경우에만 영속 cache를 추가한다.
|
||||
|
||||
### 7.2 저장·조회
|
||||
|
||||
자료를 pack하고 곧바로 복원 검사할 때 이미 메모리에 있는 객체를 사용한다. 원격 JSON을 같은 함수에서 반복 읽어 파싱하거나, 검증용 대형 payload를 stdout으로 반송하지 않는다. 필요한 최초 read-back과 발행 직전 변경 확인은 유지한다. reducer의 동일성 검사는 compiler의 원본 digest·model packet digest·참조 대응표·control의 결속을 이용하며, 전체 사건을 다시 추론하거나 모든 입력을 다시 map source에 합치지 않는다.
|
||||
|
||||
slot·map source JSON은 UTF-8 텍스트 저장과 실제 `read_docs` 반환 본문을 확인한다. binary envelope를 원본 JSON처럼 취급하지 않고, 잘린 JSON이나 첫 객체만 추출하는 방식으로 성공 처리하지 않는다. 독립적인 읽기·slot 쓰기는 같은 단계에서 순서 의존성이 없으면 제한된 동시 I/O를 비교할 수 있다. MCP 세션과 client의 동시 요청 처리를 확인하고, 각 파일의 write→read-back은 순서를 유지하며, control/index 공개와 status 발행은 선행 작업 완료 뒤에 수행한다. “병렬이면 항상 빠르다”는 이유로 파일 요청을 무제한 늘리지 않는다.
|
||||
|
||||
## 8. 실제 전달 경로와 작업 파일
|
||||
|
||||
### 8.1 우선 구현 경로: 작은 인덱스 + compact slot
|
||||
|
||||
| 파일 | 소비자와 역할 |
|
||||
|---|---|
|
||||
| `work/wave_input.json` | 저장용 공통 영역·사전·최대 8개 items; Python의 원본 복원 검사 |
|
||||
| `work/wave_control.json` | input binding, 논리적 waves·선택 집합, 검증 기준, 별칭 역변환, 원본/packet/index/slot 해시; reducer 전용 |
|
||||
| `work/map_index.json` | 최대 8개 `cluster_ref`·`input_path`·packet hash descriptor; 실제 map source |
|
||||
| `work/llm_input/slot-00.json` ~ `slot-07.json` | 확장본 대신 해당 cluster의 자기완결적 compact packet·repair; 호출 전 지정 파일 읽기 |
|
||||
| `waves/wave-NNNN.json`, `s2_10_status.json` | 원래 ref로 복원한 법률판단 결과와 전체 상태; 후속 handoff |
|
||||
|
||||
prepare에서 저장용 사전을 공통으로 읽고, cluster별 원래 payload를 복원·검증한 뒤 compact packet을 만든다. map은 최대 8개 descriptor를 읽고, backend preflight가 해당 slot 하나만 로드하여 LLM에 전달한다. 모델은 slot 안의 본문 사전을 문서 구조로 읽으며 추가 파일 접근·요약·검색을 수행하지 않는다. map에 별도 Code Executor 복원 task를 붙여 대형 stdout을 `map_results`에 다시 담지 않는다.
|
||||
|
||||
동적 `preflight_files`의 실제 map 동작과 whitelist 적용은 구현 채택 전 검증한다. 현행 `preflight: false`는 지정 backend 읽기를 허용하는 정책과 함께 변경해야 하며 LLM의 임의 도구 호출은 계속 금지한다. shared dictionary에 단지 파일 path만 넣거나, `shared_context`가 임의의 Python 복원 hook을 지원한다고 가정하지 않는다. 원문 전달·중복 삽입 여부를 확인하지 못하면 이 경로를 동작 완료로 보고하지 않는다.
|
||||
|
||||
### 8.2 검증 후 선택할 빠른 경로: 작은 직접 map source
|
||||
|
||||
compact packet을 담은 최대 8개 `items`가 **실제 native `read_docs` 전체 응답과 reducer envelope 예산**을 충분히 만족하면, slot 대신 자기완결적 packet을 map source에 직접 담고 `{{item_json}}`으로 전달하는 경로를 비교한다. 이는 모든 cluster의 확장본을 대형 source로 되돌리는 방식이 아니다. source는 이번 배치에만 한정하고 실제 모델 입력도 compact 상태로 유지한다. 공통 저장 사전을 cluster별로 풀어 넣는 비용과 packet별 사전 중복까지 계산한다.
|
||||
|
||||
이 방식은 slot 쓰기·read-back·preflight I/O를 줄이고 현행 직접 prompt 전달에 가깝지만, SKILL의 `map_results`가 item 전체를 반송하므로 packet이 reducer로 한 번 더 전달된다. 입력과 최대 모델 출력 및 base64 팽창을 합쳐 admission해야 한다. 한 cluster라도 경계를 넘으면 이 경로가 더 빠르다는 이유만으로 강행하지 않는다.
|
||||
|
||||
먼저 한 경로를 선택·검증하여 배포한다. 가이드에 확인되지 않은 “모드별 동적 preflight 전환”이나 skip된 task envelope를 가정하여 두 LLM task를 동시에 설치하지 않는다. direct 경로가 실제로 안전하고 더 빠른 경우에는 배포 구성을 그 경로로 단순화하고 slot 파일을 만들지 않는다. 불확실하면 8.1 경로를 채택한다. 서로 다른 경로에서 나온 결과의 compiler·prompt·해시 binding도 명시적으로 관리한다.
|
||||
|
||||
## 9. 입력 필드 제거와 reducer 기준 유지
|
||||
|
||||
`wave_input.json`에서 다음 10개 최상위 필드는 제거한다. 파생 가능한 값을 모두 다른 파일에 복제하지 않는다.
|
||||
|
||||
| 제거 필드 | 사용 기준 |
|
||||
|---|---|
|
||||
| `algorithm_version` | 코드 `ALGORITHM`과 `input_binding.contract.algorithm` 대조 |
|
||||
| `upstream_root` | 코드 `UPSTREAM_ROOT` |
|
||||
| `output_root` | upstream root와 출력 계약 버전에서 계산; 작은 prepare stdout의 경로는 유지 가능 |
|
||||
| `input_fingerprint` | canonical `input_binding`의 digest |
|
||||
| `expected_clusters` | 원래 `waves`의 평탄화와 중복·coverage 검사 |
|
||||
| `prior_artifacts` | 준비 시 해시로 고정한 기존 status에서 읽고 실제 artifact 검증 |
|
||||
| `previous_wave_sha256` | 기존 status의 대상 논리적 wave artifact 해시; 최초 실행에는 부재 확인 |
|
||||
| `execution_mode` | 해시로 고정한 upstream ingress status |
|
||||
| `source_policy_release_class` | 같은 upstream ingress status |
|
||||
| `upstream_status` | 같은 upstream 파일의 status |
|
||||
|
||||
control에는 현재 배치의 `validation`, `input_binding`, 원래 `waves`, `wave_ordinal`, `batch_cluster_refs`, `previous_status_sha256`, `base_summary`, `source_issues`, `reused_complete` 및 입력·인용 변환의 해시 기준을 둔다. 원본 참조 대응표는 모델 판단 대상 자료의 축소가 아니라 내부 표현의 역변환 계약이다.
|
||||
|
||||
reducer는 wire 출력에 대한 복원 후 원래 허용 ref·authority·review·domain·선행 후보 endpoint를 검사한다. 차단 review 반영, 검증 공백에 따른 확정 판단 금지, `missing_inputs`, 의뢰인 미제기 지시와 실제 배제의 구별도 유지한다. 출력 해시·동일 입력 binding·성공 결과 불변·review 제안 충돌·미선택 자료 보존·status-last는 계속 완료 판정에 포함한다.
|
||||
|
||||
## 10. 최대 8개 병렬 배치와 처리시간
|
||||
|
||||
### 10.1 논리적 의존성과 물리적 실행을 분리
|
||||
|
||||
S2_00의 논리적 wave·SCC는 유지한다. 현재 wave에서 미처리 또는 허용된 repair 대상만 선택하고, **한 실행의 cluster 수 ≤8, map 동시성 ≤8**을 모두 적용한다. 각 cluster의 full SCC 원본 이웃 자료와 법률판단 한계를 유지하며, 같은 논리적 wave의 앞 배치 결과를 뒤 배치의 선행 verdict로 추가하지 않는다. 다음 논리적 wave는 현재 wave 전체가 검증된 뒤에 시작한다.
|
||||
|
||||
배치 선택 순서는 같은 논리적 wave 안에서 바꿀 수 있으나 결과 파일의 cluster 순서는 원래 순서로 정규화한다. 최대 8개를 항상 채울 의무는 없다. cluster별 입력·출력 상한, 전체 MCP 응답, 동시 토큰 및 시간 예산에 따라 개수를 줄인다. retry도 같은 예산을 적용하고 원래 실패 항목에 대한 보정 횟수를 늘리지 않는다.
|
||||
|
||||
### 10.2 배치 종료 대기를 줄이는 선택
|
||||
|
||||
현행 자료에서 직접 사용할 수 있는 것은 packet 크기, 관련 자료 수, repair 여부이고 실제 처리시간은 실행 후 얻는 값이다. 이들을 토대로 긴 작업끼리 같은 배치에 놓는 방식 등을 비교하여, 모든 배치에 한 개씩 긴 작업이 섞여 reducer가 반복 대기하는 상황을 줄인다. 과거 지연을 사용할 때는 같은 모델·prompt·입력 표현 버전별로 측정하며, 토큰 수만으로 reasoning 시간이 정확히 예측된다고 가정하지 않는다.
|
||||
|
||||
개념적 예로, 16개 독립 작업 중 8개가 100초, 8개가 10초이고 모든 작업이 동시에 시작되며 자원 경쟁이 없다면, 두 배치에 긴 작업을 섞는 경우 map 대기는 200초이고 긴 8개·짧은 8개로 묶으면 110초다. 이는 선택 전략을 설명하는 계산 예시이며 실제 workspace 성능 수치가 아니다. 큰 입력을 한꺼번에 묶으면 TPM·메모리 제한을 넘을 수 있으므로 그 경우 크기 admission이 우선한다.
|
||||
|
||||
cluster별 모델 task는 하나로 유지한다. 법률판단을 여러 작은 LLM task로 쪼개거나 관련 없는 cluster를 한 번의 8-cluster 공동 판단으로 합치지 않는다. 전자는 prompt·자료 재전송과 집계 비용을 늘리고, 후자는 긴 출력·사실 혼합·실패 시 여러 cluster 재처리 위험이 있다. 같은 wave에서 어떤 cluster가 먼저 완료해도 reducer는 해당 배치의 결과를 기다리는 현행 계약을 유지한다. 확인되지 않은 rolling scheduler·Stage loop를 YAML에 추가하지 않는다.
|
||||
|
||||
### 10.3 이어 실행과 발행
|
||||
|
||||
46개가 같은 wave에 있고 admission이 8개씩 허용하면 최소 6번의 Agent 실행에서 총 46번의 모델 판단이 필요하다. 전체 처리 자동화는 호출자가 status에 따라 **한 writer로 순차 재호출**하는 책임이다. 재호출 사이에 준비 비용이 다시 발생함을 숨기지 않는다. 실행 중인 slot·control을 다음 실행이 덮어쓰는 overlapping Agent 호출은 하지 않는다.
|
||||
|
||||
배치가 끝나면 논리적 `wave-NNNN.json`에 결과를 누적한다. 전체 기대 cluster와 실제 시도한 cluster의 포함·중복·coverage를 검사하고, 미선택 항목은 pending으로 유지한다. 실패 없음+pending은 `NEXT_WAVE_PENDING`, 선택 항목의 기술 실패는 `TECHNICAL_INCOMPLETE`, 전체 완료 후 법률상 공백은 `COMPLETED_WITH_ISSUES`로 구분한다. 검증 완료 항목은 수정하거나 재호출하지 않는다.
|
||||
|
||||
부분 wave의 누적 쓰기는 원래 결과 파일보다 계약을 확장하므로 새 알고리즘·Schema·출력 버전 경로에 반영한다. 기존 wave 파일을 매 배치 갱신하는 비용은 일단 유지하여 복잡한 per-cluster journal을 만들지 않는다. 대규모 사건에서 누적 읽기·쓰기가 실제 병목으로 측정된 경우에만 별도 immutable 부분 결과를 모아 최종 wave를 만드는 대안을 검토한다. 현재 46개 사례만으로 추가 checkpoint 체계를 정당화하지 않는다.
|
||||
|
||||
wave read-back 후 status를 마지막에 저장한다. 그 사이 중단되면 고아 wave와 이전 status가 충돌할 수 있으므로 단순 재실행으로 덮어쓰지 않는다. 같은 binding·기존 유효 결과 보존·부분 저장 상태를 확인한 복구가 검증된 경우에만 이어 처리한다. single writer는 원자적 서버 잠금·CAS를 대신하지 않는다.
|
||||
|
||||
## 11. 자료를 선별해 더 줄이는 방안의 경계
|
||||
|
||||
“법리 판단에 필요한 것만 남긴다”는 목적은 타당하지만, 현재 원본의 자유 서술에서 어떤 항목이 불필요한지를 deterministic code가 항상 판단할 수는 없다. v2 기본안은 원래 선택된 법률 자료의 값을 모두 유지한다. 미래의 선별 규칙은 원본 필드별 사용 목적·source/ref 보존·대체 표현·제외 이유를 정하고, **규칙에 없는 필드와 관련성을 확신할 수 없는 자료는 유지**하는 방식이어야 한다.
|
||||
|
||||
검증 해시·저장 경로·처리 로그처럼 판단과 무관하다고 계약상 확인된 메타데이터는 model packet 밖에 둘 수 있다. 반면 “사용 안 된 ref니까 본문 삭제”, “같은 domain이 아니니까 차단 review 제외”, “같은 사실처럼 보이니까 증거 하나만 보존”, “당사자끼리 연결되지 않았으니까 SCC 이웃 제거”, “해당 요건이 아직 없으니까 profile의 항변 질문 제외”는 채택하지 않는다. 원래 profile_catalog가 허용한 다른 법률영역도 임의로 제거하지 않는다.
|
||||
|
||||
한 번 더 LLM으로 모든 cluster를 요약하는 구조는 입력·reasoning·출력·재시도 비용과 법률 자료 누락 경로를 추가하므로 기본안에서 제외한다. 필요한 자료를 조건부 추가하는 방식도 기존 출력 계약·도구 금지 정책·총 호출 수를 바꾸므로 별도 평가 대상이다. 단일 cluster가 예산을 넘는 경우 compact 표현을 더 적용하거나 명시적으로 미완료를 보고하며, 법률 자료를 잘라 성공으로 표시하지 않는다.
|
||||
|
||||
## 12. 검증 계획과 채택 기준
|
||||
|
||||
### 12.1 코드와 표현의 동등성
|
||||
|
||||
- 저장용 pack/unpack 및 model packet 역변환에서 원래 14개 값·cluster_ref·repair 자료의 canonical 동등성을 검사한다. occurrence·순서·null·배열·서로 다른 partition/차단 상태·유사 문장·본문과 마커의 충돌을 포함한다.
|
||||
- alias→원본 ref가 1:1이고 field pointer가 허용 범위 안에 있는지 검사한다. 명시적으로 허용한 review 그룹만 정확한 집합으로 확장하고, 다른 ref 종류로 바꿔 인용할 수 없게 한다.
|
||||
- 원래 선택 코드와 새 인덱스 코드의 member/signal/review/profile/authority/관계/SCC/선행 후보 집합과 source_gaps·unbound counts가 같은지 확인한다.
|
||||
- 공통화한 prompt Schema를 역확장해 정본과 대조하고, 모델 출력 복원 뒤 기존 Schema·참조·차단·coverage 검사를 실행한다.
|
||||
|
||||
### 12.2 실제 모델과 실행의 비교
|
||||
|
||||
같은 S2_00 snapshot에서 원래 확장 payload와 v2 packet을 같은 모델·추론 설정·출력 계약으로 비교한다. **구조 검증 통과율만으로 법률판단 품질 유지를 선언하지 않는다.** 요건·항변/재항변·부담·구제·불리한 사실·의뢰인 지시·공백의 누락, 원본 인용 정확성, 차단 review coverage, 근거 없는 확정 판단, 후보 관계의 정합성을 검토한다. 출력 문장이 동일할 필요는 없으나 중요한 검토 항목과 근거가 빠지지 않아야 한다. authority 없는 결과가 모두 조건부라는 사실만으로 비교 품질을 높게 평가하지 않는다.
|
||||
|
||||
packet 사전 해석으로 reasoning이나 오류 보정이 늘면 그 비용을 포함한다. 실제로 이익이 없는 cluster에서는 일반 payload 표현을 선택하고, 표현 선택은 prepare가 입출력 예산과 검증된 규칙으로 수행한다. packet의 일반·사전 표현 모두 같은 입력 slot 계약을 사용하게 하면 map task를 두 종류로 늘릴 필요가 없다. 검증된 이득이 없으면 짧은 별칭이나 Schema 공통화만 적용할 수 있다.
|
||||
|
||||
### 12.3 수집할 지표
|
||||
|
||||
| 지표 | 비교 목적 |
|
||||
|---|---|
|
||||
| system/schema + 실제 model packet + repair의 전체 입력 토큰 | 모델 입력 자체의 감소 확인; 파일 바이트 수와 구분 |
|
||||
| output·reasoning 토큰, cache/billing 구분 | 별칭 효과와 해석 부담, 총 토큰 비용 비교 |
|
||||
| cluster별 지연, 배치 map 종료시간, 전체 사건 종료시간 | 병렬 구성·재호출·긴 작업 대기 효과 비교 |
|
||||
| prepare·읽기/쓰기·preflight·reducer 시간과 MCP 횟수/바이트 | 추가 파일·인덱스·direct 전달 경로의 이득 검증 |
|
||||
| 구조/참조 실패·보정 횟수·법률 검토 항목 누락 | 효율을 위해 목적을 훼손했는지 확인 |
|
||||
| 완료·pending·실패·자료 공백·review 미해결 coverage | 일부 성공을 전체 성공으로 오인하는지 확인 |
|
||||
|
||||
현행 entry의 `usage`는 null이며 문서화된 map 결과에서 사용량을 얻지 못한다고 표시한다. provider/backend가 실제 usage를 제공하는 경로를 확인하지 못하면 임의의 reasoning 토큰을 기록하지 않는다. 입력 토큰은 대상 모델에 맞는 확인된 측정 방법을 사용하고, 사용량 확보를 위해 모델에게 hash·토큰 계산을 시키지 않는다.
|
||||
|
||||
0·1·8·9개, 8개 초과 SCC, 한 cluster의 크기 초과, 동일 본문·다른 ref/상태, 실패 하나의 한 번 보정, stale slot/control, 출력 누락, wave 저장 후 status 저장 전 중단, 완료본 재사용을 검증한다. 완료본 재사용은 모델 호출 0회이다. 안전 상한은 실제 배포 환경에서 확인하며, 기존 768,000바이트나 32 MiB 값을 모델·MCP·Agent 전체 한도로 오인하지 않는다.
|
||||
|
||||
## 13. 구현 순서·결정 기록·잔여 한계
|
||||
|
||||
1. **원본 고정:** 현재 YAML·S2_00 snapshot과 계약을 기록한다. S2_00은 유지하고 새 S2_10 알고리즘·prompt·compiler·wire·출력 계약 버전을 정의한다.
|
||||
2. **저비용 변경:** prepare 인덱스, prompt Schema 공통화, JSON 객체 저장, 10개 필드 파생을 구현하고 기존 값·선택 집합이 유지되는지 확인한다.
|
||||
3. **모델 입력 단축:** 한 cluster 안의 본문 사전과 참조 별칭을 구현한다. 원본 복원·정본 출력 검증을 먼저 통과시키고 실제 모델의 해석·검토 범위를 비교한다.
|
||||
4. **전달 경로:** 작은 descriptor+slot을 검증한다. 소형 직접 source는 같은 사건으로 전체 envelope·I/O·시간을 비교한 뒤 실제 이익이 있는 경우에만 채택한다.
|
||||
5. **최대 8개 실행:** admission·wave 내부 배치 선택·부분 누적 발행·미선택 pending·single repair를 연결한다. 같은 wave 판단이 뒤 배치의 선행 후보에 섞이지 않게 한다.
|
||||
6. **최종 비교:** 품질 보존과 총 비용·전체 시간의 개선을 확인한 범위에서만 개정 효과를 보고한다. 기존 완료 결과는 보존하며 새 버전 경로에서 실행한다.
|
||||
|
||||
| 결정 | 이유 | 불확실성 또는 되돌림 조건 |
|
||||
|---|---|---|
|
||||
| 법률 자료 삭제보다 자기완결적 무손실 표현을 우선 | 직접 입력을 줄이면서 원본 값·참조·한계를 보존 | 모델 해석 부담·검토 누락 증가 시 확장 입력 유지 |
|
||||
| 검증 기준과 원본 ref는 reducer에서 유지 | wire 단축과 최종 계약의 충돌 방지 | alias 오류는 복원 단계에서 기술 실패 처리 |
|
||||
| 한 cluster당 한 LLM task, 최대 8개 | 현행 책임 경계 유지, 재시도·큰 출력 위험 억제 | 호출·TPM·시간 예산에 따라 배치 축소 |
|
||||
| 새 cache·journal·동적 라우터는 기본안에 넣지 않음 | 전략 자체의 불필요한 구성과 파일 I/O 억제 | 실제 병목·지원 계약 확인 뒤에만 추가 |
|
||||
|
||||
**이번 작업의 진행:** v1·현행 코드·지정 가이드를 대조했고, Schema 표현의 로컬 역복원 실험을 수행했으며, v2 전략서와 MEMORY 요약을 작성했다. model packet compiler, alias 출력 복원, 인덱스 동등성, 새로운 배치·발행 계약은 아직 구현하지 않았다. workspace 실행·실제 토큰·reasoning·지연·법률판단 품질 비교도 수행하지 않았다.
|
||||
|
||||
**실행 기준:** 향후 YAML/Python은 지정 SKILL과 notebook을 따른다. 패키지는 줄바꿈 requirements로 전달하고, 별도 pip 설치 task나 cluster별 Python 실행 task를 만들지 않는다. 단일 prepare 안에서 공통 객체를 재사용하며 Code Executor 호출 사이 메모리 공유를 가정하지 않는다. 인증·workspace 격리·MCP 초기화와 session/notification 계약을 유지하고 사건 본문을 Python 소스에 직접 삽입하지 않는다.
|
||||
|
||||
**잔여 한계:** 구조상 가능한 토큰 단축이 곧 실제 추론 토큰 감소나 법률 품질 보존을 뜻하지 않는다. 가장 큰 본문이 모두 서로 다른 법률 자료라면 무손실 표현의 절감폭은 작다. 전체 모델 호출 수는 기본적으로 cluster 수와 같고, 여섯 배치로 나누어도 46개 판단이 6개 판단으로 줄지 않는다. 크기 한도 초과·preflight 지원·모델 설정 적용·중단 복구를 실제 확인한 뒤에만 안정 실행을 보고한다.
|
||||
+7
@@ -0,0 +1,7 @@
|
||||
# S2_10 wave 입력 구조 개정 평가
|
||||
|
||||
**Goal 1 — 필드 조정: S2_10 목적에는 조건부 적합하며, 단독 효율 개선은 제한적이다.** 2026-10-04에 검토한 [현행 YAML](Stage_2_S2_10.yml)의 준비 코드·map 프롬프트·reducer를 기준으로 보면, 제시한 10개 필드를 `wave_input.json`에서 제외해도 법률관계·청구권·구제수단 후보 판단과 결과 발행 목적을 유지할 수 있으나, 현재는 모두 코드에서 참조하므로 생성·소비 코드를 함께 변경해야 한다. `algorithm_version`·두 root·`input_fingerprint`·`expected_clusters`는 상수, 입력 계약, 경로 계산, `waves`에서 얻고, 기존 artifact와 대상 wave 해시는 `previous_status_sha256`으로 고정한 기존 status를 검증한 뒤 얻으며, 실행 모드·배포 등급·upstream 상태는 `input_binding`에 결속된 upstream status에서 얻어야 한다. 준비 task가 반환하는 `output_root`는 map 경로 치환에 여전히 필요하므로 파일 내부의 동명 필드 제거와 구별하고, wave/status의 기존 출력 계약도 유지해야 한다. 나열한 14개 법률판단 필드와 함께 기존 `cluster_ref`, 자료별 원본 참조, authority의 사용 가능 여부, review의 차단 상태를 보존하고, 최초 실행의 `repair_json`은 JSON null을 나타내는 문자열로 두며 보정 실행에서는 원래 입력과 구조 오류 정보를 유지해야 한다. 이 조정은 중복 metadata와 map source 전송량을 줄이지만, 현행 모델 프롬프트에는 원래 `payload_json`과 `repair_json`만 들어가므로 LLM 입력 토큰을 직접 줄이지는 않는다. reducer가 이미 읽는 status를 한 번 파싱해 재사용하면 추가 I/O를 억제할 수 있으며, 제거한 값을 얻기 위해 원본 대형 파일을 반복 조회하면 오히려 느려질 수 있다. 따라서 Goal 1은 검증 기능을 보존하는 중복 제거로 평가해야 하며, 큰 폭의 용량·속도 개선은 Goal 2·3에 달려 있다. 분석 기준 YAML SHA-256은 `3d8616c2e2a1c3a5f405ba9806718b9ac519843ddc02c80ff4d51a67c42e8c50`이다.
|
||||
|
||||
**Goal 2 — 공통 본문·사전 참조 저장: 목적 보존과 저장·전송 효율 개선 측면에서 가장 효과적이다.** 동일한 `goal`·`profile_catalog`를 공통 영역에 한 번 저장하고 완전히 동일한 review·profile 객체를 사전으로 공유하면, 사실·반대자료·미해결 review·법적 근거·판단 한계를 삭제하지 않고 cluster별 중복을 줄일 수 있다. 다만 공통 영역에 올리는 값은 모든 대상 cluster에서 실제로 동일한지 검사하고, review의 본문만 같아도 서로 다른 원본 참조·partition·차단 상태를 합치거나 소거해서는 안 된다. 현재 map은 `items`만 추출하고 LLM task에는 추가 파일 읽기 권한이 없으므로, 사전 참조를 저장하는 변경만으로는 작동하지 않으며 공통 영역을 한 번 읽어 재사용하고 각 모델 호출 전에 해당 cluster의 완전한 논리적 payload를 deterministic하게 복원하는 실행 경로가 필요하다. 전체 입력을 먼저 복원해 다시 대형 map source로 전송하는 방식은 전송량 개선을 상쇄하므로, cluster별 복원 또는 지원이 확인된 공통 context 전달을 사용하고 추가 LLM 요약·조회 호출은 만들지 않는 편이 타당하다. map source용 파일은 `read_docs`가 원본 텍스트 JSON을 반환하는 저장·조회 계약에 맞추고, cluster별 크기 외에 공통 사전을 포함한 전체 source의 전송 크기도 제한해야 한다. 앞선 2026-10-03 workspace 관측에서 46개 `items`는 1,902,126바이트였고, 공통 본문·중복 객체 분리와 중첩 JSON 문자열을 객체로 바꾸는 직렬화 개선을 함께 적용한 메모리 실험에서는 공통 영역과 사전까지 포함해 598,663바이트로 68.53% 줄었으며 필드 값 복원 검사가 통과했다. 이는 Goal 2의 사전 공유만으로 얻은 절감률이나 전체 파일의 절감률이 아니고, 이번 평가에서 재측정하거나 backend 구현·실행으로 검증한 수치도 아니다. 복원 후 모델에 같은 자료를 전달하면 LLM 입력 토큰은 거의 그대로이며, 전송량 감소가 읽기·파싱 시간을 줄일 가능성은 있지만 실제 속도는 복원 비용과 추가 MCP 호출 수에 따라 달라진다. 따라서 동일한 cluster·참조·review 범위와 canonical payload 해시의 일치를 확인한 뒤 효과를 판정해야 하며, 저장 표현이 작아진 것만으로 법률판단 품질이나 기존 대용량 MCP 오류의 해소를 보장해서는 안 된다.
|
||||
|
||||
**Goal 3 — reducer용 독립 JSON: 역할 분리에는 적합하지만, 제시된 이관 대상만으로는 효율 개선 목적을 충분히 달성하지 못한다.** Goal 1의 10개 필드를 입력 파일에서 빼고 다른 파일에 보관하는 것은 위치를 옮기는 설계로서 양립 가능하나, 재계산 가능한 값을 전부 별도 저장하면 총 저장량 감소는 작고 추가 파일 쓰기·읽기 비용이 생긴다. 특히 문자 그대로 그 10개만 옮기면 현재 Goal 1 이후에도 남는 `validation`, `input_binding`, `wave_ordinal`, `waves`, `previous_status_sha256`, `base_summary`, `source_issues`, `reused_complete`가 map source에 계속 포함되어 LLM용 입력과 reducer용 계획이 충분히 분리되지 않는다. 앞선 관측에서 `validation`만 489,373바이트였으므로, 원하는 분리를 달성하려면 독립 JSON의 범위를 이 검증·처리 정보까지 포함하도록 명확히 하고, 10개 필드 중 재계산하는 값과 추적 목적으로 보관하는 값을 구별해야 한다. 이렇게 범위를 정리하면 입력 JSON에는 cluster별 모델 입력과 Goal 2의 공통 영역·사전만 두고, reducer JSON에는 허용 참조·authority·차단 review·후보 연결 검증과 전체 coverage·기존 결과 보호에 필요한 기준을 유지할 수 있어 S2_10 목적에 부합한다. 두 파일은 새 request ID 없이 기존 경로·cluster 참조와 해시로 결속하고, 준비 task가 입력 파일을 저장·read-back한 뒤 그 해시를 포함한 reducer 파일을 저장·검증하며, 준비 결과에는 필요한 두 파일의 해시를 전달하도록 개정해야 한다. reducer는 파일 결속, 복원된 payload 해시, map 항목 대응을 검사하고 발행 직전 두 파일의 변경 여부를 재확인해야 하며, 이는 두 파일의 물리적 원자 저장을 보장하는 방식은 아니다. Goal 2와 함께 적용하면 map이 약 489KB의 validation 및 처리 metadata를 매번 운반하는 비용을 줄일 수 있지만, LLM 토큰 절감은 직접 발생하지 않고 추가 I/O를 포함한 실제 속도는 미검증이다. 최종 채택은 동일 입력 복원, 참조·차단 review 검증, 파일 변조·부분 저장 거부, 빈 입력·완료본 재사용·실패 cluster 보정, 기존 wave/status 결과 계약과 status-last 발행을 유지하는지 확인한 뒤 판단하는 것이 타당하다. 이번 산출물은 세 Goal에 대한 평가서이며 S2_00·S2_10 YAML 개정이나 backend 재실행은 수행하지 않았다.
|
||||
@@ -4,6 +4,24 @@
|
||||
|
||||
## How to Write MEMORY.md
|
||||
|
||||
### 2026-10-04 — S2_10 전략 v2: 실제 모델 입력·반복 처리 단축
|
||||
|
||||
한 줄 요약: `agent_scripts/S2_10_revision_strategy_v.2.md`에 cluster 내부 본문 공유·임시 인용 별칭·Schema 공통화·prepare 인덱싱·예산 기반 최대 8개 배치를 제안했다. 저장 중복 제거와 실제 모델 토큰 개선은 별도로 검증한다.
|
||||
|
||||
- Schema 공통화의 로컬 실험에서 7,668→5,443바이트(29.02%)와 원래 객체 역복원만 확인했다. 모델 packet과 별칭은 원본 자료·review occurrence를 보존하고 reducer에서 원래 ref로 복원하도록 설계했으며, 해석 부담·재시도·전체 지연과 법률 검토 누락을 함께 비교한다. v1·YAML·backend는 변경하지 않고 전략서와 본 기록만 작성했다.
|
||||
|
||||
### 2026-10-04 — S2_10 최대 8개 배치·공통 입력 개정 전략
|
||||
|
||||
한 줄 요약: `agent_scripts/S2_10_revision_strategy_v.1.md`에 공통 자료의 무손실 복원, 작은 map 인덱스, 최대 8개 배치, 논리적 wave 누적 발행을 연결한 개정 전략을 작성했다.
|
||||
|
||||
- 동시성 8과 실행당 입력 8을 구분하고, 10개 파생 필드 제거·reducer control 분리·텍스트 JSON/preflight 전달을 설계했다. 같은 wave의 앞 배치 판단을 뒤 배치의 선행 후보로 사용하지 않으며, 실제 모델 토큰 절감과 backend 한도 충족은 별도 검증 대상으로 남겼다. 전략서와 본 요약만 작성하고 YAML·backend 실행은 변경하지 않았다.
|
||||
|
||||
### 2026-10-04 — S2_10 wave 입력 구조 개정 평가
|
||||
|
||||
한 줄 요약: `agent_scripts/S2_10_wave_revision.md`에 Goal 1·2·3의 목적 적합성과 토큰·속도 효율을 각각 한 문단으로 평가했다. 입력 중복 제거와 reducer 기준 보존을 함께 설계해야 한다.
|
||||
|
||||
- 10개 필드만 이관하면 `validation` 등 reducer 정보가 입력 파일에 남는다는 범위 불일치를 지적하고, 공통 본문·사전의 호출 전 deterministic 복원과 두 파일의 해시 결속을 채택 조건으로 제시했다. 앞선 68.53% 수치는 직렬화 개선을 포함한 메모리 실험이며 LLM 토큰·실행 속도·MCP 오류 해소의 검증 결과가 아님을 명시했다. 평가서와 본 요약만 저장하고 YAML·backend 실행은 변경하지 않았다.
|
||||
|
||||
상단에 한 줄 요약이 있는 task당 하나의 교훈을 저장하라.
|
||||
수정 사항과 확인된 접근 방식을 모두 간략하게 기록하고, 왜 중요한지 포함하라.
|
||||
이미 저장소나 채팅 기록에 있는 정보는 저장하지 마라.
|
||||
|
||||
Reference in New Issue
Block a user