트랜잭션 데이터베이스란 무엇인가요?

트랜잭션 데이터베이스는 데이터를 읽고 쓰는 대량의 짧은 실시간 작업을 처리하도록 설계된 데이터베이스입니다. 이러한 작업은 고객 주문 처리, 계정 잔액 업데이트, 결제 제출 또는 고객 기록 수정과 같이 일상적인 비즈니스 활동을 지원하는 작지만 중요한 상호 작용을 나타냅니다. 각 상호 작용이 시스템의 상태를 변경하므로, 트랜잭션 데이터베이스는 모든 업데이트가 정확하고 완전하며 안전하게 기록되도록 보장합니다.

이러한 안정성의 핵심은 ACID 준수이며, 이는 많은 사용자나 애플리케이션이 동시에 데이터베이스에 액세스할 때도 각 트랜잭션이 예측 가능하게 작동하도록 보장하는 속성 집합입니다. 이로 인해 트랜잭션 데이터베이스는 속도, 정확성 및 일관성이 필수적인 온라인 트랜잭션 처리(OLTP) 워크로드의 기반이 됩니다.

트랜잭션 데이터베이스는 일반적으로 데이터를 완전한 레코드로 구성하는 행 지향 스토리지 모델을 사용합니다. 이 레이아웃은 개별 행을 자주 삽입, 업데이트 또는 검색하는 워크로드에 최적화되어 애플리케이션이 최소한의 오버헤드로 필요한 정확한 데이터에 액세스할 수 있도록 합니다.

이러한 특성들이 결합되어 트랜잭션 데이터베이스는 비즈니스의 현재 상태를 항상 반영해야 하는 시스템에 신뢰할 수 있는 선택이 됩니다. 소매 구매부터 은행 시스템, 빠르고 정확하며 일관된 데이터 변경에 의존하는 운영 애플리케이션에 이르기까지 모든 것을 지원합니다.

트랜잭션 데이터베이스 작동 방식

트랜잭션 수명 주기

트랜잭션은 처음부터 끝까지 안정적으로 처리되어야 하는 단일 논리적 작업 단위를 나타냅니다. 트랜잭션에 여러 단계가 포함되어 있더라도 데이터베이스는 전체 시퀀스를 하나의 작업으로 처리합니다. 수명 주기는 일반적으로 세 가지 단계로 구성됩니다.

1. 시작: 애플리케이션이 새 트랜잭션이 시작됨을 알립니다.
2. 작업 실행: 트랜잭션은 INSERT, UPDATE 또는 DELETE와 같은 하나 이상의 데이터 수정 문을 수행합니다.
3. 커밋 또는 롤백: 모든 작업이 성공적으로 완료되면 트랜잭션이 커밋되고 변경 사항이 영구적으로 적용됩니다. 단계 중 하나라도 실패하면 데이터베이스는 전체 트랜잭션을 이전 상태로 롤백합니다.

이러한 전부 또는 전무(all-or-nothing) 동작은 데이터 불일치를 초래할 수 있는 부분적인 업데이트를 방지합니다. 예를 들어, 은행 송금은 하나의 트랜잭션의 일부로 두 계정을 함께 업데이트합니다. 데이터베이스는 시스템이 절반만 적용된 상태로 끝나지 않도록 보장합니다.

행 기반 스토리지

트랜잭션 데이터베이스는 일반적으로 각 행이 단일 레코드의 모든 필드를 포함하는 행 지향 스토리지 모델을 사용합니다. 이 레이아웃은 데이터베이스가 단일 작업으로 전체 행을 검색하거나 업데이트할 수 있으므로 개별 레코드를 자주 읽거나 수정하는 워크로드에 최적화되어 있습니다.

이 설계는 데이터를 열별로 구성하고 몇 가지 속성에 걸쳐 대량의 데이터를 스캔하는 분석 워크로드에 최적화된 열 기반 스토리지와 대조됩니다. 열 기반 시스템은 집계 및 대규모 쿼리에 뛰어나지만, 트랜잭션 시스템에서 흔히 발생하는 작고 빈번한 읽기/쓰기 작업에는 효율성이 떨어집니다.

