[UML 제대로 알기] ① 가능성·확장성 품고 등장한 UML 2.0

연재순서
1회.가능성·확장성 품고 등장한 UML 2.0
2회.초보자를 위해 다각도로 살펴본 UML
3회.바로 알고 제대로 쓰는 UML 실전 모델링
4회.닷넷 환경에서 UML 툴 활용 가이드
5회.표준을 넘나드는 UML의 적절한 사용

UML을 중심으로 소프트웨어 업계에서 벌어지는 경제적, 사회적 현상들을 알아보고 UML 2.0 발표 이후 소프트웨어 업계에 불어 닥칠파장에 대해 알아본다. 또한 UML 2.0에서 개발자들이 주목해야 하는 세부 내용도 간단히 검토해 보자.

UML 2.0의 실로 엄청난 중요성을 미리 알고 대비할 것인지, 뒷짐 지고 좀 더 지켜볼지는 이번 글을 보고 판단해 주기를 바란다.

필자는 지난 2004년 마이크로소프트웨어 8월호에 MDA 관련 글을 기고하던 당시부터 지금까지 필자의 소속 회사가 지난 10여 년간 전문적으로 개발해 오던 인적 자원 관리(HRM) 시스템에 대한 획기적인(?) 개선 방안으로 MDA 기반의 시스템 개발을 추진하고 있다. 필자가 본격적으로 UML 2.0을 검토하기 시작한 것도 8월을 전후해서였다.

그러나 회사에서 표준으로 사용하는 모델링 도구 제작 업체에서는 4개월 전만 해도 UML 2.0을 지원하지 않았고, MDA 패러다임을 표방하면서도 아쉽게도 그 요체인 UML 2.0은 그저 각종 문서나 자료들을 통해서만 접할 수 있었다. 인사 비즈니스 프로세스 개선 작업(BPI)과 같은 초기 설계 작업은 UML 1.4 기반으로 추진해야 했고, 올 연말로 예정됐던 도구 공급사의 차기 버전을 기대해야 하는 상황이었다.

그러던 얼마 전, 필자는 해당 업체로부터 UML 2.0을 충실히 지원하게 된 새 버전의 케이스 도구를 입수했다. 비록 필자가 이미 여러 책이나 자료들을 통해 UML 2.0을 검토했었음에도, 막상 본격적으로 UML 2.0 지원 모델링 도구를 설치하고 작업을 착수하려던 그 순간의 첫 느낌을 말로 하자면 막막함 그 자체였다.

그 모델링 도구의 새로운 버전이 완전히 개편된 새로운 사용자 인터페이스로 구성됐으며 내부적으로도 상당한 기술적인 패러다임 전환이 있었던 것도 한 원인이었겠지만, 무엇보다도 근본적으로 UML 2.0이 내포한 그 가능성과 확장성에 대한 놀라움과 설렘이 교차하면서 만들어낸 미묘한 흥분과 두려움이었다는 것이 적절한 것 같다. 1620년 메이플라워호를 타고 미지의 땅 아메리카에 첫 발을 내디뎠던 이주민들의 마음이 이렇지 않았을까?

UML의 사회적 파장
UML 2.0 발표와 더불어 개발자들이 주목해야 하는 세부 내용을 살펴보기 전에 우선, UML을 중심으로 소프트웨어 업계에서 벌어지는 경제적, 사회적 현상들을 통해 향후 UML 2.0 발표 이후 소프트웨어 업계에 불어 닥칠 파장에 대해 미리 가늠해 보는 시간을 가져 보기로 하겠다.

IT 시장 변화에 주목하자
이 시대 소프트웨어 산업에 종사하는 사람이, 딴 세상에 사는 사람(beings in heaven)이 아닌 이상, 자본주의 시대를 살아가는 현대인으로서 공급과 수요를 결정하는 시장 논리로부터 자유로울 수는 없다.

우리는 종종 뛰어난 기술력을 갖추고 있음에도 망하는 반면, 특별한 기술력을 가지고 있지 않음에도 번창하는 사람이나 기업을 종종 목격하곤 한다. 즉, 기술력이 곧 성공을 의미하지는 않는다. 마찬가지 논리로, UML 2.0이 아니라 그 어떤 뛰어난 기술이 존재한다 하더라도 IT 시장에서 그 기술력을 필요로 하지 않거나 수용할 수 없다면, 그 기술력의 시장 가치는 무의미할 수밖에 없다.

2000년을 전후해서 전세계적으로 Y2K 문제가 사회적 문제로 부각되고 시스템의 대공황 사태가 예고되던 시절, 아이러니컬하게도 당시 소프트웨어 산업에서는 사양길로 접어들었던 프로그래밍 언어의 전문가들이 국내의 IMF 사태와 맞물려 고액 연봉으로 대접 받으면서 해외로 진출했던 일이 기억난다. 역시 기술의 가치(technology value)는 시장 원리(market behavior)에 의해 결정될 수밖에 없음을 인정하지 않을 수 없다.

그런 관점에서 UML 2.0이 공식적으로 공표되는 전후의 소프트웨어 산업계 판도를 살펴보는 것은 의의가 있다. 세계적으로 이미 프로그램 개발 도구 시장은 그 성장세가 둔화됐고, 모델링 도구는 빠른 속도로 보편화되어 가고 있다. 지난 몇 년간 일어났던 IT 업계의 큰 사건들을 살펴보면 그러한 사실을 쉽게 확인할 수 있다.

이를테면 예전에는 비싸게 판매하던 개발 도구를 점차 저렴하게 행사 가격으로 판매한다거나, 개발자 저변 확산이라는 명목 하에 학교나 학원을 중심으로 무료로 배포하고 있다. 심지어는 이클립스 등과 같은 막강한 개발 도구를 오픈소스로서 인터넷을 통해 무료로 배포하고 있다.

몇 년 전 세계적인 소프트웨어 업체인 MS에서는 비지오(Visio)라는 2D 전용 도구 개발 업체를 인수했고, IBM은 세계적인 모델링 도구 전문 개발 업체인 래쇼날을 인수합병했으며, 연이어 볼랜드에서는 투게더를 사들였다. 한편, 국내외 UML 관련 포럼이나 협회들에서는 앞다퉈 UML 관련 인증 제도를 만들어 발표하면서 그 인지도를 넓혀 가기 위한 대대적인 작업을 벌이고 있다.

UML 인증 제도의 필요성이라든지, 인증 제도 자체의 신빙성이나 효용성에 대해 논하기 이전에, 어떠한 사상이나 개념이 제도화 되는 과정을 거치고 있다는 사실은 그 사상이나 개념이 해당 분야에서 도입기(intro)와 성장기(growth)를 거쳐 성숙기(mature)에 진입하고 있음을 암시하는 것이다.

표준화의 숨은 뜻
UML을 논하면서 표준화(standardization)라는 키워드를 빼놓을 수 없다. UML이 발표되기 전에 국방이나MIS분야 엔지니어들에게 친숙한 IDEF라든지 DFD, ER 혹은 Petri nets 등과 같은 정형 기법(formal method)으로 통칭되는 수많은 표기법(notation)과 지원 케이스 도구들이 존재했음에도 불구하고(참고자료:[1]번혹은[2]번등), UML은 가장 단기간 동안 소프트웨어 공학 분야에서만큼은 빠른 속도로 사실상의 표준(de-facto)의 위치를 확보했다. 언뜻 생각해 보면 UML이 여타 표기법들을 교통정리해 준 안도감(?)이 들 수도 있겠지만, 겉으로 잘 드러나지 않는 그 내막에는 무서운 음모(?)가 도사리고 있다.

표준화 작업에 주도적인 역할을 수행하는 업체들이 왜 그토록 천문학적인 자본을 투자하면서 공개적인 표준화 작업에 동참하는 것일까? 여러 가지 복합적인 이유들이 있을 수 있겠지만, 결론적으로 표준화 경쟁이다.

유명한 예로, 1970년대부터 시작됐던 빅터(Victor)의 VHS 방식과 소니의 베타 방식으로 대표되는 비디오 표준 전쟁을 들 수 있고, 최근에는 유럽과 미국을 중심으로 벌어지고 있는 위성방송 표준화 전쟁을 들 수 있다. 표준화 전쟁에서의 승패는 곧 기업의 운명을 좌우하는 것이다.

표준화의 이면에는 높은 진입 장벽을 통해 허가 받지 않은 침입자(intruder)를 봉쇄하려는 무서운 저의가 자리 잡고 있다. 시야를 좀 더 넓혀 보면, 의사나 판사, 회계사 등. 통속적인 표현으로 소위 ‘사’자로 끝나는 직업들에 대한 사회적 가치관을 살펴보면 쉽게 이해할 수 있다.

사람 몸을 열어서 칼질하고, 같은 인간으로서 다른 인간을 판단하고, 숫자 가지고 씨름하는 직업이 산업혁명 이전에는 별볼일 없는 직업이었다. 인류의 보편적인 가치관으로 판단하더라도 결코 즐거운 일이 될 수 없음에도 불구하고 전세계적으로 공히 가장 선호하는 직업이자 사회적으로도 가장 대접받는 직업이 된 현실에 미루어 짐작해 보면, 왜 그토록 세계적인 소프트웨어 업체들이 표준화를 통해 높은 진입 장벽을 구축하고 제도화에 전념하는지 그 이유를 충분히 이해할 수 있다.

어려운 시험을 통과하지 않고 누구라도 일정한 요건만 갖추면 수행할 수 있는 일반적인 직종 중의 하나라면 그렇게들 동경하는 직종이 됐겠는가? UML 2.0이 경제적으로나 사회적으로 주목 받는 이유 중의 하나는 바로 그러한 맥락에서 비전문인과 전문가를 구별하는 높은 장벽(?)을 쌓을 수 있는 재료(material)를 확보하고 토대를 마련했다는 점에서 의의가 있는 것이다.

주목해야 할 UML 2.0의 핵심 메커니즘
1997년 11월 UML 1.1로 시작된OMG의 표준화 노력은 2001년 5월 UML 1.4 발표와 더불어 부분적인 개정 작업(minor version upgrade)의 막을 내리고, 대대적인 수술 작업을 거쳐 2004년 연말을 전후로 드디어 그 실체를 드러내었다.

그 동안 쟁쟁한 세계적인 소프트웨어 벤더들간의 보이지 않는 이해 관계(?)에 얽혀 2002년 말로 예정됐던 최종 발표 시한을 2년여를 연장하면서 이제서야 그 대단원의 막이 마무리되고 있다. 향후 UML 2.0의 일정은 명실상부한 국제 표준(de jure)으로 자리매김하기 위해 ISO 설계 표준으로 추진 중인 것으로 알려져 있다.

UML 2.0이 주목 받는 가장 중요한 이유는 무엇일까? 처음 세상에 나오고 나서는 여기저기서 수많은 비판을 받았지만, 그것은 UML이 어떠한 플랫폼이나 도메인에도 의존하지 않고 소프트웨어 개발의 전 공정(SDLC)을 지원하는 방향으로 지향해왔다는 데에 그 원인을 찾을 수 있다. 즉, 요구사항 획득으로부터 마지막 테스트까지 모두 지원하는 표기법으로서 진화해 왔다는 것이다.

그리고 점진적으로 UML 2.0부터는 실행 모델(executable UML)이라는 기법을 수용함으로써, 소프트웨어 공학에서 궁극적으로 염원하던 분석 설계(analysis & design)와 실제 구현(implementation) 간의 차이(chasm)를 극복하는 성과를 보였기 때문이다.

OMG의 UML 2.0에 대한 제안요청서(RFP)의 주제이자 현재 채택된 명세서 초안은 크게 4가지의 영역으로 분류된다. CASE 도구 벤더들간의 모델 호환성 문제를 다루고 있는 다이어그램 호환(Diagram Interchange) 영역과 모델 수준에서의 요소(elements) 제어 및 제약 문제를 다루고 있는 OCL(Object Constraint Language) 영역, UML뿐만 아니라 OMG가 주관하는 각종 표준의 통합과 정의에 활용되는 메타 모델 수준의 기본 구조체(constructs)를 명시하고 있는 하부구조(Infrastructure), 그리고 메타 모델을 기반으로 사용자 수준에서 모델을 활용하여 시스템의 구조(structure)와 행위(behavior)를 정의하고 있는 14개의 다이어그램을 정의하고 있는 상부구조(Superstructure)로 분류할 수 있다.

UML 2.0의 본질을 제대로 이해하려면 핵심인 하부구조로부터 차근차근 살펴보는 것이 순서이겠지만, 지면과 주제를 고려할 때, 일반인들이나 설계자들이 UML 2.0을 처음 대면하는 경우 가장 먼저 관심을 가지게 되는 UML 구조체(user-level constructs)인 상부구조로부터 이야기를 풀어가는 방식을 택하기로 하겠다.

<그림 1> UML 2.0 표준 다이어그램

*빨간 밑줄: 새롭게 추가된 다이어그램, 녹색 밑줄: 명칭이 변경된 다이어그램

상부 구조는 크게 6개의 다이어그램으로 구성된 구조형 다이어그램(Structural Diagram)군과 7～8개의 다이어그램으로 구성된 행위형 다이어그램(Behavioral Diagram) 군으로 분류할 수 있는데, 각 군의 대표적인 복합 구조 다이어그램(Composite Structure Diagram)과 순차도(Sequence Diagram)를 중심으로 그 특징과 의의를 살펴보도록 하겠다.

이어서 UML 2.0의 기반을 설명하고 있는 하부구조의 의미는 무엇인지, 그리고 실제 설계 작업에서 하부구조의 접근법은 어떠한 방식으로 활용하게 될 것인지 논의하기로 하겠다.

상부구조 - 구조형 다이어그램
일명 아키텍처 다이어그램(architectural diagram)이라고도 불리는 복합 구조 다이어그램(composite structure diagram)은 UML의 핵심 다이어그램인 클래스 다이어그램의 변형된 형태이다. 이는 시스템 구조 설계에 있어 또 다른 핵심 축으로 평가 받고 있으며 가장 주목 받는 다이어그램 중의 하나이다.

복합 구조 다이어그램은 기본적으로 시스템 혹은 컴포넌트의 내부 구조(internal structure)를 명시적으로 중첩시켜 표현하고 있으며, 시스템 아키텍처의 보다 섬세한 분석과 설계 사상을 담을 수 있게 된 점이 가장 큰 매력으로 꼽을 수 있다.

그렇다면 왜 복합 구조 다이어그램이 주목받는지, 그리고 복합 구조 다이어그램은 왜 탄생하게 되었으며, 향후 어떠한 용도로 활용하게 될까? 보는 시각에 따라 의견을 달리 할 수 있겠지만, UML 1.x은 근본적으로 OOAD 수준의 설계 사상을 표현하기에 최적화된 표기법으로 평가되어 왔다.

UML 1.x에도 비록 컴포넌트 다이어그램이라는 것이 있기는 했지만, 실제 너무 빈약한 문맥(semantics)으로 인해 별로 활용되지 못했으며, 강경한 컴포넌트 신봉자들이나 대용량 시스템 혹은 전체 시스템을 통합적으로 표현하기 원했던 아키텍처 전문가 진영 개발자들에게는, 그저 객체 옹호론자들이 제시하는 옹색한 명분(?)에 지나지 않았다. 사실 UML 1.x 자체에도 명시하고 있듯이, 컴포넌트 다이어그램은 몇몇 다이어그램들과 더불어 클래스 다이어그램에 일종의 간단한 확장 메커니즘을 통한 단순한 관점(view) 변경 수준에 지나지 않았다.

비즈니스 컴포넌트에 관심이 많았던 컴포넌트 신봉자들의 경우, UML 1.x의 스테레오타입(stereotype)등의 확장 메커니즘을 통해 그럭저럭 UML 1.x과의 관계를 유지하면서도 BPM이라는 포괄적이고 확장된 별도의 비즈니스 컴포넌트 표기법을 병행하며 UML 1.x의 미비한 부분을 채워 나갔다.

아키텍처 전문가 진영에서는 상황이 조금 달랐는데, 대다수의 아키텍처 전문가 진영에서 관심을 가지고 있던 임베디드 혹은 리얼타임 도메인에서는 단순히 UML 1.x 정도의 확장 메커니즘으로는 그들이 필요로 하는 아키텍처를 통한 시뮬레이션 등과 같은 시스템의 섬세한 분석 및 설계라는 목적 달성이 거의 불가능했고, 그러한 목적 달성을 위해 UML의 확장 메커니즘을 활용한다는 것은 차라리 자신들만의 특정 영역에 필요한 표기법을 자체 정의하여 사용하는 것이 훨씬 경제적이었다는 것이다.

왜냐하면 이미 아키텍처 전문가 진영에서는 UML 1.x가 발표되기 이전에 광범위하게 수많은 ADL(Architectural Description Language)과 관련 시뮬레이션 도구들이 개발되어 활용되고 있었으며, 굳이 UML에 순응하는(compliant) 방안을 모색하기 위해 UML을 연구하고 고민할 시간적 여유나 명분이 없었던 것이다.

그러나 그러한 두 진영에서 근본적으로 해결하지 못한 결정적인 문제는 자신들이 독자적으로 발전시켰던 표기법 중에 어떠한 것도 명실상부한 사실 표준(de-facto)으로 합의하지 못했다는 것이다. 가령, 아키텍처 전문가 진영에서 필요로 하는 시스템 시뮬레이션 기능을 구현하는 데 사용하는 정형 기법의 경우 동일한 도메인에서조차 연구소나 익숙한 기법에 따라 서로 달리 정의하고 필요한 시뮬레이션 도구를 개발해야 했다.

국제적인 공동 작업은 말할 것도 없이 국내에서 서로 다른 연구기관이 공동 작업을 수행하기 위해서도 사전에 일정한 표준 정형 기법을 합의하고 정립한 후 과제를 수행해야 했으며, 최종적으로 통합하는 과정에서는 결국에 모델 수준에서의 통합을 포기하고 구현 수준에서 테스트를 통해 통합하는 방식을 따라야 하는 문제점을 내포하고 있었다.

덧붙여 두 진영에서 해결하지 못한 결정적인 문제 중의 하나는 실제 구현(code)에 필요한 낮은 추상화 수준의 설계에 대해서만큼은 어설픈 UML 1.x의 메커니즘만한 수준의 방안을 제시하지 못했다는 것이다.

UML 2.0에서 새롭게 등장한 복합 구조 다이어그램은 바로 지금까지 앞서 살펴 본 아키텍처 전문가 진영으로 대표되는 임베디드 혹은 리얼타임 도메인의 핵심 개념이자 도구였던 SDL(Specification Description Language)을 수용하여 탄생한 다이어그램이다.

<그림 2> UML 2.0 복합 구조 다이어그램 예

UML을 잠시라도 살펴 본 경험이 있는 개발자들이라면, 복합 구조 다이어그램의 개략적인 형태만을 보고서도 쉽게 그 특징을 이해할 수 있을 것이다. 즉, 복합 구조 다이어그램은 매우 직관적인 형태를 취하고 있으며, 기존의 UML 1.x에서 단순한 패키지 개념의 서브시스템 내부를 구성하고 있는 클래스 다이어그램으로만 표현이 가능하던 시스템 내부 구조를 보다 섬세하게 설계할 수 있게 됐다.

그렇다고 <그림 2>와 같이 대부분의 UML 2.0을 기반으로 한 샘플들처럼 임베디드나 리얼타임 도메인과 같이 상대적으로 소프트웨어의 비중이 작은 단위 시스템이나, 특정 MIS 분야의 단위 서브시스템의 내부 설계에만 국한되어 복합 구조 다이어그램을 활용하겠다고 생각한다면, UML 2.0의 본질을 제대로 이해하지 못하고 있는 것이다.

복합 구조 다이어그램의 형태는 앞서 언급한 아키텍처 전문가 진영에서 아키텍처를 표기하는데 가장 많이 활용하는 아키텍처 스타일인 C&C(Component & Connector) 뷰 타입(view type)과도 일맥상통하는데, 복합 구조 다이어그램을 활용하고자 하는 모델의 추상 수준을 높이면 대규모 시스템의 아키텍처도 매우 유용하게 설계할 수 있게 된다.

<그림 2>에서 벤딩머신(VendingMachine)으로 되어 있는 부분을 인사시스템이라 정의하고 내부 부분(parts)들을 그것을 구성하고 있는 단위 시스템으로 정의하게 되면, 외부 인터페이스를 통해 회계시스템(AS)이나 고객관리시스템(CRM) 등과 주고받아야 할 데이터나 정보를 명시적으로 설계에 반영할 수 있을 것이다.

바로 설계자가 의도하는 어떠한 추상화 수준의 모델이라도 UML 2.0의 복합 구조 다이어그램은 보다 섬세하게 설계할 수 있도록 일관된 문맥(context)과 의미(semantics)를 제공하고 있는 것이다.

상부구조 - 행위형 다이어그램
UML 2.0 상부구조 중 구조형 다이어그램은 말 그대로 구조적인 혁명을 꾀했다면, 행위형 다이어그램 군에서는 시스템의 동적 설계를 제대로 반영하기 위해 기존의 행위형 다이어그램 군 소속 다이어그램의 의미(semantics)를 보강하고 정제함으로써, 진화 방식을 선택했다는 표현이 적절할 것 같다.

