이벤트 중심 비즈니스 작동

비즈니스는 제품이나 서비스 또는 이 두 가지 모두를 고객에게 제공하기 위해 존재한다. 이러한 과정은 제품이나 서비스를 직접 제공하거나 이러한 제품이나 서비스의 전달이나 성과를 지원하는 매우 다양한 수동 비즈니스 또는 자동화된 비즈니스 조작(프로세스)을 수행함으로써 이루어진다. 이러한 프로세스를 트리거하는 것을 비즈니스 이벤트라고 하며 일정 조건이 만족되면 특정 비즈니스 프로세스가 실행될 것이라는 점을 나타낸다. (자세한 정보를 확인할 수 있는 링크는 참고자료를 확인한다.) 예를 들면, 고객이 휴대전화를 새로 구매하고자 하는 경우에는 고객 구매 이벤트가 발생하며 이 이벤트는 그림 1과 같이 비즈니스 프로세스에서 일련의 조작(예:재고품 목록 업데이트, 청구 준비 및 원하는 서비스 제공)을 수행하여 이러한 요청을 이행해야 한다는 것을 나타낸다. (그림 1의 확대 이미지 보기)

이러한 트리거 이벤트는 다른 비즈니스 이벤트를 단계적으로 촉발하여 전체 비즈니스 프로세스를 완료한다. 이전의 고객 구매 이벤트에서는 서비스를 제공하려면 새로운 서비스 이벤트와 같은 업데이트를 수신할 많은 내부 시스템이나, 자체 작동을 통해 비즈니스 이벤트 트리거에 응답해야 하는 외부 파트너가 필요하다. 비즈니스가 제대로 이행되려면 이처럼 복잡한 비즈니스 구성이 매일 수백, 수천 번이나 성공적으로 수행되어야 한다. 복잡한 비즈니스 조작을 추적하고 관리하려면 어떤 비즈니스 이벤트가 언제 발생하는지 파악할 수 있는 기능이 분명히 필요하다.

위로

고객 활동에 대한 응답

조작에 집중하는 것 외에도 비즈니스에서는 개인 고객 관계에 대한 개념의 가치가 점차 높아지고 있다. (자세한 정보를 확인할 수 있는 링크는 참고자료를 참조한다.) 조직에서는 다양한 범주의 고객 행동(즉, 인구 통계학적 데이터)을 사용하여 어떤 고객 그룹이 제품이나 서비스를 선호하는지 나타내는 대신 대상 마케팅에 맞춰 개별 고객 행동을 분석한다. 예를 들면, 많은 슈퍼마켓 체인에는 고객의 구매 행동을 파악하는 것에 대한 대가로 즉시 할인을 해주는 고객 충성도 프로그램이 있다. 나중에 이 정보는 자주 구매한 제품을 기반으로 대상 쿠폰을 제공하는 데 사용된다. 개별 고객이 시작한 행위(일련의 연속된 비즈니스 이벤트)를 추적하는 기능은 고객이 해당 비즈니스와 상호 작용할 때마다 직접적인 상향 판매 및 교차 판매 기회를 통해 고객의 가치를 향상시킬 수 있는 강력한 메커니즘을 제공한다.

게다가 시간이 지나면서 이러한 행동을 추적하는 기능은 고객 유지 행위를 예측하는 데 필요한 데이터를 제공한다. 가장 일반적인 유지 노력은 불필요한 절차를 줄이거나 고객이 경쟁사로 이동하지 않도록 하는 데 있지만, 이러한 활동은 일반적으로 반작용적인 것이다. 다시 말해서 유지 행위는 고객이 비즈니스에 불만족을 표시한 후에만 취해진다. 그렇지만 고객 서비스에 전화가 자주 오거나 특정 제품이 반품되는 경우와 같이 고객이 서비스나 제품에 만족하고 있지 못하다는 것을 표시하는 여러 가지 중요한 경고 신호가 있다. 비즈니스가 이러한 이벤트를 개별 레벨에서 파악하고 추적할 수 있으면 회복할 수 없는 단계에 이르기 전에 미리 대책을 강구하여 고객의 경험과 회사와의 관계를 개선할 수 있다.

위로

이벤트 중심 비즈니스 인텔리전스

