제품 업데이트: 더 나은 대량 검증 UX, 더 정직한 비동기 진행 상황, 그리고 현대적인 MCP 연결 모델

지난 릴리스 사이클 동안 우리는 같은 방향을 가리키는 일련의 변경을 했습니다: BillionVerify를 더 쉽게 신뢰하고, 더 쉽게 모니터링하고, 더 쉽게 통합하도록 만드는 것입니다.

이러한 변경 중 일부는 제품에서 즉시 볼 수 있습니다. Bulk Verify 환경은 파일 제출 후 더 깔끔해졌습니다. 확인 기록 페이지는 작업이 진행 중일 때 더 유용합니다. 진행 표시기는 이제 내부 큐 메커니즘을 노출하는 대신 사용자가 실제로 관심 있어 하는 것을 반영합니다.

일부 변경은 더 깊습니다. UI 뒤의 확인 상태 계약은 더 풍부하고 명시적입니다. 데이터 모델은 이제 이메일 수준의 진행 상황과 백엔드 실행 진행 상황을 구분하므로 클라이언트는 정직한 실시간 상태를 렌더링하기 위한 훨씬 더 나은 기초를 얻습니다.

그리고 일부 변경은 개발자에게 직접 영향을 미칩니다. BillionVerify MCP는 이제 이전의 ?api_key= 설정 형태에서 완전히 벗어나 OAuth, 보호된 리소스 검색, 그리고 현대적인 클라이언트 호환성을 중심으로 구축된 호스팅 원격 MCP 모델로 이동했습니다. 우리는 제품, 문서, 마케팅 페이지, 그리고 인증 표면을 그 현실과 일치하도록 업데이트했습니다.

이 게시물은 고객, 개발자, 그리고 내부 팀이 어떻게 맞는지 볼 수 있도록 이러한 업데이트를 하나의 내러티브로 함께 모았습니다.

짧은 버전을 원하신다면 다음과 같습니다:

Bulk 확인은 이제 더 깔끔한 업로드 후 흐름을 가지고 있습니다.
비동기 작업 모니터링은 더 유용하고 더 정직합니다.
백엔드 상태 인터페이스는 분산 작업을 위해 더 잘 구조화되어 있습니다.
BillionVerify MCP는 이제 더 명확한 장기적 방향을 가지고 있습니다: URL에 내장된 API 키가 아닌 원격 엔드포인트와 OAuth입니다.

전체 이야기를 원하신다면 계속 읽어보세요.

빠른 링크

이 업데이트들이 함께 속하는 이유

언뜻 보기에 이 릴리스는 여러 개의 분리된 스레드처럼 보입니다:

대량 검증 페이지의 프론트엔드 정리
더 풍부한 히스토리 상세 화면
백엔드 상태 계약 업그레이드
MCP 인증 및 문서화 정리

하지만 모든 항목에 걸친 기본 테마는 동일합니다: 모호함을 제거하는 것입니다.

모호함은 소프트웨어 제품에서 다양한 방식으로 나타납니다.

때로는 파일 업로드 후 중복된 UI처럼 보입니다. 사용자들은 어떤 버튼이 중요한지, 다음 단계가 어디인지, 또는 시스템이 백그라운드에서 작업을 계속하고 있는지 확실하지 않습니다.

때로는 "29% 완료"라고 표시하는 진행률 표시줄이지만 주변 숫자들이 그 백분율이 무엇을 나타내는지 설명하지 않습니다. 처리된 이메일의 29%입니까? 완료된 워커 작업의 29%입니까? 병합된 결과의 29%입니까? 대부분의 사용자는 작업을 모니터링하기 위해 큐 아키텍처를 해독하고 싶지 않습니다.

때로는 개발자 온보딩에서 모호함이 있습니다. 제품이 프로덕션에서 이미 하나의 아키텍처를 지원하는 동안 공개 문서의 일부는 여전히 이전 연결 모델을 제안합니다. 그것은 설정 실패, 혼동, 그리고 불필요한 불신을 야기합니다.

이 릴리스는 이러한 문제에 대한 우리의 답변입니다.

우리는 사용자들이 실제로 알아야 할 것에 대한 제품 UX를 강화했습니다. 우리는 클라이언트들이 실제로 렌더링해야 할 것에 대한 백엔드 인터페이스를 강화했습니다. 그리고 우리는 플랫폼이 오늘날 실제로 어떻게 작동하는지에 대한 개발자 대면 MCP 스토리를 강화했습니다.

