온프레미스 AI 에이전트 구축 업체, 무엇을 확인하고 고르나

온프레미스 AI 에이전트 구축 업체를 고를 때 확인할 것은 다섯 가지입니다. 모델을 어떤 파일로 들여와 어떻게 바꾸는지, 끊긴 망에 업데이트가 어떻게 들어오는지, 추론 서버 사양을 무엇으로 산정했는지, 장애 때 누가 오는지, 로그가 밖으로 나가지 않는지입니다.

이 다섯 칸은 온프레미스로 가기로 정한 다음에야 생기는 질문입니다. 사내에 둘지 클라우드에 둘지를 가르는 조건은 온프레미스와 클라우드를 가르는 세 가지 조건에서 다뤘고, 여기서는 그 결정이 끝난 회사가 업체 제안서를 받아 든 단계를 전제로 씁니다.

문서 요약을 ChatGPT API에 맡겨 오던 팀에 보안 검토 의견이 붙고, 내부망 설치로 방향이 정해졌다고 해 보죠. 두세 곳에서 제안서가 오면 대개 같은 문장이 들어 있습니다. 「온프레미스 설치 지원」. 이 한 줄은 설치가 가능하다는 사실만 말합니다. 설치한 다음 해에 그 서버가 어떻게 살아 있는지는 말하지 않습니다.

온프레미스 AI 솔루션 업체들을 비교하면 무엇이 달라지나?

기능 목록은 거의 겹치고, 갈리는 자리는 설치 이후입니다. 외부와 끊긴 망 안에서 모델과 패치와 장애와 로그를 누가 어떤 경로로 다루는지가 업체마다 다릅니다. 그래서 비교표의 행을 기능이 아니라 이 다섯 경로로 세워야 제안서 사이의 차이가 보입니다.

클라우드형 서비스를 비교할 때는 이 다섯 가지가 대부분 공급사 안에서 처리됩니다. 모델 교체도 패치도 공급사 서버에서 일어나고, 고객은 결과만 받죠. 내부망에 설치하는 순간 그 일들이 전부 우리 서버실 안으로 들어옵니다. 들어온 일마다 담당자와 절차가 필요해지는데, 제안서의 「지원」이라는 낱말이 그 담당자가 누구인지까지 적어 주지는 않습니다.

업체를 고르는 일반 기준, 예컨대 검증을 열어 주는지나 견적 구조가 보이는지는 AI 에이전트 업체 선정 기준에 정리해 두었습니다.

온프레미스 AI 구축 업체의 제안서를 대입하는 확인 표는 어떻게 생겼나?

항목마다 업체에 그대로 보낼 질문 하나와, 돌아온 답을 판정할 기준 두 개를 붙인 표입니다. 제안서를 옆에 놓고 칸마다 업체 답을 적어 넣은 뒤, 오른쪽 두 열 중 어느 쪽에 가까운지 표시하면 됩니다.

확인 항목	업체에 보낼 질문	좋은 답의 모습	흐린 답의 신호
모델 반입과 교체	우리 망에 들어올 모델 파일의 형식과 라이선스, 다음 모델로 바꿀 때의 절차를 문서로 주실 수 있습니까	파일 형식·라이선스 조건·교체 시 재검증 범위가 모델 이름 단위로 적혀 있다	「최신 모델을 지원합니다」처럼 모델 이름 없이 목록만 있다
업데이트 반입	인터넷이 끊긴 서버에 보안 패치와 새 버전은 어떤 매체로, 몇 주 간격으로, 누가 검증해 들여옵니까	반입 매체·무결성 확인 방법·되돌림 절차가 한 장에 있다	「원격으로 업데이트해 드립니다」 — 끊긴 망이라는 전제와 충돌한다
추론 서버 사양	제시한 GPU 사양은 어떤 모델 크기·정밀도·동시 사용자 수·문서 길이로 계산했습니까	계산 입력값 네 가지와 여유분이 숫자로 나온다	「넉넉한 사양」·「권장 사양」만 있고 입력값이 없다
현장 유지보수 인력	장애가 나면 원격과 방문 중 어느 쪽으로, 누가, 몇 시간 안에 대응합니까	대응 방식별 담당 조직과 연락 경로, 원격 접속 시 인증·기록 방법이 적혀 있다	「24시간 지원」이라는 문구만 있고 사람과 경로가 없다
로그 외부 전송	설치된 제품이 사용량 집계·라이선스 확인·오류 보고로 외부에 연결하는 기능이 있습니까, 끌 수 있습니까	외부 연결 목록과 차단 설정, 차단 뒤에도 동작하는 범위가 나온다	「데이터는 외부로 나가지 않습니다」 한 문장으로 끝난다

