다음을 통해 공유


데이터 도메인

데이터 메시는 기본적으로 분산과 도메인에 대한 책임 분산을 기반으로 합니다. 비즈니스의 일부를 진정으로 이해한다면 연결된 데이터를 관리하고 정확성을 보장하는 것이 가장 좋습니다. 이것이 도메인 지향 데이터 소유권의 원칙입니다.

도메인 지향 데이터 소유권을 승격하려면 먼저 데이터 아키텍처를 분해해야 합니다. 데이터 메시 설립자인 Zhamak Dehghani는 데이터 도메인을 식별하는 데 유용한 방법으로 소프트웨어 개발에 대한 DDD(Domain-Driven Design) 접근 방식을 홍보합니다.

데이터 관리에 DDD를 사용하는 데 어려움은 DDD의 원래 사용 사례가 소프트웨어 개발 컨텍스트에서 복잡한 시스템을 모델링했다는 것입니다. 원래 엔터프라이즈 데이터를 모델링하기 위해 만들어지지 않았으며 데이터 관리 실무자의 경우 해당 방법은 추상적이고 기술적일 수 있습니다. DDD에 대한 이해가 부족한 경우가 많습니다. 실무자는 개념적 개념을 파악하기가 너무 어렵거나 소프트웨어 아키텍처 또는 개체 지향 프로그래밍의 예제를 데이터 환경으로 프로젝션하려고 합니다. 이 문서에서는 DDD를 이해하고 사용할 수 있도록 실용적인 지침과 명확한 어휘를 제공합니다.

도메인 기반 디자인

Eric Evans가 소개한 Domain-Driven Design은 대규모 조직을 위한 복잡한 시스템을 설명하는 데 도움이 되는 소프트웨어 개발을 지원하는 방법입니다. DDD는 많은 고급 사례가 마이크로 서비스와 같은 최신 소프트웨어 및 애플리케이션 개발 접근 방식에 영향을 주기 때문에 인기가 있습니다.

DDD는 제한된 컨텍스트, 도메인 및 하위 도메인을 구분합니다. 도메인은 해결하려는 문제 공간입니다. 지식, 행동, 법률 및 활동이 함께 모이는 영역입니다. 도메인의 의미 체계 결합, 구성 요소 또는 서비스 간의 동작 종속성이 표시됩니다. 도메인의 또 다른 측면은 통신입니다. 팀 구성원은 모든 사람이 효율적으로 작업할 수 있도록 팀 전체가 공유하는 언어를 사용해야 합니다. 이 공유 언어를 유비쿼터스 언어 또는 도메인 언어하고도 한다.

도메인은 복잡성을 더 잘 관리하기 위해 하위 도메인으로 분해됩니다. 이 예제의 일반적인 예는 AI/ML대한 운영화 데이터 메시에 표시된 것처럼 각각 특정 비즈니스 문제에 해당하는 하위 도메인으로 도메인을 분해하는 것입니다.

모든 하위 도메인이 동일한 것은 아닙니다. 예를 들어 도메인을 핵심, 제네릭 또는 지원으로 분류할 수 있습니다. 핵심 하위 도메인이 가장 중요합니다. 그들은 조직을 독특하게 만드는 비밀 소스, 재료입니다. 제네릭 하위 도메인은 비특이적이며 일반적으로 기성품으로 쉽게 해결할 수 있습니다. 하위 도메인을 지원하는 것은 경쟁 우위를 제공하지 않지만 조직을 계속 운영하는 데 필요하며 복잡하지 않습니다.

제한된 컨텍스트는 논리적(컨텍스트) 경계입니다. 솔루션 공간인 시스템 및 애플리케이션 디자인에 중점을 줍니다. 솔루션 공간에 포커스를 맞추는 것이 적합한 영역입니다. DDD 내에서 코드, 데이터베이스 디자인 등을 포함할 수 있습니다. 도메인과 경계가 있는 컨텍스트 사이에는 정렬이 될 수 있지만, 두 가지를 함께 바인딩하는 엄격한 규칙은 없습니다. 제한된 컨텍스트는 기본적으로 기술적이며 여러 도메인 및 하위 도메인에 걸쳐 있을 수 있습니다.

도메인 모델링 권장 사항

