Google Cloud의 Lakebase Postgres GA, 앱 데이터베이스를 분석 환경에 더 가깝게

Databricks가 Google Cloud에서 Lakebase Postgres GA를 발표하며, 기존의 분석 워크로드를 넘어 애플리케이션 데이터베이스 제공 범위를 확장했다. 11월 2일 발표로 Google Cloud 고객은 애플리케이션 트랜잭션과 AI 에이전트 메모리를 저장할 또 하나의 선택지를 얻게 됐다. 이제 판단은 데이터베이스 기능에만 국한되지 않는다. 팀은 분석 데이터와의 관계 속에서 애플리케이션 상태를 어디에 둘지 고려해야 한다.

Lakebase는 PostgreSQL로도 알려진 오픈소스 관계형 데이터베이스 Postgres를 기반으로 구축된 관리형 서비스다. 이 서비스의 등장은 애플리케이션 데이터베이스를 Databricks로 가져올지, 별도 관리형 데이터베이스 서비스에 유지할지에 관한 구체적인 선택지를 만든다. Google의 AlloyDB는 이미 까다로운 PostgreSQL 워크로드를 지원하고 있어, Databricks는 비어 있는 분야가 아닌 이미 형성된 시장에 진입한다.

개발자와 엔터프라이즈 구매자에게 중요한 점은 이러한 아키텍처 선택에 있다. 통합은 운영 경계를 줄일 수 있지만, 별도 서비스는 더 명확한 책임 구분과 독립적인 배포 결정을 유지한다. 정식 출시로 Lakebase는 더 구체적인 조달 선택지가 됐지만, 각 팀은 실제로 어떤 경계를 없애는지 여전히 확인해야 한다.

Google Cloud에서 Lakebase Postgres GA가 바꾸는 점

이번 출시는 Databricks 고객에게 Google Cloud의 운영 애플리케이션을 위한 정식 출시 Postgres 옵션을 제공한다.

날짜는 주의 깊게 살펴볼 필요가 있다. Databricks의 Lakebase 릴리스 노트는 2026년 10월 30일을 정식 출시일로 표시한다. 공개 발표는 11월 2일에 뒤따랐다. 릴리스 노트는 출시가 단계적으로 진행된다고도 경고하므로, 발표가 모든 계정에서 즉시 사용할 수 있음을 뜻하지는 않는다.

릴리스 노트는 지원 지역으로 us-east4, us-central1, us-west1, europe-west3, asia-southeast1의 다섯 곳을 명시한다. Oregon과 Singapore가 기존에 열거된 지역에 추가됐다. 엔터프라이즈 데이터베이스 결정은 성능이나 개발자 편의성을 논의하기 전에 배포 가능 여부부터 시작되므로, 이러한 지리적 범위는 중요하다.

지역 출시가 애플리케이션 팀의 실질적인 장애물을 없앨 수는 있지만, 더 폭넓은 아키텍처를 결정해 주지는 않는다. 데이터 레지던시 요건, 애플리케이션 위치, 기존 네트워크 구성은 여전히 판단에 영향을 미친다. 구매자는 Google Cloud에서 제공된다는 이유만으로 어디서나 사용할 수 있다고 가정하기보다, 의도한 환경이 지원되는지 확인해야 한다.

더 중요한 변화는 팀이 Databricks 아키텍처 안에 무엇을 배치할 수 있는지와 관련된다. 분석 플랫폼은 일반적으로 기록된 활동에 관한 질문에 답한다. 운영 데이터베이스는 사용자가 정확히 지속되기를 기대하는 애플리케이션 업데이트를 포함해 활동 자체를 처리한다. 이러한 책임을 더 가깝게 배치하면 더 단순한 애플리케이션 설계 기회가 생기는 동시에, 플랫폼의 운영 책임도 확대된다.

과거 활동에서 도출한 추천과 고객 상호작용을 결합하는 비즈니스 애플리케이션을 생각해 보자. 개발자는 현재 행동을 기록할 장소와 이전 행동을 분석할 장소가 필요하다. 공급업체가 인프라를 더 가깝게 가져오더라도 이러한 책임은 별개로 남는다. 이번 출시는 트랜잭션과 분석의 구분을 없애는 것이 아니라, 사용할 수 있는 배포 구성을 바꾼다.