마지막 열의 신호가 나왔다고 곧바로 탈락시킬 필요는 없습니다. 흐린 답은 대개 업체가 그 질문을 받아 본 적이 없다는 뜻이고, 서면으로 다시 물으면 답이 채워지는 경우가 많습니다. 두 번 물어도 채워지지 않는 칸이 판정의 재료가 됩니다.

모델 반입과 교체 경로에서는 무엇을 물어야 하나?

파일 형식, 라이선스, 교체 절차 세 가지입니다. 셋 다 모델 이름을 특정해야 답이 나오므로, 업체가 설치할 모델을 이름과 버전으로 먼저 적어 달라고 요청합니다.

파일 형식부터 보겠습니다. 모델 가중치를 저장하는 방식 가운데 pickle 계열은 불러오는 순간 임의의 코드가 실행될 수 있다고 허깅페이스가 보안 문서에서 경고하고 있습니다. 같은 문서는 믿을 수 있는 출처의 파일만 받기, 다른 저장 형식 쓰기 같은 대안을 들며, 그 가운데 하나로 safetensors 형식을 소개합니다.

폐쇄망에 반입하는 파일은 한번 들어오면 외부 점검 도구의 도움을 받기 어려우니, 반입 파일이 어떤 형식인지와 반입 전에 무엇으로 검사하는지를 업체 답으로 받아 두는 편이 안전합니다.

라이선스는 모델마다, 버전마다 따로 읽어야 합니다. 예컨대 메타의 Llama 3.1 커뮤니티 라이선스에는 3.1 버전 출시일을 기준으로 직전 달 월간 활성 사용자가 7억 명을 넘는 서비스는 메타에 별도 라이선스를 요청해야 한다는 조항이 있습니다. 대부분의 기업에는 해당하지 않는 조건이지만, 요점은 조건이 모델 파일마다 붙어 온다는 사실입니다. 모델을 바꾸면 조건도 바뀝니다.

교체 절차는 흐린 답이 가장 자주 나오는 자리입니다. 새 모델이 나오면 업체가 파일을 들여와 올려 주는 것으로 끝나지 않고, 기존 업무 질문에 대한 답의 품질을 다시 확인하는 일이 따라붙습니다. 교체 한 번에 무엇을 재검증하는지, 그 비용이 유지보수 계약 안에 있는지 밖에 있는지를 물어 두세요.

지원 모델 목록을 읽을 때는 두 부류를 나눠 보셔야 합니다. 공급사 서버에 API로 호출해야만 쓸 수 있는 모델과, 가중치 파일을 받아 우리 서버에 직접 올릴 수 있는 모델입니다. 앞의 부류는 목록에 이름이 있어도 외부와 끊긴 망 안에서는 돌지 않습니다.

그러니 업체에 물을 것은 목록의 길이가 아니고, 우리 내부망 구성에서 실제로 돌릴 수 있는 모델이 무엇이며 그중 어느 것을 기본으로 설치하는지입니다. 이 답이 나와야 앞의 파일 형식과 라이선스 질문도 대상이 정해집니다.

내부망에 올릴 모델이 정해지면, 우리 업무 문서와 질문으로 먼저 돌려 본 결과를 요청하세요. 같은 이름의 모델도 크기와 설정에 따라 한국어 문서를 다루는 품질이 다르고, 공급사 API로 쓰던 대형 모델과 사내 서버에 올릴 수 있는 크기의 모델은 답의 결이 달라질 수 있습니다. 평소 자주 받는 질문 스무 개 정도를 골라 두면 후보 간 비교에도 그대로 쓸 수 있습니다.

교체 시점을 누가 정하는지도 적어 두면 좋습니다. 업체가 새 모델을 권할 때 바꾸는지, 우리 쪽 검증을 통과한 뒤에만 바꾸는지, 바꾼 뒤 이전 모델을 얼마 동안 함께 남겨 두는지가 정해져 있어야 교체가 사고가 되지 않습니다.

구축하는 쪽에 서 보면 이 칸이 비는 이유가 보입니다. 지원 모델 목록은 영업 자료에 들어가지만, 교체 절차는 첫 교체가 닥쳐야 만들어지는 문서라서요. 목록의 길이보다 교체 절차 문서의 유무가 설치 두 번째 해의 운영을 더 크게 좌우합니다.

