실행 비용과 작업량의 증거 지도

2026-09-12 추가 관측. 이 페이지는 언어 전체의 지표 목록이나 실시간 대시보드가 아니라, 자기개선 실행 경로의 비용·작업량 지표를 읽는 상세 지도입니다. 이미 공개한 전체 지표 탐색과 과거 관측값을 대체하지 않습니다. 수치는 해당 head와 실행에 고정됩니다.

02:48 UTC 후속 관측: 실제 작업량 기록 확보

#814 첫 번째 전용 실행은 30분 제한으로 취소됐습니다. GitHub의 실패 주석이 이 원인을 명시했습니다. 다만 업로드된 artifact 10290225924에 완료된 검증 프로세스 네 개의 실제 작업량 기록이 남았습니다. 아래 값은 취소된 실행의 관측값이지, 전체 작업이 통과했다는 증거가 아닙니다.

실제 작업·회차	verifier elapsed_ns	파싱한 행	시간·ok 표기 행	테스트 파일 없음 표기 행	화면에 남은 행
SplitGoDeclarations 첫 실행	424324508745	383	209	174	16
SplitGoDeclarations 재실행	410046762683	383	209	174	16
CollapseAssignReturn 첫 실행	404086356745	383	209	174	16
CollapseAssignReturn 재실행	402359027676	383	209	174	16

trace 이벤트는 24개이고, 종료된 verifier 프로세스 4개 모두 verifier_work를 가집니다. 네 프로세스의 종료 코드는 각각 0입니다. 각 기록은 input_coverage=COMPLETE, process_binding=MATCHED이며, 별도 표시용 요약과 invocation·action·pass를 대응하면 각각 정확히 한 기록이 연결되고 원본 stdout digest·바이트 수가 모두 일치합니다.

각 실행의 fail_rows=0, cached_marker_rows=0, unrecognized_lines=0입니다. 383은 패키지 요약 행 수이고 테스트 사례 수가 아닙니다. 174개의 [no test files] 행은 시간이 없는 관측이며 실패나 0초 실행으로 바꾸지 않습니다. 캐시 표기 0개도 컴파일 캐시 미사용이나 모든 테스트 재실행의 증거가 아닙니다.

표시용 파일은 TRUNCATED_OUTPUT_FILE로 16행을 남겼지만, 파서 한도 안에서 확보한 원래 383행 계수는 소실되지 않았습니다. 이것이 이번에 실제로 확인한 기능 범위입니다. 파서의 COMPLETE가 언어 전체의 완전성을 뜻하지 않으며, execution_claims=NOT_INFERRED, reuse_authority=OUTPUT_MARKER_ONLY, improvement=UNKNOWN은 유지됩니다.

증거 결합	값
head	b3c688bde7fe5e0b3215c0328315923eb440cae1
plan digest	da6921cba067c7b6bef31b3118db4bde57e6aa0b7d2ccbe7b785e142ebdc9238
manifest digest	f71730eff62c8167f63829d23e984f37cdb15e2c9d66c1aa6d9d83d98fb4d695
Gooo 입력 계약 source digest	b886df4511dab6fcc9f37a9a661594f0fd8bb24f43f92337bb30146354177a0a
Gooo 입력 계약 semantic digest	b9a780ed3ba67f58bd91a86e83280ef8b98fd3b38893dc11ddd69169c85e012e
다운로드한 artifact SHA-256, GitHub 메타데이터와 일치	7e447b17aef993a0da5cc19afe5e88954d543dc81c5563d37a3f897db203def8

02:52 UTC에 같은 head의 두 번째 실행이 시작됐습니다. 종료된 작업만 1회 재실행했으며 검사 범위, 30분 제한, 소스·CI 설정은 변경하지 않았습니다. 최종 정책 CI도 별도로 계속 실행 중입니다. 첫 실행의 산출물과 두 번째 실행의 최종 통과 여부를 섞지 않으며, 같은 시간 초과가 반복되면 무한 재시도 대신 실제 구간 비용과 검증 구조를 바탕으로 별도 개선을 설계합니다.

