▲

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

 (georgelarson.me)
2P by GN⁺ 5시간전 | ★ favorite | 댓글 1개
  • 개인 포트폴리오 사이트에 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 방문 또는 홈페이지 터미널에서 irc 입력
  • IRC 클라이언트 사용 시: irc.georgelarson.me, 포트 6697(TLS), 채널 #lobby
  • nully가 대기 중이며, 방문자와 실시간 대화 가능
▲
GN⁺ 5시간전  [-]
Hacker News 의견들

  • 이메일과 개인 데이터에 접근할 수 있는 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 — 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가 제각각이라, 봇이 모든 사이트에 자동 지원하려면 많은 학습이 필요함
    • 이런 시스템이 생기면 스팸 지원자나 위조 계정이 넘쳐날 수도 있음
    • 실제로 이런 프로젝트를 이미 진행 중임
답변달기