Molayo

© 2026 Molayo

GitHub요약2026. 06. 10. 08:39

Agently Daily News Collector 사용 가이드

요약

Agently v4를 기반으로 재작성된 Agently Daily News Collector의 사용 가이드입니다. 검색, 요약, 보고서 생성을 하나의 엔드투엔드 파이프라인으로 자동화하며, 구조화된 출력 계약과 모듈화된 아키텍처를 제공합니다.

핵심 포인트

  • Agently v4의 TriggerFlow를 활용한 엔드투엔드 뉴스 수집 파이프라인
  • 프롬프트, 도구, 워크플로우 레이어의 명확한 책임 분리 및 모듈화
  • 구조화된 출력 계약을 통한 검색 및 브라우징 도구의 안정성 확보
  • YAML 설정 및 환경 변수를 통한 유연한 모델 및 API 관리

Agently Daily News Collector가 Agently v4를 기반으로 재작성되었으며, 이제 다음 기능을 사용합니다:

TriggerFlow

  • 엔드투엔드 파이프라인을 위해 (Agently v4 내장)
  • Search 및 Browse 도구 - 이전 v3 워크플로우 API 대신 구조화된 출력 계약(structured output contracts) 사용

버전 제약: 이 프로젝트는 Agently v4.0.8.3 이상을 요구합니다. 현재 구현은 열별 파이프라인을 구성하기 위해 TriggerFlow sub flow를 사용하므로, 이전 버전의 v4 릴리스는 여기서 사용되는 워크플로우 구조와 호환되지 않습니다.

이전 Agently v3 프로젝트는 ./v3 아래에 아카이브되었습니다.

  • 주제(topic)를 입력하고 다중 열 뉴스 브리핑을 자동으로 생성합니다.

  • 검색, 후보 선정, 탐색, 요약 및 스토리를 하나의 흐름에서 조립합니다.

  • 최종 보고서를 Markdown 형식으로 ./outputs 아래에 저장합니다.

  • 프롬프트 템플릿은 편집이 쉽도록 ./prompts에 보관합니다. 독립적인 ./tools 레이어를 유지하여 검색/탐색 기능이 메인 워크플로우를 건드리지 않고 대체될 수 있도록 합니다. 또한, 오케스트레이션(orchestration)이 컬렉터 로직과 독립적으로 발전할 수 있도록 흐름 구성은 ./workflow에 보관합니다.

  • 의존성 설치:

pip install -r requirements.txt

Agently를 수동으로 설치하는 경우, 다음을 사용해야 합니다:

pip install "agently>=4.0.8.3"

  • SETTINGS.yaml 수정:

:

  • 모델 블록은 환경 자리 표시자(environment placeholders)로 유지합니다.
  • 필요한 환경 변수를 내보냅니다:
export AGENTLY_NEWS_BASE_URL="https://api.openai.com/v1"
export AGENTLY_NEWS_MODEL="gpt-4.1-mini"
export AGENTLY_NEWS_API_KEY="your_api_key"
  • 또는 로컬 .env 파일에 넣습니다:
AGENTLY_NEWS_BASE_URL=https://api.openai.com/v1
AGENTLY_NEWS_MODEL=gpt-4.1-mini
AGENTLY_NEWS_API_KEY=your_api_key

  • 필요에 따라 언어/검색/동시성(concurrency) 설정을 조정합니다.

  • OpenAI와 호환되는 엔드포인트가 인증을 요구하지 않는 경우, AGENTLY_NEWS_API_KEY를 설정하지 않아도 프로젝트는 auth 단계를 건너뜁니다.

  • 실행:

python app.py

또는 주제를 직접 전달합니다:

python app.py "AI agents"

.
├── app.py
├── news_collector/
...

비즈니스 체인은 여전히 대략 다음과 같습니다:

비즈니스 체인은 여전히 대략 다음과 같습니다:

outline -> search -> pick -> browse + summarize -> write column -> render markdown