데이터 민주화를 위한 개념으로 데이터 메시를 채택하고 유연성을 높이기 위해 도메인 지향 데이터 소유권의 원칙을 구현하는 경우 실제로 어떻게 작동하나요? 엔터프라이즈 데이터 모델링에서 도메인 기반 디자인 모델링으로의 전환은 어떤 모습일까요? 데이터 관리를 위해 DDD에서 어떤 교훈을 얻을 수 있나요?

문제 공간의 기능적 비즈니스 분해 만들기

팀이 데이터를 엔드 투 엔드(end-to-end)로 운영할 수 있도록 허용하기 전에 범위를 살펴보고 해결하려는 문제 공간을 이해합니다. 기술 구현의 세부 정보로 이동하기 전에 먼저 이 연습을 수행하는 것이 중요합니다. 이러한 문제 공간 간에 논리적 경계를 설정하면 책임이 더 명확해지고 더 잘 관리할 수 있습니다.

문제 공간을 그룹화할 때 비즈니스 아키텍처를 살펴봅니다. 비즈니스 아키텍처 내에는 특정 목적이나 결과를 달성하기 위해 비즈니스에서 소유하거나 교환하는 능력 또는 용량과 같은 비즈니스 기능이 있습니다. 이 추상화는 조직의 전략적 비즈니스 목표 및 목표에 맞게 데이터, 프로세스, 조직 및 기술을 특정 컨텍스트로 압축합니다. 비즈니스 기능 맵은 임무와 비전을 수행하는 데 필요한 기능 영역을 보여 줍니다.

다음 모델에서 가상 회사 Tailwind Traders의 기능 분해를 볼 수 있습니다.

비즈니스 기능 분해를 보여 주는 다이어그램

Tailwind Traders는 성공하려면 비즈니스 기능 맵에 나열된 모든 기능 영역을 마스터해야 합니다. Tailwind Traders는 예를 들어 온라인 또는 오프라인 티켓 관리 시스템의 일부로 티켓을 판매하거나 파일럿 관리 프로그램의 일환으로 비행기를 조종할 수 있는 조종사가 있어야 합니다. 회사는 다른 활동을 비즈니스의 핵심으로 유지하면서 일부 활동을 아웃소싱할 수 있습니다.

실제로 관찰하는 것은 대부분의 사람들이 비즈니스 기능을 중심으로 구성되어 있다는 것입니다. 동일한 비즈니스 기능을 사용하는 사람들은 동일한 어휘를 공유합니다. 일반적으로 지원되는 활동의 응집력에 따라 잘 정렬되고 긴밀하게 연결된 애플리케이션 및 프로세스도 마찬가지입니다.

비즈니스 기능 매핑은 좋은 시작점이지만 여기서는 스토리가 끝나지 않습니다.

애플리케이션 및 데이터에 비즈니스 기능 매핑

엔터프라이즈 아키텍처를 더 잘 관리하려면 비즈니스 기능, 제한된 컨텍스트 및 애플리케이션을 조정합니다. 그렇게 할 때 몇 가지 기초 규칙을 따르는 것이 중요합니다.

비즈니스 기능은 비즈니스 수준에서 유지되어야 하며 추상적으로 유지되어야 합니다. 조직에서 수행하는 작업을 나타내며 문제 공간을 대상으로 합니다. 비즈니스 기능을 구현하면 특정 컨텍스트에 대한 실현(기능 인스턴스)이 만들어집니다. 여러 애플리케이션과 구성 요소가 솔루션 공간에서 이러한 경계 내에서 함께 작동하여 특정 비즈니스 가치를 제공합니다.

특정 비즈니스 기능에 맞는 애플리케이션 및 구성 요소는 다른 비즈니스 문제를 해결하기 때문에 다른 비즈니스 기능과 일치하는 애플리케이션에서 분리된 상태를 유지합니다. 제한된 컨텍스트는 비즈니스 기능에서 파생되고 독점적으로 매핑됩니다. 비즈니스 기능 구현의 경계를 나타내며 도메인처럼 동작합니다.

비즈니스 기능이 변경되면 제한된 컨텍스트가 변경됩니다. 도메인과 해당 경계가 설정된 컨텍스트 간에 전체적으로 일치하기를 기대하는 것이 바람직하지만, 이후 섹션을 배우다 보면 현실이 때때로 이상과 다를 수 있습니다.

Tailwind Traders에 대한 기능 매핑을 프로젝션하는 경우 바인딩된 컨텍스트 경계 및 도메인 구현은 다음 다이어그램과 유사할 수 있습니다.