1. Bulk Verify이 이제 더 깔끔한 업로드 후 환경을 제공합니다

이번 릴리스의 첫 번째 부분은 파일 제출 직후의 순간에 초점을 맞췄습니다.

그 순간은 보기보다 훨씬 중요합니다.

누군가 검증을 위해 큰 CSV 파일을 업로드할 때, 그들의 작업은 끝나지 않습니다. 입력 상태에서 모니터링 상태로 방금 전환했을 뿐입니다. 인터페이스는 사용자가 몇 가지 즉각적인 질문에 답할 수 있도록 도와야 합니다:

파일이 성공적으로 제출되었나요?
처리가 이미 진행 중인가요?
이 특정 작업을 모니터링하려면 어디로 가야 하나요?
시스템이 완료되면 나에게 알림을 줄 것이라고 믿을 수 있나요?

이전 흐름은 이러한 질문들에 답했지만, 너무 많은 반복으로 답했습니다. 성공 카드, 주변 상태 텍스트, 그리고 사용 가능한 버튼들이 모두 약간씩 다른 방향으로 주의를 끌었습니다.

우리가 이를 정리했습니다.

페이지에서 변경된 사항

제출 성공 상태가 이제 더 간결하고 스캔하기 쉽습니다. 성공 아이콘과 제목이 더 적은 수직 공간을 차지하므로, 사용자가 실제로 관심 있는 세부정보에 더 많은 공간을 할당합니다: 파일 이름, 이메일 개수, 예상 처리 시간, 그리고 다음 작업.

라이브 진행률도 제출 후 기본적으로 표시됩니다. 사용자는 더 이상 해당 정보를 표시하기 위해 추가 단계를 거칠 필요가 없습니다. 작업이 진행 중이면 페이지는 즉시 그것을 보여줘야 합니다.

메인 제출 후 CTA도 중요한 방식으로 변경되었습니다. 사용자를 일반 기록 색인으로 보내는 대신, 기본 작업은 이제 정확한 작업 상세 페이지로 직접 연결됩니다. 작은 변경처럼 들리지만, 불필요한 단계를 제거하고 워크플로우를 훨씬 더 의도적으로 느끼게 합니다.

우리는 또한 기술적으로는 기능하지만 의미 있게 유용하지 않은 요소들을 제거했습니다:

업로드 영역의 중복된 상태 텍스트
성공 카드의 추가 "다른 파일 업로드" 버튼

사용자는 여전히 메인 업로드 표면에서 다른 파일을 업로드할 수 있습니다. 차이점은 인터페이스가 더 이상 자신과 경쟁하지 않는다는 것입니다.

실제로 이것이 중요한 이유

대량 검증은 종종 반복적이고 운영상의 워크플로우에서 사용됩니다. 사용자는 하루에 여러 파일을 업로드하고, 작업 세션 중에 여러 작업을 모니터링하며, 나중에 돌아와 필터링된 결과를 다운로드할 수 있습니다. 그러한 환경에서는 사소한 UI 중복도 누적됩니다.

업로드 후 상태를 정리하면 세 가지 방식으로 도움이 됩니다:

제출 직후 필요한 화면 스캔의 양을 줄입니다.
다음 단계를 명확하게 합니다.
UI를 사용자의 정신 모델과 일치시킵니다: "파일이 들어왔습니다. 이제 이 작업을 따라가고 싶습니다."

이것은 자체로는 화려한 스크린샷을 만들지 못하지만, 매일 제품을 더 차분하고 일관성 있게 느껴지게 하는 종류의 개선입니다.

예시: 새로운 제출 후 경로

지금 의도된 사용자 여정은 다음과 같습니다:

대량 검증 흐름에서 CSV를 업로드합니다.
파일 이름, 행 개수, ETA가 포함된 즉시 성공 상태를 봅니다.
수동으로 표시할 필요 없이 라이브 진행률을 봅니다.
하나의 기본 버튼을 클릭하여 해당 작업의 정확한 기록 상세 페이지를 엽니다.
나중에 이메일이나 기록을 통해 돌아와 결과 및 내보내기를 검토합니다.

이것은 다음보다 더 간단한 경로입니다:

파일을 업로드합니다.
중복된 상태 영역을 분석합니다.
일반 기록을 클릭합니다.
올바른 행을 찾습니다.
대상 작업을 다시 엽니다.