1. 먼저 묻는 질문

검증이 오래 걸릴 때 필요한 것은 단순히 “느리다”는 점수가 아닙니다.

1. 어떤 Gooo 작업이 어떤 입력으로 실행됐는가?
2. 변환·평가·검증 중 어느 구간에서 시간이 관측됐는가?
3. 그 검증 출력에서 실제로 몇 행을 읽었는가?
4. 출력에 캐시 표기가 있었는가, 실제 재사용까지 증명됐는가?
5. 출력이 잘렸다면 무엇까지 말할 수 있는가?

이 질문에 답하는 관측과, 동작을 생략하거나 변경해도 된다는 권한은 다릅니다. 진단 지표가 CI 우회 권한을 만들지 않습니다.

2. 숫자와 메타 코드의 연결

.gooo 작업 입력 계약
  | source digest + semantic digest
  v
선택 계획 + 실행 명세
  | head + plan digest + manifest digest
  v
작업 Activity / action indicator / first 또는 replay
  |
  +-- evaluator: 적용 가능한가?
  +-- executor: 허용된 변환 실행
  +-- verifier: 변환 결과 검사
          |
          v
      PROCESS_RETURNED
          |
          +-- cost.elapsed_ns: 그 프로세스 구간의 시간
          +-- 실제 stdout의 digest와 바이트 수
          +-- verifier_work: 제한된 출력 파싱의 작업량
                  |
                  v
              행 수 / 상태 / 표기 / 읽은 범위
                  |
                  v
              사람이 보는 요약과 원본 증거

연결할 소스는 Gooo 입력 계약, 실행 trace, 작업량·시간 관측, 출력 파서와 표시 제한입니다. 이 링크의 head는 #814의 PR 후보이며, 공개 릴리스나 병합 완료를 뜻하지 않습니다.

3. 지표 사전: 한국어 의미와 금지되는 해석

실제 필드	한국어 의미	단위·범위	이것만으로 말할 수 없는 것
cost.elapsed_ns	관측 경계 사이에 흐른 시간	정수 ns, 해당 구간	CPU 사용량, 전체 CI 시간, 원인
verifier_work.observed_rows	파서가 인식한 패키지 요약 행	행, 반복된 경로도 별도 행	고유 패키지 수, 테스트 사례 수
elapsed_observed_rows	시간이 표시된 행	행	실행한 테스트 수
elapsed_unknown_rows	행에 시간이 관측되지 않은 경우	행	실행 시간이 0이라는 주장
ok_rows, fail_rows, question_rows	출력의 상태 표기별 행	세 범주	언어 기능의 성공·실패·완성률
cached_marker_rows	(cached) 표기를 읽은 행	행	해당 head에서 사례를 재실행했다는 증거
no_test_files_marker_rows	테스트 파일 없음 표기	행	제품 효용 또는 의미 검증 완료
no_tests_to_run_marker_rows	실행 대상 테스트 없음 표기	행	모든 테스트가 성공했다는 주장
build_failed_marker_rows, setup_failed_marker_rows	빌드·설정 실패 표기	행	실패를 UNKNOWN으로 바꿀 허가
unmarked_rows	위 표기가 없는 인식 행	행	아무 작업도 하지 않았다는 주장
unrecognized_lines	파서가 요약 행으로 인식하지 않은 줄	줄	그 줄의 의미·성공 여부
input_coverage	파서가 본 입력의 범위	상태값	전체 테스트 분모
process_binding	실제 출력과 프로세스 관측의 digest·크기 대응	MATCHED / UNOBSERVED / MISMATCH	실행 진위 또는 의미 수용의 독립 증명
execution_claims	출력에서 실행 수를 추정하지 않음	NOT_INFERRED	실행 사례 계수
reuse_authority	재사용 해석의 한계	OUTPUT_MARKER_ONLY	검증 생략 권한
improvement	통제된 개선 관측의 상태	현재 UNKNOWN	시간·메모리·추론 비용 감소

