API

API, 어렵지 않아요 프로그램끼리 대화하는 규칙, 쉽게 이해하기

1. API가 대체 뭔가요?

API는 'Application Programming Interface'의 줄임말이에요. 쉽게 말하면, 한 프로그램이 다른 프로그램의 기능이나 데이터를 가져다 쓸 수 있도록 미리 정해 둔 '요청하고 응답받는 규칙 모음'이에요. 우리가 화면(그래픽 인터페이스)을 보고 버튼을 눌러 서비스를 쓰듯이, 프로그램은 이 API를 통해 서비스를 이용해요. 예를 들어 어떤 앱이 실시간 가격을 보여 주려면, 가격 데이터를 가진 서버의 API에 '가격 좀 주세요'라고 요청을 보내고, 서버는 정해진 형식(주로 JSON이라는 데이터 형식)으로 답을 돌려줘요.

API의 핵심은 '속을 감춘다'는 데 있어요. 상대편 서버가 안에서 어떤 언어로 어떻게 계산하는지는 몰라도 돼요. 그냥 '무엇을, 어떤 형식으로 요청하면, 어떤 형식으로 답이 오는지'만 약속해 두는 거예요. 요청하는 쪽은 공개된 규격에 맞춰 요청만 보내면 되니까, 서로 다른 회사가 서로 다른 기술로 만든 시스템도 마치 하나처럼 연결될 수 있어요.

암호화폐 분야에서는 API가 특히 중요한 역할을 해요. 중앙화 거래소는 대부분 거래용 API를 제공해서, 사용자가 웹 화면을 거치지 않고도 프로그램으로 주문을 넣거나 잔고를 확인하고 시세를 받아올 수 있게 해줘요. 이때 발급되는 'API 키'는 내 계정을 대신 조작할 수 있는 권한을 담고 있어요. 그래서 개인키에 준하는 수준으로 안전하게 관리해야 해요.

이렇게 보면 쉬워요 · API는 식당 메뉴판 같은 거예요. 주방이 어떻게 요리하는지 몰라도, 메뉴판 규칙대로 주문하면 음식이 나와요.

2. API는 어떻게 움직이나요?

대부분의 웹 API는 '요청(request)'과 '응답(response)'이라는 한 쌍의 흐름으로 움직여요. 요청하는 쪽(클라이언트)이 특정 주소로 요청을 보내면, 서버가 처리 결과를 정해진 형식으로 돌려주는 식이에요.

이 과정에는 몇 가지 구성요소가 있어요. 먼저 '엔드포인트'는 기능마다 붙어 있는 고유 주소(URL)예요. 예를 들어 시세를 조회하는 주소와 주문을 넣는 주소가 서로 달라요. '메서드'는 요청의 성격을 구분해요. 데이터를 그냥 읽어 오는 요청(조회)과 상태를 바꾸는 요청(주문·취소)을 나누는데, 웹 API에서는 흔히 GET·POST 같은 HTTP 메서드로 표현해요. '파라미터와 본문'은 세부 조건을 함께 실어 보내는 부분이에요. 어떤 종목의 시세인지, 몇 개를 얼마에 살지 같은 내용이 여기 들어가요. '응답 형식'은 결과가 돌아오는 방식인데 주로 JSON으로 오고, 처리가 성공했는지 실패했는지는 '상태 코드'라는 숫자로 함께 알려줘요. 마지막으로 '인증 정보'는 거래처럼 권한이 필요한 요청에 필요해요. API 키나 서명 값을 헤더(요청에 딸린 정보 칸)에 담아 '나 이런 사람이에요'라고 신원을 증명하는 거예요.

이렇게 규칙이 딱 정해져 있으니, 사람이 마우스로 버튼을 하나씩 누르는 대신 프로그램이 1초에 수많은 요청을 자동으로 처리할 수 있어요. 다만 서버가 부담을 못 견디는 걸 막으려고, 대부분의 API는 일정 시간당 부를 수 있는 횟수를 정해 둔 '요청 한도(rate limit)'를 둬요.

이렇게 보면 쉬워요 · 편지 봉투와 답장 같아요. 정해진 주소로 정해진 양식대로 편지를 보내면, 정해진 형식으로 답장이 와요.

