DBMS에서의 동시성 제어: 잠금, MVCC 및 낙관적 전략이 데이터를 일관되게 유지하는 방법

동시성 제어는 데이터 손상 없이 동시 트랜잭션을 관리하기 위해 데이터베이스 관리 시스템(DBMS)이 사용하는 메커니즘 집합입니다. 여러 사용자나 프로세스가 동시에 읽고 쓸 때 제어되지 않은 액세스는 데이터 손실, 더티 리드, 다운스트림 시스템으로 확산될 수 있는 일관되지 않은 결과와 같은 데이터 이상 현상을 초래합니다.

동시성 제어는 ACID의 “I”(격리)를 강제합니다. 즉, 동시 트랜잭션은 마치 순차적으로 실행된 것처럼 동일한 결과를 생성해야 하며, 이는 직렬화 가능성이라는 속성입니다. 이것이 없으면 은행 애플리케이션은 이체를 놓칠 수 있고, 재고 시스템은 제품을 과잉 판매할 수 있으며, 분석 파이프라인은 부분적으로 작성된 데이터를 기반으로 보고서를 생성할 수 있습니다.

이 가이드에서는 주요 동시성 문제, 이를 해결하기 위한 주요 메커니즘(잠금, 다중 버전 동시성 제어(MVCC), 낙관적 및 비관적 전략)과 격리 수준, 교착 상태 처리, 워크로드에 적합한 접근 방식을 선택하기 위한 실용적인 지침을 다룹니다.

동시성 제어가 중요한 이유

현대 데이터베이스 시스템은 초당 수천에서 수백만 건의 동시 트랜잭션을 일상적으로 처리합니다. 사용자가 쿼리를 제출하거나, 레코드를 업데이트하거나, ETL 파이프라인을 시작할 때마다 DBMS는 동시에 발생하는 모든 다른 작업과 함께 해당 작업을 조정해야 합니다. 동시성 제어가 없으면 인터리빙된 트랜잭션은 예측할 수 없고 잘못된 결과를 생성합니다.

두 사용자가 동시에 동일한 은행 계좌 잔액을 업데이트하는 구체적인 시나리오를 생각해 보겠습니다. 사용자 A는 잔액($1,000)을 읽고, $200을 빼고, $800을 씁니다. 사용자 B도 $1,000을 읽고, $500을 더하고, $1,500을 씁니다. 올바른 결과는 순서에 따라 달라지지만($800 또는 $1,500), 조정이 없으면 한 쓰기가 다른 쓰기를 단순히 덮어씁니다. 이것은 동시성 제어가 방지하기 위해 존재하는 여러 이상 현상 중 고전적인 업데이트 누락입니다.

동시성 제어는 직렬화 가능성을 강제합니다. 즉, 동시 실행의 결과는 해당 트랜잭션의 일부 직렬 순서와 일치해야 합니다. 이는 ACID 보장(원자성(전부 또는 전무), 일관성(유효한 상태 전환), 격리(간섭 없음), 지속성(커밋된 변경 사항은 영구적))을 직접적으로 지원합니다. 이는 모든 애플리케이션이 데이터에 대한 신뢰를 구축하는 기반을 보장합니다.

해결해야 할 동시성 문제

솔루션을 탐색하기 전에 적절한 제어 없이 동시 트랜잭션이 실행될 때 발생하는 특정 이상 현상을 이해하는 것이 도움이 됩니다.

• 더티 리드. 트랜잭션이 아직 커밋되지 않은 다른 트랜잭션이 쓴 데이터를 읽습니다. 두 번째 트랜잭션이 롤백되면 첫 번째 트랜잭션은 실제로 존재하지 않았던 데이터를 기반으로 로직을 수행합니다. 더티 리드는 의사 결정에 잘못된 상태를 도입하기 때문에 가장 위험한 이상 현상 중 하나입니다.
• 업데이트 누락. 두 트랜잭션이 동일한 데이터 항목을 읽고 업데이트된 값을 씁니다. 두 번째 쓰기는 첫 번째 쓰기의 변경 사항을 통합하지 않고 덮어쓰므로 유효한 업데이트가 지워집니다. 위의 은행 계좌 시나리오는 교과서적인 예입니다.
• 반복 불가능한 읽기. 트랜잭션이 동일한 행을 두 번 읽지만 다른 트랜잭션이 읽기 사이에 행을 수정하고 커밋했기 때문에 다른 값을 얻습니다. 이는 단일 트랜잭션 내에서 안정적인 데이터에 의존하는 모든 로직을 중단시킵니다.
• 팬텀 읽기. 트랜잭션이 범위 쿼리를 다시 실행하지만 다른 트랜잭션이 해당 간격에 일치하는 행을 삽입하거나 삭제했기 때문에 다른 행 집합을 얻습니다. 팬텀은 집계 쿼리 및 보고 워크로드에 특히 문제가 됩니다.

