API 수명 주기란 무엇인가요?

API는 소프트웨어 애플리케이션 간 데이터, 기능 및 기능성을 교환할 수 있도록 하는 규칙 또는 프로토콜의 집합입니다. API 생성 및 배포에 초점을 맞춘 API 생산자 수명 주기와 소비자 관점에서 API 사용에 초점을 맞춘 API 소비자 수명 주기가 있으며 이 글에서는 API 생산자 수명 주기에 중점을 둡니다.

단일한 표준 API 생산자 수명 주기는 존재하지 않습니다. 출처에 따라 다양한 형태가 있을 수 있지만 일반적으로 수명 주기는 계획, 설계, 개발, 테스트, 배포, 모니터링 및 폐기 단계로 구성됩니다.

API 관리 플랫폼은 API 수명 주기 전반의 활동을 체계화하고 IT 환경 전반에서 API 전략, 거버넌스, 문서화 및 디렉터리를 중앙 집중화하는 데 자주 사용됩니다. 많은 플랫폼에는 고급 분석 기능과 API 검색 및 수익화 툴이 포함되어 있어 조직이 API를 최대한 활용할 수 있도록 지원합니다.

전체 API 수명 주기를 고려하고 이해하면 개발 팀이 리소스를 보다 효율적으로 할당하고 현실적인 전달 일정 계획을 수립하며 모든 이해관계자에게 진행 상황을 공유하고 API가 비즈니스 요구 사항을 충족하도록 보장할 수 있습니다. 결국 잘 설계되고 실행된 수명 주기는 높은 성능과 보안을 갖춘 API와 더 우수한 사용자 경험을 제공합니다.

엔드투엔드 API 수명 주기 관리는 초기 계획 단계에서 시작하여 대부분의 경우 폐기 또는 대체로 끝나는 여러 핵심 단계로 구성됩니다. 예를 들어 고객 데이터를 지원 티켓 시스템, 회계 시스템, 프로젝트 관리 플랫폼 등 다양한 비즈니스 툴과 동기화하기 위해 API를 구축하려는 소프트웨어 회사를 생각해 보겠습니다.

API 구축은 다음과 같은 기본적인 질문에 답하는 것에서 시작됩니다. 왜 이 API가 필요한가, 대상은 누구인가, 어떻게 사용될 것인가, 성공은 어떻게 측정할 것인가? 

API 프로젝트의 목표를 구체적으로 정의하면 API 설계에 필요한 기능과 기능성을 명확히 하는 데 도움이 됩니다. 이 소프트웨어 개발 사례에서 API의 목표는 회사가 사용하거나 사용할 예정인 애플리케이션과 플랫폼 간에 고객 데이터가 원활하게 이동하도록 하는 것입니다. 

이 계획 단계에서 조직은 다음을 수행합니다.

• API의 잠재적인 비즈니스 이점 검토
• 이 API가 비즈니스 요구를 어떻게 충족할지 설명
• 기존 API나 네이티브 통합 마켓플레이스에 요구 사항을 충족할 수 있는 다른 제품이 없는지 확인(즉, 해당 API 구축이 필요한지 검증)
• 어떤 애플리케이션과 플랫폼이 API에 의존하는지와 API가 기존 워크플로와 어떻게 통합될지를 명확히 정의합니다.

다음으로 팀은 잠재 사용자와 사용 사례를 논의해야 합니다. 이 API는 내부용으로만 사용할 것인가? 어떤 팀이 이 API를 어떤 목적으로 사용할 것인가? 설계 및 개발 단계에서 고려해야 할 보안 이슈가 있는가? 그리고 무엇보다 API 생산의 각 단계에 대한 책임자는 누구인가?

프로젝트 완료 일정 설정은 프로젝트가 예산 범위 내에서 진행되도록 하는 데 도움이 됩니다. 중요하게도 일정은 현실적이고 유연해야 합니다. 

팀은 다음과 같은 질문에 답하게 됩니다. 신규 기능 출시일과 같이 반드시 지켜야 할 특정 일정이 있는가? 이 API를 배포하기 전에 승인해야 하는 보안 또는 법적 컴플라이언스 팀이나 기타 이해관계자가 있는가? 

API 관련 문서와 기타 정보는 어디에 저장되며 개발자와 사용자 모두가 어떻게 접근할 수 있게 할 것인가? 코드 변경 사항은 어디에서 추적되고 저장될 것인가?

