신원 확인 마이크로서비스를 위한 gRPC 기반 고급 API 버전 관리 (KO)

gRPC를 통한 스키마 진화gRPC의 프로토콜 버퍼는 강력한 스키마 진화 기능을 제공하여 기존 클라이언트를 손상시키지 않고 추가적인 변경을 가능하게 하며, 이는 신원 확인 마이크로서비스에서 호환성을 유지하는 데 필수적입니다.

URL을 넘어선 버전 관리 전략URL 버전 관리가 일반적이지만 유일한 방법은 아닙니다. 헤더 버전 관리와 콘텐츠 협상은 특히 마이크로서비스 아키텍처에서 API 변경 사항을 관리하는 데 더 유연하고 덜 침해적인 접근 방식을 제공합니다.

하위 및 상위 호환성 유지프로토버프 메시지 내 버전 관리 및 기능 플래그 사용과 같은 전략을 구현하는 것은 이전 클라이언트가 최신 서비스와 상호 작용할 수 있도록 하고, 새 서비스가 이전 클라이언트의 요청을 원활하게 처리할 수 있도록 보장하는 데 필수적입니다.

Didit의 모듈식 및 API 우선 접근 방식Didit은 AI 기반의 개발자 우선 플랫폼으로, 깔끔한 API, 즉각적인 샌드박스, 모듈식 아키텍처를 통해 API 버전 관리 문제를 간소화하여 신원 확인 서비스의 원활한 통합 및 진화를 보장합니다.

신원 확인 마이크로서비스에서 API 버전 관리의 중요성

급변하는 디지털 신원 환경에서 마이크로서비스는 확장 가능하고 탄력적이며 독립적으로 배포 가능한 시스템을 구축하기 위한 아키텍처의 중추가 되었습니다. 많은 온라인 서비스의 핵심 구성 요소인 신원 확인은 종종 신분증 확인(OCR, MRZ, 바코드), 수동 및 능동 생체 인식 검사, 1:1 얼굴 매칭, AML 심사와 같은 작업을 처리하는 일련의 전문 마이크로서비스에 의존합니다. 이러한 서비스가 성숙하고 요구 사항이 변경됨에 따라 기본 API도 진화해야 합니다. 그러나 이러한 진화는 중요한 과제를 제시합니다. 즉, 서비스에 의존하는 클라이언트 애플리케이션을 방해하지 않고 새로운 기능을 도입하거나 기존 기능을 수정하는 방법은 무엇일까요? 바로 이 지점에서 특히 gRPC를 활용할 때 고급 API 버전 관리 전략이 중요해집니다.

일관된 버전 관리 전략이 없으면 사소한 변경 사항이라도 마이크로서비스 및 클라이언트 애플리케이션 생태계 전반에 걸쳐 연쇄적인 장애를 초래할 수 있습니다. 신뢰와 지속적인 운영이 가장 중요한 신원 플랫폼의 경우 이러한 중단은 용납될 수 없습니다. 잘 구현된 버전 관리 전략은 하위 호환성을 보장하여 이전 클라이언트가 계속 작동할 수 있도록 하는 동시에 최신 클라이언트는 최신 기능을 활용할 수 있도록 합니다. 또한 최신 서비스가 이전 클라이언트의 요청을 여전히 처리할 수 있는 상위 호환성을 촉진합니다.

gRPC 및 프로토콜 버퍼: 강력한 버전 관리의 기반

고성능 오픈 소스 범용 RPC 프레임워크인 gRPC는 프로토콜 버퍼(protobuf)를 IDL(Interface Definition Language) 및 기본 메시지 교환 형식으로 사용합니다. 이 조합은 JSON을 사용하는 기존 RESTful API에 비해 API 버전 관리에 내재된 이점을 제공합니다. 프로토버프의 스키마 진화 기능은 효과적인 gRPC 버전 관리의 초석입니다.

• 추가 변경: 이전 클라이언트를 손상시키지 않고 프로토버프 메시지에 새 필드를 추가할 수 있습니다. 이전 클라이언트는 새 필드를 단순히 무시합니다.
• 필드 제거: 기술적으로는 가능하지만, 필드를 제거하는 것은 해당 필드를 기대하는 이전 클라이언트를 손상시킬 수 있으므로 극도로 주의해야 합니다. 더 나은 방법은 필드를 '사용 중단'으로 먼저 표시하는 것입니다.
• 필드 이름 변경: 필드 이름을 변경하는 것은 호환성을 깨뜨리는 변경입니다. 대신 새 이름으로 새 필드를 추가하고 이전 필드는 사용 중단으로 표시한 다음 클라이언트를 점진적으로 업데이트합니다.
• Enum 진화: enum에 새 값을 추가하는 것은 일반적으로 안전하지만, 기존 값을 변경하거나 제거하면 문제가 발생할 수 있습니다.

