작은 업무 규칙부터 도입해 보기

업데이트: 2026-10-11 KST.

Gooo의 다음 개발 기준은 다른 개발자가 기존 서비스의 작은 부분에 넣고, 요구가 바뀔 때 계속 쓸 이유를 확인하는 것입니다. 사용할 수 있는 선택지와 입출력 요구를 소스에 적고, 작은 모델이 시도할 순서를 제안합니다. Gooo는 실제 결과를 검사하고 구성한 프로그램을 저장합니다. 모델을 생략하면 고정 순서로 진행합니다.

첫 실행 예제: 배치 처리량 바꾸기

대기 작업이 5개면 5개, 100개면 최대 16개를 처리할 계획을 만듭니다. 음수 입력은 0으로 정규화합니다. 이후 상한을 32개로 바꿔 같은 입력의 결과를 확인합니다. 실제 큐에 작업을 보내는 연동은 후속 범위입니다.

이 정도 규칙은 짧은 Go 함수와 테스트로도 쉽게 표현됩니다. 이번 예제는 요구·선택·생성 결과·재실행을 연결하는 사용 흐름을 보여줍니다. 도입할 가치는 실제 팀에서 규칙을 반복 변경할 때 드는 노력과 운영 결과로 확인해야 합니다.

Gooo 소스의 조립 전 본문에는 상한과 입력 중 큰 값을 반환하는 경로가 들어 있습니다. 작성한 사례는 작은 값을 요구하므로, 선언된 네 가지 조합에서 올바른 분기를 찾아야 합니다. 초기 본문을 일부러 틀리게 둔 예제라는 점을 포함해 원본을 공개합니다.

직접 실행

공개 0.6.27 컴파일러와 Go 1.27.2를 사용합니다. 빈 작업 폴더에서 다섯 파일을 받습니다. 모델 없이도 실행할 수 있습니다.

base=https://raw.githubusercontent.com/wiki/kimjooyoon/meta-ontology-go/observations/queue-batch-pilot-20261011
for file in batch16.gooo batch32.gooo construction.json evaluation16.json evaluation32.json; do
  curl -fSLo "$file" "$base/$file"
done

gooo body-construct --source batch16.gooo --entry Main \
  --construction-cases construction.json --cases evaluation16.json \
  --attempts 4 --out batch16-run

gooo body-construct --source batch16-run/original.gooo \
  --construction batch16-run/construction.json --cases evaluation16.json

gooo body-construct --source batch32.gooo --entry Main \
  --construction-cases construction.json --cases evaluation32.json \
  --attempts 4 --out batch32-run

--out에는 새 폴더를 지정합니다. 첫 명령으로 생성한 selected.gooo, generated.go, construction.json에서 선택한 소스·실제 Go 코드·진행 기록을 읽을 수 있습니다. 두 번째 명령은 저장한 구성을 사용합니다. 세 번째는 바뀐 상한을 새 폴더에 조립합니다.

자체 모델을 함께 쓰려면 모델 준비 안내에 따라 SDK0.2.37의 model-choice-v1.json을 받은 뒤 첫 조립 명령에 --model을 추가합니다. 이 모델의 SHA256은 aa81790884cd21ac9dd435fe5cf14b604cdd658f514f6460a526fc858ae07ab1입니다. 저장 재실행에는 모델 옵션이 필요 없습니다. 새 상호작용 모델의 일반 컴파일러 연결은 후속 작업이며, 이 예제는 현재 공개판이 지원하는 선택별 사례 모델을 사용했습니다.

실제 관측

소스와 관측 조건을 실행 전에 위키 커밋 ce4413ddd01caf15b3dc8481f06cacd574adf8bc에 고정했습니다. 공개 0.6.26으로 상한마다 고정 순서 조립·모델 조립·저장 재실행을 한 번씩 실행했습니다. 두 상한은 같은 업무 틀의 변형입니다. 고객 데이터와 독립적인 업무 정확도 평가는 아직 없습니다.