단위는 PACKAGE_SUMMARY_ROWS_NOT_TEST_CASES, 범위는 BOUNDED_STDOUT_PARSE_ONLY입니다. 원문 stdout 전체를 보고서에 복사하는 대신 digest와 계수를 결합합니다. 이 사전은 #814에 추가된 필드의 해설이며, 아래에서 따로 확인하지 않은 실제 실행값을 채우지 않습니다.

4. 세 계수 축은 서로 합산하지 않음

observed_rows = elapsed_observed_rows + elapsed_unknown_rows

observed_rows = ok_rows + fail_rows + question_rows

observed_rows = cached_marker_rows
              + no_test_files_marker_rows
              + no_tests_to_run_marker_rows
              + build_failed_marker_rows
              + setup_failed_marker_rows
              + unmarked_rows

세 식은 같은 행을 서로 다른 관점으로 나눈 것입니다. 세 우변을 모두 더하면 같은 행을 세 번 세게 됩니다. 같은 패키지 경로의 첫 실행과 재실행도 서로 다른 관측입니다. 시간·상태·표기의 보존 관계가 맞아도 전체 테스트 사례 수는 여전히 별도 자료가 필요합니다.

5. 낮은 해상도와 누락을 구분

기존 파서는 입력 64 KiB, 한 줄 1 KiB, 인식 행 512개로 제한됩니다. #814의 계수는 화면용 샘플링 전에 만들어지지만, 이 파서 제한을 넘어서 전체 입력을 센다는 뜻은 아닙니다.

input_coverage	읽는 방법
COMPLETE	제한된 파서의 입력 관측 범위가 완료됨. 테스트 의미 전체가 완전하다는 뜻은 아님
TRUNCATED	입력·줄·행 제한에 걸림. 계수는 읽은 범위에만 유효
UNRECOGNIZED_INPUT	요약으로 해석할 수 없는 입력. 테스트 0개로 해석하지 않음
NO_PACKAGE_SUMMARIES	패키지 요약을 확보하지 못함. 실행 0건으로 해석하지 않음

표시용 파일의 TRUNCATED_OUTPUT_FILE은 위 파서 상태와 다른 층입니다. 화면에 16행만 남았다는 이유로 원래 관측도 16행이었다고 말하면 안 됩니다. 반대로 원래 계수가 남았더라도 파서 한도 밖의 행 수는 알 수 없습니다.

현재 구현은 이 상태들을 기록합니다. 출력이 잘리면 자동으로 재실행하거나 검증 범위를 축소하는 기능을 이 페이지가 새로 선언하는 것은 아닙니다. 이미 관측된 실패·바인딩 모순은 낮은 해상도라는 이유로 사라지지 않습니다.

6. 실제로 관측된 비용: 서로 다른 실행을 섞지 않음

#812의 전용 변환 실행에서 아래 네 검증 구간을 원본 trace와 패키지 요약의 invocation·action·pass로 대응했습니다. 자세한 판단과 artifact digest는 관측 기록에 있습니다.

작업·회차	verifier elapsed_ns	출력에 표시된 meta-execution 패키지 시간 ns
SplitGoDeclarations 첫 실행	404406650568	308074000000
SplitGoDeclarations 재실행	391197952633	313281000000
CollapseAssignReturn 첫 실행	387758864690	306963000000
CollapseAssignReturn 재실행	389482664680	309026000000

네 프로세스의 종료 코드는 모두 0입니다. 각각의 표시용 요약은 TRUNCATED_OUTPUT_FILE이고 16행이 남아 있었습니다. 이 16을 실행 테스트 분모로 사용하지 않습니다. 두 시간 열은 측정 경계가 다르므로 차이를 곧바로 컴파일 비용이나 캐시 손실이라고 부르지 않습니다.

