API로 남의 기능 가져다 쓰기

지도, 날씨, 결제, 메일 전송. 이런 기능을 처음부터 직접 만든다면 까마득해요. 그런데 사실 만들 필요가 없어요.

누군가 이미 잘 만들어뒀거든요. 그걸 빌려서 내 소개 페이지에 붙이면 돼요. 그 창구가 바로 API예요.

지난 편(Part 6)에서 데이터 저장을 서비스에 맡겼죠. 기능도 똑같이 빌릴 수 있어요. 원리가 같아요. 우리 페이지로 치면 방문자가 나한테 연락하는 문의 폼이 좋은 예인데, 이것도 메일 보내는 기능을 빌려다 붙이는 거예요. 뒤에서 다시 나와요.

이 편에서 얻는 것:

• API가 뭔지 비유로 이해하기
• API 키가 뭔지, 그리고 키 없이 쓰는 API도 있다는 것
• AI에게 “이거 붙여줘” 하고 시키는 흐름
• 빌려 쓰는 것만이 아니라, 내 API도 만들 수 있다는 것

API는 전화 주문과 같아요

API를 가장 빠르게 이해하는 방법은 전화 주문 비유예요.

내 페이지가 손님이고, 다른 서비스(지도 회사, 날씨 회사 등)가 가게예요. 내 페이지가 가게에 전화를 걸어 “오시는 길 지도 데이터 주세요”라고 주문(요청)하면, 가게가 결과물(응답)을 보내줘요.

주방이 어떻게 요리하는지 몰라도 주문하고 받으면 되죠. 지도 회사 내부 코드가 어떻게 도는지 몰라도, 결과만 받아서 쓰면 돼요.

API는 두 프로그램이 대화하는 창구예요. 내 페이지가 다른 서비스에 “이거 해줘”라고 요청하면, 그 서비스가 결과를 돌려주는 방식이죠.

API 키가 뭔데요

빌려 쓰는 기능에는 대부분 출입증이 필요해요. 그게 API 키예요.

가게에 “저 여기 회원이에요”를 증명하는 회원증이라고 보면 돼요. 서비스에 가입하면 키라는 긴 문자열을 하나 발급해줘요. 그걸 요청할 때 함께 보내면 “정식 손님”으로 인정해주는 거예요.

키가 없으면 요청이 거절돼요. 단순해요.

키를 실어 보내면, 실제론 이런 걸 주고받아요. 날씨를 예로 들면요.

키 보안, 즉 절대 코드에 노출하면 안 되는 이유는 Part 9에서 자세히 다뤄요.

키가 꼭 필요한 건 아니에요

방금 ‘대부분’이라고 했죠. 뒤집으면, 키 없이 그냥 쓰는 API도 있어요. 무엇을 주느냐에 따라 갈려요.

• 키 없이 바로 쓰는 것. 누가 봐도 되는 조회성 정보요. 환율이나 사전처럼 공개돼도 괜찮은 데이터엔 가입도 키도 없이 되는 게 있어요.
• 키가 필요한 것. 돈이 오가는 결제, 개인 계정을 건드리는 메일 발송, 사용량을 재 과금하는 서비스요. 지도·결제·메일이 보통 이쪽이에요.

간단한 감으로는, ‘아무나 봐도 되는 정보’는 키 없이, ‘돈·개인·민감한 기능’은 키가 필요하다고 보면 얼추 맞아요.

그리고 헷갈리기 쉬운 말 하나. 오픈 API는 ‘외부 누구나 쓰라고 공개한 API’라는 뜻이지, ‘키가 필요 없다’는 뜻이 아니에요. 키 없이 바로 되는 것도, 무료로 가입해 키만 받으면 되는 것도 다 오픈 API예요. 그러니 ‘오픈이니까 공짜·무제한’으로 넘겨짚지 말고, 서비스 안내에서 키가 필요한지·무료 한도가 얼마인지만 확인하면 돼요.