정식 출시는 엔지니어링과 조달 부서 간의 대화도 바꾼다. 이제 팀은 서비스를 단순한 실험으로 취급하는 대신 프로덕션 요구 사항에 맞춰 평가할 수 있다. 이 평가에는 계약상 보장 범위, 지원 기대치, 복구 절차, 새로운 서비스 기능에 대한 조직의 수용 수준도 포함된다.

따라서 Lakebase Postgres GA는 이미 애플리케이션이 Databricks 데이터를 어떻게 사용해야 하는지 고민하는 조직에 가장 큰 의미가 있다. 이러한 구매자에게 서비스는 운영 상태를 위한 또 하나의 배치 옵션을 제공한다. 그 밖의 조직에는 이번 발표가 가용성을 알릴 뿐, 정상 작동 중인 데이터베이스를 이전해야 할 자동적인 이유를 제공하지는 않는다.

에이전트 메모리가 데이터베이스 배치를 더욱 중요하게 만든다

지속되는 에이전트 상태는 데이터베이스 배치를 애플리케이션 신뢰성의 문제로 바꾼다.

Databricks의 Google Cloud 출시 발표는 자동 확장, 유휴 컴퓨팅 일시 중지, 격리된 데이터베이스 브랜치, 이전 시점으로의 복구를 강조한다. 또한 KaBuM!이 AI 에이전트 메모리에 Lakebase를 사용하는 고객이라고 소개한다. 이 사례는 구체적인 애플리케이션 맥락을 제공하지만, 발표는 독립적 평가가 아닌 고객 추천 사례를 제시한다.

에이전트 메모리는 애플리케이션이 상호작용이나 워크플로 단계 전반에 걸쳐 검색하는 저장 정보다. 여기에는 대화 이력, 작업 진행 상황, 이후 검토가 필요한 결정이 포함될 수 있다. 애플리케이션이 이 정보에 의존하기 시작하면 데이터베이스 동작은 사용자 경험의 일부가 된다. 유창한 응답도 손실된 업데이트나 잘못 복원된 워크플로를 보완할 수는 없다.

이는 분석 데이터와 실시간 애플리케이션을 연결하는 팀에 부담을 준다. 이들은 어떤 정보에 즉각적인 트랜잭션 정확성이 필요한지, 어떤 정보는 나중에 도착해도 되는지 판단해야 한다. 과거 기록에서 생성된 추천과 주문 업데이트는 하나의 인터페이스에서 함께 제시되더라도 서로 다른 정확성 경계에 속한다.

플랫폼 팀에도 부담이 따른다. 또 다른 데이터베이스 서비스를 추가하면 보안, 관측, 지원이 필요한 환경도 하나 더 늘어난다. 서비스 통합은 일부 조정 업무를 줄일 수 있지만, 이는 책임이 더 명확해질 때만 가능하다. 기존 플랫폼 아래로 워크로드를 옮긴다고 해서 스키마, 액세스 결정, 사고 대응의 소유자가 자동으로 정해지는 것은 아니다.

Lakebase Google Cloud 배포는 동일한 조직이 분석 워크플로와 그 결과를 소비하는 애플리케이션을 함께 구축할 때 특히 관련성이 높다. 근접성은 이러한 팀의 협업을 더 쉽게 만들 수 있다. 그러나 이점은 공급업체 이름을 적게 쓰는 조직적 매력보다 애플리케이션의 실제 데이터 경로에 달려 있다.

고객 서비스 보조 도구를 예로 들면 차이가 분명해진다. 보조 도구는 계정 맥락을 검색하고, 미해결 요청을 기억하며, 권한이 부여된 작업을 수행하도록 다른 서비스에 요청할 수 있다. 이 데이터베이스는 진행 상황을 정확히 보존해야 한다. 관련 정보를 가까이에 두는 것은 애플리케이션이 권한을 집행하고 중단된 작업을 올바르게 처리할 때에만 도움이 된다.

따라서 개발자는 메모리 저장 문제와 에이전트 품질 문제를 분리해야 한다. 데이터베이스는 잘못된 결론도 올바른 결론만큼 충실하게 보존할 수 있다. 더 나은 지속성은 더 나은 추론, 적절한 권한 부여, 신뢰할 수 있는 도구 사용을 보장하지 않는다. 이를 위해서는 별도의 애플리케이션 제어와 평가가 필요하다.

