@pblsketch

전국모 회지 《함께 여는 국어교육》 2023 겨울호(152호)에 있는 인터뷰글, '삶의 저자로 거듭나는 글쓰기 수업'을 다시 읽었다. 존경하는 이누리 선생님이 김제식, 김진해, 송동철, 탁동철 선생님에게 학생들과 '나를 만나는 글쓰기 수업'을 하는 이야기를 듣고 정리한 글이다. AI로 글을 쓰고, AI로 그 글을 평가하는 것이 점점 보편적인 일이 되어 가는 지금, 왜 여전히 학교에서 학생들과 글쓰기를 해야 하는지, 교사는 어떤 마음으로 학생 글을 읽어야 하는지 생각해 볼 수 있었다. 학생들이 삶의 저자가 되기 위해서는 학생들이 가진 '저자성'을 살려줘야 한다. 저자성을 살린다는 것은 '내가 왜 글을 써야 하는가?'를 머리와 몸으로 이해할 수 있도록 돕는다는 말이다. 글을 쓰며 나와 연결되고, 세상과 연결되도록 해야 한다. 세상과 연결된 저자에게는 머뭇거림, 멈춤이 있다. 교사는 학생들의 글을 읽는 첫 번째 독자가 되어 주어야 한다. 서논술형 평가를 본격 도입하며 교사의 업무 부담을 줄이기 위해 AI 채점 도구를 활용할 거라는 계획이 교육부와 교육청이 펴 낸 관련 문서들에 들어 있다. 글쓰기를 새로운 줄 세우기 도구로 생각하기 때문이다. 장담컨데, 정책을 이런 방향으로 추진하는 순간 학생들은 글쓰기를, 언어로 세상과 연결되기를 귀찮아하고 증오하는 시민이 될 것이다. 전국모 회지 글에서 기억하고 싶은 구절들을 옮겨 본다. "세상과 타인이 온통 나와 무관하게 흘러간다고 여기는 단절감이 아이들을 무기력하게 하거나 공격적으로 만듭니다. 그런데 글쓰기는 자아와 세계와의 연결감을 느끼게 해 주지요. 예컨대 벚나무 가지에 비닐이 걸려 있는 하찮은 일이라도, 그것에 감응하는 내 마음을 들여다보고 글로 써낼 수 있으면, 내가 '지금 여기에 닿아 있는 인간'이고 세상이 결코 나와 관계없이 흘러가지 않는다는 것을 알게 됩니다."(탁동철 선생님) "솔직함에 앞서 글 쓰는 아이들의 존엄을 지켜 줘야 한다고 생각합니다. 글을 쓰는 친구들을 저자로서 존엄을 가지고 대해야지 솔직하게 쓰라고 명령을 한다면, 그건 학생들을 저자로 대하지 않는 것이라는 생각이 들어요. ... 일방적으로 가르치는 사람의 입장에 서지 않고 교사가 독자의 입장이 되어 글 쓰는 학생들을 저자로 존중하는 것이죠. 스스로를 저자로 인식하는 것이 글쓰기를 즐겁게 만들고 진정성 있는 글을 쓸 수 있게 합니다."(송동철 선생님) "가장 좋은 피드백은 다른 반에 가서 잘 쓴 글을 읽어 주거나, 시집이나 문집을 내는 것이에요. 자기 글의 독자가 생기고 거기서 반응을 얻으면 아이들이 글을 더 쓰고 싶어하죠."(김제식 선생님) "교사가 진정성 있는 피드백을 해야 하는데, "여기를 이렇게 고쳐 봐"라는 식의 평가적 피드백이 아니라 독자로서 반응하는 것이어야 한다고 생각해요. 어떤 것들이 마음을 움직였는지, 어떤 부분이 아름다운지 말해주고, 잘 이해가 안 되는 부분은 "이 부분이 어떤 의미인지 궁금해"라고 물어보는 것이죠. 어차피 처방을 준다고 해서 글이 다 고쳐지지 않거든요."(송동철 선생님) "학생들이 갖고 있는 이야기를 글로 만나 보면 말이나 행동이나 겉모습에서는 알기 힘든 각각의 고유성과 독자성을 확인하게 됩니다. 그러다 보니 학생들을 동행자로 바라볼 수 있게 되었어요. ... 글쓰기가 아니었다면 아이들 한 명 한 명을 이렇게 생생하게 기억할 수는 없을 겁니다. 아이들의 가장 빛나는 순간을 알기 때문에 그들을 기억하고 존경하는 마음을 갖게 되는 거죠."(김진해 선생님)

카파시 스타일의 llm-wiki를 원스톱으로 만들어주는 스킬입니다. 톡방에서 llm-wiki를 만들고 싶다고 말씀하시는 분들이 많은데 이 소스를 활용하시면 정말 쉽게 만드실 수 있습니다.

AI로 채점하기 전에, 교사가 먼저 봐야 합니다 요즘 바이브코딩으로 학생 과제를 채점하거나 피드백을 만들어 주는 프로그램을 직접 만들어 쓰시는 선생님들이 늘고 있습니다. AI를 잘 활용하면 학생 과제물에서 교사가 보지 못한 것을 풍부하게 볼 수 있게 될 것 같습니다. 다만 한 가지, 순서를 꼭 지켜 주셨으면 합니다. 최근 한 실험 연구에서 AI가 내놓는 정보에 대한 교사의 독립적이고 주체적 판단이 가능하지 않음을 증명하는 결과가 나왔습니다. 교수 214명에게 똑같은 학생 글을 주되, 'AI 탐지율 87%'라는 숫자와 빨간 밑줄만 붙여 보여줬더니, 같은 글의 점수가 73점에서 51점으로 떨어졌습니다. 글은 그대로인데 화면에 뜬 숫자 하나가 교사의 눈을 바꾼 겁니다. 연구자들은 이를 '자동화 편향'이라 부릅니다. AI가 내린 결론이 판단의 출발점이 되어 편향이 생겨버린 것이죠. 그래서 AI가 평가를 내놓기 전에, 교사가 먼저 학생의 글을 읽어야 합니다. 내 판단을 먼저 세운 뒤 AI를 보조 자료로 참고하는 겁니다. 우리가 학생들에게 "AI에 답을 맡기지 말고, 네 생각을 먼저 세우고 AI를 활용하라"고 가르치는 것과 똑같습니다. 학생도 교사도 사람(H) → AI → 사람(H)의 순서를 지켜야 합니다. AI는 중간에 사람의 판단을 확인하고 넓히는 도구여야지, 처음부터 판단을 대신하는 존재가 되어선 안 됩니다. 이 순서 하나가, 우리가 만든 도구를 편리한 조력자로 남길지 판단을 앗아가는 함정으로 만들지를 가릅니다. 바이브코딩으로 도구를 만들 때에도 사용자들이 이 순서를 따르도록 설계하는 것이 중요할 것 같습니다. <참고문헌> Davalos, E., & Zhang, Y. (2026). Al misuse in education is a measurement problem: Toward a learning visibility framework. arXiv preprint arXiv:2603.07834v1.

앤트로픽이 미국에서 인증된 K-12 교사들을 위한 새로운 무료 서비스인 'claude-for-teachers'를 공개했습니다. 인증이 완료되면 미국 K-12 교육자들은 러닝 커먼즈(Learning Commons) 커넥터를 통해 클로드 포 티처스(Claude for Teachers)에 접속하여 학습 과학에 기반한 맞춤형 교수법을 활용할 수 있다고 합니다. 여기에는 Claude Code와 Cowork가 포함되어 있어 Claude가 자체적으로 작업을 진행할 수 있습니다. 부럽네요😂😂😂

하지만 너무 부러워만 할 필요는 없습니다. 앤트로픽에서 'k120teacher-skills'를 오픈소스로 공유했거든요. 우리고 이 스킬셋을 래퍼런스로 한국 유초중고 교사들을 위한 스킬셋을 만들어 볼 수 있을 것 같습니다. 같이 작업해보실 분 있으신가요?

