2026년 10월 20일

사내 데이터와 24시간 운영 책임: AI 인프라 2가지 비교

사내 데이터 경계와 24시간 운영 책임을 기준으로 클라우드의 구내 확장과 온프레미스 RAG 플랫폼·MSP 조합을 비교하고, 내부 운영 인력이 부족하면 후자를 우선 검토하도록 안내합니다. Seahorse는 플랫폼이며 인프라 관제는 별도 계약으로 정합니다.

사내 데이터 경계와 야간 장애 대응을 함께 정해야 하는 조직은 원본·색인·로그·백업의 위치와 실제 대응 담당자를 나누어 비교합니다. 클라우드의 구내 확장과 온프레미스 AI 플랫폼·MSP 조합을 감지, 호출, 복구 승인과 서비스 재검증 책임으로 평가합니다. 두 경로 중 조직이 허용한 데이터 통제와 운영 조건을 충족하는 구성을 선택합니다.

핵심 요약

경계를 먼저 정합니다: 원본, 복제본, 로그와 관리 정보를 어디에 둘지 각각 정해야 적합한 인프라를 고를 수 있습니다.
운영 범위를 계약합니다: 모니터링, 장애 대응, 패치와 복구의 담당자 및 처리 범위를 각각 정합니다.
두 경로를 비교합니다: 클라우드 사업자의 온프레미스 확장과 온프레미스 AI 플랫폼 및 별도 MSP 조합을 데이터 위치와 운영 책임으로 나눠 봅니다.
플랫폼과 MSP를 구분합니다: Seahorse Cloud는 온프레미스 설치가 가능한 검색 증강 생성(Retrieval-Augmented Generation, RAG) 플랫폼이며, 24시간 인프라 운영은 별도 담당자와 계약으로 정합니다.

1. ‘사내 데이터’의 경계를 데이터 종류별로 정합니다

기업의 데이터 정책은 저장 장소뿐 아니라 어떤 데이터가 그 경계를 벗어날 수 있는지도 규정합니다. 어떤 회사는 데이터가 회사 소유 건물의 장비 안에 있어야 한다고 요구하고, 다른 회사는 회사가 승인한 국내 데이터센터에 둘 수 있다고 정합니다. 또 다른 회사는 원본 파일만 지정 위치에 두고, 검색 인덱스나 로그 같은 파생 정보는 별도로 관리하기도 합니다.

개인정보 처리 위치와 수탁자의 업무 범위는 관련 법령과 계약에 따라 정합니다. 「개인정보 보호법」 제28조의8은 개인정보를 국외로 제공하거나 국외에서 조회하게 하는 경우, 국외에 처리위탁하거나 보관하는 경우를 국외 이전의 범위에서 다룹니다.

국내 개인정보 처리위탁의 문서화·보호조치·수탁자 감독은 적용되는 법령과 계약으로 확인합니다. 외부 시설이나 MSP를 이용하는 조직은 처리 장소, 처리 주체, 재위탁과 접근 범위를 법무·보안 담당자에게 연결해 검토합니다. 특정 기관의 개인정보 처리방침을 모든 조직의 법적 요건을 대신하는 근거로 쓰지 않습니다.

회사는 다음 항목을 데이터 목록에 넣으면 경계를 구체화할 수 있습니다.

원본: 문서, 이미지, 데이터베이스 레코드, 사용자 입력과 그 안의 개인정보를 구분합니다.
복제본: 백업, 재해복구 사본, 임시 처리 파일, 캐시와 수동 반출 파일이 저장되는 곳을 적습니다.
검색·AI 데이터: 문서를 나눈 청크, 임베딩(텍스트를 수치로 표현한 데이터), 벡터 인덱스(의미 검색용 색인), 추출 메타데이터, 모델에 전달한 입력과 출력을 목록화합니다.
운영 정보: 접속 기록, 질의 로그, 오류 추적 정보, 감사 기록, 키와 인증 정보의 위치 및 접근자를 정합니다.
관리 제어 영역: 콘솔, 원격 관리 연결, 업데이트 전달 경로, 모니터링 데이터와 지원 인력의 접근 경로를 포함합니다.

