요약하자면(TL;DR): 저는 저렴한 모델이 코드를 작성하게 하고, 완성된 diff만 최전선(frontier) 모델에게 검토하도록 했습니다. 66개의 실제 코딩 작업에서 이 방식은 가장 비싼 모델이 단독으로 작동했을 때와 거의 같은 수의 문제를 해결했으며, 비용은 작업당 약 5센트 수준에 불과했습니다 (기존 대비). 모든 과정은 공개되었으며 영수증까지 포함되어 있습니다. 제가 무엇을 잘못했는지 말해주세요. 안녕하세요, 여러분. 저는 코딩 작업을 수행하는 모든 단계마다 최전선 모델 가격을 지불하는 것에 질렸습니다. 왜냐하면 그 단계들 대부분은 파일을 읽거나 타이핑하는 것일 뿐이기 때문입니다. 하지만 저렴한 모델만 단독으로 사용했을 때는 버그를 포함하여 배포했고, 저는 나중에야 그것들을 발견했습니다. 그래서 저는 하나의 루프(loop)를 만들었습니다—Krystal Loop Protocol: 저렴한 모델이 샌드박스(sandbox) 내에서 변경 사항을 작성합니다. 여러분의 테스트가 실행됩니다. 다른 회사의 최전선 모델이 정확한 diff만을 검토합니다. 이 모델은 오직 작은 패킷, 즉 작업 내용, diff, 그리고 테스트 출력을만 보기 때문에 검토 비용이 약 1달러 반센트 정도밖에 들지 않습니다. 중요한 부분은 다음과 같습니다: 검토자는 단순히 "이것은 잘못된 것 같다"라고 말할 수 없습니다. 반드시 그것을 증명하는 테스트를 작성해야 합니다. 만약 테스트가 실패하면, 버그는 실제이며 수정됩니다. 테스트가 통과하면, 그 불만 제기는 기각됩니다. 그런 다음 수정 사항은 깨끗해지거나 한계에 도달할 때까지 계속 확인되고 검토됩니다. 모델이 본 적 없는 테스트로 평가된 CooperBench의 66개 기능 작업에 대한 결과는 다음과 같습니다:
| 설정 | 해결 수 | 비용/작업 |
|---|
| gpt-6-astra 단독 | 56 | $0.721 |
| gpt-6.1-sol 단독 | 56 | $0.123 |
| deepseek-flash 단독 (3회 실행) | 54–57 | $0.014–$0.027 |
| 루프: deepseek-flash 빌드, gpt-6.1-sol 검토 (3회 실행) | 54–59 | $0.046–$0.061 |
솔직히 말하자면: 저렴한 모델이 단독으로 작동했을 때의 성능은 예상보다 훨씬 좋았습니다. 검토 과정은 실행당 0개에서 최대 2개의 해결된 작업만 추가했습니다. 하지만 이 루프는 실제 버그(최고 실행에서 실패하는 테스트로 입증된 77개, 수정된 70개)를 잡아냈으며, 이미 작동하고 있던 것을 망가뜨린 적은 단 한 번도 없었습니다. 따라서 승리는 주로 점수보다는 가격 측면에서 이루어졌습니다. 더 중요했던 부분은: 충돌하는 기능을 빌드하는 두 에이전트의 경우였습니다. 루프가 이미 두 기능을 모두 구축한 30쌍을 가져왔습니다. 일반적인 git merge는 그중 2개에 대해서만 작동했습니다.
짧고 구조화된 메시지를 통해 작업을 인계하는 두 에이전트는 10센트당 약 28개의 작동 가능한 작업을 달성했습니다. 서로 대화하는 방식의 에이전트들도 28개를 달성했지만, 대신 333개였던 모델 호출을 사용하여 581개를 소모했습니다. 참고로, 한 최전선 모델(frontier model)이 두 기능을 처음부터 구축한 것만으로도 겨우 22개를 달성했으며 비용은 $0.196에 달해 거의 두 배의 비용이었습니다.
현재 시장과 다른 점:
| 설정 | 누가 구축하는가 | 누가 검토하는가 | 무엇이 수정을 유발하는가 |
|---|
| 단일 에이전트 최전선 모델 | 없음 (자체 판단) | - | - |
| 아키텍트/편집자 | (강력한 모델이 계획, 저렴한 모델이 수정) | 없음 | 계획 후 n/a |
| 검토자 서브 에이전트 | 같은 모델 계열 | 같은 계열을 다시 검토하는 검토자의 의견 | 이 루프는 실패한 테스트만으로 작동하며, 검토자는 이미 비용을 지불하고 있는 CLI 구독일 수도 있습니다. |
Gemini, Kimi, Grok, Qwen 모두 동일한 작업자 출력을 검토했으며 서로 2개 작업 이내의 범위에 도달했습니다. Gemini는 API 등가 지출로 작업당 3센트 미만으로 측정 가능한 최전선 비평가(frontier critic)와 정확히 일치하는 성과를 보였습니다 (56개 작업).
저를 비판해 주세요: 실제 저장소에서 무엇이 이것을 망가뜨릴까요? 66개의 작업만으로는 무언가를 말하기에 충분할까요? 저는 아직 빌더로 로컬 모델을 시도해보지 않았습니다. 제 예상은 테스트 게이트가 빌더의 지능보다 품질을 더 잘 보호한다는 것이므로, 괜찮은 로컬 모델이라면 점수를 유지하면서 비용을 거의 0에 가깝게 만들 수 있을 것입니다. 만약 로컬 환경이 있으시다면, 이것이 유효한지 알고 싶습니다. 직접 확인해 보세요: API 키 없이 영수증(receipts)으로 모든 숫자가 재계산됩니다 (python3 -m bench.verify). 제 루프를 다시 실행하는 비용은 약 $3입니다. 아니면 동일한 작업과 숨겨진 테스트로 자신만의 환경을 구축하여 점수를 게시해 주세요:
저장소: https://github.com/KrystalUnity/krystal-loop-protocol . 개인 및 소규모 회사에 한해 사용 가능하며 무료입니다.
제출자 /u/KrystalUnity [링크] [댓글]