AI 기반의 개발자 우선 신원 플랫폼인 Didit은 이러한 기능을 적극적으로 활용합니다. Didit의 모듈식 아키텍처와 깔끔한 API는 스키마 진화를 염두에 두고 설계되어, 사용자에게 파괴적인 업데이트를 강요하지 않고 신원 확인 및 연령 추정과 같은 분야에서 지속적인 혁신을 가능하게 합니다. 이를 통해 Didit의 인프라를 기반으로 구축하는 개발자는 원활한 통합 및 업데이트를 경험할 수 있습니다.

일반적인 API 버전 관리 전략 및 gRPC 적용

gRPC의 프로토버프는 뛰어난 스키마 진화를 제공하지만, 서비스 수준에서 API 버전을 관리하기 위한 포괄적인 전략이 여전히 필요합니다. 다음은 일반적인 접근 방식과 gRPC에 적용되는 방법입니다.

1. URL 경로 버전 관리 (예: /v1/service, /v2/service)

이것은 아마도 가장 간단한 접근 방식일 것입니다. 각 주요 호환성 파괴 변경은 새로운 URL 경로 세그먼트를 초래합니다. gRPC의 경우 이는 각 주요 버전에 대해 별도의 .proto 파일(또는 .proto 파일 내의 패키지)을 정의하는 것을 의미합니다. 예를 들어, com/didit/identity/v1/user.proto 및 com/didit/identity/v2/user.proto를 가질 수 있습니다. 이는 버전을 명확하게 구분하고 서비스가 여러 버전을 동시에 실행할 수 있도록 합니다. 그러나 신중하게 관리하지 않으면 코드 중복 및 유지 보수 증가로 이어질 수 있습니다.

2. 헤더 버전 관리 (예: X-API-Version: 1)

헤더 버전 관리를 사용하면 클라이언트가 사용자 지정 HTTP 헤더에 원하는 API 버전을 지정합니다. 일반적으로 HTTP/2에서 실행되는 gRPC는 사용자 지정 메타데이터 헤더를 검사하여 이를 지원할 수도 있습니다. 이 접근 방식은 URL을 더 깔끔하게 유지하지만 클라이언트가 헤더를 명시적으로 설정해야 합니다. 그러면 서버는 이 헤더를 사용하여 요청을 적절한 버전의 서비스 구현으로 라우팅합니다. 이는 버전을 엔드포인트 자체에 하드코딩하지 않으므로 URL 버전 관리보다 더 유연한 경우가 많습니다.

3. 콘텐츠 협상 버전 관리 (예: Accept: application/vnd.didit.v1+json)

이 방법은 HTTP Accept 헤더를 사용하여 원하는 미디어 유형 및 버전을 나타냅니다. REST에서 더 일반적이지만 gRPC는 사용자 지정 프로토버프 미디어 유형을 정의하거나(덜 일반적이지만) 사용자 지정 메타데이터를 사용하여 유사한 효과를 얻음으로써 이를 적용할 수 있습니다. 이 전략은 클라이언트가 버전에 따라 특정 데이터 표현을 요청할 수 있도록 하여 페이로드 구조에 대한 더 세밀한 제어를 제공합니다.

4. 프로토버프 메시지 내 버전 관리

이는 gRPC에 특화된 접근 방식이며 사소한 비호환성 파괴 변경에 적극 권장됩니다. 모든 작은 변경에 대해 완전히 새로운 프로토버프 서비스를 생성하는 대신 개별 메시지를 버전 관리할 수 있습니다. 예를 들어, User 메시지에 선택적 version 필드가 포함될 수 있거나 UserV1 및 UserV2 메시지를 가질 수 있으므로 단일 RPC 엔드포인트가 클라이언트의 기능에 따라 다른 메시지 버전을 처리할 수 있습니다. 이는 Didit의 신분증 확인 및 AML 심사 서비스에 특히 유용하며, 전체 API 버전 범프 없이도 시간이 지남에 따라 새로운 데이터 필드가 추가될 수 있습니다.

호환성 파괴 변경 관리 및 호환성 보장 전략

gRPC의 장점에도 불구하고 호환성 파괴 변경은 때때로 불가피합니다. 다음은 이를 관리하는 방법입니다.

