Aside로 업계 뉴스 브리핑 완성하기 — 수집·요약에 확인하는 스킬을 붙였다

뉴스를 모으고 요약해 전달하는 자동화는 이미 있었다. 여기에 Aside로 만든 확인 스킬을 붙여 실제 페이지를 읽혔더니, ‘OTT 누적 11개’라고 표시한 화면에 카드가 9개만 있었다. 이번에는 그 차이를 찾고 수정 후보를 다시 확인하는 과정까지 진행했다.

소개

처음에는 드라마 반응과 업계 뉴스를 모아서 매거진 형태로 읽는 작업이었다. 반복 실행은 n8n이라는 자동화 도구와 수집 코드가 맡고, 모인 자료를 읽어 분류하고 요약하는 일은 별도의 스킬에 맡겼다.

이미 사용하던 drama-monitor-summarize는 뉴스 분류와 헤드라인 선정, 출처 매핑, 작성 후 자체 점검을 순서대로 수행하는 스킬이다. 기사 제목을 그대로 반복하지 않고 새 정보를 요약하도록 하는 규칙도 들어 있다.

이후에는 공개할 수 있는 항목만 골라 웹페이지와 전달 문안을 만드는 공유판을 만들었다. 혼자 읽는 자료에서 다른 사람이 읽는 결과물로 범위가 넓어진 셈이다.

Aside를 이번에 처음 사용한 것은 아니다. 이전에는 X 반응을 브라우저에서 수집하는 데 썼고, X 수집은 10월 초에 중단했다. 이번에는 수집에서 한 단계 더 나아가, 독자가 받는 결과를 읽고 확인하는 역할을 맡겼다.

지난주 과제는 부동산 매물 탐색이었고, 이번 주에는 업무를 미디어 브리핑으로 바꿨다. 지난주에 쓰던 확인 방식 두 가지는 그대로 가져왔다. 목록에 적힌 값만 믿지 않고 실제 화면을 읽는 것, 그리고 어느 시점 기준의 값인지 밝히는 것이다.

이 글은 뉴스 요약이나 정기 보고서를 이미 만들고 있지만, 전달 직전에 무엇을 확인해야 할지 매번 다시 설명하는 분들에게 참고가 될 것 같다.

진행 방법

이번 주 수업은 내장 스킬을 써보고, 반복되는 작은 단계를 사용자 스킬로 만든 뒤, 실제 도구 호출까지 확인하는 내용이었다. 기존 자동화 전체를 옮기기보다 ‘브리핑 발송 전 확인’ 한 단계를 골랐다.

자연어 요청은 Aside CLI를 통해 Aside 에이전트에 전달했다. CLI는 터미널에서 Aside를 부르는 경로다. REPL은 브라우저에 명령을 실행해 화면과 값을 확인하는 기능이고, MCP는 다른 에이전트에서 Aside의 도구를 연결해 사용하는 경로다. 앱 채팅 입력창을 직접 조작한 실험은 아니다.

세 경로는 브리핑 점검 업무 안에서 한 단계씩 맡았다. CLI로 보낸 요청은 Aside 세션의 실행 기록으로, REPL·MCP는 호출과 반환값으로 남겼다.

여기서 한 번 막혔다. MCP로 처음 셌을 때는 헤드라인이 31개로 나왔다. 세는 범위를 넓게 잡아서 나온 값이었다. REPL에서 범위를 헤드라인 목록으로 좁혀 다시 세니 7개였고, 31은 결과에 쓰지 않았다.

1. 내장 스킬부터 비교했다

업계 뉴스의 공식 발표 후보를 찾는 작은 작업으로, 같은 검색어를 두 방식으로 실행했다. 한쪽은 기본 브라우저 도구로 Google 검색결과를 읽었고, 다른 쪽은 Aside의 내장 google-search 스킬을 사용했다.

두 방식 모두 같은 공식 후보 3개를 찾았고, 그중 한 원문을 열어 등록일을 확인했다. 다만 기본 방식에서 보였던 검색결과 날짜가 스킬의 추출 결과에서는 미표기로 남았다. 원문에서는 두 방식 모두 같은 등록일을 확인했다.