엔터프라이즈 구매자에게 이번 출시는 실질적인 아키텍처 논의를 넓힌다. 운영 상태를 기존 분석 플랫폼에 더 가깝게 옮겨야 할까, 아니면 애플리케이션이 별도의 데이터베이스 경계를 유지해야 할까? 이 선택은 초기 시연이 끝난 뒤에도 오랫동안 배포 소유권과 복구 계획에 영향을 미친다.

컴퓨팅과 스토리지의 분리가 제품의 유연성을 설명한다

Lakebase의 유연성은 쿼리 실행과 영구 데이터 저장을 분리하는 데서 비롯된다.

Lakebase 아키텍처 문서는 영구 데이터를 소유하지 않는 Postgres 컴퓨팅 계층을 설명한다. 별도의 스토리지 구성 요소가 데이터베이스 변경 사항을 보존하고, 데이터 페이지를 재구성하며, 정보를 Google Cloud Storage에 지속적으로 저장한다. 이러한 구성은 데이터베이스의 영구 콘텐츠를 함께 이동하지 않고도 컴퓨팅 리소스를 변경할 수 있게 한다.

이 구분은 애플리케이션 활동과 저장 데이터가 서로 다르게 증가하기 때문에 중요하다. 애플리케이션은 상당한 이력을 유지하면서도 밤사이에는 트래픽이 거의 없을 수 있다. 또 다른 애플리케이션은 영구 데이터가 크게 늘지 않아도 짧은 급증을 경험할 수 있다. 실행 용량과 영구 스토리지를 분리해 취급하면 서비스는 이러한 패턴을 더 유연하게 처리할 수 있다.

이러한 유연성은 개발 환경에서 특히 관련성이 높다. 엔지니어는 애플리케이션 변경 사항을 검증할 때 현실적인 데이터 동작이 필요하지만, 테스트 환경은 프로덕션 수준의 지속적인 활동을 거의 갖지 않는다. 독립적인 환경을 지원하는 데이터베이스 아키텍처는 실행 리소스를 실제 개발 작업에 더 맞출 여지를 만든다.

비즈니스 이점은 여전히 팀이 이러한 환경을 어떻게 사용하는지에 달려 있다. 손쉬운 생성은 대기 시간을 줄일 수 있지만, 방치된 데이터베이스와 불분명한 소유권을 조장할 수도 있다. 환경 수명 주기 정책이 프로비저닝 편의성과 함께할 때 개발 속도는 개선된다. 그렇지 않으면 조직은 수동 병목 현상을 인벤토리 문제로 바꾸게 된다.

같은 논리는 애플리케이션 변경에도 적용된다. 격리된 데이터베이스 환경은 개발자가 프로덕션에 즉시 영향을 주지 않고 마이그레이션을 조사하도록 돕는다. 그렇다고 그 마이그레이션이 비즈니스 규칙을 보존한다는 뜻은 아니다. 변경 사항은 성공적으로 실행되면서도 고객 기록, 권한 또는 워크플로 상태의 의미를 바꿀 수 있다.

복구에도 애플리케이션 맥락이 필요하다. 데이터베이스 콘텐츠를 복원하는 것은 사고의 한 부분을 해결한다. 애플리케이션은 이미 메시지를 전송했거나 다른 시스템에 작업을 요청했을 수 있다. 이러한 효과에는 별도의 조정 절차가 필요하다. 팀이 복원된 기록에 대응하는 외부 작업을 이해할 때 데이터베이스 복구는 더 유용해진다.

이 때문에 아키텍처는 운영 증거를 대체하는 수단이 되지 않으면서도 주목할 가치가 있다. 컴퓨팅과 스토리지의 분리는 서비스가 유연한 리소스 관리를 지원하는 방식을 설명한다. 하지만 개별 애플리케이션이 경험할 지연 시간이나 종속성을 마이그레이션하는 데 필요한 노력까지 보여 주지는 않는다.

Lakebase Postgres GA는 이러한 아키텍처적 제안을 Google Cloud 고객을 위한 배포 옵션으로 전환한다. 유용한 평가 질문은 이 분리가 특정 워크로드의 운영 모델을 개선하는지 여부다. 팀은 아키텍처를 일반적인 성능 보장으로 받아들이기보다, 홍보되는 각 기능을 측정 가능한 애플리케이션 요구 사항과 연결해야 한다.

