본문으로 건너뛰기
Didit, 신원·사기 방지 인프라 구축 위해 750만 달러 투자 유치
Didit
블로그로 돌아가기
블로그 · 2026년 3월 7일

레거시 본인 인증 시스템, Strangler Fig 패턴과 Didit으로 현대화하기 (KO)

오래된 본인 인증 시스템을 현대화하는 일은 쉽지 않습니다. 이 게시물에서는 Java/Spring Boot에서 Strangler Fig 패턴을 사용하여 Didit의 고급 API로 점진적으로 마이그레이션하여 위험을 최소화하고 원활한 전환을 보장하는 방법을 설명합니다.

작성자: Didit업데이트됨
migrating-legacy-identity-verification-with-strangler-fig-didit.png

점진적 마이그레이션 전략Strangler Fig 패턴은 새로운 기능을 기존 시스템과 함께 구축하여 레거시 구성 요소를 점진적으로 교체함으로써, 중단적인 전면 재작성 없이 단계별 마이그레이션을 가능하게 합니다.

위험 및 다운타임 최소화새로운 기능을 분리하고 트래픽을 선택적으로 라우팅함으로써, 조직은 시스템 장애 위험을 줄이고 전환 기간 동안 지속적인 서비스 가용성을 유지할 수 있습니다.

최신 API 활용Didit의 API와 통합하면 AI 기반의 본인 인증 기능을 사용할 수 있어, 기존 시스템에 비해 뛰어난 사기 탐지, 규정 준수 및 사용자 경험을 제공합니다.

Didit의 모듈식 및 개발자 우선 접근 방식Didit 플랫폼은 Free Core KYC를 포함한 모듈식 API 중심 아키텍처를 제공하여, 점진적인 도입과 기존 Spring Boot 애플리케이션으로의 원활한 통합에 이상적입니다.

레거시 본인 인증 시스템의 과제

많은 조직이 유지보수가 어렵고, 확장 비용이 많이 들며, 최신 솔루션의 고급 사기 탐지 기능이 부족한 레거시 본인 인증(IDV) 시스템에 의존하고 있습니다. 전면적인 개편에 대한 생각은 마비될 수 있으며, 이는 정체와 위험 증가로 이어집니다. 이러한 오래된 시스템은 새로운 규정 준수 요구 사항에 어려움을 겪거나, 열악한 사용자 경험을 제공하거나, 정교한 딥페이크 및 합성 신분 사기를 탐지하지 못할 수 있습니다. 시스템 전체를 한 번에 교체하는 전통적인 "빅뱅" 마이그레이션은 위험, 잠재적인 다운타임 및 상당한 개발 비용으로 가득 차 있습니다. 이러한 상황에서 보다 전략적이고 점진적인 접근 방식이 매우 중요합니다.

IDV 마이그레이션을 위한 Strangler Fig 패턴 소개

마틴 파울러가 유명하게 명명한 Strangler Fig 패턴은 레거시 시스템 주변에 새로운 기능을 구축하여 점진적으로 마이그레이션하고, 결국에는 기존 시스템을 "조여" 은퇴시킬 수 있는 우아한 솔루션을 제공합니다. 본인 인증의 경우, 이는 특정 IDV 기능을 Didit과 같은 최신 API 호출로 대체하는 것을 의미하며, 나머지 레거시 애플리케이션은 처음에는 그대로 유지됩니다. 이 패턴은 Java/Spring Boot 애플리케이션에 특히 적합하여 개발자가 새로운 서비스 및 API 호출을 점진적으로 도입할 수 있도록 합니다.

핵심 아이디어는 레거시 시스템 앞에 파사드 또는 API 게이트웨이를 배치하는 것입니다. 새로운 요청은 이 게이트웨이를 통해 라우팅되며, 이 게이트웨이는 새 시스템(Didit)을 사용하여 처리할지 아니면 레거시 시스템으로 전달할지 결정합니다. 시간이 지남에 따라 점점 더 많은 기능이 새 시스템으로 마이그레이션되고, 레거시 구성 요소는 서서히 해체됩니다. 이 접근 방식은 위험을 최소화하고, 지속적인 배포를 가능하게 하며, 새 시스템의 기능에서 즉각적인 가치를 제공합니다.

