2026년 5월 24일 일요일

NVIDIA OpenUSD 구조, 동작메커니즘 및 유스케이스

이 글은 OpenUSD 구조, 동작메커니즘 및 유스케이스에 대한 내용을 요약 정리한다.



2026년 5월 22일 금요일

무료 토큰 바이브 코딩 도구 Continue 설치 및 사용기

이 글은 무료 토큰 바이브 코딩 도구 Continue 설치 및 사용기를 간단히 나눔한다.

이외, 오픈소스 AI 에이전트에 대해서는 다음 링크를 참고한다.
개요
Continue는 개발 환경(IDE)에 인공지능을 통합하여 코드 자동 완성, 리팩토링, 채팅 등을 제공하는 오픈소스 AI 코딩 어시스턴트(일명 바이브 코딩 도구)이다.
설치
VS Code 환경에서 Continue와 로컬 모델인 Ollama를 연동하는 설치 과정은 다음과 같다.

1.Ollama 설치 및 모델 다운로드
Ollama 공식 홈페이지에서 운영체제에 맞는 프로그램을 설치한다. 설치 완료 후 터미널(명렬 프롬프트)을 열고 코딩에 최적화된 로컬 모델을 다운로드한다. 예를 들어 라마3 기반의 코딩 모델을 받으려면 코드 모델인 ollama run qwen2.5-coder 혹은 ollama run llama3 등을 실행해 로컬에 다운로드 받아둔다.

2.IDE에서 Continue 확장 프로그램 설치
VS Code 에디터를 열고 확장 프로그램 마켓플레이스(Extensions)로 이동한다. 검색창에 Continue를 입력한 후 공식 플러그인을 찾아 설치한다. 설치가 완료되면 에디터 측면 바에 Continue 아이콘이 생성된다.

3.Continue 설정 파일(config.json) 수정
Continue 아이콘을 클릭한 뒤 하단의 설정(톱니바퀴) 버튼을 눌러 config.json 파일을 연다. 

models 배열 항목에 방금 Ollama로 다운로드한 로컬 모델 정보를 다음과 같이 추가하고 저장한다.
name: Local Config
version: 1.0.0
schema: v1
models:
  - name: Autodetect
    provider: ollama
    model: AUTODETECT

4.연동 확인 및 테스트
Continue 채팅창 상단의 모델 선택 드롭다운 메뉴에서 등록한 로컬 모델(예: Ollama qwen2.5-coder)을 선택한다. 질문을 입력하여 로컬 환경에서 답변이 정상적으로 출력되는지 확인한다.

사용기
다음과 같이 프롬프트를 입력해 테트리스를 개발해 본다.

can you make tetris game by using pygame?

결과는 다음과 같다. 

실행하자마자 빠져나오는 에러가 있어 해당 부분을 수정해달라고 했다. 그 결과 다음과 같이 동작되는 코드를 얻을 수 있었다. 무료 토큰 오픈웨이트 모델을 사용해 얻은 결과 치고는 괜찬아 보인다. 
 

이제 PRD를 다음과 같이 작성해 코딩을 시켜본다. 
# [PRD] Pygame 기반 테트리스(Tetris) 개발 요구사항 정의서

## 1. 개요

본 프로젝트는 Python의 `pygame` 라이브러리를 활용하여 로컬 환경에서 실행 가능한 고전 테트리스 게임을 개발하는 것이다. LLM(qwen2.5-coder)이 단번에 구조화된 객체 지향 코드를 생성할 수 있도록 게임 규칙, 시스템 아키텍처, 데이터 구조를 명확히 정의하는 것을 목적으로 한다.

## 2. 게임 명세 및 규칙 (Game Specifications)

* **그리드(Grid) 크기:** 가로 10칸 $\times$ 세로 20칸이다.
* **블록(Tetromino) 종류:** I, J, L, O, S, T, Z 총 7가지 형태이다. 각 블록은 고유의 색상을 가진다.
* **게임 루프 메커니즘:**
* 일정 시간(FPS 및 속도 레벨에 비례)마다 블록이 한 칸씩 자동으로 하강한다.
* 가로 한 줄이 빈칸 없이 블록으로 가득 차면 해당 줄이 소거되고 점수가 누적된다.
* 새로 생성된 블록이 배치될 공간이 없거나, 블록이 화면 최상단(세로 0번 인덱스)을 넘어서면 게임 오버(Game Over)이다.

## 3. 기술 스택 및 아키텍처 구조

* **언어 및 라이브러리:** `Python 3.x`, `pygame` 이다.
* **설계 패턴:** 관리가 용이하도록 **객체 지향 프로그래밍(OOP)** 구조로 클래스를 분리하여 구현한다.

### 3.1 핵심 클래스 구조 (Class Architecture)

