$7/월 VPS에 IRC를 transport로 쓰는 AI Agent 포트폴리오 도우미 만들기

Who Should Read

개인 포트폴리오나 소규모 서비스에 AI agent를 붙이고 싶은데 비용과 보안이 걱정인 풀스택/백엔드 개발자. 특히 multi-agent 아키텍처와 tiered inference 비용 최적화 전략을 실제로 어떻게 구현하는지 궁금한 사람.

Core Mechanics

• 대부분의 포트폴리오 AI 챗봇은 이력서 내용을 그대로 LLM에 먹여서 방문자가 그걸 재구성하게 만드는 수준인데, 저자는 이를 '마술쇼'로 표현하며 실제 GitHub 코드를 clone하고 CI 설정까지 읽어서 구체적인 수치로 답하는 agent를 만들고자 했다.
• 보안 경계를 명확히 하기 위해 agent를 둘로 나눴다. 공개용 nullclaw는 $7/월 VPS에서 동작하며 GitHub 공개 repo 접근과 포트폴리오 컨텍스트만 갖고, 비공개용 ironclaw는 Tailscale로 연결된 별도 서버에서 이메일·캘린더·개인 컨텍스트를 처리한다. 이 경계 덕분에 공개 박스가 뚫려도 개인 데이터는 안전하다.
• transport layer로 IRC를 선택한 이유는 세 가지다. 포트폴리오 사이트의 터미널 UI와 맞는 aesthetics, 플랫폼 의존성 없는 완전한 자체 스택 소유, 그리고 30년된 검증된 프로토콜이라는 점. Discord나 Telegram은 언제든 API 정책이 바뀔 수 있지만 IRC는 vendor lock-in이 없다.
• 모델 선택을 의도적으로 tiered(계층화)했다. 인사말·간단한 질문 등 hot path는 Claude Haiku 4.5(빠르고 저렴, 대화당 몇 센트)를 쓰고, repo를 clone하거나 여러 파일을 분석해야 할 때만 Claude Sonnet 4.6으로 escalate한다. '추론이 필요할 때만 추론 비용을 낸다'는 철학이다.
• 비용 제어를 설계의 핵심으로 넣었다. 하루 $2, 한 달 $30 하드캡을 설정해서 누군가 의도적으로 API 비용을 소진시키려 해도 한계가 있다. nullclaw는 시간당 10개 action 제한, read-only 도구만 허용된 샌드박스 모드로 동작한다.
• 기술 스택이 인상적으로 가볍다. nullclaw는 4MB Zig 바이너리로 ~1MB RAM만 쓰고, IRC 서버인 ergo는 Go 바이너리 2.7MB RAM, 웹 IRC 클라이언트 gamja는 빌드 결과 152KB다. Cloudflare를 앞단에 붙여서 방문자가 서버에 직접 닿지 않게 하고 TLS 종료·레이트 리밋·봇 필터링을 맡겼다.
• 보안 hardening을 퍼미터 박스 수준으로 적용했다. SSH는 비루트 유저·키 인증·비표준 포트, UFW로 SSH/IRC(TLS)/HTTPS 세 포트만 열고, Let's Encrypt 자동 갱신, 보안 업데이트 자동 적용, 모든 tool call 감사 로그를 남긴다. 박스의 역할이 딱 두 가지(ergo + nullclaw)여서 attack surface 자체가 작다.

Evidence

