last30days: AI 에이전트로 최근 30일의 커뮤니티 흐름 읽기

새로운 개발 도구를 발견하면 공식 문서부터 읽는다. 어떤 기능이 있는지, 어떻게 시작하는지는 비교적 빨리 알 수 있다. 그런데 도입을 결정하기 전에 궁금한 것은 따로 있다. 최근에 써본 사람들은 무엇을 좋아하고, 어디에서 막히고 있을까?

이 질문에 답하려면 여러 곳을 오가게 된다. Reddit에서 사용 후기를 읽고, X에서 개발자의 글을 찾고, YouTube에서 시연 영상을 보고, GitHub에서 관련 이슈를 확인한다. 자료를 찾는 일만큼 게시 시점을 확인하고 비슷한 이야기를 묶는 일에도 시간이 든다.

last30days는 이런 최근 동향 조사를 AI 에이전트에게 맡기기 위한 오픈소스 스킬이다. 이 글에서는 무엇을 하는 도구인지, 어떤 순서로 조사하는지, 어디에 유용하고 어떤 한계가 있는지를 살펴본다.

last30days는 무엇인가

last30days는 주어진 주제를 최근 30일이라는 시간 범위를 중심으로 조사하고, 여러 플랫폼에서 찾은 자료를 요약하는 도구다. Reddit, X, YouTube, Hacker News, GitHub 등을 지원하며, 환경과 설정에 따라 실제로 조회하는 소스는 달라진다. 프로젝트 소개와 지원 범위는 공식 GitHub 저장소에서 확인할 수 있다.

여기서 스킬은 AI 에이전트가 따라야 할 지침과 실행 도구를 묶은 패키지를 뜻한다. last30days에도 조사 절차를 설명하는 SKILL.md와 실제 수집을 수행하는 Python 코드가 함께 들어 있다. 사용 중인 에이전트가 지침을 읽고 도구를 실행하며 조사를 진행하는 구조다. 프로젝트의 개념 설명

관심의 중심에는 커뮤니티의 최근 반응이 있다. 공식 문서가 기능과 사용 조건을 확인하는 데 필요하다면, last30days로 모은 자료는 그 기능을 사용하는 사람들이 어떤 경험을 하고 있는지 살펴보는 데 쓸 수 있다.

예를 들어 새 라이브러리의 도입을 검토한다면 릴리스 노트에서 바뀐 기능을 읽은 뒤, 관련 토론에서 반복되는 불편이나 사용 사례를 찾아보는 식이다. 두 자료를 함께 읽으면 기능 목록만으로는 드러나지 않는 검토 항목을 얻을 수 있다.

어떻게 조사하는가

동작 원리를 이해할 때는 AI 에이전트가 맡는 판단과 Python 엔진이 맡는 수집·정리 작업을 나누어 보면 쉽다. 웹 검색과 추론 기능을 사용할 수 있는 호스트에서는 에이전트가 검색 계획을 만들어 엔진에 전달하고, 수집 결과를 읽어 최종 설명을 작성한다. 실행 환경에 따라 엔진 내부의 계획·순위 처리 경로를 사용하기도 한다. 스킬의 실행 지침

1. 01검색 계획
2. 02자료 수집
3. 03관련도·최신성·참여도 평가
4. 04중복·근거 정리
5. 05결과 요약

1. 질문을 검색 계획으로 바꾼다

먼저 무엇을 조사할지 구체화한다. 같은 이름을 쓰는 제품이나 인물이 있을 수 있으므로 관련 계정, 저장소, 커뮤니티를 확인하고 검색 대상을 좁힌다. 이어 질문을 몇 개의 하위 검색어로 나누고, 각 검색에서 조회할 소스를 정한다.

예를 들어 특정 라이브러리의 평가를 묻는다면 사용 후기와 마이그레이션 경험은 서로 다른 검색 관점이 된다. 단순히 제품 이름을 반복해서 검색하는 것보다 질문을 나누는 편이 필요한 근거를 찾는 데 유리하다.

이 단계에는 사용자 질문을 해석하는 모델의 판단이 들어간다. 그래서 주제 이름만 전달하기보다 제품의 종류와 궁금한 점을 함께 적는 것이 좋다.