• 사용 중단 정책: 명확한 사용 중단 정책을 수립합니다. 필드 또는 메서드가 더 이상 지원되지 않으면 .proto 파일에서 (deprecated = true)로 표시합니다. 이를 클라이언트에게 명확하게 전달하고 마이그레이션 경로를 제공합니다. Didit의 개발자 우선 접근 방식에 대한 약속은 이러한 전환에 대한 투명한 커뮤니케이션과 충분한 지원을 의미합니다.
• 유예 기간: 이전 버전과 새 버전이 동시에 실행되는 충분한 유예 기간을 제공합니다. 이를 통해 클라이언트는 마이그레이션할 충분한 시간을 확보할 수 있습니다.
• 기능 플래그: 마이크로서비스 내에서 기능 플래그를 사용하여 새로운 로직 또는 데이터 구조를 조건부로 활성화합니다. 이를 통해 호환성 파괴 변경을 즉시 노출하지 않고 새 코드를 배포할 수 있으며, 롤백 메커니즘을 제공합니다.
• 하위 호환성 계층: 중요한 호환성 파괴 변경의 경우, 이전 클라이언트의 요청을 새 API 형식으로 변환하는 호환성 계층 또는 어댑터를 구현하는 것을 고려합니다.
• 클라이언트 라이브러리: 다양한 버전에 대해 잘 관리된 클라이언트 라이브러리를 제공합니다. 이를 통해 개발자의 사용이 간소화되고 Didit이 업데이트를 효율적으로 푸시할 수 있습니다.

이러한 전략을 신중하게 계획하고 구현함으로써 조직은 신원 확인 마이크로서비스가 민첩하고 견고하게 유지되어 안정성이나 클라이언트 경험을 희생하지 않고 미래 요구 사항에 적응할 수 있도록 보장할 수 있습니다.

Didit이 도움이 되는 방법

AI 기반의 개발자 우선 신원 플랫폼인 Didit은 API 버전 관리 및 마이크로서비스 진화의 복잡성을 해결하기 위해 처음부터 구축되었습니다. Didit의 모듈식 아키텍처와 깔끔한 API는 원활한 통합과 미래 보장을 위해 설계되었습니다. 다음과 같은 서비스를 제공합니다.

• 무료 핵심 KYC: Didit이 신원 확인의 복잡성을 처리하는 동안 핵심 비즈니스에 집중할 수 있도록 선불 비용 없이 필수 신원 확인 기능을 시작하세요.
• AI 기반 디자인: Didit의 플랫폼은 신분증 확인(OCR, MRZ), 수동 및 능동 생체 인식, 1:1 얼굴 매치와 같이 지속적으로 진화하는 고급 기능을 본질적으로 지원합니다. Didit의 API 디자인은 강력한 스키마 진화 및 명확한 버전 관리 관행을 통해 이러한 변경 사항을 예측하고 수용합니다.
• 개발자 우선 접근 방식: 즉각적인 샌드박스와 포괄적인 공개 문서를 통해 개발자는 Didit의 서비스를 신속하게 이해하고 통합할 수 있으며, 다양한 API 버전과 상호 작용하는 방법을 알 수 있습니다. Didit의 API는 명확성을 위해 설계되어 필요한 업데이트의 영향을 최소화합니다.
• 오케스트레이션된 워크플로우: Didit의 KYC용 노코드 엔진을 사용하면 복잡한 확인 흐름을 구축하고 관리할 수 있습니다. 이 오케스트레이션 계층은 기본 마이크로서비스 버전 관리의 대부분을 추상화하여 비즈니스 로직에 통합된 인터페이스를 제공합니다.
• 설치비 없음: Didit의 투명한 가격 모델은 성공적인 확인에 대해서만 비용을 지불한다는 것을 의미하며, 내부적으로 버전 관리 문제를 처리하는 최첨단 신원 솔루션을 채택하는 데 있어 재정적 장벽을 제거합니다.

개방적이고 모듈식 신원 계층에 대한 Didit의 약속은 호환성을 유지하고 새로운 기능 채택을 위한 명확한 경로를 제공하는 데 항상 초점을 맞춰 API 및 서비스를 지속적으로 개선하고 있음을 의미합니다. 신분증 확인, 연령 추정 또는 AML 심사를 통합하든 Didit은 원활하고 확장 가능한 여정을 보장합니다.

시작할 준비가 되셨습니까?

Didit이 작동하는 모습을 보실 준비가 되셨습니까? 지금 무료 데모를 받아보세요.

Didit의 무료 티어로 무료로 신원 확인을 시작하세요.