AI·바이브코딩

(교사가 직접 만든 앱을 학교에서 공식적으로 사용하기 위한 절차를 정리해봤습니다! 본문 중간에 있는 링크를 클릭하시면 바로 확인하실 수 있습니다^^) 선생님들의 순수한 열정, 그리고 도름미(?)로 만드신 앱을 용기내서 학교에 소개하면 현장에선 보안 걱정부터 먼저 고개를 듭니다. 기존의 체계를 바꾼다는건 그만큼의 책임이 따른다고 생각합니다. 결코 가벼운 일이 아니기에 그러한 걱정은 충분히 자연스럽다고 생각합니다. 다만, 실체가 없는 보안 걱정과 실체가 없는 '걱정마세요'는 어떠한 결론을 내리기에도 참 애매하고 서로에게 서운한 감정만 생깁니다. 불행중 다행인 소식은 사실 이미 학교 현장에서 어떤 교육용 소프트웨어를 쓸 수 있냐, 없냐의 명확한 기준이 법적으로도, 교육부 차원에서도 가이드라인이 다 나와있다는 사실입니다. 학교에 공식적으로 도입해서 사용하고 싶은 소프트웨어가 있으시다면 이러한 막연한 보안걱정에 좌절하시기보다는 명확한 기준을 바탕으로 답변하시면 되겠습니다. 흩어진 자료와 법적 근거를 찾고 이해하는게 선생님들이 해야할 본질적인 일은 아니기에 한 곳에 모아 전문가가 아닌 교사도 이해할 수 있도록 정리해봤습니다. 실제로 같은 절차를 거쳐 제가 재직중인 학교에서도 @김태영 태영이와 함께 만든 기숙사 관리프로그램 ZUDO, 그리고 선생님들께서 잘 알고계신 생기부 AI 살핌을 공식적으로 사용하고 있습니다. 모든 내용에는 출처 링크를 걸어두었으니 하나씩 확인하며 공부해보시기 바랍니다. 궁금한 점이나 부족한 부분은 언제든 문의주시면 저 또한 성장하는 데 도움이 될 것 같습니다!

P. S. 창작의 기쁨뒤에는 그만큼의 책임 또한 따르기 마련입니다. 만드신 소프트웨어를 학교에서 공식적으로 사용하시려면 법적인 보안책임자는 당연히 선생님 본인이 되시기 때문에 이 점을 꼭 인지하고 계셔야 합니다. 보안이라는게 완벽한 100%는 없습니다. 저희가 쓰는 많은 플랫폼들도 수시로 해킹 소식이 전해지는것처럼요. 그런데 사실 저희는 교육의 전문가이지 개발 전문가는 아니지 않습니까? 그러니 애초에 털릴 금고 자체를 만들지 않는 구조를 조심스럽게 권해드립니다. 예컨대 생기부 AI 살핌은 학생 개인정보를 저장할 외부 클라우드(DB) 자체가 존재하지 않으며, 각 사용자의 개인 컴퓨터 안에만 저장되고 관리됩니다. (이러한 구조는 또한 학운위 심의 통과 또한 아주 수월합니다.)

방학 기념으로 '교사들만의 AI 커뮤니티 도름스'를 만들게된 스토리를 남겨봅니다! 저는 작년 처음 바이브코딩이 유행할 때, 거창한 사명감보다는 그저 호기심으로 바이브코딩을 시작한 평범한 고등학교 수학 교사입니다. 처음엔 모든게 신기했습니다. '만들어줘'하면 뚝딱 만들어주는거 있죠?! 막 엄청난 코딩이라도 하는 것 같이 있어보이고.. 실상은 AI 없으면 쓸 줄 아는 코드가 5줄 정도인 무지랭이입니다! 다만 저는 평소에도 창작하는걸 좋아하는 사람입니다. 그래서 취미도 음악이에요(음원사이트에 '신창 공개수업'이라고 검색해보시면 앨범도 나옵니다 ㅎㅎ) 바이브코딩을 통해 알게된 것이지만, 결국 코딩이란것도 엄청난 창작의 영역이더라고요! 그게 저를 가슴뛰게 만들었고 이왕 무언가를 만든다면 그래도 저의 도메인인 교육에서 의미있는걸 만들어보자 싶었습니다. 학교에서 정말 많은 시도들이 있었고, 그 뒤 대외적으로? 처음 공개한 앱은 생기부 AI 살핌입니다. 살핌이 주제는 아니니까 어떤 배경으로 만들었는지나 그런건 본 글에서는 생략하도록 하겠습니다. 아무튼 동료 교사와 이런저런 좋은 의도로 열심히 만든 앱을 묵혀두는게 아까워 부끄럽지만 인스타 계정을 만들고 홍보 릴스를 올렸습니다. 무플이면 어쩌나 했는데 걱정이 무색하게 나름대로 많은 관심과 사랑을 받았습니다. 이 앱으로 아무런 수익도 나지 않고 오히려 돈만 잔뜩 썼습니다만.. ㅋㅋ 그만큼 교육 외적인 목적성이 없기에 순수한 취지로 만든 앱이고, 이에 공감해주시는 전국의 많은 선생님들이 오픈 카톡에서 함께하기 시작했습니다. 정신을 차려보니.. 현재는 700명의 선생님들이 참여하는 오픈 카톡의 방장이 됐습니다. 초중고 시절 반장은 커녕 부반장도 한 번 안해본 그림자 같은 사람인데.. 일이 커져버린 것입니다. 학교에서는 무슨 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.

오늘 또 지난주에 이어 도름 선생님들의 귀한 정보가 가득 담긴 연수가 열렸습니다! 김태영 선생님, 홍창욱 선생님, 최시강 선생님, 최진영 선생님, 정유신 선생님께서 나누어 주신 귀한 자료를 한 눈에 보실 수 있게 정리했습니다. 다시 한 번 감사의 인사를 드립니다!🙇🏻‍♀️ 그러나 보시다시피 이 자료만 봐서는 대략적인 흐름만 이해할 수 있으실텐데요, 자세한 내용은 창욱 선생님께서 올리신 직전 글(아래)을 확인하시기 바랍니다! 그리고 자료를 읽어보는 것보다 더 좋은 방법은, 다음에 또 찾아올 DoRm 연수에 직접 참여하시는 것! 3시간 연수가 선생님의 30시간을 줄여줄 거라고 믿어 의심치 않습니다🥰

