Artist Operations Agent
아티스트 공개 정보 수집·분석·검토를 지원하는 운영 Agent
소개
시도하고자 했던 것과 그 이유
이번 프로젝트는 "홈랩에서 24시간 멈추지 않는 AI 에이전트 운영 인터페이스 개발하기" 지피터스 스터디에 참여하면서 시작했습니다.
원래 특정 아티스트 관련 뉴스를 키워드 기준으로 수집해 뉴스레터를 만드는 기능을 이미 개발해 두고 있었습니다. 이 기능을 혼자 쓰고 끝내기보다, 아티스트 콘텐츠 운영 업무를 하는 사람에게 실제로 도움이 되는 형태로 확장해보고 싶었습니다.
아티스트 관련 정보를 운영 관점에서 관리하려면 다음과 같은 작업을 매일 반복해서 직접 확인해야 한다고 생각했습니다.
네이버에서 관련 키워드 뉴스 검색
기사 본문과 여러 매체의 보도 내용 확인
YouTube 댓글 반응 확인
과거 영상과 현재 영상의 반응 비교
나무위키 문서의 최근 변경사항 확인
변경된 내용이 중요한지 다시 판단
이 작업은 단순 검색보다 반복적인 운영 업무에 가깝습니다. 기존에 만들어둔 뉴스레터 기능을 확장하면 이런 반복 업무를 줄이는 데 실질적으로 도움이 될 수 있겠다고 판단했습니다.
그래서 뉴스를 비롯한 여러 공개 정보를 자동으로 수집하고, 분석 결과와 검토가 필요한 내용을 한 화면에서 확인할 수 있는 Artist Operations Agent를 만들었습니다.
이 프로젝트의 목표는 AI가 모든 판단을 대신하는 것이 아닙니다. 외부 정보를 수집하고 분석하되, 무엇이 확인된 내용인지, 무엇이 AI의 분석인지, 무엇을 사람이 다시 검토해야 하는지를 구분해서 보여주는 것입니다.
뉴스 기능은 기존에 만들었던 뉴스레터 프로젝트에서 발전시켰습니다.
네이버 뉴스 수집
→ 기사 본문 확인
→ 뉴스 요약
→ 관련 뉴스 그룹화
→ 결과 제공
기존 뉴스레터에서 경험한 날짜 범위 오류, 기사 본문 추출 실패, 뉴스 중복, LLM 환각과 출력 형식 오류 문제를 현재 운영 서비스에 반영했습니다.
진행 방법
전체 서비스 구성
서비스는 다음과 같은 네 가지 화면과 통합 Agent로 구성했습니다.
메인 대시보드
├─ 뉴스
├─ YouTube
├─ 나무위키
└─ 통합 Agent
각 기능은 외부 정보를 수집하고, 저장하고, 필요한 분석을 수행한 뒤 화면과 자연어 질문으로 확인할 수 있도록 구성했습니다.
외부 정보
→ 수집
→ 저장
→ 분석·변경 비교
→ 검토 대상 표시
→ 대시보드·Agent로 조회
1. 뉴스 모니터링
어떤 문제를 해결했나요
뉴스 검색 결과를 매번 직접 확인하지 않고, 특정 키워드의 새로운 기사를 정해진 범위로 수집해 핵심 내용을 빠르게 확인할 수 있도록 했습니다.
주요 기능
네이버 뉴스 API 기반 뉴스 수집
직전 KST 날짜 기준 뉴스 필터링
같은 기사 중복 저장 방지
언론사별 기사 본문 추출
기사 핵심 내용과 아티스트 관련 내용 요약
같은 이슈의 기사 그룹화
관련 기사를 묶어서 확인
뉴스 내용을 검색하고 Agent에게 질문
사용 흐름
네이버 뉴스 API
→ 원하는 날짜 범위만 선별
→ 이미 저장된 기사인지 확인
→ 기사 본문 추출
→ 기사 핵심 내용 요약
→ 관련 기사 그룹화
→ 검색 가능한 형태로 저장
→ 뉴스 화면과 통합 Agent에서 조회
기능을 만들면서 해결한 문제
네이버 API 결과를 그대로 저장하지 않고 기사 발행 시각을 다시 확인했습니다. 이를 통해 다른 날짜의 기사가 섞이는 문제를 줄였습니다.
언론사마다 본문 구조가 달라 여러 본문 탐색 기준을 순서대로 적용했습니다. 특정 언론사의 구조가 달라져도 전체 수집이 중단되지 않도록 했습니다.
또한 LLM이 기사에 없는 내용을 추가하지 않도록 기사에 실제로 적힌 사실 중심으로 요약하도록 구성했습니다.
2. YouTube 반응 모니터링
어떤 문제를 해결했나요
YouTube 댓글을 단순히 많이 읽는 것이 아니라, 현재 활동 중인 영상과 과거 영상을 구분하고 댓글 반응을 운영 관점에서 확인하고자 했습니다.
주요 기능
채널 영상 수집
현재 영상과 과거 영상 분리
일반 영상과 Shorts 분리
댓글 수집 및 중복 방지
긍정·중립·부정 반응 분류
댓글 주제와 위험도 분류
반복적으로 등장하는 댓글 작성자 확인
사람이 검토할 후보 표시
검토 결과 저장
사용 흐름
YouTube 채널
→ 영상 목록 확인
→ 일반 영상·Shorts 구분
→ 현재 영상·과거 영상 구분
→ 댓글 수집
→ 댓글 반응 분석
→ 작성자별 반복 패턴 집계
→ 검토가 필요한 후보 표시
현재 영상과 과거 영상 분리
현재 영상은 최신 반응을 확인하기 위한 영역으로 사용하고, 과거 영상은 누적된 반응과 통계를 확인하는 영역으로 분리했습니다.
이를 통해 다음 질문에 각각 답할 수 있도록 했습니다.
현재 팬 반응은 어떤가요?
과거 영상에서 반복되는 반응은 무엇인가요?
일반 영상과 Shorts의 반응 차이가 있나요?
검토 기준
댓글 작성자의 실제 신원을 추정하지 않습니다. 공개된 YouTube 채널 ID를 기준으로 반복적인 행동 패턴을 확인하고, 사람이 검토할 후보를 표시합니다.
즉, AI가 누군가를 악성 사용자로 확정하는 기능이 아니라 운영자가 추가 확인할 대상을 좁혀주는 기능입니다.
3. 나무위키 문서 변경 모니터링
어떤 문제를 해결했나요
나무위키 문서의 현재 내용만 보는 것이 아니라, 이전에 확인했을 때와 비교해 어떤 부분이 바뀌었는지 확인하고자 했습니다.
주요 기능
문서 snapshot 저장
이전 snapshot과 현재 내용 비교
추가·수정·삭제된 문단 확인
루트 문서와 하위 문서 구조 표시
실제 문단 제목 기준으로 변경 내용 표시
변경 중요도와 검토 필요 여부 분석
문서 내용 검색
마지막 확인 시각과 문서 snapshot 시각 분리
사용 흐름
등록된 문서 확인
→ 현재 문서 수집
→ 이전 snapshot과 비교
→ 변경된 문단 확인
→ 변경 내용 요약
→ 중요도와 검토 필요 여부 표시
→ 문서 구조와 변경 근거 조회
단순히 "문서가 변경되었습니다"라고 표시하지 않고 다음과 같이 확인할 수 있도록 했습니다.
어떤 문서가 변경되었나요?
어떤 하위 문서인가요?
어떤 문단 제목이 바뀌었나요?
추가·수정·삭제 중 무엇인가요?
언제 마지막으로 확인했나요?
나무위키 내용은 공식 자료로 자동 확정하지 않고, 변경된 내용을 참고 정보와 검토 대상으로 제공합니다.
4. 통합 Agent
뉴스·YouTube·나무위키 화면을 각각 사용할 수도 있지만, 자연어로 질문할 수 있는 통합 Agent를 추가했습니다.
예시:
어제 아티스트 관련 뉴스 정리해줘
현재 영상 댓글 반응 알려줘
최근 나무위키에서 변경된 내용이 있어?
질문 내용에 따라 관련 기능으로 연결합니다.
뉴스 질문
→ 뉴스 검색 결과와 요약 확인
YouTube 질문
→ 현재 영상과 댓글 집계 확인
나무위키 질문
→ 문서 검색 또는 변경 내역 확인
통합 Agent의 목적은 모든 데이터를 하나의 답변으로 섞는 것이 아닙니다. 질문에 맞는 데이터 영역을 선택하고, 해당 영역의 저장된 정보와 출처를 바탕으로 답하는 것입니다.
5. 공통 수집 작업 관리
뉴스·YouTube·나무위키 수집 버튼을 여러 번 누르면 같은 시간에 여러 작업이 실행될 수 있습니다.
이를 방지하기 위해 수집 작업을 하나의 공통 큐에서 순차 실행하도록 했습니다.
수집 요청
→ 대기
→ 실행
→ 완료 또는 실패
이미 다른 작업이 실행 중이면 새 작업을 바로 실행하지 않고 현재 작업 상태를 안내합니다.
이 기능을 통해 외부 API와 LLM을 동시에 과도하게 호출하거나, 여러 수집 결과가 서로 섞이는 문제를 줄였습니다.
6. 관리자 인증과 읽기 중심 화면
기본 화면은 조회 중심으로 구성했습니다.
수집이나 검토처럼 실제 상태를 변경하는 작업은 관리자 인증 후에 사용할 수 있도록 분리했습니다.
일반 사용자
→ 수집 결과와 분석 결과 조회
관리자
→ 뉴스·YouTube·나무위키 수집 실행
→ 검토 결과 저장
운영 도구에서는 기능을 많이 제공하는 것보다, 실수로 수집을 반복 실행하거나 검토 결과를 잘못 바꾸지 않도록 하는 것이 중요하다고 판단했습니다.
결과와 배운 점
결과
현재 다음 기능을 하나의 서비스에서 확인할 수 있습니다.
뉴스 수집·요약·그룹화·검색
YouTube 현재·과거 영상과 댓글 반응 분석
나무위키 문서 snapshot과 변경 비교
통합 자연어 Agent
공통 수집 큐
관리자 인증
Docker 실행
현재 로컬 테스트 결과는 다음과 같습니다.
110 passed, 1 warning
다만 실제 외부 API, 운영 PC, 모바일 접속, 장시간 스케줄러 실행까지 포함한 최종 운영 검증은 별도 단계로 남아 있습니다.
가장 크게 배운 점
1. AI보다 먼저 데이터 흐름을 확인해야 했습니다
좋은 프롬프트를 작성하는 것만으로는 충분하지 않았습니다.
잘못된 데이터 수집
→ 잘못된 본문
→ 잘못된 요약
→ 잘못된 판단
이 흐름을 경험한 뒤, LLM보다 먼저 수집 범위와 원문 데이터가 맞는지 확인하게 되었습니다.
2. LLM 결과를 그대로 믿으면 안 됩니다
LLM이 JSON 형식으로 답하도록 요청해도 형식이 깨지거나 ID가 누락될 수 있었습니다.
그래서 LLM 결과는 사람이 입력한 외부 데이터처럼 검증해야 한다고 배웠습니다.
3. "없음"과 "실패"를 구분해야 합니다
검색 결과가 없다고 해서 항상 관련 내용이 없는 것은 아닙니다.
정말 내용이 없음
본문 추출 실패
LLM timeout
RAG에 아직 색인되지 않음
외부 API 장애
이 상태를 모두 같은 문장으로 표시하면 운영자가 잘못 판단할 수 있습니다. 따라서 데이터 부재와 시스템 실패를 구분해서 보여주는 것이 중요했습니다.
4. 자동화와 자동 판단은 다릅니다
수집과 분류는 자동화 할 수 있지만, 모든 판단까지 AI에게 맡기지는 않았습니다.
특히 YouTube 댓글 작성자 분석은 공개 ID 기반 검토 후보를 만드는 기능이며, 실제 신원이나 악성 여부를 확정하는 기능이 아닙니다.
나만의 팁
처음에는
수집 → 저장 → 조회까지만 만든 뒤 분석 기능을 추가합니다.LLM 응답에는 반드시 실패 처리와 결과 검증을 둡니다.
기능을 하나로 합치기보다 현재·과거, 일반 영상·Shorts처럼 사용자가 헷갈리는 영역을 분리합니다.
날짜와 시간은 처음부터 KST 기준을 명시합니다.
운영 화면은 읽기 전용을 기본으로 하고, 상태 변경 기능은 관리자 인증 뒤에 둡니다.
외부 서비스가 포함된 프로젝트는 로컬 테스트 통과와 실제 운영 검증을 구분해서 기록합니다.
시행착오
기존 뉴스레터와 현재 서비스의 차이
기존 뉴스레터는 다음 흐름이었습니다.
PostgreSQL
→ HTML 뉴스레터
→ 네이버 SMTP
→ Windows 작업 스케줄러
현재 서비스는 다음 흐름으로 확장했습니다.
FastAPI
→ SQLite·Chroma
→ 웹 대시보드
→ 공통 수집 큐
→ Docker
두 프로젝트의 기능을 동일하다고 설명하지 않고, 기존 뉴스레터에서 얻은 문제 해결 경험이 현재 서비스의 뉴스 기능으로 발전했다고 정리했습니다.
