API·REST가 뭐길래
— 프로그램끼리 주문을 주고받는
'창구'

제가 처음 앱이라는 걸 만들어보겠다고 덤볐을 때 이야기부터 해볼게요. 저는 날씨 정보를 보여주는 아주 간단한 앱을 만들고 싶었어요. 그런데 만들다 보니 근본적인 질문에서 딱 막히더라고요. "잠깐, 그럼 오늘 서울 날씨가 맑은지 흐린지, 이 정보는 내가 직접 하늘을 보고 입력해야 하나?" 당연히 아니잖아요. 그렇다면 이 날씨 정보는 대체 어디서, 어떻게 내 앱 안으로 들어오는 걸까요?

지도도 마찬가지였어요. 저는 지구를 한 바퀴 돌며 도로를 다 그린 적이 없는데, 어떻게 제 앱에 지도가 척 뜨는 걸까요? 결제는요? 제가 카드사 전산실을 직접 운영하는 것도 아닌데 어떻게 "결제 완료"가 되는 걸까요? 처음엔 이게 다 마법처럼 느껴졌습니다. 그런데 이 모든 마법의 뒤에 딱 하나의 공통된 원리가 숨어 있더라고요. 그게 바로 오늘의 주인공, API(에이피아이)입니다.

API라는 단어를 처음 들으면 무슨 암호 같죠. 저도 그랬어요. 그런데 알고 보니 이건 우리가 매일 식당에서 하는 그 일과 똑같은 개념이더라고요. 오늘은 이 API라는 걸, 코드 한 줄 몰라도 완전히 이해할 수 있도록 식당 이야기로 풀어드릴게요. 겁먹지 마세요. 다 읽고 나면 "아, 이거였어?" 하실 겁니다.

API = 식당의 메뉴판 + 주문 창구예요. 손님(내 앱)은 주방(서버) 안이 어떻게 생겼는지, 요리사가 몇 명인지, 불을 어떻게 쓰는지 전혀 몰라도 됩니다. 그냥 메뉴판에 적힌 대로 주문하면, 완성된 요리(결과)가 창구로 나온다. 이게 API의 전부예요.

이 한 문장만 붙잡고 계셔도 오늘 글의 절반은 챙긴 겁니다. 이제 이 식당 비유를 하나씩 늘려가며, API가 뭔지, 요청과 응답이 뭔지, 요즘 다들 말하는 REST가 뭔지, 그리고 초보가 꼭 알아야 할 API 키와 보안까지 천천히 풀어볼게요.

API가 뭔가요 — 주방을 몰라도 주문할 수 있게 해주는 창구

먼저 상상을 해볼게요. 여러분이 식당에 갔어요. 배가 고파서 김치찌개가 먹고 싶습니다. 그럼 여러분은 어떻게 하나요? 주방에 직접 들어가서 냄비를 꺼내고 불을 켜나요? 당연히 아니죠. 그건 위험하기도 하고, 애초에 손님은 주방에 들어갈 수 없어요. 대신 여러분은 메뉴판을 봅니다. 거기 적힌 "김치찌개 9,000원"을 보고, 종업원에게 "김치찌개 하나요"라고 주문하죠. 그럼 잠시 뒤 김치찌개가 완성돼서 여러분 앞에 나옵니다.

여기서 아주 중요한 점이 하나 있어요. 여러분은 주방 안에서 무슨 일이 벌어지는지 하나도 몰라도 됩니다. 요리사가 몇 명인지, 김치를 어디서 사 오는지, 불 세기를 어떻게 조절하는지 전혀 신경 쓸 필요가 없어요. 그냥 "메뉴판에 있는 것을, 정해진 방식으로 주문하면, 결과가 나온다"는 약속만 지키면 됩니다. 이 약속된 창구가 바로 API예요.

왜 이런 창구가 필요할까요? 만약 창구가 없다면 어떻게 될지 상상해보세요. 손님이 저마다 주방에 마음대로 들어와서 "나 김치찌개 끓일게" 하고 냄비를 집어 든다면 주방은 아수라장이 될 거예요. 위생도 엉망이 되고, 요리사끼리 부딪히고, 누가 뭘 가져갔는지도 모르게 되죠. 그래서 식당은 "주문은 창구로만 받습니다"라고 벽을 세워둔 겁니다. 그 덕분에 주방은 안전하게 자기 일에만 집중할 수 있고, 손님은 복잡한 주방 사정을 몰라도 편하게 밥을 먹을 수 있어요.