Spring Boot 및 Didit으로 Strangler Fig 구현

Spring Boot 애플리케이션의 실제 시나리오를 살펴보겠습니다. ID 문서 처리 및 라이브니스 검사를 담당하는 레거시 서비스가 있다고 가정해 봅시다. 이를 Didit의 고급 ID 검증 및 수동 및 능동 라이브니스 기능으로 대체하려고 합니다. 새로운 Spring Boot 서비스를 도입하거나 기존 서비스 내에 "스트랭글러" 역할을 하는 구성 요소를 도입할 수 있습니다.

1단계: 프록시/파사드 계층 생성

본인 인증을 위한 호출을 가로채는 새로운 Spring 구성 요소를 개발합니다. 이 구성 요소는 레거시 시스템을 사용할지 Didit을 사용할지 결정하는 로직을 포함합니다. 예를 들어, 새 사용자 등록만 마이그레이션하는 경우 해당 등록은 Didit으로 라우팅할 수 있으며, 기존 사용자 재확인은 처음에는 레거시 시스템을 통해 계속 진행될 수 있습니다.


@Service
public class IdentityVerificationGateway {

    private final DiditApiClient diditApiClient;
    private final LegacyIdvService legacyIdvService;

    public IdentityVerificationGateway(DiditApiClient diditApiClient, LegacyIdvService legacyIdvService) {
        this.diditApiClient = diditApiClient;
        this.legacyIdvService = legacyIdvService;
    }

    public VerificationResult verifyIdentity(User user) {
        // Didit 또는 레거시 사용 여부를 결정하는 로직
        if (user.isNewUser() || featureFlags.isDiditEnabledFor(user.getRegion())) {
            // ID 검증 및 라이브니스를 위해 Didit API 호출
            return diditApiClient.performVerification(user);
        } else {
            // 레거시 시스템으로 대체
            return legacyIdvService.performVerification(user);
        }
    }
}

2단계: Didit API 통합

DiditApiClient 내에서 Didit의 강력한 API 엔드포인트로 호출합니다. Didit의 모듈식 아키텍처는 필요한 정확한 ID 기본 요소를 선택하고 선택할 수 있음을 의미합니다. 예를 들어, ID 검증 및 라이브니스를 수행하려면 일반적으로 세션을 시작한 다음 결과를 처리합니다. Didit의 API는 진정으로 개발자 우선이며, 깨끗한 API와 빠른 통합을 위한 즉각적인 샌드박스를 제공합니다.


@Service
public class DiditApiClient {

    private final RestTemplate restTemplate;
    private final String diditApiKey;
    private final String diditApiUrl;

    public DiditApiClient(@Value("${didit.api.key}") String diditApiKey,
                          @Value("${didit.api.url}") String diditApiUrl) {
        this.restTemplate = new RestTemplate();
        this.diditApiKey = diditApiKey;
        this.diditApiUrl = diditApiUrl;
    }

    public VerificationResult performVerification(User user) {
        HttpHeaders headers = new HttpHeaders();
        headers.set("x-api-key", diditApiKey);
        headers.setContentType(MediaType.APPLICATION_JSON);

        // 예시: ID 검증 및 라이브니스를 위한 세션 생성
        // workflow_id는 원하는 검사 시퀀스를 위해 Didit의 Business Console에 구성됩니다.
        String workflowId = "your-didit-workflow-id"; 
        Map<String, String> requestBody = Map.of("workflow_id", workflowId, "vendor_data", user.getUserId());

        HttpEntity<Map<String, String>> request = new HttpEntity<>(requestBody, headers);

        ResponseEntity<DiditSessionResponse> response = restTemplate.postForEntity(
            diditApiUrl + "/v3/session/", request, DiditSessionResponse.class);

        // 세션 URL 처리, 사용자 리디렉션, 결과를 위한 웹훅 처리
        // 이 간소화된 예시는 간결성을 위해 동기식 결과를 가정합니다.
        return new VerificationResult(response.getBody().getSessionId(), "PENDING");
    }
}

