아이 AI 수업은 도구 말고 누가 가르치는지부터 보자

아이들 AI 수업은 지금 누가 가르치고 있을까요.

얼마 전에 아이 학교 참관수업을 보고 왔습니다. 요즘은 수업 시간에 AI로 글을 쓰는 것 같은 걸 가르치는 모양입니다. 보고 나오면서 든 생각은 하나였습니다. 개발자 입장에서 보면 이건 아니다 싶었습니다.

처음 드는 생각도 아닙니다. 스크래치가 유행할 때도, 마인크래프트로 코딩을 가르친다고 할 때도 저는 비슷한 생각을 했습니다. 도구 이름은 그때마다 바뀌었는데, 개발자 눈에 비어 보이는 것은 매번 같았습니다.

도구가 문제였다면 도구가 바뀔 때 뭔가 달라졌어야 합니다. 세 번을 바꿔도 같은 것이 비어 있으니 도구보다 앞에 원인이 있다고 봤고, 그걸 따라가다 보니 가르치는 사람이 어디서 배워서 교실에 들어오는지에 닿았습니다.

범위를 먼저 그어 두겠습니다. 참관수업이 몇 학년 무슨 수업이었는지, 누가 가르쳤는지는 적지 않습니다. 이 글은 교실 하나나 강사 한 사람을 두고 하는 이야기가 아닙니다. 제도에 관한 사실은 원문을 열어서 확인한 것만 쓰고, 확인하지 못한 것은 제 판단이라고 밝혀 두겠습니다. 인용한 자료는 전부 2026년 9월 27일에 확인했습니다.

디지털새싹 강사는 이틀짜리 양성과정을 거쳐 교실에 들어갑니다

배경부터 짧게 적겠습니다. 소프트웨어 교육은 중학교가 2018학년도 신입생부터, 초등학교 5·6학년이 2019년부터 필수가 됐습니다(한국일보, 2017-12-27). 그리고 2025년부터 적용되는 2022 개정 교육과정에서 정보 수업 시간이 초등은 17시간에서 34시간 이상으로, 중학교는 34시간에서 68시간 이상으로 늘었습니다(정책브리핑, 2022-08-29). 정규 교과 안의 정보 수업은 학교 선생님이 맡습니다.

교과 밖으로 들어오는 AI 교육은 경로가 다릅니다. 대표적인 게 교육부의 디지털새싹입니다. 올해는 대학과 공공·민간기관을 대상으로 운영기관 공모를 해서 45곳을 골랐고, 이 기관들이 267종의 프로그램을 들고 학교로 직접 찾아가 8~12차시 이상씩 수업을 합니다. AI 특화과정도 새로 생겼습니다(머니투데이, 2026-05-27).

이 구조에서 학교가 고르는 건 프로그램이고, 강사는 운영기관 쪽에서 옵니다. 기사에 적힌 방식이 운영기관이 학교로 직접 찾아가는 것이니 그렇게 읽힙니다. 학부모 입장에서는 학교 수업 시간에 들어온 사람이니 학교가 뽑은 사람이라고 생각하기 쉬운데, 실제로 그 사람을 모집하고 가르쳐서 보낸 곳은 학교 바깥에 있는 셈입니다. 그러니 그 사람이 무엇을 알고 교실에 들어오는지를 알려면 운영기관이 강사를 어떻게 만드는지를 봐야 합니다.

강사는 운영기관이 모으고 운영기관이 양성합니다. 한 컨소시엄의 2025년 강사 양성과정은 8월 30일과 31일, 이틀이었습니다. 이틀 동안 과정별 주제 실습을 했고, 과정을 마친 교육생에게는 그 과정과 연계된 캠프를 운영할 자격이 주어졌습니다(전자신문, 2025-09-03). 다른 대학이 연 양성교육도 기사에 적힌 내용은 비슷합니다. 프로그램 실습과 교수법, 청소년 대상 교수법, 프로그램 운영 방법을 익혔고 수료한 강사를 하반기부터 중학교 현장에 보낸다고 했습니다(대학신문, 2025-08-21).