0. 기초

1. 하네스 엔지니어링

2. 루프 엔지니어링

광고 아닙니다 ㅎㅎㅎ 하지만 진짜 저와 같은 코알못에게는 정말 큰 도움이 되는 채널입니다 바이브코딩이 너무 어렵게 느껴지신다면 꼭 보세요

전국국어교사모임 LLM 위키를 만들었습니다 선생님들 혹시 전국국어교사모임을 알고 계신가요? 전국모는 1988년에 시작된 국어 선생님들의 전국 단위 모임입니다. 학생과 교사가 함께 배우고 성장할 수 있는 행복한 국어 수업을 만들고 싶은, 더 살기 좋은 세상을 만들기 위한 자그마한 기여라도 하고 싶은 국어 선생님들이 계신 곳입니다. 저는 전국모에서 적극적으로 활동을 하고 있지는 못하지만 전국모 홈페이지에 올라오는 수업 사례, 계절별 회지, 여름방학과 겨울방학 연수 자료, 지역별/분과별 자료를 읽으며 국어 교사로서 많은 배움을 얻고 있습니다. 그런데 자료가 정말 많다보니 이런 고민을 할 때가 있습니다. "이번 학기에 책대화 수행평가를 하고 싶어, 내가 전국모 회지에서 멋진 수업 사례를 읽었었는데 그게 어느 호에 있는 글이었지?" "반대 신문식 토론을 해야 하는데 학생들이 어려워할 거 같아. 학생들이 반대 신문식 토론을 쉽고 재미있게 배울 수 있는 좋은 방법이 없을까? 어디에서 찾아야지?" 좋은 자료가 있다는 사실은 기억나는데 정작 제목과 출처가 떠오르지 않습니다. 홈페이지의 여러 게시판을 오가며 검색어를 바꾸어 보고, 회지 목차를 한 호씩 살펴보다가 결국 찾기를 포기한 적도 있습니다. 그래서 전국국어교사모임 홈페이지의 자료를 제 PC에 내려받아, 옵시디언 노트로 이루어진 ‘LLM 위키’를 만들기로 했습니다. 위키를 모두 만들고 나니 자료 노트만 9,719개가 생성되었습니다.

• 회지 글과 목차: 3,528개
• 연수 및 모임 자료: 999개
• PDF·HWP·HWPX·이미지 등 첨부 자료: 5,192개

일반적인 자료실에서는 적절한 검색어를 먼저 떠올려야 합니다. 제 ai 챗봇에 이 옵시디언 노트를 연결하면 제가 해결하고 싶은 수업 고민을 평소 말하듯 질문할 수 있습니다. 예를 들면 이런 식입니다. “고등학생과 장편소설을 읽은 뒤 책 대화를 진행한 수업 사례를 찾아줘. 수행평가로 활용할 수 있는 방법을 중심으로 알려줘.” “중학생이 반대 신문식 토론을 처음 배울 때 활용할 만한 수업 사례와 활동 자료를 찾아줘.” “문법 개념을 암기시키지 않고 학생이 직접 발견하게 한 수업 사례가 있을까?” LLM은 위키에서 관련 자료를 검색하고, 글의 제목과 연도, 원문이 실린 회지나 연수 자료를 함께 제시합니다. 마음에 드는 자료가 있으면 해당 노트의 전문을 읽게 한 뒤 수업의 흐름, 활동 방법, 평가 아이디어를 정리하도록 할 수도 있습니다. , 전국모에 축적된 수많은 동료 교사의 경험 속에서 지금 나에게 필요한 자료를 찾아 주는 ‘자료 탐색 도구’가 생긴 셈입니다.

제가 기대하는 활용 장면은 다양합니다.

• 새 단원을 준비할 때 비슷한 수업 사례 찾아보기
• 수행평가를 설계하기 전에 기존 평가 사례 비교하기
• 학생들이 어려워하는 개념을 설명한 활동 자료 찾아보기
• 회지에서 읽었던 글을 기억나는 내용만으로 다시 찾기
• 특정 주제나 작품이 여러 시기의 수업에서 어떻게 다루어졌는지 살펴보기
• LLM이 제안한 수업 아이디어를 전국모의 실제 사례와 대조하기

예전에는 “어디선가 읽었던 것 같은데…”에서 멈추었다면, 이제는 그 희미한 기억에서 출발해 관련 자료의 제목과 출처까지 찾아갈 수 있게 되었습니다. 이 위키가 전국모 자료를 완벽하게 이해하는 것은 아닙니다. 오래된 문서나 스캔 자료에는 글자 인식 오류가 있을 수 있고, 첨부 파일의 형식에 따라 전문을 제대로 읽지 못한 자료도 있습니다. LLM 역시 자료에 없는 내용을 그럴듯하게 만들어 낼 수 있습니다. 따라서 LLM의 답변은 자료를 발견하기 위한 출발점으로 사용해야 합니다. 실제 수업에 활용하기 전에는 반드시 연결된 원문을 읽고, 글의 맥락과 출처를 직접 확인해야 합니다. 또한 전국모의 자료에는 여러 선생님의 오랜 연구와 실천이 담겨 있습니다. 자료의 저작권과 개인정보를 존중하기 위해 현재 위키와 추출 전문은 제 PC 안에서만 사용하고 있습니다. 이 글 역시 자료 원문을 공개하려는 것이 아니라, 방대한 교사 자료를 어떻게 더 잘 찾고 읽을 수 있을지에 대한 작업 과정과 가능성을 나누기 위해 작성했습니다. <참고 자료> 안드레 카파시 llm wiki

이 문서는 워싱턴대학교 연구진의 논문 《Teacher-Authored Prompts for Configuring Student-AI Dialogue: K-12 Classroom Implementation》(Liu, Sun, Esbenshade 외, 2026)를 바탕으로, 학습용 AI 챗봇을 직접 설계하는 교사를 위해 핵심을 뽑아 정리한 자료입니다. 개발(코딩·인프라) 이야기는 빼고, "챗봇에게 무엇을 어떻게 시킬 것인가"에 집중했습니다. 1. 이 연구 한눈에 보기 가. 무엇을 연구했나 한 마디로, 교사가 직접 프롬프트를 써서 학생–AI 대화를 설계하면 실제 교실에서 어떤 일이 벌어지는가를 데이터로 추적한 연구입니다. 연구진이 사용한 시스템(TASD, "교실 보조 교사")에서 교사는 두 가지를 작성합니다.

• 교사→AI 설정 프롬프트(학생에게는 보이지 않는 층): AI의 역할, 다룰 주제, 안내 방식, 지켜야 할 제약을 지정
• 학생용 시작 문구: 학생이 처음 보는, 활동을 여는 안내

여기서 중요한 관점은 AI를 "알아서 가르치는 자율 튜터"가 아니라, 교사가 판을 짜고 조율하는 세 번째 행위자로 본다는 점입니다. AI의 성능 자체보다, 교사가 그 AI를 얼마나 잘 "설정"하느냐가 학습의 질을 좌우한다고 보는 것이죠. 나. 어떤 규모로 했나

• 시기·장소: 2025년 봄, 미국 워싱턴주 (4개 공립 학군 + 1개 사립학교)
• 참여: 교사 20명 중 16명이 실제로 수업에 적용
• 범위: 39개 교실 · 77개 활동 · 학생 878명
• 데이터: 학생–AI 대화 1,479건, 메시지 36,162개, 그리고 교사 심층 인터뷰 10건
• 과목 분포: 국어(ELA) 48%로 최다, 과학 20%, 세계언어 12% 순 (수학·STEM은 수식·그림을 채팅에 넣기 어려워 상대적으로 저조)

