내부망 LLM 기반 Internal AI Agent Platform (OpenClaw + MCP) 구축

목표 정의: “완전하게 활용”의 범위부터 딱 잡기

내부 LLM + OpenClaw를 제대로 쓰려면, 목표를 아래 4개로 분해해 설계하는 게 안정적입니다.

모델 계층: 내부망에서 LLM 추론(서빙) 제공
에이전트 계층(OpenClaw): 대화/업무흐름/툴 호출/멀티에이전트 라우팅
툴 계층(MCP 서버들): 사내 시스템(티켓/CMDB/로그/DB/웹자동화/파일) 기능을 표준 인터페이스로 제공
운영·보안 계층: 권한/감사/네트워크/비밀정보/샌드박스/확장 코드 검증/관측성

권장 아키텍처(레퍼런스)

논리 구성

LLM Inference(내부)
- 선택지 A: Ollama(간편)
- 선택지 B: vLLM/TGI(고성능/대규모)
OpenClaw Gateway/Agent Workspaces
- 워크스페이스(에이전트 단위) + 인증/라우팅/채널(메신저/웹훅) 연결
- CLI로 에이전트 관리 기능 제공
MCP Tool Servers
- 예: Playwright(웹 자동화), Git/CI, 티켓 시스템, 로그 검색(ES), 자산(CMDB), 비밀관리(Vault) 등
- OpenClaw에 MCP를 붙이는 플러그인이 존재(“MCP Streamable HTTP” 기반)
보안/운영 공통
- 프록시/egress 통제, 토큰/시크릿 관리, 실행 샌드박스, 감사 로그, 레이트리밋, 모델/프롬프트 정책

단계별 구축 가이드 (내부 LLM 서빙 구축)

옵션 A) Ollama 기반(가장 빠른 PoC → 운영까지 가능)

Ollama 설치 및 서비스 확인(리눅스 예)
```
ollama --version
sudo systemctl status ollama
```
Ollama를 데몬/서비스로 운영하는 형태는 실무에서 흔히 이 패턴으로 상태를 확인합니다.
내부에서 사용할 모델 선택 & Pull
```
ollama list
ollama pull llama3.1:8b-instruct
# 또는 qwen2.5:7b-instruct 등 업무/툴콜에 가벼운 모델부터
```
OpenClaw + 로컬 LLM 조합에서 “현실적인 로컬 모델 추천” 흐름이 이런 식으로 많이 정리되어 있습니다.
추론 API를 내부 서비스로 제공

핵심은 내부망에서만 접근 가능하게 바인딩/방화벽을 구성하고,
OpenClaw는 이 endpoint를 사용하게 연결합니다.

GLM-5 같은 초대형 모델은 로컬에서 “그대로” 운영이 빡센 경우가 많아, 내부 운영 모델은 작고 빠른 모델(7B~14B급)로 먼저 안정화한 뒤, 필요 업무만 상위 모델로 승격하는 전략이 현실적입니다. (참고: GLM-5는 MoE 계열로 소개됩니다.)

옵션 B) vLLM/TGI 기반(중대형 운영/동시성/지연 최적화)

GPU 다수, 동시 요청 많고, 토큰 처리량이 중요하면 이 쪽이 유리합니다.
사내 표준이 Kubernetes라면 “Inference Deployment”로 올리고,
- Ingress(내부), mTLS, HPA, 캐시/배치, 모니터링까지 함께 붙이는 게 운영 포인트입니다.

OpenClaw 설치/초기 세팅(내부망 배포)

빠른 시작은 공식 가이드를 따라가면 됩니다. (macOS/Linux/Windows 지원)
Onboarding(마법사)로 Gateway/인증/채널/데몬 설치까지 잡는 흐름이 많이 쓰입니다.

예: openclaw onboard --install-daemon 같은 방식으로 데몬(systemd/launchd) 등록까지 진행

멀티 에이전트/워크스페이스 운영

