Agentic AI 구축 사례: MCP로 만든 AI 뉴스 수집·카톡 배포 시스템 (일 300명 사용)

매일 아침 카카오톡으로 AI 뉴스가 도착하는 채널을 만들었더니, 운영 시작 두 달 만에 일일 사용자 300명을 넘었습니다. 이 시스템은 단순한 RSS 수집 봇이 아니라 MCP(Model Context Protocol)를 도구 계층으로 쓰는 Agentic AI 구축 사례에 가깝습니다. 에이전트가 어떤 소스에서 어떤 뉴스를 가져올지, 어떤 글을 버리고 어떤 글을 요약할지 매번 판단을 내리고, 그 판단을 바탕으로 카카오톡 채널에 자율적으로 배포합니다. 이 글은 우리가 그 Agentic AI 구축 과정에서 부딪힌 설계 결정과 안정화 과정을 코드 흐름과 함께 공개합니다.

!MCP 기반 AI 뉴스 자동 수집 시스템 — 일 300명 사용

단순 RSS 수집기와 Agentic AI는 무엇이 다른가

겉으로만 보면 "AI 뉴스를 모아 카톡으로 보내준다"는 흔한 자동화입니다. 그러나 RSS 크롤러와 Agentic 시스템의 차이는 명확합니다. RSS는 정해진 피드에서 정해진 필드를 그대로 끌어옵니다. 사람이 사전에 룰을 모두 박아 둬야 하고, 새 소스가 등장하면 코드를 고쳐야 합니다. 반면 Agentic AI는 LLM이 매 사이클마다 "지금 이 글을 가져올 가치가 있는가", "이 글은 어제 본 글과 같은 주제인가", "바이브 코더에게 도움이 되는 글인가"를 판단합니다. 판단의 입력은 메타데이터가 아니라 본문 자체이고, 판단의 출력은 단순한 boolean이 아니라 다음에 어떤 도구를 호출할지에 대한 선택입니다.

이 차이가 운영에서 가장 크게 드러나는 지점은 노이즈 필터링이었습니다. AI 관련 키워드가 들어간 글의 70~80%는 단순 마케팅 리포스트, 광고성 콘텐츠, 또는 어제 다른 매체에 나간 기사의 재가공입니다. 룰 기반 필터로는 "OpenAI"라는 단어를 포함한 글을 모두 떨어뜨리거나 모두 받아들이거나 둘 중 하나밖에 선택지가 없습니다. 에이전트는 본문 200~400자를 직접 읽고 "이 글은 어제 본 GPT 발표의 재가공이라 스킵", "이 글은 새로운 벤치마크 결과라 채택"이라는 식의 결정을 내립니다. 같은 키워드를 가진 두 글의 운명이 달라지는 셈입니다.

이 결정 루프를 사람이 룰로 흉내 내면 룰의 개수가 기하급수로 늘어나고, 결국 유지보수 불가능한 상태가 됩니다. Agentic AI는 룰 대신 시스템 프롬프트 한 페이지로 같은 일을 합니다. 새로운 노이즈 패턴이 발견되면 프롬프트에 한 줄 추가하는 것이 전부고, 코드는 그대로입니다. 이것이 Agentic AI 구축이 단순 자동화보다 운영 비용이 빠르게 줄어드는 본질적인 이유입니다.

MCP 기반 AI 에이전트 아키텍처 3축: 수집-필터-배포

전체 구조는 세 개의 축으로 단순화할 수 있습니다. 수집(Ingestion), 필터(Curation), 배포(Distribution). 각 축은 LLM이 의사결정을 맡고, MCP 서버가 도구를 제공합니다.