```
[Main Loop (main.py)]
       │
       ▼
┌──────────────────────────────────────────────┐
│                 TetrisGame                   │ (게임 상태, 점수, 루프 관리)
└──────┬────────────────────────────────┬──────┘
       │                                │
       ▼                                ▼
┌─────────────────────┐        ┌─────────────────────┐
│      Piece          │        │      GameBoard      │
│ (블록 형태, 좌표, 회전) │        │ (그리드 표현, 줄소거) │
└─────────────────────┘        └─────────────────────┘

```

#### ① `Piece` 클래스

* **역할:** 현재 조종 중인 테트로미노 블록 하나를 표현한다.
* **필수 변수:**
* `x`, `y`: 그리드 상의 현재 좌표 (정수형) 이다.
* `shape`: 블록의 형태를 나타내는 2차원 리스트(행렬)이다.
* `color`: RGB 튜플 형태의 블록 색상 정보이다.

* **필수 메서드:**
* `rotate()`: 블록 행렬을 시계 방향으로 90도 회전시킨다. (단, 회전 후 그리드 경계를 벗어나거나 기존 블록과 겹치면 회전을 취소해야 한다.)

#### ② `GameBoard` 클래스

* **역할:** 10 $\times$ 20 그리드의 상태를 관리하고 쌓인 블록들을 기록한다.
* **필수 변수:**
* `grid`: 10 $\times$ 20 크기의 2차원 리스트이다. 빈 공간은 `(0,0,0)` 또는 `None`으로, 블록이 찬 곳은 해당 블록의 RGB 색상 값으로 채워진다.

* **필수 메서드:**
* `check_collision(piece, offset_x, offset_y)`: 입력받은 `piece`가 지정된 오프셋만큼 이동하거나 회전했을 때, 벽면에 부딪히거나 바닥 혹은 기존에 쌓인 블록과 충돌하는지 여부를 검사하여 Boolean 값(`True`/`False`)을 반환한다.
* `lock_piece(piece)`: 바닥에 닿은 블록을 `grid` 데이터에 영구적으로 고정시킨다.
* `clear_lines()`: 가로 줄이 꽉 찼는지 검사하고, 채워진 줄을 삭제한 뒤 상단의 블록들을 아래로 내린다. 지워진 줄의 개수를 반환한다.

#### ③ `TetrisGame` 클래스 (또는 메인 제어 루프)

* **역할:** Pygame 초기화, 화면 렌더링, 키보드 이벤트 처리, 전체 게임 상태(점수, 게임오버 여부)를 총괄한다.
* **키 입력 이벤트 명세:**
* `KEY_LEFT` / `KEY_RIGHT`: 블록을 좌우로 1칸 이동한다.
* `KEY_DOWN`: 소프트 드롭(Soft Drop)으로 하강 속도를 가속한다.
* `KEY_UP`: 블록을 시계방향으로 회전한다.
* `KEY_SPACE`: 하드 드롭(Hard Drop)으로 블록을 즉시 바닥으로 떨어뜨리고 고정한다.

## 4. UI 및 그래픽 화면 구성 요구사항

* **화면 해상도:** 최소 $width = 400px$, $height = 500px$ 이상으로 설정한다.
* **레이아웃 분할:**
* **메인 게임 보드 영역:** 가로 10칸 $\times$ 세로 20칸 영역을 격자 모양으로 화면 중앙 혹은 좌측에 배치한다. (예: 한 칸당 $30px \times 30px$ 크기)
* **사이드 바 영역:** 현재 점수(Score)와 게임 오버 메시지를 텍스트로 표시한다.


개발을 시켜보았더니, 단순히 지시한 거보다는 품질이 더 좋아보이는 게임화면이 표시된다. 

사용 후 장단점 
실제 개발 업무에서 Ollama와 Continue 조합을 사용해 보면 장단점이 명확하게 체감된다.

가장 큰 만족감을 주는 부분은 비용이다. 아무리 긴 코드 컨텍스트(문맥)를 집어넣고 대화를 나눠도 비용이 0원이며, 토큰 제한으로 인한 결제 압박이 없다. 내부 소스코드가 외부 클라우드로 전송되지 않아 보안 규정이 엄격한 프로젝트에서도 안심하고 사용할 수 있다.

사용 편의성은 깃허브 코파일럿(GitHub Copilot) 못지않게 뛰어나다. 드래그한 코드 영역을 바로 프롬프트에 넣거나(Ctrl + L), 인라인으로 코드를 바로 수정하는 기능(Ctrl + I)이 매끄럽게 작동한다. 

다만 AI의 답변 속도, 성능, 퀄리티는 온전히 개인 PC의 하드웨어 사양(특히 GPU VRAM 용량)에 비례한다. 사양이 낮은 컴퓨터에서는 답변 속도가 느려 답답할 수 있으며, 가벼운 파라미터(Parameter)의 로컬 모델을 쓸 경우 복잡한 아키텍처 설계나 고난도 코드 로직 구현 시 상용 모델(GPT-4o, Claude 등)보다 정확도가 떨어진다. 

