AI 시대, 코딩 교육은 무엇을 평가해야 하나

COSMIC 데스크톱 프로젝트가 AI 생성 코드와 문서, 풀 리퀘스트(PR) 설명의 기여를 금지했습니다. 반면 AI로 학습하거나 버그를 찾는 일은 허용합니다. 이 구분은 교육에서 중요한 질문을 남깁니다. 학생이 AI를 썼는지가 아니라, 결과를 이해하고 검증하며 책임질 수 있는지가 더 중요해지고 있습니다.

오픈소스가 던진 경계선

System76의 COSMIC 프로젝트는 기여자가 대규모 언어 모델(LLM, 대량의 텍스트를 학습해 문장을 생성하는 인공지능)로 만든 코드·주석·설명을 제출하지 않았다고 선언하도록 지침을 바꿨습니다. 일부 GNOME 하위 프로젝트도 AI 생성 기여를 제한해 왔습니다.

이 정책은 AI를 전면 부정하는 방식과는 다릅니다. AI를 학습 보조 도구나 버그 탐색 도구로 쓰는 일은 가능하지만, 공동 코드베이스에 들어가는 최종 결과물에는 사람의 작성과 검토 책임을 요구합니다. 오픈소스는 유지보수자가 코드의 의도와 변경 이력을 이해해야 장기적으로 안전하게 운영할 수 있기 때문입니다.

보안 발견과 코드 작성은 다릅니다

GNOME 개발자 커뮤니티에서는 AI가 찾아낸 취약점 보고를 받아들여야 한다는 의견도 나옵니다. 규모가 큰 코드베이스에서 AI 보조 분석은 누락된 오류를 발견하는 데 도움을 줄 수 있습니다. 그러나 오류 보고와 수정 코드는 같은 일이 아닙니다. 보고는 검증의 출발점이고, 수정 코드는 다른 사람이 읽고 고치며 장기간 유지해야 할 산출물입니다.

따라서 개발 교육에서도 AI의 답변을 곧바로 제출하는 습관보다, 생성된 코드의 동작을 테스트하고 설계 이유를 설명하는 과정을 평가해야 합니다. 예를 들어 과제 제출 때 핵심 함수의 입력·출력, 실패 가능성, 테스트 결과를 짧게 설명하게 하면 AI 사용 여부와 무관하게 이해도를 확인할 수 있습니다.

교육의 평가는 ‘결과물’에서 ‘검증 과정’으로

글쓰기 분야에서도 인간 저작을 표시하려는 인증 시도가 등장하고 있습니다. 다만 AI 탐지기만으로 사람과 기계의 작업을 가르는 방식은 오탐으로 창작자에게 피해를 줄 수 있다는 우려가 큽니다. 교육 역시 탐지 점수 하나로 부정행위를 판정하기보다 초안, 수정 기록, 출처, 발표와 질의응답을 함께 살피는 편이 타당합니다.

교육자는 과제마다 AI 허용 범위를 먼저 명시할 필요가 있습니다. 개념 설명과 아이디어 정리는 허용하되, 최종 코드·보고서에는 사용한 도구와 검증 절차를 밝히게 하는 방식입니다. 학생에게는 ‘AI가 작성했는가’보다 ‘내가 오류를 찾고 근거를 설명할 수 있는가’가 실력의 기준이 됩니다.

학생 활용법

AI에게 코드를 요청했다면 그대로 제출하지 말고, 각 함수가 왜 필요한지 자신의 말로 설명해 보세요. 예외 입력을 세 가지 이상 만들고 테스트한 뒤, 발견한 오류와 수정 이유를 기록하면 AI를 학습 도구로 바꾸는 데 도움이 됩니다.