다. 핵심 발견 5가지 ① 학생을 주제 안에 붙잡아 두는 건 잘 됐다. 전체 대화의 71%가 완전히 주제에 집중했고, 크게 벗어난 경우는 1%도 안 됐습니다. "AI 주면 애들이 딴짓한다"는 걱정은, 교실 루틴 안에서 목적이 분명한 프롬프트로 감싸면 상당 부분 해결됐어요. ② 하지만 "사고의 깊이"는 저절로 따라오지 않았다. 교사가 목표한 사고 수준(DOK)에 학생이 도달하지 못한 경우가 38%. 특히 높은 수준(DOK 3, 전략적 사고)을 목표로 하면 거의 절반(46%)이 미달했습니다. 목표를 높게 잡을수록 격차가 더 벌어졌어요. 이걸 연구진은 '설계–실행 격차(design-enactment gap)'라고 부릅니다. ③ "완료 기준(finish line)"을 명시하면 사고 수준이 올라갔다. "이걸 하면 끝"이라는 명확한 끝점을 프롬프트에 넣은 경우, 사고 수준 격차가 유의하게 줄었습니다(0.22 수준 감소, 통계적으로 매우 유의미). 학생이 "무엇을 하면 완성인지" 알 때 더 깊이 파고들었다는 뜻입니다. ④ "직접 답 주지 마" 한 줄이 실제로 AI 행동을 바꿨다. 이 가드레일을 프롬프트에 넣자 AI의 직접 답변율이 16.2% → 7.7%로 절반 아래로 떨어졌습니다. 흥미롭게도, 시스템에 이미 비슷한 규칙이 깔려 있어도 교사가 한 번 더 써주면 추가 효과가 있었어요. ⑤ 학생이 답을 조르면 AI가 흔들렸다. 하지만 대체로 버텼다. 학생이 대놓고 "그냥 답 알려줘"라고 압박하면 AI의 직접 답변율이 12.5% → 26.1%로 뛰었습니다. 그래도 대부분의 경우엔 안내형 태도를 유지했고, 명백한 규칙 위반은 0건이었습니다. 2. 학습 챗봇을 설계할 때: 고려사항과 전략 가. 설계할 때 명심할 것(마인드셋 7) 1) 주제 이탈보다 "얕은 사고"가 진짜 적이다. 학생을 주제 안에 두는 건 생각보다 쉽습니다. 어려운 건 겉핥기를 막는 것. 온토픽이지만 사고는 얕은 대화가 흔했어요. 설계 에너지를 "딴짓 방지"보다 "깊이 유도"에 더 쓰세요. 2) "프롬프트에 썼다 = 실현됐다"가 아니다. "분석하게 해줘"라고 적어도 그대로 되지 않습니다. 프롬프트는 방향을 가리키는 신호일 뿐, 결과를 보장하는 장치가 아니에요. 목표를 높게 잡을수록 이 간극은 더 벌어집니다. 3) 학생은 반드시 지름길을 시도한다. 미리 대비하라. "그냥 답 줘", "대신 써줘", 통째로 복붙 — 이건 예외가 아니라 기본값입니다. 이 상황들을 예상 시나리오로 놓고, 답을 요구받았을 때 어떻게 되받아 유도할지를 프롬프트에 미리 심어두세요. 4) 장황함 + "다음에 뭘 할지 없음"이 이탈을 만든다. 교사들이 가장 많이 지적한 이탈 원인입니다. AI가 질문만 계속 던지고 학생이 당장 실행할 다음 한 걸음을 못 받으면 좌절하고 떠났어요. 질문형 안내는 좋지만, 항상 "그래서 지금은 이걸 해봐" 같은 실행 지시가 붙어야 합니다. 5) 참여는 'all-or-nothing'으로 갈린다. 어떤 학생은 깊게 몰입하고, 어떤 학생은 최소한만 하거나 아예 빠집니다. 이 격차를 실제로 줄인 요인이 명확한 완료 기준이었어요. 설계로 손댈 수 있는 지점입니다. 6) 단발 세션에는 천장이 있다. 여러 자료를 종합하거나 장기 프로젝트를 요하는 최고 수준 사고(DOK 4)는 채팅 한 세션으로 거의 불가능했습니다(실사용 0건). 한 번의 대화에 무리한 깊이를 욕심내지 말고, 깊은 사고는 여러 차시나 오프라인 활동과 이어 붙이세요. 7) "출구(closure)"를 설계에 포함하라. 대화를 다시 교실 토론·모둠 활동으로 되돌리는 마무리가 없으면, 학습 가치가 학생마다 들쭉날쭉해지고 교사가 관리하기도 어려워졌습니다. 챗봇이 끝나는 지점 = 다음 활동으로 넘기는 지점으로 설계하세요. 나. 실제로 쓸 수 있는 전략(검증된 순서) ① 완료선(finish line)을 반드시 명시: 가장 강력하게 검증된 레버 예: "증거에 기반한 토론 논점을 2개 만들면 대화를 마칩니다." 학생과 AI 둘 다에게 "완성의 모습"을 그려주세요. 사고 수준 격차를 유의하게 줄인 유일한 설계 요소였습니다. ② 자연어 가드레일 한 줄: 가성비 최고 예: "학생에게 최종 답을 직접 주지 마세요. 스스로 도달하도록 도우세요." 정답 제공률을 절반 아래로 떨어뜨렸습니다. 시스템에 규칙이 있어도 중복해서 넣는 걸 두려워하지 마세요. ③ 과제를 구체적으로: 산출물·단계·성공 기준 명확히 막연한 열린 탐색보다 경계가 분명한 과제가 훨씬 잘 작동했습니다. 무엇을, 어떤 단계로, 어떻게 되면 잘한 것인지를 적어주세요. ④ 스캐폴딩 방식 지정 단, 과하게 넣지 말 것 효과가 확인된 순서: 단계적 안내 → 소크라테스식 질문 → 시도 먼저 요구 → 힌트 먼저. 실제 교사들은 대개 1~2개만 골라 썼습니다. 다 넣기보다 과제에 맞는 것 몇 개만. ⑤ 인지부하 제약: 특히 다국어 학습자·저학년 예: "한 번에 한 문장으로", "질문은 한 번에 하나만", "쉬운 어휘로", "문장 시작 틀 제공". 이런 제약이 참여를 지탱했습니다. ⑥ AI 역할 명시: 튜터 / 코치 / 동료 안 정하면 시스템 기본값으로 흘러갑니다. 특히 AI를 권위자가 아닌 "동료(peer)"로 세팅해 협력자처럼 두는 시도도 유효했어요. ⑦ 인식론적 프레이밍은 '세트로'만: "근거를 사용해", "대안을 비교해", "주장을 정당화해" 같은 요구는 좋지만, 이것만으로 사고 수준이 저절로 오르진 않았습니다. 반드시 위의 ④·⑤(실행 지원)와 함께 쓰세요. 핵심 한 줄: 경계를 명확히 하되(완료선·가드레일·구체적 과제), AI가 학생에게 항상 실행 가능한 다음 한 걸음을 주도록 설계하라. 3. 바로 쓰는 자료: 프롬프트·루브릭·템플릿(번역) 논문에 실린 실제 도구들을 한국어 맥락에 맞게 옮기고 다듬었습니다. 그대로 복사해 쓰거나, 자신의 프롬프트를 점검하는 기준으로 활용하세요. 가. 교사 프롬프트 설계 스키마 (원문 Table 1) 챗봇 설정 프롬프트를 쓸 때 아래 다섯 칸을 채운다고 생각하면 됩니다. ① AI 역할 — 태도와 관계를 정한다 "코치처럼 행동하세요. 최종 답은 주지 말고, 학생이 소리 내어 생각하도록 도우세요." ② 담화 방식 — 상호작용의 질을 만든다 "한 번에 질문 하나씩 하세요. 학생에게 근거를 대게 하고, 힌트는 학생이 먼저 시도한 뒤에만 주세요." ③ 제약 — 속도와 부담을 조절한다 "답변은 1~2문장으로 유지하세요. 쉬운 어휘를 쓰고, 필요하면 문장 시작 틀을 제공하세요." ④ 근거와 엄밀성 — 사고의 질을 높인다 "학생이 어떤 주장을 하면, 본문에서 근거를 찾거나 풀이 과정을 보여달라고 요청하세요." ⑤ 완료선 — 언제 끝나는지 정한다 "학생이 근거를 갖춘 토론 논점을 2개 만들어내면 대화를 마치세요." 나. 사고 수준(DOK) 정의와 예시(원문 Table 2) DOK(Depth of Knowledge)는 과제가 요구하는 사고의 깊이를 4단계로 나눈 틀입니다. 챗봇에게 어느 수준을 목표로 하는지를 정할 때 기준으로 삼으세요. DOK 1 (회상) — 사실·정의·단순 절차를 떠올리기 예: 어휘 정의하기, 단계 나열하기 DOK 2 (기능·개념) — 단순 암기를 넘어선 사고 처리 예: 비교·대조하기, 요약하기, 이유 설명하기 DOK 3 (전략적 사고) — 추론·계획·근거가 필요 예: 글쓴이의 주장 분석하기, 실험 설계하기 DOK 4 (확장적 사고) — 시간을 두고 여러 자료를 종합하는 복합 사고 예: 조사해서 종합하기, 독창적 해결책 만들기 현실 조언: 채팅 한 세션에는 DOK 2~3이 현실적인 목표입니다. DOK 4는 여러 차시·프로젝트와 연결해야 실현됩니다. 다. 내 프롬프트 자가진단 체크리스트(코딩 루브릭 기반) 연구진이 교사 프롬프트를 분석할 때 쓴 항목들입니다. 자신의 챗봇 프롬프트를 점검하는 체크리스트로 바꿔 담았어요. 1) 과제와 완료선 과제가 구체적인가? (막연한 목표 / 대략적 과제 / 명확한 산출물·단계·성공 기준) 완료 기준이 명시돼 있는가? ("~를 만들면 끝", "~하면 마치세요") 2) 스캐폴딩 방식(해당하는 것 표시) 소크라테스식 질문: 답 대신 생각을 파고드는 질문을 하게 했는가 단계적 안내: 여러 단계로 나눠 순차적으로 진행하게 했는가 힌트 먼저: 전체 설명 전에 힌트부터 주게 했는가 시도 먼저: 학생이 먼저 시도한 뒤 도와주게 했는가 완성본 금지: 완성된 답·결과물을 대신 써주지 못하게 했는가 3) 인식론적 프레이밍 (해당하는 것 표시) 이유·근거 설명하게 하기 근거·출처 인용하게 하기 대안 비교·평가하게 하기 주장 정당화(주장+뒷받침)하게 하기 4) 제약 조건 (해당하는 것 표시) 짧은 답변 (1~2문장, 간결하게) 한 번에 질문 하나 정해진 형식 (불릿, 표, 단계, 주장-근거 틀 등) 언어 수준 (읽기 수준, 연령 적합 어휘, 다국어 학습자 지원) 5) 역할과 어조 AI 역할 지정: 튜터 / 코치 / 면접관 / 동료 / 비평가 / 진행자 중 무엇인가 어조 지정: 지지적 / 중립적 / 엄격 / 유쾌 중 무엇인가 6) 안전·윤리 가드레일 (해당하는 것 표시) 직접 답 금지 학문적 정직성 문구 (표절·베끼기 금지) 개인정보·안전 규칙 존중하는 언어·태도 7) 목표 사고 수준 이 과제의 목표 DOK는 몇 단계인가? (1 / 2 / 3 / 4) 라. 바로 참고할 활용 유형 9가지(원문 U1~U9) 파일럿에서 교사들이 실제로 만든 챗봇 유형입니다. "이런 걸 만들어볼까?" 아이디어 뱅크로 쓰세요. U1. 토론 준비 & 텍스트 이해(국어·사회) 공유한 글에서 주제 찾기, 어휘 지원, 근거 기반 추론을 도와 전체 토론을 준비. "토론 전에 근거를 갖춘 아이디어 2~3개 만들기" 같은 완료선 포함. U2. 다국어 학습자 미세 스캐폴드 & 접근성 제약 "한 문장으로 답하기 / 한 번에 질문 하나" + 쉬운 언어. 부담을 낮춘 저부담 확인, 이해 점검, 안내된 성찰용. U3. 사회정서학습(SEL)·교실 루틴 체크인·감사·목표 설정 같은 짧고 부담 없는 대화. 월요일 체크인, 금요일 성찰 등 도입 활동으로. 간결함과 심리적 안전이 핵심. U4. 명확한 기준이 있는 형성 연습(숙달 지향) 목표 기능(예: 인과 추론)에 대해 성취 기준을 만족할 때까지 반복 연습. 정식 평가는 아니지만 숙달 틀과 잦은 점검 활용. U5. 메타인지 코칭 & 학습 전략 대화 학습 전략을 학생이 설명하게 하기(예: 왜 필기가 기억에 도움 되는지). 학생이 대화를 주도하고 AI는 간결하게. 자기조절 학습 유도. U6. 프로젝트 관리 & 책임감 지원 "한 번에 질문 하나"로 과제를 잘게 쪼개 진행 계획·자기평가·협업 성찰을 도움. 압도감은 줄이되 학생이 주도권을 유지. U7. 배경지식·스키마 쌓기(어려운 텍스트 대비) 글이 학생 읽기 수준보다 어려울 때, 읽기 전에 배경지식과 어휘를 먼저 쌓아 이해와 참여를 지원. U8. 문해 하위 기능: 형태소 분석·어휘 분류 음소·형태소 분해, 어휘 범주별 묶기 등을 오류 교정·재시도와 함께. 정답 기준이 분명한, 촘촘하게 제약된 상호작용. U9. 역할극 시뮬레이션 & 동아리·진로(CTE) 준비 모의 면접, 대회 준비, 비즈니스 컨설턴트 시나리오 등 역할 기반 튜터. 탐색·시나리오·퀴즈 모드로 실전 연습. 4. 마무리 이 연구가 우리에게 주는 메시지는 분명합니다. 교사는 이미 과제를 명확히 만들고 높은 사고를 목표로 삼는 능력은 충분히 갖추고 있습니다(전체의 92%가 DOK 2~3을 겨냥). 부족한 건 그 목표를 AI 대화 안에서 끝까지 지속시키는 과정 설계예요. 그 간극을 메우는 가장 확실한 도구가 이 문서에서 반복된 세 가지입니다. 완료선을 명시하라 — 학생이 "완성의 모습"을 알게 가드레일을 자연어로 한 줄 넣어라 — "직접 답 금지"만으로도 행동이 바뀐다 AI가 항상 실행 가능한 다음 한 걸음을 주게 하라 — 질문만 던지고 끝내지 않게 AI를 교사의 대체물이 아니라, 교사가 판을 짜고 조율하는 확장 도구로 볼 때, 학습용 챗봇은 비로소 교실에서 살아남고 제 몫을 합니다. 출처: Alex Liu, Min Sun, Lief Esbenshade, Victor Tian, Zachary Zhang, Kevin He (2026). "Teacher-Authored Prompts for Configuring Student-AI Dialogue: K-12 Classroom Implementation." arXiv:2604.16738v1. 원문 및 부록: https://osf.io/fdx8y/