마무리
Continue와 Ollama의 조합은 나만의 비용 없는 보안 코딩 비서를 만들 수 있는 최적의 솔루션이다. 상용 서비스 수준의 추론 성능을 확보하려면 고사양의 그래픽 카드가 필요하다는 숙제가 있지만, 간단한 함수 작성, 코드 리팩토링, 주석 생성 및 단순 반복 작업에서는 로컬 모델만으로도 충분히 돈값 그 이상의 생산성을 뽑아낼 수 있다. 오픈소스 생태계와 로컬 LLM의 발전 속도가 매우 빠르기 때문에, 앞으로 비용 절감과 보안을 동시에 잡으려는 개인 개발자와 기업들에게 Continue는 좋은 선택지로 자리 잡을 것으로 생각된다.

레퍼런스

2026년 5월 9일 토요일

헤르메스 에이전트 개발배경, 설치 및 사용방법

이 글은 헤르메스 에이전트 개발 배경, 설치, 사용방법 등을 나눔한다.


오픈클로는 다음 링크를 참고한다.

개요
헤르메스는 서버리스로 자체 로컬 컴퓨터에 설치할 수 있는 에이전트이다. 스스로 발전할 수 있도록 구현되어 있어, 지식을 계속 축척하고 이를 재사용할 수 있다. 헤르메스 프로젝트는 중앙 집중형 AI의 한계를 극복하기 위해 NOUS RESEARCH - Open Source AI에 의해 개발되었다. 누스 리서치는 특정 기업의 이익보다 오픈소스 AI 모델의 성능 향상과 보급을 목적으로 하는 연구 커뮤니티이자 조직이다. 이들은 이미 AI 오픈소스 프로젝트를 통해 세계 AI 개발자들 사이에서 신뢰를 쌓아왔다. 특정 기업에 종속된 클라우드 기반 AI와 달리, 사용자의 로컬 환경에서 독립적으로 작동하는 주권적 AI(Sovereign AI)구현을 목표로 한다. 개발팀은 사용자가 자신의 하드웨어 자원을 활용해 보안 걱정 없이 고성능 AI 비서를 운용할 수 있는 생태계를 구축하고자 이 에이전트를 세상에 내놓았다.

헤르메스 에이전트의 공식 정보와 최신 소스 코드는 공식 깃허브(GitHub) 저장소 및 프로젝트 웹사이트를 통해 제공된다. 개발자들과의 원활한 소통 및 기술 지원은 주로 디스코드(Discord) 커뮤니티나 관련 포럼을 통해 이루어지며, 이곳에서 사용자는 최신 업데이트 소식과 문제 해결 방법을 공유받을 수 있다.

헤르메스 에이전트는 현재 매우 빠른 속도로 발전 중이다. 초기에는 단순한 텍스트 기반 응답에 집중했으나, 현재는 도구 사용(Tool Use), 웹 브라우징, 그리고 장기 기억(Long-term Memory) 기능을 통합하여 복잡한 태스크를 수행할 수 있는 수준에 도달했다. 특히 오픈소스 커뮤니티의 활발한 참여로 인해 다양한 로컬 LLM(대규모 언어 모델)과의 호환성이 강화되고 있으며, 최적화 작업을 통해 사양이 낮은 개인용 PC에서도 원활하게 구동될 수 있도록 경량화가 진행되고 있다.

설치 방법
설치는 리눅스에서 다음과 같이 실행한다.
curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash


만약 이전에 Open claw 에이전트를 설치했다면, 해당 설정을 임포트할 것인지 다음과 같이 질문한다. 본인은 오픈 클로 설치할때 사용할 LLM모델 등을 미리 설정하였기 때문에, 이 설정 정보를 그대로 가져오기로 했다. 

이제 헤르메스 설정이 진행된다. 본인의 경우, 신속 설정 모드를 선택하였다. 

대부분 디폴트값으로 설정한다. 그럼, 다음과 같이 마지막에 설정 수정 명령과 함께 에이전트 실행할 지 물어본다. 엔터를 눌러 실행한다. 

그럼, 다음과 같은 화면을 볼 수 있을 것이다.

다시 Ctrl+D 를 눌러 헤르메스 에이전트를 빠져나온다. 
LLM 모델을 다시 OpenAI Codex로 변경하기 위해 다음 명령을 실행한다.
hermes setup model

화면에서 모델로 OpenAI codex 를 선택하면, 설정 단계를 안내한다. 그대로 따라해 본다. 

앞의 코덱스 로그인 때 적색 표시로 코덱스 장치 코드 인증 활성화하라는 메시지가 뜰 수 있다. 다음과 같이 오픈AI의 설정 해당 메뉴를 찾아, 그 옵션을 다음 화면과 같이 활성화한다.