정상적인(또는 비정상적인) 비즈니스 조작 과정에서 발생하는 다양한 비즈니스 이벤트를 이해하는 것은 대단한 가치가 있다. 복합 이벤트 처리라고도 하는 비즈니스 이벤트 패턴을 파악하고 분석하면 사기 행위 발견, 재무지표 감사 및 침입 탐지를 포함한 다양한 비즈니스 의사결정을 수행할 수 있다. 애플리케이션 로깅은 내부 비즈니스 시스템 안에서 이루어지는 작업을 면밀하게 살펴볼 수 있는 정보를 제공하는 제대로 확립된 수단이며 오랫동안 시스템의 결함을 찾고 제거하는 데 사용되었다. 최근 몇 년 동안 로그 파일은 비즈니스 인텔리전스의 다른 영역에 적용되어 고객의 행동을 파악할 수 있는 정보를 얻는 데 사용되었다.

불행히도 파일 기반 로깅은 여러 가지 이유로 이러한 용도로는 적합하지 않다. 첫째, 로그 항목이 일회성 시스템 레벨 이벤트를 기반으로 하며 일반적으로 상위 레벨 비즈니스 드라이버와 연결되어 있지 않다. 둘째, 애플리케이션 개발자들이 로깅 노력의 기본적인 수혜자이기 때문에 다음 두 가지 예제에서 알 수 있듯이 로그 항목마다 구문과 컨텐츠 다르고 해석하기 어려운 경우도 자주 있다.

Example 1 (from Java application): 
08:50:49,664 FATAL LogClass:33 – Log Attempt Failed (btrack@metatelecommunications)

Example 2 (from web server):
April 3, 2010 (23:04:05) 45:T50 Log attempt failure – 772, 81gAt

로그 정보는 다양한 조작 레벨(비즈니스, 서비스, 애플리케이션, 데이터베이스, 네트워크, 인프라)에서 다양한 목적(비즈니스 인텔리전스, 운영 지원, 보안, 감사)으로 필요하다. 로그 항목은 데이터베이스, 네트워크 디바이스 또는 애플리케이션과 같은 특정 시스템 환경 내에서만 생성되므로 오래 실행되는 비즈니스 트랜잭션(즉, 비즈니스에서 가장 중요한 트랜잭션)은 다수의 시스템을 통해 추적하기가 어렵다. 일반적으로 비즈니스 트랜잭션 내에서 로그 항목 간의 상관 관계를 식별할 수 있는 공통 메커니즘은 없다.

현재의 애플리케이션 레벨 로깅 메커니즘은 대부분 다음과 같이 다양한 문제점을 안고 있다.

• 애플리케이션, 데이터 저장소, 서버 및 네트워크 요소는 모두 다양한 구문과 메커니즘 및 추적 레벨(예: 치명적 오류, 정보, 경고)을 사용하여 다양한 방식으로 로깅을 처리한다.
• 다양한 레벨(비즈니스, 애플리케이션, 데이터 저장소 또는 네트워크)에서 생성된 이벤트를 결합하여 이벤트 간의 인과 관계(즉, 비즈니스 이벤트 1로 인해 이벤트 A, B, C가 발생)를 판별하는 것이 불가능하지는 않지만 어렵다.
• 로그 정보는 비즈니스상의 필요성 때문이라기보다는 개발 또는 운영상의 필요성에 의해 더 많이 사용되며 이 로그 정보에는 적절한 해석이 중요한 정보가 없을 수도 있다.
• 상위 레벨 시스템 이벤트와 하위 레벨 시스템 이벤트를 구성하기 위한 이벤트 택소노미(즉, 잘 정의된 이벤트 설명 항목 세트)의 개념이 없다.
• 파일 기반 로그를 검색 가능하고 이해할 수 있는 데이터 저장소로 변환하려면 추가 처리 작업이 많이 필요하다.
• 협력하는 여러 시스템 간의 상호 작용(서비스 프로비저닝과 같은 복잡한 트랜잭션에서 필요함)은 이러한 조작의 비동기적인 특성 때문에 쉽게 추적하거나 연결할 수 없다.
• 복잡한 이벤트 패턴 일치, 특히 고객이 시작한 이벤트, 사기 시도 또는 보안 침입과 같은 중요한 상황을 실시간으로 대처하는 데 필요한 프로비저닝이 없다.

위로

엔터프라이즈 이벤트 관리 프레임워크

