요즘 하루가 멀다하고 정말 다양한 AI 개발 툴들이 쏟아지고 있습니다. 말로만 코딩하는 '바이브 코딩'이라는 말도 이제는 제법 익숙해진 것 같습니다.

사실 저는 개발에서 손뗀 지는 이미 20년이 훌쩍 넘은 개발자라고 불리었던 적이 있는 사람이죠. 사업부 관리 업무에 치이다 보니 코딩은 고사하고 최신 기술 트렌드를 따라가기도 벅찬 게 현실이었죠.

회의 때마다 팀원들에게 "요즘 세상이 바뀌었으니 업무에 AI 좀 적극적으로 적용해라. 니들 업무는 니들이 제일 잘 알지 않냐"라며 입개발(?)만 시전하곤 했습니다. 그러던 어느 날 말로만 떠들바에는, 차라리 내가 직접 부딪쳐서 지시보다는 모범을 보여주자고 결론을 내렸습니다.

Google의 Antigravity를 활용해서 비개발자 대상으로 세미나도 하고 뭐 이것 저것 하고 있었는데 Antigravity가 2.0으로 환골 탈퇴를 했더군요

그중 SDK 지원이 눈에 들어와서 이걸 테스트도 할 겸 실제 업무에 한번 써먹어 보자라고 마음을 먹게 되었습니다.

0단계: 내 업무의 에이전트화, 그리고 눈물겨운 인프라 선정기

그리고 매일 반복되는 제 일과를 보며 제대리와 안과장에게 지시를 내려 구현하다 보니, 거창한건 아니지만 어느새 3개의 에이전트 라인업이 갖춰졌습니다.

· Agent 1 (IT 뉴스 봇): 매일 아침 테크 트렌드를 파악해야 하는 나를 대신해, 구글 챗으로 기술 뉴스를 검색하고 요약해 주는 봇
· Agent 2 (트렌드 뉴스 봇): 시장 변화를 읽기 위해 비즈니스 뉴스를 상시 스크랩하고 구글 챗으로 요약본을 던져주는 봇
· Agent 3 (공식 업데이트 봇): 주요 글로벌 기업의 Google RSS를 분석하여 운영 중인 워드프레스에 자동으로 정보를 포스팅해 주는 봇

제대리, 안과장 덕분에 만드는건 무난하게 끝이 났습니다. 하지만 개발이 끝난 후, 이 에이전트들을 내 PC가 아닌 서버 환경에서 24시간 실시간(프로덕션)으로 돌리려니 비용과 인프라라는 현실적인 벽에 부딪혔습니다. 개인 자동화인데 매달 아까운 서버 비용을 펑펑 쓸 수는 없었으니까요. 비용 최소화를 위한 제 눈물겨운 여정은 이랬습니다.

1. LLM API 선택 (Gemini 무료 플랜): 비용 부담을 제로로 만들기 위해, 분당 요청 제한(RPM)은 있지만 완벽히 무료인 우리 제대리(Gemini)의 무료 플랜을 기반으로 구조를 짰습니다.
2. 사내 안 쓰는 구형 PC 발굴: 사무실 구석에 먼지 쌓인 PC를 서버로 쓸까 했으나, 24시간 켜두기엔 전력 소모와 소음, 부품 고장 우려가 컸습니다.
3. 미니 PC 구매 고려: 당근마켓이나 알리를 뒤적거리며 가성비 미니 PC 구매를 진지하게 고민했습니다. 하지만 이 역시 추가 비용이 들어가는 일이었죠.
4. 최종 선택 (Synology DS218play): 결국 제 눈에 들어온 것은 이미 사무실 한구석에서 파일 백업용으로 조용히 돌아가고 있던 Synology DS218play NAS였습니다.

💡 여기서 잠깐, 우리 서버(DS218play) 사양 보고 가실게요. • CPU: Realtek RTD1296 (4코어 1.4GHz) -> 폰 프로세서보다 못한 ARM 아키텍처 • RAM: DDR4 1GB (업그레이드 절대 불가, 납땜 고정형) • OS: DSM (DiskStation Manager) 기본 상주 원래 목적이 '미디어 스트리밍 및 파일 백업용'이라, 메모리가 고작 1GB밖에 안 되는 녀석입니다. 시스템 OS가 먹고 남은 쥐꼬리만 한 RAM 용량 위에서 파이썬 스크립트 3개를 돌려야 하는 극한의 환경이었죠. 여기에 꾸역꾸역 얹어서 무상으로 돌리기로 결론을 내렸습니다.

문제는 사양이 낮은 NAS 환경에서, 그것도 무료 API를 쓰면서 혼자 에이전트 3개를 무중단으로 돌리려니 메모리를 너무 많이 잡아 먹는 것 외에도 몇가지 예외처리와 고도화 작업이 필요했다는 점입니다.

