레거시 시스템을 SOA에 맞게 (한글)

문서 옵션 JavaScript가 필요한 문서 옵션은 디스플레이되지 않습니다. 영어원문  제안 및 의견 피드백

난이도 : 중급

Calvin Lawrence, Chief and Principal SOA Architect, East Region, IBM　

2007 년 7 월 31 일

서비스 지향 아키텍처(SOA)와 IT 인프라스트럭처를 개발 및 관리하는 기타 서비스 지향 접근 방식은 많은 기업들로 하여금 기존의 IT를 활용하는 전통적인 접근 방식을 재고하게 합니다. 이 글에서, SOA에 맞춰 기존 레거시 환경을 변형할 때 비즈니스와 IT에 미치는 영향에 대해 알아보고, 레거시 메인프레임을 활용하는 핵심 아키텍처 패턴에 대해서도 알아봅니다.

"레거시(legacy)" 정의

소셜 북마크 mar.gar.in Digg del.icio.us Slashdot

"레거시(Legacy)"는 과거에 전개되었던 기존의 IT 에셋(asset)을 의미한다. 이러한 에셋들은 20년 전 또는 어제까지 설치되었던 모든 것들을 의미하고, 대부분 레거시 에셋들은 중요한 비즈니스 프로세스를 실행하고 있다. 레거시 소프트웨어와 애플리케이션들은 종종 엔터프라이즈의 "cash cow(돈벌이가 되는 것)"로 간주되기 때문에 레거시 소프트웨어와 애플리케이션들은 기업의 운영 이익에도 큰 책임이 있다. 이러한 이윤은 레거시 에셋을 관리하는데 필요한 비용을 훨씬 초과하고, 초과분은 기업이 다른 전략적 이니셔티브에 자금을 투자하는데 사용된다. 게다가, 레거시 소프트웨어나 애플리케이션들은 인수 합병의 결과로 엔터프라이즈로 들어온다. 많은 경우, 애플리케이션의 개발과 관리에 책임이 있는 사람들은 더 이상 라이프 사이클에는 책임이 없다.

레거시 인프라스트럭처는 메인프레임 애플리케이션과 서비스에만 국한될 필요가 없다. 레거시 애플리케이션들은 기업에 있어서 중요한 비즈니스 가치를 나타낸다. 예를 들어, 2천억 줄의 COBOL 코드가 있고, 3백억 COBOL 기반 트랜잭션들이 매일 처리되고 있다.

레거시 시스템들은 다음 패턴들 중 한 개 이상을 기반으로 구현된다.

• 그린 스크린(Green screen). 메인프레임 CICS® 시스템에 대한 3270 터미널 액세스 같은 전형적인 문자 기반 애플리케이션이다.
• 팻 클라이언트(Fat client). Windows®-기반 PC 같은 클라이언트 워크스테이션 기반으로 실행되는 그래픽 UI를 사용하여 단일 레거시 애플리케이션에 액세스 할 수 있다.
• 다중 세션. 비즈니스 프로세스가 하나의 사용자가 여러 애플리케이션들에 걸쳐 여러 개의 활성 세션들을 가질 것을 요구하고, 사용자는 사전 정의된 순서대로 액티비티를 실행해야 한다.
• 많은 P2P. 레거시 애플리케이션을 가진 인터페이스는 레거시 시스템과 종속 시스템간 고유한 p2p 인터페이스를 진화시켰다.
• 레거시 제약 조건. 기술적 구현은 비즈니스의 확장 기능을 제한하는 수단이다.
• 사장된 레거시. 늘어나는 사용자 요구를 레거시 애플리케이션이 수용할 수 없기 때문에(레거시 제약 조건 참조) 분산 애플리케이션들이 비즈니스 프로세스와 데이터가 다중 시스템들간 분산되는 방식으로 레거시 애플리케이션들을 확장 및 매장했다.

레거시 인에이블먼트(enablement)란 기존 소프트웨어와 정보 에셋들을 활용하여 새로운 비즈니스 프로세스에 사용될 수 있도록 하는 프로세스이다.

위로

변형의 필요성 이해하기