3. API에도 종류가 있나요?

API는 통신하는 방식과 설계 철학에 따라 여러 갈래로 나뉘어요.

가장 널리 쓰이는 건 'REST 방식'이에요. 자원(데이터)을 주소로 표현하고 요청과 응답을 주고받는 방식인데, 구조가 단순해서 시세·잔고 조회 같은 데 두루 쓰여요. '실시간 스트리밍(WebSocket)'은 한 번 연결을 맺어 두면 서버가 새 데이터가 생길 때마다 알아서 밀어 주는 방식이에요. 체결 내역이나 호가처럼 계속 바뀌는 정보를 지연 없이 받는 데 유리해요. 'RPC / JSON-RPC'는 멀리 있는 함수를 마치 바로 앞에서 부르듯 호출하는 방식으로, 블록체인 노드와 통신할 때 표준처럼 쓰여요. 'GraphQL'은 필요한 데이터 항목만 콕 집어서 한 번에 받아오도록 설계된 쿼리형(질의형) 방식이에요. 'FIX'는 전통 금융권에서 오래 써 온 거래 메시지 표준인데, 아주 낮은 지연으로 대량 주문을 넣어야 하는 일부 기관용 암호화폐 거래에서 FIX API 형태로 제공되기도 해요.

실제로는 한 서비스가 여러 방식을 함께 쓰는 경우가 많아요. 예를 들어 조회는 REST로 하고, 실시간으로 바뀌는 시세는 WebSocket으로 받는 식이에요.

이렇게 보면 쉬워요 · 소식을 전하는 방법이 여러 가지인 것과 같아요. 필요할 때 물어보기(REST), 알림을 계속 받기(WebSocket)처럼 상황에 맞게 골라 써요.

4. 암호화폐 거래소 API는 어떻게 나뉘나요?

거래소 API는 크게 두 종류로 나뉘어요.

하나는 '조회용(공개) API'예요. 시세·호가·체결 내역·거래량처럼 누구에게나 공개된 시장 데이터를 읽어 오는 용도인데, 인증 없이도 쓸 수 있는 경우가 많아요. 다른 하나는 '거래용(비공개) API'예요. 주문 제출·취소, 잔고 조회, 입출금처럼 내 계정과 직접 연결된 기능을 다루는 거라, 반드시 API 키 인증이 필요해요.

자동매매 봇이나 차익거래 프로그램은 이 API를 통해 사람이 일일이 손대지 않아도 빠르게 매매를 해요. 특히 고빈도 거래에서는 주문이 서버에 도착하기까지 걸리는 아주 짧은 시간이 승부를 가르기 때문에, 거래소 서버와 물리적으로 가까운 곳에 장비를 두는 코로케이션으로 레이턴시(신호가 오가는 데 걸리는 지연 시간)를 줄이려는 시도가 이어지고 있어요.

거래소 API는 대개 초당 또는 분당 부를 수 있는 횟수 한도를 두고, 이 한도를 넘기면 잠깐 동안 요청을 거부해요. 그래서 프로그램은 응답의 상태 코드를 확인하면서 스스로 호출 빈도를 조절하도록 설계돼요.

이렇게 보면 쉬워요 · 도서관에 비유하면, 열람실 자료는 누구나 볼 수 있지만(조회용) 대출·반납은 회원증이 있어야 하는 것(거래용)과 비슷해요.

5. 노드를 안 돌려도 블록체인 데이터를 볼 수 있나요?

블록체인 데이터 API를 쓰면, 직접 노드를 운영하지 않고도 잔고·트랜잭션·블록 정보를 조회할 수 있어요. 노드를 직접 돌리려면 저장 공간도 많이 들고 관리 부담도 큰데, 노드 API를 쓰면 이런 인프라 없이도 네트워크에 질문을 던질 수 있어요.