결국 참지 못하고 주말, 모니터 앞에 주저앉았습니다. 휴일에 집안일은 안 돕고 컴퓨터 앞에만 앉아있냐는 마눌님의 따가운 핀잔을 들어가며 하루 종일 제대리, 안과장에게 업무 지시를 내리며 뚝딱거렸는데, 이상하게도 입가에 미소가 번지더군요. 생소한 Python 에러 코드를 분석하고 예외 처리를 고민하는 과정이 마치 20대 젊은 개발자 시절로 돌아간 것 같아 가슴 한구석이 살짝 설레고 즐거웠습니다. 그렇게 마눌님의 등짝 스매싱(?) 위기를 넘기며 시스템을 뜯어고친 생생한 기록을 공유합니다.

1단계: 죽지 않는 좀비로 만들기 (다중화 모델 백업)

AI 에이전트의 심장이라고 할 수 있는 LLM API는 제 통제 하에 있지 않습니다. 제대리(Gemini 무료 플랜)가 일을 참 잘하는데, 무료 플랜 특성상 조금만 요청이 몰려도 429 Rate Limit(할당량 초과)을 뱉으며 파업을 선언하거나, 구글 서버 상태에 따라 503 Service Unavailable 에러를 내며 프로세스가 그냥 다운되어 버리죠.

과거에는 에러가 나면 시스템 전체가 죽으면서 구글 챗 채널에 지저분한 시스템 에러 코드가 그대로 노출되는 취약점이 있었습니다. 바쁘게 일하다가 슬쩍 채널을 봤을 때 에러 코드가 도배되어 있으면 여간 스트레스가 아니었죠.

그래서 제대리가 과부하로 에러를 뿜으면, 시간 간격을 늘려가며 여러 번 재시도하는 지수 백오프(Exponential Backoff)를 적용했습니다. 하지만 지정된 횟수를 다 실패한다? 그럼 최후의 보루로 상대적으로 트래픽 여유가 있거나 쿼터가 남아있는 백업 모델로 자동 전환되어 재처리를 시도하는 '다중화 모델 백업(Fallback)' 구조를 설계했습니다. 안과장에게 백업 라인을 든든하게 받치도록 지시해 둔 덕분입니다.

🔄 자가 복구형(Self-healing) 핵심 구조

메인 모델(5회 재시도 실패) ➔ 백업 모델 자동 전환 및 6번째 재처리 시도 ➔ 안정적인 무중단 파이프라인 유지

여기에 포스팅 전 과정을 최상위 try-except 블록으로 싹 감쌌습니다. 백업 모델까지 다 실패하는 최악의 상황이 오더라도, 채널에 에러 코드를 뱉는 대신 콘솔에 깔끔한 로그만 남기고 다음 주기로 안전하게 이관되도록 한 거죠. 일명 '우아한 종료(Graceful Shutdown)'입니다.

콘솔 로그도 직관적으로 볼 수 있게 세분화해 두니, 터미널만 봐도 뭐가 문제인지 한눈에 역추적이 되어서 마음이 아주 편안해집니다.

⚠️ 구글 서버 과부하 감지... (제대리 재시도 중) 🔄 [백업 모드] 메인 모델 과부하로 인한 모델 전환 시도 (안과장 등판) 🚨 백업 모델 요약도 실패했습니다. 이번 턴은 발행을 건너뜁니다.

2단계: 에이전트별 특성을 고려한 정밀 모니터링

실제 1GB RAM의 DS218play 환경에서 24시간 구동해 보니 참 별의별 에러 케이스들이 쏟아지더군요. 제대리와 안과장에게 각자 맡은 에이전트 성격과 인프라에 맞게 모니터링 체크포인트를 촘촘하게 치도록 지시했습니다.

1. 뉴스 검색 및 요약 봇 계열 (Agent 1, 2)

· 할당량 초과 감시: 무료 플랜의 한계로 인해 429 에러가 상시 감시망에 걸리면, 제대리가 준비해 둔 다른 API 키로 알아서 로테이션(Rotation) 시키도록 매니저 모듈을 구현했습니다.
· LLM 출력 제어: 이 녀석들이 가끔 프롬프트를 무시하고 마크다운 기호를 난입시켜 구글 챗 가독성을 해칠 때가 있습니다. 특화 UI 기호(■, •)가 깨지지 않게 정규식 치환 장치를 상시 가동 중입니다.
· 스토리지 관리: 중복 발송을 막으려고 만든 데이터 이력 JSON 파일이 안 그래도 부족한 DS218play의 스토리지와 인덱싱 자원을 무한히 잡아먹으면 시스템 전체가 느려지겠죠? 일정 기간이 지난 데이터는 자동으로 날려버리는 Clean 메커니즘을 심어두었습니다.
· API 키 매니저 : 여러 개의 Gemini 무료 API 키를 하드코딩하지 않고, 제한량에 걸릴 때마다 제대리가 안전하게 동적 조회/로테이션하는 중앙 집중형 모듈 만들기