에이전트(업무별) 별로 워크스페이스를 분리하면 권한/툴/프롬프트/로그를 분리 운영하기 쉽습니다.
CLI 예시(에이전트 목록/추가 등)

OpenClaw ↔ 내부 LLM(Ollama 등) 연동

OpenClaw는 “로컬 LLM(Ollama) 연동” 사례가 이미 많이 공유돼 있습니다.

300x250

실전에서는 아래 3가지를 확실히 정해두면 됩니다.

모델 엔드포인트 주소: 내부 DNS/내부 LB로 고정
모델 선택 정책
- “일상 대화/요약” = 경량 모델
- “코드/툴콜/에이전트” = 지시 튜닝(instruct) 모델
- “고난도 분석” = 고급 모델(가능하면 별도 풀)
프롬프트/컨텍스트 정책: 내부정보/개인정보 입력 제한, 마스킹 룰, 로그 저장 정책

“완전 활용”의 핵심: MCP로 사내 도구를 표준화해 붙이기

OpenClaw을 “그냥 챗봇”이 아니라 “업무 자동화 에이전트”로 쓰려면 MCP가 게임체인저입니다.

OpenClaw가 어떤 MCP 서버든 연결해서 툴을 에이전트에게 노출시키는 플러그인이 공개돼 있고,
MCP Streamable HTTP 규격을 구현했다고 명시돼 있습니다.

운영 설계(중요): 안정성/관측성/비용

안정성(HA)

LLM 서빙: 2대 이상 + 내부 LB(헬스체크)
OpenClaw Gateway: systemd/컨테이너로 재기동 보장
MCP 서버: stateless로 두고 스케일아웃

관측성

최소 수집 항목
1. 요청 수/토큰 수/지연시간/에러율(모델별)
2. 툴 호출 성공률/실패 원인(입력 검증 실패 vs 권한 vs 외부 장애)
3. 에이전트별 작업량/리트라이/루프 탐지

보안 관점: “내부 LLM + 에이전트”에서 반드시 막아야 할 것

최근 OpenClaw는 “스킬/확장(마켓플레이스) 공급망” 이슈가 크게 보도됐습니다.

악성 스킬이 민감정보(자격증명/SSH/브라우저 패스워드 등) 탈취를 시도했고
프로젝트가 악성 코드 대응을 위해 VirusTotal 같은 스캐닝 연계를 했다는 보도도 있습니다.

따라서 내부 환경에서 “완전 활용”하려면 아래 통제가 사실상 필수입니다.

스킬/플러그인/확장 코드 통제(공급망)

외부 스킬 마켓/레지스트리 기본 차단
내부 승인된 저장소(사내 Git)에서만 설치(allowlist)
설치 전 정적 분석/서명/리뷰 프로세스
“사용자에게 터미널 커맨드 실행을 유도하는 스킬”은 원칙적으로 금지
- (사고 케이스에서 이 방식이 악용됐다는 보도가 있음)

툴 권한 최소화(에이전트가 OS를 만지는 순간 위험 급상승)

MCP 서버를 만들 때 원칙
1. 읽기 전용부터 시작
2. 쓰기/삭제/배포/권한변경은 “승인 단계(사람)”를 끼워 넣기
3. 파일 시스템 접근은 샌드박스 디렉터리만
4. 네트워크 egress는 목적지 allowlist만

비밀정보(Secrets) 처리

API 키/토큰을 에이전트 워크스페이스에 평문 저장 금지
Vault/KMS 연동 + 단기 토큰 + 최소 권한
프롬프트/로그에서 토큰이 새지 않도록 마스킹

데이터 반출(DLP) 관점

내부 LLM이면 “원칙적으로” 외부 반출이 없지만,
에이전트가 웹 검색/외부 API/클라우드 모델을 붙이는 순간 반출 리스크가 생깁니다.
→ 따라서 “모델/툴/채널”별로 반출 정책을 분리해야 합니다.

감사/추적(누가 무엇을 했나)