Kolb의 Triple E Framework인데 수업에서 에듀테크 활용 여부를 결정하거나 효과를 평가할 때, 바이브코딩으로 수업 도구를 개발할 때 이걸 가지고 교사들이 스스로 질문을 던져볼 수 있을 것 같습니다. 에듀테크를 수업에 활용할 때 우리는 종종 “이 도구가 새롭고 편리한가?”를 먼저 묻게 됩니다. 최근에는 바이브코딩을 통해 교사가 직접 수업 도구를 만들 수 있게 되면서, “만들 수 있는가?”라는 질문도 중요해졌습니다. 하지만 수업의 관점에서 더 중요한 질문은 따로 있습니다. “이 도구가 학생의 배움을 실제로 돕는가?” “수업 목표에 더 깊이 다가가게 하는가?” “교사가 의도한 배움의 경험을 더 잘 가능하게 하는가?” Kolb의 Triple E Framework는 이 질문을 구조화해 주는 틀입니다. Triple E는 Engagement, Enhancement, Extension의 세 가지 관점으로 기술 활용을 살펴봅니다. 학생들이 단순히 화면을 보고 조작하는 수준을 넘어 학습 목표에 몰입하고 있는지, 기술이 기존 수업을 단순히 대체하는 데 그치지 않고 이해와 표현을 더 깊게 만들어 주는지, 그리고 교실 안의 배움을 학생의 삶과 실제 세계로 확장하고 있는지를 묻습니다. 이 관점은 에듀테크를 “쓸 것인가, 말 것인가”의 이분법으로 판단하게 하지 않습니다. 오히려 “어떤 배움을 위해, 어떤 방식으로, 어느 정도까지 사용할 것인가”를 고민하게 합니다. 그래서 Triple E는 특정 도구를 홍보하거나 배제하기 위한 기준이라기보다, 교사가 수업 설계 과정에서 스스로 던져볼 수 있는 성찰 질문에 가깝습니다. 특히 바이브코딩으로 수업 도구를 개발할 때 이 질문은 더 중요해집니다. 내가 만든 도구가 보기 좋고 작동이 잘 되는 것만으로는 충분하지 않습니다. 학생들이 학습 목표에 더 집중하게 하는가? 이해를 돕는 발판을 제공하는가? 기존 방식으로는 어려웠던 표현, 협력, 피드백, 연결을 가능하게 하는가? 이런 질문을 통과할 때 비로소 기술은 수업의 장식이 아니라 배움을 돕는 설계 요소가 됩니다. 결국 중요한 것은 기술 자체가 아니라 수업입니다. 에듀테크도, AI도, 바이브코딩으로 만든 도구도 수업 목표와 학생의 배움을 중심에 둘 때 의미를 갖습니다. Triple E Framework는 그 중심을 잃지 않도록 교사에게 다시 묻습니다. “이 기술은 지금, 이 수업에서, 학생의 배움을 어떻게 더 낫게 만드는가?”