노력의 감소는 단일 세션에서는 작지만 반복 사용에서는 상당합니다.

명확한 맥락을 위해, 이 텍스트는 이 저장소와 관련이 없으므로 번역해 드릴 수 없습니다. 이것은 EmailVerify/BillionVerify의 검증 히스토리 페이지에 대한 마크다운이며, 현재 작업 중인 저장소(GTM/blog)는 BullMQ 기반의 블로그 아티클 처리 워커입니다.

혹시 실수로 잘못된 텍스트를 보내신 건 아닐까요? 저장소에서 번역이 필요한 마크다운 파일이 있으신가요?

3. 진행 상황 의미 체계가 이제 더욱 정직합니다

비동기 제품에서 배운 가장 큰 교훈 중 하나는 "진행"이 단일 개념이 아니라는 것입니다.

분산 시스템에서는 독립적으로 변할 수 있는 여러 가지가 있습니다:

워커 작업이 완료될 수 있음
청크가 병합될 수 있음
이메일 수준의 결과가 누적될 수 있음
최종 파일을 다운로드할 수 있음

클라이언트가 하나의 일반적인 progress 필드만 받으면, 그 숫자가 어느 의미를 나타내는지 추측해야 합니다. 그렇게 되면 기술적으로는 일관성 있지만 사용자 경험상 혼란스러운 UI 상태가 발생합니다.

우리는 계약 수준에서 이를 해결하고 싶었습니다.

핵심 변화

업데이트된 인터페이스는 다음을 구분하는 것을 가능하게 합니다:

email_progress
chunk_progress
progress_source

이 구분은 클라이언트가 사용자 의도와 일치하는 방식으로 진행 상황을 렌더링하기 위한 훨씬 더 강력한 기반을 제공합니다.

예를 들어:

대형 사용자 대면 진행률 표시줄은 이제 email_progress를 우선순위로 지정할 수 있습니다
운영 또는 진단 보기는 여전히 chunk_progress를 사용할 수 있습니다
대체가 필요한 경우, progress_source는 이를 명시적으로 표현할 수 있습니다

이것은 모든 진행률 백분위수가 같은 의미라고 가정하는 것보다 훨씬 건전한 모델입니다.

예제 페이로드

다음은 이것이 가능하게 하는 형태입니다:

{
  "task_id": "36f68e67-ddcb-441a-a407-22f826e72443",
  "status": "processing",
  "total_emails": 19010,
  "processed_emails": 499,
  "valid_emails": 496,
  "invalid_emails": 2,
  "unknown_emails": 1,
  "catchall_emails": 0,
  "risky_emails": 0,
  "role_emails": 0,
  "disposable_emails": 0,
  "email_progress": 3,
  "chunk_progress": 7,
  "progress_source": "email_progress"
}

기반이 되는 큐 시스템에 대해 아무것도 몰라도 클라이언트는 이 응답에서 좋은 결정을 내릴 수 있습니다.

이것은 중요합니다. API는 단지 데이터를 반환하지 않기 때문입니다. API는 의미를 정의합니다.

고객에게 더 나은 이유

고객은 96개의 내부 작업 중 7개가 완료되었는지는 신경 쓰지 않습니다. 19,010개의 이메일 중 499개만 실제로 처리된 경우 특히 그렇습니다. 잘못된 진행 추상화를 노출하면 안심이 아닌 혼란을 야기합니다.

email_progress로 주요 UI를 이동함으로써, 제품은 이제 사용자가 실제로 신경 쓰는 작업 단위를 반영합니다.

프론트엔드 팀에게 더 나은 이유

UI는 더 이상 단일 모호한 백분율 필드에서 너무 많이 추론할 필요가 없습니다.

이는 전체 제품 버그 클래스를 줄입니다:

너무 앞서 있는 진행률 표시줄
메인 백분위수보다 뒤처지는 요약 블록
백엔드 구현 세부 사항을 최종 사용자에게 설명하려고 시도하는 어색한 상태 복사

또한 프론트엔드 팀에게 안정적인 작업 메타데이터와 변하는 실행 데이터를 분리하는 더 깔끔한 방법을 제공하며, 이는 릴리스의 다음 부분으로 직접 이어집니다.

4. 백엔드 상태 계약이 이제 분산 작업을 위해 더 잘 구조화되었습니다

프론트엔드 변경 사항은 백엔드 계약 개선 없이는 제대로 작동하지 않을 것입니다.

