업데이트: 2026-10-09 KST. PR 1384를 필수 CI 확인 후 개발 브랜치에 병합했고, 공개 0.6.12 실행 파일에 포함했습니다. 정수 계산식 탐색과 지역 거절 후 이어가기는 공개 0.6.13에 포함했습니다. 조건식·대입식의 여러 빈칸을 함께 고르는 경로는 공개 0.6.14에서 사용할 수 있습니다.

0.6.12 후보 사용법과 로컬 배포 회귀 기록도 공개했습니다. 네 플랫폼 후보에서 새 명령을 실행·재실행했고 실제 값이 같았습니다. 배포 준비 PR 1385도 병합했고 공개 파일을 설치해 다시 사용했습니다. 기본 브랜치 반영 상태는 현재 상태에 기록합니다.

함수 하나의 예제가 너무 적으면 서로 다른 구현이 같은 점수를 받을 수 있습니다. 예를 들어 0을 넣으면 0이라는 조건은 그대로 반환과 두 배로 반환이 모두 맞힙니다. 그 함수를 가져다 쓴 프로그램이 3을 넣으면 6을 기대하면 차이가 드러납니다.

body-construct는 이때 전체 프로그램의 결과를 보고 다른 조합을 시도합니다. 부품별 검사도 매번 함께 남깁니다. 아래 함수가 바뀌면 그것을 호출하는 함수의 기존 검사 결과를 다시 계산합니다.

flowchart TD
    A["기본 코드·선택지·기대값"] --> B["살펴볼 순서 결정<br/>모델 또는 고정 순서"]
    B --> C["함수 조합을 만들고<br/>부품별 검사"]
    C --> D["전체 프로그램을 컴파일·실행"]
    D -->|실행 성공| E{"부품과 전체의<br/>기대값을 충족하나?"}
    D -->|실행 오류| H["오류와 시도 기록 저장"]
    E -->|예| F["선택한 코드와 결과 저장"]
    E -->|아니오·시도 가능| C
    E -->|후보 또는 횟수 소진| G["부분 결과와 미해결 항목 저장"]

두 부품을 함께 바꿔야 결과가 좋아지는 경우도 있습니다. 하나를 바꾸고 점수가 오르지 않았다고 바로 끝내면 이런 조합을 놓칩니다. 지금 구현은 허용된 조합을 정해진 한도까지 살펴봅니다. 서로 모순된 기대값은 미해결 상태로 남습니다.

계산 두 개와 조건 하나를 선택하는 프로그램을 준비했습니다. 소스와 검사 입력을 먼저 커밋하고, 기존 자체 그래프 모델을 재학습 없이 연결했습니다.

실행 검사는 모두 일곱 사례를 사용했습니다. 고정 순서의 여덟 번째 조합과 모델의 첫 조합은 같은 Gooo 코드였고 실제 출력도 같았습니다. 한 프로그램을 두 방식과 네 한도로 실행한 여덟 번의 관측입니다. 일곱 평가 입력 중 하나는 조립에도 썼고, 0은 부품의 예제에도 들어 있습니다.

이 경로에서 모델은 처음에 순서를 제안합니다. 이후 실패는 저장된 순서에서 다음 조합으로 넘어가게 합니다. 네 번의 모델 판단은 약 42~46µs였고, 전체 조립에는 컴파일·실행 시간이 추가됩니다. 호스트 CPU 사용률은 측정하지 않았습니다. 임시 모델 파일을 지운 뒤에도 저장한 조립과 일곱 출력이 새 추론 없이 재현됐습니다.

공개 0.6.12 또는 해당 개발 소스에서 실행합니다. --construction-cases는 조립에 사용하는 입력, --cases는 선택 뒤에 실행할 입력입니다. 두 집합에 겹치는 입력이 있으면 결과에 표시합니다.

go run ./cmd/gooo body-construct \
  --source examples/caller-guided-construction/main.gooo.fixture --entry Main \
  --construction-cases examples/caller-guided-construction/construction-cases.json \
  --cases examples/caller-guided-construction/evaluation-cases.json \
  --attempts 2 --out /tmp/my-caller-construction

새 출력 폴더를 지정합니다. 첫 조합은 3을, 다음 조합은 6을 반환합니다. 저장한 기록을 다시 실행하면 당시 시도한 조합도 모두 재검사합니다. 선택이 끝난 일반 Gooo 소스와 생성된 Go 파일도 남깁니다.

현재 범위는 한 구성 안의 조립 본문 최대 16개와 전체 조립 최대 64회입니다. 공개 0.6.14에서 레코드 선택, 정수 IR 탐색과 여러 홀의 source_fill을 함께 연결합니다. 패키지를 가로지르는 조립은 PR 1402에서 구현했고 필수 CI를 거쳐 개발 브랜치에 병합했습니다. 작업장에서도 Gooo 규칙으로 실패 사례 반영과 다음 시도를 연결했습니다. 패키지 조립 사용법.

