온프레미스와 클라우드를 가르는 세 가지 조건

온프레미스 클라우드 AI 에이전트 배포는 보안 등급의 우열로 갈리지 않습니다. 데이터 소재·운영 인력·확장 시점 세 조건에 우리 회사 값을 넣으면 답이 나오는 판정표와, 조건이 어긋날 때의 우선순위를 정리했습니다.

온프레미스와 클라우드를 가르는 세 가지 조건 hero image

온프레미스와 클라우드를 가르는 세 가지 조건

AI 에이전트를 사내 서버에 둘지 클라우드에 둘지는 보안 등급의 우열로 갈리지 않습니다. 데이터가 어디에 있어야 하는가, 운영을 맡을 사람이 사내에 있는가, 열두 달 뒤의 처리량이 정해져 있는가. 이 세 조건이 답을 정합니다.

보안 검토 회의에서 이 주제가 나오면 어느 쪽이 더 안전하냐는 질문으로 시작합니다. 그런데 그 질문에는 답이 없습니다. 같은 배포 방식이 어떤 회사에서는 통제 수단이 되고 다른 회사에서는 방치된 서버 한 대가 되니까요.

답이 나오는 질문은 형태가 다릅니다. 우리 회사의 어떤 값이 이 결정을 이미 정해 놓았는가입니다.

온프레미스가 더 안전하다는 말은 어디까지 맞나?

데이터가 물리적으로 사내에 있다는 사실까지만 맞습니다. 그 서버의 계정 권한이 부서 단위로 뭉뚱그려져 있고 보안 패치가 밀려 있으면, 위치가 사내라는 것은 안전의 근거가 되지 못하죠.

클라우드도 마찬가지입니다. 사업자가 갖춘 통제와 우리가 설정한 통제는 별개라, 접근 키를 공용 문서에 적어 두면 인증받은 인프라 위에서도 같은 사고가 납니다.

그래서 등급 비교는 판단을 만들지 못합니다. 안전은 배포 위치가 아니라 그 위치에서 누가 무엇을 통제하느냐에서 나오고, 통제 가능 여부는 회사마다 다르니까요.

AI 에이전트에서 「어디에 둔다」는 것은 무엇을 둔다는 뜻인가?

데이터와 모델, 둘입니다. 이 둘이 같은 자리에 있어야 할 이유는 없고, 그래서 선택지도 두 개가 아닙니다.

업무 문서와 거래 기록이 놓이는 자리가 하나 있고, 그 데이터를 읽어 답을 만드는 모델이 도는 자리가 따로 있습니다. 둘을 나눠 보면 실무에서 고르게 되는 구성은 넷으로 정리됩니다. 데이터와 모델 모두 사내, 데이터만 사내이고 모델은 외부, 모두 외부, 그리고 모두 사내이되 운영만 공급사에 맡기는 형태입니다.

넷을 구분해 두면 아래 조건표의 답이 읽힙니다. 온프레미스냐 클라우드냐로만 물으면 가운데 두 구성이 시야에서 사라지는데, 조건이 서로 갈리는 회사의 답은 그 가운데에 있으니까요.

온프레미스 클라우드 AI 에이전트 배포를 가르는 세 조건은 무엇인가?

데이터 소재, 운영 인력, 확장 시점입니다.

셋 다 의견이 아니라 사내 문서나 실측값으로 확인되는 값이라, 회의에서 다투는 대신 찾아오면 됩니다. 각 조건이 무엇을 묻고 어디서 확인되는지는 아래와 같습니다.

조건묻는 것우리 값을 확인하는 자리값이 나오면
데이터 소재사외로 나가면 안 되는 데이터가 있는가개인정보 처리방침·수탁자 현황, 고객사 계약의 반출 조항근거 문서가 있으면 사내, 없으면 외부 가능
운영 인력서버와 모델을 계속 돌볼 사람이 있는가사내 서버 패치 이력의 담당자 이름과 날짜이름·날짜가 나오면 사내, 안 나오면 외부
확장 시점열두 달 뒤 처리량이 정해져 있는가대상 업무의 최근 3개월 처리 건수, 확장 계획의 예산 반영 여부예측되면 사내 유리, 미정이면 외부 유리