그 근거로서 앞서 복합 구조 다이어그램으로 대표되는 구조형 다이어그램에서 수용한 SDL의 경우와는 다르게 UML 1.x에서 이미 수용하던 MSC(Message Sequence Chart) 개념을 UML 2.0에 와서는 전폭적으로 수용하여 순차도(Sequence Diagram)를 중심으로 행위형 다이어그램들의 유기적 결합 통로를 확보함으로써 시스템의 모델 수준에서의 논리적인 실행을 그대로 설계에 반영할 수 있는 발판을 마련했다.

<그림 3> UML 2.0 순차도의 예

<그림 3>에서 보는 바와 같이 UML 2.0 순차도의 가장 두드러진 특징은, 기존의 UML 1.x에서 지원하지 못했던 시스템의 분기, 참조, 병렬 실행 등과 같은 세세한 부분들까지도 지원이 가능하도록 중첩된(nested) 표기법 체계를 설계 기법으로 도입했다는 사실이다.

MSC와 같은 기법에 익숙한 개발자들에게는 언뜻 보기에 별로 특이할 것이 없어 보일지 모르지만, 중요한 사실은 UML 2.0을 표준 표기법으로 수용함으로써 어떠한 비즈니스 도메인이나 기술 영역에서도 <그림 3>의 순차도 뿐만 아니라 UML 2.0의 다른 다이어그램들과 유기적인 연결고리를 가지고 활용함으로써 거의 무한대에 가까운 표현 수단을 확보할 수 있다는 사실이다.

UML 2.0 상부구조 중 행위형 다이어그램의 갱신에 대해 많은 관심을 가지는 사람은 임베디드 혹은 리얼타임 진영에 종사하고 있는 개발자들이겠지만, 기존의 비즈니스 프로세스 모델링 분야에서 종사하던 개발자 진영도 깊은 관심과 기대를 가지고 있다.

필자 또한 비즈니스 프로세스 모델링과 관련하여 행위 형 다이어그램의 특성과 최적 방안을 모색하고 있는데, 동일 비즈니스 도메인에서조차 개별 기업마다 그 특성과 비즈니스 프로세스 처리 방식이 천차만별인 문제를 해결하고자 등장했던 워크플로우 엔진 혹은 설계 시스템(workflow engine or system)과 같은 전문적인 도구의 기능을 충분히 대치할 방안이 마련된 것으로 평가되고 있다.

하부구조 - 메타 모델
소프트웨어 공학 분야에서는 이런 속설이 있다. 자신의 분야에서 메타 모델 기반의 접근을 하게 되면 하나의 논문이 된다. 매일 고객들과 씨름하면서 현장에서 일하는 개발자들에게는 먼 나라 이야기처럼 들리고, 현실적으로는 일정 규모의 연구소 혹은 학교에서나 다루어질 만한 주제로 치부됐던 것이 사실이다.

UML 2.0 하부구조(Infrastructure)는 일반적으로 UML 2.0을 지칭할 때 생각하는 UML 2.0 상부구조뿐만 아니라 OMG의 또 다른 메타 모델 집합인 MOF, CWM 뿐만 아니라 미래의 새로운 표준을 정의하기 위해 심혈을 기울여 정의한 메타 모델이다.

OMG에서 처음 메타 모델 4계층 개념을 발표했을 때에는 그저 개념적인 내용으로만 인식하지 못했지만, UML 2.0의 실체가 드러나고 그것을 지원하는 케이스 도구들의 기능들이 메타 모델 기반 설계 방식을 지원함으로써, 이제는 메타 모델이라는 주제가 현장에서조차 피해갈 수 없는 현실 문제로 다가올 것이다. 그러므로 이제는 메타 모델 4계층 개념을 충분히 이해하고 응용하는 노력을 기울일 필요가 있다.

<그림 4> OMG 4계층 메타 모델 예

글의 주제와 지면 관계상 메타 모델에 대한 깊이 있는 논의를 하지는 못하지만, <그림 4>의 예로 간단히 살펴보자. 시스템 분석가나 설계자들이 일반적인 모델링 케이스 도구를 통해 특정 도메인 시스템을 설계한다고 했을 때의 메타 모델 수준(level)이 바로 사용자 모델을 도식하게 되는 M1 수준이다.

M2 수준은 그러한 UML 기반의 설계를 가능케 하는 어트리뷰트, 클래스, 인스턴스 등과 같은 모델 요소를 정의하는 메타 모델이며, UML 2.0의 하부구조는 바로 위 4계층 메타 모델 관점에서 M2 수준의 UML 메타 모델이 된다. M3 수준에 위치한 MOF(Meta Object Facility)는 M2 수준에 속한 메타 모델을 정의하는 메타메타 모델이 된다.

참고로 CWM(Common Warehouse Metamodel)은 M2 레벨이며, MOF의 내부 구조는 추상화된 UML 하부구조와 동일한 방식으로 정의하고 있다. 자세한 사항은 OMG UML 2.0 Infrastructure, 7. Language Architecture를 참조한다.

앞에서 살펴 본 바와 같이 OMG에서 UML 2.0 관련 제안요청서(RFP)를 제기한 목적은 단순히 UML 2.0을 체계적으로 정리하고자 한 것이 아니라, OMG의 또 다른 표준인 MOF와 CWM 및 미래의 새로운 표준을 체계적으로 정의하기 위한 용도로 제기됐던 것이다. 여기서 우리가 주목해야 할 사항은 UML 2.0 하부구조에 대한 제안요청서를 통해 제기한 또 다른 목적이다.

그것은 바로 지금까지 M1 수준에서 UML을 활용하던 사용자들이 보다 수월하게 M2 수준에서 UML을 커스터마이징하여 활용할 수 있는 메커니즘을 제공하는, 즉 이원화된 메커니즘을 제공하여 사용자들이 유연하게 특정 기술 도메인이나 비즈니스 도메인에 최적화된 방식으로 설계를 수행할 수 있도록 하자는 데 그 취지가 있었다.

그 핵심이 바로 UML 프로파일(UML Profiles)이다. 지금 UML 2.0 작업과 동시에 진행되고 있는 대표적인 기술 도메인 프로파일로는 우리들에게 친숙한 EJB 프로파일(Profile for EJB), 닷넷 프로파일(Profile for .Net)을 들 수 있다. 프로파일을 간단히 설명하면, 일종의 특정 기술이나 비즈니스에 적절한 커스터마이징된 확장 메커니즘을 사전 정의해 놓고, 추상화 수준이 서로 다른 모델들간의 전환(transformation)을 자동화시키는 핵심 메커니즘이다.

플랫폼 독립 모델(PIM: Platform Independent Model)로부터 특정 플랫폼 종속 모델(PSM: Platform Specific Model)로의 자동화된 전환이라는 MDA의 사상이 바로 대표적인 일례라고 볼 수 있다. UML 프로파일은 향후 MDA를 통해서 달성하려고 하는, 아니 궁극적으로 UML 2.0을 통해 달성하게 될 소프트웨어 공학의 핵심 화두인 소프트웨어 개발 생산성 향상의 핵심 메커니즘으로 평가 받고 있다.

만약 이 글을 읽는 개발자가 속한 관련 분야에 MIS 분산 시스템 개발의 사실 표준으로 통용되는 J2EE나 닷넷 등과 같은 개발 기술 표준 프레임워크가 존재한다면 다행스러운 일이다. 모델링 도구 벤더에서 제공하는 EJB 프로파일이나 닷넷 프로파일과 같은 기술 메타 모델은 그대로 활용하고, 관심 비즈니스 영역에 해당하는 표준 도메인 프로파일을 활용하거나, 독자적으로 정의해 설계 작업을 추진해 나갈 수 있기 때문이다.

하지만 최악의 경우 관련 분야에 기술이나 도메인 프로파일이 존재하지 않고, 더욱이 활용할 만한 케이스 도구조차 존재하지 않는다면 난감하다. 하지만 UML 2.0을 충분히 지원하는 범용 혹은 상용 케이스 도구를 통해 구현된 방식이나 기능을 살펴보면 놀랄 만큼 간결하다. 문제는 UML 2.0의 프로파일 방식과 같은 메커니즘을 이해하는 것이 아니라, 그 동안 개발자들이 간과해 왔던 문제, 가령 “해당 비즈니스 도메인을 제대로 이해하고 있었는가?” 등과 같은 근본적인 문제를 되돌아보는 계기가 될 것으로 생각된다.

어떻게 대처할 것인가
지금까지 UML 2.0 출시를 전후해서 전개되어 왔던 소프트웨어 산업계의 전반적인 흐름과 사회적 파장, 그리고 UML 2.0의 상부 및 하부구조의 핵심 메커니즘을 중심으로 간단히 살펴보았다. 그렇다면 과연 어디서부터 어떻게 UML 2.0을 시작할 것인가?

기본 원칙에 충실하자
우선 스스로에게 UML 1.4는 제대로 이해하고 활용해 왔는가라는 질문을 던져 보아야 한다. 필자의 경우 하는 일이 하는 일인만큼 UML 2.0이 발표되기 이전에도 자바나 비주얼 베이직 등과 같은 프로그래밍 용어나 주제에 비해 상대적으로 UML(1.x), OOAD, CBD, 방법론 등이라는 용어가 훨씬 낯설지 않았다.

당연히 주변에는 상대적으로 코딩보다는 현장에서 분석(analysis)이나 설계(design)를 전문으로 하거나, 학교나 학원 등에서 학생들을 가르치는 사람들이 많았지만 그 중에 UML 1.x 관련된 OMG 무료 명세를 제대로 살펴보았거나, 가까이 두면서 참조하는 사람은 찾아보기 어려웠다.

필자 가까이에 ‘UML 1.4 사용자 지침서’를 한글로 번역했던 분을 통해 확인해 보아도, 국내 출판사에서 출간한 책 부수로 미루어 UML 원문은 차치하고서라도 핵심 내용만을 추려서 발간한 그 UML 사용자 지침서마저 꼼꼼히 살펴 본 사람은 별로 보지 못한 것 같다. 필자도 예외는 아닌데, 돈이 없어서 혹은 원서이기 때문에라는 것은 이유가 되지 않았던 것이다.

그런데 UML 2.0이 공식 발표되는 이 시점에도 상황은 예전이나 별반 다르지 않은 것 같다. UML 2.0으로 공식 공표되기 전에 이미 오래 전부터 OMG에는 UML 관련 명세를 1.5의 형태로 인터넷에 배포하고 있었지만, 살펴본 사람은 찾기 어려웠다. UML 1.1이 처음 발표되던 시점에는 표기법으로서의 표준화 경쟁에서 판정승이 나지 않았던 때여서 그랬다고 하더라도, UML 2.0이 공표되는 이 시점에는 이미 국내외 많은 대학의 컴퓨터 관련학과에서 필수 과목으로 개설되었을 만큼 그 중요도와 필요성이 검증된 마당에 애써 그 사실을 외면하는 것은 더 이상 이유가 될 수 없다.

물론 지금까지의 현실은 그렇지 못했던 것이 사실이다. UML 전문가들마저도 UML 1.x의 설계 도구로서의 완성도가 받쳐주지 못했고, 무엇보다도 고객들도 유기적으로 논리적인 설계 모델을 기대하지 않았기 때문에 UML이라는 포장지를 가지고 피상적이고 개념적으로 대충 구색 맞추기식 설계 산출물을 만들어 주면 그만이었다.

그러나 앞으로의 상황은 그렇지 못할 것이다. 당장은 아니겠지만 UML 2.0 표기법이 소프트웨어 산업 시장에서 보편적으로 활용되고 국내외에서 하나 둘 그 무한한 잠재력과 가능성이 증명되어 그 시장 가치가 확연히 드러나기 시작하는 시점에는 우리 주변의 고객들 또한 단순히 보기 좋은 산출물 정도의 설계를 요구하지는 않을 것이다.

그렇다면 어디서부터 어떻게 준비해야 할 것인가? 그 실마리는 처음 접하면 이해하기 어렵고 복잡한 UML 2.0 관련 명세나 두꺼운 책에서 찾을 것이 아니고, 누구나 알고 있으면서도 충실하지 못했던 가장 기본적이고 원칙적인 원리를 고민하는 것부터 시작해야 한다.

원칙 하나, 도메인을 철저하게 분석하자
시스템을 설계한다고 했을 때, UML과 같은 설계 기법을 동원하여 작업하는 시스템 분석 및 설계자 그룹 외에 매우 중요한 역할을 수행하는 집단이나 개인을 가리켜 도메인 전문가 혹은 비즈니스 분석가라고 한다. 가장 이상적인 시스템 설계자는 두 가지 능력 즉, 해당 도메인에 대한 공인된 전문적인 지식을 가지고 있으면서 동시에 설계 능력을 고루 갖춘 인재일 것이다.

그러나 현장에서 그런 핵심 인재를 찾기는 어려운 것이 사실이다. IT 업계로만 보더라도 시스템 설계자와 개발자 간에 차이가 좀처럼 좁혀지지 않는데, 전혀 그 분야와 전공이 다른 비즈니스 전문가와 시스템 전문가 간에 느끼는 갈등은 말할 필요도 없다. 시스템을 설계해 본 사람은 누구라도 공감하겠지만, 시스템을 제대로 설계하려면 해당 도메인을 충분히 이해하고 철저하게 분석해야 한다. 그렇지 않으면 제대로 된 시스템을 설계할 수 없다.

시스템 설계자 입장에서 문제는 해당 도메인을 제대로 이해하기 위한 충분한 시간도 주어지지 않고, 나름대로 시스템 설계자가 충분히 이해한 것을 객관적으로 검증해 줄 만한 기준도 마련되어 있지 않다는 것이다. 설사 객관적 기준이 있더라도 그것은 현실적으로 거의 불가능하다는 것이다.

가령 회계 시스템을 설계하려면 회계사 자격증을 갖춰야 하는가? 물론 아니다. 그런데 우리는 주변에서 타의든 자의든 특정 도메인 시스템을 반복해서 설계하는 설계자의 경우 점점 해당 도메인에 대한 이해력이 높아지고, 회계사와 같은 공인된 자격증은 취득하지 못하더라도 나름대로 그 전문성을 인정받아 시장에서 높이 평가되는 경우를 보곤 한다.

비단 시스템 설계자에게만 해당되는 문제는 아니다. 조각조각 할당된 부분만 열심히 해야 하는 개발자에게도 비슷한 현상은 쉽게 찾아 볼 수 있다.

설계하고자 하는 해당 도메인에 대한 철저한 분석 없이는 일정한 추상화 수준을 유지한 유기적인 모델을 만들어 낼 수가 없다. 몇몇 책이나 발표 자료에서 설계 팁으로 이야기 하듯이 해당 도메인에서 반복적으로 등장하는 명사(nouns)를 클래스명으로 명명한다는 식으로 설계를 진행하다 보면 점점 헤어나지 못하는 미궁으로 빠져들게 된다. 결국에는 UML 2.0이라는 강력한 설계 도구를 가지고도 설계 따로, 코딩 따로라는 늪에서 벗어날 수 없다.

UML 표준화를 주도하는 OMG에 대해서 많은 사람들은 단순히 CORBA, ORB 등과 관련한 국제적인 기술 표준화 단체 정도로만 인식하고 있다. 하지만 앞서 주장한 도메인 지식 혹은 도메인 표준에 대한 중요성에 대해서는, 그러한 기술 표준화 단체로 출범한 OMG에서 2002부터 발족하여 추진하고 있는 DTF(Domain Task Forces) 위원회의 활동을 살펴보면 쉽게 이해할 수 있다.

이미 전략전술 통제(C4I), 재무(finance), 의료(healthcare), 제조(manufacturing), 우주항공(space), 통신(telecommunications), 운송(transportation) 등의 도메인을 필두로 그 표준화 작업을 진행 중에 있으며, 여러 표준화 단체들과 연합하여 다른 도메인으로까지 표준화 작업을 확장 중에 있다.

물론 아직까지 그 시도는 기술적인 관점에서의 접근이라는 한계를 크게 뛰어 넘고 있지는 못하지만 인터넷, 즉 IT 기술을 배제한 고전적 의미의 비즈니스는 점차 그 경쟁력을 잃어 가고 있는 현실을 생각할 때 OMG의 영향력은 쉽게 무시할 수 없는 것이 될 것이다.

원칙 둘, 모델의 추상 수준
사전적 의미로도 알 수 있듯이 모델은 본질적으로 어떤 특정 사물이나 현상에 비해 상대적으로 추상화되어 있는 무엇이기 때문에 똑같은 실체에 대한 서로 다른 모델은 서로 다른 추상화 수준(level of abstraction)을 가질 수밖에 없다.

<그림 5> 모델의 서로 다른 추상화 수준

<그림 5>를 보면 똑같은 자동차를 모델로 만든 것이지만, 상단의 자동차 그림(혹은 모델)은 추상화 수준이 높고 하단의 자동차는 추상화 수준이 낮다. 여기서 중요한 것은 추상화 수준의 높고 낮음은 상대적이라는 것이다. 우리가 UML에서 제시하는 여러 다이어그램을 가지고 모델을 제작한다는 것은 결국 목표하는 자동차나 건물 등과 마찬가지의 실체 즉, 특정 시스템 하나를 완성하기 위한 노력인 것이다.

즉, 설계 작업을 수행한다는 UML 1.4의 표기법을 동원하든 UML 2.0의 표기법을 동원하든 아니면 제3의 표기법을 활용하든 목표하는 시스템을 완성하기 위한 과정이지 다이어그램 혹은 표기법 자체가 목적이 되지는 않는다는 것이다. 이러한 똑같은 모델의 원리를 UML의 다이어그램을 가지고 설명할 수 있다. <그림 5>는 UML 1.4에서 제시하는 9개의 표준 다이어그램의 추상화 수준을 계량화하는 방안으로 방사형의 표로 도식해 본 것이다.

<그림 6> UML 1.4 다이어그램 추상화 분포

<그림 6>의 중앙에 위치한 지점을 설계자가 목적하는 목표 시스템의 코드 혹은 운영(run-time) 시스템이라고 한다면, 유스케이스 축에서 0.8으로 표시된 지점 정도의 추상화 수준으로 유스케이스를 작성한 것을 비즈니스 유스케이스라 할 수 있겠고, 0.4 정도의 지점 추상화 수준으로 작성한 것을 시스템 유스케이스라고 할 수 있을 것이다. 그렇게 가정해 본다면, 중앙에 가까운 지점의 추상화 수준으로 낮게 모델을 작성한다면 설계자가 목적하는 시스템은 보다 세세하게(detailed) 보이게 될 것이다.

유럽의 모든 길이 로마로 향하듯이, 어떠한 길(다이어그램)을 선택하더라도 종국에는 목적지(목표 시스템)에 도달할 수 있다. 하지만 각 다이어그램은 각자 목표하는 시스템으로 접근할 수 있는 추상화 수준의 한계를 가지고 있다.

가령, 유스케이스 다이어그램만을 가지고 시스템 설계를 완성할 수는 없는 것이다. 반면에, 클래스 다이어그램만 가지고 시스템 설계에 접근하다 보면 나무는 보고 숲을 보지 못하는 우를 범할 수 있다. 그러한 이유로 소프트웨어 설계에서 UML을 활용하여 목표 시스템을 설계할 때는 하나 이상의 다이어그램을 활용하게 된다.

대표적으로 많이 활용되는 다이어그램으로는 유스케이스, 클래스, 시퀀스 등을 들 수 있을 것이다. 문제는 여기서부터 시작 된다. 시스템 설계에 대표적인 3개의 다이어그램을 활용하든 아니면 9개의 다이어그램을 모두 활용하든 활용하는 다이어그램들이 각자 따로 존재하게 되는 것이다.

유스케이스 다이어그램 따로 클래스 다이어그램 따로 심지어는 동일한 시스템에 대한 유스케이스 다이어그램을 그리더라도 그리는 사람에 따라 서로 다른 추상화 수준(level of abstraction) 혹은 입도(granularity)의 유스케이스가 작성된다는 것이다. 이건 비즈니스 유스케이스니 이건 시스템 유스케이스니 하면서 무의미한 논쟁으로 치닫게 된다.

이러한 문제를 본질적으로 해결책하기 위해서는 그것이 UML 1.4이든 UML 2.0이든 각 다이어그램의 주된 용도(usage)와 목적(objectives), 그리고 그 한계를 충분히 이해하고, 각 다이어그램이 그러한 용도와 목적을 충족시키기 위해 제시하는 특성 표기법의 명확한 의미와 용도를 숙지해야 한다. 그 후에 활용하려는 다이어그램의 핵심 표기들 간의 추상화 수준에 대해 일관된 원칙(principle)을 우선 정립하고 설계 작업을 수행해야 한다.

가령 이러한 원칙 수립이 가능하다. 유스케이스 다이어그램을 통해 작성한 하나의 유스케이스를 하나의 활동도(Activity Diagram)로 도식하기로 했다면, 활동도의 활동(Activity)은 유스케이스 시나리오로 작성하는 사건 흐름(flow of event) 상의 단일 스텝(step)이라는 원칙을 설정하게 되면 일관된 설계 작업을 수행할 수 있다. 그러한 설계 전략을 위 <그림 6> 위에 상징적으로 표현해 보면, <그림 7>과 같이 도식할 수 있을 것이다.

<그림 7> 다이어그램 간의 추상화 수준 조정