예산 함수라면 조건 하나만 맞아도 부족할 수 있습니다. 상한에 도달했는지 확인하는 조건과, 그때 남길 값을 함께 맞춰야 합니다. source_fill은 이 둘을 한 후보 묶음으로 선언하고 코드에 채웁니다. 이번 변경은 그 후보를 실제 호출 결과로 다시 고르게 합니다.

처음의 사용량 0, 상한 8 → 다음 1 예제는 세 후보가 모두 통과했습니다. 사용량 8, 상한 8 → 상한 8에서 멈추기라는 호출 사례를 추가하면 차이가 드러납니다. 두 번 시도한 결과는 부분 완성으로 남았고, 세 번째 후보에서 조건을 맞췄습니다. 선택 후 별도로 실행한 네 입력도 통과했습니다. 큰 정수는 2^53을 넘어도 그대로 비교합니다.

기존 소형 모델을 붙인 혼합 예제도 실행했습니다. 모델은 레코드 선택 순서를 한 번 제안했고, 빈칸 묶음은 소스 순서로 골랐습니다. 고정 순서 24번과 모델 순서 3번이 같은 코드를 만들었고 별도 평가는 둘 다 4/4였습니다. 서로 관련된 두 프로그램의 관측이며, 모델을 추가 학습하지 않았습니다.

자동 루프에서는 Gooo가 틀린 호출 사례 한 개를 다음 조립에 추가했습니다. 한도 1 → 1 → 2 → 4로 네 회차를 진행했고 실제 시도는 총 7번입니다. 마지막 평가는 선택을 마친 뒤 4/4, 새 모델 호출은 0회였습니다. 모든 기대값과 부분 결과를 남깁니다. 소스의 별도 평가도 따로 기록하며 선택 점수에 더하지 않습니다. COMPLETE_FINITE는 공급한 지역 학습·호출 사례가 맞았다는 뜻입니다.

선택한 selected.gooo는 보통의 Gooo 소스입니다. 이번 두 소스를 기존 공개 0.6.13의 body-compose로 실행해도 같은 네 결과가 나왔고, 모델 호출은 0회였습니다. 다음 입력을 처리할 때는 이 소스를 가져다 쓸 수 있습니다.

실행 명령 · 원본과 자체 모델 측정 · 개발·병합 상태.

필수 CI 후 dev 934aed80에 병합한 PR 1387에서는 함수 안에 남겨 둔 계산식도 전체 결과를 보고 다시 고릅니다. 예를 들어 함수의 0 → 0 사례만 보면 input과 0이 모두 맞습니다. 호출자가 실행한 결과가 틀리면 그 차이를 근거로 다른 계산식을 넣습니다. 함수에 적힌 기대값은 보존합니다.

정수 계산식과 세 개의 레코드 선택을 섞은 예제에서 기본 순서는 16번, 기존 자체 모델을 연결한 순서는 9번의 프로그램 시도가 필요했습니다. 두 결과의 Gooo 소스가 같고, 별도 평가 4/4와 저장 재실행도 같았습니다. 모델은 레코드 순서를 한 번 제안했고 계산식은 소스의 문법에서 정해진 순서로 살폈습니다. 가중치는 그대로입니다.

작업장 PR 33에서는 이 새 기록을 Gooo 진단과 자동 반례 반영에 연결했습니다. 같은 혼합 예제를 약한 호출자 조건 하나로 시작하자 두 실패 사례가 자동으로 추가됐습니다. 6회차·25번의 프로그램 시도 뒤 마지막 별도 평가 4/4를 맞혔습니다. 반복한 조합도 시도 수에 셉니다.

이 기능은 공개 0.6.13에 포함했습니다. 아래 링크는 처음 관측한 개발 소스입니다. 예제·실행 명령 · 직접 조립과 원본 기록 · 자동 반복 원본.

후보 중간에 0으로 나누기가 나오면 이전 구현은 전체 조립을 중단했습니다. 필수 CI 후 dev de253a03에 병합한 개발 소스는 지역 계산식의 타입 검사나 순수 평가가 실패한 이유를 남기고 다음 후보를 살펴봅니다. 거절된 조합도 시도 횟수에 포함합니다. 컴파일한 프로그램의 실행 오류, 실행 도구 오류와 취소는 계속 중단 사유입니다.

작은 예제는 input을 시도한 뒤 0을 거절하고, -input을 선택합니다. 세 번의 조합 중 두 프로그램을 실제 실행해 마지막 평가 4/4를 맞혔습니다. 한도를 두 번으로 줄이면 첫 프로그램과 부분 결과 1/4가 남습니다. 그 결과도 원본에 보존했습니다.

