블로그›기술
기술

대학 AI 플랫폼 구축: 클라우드형 vs 온프레미스

대학 AI 플랫폼 구축 방식은 데이터가 학교 밖으로 나갈 수 있는지로 정합니다. 데이터를 나누는 법, 확인할 법령과 지침, 클라우드형과 온프레미스의 구조, 함께 쓸 때 확인할 것, 일정과 운영의 차이, 고르는 기준을 결정표로 정리했습니다.

유에이지·2026-11-01·8분·조회 0회
대학 AI 플랫폼 구축: 클라우드형 vs 온프레미스

대학 AI 플랫폼 구축 방식은 데이터가 학교 밖으로 나갈 수 있는지로 정합니다.

외부 모델로 보내도 되는 데이터가 중심이면 클라우드형, 밖으로 나갈 수 없는 데이터가 중심이면 온프레미스, 나갈 수 있는 데이터(가린 뒤 포함)와 나갈 수 없는 데이터가 섞여 있으면 함께 쓰는 구성을 검토합니다.

대학 AI 플랫폼 구축은 장비를 고르기 전에 데이터부터 나눠야 합니다. 이 글은 대학 생성형 AI 플랫폼, 도입 전에 정해야 할 5가지의 다섯째 항목 "데이터를 밖으로 보낼 수 있나"를 이어받아, 정보처·전산원·정보보호 담당자가 방식을 고를 때 볼 기준을 정리했습니다.

이 데이터는 학교 밖으로 나갈 수 있나요?

방식을 비교하기 전에 쓰려는 데이터를 세 묶음으로 나눕니다.

  • 나가도 되는 데이터 — 외부 모델로 보내도 문제가 없는 자료입니다.
  • 가려서 내보낼 데이터 — 개인정보가 섞여 있어, 가린 뒤 내보내도 되는지 담당 부서가 판단한 자료입니다.
  • 나갈 수 없는 데이터 — 규제나 기밀 때문에 기관 밖으로 반출할 수 없는 자료입니다.

학생 실습, 교직원 업무, 연구실 과제는 다루는 데이터가 다르므로 업무별로 나눠 봅니다.

방식을 고르기 전에 데이터를 세 묶음으로 나누는 도식 — 나가도 되는 데이터는 클라우드형 외부 모델로 바로, 가려서 내보낼 데이터는 마스킹·기밀 차단을 먼저 거쳐 클라우드형 외부 모델로, 나갈 수 없는 데이터는 내부망 안에서 처리해 온프레미스 로컬 모델로 이어짐

학교 밖으로 보낼지는 어떤 기준으로 확인하나요?

아래는 출발점이 되는 공식 자료입니다(2026년 11월 1일 확인). 우리 학교에 어떻게 적용되는지는 정보보호·개인정보 담당 부서에 확인합니다.

  • 개인정보 보호법 제28조의8 — 개인정보를 국외로 제공·처리위탁·보관하는 일을 "이전"으로 묶고, 별도 동의 등 법에 정한 경우에만 할 수 있게 합니다. 외부 모델이 국외에서 운영된다면 개인정보가 담긴 요청이 여기에 해당하는지 살펴봅니다(법령 원문).
  • 국가 사이버보안 기본지침(국가정보원, 2026년 5월) — 적용 대상인 "각급기관"에 국·공립학교가 들어갑니다. 업무정보를 기밀·민감·공개 등급으로 나누고(제39조의2), 인공지능시스템을 구축·운용할 때 보안대책을 세우도록 합니다(제72조의2). 공무원등이 인공지능을 활용한 상용 서비스로 기밀·민감등급 업무정보를 작성·저장·주고받는 일은 일부 경우를 빼고 금지합니다(제66조제4항)(지침 원문).
  • 교육 목적 환경 — 같은 지침은 국·공립학교의 교육 목적 정보통신환경을 "교육현장"으로 따로 정의합니다. 교육현장에서는 민간 클라우드를 학교장 책임 아래 이용할 수 있고(제24조의4제3항), 위 상용 서비스 금지를 포함한 제66조제1~5항이 적용되지 않습니다(제66조제6항). 다만 교육부장관과 시·도 교육감이 보안관리 방안을 따로 세울 수 있습니다. 같은 학교 안에서도 환경에 따라 기준이 다를 수 있습니다.
  • 사립대학 — 이 지침의 "각급기관" 정의에 사립학교는 적혀 있지 않습니다. 다만 교육부장관과 시·도 교육감이 사립학교를 지도·감독할 때 이 지침을 참고해 사이버보안업무를 관리·감독하도록 한 조항이 있습니다(제150조제2항). 학내 보안 규정, 참여 사업의 조건과 함께 확인합니다.

개인정보보호위원회의 생성형 AI 개발·활용 개인정보 처리 안내서(안내서 공개 보도자료, 2025년 8월)는 활용 방식을 서비스형 LLM 활용, 기성 LLM 활용, 자체개발로 나눠 기준을 제시합니다. 클라우드형은 첫째, 온프레미스의 로컬 모델은 둘째에 가깝습니다.

