<div id="readability-page-1" class="page"><div>
<p>최근 나의 디지털 생활은 ‘비서실’ 체제로 전환되었다. 메인 비서 <strong>루나</strong>, 작가 비서 <strong>노아</strong>, 알림 센터 <strong>벨</strong>, 그리고 기술 이사 <strong>아이언</strong>까지. 하지만 이 화려한 라인업을 구축하는 과정은 그야말로 ‘API와의 전쟁’이자 ‘자원 최적화의 대장정’이었다.</p>

<p><img src="https://moonspam.github.io/images/2026-02-24-multi-agent.jpg" alt="비서실 단체 사진"></p>

<h3 id="-왜-멀티-에이전트인가">🤖 왜 멀티 에이전트인가?</h3>
<p>처음엔 루나 한 명이면 충분할 줄 알았다. 하지만 대화, 수집, 집필, 모니터링이 한 채널에 섞이니 가독성이 처참해졌고, 무엇보다 한 명의 에이전트가 모든 컨텍스트를 짊어지기엔 4GB라는 UTM 가상 머신의 환경이 너무나 가혹했다. 그래서 역할을 분리하고, 각자 전용 워크스페이스와 텔레그램 봇을 부여한 ‘비서실’을 만들게 되었다.</p>

<h3 id="️-최대의-위기-api-할당량-초과와-무응답의-늪">🌪️ 최대의 위기: “API 할당량 초과와 무응답의 늪”</h3>
<p>가장 큰 고비는 비서들이 한데 모인 <strong>단체 대화방</strong>을 구축했을 때 찾아왔다. 비서들끼리 서로의 메시지에 응답하고, 각자의 크론(Cron) 작업 결과를 실시간으로 보고하기 시작하면서 API 호출량이 기하급수적으로 폭증했다.</p>

<p>결국, 몇 시간 동안 모든 에이전트가 “Connection error”를 내뱉으며 집단 파업에 들어가는 사태가 발생했다. ‘스마트함’을 위해 구축한 시스템이 오히려 ‘무응답’이라는 부메랑이 되어 돌아온 것이다.</p>

<h3 id="️-어떻게-풀어나갔나-안정화-전략">🛠️ 어떻게 풀어나갔나? (안정화 전략)</h3>
<p>이 위기를 극복하기 위해 우리는 ‘침묵의 미학’과 ‘분리 전략’을 도입했다.</p>

<ol>
  <li>
    <p><strong>중복 보고 금지 및 NO_REPLY 원칙:</strong> 
가장 먼저 한 일은 에이전트들에게 “할 말이 없으면 침묵하라”는 지침을 내린 것이다. 10분 이내의 중복 알림이나, 특이사항이 없는 루틴 작업은 <code>NO_REPLY</code>로 처리하게 하여 불필요한 API 소모를 원천 차단했다.</p>
  </li>
  <li>
    <p><strong>Worker-Agent 구조로의 체질 개선:</strong>
에이전트가 직접 웹을 크롤링하고 분석하던 방식에서, 가벼운 파이썬 스크립트(Worker)가 로우 데이터를 먼저 수집해 파일로 저장하고, 에이전트는 필요한 시점에 그 파일만 읽어 분석하는 방식으로 개편했다. 이 ‘저비용 고효율’ 구조 덕분에 API 호출 횟수를 획기적으로 줄일 수 있었다.</p>
  </li>
  <li>
    <p><strong>로컬 모델(Ollama)의 퇴진:</strong>
4GB RAM 환경에서 메모리를 대량 점유하던 로컬 모델을 과감히 포기하고, All-Cloud(Gemini) 체제로 전환했다. 덕분에 시스템은 다시 기민해졌고, 비서들은 지치지 않고 응답하기 시작했다.</p>
  </li>
</ol>

<h3 id="-마치며">🌟 마치며</h3>
<p>시행착오를 거치며 깨달은 점은, AI 비서 역시 사람과 마찬가지로 ‘명확한 R&amp;R(역할과 책임)’과 ‘적절한 휴식(API 절약)’이 필요하다는 것이다. 현재 우리 비서실은 그 어느 때보다 평온하고 정갈하다.</p>

