API 제품 관리의 플랫폼 사고방식

팬데믹으로 인해 조직이 디지털 우선 전략을 수용해야 할 필요성이 크게 확대되었다는 것은 비밀이 아닙니다. 다른 조직 목표를 위해 우선 순위를 낮추던 디지털 혁신이 밤새 전례 없이 시급하게 전면 및 중앙으로 이동했습니다. 2020년 McKinsey 글로벌 경영진 설문조사에 따르면, 기업은 COVID-19로 인한 중대한 도전에도 불구하고 내부 운영을 디지털화하고 디지털 제품 포트폴리오를 확장하는 속도를 몇 년 앞당겼습니다.

이러한 디지털 변환의 핵심은 API(응용 프로그래밍 인터페이스)로 촉진되는 통합입니다. 한때 API는 소프트웨어 시스템 간에 데이터를 전송하는 "메신저" 또는 "중개자"로 생각되었지만 이제는 디지털 생태계의 "연결 조직"으로 인식되어 API를 구축하고 활용하는 조직에 무한한 통합 및 비즈니스 기회를 제공합니다. 고유한 잠재적 API가 나타내므로 개발을 감독하는 제품 관리자는 완벽한 통합 경험을 보장하기 위해 유연성과 확장성을 강조하는 접근 방식을 채택하여 잠재 가치를 실현해야 합니다.

적은 비용으로 더 많은 작업 수행

전례 없는 지난 해 이전에도 조직에 대한 API의 가치는 잘 문서화되었으며 API 경제는 한동안 번성했습니다. 오늘날의 통합 환경을 이해하려면 BoB(Best of Breed) 철학의 기원을 탐색하는 것이 좋습니다. 1990년대 이전에 소프트웨어 공급업체는 조직의 다양한 문제를 해결하기 위해 ERP(Enterprise Resource Planning) 제품군 솔루션을 판매했습니다. 이러한 제품군은 조직별 사용 사례를 처리하지 못했기 때문에 점점 더 복잡하고 비실용적인 것으로 간주되었습니다. 결과적으로 공급업체는 모든 사람을 위해 모든 것을 시도하는 더 큰 제품군 대신 하나의 기능 영역에 대한 문제를 해결하는 더 집중된 도구를 구축하기 시작했습니다. 기업은 보다 작고 전문화된 다양한 도구 중에서 선택하는 아이디어를 환영하고 특정 요구 사항에 가장 잘 맞는 개별 솔루션 컬렉션을 모으기 시작했습니다.

점들을 잇는

BoB 접근 방식이 인기를 얻으면서 통합이 제품 전략의 중요한 부분이 되었습니다. 비즈니스의 한 영역에 대한 문제를 해결하는 데 탁월한 도구는 함께 사용될 가능성이 있는 다른 BoB 제품과 잘 통합될 수 있어야 했습니다. 조직에서 판매 파이프라인과 고객 관계를 추적하고 최적화하기 위해 구현한 판매 및 CRM 소프트웨어인 HubSpot을 고려해 보십시오. HubSpot은 고객 엔지니어링 팀의 추가 개발 없이 DocuSign(디지털 서명), Twilio(이메일/SMS 알림) 및 Zendesk(고객 지원)와 같은 다른 BoB 소프트웨어와 쉽게 통합됩니다.

서로 원활하게 연결되는 보완 도구의 필요성은 시스템 간의 상호 작용을 제한하기보다는 개방성을 수용하는 방향으로 업계 전반의 변화를 동반했습니다. 그 과정에서 제품이 지원하는 통합 수가 마케팅 가치가 있는 지표가 되었습니다.

플랫폼 제안

그러나 통합의 진정한 가치는 서로 다른 도구와 시스템을 조정하는 능력 이상입니다. API는 최상의 상태에서 제품을 플랫폼으로 전환하기 위한 집합적 메커니즘입니다. 제품은 정의에 따라 특정 응용 프로그램이 있는 도구입니다. 따라서 "앱"입니다. 그들은 여러 가치 제안, 나아가 여러 수익원을 창출하는 능력이 제한적입니다. 반면 플랫폼은 다른 방식으로 가치를 추가합니다. 즉, 수많은 제품을 구축할 수 있는 인프라 계층을 제공합니다.