EEMF(Enterprise Event Management Framework)의 목적은 이벤트를 생성하고 다른 시스템에서 생성하는 이벤트에 응답할 수 있도록 조직 내에 있는 새 애플리케이션과 레거시 애플리케이션에 필요한 경량 메커니즘을 제공하는 데 있다. 여러 가지 면에서 EEMF는 서비스 지향 아키텍처와 비슷하지만, 시스템 서비스 세트에 인터페이스를 정의하는 대신 EEMF에서는 기존 애플리케이션과 서비스에서 공통으로 액세스 가능한 위치에 이벤트를 로그한다. 더욱이 이벤트 알림(예: 복합 이벤트 프로세서 규칙 엔진이나 실시간에 가까운 이벤트 비즈니스 분석) 대상으로 등록되는 기타 시스템이 중요한 이벤트가 발생할 때마다 알림을 받을 수 있다.

EEMF에는 다음과 같은 다섯 가지 중요한 컴포넌트가 있다.

• 이벤트 택소노미는 잘 정의된 계층 구조에서 각 이벤트와 그 아래 및 위에 있는 다른 이벤트와의 관계를 명확하게 식별하는 비즈니스 이벤트 제어 어휘이다.
• 이벤트 식별은 이벤트 트리에 있는 하위 이벤트와 상위 이벤트를 포함한 기타 모든 이벤트에 대해 이벤트를 전체적으로 고유하게 식별한다.
• 이벤트 구조는 이벤트의 시작점(시스템 및 사용자 정보)과 트리거된 비즈니스 프로세스에서 사용된 특정 이벤트 데이터가 포함된 이벤트 관련 핵심 설명 정보이다.
• 이벤트 전송은 이벤트를 생성하고 보장된 정규 시간 내에 이벤트에 응답하는 메커니즘이다.
• 이벤트 지속성은 감사 및 비즈니스 인텔리전스를 위해 이벤트 정보를 장기간 저장하는 것을 말한다.

그림 2에는 이러한 컴포넌트가 표시되어 있다.

이벤트 택소노미

이벤트 택소노미는 점점 더 상세해지는 방식으로 각 이벤트 유형을 고유하게 식별하는 방법을 제공한다. (이 방법은 이벤트 데이터 페이로드 구조를 논의하는 과정에서 중요하게 다루어진다.) 각 항목은 트리 자체의 특성을 기반으로 하는 이벤트 택소노미 ID에 의해 고유하게 식별된다. 예를 들면, 그림 3에 표시된 바와 같이 고객(Customer)은 택소노미 ID가 A이고 구매(Purchase)는 택소노미 ID가 A1이며 새 항목은 택소노미 ID가 A13이다. 계층 구조 레벨마다 ID에 하나의 문자 위치를 사용하는 이러한 접근 방식을 이용하면 다른 항목의 ID를 재지정하지 않고도 새 항목을 트리에 삽입할 수 있다.

이벤트 식별

이벤트 택소노미 이외에도 다음과 같은 두 가지 이유 때문에 생성된 각 이벤트를 고유하게 식별해야 한다. 첫째, 잘못된 순서로 생성된 이벤트를 적절한 순서(예: 시간 소인 순)로 배치할 수 있고 둘째, 어떤 이벤트가 다른 이벤트를 발생시켰는지 알 수 있고 이벤트의 인과관계를 파악할 수 있다. 각 이벤트는 이러한 인과관계를 통해 상위 이벤트 및 하위 이벤트와 연결된다. 트리에 있는 모든 이벤트를 파악하면 이러한 고유 ID를 사용하여 전체 트리를 재구성할 수 있다(그림 4 참조).

상위 이벤트와 하위 이벤트의 관계를 추적할 수 있도록 하기 위해 EEMF 아키텍처에서는 PCI(Propagating Composite Identifier) 개념을 도입했다. PCI는 이벤트 트리 맨 위에서 시작하여 모든 후속 이벤트로 전달된다. 목록 1에 표시된 바와 같이 PCI는 GUID(Globally Unique Identifier) 세트를 이용하여 작성되며 이 GUID 세트를 각 후속 이벤트로 전달하고 이 이벤트의 GUID와 함께 추가하여 복합 ID를 작성한다. 현실적으로 말하면 이는 이벤트 GUID가 이벤트 트리에 있는 네트워크 요소나 애플리케이션에서 수행되는 모든 이벤트 로그 호출의 필수 매개변수가 된다는 것을 의미한다. 이렇게 하려면 레거시 시스템에서는 메소드 호출을 계속하기 전에 이벤트를 캡처하는 방식으로 API 호출을 둘러싸야 한다.

	
Event #1: 
	Customer.Purchase.Change Composite Event ID =
				{4ef9ff68-d50d-4c0a-98cc-b60179ba238d}