현재 #814 head b3c688bde7fe5e0b3215c0328315923eb440cae1의 기본 CI 테스트는 02:26:07 UTC에 성공했습니다. 작업 전체는 450초이고, 로그의 meta-execution 패키지 행은 314.557s입니다. 두 값은 다른 범위입니다. 이전 표와 조건을 고정한 before/after 쌍이 아니므로 개선률은 계산하지 않습니다.

기본 테스트 종료 직후의 공개 요약 화면에서는 #814의 새 verifier_work 원본 레코드를 확인하지 못했으므로 당시에는 미관측으로 남겼습니다. 이후 확보한 실제 artifact 관측은 이 페이지 상단의 02:48 UTC 후속 기록에 분리했습니다. 테스트 작업의 통과 자체를 새 계수의 실제 관측으로 대신하지 않았습니다.

7. 구현·CI·병합을 분리한 상태

작업	확인된 상태	아직 닫지 않은 범위
#811 정책 변경 실행	dev 병합, merge 79fc7b58	독립 수용, 공통 실행기로의 정책 자동 채택
#812 실제 비용 요약	dev 병합, merge ada5aa05	성능 개선, 전체 CI 비용 원인
#813 독립 보고서 대조	CI가 생산자 패키지 의존을 거부함. 병합 안 함	소비자 독립성, 최종 CI 수용
#814 검증 출력 작업량	기본·병렬 접근·형식·정적·의미론 검사 통과. 실제 작업량 4기록 확보. 전용 실행 1회 시간 초과 후 재실행 중	최종 정책·재실행 CI, 병합

#814의 Go 1.27 CI formatter 피드백은 기록된 패치를 그대로 반영했습니다. 후속 formatter 영수증의 변경 경로 0개·패치 0바이트·재실행 일치로 형식 피드백만 닫았습니다. 이것을 의미론적 FIXED_POINT 수용이나 자기개선 전체 완료로 확대하지 않습니다.

8. 다음 결정을 위한 최소 증거

결정하고 싶은 것	필요한 증거	현재 이 페이지가 허용하지 않는 단축
새 작업량이 실제 실행과 연결됨	현재 head의 PROCESS_RETURNED, 원본 출력 바인딩, 작업·회차·계수·범위	작성된 테스트 수를 실제 계수로 대체
느린 구간을 줄임	같은 입력·계약·도구·범위의 정확한 before/after, 반례·권한 비회귀	다른 CI 실행 시간끼리 개선률 계산
이전 검증을 재사용함	재사용 대상의 정확한 입력·환경·검증 계약과 유효한 증거	(cached)만 보고 CI 생략
정책 변경을 자동 채택함	독립 관찰·실행 증거와 기존 권한 경계	보고서가 자기 일관적이라는 이유만으로 적용
언어의 사용자 효용이 늘어남	해당 사용자 경로의 실제 결과	PR 수·코드 줄 수·CI 성공 수로 대체

현재는 관측을 더 명확하게 만드는 절편입니다. 실험 언어의 진전을 위해 모든 것을 먼저 완벽하게 만들 필요는 없지만, 작은 성공의 범위를 크게 부풀려서도 안 됩니다.

2026-09-12 12:36 KST 후속 관측: 성공, 시간 초과, 권한은 별개

이 절은 실시간 상태가 아니라 아래 정확한 커밋과 CI 실행에 대한 관측 기록입니다. 앞선 원시 기록은 수정하거나 삭제하지 않습니다.

실제 실행 비용과 완료 여부