누가 그 과정에 들어가는지도 몇 군데 열어봤습니다. 현직 교원 50여 명이 양성교육을 받았다는 기사가 있고(아시아경제, 2025-06-02), 교육이나 컴퓨터공학 계열 대학(원)생을 뽑되 대학생은 보조강사로만 출강할 수 있다는 모집 공고가 있습니다(링커리어 모집 공고). 방과후 쪽으로 가면 민간자격이 따로 있습니다. 제가 열어본 코딩교육지도사 과정 하나는 100% 온라인 20차시였고, 자격을 쓸 곳으로 방과후학교를 맨 앞에 적어 두고 있었습니다(과정 안내 페이지).

제가 열어본 공고와 기사 가운데 현업 개발 경력을 요구하는 문장은 하나도 없었습니다. 공고를 전부 본 것은 아니니 어디에도 없다고 단정하지는 않겠습니다. 다만 교실에 들어오는 문이 무엇으로 열리는지는 분명하게 보였습니다. 이력보다 이수입니다.

사업을 운영하는 쪽에서 보면 이렇게 짜는 게 이해가 됩니다. 전국 학교를 찾아가 올해만 학생 16만 명 넘게 가르치려면 강사가 많이 필요하고, 그것도 빨리 필요합니다. 현업 개발자를 그만큼 모아서 평일 낮 교실에 보내는 건 현실적으로 안 됩니다. 그러니 가르칠 수 있는 사람을 모아 프로그램을 익히게 하고 내보내는 쪽으로 갈 수밖에 없습니다. 저는 이 선택이 틀렸다고 보지 않습니다. 오히려 누가 운영해도 비슷하게 짰을 거라고 봅니다. 그래서 이 문제를 사람이나 기관 탓으로 돌리면 안 된다고 생각하고, 구조라고 부르는 이유도 거기 있습니다.

오해가 없게 적어 두면, 이건 강사들이 성실하지 않다거나 실력이 없다는 이야기가 아닙니다. 현직 선생님도 있고 전공자도 있습니다. 제가 보는 건 사람이 아니라 한 사람이 교실 앞에 서기까지 거치는 경로입니다. 그 경로에서 강사가 받는 건 운영할 프로그램 그 자체이고, 그러니 강사가 교실에 들고 들어가는 것도 그 차시를 진행하는 순서입니다. 순서 바깥의 것, 이를테면 결과가 이상할 때 어디부터 의심하느냐는 양성과정에서 다루지 않았다면 강사가 갖고 있을 이유가 없습니다.

참관수업을 보면서 제가 느낀 것도 이 구조에서 나온다고 보고 있습니다. 교실에 선 사람이 누구든, 현업을 거치지 않고도 설 수 있게 경로가 짜여 있으면 현업에서만 생기는 감각은 교실까지 오지 않습니다. 아래 세 가지가 전부 그 결과입니다.

스크래치와 마인크래프트를 지나 생성형 AI까지 도구 이름만 바뀌었습니다

이틀짜리 과정으로 넘겨줄 수 있는 게 무엇일까를 생각해 보면 답이 좁아집니다. 어떤 블록을 끌어다 놓으면 캐릭터가 움직이는지, 어디에 무엇을 입력하면 글이 나오는지는 이틀이면 넘겨줄 수 있습니다. 강사 매뉴얼로 쓸 수 있고, 따라 하면 같은 결과가 나오니까요. 반면 결과를 보고 이게 맞는지 의심하는 감각은 매뉴얼로 옮겨지지 않습니다.

그래서 수업의 단위가 도구가 됩니다. 스크래치가 뜨면 스크래치 과정이 생기고, 마인크래프트가 뜨면 마인크래프트 과정이 생기고, 생성형 AI가 뜨면 AI 과정이 생깁니다. 강사는 새 도구로 다시 양성되고, 수업은 새 도구의 조작법을 중심으로 다시 짜입니다. 겉에서 보면 매번 새로운 교육인데, 개발자 눈으로 보면 매번 같은 수업의 도구만 갈아 끼운 것으로 보입니다.