세 조건은 이렇게 골랐습니다. 값이 달라지면 배포 방식을 되돌리게 만드는 항목만 세웠고 나머지는 뺐습니다. 데모가 매끄러웠는지, 국내 사업자인지도 결정 순간에는 크게 들리지만, 그 값 때문에 서버 위치를 다시 정하지는 않으니까요.

첫째 조건, 데이터가 사외로 나가면 안 되는 근거가 문서에 있는가?

느낌이 아니라 문서로 확인합니다. 「우리 데이터는 민감해서」는 근거가 아니고, 「이 계약서 제몇 조에 재위탁 금지가 있어서」는 근거입니다.

세 곳을 찾아봅니다. 개인정보 처리방침과 수탁자 현황표, 주요 고객사와 맺은 계약의 데이터 반출·재위탁 조항, 그리고 사내 정보보호 규정의 등급 분류표입니다.

셋 중 어디에도 걸리는 문장이 없으면 데이터 소재 칸을 일단 「외부 가능」으로 두고, 우리 업종에 따로 붙는 규제가 있는지만 한 번 더 봅니다. 금융의 망 분리나 공공 부문의 인증 요건 같은 조건은 사내 문서 세 곳에 나타나지 않으니까요.

법령 층도 이 칸의 값을 정하는 데 관여합니다. 다만 「사내」로 못 박는 방향이 아니라, 문서를 갖추면 「외부 가능」 쪽을 열어 두는 방향입니다.

「개인정보 보호법」 제26조 제1항이 위탁의 조건으로 내건 것은 문서입니다. 그 문서에는 목적 외 처리 금지와 기술적·관리적 보호조치가 들어가고, 이 법의 시행령 제28조 제1항이 열거한 사항은 다섯 가지인데 그중 데이터 소재 칸에 닿는 것을 추리면 재위탁 제한, 관리 현황 점검 등 감독, 손해배상 등 책임 세 항목입니다.

여기서 갈리는 것은 클라우드 사용 여부가 아닙니다. 외부에 맡길 수 있느냐가 아니라, 맡길 때 갖춰야 할 문서를 갖췄느냐가 갈리죠. 위탁 문서를 만들 수 있으면 클라우드는 선택지 안에 남습니다.

온프레미스 구성을 검토하러 고객사에 들어가면 저는 서버실보다 계약서 캐비닛을 먼저 봅니다. 반출 금지 조항을 실제로 갖고 있는 곳은 그 조항이 어느 고객사와의 어느 계약에 있는지까지 짚어 냈고, 온프레미스를 먼저 정해 놓고 근거를 찾던 곳은 그 조항을 끝내 찾지 못하는 경우가 있었습니다. 하마다랩스가 제조·유통 쪽 구성 검토에서 반복해 본 장면입니다.

둘째 조건, 운영을 맡을 사람이 이름으로 나오는가?

직책이 아니라 이름과 날짜로 확인합니다. 지금 쓰는 사내 서버가 있다면, 마지막 보안 패치를 누가 언제 적용했는지 물어보세요. 이름과 날짜가 바로 나오면 운영 인력이 있는 것이고, 서로 쳐다보면 없는 것입니다.

이 조건이 두 번째에 오는 까닭은 온프레미스를 고르는 순간 가용성의 책임자가 우리가 되기 때문입니다. 가용성이라는 말의 뜻은 과학기술정보통신부 고시에 정해져 있습니다. 「클라우드컴퓨팅서비스 품질·성능에 관한 기준」이 이 말을 「장애 없이 정상적으로 운영되는 능력」으로 적어 두었죠. 클라우드에서는 이 능력이 사업자의 약정 항목이지만, 사내 서버에서는 우리 팀의 당직 표가 그 자리를 대신합니다.

이 칸은 세 자리에서 값을 확인합니다.

  • 주기 작업: 운영체제와 라이브러리 보안 패치를 정해진 주기로 적용할 사람이 있는가
  • 새벽 장애: 주말과 야간에 걸린 프로세스를 되살릴 연락 경로가 문서에 있는가
  • 버전 갱신: 모델이나 프레임워크 버전이 올라갈 때 검증하고 반영할 사람이 있는가

세 자리 중 하나만 비어도 온프레미스는 유지되지 않습니다. 도입 첫해에는 잘 돌아가다가 담당자가 부서를 옮긴 뒤 아무도 손대지 않는 서버가 되는 경로가 여기서 생기죠.