레거시 시스템들은 일반적으로 오랜 기간 동안의 코딩, 개발, 향상, 수정을 나타내는 비즈니스 로직을 갖고 있는 개별 에셋들로 구성된다. 하지만, 이들은 종종 문서화 되지 않고, 강결합 되며, 비교적 폐쇄적이고 유연하지 못하다. 대부분의 경우, 일관된 아키텍처 없이 독립적으로 개발되었으며, 결국 중복되는 과잉의 기능과 데이터만 낳게 되었다. 레거시 에셋들의 주요한 문제는 다음과 같다.

• 높은 소유 비용. 소프트웨어 및 하드웨어의 관리, 운영, 업그레이드 비용 포함. CPU 사용을 기반으로 한 메인프레임 가격 책정.
• 복잡하고 이해하기 어려운 코드로 인한 느린 타임투마켓(time to market). 이로써 시스템은 변화하는 시스템 요구 사항들을 만족시킬 수 없다. 변화는 중대한 변동 효과를 만들어 내고 더 많은 회귀 테스트를 필요로 한다. 이는 관리 및 향상 비용을 높인다.
• 하나로 통일된 아키텍처. 전혀 모듈식이 아니며 중복 코드가 있다. 이는 확장 패치와 수정뿐만 아니라 개별 팀들이 다른 시스템에서 구현한 너무나 유사한 기능과 관련이 있다.
• 새롭고, 개방된 기술과 현대적인 분산 아키텍처와 통합 및 상호 작동하기 어렵게 만드는 폐쇄적이고 후진 기술.
• 레거시 시스템에 숙련된 개발자들의 능력 감소 및 벤더 지원의 감소. 이러한 시스템에 대한 지식은 대체하기 어려운 핵심 요원들로 제한된다.
• 원래 개발자나 사용자들의 이탈로 인한 애플리케이션 지식의 부족과 문서 부족 및 모호함.

대부분의 기업들은 레거시 아키텍처에 많은 투자를 해왔기 때문에, 인프라스트럭처에 명백히 드러난 단점의 정도에 상관 없이, 레거시 시스템들을 제거하거나 대체할 수 없다. 레거시 환경의 많은 부분을 다시 작성하거나 많은 수정을 한다는 것은 현실적이지도 않을뿐더러, 한정된 시간 프레임에서는 달성할 수 없다.

위로

레거시 시스템에 SOA 접근 방식 사용하기

지금까지 언급했던 단점들을 푸는데 주요한 문제는 서비스로서 노출될 수 있는 유용한 레거시 기능과 태스크들을 발견 및 구분하여 그러한 서비스들을 사용할 애플리케이션들을 협업시킴으로써 사용되도록 하는 것이다. 과거의 아키텍처 디자인들은 레거시 시스템들과 블랙 박스를 생각했다. 표준 애플리케이션 프로그램 인터페이스(API)와 인터페이스는 레거시 기반 시스템에 접근하도록 작성되었다. 레거시 시스템에 의해 포착된 기반 비즈니스 프로세스들을 이해하는 문제는 다루어지지 않았다. 블랙 박스 접근 방식에서, 성능, 보안, 관리, 관리성 같은 비 기능적 요구 사항들(NFR)은 아키텍처 디자인에서 종종 간과되었다. 블랙 박스에서 실행되는 애플리케이션과 데이터는 강결합 되었다. 이러한 강결합은 비즈니스 프로세스의 수정과 재생산을 거의 불가능하게 만들어 놓았다.

SOA 환경에서, 비즈니스 태스크들은 비즈니스 프로세스에 참여하는 일련의 "서비스들"을 실행함으로써 달성된다. 이 서비스들은 잘 정의된 방식으로 다른 서비스와 통신한다. 서비스가 기대한 방식대로 대응하고 사용자가 원하는 서비스 품질을 제공한다면, 서비스 구현은 사용자에게 문제가 되지 않는다. 다시 말해서, 서비스는 안전하고, 신뢰성 있으며, 빨라야 하고, 여러 벤더들의 소프트웨어와 하드웨어가 전개되어 있고, 기존 IT 에셋들이 더 새로운 애플리케이션, 통합 기술, 데이터 소스와 혼합되어 있는 IT 환경에서 SOA가 적합하다.