늘 좋은 마음으로 귀한 정보와 자료를 나누어 주시는 도름 선생님들께 다시 한 번 감사의 인사를 드립니다. 저도 오늘은 수강생이었지만, 열심히 연마(?)해서 다음엔 꼭 연수자로 서보고 싶다는 목표도 다시 한 번 다짐하고 갑니다ㅎㅎ 모두 다음에 DoRm 연수에서 만나요!

자료 공유시 출처와 저작자를 반드시 밝혀주세요! 하네스 엔지니어링이란 AI에게 작업환경을 구축해주는 일을 일컫습니다. 각자가 원하는 AI의 작업 환경은 다르기 때문에 이 영역에 정답은 없다고 생각합니다. 여러 자료들을 훑어보시며 취향에 맞는 부분을 취사 선택하시면 되겠습니다. 사실 바이브코딩 강의는 유튜브에만 검색해도 차고 넘칩니다. 그럼에도 도름스에서 연수를 진행하고 선생님들만의 커뮤니티를 형성하는 이유는 바이브코딩과 교육적 도메인을 함께 고민하는 공간은 많지 않기 때문입니다. 앞으로도 연수가 보다 체계화 되고 선순환 시스템을 구축할 수 있도록 최선을 다하겠습니다. 교육에 AI가 어떻게 들어와야 적절한 것일까?라는 막연한 질문에 답을 교육현장의 주인인 교사들이 직접 찾아나가는 여정에 모두 모두 동참해주세요! 순수하게 열정을 가지고 나눔에 동참해주신 선생님들, 그리고 바쁜 학기말 늦은 시간에도 열심히 강의를 들어주신 선생님들 모두에게 깊은 존경을 표합니다. 개성 넘치는 각 선생님들의 자료가 한자리에 모이니 참 유익한 시간이었습니다! 1. 보평고등학교 김태영 선생님

2. 경기북과학고등학교 홍창욱 선생님

3. 학남고등학교 최시강 선생님

4. 잠원중학교 최진영 선생님

• 학생부 업무, 생활지도 관련한 체계적인 하네스와 에이전트 시스템을 소개해주셨습니다! 조만간 오픈 소스의 형태로 공유주신다고 하시네요 🥹

5. 포항중앙고등학교 정유신 선생님

지난 강의 자료 1. DoRm 1주차 바이브코딩 입문 강의 - 김태영 선생님의 바이브코딩 무작정 따라하기

-연수 원고 📂

2. DoRm 바이브코딩 기초 강의 자료 공유(3차시) - 홍창욱

앤트로픽이 미국에서 인증된 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

바이브코딩을 전혀 접하지 못한 '진짜' 입문자를 위한 학교 현장 비유를 기반으로 한 강의자료! 조금이라도 바이브코딩을 해보셨던 분들이라면 절대 보지 않으셔도 됩니다. 아예 처음 시작하고 싶은 선생님들만 살펴보시길 추천드려요. 2탄도 곧 업로드 예정입니다.

링크 :

하하.. 😅

도름스에 앱이 점점 쌓이면서 점점 각 선생님들이 가지신 비전에도 교집합이 생겨나는 것 같습니다. 🌀 비슷한 문제의식과 해결 방식을 지닌 앱들도 늘어나고 있는 것 같습니다. 이번 기회에 도름스 선생님들의 합작 프로젝트가 탄생하면 어떨까요? 그건 단순히 혼자 할 수 없었던 한단계 성장한 앱을 만드는 결과 뿐 아니라 엄청난 배움의 계기가 될 것이라고 확신합니다. 함께 프로젝트를 만들면서 논의를 하고, 때로는 논쟁도 생기고, 또 동료의 작업 방식을 엿보고 하다보면 서로 성장할 수 밖에 없더라고요. 제가 처음 본격적인 바이브코딩 프로젝트를 진행했던 시작은, 운좋게도 @김태영 태영이와 협업하여 저희 학교 기숙사 관리 프로그램 ZUDO를 만드는 작업이었습니다. 이미 태영이가 구축한 ZUDO라는 프로젝트에 중간에 들어갔어요. 시작을 협업으로 했다는건 참 운이 좋았던것 같습니다. 선생님들도 도름스에 수많은 인력풀을 활용하셔서 협업에 도전해보세요! 바이브코더 맞춤 GitHub 협업 방식을 정리해봤습니다. 궁금한 점은 언제든 말씀해주세요!

이 문서는 워싱턴대학교 연구진의 논문 《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/

도름스로 열심히 활동중이신 일원분들 중 링크트리 예쁘께 꾸미고 싶으신 분 계시다면 활용해주세요! 링크트리를 맞추면 뭔가 다 함께 소속감도 생기고 좋지않을까 해서 공유드려요 ㅎㅎ 바이브코딩 AI 툴에게 깃헙 링크 알려주시고 거기 프롬프트 마크다운 파일을 읽어보라고 하면 선생님 블로그, SNS 등 설문하면서 링크 트리를 선생님에 맞게 맞춰나갈 수 있도록 안내해줄거에요. 색상조합도 취향에 맞춰 변형해보세요 ㅎㅎ 링크트리 만드신 분들은 저에게 말씀해주시면 하루에도 수많은 외부 샘들께 보내지는 도름스 링크트리에 선생님들 링크트리로 넘어가는 버튼도 만들어두겠습니다. 헤헤

하나의 주제를 바탕으로, 지금까지 만든 결과물들이 어떻게 탄생하게 됐는지 개인적인 경험을 담았습니다. 대단한건 없지만 바이브코딩 하는 평범한 교사가 어떤 생각을 가지고 일을 벌려(?) 왔는지 살펴보시죠!

제목이 좀 자극적이긴한데.. AI 시대의 중요한 가치에 대해 이야기하는데 너무 유익해서 공유드려 봅니다.. 끝까지 보면 넘 좋을거 같습니다 구글X CBO 인터뷰입니다 인간적 교감과 관계는 AI가 대체할 수 없다 AI로 일을 편하게 하려 하는게 아닌, 더 똑똑하게 하려고 하라 문서 편집 소프트웨어를 다운로드 받아 쓸 필요가 없는 시대, 5분이면 만들어내는 시대의 일자리 변화 등에 대해 이야기합니다