원본 데이터와 운영 정보는 별도 범주로 분류해 각각 허용 위치와 접근 기준을 정합니다. 반대로 회사 정책이 승인한 외부 시설에 데이터를 두더라도 계약, 접근통제와 기록 관리로 운영 경계를 정할 수 있습니다. 항목별로 허용 위치와 허용 주체를 정하면 공급자의 “데이터는 로컬에 있다”는 설명을 회사 기준에 대조하기 쉬워집니다. 원본이 로컬에 있더라도 외부 모델·파서로의 전송과 지원 인력의 접근 경로는 별도로 확인합니다.

NIST의 미국 정부 클라우드 컴퓨팅 기술 로드맵은 클라우드로 처리·저장·전송할 정보의 보안 범주가 필요한 통제 선택을 이끈다고 설명합니다. 조직은 업무별 데이터 유형과 위험 수준을 먼저 정하고, 계약과 시스템 설계에서 해당 통제를 누가 구현할지 연결해야 합니다. 이 원칙은 한국 조직의 내부 분류 체계를 만드는 데도 유용한 설계 기준입니다.

2. Google Distributed Cloud connected 사례에서 관리 역할까지 확인합니다

Google Distributed Cloud connected는 클라우드 관리 서비스를 고객 구내 하드웨어로 확장하는 한 사례로, Kubernetes 제어 플레인(클러스터의 상태와 노드를 관리하는 계층)을 현장 장비에서 실행합니다.

Google의 작동 구조 문서는 이 제품에서 Google 사이트 신뢰성 엔지니어(SRE)가 구성 문제를 해결하고 패치와 업데이트를 설치하며 보안을 유지하고, Google이 소프트웨어와 노드 연결 가능성을 원격으로 관리한다고 설명합니다. 이는 Google Distributed Cloud connected에 한정된 역할 분담이며, 다른 공급자의 구내 확장 서비스에도 같은 운영 역할이 적용된다는 뜻은 아닙니다.

같은 문서에서 Google 인증 시스템 통합업체(SI)는 하드웨어를 배포하고 유지하며, 고객의 네트워크 관리자는 로컬 네트워크 연결과 접근 제어, 라우팅, 방화벽 규칙을 구성하고 유지합니다. 즉, 사업자가 맡는 소프트웨어·하드웨어 관리와 고객 측 네트워크 운영을 책임표에서 분리해야 합니다.

Google은 해당 구내 설치의 Google Cloud 리전이 가까운 Google 데이터센터의 위치에 따라 정해진다고 설명합니다. 또 Distributed Cloud connected는 인증 토큰과 스토리지 암호화 키를 갱신하고 관리·감사 로깅 데이터를 동기화하기 위해 Google Cloud와 다시 연결해야 합니다.

연결이 끊겼을 때의 조건도 운영계획에 넣습니다. Google 가용성 권고 문서는 Distributed Cloud connected가 SLA를 제공하지 않는다고 명시합니다. 연결이 끊겨도 워크로드는 계속 실행될 수 있지만, 최대 7일간 지속 가용성이 보장된다는 뜻은 아닙니다. 해당 제품은 토큰과 스토리지 암호화 키를 갱신하고 관리·감사 로깅 데이터를 동기화하기 위해 7일마다 Google Cloud에 재연결해야 합니다.

이 경로는 클라우드 사업자가 플랫폼 운영 일부를 맡고 고객이 구내 네트워크와 데이터 사용 정책을 관리할 때 적합합니다. 조직은 계약과 배포 설계에서 원본, 인덱스, 백업, 로그, 관리 트래픽의 위치를 구분하고, 고객이 맡는 네트워크 운영에 필요한 인력도 산정합니다. 회사 정책이 구내 설치뿐 아니라 외부 관리 연결까지 제한한다면 해당 서비스의 연결 방식이 정책에 들어맞는지 별도로 판단합니다.

온프레미스는 배치 위치를 뜻하고, 에어갭은 외부 네트워크와의 물리적 연결 분리를 뜻합니다. Google의 별도 Distributed Cloud air-gapped 문서는 물리적·논리적 완전 격리가 필요한 조직을 위한 관리형 하드웨어·소프트웨어 플랫폼으로 설명합니다.

이 에어갭 제품의 보안 역할 문서는 인프라 운영자가 일상 인프라 운영을 맡고 고객 데이터에는 접근하지 않는다고 설명하며, 운영자는 Google, 계약된 제3자 또는 고객이 될 수 있다고 밝힙니다. 에어갭 환경에서는 인프라 운영자가 업데이트 파일을 검증하고 시스템 안으로 옮겨 배포합니다. 이 사례는 배치 위치뿐 아니라 운영자를 지정하는 일이 별도 설계 항목임을 보여줍니다.