관측 대상	정확한 관측	해석 경계
#814 커밋	b3c688bde7fe5e0b3215c0328315923eb440cae1	다른 커밋의 성공을 상속하지 않음
기본 CI의 선언된 계획 실행	1,647초, SUCCESS	02:33:54~03:01:21 UTC
기본 CI의 같은 계획 replay	1,645초, SUCCESS	03:01:21~03:28:46 UTC
별도 focused 검증 첫 시도	30분 job 제한으로 CANCELLED	전체 focused 검증 성공 아님
별도 focused 검증 재시도	같은 30분 job 제한으로 CANCELLED	허용한 재시도 1회 중 1회 사용
두 번째 시도의 첫 effect 실행	wall_ms=40614, peak_rss_kib=515124	완료된 replay 및 독립 검증 결과는 없음
실제 verifier 작업 관측	process 반환 기록 4개, 각 package-summary 383행	테스트 케이스 383개라는 뜻이 아님
각 기록의 화면용 보존 행	16행	383행을 16행으로 축소해 작업량을 계산하지 않음
성능 개선	UNKNOWN	조건이 통제된 before/after 쌍이 아님

근거: 기본 CI policy job, focused 실행과 재시도, 정확한 관측과 후속 결정.

여기서 구분해야 할 세 가지는 개별 process 반환, 해당 job 전체 완료, PR의 병합 가능 여부입니다. 앞 단계가 성공했다고 뒤 단계까지 성공으로 추정하지 않습니다. 또한 바깥 activity 시간과 그 안의 verifier 시간을 더하면 중복 계산이 됩니다.

#815의 회복 경로: 검증 축소가 아닌 단계 분리

PR #815의 커밋은 75c44fb124bdd1413724233f1e88ef23924a069c입니다. 기존 검증 명령과 판정식을 유지하면서 같은 job 안에서 입력 수집과 effect/replay/독립 검증을 별도 단계로 노출합니다.

항목	변경 전	PR #815 후보
바깥 job 시간 예산	30분	45분
입력 수집 단계의 별도 제한	없음	30분
effect/replay/검증 단계의 별도 제한	없음	10분
새 job / artifact 전달 / 권한 추가	해당 없음	0 / 0 / 0
로컬 테스트·빌드·포매터 실행	0	0

45분은 설정된 자원 예산이지 관측된 실행 시간이나 성능 개선량이 아닙니다. 새 입력 단계는 03:27:21 UTC에 시작됐고, 이 기록 시점에는 후속 검증 완료가 관측되지 않았습니다. #814의 실패한 실행을 다시 성공으로 표시하지 않으며, #815가 실제로 수용·병합된 뒤 새 기준 커밋을 #814에 반영하고 그 새 커밋을 CI에서 검증합니다.

UNKNOWN의 출처를 보존하는 권한 관측

#815의 현재 커밋에서 생성된 FOUNDATION protocol artifact 10290648124는 고정된 12개 셀 중 CLOSED 9 / UNKNOWN 3 / REFUTED 0을 기록합니다. 이것은 품질 점수나 병합 권한 75%가 아닙니다.

UNKNOWN 셀	원인	다음에 필요한 증거
REPOSITORY_ACTOR_AUTHORITY	OWNER_SELECTION_MISSING	저장소 소유자 선택
ONE_USE_NONCE	NONCE_NOT_ISSUED	일회성 nonce 발급
EXPIRY_STALENESS	INCOMPLETE_EXPIRY_BINDING	발급·만료 시각 결합

별도 root axiom은 NO_SERVER_SIDE_OWNER_AUTHORIZATION_OPERATION으로 UNKNOWN입니다. 권한 프로토콜을 관측하는 job의 SUCCESS는 권한 자체의 CLOSED가 아닙니다.

Guardian shadow는 과거의 정확한 후보를 요구하는 dispatch 검사에서 현재 PR과의 불일치를 보고했습니다. 해당 실패를 삭제하거나 옛 인가 기록을 현재 PR에 맞춰 다시 쓰지 않습니다. 수용된 기본 코드의 feature_dev 경로와 일반 required-context 선언은 구분하고, 최종 수용에는 현재 커밋의 native proof/route 및 서버가 실제 요구하는 검사를 사용합니다. 강제 병합·보호 규칙 변경·CI 우회·main 또는 release 승격은 하지 않습니다.

근거: 권한·검증 경계 결정 기록, guardian 원본 실행.