인력이 없다는 답이 온프레미스를 지운다는 뜻은 아닙니다. 운영을 공급사에 위탁하는 구성이 남아 있고, 그 경우 확인할 것은 우리 인력이 아니라 위탁 계약의 범위로 옮겨 갑니다.

셋째 조건, 열두 달 뒤의 처리량이 정해져 있는가?

정해져 있다는 말은 숫자가 있다는 뜻입니다. 대상 업무의 최근 3개월 처리 건수를 세고, 확장 계획이 예산 문서에 반영되어 있는지를 확인하면 값이 나옵니다.

처리량이 예측되고 상시로 높으면 온프레미스가 유리해집니다. 하드웨어를 한 번 사서 몇 년에 걸쳐 나눠 쓰는 구조라, 사용량이 일정할수록 단위 비용이 내려가니까요. 반대로 처리량이 몇 배로 뛸지 정해지지 않았다면 클라우드가 유리합니다. 쓰지 않을 용량을 미리 사 두지 않아도 되고, 예측이 빗나가도 손실이 서버 자산으로 남지 않죠.

이 조건은 셋 중 유일하게 나중에 다시 정할 수 있습니다. 처리량이 예상과 달라지면 그때 구성을 바꾸면 되고, 다시 드는 일은 장비를 늘리거나 계약 조건을 다시 잡는 선에서 끝납니다.

배포 방식에 따른 비용 구조를 숫자로 견주려면 하드웨어와 인건비를 몇 년에 걸쳐 나눠 보는 계산이 따라옵니다. 그 계산의 틀은 3년 총소유비용으로 도입 비용을 계산하는 방법에서 따로 다뤘습니다.

세 값을 조합하면 답이 몇 개로 줄어드나?

여덟 가지 조합이 나오는데, 실제 답은 네 종류뿐입니다.

세 칸에 우리 값을 넣고 해당 줄을 찾으면 됩니다.

데이터 반출 금지 근거운영 인력확장 시점
있음있음예측 가능온프레미스
있음있음미정온프레미스 — 초기 용량은 최소로, 증설 조건을 미리
있음없음예측 가능운영 위탁형 온프레미스
있음없음미정하이브리드
없음있음예측 가능클라우드
없음있음미정클라우드
없음없음예측 가능클라우드
없음없음미정클라우드

표의 값은 사내 문서와 법령 층까지를 넣어 읽은 것입니다. 업권 단위로 규제가 붙는 영역이라면 첫 칸을 그 규제로 한 번 더 확인한 뒤 줄을 찾습니다.

표의 아래 절반이 한 답으로 모입니다. 반출 금지 근거가 없으면 나머지 두 조건이 어떤 값이든 답이 바뀌지 않는다는 뜻이죠. 사내에 훌륭한 인프라 팀이 있어도, 데이터에 걸리는 제약이 없다면 그 팀의 시간을 서버 유지에 쓸 이유가 약해집니다.

위쪽 네 줄만 갈라집니다. 그리고 그중 순수한 온프레미스로 가는 줄은 둘뿐이고, 나머지 둘은 운영을 밖에 맡기거나 구성을 쪼개는 쪽으로 갑니다.

이 표의 쓸모는 답을 주는 데 있지 않습니다. 우리가 세 칸 중 어느 칸을 아직 채우지 못하는지 드러나는 데 있죠. 채워지지 않는 칸이 그대로 다음 주에 확인할 목록이 됩니다.

조건이 서로 어긋나면 무엇을 먼저 따르나?

데이터 소재, 운영 인력, 확장 시점 순입니다. 이 순서는 중요도가 아니라 우리 힘으로 바꿀 수 있는 정도의 역순입니다.

데이터 소재는 법령과 고객사 계약이 정한 조건이라 우리 의지로 바꿀 수 없습니다. 운영 인력은 채용이나 위탁으로 바꿀 수 있지만 분기 단위의 시간이 듭니다. 확장 시점은 셋 중 유일하게 나중에 다시 정할 수 있죠.

바꿀 수 없는 것부터 따르는 이유는 되돌림 비용에 있습니다. 확장 시점을 근거로 데이터 조건을 덮은 결정이 되돌아오는 자리는 감사나 고객사 실사이고, 그때는 구성 변경만이 아니라 그동안 처리한 데이터의 이력까지 함께 정리해야 합니다.

