Synapse에서 Databricks로의 마이그레이션 탐색하기

Azure Synapse는 대규모 SQL 분석을 위한 신뢰할 수 있는 기반 역할을 해왔으며, 이를 기반으로 구축한 팀들은 당시로서는 현명한 선택을 한 것이었습니다. 하지만 주로 데이터 웨어하우스 중심으로 설계된 플랫폼은 현재 데이터 팀이 제공해야 하는 모든 요구사항을 충족하도록 구축되지 않았습니다. 이러한 격차를 메우려면 대개 더 많은 서비스, 통합 및 운영 오버헤드가 추가되며, 이는 시간이 지남에 따라 누적됩니다.

Databricks로 마이그레이션하는 것은 이 문제를 해결하는 한 가지 방법입니다. 이 블로그에서는 Synapse 마이그레이션에 접근하는 방법과 실행 시 유의해야 할 사항에 대해 설명합니다.

Synapse 마이그레이션이 제공하는 이점

고객들과 함께 진행한 Synapse 마이그레이션 프로젝트 전반에서 다음과 같은 세 가지 비즈니스 동기가 일관되게 나타납니다.

1. 통합된 데이터 자산. 데이터 플랫폼이 성장함에 따라 관련 서비스의 수도 늘어납니다. 예를 들어, Synapse Analytics 풀은 특정 워크로드를 처리하고, Spark 풀은 다른 워크로드를 처리하며, 서버리스 SQL은 임시(ad hoc) 액세스를 제공합니다. Azure Data Factory는 종종 이들과 함께 작동하여 모든 것을 오케스트레이션합니다. 또한 많은 조직에는 여전히 지원해야 하는 레거시 SSIS 워크로드가 있습니다. 이러한 구성 요소 중 어느 것도 개별적으로는 문제가 되지 않습니다. 하지만 추가 서비스가 도입되면 거버넌스, 모니터링, 권한 관리 및 운영 오버헤드가 한층 더 추가되면서 문제가 발생합니다.
   Databricks는 데이터 엔지니어링, 분석, 머신러닝 및 거버넌스를 단일 플랫폼으로 통합하여 이 문제를 해결합니다. 팀은 서로 다른 운영 모델을 가진 서비스 간에 이동하는 대신, 동일한 기본 아키텍처와 거버넌스 프레임워크를 바탕으로 작업할 수 있습니다. 그 결과 복잡성이 줄어들고, 통합 포인트가 감소하며, 대규모로 운영하기가 더 쉬운 플랫폼이 구축됩니다.
2. 미래 대비. 현대 데이터 팀의 초점은 이제 머신러닝 모델, 실시간 데이터 파이프라인 및 AI 기반 애플리케이션 지원으로 이동했습니다. 이러한 모든 워크로드는 동일한 기본 데이터에 의존합니다. 문제는 기존의 데이터 웨어하우스 중심 아키텍처가 이러한 수준의 융합을 위해 설계되지 않았으며 주로 BI 요구사항을 대상으로 했다는 점입니다. 요구사항이 확장됨에 따라 조직은 기능 격차를 메우기 위해 더 많은 서비스와 전문 도구를 추가하게 되는 경우가 많습니다.
   Databricks는 이러한 융합을 위해 구축되었으며 데이터, 분석 및 AI를 단일 플랫폼으로 통합합니다. Unity Catalog는 데이터, 노트북 및 AI/ML 자산 전반에 걸쳐 일관된 거버넌스를 제공하고, Unity AI Gateway는 이러한 제어 기능을 모델, 에이전트 및 AI 애플리케이션으로 확장하므로, 조직은 새로운 거버넌스 사일로를 추가하지 않고도 새로운 AI 워크로드를 도입할 수 있습니다.
3. 운영 효율성. 대부분의 마이그레이션 비즈니스 케이스는 라이선스 비용에서 시작하지만, 가장 큰 비용 절감이 발생하는 곳은 거의 라이선스 비용이 아닙니다. 더 큰 영향은 팀이 운영하고 지원해야 하는 시스템의 수를 줄이는 데서 오는 경우가 많습니다. 서비스가 적을수록 통합이 줄어들고, 도구 간의 핸드오프가 줄어들며, 잠재적인 문제가 줄어듭니다.