레코드 선택을 섞은 예제는 기본 순서에서 24번, 기존 자체 모델 순서에서 17번의 조합을 시도했습니다. 두 경로 모두 8번은 지역 검사에서 거절됐고, 실제 프로그램 실행은 16번과 9번입니다. 최종 Gooo 소스와 마지막 평가 4/4가 같았습니다. 한 프로그램의 두 순서 비교이며 모델 가중치는 바꾸지 않았습니다.

거절을 포함한 기록은 joint-construction/v3입니다. 실행 전 거절에는 호출부 점수가 없습니다. 저장 재실행에서 거절된 계산식과 이유를 다시 검사하고 새 추론 없이 선택한 프로그램을 실행합니다. 컴파일러 원본.

작업장 PR 34의 Gooo 피드백 반복에서도 이를 연결했습니다. 원래 기대값을 유지하고 실패 사례 두 개를 다음 조립에 추가해, 7회차·49번의 전체 시도 후 별도 평가 4/4를 맞혔습니다. CI에서도 새로 실행했고 로컬과 최종 코드가 같았습니다. 자동 반복 원본과 범위.

생태계 작업장에 workbench construct를 추가했습니다. 부품 검사·전체 호출 검사·별도 평가를 읽고, Gooo 코드가 다음 행동과 시도 한도를 계산합니다. 후보가 남으면 한도를 늘려 자동으로 다시 조립합니다. 한도 확대는 처음부터 실행하므로, 1·2·4·8회 한도를 사용한 기록은 총 15번의 프로그램 시도로 셉니다.

같은 예제에 자체 모델을 붙이면 한 회차·한 번의 조립으로 일곱 평가 출력을 맞혔습니다. 로컬 후보, CI, 공개 실행 파일에서 같은 최종 Gooo 코드가 나왔습니다. 아직 선택지나 기대값을 자동 수정하지는 않으며, 그런 조치가 필요하면 이유를 남깁니다. 소스와 명령 · 실제 실행과 재집계.

새 개발 소스는 source_fill의 후보를 먼저 확인하고, 타입이나 조립 사례 평가에서 실패한 후보를 따로 보관합니다. 나머지 후보로 조립을 계속할 수 있습니다. candidate_scores에는 점수를 계산한 후보만, rejected_candidates에는 실패 이유와 채우려던 식을 기록합니다. 전체 조립에서는 탈락한 조합도 시도 한도에 포함됩니다. 그 조합의 실행 결과나 정답률을 만들어 넣지 않습니다.

다섯 후보 예제에서 한도 3은 시도 3·탈락 2·실행 1로 별도 평가 1/4를 남겼고, 한도 5는 시도 5·탈락 2·실행 3으로 4/4를 만족했습니다. 기록의 실패 이유나 점수를 바꾸면 컴파일러 재실행 검증이 이를 거부합니다. 새 기록은 v5이고, 탈락이 없던 이전 v4 기록도 재사용할 수 있습니다. 별도 holdout 평가와 native 실행 자체의 실패는 여전히 중단 사유이며, 후보 선택 점수로 바꾸지 않습니다.

구현 PR · 고정 실험과 원본. 공개 0.6.14 바이너리보다 새 개발 소스를 사용한 결과입니다.

CI를 통과해 병합한 작업장 PR 32에서는 평가에 실패한 사례를 Gooo 규칙이 골라 다음 조립에 반영합니다. 입력과 기대값 전체를 복사하고, 원본과 추가한 행의 출처를 남깁니다. 중복은 한 번만 추가하며 모순된 기대값은 둘 다 보존합니다. 회차나 사례 수의 상한에 닿으면 결과와 이유를 저장합니다.

반복에 쓰는 --evaluation-cases는 선택에 영향을 줍니다. 마지막에 별도로 확인할 예제는 --holdout-cases로 전달합니다. 마지막 파일은 선택이 끝나야 컴파일러에 전달되며, 저장한 조립을 새 추론 없이 재실행합니다.

요금 계산에서는 모델이 잘못된 조합을 먼저 골랐습니다. 실패 사례 네 개를 다음 조건에 반영하고 시도 한도를 늘려 같은 최종 코드에 도달했습니다. 두 프로그램, 네 실행에서 관측한 결과입니다. 모델의 가중치와 원래 기대값은 그대로 사용했습니다. 마지막 평가의 네 입력은 각 실행의 조립 입력과 겹치지 않았고, 큰 정수도 정확히 비교했습니다. 입력이 다르다는 사실만으로 학습 자료와의 독립성을 주장하지 않습니다.

구현·사용법 · 실행 시간·실패·원본과 재집계.

소스와 사용법 · 고정 계획·원본 결과·Go 재집계 · 처음 발견한 실패 · 언어 발전 방향