사례를 모두 통과했는데도 의도가 다른 경우

확인: 2026-10-11 KST.

거리 계산에 기준값을 넣으면 0이라는 사례 하나를 적었다고 생각해 봅시다. 입력에서 기준을 빼도, 기준에서 입력을 빼도 이 사례는 통과합니다. Gooo가 적힌 사례를 모두 만족하는 본문을 만들었어도, 사용자가 바라던 방향까지 정해진 것은 아닙니다.

이번에는 이 간극과 작은 모델의 역할을 함께 확인했습니다. 소스 320개와 평가 계획을 공개한 뒤, 기존 입력 형식과 변수 표현을 정리한 새 입력 형식으로 모델을 한 번씩 학습했습니다. 모두 Go로 실행했고 모델마다 가중치는 19,034개입니다. 320개는 세 가지 계산 틀에서 만든 관련 변형이며, 서로 독립된 업무 320개로 세지 않습니다.

모델 입력을 정리하면 잘 배우는가

처음 고른 본문이 모든 요구를 만족	고정 순서	기존 입력 모델	새 입력 모델
학습 문서	16/64	17/64	18/64
학습한 계산의 새 상수·한영 설명	32/128	33/128	36/128
학습에서 제외한 계산	16/64	15/64	16/64

새 입력 모델은 128개 평가에서 기존 모델보다 18개를 더 맞히고 15개를 새로 틀렸습니다. 전체 차이는 작고 학습 문서도 잘 맞히지 못했습니다. 같은 계산을 직접 반환하거나 변수에 담는 128쌍에서는 새 입력·점수·추천이 모두 같아졌습니다. 표현의 일관성은 확인했지만 이번 학습 결과만으로 새 모델을 기본값으로 바꿀 근거는 부족합니다.

저장된 입력과 학습 기록을 다시 읽어 보니

낮은 성적의 원인을 좁히려고 기존 학습 문서 64개의 입력을 묶어 봤습니다. 완전히 같은 입력을 받은 문서에는 같은 답을 고른다고 할 때, 이 자료에서 최대로 맞힐 수 있는 수를 셌습니다. 학습이나 모델 호출을 새로 실행한 결과는 아닙니다.

모델에 보여줄 정보	서로 다른 입력 묶음	다른 정답이 섞인 묶음	묶음별 한 답으로 맞힐 수 있는 최대 수
소스	16	16	16/64
소스 + 출력 사례	32	32	32/64
소스 + 중간 조건	32	32	32/64
소스 + 출력 사례 + 중간 조건	64	0	64/64

이번 자료는 출력 방향과 비교 조건을 각각 다르게 요구하도록 만들었습니다. 둘 중 하나를 빼면 구별할 정보가 빠집니다. 전체 입력에는 같은 내용으로 서로 다른 정답을 요구한 문서가 없었습니다. 다만 모델 내부에서 정보를 압축한 뒤에도 이 차이를 유지하는지는 별도 문제입니다. 마지막 행의 64/64는 저장된 입력의 구분 가능성이고, 실제 학습 성적은 위 표의 18/64입니다.

새 입력 모델의 기록된 평균 손실은 1회차 1.492613, 100회차 1.386399, 1,000회차 1.386169, 2,000회차 1.385903이었습니다. 각 값은 해당 회차에서 가중치를 갱신하기 직전의 값입니다. 뒤의 1,000회 동안 감소한 양은 약 0.000266입니다. 이 기록만으로 원인을 하나로 확정할 수는 없습니다. 다음 학습 실험에서는 출력·조건 정보를 함께 유지하면서 내부 압축과 학습 방법을 나누어 점검하고, 필요한 시간과 메모리도 기록하겠습니다.

입력 묶음·손실 추출 결과와 재확인 방법을 공개했습니다. 원래 자료의 식별값을 함께 남겼으며 새 학습·판단·후보 실행은 모두 0회입니다.

앞선 학습 범위 실험의 117/128과는 문서와 요구 조합이 다릅니다. 같은 평가에 대한 성능 하락이나 상승으로 직접 비교하지 않습니다.

빠진 사례를 소스에 넣고 다시 조립하기

추가 64개 문서에는 일부러 기준점의 출력과 조건만 적었습니다. 네 후보가 모두 이 요구를 만족하지만, 따로 준비한 검사에는 의도한 방향을 구별하는 값이 있습니다.

64개 문서에서 관측한 것	고정 순서	기존 모델	새 모델
처음 조립한 본문이 소스 사례를 모두 만족	64/64	64/64	64/64
그 본문이 별도 검사까지 모두 만족	16/64	16/64	16/64
반례를 최대 두 개 추가한 뒤 같은 검사 만족	64/64	64/64	64/64

