생성한 수정안을 실제 동작으로 연결하기

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

Gooo의 수정 프로그램은 선택한 입력과 변경 조건에 묶인 수정 후보를 만듭니다. 후보를 만들었다는 사실만으로 원래 문제가 해결되거나, 저장소를 바꿀 권한이 생기지는 않습니다.

이 안내는 수정 프로그램 작성하기와 수정 활동 연결하기 다음 단계입니다. 생성 결과를 검토하는 사람과 다음 작업을 이어받는 에이전트가 같은 근거를 읽는 방법을 설명합니다.

먼저, 사용자가 겪는 문제

코드 생성 명령이 외부 출력 폴더에 파일을 만든 뒤 성공 안내를 출력한다고 생각해 봅시다. 이때 출력 대상이 쓰기를 거절하면 어떻게 되어야 할까요?

파일 생성과 결과 전달은 서로 다른 일입니다.

실제 관측	설명해야 하는 결과
파일을 만들고 안내도 전달했다	두 단계가 모두 성공했다.
파일은 만들었지만 안내를 전달하지 못했다	전달은 실패했다. 이미 만든 파일이 없어진 것은 아니다.
실행 결과를 수집하지 못했다	성공이나 실패를 확정하지 못했다. 필요한 증거를 밝혀야 한다.

Gooo의 실제 공개 프로파일에서는 사람이 읽는 안내의 쓰기 오류를 무시하고 성공 종료를 반환하던 경로를 다뤘습니다. JSON 출력 경로에는 이미 오류 처리가 있었습니다. 수정의 목적은 단순히 오류 코드를 추가하는 것이 아니라 다음 의미를 함께 지키는 것이었습니다.

• 결과 전달 실패를 명령 성공으로 숨기지 않는다.
• 이미 만들어진 외부 파일을 보존한다.
• 원본 Gooo 입력을 바꾸지 않는다.
• 정상적인 사람용 출력과 JSON 출력을 그대로 유지한다.
• 출력 오류 처리를 저장소 변경이나 배포 권한으로 확대하지 않는다.

이 구분은 생성기뿐 아니라, 여러 단계를 수행하는 자동화에서 무엇까지 완료됐는지 설명할 때도 중요합니다. 다만 다른 프로그램에도 같은 수정기가 적용된다는 뜻은 아닙니다. 지원하는 입력 형태와 변경 조건은 각 수정 프로파일의 계약을 따라야 합니다.

Gooo 선언과 생성 코드는 어떻게 이어지는가

이 사례의 출발점은 에이전트가 Go 파일을 임의로 고치는 행위가 아니라, Gooo 선언에 묶인 수정 활동입니다. 선택한 함수, 출력 대상, 기존 오류 처리 경로와 원본 소스의 식별값이 후보 생성의 경계를 정합니다.

Gooo 소스와 의미 IR은 어떤 활동을 수행하는지 설명하고, 원본 Go와 후보 Go의 식별값은 실제로 무엇이 바뀌었는지 연결합니다. 생성 활동과 정규화 활동을 연결할 때에는 원시 후보와 정규화된 후보도 구분합니다.

읽어야 할 근거는 역할이 다릅니다.

근거	답하는 질문
Gooo 소스와 의미 IR	어떤 변경 조건과 활동을 선언했는가?
원본 소스 식별값	지금 수정하려는 입력이 그 입력인가?
원시 후보	수정 활동이 무엇을 제안했는가?
정규화된 후보	이후 검증과 적용의 대상은 정확히 어떤 바이트인가?
독립된 검증 기준	무엇을 지켜야 성공이라고 판단하는가?
해당 커밋의 CI 결과	그 입력과 후보를 실제로 실행했는가?
병합 기록과 다음 실행	무엇을 채택했고, 이후에도 실제로 사용했는가?

해시가 같다는 것은 식별에 도움이 됩니다. 그것만으로 의미가 올바르거나 사용자에게 유용하다는 결론이 나오지는 않습니다.

생성, 검증, 채택, 다음 사용은 다르다

다음 표는 과정을 설명하기 위한 구분입니다. 언어 전체의 완성도를 세는 새로운 점수나 인수 조건의 분모가 아닙니다.

단계	확인한 것	아직 의미하지 않는 것
후보 생성	비교할 수정안이 있다.	문제가 해결됐다.
독립 검증	정해 둔 사례와 보존 조건에서 결과를 관측했다.	모든 프로그램에서 올바르다.
실제 채택	검증한 변경을 프로젝트에 반영했다.	다음 실행도 그것을 사용했다.
다음 사용	반영된 변경이 후속 실행에서 소비됐다.	시스템이 제한 없이 스스로 개선된다.

기각도 검토 과정의 정상적인 종료입니다. 다만 개선 성공으로 세지는 않습니다. 후보가 평가 기준을 낮춰 통과하거나, 검증하지 않은 바이트를 대신 반영했다면 이 연결은 성립하지 않습니다.

검토자는 무엇을 확인하는가