이 네 가지 이상 현상은 모든 동시성 제어 메커니즘의 “이유”입니다. 각 메커니즘은 적용하는 격리 수준에 따라 일부 또는 전부를 방지합니다.

잠금 기반 동시성 제어

잠금은 동시성 제어에 대한 가장 오래되고 직관적인 접근 방식입니다. DBMS는 트랜잭션이 데이터 항목(행, 페이지 또는 전체 테이블)에 액세스하도록 허용하기 전에 해당 데이터 항목에 잠금을 할당합니다. 잠금은 게이트키퍼 역할을 합니다. 다른 트랜잭션이 이미 충돌하는 잠금을 보유하고 있다면 요청하는 트랜잭션은 기다려야 합니다.

공유 및 배타적 잠금

• 공유(읽기) 잠금 은 여러 트랜잭션이 동일한 데이터를 동시에 읽을 수 있도록 합니다. 아무도 데이터를 수정하고 있지 않기 때문에 동시 읽기는 안전합니다.
• 배타적(쓰기) 잠금 은 단일 트랜잭션에 데이터 항목에 대한 독점적인 액세스 권한을 부여합니다. 배타적 잠금이 유지되는 동안 다른 트랜잭션은 해당 항목을 읽거나 쓸 수 없습니다. 이는 업데이트 누락 및 더티 리드를 방지하지만 동시성도 제한합니다.

잠금 세분성은 중요한 절충점을 도입합니다. 행 수준 잠금은 관련 없는 행에 계속 액세스할 수 있으므로 동시성을 극대화하지만 시스템이 많은 개별 잠금을 추적해야 하므로 오버헤드가 추가됩니다. 테이블 수준 잠금은 관리하기가 더 간단하고 저렴하지만 관련 없는 트랜잭션이 기다리도록 강제하여 처리량을 줄입니다.

2단계 잠금(2PL)

2단계 잠금은 잠금을 통해 직렬화 가능성을 보장하는 표준 프로토콜입니다. 모든 트랜잭션을 두 단계로 나눕니다. 성장 단계 동안 트랜잭션은 필요한 모든 잠금을 획득하지만 절대 해제하지 않습니다. 첫 번째 잠금을 해제하면 축소 단계 로 들어가 새로운 잠금을 획득할 수 없고 잠금만 해제할 수 있습니다. 이 규칙은 트랜잭션이 데이터 항목을 잠그는 순서가 일관되도록 보장하며, 이는 차례로 직렬화 가능한 스케줄을 보장합니다.

엄격한 2PL 은 모든 잠금을 트랜잭션이 커밋될 때까지 유지하는 일반적인 변형입니다. 이는 캐스케이딩 롤백을 방지합니다. 캐스케이딩 롤백은 하나의 중단된 트랜잭션이 해당 커밋되지 않은 데이터를 읽은 다른 트랜잭션을 중단하도록 강제하는 상황입니다. 잠금 기반 동시성 제어를 사용하는 대부분의 관계형 데이터베이스는 엄격한 2PL의 일부 형태를 구현합니다.

2PL의 단점은 차단(트랜잭션이 다른 트랜잭션이 보유한 잠금을 기다려야 함)을 도입하고 교착 상태의 조건을 생성한다는 것입니다.

다중 버전 동시성 제어(MVCC)

MVCC는 근본적으로 다른 접근 방식을 취합니다. 액세스를 차단하는 대신 각 데이터 항목의 여러 버전을 유지하여 각 트랜잭션이 데이터베이스의 일관된 스냅샷을 볼 수 있도록 합니다. 트랜잭션이 행을 쓰면 MVCC는 기존 버전을 덮어쓰는 대신 새 버전을 생성합니다. 읽는 트랜잭션은 트랜잭션이 시작될 때 최신이었던 버전을 계속 봅니다.

