네트워크

글로벌 칼럼 | API, 네트워크 업체 종속의 숨은 위협

Tom Nolle | Network World 2021.12.09
대부분 기업은 네트워크의 업체 종속을 우려한다. 기업에 종속 회피 방법을 물으면, ‘표준 인터페이스’ 또는 ‘오픈소스’라고 답한다. 오늘날까지도 종속 회피 조치에 ‘API 관리’를 포함한 기업의 수는 많지 않다. 하지만 API는 현재 가장 빠른 속도로 성장하는 종속 문제이며, 앞으로 중대한 문제가 될 것임이 확실하다. 
 
ⓒ Getty Images Bank

API는 ‘애플리케이션 프로그래밍 인터페이스(application programing interface)’를 의미한다. 오늘날에는 의미가 확장돼 애플리케이션뿐만 아니라 클라우드, 네트워크에 사용하는 모든 소프트웨어 컴포넌트의 인터페이스를 가리킨다. API는 소프트웨어 조각이 서로 통신할 수 있게 해준다. 따라서 하드웨어 장치가 연결된 환경보다는 소프트웨어 컴포넌트가 연결된 환경에서 필수적이다. 표준 인터페이스만큼이나 중요한 것이다. 하지만 이렇게 중요한 API의 흐름을 추적하는 기업은 극히 드물다. 

네트워크 장비에는 4개의 소프트웨어 계층이 있다. 최하단에는 이더넷 인터페이스 칩을 소프트웨어와 연결하는 드라이버가 있다. 그 위에는 일반적인 호스팅 기능을 제공하는 NOS(Network Operating System)가 있고, 그 위에는 특수한 네트워크 기능을 처리하는 ‘미들웨어’가 있다. 최상부에는 통합 커뮤니케이션이나 서비스 거부 공격 완화 등 관리 및 서비스 기능을 하는 네트워크 의존 애플리케이션이 있다. 이들 계층은 API를 다른 계층으로 노출한다. 

우리는 이더넷과 광 네트워크, 무선 네트워크까지 다양한 하드웨어 인터페이스에 익숙하다. 또 이더넷 커넥터를 광 네트워크 포트에 연결할 수 없다는 것과 입력 선을 출력 단자와 연결하면 안 된다는 것을 잘 안다. 하지만 API는 물리적 커넥터가 없다. 


소프트웨어에서 발생하는 API 문제

API는 메시지 교환 규격이다. 메시지 포맷, 데이터 구조, 요청/응답 동기화 등 모든 측면이 API 규격 내에 설정되어 있고, 전체 요소가 일치하지 않으면 해당 API를 사용하는 소프트웨어는 적절하게 통신할 수 없다. 서로 맞지 않는 API는 소프트웨어 통신을 단절시킨다. 장치 및 네트워크 관리 센터 내의 소프트웨어가 작동하지 않는 것이다. 

이를 인지하는 네트워크 솔루션 업체는 API를 라이선스 하에서 배포한다. 따라서 기업은 API를 라이선스 조항에 따라 사용할 수밖에 없다. 라이선스를 보유한 API에 다른 업체의 소프트웨어를 부착하는 것은 아마 불가능할 것이다. 라이선스 조항을 위배하지 않고 어댑터 소프트웨어를 자체적으로 개발했다고 해도 마찬가지다. 라이선스를 보유한 API에 맞춰 소프트웨어를 제작했다가 추후 소프트웨어를 변경하면, API 사용 권리를 잃을 수 있다. 실제로 필자는 한 금융 서비스 업체에서 정확히 이런 문제를 목격했다. 해결하는 데는 몇 개월이 걸렸다. 

솔루션 업체가 사용자를 종속하는 데 API를 사용하지 않는다고 해도, API가 의도치 않은 종속을 유발할 수 있다. 앞서 설명한 4가지 소프트웨어 계층에서 각 계층은 NOS API를 사용하는데, 대다수 NOS는 드라이버 API를 사용하며, 미들웨어는 NOS API와 다른 미들웨어 패키지의 API를 모두 사용한다. 이들이 모여 상호 연결망을 생성하는 것이다.