이러한 질문에 초기 단계에서 답하는 것은 이후 수명 주기에 대한 명확한 계획을 수립하는 데 도움이 됩니다.

계획 단계가 원하는 결과를 정의한다면 설계 단계는 그 목표에 도달하는 방법을 정의합니다. 설계 과정 전반에서 API 설계 팀은 계획 단계에서 정의된 요구 사항을 충족하기 위해 API를 어떻게 구축할지 결정합니다. 

팀은 API가 사용할 프로토콜과 아키텍처 스타일에 대한 설계 결정을 내려야 합니다. 이 결정은 조직의 기존 API 아키텍처 또는 새로운 API의 예상 사용 사례를 기반으로 이루어질 수 있습니다.

예를 들어 일반적인 API 프레임워크 및 아키텍처에는 REST, GraphQL 및 gRPC가 있으며 각각 고유한 장점과 단점이 있습니다. 

• REST: 단순하고 직관적이며 널리 사용되지만 복잡한 쿼리에는 적합하지 않고 강한 타입 지정을 제공하지 않습니다.
  
  
• GraphQL: 효율적이며 강한 타입 지정과 내장 문서화를 제공합니다. 그러나 GraphQL은 복잡할 수 있으며 REST보다 더 많은 설정과 전문 지식을 요구합니다.
  
  
• gRPC: 빠르고 강한 타입 지정, 자동 코드 생성 및 양방향 스트리밍을 제공합니다. gRPC는 마이크로서비스 간 통신에 자주 사용됩니다. 그러나 비교적 새로운 프레임워크이기 때문에 학습 곡선이 존재할 수 있으며 문서 형식이 사람이 읽기 쉬운 형태가 아니라 이진 형식입니다.

API를 설계할 때 팀은 적절한 인증 방식(OAuth 2.0 등)과 API가 API 게이트웨이 뒤에 위치해야 하는지 여부도 결정합니다.

명세 문서는 API의 구조, 동작 및 기능을 표준화된 방식으로 설명합니다. 이 문서는 API가 어떻게 구축되었는지, 어떤 기능을 수행하는지, 어떻게 상호작용할 수 있는지에 대한 정보를 제공하는 신뢰할 수 있는 단일 소스 역할을 합니다. 

가장 널리 사용되는 표준 명세는 OpenAPI 명세로 개발자가 경로, 메서드, 매개변수, 인증 방식 등을 정의할 수 있도록 합니다. OpenAPI는 REST API에 특화되어 있으며 코드 생성, 편집 및 자동 문서 생성을 제공하는 Swagger라는 오픈 소스 툴 세트를 지원합니다.

GraphQL의 경우 이에 해당하는 명세는 GraphQL 스키마이며 이는 스키마 정의 언어(SDL)로 작성된 강한 타입 기반 계약으로 사람이 읽기 쉬운 형식입니다. GraphQL 에코시스템은 OpenAPI와 유사한 기능을 제공하도록 이 스키마를 활용하는 다양한 툴을 제공하며 예를 들어 GraphiQL은 개발자가 샌드박스로 사용할 수 있는 브라우저 기반 통합 개발 환경(IDE)입니다. 

gRPC의 경우 Protocol Buffers, 즉 protobuf가 직렬화 형식이자 인터페이스 정의 언어(IDL)로 사용되며 명세에 가장 널리 사용되는 파일 형식입니다. protobuf는 자체적으로는 인터랙티브 테스트를 제공하지 않지만 이를 지원하는 웹 UI가 존재합니다.

이 단계에서 개발자는 이전 단계에서 정의된 API 설계 계획에 따라 코딩을 시작합니다. 버전 관리 시스템은 개발 과정 전반에서 버전과 코드 변경 사항을 추적하는 데 사용됩니다.

버전 관리 시스템의 업계 표준은 Git이며 이는 개발자의 장치에 로컬로 저장된 코드 변경 사항을 추적하는 오픈 소스 소프트웨어입니다. 개발자는 Git을 사용해 코드를 생성하고 관리하며 변경 사항을 추적하지만 이를 자신과 다른 사람이 접근할 수 있도록 저장할 공간이 필요합니다. 

GitHub는 가장 인기 있는 Git 호스팅 서비스로 무료 및 유료 플랜을 모두 제공하며 Git 코드 리포지토리의 저장, 조회 및 협업을 지원합니다. Git 리포지토리를 호스팅할 수 있는 대안으로 GitLab, AWS CodeCommit 및 Microsoft Azure Repos 등이 있습니다.