주요 이점은 읽는 트랜잭션은 쓰는 트랜잭션을 차단하지 않고 쓰는 트랜잭션은 읽는 트랜잭션을 차단하지 않는다 는 것입니다. 이는 읽기 집약적인 워크로드에 상당한 성능 이점을 제공하므로 MVCC는 현대 데이터베이스에서 지배적인 동시성 제어 메커니즘입니다. PostgreSQL, MySQL/InnoDB, Oracle 및 대부분의 최신 OLTP 및 OLAP 시스템은 MVCC의 일부 형태를 사용합니다.

쓰기 충돌은 커밋 시점에 감지됩니다. 두 트랜잭션이 동일한 행을 수정하면 먼저 커밋하는 트랜잭션이 승리하고 두 번째 트랜잭션은 재시도해야 합니다. 쓰기 충돌 해결에 대한 이 낙관적인 접근 방식은 충돌이 드문 경우(대부분의 경우) 처리량을 높게 유지합니다.

스냅샷 격리 는 가장 일반적인 MVCC 기반 격리 수준입니다. 각 트랜잭션은 트랜잭션이 시작될 때 존재했던 데이터베이스를 보므로 더티 리드와 반복 불가능한 읽기를 방지합니다. 그러나 스냅샷 격리는 두 트랜잭션이 각각 겹치는 데이터를 읽고 읽은 내용을 기반으로 쓰기를 수행하여 두 트랜잭션 모두 단독으로는 생성하지 않았을 상태를 초래하는 쓰기 편향 이라는 미묘한 이상 현상을 허용합니다. 직렬화 가능한 스냅샷 격리(SSI)는 추가 오버헤드를 희생하면서 이 격차를 해결합니다.

MVCC는 자체적인 절충점을 도입합니다. 여러 버전을 유지하면 추가 스토리지가 소비되고 시스템은 주기적으로 오래된 버전을 가비지 수집해야 합니다. PostgreSQL에서는 이 프로세스를 VACUUM이라고 합니다. 높은 쓰기 경합 하에서 재시도 비용과 버전 관리 오버헤드가 상당해질 수 있습니다.

낙관적 vs. 비관적 동시성 제어

잠금 및 MVCC의 특정 메커니즘을 넘어 동시성 제어 전략은 비관적 및 낙관적이라는 두 가지 철학적 진영으로 나뉩니다. 어떤 진영이 워크로드에 적합한지 이해하는 것은 데이터 팀이 내릴 수 있는 가장 중요한 아키텍처 결정 중 하나입니다.

비관적 제어

비관적 동시성 제어는 충돌이 발생하기 쉽다고 가정하고 데이터에 액세스하기 전에 잠금을 획득하여 충돌을 방지합니다. 이 접근 방식은 충돌이 빈번하고 트랜잭션을 롤백하고 재시도하는 비용이 높은 쓰기 집약적인 워크로드에 가장 적합합니다. 모든 쓰기를 순차화하고 확인해야 하는 금융 원장 시스템은 고전적인 사용 사례입니다.

단점은 차단입니다. 높은 동시성 하에서 트랜잭션은 잠금을 기다리며 대기열에 들어가 처리량을 줄입니다. 최악의 경우 경쟁 잠금 요청은 교착 상태를 만듭니다.

낙관적 제어

낙관적 동시성 제어는 충돌이 드물다고 가정합니다. 트랜잭션은 잠금을 획득하지 않고 자유롭게 실행되며 자체 개인 데이터 복사본에서 작동합니다. 커밋 시점에 시스템은 트랜잭션의 읽기 및 쓰기가 다른 커밋된 트랜잭션과 충돌하는지 여부를 검증합니다. 충돌이 발견되지 않으면 트랜잭션이 커밋됩니다. 충돌이 감지되면 트랜잭션이 롤백되고 재시도됩니다.

이 3단계 모델 — 읽기, 검증, 쓰기 — 는 대부분의 트랜잭션이 동일한 데이터를 다루지 않는 환경에서 뛰어납니다. 콘텐츠 관리 시스템, 카탈로그 검색 애플리케이션 및 보고 대시보드가 일반적인 예입니다.

