AI 시대의 ‘슬롯머신식 프로그래밍’이 드러내는 숨은 교육과정

TL;DR

• AI를 허용한 컴퓨터과학 수업에서도 학생이 문제를 나누지 않고 같은 프롬프트를 여러 도구에 반복 입력하는 ‘슬롯머신식 프로그래밍’은 문제 해결 역량의 결핍을 드러냄.
• 디버깅, 대규모 코드베이스 작업, 버전 관리, 명령줄 사용, 팀워크, 소프트웨어 설계, 기술 면접, 문서 작성은 그동안 명시적으로 가르치지 않아도 습득될 것으로 기대된 숨은 교육과정의 기술임.
• AI가 한 번의 프롬프트로 수백~수천 줄의 코드를 생성하고 학생의 문제 해결 과정이 줄어들면서, 과거 코드를 직접 작성하며 익혔던 기술을 학생이 암묵적으로 습득하기 어려워짐.
• 코드 작성 비용이 거의 0에 가까워져도 소프트웨어 엔지니어링은 해결된 문제가 아니며, AI 도구로 좋은 결과를 얻으려면 여전히 소프트웨어 엔지니어링 원칙과 기술이 필요함.
• 교육자는 숨은 교육과정의 기술을 명시적으로 가르치고, AI 시대에도 필요한 기술과 덜 중요해진 기술을 재평가해야 함.

슬롯머신식 프로그래밍

• 과제를 해결하지 못해 찾아온 한 학생은 무엇을 시도했는지 묻자 Claude, Gemini, ChatGPT를 사용했다고 답함. 문제는 AI 사용 자체가 아니라, 막혔을 때 진전을 만들 방법을 갖추지 못한 점임. 해당 수업은 AI 사용을 허용함.
• 함께 문제를 살펴보니 학생은 문제의 정신 모형을 만들거나 문제를 작은 단위로 나누지 않고, 한 번의 대형 언어 모델(LLM) 프롬프트로 전체 문제를 풀려 했음.
• 같은 프롬프트를 계속 재사용하며 다음 답변은 맞기를 기대하는 반패턴을 ‘슬롯머신식 프로그래밍’이라 부름. 슬롯머신의 각 시도가 통계적으로 서로 독립적인 것처럼, 같은 프롬프트를 여러 AI 도구에 넣는다고 해결에 더 가까워지는 것은 아님.
• 학생들 사이에서 이 패턴이 점점 더 자주 관찰됨. AI를 사용하는 학생이 게으르기 때문이라고만 볼 수 없으며, 비효율적으로 일해 의미 있는 진전 없이 많은 시간과 노력을 들이는 경우도 있음.

숨은 교육과정의 기술

• 컴퓨터과학 교육자는 학생이 학위를 밟는 동안 여러 기술을 암묵적으로 익힐 것이라 기대해 왔음. 이를 숨은 교육과정이라고 부르며, 슬롯머신식 프로그래밍은 그중 문제 해결 기술의 부족을 드러내는 사례임.
• 다른 주요 기술에는 디버깅, 대규모 코드베이스 작업, 버전 관리, 명령줄 사용, 팀워크, 소프트웨어 설계, 기술 면접, 문서 작성 등이 포함됨.
• 일부 교육 과정에서는 MIT의 Missing Semester 수업이나 *How to Design Programs*처럼 이런 기술을 가르쳤지만, 대다수 학생에게 널리 직접 가르치지는 않았음. 그럼에도 학생이 학습 과정에서 자연스럽게 익힐 것으로 기대해 왔음.
• 컴퓨터과학을 배우는 과정이 달라졌으므로, 학생이 예전처럼 경험을 통해 기술을 암묵적으로 습득하리라 기대하기 어려움. 많은 기술은 작은 문제를 해결하며 고전하고 점차 더 큰 문제로 나아가는 과정에서 습득됐음.
• AI 사용은 학생이 해결책을 찾느라 고심하는 시간을 크게 줄이며, 그 결과 학생이 기술을 개발하지 못할 수 있다는 우려가 있음. 오피스 아워 이용 감소로 다른 학생이나 조교(TA)와 관계를 맺는 대신 AI로 답을 얻는 경향이 커지면 문제가 더 심해짐.
• AI는 많은 질문에 답할 수 있지만, 학생이 질문해야 한다는 사실조차 모르는 질문에는 도움을 주기 어려움. 직접 가르치지 않는 숨은 교육과정 기술은 학생에게 질문을 명확히 표현할 언어와 틀이 없다는 점에서 특히 취약함.

AI가 바꾸는 문제 해결 학습