• '공개 박스가 뚫려도 blast radius가 $2/day IRC 봇 수준'이라는 저자 주장에 대해, 댓글에서는 nullclaw가 ironclaw에 라우팅할 수 있으므로 실제로는 이메일과 개인 데이터 접근이 가능하다는 반론이 나왔다. 또한 채팅이 public lobby라서 방문자끼리 대화가 보이는 구조이기 때문에 '불법 콘텐츠 유통 허브가 될 수 있다'는 심각한 지적도 있었고, 실제로 테스트 중 채팅이 '완전히 통제 불능 상태'가 됐다는 목격담도 공유됐다.
• Haiku/Sonnet 선택에 대해 OpenRouter에 더 저렴한 모델이 있다는 지적이 있었다. Haiku 4.5가 입력 $1/M 토큰인데 비해 MiniMax M2.7은 $0.30/M, Kimi K2.5는 $0.45/M이며 성능도 대부분의 태스크에서 비슷하거나 낫다는 경험이 공유됐다. 비용에 민감한 구현이라면 대안 모델 검토가 필요하다는 의견이다.
• IRC의 at-most-once 메시지 전달 특성에 대한 기술적 비판이 있었다. agent가 연결이 끊기면 그 사이 메시지가 소실되는데, 대화용으로는 괜찮지만 실제 작업을 처리하는 agent라면 at-least-once 보장이 필요하다는 것이다. SSE(Server-Sent Events)나 HTTP polling + ack 기반 dedup이 더 나은 대안이라는 의견도 나왔다. 비슷한 multi-agent 아키텍처를 FastAPI + SQLite로 구현한 팀은 하루 약 50번 agent crash가 발생했고, dedup 상태 지속성이 첫 번째로 문제가 됐다고 경험을 공유했다.
• 보안 관련 추가 지적으로, prompt injection 방어가 system prompt에 '이걸 하지 마라'고 적어두는 수준이라면 실질적인 보안이 아니라는 날카로운 비판이 있었다. 또한 unattended security upgrades(자동 보안 업데이트)가 오히려 보안 리스크가 될 수 있다는 의견도 나왔는데, 최근 litellm 라이브러리 보안 사고 사례를 예로 들며 자동 업데이트 자체가 공격 벡터가 될 수 있다고 지적했다.
• $2/day 비용 상한이 결국 'Achilles heel'이 됐다는 실제 관찰이 있었다. 글이 공유된 직후 봇이 이미 응답을 멈췄다는 제보가 있었으며, 자주 묻는 질문 캐싱이나 API 무료 티어 활용으로 비용을 줄일 수 있다는 제안이 나왔다. 반면 하루 지출 하드캡 방식을 'smart하다'고 평가하며, 비용 거버넌스를 잘못된 레이어에서 해결하는 AI 코딩 도구들의 문제를 이 방식이 제대로 짚었다는 긍정적 평가도 있었다.

How to Apply

• 포트폴리오나 개인 프로젝트에 AI 챗봇을 붙이려는 경우, 이력서 텍스트 대신 실제 GitHub repo URL을 컨텍스트로 제공하고 agent가 repo를 clone해서 읽도록 구성하면 'CI 커버리지가 몇 %인가', '어떤 테스트 프레임워크를 쓰는가' 같은 구체적인 질문에 실제 코드 기반으로 답할 수 있다.
• LLM API 비용 폭탄이 걱정되는 공개 서비스를 운영 중이라면, 저자처럼 hot path(인사말, 간단 질문)는 Haiku급 소형 모델, 실제 분석이 필요한 경우만 Sonnet급으로 escalate하는 tiered inference 구조를 적용하고 하루 $2~$5 하드캡을 API 레벨에서 설정하면 abuse 시 피해를 제한할 수 있다.
• multi-agent 시스템에서 공개/비공개 데이터 접근 경계가 필요한 경우, nullclaw/ironclaw처럼 agent를 물리적으로 다른 서버에 분리하고 Tailscale로 내부 통신만 허용하는 구조를 채택하면 공개 agent가 타협되더라도 개인 데이터로의 접근 경로를 차단할 수 있다. 단, 두 agent 간 라우팅 경로 자체가 attack vector가 될 수 있으므로 ironclaw 접근 조건을 엄격히 설계해야 한다.
• agent의 file system 접근과 실행 권한이 걱정된다면, 저자처럼 workspace 디렉토리 한정 파일 접근, read-only 도구만 허용하는 command allowlist, 시간당 action 횟수 제한(예: 10회/시간)을 조합해서 supervised mode로 운영하면 agent가 탈취되더라도 할 수 있는 행동 범위를 제한할 수 있다.

Terminology

Related Resources

• 원문: Building a Digital Doorman
• 댓글에서 공유된 유사 프로젝트: GitHub repo 기반 웹사이트 인터콤 봇
• Ergo IRC 서버 (Go 바이너리, 2.7MB RAM)
• gamja 웹 IRC 클라이언트 (152KB built)