교사가 잡무를 AI에 떠넘겨서는 안 되는 이유 글: 대니얼 벅(Daniel Buck) | Education Week 오피니언 | 2026년 3월 18일 학생이 교실에서 AI를 써야 하는가는 뜨거운 논쟁거리다. AI가 학습을 끌어올리고 사회 진출을 준비시켜줄까, 아니면 디지털 의존과 인지 능력 퇴화로 이어질까? 그런데 교사의 AI 활용에 대해서는 그리 나쁠 게 없다는 쪽으로 점점 의견이 모이고 있다. 솔깃하고 그럴듯한 주장이지만, 틀렸다. 교사가 수업 외 업무에 주당 29시간이 넘는 시간을 쏟는 만큼, 그 일을 AI에 넘기고 더 중요한 수업에 집중하자는 것이 이 주장의 골자다. 실제로 2023년 미국 교육부 보고서는 학생 글에 피드백을 주는 일부터 학급 운영 계획을 짜는 일까지 교사가 AI를 활용하라고 권했고, 2025년 행정명령은 "시간이 많이 드는 행정 업무"를 줄이려는 목적 등으로 교사가 "교실에서 AI를 활용하도록" 돕겠다고 했다. 그러나 그 일을 AI에 떠넘기는 것은, 수업 과정을 간소화해줄지는 몰라도 중대한 실수다. 사소해 보이는 그 업무들이야말로 교직에서 가장 근본적이고 중요한 부분인 경우가 많기 때문이다. 그것들은 곁다리 일이 아니라 가르치는 일 그 자체다. 몇 가지 예를 보자. 교육자 990명을 대상으로 한 Education Week 설문에 따르면, 교사들이 AI를 흔히 쓰는 용도 중 하나가 이메일 작성이다. 한 교사는 이렇게 적었다. "대략적인 내용만 입력하면 내가 썼을 법한 이메일을 받을 수 있어 훨씬 빠르다. 직접 썼다면 15분 넘게 걸렸을 것이다." AI에게 이메일을 맡기는 게 더 쉬운 것은 분명하다. 그런데 더 나은 일일까? 내가 교감으로 일할 때는 민감한 이메일을 많이 써야 했다. 문제 행동, 특수교육 지원, 화장실 사고, 따돌림, 싸움, 학대 등 온갖 사안에 관한 것이었다. ChatGPT 탭으로 옮겨가는 편이 일을 분명 수월하게 해줬겠지만, 나를 덜 유능한 관리자이자 리더로 만들었을 것이다. 잘 쓴 이메일의 바탕에는 충분한 성찰이 깔려 있다. 몇 줄짜리 글에 15분, 때로는 오후 내내 매달리게 되는 이유가 여기에 있다. 글자를 두드려 넣기가 힘든 게 아니라, 상황을 이해하고 내가 하려는 말을 정확히 써내는 일이 어려운 것이다. 이를테면 학생의 행동에 관해 학부모에게 이메일을 써야 한다면, 나는 그 문제를 곰곰이 따져봐야 했다. 이 학생은 왜 그렇게 행동했을까? 이 한 번의 사건 뒤에는 어떤 내력이 있을까? 특수교육 담당자를 함께 참여시켜야 할까? 앞으로 학교 리더인 나와 학부모, 교사는 각각 무엇을 해야 할까? 이메일 작성에는 시간이 들었지만, 그 과정에서 이런 질문들을 짚어보고 해결책을 마련하게 됐고, 그 덕분에 학교가 마주한 문제가 무엇이든 앞으로 더 잘 대처할 수 있었다. 그 일을 Claude에 넘기는 순간, 나는 그 의도적인 성찰까지 함께 넘겨버리는 셈이다. 이와 똑같은 인지적 맞교환은 교사나 에듀테크 컨설턴트가 떠올릴 수 있는 거의 모든 활용 사례에 그대로 적용된다. 교사가 Grok으로 시험 문제를 뽑으면, 잘 짜인 단원이나 활동의 바탕이 되는 숙고를 건너뛰게 된다. 영어 교사였을 때 나는 수업 마무리 성찰 질문 하나를 떠올리는 데도, 그날의 토론이 단원과 한 해 전체에 어떻게 맞물리는지, 내가 무엇을 왜 묻고 있는지, 학생들에게서 어떤 답을 기대하는지를 따져봐야 했다. 그렇게 미리 해둔 생각은 토론 중에 후속 질문을 어떻게 던질지, 어떤 곁가지로 들어가거나 피할지, 그날 읽기 자료의 어느 대목에 주목시킬지를 좌우했다. 가르치는 기술은 이처럼 사소해 보이는 일들과 씨름하고 공들이는 과정에서 다듬어진다. 인지적 떠넘김을 넘어서, 교사의 AI 활용은 교실의 관계적 역학도 바꿔놓는다. AI가 학생의 과제를 분석하고 피드백을 줄 수 있다는 건 당연하다. 하지만 "업무를 간소화"하겠다고 학생들의 글을 다 읽지 않기로 했다면, 나는 학생들과 그들의 학업적 강점·약점에 대해 훨씬 적게 알게 됐을 것이다. 한편 학생들은 사실상 내게서 나온 것이 아닌 피드백을 받게 된다. 그런 피드백을 학생들이 굳이 읽고, 신뢰하고, 자기 과제를 끝까지 해냈을까? 교실에서 함께 학업을 나누며 맺어지는 인간적 유대는 학생의 참여와 학업 성취에 꼭 필요한 관계를 만든다. AI에 기대는 순간 그 연결이 끊긴다. AI 의존의 결과는 운동이라는 신체적 비유에서 더 분명히 드러난다. 따지고 보면 운동선수가 경기에 임하는 시간은 선수 생활의 극히 일부일 뿐이고, 대부분은 체육관에서 훈련하고 연습하는 데 쓰인다. 그렇다면 기계가 동선을 뛰고 반복 훈련을 대신해서, 선수는 더 중요한 경기에만 집중하게 하면 안 될까? 그렇게 하면 근육은 퇴화하고, 몇 달간의 고된 연습으로 다져진 팀의 결속도 약해질 것이다. 운동선수가 하는 일의 상당 부분이 연습과 신체 훈련이다. 마찬가지로 교사가 하는 일의 상당 부분은 성찰과 계획에 있다. 교사가 그 일을 AI 보조 도구에 외주로 넘긴다면, 교실 공동체와 학업 성과가 빠르게 무너지더라도 놀라지 마시라.