```python

# news_agent/orchestrator.py (요지)

async def daily_news_pipeline(date: str) -> PipelineResult:

# 1) 수집: 에이전트가 소스 우선순위를 매번 재평가

sources = await agent.invoke(

prompt="오늘 어떤 소스에서 뉴스를 가져올지 골라라",

tools=[mcp.list_sources, mcp.fetch_url, mcp.search_arxiv],

)

# 2) 필터: 본문을 직접 읽고 채택/스킵 결정

candidates = []

for item in sources.items:

decision = await agent.invoke(

prompt=f"이 글을 바이브 코더에게 보낼지 결정하라",

context={"body": item.body, "history": recent_published},

tools=[mcp.summarize, mcp.deduplicate],

)

if decision.action == "PUBLISH":

candidates.append(decision.payload)

# 3) 배포: 카카오톡 채널 포맷으로 변환 후 발송

await mcp.kakao_channel.send(

room_id=KAKAO_OPENCHAT_ID,

messages=[render_card(c) for c in candidates[:5]],

)

return PipelineResult.success(len(candidates))

```

핵심은 세 축 모두에서 `mcp.*` 도구를 호출하는 주체가 사람의 룰이 아니라 에이전트라는 점입니다. MCP 기반 AI 에이전트의 강점은 도구의 명세(스키마)와 호출(invoke)이 표준화돼 있다는 데 있습니다. 우리는 카카오톡 발송, arXiv 검색, URL fetch, 요약, 중복 제거를 각각 다른 MCP 서버로 분리해두고, 에이전트는 그때그때 필요한 도구만 골라 씁니다. 새 소스를 추가할 때 에이전트 코드를 고치지 않고 MCP 서버를 하나 더 붙이면 끝납니다. 우리 팀은 이미 다른 글에서 Claude Code 호환 마이그레이션 도구와 같은 OSS를 공개해왔고, 이 뉴스 에이전트도 같은 MCP 생태계 안에서 동작합니다.

도구 분리에서 중요한 또 한 가지 원칙은 "에이전트가 절대 직접 접근하면 안 되는 권한은 MCP 서버 뒤로 숨기기"입니다. 카카오톡 발송 권한은 MCP 서버 내부의 secret으로만 풀리고, 에이전트는 `kakao.send(room_id, messages)`라는 호출만 알고 있습니다. 키 유출 시 회수 범위가 MCP 서버 한 곳으로 제한됩니다. Agentic AI 아키텍처에서 흔히 간과되는 보안 패턴인데, 에이전트가 자율적으로 행동할수록 권한 격리가 더 중요해집니다.

AI 뉴스 수집 자동화에서 카카오톡 채널 통합이 까다로운 이유

API 문서만 보면 카카오톡 채널 발송은 단순한 HTTP POST입니다. 그러나 실제로 매일 안정적으로 보내려고 하면 세 가지 함정이 있습니다. 첫째, 카카오 비즈니스 채널의 메시지 템플릿 사전 승인 — 자유 텍스트로는 발송이 불가능하고, 사전에 등록된 알림톡/친구톡 템플릿 변수 안에서만 동작합니다. 우리는 처음에 자유 텍스트로 만들었다가 발송 차단을 경험한 뒤, 템플릿을 "헤드라인 + 요약 3줄 + 링크" 구조로 고정했습니다.

둘째, 오픈채팅 기반 배포 vs 채널 기반 배포의 운영 비용 차이입니다. 오픈채팅은 봇 진입에 제약이 있지만 사용자 진입장벽이 낮고 알림이 자유롭습니다. 채널은 정식 비즈니스 인증이 필요하지만 메시지 수신 신뢰도가 더 높습니다. AI 뉴스 수집 자동화 사이드 프로젝트에서는 오픈채팅 + 외부 OAuth 봇 조합이 시작점으로 적절했고, 일일 활성 사용자가 200~300명을 안정적으로 넘어선 뒤에야 채널 인증을 신청하는 순서가 합리적이었습니다.

셋째, 발송 시각의 결정입니다. 너무 이르면 사용자가 안 깨어 있고, 너무 늦으면 출근길 직장인 독자를 놓칩니다. 우리는 매일 오전 7시 50분 발송으로 고정했는데, 이 시각은 가설이 아니라 1주일간 발송 시각을 30분 단위로 옮겨가며 카카오 진입 로그를 비교해 잡은 값입니다. 작은 운영 자동화 시스템조차 A/B 데이터 없이는 시간을 못 잡습니다.