무료지만 한 번 신청해서 키를 받아 쓰는 중간 지대도 있어요. 대표가 공공데이터예요. 정부가 버스 도착 시간, 날씨, 미세먼지 같은 정보를 무료로 열어뒀거든요. 공공데이터포털에서 무료로 신청하면 키를 주고, 그 키로 데이터를 받아와요. 예를 들어 우리 동네 미세먼지나 버스 도착 시간을 가져와 내 페이지에 띄우면, 그럴듯한 생활정보 페이지 하나가 나오죠. ‘뭘 만들지’ 막막할 때 이런 공개 데이터가 좋은 재료가 돼요.

그래서 어떻게 붙이나

서비스마다 세부 절차는 달라도, 큰 흐름은 세 단계로 같아요. 키가 필요 없는 API면 2번만 건너뛰면 되고요.

3단계에서 쓸 프롬프트 (복붙용)

내 페이지에 [기능 이름] 기능을 붙이고 싶어.
[서비스 이름] API를 쓰려고 해. 내가 만든 건 index.html 한 파일짜리 정적 웹페이지야(빌드 도구 없이 브라우저에서 바로 여는 방식).
연동 코드를 써주고, API 키는 어디에 어떤 형식으로 넣어야 하는지 알려줘.
키가 꼭 필요한 API라면, 키를 안전하게 두는 자리도 초보자 기준으로 알려줘.

중요한 건 키를 프롬프트에 그대로 붙여 넣지 않는 것이에요. AI가 “키는 이 파일에 이렇게 넣으세요” 하고 위치와 형식을 알려주면, 그 자리에 내 키를 직접 넣어요. 키는 남에게 보이면 안 되는 값이라, 코드에도 채팅에도 노출하지 않는 게 기본이에요.

키를 발급받고 안전하게 두는 게 막막하면, 그 부분만 따로 더 물어도 돼요. 어떤 서비스의 API를 쓰는지, 어떤 도구로 만드는지 적고 보안까지 같이 물으면 단계로 짚어줘요. 이런 식으로요.

나는 index.html 한 파일짜리 정적 페이지에 [서비스 이름] API를 붙이려고 해.
1. 이 서비스에서 API 키를 어디서 발급받는지
2. 이 키가 브라우저에 노출돼도 되는 키인지, 숨겨야 하는 키인지
3. 숨겨야 하는 키라면 어디에 어떻게 두는지
초보자 기준으로 순서대로 알려줘.

알려주는 대로 따라 하면 되고, 막히는 단계가 나오면 그 화면이나 에러를 그대로 붙여 다시 물어보면 돼요.

뭘 붙일 수 있나

API로 제공되는 기능은 생각보다 많아요. 내가 만든 게 아니라 연결해서 쓰는 것이죠.

그중 하나가 문의 폼이에요. 우리 소개 페이지에 방문자가 남긴 메시지를 폼 전송 서비스에 태우면, 서버 한 줄 없이 내 메일함으로 받을 수 있어요. 이건 바로 아래에서 실제로 붙여요.

소개 페이지에 문의 폼 달기 (키 없이)

위에서 예로 든 문의 폼, 이제 진짜로 붙여요. 이게 API 붙이기 중에 제일 쉬운 축이에요. 키도 필요 없거든요.

원리는 이래요. 방문자가 폼에 남긴 내용을 폼 전송 서비스가 대신 받아서 내 메일로 보내줘요. 서버도, 비밀키도 없어요. 앞에서 말한 ‘키를 대신 들어주는 완성형 서비스’가 딱 이거죠. 대표적으로 Formspree 같은 게 있어요.

2단계에서 쓸 프롬프트 (복붙용)

내 index.html 한 파일짜리 소개 페이지에 문의 폼을 추가해줘.
이름·이메일·메시지 입력칸과 보내기 버튼이 있고,
Formspree로 제출되게 form의 action을 아래 주소로 해줘.
action 주소: https://formspree.io/f/xxxxxx  (내가 받은 주소로 바꿔 넣을게)
디자인은 지금 페이지랑 어울리게, 모바일에서도 잘 보이게.