반대 방향의 실수도 있습니다. 데이터 조건이 비어 있는데 「그래도 안전하게」라는 이유로 온프레미스를 고르면, 근거 없는 통제 비용을 몇 년간 지불하게 됩니다. 조건이 서지 않는 쪽으로 가는 것도 판단 오류입니다.

세 조건에 순서를 매기고 나면 회의가 짧아집니다. 무엇이 먼저인지 정해져 있으면 각자의 우려를 나열하는 대신 첫 조건의 값을 확인하러 가면 되니까요.

하이브리드는 정확히 어디를 자르는 구성인가?

자르는 자리를 하나 정하는 구성입니다. 데이터 종류로 자를 수도, 처리 단계로 자를 수도, 업무로 자를 수도 있죠. 선을 정하지 않으면 관리 지점만 두 배가 됩니다. 실무에서 쓰이는 절단선은 아래 셋입니다.

  • 데이터 종류로 자르기: 개인정보와 거래 원장은 사내, 공개 문서와 매뉴얼은 외부. 선행 작업으로 데이터 분류표가 있어야 합니다.
  • 처리 단계로 자르기: 원본 저장과 전처리는 사내, 추론은 외부 모델. 데이터 자산을 옮기지 않아도 되는 구성입니다.
  • 업무로 자르기: 인사와 법무는 사내, 마케팅 문서 요약은 외부. 설명하기는 가장 쉽지만 업무 간에 데이터가 오가면 첫째 방식으로 돌아가야 합니다.

처리 단계로 자르는 방식에는 함정이 하나 있습니다. 데이터는 사내에 두기로 해 놓고 질문을 만들 때 원문 조각을 그대로 실어 보내면, 저장 위치만 사내이고 내용은 이미 밖으로 나간 상태가 됩니다. 검색으로 찾은 문단을 통째로 붙여 보내는 구성에서 이 일이 생기죠.

그래서 온프레미스 데이터 보안 구성을 검토할 때 저는 구조도보다 실제 오가는 요청 본문을 먼저 열어 봅니다. 설계도에는 경계선이 분명히 그려져 있는데 요청 본문에는 원문 문단이 그대로 실려 있는 경우가 있었고, 경계가 구조도가 아니라 요청 하나하나에서 지켜진다는 사실이 그 자리에서 드러났습니다. 하마다랩스가 연동 구성을 점검할 때 먼저 보는 자리도 여기입니다.

절단선은 문장으로 적어 두는 편이 안전합니다. 「어떤 데이터가 어느 단계에서 어디로 나가는가」를 한 줄로 쓸 수 없으면 아직 선이 정해지지 않은 것입니다.

참고로 우리가 만드는 구성도 이 세 절단선을 전제로 놓고 설계합니다. 하마다랩스 윈디플로는 클라우드와 온프레미스, 하이브리드 배포를 지원하고 500개가 넘는 외부 시스템 연동을 제공합니다.

클라우드를 골랐다면 계약서에서 무엇을 확인하나?

데이터를 되찾는 경로와 데이터가 놓인 나라입니다. 두 항목은 법에 근거 조항이 있어서 확인의 출발점이 계약서 밖에 있습니다.

근거는 「클라우드컴퓨팅 발전 및 이용자 보호에 관한 법률」입니다. 제27조가 계약이 끝났을 때 이용자 정보를 반환하거나 파기하도록 하고, 사업자가 사업을 종료할 때는 이용자에게 알리고 종료일 전에 반환·파기하도록 정하고 있습니다. 정보가 어느 나라에 있는지 알리는 문제는 같은 법의 별도 조항인 제26조가 다룹니다.

계약서에서 볼 것은 이행 방법입니다. 반환한다는 문장은 있는데 어떤 파일 형식으로 며칠 안에 주는지가 없으면, 계약을 끝낼 때 그 협의를 처음부터 하게 되죠.

이 항목만은 세 조건 표가 답해 주지 못합니다. 지금 맺는 계약에 이 법이 걸리는지 자체가 계약의 형태를 따라가기 때문입니다. 국내 사업자와 직접 맺었는지 해외 서비스를 되파는 형태인지는 표 밖에서 법무와 함께 확인해 둡니다.

공급사 쪽 값을 확인하는 자리도 같은 형식으로 하나 더 있습니다. 계약서가 아니라 인증 문서입니다. ISO/IEC 42001 인증서와 그 적용 범위 문서를 받아 보면, 책임 소재와 변경 관리가 외부 심사를 한 번 거쳤는지가 확인됩니다.