인터넷이 끊긴 서버에 업데이트는 어떻게 들어오나?

누군가 매체에 담아 들고 들어옵니다. 그 매체가 무엇인지, 누가 검사하는지, 문제가 생기면 이전 상태로 어떻게 돌아가는지가 업체 답에 들어 있어야 합니다.

온프레미스 AI 구축에서 업데이트는 모델만의 일이 아닙니다. 운영체제 보안 패치, GPU 드라이버, 추론 엔진, 에이전트 플랫폼 자체의 새 버전이 각자 다른 주기로 나옵니다. 넷을 한 번에 묶어 들여오는지 따로 들여오는지에 따라 반입 횟수와 점검 부담이 크게 달라집니다.

좋은 답에는 보통 세 문서가 딸려 옵니다.

반입 목록: 이번 반입에 들어가는 파일과 버전, 각 파일의 해시값
검증 기록: 반입 전 악성코드 검사와 무결성 확인을 누가 언제 했는지
되돌림 절차: 새 버전에서 문제가 나면 몇 단계로, 몇 시간 안에 이전 버전으로 돌아가는지

되돌림 절차는 제안 단계에서 시연을 요청할 만한 항목입니다. 문서로는 모두 갖춰 둔 것처럼 보여도, 끊긴 망에서 이전 버전 파일을 어디에 보관하는지 물으면 답이 멈추는 경우가 있습니다. 보관 위치가 없으면 되돌림도 없습니다.

정기 반입과 긴급 반입도 따로 물어 두세요. 한 달이나 분기 단위로 묶어 들여오는 정기 반입만 정해 두면, 심각한 취약점이 공개된 주에 다음 반입일까지 기다려야 하는 상황이 생깁니다. 긴급 패치를 며칠 안에 어떤 승인 경로로 들여올 수 있는지가 업체 답에 한 줄이라도 있어야 합니다.

「원격으로 업데이트해 드립니다」라는 답을 받았다면 한 번 더 물어야 합니다. 원격 접속이 가능한 구성이라면 그 경로가 어디서 열리고 누가 여는지가 새 질문이 되고, 이 질문은 뒤의 현장 인력 칸과 로그 칸으로 이어집니다.

추론 서버 사양은 무엇을 근거로 산정해야 하나?

모델 크기, 정밀도, 동시 사용자 수, 한 번에 넣는 문서 길이, 이 네 값입니다. 업체가 제시한 GPU 사양 옆에 이 네 값이 적혀 있지 않다면 그 사양은 검산할 방법이 없습니다.

가장 큰 몫은 모델 가중치가 차지합니다. 허깅페이스 문서가 제시하는 어림 계산으로, bfloat16이나 float16 정밀도에서는 파라미터 X십억 개짜리 모델을 올리는 데 GPU 메모리가 대략 2×X GB 듭니다. 계산 예시로, 80억 파라미터 모델이면 가중치만 약 16GB입니다(공식에 값을 넣은 계산 예시이며 고객사 수치가 아닙니다).

이 값은 출발점일 뿐입니다. 같은 문서는 입력이 길어지면 이전 토큰의 계산 결과를 담아 두는 캐시가 메모리를 따로 차지하며, 긴 입력에서는 그 크기가 가중치의 절반에 이를 수 있다는 예도 보여 줍니다. 사내 매뉴얼 수십 쪽을 통째로 넣는 업무와 짧은 문의에 답하는 업무는 같은 모델이라도 필요한 메모리가 다릅니다.

에이전트가 사내 문서를 찾아 답하는 구성이라면 계산에 들어갈 것이 더 있습니다. 문서를 검색용으로 바꾸는 임베딩 모델, 그 결과를 담아 두는 검색 저장소, 에이전트 플랫폼 자체도 서버 자원을 씁니다. 제안서의 GPU 사양이 답을 만드는 모델 하나만 계산한 값인지, 이 구성 요소까지 포함한 값인지를 확인해 두면 설치 뒤에 모자라는 일을 줄일 수 있습니다.

그래서 업체에 되물을 것은 사양 자체보다 계산 과정입니다.