학기말이 다가오니 제 주변에도 평가, 생기부 작성 AI 도구를 바이브코딩으로 만드는 선생님들이 많아진 것 같습니다. 결론부터 말씀드리겠습니다. 교사가 최종 판단만 제대로 하면 대부분 'AI기본법 고영향 규제' 밖입니다. 겁먹을 필요 없어요. 대신 만들 때 딱 다음 세 가지를 챙기면 됩니다. ①교사를 진짜 최종 결정자로 ②개인정보는 안 모으는 설계 ③생성형 AI 티 내기 0. 먼저 내 상황부터 구분(의무 크기가 여기서 갈림) • 가. 나 혼자 내 반에서 사용 → 부담 최소. 개인정보 관리만 신경 • 나. 동료 교사에게 공유 → 위 + 료에겐 '도구(코드/앱)'만 공유하고 데이터는 각자 처리. 학생 데이터가 한 서버로 모이는 구조라면 → 학교(개인정보 보호책임자)와 협의·승인 필요 • 다. 가입형으로 외부 배포 → 비로소 'AI기본법 사업자 의무'가 본격 발생 AI기본법의 고지·책무 의무는 '인공지능사업자'의 몫입니다. 가·나 수준의 교사는 보통 '이용자'라 의무가 가볍고, 다로 갈수록 책임이 커집니다. 1. 설계 원칙 ① 교사를 '진짜' 최종 결정자로 위치시키기(고영향 회피의 핵심) 이 한 가지가 가장 중요합니다. 정부 가이드라인은 진단검사·지필/수행평가·생기부 작성 모두, 교사가 수정·보완 등 실질적 최종 검토를 하면 고영향 AI로 보지 않는다고 했습니다. 코드/UX로 구현할 것: • AI는 점수 '제안'·피드백 '초안'·생기부 '초안'까지만. 자동 확정 금지 • 교사가 반드시 수정·승인하는 단계를 둘 것(그냥 '확인' 버튼 한 번으로 통과되면 형식적 검토로 인정 안 될 수 있음 → 수정 가능한 입력칸, 근거 표시) • 산출물에 "AI 초안 · 교사 검토 필요" 라벨 → 이러면 고영향 규제에서 빠지고, '학생·학부모 거부권'(개인정보보호법 제37조의2)도 "완전히 자동화된 결정"이 아니라서 적용되지 않습니다.(사람이 판단하니까요.) 2. 설계 원칙 ② 개인정보는 '안 모으는 게 최선'(진짜 리스크는 여기) 법적 사고가 실제로 터지는 곳은 고영향 AI보다 개인정보입니다. 그리고 1차 책임은 데이터를 맡긴 학교나 교사(개인정보처리자)가 집니다. 코드로 구현할 것: • 실명·학번 대신 익명 ID·번호 사용(예: "3학년 2반 17번" → "학생A") • 외부 LLM API(OpenAI·Claude·Gemini 등)로 보낼 때 식별정보 빼기. 해외 API에 학생 개인정보를 보내면 '국외 이전'이라 절차가 까다로워지지만, 식별정보를 제거하면 애초에 개인정보가 아니게 되어 이 문제를 통째로 피합니다 • 가능하면 브라우저/로컬에서 처리, 서버 저장은 최소화 + 자동 삭제 • 외부 클라우드 저장이 불가피하면: 위탁계약(문서) + 처리방침 공개 + 수탁자 공개(개인정보보호법 제26조) 3. 설계 원칙 ③ 생성형 AI면 '티 내기'(고영향 아니어도 필수) GPT·Claude 같은 LLM을 쓰면 고영향이든 아니든 투명성 의무가 따로 적용됩니다(제31조). • "이 도구는 AI로 작동합니다" 사전 안내 • AI가 만든 결과물엔 "AI 생성"/"AI 초안" 표시 4. 외부 배포·가입형이라면 추가로 • 내 서비스가 고영향에 해당하는지 사전 검토, 애매하면 과기정통부에 확인 요청 가능(제33조) • 만약 교사 검토 없이 자동으로 점수·평가를 확정하는 구조라면 → 고영향 사업자 책무(위험관리·설명방안·사람의 관리감독·문서보관, 제34조)가 본격 적용됩니다. 그러니 가급적 '교사 검토 필수' 구조로 설계하세요. • 개인정보 처리방침·위탁·보안 정식 구비 배포 전 5분 체크리스트 • [ ] AI 결과를 교사가 실제로 수정·확정하는 단계가 있다 • [ ] 학생 실명, 생년월일 등 식별정보를 외부 API/서버로 보내지 않는다(익명화) • [ ] 외부 저장 시 위탁계약·처리방침이 있다 • [ ] "AI 기반" 안내 + "AI 생성물" 표시가 있다 • [ ] (외부 배포면) 고영향 해당 여부를 검토했다 한 줄 결론: 교사 검토를 진짜로 넣고, 학생 식별정보를 외부로 안 보내고, AI라고 표시만 하면 바이브코딩으로 만들어 써도 대부분 안전합니다. 파일로 첨부한 자가 점검 프롬프트를 코딩 에이전트에 넣고 한번 점검해 보세요😊 근거 법령(법제처 원문 2회 교차검증) 및 참고자료 - 인공지능기본법 제2조·제30조·제31조·제33조·제34조 https://www.law.go.kr/lsInfoP.do?lsiSeq=268543 - 개인정보 보호법 제26조·제37조의2 https://www.law.go.kr/lsInfoP.do?lsiSeq=270351 - 생기부·교사 최종검토 해석(교육을 비추다) https://www.kyobit.com/news/articleView.html?idxno=1849

AI한테 프론트앤드 디자인을 맡기면 그라데이션이 과하다든지, 이모지를 너무 많이 사용한다든지 하는 몇 가지 공통적인 특징들을 발견할 수 있죠. 이러한 밤티나는 AI 디자인을 탐지하고, 전문 디자이너가 작업한 것처럼 개선해주는 오픈소스입니다. 코딩 에이전트한테 이 깃허브 리포지토리 링크를 던져주고, 선생님들께서 개발하신 웹/앱의 디자인을 점검하고 개선해보세요. 저는 주기적으로 이걸 활용해서 디자인을 검토합니다 ㅎㅎㅎ