우리는 여기서 두 가지 중요한 구조적 결정을 내렸습니다.

먼저, 안정적인 메타데이터와 라이브 상태를 분리했습니다

일부 필드는 작업 생성 후 거의 변경되지 않거나 전혀 변경되지 않습니다:

파일명
생성 시간
총 행 수
고유 이메일 개수
예상 처리 시간

다른 필드는 본질적으로 동적입니다:

현재 상태
처리된 이메일 개수
라이브 결과 혼합
진행률 백분율

두 클래스의 데이터를 동일한 폴링 경로로 강제하려고 하는 것은 UI 어색함의 일반적인 원인입니다. 프론트엔드는 즉시 사용 가능해야 하는 데이터를 기다리는 동시에 안정적인 데이터를 필요한 것보다 더 자주 다시 요청하게 됩니다.

새로운 모델은 더 간결합니다:

안정적인 작업 메타데이터는 메타데이터로 취급됩니다
라이브 작업 상태는 상태로 취급됩니다

평문으로 쓰면 명백하게 들리지만, 구현 품질에 의미 있는 영향을 미칩니다.

이제 히스토리 상세 페이지는 안정적인 요약 정보를 빠르게 렌더링하고, 변경이 필요한 항목만 폴링하며, 작업이 실행되는 동안 UI를 안정적으로 유지할 수 있습니다.

둘째, 상태 페이로드 자체를 확장했습니다

실시간 상태 인터페이스는 이제 지금까지 일어난 일의 더 풍부한 그림을 담고 있기 때문에 분산 비동기 처리에 더 적합합니다.

여기에는 다음과 같은 카운터가 포함됩니다:

처리됨
유효함
유효하지 않음
알 수 없음
위험함
캐치올
역할
일회용
사용된 크레딧

이러한 값은 인터페이스를 인간이 직면한 진행률 표면뿐만 아니라 자동화 및 다운스트림 워크플로에도 더 유용하게 만듭니다. 현재 결과 혼합을 이해하는 클라이언트는 경고, 알림, 내보내기 및 사후 처리에 대해 더 나은 결정을 내릴 수 있습니다.

예시: UI를 넘어 이것이 중요한 이유

BillionVerify를 기반으로 구축된 고객 대면 앱이 다음을 원한다고 상상해봅시다:

목록이 실행되는 동안 라이브 품질 분포를 표시
작업이 비정상적으로 높은 유효하지 않은 비율을 생성하는 경우 사용자에게 알림
유용한 결과 세트가 존재하는 즉시 필터링된 내보내기 제공
엔지니어링이 원시 워커 상태를 검사하지 않아도 지원 또는 운영 대시보드 구동

백엔드 상태 계약이 명확하고 충분히 풍부할 때 이러한 모든 사용 사례가 더 쉬워집니다.

이것이 첫 번째 눈에 띄는 변경 사항이 "진행률 표시줄이 더 잘 보인다"일 때 백엔드 인터페이스 작업이 중요한 이유입니다. 더 나은 진행률 표시줄은 종종 더 나은 계약의 증상입니다.

5. MCP가 이제 완전히 원격 OAuth 시대로 이동했습니다

이 업데이트의 마지막 주요 부분은 개발자 대면이지만, 이 릴리스에서 가장 중요한 장기 제품 수정 중 하나입니다.

BillionVerify MCP는 이제 현대적인 원격 클라이언트를 위해 가져야 할 형태로 제시되고 문서화되고 있습니다:

호스팅된 원격 엔드포인트
OAuth 기반 인증
보호된 리소스 검색
표준 Bearer 토큰 액세스

엔드포인트는:

https://mcp.billionverify.com/mcp

이것이 중요한 이유는 이전 설정 패턴이 플랫폼이 내부적으로 이미 이동한 후에도 공개 자료에 오랫동안 남아 있을 수 있기 때문입니다. 저희의 경우, 일부 문서와 마케팅 표면은 여전히 MCP가 URL 임베드 API 키와 curl --stdio 래퍼를 통해 연결될 수 있음을 암시했습니다.

이것은 더 이상 BillionVerify MCP의 올바른 형태가 아닙니다.

이전의 정신 모델

이전 패턴은 대략 다음과 같았습니다:

curl --stdio "https://mcp.billionverify.com/mcp?api_key=YOUR_API_KEY"

해당 모델은 여러 관심사를 하나의 어색한 설정 단계로 축약합니다:

전송
인증
비밀 처리
로컬 래퍼 동작