어떤 모델을 어떤 정밀도로 올리는지(가중치 숫자를 더 적은 비트로 줄여 메모리를 아끼는 양자화를 쓴다면 몇 비트인지)
동시에 몇 명이 질문한다고 가정했는지
한 번의 질문에 문서를 얼마나 길게 붙인다고 가정했는지
사용자가 늘면 증설을 어떤 단위로 하는지

양자화는 메모리를 줄이는 대신 답의 품질이나 속도가 달라질 수 있다고 같은 문서가 적고 있습니다. 업체가 양자화를 전제로 사양을 낮췄다면, 그 설정으로 우리 업무 질문을 돌려 본 결과를 함께 받아 두세요.

장비값을 사용 연수로 나눠 운영비와 합치는 계산은 AI 에이전트 도입비를 3년 TCO로 따져 보는 글의 틀을 그대로 쓸 수 있습니다.

장애가 나면 누가 어떤 경로로 서버에 닿나?

원격이든 방문이든 사람 이름과 경로가 문서로 나와야 합니다. 「24시간 지원」은 시간대를 말할 뿐, 새벽 세 시에 추론 서버가 멈췄을 때 누가 어떤 권한으로 들어오는지는 말하지 않습니다.

방문 대응이라면 담당 조직의 위치와 도착까지 걸리는 시간, 담당자가 휴가일 때 대신 올 사람을 묻습니다. 설치 업체가 수도권에만 인력을 두고 있고 서버실이 지방 공장에 있다면, 계약서의 대응 시간과 실제 도착 시간이 어긋날 수 있습니다.

원격 대응이라면 확인할 것이 하나 더 붙습니다. 2025년 7월 개정되어 10월 31일 시행된 「개인정보의 안전성 확보조치 기준」은 외부에서 개인정보처리시스템에 접속할 때 안전한 인증수단을 적용할 대상을 「정당한 접근권한을 가진 자(정보주체는 제외)」로 넓혔고, 접속기록을 남길 대상도 「개인정보처리시스템에 접속한 자(정보주체는 제외)」로 넓혔습니다.

에이전트가 개인정보를 다루는 시스템과 연결되어 있다면, 업체 엔지니어의 원격 접속도 인증과 기록의 대상으로 설계해야 한다는 뜻으로 읽힙니다. 개정 고시는 내부관리계획 수립처럼 처리자의 준비가 필요한 사항을 발령일로부터 1년 뒤에 시행하도록 따로 두었고, 그 1년도 2026년 7월에 지나 지금은 함께 적용되고 있습니다. 우리 회사에 어느 조항이 언제부터 걸리는지는 사내 법무나 개인정보보호 담당과 확인해 두세요.

업체 사정이 바뀌는 경우도 이 칸에서 함께 봅니다. 담당 인력이 바뀌거나 유지보수 계약이 끝났을 때, 설치 구성 문서와 설정 파일, 반입 이력이 우리 쪽에 남아 있어야 다른 인력이 이어받을 수 있습니다. 설치 완료 시점에 넘겨받을 문서 목록을 제안 단계에서 받아 두세요.

장애의 종류도 나눠서 물어야 합니다. 서버가 멈추거나 GPU가 인식되지 않는 문제는 인프라 엔지니어의 일이고, 에이전트가 엉뚱한 문서를 근거로 답하거나 업무 흐름이 중간에 끊기는 문제는 에이전트 설계를 아는 사람의 일입니다. 제안서의 지원 인력이 두 종류를 모두 포함하는지, 한쪽만 방문하고 다른 쪽은 원격으로만 닿는지를 확인하세요.

이 칸에서 좋은 답은 대응 경로별 표 한 장입니다. 원격 접속 경로와 인증 방식, 접속기록이 남는 위치, 방문 인력의 연락 순서가 한데 적혀 있으면, 보안 감사에서 받을 질문 상당수에 이 표로 답할 수 있습니다.

감사에서 반복되는 점검 항목은 감사 전에 스스로 훑어 둘 온프레미스 점검 순서에 따로 모았습니다.

로그가 밖으로 나가지 않는다는 말은 어떻게 확인하나?

제품이 스스로 외부에 연결하는 기능의 목록을 받아 하나씩 끄고, 끈 상태에서 무엇이 동작하는지 확인합니다. 데이터가 나가지 않는다는 선언보다 외부 연결 목록 쪽이 판정에 쓸 정보가 더 많습니다.

