Databricks AI Search, 라이브 테이블 소스 추가로 데이터 우회 경로 제거

Databricks AI Search는 이제 세 가지 추가 소스 유형을 지원하며, 고객이 이전에는 직접 관리해야 했던 중간 데이터 계층을 없앴다. 10월 26일 발표에는 유입되는 레코드를 처리하는 Streaming Tables, 계산된 쿼리 결과를 저장하는 Materialized Views, 그리고 관리형 Apache Iceberg 테이블이 포함된다. Iceberg는 분석 데이터를 구성하기 위한 개방형 테이블 포맷이다. 이번 변화의 직접적인 대상은 새로운 모델이 아니라 비즈니스 데이터와 검색 사이의 경로다.

핵심적인 긴장 관계는 플랫폼 관리 동기화와 고객 관리 사본 사이에 있다. Databricks는 고객이 이전에는 이러한 소스를 위해 자사의 기존 분석 포맷에 속하는 추가 테이블인 별도의 Delta 표현을 필요로 했다고 설명한다. 이 표현을 제거하면 검색 데이터가 원본과 어긋날 수 있는 지점이 줄어든다. 그렇다고 모든 애플리케이션이 즉시 최신 결과를 받는다는 뜻은 아니다.

Snowflake는 관리형 검색 서비스인 Cortex Search를 통해 유용한 비교 기준을 제공한다. 두 접근 방식 모두 검색을 엔터프라이즈 데이터에 더 가깝게 배치한다. 개발자와 구매자에게 중요한 질문은 어떤 시스템이 업데이트 프로세스를 소유하는지, 지연을 얼마나 명확하게 드러내는지, 그리고 문제가 발생했을 때 무엇이 일어나는지다.

Databricks AI Search, 중간 테이블 제거

native source support는 기존 검색 워크플로에서 사용할 수 있는 입력을 확장한다. Databricks는 고객이 이러한 소스를 별도의 Delta 테이블로 변환하는 대신 직접 연결할 수 있다고 설명한다.

의미 있는 변화는 고객이 관리하던 동기화 경계가 사라진다는 점이다.

추가 사본은 또 하나의 운영 책임을 만들기 때문에 이 경계는 중요하다. 누군가는 업데이트 시점, 장애 복구 방식, 그리고 내용이 여전히 의도한 소스를 반영하는지를 결정해야 한다. 검색에서 오래된 레코드가 반환되면 엔지니어는 어느 단계에서 흐름이 멈췄는지 파악해야 한다.

검색 애플리케이션이 판매 가능한 제품을 추천하는 가상의 소매업체를 생각해 보자. 이 애플리케이션에는 제품 설명, 현재 재고 상태, 그리고 유용한 일치 결과를 반환할 충분한 맥락이 필요하다. 별도의 검색 준비 테이블은 재고 상태가 오래될 수 있는 또 다른 지점을 만든다. 이 테이블을 제거하면 수정 사항이 거쳐야 하는 경로가 단순해진다.

이번 발표가 검색에서 효율적인 검색을 위해 준비된 구조인 인덱스를 더 이상 사용하지 않는다는 의미는 아니다. 이는 소스가 해당 인덱스에 연결되는 방식을 바꾸는 것이다. 구매자는 중간 비즈니스 데이터 사본을 제거하는 것과 모든 파생 표현을 없애는 것을 구분해야 한다.

이러한 구분은 발표의 의미를 적절한 수준으로 유지한다. Databricks는 고객이 이미 사용하는 데이터 객체 전반에서 기존 서비스의 범위를 확장하고 있다. 어떤 임의의 운영 시스템에 대해서도 검색이 모든 질문에 직접 답할 수 있다고 발표한 것은 아니다.

기존 배포 환경에서 실질적인 결정은 이미 존재하는 인프라 구성 요소에 관한 것이다. 별도의 준비 테이블은 이전에 검색 서비스가 요구했기 때문에만 존재하는가? 아니면 유용한 비즈니스 규칙, 개인정보 보호 경계, 콘텐츠 준비도 수행하는가?

테이블이 호환성 연결 역할만 한다면 네이티브 지원은 분명한 단순화 기회를 제시한다. 의미 있는 변환을 수행한다면, 이를 제거하려면 그러한 변환을 다른 곳에서 보존해야 한다. 아키텍처 다이어그램이 짧아진다고 해서 자동으로 더 나은 애플리케이션이 만들어지는 것은 아니다.

