여러 입력을 받아 실제 본문에 연결하기

업데이트: 2026-10-04. 개발 #1221· main #1222로 병합·설치한 입력 연결 기능과 실제 관측을 설명합니다. 아래 명령의 소스는 1bef47fc1e7a4aca8ffb1cbd5a5aa7ded2353ce5입니다. 설치된 버전은 현재 상태에서 확인합니다.

입력은 번호가 붙은 소켓입니다

활동을 작은 작업대에 비유하면, 입력은 부품을 받는 소켓이고 bind는 값을 전달하는 연결선입니다. 소켓 두 개가 같은 Integer 타입이어도 서로 다른 자리를 차지합니다. 소스에 적은 순서가 생성한 함수의 인자 순서까지 이어집니다.

activity Add(Integer, Integer) -> Integer computes "return input0 + input1"
activity Difference(Integer, Integer) -> Integer computes "return input0 - input1"
bind Left.result -> Add.input0
bind Right.result -> Add.input1
bind Right.result -> Difference.input0
bind Left.result -> Difference.input1

이 경우 Difference는 Right에서 Left를 뺍니다. 두 연결을 바꾸면 의미도 바뀝니다. 동일 타입을 하나의 PROV used 사실로 정리하더라도, 선언의 입력 위치는 별도로 보존하여 같은 타입 두 개의 순서를 유지합니다.

선언	본문에서 읽는 이름	외부 입력 키
Root(Integer)	input	Root
Compare(Text, Text)	input0, input1	Compare.input0, Compare.input1
Label(Integer, Boolean, Text)	input0, input1, input2	연결하지 않은 위치의 Label.inputN

현재 순수 계산 본문은 Integer·Boolean·Text 입력 1~16개와 출력 1개를 지원합니다. 입력은 읽기 전용이며 let으로 만든 지역 변수에는 다시 값을 할당할 수 있습니다. 입력 하나는 input, 여러 입력은 input0부터 사용합니다. input01과 같은 다른 표기나 선언 범위를 벗어난 번호는 오류로 안내합니다.

일부 위치만 연결할 수 있습니다

activity Label(Integer, Boolean, Text) -> Text computes "if input1 && input0 > 0 { return input2 + \"!\" }; return input2"
bind Add.result -> Label.input0

Label.input0은 Add의 실제 결과를 받습니다. 호출자는 Label.input1과 Label.input2만 제공합니다. 연결한 위치를 외부 값으로 덮어쓰지 않습니다. 각 입력 위치에는 생산자 하나를 연결할 수 있습니다.

{
  "schema": "gooo/body-composition-cases/v1",
  "cases": [{"inputs": {
    "Left": -8,
    "Right": 6,
    "Label.input1": true,
    "Label.input2": "gooo",
    "Compare.input0": "같음",
    "Compare.input1": "같음"
  },
  "expected": {"Add": 27, "Difference": -3, "Label": "gooo!"}}]
}

전체 파일 형식과 정확한 일곱 활동의 기대값은 실행 사례를 그대로 받아 시작할 수 있습니다. 위 JSON은 기대값 세 개를 제공하는 한 사례입니다.

한 명령으로 조립하고 실행하기

시작하기에서 소스를 받은 새 예제 체크아웃의 루트에서 아래 리비전을 선택하고 빌드합니다. 기존 작업 파일이 있는 체크아웃에서는 그 변경을 보존합니다.

git fetch origin
git switch --detach 1bef47fc1e7a4aca8ffb1cbd5a5aa7ded2353ce5
gooo_go_bin="$(GOTOOLCHAIN=go1.27.1 go env GOROOT)/bin/go"
"$gooo_go_bin" build -trimpath -o gooo ./cmd/gooo

이어서 같은 루트에서 실행합니다.

./gooo body-compose \
  --source examples/body-codegen/native-input-joins.gooo.fixture \
  --cases examples/body-codegen/native-input-joins-cases.json \
  --out input-joins-results

기본 경로는 결정론적으로 후보를 확인합니다. 새 출력 폴더에 선택한 Gooo, Go 함수, 연결 드라이버와 결과를 보관하고, 한 번 빌드한 프로그램을 두 번 실행합니다. 저장한 조립 기록은 추가 추론 없이 새 입력에 재사용합니다. body-compose가 담당하는 순수 본문 연결은 등록된 활동 구현을 실행하는 일반 run 명령과 별도의 실행 경로입니다.

출력 폴더에서 다음 파일을 확인할 수 있습니다.

파일	읽을 내용
original.gooo, cases.json	실행에 사용한 원본과 기대값
realized.gooo	선택한 본문을 반영한 다음 개발용 Gooo
generated.go, main.go	생성한 함수와 입력 전달 코드
composition.json	본문 선택과 연결의 저장 기록
runtime.json	실제 결과, 기대값 충족 수, 입력별 전달 값

