3. 사용 흐름

내부 평가기 이름을 모두 외우기 전에, 지금 하려는 작업부터 고릅니다.

업데이트: 2026-10-09. 공개 0.6.22와 자체 모델을 이용한 조립·실제 실행 흐름입니다.

소스에서 실행과 다음 조립까지 이어 쓰기

작업장에서 assemble로 소스와 모델을 확인하고 실행합니다. 저장한 결과의 실패 입력은 construct --assembly로 다음 조립에 반영합니다. 한 활동뿐 아니라 루트 레코드를 조립하고 그 값을 받은 고정 활동·보조 함수를 실행하는 흐름도 연결합니다. 처음 실행하기, 연결 활동 예제.

정답 없이 실행부터 시작하려면 개발판 gooo-dev의 body-compose --inputs를 사용합니다. 나중에 같은 생성물에 기대값을 제공해 검사합니다. 작업장의 assemble는 선언한 호출 기대값을 사용합니다. 입력부터 실행하기.

작은 모델과 함께 함수 바디를 조립하고 싶습니다

원본 Gooo + 허용된 경로 계획 + 한국어/영어 의도
  -> 모델의 경로 순위 또는 결정론적 순서
  -> 타입·범위 검사와 바디 조립
  -> 유한 예시 평가와 실패 피드백
  -> Go 생성
  -> 빌드·실행 관측

조건·변수·대입·분기·순서를 계획 안에서 선택합니다. 모델의 첫 선택과 추가 탐색 후 결과, 생성된 코드의 실제 실행은 각각 기록합니다. 현재 자체 모델은 제한된 숫자식 빈칸과 세 필드 레코드의 후보 순서를 다룹니다. 모델의 입력 범위는 조립 전 소스·모델 사전 확인에서 읽습니다. 실제 조립 과정과 실행 명령을 따라갈 수 있습니다.

소스·조립 계획·기대값이 파일에 있다면 gooo body-path-run으로 생성과 실행을 이어갑니다. 모델을 생략하면 같은 계획에서 결정론적으로 조립합니다. 출력 폴더의 summary.json에서 요청별 충족 수·분모를 읽고, run-N-generated.go와 run-N-runtime.json에서 실제 코드를 확인합니다. 파일 실행 예제와 결과 읽는 법.

이전 생성·실행 기록을 다음 입력으로 사용할 때에는 gooo completeness-delta --before ... --after ...로 같은 조건의 충족 수와 변경된 기대값·단위·분모를 읽습니다. 실제 명령과 읽는 순서.

선언에서 Go 구조를 만들고 싶습니다

Gooo 선언
  -> 의미 검사
  -> Go 구조 생성
  -> 허용된 슬롯에서 로직 구현
  -> 다시 생성하고 변경 범위 확인

업무 의도를 바꾸려면 .gooo 원본을 바꿉니다. 생성기의 구조가 잘못되었다면 생성기 쪽을 수정합니다. 생성된 영역을 임시로 고치면 다음 생성에서 그 수정의 권위와 보존 여부가 모호해집니다.

수작업 슬롯 보존은 정해진 marker와 생성 계약 안에서의 보장입니다. marker가 손상되거나 ID가 충돌하면 무조건 덮어쓰는 대신 거절해야 합니다. 생성 경계 계약

실행 결과를 확인하고 싶습니다

먼저 무엇이 실행되었는지 묻습니다.

결과의 범위	읽을 수 있는 사실	아직 별도로 필요한 것
선언 해석	입력·출력 선언과 전이의 해석	수작업 Go 실행, 외부 효과
등록된 값 연산	해당 계약에서 실제 호출·출력으로 관측한 값	다른 연산·모든 입력의 보장
생성 Go 실행	고정된 입력에 대해 해당 프로세스가 반환한 결과	업무 전체의 성공, 일반적인 의미 보존
외부 서비스 작업	어댑터가 실제 관측한 효과	선언과의 연결, 허용 범위, 재시도 의미

범위 이름만으로 실행 성공을 판단하지 않습니다. 실제 호출 수, 출력, 실패 기록, 입력 정체성이 함께 있어야 합니다. 선언·값 실행의 구분

잘못된 정책을 고치고 싶습니다

실패나 반례 관측
  -> 원본에 결속된 수정 조건
  -> Gooo 후보
  -> 실제 실행과 독립 비교
  -> 선택 또는 거절
  -> 다음 실행에서 선택 결과 사용

현재 개발은 이 연결을 작은 사례에서 닫는 데 집중합니다. 각 단계가 존재한다는 사실만으로 모든 정책이 자율적으로 수정되는 것은 아닙니다. 어느 단계까지 병합·실행됐는지는 현재 상태에서 분리합니다.

이미 병합된 정책 선택 경로의 입력 준비, 실제 명령, 거절 사유는 실험: 고정된 목표로 정책 후보 선택하기에서 따라갈 수 있습니다. 후보의 선택과 공식 정책 채택은 다른 단계입니다.

수정 후에는 예전 입력의 해시를 새 소스에 맞춰 바꾸어 성공처럼 만들면 안 됩니다. 새로운 입력 스냅샷을 사용했다면 그 사실을 기록합니다. 입력이 달라진 두 결과를 그대로 인과적인 개선 전후 쌍이라고 부르지도 않습니다.

결과가 UNKNOWN입니다

UNKNOWN은 답을 피하는 문구가 아니라, 필요한 근거와 다음 작업을 보존하기 위한 상태입니다. 여섯 필드 계약을 지원하는 경로에서는 다음처럼 읽습니다.

필드	사용자가 얻어야 하는 답
stage	어디에서 멈췄나?
step	어떤 작업을 하던 중인가?
reason	무엇 때문에 결정하지 못했나?
unknown_class	누락·오래된 입력·모호함·의존성 중 무엇인가?
next_operation	다음에 어떤 작업을 해야 하나?
blocked_by	어떤 선행 입력이나 근거가 필요한가?

실행 중인 CI라면 같은 실행 ID를 다시 관측합니다. 시간이 지났다는 이유로 실패나 성공을 추측하지 않습니다. 반대로 이미 발견된 모순은 나머지 자료가 없더라도 반례로 남겨야 합니다.

모든 오래된 경로가 동일한 여섯 필드를 제공한다는 보장은 없습니다. 해당 결과 스키마를 먼저 확인합니다.

어디에 적용해 볼 수 있나요?

프로젝트 관리, 디자인 시스템과 구현의 대응, 인프라 선언과 서비스 계약의 연결은 실험 대상으로 생각할 수 있습니다. 공통점은 “대상, 관계, 변경 근거”가 중요하다는 것입니다.

이 목록은 제품 완성이나 외부 효용의 증거가 아닙니다. 새로운 작업 하나를 기존 의미 요소와 어댑터로 끝까지 연결할 수 있는지부터 확인하는 편이 유용합니다.

---

이전: 언어 둘러보기 · 문서 홈 · 다음: 원리와 경계