글

아이 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 ...

웹에서 영상 편집이 되는지 궁금해서 AI로 하루 동안 직접 만들어 봤다

이미지
아는 엄마 중에 AI로 유튜브 채널을 하는 분이 있다는 얘기를 아내에게 들었습니다. 9월 24일, 목요일이었습니다. 그 얘기를 듣고 며칠 전에 접어 둔 질문 하나가 다시 떠올랐습니다. 웹에서 동영상 편집이 될까. 그날 밤에 만들기 시작했습니다. 다음 날 밤 9시가 조금 넘어 마지막 커밋을 찍었을 때는 브라우저 화면 하나에서 대본을 넣고, 등장인물과 장면 그림을 그리고, 내레이션 목소리를 입히고, 타임라인에서 자르고 붙여 영상 파일로 뽑고, 유튜브에 올릴 제목과 설명 초안까지 받는 데까지 와 있었습니다. 코드는 전부 AI와 같이 썼습니다. 이 글은 그 하루의 기록입니다. AI로 쇼츠를 만들어 돈을 버는 방법을 다루지는 않습니다. 저는 그 채널이 얼마를 버는지 모르고, 제가 만든 도구로 올린 영상도 아직 없습니다. 궁금했던 건 개발자인 제가 이걸 직접 만들 수 있느냐였고, 만들고 나서 무엇을 알게 됐는지를 적어 두려고 합니다. ChatGPT 와 나눈 이야기는 유튜브 스튜디오에서 멈췄습니다 질문은 그보다 며칠 앞에 시작됐습니다. 웹에서 동영상 편집이 가능할까가 문득 궁금해져서 ChatGPT 와 여러 이야기를 주고받았습니다. 그러다 유튜브 스튜디오가 떠올랐습니다. 유튜브 스튜디오에는 브라우저에서 쓰는 편집기가 있습니다. 이미 올린 영상을 자르고, 음악을 얹고, 일부를 흐리게 가리는 정도는 거기서 됩니다. 이미 누군가 웹에서 하고 있으니 되긴 되는 일이구나, 하고 대화가 거기서 끝났습니다. 그리고 한동안 잊고 지냈습니다. 지금 보면 그 결론은 반만 맞았습니다. 된다는 건 맞습니다. 유튜브 스튜디오가 하는 일은 다 만든 영상을 조금 손보는 일이고, 제가 궁금했던 건 아무것도 없는 데서 영상 한 편을 만드는 흐름 전체가 웹 화면 하나에서 돌아가느냐였습니다. 그때는 그 둘을 나눠서 생각하지 않았습니다. 대화로 갈 수 있는 건 "되긴 된다"까지였고, 그다음은 만들어 봐야 아는 일이었습니다. 당근에서 AI 콘텐츠 모임을 여러 번 봤습니다 아내...

“환각도 타입 에러도 0%”라는 Jev 를 써도 오답을 잡는 검증은 그대로 남습니다

