Integrating AI into Requirements Quality Learning in Software Engineering Education: A TPACK-Guided Empirical Study

당신이 거대하고 정교한 레고 성을 만들고 있다고 상상해 보세요. 첫 번째 벽돌을 끼우기 전에, 당신은 그 성이 어떻게 생겨야 하는지, 어떻게 작동해야 하는지, 그리고 무엇을 위한 것인지 정확하게 적어두어야 합니다. 소프트웨어의 세계에서 이 글쓰기 단계는 **요구사항 공학(Requirements Engineering)**이라고 불립니다. 이것은 엔지니어가 프로그램이 무엇을 해야 하는지 파악하는 설계도 단계입니다. 만약 설계도가 모호하거나 틀렸다면, 나중에 성 전체가 무너질 수도 있습니다.

이제, 당신을 위해 즉석에서 이 설계도를 써줄 수 있는 초스마트 로봇 조수(생성형 AI)가 있다고 상상해 보세요. 이 로봇은 빠르고 창의적이지만, 여기에는 함정이 있습니다. 만약 당신이 로봇에게 모든 일을 다 시키기만 한다면, 당신은 스스로 성을 쌓는 법을 결코 배우지 못할 수도 있고, 혹은 로봇의 설계도에 숨겨진 결함이 있다는 사실을 알아차리지 못할 수도 있습니다. 이것이 오늘날 교사들이 직면한 큰 질문입니다. 어떻게 하면 학생들이 단순히 복사해서 붙여넣는 게 아니라 규칙을 이해하는 게으른 사람이 되지 않도록, 이 강력한 로봇들을 학습에 활용할 수 있을까요?

이 질문에 답하기 위해, 연구자들은 TPACK이라는 교육 지도를 사용합니다. TPACK을 완벽한 수업을 위한 레시피라고 생각해보세요. 이 레시피는 세 가지 재료를 혼합합니다: 내용(Content) (실제 구축 규칙), 교수법(Pedagogy) (지식을 각인시키기 위한 가르침의 기술), 그리고 기술(Technology) (로봇 도구). 목표는 로봇이 당신을 대신해 생각하는 것이 아니라, 당신이 생각하도록 돕는 방식으로 이들을 혼합하는 것입니다.

---

실험: 학생들을 로봇의 주인으로 가르치기

탐페레 대학교의 석사 과정 소프트웨어 공학 수업에서 연구자들은 AI를 사용하는 새로운 방법을 실험했습니다. 그들은 단순히 "여기 로봇이 있으니 요구사항을 작성해봐"라고 말하지 않았습니다. 대신, TPACK 레시피를 바탕으로 학생들과 AI가 따라야 할 특정한 "춤"을 설계했습니다.

과제는 **사용자 스토리(User Stories)**에 관한 것이었습니다. 사용자 스토리는 사용자가 소프트웨어 기능에 대해 무엇을 원하는지를 설명하는 짧은 문장입니다. 이 스토리들의 품질을 보장하기 위해, 수업에서는 INVEST라는 체크리스트를 사용했습니다 (이는 독립적(Independent), 협상 가능(Negotiable), 가치 있음(Valuable), 추정 가능(Estimable), 작음(Small), 테스트 가능(Testable)을 의미합니다).

이 "춤"은 다음과 같이 진행되었습니다:

1. 인간 우선: 학생들은 먼저 로봇 없이, INVEST 체크리스트를 사용하여 오래되고 엉망인 기존 요구사항들을 좋은 사용자 스토리로 직접 다시 작성해야 했습니다.
2. 로봇 다음: 그 후, 학생들은 멀티 에이전트 AI 도구(고객이나 개발자 같은 다양한 '인격'을 가진 로봇들)를 사용하여 AI가 생성한 버전의 스토리를 만들었습니다.
3. 대결: 학생들은 자신이 직접 쓴 스토리와 로봇이 만든 스토리를 비교해야 했습니다. 그들은 어떤 것이 더 나은지 결정하고, 로봇의 결과물을 수정하며, 그 이유를 설명해야 했습니다.
4. 동료 검토: 마지막으로, 학생들은 자신의 작업물을 반 친구들과 교환하여 동일한 체크리스트를 사용하여 서로의 점수를 매겼습니다.

연구 결과: 로봇은 대체재가 아닌 조력자이다

연구는 참여한 72명의 학생을 대상으로 진행되었습니다. 학생들이 AI와 협업했을 때 다음과 같은 일이 일상적으로 일어났습니다.

