요즘 AI 에이전트라는 말을 심심치 않게 들을 수 있습니다. 그런데 막상 내 일에 맞는 에이전트를 직접 만들어 보려고 하면 어디서부터 시작해야 할지 막막합니다. 기사나 SNS에 소개되는 사례는 대부분 개발팀이 있는 큰 조직의 이야기이고, 비전문가나 작은 기업이 그대로 따라 하기는 현실적으로 만만치 않습니다. 직접 개발하려면 비용과 시간이 들고, 어렵게 만들어도 그 뒤의 유지보수가 더 큰 부담으로 남습니다.
다행히 최근에는 Claude 데스크톱 앱이나 AI 브라우저 같은 시중의 AI 앱들이 워낙 좋아졌습니다. 이 앱들을 잘 엮기만 해도 쓸 만한 에이전트 환경을 충분히 만들 수 있습니다.
이번 글에서는 AI 및 Tech 관련 뉴스를 모아 정리하고, 그 결과를 블로그와 SNS에 발행하는 뉴스 브리핑 에이전트를 만든 과정을 정리했습니다. 별도 앱을 개발하지 않고 Claude 데스크톱 앱과 AI 브라우저 Aside 두 개에 역할을 나눠 맡겼습니다. 직접 작성한 코드는 없고, 모든 것은 바이브 코딩 방식으로, 대화로 만들었습니다.
미리 말씀드리면 오늘 보여 드릴 구조는 완벽하지 않습니다. 필요할 때마다 만들고 넓혀 가다 보니 나온 형태입니다. 다만 비전문가나 작은 조직에서 일을 하다 보면 아마 비슷한 과정과 모양에 이르게 될 것이라고 생각합니다. 그런 의미에서 짧은 기간 동안의 경험을 정리해 보았습니다. 지난 글 「바이브 코딩, SNS 분석 에이전트, 필요한 앱은 만들어 쓰자」가 필요한 앱을 직접 만드는 이야기였다면, 이번에는 외부 앱들을 역할별로 엮어서 필요한 시스템을 구축하는 이야기입니다.
배경
IT 기업에 근무하면 쏟아지는 기술 정보를 따라가기 위해 매일 AI와 기술 뉴스를 챙겨 보아야 합니다. 국내외 매체들을 돌다 보면 가끔은 같은 소식을 몇 번씩 읽게 되고, 또 며칠째 이어지는 소식은 기존에 무슨 내용까지 나왔는지를 기억해서 앞뒤를 이어 생각해야 합니다. 이런 일이 하루 이틀은 모르겠지만 매일 반복하기는 쉽지 않습니다.
그래서 뉴스 수집, 중복 제거, 후속 보도 연결 등을 자동화해 주는 뉴스 브리핑 에이전트를 만들어 보기로 했습니다. 처음에는 같은 소식은 하나로 묶고, 중요한 순서대로 보고, 이미 본 소식은 달라진 점만 알려 주는 정도면 충분하다고 생각했습니다.
하지만 일을 진행하다 보니 요구사항은 점점 늘어나더군요. 취합한 정보를 여러 사람과 나눌 필요가 생겼습니다. 그래서 뉴스 브리핑 에이전트가 수집해 정리한 뉴스를 여러 곳에 발행하는 기능도 추가했습니다. 기본적으로 하루 동안의 기사를 보고서 형태로 만들어 블로그에 게시하고, 발행처별로 1,500자 요약이나 500자 단위의 짧은 글로 올립니다. 이 과정에서 채널마다 독자와 분량이 달라 같은 내용을 조금씩 다듬어야 했습니다.
결국 필요한 일은 두 가지였습니다. 흩어진 정보를 잘 모으고 정리하는 일, 그리고 모은 정보를 채널에 맞춰 잘 내보내는 일입니다.
시스템 개요
이 시스템을 한마디로 정리하면, 코드 작성이나 시스템에 대한 사전 공부 없이 순수 대화만으로 기본 AI 앱 두 개(Claude, Aside)에 역할을 나눠 만든 에이전트 시스템입니다.
Claude는 하루 두 번 뉴스 21곳을 모아 선별하고 요약해 Markdown 파일로 정리해 둡니다. Aside는 그 결과로 블로그, 리멤버, Threads 게시물을 준비하고, 사용자의 지시가 있으면 최종 발행합니다. 사람은 휴대폰으로 결과를 받고 지시를 보냅니다. 이렇게 발행된 블로그 브리핑은 Daily Briefing에서 매일 보실 수 있습니다.
별도로 추가한 서버는 없습니다. 늘 켜져 있는 Mac mini 한 대가 서버 역할을 하고, 두 AI 앱과 모든 데이터가 Mac mini에 모여 있습니다. 외부로 나가는 통로는 텔레그램 봇 하나이고, 안으로 들어오는 통로는 휴대폰에서 쓰는 Claude의 리모트 컨트롤 기능입니다.
물론 앱을 직접 개발하지 않았다고 해서 코드가 없는 것은 아닙니다. 기사 수집, 본문 읽기, 보고서 생성, 텔레그램 발송, PDF 변환, Aside 알림처럼 매번 똑같이 반복되는 기능은 AI 앱들이 작은 도구로 만들어 이용합니다. 파이썬 도구 총 9개와 Aside가 만든 JS 스크립트 하나입니다. 새 기능이 필요할 때마다 “이런 게 필요해”라고 요청하면 도구가 늘어 갔습니다. 다만 이 도구들은 따로 실행되는 앱이 아닙니다. AI가 작업 지침을 읽고 필요할 때 그에 맞는 도구를 골라 실행하는 방식입니다.
구축 과정
구축은 약 2주 정도 진행했습니다. 단계별로 중요한 요청과 결정을 정리했습니다.
1단계. 뼈대 만들기 (1일)
사전 준비
- “이런 작업은 처음이고 기술적인 방법은 잘 모르니, 함께 의논하면서 진행해줘”로 시작
- 시범으로 국내외 매체 10곳을 선정하고 접속 가능 여부부터 점검. 10곳 모두 기사 목록(RSS)과 본문 수집은 가능
- AI 접근을 거절한 3곳(The Verge, Ars Technica, TechCrunch)은 본문 대신 매체가 배포한 제목과 요약만 쓰기로 결정
시범 적용 및 형식 결정
- 당일 기사를 수동으로 모아 478건 중 같은 소식을 묶고 24건으로 정리한 견본 생성
- 결과를 보며 형식 확정.
중요한 순서로 “먼저 볼 소식”과 “이어서 볼 소식”으로 구분하고, 항목마다[본문],[RSS]로 근거 표시
시스템 인터페이스 결정
- 저장 방식은 Claude가 처음에 날짜별 Markdown 파일에 JSON 파일 두 개로 이력을 관리하는 방식을 제안.
기사가 누적되면 빠른 인덱싱이 필요하다는 판단으로 DB 사용을 다시 검토해, 내용은 Markdown, 색인과 이력은 SQLite로 결정 - 기사 전달 방법은 카카오톡, 웹 페이지, 이메일 등 5가지 선택지 중 텔레그램으로 결정
- 예약 자동 실행은 2번 실패 후 성공.
1차는 예약 실행 명령마다 승인이 필요해 멈춤(“항상 허용”은 그 명령 한 줄만 저장), 2차는 예약이 처음 만든 폴더에 묶여 있어 폴더를 옮기자 실행되지 않음, 3차는 허용 명령을 미리 정하고 예약을 새 폴더에서 다시 만들어 성공 - 하루 두 번(9시, 17시) 수집과 발송으로 확정하고, 주요 소식은 본문을 3,000자까지 읽도록 조정
2단계. 시범 운영 (9일)
시범 운영 준비
- 상시 동작 중인 Mac mini로 실행 환경 이전.
새 세션은 인수인계 문서를 읽고 이어받고, 텔레그램 토큰은 사용자가 직접 옮김 - 매체를 10곳에서 20곳으로 확대.
공식 블로그 3곳과 해외 AI 전문 매체를 더하고, GeekNews는 다른 매체의 뉴스를 모아 소개하는 곳이라 일부 겹치지만, 다루는 범위가 넓어 포함하기로 결정 - 스크립트 7개(수집, 본문 읽기, DB 조회, 보고서 생성, 발송, 실행 기록, 공통 모듈, 약 900줄)를 전체 점검.
버그 2건과 이슈 사항을 찾아 수정 - 전송 실패 시 재전송은 전체를 다시 보내기로 결정
채널 추가
- 수집된 뉴스를 다른 채널(Threads)로 전달하기 위한 요약 기능 추가
- 요약의 형식을 확정하기 위해 열다섯 번 가량 수정.
목록형에서 기사체로, 1편에서 최대 3편(편당 500자)으로 바꾸고 번호, 제목 줄, 작은따옴표, 영어 병기 규칙 추가
형식 및 범위 조정
- 운영해 보면서 발송 형식을 조정.
Threads용 글은 편마다 1통씩, 주요 소식과 나머지 소식은 따로 보내고 첨부는 PDF로 변경.
요약은 30% 줄이고 항목은 30% 늘림(주요 소식 8건에서 10건, 나머지 16건에서 21건)
3단계. 추가 발행 자동화 (3일)
발행 대상 분석 및 발행 자동화 준비
- Aside 브라우저를 통해 블로그에 자동 발행이 가능한지 점검
- 블로그는 전날 오후판과 당일 아침판을 합쳐 하루 한 편 발행하기로 결정.
첫 글은 두 판 55건을 53개 항목으로 정리했고, 사용자가 손본 수정본과의 차이(목차, 구분선 6개, 카테고리, 섹션 이름)를 Aside가 뽑아 규칙으로 반영 - SEO와 태그를 포함하고 대표 이미지(1200×630 JPG) 생성도 추가
- 불필요한 설명을 제거해 하나의 기사로 통합하고, 기사 제목도 한눈에 보기 편하도록 30자 이내로 축약
- 유사 과정을 거쳐 발행 대상 추가(리멤버), 1,500자 요약 게시 시작.
이후 1,500자를 꽉 채우도록 소식 수를 5개에서 6~8개로 늘림 - 매체 케이벤치를 추가해 21곳으로 확대
작업 규칙 정리
- Aside 작업 규칙은 Aside 전용 인수인계 문서로 분리하고, 다른 에이전트가 따르지 않도록 명시
- Aside 실행도 상시 운영 중인 Mac mini로 이동
4단계. 두 에이전트 연동 (1일)
두 에이전트를 연동하여 작업 자동화
- Claude가 텔레그램 발송 직전에 Aside에 상태를 알리도록 결정.
같은 PC 안에서 이루어지는 일이므로 간단한 상태 알림으로 진행 - Aside는 알림을 받으면 수신을 먼저 알리고, 준비 완료 알림이면 Threads에 1~3편을 임시저장한 뒤 같은 텔레그램 대화방으로 완료 보고
에이전트 간 상호 리뷰
- Aside의 텔레그램 알림 스크립트는 Aside가 직접 작성.
Claude가 점검해 고칠 점 3가지를 찾고, 그중 2가지는 수정 지시문을 써서 Aside에 전달
최종 운영 준비
- 시험판(2편)으로 Claude 알림부터 Threads 임시저장, 완료 보고까지 전체 흐름 확인
- Aside 아침 작업을 매일 9시 30분 반복으로 전환. 블로그, 리멤버, Threads 초안까지만 자동으로 하고, 발행은 지시가 있을 때 블로그, 리멤버, Threads 순서로 진행
- 모든 글 제목의 “AI & 기술”을 “AI & Tech”로 통일
작업 규모 및 환경
|
항목
|
내용
|
|---|---|
|
기간
|
2주
|
|
대화 세션
|
Claude 3개, Aside 3개
|
|
컴퓨터
|
2대: MacBook에서 작업, Mac mini에서 운영
|
|
수집 매체
|
10곳 → 21곳
|
|
처리량
|
한 번 실행 기사 약 300여 건 → 소식 20여 건, 약 5분
|
|
블로그 글
|
하루 한 편, 소식 약 50건
|
|
생성된 코드
|
파이썬 도구 9개, Node 스크립트 1개, 단 직접 작성 0줄
|
|
사용 도구
|
Claude 데스크톱 앱 및 리모트 컨트롤,
Aside(ChatGPT 계정 OAuth 연결), 텔레그램 봇, GitHub 비공개 저장소, Obsidian 등 |
|
추가 설치
|
없음
|
구성도
본 시스템의 핵심은 두 에이전트의 분업입니다.
Claude는 뉴스 매체에서 기사를 모아 공유 폴더에 보고서와 Threads용 글을 쓰고, Aside에는 “준비됐다”는 상태만 알립니다. Aside는 그 폴더를 읽고, 로그인된 브라우저로 블로그와 SNS에 글을 올립니다. 두 에이전트 사이에 오가는 정보는 시스템 내의 파일들과 간단한 알림뿐입니다.
축적한 자료는 매번 GitHub 비공개 저장소에 백업됩니다. 모든 내용이 Markdown이라 Obsidian에서 바로 검색할 수 있고, 추후 llm-wiki의 재료로 이용할 예정입니다.
작업 흐름도 및 적용 사례
아침 8시 50분에 Claude가 아침판을 만듭니다. 수집부터 선별, 보고서, 텔레그램 발송, 백업까지 사람 없이 진행하고, 발송 직전에 Aside에 알립니다. Aside는 알림을 받아 Threads용 글을 임시저장하고 완료 알림을 텔레그램으로 보냅니다.
9시 30분에는 Aside가 루틴 작업을 시작합니다. 전날 오후판과 당일 아침판을 합쳐 블로그 임시글, 리멤버 초안, Threads 소개 글을 준비합니다. 사용자는 휴대폰으로 초안 보고를 받고, 원할 때 “발행해”라고 지시합니다. 그러면 블로그, 리멤버, Threads 순서로 발행됩니다. 블로그를 먼저 공개해야 다른 채널의 링크 미리보기가 생성되므로, 순서가 중요합니다.
오후 4시 50분에는 오후판이 아침판과 같은 절차로 만들어지고, Aside는 이번에도 Threads용 글을 임시저장한 뒤 완료를 알립니다.
텔레그램 메시지 사례는 아래와 같습니다.
다음은 실제 게시글 사례입니다. (좌측: 스레드, 우측: 리멤버, 블로그 게시글)
특징 및 가이드
본 시스템을 개발하면서 중요하게 생각한 특징 및 가이드를 바이브 코딩 관점에서 중요한 순서로 정리했습니다.
A. 대화 기반 개발
- 의논으로 시작: 기술을 잘 모른다고 밝히며 시작했고, AI가 선택지와 장단점을 제시하면 사람이 골랐습니다.
- 견본을 보고 고치기: 명확한 설계서 대신 결과물을 보며 형식을 고쳐 나갔습니다. (Threads용 글은 15회 이상)
- 대화로 지침 작성: 정해진 내용은 바로 작업 지침 문서에 적혀 다음 실행부터 적용됩니다. 지침 문서가 곧 명세서입니다.
- 사람은 편집장이자 감독관: 사람은 목적 설명, 선택, 승인, 비밀 값 입력을 맡고, AI의 제안을 판단하는 역할을 합니다.
- 에이전트끼리 서로 검토: Aside가 만든 코드를 Claude가 점검하고, Claude가 쓴 수정 지시를 Aside가 반영했습니다.
B. 전용 앱 대신 AI 앱으로
- AI 앱의 예약 기능이 핵심 엔진: API 호출 프로그램 대신 Claude 데스크톱 앱의 예약 작업으로 지침을 읽고 실행합니다.
- 필요 기능은 AI가 도구로 구현: 수집, 발송, 변환처럼 반복되는 기능은 작은 코드로 만들고, 정해진 시각에 실행합니다.
- 웹 작업은 브라우저 에이전트가: 블로그와 SNS 게시는 API 연동 없이 Aside 브라우저에서 사람처럼 처리합니다.
- 이용 중인 컴퓨터가 서버: Mac mini 한 대에 두 AI 앱과 자료를 모아 서버 부담과 동기화 문제를 없앴습니다.
- 추가 설치 없음: 파이썬 기본 라이브러리와 이미 설치된 프로그램만 써서 환경 관리 부담이 없습니다.
- 단순 작업은 OS 기능 활용: 단순 반복 작업은 macOS 예약 기능에 맡겨 AI 사용량을 아꼈습니다.
C. 역할 분담과 소통
- 수집은 Claude, 발행은 Aside: 수집 쪽에는 브라우저 권한을 주지 않고, 로그인이 필요한 일은 모두 Aside가 맡습니다.
- 두 가지 실행 방식: Aside는 매일 정해진 시각에 작업하며, 하루 두 번은 Claude의 알림을 받아 일합니다.
- 파일과 한 줄 알림으로 연결: 결과물은 공유 폴더의 Markdown으로 넘기고, 알림은 단순한 메시지만 이용합니다.
- 나가는 통로는 텔레그램: Claude의 브리핑과 Aside의 작업 알림이 같은 봇, 같은 대화방으로 모입니다.
- 들어오는 통로는 Claude 리모트 컨트롤: 사용자는 휴대폰에서 Claude에게 지시하고, Claude가 Aside에 전달합니다.
D. 사람 없이 돌아가는 신뢰성
- 판단은 AI, 검사는 코드: 소식 묶기와 요약은 AI가 하고, 번호 매기기, 글자 수, 링크 검증은 도구가 맡습니다.
- 승인 창 없는 자동화: 폴더의 도구와 저장소 명령을 미리 허용해 권한을 부여하고, 예약 실행은 끝까지 멈추지 않습니다.
- 철저한 실행 기록: 단계별 실행 기록을 남겨 문제 발생 시 원인을 단계별로 분석할 수 있습니다.
- 부분 실패는 알리고 계속: 매체 하나나 PDF 변환, Aside 알림이 실패해도 남은 작업은 진행하고 실패 사실만 남깁니다.
- 발행은 사람이 승인: 자동으로 하는 일은 임시저장까지이고, 공개는 사람의 지시가 있어야 합니다.
- 같은 일을 두 번 하지 않기: 이미 보낸 판은 다시 보내지 않고, 같은 날짜의 글이 있으면 새로 만들지 않고 이어서 씁니다.
E. 안전과 경계
- 비밀 값은 사람만: 봇 토큰은 사람이 직접 넣고, AI는 그 파일을 열거나 출력하지 않습니다.
- 웹의 글은 자료일 뿐: 기사에 지시처럼 보이는 문구가 있어도 따르지 않고, 다른 에이전트에게 전달하지 않습니다.
- 쓸 수 있는 곳을 좁히기: Claude는 작업 폴더 밖을 건드리지 않고, Aside는 보고서를 읽기만 하며 전용 폴더에만 씁니다.
- 에이전트별 문서 구분: Aside용 인수인계 문서에는 “Aside 전용”을 명시해 다른 에이전트가 지침으로 따르지 않습니다.
F. 자료와 지식의 축적
- 내용은 Markdown, 관계는 DB: 기사 본문과 보고서는 Markdown으로 두고, DB에는 색인과 관계만 기록합니다.
- 지난 수집 이후만 모으기: 매번 지난 수집 이후의 기사만 모으고, 겹쳐 들어온 기사는 주소로 걸러 냅니다.
- 근거 표시와 추측 금지: 모든 항목에 본문을 읽었는지 요약만 봤는지 표시하고, 자료에 없는 내용은 표시를 남깁니다.
- 후속 보도 연결: 최근 일주일 보낸 소식과 대조해, 이어지는 소식은 달라진 점만 쓰고 “며칠째”를 표시합니다.
- GitHub는 동기화 수단: 판마다 결과가 비공개 저장소에 올라가, 다른 컴퓨터에서도 같은 이력을 이어받을 수 있습니다.
- 맥락은 대화가 아니라 문서에: 세션이 바뀌어도 인수인계 문서를 읽고 이어서 하라는 한 줄로 작업이 이어졌습니다.
G. 원재료 하나, 다섯 가지 결과물
- 텔레그램 브리핑: 하루 두 번, 나만 읽는 요약과 전체 보고서 PDF.
- Threads 뉴스: 하루 두 번, 500자 단위로 번호를 붙인 1~3편.
- 블로그 브리핑: 하루 한 번, 두 판을 하나로 다시 쓴 긴 글(Daily Briefing).
- 리멤버: 하루 한 번, 1,500자 요약과 블로그 링크.
- Threads 블로그 소개: 하루 한 번, 500자 본문과 블로그 링크 답글.
배운 점
가장 중요한 것은 처음부터 설계하지 않아도 된다는 점입니다. 당일 기사로 한 번 수동으로 돌려 보고, 결과를 보며 고친 뒤 자동 실행을 붙였습니다. 무엇을 원하는지 말로 정확히 설명하기는 어렵지만, 결과물을 보면 무엇이 아닌지는 바로 알 수 있습니다. 그렇게 정해진 것을 그 자리에서 지침 문서에 적어 두는 방식이 설계서를 먼저 쓰는 것보다 빨랐습니다. 지금의 구조도 처음부터 그린 것이 아니라 필요할 때마다 넓혀 가며 생긴 것입니다.
막상 어려웠던 것은 기능이 아니라 실행 환경이었습니다. 명령마다 뜨는 승인 창, 처음 만든 폴더에 묶인 예약, 앱 안의 실행 격리는 모두 실제로 사람 없이 돌려 보기 전에는 드러나지 않았습니다. AI 앱으로 에이전트를 만든다면, 기능을 늘리기 전에 “사람 없이 끝까지 잘 실행되는가”부터 시험해 보는 것이 중요하다고 생각합니다.
AI를 믿는 방식도 다시 생각하게 됐습니다. 첫 보고서에서 링크 하나가 잘못 들어간 뒤로는, 판단은 AI에게 맡기되 형식과 검증은 코드가 막아 주도록 구조를 바꿨습니다. git이 실행되지 않았을 때 Aside는 처음에 개발 도구를 다시 설치하라고 했지만, 원인은 샌드박스였습니다. AI가 내놓은 설명을 그대로 받기보다 “왜 그런지 확인해 달라”고 되묻는 것이 사람이 맡아야 할 중요한 역할이라고 생각합니다.
마지막으로, AI 앱 기반의 에이전트는 세션이 끊기는 것을 전제로 만들어야 했습니다. 2주 남짓 동안 폴더를 다섯 번 옮기고 컴퓨터를 바꾸고 대화 세션이 여섯 개로 나뉘었지만, 작업은 순조롭게 이어졌습니다. 결정 사항이 대화가 아니라 문서에 남아 있었기 때문입니다.
맺음말
이번에 만든 뉴스 브리핑 에이전트는 완성된 제품이 아닙니다. 컴퓨터와 AI 앱이 켜져 있어야 하고, 실행 환경이 바뀌면 승인이나 인증 문제로 멈추기도 합니다. 그래도 별도 개발 없이, 기본 AI 앱 두 개와 텔레그램, 휴대폰만으로 매일 돌아가는 체계를 만들 수 있었습니다.
돌아보면 중요한 것은 앱을 만드는 기술보다 일을 나누는 방식이었습니다. 무엇을 AI에게 맡기고 무엇을 코드에 맡길지, 어느 에이전트가 어디까지 할지, 사람은 어디에서 개입할지를 정하는 일입니다. 작은 조직의 에이전트는 아마 이런 모양에서 시작해 필요한 만큼 자라 갈 것이라고 생각합니다.
잘 만든 앱 하나보다 잘 나눈 역할 몇 개가 작은 조직의 에이전트가 됩니다
ChulJoo Kim (김철주)
※ 참고문헌
- ChulJoo Kim, 「바이브 코딩, SNS 분석 에이전트, 필요한 앱은 만들어 쓰자」, ckarch.kr, 2026. 10.
- Anthropic, 「Download Claude」, Anthropic, 2026.
- Aside, 「Aside: AI browser」, Aside, 2026.
ckarch.kr
© 2026
is licensed under
CC BY-NC-SA 4.0
