이 책은 교사·개발자·정책가를 위한 전문가 초안이지만, 첫 문장은 아이에게 하는 말과 똑같이 시작한다. AI는 한 종류가 아니다. 'AI'라는 말은 하나의 물건 이름이 아니라, 여러 종류를 한꺼번에 덮는 우산 같은 이름이다. 우산을 보고 "저건 빗방울 하나야"라고 부를 수 없듯, AI 전체를 챗봇(LLM) 하나로 환원하는 순간 우리는 가장 흔한 오해의 출발선에 선다.
현장에서 'AI 도입'이라는 한 단어가 곧 'LLM 도입'으로 미끄러지는 일이 잦다. 이 미끄러짐은 단순한 용어 문제가 아니라 설계·예산·위험의 문제다. 어떤 작업은 규칙 한 줄이면 100% 정확하게 끝나는데도, 굳이 거대한 생성 모델을 불러 비싸고 불확실하게 처리하는 일이 벌어진다. 그래서 도구를 아는 사람의 첫 질문은 늘 이것이다. "이건 AI를 안 써도 되는 일 아닐까?" 더 정확히는, "이 일에 맞는 AI는 어떤 종류인가?"
크라우니 시스템은 이 분업을 실제로 구현해 둔 사례다. 하나의 거대한 모델에 모든 일을 맡기는 대신, 역할이 다른 여러 부품이 한 지붕 아래 함께 산다. 각 부품은 잘하는 일과 못하는 일이 분명하다.
첫째, 규칙기반 셀코어다. 15개 모듈로 된 if-then 규칙 엔진으로, 정해진 조건에 정해진 답을 따진다. 정해진 일에 대해서는 가장 정확하고, 속이 그대로 들여다보인다. 둘째, 검색을 담당하는 learn DB다. 약 1만 5천 개의 패턴을 보관해 두고, 새 답을 만드는 대신 이미 본 답을 빠르게(약 36ms) 꺼내 온다. 셋째, 분류기인 거대SLM2다. 839줄의 한선씨로 작성되었고, 새 답을 '생성'하지 않는다. 들어온 것을 티·옴·타·음 네 가지로 '판정'만 한다. 넷째, 삼진생성기다. 보관된 답이 없을 때 없던 답을 새로 만들어 본다. 다섯째, 검증기인 501브리지다. 만들어진 코드를 실제로 컴파일해 통과/실패로 채점한다. 여섯째, 로봇제어를 맡는 CrownyOS GPIO다. 신호로 실제 기계를 움직인다. 일곱째, LLM(Opus 등 챗봇)이다. 가장 마지막, '음' 경로의 최후 수단으로만 호출된다.
핵심은 이 분업이 우연이 아니라 설계라는 점이다. 부품을 나누면 한 칸이 틀려도 다른 칸이 그것을 잡아 줄 수 있다. 생성하는 부품과 검사하는 부품을 떼어 놓으면, 틀린 답이 검사 없이 흘러나가지 못한다. 규칙으로 끝낼 수 있는 일을 규칙으로 끝내면, 불확실한 생성을 부르지 않아도 된다.
교사에게 이 장은 '리터러시의 첫 단추'다. 학생이 'AI'를 챗봇과 동의어로 쓰는 순간을 잡아, 그 우산 아래 여러 종류가 있음을 보여 줘야 한다. 개발자에게 이 장은 '아키텍처 원칙'이다. 단일 거대 모델에 모든 책임을 싣지 말고, 역할별로 가장 정확하고 가장 투명한 부품에 일을 맡기는 분업을 먼저 설계하라는 것이다. 정책가에게 이 장은 '평가 기준'이다. 'AI를 썼는가'가 아니라 '어떤 종류의 AI를, 검증과 함께 썼는가'를 물어야 한다.
AI는 무섭지도 신비롭지도 않다. 종류가 여럿인, 사람이 다스리는 연장 묶음이다. 다음 장부터 그 연장들을 하나씩, 특히 가장 오해받는 챗봇부터 정확히 들여다본다.
챗봇(LLM)에는 마음도, 기분도, 바람도 없다. 이것은 다정함을 위해 누그러뜨린 표현이 아니라 정확한 기술적 사실이다. LLM이 하는 일은 딱 하나, '다음에 올 단어를 맞히는 것'이다. 아주 커다란 자동완성이라고 보면 된다. 그래서 우리는 LLM을 두고 '생각한다·느낀다·원한다'고 말하지 않는다. '고른다·맞힌다·되비춘다·계산한다'고 말한다.
작동을 단순화하면 이렇다. '크라우니는 좋은 ___'이라는 문장의 빈칸을, LLM은 본 적 있는 후보들 중에서 더 자주 본 쪽을 골라 채운다. 예를 들어 '도구' 60%, '회사' 30%, '친구' 10% 같은 분포에서 한 칸을 고른다. 이 과정에 '크라우니가 정말 무엇인지'에 대한 이해는 없다. 패턴을 복사해 그럴듯한 다음 단어를 잇는 것이다. 그래서 LLM은 앵무새나 거울에 가깝다. 우리가 준 말을 패턴으로 되비출 뿐, 무엇을 '안다'고는 못 한다.
이 원리에서 환각(hallucination)이 곧바로 따라 나온다. LLM은 맞는 답과 틀린 답을 똑같이 자신 있게 말한다. 빈칸을 채우는 데 '자신감'이라는 내부 진위 감각이 따로 없기 때문이다. 그럴듯하게 이어지는 단어열이면 사실 여부와 무관하게 매끄럽게 출력된다. 그래서 역설적으로, 챗봇이 막힘없이 술술 대답할수록 한 번 더 멈춰 확인해야 한다. 유창함은 정확함의 보증이 아니다.
이 사실은 LLM을 깎아내리려는 것이 아니다. LLM에는 분명한 쓸모가 있다. 빠르게 초안을 만들고, 표현을 바꾸고, 막힌 생각의 물꼬를 터 준다. 다만 그 쓸모의 정확한 위치를 알아야 한다. LLM은 '맞는 답을 보증하는 장치'가 아니라 '그럴듯한 후보를 빠르게 내놓는 장치'다. 보증은 다른 부품이 맡아야 한다.
그래서 크라우니는 이 생성 기능을 평소에 거의 쓰지 않는다. LLM(Opus 등)은 여러 부품 중 하나일 뿐이고, 규칙·검색·분류로 풀리지 않는 일이 남았을 때 '음' 경로의 마지막 수단으로만 호출된다. 생성이 비싸고 불확실하다는 것을 알기에, 일부러 가장 뒤에 둔 것이다.
교사에게 이 장의 실천은 분명하다. 학생이 챗봇에게 "미안해"라고 말하거나 "얘가 화났어"라고 느끼는 순간, 부드럽지만 또렷하게 바로잡아 줘야 한다. 챗봇은 인격이 아니라 '다음 단어를 맞히는 계산'이다. 이 구분은 차가운 것이 아니라 오히려 학생을 보호한다. 기계에 감정을 투사하지 않는 아이가, 기계의 말을 더 침착하게 검증한다.
개발자에게 이 장은 '신뢰 경계 설정'이다. LLM의 출력은 입력이지 결론이 아니다. 유창함을 신뢰 신호로 오해하지 말고, 사실성·실행 가능성은 항상 모델 바깥에서 검증해야 한다. 정책가에게 이 장은 '책임 귀속의 출발점'이다. LLM이 자신 있게 말했다는 사실은 면책 사유가 될 수 없다. 환각은 결함이 아니라 작동원리에서 따라 나오는 성질이고, 그래서 사람의 검증과 책임이 반드시 따라붙어야 한다.
다음 장에서는 바로 그 검증을 시스템으로 만든 사례 — 만든 답을 만든 자가 채점하지 않게 떼어 놓는 501브리지를 본다.
이 책에서 가장 중요한 한 줄은 이것이다. "만든 사람에게 채점을 맡기지 마라." LLM에게 "이 답 맞아?"라고 물으면 거의 언제나 "맞아요"라고 한다. 자기 출력을 검증할 독립적 기준이 모델 안에 없기 때문이다. 생성한 주체가 채점까지 하면, 틀린 답이 검사 없이 통과한다. 그래서 크라우니는 '만드는 AI'와 '검사하는 AI'를 구조적으로 분리한다.
분리의 핵심 장치가 501브리지다. 삼진생성기 같은 부품이 코드를 만들면, 501브리지는 그 코드를 실제로 컴파일한다. 통과하면 신뢰하고, 실패하면 거부한다. 여기서 채점 기준은 LLM의 자기 확신이 아니라 '정말로 컴파일되는가'라는 외부의 객관적 사실이다. 모델이 아무리 자신 있게 내놓아도, 컴파일이 실패하면 그 답은 거부된다. 모델이 머뭇거려도, 컴파일이 통과하면 그 답은 신뢰된다. 판정의 권한이 모델의 말솜씨에서 실행 가능한 검증으로 옮겨 간 것이다.
이것은 소프트웨어 공학의 오래된 원리를 AI에 적용한 것이기도 하다. 생성과 검증의 관심사 분리, 그리고 '주장'이 아니라 '실행 결과'로 판정하는 테스트 주도의 사고다. AI가 만든 산출물에 이 원리를 붙이면, 환각의 상당 부분이 검증 게이트 앞에서 걸러진다. 그럴듯하지만 돌아가지 않는 코드는 통과하지 못하기 때문이다.
501브리지는 데몬으로 가동된다. LaunchAgent com.crowny.bridge501로 등록되어 매일 10:10에 자동으로 수확·검증·보고한다. 새로 쌓인 답들을 모아 컴파일로 채점하고, 통과/실패를 기록으로 남기며, 그렇게 시스템은 매일 조금씩 개선된다. SLM 본체는 모델0 서버 포트 :9501에서 가동된다.
여기서 표현을 정확히 해야 한다. 501브리지가 '스스로' 똑똑해지는 것이 아니다. 사람이 정해 둔 시각에, 사람이 짜 둔 절차대로 부지런히 채점하고 기록할 뿐이다. '매일 조금씩 개선된다'는 말은 신비한 자기진화가 아니라, 검증을 통과한 좋은 패턴이 누적되고 실패가 걸러지는 결과다. 자동화는 자율이 아니다. 자동화된 검증조차 그 기준과 일정과 책임은 사람에게 있다.
도구를 다스리는 사람은 다섯 가지를 한다. 잘 묻고, 답이 맞는지 확인하고, 틀리면 고치고, 끌 줄 알고, 책임은 사람이 진다. 501브리지는 이 중 '확인'을 사람의 눈대중에서 자동 채점기로 끌어올린 장치다. 다만 나머지 넷 — 무엇을 물을지, 무엇을 고칠지, 언제 멈출지, 누가 책임질지 — 는 여전히 사람의 몫으로 남는다.
개발자에게 이 장은 직접적인 설계 지침이다. AI 산출물 파이프라인에는 생성기와 독립된 검증기를 반드시 두라. 가능하면 컴파일·테스트 실행·정적 검사처럼 모델의 자기평가에 기대지 않는 객관적 게이트를 써라. 정책가에게 이 장은 평가 프레임이다. AI 시스템을 심사할 때 "생성과 검증이 분리되어 있는가, 검증 기준은 무엇이며 누가 정했는가, 실패 기록은 남는가"를 물어야 한다. 교사에게 이 장은 한 문장으로 압축된다. 답을 받은 사람이 채점도 하면 안 된다는 것. 이것은 AI만의 규칙이 아니라, 아이가 자기 숙제를 검산할 때도, 어른이 자기 일을 점검할 때도 통하는 보편 원리다.
가장 깨끗한 AI 사용은, 종종 'AI를 쓰지 않는 것'이다. 더 정확히는, 생성형 AI를 부르지 않고 끝낼 수 있는 일은 끝내는 것이다. 연필로 될 일에 큰 기계를 부르지 않는 절제 — 크라우니의 토큰0 라우터는 이 절제를 시스템 차원에서 강제한다.
토큰0 라우터는 들어온 작업을 단계별로 흘려보낸다. 먼저 규칙기반 셀코어(L0)가 if-then으로 처리할 수 있는지 본다. 안 되면 검색 learn DB(L1~L2)가 이미 본 패턴에서 답을 꺼낼 수 있는지 본다. 이 규칙·검색 단계(L0~L2)에서 전체 작업의 약 95%가 종결된다. 즉, 새 답을 '생성'하는 부품을 부르는 일은 전체의 일부에 불과하다. 라우터의 이름에 '토큰0'이 붙은 이유가 여기 있다. 대다수 작업이 생성 토큰을 거의 소모하지 않고 끝나기 때문이다.
이 구조의 이점은 분명하다. 규칙과 검색은 빠르고(learn DB 조회는 약 36ms), 결정적이며, 같은 입력에 같은 출력을 낸다. 생성형 모델 특유의 불확실성과 환각이 끼어들 여지가 애초에 없다. 가볍고, 정확하고, 재현 가능하다. 비용과 전력도 절약된다. 무엇보다, 부르지 않은 부품은 틀릴 수 없다.
흔히 AI 시스템의 발전을 '더 큰 모델을 더 자주 부르는 것'으로 상상한다. 토큰0 라우터는 정반대의 직관을 보여 준다. 잘 설계된 시스템은 '얼마나 자주 생성을 안 부르고 끝내는가'로도 평가된다. 생성 호출은 능력의 증거가 아니라 마지막 카드다. 규칙으로 풀리는 일을 생성으로 풀면, 더 느리고 더 비싸고 더 불확실해진다.
이것은 단순한 효율 이야기가 아니라 안전 이야기이기도 하다. 생성을 적게 부를수록 환각이 끼어들 표면적이 줄어든다. 결정적 규칙과 검증된 검색으로 처리된 95%는, 출력의 근거를 추적할 수 있다. 어떤 규칙이 어떤 조건에서 어떤 답을 냈는지 들여다볼 수 있기 때문이다. 이 투명성은 다음 장의 주제인 '유리 상자'와 곧장 이어진다.
교사에게 이 장은 분별의 습관이다. "이건 AI를 안 써도 되는 일 아닐까?"라는 질문을 학생의 기본기로 만들어야 한다. 검색하면 될 일, 계산기로 될 일, 규칙표로 될 일에 굳이 챗봇을 부르지 않는 절제가 곧 도구 리터러시다. 생성형 AI를 '먼저' 꺼내 드는 습관이야말로 가장 흔하고 가장 비싼 오용이다.
개발자에게 이 장은 라우팅 우선 설계다. 파이프라인의 첫 단을 생성 모델로 두지 말라. 결정적 규칙 → 캐시·검색 → 분류 → 생성의 순서로 단계를 쌓고, 가능한 한 앞 단에서 종결시켜라. 생성은 폴백이지 기본값이 아니다. 정책가에게 이 장은 비용·위험·전력의 정합성 문제다. 'AI를 많이 썼는가'가 아니라 '필요한 만큼만, 가장 검증 가능한 단계에서 썼는가'가 좋은 시스템의 지표다. 안 쓰는 것이 가장 깨끗하다는 원칙은, 윤리와 효율과 안전이 한 방향을 가리키는 드문 지점이다.
거대 LLM의 가장 위험한 습성은, 무엇을 물어도 결국 '예스'에 가까운 답을 한다는 것이다. 모르는 것도 아는 척, 못 하는 것도 할 수 있는 척 매끄럽게 답한다. 다음 단어를 맞히는 기계에는 '모름'이나 '못함'을 출력할 내적 동기가 약하기 때문이다. 환각의 뿌리가 여기 있다. 크라우니의 4상 거버넌스는 바로 이 지점을 겨냥한다. '모름'과 '못함'을 일급 출력으로 만드는 것이다.
크라우니의 판정은 네 가지 상(相)으로 이루어진다. 티(T, +1)는 예스·확정이다. 답이 맞으면 받아들인다. 옴(O, 0)은 모름·보류다. 확실하지 않으면 멈추고 알아보거나 검증한다. 타(A, −1)는 노·거부다. 틀리면 고치거나 거절한다 — AI도 틀리기 때문이다. 음(U, -0)은 이관이다. 이상하거나 내가 다룰 일이 아니면 멈추고 사람(어른·담당자)에게 넘긴다.
사람들은 흔히 '티' 칸만 멋지다고 여긴다. 그러나 거버넌스의 진짜 힘은 멈추는 칸 — 옴과 음 — 에 있다. 거대 LLM이 무엇이든 티로만 답하며 환각을 내는 것과 달리, 크라우니의 분류기 거대SLM2는 옴(모름)과 음(못함)을 정직하게 출력할 수 있다. '모른다'와 '못 한다'를 말할 줄 아는 것이 더 똑똑한 도구다. 무엇이든 '맞다'고만 하는 도구일수록 더 꼼꼼히 의심해야 한다.
거대SLM2는 새 답을 만들지 않는다. 들어온 신호를 판정만 한다. 839줄의 한선씨로 작성된 이 분류기는 27칸 큐브에 신호를 저장한다. 각 칸에는 T(좋은 신호), O(모름), A(나쁜 신호), U(이관)가 들어간다.
여기서 옴(O)의 공학적 의미가 특히 중요하다. 옴은 '곱셈의 0'처럼 작동한다. 즉, 모름 상태는 아무 일도 일으키지 않는다. 확실해지기 전에는 어떤 행동도 촉발하지 않는다는 뜻이다. 거짓 확신으로 잘못된 행동을 일으키는 대신, 모름은 안전하게 '정지'로 귀결된다. 이것은 단순한 비유가 아니라, 불확실성이 사고로 번지지 않게 하는 설계 원리다. 모르면 멈춘다 — 이 한 줄이 환각을 행동으로 옮기지 않게 막는다.
그리고 음(U)은 시스템의 한계를 인정하는 출력이다. 자기가 다룰 일이 아닌 것을 억지로 처리하지 않고, 사람에게 되돌린다. 자동화 시스템이 가질 수 있는 가장 성숙한 능력은, 자기 권한 밖의 일을 '못 한다'고 정직히 말하고 넘기는 것이다.
교사에게 4상은 평생 쓰는 분별의 틀이다. 새 도구를 만났을 때 티·옴·타·음 네 칸으로 다스리는 습관을 어릴 때 익히면, 어떤 새 AI가 나와도 흔들리지 않는다. 특히 '모르면 멈춘다(옴)'와 '내 일이 아니면 어른께 넘긴다(음)'를 가르치는 것은, AI 교육이자 동시에 안전 교육이고 책임 교육이다.
개발자에게 4상은 출력 스키마 설계 지침이다. 모델의 출력을 '답/무답'의 이진이 아니라 확정·보류·거부·이관의 네 상태로 설계하라. 특히 '보류(옴)'를 행동 차단 게이트로, '이관(음)'을 사람 개입 트리거로 명시적으로 배선하라. 정직한 불확실성 표현은 모델 성능을 깎는 것이 아니라, 시스템 안전을 끌어올린다. 정책가에게 4상은 거버넌스 체크리스트다. 시스템이 '모름'과 '못함'을 출력할 수 있는가, 불확실할 때 행동을 멈추는가, 권한 밖의 사안을 사람에게 이관하는가. 무엇이든 자신 있게 답하는 시스템은 유능한 것이 아니라 위험한 것이다. 정직성은 미덕이기 이전에 공학적 안전장치다.
같은 답을 내더라도, 그 답이 '왜' 나왔는지 들여다볼 수 있는 시스템과 그럴 수 없는 시스템은 전혀 다르다. 거대 LLM은 대체로 안이 보이지 않는 '깜깜 상자(블랙박스)'다. 수많은 가중치가 입력을 출력으로 바꾸지만, 특정 답이 나온 이유를 사람이 또렷한 규칙으로 추적하기 어렵다. 반면 규칙과 작은 SLM은 속이 보이는 '유리 상자'에 가깝다. 어떤 조건이 어떤 답으로 이어졌는지 따라갈 수 있다.
다만 한 가지를 분명히 해야 한다. 유리 상자라고 해서 항상 맞는 것은 아니다. 속이 보인다는 것과 옳다는 것은 다른 문제다. 규칙이 잘못 짜여 있으면 유리 상자도 틀린 답을 낸다. 유리 상자의 진짜 미덕은 '항상 옳음'이 아니라 '틀렸을 때 어디가 틀렸는지 짚을 수 있음'이다. 블랙박스가 틀리면 원인 규명이 어렵지만, 유리 상자가 틀리면 어느 규칙이 잘못이었는지 찾아 고칠 수 있다. 디버깅 가능성, 감사 가능성, 수정 가능성 — 이것이 투명성이 주는 실질적 힘이다.
크라우니의 구조는 이 투명성을 의도적으로 키운다. 규칙기반 셀코어는 if-then이라 그 자체가 읽을 수 있는 논리다. 검색 learn DB는 어떤 패턴을 꺼냈는지 추적된다. 분류기 거대SLM2는 27칸 큐브에 T/O/A/U를 저장하므로, 어떤 신호가 어디에 어떻게 들어갔는지 살펴볼 수 있다. 501브리지의 컴파일 채점은 통과/실패 기록을 남긴다. 토큰0 라우터로 95%가 규칙·검색에서 끝나기에, 전체 출력의 대부분이 추적 가능한 경로를 거친다. 가장 불투명한 부품인 LLM은 가장 마지막, 가장 드물게만 호출된다. 즉 시스템 설계 자체가 '추적 가능한 영역을 최대화하고, 블랙박스 영역을 최소화하는' 방향이다.
여기서 앞 장들이 하나로 이어진다. AI를 한 종류가 아니라 여러 부품으로 나눈 것(1장), 생성과 검증을 분리한 것(3장), 생성을 거의 부르지 않는 것(4장), 모름·못함을 출력하게 한 것(5장) — 이 모든 선택이 합쳐져 '유리 상자에 가까운 전체'를 만든다. 투명성은 하나의 기능으로 추가되는 것이 아니라, 분업과 절제와 검증이라는 설계 선택들의 누적된 결과다. 거대한 단일 모델 하나로 모든 것을 처리하는 구조에서는 얻기 어려운 성질이다.
교사에게 이 장은 비판적 질문의 도구다. 학생에게 '큰 챗봇은 깜깜 상자, 작은 규칙은 유리 상자'라는 대비를 쥐여 주되, '유리 상자도 규칙이 틀리면 틀린다'는 단서를 함께 줘야 한다. 그래야 아이가 투명성을 맹신이 아니라 검증의 출발점으로 쓴다.
개발자에게 이 장은 관측 가능성 설계다. 출력만이 아니라 '그 출력에 이른 경로'를 로그로 남겨라. 어떤 규칙·어떤 검색 결과·어떤 판정·어떤 검증을 거쳤는지 추적할 수 있어야, 틀렸을 때 고칠 수 있다. 블랙박스 호출은 최소화하고, 불가피하다면 그 입출력만이라도 기록하라. 정책가에게 이 장은 설명책임의 기준이다. 중요한 결정에 쓰이는 AI는 '왜 그렇게 판단했는가'를 사람이 검토할 수 있어야 한다. 해석 불가능한 블랙박스에 고위험 결정을 통째로 맡기는 것은, 책임의 주체를 사라지게 만든다. 투명성은 친절이 아니라, 책임을 사람에게 묶어 두기 위한 전제 조건이다.
이 책은 처음부터 끝까지 세 가지만 또렷이 말했다. 첫째, AI는 한 종류가 아니다. 둘째, 네가 매일 쓰는 챗봇은 사람이 아니라 연장이다. 셋째, 연장의 주인은 언제나 사람이다. 무서운 이야기도, 떠받드는 이야기도 아니다. AI는 유용하지만 틀릴 수 있는 연장 — 딱 그만큼이다.
앞의 여섯 장은 이 명제를 실제 시스템으로 떠받쳤다. AI를 여러 부품으로 나누고(1장), LLM이 '다음 말 맞히기'임을 직시하고(2장), 생성과 검증을 분리하고(3장), 생성을 거의 부르지 않으며(4장), 모름·못함을 정직하게 출력하고(5장), 추적 가능한 유리 상자를 키운다(6장). 이 모든 선택의 공통 목적은 하나다. 도구가 사람을 대신해 결정하지 않게, 사람이 도구를 다스리게 하는 것.
다스리는 사람은 다섯 가지를 한다. 잘 묻고, 답이 맞는지 확인하고, 틀리면 고치고, 끌 줄 알고, 책임은 사람이 진다. 이 다섯은 추상적 구호가 아니라 시스템에 박힌 동작이다. '잘 묻기'는 토큰0 라우터의 분별(이 일에 맞는 부품은 무엇인가)로, '확인'은 501브리지의 컴파일 채점으로, '고침'은 유리 상자의 추적·수정 가능성으로, '끔'은 옴(모름이면 멈춤)과 음(못하면 이관)으로 구현된다. 그리고 다섯째 — 책임 — 만은 끝내 사람의 몫이다. 자동화는 자율이 아니다. 501브리지가 매일 정해진 시각에 부지런히 채점해도, 그 기준과 일정과 결과에 대한 책임은 그것을 설계하고 운영하는 사람에게 있다.
교사에게. AI 리터러시의 핵심은 화려한 활용법이 아니라 절제와 검증의 습관이다. 학생이 'AI=챗봇'이라 말할 때 우산의 비유로 넓혀 주고, 챗봇에 감정을 투사할 때 '다음 말 맞히기'로 바로잡고, 답을 받았을 때 '누가 채점했는가'를 묻게 하라. 티·옴·타·음 네 칸을 어릴 때 손에 쥐여 주면, 그 아이는 앞으로 어떤 새 도구가 나와도 다스릴 수 있다.
개발자에게. 단일 거대 모델에 모든 책임을 싣지 말라. 결정적 규칙 → 검색 → 분류 → 생성의 순으로 라우팅하고, 생성기와 독립된 검증기를 두고, 출력을 확정·보류·거부·이관의 네 상태로 설계하고, 경로를 추적 가능하게 로깅하라. 가장 좋은 설계는 생성 호출을 자랑하는 설계가 아니라, 검증 가능한 단계에서 가장 자주 일을 끝내는 설계다.
정책가에게. 좋은 질문은 'AI를 도입했는가'가 아니라 '어떤 종류의 AI를, 검증·투명성·책임과 함께 썼는가'이다. 시스템이 모름과 못함을 말할 수 있는지, 생성과 검증이 분리되어 있는지, 결정 경로를 사람이 검토할 수 있는지, 책임의 주체가 사람으로 명확한지를 물어라. 자신만만하고 불투명한 시스템을 경계하고, 정직하고 추적 가능한 시스템을 우대하라.
너는 도구의 주인이다. AI는 너 대신 생각해 주는 친구가 아니라, 네 시간을 아껴 주는 연장이다. 그렇게 아낀 시간으로 너는 사람을 더 사랑하면 된다 — 가족과 더 놀고, 친구 말을 더 들어 주면서. 무서워하지도, 떠받들지도 말자. 다정하지만 분명하게, 잘 묻고 꼭 확인하며 다스리는 사람이 되자. 그리고 답이 맞든 틀리든, 책임은 언제나 사람이 진다.