1. 학생들은 그냥 "모두 승인" 버튼을 누르지 않았다
만약 로봇이 단순한 마법 버튼이었다면, 학생들은 로봇이 쓴 모든 것을 수락했을 것입니다. 하지만 그렇지 않았습니다. 학생들은 까다로웠습니다. 평균적으로 로봇은 학생 1명당 약 16.5개의 사용자 스토리를 생성했지만, 학생들은 그중 약 9.5개만을 승인했습니다. 이는 **56%**의 승인율입니다.

• 비유: 이것은 로봇 요리사에게 피자를 주문하는 것과 같습니다. 로봇은 16판의 피자를 만들지만, 당신은 치즈가 너무 많거나 토핑이 잘못되었다는 이유로 9판만 남깁니다. 당신은 로봇이 아니라 맛을 보는 감별사입니다.
• 행동: 약 **24%**의 학생이 명시적으로 로봇의 결과물을 수정했으며, 대부분의 학생은 스토리를 다듬는 과정을 적어도 한 번 이상 거쳤습니다. 그들은 AI를 최종 해결책이 아닌 초안 생성기로 취급했습니다.

2. 로봇은 잘하는 것도 있지만, 서툰 것도 있었다
연구자들이 AI를 사용하기 전과 후의 품질 규칙(INVEST 체크리스트)에 대한 학생들의 이해도를 확인했을 때, 엇갈린 결과가 나타났습니다.

• 승리: 학생들은 스토리가 테스트 가능(Testable)(테스트로 확인할 수 있는지)하고 가치 있는(Valuable)(실제로 유용한지) 측면을 포착하는 능력이 훨씬 좋아졌습니다. 로봇은 이 부분들을 더 명확하게 만드는 데 도움을 주었습니다.
• 혼란스러운 부분: 협상 가능(Negotiable)(논의를 통해 변경할 수 있음)이라는 품질에 대해서는 결과가 묘했습니다. 학생들은 로봇이 이 부분을 이해하는 데 도움이 되었다고 느꼈지만, 실제 학생들의 답변을 교사의 "정답"과 대조해 본 결과, 점수는 오히려 약간 하락했습니다.
• 교훈: 로봇은 구조를 잡거나 명확하게 만드는 것(문법 교정 등)에는 뛰어나지만, 사람들이 무엇을 원할지 추측해야 하는 소프트웨어 설계의 모호하고 인간적인 부분에서는 어려움을 겪습니다.

3. 신뢰하되, 검증하라
도구에 대한 느낌을 물었을 때, 학생들은 조심스러운 낙관론을 보였습니다.

• 유용성: 대부분의 학생은 로봇이 아이디어를 생성하고 세부 사항을 추가하는 데 도움이 되었다고 동의했습니다. 한 학생은 로봇이 "구조화된 언어"와 "더 명확한 수용 기준"을 제공했다고 말했습니다.
• 신뢰: 그들은 맹목적으로 믿지 않았습니다. 약 14명의 학생은 규칙에 따라 로봇의 작업을 적극적으로 확인했다고 답했고, 10명은 명시적으로 로봇의 아이디어를 거부하거나 이의를 제기했습니다.
• 문제점: 일부 학생들은 로봇의 인터페이스가 다소 투박하다고 느꼈으며, 때때로 로봇이 프로젝트와 맞지 않는 너무 모호한 답변(예: 프로젝트는 드론 배송 관련인데 드론 배송 기능을 제안하는 경우)을 내놓기도 했습니다.

핵심 결론

이 연구는 AI를 교육에 사용하는 비결은 단순히 멋진 도구를 갖는 것이 아니라, 어떻게 사용하는가에 달려 있다는 것을 시사합니다.

만약 학생들이 AI를 먼저 사용하게 한다면, 그들은 단순히 정답을 베낄 수도 있습니다. 하지만 만약 어려운 생각을 먼저 하게 한 뒤, AI를 두 번째 의견을 듣고 비교하며 다듬는 용도로 사용하게 한다면, AI는 강력한 학습 파트너가 됩니다. 이 연구의 학생들은 게을러진 것이 아니라 편집자가 되었습니다. 그들은 로봇의 실수를 찾아내고, 로봇의 강점을 활용해 자신의 작업을 개선하는 법을 배웠습니다.

하지만 연구자들은 이것이 마법 같은 해결책은 아니라고 경고합니다. 로봇은 여전히 소프트웨어 요구사항의 "모호한" 부분에서 갈팡질팡합니다. 따라서 교사들은 주의를 기울여야 합니다. AI를 학습의 명확하고 구조적인 부분을 돕는 데는 사용하되, 까다롭고 해석이 필요한 부분에서는 인간 교사가 개입하여 가이드를 제공해야 합니다.

요약하자면, 로봇은 환상적인 부조종사이지만, 운전대는 반드시 학생이 꽉 잡고 있어야 합니다.