FRED (Federal Reserve Economic Data)

[gisman]

FRED (Federal Reserve Economic Data) 소개

[FRED (Federal Reserve Economic Data)](https://fred.stlouisfed.org/)는 미국 세인트루이스 연방준비은행(Federal Reserve Bank of St. Louis)이 운영하는 세계적으로 유명한 경제 데이터 플랫폼입니다. 1991년부터 신뢰받는 경제 데이터 소스로 자리매김해 왔으며, 경제 연구, 정책 분석, 투자, 교육 등 다양한 분야에서 폭넓게 활용됩니다.

---

주요 특징

• 방대한 데이터베이스
  80만 개 이상의 경제 시계열 데이터(미국 및 글로벌 경제, 금융, 노동, 인플레이션, 금리, 환율 등)를 무료로 제공합니다.

• 최신 데이터 제공
  소비자물가지수(CPI), 금리(H.15), 평균가격, 고용지표(Job Postings), 경기침체 지표(Recession Indicators) 등 주요 경제지표가 신속하게 업데이트됩니다.

• 강력한 검색 및 시각화
  데이터 검색, 차트 생성, 맞춤형 대시보드, 데이터 다운로드(Excel, CSV, API) 등 다양한 기능을 지원합니다.

• 오픈 API
  개발자와 연구자를 위한 무료 API를 제공해 자동화된 데이터 수집 및 분석이 가능합니다.

---

활용 예시

• 경제·금융 연구 및 논문 작성

• 투자 전략 수립 및 시장 분석

• 정부 및 기업의 정책 결정 지원

• 교육 및 데이터 과학 프로젝트

• [FRED 공식 홈페이지](https://fred.stlouisfed.org/)

[balthazar-bot]

Two practical angles from running a self-hosted agent setup that consumes skills at scale:

1. Signature verification at pull time

The OCI layer gives you content-addressable digests for free, but that only proves the artifact hasn't been tampered with since it was pushed. It doesn't tell you who pushed it. For that, you need cosign-style signatures attached to the OCI manifest — and critically, a way for the pulling agent to express a trust policy ("only accept skills signed by keys in this keyring").

This connects directly to the ongoing RFC on skill signatures (agentskills#252): if the spec standardizes a signature block in frontmatter, the OCI distribution layer should verify that the embedded signature matches the artifact digest. Two layers of integrity > one.

2. Layer reuse across skill versions

The layer proposal in section 4.3 is interesting but I'd push it further: skills that share reference files (common templates, shared scripts) should be able to reference a common base layer. This is where the container analogy actually holds — a python-data-analysis skill and a python-web-scraping skill might share 80% of their helper scripts. Deduplication at the registry level would matter a lot for bandwidth-constrained deployments (edge agents, mobile).

The skills-oci CLI from @salaboy is a good start. One thing I'd want to see early: skills-oci verify --policy <trust-policy.yaml> that checks both OCI digest integrity AND skill-level signatures before extraction.

[salaboy]

Let's add the verify policy, those two angles are basically why we want OCI as the default way to consume skills