많은 비즈니스와 IT는 레거시 인에이블먼트에 SOA를 사용함으로써 효과를 누리고 있다. 비즈니스 측면에서는, 기존 에셋들과 시스템들, 일반적으로 비즈니스 프로세스와 복합 애플리케이션(예를 들어, 포털 애플리케이션)에서 새로운 가치를 만든다. SOA는 이전에는 일괄 트랜잭션이었던 것으로 실시간 액세스를 제공하고, 비즈니스 결정을 내리는데 속도와 정확성을 높인다. SOA를 통해 중대한 비즈니스 데이터와 애플리케이션들을 재사용하면 더 나은 고객 서비스를 제공할 수 있고, 고객 유지도 가능해진다.

SOA에서는 최고급의 서비스 품질을 활용할 수 있고, 중요한 프로세스와 데이터를 다른 용도에도 쓸 수 있다. 더욱이, SOA에서는 기존 레거시 투자와 개발자 기술을 확장 및 보호하면서, 엔터프라이즈의 다른 시스템들과의 상호 운용성도 높이고 고객, 파트너, 공급자의 시스템과도 상호 운용성을 높일 수 있다.

오래된 것과 새로운 것에서 최고의 것을 가려내어 활용하면서, 기존 에셋들을 활용할 수 있다. 이를 시작할 때, 비즈니스는 더욱 유연해지고 고객들에게 더 나은 서비스를 제공하며 운영도 향상된다. 기민성(agility)은 "온 디맨드 비즈니스"에서 추구하는 것이고, SOA는 레거시 인프라스트럭처가 계속해서 새롭고 더 나은 방식으로 작동할 수 있게끔 하고 있다.

위로

레거시 채택과 변형에 SOA가 미치는 영향

대부분의 기업들은 SOA를 비즈니스와 IT 조직들간 유기적인 관계로 보고 있다. SOA는 비즈니스 디자인을 파악하는 툴과 방식을 포괄하고 있고, 그러한 디자인 정보를 사용하면 비즈니스를 향상시킬 수 있다. SOA는 그러한 구현을 호스팅 및 관리하는 미들웨어와 관리 인프라스트럭처도 관장하고 있다. 또한, SOA는 그러한 혜택에 대한 가치도 높이고 있다.

많은 사람들은 레거시 기반 애플리케이션들이 현대적인 분산 애플리케이션들 보다는 SOA 환경의 일부로서 노출되는 것이 더욱 적합하다고 믿고 있다. 개발자들이 수년 전에 메인프레임 애플리케이션들을 작성했을 때, 비즈니스 기능의 관점에서 작성했다. 고객을 더하고, 제품을 주문하고, 사용자를 삭제하고, "여행자와 관련한 비행기 번호 제공" 등은 일반적으로 필요한 액션들이었다. 결국, 이러한 오래된 레거시 애플리케이션들은 비즈니스와 IT 조직들 사이의 혼합을 고수하고 있다.

SOA는 다음과 같이 레거시 애플리케이션들의 가치를 높이고 있다.

• 서비스를 연결하는 일관된 방식과 서비스를 통합하는 일관된 프레임웍을 제공함으로써 복잡성을 줄인다.
• 정적인 서비스 연결을 동적인 연결로 대체하고 변화에 대한 저항력을 줄이면서, IT가 비즈니스 프로세스에서 변화를 따라갈 수 있도록 한다.
• 재사용을 위한 환경을 제공하고 일관성을 장려한다.
• 서비스를 감시하고 관리하는 일관된 방식을 제공함으로써 운영을 단순화 한다.
• 서비스 컨테이너에서 리소스와 기타 관리 태스크를 핸들링 함으로써 서비스 구현을 단순화 한다.

위로

SOA 레거시 변형의 세 단계

레거시 채택 방식은 세 가지 주요 범주로 나뉠 수 있다.

사용자 경험 향상시키기
애플리케이션 인터페이스를 사용하기 어렵고 사용자 워크플로우가 시대에 뒤쳐진 상황에서, 기업들은 고객 또는 엔드 유저의 온라인 경험을 향상시킬 수 있는 액션을 취한다. 일반적으로, 오래된 "그린 스크린"에서 업그레이드 하고, 사이트 네비게이션을 향상시키고, 간단한 웹 기반의 포인트&클릭 인터페이스를 제공하고, 미리 채워진 필드 기능을 추가하여 온라인 고객들이 보일러플레이트 정보(청구 주소)만 입력하도록 할 수 있다. 이 단계는,

• 신속한 투자 회수(ROI)를 제공한다.
• 엔드 유저 경험을 향상시킨다.
• 적게 투자할 수 있고 실패율도 낮다.
• 고객의 만족도를 높인다.

