원문은 AIdeazz에 게시되었습니다 — 정식 링크와 함께 이곳에 교차 게시되었습니다.

나의 웹 대시보드는 실패했습니다. 그것은 FastAPI 백엔드에 연결되어 프로덕션(production) AI 에이전트의 메트릭(metrics)을 표시하고 제어 기능을 제공하는 맞춤형 React 앱이었습니다. 나는

나는 AIdeazz를 1인 창업자(solo founder)로서 운영합니다. 나의 "팀"은 Python 스크립트와 OCI 서비스들의 집합입니다. 나는 NOC(Network Operations Center) 팀이나 전담 DevOps 엔지니어를 두고 있지 않습니다. 나의 운영 오버헤드(operational overhead)는 거의 제로에 가까워야 합니다.

웹 UI는 다음과 같은 사항들을 요구합니다:

• 배포 (Deployment): 별도의 서비스가 필요하며, 종종 자체적인 데이터베이스, 인증(authentication), 로드 밸런서(load balancer)를 동반합니다. 나의 React 앱 하나만으로도 OCI VM에서 0.5 OCPU와 1GB RAM을 소비했습니다.
• 유지보수 (Maintenance): 라이브러리 업데이트, 보안 패치, 브라우저 호환성 문제.
• 컨텍스트 스위칭 (Context Switching): 나는 이미 터미널, IDE, 또는 이메일에 접속해 있습니다. 운영을 위해 또 다른 브라우저 탭을 여는 것은 정신적인 컨텍스트 스위칭을 유발합니다.
• 모바일 경험 (Mobile Experience): 반응형 디자인(Responsive design)은 어렵습니다. 작은 화면에서 복잡한 데이터와 실시간으로 상호작용하는 것은 더 어렵습니다.

반면, Telegram 봇은 다음과 같습니다:

• 기존 인프라 활용: Telegram이 인증, 푸시 알림(push notifications), 기기 간 동기화(cross-device sync)를 처리합니다.
• 배포 오버헤드 제로: 봇은 그저 내 에이전트들과 함께 실행되거나, 심지어 에이전트 프로세스 내부에서 실행되는 또 다른 Python 스크립트일 뿐입니다. 현재 나의 봇은 메인 오케스트레이션(orchestration) 에이전트 포드(pod) 내에서 사이드카 컨테이너(sidecar container)로 실행되며, 무시할 수 있는 수준의 리소스(50MB RAM 미만)를 소비합니다.
• 네이티브 모바일 경험: 이것은 채팅 앱입니다. 모바일에 최적화되어 설계되었습니다.
• 직접적인 상호작용: 명령을 보내고, 구조화된 데이터(structured data)를 받으며, 승인 흐름(approval flows)을 위해 인라인 키보드(inline keyboards)를 사용할 수 있습니다.

나의 현재 설정은 python-telegram-bot과 asyncio를 사용합니다. 봇은 명령을 대기하고, 로컬 Redis 인스턴스를 통해 에이전트 상태를 조회하며, 메시지를 전송합니다.

실시간 브로드캐스트 및 인라인 승인 (Real-Time Broadcasts and Inline Approvals)

나의 에이전트들은 종종 장시간 실행되는 다단계 프로세스입니다. 예를 들어, 나의 "AI 콘텐츠 크리에이터" 에이전트 체인은 다음과 같습니다:

1. 주제 생성 (Topic Generation): Groq Mixtral-8x7B.
2. 개요 초안 (Outline Draft): Claude 3 Sonnet.
3. 섹션 확장 (Section Expansion): Groq Mixtral-8x7B.
4. 검토 및 개선 (Review & Refine): Claude 3 Opus.
5. 발행 (Publishing): 커스텀 API 호출.

각 단계에서 오류가 발생하거나, 인간의 개입이 필요한 최적화되지 않은 결과물이 나올 수 있습니다.

브로드캐스트: "에이전트 X의 주의가 필요합니다"