실패한 출력 하나를 고르고, 출력이 모두 맞으면 실패한 조건 하나를 고릅니다. 그 기대값을 새 Gooo 소스에 적은 뒤 다시 읽고 조립합니다. 원래 실패와 추가한 사례, 소스 변경, 후보 선택을 모두 남깁니다. 모델은 각 조립을 시작할 때 먼저 한 번 호출되며, 후보를 하나씩 확인하는 동안에는 다시 호출하지 않습니다. 가중치도 바뀌지 않습니다.

고정 순서도 같은 최종 결과를 얻었습니다. 여기서 확인한 효과는 구분에 필요한 사례를 더하고 네 후보 안에서 검사한 효과입니다. 반례로 사용한 검사에서 얻은 최종 64/64이며, 그 뒤 새로운 입력 묶음으로 다시 평가하지 않았습니다. 실제 업무에서도 반례의 올바른 기대값을 제공할 근거가 필요합니다. 이번에는 미리 작성한 계산 함수가 그 역할을 했습니다.

우리 PC에서 든 비용

• 모델 학습: 기존 15.319초, 새 입력 15.553초, 각각 한 번.
• 첫 판단 320회 중앙값: 기존 95.958µs, 새 입력 96.166µs.
• 전체 실험: 32.29초, CPU 시간 31.98초, 최대 RSS 96.219MiB.
• 모든 조립·반례 단계의 후보 검사: 고정 912회, 기존 876회, 새 입력 919회.
• 그 조립 구간의 시간 합계: 각각 37.484ms / 104.383ms / 92.619ms.

Apple M4·RAM 16GiB에서 관측했습니다. CPU 시간은 평균 한 코어의 약 99%에 해당하며, PC 전체의 순간 사용률 증가를 측정하지는 않았습니다. 최대 메모리에는 두 학습과 모든 자료가 포함됩니다. 실행 순서와 다른 작업의 영향을 통제하지 않은 단회 관측입니다. 이 저렴한 계산에서는 고정 순서가 전체 조립을 더 빨리 마쳤습니다.

제품에 반영할 방향

사용자가 보는 결과에는 다음 세 가지를 함께 표시하는 것이 필요합니다.

1. 소스에 적힌 사례를 몇 개 만족했는지.
2. 별도 실행에서 무엇을 확인했고 무엇이 실패했는지.
3. 실패를 다음 소스 사례로 옮겼을 때 무엇이 바뀌었는지.

모델 추천 점수만으로 완료를 표시하지 않고, 이 기록을 따라 작은 업무 규칙을 바꾸고 재사용할 수 있게 다듬겠습니다. 일반 Go 함수와 테스트를 직접 수정하는 방식과 비교해, 첫 연결과 두 번째 요구 변경에 드는 수고를 기록할 계획입니다. 실제 팀의 반복 사용과 지불 의사, 운영·지원 비용은 아직 관측하지 않았습니다.

작은 업무 도입 계획에 이 기준을 연결했습니다. 투자·독점 계약·인수를 예상 성과로 적기보다, 다른 사람이 다음 변경에도 이 도구를 선택할 이유를 확인하려 합니다.

공개 자료와 상태

고정된 원본·두 모델·검산기, SDK PR58. 전체 자료는 약 1.9MiB로 압축했습니다. 검산기는 저장된 기록만 읽으며 원래 학습·판단을 다시 실행하지 않습니다. 로컬 SDK 전체 검사·정적 검사와 기록 검산 race 검사를 통과했습니다. 원래 push·PR CI도 통과해 SDK main의 fdecc287에 병합했습니다. 병합된 소스의 원래 CI38082286944도 통과했습니다.

새 형식의 네이티브 컴파일러 연결은 PR1452에 구현하고 원래 필수·호환성 검사를 통과해 개발 브랜치 88a2386d에 병합했습니다. 실제 연결 관측도 공개했습니다. 병합된 소스의 CI는 진행 중입니다. 공개 Gooo 0.6.27의 설치 파일은 그대로이며, Hugging Face 업로드는 아직 완료되지 않았습니다.

후속 사례 압축 방식 비교는 새 상수의 자료를 먼저 공개하고 평균·극값 모델을 한 번씩 학습했습니다. 학습 성적 차이에 비해 관련 평가의 차이는 작았고, 제외한 계산 유형의 첫 선택 성적은 같았습니다. 원래 실험과 분모를 합치지 않고 따로 읽습니다.