이미 마이그레이션을 마친 조직들은 실질적인 성과를 거두고 있습니다. 예를 들어, 미국의 3대 편의점 체인인 Casey's는 분석 환경을 Synapse에서 Databricks Lakehouse(이전의 Databricks SQL)로 마이그레이션하여 운영 데이터 제공 시간을 8시간에서 4시간으로 단축했습니다. 또 다른 예로, Italgas는 Synapse와 Azure Analysis Services를 모두 제거하여 아키텍처를 단순화했습니다. 이 회사는 Databricks에서 직접 Power BI와 AI 기반 분석을 모두 지원하면서 워크로드 비용을 73% 절감했다고 보고했습니다.

세부 사항은 조직마다 다르지만, 더 단순한 아키텍처, 더 빠른 데이터 제공, 현대 데이터 팀의 요구사항에 더 잘 부합하는 플랫폼이라는 일관된 패턴이 나타납니다.

실제로 마이그레이션하는 대상 이해하기

Synapse 마이그레이션 초기에 팀들이 종종 예상치 못하게 당황하는 부분은 마이그레이션 대상의 범위입니다. Azure Synapse는 흔히 단일 플랫폼으로 간주되지만, 실제로는 하나의 브랜드 아래에서 운영되는 다양한 개별 서비스로 구성되어 있으며, 각 서비스는 서로 다른 마이그레이션 전략이 필요하고 복잡성 수준도 다릅니다.

대부분의 마이그레이션에서는 비즈니스 로직, 저장 프로시저, 분산 전략, 인덱싱 결정 및 성능 최적화가 수년에 걸쳐 축적된 Dedicated SQL Pools에 대부분의 노력을 투입합니다. 하지만 복잡성은 SQL에서 끝나지 않습니다. 동일한 마이그레이션에서 오케스트레이션(Azure Data Factory 및 Synapse Pipelines), 권한 및 거버넌스(SQL 권한 및 Microsoft Purview, 리니지는 종종 수동으로 연결됨), BI 및 서드파티 연결(Synapse 엔드포인트에 직접 연결된 시맨틱 모델, 보고서 및 다운스트림 도구)을 고려해야 하는 경우가 많습니다. 이 부분은 가장 많은 재설계, 테스트 및 검증이 필요한 자산 영역이며, 가장 과소평가되기 쉬운 부분이기도 합니다.

Serverless SQL Pools는 주로 데이터 레이크의 파일에 대한 쿼리 레이어를 제공하므로 일반적으로 더 간단합니다. 여기서 마이그레이션은 복잡한 워크로드를 재설계하는 것이 아니라 주로 뷰, 외부 테이블 및 액세스 패턴을 재설정하는 것입니다. Spark Pools는 이동하기 가장 간단한 구성 요소인데, Synapse Spark와 Databricks 모두 Apache Spark를 기반으로 구축되었으며 노트북은 비교적 적은 변경만으로 마이그레이션할 수 있는 경우가 많기 때문입니다.

중요한 점은 이러한 구성 요소가 서로 다른 속도로 이동하고, 서로 다른 이해관계자가 관여하며, 서로 다른 리스크를 수반한다는 것입니다. 마이그레이션을 단일 일정의 단일 워크스트림으로 접근하는 조직은 노력과 복잡성을 모두 과소평가하는 경우가 많습니다. 이로 인해 일정이 지연되고 마이그레이션 프로그램이 원래 범위를 벗어나 확장되기 시작합니다. 성공적으로 마이그레이션하려면 팀은 마이그레이션 여정을 구조화해야 합니다.

마이그레이션 구조화 방법

Synapse에서 Databricks로의 마이그레이션은 단일 워크스트림이 아닙니다. 세 가지 서로 다른 컴퓨팅 모델을 이동하고, 거버넌스를 통합하며, 오케스트레이션을 현대화하고, 수년간 축적된 T-SQL 로직을 재작업해야 합니다. 이를 잘 처리하는 팀은 이를 단순한 기술 프로젝트가 아니라 단계별 접근 방식을 갖춘 구조화된 프로그램으로 취급합니다.

현황 파악(Discovery). 모든 마이그레이션은 실제로 무엇이 실행되고 있는지 이해하는 것에서 시작합니다. Lakebridge Profiler는 Synapse 자산을 스캔하고 구성, 리소스 사용률, 쿼리 패턴 및 성능 기준선에 대한 메타데이터를 수집합니다. 출력 결과는 TCO 사례를 구축하는 데 사용됩니다.