항목	고정 순서	공개 자체 모델	모델 구성의 저장 재실행
처음 고른 본문이 모든 소스 사례 만족	0/2	0/2	새 선택 없음
소스 후보 검사 수 합계	6	4	원래 선택 기록 재검사
최종 네이티브 출력 사례	20/20	20/20	20/20
새 모델 호출	0	2	0

모델의 첫 선택은 두 경우 모두 틀렸고, 각각 다음 후보에서 요구를 만족했습니다. 각 본문은 소스의 출력 4개와 중간 조건 2개를 만족합니다. 별도 실행 파일의 입력 10개에는 소스 사례와 겹치는 값이 있으므로 이를 새로운 입력 10개에 대한 일반화 성적으로 읽지 않습니다. 모드마다 같은 입력을 반복하므로 세 열을 합쳐 독립적인 60개 문제로 세지 않습니다. 9007199254740993과 음수 큰 정수도 Go의 int64로 비교했습니다.

상한 16→32 변경 뒤 입력 17·31·32·33·큰 양수의 결과가 달라졌고, 음수·0·2·15·16은 같은 결과였습니다. 의미 ID는 유지하며 소스의 상한과 기대 사례를 바꿨습니다.

명령	전체 시간	최대 RSS	모델 판단
상한 16, 고정 순서	1.68초	83.36MiB	0회
상한 16, 모델	0.64초	83.69MiB	66.625µs, 1회
상한 16, 저장 재실행	0.35초	84.05MiB	0회
상한 32, 고정 순서	0.83초	82.88MiB	0회
상한 32, 모델	0.62초	82.66MiB	52.458µs, 1회
상한 32, 저장 재실행	0.35초	82.86MiB	0회

시간은 네이티브 Go 컴파일·실행을 포함한 단회 관측입니다. 고정 순서로 진행해 첫 실행의 캐시 상태와 PC의 다른 작업 영향을 분리하지 못했습니다. 이 표로 모델의 속도 향상이나 서비스 처리량을 추정하지 않습니다. 최대 RSS도 가중치 배열 51,272B와 구분합니다.

원본 파일·기록·검산 방법을 공개했습니다. 검산기는 저장된 기록만 읽으며 모델과 컴파일러를 다시 호출하지 않습니다.

다음 개발에서 먼저 해결할 것

1. 한 업무의 변경 흐름. 기존 Go 서비스에서 교체할 함수 하나와 입력·출력 계약을 정합니다. 큐 처리 예제에서 시작해, 실제 요구를 받으면 필요한 조건식·필드·호출 표현을 보강합니다.
2. 변경 전후 비교. 요구 변화로 결과가 달라진 입력, 새로 실패한 사례, 아직 확인하지 않은 범위를 자동으로 요약하는 비교 명령을 개발 브랜치에 병합했습니다. 기존 실행 기록에서 기대값 변화 5개와 실제 값 변화 5개를 연결했습니다. 검사 목록 등록 누락을 수정했고, 원래 PR과 병합 후의 핵심 CI·네 플랫폼 검사를 통과했습니다. 0.6.27 준비 PR1448도 원래 검사를 통과해 34eb72d6에 병합했습니다. 병합된 소스의 검사를 통과해 공개 0.6.27에 포함됐고 실제 배포 파일을 설치했습니다.
3. 작은 자체 판단기. 조건·변수·한영 의도와 실행 관측에서 경로 순서를 배우는 방향을 유지합니다. 지원하는 소스 범위와 실패율을 함께 공개하고, 모델 없는 실행도 제공합니다.
4. 기존 서비스 연결. 호출 계약과 저장 결과를 재사용할 수 있게 다듬고, 한 팀의 도입에 필요한 설정·수정·운영 비용을 기록합니다. 상시 판단 서버와 외부 모델 연동은 실제 수요로 정합니다.