2. 소스별로 자료를 수집한다

Python 엔진은 계획에 따라 여러 소스를 병렬로 조회한다. 플랫폼마다 얻을 수 있는 자료도 다르다. 토론 글과 댓글, 영상 정보와 자막, 저장소 활동 등 서로 다른 형태의 자료를 처리해야 한다.

이때 설치되어 있는 CLI, API 키, 인증 상태가 조사 범위에 영향을 준다. 지원 목록에 YouTube나 X가 있다는 것과 이번 실행에서 그 소스를 정상적으로 조회했다는 것은 별개의 정보다. 결과를 읽을 때 실제 수집 범위도 함께 봐야 하는 이유다.

3. 관련도·최신성·참여도를 함께 살핀다

수집한 자료는 주제와 얼마나 관련 있는지, 얼마나 최근 자료인지, 사람들이 얼마나 반응했는지를 함께 고려해 정렬한다. 참여도에 쓰이는 정보도 플랫폼에 따라 달라진다. 업보트, 댓글 수, 좋아요, 조회수 등을 해당 소스에 맞게 처리한다.

로컬에서 확인한 v3.23.0의 초기 정렬 코드는 관련도에 65%, 최신성에 25%, 참여도에 10%의 가중치를 둔다. 이 비율은 각 검색 결과 목록 내부의 초기 순위에 해당한다. 이후 결과를 합치고 다시 순위를 계산하는 단계가 있으므로 최종 보고서의 점수 공식과는 구분해야 한다. 초기 정렬 코드

여기서 알 수 있는 것은 참여도가 여러 판단 기준 중 하나라는 점이다. 조회수가 높더라도 질문과 관계없는 자료라면 조사에 도움이 되기 어렵다.

4. 중복을 합치고 근거를 정리한다

여러 검색어로 같은 글을 찾을 수 있다. 엔진은 URL을 기준으로 중복 자료를 합치고, 각 검색 결과에서의 순위를 결합한다. 이 과정에 사용하는 기법이 RRF, 즉 Reciprocal Rank Fusion이다. 여러 목록에서 상위에 등장한 자료의 순위 정보를 합치는 방식이라고 이해하면 된다. 결과 병합 코드

조사 유형에 따라 관련 자료를 묶는 클러스터링도 수행한다. 예를 들어 같은 사건이나 논쟁을 다룬 글들을 묶으면, 에이전트가 흩어진 링크를 하나씩 읽는 것보다 논점을 파악하기 쉬워진다. 클러스터링 코드

단, 여러 플랫폼에 비슷한 글이 있다고 해서 독립적으로 확인된 사실이라는 뜻은 아니다. 모두 같은 발표나 원문을 재인용했을 수도 있다. 자료가 얼마나 퍼졌는지와 사실을 뒷받침하는 근거가 얼마나 독립적인지는 따로 판단해야 한다.

5. 에이전트가 결과를 읽고 요약한다

마지막으로 에이전트가 수집·정리된 근거를 읽고 주요 내용과 반복되는 패턴을 설명한다. 이때 소스별 수집량과 접근하지 못한 소스도 결과의 해석에 영향을 준다.

일반 조사 외에도 비교나 주제 탐색 같은 흐름을 지원한다. 예를 들어 비교할 두 도구를 지정하거나, 관심 분야에서 조사할 만한 주제를 찾는 식으로 요청을 바꿀 수 있다. 지원 모드와 옵션은 설정 문서에 정리되어 있다.

어떤 점이 유용한가

첫째, 조사 시작에 드는 반복 작업을 줄일 수 있다. 여러 사이트에서 검색하고, 날짜를 확인하고, 중복 링크를 정리하는 과정은 주제가 바뀔 때마다 되풀이된다. 이 과정을 맡기고 나면 사용자는 관련성이 높은 원문을 골라 읽는 데 시간을 쓸 수 있다.

둘째, 서로 다른 종류의 자료를 함께 검토할 수 있다. 사용 후기에 등장한 불편이 GitHub 이슈에서도 논의되는지, 영상에서 소개한 기능에 실제 사용자 반응이 있는지 살펴볼 수 있다. 여러 소스를 모으는 가치는 자료의 개수보다 서로 다른 관점을 비교할 기회에 있다.