평가(Assessment). 인벤토리가 확보되면 다음 단계는 복잡성을 이해하는 것입니다. Lakebridge Analyzer는 T-SQL 코드베이스를 평가하여 모든 개체를 복잡성별로 분류하고, 지원되지 않는 구문을 플래깅하며, 종속성을 매핑합니다. 출력 결과는 마이그레이션 일정 및 관련 노력을 평가하고 자산 마이그레이션의 우선순위를 정의하는 데 사용할 수 있습니다. 쉽게 해결할 수 있는 과제(low hanging fruits)인 저복잡성 및 중간 복잡성 워크로드부터 시작한 다음, 가장 중요한 사용 사례에 대한 계획을 세우세요.

설계(Design). 자산에 대한 가시성이 확보되면 아키텍처와 설계로 관심이 이동합니다. 첫 번째는 접근 방식입니다. lift-and-shift(리프트 앤 시프트), 현대화 또는 하이브리드 중 선택합니다. 대부분의 Synapse 마이그레이션의 경우 하이브리드가 올바른 답입니다. 자동화된 도구가 코드 변환의 대부분을 처리하여 일정에 맞춰 Synapse에서 벗어날 수 있도록 하며, 현대화는 워크로드가 Databricks에서 실행된 후 점진적으로 진행됩니다.

두 번째 결정은 순서 지정입니다. BI 우선 접근 방식은 ETL로 시작하는 것보다 더 빠르게 모멘텀을 구축하는 경향이 있습니다. Lakehouse Federation을 사용하면 기본 파이프라인이 이동하기 전에 Unity Catalog를 통해 Synapse 데이터를 노출할 수 있습니다. 시작하는 실용적인 방법은 비즈니스 지향적인 확장 데이터(데이터 마트)를 Databricks에 먼저 배치한 다음, 자연어 분석을 지원하는 Genie를 통해 비즈니스 사용자에게 직접 제공하는 것입니다. 비즈니스 이해관계자는 진행 상황과 가치를 조기에 확인할 수 있으며, 엔지니어링 팀은 그 아래에 있는 더 복잡한 ETL을 현대화할 수 있습니다. 귀사에 적합한 마이그레이션 접근 방식을 정의하려면 블로그 게시물을 읽어보세요.

파일럿(Pilot). 규모를 확장하기 전에 실제 워크로드를 대상으로 마이그레이션 전략을 엔드투엔드로 검증해야 합니다. 하나의 등대(lighthouse) 사용 사례를 선택하여 수집부터 소비까지 마이그레이션하고 프로덕션으로 전환하세요. 파일럿은 실제 조건에서 아키텍처, 거버넌스 모델, 테스트 절차 및 도구를 검증하고, 이후 진행될 단계(wave)를 위해 재사용 가능한 자산을 생성합니다.

단계별 마이그레이션(Migration in waves). 확장 단계에서는 단계별(wave) 마이그레이션을 권장합니다. 각 단계는 눈에 보이는 비즈니스 성과를 제공하도록 설계되었으며 최종 사용자와의 피드백 루프를 구축합니다.

실행은 일반적으로 네 개의 병렬 작업 스트림으로 진행됩니다. 수집(ADF 및 Synapse Pipeline 워크로드를 Lakeflow Connect로 이동), 변환(T-SQL 프로시저 및 비즈니스 로직을 Databricks로 마이그레이션), 오케스트레이션(일정 및 종속성을 Databricks Workflows로 이동), 소비(BI 도구 및 시맨틱 모델을 Databricks SQL Warehouses로 재지정)가 이에 해당합니다. 이를 병렬로 실행하면 팀이 가치를 조기에 제공하고 예측 가능한 일정에 따라 Synapse 사용을 중단할 수 있습니다.

Databricks는 다양한 각도에서 Synapse 마이그레이션을 지원합니다. 당사의 Forward Deployed Engineering 팀의 자문 및 제공, 인증된 Brickbuilder 파트너, 그리고 번거로운 작업을 자동화하는 Lakebridge와 같은 액셀러레이터가 있습니다. 목표는 단순히 마이그레이션을 완료하는 것이 아니라, 프로젝트가 끝난 후에도 팀이 플랫폼을 오랫동안 유지하는 데 필요한 기술을 구축하고 운영 모델을 만드는 것입니다.