온프레미스 제품에도 바깥을 향한 연결이 숨어 있을 수 있습니다. 사용량을 집계해 공급사로 보내는 기능, 라이선스가 유효한지 주기적으로 확인하는 호출, 오류가 나면 진단 정보를 보내는 보고 기능이 대표적입니다. 이 가운데 오류 보고에는 실패한 질문 원문이 함께 실릴 수 있어서, 업무 문서 조각이 진단 정보에 섞여 나가는 경로가 생깁니다.

에이전트라서 생기는 경로가 하나 더 있습니다. 에이전트는 업무를 처리하면서 도구를 부르는데, 그 도구 가운데 웹 검색이나 외부 서비스 API가 섞여 있으면 질문 내용이 그 호출에 실려 나갈 수 있습니다. 제품의 외부 연결과 별개로, 업무 흐름에 들어간 도구 목록도 같은 기준으로 점검 대상에 올려 두세요.

업체에 받을 답은 세 가지로 좁혀집니다. 외부로 연결하는 기능이 무엇무엇인지, 각각을 설정으로 끌 수 있는지, 모두 끈 상태에서 라이선스 확인과 업데이트가 어떻게 돌아가는지입니다. 셋째 답이 없으면 차단은 서류상으로만 가능한 것일 수 있습니다.

확인 방법까지 약속받으면 더 좋습니다. 설치 뒤 일정 기간 방화벽에서 이 서버의 외부 연결 시도를 기록해 보고, 그 기록을 업체 목록과 맞춰 보는 절차에 업체가 협조하는지 묻는 식입니다. 목록에 없던 연결이 기록에 나타나면 그 자리가 다음 질문이 됩니다.

제안서의 범위에서 비기 쉬운 곳은 어디인가?

업체와 고객 사이의 경계선 위에 놓인 일들입니다. 다섯 칸의 답이 모두 좋아도, 누가 할지 적히지 않은 일이 착수 뒤에 일정을 붙잡습니다.

자주 비는 자리를 넷으로 추리면 다음과 같습니다.

서버 조달: GPU 서버를 업체가 공급하는지, 우리가 사서 업체가 설치만 하는지
망 반입 승인: 장비와 소프트웨어 매체를 들여올 때의 사내 승인과 검사를 어느 쪽이 준비하는지
사내 시스템 접근: 에이전트가 ERP나 문서 저장소를 읽을 계정을 누가 언제 발급하는지
운영 인수인계: 설치가 끝난 뒤 우리 담당자가 받을 교육과 문서의 범위

넷 모두 기술 문제로 보이지 않아 제안서 본문에서 빠지곤 합니다. 특히 사내 시스템 접근 계정은 우리 쪽 보안 담당의 승인이 필요한 일이라, 업체가 아무리 준비되어 있어도 이 계정이 늦으면 설치가 멈춥니다. 제안서를 받으면 이 네 줄에 담당 주체를 적어 넣어 달라고 요청하고, 빈 줄이 남으면 계약 전에 채워 두세요.

제안서 세 통을 표에 넣으면 실제로 어떻게 보이나?

아래는 판정 과정을 보여 주려고 만든 가상 예시입니다. 실제 업체나 고객사의 답이 아닙니다. 세 후보가 모두 「온프레미스 설치 지원」을 적어 보냈고, 다섯 질문을 서면으로 보낸 뒤 돌아온 답을 표에 옮겼다고 가정합니다.

확인 항목	후보 가	후보 나	후보 다
모델 반입과 교체	모델 이름·파일 형식 명시, 교체 절차 문서 있음	지원 모델 목록만 있음	모델 이름 명시, 교체 비용은 별도 협의
업데이트 반입	분기 반입, 되돌림 절차 문서 있음	원격 업데이트 전제	반입 매체·해시 목록 있음, 되돌림은 미기재
추론 서버 사양	입력값 네 가지 제시	권장 사양만 있음	입력값 제시, 검색 구성 요소는 제외
현장 유지보수 인력	원격 우선, 방문은 수도권만	24시간 지원 문구	원격·방문 담당 조직과 연락 순서 있음
로그 외부 전송	외부 연결 두 종류, 둘 다 차단 가능	외부 전송 없음 선언	외부 연결 목록 있음, 오류 보고는 차단 불가

후보 나는 다섯 칸이 모두 오른쪽 열의 신호에 가깝습니다. 재질의를 보내되, 로그 칸이 두 번째에도 선언으로 끝나면 아래 순서표대로 제외를 검토합니다.