프로그램 세계도 똑같아요. 여러분의 날씨 앱이 기상청 컴퓨터 안에 마음대로 들어가서 데이터를 헤집는다고 생각해보세요. 끔찍하죠. 그래서 기상청은 "날씨 정보가 필요하면, 정해진 창구(API)로 요청하세요. 그러면 제가 정리된 결과를 드릴게요"라고 문을 하나 열어둔 겁니다. 이 창구 덕분에 세상의 수많은 프로그램들이 서로의 내부를 몰라도 필요한 것을 주고받을 수 있게 된 거예요.

제가 이 개념을 처음 이해했을 때 정말 후련했어요. 그동안 "내 앱은 어떻게 날씨를, 지도를, 환율을 다 아는 거지?"라는 질문이 풀렸거든요. 답은 간단했어요. 내 앱이 다 아는 게 아니라, 아는 곳에 물어보는 것이었어요. 그 "물어보는 창구"가 API고요.

API가 없다면 — 매번 바퀴를 새로 만드는 고통

API가 왜 이렇게 중요한지 확 와닿게 하려면, 반대로 "API가 없는 세상"을 상상해보는 게 제일 빨라요. 제가 날씨 앱을 만든다고 했잖아요. API가 없다면 저는 어떻게 해야 할까요? 전국에 관측소를 세우고, 온도계와 습도계를 사서 설치하고, 24시간 데이터를 측정하고, 그걸 실시간으로 정리하는 시스템을 직접 만들어야 해요. 앱 하나 만들려다 기상청을 통째로 차려야 하는 거죠. 말도 안 되잖아요.

지도도 마찬가지예요. 지도 API가 없다면 저는 위성을 띄우고 전 세계 도로를 측량해야 해요. 결제도 API가 없다면 카드사, 은행과 일일이 계약하고 복잡한 금융 전산망을 직접 뚫어야 하고요. 이건 개인은커녕 웬만한 회사도 감당 못 할 일이에요.

그런데 API 덕분에 이 모든 게 "창구에 물어보기" 한 번으로 해결돼요. 날씨는 기상 서비스에, 지도는 지도 서비스에, 결제는 결제 서비스에 창구로 부탁하면 되니까요. 세상에서 제일 잘하는 전문가들이 만들어둔 기능을, 나는 그 내부를 몰라도 가져다 쓰기만 하면 되는 거예요. 개발자들이 흔히 하는 말 중에 "바퀴를 다시 발명하지 말라"는 게 있어요. 이미 잘 굴러가는 바퀴(API)가 있는데 굳이 처음부터 다시 만들 필요가 없다는 뜻이죠. API는 바로 그 "이미 만들어진 훌륭한 바퀴"를 빌려 쓰는 통로예요.

저는 이 사실을 깨닫고 나서 앱 만들기가 갑자기 만만해졌어요. "아, 내가 세상 모든 걸 다 만들 필요가 없구나. 필요한 건 창구에서 빌려 오고, 나는 그걸 어떻게 조합해 멋진 서비스를 만들지만 고민하면 되는구나." 이게 현대 앱 개발의 핵심이에요. 대부분의 앱은 사실 여러 API를 똑똑하게 조합한 결과물이거든요.

요청과 응답 — 주문표를 보내면 요리가 나온다

이제 창구에서 실제로 오가는 게 뭔지 볼게요. API에서 벌어지는 일은 딱 두 가지로 정리됩니다. 요청(Request)과 응답(Response)이에요. 식당으로 치면 "주문"과 "나온 요리"죠. 이 둘이 한 쌍으로 오가는 게 API 통신의 전부예요. 정말 이게 다예요.