3. 온프레미스 AI 플랫폼과 MSP는 서로 다른 일을 맡습니다

회사가 데이터와 RAG 시스템을 자체 환경에 두려면 AI 플랫폼과 인프라 운영을 두 역할로 나눌 수 있습니다. 플랫폼은 문서 수집, 파싱, 검색 인덱스, 벡터 검색과 에이전트 실행을 지원합니다. 관리형 서비스 제공자(MSP)는 별도 계약으로 정한 서버, 네트워크, 운영체제, 데이터베이스와 모니터링 업무를 맡을 수 있습니다.

온프레미스 플랫폼 후보를 책임표에 넣을 때 Seahorse Cloud 제품 문서로 실제 사용할 구성요소를 확인합니다. 각 구성요소의 야간 대응·유지보수·복구 담당자는 선택한 제공 방식과 계약의 대상 시스템에 연결합니다.

이 통합 범위는 팀이 별도로 연결하고 운영해야 하는 RAG 구성요소의 수를 줄이는 선택 근거가 됩니다. 예를 들어 문서가 스토리지에 들어오면 파싱과 청킹을 거쳐 벡터 데이터베이스와 연계하는 흐름을 하나의 RAG 플랫폼 안에서 설계할 수 있습니다. 매니지드 에이전트는 검색 기반 애플리케이션과 에이전트 기능을 같은 플랫폼 논의에 포함합니다.

제품 통합은 권한 상속이나 즉시 동기화, 무중단 운영을 자동으로 의미하지 않으므로, 문서 변경 처리 시간과 권한 전달, 실패 재처리 방식을 실제 구성에서 검증합니다.

Seahorse Cloud는 Kubernetes 네이티브 아키텍처이며 온프레미스 설치 또는 SaaS 구독으로 제공됩니다. 이 구분은 전달 모델과 호스팅 위치를 함께 확인해야 한다는 뜻입니다. 온프레미스 설치는 회사가 정한 환경에 플랫폼을 배치하는 선택지입니다. 제품의 매니지드 플랫폼 기능은 RAG 구성요소의 연결·운영에 쓰이고, MSP 계약은 서버 관제, 야간 장애 대응, OS 패치와 백업 복구 등 외부에 맡길 인프라 업무를 정합니다.

선택한 계약에서 문서 처리·벡터 갱신·검색 품질·에이전트·도구 연결과 서버·네트워크·호스트 보안을 각각 담당 역할에 연결합니다. 제품이나 설치 위치만으로 같은 공급자 또는 내부팀이 모든 계층을 운영한다고 정하지 않습니다.

MSP 계약은 “24시간 지원”이라는 문구만으로 고르기보다 대상 시스템과 조치를 적어야 합니다. 계약표에 다음 범위를 넣으면 야간 호출을 받아도 누가 무엇을 해야 할지 명확해집니다.

운영 항목	계약서에 정할 내용
모니터링과 알림	대상 장비, 플랫폼 구성요소, 로그, 감시 시간, 알림 수신자와 에스컬레이션 경로
장애 대응	24시간 적용 대상, 최초 응답 시간, 담당자 연결 방식, 원격·현장 조치의 경계
패치와 변경	OS·펌웨어·컨테이너·플랫폼별 승인자, 적용 창구, 롤백과 변경 기록
백업과 복구	백업 대상, 사본 위치, 보존 기간, 복구 시험, 실제 복구 실행 주체
RAGOps	문서 처리 실패, 인덱스 상태, 검색 점검, 재처리와 변경 검증의 담당자
AgentOps·MCP	에이전트 버전, 도구 연결, 자격증명, 오류 추적, 배포 승인과 비상 중지 담당자

운영 범위가 분리되면 장애가 생겼을 때 플랫폼 문제인지 인프라 문제인지 분류할 기준도 필요합니다. 예를 들어 검색 결과가 오래된 경우 문서 수집 파이프라인과 벡터 동기화를 점검하고, 서버 자원 문제라면 MSP의 시스템 경보 및 인프라 조치를 연결합니다. 외부 도구 호출 실패는 MCP 연결, 인증 정보, 네트워크 경로 중 어디서 발생했는지 운영 로그에서 추적할 수 있도록 역할별 접근 권한과 에스컬레이션을 정합니다.