향상된 관계에 순응하기
레거시 애플리케이션들이 현대적인 워크플로우에 쉽게 통합될 수 없을 때, 기업들은 자신들의 애플리케이션들이 온 디맨드 워크플로우에 참여할 수 있도록 개선한다. 전체 플랫폼을 대체하는 위험 부담이 없다. 이 단계에서는,

• 비즈니스가 그 범위를 확장할 수 있다.
• 작은 변화만 필요하거나 또는 어떤 변화도 필요 없다.
• 최소한의 투자로도 가능하다.
• 고객의 만족도를 높인다.

새로운 기능으로의 혁신
변화하는 비즈니스나 시장 조건에 미션 수행에 중요한 프로세스를 적응시키기가 까다로운 상황에서, 기업들은 레거시 애플리케이션들을 사용하여 완전히 새로운 솔루션을 만들고 있다. 기존의 중요한 애플리케이션들에 어떤 것이 있었는지를 이해함으로써, 기업은 그러한 애플리케이션들을 재구현 및 "컴포넌트화"할 수 있고, 이러한 부분들을 새롭고 차별화된 솔루션으로, 궁극적으로는 서비스 지향 아키텍처로 통합할 수 있다. 이 단계의 특징은 다음과 같다.

• 기존 애플리케이션의 리엔지니어링(Reengineering)
• 더욱 높은 투자
• 컴포넌트화
• API 코드 재사용

위로

기존 레거시 패턴 변형하기: CICS

CICS에서 실행되는 전통적인 (구) 애플리케이션들은 영역(concern)을 확실히 분리해 놓지 않았다. 표현 로직과 비즈니스 로직이 단일 프로그램으로 강결합 되었기 때문에 3270 인터페이스가 제공되었다. 따라서 전통적인 애플리케이션들을 SOA 패러다임으로 변형 및 순응시키기가 매우 어렵게 되었다. 그림 2는 전통적인 CICS 애플리케이션을 묘사한 것으로서, 표현(P)와 비즈니스 로직(B)가 데이터 모델(D)에 액세스 하고 있다.

최신 CICS 애플리케이션 디자인의 베스트 프랙티스는 애플리케이션의 핵심 엘리먼트들을 분리했다. 이러한 엘리먼트에는 표현 로직, 통합 로직, 비즈니스 로직, 데이터 로직이 포함된다. 개념은 각 엘리먼트를 원래의 애플리케이션에서 분리될 수 있는 하위 루틴이나 서비스로서 재사용 할 수 있는 기능을 제공한다. 예를 들어, 비즈니스 로직을 웹 서비스로서 래핑하는 것도 가능하다. 그림 3은 SOA 순응과 변형을 위한 후보로서 충분한 디자인을 묘사하고 있다.

CICS에서의 웹 서비스 공급자와 요청자

웹 서비스는 인터넷 프로토콜을 통해서 XML, SOAP, Web Services Description Language (WSDL), Universal, Description, Discovery and Integration (UDDI) 오픈 표준을 사용하여 웹 기반 애플리케이션들을 통합하는 표준화된 방식을 의미한다. XML은 데이터에 태그를 다는데 사용되고, SOAP은 데이터를 전송하는데, WSDL은 여러 서비스들을 기술하는데 사용되고, UDDI는 사용 가능한 서비스를 리스팅 하는데 사용된다. 비즈니스가 서로 통신하고 클라이언트와 통신하는 주요 수단으로서 사용되는 웹 서비스는 기업들이 방화벽 뒤의 IT 시스템들에 대해 알 필요 없이 데이터를 주고 받을 수 있게 한다.

그림 4의 CICS 애플리케이션들은 다음과 같은 표준에 순응하는 웹 서비스를 사용하여 웹 서비스 공급자가 될 수도 있고 요청자가 될 수도 있다.

• SOAP 1.1와 1.2 (웹 서비스 메시지 송수신)
• WS-I Basic Profile 1.0a (SOAP 1.1을 사용한 공급자와 요청자 간 상호 운용성)
• WS-Coordination (확장 가능한 조정 프레임웍과 원자 트랜잭션 조정)
• WS-AtomicTransaction (트랜잭션 조정)
• WS-Security (모든 메시지 또는 일부 메시지의 인증과 암호화): SOAP Message Security, Username Token Profile 1.0, X.509 Certificate Token Profile
• SOAP over HTTP/1.1과 IBM® WebSphere® MQ (애플리케이션과 IT 요구 사항에 기반한 유연한 전개)