이 때문에 이번 업데이트는 지원 입력 목록 이상의 주목을 받을 만하다. 유지 관리되는 엔터프라이즈 데이터세트를 검색에 연결하는 팀의 설계 전제를 바꾼다. 가장 강력한 사례는 답변 품질의 자동적 개선이 아니라 불필요한 중복을 줄이는 데 있다.

이번 발표는 제품 방향과 예시 애플리케이션을 제시한다. 고객이 얼마나 많은 엔지니어링 노력을 절감할 수 있는지를 입증하는 독립적 측정치는 제공하지 않는다. 절감 규모는 기존 연결 계층이 실제로 무엇을 수행하는지에 달려 있다.

검색 팀은 사본을 덜 물려받지만 비즈니스 소유권은 유지한다

즉각적인 영향을 받는 팀은 소스 데이터세트와 검색 사이의 맞춤형 연결 계층을 유지하는 개발자와 데이터 엔지니어다. 플랫폼이 연결 계층의 기본 동기화 기능을 흡수할 수 있게 되면 이들의 업무도 달라진다.

플랫폼 관리형 전송은 연결 작업을 줄이지만, 검색 가능한 데이터가 무엇을 의미하는지는 여전히 애플리케이션 팀이 책임진다.

Databricks의 table processing semantics는 스트리밍 처리와 저장된 쿼리 결과를 구분한다. 새로운 이벤트와 유지 관리되는 비즈니스 상태는 서로 다른 애플리케이션 요구에 답하기 때문에 이 차이는 중요하다.

이벤트는 일어난 일을 기록한다. 유지 관리되는 결과는 관련 정보를 결합한 뒤 기업이 현재 무엇을 사실로 간주하는지를 나타낼 수 있다. 검색 품질은 인덱싱이 시작되기 전에 올바른 표현을 선택하는 데도 부분적으로 좌우된다.

가상의 지원 어시스턴트에서 새로 수신된 고객 메시지는 이벤트다. 고객의 현재 지원 상태는 파생 상태다. 최신 메시지만 검색한다고 해서 문제가 해결됐는지, 에스컬레이션됐는지, 또는 다른 문제로 대체됐는지가 반드시 드러나는 것은 아니다.

이 지점에서 Databricks materialized views는 발표의 더 큰 논의와 관련된다. 팀은 검색 후 애플리케이션이 해당 맥락을 재구성하도록 하는 대신, 검색 가능한 비즈니스 맥락을 업스트림에서 준비할 수 있다. 이점은 그 준비가 올바른 관계를 포착하는지에 달려 있다.

의도적인 분리를 일부 유지해야 할 이유도 있다. 검색 애플리케이션에는 더 광범위한 데이터세트 중 제한된 하위 집합이 필요할 수 있다. 사용 가능한 모든 필드가 아니라 신중하게 작성된 텍스트가 필요할 수도 있다. 이러한 요구는 호환성 사본이 제거된 뒤에도 남는다.

따라서 제품 팀은 아키텍처와 함께 소유권도 재검토해야 한다. 검색 가능한 표현을 누가 승인하는가? 필드 이름이 바뀌면 누가 처리하는가? 새로고침 실패 중 오래된 결과를 계속 노출할지 누가 결정하는가?

이 질문들은 특히 프로토타입이 공동으로 사용하는 프로덕션 서비스가 될 때 중요하다. 개발자는 직접 확인을 통해 작은 데이터세트를 이해할 수 있다. 더 광범위한 배포 환경에는 명시적인 책임이 필요하다. 다른 팀이 구축한 애플리케이션에 소스 변경이 영향을 줄 수 있기 때문이다.

같은 소유권 문제는 searchable knowledge base에서도 나타난다. 문서를 수집하고 검색 가능하게 만드는 것만으로는 어느 버전을 신뢰해야 하는지가 해결되지 않는다. 검색 인프라와 지식 관리는 서로 연결된 책임으로 남는다.

구매자에게 상업적 의미는 평가 기준의 변화다. 더 적은 통합 단계를 보여주는 공급업체라면 운영상 소유권이 어떻게 바뀌는지도 설명해야 한다. 고객이 사라지는 특정 업무, 테이블 또는 장애 경로를 식별할 수 있을 때 유지 관리 감소 주장은 더 설득력 있다.