운영 로그에는 업무 목적에 필요한 정보만 남기고 개인정보와 비밀값을 가립니다. 검색 질의나 도구 호출 기록을 보관할 때는 접근 권한과 보존 기간도 정합니다. MSP와 플랫폼 운영팀이 함께 장애를 분석하더라도 각자가 볼 수 있는 로그의 범위와 고객 데이터 처리 조건을 계약 및 접근 정책에 반영합니다.

4. 두 경로를 같은 기준으로 비교합니다

두 경로는 “데이터가 어디에 있는가”와 “누가 운영하는가”를 별도 기준으로 비교해야 합니다. 첫 번째 경로는 모든 클라우드 구내 확장을 대표하는 것이 아니라 Google Distributed Cloud connected 사례입니다. 그 운영 역할은 해당 제품 문서에 한정되며 다른 공급자에게 일반화하지 않습니다. 표는 각 경로의 데이터와 장비 배치, 외부 운영자의 역할, 조직에 남는 업무, 적합한 조건을 같은 기준으로 비교합니다.

경로	데이터·장비 배치와 연결	외부 운영자의 역할	조직에 남는 업무	적합한 조건
Google Distributed Cloud connected 예시	워크로드와 Kubernetes 제어 플레인을 고객 구내 하드웨어에서 실행하며 Google Cloud 관리 연결을 사용함. 이 제품은 SLA를 제공하지 않음	Google이 소프트웨어와 노드 연결 가능성을 원격 관리하고 SRE가 패치·구성 문제·보안을 담당하며, Google 인증 SI가 하드웨어를 배포·유지함	데이터와 정상 작동 중복 백업, 전력·냉각·물리 보안, 로컬 네트워크 보안·연결을 유지하고 데이터 경계와 허용 통신을 설계함	해당 제품의 관리 연결을 허용하고 고객 책임 범위 및 별도 운영 요건을 충족할 수 있음
온프레미스 RAG 플랫폼과 MSP	회사가 선택한 온프레미스 환경에 RAG 플랫폼과 데이터를 설치함. Seahorse Cloud는 온프레미스 설치를 지원함	플랫폼은 문서 처리, 벡터 데이터베이스와 매니지드 에이전트를 제공함. MSP는 별도 계약에 명시된 인프라 운영을 맡음	MSP의 책임과 플랫폼 운영을 나누고 데이터 정책, 접근 권한과 계약 이행을 관리함	회사가 정한 환경에 RAG를 배치하고, 계약으로 정한 인프라 업무를 외부에 맡기려 함

NIST의 클라우드 기술 로드맵은 클라우드 서비스 모델에 따라 제공자와 고객이 나눠 구현하는 보안·개인정보 통제의 책임이 달라지므로, 계약과 서비스 수준 협약(SLA)에 구체적인 책임 배분을 적도록 권고합니다.

계약과 운영계획에서는 24시간 대응 범위, SLA 제공 여부와 조건, 복구 시간 목표(RTO), 복구 시점 목표(RPO)를 업무별로 구분해 정합니다. RTO는 서비스 복구까지 목표로 하는 시간이고, RPO는 허용 가능한 데이터 손실을 시간으로 나타낸 범위입니다.

24시간 응답은 접수·응답 약속, 업타임은 서비스 가동률 지표, SLA는 합의된 서비스 수준과 조건을 정한 약정이므로 서로 대체할 수 없습니다. 24시간 모니터링은 경보를 감지하고 담당자에게 전달하는 범위입니다.

특히 Google Distributed Cloud connected는 SLA를 제공하지 않으므로, 일반적인 SLA 계약 권고가 해당 제품에 SLA가 있음을 뜻하지 않습니다. 조직은 비상계획에서 RTO와 RPO를 정하고, 시스템이 운영 상태로 돌아온 뒤 두 목표의 달성 여부를 평가합니다.

NIST의 정보시스템 비상계획 가이드는 시스템이 운영 상태로 돌아오면 복구 작업 시간을 멈추고 사고 중 RTO·RPO 목표가 충족됐는지 판단한다고 설명합니다. 그러므로 백업 보유 여부와 24시간 대응 인력은 다른 항목입니다. 백업은 복구에 사용할 사본이고, 운영자는 경보를 확인해 복구를 시작하고 검증하는 담당자입니다. 복구 시험을 수행하는 주기와 실제 복구 승인자를 함께 정하면 목표가 실행 가능한 절차가 됩니다.