경계가 설정된 컨텍스트를 보여주는 다이어그램

이 다이어그램에서 고객 관리는 주제별 전문 지식을 기반으로 하므로 다른 도메인에 제공할 데이터를 가장 잘 알고 있습니다. 고객 관리의 내부 아키텍처는 분리되므로 이러한 경계 내의 모든 애플리케이션 구성 요소는 애플리케이션별 인터페이스 및 데이터 모델을 사용하여 직접 통신할 수 있습니다.

데이터 제품 및 명확한 상호 운용성 표준은 다른 도메인에 대한 데이터 배포를 공식화하는 데 사용됩니다. 이 방법에서 모든 데이터 제품은 도메인에 맞춰 동일한 도메인의 이해 관계자 및 디자이너가 동의한 구성되고 공식화된 언어인 유비쿼터스 언어를 상속하여 해당 도메인의 요구 사항을 충족합니다.

여러 기능 구현에서 파생된 추가 도메인

비즈니스 기능 맵으로 작업할 때 일부 비즈니스 기능을 여러 번 인스턴스화할 수 있음을 인정하는 것이 중요합니다.

예를 들어 Tailwind Traders는 "수하물 취급 및 분실물"을 여러 방식으로 지역화할 수 있습니다. 사업부 중 하나가 아시아에서만 운영된다고 가정합니다. 이러한 맥락에서 "수하물 취급 및 분실물"은 아시아 관련 항공기에 대해 충족되는 기능입니다. 다른 사업 라인이 유럽 시장을 대상으로 할 수 있으며, 이러한 맥락에서 또 다른 "수하물 취급 및 분실물" 기능이 사용됩니다. 여러 인스턴스의 이 시나리오는 서로 다른 기술 서비스 및 연결되지 않은 팀을 사용하여 여러 지역화된 구현으로 이어져 해당 서비스를 운영할 수 있습니다.

비즈니스 기능 및 기능 인스턴스(실현)의 관계는 일대다입니다. 이로 인해 추가(하위) 도메인이 생깁니다.

공유 기능 찾기 및 공유 데이터 주의

공유 비즈니스 기능을 처리하는 방법이 중요합니다. 일반적으로 공유 기능을 서비스 모델로 중앙에서 구현하고 다양한 비즈니스 라인에 제공합니다. "고객 관리"는 이러한 종류의 기능의 예일 수 있습니다. Tailwind Traders 예제에서 아시아 및 유럽 비즈니스 라인은 모두 클라이언트에 대해 동일한 관리를 사용합니다.

하지만 공유 기능에 도메인 데이터 소유권을 프로젝터화하려면 어떻게 해야 하나요? 여러 비즈니스 담당자가 동일한 공유 관리 내의 고객에 대한 책임을 지게 될 수 있습니다.

애플리케이션 도메인과 데이터 도메인이 있습니다. 도메인과 제한된 컨텍스트는 데이터 제품 관점에서 완벽하게 일치하지 않습니다. 반대로 비즈니스 기능 관점에서 여전히 단일 데이터 문제가 있다고 주장할 수 있습니다.

복잡한 공급업체 패키지, SaaS 솔루션 및 레거시 시스템과 같은 공유 기능의 경우 도메인 데이터 소유권 접근 방식에서 일관성을 유지해야 합니다. 데이터 제품을 통해 데이터 소유권을 분리할 수 있으며, 애플리케이션을 개선해야 할 수 있습니다. Tailwind Traders "고객 관리" 예제에서 애플리케이션 도메인의 다른 파이프라인은 모든 아시아 관련 고객을 위한 데이터 제품 하나와 모든 유럽 관련 고객을 위한 데이터 제품 등 여러 데이터 제품을 생성할 수 있습니다. 이 경우 여러 데이터 도메인이 동일한 애플리케이션 도메인에서 시작됩니다.

자체 데이터 소유권을 구분하기 위해 메타데이터를 캡슐화하는 단일 데이터 제품을 만들도록 애플리케이션 도메인에 요청할 수도 있습니다. 예를 들어 소유권에 대한 열 이름을 예약하여 각 행을 단일 특정 데이터 도메인에 매핑할 수 있습니다.

여러 비즈니스 기능을 제공하는 모놀리식 시스템을 찾기