이 표준은 2023년에 나온 인공지능 경영시스템 표준으로, AI를 만들거나 공급하거나 쓰는 조직의 관리 체계를 대상으로 삼습니다. 확인되는 것은 거기까지입니다. 인증서가 구축 실력이나 우리 데이터의 안전까지 말해 주지는 않습니다.

온프레미스로 답이 나왔다면 그 뒤에 무엇이 계속 붙나?

서버 값 말고 계속 나가는 것들입니다. 도입 결재는 하드웨어 견적으로 올라가는데, 실제 부담은 그 뒤에 붙는 항목에서 생깁니다.

  • 갱신: 모델과 프레임워크 버전이 올라갈 때 검증하고 반영하는 일이 우리 일정이 됩니다.
  • 증설: 처리량이 늘면 장비를 주문하고 받는 기간만큼 대응이 늦어집니다.
  • 승계: 담당자가 바뀔 때 넘길 문서가 없으면 구성을 다시 파악하는 시간이 듭니다.

이 항목들이 감사에서 어떤 질문으로 돌아오는지는 보안 감사에서 반복되는 온프레미스 점검 항목에 정리해 두었습니다.

세 칸을 실제로 채우는 순서는 어떻게 되나?

한 주 안에 끝나는 순서가 있습니다. 조합표 여덟 줄 가운데 아래 네 줄은 첫 칸 하나로 답이 확정되고 위 네 줄만 둘째·셋째 칸을 따라 갈라지니, 세 조건을 동시에 조사하지 않고 앞에서부터 확인하면 됩니다.

  1. 개인정보 처리방침과 주요 고객사 계약에서 데이터 반출·재위탁 조항을 찾습니다. 조항 번호까지 적습니다.
  2. 조항이 있으면 사내 서버 패치 이력에서 담당자 이름과 마지막 날짜를 확인합니다.
  3. 두 값이 정해지면 대상 업무의 최근 3개월 처리 건수를 세고 확장 계획의 예산 반영 여부를 봅니다.
  4. 세 칸을 조합표에 넣고, 채워지지 않은 칸이 있으면 그 칸을 다음 확인 항목으로 남깁니다.

배포 방식이 정해지면 그다음에 정할 것은 누가 무엇을 승인하고 무엇을 기록하는가입니다. 그 층의 기본 틀은 중소기업이 세우는 최소한의 AI 거버넌스에서 다뤘습니다.

세 칸 중 하나가 끝내 채워지지 않는다면 그 칸이 상담에서 가장 먼저 볼 자리입니다. 지금 확인한 값을 들고 보안 상담으로 알려 주시면, 우리 조건에서 어느 구성이 서는지 그 자리에서 함께 맞춰 봅니다.

자주 묻는 질문

개인정보를 다루는 업무는 전부 사내 서버에 두어야 하나요?

그렇지는 않습니다. 개인정보 보호법은 외부 위탁 자체를 막지 않고, 문서로 계약하고 정해진 사항을 담도록 정하고 있습니다. 판단이 갈리는 자리는 개인정보 여부가 아니라 위탁에 필요한 문서와 점검 체계를 갖출 수 있느냐입니다. 다만 고객사와의 개별 계약에 반출 금지가 걸려 있다면 그 조항이 법령보다 좁은 조건을 만들 수 있으니 함께 확인하세요.

국내 리전을 선택하면 데이터 소재 조건은 해결되나요?

부분적으로만 해결됩니다. 저장 위치가 국내가 되는 것은 맞지만, 운영과 기술 지원이 어느 나라에서 이뤄지는지와 장애 대응 시 접근 권한이 어디까지 열리는지는 별도 항목입니다. 계약서에서 저장 위치, 처리 위치, 지원 인력의 접근 범위를 나눠 확인하면 같은 질문이 다시 오지 않습니다.

이미 사내 서버가 있는데 그대로 쓰면 되지 않나요?

용도가 다르면 그대로 쓰기 어렵습니다. 기존 업무 시스템용 장비와 모델을 돌리는 장비는 요구되는 성능의 종류가 달라, 같은 서버실에 있다는 것만으로 조건이 충족되지는 않습니다. 다만 장비를 이미 운영해 온 팀이 있다면 둘째 조건은 충족될 가능성이 높고, 그 값이 판단에서는 더 큽니다.