커서를 활용하여, 교과 게임을 진행하는 프로젝트 초안을 공유합니다. 아직 지필평가가 끝나지 않은 시점, 준비 과정에서 공유하는 프로젝트 입니다. 조금 더 다듬어야 할 부분이 많지만, 다른 교과에서도 이런 식으로 진행해볼 수 있을 것 같아서 올려보아요! 가이드 파일은, 학생들에게 공유되는 파일입니다. 해당 페이지에서, 프로그램을 제작하는 단계적 프롬프트를 확인할 수 있습니다. 교사용 파일은, 수업 기획 시 참고할 수 있는 교사용 가이드 파일입니다. 수업 단계, 차시에 따라 선생님이 어떤 과정으로 운영해야 하는지에 대한 초안이 담겨있습니다. 저는 지리과인데요, 사용중이신 ai 툴에 두 파일을 넣고, 해당 교과에 맞는 주제로 개편하시면, 될 것 같습니다! 부디,,, 성공적인 수업을 진행하여 도름스에서도 수업 후기를 공유해보고 싶네요 ... ㅎㅎ 혹여나 활용하시는 분들도, 사례 나눔 해주시면 좋을 것 같습니다 ^_^...!!!

클로드코드와 함께 열심히 구축한 클로드코드 맞춤 하네스를 코덱스가 그대로 따르게만 해놨는데요 아이러니 하게도 코덱스가 작성 당사자인 클로드 코드보다 하네스를 훨씬 잘 준수하네요.. 이게 무슨 일이람? 클로드코드로 AI와의 협업 구조를 만든 다음 일은 코덱스를 시켜야 하는건가요..? ㅋㅋㅋ 그래도 아직 저는 클로드코드와의 협업이 더 익숙하고 자연스럽긴 합니다 특히 글 적는거나 인간적인 컨택은 클로드코드가 훨씬 자연스럽긴해서.. ㅎㅎ 샘들은 어떤걸 더 선호하시나요?

학교에서 사용할 수학 학습 플랫폼을 만들고 있는데요, 만약 타학교 사람이 쓰게될 때 데이터베이스를 따로 구축할 수 있는 쉬운 방법이 있을까요? 개인정보 수집하고싶지 않아서요. 지금 개발자, 학교 데이터베이스는 따로 구축해놨는데 학교데이터베이스에 거의 대부분이 들어있는거라 타학교에서 사용하려면 이 데이터베이스랑 똑같이 구축해야 할텐데 가능할까요? supabase 사용중입니다. 개인정보와 보안이 너무너무 어려워요 어떤 구조로 배포하는게 좋을까요.

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

너는 보안 코드 리뷰어이자 오픈소스 저장소 감사자다. 나는 GitHub 저장소의 코드를 내 컴퓨터에서 실행하거나 설치하기 전에 보안 위험을 점검하려고 한다. 아래 저장소 또는 코드 파일을 분석해서 악성 코드, 개인정보 탈취, 토큰 유출, 시스템 손상, 백도어, 의심스러운 네트워크 통신 가능성을 검토해줘. 검토할 때 다음 기준을 반드시 적용해라. 1. 실행 전 위험 요소 점검

• 설치 명령어가 안전한지 확인해라.
• npm install, pip install, curl, wget, bash, sh, powershell, npx, docker 실행 과정에서 위험한 부분이 있는지 확인해라.
• README에 적힌 실행 명령어가 실제 코드와 일치하는지 확인해라.
• 사용자가 무심코 복사해 실행하면 위험할 수 있는 명령어를 찾아라.

2. 의심스러운 코드 패턴 탐지 다음과 같은 코드가 있는지 찾아라.

• os.system, subprocess, exec, eval, Function, childprocess, spawn, shellexec
• curl 또는 wget으로 외부 스크립트를 받아 즉시 실행하는 코드
• base64, hex, 난독화된 문자열, 알 수 없는 긴 문자열
• 환경변수, API 키, 토큰, 쿠키, 브라우저 세션, SSH 키, .env 파일을 읽는 코드
• 사용자 홈 디렉터리, Downloads, Desktop, Documents, AppData, .ssh, .aws, .config 접근 코드
• 외부 서버로 데이터를 전송하는 코드
• 알 수 없는 IP 주소, Discord webhook, Telegram bot, pastebin, gist, ngrok, cloudflare tunnel 같은 외부 전송 경로
• 자동 업데이트, 원격 코드 실행, 백도어 가능성이 있는 코드
• 패키지 설치 시 실행되는 postinstall, preinstall, setup.py, pyproject.toml, package.json scripts 코드

3. 권한과 데이터 접근 범위 분석

• 이 저장소가 내 파일 시스템에서 어디까지 접근하려 하는지 설명해라.
• 인터넷 연결이 필요한지 확인해라.
• 외부 서버로 어떤 데이터를 보낼 가능성이 있는지 분석해라.
• 내 API 키, OpenAI 키, Supabase 키, Firebase 키, Google OAuth 정보, GitHub 토큰 등이 노출될 위험이 있는지 확인해라.

4. 의존성 위험 분석

• package.json, requirements.txt, pyproject.toml, Dockerfile, docker-compose.yml이 있다면 위험한 의존성이 있는지 검토해라.
• typosquatting 가능성, 즉 유명 패키지와 이름이 비슷한 가짜 패키지 가능성을 확인해라.
• 너무 오래되었거나 유지보수되지 않는 패키지가 있는지 확인해라.
• 설치 시 자동 실행되는 스크립트가 있는지 확인해라.

5. 안전 실행 가이드 제시 위험도가 낮더라도 바로 실행하지 말고, 다음 순서로 안전하게 실행하는 방법을 알려줘.

• 코드를 먼저 읽는 순서
• 의존성 설치 전 확인할 파일
• 가상환경 또는 Docker에서 격리 실행하는 방법
• 네트워크 차단 또는 제한 실행 방법
• .env 파일을 만들 때 주의할 점
• 실제 API 키 대신 테스트 키를 쓰는 방법
• 실행 후 삭제하거나 회수해야 할 토큰