후보 가와 다는 흐린 칸의 성격이 다릅니다. 가는 방문 인력의 지역이, 다는 오류 보고 차단 불가와 되돌림 미기재가 남았습니다. 서버실이 지방에 있다면 가의 약점이 커지고, 개인정보가 오가는 업무라면 다의 오류 보고 경로가 먼저 걸립니다. 같은 표라도 우리 회사 조건에 따라 무거운 칸이 달라지므로, 표를 채운 뒤에는 우리 조건 두세 줄을 옆에 적고 판정하세요.

설치 뒤 우리 손으로 확인할 수 없는 칸은 어디인가?

로그 칸입니다. 다른 네 칸은 설치 뒤에 우리가 직접 재 보거나 시험해 볼 방법이 있지만, 제품이 밖으로 무엇을 보내는지는 방화벽 기록을 오래 쌓아 두는 것 말고는 알아낼 수단이 거의 없습니다. 그래서 흐린 답이 여러 칸에 나왔다면 이 칸부터 판정합니다.

기준은 하나입니다. 계약한 뒤에 우리 쪽에서 스스로 확인할 수단이 적은 칸일수록 업체의 말에 기대는 몫이 커지고, 그만큼 계약 전에 문서로 못 박아 두어야 합니다. 거꾸로 우리 손으로 검산하거나 시험할 수 있는 칸은 뒤로 미뤄도 됩니다.

순서	흐린 칸	설치 뒤 우리가 쓸 수 있는 확인 수단	두 번 물어도 흐리면
1	로그 외부 전송	방화벽의 외부 연결 기록뿐이고, 쌓이는 데 시간이 든다	후보에서 제외를 검토
2	현장 유지보수 인력	실제 장애가 나기 전에는 시험할 방법이 없다	대응 경로 문서를 계약 전 조건으로 건다
3	업데이트 반입	시험 설치에서 반입과 되돌림을 한 번 돌려 볼 수 있다	되돌림 시연을 선행 조건으로 건다
4	모델 반입과 교체	라이선스 원문은 직접 읽고, 교체 뒤 품질은 우리 질문으로 다시 돌려 볼 수 있다	교체 절차와 재검증 범위를 계약 부속서로 받는다
5	추론 서버 사양	입력값만 받으면 사내에서 검산할 수 있다	입력값을 받아 직접 계산한다

사양 칸이 마지막에 놓인 것은 틀려도 괜찮아서가 아닙니다. 모델 크기와 정밀도, 사용자 수, 문서 길이 네 값만 손에 쥐면 앞에서 본 어림 계산으로 우리 팀이 직접 맞춰 볼 수 있기 때문입니다. 업체 답이 흐려도 우리가 메울 수 있는 칸이라 판정을 서두를 이유가 적습니다.

모델 칸도 절반은 우리 손에 있습니다. 라이선스 문서는 누구나 읽을 수 있고, 교체한 모델의 답은 평소 질문 스무 개로 다시 확인하면 됩니다. 남는 절반, 곧 누가 언제 파일을 들여와 재검증하는지는 업체만 답할 수 있으니 그 부분만 서면으로 받습니다.

인력 칸이 로그 칸 바로 뒤에 오는 까닭은 확인 시점에 있습니다. 대응 경로가 실제로 작동하는지는 첫 장애가 나는 날에야 드러나고, 그날 문서가 없으면 확인과 대응이 동시에 필요해집니다.

계약서에서 모델 교체와 데이터 반환을 어떤 조항으로 잡는지는 이 표가 다루는 범위 밖입니다. 흐린 칸을 계약 조건으로 넘기기로 했다면, 그 조항의 형태는 법무와 함께 따로 검토하세요.

하마다랩스의 윈디플로라면 이 표의 어느 칸까지 공개되어 있나?

하마다랩스(윈디플로)도 이 표로 판정받는 후보 가운데 하나입니다. 공개 자료로 확인되는 것은 배포 방식과 연동 모델 제공처 목록까지이고, 다섯 칸의 답은 상담에서 문서로 받아 표에 넣으셔야 합니다.

윈디플로 플랫폼 페이지는 클라우드·온프레미스·하이브리드 배포를 안내하고, 연동할 수 있는 모델 제공처 목록에 Hugging Face와 오픈소스 LLM을 올려 두고 있습니다. 이 목록은 연동 가능한 대상을 보여 줄 뿐이고, 온프레미스 설치에서 어떤 모델을 기본으로 올리는지는 표의 「모델 반입과 교체」 칸 질문으로 상담에서 문서로 받는 항목입니다.

