PRO-Judge
제10회 공개SW 개발자대회 채점 보고서
54.3/ 100
100점 만점 환산 총점
- 진단 지표다. 실제 대회 점수의 예측이 아니다.
- 추정 규칙 민감도 49.3 ~ 59.3 (추정 규칙 비중 50%, 신뢰구간 아님)
- 지난 회차 24.2 대비 +30.1
가장 먼저 고칠 것 — 다음 기준까지 바로 오르는 점수
공개SW 활용성 +2.7점
OSI 라이선스 파일, 설치 명령, 의존성 라이선스 목록이 모두 레포에 있다
가장 큰 손실 작품 데모 -11.3점
이 점수 읽는 법 · 확인할 것 2건
- 진단 지표 이 점수는 아래 점수표로 잰 상대 진단이다. 실제 대회에서 받을 점수의 예측이 아니다. 같은 점수표로 고치기 전후를 비교하는 데 쓴다.
- 보정 안 됨 역대 수상작으로 점수표를 검증하지 않았다.
총평
54.3점, 첫 구현 시점보다 30.1점 올랐다. 오른 점수의 대부분은 LICENSE·CONTRIBUTING·행동 강령(공개SW 활용성 3.0→7.3, 커뮤니티 1.3→9.3)과 promptfoo·DeepEval 비교 페이지(독창성 3.5→12.5)에서 나왔다. 가장 큰 손실은 여전히 데모·발표다: 시연 영상과 발표자료가 없어 두 항목 30점 중 11.3점(+7.4)에 머물렀다. 커뮤니티는 20점 중 9.3점이다 — 커밋 73개가 하루에 몰려 있고 외부 기여자가 0명이며, 대회 뒤 유지 계획이 없다. 기능테스트는 2점에서 1점으로 내려갔는데, 검증 담당 1명만 채점하는 항목이라 회차마다 흔들릴 수 있고 두 회차 모두 테스트 통과 기록이 자료에 없었다. 다음은 시연 영상과 발표자료, 유지 계획이다.
항목별 점수
고칠 것 Top 5
다음 기준 문장(10점 척도의 5점 또는 10점)까지 올렸을 때 바로 오르는 총점 순서다. 그 문장이 자료에 생기게 만드는 것이 할 일이다. 다음 기준이 가까운 항목은 오르는 점수가 작게 나온다 — 손실이 큰 항목은 맨 위 '가장 큰 손실'을 함께 본다.
1
공개SW 활용성10점 척도 7.3 → 10 · 만점까지 최대 +2.7점
+2.7점- 다음 기준 문장 — 이 문장이 자료에 생기게 만든다
- OSI 라이선스 파일, 설치 명령, 의존성 라이선스 목록이 모두 레포에 있다
- 해제 조건
- Apache-2.0 LICENSE, NOTICE, 설치 명령은 있다. 하지만 필수 의존성 PyYAML을 포함해 의존성 라이선스를 한 목록으로 정리한 문서는 없다. 그런 목록이 레포에 있으면 9점 이상이다.
2
독창성10점 척도 8.3 → 10 · 만점까지 최대 +2.5점
+2.5점- 다음 기준 문장 — 이 문장이 자료에 생기게 만든다
- 기존 도구 2개 이상을 이름으로 비교하고 차별 기능이 코드에서 확인된다
- 해제 조건
- promptfoo, DeepEval 2개를 이름으로 비교하고 인용 대조·상한 강제가 aggregate.py에 구현돼 있어 8점. 비교 표의 차별 항목마다 해당 코드 위치를 적으면 10점입니다.
3
작품 발표10점 척도 2.7 → 5 · 만점까지 최대 +7.3점
+2.3점- 해제 조건
- 발표자료(PPT/PDF) 또는 발표 영상이 제출돼야 넘는다. 문제 규모·결과 숫자(29/36 등)와 시연 화면이 들어간 자료가 있으면 10점 기준에 닿는다
- 심사위원이 적용한 상한
- no-deck
- 다음 기준 문장 — 이 문장이 자료에 생기게 만든다
- 발표자료는 있으나 문제 규모나 결과에 숫자가 없다
4
코드의 완성도 및 시연가능성10점 척도 5.7 → 10 · 만점까지 최대 +2.2점
+2.2점- 다음 기준 문장 — 이 문장이 자료에 생기게 만든다
- README 절차대로 실행되고 테스트 N개 통과가 확인되며 시연 영상이 있다
- 해제 조건
- README에 설치 명령은 있다. 그러나 테스트가 N개 통과했다는 결과 수치가 문서에 없고 3분 시연 영상도 없다. 그 둘이 있으면 8점 이상이다.
5
코딩의 적절성 및 구조의 합리성10점 척도 6.0 → 10 · 만점까지 최대 +2.0점
+2.0점- 다음 기준 문장 — 이 문장이 자료에 생기게 만든다
- 모듈마다 책임이 한 문장으로 설명되고 복사된 코드가 없으며 에러 처리 방식이 한 가지다
- 해제 조건
- shared/와 skills/*/shared/ 사본이 같은 코드를 2곳에 둔다. 테스트가 동기화를 검사하긴 하지만 복사본이 있는 건 사실이다. 사본 없이 단일 원본으로 쓰는 구조가 되거나 모듈별 책임 문서가 있으면 7점 이상이다.
확인한 자료와 빈칸
| 출처 | 어디서 | 어떻게 | 신뢰 | 상태 |
|---|---|---|---|---|
| 저장소 | https://github.com/Cassiiopeia/pro-judge/tree/v0.4.3 | repo_facts.py — 커밋·작성자·라이선스·테스트·CI, README·CONTRIBUTING·CODE_OF_CONDUCT 전문 | 팀 자료 | 확인함 |
| 파일 | SKILL.md 2개, aggregate.py, SECURITY.md, 문서 사이트 원본 4쪽 | 파일 원문을 target/에 복사 | 팀 자료 | 확인함 |
| URL | https://cassiiopeia.github.io/pro-judge/ | 브라우저로 열어 메뉴와 '실제 보고서 보기'를 눌러 봄 | 팀 자료 | 확인함 |
| 사용자 | 팀 확인 | 발표자료·시연 영상·외부 사용자를 물음 | 사용자 진술 | 확인함 |
못 본 것 — 점수표가 요구하는 근거 중 자료에서 찾지 못한 것. 이 항목의 점수는 자료를 넣으면 달라질 수 있다.
- 코딩의 적절성 및 구조의 합리성 — 인용 근거를 자료에서 찾지 못함
- 코드의 완성도 및 시연가능성 — 시연·관찰 근거를 자료에서 찾지 못함
- 개발 문서의 구체성 — 관찰 근거를 자료에서 찾지 못함
- 프로젝트 수준 — 관찰 근거를 자료에서 찾지 못함
- 기능테스트 결과 — 시연 근거를 자료에서 찾지 못함
- 작품 발표 — 인용 근거를 자료에서 찾지 못함
- 공개SW 활용성 — 관찰·인용 근거를 자료에서 찾지 못함
- 독창성 — 인용·관찰 근거를 자료에서 찾지 못함
- 커뮤니티로 발전가능성 — 고유명사 근거를 자료에서 찾지 못함
없다고 확인된 것
- 작품 발표: 시연 — 사용자: 발표자료(PPT·PDF) 없음
- 작품 데모: 시연 — 사용자: 3분 시연 영상 없음
- 커뮤니티로 발전가능성: 숫자 — 사용자: 외부 기여자·외부 이슈 0건
편차 경보
- (없음)
회차마다 흔들린 항목
- (없음)
공통 약점 (모델 2종 이상, 전원 5점 이하)
- 작품 발표
- 커뮤니티로 발전가능성
- 작품 데모
항목별 근거
| 항목 | 득점 / 배점 | 심사위원별 | 상한 | 인용 | 변화 |
|---|---|---|---|---|---|
| 코딩의 적절성 및 구조의 합리성 | 3 / 5 | 학계 심사위원 7, 오픈소스 커뮤니티 대표 심사위원 6, 산업계 개발자 심사위원 5 | - | `skills/*/shared/`는 `shared/`의 사본이다. `npx skills`가 skill 폴더 하나만 복사하기 때문에 사본을 커밋한다. / 사본을 직접 고치거나 sync를 빠뜨리면 `test_repo_copies_in_sync`가 실패한다. | +0.3 |
| 코드의 완성도 및 시연가능성 | 2.83 / 5 | 학계 심사위원 6, 오픈소스 커뮤니티 대표 심사위원 6, 산업계 개발자 심사위원 5 | - | python3 -m pytest # 모두 통과해야 PR을 받는다 | +0.5 |
| 개발 문서의 구체성 | 3.83 / 5 | 학계 심사위원 8, 오픈소스 커뮤니티 대표 심사위원 8, 산업계 개발자 심사위원 7 | - | 판단은 에이전트가, 숫자는 스크립트가 맡는다. 에이전트가 규칙을 어겨도 합산 단계에서 강제로 맞춰진다. / | 상한 강제 | 신고된 상한보다 높은 점수는 상한으로 내린다. 확인 불가는 시연 실패와 같은 4점 — 데모를 숨기는 편이 유리하지 않게 | / python3 tools/sync_shared.py / 판단은 에이전트가, 숫자는 스크립트가 맡는다. / `skills/*/shared/`는 `shared/`의 사본이다. | +1.2 |
| 프로젝트 수준 | 3.17 / 5 | 학계 심사위원 7, 오픈소스 커뮤니티 대표 심사위원 6, 산업계 개발자 심사위원 6 | - | 수상팀이 미수상팀보다 높게 나온 쌍 **29 / 36** (한 줄 프롬프트 26 / 36) / 틀린 쌍도 있다. fork한 저장소(Zephyr 금상작)는 팀 기여분이 안 보여 최하위로 나왔다 — 이 발견으로 `repo_facts.py`가 원본 대비 팀 커밋을 따로 세게 됐다 | +0.5 |
| 기능테스트 결과 | 1 / 5 | 기능테스트 검증 담당 2 | - | (인용 없음) | -1.0 |
| 작품 발표 | 2.67 / 10 | 학계 심사위원 3, 오픈소스 커뮤니티 대표 심사위원 2, 산업계 개발자 심사위원 3 | no-deck | (인용 없음) | +2.7 |
| 공개SW 활용성 | 7.33 / 10 | 학계 심사위원 8, 오픈소스 커뮤니티 대표 심사위원 7, 산업계 개발자 심사위원 7 | - | PyMuPDF(AGPL-3.0)·poppler(GPL)를 skill 폴더에 넣거나 함께 배포하지 않는다 — 사용자가 고른 도구를 설치해 쓰게 둔다. / Python 3.9 이상. 새 외부 의존성은 넣지 않는다 — PyYAML 하나만 필수다. / npx skills add Cassiiopeia/pro-judge | +4.3 |
| 독창성 | 12.5 / 15 | 학계 심사위원 8, 오픈소스 커뮤니티 대표 심사위원 9, 산업계 개발자 심사위원 8 | - | promptfoo와 DeepEval은 LLM 애플리케이션의 출력을 테스트하는 범용 평가 프레임워크다. 기준 하나로 통과·실패와 점수를 낸다. / | 근거 확인 | 없음 | 없음 | 없음 | **인용을 원문과 대조**, 없는 인용은 삭제 | / 에이전트가 상한·인용 규칙을 어겨도 여기서 강제로 맞춘다. / | | 한 줄 프롬프트 | promptfoo `llm-rubric` | DeepEval G-Eval | **pro-judge** | / promptfoo와 DeepEval은 LLM 애플리케이션의 출력을 테스트하는 범용 평가 프레임워크다. | +9.0 |
| 커뮤니티로 발전가능성 | 9.33 / 20 | 학계 심사위원 5, 오픈소스 커뮤니티 대표 심사위원 4, 산업계 개발자 심사위원 5 | last-minute-commits | (인용 없음) | +8.0 |
| 작품 데모 | 8.67 / 20 | 학계 심사위원 5, 오픈소스 커뮤니티 대표 심사위원 4, 산업계 개발자 심사위원 4 | no-demo-material | (인용 없음) | +4.7 |
심사위원별 총평
학계 심사위원
모델 opus
독창성 8점: promptfoo·DeepEval·한 줄 프롬프트를 이름으로 비교하고 인용 대조가 aggregate.py에 구현돼 있으나, 비교 도구와의 정량 비교는 없고 한 줄 프롬프트 대비 29 vs 26/36은 12팀 표본이라 근거로서 약합니다. 설계 문서는 작동 방식·합산 규칙의 이유를 적어 8점이지만 버린 대안은 적혀 있지 않습니다. 발표자료(3점)·시연 영상(5점)이 없고 커밋 73개가 하루에 몰려 있으며 외부 기여자 0명이라 커뮤니티 5점입니다.
오픈소스 커뮤니티 대표 심사위원
모델 sonnet
이 레포 파일은 어디 있나요 하고 물으면 대답할 게 많다. Apache-2.0 LICENSE, NOTICE, CONTRIBUTING, CODE_OF_CONDUCT, 비교 페이지가 모두 레포에 있어서 oss-usage와 originality는 높게 줬다. 그러나 커밋 73개가 하루에 몰려 있고, 사람 작성자는 1명이며, 외부 기여자와 외부 이슈는 0건이고, 대회 뒤 누가 이슈에 답하는지 적은 곳이 없다. 그래서 community-potential은 4점이다. 발표자료와 3분 시연 영상도 없어 presentation과 demo는 상한에 걸렸다.
산업계 개발자 심사위원
모델 sonnet
코드는 shared/ 원본을 skills/*/shared/에 복사하는 구조라 중복이 남고, 테스트 함수는 147개인데 통과 수 기록이 없어 구조와 완성도는 5점입니다. 문서와 독창성은 근거가 있어 점수를 줬지만, 발표자료와 3분 시연 영상이 없어 발표 3점, 데모 4점입니다. 외부 기여자와 외부 이슈가 0건이고 커밋이 하루에 몰려 커뮤니티 항목도 5점에 그쳤습니다.
기능테스트 검증 담당
모델 haiku
기능테스트 항목은 2점입니다. 원문에는 테스트 파일 24개와 테스트 함수 147개의 개수만 있고, 실행 결과(통과/실패 수)가 없습니다. 이 검증에서 테스트와 코드는 실행하지 않았으므로 README 기능 5개의 실행 여부는 확인되지 않았습니다. 실행 결과와 예외 입력 응답이 원문에 들어오면 점수를 다시 매깁니다.
부록
추정(inferred) 규칙 — 공고에 없어 에이전트가 정한 것
- evaluator_groups(verification): 제10회 문서는 기능테스트를 '발표 평가 전 별도 진행'으로만 적고 수행 주체가 없다. 2026 공고의 '전문 검증기관' 표현을 따라 별도 그룹으로 뒀다
- items[code-structure] 질문 '모듈·파일이 책임 단위로 나뉘어 있고 중복이 없는가': 구조의 합리성은 책임 분리와 중복으로 관찰된다
- items[code-structure] 질문 '코드 규칙(이름·주석·에러 처리)이 레포 전체에서 일관된가': 코딩의 적절성을 관찰 가능한 일관성으로 바꿨다
- items[code-completeness] 질문 'README 절차만으로 외부인이 설치·실행할 수 있는가': 시연가능성의 1차 근거는 재현 가능한 실행 절차
- items[code-completeness] 질문 '자동 테스트가 있고 통과하는가': 완성도를 숫자로 확인할 수 있는 근거
- items[code-completeness] 상한 no-run-instructions(4): 실행 절차가 없으면 심사위원이 시연가능성을 확인할 방법이 없다
- items[doc-specificity] 질문 '설계·구조·사용법이 문서로 있는가': 프로젝트 Document가 1차 제출물이다
- items[doc-specificity] 질문 '문서에 숫자·명령·파일 경로처럼 따라 할 수 있는 내용이 있는가': 구체성은 따라 할 수 있는 내용의 양으로 관찰된다
- items[project-level] 질문 '기술적 난이도가 있는 부분이 무엇이고 그것이 동작하는가': 수준은 어려운 문제를 실제로 풀었는지로 판단된다
- items[project-level] 질문 '규모(코드량·기능 수·커밋 기간)가 숫자로 드러나는가': 수준 비교는 숫자로만 가능하다
- items[function-test] 질문 '명시된 기능을 테스트 절차대로 돌렸을 때 통과하는가': 기능테스트는 명시 기능 대비 통과 여부
- items[function-test] 질문 '실패·예외 입력에서 오류 메시지가 나오는가': 검증기관 테스트는 예외 경로도 본다
- items[presentation] 질문 '10분 안에 문제·해결·결과를 숫자와 함께 전달하는가': 발표 10분 + Q&A 5분 형식
- items[presentation] 질문 'Q&A에서 근거를 들어 답하는가': 15분 PT에 Q&A 5분이 포함된다
- items[presentation] 상한 no-deck(3): 발표 항목은 발표자료 없이는 평가 대상이 없다
- items[oss-usage] 질문 'OSI 승인 라이선스로 공개되어 있는가': 공개SW의 전제 조건
- items[oss-usage] 질문 '다른 사람이 가져다 쓸 수 있는 단위(라이브러리·CLI·플러그인)로 나와 있는가': 활용성은 재사용 단위가 있는지로 관찰된다
- items[oss-usage] 질문 '사용한 오픈소스 의존성과 그 라이선스를 밝히는가': 라이선스 검증(분석보고서)이 대회 절차에 있다
- items[oss-usage] 상한 no-license(4): 라이선스 없는 코드는 재사용이 불가능해 오픈소스로 볼 수 없다
- items[originality] 질문 '기존 도구 이름을 들고 무엇이 다른지 밝히는가': 독창성은 비교 대상이 있어야 판단된다
- items[originality] 질문 '그 차이가 코드에 실제로 구현돼 있는가': 주장만 있는 차별점은 의도다
- items[community-potential] 질문 '외부 기여자가 첫 PR을 보낼 경로(CONTRIBUTING·이슈 템플릿·테스트 방법)가 있는가': 커뮤니티의 입구는 기여 경로
- items[community-potential] 질문 '이미 외부 사용자·기여자·이슈가 있는가': 발전가능성의 가장 직접적인 근거는 현재 참여자 수
- items[community-potential] 질문 '대회 뒤 누가 유지보수하는지 밝히는가': 유지 주체가 없으면 커뮤니티가 자라지 않는다
- items[community-potential] 상한 no-contribution-path(6): 외부 기여 경로가 없으면 공개된 코드일 뿐 오픈소스 프로젝트가 아니다
- items[community-potential] 상한 no-license(4): 라이선스 없이는 외부인이 법적으로 기여·재사용할 수 없다
- items[community-potential] 상한 last-minute-commits(6): 일괄 커밋은 공개 개발 과정이 없었다는 신호다
- items[demo] 질문 '핵심 기능을 실제 입력으로 시연하는가': 데모는 실제 동작으로만 확인된다
- items[demo] 질문 '시연 결과를 심사위원이 재현할 수 있는가': 재현 불가한 데모는 녹화본과 같다
- items[demo] 상한 no-demo-material(5): 1차 제출물에 시연 동영상이 필수로 들어 있다
실행 정보
- 학계 심사위원: 모델 opus, 독립 실행 예
- 오픈소스 커뮤니티 대표 심사위원: 모델 sonnet, 독립 실행 예
- 산업계 개발자 심사위원: 모델 sonnet, 독립 실행 예
- 기능테스트 검증 담당: 모델 haiku, 독립 실행 예
경고
- (없음)