이는 주된 목적이 제품 한계를 우회하는 것이었던 맞춤형 통합 작업에 압박을 가한다. 그렇다고 모든 전용 검색 아키텍처가 불필요해지는 것은 아니다. 특화된 검색 요구사항은 여전히 자체 기준으로 평가해야 한다.

네이티브 동기화는 경로를 바꾸지만 모든 새로고침 주기를 바꾸지는 않는다

이번 업데이트의 메커니즘은 기존 사용자에게 익숙하다. Databricks의 소스 동기화 인덱스 유형인 Delta Sync 인덱스가 이제 추가 지원 소스를 받아들인다.

index synchronization options는 중요한 조건을 보여준다. 표준 엔드포인트는 연속 및 트리거 방식 업데이트를 지원한다. 스토리지 최적화 엔드포인트는 트리거 동기화를 지원하며, 각 동기화는 인덱스를 부분적으로 재구축한다.

지원되는 라이브 소스가 모든 다운스트림 구성을 지속적으로 최신 상태로 만드는 것은 아니다.

엔드포인트는 검색 인덱스를 제공하는 서비스 리소스다. 그 구성을 선택하면 업데이트가 애플리케이션에 도달하는 방식이 달라진다. 소스 호환성과 업데이트 동작은 관련된 결정이지만 서로 대체할 수는 없다.

Databricks는 연속 동기화를 초 단위 지연 시간으로 인덱스를 정렬된 상태로 유지하는 방식이라고 설명한다. 문서에서는 이 모드가 추가 컴퓨팅 사용량과 연관된다고도 설명한다. 이는 구성별 설명이며, 이벤트에서 답변까지의 보편적인 보장은 아니다.

트리거 동기화는 지원되는 인터페이스를 통해 지시받았을 때 시작된다. 변경이 드문 참조 컬렉션에는 이 접근 방식이 애플리케이션 요구에 맞을 수 있다. 가용성에 민감한 경험에서는 트리거 사이의 간격이 제품의 최신성 동작 일부가 된다.

개념적으로 고려해야 할 시간 축은 여러 가지다. 비즈니스 이벤트는 소스에 도달해야 한다. 모든 준비 작업이 완료되어야 한다. 인덱스는 결과 변경을 반영해야 한다. 그 뒤 애플리케이션은 업데이트된 결과를 요청하고 사용해야 한다.

중간 사본을 제거하면 이러한 책임의 연결 고리가 짧아진다. 그러나 특정 워크로드에서 남아 있는 각 단계가 얼마나 걸리는지는 보장하지 않는다. 이를 확인하려면 전체 애플리케이션 경로를 관찰해야 한다.

새로 예약 가능한 약속을 추천하는 가상의 검색 경험을 생각해 보자. 관련 지표는 약속의 가용성이 변경된 후 언제 검색 가능한 상태가 되는지다. 인덱스에 이전 정보가 여전히 들어 있다면 빠른 검색 응답은 그 지연에 대해 거의 말해주지 않는다.

같은 구분은 Databricks streaming tables에도 적용된다. 아키텍처에 이들이 존재한다는 사실은 소스 처리에 관한 정보를 제공한다. 그렇다고 그 결과를 소비하는 모든 서비스의 동작을 독립적으로 입증하는 것은 아니다.

엔지니어링 관리자에게 이는 성공적인 마이그레이션이 무엇을 보여줘야 하는지를 바꾼다. 대체 구현은 유지 관리 부담을 줄이면서 필요한 결과를 보존해야 한다. 또한 단순히 지연을 관리형 서비스 내부로 넣는 대신, 지연된 업데이트를 더 쉽게 식별할 수 있어야 한다.

유용한 평가는 마이그레이션 전후의 동등한 비즈니스 변경을 비교하는 방식이 될 것이다. 엔지니어는 변경 사항이 언제 검색 가능해지는지, 반환된 콘텐츠가 올바른지, 장애가 얼마나 명확하게 드러나는지를 살펴볼 수 있다. 이는 발표에서 보고된 결과가 아니라 제안된 평가 기준이다.

관리형 경로가 동작을 가리지 않으면서 맞춤형 작업을 대체할 때 플랫폼의 가치는 커진다. 이것이 이번 릴리스가 제시하는 운영상 약속이다. 유지 관리되는 데이터와 검색 사이에서 고객이 소유해야 하는 연결 고리가 줄어든다는 것이다.