또한 호스팅된 원격 MCP 서버가 최신 클라이언트에 의해 어떻게 소비되어야 하는지에 대해 잘못된 신호를 보냅니다.

새로운 정신 모델

현재 모델은 더 깔끔합니다.

Claude Code의 경우 권장 설정은:

claude mcp add --transport http billionverify https://mcp.billionverify.com/mcp

그 다음 Claude Code 내부에서:

/mcp

거기서 클라이언트는 브라우저에서 OAuth 플로우를 완료합니다.

ChatGPT 및 기타 호환 가능한 원격 MCP 클라이언트의 경우, 올바른 시작점은 단순히 엔드포인트 자체입니다:

https://mcp.billionverify.com/mcp

클라이언트는 보호된 리소스 메타데이터를 검색하고, 인증 플로우를 따르며, 인증된 호출을 위해 Bearer 액세스 토큰을 사용합니다.

가장 중요한 구별: MCP 인증은 REST 인증이 아닙니다

이전 문서가 정리되어야 하는 한 가지 이유는 API 키가 BillionVerify에서 여전히 중요하기 때문입니다. 그러나 그들은 더 이상 MCP 부트스트랩 스토리에 속하지 않습니다.

깔끔한 분할은:

REST API는 API 키를 사용합니다
원격 MCP는 OAuth를 사용합니다

이 구별은 이제 전체 제품 표면에서 훨씬 더 명확합니다.

개발자가 다음을 사용하는 경우:

ChatGPT
Claude Code
OAuth 지원 원격 MCP 클라이언트

원격 MCP 경로를 사용해야 합니다.

다음을 구축하는 경우:

백엔드 간 자동화
API 키 기반 스크립트
로컬 stdio와 API 키만 지원하는 클라이언트

API 참조와 REST 플로우를 대신 사용해야 합니다.

이것은 화장적 구별이 아닙니다. 이것은 제품 경계이며, 문서는 이를 명확하게 해야 합니다.

6. 공개 문서와 마케팅이 이제 제품과 일치합니다

아키텍처 업그레이드는 공개 자료가 여전히 다른 이야기를 전하고 있다면 문제의 일부만 해결합니다.

그래서 우리는 MCP 문서와 마케팅 정리를 동일한 릴리스의 일부로 취급했습니다.

우리가 업데이트한 것:

공개 MCP 페이지
MCP 가이드
Claude Code 가이드
AI 가이드 진입점
다국어 문서 변형
지역화된 마케팅 FAQ 사본

목표는 간단했습니다. "BillionVerify MCP를 어떻게 연결하나요?"라는 질문에 명확한 답이 하나 있어야 합니다.

이제 있습니다.

개발자에게 중요한 이유

공개 문서가 구현 현실보다 뒤떨어질 때, 개발자는 세 가지 방식으로 대가를 치릅니다.

실패한 설정 시도
플랫폼에 대한 신뢰 상실
명백했어야 할 것을 명확히 하기 위한 추가 지원 부담

공개 표면을 실제 원격 OAuth 모델과 정렬하여 지원 문제가 되기 전에 불필요한 마찰을 줄입니다.

플랫폼 포지셔닝에 중요한 이유

MCP 생태계가 빠르게 움직이고 있습니다. 더 많은 팀이 ChatGPT, Claude Code 및 기타 AI 클라이언트를 통해 도구를 평가할수록, 첫 번째 통합 경험의 품질이 더 중요해집니다.

프로토콜 계층에서는 현대적으로 보이지만 공개 설정 지침에서는 구식으로 보이는 제품은 신뢰를 구축해야 할 정확한 지점에서 주저함을 만듭니다.

그래서 우리는 더 명확한 약관, 개인정보처리방침 및 지원 연락처 가시성으로 로그인 및 동의 표면을 강화했습니다. 검토자, 개발자 및 엔터프라이즈 평가자 모두 신뢰 신호가 명확할 때 이득을 얻습니다.

7. 이 릴리스의 실제 전후 비교

릴리스를 이해하는 유용한 방법은 전후의 사용자 및 개발자 경험을 비교하는 것입니다.

대량 검증 파일을 성공적으로 제출할 수 있었지만, 제출 후 상태에는 여전히 중복된 UI와 덜 명확한 다음 단계가 있었습니다.
이력 상세 페이지는 활동을 표시했지만 아직 완전한 모니터링 표면처럼 느껴지지 않았습니다.
완료율 값이 존재할 수 있었지만 처리된 이메일 또는 내부 작업 완료를 나타내는지 명확하게 사용자에게 알리지 못했습니다.
MCP 공개 자료는 여전히 부분적으로 레거시 ?api_key= 설정 스토리를 반영했습니다.

