Lakebase와 함께하는 Backstage, 2부

이 시리즈의 1부에서는 Backstage의 기본 데이터베이스를 Databricks Lakebase로 옮기면서 위험한 스키마 마이그레이션이 1초 만에 완료되는 브랜치-앤-테스트 작업으로 어떻게 바뀌었는지 살펴보았습니다. 하지만 보안 및 거버넌스 팀이 운영 데이터베이스를 여전히 블랙박스처럼 취급한다면, 더 빠른 개발 주기는 한계가 있습니다.

기존 스택에서는 애플리케이션 데이터베이스와 데이터 레이크가 완전히 다른 두 가지 보안 패러다임으로 존재합니다. 인프라의 소유권 그래프는 Backstage에 있으며, 격리된 RDS 인스턴스에 의해 지원되고 복잡한 IAM 역할 및 Postgres 기본 권한으로 관리됩니다. 한편, 웨어하우스 데이터는 데이터 팀이 Unity Catalog를 사용하여 관리합니다. Unity Catalog는 Databricks가 만든 오픈 소스 프레임워크로, 데이터, AI, 그리고 이제는 운영 데이터베이스를 위한 통합 거버넌스 레이어를 제공합니다. 이는 플랫폼의 모든 것에 걸쳐 액세스 제어, 감사 추적, 계보 및 규정 준수를 관리하는 단일 공간입니다.

RDS에서 단일 테이블 삭제를 감사하려면, IAM 주체에 대한 CloudTrail, pg_stat_activity 또는 SQL 문에 대한 pgaudit 로그, 그리고 타임스탬프에 대한 CloudWatch를 교차 참조해야 합니다. 세 가지 서비스, 세 가지 쿼리 언어, 세 가지 액세스 정책이 필요합니다. 운영 데이터베이스는 규정 준수 측면에서 부가적인 채널이 됩니다.

Unity Catalog, 운영 DB를 통합하다

Backstage를 Lakebase로 연결했을 때, 우리는 데이터가 저장되는 위치만 바꾼 것이 아닙니다. 액세스 정책이 존재하는 위치도 변경했습니다.

Lakebase는 Databricks 내부에 기본적으로 임베드되어 있으므로, Unity Catalog는 운영 Postgres 데이터베이스로 직접 확장됩니다. 이 POC에서는 Lakehouse Federation을 사용하여 Backstage 카탈로그를 Unity Catalog의 외부 카탈로그 (lakebase_bs)로 노출했습니다. 일단 노출되면, 표준 UC 권한이 누가 무엇을 볼 수 있는지 제어하며, Postgres 수준의 역할 관리는 필요하지 않습니다.

이 POC에서 Backstage를 위한 엔드투엔드 행 수준 보안(Row-Level Security) 정책을 구축하지는 않았지만, 아키텍처적으로 민감한 청구 테이블을 보호하는 것과 동일한 RLS 규칙을 이러한 운영 테이블에 직접 적용할 수 있습니다. '운영'과 '분석' 사이의 경계는 물리적인 장벽이 아니라 단순히 액세스 패턴이 됩니다.

별도의 설정 없이 통합 감사 추적

1부에서 실행했던 1초 만의 복사-온-쓰기(copy-on-write) 브랜칭을 기억하십니까? 기존 설정에서는 개발자가 데이터베이스를 한 시간 동안만 브랜치하고 삭제했다는 것을 보안 엔지니어에게 증명하는 것은 수동 작업입니다.

Lakebase를 사용하면 운영 데이터베이스에 대한 모든 제어 플레인 작업이 system.access.audit에 자동으로 기록됩니다. 이를 증명하기 위해, 1부의 재해 복구 실험에서 정확한 브랜치 작업에 대한 감사 로그를 쿼리했습니다.

결과:

1부 실험에서 모든 브랜치 생성 및 삭제가 기록됩니다. 각 이벤트는 특정 OAuth 사용자 ID 및 소스 IP에 연결되며, 자동으로 캡처되고, Unity Catalog의 다른 모든 감사 테이블과 동일한 행 수준 보안(Row-Level Security) 제어에 의해 관리됩니다. CloudTrail 교차 참조도, RDS 로그 파싱도 필요 없습니다. 단 하나의 SQL 쿼리만으로 가능합니다.

브랜치별 자동 비용 할당

거버넌스 팀은 브랜치를 누가 생성했는지 아는 것뿐만 아니라, 얼마의 비용이 들었는지도 알고 싶어 합니다.