지금까지 UML 1.4를 중심으로 모델의 추상 수준이라는 원리에 대해 살펴보았다. 그러한 모델의 추상 수준이라는 핵심 메커니즘은 본질적으로 UML 2.0이라고 해서 다르지 않다. 앞선 <그림 1>과 <그림 7>을 언뜻 비교해 보아도 UML 2.0에서는 표준 다이어그램의 개수로도 UML 1.4에 비해 수적으로 많이 늘어났으며(<그림 4>에서 빨간색으로 표시된 다이어그램), 이전부터 있었던 몇몇 다이어그램들은 명칭이 변경됐고(<그림 4>에서 초록색으로 표시된 다이어그램), 무엇보다도 전반적으로 모든 다이어그램들이 보다 섬세한 설계자의 의도를 반영할 수 있도록 세부적인 표기들이 많이 추가되고 세분화됐다. 즉, 사용할 수 있는 다이어그램 선택의 폭(width)이 넓어졌고, 설계자의 의도를 보다 정밀하게 반영할 수 있는 깊이(depth)도 깊어졌다.

원칙 셋, 모델 자체의 완성도를 높이자
앞서 소프트웨어 업계에서 최근 발생하고 있는 현상들을 통해 잠시 언급했지만, UML 관련 국내외 포럼이나 협회들을 중심으로 UML 자체 혹은 설계 능력 인증 제도가 점차 많아지고 있다. 필자가 인증 제도의 본질적인 목적이나 그 가치 자체를 부정하는 것은 아니지만, 올해 사회적으로 충격을 던져 주었던 대입 수능 시험에서의 대량 부정 사태라든지, 얼마 전부터 공공연하게 제기됐던 영어 관련 인증 제도 등에서 발생하고 있는 문제점 등에 비추어 UML 인증 제도에서도 충분히 발생할 수 있는 그 변별력 문제에 대해 우려를 감출 수 없다.

그러나 다행히도 UML 2.0이 가지고 있는 그 강력한 표현력(semantic expressiveness)과 섬세함(elements precision) 그리고 다이어그램들간의 유기적 연결성 지원(support for diagram interchange) 능력으로 인해 인증서를 가지고 있다고 들먹이지 않아도 모델 결과물 자체로 그 완성도를 검증(self verification)할 수 있다. 즉, 모델 결과물만으로도 충분히 설계자의모델링 역량을 충분히 증명할 수 있는기반을 제공하고 있는 것이다.

UML 2.0이 공식으로 발표되기 이전 특정 케이스 도구들을 중심으로 시도됐지만 UML 1.4의 제약으로 그 실효성(efficiency)을 의심받았던 코드 자동 생성(automatic code generation) 기능은 케이스 도구들이UML 2.0 엔진으로 교체함으로써 그 완성도를 높일 수 있게 됐다. 더 나아가 UML 2.0이 내포한 그 풍부한 표현력과 정교함은, 특정 플랫폼에 종속적인 코드를 생성해 내기 이전에 케이스 도구의 도움을 통해 모델들만을 가지고 사전에 시뮬레이션마저도 어려운 문제가 되지 않는다.

앞으로의 전망
지금까지 개발자들은 새로운 기술이나 제품이 출시되면, 여기저기서 화려한 수식어와 찬사로 밝은 미래를 전망하는 이야기에 너무나도 익숙해져 있다. 1997년 UML 1.1이 처음 세상에 나왔을 때도 마찬가지였다. 그런 맥락에서 단순히 UML 2.0이라는 새로운 패러다임에 무조건 주목하자고 주장하고 싶지는 않다. 실리에 밝은 국내외 소프트웨어 업체들과 협회들의 행보와 여러 가지 상황을 종합해 보아도 UML 2.0이 소프트웨어 산업계에 미칠 파장의 크기는 실로 엄청날 것으로 예상된다.

그것이 더 이상 거스를 수 없는 현실이라면 그러한 도전에 수동적으로 대처할 것인가, 아니면 능동적으로 대처할 것인가의 문제는 독자 스스로 선택할 문제이다. 혹시 이솝 우화에 나오는 거짓말하는 늑대 이야기에서처럼 중요하다는 말을 너무 자주 들어 개발자들이 UML의 중요성을 공허한 메아리 정도로만 치부하고 지나칠까 걱정될 뿐이다.@

* 이 기사는 ZDNet Korea의 제휴매체인마이크로소프트웨어에 게재된 내용입니다.

원문 :http://www.zdnet.co.kr/techupdate/lecture/etc/0,39024989,39134178,00.htm

MS 소프트웨어 사업 특명「RFID 잡아라!」

RFID기술에 대해 막대한 투자를 해온 MS가 드디어 RFID 소프트웨어 패키지의 첫 메이저 제품을 출시할 예정이다. 기업들은 RFID 소프트웨어 패키지를 사용해 제품 태그 기술을 관리하는 데 도움을 받을 수 있다.

MS는 내년 초 RFID 서비스 플랫폼을 출시할 계획이며, 이 플랫폼은 RFID 신호를 모니터하는 하드웨어와 RFID 정보를 인식하는 비즈니스 소프트웨어를 연결하는미들웨어제품인 것으로 알려졌다.

이 제품은 RFID를 자사 시스템에 통합하기를 바라는 기업들뿐 아니라, MS 기술에 기반을 두고 제품을 만들려고 하는 소프트웨어 기업들을 대상으로 설계된 것이다.

MS의 RFID 프로그램 부장 알렉스 렌즈는 지난 8일 CNET 뉴스닷컴과의 인터뷰에서 "RFID 제품은 MS 닷넷 개발 플랫폼 위에서 만들어지고 2개의 프로세서를 지닌 서버에서 구동될 것"이라고 말했다. RFID 제품에는 또한 정보를 저장하기 위해 MS SQL 데이터베이스 소프트웨어를 통합할 것으로 보인다.

저렴함을 무기로 승부
렌즈는 제품의 가격 정책을 털어놓지는 않았지만, 제품 가격이 전반적으로 떨어지고 있는 시장 상황에서 MS 제품이 낮은 비용으로 구매할 수 있는 제품으로 자리 잡기를 원한다고 강조했다. 그는 "우리는 이 제품이 턱없이 비싸지 않을 것이라는 점을 확신시킬 것이다"라고 말했다.

RFID는 벤처 기업들뿐 아니라 기술 분야의 많은 대기업들도 관심을 가지고 있는 분야다. IBM과 오라클은 이 영역에 매우 깊게 관련된 기업들이다.

흔히 전자 바코드라 불리는 RFID 태그는 제품에 대한 기본적인 식별 정보를 공유하는 신호를 보낸다. 이 태그는 제조부터 유통 그리고 소매점까지 제품을 추적하는 데 활용될 수 있다.

MS는 RFID를 자사의 광범위한 '더 현명한 소매 전략(Smarter Retail Initiative)’의 핵심 요소로 만들어왔다. MS는 또한 윈도우 XP의 임베디드 버전에서 태그 기술을 지원할 계획이라고 발표했다. 이는 특별히 소매업자들을 대상으로 한 계획이라고 한다.

이와 대조적으로 대부분의 고객들은 핵심 비즈니스 파트너가 태그를 제품에 추가하도록 강요하고 있기 때문에 마지못해 RFID를 받아들이고 있을 뿐이다.

렌즈는 '컨버전스 2005' 컨퍼런스에서 프레젠테이션을 통해 "제조업자들은 비즈니스 사례를 발견하기 위해 고군분투하고 있다"라고 말했다.

많은 경우에 있어, 제품 제조업자들은 월마트와 같은 소매업자로부터 강요를 받고 있다. 소매 분야의 거인인 월마트는 이미 대규모 납품업자들에게 특정 물류센터로 보내는 화물에 태그를 붙이도록 요구하고 있으며, 중소 납품업체들도 오는 2007년까지 같은 작업을 하도록 요구할 계획이다.

눈에 띄는 효과가 없는 것이 딜레마
대부분의 경우, 월마트 공급업자들은 제조 단계의 마지막에 태그를 달아서 월마트의 요구사항을 만족시키고는 있지만 비용 절감 또는 효율성 증가 등의 효과는 전혀 보지 못하고 있다.

MS는 더 많은 기업이 자사의 저비용 RFID 옵션을 통해 RFID를 공급망에 더 일찍 통합하기를 바라고 있다. SAP는 지난 2일, 인터멕과 협력 관계를 맺어 중소기업들이 파트너의 요구사항을 만족시킬 수 있도록 하겠다고 발표했다.

렌즈는 MS가 내년에 출시할 예정인 RFID 소프트웨어의 주요 장점 중 하나는 이 솔루션이 시장에 보급되는 다양한 RFID 하드웨어에 대응할 수 있는 점이라고 말했다.

RFID 미들웨어를 단독으로 공급하는 것 외에도 렌즈는 "MS가 내년에 나올 세 가지 비즈니스 애플리케이션에 미들웨어를 포함시킬 것"이라고 말했다. RFID 기술을 내장할 첫 번째 제품은 아삽타(Axapta) 4.0으로 내년 전반기 출시될 예정이다. 2개의 다른 제품, 네비전(Navision) 5.0과 그레이트 플레인(Great Plains) 9.0은 내년 하반기에 나올 예정이며, 이 두 제품에도 RFID 기술을 추가할 계획이다.

MS는 또한 글로브레인저와 커넥테라가 MS의 핵심 기술을 이들의 제품에 활용하는 계약을 체결했다고 발표했다. MS는 현재 육포 제조업체인 잭 링크 스낵을 포함한 2개의 초기 고객들을 보유하고 있다.

피할 수 없다면 맞이하라
렌즈는 RFID 투자가 성과를 거두게 되면 잭 링크와 같은 소규모 기업들은 실질적으로 혜택을 본다고 자신했다. 대규모 기업들은 제품 추적을 위해 바코드 분야에 이미 막대한 투자를 한 상태이기 때문에 RFID로 인한 부가적인 인력 비용 절약이나 효율성 증대는 미미한 실정이다. 그렇지만 RFID는 전반적으로 볼 때 바코드 시스템이 없는 기업에서 더욱 극적인 효과를 거둘 수 있다.

그는 "이들에게는 바코드 시대를 받아들여서 혁신을 위해 도약할 수 있는 기회가 있는 셈"이라고 말했다. @

Ina Fried (CNET News.com)

2005/03/10
원문보기

원문 :http://www.zdnet.co.kr/news/enterprise/0,39024412,39134402,00.htm

1. IP Autoconfiguration의 개념 및 주소의 종류

IP 주소 자동설정 기능은 IPv6 주소체계의 새로운 기능중 하나로, 각종 단말에 IPv6 주소가 자동적으로 생성되도록 한다. 이는 IPv6는 일반 PC 뿐만 아니라 콘솔이나 디스플레이가 없는 Embedded OS 및 non-PC 장치에 까지 IPv6 주소를 부여하고자 하기 때문이다.

IP 주소 자동설정기능을 이용함으로써 사용자는 별도의 IPv6 주소를 설정할 필요가 없으며, 관리자 또한 사용자별로 IP 주소를 할당해야하는 관리상의 불편함을 줄일 수 있다.

2. Link Local Address와 Global Address

일반적으로 IPv6 단말이 이용하는 주소에는 Link Local 주소와 Global 주소가 있다. Link Local 주소는 단일 네트워크 내에서 이용되는 주소로, 주로 관리 및 내부 통신 목적으로 활용된다. 반면 Global 주소는 외부의 IPv6 네트워크와 데이터 통신을 하기 위해 이용된다. Link Local 주소와 Global 주소 모두 IP Autoconfiguration에 의해 생성된다.

3. IPv6 주소 생성 방법

기존 IPv4 주소와 유사하게 IPv6 주소역시 수동 생성(Manual Configuration), 주소 할당에 의한 자동 생성(Stateful Address Autoconfiguration) 그리고 임의의 자동 생성(Stateless Autoconfiguration)으로 구분된다.

가. Manual Configuration

관리자 또는 사용자가 직접 자신이 사용할 IPv6 주소를 수동으로 입력하는 방식으로, 외부 서비스를 위한 서버를 이용할 때, 시스템이 변경되더라도 항상 동일한 주소를 가져야 하기 때문에 수동 설정을 많이 이용한다.

나. Stateful Address Autoconfiguration

IPv6 주소를 할당하는 별도의 서버(예: DHCPv6 서버)이 존재하고 시스템이 주소할당 시스템으로부터 적절한 주소를 할당받는 방식이다. 기존 IPv4의 DHCP(Dynamic Host Configuration Protocol)와 유사한 개념이다

다. Stateless Address Autoconfiguration

별도의 주소 관리 시스템 없이, 단말이 스스로 자신이 이용할 IPv6 주소를 생성하는 방식으로, 각 단말간 중복되지 않는 고유의 구분자(예: Mac 어드레스)를 이용하여 주소를 생성한다.

4. Stateless Autoconfiguration 절차

IPv6의 Stateless Autoconfiguration은 네트워크에 할당된 64bit Prefix와 인터페이스의 Interface ID의 조합으로 이루어진다. 즉 라우터에 할당된 64bir Prefix와 인터페이스(랜카드)에 부여되어 있는 MAC 어드레스의 조합을 통해 총 128bit의 IPv6 주소가 자동으로 생성되는 것이다.

Stateless Autoconfiguration 절차는 아래와 같다.

(1)네트워크의 새로운 단말은 Link Local 주소를 생성하고 인터페이스에 할당을 한다. Link Local 주소는 fe80:0000:0000:0000:0000 형태를 취한다.

(2)방금 생성한 Link Local 주소가 같은 네트워크내에 존재하는지 확인(DAD: Duplicate Address Detection)한다.

   가. 새로운 단말이 Neighbor Solicitation(NS) 메시지를 네트워크에 전송한다.

   나.만약 다른 단말이 동일한 주소를 사용하고 있으면, 그 단말이 Neighbor Advertisement(NA)메시지를 전송한다.

   다. 단약 일정 기간동안 NS 메시지를 받지 못하면, NS 메시지를 보낸 새로운 단말이 Link Local 주소를 이용한다.

   라.단약 NS 메시지를 보낸 단말이 NA 메시지를 통해 자신이 생성한 Link Local 주소가타 단말과 중복됨을 확인하면 Link Local 주소를 네트워크 인터페이스에 할당하지 않는다.

(3)새로운 단말은 라우터로부터 네트워크 정보를 얻기 위해 새로 생성한 Link Local 주소를 이용하여 Router Solicitation 메시지를 네트워크에 전송한다. RS 메시지를 전송하는 것은 필수는 아니며, RA 메시지가 올때까지 기다릴 수도 있다.

(4)RS 메시지를 받은 단말(주로 라우터)는 Router Advertisement(RA) 메시지를 전송한다. RA 메시지는 주기적으로 네트워크에 뿌려지기 때문에 반드시 RS 메시지가 필요한 것은 아니다.

(5)RA 메시지를 받은 단말은 IPv6 Prefix(상위 64bit) 정보를 얻게 된다.

(6)단말은 Link Local 주소 생성때와 유사하게 Prefix 정보와 인터페이스 ID(하위 64bit)를 조합하여 128bit Global Address를 생성한다.

5. Generation of Interface ID

지금까지 단말이 속한 네트워크의 Prefix 정보를 얻는 절차에 대해 알아보았다. 이제 단말자신의 Interface ID를 생성하는 방법에 대해 알아보자.

인터페이스 ID가 생성되는 방식은 인터페이스의 종류에 따라 다르다. 일반적인 Ethernet 인터페이스의 경우 IEEE EUI-64(Extended Unique Identifier-64) 주소가 생성된다.

모든 Ethernet 인터페이스는 IEEE 표준에 의해 할당받은 유일한 주소(MAC 어드레스)를 가지고 있다. 현재 MAC 어드레스는 48bit(6byte)의 물리적 주소를 가지고 있으며, 그 형태는 아래 그림과 같다.

Ethernet 인터페이스는 아래와 같은 절차에 의해 MAC 어드레스로부터 인터페이스 ID(EUI-64 주소)를 생성하게 된다.

인터페이스 ID 생성 절차

(1)MAC 어드레스가 두 부분으로 분리된다.

   - 일반적으로 24비트와 25비트 사이, 혹은 3번째 바이트와 4번째 바이트 사이

(2)"ff fe"가 3번째 바이트 사이에 삽입된다.

(3)MAC 어드레스의 나머지 3바이트가 뒤에 붙는다.

(4)처음 8비트중 7번째 비트에 “Universal/Local" 비트임을 나타내는 수치가 더해진다.

   - 1이면 Universal 관리 주소, 0이면 Locally 관리 주소

(5)처음 8비트중 8번째 비트에 “Individual/Group" 비트임을 나타내는 수치가 더해진다.

   - 0이면 유니캐스트 주소, 1이면 멀티캐스트 주소

실제로 생성된 Interface ID의 예를 보면

Auto Configuration에 의해 생성된 2001:2b8:80:12:209:6bff:fee3:f8be IPv6 주소중 Interface ID 부분은 “209:6bff:fee3:f8be”이며 16진수를 2진수로 변경하면 아래와 같다.

0000001000001001011010111111111111111110111000111111100010111110

위 2진수중 7번째 비트가 1로 되어 있으므로 Universal administrated address 이고, 8번째 비트가 0이므로 유니캐스트 주소이며, 주소 생성 절차에 의해 24비트 ~ 40비트 까지가 1111111111111110(16진수 ff fe)로 채워진 것을 확인할 수 있다.

6. IPv6 주소 정보의 확인

http://doc.tavian.com/ipv6util사이트의 IPv6 확인 도구를 이용하여 IPv6 주소의 정보를 아래와 같이 확인이 가능하다.

1. 전시회 개요

   o 일시 : 2004. 11. 16 ~ 18
   o 장소 : 일본 동경 Tokyo International Forum
   o Global IP Business Exchange 전시 행사 구성
       - 총 3개의 쇼케이스로 구성되었으며, 약 30여개의 기업이 50여종의 제품을 전시함

2. IPv6 Ready Logo 프로그램 및 인증 제품 전시

 가. IPv6 Ready Logo 프로그램

   o Global IPv6 포럼과 일본의 IPv6 관련 기관을 중심으로 추진되고 있는 IPv6 Ready Logo
      프로그램에 대한 안내 및 인증 획득 제품 전시

   o IPv6 Ready Logo 프로그램 홍보
     - 현재 진행되고 있는 Phase I에 대한 전반적인 안내 및 향후 진행될 Phase 2에 대한 정보를
        제공하고 있었음
     - Phase I의 경우 IPv6 Core Protocol에 대한 테스트를 통해 인증로고를 부여하고 있으며,
        현재 약 130여개의 제품이 인증로고를 받았음
     - Phase 2 프로그램은 2004년 12월 중으로 실시될 예정이며, Core Protocol이외에
        Mobile IPv6, 변환기술, 라우팅 프로토콜에 대한 부분까지  확대할 계획이라고 함

  나. IPv6 Ready Logo 인증 제품 전시

   o 일본 IPv6 Promotion Council의 주관으로 IPv6 Ready Logo를 받은 제품을 한자리에 모아서
      전시를 하고 있었고, IPv6 지원 라우터, L3 스위치, 방화벽, 임베디드 OS 등이 전시되었음

   o 주요 전시 제품 및 솔루션
       - Allied Telesis : 소형 IPv6 지원 네트워크 제품
          · CentreCOM 9924Ts : IPv6 지원 Gigabit L3 Switch
          · CentreCOM AR450S : IPv6 Broadband Router(소형 라우터)
       - Nokia : IPv6 지원 방화벽
       - Wind River : IPv6 지원 OS Stack, Wind River Network Stack v2.0
       - Extream Networks : Extream Black Diamond 6800 IPv6 지원 L3 스위치
       - Internet Initiative Japan Inc. : 소형 라우터 제품
          ·  SEIL neu 2FE Plus IPv6 Access Router, SEIL Turbo IPv6 Router

   o 일본의 경우 대규모 백본용 네트워크 장비보다는 소규모 네트워크 제품을 중심으로
      발 빠르게 IPv6 지원 장비를 출시하고 있었음
       - 관계자의 말에 의하면 백본용 장비는 CISCO, Hitachi, Juniper와 같은 대형 벤더와 경쟁하기
          곤란하므로 상대적으로 개발이 용이하고, 진입장벽이 낮은 엑세스급 네트워크 장비를 위주로
          IPv6 지원 장비 개발을 진행한다고 함

3. 파나소닉 IPv6 제품 전시

   o 그동안 꾸준히 IPv6 관련 제품을 출시하였던 파나소닉은 자사의 IPv6 관련 제품을 한곳에 모은
      별도의 부스를 마련하였음

   o 파나소닉은 기존 네트워킹 제품과 함께, 건물 및 설비 관리(facility management) 솔루션 전시

   o IPv6 네트워크 카메라(총 4종)
      - 이번 전시회에는 총 4종의 IPv6 네트워크 카메라(KX-HCM180, BB- HCM311, BB-HCM331,
         BB-HCM371)가 전시되었으며, 이중 3종의 네트워크 카메라가 상용화되어 일반인 구입 가능
      - 세계 최초의 IPv6 네트워크 카메라 개발 기업답게 작은 외형과 깔끔한 디자인