에이전트 작업은 “실행 로그”가 곧 감사 증적입니다.
최소로라도 아래는 남겨야 합니다.
1. 사용자/채널/에이전트 ID
2. 호출된 툴 이름 + 입력 파라미터(민감정보 마스킹)
3. 실행 결과(요약) + 실패 사유
4. 사람이 승인한 변경 작업의 승인자/시간

내부 구축 “추천 로드맵”

PoC
- Ollama로 경량 모델 운영
- OpenClaw 설치 + 내부 LLM 연결
- MCP 1개(Playwright 또는 로그검색)만 붙여서 end-to-end 검증
Pilot
- 에이전트 워크스페이스 분리(업무별)
- Secrets/Vault 연동, 감사 로그 정식화
- egress/권한/툴 스키마 고정
Production
- vLLM/TGI 도입(필요 시)
- 툴 승인 워크플로(사람-in-the-loop)
- 스킬 공급망 통제(allowlist, 리뷰, 스캔) 고도화

내부 LLM + OpenClaw 표준 아키텍처 문서 (템플릿)

목적/범위

목적: 내부망에서 LLM 추론(Serving) 을 제공하고, OpenClaw를 통해 업무 자동화(Agent) 및 사내 도구(MCP) 호출을 표준화
범위
- LLM Inference Layer (Ollama/vLLM/TGI 등)
- OpenClaw Gateway/Agent Runtime
- MCP Tool Server Layer (사내 시스템 접근)
- Observability + Security Controls (감사/권한/네트워크/DLP)

레퍼런스 아키텍처(논리)

