장비는 책상 위에, 지식은 우리 안에: DGX Spark에서 CAP 쓰기

회의까지 10분 남았습니다. 지난달 제안서와 내부 규정, 제품 매뉴얼을 함께 확인해야 하는데 회사 자료를 외부 AI에 올리기는 어렵습니다. 책상 위 DGX Spark에 질문을 던져 보면 어떨까요.

“이 제안서에서 내부 규정과 충돌하는 내용을 찾아줘. 근거 문서와 확인이 필요한 항목도 함께 정리해줘.”

CAP(CLU Agent Platform)을 로컬 모델과 함께 구성하면 이런 업무를 조직 내부에서 시작할 수 있습니다. 문서를 읽고 답을 찾는 일부터 시작합니다. 외부에서 검토한 지식을 들여오고 권한을 부여한 내부 시스템의 반복 업무까지 맡기는 방식입니다.

이 글은 2026년 9월 16일 기준 DGX Spark 운영 구성과 현재 제품 기능을 바탕으로 작성했습니다. 아래 업무 예시는 활용 시나리오이며 성능 측정 결과가 아닙니다.

DGX Spark 한 대에 무엇을 올리나요?

DGX Spark는 NVIDIA GB10과 128GB 통합 메모리를 갖춘 소형 AI 컴퓨터입니다. CPU와 GPU가 메모리를 공유하므로 모델과 문서 처리 서비스가 함께 쓸 자원을 고려해야 합니다. 모델 크기만으로 응답 속도나 동시 사용자 수를 정할 수는 없습니다. NVIDIA 하드웨어 안내

이번에 확인한 장비는 ARM64 기반 DGX Spark입니다. CAP 웹 화면과 백엔드, CLUE 데이터 서비스, 로컬 LLM 서비스가 컨테이너로 구성돼 있습니다. 운영 런타임은 Podman입니다.

각 구성은 다음 역할을 맡습니다.

구성	맡는 일
CAP	사용자가 문서를 등록하고 에이전트와 대화하는 업무 화면
CLUE	문서에서 지식을 만들고 검색하며 세트를 관리하는 데이터 계층
로컬 LLM·임베딩 모델	질문을 이해하고 답변을 작성하며 문서 검색에 쓸 표현을 계산
에이전트 실행 환경	허용한 도구로 작업을 수행하고 결과를 돌려주는 실행 계층

브라우저에서 조직 내부의 CAP 주소에 접속합니다. 여러 사람이 같은 장비를 쓴다면 사용할 모델과 문서량, 동시 작업 수를 실제 질문으로 시험해 적정 범위를 정합니다.

설치 전, 사용할 네트워크부터 정하세요

인터넷에 연결해 설치하는 환경과 처음부터 폐쇄망에 설치하는 환경은 준비물이 다릅니다. 폐쇄망에서는 설치 중 필요한 파일을 즉석에서 내려받을 수 없으므로 운영체제 패키지부터 모델까지 미리 반입해야 합니다.

DGX OS와 GPU 드라이버를 준비하고 nvidia-smi로 GPU가 인식되는지 확인합니다. 설치본에 맞는 NVIDIA Container Toolkit, ARM64 런타임과 이미지도 필요합니다. CAP 라이선스와 설치 주소, 저장 경로, 내부 DNS·TLS 인증서는 담당자와 정합니다.

인터넷 연결이 가능한 준비 구간

인터넷에 연결할 수 있는 준비 구간에서 공식 설치 스크립트를 내려받습니다.

curl -fsSL https://license.aiclude.com/install.sh -o aiclude-install.sh

라이선스 발급처의 장비 등록 안내에 따라 준비한 뒤 CAP을 설치합니다. 예시 값 대신 실제 라이선스 키를 입력합니다.

sudo bash aiclude-install.sh \
  --license-key 'AICL-XXXX-XXXX-XXXX-XXXX' \
  --install-dir /data/aiclude/cap

제품 구성은 라이선스에 따라 결정됩니다. 설치가 끝나면 안내된 CAP 주소에 접속해 관리자 초기 설정을 마칩니다.

처음부터 폐쇄망에 설치할 때

공급받은 오프라인 설치 묶음에 설치 스크립트와 보조 도구, ARM64 이미지, Podman 런타임, GPU 관련 패키지, 로컬 LLM·임베딩 모델, 필요한 문서 처리 모델, 인증서와 오프라인 라이선스 토큰이 포함돼 있는지 확인합니다. 이미지와 설치 파일은 같은 릴리스 구성이어야 합니다.

이미지는 설치 안내에 따라 podman load로 미리 적재합니다. 다음은 이 준비를 마친 뒤 설치를 시작하는 명령 예시입니다. 토큰 하나만으로는 빈 장비에 오프라인 설치를 할 수 없습니다.