변경된 것은 이 체인을 둘러싼 엔지니어링 구조입니다.

  • 이전 v3 프로젝트는 ./workflows 아래에 메인 워크플로우와 중첩된 컬럼 워크플로우를 사용했으며, 커스텀 search.py/browse.py 헬퍼와 스토리지 스타일의 상태 전달 방식을 사용했습니다. - v4 프로젝트는 책임을 더 명확하게 분리합니다:
    news_collector/
    : 앱/통합 계층workflow/
    : 부모 흐름, 컬럼 하위 흐름 및 구체적인 청크 로직tools/
    : 검색/브라우징 어댑터 계층prompts/
    : 구조화된 프롬프트 계약

  • 모델 설정이 더 이상 Python에 하드코딩되지 않습니다. 이제 SETTINGS.yaml의 ${ENV.xxx} 플레이스홀더를 사용하므로 배포 및 로컬 전환이 더 간단합니다. - 도구 연결(Tool wiring)은 워크플로우 코드 내부에 묻혀있지 않습니다. 검색, 브라우징, 로거는 TriggerFlow 런타임 리소스로 주입되므로 워크플로우를 교체하거나 테스트하기가 더 쉽습니다.

  • 워크플로우 계획이 이제 비즈니스 경계에 더 가깝습니다:

  • 부모 흐름(parent flow):
    prepare_request -> generate_outline -> for_each(column) -> render_report

  • 컬럼 하위 흐름(column sub flow):
    search -> pick -> summarize -> write_column

  • 컬럼 흐름 내부의 summarize 단계는 요약 하위 흐름(summary sub flow)으로 더 깊이 분리되었으며, 여기서 TriggerFlow는 비즈니스 코드 내에서 asyncio.gather를 사용하는 대신 팬아웃 및 수집을 직접 처리합니다. - 이는 부모가 보고서 오케스트레이션에 집중하고 자식이 하나의 컬럼 라이프사이클에 집중하도록 유지합니다.

  • 여기에서 sub flow의 즉각적인 가치는 컬럼 파이프라인이 크고 거대한 부모 청크 안에 묻혀있는 대신 재사용 가능하고 독립적으로 진화할 수 있는 워크플로우 단위가 된다는 것입니다.

  • 부모 흐름(parent flow):

TriggerFlow 오케스트레이션 - 이전 v3 워크플로우 스타일을 더 명시적인 플로우 그래프(to, for_each, sub flow)로 대체합니다.

-, 분기 처리가 용이한 구성(branching-ready composition)을 지원합니다. 이전 v3 워크플로우 체인과 달리, TriggerFlow는 여러 열(columns)을 동시에 실행하며 각 열 내에서 선택된 기사들을 동시에 요약할 수도 있습니다.

이는 이 프로젝트에 다음과 같은 의미를 가집니다: 엔드투엔드 뉴스 파이프라인을 오케스트레이션 로직과 비즈니스 로직을 혼합하지 않고도 검사(inspect), 발전(evolve), 그리고 청크로 분리하기가 더 쉬워졌습니다. 또한, 부모 보고서 흐름과 개별 열(per-column) 파이프라인을 하나의 거대한 청크 대신 부모/자식 흐름으로 직접 모델링할 수 있게 되었습니다.

하위 흐름 구성 (Sub flow composition) - 프로젝트가 자연적으로 반복되는 비즈니스 파이프라인인 “한 열 만들기(build one column)”를 자체 TriggerFlow로 추출하여, 이를 부모 흐름 내의 for_each(column)에서 반복적으로 호출할 수 있게 되었습니다.

이는 이 프로젝트에 다음과 같은 의미를 가집니다:

  • 부모 흐름은 보고서 수준의 오케스트레이션에 집중합니다.
  • 열 파이프라인을 독립적으로 테스트, 시각화 및 내보내기(export) 할 수 있습니다.
  • “브리핑 열”, “심층 분석 열”, 또는 “지역별 열”과 같은 미래 변형들은 부모 흐름 노드를 복제하는 대신 자식 흐름을 재사용하거나 파생시킬 수 있습니다.

