api키란 외부 프로그램이나 서비스가 다른 시스템의 기능을 불러 쓸 때 본인이 누구인지 증명하는 문자열을 말한다. 흔히 영문과 숫자가 뒤섞인 긴 조합으로 나타나며, 이 문자열을 요청에 함께 실어 보내야 상대 시스템이 요청을 받아들인다. 이 기사는 api키가 정확히 무엇을 하는 장치인지, 어떻게 발급받고 만들며, 확인하고 관리할 때 무엇을 주의해야 하는지를 차례로 다룬다.
api키란 무엇인가
api키는 사람이 아이디와 비밀번호로 로그인하듯, 프로그램끼리 서로를 확인하는 수단이다. 웹사이트나 애플리케이션이 다른 서비스가 제공하는 지도, 결제, 번역, 날씨 같은 기능을 가져다 쓰려면 그 서비스에 요청을 보내야 하는데, 이때 아무 요청이나 받아 주면 서버에 과도한 부하가 걸리거나 자격 없는 이용자가 자원을 가져다 쓸 수 있다. api키는 이 요청을 보낸 주체가 등록된 이용자인지를 가리는 역할을 한다. 키 자체는 대개 무작위로 생성된 긴 문자열이며, 이 문자열을 아는 쪽만 그 계정의 이름으로 요청을 보낼 수 있다고 보면 된다.
api키를 쓰는 방식이 자리 잡은 이유는 관리와 통제 때문이다. 아이디와 비밀번호를 그대로 프로그램 코드에 넣어 쓰면 유출됐을 때 계정 전체가 위험해지지만, api키는 용도별로 나누어 발급하고 필요하면 그 키 하나만 없애거나 새로 바꿀 수 있다. 또한 서비스를 제공하는 쪽에서는 키마다 얼마나 많은 요청이 들어오는지 헤아려 사용량에 따라 등급을 나누거나 제한을 걸 수 있어, 특정 이용자가 자원을 지나치게 많이 가져다 쓰는 상황을 막는 데도 쓰인다.
api키 발급과 만들기
api키 발급받기는 서비스마다 화면 구성은 다르지만 큰 흐름은 비슷하다. 먼저 해당 서비스에 계정을 만들고 로그인한 뒤, 개발자용 설정 화면이나 프로젝트 관리 화면으로 들어간다. 그 안에서 새 프로젝트나 애플리케이션을 등록하면 그 단위로 api키를 만들기 버튼이 나타나고, 이를 누르면 문자열 형태의 키가 자동으로 생성되어 화면에 표시된다. 발급 과정에서 이 기능을 어떤 용도로 어디까지 쓸 것인지, 하루에 몇 번까지 요청을 보낼 것인지 같은 항목을 함께 정하도록 요구하는 경우가 많다.
서비스에 따라 api키 무료로 제공하는 범위를 두고, 그 범위를 넘어서면 별도 신청이나 결제가 필요한 방식을 쓰는 곳이 있다. 어느 범위까지 별도 비용 없이 쓸 수 있는지, 그 기준이 요청 횟수인지 기간인지는 서비스마다 정책이 다르고 시점에 따라 바뀌기도 하므로, 발급 화면이나 공식 안내 문서에서 그때그때 확인하는 편이 정확하다. 기사에 특정 금액이나 횟수를 적어 두면 오히려 오래된 정보로 남아 혼동을 줄 수 있어 여기서는 다루지 않는다.
api키 확인과 관리
api키 확인은 대부분 처음 발급받은 화면이나, 로그인 후 들어가는 프로젝트 설정 화면에서 다시 볼 수 있다. 다만 보안을 이유로 키 전체를 다시 보여 주지 않고 일부만 가려서 보여 주거나, 분실 시 새 키를 발급해 기존 키를 없애는 방식만 지원하는 서비스도 있다. 이 때문에 발급받은 순간 키를 안전한 곳에 따로 기록해 두는 습관이 필요하다.
관리 측면에서 가장 흔히 저지르는 실수는 api키를 코드에 그대로 적어 두고 그 코드를 외부에 공개하는 저장소에 함께 올리는 것이다. 키가 사람 눈에 보이는 형태로 인터넷에 노출되면 누구나 그 키를 가져다 자신의 요청인 것처럼 꾸며 쓸 수 있고, 그 결과로 발생하는 요청 비용이나 제한 초과는 원래 키를 발급받은 계정에 돌아간다. 키는 코드와 분리된 별도의 설정 파일이나 환경변수로 관리하고, 그 파일이 공개 저장소에 함께 올라가지 않도록 신경 쓰는 것이 기본이다.
상황에 따라 달라지는 판단
api키를 쓰는 프로그램이 어디에서 실행되는지에 따라 주의할 점이 달라진다. 서버에서만 실행되는 프로그램이라면 키가 이용자의 화면까지 전달되지 않으므로 비교적 안전하게 감출 수 있지만, 누리집을 방문한 사람의 화면에서 직접 실행되는 코드에 키를 넣으면 화면의 구성 요소를 살펴보는 것만으로 누구나 그 키를 볼 수 있다. 이런 경우에는 특정 인터넷 주소나 특정 도메인에서 보낸 요청만 받아들이도록 키에 제한을 걸어 두는 기능을 함께 쓰는 것이 일반적이다.
또한 여러 사람이 함께 개발하는 프로젝트라면 한 개의 키를 여럿이 나눠 쓰기보다, 사람이나 용도별로 키를 나누어 발급받는 편이 문제가 생겼을 때 원인을 좁히기 쉽다. 흔한 오해 가운데 하나는 api키만 있으면 무조건 안전하게 인증이 끝난다고 여기는 것인데, 키는 어디까지나 요청을 보낸 쪽을 가려내는 최소한의 장치이고, 이보다 더 민감한 기능에는 별도의 로그인 절차나 추가 인증을 함께 요구하는 서비스도 많다.
| 구분 | 내용 |
|---|---|
| 키를 두는 위치 | 서버 안에서만 쓰면 노출 위험이 낮고, 화면에서 실행되는 코드에 두면 노출 위험이 높다 |
| 발급 절차 | 계정 등록과 로그인, 프로젝트 등록, 키 생성 순서로 진행되는 경우가 많다 |
| 확인 방법 | 발급 화면이나 프로젝트 설정 화면에서 다시 확인하되, 일부만 표시되는 경우가 있다 |
| 관리 원칙 | 코드와 분리해 보관하고, 공개 저장소에 함께 올리지 않는다 |
api키와 관련해 무엇을 먼저 확인해야 할지 정리하면, 우선 사용하려는 서비스의 개발자 문서에서 발급 절차와 이용 범위를 확인하고, 발급받은 키는 코드와 분리해 보관하며, 화면에서 직접 실행되는 프로그램이라면 키 사용 범위를 제한하는 기능이 있는지부터 살펴보는 것이 순서에 맞다. 구체적인 무료 제공 범위나 요청 제한 수치는 서비스가 안내하는 공식 문서에서 그때그때 확인하는 것이 가장 정확하다.
· · · · · · · · · ·
스페셜타임스는 AI 기술의 도움을 받아 더 빠르고 다양한 뉴스를 독자에게 전달하기 위해 노력하고 있습니다.