행 기반 스토리지는 OLTP 패턴과 자연스럽게 일치합니다. 예를 들어, 애플리케이션은 주문, 고객 프로필 또는 계정과 같은 완전한 레코드를 신속하게 가져오거나 업데이트해야 하는 경우가 많습니다. 데이터를 완전한 행으로 저장함으로써 트랜잭션 데이터베이스는 I/O를 최소화하고 실시간 작업에 빠른 성능을 제공합니다.

ACID 속성 설명

트랜잭션 데이터베이스는 원자성, 일관성, 고립성, 지속성이라는 네 가지 보장에 의존하며, 이를 통칭하여 ACID 속성이라고 합니다. 이러한 보장은 높은 동시성 또는 시스템 장애 상황에서도 모든 트랜잭션이 안전하고 예측 가능하게 처리되도록 보장합니다.

원자성

원자성은 트랜잭션이 단일하고 분할할 수 없는 작업 단위로 처리되도록 보장합니다. 트랜잭션에 여러 단계가 포함되어 있더라도 데이터베이스는 모든 단계를 적용하거나 아무것도 적용하지 않아야 합니다. 일부 변경은 성공하고 다른 변경은 실패하는 시나리오는 없습니다. 트랜잭션 내의 어떤 작업에서 오류가 발생하면 데이터베이스는 일관된 상태를 유지하기 위해 전체 변경 집합을 롤백합니다.

예를 들어, 주문 생성과 재고 업데이트는 함께 이루어져야 합니다. 시스템은 항목 수를 줄이지 않고 주문을 기록해서는 안 됩니다.

일관성

일관성은 모든 트랜잭션이 데이터베이스를 하나의 유효한 상태에서 다른 유효한 상태로 이동시키도록 보장합니다. 트랜잭션이 커밋되기 전에 모든 규칙, 제약 조건 및 데이터 무결성 요구 사항이 충족되어야 합니다. 트랜잭션이 중복 기본 키 삽입 또는 외래 키 관계 위반과 같은 제약 조건을 위반하는 경우, 데이터베이스는 해당 트랜잭션을 거부하고 변경 사항을 롤백합니다.

이는 데이터베이스가 항상 정의된 구조 및 비즈니스 규칙을 준수하는 데이터를 반영하도록 보장합니다. 어떤 트랜잭션도 유효하지 않거나 모순되는 정보를 도입할 수 없습니다.

고립성

고립성은 동시 트랜잭션이 서로 간섭하지 않도록 보장합니다. 많은 트랜잭션이 동시에 실행될 때도 각 트랜잭션은 마치 단독으로 실행되는 것처럼 작동해야 합니다. 한 트랜잭션에 의해 이루어진 커밋되지 않은 변경 사항은 해당 트랜잭션이 커밋될 때까지 다른 트랜잭션에 보이지 않아야 합니다.

이는 더티 읽기, 손실된 업데이트 또는 일관되지 않은 중간 상태와 같은 문제를 방지합니다. 다양한 데이터베이스는 여러 메커니즘과 격리 수준을 통해 고립성을 구현하지만, 핵심 아이디어는 동일합니다. 즉, 동시 활동이 정확성을 손상시켜서는 안 됩니다.

지속성

지속성은 트랜잭션이 커밋되면 해당 변경 사항이 영구적임을 보장합니다. 시스템 장애, 정전 또는 충돌이 발생하더라도 데이터는 지속되어야 합니다. 데이터베이스는 write-ahead logging, 체크포인트 및 중복 스토리지와 같은 기술을 통해 지속성을 달성합니다. 트랜잭션이 커밋된 것으로 확인되면 시스템은 그 효과가 이후의 모든 장애에서도 유지되도록 보장합니다.

동시성 제어 및 복구

트랜잭션 데이터베이스는 동시에 발생하는 많은 작업을 처리하면서도 데이터 손상이나 손실로부터 데이터를 보호해야 합니다. 동시성 제어는 동시 읽기 및 쓰기가 서로 간섭하지 않도록 보장하며, 복구 메커니즘은 시스템이 실패하더라도 데이터가 손상되지 않도록 보장합니다. 이 모든 것이 결합되어 트래픽이 많은 애플리케이션이 실제 환경에서 안전하게 작동할 수 있도록 합니다.

동시 액세스 관리

