기술 요약: Copilot을 이용한 주석 작성

문제 정의

GitHub Copilot과 같은 AI 코드 생성 도구가 프로그래밍 환경에 통합됨에 따라, 컴퓨팅 교육의 교수법적 초점은 코드를 한 줄씩 작성하는 것에서 자연어로 의도된 동작을 명시하는 것으로 이동하고 있다. 그러나 학생들이 AI 어시스턴트를 사용할 때 이러한 명세(주석)를 어떻게 구성하는지에 대한 실증적 이해는 제한적이다. 특히 학생들이 주석을 통해 어떤 유형의 주석을 작성하는지, 반복적인 시도 과정에서 주석이 어떻게 진화하는지, 그리고 대화형 대화가 아닌 주석을 통해 대규모 언어 모델(LLM)을 가이드하는 과정을 어떻게 인식하는지는 불분명하다. 본 연구는 AI 지원 프로그래밍 과업에서 학생들의 명세 작성 방식, 특히 학생들이 주석을 실행 가능한 프롬프트로 취급하는지 아니면 기술적인 문서로 취급하는지, 그리고 AI가 생성한 코드를 검증하는 과정을 어떻게 관리하는지에 대한 지식의 공백을 다룬다.

방법론

본 연구는 Java를 사용하는 학부 객체 지향 프로그래밍(OOP) 과정의 4개년 데이터셋(2023~2026)을 분석하였다. 활동은 학생들이 제공된 스크린샷 형태의 짧은 Java 클래스의 동작을 GitHub Copilot을 사용하여 재현하도록 요구하였다. 결정적으로, 학생들은 코드를 직접 작성하는 것이 금지되었으며, 대신 스타터 파일에 자연어 주석을 작성하여 Copilot의 생성을 유도해야 했다. 학생들은 이 파일들을 자동 테스트 환경(CodeRunner)에 제출하여 실패한 테스트에 대한 피드백을 받았으며, 주석을 반복적으로 수정할 수 있었다.

데이터셋:

• 참가자: 4개 연도 코호트에 걸친 1,161명의 학생.
• 규모: 10,257건의 기록된 제출 시도 및 136,424건의 추출된 주석 인스턴스 (변경되지 않은 전달 주석을 제거한 후 콘텐츠 분석을 위해 52,172개의 고유 인스턴스로 축소).
• 과업: 세 가지 프로그래밍 과업(SimpleMath, BankAccount, ShoppingCart) 및 최종 성찰.

분류 체계 및 분석:
저자들은 학생의 주석을 분류하기 위해 다차원 분류 체계를 도입하였다:

1. 주석 유형: 무엇(의도된 결과/상태), 어떻게(절차/순서), 또는 왜(이유).
2. 코드 표현 수준: 엄격한 코드(Strict-Code, 의사코드/컴파일 가능), 코드 유사(Code-Like, 의사 코드), 또는 자연어(Natural-Language, 일반적인 지시문).
3. 코드 구조: 대상 Java 요소 (예: 조건문, 루프, 반환, 필드 선언).