Didit은 ID 검증, 수동 및 능동 라이브니스, 1:1 얼굴 매치, AML 스크리닝, 주소 증명과 같은 요소를 결합하여 복잡한 오케스트레이션 워크플로를 설계하기 위한 코드 없는 비즈니스 콘솔도 제공한다는 점을 기억하십시오. 이를 통해 검증 여정을 한 번 정의한 다음 간단한 API 호출을 통해 트리거하여 Spring Boot 통합을 간소화할 수 있습니다.

3단계: 점진적인 트래픽 전환 및 모니터링

Didit 통합이 완료되면 트래픽을 점진적으로 전환할 수 있습니다. 소수의 사용자부터 시작하거나, A/B 테스트를 수행하거나, 특정 코호트에 대해 활성화하십시오. 성능, 사용자 경험 및 검증 정확도를 면밀히 모니터링하십시오. Didit의 포괄적인 분석 및 웹훅 기능은 이 모니터링 프로세스를 효율적으로 만들어 사용자가 검증을 진행함에 따라 실시간 업데이트를 제공합니다. 신뢰가 쌓이면 Didit으로 라우팅되는 트래픽을 늘리고, 결국 레거시 구성 요소를 완전히 해체할 수 있습니다.

Didit이 도움이 되는 방법

Didit은 Strangler Fig 패턴을 사용하여 원활한 마이그레이션을 촉진하는 데 독보적인 위치를 차지하고 있습니다. 당사의 AI 기반, 개발자 우선 ID 플랫폼은 고급 ID 검증 기능을 쉽게 통합할 수 있도록 모듈식 아키텍처를 제공합니다. Didit을 통해 강력한 도구 모음에 액세스할 수 있습니다.

  • ID 검증(OCR, MRZ, 바코드): 전 세계적으로 ID 문서에서 데이터를 정확하게 추출합니다.
  • 수동 및 능동 라이브니스: 고급 생체 인식 라이브니스 감지로 딥페이크 및 프레젠테이션 공격에 대응합니다.
  • 1:1 얼굴 매치: ID를 제시하는 사람이 정당한 소유자인지 확인합니다.
  • AML 스크리닝 및 모니터링: 제재 및 PEP 목록에 대해 스크리닝하여 글로벌 규정을 준수합니다.
  • 주소 증명: 주거 주소를 효율적으로 확인합니다.
  • 연령 추정(프라이버시 보호): 프라이버시를 침해하지 않고 연령 제한 산업의 규정 준수를 위해.
  • 전화 및 이메일 검증: 계정 보안을 강화하고 사기를 방지합니다.

Didit의 장점은 분명합니다. 시작하는 데 도움이 되는 무료 핵심 KYC, 필요한 것만 통합할 수 있는 진정한 모듈식 아키텍처, 최첨단 정확성과 사기 방지를 제공하는 AI 기반 접근 방식을 제공합니다. 당사의 플랫폼은 설정 비용이 없으며, 개발자 우선 정신은 Strangler Fig 패턴의 점진적인 특성과 완벽하게 일치하는 빠르고 쉬운 통합을 위한 깨끗한 API와 광범위한 문서를 보장합니다.

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

Didit의 작동 방식을 보고 싶으십니까? 지금 무료 데모를 받으십시오.

Didit의 무료 티어로 무료로 ID를 확인하십시오.

신원 및 사기 방지 인프라.

KYC, KYB, 거래 모니터링, 지갑 심사를 위한 단일 API. 5분 만에 통합하세요.

AI에게 이 페이지 요약 요청
Strangler Fig 패턴과 Didit을 활용한 본인 인증 마이그레이션.