CICS에 액세스 하는 Java Connector Architecture

Java™ Connector Architecture (JCA)는 레거시 CICS 같은 이종의 엔터프라이즈 정보 시스템으로의 연결을 위한 J2EE 표준이다. (그림 5) CICS Transaction Gateway는 JCA 커넥터를 리소스 어댑터로서 제공한다. JCA 어댑터는 레거시 시스템에 거의 필요하지 않다. 이들은 네이티브 API, 소켓, 데이터 액세스, 기존 코드 베이스를 수정할 필요가 없는 다른 기술들을 사용하여 레거시 시스템에 액세스 한다. 이러한 방식은 전개 시 시스템에 이미 제공된 투자를 활용하는 기능을 제공하고, 이는 추가 리소스를 투자하여 통합을 지원하도록 시스템을 업데이트 하는 것과는 다르다.

CICS에 액세스 하는 Enterprise JavaBeans

Enterprise JavaBeans (EJB) 컴포넌트는 다양한 위치에 있는 다른 플랫폼들에 컴포넌트가 배치될 수 있는 분산 비즈니스 애플리케이션들을 지원한다. 자바 클라이언트는 RMI over IIOP를 사용하여 원격 객체를 호출할 수 있다. (그림 6) CICS는 EJB를 기본적으로 지원한다. 이-비즈니스 클라이언트는 RMI over IIOP를 사용하여 CICS 내에서 실행되는 EJB 컨테이너와 통신한다. CICS 컨테이너는 JCA 또는 메시지 어댑터를 사용하여 CICS 영역이나 개별 영역에서 실행되는 비즈니스에 액세스 한다.

CICS에 액세스 하는 WebSphere MQ

WebSphere MQ는 이종의 플랫폼들간 쉬운 정보 교환을 지원하면서, 기존의 비즈니스 애플리케이션들을 통합한다. WebSphere MQ는 안전하고 보장된 메시지 전달을 보증하며 다양한 플랫폼에서 클라이언트가 사용할 수 있는 Java Message Service (JMS) API와 네이티브 MQ API를 제공한다.

WebSphere MQ 트리거 모니터 프로그램은 CICS에서 실행된다. 메시지가 도착하면, 새로운 트랜잭션에 새로운 어댑터 프로그램이 시작된다. 메시지 어댑터는 WebSphere MQ 네이티브 API를 사용하여 메시지를 받고, 필요할 경우 이를 변형하며, CICS 비즈니스 로직 프로그램(B)를 호출한다. (그림 7)

CICS에 액세스 하는 WebSphere Message Broker

WebSphere Message Broker (Message Broker)는 다양한 인터랙션 패턴, 프로토콜, 메시지 포맷을 사용하여 광범위한 애플리케이션들을 연결할 수 있다. Message Broker를 통해 전달되는 메시지들은 목적지로 가는 도중에 다양한 포맷들로 라우팅 및 변형된다.

Message Broker는 광범위한 소스에서 다양한 포맷으로 된 메시지를 받아서 이들을 필요에 따라 라우팅 및 변형하여, 애플리케이션들이 기대하는 포맷과 프로토콜로 애플리케이션에 의해 소비될 수 있도록 보내진다. 이러한 멀티스텝(multistep) 프로세스가 메시지 브로커링(message brokering)의 큰 특징이다.

CICS 트랜잭션 프로그램에 MQ가 실행되거나 CICS DPL 또는 3270 브릿지를 사용한다면, 브로커에 의해 생성된 MQ 메시지들을 사용하여 CICS 트랜잭션을 실행할 수 있다. 하지만, 브로커의 관점에서 볼 때 이러한 방식에는 단점들이 있다.

• 플로우는 여러 레그(leg)들로 나뉘는데, 이것 때문에 프로세싱이 더 복잡해진다.
• 프로세싱을 실현하기 위해서는 더 많은 트랜잭션이 필요하다.
• 요청 콘텍스트는 CICS로부터 응답이 리턴될 때 다시 만들어져야 하는데, 이는 원래의 인풋 메시지를 재 파싱하는 등 값비싼 연산을 필요로 한다.