저는 쓴 언어만 열두 개입니다. GW-BASIC을 애플 컴퓨터용 책으로 배웠고, 그 뒤로 C와 COBOL과 어셈블리를 거쳐 PHP, ASP, C#, 지금은 React와 Vue까지 왔습니다. 그중 지금 제 일에 그대로 쓰이는 조작법은 거의 없습니다. GW-BASIC에서 줄 번호를 매기던 습관은 다음 언어로 넘어가지 않았습니다. 넘어간 건 다른 쪽이었습니다. 큰 문제를 작게 자르는 버릇, 돌려 보기 전에 무엇이 나와야 하는지 먼저 생각하는 버릇, 망가지면 마지막으로 멀쩡했던 곳으로 돌아가는 버릇. 이건 언어를 열두 번 바꾸는 동안 한 번도 버린 적이 없습니다.

같은 AI 글쓰기 수업이라도 무엇을 단위로 삼느냐에 따라 한 시간이 완전히 다르게 흘러갈 수 있습니다. 도구를 단위로 삼으면 어디에 무엇을 입력하는지, 원하는 글이 안 나오면 어떤 말을 덧붙이는지가 그 시간을 채웁니다. 판단을 단위로 삼으면 같은 시간이 받은 글의 어느 문장을 믿을 수 있는지, 믿을 수 없다면 무엇으로 확인하는지로 채워집니다. 도구는 똑같이 쓰는데 아이가 들고 나가는 게 다릅니다. 앞쪽은 그 도구가 없어지면 같이 없어지고, 뒤쪽은 다음 도구에도 그대로 씁니다.

아이들이 스크래치 조작법을 배워도 중학교에 가면 도구가 바뀌고, 지금 배우는 AI 도구도 아이들이 사회에 나갈 때는 다른 이름일 겁니다. 도구가 바뀌어도 남는 쪽을 가르쳐야 하는데, 도구를 기준으로 강사를 양성하면 남는 쪽은 강사에게도 없습니다.

정책 쪽에서도 같은 모양을 한 번 봤습니다. AI 디지털교과서는 2025년 3월 현장 적용을 목표로 교원 연수까지 진행하면서 들어왔고(정책브리핑, 2024-12-26), 그해 8월 4일 국회 본회의에서 초중등교육법 개정안이 통과되면서 교과서가 아니라 교육자료로 규정됐습니다. 한 학기 만이었습니다(경향신문, 2025-08-04). 이 과정의 옳고 그름을 따질 생각은 없습니다. 제 눈에 들어온 건 도구가 먼저 도착했고, 그 도구로 무엇을 가르칠지는 나중 문제였다는 순서입니다. 교실 단위에서 제가 본 것과 모양이 같습니다.

현업 개발자는 AI 결과물을 확인하느라 시간을 가장 많이 씁니다

제가 회사에서 AI를 쓰면서 시간을 가장 많이 쓰는 건 만드는 쪽이 아닙니다. 만드는 건 금방입니다. 요청을 넣으면 몇십 초 안에 코드가 나옵니다. 시간이 가는 건 그다음입니다. 나온 코드를 읽고, 돌려 보고, 제가 처음에 요구한 것과 한 줄씩 맞춰 보고, 요구하지 않았는데 끼어든 것이 없는지 봅니다. 돌아가는데 틀린 코드가 제일 무섭습니다. 에러가 나면 바로 보이는데, 돌아가면서 틀린 건 누가 열어보기 전까지 아무도 모릅니다.

예를 들면 이런 식입니다. 목록을 날짜순으로 정렬하는 코드를 부탁하면 AI는 금방 짜 줍니다. 돌려 보면 정렬이 됩니다. 화면에 나온 목록도 날짜순입니다. 여기서 끝내면 안 되는 이유는 제가 준 예시 데이터에 같은 날짜가 두 개 들어 있지 않았기 때문입니다. 같은 날짜가 있을 때 순서가 어떻게 되는지, 날짜가 비어 있는 항목은 어디로 가는지, 목록이 아예 비어 있으면 어떻게 되는지는 제가 따로 넣어 봐야 압니다. 이걸 넣어 보는 건 AI가 해 주지 않습니다. 정확히는 시키면 해 주는데, 무엇을 넣어 봐야 하는지를 떠올리는 건 제 몫입니다. 제가 하루에 AI와 주고받는 시간의 대부분이 이런 것들을 떠올리고 넣어 보는 데 들어갑니다.