Lakebase vs AlloyDB는 플랫폼 경계에 관한 선택이다

가장 중요한 비교는 보편적인 데이터베이스 승자가 아니라 애플리케이션 소유권과 데이터 배치에 관한 것이다.

Google의 AlloyDB 아키텍처는 이미 컴퓨팅과 스토리지가 분리된 PostgreSQL 호환 엔진을 결합한다. Google은 고가용성, 복구 기능, 분석 쿼리 지원, AI 애플리케이션 기능을 문서화하고 있다. 따라서 Lakebase는 아키텍처 분리와 AI 지향 데이터베이스 기능이 이미 존재하는 시장에 진입한다.

이러한 맥락은 이번 출시를 해석하는 방식에 한계를 둔다. Databricks는 자체 플랫폼 안에 Google Cloud 배포 옵션을 추가했다. 기존 관리형 PostgreSQL 서비스에 현대적 애플리케이션에 필요한 기능이 없다고 입증한 것은 아니다. 구매자는 자신의 플랫폼에 새로 추가된 옵션과 새로 발명된 데이터베이스 범주를 구분해야 한다.

Lakebase와 AlloyDB의 비교는 조직의 기존 책임과 역할을 중심으로 살펴볼 때 가장 유용해진다. 이미 Databricks를 기반으로 애플리케이션을 구축하는 팀은 독립적인 Google Cloud 애플리케이션을 운영하는 팀과 통합 우선순위가 다르다. 두 팀 모두 PostgreSQL 호환성이 필요할 수 있지만, 선호하는 제어 플레인과 소유권 구조는 다를 수 있다.

제어 플레인은 서비스를 구성하고 관리하는 데 사용하는 관리 인터페이스다. 이를 선택하면 팀이 액세스를 요청하고, 리소스를 점검하며, 운영 변화에 대응하는 방식에 영향을 미친다. 조직이 장기 유지보수 부담을 평가할 때 이러한 일상적인 활동은 기능 비교만큼 중요할 수 있다.

기존 Databricks 고객에게는 운영 상태를 플랫폼 안에 배치하는 방안을 검토할 가치가 있다. 팀은 이 구조가 기존 통합 작업을 제거하는지, 아니면 단지 다른 곳으로 옮기는지 살펴봐야 한다. 엔지니어가 여전히 같은 변환 및 조정 로직을 유지해야 한다면, 아키텍처 다이어그램이 짧아져도 가치는 크지 않다.

확립된 Google 데이터베이스 운영 방식을 가진 애플리케이션 팀은 다른 계산을 해야 한다. 현재의 배포 절차, 인시던트 소유권, 운영 경험에는 실질적인 가치가 있다. 데이터베이스를 옮기면 전환 작업이 발생한다. 새로운 구조는 그 노력을 정당화할 만큼 워크로드별 이점을 제공해야 한다.

PostgreSQL 호환성은 서비스 간 기술적 거리를 좁히는 데 도움이 되지만, 모든 관리형 환경을 상호 대체 가능하게 만들지는 않는다. 애플리케이션은 쿼리 문법뿐 아니라 구성, 확장 기능, 인증 동작, 운영 도구에 의존한다. 책임 있는 비교라면 애플리케이션이 실제로 얼마나 이식 가능한지 추정하기 전에 이러한 의존성을 검토해야 한다.

Lakebase와 AlloyDB의 비교는 근거 없는 성능 순위도 피해야 한다. 여기서 검토한 출처는 동등한 배포 환경 간의 통제된 독립 비교를 제시하지 않는다. 구매자는 성능 차이를 해석하기 전에 일치하는 워크로드 조건과 동등한 안정성 요구사항을 확보해야 한다. 공급업체의 포지셔닝만으로는 이 질문에 답할 수 없다.

따라서 경쟁 압력은 구체적이다. Databricks는 고객에게 애플리케이션 데이터를 자사 플랫폼 안에 유지하는 방안을 고려할 또 하나의 이유를 제공한다. Google은 자사 데이터베이스 서비스를 직접 선택하는 팀을 위한 확립된 대안을 유지한다. 이번 출시는 운영 워크로드가 어디에 위치하는지를 둘러싼 경쟁을 강화하지만, 모든 워크로드가 이동해야 한다는 점을 입증하지는 않는다.