6. 최종 판정 마지막에 아래 형식으로 요약해라. [위험도] 낮음 / 보통 / 높음 / 매우 높음 중 하나 [실행 가능 여부] 바로 실행 가능 / 격리 환경에서만 실행 / 실행 보류 / 실행 금지 중 하나 [가장 위험한 부분 3개] 1. 2. 3. [안전하게 실행하려면] 구체적인 단계별 조치 제시 [내가 반드시 확인해야 할 파일] 파일명과 이유를 함께 제시 중요: 확실하지 않은 부분은 추측하지 말고 “확인 필요”라고 표시해라. 코드 일부만 보고 전체가 안전하다고 단정하지 마라. README 설명만 믿지 말고 실제 코드 기준으로 판단해라.

2025년 iOS, iPadOS, MacOS 등에서 업데이트된 [글래스모피즘] 이라 불리는 '투명 유리 테마' 디자인이 저는 너무 예쁘더라구요 ㅎㅎ 그래서 이후에 웹 페이지를 만들 때 이게 잘 활용되면 너무 좋겠다는 생각을 해왔습니다. 잘 모르고 일단 들이박고보는 성격이 있는지라 토큰 어마어마하게 써대가면서 구현을 시도했고 어느정도 자리잡힌 지금 프롬프트를 정리하여 여기에 공유해봅니다 ㅎㅎ 아래에 프롬프트 전문을 첨부합니다! 그리고 Cursor AI 에게 프롬프트와 지시사항 1회 제공 후 만들어진 결과물도 공유합니다. 저의 지시사항이 애매했던지라 컨텐츠를 화면에 구성하는 것에는 부족함이 많지만 [글래스모피즘] 자체는 너무나도 잘 구현된 것 같아요. 투명한 배경 뒤의 디자인 요소가 흐릿하게 비치는 점, 돋보기 확대경이 유리느낌으로 잘 표현되고있는 점 등 ㅎㅎ 디자인 지침에 프롬프트를 활용하셔서 이 후에 다양한 프로그램 개발에도 쓰일 수 있다면 너무 뿌듯할 것 같습니다 ^__^ p.s. 혹시나 글래스모피즘에 특허가 있을까 해서 이를 피해달라는 요청도 했었는데.. 애플도 이 디자인 주인이 아니고 어디서 베껴왔다고 피소당한 상태라고 하네요 ㅋㅋㅋㅋ 창작이 아닌 아이디어의 영역이고 일반적인 기술로 누구나 구현 가능한 단계기 때문에 막 사용해도 아무 문제 없다고 합니다 하하! ===== 프롬프트 ===== [디자인 방향: 프리미엄 글래스모피즘 / "유리 느낌" UI] 이 프로젝트의 UI는 애플의 Liquid Glass에서 영감을 받은, 깊이감 있는 글래스모피즘 스타일로 구현한다. 단, 애플의 어떤 에셋·서체·아이콘·private API도 사용하지 않고 오직 표준 웹 기술(CSS backdrop-filter, SVG 필터, WebGL)로만 독자 구현한다.

핵심 철학

• "장식이 아니라 계층 표현 도구로서의 깊이." 블러를 제거해도 정보 위계가

이해되어야 한다. 유리 효과는 절제해서 선택적으로만 적용한다.

• 글래스는 다음에만 적용: 내비게이션 바/탭바, 모달·오버레이, 플로팅 카드,

미디어 위 컨트롤, 핀 고정 헤더, 컨텍스트 메뉴/툴팁.

• 글래스를 적용하지 말 것: 데이터 테이블, 빽빽한 본문 텍스트, 콘텐츠 본문 레이어,

유리 위에 또 유리를 겹치는 중첩.

배경 (글래스모피즘의 생명)