,

  o 건물 및 설비 관리(facility management) 솔루션
     - 건물관리를 위한 조명 제어 솔루션으로 사람이 직접 현장에 가지 않고도 원격에서 전원장치의
        릴레이(relay)를 제어할 수 있음
     - 즉, IPv6 주소가 내장된 소형 콘트롤 박스(BX : Building Exchange)와 조명 제어를 위한
        릴레이가 시리얼 라인으로 연결되어 있으며, 사용자는 웹 인터페이스를 통해 조명의 상태 제어      - 한국전산원 IPv6 체험관에 있는 SINKBoard와 유사한 개념

  o IPv6 지원 네트워크 프린터(WORKIO CL-500)
     - 기존 네트워크 프린터의 프린터 서버 모듈을 수정하여 IPv6를 지원할 수 있도록 수정한 제품
        아직 시판되지는 않는다고 함
     - IPv6의 자동주소 할당기능을 이용하여, 자동으로 프린터에 IP 주소가 할당되며,
        사용자는 별도의 설치 절차 없이 간단하게 프린터를 이용할 수 있다고 함

4. IPv6를 이용한 건물 및 설비 관리 관련 전시

   o Global IP Business Exchange 2004의 주요 이슈중 하나가 IP 네트워크를 이용한 건물 및
      설비 관리(facility management)임
      - 파나소닉, 요코가와 전기, NEC 등의 전기전자 기업이 건물 관리를 위한 IPv6 기반의 각종 제어
         장치를 개발하고, 건설회사에서 이를 실제 건설현장에 도입하고 있음
      - 즉, IPv6를 Intelligent 빌딩, Home 네트워크의 구현에 필요한 핵심 요소기술로서 인식

  o 요코가와 전기 : Fis(Field information Server)
      - 실외의 기온, 풍향, 풍속, 습도, 강수량 등의 각종 정보를 IPv6 네트워크를 통해 원격지로 전달
      - 원격지에서는 각종 계측 정보를 바탕으로 적절한 의사결정을 내리거나 원격 제어장치를 작동
      - Fis 모듈에는 IPv6를 지원하는 OS가 내장, 각종 센서 데이터를 IPv6 네트워크로 전송함

  o 요코가와 전기 : Xancia
     - Windows CE 기반의 Embedded OS를 내장한 초소형 단말
     - 각종 외부 입출력 포트(Serial, Digital-I/O, 이더넷 등)를 활용하여 다양한 장치를 제어

  o 청수건설(淸水建設) 주식회사 : IPv6 기반 건물 환경 관리
     - 청수건설에서는 IPv6 기반의 건물관리 솔루션을 활용하여 실제 건물관리에 활용하고 있음
     - 건물내부의 온도, 습도, 조도, 전압, 전력 등을 실시간으로 모니터링 하여, 사용자가 원하는
        최적의 상태로 유지할 수 있다고 함
     - 한국전산원 IPv6 체험관 내의 무드 스피어와 유사한 솔루션임

  o 기타
     - 파나소닉 : FreeFit Light 콘트롤러

     - 도시바 : GIGABINE, Ethernet-to-Loanworks 게이트웨이

 

5. IPv6 지원 운영체계(OS)

   o Embedded OS와 Linux 기반의 IPv6 운영체제가 선보였으며, 소형 임베디드 기기에 IPv6를
      적용하는 추세를 반영하고 있었음
      - MiSPO의 NORTi,
      - Wind River의 VxWorks
      - ELMIC Systems의 KASAGO IPv6 실시간 Embedded OS
      - 알파시스템의 KNOPPIX Bootable Linux OS가 전시되었음

   o KNOPPIX/IPv6 Live Linux
      - KNOPPIX는 별도의 설치과정 없이 바로 CD로 부팅하여 사용할 수 있는 테스트탑용 Linux OS
      - IPv6 프로토콜 스택, 터널링, 자동주소설정 등 IPv6에서 요구되는 기본기능을 제공하며
         웹브라우저, 오피스프로그램 등이 포함되어 가정이나 기업에서 이용하기 용이함

,

  o NORTi RTOS(Real Time Embedded OS)
     - NORTi는 일본 TRON 프로젝트의 일환으로 개발된 임베디드 OS,  IPv6 프로토콜 스택 지원
     - 일본에서 개발된 다수의 IPv6 지원 임베디드 기기에 NORTi RTOS가 탑재되어 있다고 함

6. IPv6 네트워크 장비

   o 이번 전시에서는 Hitachi, NEC와 같은 대형 IPv6 장비 제조사뿐만 아니라,
      중소규모 기업의 다양한 IPv6 장비가 전시되었음

   o 주요 전시 제품
      - 시스코 : 모바일 라우터 - CISCO 3200 Mobile Access Router
      - NEC : IPv6 라우터 - IX2000/IX1000/IX3010
      - Extream Networks - BlackDiamond 10808
      - 후지스 : IPv6 라우터 - GeoStream SI-R370
      - FITEL : IPv6 라우터 - FITELnet-F3000, F1000, F100
      - 파나소닉 : IPv6 홈게이트웨이 - BB-HGW502
      - 야마하 : IPv6 라우터 - RTX1500, RTX1000
      - ALLIED Telesis : 소형 라우터 - AR450S
      - Internet Initiative Japan - SEIL Plus, SEIL Turbo
      - YOKOGAWA : TTB IPv6/IPv4 변환기 - TTB3020

   o CISCO : CISCO 3200 Mobile Access Router\
      - 이동중에 소규모 IPv6 네트워크 구성이 가능한 모바일 라우터 제품
      - 본 전시회에서는 실제 데모를 볼 수 없었으나, 미국의 경찰업무에 시범적으로 적용됨

,

   o NEC : IPv6 라우터 - IX2000/IX1000/IX3010
      - NEC는 저가의 소형 엑세스급 라우터 2종과, 중형 라우터 1종을 전시
      - 이중 소형 엑세스급 라우터는 원화로 약 1백~2백만원 정도로,
         대규모 벤터의 장비와 기술 및 가격 측면에서 경쟁력이 있다고 판단됨

,

   o 파나소닉 : IPv6 홈게이트웨이 - BB-HGW502
      - 가정에서 유무선 인터넷을 이용하기 위한 IPv6 홈게이트웨이 장비
      - KOREAv6 시범사업에서 (주)에스넷시스템의 Ubi-6 G10 장비와 유사한 개념 및 기능제공

   o 야마하 : IPv6 소형 라우터
      - 야마하에서는 IPv6 소형 라우터와 IPv6 지원 홈게이트웨이 장비 전시
      - 특히 IPv6 홈게이트웨이는 ADSL에서 IPv6 네트워크를 지원하며,
         일본내 IPv6 시범사업에 이용된다고 함

,

   o YOKOGAWA : TTB IPv6/IPv4 변환기 - TTB3020
      - 이번 전시회에 유일한 IPv6/IPv4 변환기로 NAT-PT 기능을 수행함
      - 국내 iBIT의 Forsix IPv6/IPv4 변환기와 기본 기능을 동일하며,
         SIP 프로토콜을 위한 ALG(Application Level Gateway)를 지원함
      - 파나소닉의 PSTN-VoIPv6 게이트웨이를 이용하여 IPv6 인터넷전화와 IPv4 인터넷전화간의
         변환기능을 시연하였음

,

KOREAv6.VSIX.NET

 o 다양한 분야의 일반이용자들에게 IPv6 이용을 권장하여 IPv6 서비스를 활성화 하고

 o 실망(real-network)에서 IPv6 장비 및 솔루션에 대한 시험 운영 프로젝트

 KOREAv6 진행 단계

   o KOREAv6 1단계 : 2003년 : KOREAv6 백본 네트워크 구성, 시범사업 기획
   o KOREAv6 2단계 : 2004년 : KOREAv6 백본 확장, 시범 서비스 및 시험 운영 실시
   o KOREAv6 3단계 : 2005년 : KOREAv6 백본 확장, 휴대인터넷, RFID, BcN 사업과 연계
   o KOREAv6 4단계 : 2006년 : IPv6 서비스 상용화 단계
 

KOREAv6 백본

   o 이미 구축되어 있는 국내의 IPv6 망들을 연계한 국내 최대의 IPv6 망 구축함
      - 6NGIX를 중심으로 6KANet, KREONET, KOREN 등의 연구망과
      - 상용 ISP 사업자의 IPv6 망을 포함
   o KOREAv6 시범 서비스와 시험 운영을 위한 기반 인프라로 활용함

IPv6 시범 서비스

  o다양한 분야의 IPv6 시범 서비스 제공하여 실제 IPv6 이용자를 확보
  oIPv6 서비스 구현 및 서비스 제공에 대한 가이드라인 제시
  o11개 시범서비스, 35개 기관 참여
      -IPv6 인터넷을 이용한 자연생태계 모니터링 서비스
      -통신사업자(DACOM)의 IPv6 서비스
      -SOHO용 유무선 IPv6 Internet Gateway를 이용한 시범서비스
      -IPv6-IPv4 통합 모바일 홈네트워크 시범망 구축 및 시범 서비스
      -IPv6 고품질 영상 전송 서비스
      - 가정에 IPv6 시스템-응용서비스 도입 및 이용활성화
      - IPv6를 활용한 병원용 디지털 차트 시스템 시범서비스
      - IPv6 캠퍼스 망에서 원격 가상 저장장치를 이용한 모바일 학습서비스
      - 학교 내에 IPv6 시스템-응용서비스 도입 및 이용활성화
      -VoIPv6 음성 및 화상 서비스
      - IPv6 포탈 서비스 및 IPv6 체험관 서비스
 

IPv6 장비 시험 운영

  o실망에서 IPv6 장비의 기능 검증 및 여러 IPv6 장비간 상호 운영성, 기능 확인
  oIPv6 시험운영에 대한 가이드라인 제시
  o개방된 IPv6 시험운영 환경을 제공하여 업체의 기술력 향상에 기여
  o18개 업체, 39개 제품 시험 운영 참가

Windows XP SP1 + 고급네트워킹 팩 내장 IPv6 Firewall 활용 Part 1

Part1에서는 IPv6 ICF의 주요 기능 소개, IPv6 네트워크 인터페이스의 필터링 설정을 다룹니다.

1. IPv6 Internet Connection Firewall - IPv6 ICF

최근 다양한 애플리케이션이 개발되고, 보안에 대한 관심이 높아짐에 따라 Windows XP 및 2003 OS에서는 간단한 IPv4 방화벽(firewall)을 내장하고 있습니다.[그림1]

하지만, IPv6 애플리케이션이 늘어나고, End-to-End 연결성을 지향하는 IPv6의 특성상 IPv6 네트워크에 대한 보안의식이 증대되면서 IPv6 방화벽에 대한 관심이 증가하고 있습니다.

이러한 추세를 반영하여 Microsoft에서는 Windows SP1(서비스팩 1)에 고급네트워킹 팩(Advanced Networkig Pack)을 설치하거나 Windows XP SP2를 이용하는 경우 IPv6 Internet Connection Firewall을 지원하고 있습니다.

Windows XP SP1 + 고급네트워킹팩에 내장된 IPv6 ICF와 Windows XP SP2에 내장된 IPv6 ICF는 서로 사용방법이 다른 까닭에,본 문서에서는 Windows XP SP1 + 고급네트워킹팩을 이용하는 경우를 가정하고 설명하겠습니다.

Windows XP SP2용은 향후 별도의 문서로 설명할 예정입니다.

2. IPv6 ICF의 위치 확인

[그림1]처럼 IPv4 ICF는 각 네트워크 인터페이스의 속성에서 [고급] 탭을 선택하면 이용을 할 수 있습니다. 하지만 IPv6 ICF는 [그림1]같은 GUI가 제공되지 않으므로,netsh를 통한 CLI(Command Line Interface)를 이용해야 합니다.

명령 프롬프트에서netsh와firewall을 입력하면 IPv6 ICF 설정 메뉴로 들어가게 됩니다.[그림2]
** IPv6 ICF 설명 메뉴에서 ?를 입력하면 관련 도움말을 볼 수 있습니다.

3. IPv6 네트워크 인터페이스에 대한 IPv6 ICF 적용 상태 확인

구체적인 IPv6 방화벽 설정에 앞서, 현재 각 IPv6 네트워크 인터페이스에 대한 IPv6 ICF 적용 상태를 확인해 보겠습니다.

>> netsh firewallshow adapter

show adapter명령은 시스템에 설치된 모든 IPv6 네트워크 인터페이스에 대한 IPv6 ICF 적용 상태를 표시합니다. 별다른 설정을 하지 않았으면 [그림3]처럼 모든 네트워크 인터페이스가 필터링되고 있습니다.

** IPv6FilteringEnabled가 "예"로 되어 있으면 해당 인터페이스에 방화벽이 활성화되어 있다는 의미 입니다.

특정 IPv6 네트워크 인터페이스에 대한 구체적인 방화벽 적용 상태를 확인하려면netsh firewall show adapter "네트워크 인터페이스 명"을 실행합니다.[그림4]

>> netsh firewallshow adapter ADSL

4. IPv6 방화벽 적용 상태 변경

특정 IPv6 네트워크 인터페이스에 대해 방화벽 적용 상태를 변경하기 위해서는netsh firewall set adapter명령을 이용합니다.

netsh firewall set adapter명령을 입력하면 [그림5] 같은 옵션을 확인할 수 있습니다.

o name :: 네트워크 인터페이스의 이름

o icmp :: IPv6 icmp 필터링의 활성화 여부

o port :: 특정 포트의 필터링 여부

o protocol :: tcp, udp의 선택

o ignoreglobalport :: 글로벌 포트 설정의 무시 여부

o filtering :: 필터링의 여부

 

예)netsh firewallset adapter "6to4 Pseudo-Interface" filtering=disable
     ** 6to4 Pseudo-Interface의 IPv6 방화벽 설정을 해제함[그림8]

예)netsh firewallset adapter "Automatic Tunneling Pseudo-Interface" icmp all=enable filtering=enable
     ** Automatic Tunneling Pseudo-Interface(보통 ISATAP)에 방화벽을 적용하되, icmp 프로토콜은 허용함

[그림6]에서icmp all=enable에서icmp all=disable로 설정을 변경했을 때, ping에 대한 응답을 더 이상 하지 않는 것을 확인할 수 있다.

참고 :: Windows XP에서 고급네트워킹팩을 설치한후 해당 PC로 ipv6 ping이 안되는 이유는, 고급네트워킹팩이 설치되면 모든 인터페이스의 방화벽 설정이 enable 되기 때문입니다.

예)netsh firewallset adapter "ADSL" port 80=enable
      ** ADSL 인터페이스의 80 포트를 오픈함

[그림7]에서 TCP 프포토콜 80포트에 대해 IPv6 방화벽이 Open 되었음을 알 수 있습니다.

예를 들어 Native IPv6 환경에서 IPv6 웹서버를 운영하고 있는 경우, 외부 접속은 물리적 네트워크 인터페이스의 80포트를 통해 이루어 집니다.

이 경우 netsh firewall set adapter "물리적 인터페이스명" filtering=disable명령을 통해 해당 네트워크 인터페이스에 대한 IPv6 방화벽 적용을 해제하거나

netsh firewall set adapter "물리적 인터페이스명" port 80=enable filtering=enable명령을 통해 IPv6 방화벽은 적용하되 80포트는 open 해야지만 외부에서 80 포트로 웹서버에 접속 할 수 있습니다.

만약 6to4 터널링 환경에서 IPv6 웹서버를 운영한다면 6to4 터널링 인터페이스(6to4 Pseudo-Interface)의 80번 포트를, ISATAP 터널링 환경에서 IPv6 FTP 서버를 운영한다면 ISATAP 터널링 인터페이스(Automatic Tunneling Pseudo-Interface)의 20, 21번 포트를 각각 오픈해 주어야 합니다.

Part2에서는 IPv6 ICF의 Global Port와 Logging 기능에 대해 알아보겠습니다.

IPv6 ICF Part 1에서는 기본적인 설정 방법에 대해 알아보았습니다.

IPv6 ICF Part 2에서는 모든 IPv6 네트워크 인터페이스에 공통으로 설정을 적용하는globalport 명령과 IPv6 ICF의 동작결과를 기록하는logging 명령에 대해 알아보겠습니다.

1. set globalport 명령 및 show globalport 명령

Part 1에서 설명한 set adapter 명령은 특정한 하나의 네트워크 인터페이스에 대한 설정을 변경합니다. 그런데, 경우에 따라시스템에 설치된 모든 네트워크 인터페이스에 공통적으로 적용하거나 변경해야할 필요가 있습니다. 이 경우 set globalport 명령을 이용할 수 있습니다.

set globalport명령의 결과는 모든 IPv6 네트워크 인터페이스에 공통적으로 적용됩니다.

명령어 프롬프트에서netsh firewall set global명령을 입력합니다.[그림1]

o port# : 방화벽에서 개방(open)할 포트번호, enable은 개방을 한다는 의미

o name : 방화벽 룰(rule)에 대한 이름 지정

o protocol : tcp, udp 프로토콜 종류 지정
 

예를 들어 웹서버와 관련된 80포트를 개방(open)하기 위해서는 아래 명령을 입력합니다.[그림2]

netsh firewallset globalport 80=enable name=webserver

globalport의 적용 결과를 확인합니다.[그림3]

netsh firewallshow globalport

위 그림에서 보면, 80포트가 개방되어 있고, 이름이 webserver로 지정된 것을 확인할 수 있습니다.

만약 다시 80포? 폐쇄하려면,set global 80=disable명령을 입력합니다.

globalport 적용예를 더 들어보면

netsh firewallset globalport 53=enable name="open dns server" protocol=udp

netsh firewallset globalport 22=enable name="open ssh port" protocol=tcp

위 명령을 실행한뒤show globalport명령으로 결과를 확인합니다.[그림4]

2. set logging 명령 및 show logging 명령

set logging 명령을 이용하여 IPv6 ICF에서 발생한 각종 이벤트를 특정 파일에 기록할 수 있으며, 나중에 이 기록을 바탕으로 각종 분석을 실시하게 됩니다.

명령어 프롬프트에서netsh firewall set logging명령을 입렵합니다.[그림5]

o filelocation : 로그파일이 저장될 위치를 지정

o filesize : 로그파일의 크기

o droppedpackets : 방화벽에서 차단된 패킷의 정보 저장 여부

o successfulconnections : 정상적으로 통과된 연결 정보의 저장 여부

예) netsh firewallset logging filelocation=c:\logfile.log filesize=4096

예) netsh firewallset logging droppedpackets=enable

예) netsh firewallset logging successfulconnections=enable filesize=9068

netsh firewallshow logging명령을 이용하여 정책에 대한 설정을 확인할 수 있습니다.[그림6]

SW업계, "RFID 앞으로!"

전자태그(RFID)를 향한 소프트웨어 업계의 움직임이 급물살을 타고 있다.

한국IBM, 한국오라클, 티맥스소프트 등 미들웨어 업체들은 최근들어 RFID 지원 전략을 발표하고 신제품도 출시하는 등 이제 막 시작된 RFID SW 시장에서 격렬한 주도권 쟁탈전을 시작했다.

SW업계에 RFID는 기존 제품 판매를 확대할 수 있는 매력적인 신규 시장.

RFID로 효과를 나타내려면 SW를 활용, RFID와 기존 IT시스템을 연결하는 작업이 필수적이기 때문이다. 결국 SW가 받쳐주지 못하는 RFID는 무용지물이라는 얘기다.

관련 업계에 따르면 기업들이 RFID에 대한 관심은 높지만, 효과에 대한 확신이 부족해 투자는 망설이고 있는 단계로 평가된다.

한국IBM은 "관심은 높은데, 투자대비 효과 측면에서 고민하고 있는 것 같다"면서 "그러나 최근들어 창고 관리 등 몇몇 업무에서 RFID는 투자 가치가 있다는 인식이 확산되고 있다"고 설명했다.

이는 멀지 않은 장래에 기업들이 RFID 도입에 적극 나설 가능성이 크다는 것을 의미한다. 기업 입장에서 보면 먼저 시장에 들어가서 사전 정지 작업을 벌여야할 시점에 이르렀다는 얘기다.

◆ RFID와 SW의 관계는?

기업들이 RFID를 갖고 효과를 보려면 RFID로 수집한 정보를 기존 IT시스템과 연결하는 작업이 선행돼야 한다.

그러자면 기존 IT시스템에 RFID가 가진 특수성을 반영시킬 수 있는 미들웨어가 필요해진다. SW업체들이 말하는 RFID 솔루션은 대부분 이같은 미들웨어를 뜻한다.

한국IBM에 따르면 RFID 관련 미들웨어는 3가지로 이뤄진다.

첫번째 필요한 미들웨어는 RFID 제어기. RFID 제어기는 RFID 리더기를 거쳐 들어온 정보를 처음으로 읽어들이는 역할을 담당한다. RFID 제어기는 사업장마다 여러 개가 설치될 수 있으며, 겉은 하드웨어 형태지만 내부에는 모바일DB 등 각종 임베디드SW를 포함하고 있다.

RFID 제어기 다음에는 RFID로 수집한 정보를 기존 IT시스템과 연계하는 미들웨어가 배치된다. 한국IBM은 이같은 미들웨어를 '프레미스서버'라고 부른다. 유통센터별로 하나씩 설치되는게 일반적이라고 한다.

이 미들웨어가 수행하는 핵심 역할은 RFID로 확보한 데이터중 사업에 필요한 것만 골라내 내부 시스템에 보내주는 것. 이를 감안하면 RFID 미들웨어중 핵심 제품이라고 할 수 있다.