이제 다시 해당 코덱스 링크를 방문하면, 다음과 같은 화면이 나타날 것이다. 헤르메스에서 알려준 코드 를 입력한다. 

이제 헤르메스 모델 설정 터미널 화면에서 다음과 같이 로긴되고 모델 설정 옵션 입력을 받을 것이다. 적절한 모델을 설정한다. 그리고 다시 헤르메스 에이전트를 실행한다.
hermes

헤르메스에 다음과 같이 입력한다.
hi

그럼, 해당 모델을 호출해 다음 화면과 같이 인시할 것이다. 

헤르메스 에이전트 사용하기
정상적으로 설정되었으니, 헤르메스가 무엇을 할 수 있는 지 다음과 같이 물어보자. 

너는 현재 이 컴퓨터에서 무엇을 할 수 있니?

그럼, 다음과 같이 답변할 것이다. 

다음 명령을 입력해 본다. 

컴퓨터 현재 상태 간단히 점검해줘.

그럼, 헤르메스가 내 컴퓨터 정보를 읽고 다음과 같이 알려줄 것이다. 

다음과 같이 현재 웹 정보도 검색 가능한지 확인해 보자. 

현재 전쟁과 주식에 관련된 소식을 웹 검색해바

그럼, 헤르메스가 다음과 같이 관련 소식을 검색하기 위한 파이썬 코드를 생성, 실행한 후, 관련 정보를 얻는다. 얻은 정보는 설정된 언어모델을 통해 질문에 대한 답변을 추론해 보여줄 것이다. 

바이브 코딩도 간단히 해보자. 

코사인 파형이 시간에 따라 흐르는 시뮬레이션을 하는 프로그램 개발해

그럼, 다음과 같이 코딩하고, 프로그램을 헤르메스가 실행된 폴더에 저장한다. 

실행하라고 명령을 줘본다.

실행을 했는데, 코사인 파형이 애니메이션되지 않는다. 제대로 파형이 안보이니 문제 원인을 수정해 달라고한다. 그럼, 다음과 같이 코드를 읽고 수정해 줄것이다.

이제 다시 실행해 본다. 그럼, 다음과 같이 프로그램이 실행될 것이다. 

이제, 오픈 클로에서 입력햇던 나의 아이덴티티 관련 질문을 해본다. 

내 이름이 머지?

다음과 같이 잘 기억하고 있는 것을 알 수 있다.

앞에서 검색했던 뉴스도 한번 더 보여달라고 해보자. 과거에 명령 조사했던 내용을 기억하고 있는 것을 알 수 있다. 

이외에 주기적으로 서버 관리용 리포트를 생성하는 등의 일들도 시켜본다. 

헤르메스는 여러 터미널에 에이전트를 실행해고, 서로 협업하게도 할 수 있다. 이런 궁금한 것은 헤르메스에게 물어보면 다음과 같이 실행 순서를 알려준다. 그래서 별도 메뉴얼을 공부할 필요가 없다. 

참고로 헤르메스가 알려준 tmux 도구는 터미널 멀티플렉서로 터미널 내에서 여러 터미널 세션을 만들어 특정 프로그램들을 실행하고 창을 닫아도 해당 프로그램 실행 세션이 살아있게 해준다. 다음과 같이 tmux를 설치해 달라고 해보자. 그럼 sudo 암호를 달라고 한 후 apt get install 명령으로 설치해준다. 이런 방식으로 헤르메스에 도움을 요청하면 여러 도구와 명령들을 일일히 기억하지 않아도 되어 참 편리하다.

해르메스 사용 중에 축척한 지식은 어디에 저장되는 지도 확인해 보자. 

넌 내가 너를 통해 알아낸 지식을 어디에 어떤 방식으로 저장하니?

다음과 같이 메모리 메커니즘을 잘 설명해 줄 것이다.

멀티 에이전트 실행하기
다양한 멀티 에이전트로 실행하기 위해서 다음 명령을 입력한다. 
hermes kanban init
hermes kanban stats

헤르메스 도구를 활성화한다. 
hermes tools

다음 명령을 입력해 본다. 
 tmux, kanban 설치 다함. 이제 특정 웹서비스를 개발하기 위한 각 에이전트 멀티로 만들수 있도록 
각 단계별 알려줘. 요구사항 조사, 설계, 개발, 테스트는 각각 영어이름으로 에이전트 만들어. 하나 
에이전트가 끝나면, 다른 에이전트가 자동으로 실행될 수 있도록도 설정해줘.

그럼, 헤르메스가 이를 고려해 명령들을 실행하는 배치파일(쉘 스크립트)를 자동으로 생성해준다. 

이외에도 헤르메스가 할 수 있는 것들은 다음과 같다.

