이름이 판정에 대한 오해를 만든다 — 「증거」에서 「확인 위치」까지, 그리고 AI 채점 입력에서 떼기

Codemit에서 제출자는 체크리스트 항목마다 「이 기능은 여기서 볼 수 있습니다」를 붙일 수 있습니다. 소스 파일의 위치, 배포한 화면의 URL, 시연 영상의 몇 분 몇 초 같은 것입니다. 코드와 API에서는 이것을 Evidence라고 부릅니다.

공모전 화면에서는 이 칸이 「증거」로 보였고, 수업 화면에서는 「근거」로 보였습니다. 같은 것을 두 이름으로 부르는 게 어색해서 2026년 11월 5일 공모전 화면도 「근거」로 맞췄습니다. 여기까지는 단순한 용어 정리였습니다.

바꾼 뒤 실제로 써 본 쪽에서 피드백이 왔습니다. 「근거 연결」이라고 하니 AI가 이걸 보고 판정하는 것처럼 읽힌다는 것이었습니다.

처음에는 문구의 인상 문제라고 생각했습니다. 그런데 채점 프롬프트를 열어 보니 인상이 아니라 사실이었습니다. 프롬프트에는 두 규칙이 같이 들어 있었습니다.

• 「연결된 Evidence가 주장을 뒷받침하는지 확인하라. Evidence가 없거나 소스에서 근거를 찾지 못하면 반드시 미달」
• 「제출자의 자가 응답은 참고용」

제출자의 말은 참고만 하라면서, 제출자가 붙인 링크가 없으면 미달이라고 했습니다. 소스에 기능이 분명히 있어도 확인 위치를 비워 둔 제출은 미달이 될 수 있었고, 실제로 어떻게 될지는 모델이 두 문장 중 어느 쪽을 더 무겁게 읽느냐에 달려 있었습니다. 화면 이름이 「증거」·「근거」였던 것은 우연이 아니라, 이 칸이 정말 판정 입력이었기 때문입니다.

이름만 바꾸면 화면은 「참고용」이라고 말하는데 채점은 여전히 그 칸을 보는 상태가 됩니다. 그래서 순서를 정했습니다. 판정에서 먼저 떼고, 그 뒤에 이름을 동작에 맞춥니다.

판정 입력에서 떼기

• 채점(Score) 프롬프트에서 Evidence를 다루는 문단, 종류별 확인 방법, 항목별 Evidence 줄을 모두 걷었습니다. 판정은 「소스코드에 그 기능이 실재하는지」만 봅니다.
• 완성도 평가는 채점 프롬프트를 이어 쓰기 때문에 같은 변경이 그쪽에도 들어갑니다.
• 이미 매긴 점수는 바꾸지 않습니다. 점수는 그때의 프롬프트와 함께 고정된 기록이라, 다시 매기지 않고 앞으로 매기는 것부터 새 규칙을 따릅니다.

이름 고르기

떼고 나면 이 칸은 「제출자가 심사하는 사람에게 이 항목을 어디서 보면 되는지 알려 주는 곳」입니다. 판정과는 상관없는 선택 안내입니다.

• 근거 — 버렸습니다. 서비스 안에서 「근거」는 이미 AI의 판정 근거와 완성도 근거를 가리킵니다. 같은 말을 쓰면 다시 판정과 이어 읽힙니다.
• 위치 안내 — 뜻은 맞지만, 버튼과 개수 표시에 붙이기 어색했습니다.
• 확인 위치 — 골랐습니다. 명사 하나라 「+ 확인 위치 추가」, 「확인 위치 2곳」처럼 어디에나 붙고, 「확인하는 사람이 볼 위치」라는 뜻이 그대로 읽힙니다.

화면 라벨은 「확인 위치(선택)」으로 해서, 비워 둬도 된다는 것을 이름에 넣었습니다.

바꾸지 않은 것

코드의 이름, API 필드, 종류 값(파일·URL·영상 시각 등)은 그대로 두었습니다. 이번 일은 동작과 화면의 말을 맞추는 것이고, 외부에 이미 나간 API 이름까지 바꿀 이유는 없었습니다. 대신 용어집에 「Evidence — 화면에서는 확인 위치, 근거·증거라고 부르지 않는다」를 적었습니다.

판정에서 뗐으니, 판정과 이어지는 말도 화면에서 지워야 했습니다.

• 확인 위치를 비운 채 제출하려 하면 뜨던 「이대로 제출하면 이 필수 항목은 미달로 채점됩니다」 경고를 지웠습니다. 이제는 사실이 아니기 때문입니다.
• 심사 화면의 「근거 없음 — 미달로 채점됩니다」, 「미충족(근거는 연결됨)」도 지웠습니다. AI 판정은 충족·미충족만 보이고, 확인 위치는 있을 때만 목록으로 보입니다.
• 제출물을 얼마나 채웠는지 보여 주는 지표는 계산을 그대로 두고 말만 맞췄습니다. 「채움률 N% — 확인 위치 a/b, 권장 자료 c/3」입니다. 채움률은 판정이 아니라 얼마나 채웠는지의 표시이고, 확인 위치는 심사하는 사람에게 여전히 도움이 되기 때문에 남겨 두었습니다.