대시보드를 계속 확인(polling)하는 대신, 저의 Telegram 봇은 중요한 업데이트를 푸시(push)합니다. 만약 "Outline Draft" 단계에서 주제를 벗어난 개요가 생성되면, 에이전트는 다음과 같은 메시지를 보냅니다:

🚨 Agent: ContentCreator-001
Task: Outline Draft
Status: Review Required
...

[View Outline] 버튼을 누르면 전체 초안을 보내줍니다. [Approve]는 프로세스를 계속 진행하며, [Reject]는 특정 지침과 함께 재시도(retry)를 트리거합니다. 이것이 Telegram의 핵심 기능인 인라인 키보드(inline keyboard)입니다.

인라인 키보드: 단순한 데이터가 아닌 의사결정 지점

저의 웹 대시보드에도 버튼이 있었지만, 그것들은 정적(static)이었습니다. Telegram의 인라인 키보드는 동적(dynamic)입니다. 제가 개요를 거절하면, 봇은 즉시 다음과 같이 묻습니다:

Reason for rejection?
[Too broad] [Off-topic] [Inaccurate] [Other (type below)]

이렇게 구조화된 입력값은 이후 tool_code 또는 user_feedback 파라미터로서 에이전트에게 다시 전달되어, 다음 반복(iteration) 과정을 안내합니다. 이는 상당한 커스텀 개발 없이는 정적인 웹 UI가 구현하기 어려운 핵심적인 피드백 루프(feedback loop)입니다.

예를 들어, OCI 상에서 새로운 에이전트 인스턴스를 생성하는 저의 "AI Agent Provisioner" 봇은 리소스 할당을 위해 인라인 키보드를 사용합니다:

New agent requested: "Marketing Campaign Planner"
Estimated OCPU: 1
Estimated RAM: 2GB
...

이를 통해 실수로 인한 과다 프로비저닝(over-provisioning)을 방지하고, OCI 리소스를 할당하기 전에 빠르게 무결성 검사(sanity check)를 수행할 수 있습니다.

"제대로 된" UI vs. 챗봇의 비용 차이

작은 OCI VM에서 실행되던 저의 웹 대시보드는 한 달에 약 25달러의 비용이 들었습니다. 여기에는 저의 노동 시간 80시간은 포함되지 않았습니다. 그것은 운영 가치가 제한적인 매몰 비용(sunk cost)이었습니다.

반면, 저의 Telegram 봇은 기존의 Kubernetes 포드(pod) 내에서 실행됩니다. 리소스 소비는 무시할 수 있는 수준이며, OCI 청구서에 한 달에 약 0.05달러 정도만 추가됩니다. python-telegram-bot 라이브러리는 무료이며, Telegram API 또한 무료입니다. 저의 개발 시간은 12시간이었습니다.

이러한 비용 차이는 AIdeazz와 같은 부트스트랩 (bootstrapped) 운영 방식에서는 매우 결정적입니다. 인프라에서 절약되는 모든 달러와 핵심 외 개발에서 절약되는 모든 시간은 제가 더 많은 AI 에이전트 (AI agents)를 구축하고 출시할 수 있는 능력에 직접적인 영향을 미칩니다.

다중 에이전트 관리 및 라우팅 (Routing)

저는 현재 10개의 별도 AI 에이전트 (AI agent) 시스템을 관리하고 있습니다. 각 시스템은 여러 개의 하위 에이전트 (sub-agents)를 가질 수 있습니다. 예를 들어, 저의 "AI 연구 보조원 (AI Research Assistant)" 시스템은 다음과 같이 구성됩니다:

• 검색 에이전트 (Search Agent): SerpAPI를 호출하고 결과를 처리합니다.
• 요약 에이전트 (Summarization Agent): Claude 3 Sonnet을 사용합니다.
• 합성 에이전트 (Synthesis Agent): 빠른 초안 생성을 위해 Groq Mixtral-8x7B를 사용합니다.
• 팩트 체크 에이전트 (Fact-Checking Agent): 외부 API를 호출하고 교차 검증합니다.