여러 사용자 또는 프로세스가 동시에 데이터베이스와 상호 작용할 때, 그들의 작업이 충돌하는 것을 허용해서는 안 됩니다. 데이터베이스는 공유 데이터에 대한 액세스를 조정하기 위해 잠금 전략과 격리 수준을 사용합니다. 잠금은 한 번에 하나의 트랜잭션만 데이터 조각을 수정할 수 있도록 보장하며, 격리 수준은 커밋되지 않은 변경 사항이 다른 트랜잭션에 얼마나 보이는지를 결정합니다.

이러한 제어가 없으면 여러 문제가 발생할 수 있습니다. 더티 읽기는 한 트랜잭션이 다른 트랜잭션의 커밋되지 않은 데이터를 볼 때 발생합니다. 손실된 업데이트는 두 트랜잭션이 서로의 변경 사항을 덮어쓸 때 발생합니다. 팬텀 읽기는 쿼리 중에 다른 트랜잭션에 의해 새 행이 삽입되거나 삭제되어 결과가 예기치 않게 변경될 때 나타납니다.

실질적으로 동시성 제어는 트래픽이 많은 전자상거래 결제에서 고객에게 이중 청구하는 것을 방지하거나 은행 앱이 일관되지 않은 계정 잔액을 표시하는 것을 막습니다. 공유 데이터에 대한 액세스를 조정함으로써 데이터베이스는 높은 부하에서도 각 트랜잭션이 예측 가능하게 작동하도록 보장합니다.

충돌 복구

잘 설계된 시스템도 장애를 겪을 수 있으므로, 트랜잭션 데이터베이스는 충돌 후 일관된 상태를 복원하는 메커니즘을 포함합니다. 가장 일반적인 접근 방식은 write-ahead logging (WAL)이며, 이는 모든 변경 사항이 데이터베이스에 적용되기 전에 로그에 기록되는 방식입니다. 이는 시스템이 항상 발생해야 했던 일에 대한 신뢰할 수 있는 기록을 가지고 있도록 보장합니다.

장애가 발생하면 데이터베이스는 로그를 재생하여 커밋된 트랜잭션을 복구하고 불완전했던 트랜잭션은 롤백합니다. 이 프로세스는 데이터베이스가 유효하고 완전히 처리된 변경 사항만 반영하도록 보장합니다.

지속성은 이러한 복구 메커니즘이 함께 작동하는 것에 달려 있습니다. WAL, 트랜잭션 로그 및 신중한 재생 로직을 결합함으로써 데이터베이스는 커밋된 데이터가 예기치 않은 중단에도 지속되도록 보장합니다.

트랜잭션 데이터베이스 vs. 분석 데이터베이스

트랜잭션 및 분석 데이터베이스는 근본적으로 다른 워크로드를 위해 설계되었습니다. 트랜잭션 시스템은 개별 레코드에 대한 빠르고 안정적인 업데이트에 중점을 두는 반면, 분석 시스템은 데이터를 스캔하고 집계하는 대규모 쿼리에 중점을 둡니다. 이러한 시스템이 어떻게 다른지 이해하면 대부분의 조직이 두 가지를 모두 사용하는 이유를 명확히 하는 데 도움이 됩니다. 하나는 실시간 활동을 캡처하고 다른 하나는 시간 경과에 따른 추세를 분석하는 데 사용합니다.

트랜잭션 데이터베이스

트랜잭션 데이터베이스는 많은 짧은 실시간 읽기/쓰기 작업을 지원합니다. 개별 레코드에 대한 낮은 지연 시간 액세스에 최적화되어 있어 비즈니스의 현재 상태를 항상 반영해야 하는 애플리케이션에 이상적입니다. OLTP 시스템은 일반적으로 행 지향 스토리지를 사용하여 데이터베이스가 완전한 레코드를 효율적으로 검색하거나 업데이트할 수 있도록 합니다.

이러한 시스템은 데이터 속도를 우선시합니다. 따라서 가능한 한 빠르고 안전하게 변경 사항을 캡처하고 적용하는 데 탁월합니다. 예시로는 주문 처리, 재고 업데이트, 사용자 프로필 변경 및 금융 거래가 있습니다.

분석 데이터베이스