이번 비교에서 내장 스킬이 더 정확하다는 결론은 나오지 않았다. 검색결과에서 가져온 정보와 실제 원문을 열어 확인한 정보를 나눠 기록했다. 두 실행 모두 공통으로 필요한 계정 관련 안내는 읽었으므로, ‘아무 스킬도 읽지 않은 실행’과의 비교는 아니다.

2. 성공한 확인 절차를 사용자 스킬로 만들었다

먼저 합성 예시 세 개를 Aside에 확인시켰다. 실제 뉴스가 아닌 시험용 자료였다.

• A: 기사 목록 3개, 문안에도 3건이라고 적힌 페이지.

• B: 기사 목록은 3개인데 문안은 5건이라고 적힌 페이지.

• C: 발행일은 있지만 자료 기준일은 없는 페이지.

스킬 없이 기본 브라우저 도구만 사용한 실행도 건수 불일치와 기준일 누락을 찾아냈다. 이 결과를 남긴 뒤, Aside의 내장 skill-creator로 news-brief-check라는 사용자 스킬을 만들었다.

스킬에 담은 핵심은 다음과 같다.

1. 페이지와 문안을 실제로 열어 확인한다.

2. 뉴스 목록의 표시 항목 수, 같은 URL을 제외한 고유 기사 수, 헤드라인 수를 따로 센다.

3. 자료 기준일과 발행일을 구분하고, 없는 날짜를 추측으로 채우지 않는다.

4. 링크가 있는 것과 원문을 실제로 연 것을 구분한다.

5. 보지 못한 모바일 화면은 확인 못 했다고 적고, 수정·발송은 하지 않는다.

쓰는 조건과 입력도 스킬 설명에 적었다. ‘브리핑 점검’, ‘발송 전 확인’ 같은 요청에 쓰고, 글을 쓰는 요청은 다른 스킬이 맡도록 제외했다. 입력은 브리핑 페이지와 요약 문안이고, 모바일 확인이 필요하면 화면 폭을 함께 받는다. 결과는 항목마다 일치·불일치·확인 못 함 가운데 하나와 관찰 근거를 붙인 보고서로 나온다. 이번 주 수업에서 말한 ‘증거 산출물’에 해당하는 부분이다.

새 대화에서 같은 예시를 다시 확인했다. 건수·기준일에 대한 핵심 판단은 앞선 실행과 같았다. 스킬 적용 결과에는 문안 날짜의 역할이 명시되지 않았다는 지적도 추가됐다. A 역시 모든 항목이 갖춰진 정상본은 아니었다.

같은 모델과 같은 입력을 사용했지만 각 조건을 한 번씩만 실행했고, 사용자 스킬 실행에서는 보고서를 보여주는 visualize도 추가로 읽었다. 이 결과만으로 정확도나 속도가 향상됐다고 주장할 수는 없다.

스킬 생성 후에는 파일이 생긴 것만 확인하지 않았다. 실제 브리핑을 대상으로 스킬 이름을 지정하지 않고 다음과 같이 요청했다.

이 업계 뉴스 브리핑을 발송 전에 점검해줘.

대상 페이지와 문안 주소, 모바일 확인 조건, 첫 원문만 확인할 범위를 함께 전달했다. 실행 기록에서 news-brief-check를 읽은 뒤 브라우저를 여는 것을 확인했다.

3. 실제 브리핑에서 표시 수량이 어긋난 곳을 찾았다

10월 13일 브리핑과 전달 문안의 보관본을 점검했다. 운영 페이지를 그대로 수정하지 않도록 별도 실험 사본에서 진행했다.

첫 번째 발견은 뉴스 집계의 단위였다. 분류별로 표시된 항목은 24개였지만, 같은 URL을 제외한 고유 기사는 22개였다. 두 기사가 각각 다른 분류에도 나타났다. 24라는 숫자 자체가 틀렸다기보다, 무엇을 센 숫자인지 설명이 필요했다.

두 번째는 실제 불일치였다. 브리핑 상단과 전달 문안에는 ‘OTT 누적 11’이 적혀 있었는데, 화면에는 해당 카드가 9개였다. 페이지와 문안의 숫자만 서로 비교했다면 둘 다 11이라 통과했을 것이다.

