나무의 SW연구소

[English] 5 Critical Security Layers for Using OpenClaw in Enterprise Environments Introduction Running an autonomous agent like OpenClaw is like handing your car keys to a stranger. It’s efficient, but you need to set boundaries. For those who want to leverage Agentic AI while maintaining a "Zero Trust" posture, here is a detailed technical guide. 1. Hard Isolation via Containerization (Docker) Never let OpenClaw access your host OS directly. By using Docker, you create a "Digital Jail" for the AI. Implementation: Map only a specific, empty directory for OpenClaw to work in. Security Benefit: Even if OpenClaw attempts to delete files or search for .ssh keys, it will only see the limited environment inside the container. It effectively prevents Lateral Movement within your local network. 2. Strategic API Quota & Token Management Unrestricted API access is a financial and security risk. Implementation: In the OpenAI/Anthropic dashboard, create a project-specific ...

[English] Introduction In early 2026, the tech world witnessed a massive paradigm shift with the explosive rise of OpenClaw. As an open-source, autonomous AI agent capable of controlling a computer's mouse, keyboard, and browser, it promised unprecedented productivity. However, this "ultimate personal assistant" has quickly turned into an IT administrator's worst nightmare. Recently, major global tech giants and leading South Korean IT enterprises have issued strict internal mandates: A total ban on OpenClaw in the workplace. But why are companies hitting the brakes on such a revolutionary tool? The answer lies in the terrifying new frontier of cybersecurity: Shadow AI. Here is exactly why top companies are banning OpenClaw and what enterprise IT leaders must do to mitigate these risks. What Makes OpenClaw a Cybersecurity Threat? Unlike traditional generative AI tools (like ChatGPT or Claude) where users simply input text, OpenClaw is an Agentic AI. It doesn't jus...

 ■ 가상화와 컨테이너 1) 컨테이너형 가상화(어플리케이션 격리 기술) [컨테이너]라는 어플리케이션과 실행 환경을 같이 분리하는 방식으로 OS 단위가 아닌 어플리케이션 단위로 가상화하는 기술 2) 컨테이너를 만드는 비용은 저렴하기 때문에 하나의 컨테이너에 여러 어플리케이션을 도입하는 것보다 여러 개의 컨테이너에 하나의 어플리케이션을 도입하여 연계하는 것이 좋다. 3) 컨테이너 가상화 도구 : Docker 4) 쿠버네티스 : 컨테이너 오케스트레이션 도구. 많은 컨테이너를 오케스트레이션(배포 및 관리)할 수 있다. 5) 데브옵스 : 개발자와 운영자가 협력해 서비스를 제공하는 방법 - 개발자 : 계획 > 코드 > 빌드 > 테스트 - 운영자 : 출하 > 배포 > 운영 > 감시 6) 데브옵스를 원활하게 돌리기 위해서 컨테이너 기술이 자주 사용된다. 7) 개발 환경 <> 운영 환경 차이로 인해 오류가 자주 발생하는데, 컨테이너 기술은 이를 해결해 줄 수 있다. 8) 마이크로서비스 : 의존 관계가 없는 여러 작은 서비스를 조합해 큰 서비스로 제공하는 설계 기법 9) 모놀리스 : 하나의 큰 기능을 단일의 서비스로 제공하는 설계 기법 10) 도커 : 컨테이너를 실행하거나 컨테이너 이미지를 만들고 배포하는 플랫폼 11) 컨테이너 이미지 : 컨테이너를 실행하기 위한 템플릿 12) 도커 엔진 : 컨테이너 및 컨테이너 이미지를 관리하는 응용 프로그램. 서버(도커 데몬)-클라이언트(도커 클라이언트) 구조를 가짐 13) 컨테이너 : 운영 체제에서 실행되는 프로세스. 일반 프로세스와 다른 점은 다른 프로세스와 격리되도록 설정되어 있다는 점이다. 14) 컨테이너를 외부와 격리하기 위해 네임스페이스라는 구조를 사용한다. 15) 컨테이너 이미지 : 컨테이너를 실행하기 위한 템플릿 (Java의 클래스 파일과 동일 개념) 16) 컨테이너 상태 : 컨테이너 상태는 도커 명령이 실행되거나 컨테이너 내 프로세스가 종료되는 등으로 변경된다. 17) 도커 ...