분석 데이터베이스는 대규모 데이터셋에서 작동하는 더 적고 복잡한 쿼리를 위해 구축됩니다. 개별 레코드에 초점을 맞추기보다, 온라인 분석 처리(OLAP) 시스템은 집계, 추세 분석 및 과거 보고를 지원합니다. 이러한 시스템은 일반적으로 컬럼 지향 스토리지를 사용하여 엔진이 수백만 또는 수십억 개의 행에 걸쳐 특정 속성을 높은 처리량으로 스캔할 수 있도록 합니다.

OLAP 시스템은 데이터 볼륨을 우선시합니다. 따라서 OLAP 시스템의 장점 중 하나는 대량의 과거 또는 배치 로드된 데이터를 효율적으로 처리할 수 있다는 것입니다. 일반적으로 대시보드, 예측 모델, 비즈니스 인텔리전스 도구 및 대규모 분석 워크로드에 사용됩니다.

OLTP 및 OLAP 시스템 간의 관계

이러한 시스템은 상호 배타적이지 않습니다. 대부분의 조직에서는 트랜잭션 데이터가 분석 시스템으로 지속적으로 또는 주기적으로 복제됩니다. 이러한 분리를 통해 운영 애플리케이션은 빠르고 반응성을 유지하면서, 분석 워크로드는 실시간 성능에 영향을 주지 않고 독립적으로 실행될 수 있습니다.

아래 표는 OLTP 및 OLAP 시스템이 내부적으로 어떻게 다른지, 그리고 조직이 왜 두 시스템 모두에 의존하는지를 여러 차원에서 비교하여 보여줍니다. 여기에는 각 시스템이 처리하기에 가장 적합한 워크로드 유형과 몇 가지 중요한 아키텍처적 차이점이 포함됩니다.

트랜잭션 데이터베이스 vs. 관계형 데이터베이스

관계형 데이터베이스와 트랜잭션 데이터베이스는 종종 함께 논의되지만, 시스템의 다른 측면을 설명합니다. 관계형 데이터베이스는 데이터 모델로 정의됩니다. 즉, 행과 열로 구성된 테이블, 관계를 강제하는 키, 데이터 저장 방식을 구성하는 구조화된 스키마로 정의됩니다. 반면 트랜잭션 데이터베이스는 높은 볼륨의 실시간 읽기/쓰기 작업을 강력한 ACID 보장과 함께 처리하도록 최적화된 기능으로 정의됩니다.

핵심적인 차이점은 간단합니다. “관계형”은 데이터가 어떻게 구조화되는지를 설명하고, “트랜잭션”은 데이터베이스의 기능을 설명합니다. 시스템은 설계 및 워크로드에 따라 트랜잭션이 아니면서 관계형일 수도 있고, 관계형이 아니면서 트랜잭션일 수도 있으며, 둘 다일 수도 있습니다.

관계형 데이터베이스

관계형 데이터베이스는 테이블 형식 모델을 사용하여 데이터와 엔터티 간의 관계를 나타냅니다. 이 구조는 제약 조건을 적용하고, 참조 무결성을 유지하며, SQL을 사용하여 데이터를 쿼리하는 것을 쉽게 만듭니다. MySQL, PostgreSQL, Oracle 및 SQL Server와 같은 시스템은 모두 데이터를 테이블에 저장하고 스키마에 의존하여 데이터가 구성되는 방식을 정의하므로 관계형입니다.

대부분의 관계형 데이터베이스는 트랜잭션 워크로드도 지원하며, 이 때문에 용어가 때때로 혼동되기도 합니다. 그러나 관계형이라는 것이 본질적으로 시스템을 트랜잭션으로 만드는 것은 아니며, 단지 데이터가 어떻게 구조화되는지를 정의할 뿐입니다.

트랜잭션 데이터베이스

트랜잭션 데이터베이스는 많은 짧은 실시간 작업을 안전하고 효율적으로 처리하도록 구축됩니다. 이들은 낮은 지연 시간의 읽기 및 쓰기를 우선시하고, ACID 속성을 강제하며, 높은 동시성 환경에서도 각 변경 사항이 예측 가능하게 적용되도록 보장합니다. 많은 트랜잭션 시스템이 관계형이지만, 이 범주는 더 넓습니다.

MongoDB, CockroachDB 및 ScyllaDB를 포함한 여러 NoSQL 데이터베이스도 ACID 트랜잭션을 지원합니다. 이러한 시스템은 관계형 모델을 사용하지 않을 수 있지만, 안정적인 OLTP에 필요한 보장을 여전히 제공합니다.

