차례[숨다][보여 주다]
마이크로서비스에 대한 아이디어는 최근 많은 주목을 받았으며 많은 기업에서 이를 사용하여 대규모의 단일 백엔드를 없애고 있습니다.
웹 앱의 서버 측을 구성하는 이러한 분산 방식이 연구 및 실행 측면에서 다소 안정적이더라도 프론트엔드와 동일한 경로를 사용하는 것은 여전히 많은 비즈니스에서 어려운 과제입니다.
클라이언트 측 모노리스는 밀접한 종속성으로 인해 일반적으로 새로운 기능을 통합하고, 새로운 기술을 채택하고, 개별 구성 요소를 확장하는 것을 어렵게 만듭니다.
이러한 문제와 기타 문제로 인해 프런트엔드 개발자는 마이크로서비스 사용을 조사하게 되었습니다.
그 결과 웹사이트와 웹 기반 애플리케이션의 프론트엔드 계층을 만들기 위해 마이크로 프론트엔드라는 새로운 아키텍처 전략이 개발되었습니다.
이 용어는 2016년에 처음 사용되었으며 그 이후로 좋은 취지로 많은 주목을 받았습니다.
이 기사는 마이크로 프론트엔드가 무엇이며 해결하는 문제에 대한 일반적인 이해를 제공합니다. 장점과 단점뿐만 아니라 효과가 있습니다.
마이크로 프론트엔드 아키텍처 소개
마이크로 프론트엔드 아키텍처라고 하는 프론트엔드 개발의 현대적인 방법은 웹 애플리케이션 작고 독립적인 부분으로.
최종 사용자에게 이러한 부품은 독립적으로 구성되어 함께 구성되더라도 하나의 단위로 보입니다.
마이크로 프론트엔드가 온라인 솔루션의 서버 측이 아닌 클라이언트 측과 관련되어 있다는 차이점과 함께 그 기반이 되는 근거는 마이크로 서비스와 동일합니다.
정교한 웹 기반 제품을 만드는 것은 마이크로 프론트엔드 접근 방식을 사용할 때 가장 합리적입니다.
마이크로 프론트엔드는 기존의 프론트엔드 모놀리스와 달리 여러 팀이 다양한 소프트웨어 프로젝트에서 개별적으로 협업할 수 있도록 합니다.
프로그래머는 이 아키텍처 디자인을 사용하여 더 빠르고 확장성과 유지 관리 용이성을 갖춘 웹 앱을 만들 수 있습니다.
간단히 말해서 각 마이크로 프론트엔드는 웹 페이지의 고유한 구성 요소에 대한 코드 조각일 뿐입니다.
이러한 기능은 각각 특정 산업 또는 목표를 전문으로 하는 별도의 팀에서 제어합니다.
모놀리식 vs 마이크로서비스 vs 마이크로 프론트엔드 아키텍처
이사를 생각해보세요. 모든 것을 전문적으로 라벨이 붙은 여러 개의 작은 상자로 정리하고 각 상자를 개별적으로 재배치하거나 전체 직원을 하나의 거대한 상자에 포장하여 새 위치로 옮기는 것이 더 간단할까요?
분명한 해결책이 있습니다.
이 비유는 두 가지 별개의 웹 앱 아키텍처인 모놀리스와 마이크로서비스(마이크로 프론트엔드라고도 함)를 비교합니다.
모 놀리 식 아키텍처
완전한 애플리케이션이 하나의 응집력 있는 엔터티로 생성되었던 "좋은 옛날"을 기억할 수 있습니다. 이러한 방법을 단일체(monolith)라고 하며, 이는 큰 돌 블록에 대한 오래된 용어입니다.
이것은 말이됩니다.
모놀리식 시스템에는 상호 의존적인 요소가 있습니다. 따라서 무언가를 수정하거나 새로운 기능을 추가하려는 경우 전체 시스템이 중단될 수 있습니다.
비록 구식이지만 때때로 여전히 존재합니다. 예, 귀하의 현재 표정을 알고 있습니다.
새로운 기술이 개발되고 소프트웨어 제품이 더 복잡해짐에 따라 코드베이스를 프론트엔드(클라이언트 측)와 백엔드(서버 측)의 두 가지 구성 요소로 개념적으로 나누는 것은 불가피해졌습니다.
가장 널리 사용되는 작업 방법은 이제 최종 사용자가 상호 작용하는 프레젠테이션 계층과 백그라운드에서 발생하는 모든 것 사이의 문제를 분리하는 것입니다.
두 개의 소프트웨어 엔지니어링 팀이 필요합니다. 프런트 엔드 팀은 시각적 구성 요소를 구축하고 백 엔드 팀은 웹 서비스, 비즈니스 로직, 데이터 액세스, 통합 등을 구축합니다.
그러나 이러한 분리에도 불구하고 이 전략은 여전히 본질적으로 모놀리식으로 남아 있습니다.
주요 변경 사항은 이제 하나의 거대한 응용 프로그램 대신 프론트엔드와 백엔드라는 두 개의 상당한 코드 블록이 있다는 것입니다. 모놀리식 아키텍처는 끔찍할 필요가 없습니다. 다음을 포함한 몇 가지 이점이 있습니다.
- 단일 소스 코드베이스와 매우 단순한 디자인으로 소규모 애플리케이션을 위한 간단하고 빠른 개발.
- 모든 코드가 한 위치에 있기 때문에 테스트 및 디버깅이 매우 간단하여 팀이 요청의 흐름을 추적하고 버그를 식별하기가 더 쉽습니다.
- 애플리케이션 개발 초기에는 새로운 기능이 추가될 때까지 인프라 비용이나 개발 비용이 발생하지 않기 때문에 비용이 저렴합니다.
이 전략의 단점은
- 제한된 배포 유연성 – 소수의 팀만 프로젝트에서 작업하고 코드를 업데이트할 때마다 새로운 배포가 필요한 경우 팀은 기다려야 합니다.
- 새로운 기술을 채택하는 것은 전체 프로젝트는 아닐지라도 상당한 부분을 다시 작성해야 하기 때문에 어려운 일입니다.
- 개발자의 수가 증가하면 코드 시스템은 밀접하게 연결되고 복잡해지며 관리 및 이해하기 어렵습니다.
- 조직 문제 – 각 팀 구성원은 동일한 버전의 라이브러리를 사용해야 하며 많은 팀이 모놀리식 프로젝트에서 작업하는 경우 변경 사항을 보고해야 합니다.
- 확장성에 대한 우려 – 프로젝트의 구성 요소가 서로 연결되어 있기 때문에 개별적으로 확장하는 것은 상당한 가동 중지 시간과 더 많은 비용을 초래하는 어려움을 나타냅니다.
- 프로젝트의 복잡한 논리는 특히 처음에 작업한 엔지니어가 더 이상 고용되지 않는 경우 새로운 팀 구성원이 이해하기 어려울 수 있습니다.
마이크로서비스와 그 가까운 친척, 마이크로 프론트엔드의 개발은 모놀리식 시스템의 주요 문제를 해결했습니다.
마이크로서비스 아키텍처
마이크로서비스로 알려진 아키텍처 방법을 사용하면 애플리케이션 백엔드를 구성하는 느슨하게 연결되고 독립적으로 배포 가능한 더 작은 구성 요소 또는 서비스를 많이 생성할 수 있습니다.
모든 서비스에는 자체 코드베이스, CI/CD 파이프라인, DevOps 절차 및 이를 실행하기 위한 프로세스가 있습니다.
위 이미지를 보면 모놀리식 백엔드 팀이 별도의 팀으로 나뉘어져 있음을 알 수 있습니다.
각각은 애플리케이션의 다른 측면(예: 제품 서비스, 검색 서비스, 결제 서비스)에 개별적으로 초점을 맞춥니다.
서비스 간의 통신은 동기식 요청-응답 패턴을 사용하는 경량 REST API 프로토콜과 같은 API로 알려진 확립된 프로토콜을 통해 발생합니다.
또 다른 옵션은 게시/구독 통신 구조 및 이벤트를 제공하는 Kafka와 같은 소프트웨어를 사용하여 비동기 통신을 사용하는 것입니다.
마이크로서비스는 프론트엔드(BFF) 서비스용 백엔드 또는 네트워크를 통한 API 게이트웨이를 통해 프론트엔드와 통합됩니다. BFF는 각 클라이언트에 대해 맞춤형 API를 제공하는 반면 API 게이트웨이는 마이크로서비스 모음에 대한 단일 액세스 지점을 제공합니다.
그러나 자율적인 백엔드 구성 요소와 이들이 제공하는 모든 이점에도 불구하고 프론트엔드는 여전히 단일체입니다.
따라서 마이크로 프론트엔드가 유용한 곳입니다.
마이크로 프론트엔드 아키텍처
느슨하게 연결된 구성 요소가 여러 팀에서 관리되는 마이크로 서비스와 유사하게 마이크로 프론트엔드 아키텍처는 개념을 브라우저에 적용합니다.
이러한 웹 애플리케이션 사용자 인터페이스는 다소 자율적인 구성 요소로 구성된 이 구조를 따릅니다.
팀은 또한 특정 전문 지식이나 기술보다는 고객의 요구나 사용 사례에 따라 만들어집니다.
결과적으로 팀은 마이크로서비스 및 마이크로 프론트엔드 프로젝트에 참여합니다.
- 수직 분할 — 프론트엔드 개발자, 데이터 전문가, 백엔드 엔지니어, QA 엔지니어 등이 동일한 프로젝트에서 작업하기 때문에 기능을 생성합니다. 사용자 인터페이스 데이터베이스에; 그리고
- 교차 기능 – 각 팀 구성원은 그룹에 자신의 전문 지식을 제공합니다.
팀은 특정 비즈니스 라인에 가장 적합한 기술 스택을 선택할 수도 있습니다.
한 팀은 React를 사용하여 단편을 프로그래밍할 수 있습니다. 다른 팀이 새 Angular 버전을 만듭니다. Vue.js가 그러한 예입니다.
마이크로 프론트엔드는 관련 마이크로 서비스와 함께 사용하여 개발 팀이 일반적으로 모놀리식과 관련된 문제를 해결합니다. 이 전략은 다음과 같은 이점을 제공합니다.
- 기술 자유: 프론트엔드 엔지니어는 회사의 요구 사항에 따라 대체 JavaScript 프레임워크, 런타임 환경 및 전체 기술 스택을 선택할 수 있습니다. 구식 아키텍처 위에 새로운 프레임워크가 적용될 수 있습니다.
- 각 마이크로 프론트엔드가 독립적이며 개별적으로 개발, 테스트, 배포 및 업그레이드할 수 있으므로 더 큰 유연성이 가능합니다. 결과적으로 한 팀이 기능에 대해 작업 중이고 버그 수정을 푸시하고 다른 팀이 자체 기능을 추가해야 하는 경우 첫 번째 팀이 작업을 완료할 때까지 기다릴 필요가 없습니다.
- 자율적인 팀과 시스템: 각 제품 팀과 결과적으로 각 기능은 다른 팀에 거의 의존하지 않고 기능할 수 있으므로 주변 구성 요소를 사용할 수 없는 경우에도 계속 작동할 수 있습니다.
- 여러 개의 더 작은 코드베이스: 각 마이크로 프론트엔드에는 더 관리하기 쉽고 더 작은 자체 코드베이스가 있습니다. 특정 UI 구성 요소에 집중하고 코드 검토를 단순화하며 전체 구성을 개선하는 사람이 줄어들 것입니다.
- 간단한 앱 확장: 마이크로 프론트엔드의 또 다른 이점은 각 기능을 개별적으로 확장할 수 있다는 것입니다. 새로운 기능이 추가될 때마다 전체 프로그램을 확장해야 하는 모놀리스와 달리 전체 프로세스는 시간과 비용 면에서 더 효율적입니다.
마이크로 프론트엔드는 어떻게 작동합니까?
이전에 언급했듯이 팀은 마이크로 프론트엔드 아키텍처 내에서 수직으로 조직되어 있습니다. 즉, 팀은 도메인 지식이나 목적에 따라 분리되고 특정 제품에 대해 처음부터 끝까지 책임을 집니다.
하나 또는 두 개의 백엔드 마이크로서비스와 작은 프론트엔드를 가질 수 있습니다. 이 시각적 요소의 특성, 다른 UI 구성 요소와의 상호 작용 및 홈페이지로의 통합에 대해 자세히 살펴보겠습니다.
마이크로 프론트엔드는
- 전체 페이지(예: 제품 상세 페이지) 또는
- 머리글, 바닥글 및 검색 창과 같이 다른 팀에서 사용할 수 있는 페이지 섹션.
큰 웹 사이트를 여러 페이지 종류로 나누고 각 유형을 특정 직원에게 할당하여 작업할 수 있습니다.
그러나 머리글, 바닥글, 제안 블록 등과 같은 여러 구성 요소가 여러 페이지에 자주 발생합니다. 예를 들어 제안 블록은 홈페이지, 제품 세부 정보 페이지 또는 결제 페이지에 포함될 수 있습니다.
본질적으로 팀은 다른 팀이 페이지에서 사용할 수 있는 조각을 만들 수 있습니다.
그러나 마이크로 프론트엔드는 재사용 가능한 구성 요소가 아닌 다른 프로젝트로 별도로 배포할 수 있습니다.
이 모든 것이 환상적으로 들리지만 통합 인터페이스를 만들려면 페이지와 조각이 어떻게든 결합되어야 합니다.
이를 위해서는 라우팅, 구성 및 통신을 포함한 다양한 전략을 통해 달성할 수 있는 프론트엔드 통합이 필요합니다(위 그래픽 참조).
라우팅
한 팀이 제어하는 페이지의 서비스가 다른 팀이 소유한 페이지에 액세스해야 하는 경우 라우팅은 페이지 수준 통합에 유용합니다.
모든 마이크로 프론트엔드는 단일 페이지 애플리케이션으로 처리됩니다. 간단한 HTML 링크를 사용하여 라우팅을 제공할 수 있습니다.
사용자는 브라우저가 서버에서 대상 마크업을 다운로드하도록 하고 하이퍼링크를 클릭하여 현재 페이지를 새 페이지로 바꿀 수 있습니다.
앱 셸은 UI를 구동하는 최소한의 HTML, CSS 및 JavaScript입니다. 서버에서 요청한 콘텐츠 데이터가 아직 대기 중이더라도 사용자는 즉시 정적 표시 페이지를 받습니다. 중앙 앱 셸은 다양한 팀에서 만든 단일 페이지 앱의 상위 애플리케이션 역할을 합니다.
사용 중인 라이브러리나 프레임워크에 관계없이 메타 프레임워크를 사용하면 다양한 페이지를 단일 페이지로 융합할 수 있습니다.
조성
구성은 페이지의 적절한 공간에 맞게 조각을 배열하는 과정입니다. 대부분의 경우 페이지를 배포하는 팀은 조각의 콘텐츠를 즉시 가져오지 않습니다.
대신, 조각이 마크업에 있어야 하는 곳에 자리 표시자 또는 마커를 배치합니다.
다른 구성 프로세스를 사용하여 최종 조립이 완료됩니다. 구성은 클라이언트 측과 서버 측의 두 가지 기본 범주로 나눌 수 있습니다.
클라이언트 측 구성: 웹 브라우저는 HTML 마크업을 생성하고 편집하는 데 사용됩니다. 각 마이크로 프런트엔드에는 페이지의 나머지 부분과 별도로 마크업을 변경하고 표시할 수 있는 기능이 있습니다.
예를 들어 웹 구성 요소를 사용하면 이러한 유형의 구성을 수행할 수 있습니다.
계획은 각 조각을 a.js 파일로 독립적으로 설치할 수 있는 웹 구성 요소로 전환하는 것입니다. 그런 다음 앱은 테마 레이아웃에서 지정된 공간에 로드하고 렌더링할 수 있습니다.
웹 구성 요소는 다른 프론트엔드 프레임워크에서 사용할 수 있는 HTML 및 DOM API와 props 및 이벤트를 통해 데이터를 보내고 받는 표준 방법에 의존합니다.
서버 측 구성: 이 디자인에서는 UI 조각이 서버에서 결합되어 완전히 형성된 페이지가 클라이언트 측으로 전송되어 로딩 속도가 빨라집니다.
어셈블리는 종종 웹 브라우저와 웹 서버 사이에 있는 별도의 서비스에 의해 수행됩니다. CDN은 서비스(콘텐츠 전달 네트워크)의 한 인스턴스입니다.
필요에 따라 하나 또는 둘을 조합하여 선택할 수 있습니다.
마이크로 프론트엔드 커뮤니케이션 패턴
마이크로 프론트엔드 아키텍처는 다양한 구성 요소 간의 상호 작용이 거의 또는 전혀 없을 때 가장 잘 작동합니다. 마이크로 프론트엔드는 때때로 서로 대화하고 정보를 공유해야 합니다. 다음은 이를 유발할 수 있는 몇 가지 잠재적 패턴입니다.
- 웹 작업자: 온라인 작업자는 웹 콘텐츠가 페이지 속도에 영향을 주지 않고 다른 스크립트와 독립적으로 백그라운드에서 JavaScript를 실행할 수 있도록 하는 메커니즘입니다. 마이크로 앱마다 고유한 작업자 API가 제공됩니다. 이 이점은 시간 소모적인 작업을 다른 스레드에서 수행할 수 있어 UI 스레드가 느려지거나 중단되지 않고 계속 진행될 수 있다는 것입니다.
- 이벤트 이미터참고: 이 경우 많은 구성 요소가 구독 중인 구성 요소의 상태 변경을 수신 대기하고 그에 따라 작동하여 서로 통신합니다. 특정 이벤트를 구독한 다른 마이크로 프론트엔드는 마이크로 프론트엔드가 해당 이벤트를 실행할 때 응답합니다. 각 마이크로 프론트엔드에 도입된 이벤트 이미터는 이것을 가능하게 합니다.
- 콜백 및 소품: 이 섹션에서는 상위 구성 요소와 하위 구성 요소를 정의합니다. 통신은 나무와 같은 구조로 구성됩니다. 상위 구성 요소는 props를 사용하여 구성 요소 트리를 따라 하위 구성 요소에 데이터를 함수로 전달합니다. 차례로, 아이는 콜백에 응답하여 자신의 상태에서 어떤 일이 발생했을 때 부모에게 효율적으로 경고할 수 있습니다. React는 이 모드를 사용합니다.
마이크로 프론트엔드의 장점
신속하게 자율적인 팀의 개발
독립적인 팀은 마이크로 프론트엔드 방식을 사용할 때 웹 앱이나 웹사이트의 각 부분을 만들 수 있습니다.
각 팀은 완전히 자율적입니다. 즉, 구상에서 출시 및 후반 작업에 이르는 전체 구성 요소 개발 주기를 담당합니다.
또한 여러 팀이 동일한 프로젝트에서 동시에 작업하면서 원활하게 협업할 수 있음을 의미합니다.
따라서 릴리스 주기는 프런트 엔드 모노리스보다 훨씬 빠릅니다.
개별 마이크로 프론트엔드의 더 작은 코드베이스는 더 깔끔한 코드로 이어집니다
모놀리식 프런트 엔드에는 시간이 지남에 따라 점점 더 혼란스러워지고 관리하기 어려워지는 크고 다루기 힘든 코드베이스가 있습니다.
마이크로 프론트엔드는 이 문제를 해결합니다. 각 마이크로 프론트엔드의 소스 코드는 더 작고 단순하며 더 작기 때문에 관리하기 쉽습니다.
결과적으로 전체 웹 솔루션은 보다 깨끗한 코드의 이점을 얻습니다.
느슨한 연결로 인해 앱 안정성 향상
웹 솔루션은 완전히 독립적인 조각으로 거의 분할될 수 없습니다. 결과적으로 마이크로 프론트엔드는 서로 통신합니다.
그러나 느슨한 연결에도 불구하고 구성 요소 간의 각 링크는 중요합니다.
한 구성 요소의 오류는 다른 모든 구성 요소의 작동에 거의 또는 전혀 영향을 미치지 않으므로 웹 솔루션의 향상된 안정성을 제공합니다.
더 간단해진 개별 기능 테스트
이러한 이점은 마이크로 프론트엔드의 특성에서 비롯됩니다. 이 아키텍처 설계를 기반으로 웹 솔루션의 클라이언트 측이 모듈식이며 각 모듈은 자율적입니다.
결과적으로 팀이 대규모 단일체를 테스트하는 것보다 사용자 인터페이스의 작은 부분을 자체적으로 평가하는 것이 더 쉽습니다.
번들 크기 감소로 페이지 로드가 빨라짐
기능이 풍부한 모놀리식 웹 시스템에서 로드 시간이 지연되는 주요 원인 중 하나는 JavaScript 번들의 크기입니다. 반면에 마이크로 프론트엔드 접근 방식을 사용하면 페이지 로드 시간을 더 쉽게 줄일 수 있습니다.
웹 페이지는 여러 개의 작은 번들로 구성되어 있기 때문에 브라우저는 불필요한 코드를 반복적으로 다운로드할 필요가 없습니다. 결과적으로 페이지 성능과 로드 시간이 증가합니다.
기술 독립
배수 프론트엔드 프레임워크 개발자는 마이크로 프론트엔드 아키텍처로 단일 온라인 솔루션을 만드는 데 사용할 수 있습니다.
각 구성 요소는 자율적이므로 팀의 작업에 가장 적합한 기술을 사용하여 구성할 수 있습니다.
당연히 프로그래머는 자신이 담당하는 소프트웨어 프로젝트의 프레임워크를 선택할 때 주의해야 하며 여전히 다른 팀과의 협의를 적극 권장합니다.
그러나 앱의 수명 기간 동안 레거시 프레임워크를 사용해야 할 가능성은 없습니다.
마이크로 프론트엔드의 단점
전체적으로 복잡한 웹 솔루션 테스트
마이크로 프론트엔드 아키텍처를 사용하면 웹 솔루션의 다양한 모듈을 쉽게 테스트할 수 있습니다. 하지만 웹 애플리케이션을 전체적으로 평가하는 것과는 다릅니다.
계속하기 전에 모든 부품이 의도한 대로 작동하는지 확인하십시오. 마이크로 프론트엔드는 독립적으로 작동하고 별도의 전달 프로세스가 있기 때문에 어려울 수 있습니다.
비싼 초기 투자
마이크로 프론트엔드 개발에는 일반적으로 상당한 재정적 지출이 필요합니다. 많은 프런트 엔드 팀을 구성하고 유지하는 데 비용이 많이 듭니다.
또한 작업을 조직하고 모든 것이 조정되고 우수한 팀 의사 소통을 보장하기 위해 관리 직원이 필요합니다.
개발 및 배포의 복잡성
개발 및 배포 절차는 마이크로 프론트엔드 설계의 결과로 더 복잡해질 수 있습니다.
예를 들어 동일한 프로젝트에서 작업하는 독립적인 개발 팀에 의해 너무 많은 구성 요소로 인해 솔루션이 복잡해져서 배포 단계에서 문제가 발생할 수 있습니다.
모든 모듈을 올바르게 조립하고 전체 구성표에 원활하게 통합하는 것도 항상 간단한 것은 아닙니다. 이 작업은 일반적으로 모든 종속성에 대한 철저한 이해를 필요로 합니다.
사용자 경험의 일관성 유지 문제
팀이 소프트웨어의 여러 부분에서 개별적으로 작업할 때 일관된 사용자 인터페이스를 유지하는 것이 어렵습니다.
웹 솔루션은 프로젝트의 모든 개발자가 공유해야 합니다. 그렇지 않으면 길을 따라 많은 모순이 있을 수 있습니다.
결론
현대적인 아키텍처 디자인인 마이크로 프론트엔드는 대규모 마이크로 서비스 기반 웹 개발 프로젝트의 성능을 크게 향상시킬 수 있습니다.
이를 통해 프로그래머는 전체 솔루션을 여러 자율 팀에서 생성할 수 있는 개별 부품으로 나눌 수 있습니다. 더 빠른 기능 롤아웃, 더 쉬운 개별 모듈 테스트, 더 원활한 업그레이드 등 수많은 이점이 있습니다.
그러나 마이크로 프론트엔드에도 몇 가지 어려움이 있습니다.
예를 들어 애플리케이션의 포괄적인 테스트는 어려울 수 있습니다.
또한 엔지니어와 관리자로 구성된 대규모 팀이 필요하기 때문에 마이크로 프론트엔드 프로젝트는 비용이 많이 듭니다.
따라서 결정을 내리기 전에 비즈니스 사례의 모든 구성 요소를 고려해야 합니다.
블라디미르 카마즈
어쩐지 저는 프런트엔드의 개별 구성 요소 간 통신이 어떤 원리로 작동하는지 이해하지 못했습니다. 다른 프레임워크에서 생성된 구성 요소를 어떻게 연결하려는지 이해할 수 없습니다. 기사에는 그것에 관한 내용이 없습니다. 이벤트 시스템과 청취자는 나에게 지구상의 지옥처럼 보입니다. 어떻게 상상해야 할까요?