public-apis 43만 스타 — 외부 무료 API 도입 전 백엔드 체크리스트

본 가이드는 GitHub public-apis/public-apis 저장소를 한국 백엔드 개발자가 실무에서 활용할 때 점검해야 할 항목을 정리합니다. 사이드 프로젝트나 MVP에서 외부 무료 API를 빠르게 끌어다 쓰기 좋은 카탈로그이지만, 운영 환경 도입 전에는 인증 방식, 라이선스, 가용성을 추가로 검토해야 합니다.

참고 시점: 2026년 6월 1일 기준, 저장소 README와 GitHub API 메타데이터. 점검 대상은 Node.js 22 또는 Python 3.12 환경의 서버 사이드 통합을 가정합니다.

1. public-apis 저장소 개요

public-apis는 커뮤니티가 수동 큐레이션하는 무료 공개 API 목록입니다. GitHub API 응답 기준 2026년 6월 1일 시점에 stargazers_count는 438,234, forks_count는 48,028로 확인됩니다(출처: api.github.com/repos/public-apis/public-apis). 라이선스는 MIT이며 README는 50개 안팎의 도메인 카테고리로 항목을 분류합니다.

주제 범위는 Animals, Authentication, Cryptocurrency, Currency Exchange, Geocoding, Government, Machine Learning, Weather까지 광범위합니다. 한국 서비스 통합에서 자주 쓰이는 카테고리는 Currency Exchange, Geocoding, Government, Weather, Open Data 다섯 가지입니다.

2. 항목 메타 읽는 법 (Auth / HTTPS / CORS)

각 API는 표 형식으로 Auth, HTTPS, CORS 세 가지 메타를 명시합니다. 백엔드 통합 관점에서 이 세 컬럼이 가장 먼저 보아야 할 신호입니다.

• Auth: No / apiKey / OAuth. apiKey 표기여도 무료 한도가 있는 유료 서비스인 경우가 많으므로 가입 페이지에서 Free Tier 한도와 결제 정보 요구 여부를 확인합니다.
• HTTPS: Yes가 아닌 항목은 운영 환경 후보에서 제외하도록 합니다. 평문 통신은 토큰 유출과 무결성 훼손 위험이 큽니다.
• CORS: 서버 사이드에서 호출한다면 CORS 값과 무관하지만, 브라우저에서 직접 호출하는 위젯이라면 Yes가 아닌 항목은 백엔드 프록시가 필요합니다.

3. 한국 백엔드의 실무 활용 시나리오

실무에서 외부 무료 API는 다음 구간에서 가장 잘 맞습니다. 핵심 비즈니스 로직보다는 보조 데이터 공급에 한정하도록 합니다.

• 사이드 프로젝트 또는 MVP의 빠른 검증 — Currency Exchange, Weather, Geocoding은 자체 데이터 구축 비용을 회피합니다.
• 사내 자동화 도구 — Slack 봇, 모니터링 대시보드의 보조 정보 공급원으로 활용 가능합니다.
• 교육·실습 환경 — REST 클라이언트 패턴, 인증 흐름, 재시도 정책을 학습하기에 적절합니다.

반면 결제·인증·개인정보·SLA 보장이 필요한 운영 트래픽은 카탈로그의 무료 API에 의존하지 않도록 합니다. 한국 사용자 대상 서비스라면 환율은 한국은행 경제통계시스템, 행정 데이터는 정부 공공데이터포털(data.go.kr)을 1순위로 검토하는 것이 안전합니다.

4. 도입 전 체크리스트

4-1. 라이선스와 이용약관

public-apis 저장소 자체는 MIT 라이선스이지만, 나열된 각 API의 데이터 사용 조건은 별개입니다. 상업적 이용 가능 여부, 결과물 캐싱 허용 여부, 출처 표기 의무를 제공자의 공식 ToS에서 확인합니다. 라이선스 불명 API는 무료라 해도 사내 도구 한정으로 사용 범위를 제한합니다.

