|
| |
| Sun Java System Message Queue 3 2005Q1 기술 개요 | |
1장
개념적 기초Sun Java™ System Message Queue(Message Queue)는 기업 전체에 분산된 응용 프로그램 및 구성 요소를 통합할 수 있는 안정적인 비동기식 메시징을 제공합니다. 다양한 플랫폼 및 운영 체제에서 실행 중인 프로세스가 서비스에 연결하여 서로 상호 작용할 수 있습니다.
Message Queue는 JMS(Java™ Message Service) 개방형 표준을 구현하는 표준 기반 메시징 솔루션입니다. 또한 Message Queue는 대규모 엔터프라이즈 배포에 필요한 상호 운용성, 보안, 확장성, 가용성, 관리성 및 기타 기능을 제공합니다.
이 장에서는 Message Queue에 대한 개념적 기초를 제공하며 다음 내용으로 구성되어 있습니다.
JMS 개념 및 용어에 이미 익숙하다면 2장, "Message Queue 소개"로 건너뛸 수 있습니다.
엔터프라이즈 메시징 시스템엔터프라이즈 메시징 시스템에서 독립 분산 응용 프로그램이나 응용 프로그램 구성 요소는 메시지를 통해 상호 작용할 수 있습니다. 동일한 호스트나 네트워크에 있거나 또는 인터넷을 통해 느슨하게 연결되어 있는 이 구성 요소들은 메시징을 사용하여 데이터를 전달하고 각자의 기능을 조정합니다.
많은 수의 구성 요소가 동시에 메시지를 교환하고 고용량의 처리량을 지원하기 위해서는 메시지 발신이 사용자의 즉시 수신 가능 여부에 따라 결정되어서는 안 됩니다. 메시지 사용자가 작업 중이거나 오프라인 상태인 경우, 시스템은 사용자가 온라인이 될 때 메시지 수신이 가능하도록 해야 합니다. 이러한 메시지 송수신의 분리를 비동기식 메시지 전달이라고 합니다.
비동기식 메시징 모델은 복잡한 시스템을 통합하는 작업에 매우 적합합니다. 이 모델은 작업 수행 과정에서 한 구성 요소가 다른 구성 요소를 방해할 수 없게 되어 있습니다. 비동기식 메시징은 동기식 시스템에서 가능한 일부 제어 기능을 포기하지만 구성 요소의 상호 작용에 상당한 유연성을 제공하며 한 구성 요소가 실패하더라도 전체 구성 요소의 실패로 연결되지 않으므로 견고성이 더해집니다.
엔터프라이즈 메시징 시스템의 요구 사항
일반적으로 엔터프라이즈 응용 프로그램 시스템은 24시간 중차대한 작업으로 무수히 많은 메시지를 교환하는 많은 수의 분산 구성 요소로 구성됩니다. 비동기식 메시징 지원을 비롯하여 이러한 시스템을 지원하려면 엔터프라이즈 메시징 시스템이 다음 요구 사항을 만족시켜야 합니다.
안정적인 전달. 구성 요소 간에 전달되는 메시지는 네트워크나 시스템 오류로 인해 손실되지 않아야 합니다. 즉 시스템에서 메시지 전달을 보장할 수 있어야 합니다.
보안. 메시징 시스템은 사용자 인증, 메시지 및 자원에 대한 인증된 액세스, 회선을 통한 암호화와 같은 기본 보안 기능을 지원해야 합니다.
확장성. 메시징 시스템은 성능이나 메시지 처리량이 실제로 저하되지 않으면서 로드 증가(사용자 수 및 메시지 수 증가)를 수용할 수 있어야 합니다. 업무와 응용 프로그램이 늘어나면 이는 매우 중요한 요구 사항이 됩니다.
가용성. 메시징 시스템은 거의 다운 타임 없이 작동해야 합니다. 즉 오류 발생 시 시스템이 메시징 서비스를 계속 제공하기에 충분한 중복을 포함해야 함을 의미합니다.
관리성. 메시징 시스템은 메시지 전달을 모니터하고 관리할 도구를 제공해야 합니다. 관리자는 시스템 자원을 최적화하고 시스템 성능을 조정할 수 있어야 합니다.
중앙 집중식(MOM) 메시징
메시지 대기열은 그림 1-1에 표시된 대로 중앙 집중식 메시징 시스템을 사용합니다. 이러한 시스템에서 각 메시징 구성 요소는 단일 중앙 메시지 서비스와의 연결을 유지 관리합니다. 구성 요소는 잘 정의된 인터페이스를 통해 메시지 서비스와 상호 작용합니다.
모든 메시징 구성 요소가 다른 모든 구성 요소와의 연결을 유지 관리하는 대체 피어 투 피어 시스템은 그림의 왼쪽에 있습니다. 피어 투 피어 시스템에서는 빠르고 안정적이며 보안이 유지된 상태로 전달을 할 수 있지만, 안정성과 보안을 지원하는 코드가 각 구성 요소마다 존재해야 합니다. 메시지의 송수신은 긴밀하게 결합되어 있으므로 비동기식 전달이 어려워집니다. 구성 요소가 시스템에 추가되면 연결 수가 기하학적으로 늘어나므로 시스템이 제대로 확장되지 않습니다. 또한 중앙 집중식 관리는 피어 투 피어 시스템에서 문제가 됩니다.
그림 1-1 중앙 집중식 메시징과 피어 투 피어 메시징 비교
엔터프라이즈 메시징의 권장되는 접근 방식인 중앙 집중식 시스템에서 메시지 서비스는 구성 요소 간에 메시지 경로 지정 및 전달을 제공하고 안정적인 전달 및 보안을 담당합니다. 이 시스템의 구성 요소는 느슨하게 결합되어 있으므로 비동기식 메시징을 달성하기 쉽습니다.
메시징 구성 요소가 시스템에 추가되면 선형적으로 연결 수가 증가되므로, 메시지 서비스를 확장하여 시스템을 보다 쉽게 확장할 수 있습니다. 중앙 메시지 서비스는 메시징 클라이언트를 연결할 뿐만 아니라 동작을 구성하고 성능을 모니터하며 서비스를 조정하여 각 메시징 클라이언트의 요구를 만족시킬 수 있는 관리 인터페이스를 제공합니다.
기본 메시지 서비스 구조
중앙 집중식 메시징 시스템의 기본 구조는 그림 1-2와 같으며 일반 메시지 서비스를 통해 메시지를 교환하는 메시지 생성자와 메시지 사용자로 구성됩니다. 메시지 생성자와 사용자는 그 수의 제한 없이 동일한 메시징 구성 요소(또는 응용 프로그램)에 위치할 수 있습니다.
메시지 생성자는 메시지 서비스 프로그래밍 API를 사용하여 메시지를 메시지 서버로 전송합니다. 메시지 서버는 메시지에 대해 인터레스트를 등록한 하나 이상의 메시지 사용자에게 메시지를 경로 지정하고 전달합니다. 사용자는 메시지 서비스 프로그래밍 API를 사용하여 메시지를 수신합니다. 메시지 서비스는 관련된 모든 사용자에게 메시지가 전달되도록 보장하는 역할을 합니다.
그림 1-2 메시지 서비스 구조
이 프로세스를 은유적으로 표현할 때 가장 적절한 표현은 편지 교환이라고 할 수 있습니다. 편지가 최종 수신자의 주소로 지정되어 있어도 편지는 우체국을 통해 발송되므로 수신인이 우편함을 통해 받아볼 때까지 여러 중간 위치에 머물게 됩니다.
JMS(Java Message Service) 기초Message Queue는 JMS(Java Message Service) 개방형 표준을 구현하는 엔터프라이즈 메시징 시스템 즉, JMS 공급자입니다. 따라서 JMS 개념은 Message Queue 서비스의 작업 방식을 이해하는 데 기본이 됩니다.
JMS 사양은 안정적인 비동기식 메시징에 적용되는 일련의 규칙과 의미의 집합을 규정하며 메시지 구조, 프로그래밍 모델 및 API를 정의합니다.
이 절에서는 이 책의 나머지 장을 이해하는 데 필요한 JMS 개념 및 용어를 설명합니다. 이 절은 다음 내용으로 구성되어 있습니다.
JMS 메시지 구조
Message Queue에서 데이터는 JMS 메시지를 사용하여 교환됩니다. JMS 사양에 따라 생성자 클라이언트에 의해 작성된 메시지는 헤더, 등록 정보 및 본문 등 세 부분으로 구성됩니다.
헤더
헤더는 모든 JMS 메시지에서 필수입니다. 헤더 필드에는 메시지 경로 지정 및 식별에 사용되는 값이 포함됩니다.
헤더 값은 다음과 같은 여러 가지 방법으로 설정할 수 있습니다.
JMS에 의해 정의된 헤더 필드에 대한 자세한 내용은 Message Queue Developer’s Guide for Java Clients 또는 Message Queue Developer’s Guide for C Clients를 참조하십시오. 이러한 헤더 필드를 사용하여 메시지의 대상, 만료 시간, 메시지 우선 순위 등을 정의할 수 있습니다.
등록 정보
메시지는 등록 정보라는 선택적 헤더 필드를 포함할 수 있습니다. 등록 정보는 등록 정보 이름과 등록 정보 값 쌍으로 지정됩니다. 메시지 헤더의 확장으로 생각할 수 있는 등록 정보는 데이터를 작성한 프로세스에 대한 정보, 데이터가 작성된 시간 및 데이터 각 부분의 구조를 포함할 수 있습니다. 또한 JMS 공급자는 메시지의 압축 여부 또는 수명이 다했을 때 메시지 처리 방법 등 메시지 처리에 영향을 미치는 등록 정보를 추가할 수 있습니다.
JMS 공급자는 메시지 등록 정보를 선택기로 사용하여 메시지를 정렬하고 경로 지정할 수 있습니다. 생성자 클라이언트는 메시지에 응용 프로그램별 등록 정보를 포함시킬 수 있으며 사용자 클라이언트는 등록 정보가 특정 값을 갖는 메시지만 수신하도록 선택할 수 있습니다. 예를 들어, 사용자 클라이언트는 뉴저지에 있는 시간제 직원에 대한 급여 메시지에 대해서만 관심 분야를 표시할 수 있습니다. 지정된 선택 기준을 만족하지 않는 메시지는 클라이언트로 전달되지 않습니다.
선택기는 사용자 클라이언트 작업을 간소화하고 해당 메시지가 필요하지 않은 클라이언트로 메시지를 전달하는 오버헤드를 없앱니다. 그러나 선택 기준을 처리해야 하는 메시지 서비스에 일부 오버헤드가 추가됩니다. 메시지 선택기 구문과 의미는 JMS 사양에 설명되어 있습니다.
메시지 본문 유형
JMS 메시지의 유형은 표 1-1에 지정된 대로 본문의 내용을 결정합니다.
JMS 프로그래밍 모델
JMS 프로그래밍 모델은 비동기식 메시징 서비스의 구조를 지원합니다. JMS 클라이언트는 JMS 메시지 서비스를 통해 메시지를 교환합니다. JMS 공급자는 JMS 메시징을 수행하는 데 필요한 객체를 준비합니다. 이러한 객체는 JMS API(Application Programming Interface)를 구현합니다.
이 절에서는 JMS 메시징에 필요한 프로그래밍 객체를 설명하고 메시지를 송수신하는 데 사용되는 전달 모델(지점간 및 게시/가입)을 소개합니다.
프로그래밍 객체
메시지 전달을 위해 JMS 클라이언트 설정에 사용되는 객체는 그림 1-3에 나와 있습니다.
그림 1-3 JMS 프로그래밍 객체
JMS 프로그래밍 모델에서 JMS 클라이언트는 연결 팩토리객체(ConnectionFactory)를 사용하여 JMS 메시지 서버와 메시지를 송수신할 연결을 만듭니다. 연결 객체(Connection)는 클라이언트와 메시지 서버 간의 활성 연결을 나타냅니다.
연결되면 통신 자원 할당 및 클라이언트 인증이 이루어집니다. 이는 비교적 중량급 객체이며 대부분의 클라이언트는 단일 연결을 사용하여 모든 메시징을 수행합니다.
연결은 세션 객체(Session)를 생성할 때 사용합니다. 세션은 메시지 생성 및 사용을 위한 단일 스레드 컨텍스트입니다. 메시지 생성을 비롯하여 메시지를 보내고 받는 메시지 생성자 및 사용자를 생성할 때 사용하며, 전달할 메시지의 일련 순서를 정의합니다. 세션은 여러 관리 대상 객체 옵션이나 트랜잭션을 통해 안정적인 전달을 지원합니다.
클라이언트는 메시지 생성자 객체(MessageProducer)를 사용하여 API에서 대상 객체로 표시되는 지정된 물리적 대상으로 메시지를 보냅니다. 메시지 생성자는 생성자가 물리적 대상으로 보낼 모든 메시지에 적용되는 전달 모드(지속성 메시지 및 비지속성 메시지), 우선 순위 및 수명 값과 같은 기본 메시지 헤더 값을 지정할 수 있습니다.
그와 비슷하게 클라이언트는 메시지 사용자 객체(MessageConsumer)를 사용하여 API에서 대상 객체로 표시되는 지정된 물리적 대상으로부터 메시지를 받습니다. 메시지 전달 모델에 따라 Queue와 Topic의 2가지 대상 유형이 있습니다.
메시지 사용자는 메시지 선택기를 사용하여 메시지 서비스가 특정 선택 기준과 일치하는 등록 정보를 갖는 메시지만 전달하도록 할 수 있습니다.
메시지 사용자는 동기식 또는 비동기식 메시지 사용을 지원할 수 있습니다.
프로그래밍 도메인: 메시지 전달 모델
JMS는 서로 다른 2가지 메시지 전달 모델인 지점간 모델과 게시/가입 모델을 지원합니다.
지점간(Queue 대상) 메시지는 생성자로부터 단일 사용자에게 전달됩니다. 이 전달 모델에서 대상 유형은 대기열(Queue)입니다. 메시지는 먼저 대기열 대상으로 전달된 다음, 대기열로부터 해당 대기열에 등록된 사용자 중 하나에게 한 번에 하나씩 전달됩니다. 생성자 수의 제한 없이 생성자는 대기열 대상에게 메시지를 보낼 수 있으며, 각 메시지는 반드시 한 사용자에게만 전달되어 성공적으로 사용됩니다. 대기열 대상에 등록된 사용자가 없는 경우, 대기열은 받은 메시지를 보관했다가 사용자가 대기열에 등록하면 메시지를 전달합니다.
게시/가입(Topic 대상) 단일 생성자가 사용자 수의 제한 없이 메시지를 전달합니다. 이 전달 모델에서 대상 유형은 주제(Topic)입니다. 메시지는 먼저 주제 대상으로 전달된 다음, 해당 주제에 가입한 모든 활성 사용자에게 전달됩니다. 생성자 수의 제한 없이 생성자는 특정 주제 대상으로 메시지를 보낼 수 있으며, 각 메시지는 가입한 사용자 수의 제한 없이 전달될 수 있습니다.
또한 주제 대상은 영구 가입을 지원합니다. 영구 가입은 주제 대상에 등록되었지만 메시지가 대상에 도달하는 시점에 비활성될 수 있는 사용자를 의미합니다. 나중에 활성화된 사용자는 메시지를 수신합니다. 주제 대상에 대해 등록된 사용자가 없는 경우, 해당 주제는 영구 가입이 있는 비활성 사용자에 대해서만 메시지를 보관합니다.
이러한 2가지 메시지 전달 모델은 표 1-2에 표시된, 서로 조금씩 다른 의미를 갖는 다른 프로그래밍 도메인을 나타내는 3가지 API 객체 집합을 사용하여 처리됩니다.
표 1-2 JMS 프로그래밍 도메인 및 객체
기본 유형
(통합 도메인)
지점간 도메인
게시/가입 도메인Destination (Queue 또는 Topic)1
Queue
Topic
ConnectionFactory
QueueConnectionFactory
TopicConnectionFactory
Connection
QueueConnection
TopicConnection
Session
QueueSession
TopicSession
MessageProducer
QueueSender
TopicPublisher
MessageConsumer
QueueReceiver
TopicSubscriber
1프로그래밍 방식에 따라 특정 대상 유형을 지정해야 합니다.
통합 도메인은 JMS 버전 1.1에서 소개되었습니다. 1.02b 이전 사양을 준수해야 할 경우 도메인별 API를 사용할 수 있습니다. 또한 도메인별 API를 사용하면 대기열 대상에 대한 영구 가입자 작성 등의 특정 유형 프로그래밍 오류를 방지하는 깨끗한 프로그래밍 인터페이스의 장점이 있습니다. 하지만 도메인별 API는 동일한 트랜잭션이나 동일한 세션에서 지점간 및 게시/가입 작업을 결합할 수 없다는 단점이 있습니다. 이러한 결합이 필요한 경우 통합 도메인 API를 선택하십시오.
Message Queue 제품에 포함된 예제 응용프로그램을 비롯한 Message Queue 설명서의 많은 코드 예제는 개별 프로그래밍 도메인을 사용합니다.
안정적인 메시징
메시지의 전달 모드는 지속성 또는 비지속성으로 설정될 수 있으며 이 모드에서 메시지 전달의 안정성을 관리합니다.
지속성 메시지의 경우 안정성 보장에는 2가지 측면이 있습니다. 하나는 확인과 트랜잭션을 사용하여 메시지 생성 및 사용이 성공적으로 이루어지게 하는 것입니다. 다른 하나는 지속성 저장소에 메시지를 보관하여 메시지를 사용자에게 전달할 때까지 메시지 서비스에서 지속성 메시지가 손실되지 않게 하는 것입니다.
다음 절에서는 안정성을 보장하는 이러한 2가지 측면에 대해 설명합니다.
확인/트랜잭션
안정적인 메시징은 메시지 생성자에서 메시지 서버의 물리적 대상으로, 그리고 해당 물리적 대상에서 메시지 사용자에게로 지속성 메시지가 성공적으로 전달될 수 있는지 여부에 따라 결정됩니다. 이러한 안정성은 JMS 세션이 지원하는 2가지 일반 메커니즘인 관리 대상 객체 또는 트랜잭션 중 하나를 사용하여 실현할 수 있습니다. 트랜잭션의 경우, 로컬 트랜잭션 또는 분산(분산 트랜잭션 관리자의 제어 하에서) 트랜잭션이 될 수 있습니다.
확인
확인은 안정적인 전달을 위해 클라이언트와 메시지 서비스 간에 전송되는 메시지입니다.
메시지 생성 시, 메시지 서비스는 메시지 전달을 수신하고 메시지를 대상에 넣고 영구적으로 저장했음을 확인합니다. 생성자의 send() 메소드는 확인이 반환할 때까지 차단됩니다.
메시지 사용 시, 클라이언트가 대상으로부터의 메시지 전달을 수신하고 메시지를 사용했음을 확인한 다음 메시지 서비스가 해당 대상에서 메시지를 삭제합니다. JMS는 다양한 안정성 정도를 나타내는 다양한 확인 모드를 지정합니다. 이러한 모드 중 일부에서는 메시지 서버가 메시지를 삭제하여 메시지를 다시 전달할 수 없음을 확인할 때까지 클라이언트는 메시지 서버에 대한 대기를 차단합니다.
로컬 트랜잭션
세션을 트랜잭션된 것으로 구성할 수 있는데, 이 경우 하나 이상의 메시지 생성 및/또는 사용을 트랜잭션이라는 기본 단위로 분류할 수 있습니다. JMS API는 트랜잭션을 시작, 완결 또는 롤백하는 메소드를 제공합니다.
트랜잭션 내부에서 메시지를 생성하거나 사용하면 메시지 서비스는 다양한 발신 및 수신을 추적하여, JMS 클라이언트가 트랜잭션을 완결하도록 호출한 경우에만 작업을 완료합니다. 트랜잭션 내부에서 특정 발신 또는 수신 작업이 실패할 경우 예외가 발생합니다. 클라이언트 코드는 예외를 무시하거나 작업을 다시 시도하거나 전체 트랜잭션을 롤백하는 방법으로 예외를 처리할 수 있습니다. 트랜잭션이 완결되면 작업이 모두 완료됩니다. 트랜잭션이 롤백되면 성공적인 작업이 모두 취소됩니다.
로컬 트랜잭션의 범위는 항상 단일 세션입니다. 즉 단일 세션 컨텍스트에서 수행되는 하나 이상의 생성자 또는 사용자 작업을 묶어 단일 로컬 트랜잭션으로 분류할 수 있습니다.
트랜잭션 범위가 단일 세션에 국한되므로 메시지 생성과 사용을 모두 총괄하는 종단간 트랜잭션은 만들 수 없습니다. 즉, 대상으로 메시지를 전달하는 것과 나중에 메시지를 클라이언트로 전달하는 것을 같은 트랜잭션으로 분류할 수 없습니다.
분산 트랜잭션
또한 JMS 사양은 분산 트랜잭션을 지원합니다. 즉 메시지 생성 및 사용은 데이터베이스 시스템과 같은 다른 자원 관리자가 관련된 작업들을 포함하는 더 크고 분산된 트랜잭션의 일부가 될 수 있습니다. 분산 트랜잭션의 경우, 분산 트랜잭션 관리자는 JTA(Java Transaction API)인 XA Resource API 사양에 정의된 2단계 완결 프로토콜을 사용하여 여러 자원 관리자(메시지 서비스, 데이터베이스 관리자 등)가 수행하는 작업을 추적하고 관리합니다. Java에서 자원 관리자 및 분산 트랜잭션 관리자 간의 상호 작용은 JTA 사양에서 설명합니다.
분산 트랜잭션 지원은 메시징 클라이언트가 JTA에서 정의된 XAResource 인터페이스를 통해 분산 트랜잭션에 참여할 수 있음을 의미합니다. 이 인터페이스는 2단계 완결을 구현하는 여러 메소드를 정의합니다. 클라이언트측에서 API 호출이 이루어지는 동안 브로커는 분산 트랜잭션 내부의 다양한 발신 및 수신 작업을 추적하고 트랜잭션 상태를 추적하며 JTS(Java Transaction Service)가 제공하는 분산 트랜잭션 관리자와의 조정을 통해서만 메시징 작업을 완료합니다.
로컬 트랜잭션과 마찬가지로 클라이언트는 예외를 무시하거나 작업을 다시 시도하거나 전체 분산 트랜잭션을 롤백하는 방법으로 예외를 처리할 수 있습니다.
영구 저장소
안정성의 또 다른 측면은 메시지가 사용자에게 전달될 때까지 메시지 서비스가 영구 메시지를 잃어버리지 않아야 한다는 것입니다. 즉 지속성 메시지가 물리적 대상에 전달되면 메시지 서버는 이를 영구 데이터 저장소에 저장해야 합니다. 어떤 이유로 메시지 서버가 중단되는 경우, 메시지 서버는 메시지를 복구하여 해당 사용자에게 전달할 수 있습니다.
또한 메시지 서버는 영구 가입도 지속적으로 저장해야 합니다. 그렇지 않으면, 오류 발생 시 메시지 서버는 메시지가 주제 대상에 도달한 다음에 활성화되는 영구 가입자에게 메시지를 전달할 수 없습니다.
메시지 전달을 보장하려는 메시징 응용프로그램은 메시지가 지속성을 갖도록 지정하고 이들을 영구 가입을 갖는 주제 대상이나 대기열 대상 중 하나로 전달해야 합니다.
JMS 관리 대상 객체
JMS 프로그래밍 모델에서 사용된 2가지 객체인 연결 팩토리와 대상은 공급자의 JMS 사양 구현에 따라 달라질 수 있습니다.
클라이언트 이식을 허용하면서 이러한 객체 정의에 있어서 공급자에게 최대한의 유연성을 제공하기 위해 JMS 사양은 공급자별 정보를 캡슐화하는 연결 팩토리 및 대상에 대한 관리 대상 객체를 정의합니다. 이러한 객체는 관리자가 작성 및 구성하고 JNDI 이름 영역(객체 저장소)에서 저장하며 클라이언트가 표준 JNDI 조회 코드를 통해 액세스합니다.
관리 대상 객체를 사용하면 JMS 클라이언트는 공급자별 객체를 조회하고 참조할 때 논리적 이름을 사용할 수 있습니다. 그렇게 되면 클라이언트 코드는 공급자가 사용하는 특정 이름 또는 주소 지정 구문이나 구성 가능한 등록 정보를 알아 둘 필요가 없습니다. 따라서 코드 공급자 독립성을 갖게 됩니다.
관리 대상 객체 절에서는 메시지 대기열에서 사용된 관리 대상 객체에 대한 추가 정보를 제공합니다.
주
JMS 사양에서는 JNDI 조회를 사용하여 관리 대상 객체에 액세스하지 않아도 됩니다. 클라이언트 코드는 연결 팩토리 및 대상 객체를 인스턴스화하고 해당 속성에 대한 값을 설정합니다. 하지만 클라이언트 코드를 다른 공급자에게 이식할 수 없음을 의미합니다.