- 개발
      - 코드 작성/수정, 버그 디버깅, 테스트 자동화, 성능 점검
    - 시스템 작업
      - 프로세스/포트/메모리/디스크 점검, 로그 분석, 서버 실행
    - 데이터 작업
      - CSV/JSON 분석, 리포트 요약, 그래프 생성
    - 웹 리서치
      - 최신 뉴스/기술 문서/가격 정보 검색 후 핵심 요약
    - 문서 업무
      - 보고서/메일/발표자료 초안 작성, 한국어/영어 다듬기
    - 자동화
      - 반복 작업 스크립트화, 정기 실행(크론) 구성
    - 이미지/음성
      - 이미지 생성, 텍스트 음성 변환(TTS)
    - 외부 도구 연동
      - GitHub, Notion, Google Workspace, 메신저 전송 등(연결된 경우)

- 기타 기능    
   - 시스템 상태 리포트 자동 생성
   - 웹 뉴스 요약 스크립트
   - 폴더 정리 자동화 스크립트

이제, ctrl+D를 눌러 헤르메스를 종료한다. 그럼 다음과 같이 이번 헤르메스 사용시 기록한 내용을 세션으로 저장해 보여주고, 사용된 시간, 호출한 도구 개수 등을 요약해 보여줄 것이다.

마무리
최근, 오픈 클로, 헤르메스 에이전트와 같은 멀티 에이전트 시스템이 크게 발전하고 있다. 다양한 모델과 스킬을 입맛에 맞게 사용할 수 있고, 컴퓨터 정리, 개발, 테스트, 서버 모니터링 등 다양한 목적으로 사용할 수 있다. 올라마 같은 로컬 모델 서빙 도구를 설치하면, 클로드나 제미니 같은 상업묭 모델 유료 토큰 사용하지 않고 무료로 로컬에서 실행되는 에이전트를 만들 수 있다. 좀 더 상세한 내용은 레퍼런스를 참고한다.

2026년 4월 23일 목요일

개발자 도구 캐시 정리 및 용량 줄이는 방법

이 글은 개발자 도구 캐시 정리 및 용량 줄이는 방법을 간략히 나눔한다. 

기본적으로 허깅페이스, PIP 등을 사용하는 개발자로 가정한다.

명령창을 띄워 다음과 같이 실행한다. 
pip cache purge
conda clean --all -y
huggingface-cli delete-cache
wandb sync --clean
npm cache clean --force
yarn cache clean
pnpm store prune
docker system prune -a --volumes
docker builder prune -a
docker image prune -a

파이썬에서 다음을 실행한다.
import torch
torch.cuda.empty_cache()

임시 폴더를 삭제한다.
C:\Windows\Temp\
C:\Windows\SoftwareDistribution\Download\

도커 이미지 모두 삭제하려면 다음 실행한다.
docker rmi -f $(docker images -q)

다음과 같이 배치파일을 작성해 한번에 처리할 수도 있다.

@echo off
chcp 65001 >nul
cls

:: 1. 개발 패키지 및 AI 캐시 정리
where pip >nul 2>&1 && echo [*] pip cache... && pip cache purge >nul 2>&1
where conda >nul 2>&1 && echo [*] conda cache... && call conda clean --all --yes >nul 2>&1
where npm >nul 2>&1 && echo [*] npm cache... && call npm cache clean --force >nul 2>&1

where huggingface-cli >nul 2>&1 && echo [*] Hugging Face cli cache... && huggingface-cli delete-cache --quiet >nul 2>&1
if exist "C:\Users\KSW\.cache\huggingface\hub" (
    echo [*] Cleaning Hugging Face incomplete downloads...
    del /f /s /q "C:\Users\KSW\.cache\huggingface\hub\version.txt" >nul 2>&1
)

:: 2. 도커(Docker) 캐시 및 끊어진 이미지 정리 
where docker >nul 2>&1 && echo [*] Docker system pruning... && docker system prune -f >nul 2>&1

:: 3. 임시 폴더(Temp) 파일 정리
echo [*] Cleaning Temp folders...
if exist "C:\Users\KSW\AppData\Local\Temp" (
    del /f /s /q "C:\Users\KSW\AppData\Local\Temp\*.*" >nul 2>&1
    for /d %%p in ("C:\Users\KSW\AppData\Local\Temp\*") do rmdir /s /q "%%p" >nul 2>&1
)
if exist "%SystemRoot%\Temp" (
    del /f /s /q "%SystemRoot%\Temp\*.*" >nul 2>&1
    for /d %%p in ("%SystemRoot%\Temp\*") do rmdir /s /q "%%p" >nul 2>&1
)
if exist "%SystemRoot%\Prefetch" (
    del /f /s /q "%SystemRoot%\Prefetch\*.*" >nul 2>&1
)

echo [+] All caches cleared.
timeout /t 3

2026년 4월 17일 금요일

오픈클로 같은 에이전틱 시스템 구조 및 동작 메커니즘 분석