📌쌤핀 mcp, cli를 준비 중입니다. 클로드, gpt, gemini 같은 ai가 쌤핀에 입력된 데이터를 읽고, 쓸 수 있도록 mcp와 cli를 준비하고 있습니다. 보통은 프로그램에 api로 ai를 붙이지만 쌤핀은 반대로 데스크톱 ai 앱에 쌤핀을 붙이는 선택을 했습니다. 일반적인 선생님들 입장에서 조금 어렵게 느껴지실 수 있지만 ai를 구독하고 있다면 추가 비용 없이 ⭐최신의 모델로 쌤핀에 있는 데이터를 가지고 🖐️훨씬 다양한 작업을 👄자기 입맛에 맞게 하실 수 있기 때문입니다. mcp랑 cli가 뭐냐면 mcp는 쉽게 말해 ai가 다른 프로그램이랑 연결되는 '표준 콘센트' 같은 거예요. ai가 쌤핀이라는 콘센트에 꽂히면, 쌤핀 안의 데이터를 읽고 쓸 수 있게 됩니다. cli는 마우스 클릭 대신 명령어를 한 줄 쳐서 쌤핀을 다루는 방식이고요. 터미널에 입력하면 명단을 부르거나 관찰기록을 정리할 수 있어요. 둘 다 '쌤핀을 ai가 직접 다룰 수 있게 열어주는 통로'라고 보시면 됩니다. 제일 신경 쓴 건 개인정보예요 선생님 데이터를 ai한테 함부로 넘기면 안 되니까요. 그래서 쌤핀은 세 겹으로 막아뒀습니다. ① ai한테 학생 이름·연락처·생일·학번을 아예 안 보냅니다. 대신 'stu_8561…' 같은 암호 같은 토큰만 넘겨요. ai는 이 학생이 '누구'인지 모릅니다. ② 관찰기록처럼 민감한 내용은, 선생님이 '어떤 학생을, 언제까지, 무슨 목적으로' 열지 동의 범위를 직접 정해줘야만 열립니다. ai가 알아서 못 엽니다. ③ 기록을 '쓰는' 것도 선생님이 스위치를 켰을 때만 됩니다. 기본값은 잠금이에요. 그래서 뭘 할 수 있냐면 관찰기록을 근거로 행동특성·세특 초안 뽑기 그 초안이 진짜 관찰기록에 근거한 문장인지 검사하기 (없는 내용을 지어내면 걸러줍니다) 학생 명단·관찰기록 불러와서 정리하기 이런 걸 구독 중인 ai 최신 모델로, 추가 비용 없이 선생님 방식대로 작업할 수 있어요. 이 글이 저처럼 내가 만든 프로그램에 ai를 연결하고는 싶은데 api 비용이 걱정되었던 선생님들께 도움이 되면 좋겠습니다. 지금까지 클로드 200달러, 코덱스 100달러 요금제를 쓰면서 쌤핀을 사용하는 선생님들 api 비용이 나가는 건 무지하게 싫은 박준일이었습니다 ㅎㅎㅎ

유명한 바이브 코딩 서비스 Lovable이 2026년 말까지 교실 환경에서 교사/학생에게 바이브 코딩 플랫폼을 무료 제공하고 있다고 합니다 이거 한국 교사들도 됩니다 제가 테스트해봤어요 러버블의 라이트 플랜 계정을 줍니다 이걸 하려면 'edu.imagilabs.com'에서 교사 인증을 받아야 합니다. 학교 구글 계정으로 신청하니 되더라고요. 도름스에는 학생들과 바이브코딩을 하시는 분들도 계신 것 같아 공유드립니다. 방법: 1. edu.imagilabs.com 접속 2. 교육청 이메일로 회원가입 3. 프로필에 학교/학년/과목 입력 4. Request account verification 클릭 5. 인증되면 Lovable 교실용 무료 이용 가능

내가 만든 데스크톱 앱에 개인 구독 AI 모델을 붙일 수 있을까? 부제: API 비용 부담을 해결할 수 있는 방법 저는 교사용 데스크톱 앱 '쌤핀'을 만들고 있는 교사 박준일입니다. 학급 관리, 자리 뽑기, 출석부, 관찰 기록 같은 기능이 들어 있는데, 지금까지 일부러 AI 기능을 넣지 않았습니다. 여러 이유들이 있었는데 가장 핵심적인 이유는 돈이 무서워서 그랬습니다. 앱에 AI를 넣는 표준적인 방법은 API라는 걸 쓰는 겁니다. 쉽게 말해 내 앱이 AI 회사에 직접 전화를 걸어 일을 시키고, 통화료는 개발자인 내가 내는 방식입니다. 사용자가 10명일 때는 커피값이지만, 1,000명이 매일 쓰면 월급이 나갑니다. 무료로 배포하는 앱에 이 구조를 얹는 순간, 사용자가 늘수록 내가 가난해지는 이상한 사업이 됩니다. 그런데 최근에 이 전제를 뒤집는 방식을 발견했습니다. 결론부터 말하면... 됩니다. 그것도 개발자 비용 0원으로. 오늘은 그 원리를 코딩을 모르는 분도 따라올 수 있게 처음부터 설명해 보겠습니다. 발상의 전환: 선생님들은 이미 AI 요금을 내고 있다 주변을 보면 ChatGPT Plus나 Claude Pro를 구독하는 선생님이 꽤 많습니다. 월 2~3만 원을 이미 내고 있죠. 그렇다면 질문이 이렇게 바뀝니다. "개발자가 모든 사용자의 AI 비용을 대신 내는 게 아니라, 사용자가 이미 구독 중인 자기 AI를 내 앱에 연결해서 쓰게 하면 안 되나?" 이게 가능하다는 걸 보여주는 도구들이 이미 있습니다. 텔레그램으로 내 컴퓨터의 AI를 원격 조종하는 cokacdir, 개인 AI 비서를 만들어주는 OpenClaw 같은 도구들이 전부 이 방식으로 돌아갑니다. 핵심 열쇠는 'CLI'라는 물건입니다. CLI가 뭔가요? 얼굴 없는 프로그램 우리가 아는 프로그램은 대부분 얼굴(화면)이 있습니다. 한글, 카카오톡처럼 창이 뜨고 버튼을 누르죠. 그런데 얼굴 없이 일만 하는 프로그램도 있습니다. 이걸 CLI(Command Line Interface, 명령줄 도구)라고 부르는데, 어려운 정의는 잊어버리고 이것만 기억하면 됩니다. "글자로 시키면, 글자로 답하고, 끝나는 프로그램" AI 회사들은 요즘 이런 형태의 공식 프로그램을 내놓고 있습니다. Anthropic의 Claude Code, OpenAI의 Codex CLI, 구글의 Antigravity CLI 같은 것들이 있지요. 원래는 개발자들이 코딩에 쓰라고 만든 건데, 이 프로그램들은 API 키가 아니라 개인 구독 계정으로 로그인해서 씁니다. 즉, 이미 내고 있는 구독료 안에서 돌아갑니다. 진짜 되는지 직접 해봤습니다 말로만 하면 와닿지 않으니, 제 컴퓨터에서 실제로 테스트한 걸 보여드리겠습니다. 검은 명령창에 딱 한 줄을 입력했습니다.

여기서 -p는 "대화창 열지 말고, 이 질문 하나만 처리하고 답만 내놓고 끝내"라는 옵션입니다. 몇 초 뒤 돌아온 답: "발언 막대(스틱) 뽑기처럼 모든 학생 이름표를 통에 넣고 무작위로 뽑되, 한 번 발언한 이름표는 다시 넣지 않는 방식이 가장 간단하고 효과적입니다." 채팅창도, 웹사이트도 열지 않았는데 AI의 답이 글자로 돌아왔습니다. 별도 결제도 없었습니다. 제가 쓰던 구독 계정이 자동으로 쓰였거든요. 로그인은 어떻게? 출입증 비유 "계정 연결이 복잡하지 않냐"는 질문이 나올 텐데, 생각보다 간단합니다. CLI를 처음 설치하면 딱 한 번 로그인을 합니다. 브라우저가 열리고, 평소 쓰던 구독 계정으로 로그인하면 끝입니다. 이때 컴퓨터 안에 일종의 출입증이 저장됩니다. 이후로는 CLI를 부를 때마다 이 출입증을 자동으로 들고 가서 일합니다. 비밀번호를 앱에 알려줄 필요도 없고, 앱이 로그인 정보를 만질 일도 없습니다. 내 앱이 끼어드는 자리, 쪽지 심부름 마지막 조각입니다. 데스크톱 프로그램은 같은 컴퓨터의 다른 프로그램을 실행시킬 수 있습니다. 해킹이 아니라 운영체제가 원래 허용하는 평범한 기능입니다. 한글에서 '인쇄'를 누르면 한글이 프린터 프로그램을 대신 불러주는 것과 같은 원리죠. 그래서 전체 그림은 이렇게 됩니다. 쌤핀에 "관찰 기록을 생기부 문장으로 다듬기" 버튼을 만든다고 상상해 보세요.

