2026-10-03 안내: 아래 예제와 관측은 각 절에 고정된 소스·도구체인을 기준으로 읽습니다. 최신 바디 생성과 자체 소형 모델의 흐름은 모델과 메타프로그래밍, 지금 사용할 버전은 현재 상태와 시작하기에 정리했습니다.

Gooo에서 수정 조건을 선언하면 Go 코드 후보를 만들 수 있습니다. 그런데 그 후보를 누가 표준 형식으로 바꾸고, 무엇을 검증하며, 언제 실제 소스에 반영해야 할까요?

이 문서는 후보 생성과 형식 변환을 Gooo의 두 활동으로 연결하는 방법을 설명합니다. 연결했다고 해서 검증이나 적용 권한까지 생기지는 않습니다.

설명 기준은 dev에 정상 병합된 #856의 9c6fc36456853e7a8a67ca24eadc63ec9290d5a4, Go 1.27.0입니다. 이 기준이 현재 공개 릴리스에 포함되었다고 가정하지 않습니다. 먼저 수정 프로그램 작성하기를 읽으면 개별 활동을 이해하기 쉽습니다.

프로그램이 파일을 생성한 뒤 결과를 화면에 쓰려는데, 출력 대상이 닫혀 있을 수 있습니다. 파일 생성은 끝났지만 결과 전달은 실패한 것입니다. 이때 무조건 성공을 반환하면 호출자는 두 상황을 구분할 수 없습니다.

이 사례에서는 이미 존재하는 JSON 출력 경로의 오류 처리를 명시적으로 선택하여, 오류를 버리던 사람용 출력 경로에 재사용합니다. Gooo가 새 오류 처리 정책을 추측하는 것이 아닙니다.

그 다음에는 생성된 Go 코드를 표준 형식으로 바꿉니다. 기존 Go 도구의 역할을 다시 구현하는 대신, 어떤 후보를 어떤 도구 선택으로 변환했는지를 활동과 결과의 연결로 남깁니다.

Source                RawCandidate                 Candidate
원본 Go 바이트         생성 직후 Go 후보              표준 형식의 Go 후보
       -- GuardWrite -->          -- Canonicalize -->

여기까지: 후보 생성
그 이후: 독립 검증 -> 별도의 채택 결정 -> 실제 반영 -> 다음 실행

앞의 두 화살표만 이 합성 프로그램에 속합니다. 뒤의 검증과 채택까지 자동으로 실행하는 범용 작업 엔진은 아닙니다.

아래는 설명용 템플릿입니다. SOURCE_HEX와 HANDLER_HEX는 실제 값이 아니므로 그대로 실행할 수 없습니다. 선택한 원본 Go 파일 전체와 기존 오류 처리 블록의 정확한 바이트에서 각각 얻은 SHA-256 값으로 채워야 합니다. 블록의 중괄호와 공백도 식별 대상입니다.

package goerrorguard
namespace goerrorguard
entity Source id "gooo://error-guard/source"
entity RawCandidate id "gooo://error-guard/raw-candidate"
entity Candidate id "gooo://error-guard/candidate"
activity GuardWrite(Source) -> RawCandidate computes "go-error-guard:v2;function=runMetaPolicyGenerationProfile;writer=stdout;writer-type=interfaceWriter;source=sha256:SOURCE_HEX;handler=sha256:HANDLER_HEX"
activity Canonicalize(RawCandidate) -> Candidate computes "go-source-format:v1;toolchain=go1.27.0"

중간 결과를 별도 개체로 선언하면 두 활동 사이의 의존 관계가 의미 그래프에 남습니다. 결과가 달라졌을 때 생성 단계와 형식 변환 단계를 나누어 추적할 수 있습니다.

computes 값은 이 실험적 어댑터가 지원하는 선택 프로파일입니다. 새로운 범용 정책 문법이나 임의의 작업을 실행할 수 있다는 선언은 아닙니다. 이 버전의 합성은 정확히 세 개체와 두 활동을 대상으로 합니다.

다음은 해당 소스 버전의 예제 어댑터 사용 형식입니다. 입력 파일과 출력 디렉터리는 호출자가 준비합니다. 이 문서 작성 과정에서는 이 명령을 로컬에서 실행하지 않았습니다.

go run ./examples/meta-policy-compilation/go-error-guard \
  -pipeline \
  -program /caller/input/canonical-guard.gooo \
  -source /caller/input/original.go \
  > /caller/output/pipeline-proposal.json