이후

제출 후 경험이 더 깔끔하고 간결하며 직접적입니다.
라이브 진행 상황이 대량 흐름에서 기본적으로 표시됩니다.
제출 후 주요 CTA는 사용자를 정확한 작업 상세 페이지로 바로 이동합니다.
이력 상세 페이지는 안정적인 요약 메타데이터와 더 풍부한 라이브 결과 가시성을 표시합니다.
사용자 대면 진행 상황은 이제 이메일 수준의 진행 상황 의미론에 중심을 둡니다.
내부 작업 개수는 더 이상 고객 대면 메트릭으로 노출되지 않습니다.
백엔드 상태 인터페이스는 실시간 클라이언트 및 분산 작업을 위해 더 잘 구조화되었습니다.
MCP 공개 자료는 이제 원격 OAuth 아키텍처를 일관되게 반영합니다.

이것은 단일 기능이 아닙니다. 이것은 워크플로우 전반에 걸친 의미 있는 품질 개선입니다.

8. 다양한 사용자 그룹에게 미치는 영향

운영 및 성장 팀의 경우

UI 마찰이 적은 더 부드러운 대량 검증 워크플로우, 작업 실행 중 더 나은 가시성, 방금 시작한 정확한 작업에 대한 더 명확한 접근 권한을 얻게 됩니다.

제품 및 프론트엔드 팀의 경우

이제 더 강력한 진행률 의미론과 메타데이터와 실시간 상태 간의 더 명확한 분리가 있어서 진행률이 많은 화면을 더 쉽게 구축하고 설명할 수 있습니다.

백엔드 및 플랫폼 팀의 경우

분산 검증을 위한 더 강력한 상태 계약과 서로 다른 진행률 값이 실제로 무엇을 의미하는지에 대한 더 명확한 스토리가 있습니다.

MCP를 통합하는 개발자의 경우

이제 설정 질문에 대해 훨씬 더 명확한 답변을 갖게 됩니다: MCP 클라이언트의 경우 원격 MCP와 OAuth를 사용하고, 해당 모델이 적절한 경우 REST API에 API 키를 사용합니다.

9. 시작하기

업데이트된 경험이나 통합 경로를 탐색하고 싶다면 여기서 시작하세요:

제품에 대해 자세히 알아보기: 이메일 인증
더 큰 워크플로우 실행: 대량 이메일 인증
기본 사항 이해: 이메일 인증이란?
지원되는 클라이언트에서 MCP 연결: MCP 개요
설정 심화 학습: MCP 가이드
Claude Code 구체적으로 설정: Claude Code 가이드
대신 API 키 기반 통합 사용: API 참고자료

마무리

이번 릴리스는 하나의 거대한 화려한 표면에 관한 것이 아니었습니다. 모호함이 스며든 곳에서 제품을 강화하는 것에 관한 것이었습니다.

벌크 검증 여정을 더 깔끔하게 만들었습니다. 비동기 모니터링을 더 유용하게 만들었습니다. 진행률 보고를 더 정확하게 만들었습니다. 그리고 MCP 스토리를 우리가 실제로 구축하고 있는 플랫폼과 일치하도록 만들었습니다.

이러한 개선 사항들은 서로를 강화합니다.

UI가 더 적게 말하지만 더 많은 의미를 전달할 때 제품은 더 신뢰하기 쉬워집니다. 문서가 실제 아키텍처를 설명할 때 통합하기가 더 쉬워집니다. 그리고 경험 아래의 인터페이스가 더 명확한 의미론을 가질 때 진화하기가 더 쉬워집니다.

이것이 BillionVerify를 계속 밀어붙이는 방향입니다.

이미 BillionVerify를 사용하고 있다면, 이러한 변경 사항으로 인해 일상적인 워크플로우가 더 직접적이고 더 예측 가능하게 느껴질 것입니다.

지금 플랫폼을 평가하고 있다면, 이 업데이트는 제품 품질에 대해 우리가 어떻게 생각하는지에 대한 좋은 스냅샷입니다: 위에는 사용자 대면 명확성, 아래에는 명시적 계약, 그리고 현실과 일치하는 문서입니다.