API는 API를 활용하는 타사의 전문 지식을 활용하여 새로운 비즈니스 채널을 엽니다. 소비 개발자는 Google Maps의 Places API를 사용하여 사용자가 집을 찾는 데 도움이 되는 부동산 앱을 디자인하거나 Skyscanner의 Flight API와 Expedia의 Hotel API를 활용하여 특정 위치로의 여행을 전문으로 하는 생태 관광 사이트를 만들 수 있습니다. 이러한 개발자와 외부 파트너는 비즈니스에 맞게 조정할 수 있는 기존 데이터 및 서비스에 대한 액세스 권한을 얻음으로써 이익을 얻고 Expedia와 같은 API 소유자는 범위를 확장하고 제품에 호텔만 계속 나열했다면 존재하지 않았을 기회를 수익화합니다.

모듈화

제품 리더의 경우 성공적인 API 전략을 개발하려면 제품 사고에서 플랫폼 사고로 사고 방식의 전환이 필요합니다. 이는 기능을 재결합할 수 있고 소비하는 개발자를 위한 유연성을 우선시하는 모듈식 개방형 방식으로 제품을 구축한다는 것을 의미합니다. 고객이 다양한 요구를 충족하기 위해 다양한 방식으로 구매, 조립 및 맞춤화할 수 있는 IKEA 선반 시스템을 생각해 보세요. 훌륭한 API 제품 관리자는 API를 비즈니스 확장 및 가치 있는 파트너십 개발을 위한 도구로 봅니다. 이러한 가능성을 인식한다는 것은 채택을 보장하기 위해 모범 사례를 구현하는 것을 의미합니다.

개발자를 기쁘게

견고한 API 전략의 기본 기둥이 하나 있다면 DX(개발자 경험)입니다. API 통합의 경우 제품 관리자가 만족해야 하는 "고객"은 개발자를 소비하는 것입니다. 이들은 궁극적으로 API를 호출/통합하는 사용자이며, 제품 대 플랫폼 비전을 실현하는 데 도움이 될 수 있는 잠재적 파트너입니다. 그들의 경험에 "UX" 대신 "DX"라는 이름을 붙이면 그들이 일반적인 최종 사용자가 아니라 훨씬 더 기술적으로 능숙하다는 것을 알 수 있습니다. 그들과 공감하기 위해서는 그들의 구체적인 요구와 기대를 이해하는 것이 필수적입니다.

모범 사례

다음은 완전한 목록을 나타내는 것은 아니지만 소비하는 개발자에게 마찰이 없고 일관되고 예측 가능한 통합 경험을 보장하는 일류 API를 구축하기 위한 필수 사례입니다. 제품 관리자는 확장 가능한 방식으로 API 설계에 접근하고 모범 사례 프레임워크를 정의하고 팀이 새 API를 구축할 때 참조할 수 있는 문서로 게시해야 합니다.

일관된 명명 규칙 및 끝점

API의 특성과 목적을 명확하게 식별하는 API 끝점에 대한 일관된 명명 규칙을 설정하면 모호성이 제거되고 긍정적이고 예측 가능한 DX에 기여합니다. 모든 API에 대해 공통 기본 URL을 선택하고 전문 용어와 약어를 피하는 후행 URL에 대한 프레임워크를 선택하는 것이 가장 좋습니다. Nordic API는 끝점 이름 지정에 대한 유용한 팁 목록을 제공합니다.

상세한 성공 및 실패 대응 구조

개발자는 성공 및 실패 응답을 위해 친숙한 데이터 개체와 상태 코드를 원하고 기대합니다. 즉, 성공 시나리오의 경우 2xx 상태 코드, 클라이언트측 실패의 경우 4xx 코드, 서버측 오류의 경우 5xx 코드입니다. 그러나 특이성이 핵심입니다. 추가 정보 없이 단순히 4xx 응답을 반환하는 "이메일 보내기" API를 호출하면 정확히 무엇이 잘못되었는지에 대한 추가 정보를 제공하지 않고 클라이언트 요청에 오류가 있다는 것만 확인하기 때문에 개발자 경험이 좋지 않습니다.

 { "status": 400, "message": "incorrect request" }

반대로 사람이 읽을 수 있는 형식과 고유한 오류 코드 형식으로 특정 세부 정보를 제공하는 응답은 개발자가 오류 시나리오를 수정하고 문제를 해결하기 위한 코드를 작성하고 API 호출을 재시도하는 방법을 신속하게 결정하는 데 도움이 될 수 있습니다.

 { "status": 400, "message": "To recipient not specified", "code": 21221 }

최적의 DX를 위해서는 상태를 전달하는 응답 구조와 키가 API 간에 일관되어야 합니다. 예를 들어, 위의 오류 코드 필드는 일부 API에서는 "코드"이고 다른 API에서는 "errorCode"가 아니라 모든 API에서 항상 "코드"로 참조되어야 합니다.