실행 확인	남길 근거
복구 훈련과 인계	장애 시나리오, 호출 시각, 담당자 인계, 조치 단계와 서비스 정상화 확인 결과를 기록합니다.
비상계획 시험	NIST의 ITL 시험·훈련·연습 프로그램 안내는 시험 대상 시스템과 전체 목표를 시험 계획에 적고, 계획을 실제로 연습해 효과성을 확인하도록 안내합니다. 결과와 후속 조치를 남깁니다.
시험 주기	조직은 필요한 시험 빈도를 평가해 일정에 기록합니다. NIST 가이드는 보편적인 고정 간격 대신 필요에 맞춘 주기 설정을 제시합니다.

5. 우리 조직은 어떤 경로부터 검토하면 될까요?

회사는 데이터 정책, 외부 관리 연결 허용 여부, 내부 운영 역량, 역할 분담과 계약 범위를 비교한 뒤 적합한 경로를 선택합니다. 온프레미스 RAG 플랫폼과 MSP 조합, 클라우드의 구내 확장 모두 실제 데이터 경계와 관리 연결, 운영 책임 및 계약 조건을 기준으로 평가합니다.

파일 업로드는 되지만 검색 인덱스 갱신이 지연되는 상황에서는 MSP가 서버만 정상이라고 확인해도 업무가 복구된 것은 아닙니다. RAG 플랫폼 운영자는 수집 작업과 벡터 동기화 상태를 확인하고, MSP는 인프라 자원과 네트워크를 조사하며, 서비스 책임자는 검색 결과를 검증하도록 절차를 나눕니다. 에이전트가 승인되지 않은 도구에 연결되는 위험에는 도구 자격증명과 권한을 관리하는 담당자, 에이전트 배포 승인자, 비상 중지 권한자를 지정합니다.

백업 복구 시험에서는 파일 복원뿐 아니라 원문·문서 메타데이터·벡터 인덱스 간 일관성, 권한 연결, 에이전트 설정과 로그가 업무에 필요한 상태로 돌아오는지 확인하고, 필요한 재색인에 걸리는 시간도 측정합니다. 복구가 끝난 뒤 실제 사용자가 검색과 도구 호출을 수행하는 절차도 포함합니다. 이 단계가 있어야 RPO·RTO를 인프라 수치에서 서비스 복구 목표로 연결할 수 있습니다.

자주 묻는 질문

온프레미스 설치만으로 24시간 운영이 해결되나요?

아니요. 온프레미스는 시스템을 배치하는 위치이고, 24시간 운영은 모니터링과 장애 조치의 담당자 및 계약 범위로 정합니다. 플랫폼 공급자, 내부팀, MSP 가운데 누가 경보 확인부터 복구 검증까지 맡는지 나눠 적습니다.

데이터가 국내에 있으면 회사 사내에 저장된 것인가요?

아니요. 국내 위치와 회사 소유 시설은 다른 조건입니다. 회사 정책이 허용한 국내 IDC나 사업자 시설을 사내 데이터로 인정하는지, 원본 외의 백업·로그·관리 정보까지 어떤 위치에 둘 수 있는지 정합니다.

Seahorse Cloud가 24시간 인프라 관제를 제공하나요?

제품 설명은 Seahorse Cloud를 RAG 플랫폼으로 소개하며, 오브젝트 스토리지 관리, 벡터 데이터베이스, 자율 파서와 매니지드 에이전트를 포함합니다. Enterprise 가격 안내는 24/7 전담 엔지니어 지원과 99.95% 업타임 SLA를 제시합니다. 그 지원 범위가 선택한 설치 환경의 서버·네트워크 관제와 실제 장애 조치까지 포함하는지는 해당 계약으로 확인합니다. 지원 시간, 인프라 운영, 유지보수 제외와 서비스 복구 조건을 같은 항목으로 취급하지 않습니다.

백업과 재해복구 계획이 있으면 야간 운영자를 줄일 수 있나요?

복구 절차를 자동화하고 시험하면 복구 작업의 일부를 줄일 수 있지만, 경보 확인과 복구 승인 역할은 따로 지정해야 합니다. 업무별 RTO·RPO, 호출 대상, 복구 승인자와 시험 결과를 기준으로 필요한 야간 대응 인력을 설계합니다.

Seahorse Cloud는 RAG 플랫폼이며, 서버·네트워크 관제와 인프라 장애 조치는 별도 운영 주체와 계약 범위로 정합니다. 데이터 경계와 운영 책임을 확인해 조직에 맞는 구성을 선택하세요.