요청은 손님인 내 앱이 "이거 주세요"라고 보내는 주문표예요. 응답은 주방인 서버가 "여기 있습니다"라고 돌려주는 결과물이고요. 손님이 먼저 요청을 보내야만 응답이 옵니다. 손님이 가만히 있는데 요리가 저절로 나오지는 않죠. (참고로 이 순서를 뒤집는 특별한 방식도 있는데, 그건 뒤에서 '웹훅'으로 따로 설명할게요.)

엔드포인트 — 창구의 주소

그런데 큰 식당에는 창구가 여러 개일 수 있어요. "음료 주문은 1번 창구, 디저트는 2번 창구, 포장은 3번 창구" 이런 식으로요. API도 똑같아요. 날씨 정보를 받는 주소, 지역 목록을 받는 주소, 예보를 받는 주소가 각각 따로 있어요. 이렇게 "무엇을 요청할지"에 따라 정해진 각각의 주소를 엔드포인트(Endpoint)라고 불러요.

엔드포인트는 우리가 웹사이트 주소(URL)를 입력하듯 생긴 주소예요. 예를 들면 https://api.날씨.com/현재날씨 이런 식이죠. 뒤에 붙는 /현재날씨 부분이 "아, 이 손님은 현재 날씨 창구로 왔구나"를 알려주는 거예요. 만약 예보가 필요하면 /예보라는 다른 창구 주소로 가면 되고요. 어렵게 생각할 것 없어요. 엔드포인트 = 목적별로 나뉜 창구의 주소, 이렇게만 기억하시면 됩니다.

응답은 어떻게 생겼나 — JSON이라는 정리된 상자

자, 요청을 보냈으면 응답이 옵니다. 그런데 이 응답이 그냥 줄글로 "오늘 서울은 맑고 기온은 28도이고 습도는 60퍼센트입니다"라고 오면 프로그램이 읽기가 어려워요. 사람은 읽을 수 있지만 컴퓨터는 어디까지가 기온이고 어디부터가 습도인지 헷갈리거든요. 그래서 프로그램끼리는 깔끔하게 칸이 나뉜 상자에 담아서 주고받아요. 이 상자의 이름이 JSON(제이슨)이에요.

JSON은 어렵지 않아요. "이름표: 값" 형태로 정리된 목록이라고 보시면 돼요. 우리가 택배 상자에 "내용물: 책, 무게: 2kg, 받는사람: 김부장"이라고 라벨을 붙이는 것과 똑같아요. 실제로 날씨 API의 응답은 대략 이렇게 생겼어요.

{ "도시": "서울", "날씨": "맑음", "기온": 28, "습도": 60 }

보세요, 전혀 무섭지 않죠? "도시"라는 이름표에 "서울"이라는 값이 붙어 있고, "기온"이라는 이름표에 28이라는 값이 붙어 있어요. 내 앱은 이 상자를 받아서 "아, 기온 칸을 보니 28이구나. 그럼 화면에 28도라고 크게 띄워야지" 하고 꺼내 쓰는 거예요. 이렇게 이름표가 딱딱 붙어 있으니 컴퓨터가 헷갈리지 않고 원하는 값을 쏙쏙 골라 쓸 수 있는 거죠.

HTTP 메서드 — 창구에서 하는 네 가지 부탁

이제 조금 더 들어가 볼게요. 손님이 창구에서 하는 부탁에도 종류가 있잖아요. "이 메뉴 좀 보여주세요(조회)", "이거 주문할게요(등록)", "아까 주문한 거 곱빼기로 바꿔주세요(수정)", "그 주문 취소할게요(삭제)". API에서도 이렇게 부탁의 종류를 구분하는 방법이 있는데, 그게 바로 HTTP 메서드예요.

메서드라는 말이 딱딱하게 들리지만, 그냥 "내가 지금 하려는 게 조회냐, 등록이냐, 수정이냐, 삭제냐"를 표시하는 꼬리표라고 보시면 돼요. 대표적인 네 가지가 있는데, 우리말로 바꾸면 이렇게 착 정리됩니다.

어때요, 생각보다 직관적이죠? 우리가 일상에서 데이터를 다룰 때 하는 일이 결국 이 네 가지예요. 보고(조회), 새로 만들고(등록), 고치고(수정), 지우고(삭제). 개발자들은 이 네 가지를 묶어서 영어 앞글자를 따 CRUD(크러드)라고 부르기도 해요. Create(만들기), Read(읽기), Update(수정), Delete(삭제)의 앞글자죠. 그냥 별명이니 부담 갖지 마세요.