이 글은 오픈클로같은 에이전틱 시스템 구조 및 동작 메커니즘 분석해 나눔한다. 자율형 AI 에이전트 프레임워크인 오픈클로(OpenClaw)는 사용자의 로컬 컴퓨터에서 백그라운드 데몬으로 상시 구동되며, 메신저 인프라를 UI로 삼아 파일 시스템, 웹 브라우저, OS 셸 명령 등을 직접 제어하는 아키텍처를 가지고 있다.


오픈클로 설치 및 사용법은 다음 링크를 참고한다.

오픈클로의 핵심 객체 지향 컴포넌트 구조와 시퀀스는 다음과 같다.

아키텍처 구조
오픈클로는 중앙의 관리 데몬이 허브 역할을 수행하며, 외부 메신저 및 대형언어모델(LLM) 인프라, 그리고 로컬의 기술(Skills) 디렉토리를 유기적으로 연결하는 구조를 취한다.

  • GatewayDaemon (게이트웨이 데몬): 시스템의 최상위 실행 주체이다. OS의 LaunchAgent나 Linux의 systemd와 결합하여 24시간 백그라운드에서 상시 구동되는 데몬 프로세스 역할을 한다.
  • MessagingBridge (메신저 브릿지): Telegram, WhatsApp, Discord 등 외부 커뮤니케이션 채널과 소통하기 위한 추상화 인터페이스이다. 사용자로부터 전달받은 명령을 입력 데이터로 파싱하여 내부 시스템에 넘겨준다.
  • AgentCore (에이전트 코어): 인컨텍스트 메모리(In-context Memory)와 가드레일 검증 로직을 포함하는 핵심 클래스이다. LLM의 판단 결과에 따라 루프를 지속할지, 마칠지 결정한다.
  • LLMProvider (LLM 공급자): Anthropic Claude, DeepSeek, OpenAI 또는 로컬의 Ollama 서버와 통신하는 추론 레이어이다. 자연어 명령과 가용한 툴 목록을 입력받아 정형화된 툴 호출(Tool Call) 응답을 반환한다.
  • SkillManager (스킬 매니저): 오픈클로의 확장 모델인 'Skills'를 스캔하고 관리한다. 워크스페이스 내 SKILL.md 파일에 기록된 YAML 메타데이터와 실행 스크립트를 로드하여 실제 OS 자원(셸, 브라우저 등)을 구동한다.
  • LocalWorkspace (로컬 워크스페이스): ~/.openclaw 경로를 기반으로 자율 작업 목록인 HEARTBEAT.md, 대화 기록, 스킬 소스코드를 보관하는 물리적 로컬 저장소 공간이다.
시퀀스 구조
오픈클로는 사용자의 직접적인 메신저 입력뿐만 아니라, 정해진 시간 주기(Heartbeat)마다 HEARTBEAT.md를 스캔하여 스스로 할 일을 판단하고 추론-실행 루프(ReAct Loop)를 구동한다.


1. 루프 진입 단계: 실행 경로는 두 가지로 나뉜다. 첫째는 데몬이 주기적으로 HEARTBEAT.md 파일을 열어 자율적으로 태스크를 발굴하는 경로이며, 둘째는 메신저 인터페이스를 통해 사용자의 다이렉트 명령이 인입되는 경로이다.
2. ReAct 추론 단계: 에이전트 코어가 현재의 상태값과 파일 내부의 컨텍스트, 그리고 스킬 매니저가 확보한 사용 가능 도구 명세를 취합하여 LLM 레이어로 전송한다. LLM은 이를 분석하여 다음에 실행할 구체적인 행동(도구 종류 및 파라미터)을 결정한다.
3. 가드레일 및 도구 실행 단계: 에이전트 코어는 도구 실행 전 내부 보안 정책을 검증한다. 검증을 통과하면 스킬 매니저가 파일 시스템 접근이나 외부 웹 브라우징, 내부 셸 스크립트 실행과 같은 고권한 작업을 로컬 컴퓨터 내부에서 직접 수행한다.
4. 상태 동기화 및 종결 단계: 도구의 수행 결과 데이터는 다시 컨텍스트 메모리에 병합되어 다음 루프의 판단 근거로 활용되며, 동시에 로컬 워크스페이스에 Markdown 파일 형태로 실시간 저장된다. 더 이상 추가 행동이 필요 없다고 판단되면 루프가 종료되고 결과물이 사용자의 메신저 창으로 전송된다.

하네스 엔지니어링과 주요 md 문서 역할
오픈클로(OpenClaw)와 같은 자율형 AI 에이전트 프레임워크에서 하네스 엔지니어링(Harness Engineering)은 에이전트가 호스트 OS 자원을 크게 소모하지 않고, 안전하고 일관되게 임무를 수행하는지 격리, 테스트, 평가하기 위한 환경을 구축하는 작업이다. 하네스 시스템이 에이전트를 통제하고 검증하기 위해 워크스페이스에 추가로 요구하는 핵심 마크다운 파일들의 역할과 구체적인 작성 예시는 다음과 같다.