또한 대기업과 기존 기업에서 흔히 볼 수 있는 여러 비즈니스 기능을 충족하는 애플리케이션에 주의를 기울입니다. 이 예제 시나리오에서 Tailwind Traders는 복잡한 소프트웨어 패키지를 사용하여 "비용 관리"와 "자산 및 자금 조달"을 용이하게 합니다. 이러한 공유 애플리케이션은 가능한 한 많은 기능을 제공하여 크고 복잡한 모놀리식 애플리케이션입니다. 이러한 상황에서 애플리케이션 도메인은 더 커야 합니다. 여러 데이터 도메인이 애플리케이션 도메인에 있는 공유 소유권에도 동일하게 적용됩니다.

원본 맞춤, 재배포 및 소비자 맞춤 도메인에 대한 디자인 패턴

도메인을 매핑할 때 데이터의 생성, 사용 또는 재배포에 따라 패턴을 선택할 수 있습니다. 아키텍처의 경우 도메인의 특정 특성에 따라 도메인을 지원하는 템플릿을 디자인할 수 있습니다.

소스 시스템에 정렬된 도메인

원본 시스템 정렬 도메인을 보여 주는 다이어그램입니다.

원본 시스템 정렬 도메인은 데이터가 시작되는 원본 시스템과 정렬됩니다. 이러한 시스템은 일반적으로 트랜잭션 시스템이나 운영 시스템입니다.

목표는 이러한 골든 소스 시스템에서 직접 데이터를 캡처하는 것입니다. 데이터 집약적인 사용을 위해 제공 도메인에서 읽기 최적화된 데이터 제품을 활용하십시오. 데이터 변환 및 공유를 위해 표준화된 서비스를 사용하여 이러한 도메인을 용이하게 합니다.

미리 구성된 컨테이너 구조를 포함하는 이러한 서비스를 사용하면 원본 지향 도메인 팀이 데이터를 보다 쉽게 게시할 수 있습니다. 최소한의 중단과 비용으로 최소 저항의 경로입니다.

소비자 맞춤 도메인

소비자 맞춤 도메인을 보여 주는 다이어그램

소비자 맞춤 도메인은 원본 정렬 도메인과 반대입니다. 다른 도메인의 데이터가 필요한 특정 최종 사용자 사용 사례와 일치합니다. 고객 맞춤 도메인은 조직의 사용 사례에 맞게 데이터를 사용하고 변환합니다.

이러한 소비 요구 사항에 맞게 데이터 변환 및 소비를 위한 공유 데이터 서비스를 제공하는 것이 좋습니다. 예를 들어 데이터 파이프라인, 스토리지 인프라, 스트리밍 서비스, 분석 처리 등을 처리하기 위해 도메인에 구애받지 않은 데이터 인프라 기능을 제공할 수 있습니다.

재배포 도메인

다시 전달 도메인을 보여주는 다이어그램

데이터의 재사용 가능성은 다르고 더 어려운 시나리오입니다. 예를 들어 다운스트림 소비자가 서로 다른 도메인의 데이터 조합에 관심이 있는 경우 데이터를 집계하거나 많은 도메인에 필요한 상위 수준 데이터를 결합하는 데이터 제품을 만들 수 있습니다. 이를 통해 반복적인 작업을 방지할 수 있습니다.

데이터 제품과 분석 사용 사례 간에 강력한 종속성을 만들지 마세요. 대신 유연성과 느슨한 결합을 위해 노력합니다. 다음 모델은 유연성을 달성하는 방법을 보여 줍니다. 도메인은 데이터 제품 및 분석 사용 사례 모두의 소유권을 가지며 데이터 제품 생성 및 데이터 사용을 위한 별도의 프로세스를 설계했습니다.

겹치는 도메인 패턴 정의

도메인 모델링은 데이터 또는 비즈니스 논리가 도메인 간에 공유될 때 복잡해지는 경우가 많습니다. 대규모 조직에서 도메인은 종종 다른 도메인의 데이터를 사용합니다. 다른 하위 도메인이 표준화하고 이점을 얻을 수 있는 방식으로 통합 논리를 제공하는 제네릭 도메인을 사용하는 것이 유용할 수 있습니다. 하위 도메인 간의 공유 모델을 작게 유지하고 항상 유비쿼터스 언어에 맞춥니다.