종류를 나눠 보면 이래요. '노드 접속 API'는 JSON-RPC 규격으로 블록·트랜잭션을 읽거나, 서명된 거래를 네트워크에 퍼뜨리는 역할을 해요. 디앱과 지갑 앱은 이 API를 통해 이더리움 같은 네트워크와 통신해요. '데이터·탐색 API'는 블록 익스플로러나 데이터 제공 서비스가 주소별 잔고·거래 이력을 보기 좋게 정리해서 공개하는 거예요. '온체인 분석 API'는 온체인(블록체인에 기록된) 활동을 쿼리하고 모아서 대시보드나 리서치에 쓸 수 있게 도와줘요. 자금 흐름을 추적하거나, 지표를 계산하거나, 시각화하는 데 활용돼요.

이런 API 덕분에 개발자는 블록체인의 복잡한 내부 구조를 하나하나 다루지 않고도 필요한 데이터를 간편하게 끌어올 수 있어요.

이렇게 보면 쉬워요 · 도서관을 직접 짓는 대신, 이미 잘 정리된 도서관에 가서 필요한 책만 빌려 오는 것과 같아요.

6. 블록체인은 왜 스스로 외부 데이터를 못 가져오나요?

스마트 계약(조건이 맞으면 자동으로 실행되는 프로그램) 환경에서는 오라클이 외부 API로부터 가격 같은 실세계 데이터를 받아와 온체인으로 전달하는 다리 역할을 해요. 블록체인은 '결정성'을 지켜야 해요. 결정성이란 모든 노드가 똑같은 결과에 도달해야 한다는 뜻이에요. 그런데 외부 API를 직접 부르면 노드마다 받는 값이 달라질 수 있어서, 블록체인은 스스로 외부 API를 호출하지 못해요. 그래서 오라클이 API와 블록체인 사이를 이어 주는 중간 역할을 하는 거예요.

체인링크처럼 여러 데이터 출처를 모아서 검증하는 탈중앙 오라클 네트워크는, 어느 한 API에 오류가 있거나 조작이 있어도 계약 전체가 왜곡되지 않도록 여러 출처를 종합해요. 에이피아이쓰리는 데이터를 제공하는 쪽이 직접 온체인에 데이터를 올리는 방식을 지향하는 등, 'API를 어떻게 하면 믿을 수 있는 형태로 온체인에 연결할까'는 이 분야의 핵심 과제로 남아 있어요. 이렇게 공급된 데이터는 탈중앙 금융 프로토콜에서 담보를 평가하거나 청산(빚을 못 갚을 때 담보를 처분하는 것)을 판단하는 데 직접 쓰여요.

이렇게 보면 쉬워요 · 방음실 안에 있는 사람이 바깥 날씨를 직접 못 보니, 여러 명이 밖을 확인해 와서 같은 답을 전해 주는 것과 비슷해요.

7. API 키는 왜 그렇게 조심해야 하나요?

거래용 API 키는 보통 공개 키와 비밀 키 한 쌍으로 발급돼요. 서비스에 따라 '출금 권한은 빼기'나 '특정 IP 주소에서만 쓰기 허용' 같은 권한 제한을 걸 수도 있어요. 키가 새어 나가면 자산을 뺏길 수 있으니, 꼭 필요한 최소한의 권한만 주고 출금 권한은 되도록 꺼 두는 게 안전해요.

안전하게 관리하는 일반적인 원칙은 이래요. '최소 권한'은 시세만 필요하면 조회 권한만, 매매만 필요하면 출금 권한을 빼고 발급하는 거예요. 'IP 제한'은 정해진 서버 주소에서만 키가 작동하게 묶어 두는 건데, 그러면 키가 유출돼도 다른 곳에서는 쓰기 어려워요. '비밀 키 보관'도 중요해요. 비밀 키는 발급할 때 딱 한 번만 보여 주는 경우가 많으니, 소스 코드나 깃허브 저장소에 그대로 남겨 두면 안 돼요. '주기적 폐기·재발급'은 수상한 활동이 보이면 즉시 키를 없애 버리는 거예요.

API 키는 계정을 대신 조작하는 권한을 담고 있어서, 사실상 계정에 접근하는 열쇠나 마찬가지예요. 그래서 커스터디나 개인키 관리와 똑같은 수준으로 조심해야 해요.

이렇게 보면 쉬워요 · API 키는 집 열쇠 같아요. 필요한 문만 열리는 열쇠를 주고, 잃어버릴 것 같으면 곧바로 자물쇠를 바꾸는 게 안전해요.