이 메커니즘은 아키텍처 단순화로서 신뢰할 만하다. 애플리케이션 수준의 이점은 여전히 소스 동작, 엔드포인트 구성, 그리고 제공되는 워크로드에 달려 있다.

관리형 Iceberg 지원은 적용 범위를 넓히지만 모든 호환성을 주장하지는 않는다

Databricks는 버전 3 이상을 사용하는 관리형 Iceberg 테이블을 명시한다. 이 표현은 지원 범위를 정의한다. 어떤 카탈로그에 있든 모든 Iceberg 테이블이 즉시 서비스를 제공할 수 있다는 주장으로 확대해서는 안 된다.

오픈 소스 포맷은 아키텍처 선택지를 넓히지만, 관리형 서비스 경계는 여전히 구현 방식을 좌우한다.

AI Search architecture는 의미적 유사성을 식별하는 데 사용되는 콘텐츠의 수치 표현인 임베딩을 활용한 검색을 설명한다. 또한 자동으로 동기화되는 인덱스와 고객이 직접 업데이트를 관리하는 직접 벡터 액세스를 구분한다.

그 구분은 핵심 내용을 더욱 분명히 한다. 이번 릴리스는 플랫폼 관리형 경로를 확장한다. 고객 관리형 대안을 없애거나 모든 검색 아키텍처가 동일한 수명 주기를 따르도록 만들지는 않는다.

Databricks Iceberg 지원은 이미 해당 형식을 유지해야 할 이유가 있는 조직에 가장 중요하다. 검색을 연결하기 위해서만 다른 형식을 요구하면 추가적인 설계 부담이 생긴다. 네이티브 수용은 문서화된 범위 내에서 변환이 필요한 특정 이유를 없앤다.

그러나 형식 호환성은 이식성의 일부일 뿐이다. 향후 유연성을 평가하는 팀은 다른 환경에서 변환, 액세스 규칙, 인덱스 설정, 애플리케이션 동작을 어떻게 재구성할지도 고려해야 한다. 이러한 우려는 기반 테이블 파일을 넘어선다.

이는 고객 벤치마크를 통해 입증된 비판이 아니라 아키텍처적 추론이다. 개방형 형식은 스토리지 계층의 의존성을 줄일 수 있지만, 애플리케이션은 그 위의 관리형 서비스에 계속 의존할 수 있다.

따라서 실질적인 질문은 시스템이 개방형인지 여부보다 더 구체적이다. 어떤 자산을 옮길 수 있고, 어떤 동작은 재구축해야 하며, 그 이전 과정에서 어떤 운영 책임이 달라지는가?

여러 분석 워크플로에서 제품 정보를 결합하는 예시 기업의 경우, 지원되는 테이블 형식을 유지하면 조율을 단순화할 수 있다. 팀은 검색 요구사항을 충족하기 위해 변환 단계를 추가하지 않아도 된다. 다만 식별자와 공유 필드의 의미에 대해서는 여전히 합의가 필요하다.

이번 릴리스는 검색이 소스 표현 방식을 결정해야 하는지 묻는 고객에게 Databricks가 더 명확히 답할 수 있게 한다. 지원되는 범위 내에서 회사는 이제 더 폭넓은 기존 입력을 제시할 수 있다.

이는 불필요한 형식별 준비 작업에 압박을 가한다. 그러나 실제 애플리케이션 목적이 있는 준비 작업은 여전히 유용하다. 설명을 정규화하거나, 민감한 필드를 제거하거나, 표준 제품 레코드를 설정하는 일은 호환성만을 위해 복사본을 유지하는 것과 다르다.

이 구분은 Databricks Iceberg 배포를 평가할 때 기준이 되어야 한다. 구매자는 정확히 어떤 변환 단계가 사라지는지 식별해야 한다. 그 제거와 무관한 관련성, 이식성 또는 거버넌스 개선까지 그 효과로 돌려서는 안 된다.

더 넓게 보면, 이는 엔터프라이즈 데이터 아키텍처와 검색 인프라 간의 적합성이 높아진다는 의미다. 이는 형식 지원을 상호운용성에 대한 완전한 해답으로 취급하지 않아도 가치가 있다.

Snowflake가 보여주는 관리형 검색에도 여전히 면밀한 검토가 필요한 이유