절단선을 정하고 나면 관리할 항목이 무엇이 늘어나나요?

세 가지가 새로 생깁니다. 경계를 넘는 요청에 원문이 실려 나가지 않는지 보는 일, 데이터 분류표를 업무 변경에 맞춰 갱신하는 일, 사내와 외부에서 각각 도는 모델의 버전 일정을 맞추는 일입니다. 셋 다 선을 어디에 그었는지에 따라 내용이 달라집니다.

클라우드로 시작했다가 나중에 사내로 옮길 수 있나요?

옮길 수 있지만 옮기는 비용은 처음에 결정됩니다. 업무 규칙과 학습 데이터를 내려받을 수 있는 형식이 무엇인지, 연동 설정을 이관할 수 있는지가 계약 단계에서 정해지기 때문입니다. 나중에 옮길 가능성이 있다면 반출 형식과 절차를 착수 전에 문서로 받아 두세요.

세 조건 중 두 개가 애매하면 결정을 미뤄야 하나요?

첫 조건이 확정되면 미루지 않아도 됩니다. 반출 금지 근거가 없다는 것이 확인되면 나머지 두 조건과 무관하게 방향이 정해지고, 근거가 있다면 인력 조건을 확인하는 데 하루면 충분합니다. 셋 다 애매한 경우는 대상 업무의 범위가 아직 좁혀지지 않은 신호에 가깝습니다.

참고 자료

  • 「개인정보 보호법」 제26조 제1항 — 위탁 시 문서 계약 의무, 목적 외 처리 금지와 기술적·관리적 보호조치(2026-08-26 확인): https://www.law.go.kr/법령/개인정보보호법
  • 「개인정보 보호법 시행령」 제28조 제1항 — 위탁 문서에 담을 사항 다섯 가지. 본문에 든 것은 그중 재위탁 제한, 관리 현황 점검 등 감독, 손해배상 등 책임 세 항목(2026-08-26 확인): https://www.law.go.kr/법령/개인정보보호법시행령
  • 「클라우드컴퓨팅 발전 및 이용자 보호에 관한 법률」 제27조(이용자 정보의 보호) 제3항·제4항 — 계약 종료 시 이용자 정보 반환·파기, 사업 종료 시 통지 및 종료일 전 반환·파기. 정보 소재 국가 공개는 같은 법 제26조가 규정(2026-08-26 확인): https://www.law.go.kr/법령/클라우드컴퓨팅발전및이용자보호에관한법률
  • 과학기술정보통신부 고시 「클라우드컴퓨팅서비스 품질·성능에 관한 기준」 — 가용성을 「장애 없이 정상적으로 운영되는 능력」으로 정의(2026-08-26 확인): https://www.law.go.kr/행정규칙/클라우드컴퓨팅서비스품질·성능에관한기준
  • ISO/IEC 42001:2023 — 2023년 제정된 인공지능 경영시스템(AIMS) 표준. 인증 심사는 독립 인증기관이 맡습니다(2026-08-25 확인): https://www.iso.org/standard/42001
  • 이득기(하마다랩스 CTO), 온프레미스 배포 요건 검토·연동 구성 점검 단계 관찰 — 자사 1차 자료(2026년 기준, 익명 관찰·건수 미집계). 서술 범위: ① 반출 금지 근거를 계약 조항 단위로 특정하는 곳과 특정하지 못하는 곳의 차이(제조·유통 구성 검토 범위) ② 데이터 저장 위치를 사내로 잡은 구성에서 요청 본문에 원문 문단이 실려 경계가 무너지는 지점 — 특정 고객사 사례가 아닙니다
  • 하마다랩스 윈디플로 플랫폼 소개(클라우드·온프레미스·하이브리드 배포, 500개 이상 외부 시스템 연동): https://www.hamadalabs.com/platform

작성자

이득기 — 하마다랩스 공동 창업자이자 기술총괄(CTO). 발명의 날 대통령 표창을 받은 AI 개발자로, 기존 ERP·CRM을 교체하지 않고 AI 에이전트를 연동하는 구축 방식과 데이터가 외부로 유출되지 않는 온프레미스 보안 아키텍처를 시스템 구조 관점에서 다룹니다. 회사 소개: https://www.hamadalabs.com/