runtime.json의 traces에는 사례별 deliveries가 있습니다. 각 전달의 inputs는 입력 위치(port), 타입의 식별자(entity_id), 값을 만든 활동 (producer_id), 실제 값(value)을 함께 보관합니다. 연결에서 값이 뒤바뀌었다면 그 위치를 따라가고, 계산이 달랐다면 actual과 expected를 비교할 수 있습니다.

모델을 연결하려면 공개된 자체 모델의 두 파일을 받습니다.

hf download asketeddy/gooo-three-choice-feedback-tiny-v1 \
  models/set-feedback/fp32/model.json models/set-feedback/fp32/weights.bin \
  --revision 24238ca67048b36bc305731799985271bb752dd1 \
  --local-dir gooo-models
./gooo body-compose \
  --source examples/body-codegen/native-input-joins.gooo.fixture \
  --cases examples/body-codegen/native-input-joins-cases.json \
  --model gooo-models/models/set-feedback/fp32/model.json \
  --out input-joins-model-results

사용한 모델은 자체 three-choice FP32 모델입니다. 가중치 크기는 74,624바이트이며 이번 입력 연결 실험에서는 새로 학습하지 않았습니다. 모델은 Left 본문의 세 가지 이진 조립 선택을 제안합니다. Add·Difference·Label· Compare의 본문과 연결 순서는 Gooo 선언을 따릅니다.

완전성은 무엇을 확인했는지와 함께 읽습니다

확인한 것	이번 관측
선택한 Left 본문의 유한 예시	첫 모델 후보 0/6, 다음 후보 6/6
실제 프로그램의 명시된 출력	한 제어에서 49/49
여러 입력이 실제 값으로 도착했는지	한 제어에서 입력 84개·연결 전달 42개
반복 생성과 저장 기록 재실행	12개 제어에서 588/588·입력 1,008개·연결 504개
틀린 기대값 하나를 일부러 넣은 별도 제어	48/49

점수의 분모는 사용자가 제공한 출력 기대값입니다. 기대값을 생략한 중간 값은 관측에는 남고 점수에는 더해지지 않습니다. 입력마다 위치·타입의 식별자·생산자· 실제 값이 기록되어 연결이 어디서 틀렸는지 따라갈 수 있습니다. 위 세 기대값의 JSON도 후속 후보 6b6c86f2에서 자체 모델을 한 번 호출해 실행했고, 두 실제 실행이 일치하며 3/3을 기록했습니다. 588개는 같은 그래프를 반복한 제어의 합계입니다. 독립 과제 수와 일반적인 의도 충족률을 추정할 때는 별도의 과제와 관측이 필요합니다.

개발 후보 5af78bcb의 세 번씩 측정에서 모델은 후보 2개, 결정론적 탐색은 8개를 확인했고 같은 프로그램에 도달했습니다. 전체 그래프 생성 시간의 중앙값은 모델 9.711ms·결정론적 6.396ms였습니다. 빌드와 두 실행을 포함한 전체 명령은 약 301566ms, 관측된 프로세스 최대 RSS는 약 8183MiB였습니다. 고정된 실행 순서와 따뜻한 Go 캐시에서 측정했으며, 컴퓨터 전체 CPU 사용률은 이 측정에 함께 수집하지 않았습니다.

원본·비용·동시 요청·추가 입력 기록을 함께 공개합니다. 측정 후보의 배포 검사에서 준비 함수를 더 작게 나눌 필요가 확인되어 후속 소스 6b6c86f2로 정리했습니다. 개발·main의 각 전체 CI와 독립 증거를 확인해 main 1bef47fc로 병합하고 CLI·실행기를 함께 설치했습니다.

설치본의 별도 관측

같은 열두 제어에서 588/588·입력 1,008개·연결 504개와 동일한 Gooo·Go·연결 코드 지문을 확인했습니다. 모델은 세 번 실제 호출했고 저장 재실행은 추가 추론 0번입니다. 동시 요청은 98/98·정상 종료, 추가 입력은 42/42, 의도적으로 바꾼 기대값은 48/49였습니다. 새 생성 시간 중앙값은 모델 9.449ms·결정론 8.480ms, 전체 명령 중앙값은 316.959ms·312.954ms였습니다. 전체 열두 제어의 최대 RSS 범위는 81.33~83.56MiB입니다. 따뜻한 Go 캐시·고정 순서·각 세 번의 새 측정이며 원인별 속도 변화를 추정하지 않습니다. 설치 소스·원본·시간·메모리·각 관측 범위. 같은 설치 기록은 연구 저장소에도 올렸으며, 열두 제어의 소스·생성 코드·실제 추론 횟수·입력 관측을 검산하는 회귀 검사를 포함해 20개 CI 작업을 통과했습니다.

다음에 이 연결을 활용할 곳

명시적인 입력 위치를 기반으로 작은 모델이 허용된 인자·연결 후보를 고르는 실험을 할 수 있습니다. 조건, 변수 할당, 자료 전달을 소스에 남기면서 각 단계의 관측을 다음 선택의 자료로 사용하는 방향입니다. 기록값을 받는 본문, 호출·반복, 호출을 넘는 피드백은 각각의 의미와 실행 구현을 이어 확장할 영역입니다.