트랜잭션 데이터베이스의 주요 이점

트랜잭션 데이터베이스는 실시간 비즈니스 운영을 안전하고 효율적으로 지원하도록 설계되었습니다. 이들의 아키텍처와 보장은 높은 부하에서도 개별 레코드에 대한 일관되고 신뢰할 수 있는 업데이트가 필요한 애플리케이션에 매우 적합합니다. 아래의 이점들은 이러한 시스템이 OLTP의 기반으로 남아있는 이유를 강조합니다.

데이터 무결성

ACID 준수는 모든 트랜잭션이 완전하고 정확하게 적용되도록 보장합니다. 이는 부분 쓰기, 충돌하는 업데이트 및 기타 형태의 데이터 손상을 방지합니다. ACID 속성을 강제함으로써 트랜잭션 데이터베이스는 비즈니스 활동의 정확하고 신뢰할 수 있는 기록을 유지합니다.

신뢰성

내장된 복구 메커니즘은 데이터베이스 시스템이 충돌이나 예기치 않은 오류로부터 깨끗하게 복구할 수 있도록 합니다. WAL 및 트랜잭션 재생과 같은 이러한 기능은 커밋된 데이터가 보존되고 불완전한 작업이 롤백되어 데이터베이스가 일관된 상태를 유지하도록 보장합니다.

실시간 성능

트랜잭션 데이터베이스는 개별 읽기 및 쓰기 작업에서 밀리초 수준의 응답 시간을 위해 최적화되어 있습니다. 이는 주문 처리, 계정 업데이트 또는 재고 변경과 같이 최신 상태를 즉시 반영해야 하는 애플리케이션에 이상적입니다.

동시 액세스

트랜잭션 시스템은 또한 충돌 없이 수천 명의 동시 사용자를 지원하도록 설계되었습니다. 동시성 제어 메커니즘은 공유 데이터에 대한 액세스를 조정하여, 많은 작업이 동시에 발생하더라도 각 트랜잭션이 예측 가능하게 작동하도록 보장합니다.

감사 가능성

포괄적인 트랜잭션 로그는 변경 사항에 대한 완전한 기록을 제공합니다. 이러한 로그는 규정 준수 요구 사항을 지원하고, 디버깅을 단순화하며, 예기치 않은 동작이나 시스템 문제를 조사할 때 포렌식 분석을 가능하게 합니다.

일반적인 제한 사항

트랜잭션 데이터베이스는 실시간 작업에 최적화되어 있지만, 동일한 설계 선택은 워크로드가 분석, 대규모 조인 또는 빠른 스키마 진화로 전환될 때 제약을 초래할 수 있습니다. 이러한 시스템은 빠른 지점 수준 읽기 및 쓰기를 위해 구축되었기 때문에 대규모 데이터셋을 스캔하거나 집계하는 분석 쿼리에 어려움을 겪습니다. 수백만 행 집계 또는 광범위한 과거 분석과 같은 작업은 스토리지 엔진에 과부하를 주어 운영 워크로드를 느리게 만들 수 있습니다.

또한, 엄격한 스키마는 변경 비용을 높입니다. 데이터 무결성을 강제하는 테이블, 제약 조건 및 잘 정의된 관계는 열을 추가하거나, 제약 조건을 수정하거나, 관계를 재설계할 때 신중한 계획을 필요로 합니다. 마이그레이션은 다운타임이나 불일치를 피하기 위해 조정되어야 하며, 이는 데이터 모델이 진화함에 따라 민첩성을 제한할 수 있습니다.

쿼리가 조인에 크게 의존할 때도 성능 문제가 발생합니다. 트랜잭션 데이터베이스는 조인을 실행할 수 있지만, 데이터셋이 커짐에 따라 깊거나 빈번한 다중 테이블 조인은 I/O 및 잠금 경합을 증가시킵니다. 이는 대규모에서 조인 중심의 분석 워크로드를 비실용적으로 만들며, 특히 실시간 작업과 경쟁할 때 더욱 그렇습니다.

확장은 또 다른 제한 사항을 야기합니다. 대부분의 트랜잭션 엔진은 단일 노드에 더 많은 CPU, 메모리 또는 스토리지를 추가하여 수직적으로 확장됩니다. 수평 확장이 가능하지만, 처음부터 분산 작업을 위해 설계된 NoSQL 시스템보다 훨씬 더 복잡합니다. 트래픽 또는 데이터셋 크기가 증가함에 따라 이러한 아키텍처 제약은 더욱 제한적이 됩니다.