셋째, 다음에 확인할 질문을 만드는 데 유용하다. 반복되는 설치 문제, 특정 기능에 대한 기대, 서로 엇갈리는 평가를 발견하면 조사 방향이 구체화된다. 블로그를 쓸 때도 이런 자료를 통해 독자가 궁금해할 쟁점을 찾고 공식 문서로 다시 확인할 수 있다.

활용 범위는 도구 도입 전의 평판 조사, 제품 업데이트 이후 반응 확인, 글을 쓰기 전의 논점 탐색처럼 최근 맥락이 필요한 작업과 잘 맞는다. 특히 이미 검색할 주제는 정해졌지만 어떤 원문부터 읽을지 막막할 때 시작점으로 삼기 좋다.

결과를 읽을 때 알아둘 한계

인기와 정확성은 다른 기준이다

참여도는 어떤 이야기가 주목받는지 보여준다. 하지만 좋아요가 많다고 기술적 설명까지 정확한 것은 아니다. 자극적인 주장이나 홍보성 콘텐츠도 높은 반응을 얻을 수 있다.

따라서 요약에 등장한 기능, 성능 수치, 지원 여부를 글에 인용하려면 공식 문서나 원문을 다시 확인해야 한다. 커뮤니티 반응은 경험과 의견을 파악하는 자료로 읽는 편이 적절하다.

조회하지 못한 소스는 조용한 소스가 아니다

인증 만료, 호출 제한, 네트워크 문제 때문에 자료를 가져오지 못할 수 있다. 이 상태에서 결과가 0건이라면 “관련 논의가 없다”고 결론 내릴 수 없다.

프로젝트는 정상 조회 후 결과가 없는 상태와 인증 실패·시간 초과·부분 수집을 구분하도록 지침을 두고 있다. doctor는 설정과 소스 상태를 진단하고, doctor --postmortem은 마지막 실행의 결과를 바탕으로 문제를 확인하는 데 쓰인다. --preflight는 실제 조사 전에 설정 출처와 예정된 접근·저장 작업을 보여준다. 진단 및 실행 지침

독자가 보고서에서 확인해야 할 것은 어떤 주장이 나왔는지뿐 아니라, 그 주장을 만들 때 어떤 자료까지 볼 수 있었는지다.

주제와 언어에 따라 얻는 자료가 달라진다

지원 플랫폼에 관련 글이 적거나 제품 이름이 모호하면 유용한 자료가 충분히 모이지 않을 수 있다. 한국어로 질문하고 한국어 요약을 받더라도 수집된 원문은 영어권 플랫폼에 치우칠 수 있다.

한국어 커뮤니티의 반응이 중요하다면 대상 커뮤니티를 직접 확인하는 조사도 필요하다. 한국어로 작성된 결과라는 이유만으로 국내 사용자의 의견을 대표한다고 해석해서는 안 된다.

최근 30일이라는 범위에도 같은 주의가 필요하다. 오래 누적된 불편이나 장기적인 평가는 짧은 조사 창만으로 파악하기 어렵다. 기간 설정과 실제 자료의 날짜를 함께 확인하고, 장기 변화가 궁금하다면 과거 자료도 별도로 비교하는 편이 좋다.

설정과 실행 비용이 따른다

스킬의 설치 비용과 조사에 필요한 비용은 나누어 생각해야 한다. 무료로 접근할 수 있는 경로도 있지만, 선택한 소스에 따라 별도 API 키나 로그인 상태가 필요할 수 있고 사용량에 따른 비용도 발생할 수 있다. 에이전트가 검색 계획과 요약을 만드는 과정 역시 해당 호스트의 사용량을 소비한다. 소스별 설정 안내

브라우저 세션을 사용하는 경로를 선택한다면 어떤 계정에 접근하는지도 이해해야 한다. 설치 직후에는 필요한 소스부터 활성화하고, 실제 수집 범위를 확인한 뒤 넓혀가는 접근이 관리하기 쉽다.

소스가 많고 댓글이나 자막까지 확인할수록 기다리는 시간도 늘어난다. 단일 사실을 확인하는 질문은 공식 문서를 바로 찾는 편이 빠를 수 있다. 여러 사람의 최근 반응을 모아 읽어야 하는 질문에서 이 도구의 효용이 커진다.