클라우드형은 어떻게 동작하나요?

클라우드형은 요청이 관리형 게이트웨이를 거쳐 외부 모델로 나가는 구조입니다. 학교에 GPU 서버를 들이지 않고 시작합니다. UAG.IM의 관리형 AI 게이트웨이를 기준으로 보면 이렇습니다.

  • 보호 — 요청은 외부 모델로 나가기 전에 개인정보 마스킹과 기밀 차단 규칙을 거치고, 호출 기록은 지울 수 없는 감사 로그로 보관됩니다.
  • 모델 — 통합 엔드포인트 하나로 340개가 넘는 모델을 부르고, 쓸 수 있는 범위는 역할·부서별 정책으로 나눕니다.
  • 관제 — 유에이지의 기관용 AI 통합관리 서비스 Gadia AIMS를 함께 쓰면 실시간 사용·비용 대시보드로 누가 어떤 모델을 얼마나 쓰는지 봅니다. 이상 사용·급증은 감지해 알리고, 월 한도의 80%에 다다르면 알림을 보내며, 초과하면 정한 정책대로 동작합니다.

마스킹과 기밀 차단은 외부로 보내도 되는 요청의 노출을 줄이는 장치입니다. 나갈 수 없는 데이터를 나갈 수 있게 바꾸는 장치는 아닙니다. 데이터가 아예 기관 밖으로 나갈 수 없다면 온프레미스를 검토합니다. 가려서 내보낼 데이터라면 마스킹이 학교 밖으로 나가기 전에 적용되는지도 도입 전에 확인합니다.

게이트웨이를 직접 세울지 맡길지는 AI Gateway 구축, 직접 할까 관리형으로 맡길까에서 다뤘습니다.

온프레미스는 어떻게 구성하나요?

온프레미스는 AI 서버와 인프라를 기관 내부망 안에 직접 구축해, 데이터가 기관 밖으로 나가지 않게 하는 방식입니다. UAG.IM의 온프레미스 AI 서버는 다음 요소로 설계합니다.

  • GPU 서버 — 모델 크기, 동시 사용자, 목표 응답 속도를 계산해 규모를 정합니다. 과투자도 병목도 없게 맞추는 일입니다.
  • 로컬 모델 — 내부망 안에 모델을 배포하고 운영합니다.
  • 저장소 — NAS·사내 스토리지를 연동합니다.
  • 운영 콘솔 — 설치형 운영 콘솔과 계정 관리로 기관이 직접 통제합니다.

저장과 처리 전 과정을 내부에 두므로 데이터 주권을 지키기 좋고, 외부 API의 요금·정책 변화에 덜 흔들립니다. 인터넷이 차단된 폐쇄망이라면 모델과 보안 패치를 안전하게 반입·업데이트하는 절차까지 함께 설계합니다.

서버를 놓는 것과 운영되는 AI는 다릅니다. 구축 전에 동시 사용자, 목표 응답 속도, 로컬 모델이 맡을 업무, 갱신 담당자를 정해 둡니다.

두 구조를 나란히 놓은 도식 — 클라우드형은 학생·교직원·연구실의 요청이 마스킹·기밀 차단과 감사 로그를 맡는 관리형 게이트웨이를 거쳐 외부 모델로 이어지고, 온프레미스는 점선으로 둘러싼 학교 안 내부망에 내부 단말, 로컬 모델(GPU 서버), NAS·사내 스토리지, 운영 콘솔·계정 관리가 모여 있으며 밖으로 나가는 길이 없음

둘을 함께 쓰는 구성을 검토할 때 무엇을 확인하나요?

데이터가 섞여 있다면 두 방식을 함께 쓰는 구성도 검토 대상입니다. UAG.IM 멀티 모델 라우팅 페이지는 요청의 민감도·비용·용도에 따라 로컬(T0)부터 프론티어(T3)까지 나누는 구조를 설명합니다. 실제 구성과 제공 범위는 상담에서 확인합니다.

도입 전에 세 가지를 확인합니다.

  1. 민감도를 판단하는 라우터는 어디서 돌아가나 — 판단 지점에 따라 요청이 지나는 길이 달라집니다.
  2. 나갈 수 없는 데이터가 판단 전에 밖을 지나지 않나 — 판단을 위해 밖을 먼저 지난다면 이 글의 첫 기준과 어긋납니다.
  3. 로컬 모델이 실패할 때 고민감 요청이 외부 모델로 넘어가지 않나 — 실패한 요청이 넘어가는 다음 후보에 외부 모델이 들어 있는지 봅니다.

함께 쓰는 구성을 검토할 때 확인할 세 가지를 표시한 도식 — 요청, 민감도 판단 라우터, 내부망 로컬 모델, 외부 모델을 차례로 놓고, 라우터 위에 1번(라우터는 어디서 돌아가나), 요청과 라우터 사이에 2번(판단 전에 밖을 지나지 않나), 로컬 모델과 외부 모델 사이 점선에 3번(실패할 때 외부로 넘어가지 않나)을 붙이고 아래에 세 질문을 풀어 쓴 카드가 있음