4-2. 인증과 시크릿 관리

apiKey 방식은 단순하지만 클라이언트 코드에 노출되면 즉시 폐기·재발급이 필요합니다. 백엔드 환경 변수 또는 AWS Secrets Manager, HashiCorp Vault 같은 비밀 저장소에 보관합니다. 키 만료·로테이션 정책이 공식 문서에 없는 서비스는 도입을 보류하도록 합니다.

4-3. Rate Limit과 타임아웃

대부분의 무료 티어는 분당 또는 일별 호출 한도가 명시되어 있습니다. 한도 초과 시 HTTP 429 응답을 받는 경우가 일반적이며, 지수 백오프와 회로 차단기(circuit breaker) 패턴이 필요합니다. 클라이언트 측 타임아웃은 5초 이내로 설정하고 재시도는 최대 2회를 권장합니다.

// Node.js 22 + undici 예시
import { fetch } from 'undici';

const res = await fetch('https://api.example.com/v1/rates', {
  signal: AbortSignal.timeout(5000),
  headers: { 'X-Api-Key': process.env.PUBLIC_API_KEY }
});

if (res.status === 429) {
  // 지수 백오프 후 재시도, 누적 실패 시 fallback
}

4-4. 데이터 보호와 개인정보보호법

한국 사용자 데이터를 외부 API로 전송할 경우 개인정보보호법상 국외 이전 동의와 위·수탁 고지가 필요할 수 있습니다. 개인정보보호위원회 공식 고시·가이드를 기준으로 처리 위탁 범위와 동의 절차를 사전에 정리하도록 합니다.

5. 운영 리스크

무료 API의 가장 큰 리스크는 통제권 부재입니다. 제공자가 서비스를 종료하거나 무료 정책을 변경하면 사용자가 영향을 받습니다. 다음 3가지 시나리오에 대한 대응 계획을 미리 수립하도록 합니다.

• 서비스 종료·도메인 만료: 응답 실패율이 임계치를 넘으면 자동으로 캐시 모드 또는 대체 공급자로 전환하는 fallback 경로를 설계합니다.
• 무료 정책 변경: 일정 호출 이후 유료 전환이 강제되거나 결제 정보를 요구하는 사례가 잦습니다. ToS 변경 감지를 위해 분기별 1회 약관 페이지를 점검합니다.
• 스키마 변경: 무료 서비스는 변경 공지 없이 응답 필드가 바뀌기도 합니다. 응답 스키마 검증(JSON Schema, Zod 등)을 통과하지 못하면 알림을 발생시키도록 합니다.

6. 언제 쓰고 언제 피해야 하는가

public-apis 카탈로그는 학습·프로토타입·내부 도구에 최적입니다. 결제·인증·개인정보 처리·법적 책임이 따르는 운영 트래픽은 SLA가 명시된 유료 서비스 또는 공식 공공기관 API를 우선 고려합니다. 운영 도입을 결정한 경우라면 본 글 4~5절의 체크리스트와 fallback 설계를 반드시 적용하도록 합니다.

7. 관련 글

외부 의존성과 자체호스팅 사이의 의사결정은 비슷한 무게를 가집니다. 다음 글들이 같은 맥락에서 참고가 됩니다.

• 외부 워크플로 자동화를 사내에 도입할 때 점검 항목은 n8n 자체호스팅 체크리스트에서 다룹니다.
• 외부 시스템 대신 Postgres 한 곳으로 워크플로를 통합하는 흐름은 Postgres Durable Workflow에서 정리했습니다.
• 외부 의존성이 비용 구조에 미치는 영향은 HBM과 AI 칩 비용 구조 글의 시각과 연결됩니다.

---

📌 함께 보시면 좋은 글

• 개발자 커리어 체크리스트 →
• 개발 커리어 결정 가이드 →

※ 본 글은 AI(Claude)의 초안을 기반으로 편집자 검수를 거쳐 발행되었습니다. (한국 AI기본법 대응 고지)