이때 NOS 공급업체가 API를 변경한다고 가정해보자. 1차 미들웨어 솔루션 업체가 해당 변경 사항을 지원하지만 다른 미들웨어 업체는 이를 지원하지 않는다면, 새 NOS를 설치했을 때 API 변경 사항을 지원하지 않는 모든 미들웨어와의 연결이 단절된다. 새 NOS를 설치하지 않는다면, 해당 미들웨어 업체의 신기능을 전혀 이용할 수 없다.

오픈소스 소프트웨어에도 API 문제가 있다. 오픈소스 라이선스는 대부분 커스터마이징을 금지하지 않고 소스코드를 공개하도록 규정한다. 오픈소스 NOS나 미들웨어, 또는 네트워크 관리 소프트웨어 도구 공급업체가 몇몇 API를 커스터마이징하고, 소스코드를 공개한다면 해당 오픈소스 라이선스 규정을 준수한 셈이다. 그러나 표준 API를 기준으로 제작된 소프트웨어는 커스터마이징된 API와 상호작용하지 못한다. 

리눅스에서 이런 문제를 경험한 적 있다. 리눅스는 수많은 배포판과 다양한 미들웨어 컴포넌트를 포함한다. 예컨대 파이썬을 사용하는 리눅스에서 앱을 실행하려고 한다고 가정했을 때, A 배포판과 B 배포판에 포함된 파이썬 버전이 다를 수 있다. 파이썬을 이용하는 앱과 툴이 있음에도 파이썬 API가 버전에 따라 바뀐다면 여러 배포판에서 사용할 수 있는 소프트웨어를 개발할 방법이 없다.


업체 종속을 피하는 API 관리법

하드웨어는 물리적 인터페이스로, 소프트웨어는 API로 연결된다. 네트워크 운영 단계와 분산된 기기에서 네트워킹이 소프트웨어를 하드웨어에서 분리하고 소프트웨어 패키지를 결합해 제반 기능을 구축한다면, 물리적인 인터페이스뿐만 아니라 API에도 신경을 써야한다. 어떤 방법이 있을까?

첫 단계는 소프트웨어 제품이 노출하고 소비하는 모든 API에 대한 상세 설명을 요구하는 것이다. 이 설명에는 해당 제품이 지원하는 표준, 모든 보완 및 확장 기능, API와 연관된 라이선스 조항을 포함해야 한다. 또 API를 이용하는 샘플 코드를 요청해 API의 작용 방법을 파악해야 한다. API로 패키지 A와 B를 연결할 계획이라면, 이들 패키지의 API 규격이 완전히 일치하는지 확인해 두 패키지가 지원하지 않는 확장 기능(특정 기능 또는 명령 등)을 불러오는 상황을 방지해야 한다.

두 번째 단계는 API 변경이 있을 때마다 소프트웨어 버전 이력을 입수하는 것이다. 조사해야 할 것은 API 변경이 각종 소프트웨어 패키지에 반영되는 일정이다. 패키지 A의 공급업체가 신규 API를 매우 신속하게 지원하더라도 지원 속도가 느린 다른 업체의 제품을 함께 사용한다면 문제가 된다. 해당 API를 사용하는 모든 업체가 업데이트할 때까지 계속 문제가 발생하며, 일부 API 연결을 끊지 않고는 소프트웨어를 업데이트할 수 없게 될 것이다. 

마지막 단계는 가정을 계약화하는 것이다. 아무리 조사를 꼼꼼하게 하더라도 정책이나 방향의 변화를 놓칠 수 있고, 소프트웨어 업체가 API를 변경한다면 앱이나 네트워크에 단절이 발생한다. 따라서 변화할 수 있는 상황을 계약 조항으로 명문화할 필요가 있다. 

네트워크 기기 또는 애플리케이션은 대표적인 ‘블랙박스(black box)’다. 내부 구조를 상세히 들여다볼 수 없다는 의미다. 블랙박스는 입출력 관계에 따라 정의된다는 말이 있다. 소프트웨어는 글자 그대로 API 간 관계로 정의되지만, 사용자는 주의를 기울이지 않는다. 고의적이든 우발적이든, 네트워크 업체의 종속을 피하고 싶다면 API를 심각하게 받아들여야 한다. editor@itworld.co.kr

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

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

Copyright © 2024 International Data Group. All rights reserved.