알고리즘 개요
프롬프트 점수의 대표 지표는 평균 프롬프트 등급입니다. 이 페이지는 그 밑에서 돌아가는 구조, 곧 서브세션과 완료율을 다룹니다. 완료율은 조건을 만족한 서브세션 중 목표를 완료한 서브세션이 얼마나 되는지 재는 보조 지표입니다.
완료율 = 100 × 완료한 서브세션 ÷ 채점된 서브세션서브세션은 다음 세 가지가 모두 성립할 때 완료로 인정됩니다.
- 실질 기준 통과 — 턴 3회 이상 OR 순 변경 라인 10줄 이상 OR 변경 도구 호출 1회 이상
- 목표 달성 — LLM 결과 채점기가 의도별 기준에 따라 서브세션이 목표를 달성했다고 인정
- 재작업 아님 — 이후 서브세션에서 같은 코드를 되돌리거나 다시 작성하지 않음
의도는 이 판정에 들어가지 않습니다. 어떤 루브릭 항목을 적용할지를 정할 뿐이며, 루브릭 채점기가 유형을 정하지 못한 서브세션은 실패로 세는 대신 점수에서 빠집니다. 실질 기준을 넘지 못한 서브세션은 분자와 분모 양쪽에서 빠지므로, 가벼운 대화가 완료율을 부풀리거나 깎지 않습니다.
완료율은 하나의 공식에 들어가는 두 가지 독립 알고리즘으로 만들어집니다.
- 서브세션 경계 감지 — 어디서 한 서브세션이 끝나고 다음 서브세션이 시작되는가?
- 완료 서브세션 판정 — 닫힌 각 서브세션이 목표를 완료했는가?
서브세션 경계
섹션 제목: “서브세션 경계”서브세션은 다음 중 하나라도 발생하면 닫힙니다.
| 신호 | 의미 |
|---|---|
/clear | 컨텍스트를 명시적으로 초기화한 경우. 터미널을 새로 시작해도 동일하게 처리됩니다. |
| 주제 전환 | 프롬프트가 실질적으로 다른 작업으로 넘어간 경우. |
| 30분 유휴 | 30분간 멈춘 경우 — 점심, 회의, 퇴근 등. |
/compact는 경계가 아닙니다. 트랜스크립트를 압축하지만 목표는 유지하므로 서브세션이 이어집니다.
유휴 경계 덕분에 그냥 자리를 떠도 작업이 정리됩니다. /clear를 잊지 않으려 애쓸 필요가 없습니다. 다만 작업 중간에 오래 자리를 비우면 그 작업이 둘로 나뉩니다. 곧바로 같은 작업으로 돌아온다면 아래 병합이 보통 다시 이어 붙입니다.
조각화 방지 병합(anti-fragmentation merge)
섹션 제목: “조각화 방지 병합(anti-fragmentation merge)”작업 도중에 /clear를 자주 누르면 서브세션이 필요 이상으로 잘게 쪼개집니다. 그래서 서브세션이 닫힌 뒤, 다음 두 조건을 모두 만족하면 앞뒤를 하나로 다시 잇습니다.
- 앞 서브세션이 끝난 지 10분 안에 다시 시작했고,
- 다루는 파일이 50% 이상 겹칠 것
이 병합이 있어야 /clear를 확실한 경계로 쓸 수 있습니다. 병합이 없으면 /clear를 자주 쓰는 것만으로 성실하게 일한 사용자의 점수가 깎일 수 있습니다.
/clear 처리 방식
섹션 제목: “/clear 처리 방식”/clear는 가장 강한 단일 경계 신호입니다. 플러그인이 /clear 이벤트를 보낼 때 다음과 같이 동작합니다.
- 서브세션 종료. 현재 서브세션이 닫혀 채점 대기열로 들어갑니다. 다음 사용자 프롬프트는 새로운 서브세션을 엽니다.
- 닫힌 서브세션은 그 상태 그대로 채점됩니다.
/clear시점의 작업 상태가 결과 채점기에 그대로 전달됩니다. 수정을 검증하기 전에/clear를 하면 서브세션이 완료로 인정되지 않을 수 있습니다. 서브세션을 명시적으로 완료하는 법을 참고하세요. - 조각화 방지 병합 실행. 다음 서브세션이 10분 이내에 시작하고 같은 파일을 50% 이상 다루면, 두 서브세션은 다시 하나로 병합됩니다. 병합된 서브세션은 단일 단위로 재채점되므로, 작업 중간의
/clear가 한 작업을 두 개의 실패 서브세션으로 쪼개지는 않습니다. /compact는 다릅니다. 트랜스크립트를 압축하지만 목표는 유지하므로, 서브세션 경계가 아닙니다. 작업을 끝내지 않고 컨텍스트만 비우고 싶을 때는/compact를, 정말로 새로운 일을 시작할 때는/clear를 사용하세요.
실용 원칙: /clear는 작업 사이에 쓰고, 작업 안에서는 쓰지 마세요. 작업 중간에 /clear를 하고 곧바로 이어서 작업하면 보통 병합기가 잡아주지만, 병합기에 기대지 않는 것이 안전합니다.
닫힌 서브세션이 기록하는 것
섹션 제목: “닫힌 서브세션이 기록하는 것”닫힌 서브세션은 다음을 기록합니다.
| 기록 | 출처 | 답하는 질문 |
|---|---|---|
| 실질 기준 | 규칙 기반 판정 | 실제 작업이 있었는가? (턴 3회 이상 OR 순 변경 라인 10줄 이상 OR 변경 도구 호출 1회 이상) |
| 목표 달성 | LLM 결과 채점기 | 의도별 기준에 따라 서브세션이 목표를 달성했는가? |
| 재작업 | 규칙 기반 판정 | 이후 서브세션이 이를 되돌리거나 다시 작성했는가? |
| 사용 토큰 | OTel | 이 서브세션에서 얼마의 토큰을 소모했는가? |
| 의도 확립 | LLM 루브릭 판정 | 서브세션이 명확한 유형(질문, 버그 수정, 기능 개발 등)으로 분류되었는가? |
의도별 완료 기준
섹션 제목: “의도별 완료 기준”무엇을 “끝냈다”고 볼지는 어떤 작업이었는지에 따라 다릅니다. 판정은 서브세션을 읽고, 어떤 종류의 작업이었는지를 반영해 해당하는 기준을 적용합니다.
| 의도 | 완료로 인정되는 조건 | 묵시적 완료 기준선 |
|---|---|---|
| 질문 | 사용자가 답을 받아들임 (추가 확인 질문 없음) | 0.50 |
| 원인 조사 | 명시된 결론에 도달 (원인 규명, 가설 확인/반박) | 0.60 |
| 리뷰 | 실행 가능한 평결을 냄 (승인 / 거부 / 구체적 변경) | 0.60 |
| 계획·설계 | 세션 내에서 계획 수용 (명시적 “구현하자” 또는 구현으로 이어지는 암묵적 수용) | 0.60 |
| 소규모 수정 | 변경 적용 + 즉시 되돌리지 않음 | 0.50 |
| 버그 수정 | 수정 적용 + 검증 증거 (테스트 통과, 오류 해소, 재현 깨짐 확인) | 0.75 |
| 기능 개발 | 범위에 맞는 스캐폴딩 + 인수 조건 + (테스트 OR 명시적 “테스트는 나중에”) | 0.75 |
| 리팩터링 | 동작 보존 증거 (테스트 통과, lint 통과, 타입 체크 통과) | 0.75 |
버그 수정·기능 개발·리팩터링은 결과가 잘못되면 타격이 큰 고위험 작업입니다. 그래서 테스트 통과 같은 명시적인 완료 신호가 없으면, 정황 증거만으로 완료를 인정받기가 더 어렵습니다. 표에서 이 세 의도의 기준선이 0.75로 가장 높은 것도 그 때문입니다.
묵시적 완료 기준선(silent-completion floor)의 의미
섹션 제목: “묵시적 완료 기준선(silent-completion floor)의 의미”채점기는 명시적 완료 신호를 가장 신뢰합니다. “고마워, 잘 되네” 같은 사용자 반응이나 테스트 통과, 오류가 사라진 것 등이 그런 신호입니다. 이런 신호가 없으면 채점기는 암묵적 증거에 기댑니다. 대화가 자연스럽게 끝났는지, 다음 주제로 넘어갔는지, 뒤이어 불만이 없었는지 같은 정황입니다.
묵시적 완료 기준선은 이 암묵적 증거만으로 서브세션을 완료로 인정하기 위해 채점기가 넘어야 하는 신뢰도 임곗값입니다. 값이 높을수록 더 많은 정황 증거가 필요합니다.
0.50(질문, 소규모 수정) — 약한 확신으로도 충분. 위험이 낮은 작업.0.60(원인 조사, 리뷰, 계획) — 보통의 확신. 결론이나 평결이 명확히 추론 가능해야 함.0.75(버그 수정, 기능 개발, 리팩터링) — 높은 확신. 명시적 검증이 없으면 채점기는 기본적으로 “미달성”으로 둠.
버그를 고치고도 제대로 됐는지 확인하지 않으면, 그 서브세션은 완료로 인정되지 않을 가능성이 큽니다. 점수를 정직하게 지키려고 기준선을 일부러 높게 잡아 둔 것입니다.
서브세션을 명시적으로 완료하는 법
섹션 제목: “서브세션을 명시적으로 완료하는 법”특별히 뭔가를 할 필요는 없습니다. 작업이 실제로 끝나면 대부분의 서브세션은 알아서 완료합니다. 다만 명시적 신호를 남기면 채점기의 확신이 훨씬 높아집니다. 몇 가지 짧은 습관으로 적중률을 올릴 수 있습니다.
| 의도 | 가장 쉬운 명시 신호 |
|---|---|
| 질문 | 답을 받았다고 표시(“알겠어”, “고마워”)하고 추가 확인 질문을 하지 않기. |
| 원인 조사 | 결론을 대화에 남기기: “원인은 X” / “가설 확인됨”. |
| 리뷰 | 평결을 주기: “승인”, “거부”, 또는 원하는 변경을 구체적으로 나열. |
| 계획·설계 | ”구현하자”라고 말하기 — 또는 같은 서브세션에서 구현을 시작하기. |
| 소규모 수정 | 변경을 적용하고, 곧바로 되돌리지 않기. |
| 버그 수정 | 실패하던 테스트나 재현을 실행해 통과 / 오류 해소를 확인하기. |
| 기능 개발 | 테스트와 함께 스캐폴딩을 마무리하기 (또는 명시적으로 미루기: “테스트는 나중에”). |
| 리팩터링 | 테스트·lint·타입 체크를 실행하고 통과했음을 언급하기. |
피해야 할 것: 검증 없이 수정 중간에 끝내기, 확인 전에 /clear로 주제 전환하기, “나중에 다시 볼게”로 흐지부지 끝내기.
실패 신호
섹션 제목: “실패 신호”마지막 2–3 턴 안에 다음 중 하나라도 나타나면 목표에 도달하지 못한 것으로 봅니다.
| 신호 | 패턴 |
|---|---|
| 미해결 오류 | 스택 트레이스, Error:, 후속 수정 없는 실패 테스트 |
| 사용자 좌절 | ”ugh”, “still broken”, “never mind”, “this isn’t working” |
| 범위 포기 | ”let’s try something else”, “I’ll come back to this”, “skip it” |
| 반복 루프 | 같은 수정에 시도 3회 이상, 해결 흔적 보이지 않음 |
종합하면
섹션 제목: “종합하면”서브세션은 실제로 작업이 이루어졌고, 목표에 도달했으며, 이후 다시 뒤집히지 않았을 때 완료로 집계됩니다.
완료율 = 100 × 완료한 서브세션 ÷ 채점된 서브세션실질 기준을 통과하고 판정이 명확하게 나온 서브세션만 집계 대상입니다. 가벼운 서브세션과 목표 없는 잡담은 분자·분모 양쪽에서 빠지므로 점수에 도움도, 손해도 되지 않습니다. 판정을 확신할 수 없는 서브세션은 추측하지 않고 미채점으로 남깁니다.