지표와 메타 코드의 연결: Gooo 활동에서 나온 계획과 실행 기록을 exact source/semantic digest에 결합하고, 관측된 process 작업량·단계 시간·실패 원인을 각각 독립 축으로 보여줍니다. 시간 초과를 의미론적 실패로 바꾸거나, CI 성공을 효용·권한·개선으로 바꾸지 않는 것이 이 지도의 목적입니다.

#815 후속 관측: 두 단계 완료와 서로 다른 판정의 해상도

정확한 후보 75c44fb124bdd1413724233f1e88ef23924a069c의 focused CI 실행은 SUCCESS로 완료됐습니다. 판정 기록에 실행 ID, artifact ID, 원시 archive digest와 해석 경계를 함께 남겼습니다.

지표가 답하는 질문	원본 코드·증거와의 연결	관측값	이 숫자가 증명하지 않는 것
선택한 메타 작업이 실행기에 연결됐는가?	SplitGoDeclarations, CollapseAssignReturn의 source-bound operation receipts	선택 2, 연결 2, 미연결 0	정책 수정 작업의 자동 채택
변환 결과가 기존 명시 규칙을 만족하는가?	first/ledger.json의 기존 11개 indicator	PASS 11/11	언어 전체의 완전성
잘못된 실행기 연결을 거부하는가?	counterexamples.json의 missing / duplicate / stale 사례	예상한 REFUTED 3/3	모든 가능한 오류의 발견
같은 결과를 재현했는가?	first/replay 결과와 독립 verification.json	replay_equal=true, PASS / EXACT	외부 사용자 효용, 권한 부여
입력 수집과 후속 검증에 얼마가 걸렸는가?	GitHub Actions의 독립된 두 step 시작·완료 시각	1,365초 / 79초	속도 개선이나 45분 제한의 인과적 효과
원본을 변경했는가?	source tree before/after digest, write boundary	원본 변경 0, SANDBOX_ONLY	원본 저장소에 변환을 자동 적용할 권한

관측된 source/semantic 결합은 다음과 같습니다. 이 식별자는 지표를 실제 메타 작업의 입력 계약과 연결하며, 사람이 만든 점수나 작업 제목으로 대체하지 않습니다.

• source digest: b886df4511dab6fcc9f37a9a661594f0fd8bb24f43f92337bb30146354177a0a
• semantic digest: b9a780ed3ba67f58bd91a86e83280ef8b98fd3b38893dc11ddd69169c85e012e

실제 대상도 구분합니다. 파일 분할은 일회용 복사본의 bootstrap/function-extractor/apply.go를 대상으로 했고, 대입·반환 축약은 명시된 collapsefixture를 대상으로 했습니다. 두 사례를 모두 실제 정책 변경이나 외부 제품 효용으로 세지 않습니다.

시간과 메모리의 정확한 관측

범위	wall_ms	peak_rss_kib
첫 effect 생성	34513	489776
effect replay	34215	517388

입력 수집 step은 03:27:2103:50:06 UTC, 후속 step은 03:50:0603:51:25 UTC였습니다. 위 effect runtime은 뒤쪽 step 안의 하위 관측이므로 step 시간에 다시 더하지 않습니다.

이번 성공 실행은 기존 30분 제한 안에도 들어옵니다. 따라서 시간 예산 증가가 성공을 만들었다고 입증된 것은 아니며, improvement=UNKNOWN입니다. 통제된 before/after 없이 더 빠르거나 더 적은 메모리를 쓴다고 주장하지 않습니다. 보고서의 command 2 / test 2는 operation receipt에 기록된 범위이며, reused evidence record 2도 새 테스트 실행 수나 cache hit 수로 바꾸지 않습니다.

현재 확인된 성공은 이 focused 실행에 한정됩니다. 별도 canonical CI policy와 최종 proof/route의 수용은 아직 남아 있습니다. 앞 절의 guardian shadow 실패와 FOUNDATION의 CLOSED 9 / UNKNOWN 3도 그대로 보존하며, promotion_authorized=false입니다.