구성 가능한 속도 제한

속도 제한은 사용자가 단일 시간 단위로 API를 호출할 수 있는 횟수를 결정하여 API에 액세스할 수 있는 방법을 제어합니다. 속도 제한이 너무 높으면 관리할 수 없는 수의 요청으로 시스템에 넘쳐 성능이 저하될 수 있으며, 부당하게 낮은 속도 제한은 보류 중인 트랜잭션이 사용자 시스템의 대기열에 들어가게 할 수 있습니다. 둘 다 나쁜 DX에 기여합니다. API를 설계할 때 특정 비즈니스 사례 및 상황에 따라 조정할 수 있는 속도 제한을 허용하는 것이 가장 좋습니다. 예를 들어, 대량 고객은 API를 더 자주 호출해야 할 필요가 있습니다.

적절한 속도 제한을 가장 잘 결정하려면 먼저 API를 호출하는 빈도와 볼륨에 따라 의미 있는 범주로 API를 그룹화하는 것이 좋습니다. 예를 들어 기본 고객 데이터(프로필/계정 생성)를 구성하는 API는 덜 자주 호출되고 더 낮은 비율 제한을 처리할 수 있는 반면 트랜잭션 API("주문 생성", "이메일 보내기")는 더 자주 호출되어 더 높은 비율 제한이 필요합니다. 다양한 사용 사례에 대한 범주 또는 계층을 설정하면 API가 더 안정적이고 확장 가능합니다. 명확하게 정의된 속도 제한의 예는 Slack의 API 설명서를 참조하세요.

종합 문서

문서는 API의 사용자 매뉴얼 역할을 합니다. API가 무엇을 하는지, 어떻게 사용하는지, API에서 무엇을 기대할 수 있는지 개발자에게 명확하게 설명합니다. 좋은 문서는 명확하고 접근 가능한 언어로 작성되었으며 상세하고 대화형이며 통합을 더 간단하게 만드는 많은 데모와 코드 조각을 제공합니다. 이러한 방식으로 개발자가 첫 번째 API를 얼마나 신속하게 성공적으로 호출할 수 있는지를 나타내는 중요한 측정항목인 TTFHW(Time to First Hello World)가 쉽고 빠르게 시작됩니다.

문서는 API 요청에서 필수 필드와 선택 필드는 물론 해당 필드의 최소 및 최대 길이와 데이터 유형을 명확하게 식별해야 합니다. 기본적으로 개발자를 소비하는 데 필요한 기대치를 설정하고 장애물을 제거하는 데 필요한 모든 것이 포함되어야 합니다. 예를 들어, 시스템에서 데이터베이스 스키마를 생성하는 개발자는 문서에서 매개변수를 지정하지 않았기 때문에 나중에 테이블의 열 길이를 조정할 필요가 없습니다.

API 문서는 소비하는 개발자를 위한 신뢰할 수 있는 참조 역할을 할 뿐만 아니라 API 자체에 대한 마케팅 도구 역할을 함으로써 채택을 늘릴 수 있습니다. API 문서를 가장 먼저 접하는 사람은 종종 제품 평가의 초기 단계에서 API 문서를 탐색하는 비즈니스 관련 이해 관계자입니다. 따라서 API의 기술 요소에 대한 세부 정보를 포함해야 할 뿐만 아니라 API가 가능하게 하는 비즈니스 사용 사례도 명확하게 설명해야 합니다.

포괄적인 API 문서를 생성하는 데 도움이 될 수 있는 여러 도구가 시중에 나와 있습니다. Stripe와 같은 고품질 문서의 예를 검토하는 것도 도움이 됩니다.

모든 것을 하나로 모으기

통합은 많은 구성 요소가 포함된 광대한 영역을 나타내지만 우수한 API의 핵심 원칙을 이해하는 것은 견고한 전략을 개발하는 데 기본입니다. API는 단순한 시스템 커넥터 그 이상입니다. 이는 광범위한 디지털 네트워크의 빌딩 블록이자 새로운 수익원을 열고 미개척 가치를 창출하는 열쇠입니다. 이 때문에 성공적인 API 전략은 단순히 제품을 구축하는 것이 아닙니다. 잠재력을 키우는 것입니다. API 제품 관리자는 플랫폼 사고방식을 채택하고 API를 사용하여 통합하고 실행할 수 있는 잠재적 파트너를 원활하게 채택할 요소의 우선 순위를 지정해야 합니다.