이 과정을 거친 RFID 정보는 기업 비즈니스프로세스와 실실적으로 통합된다. 이같은 업무는 기업애플리케이션통합(EAI)이나 비즈니스프로세스관리(BPM) 솔루션으로 해결할 수 있다.

SW업체들이 RFID 프로젝트를 수주하면 RFID 미들웨어만 팔 수 있는게 아니다. RFID 미들웨어를 구성하는데 필요한 데이터베이스관리시스템(DBMS), 웹애플리케이션서버(WAS), EAI 등 전통적인 미들웨어 판매 수입도 덤으로 챙길 수 있다.

SW업계가 RFID를 주목하는 이유는 바로 이 때문이다.

◆ 주도권을 확보하라

이를 보여주듯 최근들어 SW업계의 RFID 시장 공략 작전이 본격화했다. 실제 영업보다는 잠재 고객들을 상대로 한 설명회나 세미나에 초점이 맞춰져 있다.

한국오라클은 지난달 18일 RFID 플랫폼 '오라클센서기반서비스'를 출시하고, 국내 RFID 시장 공략을 공식화했다.

'오라클엣지서버'와 '오라클센서데이터허브'로 구성된 '오라클센서기반서비스'는 분산된 데이터를 원격지에서도 통합 관리할 수 있는 환경을 제공한다. 리더기에서 추출된 데이터가 애플리케이션으로 전달되기전, 데이터를 정제할 수 있는 기술도 내장하고 있다.

한국오라클은 지난달 26일 코엑스 인터콘티넨탈 호텔에서 'RFID와 센서 기반 서비스'를 주제로한 기술 세미나도 개최, RFID 시장 공략에 대한 의지를 분명히 했다.

한국IBM도 RFID 소프트웨어 시장 선점에 본격적인 시동을 걸었다. RFID 미들웨어를 활용, 전사적인 IT시스템과 효과적으로 통합할 수 있는 솔루션 제공에 전력을 집중하고 있다. 이외에도 한국사이베이스, 티맥스소프트, SAP코리아 등 주요 SW업체들도 RFID 지원 SW를 선보이고 경쟁에 뛰어들었다.

관련 업계의 이같은 행보는 RFID 시장에서 초반 주도권 확보를 위한 첫번째 힘겨루기 양상을 띄고 있다. 이를 감안하면 이들 업체들은 당분간 레퍼런스 확보와 마케팅 캠페인을 통해 분위기를 잡아나가는 전술을 구사할 것으로 전망된다.

또 수요 확산에 대비, 자사 플랫폼 기반으로 RFID 응용 애플리케이션을 개발할 수 있는 우수한 독립소프트웨어벤더(ISV)를 확보하는 작업도 본격화할 것으로 전망된다.

황치규기자delight@inews24.com
2004년 12월 07일

원문 :http://www.inews24.com/php/news_view.php?g_serial=131994&g_menu=020200&pay_news=0

유비쿼터스 컴퓨팅 환경을 위한 RFID 기반 센서 데이터 처리 미들웨어 기술 동향

유비쿼터스 컴퓨팅을 가능하게 하는 차세대 핵심 기술로 RFID 기술이 주목 받고 있으며, RFID를 기반으로 하는 유비쿼터스 컴퓨팅 환경에서 응용 서비스를 제공하기 위하여 다양한 각도에서 연구 개발이 진행되고 있다. 본 고에서는 RFID를 기반으로 하는 유비쿼터스 컴퓨팅 환경을 구 현하기 위한 EPCglobal의 EPC Network Architecture의 구성 요소에 대하여 알아보고 이를 지원하는 미 들웨어 제품 및 솔루션을 살펴보고, 연속적으로 들어오는 데이터 스트림을 실시간으로 처리하기 위해 수 행되고 있는 프로젝트들의 기술 동향에 대하여 논의한다.

서 론

5C(Computing, Communication, Connectivity, Contents, Calm) 또는 5Any(Any-time, Any-where, Any-network, Any-device, Any-service)를 지향하는, 즉 모든 장소에 컴퓨터가 있어 그것을 자유롭게 누구나가 사용할 수 있는 인간 중심의 미래 컴퓨터 환경인 유비쿼터스 컴퓨팅 환경 실현을 위한 연구 개발이 활발히 진행되고 있다. 마크와이저에 의 하여 제창된 유비쿼터스 컴퓨팅의 주요 사상 중 하나인 고요한 상거래(silent commerce)를 가능하게 하는 차세대 핵심 기술로 RFID 기술이 주목 받고 있으며, RFID를 기반으로 하는 유비쿼터스 서비스 환경 구축을 위한 연구 개발이 진행되고 있다.

사용자의 다양한 요구를 시간과 장소에 상관없이 가능하게 하는 유비쿼터스 서비스 환경을 위해서는 내재되는 다양한 컴퓨팅 디바이스가 생성하는 다양한 대량의 정보를 가공하여 사용자 또는 응용 서비스에게 전달해주는 미들웨어 기술이 요구된다.

본 고에서는 RFID 기술을 기반으로 한 유비쿼터스 컴퓨팅 환경에서 응용 서비스 구축을 지원하는 센서 데이터 처리 미들웨어 기술에 대하여 설명한다. 먼저 유비쿼터스 서비스 환경의 참조 모델로 RFID를 물류, 유통 분야에 적용한 EPCglobal의 EPC Network Architecture에 대하여 살펴보고, RFID 기반의 응용 서비스를 위하여 수집된 RFID 데이터로부터 필요한 데이터를 필터링하여 적절한 장소와 적절한 시간에 전달하는 대표적인 미들웨어 제품에 대하여 소개한다. 또한 이와 같은 미들웨어의 핵심 요소 기술로 끊임없이 연속적으로 들어오는 RFID 데이터를 처리하는 기술인 데이터 스트림 처리 기술 연구 동향에 대하여 설명한다.

EPC Network Architecture

21세기형 차세대 정보 인식을 목적으로 MIT, UCC, P&G 등 46개의 협력사가 공동으로 1999년에 설립된 auto-ID 센터에서는 상품의 세부 정보를 담고 있으며 RF(Radio Frequency) 를 사용하여 내장된 정보를 전송하는 스마트 태그를 각종 상품에 부착해 사물을 지능화하여 사물간, 또는 기업 및 소비자와의 통신을 통해 자동화된 공급망 관리 시스템 구축을 위한 기술을 개발하였다. 이를 표준화하고 상용화하기 위하여 설립된 EPCglobal에서 제안한 EPC Network Architecture는 (그림 1)에 보이는 바와 같이 Electronic Product Code(EPC), 전파식별(Radio Frequency Identification: RFID)와 RFID 리더, SAVANT, EPC 정보서버(Information Server), ONS(Object Name Server) 로 구성된다.

EPC

EPC는 새롭게 생성되거나 이미 존재하는 모든 객체들을 유일하게 식별할 수 있도록 주어지는 객체 고유의 코드로 (그림 2)에 보인 것과 같이 EPC 코드에 대한 형식, 버전, 길이 등의 정보를 갖는 EPC 헤더(header), EPC 코드의 관리 책임을 갖는 기업, 즉 제조회사 코드를 표시하는 EPC manager 번호, SKU와 같은 상품의 분류 번호를 표시하는 object class, 그리고 품목 내에서의 개별 제품의 고유 일련번호(serial number)로 구성된다[1]. [1]은 또한 기존의 다양한 코드 체계를 수용하기 위하여 64bit와 96bit 길이의 EPC 코드 체계를 정의하였으며, (현재 256bit 길이의 EPC 코드 체계에대한 표준화 작업이 진행되고 있음) GID(General IDentifier), SGTIN(Serialized Global Trade Identification Number), SSCC(Serial Shipping Container Code), SGLN(Serialized Global Location Number), GRAI(Global Returnable Asset Identifier), GIAI(Global Individual Asset Identifier) 와 같은 다양한 코드 체계를 EPC 코드 체계로 전환하기 위한 매핑 표준을 정의하고 있다.

RFID & RFID 리더

스마트 태그(smart tag)라고도 불리우는 전파식별(RFID)은 무선 주파수를 발산하는 아주 작은 마이크로 칩에 각종 정보를 저장하는 RFID 태그와 태그에 저장되어 있는 정보를 읽거나 기록할 수 있는 RFID 리더와 안테나로 구성된다.

RFID 태그는 태그가 사용하는 전원(power) 의 유무, RFID 태그가 사용하는 주파수 및 RFID 태그가 제공하는 기능에 따라 분류될 수 있다.

전원의 유무에 따라 RFID 태그는 수동형(passive)태그, 반수동형(semi-passive) 태그, 그리고 능동형(active) 태그로 구분할 수 있다. 수동형 태그는 태그의 동작을 위한 전원을 모두 외부(즉, 리더 안테나)에 의존하는 반면, 능동형 태그는 자체 배터리를 내장하고 있고, 반 수동형 태그는 외부 전원과 자체 내장 배터리를 모두 사용한다.

RF의 주파수에 따라 분류하면 접근제어, 동물 관리 등에 사용되는 124~134kHz의 LF(Low Freqeuncy)태그, IC 카드, 신분증 등에 사용되는 13.56MHz의 HF(High Frequency) 태그, 유통 물류 등 컨테이너 식별을 위해 사용되는 400~915MHz의 UHF(Ultra HF) 태그, 그리고 히타치의 뮤칩에서 사용되는 2.45GHz의 마이크로웨이브 태그로 구분할 수 있다 (참고로, 유럽지역에서는 텔레매틱스를 위하여 5.8GHz가 사용되고 있다).

태그의 기능에 따라 RFID 태그를 분류하면 식별태그(identity tag)와 기능 태그(functional tag)로 구분될 수 있다. 식별 태그는 가장 기본적인 형태의 태그로 변경될 수 없는 EPC 코드와 데이터 통신에서 발생할 수 있는 오류를 수정하기 위한 RC(Cyclic Redundancy Checking) 정보만을 갖는 반면, 기능 태그는 식별 태그의 기본적인 정보 외에 임의의 사용자 정보를 저장할 수 있는 기능을 갖는다. 이에 대한 EPCglobal의 표준은 다음과 같다[2]-[4].

• Generation 1 Class 0(C0g1 또는 C0v1): Read-Only(R/O) 
• Generation 1 Class 1(C1g1): Write Once, Read Many(WORM) 
• Generation 1 Class 2(C2g1): Write Many, Read Many(WMRM)

RFID 태그에 저장된 정보를 읽거나 새로운 정보를 기록하기 위하여 RFID 리더(또는 트랜스폰더)가 사용되며, 각각의 태그의 종류에 따라 서로 통신 프로토콜(air protocol)이 다르기 때문에 하나의 리더로 서로 다른 종류의 태그를 인식할 수 없다.

이와 같은 문제를 해결하기 위하여 EPCglobal에서는 RFID 태그에 대한 Generation 2 표준을 정의 하고 있으며, 2003년 10월 23일 현재 860MHz~960MHz에 해당하는 UHF 클래스에 대하여 공통통신 프로토콜을 사용하는 Class 1(C1g2) 표준화 작업이 “Last Call Working Draft” 상태에 있으며, 2004년 9월까지 완료하여 ISO에 제안할 예정이다.

EPC 정보 서버

EPC Network에서 상품의 제조업자(manufacturer)에 의해 유지되는 EPC 정보 서버(EPC Information Server: EIS)는 생산된 모든 제품에 대한 정보를 제공한다. EPC 정보 서버가 제공하는 데이터는 EPC 코드 데이터, 제조일, 유효기간 같은 인스턴스 데이터, 제품에 대한 카탈로그 정보와 같은 객체 수준의 데이터를 포함한다. 이와 같은 정보를 표현하기 위하여 ML(eXtensible Markup Language)를 기반으로 하는 PML 버전 1.0을 2003년 9월 15일에 발표하였다[5]. 이 규격에는 PML 코어의 범위 및 PML과의 관련성에 대하여 규정하고 있으며, PML 코어의 요구사항과 W3C의 XSD(XML Schema Definition)를 이용한 스키마 구조 및 엘리먼트(element)에 대하여 정의하고 있다.

ONS

웹 상에서 컴퓨터의 위치를 지정해주는 DNS(Domain Name Service)와 유사하게 ONS 는 RFID태그에 저장되어 있는 EPC에 해당되는 제품의 정보 위치를 제공하기 위한 프레임워크이다[6].
ONS는 DNS 프레임워크 위에서 동작하며, EPC와 연관된 EPC 도메인 이름을 찾아내는 Pre Resolver, EPC 도메인 이름으로 EPC와 연관된 PML 서버들을 구하는 Resolver, PML 서버와 연관된 IP주소와 EPC 도메인 이름 사이의 정보를 매핑하는 DNS 서버, ONS 명세 파일(specification file)을 사용하여 DNS 에 사용되는 바인딩 구성 파일을 생성하는 Server Configuration Tool, ONS가 갱신되었을 때 ONS 명세 파일을 갱신하는 Specification Management Tool, 데이터베이스의 정보를 매핑하여 저장하고 하나 이상의 ONS에 대한 명세 파일을 제공하는 Content Server로 구성되며 (그림 3) 과 같다.

SAVANT

RFID 리더에서 계속적으로 발생하는 EPC 데이터를 기반으로 하는 EPC 이벤트를 처리하고 관리하기 위한 소프트웨어로, EPC 데이터를 캡처하고, 캡처한 데이터를 모니터링 하며, 데이터 전송(transmission)을 담당하는 일종의 라우터 역할을 수행하는 미들웨어이다.

SAVANT의 구조는 (그림 5)과 같이 수집된 데이터를 용도에 맞게 분류하고 해당된 일을 처리하는 곳에 배치하는 역할을 수행하는 이벤트 관리 시스템(Event Management System: EMS), 다중 스냅샷을 유지할 수 있는 실시간 메모리 데이터 구조 (real-time in-memory data structure: RIED), 그리고 기존의 시스템과 연동하여 실제 처리를 수행하는 태스크 관리 시스템(Task Management System: TMS)로 구성되며, 리더 또는 센서와의 통신을 위한 인터페이스, 외부 응용과의 통신을 위한 인터페이스, ONS 또는 EPC IS와의 통신을 위한 인터페이스를 제공하고 있다[7].(현재 SAVANT 규격에는 리더와의 인터페이스와 외부 응용과의 통신을 위한 인터페이스만 정의되어 있다.)

RFID 기반 미들웨어

RFID를 기반으로 하는 유비쿼터스 컴퓨팅 환경에서 응용 서비스 시스템은 고유 정보를 저장하고 있는 RFID 태그, RFID 태그에 저장되어 있는 정보를 판독 및 해독하는 RFID 리더와 안테나, 호스트 컴퓨터와 ERP(Enterprise Resource Planning), SCM(Supply Chain Management)와 같은 응용 서비스 애플리케이션으로 구성된다.

RFID가 다양한 응용 서비스에서 사용되기 위해서는 RFID 장치에 저장되어 있는 데이터를 적절한 장소와 적절한 시간에 응용 서비스로 전달하는 RFID 기반 미들웨어가 요구된다.

RFID 기반 미들웨어가 정확한 데이터를 전달한다는 것은 RFID 장치로부터 수집된 정보 중 응용 서비스가 관심 있는 데이터만을 필터링하여 전달하는 것을 의미한다. 데이터 필터링 기능은 데이터의 형식 및 응용 환경에 따라 요구되는 기능이 달라진다. 단순한 EPC 코드를 활용하는 응용에서 필요한 정보를 얻는 방법과 훨씬 더 복잡한 구조를 갖는 데이터를 이용하 는 응용에서 정보를 필터링하는 방법은 다르다. 또한 처리되어야 할 데이터의 양, 동시에 처리되는 필터링 조건의 수 등을 고려하여 데이터 처리 방법을 채택하여야만 데이터의 손실없이 실시간 처리가 가능하다.

최근에 RFID 기반 미들웨어 제품 및 솔루션들이 많이 개발되고 있으나 주로 EPC 코드 등과 같은 간단한 형식의 데이터를 처리하며, 대량의 데이터 처리에 대한 고려가 미진한 상태로 나와 있는 대표적인 시스템은 다음과 같다.

SUN Savant[8]

EPCglobal의 EPC Network Architecture의 구성 요소인 SAVANT 규격을 기반으로 구현한 선 마이크로시스템사의 Java 플랫폼 기반의 RFID 이벤트 관리기(event manager) 는 여러 개의 리더들로 부터 들어오는 RFID 태그 혹은 센서 데이터 스트림을 처리하는 시스템으로 reader adapter, filter, logger, enterprise gateway로 구성된다. RFID 이벤트 관리기는 RFID 리더와 EPC 네트워크에 연결된 다른 네트워크 장치나 센서들과의 인터페이스와 시스템간에 실시간 데이터를 주고 받을 수 있는 인터페이스를 정의하여 제공함으로써 RFID 데이터와 EPC 정보 서버와의 통합과 라우팅 기능을 제공한다. 또한 서버나 네트워크 장치에 이상이 발생시 이를 수용할 수 있도록 연방 서비스 구조를 지원한다.

TagsWare

자바로 개발된 CapTech사의 TagsWare[9]는 리더를 제어하고, 수집된 데이터를 해석하고, 엔터프라이즈 시스템을 통합하고 패키지된 환경을 확장할 수 있게 하기 위해, 많은 다른 제조사의 RFID 장치를 쉽게 통합할 수 있도록 인터페이스를 추상화하여 제공하며, 응용과의 통합을 위하여 다양한 표준인터페이스를 제공한다. TagsWare는 RFID 리더로 부터 수집된 잡음이 많은 원시 데이터를 엔터프라이즈 시스템에서 사용할 수 있는 추상화된 정보로 변환하기 위해 link라는 컴포넌트를 체인으로 연결된 구조를 통해 정제된 데이터를 제공한다.

RFTagAware

Solaris, Linux, Windows 등 다양한 플랫폼을 지원하는 ConnecTerra사의 RFTagAware[10]는 전사적 응용과의 간편한 통합을 위하여 다양한 형태의 이벤트를 정의할 수 있고, RFID 리더기와 상호작용하여 이를 수행하며, 데이터의 필터링, 카운팅, 그루핑 등을 지원한다. RFTagAware는 데이터를 단순히 전달하는 기능뿐 아니라 안정적인 수행을 위하여 RFID 리더와 서버를 원격 관리하고 모니터링하는 기능을 포함하고 있다.

iMotion

마이크로소프트의 .NET 플랫폼에서 동작하는 GlobeRanger사의 iMotion[11]은 이동 환경에서의 서비스를 지원하기 위한 것으로 RFID 리더에서 읽은 데이터를 처리하여 비즈니스 이벤트로 변환하고, 특정 이벤트에 대한 실시간 알림(alerts) 기능을 제공하고 있다. 또한 비즈니스 로직 구성 및 관리를 용이하게 하기 위한 visual workflow editor와 RFID 리더기, 안테나, 태그의 작동을 에뮬레이터 할 수 있는 visual reader emulator와 같은 도구를 제공한다.

URIS

국내의 ㈜앨릭슨사는 EPC Network Architecture의 구성 요소인 SAVANT 규격을 따르는 RFID 미들웨어인 URIS[12]를 개발하였으며, URIS는 각 제품들의 정보를 읽은 RFID 리더들로부터 실시간 데이터를 수집하는 RFID 멀티 어댑터, RFID 리더로부터 읽은 실시간 데이터들의 필터링과 EPC Network Architecture를 통해 제품의 추적이 가능한 Savant, 그리고 ERP, CRM(Customer Relationship Management), WMS(Warehouse Management System) 등 주요 기업들이 사용하고 있는 기업용 응용과 RFID 시스템을 연동해주는 RFID enterprise middleware로 구성된다.

기타

GenuOne과 Acsis사는 기존의 바코드 미들웨어에 RFID를 지원하기 위한 기능을 추가하였고[13], MIT auto-ID 센터의 초기 참여 기업인 OATSystem사는 장치를 관리 및 모니터링하고 데이터 필터링 기능을 가지고 있는 Senseware를 개발하였다[14],[15].

SAP사는 Java 기반의 솔루션 패키지로 SAP event management와 SAP event portal로 구성되는 SAP auto-ID infrastructure를 제공하고 있으며, RFID 데이터와의 통신뿐 아니라 트래킹 및 추적(tracing) 기능을 가지고 있다[16].

데이터 스트림 처리 프로젝트

RFID를 기반으로 유비쿼터스 환경의 응용 서비스를 지원하는 미들웨어는 지속적으로 끊임없이 입력되는 데이터를 정확하게 실시간으로 처리하고 응용 서비스에서 요구하는 결과를 획득해서 전달하여야 한다. 이와 같은 지속적으로 입력되는 대량의 데이터 스트림을 처리하기 위해 요구되는 사항은 다음과 같이 요약될 수 있다[17].

• 순서(order) 와 시간(time)을 기반으로 하는 데이터 모델과 질의가 허용되어야 한다. 
• 질의의 결과로 근사값을 허용하여야 한다. 
• 질의에 대한 결과를 얻기 위하여 입력되는 모든 데이터 스트림을 대상으로 하는 블로킹(blocking) 연산을 사용하지 않아야 한다. 
• 성능 및 데이터 저장소에 대한 제약으로 인하여 데이터 스트림에 대한 백트래킹(backtracking)은 적절하지 않다. 
• 실시간으로 데이터 스트림을 모니터하는 응용에서 비정상적인 데이터에 대하여 빠르게 대응하여야 한다. 
• 확장성을 위하여 많은 질의를 공유하여 실행할 수 있어야 한다.