단점은 낭비되는 작업입니다. 충돌이 빈번할 때 트랜잭션은 반복적으로 전체 로직을 실행한 후 검증 단계에서 롤백되어 결과물을 생성하지 않고 리소스를 소모합니다.

언제 무엇을 사용해야 할까

비관적 제어와 낙관적 제어 사이의 선택은 워크로드 특성에 따라 달라집니다. 높은 쓰기 경합, 짧은 트랜잭션 및 낮은 재시도 허용 오차는 비관적 제어를 가리킵니다. 낮은 충돌 확률과 높은 동시성 요구 사항을 가진 읽기 중심 워크로드는 낙관적 또는 MVCC 기반 접근 방식을 선호합니다.

실제로는 많은 프로덕션 시스템이 두 전략을 혼합하여 사용합니다. 일반적인 패턴은 일반 읽기 및 쓰기에는 MVCC를 사용하고 알려진 핫스팟 행에는 비관적 잠금을 적용하는 것입니다. 예를 들어, 여러 트랜잭션이 동시에 경합할 가능성이 있는 특정 행을 잠그기 위해 SELECT ... FOR UPDATE를 사용합니다.

격리 수준 및 절충점

격리 수준은 트랜잭션이 어떤 동시성 이상 현상을 겪을 수 있는지 정의합니다. 더 엄격한 수준은 더 많은 이상 현상을 방지하지만 동시성을 줄입니다. SQL 표준은 4가지 수준을 정의하며 대부분의 데이터베이스는 이 중 일부 변형을 구현합니다.

• 읽기 미커밋 은 최대 동시성을 제공하지만 더티 읽기를 포함한 모든 이상 현상을 허용합니다. 위험이 성능 이점보다 훨씬 크기 때문에 프로덕션에서는 거의 사용되지 않습니다.
• 읽기 커밋 은 트랜잭션이 각 문 실행 전에 커밋된 데이터만 보도록 보장하여 더티 읽기를 방지합니다. 반복 불가능 읽기와 팬텀을 허용하며, 이는 대부분의 웹 애플리케이션 및 범용 워크로드에 대한 허용 가능한 절충점입니다. PostgreSQL 및 Oracle은 이를 기본값으로 사용합니다.
• 반복 가능 읽기 는 트랜잭션 중에 읽은 모든 행이 다시 읽을 때 동일한 값을 반환하도록 보장하여 더티 읽기 및 반복 불가능 읽기를 방지합니다. 팬텀은 여전히 발생할 수 있습니다. MySQL/InnoDB는 이 수준을 기본값으로 사용합니다.
• 직렬화 가능 은 모든 이상 현상을 방지합니다. 트랜잭션은 일부 직렬 순서로 한 번에 하나씩 실행된 것처럼 작동합니다. 이것은 가장 높은 일관성 보장이지만 가장 낮은 동시성을 제공합니다. 절대적인 정확성이 협상 불가능한 금융, 규정 준수 또는 안전 필수 워크로드에 일반적으로 예약됩니다.

대부분의 애플리케이션은 읽기 커밋 또는 반복 가능 읽기 수준에서 안전하게 작동합니다. 직렬화 가능을 선택하는 것은 기본값으로 사용되기보다는 특정 비즈니스 요구 사항에 따라 결정되어야 하는 의도적인 절충입니다.

교착 상태: 예방 및 해결

교착 상태는 두 개 이상의 트랜잭션이 서로 필요한 잠금을 각각 보유하여 상호 대기 순환을 형성할 때 발생합니다. 어느 트랜잭션도 진행할 수 없으며, 개입 없이는 둘 다 무한정 대기하게 됩니다.

• 탐지. 대부분의 데이터베이스는 어떤 트랜잭션이 어떤 잠금을 기다리고 있는지 매핑하는 데이터 구조인 대기 그래프에서 주기를 주기적으로 확인하여 교착 상태를 탐지합니다. 주기가 발견되면 DBMS는 “희생자” 트랜잭션을 선택하고 이를 중단하여 잠금을 해제함으로써 나머지 트랜잭션이 계속 진행될 수 있도록 합니다.
• 예방. 가장 효과적인 예방 전략은 모든 트랜잭션에서 일관되고 예측 가능한 순서로 잠금을 획득하는 것입니다. 모든 트랜잭션이 동일한 순서로 리소스를 잠그면 순환 대기 조건이 형성될 수 없습니다. 잠금 시간 초과는 추가적인 안전망을 제공합니다. 트랜잭션이 너무 오래 기다리면 잠재적인 교착 상태에 기여하는 대신 중단됩니다.
• 해결. 중단된 희생자 트랜잭션은 롤백되고 일반적으로 애플리케이션에 의해 자동으로 재시도됩니다. 교착 상태는 일반적으로 드물기 때문에 재시도 비용은 미미합니다.