이미지
환각이 0% 라는 말과 정확도가 최고 76.0% 라는 말은 같이 성립합니다. 둘 다 TypeSafe AI(타입세이프)가 Jev(제브)를 공개하면서 내놓은 값이고, 서로 모순되지 않습니다. 모순처럼 보인다면 앞의 0% 가 무엇에 대한 0% 인지를 잘못 읽은 겁니다. 이 발표문을 열어본 건 지금까지 본 0% 주장하고는 종류가 좀 달라 보여서였습니다. 대부분의 0% 는 재서 나온 값입니다. 몇 건 중 몇 건이었다는 분모와 분자가 뒤에 붙어 있고, 그래서 다음 달에 다시 재면 0.3% 가 될 수도 있는 값이죠. 그런데 이 0% 는 재기 전에 이미 참인 문장이었습니다. 출력이 미리 정의한 스키마 밖으로 나갈 수 없게 만들어 놓았으니, 스키마를 벗어나는 사건의 빈도는 세어 볼 필요가 없습니다. 읽고 나서 달라진 게 있습니다. 「0% 가 사실이냐」를 따지는 자리에서 내려왔습니다. 사실입니다. 대신 무엇에 대해 사실인지가 문제로 남습니다. 보장되는 것은 돌아온 값의 형식이고, 그 값이 맞느냐는 보장 밖에 그대로 있습니다. 범위를 먼저 그어 두겠습니다. 저는 Jev 를 호출해 본 적이 없습니다. 신청해서 받아 돌려본 적이 없으니 지연이 실제로 얼마나 나오는지, 확률이 얼마나 잘 맞는지를 제 눈으로 본 문장은 이 글에 하나도 없습니다. 제가 읽은 건 TypeSafe 의 공식 발표문, 그 발표문이 넘긴 평가 사이트, Wikipedia 항목, 그리고 이 모델을 두고 쓴 외부 글 두 편입니다. 전부 2026년 9월 22일에 확인했습니다. Jev 가 돌려주는 것은 문장이 아니라 스키마에 맞는 값입니다 Jev 는 문장을 생성하지 않습니다. 미리 정의한 스키마에 맞는 타입이 붙은 값과 확률, 그리고 신뢰도를 돌려줍니다. 질문의 형태는 세 가지입니다. 정의된 집합에서 하나를 고르는 Choice , 정렬된 수준에 대해 상태를 평가하는 Score , 예 또는 아니오 명제를 0에서 1 사이 확률로 평가하는 Noul 입니다. Choice 는 고른 값만 주는 게 아니라 옵션별 확률까지...

가족 위치 앱은 끄는 법까지 적고 기록이 어디 남는지는 안 적습니다

이미지
가족 위치 확인 앱을 만들었다는 글을 끝까지 읽었습니다. 서로 동의한 가족이나 단짝끼리만 연결해서 위치를 볼 수 있다고 적혀 있었고, 위치 공유는 원할 때 끌 수 있다고 적혀 있었고, 연결도 언제든 해제할 수 있다고 적혀 있었습니다. 앱스토어와 플레이스토어 양쪽에 올라가 있는 앱입니다. 소개글 치고는 성실한 축입니다. 동의를 받는 구조와 끄는 방법과 관계를 끊는 방법까지, 누가 물어본 것도 아닌데 셋 다 먼저 적혀 있었습니다. 그런데 한 칸이 비어 있었습니다. 이동 기록이 어디에 얼마나 남는지는 없었습니다. 위치를 지도에 그려주고 지나온 경로까지 보여주는 앱이니 기록은 어딘가에 쌓일 텐데, 그게 기기 안에 있는지 서버에 있는지, 남는다면 며칠인지 몇 달인지에 대한 문장이 한 줄도 없습니다. 공을 많이 들였다는 대목은 있습니다. 위치가 너무 자주 튀지 않게 하고 기록이 끊겨 보이지 않게 하는 쪽이라고 적혀 있습니다. 정확도와 배터리 이야기이지 보관 이야기가 아닙니다. 비어 있는 칸이 하필 그 칸인 게 눈에 걸렸습니다. 지난번에 무료 이미지 편집 도구 이야기를 쓰면서 확인해 보지 않은 사람이 더 단정적으로 말한다 는 데서 끝냈습니다. 그 글을 쓰고 나서 같은 개발자 게시판의 2주치를 모아서 다시 읽었는데, 제가 내린 결론이 반쪽이었습니다. 사람들은 위험을 안 적는 게 아닙니다. 자기가 볼 수 있는 위험은 다들 스스로 먼저 적습니다. 가족 위치 앱에서 동의와 해제는 적혔고 보관만 비었습니다 동의, 끄기, 해제. 이 셋에는 공통점이 있습니다. 전부 화면에 있는 물건입니다. 동의를 받으려면 동의를 묻는 화면을 만들어야 합니다. 끄는 기능을 넣으려면 스위치를 그려야 하고, 연결 해제를 넣으려면 목록에서 상대를 지우는 버튼을 붙여야 합니다. 만든 사람은 그걸 직접 만들면서 봤고, 쓰는 사람도 눌러서 확인할 수 있습니다. 그래서 소개글에 적힙니다. 적을 게 있으니까 적는 겁니다. 보관은 그렇지 않습니다. 위치 좌표가 서버 데이터베이스에 며칠 남는지, 요청...

AI가 만들었는데 왜 안전하다고 말할까? - 얼굴 사진을 받는 무료 도구들