제가 이걸 배울 때 가장 헷갈렸던 건 GET과 POST의 차이였어요. 쉽게 구분하는 팁을 하나 드릴게요. GET은 세상을 바꾸지 않는 부탁이에요. 메뉴판을 백 번 봐도 식당에 아무 일도 안 생기잖아요. 반면 POST는 세상에 뭔가를 새로 만드는 부탁이에요. 주문을 넣으면 주방에 실제로 새 요리가 시작되죠. 그래서 회원가입, 글쓰기, 결제 같은 "실제로 뭔가 생기는 일"은 대부분 POST를 써요. 반대로 목록 보기, 검색 결과 보기처럼 "그냥 구경만 하는 일"은 GET을 쓰고요.

이 메서드 개념은 나중에 데이터베이스 이야기를 읽으실 때도 그대로 이어져요. 결국 데이터를 넣고, 빼고, 고치고, 지우는 게 프로그램의 본질이거든요. API는 그 일을 창구 너머로 부탁하는 방법일 뿐이에요.

REST가 뭔가요 — 창구를 정리하는 깔끔한 규칙

자, 이제 그 유명한 REST(레스트)가 나올 차례예요. 사람들이 "REST API로 만들었어요"라는 말을 정말 많이 하는데, 처음엔 이게 무슨 대단한 기술인 줄 알았어요. 그런데 알고 보니 REST는 새로운 프로그램이 아니라, API 창구를 깔끔하고 일관되게 정리하는 약속(스타일)이더라고요.

다시 식당으로 돌아가 볼게요. 어떤 식당은 창구가 엉망진창이에요. 김치찌개는 1번 창구에서 시키는데 취소는 뒷문으로 가야 하고, 곱빼기 변경은 사장님한테 전화를 해야 해요. 손님 입장에서 얼마나 헷갈리겠어요? 반면 잘 정리된 식당은 규칙이 명확해요. "모든 메뉴는 같은 창구에서, 주문은 이렇게, 취소는 저렇게"라고 딱 정해져 있죠. REST는 바로 이 "잘 정리된 식당"의 규칙 같은 거예요.

REST의 핵심 아이디어는 딱 두 가지로 요약돼요. 첫째, 모든 것을 '자원(자료)'으로 보고, 그 자원마다 고유한 주소를 준다. 둘째, 그 자원에 무슨 일을 할지는 앞에서 배운 메서드(조회·등록·수정·삭제)로 표현한다. 말이 어렵죠? 예를 들어볼게요.

회원 정보를 다루는 API가 있다고 해봐요. REST 방식에서는 "회원"이라는 자원에 /회원이라는 주소를 하나 딱 정해둬요. 그리고 이 하나의 주소에서 메서드만 바꿔가며 모든 일을 처리해요.

보세요, 얼마나 깔끔해요. 주소는 "무엇을(자원)", 메서드는 "어떻게(행동)"를 나타내요. 주소만 봐도 "아, 회원을 다루는구나", 메서드만 봐도 "아, 목록을 보는구나(GET)"를 알 수 있죠. 이렇게 규칙이 일관되면 처음 보는 API라도 금방 감을 잡을 수 있어요. 그래서 전 세계 개발자들이 이 REST 스타일을 표준처럼 쓰는 거예요.

상태코드 — 주문이 어떻게 됐는지 알려주는 번호

식당에서 주문하면 결과가 여러 가지죠. "네, 나왔습니다!"(성공)일 수도 있고, "손님, 그 메뉴는 저희 집에 없어요"(그런 메뉴 없음)일 수도 있고, "죄송해요, 주방에 불이 나서 지금 요리를 못 해요"(주방 사고)일 수도 있어요. API도 응답을 줄 때 이 "결과가 어떻게 됐는지"를 숫자 번호로 함께 알려줘요. 이걸 상태코드(Status Code)라고 해요.

