AI는 한 종류가 아니다 — 우산 이름과 연장의 분업

이 책은 교사·개발자·정책가를 위한 전문가 초안이지만, 첫 문장은 아이에게 하는 말과 똑같이 시작한다. 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는 무섭지도 신비롭지도 않다. 종류가 여럿인, 사람이 다스리는 연장 묶음이다. 다음 장부터 그 연장들을 하나씩, 특히 가장 오해받는 챗봇부터 정확히 들여다본다.