API 테스트는 개발 단계 중과 이후 모두 수행되며 지속적인 테스트는 취약점과 요구 사항을 드러내고 정기적인 업데이트를 가능하게 하여 개발을 지원합니다. 

단위 테스트는 코드의 작은 부분을 분리하여 개별적으로 테스트하는 것을 의미합니다. 앞서의 소프트웨어 회사 API 사례에서 사용자 정보를 조회하는 요청에 대한 응답을 테스트해야 한다고 가정해 보겠습니다. GET 명령은 고객 데이터베이스에서 사용자 ID를 기반으로 사용자 이름과 이메일 주소를 조회하기 위한 것입니다. 단위 테스트에서는 해당 GET 요청이 의도한 정보를 정확히 반환하는지 그리고 존재하지 않는 사용자 ID에 대한 요청이 적절한 오류 메시지를 반환하는지를 확인합니다.

통합 테스트는 일반적으로 단위 테스트 이후에 수행되며 단위 테스트에서 놓친 문제를 발견하는 데 사용됩니다. 통합 테스트는 여러 구성 요소 또는 서비스가 API를 통해 의도한 대로 통신하는지 보장하는 데 도움을 줍니다. 

다시 예로 돌아가 보면 특정 이벤트(예: 신규 고객 추가)가 발생했을 때 한 시스템에서 다른 시스템으로 웹훅 또는 알림이 전송되는 기능이 있다고 가정해 보겠습니다. 이를 확인하기 위해 CRM에 새로운 고객 정보가 추가되면 알림을 수신하고 예상된 동작을 수행하는 가짜 서버를 사용하여 통합 테스트를 설정합니다. 이 과정은 모든 통합에 대해 반복됩니다.

API 계약 테스트는 API가 사용자 기대에 부합하는 동작을 수행하는지 보장합니다. 이 계약은 일반적으로 API의 기능과 성능 요소를 정의하는 표준 기계 판독 가능 문서인 OpenAPI 명세 파일로 구성됩니다. API 명세 파일은 일반적으로 JSON 또는 YAML로 작성되며 API 엔드포인트, 인증 방식, 허용되는 요청 및 응답 형식, 메타데이터 및 입력 매개변수와 같은 요소를 포함합니다.

API 성능 평가는 일반적으로 속도와 효율성을 평가하는 것을 포함합니다. 이 단계에서 테스터는 쿼리 응답 시간, 오류율, 리소스 사용량(예: CPU 및 메모리 사용), 지연 시간 및 처리량을 측정합니다. 이 단계에서 API 성능을 이해하면 사용자 경험을 저하시킬 수 있는 병목 현상이나 중복 요소를 파악하는 데 도움이 됩니다.

API는 민감한 데이터를 전송하는 데 자주 사용되므로 보안 테스트는 매우 중요한 요소입니다. API 보안 테스트는 다양한 방식으로 API를 공격해 보면서 안전성과 안정성을 검증하는 것을 의미합니다. 이러한 테스트에는 사전 승인된 형식으로 입력된 데이터만 허용되도록 하는 입력 검증 테스트가 포함될 수 있습니다. 

입력 검증 테스트는 다양한 유형의 공격을 탐지합니다. 일반적인 공격 유형에는 악의적인 코드가 애플리케이션에 삽입되는 SQL 인젝션이 포함됩니다. SQL은 데이터베이스와 통신하는 데 사용되는 언어이며 특정 공통 SQL 명령은 전체 사용자 목록과 같은 무단 응답을 유발할 수 있습니다. 

기타 보안 테스트 방식에는 생체 인식과 같은 식별 보안 조치가 제대로 작동하는지 확인하는 인증 테스트와 사용자가 승인된 기능에만 접근할 수 있도록 보장하는 권한 부여 테스트가 포함됩니다. 

보안 테스트는 개발 단계 중과 이후 모두 수행되며 새로운 인공지능(AI) 기능과 자동화는 이러한 테스트의 강도와 정확성을 향상시키고 있습니다. AI 보안 테스트 툴은 테스트를 자동으로 생성하고 코드의 버그를 검사하며 성능 데이터를 분석해 문제를 예측하고 이상 행동을 탐지하는 등 다양한 기능을 제공합니다.