sudo bash aiclude-install.sh \
  --offline-license-token '<발급받은 오프라인 토큰>' \
  --podman-tarball /media/approved/podman-linux-arm64.tar.gz \
  --install-dir /data/aiclude/cap

오프라인 라이선스에는 유효기간이 있습니다. 갱신 토큰과 업데이트 파일도 조직의 반입 절차에 맞춰 준비합니다. 온라인 라이선스로 설치한 뒤 네트워크 선만 빼는 방식과는 운영 조건이 다릅니다.

설치한 CAP의 상태 확인

여러 제품이 설치된 장비에서는 CAP의 설치 경로를 명시합니다. 아래 경로는 이 글의 설치 예시와 같습니다.

sudo env AICLUDE_DIR=/data/aiclude/cap aiclude-ctl status
sudo env AICLUDE_DIR=/data/aiclude/cap aiclude-ctl health

서비스를 시작해야 할 때는 같은 경로로 실행합니다.

sudo env AICLUDE_DIR=/data/aiclude/cap aiclude-ctl start

상태가 정상이라면 브라우저 로그인, 문서 등록, 근거를 포함한 답변까지 확인합니다. 서비스가 켜졌다는 표시만으로 문서 기반 AI 사용 준비가 끝나지는 않습니다.

첫 질문은 내 문서에서 시작합니다

처음에는 내부 규정 한 개와 제품 매뉴얼 한 개처럼 답을 직접 확인할 수 있는 자료를 고릅니다. CAP의 지식 화면에서 자료를 등록하고 학습·처리 상태가 완료됐는지 확인합니다. 여기서 학습은 문서를 검색 가능한 지식으로 처리하는 과정입니다. 업로드할 때마다 LLM 자체를 재훈련하는 것은 아닙니다.

에이전트가 사용할 지식 범위와 로컬 모델을 설정한 뒤 이렇게 질문해 보세요.

출장비 정산 규정에서 숙박비 예외 조건을 찾아줘. 근거 문서와 해당 내용을 보여주고, 자료에 없는 조건은 없다고 말해줘.

이어서 실제 업무 자료를 비교해 봅니다.

이 제품 매뉴얼과 고객 요청서를 비교해서 지원 가능한 항목, 추가 확인이 필요한 항목, 근거가 없는 항목으로 정리해줘.

문서를 찾아 답변의 참고 자료로 쓰는 방식을 RAG라고 부릅니다. 검색 결과를 활용하더라도 답변이 틀릴 수 있으므로 출처와 원문을 함께 확인합니다. 적용 시점이 다른 규정이나 개정 전 매뉴얼도 눈여겨볼 부분입니다.

폐쇄망 운영에서는 답변 모델뿐 아니라 임베딩, OCR 등 사용하는 처리 단계도 내부에서 실행돼야 합니다. 외부 API 모델, 웹 검색, 외부 MCP 연결이 남아 있으면 해당 작업에는 인터넷이 필요합니다. 로컬 모델 선택과 네트워크의 외부 통신 차단을 함께 점검하고 실제 차단 상태에서 문서 등록과 질문을 시험합니다. 이 글의 운영 구성 확인은 네트워크를 끊은 실증 시험을 대신하지 않습니다.

외부 지식은 세트로 검토해서 들여옵니다

폐쇄망이라고 해서 지식을 오래된 상태로 둘 필요는 없습니다. 공개 매뉴얼이나 기술 자료를 외부망에서 정리한 뒤 승인된 지식 묶음만 내부로 옮기는 방법이 있습니다. 이때 쓰는 기능이 세트입니다.

장비 유지보수 팀이 제조사의 새 매뉴얼을 반영하는 경우를 예로 들어보겠습니다. 외부망의 CLUE에서 자료를 수집·처리하고 담당자가 출처, 배포 권한, 개정일, 불필요한 개인정보를 검토합니다. 검토한 지식을 세트 파일로 내보내 내부 CAP에 반입합니다.

외부 CLUE에서 준비하고 내부 CAP에서 사용하기

1. 외부망의 CLUE에서 반입할 지식을 준비합니다. 학습이 끝난 뒤 세트의 문서와 내용을 검토합니다.
2. 세트를 다운로드하면서 전송용 비밀번호를 설정합니다. 현재 암호화 세트 파일의 확장자는 .clueset입니다.
3. 파일과 출처·버전 목록을 조직의 승인된 매체나 반입 경로로 옮깁니다. 악성 파일 검사와 승인 기록을 남기고 비밀번호는 별도 경로로 전달합니다.
4. 내부 CAP에서 지식 → 세트 → 세트 로딩을 열어 파일을 선택하고 비밀번호를 입력합니다.
5. 세트 상태가 로딩 완료인지 확인하고 문서 수, 본문, 검색 결과를 점검합니다. 파일 업로드 응답만으로 반입 성공을 판단하지 않습니다.