정식 출시가 모든 구성을 동등하게 만들지는 않는다

프로덕션 준비 상태는 애플리케이션이 실제로 사용할 정확한 구성을 기준으로 평가해야 한다.

Databricks의 자동 확장 문서는 고객이 선택한 한도 내에서 컴퓨팅 리소스를 자동으로 조정하는 방식을 설명한다. 또한 고가용성 구성은 0까지 확장할 수 없다고 명시한다. 고가용성은 특정 장애 상황에서도 서비스를 계속 제공할 수 있도록 이중화된 용량을 유지하는 것을 의미한다. 이 요구사항은 배포 환경에서 가능한 리소스 동작을 바꾼다.

이러한 구분은 제품 주장들을 오해의 소지가 있는 방식으로 결합하는 일을 막는다. 서비스는 유휴 상태 일시 중지와 이중화된 프로덕션 구성을 모두 제공할 수 있지만, 두 기능을 동시에 제공하지는 않을 수 있다. 구매자는 분리된 기능 설명으로 이상화된 구성을 조합하기보다 실제 안정성 설정을 갖춘 일관된 배포 환경을 평가해야 한다.

출시 전환 기간에는 문서도 신중하게 해석해야 한다. 일부 기능 페이지에는 여전히 이전 베타 표현이 표시되는 반면, 새로운 릴리스 노트는 정식 출시를 알린다. 이러한 불일치가 출시 자체를 무효화하는 것은 아니다. 다만 프로덕션 롤아웃을 계획할 때 구성별 사용 가능 여부를 확인하는 것이 합리적이다.

유휴 상태 일시 중지는 애플리케이션 측면에서 또 다른 고려사항을 만든다. 0까지 확장하는 동작 문서는 재활성화 중 연결 재시도를 권장하고 세션 컨텍스트가 재설정된다고 설명한다. 따라서 임시 세션 객체와 연결 상태에 주의해야 한다. 중단 없는 데이터베이스 세션을 전제하는 애플리케이션은 안전하게 재연결하도록 설계된 애플리케이션과 다르게 평가해야 한다.

이는 서비스를 배제해야 할 이유가 아니라 실질적인 엔지니어링 경계다. 간헐적으로 사용하는 내부 애플리케이션은 지속적으로 이용 가능한 고객 대상 애플리케이션과 기대치가 다를 수 있다. 같은 조직이라도 각각에 서로 다른 구성을 선택하는 것이 타당할 수 있다. 평가는 이러한 기대에서 시작한 뒤, 어떤 서비스 설정이 이를 충족하는지 검토해야 한다.

더 광범위한 통합 주장에도 정확성이 필요하다. Databricks는 Lakebase를 운영 데이터와 분석 데이터 사이의 분리를 줄이는 방법으로 제시한다. 공유 플랫폼 인프라가 모든 기존 애플리케이션이 데이터 이동 작업을 없앨 수 있음을 뜻하지는 않는다. 팀은 여전히 레코드가 어디에서 생성되는지, 어떻게 변경되는지, 어떤 시스템이 그 의미를 소유하는지 파악해야 한다.

가져온 고객 정보와 애플리케이션 내부에서 생성된 업데이트를 결합하는 워크플로를 생각해 보자. 애플리케이션은 권위 있는 레코드와 파생 정보를 구분해야 한다. 충돌하는 변경에 대한 정책도 필요하다. 이러한 질문은 바이트가 저장되는 위치만이 아니라 비즈니스 소유권에서 비롯되므로 인프라를 통합해도 사라지지 않는다.

보안도 같은 양상을 보인다. 중앙 집중식 관리는 감독을 단순화할 수 있지만, 조직은 여전히 어떤 사용자와 서비스에 액세스 권한을 부여할지 결정해야 한다. 개발 환경에는 적절한 제한이 필요하다. 복구 절차도 이러한 결정을 보존해야 한다. 관리 인터페이스가 줄어든다고 명시적인 권한 설계의 필요성이 사라지는 것은 아니다.

신중한 결론은 Lakebase Postgres GA가 워크로드별 트레이드오프를 유지하면서 프로덕션 선택지의 범위를 넓힌다는 것이다. 팀은 의도한 안정성, 연결, 액세스 설정에서의 동작을 확인해야 한다. 정식 출시는 출시 상태에 관한 질문에는 답하지만, 모든 애플리케이션 수용성 질문에 답하지는 않는다.