□ 구글 애널리틱스 ■ 유니버셔 애널리틱스 → 구글 애널리틱스 4로 변경됨 ■ 퍼포먼스 마케팅/그로스해킹 - 고객획득 → 유입 후 행동 → 서비스 재사용 → 공유 → 수익 → 고객 유지 ■ 고객을 분류하고, 그룹화하여 특징을 정의하고, 그들에게 언제 어떤 메시지를 전달해야 수익이 극대화될 수 있는지 데이터를 통해 결정할 수 있어야 한다. □ Google Marketing Platform (GMP) ■ 마케팅 → 분석 → A/B 테스트 → 분석 → 개선 → 마케팅의 순환 구조 지원하는 마케팅 시스템의 집합체 ■ Google Ads - 2001/10/23 서비스 런칭 ※ 디스플레이 광고, 유튜브 광고, 앱 광고를 할 수 있도록 발전됨. ※ 장점 - 뛰어난 머신러닝 기반의 정교한 타겟팅. 여러 구글 서비스로부터 방대한 사용자 정보 및 데이터 수집 ■ Google Analytics - 2005/11/14 서비스 런칭 ※ 큰 규모의 기능 추가가 될 때마다 이름을 다르게 하여 새로운 버전의 애널리틱스를 출시함. ※ 유니버셜 애널리틱스 (Universal Analytics) - 가장 널리 사용된 버전 ※ Google Analytics 4 - 2020/10 서비스 런칭. 부가 기능으로 있던 앱 + 웹 전용 파트(속성)를 독립적인 버전으로 격상함. 머신러닝이 도입이 핵심. ※ 현재는 Universal Analytics와 Google Analytics 4가 공존하고 있으나, 2023/7/1 이전까지 GA4로 이전해야함. ■ Google Tag Manager - 태그 관리자. 2012/10/01 서비스 런칭 ※ 웹사이트 또는 모바일 앱에서 코드 및 태그라고 통칭되는 관련 코드 조각을 쉽고 빠르게 업데이트할 수 있다. ※ 웹 or 앱 분석, A/B 테스트, 행동 추적, 전환추적 부준에서 GMP의 다른 도구들을 지원한다. ※ 이전에는 모든 것을 개발자가 직접 구현으로 해야했으나, GTM에서는 마케터가 간단한 조작으로 할 수 있도록 한다. ※ 구글 시스템 이외에 여러 제공업체의 태그도...

1. TCP와 IP TCP/IP는 Internet에서 사용되는 protocol이다. 1960년대 미국방성의 연구에서 시작되어 1980년대에 protocol model이 공개되었다. hardware, OS, 매체에 관계없이 동작할 수 있다. 패킷  통신 방식의 인터넷 프로토콜인 IP(Internet Protocol)와 전송 조절 프로토콜인 TCP(Transmission Control Protocol)로 이루어져있다. IP는 패킷 전달 여부를 보증하지 않고, 패킷을 보낸 순서와 받는 순서가 다를 수 있다. TCP는 IP 위에서 동작하는 프로토콜로, 데이터의 전달을 보증하고 보낸 순서대로 받게 해준다. HTTP, FTP, SMTP 등 TCP를 기반으로 한 많은 수의 application protocol들이 IP 위에서 동작하기 때문에 TCP/IP로 부르기도 한다. TCP/IP protocol은 OSI 모형보다 먼저 개발되었다. TCP/IP 프로토콜은 OSI 모형과 정확하게 일치하지는 않지만, OSI 모형을 4계층 혹은 5계층으로 분류하여 적용할 수 있다. 2. 각 Layer별 기능 Layer 1 : 네트워크 연결 계층 (Network Access Layer) - Ethernet, Wi-Fi, Token ring TCP/IP 패킷을 네트워크 매체로 전달하는 것과 네트워크 매체에서 TCP/IP 패킷을 받아들이는 과정을 담당한다. 기본적으로 에러검출 / 패킷의 프레임화를 담당한다. Layer 2 : 인터넷 계층 (Internet Layer) - IP (IPv4, IPv6) 논리적인 주소 IP를 이용한 노드간 전송과 라우팅 기능을 처리하게 된다. 네트워크상 최종 목적지까지 정확하게 연결되도록 연결성을 제공한다. Layer 3 : 전송 계층 (Transport Layer) - TCP, UDP, DCCP, SCTP, IL, RUDP 자료의 송수신을 담당한다. 애플리케이션 계층의 세션과 데이터그램 통신서비스 제공한다. Layer 4 :...