의료 및 금융 서비스와 같은 산업에서는 사용자 안전, 보안 및 개인정보 보호를 위해 규정, 법률 및 지침이 존재합니다. 예로는 HIPAA(미국 건강 정보), GDPR(EU 개인정보) 및 CCPA(캘리포니아 개인정보)가 있습니다. 

컴플라이언스 테스트는 API가 적용 가능한 모든 법률과 지침을 준수하는지 확인하는 테스트입니다. 예를 들어 GDPR은 “잊힐 권리”를 보장하며 이는 사용자가 부당한 지연 없이 자신의 데이터를 완전히 삭제해 달라고 요청할 수 있음을 의미합니다. GDPR을 준수하는 API의 컴플라이언스 테스트는 이 규칙이 제대로 적용되는지를 확인해야 합니다.

배포 단계는 API의 출시 단계입니다. 기능, 보안 및 컴플라이언스에 대한 테스트를 완료했으며 사용할 준비가 되어 있습니다. 배포 단계에서 API는 테스트 환경에서 라이브 프로덕션 환경으로 이동합니다. API 배포에는 여러 단계가 포함됩니다.

배포 전에 팀은 지원 인프라, API 문서, 사용자 지원, 배포 및 커뮤니케이션 전략, 모니터링 프로토콜이 모두 완료되고 준비되었는지 다시 검토해야 합니다. 이 체크리스트에는 서버 확장, 알림 설정, FAQ 페이지 생성, 고객 또는 대중 대상 공지 발송 등이 포함될 수 있습니다.

CI/CD는 지속적 통합/지속적 배포를 의미하며 소프트웨어 개발, 테스트 및 전달 주기를 자동화하고 간소화하는 실천 방식입니다. 이는 DevOps 방법론의 핵심 실천 방식입니다. 소프트웨어 애플리케이션과 마찬가지로 API도 배포, 테스트 및 업데이트를 간소화하고 자동화하기 위해 CI/CD 파이프라인에 통합되는 경우가 많습니다. 

API 게이트웨이는 클라이언트가 다양한 백엔드 서비스 또는 동일한 백엔드 서비스의 여러 인스턴스에 접근할 수 있도록 단일 진입점을 제공하는 소프트웨어 계층입니다. API 게이트웨이는 다음과 같은 여러 이점을 제공합니다.

• 단순성: 클라이언트는 여러 개가 아닌 단일 서비스 URL만 관리하면 됩니다.
  
  
• 로드 밸런싱: 조직은 단일 서비스에 대한 트래픽을 여러 인스턴스로 분산하여 부하를 분산시키고 성능 병목을 방지할 수 있습니다.
  
  
  
• 보안 및 거버넌스: 게이트웨이를 사용하여 여러 API에 걸쳐 표준화된 보안 및 거버넌스 프로토콜을 적용할 수 있습니다.
  
  
• 캐싱: 게이트웨이는 여러 서비스에 걸쳐 자주 접근되는 데이터를 저장하여 캐싱을 지원할 수 있습니다. 이는 응답 속도를 높이고 성능을 향상시키는 데 도움이 됩니다.

조직은 API를 일반에 완전히 공개하기 전에 테스트하기 위해 선택된 사용자에게 베타 릴리스를 제공하는 경우가 많습니다. 이를 통해 조직은 더 안전하고 통제된 환경에서 버그를 발견하고 수정하며 피드백을 수집하고 성능을 측정하며 API를 홍보할 수 있습니다.

체크리스트와 베타 출시가 완료되면 이제 “스위치를 켜고” API를 완전히 배포할 차례입니다. 이 과정에는 내부 또는 외부 고객에게 API를 알리고 사용을 장려하기 위한 배포 전략 실행이 포함될 수 있습니다. 배포 과정에는 사용자 가이드 및 기타 공개 자료 게시, 웹사이트 또는 API 디렉터리 업데이트, 비공개 인증 없이 즉시 접근이 가능하도록 설정 조정 등이 포함될 수 있습니다.

전체 API 수명 주기를 이해하고 계획하는 주요 이점 중 하나는 초기 단계부터 모니터링, 관측 가능성 및 유지 관리에 중점을 둘 수 있다는 점입니다. 출시가 끝이 아니라 이후에도 수행해야 할 작업이 남아 있습니다. API 모니터링은 실제 환경에서 API가 어떻게 작동하는지 실시간으로 확인하기 위한 지속적인 프로세스입니다. 