공개 프로파일 사례에서는 생성과 수정 제안이라는 두 경로에 각각 네 가지 출력 사례를 둡니다.

경로	사람용 출력 거절	JSON 출력 거절	사람용 정상 출력	JSON 정상 출력
생성 프로파일	오류 종료, 생성 파일 보존	오류 종료, 생성 파일 보존	기존 출력 유지	기존 출력 유지
수정 제안 프로파일	오류 종료, 생성 파일 보존	오류 종료, 생성 파일 보존	기존 출력 유지	기존 출력 유지

여기서 세부 사례는 정확히 8개입니다. 테스트 묶음과 그 상위 테스트의 성공 행을 더해 사례 수를 늘리지 않습니다. 또한 패키지가 통과했다는 요약과 세부 사례 8개가 각각 실행된 기록은 구분합니다.

검토할 때에는 성공 개수만 보지 않습니다. 출력 오류를 처리하면서 원본 입력, 이미 생성한 파일의 내용, 정상 출력과 권한 경계가 함께 유지되는지 봅니다. 새로운 후보의 평가에는 그 후보와 분리된 기존 기준을 사용합니다.

판정하지 못할 때에는 다음 작업을 남긴다

증거가 없으면 성공으로 간주하지 않습니다. 그렇다고 모든 실패를 UNKNOWN으로 바꿔서도 안 됩니다. 실제로 관측한 모순과 아직 관측하지 못한 상태는 다릅니다.

생성 단계의 후보에 다음과 같은 검증 대기 정보가 붙을 수 있습니다.

{
  "state": "UNKNOWN",
  "stage": "INDEPENDENT_VALIDATION",
  "step": "OBSERVE_GO_GUARD_CANDIDATE",
  "reason": "NATIVE_GO_GUARD_EVIDENCE_MISSING",
  "unknown_class": "DIRECT_MISSING",
  "next_operation": "RUN_FROZEN_NATIVE_ORACLE",
  "blocked_by": []
}

이 레코드는 후보가 틀렸다고 단정하지 않습니다. 어느 단계의 증거가 없고 다음에 무엇을 관측해야 하는지 말합니다. 후속 증거가 생기면 원래 생성 기록을 성공으로 덮어쓰기보다, 그 후보를 평가한 별도의 실행 기록으로 연결합니다.

기존 입력과 후보의 식별값이 맞지 않거나 알려진 반례가 있다면, 누락 증거와 섞어 숨기지 않습니다. 지원하지 않는 형태를 추측으로 고치는 것도 별개의 문제입니다.

적용할 때 지키는 책임의 경계

수정안을 만드는 활동, 검증하는 활동, 실제로 반영하는 작업은 구분합니다. 생성된 후보가 자기 자신에게 변경 권한을 부여하지 않습니다.

프로젝트의 현재 변경 범위와 승인 경로도 충족해야 합니다. 프로그램 테스트가 성공해도 등록되지 않은 작업 경로나 보호 대상 파일의 승인 부재를 대신 해결해 주지는 않습니다. 반대로 이런 승인 실패를 프로그램의 의미론적 결함으로 잘못 설명해서도 안 됩니다.

검증 대상의 기반이 바뀌면 기존 결과가 무엇을 검증했는지 다시 구분해야 합니다. 재사용 가능한 범위는 입력, 도구, 검사 범위와 증거의 결합으로 정해야 하며, 단순한 캐시 적중 표시는 적용 권한이 아닙니다.

실제 사례의 발자취

아래는 고정된 실행 기록입니다. 최신 진행 상태는 연결된 PR과 이슈에서 확인할 수 있습니다.

• #853은 두 공개 프로파일의 생성된 오류 처리를 dev에 반영했습니다.
• 승인된 커밋은 b144bb5615f412edabf93d80d3e8f83574c5fe2c입니다.
• 후속 실행 34845880834에서는 반영된 소스와 독립 검증 파일의 식별값을 입력에 묶고, 세부 사례 8개의 PASS 이벤트를 각각 관측했습니다.
• 근거 기록은 이 관측과 후속 PR의 최종 승인 여부를 분리합니다. 이 문서 작성 시점의 #852는 기존 인수 조건 4개 중 3개가 완료된 상태입니다.
• 실행 시간이나 메모리 관측값은 같은 비교 조건의 전후 쌍이 없으면 성능 개선 주장으로 바꾸지 않습니다. 외부 사용자 효용도 별도 증거가 필요합니다.

처음 읽는 사람은 무엇이 달라졌고 무엇을 보존했는지부터 보면 됩니다. 검토자는 입력과 검증 기준, 적용된 바이트의 연결을 따라가면 됩니다. 더 깊이 확인할 때에는 실행 식별값과 원본 증거까지 내려갈 수 있습니다.

작은 자기개선의 가치는 보고서가 하나 더 생기는 데 있지 않습니다. 선언한 변경이 실제 동작에 반영되고, 그 결과를 다음 실행이 사용할 수 있도록 근거와 경계가 남는 데 있습니다.