저의 Telegram 봇을 통해 다음과 같은 작업이 가능합니다:

• 모든 활성 에이전트 목록 보기: /agents list
• 에이전트 상태 확인: /agent status ContentCreator-001
• 특정 에이전트에 명령 전송: /agent ContentCreator-001 restart 또는 /agent ResearchAssistant-003 debug_mode true
• LLM 호출 라우팅 (Routing): 특정 단계에서 Claude 3 Opus가 너무 느리다면, /agent ContentCreator-001 set_llm_for_step OutlineDraft GroqMixtral 명령을 내려 에이전트의 내부 라우터 (router)를 조정할 수 있습니다. 이는 정적인 대시보드 (dashboard)로는 제공하기 어려운 강력한 실시간 제어 기능입니다.

자주 묻는 질문 (FAQ)

Q: Telegram 봇의 인증과 보안은 어떻게 처리하나요?
A: Telegram API는 봇 토큰 (bot tokens)을 사용합니다. 저는 제 자신의 Telegram ID 화이트리스트와 user_id를 대조하여 봇에 대한 접근을 제한합니다. 이는 1인 운영자에게는 충분한 방식입니다. 팀 단위의 경우, ID 제공자 (identity provider)와 통합하거나 더 엄격한 역할 기반 액세스 제어 (role-based access control)를 위해 Telegram의 그룹 관리 기능을 사용할 것입니다.

Q: Telegram이 다운되거나 API에 문제가 생기면 어떻게 되나요?
A: 저의 에이전트들은 회복 탄력성 (resilient)을 갖도록 설계되어 자율적으로 계속 작동합니다. Telegram 봇은 에이전트의 핵심 실행을 위한 것이 아니라, 개입 (intervention) 및 _모니터링 (monitoring)_을 위한 것입니다. 봇이 다운되더라도 에이전트는 여전히 실행됩니다. 이 경우 SSH와 직접적인 로그 검사 (log inspection)로 전환하겠지만, 이는 드문 경우입니다.

Q: 봇의 코드와 배포는 어떻게 관리하나요?
A: 봇의 코드는 제 메인 오케스트레이션 에이전트 (orchestration agent) 저장소 내의 Python 스크립트입니다. 이는 동일한 Kubernetes 포드 (pod) 내의 사이드카 컨테이너 (sidecar container)로 배포됩니다. 업데이트는 오케스트레이션 에이전트를 위한 표준 CI/CD 파이프라인 (CI/CD pipeline)의 일부로 처리됩니다.

Q: 명령어와 그 출력 결과의 예시를 공유해 주실 수 있나요?
A:
사용자: /agent ResearchAssistant-003 status
봇: 에이전트 ResearchAssistant-003은 활성 (ACTIVE) 상태입니다. 현재 작업: '바이오테크 분야의 양자 컴퓨팅 (Quantum Computing in Biotech)'에 대한 보고서 합성 중. 마지막 성공 단계: 사실 확인 (Fact-checking) (2024-07-23 14:35 UTC). 예상 완료 시간: 15:00 UTC.

Q: 채팅 인터페이스가 제공할 수 없는 복잡한 데이터 시각화는 어떻게 하나요?
A: 심층 분석 (deep analytics)이나 과거 트렌드 (historical trends)를 위해서는 여전히 Oracle Cloud Monitoring과 Grafana로 메트릭 (metrics)을 전송합니다. Telegram 봇은 장기적인 데이터 분석용이 아니라, 운영 제어 (operational control) 및 _실시간 알림 (real-time alerts)_을 위한 것입니다. 이는 집계된 트렌드를 관찰하는 것이 아니라, 개입 (intervention)을 위한 것입니다.

— Elena Revicheva · AIdeazz · Portfolio