Google Cloud 출시 이후 주목할 사항

다음으로 유용한 근거는 실제 배포에서 통합이 운영 작업을 줄이는지 보여줄 것이다.

첫 번째 신호는 더 명확하고 일관되게 문서화된 프로덕션 기능 범위다. 향후 수개월 동안 구매자는 구성 지침이 정식 출시 릴리스 노트와 일치하는지 지켜봐야 한다. 더 명확한 지침은 팀이 상충하는 상태 라벨을 해결하지 않고도 배포를 계획할 수 있다는 신뢰를 높일 것이다. 모호함이 계속되면 조달 및 아키텍처 검토가 더 어려워질 것이다.

이 신호에는 핵심 서비스와 별도 출시 라벨이 붙은 기능 간의 구분도 포함된다. 팀은 애플리케이션에 어떤 기능이 필요한지, 그리고 해당 기능에 어떤 조건이 적용되는지 알아야 한다. 정식 출시된 데이터베이스가 그와 연관된 모든 네트워킹 또는 통합 옵션의 상태를 반드시 확정하는 것은 아니다.

두 번째 신호는 Google Cloud 배포에서 나온 상세한 고객 사례다. 유용한 보고서는 이전 아키텍처, 이전한 워크로드, 제거된 운영 작업을 설명할 것이다. 또한 플랫폼 외부에 남은 요소도 설명해야 한다. 이 정도의 세부 정보가 있어야 통합 주장이 단지 매력적으로 보이는 수준을 넘어 평가 가능해진다.

근거는 예외 상황뿐 아니라 일상적인 운영도 다뤄야 한다. 개발자는 일상적인 쿼리 성능뿐 아니라 배포 변경과 복구 동작을 이해하는 데 도움이 된다. 성공적인 시연은 애플리케이션이 실행된다는 점을 보여준다. 문서화된 프로덕션 경험은 가정이 무너졌을 때 팀이 애플리케이션을 계속 운영하는 방법을 설명한다.

세 번째 신호는 동등한 애플리케이션 요구사항 아래에서 재현 가능한 비교다. 여기에는 해당되는 경우 지속적인 활동, 간헐적 사용, 복구 기대치가 포함되어야 한다. 선택한 배포 환경이 작업을 줄이거나 애플리케이션 동작을 개선할 때 결과는 도입의 근거를 강화할 것이다. 혼합된 결과는 더 좁지만 유용한 적합성을 파악하는 데 도움이 될 것이다.

어느 결과도 보편적인 승자를 필요로 하지 않는다. 한 아키텍처는 개발 환경에 특히 잘 맞는 반면, 확립된 프로덕션 애플리케이션에서는 이점이 더 작을 수 있다. 다른 배포 환경은 주로 조직적 통합의 혜택을 받을 수 있다. 구체적인 결과는 데이터베이스의 미래에 관한 광범위한 주장보다 구매자가 더 정확하게 선택하도록 도울 것이다.

이 평가를 준비하는 팀에게는 판단 근거를 보존하는 것도 작업의 일부다. 검색 가능한 기술 지식 베이스는 테스트 결과, 구성 결정, 미해결 질문을 이후 검토자가 활용할 수 있도록 유지할 수 있다. 이 기록은 초기 제품 인상이 설명되지 않은 장기 약속으로 굳어지는 일을 막는 데 도움이 된다.

소유권이 명확하고 성공 기준을 관찰할 수 있는 워크로드를 선택하라. Lakebase Google Cloud 배포 옵션을 테스트하기 전에 현재 동작을 기록하고, 그다음 동등한 안정성 구성을 비교하라. 일반 트래픽과 함께 애플리케이션 재연결, 복구, 권한 검사도 포함하라. 제거할 것으로 예상하는 통합 작업을 식별하고, 실제로 사라지는지 검증하라. 팀이 의존성을 이해할 수 있도록 평가 과정에 이탈 경로를 유지하라. Lakebase Postgres GA는 Google Cloud 고객에게 구체적인 새로운 선택지를 제공한다. 다음 결정은 애플리케이션 팀의 몫이다. 데이터베이스를 옮기면 어떤 운영 경계가 제거되며, 그 변화가 도움이 되었음을 어떤 근거로 보여줄 수 있을까?