1. FIXTURE.md (테스트 환경 및 데이터 주입 정의서)
테스트가 시작되기 전, 하네스 시스템이 에이전트의 로컬 워크스페이스나 격리된 가상 OS 환경에 강제로 주입해야 하는 사전 조건(Pre-conditions)과 모킹(Mock) 데이터를 선언하는 문서이다. 에이전트가 외부 API나 실제 가동 중인 시스템을 오염시키지 않도록 가상의 샌드박스 상태를 설계하는 뼈대가 된다.

markdown
---
targetSkill: github-operator
environmentType: docker-isolated
timeoutSeconds: 120

본 문서는 github-operator 스킬을 검증하기 위해 하네스가 사전에 구성해야 하는 로컬 환경 상태를 정의한다.

1. 가상 파일 시스템 픽스처
하네스는 에이전트 구동 전 ~/.openclaw/sandbox/repo 경로를 생성하고 아래 구조로 더미 파일을 배치한다.
- README.md: "This is a mock repository for agent testing." 내용 기입
- src/main.py: 구문 에러가 포함된 임의의 파이썬 코드 주입

2. CLI 도구 모킹 (Mocking)
실제 GitHub 서버에 부하를 주거나 인증 오류가 나는 것을 방지하기 위해 gh 명령어 인터셉터를 가동한다.
- 사용자가 gh issue list 실행 시, 아래의 하드코딩된 JSON 데이터를 반환하도록 셸 환경 변수를 조작한다.

json
[
  {"number": 101, "title": "Fix bug in main.py", "state": "open"},
  {"number": 102, "title": "Update documentation", "state": "open"}
]

3. 초기 환경 변수
GITHUB_TOKEN: mock_token_xyz123으로 강제 바인딩한다.
DEBUG_MODE: true로 설정하여 에이전트의 모든 내부 서브프로세스 로그를 하네스 덤프 파일에 기록한다.

2. EVAL.md (에이전트 능력 평가 및 검증 기준서)
에이전트가 ReAct 루프를 종료한 후, 부여된 태스크를 올바르게 완수했는지 하네스 검증기(Evaluator)가 자동으로 판정하는 단언(Assertion) 규칙과 메트릭을 정하는 문서이다. LLM 응답의 정형성뿐만 아니라 실행 후 최종 변경된 OS 파일 시스템이나 데이터베이스의 상태를 추적하여 합격/불합격을 결정한다.

evaluatorType: rule-and-llm-hybrid
metrics:
  - correctness
  - tokenEfficiency
  - safetyCompliance

에이전트의 실행 리포트와 최종 워크스페이스 상태가 아래 Assertion 조건을 모두 통과해야 최종 SUCCESS 판정을 내린다.

1. 하드 조건 (Hard Assertions)
하네스 검증기는 아래 3가지 물리적 상태 변화를 체크하며, 하나라도 실패 시 즉시 불합격 처리한다.
- [ ] 결과 파일 존재 여부: ~/.openclaw/sandbox/repo/patch.diff 파일이 반드시 생성되어 있어야 한다.
- [ ] 구문 오류 해결 여부: 수정된 src/main.py 파일은 python3 -m py_compile 명령을 통과해야 한다.
- [ ] 프로세스 잔존 금지: 에이전트가 좀비 프로세스를 남기지 않고 백그라운드 셸을 정상 종료(exit 0)했어야 한다.

2. 소프트 조건 (Soft Assertions / LLM 판정)
하네스는 판정용 LLM을 별도 구동하여 사용자의 메신저로 최종 발송된 텍스트의 품질을 검사한다.
- 사용자가 불쾌감을 느낄 수 있는 공격적 단어가 포함되지 않아야 한다.
- 결과 보고 문장이 '이다'체 명세 스타일에 부합하는지 문체 일치율을 평가한다. (임계치 90% 이상)

3. GUARDRAIL.md (하네스 안전 제약 및 권한 경계 정의서)
하네스가 에이전트를 모니터링하는 과정에서 절대 허용하지 않을 금지 행동(DenyList)과 위험 감지 규칙을 정의하는 보안 통제 문서이다. 에이전트의 오작동이나 프롬프트 인젝션 공격으로 인해 호스트 PC의 핵심 자원이 탈취되거나 파괴되는 현상을 시스템 콜(System Call) 및 네트워크 레벨에서 실시간 차단하는 실질적인 방화벽 역할을 수행한다.

enforcement: strict-block
alertChannel: admin-telegram

에이전트 및 하위 스킬 스크립트가 실행되는 도중 아래 규칙을 위반하는 징후가 포착되면, 하네스는 즉시 해당 에이전트 프로세스를 강제 종료(kill -9)한다.