상태코드는 세 자리 숫자인데, 처음엔 종류가 많아 보여도 큰 그림만 알면 돼요. 200번대는 성공, 400번대는 손님 잘못, 500번대는 주방(서버) 잘못이에요. 이 세 덩어리만 기억하시면 절반은 끝난 거예요. 대표적인 것 세 개를 식당 비유로 정리해볼게요.

인터넷 하다가 "404 페이지를 찾을 수 없습니다"라는 화면 본 적 있으시죠? 그게 바로 이 404예요. 여러분이 없는 주소로 들어가니 서버가 "그런 거 없는데요?"라고 404 번호를 돌려준 거죠. 이제 그 화면을 보면 무슨 뜻인지 아시겠죠?

이 상태코드가 왜 중요하냐면, 내 앱이 응답을 받았을 때 이 번호를 보고 다음 행동을 결정하기 때문이에요. 200이 오면 "좋아, 데이터를 화면에 보여주자"고 하고, 404가 오면 "찾는 게 없네, 사용자에게 '결과 없음'이라고 안내하자"고 하고, 500이 오면 "서버가 아프네, 잠시 후 다시 시도하라고 하자"고 판단하는 거예요. 그래서 좋은 앱은 항상 이 번호를 꼼꼼히 확인해요. (이걸 안 하면 어떤 사고가 나는지는 뒤 '초보 실수' 편에서 이야기할게요.)

아주 쉬운 예시 — 날씨 API 한 번 호출해보기

지금까지 배운 걸 한 흐름으로 이어볼게요. 여러분의 날씨 앱이 "서울 날씨"를 화면에 띄우기까지, 창구 너머로 무슨 일이 오가는지 순서대로 따라가 봅시다. 코드는 없어요. 그냥 흐름만 보시면 돼요.

하나씩 풀어볼게요. 우리가 배운 용어가 다 나오니 복습이라 생각하고 보세요.

어때요? 마법 같던 일이 이제 한 편의 이야기처럼 보이시죠? 세상의 거의 모든 앱이 이 흐름을 수도 없이 반복하면서 돌아가요. 지도를 띄울 때도, 결제를 할 때도, 로그인을 할 때도, 전부 이 "요청 → 처리 → 응답"의 왕복이에요. 이 한 흐름만 머릿속에 그려지면 여러분은 이미 API의 핵심을 이해하신 거예요.

API 키와 인증 — "누가 부르는지" 확인하는 회원카드

여기서 중요한 질문이 하나 생겨요. 창구가 아무한테나 열려 있으면 어떻게 될까요? 나쁜 사람이 하루에 수백만 번씩 창구를 두드려서 서버를 마비시킬 수도 있고, 유료로 파는 정보를 공짜로 퍼갈 수도 있어요. 그래서 대부분의 API는 "당신 누구세요?"를 확인하는 절차를 둬요. 이걸 인증(Authentication)이라고 하고, 그 신분증 역할을 하는 게 API 키(API Key)예요.

API 키는 회원제 창고의 회원카드나 놀이공원의 입장 팔찌 같은 거예요. 여러분이 어떤 서비스에 가입하면 길고 복잡한 문자열로 된 키를 하나 줘요. 예를 들면 sk-3f9a2b... 같은 거죠. 그럼 여러분의 앱은 창구에 요청을 보낼 때마다 이 키를 함께 내밀어요. 서버는 그 키를 보고 "아, 이건 정식 가입한 김부장님이구나. 통과!" 하고 요청을 처리해주는 거예요.

이 키 덕분에 서버는 여러 가지를 할 수 있어요. 누가 얼마나 요청했는지 세어서 요금을 매기고, 이상하게 많이 부르는 사람을 막고, 문제가 생기면 누가 그랬는지 추적하죠. 그러니 API 키는 여러분의 신분증이자 계좌 비밀번호 같은 거예요. 남이 알면 그 사람이 여러분 이름으로 창구를 이용하고, 그 요금은 여러분에게 청구될 수 있거든요. 이게 정말 중요해요.

절대 하면 안 되는 것 — 코드에 키를 그냥 적어두기