일 300명까지 도달한 운영 안정화 과정

서비스 오픈 후 첫 2주는 매일 한 가지 이상이 망가졌습니다. 도구 호출 타임아웃, LLM이 발송 직전 생성한 카드의 글자 수 초과, 카카오 측 일시적 5xx, 중복 발송, 그리고 가장 흔했던 "에이전트가 어제 보낸 글과 같은 글을 다시 보내려는 시도". 우리는 이 모든 문제를 에이전트의 메모리 한 군데로 흡수했습니다. 즉, 최근 14일간 발송 이력(제목 + 요약 + URL의 임베딩)을 벡터 DB에 넣어두고, 새 후보가 들어오면 코사인 유사도 0.85 이상이면 자동 스킵합니다. 이 한 줄 규칙으로 중복 발송은 거의 사라졌습니다.

GitHub 스타가 꾸준히 올라간다는 사실은 단지 마케팅 지표가 아닙니다. 새로운 사용자가 코드를 직접 들여다보고 자기 환경에 포팅한다는 뜻이고, 그때마다 우리가 빠뜨린 엣지 케이스에 대한 PR과 이슈가 들어옵니다. Agentic AI 구축에서 가장 큰 안정화 동력은 우리가 만든 게 아니라 사용자가 보고한 실패 시나리오였습니다. 한 사용자는 "한국어 PDF의 표를 본문으로 그대로 갖다 넣었을 때 에이전트가 무한 루프에 빠진다"는 이슈를 제출했고, 우리는 그 케이스에 도구 호출 횟수 상한을 추가했습니다. 또 다른 사용자는 카카오톡 메시지 길이가 OS 버전마다 잘리는 위치가 다르다는 점을 알려줬고, 우리는 카드 길이를 보수적으로 줄였습니다.

운영 두 달 차에 일일 사용자 300명을 넘기면서 우리는 한 가지 원칙을 더 굳혔습니다 — Agentic AI는 출시일이 종료일이 아니라 시작일입니다. 매주 한두 가지씩 프롬프트를 보완하고, 한 달에 한 번씩 새 MCP 서버를 추가합니다. 사용자 입장에서는 같은 카톡 메시지가 매일 오는 것처럼 보이지만, 그 뒤의 의사결정 루프는 계속 다르게 동작합니다. 단순 RSS 봇이라면 두 달 뒤에는 정체됐을 시스템이, Agentic 구조 덕분에 두 달 뒤 오히려 정확도가 올라가는 구간에 들어섰습니다.

다음 단계: 우리 도메인에 Agentic AI를 도입하려면

당장 같은 패턴을 자기 도메인에 옮기려는 팀이라면 세 가지를 먼저 정하는 것을 추천합니다. (1) 에이전트가 다룰 도구를 MCP 서버로 분리할 것인지, 코드에 직접 박을 것인지 — 장기적으로는 분리하는 쪽이 항상 유리합니다. (2) 의사결정 루프의 "스킵 기준"을 처음부터 명문화할 것 — 무엇을 안 할지가 무엇을 할지보다 중요합니다. (3) 메모리 레이어를 어디에 둘 것인지 — 우리는 임베딩 DB로 충분했지만, 도메인에 따라 그래프 DB가 필요한 곳도 있습니다.

뉴스 에이전트 코드는 GitHub에 공개돼 있고, 카카오톡 채널에 직접 들어와 결과물을 받아보면서 시스템을 평가해보는 쪽이 가장 빠른 길입니다. 우리 팀이 Agentic AI를 다른 클라이언트 환경에 어떻게 이식했는지에 대한 케이스는 treesoop.com/blog에서 이어집니다. Agentic AI 구축은 모델 선택의 문제가 아니라 도구 설계와 운영 루프의 문제이고, 그 운영 루프를 어떻게 굴리느냐가 두 달 뒤 일 300명을 만들지 30명에서 멈출지를 결정합니다.