만약 당신이 학생이 채팅창을 열고 "습도 센서를 어떻게 조립하나요?"라고 물었을 때 모든 것에 대한 즉각적인 정답을 얻기를 기대한다면, 지금 이야기할 파일럿 프로그램은 그 반대로 설계되었습니다. 이 조력자는 의도적으로 학교 커리큘럼 내에 갇혀 있으며, 학생이 아닌 교사에게 답변하고, 최종 결정권은 살아있는 교육자에게 남겨둡니다. 바로 이 점이 "교실에 들어온 또 하나의 봇"이 아닌, 이번 뉴스의 핵심입니다.

2026년 7월 14일, Google DeepMind와 Atal Innovation Mission은 ATL Saathi라는 이름의 라이브 파일럿을 발표했습니다. 이는 2026년 7월 14일자 Google DeepMind 블로그를 통해 알려졌습니다. 첫 번째 단계는 인도의 100개 학교를 대상으로 하며, 이 조력자는 Gemini를 기반으로 구축되었고, 아이들이 코드만 작성하는 것이 아니라 직접 물리적 장치를 조립하는 학교 워크숍인 Atal Tinkering Labs의 교육자들을 위해 설계되었습니다.

아래에서 무엇이 정확히 바뀌었는지, 이러한 제한된 조력자가 범용 챗봇과 어떻게 다른지, 그리고 당신이 어떻게 이 아키텍처를 직접 재현할 수 있는지 분석하겠습니다. 미리 말씀드리자면, 이는 개발자들의 발표이자 파일럿 단계입니다. 학업 성취도, 교사 업무 부하 감소 또는 사용 안전성에 대한 독립적인 데이터는 아직 없습니다.

7월 14일에 발표된 정확한 내용

핵심: 이것은 모두를 위한 제품 출시가 아니라, Gemini 인공지능이 엄격하게 정의된 학습 콘텐츠 내에서 작동하는 100개 학교 대상의 좁은 범위의 라이브 파일럿입니다.

Google DeepMind 블로그(2026년 7월 14일)에서 확인된 사실은 다음과 같습니다:

• ATL Saathi 파일럿은 2026년 7월 14일 Google DeepMind와 Atal Innovation Mission의 공동 발표로 공개되었습니다.
• 첫 번째 단계는 인도의 100개 학교를 대상으로 합니다.
• 조력자는 Gemini를 기반으로 구축되었으며, 주로 Atal Tinkering Labs의 교육자들을 대상으로 합니다.
• 12개 학습 모듈의 콘텐츠는 NotebookLM에 조직되어 요약 자료, 인포그래픽, 비디오 리뷰 및 테스트 형태로 제공됩니다.
• 이 중 10개 모듈에 대해 시스템은 연령별 프로젝트 아이디어와 단계별 조립 지침을 생성합니다.
• 답변에는 학생들이 직접 가져오는 과제에 대한 연결 회로도(schemes) 및 안전 조치가 포함됩니다.
• 파일럿은 8개 언어로 시작되며, 교사가 수업 진행에 대한 책임을 유지하도록 합니다.

두 가지 세부 사항에 주목하십시오. 첫째, 12개의 모듈이 NotebookLM에 업로드되었지만, 프로젝트 아이디어와 지침은 그중 10개에 대해서만 생성됩니다. 즉, 기능의 범위가 참조 콘텐츠의 범위보다 좁으며, 이는 미비함이 아니라 의도적인 제한입니다. 둘째, 시스템은 연결 회로도(schemes)와 안전 조치를 제공합니다. 이는 모델의 오류가 '보고서 내의 잘못된 사실'에서 '십 대의 손에 들린 220V에 연결된 인두기'로 변질될 수 있는 바로 그 영역입니다. 따라서 여기서 교사는 형식적인 존재가 아니라 안전 루프(safety loop)의 일부입니다.

여기서 러시아 시장의 교육용 AI를 고민하는 모든 이들에게 유용한 통찰이 있습니다. 실질적인 가치는 '아이들에게 똑똑한 봇을 주자'가 아니라 '제한'에서 탄생했다는 점입니다. 만약 Gemini, Claude 또는 GPT가 동일한 과제를 어떻게 해결하는지 비교해야 한다면, 단 하나의 실험을 위해 세 개의 별도 계정을 만들 필요 없이 provod.ai와 같이 모든 모델에 한 번에 접근할 수 있는 수단을 갖는 것이 편리합니다.