capture / write_back은 입력, 상태 및 리소스에 대한 부모와 자식 간의 경계를 명확하게 합니다.

구조화된 출력 계약 (Structured output contracts) - YAML 프롬프트가 개요 생성, 뉴스 선택, 요약, 열 작성 등을 위해 출력 스키마를 직접 정의합니다.

이는 이 프로젝트에 다음과 같은 의미를 가집니다: 수동으로 작성해야 하는 파싱 접착 코드(parsing glue)가 훨씬 적어지고, 단계 간의 인터페이스가 명확해지며, 프롬프트 반복 작업이 더 쉬워졌습니다.

내장 검색/탐색 도구 (Built-in Search / Browse tools) - 프로젝트는 이제 이전의 로컬 헬퍼 대신 Agently v4 내장 도구 구현을 기본값으로 사용합니다.

이는 이 프로젝트에 다음과 같은 의미를 가집니다: 사용자 정의 인프라 코드가 줄어들고, 워크플로우를 다시 작성하지 않고도 ./tools를 통해 구현체를 교체할 수 있습니다.

런타임 리소스 및 상태 네임스페이스 (Runtime resources and state namespaces) - TriggerFlow 런타임 리소스는 로거(logger)/검색(search)/브라우징(browse) 종속성을 주입하는 데 사용되며, 런타임 상태(runtime state)는 요청(request), 개요(outline), 중간 결과와 같은 실행 데이터를 저장합니다.

  • 이 프로젝트의 의미: 종속성 연결(dependency wiring)과 실행 상태가 깔끔하게 분리되어 청크 코드(chunk code)를 더 간결하고 유지보수하기 쉽게 만듭니다.

환경 인식 설정 (Environment-aware settings) - Agently v4
set_settings(..., auto_load_env=True)

${ENV.xxx} 플레이스홀더와 직접 작동합니다. - 이 프로젝트의 의미: 코드 수정이나 비밀 정보 커밋 없이 환경 변수를 통해 모델 엔드포인트, 모델 이름, API 키를 전환할 수 있습니다.

  • Agently v4

  • 핵심 제품 동작은 v3 사용자에게 익숙하게 유지되지만, 이제 프로젝트는 더 깔끔한 app/workflow/tools/prompts 분할 구조를 갖게 되었습니다.

  • 프로젝트별 접착 코드(glue code) 대신 Agently 네이티브 기능에서 더 많은 로직을 표현합니다.

  • 진정한 동시성(True concurrency)이 기본 실행 모델의 일부가 되었습니다. v3 버전은 사실상 순차적(serial)이었던 반면, v4 버전은 TriggerFlow를 통해 컬럼 및 컬럼별 요약을 병렬로 처리할 수 있습니다.

  • 도구를 교체하거나 프롬프트를 조정하거나 워크플로우 단계를 발전시키는 것이 이전 v3 레이아웃보다 위험도가 낮아졌으며, 전체 오케스트레이션 형태는 다시 원래의

애플리케이션/통합 계층으로서 구성(configuration), 모델 연결(model wiring), 그리고 CLI 진입점 지원 역할을 합니다. 현재 샘플 SETTINGS.yaml은 많은 뉴스 페이지가 사용 가능한 콘텐츠를 반환하기 위해 실제 브라우저가 필요하므로 기본적으로 BROWSE.enable_playwright: true를 활성화합니다. Playwright 설치를 원하지 않는 경우, BROWSE.enable_playwright를 수동으로 false로 설정할 수 있지만, 동적 또는 보호된 사이트에서는 낮은 수준의 브라우징 품질을 예상해야 합니다. 이 설정 로더는 MODEL_PROVIDER, MODEL_URL, MODEL_AUTH, MODEL_OPTIONS, MAX_COLUMN_NUM, 그리고 USE_CUSTOMIZE_OUTLINE과 같은 이전 v3 키와의 기본적인 호환성을 유지합니다.

AI 자동 생성 콘텐츠

본 콘텐츠는 GitHub AI Tools의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0