-
Notifications
You must be signed in to change notification settings - Fork 0
Testing and Reuse
현재 반복 바디 실행의 도구·실행파일 재사용은 반복 조립의 검사·실행 비용에 정리했습니다. 매번 현재 소스와 실행파일을 확인하고 현재 입력을 두 번 실행하며, 보관한 버전·빌드 관측과 현재 프로세스 비용을 runtime v3에서 구분합니다.
2026-10-03 안내: 아래 예제와 관측은 각 절에 고정된 소스·도구체인을 기준으로 읽습니다. 최신 바디 생성과 자체 소형 모델의 흐름은 모델과 메타프로그래밍, 지금 사용할 버전은 현재 상태와 시작하기에 정리했습니다.
Gooo가 테스트를 생략하려면, 먼저 무엇을 실제로 테스트했는지 설명할 수 있어야 합니다.
재사용은 단순히 캐시에 파일이 있다는 뜻이 아닙니다. 특정 입력에서 실행한 특정 테스트의 결과를 보존하고, 다음 실행에 그 결과를 적용할 조건을 확인하는 일입니다. 자기개선도 같은 원리를 따릅니다. 수정 후보를 만들었다는 사실과, 수정한 결과를 다음 실행이 안전하게 사용했다는 사실은 다릅니다.
이 페이지는 주문·재고의 작은 두 파티션 예제와, 코드 변환을 검증하는 실제 Go 실행 경로를 설명합니다. 모든 Gooo 프로그램에 대한 자동 테스트 선택이나 일반적인 의존성 분석이 완성됐다는 설명은 아닙니다.
| 관측 | 알 수 있는 것 | 이것만으로 알 수 없는 것 |
|---|---|---|
| 프로세스 종료 코드가 0이다 | 명령이 성공으로 종료했다 | 원하는 테스트가 실제로 선택됐는가 |
테스트 이름의 run과 pass가 있다 |
그 이름의 테스트가 실행되고 통과했다 | 현재 입력에서도 예전 결과를 재사용할 수 있는가 |
| 재사용 증거와 현재 입력의 연결이 맞는다 | 해당 검증 범위에서 결과를 재사용할 조건이 맞는다 | 언어 전체가 완성됐거나 제품 효용이 입증됐는가 |
예를 들어 테스트 선택식이 잘못되면, 테스트 하나를 빠뜨리고도 명령은 성공할 수 있습니다. 따라서 요청한 테스트 개수를 실제 실행 개수로 기록해서는 안 됩니다.
기존 예제의 .gooo 선언에는 주문과 재고의 역할, 테스트 이름, 의존 관계가 들어 있습니다. 생성된 Go 프로젝트는 TestOrdersPartition과 TestInventoryPartition으로 관측합니다.
-
.gooo선언에서 테스트할 역할과 이름을 읽습니다. - 선언을 의미 IR로 낮추고 Go 코드를 생성합니다.
- 각 역할에 연결된 정확한 테스트 명령을 실행합니다.
- 실제 테스트 출력에서 이름별 실행과 성공, 패키지 성공을 확인합니다.
- 실행 명령과 결과를 해당 파티션의 증거에 연결합니다.
- 선택 실행에서는 영향받은 파티션을 실행하고, 조건이 맞는 나머지 증거만 재사용합니다.
현재 예제에서 확인하는 경로는 다음과 같습니다.
| 경로 | 실행한 테스트 | 재사용한 테스트 |
|---|---|---|
| 전체 기준 실행 | 2 | 0 |
| 변경 없는 선택 실행 | 0 | 2 |
| 주문 파티션을 변경한 선택 실행 | 1 | 1 |
이 표는 해당 예제의 기준 실행과 선택 실행을 설명합니다. 서로 다른 릴리스 사이의 재사용을 모두 검증했다는 뜻도, 실행 시간이 그 비율만큼 줄었다는 뜻도 아닙니다.
재사용 증거에는 선언과 의미, 생성물, 테스트 계약, 명령, 의존 관계, 도구 식별자, 원래 실행 결과의 식별자가 연결됩니다. 새 실행은 이 연결을 비교해야 합니다.
병합된 파티션 실행 경로는 CI 로그에도 실제 명령, 원본 테스트 JSON, 표준 오류, 결과 digest를 남깁니다. 사람은 테스트 이름을 읽을 수 있고, 도구는 발급된 증거와 실제 프로세스 결과를 대조할 수 있습니다.
digest는 같은 바이트인지 확인하는 수단입니다. 그 자체가 서명이나 실행 이력의 독립적인 인증은 아닙니다. 선언된 도구 식별자만으로 실제 바이너리와 모든 전이 의존성까지 검증했다고 해석해서도 안 됩니다.
Gooo의 테스트 선택과, 그 안에서 호출하는 Go 도구의 캐시는 서로 다른 층입니다.
| 층 | 판단하는 대상 | 관측과 권한의 경계 |
|---|---|---|
| Gooo 파티션 증거 재사용 | 선언된 역할·테스트·입력에 이전 증거를 적용할 수 있는가 | 위의 주문·재고 예제처럼 명시된 계약과 실제 테스트 이벤트로 판단합니다. |
| Go 검증 프로세스의 캐시 | Go 도구가 이번 go test ./... 호출의 결과를 재사용했는가 |
네이티브 출력의 (cached) 표시는 관측입니다. Gooo에 검사 생략이나 변경 채택 권한을 주지 않습니다. |
현재 코드 변환 경로의 SplitGoDeclarations와 CollapseAssignReturn은 변환된 Go 프로젝트에 검증 프로세스를 호출합니다. 읽는 순서는 다음과 같습니다.
Gooo activity + source/semantic identity
-> transformed Go workspace
-> go test ./...
-> process result + activity-bound observation
-> conformance receipt
-> scoped acceptance decision
프로세스 결과는 어느 Gooo 연산의 어느 실행에서 나온 것인지와 함께 읽어야 합니다. 종료 코드, 출력, receipt를 서로 다른 실행에서 가져와 하나의 성공으로 조립하면 안 됩니다. receipt가 적합하다는 사실 역시 저장소 병합이나 릴리스 권한을 대신하지 않습니다.
병합된 검증 실행기는 위 두 연산 각각의 첫 실행과 재실행에 연산이 소유한 동일한 임시 경로를 사용합니다. 매번 이전 내용을 제거하고 원래 입력을 새로 복원하며, Git 입력 스냅샷도 새로 만듭니다. 서로 다른 연산은 별도의 작업 공간을 가집니다.
이 구분은 중요합니다. 재실행에 필요한 경로 안정성은 유지하되, 첫 실행이 남긴 변경이나 파일이 두 번째 실행의 입력이 되는 일을 막습니다. 경로가 같다고 입력이 같거나 캐시 재사용이 안전하다고 선언하는 것은 아닙니다. 네이티브 캐시 판정은 여전히 Go 도구가 수행합니다.
구현은 호출자가 명시적으로 선택한 설정을 보존하면서 Go 캐시 진단을 요청합니다. 정상 첫 실행, 캐시가 사용되는 재실행, 소스를 바꿔 실패해야 하는 실행을 구분하는 회귀 사례도 유지합니다. 이 동작의 근거는 병합된 실행기 변경과 소스에 연결된 CI 실행 기록입니다. 공개 릴리스 포함 여부와는 별개입니다.
위 실행 기록의 두 연산은 각각 첫 실행과 재실행을 완료했습니다.
| Gooo 연산 | 첫 실행의 패키지 요약 행 / 캐시 표시 행 | 재실행의 패키지 요약 행 / 캐시 표시 행 |
|---|---|---|
SplitGoDeclarations |
386 / 0 | 386 / 143 |
CollapseAssignReturn |
386 / 0 | 386 / 143 |
네 검증 프로세스는 모두 종료 코드 0을 반환했고, 두 연산의 receipt는 CONFORMANT였습니다. 386은 테스트 케이스 수가 아니며, 143도 생략을 승인한 테스트 수가 아닙니다. 이 실행에서 파서가 읽은 패키지 요약 행과 그중 캐시 표시가 있는 행입니다. 서로 다른 실행의 동일한 행 수만으로 동일한 검사 범위나 안전한 재사용을 증명하지 않습니다.
이 표는 특정 입력과 도구 버전의 실행 관측입니다. 모든 프로그램에서 캐시가 적중하거나 실행이 빨라진다는 보장은 아닙니다.
실행 시간이 길다는 사실과 그 원인을 구분합니다. 다음 순서로 기존 근거를 좁혀 읽으면 됩니다.
- 기다림과 실행을 구분합니다. Actions 대기 시간, 작업 전체 시간, 실제 검증 프로세스 시간을 섞지 않습니다.
- 느린 연산을 찾습니다. Gooo 연산 ID와 첫 실행·재실행 구분을 따라 실제 프로세스의 시작과 반환을 확인합니다.
- 포함 관계를 확인합니다. 입력 준비 단계 안에 검증 프로세스가 있다면, 준비 시간과 그 안의 프로세스 시간을 더해 총비용으로 만들지 않습니다.
- 관측 범위를 확인합니다. 출력이 잘렸다면 읽지 못한 부분은 미관측입니다. 캐시 표시가 보이지 않았다는 이유만으로 전체 실행에서 캐시가 없었다고 결론 내리지 않습니다.
-
같은 조건의 전후 실행을 비교합니다. 사례, 입력·계약·도구 식별자와 측정 범위가 맞는 전후 쌍이 없으면 성능 개선은
UNKNOWN으로 둡니다.
메모리 사용량도 직접 측정한 값과 단위, 측정 대상을 함께 제시해야 합니다. 출력 크기나 캐시 표시 수로 메모리 절감을 추정하지 않습니다. 시간을 더 정확히 설명하게 된 것은 관측 개선이며, 시간이 실제로 줄었다는 주장은 별도의 근거가 필요합니다.
모르는 것과 반증된 것을 구분합니다.
- 필요한 증거나 의존 관계가 없으면
UNKNOWN입니다. 다음에 무엇을 확보해야 하는지 남깁니다. - 알려진 모순이나 변조가 있으면
REFUTED입니다. 모순을 단순한 자료 부족으로 바꾸지 않습니다. - 정해진 범위의 조건이 충족되면
CLOSED입니다. 모든 미래 입력에 대한 보증은 아닙니다.
UNKNOWN의 여섯 필드는 사람이 작업을 이어받기 위한 안내이기도 합니다.
| 필드 | 읽는 방법 |
|---|---|
stage |
어느 처리 단계에서 멈췄는가 |
step |
그 단계의 어느 연산인가 |
reason |
무엇 때문에 판정하지 못했는가 |
unknown_class |
누락, 오래된 증거, 모호함 등 어떤 종류인가 |
next_operation |
다음에 수행할 명시적인 연산은 무엇인가 |
blocked_by |
먼저 해결해야 할 의존 대상은 무엇인가 |
실행되지 않았거나 생략된 테스트에는 성공 증거를 발급하지 않습니다. 중복된 성공 이벤트, 예상 밖 테스트, 불완전하거나 깨진 출력도 성공 개수에 더하지 않습니다.
원래 주장을 지우기보다는 주장, 근거, 판정의 연결을 남깁니다. 그래야 어떤 입력과 기준에서 채택했으며, 이후 무엇이 바뀌어 재검증이 필요해졌는지 추적할 수 있습니다.
이것이 개발 작업 자체의 provenance이기도 합니다. 결함 관측, 수정, 검증, 채택은 서로 다른 사건입니다. PR이 생성됐다는 사실을 수정 완료로, CI 일부가 성공했다는 사실을 병합 완료로 대신하지 않습니다.
목표를 고정한 후보 선택과 다음 실행의 관계는 고정된 목표에 따른 선택에서 이어집니다.
2026년 9월 14일 확인한 PR #838의 실행 증거에서는 테스트 실행 기록 5개와 기준 실행 증거 4개의 명령·결과 연결을 확인했습니다. 두 기준 실행 모두 주문과 재고 테스트가 실제로 실행됐습니다. 기존 부분 재사용 및 후속 해상도 복구 사례는 각각 정상 2개, UNKNOWN 2개, REFUTED 2개의 구성을 유지했습니다.
관측한 시간과 메모리는 품질 점수가 아닙니다. 현재 비교 모드는 동등하다고 선언되지 않았으므로 시간 개선 판정은 UNKNOWN입니다. 과거의 잘못된 실행 개수 역시 성능 개선의 기준으로 사용하지 않습니다.
이 파티션 실행 수정은 #838로 개발 브랜치에 병합됐습니다. 병합 커밋은 b80c7d55a69a783fd1635ead49855009c51f5fd8입니다. 위의 실행기 수정은 #847, 병합 커밋 51d476388325f43e03346e67aeab6060b2a654a2에 해당합니다. 개발 브랜치의 병합과 공개 릴리스 포함 여부는 구분합니다.
또 하나의 남은 경계는 상위 보고서의 성공 주장과 실제 승인 증거의 차이입니다. #839에 기록한 문제를 고치는 #841은 원본 증거를 독립적으로 재구성하는 후보 구현이지만, 2026년 9월 14일 확인 시 미병합입니다. 보호된 워크플로 변경의 권한 문제가 남아 있으므로 일부 검증 성공을 채택으로 해석하지 않습니다. 후보 구현, 개발 브랜치에서 사용 가능한 기능, 공개 릴리스를 구분해야 합니다.