아이들 수업은 이 순서의 앞쪽만 가르칩니다. 만드는 법입니다. 블록을 이어서 캐릭터를 움직이게 하는 법, AI에게 부탁해서 글을 받아내는 법. 받아낸 글이 맞는지, 움직이는 캐릭터가 원래 하려던 대로 움직이는지를 따져 보는 시간은 제가 본 범위에서는 수업의 중심에 없었습니다.

예전에 AI 부업 강의 여섯 편의 자막을 붙여 놓고 읽은 적이 있는데, 그때도 제일 오래 붙잡고 있던 게 데모가 생성까지만 보여 주고 멈춘다는 점이었습니다. 어른 대상 강의든 아이 대상 수업이든, 가르치는 쪽에서 보여 주기 좋은 건 만들어지는 순간입니다. 확인하는 순간은 화면에 보여 줄 게 별로 없습니다.

AI 글쓰기로 옮겨 오면 이 빈칸이 더 커집니다. AI가 쓴 글은 문장이 매끄럽습니다. 스크래치 시절에는 프로그램이 틀리면 고양이가 벽을 그냥 지나가 버리는 식으로라도 틀린 게 화면에 드러났습니다. 글은 틀려도 매끄럽습니다. 없는 사실을 있는 것처럼 써도 문장이 자연스러우면 아이 눈에는 맞는 글로 보입니다. 확인하는 법을 안 배운 아이가 이 도구부터 쓰기 시작하면, 틀린 글과 맞는 글을 가르는 기준이 매끄러운지 아닌지가 됩니다.

프롬프트를 잘 쓰는 법을 가르치는 게 AI 교육은 아니라는 이야기는 아들과 루프를 돌린 글에서 이미 했습니다. 여기서 보태고 싶은 건 그 뒤쪽입니다. 자기가 원하는 걸 말로 꺼내는 것까지가 루프의 앞 절반이라면, 돌아온 것이 맞는지 확인하는 게 뒤 절반입니다.

뒤 절반이 양성과정에 없는 이유도 저는 경로에서 찾습니다. 검증하는 감각은 대개 틀린 걸 내보내 본 경험에서 생깁니다. 제가 확인이라고 믿고 넘긴 것이 운영에서 터지고, 다른 사람이 그걸 찾아내서 알려 주고, 그다음부터 같은 종류를 먼저 의심하게 되는 식입니다. 현업을 거치지 않은 사람에게는 그 경험이 쌓일 기회가 없었을 뿐입니다. 개인의 문제로 보지 않는 이유가 여기 있습니다.

스크래치 한 차시로도 문제 쪼개기와 되돌리기는 가르칠 수 있습니다

그럼 현업 개발자가 그 교실에 한 차시를 맡았다면 무엇을 했을까요. 도구를 바꾸자는 이야기는 아닙니다. 스크래치든 AI든 지금 쓰는 도구 그대로 할 수 있는 것들입니다.

저라면 먼저 문제를 쪼개게 했을 겁니다. 고양이가 미로를 빠져나가게 만들라고 하면 아이들은 대개 한 번에 전부를 만들려고 합니다. 그러다 안 되면 어디가 안 되는지 모릅니다. 그 대신 고양이를 한 칸만 움직이게 하고 멈추게 합니다. 그게 되면 벽에 닿았을 때 멈추게 합니다. 그게 되면 출구에 닿았을 때 끝나게 합니다. 조각마다 돌려 보고 맞는지 확인한 뒤에 다음 조각으로 갑니다. 이게 제가 매일 AI에게 일을 시킬 때 하는 것과 같습니다. 한 번에 다 시키지 않고, 확인할 수 있는 크기로 잘라서 시킵니다.

그다음은 돌려 보기 전에 예상을 적게 했을 겁니다. 초록 깃발을 누르기 전에 고양이가 어디에 가 있어야 하는지를 종이에 먼저 적습니다. 그리고 누릅니다. 적은 것과 화면이 다르면 그게 그날의 수업입니다. 왜 다른지를 찾는 과정에서 아이는 자기가 만든 걸 처음으로 읽게 됩니다. 예상을 안 적고 누르면 화면에 나온 게 곧 답이 되고, 틀렸는지 알 방법이 없습니다. 현업에서 테스트를 먼저 적는 것과 뿌리가 같은 버릇입니다.