특화된 조력자와 범용 챗봇의 차이점

핵심: 범용 봇은 모든 것에 답하며 항상 확신에 차 있습니다. 반면 교육용 조력자는 커리큘럼의 범위 내에서 답해야 하며, "모듈에 해당 내용이 없습니다"라고 말할 수 있어야 합니다.

차이점은 모델 자체에 있는 것이 아니라 모델 주변에 무엇을 구축했느냐에 있습니다. 내부의 Gemini는 동일합니다. 차이점은 컨투어(contour)에 있습니다.

여기서 사용된 핵심적인 엔지니어링 기법은 그라운딩 (grounding)이라 불리며, 이는 답변을 모델의 '기억'이 아닌 특정 문서에 고정하는 것을 의미합니다. 파일럿 프로그램에서 NotebookLM은 이 고정(grounding) 역할을 수행합니다. 즉, 모델은 자신이 이전에 보았던 모든 것이 아니라 업로드된 자료를 바탕으로 답변합니다. 연결 회로도와 관련된 주제에서 이는 매우 결정적입니다. 조립 지침이 인터넷의 평균적인 버전이 아니라, 교육 전문가가 검증한 내용과 일치해야 하기 때문입니다.

두 번째 전략은 역할입니다. 이 보조 도구는 교사를 대체하는 것이 아니라 교사의 조력자(Assistant)로 설계되었습니다. 이는 리스크의 절반을 제거합니다. 만약 모델이 안전 수칙에서 오류를 범하더라도, 모델과 아이 사이에는 해당 수칙을 미리 읽고 검증할 수 있는 성인이 있기 때문입니다.

유사한 제한적 보조 도구를 구축하는 방법

핵심: 세 가지가 필요합니다 — 검증된 콘텐츠 세트, 해당 콘텐츠에 답변을 결합하는 것(Grounding), 그리고 보조 도구가 답변하지 말아야 할 명확한 경계입니다.

단계별로 살펴보겠습니다. 파일럿 프로젝트에서 사용했던 것과 동일한 논리를 의도적으로 유지하겠습니다: 먼저 콘텐츠, 그다음 결합(Grounding), 마지막으로 역할입니다.

1. 콘텐츠를 수집하고 검토하십시오. 텍스트, 교육 지침서, 조립 설명서 등 기존의 학습 모듈을 그대로 가져오십시오. 이는 해당 과목을 담당하는 사람이 반드시 검토해야 합니다. 모델이 당신을 대신해 지침서를 검토해주지는 않습니다.
2. '참조(Reference)'와 '생성(Generation)'을 분리하십시오. 파일럿에서는 12개의 모듈이 참조용으로 제공되지만, 프로젝트는 10개에 대해서만 생성됩니다. 동일하게 구성하십시오: 일부 주제는 검증된 내용만 읽도록 하고, 일부는 그 내용을 바탕으로 아이디어를 생성하도록 합니다. 이 둘을 섞지 마십시오.
3. 그라운딩(Grounding)을 설정하십시오. 기술적으로 이는 검색(Retrieval)입니다: 답변하기 전에 관련 문서 조각들을 불러와 모델에 컨텍스트(Context)로 전달하십시오. 모델은 '자신의 머릿속'이 아니라 전달된 내용을 바탕으로 답변합니다.
4. 시스템 프롬프트(System Prompt)에 경계를 명시하십시오. 모듈 범위를 벗어난 질문이 들어왔을 때 어떻게 해야 하는지 모델에게 명확히 지시하십시오: 지어내지 말고, 사용자를 프로그램이나 교사에게 다시 안내하도록 합니다.
5. 인간을 루프에 포함시키십시오(Human-in-the-loop). 안전 및 물리적 조립과 관련된 모든 사항에 대해 모델의 답변은 성인을 위한 초안일 뿐, 아이에게 내리는 명령이 아닙니다.

역할과 경계를 설정하는 시스템 프롬프트의 간략한 예시:

당신은 실험실 교사의 조력자이며, 학생의 대화 상대가 아닙니다.
아래에 전달된 학습 모듈에 따라서만 답변하십시오.
질문이 모듈의 범위를 벗어난다면, 솔직하게 이를 알리십시오.
...

주의하십시오: 이것은 보증이 아닙니다. 시스템 프롬프트 (System Prompt)는 위험을 줄여주지만, 인간의 검토를 대체하지는 않습니다. 모델은 특히 긴 대화 과정에서 지침을 무시할 수 있습니다.

액세스 및 코드: 러시아에서 접속하는 방법

핵심: 러시아에서 Gemini를 직접 사용하려면 해외 카드와 차단 우회(VPN)가 필요한 경우가 많지만, 호환 가능한 API를 사용하면 이 두 가지 번거로움을 모두 제거할 수 있습니다.

여기서 개념을 혼동하지 않는 것이 중요합니다. Gemini는 Google의 모델입니다. NotebookLM은 문서 작업을 위한 Google의 별도 제품이며, 파일럿 프로젝트에서는 콘텐츠 저장소로 이 제품이 사용됩니다. provod.ai는 NotebookLM을 대체하거나 그 기능을 제공하는 것이 아닙니다. 이는 여러 모델 제품군을 비교하거나 전환해야 할 때, 하나의 호환 가능한 API를 통해 모델 자체에 접근할 수 있게 해주는 서비스입니다.

러시아 독자들에게 실질적인 의미는 간단합니다. provod.ai는 Claude, GPT, Gemini, DeepSeek, Qwen을 하나의 채팅창에 통합하여 제공하며, OpenAI 및 Anthropic의 SDK와 호환되는 단일 API를 제공합니다. 즉, 키(Key)와 base_url만 변경하면 나머지 코드는 그대로 유지됩니다. 러시아 카드를 통한 루블 잔액 결제, SBP(Faster Payments System) 또는 계좌 이체를 지원하며, VPN이나 해외 카드 없이도 작동합니다. 법인 고객을 위한 계약, 인보이스 및 증빙 서류도 제공됩니다. 이는 두 개의 해외 구독을 가입하지 않고도 Gemini와 Claude가 보안 지침을 어떻게 작성하는지 비교하고 싶을 때 딱 맞는 사례입니다.

다음은 OpenAI SDK를 통한 최소한의 호출 예시입니다. 키와 기본 주소만 변경하면 됩니다:

from openai import OpenAI

# 자신의 키로 교체하세요. 리포지토리에 커밋하지 마십시오.
...

키는 코드에 직접 넣지 말고 환경 변수 (Environment Variable)로 빼두십시오. model 필드의 모델 이름은 파라미터로 유지하십시오. 그렇게 하면 1분 만에 Gemini에서 Claude로 전환하여 하나의 프롬프트에 대한 두 응답을 비교할 수 있습니다.

어떤 모델을 선택해야 하며 비용은 얼마나 드는가

핵심: 좁은 범위의 학습 보조 도구(tutor)를 위해서는 가장 강력한 모델보다, 예측 가능성이 높고 대량 사용 시 비용이 저렴한 모델이 승리하는 경우가 많습니다. 정확한 가격은 서비스 시작 시점의 제공업체 가격표를 확인하십시오.

토큰당 구체적인 수치를 언급하지는 않겠습니다. 수치는 계속 변하며, 기사 내의 어떤 가격표도 읽기도 전에 구식이 될 것이기 때문입니다. 올바른 접근 방식은 타인의 벤치마크(benchmark)가 아니라, 자신의 작업(task)에 모델을 직접 비교해 보는 것입니다.

학습 시나리오를 위한 선택 논리는 다음과 같습니다:

• 예측 가능하고 큰 볼륨 (교사들로부터 오는 수백 개의 동일한 형식의 요청) — 더 저렴한 모델을 선택하고, 해당 모델의 품질이 근거 제시(grounding)에 충분한지 확인하십시오. 대개는 충분합니다.
• 긴 컨텍스트(long context) 작업이 필요한 경우 (프롬프트에 모듈 전체를 포함) — 모델의 "지능"이 아니라 해당 모델의 컨텍스트 제한(context limit)을 확인하십시오.
• 경계 준수의 엄격함이 중요한 경우 — 어떤 모델이 모듈의 범위를 벗어나는 일이 더 적은지 테스트하십시오. 이는 모델의 크기 문제가 아니라 동작(behavior)의 문제입니다.