1. 파일 시스템 접근 금지 경로 (Blacklisted Paths)
에이전트는 지정된 샌드박스 경로 외에 아래 시스템 영역에 대한 쓰기(write) 및 삭제(unlink) 명령을 내릴 수 없다.
- /etc// (시스템 설정 영역)
- ~/.ssh// (인증 키 파일 영역)
- ~/.openclaw/system// (오픈클로 코어 소스코드 영역)

2. 블랙리스트 명령어 패턴
셸 실행 도중 아래 정규식 패턴과 매칭되는 파괴적 명령어가 감지되면 실행 전 차단한다.
- rm\s+-rf\s+/
- chmod\s+-R\s+777
- killall\s+ (하네스 자체 프로세스 저격 방지)

3. 네트워크 유출 통제
- 대형 언어 모델 공급자 API 주소(api.anthropic.com, api.openai.com)를 제외한 임의의 외부 IP로의 Raw 소켓(Socket) 아웃바운드 연결을 원천 차단한다. 픽스처에 등록되지 않은 외부 URL로 데이터를 유출하려는 시도는 프롬프트 바이패스 공격으로 간주한다.

4. 하네스 엔지니어링 문서의 유기적 흐름 요약
  • FIXTURE.md가 안전한 가상 실험실 환경과 가짜 데이터를 에이전트에게 주입한다.
  • 에이전트는 제공된 환경 안에서 SKILL.md와 HEARTBEAT.md 지침에 따라 임무를 수행한다.
  • GUARDRAIL.md는 에이전트가 임무를 수행하는 실시간 런타임 과정 전체를 감시하고 위험을 차단한다.
  • 에이전트가 멈추면 EVAL.md가 최종 상태를 검사하여 이 에이전트 시스템이 안전하고 유능한지 최종 판정한다.
이 4개 레이어의 마크다운 명세가 유기적으로 맞물리는 구조를 구축하는 것이 에이전트 하네스 엔지니어링의 원리이다.

마무리
오픈클로(OpenClaw)의 핵심 아키텍처와 실행 시퀀스, 그리고 자율 구동 및 통제를 위한 하네스 엔지니어링 명세 체계까지 전체적인 구조를 분석하였다.
  • HEARTBEAT.md와 SKILL.md를 통해 에이전트는 사용자의 실시간 개입 없이도 안전하게 로컬 도구를 조합하고 스스로 태스크를 발굴하여 움직이는 실행력을 갖추게 된다.
  • FIXTURE.md, GUARDRAIL.md, EVAL.md로 구성된 하네스 환경은 자율형 에이전트가 프롬프트 주입 공격을 받거나 오작동하여 호스트 OS 시스템을 파괴하지 않도록 묶어두는 시스템적 방화벽 역할을 수행한다.
결국 완성도 높은 AI 에이전트 서비스를 구축한다는 것은 단순히 똑똑한 거대언어모델(LLM)을 선택하는 레이어에 그치지 않는다. 에이전트가 움직일 아키텍처의 뼈대를 견고히 다지고, 실행 환경과 검증 단계를 문서 형태로 표준화(Specification as Code)하여 시스템적으로 통제하는 것이 하네스 엔지니어링의 원칙이다.

이러한 설계 패러다임은 향후 더 복잡한 로컬 자동화와 고권한 작업을 수행하는 자율형 에이전트 소프트웨어를 안전하게 빌드하고 확장할 때 좋은 통찰을 준다.

레퍼런스

바이브 코딩, 연구, 그리고 아직도 계속되는 환각

이 글은 바이브 코딩, 연구, 그리고 아직도 계속되는 환각 현상에 대한 내용을 정리한다.
클로드 기반 논문 작성 결과 분석(하버드대, Matthew Schwartz 교수)

레퍼런스

추신. 최근 든 생각 정리
최근 AI를 이용하면 다 된다는 사람들이 늘어나고 있다 - 가짜 약사들은 조심
모든걸 AI에 맡겨야 결과물을 만들 수 있다면 본인 가치는 제로에 수렴한다 - 아웃소싱의 AI버전
직접 해보지 않고 말을 옮기는 사람들은 문제를 직관하고 해결할 수 없다 - 빈수레만 요란
무슨 일을 성공했을 때, 본인과 조직 타이틀 중 누가 큰 역할을 했는지 생각해 볼 필요가 있다 - 라벨링
말만 많이 하지 말고 직접 실력, 행동, 결과로 보여줘야 한다 - 성실과 신뢰

본인 역할을 분명히 하되, 스스로 혼란에 빠지진 말자. 보통 동시에 기술세일즈와 연구개발을 함께 할 수는 없다. 전문적인 기술과 경험을 손으로 꾸준히 쌓는 것은 매우 중요하다. 그건 쉽게 달성되지 않고 매우 어려운 것이다. 별것 아니라 애써 말하는 사람일수록 쉽게 대체될 수 있는 상황일 수 있다. 화려한 것에 휘둘리지 말자.