하마다랩스 회사소개서는 배포 환경을 SaaS·고객 클라우드·온프레미스·하이브리드 넷으로 나누고, 온프레미스에 내부망 설치와 운영 지원을 포함합니다. 보안과 규모가 중요한 기업을 위한 엔터프라이즈 패키지에서는 온프레미스나 전용 클라우드 설치, 기존 시스템 연동, 전사 운영 지원을 함께 다룹니다.

그 밖의 칸, 곧 반입 파일 형식과 검사 방식, 업데이트 반입 주기, 사양 산정의 입력값, 대응 경로, 외부 연결 목록은 고객 환경에 따라 값이 달라지는 항목이라 공개 자료에 일반값으로 나와 있지 않습니다. 비용도 설치 환경과 반입 조건에 따라 달라져 상담에서 산정합니다.

여러 업체의 답을 받은 뒤에는 어떤 순서로 좁히나?

표의 다섯 질문을 모든 후보에게 같은 날 같은 문면으로 보내는 것에서 시작합니다. 질문이 업체마다 조금씩 다르면 답도 비교되지 않습니다.

답이 모이면 먼저 로그 칸만 봅니다. 여기서 두 번 물어도 목록이 나오지 않는 후보를 먼저 걸러 두면, 나머지 네 칸을 비교할 후보 수가 줄어듭니다. 남은 후보의 사양 칸은 계산 입력값을 모아 한 장에 나란히 적습니다. 같은 모델, 같은 사용자 수를 가정했는데 사양이 크게 다르다면 그 차이가 어디서 왔는지 묻는 것이 다음 회의의 안건이 됩니다.

업데이트 칸과 모델 칸은 시연과 문서로 확인하는 단계라 시간이 더 듭니다. 최종 후보 두 곳 정도로 좁힌 뒤에 되돌림 시연과 교체 절차 문서를 요청하는 편이 양쪽 모두의 수고를 줄입니다.

시험 설치를 한다면 처음부터 인터넷을 끊은 환경에서 해 보기를 권합니다. 외부 연결이 열린 상태에서 끝낸 시험은 설치 과정에 숨은 다운로드나 라이선스 확인 호출을 드러내지 못합니다. 끊긴 환경에서 설치가 막히는 지점이 나오면, 그 지점이 로그 칸과 업데이트 칸의 실제 답입니다.

업체를 정한 뒤에도 이 표는 버리지 않습니다. 다섯 칸에 적힌 업체 답은 제안 단계의 약속이라, 계약서 부속 문서로 옮겨 두면 설치 뒤 첫 반입이나 첫 장애 때 약속과 실제를 맞춰 보는 기준이 됩니다. 제안서의 문장이 계약서로 옮겨지는 과정에서 빠지는 일이 흔하므로, 표를 통째로 부속서에 붙여 달라고 요청하는 편이 간단합니다.

운영 첫해가 끝날 때 같은 표를 다시 채워 보면, 어느 칸의 약속이 지켜졌고 어느 칸이 비어 있는지가 재계약 협의의 출발점으로 남습니다.

상담 전에 우리 쪽에서 챙겨 두면 견적과 일정이 빨라지는 자료는 따로 정리해 곧 공유할 예정입니다. 다른 후보에게 보낸 다섯 질문을 같은 날 같은 문면으로 보안 상담을 통해 저희에게도 보내 주시면, 칸마다 문서로 답해 같은 표에서 견주어 보실 수 있게 하겠습니다.

자주 묻는 질문

온프레미스로 설치하면 외부 AI 모델은 전혀 쓸 수 없나요?

구성에 따라 다릅니다. 모든 처리를 내부망 안에서 끝내는 구성도 있고, 데이터 저장과 전처리는 사내에 두고 일부 업무만 외부 모델을 부르는 하이브리드 구성도 있습니다. 외부 모델을 섞는다면 어떤 업무의 어떤 데이터가 외부 호출에 실리는지를 업무별로 적어 두고, 그 목록을 로그 칸 점검과 함께 관리하세요.

업체가 제시한 GPU 사양이 과해 보이면 어떻게 줄이나요?

계산 입력값 가운데 어느 것이 사양을 끌어올렸는지부터 찾습니다. 동시 사용자 수를 최대치로 잡았는지, 문서 길이를 가장 긴 매뉴얼 기준으로 잡았는지가 흔한 원인입니다. 실제 업무의 최근 사용 패턴으로 가정을 다시 잡으면, 초기 장비를 줄이고 증설 조건을 계약에 남기는 방식으로 조정할 수 있습니다.