데이터 수집

SQL 코드를 변환하기 전에 먼저 데이터를 레이크하우스로 수집해야 합니다. Databricks는 소스 시스템과 운영 요구 사항에 따라 몇 가지 옵션을 제공합니다.

많은 일반적인 엔터프라이즈 소스의 경우, Lakeflow Connect는 기본 제공 커넥터와 자동화된 파이프라인 관리를 통해 관리형 수집 환경을 제공합니다. 동시에 Databricks는 개방형 스토리지 형식을 기반으로 구축되어 조직에서 다양한 타사 수집 도구를 사용할 수 있습니다. Fivetran, Airbyte 및 기타 ETL/ELT 플랫폼과 같은 솔루션은 데이터를 Delta Lake로 직접 수집할 수 있으므로 고객은 단일 수집 프레임워크에 종속되지 않고 기존 데이터 통합 에코시스템과 통합할 수 있습니다.

실제 코드 변환

레이크하우스에서 데이터를 사용할 수 있게 되면 마이그레이션 작업은 코드 변환으로 전환되며, 이는 일반적으로 마이그레이션에서 가장 복잡한 단계입니다. 자동화된 도구가 변환의 대부분(일반적으로 약 80~90%)을 처리하지만, 나머지 작업은 절차적 로직을 미세 조정하고 자동으로 변환할 수 없는 패턴을 해결하는 데 소요됩니다.

다음은 Synapse 및 Databricks 구문에서 주의해야 할 몇 가지 차이점입니다.

물리적 지시어 제거

가장 일반적인 변환 패턴은 물리적 최적화 지시어(physical optimization directives)를 제거하는 것입니다. Dedicated SQL Pools는 HASH 배포, ROUND_ROBIN 배포, REPLICATE 배포 및 클러스터형 컬럼스토어 인덱스와 같은 구조에 크게 의존합니다. 이는 Synapse 성능 튜닝의 핵심이지만 Databricks에는 직접적인 대응 항목이 없으므로 일반적으로 마이그레이션 중에 생략됩니다.

대신 Databricks는 쿼리 성능을 향상시키기 위해 스토리지 최적화 및 Liquid Clustering에 의존합니다. 전자는 Delta 테이블에 대해 파일 압축, 통계 수집 및 VACUUM과 같은 유지 관리 작업을 지속적으로 수행하는 Predictive Optimization을 통해 자동으로 처리됩니다. 후자는 쿼리 성능을 향상시키기 위해 하나 이상의 클러스터링 컬럼을 사용하여 Delta 테이블 내의 데이터를 구성하는 Liquid Clustering에 의해 제공됩니다. 그러나 최적의 클러스터링 컬럼을 선택하려면 데이터가 쿼리되는 방식을 이해해야 하는데, 이는 실제로는 어려운 경우가 많고 워크로드가 발전함에 따라 자주 변경됩니다. 이러한 운영 부담을 줄이기 위해 Databricks는 관찰된 쿼리 액세스 패턴을 기반으로 클러스터링 컬럼을 자동으로 식별하고 지속적으로 미세 조정하는 CLUSTER BY AUTO를 도입했습니다. 이러한 기능들이 결합되어 Dedicated SQL Pools에 비해 필요한 수동 물리적 튜닝의 양이 크게 줄어듭니다.

Synapse에서 상당한 엔지니어링 노력이 소요되었던 물리적 설계 결정은 그냥 생략됩니다. 이전에는 수동으로 처리해야 했던 작업을 플랫폼이 알아서 처리합니다.

함수 재매핑

가장 일반적으로 사용되는 T-SQL 함수는 직접적인 Databricks 대응 항목이 있으며, Lakebridge가 대부분의 매핑을 자동으로 처리합니다.

더 흔하게 발생하는 문제의 원인은 함수 매핑 자체보다는 결과에 미묘한 영향을 미치는 동작의 차이입니다. 문자열 비교가 좋은 예입니다. Synapse Dedicated SQL Pools는 일반적으로 대소문자를 구분하지 않는 데이터 정렬(collation)로 작동하는 반면, Databricks SQL은 기본적으로 대소문자를 구분합니다. 대소문자를 구분하지 않는 일치에 암시적으로 의존하는 로직은 마이그레이션 후에 다른 결과를 반환할 수 있습니다. 필요한 경우 양쪽 모두에 LOWER() 또는 UPPER()를 사용하여 비교를 명시적으로 만들어야 합니다. 구문 변환은 대개 간단하지만, 의미론적 차이에는 더 많은 주의가 필요합니다.