Event #1.1: 
	Customer.Purchase.Change.Mobile_Number Composite Event ID =	
				{4ef9ff68-d50d-4c0a-98cc-b60179ba238d}::
				{83dfd56a-e973-4f74-9cf9-ae2a901f80d2}
Event #1.2: 
	Customer.Purchase.Download.Equipment Composite Event ID =	
				{4ef9ff68-d50d-4c0a-98cc-b60179ba238d}::
				{c5eb0984-fce4-45c7-8aa5-809da165ca15}
Event #1.2.1: 
	Customer.Purchase.Download.Equipment.Mobile Composite Event ID =
				{4ef9ff68-d50d-4c0a-98cc-b60179ba238d}::
				{c5eb0984-fce4-45c7-8aa5-809da165ca15}::
				{aed0dd16-6a1b-4bbd-90a4-a30f0c939bca}

이벤트 트리가 완료되면 복합 키를 조사하여 상위 키를 얻은 다음 루트 상위 키(복합 키의 첫 번째 키)를 사용하여 기타 모든 관련 노드를 얻어서 정렬함으로써 트리에 있는 모든 이벤트를 이용하여 이벤트 트리를 재구성할 수 있다.

각 이벤트 트리를 시작하는 비즈니스 트랜잭션의 구조를 캡처하기 위해 페이로드의 이벤트 헤더에는 트랜잭션 ID의 속성이 포함되어 있다. 그러나 상위 이벤트를 생성하는 과정에서 이 값을 삽입하는 역할은 시작 애플리케이션이 담당한다. 더 아래쪽 트리에 있는 이벤트에서는 이 값이 거의 사용되지 않으며 이 값을 유지하거나 다른 이벤트로 전달할 필요가 없다.

이벤트 구조

각 이벤트에는 모든 이벤트에 광범위하게 적용되지만, 해당 이벤트에 특정된 일련의 정보(예: 이벤트 이름, 이벤트 GUID 및 이벤트 키)가 포함되어 있다. 이벤트 메시지의 기본 구조는 그림 5와 그림 6에 있는 XML 문서로 표시되어 있다. <event-context> 태그과 더불어 <event> 태그는 XML 문서의 루트 요소를 나타내며 모든 이벤트에 광범위하게 적용되는 정보를 포함하고 있다. 이벤트 컨텍스트를 이용하면 각 이벤트에서 이벤트가 생성된 위치와 이 이벤트를 생성한 사람을 표시하고 이벤트가 생성된 시점에서의 실행 환경에 대한 세부사항을 제공할 수 있다. 또한, 그림 5에 표시된 바와 같이 이벤트 컨텍스트에는 보안 감사(예: 사용자 ID)에 사용할 수 있는 정보가 포함되어 있다.

나머지 이벤트 메시지는 이벤트 "페이로드"(그림 6)로 지정된다. 이벤트 페이로드에는 각 이벤트 유형에 고유한 정보(예: 일반적으로 이벤트 택소노미 트리의 각 이벤트 레벨에서 XML 속성으로 캡처된 정보)가 포함되어 있다. 예를 들면, <customer> 태그에는 특정 고객에 고유한 정보(예: 성, 이름 및 기타 식별 데이터)가 들어 있다. 각 추가 태그에는 이벤트 트리를 전체적으로 조망할 수 있는 전체 이벤트에 대한 정보가 포함되어 있다.

또한, 이벤트가 한 시스템에서 다른 시스템으로 전파된다고 해서 각 레벨에서 제공된 데이터가 반드시 중복되는 것은 아니다. 예를 들면, 시작 애플리케이션(즉, 고객 관리 애플리케이션)에 고객 및 구매와 관련된 상위 레벨 정보는 있지만, 지정된 디렉토리 번호(MIN/MDN) 또는 장비 번호(MEID)와 같은, 하위 레벨 이벤트 정보는 없을 수도 있다. 택소노미에서 태그를 추가하고 상위 레벨 태그를 비어 있는 상태로 유지하여 해당 레벨에서 캡처할 수 있는 정보를 후속 이벤트에서 생성할 수도 있다.

