API
API는 한 소프트웨어가 다른 소프트웨어의 내부 구현을 몰라도 데이터를 요청하거나 동작을 시킬 수 있게 정해 둔 계약이다. 어떤 기능을 제공하는지, 입력과 응답이 어떤 형태인지, 어떤 오류가 날 수 있는지를 규정하기 때문에 계약만 지키면 양쪽 모두 내부를 자유롭게 다시 만들 수 있다. 오늘날 주류는 웹 API다. REST는 동작을 HTTP 메서드와 URL에 대응시키는 방식으로 여전히 기본값이고, GraphQL은 클라이언트가 필요한 필드만 한 번의 왕복으로 가져가게 한다. gRPC는 바이너리 프로토콜 버퍼를 써서 시스템 내부의 서비스 간 호출을 빠르게 처리한다. 웹훅은 방향을 뒤집어, 이쪽이 계속 물어보는 대신 이벤트가 생겼을 때 제공자가 우리 엔드포인트를 호출한다. SaaS 제품이 서로 붙는 방식도, AI가 애플리케이션에 닿는 방식도 API다. OpenAI와 Anthropic, Google 모두 모델 접근을 API로 판다. 운영에서 신경 쓸 것은 인증과 요청 한도, 버전 관리, 재시도에 대비한 멱등성이다. 가장 큰 함정은 호환을 깨는 변경이다. 필드를 없애거나 검증을 조이면 모든 사용처가 조용히 망가지므로, 안정적인 API는 버전을 명시하고 공표된 일정에 따라 폐기한다.
An API, or Application Programming Interface, is a defined contract that lets one piece of software request data or actions from another without knowing how the other is built. The contract specifies the available operations, the shape of the input, the shape of the response, and the errors that can occur, so either side can be rewritten as long as the interface holds. Web APIs dominate today. REST maps operations onto HTTP verbs and URLs and remains the default; GraphQL lets a client request exactly the fields it needs in one round trip; gRPC uses binary protocol buffers for fast service-to-service calls inside a system. Webhooks invert the direction, with the provider calling your endpoint when an event occurs instead of you polling. APIs are how SaaS products integrate and how AI reaches applications, since OpenAI, Anthropic, and Google all ship model access as an API. Production concerns are authentication, rate limits, versioning, and idempotency for retried requests. The pitfall is breaking changes: removing a field or tightening validation silently breaks every consumer, which is why stable APIs version explicitly and deprecate on a published schedule rather than changing in place.
사용 예시
- •“OpenAI API로 모델을 붙이면서 인증과 요청 한도 설계를 함께 손봤다”
- •“필드 하나를 제거한 API 변경이 연동 서비스 전반의 장애로 번졌다”
- •“폴링 대신 웹훅으로 바꿔 이벤트 발생 시점에만 호출이 일어나도록 정리했다”