8. API는 실제로 어디에 쓰이나요?

API는 암호화폐 생태계에서 여러 자동화의 밑바탕이 돼요.

대표적으로 '자동매매·전략 실행'이 있어요. 정해진 조건에 따라 사람 없이 주문을 내는 봇이 거래소 API로 돌아가요. '차익거래'는 여러 거래소의 시세를 동시에 읽어서 가격 차이를 찾아내고 즉시 매매하는 거예요. '포트폴리오·회계 도구'는 여러 거래소와 지갑에 흩어진 잔고와 거래 내역을 한곳에 모아 내 자산 현황을 정리해 줘요. '데이터 분석·대시보드'는 온체인 데이터 API로 지표를 모아서 리서치나 리스크 감시에 활용하는 거고요. '디앱·지갑'은 노드 API를 통해 네트워크와 통신하면서 잔고를 표시하고 거래를 전송해요.

이렇게 API는 개인 트레이더가 짠 작은 스크립트부터 기관의 대규모 거래 시스템까지 폭넓게 쓰이고 있어요.

이렇게 보면 쉬워요 · 여러 은행 계좌를 한 앱에서 몰아 보는 것처럼, API는 흩어진 정보와 기능을 하나로 이어 줘요.

9. API를 쓸 때 조심할 위험은 뭔가요?

API를 쓰는 데는 구조적으로 몇 가지 위험이 따라와요.

첫째는 '키 유출'이에요. 비밀 키가 새어 나가면 잔고를 뺏기거나 원치 않는 매매가 일어날 수 있어요. 출금 권한을 꺼 두고 IP를 제한하는 게 기본 방어선이에요. 둘째는 '요청 한도 초과'예요. 정해진 호출 횟수를 넘기면 잠깐 요청이 막혀서, 중요한 주문이나 취소가 실패할 수 있어요. 셋째는 '서버 장애와 지연'이에요. 거래소나 데이터 제공자 쪽에 문제가 생기거나 네트워크가 느려지면 응답이 늦거나 사라질 수 있어서, 이런 상황을 대비한 오류 처리 설계가 필요해요. 넷째는 '명세 변경'이에요. 제공자가 API 버전을 바꾸거나 없애 버리면, 기존 프로그램이 갑자기 멈출 수 있어요.

그래서 자동화 시스템은 응답 상태를 항상 점검하고, 실패했을 때는 다시 시도하거나 안전하게 멈추는 예외 처리를 꼭 갖춰야 해요.

이렇게 보면 쉬워요 · 자동으로 돌아가는 기계일수록 '문제가 생기면 어떻게 멈출지'를 미리 정해 두는 게 중요한 것과 같아요.

10. API 세계는 앞으로 어떻게 될까요?

API 생태계는 서로 더 잘 연결되는 방향으로 발전해 왔어요. REST와 JSON이 사실상 표준으로 자리 잡고, 규격을 기계가 읽을 수 있게 문서로 정리하는 방식이 퍼지면서 서로 다른 서비스를 조합하기가 훨씬 쉬워졌어요.

반면 아직 남은 숙제도 뚜렷해요. 거래소마다 API 규격과 권한 정책이 제각각이라 이걸 하나로 다루기가 어려워요. 또 외부 API에서 온체인으로 넘어오는 데이터를 얼마나 믿을 수 있느냐 하는 문제(오라클 문제)는 여전히 활발히 연구되는 영역이에요. 데이터를 제공하는 주체를 특정 회사 한 곳에 의존하지 않으려는 탈중앙 API·오라클 시도(에이피아이쓰리 같은 것)와, 키 유출이나 요청 위조를 막기 위한 인증·서명 방식의 강화도 계속 이어지고 있어요.

API는 서비스와 서비스를 이어 주는 '보이지 않는 배관' 같은 역할을 해요. 그래서 그 안정성과 보안은 곧 생태계 전체의 신뢰와 직결돼요.

이렇게 보면 쉬워요 · 집 안 벽 뒤의 배관처럼, 평소엔 안 보이지만 새거나 막히면 온 집이 곤란해지는 것과 같아요.