클라이언트가 "데이터는 어디서 가져오나요?"라고 물을 때 — 외주 개발사가 쓰는 API 지도

한줄 요약

외주 개발에서 "데이터를 어디서 가져올지" 결정하는 순간, 제품의 완성도가 절반은 정해진다.

앱 개발을 의뢰하는 클라이언트 대부분은 기능 목록을 들고 온다. "현재 위치 기반으로 주변 정보를 보여주세요", "날씨 정보를 화면에 띄워주세요", "아파트 실거래가를 조회할 수 있게 해주세요." 이런 요청들의 공통점이 하나 있다. 전부 외부 데이터가 필요하다는 것이다.

개발 업체 입장에서 이 데이터를 어떻게 확보하느냐는 단순한 기술 선택이 아니다. 비용 구조, 유지보수 부담, 서비스 안정성 전부가 여기서 갈린다. 직접 수집할지, 유료 서드파티를 쓸지, 공개된 API를 활용할지 — 이 판단이 프로젝트의 성패를 가른다.

왜 외주 개발에서 API 선택이 중요한가

앱이 하는 일의 본질은 데이터를 받아서 보기 좋게 정리해주는 것이다. 버튼은 그 심부름을 시키는 장치고, 화면은 결과를 담는 그릇이다. 그러니 "어떤 데이터를, 어디서, 얼마나 자주 받아올 수 있는가"가 서비스의 실질적인 스펙을 결정한다.

외주 개발사가 클라이언트에게 제안을 넣을 때 API 선택 기준을 명확히 설명하지 못하면 두 가지 문제가 생긴다. 하나는 런칭 후 예상치 못한 API 비용이 청구서에 등장하는 것, 다른 하나는 데이터 제공처의 정책이 바뀌었을 때 아무도 대응을 못하는 것이다. 둘 다 클라이언트와의 관계를 망가뜨린다.

도메인별로 어떤 API를 써야 하나

지도·위치 서비스를 붙일 때

위치 기반 서비스는 앱 개발 외주 요청 중 가장 빈번한 유형이다. 장소 검색, 경로 안내, 지도 표시가 묶여 들어오는 경우가 많다. 국내 서비스라면 카카오맵 API가 현실적인 첫 선택이다. 계정 하나로 지도 표시, 장소 검색, 경로 탐색을 한번에 연결할 수 있고, 별도 심사 절차 없이 키 발급 즉시 개발을 시작할 수 있다. 프로젝트 납기가 빡빡한 외주 현장에서 이 점은 작지 않다.

트래픽이 늘어날 경우 건당 과금 구조로 전환되므로, 제안서 단계에서 예상 호출량을 기반으로 원가를 계산해 클라이언트에게 미리 안내해두는 것이 좋다. 주소 변환만 필요한 경우라면 정부에서 무료로 제공하는 도로명주소 API로도 충분히 커버된다.

교통 실시간 데이터가 필요할 때

버스 도착 알림, 지하철 혼잡도 표시처럼 실시간성이 핵심인 서비스는 공공 교통 데이터를 쓰는 것이 기본이다. 서울 한정 서비스라면 지자체가 운영하는 교통 데이터 API가 밀도 면에서 가장 낫다. 전국 단위 서비스라면 국토부가 운영하는 통합 교통 정보 API를 검토해야 한다. 다만 전국 커버리지를 선택하면 데이터 정밀도와 실시간성은 일부 희생된다는 점을 클라이언트와 사전에 합의해야 한다.

공공 데이터는 요금이 없지만, "무료"가 곧 "자유롭게 상업 이용 가능"을 뜻하지 않는다. 데이터셋마다 이용 허락 범위가 다르다. 유료 서비스를 개발하는 경우라면 반드시 개별 데이터의 이용 조건을 확인하고 계약서에 명시해야 한다.

날씨 정보를 메인 또는 보조로 쓸 때