현재 코어의 후보 검사와 기록으로 이 흐름을 구성합니다. 실행 중 사람의 필수 승인 단계는 추가하지 않습니다. 요구가 불완전하면 미확인 범위를 결과에 남기고, 예산 안에서 완료되지 못한 조립은 그 상태와 실패 사례를 반환합니다.

무엇을 보고 계속 투자할 것인가

첫 목표 사용자는 반복되는 조건·분류·업무 규칙을 관리하는 백엔드 팀이라는 가설입니다. 도입 여부를 결정할 담당자와 실제 반복 업무는 아직 확인하지 않았습니다.

판단할 문제	기록할 값	현재
다른 개발자가 붙일 수 있는가	설치부터 첫 실행까지 시간, 수정 파일·설정 수, 막힌 지점	외부 관측 없음
요구 변경이 쉬워졌는가	같은 변경의 일반 Go 방식 대비 작업 시간, 누락 사례, 재작업	미측정
실제 동작이 나아졌는가	분리한 업무 입력의 성공률·실패·미확인 범위	합성 예제만 관측
운영에 이익이 있는가	처리당 총비용, p50/p95, 실패 복구·지원 시간	미측정
계속 쓸 이유가 있는가	다음 변경에도 사용한 팀 수, 유지 기간, 유료 사용 의향·계약	미확인

비용에는 추론료뿐 아니라 컴파일·검사·실행·설정·지원 비용을 포함합니다. 측정하지 않은 값은 null/미측정으로 둡니다. 별·다운로드·생성 파일 수는 관심의 신호로 기록할 수 있지만 고객의 절감액이나 구매를 대신하지 않습니다.

도입 시간에는 최초의 Gooo 선언과 기대 사례를 작성하는 노력도 포함합니다. 다음 네 주는 아래 가설을 확인하는 순서로 사용합니다.

1. 첫 주: 소스·실행·변경 보고서·저장 재실행을 한 흐름으로 정리합니다.
2. 둘째 주: 참여를 원하는 개발자 3명이 자기 업무의 작은 함수 하나에 적용하는 것을 목표로 합니다. 현재 사용자를 뜻하는 숫자는 아니며, 설치 실패와 표현할 수 없는 요구도 기록합니다.
3. 셋째 주: 첫 사용자의 두 번째 실제 규칙 변경을 살펴보고 Go와 테스트를 직접 고치는 방식과 비교합니다.
4. 넷째 주: 두 팀의 반복 사용과 한 팀의 구체적인 유료 지원 요청이 관측되면 작은 유료 파일럿을 설계합니다. 충족되지 않으면 작업 범위와 사용을 막은 문제를 수정합니다. 이 수치는 내부 진행 기준입니다.

외부 모집과 인터뷰는 아직 실행하지 않은 후속 작업입니다. 설치·연동 지원, 팀의 변경 기록 관리, 반복 검증 운영에서 지불 의사를 확인합니다. 호스팅·SLA·요금제는 실제 요구와 운영 비용을 바탕으로 정합니다. 매출·투자·인수 시점은 미관측으로 남깁니다.

개발 우선순위를 정하는 기준

첫 제품 가설은 자주 바뀌는 작은 업무 규칙을 조립하고, 변경 영향을 보여주는 도구입니다. 예를 들어 배치 한도를 바꿀 때 같은 입력의 결과와 기대값이 어떻게 달라졌는지 함께 보여줍니다. 기존 Go 함수와 테스트를 작성하는 방법을 비교 기준으로 두고, 처음 선언을 배우고 작성하는 비용까지 포함합니다. 사용자가 다음 규칙 변경에서도 다시 꺼내 쓰는지가 중요한 관측입니다.

우선할 작업	실제 사용에서 확인할 질문
함수 하나의 입력·출력과 사례를 가져오기	기존 서비스에서 몇 파일과 설정을 바꿔야 하는가?
모델 두 개와 고정 순서를 같은 요구로 바꾸어 쓰기	얻은 결과·시도 수·총시간에 어떤 차이가 있는가?
저장 재사용과 변경 보고서	두 번째 요구 변경을 이해하고 적용하는 수고가 줄었는가?
지원하지 않는 표현과 실패 사례 설명	사용자가 다음으로 고칠 소스 위치와 요구를 찾을 수 있는가?