• 단색 배경 금지. 풍부한 그라데이션 또는 방사형 글로우 블롭을 의도적으로 배치한다.
• 예: 딥 네이비/인디고 베이스(#0f172a 계열) + 두 개의 radial-gradient 글로우.
• 유리 패널 바로 아래는 명암 변화가 급격하지 않게 배경을 구역화한다.

유리 표면 디테일 (단순 블러를 넘어서)

1. backdrop-filter: blur(12–16px) saturate(160–180%) ← saturate 필수(회색조 방지) 반드시 -webkit-backdrop-filter 도 함께 작성. 2. 반투명 배경 fill: 다크 모드 rgba(255,255,255,0.06–0.12), 라이트 모드 rgba(255,255,255,0.5–0.65) (라이트는 alpha를 높여야 효과가 보임). 3. 테두리: 1px, 상단(border-top)을 더 밝게 줘서 광원 방향감 부여. 가능하면 그라데이션 테두리(linear-gradient border-box)로 굴절감 추가. 4. 다층 box-shadow: 외부(부유감) + inset 상단(내부 반사) + inset 하단(내부 그림자). 5. 미세 노이즈 텍스처: SVG feTurbulence를 1–2% opacity, mix-blend-mode: overlay로 오버레이해 진짜 유리 질감을 낸다. 6. (선택, 고급) Liquid Glass 굴절감: SVG feDisplacementMap 또는 WebGL 셰이더로 가장자리 렌즈 굴절·specular highlight를 근사. backdrop-filter와 filter는 같은 요소에 동시 적용 불가하므로 별도 레이어로 분리한다.

라이트/다크 모드

• :root CSS 변수(--glass-bg, --glass-blur, --glass-border, --glass-shadow,

--glass-radius, --glass-text)로 중앙 관리. prefers-color-scheme로 전환.

• 다크 모드: blur에 brightness(1.05) 추가, 림 라이트는 순수 흰색 대신

네이비/바이올렛/틸 색조.

• border-radius 16px 기본, 모서리 동심원(concentricity) 유지.

모션 / 마이크로인터랙션

• 호버 시 background alpha 소폭 증가 + translateY(-2px) + scale(1.01) +

shadow 강화. 부드러운 ease 트랜지션.

• 절대 금지: backdrop-filter(blur 값) 자체를 transition/animation 대상으로 삼는 것

(GPU 비용 폭증). opacity/transform/background만 애니메이션한다.

접근성 (필수)

• 유리 위 텍스트는 WCAG 4.5:1 대비 충족. 미달 시 text-shadow 또는 텍스트 영역에

반불투명 딤 레이어 추가.

• @supports로 backdrop-filter 미지원 시 불투명 배경 폴백 제공.
• @media (prefers-reduced-transparency: reduce) → 불투명 전환.
• @media (prefers-reduced-motion: reduce) → shimmer/모션 비활성화.

성능

• 블러 16px 이하(모바일), 동시 활성 유리 레이어 2개 이하.
• will-change: transform; contain: layout style paint; 로 합성 최적화.

법적 안전 (반드시 준수)

• SF Symbols 사용 금지 → Lucide / Phosphor / Heroicons / Tabler 사용.
• San Francisco(SF Pro) 서체 사용 금지 → Inter / Geist / Pretendard /

Noto Sans KR 사용.

• 애플 로고·시스템 아이콘·UI 스크린샷 복제 금지.
• -apple-visual-effect 등 애플 private CSS 사용 금지.
• "Liquid Glass" 등 애플 상표명을 제품·기능 이름으로 쓰지 말 것

(내부 코드 주석 수준은 무방).

• 자체 브랜드 색상·아이콘·서체로 독자적 비주얼 아이덴티티를 유지해,

애플 UI와 혼동되지 않게 한다. 이 프롬프트를 바탕으로 웹으로 살펴보는 식당 메뉴판 페이지 디자인해줘. 마우스 커서를 따라다니는 돋보기가 메뉴판에 풍성하게 존재하는 다양한 음식들에 닿을 때마다 그 음식의 디자인을 돋보기 안에서 확대해서 보여주고 돋보기 옆에는 해당 음식의 가격과 영양정보가 말풍선 텍스트로 나오도록 구현해줘. ========= 프롬프트 끝 ===========

교사가 잡무를 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기본법 고영향 규제' 밖입니다. 겁먹을 필요 없어요. 대신 만들 때 딱 다음 세 가지를 챙기면 됩니다. ①교사를 진짜 최종 결정자로 ②개인정보는 안 모으는 설계 ③생성형 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 디자인을 탐지하고, 전문 디자이너가 작업한 것처럼 개선해주는 오픈소스입니다. 코딩 에이전트한테 이 깃허브 리포지토리 링크를 던져주고, 선생님들께서 개발하신 웹/앱의 디자인을 점검하고 개선해보세요. 저는 주기적으로 이걸 활용해서 디자인을 검토합니다 ㅎㅎㅎ

재밌는데 의외로 유익해요 ㅋㅋ 개인적으로 지금까지 바이브코딩을 하면서 느낀 점은 UI/UX, 보안 쪽은 따로 공부가 필요하구나 였습니다. AI는 구조상 UI/UX에 있어 완벽할 수 없더라고요. 영상을 보는것만으로도 앞으로 작업하시면서 한 번쯤 고민하며 만들게 되지 않을까하여 공유드립니다 🙂

서울: sonline20.sen.go.kr, .sen.ms.kr, .sen.es.kr, .sen.hs.kr 부산: (없음) 대구: dge.go.kr 인천: gclass.ice.go.kr 광주: gsuite.gen.go.kr 대전: dje.go.kr, djsch.kr, .djsch.kr 울산: (없음) 세종: edu.sje.go.kr, .sjedues.kr, .sjedums.kr, .sjeduhs.kr 경기: goedu.kr, goe.go.kr, .goe.go.kr 강원: (없음) 충북: cberi.go.kr 충남: g.cnees.kr, g.cnems.kr, g.cnehs.kr, .cnees.kr, .cnems.kr, .cnehs.kr 전북: (없음) 전남: e.jne.go.kr, m.jne.go.kr, h.jne.go.kr 경북: .gyo6.net 경남: gne.go.kr, g.gne.go.kr 제주: onedu.jje.go.kr === 이렇게 조사했는데 맞을까요? 오류나 추가사항 있으면 댓글로 알려주세요! 혹시나 개발하시다 필요하시면 활용하세욥 ㅎㅎ 참고로 학생들도 활용하는 도메인이다보니 교사인증용으로는 한계가 있습니다만 학교 구성원 인증은 이거로 가능할듯 합니다

📌쌤핀 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 비용이 나가는 건 무지하게 싫은 박준일이었습니다 ㅎㅎㅎ

좋은 클로드스킬 발견했어요 Claude 리서치 자동화 — 진짜 논문 수준의 결과가 나올까? 한국 개발자 중 학술 자료 쓸 일 있는 사람들 봤는데 대부분 손으로 하거든. 이 레포는 5단계(research write review revise finalize)를 한 번에 자동으로 처리함. 내가 본 코드 샘플도 형식이 깔끔하고 리뷰 단계가 실제로 피드백 제시함.

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

첫낚시 서비스

안녕하세요, 경기도에 근무하는 국어교사입니다. 처음으로 인사드립니다^^ 같은 고민을 나누는 커뮤니티가 생겨 좋습니다. 활발히 활동하겠습니다. 잘 부탁드려요~ 최근에 진행했던 업무 간소화 작업들의 진행담을 소개해드리고자 글을 남깁니다. 저는 요즘 교사 업무를 조금이라도 덜어보려고 여러 가지 자동화 실험을 해보고 있습니다. 제가 요새 가장 느끼는 업무 장벽은 쏟아지는 메신저 관리였습니다. 하루에도 몇 십개씩 날아오는 쪽지들.. 마감일을 지나치거나 놓치는 경우가 워낙 많더라구요. 어떻게 하면 메시지를 잊지 않고 관리할 수 있을까 하는 생각이 들었습니다. 물론 시중에 나와 있는 수많은 일정 관리 어플이나 교무수첩에 메시지 내용을 기록하면 잊지 않겠지만, 안 그래도 바쁜 와중에 메시지 내용을 하나하나 기록하는 것이 여간 귀찮은 게 아니더라구요. 그래서 메신저의 내용을 에이전트가 읽고 일정 관리 어플에 자동으로 등록할 수 있을까 하는 생각이 들었습니다. 그렇다면 데스크톱 / 폰 모두에 메신저 내용이 어플을 통해 기록되고 알람까지도 받을 수 있지 않을까 싶었습니다.

여러 어플을 찾아보다가 TickTick이라는 일정 관리 어플을 이용해보기로 했습니다. 사실 제공하는 기능(할일 목록, 달력, 아이젠하워 매트릭스 등)이나 UI/UX가 괜찮아 유료 결제하고 사용하던 어플이었습니다. 무엇보다 중요한 것은 다양한 기기 환경을 지원하다는 점과, 공식적으로 CLI와 MCP를 지원하여 에이전트에 물리기가 수월했다는 점이 컸습니다. (광고는 절대 아닙니다. 부족한 면도 많습니다. 한국어 입력이 가끔 씹히거나 그런거...?) CLI를 지원하는 어플이면 다 가능할 것 같습니다.

메신저 내용 자동 등록은 Hermes Agent의 크론잡을 활용해 실험해 보았습니다. 간단히 말하면, 본인에게 온 학교 메신저의 새 메시지를 5분마다 확인하고, 그중 업무성이 있는 메시지를 AI가 분류하는 구조입니다. 제출, 회신, 확인, 참석, 준비, 신청, 입력, 작성, 검토처럼 실제 행동이 필요한 메시지를 후보로 뽑고, 가능하면 마감일과 우선순위도 함께 정리합니다.

현재는 일정 시간마다 새 메시지를 확인하고, 업무 후보를 추출한 뒤 TickTick에 등록하는 방식으로 사용하고 있습니다. 단순히 마감이 있는 일정만 찾는 것이 아니라, 누군가 저에게 문의하거나 확인을 요청한 메시지도 회신 업무로 잡도록 했습니다. 첨부파일이 있는 경우에는 파일명과 다운로드 상태도 함께 표시되도록 했습니다.

처음부터 바로 자동 등록을 한 것은 아니고, hermes 에이전트를 discord에 연결한 뒤 dry-run 검증 단계를 두었습니다. 어떤 메시지가 업무 후보로 잡히는지 먼저 확인하고, 오등록 가능성을 줄인 뒤 점진적으로 자동 등록 범위를 넓혔습니다. 등록 결과도 따로 디스코드 알림으로 받아볼 수 있게 해서, 어떤 업무가 TickTick에 들어갔는지 확인할 수 있도록 했습니다. 이런 점에서는 자가 개선이 핵심인 헤르메스 에이전트가 빛을 발했습니다. 물론 조심해야 할 부분도 있습니다. 메시지에는 개인 정보에 관련한 내용이 종종 섞여 있는데 이러한 프로세스가 개인정보 보호나 보안 정책에 어긋나는지는 확인하지 못했습니다. 교사 개인 업무 흐름을 AI로 개선해 본 하나의 실험 사례로 봐주시면 좋겠습니다. 관련된 정책을 잘 알고 계시는 분께서는 말씀해주시면 감사드리겠습니다. 이번 실험을 하면서 AI 활용이 꼭 수업 자료 생성이나 글쓰기 보조 등에만 머무를 필요는 없다는 것을 느꼈습니다. 교사가 자기 업무 흐름을 잘 관찰하고, 반복되는 불편함을 발견하면, 바이브코딩을 통해 꽤 실용적인 개인 업무 도구를 만들 수 있습니다. 완벽한 프로그램을 처음부터 만드는 것보다 중요한 것은 업무에서 반복적으로 나를 피곤하게 하는 지점이 어디인지 찾고, 그것을 조금씩 줄여보는 경험인 것 같습니다. 혹시 선생님들은 일정이나 할 일 관리를 어떤 방식으로 하고 계신가요? 또 학교 업무 중 AI나 자동화로 줄여보고 싶은 부분이 있으신지도 궁금합니다.

0. 본 수업의 목적은 학생들이 바이브코딩을 통해 수학 문제 및 개념 이해를 돕는 시각화 자료를 만들어 보면서, 학생들의 창의력과 수학적 역량, AI 활용 역량을 평가하기 위함입니다. 꼭 수학 수업이 아니더라도 적용이 가능한 방식의 수업일 것 같습니다. 저희 학교 학생들은 이 수업을 통해 모두 바이브코딩을 한 번 쯤 경험해보게 됩니다. 비록 아직은 라이트하게 html 파일 하나 만들어보는 경험이지만.. 시작점으로는 적당하다고 생각합니다. 적당한 프롬프트와 학생들이 함께 쓸 오픈라우터 키(총알)만 있다면 도전해볼 수 있는 수업입니다! 1. 수업 때 학생들과 같은 와이파이에 연결하면 사이트에 접속할 수 있습니다.

(와이파이 연결을 끊고, 터미널 실행을 멈추면 더 이상 제작 사이트에 학생들이 접속할 수 없는 내부망입니다. 제 컴퓨터의 실제 IP가 아닙니다!) 2. 학생들이 주소에 접속하면 저의 오픈라우터 API키로 호출 가능한 챗봇이 셋팅되어있습니다.

• 교과 수업 활용 목적으로 학교 예산 10만원 가량을 품의 결재 받고 사용해요. gemini 가성비 모델을 사용하는데 퀄리티가 나쁘지 않고 두시간 수업해도 학급당 만원이 안나옵니다. ㅎㅎ

• 처음에 문제를 올려 달라고 합니다. AI는 풀이를 제공하지 않도록 프롬프팅 되어 있습니다. 학생이 직접 풀이를 해야 하고, 풀이가 틀린 경우 AI가 힌트를 주는 등 과외 선생님 역할(?)을 합니다. 풀이가 확정되고나면 시각화 자료를 함께 만들자고 AI가 제안합니다. 그때부터 본격적인 바이브코딩(?) 시간이 됩니다.

3. 작품이 완성되고나면 갤러리에 업로드하고 다 함께 공유합니다. 똑같은 문제의 풀이에 대해서, 특별한 지시가 없는 경우 동일한 형태의 html이 완성되고, 자신만의 창의적 아이디어를 프롬프트로 넣은 경우 보다 독창적인 결과물이 나오게 된 것을 확인할 수 있습니다. P. S. 학생들 결과물 몇 가지를 공유드립니다!!

혹시 궁금하신 분들은 소스 코드를 오픈 소스로 공유드릴까 합니다. 필요한 분들이 계실까요?

@뚠뚠한김햄찌 선생님의 글을 읽고 5분 바이브코딩 해봤습니다 :) 저는 작년에 1년짜리 제미나이를 구독해버린지라ㅠ 거기에 그냥 생각나는대로 와다다다 일단 프롬프트를 쳐보았고 이 프롬프트로 만들어진 최초버전파일인데 꽤나 익숙하네요 ㅎㅎ 살펴보시고 이걸 시작으로 또 다듬어보신다면 가계부 앱도 꽤나 도움이 될 듯 합니다 ?! ====================== 제미나이에게 1회 제공한 프롬프트 -------------------------------- 용기를 얻어 학교와 정말 아무상관 없는 것에 대해 여러분의 의견을 물으려 합니다 ㅎㅎ 제가.... 가계부를 본격적으로 쓰고 싶은데요... 어릴 때 종이로된 가계부도 써봤고... 얼마전까지는 앱으로 된(착한가계부) 가계부도 열심히 써봤는데... 살짝 도움이 안되는 것 같아서... 혹시 가계부 쓰는 방법 추천해주실 분 계신지요? 요새 기웃거리고 있는 것은 엑셀 형태로 2만원대에 네이버에서 가계부 형식을 파는 게 있더라구요... 구글 시트로 해서 폰에서도 쓸 수 있다고 해요..... (구글시트 형태, 완전 엑셀 파일 선택 가능...) 사고 싶은데 사서 쓰지 않을까봐.... 계속 고민만 하고 있습니다. ㅎㅎ 정보 선진화(?)교사분들께 묻습니다. 가계부 어찌해야 하나요 ㅎㅎ 제가 과연 저 엑셀을 사면 잘 쓸까요? ㅎㅎ 앱으로 몇 년 잘 쓰다가 안드로이드 폰에서 아이폰으로 갈아타면서 갑자기 안쓰고 있어요 ㅠㅠㅠㅠ 이런 고민을 가진 선생님에게 추천할만한 가계부를 만들어줘. 이 분이 참고하고자 했던 가계부 앱, 프로그램들의 스타일을 반영해줘. 1. UI 는 숫자가 잘 보이는 형태여야해. 2. 수정이 간편해야하며, 가계부 작성에 유용하고 유의미한 기능이 무엇이 있을지 추론해서 반영해. 3. 날짜별로 가계부를 정리할 수 있게 해주고 주제별로 가계부를 정리할 수 있게 해줘. 4. 주제는 사용자가 직접 입력해서 추가할 수 있도록 해주고, 사용자가 추가한 주제들은 가계부 작성시에 드롭다운 형태로 선택할 수 있게 해줘. 5. 날짜와 주제는 서로 연결되어 있어서, 어디를 기준으로 하든 상호간에 내용 참조가 이루어질 수 있도록 해줘. 6. 가계부에 정리된 내용들에 적합한 막대그래프, 원형그래프, 꺾은선 그래프 시각화가 이루어져야하고 파스텔 톤의 다양한 색으로 직관적인 분석이 가능하게 해줘. 7. 생성된 가계부는 일상을 설계하는 자료로 쓰이니까 가계부가 날짜별로 혹은 주제별로 생성될 때 사용자의 한마디를 작성할 수 있는 메모칸도 만들어줘. 8. 폰트는 손글씨체를 사용해주고 말투는 '토스 앱'과같은 친절한 말투를 사용하자. ----------------- ===================