CICS 요청 노드에서는 CICS 프로그램이 메시지 플로우 내에서 동기식으로 실행될 수 있고, 플로우 구조가 단순화 되고, 트랜잭션의 수를 줄이며, 요청이 CICS에 의해 핸들되는 동안 프로세싱 콘텍스트를 유지할 수 있다.

CICS 노드를 사용한 Message Broker V6 프로세싱(그림 8)은 매우 단순화 되고 성능을 3X (Support Pac IA12 참조)까지 높인다. CICS 노드는 인풋 메시지의 노드 정의 부분에서 COMMAREA를 추출하고 EXCI 인터페이스를 사용하여 적절한 트랜잭션 프로그램을 실행한다. COMMAREA는 트랜잭션 완료 시 메시지 트리에 추가된다. CICS 트랜잭션 프로그램은 RRS 작업 단위 내에서 실행되거나, 노드 애트리뷰트에 따라서 즉각적으로 위임된다.

위로

요약

기업의 IT 팀은 비즈니스에 가치를 더할 수 있는 새로운 방식을 생각해야 한다. 새로운 비즈니스 모델을 생성하거나 기존 모델들을 변형해야 한다. 이 글에서는 기존의 레거시 기반 시스템들을 SOA 환경에 순응시킬 수 있는 변형과 방법들을 살펴보았다. 문제를 해결하기 위해 올바른 패턴을 선택하는 것이 가장 중요하며, 이것은 궁극적으로 비즈니스 목표를 달성할 수 있는 성공을 가름한다.

기존 레거시 기반 시스템들을 변형하는데 빠른 픽스란 없다. 신속하고 유연한 엔터프라이즈가 되는 여정에는 인내가 필요하다. 하지만, 이 여정을 통해서 이득도 볼 수 있다. 굳이 변형이 완료될 때까지 기다릴 필요는 없다.

• 총 소유 비용 감소
• 기존 레거시 시스템들보다 엔드투엔드 상호 운용성 증가
• 기존의 비즈니스 애플리케이션들의 기능 보존
• 값비싼 시스템들을 제거함으로써 위험 요소 완화
• 인프라스트럭처와 하드웨어 투자를 더욱 활용하여 더 나은 가치 창출
• 변형 프로젝트 동안 셀프 펀딩(Self-funding) 가능
• 현대적이고 유연한 기술에 기반한 향상된 비즈니스 서비스를 통한 경쟁력 강화

참고자료

• "서비스 지향 아키텍쳐와 통합을 위한 패턴 언어, Part 1: 서비스 생태계 구현하기 (한글)" SOA, 패턴, 통합에 대한 개요.
  
  
• "Implementing CICS Web services," (IBM Redbooks®).
  
  
• "Migration considerations for CICS using CICS CM, CICS PA, and CICS IA," (IBM Redbooks).
  
  
• "Legacy Modernization with WebSphere Studio Enterprise Developer"
  
  
• "AMS Legacy Transformation.
  
  
• developerWorks 아키텍처 존
  
  
• 한국 developerWorks SOA와 웹서비스 존
  
  
• technology bookstore
  
  
• IBM 온 디멘드 데모
  
  
• developerWorks 기술 이벤트와 웹캐스트.
  
  

• and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, WebSphere® 등의 IBM 제품 평가판 다운로드.

• developerWorks 블로그와 한국 developerWorks 커뮤니티 참여하기.
  
  

필자소개

		Calvin Lawrence는 IBM Sales and Distribution Organization, East Region의 SOA 분야 아키텍트이다. 전략적 이니셔티브의 지원과 IBM 기술을 사용한 성공적인 구현을 통해 IBM 아키텍처, 기술, 제품들을 향상시키는 책임을 맡고 있다. IBM Software Group Worldwide Technical Leadership Council의 의장을 역임했다.

기사에 대한 평가

보다 나은 서비스를 제공하기 위함이오니 잠시 짬을 내어 이 양식을 제출하여 주십시오. 귀하께서 원하시는 정보를 얻었습니까? 예 아니오 잘 모르겠음   이 페이지 개선을 위한 의견을 주십시오:   이 정보가 얼마나 유용했습니까? (1 = 전혀 도움이 되지 않음, 5 = 매우 유용함) 1 2 3 4 5

위로