겹치는 데이터 요구 사항의 경우 도메인 기반 디자인과 다른 패턴을 사용할 수 있습니다. 다음은 선택할 수 있는 패턴에 대한 간단한 요약입니다.

겹치는 도메인에 대한 DDD 패턴을 보여 주는 다이어그램

  • 중복에 대한 관련 비용을 재사용성보다 선호하는 경우, 별도의 방법 패턴을 사용할 수 있습니다. 더 높은 유연성과 민첩성을 위해 재사용성이 희생됩니다.
  • 한 도메인이 강력하고 다운스트림 소비자의 데이터 및 요구 사항을 소유하려는 경우 고객 공급업체 패턴을 사용할 수 있습니다. 단점으로는 상충하는 우려와 다운스트림 팀이 결과물과 우선 순위를 협상하고 조정하도록 강요하는 것이 포함됩니다.
  • 통합 논리가 새로 만든 도메인 내에서 계획되지 않은 방식으로 조정될 때 파트너 관계 패턴을 사용할 수 있습니다. 모든 팀은 서로의 요구를 협력하고 고려합니다. 아무도 공유 논리를 자유롭게 변경할 수 없으므로 관련된 모든 사람에게 상당한 약정이 필요합니다.
  • 모든 도메인이 모든 요구 사항에 부합되도록 준수하는 패턴을 사용할 수 있습니다. 통합 작업이 복잡하거나 다른 당사자가 제어할 수 없거나 공급업체 패키지를 사용하는 경우 이 패턴을 사용합니다.

모든 경우에 도메인은 상호 운용성 표준을 준수해야 합니다. 다른 도메인에 대한 새 데이터를 생성하는 파트너 관계 도메인은 소유권 가져오기를 포함하여 다른 도메인과 마찬가지로 해당 데이터 제품을 노출해야 합니다.

도메인 책임

데이터 메시는 도메인 팀 간에 분산하여 데이터 소유권을 분산합니다. 이는 많은 조직에서 거버넌스와 관련한 중앙 집중식 모델에서 페더레이션된 모델로의 전환을 의미합니다. 도메인 팀에는 다음과 같은 작업이 할당됩니다.

  • 데이터 수집, 정리 및 변환과 같은 데이터 파이프라인의 소유권을 최대한 많은 데이터 고객의 요구에 맞게 가져오기
  • SLA 준수 및 데이터 소비자가 설정한 품질 측정값을 포함하여 데이터 품질개선
  • 메타데이터 캡슐화 또는 예약된 열 이름 사용을 통한 행 및 열의 세분화된 수준 필터링
  • 다음을 비롯한 메타데이터 관리 표준을 준수합니다.
    • 애플리케이션 및 원본 시스템 스키마 등록
    • 검색 기능 향상을 위한 메타데이터
    • 버전 관리 정보
    • 데이터 특성 및 비즈니스 용어의 링크
    • 도메인 간의 통합을 향상하기 위해 메타데이터 정보의 무결성
  • 프로토콜, 데이터 형식 및 데이터 형식을 비롯한 데이터 상호 운용성 표준 준수
  • 원본 시스템 및 통합 서비스를 스캐너에 연결하거나 계보를 수동으로 제공하기
  • IAM 액세스 검토 및 데이터 계약 만들기를 비롯한 데이터 공유 작업 준수

분리를 위한 세분성 수준

이제 데이터 도메인을 인식하고 용이하게 하는 방법을 알게 되었으므로 적절한 수준의 도메인 세분성 및 분리 규칙을 디자인하는 방법을 배울 수 있습니다. 아키텍처를 분해할 때 두 가지 중요한 측면이 작용합니다.

기능 도메인의 세분성 및 제한된 컨텍스트 설정은 1차원입니다. 도메인은 특정 작업 방식을 준수하여 공유 서비스, 소유권 가져오기, 메타데이터 표준 준수 등을 사용하여 모든 도메인에서 데이터를 사용할 수 있도록 합니다.

데이터 배포를 위해 가능한 경우 세분화된 경계를 설정합니다. 데이터 기반이 되는 것은 데이터를 집중적으로 재사용할 수 있도록 하는 것입니다. 경계를 너무 느슨하게 만들면 많은 애플리케이션 간에 원치 않는 결합이 강제로 적용되고 데이터 재사용성이 손실됩니다. 데이터가 비즈니스 기능의 경계를 넘을 때마다 분리하려고 노력합니다. 도메인 내에서 도메인의 내부 아키텍처 내에서 긴밀한 결합이 허용됩니다. 그러나 비즈니스 기능의 경계를 넘을 때 도메인은 분리된 상태를 유지하고 다른 도메인과 공유하기 위해 읽기 최적화 데이터 제품을 배포해야 합니다.