폐쇄망 설치 기간은 보통 얼마나 걸리나요?

일정을 좌우하는 것은 설치 작업보다 반입 승인 절차입니다. 장비 반입, 소프트웨어 반입 매체 검사, 방화벽 정책 변경이 사내 승인을 거치는 순서와 기간이 회사마다 달라, 업체 일정표에 이 승인 단계가 따로 표시되어 있는지 확인하는 편이 정확합니다.

설치 뒤에 운영을 내부 인력으로 넘겨받을 수 있나요?

넘겨받을 범위를 정하면 가능합니다. 서버와 운영체제 관리, 모델 교체, 에이전트 업무 흐름 수정은 필요한 역량이 서로 달라서, 어느 층을 내부가 맡고 어느 층을 업체에 남길지 나누어 두어야 인수인계 문서의 범위도 정해집니다.

오픈소스 모델을 쓰면 라이선스 비용이 없는 건가요?

모델 사용료가 없는 경우가 많지만 조건은 붙어 있습니다. 상업적 이용 범위, 출처 표기, 규모에 따른 별도 계약 조건 같은 항목이 모델별 라이선스 문서에 적혀 있으니, 도입 모델과 교체 후보 모델의 라이선스를 버전 단위로 보관해 두세요.

보안 감사에서 온프레미스 AI에 대해 가장 먼저 묻는 것은 무엇인가요?

감사마다 순서는 다르지만, 데이터가 어디로 흘러 어디에 남는지를 설명할 수 있는지가 출발점이 되는 경우가 많습니다. 외부 연결 목록과 접속기록 위치를 담은 대응 경로표가 준비되어 있으면 그 질문에 문서로 답할 수 있습니다.

참고 자료

Hugging Face Hub 문서 「Pickle Scanning」 — pickle 파일을 불러올 때 임의 코드 실행 공격이 가능하다는 경고, 신뢰 출처 파일 사용·다른 저장 형식 등 대안과 그중 하나로 safetensors 소개(2026-10-01 확인): https://huggingface.co/docs/hub/security-pickle
Hugging Face safetensors 문서 — pickle과 달리 텐서를 안전하게 저장하는 형식(2026-10-01 확인): https://huggingface.co/docs/safetensors/index
Hugging Face Transformers 문서 「Optimizing LLMs for Speed and Memory」 — bfloat16/float16에서 X십억 파라미터 모델 가중치 적재에 약 2×X GB, 긴 입력에서 키-값 캐시가 가중치의 절반가량에 이를 수 있는 예, 양자화의 품질·속도 영향(2026-10-01 확인): https://huggingface.co/docs/transformers/llm_tutorial_optimization
Meta 「Llama 3.1 Community License Agreement」(2024-07-23) — 추가 상업 조건: 3.1 버전 출시일 기준 직전 달 월간 활성 사용자 7억 명 초과 시 별도 라이선스 요청(2026-10-01 확인): https://github.com/meta-llama/llama-models/blob/main/models/llama3_1/LICENSE
개인정보보호위원회 고시 「개인정보의 안전성 확보조치 기준」 — 2025-07-21 개정, 2025-10-31 시행(2026-10-01 확인): https://www.law.go.kr/행정규칙/개인정보의안전성확보조치기준
김·장 법률사무소 「개정 ‘개인정보의 안전성 확보조치 기준’ 시행」 — 외부 접속 시 안전한 인증수단 적용 대상과 접속기록 보관 대상의 확대, 내부관리계획 수립 등 준비가 필요한 사항의 발령일로부터 1년 뒤 시행(2026-10-01 확인): https://www.kimchang.com/ko/insights/detail.kc?sch_section=4&idx=33291
윈디플로 플랫폼 페이지 — 클라우드·온프레미스·하이브리드 배포 안내, 연동 모델 제공처 목록(Hugging Face·오픈소스 LLM 포함)(2026-10-01 확인): https://www.hamadalabs.com/platform
하마다랩스 회사소개서(2026년 9월판) — 배포 환경 넷(SaaS·고객 클라우드·온프레미스·하이브리드)과 온프레미스의 내부망 설치·운영 지원, 엔터프라이즈 패키지. 자사 1차 자료

작성자

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