API는 새로운 CLI입니다. 하지만 어떤 종류의 API를 구축할지 결정할 때는 선언형 방식이 대세입니다.
API, 즉 애플리케이션 프로그래밍 인터페이스는 오늘날 필수적인 역량입니다. 조직은 비즈니스 계층에 API를 도입하여 파트너 통합과 이른바 "시민 개발자"에 의한 혁신을 촉진합니다. 애플리케이션에도 API가 있어 통합을 간소화하고, 자주 변경될 수 있는 비즈니스 로직을 상대적으로 변경 빈도가 낮아야 하는 인터페이스와 분리합니다. 인프라에도 API가 있습니다. 스위치와 라우터부터 애플리케이션 서비스, 미들웨어, 데이터베이스에 이르기까지 제공 및 배포 파이프라인을 구성하는 인프라는 API를 통해 구동됩니다.
이 사실만으로도 새롭게 부상하는 NetOps 커뮤니티에 어떤 의미가 있는지 잠시 멈춰 생각해 볼 필요가 있습니다. 조직은 몇 가지 핵심 애플리케이션 인프라 구성 요소를 표준으로 채택하는 경향이 있지만, 네트워크 및 애플리케이션 서비스 인프라 구성 요소의 경우에는 소수의 핵심 요소만을 표준화할 가능성이 그리 높지 않기 때문입니다.
조직이 애플리케이션을 더 빠르고 안전하게 만들기 위해 사용하는 평균 16개의 서로 다른 애플리케이션 서비스는 분명 소수보다 많은 인프라 구성 요소를 통해 제공됩니다. 구성 요소 하나당 애플리케이션 서비스가 3개라고 넉넉하게 가정해도, 서로 다른 장치가 5개이며 API도 5개나 됩니다.
여기서 문제는 인프라 제공업체가 "API는 새로운 CLI다"라는 말을 지나치게 문자 그대로 받아들이는 경우가 많다는 점입니다. 즉, API는 단지 CLI를 REST 방식으로 구현한 것에 불과합니다.
인프라 구성 요소 전반에서 CLI를 사용해 본 사람이라면 CLI 탐색 구조가 인프라의 객체 모델과 매우 밀접하게 대응한다는 점을 잘 알고 있습니다. API는 이러한 설계를 HTTP로 그대로 옮기는 데 그치는 경우가 많습니다. 따라서 API를 활용하려는 사람은 해당 장치의 객체 모델도 반드시 익혀야 합니다.
이러한 추상화 수준은 자동화와 오케스트레이션의 발전을 저해하고 있습니다. 이제는 단순히 자동화 인재를 찾는 데 그치지 않고, 서로 다른 5개 이상의 네트워크 인프라 모델에 대해 일정 수준의 전문성을 갖춘 자동화 인재를 찾아야 하기 때문입니다. 또한 요구되는 전문성 수준에는 VLAN 구성 및 라우팅에 대한 기초적인 이해부터 가상 서버, 가상 IP 주소, 노드, 멤버 및 풀 간의 관계에 이르기까지 폭넓은 도메인 지식이 필요한 경우가 많습니다.
인프라의 근본적인 복잡성을 그대로 드러내면 도입을 촉진하고 자동화를 구현하는 데 방해가 됩니다. 인터페이스는 모델과 로직을 추상화하여 사용자와 운영자가 이러한 복잡성을 직접 다루지 않도록 보호해야 합니다. GUI는 간단한 서비스를 구성할 때 객체 계층 구조를 탐색할 필요가 없도록 함으로써 이를 실현합니다.
그렇기 때문에 API가 이 끔찍한 탐색 문제를 다시 불러왔다는 사실을 알게 되면 답답할 때가 많습니다.
이 문제는 네트워크 및 애플리케이션 인프라에만 국한된 것이 아닙니다. 실제로 MuleSoft의 "API 가치의 상승" 연구에 따르면, 고객과 파트너가 API 통합과 관련해 가장 많이 요구한 사항은 응답자의 47%가 선택한 "특정 비즈니스 요구에 맞는 맞춤형 API"였습니다. 그 뒤를 더 나은 문서화(19%), '노코드' 통합 템플릿(19%), 필요한 API를 쉽게 사용할 수 있도록 해주는 SDK 래퍼(13%)가 이었습니다.
이 모든 요구는 단순화에 대한 요청으로 요약할 수 있습니다. 그리고 기술에서 단순화란 추상화를 의미합니다.
이제 이 글의 핵심으로 들어가 보겠습니다. 바로 선언적 인터페이스가 그러한 추상화라는 점입니다. 선언적 인터페이스는 오늘날 인프라를 프로비저닝하고 구성하며 관리하고 통합하는 데 사용되는 인터페이스를 단순화함으로써 누구나 인프라를 활용할 수 있게 하고 새로운 기회를 열어 줍니다.
선언형과 명령형
일반적으로 선언형과 명령형은 모두 API의 유형으로 볼 수 있습니다. 명령형 API는 누군가 API라고 말할 때 흔히 떠올리는 방식입니다. 명령형 API는 대상 시스템에 작업을 수행하는 정확한 방법을 지시합니다. 가상 서버를 추가하려면 별도의 API 호출이 5번, 10번 또는 그 이상 필요하더라도 정확히 어떻게 추가할지 일일이 지시해야 합니다.
즉, 적절한 속성을 가진 특정 객체(예: IP 주소가 있는 노드)를 생성하도록 지시해야 합니다. 그런 다음 해당 노드가 할당될 풀을 이름과 함께 생성하도록 시스템에 별도로 지시해야 합니다. 그다음에는 또… 이제 무슨 뜻인지 아실 겁니다. 명령형 API를 사용하려면 시스템과 그 객체 모델뿐만 아니라 원하는 결과를 얻는 데 필요한 단계까지 이해해야 하므로 사용자에게 부담이 됩니다.
이것이 바로 명령형 방식을 사용할 때 치러야 하는 API 비용입니다.
명령형 API가 전반적으로 나쁜 것은 아닙니다. GUI를 구축하거나 명령형 API가 제공하는 수준의 세밀한 제어가 필요한 다른 시스템과 통합할 때는 매우 중요합니다. 명령형 API도 필요하지만, NetOps 및 DevOps용 자동화와 통합에는 적합하지 않을 뿐입니다.
하지만 나머지 사람들은 그 정도로 세세한 내용까지 알 필요가 없습니다. 실제로 그처럼 깊이 있는 지식을 요구하면 거부감을 불러일으키고 자동화 및 오케스트레이션 작업의 속도를 늦출 수 있습니다. 이는 인프라의 대중화와 DevOps 및 개발자를 위한 셀프서비스 모델 구현에 적합하지 않으며, 특정 인프라 영역 밖의 NetOps에는 더더욱 그렇습니다.
바로 이 지점에서 선언형 API가 중요한 역할을 합니다.
선언적 인터페이스는 원하는 작업이 무엇인지 지정하면, 관련 로직과 워크플로는 시스템이 알아서 처리합니다. 따라서 시스템에 노드와 풀을 생성하고 필요한 객체에 적절한 로직을 모두 수행하라고 일일이 지시하는 대신, 해당 객체와 객체 간의 관계를 기술하면 됩니다.
일부 선언형 인터페이스는 JSON을 사용하고, 다른 인터페이스는 XML을 사용하며, 일부는 여전히 단순한 폼 데이터에 의존하기도 합니다. 이들의 공통점은 객체 모델과 시스템 계층 구조를 거의 이해하지 않아도 될 만큼 데이터가 객체를 단순하고 명확하게 기술한다고 가정한다는 것입니다.
예를 들어, 이 선언은 사람이 읽고 이해하기가 비교적 쉽습니다. 객체 모델에 대한 기본적인 이해는 필요하지만, 이 선언을 작성하기 위해 특정 제품의 자격증까지 취득해야 할 정도는 아닙니다:
"web_pool": { "class": "Pool", "monitors": [ "http" ], "members": [ { "servicePort": 80, "serverAddresses": [ "192.0.1.10", "192.0.1.11" ] } ] }
바로 이 지점에서 선언적 인터페이스의 가치가 분명해집니다. 인프라 프로비저닝 및 구성에 필요한 도메인 지식과 복잡성을 줄일 수 있기 때문입니다. 요구되는 전문 지식 수준을 낮춤으로써 NetOps는 더 빠르고 효율적으로 작업할 수 있을 뿐만 아니라, 이제 DevOps와 개발자도 이 기능을 활용하도록 장려할 수 있습니다.
선언적 인터페이스를 인프라 관리의 표준 방식으로 채택하면 셀프서비스와 고급 자동화 기능을 구현하는 데 활용할 수 있는 인재 풀이 즉시 확대됩니다. 위의 선언적 인터페이스는 DevOps 담당자와 개발자가 이해하고 사용하는 데 별다른 설명이 필요하지 않습니다. 반면 명령형 인터페이스로 원하는 결과를 얻으려면 먼저 인프라별 모델과 워크플로를 익히는 데 훨씬 더 많은 노력을 기울여야 합니다.
선언적 인터페이스는 배포 파이프라인을 자동화하고 시스템을 다른 인프라 서비스와 통합하는 데 필요한 프로비저닝, 구성 및 관리를 간소화함으로써 누구나 인프라를 쉽게 활용할 수 있도록 합니다. 인프라의 대중화는 더 빠르고 지능적인 자동화를 가능하게 하며, NetOps와 DevOps의 이점을 실현하는 데 필요한 운영 영역 간 협업과 공조를 촉진할 수 있음을 의미합니다.
작성자 소개
Lori MacVittie는 F5 CTO 오피스의 수석 엔지니어이자 최고 에반젤리스트로, 애플리케이션 딜리버리, 자동화 전략 및 인프라 분야에서 깊이 있는 전문성을 보유하고 있습니다. AI 에이전트를 위한 가드레일을 정의하고, 취약한 멀티클라우드 아키텍처를 분석하며, 확장 가능한 시스템의 한계를 탐구하는 등 복잡한 문제를 명확하게 풀어내는 것으로 잘 알려져 있습니다. 애플리케이션 개발, IT 아키텍처, 네트워크 및 시스템 운영 전반에 걸쳐 30년 이상의 업계 경험을 쌓았습니다. F5에 합류하기 전에는 수상 경력이 있는 기술 편집자로 활동했습니다. MacVittie는 컴퓨터 과학 석사 학위를 보유하고 있으며, 보안, 클라우드 및 엔터프라이즈 아키텍처 분야를 아우르는 다수의 저서를 집필한 작가입니다. 또한 보드게임과 비디오 게임을 열정적으로 즐기며, 치즈에 대해서는 거리낌 없이 확고한 견해를 갖고 있습니다.
Lori Mac Vittie의 다른 블로그 게시물관련 블로그 게시물
AI 시대의 새로운 애플리케이션 제공 원칙으로 복잡성 극복하기
보안, 일관성, 완전 자동화에 중점을 둔 애플리케이션 제공의 새로운 6가지 원칙을 도입하여 복잡성 없이 하이브리드 멀티클라우드의 유연성을 누리세요.
디지털 혁신을 가속화하는 6가지 기술 역량
오늘날의 엔터프라이즈 아키텍처에는 기술 변화를 주도하는 데 핵심적인 민첩성, 확장성, 보안 및 관찰 가능성이 부족하지만, 이 여섯 가지 핵심 역량은 기업이 디지털 혁신 전반에 걸쳐 위험과 과제를 관리하는 데 도움이 될 것입니다.
하이브리드 근무가 ID 중심 보안으로의 전환을 이끌고 있습니다
자동화와 디지털화의 폭발적인 성장에 하이브리드 근무 모델로의 전환 추세가 더해지면서, IP 기반 보안에서 벗어나 ID 기반 액세스 전략으로 전환하는 움직임이 더욱 가속화될 것입니다.
관점의 현대화: 애플리케이션에서 경험으로
그리스와 로마의 신들처럼, 여러 신화에서도 동일한 존재가 다양한 모습으로 나타나는 것을 볼 수 있습니다. 본질적으로 각각의 화신은 기존 존재가 새로운 얼굴로 드러난 것입니다. 디지털 세계에서도 이와 비슷한 양상이 나타납니다. 우리가 ‘애플리케이션’이라고 부르는 것들은 흔히 기존 기능이 새로운 형태로 구현된 것이라 볼 수 있습니다.
코로나19 이후 기업 결제의 디지털 전환
디지털 결제는 과거의 현금만큼이나 보편화되었습니다. 코로나19 팬데믹으로 인한 봉쇄 조치는 소비자의 디지털 결제 서비스 의존도를 더욱 빠르게 높였습니다. 기업의 디지털 결제 도입 역시 가속화되었습니다. 대중을 상대로 영업하든 하지 않든 기업에는 여전히 지급해야 할 대금과 받아야 할 대금이 있기 때문입니다.
공급망 해킹과 보안에서 하드웨어의 역할
수석 아키텍트 Dave Schmitt와 CTO 오피스가 최근 Bloomberg의 Super Micro 관련 기사를 계기로 하드웨어 보안 전문성의 중요성을 되짚어봅니다. 또한 이 글에서는 시스템이 안전하게 보호되고 있는지 확인하기 위해 공급업체에 물어봐야 할 질문도 소개합니다.