Client Layer: Web/Slack/CLI/Portal
Agent Layer(OpenClaw)
- Gateway(WS) + Agent Profiles(업무별 워크스페이스)
- Gateway는 기본 loopback(예: ws://127.0.0.1:18789) 중심이며, 외부 바인딩 시 토큰이 필수인 흐름이 문서에 명시됩니다.
Model Layer(Internal LLM Serving)
- 내부 DNS/LB 뒤에 모델 서빙 엔드포인트(예: http://llm-gw.intra:11434)
Tool Layer(MCP)
- “MCP Streamable HTTP” 서버들(로그검색/티켓/웹자동화/CMDB/DB 등)
- OpenClaw ↔ MCP 연결은 Streamable HTTP 전송 규격을 구현한 플러그인 방식으로 가능
Security/Operations Layer
- Secrets(Vault/KMS), mTLS, Egress Allowlist, Audit Log, Rate Limit, Sandbox

네트워크/배치 표준(권장)

Zone 분리
- Z1: 사용자/업무망
- Z2: Agent Zone(OpenClaw + MCP Gateway)
- Z3: Data/Tool Zone(ES/DB/ITSM/CMDB)
- Z4: Model Zone(LLM Serving)
흐름(필수 원칙)
- Client → OpenClaw만 허용(단일 진입점)
- OpenClaw → MCP(허용 목록), OpenClaw → LLM(내부 엔드포인트)
- MCP → 내부 시스템은 툴별 최소권한으로 제한
- 인터넷 Egress는 원칙적으로 차단(필요 시 툴별 프록시/allowlist)

표준 구성요소(선정 가이드)

LLM Serving
- PoC/소규모: Ollama
- 동시성/지연/대규모: vLLM/TGI(권장)
OpenClaw
- Gateway를 systemd/launchd 등으로 상시 구동(상태/헬스 체크 명령 제공)
MCP
- Streamable HTTP 기반(POST/GET, optional streaming)

워크스페이스(에이전트) 표준

업무별로 분리(예: SOC Agent / Infra Agent / ITSM Agent / Report Agent)
각 워크스페이스에 대해
- 허용 MCP 목록(Allowlist)
- 권한 스코프(읽기 전용/승인 필요/금지)
- 데이터 처리 등급(DLP 정책)
- 로깅 레벨/보관기간

표준 SLO/용량 기준(예시)

LLM: P95 응답 5~10s 목표(업무별), 오류율 <1%
MCP: 성공률 99%+, 타임아웃/리트라이 규정
OpenClaw: Gateway 재기동 1분 이내 자동복구

보안 기준서/점검표 (네트워크·권한·감사·확장코드·DLP)

핵심 메시지: “내부 LLM”이어도, 에이전트/확장/툴이 붙는 순간 공격면이 크게 늘어납니다. 특히 OpenClaw는 스킬/확장(ClawHub)에서 악성코드 유포가 보고돼 공급망 통제가 필수입니다.

네트워크 통제 체크리스트

OpenClaw Gateway는 loopback 우선, 외부 바인딩 시 토큰 필수
OpenClaw → LLM/MCP 목적지 Allowlist 적용
MCP → 내부 시스템도 시스템별 allowlist(포트/프로토콜 제한)
인터넷 Egress 기본 차단(필요 시 프록시 + 도메인 allowlist)
mTLS/내부 CA 적용(특히 MCP/LLM API)

권한/인증(Identity & Access) 체크리스트

사용자 인증: SSO(SAML/OIDC) + MFA
에이전트 권한: “사용자 대리권”을 그대로 주지 말고 역할 기반(Agent RBAC) 로 분리
MCP 권한: 각 툴은 최소권한, 가능하면 “읽기 전용부터”
쓰기/삭제/권한변경 작업은 승인 워크플로(사람-in-the-loop) 강제

감사/로깅 체크리스트(필수)

누가(사용자/워크스페이스)
무엇을(모델/프롬프트 정책 ID/툴 이름)
언제(타임스탬프/세션)
어디로(MCP 서버/내부 시스템)
결과(성공/실패/에러코드)
민감정보 마스킹(토큰/키/개인정보)
로그 보관/접근통제(보안팀만, 무결성 보호)

확장코드/스킬(공급망) 통제 체크리스트(최우선)

배경: OpenClaw의 스킬/확장 마켓에서 악성 스킬이 대량 발견/유포되었다는 보도가 다수 존재
정책(권장 “필수”)
1. 외부 레지스트리(ClawHub) 기본 차단
2. 사내 승인 Git 저장소(allowlist)에서만 설치
3. 설치 전
  - 정적분석(SAST) / 의존성 스캔(SCA) / 서명 검증
  - 설치 스크립트/쉘 명령 포함 여부 검사
4. “터미널 명령을 복사해 실행하라”는 형태는 즉시 차단/격리
5. 실행 권한 분리(확장코드는 별도 사용자/컨테이너/샌드박스)
6. 정기 점검: 설치된 확장 인벤토리/해시/버전 추적

DLP/데이터 보호 체크리스트

데이터 등급 분류(예: 공개/사내/민감/극민감)
워크스페이스별 입력 제한
- 극민감(고객 PII, 비밀키, 소스코드 원문, 보안로그 원문)은 금지/마스킹 필수
결과물 반출 통제(다운로드/공유/외부 전송 차단)
프롬프트/컨텍스트 저장 정책(기본 비저장 또는 단기 보관)
모델 학습/튜닝에 내부 데이터 사용 시 별도 승인(데이터 거버넌스)

MCP 서버 설계 가이드 (스키마 규칙·에러 처리·승인 워크플로 패턴)

설계 원칙

목표: 에이전트가 “추측”으로 도구를 때리지 않도록 계약(Contract) 기반으로 설계
MCP 전송: Streamable HTTP는 POST/GET 기반이며 서버가 독립 프로세스로 다중 클라이언트를 처리하는 구조를 설명합니다.

Tool 스키마 규칙(강제)

입력 스키마는 JSON Schema로 고정
필수/옵션을 명확히(필수 누락 시 4xx)
민감 필드는 항상 별도 타입으로 분리(예: secret_ref 형태로 Vault 참조만 허용)
출력은 기계 처리 가능해야 함(텍스트 요약 + 구조화 결과 병행)
모든 툴은 request_id/trace_id를 받아서 로그 상관관계 확보

예시: 로그 검색 툴(읽기 전용)

{
  "name": "es_search",
  "input_schema": {
    "type": "object",
    "required": ["index", "query", "time_range"],
    "properties": {
      "index": {"type": "string"},
      "query": {"type": "string"},
      "time_range": {
        "type": "object",
        "required": ["from", "to"],
        "properties": {
          "from": {"type": "string"},
          "to": {"type": "string"}
        }
      },
      "max_hits": {"type": "integer", "default": 50, "maximum": 200},
      "trace_id": {"type": "string"}
    }
  }
}

에러 처리 표준(강제)

에러는 “사람 읽기”가 아니라 에이전트 재시도/분기가 가능해야 합니다.
권장 에러 구조
- error_code: ENUM (VALIDATION_ERROR, AUTHZ_DENIED, UPSTREAM_TIMEOUT, RATE_LIMIT, INTERNAL_ERROR)
- message: 짧은 설명
- retryable: true/false
- details: 필드 단위 오류/제약 조건

승인 워크플로 패턴(가장 중요)

“쓰기/삭제/권한변경” 계열 툴은 아래 패턴으로만 허용하는 것을 권장합니다.

패턴 A: 2단계 커밋(Prepare → Approve → Execute)

change_prepare: 변경안 생성(영향도/대상/롤백플랜 포함)
change_approve: 승인자 확인(사람이 티켓/버튼으로 승인)
change_execute: 승인 토큰이 있을 때만 실행

패턴 B: 티켓 기반(ITSM) 게이트

에이전트는 “변경 실행”이 아니라 “티켓 생성 + 근거 첨부 + 승인 요청”만 수행
승인 후 실행은 별도 자동화(파이프라인) 또는 제한된 실행자만 수행

보안 기본값(필수)

입력 검증(allowlist) + 출력 마스킹
파일/쉘 실행 금지(필요 시 샌드박스에서만)
네트워크 egress 목적지 제한
레이트리밋/쿼터(워크스페이스별)
감사 로그(요청/응답 요약 + trace_id)

OpenClaw 연동 포인트(현실 팁)

OpenClaw ↔ MCP 연동은 Streamable HTTP 기반 구현 플러그인이 존재하며, 여러 서버를 하나의 인터페이스로 묶는 방식이 소개됩니다.
→ 운영 표준에서는 MCP 서버를 늘리더라도 “서버 등록/툴 디스커버리/권한 정책”이 일관되게 유지되도록 구성하세요.

운영 Runbook (장애 대응, 롤백, 모델 교체, 로그 점검)

운영 구성요소별 “정상 상태” 정의

OpenClaw Gateway: 서비스 running + RPC/health OK (gateway status/health 명령군 존재)
LLM Serving: P95 지연/오류율 기준 만족
MCP: 툴별 성공률, 타임아웃, upstream 상태

장애 대응(Incident) 표준 절차

분류

LLM 장애(지연/Out of memory/모델 로딩 실패)
OpenClaw 장애(Gateway down/토큰 문제/연결 불가)
MCP 장애(업스트림 타임아웃/권한 거부/스키마 변경)

즉시 조치(First Aid)

OpenClaw: gateway status/health 확인 → 재기동(서비스 관리)
LLM: 프로세스 상태/VRAM/RAM 확인 → 모델 교체(경량 모델로 failover)
MCP: upstream 헬스체크 → 리트라이/서킷브레이커

영향 최소화

워크스페이스별 레이트리밋 강화
쓰기 작업 중단(읽기만 허용)
외부 통신 차단(이상 징후 시)

롤백(Rollback) 절차(필수)

변경 단위를 “3종”으로 분리해 롤백 가능하게 운영

모델(가중치/서빙 버전)
OpenClaw 설정(프로필/토큰/워크스페이스 정책)
MCP 서버(툴 스키마/권한/업스트림 연결)

표준 롤백 규칙
- “마지막 정상 버전”을 항상 보관
- 스키마 변경은 버저닝(v1/v2) 으로 병행 운영 후 전환

모델 교체(Upgrade/Swap) 표준

사전 점검

토큰 처리량/지연 측정(부하 테스트)
툴콜/JSON 출력 안정성 확인(업무 모델은 이게 핵심)
프롬프트 정책(금칙어/데이터 마스킹) 호환성

단계적 배포

Canary(일부 워크스페이스만) → 확대
장애 시 즉시 이전 모델로 스위치백

로그 점검(정기)

매일
- Top 에러코드(VALIDATION/AUTHZ/TIMEOUT)
- 툴 실패율 상위 10
- 비정상 반복 호출(루프) 탐지
매주
- 워크스페이스별 사용량/민감 데이터 탐지 결과
- 확장/플러그인 인벤토리 점검(해시/버전/변경 내역)

“확장/스킬” 비상 대응(권장 Runbook)

근거: OpenClaw 스킬/확장에서 악성코드 유포가 보고되어, 설치/실행을 신뢰할 수 없다는 전제가 필요
절차
1. 외부 레지스트리 차단(즉시)
2. 설치된 확장 전체 인벤토리 수집
3. 의심 확장 격리(실행 사용자/권한 차단)
4. EDR/포렌식(비밀키/브라우저 크리덴셜/SSH 키 유출 가능성 조사)
5. “내부 승인 저장소 only” 정책 재확인

728x90

그리드형(광고전용)

저작자표시 비영리 동일조건 (새창열림)

내부망 LLM 기반 Internal AI Agent Platform (OpenClaw + MCP) 구축

내부망 LLM 기반 Internal AI Agent Platform (OpenClaw + MCP) 구축

목표 정의: “완전하게 활용”의 범위부터 딱 잡기

권장 아키텍처(레퍼런스)

논리 구성

단계별 구축 가이드 (내부 LLM 서빙 구축)

옵션 A) Ollama 기반(가장 빠른 PoC → 운영까지 가능)

옵션 B) vLLM/TGI 기반(중대형 운영/동시성/지연 최적화)