모니터링의 주요 지표에는 응답 시간(요청에 대한 API 응답 소요 시간), 오류율(실패한 요청의 비율), 처리량 및 트래픽(API가 처리할 수 있는 요청 수), 그리고 서버의 부하와 상태를 측정하는 인프라 분석이 포함됩니다.

유지 관리 단계는 모니터링 툴이 수집한 데이터에 대응하는 과정에서 이루어집니다. 유지 관리는 버그 수정, 성능 최적화 또는 새로운 기능과 역량 추가의 형태로 이루어질 수 있습니다.

CRM 사례에서 모니터링 툴이 고객 데이터가 한 플랫폼에서 다른 플랫폼으로 전송될 때 지연 시간이 높다는 점을 감지할 수 있으며 유지 관리 단계에서는 코드 중복 제거, 캐싱 설정 최적화 또는 고객과 더 가까운 위치로 서버를 이전하는 방식으로 이를 해결할 수 있습니다.

API 수명 주기의 종료 단계 역시 다른 단계만큼 중요하고 동적이며 많은 정보를 제공합니다.

버전 관리는 API의 활성 수명 동안 업데이트를 통해 효율성을 유지하는 확장된 프로세스입니다. 버전 관리의 핵심은 기존 사용자에게 영향을 주지 않으면서 변경 사항과 개선 사항을 제공하는 것입니다. 

간단한 버그 수정과 같은 경우 이러한 변경은 “비호환성 없음”으로 간주되므로 새로운 API 버전을 적용하지 않고 업데이트가 이루어지는 것이 일반적입니다. 그러나 기존 버전과 호환되지 않는 “비호환성 변경”의 경우에는 새로운 버전으로 변경 사항을 도입하는 것이 바람직합니다.

초기부터 지속적인 커뮤니케이션은 버전 관리의 핵심입니다. 일반적인 방식은 병렬 버전을 지원하는 것으로 이전 버전은 새로운 버전과 함께 계속 활성 상태로 유지되며 개발자는 사용자에게 새로운 버전으로 전환하도록 변경 사항을 안내합니다. 모든 사용자 또는 충분한 수의 사용자가 전환하면 이전 버전은 비활성화할 수 있습니다.

폐기는 API를 영구적으로 제거하고 비활성화하는 것을 의미합니다. 모든 API가 폐기되는 것은 아니지만 시간이 지나면서 API를 교체하는 경우가 많습니다. API가 폐기되는 데에는 여러 가지 이유가 있습니다.

• 새로운 버전이 더 뛰어난 성능을 제공하는 경우
• 컴플라이언스 또는 보안 요구 사항이 더 이상 충분히 충족되지 않는 경우 
• 조직 내 비즈니스 또는 재무적 변화가 발생한 경우
• 최신 소프트웨어와의 호환성 부족

폐기 이후 API는 더 이상 작동하지 않습니다. 하지만 이 전환을 원활하게 하기 위한 몇 가지 단계가 있습니다.

API 폐기는 논의를 필요로 합니다. API를 폐기해야 하는가, 그 이유는 무엇인가? 대안이 있다면 무엇인가, 그리고 예정된 폐기에 대해 누구에게 알릴 필요가 있는가?

일반적으로 조직은 API 폐기 예정 사실을 공지합니다. 이 공지에는 변경 이유, 시행 시점, 사용자에게 필요한 조치 등 API 사용자에게 필요한 모든 정보가 포함됩니다. 

이후 API는 공식적으로 지원 중단 상태가 됩니다. 이 단계에서 API는 계속 작동하지만 더 이상 새로운 업데이트나 기능은 제공되지 않습니다. 지원 중단 기간은 사용자가 필요한 변경을 수행할 수 있도록 시간과 인식을 제공하기 위한 것입니다.

“선셋 데이”는 공개 API가 완전히 종료되는 시점으로 이때부터 요청은 더 이상 처리되지 않으며 API에 접근하려는 클라이언트는 오류 메시지를 받게 됩니다. 이러한 변경 사항을 반영하여 문서를 업데이트하고 API가 사용하던 서버 공간이나 기타 인프라를 정리하는 것이 바람직합니다. 

폐기된 API에 대한 사후 분석은 유용한 작업이 될 수 있습니다. 팀은 전체 API 수명 주기에서 얻은 교훈과 이를 향후 프로젝트에 어떻게 적용할 수 있을지 논의할 수 있습니다.