What Bugs Do Prolog Students Write? An Empirical Taxonomy and Data-Driven Mutation Framework

당신이 로봇에게 인간처럼 생각하는 법을 가르치고 있다고 상상해 보세요. 당신은 단순히 "범죄를 해결하라"고 말하는 것이 아니라, 단서들이 어떻게 서로 맞물리는지에 대한 특유의 독특한 논리 규칙들을 가르쳐야 합니다. 이것이 바로 **논리 프로그래밍(Logic Programming)**의 세계입니다. 이는 단계별로 '어떻게' 할 것인지를 쓰는 대신, 무엇이 '참'인지를 기술하는 방식의 코딩입니다. 이는 마치 운전 경로를 일일이 알려주는 대신 도시의 지도를 주는 것과 같습니다. 하지만 여기 함정이 있습니다. 인간은 실수투성이입니다. 우리가 이러한 규칙을 배울 때, 우리는 매우 구체적이고 예측 가능한 실수를 저지릅니다. 규칙 하나를 잊어버리거나, 두 단서를 서로 섞어버리거나, 혹은 잘못된 위치에 "정지 표지판"을 배치하기도 합니다.

우리의 코드를 고쳐줄 수 있는 유능한 로봇 튜터를 만들기 위해서는, 우리가 어떤 종류의 실수를 하는지 정확히 알아야 합니다. 만약 로봇이 무작위로 만들어진 가짜 오류들로만 연습한다면, 실제 학생을 만났을 때 당황하게 될 것입니다. 이는 마치 타이어가 펑크 난 자동차로만 연습한 운전 강사가, 학생이 실제로 안전벨트를 매는 것을 잊었을 때 깜짝 놀라는 것과 같습니다. 이 논문은 더 나은 AI 튜터 훈련장을 구축하기 위해, 학생들의 실수라는 혼란스러운 현실을 깊이 파고듭니다.

위대한 프롤로그 버그 사냥 (The Great Prolog Bug Hunt)

최근 한 연구에서 연구자들은 범인을 찾는 대신 컴퓨터 코드 속의 버그를 추적하는 탐정이 되기로 했습니다. 그들은 학생들이 배우고 있는 '프롤로그(Prolog)'라는 언어의 코드 제출물 7,201건을 조사했습니다. 학생 수는 265명의 학부생들이었습니다. 프롤로그를 사실(fact)과 규칙(rule)의 목록을 작성하면 컴퓨터가 답을 찾아내는 언어라고 생각하면 됩니다. 학생들은 단순한 논리 게임부터 "스타 배틀(Star Battle)"이라는 복잡한 보드게임의 솔버를 만드는 최종 프로젝트까지 다양한 퍼즐을 풀었습니다.

연구팀은 단순히 프로그램이 얼마나 많이 실패했는지를 센 것이 아니라, '왜' 실패했는지를 알고 싶어 했습니다. 그들은 학생들이 실수를 수정하고 난 200개의 제출물을 선정하여, 오류들을 하나의 "분류 체계(taxonomy)", 즉 상세한 파일링 시스템으로 직접 분류했습니다. 그 결과, 가장 흔한 실수는 까다로운 논리 오류가 아니라 단순히 미완성된 작업이라는 것을 발견했습니다. 약 **37.5%**의 경우, 학생들은 이야기의 한 장을 빠뜨린 것처럼 퍼즐의 한 부분을 통째로 쓰는 것을 잊어버렸습니다. 그다음으로 흔한 오류는 잘못된 재료를 사용한 것(20.5%)과 규칙 내의 목표(goals)를 서로 뒤섞은 것(13.0%)이었습니다. 흥미롭게도, 학생들은 다른 언어에서 발생하는 것과 같은 단순한 "부주의한" 오타를 거의 만들지 않았습니다. 그들의 실수는 종 often 논리가 어떻게 작동하는지에 대한 깊은 오해에서 비롯되었습니다.

"버그 공장" 구축하기 (LOGMORPH)

학생들이 어떤 실수를 하는지 아는 것도 좋지만, 컴퓨터가 이를 인식하도록 어떻게 가르칠 수 있을까요? 연구진은 LOGMORPH라고 불리는 도구를 만들었습니다. 완벽하게 작동하는 코드 조각을 가져와 의도적으로 망가뜨리는 공장을 상상해 보세요.