설치와 간단한 사용 예시

호스트별 설치 방법과 필요한 실행 환경은 공식 README의 설치 안내를 참고하면 된다. 소스별 API 키와 출력 옵션은 CONFIGURATION.md에서 확인할 수 있다.

설치 후에는 스킬을 선택하고 조사 주제와 목적을 함께 전달한다. 아래는 질문을 구성하는 예시이며, 실제 조사 결과를 인용한 것은 아니다.

last30days로 Next.js App Router의 최근 마이그레이션 경험을 조사해줘. 반복되는 문제와 해결 사례를 구분하고, 확인할 수 없었던 소스도 알려줘.

last30days로 두 개발 도구에 대한 최근 사용자 반응을 비교해줘. 팀 협업과 확장 기능을 중심으로 정리해줘.

제품 이름을 정확히 적고 비교 기준을 좁히면, 결과가 나온 뒤 어떤 원문을 확인해야 할지도 명확해진다.

실제 조사 사례: INTENT.md

2026년 9월 6일 저장한 INTENT.md 추가 조사 보고서는 last30days의 활용 방식을 보여주는 사례다. 의도와 제약을 문서로 남기는 관행이 실제 코드 변경·검증·에이전트 인계에 어떻게 연결되는지를 살폈다. 최근 동향의 범위는 8월 7일부터 9월 6일까지였고, 그보다 오래된 자료는 배경으로 구분했다.

조사 결과에서 찾은 원문을 확인하니 서로 다른 적용 방식이 드러났다.

• X-GIS: 9월 5일 병합된 PR은 의도·제약·거절한 접근·완료 검증을 기록하는 새 GitHub 이슈 템플릿을 추가하고 기존 지침에 연결했다. 별도 문서를 늘리는 대신 이슈를 작성하는 시점에 의도를 남기는 방식이다. PR과 변경 파일
• callback: PR #81은 INTENT.md의 요구를 근거로 수집기를 교체하고 검증 자료를 추가했다. 9월 6일 확인 당시에는 아직 병합되지 않았다. 수집기 교체 전후의 성능 수치는 의도 문서 자체의 효과를 측정한 결과와 구분해야 한다. PR 원문
• Pathmode: 8월 30일에는 다음 에이전트에게 인계 기록이 전달되지 않던 문제를 수정했다고 밝혔고, 9월 3일에는 PR 커밋과 의도 문서 버전에 연결된 검토 기능을 발표했다. 이 검토는 병합을 차단하지 않는 참고 기능이다. 변경 기록

세 사례는 의도 문서를 개발 흐름에 연결하는 시도가 있다는 근거다. 다만 도입 사례를 찾았다는 것과 생산성 향상이 입증됐다는 것은 다르다. PR 작성자나 제품 공급자가 설명한 효과를 독립적인 비교 실험의 결과로 읽어서는 안 된다.

이 과정에서 last30days 결과는 읽어볼 원문과 비교할 쟁점을 찾는 출발점이 됐다. 이어 원문에서 실제 변경 파일, 병합 여부, 기능의 적용 범위를 확인해야 글에 쓸 수 있는 근거가 된다. 수집 건수 역시 검색 결과의 양이며 독립적인 도입 사례 수를 뜻하지 않는다.

블로그 자료 조사에 활용한다면

블로그 자료 조사에 사용한다면 요약에서 논점을 찾고, 핵심 주장은 연결된 원문과 공식 문서로 확인하는 흐름이 적합하다. 그렇게 사용하면 조사를 시작하는 수고를 줄이면서도 글의 근거를 직접 검토할 수 있다.

기능 설명은 2026년 9월 6일 확인한 공식 문서와 로컬 v3.23.0 코드를 바탕으로 작성했다. 사례 부분은 같은 날 저장한 INTENT.md 조사 보고서와 연결된 원문을 대조해 정리했다. 이번 글 보완 과정에서 조사 엔진을 새로 실행하거나 생산성 개선 효과를 측정하지는 않았다. 지원 소스와 설정 방법은 버전에 따라 달라질 수 있다.