분류 파이프라인:
자동 분류는 GPT-5.4 계열 모델을 사용하여 수행되었다. 파이프라인은 세 가지 분류 체계 차원에서 인간 연구자와 높은 일치도(Cohen's $\kappa$ 범위 0.771 ~ 0.927)를 달了했다. 학생들의 성찰은 주제 식별을 위해 4단계의 LLM 지원 파이프라인을 통해 분석되었다.

주요 기여

1. AI 명세를 위한 분류 체계: 목적(What/How/Why), 언어적 코드 근접성, 대상 코드 구조에 따라 학생의 주석을 특징짓는 프레임워크.
2. 다년간의 실증적 분석: 다양한 코드 구조에 따라 주석 전략이 어떻게 달라지는지, 그리고 여러 제출 시도에 걸쳐 어떻게 진화하는지에 대한 대규모 분석.
3. 수정 패턴에 대한 통찰: 주석을 수정하는 정도와 생성된 코드를 검증하는 것 사이의 관계에 대한 증거.
4. 학생 관점: LLM을 가이드하는 역할로서의 주석에 대한 학생들의 인식(속도, 검증 부담, 학습 주체성 등)에 대한 주제 분석.

결과

주석 유형 및 표현 (RQ1)

• "What"의 지배적 사용: 주석의 77.0%는 'What' 주석(의도된 결과 기술)이었으며, 'How' 주석은 21.0%를 차지했고, 'Why' 주석은 매우 드물었다(0.4%).
• 구조 의존성: 여러 단계나 루프를 포함하는 절차적 구조의 경우, 학생들은 'How' 주석으로 이동했다. 예를 들어, Multi-Step-Block의 94.3%, Loop-Iteration의 57.3%의 주석이 'How'로 분류되었다.
• 표현 수준: 대부분의 주석은 자연어였다. 그러나 Return 문의 경우 상당한 비율의 'Strict-Code' 표현(36.7%)을 보였는데, 이는 학생들이 단순한 반환 로직을 위해 때때로 컴파일 가능한 수준의 코드를 작성했음을 시사한다.

주석 수정 (RQ2)

• 낮은 수정율: 대다수의 주석은 시도 과정에서 '신규'(41.3%) 또는 '변경 없음'(48.4%)이었다. 상당한 수정(Heavy Modification 및 Full Rewrite)은 단 4.4%에 불과했다.
• 검증에 집중: 주석 재작성률이 낮다는 것은 학생들이 반복적인 프롬프트 엔지니어링을 통해 명세를 정교하게 다듬지 않았음을 의미한다. 대신, "수정" 노력은 테스트 피드백에 따라 생성된 코드를 확인하는 데 집중되었다.
• 핫스팟: 가장 복잡한 구조들(Multi-Step-Block, Conditional-Return)은 오류 발생 시 가장 상당한 구조 재편을 필요로 했다.

학생 관점 (RQ3)

학생 성찰 분석 결과 13개의 주제가 도출되었으며, 가장 빈번한 주제는 다음과 같다:

• 속도 및 스캐폴딩 (84.5%): 학생들은 빠른 초안 작성과 구문적 마찰을 줄이는 데 있어 도구의 가치를 높게 평가했다.
• 과업 적합성 (64.5%): 학생들은 Copilot이 상용구(boilerplate)나 익숙한 과업에는 효과적이지만, 복잡하거나 구체적이거나 제약이 있는 요구사항에는 어려움을 겪는다고 느꼈다.
• 검증 부담 (57.3%): 학생들은 출력물을 이해하고, 검토하고, 유효성을 확인하는 책임이 여전히 자신들에게 있음을 강조하며, 검증 작업이 시간 절감 효과를 상쇄할 수 있다고 언급했다.
• 학습 및 주체성 (57.2%): 과도한 의존이 핵심 프로그래밍 기술을 약화시킬 수 있다는 우려가 제기되었으나, 비판적 사용은 교육적일 수 있다는 의견도 있었다.
• 프롬프트 정밀도 (54.0%): 학생들은 일반적이거나 부정확한 출력을 피하기 위해 명시적이고 구체적인 제약 조건이 필요함을 인식했다.

의의 및 주장

본 논문은 주석 기반의 AI 프로그래밍이 단순히 코드 생산을 위한 지름길이 아니라, 동작을 이해하고, 의도를 명확히 표현하며, 정확성을 판단하는 복잡한 과업이라고 주장한다.

• 교육적 시사점: 연구 결과는 AI 지원 활동이 코드 생성이 아닌 명세와 검증의 연습으로 프레임화되어야 함을 시사한다. 데이터에 따르면 학생들은 프롬프트를 반복적으로 다시 쓰는 대신, 명확한 자연어 명세를 작성한 후 인지적 부하를 AI 출력물을 검증하는 쪽으로 전환함으로써 성공한다.
• 기술의 변화: 본 연구는 요구되는 기술이 코드를 작성하는 것에서 의도를 명료하게 전달하고 AI가 생성한 솔루션을 비판적으로 평가하는 것으로 변화하고 있음을 강조한다.
• 한계점: 저자들은 본 연구가 하나의 강의 설계와 기관에 국한되어 있으며, 분석이 가시적인 제출 변경 사항만을 포착한다는 점(IDE 내부 편집은 기록되지 않음)을 인정한다. 또한, 자동 테스트를 통과하는 것이 참조 솔루션과의 의미론적 동등성을 보장하는 것은 아니다.

저자들은 결론적으로, AI 시대의 컴퓨팅 교육에서 핵심 학습 목표는 AI 도구를 자율적인 해결사가 아닌 설계 과정의 파트너로 취급하는 명세와 검증이 되어야 한다고 주장한다.