조직이 분석 작업을 읽기 복제본으로 오프로드하더라도 트랜잭션 엔진은 결국 성능 한계에 도달합니다. 복제본은 여전히 행 지향 스토리지와 기본 시스템과 동일한 실행 모델에 의존하므로, 운영 성능에 영향을 주지 않고 대규모 분석 워크로드를 효율적으로 처리하는 능력이 제한됩니다.

사용 사례 및 데이터베이스 예시

일반적인 사용 사례

트랜잭션 데이터베이스는 정확성, 속도 및 일관성이 필수적인 광범위한 운영 시스템을 지원합니다. 은행 및 금융 서비스에서는 이체, 결제 및 실시간 계정 업데이트를 지원하여 모든 변경 사항이 안정적으로 기록되도록 합니다. 전자상거래 플랫폼은 주문 처리, 재고 관리 및 결제 흐름을 위해 트랜잭션 데이터베이스에 의존하며, 각 작업은 즉시 반영되어야 합니다.

의료 시스템은 환자 기록, 예약 일정 및 청구를 관리하기 위해 트랜잭션 데이터베이스를 사용하며, 이 모든 것은 엄격한 무결성과 최신 정보를 요구합니다. 항공사, 호텔 및 이벤트의 예약 시스템은 이중 예약을 방지하고 정확한 가용성을 유지하기 위해 트랜잭션 보장에 의존합니다. 통신 제공업체는 통화 기록을 추적하고, 가입자 데이터를 관리하며, 대규모 청구 작업을 지원하기 위해 이를 사용합니다.

인기 있는 트랜잭션 데이터베이스

다양한 데이터베이스 엔진이 트랜잭션 워크로드를 지원합니다. 관계형 시스템 중에서는 MySQL, PostgreSQL, Oracle Database, Microsoft SQL Server 및 IBM Db2가 성숙한 ACID 구현과 강력한 에코시스템 지원으로 널리 사용됩니다. MongoDB, CockroachDB, Amazon DynamoDB 및 ScyllaDB를 포함한 여러 NoSQL 데이터베이스도 트랜잭션 보장을 제공하여, 데이터 모델의 유연성을 제공하면서도 안정적인 다중 작업 업데이트를 지원합니다.

Amazon Aurora, Google Cloud SQL, Azure SQL Database 및 Cloud Spanner와 같은 클라우드 관리 서비스는 자동 확장, 고가용성 및 관리형 운영으로 이러한 기능을 확장하여, 기본 인프라를 유지 관리할 필요 없이 트랜잭션 워크로드를 더 쉽게 실행할 수 있도록 합니다. Databricks에서 애플리케이션을 구축하는 팀의 경우, Databricks 앱을 위한 트랜잭션 데이터 계층으로 Lakebase를 사용하는 방법을 참조하십시오.

워크로드에 적합한 데이터베이스 선택

트랜잭션 데이터베이스는 개별 레코드에 대한 빠르고 안정적인 업데이트가 필요한 애플리케이션에 필수적입니다. ACID 보장, 실시간 성능, 그리고 수많은 동시 사용자를 지원하는 능력 덕분에 트랜잭션 데이터베이스는 모든 산업 분야의 운영 시스템에서 중추적인 역할을 합니다. 동시에 분석 워크로드, 스키마 진화 및 수평 확장에 대한 아키텍처 제약은 기업이 대규모 분석을 위해 설계된 시스템과 트랜잭션 데이터베이스를 함께 사용하는 이유를 보여줍니다. 관계형 및 트랜잭션 모델의 차이점과 트랜잭션 엔진의 특정 강점 및 한계를 이해하면 팀이 각 워크로드에 적합한 데이터베이스를 선택하고 무결성, 성능 및 장기적인 확장성을 균형 있게 유지하는 아키텍처를 구축하는 데 도움이 될 것입니다. 통합 데이터 아키텍처 내에서 트랜잭션 워크로드를 실행하려는 팀을 위해, Databricks Lakebase는 Databricks Platform 내에 운영 데이터베이스를 제공하며 lakehouse와 통합됩니다.

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