장기적으로 쌓을 자산은 재사용 가능한 Gooo 규칙, 실제로 드러난 실패 사례, 모델을 바꿔도 비교할 수 있는 실행 기록입니다. 외부 사용자의 데이터 공개에는 별도 동의가 필요합니다. 모델이 이득을 주지 않는 업무에서는 고정 순서를 쓰고, 반복적으로 나타나는 표현의 부족을 다음 언어 기능으로 해결합니다. 큰 학습과 상시 추론 서비스의 필요성은 그 뒤에 판단합니다.

사례와 반례 실험에서 이 선택을 뒷받침하는 관측이 나왔습니다. 요구가 부족한 64개 소스는 모두 작성된 사례를 통과했지만 별도 검사는 16개만 통과했습니다. 반례를 최대 두 개 추가하면 모델과 고정 순서 모두 같은 검사에서 64개를 통과했습니다. 다음 사용성 작업에서는 완성률의 분모와 미확인 범위를 보여주고, 실패한 기대값을 다음 소스 사례로 옮기는 수고를 줄이는 데 우선순위를 둡니다. 이 결과를 고객 절감액으로 세지 않습니다.

초기 수익 가설은 업무 하나의 연동·전환 지원과 반복 검증 운영입니다. 예산을 결정할 담당자, 현재 지출하는 시간과 지원 부담, 구체적인 유료 요청을 기록해 계약 범위를 정합니다. 지원 비용이 절감 효과보다 크거나 반복 사용이 관측되지 않으면 패키지와 대상을 다시 좁힙니다.

한 팀이 계속 사용할 때 남는 가치

첫 데모 다음에는 동일한 팀의 두 번째 실제 변경을 관측합니다. 비교 기간과 업무 범위를 먼저 정하고, 그 기간에 발생한 설치·사례 작성·수정·실패 처리·지원 시간을 함께 셉니다. 처음 설치한 시간이 여러 변경에 걸쳐 회수되는지 볼 수 있도록 초기 비용도 남깁니다.

구분	기록할 항목	비교할 기준
사용자 작업	규칙 작성·변경·결과 확인·재작업에 쓴 시간	같은 요구를 Go 함수와 테스트로 처리한 시간
사용자 실행비	모델 준비·추론·컴파일·검사·실행의 실제 비용	같은 기간·입력의 기존 실행비
공급자 부담	해당 팀의 설치 지원·문의·장애 처리 시간과 직접 운영비	그 팀이 실제로 지급한 금액
반복 수요	첫 실행을 완료한 외부 팀 중 두 번째 변경에도 사용한 팀 수	완료한 팀 수와 중단 이유를 함께 공개

시간을 금액으로 바꿀 때에는 해당 팀이 동의한 시간당 비용을 사용합니다. 사용자 순편익은 기존 방식의 총비용에서 Gooo 도입·사용·지원·구매 비용을 뺀 값으로 계산합니다. 초기 비용을 비교 기간에 전액 반영했는지, 나누어 반영했는지도 적습니다. 공급자 쪽 잔여 금액은 실제 수입에서 그 팀의 직접 운영비와 지원 인건비를 뺀 값으로 기록하며, 공통 개발비까지 충당한 영업이익과 구분합니다. 현재 이 항목들은 모두 외부 관측이 없습니다.

다음 기능은 반복 사용 중 막힌 표현이나 변경 작업을 해결할 때 우선합니다. 같은 업무에서 일반 Go 방식이 더 간단하고 총비용도 낮으면 그 결과를 남기고 대상 업무를 조정합니다. 모델을 생략했을 때 사용 흐름이 나아지면 그 구성을 제공합니다. 유료 지원은 반복 요청과 직접 비용이 확인된 범위부터 정하고, 투자나 인수는 별도의 협상 결과로 다룹니다.