이벤트 전송

정의된 이벤트 택소노미와 ID 및 구조를 사용하려면 애플리케이션 개발자가 이벤트 메시지를 손쉽게 작성하고 게시할 수 있는 메커니즘이 있어야 한다. EEMF 환경에서는 ESB(Enterprise Service Bus)와 EMS(Enterprise Messaging Service)를 통해 이 메커니즘을 제공한다. ESB는 이벤트 생성기와 등록자가 이벤트 메시지 큐 및 주제와 상호 작용할 수 있는 일련의 서비스를 제공한다. 요약된 이벤트 전송 서비스가 그림 7에 표시되어 있다. (그림 7 크게 보기)

이벤트 생성기 애플리케이션이 이벤트의 복합 ID로 GetEventGUID() 메소드를 사용할 수 있도록 이벤트 서비스가 제공된다. 또한, 서비스를 제공하기 위해 이벤트 계층에 대해서는 ValidateEvent() 메소드를 사용하고 처리를 위해서는 PostEvent() 메소드를 사용한다. 마지막으로 RegisterEventSubscriber() 메소드와 DeregisterEventSubscriber() 메소드를 사용하여 관심 대상을 특정 이벤트에 등록하거나 등록 해제할 수 있다.

이벤트 메시지 큐에 게시된 이벤트는 특정 이벤트 주제와 관련된 이벤트 메시지를 게시하는 정규화된 메시지 라우터에 의해 즉시 처리된다. 이벤트 주제는 이벤트 택소노미를 기반으로 구성된다. 예를 들면, 첫 번째 주제는 고객 이벤트 주제이다. 표준 메시지 처리 메커니즘을 사용하면 ESB를 통해 EMS에 제출된 이벤트가 메시지 전달이 보장될 수 있게 구성된다. 모든 이벤트 메시지가 제대로 구성되도록 ValidateEvent() 서비스를 사용하여 이벤트 데이터의 품질을 관리한다. 그러나 이 시점에서는 이벤트 페이로드에 포함된 실제 데이터는 유효성이 검증되지 않는다. 메시지 필터링은 등록자 주제 레벨에서 처리된다. 유효성 검증에 실패한 이벤트는 거부되어 오류로서 호출 이벤트 생성기로 되돌아 가며 오류 조건에서 이벤트가 잘못된 원인과 유효성 검증에 실패한 원인이 자세히 기술된 예외 이벤트가 생성된다.

이벤트 지속성

ESB/EMS에서 생성된 이벤트는 장기적인 분석과 감사를 위해 저장해야 한다. 이벤트 데이터 마트 저장소에는 이벤트가 유지되는 기간이 설정된 이벤트 유지 창이 정의되어 있다. 이벤트 유지 창은 이벤트 메시지를 유지해야 할 필요성을 표현함으로써 정의되며 분석과 비즈니스 검토에 필요한 시간을 제공하기 위해 이벤트 유지 기간은 60일 이상이 되어야 한다. 이벤트가 저장되는 기간은 주로 생성된 이벤트 수와 사용 가능한 저장 공간에 따라 달라진다. 60일 동안은 첫 번째 티어에 있는 스토리지를 활용한 다음, 데이터를 비용이 저렴한 두 번째나 세 번째 티어에 있는 스토리지로 이동하여 온디맨드 데이터와 스토리지 비용 간에 타협을 보는 것이 합리적이다.

제공된 이벤트 페이로드 정의를 기반으로 데이터 스토리지 요구사항을 추정한 내용이 표 1에 표시되어 있다.

위로

결론

비즈니스 이벤트는 비즈니스의 성능에 관한 다양한 정보를 의미하며 고객과 비즈니스 파트너의 행동을 통찰할 수 있는 방법이기도 하다. 잘 정의된 이벤트 택소노미와 구조를 다양한 이벤트를 서로 연결해주는 글로벌 메커니즘 및 엔터프라이즈 전체에서 사용 가능한 전송 메커니즘과 함께 사용하면, 관련된 모든 비즈니스 이벤트를 캡처하고 분석할 수 있다. 이 시리즈의 다음 기사에서는 프로토타입 엔터프라이즈 이벤트 관리 시스템을 개발하여 이러한 시스템이 실제로 어떻게 작동하는지 살펴본다.