교착 상태를 최소화하기 위한 실용적인 팁: 트랜잭션을 가능한 한 짧게 유지하고, 예측 가능한 순서로 리소스에 액세스하고, 적절한 잠금 시간 초과 값을 설정하고, 시스템 상태 신호로 교착 상태 빈도를 모니터링합니다.

올바른 동시성 제어 접근 방식 선택

보편적인 답은 없습니다. 올바른 메커니즘은 워크로드 특성, 일관성 요구 사항 및 운영상의 절충점에 따라 달라집니다. 여러 요인이 결정을 안내합니다.

• 읽기 대 쓰기 비율. 읽기 중심 워크로드는 차단 없이 동시 읽기를 허용하는 MVCC 또는 낙관적 제어의 이점을 누립니다. 쓰기 중심 워크로드는 빈번한 재시도 비용을 피하기 위해 종종 비관적 잠금이 필요합니다.
• 충돌 빈도. 대부분의 분석 및 웹 워크로드에서처럼 충돌이 드문 경우 낙관적 제어가 더 나은 처리량을 제공합니다. 충돌이 빈번하면 재시도 오버헤드로 인해 비관적 제어가 전반적으로 더 효율적입니다.
• 트랜잭션 기간. 짧은 트랜잭션은 잠금이 짧게 유지되므로 잠금과 잘 작동합니다. 장기 실행 트랜잭션은 장기간의 차단을 피하는 MVCC의 이점을 누립니다.
• 일관성 요구 사항. 엄격한 요구 사항(금융, 규정 준수)은 2PL을 사용한 직렬화 가능 격리를 선호합니다. 중간 요구 사항(웹 애플리케이션, 카탈로그)은 MVCC를 사용한 읽기 커밋으로 잘 처리됩니다.
• 분산 대 단일 노드. 분산 시스템은 네트워크 지연 시간, 파티션 허용 오차 및 합의 요구 사항과 같은 조정 오버헤드를 도입하여 동시성 제어를 더 복잡하고 비용이 많이 들게 합니다.

많은 프로덕션 시스템은 전략을 결합합니다. MVCC를 기본값으로 사용하고, 알려진 핫스팟 행에는 비관적 잠금을 사용하고, 낙관적 충돌 해결을 위해 애플리케이션 수준 재시도 로직을 사용합니다.

분산 및 분석 시스템의 동시성 제어

분산 데이터베이스는 추가적인 조정 문제를 직면합니다. 노드 간 네트워크 지연 시간, 파티션 허용 오차의 필요성 및 합의 요구 사항은 모두 동시성 제어의 비용과 복잡성을 증가시킵니다. 접근 방식에는 분산 2PL, 전역 타임스탬프를 사용한 분산 MVCC(Google Spanner의 TrueTime 시스템에서 사용됨) 및 Raft 및 Paxos와 같은 합의 프로토콜이 포함됩니다.

분석 및 레이크하우스 플랫폼은 기존 OLTP 데이터베이스와 다르게 동시성을 처리합니다. 이러한 시스템은 트랜잭션 시스템에서 일반적인 행 수준 잠금 패턴보다 스냅샷 격리를 사용한 읽기 중심의 대규모 스캔 워크로드에 최적화되어 있습니다.

Databricks 및 Delta Lake는 동일한 테이블에 대한 동시 쓰기에 대해 낙관적 동시성 제어를 사용합니다. 쓰기는 3단계 프로세스를 따릅니다. 영향을 받는 파일을 식별하기 위해 최신 테이블 버전을 읽고, 새 데이터 파일을 작성한 다음, 커밋 시점에 충돌하는 변경 사항이 발생하지 않았는지 확인합니다. 트랜잭션이 충돌하지 않으면 성공합니다. 충돌이 감지되면 자동 재시도 또는 충돌 해결이 나머지를 처리합니다. Delta Lake는 잠금을 사용하지 않는 MVCC 모델을 구현하므로 독자는 항상 일관된 스냅샷을 보고 작성자는 독립적으로 진행합니다.