이와 같은 요구사항을 만족하기 위하여 기존의 전형적인 데이터베이스 관리 시스템(Database Management System: DBMS)을 이용하여 데이터 스트림을 일반 테이블에 대한 삽입으로 처리하고, 연속 질의는 트리거(trigger) 또는 객체화된 뷰(materialized view)로 처리할 수 있으나, 다음과 같은 문제점을 갖는다.

• 삽입 연산 부하가 크다. 
• 트리거로 표현할 수 있는 조건이 제한적이며, 뷰에는 시퀀스를 표현할 수 없다. 
• 근사치와 자원 할당을 표현할 수 없다. 
• 지원하는 트리거의 수가 한계가 있다. 
• 뷰는 스트림 결과를 제공하지 못한다.

이와 같은 문제점을 해결하고 위에서 언급한 데이터 스트림을 처리하기 위해 요구되는 사항을 만족하기 위하여 (그림 6)과 같은 데이터 스트림 관리 시스템(Data Stream Management System: DSMS)을 개발하기 위한 연구가 진행되고 있다.

이와 같은 DSMS를 구현하기 위한 개략적인 구조는 (그림 7)과 같다[17].

이와 같은 데이터 스트림을 효율적으로 처리하기 위한 다양한 프로젝트가 진행되고 있으며, 그중 대표적인 프로젝트의 개발 목표 및 기능은 다음과 같다.

AURORA 프로젝트

데이터 스트림을 활용하는 애플리케이션들의 요구사항을 효과적으로 충족시키고 애플리케이션들에 제공되는 전반적인 서비스의 질을 극대화하기 위한 기반 인프라를 구축하는 것을 목표로 하고 있는 AURORA 프로젝트[18]는 미국의 Brown 대학, Brandeis 대학, MIT 대학이 공동으로 수행중인 데이터 스트림 관리 시스템(DSMS)을 개발하기 위한 프로젝트이다.

이와 같은 목표를 위하여 데이터 스트림에 대한 실시간 처리, 변화하는 데이터 전송 속도에 따른 메모리 연산 스케줄링 등에 필요한 데이터 스트림 관리 시스템 구조를 개발하고, 로드 밸런싱, 데이터 스트림 관리 시스템 모델 구조, 실시간 질의 처리 모델등을 연구하고 있다. 또한 분산 환경에서 분산 스트림 처리 애플리케이션들에게 높은 확장성과 가용성을 제공하기 위하여 경량화된 비집중화 기술과 부하의 분산 처리, 고장 검출 및 회복 등을 포함한 동적인 연속 내성(introspection)과 최적화를 위한 프로토콜을 개발하고 있다.

AURORA 프로젝트는 데이터 스트림을 처리하기 위해 입력되는 스트림에 대한 한정된 영역에 대해 동작할 수 있는 윈도 기반의 연산자들을 포함하는 Filter, Map, Union, BSort, Aggregate, Join, Resample과 같은 새로운 연산자 집합을 제공하고 있으며, QoS를 위하여 시스템에서 요구되는 시스템의 동작에 대한 명세뿐 아니라 스케줄링과 부하 분산 등의 정책에 대한 QoS 명세를 정의하여 동적인 자원 할당을 가능하게 함으로써 사용자의 실시간 요구 사항을 만족시킨다.

STREAM 프로젝트

STREAM(STanford stREam datA Manager)[19]은 연속적이고 무제한으로 생성되는 데이터 스트림을 효과적으로 처리하고, 연속적으로 입력되는 데이터 스트림과 저장되어 있는 데이터 집합에 대한 연속 질의(Continuous Query: CQ)를 지원하기 위하여 스탠포드 대학에서 수행되고 있다.
이를 위하여 STREAM 프로젝트는 데이터 스트림에 대한 연속 질의를 정의할 수 있도록 표준 SQL을 확장하였으며, QoS를 제공하기 위하여 질의 계획에 대한 모니터링과 재-최적화를 통해 융통성있는 질의 계획과 실행 전략을 수립한다. 또한 제약 조건 탐색, 연산자 스케줄링 등을 통한 한정된 자원 소모를 최소화하고 있으며, 부하 감소(load shedding)를 이용한 근사값 계산을 허용하고 있다.

연속 질의를 위한 질의어로 STREAM은 SQL과 유사한 질의 언어인 CQL(Continuous Query Language)를 사용하며, CQL은 데이터 스트림과 윈도를 타임스탬프로 정렬된 테이블로 간주하고 있으며, (그림 8)과 같이 질의에 대한 결과 테이블을 데이터 스트림으로 전달하기 위한 Istream, Dstream, Rstream과 같은 변환 연산자를 제공한다.

NiagaraCQ 프로젝트

NiagaraCQ 프로젝트[20]는 미국 위스콘신 매디슨 대학에서 1999년부터 2002년까지 인터넷 환경에서 연속 질의를 처리하기 위한 고확장성의 시스템을 개발하기 위한 프로젝트이다.

NiagaraCQ 는 기존에 개발한 분산 XML 데이터 검색 엔진인 Niagara에 연속 질의 기능을 확장한 것으로, 분산 환경에서 XML 데이터 스트림에 대한 XML 질의 언어인 XML-QL을 이용한 연속 질의를 지원하며, 고확장성을 위하여 유사한 구조를 갖는 연속 질의를 그룹화함으로써 공통적으로 필요한 연산을 한 번만 수행함으로써 전체적인 질의 처리 성능을 향상시키고 CPU 및 메모리 자원의 사용을 최소화함으로써 단위시간 내에 보다 많은 질의 처리를 가능하도록 한다.

TelegraphCQ 프로젝트

연속 질의를 사용하여 매우 유동적이고 대용량의 데이터 스트림으로부터 원하는 정보를 얻을 수 있도록 하기 위하여 미국 버클리 대학에서 Adaptive Dataflow 구조 개발을 목표로 수행되고 있는 프로젝트로 자바 기반으로 개발된 Telegraph를 데이터 스트림에 대한 연속 질의를 지원하기 위하여 PostgreSQL을 기반으로 새롭게 진행되고 있다.

연속적인 데이터 스트림에 대한 질의 처리를 위하여 입력되는 데이터 스트림에 대한 라우팅과 연산자에 대한 스케줄링을 제공하며, 또한 연산자간의 통신을 제공하고 있다. 또한 질의 처리 비용을 최소화하기 위하여 자원의 공유를 제공하고 있다.

데이터 스트림에 대한 질의를 위하여 TelegraphCQ[21]에서 제공하는 질의 언어인 StreaQuel은 모든 입력과 출력을 스트리밍으로 간주함으로써 스트림과 테이블간의 변환이 필요하지 않다. 또한 윈도 연산을 위하여 WindowIS 연산자를 제공한다.

OpenCQ 프로젝트

인터넷 상의 분산되어 존재하는 이질 정보들의 변화를 효율적으로 모니터링 하기 위해 미국 Georgia Tech에서 1996년부터 진행되고 있는 프로젝트로 인터넷이나 인트라넷에 존재하는 대용량의 분산정보 시스템에서의 정보 변화를 모니터링하기 위하여, 분산되어 있는 서로 다른 시스템들을 동등한 수준으로 접근할 수 있도록 조율함으로써 데이터 전송의 품질 보장과 안정성 그리고 최신 정보를 제공할 수 있는 지능적이며 적응성 있는 구조를 설계하고 분산되어 존재하는 대용량의 정보에서 어떤 특정 정보가 변경되는 것을 변경 시점과 최대한 가까운 시간내에 감지하기 위한 방법과 기술을 개발하고 있다.

OpenCQ[22]는 인터넷상에서 변화된 내용을 감지하여 가져온 후, 그 내용을 사용자에게 전달해주는 시스템으로, 개인별로 알고 싶은 변경사항을 연속 질의로 시스템에 등록하면 시스템이 변경 사항을 모니터링 하여 변경된 내용을 사용자에게 알려준다.

OpenCQ는 입력, 수정, 삭제와 같은 일반적인 변화를 모니터링 함으로써 질의의 대상이 되는 모든 데이터 소스를 검색할 필요 없이 변화된 내용을 반영한 결과를 효율적으로 생산해낼 수 있다.

COUGAR 프로젝트

코넬 대학에서 연구되고 있는 센서 네트워크용 분산 데이터 처리 시스템인 COUGAR[23]는 네트워크의 변화에 동적으로 적응할 수 있고, 유연성(flexibility)과 확장성(scalability) 이 높으며, 고장 감내성(fault tolerant) 을 갖는 데이터 스트림 처리 시스템을 개발하는 것을 목표로 수행되는 프로젝트로, 객체 기반으로 데이터의 수집 및 처리를 중앙에서 처리하는 많은 다른 프로젝트와 달리 데이터 접근과 처리를 모두 분산된 형태로 처리한다.

COUGAR 시스템에서 데이터 스트림은 추상화 자료 구조(Abstract Data Type: ADT)로 표현되며, 모든 데이터 스트림의 소스는 ADT로 모델링 된다. 질의 처리를 위하여 연속 질의의 실행 주기를 표현하기 위한 $every() 절을 포함하는 SQL과 유사 한 질의 언어를 제공한다.
이외의 데이터 스트림 처리 관련 프로젝트로는 버지니아 대학의 DSWare, UCLA의 SensorWare, 프린스턴 대학의 Impala, UC 버클리의 Mate 등이 있다.

결 론

유비쿼터스 컴퓨팅 환경을 구축하기 위하여 차세대 핵심 기술인 RFID 기술을 기반으로 하는 스마트 객체를 활용하는 다양한 응용 서비스를 조기에 구축하기 위해서는 스마트 객체와 응용 서비스를 이음새 없이 연결하는 미들웨어가 요구된다. 즉, 유비쿼터스 컴퓨팅 환경에서 스마트 객체를 활용하는 응용 서비스를 개발하기 위해 요구되는 공통적인 작업은 미들웨어가 처리하도록 하고, 응용 서비스 개발자는 개발하고자 하는 응용 서비스의 본래의 기능만을 고려함으로써 보다 양질의 제품을 조기에 개발할 수 있으며, 새로운 환경으로의 적용을 용이하게 할 수 있다.

본 고에서는 RFID를 기반으로 하는 스마트 객체를 활용하는 유비쿼터스 컴퓨팅 환경을 구축하기 위한 기술들을 표준화하고 상용화하기 위하여 EPCglobal에서 정의한 EPC Network Architecture와 각각의 구성 요소에 대하여 논하고, 유비쿼터스 컴퓨팅 환경의 응용 서비스를 용이하게 구축할 수 있도록 개발된 미들웨어 제품 및 솔루션들의 기능을 살펴봄으로써 현재 미들웨어 기술의 방향에 대하여 살펴보았다. 또한 미들웨어를 구현하기 위하여 지속적으로 끊임없이 생성되는 데이터를 처리하기 위하여 진행되고 있는 데이터 스트림 처리 프로젝트들의 연구동향을 살펴 봄으로써, RFID 기반의 유비쿼터스 컴 퓨터 환경의 응용 서비스를 구축하기 위한 기반 시스템인 미들웨어 기술 개발에 따른 전략 및 정책 방향을 제시하고자 하였다.

원종호 | 데이터베이스연구팀 선임연구원
이미영 | 데이터베이스연구팀 책임연구원, 팀장
김명준 | 인터넷서버그룹 책임연구원, 그룹장

출처 : DB포탈사이트 DBguide.net

원문 : DB포탈사이트 DBguide.net

지금까지 Part 1, 2, 3, 4를 통해  IPv6 관련 설정을 확인(show), 추가(add), 삭제(delete), 설정(set)하는 방법을 알아 보았습니다. Part 5에서는 IPv6 인터페이스 정보를 설정하기 위한 set interface 명령에 대해 알아보겠습니다.

** 본 문서는 Windows XP SP1에 고급네트워킹팩을 설치한 환경을 기준으로 설명하겠습니다.

1. set interface 명령의 주요 옵션

set interface 명령은 시스템에 구성된 물리적, 논리적 IPv6 인터페이스의 정보를 변경하는 명령으로 netsh interface ipv6 set interface 명령을 실행하면 [그림1]처럼 다양한 옵션이 표시됩니다.

oforwarding:: 패킷 포워딩의 가능 여부를 설정
   - 패킷 포워딩 : 해당 인터페이스에 도착한 패킷을 다른 인터페이스로 전달하는 것

oadvertise:: RA(Router Advertisement)가 해당 인터페이스로 보내져야 하는지 여부

o mtu :: 인터페이스의 mtu를 설정

o siteid :: Site scope zone identifier를 설정

o metric :: 인터페이스의 매트릭(일종의 우선 순위)를 지정

o firewall :: firewall 모드로 동작여부를 설정

o siteprefixlength :: global prefix의 길이를 수정

o store :: 설정내용이 계속 지속될지(persistent), 다음 부팅전 까지만 지속되는지 결정
 

 

2. set interface forwarding 옵션

forwarding(패킷 포워딩) 옵션은 PC를 이용하여 라우터를 구성하거나 6to4 릴레이 등을 구성할 때 해당 인터페이스로 도달한 데이터를 내부의 타 인터페이스나 타 단말(보통 라우터)로 보내고자 할 때 이용합니다.

forwarding 옵션이 활성화(enable)되면, 추가적인 라우팅 명령을 이용하여 PC를 IPv6 라우터로 이용할 수 있습니다.

패킷 포워딩 활성화 ::set interface [인터페이스 이름]forwarding=enabled

예) netsh interface ipv6 set interface wire forwarding=enabled
 

패킷 포워딩 비활성화 ::set interface [인터페이스 이름]forwarding=disabled

예) netsh interface ipv6 set interface wire forwarding=diabled

패킷 포워딩 여부를 확인하려면netsh interface ipv6 show interface [인터페이스 이름]을 입력합니다. 아래 그림에서Forwards Packets이 Yes로 설정된 것으로 알 수 있습니다.

3. set interface advertise 옵션

advertise 옵션은 라우터에서 배포하는 RA(Router Advertisement) 정보를 해당 인터페이스로 보낼지 선택합니다. RA를 수신하게 되면 자동으로 IPv6 주소를 생성하게 되고, RA를 수신하지 않으면 IPv6 주소를 자동으로 생성하지 않습니다.

테스트 등의 목적으로 IPv6 자동 생성 기능을 이용하지 않을 때 유용합니다.

RA 정보를 받아야 할 때(자동 주소 생성이 필요할 때)

setinterface [인터페이스 이름] advertise=diabled

예) netsh interface ipv6 set interface wire advertise=disabled
 

RA 정보를 받지 않아야 할 때(자동 주소 생성이 필요 없을 때)

set interface [인터페이스 이름] advertise=enabled

예) netsh interface ipv6 set interface wire advertise=enabled
 

4. set interface mtu 옵션

인터페이스의 MTU(Maximum Transmission Unit, 최대 전송 단위)를 수정합니다.

netsh interface ipv6 set interface [인터페이스 이름] mtu=정수

예)netsh interface ipv6 set interface wire mtu=1500
 

5. set interface  metric 옵션

인터페이스의 metric(우선순위)을 수정합니다.

netsh interface ipv6 set interface [인터페이스 이름] metric=정수

예) netsh interface ipv6 set interface wire metric=10

이상으로 set interface 명령에 대해 간단하게 알아보았습니다.

IPv6 Ready Logo Program

IPv6 Ready Logo Program 이란

IPv6 Ready Logo Program은 IPv6 포럼이 v6 Logo Committee를 구성하여, IPv6 장비의 신뢰성 확보 및 기술보급을 위해 2003년 9월부터 시행 중인인증제도이다.

즉 검증된 IPv6 제품에 대해 IPv6 Ready 로고를 발급하는 것으로, 2003년 9월부터 시행된 Phase I과 2004년 중에 실시 예정인 Phase II로 구분된다.

Phase I은 IPv6 기술의 보급 측면에서 IPv6 코어 프로토콜에 대해서만 인증을 수행하고, Phase II는 IPv6 프로토콜과 관련된 보다 다양한 인증 규격을 갖출 전망이다.

IPv6 Logo Program 인증 대상 분류

Ready Logo Phase I의 시험 대상은 크게 라우터와 호스트로 분류되며, 아래와 같이 상세하게 나뉜다.

(1) Host
(2) Router
(3) Operating System : 예) 리눅스
(4) Protocol Stack
(5) Special Devices : 예) 임베디드 시스템, 특정 목적 서버, 변환기 등

IPv6 Ready Logo 시험 범위 및 인증기준

Ready Logo Program에서는 적합성 시험과 상호 운영성 시험을 수행한다.

적합성 시험이란 표준에 명시된 특정기능에 대해 장비의 올바른 구현여부를 시험하는 것으로, 시험 대상 장비와 관련하여 약 200여 개의 시험 항목을 준비해 놓고 있으며, 시험 통과를 위한 기준은 모든 시험 항목에 100% 통과를 해야 한다.

이를 시험하기 위한 시험용 소프트웨어는 Self Testing Tool이라 하며,IPv6 Ready Logo 홈페이지에서 무상으로 구할 수 있다.

상호 운영성 시험은 시험 규격에서 정하는 해당 기능에 대해 서로 다른 장비가 표준에 따라 상호 연동가능한지를 판단하는 시험으로, 자신의 장비가 무엇이든지 관계없이, 상호 연동이 가능한 장비를 최소한 4개 이상 확보하여야 한다. 또한 장비의 종류에 따라 2종 이상의 라우터 및 2종 이상의 호스트를 필수적으로 포함하여야 한다.

IPv6 Ready Logo 인증 획득 리스트

2004년 10월말 기준으로 약 130개의 제품이 IPv6 Ready Logo를 획득했으며 이중 국내 제품 리스트는 아래와 같다.

  o 아이비트 - Forsix-100R - Host Box(IPv6/IPv4 translator based on RTOS) - 2003.11.21
  o 삼성전자 - SAMSUNG IPv6 Stack - IPv6 Stack over VxWorks OS - 2003.11.21
  o ETRI - ETRI NGAR - IPv6 백본 라우터 - 2003.12.22
  o 삼성전자 - SAMSUNG IPv6CH - IPv6 Stack for Cellular Host - 2004.01.06
  o 아이비트 - iBIT TCP/IPv6 Protocol Stack - IPv6 Stack over iBITv6 OS v1.0.0 - 2004.03.01
  o ETRI - ETRI HR - IPv6 홈 라우터 - 2004.6.28
  o 삼성전자 - SR2000 - IPv6/IPv4 Dual Stack Access Router - 2004.8.4
  o 애드팍 - AP900s - Operating System for AddPac Routers and Support VPN - 2004.9.6
  o 애드팍 - AP2830 - Operating System for AddPac Routers - 2004.9.6
  o 애드팍 - AP2850 - Operating System for AddPac Routers - 2004.9.6
  o 애드팍 - AP4820 - Operating System for AddPac Routers - 2004.9.6
  o 애드팍 - AP5840 - Operating System for AddPac Routers - 2004.9.6
  o 애드팍 - AP5850 - Operating System for AddPac Routers - 2004.9.6

「RFID로 데이터센터 관리 쉽게 한다」

RFID기술의 잠재적인 노동 절감효과는 지금까지 일반 기업 경영진 및 관리자의 기대를 집중적으로 받아왔지만 앞으로는 IT 분야 종사자의 관심도 끌게 될 것으로 보인다.

HP는 RFID 시스템을 이용, 데이터센터 관리를 용이하게 해주는 '스마트 랙(smart rack)' 기술을 개발중이다. 2년 안에 시장에 출시될 예정인 스마트 랙은 데이터센터 내부의 서버들에 대한 즉석 점검이 가능해 관리자가 과열과 같은 문제를 조기에 발견할 수 있도록 해준다.

HP 연구진은 지난주 RFID 데모 센터를 통해 스마트 랙 프로토타입을 언론에 공개, 시연했다.

스마트 랙의 각 선반에는 RFID 판독기가 장착돼 있다. 각 서버에는 해당 서버의 고유 ID를 저장한 칩이 내장돼 있으며, 여기서 송신하는 고주파 신호를 판독기가 읽게 된다.

데이터센터 관리자는 현재 상황에 대한 정보를 요청하는 즉시 얻을 수 있기 때문에 각 랙을 일일이 검사해야 하는 노동 부담이 없어진다고 HP 연구소 기술 책임자 살릴 프라드한은 설명했다.

스마트 랙을 이용하면 각 서버의 관리 기록을 통해 서비스 및 유지보수 절차 효율성을 높일 수 있으며 중요한 정보를 저장한 하드디스크의 분실에 대한 우려도 줄일 수 있다. 현재 HP는 온도감지 RFID 칩을 이용, 과열 문제를 신속히 탐지해 이에 따른 장애를 막는 시스템을 개발하고 있다.

프라드한은 "수천 대 규모의 서버를 운영하고 있는 대형 데이터센터에 적합한 기술"이라고 말했다.

지금까지 RFID 기술은 주로 가축류 추적, ID 출입 시스템, 고속 통행료 지불 등의 분야에 사용돼 왔다. 하지만 칩 가격이 하락하고 새로운 표준이 부상하면서 새로운 용도가 개척되고 있다.