참고자료

교육

• 이벤트 관리 및 복합 이벤트 처리의 비즈니스 가치가 잘 소개되어 있는 David Luckham의 The Power of Events(Addison-Wesley, 2002년) 기사를 확인하자.
  
  
• 비즈니스 고객 관계 개발의 가치와 실행을 이해하려면 Don Peppers와 Martha Roger가 작성한 Managing Customer Relationships(John Wiley and Sons, 2004년) 기사를 검토한다.
  
  
• 고객 관계 관리에 대한 개요가 잘 기술되어 있는 Marcus Wübben의 박사 논문, Analytical CRM from Technische Universitat München(2008년)을 확인하자.
  
  
• 고객의 요구에 대한 실시간 응답의 유용성을 검토하려면 Profit Maximization Through Customer Relationship Marketing(L. Aksoy, T. Keiningham, D. Bejou, eds.; Haworth Press, 2008년) 책에 있는 Kamakurq Wagner의 장, "Cross-Selling — Offering the Right Product to the Right Customer at the Right Time"을 읽어본다.
  
  
• IBM developerWorks Industries: 특정 산업에 적합한 개발자용 최신 기술 자료를 확인하자.
  
  
• 산업용 라이브러리: 기술 문서와 팁, 튜토리얼, 표준 및 IBM Redbooks는 developerWorks 산업용 라이브러리를 참고하자.
  
  
• developerWorks 기술 행사 및 웹 캐스트: 이러한 세션에 참가하여 최신 기술에 대한 정보를 얻을 수 있다.
  
  
• Twitter의 developerWorks 페이지: 오늘 가입하여 developerWorks 트윗을 팔로우하자.
  
  
• developerWorks podcasts: 소프트웨어 개발자의 흥미로운 인터뷰와 토론을 확인할 수 있다.
  
  

제품 및 기술 얻기

• IBM 제품 평가판: IBM SQA Sandbox의 온라인 시험판을 다운로드하거나 살펴보고 DB2®, Lotus®, Rational®, Tivoli® 및 WebSphere® 애플리케이션 개발 도구 및 미들웨어 제품을 사용해 볼 수 있다.
  
  

토론

• developerWorks 블로그: 이러한 블로그를 읽어보고 참여할 수 있다.
  
  

필자소개

Ben Lieberman은 BioLogic Software Consulting에서 프린시펄 아키텍트로 근무한다. 소프트웨어 아키텍처, 요구사항 분석, 소프트웨어 분석 및 설계, 구성 관리 및 개발 프로세스 개선과 같은 다양한 소프트웨어 개발 주제와 관련된 교육과 컨설팅을 전문으로 한다. Lieberman은 통신, 항공 여행, 전자상거래, 금융 서비스 및 생명과학과 같은 다양한 분야에서 10년 이상 소프트웨어 아키텍처와 IT를 다루었다. 그의 컨설팅 서비스는 소프트웨어 개발 우수 사례를 기반으로 하며 오브젝트 지향 아키텍처와 분산 컴퓨팅, 특히 Java™ 기반 시스템과 분산 웹 사이트 개발(J2EE), XML/XSLT, Perl 및 C++ 기반 클라이언트 서버 시스템을 전문으로 한다. Lieberman은 Jones Cyber Solutions, Blueprint Technologies, Trip Network Inc., Galileo International, 듀크대학교 및 콜로라도대학교를 포함한 교육기관, Mine Safety 및 Health Administration를 포함한 정부 기관에 아키텍처 서비스를 제공했다. 또한, 그는 책 한 권과 소프트웨어 관련 기사를 다수 저술한 전문 작가이기도 하다. Lieberman은 콜로라도대학교 Health Sciences Center에서 생물물리학과 유전학 박사학위를 받았다.

아티클 순위

의견

위로

목차

• 이벤트 중심 비즈니스 작동
• 고객 활동에 대한 응답
• 이벤트 중심 비즈니스 인텔리전스
• 엔터프라이즈 이벤트 관리 프레임워크
• 결론
• 참고자료
• 필자소개
• 의견