바로 '분리수거' 작업이라고 생각합니다. Open AI 개발자 표현을 빌려봤는데요. 저는 하나의 세션을 통해서 제가 원하는 기능이 완성 되고 나면 전역에 만들어둔 분리수거 스킬을 호출합니다. 그 세션 동안 저와 클로드가 나눈 대화를 모두 전사하며 대화와 작업에 어떤 마찰들이 있었는지 돌아보고, 전역 또는 프로젝트 하네스에서 원인을 찾고 유지보수 하는 스킬입니다. 어떤 형태로든 이러한 메타 하네스(?)는 꼭 구축하시길 강추드립니다. 계속 하다보면 나중엔 분리수거 할 필요가 점점 줄어들고 제 AI가 점점 똑똑해지는걸 느낍니다. 하네스 엔지니어링의 본질은 결국 '같은 실수를 두 번 하지 않게, AI가 딱 내가 원하는 방식으로 일하게' 만드는 시행착오 과정인 것 같습니다. 🧐 이미 비슷한 셋팅을 해두셨다면 꿀팁 혹은 인사이트를 댓글에 공유 해주세요 🥺

자유게시판에서 바이브코딩 관련 글의 분량이 다소 많은 편이라 아예 따로 빼버렸습니다! 일단 저부터.. 바이브코딩 글을 잔뜩 적다보니.. ㅋㅋ 이제 맘평히 바이브코딩 이야기를 이 공간에 나누셔도 좋습니다 👏

