학생이 AI에게 질문한다.
“조선 후기의 사회 변화를 쉽게 설명해 줘.”
몇 초 뒤 잘 정리된 답이 나온다.
다른 학생은 영어 수행평가를 준비하며 요청한다.
“이 글을 중학생 수준의 영어로 바꿔 줘.”
AI는 곧바로 문장을 수정한다.
수학 문제의 풀이를 물을 수도 있다.
책을 요약해 달라고 할 수도 있다.
발표 주제를 추천받고 발표 자료의 개요를 만들 수도 있다.
이미 많은 학생에게 AI는 특별한 기술이 아니다.
검색하고, 묻고, 정리하고, 번역하고, 글을 쓰는 일상적인 도구가 되어 가고 있다.
그렇다면 AI 시대의 교육은 학생들에게 AI 사용법을 알려 주는 것으로 충분할까?
좋은 프롬프트를 작성하는 방법을 가르치면 AI 교육이 완성되는 것일까?
그렇지 않다. AI에게 좋은 답을 얻는 능력은 분명 필요하다.
하지만 그것은 시작에 불과하다. 앞으로 더 중요한 능력은 다른 곳에 있다.
어떤 문제를 AI로 해결할 것인지 결정하는 능력.
그 문제를 해결하는 시스템을 설계하는 능력.
실제로 작동하는 것을 만들어 보는 능력.
결과가 정확한지 검증하는 능력.
오류가 발생했을 때 원인을 찾아 수정하는 능력.
그리고 AI를 어디까지 사용하고 어디에서 사람이 책임져야 하는지 판단하는 능력.
AI교육의 목표는 AI에게 질문을 잘하는 학생을 만드는 데서 끝나서는 안 된다.
우리가 원하는 것은 한 단계 더 나아간 모습이다.
AI를 이용해 자신의 문제를 해결하는 시스템을 설계할 수 있는 학생.
1. AI를 사용하는 것과 AI를 설계하는 것은 다르다
AI를 ‘사용한다’는 말과 ‘설계한다’는 말은 어떻게 다를까?
학생이 AI에게 말한다.
“우리 동네 관광지를 추천해 줘.”
이것은 AI를 사용하는 것이다.
그런데 학생이 이런 생각을 한다면 이야기가 달라진다.
“우리 지역을 처음 방문하는 청소년에게 취향과 이용 가능한 시간에 맞춰 장소를 추천해 주는 AI 안내 서비스를 만들 수 없을까?”
이제 새로운 질문들이 생긴다.
누가 사용할 것인가?
사용자는 무엇을 궁금해할까?
어떤 정보를 제공해야 할까?
추천 기준은 무엇이어야 할까?
지역 정보는 어디에서 가져올까?
정보가 오래되었으면 어떻게 할까?
AI가 존재하지 않는 장소를 추천하면 어떻게 할까?
학생의 개인정보는 저장해도 될까?
잘못된 추천으로 문제가 생기지 않으려면 무엇을 확인해야 할까?
어떤 경우에는 AI가 답하지 않도록 해야 할까?
이 순간 학생의 위치가 달라진다.
AI에게 답을 요청하는 사용자에서 AI가 작동하는 방식을 결정하는 설계자로 이동하게 된다.
2. 프롬프트를 잘 쓰는 것은 중요하다
AI교육에서 프롬프트를 가르치는 것이 잘못된 것은 아니다.
질문을 구체적으로 하는 능력은 중요하다.
목적을 설명하고 필요한 조건을 제시하며 원하는 결과의 형태를 분명하게 요청하면 더 유용한 답을 얻을 가능성이 높다.
예를 들어 “환경에 대해 알려 줘.” 라는 질문 보다 “우리 학교에서 학생들이 직접 조사할 수 있는 에너지 낭비 문제 다섯 가지를 제안하고, 각 문제마다 어떤 데이터를 수집하면 좋을지 설명해 줘.”
라고 묻는 것이 목적에 더 가까운 답을 얻기 쉽다.
프롬프트를 작성하는 과정 자체가 생각을 구조화하는 훈련이 될 수도 있다.
무엇을 원하는가?
조건은 무엇인가?
결과는 어떤 형태여야 하는가?
무엇을 제외해야 하는가?
하지만 여기에서 멈추면 안 된다.
AI가 발전할수록 사용자가 복잡한 명령어를 익혀야 하는 부담은 오히려 줄어들 수 있다.
자연스럽게 말해도 AI가 의도를 이해하고 필요한 질문을 다시 할 수 있기 때문이다.
따라서 특정한 프롬프트 공식만 외우게 하는 교육은 오래 지속되는 AI교육의 핵심이 되기 어렵다.
더 근본적인 능력이 필요하다.
무엇을 물어볼 것인가보다 먼저, 무엇을 해결할 것인가를 결정하는 능력이다.
3. 좋은 프롬프트보다 좋은 문제 정의가 먼저다
한 학생이 말한다.
“AI로 공부를 도와주는 앱을 만들고 싶어요.”
좋은 출발이다.
하지만 아직 문제는 정의되지 않았다.
누구의 공부를 도와주려는가?
초등학생인가?
중학생인가?
영어 단어를 외우기 어려운 학생인가?
수학에서 반복적으로 같은 실수를 하는 학생인가?
책을 읽고도 핵심 내용을 정리하기 어려운 학생인가?
무엇이 실제 문제인가?
기존 서비스로는 왜 해결되지 않는가?
사용자가 가장 불편하게 느끼는 순간은 언제인가?
이 질문에 답하기 시작하면 프로젝트의 모습이 달라진다.
예를 들어 문제를 이렇게 정의할 수 있다.
영어책을 읽기 시작한 학생들이 자신의 수준에 맞는 다음 책을 선택하기 어려워한다.
그러면 해결책도 구체적으로 생각할 수 있다.
학생이 지금까지 읽은 책을 기록한다.
관심 분야를 선택한다.
읽기 난이도와 선호 주제를 고려한다.
AI가 몇 권의 후보를 제안한다.
학생이 실제로 읽은 뒤 난이도와 만족도를 평가한다.
그 기록을 다음 추천에 반영한다.
이제 ‘AI 공부 앱 만들기’라는 막연한 아이디어가 해결해야 할 구체적인 문제로 바뀌었다.
AI 프로젝트의 첫 번째 단계는 AI를 켜는 것이 아니다.
문제를 관찰하고 정의하는 것이다.
4. 문제 정의에는 사람이 먼저 필요하다
AI에게 이렇게 물어볼 수도 있다.
“학생들이 겪는 문제를 열 가지 알려 줘.”
AI는 순식간에 목록을 만들어 줄 것이다.
하지만 그 목록에 있다고 실제 문제가 되는 것은 아니다.
학생을 만나서 관찰하고 질문해야 한다. 필요하면 설문조사를 해야 할 수도 있다 .
기존에 어떤 방법을 사용하는지도 알아봐야 한다.
예를 들어 학생들이 독서 기록을 잘 남기지 않는다고 하자.
처음에는 이렇게 생각할 수 있다.
‘독서 기록을 자동으로 작성해 주는 AI가 필요하다.’
하지만 실제 학생과 이야기해 보니 다른 문제가 있을 수 있다.
기록 방법이 복잡해서 또는 책을 읽은 직후 무엇을 써야 할지 몰라서 미루는 것일 수도 있다.
어떤 경우에는 자신의 생각을 글로 표현하는 것이 어려울 수도 있다.
그렇다면 AI가 기록을 대신 작성하는 것이 최선의 해결책은 아니다.
오히려 학생에게 짧은 질문을 하나씩 던지고 학생의 답을 정리해 주는 시스템이 더 적절할 수 있다.
좋은 AI 프로젝트는 기술에서 출발하지 않는다.
사람과 문제에서 출발한다.
5. 모든 문제에 AI가 필요한 것은 아니다
AI교육에서 반드시 가르쳐야 할 질문이 하나 있다.
“이 문제에 정말 AI가 필요한가?”
간단한 계산이면 계산기가 더 적절할 수 있다.
정해진 시간에 알림을 보내는 일이라면 일반적인 자동화 기능으로 충분할 수 있다.
자료를 정해진 순서대로 저장하는 일이라면 AI보다 단순한 규칙 기반 프로그램이 더 안정적일 수 있다.
AI를 넣었다고 더 좋은 프로젝트가 되는 것은 아니다.
오히려 필요하지 않은 곳에 AI를 사용하면 시스템이 복잡해지고 오류 가능성이 커질 수 있다.
따라서 학생에게 이런 질문을 하게 해야 한다.
AI가 필요한 이유는 무엇인가?
AI가 하지 않아도 되는 부분은 무엇인가?
규칙으로 처리할 수 있는 부분은 무엇인가?
사람이 판단해야 하는 부분은 무엇인가?
이 질문을 할 수 있는 학생이 AI를 더 책임 있게 사용할 수 있다.
AI를 사용할 줄 아는 능력만큼 AI를 사용하지 않아도 되는 순간을 판단하는 능력도 중요하다.
6. AI 에이전트란 무엇인가
생성형 AI를 처음 접하면 우리는 대화창을 떠올린다.
질문을 입력한다. 답변을 받는다. 다시 질문한다.
하지만 AI를 실제 문제 해결에 활용하려면 대화창보다 조금 더 넓게 볼 필요가 있다.
예를 들어 학생을 위한 ‘독서 코치’를 만든다고 생각해 보자.
학생이 책을 읽고 내용을 입력한다.
AI가 질문을 한다.
학생이 답한다.
AI가 답변을 정리한다.
이전 독서 기록을 참고한다.
학생의 관심 분야와 읽기 수준을 고려한다.
다음 활동을 제안한다.
필요하면 기록을 데이터베이스에 저장한다.
이제 AI는 한 번 답하고 끝나는 것이 아니라 목표를 위해 여러 정보와 도구를 연결해 일련의 작업을 수행하는 시스템의 일부가 된다.
이 책에서는 학생들이 이해하기 쉽게 이런 구조를 AI 에이전트의 기본적인 모습으로 생각해 보려고 한다.
중요한 것은 어려운 용어를 외우는 것이 아니다.
학생이 이런 질문을 할 수 있어야 한다.
무엇을 입력받는가?
무엇을 판단해야 하는가?
어떤 정보가 필요한가?
어떤 도구를 사용할 것인가?
무엇을 출력할 것인가?
어디에서 사람의 확인이 필요한가?
7. AI 에이전트는 여섯 가지 질문으로 시작할 수 있다
처음 AI 에이전트를 설계하는 학생에게 복잡한 기술 구조부터 설명할 필요는 없다.
여섯 가지 질문에서 시작할 수 있다.
첫째, 누구를 위한 것인가? : 사용자를 정한다.
둘째, 어떤 문제를 해결하는가? : 문제를 한 문장으로 정의한다.
셋째, 어떤 정보를 받아야 하는가? : 사용자의 질문, 문서, 사진, 선택 항목, 기존 기록 등이 될 수 있다.
넷째, AI는 무엇을 해야 하는가?
분류하는가? 요약하는가? 추천하는가? 질문하는가? 비교하는가?
다섯째, 어떤 도구나 정보와 연결해야 하는가?
검색 자료. 문서. 스프레드시트. 데이터베이스. 캘린더. 메시지 도구. 다른 프로그램 등이 될 수 있다.
여섯째, 마지막에는 누가 확인하는가?
AI의 결과를 그대로 사용할 것인가? 학생이 검토할 것인가? 교사나 담당자가 승인해야 하는가?
이 여섯 질문만 제대로 답해도 학생은 이미 단순한 AI 사용자에서 시스템 설계자로 이동하기 시작한다.
8. 입력-판단-행동-기록의 구조로 생각해 보자
AI 에이전트의 구조를 더 단순하게 표현하면 다음과 같이 볼 수 있다.
입력 → 판단 → 행동 → 기록
예를 들어 ‘학습 코치 에이전트’를 생각해 보자.
입력 : 학생이 오늘 공부한 내용과 어려웠던 부분을 입력한다.
판단 : AI가 기록을 읽고 학생이 반복적으로 어려워하는 부분을 찾는다.
행동 : 복습 질문이나 다음 학습 과제를 제안한다.
기록 : 학생의 답변과 학습 결과를 다시 저장한다.
그리고 다음 학습에서는 이전 기록을 참고한다.
여기에 필요에 따라 사람이 개입한다.
학생의 학습 문제가 단순한 연습 부족인지, 개념 자체의 이해 부족인지 AI의 판단만으로 결정하기 어려울 수 있다.
이때 코치가 기록을 보고 다음 과제를 조정한다.
따라서 실제 시스템은 이렇게 표현하는 것이 더 정확하다.
입력 → AI의 판단 → 도구를 이용한 행동 → 결과 기록 → 사람의 확인 → 다음 행동
학생이 이 구조를 이해하면 AI를 단순한 ‘말 잘하는 기계’가 아니라 정보와 행동을 연결하는 시스템의 한 부분으로 보기 시작한다.
9. 먼저 종이에 설계해도 된다
AI 프로젝트라고 하면 바로 컴퓨터부터 켜야 할 것 같지만 그렇지 않다.
처음에는 종이 한 장이면 충분하다.
가운데 사용자를 그린다.
사용자가 무엇을 입력하는지 적는다.
AI가 해야 할 일을 적는다.
필요한 정보가 어디에서 오는지 연결한다.
결과가 어디로 가는지도 표시한다.
오류가 발생할 수 있는 지점을 표시한다.
사람이 확인해야 하는 부분에는 별표를 한다.
이것만으로도 훌륭한 첫 번째 설계도가 된다.
학생은 이 과정에서 시스템을 눈으로 볼 수 있게 된다.
코딩을 시작하기 전에 생각을 구조화하는 것이다.
만들기 전에 그려 보는 습관은 복잡한 시스템을 설계하는 데 매우 중요하다.
10. 처음부터 코딩을 잘해야 하는 것은 아니다
AI 프로젝트를 이야기하면 학생이나 학부모가 걱정할 수 있다.
“코딩을 잘해야 가능한 것 아닌가요?”
반드시 그렇지는 않다.
오늘날에는 화면에서 여러 기능을 연결하는 방식으로 프로그램과 자동화를 만드는 도구가 많다.
학생은 상자를 연결하듯 작업의 흐름을 구성할 수 있다.
예를 들어 다음과 같은 흐름을 생각할 수 있다.
신청서가 들어온다.
↓
내용을 AI가 분류한다.
↓
결과를 표에 저장한다.
↓
담당자에게 알린다.
↓
담당자가 확인한다.
학생은 복잡한 코드를 작성하지 않더라도 시스템의 구조를 이해할 수 있다.
이런 노코드 또는 로우코드 도구는 기술적 장벽을 낮춰 준다.
특히 처음 프로젝트를 시작하는 학생에게는 아이디어를 빠르게 작동하는 형태로 만들어 보는 경험을 제공한다.
11. 노코드는 ‘쉬운 코딩’이 아니라 시스템 사고의 도구다
노코드 도구의 교육적 가치를 단순히 ‘코딩을 몰라도 프로그램을 만들 수 있다’는 데서만 찾을 필요는 없다.
더 중요한 것은 시스템의 흐름을 눈으로 볼 수 있다는 점이다.
어디에서 데이터가 들어오는가?
어떤 조건에서 다음 단계로 이동하는가?
AI는 어느 단계에서 사용되는가?
결과는 어디에 저장되는가?
오류가 발생하면 어디에서 멈추는가?
사람의 승인은 어디에 들어가는가?
학생은 이러한 흐름을 연결하면서 자연스럽게 시스템을 생각하게 된다.
이것은 다음 장에서 다룰 자동화 교육과도 연결된다.
AI 시대에 중요한 것은 특정 프로그램의 버튼 위치를 외우는 것이 아니다.
일이 어떤 단계로 이루어지고, 어떤 단계는 자동화할 수 있으며, 어디에서 사람의 판단이 필요한지를 볼 수 있는 능력이다.
12. 그렇다면 코딩은 필요하지 않을까
노코드 도구가 발전한다고 코딩의 가치가 사라지는 것은 아니다.
오히려 학생이 더 복잡한 것을 만들고 싶어질수록 코딩의 필요성을 자연스럽게 느낄 수 있다.
처음에는 노코드로 만들 수 있다.
그러다 원하는 기능이 지원되지 않는 상황을 만난다.
데이터를 특별한 방식으로 처리해야 할 수도 있다.
다른 서비스와 연결해야 할 수도 있다.
더 세밀한 조건을 설정하고 싶을 수도 있다.
그때 간단한 코드를 배우면 된다.
이런 방식의 코딩 학습에는 분명한 목적이 있다.
“프로그래밍 문법을 외워야 하니까.” 가 아니라
“내가 만들고 싶은 기능을 구현하려면 이것이 필요하니까.” 배우는 것이다.
노코드와 코딩을 서로 경쟁시키지 않아도 된다.
노코드로 빠르게 구조를 만들고 필요한 부분에서 코드를 추가할 수 있다.
중요한 것은 도구가 아니라 문제를 해결하는 능력이다.
13. AI에게 코딩을 맡겨도 될까
AI는 코드 작성도 도와줄 수 있다.
학생이 원하는 기능을 설명하면 예제 코드를 만들어 줄 수 있다.
오류 메시지를 보여 주면 원인을 설명하기도 한다.
기존 코드를 수정하는 데 도움을 줄 수도 있다.
그렇다면 학생은 코딩을 몰라도 되는 것일까?
여기에도 같은 원칙이 적용된다.
AI가 만들어 주었다고 해서 학생의 결과물이 되는 것은 아니다.
학생은 최소한 다음 질문에 답할 수 있어야 한다.
이 코드는 무엇을 하는가?
어떤 입력을 받는가?
어떤 결과를 만드는가?
어디에서 오류가 발생할 수 있는가?
수정하려면 어느 부분을 살펴봐야 하는가?
AI가 만든 코드를 실행했더니 오류가 났을 때 그대로 다시 AI에게 맡기는 것만 반복한다면 학생의 역량은 제한적이다.
반대로 코드를 한 줄 한 줄 완벽하게 작성하지 못하더라도 구조를 이해하고, 테스트하고, 오류를 찾아 수정 방향을 판단할 수 있다면 훨씬 의미 있는 학습이 된다.
AI 시대의 코딩 교육 역시 모든 것을 직접 타이핑하는 능력에서 시스템을 이해하고 검증하는 능력으로 범위가 넓어져야 한다.
14. 첫 번째 목표는 완제품이 아니라 시제품이다
학생 프로젝트에서 흔히 나타나는 문제가 있다.
처음부터 너무 큰 것을 만들려고 한다.
“전국의 청소년에게 진로를 추천해 주는 AI를 만들겠습니다.”
“모든 과목을 가르쳐 주는 AI 선생님을 만들겠습니다.”
“우리 도시 전체의 관광 서비스를 만들겠습니다.”
아이디어는 좋지만 처음부터 완성하기에는 너무 크다.
그래서 프로젝트에서는 시제품, 즉 프로토타입이 중요하다.
모든 기능을 구현할 필요가 없다.
핵심 기능 하나가 작동하면 된다.
예를 들어 진로 AI라면 처음에는
학생이 관심 분야 세 가지를 입력한다.
↓
AI가 관련 직업을 몇 개 제안한다.
↓
왜 추천했는지 설명한다.
↓
학생이 추천의 적절성을 평가한다.
이 정도로 시작할 수 있다.
그다음 실제 사용자를 만나 본다.
추천이 도움이 되었는가?
엉뚱한 추천은 없었는가?
어떤 정보가 더 필요했는가?
사용자는 무엇을 불편해했는가?
이 피드백을 받아 두 번째 버전을 만든다.
작게 만들고 빨리 확인하는 것.
이것이 학생 프로젝트에서도 중요한 원칙이다.
15. 작동한다는 것과 잘 작동한다는 것은 다르다
학생이 버튼을 누른다.
AI가 답한다.
“됐다!”
물론 중요한 순간이다.
하지만 프로젝트는 여기에서 끝나지 않는다.
작동한다는 것과 잘 작동한다는 것은 다르다.
열 번 질문하면 열 번 모두 적절하게 답하는가?
표현을 조금 바꾸어도 이해하는가?
잘못된 정보를 입력하면 어떻게 되는가?
답을 모를 때도 아는 것처럼 말하지는 않는가?
사용자가 예상하지 못한 질문을 하면 어떻게 되는가?
필요한 경우 답변을 거절할 수 있는가?
다른 사용자가 사용해도 이해하기 쉬운가?
이 질문을 확인하는 과정이 테스트다.
AI 프로젝트에서 테스트는 부가적인 일이 아니라 설계의 일부다.
16. 실패하는 사례를 일부러 찾아보자
학생들은 자신이 만든 것이 잘 작동하는 모습을 보여 주고 싶어 한다.
발표에서도 성공한 장면을 보여 주는 것이 자연스럽다.
하지만 진짜 개발 과정에서는 반대의 태도도 필요하다.
“어떻게 하면 이것이 실패할까?” 를 찾아보는 것이다.
예를 들어 관광 안내 AI라면 일부러 애매한 질문을 해 본다.
존재하지 않는 장소를 물어보거나 오래된 정보를 넣어 본다.
조건이 서로 충돌하는 요청을 해 보거나 필요한 정보가 빠진 질문도 해 보고 그 결과를 기록한다.
어떤 상황에서 잘못된 답을 하는가?
어떤 정보가 부족한가?
프롬프트를 바꾸면 개선되는가?
자료를 추가해야 하는가?
사람의 확인 단계가 필요한가?
학생이 자신의 시스템을 무너뜨려 보려는 순간 프로젝트의 수준은 한 단계 올라간다.
좋은 개발자는 성공 사례만 찾지 않는다.
실패할 조건을 찾아 시스템을 더 강하게 만든다.
17. 오류는 감점의 이유가 아니라 학습 자료다
학교에서는 오류를 줄여야 할 것으로 생각하기 쉽다.
시험에서 틀리면 점수를 잃기 때문이다.
하지만 제작 프로젝트에서 오류는 매우 중요한 자료다.
왜 잘못되었는가?
입력의 문제인가?
자료의 문제인가?
AI 모델의 한계인가?
설계한 규칙의 문제인가?
다른 프로그램과 연결하는 과정에서 문제가 생겼는가?
사용 방법이 불분명했는가?
학생이 오류를 분류하고 원인을 찾으면 시스템에 대한 이해가 깊어진다.
그래서 프로젝트 기록에는 성공한 결과만 남겨서는 안 된다.
오류 기록표를 만들 수 있다.
발생한 문제.
발생 조건.
예상했던 결과.
실제 결과.
추정 원인.
수정 방법.
수정 후 결과.
이 기록은 완벽하게 작동하는 최종 화면보다 학생의 문제 해결 능력을 더 잘 보여 줄 때가 있다.
과정에서의 오류를 실패로 받아들이는 생각습관을 바꿔야 한다 .
18. AI의 답은 왜 검증해야 할까
AI가 자신 있게 말한다고 사실이라는 뜻은 아니다.
잘못된 정보를 제공할 수 있다.
오래된 정보를 사용할 수도 있다.
출처가 불분명한 내용을 그럴듯하게 정리할 수도 있다.
질문의 맥락을 잘못 이해할 수도 있다.
따라서 AI교육에는 반드시 검증하는 습관이 포함되어야 한다.
학생은 물어야 한다.
이 정보의 출처는 무엇인가?
원자료를 확인할 수 있는가?
다른 자료와 일치하는가?
언제 만들어진 정보인가?
숫자는 정확한가?
AI가 제시한 출처가 실제로 존재하는가?
전문적인 판단이 필요한 내용은 누구에게 확인해야 하는가?
AI 시대에는 답을 만들어 내는 능력만큼 답을 의심하고 확인하는 능력이 중요하다.
19. 사실 확인만으로 충분하지 않다
검증은 정보의 사실 여부만 확인하는 일이 아니다.
추천 시스템을 만든다고 생각해 보자.
AI가 실제 존재하는 책만 추천한다.
정보도 정확하다.
그렇다고 좋은 시스템이라고 말할 수 있을까?
특정 종류의 책만 반복해서 추천할 수도 있다.
학생의 관심을 지나치게 단순하게 해석할 수도 있다.
추천 이유가 불분명할 수도 있다.
사용자가 원하지 않는 개인정보를 요구할 수도 있다.
따라서 검증에는 여러 관점이 필요하다.
정확한가?
유용한가?
일관되게 작동하는가?
사용자가 이해할 수 있는가?
누군가에게 불리하게 작동하지 않는가?
불필요한 정보를 수집하지 않는가?
문제가 생겼을 때 사람이 개입할 수 있는가?
AI 시스템의 품질은 정답률 하나로 설명하기 어렵다.
20. 개인정보는 프로젝트의 마지막에 생각하는 문제가 아니다
학생이 AI 서비스를 만들면서 사용자의 이름, 나이, 학교, 관심 분야 등을 입력받는다고 하자.
기술적으로는 쉽게 만들 수 있다.
하지만 먼저 물어야 한다.
이 정보가 정말 필요한가?
저장해야 하는가?
얼마 동안 보관해야 하는가?
누가 볼 수 있는가?
외부 서비스로 전달되는가?
삭제할 수 있는가?
특히 다른 사람의 정보를 다루는 프로젝트에서는 더욱 조심해야 한다.
학생들에게 개인정보 보호를 긴 약관으로만 가르칠 필요는 없다.
간단한 원칙에서 시작할 수 있다.
필요하지 않은 정보는 받지 않는다.
받은 정보는 함부로 공유하지 않는다.
왜 필요한지 설명할 수 없는 정보는 수집하지 않는다.
민감한 판단을 AI에게 함부로 맡기지 않는다.
기술을 만들기 시작할 때부터 이런 질문을 포함해야 한다.
책임 있는 AI는 완성된 제품에 윤리 항목을 마지막으로 붙이는 일이 아니다.
설계의 처음부터 책임을 포함시키는 것이다.
21. 저작권과 출처도 설계의 일부다
AI를 사용하면 이미지와 글, 음악, 코드, 자료를 쉽게 만들거나 변형할 수 있다.
학생 프로젝트에서는 그만큼 출처와 저작권에 대한 감각도 필요하다.
인터넷에서 찾았다고 자유롭게 사용할 수 있는가?
AI가 만들어 준 내용에 다른 사람의 저작물이 포함될 가능성은 없는가?
원문을 지나치게 그대로 사용하고 있지는 않은가?
사용한 자료의 출처를 밝혀야 하는가?
공개된 프로젝트라면 사용할 수 있는 자료의 조건은 무엇인가?
학생에게 모든 법률적 세부사항을 가르칠 필요는 없다.
하지만 기본적인 습관은 만들 수 있다.
자료의 출처를 기록한다.
다른 사람의 결과물을 자신의 것처럼 제시하지 않는다.
사용 조건을 확인한다.
AI가 만든 결과도 그대로 믿거나 그대로 제출하지 않는다.
필요한 경우 교육자나 전문가에게 확인한다.
AI 시대에는 만드는 능력과 함께 어디에서 가져왔고 어떻게 사용했는지 설명할 수 있는 능력도 중요하다.
22. 마지막 판단을 AI에게 넘기지 않는 구조
AI가 매우 편리해질수록 중요한 질문이 있다.
“마지막 결정은 누가 하는가?”
책 추천처럼 비교적 위험이 낮은 활동에서는 AI가 여러 선택지를 제시하고 사용자가 결정할 수 있다.
하지만 학생을 평가하거나 중요한 지원 대상을 결정하는 것처럼 사람에게 큰 영향을 줄 수 있는 판단이라면 이야기가 달라진다.
AI의 결과만으로 결정해서는 안 되는 영역이 있다.
그래서 학생의 AI 프로젝트에도 ‘사람의 확인’이라는 개념을 넣을 필요가 있다.
AI가 초안을 만든다.
사람이 확인한다.
필요하면 수정한다.
최종 결정은 책임 있는 사람이 한다.
학생들은 여기에서 중요한 원리를 배운다.
자동화할 수 있다는 것과 자동화해야 한다는 것은 다르다.
23. 학생이 만들 수 있는 첫 번째 AI 에이전트
처음부터 거대한 서비스를 만들 필요는 없다.
학생의 생활에서 작은 문제를 찾으면 된다.
예를 들어 다음과 같은 프로젝트를 생각해 볼 수 있다.
독서 질문 코치
읽은 책을 입력하면 정답을 알려 주는 대신 학생에게 생각할 질문을 던진다.
영어 독서 도우미
학생의 수준과 관심 분야를 바탕으로 읽을 자료의 후보를 정리하고 읽은 뒤 이해 질문을 제공한다.
수학 오류 분석 도우미
학생이 자신의 풀이와 오류를 입력하면 바로 정답부터 알려 주지 않고 어느 단계부터 다시 확인해야 하는지 질문한다.
프로젝트 코치
학생이 목표와 진행 상황을 기록하면 다음에 확인해야 할 일을 질문한다.
지역 탐방 안내 도우미
검증된 지역 자료를 바탕으로 사용자의 관심에 맞는 탐방 정보를 제공한다.
청소년 기자 취재 도우미
취재 주제를 입력하면 조사할 자료, 확인할 사실, 인터뷰 질문의 초안을 제안한다.
공통점이 있다.
AI가 학생의 생각을 대신하는 것이 아니라 학생의 생각과 행동을 촉진하도록 설계한다는 것이다.
24. 하나의 프로젝트는 이렇게 진행할 수 있다
AI 프로젝트를 일정한 흐름으로 정리하면 다음과 같다.
1단계 — 관찰
내 주변에서 불편하거나 반복되는 문제를 찾는다.
2단계 — 문제 정의
누가 어떤 상황에서 어떤 어려움을 겪는지 한 문장으로 정리한다.
3단계 — 사용자 확인
실제 사용자가 같은 문제를 느끼는지 확인한다.
4단계 — 해결 방법 비교
AI가 필요한지, 더 단순한 방법은 없는지 검토한다.
5단계 — 시스템 설계
입력, 판단, 행동, 기록, 사람의 확인 과정을 그린다.
6단계 — 시제품 제작
노코드 도구나 간단한 코딩으로 핵심 기능을 구현한다.
7단계 — 테스트
정상적인 상황과 실패할 가능성이 있는 상황을 함께 시험한다.
8단계 — 오류 분석
무엇이 왜 잘못되었는지 기록한다.
9단계 — 개선
설계, 자료, 프롬프트, 코드, 사용자 경험을 수정한다.
10단계 — 책임 검토
개인정보, 출처, 저작권, 편향, 사람의 최종 판단 여부를 확인한다.
11단계 — 사용자 피드백
실제 사용자에게 사용하게 하고 의견을 받는다.
12단계 — 발표와 성찰
무엇을 만들었는지만이 아니라 무엇을 실패했고 어떻게 개선했는지 설명한다.
이 과정이 하나의 AI 프로젝트가 된다.
25. 결과물보다 과정의 증거를 남겨야 한다
AI를 사용하면 결과물이 매우 빠르게 만들어질 수 있다.
잘 정리된 보고서.
멋진 이미지.
작동하는 프로그램.
그럴수록 교육자는 결과물만 보고 학생의 역량을 판단하기 어려워진다.
AI가 대부분 만들어 준 것인지 학생이 실제로 설계한 것인지 구별하기 어렵기 때문이다.
그래서 AI 프로젝트에서는 과정의 증거가 중요하다.
최초의 문제 정의.
사용자 인터뷰 기록.
초기 설계도.
첫 번째 시제품.
사용한 프롬프트와 수정 과정.
코드 또는 노코드 작업 흐름.
테스트 사례.
오류 기록.
사용자 피드백.
수정 전후의 비교.
개인정보와 저작권 검토.
최종 성찰.
이 자료들이 남아 있으면 학생이 무엇을 실제로 생각하고 결정했는지 볼 수 있다.
AI 시대에는 결과물이 쉽게 만들어질수록 과정을 설명하는 능력의 가치가 커진다.
26. 발표할 때 ‘무엇을 만들었는가’만 묻지 말자
AI 프로젝트 발표에서는 질문도 달라져야 한다.
“무엇을 만들었니?” 에서 끝나지 않는다.
“왜 이 문제를 선택했니?”
“누구의 문제인가?”
“처음 생각했던 문제와 실제 문제가 같았니?”
“왜 AI를 사용했니?”
“AI를 사용하지 않은 부분은 어디니?”
“가장 많이 실패한 부분은 무엇이니?”
“어떤 테스트에서 문제가 발견되었니?”
“사용자의 피드백을 받고 무엇을 바꾸었니?”
“AI가 틀렸을 때 어떻게 확인했니?”
“개인정보는 어떻게 다루었니?”
“다시 만든다면 무엇을 바꾸고 싶니?”
학생이 이 질문에 자신의 말로 답할 수 있다면 결과물의 화려함과 관계없이 많은 것을 배운 것이다.
27. AI 프로젝트의 난이도도 학생마다 달라질 수 있다
7장에서 살펴본 개인 맞춤형 교육의 원칙은 AI 프로젝트에도 그대로 적용된다.
탐색자 Explorer
주어진 문제를 이해한다.
간단한 AI 기능을 사용해 본다.
교육자가 제공한 구조를 따라 작은 시제품을 만든다.
기본적인 테스트를 한다.
AI의 답이 틀릴 수 있다는 것을 이해한다.
실행자 Builder
자신의 문제를 정의한다.
필요한 기능을 설계한다.
노코드 도구나 간단한 코딩을 이용해 시제품을 만든다.
여러 테스트 사례를 설계한다.
오류를 찾아 수정한다.
사용자의 의견을 반영한다.
혁신가 Innovator
실제 사용자의 문제를 조사한다.
여러 도구와 데이터를 연결한다.
더 복잡한 에이전트나 자동화 시스템을 설계한다.
성능과 한계를 체계적으로 검증한다.
개인정보, 편향, 저작권, 사회적 영향까지 고려한다.
실제 사용자에게 적용하고 지속적으로 개선한다.
중요한 것은 어떤 도구를 사용했는지가 아니다.
얼마나 독립적으로 문제를 정의하고 설계하고 검증할 수 있는가다.
28. AI 역량을 무엇으로 평가할 것인가
AI 활용 역량을 ‘프롬프트를 잘 작성하는가’만으로 평가해서는 부족하다.
더 넓은 기준이 필요하다.
예를 들어 다음과 같은 항목을 볼 수 있다.
문제 정의
해결하려는 문제와 사용자가 분명한가?
설계
입력, 판단, 행동, 결과의 흐름을 설명할 수 있는가?
도구 선택
AI가 필요한 이유를 설명할 수 있는가?
제작
작동하는 시제품을 만들었는가?
검증
다양한 조건으로 테스트했는가?
오류 수정
실패 원인을 찾고 개선했는가?
사용자 관점
실제 사용자의 피드백을 반영했는가?
책임
개인정보, 출처, 저작권, 편향과 사람의 최종 판단을 고려했는가?
설명
자신의 선택과 과정을 자신의 말로 설명할 수 있는가?
이런 기준을 사용하면 AI교육은 특정 도구의 사용법을 배우는 수업에서 종합적인 문제 해결 교육으로 발전한다.
29. ‘AI Agent Builder’ 배지는 무엇을 증명해야 할까
학생이 AI 프로젝트 수업을 수료했다는 이유만으로 역량 배지를 주어서는 안 된다.
예를 들어 ‘AI Agent Builder’ 배지를 만든다면 최소한 다음과 같은 증거가 필요하다.
실제 문제를 정의했다.
사용자를 설정했다.
AI가 필요한 이유를 설명했다.
시스템의 흐름을 설계했다.
작동하는 시제품을 만들었다.
테스트 사례를 작성했다.
오류를 발견하고 수정했다.
AI 결과를 검증했다.
개인정보와 출처 문제를 검토했다.
사용자의 피드백을 받았다.
자신의 설계와 한계를 설명했다.
그리고 이 책에서 제시하는 공통 원칙을 적용한다.
성취도 80% 이상.
성실도 90% 이상.
두 조건을 모두 충족해야 한다.
배지가 증명해야 하는 것은 “AI 수업을 들었습니다.” 가 아니다.
“저는 문제를 정의하고 AI를 활용한 해결 시스템을 설계하고, 시제품을 만들고, 검증하고, 개선할 수 있습니다.”
여야 한다.
30. AI 시대에는 완성품보다 성장 과정이 더 중요해질 수 있다
앞으로 AI가 발전하면 학생들이 만들 수 있는 결과물의 수준은 빠르게 높아질 것이다.
중학생도 이전에는 전문 개발자가 해야 했던 일을 일부 수행할 수 있다.
웹페이지를 만들 수 있다.
프로그램을 만들 수 있다.
영상을 만들 수 있다.
데이터를 분석할 수 있다.
AI 에이전트를 만들 수도 있다.
이것은 놀라운 기회다.
동시에 교육에는 새로운 문제가 생긴다.
결과물이 훌륭하다는 사실만으로 학생의 능력을 판단하기 어려워진다.
누가 무엇을 했는가?
학생은 어떤 판단을 했는가?
어디까지 이해하고 있는가?
AI의 제안을 왜 받아들였는가?
왜 거절했는가?
어떤 오류를 발견했는가?
무엇을 수정했는가?
이 질문이 중요해진다.
그래서 AI 시대의 포트폴리오는 완성품 전시장만 되어서는 안 된다.
생각과 판단과 실패와 수정의 기록이 함께 있어야 한다.
31. AI를 설계한다는 것은 결국 책임을 설계하는 일이다
AI 시스템을 만들다 보면 학생은 기술보다 더 큰 질문을 만나게 된다.
AI에게 어디까지 맡길 것인가?
어떤 정보는 사용하지 않을 것인가?
잘못된 결과가 나오면 누가 확인할 것인가?
사용자에게 AI가 사용되고 있다는 사실을 알려야 하는가?
사람에게 영향을 주는 중요한 판단을 자동화해도 되는가?
편리함과 개인정보 보호가 충돌하면 무엇을 선택할 것인가?
이 질문에는 하나의 정답이 없을 수 있다.
그래서 더 중요하다.
AI교육은 학생에게 새로운 기술을 빨리 사용하게 하는 교육만이어서는 안 된다.
기술을 사용할 때 어떤 책임이 따라오는지 생각하게 하는 교육이어야 한다.
학생이 자신의 시스템에
‘여기에서는 사람이 확인해야 한다.’
라고 표시할 수 있다면 그것도 훌륭한 설계 능력이다.
모든 것을 자동화하는 사람이 가장 뛰어난 설계자는 아니다.
자동화해서는 안 되는 부분을 알아보는 사람도 좋은 설계자다.
제8장을 마치며
질문하는 아이에서 설계하는 아이로
AI 시대에 가장 쉽게 할 수 있는 일 가운데 하나는 답을 얻는 것이다.
질문을 입력하면 답이 나온다.
글을 요청하면 글이 나온다.
그림을 요청하면 이미지가 만들어진다.
코드를 요청하면 프로그램의 초안도 나온다.
그래서 역설적으로 교육은 답을 얻는 능력보다 답을 얻기 전에 해야 하는 일에 더 주목해야 한다.
무엇이 문제인가?
누구의 문제인가?
왜 해결해야 하는가?
AI가 필요한가?
어떤 정보를 사용해야 하는가?
어떤 과정을 자동화할 것인가?
어디에서 사람이 판단해야 하는가?
결과가 틀렸다는 것을 어떻게 알 수 있는가?
실패하면 무엇을 바꿀 것인가?
누가 결과에 책임을 져야 하는가?
이 질문에 답하면서 학생은 AI 사용자에서 설계자로 이동한다.
그래서 AI교육의 성장 과정을 다음과 같이 생각해 볼 수 있다.
AI에게 질문한다.
↓
AI와 함께 탐구한다.
↓
문제를 발견한다.
↓
문제를 정의한다.
↓
해결 구조를 설계한다.
↓
AI와 다른 도구를 연결한다.
↓
작은 시제품을 만든다.
↓
실제로 테스트한다.
↓
오류를 발견한다.
↓
수정하고 다시 테스트한다.
↓
사람과 사회에 미칠 영향을 검토한다.
↓
실제 문제 해결에 적용한다.
여기에서 중요한 변화가 일어난다.
학생은 더 이상 AI에게 “무엇을 만들어 줘.” 라고 요청하는 데 머물지 않는다.
대신 이렇게 생각하기 시작한다.
“내가 해결하려는 문제는 무엇이지?”
“이 문제를 해결하려면 어떤 시스템이 필요하지?”
“그중에서 AI는 어떤 역할을 해야 하지?”
“내가 직접 결정해야 하는 것은 무엇이지?”
이것이 AI 시대에 필요한 설계자의 사고다.
그리고 이런 경험을 한 학생에게 코딩은 시험 과목이 아니라 필요한 것을 만드는 도구가 된다.
수학은 데이터를 이해하고 시스템을 검증하는 도구가 된다.
영어는 더 넓은 자료와 기술에 접근하는 도구가 된다.
교과서에서 배운 사회와 과학의 지식은 해결할 문제를 이해하는 배경이 된다.
앞 장들에서 배웠던 지식과 역량이 이곳에서 하나로 만난다.
읽고, 질문하고, 생각하고, 만들고, 실행한다.
그리고 그 과정에서 자신의 성장을 증명한다.
하지만 하나의 AI 에이전트를 만드는 것보다 더 넓은 세계가 있다.
우리의 일상에는 수많은 반복 업무가 있다.
신청서를 받고 정리한다.
자료를 분류한다.
일정을 확인한다.
필요한 사람에게 알림을 보낸다.
기록을 남긴다.
다시 다음 업무를 시작한다.
이런 일의 흐름을 관찰하기 시작하면 학생은 새로운 것을 발견한다.
일에는 구조가 있다는 사실이다.
그리고 구조를 이해하면 그중 일부를 자동화할 수 있다.
다음 장에서는 AI를 하나의 대화 도구에서 일의 흐름을 바꾸는 도구로 확장한다.
제9장, 반복 업무를 자동화하면 시스템이 보인다.