제가 초보 시절에 진짜 아찔했던 실수 이야기를 해드릴게요. 저는 API 키를 그냥 코드 파일 안에 내키 = "sk-3f9a2b..." 이렇게 적어뒀어요. 잘 돌아가니까 "됐다!" 하고 그 코드를 통째로 인터넷(깃허브)에 올렸죠. 그런데 그게 얼마나 위험한 일인지 나중에 알고 식은땀이 났어요. 인터넷에 올린 코드는 전 세계 누구나 볼 수 있잖아요. 제 신분증을 광장 한복판에 붙여둔 거나 마찬가지였어요.

그래서 반드시 지켜야 할 원칙이 있어요. API 키 같은 비밀 값은 코드 안에 직접 적지 말고, 코드 바깥의 안전한 곳에 따로 보관해야 해요. 이걸 "환경변수(환경 설정 값)"로 관리한다고 하는데, 쉽게 말하면 비밀은 비밀 서랍에 따로 넣어두고, 코드는 그 서랍을 열어보는 방식이에요. 코드에는 "비밀 서랍에서 키를 꺼내 쓴다"고만 적고, 정작 키 값 자체는 코드에 안 남기는 거죠.

웹훅 — 반대 방향의 알림

지금까지는 전부 "내 앱이 먼저 물어보고, 서버가 답하는" 방향이었죠. 손님이 주문해야 요리가 나오는 것처럼요. 그런데 반대 방향도 있어요. 서버가 먼저 내 앱에게 "이런 일이 생겼어요!"라고 알려주는 방식이죠. 이걸 웹훅(Webhook)이라고 해요.

식당으로 치면 이런 거예요. 요리가 오래 걸리는 집에서는 진동벨을 주잖아요. 손님이 "다 됐어요?"라고 계속 물으러 갈 필요 없이, 요리가 완성되면 벨이 먼저 울리는 거죠. 웹훅이 딱 이 진동벨이에요. 예를 들어 결제가 완료되거나, 배송이 시작되면, 그쪽 서버가 내 앱에게 먼저 "결제 완료됐어요!"라고 신호를 쏴주는 거예요. 그럼 내 앱은 굳이 1초에 한 번씩 "결제 됐나요? 됐나요?" 물어볼 필요가 없어요. 한 줄로 정리하면, 웹훅은 요청과 응답의 방향이 뒤집힌, 서버발(發) 알림이에요.

초보가 흔히 하는 실수 & 해결

이제 여러분이 API를 직접 써보실 텐데, 저를 포함한 초보들이 꼭 밟는 지뢰 세 개가 있어요. 미리 알려드릴 테니 여러분은 피해 가세요.

특히 세 번째, "응답 검증 안 하기"는 정말 흔해요. 저도 처음엔 응답이 항상 성공일 거라고 순진하게 믿었거든요. 그런데 네트워크는 늘 완벽하지 않아요. 서버가 잠깐 아플 수도 있고, 내가 주소를 잘못 쓸 수도 있어요. 그래서 "응답은 실패할 수도 있다"를 기본 전제로 깔고 코드를 짜야 앱이 튼튼해져요. 이건 겁주려는 게 아니라, 미리 알면 훨씬 마음 편하게 만들 수 있다는 뜻이에요.

자주 묻는 질문(FAQ)

Q. API를 쓰려면 코딩을 잘해야 하나요?
A. 아니에요. 개념은 오늘 배운 게 거의 전부예요. 요청 보내고, 응답 받고, JSON에서 값 꺼내 쓰기. 요즘은 요청을 보내주는 도구도 잘 나와 있어서, 개념만 알면 코드는 예제를 조금씩 따라 하며 익힐 수 있어요. 저처럼 늦게 시작한 사람도 했으니 겁먹지 마세요.

Q. API는 다 공짜인가요?
A. 무료도 있고 유료도 있어요. 보통 "하루에 몇 번까지는 무료, 그 이상은 요금"인 경우가 많아요. 정확한 가격과 무료 사용량은 서비스마다 다르고 자주 바뀌니, 쓰려는 API의 공식 문서에서 직접 확인하는 게 가장 정확해요. 유료 API는 특히 사용량 관리를 잘하셔야 요금 사고를 막을 수 있어요.