내가 만든 데스크톱 앱에 개인 구독 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는 포기"라고 생각했던 전제 하나가 무너진 건 분명합니다. 비슷한 고민을 하던 선생님 개발자분들께 이 글이 갈림길 하나를 보여드렸기를 바랍니다. 궁금한 점이나 "우리 앱에는 이렇게 적용해 봤다" 하는 경험이 있다면 댓글로 나눠 주세요.

'친절한 말투를 사용해줘' 혹은 '친근한 표현으로 작성해줘' 같은 프롬프트는 사실 많이많이 추상적입니다. 사람 사이에서 친절한 사람과 친근한 사람의 기준이 다른 것 처럼요! 이런 모호함이 AI에게도 적용되기 때문에 때로는 격식을 차리는 친절한 표현을 쓸 때가 있고 '대박 ㅋㅋㅋ' 이런 가벼움 쪽의 친근함을 보일 때도 있습니다. 이 때 꿀 팁이 될 수 있겠습니다! '친근한 표현을 쓰되 '토스 앱'처럼 해줘' 라고 해주시면 너무 좋더라구요 ^_______^ 다시 위의 사진을 보시면 토스 앱을 쓰시는 분들은 '아? 어쩐지 어디서 본 듯한 말투네' 라는 생각이 드실 겁니다 ㅎㅎ 구체적인 요구사항을 추상적인 표현으로 설명할 수밖에 없을 때는 레퍼런스(참고할 만한 다른 사례)를 프롬프트에 제공하면 AI는 보다 정교한 결과물을 내어놓습니다! (e.g. '느낌있는 디자인으로 해줘' -> '내셔널 지오그래픽 로고 색 조합을 기본 테마로 정해줘')

1차시는 바이브코딩을 할 수 있는 모든 환경설정, 그리고 간단한 체험을 해볼 수 있는 차시입니다. 클로드 또는 챗지피티 사용하고 계신 AI에게 해당되는 .md 문서를 던져주고 엔터치시면 가이드가 시작됩니다. 2차시는 바이브코딩을 이해하기위한 기초 용어들을 다뤄보고 실제 나만의 사이트를 만들어 배포해보는 수업입니다.