일정과 운영은 어떻게 달라지나요?

항목 클라우드형 온프레미스
시작까지 상담·계약 후 셋팅이 보통 1~3영업일 진단 후 범위에 따라 일정을 정함
운영 관제 24/7 운영 관제를 UAG.IM이 맡고 기관은 대시보드로 확인 사용률·성능·장애를 관제하며 지속 유지보수

온프레미스는 현장 상주 엔지니어링(FDE)으로 실무 정착과 내부 담당자 이관까지 함께할 수 있습니다.

우리 대학은 어떤 방식이 맞나요?

어느 방식이 언제나 낫지는 않습니다. 네 가지 기준을 보되 첫 줄인 데이터 등급이 가장 앞섭니다.

기준 클라우드형 온프레미스 함께 쓰는 구성
데이터 등급 외부 모델로 보내도 되는 데이터가 중심 밖으로 나갈 수 없는 데이터가 중심 나갈 수 있는 데이터(가린 뒤 포함)와 나갈 수 없는 데이터가 섞여 있음
사용 인원 학생·교직원 다수에게 학기 단위로 엶 동시 사용자를 가늠해 GPU를 설계 데이터 묶음별로 쓰는 사람을 나눠 봄
쓸 모델 여러 프론티어 모델이 필요 로컬 모델로 처리할 업무가 분명 외부 모델과 로컬 모델의 업무 구분을 검토
예산 시기 사용량에 맞춰 크레딧으로 시작 진단으로 범위를 정한 뒤 예산 편성 구성과 제공 범위를 상담에서 확인한 뒤 순서를 정함

결정표 도식 — 데이터 등급, 사용 인원, 쓸 모델, 예산 시기 네 줄을 클라우드형, 온프레미스, 함께 쓰는 구성 세 칸으로 비교한 표

상담 전에 데이터 묶음별 목록, 사용 인원, 쓰려는 모델, 예산 시기를 정리해 두면 좋습니다. 대학 전체 구성은 대학 생성형 AI 통합 플랫폼에서 볼 수 있습니다.

자주 묻는 질문

마스킹을 거치면 어떤 데이터든 외부 모델로 보내도 되나요?

그렇지 않습니다. 마스킹과 기밀 차단은 외부로 보내도 되는 요청의 노출을 줄이는 장치입니다. 데이터가 아예 기관 밖으로 나갈 수 없다면 온프레미스를 검토합니다.

내부망 AI 서버의 규모는 무엇으로 정하나요?

모델 크기, 동시 사용자, 목표 응답 속도를 계산해 정합니다.

클라우드형과 온프레미스를 함께 쓰려면 무엇을 확인하나요?

라우터 위치, 판단 전 데이터 경로, 로컬 모델이 실패할 때의 경로를 봅니다. 구성과 제공 범위는 상담에서 확인합니다.

국·공립대학과 사립대학은 확인할 기준이 다른가요?

다를 수 있습니다. 국가 사이버보안 기본지침의 "각급기관"에는 국·공립학교가 들어가고, 교육 목적 정보통신환경은 "교육현장"으로 따로 정의돼 민간 클라우드와 상용 서비스 조항이 달리 적용됩니다(제24조의4제3항, 제66조제6항). 사립학교에 대해서는 교육부장관과 시·도 교육감이 지도·감독할 때 이 지침을 참고하도록 한 조항이 있습니다(제150조제2항). 적용 여부는 담당 부서에 확인합니다.

관련 카테고리 최신글
AI Gateway 구축, 직접 할까 관리형으로 맡길까
기술

AI Gateway 구축, 직접 할까 관리형으로 맡길까

AI Gateway 구축은 직접도, 관리형도 됩니다. 갈림길은 계약·결제·키·한도·보안·관제를 누가 맡느냐입니다. 고르는 기준을 정리했습니다.

2026-10-27 · 8분
멀티 LLM 플랫폼이란? ChatGPT·Claude·Gemini를 한 API로
기술

멀티 LLM 플랫폼이란? ChatGPT·Claude·Gemini를 한 API로

멀티 LLM 플랫폼은 여러 AI 모델을 하나의 API로 쓰고, 키·예산·정책·기록을 한 곳에서 관리하게 하는 구조입니다.

2026-10-19 · 6분
에이전틱 워크플로우로의 전환
기술

에이전틱 워크플로우로의 전환

생성형 AI가 답변을 만들어줬다면, 에이전틱 AI는 업무를 완수한다. - 지금부터 준비해야 할 멀티 에이전트 시스템의 모든 것.

2026-03-19 · 8분
관리형 AI 게이트웨이, 우리 조직에도 도입하고 싶으신가요?
조직 상황에 맞는 도입 범위와 일정을 함께 안내해 드립니다.