소매 업계에서는 월마트를 선두로 상품현황 파악에 RFID를 도입하고 있으며 미국 정부는 여권 바이오메트릭 데이터 저장, 군수공급 조직화에 이 기술 적용을 추진하고 있다.

RFID 기술의 가능성과 이에 대한 투자가 급증하면서 HP, IBM, 썬 등 대형 IT 업체들도 발빠르게 대응하고 있다. HP는 지난 5월부터 기업 공장 및 창고의 RFID 시스템 도입 지원을 중심으로 하는 RFID 서비스 전략을 추진하고 있다. @

Alorie Gilbert (ZDNet Korea)

2004/11/01
원문보기

원문 :http://www.zdnet.co.kr/news/enterprise/0,39024412,39131254,00.htm

Hosts 파일을 이용한 IPv6 호스트네임 구성 방법

IPv6 주소체계는 주소의 길이가 길고(128bit) 16진수 표시 체계인 관계로 주소를 입력하거나 암기할 때 어려운 점이 많습니다. 특히, Internet Explorer에서 웹사이트를 접속할 때 IPv6 주소를 바로 입력하는 방식(예: http://[2001:2b8:2:fff3::100])을 지원하지 않고 반드시http://www.6dns.org와 같이 FQDN(Fully Qualified Domain Name)을 이용해야 합니다.

이러한 특성으로 인하여, IPv6를 테스트중 IPv6 서비스를 원할하게 이용하기 위해서는 DNS 서버를 설치하여 운영하는 것이 일반적입니다.

하지만, IPv6 DNS 서버의 운영과 관리에도 노력이 들어가고, 간단하게 임시로 DNS 서버 환경이 필요할 때 OS 자체에서 제공하는 hosts 파일을 이용하여 DNS 서버 대용으로 이용할 수 있습니다.

본 문서에서는 hosts 파일을 이용하여 로컬 환경에서 IPv6 주소와 호스트네임을 맵핑 시키는 방법을 알아보겠습니다.

1. hosts 파일의 역할 및 위치

hosts 파일은 IP 주소와 호스트네임을 1:1로 맵핑을 시켜주는 역할을 합니다.

예를 들어 100.1.1.1 IPv4 주소를 가진 서버가 있고, 임시로 이 서버의 이름을 test.vsix.net 으로 하기 위해서는 hosts 파일에 아래와 같은 내용을 추가하면 해당 시스템 내에서 test.vsix.net에 100.1.1.1 IPv4 주소가 맵핑되게 됩니다.

예) 100.1.1.1                  test.vsix.net

hosts 파일은c:\windows\system32\drivers\etc폴더에 있으며, 초기치는 아래와 같습니다.

2. hosts 파일에서 IPv6 주소와 호스트네임 맵핑

hosts 파일에서 IPv6 주소와 호스트네임을 맵핑 시키는 방법은 IPv4 주소를 호스트네임에 맵핑 시키는 방법과 동일 합니다.

예를 들어 2001:2b8:2:fff3::100 이라는 IPv6 주소와 imsi.imsi.com 이라는 호스트네임을 맵핑을 하려면 host 파일 마지막에 아래와 같이 추가하면 됩니다.

[ IPv6 주소와 호스트네임 맵핑 예 ]

3. 적용 결과 테스트

이제 imsi.imsi.com 이라는 호스트네임에 2001:2b8;2:fff3::100 IPv6 주소가 맵핑되었습니다. ping6 테스트를 이용해 hosts 파일의 수정결과가 정상적으로 적용되는지 확인해 보겠습니다.

4. 응용 사례

이상으로 IPv6 주소와 호스트네임간의 맵핑 방법을 알아 보았습니다.

이 방법을 이용하면 복잡한 IPv6 주소를 간단한 호스트네임으로 1:1 맵핑 시킬 수 있습니다. 그리고 특정 웹사이트 접속시 DNS 서버를 이용하지 않고도 호스트네임을 통해 IPv6 웹사이트에 접속할 수 있습니다.

아래 그림과 같이 imsi.imsi.com 호스트 네임을 통해 2001:2b8:2:fff3::100 IPv6 웹사이트에 접속가능합니다.

NCA 6CAM - IPv6 Enabled Network Camera Part 2

지난 IPv6 Enabled Network Camera Part 1에서는 IPv6 네트워크 카메라의 개념과 한국전산원의 NCA 6CAM에 대해 간단히 알아보았습니다. Part 2에서는 IPv6 네트워크 카메라에 접속하여 원격제어를 해보겠습니다.

1. 한국전산원 IPv6 네트워크 카메라(NCA6 CAM) 원격 접속

현재 IPv6 네트워크 카메라 시제품은 2004년도 KOREAv6 시범사업에 두루 활용되고 있으며, 이미 한국전산원 IPv6 체험관에 설치되어 IPv6 네트워크 환경에서 동작하고 있습니다.

IPv6 체험관에 설치되어 내부를 모니터링 할 수 있는 NCA 6CAM-02에 접속하기 위해서는 웹 브라우저에서http://cam02.6dns.org를 입력합니다. 이미 네트워크 카메라 OS에 IPv6 웹서버(thttpd)가 내장되어 있기 때문에, 전용 클라이언트 뿐만 아니라 웹 브라우저로 접속할 수 있습니다.

** cam02.6dns.org URL은 IPv6 전용 URL이기 때문에 IPv6 사용자만 접속 가능합니다.

위 그림을 보시면 접속한 사용자(client)의 IPv6 주소가 표시됩니다.

2. 사용자 로그인

NCA 6CAM의 접근 권한은 크게 관리자와 방문자(GUEST)로 구분되며 방문자는 카메라 조작만 가능하며 기타 시스템 설정을 할 수 없습니다.

방문자로 로그인하기 위해 GUEST 버튼을 클릭합니다.

방문자(GUEST)로 로그인하면 아래 그림과 같이 네트워크 카메라 조작 인터페이스가 나타납니다.

사용자는 상하좌우(Pan, Tilt, Up, Down) 조작 인터페이스와 Zoom In-Out 인터페이스를 이용하여 IPv6 네트워크 카메라를 원하는 방향으로 움직일 수 있습니다.

3. IPv6 관련 설정 기능

한국전산원 NCA IPv6 6CAM은 IPv6 환경에 적합하도록 개발되었습니다. 기존 IPv4 네트워크 카메라의 주요 기능이외에 IPv6 만을 위한 기능을 살펴보겠습니다.

IPv6 네트워크 카메라의 관리자 페이지로 들어가면(손님은 들어갈 수 없고, 관리자만 들어갈 수 있습니다.) 아래 그림과 같이 각종 카메라 기능 설정 화면이 나타납니다.

위 그림에서 IPv6 네트워크 카메라의 IPv6 주소를 확인할 수 있습니다.

NCA 6CAM은 IPv4 네트워크 환경에서 IPv6 터널 기법을 통해 IPv6 환경을 이용할 수 있도록 구현되었습니다. 아래 그림에서 6to4 IPv6 터널과 관련된 설정을 할 수 있습니다.

NCA 6CAM의 가장 큰 특징은 IPv6 Dynamic DNS를 지원한다는 점입니다.(IPv4 DDNS도 지원) IPv6 DDNS 서비스(http://www.6dns.org)와 연계되어, IPv6 네트워크 카메라에 DDNS 관련 설정을 해두면, 어떤 IPv6 네트워크로 이동을 하더라도 Dynamic DNS Update를 이용하여 IPv6 네트워크 카메라에 쉽게 접속을 할 수 있습니다.

특히, Internet Explorer에서는 주소입력창에 IPv6 주소를 입력하는 방식을 지원하지 않고, 반드시 호스트 네임(도메인 네임)을 입력해야 하기 때문에 DDNS와의 연동이 필요합니다.

예를 들어 사전에 camera.6dns.org라는 DDNS 정보를 등록해두고, 타 IPv6 네트워크로 이동을 하더라고 IPv6 통신만되면, camera.6dns.org라는 도메인의 IPv6 DNS 정보가 새로 이동한 네트워크에서 할당받은 IPv6 주소로 실시간 변경되어, 사용자는 항상 IPv6 네트워크 카메라에 접근할 수 있습니다.

IPv6 DDNS에 대한 정보는http://www.vsix.net/customer/ipv6DDns.jsp문서 참고

4. 전용 클라이언트

지금까지 웹기반 클라이언트에 대해 설명 드렸습니다.

하지만 네트워크 카메라가 증가하고, 동시에 모니터링해야 하는 내용이 많아질 경우 여러 대의 네트워크 카메라를 중앙 집중식으로 관리할 수 있는 전용 클라이언트가 필요합니다.

한국전산원의 NCA 6CAM 역시 이러한 상황을 고려하여 IPv6를 지원하는 전용 윈도 클라이언트를 개발하였습니다.

5. 기타 데모 사이트

웹상에서 이용가능한 IPv6 네트워크 카메라

** 청계천 공사현장(한국전산원 빌딩 앞) ::http://cam01.6dns.org

** 한국전산원 IPv6 체험관 내부 ::http://cam02.6dns.org

** IPv6 체험관 파일럿 램프 ::http://www.kiesv6.or.kr/iMain.jsp?pageID=0204

** IPv6 체험관 화분관리 ::http://www.kiesv6.or.kr/iMain.jsp?pageID=0303

그리고 곧, IPv6 네트워크 카메라를 이용한 생태계 모니터링 서비스가 제공될 예정입니다. 10월 말이되면 네트워크 카메라로 부산의 을숙도 철새도래지를 실시간으로 감상하실 수 있습니다.

터널 브로커(Tunnel Broker)를 이용한 IPv6 접속 방법

일반 IPv4 인터넷 환경에서 IPv6 주소체계를 이용하기 위해 IPv6-in-IPv4 터널링(IPv6 터널링)을 이용합니다. IPv6 포탈에서는 여러 문서를 통해 6to4, ISATAP, Teredo 등의 자동 터널링 이용 방법을 소개했습니다.

본 문서에서는 최근 이용이 증가하고 있는터널 브로커(tunnel broker)를 이용한 IPv6 접속 방법을 알아보겠습니다.

1. 터널 브로커의 개념

일반적으로 IPv6 터널을 구성하는 방법에는 설정 터널(수동터널, configured tunnel)과 자동 터널(automatic tunnel)이 있습니다.

설정 터널은 미리 준비된 IPv6 주소 블록을 이용하여 라우터-라우터, 네트워크-네트워크간 IPv6 터널을 구성하는데 주로 이용되며 관리자가 복잡한 IPv6 터널 설정을 직접 해야 하는 부담이 있으며 IPv4 주소와 관계없이 IPv6 터널을 생성할 수 있습니다.

자동 터널은 일련의 터널 생성 절차를 자동으로 수행하며 단말의 IPv4 주소를 기반으로 단말-라우터, 단말-단말간  IPv6 터널을 형성하는 방법입니다. 이는 복잡한 터널 설정 방법을 몰라도 IPv6 터널 형성을 위한 TEP(Tunnel End Point, 보통 라우터)의 IPv4 주소와 간단한 설정 명령만 알면 IPv6 터널을 형성할 수 있습니다. 여러분이 일반적으로 이용하는 6to4, ISATAP, Teredo 터널링은 모두 자동 터널입니다..

터널 브로커는 일종의 자동 터널링 기법으로 기존 설정 터널(수동 터널)의 단점인 터널 설정 및 관리상의 어려움을 해결할 수 있습니다. 즉 터널 설정을 도와주고 설정된 터널을 관리하기 위한 별도의 터널 브로커 서버를 구성하고 사용자의 터널 생성 요청을 자동으로 처리합니다.

일부 터널 브로커 서비스는 사설 IPv4 환경에서도 IPv6 주소체계를 이용할 수 있는 NAT Traversal을 지원하고, 터널 설정을 위한 프로토콜(TSP: Tunnel Setup Protocol)을 위한 전용 클라이언트를 제공하기도 합니다.

2. 국내외 주요 터널 브로커 서비스

현재 유럽을 중심으로 전세계에 약 10여개의 터널 브로커 서비스가 운영되고 있습니다. 그러나 국내에는 정상적으로 동작하는 터널 브로커 서버가 현재는(2004.9월 기준) 없는 것으로 파악됩니다. 한국전산원 6NGIX 홈페이지에서 터널 브로커 서비스가 제공되었으나 지금은 정상 동작을 하지 않는 것 같습니다. (2004년 12월경에 IPv6 포탈에서 터널 브로커 서비스를 재개할 예정이라고 합니다.)

국내에 터널 브로커 서버가 없는 경우 해외의 터널 브로커 서버를 이용해야 하는데, 이 경우 IPv6 데이터가 해외를 경우하는 문제가 발생합니다.  예를 들어 유럽의 터널 브로커 서비스를 이용하여 IPv6 주소를 할당받고 IPv6 포탈 서비스를 이용할 경우 사용자 PC >> 해외 네트워크 >> 유럽 >> 해외 네트워크 >> IPv6 포탈 서비스(Vsix.Net) 경로를 거치게 됩니다. 만약 국내에 있는 터널링 서비스를 이용할 경우 사용자 PC >> 국내 네트워크 >> IPv6 포탈의 경로를 거치게 되어 네트워크 응답 및 전송 속도가 빠르게 나옵니다.

해외의 주요 터널 브로커 서비스를 알아보면 아래와 같습니다.

o Freenet6 Tunnel Broker Service ::http://www.hexago.com
o AS8758 Tunnel Broker Service ::http://tunnelbroker.as8758.net
o Hurricane Electronic IPv6 Tunnel Broker Service ::http://tunnelbroker.net
o BT Exact Tunnel Broker ::https://tb.ipv6.btexact.com
o MANIS IPv6 Tunnel Broker ::http://tbroker.manis.net.my
o ASCC IPv6 Tunnel Broker ::http://tb.ipv6.ascc.net/cgi-bin/tb.pl
o SingNet IPv6 Tunnel Broker ::http://tunnel-broker.singnet.com.sg
o COREDUMPS.ORG Tunnel Broker ::http://tb.coredumps.org
o NGDC Tunnel Broker ::http://noodle.ngdc.net/~hroi/tb
o XS26 Distributed Tunnel Broker ::http://www.xs26.net
o AARNET IPv6 Migration Broker ::http://broker.aarnet.net.au
** 한국전산원 IPv6 터널 브로커 ::http://www.ngix.ne.kr/menu/main.jsp?menuID=0401

3. Freenet6 터널 브로커 서비스

본 문서에서는 Freenet6 터널 브로커 서비스를 이용하겠습니다.

Freenet6 터널 브로커 서비스를 이용하기 위해서는 크게 두 가지 조건이 필요합니다. 우선 IPv6 스택이 설치되어 있어야 하며, 터널 브로커 서비스에 사용자 등록(가입) 해야 합니다.

터널 브로커 서비스에 가입을 하는 이유는 터널 브로커 서비스는 개인에게 공인 IPv6 주소 또는 IPv6 주소 블록을 할당하는 것이므로, 주소 할당 정보를 관리해야 합니다. 그리고 일정 기간동안 사용이 없으면 할당된 주소를 회수하게 됩니다. 이러한 IPv6 주소의 효율적인 할당 및 회수를 위해 서비스 가입을 요구하고 있습니다.(물론 익명으로도 이용 가능합니다.)

가. Freenet6 서비스 접속

Freenet6 터널 브로커 서비스는 유럽의 Hexago사에서 제공하고 있습니다.
http://www.hexago.com또는http://www.freenet6.com으로 접속합니다.

나. Freenet6 서비스 가입(Step1)

익명으로 Freenet6 서비스를 이용할 수도 있지만, 좀더 특화된 서비스를 위해 사용자 등록을 하겠습니다.

홈페이지 중앙 상단의 "Get IPv6 in 3 steps" 버튼을 클릭하고, 사용자 등록 양식에 필요한 정보를 입력하고 등록을 하면 "User Account Creation Succeeded" 메시지가 나오고, Step 2로 진행합니다.

** 사용자 암호는 서비스 가입시 기입한 E-Mail 주소로 발송이 됩니다.

다. TSP Client 다운로드 및 설치(Step2 and Step3)

Step2에서는 자신의 OS에 적합한 TSP(Tunnel Setup Protocol) Client를 다운로드 받습니다. 아래 그림에서 Windows XP용 Binary Code를 다운로드합니다.

** 본 문서에서는 Windows XP OS를 중심으로 설명합니다.

다운로드 받은 TSP-Client를 실행하면 일련의 설치 절치가 진행됩니다.

계속 "다음" 또는 "OK"를 누르면서 설치를 진행하다가 아래와 같은"하드웨어 설치" 메시지가 나오면 꼭 "계속" 버튼을 선택하여 IPv6 터널 가상 어뎁터를 설치하시기 바랍니다. 이 가상 어뎁터를 설치하지 않으면 Freenet6 서비스를 이용할 수 없습니다.

설치가 모두 완료되었으면, c:\program fils\tsp-client 폴더에 TSP Client가 설치되어 있습니다.

** 보다 자세한 설치 방법은 Windows Installation Guide[다운로드]를 참고 하시기 바랍니다.

라. TSP Client 환경 설정

Freenet6 서비스를 보다 잘 이용하기 위해서는 Step1에서 생성한 사용자 ID와 암호를 TSP Client 설정파일(tspc.conf)에 입력해야 합니다.

TSP Clinet가 설치된 폴더(c:\program fils\tsp-client)에서 tscp.conf 파일을 열어 텍스트에디터로"userid="와"passwd="에 Step1에서 등록한 ID와 암호를 입력합니다.

그리고 익명으로 Freenet6 서비스를 이용하지 않기 때문에 server 항목을 server=broker.freenet6.net 로 변경합니다.

** 만약 별도의 등록과정을 거치지 않고 freenet6 서비스를 사용하려면 TSPC Client를 설치한 후 tspc.conf 파일을 수정하지 않고 바로 tspc.exe를 실행하면 됩니다. 하지만 익명으로 서비스를 이용하면 고정된 IPv6 주소를 받지 못하고 새로 접속을 할 때마다 IPv6 주소가 변경됩니다. 그리고 Userid에 해당되는 도메인 네임을 가질 수 없습니다.

** 만약 사용자 등록을 하고 그에 맞게 tspc.conf 파일을 수정한 뒤 IPv6 터널을 설정하면 항상 일정한 IPv6 주소를 할당 받으며, 자신의id.freenet6.com(예: ahnchul.freenet6.com) 형태의 도메인이 형성됩니다.

라. 터널 브로커를 이용한 터널 생성전 확인 사항

Freenet6 터널 브로커 서버와 IPv6 터널을 형성하기 이전에 타 IPv6 터널과 혼란을 피하기 위해 기존에 설정되어 있는 각종 IPv6 터널(6to4, ISATAP, Teredo)을 비활성화(disable) 하는 것이 좋습니다.

o 6to4 터널 비활성화 : netsh interface ipv6 6to4 set state state=disabled

o ISATAP 터널 비활성화

   - netsh interface ipv6 isatap set state disabled 또는

   - netsh interface ipv6 isatap set router isatap.ngix.ne.kr diabled

o Teredo 비 활성화 : netsh interface ipv6 set teredo disable

명령프롬프트에서 ipconfig 명령을 내려 아래 그림처럼 IPv6 터널이 모두 비활성화되었는지 확인합니다.

라. 공인 IPv4 주소 환경에서 IPv6 터널 형성

공인 IPv6 주소환경에서 IPv6 터널을 형성하기 위해서는 tspc.conf 파일을 수정하고 tspc.exe 파일을 실행하면 곧바로 freenet6로 부터 할당받은 자신의 IPv6 주소를 아래 그림처럼 확인할 수 있습니다.

** 터널이 형성되는 과정을 자세히 확인하시려면 tspc.exe -vvv를 입력합니다.

** 공인 IPv4 환경에서 IPv6 터널을 형성하는 경우 TSP Client 설치과정에서 생성된 "TAP/TUN IPv6 Adapter"는 이용하지 않습니다.

마. 사설 IPv4 주소환경에서 IPv6 터널 형성(NAT traversal)

Freenet6는 사설 IPv4 환경에서 IPv6 터널을 형성해주는 NAT Traversal을 지원합니다.

사설 IPv4 환경에서 IPv6 터널을 형성하기 위해서는 공인 IPv4 환경에서와 동일하게 tspc.exe 파일을 실행하면 바로 freenet6로 부터 할당받은 자신의 IPv6 주소를 확인할 수 있습니다.

실제로 ipconfig 명령을 이용하여 시스템에 생성된 IPv6 주소를 확인해 보면 아래와 같습니다.

단 이 과정에서 "TAP/TUN IPv6 Adapter" 인터페이스가 활성화됩니다.

주의하실 점은 사설 IPv4 환경에서 IPv6 터널을 실행하신 경우에는 tspc.exe가 실행되고 있는 윈도우즈 창을 절대로 닫으시면 안됩니다. 이는 사설 IPv4 환경에서 터널 브로커와 터널 지속을 위한 데이터를 계속 주고 받아야 하기 때문입니다.

아. IPv6 네트워크 테스트 및 IPv6 웹사이트 접속

이제 IPv6 네트워크 테스트 및 IPv6 웹사이트 접속을 해보겠습니다.

IPv6 네트워크 테스트는 한국전산원 IPv6 포탈 서비스와 ping6 테스트를 합니다.

그런데 이미 설명드린 바와 같이 freenet6 터널 브로커가 유럽에 있기 때문에 IPv6 데이터가 유럽을 거쳐서 다시 한국으로 들어오게 됩니다. 이러한 문제점으로 인하여 ping에 대한 응답시간이 거의 500ms를 넘어가고 있습니다.

만약 국내에 터널 브로커 서버가 있다면 아래와 같이 약 10~20ms 정도로 응답시간이 나올 것입니다. 하지만 국내에는 적절한 터널 브로커가 없습니다.

아래 화면은 freenet6 터널브로커 서비스를 이용해 IPv6 포탈 서비스에 접속한 화면입니다.

IPv6 접속 통계 부분을에서 freenet6 터널 브로커에 의해 할당받은 IPv6 주소(2001:5c0:8fff:fffe::5f5)로 연결이 이루어진 것을 알 수 있습니다.

사. 생성된 IPv6 터널의 삭제

터널 브로커에 의해 생성된 IPv6 터널이 더 이상 필요없이 삭제를 하려면 시스템을 재시작하거나,

netsh interface ipv6 reset all 명령을 입력하면 됩니다.

그리고 사설 IPv4 환경에서 터널을 형성한 경우에는 tspc 클라이언트가 실행되고 있던 윈도우즈 창을 종료하면 자동으로 터널이 종료됩니다.

4. 기타 참고 사항

지금까지 freenet6 터널 브로커 서비스의 이용 방법을 알아 보았습니다.

한가지 중요한 사항은 시스템을 재시작하면 기존 터널브로커간 터널 설정이 초기화(삭제)됩니다. 따라서 계속 터널 브로커 서비스를 이용하시려면 "시작 프로그램"에 tspc 클라이언트를 등록하여 시스템이 시작될 때 자동으로 tspc 클라어언트가 실행되도록 해야 합니다.

Pv4 또는 듀얼스택 네트워크가 아닌 IPv6 Native Only 네트워크에서 MRTG를 이용하여 네트워크 장비를 모니터링 하기 위해서는 IPv6 네트워크를 통한 SNMP 데이터의 전송(IPv6 over SNMP)과 MRTG의 IPv6 지원이 필요합니다.
** SNMP : Simple Network Management Protocol
** MRTG : Multi Router Traffic Grapher

본 문서에서는 IPv6 over SNMP를 지원하는 라우터를 대상으로 리눅스에서 MRTG를 이용하여 네트워크 트래픽을 모니터링 하는 방법을 알아보겠습니다. 기본적인 MRTG 설정 및 이용방법은 "MRTG의 설치 및 구성법[PDF 문서 다운로드]" 문서 참고하시기 바랍니다.

1. IPv6를 지원하는 MRTG 및 Perl 모듈

MRTG 2.10.0 버전 이후로는 IPv6을 기본적으로 지원하고 MRTG 2.9.29 버전은 별도의 패치를 요구합니다. 또한 MRTG는 perl 언어로 제작되었기 때문에IPv6 Perl Module의 추가 및 패치가 필요합니다.(본 문서는 Unix용 MRTG 2.10.0 버전을 기준으로 설명 합니다.)

   o IPv6 지원 MRTG 2.10.0 버전 [다운로드],     MRTG 홈페이지[Click]

   o IPv6 Perl Module
      - Socket6 0.17 or above [다운로드], 관련홈페이지[Click]
      - INET6 1.26 or above [다운로드],  관련홈페이지[Click]

2. Perl 모듈 패치

우선 일반적인 방법으로 MRTG를 설치합니다.

    가. Socket6 0.17 Perl 모듈 설치

           다운로드 받은 Socket6 0.17 모듈의 압축을 해제하고 아래와 같이 설치합니다.

           perl Makefile.PL
           make
           make install

    나. INET6 1.26 Perl 모듈 설치

          역시 다운로드 받은 INET 1.26 모듈의 압축을 해제하고 아래와 같이 설치합니다.

           perl Makefile.PL
           make
           make install

만약 위의 두 모듈이 정상적으로 설치되었다면, MRTG의 cfgmaker가 IPv6 지원 여부를 자동적으로 인식하고[--base: IPv6 libraries found, IPv6 enabled.]메시지가 표시됩니다.

3. MRTG cfgmaker 옵션 지정

MRTG가 IPv6 지원을 하더라도 기본적으로 IPv6 기능이 비 활성화되어 있기 때문에 cfgmaker를 이용하여 CFG 파일을 생성할 때 별도의 옵션을 지정해야 하며, 기본적인 cfgmaker 옵션 다음에--enable-ipv6옵션을 추가하면 됩니다.

MRTG를 이용한 모니터링 대상(IPv6 네트워크 장비)은 snmp-communinty@[장비의 IPv6 주소]:161 형태로 지정합니다.

예) public@[2001:2b8:fffe::1]:161