-pipeline은 생략 가능한 장식이 아닙니다. 기본 어댑터의 두 개체·한 활동 계약과 구분하여 합성 계약을 선택합니다. 어댑터는 JSON을 표준 출력에 내보내며 입력 프로젝트를 수정하거나 후보를 실행하지 않습니다. 위 출력 파일은 호출자의 셸 리다이렉션으로 만들어집니다.

이 생성 결과는 PROPOSED이며 독립 검증 판정은 UNKNOWN, 수정·승격 권한은 0입니다. 이후 CI에서 얻은 관측은 별도 근거로 연결합니다. 생성 시점의 기록을 나중에 이미 검증된 기록이었던 것처럼 바꾸지 않습니다.

이 버전은 기존 v1 또는 v2 오류 처리 규칙을 명시적으로 선택합니다. 위 템플릿은 v2입니다. 대상 함수와 지역 출력 인터페이스, 반환만 하는 오류 처리 블록, 인접한 출력·반환 구조 등 기존 규칙의 제한을 그대로 따릅니다.

형식 변환은 원본이 이미 표준 형식인 경우를 대상으로 합니다. 관계없는 줄까지 고치면서 성공했다고 판단하지 않도록, 원래 수정 구간 밖의 바이트를 보존해야 합니다.

형식 변환 내부의 세 번의 호출은 원본 형식 확인, 후보 형식화, 결과의 형식 고정점 확인입니다. 세 번의 전체 테스트나 세 번의 의미 검증이 아닙니다.

UNKNOWN에는 stage, step, reason, unknown_class, next_operation, blocked_by가 남습니다. 직접 누락과 의존 대상 때문에 막힌 상태를 한 실패로 뭉개지 않습니다. 앞 활동이 실패하면 형식 변환을 호출하지 않습니다.

설명 기준 컴파일러의 CI 실행은 동일한 고정 검증 조건에서 원본과 표준 형식 후보를 각각 실행했습니다. 다음 다섯 항목은 이 사례의 고정된 분모이지 언어 전체의 완성도 지표가 아닙니다.

관측은 4개 성공·1개 실패에서 5개 성공·0개 실패입니다. 이 검증은 공용 생성 프로파일을 대상으로 하며 정책 수정 프로파일 전체의 실행 증거로 확대하지 않습니다. 입력 Gooo와 생성 파일, 활성 테스트 소스의 경계도 함께 고정합니다.

이후 투영된 저장소 형태에서도 패키지 검사가 통과했습니다. 그것을 별도로 복구한 또 한 벌의 다섯 개 실행 사건으로 중복 계산하지 않습니다. 전체 CI 시간이나 성능 향상도 이 사례 수에서 추정하지 않습니다.

1. 원본과 후보를 같은 독립 검증 기준으로 비교합니다. 후보가 자신을 통과시키기 위해 기준도 함께 낮춰서는 안 됩니다.
2. 실제 적용 대상이 여전히 맞는지, 기존 수정이나 다른 선언을 덮어쓰지 않는지 구분합니다. 오래된 전체 파일을 그대로 덮어쓰는 것은 안전한 적용이 아닙니다.
3. 권한 있는 채택 경로에서 실제 변경과 전체 CI 검증을 연결합니다. 임시 실행 성공과 영구 반영을 구분합니다.
4. 채택된 결과가 다음 실제 실행에 사용되는지 관측합니다. 이 연결 전에는 누적되는 자기개선이라고 단정하지 않습니다.

공용 두 프로파일의 별도 수정인 #853은 두 원시 제안과 CI 형식 변환을 조합한 이력이 있습니다. 그 이력을 이 새 합성 프로그램이 처음부터 만들었던 것으로 바꾸지 않습니다. 작업 방식이 발전하는 과정 자체도 provenance에 속합니다.

• 문법 오류와 UNKNOWN 읽기: 실패 단계와 다음 작업을 구분합니다.
• 코드 변환과 효과: 후보 생성과 효과 관측을 연결합니다.
• 테스트·실행 비용·증거 재사용: 이미 얻은 증거의 적용 범위를 다룹니다.
• Provenance와 결정: 주장, 관측, 채택을 연결합니다.
• 거버넌스와 기여: 기능의 정의와 변경 권한을 설명합니다.