이미지
요런 파일들도 다 외부로 안 나가게 안전하게 그리고 다운로드 받는 파일도 메타데이터 다 제거해서 무료 이미지 편집 도구를 공개하는 영상에 나온 말입니다. 채널을 O년 운영한 기념으로 구독자들에게 뭐라도 돌려주고 싶었다고 했고, 링크는 누구나 접근할 수 있게 열어뒀다고 했습니다. 기능 소개가 한참 이어지다가 끝자락에 이 한 줄이 지나갑니다. 지나가는 한 줄인데, 이 도구에 대해 할 수 있는 말 중에서는 제일 큰 말입니다. 먼저 경계를 그어두겠습니다. 저는 이 도구의 코드를 보지 않았습니다. 파일이 실제로 브라우저 안에서만 처리되는지 서버를 거치는지 확인하지 않았고, 그래서 이 글은 위반 사례를 적은 글이 아닙니다. 만든 사람이 코드를 읽을 수 있는 사람인지도 모릅니다. 영상에는 AI 를 썼다는 말도 안 썼다는 말도 없습니다. 기획하고, 만들라고 지시하고, 배포한 것은 본인이 한 일입니다. 궁금했던 건 다른 쪽입니다. 저 문장이 참이냐 거짓이냐는 제가 답할 수 없습니다. 제가 보는 건 그 문장을 받아 든 사람이 그걸 확인할 방법이 있느냐입니다. 이 질문은 만든 사람의 실력과 무관하게 성립하고, 실력을 따지는 것보다 훨씬 오래 남습니다. 채널 이름도 사이트 이름도 적지 않겠습니다. 이 글에 필요한 건 인용한 문장과 기능 목록이고, 이름이 들어가는 순간 글의 성격이 바뀝니다. 파일이 외부로 안 나간다는 말은 확인한 사람만 할 수 있습니다 저 한 문장이 참이 되려면 여러 개가 동시에 참이어야 합니다. 편집이 전부 브라우저 안에서 끝나야 하고, 같은 페이지에 실린 광고나 방문 분석 스크립트가 캔버스를 읽어가지 않아야 하고, 오류를 모아주는 도구가 화면을 떠서 보내는 경로가 없어야 하고, 파일을 잠깐 서버에 올려 처리한 뒤 지우는 구간도 없어야 합니다. 넷 중에 하나만 어긋나도 저 문장은 거짓이 됩니다. 그리고 넷 다 화면에는 안 보입니다. 사진을 붙여 넣으면 모자이크가 얹히고 다운로드가 됩니다. 파일이 서버를 한 바퀴 돌고 왔든 브라우저 안에서만 돌았...

리버스한 C를 러스트로 옮겼더니 완벽하게 돌아가던데요?

이미지
리버스 엔지니어링으로 뽑아낸 C 소스를 빌드해 봤습니다. 한 번에 된 건 아닙니다. 디컴파일 출력은 원래 컴파일러에 그냥 넣을 수 있는 물건이 아니라서, 오류를 보고 고치고 다시 넣기를 여러 차례 주고받았습니다. 그러고 나서 한 번 더 갔습니다. 그 C 를 러스트로 포팅했고, 포팅본도 빌드가 됐고, 나온 산출물이 완벽하게 동작했습니다. 먼저 범위를 정확히 적어두겠습니다. 무슨 물건을 뜯는지는 알고 시작했습니다. 뜯기로 정한 사람이 저였으니 그 프로그램이 무엇을 하는지는 처음부터 알고 있었습니다. 몰랐던 건 그 안쪽입니다. 열어보면 이게 무슨 역할인지 감이 안 오는 덩어리가 여럿 나오는데, 그런 건 비슷한 모양의 소스를 찾아다니면서 이런 구조면 대개 이런 물건이더라를 대조하는 식으로 메웠습니다. 그렇게 하고도 끝내 정체가 안 잡힌 덩어리가 남았습니다. 그건 이해하지 못한 채로 그냥 옮겼습니다. 그런데도 빌드가 통과했고 산출물이 돌아갔습니다. 제가 눈여겨본 게 여기입니다. 무엇을 뜯었는지는 적지 않겠습니다. 이 글에 필요한 건 대상이 아니라 체인이고, 대상을 적는 순간 글의 성격이 바뀝니다. 제가 눈여겨본 것도 결과물이 아니었습니다. 나온 C 가 얼마나 사람이 쓴 것처럼 생겼는지는 여기서 별로 중요하지 않습니다. 예전 같으면 여기 있어야 할 며칠이 통째로 비어 있었습니다. 이 체인을 끝까지 돌려본 이유도 거창하지 않습니다. 요즘 도구로 어디까지 되는지가 궁금해서 한 번 끝을 봤습니다. 중간에 멈추면 어차피 그럴듯한 텍스트를 본 것에 불과하니, 맞는지 틀리는지 판정이 날 때까지는 가야 한다고 봤습니다. 그 판정을 빌드가 해 줍니다. 먼저 경계를 긋겠습니다. 제가 확인한 것은 이 체인 하나입니다. 임의의 바이너리에서 같은 결과가 나오는지, 수십만 줄짜리 상용 코드베이스에서도 같은지는 확인하지 않았습니다. 그래서 이 글은 이제 전부 뚫린다는 이야기가 아닙니다. 제가 하려는 이야기는 우리가 오랫동안 어떤 값 하나에 기대어 설계를 해 왔는데 그 값이 예전 같지...