저장 프로시저: 선 마이그레이션, 후 최적화

Databricks의 네이티브 저장 프로시저 지원을 통해 대부분의 Synapse 프로시저는 전체적인 구조를 그대로 유지한 채 마이그레이션할 수 있습니다. 매개변수, 변수, 조건부 로직 및 DML 작업이 모두 지원됩니다.

프로시저 자체는 문제가 되는 경우가 드뭅니다. 진짜 복잡한 부분은 그 내부에 있습니다. 커서, 행 단위 처리, 동적 SQL, Synapse 전용 성능 최적화 등이 이에 해당합니다. 이러한 패턴은 단순한 변환이 아닌 판단이 필요합니다.

SCD Type 2: Delta Lake로 이력 보존하기

느리게 변하는 차원(Slowly Changing Dimensions)은 Synapse 구현이 가장 다양한 영역 중 하나입니다. 많은 조직이 수년에 걸쳐 맞춤형 저장 프로시저와 병합 로직을 축적해 왔습니다. 마이그레이션의 목표는 해당 구현을 똑같이 재현하는 것이 아니라, 현재 상태를 쿼리할 수 있도록 유지하면서 차원 레코드의 이력 버전을 유지한다는 비즈니스 요구 사항을 보존하는 것입니다.

일반적인 Databricks 접근 방식은 두 단계를 사용합니다. 먼저 변경된 레코드를 만료시킵니다. 그런 다음 새 버전을 삽입합니다.

Delta Lake의 ACID 트랜잭션 덕분에 여러 작업이 수반되는 경우에도 이 패턴을 안전하게 사용할 수 있습니다.

오류 처리

많은 Synapse 저장 프로시저는 오류를 캡처하거나 감사 레코드를 기록하기 위해 TRY...CATCH 블록에 의존합니다. Databricks SQL은 조건 처리기(condition handler)를 통해 네이티브 대응 기능을 제공하므로 기존 패턴의 대부분을 SQL 기반으로 유지할 수 있습니다.

감사 로깅 및 제어된 실패와 같은 간단한 시나리오는 일반적으로 직접 변환됩니다. 특히 Databricks Workflows를 통한 다운스트림 조정이 포함되는 경우, 더 복잡한 워크플로우에는 추가적인 설계가 필요할 수 있습니다.

현장 경험이 주는 교훈

조직의 규모나 자산의 복잡성에 관계없이 Synapse 마이그레이션 전반에서 몇 가지 교훈이 일관되게 나타납니다.

전환이 아닌 평가부터 시작하세요. 전환 코드를 단 한 줄도 작성하기 전에 Lakebridge Profiler and Analyzer를 실행하세요. 실제 사용량, 범위, 복잡성 및 종속성을 명확히 파악하고, 해당 데이터를 활용해 가능한 부분에서 범위를 축소하세요.

적극적으로 자동화하세요. Lakebridge는 코드 전환의 80~90%를 처리합니다. 엔지니어링 시간은 커서, 동적 SQL, 복잡한 오류 처리와 같이 사람의 판단이 필요한 10~20%에 집중하세요.

검증을 절대 과소평가하지 마세요. 실제로 검증은 마이그레이션 자체보다 더 많은 노력이 드는 경우가 많습니다. 가장 효과적인 방법은 마이그레이션이 진행될 때마다 조정을 실행하여 행 수, 집계, 해시 기반 레코드 비교, 정확한 일치가 적절하지 않은 값에 대한 허용 오차 기반 검사를 비교하는 것입니다. Lakebridge Reconcile은 이 모든 차원에서 이를 지원합니다. 비즈니스 크리티컬한 워크로드의 경우, 최종 전환 전에 두 환경을 병렬로 실행하면 사용자가 익숙한 보고서로 계속 작업하는 동안 팀이 결과를 나란히 비교할 수 있습니다.

