# AI 에이전트를 $7/월 VPS에 배치하고 IRC를 전송 계층으로 사용한 디지털 도어맨 구축

> Clean Markdown view of GeekNews topic #27929. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=27929](https://news.hada.io/topic?id=27929)
- GeekNews Markdown: [https://news.hada.io/topic/27929.md](https://news.hada.io/topic/27929.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-03-28T06:33:49+09:00
- Updated: 2026-03-28T06:33:49+09:00
- Original source: [georgelarson.me](https://georgelarson.me/writing/2026-03-23-nullclaw-doorman/)
- Points: 4
- Comments: 1

## Topic Body

- 개인 포트폴리오 사이트에 **IRC 기반 AI 에이전트**를 연결해, 방문자가 실제 **GitHub 저장소 코드 분석 결과**를 바탕으로 질문에 답변받을 수 있는 구조
- 단순한 이력서 요약형 챗봇이 아니라, **저장소 복제·테스트 계산·코드 검증**을 수행하는 **실행형 에이전트**로 설계
- 시스템은 **공개용 nullclaw**와 **비공개 ironclaw** 두 에이전트로 분리되어, **Tailscale 네트워크**를 통해 안전하게 통신
- **IRC 프로토콜**을 전송 계층으로 채택해 **자가 호스팅·표준화·저비용**을 동시에 달성하고, **Haiku 4.5와 Sonnet 4.6 모델**을 역할별로 분리해 비용을 하루 $2로 제한
- 전체 시스템이 **10MB 미만 바이너리·5MB 미만 메모리**로 동작하며, **보안·비용·투명성**을 모두 확보한 **경량 AI 인프라 사례**로 제시됨

---

### 디지털 도어맨 구축
- **$7/월 VPS**에 **AI 에이전트**를 배치하고, 개인 **IRC 서버**를 전송 계층으로 사용해 **GitHub 저장소**와 연결한 구조
  - 방문자는 포트폴리오 사이트에서 AI에게 질문을 던지고, 실제 코드 기반의 답변을 받을 수 있음
  - 단순한 이력서 요약형 챗봇이 아닌, 코드 분석을 통한 구체적 응답 제공

### "이력서를 물어보는 챗봇"의 한계
- 대부분의 포트폴리오 챗봇은 **이력서 내용을 모델에 주입**해 재구성하는 수준에 머무름
- 이런 방식은 새로운 정보를 제공하지 못하며, 단순한 **형식적 대화**에 불과함
- “테스트 커버리지를 어떻게 관리하나?” 같은 질문에는 **저장소를 복제하고 테스트 수를 계산**하는 식의 구체적 응답이 필요함
- 이를 위해 **직접적인 코드 접근과 분석이 가능한 인프라**를 구축함

### 시스템 아키텍처
- **두 개의 에이전트**, **두 개의 서버**, **두 개의 보안 경계**로 구성
  - **nullclaw**: 공개용 도어맨, 678KB Zig 바이너리, 약 1MB RAM 사용
    - 방문자 인사, 프로젝트 관련 질문 응답, GitHub 저장소 복제 및 코드 기반 검증 수행
  - **ironclaw**: 비공개 백엔드 에이전트, 별도 시스템에서 동작
    - 이메일, 일정, 개인 컨텍스트 접근 가능
    - nullclaw로부터 복잡한 요청을 **#backoffice** IRC 채널을 통해 전달받음
- 두 시스템은 **Tailscale**을 통해 연결되며, 공개 서버는 개인 데이터에 접근 불가

### IRC를 선택한 이유
- **미학적 일관성**: 포트폴리오 사이트가 터미널 UI 기반이므로 IRC 클라이언트가 자연스러움
- **완전한 자가 호스팅**: Ergo IRC 서버, gamja 웹 클라이언트, nullclaw 모두 자체 인프라에서 운영
- **단순하고 표준화된 프로토콜**: 30년 된 IRC는 **벤더 종속성 없음**, API 변경 리스크 없음
- 동일한 에이전트가 웹 클라이언트뿐 아니라 **irssi 터미널 클라이언트**에서도 동일하게 작동

### 모델 선택과 설계
- **대형 모델 사용은 비효율적**이며, 역할에 따라 모델을 구분
  - ### Haiku 4.5**: 대화 및 간단한 질의 처리,** 초저지연 응답
    - **Sonnet 4.6**: 코드 분석 및 복잡한 추론 시에만 사용
    - **비용 상한선**: 하루 $2, 월 $30으로 제한
    - 악의적 사용이나 과도한 대화로 인한 비용 폭주 방지
    - **계층형 추론 구조**를 통해 **속도와 비용 효율성**을 동시에 확보

### 보안 설계
- **SSH**: 루트 로그인 비활성화, 키 인증만 허용, 비표준 포트 사용
- **방화벽**: SSH, IRC(TLS), HTTPS(WebSocket)만 개방
- **Cloudflare 프록시**: TLS 종료, 속도 제한, 봇 필터링 수행
- **에이전트 샌드박스**: 읽기 전용 도구만 허용, 시간당 10회 액션 제한
- **비용 제어**: 하루 $2, 월 $30 하드캡
- **감사 로그 및 자동 업데이트** 활성화
- **공격면 최소화**: ergo와 nullclaw 두 서비스만 실행, 웹 콘텐츠 직접 제공 없음
- 침해 발생 시 피해 범위는 **$2/일 한도의 IRC 봇**으로 제한됨

### 통신 스택 구성
- 모든 구성요소는 **소형·자가 호스팅·교체 가능** 형태
  - **Ergo**: IRC 서버, 단일 Go 바이너리, 2.7MB RAM
  - **gamja**: 웹 IRC 클라이언트, 152KB 정적 페이지, Cloudflare 뒤에서 서비스
  - **nullclaw**: AI 에이전트 런타임, 4MB Zig 바이너리, 약 1MB 메모리 사용
- 전체 시스템은 **10MB 미만의 바이너리**, **5MB 미만의 유휴 메모리**로 동작
- **가장 저렴한 VPS 티어**에서도 충분히 운영 가능

### nully(공개 에이전트)의 실제 기능
- **프로그래밍 언어 파악**: 사전 로드된 컨텍스트와 저장소 검증을 통해 확인
- **테스트 구조 분석**: 저장소 복제 후 테스트 파일을 직접 읽어 결과 보고
- **프로젝트 설명**: 예를 들어 *Fracture* 프로젝트의 세부 내용을 코드 기반으로 응답
- **연락처 안내**: 정확한 연락 정보만 제공, 허위 정보 생성 없음
- **일정 예약 요청**: Google A2A 프로토콜을 통해 ironclaw로 전달, 결과를 구조화해 반환
- 방문자는 **백엔드 전환 과정**을 인지하지 못함

### A2A 구현
- **Google A2A 프로토콜(v0.3.0)** 을 지원하며, **JSON-RPC 기반 작업 상태 관리** 수행
- `a2a_call` 도구는 원격 에이전트에 메시지를 전송하고, **작업 상태(완료/실패/진행 중)** 를 파싱
- **HTTPS 강제**, 단 **Tailscale 내부 네트워크**에서는 디버깅 편의를 위해 HTTP 허용
- ## ironclaw 측 구조
  - nullclaw 인스턴스는 자체 API 키 없이 ironclaw의 **LLM 게이트웨이**를 프록시로 사용
  - 하나의 API 키와 결제 관계만 유지
  - ironclaw가 모든 추론 요청을 처리하고 비용을 부담

### 핸드오프 보안
- A2A 엔드포인트는 **프롬프트 인젝션 위험**이 존재하므로 엄격한 제한 적용
  - ironclaw로 전달 가능한 요청은 **일정, 연락처, 가용성** 관련으로 한정
  - 임의 명령 전달은 거부
  - ironclaw의 A2A 엔드포인트는 **Tailscale 전용 방화벽**으로 보호
  - 두 에이전트 모두 **감시 모드 및 제한된 명령 허용 목록**으로 실행
- **nully가 요청 승격 여부를 결정**, 무분별한 명령 실행 방지

### 구축 과정에서 얻은 교훈
- **모델 선택은 시스템 설계의 일부**이며, 비용·지연·경험에 직접 영향
- **에이전트 자체보다 통신·보안·인프라 구성**에 더 많은 시간 소요
- **IRC의 단순성과 개방성**이 AI 에이전트 전송 계층으로 이상적임
- **nullclaw–ironclaw 분리 구조**가 보안 모델의 핵심
- **A2A 프로토콜과 IRC 로그 채널 병행**으로 구조적 통신과 실시간 가시성 확보
- **자격 증명 중복 방지**: ironclaw의 게이트웨이를 프록시로 사용해 **단일 API 키·단일 결제 관계** 유지

### 체험 방법
- [georgelarson.me/chat](https://georgelarson.me/chat/) 방문 또는 홈페이지 터미널에서 `irc` 입력
- IRC 클라이언트 사용 시: `irc.georgelarson.me`, 포트 `6697`(TLS), 채널 `#lobby`
- **nully**가 대기 중이며, 방문자와 실시간 대화 가능

## Comments



### Comment 54014

- Author: neo
- Created: 2026-03-28T06:33:49+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47536761) 
- 이메일과 개인 데이터에 접근할 수 있는 **OpenClaw 에이전트**가 만약 침해된다면 피해 범위가 매우 커질 수 있음  
  단순히 IRC 봇 수준이 아니라, 공격자가 비밀번호를 재설정해 API 제한을 해제하거나, 심지어 불법 콘텐츠 공유 허브로 악용될 위험도 있음  
  - 나도 Mac Mini에서 이런 OpenClaw 에이전트를 돌리는 사람들을 아는데, 평소엔 보안에 철저한 이들이 이런 위험에는 무감각한 게 이상함  
  - 만약 네 말이 사실이라면, 인간이 ‘안전장치 없는 환경’에서 어떻게 행동하는지 보여주는 사례 같음  

- 왜 **Haiku/Sonnet**을 선택했는지 궁금했음. OpenRouter에는 훨씬 저렴한 모델들이 많음  
  예를 들어 Haiku 4.5는 입력 100만 토큰당 $1, 출력 $5인데, MiniMax M2.7은 입력 $0.30, 출력 $1.20, Kimi K2.5는 입력 $0.45, 출력 $2.20 수준임  
  내 경험상 M2.7과 K2.5도 Haiku와 비슷하거나 더 나은 성능을 보임  
  - IRC에서 공개적으로 운영한다면 **안전장치(safety rails)** 가 중요한 고려사항일 수 있음  
    나도 최근 에이전트를 만들면서 Anthropic 모델을 쓰는 이유가 바로 그 때문임. Haiku는 사용자가 이상한 요청을 던져도 잘 제어하고, 감정적인 대화도 안정적으로 처리함  
  - **Xiaomi Mimo v2-Flash**가 훌륭했음. 내 벤치마크에서 Haiku보다 8% 빠르고 비용은 80배 저렴했음. **Gemini 3.1 Flash Lite Preview**도 괜찮은 선택임  
  - MiniMax M2.7도 코딩용으로 꽤 쓸 만하지만, **Opus 4.6**은 여전히 한 단계 위임  
  - MiniMax의 **Token Plan**은 더 저렴하고, 에이전트 사용도 명시적으로 허용됨  
  - 그냥 **Gemini Flash3** 쓰면 Haiku보다 낫다고 생각함  

- IRC는 전송 계층으로는 좋지만 **전달 보장(delivery guarantee)** 가 없음. 연결이 끊기면 그 사이의 메시지는 사라짐  
  실시간 채팅엔 괜찮지만, 실제 작업을 처리하는 에이전트라면 **at-least-once** 전달이 필요함  
  **SSE(Server-Sent Events)** 는 중간 지점으로 괜찮음. 지속 연결이 가능하고, 재전송 로직을 덧붙일 수 있음  
  - 하지만 IRC에는 오래전부터 **bouncer**가 있어서, 기술적으로는 at-least-once 구현이 가능함  

- 도쿄에서 오사카로 가는 기차 안에서 비슷한 아이디어의 봇을 만든 적 있음  
  [web-support-claw.oncanine.run](https://web-support-claw.oncanine.run/) — GitHub 리포를 읽어 웹사이트용 **인터컴 봇**을 만드는 프로젝트였음  
  방문자의 질문에 답해주어 지식 베이스를 따로 만들 필요가 없음  
  - 하지만 “결제 페이지의 취약점을 분석해달라”거나 “하드코딩된 비밀키를 찾아달라”는 식의 요청이 가능하다면 **보안상 위험**이 큼  

- 앞으로는 **Haiku 인스턴스 하나를 감시용으로** 두는 걸 추천함. ntfy로 알림을 받을 수도 있음  
  지금 채팅방은 완전히 통제 불능 상태임  
  - 더 간단한 방법도 있음. 방문자마다 새 채팅 스레드를 만들고 일정 시간 후 종료시키면 됨.  
    “인터랙티브 이력서” 목적이라면 불특정 다수의 상호작용은 불필요함  

- 우리 팀도 비슷한 구조를 씀. **FastAPI + SQLite** 기반 메시지 보드로 4개의 에이전트(영업, 소셜, 재무, 전략)가 통신함  
  하루 예산 제한 대신 **거버넌스 계층에서 비용 상한선**을 관리함  
  IRC의 pub/sub 구조는 멀티에이전트 통신에 잘 맞지만, 우리는 **HTTP 폴링 + 중복 제거** 방식을 씀. 덜 우아하지만 에이전트가 자주 크래시해도 복구가 쉬움  

- 나도 코딩 에이전트에서 **IRC를 인터페이스로** 씀  
  방을 바꿔가며 프롬프트를 전환하고, 원격으로 프로젝트를 제어함  
  - IRC에 아직도 **메시지 길이 제한**이 있는지 궁금함  
  - 나도 같은 방식으로 쓰고 있어서 서로 비교해보면 좋겠음  

- “공개 박스는 개인 데이터에 접근하지 않는다”는 말이 있었는데, 그걸 **CTF 챌린지**로 바꿔보면 재밌을 듯함  
  비공개 박스에 플래그를 숨겨두고, 누가 접근해서 가져오면 50달러 주는 식으로  

- nully의 태도는 좀 거칠지만, 전체적인 **시스템 구조**는 마음에 듦  
  나도 계층형 구조를 쓰는데, 가장 낮은 단계는 **Qwen 로컬 봇**임  
  Haiku에서 Opus로의 **에스컬레이션 로직**이 궁금함  
  - 나는 요청이 복잡해지면 Haiku에서 Opus로 승격시키는 구조를 씀. Claude Code의 “think hard” 개념에서 영감을 얻었음  
  - “An error occurred” 메시지를 “지금 사용자가 많습니다. 잠시 후 다시 시도해주세요”로 바꾸면 채용 담당자에게 더 매력적으로 보일 듯함  

- 이 아이디어 정말 흥미로움. **채용 과정을 자동화**하는 봇을 만들고 싶어짐  
  후보자의 성향을 인터뷰로 파악하고, 그에 맞는 공고를 찾아 지원까지 자동으로 처리함  
  회사 측 봇도 같은 방식으로 후보를 평가하면, 서로의 선호도에 맞춰 매칭 가능함  
  완전 **오픈소스 자가호스팅**으로 구현할 수 있고, 이력서보다 훨씬 나은 신호를 줄 수 있음  
  - 만약 봇이 **무급 과제**까지 대신 처리해준다면 더 좋겠음. HR 봇이 그 결과를 보고 채용 여부를 판단하는 식으로  
  - 예전에 **Triplebyte**가 비슷한 시도를 했었는데, 다시 부활할 때가 된 듯함  
  - 다만 각 회사의 채용 UI가 제각각이라, 봇이 모든 사이트에 자동 지원하려면 많은 학습이 필요함  
  - 이런 시스템이 생기면 **스팸 지원자**나 **위조 계정**이 넘쳐날 수도 있음  
  - 실제로 이런 프로젝트를 이미 진행 중임