받은 코드에서 내가 확인할 건 딱 한 줄, 이 부분이에요.

<!-- 이 주소만 내 Formspree 주소로 바꾸면 돼요 -->
<form action="https://formspree.io/f/xxxxxx" method="POST">
  <input name="name" placeholder="이름" />
  <input name="email" type="email" placeholder="이메일" />
  <textarea name="message" placeholder="메시지"></textarea>
  <button type="submit">보내기</button>
</form>

무료로 월 50건쯤 받을 수 있어요(플랜은 바뀔 수 있으니 요금 안내에서 확인하면 정확해요). 처음엔 넉넉하죠. 스팸이 걱정되면 서비스가 기본 차단을 켜줘요.

빌리기만 하는 게 아니에요, 만들 수도 있죠

지금까지는 남의 가게에 전화 거는 쪽이었어요. 그런데 API는 방향이 하나 더 있어요. 내가 가게가 되는 것, 즉 내 API를 만드는 쪽이에요.

사실 이미 하나 만들었어요. Part 6에서 Supabase에 목록 테이블을 만들었을 때, 그 데이터를 주고받는 통로(API)가 자동으로 같이 생겼죠. 내 화면이 그 통로로 목록을 읽고 써요. 모르는 사이 내 API를 쓰고 있던 셈이죠.

그럼 일부러 만드는 건 언제일까요? 가장 흔한 이유는 키를 숨기려고예요.

조금 전에 결제·메일 같은 API엔 키가 필요하다고 했죠. 그 키를 화면(브라우저) 코드에 그냥 두면 누구나 들여다볼 수 있어요. 그래서 중간에 내 작은 서버를 하나 둬요. 지금까진 완성된 파일 하나를 올려두면 끝이었는데, 서버는 요청이 올 때마다 켜져서 대신 일해주는 컴퓨터예요. 내 화면은 내 서버에 부탁하고, 내 서버가 키를 들고 진짜 서비스에 요청하는 거죠. 키는 서버 안에 숨고요.

여기서 딱 하나는 정직하게 짚어야 해요. 이 ‘작은 서버’는 지금까지처럼 파일을 드래그해 올리는 걸 넘어서요. 정적 파일이 아니라 코드가 도는 자리라, 올리고 관리하는 게 확 무거워지거든요. 솔직히 비전공자가 처음 혼자 하기엔 벅찬 구간이에요.

그래서 입문 땐 순서를 이렇게 잡는 게 나아요.

정리하면 API는 빌릴 수도, 만들 수도 있다. 다만 ‘내가 서버까지 만드는’ 쪽은 급하지 않아요. 키를 안전하게 다루는 원칙은 Part 9에서 이어가요.

자주 묻는 질문

레스덕의 정리

저는 새 걸 만들 때 “이거 굳이 내가 짜야 하나?”부터 물어요. 지도, 결제, 메일, 로그인. 대개 잘 만들어둔 게 이미 있거든요. 실무에서 제가 일하는 방식도 똑같아요.

다 만들려 하면 끝이 안 나요. 잘 만들어진 걸 찾아 조립하는 눈, 그게 더 빠르고 안전해요.

다만 빌려 쓰는 건 남의 서비스에 기대는 거라, 그쪽이 가격을 바꾸거나 문을 닫으면 내 페이지도 흔들려요. 실무에선 이 의존성을 늘 염두에 둬요. 입문 땐 ‘되는 것부터’ 붙이고, 의존도가 커지면 그때 따지면 돼요. 그 순서는 현직이라고 다르지 않더라고요.

기능을 붙이다 보면 빨간 에러를 만나기 마련이에요. Part 8은 그 에러를 겁내지 않고 푸는 법이에요.