세트 제작·다운로드는 CLUE가 담당합니다. CAP은 전달받은 세트를 불러와 기존 지식에 합쳐 사용합니다. CAP 화면만으로 외부 지식 세트를 제작하는 흐름은 아닙니다.

현재 세트 파일에는 비밀번호에서 유도한 키로 AES-256-GCM 암호화를 적용합니다. 내부 설치본에 로딩할 때는 대상 설치본의 키로 다시 암호화해 저장합니다. 외부 장비의 저장 암호화 키를 내부 장비와 공유할 필요가 없습니다.

암호화는 파일 내용을 보호하고 변조를 감지합니다. 자료가 정확한지, 악성 지시가 섞였는지, 조직 밖에서 만든 파일을 믿어도 되는지는 별도 검토가 필요합니다. 길고 고유한 비밀번호를 사용하고 파일 해시를 승인 기록과 대조하며 세트 이름에 출처와 기준일을 남겨 두면 이후 교체 판단에도 도움이 됩니다. 이런 반입 검토와 기록은 조직이 운영하는 절차입니다.

반입 전후에는 양쪽의 임베딩 모델과 검색 구성이 호환되는지도 확인합니다. 세트는 지식을 옮기는 파일이며 LLM이나 OCR 모델을 설치하는 묶음은 아닙니다.

답변 다음에는 내부 업무를 맡겨 봅니다

문서에서 정비 절차를 찾았다면 다음 요청은 자연스럽습니다.

어제 접수한 장애 목록을 내부 시스템에서 조회하고, 매뉴얼에 근거한 점검 순서와 작업 요청 초안을 만들어줘.

이처럼 에이전트가 필요한 도구를 골라 단계별로 작업하는 것이 에이전틱 기능입니다. 내부 API나 MCP 서버를 연결해 조회와 처리를 맡길 수 있습니다. MCP는 AI가 외부 도구를 호출하도록 연결하는 규약입니다. 폐쇄망에서는 그 서버도 내부에서 접근 가능해야 합니다.

안전하게 시작하려면 업무 범위와 권한을 작게 잡습니다.

단계	에이전트에 맡길 일	운영자가 정할 경계
조회	재고·장애·문서 검색	읽기 전용 계정, 허용한 내부 주소와 도구
초안	점검 계획·보고서·작업 요청 작성	사람이 근거와 내용을 검토한 뒤 반영
변경	검토된 작업 요청 등록	쓰기 권한 분리, 실행 전 승인, 결과 확인과 이력

CAP의 도구 권한과 승인 설정을 활용하고 내부 시스템에서도 서비스 계정의 권한을 제한합니다. 중요한 쓰기 작업은 연결 도구와 대상 API에서 승인 조건을 강제합니다. 프롬프트에 “승인받고 실행해”라고 적는 것만으로 접근 통제를 대신하지 않습니다. 자격증명은 KeyVault 등 지원되는 보안 설정으로 관리하고 문서나 대화에 붙여 넣지 않습니다.

연결 단계에서는 허용한 조회가 성공하는지, 금지한 변경이 거부되는지 함께 시험합니다. 실행 기록과 대상 시스템의 처리 결과가 일치하는지 확인한 뒤 자동화 범위를 넓힙니다. 컨테이너 격리도 에이전트에 부여한 시스템 권한까지 없애주지는 않습니다.

첫날에는 여기까지 해보세요

회사 규정 두세 개로 출처를 확인하는 질문을 해봅니다. 외부 공개 매뉴얼 하나는 CLUE에서 세트로 만든 뒤 검토해 반입합니다. 마지막으로 내부 시스템의 읽기 전용 조회 도구 하나를 연결해 보고서 초안을 작성해 봅니다.

세 작업이 안정적으로 돌아가면 어떤 문서를 더 넣을지, 어디까지 자동화할지 판단할 근거가 생깁니다. 우리 자료를 놓을 장소, 외부 지식을 받아들이는 절차, 시스템에 일을 맡기는 권한을 직접 정하면서 AI를 업무에 들이는 방식입니다.

DGX Spark 위의 CAP으로 시작해 보세요. CAP 제품 안내에서 기능을 살펴보고 세트 제작 환경은 CLUE 제품 안내에서 확인할 수 있습니다. 폐쇄망 설치 묶음과 라이선스 구성을 문의하려면 도입 문의로 사용할 환경을 알려주세요.