기술 도메인 및 인프라 활용률에 대한 세분성은 또 다른 중요한 차원입니다. 데이터 랜딩 존은 데이터 제품을 생성하는 데이터 애플리케이션에 대한 서비스를 지원하며, 이를 통해 민첩성을 제공합니다. 공유 인프라 및 서비스를 사용하여 이러한 종류의 랜딩 존을 만들려면 어떻게 해야 할까요? 기능 도메인은 논리적으로 함께 그룹화되며 플랫폼 인프라를 공유하기에 적합한 후보입니다. 이러한 랜딩 존을 만들 때 고려해야 할 몇 가지 요소는 다음과 같습니다.

  • 데이터 작업 및 공유 시의 응집력과 효율성은 기능 도메인을 데이터 랜딩 존에 맞추는 강력한 동인입니다. 이는 대용량 데이터 제품을 도메인 간에 지속적으로 공유하는 경향이 있는 데이터 중력과 관련이 있습니다.
  • 지역 경계로 인해 추가 데이터 랜딩 존이 구현될 수 있습니다.
  • 소유권, 보안 또는 법적 경계는 도메인 분리를 강제할 수 있습니다. 예를 들어 일부 데이터는 다른 도메인에 표시될 수 없습니다.
  • 유연성과 변화의 속도는 중요한 동인입니다. 일부 도메인은 높은 혁신 속도를 가질 수 있지만 다른 도메인은 안정성을 강력하게 평가합니다.
  • 기능적 경계는 팀을 차별화할 수 있습니다. 이 예제는 소스 지향 및 소비자 지향 경계일 수 있습니다. 도메인 팀의 절반은 다른 서비스보다 특정 서비스를 소중히 여깁니다.
  • 잠재적으로 기능을 판매하거나 분리하려는 경우 다른 도메인의 공유 서비스와 긴밀하게 통합하지 않아야 합니다.
  • 팀 크기, 기술 및 성숙도는 모두 중요한 요소가 될 수 있습니다. 고도로 숙련되고 성숙한 팀은 종종 자체 서비스 및 인프라를 운영하는 것을 선호하지만, 덜 성숙한 팀은 플랫폼 유지 관리의 추가 오버헤드를 소중히 여기지 않습니다.

많은 데이터 랜딩 존을 프로비전하기 전에 도메인 분해를 살펴보고 기본 인프라를 공유할 수 있는 기능 도메인을 결정합니다.

요약

비즈니스 기능 모델링을 사용하면 데이터 메시 아키텍처에서 도메인을 더 잘 인식하고 구성할 수 있습니다. 데이터 및 애플리케이션이 비즈니스에 가치를 제공하는 방식에 대한 전체적인 보기를 제공하는 동시에 데이터 전략 및 비즈니스 요구 사항에 우선 순위를 지정하고 집중하는 데 도움이 됩니다. 데이터 이상의 비즈니스 기능 모델링을 사용할 수도 있습니다. 예를 들어 확장성이 중요한 경우 이 모델을 사용하여 가장 중요한 핵심 기능을 식별하고 이를 위한 전략을 개발할 수 있습니다.

일부 실무자들은 모든 것을 미리 매핑하여 대상 상태 아키텍처를 구축하는 것이 집중적인 운동이라는 우려를 제기합니다. 대신 새 데이터 메시 아키텍처에 등록하는 동안 도메인을 유기적으로 식별하는 것이 좋습니다. 위에서 아래로 대상 상태를 정의하는 대신 상향식으로 작업하고, 탐색하고, 실험하고, 현재 상태를 대상 상태로 전환합니다. 이 제안된 접근 방식은 더 빠를 수 있지만 상당한 위험을 수반합니다. 작업이 중단되기 시작하면 복잡한 이동 또는 리모델링 작업의 중간에 쉽게 있을 수 있습니다. 양방향, 하향식 및 상향식으로 작업한 다음 시간이 지남에 따라 중간에 만나는 것은 더 미묘한 접근 방식입니다.

다음 단계