팀에 공유할 보고서

후속 PR1449에 저장 결과를 Markdown으로 내보내는 기능과 동일한 입력 20개로 검사한 짧은 Go 비교 구현을 올렸습니다. 공개 0.6.27에는 이 출력 형식이 포함되지 않습니다. 원래 핵심 CI와 준비 검사를 통과해 개발 브랜치 22ac71e0에 병합했고, 병합된 소스의 핵심 CI와 준비 검사도 통과했습니다. 보고서는 입력별 이전·이후 값과 근거 파일의 식별값을 함께 표시합니다.

배치 예제의 원래 기록을 읽으면 요구 변경은 5/10, 같은 기대값에서 생긴 회귀는 0/5입니다. 과거에 실패했던 비교 대상은 없으므로 개선율은 미관측입니다. 각 비율은 표에 적힌 입력 그룹을 분모로 사용합니다. 전체 언어의 정확도와 모델 정답률, 고객 절감액은 따로 측정할 항목입니다. 이 보고서를 만드는 동안 모델이나 생성한 프로그램을 다시 실행하지 않습니다.

시장 자료에서 참고한 것

자체 모델을 제품에 넣기 전에 확인한 것

새 사례 압축 비교에서는 모델 크기를 유지한 평균·극값 모델을 각각 한 번 학습했습니다. 관련 평가의 첫 선택 성공은32/128·36/128, 고정 순서는32/128이었고, 모든 방식이 최종적으로 네 후보 안에서 같은 요구를 만족했습니다. 이 값싼 계산에서는 고정 순서의 총 조립 시간이 가장 짧았습니다. 첫 추천 성적과 최종 작업 비용을 함께 읽습니다.

학습 범위를 넓힌 비교에서는 모델 크기를 유지한 채 학습한 규칙군의 새 변형에서 첫 선택 성공이 72/128에서 117/128로 늘었습니다. 제외한 규칙군은 33/64에서 34/64였고, 기존 모델보다 나빠진 문서도 12개 있었습니다. 후보 검사는 줄었지만 이 단순 규칙에서는 고정 순서의 총 조립 시간이 더 짧았습니다. 사용자는 모델을 선택할 수 있고, 도입 효과는 전체 작업 시간과 반복 사용으로 확인합니다.

외부 시장의 신호

a16z는 2026-10-09 TypeSafe 투자를 발표했습니다. 투자사와 회사의 발표는 특정 회사의 자금 조달 사실을 보여줍니다. Gooo의 수요나 투자 가능성은 우리 사용자의 증거로 따로 확인해야 합니다.

Jev 공식 문서는 이미 타입이 있는 선택·점수·확률과 작은 질문을 코드에서 조합하는 방식을 제공합니다. 또한 TypeSafe의 자금 조달 발표는 주변 인프라와 기업 기능을 확장하겠다고 설명합니다. 단순 타입 검사만 추가하는 제품은 공급자가 쉽게 흡수할 가능성이 있다는 것이 이 자료에서 얻은 우리의 사업적 판단입니다.

Gooo에서는 업무 요구를 소스로 보관하고, 후보를 실행해 확인하며, 같은 생성물을 다시 사용하는 과정을 연결해 발전시킵니다. 실제 사용에서 편리함과 비용 차이를 확인하는 것이 다음 단계입니다. 지금까지 자체 모델의 성적과 실패는 모델 실측에 정리했습니다.

새 입력 모델의 실제 연결 관측에서는 첫 후보가 출력 8/8을 만족하면서도 중간 조건 1/3에 그쳤습니다. 모델은 후보 4개, 고정 순서는 1개를 검사해 같은 최종 요구를 만족했습니다. 요구의 어느 부분을 확인했는지와 전체 실행 비용을 함께 보여줘야 사용자가 도입을 판단할 수 있습니다. 다음 언어·보고서 개선에서도 이 구분을 유지합니다.