“좋은 울타리가 좋은 이웃을 만든다.” 로버트 프로스트는 오래전 이렇게 이야기했다.
좋은 API는 좋은 코드의 필수적 요소다. 이것들은 프로젝트를 분리하고 라이브러리를 생성하며 업무를 공유할 때 개발자가 그리는 경계선이다. 로버트 프로스트가 지금까지 살아 있었다면 API에 관한 시를 썼을 것이다.
API가 비즈니스의 기초가 되고 있다. 단순히 데이터와 의사결정 정보의 게이트웨이가 아니라 수익 창출을 위해 고안되고 있다. 이제 API는 사용자를 추적하고 청구를 위한 올바른 방법을 찾는다.
이런 API를 만드는 것은 TCP/IP 포트를 열고 돈이 굴러 들어오기를 기다리는 것만큼 단순하지 않다. API는 인터넷에 있는 모든 장치로부터 요청을 받고, 악의가 있는 사람들과 결백한 사람들이 모두 기업의 분을 두드리기 시작한다. 문제는 적합한 개발자가 사용하기 쉽고 환영할 만하면서 악당들이 침투할 수 없는 API를 만드는 것이다.
API 전략의 실수를 유도할 수 있는 14가지 보편적인 API 문제를 살펴본다.
탈출 비용 간과
많은 클라우드 제공자들이 각종 비용을 청구하며 이중 일부는 간과되기 쉽다. 시간당 기계 비용은 분명하지만 많은 사람들이 청구서에 ‘데이터 탈출’이 포함될 수 있다는 사실을 잊어버린다. API의 핵심 기능은 데이터를 사용자에게 탈출시키는 것이다. API 가격 책정 시 그리고 아키텍처 구상 시 이 비용을 고려해야 한다.
‘데이터 포맷 세금’ 무시
XML 등의 일부 데이터 형식은 다른 것들만큼 효율적이지 않다. API가 반환하는 데이터 패킷의 크기에 영향을 미칠 수 있다. 데이터 형식에서 추가적인 태그와 불편한 것들을 없앰으로써 회사의 비용을 40% 이상 절감하는 사례가 있을 정도다. 데이터 형식을 가능한 가볍게 유지하고 데이터를 필요한 비트에만 집중시켜 대역폭 비용을 관리한다.
장식적 기능 간과
때로는 API 개발자는 다소 멋으로 덧붙이는 기능을 포함시킨다. 대부분의 경우에는 사용하지 않더라도 문제가 발생하지 않는다. 하지만 알려지지 않은 보안 구멍이 남아 있을 수 있다.
임의 코드를 실행하는 기능을 Log4J 라이브러리에 추가한 프로그래머는 인터넷 역사상 최악의 보안 버그를 만들 계획이 아니었을 것이다. 그러나 사람들이 거의 사용하지 않는 이 기능이 불러올 위험성에 관해 잊어버렸을 때 그런 상황이 발생했다. 이런 경우에는 너무 창의적이거나 똑똑하지 않은 것이 도움이 된다. 최소한을 고수하는 것이 항상 훌륭한 제품을 개발하는 최고의 방법은 아니지만 안전한 API를 만드는 좋은 방법일 수 있다.
사전 필터링 잊어버리기
대부분의 API는 별다른 기능이 없다. 입력값을 받아 다른 코드로 전달한다. API가 제공할 수 있는 최고의 서비스는 사전 필터링을 통해 입력값이 기대치와 일치하는지 확인하는 것이다. 다수의 악성 보안 공격의 일부 API의 안일한 호의를 악용하여 버퍼를 넘치게 하거나 SQL 주입 공격을 시도한 것들이었다.
테스트에 인색하기
많은 개발자들이 기본적인 몇 가지 테스트 URL을 보유하고 있다. API로부터 적절한 패킷이 반환되면 모든 것이 원활하게 작동한다고 가정한다. 그러나 현실에서는 테스트 결과가 캐시 처리되고 단순한 테스트 URL은 첫 번째 레이어만 실행하는 경우가 많다. 좋은 테스트 스위트는 데이터베이스와 보조 API 또는 서비스에 대한 연결 등 API의 모든 부분을 평가한다.
잘못된 CORS 구성
CORS(Cross-Origin Resource Sharing) 문제는 브라우저에서 API의 응답이 직접 다른 콘텐츠와 혼합될 때 나타날 수 있다. 서둘러 API를 사용하는 일부 API 사용자에게는 문제가 될 수 있다. 때로는 태그 ACAO(Access-Control-Allow-Origin)를 헤더에 추가해야 한다. 때로는 스택에 완전 프록시를 구축하는 것이 낫다.
잘못된 인증 선택
API와 관련해 적절한 양의 인증을 파악하는 것도 중요하다. 일부 데이터는 과도하게 민감하지 않다. 이러한 API의 유일한 기능은 사용자를 추적하여 청구서를 파악하는 것이다. 이런 단순한 경우에는 변경되지 않는 무작위 키로 충분할 수 있다. 하지만 놀랍도록 민감할 수 있는 개인 정보를 다뤄야 하는 API들도 있다. 이런 경우 OAuth 2.0, OpenID, JWT 등의 더욱 안전한 프로토콜이 더 나은 선택이다. 프로토콜의 양쪽을 위한 좋은 라이브러리가 이미 존재하기 때문에 보안 업그레이드 시 새 코드를 많이 작성할 필요가 없다.
로그 파일 이상 찾아보지 않기
소프트웨어가 작동하고 있고 패닉에 빠진 고객이 전화하지 않는다면, 프로그래머는 낮잠을 자는 경향이 있다. 하지만 로그 파일을 살펴보면 API와 관련해 위험이 발생하기 전에 찾아낼 수 있다. 특정 파라미터가 소프트웨어에 더 큰 문제를 발생시키는가? 특정일, 특정 시간 또는 한 고객이 등장할 때 부하가 급증하는가? 몇 분 동안만 로그 파일의 잘못된 응답 시간을 살펴보면 하드웨어 성능이 부족하거나 소프트웨어에 버그가 있는지 파악할 수 있다.
잘못된 캐싱
API는 보편적인 질문의 결과를 캐시 처리하여 응답 속도를 높이고 연산 능력을 절약하고 싶어하는 경우가 많다. 캐싱이 제대로 작동하면 모두가 만족스러운 답변을 받게 된다. 하지만 캐싱이 과도하게 공격적이면 사용자는 오래된 답변을 받고 이것들이 언제 생성되었는지 파악할 수 없게 된다. 캐싱을 거의 또는 전혀 사용하지 않으면 이 문제가 해결되지만 연산능력과 복잡성이 희생된다. 적절한 균형을 찾는 것이 어려울 수 있다.
프레임워크 무시
API는 오늘날 보편적이기 때문에 프로그래머들은 스웨거(Swagger), 오픈API(OpenAPI), 기타 클라우드 기업들의 상용 버전 등 좋은 프레임워크를 만들었다. 몇 줄만 작성하여 파라미터를 지정하면 프레임워크가 대부분의 작업을 처리한다. 이런 프레임워크에는 악용을 차단하고 최신 측정을 제공하여 사용량을 추적하는 좋은 필터가 있다. 자체적인 버전을 만드는 것은 매우 멍청한 생각이다.
무료 티어에 대한 검토 소홀
API의 무료 티어는 새로운 사용자를 유인하는 훌륭한 수단일 수 있다. 코더가 상사에게 예산선과 승인을 요청해야 하는 경우 API가 제공할 수 있는 것을 실험하고 보여주기가 더 어려워진다. 하지만 무료 티어는 너무 관대하다면 이런 개발자들이 유료 고객이 되지 않고 API를 계속 사용할 수 있다. API별로 적절한 양을 찾는 것이 어렵다. 일부 API는 기초 데이터가 변경되지 않아 캐시 처리가 쉽기 때문에 무료 사용자가 액세스를 연장할 수 있다. 장기간 캐시 처리하기 쉬운 데이터는 엄격히 관리한다. 하지만 주된 결과가 빠르게 성장하거나 절대로 캐시 처리할 수 없는 경우 좀 더 관대해져야 한다.
잘못된 API 가격 책정
API를 관리하는 이들이 접하는 주요 문제 중 하나는 적절한 데이터 가격 책정 방법을 찾는 것이다. 수치를 너무 낮게 설정하면 수익 목표를 달성하지 못한다. 너무 높게 설정하면 사람들이 떠나간다. 모든 마케팅 및 가격 책정 표준 기법은 공정성 게임이다. 일부 기업들은 대형 사용자들로부터 수익을 얻기 위해 프리미엄 티어를 따로 설정한다. 높은 공개 가격을 설정한 후 관대한 개인용 상품을 제공하는 곳도 있다. 이 문제에는 정답이 없으며 경영대학원에 다니는 사람들이 이 마케팅 문제에 관한 여러 논문을 쓰고 있다.
서버리스(Serverless) 미활용
클라우드플레어 워커스(Cloudflare Workers)나 AWS의 람다(Lambda) 같은 도구가 모든 API에 적합하지는 않을 수 있겠지만 이상적인 경우가 많을 수 있다. 이것들은 거의 사용량과 비례하는 단순한 가격 수준을 제공하여 효과적인 비즈니스 모델을 구성하기가 훨씬 쉽다. 클라우드 기업이 각 기능 혁신에 대해 X달러를 청구하고 각 API가 기능 혁신으로 전환된다면 인프라의 수지타산을 맞추기 위해 각 API에 최소 X달러를 청구해야 할 것이다. 모든 API는 비용이 다르며 상당할 수 있지만, 최소한 서버리스 모델을 통해 경리 담당자는 API 운용을 위한 가변적인 비용의 가격을 더 쉽게 책정할 수 있다.
오류 메시지를 즐기지 않기
404 오류 메시지를 처음 만든 사람이 누구일까? 각 API에는 유머를 더할 수 있는 여러 기회가 존재한다. 비어 있거나 잘못된 형식의 요청은 너무 뻔하지만 특정 API에 이스터 에그를 숨기기 좋을 수도 있다. 시리(Siri)와 알렉사(Alexa)를 설계한 엔지니어링팀들은 “격납고 문을 열어라”(Open up the pod bay doors)에 대한 응답을 마련해야만 했다. 당신의 경우는 어떨까?
dl-ciokorea@foundryco.com