예) cfgmaker 사용예

cfgmaker --global 'WorkDir: /var/www/html/mrtg' --global 'Options[_]:bits,growright' --output /usr/local/mrtg-2/cfg/test.cfg public@[2001:111:111::1]:161--enable-ipv6

4. MRTG 동작 화면

아래 화면은 위 방법을 이용하여 MRTG를 동작시킨 예입니다.

5. 기타 사항

cfgmaker를 제외한 기타 도구(indexmaker 등)의 사용법, cron을 이용한 주기적 데이터 업데이트 방법 등은 기존 IPv4 MRTG 사용법과 동일합니다.

기타 자세한 내용은 MRTGv6 문서[Click]을 참고 하시기 바랍니다.

1. IP 네트워크 카메라 동향

기업, 아파트, 공공장소 및 가정의 보안이 중요시되면서 네트워크 카메라를 이용한 실시간 모니터링 및 감시 서비스에 대한 요구가 커지고 있습니다. 지금까지는 유선기반의 CCTV와 영상 녹화장치를 이용한 감시 시스템이 많이 이용되었으며, 얼마전 부터는 유선기반의 감시 시스템과 IP 네트워크를 결합한 DVR 시스템이 급속히 보급되고 있습니다. 이러한 추세에 맞추어 최근에는 카메라 자체에 네트워킹 기능을 부가한 IP 네트워크 카메라가 소규모 가정 및 기업용으로 이용되고, 무선 네트워킹 기능까지 추가되고 있습니다.

2. IPv6 네트워크 카메라의 개념 및 특징

IP 네트워크 카메라는 영상데이터를 인터넷을 통해 전송하는 기기로서 아날로그 영상데이터를 디지털로 변환하기 위한 영상처리 기능과 디지털화된 영상을 네트워크로 전송하는 네트워킹 기능, 그리고 전송된 영상을 화면에 표시하거나 실시간으로 저장하는 클라이언트 기술이 결합된 임베디드 기기입니다. 보통 Non-PC 기반의 임베디드 OS 또는 네트워크 카메라 전용 Chip을 이용하면서 점차 소형화되고 있습니다.

IPv6 네트워크 카메라는 기존의 IPv4 네트워크 카메라를 기반으로 IPv6 네트워킹 기능을 부가한 것입니다. 기존 IPv4 네트워크 카메라의 OS 또는 전용 Chip을 IPv6 환경에서도 작동할 수 있도록 변경함으로써 IPv6 네트워크 카메라를 구현합니다.

IPv6 네트워크 카메라는 IPv6의 여러 기능을 활용함으로써 IPv4 네트워크 카메라와 차별화됩니다.

  o 무한의 IPv6 주소를 이용함으로써 무한의 IPv6 네트워크 카메라를 설치, 이용 가능

  o IPv6의 자동주소할당(autoconfiguration) 기능을 이용함으로써 주소 관리의 편의성

  o IPv4 NAT 환경에서 네트워크 카메라 접속문제 해결 - End-to-End 투명한 통신

  o DDNS와 연계한 Plug & Play 기능

가. 무한 IPv6 주소 이용

향후 거의 모든 가정이나 기업, 도로 및 주요 시설에는 원격 감시를 위한 크고 작은 네트워크 카메라 및 센서가 설치될 것으로 예상됩니다. 이 경우 기존 IPv4 체계에서는 하나의 네트워크 설치할 수 있는 네트워크 카메라의 규모(개수)가 제한되게 됩니다. IPv6 주소체계를 이용할 경우 이러한 개수의 제한 없이 거의 IPv6 네트워크 카메라와 같은 무한 개의 모니터링 및 감시 서비스 장치를 이용할 수 있습니다.

나. IPv6 자동 주소 할당 기능 이용

기존 임베디드 네트워크 장비에서 가장 어려운 부분이 최초의 접속을 통한 IP 설정 부분이었습니다. 비록 DHCP라는 IPv4 주소 자동설정 기능이 있기는 하지만 DHCP 서버가 있을 때 가능합니다. IPv6 네트워크의 주소 자동설정 기능을 이용한다면, 별도의 디스플레이 장치가 없는 임베디스 기기의 IP 주소 설정을 한결 쉽게 할 수 있습니다. IPv6 네트워크 카메라 역시 이러한 자동주소 설정기능을 이용해 사용자가 IP 주소를 설정할 필요없이 자동으로 생성됩니다.

다. NAT 환경에서의 문제점 해결

기존 NAT를 이용하는 사설 IPv4 환경에서는 NAT 내부 네트워크에서 서버를 운영하려면 NAT에서 포트 포워딩 설정을 일일이 해주어야 합니다. 네트워크 카메라 역시 웹서버와 비디오 서버를 가지고 있기 때문에 NAT에서는 포트 포워딩이 필요합니다. 하지만 IPv6 주소체계에서는 End-to-End 연결성을 보장하기 때문에 게이트웨이에서 별도의 설정없이 바로 IPv6 네트워크 카메라를 이용할 수 있습니다.

라. DDNS와 연계한 Plug & Play 기능

IPv6 주소체계를 지원하는 DDNSv6 서비스(www.6dns.org)와 IPv6 주소 자동할당 기능을 이용하면 IPv6 네트워크 카메라를 박스에서 꺼내 네트워크에 연결하는 것만으로 바로 이용할 수 있는 Plug & Play 기능의 구현이 가능합니다. 이미 생산단계에서 DDNSv6와 연계하여 네트워크카메라 마다 특정의 호스트명(DNS 명)을 부여하고 IPv6 네트워크에 연결될 때 바로 DDNSv6 정보를 업데이트 하도록 하는 것입니다.

[ IPv6 Dynamic DNS 서비스 ]

3. 국내외 IPv6 네트워크 카메라 동향

최근에는 IP 네트워크 카메라의 소형화, 가격하락으로 인하여 일반인에게까지 보급되고 있습니다. 하지만 IPv6 네트워크 카메라는 IPv6 네트워크가 본격적으로 보급되지 않은 까닭에 R&D나 시제품 수준에서 IPv6 네트워크의 급속한 보급을 기다리고 있습니다.

현재 한국과 일본이 IPv6 네트워크 카메라를 개발하여 외부에 공개하고 있습니다.  일본은 파나소닉과 산요가 2003년 IPv6 네트워크 카메라 시제품을 개발하였고 최근 파나소닉에서는 일반인이 시중에서 직접 구입할 수 있는 상용 IPv6 네트워크 카메라를 시판할 계획입니다.

[파나소닉의 IPv6 네트워크 카메라]

[대만 IPv6 Corner에 설치된 파나소닉 IPv6 네트워크 카메라 제어 페이지]

우리나라는 한국전산원이 2004년 초(주)위즈넷과(주)셀링스와 협력하여 기존 상용 IPv4 네트워크 카메라를 이용한 IPv6 네트워크 카메라와 IPv6 비디오 서버 시제품을 개발하여 IPv6 체험관에서 공개하고 있습니다.

한국전산원이 개발한 IPv6 네트워크 카메라는 한국전산원 광화문 무교청사 15층에 있는 IPv6 체험관에 전시되어 있으며 누구나 이용할 수 있습니다. 또한 IPv6 포탈을 통해 원격에서 직접 제어를 할 수 있습니다.

[한국전산원 IPv6 Network Camera Demo 사이트]

4. 한국전산원 IPv6 네트워크 카메라 - NCA 6CAM Type1, Type2

NCA 6CAM은 기존 상용 네트워크 카메라의 임베디드 OS와 관련 애플리케이션을 IPv6로 변환하여 구현되었으며 비디어 서버 분리형인 NCA 6CAM Type1과 비디오 서버 일체형인 Type2가 있습니다.

Type1은 별도의 비디오 서버를 둠으로써 고성능 줌과 음성을 처리할 수 있으며, Type1은 기능을 제한하는 대신 비디오 서버와 영상 카메라를 일체화 함으로써 소형화가 가능하였습니다.

 [NCA 6CAM Type1]

[ NCA 6CAM Type 2 ]

지금까지 IPv6 네트워크 카메라의 개념과 국내외 동향을 간단하게 알아보았습니다.

RFID, 특허분쟁에 발목 잡히나

RFID기술이 지적재산권 분쟁에 휘말릴 위기에 직면했다. RFID에 대한 주요 특허 보유업체가 제기한 로열티 요구 때문이다.

로열티 분쟁의 시발점은 새로운 프로토콜인 EPCG2(Electronic Product Code Generation)표준. 이 표준은 여러 공급자로부터 제공되는 각기 다른 RFID 장비를 한 가지 방식으로 통일시키고 몇몇 기술적 문제를 해결하기 위해 고안된 것이다.

EPCG2 프로토콜에서는 RFID 장비 업체인 인터멕 테크놀러지즈의 특허 기술이 적용될 확률이 크다. 이 회사는 최근 특허 사용에 대한 로열티를 요구하고 나섰다. 지난 6월에는 경쟁사인 매트릭스가 특허 일부를 침해했다며 소송을 제기하기도 했다. 이 소송은 현재 계류중이며 공판 일정은 아직 정해지지 않은 상황이다.

인터멕과 매트릭스의 특허 분쟁은 새로운 프로토콜이 등장하기 직전 불거진 것이다. RFID 프로토콜 관할 단체인 EPC글로벌은 오는 10월 5일 프로토콜 표준을 확정하는 회의를 열 계획이다. 이가운데 일각에서는 인터멕 이외의 여타 특허 보유 업체들도 잇달아 로열티를 요구하고 나설 수 있다며, 이같은 움직임이 RFID 발전을 저해할 수 있음을 우려하고 있다.

알버트슨즈, 프록터&갬블, 월마트, 독일 유통업체 메트로 등 이미 RFID시스템을 설치한 주요 기업들은 새로운 프로토콜 확정을 기다리고 있으며, 바코드를 대체할 무선 추적 기술인 RFID가 상점 도난을 방지하고 재고 관리의 효율성을 높여줄 것으로 기대하고 있다.

업계에 따르면 인터멕은 그동안 표준 제정에 협조적인 자세로 참여하던 중 갑자기 태도를 바꿨다. 이 회사는 RFID의 핵심적인 특허를 가장 많이 보유하고 있다.

MIT 연구원 다니엘 엥겔스는 "EPCG2 표준 제정 과정에서 매트릭스를 상대로 소송을 제기함으로써 기업들의 협업 체제에도 차질이 생겼다"고 말했다. 그는 "이는 심각한 문제일 뿐만 아니라 표준 확립에도 방해가 된다”고 우려했다.

엥겔스가 연구 책임자로 있는 MIT의 오토-ID랩은 RFID 기술의 초기 개발을 선도했으며 로열티 없는 표준을 지향해 온 RFID 연구 기관이다. MIT는 지난해 표준화 추진을 EPC 글로벌에게 인계했다. EPC 글로벌은 바코드를 관리하는 UCC(Uniform Code Council)소속이다.

EPC 글로벌은 표준 고안과 기술 상용화에 주력하고 있다. 이 기술은 특수 마이크로 칩 형태인 RFID 태그를 제품에 이식함으로써 작동하는 원리다. 부착된 태그는 화물적재 선착장이나 창고, 매장에 설치된 RFID 판독기에 위치신호를 보냄으로써 제품 생산에서 판매에 이르기까지 경로를 실시간으로 파악할 수 있도록 한다.

전문가들은 EPCG2 표준이 현 시스템에 남아있는 문제들을 해결하고 RFID 기술을 시험 단계에서 실용화 수준으로 끌어올리는데 필수적이라고 말한다. 이를 위해서는 하드웨어와의 호환성이 뒷받침돼야 하는데, 현재 다양한 경쟁관계의 프로토콜들이 사용되고 있어 쉽지 않은 상황이다. 표준 프로토콜을 사용하면 RFID 판독기는 제조업체에 상관없이 모든 태그를 인식할 수 있다.

RFID 판독기 업체인 씽매직은 모든 태그과 호환되는 판독기를 제작하는 방법으로 호환성 문제를 해결하려 시도하고 있다. 하지만 이 방식은 새로운 종류의 태그가 도입될 때마다 판독기 소프트웨어를 업그레이드해야 한다는 단점이 있다.

엥겔스를 비롯한 전문가들은 한 업체가 로열티를 요구하고 나서면 다른 RFID 특허권자들도 로열티를 요구하게 돼 결과적으로 가격 인상이 초래되고, 초기 단계에 있는 RFID의 수요마저도 소멸될 수 있다고 우려했다. 에얼리언 테크놀러지즈, 매트릭스, TI, 필립스 반도체와 같은 RFID 장비 업체들이 로열티로 불어난 비용을 소비자에게 전가할 가능성도 있다.

인터멕 경영진들은 과거 휴대폰이나 노트북, 바코드와 같은 인기 기술들이 지적재산권 라이선싱 과정을 통해 시장에 나온 것을 선례로 들며 로열티의 정당성을 변호하고 있다. 인터멕 사장인 톰 밀러는 “크로스 라이선싱(특허의 공동사용과 상호허용)없는 제품을 꼽기란 힘들며 혁신은 이렇게 이뤄지는 것"이라고 말했다.

또한 밀러는 자사의 5개 RFID특허가 로열티 없이 제공되고 있으며, 이는 표준 참여 업체 중 가장 많은 수임을 강조했다.

지금까지는 RFID업체나 구매자들이 로열티 분쟁과 연관된 적은 없었다. 면도날 업체 질레트 대변인 폴팍스는 로열티 비용이 미미할 것으로 보고있다. 질레트는 이번 로열티 주장에 대해 그다지 우려하지 않는다고 회사 대변인은 전했다. 질레트는 월마트에 제품을 제공하고 있으며, 월마트의 RFID시스템 구축에도 적극 동참하고 있는 기업이다.

한편 EPC 글로벌측은 인터멕의 특허 주장이 모든 표준 구축 절차에 있어서 통상적으로 일어날 수 있는 문제라며 기술 개발에는 큰 영향은 없을 것이란 입장이다. 하지만 인터멕 특허 기술의 대안을 모색하는 등 공급업체들에게 로열티 부담을 덜어 주려는 노력을 진행 중이다.

텍사스 인스투르먼트(TI) 경영진도 로열티 문제가 현재로서 크게 우려할 점은 아니라고 말한다. 그러나 TI는 중소기업에 비해 자금력이 풍부하고 변화에도 강하므로 에얼리언 테크놀러지와 같은 벤처업체의 상황과는 차이가 있다. TI는 구체적인 언급을 피했으나 대변인 빌 올렌은 로열티 요구에 대해 "그리 놀라운 일도 아니지만 악재도 아니며 단지 산업계가 거쳐야 하는 과정"이라고 말했다.

태그 쇼크, 현실화 될까?
별 영향 없다는 주장도 있지만 인터멕의 로열티 프로그램은 각종 RFID기기 구성요소에 5~7.5%를 로열티를 부과, RFID 특허 보유업체들 사이에 혼란을 야기하고 있다. 인터멕의 밀러는 이를 "어려운 문제"라고 말했다. 특허 보유업체는 개발결과에 의한 이익을 원하는 동시에, 이로 인해 기술이 위축되는 것도 바라지 않는다는 것이다.

엥겔스에 따르면 인터멕 외의 다른 특허보유 기업들이 로열티를 받겠다고 나설 경우 RFID 태그 및 장비의 가격은 최고 2배까지 치솟을 수 있다.

최악의 시나리오이기는 하지만 가격이 두 배로 인상된다면 RFID 산업 전체가 큰 타격을 받은 것은 분명하다. 샌프란시스코에 위치한 RFID 컨설팅업체인 R4 글로벌 솔루션즈의 CEO 제프 리차드는 "현재 RFID 비용 하락이 수요 증가를 이끌고 있다. 하지만 로열티로 비용 상승 요소가 발생한다면 이러한 추세도 꺾이게 될 것"이라고 우려했다.

한편 로열티 문제를 우려하는 사람들도 인터멕을 비롯한 업체들이 성장 단계의 산업발전에 찬물을 끼얹지는 않을 것이라고 조심스럽게 낙관하고 있다. '대박'이 보이는 시장에서 스스로의 관에 못질을 하고 들어가는 격이기 때문이다. 미국 유통업체들은 지난해 9150만 달러를 RFID장비에 투자했으며, 이 액수는 2008년 약13억 달러로 늘어날 것이라고 시장조사기관 IDC는 전망했다. RFID하드웨어에 대한 지출액도 2007년 8억 7500만 달러에 달할 것이다.

리차드는 "모든 업체들이 RFID 기술이 발전되기를 원하고 있다. 전체적으로 봐서 흐름에 역행하는 일은 일어나지 않을 것"이라고 낙관했다. @

Alorie Gilbert (ZDNet Korea)

2004/09/15
원문보기

원문 :http://www.zdnet.co.kr/news/enterprise/0,39024412,39130380,00.htm