기존 AWS 환경에서 임시 RDS 인스턴스의 비용을 추적하려면 종종 단기 워크로드를 놓치는 맞춤형 CloudWatch 태깅 전략이 필요합니다. Lakebase는 Unity Catalog의 시스템 청구 테이블과 기본적으로 통합되므로, 컴퓨팅 비용은 project_id, branch_id, 그리고 endpoint_id별로 자동으로 분류됩니다.

이 POC에서 프로덕션 브랜치는 31.6130 DBU로 청구되었고, 삭제된 테스트 브랜치는 독립적으로 0.0107 DBU로 할당되었습니다. 감사 추적과 비용 추적은 정확히 동일한 곳에서 관리됩니다.

매일 브랜치를 사용하는 팀에게 이것이 의미하는 것

우리의 거버넌스 이야기는 규정 준수 질문에 답합니다. 누가, 언제, 무엇을 했고, 비용은 얼마였는지 증명할 수 있는가? 답은 '예'입니다. 세 가지 서비스 대신 하나의 SQL 쿼리로 가능합니다. 하지만 1부의 브랜칭 워크플로우를 채택하는 개발 팀에게는 똑같이 중요한 두 번째 거버넌스 질문이 있습니다. 팀이 스프린트당 수십 개의 브랜치를 생성할 때 거버넌스는 어떻게 되는가?

1부에서 우리는 모든 기능 브랜치와 모든 풀 리퀘스트가 자체적으로 격리된 데이터베이스 복사본을 얻는 워크플로우를 설명했습니다. 2주 스프린트를 실행하는 6명의 개발자 팀은 단일 스프린트에서 30-40개의 브랜치를 생성하고 삭제할 수 있습니다. 이는 고객 PII, 금융 기록, 건강 데이터와 같은 민감한 필드를 잠재적으로 포함할 수 있는 30-40개의 프로덕션 데이터 복사본입니다.

여기서 Unity Catalog의 브랜치 수준 거버넌스는 단순한 편의성을 넘어 핵심적인 역할을 합니다. Lakebase 브랜치가 생성될 때, Unity Catalog의 속성 수준 마스킹 정책은 새 브랜치에 자동으로 전파됩니다. 기능 브랜치에서 작업하는 개발자는 마스킹되지 않은 프로덕션 데이터를 볼 수 없습니다. 이는 누군가 설정을 기억해서가 아니라, 거버넌스 레이어가 생성 시점에 이를 강제하기 때문입니다. PR 테스트를 실행하는 CI 브랜치는 프로덕션과 동일하게 관리됩니다. 테스터가 파괴적인 시나리오를 실행하는 QA 브랜치도 프로덕션과 동일하게 관리됩니다. 누군가 정책 적용을 잊어서 민감한 데이터가 유출되는 '비프로덕션 예외'는 없습니다.

이것은 생각보다 중요합니다. Perforce의 2025년 데이터 규정 준수 보고서에 따르면, 조직의 60%가 민감한 데이터가 부적절하게 익명화된 비프로덕션 환경에서 침해 또는 도난을 경험했습니다. 개발/테스트 환경을 프로비저닝할 때 데이터를 수동으로 마스킹하는 기존 접근 방식은 환경이 몇 초 만에 생성되고 파괴될 때 확장되지 않습니다. 거버넌스는 자동화되어야만 작동합니다.

DBA의 새로운 기회

감사 추적 및 비용 할당 데이터는 또한 조용한 변화를 시사합니다. DBA의 역할이 반응적인 티켓 작업에서 전략적인 플랫폼 아키텍처로 진화하고 있다는 것입니다.

오늘날 DBA의 시간 대부분은 운영 요청(환경 프로비저닝, 스키마 검토, 데이터 새로 고침, 액세스 권한 부여)에 할애됩니다. 6명의 개발자 팀은 스프린트당 30개 이상의 티켓을 생성할 수 있으며, DBA의 일정은 대기열로 가득 찹니다. DBA를 가치 있게 만드는 전문성(데이터 무결성, 성능, 거버넌스에 대한 깊이 있는 이해)은 반복적인 프로비저닝 작업에 묻히게 됩니다.

