본 가이드는 GitHub 저장소 public-apis/public-apis에 정리된 무료 공개 API 목록을 실제 서비스에 적용하기 전에 거쳐야 할 공개 API 검증 절차를 다룹니다. 목록에 등재되어 있다는 사실만으로 통과시켜서는 안 되는 이유와, 직접 확인해야 할 항목을 순서대로 정리합니다.
검증 실행 환경: Node.js 24.14.1, curl 8.18.0, 2026년 9월 11일 기준.
1. public-apis 저장소가 제공하는 것
public-apis는 MIT 라이선스로 공개된 목록형 저장소입니다. GitHub 저장소 기준 2026년 9월 11일 현재 스타 479k, 포크 52.8k를 기록하고 있습니다. 소개 문구는 “A collective list of free APIs”이며, 커뮤니티 기여자와 APILayer 소속 인원이 수동으로 큐레이션한다고 저장소가 명시합니다.
여기서 중요한 전제는 두 가지입니다. 첫째, 자동 수집이 아니라 수동 큐레이션이므로 등재 시점과 현재 상태가 어긋날 수 있습니다. 둘째, 저장소 상단에는 스폰서 제품 소개 영역이 별도로 존재하므로, 목록 본문과 홍보 영역을 구분해서 읽어야 합니다.
2. 목록 표의 여섯 개 컬럼을 읽는 법
공식 기여 가이드(CONTRIBUTING.md)에 따르면 각 항목은 API, Description, Auth, HTTPS, CORS, Call this API 여섯 개 컬럼으로 구성됩니다. 이 중 세 개 컬럼은 값의 집합이 문서로 고정되어 있습니다.
Auth 컬럼
허용되는 값은 OAuth, apiKey, X-Mashape-Key, User-Agent, No 다섯 가지입니다. No는 인증이 필요 없다는 뜻이고, User-Agent는 별도 키 없이 헤더만 요구한다는 의미입니다. 즉 apiKey가 아니라고 해서 아무 제약이 없는 것은 아닙니다.
CORS 컬럼
허용되는 값은 Yes, No, Unknown 세 가지입니다. 기여 가이드는 Unknown을 “CORS 지원 여부가 확인되지 않음”으로 정의합니다. 확인되지 않았다는 뜻이지 지원한다는 뜻이 아니므로, 브라우저에서 직접 호출할 계획이라면 Unknown은 No와 같게 취급하는 편이 안전합니다.
HTTPS와 Call this API 컬럼
HTTPS는 TLS 지원 여부를, Call this API는 공개된 Postman 컬렉션 링크 유무를 나타냅니다. 기여 가이드는 설명 길이를 100자 이내로 제한하고 섹션 내 알파벳 순서를 유지하도록 요구하므로, 표의 형식 자체는 비교적 일관됩니다.
3. CORS 값이 아키텍처를 결정하는 지점
기여 가이드는 다음과 같이 못 박습니다.
적절한 CORS 설정이 없으면 해당 API는 서버 사이드에서만 사용할 수 있다.
public-apis 공식 기여 가이드
이 한 문장이 실무에서는 구현 방식 자체를 가릅니다. CORS=No 또는 Unknown인 API를 프런트엔드에서 바로 호출하도록 설계했다면, 결국 백엔드 프록시 엔드포인트를 추가해야 합니다. 프록시가 생기면 인증 키 보관 위치, 타임아웃, 캐시 정책, 장애 시 폴백까지 함께 결정해야 하므로 작업량이 달라집니다. CORS의 동작 자체는 MDN 공식 문서를 참고하도록 합니다.
4. 등재 정보를 직접 재확인하는 절차
수동 큐레이션 목록이므로 등재 이후 엔드포인트가 바뀌거나 무료 구간이 축소됐을 수 있습니다. 채택 후보를 추린 뒤에는 아래 순서로 직접 확인하도록 합니다.
curl -s -o /dev/null -D - \
-H "Origin: https://example.com" \
"https://api.github.com/zen" \
| grep -iE "^HTTP|access-control-allow-origin|x-ratelimit"2026년 9월 11일 기준으로 위 명령을 실행하면 다음과 같은 응답 헤더를 확인할 수 있습니다.
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 59세 가지를 한 번에 얻을 수 있습니다. 응답 코드로 엔드포인트 생존을, Access-Control-Allow-Origin 헤더로 브라우저 직접 호출 가능 여부를, X-RateLimit-Limit 헤더로 미인증 호출 한도를 확인합니다. 목록의 CORS 컬럼과 실제 헤더가 다르면 실제 헤더를 따르도록 합니다.
5. 레이트 리밋과 키 관리에서 자주 놓치는 것
- 한도 단위가 분당인지 시간당인지, 그리고 IP 기준인지 키 기준인지를 문서에서 확인합니다. 서버 프록시를 두면 전체 트래픽이 단일 IP로 합산됩니다.
- 한도 초과 시 응답 코드가 429인지 403인지 확인하고, 재시도 로직에
Retry-After헤더 처리를 넣도록 합니다. Auth=No인 API도 사용 약관은 존재합니다. 상업적 이용 가능 여부와 출처 표기 의무를 별도로 확인합니다.- 키가 필요한 API는 프런트엔드 번들에 키를 넣지 않도록 합니다. 번들은 공개 자산입니다.
6. 목록 등재가 보장하지 않는 것
기여 가이드는 유료 솔루션 홍보를 위한 PR을 받지 않는다고 명시하고, 전면 무료이거나 최소한 무료 구간이 있어야 등재 가능하다고 규정합니다. 다만 이 규정은 등재 시점의 조건을 뜻하며 가용성, 응답 속도, 데이터 정확도, 지속적인 운영을 보증하지 않습니다.
목록은 후보를 좁히는 도구이지, 채택 근거가 아닙니다.
따라서 프로토타입 단계에서는 목록을 그대로 활용해도 무방하지만, 운영 환경에 투입할 때는 SLA와 대체 경로를 함께 준비하도록 합니다.
7. 정리: 언제 쓰고 언제 피해야 하는가
- 적합: 사이드 프로젝트, 학습용 예제, 기술 검증 단계에서 데이터 소스 후보를 빠르게 훑을 때.
- 조건부: 사내 서비스에 투입하되 프록시, 캐시, 폴백을 함께 설계할 수 있을 때.
- 부적합: 장애가 곧 매출 손실로 이어지는 핵심 경로. 이 경우 계약과 SLA가 있는 상용 API를 검토합니다.
정리하면 공개 API 검증은 목록 확인에서 끝나지 않습니다. 응답 헤더 실측, 약관 확인, 한도 설계까지 마친 뒤에야 채택 판단을 내릴 수 있습니다.
관련 글
외부 자원을 실무에 들일 때 함께 읽으면 좋은 글을 정리했습니다.
- AI 에이전트 권한, 내 노트북을 맡기기 전에 정해야 할 것 — 외부 도구에 권한을 여는 판단 기준을 다룬 글로, 본문 5절의 키 관리 항목과 이어집니다.
- 오픈소스 법적 리스크, 니터 사건이 개발자에게 주는 교훈 — 무료로 제공된다는 사실과 사용 약관은 별개라는 점을 사례로 설명합니다.
- 오픈소스 기여로 개발자 커리어 만들기: freeCodeCamp가 주는 시사점 — 목록형 저장소에 직접 기여하는 방법을 알아보려면 참고할 수 있습니다.
📌 함께 보시면 좋은 글
이직·퇴사·연봉 협상을 혼자 판단하기 어렵다면
1:1 개발자 커리어 상담 신청하기 →
※ 본 글은 AI(Claude)의 초안을 기반으로 편집자 검수를 거쳐 발행되었습니다. (한국 AI기본법 대응 고지)
이직·퇴사, 지금 움직여도 될지 헷갈리시나요?
막연히 불안한 건지, 정말 시점이 온 건지 판단이 어려울 때가 있습니다.
5분 체크리스트로 지금 상태를 먼저 정리해보세요.
결론을 대신 내리기보다, 스스로 판단할 기준을 잡는 데 도움을 드립니다.
아직 확신이 없다면, 지금이 ‘고민 단계’인지부터 먼저 점검해보세요