개발자 / 클라우드

글로벌 칼럼 | ‘로스트 테크놀로지’가 되어 버린 API 설계

David Linthicum | InfoWorld 2024.01.29
금요일 오전, 당신은 약간 흥분된 상태다. 마침내 오늘 대형 퍼블릭 클라우드 서비스에 구축한 새로운 생성형 AI 시스템이 기존 이커머스 시스템과 연동해 가동을 시작하기 때문이다.
 
ⓒ Getty Image Bank

이커머스는 회사 매출의 80%를 차지하는 핵심 시스템이다. 회사는 새 생성형 AI 시스템이 매출을 높여줄 것으로 기대한다. 우리 사이트에 접속하는 사용자를 더 깊이 이해하는 데 도움이 되고, 맞춤 이벤트를 바로 만들어 적용하는 것도 가능해질 것이다. 마케팅팀에서는 이 새 시스템 덕분에 건당 평균 판매 가격이 30% 올라갈 것으로 추산했다. 이 정도면 완전히 게임 체인저다.

이 시스템을 만들 때 클라우드와 웹사이트 개발팀은 부하 테스트를 생략하라는 압박을 받았다. 클라우드 시스템이니 부하가 늘어날 때 리소스를 확장하는 것은 기본이라고 믿었다. 여기서 이커머스 시스템은 여러 가지 API를 사용하는 생성형 AI 시스템과 상호작용한다. 이를 통해 이커머스 사이트의 애플리케이션이 생성형 AI 시스템을 활용하게 되는데, 이 과정에서 데이터를 건네주고 이후 AI 시스템이 원하는 답변을 내놓게 된다.

하지만 모든 것이 생각대로 굴러가지 않았다. 이커머스 시스템 사용자가 5,000명 이상으로 치솟으면서 이 시스템과 함께 작동하는 API에 대한 부하가 폭증했고 성능이 급격히 떨어졌다. 사이트가 제대로 작동하지 않으니 사이트를 이탈하는 사용자가 속출했다. 결국 이커머스팀은 사이트를 이전 버전으로 급히 되돌렸고 생성형 API 시스템과의 연동을 끊어버렸다.

필자는 이런 상황을 꽤 자주 본다. 시스템 디자인은 문제가 없지만 API를 과소평가해 결국 성능과 확장성, 지연시간 문제가 발생한다. 많은 경우 더 많은 서버 인스턴스 같은 추가 리소스를 이용해 이런 문제를 감춘다. 실제로 퍼블릭 클라우드에서 리소스를 추가하는 것은 매우 간단하다. 하지만 이런 리소스는 공짜가 아니다. 결국 어떤 형태로든 근본적인 API 문제를 해결해야만 한다.
 

API 설계의 기본 원칙

API가 기대했던 대로 작동하지 않는 문제는 API 설계에서 필요한 부분을 반영하지 않았기 때문이다. 즉, 다시 제대로 된 API 설계의 기본으로 돌아가야 한다. 사실 이 문제는 지난 수십 년간 반복됐다. 그런데도 여전히 개발의 우선순위가 아니다. 필자가 이런 이야기를 하면 많은 기업이 마치 새로운 정보인 것처럼 받아들인다. 특히 API 개발팀이 이런 반응을 보이면 필자는 약간 두렵기까지 하다.

그렇다면 훌륭한 API 설계의 기본은 무엇일까? 몇 가지 주요 내용만 정리하면 다음과 같다.
 
  • 확장성(Scalability)은 중요하다. 이는 API가 늘어난 요청을 성능 저하 없이 처리할 수 있도록 설계하는 것을 의미한다. 이를 구현하는 방법은 여러 가지다. 캐싱 전략과 로드 밸런싱을 적용하고, 기반 아키텍처가 트래픽 증가에 따라 리소스를 동적으로 할당하도록 하면 된다.
  • 모듈화(Modularity)는 API를 모듈러 서비스의 집합으로 만드는 것을 가리킨다. 이런 단절을 통해 개별 컴포넌트를 독립적으로 개발, 배포, 확장할 할 수 있다. 이는 시스템 전체의 복잡성을 줄이고 유지보수를 더 간편하게 하며, 코드를 더 쉽게 재사용할 수 있도록 한다.
  • 스테이트리스(Statelessness)는 REST 개발 원칙 측면에서 이해해야 한다. API는 요청을 처리하는 과정의 데이터를 저장하지 않도록 해야 한다는 의미다. 이런 스테이트리스 상태를 유지하면 클러스터 내부의 서버가 모든 요청을 독립적으로 처리할 수 있기 때문에 결과적으로 확장성과 신뢰성이 개선된다.
  • 효율적인 데이터 처리(Efficient data handling)는 요청자에게 다시 돌려주는 데이터 패킷의 크기를 최적화하는 것을 가리킨다. API 응답에는 불필요한 데이터를 제거해야 한다. 그래야 지연시간과 대역폭 사용을 최소화할 수 있다.
 

모니터링과 테스트

API를 만들어 배포하는 사람들 대부분은 API의 처리 용량이 한계에 이르러 응답하지 못하는 시점을 알지 못한다. 즉 부하가 늘어남에 따라 API가 제대로 작동할 지에 대해 거의 혹은 전혀 알지 못한다. 이를 확인하는 유일한 방법은 모니터링과 테스트 그리고, 앞서 제시한 기본 원칙에 따라 API가 최적화 됐는지를 평가하는 지표를 사용하는 것 뿐이다.

필자는 성능 지표로 다음과 같은 기준을 사용하길 조언한다.
 
  • 지속적인 API 지연시간 모니터링 : 클라이언트에서 서버로 요청하는 데 걸리는 시간과 다시 클라이언트로 응답이 도착하는 시간이다.
  • 쓰루풋 측정 : 특정 시간 동안 성공적으로 메시지를 전달한 횟수인데, 이를 통해 API의 성능 한계를 알 수 있다.
  • API 오류율 확인 : 신뢰성 관련 문제에 선제적으로 대응하기 위해 필요하다. 이 수치가 높으면 뭔가 잘못됐으므로 API를 수정해야 한다.

그동안 필자가 사용해 본 여러 클라우드 시스템을 떠올려보면, API 설계와 개발, 운영에 대한 노하우와 지식을 잃어버린 게 아닐까 생각이 든다. 일종의 '로스트 테크놀로지'다. 클라우드 개발 교육 과정에서 API 설계 관련 내용을 아예 다루지 않거나 너무 간단하게 가르치고 넘어가는 것일 수도 있다. 하지만 최적화된 클라우드 기반 시스템, 즉 더 적은 리소스를 사용해 원하는 성능을 제공하려면, 애플리케이션 혹은 애플리케이션 세트의 모든 구성요소를 세심하게 신경 써야 한다. 오늘날 API는 이를 위한 핵심 요소이므로 설계 과정에서 높은 우선 순위로 다뤄야 한다. 과한 요구 같은가? 절대 그렇지 않다.
editor@itworld.co.kr
 Tags API 클라우드
Sponsored

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.