기존의 공장들은 다트 판을 향해 다트를 던지는 것처럼 무작위로 무언가를 망가뜨리려 노력했습니다. 그들은 모든 종류의 고장이 동일한 확률로 발생한다고 가정했습니다. 하지만 LOGMORPH는 다릅니다. 이것은 데이터 기반(data-driven) 공장입니다. 이 공장은 연구진이 앞서 구축한 실제 학생들의 실수 "파일링 캐비닛"을 살펴보고 이렇게 말합니다. "좋아, 학생들이 코드를 완성하지 못하는 경우가 37.5%니까, 우리도 코드를 그 방식으로 37.5%만큼 망가뜨리자."

이 도구는 네 단계로 작동합니다:

1. 스캐닝(Scanning): 완벽한 코드를 읽고 실수가 발생할 수 있는 모든 지점을 찾습니다.
2. 샘플링(Sampling): 실수를 일으킬 지점을 선택하되, 실제 학생 통계에 따라 선택합니다. 만약 "절(clause)을 잊어버리는 것"이 흔하다면, 그 빈도를 자주 선택합니다.
3. 주입(Injecting): 실제로 코드를 망가뜨립니다. 때로는 두 숫자를 바꾸는 것처럼 쉽기도 하지만, 때로는 새로운 코드 조각을 생성하여 삽입해야 합니다. 이를 위해, 규칙에 맞는 새로운 코드 한 줄을 생성하는 스마트한 "합성기(synthesizer, 일종의 AI)"를 사용합니다.
4. 테스트(Testing): 망가진 코드가 실제로 테스트를 통과하지 못하는지 확인합니다. 만약 "망가진" 코드가 여전히 완벽하게 작동한다면, 그것을 버리고 다시 시도합니다.

결과: 거의 완벽한 거울

연구팀은 이 공장을 가동하여 16,000개의 가짜 버그 프로그램을 만들었습니다. 그런 다음 이 가짜 프로그램들의 "버그 프로필"을 실제 학생 데이터와 비교했습니다. 결과는 놀라울 정도로 비슷했습니다. 대부분의 오류 카테고리에서 가짜 프로그램은 실제 데이터와 2% 이내의 차이를 보였습니다. 이는 마치 거울을 보고 자신의 모습이 똑같이 움직이는 것을 보는 것과 같았습니다.

하지만 거울이 완벽했던 것은 아닙니다. 연구진은 두 가지 주요 결함을 발견했습니다.

• "컷(Cut)" 문제: 프롤로그에는 컴퓨터에게 다른 답을 찾는 것을 멈추라고 지시하는 "컷(cut, !로 표기)"이라는 특별한 기호가 있습니다. 학생들은 종종 이를 실수합니다. 하지만 가짜 프로그램에서 이러한 실수는 드물게 나타났습니다. 왜일까요? 공장의 "테스트" 단계가 너무 엄격했기 때문입니다. 만약 가짜 컷이 테스트 결과에 변화를 주지 않는다면, 공장은 그것을 버렸습니다. 실제 학생들은 테스트 결과를 바꾸지는 않더라도 논리를 혼란스럽게 만드는 컷 실수를 할 수 있지만, 공장은 이를 걸러냈습니다.
• "로봇" 코드: 공장이 새로운 코드(예: 무작위 목표 추가)를 발명해야 할 때, "합성기"는 기술적으로는 맞지만 의미가 없는 내용을 쓰기도 했습니다. 예를 들어, 빈 리스트를 수학 기호를 사용하여 변수와 비교할 수도 있습니다. 어떤 인간 학생도 그렇게 쓰지 않을 것입니다. 그것은 마치 로봇이 인간의 말을 흉내 내려는 것처럼 보였습니다. 연구진은 만약 합성기를 학생의 글쓰기에 훈련된 더 발전된 AI로 교체한다면, 가짜 코드가 훨씬 더 자연스러워질 것이라고 추측합니다.

이것이 의미하는 바

이 논문은 논리 프로그래밍의 모든 문제를 해결했다고 주장하지 않습니다. 대신, 학생의 오류를 시뮬레이션하는 훨씬 더 나은 새로운 방법을 제시합니다. 실제 데이터를 사용하여 오류의 가중치를 부여함으로써, LOGMORPH는 현실적인 훈련장을 만들어냅니다. 연구진은 향후 이러한 데이터 기반 접근 방식과 더 스마트한 AI 언어 모델을 결합한다면, 이러한 훈련 도구들을 훨씬 더 생동감 있게 만들어, 로봇이 학생이 틀렸다는 사실뿐만 아니라 왜 그러한 특정한 '인간적인' 실수를 했는지까지 이해하도록 도울 수 있을 것이라고 제안합니다.