「AI가 이제 확인 위치를 보지 않는다」는 말은 시험으로 못 박아야 했습니다.

• 바이트 단위 비교 — 같은 소스에 확인 위치 네 종류를 모두 붙인 제출과 하나도 붙이지 않은 제출을 만들고, 두 제출의 채점 프롬프트와 완성도 프롬프트가 바이트 단위로 같은지 봅니다. 프롬프트에 Evidence라는 말이나 종류·값 문자열이 남아 있지 않은지도 같이 봅니다. 확인 위치가 판정에 영향을 줄 수 있는 통로가 프롬프트 하나뿐이니, 그 프롬프트가 같다면 판정도 확인 위치와 무관합니다.
• 흉내 채점기 — 시험용 채점기는 요구사항 문구가 소스에 있으면 충족으로 봅니다. 확인 위치 값에 기대던 시험과 시드 데이터는 소스에 문구를 싣도록 고쳤고, 데모용 미달 항목은 반대로 문구를 빼야 했습니다. 안 빼면 충족으로 뒤집히기 때문입니다.
• 옛 구분자는 남김 — 옛 프롬프트에서 확인 위치를 감싸던 구분자는 새 프롬프트에 없지만, 참가자 텍스트에서 지우는 목록에는 남겨 두었습니다. 고정된 옛 점수 기록의 프롬프트에 그 구분자가 있어서, 누가 텍스트에 심어 넣으면 계속 지워야 합니다. 남겨서 생기는 비용은 없습니다.

설계 기록도 정리했습니다. 「확인 위치는 판정 입력이 아니다」를 새 결정 문서로 쓰고, 예전에 「증거가 없으면 미달」을 정한 문서들에는 「새 문서로 대체됨」 한 줄만 붙였습니다. 옛 문서의 본문은 그때 그렇게 정했다는 역사라 고치지 않았습니다. 약관도 확인했는데, Evidence가 채점에 쓰인다는 문장이 없어서 고칠 곳이 없었습니다.

• 채점은 소스코드만 보고, 확인 위치를 붙였든 안 붙였든 같은 프롬프트가 나갑니다. 소스에 기능이 있는데 링크를 안 붙여서 미달이 되는 일은 없어졌습니다.
• 화면의 이름과 문구가 실제 동작과 같은 말을 합니다. 「확인 위치(선택)」는 비워 둬도 되고, 비워 둬도 경고가 뜨지 않습니다.
• 코드·API의 이름은 그대로라 바깥 연동은 바뀌지 않았습니다.
• 이미 매긴 점수는 그대로입니다.

• 「이름이 오해를 준다」는 피드백을 받으면, 문구를 고치기 전에 그 이름이 사실을 말하고 있는 건 아닌지 먼저 봅니다. 이번에는 이름이 아니라 동작이 문제였습니다.
• AI 프롬프트에 서로 기대가 다른 두 규칙(「없으면 미달」과 「참고만」)이 같이 있으면 결과는 모델의 해석에 맡겨집니다. 규칙은 하나의 입장으로 정리합니다.
• 「무엇을 판정에 쓰지 않는다」는 약속은 입력이 같으면 출력도 같다로 바꿔 시험합니다. 프롬프트의 바이트 비교는 싸고 확실합니다.
• 이름을 고를 때는 서비스 안에서 그 말이 이미 무엇을 가리키는지 봅니다. 「근거」처럼 이미 판정과 묶인 말은 다른 자리에 쓰면 다시 판정과 이어 읽힙니다.
• 코드 이름과 화면 이름은 달라도 됩니다. 대신 둘을 잇는 자리(용어집)에 적어 둡니다.

• 이미 매긴 점수는 옛 프롬프트로 매긴 그대로입니다. 그때 확인 위치가 없어서 미달이 된 항목이 있었다면, 그 기록은 이의 신청으로만 다시 볼 수 있습니다.
• 코드와 API에서는 여전히 Evidence라는 이름을 씁니다. 화면과 코드의 이름이 달라서, 개발하는 쪽은 용어집을 거쳐 읽어야 합니다.
• 확인 위치가 판정에서 빠졌기 때문에, 소스만으로는 확인하기 어려운 항목(배포한 화면에서만 보이는 동작 등)은 AI가 미달로 볼 수 있습니다. 그런 항목은 사람이 매기는 가산으로 두는 편이 맞습니다.