Delta Lake 테이블의 ACID 트랜잭션은 여러 파이프라인, 사용자 및 쿼리가 동일한 데이터에 동시에 액세스하더라도 데이터 일관성을 보장합니다. 실제 행 수준 동시성이 어떻게 작동하는지에 대한 자세한 내용은 Databricks 엔지니어링 블로그에서 기본 메커니즘에 대한 심층 분석을 제공합니다.

이 접근 방식은 전통적인 OLTP를 넘어 데이터 엔지니어링, ETL 및 ML 워크로드로 동시성 보장을 확장합니다. 여기서 여러 작성자와 판독기가 공유 데이터 세트에서 작동합니다. 낙관적 동시성 제어, 스냅샷 격리 및 자동 충돌 해결을 결합함으로써 최신 레이크하우스 플랫폼은 데이터베이스 등급 트랜잭션의 안정성을 클라우드 데이터 레이크의 규모와 유연성에 제공합니다.

복잡성 없이 동시성 제어: Databricks의 처리 방식

동시성 제어 이론을 이해하는 것은 한 가지 과제입니다. 분산 데이터, 여러 작성자 및 다양한 워크로드에 걸쳐 이를 안정적으로 구현하는 것은 또 다른 과제입니다. 자체 동시성 전략을 관리하는 팀은 격리 수준 구성, 잠금 동작 조정 및 재시도 로직 구축에 상당한 엔지니어링 시간을 소비합니다. 이는 실제 작업을 앞으로 나아가게 하지 못하는 시간입니다.

Databricks Lakebase는 이러한 운영 부담을 제거합니다. Databricks Data Intelligence Platform을 기반으로 하는 Lakebase는 팀이 동시성 제어를 직접 구현하거나 구성할 필요 없이 레이크하우스에 트랜잭션 안정성을 제공하는 완전 관리형 클라우드 네이티브 데이터베이스입니다. 즉시 사용 가능하며, 낙관적 동시성 제어, 읽기를 위한 스냅샷 격리 및 쓰기를 위한 쓰기 직렬화 가능 격리를 제공합니다. 이는 이 문서에서 다루는 메커니즘과 동일하며 자동으로 적용됩니다.

Lakebase는 Delta Lake에서 낙관적 동시성 제어를 사용하므로 관리할 잠금이 없고 디버깅할 교착 상태도 없습니다. 동시 쓰기는 이 가이드 앞부분에서 설명한 읽기-검증-커밋 패턴을 따릅니다. 각 트랜잭션은 최신 테이블 버전을 읽고, 새 데이터 파일을 작성하며, 커밋 시점에 충돌하는 변경 사항이 발생하지 않았는지 검증합니다. 여러 파이프라인, 사용자 또는 쿼리가 동일한 테이블에 쓸 때 Delta Lake의 행 수준 충돌 감지는 겹치지 않는 변경 사항을 자동으로 해결합니다. 이는 동시 MERGE, UPDATE 및 DELETE 작업에도 적용됩니다. 읽는 사람은 진행 중인 쓰기에 영향을 받지 않고 항상 일관된 스냅샷을 볼 수 있습니다.

이는 분석 워크로드에만 국한되지 않습니다. Lakebase는 트랜잭션 보장을 운영 워크로드, 데이터 엔지니어링, ETL 파이프라인 및 ML로 확장합니다. 이 모든 것이 동일한 플랫폼에서 이루어집니다. 레이크하우스 옆에 별도의 OLTP 데이터베이스를 유지하고 사용자 지정 통합 코드로 연결하는 대신, 팀은 단일 거버넌스 아키텍처를 통해 모든 것을 실행합니다. 데이터는 저렴한 클라우드 스토리지의 개방형 형식으로 유지되며, 트랜잭션 컴퓨팅 계층은 위에 독립적으로 실행됩니다.

결과적으로 이 문서에서 다룬 모든 동시성 제어 개념(MVCC, 낙관적 검증, 스냅샷 격리, 충돌 해결)은 Databricks에서 기본적으로 작동합니다. 팀은 동시성 전략이 아닌 데이터와 워크로드에 집중할 수 있습니다. Lakebase 살펴보기를 통해 실제 작동 방식을 확인하세요.

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