• 문제 분해를 할 수 없었던 학생의 사례는 AI가 학습 과정에 미치는 변화를 보여줌. 과거에는 사람이 코드를 손으로 작성하는 과정에서 한 번에 수백 줄을 작성할 수 없었으므로, 의식적이든 아니든 문제를 어느 정도 나눌 수밖에 없었음.
• 그렇다고 과거의 문제 분해가 반드시 좋은 방식이었다는 뜻은 아니며, 숨은 교육과정 기술을 익히는 능력에는 학생 간 편차가 컸음.
• 이제 학생은 프롬프트 한 번으로 수백, 심지어 수천 줄의 코드를 생성할 수 있어, 의도적이든 아니든 문제를 나누도록 강제하는 과정이 사라짐. 이전에는 명시적으로 배우지 않더라도 작은 문제를 많이 풀며 문제 해결 능력을 쌓은 뒤, 수백 줄의 코드가 예상대로 작동하지 않는 상황에 도달했음.
• 소프트웨어 개발을 빠르게 진행하며 이전에는 여러 기술을 암묵적으로 가르치던 활동을 건너뛰는 현상은 다른 교육 성과에도 영향을 미칠 수 있음.
• AI는 코드 작성 방식을 완전히 바꿨지만, 소프트웨어 시스템을 정해진 시간과 예산 안에 적절한 품질로 구축하는 소프트웨어 엔지니어링이 해결된 문제인지는 분명하지 않음. 코드 작성 비용이 거의 0에 가까워질수록 소프트웨어 엔지니어링 업무는 남으며, 일반 개발자의 하루에서 차지하는 비중이 점점 커지고 있음.
• 장기적으로 이런 고차원 소프트웨어 엔지니어링 작업도 자동화될 수 있지만, 현재 경험상 AI 도구로 인상적인 결과를 얻으려면 소프트웨어 엔지니어링 원칙과 기술을 적용해야 함. 다양한 기업과 산업의 실무자에게서도 같은 의견을 들음.

숨은 교육과정을 명시적으로 가르치기

• 숨은 교육과정을 포기하는 대신 드러내고, 학생이 앞으로 성공하는 데 필요한 기술을 명시적으로 가르칠 방법을 찾아야 함. 이전에 명시적으로 가르치지 않던 기술을 교육하는 동시에, 교육과정을 재평가해 어떤 기술이 여전히 중요하고 어떤 기술의 관련성이 낮아졌는지 판단해야 하는 이중 과제가 있음.
• 문제 해결은 일반적으로 소프트웨어 엔지니어링에서 명시적인 교육 주제가 아니었지만 가르칠 수 있음. George Pólya는 대표 저서 *How to Solve It*에서 문제 분해를 포함한 수학 문제 해결의 구조화된 접근법을 제시함.
• Alan Schoenfeld는 *Mathematical Problem Solving*에서 인지적 틀을 더하며, *How to Solve It*의 전략만으로는 충분하지 않고 영역별 전술로 보완해야 한다고 설명함.
• Briana B. Morrison, Lauren E. Margulieux, Mark Guzdial은 학생에게 단순히 문제를 풀게 하는 대신 하위 목표 표식을 사용하게 하는 방법을 연구함. 하위 목표를 활용한 학생의 성과가 그렇지 않은 학생보다 높았으며, 학습 시간이 길수록 성과도 좋아졌음.
• Dastyni Loksa, Amy Ko, Margaret Burnett 등의 연구는 프로그래밍에 필요한 문제 해결 기술을 가르칠 수 있음을 보여줌. 이들은 프로그래밍 심리학 연구를 바탕으로 다음의 6단계 과정을 제안함.
• 문제 설명을 재해석함.
• 유사한 문제를 찾음.
• 해결책을 탐색함.
• 잠재적 해결책을 평가함.
• 해결책을 구현함.
• 구현한 해결책을 평가함.
• 이 과정이 개발됐을 당시 학생은 전체 시간 중 상당 부분을 ‘해결책 구현’ 단계에 썼을 것임. 그러나 LLM이 구현 비용을 거의 0으로 줄인 지금은 이 과정을 따르는 사람이 ‘해결책 구현’ 이외의 단계에 대부분의 시간을 쓰게 됨.
• AI는 소프트웨어 개발 방식과 학생이 소프트웨어 개발을 배우는 방식을 크게 바꿨음. 새 과정이 이전과 같은 암묵적 학습 성과를 모두 만들어낼 것이라고 기대할 수 없음.
• 앞으로 숨은 교육과정 가운데 무엇이 여전히 필요한지는 불확실함. 해결해야 할 문제가 존재하는 한 문제 해결은 학생에게 유용하겠지만, 명령줄 도구나 소프트웨어 고고학 같은 기술은 AI로 쉽게 대체될 수 있음.
• 소프트웨어 엔지니어링 수업에서 문제 해결을 명시적으로 가르쳐야 한다는 결론에 이르렀지만, 다음 학기에 무엇을 할지에 관한 생각은 있어도 이를 해결했다고 말할 수는 없음.
• 교육자는 수업을 계속 갱신하면서 슬롯머신식 프로그래밍 같은 반패턴을 살펴, 학생이 더는 습득하지 못하는 기술과 지식을 찾아내고 필요한 교육을 보장해야 함. 학생의 성과를 우선할 때 진정한 성공을 찾을 수 있음.