생성 코드를 확인하니 표시 조건을 적용하기 전에 전체 작품을 먼저 집계하고 있었다. 화면에서는 반응 자료가 없는 작품을 생략하고 최대 표시 수도 제한하는데, 숫자는 그 전에 세어진 것이다. 이번 11과 9의 차이는 반응 자료가 없는 작품 2개에서 나왔다. 실제 표시 카드를 만들 때 집계하도록 수정 후보를 만들었다. 같은 입력을 다시 처리했을 때 페이지와 문안 모두 9로 바뀌었고, 카드 내용은 그대로였다. 이 수정에 따른 출력 차이가 해당 숫자뿐인지도 대조했다.

실험용 페이지에는 뉴스 표시 항목과 고유 기사 수를 나눠 적고, 날짜의 역할도 명시했다. 이 표기 변경은 카드 집계 코드 수정과 별도로 만든 후보이며, 운영 사이트에는 반영하지 않았다.

결과와 배운 점

이번에 확인한 발전은 기존 수집·요약을 Aside로 전부 갈아탄 것이 아니라, 완성된 페이지를 확인하는 절차를 Aside에서 다시 부를 수 있게 만든 것이다.

이번 실험에서 가져갈 팁은 두 가지다.

표시 숫자끼리만 비교하지 말고 실제 항목을 세게 한다. 페이지와 메시지가 같은 잘못된 집계값을 공유할 수 있었다. 카드나 목록 항목을 직접 센 값을 함께 두니 차이가 드러났다.

짧은 요청으로 돌아오는 범위를 확인한다. 스킬 파일을 만든 것과 새 대화에서 실제로 읽힌 것은 다른 단계였다. 이번에는 호출 기록을 확인하고 실제 페이지 점검까지 이어갔다.

도움이 필요한 부분

분류별로 같은 기사가 중복되는 브리핑을 운영한다면, 전체 기사 수는 고유 기사 기준으로 표시하는지, 분류별 항목 수도 함께 보여주는지 궁금하다. 이번 수정 후보에는 두 수를 함께 적었다.

아직 남은 것

첫 실행은 연결 모델의 사용량 제한 오류로 작업하지 못했다. 해당 실행은 비교에서 제외하고, 이후 비교에는 같은 연결 모델을 사용했다.

모바일 390px 검사는 첫 실행에서 도구의 폭 설정 기능을 확인하지 못해 미확인으로 남았다. 후속으로 같은 사본을 390px 너비의 iframe, 즉 페이지 안의 별도 화면에 넣었다. Aside가 스킬을 다시 실행해 두 화면의 내부 폭과 문서 폭이 모두 390px인 것을 확인했고, 캡처를 살펴본 구간에는 가로 넘침이 없었다. 확인 범위는 브라우저의 390px 화면이며, 실제 휴대폰의 터치 조작성은 이번 실험 범위에 포함하지 않았다.

같은 재실행에서 Aside는 수정 사본의 수량·자료 기준일·브리핑 발행일·문안 대응과 390px 화면을 확인했고, 불일치는 없다고 보고했다. 다만 기사별 발행 날짜는 여전히 확인 못 해서, 스킬의 전체 판정은 ‘점검 완료: 아니오’로 남았다. 끝낸 재검증 범위와 전체 판정을 구분해 기록했다.

새 스킬은 필요할 때 부를 수 있게 설치했지만, 매일의 자동 발송을 이 스킬이 중간에서 막도록 연결한 것은 아니다. 운영 반영과 예약 실행은 다음 단계다. 이번에 만든 것은 수량·날짜·화면 확인을 반복할 수 있는 스킬과 수정 후보이며, 모든 뉴스의 사실관계를 보증하는 시스템은 아니다.

다음 주로 넘길 메모는 세 가지다. 기억할 내용은 표시 항목 수와 고유 기사 수를 나눠 세고, 자료 기준일과 발행일을 구분한다는 기준이다. 다시 실행할 시점은 그날 브리핑이 만들어진 뒤, 전달하기 전이다. 운영 페이지 수정과 발송은 사람이 먼저 확인한다.

한 줄 요약: 수집에 쓰던 Aside에 확인 스킬을 붙여, 실제 브리핑의 표시 수량이 어긋난 곳을 찾고 수정 후보까지 다시 확인했다.

도움 받은 글 (옵션)

• 24기 에이전트 하네스 스터디 안내: 내장 스킬 비교, 사용자 스킬 생성, CLI·REPL·MCP 실습 기준.

• Aside 공식 개발 도구 안내: CLI·REPL·MCP 연결 방식.