3차시는 바이브코딩 AI를 잘 다룰 수 있는 역량을 길러보는 하네스 엔지니어링 기초 강의입니다.

이 자료 말고도 바이브코딩 관련한 강의자료를 꾸준히 올려드릴 예정입니다. 제 생각에 요정도 공부하면 정말 기초적인 사용법은 이해하고 있다고 볼 수 있지 않나 해서 구성해본 3차시 수업자료입니다..! 공유는 얼마든지 하셔도 괜찮지만, 출처만 잘 남겨주시기 바랍니다. 감사합니다 .^^

@지오퍼스 선생님께서 UI 디자인 관련 질문해주셔서 모든 분들께 설명드려요..! UI라는건 창작의 영역이고, 음악이나 디자인이나 제가 전공자는 아니지만.. 이러한 영역은 결국 래퍼런스가 꼭 필요하더라고요. 모방은 창작의 어머니라고.. ㅎㅎ.. 그리고 AI는 확률 높은 선택을 하는 기계이기 때문에 AI에게 디자인을 맡기면 필연적으로 결과물이 마음에 안들 수 밖에 없습니다. 우리가 예쁜 디자인이라고 인식하는건 흔한 디자인과는 괴리가 있기 때문이에요. AI에게 래퍼런스를 던져주는 방법은 정말 다양할 수 있으니 선생님들의 아이디어나 방법도 공유해주세요! 간편한 방법의 사이트 하나 공유드려보자면

요 사이트 추천드립니다..! 디자인 래퍼런스를 프롬프트 형태로 바로 copy 할 수 있게 도와줘요. 무료 템플릿도 쓸모있는게 많습니다. ㅎㅎ 살핌 랜딩 페이지의 각종 손글씨 느낌도 여기서 출발해서 만들었어요!

방과후에서 활용한 수업자료 공유드립니다. 똑같은 프롬프트, 똑같은 모델 (opus / effort: medium)도 하네스에 따라 과정과 결과물이 다르다는걸 체험해보는 수업자료입니다. 활동을 통해 모두가 똑같은 셋팅에서 동일한 프롬프트를 복붙하고 결과물을 뽑아냅니다. 그 후 걸린 시간, 엔터 횟수, 모든 기능이 작동하는지, 함정에 빠졌는지 등 html에서 기입을 쭉 하면 성적표가 뜹니다! 선생님들도 모의고사 풀어보세용 ㅎㅎ

최근 객체 지향 UI 디자인과 관련된 책을 읽고 있는데 아주 흥미롭습니다. 예시로 도서관의 도서 장부 시스템을 들더군요.

• 태스크 지향의 예시: 처음 시스템에 들어갔을 때 도서 등록, 도서 삭제 이렇게 버튼이 뜨고 도서 등록을 누른 다음 책 제목 등 정보를 입력
• 객체 지향의 예시: 처음 시스템에 들어갔을 때 등록된 책 목록이 쭉 보임. +버튼을 누르면 등록이 가능하고 등록된 책 옆에 휴지통 버튼을 누르면 그 책이 삭제되고, 연필 버튼을 누르면 정보 수정이 가능함.

생각해보면 바이브코딩으로 만들어진 플랫폼은 태스크 지향으로 만들어지기 쉽습니다. 왜냐하면 저희가 AI에게 작업을 요구하는 프롬프트가 그럴 수 밖에 없기 때문이죠. 예컨대 '도서 등록 및 삭제가 가능한 도서 관리 시스템 만들어줘' 라고 입력하게 되잖아요. 원인을 덧붙이자면 책에서도 이야기 하지만 이미 저희가 쓰는 90% 가량의 플랫폼이 태스크 지향 UI 디자인으로 이루어져 있어 나쁜 사례가 훨씬 많다는 겁니다. AI는 확률 기계에 불과하니 이런 오답을 답습할 가능성이 농후하죠. 그래서 요즘은 제가 설령 태스크 지향으로 프롬프팅해도 알아서 객체 지향 UI를 구현할 수 있도록 시스템을 구축하는 방향으로 UI 관련 하네스 엔지니어링을 다듬어 보고 있습니다. 여러분들도 이러한 관점에서 만드신 플랫폼을 살펴보시기 바랍니다. 사용자 입장에서는 플랫폼에 들어갔을 때 해야할 일들만 잔뜩 나열되어 있으면 숨이 막히고 뭐하는 곳인지 파악하기 어렵습니다. 그냥 버튼을 눌러보며 가지고 놀고 싶을 뿐

영상에 나오는 사람은 고등학교를 중퇴한 open AI 연구원인데요. 학습의 개념이 바뀌고 있다고 이야기합니다. 내가 학습하고자 하는 대상을 AI에게 이해하라고 요구하는게 아니라, 학습 대상의 맥락를 이해하는데 AI를 활용해야 하는게 중요하고 이런 식으로 AI를 활용한다면 이용자인 사람이 정말 빠르게 새로운 분야를 학습할 수 있다고 강조합니다. 유튜브로 넘어가서 재생하신 다음, 설정에서 자막>자동번역>한국어로 하시면 자막과 함께 보실 수 있습니다!

혼자 쓰려고 바이브코딩으로 해줘!해줘! 하면서 만들다가 선생님들 덕분에 용기 얻어서 저도 배포해보려고 여러 측면으로 리팩토링을 해보았는데...! 그 과정에서 코드 5천줄이 사실은 굳이 없어도 되는 코드였던것...! 🥹🥹🥹

oh-my-claudecode를 만드신 분과 그 팀이 함께 출연합니다. 하네스 엔지니어링이라는게 정답이 있는게 아니라 '내가 AI와 어떻게 협업하고 싶은지' 나의 페르소나에 따라 전혀 다르게 정의될 수 있다는걸 보여주는 좋은 사례인것 같습니다. 결과적으로 내가 마음에 들면 되는게 하네스 엔지니어링인가 봅니다..!

검증 하네스를 구축하는 데 교육 평가의 이론이 쓰인다는게 흥미롭네요 🧐

바이브코딩에 중독돼서 OTT를 안봐요. 교무실에서 드라마 얘기에 낄 수 없고 혼자 안드레 카파시가 어쩌고 같은 소리만 하게 되는데 어쩌죠?