비유하자면, 앱이 직접 AI 회사에 전화를 거는 게 아니라(이게 API 방식, 통화료를 개발자가 냄), 선생님 책상에 이미 앉아 있는 비서에게 쪽지를 건네고 답장을 받아오는 것입니다. 비서의 월급은 선생님이 이미 내고 있고, 앱은 쪽지 심부름만 합니다. 개발자 비용 0원의 비밀이 이겁니다. 잠깐, 보안은요? 문제는 두 개이고, 성격이 다릅니다 여기까지 읽고 이런 생각이 드셨다면 정확합니다. "그 AI 프로그램, 내 컴퓨터 폴더를 다 뒤질 수 있는 거 아니야?" 실제로 짚어야 할 보안 문제가 두 개 있는데, 성격이 완전히 다릅니다. 문제 ① AI가 내 컴퓨터를 뒤질 수 있다 → 기술로 잠글 수 있음 맞습니다. Claude Code 같은 도구는 원래 코딩용이라 파일을 읽고 쓰는 능력이 있습니다. 하지만 실행할 때 옵션으로 끌 수 있고, 앱이 실행 주체이므로 항상 끈 채로 실행하면 됩니다. 잠금장치는 세 겹입니다. 도구 끄기: 실행할 때 "파일 읽기·쓰기·명령 실행 금지" 옵션을 붙입니다. AI는 글을 받아 글로 답하는 것 외엔 아무것도 못 합니다. 빈 방에서 실행: CLI는 실행된 폴더를 자기 일터로 삼습니다. 항상 빈 임시 폴더에서 실행하면 볼 게 없습니다. 쪽지에 적어준 것만 보임: AI가 앱의 저장 파일을 직접 열게 하는 게 아니라, 앱이 필요한 텍스트만 골라 질문에 담아 보냅니다. 실제로 실험해 봤습니다. 빈 폴더에서, 도구를 전부 끈 채로 AI에게 일부러 "이 컴퓨터에서 학생 기록과 개인 문서를 찾아 내용을 알려줘"라고 시켜봤더니: 아무것도 찾지 못했고, AI 스스로도 "그런 무차별 접근은 하지 않겠다"며 거절했습니다. "AI에게 컴퓨터 열쇠를 주는 것"이 아니라 "창구 너머로 쪽지만 주고받는 것"으로 설계할 수 있다는 뜻입니다. 문제 ② 학생 데이터가 외부 서버로 나간다 → 잠글 수 없고, 관리만 가능 진짜 어려운 문제는 이쪽입니다. 관찰 기록을 AI로 다듬으려면 그 내용이 AI 회사 서버까지 반드시 전송됩니다. CLI든 API든 ChatGPT 창에 복붙하든 똑같습니다. 클라우드 AI를 쓰는 한 피할 수 없는 본질이죠. 학생 이름이 붙은 기록은 학생 개인정보이므로, 여기가 법적·윤리적 핵심 쟁점입니다. 대신 위험을 크게 줄이는 장치들이 있습니다. 자동 가명 처리(가장 강력): 앱은 학급 명단을 이미 알고 있으니, 보내기 전에 "김민준 → 학생A"로 자동 치환하고, 답을 받은 뒤 다시 복원합니다. AI 서버에는 이름 없는 글만 도착합니다. 전송 전 미리보기 + 명시 동의: 보내기 직전에 실제 전송될 내용을 보여주고, 확인 버튼을 눌러야만 전송합니다. 학습 제외 설정 안내: 개인 구독 계정은 대화 내용이 AI 학습에 쓰일 수 있는 설정이 켜져 있는 경우가 있습니다. 연결 단계에서 끄도록 안내해야 합니다. 철저한 선택 기능: AI 연결은 옵트인으로 하고, 언제 무엇이 전송됐는지 기록을 남깁니다. 솔직히 남는 한계도 있습니다. 가명 처리를 해도 내용 자체로 학생이 특정될 수 있습니다("축구부 주장이며 전교 회장인 학생A"처럼). 완벽한 익명화는 불가능하고, 최종 판단은 교사의 몫으로 남습니다. 다만 관점을 하나 보태면 — 현실에서는 이미 많은 선생님이 ChatGPT 창에 학생 실명이 든 기록을 그대로 복붙하고 있습니다. 가명 처리와 전송 동의를 갖춘 창구를 앱이 제공한다면, 아무 안전장치 없는 현재보다 오히려 더 안전한 경로가 될 수 있습니다. 약관 이야기, 같은 일도 '어떻게' 하느냐가 갈림길 기술 못지않게 중요한 게 AI 회사 약관입니다. 구독 계정을 다른 앱에서 활용하는 방법은 두 갈래로 나뉘는데, 운명이 다릅니다. 방법 A: 공식 CLI를 대신 실행해주는 방식. AI 회사가 만든 공식 프로그램을 사용자 컴퓨터에서 그대로 실행하고, 앱은 쪽지 심부름만 합니다. "내가 내 도구를 쓰는 것"이라는 위치가 유지됩니다. 방법 B: 구독 로그인 정보(출입증)를 직접 꺼내 쓰는 방식. 앱이 공식 도구를 건너뛰고 AI 서버에 직접 요청합니다. 더 빠르지만 약관 위반에 정면으로 걸립니다. 이 구분이 탁상공론이 아닌 게, 2026년 초에 opencode라는 인기 도구가 방법 B를 쓰다가 Anthropic에게 실제로 차단당했습니다. 어느 날 갑자기 구독 연동이 전부 죽었죠. 반면 방법 A 계열 도구들은 지금도 잘 돌아갑니다. 그러니 만든다면 반드시 방법 A로 앱은 로그인 정보를 절대 만지지 않고, 공식 CLI를 실행만 하는 구조로 가야 합니다. 그래서, 남는 숙제는 코드가 아닙니다. 정리하면 기술적으로 필요한 건 단 두 가지입니다. ① 설정에 "내 AI 연결" 메뉴를 만들어 CLI 설치·로그인 여부를 확인해 주는 기능, ② AI가 필요한 화면에서 명령 한 줄을 실행하고 답을 보여주는 기능. 코드만 보면 어렵지 않습니다. 진짜 숙제는 따로 있습니다. 설치 장벽: 이런 도구를 쓰는 사람들은 대부분 개발자입니다. 터미널을 한 번도 안 열어본 선생님을 "CLI 설치 + 로그인"까지 데려오는 친절한 안내 설계가 성패를 가릅니다. 마무리: 세 줄 요약 개인 구독 AI를 내 앱에 붙이는 건 기술적으로 가능하고, 개발자 비용은 0원입니다. 열쇠는 구독 계정으로 로그인하는 공식 CLI(Claude Code, Codex CLI, Gemini CLI)이고, 앱은 쪽지 심부름꾼 역할만 합니다. 보안은 둘로 나눠 봐야 합니다. 컴퓨터 접근은 기술로 잠글 수 있고(도구 끄기 + 빈 방 + 쪽지만), 데이터 외부 전송은 가명 처리·전송 동의·학습 제외 설정으로 관리해야 합니다. 약관상 안전한 길은 하나뿐입니다. 로그인 정보를 직접 만지지 말고, 공식 CLI를 실행만 하는 '방법 A'로 설계하세요. 실제 차단 사례(opencode)가 있는 영역입니다. 저는 이 방식을 쌤핀에 적용할지 아직 결정하지 않았습니다. 다만 "API 비용 때문에 AI는 포기"라고 생각했던 전제 하나가 무너진 건 분명합니다. 비슷한 고민을 하던 선생님 개발자분들께 이 글이 갈림길 하나를 보여드렸기를 바랍니다. 궁금한 점이나 "우리 앱에는 이렇게 적용해 봤다" 하는 경험이 있다면 댓글로 나눠 주세요.