<p>단순히 화려한 기능을 넣는 것보다, 제한된 자원 안에서 얼마나 우아하게 시스템을 유지하느냐가 진정한 ‘AI 엔지니어링’의 묘미가 아닐까 싶다. ✍️</p>

</div></div>

코딩 공부방

최근 나의 디지털 생활은 ‘비서실’ 체제로 전환되었다. 메인 비서 루나, 작가 비서 노아, 알림 센터 벨, 그리고 기술 이사 아이언까지. 하지만 이 화려한 라인업을 구축하는 과정은 그야말로 ‘API와의 전쟁’이자 ‘자원 최적화의 대장정’이었다.
🤖 왜 멀티 에이전트인가?
처음엔 루나 한 명이면 충분할 줄 알았다. 하지만 대화, 수집, 집필, 모니터링이 한 채널에 섞이니 가독성이 처참해졌고, 무엇보다 한 명의 에이전트가 모든 컨텍스트를 짊어지기엔 4GB라는 UTM 가상 머신의 환경이 너무나 가혹했다. 그래서 역할을 분리하고, 각자 전용 워크스페이스와 텔레그램 봇을 부여한 ‘비서실’을 만들게 되었다.
🌪️ 최대의 위기: “API 할당량 초과와 무응답의 늪”
가장 큰 고비는 비서들이 한데 모인 단체 대화방을 구축했을 때 찾아왔다. 비서들끼리 서로의 메시지에 응답하고, 각자의 크론(Cron) 작업 결과를 실시간으로 보고하기 시작하면서 API 호출량이 기하급수적으로 폭증했다.
결국, 몇 시간 동안 모든 에이전트가 “Connection error”를 내뱉으며 집단 파업에 들어가는 사태가 발생했다. ‘스마트함’을 위해 구축한 시스템이 오히려 ‘무응답’이라는 부메랑이 되어 돌아온 것이다.
🛠️ 어떻게 풀어나갔나? (안정화 전략)
이 위기를 극복하기 위해 우리는 ‘침묵의 미학’과 ‘분리 전략’을 도입했다.
중복 보고 금지 및 NO_REPLY 원칙: 
가장 먼저 한 일은 에이전트들에게 “할 말이 없으면 침묵하라”는 지침을 내린 것이다. 10분 이내의 중복 알림이나, 특이사항이 없는 루틴 작업은 NO_REPLY로 처리하게 하여 불필요한 API 소모를 원천 차단했다.
Worker-Agent 구조로의 체질 개선:
에이전트가 직접 웹을 크롤링하고 분석하던 방식에서, 가벼운 파이썬 스크립트(Worker)가 로우 데이터를 먼저 수집해 파일로 저장하고, 에이전트는 필요한 시점에 그 파일만 읽어 분석하는 방식으로 개편했다. 이 ‘저비용 고효율’ 구조 덕분에 API 호출 횟수를 획기적으로 줄일 수 있었다.
로컬 모델(Ollama)의 퇴진:
4GB RAM 환경에서 메모리를 대량 점유하던 로컬 모델을 과감히 포기하고, All-Cloud(Gemini) 체제로 전환했다. 덕분에 시스템은 다시 기민해졌고, 비서들은 지치지 않고 응답하기 시작했다.
🌟 마치며
시행착오를 거치며 깨달은 점은, AI 비서 역시 사람과 마찬가지로 ‘명확한 R&R(역할과 책임)’과 ‘적절한 휴식(API 절약)’이 필요하다는 것이다. 현재 우리 비서실은 그 어느 때보다 평온하고 정갈하다.
단순히 화려한 기능을 넣는 것보다, 제한된 자원 안에서 얼마나 우아하게 시스템을 유지하느냐가 진정한 ‘AI 엔지니어링’의 묘미가 아닐까 싶다. ✍️

멀티 에이전트 비서실 구축기: 4GB RAM과 무한 루프를 넘어 안정화로

댓글