브랜칭이 셀프 서비스이고 거버넌스가 자동화되면 반복적인 작업은 사라집니다. 개발자는 1초 만에 자신의 환경을 프로비저닝합니다. 스키마 변경 사항은 풀 리퀘스트에서 비동기적으로 검토됩니다. DBA는 CI가 게시한 형식화된 스키마 차이점을 확인하고, 자신의 일정에 따라 검토하며, 일반적인 PR 워크플로를 통해 변경 사항을 승인하거나 요청합니다. 이제 시간이 생기면서 이러한 검토는 더욱 심층적으로 이루어집니다. DBA는 팀원들이 프로덕션의 기존 데이터와 구조를 이해하도록 돕고, 더 나은 솔루션을 찾기 위해 함께 작업하며, 데이터 무결성 및 거버넌스 표준을 유지하는 철저한 검토를 수행합니다. 데이터 마스킹은 수동 개입이 아닌 정책에 의해 적용됩니다. 비용 할당은 매월 조정하는 작업이 아니라 자동화됩니다.

DBA의 전문성을 실제로 활용하는 작업이 가능해집니다. 즉, 브랜칭 정책 정의, 거버넌스 규칙 설계, 프로모션 워크플로 설계, 성능 튜닝, 그리고 셀프 서비스를 안전하게 만드는 가드레일 설정 등입니다. DBA는 작업을 수행하는 것에서 작업이 어떻게 수행되는지 설계하는 것으로 전환합니다. 스프린트당 30개 이상의 운영 티켓에서 5개 미만의 고가치 정책 검토로 말이죠. 위에 제시된 감사 추적은 단순한 규정 준수 아티팩트가 아닙니다. 이는 DBA의 새로운 전략 대시보드이며, 플랫폼이 어떻게 사용되고 다음에 어디에 투자해야 할지에 대한 실시간 보기입니다.

역할 전환에서 툴링으로

DBA가 운영 티켓에서 플랫폼 설계로 전환하는 것은 툴링이 역할과 함께 변화할 때만 가능합니다. 플랫폼은 일상적인 작업을 스스로 수행해야 하며, DBA는 해당 작업이 어떻게 수행될지 설계할 공간이 필요합니다.

두 가지 오픈 소스 도구는 모두 Databricks Apps로 배포되며 위에 설명된 동일한 Unity Catalog 권한 및 감사 추적에 의해 관리되어 이러한 순환을 완성합니다.

LakebaseOps는 플랫폼이 자체적으로 수행하는 작업입니다. 프로비저닝, 성능, 상태의 세 가지 에이전트가 DBA가 티켓을 제출했던 51가지 작업을 대체합니다. 이 중 7개는 예약된 Databricks Jobs로 실행되며, DBA가 수동으로 관리했을 pg_cron crontab을 대체합니다. 모니터링 UI는 실시간 pg_stat 메트릭, 느린 쿼리 회귀, 브랜치 TTL 적용, 9가지 KPI 채택 대시보드를 제공합니다. 마이그레이션 마법사는 10개의 소스 엔진(Aurora, RDS, Cloud SQL, AlloyDB, Cosmos DB 등)을 Lakebase와 비교하여 점수를 매기고, AWS 및 Azure API에서 실시간 가격 정보를 제공합니다.

Lakebase MCP는 DBA가 플랫폼 위에서 수행하는 작업입니다. MCP를 지원하는 모든 AI 에이전트(Claude, Copilot, GPT)에 46가지 도구를 노출하는 Model Context Protocol 서버입니다. DBA는 pgAdmin을 여는 대신 의도를 설명하기 시작합니다.

두 가지 설계 선택이 이를 안전하게 유지합니다. 첫째, 이중 계층 거버넌스입니다. SQL 문 가드와 도구별 액세스 가드가 있으며, 위에 표시된 동일한 UC 액세스 패턴에 매핑되는 4가지 사전 구축된 프로필(read_only, analyst, developer, admin)이 있습니다. 코딩 어시스턴트는 read_only로 실행되며 물리적으로 테이블을 삭제할 수 없습니다.

둘째, 모든 쿼리는 귀속 가능합니다. 서버는 모든 문에 원본 도구를 태그합니다.

이전에 표시된 브랜치 수준 비용 할당과 결합하면 "어떤 브랜치의 어떤 에이전트가 새벽 4시 CPU 스파이크를 발생시켰는가?"라는 질문에 하나의 SQL 쿼리로 답할 수 있습니다.

LakebaseOps는 팀을 위해 실행됩니다. Lakebase MCP는 팀과 함께 실행됩니다. 둘 다 방금 본 거버넌스 태세를 계승합니다.

이 시리즈의 3부에서는 궁극적인 성과를 살펴보겠습니다. Backstage 내의 인프라 소유권 데이터를 가져와 단일 SQL 쿼리로 클라우드 청구 데이터에 직접 조인하는 것입니다.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)