실무적인 팁: 교사들의 실제 질문 20개를 가져와서 동일한 시스템 프롬프트(system prompt)로 2~3개의 모델에 실행해 보고 답변을 나란히 비교해 보십시오. provod.ai는 모든 모델 제품군을 하나의 키와 하나의 잔액으로 사용할 수 있어 편리합니다. 세 명의 후보를 공정하게 비교하기 위해 세 명의 제공업체에게 각각 비용을 지불할 필요가 없습니다.

공정한 경계에 대해 다시 한번 말씀드리자면: provod.ai는 자동화 플랫폼을 대체하거나 GigaChat을 제공하지 않으며, 개인용 또는 온프레미스(on-prem) 인프라, 벤더 자체의 구독을 통해서만 사용할 수 있는 기능, 그리고 구축(implementation) 작업을 대체하지 않습니다. 이것은 모델에 대한 접근 권한이지, 즉시 사용 가능한 완성된 학교용 솔루션이 아닙니다.

전형적인 오류와 이를 포착하는 방법

핵심: 이러한 보조 도구에서 발생하는 대부분의 장애는 "모델이 멍청해서"가 아니라, "모델이 문서에 따라 답변하지 않거나" 또는 "경계가 무너졌기(leakage)\

만약 당신이 위의 단계들로 파이프라인을 구축하고 이를 자동화 도구(예: 교사들이 양식을 통해 질문을 보낼 수 있도록 하는 n8n 등)에 연결한다면, 세 가지 유형의 문제에 대비해야 합니다.

1. 콘텐츠 이탈 답변 (Answer off-content). 모델이 답변은 유려하게 하지만, 당신이 제공한 모듈을 따르지 않는 경우입니다. 징후: 답변에 가이드북에 없는 세부 사항이 나타납니다. 해결책: 검색 (Retrieval) 과정이 실제로 필요한 부분을 제대로 가져오는지, 그리고 그 내용이 질문에 전달되기 전에 프롬프트 (Prompt)에 포함되는지 확인하십시오.
2. 경계 유출 (Leaked boundaries). 어시스턴트가 프로그램 범위를 벗어난 질문에 답변하기 시작하는 경우입니다. 징후: "이웃의 Wi-Fi를 해킹하는 방법"과 같은 질문에 상세한 답변을 내놓습니다. 해결책: 시스템 프롬프트 (System Prompt)를 강화하고, 메인 질문을 처리하기 전 별도의 빠른 요청을 통해 주제 적합성을 검사하는 단계를 추가하십시오.
3. 안전성에 대한 위험한 확신 (Dangerous confidence in safety). 모델이 안전 조치를 사실인 것처럼 단호한 어조로 출력하지만, 그 조치가 불완전한 경우입니다. 이는 가장 비용이 많이 드는 유형입니다. 해결책: 안전 섹션을 초안(Draft)으로 표시하고, 사람에 의한 검토 (Human-in-the-loop)를 선택 사항이 아닌 필수 단계로 설정하십시오.

n8n 통합에 대해 별도로 언급하자면, 전형적인 실수는 전체 모듈이 컨텍스트 (Context)로 넘어갈 때 긴 프롬프트로 인해 발생하는 타임아웃 (Timeout)입니다. 콘텐츠를 조각으로 나누고, 정확히 어떤 파편들이 요청에 포함되었는지 로그 (Log)를 남기며, 네트워크 오류에 대비한 백오프 (Backoff) 재시도 로직을 유지하십시오. 프롬프트에 실제로 무엇이 포함되었는지에 대한 로그 없이는, 당신은 엉뚱한 계층을 수정하게 될 것입니다.

이 파일럿 프로젝트와 접근 방식이 해결하지 못하는 것

기대치를 솔직하게 설정하십시오. 다음 사항들은 이번 범위에서 제외됩니다.