OpenClaw 설치/초기 세팅(내부망 배포)

OpenClaw ↔ 내부 LLM(Ollama 등) 연동

“완전 활용”의 핵심: MCP로 사내 도구를 표준화해 붙이기

추천 MCP 서버(사내 활용 상위권)

운영 설계(중요): 안정성/관측성/비용

안정성(HA)

관측성

보안 관점: “내부 LLM + 에이전트”에서 반드시 막아야 할 것

스킬/플러그인/확장 코드 통제(공급망)

툴 권한 최소화(에이전트가 OS를 만지는 순간 위험 급상승)

비밀정보(Secrets) 처리

데이터 반출(DLP) 관점

감사/추적(누가 무엇을 했나)

내부 구축 “추천 로드맵”

내부 LLM + OpenClaw 표준 아키텍처 문서 (템플릿)

목적/범위

레퍼런스 아키텍처(논리)

네트워크/배치 표준(권장)

표준 구성요소(선정 가이드)

워크스페이스(에이전트) 표준

표준 SLO/용량 기준(예시)

보안 기준서/점검표 (네트워크·권한·감사·확장코드·DLP)

네트워크 통제 체크리스트

권한/인증(Identity & Access) 체크리스트

감사/로깅 체크리스트(필수)

확장코드/스킬(공급망) 통제 체크리스트(최우선)

DLP/데이터 보호 체크리스트

MCP 서버 설계 가이드 (스키마 규칙·에러 처리·승인 워크플로 패턴)

설계 원칙

Tool 스키마 규칙(강제)

에러 처리 표준(강제)

승인 워크플로 패턴(가장 중요)

보안 기본값(필수)

OpenClaw 연동 포인트(현실 팁)

운영 Runbook (장애 대응, 롤백, 모델 교체, 로그 점검)

운영 구성요소별 “정상 상태” 정의

장애 대응(Incident) 표준 절차

롤백(Rollback) 절차(필수)

모델 교체(Upgrade/Swap) 표준

로그 점검(정기)

“확장/스킬” 비상 대응(권장 Runbook)

관련글

댓글

티스토리툴바