Snowflake는 Cortex Search 역시 엔터프라이즈 데이터 가까이에서 검색과 관리형 유지 관리를 결합한다는 점에서 적절한 비교 대상이다. 이 회사의 관리형 검색 서비스는 시맨틱 매칭과 키워드 검색을 결합한 하이브리드 검색을 지원한다.

Snowflake는 소스 업데이트에 대한 서비스 콘텐츠의 구성된 최신성 목표인 목표 지연 시간을 문서화하고 있다. 또한 소스 행을 고유하게 구분하는 식별자인 기본 키를 사용하는 최적화된 새로고침 경로도 설명한다.

경쟁상 핵심 질문은 어떤 관리형 업데이트 경로가 고객의 워크로드와 운영 모델에 가장 적합한가이다.

이러한 문서화된 기능은 공통된 제품 방향을 보여준다. 두 회사 모두 고객이 더 많은 검색 유지 관리 업무를 데이터 플랫폼에 맡기도록 유도한다. 하지만 이는 동등한 지연 시간, 관련성, 안정성 또는 총 운영 노력을 입증하지는 않는다.

중립적인 비교는 고객의 유용한 데이터가 이미 어디에 있는지에서 시작해야 한다. 검색 기능을 얻기 위해 데이터세트를 옮기는 일은 더 단순한 인덱싱 인터페이스의 이점을 상쇄할 수 있는 작업을 추가할 수 있다. 기존 변환과 조직의 소유 구조도 결정에 영향을 미친다.

다음 질문은 가시성과 관련된다. 검색이 오래된 정보를 반환할 때 고객은 수집, 변환 또는 인덱스 유지 관리 중 무엇이 지연을 유발했는지 판단할 수 있는가? 이러한 단계를 불투명한 하나의 전체로 취급하면 관리형 서비스를 평가하기가 더 어려워진다.

가장 강력한 회의적 관점은 바로 여기에 있다. 맞춤형 파이프라인이 줄어든다고 해서 반드시 답변이 더 최신이 되는 것은 아니다. Databricks의 materialized view refresh 문서는 지원 여부와 비용 고려 사항에 따라 새로고침이 증분 처리 또는 전체 재계산을 사용할 수 있다고 설명한다.

증분 처리는 전체 결과를 다시 계산하는 대신 관련 변경 사항을 처리한다. 전체 재계산은 모든 입력에 걸쳐 쿼리를 다시 평가한다. 어느 접근 방식이든 그 하류의 검색 인덱스는 결과 데이터가 언제 사용 가능해지는지에 여전히 의존한다.

Databricks materialized view를 사용하는 애플리케이션에서는 이 의존성을 명시적으로 살펴볼 필요가 있다. 인덱스는 가장 최근에 완료된 뷰를 정확히 반영할 수 있지만, 뷰 자체는 기반 비즈니스 이벤트를 뒤따를 수 있다. 인덱스 최신성만으로는 이 상황을 포착할 수 없다.

이 관찰은 새로운 지원에 결함이 있음을 입증하지 않는다. 이는 발표의 약속이 미치는 경계를 식별한다. 소스 통합은 호환성 우회 단계를 제거하지만 업스트림 처리 결정까지 없애지는 않는다.

Snowflake에도 동일한 검토가 적용되어야 한다. 구성된 최신성 목표는 유용한 제어 장치이지만, 고객은 자체 변경과 장애 상황에서 실제 동작을 계속 관찰해야 한다. 벤더 용어가 애플리케이션 수준의 증거를 대체해서는 안 된다.

검색 관련성 역시 별도로 평가해야 한다. 새로 인덱싱된 레코드라도 사용자의 질문과 잘 맞지 않을 수 있다. 올바르게 매칭된 레코드에도 더는 의사결정의 근거가 되어서는 안 되는 정보가 담길 수 있다.

따라서 구매자는 유지 관리, 최신성, 답변의 유용성을 하나의 주장으로 묶지 말아야 한다. 각각은 서로 다른 실패 모드를 다룬다. 신뢰할 수 있는 평가는 각각에 독자적인 증거를 제시한다.

이번 릴리스는 Databricks의 통합 스토리를 강화한다. 그러나 Cortex Search나 전용 검색 시스템보다 우수하다고 선언하는 데 필요한 비교 테스트를 제공하지는 않는다.

최신성 증거, 폐기된 파이프라인, 호환성 경계를 지켜볼 것