Synapse 방식의 사고방식에서 벗어나세요. 좋은 예로 테이블 디자인이 있습니다. 여러 팀에서 Synapse HASH 분산 키를 Delta Lake 파티션 열에 직접 매핑하려고 시도하는 경우가 많습니다. 대부분의 경우 이는 불필요한 복잡성을 유발하고 성능을 저하시킵니다. 고객 ID나 주문 ID와 같이 카디널리티가 높은 값은 파티션 키로 적합하지 않은 경우가 많으며, 리퀴드 클러스터링(liquid clustering) 및 예측 유지 관리와 같은 Databricks의 자동화된 최적화 기능을 통해 더 잘 처리할 수 있습니다.

이제 플랫폼이 처리하는 작업을 굳이 다시 만들지 마세요. 마이그레이션은 아키텍처를 그대로 복제하는 것이 아니라 단순화할 수 있는 기회입니다. Delta Lake, 자동화된 최적화 및 현대적인 레이크하우스 패턴은 기존 웨어하우스 환경에서 필요했던 많은 수동 튜닝 기술을 제거해 줍니다. 과거의 모든 최적화 결정을 Databricks로 그대로 가져오는 것은 흔히 제약 조건이 존재했던 이유는 남겨두지 않은 채 과거의 제약 조건만 그대로 유지하는 결과를 낳습니다.

운영 준비 상태를 갖추세요. Delta 테이블은 시간이 지남에 따라 증분 워크로드가 실행되면서 자연스럽게 작은 파일들이 누적됩니다. 압축 및 유지 관리 프로세스가 없으면 성능이 점차 저하될 수 있습니다. 기존 데이터 웨어하우스 플랫폼을 사용하던 팀들은 스토리지 최적화가 지속적인 운영 모델의 일부가 된다는 사실에 놀라곤 합니다. 관리하기가 어렵지는 않지만, 처음부터 계획을 세워야 합니다.

변화 관리를 계획하세요. 대부분의 Synapse 팀은 Databricks를 처음 접하며, 역량 강화(enablement)에 대한 투자 부족은 프로젝트가 도입 목표를 달성하지 못하는 가장 흔한 이유 중 하나입니다. 기술 계획만큼이나 역량 강화 계획도 진지하게 추진하세요.

Synapse를 너무 일찍 폐기하지 마세요. 가장 성공적인 마이그레이션 사례들을 보면 프로덕션 워크로드가 이전된 후에도 일정 기간 동안 기존 환경을 유지합니다. 예기치 않은 문제가 발생할 경우를 대비해 롤백 옵션을 유지하면서 비용을 최소화하기 위해 컴퓨트를 일시 중지할 수 있습니다. 더 중요한 것은, 이러한 안전망을 유지함으로써 새 플랫폼이 실제 사용 환경에서 성능을 입증하는 동안 비즈니스 이해관계자들에게 신뢰를 줄 수 있다는 점입니다.

Synapse에서 Databricks로 마이그레이션하는 것은 단순한 기술 프로젝트가 아닙니다. 그 핵심은 시간이 지남에 따라 점점 더 복잡해진 플랫폼을 단순화하는 동시에, 차세대 분석, AI 및 데이터 제품을 지원할 수 있는 기반을 구축하는 것입니다. 기술적인 작업도 중요하지만, 이러한 마이그레이션으로 가장 큰 이점을 누리는 조직은 이 기회를 통해 아키텍처를 단순화하고 불필요한 복잡성을 제거하며 운영 방식을 동시에 현대화하는 조직입니다. 더 큰 이점은 운영하기 더 쉽고, 확장하기 더 용이하며, 조직의 미래 방향과 더 잘 부합하는 데이터 플랫폼을 갖추게 된다는 점입니다.

다음 단계

Synapse 마이그레이션을 시작하는 단계라면:

• 사용 중인 환경에서 Lakebridge Profiler and Analyzer를 실행하세요. 작업 범위를 지정하기 전에 데이터를 먼저 확보하세요.
• 마이그레이션 전략: 교훈(Migration Strategy: Lessons Learned) 블로그와 기존 데이터 웨어하우스 혁신(Transforming Legacy Data Warehouses) eBook을 읽어보세요.
• 직접적인 도움이 필요하시다면, Databricks FDE Team 및 인증된 마이그레이션 파트너가 Synapse 마이그레이션을 처음부터 끝까지 지원해 드립니다.

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