구글은 왜 앤트로픽의 클로드를 일부 직원에게 예외로 두었을까?

이미지
2026년 9월 15일에 구글이 전 엔지니어에게 Claude 를 쓰게 했다는 기사 제목을 봤습니다. 전원이 쓰게 됐다는 말은 그 앞에 일부만 쓰던 기간이 있었다는 뜻입니다. 그 일부가 누구였고 무슨 기준으로 갈렸는지가 제가 먼저 떠올린 질문이었습니다. 제미나이를 만드는 회사 안에서도 누구는 쓰고 누구는 못 썼다는 뜻이기도 합니다. 이 글은 어느 모델이 코드를 더 잘 쓰는지를 따지는 글은 아닙니다. 벤치마크 표도 없고 가격 비교도 없습니다. 제가 보려는 자리는 하나입니다. 도구를 막고, 예외를 주고, 회수하려다 무산된 이 결정이 어느 층위에서 내려왔는가. 먼저 밝혀 둘 것이 있습니다. 저는 구글 내부자도 업계 분석가도 아니고, 무엇을 쓸지 대부분 혼자 정해 온 개발자로 이 기록을 읽었습니다. 그리고 9월 15일 Business Insider 기사 의 본문을 읽지 못했습니다. businessinsider.com 이 차단돼 있고 로이터 중계본 은 페이월이라, 제가 확인한 것은 제목과 헤드라인뿐입니다. 그래서 9월 15일에 관해 이 글이 적을 수 있는 범위는 제목이 말해 주는 만큼이고, 그 경계는 뒤에 한 절을 따로 두어 적었습니다. 읽은 순서도 그대로 적자면, 저는 9월 제목을 보고 4월 보도부터 다시 읽었습니다. 2026년 4월 디지털투데이 보도에 적힌 사유는 보안 한 줄이었습니다 그 기간의 정책은 4월 보도에 남아 있습니다. 디지털투데이가 2026년 4월 22일에 블룸버그를 인용해 이렇게 적었습니다. 구글은 보안을 이유로 직원들에 클로드 코드, 오픈AI 코덱스 같은 경쟁사 툴을 쓰지 못하도록 하고 있지만 업무상 필요성을 증명하면 직원들이 예외를 신청할 수 있다. 한 줄에 두 가지가 들어 있습니다. 기본값은 금지였고, 예외 신청 제도가 따로 있었습니다. 저는 예외의 조건에서 멈췄습니다. 보안이 유일한 사유였다면 예외의 조건은 보안 요건 충족이어야 자연스럽습니다. 데이터가 어디로 나가는지, 프롬프트와 코드가 어느 사업자의 서버를 지나는지, 로그...

이 블로그의 인기 게시물

아이들은 우리 게임에 들어오지 못한다

AI 부업 강의 여섯 편이 "리스크가 제로죠"라고 말했다

AI가 썼다는 브라우저 300만 줄에서 112만 줄은 남의 코드였다