향후 몇 달간 가장 유용한 신호는 새 지원을 관찰 가능한 애플리케이션 동작과 연결할 것이다. 제품 제공 여부는 출발점일 뿐이며, 운영 증거가 이 변화의 중요도를 결정한다.

가장 강력한 후속 사례는 고객이 유지 관리하는 구성 요소를 줄이면서도 신뢰할 수 있는 검색을 보여주는 것이다.

첫째, 새로 지원되는 소스 전반에서 워크로드별 최신성 측정치를 지켜봐야 한다. 유용한 증거는 비즈니스 변경이 소스 처리와 검색 결과로 이어지는 과정을 추적한다. 일반 업데이트와 중단 후 복구를 구분해야 한다.

이러한 측정치가 더 짧아진 아키텍처가 예측 가능한 동작을 제공한다는 점을 보인다면 근거는 강화될 것이다. 반대로 지연의 위치를 계속 파악하기 어렵거나 설명 없이 크게 달라진다면 광범위한 최신성 주장은 약화될 것이다.

공개된 사례는 관련 구성 선택도 식별해야 한다. 지속적 동기화의 결과를 트리거 기반 배포의 대표 사례로 제시해서는 안 된다. 소스 업데이트가 단순한 워크로드가 모든 유지 관리형 비즈니스 뷰를 대표해서도 안 된다.

둘째, 실제로 폐기한 인프라를 밝히는 고객 사례를 지켜봐야 한다. 설득력 있는 사례는 이전 브리지가 무엇을 했는지, 네이티브 지원이 왜 이를 대체했는지, 어떤 책임이 남았는지를 설명할 것이다. 그러면 유지 관리 이점이 구체화된다.

이 증거가 중요한 이유는 새로 추가된 경로가 도입을 보장하지 않기 때문이다. 일부 기존 준비 계층에는 비즈니스 로직이 축적되어 있을 수 있다. 고객은 그 로직을 다른 곳에서 보존하고 검증할 수 있을 때까지 이를 유지할 수 있다.

필요한 동작을 잃지 않으면서 실패 경로가 줄어든다는 점을 보여주는 폐기 사례는 발표의 핵심 주장을 강화할 것이다. 동일한 준비 인프라를 유지하는 사례는 해당 배포에서 이점이 더 제한적임을 나타낼 것이다.

셋째, 다른 플랫폼의 문서화된 호환성 경계와 유사한 업데이트를 지켜봐야 한다. 중요한 세부 사항에는 지원되는 소스 구성과 새로고침 동작이 포함된다. 관리형 Iceberg의 경우 형식 독립성에 대한 광범위한 주장보다 정확한 범위가 더 유용하다.

더 폭넓은 지원은 Databricks가 기존 엔터프라이즈 아키텍처에 맞출 수 있는 역량을 강화할 것이다. 지속적인 예외 사항은 구매자가 추가 통합 작업이 필요한 지점을 식별하는 데 도움이 된다. 경쟁사의 개선도 이번 릴리스를 무효화하지 않으면서 비교 구도를 바꿀 것이다.

이러한 신호는 독자에게 발표를 현실적으로 평가하는 방법을 제공한다. 무엇이 단순해지는지, 무엇을 관찰할 수 있는지, 고객 책임이 어디까지 계속되는지에 초점을 맞춘다. 기능 목록만으로 도입을 예측하지 않는다.

Databricks AI Search를 평가하는 팀이라면 먼저 소스 데이터가 바뀔 때 답변도 바뀌는 비즈니스 질문에서 시작해야 한다. 대표 데이터세트를 선택하고 현재 준비 단계를 파악하라. 어떤 단계가 호환성을 위해 존재하고, 어떤 단계가 애플리케이션의 의미를 보호하는지 기록하라.

그런 다음 일반 업데이트, 수정, 복구가 제안된 아키텍처를 통과하는 과정을 추적하라. 검색된 증거를 사용자가 기대하는 비즈니스 상태와 비교하라. 관리형 경로가 지연을 이해 가능한 상태로 유지하면서 작업을 줄이는지 물어야 한다. 유용한 결정은 네이티브 소스 지원이 애플리케이션의 운영 모델을 개선하는지 여부다. 어떤 고객 관리형 구성 요소를 폐기할 수 있으며, 이후에도 검색이 신뢰할 수 있음을 어떤 증거로 보여줄 수 있는가?