API
Application Programming Interface
API이란?
- 프로그램끼리 주고받는 '창구'
- 무엇을 어떻게 요청할지 약속
- 서비스 연결의 기본
API가 실제로 바꾸는 것은 '무엇을 우리가 직접 만들 것인가'의 경계선입니다. 지도, 결제, 알림톡 발송, 번역, AI 답변처럼 예전이라면 개발팀 하나가 몇 달을 붙어야 했던 기능이, 가입하고 키를 발급받으면 그날 오후에 붙는 부품이 됩니다. 그래서 기획 회의의 질문도 '이걸 만들 수 있습니까'에서 '이 기능은 어느 회사 것을 가져다 쓸까요'로 옮겨갑니다.
실무에서 마주치는 형태는 몇 갈래로 갈립니다. 우리가 물어보면 답이 오는 REST가 기본이고, 필요한 항목만 골라 받는 GraphQL, 반대로 상대 쪽에서 사건이 생길 때 먼저 찔러주는 웹훅(Webhook)이 있습니다. 결제 완료나 배송 출발처럼 언제 올지 모르는 소식은 10분마다 물어보는 대신 웹훅으로 받는 편이 맞습니다. 붙이기 전에 확인할 것은 인증 방식, 호출 한도, 과금 단위 세 가지입니다. '분당 60회, 월 1만 건 무료' 같은 조건이 나중에 설계를 통째로 흔듭니다.
헷갈리는 이웃도 정리해 두면 좋습니다. SDK는 그 API를 언어별로 쓰기 편하게 감싼 꾸러미이고, 화면까지 통째로 얹어주는 위젯은 붙이기는 쉽지만 우리 입맛대로 바꿀 여지가 적습니다. 밖에서 가져오는 것만 API는 아닙니다 — 사내 주문 시스템과 재고 시스템 사이에 사내 API를 하나 깔아두면 부서마다 엑셀로 주고받던 파일이 사라집니다. 검토 단계에서는 문서와 샌드박스(테스트 환경)가 있는지부터 봅니다.
가장 흔한 사고는 API 키를 소스코드나 공용 문서에 그대로 적어두는 것입니다. 유출된 키로 남이 우리 계정에서 AI를 호출하면 청구서는 우리에게 옵니다. 두 번째는 상대 서비스가 영원할 거라고 가정하는 태도입니다. 외부 API가 30분 멈추면 우리 서비스도 같이 멈추고, 버전 종료 공지를 놓치면 어느 날 아침 연동이 통째로 끊깁니다. 붙이는 설계만 하지 말고 재시도 규칙·대체 경로·사용량 알림까지 같이 정해두어야 합니다.
API 개념은 소프트웨어 초창기부터 있었고, 오늘날 웹 API의 사실상 표준인 REST는 로이 필딩(Roy Fielding)이 2000년 박사학위 논문에서 정의했습니다.
가상의 사례로 살펴보겠습니다. 임직원 90명, 연매출 240억 원 규모의 인테리어 자재 유통사 A사 이야기입니다. 자사몰과 오픈마켓 3곳에서 하루 400여 건의 주문이 들어오는데, CS팀 2명이 매일 아침 각 사이트에서 엑셀을 내려받아 재고 시스템에 손으로 옮겨 넣고 있었습니다. 이 작업에만 하루 2시간 30분이 걸렸고, 재고가 실시간이 아니다 보니 품절 상품을 파는 오배송이 월 3건씩 났습니다.
- 물류팀 김 과장이 오픈마켓 판매자센터를 뒤지다 '주문 조회 API' 문서를 발견하고 회의에서 말했습니다. "다운로드 버튼 누르는 대신 시스템이 알아서 받아오게 할 수 있다는 거네요."
- 개발 외주를 주는 대신 사내 DX 담당 이 대리가 3주간 붙어, 마켓 3곳의 주문 API에서 10분마다 신규 주문을 끌어와 재고 DB에 넣는 스크립트를 만들었습니다.
- 테스트 둘째 주에 하루 호출 한도 1,000회에 걸려 오후 주문이 4시간 밀렸습니다. 이 대리는 전체 조회를 접고, 마켓이 주문 발생 시 먼저 알려주는 웹훅 방식으로 바꿨습니다.
- 정보보안 담당 박 팀장이 API 키가 팀 공용 구글시트에 적혀 있는 걸 보고 제동을 걸었습니다. "이건 통장 비밀번호를 벽에 붙여둔 겁니다." 키를 전부 재발급해 서버 환경변수로 옮겼습니다.
- 가동 두 달째, 수기 입력 2시간 30분이 하루 10분 검수로 줄고 오배송은 월 3건에서 0건이 됐습니다. CS 인력 1명은 상담 응대로 돌려 응답 대기시간이 12분에서 4분으로 짧아졌습니다.