Q. JSON 말고 다른 응답 형식도 있나요?
A. 있어요. 예전엔 XML이라는 형식을 많이 썼고, 지금도 일부 쓰여요. 하지만 요즘 새로 나오는 API는 대부분 JSON을 기본으로 줘요. 훨씬 가볍고 읽기 편하거든요. 그러니 초보 단계에서는 JSON만 익혀도 충분해요.

Q. REST 말고 다른 방식도 있다던데요?
A. 맞아요. GraphQL(그래프큐엘)이나 gRPC 같은 다른 스타일도 있어요. 각각 장점이 있죠. 하지만 REST가 여전히 가장 널리 쓰이고 이해하기 쉬워서, 첫 API는 REST로 시작하시길 권해요. REST를 제대로 이해하면 다른 방식은 나중에 필요할 때 금방 배울 수 있어요.

Q. 요즘 'MCP'라는 말도 들리던데, API랑 관련 있나요?
A. 좋은 질문이에요. AI 시대에 들어오면서, AI 에이전트가 여러 도구와 API를 표준화된 방식으로 연결해 쓰는 개념이 주목받고 있어요. 큰 흐름에서 보면 "프로그램끼리 약속된 방식으로 대화한다"는 API의 정신이 AI 도구 연결로 확장된 거라고 볼 수 있어요. 이 이야기는 에이전트와 스킬 이야기에서 더 다루니 관심 있으면 이어서 읽어보세요.

마무리 체크리스트 & 다음 글

오늘 정말 많은 걸 함께 걸었어요. 식당 메뉴판 하나로 시작해서 요청·응답, 엔드포인트, JSON, HTTP 메서드, REST, 상태코드, API 키, 웹훅까지 왔네요. 처음엔 외계어 같던 단어들이 이제 조금은 친근해지셨길 바라요. 마지막으로 오늘 챙긴 걸 체크리스트로 정리할게요.

• ✅ API는 프로그램끼리 주고받는 창구다 — 주방을 몰라도 메뉴로 주문하면 결과가 나온다.
• ✅ 통신은 요청과 응답의 왕복이다 — 엔드포인트(주소)로 보내고, JSON(정리된 상자)으로 받는다.
• ✅ HTTP 메서드는 조회(GET)·등록(POST)·수정(PUT)·삭제(DELETE), 즉 부탁의 종류다.
• ✅ REST는 자원은 주소로, 행동은 메서드로 표현하는 깔끔한 정리 규칙이다.
• ✅ 상태코드는 200(성공)·404(없음)·500(서버 오류), 즉 주문 결과 번호다.
• ✅ API 키는 신분증이다 — 절대 코드에 적지 말고 비밀 서랍(환경변수)에 넣는다.
• ✅ 웹훅은 반대 방향 알림 — 서버가 먼저 울려주는 진동벨이다.
• ✅ 항상 응답을 검증하고, 필요한 만큼만 부른다.

여기까지 오신 것만으로도 정말 대단해요. 저는 이 개념들을 이해하는 데 꽤 오래 걸렸는데, 여러분은 이 글 한 편으로 큰 그림을 잡으셨잖아요. API는 앞으로 뭘 만들든 계속 마주칠 친구예요. 오늘 이 지도를 손에 쥐었으니, 이제 어디서 API라는 단어가 튀어나와도 "아, 그 창구!" 하고 반갑게 맞이하실 수 있을 거예요.

다음 글에서는 오늘 잠깐 나온 두 가지를 더 깊이 파볼게요. 하나는 서버가 정보를 어디에 쌓아두는지, 즉 데이터베이스 이야기예요. API가 창구라면 데이터베이스는 그 뒤의 거대한 창고거든요. 또 하나는 오늘 신신당부한 환경변수와 비밀 관리예요. API 키를 안전하게 다루는 실전 방법을 손잡고 알려드릴게요. 그럼 다음 글에서 또 만나요. 오늘도 한 걸음 나아가신 여러분, 정말 잘하고 계세요.

(2026년 8월 기준 작성 — 각 API의 가격·사용량·정책·화면은 바뀔 수 있으니 쓰려는 서비스의 공식 문서를 함께 확인하세요.)

← 기술 블로그 목록으로