날씨는 단독 기능으로 쓰기도 하지만, 다른 서비스에 붙이는 보조 레이어로 활용하는 경우가 많다. 야외 활동 앱에 날씨를 결합하거나, 농업·물류 관련 서비스에 기상 데이터를 덧붙이는 식이다. 기상청이 공개하는 단기예보 API는 읍·면·동 단위 격자로 날씨를 제공하며, 예제 코드와 커뮤니티 자료가 풍부해 개발 속도를 높이기 좋다. 미세먼지 데이터는 별도 환경부 계열 API에서 시간 단위로 받아올 수 있다. 기상 데이터의 경우 출처 표기 조건만 지키면 상업 서비스에도 활용 가능한 경우가 많아, 부업이나 SaaS 형태의 제품 개발을 고려하는 클라이언트에게도 추천할 수 있다.

금융 데이터를 다루는 서비스라면

주식 시세, 환율, 금리를 다루는 서비스는 데이터의 신선도와 용도에 따라 API 선택이 완전히 달라진다. 실시간 호가가 필요하다면 증권사 오픈 API를 써야 한다. 최근 일부 증권사가 웹소켓 기반 실시간 데이터를 심사 없이 제공하기 시작했고, AI 코딩 도구와 연계할 수 있도록 문서 구조까지 갖춰둔 곳도 생겼다. 전일 종가 수준의 정보로 충분하다면 금융 당국이 공개하는 주식 시세 API를 공공데이터포털에서 받아 쓰는 것이 비용 면에서 유리하다.

중요한 것은 증권사 API 대부분이 본인 계좌 자동매매 용도로 설계되어 있다는 점이다. 받아온 시세를 제3자에게 상업적으로 재제공하는 것은 약관상 어렵다. 금융 서비스를 만드는 외주 개발사라면 클라이언트에게 이 한계를 명확히 설명해야 나중에 분쟁이 생기지 않는다.

부동산 실거래가 서비스

부동산 앱 개발 외주는 꾸준히 들어오는 유형이다. 특정 지역 실거래가 조회, 관심 단지 가격 변동 알림, 전세가율 계산 등이 주된 기능이다. 국토부가 제공하는 아파트 매매 실거래 API는 법정동 코드와 계약 연월만 입력하면 해당 지역의 실거래 목록 전체를 반환한다. 공공 승인 데이터라 상업적 이용도 가능하다.

이 데이터의 특성상 계약 이후 실제 신고까지 시간이 걸리기 때문에, 실시간 시세를 원하는 클라이언트라면 기대치를 조정해야 한다. 반면 한 달 정도 늦게 나오더라도 법적 효력이 있는 공식 거래 데이터라는 신뢰성은 유료 서드파티 데이터와 비교해도 충분히 강점이 된다. "신선도보다 공신력"이라는 이 특성을 기획 단계부터 클라이언트와 공유하면 기능 설계가 훨씬 명확해진다.

---

외주 개발에서 API를 제안할 때 체크해야 할 것들

실제 외주 프로젝트에서 API 선택은 기술팀의 결정으로 끝나서는 안 된다. 클라이언트가 이해하고 동의해야 할 항목이 반드시 있다.

첫째, 트래픽 증가 시 비용 구조. 무료 티어로 시작해도 사용자가 늘면 과금이 시작된다. 예상 사용자 수를 기반으로 API 비용을 미리 시뮬레이션해 제안서에 포함해야 한다.

둘째, 이용 약관과 상업 이용 가능 여부. 공공 API는 데이터셋마다 조건이 다르고, 민간 API는 재판매·재제공에 제한을 거는 경우가 많다. 서비스가 수익을 낼 구조라면 이 확인이 선행되어야 한다.

셋째, API 단종이나 정책 변경 리스크. 외부 API에 의존하는 이상 제공처의 정책이 바뀌면 서비스가 흔들린다. 대체 가능한 API가 있는지, 있다면 전환 비용이 얼마나 드는지를 설계 단계에서 검토해두는 것이 책임 있는 개발사의 역할이다.

좋은 외주 개발사는 "기능을 만들어드립니다"가 아니라 "이 데이터로, 이 구조로, 이 리스크를 안고 갑니다"를 설명할 수 있어야 한다.