1. OSI 모형 (Open Systems Interconnection Reference Model) 국제표준화기구(ISO)에서 개발한 모델로 컴퓨터 네트워크 프로토콜 디자인과 통신을 계층으로 나누어 설명한 것이다. 이 모형을 이용하면 네트워크상에서 발생하는 문제의 원인이 어디에서 발생하는지 보다 쉽게 유추가 가능하다. 2. 각 Layer별 기능  Layer 1 : 물리 계층 (Physical Layer) 네트워크의 하드웨어 전송을 담당하는 계층으로 시스템의 전기적, 물리적 표현을 나타낸다. 케이블 종류, (802.11 무선 시스템에서와 같은) 무선 주파수 링크는 물론 핀 배치, 전압, 물리 요건 등이 포함된다. 네트워킹 문제가 발생하면 많은 네트워크 전문가가 물리 계층으로 바로 가서 모든 케이블이 제대로 연결돼 있는지, 라우터나 스위치 또는 컴퓨터에서 전원 플러그가 빠지지 않았는지 확인한다. Layer 2 : 데이터 링크 계층 (Data Link Layer) - 이더넷 노드 간 데이터 전송을 제공하며, 물리 계층의 오류 검출 및 수정에 필요한 기능적, 절차적 수단을 제공한다. 여기에는 2개의 부계층(매체 접근 제어(MAC), 논리적 연결 제어(LLC))이 존재한다. 주소값은 물리적으로 할당 받는데, 이는 네트워크 카드가 만들어질 때부터 MAC address가 정해져있다는 의미이다. 데이터 링크 계층의 가장 잘 알려진 예는 이더넷이다. 이 외에도 HDLC나 ADDCCP 같은 P2P(point-to-point) 프로토콜이나 패킷 스위칭 네트워크, LLC, ALOHA 같은 근거리 네트워크용 프로토콜이 있다. Layer 3 : 네트워크 계층 (Network Layer) - 라우터 여러 개의 노드를 거칠 때마다 경로를 찾아주는 역할을 하는 계층으로 라우터 기능의 대부분이 이 계층에 해당한다. 다양한 길이의 데이터를 네트워크들을 통해 전달하고, 그 과정에서 전송 계층이 요구하는 서비스 품질을 제공하기 위한 기능적, 절차적 수단을 ...

1. 아스키 코드(ASCII) American Standard Code for Information Interchange의 약자로, 1960년대 미국 ANSI에서 표준화한 정보교환용 7비트 부호체계이다. 8비트 중에서 7비트만 사용하여 총 128개의 부호를 표기할 수 있다. 나머지 1비트는 통신 에러 검출을 위한 것으로 1의 개수가 홀수이면 1, 짝수이면 0으로 표기하였다. 이를 parity bit라고 한다. 이후 1비트를 더 확장한 ANSI 코드가 나왔으나 이것만으로는 다른 언어를 표현할 수 없었다. 이를 해결하기 위해 국제 표준 코드인 유니코드(Unicode)가 등장하게 되었다. [아스키 코드표] 2. 유니코드(Unicode) 초기 유니코드는 다양한 언어를 지원하기 위해 2바이트(=65536)로 용량을 확장하였다. 그러나 2바이트만으로는 고어(古語), 토속어 등을 담기에는 역부족이었다. 이러한 문제점을 해결하기위해 기본언어판과 보충언어판(BMP + SMP)으로 구성된 유니코드 3.0을 출시하게된다. (2019년 5월 7일 현재, 유니코드 버전 12.1) 유니코드 인코딩은 UTF-8, UTF-16, UTF-32 등이 있으며, 유니코드라 하면 일반적으로 UTF-8이 사용된다. UTF-8로 표현 가능한 길이는 최대 6바이트이나 다른 인코딩과의 호환을 위해 4바이트까지만 사용된다. 1바이트 영역은 아스키 코드와 하위 호환성을 가지며, 아스키 코드의 0~127까지는 UTF-8로 완전히 동일하게 사용된다. 아스키 코드와의 호환은 인터넷에서 가장 많이 사용되는 인코딩이 되는데 큰 이점으로 작용하였다. 유니코드가 쓰이기 전에는 대부분의 인터넷 문서들이 아스키 코드로 작성되었기 때문에 기존 인터넷 문서를 문제없이 호환된다는 것은 큰 장점이었다. UTF-8의 인코딩 규칙은 바이트가 추가될 때마다 1번째 바이트에 '1'로 표기해주는 방식이다. 1개의 바이트가 추가되었다면 '110'을, 2개의 바이트가 추가되었다면 ...