2. 워드프레스 자동 포스팅 봇 (Agent 3)

· 공백 문자 하이재킹(?): 워드프레스 API 인증을 위해 애플리케이션 비밀번호를 발급받으면 4글자 단위로 공백이 포함되어 오는데, 이게 소스코드에 그대로 복사되면 401 Unauthorized 에러가 나더군요. 공백을 완전히 지워주는 세심한 처리가 필요합니다. (예시: XXXX XXXX XXXX ➔ XXXXXXXXXXXX)
· 구글 공식 블로그의 RSS 서버가 다운되거나 데이터가 빌 때 터지는 크래시도 안과장의 상시 모니터링 대상입니다.

3. 인프라 환경 (Synology NAS 특성)

· [Errno 2]와의 사투: NAS 파일 수정 과정에서 가끔 숨김 확장자가 붙어 파일명이 변조되거나, 스케줄러(Cron job) 명령상의 대소문자가 실제 파일명과 달라 파일이 없다고 뻗는 황당한 에러들도 주기적으로 체크해 줘야 합니다. 리소스가 한정된 리눅스 기반 DSM 인프라일수록 파일 I/O 에러에 아주 민감하더군요.

3단계: 알림 채널 단일화 (Single Source of Truth)

이번 패치에서 가장 만족도가 높은 부분 중 하나입니다. 예전에는 어떤 봇이 죽었는지 확인하려면 제 업무를 하다가 일일이 각 봇의 터미널 로그를 열어보거나 개별 스페이스를 뒤적거리며 제대리와 안과장을 호출해야 했습니다. 안 그래도 챙길 게 많은데 인지적 부하가 장난이 아니었죠.

지금은 지정된 모니터링 전용 웹훅 스페이스 딱 한 곳으로 모든 에이전트의 생존 신호(Heartbeat)와 에러 로그를 집약시켰습니다.

# 보안 관리를 위해 환경변수(.env)로 관리되는 모니터링 웹훅 샘플 https://chat.googleapis.com/v1/spaces/YOUR_SPACE_ID/messages?key=YOUR_KEY&token=YOUR_TOKEN

메시지 헤더만 보고도 제가 대응 우선순위를 직관적으로 파악할 수 있도록 접두사(Prefix) 규칙도 딱 정해두었죠.

봇 상태	분류	알림 타이틀 Prefix	우선순위	예시 시나리오
정상 작동	운영상태	[운영상태] 에이전트 정상작동	Low	신규 뉴스 발행 완료 / 중복 뉴스 패스 시
예외 발생	오류로그	[오류로그] 에이전트 예외발생	High	RSS 파싱 실패 / WP 401 에러 / API 최종 거부 시

 

Agent 실행 시간에 이 채널로 전달되는 메세지만 슥 확인하면 제 에이전트들이 어떤 상태인지 바로 파악되니까 대응과 업무 관리 속도가 엄청나게 빨라졌습니다.

정리를 마치며

직접 경험해 보니, 요즘 AI 개발 가속화 툴과 LLM의 성능은 정말 눈이 부실 정도입니다. 제가 본업을 보면서, 난생처음 만지는 Python과 Google API를 조합해 나만의 멀티 에이전트 시스템을 완성해 냈으니 말입니다. 제대리와 안과장이라는 초강력 치트키 부하들이 없었다면 진작에 포기하고 팀원들에게 말로만 지시하고 있었을 것입니다.

그런데 AI가 도와 준다고 한들 결국 '인프라에 맞춘 예외 처리와 모니터링'이라는 상황에 대한 판단은 제가 할 수 밖에 없더군요. 하지만 공짜 API와 구석에 굴러다니던 똥형(?) NAS 조합이라도, 짜임새 있는 방어 코딩만 있다면 훌륭한 무중단 자동화 시스템을 만들 수 있다는 귀중한 교훈을 얻었습니다.

저 같은 기술적 노땅도 AI의 손을 잡고 '모범'을 보일 수 있었으니, 여러분들은 훨씬 더 멋진 시스템을 훨씬 쉽게 만드실 수 있을 겁니다. 비용 최소화와 업무 자동화를 위해 고민하며 저와 비슷한 삽질(?)을 하고 계신 분들께 제 기록이 작은 즐거움과 용기가 되었으면 좋겠습니다.