그리고 되돌아가는 법입니다. 고치기 전에 지금 돌아가는 작품을 사본으로 저장해 두게 합니다. 고치다가 망가지면 망가진 위에 계속 덧대지 말고 마지막으로 멀쩡했던 사본으로 돌아가서 다시 시작합니다. 아이들은 망가진 걸 고치려고 블록을 계속 붙이다가 처음 뭘 하려고 했는지를 잊어버리는데, 그건 어른도 똑같이 합니다. 되돌아갈 곳이 있다는 걸 알면 망가뜨리는 걸 덜 무서워하게 되고, 그래야 이것저것 바꿔 볼 수 있습니다. 현업에서 커밋을 자주 남기는 이유가 이겁니다.

남이 만든 걸 고치는 시간도 넣었을 겁니다. 일부러 한 군데를 틀리게 만든 스크래치 작품을 나눠 주고, 원래 이렇게 움직여야 한다는 설명을 같이 줍니다. 아이들은 설명과 화면을 맞춰 보면서 어긋나는 곳을 찾고, 그 원인이 되는 블록을 찾아야 합니다. 자기가 만든 게 아니니 어디에 뭐가 있는지부터 읽어야 합니다. 현업 개발자가 하는 일의 상당 부분이 사실 이겁니다. 새로 만드는 시간보다 이미 있는 걸 읽고 어디가 틀렸는지 찾는 시간이 훨씬 깁니다. AI가 코드를 써 주는 지금은 더 그렇습니다. 읽어야 할 코드가 전부 남이 쓴 코드가 됐으니까요.

AI 글쓰기 수업에도 앞의 것들을 그대로 옮길 수 있습니다. 쪼개기부터 보면, 한 번에 글 전체를 부탁하지 않고, 첫 문단에 무엇을 쓸지 먼저 자기 말로 정한 뒤 그 문단만 부탁하게 합니다. 받은 문단이 자기가 정한 것과 같은지 보고 나서 다음 문단으로 갑니다. 글 전체를 한 번에 받으면 어디가 내 생각이고 어디가 AI가 채운 건지 아이 스스로도 구분이 안 됩니다.

되돌리기도 글에 그대로 옮겨집니다. AI에게 고쳐 달라고 할 때마다 앞의 판을 지우지 말고 옆에 남겨 두게 합니다. 고칠수록 문장은 매끄러워지는데, 처음에 하려던 말은 조금씩 빠져나갈 수 있습니다. 앞의 판이 남아 있어야 그걸 비교할 수 있고, 비교해 봐야 AI가 고친 것이 나아진 건지 달라지기만 한 건지를 가를 수 있습니다. 제가 AI가 고친 코드를 받을 때 변경 내역부터 보는 것과 같은 이유입니다.

그리고 확인하는 시간을 따로 뗐을 겁니다. AI가 써 준 글에서 사실을 말하는 문장 하나를 골라 교과서나 사전에서 찾아보게 합니다. 같은 질문을 두 번 넣고 두 답이 어디서 달라지는지 찾게 합니다. 아니면 제가 일부러 틀린 내용을 섞어 둔 AI 글을 나눠 주고 어디가 틀렸는지 찾게 합니다. 틀린 걸 찾아낸 아이는 AI가 틀릴 수 있다는 걸 말로 듣는 게 아니라 손으로 한 번 겪습니다. 이 한 번이 있는 아이와 없는 아이는 다음에 AI 글을 받았을 때 하는 행동이 다를 거라고 봅니다.

여기 적은 것 중에 새로운 건 하나도 없습니다. 현업 개발자라면 누구나 매일 하는 일이고, 대부분 누구한테 배웠는지도 기억 안 날 만큼 몸에 붙은 것들입니다. 그래서 오히려 이틀짜리 과정의 목차에 들어가기 어렵다고 보고 있습니다. 하는 사람은 너무 당연해서 가르칠 거리로 안 보고, 안 해 본 사람은 이게 빠졌다는 것 자체를 모릅니다.

AI 글쓰기 수업에는 코드 리뷰에 해당하는 시간이 없습니다

현업과 거리가 멀다는 말을 하면 아이들한테 현업 수준을 요구하느냐는 반응이 먼저 나올 것 같습니다. 그런 이야기가 아닙니다. 초등학생에게 배포 파이프라인이나 장애 대응을 가르치자는 게 아닙니다. 제가 말하는 거리는 난이도가 아니라 질문의 순서입니다.

현업에서 일은 대개 남의 요구로 시작합니다. 누군가 이런 게 필요하다고 말하고, 저는 그 말을 제가 만들 수 있는 크기로 옮깁니다. 만든 건 다른 사람이 읽습니다. 코드 리뷰에서 동료가 이건 왜 이렇게 했느냐고 묻고, 저는 대답할 수 있어야 합니다. 그리고 오늘 돌아간 게 다음 달에도 돌아가야 합니다. 이 과정을 통틀어서 결국 이 코드에 이름을 거는 사람이 저라는 것, 그게 현업의 무게입니다.

아이들 수업은 순서가 반대입니다. 내가 만들고 싶은 걸 만들고, 돌아가면 끝나고, 발표하면 박수를 받습니다. 흥미를 붙이는 첫 단계로는 이게 맞습니다. 다만 그 뒤로도 계속 이 순서만 반복하면, 아이가 배우는 건 만들고 끝내는 것이고 남이 읽는 것을 전제로 만드는 건 배울 기회가 없습니다.

이것도 아이 수준으로 옮길 수 있습니다. 시작을 바꾸는 방법이 있습니다. 내가 만들고 싶은 걸 만드는 대신, 짝꿍이 이런 게 있으면 좋겠다고 말한 걸 만들어 주는 겁니다. 그러면 아이는 처음으로 남의 말을 자기가 만들 수 있는 크기로 옮겨야 합니다. 짝꿍이 말한 것 중에 애매한 게 있으면 되물어야 하고, 다 만든 뒤에는 짝꿍이 원한 게 이거 맞느냐고 확인받아야 합니다. 이 과정에서 아이는 자기가 알아들은 것과 짝꿍이 말한 것이 다를 수 있다는 걸 겪습니다. 현업에서 가장 흔한 사고가 바로 이 어긋남에서 나옵니다.

끝도 바꿀 수 있습니다. 짝꿍끼리 작품을 바꿔서 돌려 보고, 만든 사람이 말한 대로 움직이는지 확인해 주는 시간을 넣으면 됩니다. 짝꿍이 이거 왜 여기서 멈춰 하고 물었을 때 대답하는 것, 그게 초등학생 버전의 코드 리뷰입니다. AI 글쓰기라면 내가 AI로 쓴 글을 짝꿍이 읽고 이 문장 진짜야 하고 묻는 시간이 됩니다. 다음 달에도 돌아가야 한다는 것도 옮길 수 있습니다. 지난주에 만든 작품을 이번 주에 다시 열어서 기능 하나를 더 붙이게 하는 겁니다. 일주일 만에 열어 보면 아이는 자기가 만든 건데도 어디에 뭐가 있는지 헷갈립니다. 그때 처음으로 블록에 이름을 제대로 붙여 둘걸, 하는 생각을 하게 됩니다. 현업에서 코드를 읽기 좋게 쓰라는 말은 이 헷갈림을 한 번이라도 겪은 사람에게만 들립니다.

이런 시간은 새 도구도 새 예산도 필요 없습니다. 이런 시간이 수업에 있어야 한다는 걸 아는 사람이 교실에 서 있으면 됩니다.

지금 구조에서는 그런 사람이 교실에 들어가는 경로가 잘 안 보입니다. 현업 개발자가 평일 낮에 학교에 갈 방법은 많지 않고, 양성과정은 이력보다 이수로 문을 엽니다. 그래서 교실에 도착하는 건 그때그때의 도구와 그 도구로 만드는 법이고, 개발자들이 제일 오래 붙잡고 있는 확인하는 법은 도착하지 않습니다.

도구는 내년에 또 바뀔 겁니다. 그때 새로 양성될 강사들이 이번에는 결과가 맞는지 따지는 시간을 들고 교실에 들어갈 수 있을지, 저는 지금 경로로는 잘 모르겠다고 보고 있습니다.