ClubKona

Idea: 혁신적인 디자인과 기능의 조명 장치
        건축물과 Embed된 구조
        한국 주거 문화는 선진국에 비해 낙후

사례.1
루미오테크(http://www.lumiotec.com), 파나소닉전공 등

 

Idea: 혁신적인 디자인과 기능의 조명 장치
        건축물과 Embed된 구조
        한국 주거 문화는 선진국에 비해 낙후

사례.1
루미오테크(http://www.lumiotec.com), 파나소닉전공 등

 

2012년 임진년 IT 업계 화두는 전통적인 방법을 넘어서는 비즈니스적, IT적인 변화가 IT기술의 진화를 이끌 것이라는 전망이 나왔다.

최근 한국마이크로소프트(대표 김제임스, 이하 한국MS)는 플랫폼 어드바이저그룹(PAG)과 공동으로 ‘3대 메가 및 8대 IT트렌드’를 발표했다.

◆3대 메가 트렌드 = 올해 국내외 IT는 ▲산업적 관점의 ‘앱=웹’ ▲기술적 관점의 디바이스와 서비스의 결합 ▲전략적 관점의 플랫폼과 생태계의 진화가 거듭될 전망이다.

전통 IT 시대의 소프트웨어(‘앱’의 영역) 소비 유통 방식과 웹을 기반으로 한 서비스 형태의 IT 공급 방식이 서로 영역을 넘나드는 현상(예 포털 서비스가 앱 방식으로 배포되거나 전통 패키지 소프트웨어가 클라우드 서비스 형태로 제공됨)이 나타날 것으로 보인다.

특히 이같은 현상은 서로 통신하는 스마트 디바이스와 클라우드로 대변되는 서비스가 가져 온 디지털 정보 생산과 유통 변화로 진화한다.

아울러 기술적, 산업적 변화를 비즈니스 기회로 삼기 위한 핵심 전략으로서 자사의 플랫폼 입지 확산을 위한 생태계 확보가 국내외 주요 IT 기업의 전략적 화두로 자리 매김할 것으로 보인다.

◆8대 IT 키워드 = 이번 발표에서 올해를 관통하는 키워드 ▲클라우드 컴퓨팅 (Cloud Computing) ▲빅 데이터 (Big Data) ▲디지털 콘텐츠 (Being Digital Contents) ▲소셜 서비스 플랫폼 (Social Services Platform) ▲스마트 디바이스 (Smart Devices) ▲내츄럴 유저 인터페이스(Natural User Interface) ▲HTML5 ▲스마트워크(Flexible Workspace) 등이 제시됐다.

▲ 한국MS와 PAG 그룹이 발표한 2012년 IT 업계 3대 메가트렌드 및 8대 키워드

◆클라우드 컴퓨팅(Cloud Computing, PaaS의 등장과 본격적인 서비스 도입의 시작) = 여러 해 걸쳐 주요한 트렌드로 꼽히며 여러 기관에서 전망치 제시해 왔으나 실제 시장에서의 도입은 예측보다 느린 속도로 움직이고 있다는 것이 대체적인 의견이다.

이는 클라우드 컴퓨팅의 난이도로 인해 실제 사용층인 기업이나 개인이 클라우드 도입으로 인해 얻을 수 있는 가치에 대한 이해가 빠르게 이뤄지지 않았던 원인이 크다.

또 하나는 서버 호스팅, 스토리지 대여, CDN 사업 등 단품 서비스로는 클라우드 컴퓨팅이라고 보기 어려운 기술/사업들이 마케팅 효과를 위해 클라우드 컴퓨팅으로 포장되는 마케팅 버즈 효과로 인해 본격화도 되기 이전에 이미 그 용어 자체는 소비 대중에게 피로감이 높아진 상황이라는 것.

그럼에도 불구하고, 산업에서 클라우드 서비스에 대한 관망과 도입은 차분히 진행되고 있으며, 올 해에는 클라우드 서비스로의 차분한 전환이 본격 시작될 것으로 전망하는 시장 조사기관의 예측이 많다.

또한 ISV들의 클라우드 서비스 모델로의 전환, 즉 SaaS(Sofware as a Service) 생태계 확산의 근간으로서 PaaS(Platform as a Service)의 가치가 점차 주목 받을 것으로 예측된다.

◆빅 데이터(Big Data, 골드러시에 견주는 데이터 러시) = 생산되고 소비되는 정보 수명 주기의 전 단계가 디지털화 트렌드가 뚜렷하다.

더불어 최근 폭증하는 스마트 디바이스로 인해 디지털 정보 소비량도 함께 급증하고 있다. 또한 소셜 네트워크 서비스 확산으로 디지털 콘텐츠 유통 확산 역시 이전과는 전혀 다른 양상으로 펼쳐지고 있다.

이에 따라 정보의 처리와 분석에는 새로운 도전 과제들이 대두됐고, 이를 기존의 데이터 처리 방식과 구분지어 일컫는 목적으로 등장한 용어가 ‘빅 데이터’이다.

빅 데이터의 요구사항은 다음과 같이 설명 가능하다.

예를 들어 트위터에서 특정 정치인의 여론을 분석하거나 소셜 네트워크를 이용한 마케팅의 대상이 되는 제품에 대한 반응을 분석하는 등 시의성을 가지면서 유형이나 규격이 정형화돼 있지 않은 방대한 양의 비정형 데이터를 실시간에 가깝게 분석해야 한다. (클라우드 기반의 분산처리 플랫폼, 인메모리(In-Memory) DB, NoSQL 기술 등 빅데이터 플랫폼 기술과 시맨틱 분석 기술, 신경망 등의 인공지능 기술 등 데이터 분석 기술의 진보)

또 이를 전통적인 정형 데이터의 정보 처리 체계와 통합해야 하며, 해석된 결과를 사용자가 이해하기 쉬운 형태로 제공해야 한다. (BI의 진화, 데이터 시각화)

◆디지털 콘텐츠(Digital Contents, 플랫폼 권력의 핵으로 등장) = 과거의 디지털 콘텐츠가 종이책에서 전자책으로 전환과 같이 아날로그를 디지털로 변환하는 것이 대부분이었던 데 비해 현재의 트렌드는 콘텐츠 제작, 유통, 소비의 전 과정이 디지털화(Being Digital) 되기 시작했다는 것이다.

H.264 와 같은 표준 미디어 기술과 HTML5와 같은 크로스플랫폼 웹 기술의 영향으로 생산 단계에서부터 이미 다양한 소비자 단말과 여러 개의 스크린 사이즈(N-스크린)에 맞는 디지털 콘텐츠가 생산된다.

또한 무제한 3G를 포함하는 저렴한 네트워크와 클라우드 기술, 폭발적 성장세의 스마트 디바이스들의 결합으로 저렴하고 합법적이면서 편리한 콘텐츠 유통과 소비가 이뤄지는 시대가 도래한 것이다.

미래의 스마트 생태계에서는 하드웨어나 OS 경쟁을 넘어서 디지털 콘텐츠의 제공에 있어 얼마나 차별화된 사용자 경험을 제공할 것인가가 경쟁력의 핵심으로 등장하고 있다.

이러한 원인으로 각 매체별로 독립적이었던 사업 영역의 파괴와 디지털 컨버전스 현상이 가속화되고 있다.

◆소셜 서비스 플랫폼(Social Services Platform, 산업 카테고리의 파괴와 재창조) = 소셜 네트워크 서비스(SNS)는 ▲소셜 네트워크 정보를 바탕으로 서비스 자체를 확장할 수 있는 애플리케이션 플랫폼의 형태를 띠고 있고 ▲이러한 기술 기반 위에 다른 산업과 수직결합(vertical integration)을 통해 새로운 유형의 서비스 개발을 이끌고 있으며 ▲이러한 응용 서비스들이 다시 그 모태가 되는 소셜 네트워크 자체에 부가 가치가 높은 새로운 데이터를 유입시켜 ‘비즈니스 네트워크’화 되는 선순환의 고리를 이뤄졌다는 점에서 ‘소셜 서비스 플랫폼’이라고 명명됐다.

매우 간략한 예를 도입해 보면 ▲페이스북이라는 웹 기반의 애플리케이션 플랫폼이 ▲이를 기반으로 한 소셜 게임의 확산으로 새로운 부가가치를 생산하는 플랫폼이 되고 ▲다시 이러한 현상이 페이스북의 광고 플랫폼으로서 가치가 더 높아지는 선순환 고리를 만들어 내었다고 하면 이해가 조금 더 쉬울 것이다.

2012년 현재 소셜 서비스 플랫폼은 이미 거의 모든 형태의 온라인 서비스와 연동돼 타 산업의 소비를 촉진하는 새로운 유형의 디지털 마케팅 플랫폼으로서 가치가 급부상했다.

소셜 커머스, 소셜 게임 등 파생 서비스들은 난립에 가까운 양상을 띠고 있고, 수직적인 특정 산업분야와 결합해 소셜 서비스를 이용한 부동산 중개와 같은 신사업 방식으로 확대되기도 한다.

아울러 소셜 서비스 플랫폼 역시 스마트 디바이스 폭증과 생산, 유통되는 데이트 급증으로 인한 빅데이터 분석 기술 요구 등의 다른 트렌드 키워드들과 밀접한 상호 연결 관계를 갖고 있다.

◆스마트 디바이스(Smart Devices, 사물통신의 증가와 지능형 통신 기기 대중화로 도래한 N-스크린 시대) = 스마트 디바이스에는 흔히 알고 있는 스마트폰, 스마트 TV, 태블릿, 게임콘솔 등은 물론 주변의 상황을 인지하고 반응하는 상황인지 컴퓨팅(context-aware computing) 기술이 탑재돼 정보 합성과 지능적 애플리케이션 개발이 가능한 모든 범주의 지능형 통신기기(intelligent Communication Device)가 포함된다.

예를 들어, 자동차의 텔레매틱스나 환경 감시 기능, 냉장고와 세탁기 에어컨 등까지 스마트 기기라는 명칭으로 소개되고 있다. 스마트 TV의 예에서 잘 드러나듯이 스마트 디바이스 트렌드에서는 N스크린 서비스 역량이 핵심 경쟁력이 될 것이다.

전통적 하드웨어 업체, 콘텐츠 서비스 업체, 망 사업자 등 서로 다른 영역의 사업자들이 ‘디바이스+서비스’ 시장의 패권을 두고 치열한 경쟁이 벌어질 것으로 예상된다.

이를 위한 전제로서 디지털 콘텐츠, 클라우드 서비스 등 다른 트렌드 요소들이 핵심적인 동인이 됨은 부언이 필요없겠다.

또한 스마트폰에 이어 차기 IT 산업을 주도할 주요한 성장 동인으로 사물지능통신(Intelligent Machine to Machine Communication)에 각국 정부 및 대형 IT 기업들이 주목하고 있다.

기계들이 서로 통신하고 수다를 떠는 기계와 기계 간의 SNS 시대가 열리고 있다는 것이다.

◆내츄럴 유저 인터페이스(NUI: Natural User Interface, 사람과 디지털 기기의 ‘아날로그’ 대화법의 성장) = 내추럴 유저 인터페이스(NUI)에서 ‘내추럴’의 의미는 마우스나 키보드와 같은 인공적인 입력 제어 장치 없이도 사람의 자연스런 감각, 행동, 인지 능력을 통해 디지털 기기를 제어하는 인터페이스 기술 또는 연구 개발 방향을 통칭하는 말로 통용되고 있다.

최근의 NUI의 대표주자로 떠오른 멀티터치 UI 기술을 비롯, 스마트 디바이스와 소셜 서비스 등과 맞물려 증강현실(Augmented Reality), 상황인식 컴퓨팅(Context-aware Computing) 등이 다양한 센서 기반 컴퓨팅(Sensor-based computing) 기술과 맞물려 대중화 단계에 이르고 있다.

한편, 동작인식(Motion Capture), 컴퓨터 비전(Computer Vision) 등 이전에는 전문 분야의 특수 기술로서 고가의 장비에서만 가능하던 고수준의 컴퓨터 그래픽스 기술이 폰, 게임기, TV 등 개인용 가전 기기와 결합해 시장에서 큰 반향을 일으키고 있다(예를 들어 엑스박스 키넥트 등).

애플의 시리(Siri)나 MS의 텔미(Tell Me) 등에서 볼 수 있듯 음성인식 기술도 시장에서 실용성을 재검증 받고 있다.

◆HTML5(N-스크린을 아우르는 표준화된 앱 개발 플랫폼) = HTML5는 HTML5, CSS3 등 최신 웹 기술을 통칭하는 의미로 사용되고 있다.

HTML5는 특정 플랫폼에 종속되지 않는 공인 표준 웹 기술이므로 당연히 서로 다른 플랫폼에서 가능한 동등한 사용성을 제공하는 하는 동시에 기존에는 특정 디바이스 전용 플랫폼에서만 가능했던 기능까지 제공해 여러 디바이스를 아우르는 애플리케이션 플랫폼으로 자리매김 할 것으로 보고 있다.

지금에 이르러 HTML5의 중요성이 강조되는 배경은 ▲기존의 웹기반 서비스들이 PC, 스마트폰, 태블릿 등 다양한 사용자 단말 장치로 영역을 확대하기 위한 애플리케이션 플랫폼으로서 ‘서비스(인터넷을 통한 배포)+디바이스(다양한 단말에서의 서비스 소비)’ 생태계에서 웹 기반 기술이 명확한 입지를 굳혀가고 있는 산업적 동향을 꼽을 수 있다.

또한 ▲기술적인 측면에서 스마트 기기의 대중화로 인해 전통 IT 기기인 PC를 넘어 여러 개의 스크린(N 스크린)을 가로질러 서로 다른 기기에서도 마치 한 개의 애플리케이션을 계속 이어서 쓰는 것처럼 동등한 사용성을 보장받고자 하는 요구가 대두된 배경이 있다.

이를 위한 기술에 대한 중복 투자를 최소화 할 수 있는 표준 플랫폼의 필요 역시 함께 급부상하게 됐다.

◆스마트워크(Flexible Workspace, 디지털 라이프에서 재정의되고 있는 일과 삶의 경계) = 스마트 디바이스와 클라우드 서비스의 급속한 확산으로 기업 공간에 개인의 디바이스가 개입되는 BYOD(Bring Your Own Device) 동향과 소비 대중이 주도하는 IT 변화(Consumerization of IT)가 현실화 되고 있다.

자연스레 이러한 변화를 수용하기 위한 IT 체계의 변화, 시설 개선 등이 함께 산업에서의 화두로 등장하고 있다.

특히 ‘9to6’ 출퇴근 근무 형태에서 벗어나 개인의 일하는 방식, 내외근 직의 직무 특성 등을 고려한 모바일 환경 및 원격 근무 환경을 지원하는 IT 체계에 대한 투자 관심이 커지고 있다.

IT 인프라 및 물리적 환경에 대한 투자와 더불어 업무 수행 방식과 업무 성과 평가 방식 등 사회 문화적 요소를 함께 변화하는 것도 반드시 고려돼야 할 점으로 예측된다.

2012년 임진년 IT 업계 화두는 전통적인 방법을 넘어서는 비즈니스적, IT적인 변화가 IT기술의 진화를 이끌 것이라는 전망이 나왔다.

최근 한국마이크로소프트(대표 김제임스, 이하 한국MS)는 플랫폼 어드바이저그룹(PAG)과 공동으로 ‘3대 메가 및 8대 IT트렌드’를 발표했다.

◆3대 메가 트렌드 = 올해 국내외 IT는 ▲산업적 관점의 ‘앱=웹’ ▲기술적 관점의 디바이스와 서비스의 결합 ▲전략적 관점의 플랫폼과 생태계의 진화가 거듭될 전망이다.

전통 IT 시대의 소프트웨어(‘앱’의 영역) 소비 유통 방식과 웹을 기반으로 한 서비스 형태의 IT 공급 방식이 서로 영역을 넘나드는 현상(예 포털 서비스가 앱 방식으로 배포되거나 전통 패키지 소프트웨어가 클라우드 서비스 형태로 제공됨)이 나타날 것으로 보인다.

특히 이같은 현상은 서로 통신하는 스마트 디바이스와 클라우드로 대변되는 서비스가 가져 온 디지털 정보 생산과 유통 변화로 진화한다.

아울러 기술적, 산업적 변화를 비즈니스 기회로 삼기 위한 핵심 전략으로서 자사의 플랫폼 입지 확산을 위한 생태계 확보가 국내외 주요 IT 기업의 전략적 화두로 자리 매김할 것으로 보인다.

◆8대 IT 키워드 = 이번 발표에서 올해를 관통하는 키워드 ▲클라우드 컴퓨팅 (Cloud Computing) ▲빅 데이터 (Big Data) ▲디지털 콘텐츠 (Being Digital Contents) ▲소셜 서비스 플랫폼 (Social Services Platform) ▲스마트 디바이스 (Smart Devices) ▲내츄럴 유저 인터페이스(Natural User Interface) ▲HTML5 ▲스마트워크(Flexible Workspace) 등이 제시됐다.

▲ 한국MS와 PAG 그룹이 발표한 2012년 IT 업계 3대 메가트렌드 및 8대 키워드

◆클라우드 컴퓨팅(Cloud Computing, PaaS의 등장과 본격적인 서비스 도입의 시작) = 여러 해 걸쳐 주요한 트렌드로 꼽히며 여러 기관에서 전망치 제시해 왔으나 실제 시장에서의 도입은 예측보다 느린 속도로 움직이고 있다는 것이 대체적인 의견이다.

이는 클라우드 컴퓨팅의 난이도로 인해 실제 사용층인 기업이나 개인이 클라우드 도입으로 인해 얻을 수 있는 가치에 대한 이해가 빠르게 이뤄지지 않았던 원인이 크다.

또 하나는 서버 호스팅, 스토리지 대여, CDN 사업 등 단품 서비스로는 클라우드 컴퓨팅이라고 보기 어려운 기술/사업들이 마케팅 효과를 위해 클라우드 컴퓨팅으로 포장되는 마케팅 버즈 효과로 인해 본격화도 되기 이전에 이미 그 용어 자체는 소비 대중에게 피로감이 높아진 상황이라는 것.

그럼에도 불구하고, 산업에서 클라우드 서비스에 대한 관망과 도입은 차분히 진행되고 있으며, 올 해에는 클라우드 서비스로의 차분한 전환이 본격 시작될 것으로 전망하는 시장 조사기관의 예측이 많다.

또한 ISV들의 클라우드 서비스 모델로의 전환, 즉 SaaS(Sofware as a Service) 생태계 확산의 근간으로서 PaaS(Platform as a Service)의 가치가 점차 주목 받을 것으로 예측된다.

◆빅 데이터(Big Data, 골드러시에 견주는 데이터 러시) = 생산되고 소비되는 정보 수명 주기의 전 단계가 디지털화 트렌드가 뚜렷하다.

더불어 최근 폭증하는 스마트 디바이스로 인해 디지털 정보 소비량도 함께 급증하고 있다. 또한 소셜 네트워크 서비스 확산으로 디지털 콘텐츠 유통 확산 역시 이전과는 전혀 다른 양상으로 펼쳐지고 있다.

이에 따라 정보의 처리와 분석에는 새로운 도전 과제들이 대두됐고, 이를 기존의 데이터 처리 방식과 구분지어 일컫는 목적으로 등장한 용어가 ‘빅 데이터’이다.

빅 데이터의 요구사항은 다음과 같이 설명 가능하다.

예를 들어 트위터에서 특정 정치인의 여론을 분석하거나 소셜 네트워크를 이용한 마케팅의 대상이 되는 제품에 대한 반응을 분석하는 등 시의성을 가지면서 유형이나 규격이 정형화돼 있지 않은 방대한 양의 비정형 데이터를 실시간에 가깝게 분석해야 한다. (클라우드 기반의 분산처리 플랫폼, 인메모리(In-Memory) DB, NoSQL 기술 등 빅데이터 플랫폼 기술과 시맨틱 분석 기술, 신경망 등의 인공지능 기술 등 데이터 분석 기술의 진보)

또 이를 전통적인 정형 데이터의 정보 처리 체계와 통합해야 하며, 해석된 결과를 사용자가 이해하기 쉬운 형태로 제공해야 한다. (BI의 진화, 데이터 시각화)

◆디지털 콘텐츠(Digital Contents, 플랫폼 권력의 핵으로 등장) = 과거의 디지털 콘텐츠가 종이책에서 전자책으로 전환과 같이 아날로그를 디지털로 변환하는 것이 대부분이었던 데 비해 현재의 트렌드는 콘텐츠 제작, 유통, 소비의 전 과정이 디지털화(Being Digital) 되기 시작했다는 것이다.

H.264 와 같은 표준 미디어 기술과 HTML5와 같은 크로스플랫폼 웹 기술의 영향으로 생산 단계에서부터 이미 다양한 소비자 단말과 여러 개의 스크린 사이즈(N-스크린)에 맞는 디지털 콘텐츠가 생산된다.

또한 무제한 3G를 포함하는 저렴한 네트워크와 클라우드 기술, 폭발적 성장세의 스마트 디바이스들의 결합으로 저렴하고 합법적이면서 편리한 콘텐츠 유통과 소비가 이뤄지는 시대가 도래한 것이다.

미래의 스마트 생태계에서는 하드웨어나 OS 경쟁을 넘어서 디지털 콘텐츠의 제공에 있어 얼마나 차별화된 사용자 경험을 제공할 것인가가 경쟁력의 핵심으로 등장하고 있다.

이러한 원인으로 각 매체별로 독립적이었던 사업 영역의 파괴와 디지털 컨버전스 현상이 가속화되고 있다.

◆소셜 서비스 플랫폼(Social Services Platform, 산업 카테고리의 파괴와 재창조) = 소셜 네트워크 서비스(SNS)는 ▲소셜 네트워크 정보를 바탕으로 서비스 자체를 확장할 수 있는 애플리케이션 플랫폼의 형태를 띠고 있고 ▲이러한 기술 기반 위에 다른 산업과 수직결합(vertical integration)을 통해 새로운 유형의 서비스 개발을 이끌고 있으며 ▲이러한 응용 서비스들이 다시 그 모태가 되는 소셜 네트워크 자체에 부가 가치가 높은 새로운 데이터를 유입시켜 ‘비즈니스 네트워크’화 되는 선순환의 고리를 이뤄졌다는 점에서 ‘소셜 서비스 플랫폼’이라고 명명됐다.

매우 간략한 예를 도입해 보면 ▲페이스북이라는 웹 기반의 애플리케이션 플랫폼이 ▲이를 기반으로 한 소셜 게임의 확산으로 새로운 부가가치를 생산하는 플랫폼이 되고 ▲다시 이러한 현상이 페이스북의 광고 플랫폼으로서 가치가 더 높아지는 선순환 고리를 만들어 내었다고 하면 이해가 조금 더 쉬울 것이다.

2012년 현재 소셜 서비스 플랫폼은 이미 거의 모든 형태의 온라인 서비스와 연동돼 타 산업의 소비를 촉진하는 새로운 유형의 디지털 마케팅 플랫폼으로서 가치가 급부상했다.

소셜 커머스, 소셜 게임 등 파생 서비스들은 난립에 가까운 양상을 띠고 있고, 수직적인 특정 산업분야와 결합해 소셜 서비스를 이용한 부동산 중개와 같은 신사업 방식으로 확대되기도 한다.

아울러 소셜 서비스 플랫폼 역시 스마트 디바이스 폭증과 생산, 유통되는 데이트 급증으로 인한 빅데이터 분석 기술 요구 등의 다른 트렌드 키워드들과 밀접한 상호 연결 관계를 갖고 있다.

◆스마트 디바이스(Smart Devices, 사물통신의 증가와 지능형 통신 기기 대중화로 도래한 N-스크린 시대) = 스마트 디바이스에는 흔히 알고 있는 스마트폰, 스마트 TV, 태블릿, 게임콘솔 등은 물론 주변의 상황을 인지하고 반응하는 상황인지 컴퓨팅(context-aware computing) 기술이 탑재돼 정보 합성과 지능적 애플리케이션 개발이 가능한 모든 범주의 지능형 통신기기(intelligent Communication Device)가 포함된다.

예를 들어, 자동차의 텔레매틱스나 환경 감시 기능, 냉장고와 세탁기 에어컨 등까지 스마트 기기라는 명칭으로 소개되고 있다. 스마트 TV의 예에서 잘 드러나듯이 스마트 디바이스 트렌드에서는 N스크린 서비스 역량이 핵심 경쟁력이 될 것이다.

전통적 하드웨어 업체, 콘텐츠 서비스 업체, 망 사업자 등 서로 다른 영역의 사업자들이 ‘디바이스+서비스’ 시장의 패권을 두고 치열한 경쟁이 벌어질 것으로 예상된다.

이를 위한 전제로서 디지털 콘텐츠, 클라우드 서비스 등 다른 트렌드 요소들이 핵심적인 동인이 됨은 부언이 필요없겠다.

또한 스마트폰에 이어 차기 IT 산업을 주도할 주요한 성장 동인으로 사물지능통신(Intelligent Machine to Machine Communication)에 각국 정부 및 대형 IT 기업들이 주목하고 있다.

기계들이 서로 통신하고 수다를 떠는 기계와 기계 간의 SNS 시대가 열리고 있다는 것이다.

◆내츄럴 유저 인터페이스(NUI: Natural User Interface, 사람과 디지털 기기의 ‘아날로그’ 대화법의 성장) = 내추럴 유저 인터페이스(NUI)에서 ‘내추럴’의 의미는 마우스나 키보드와 같은 인공적인 입력 제어 장치 없이도 사람의 자연스런 감각, 행동, 인지 능력을 통해 디지털 기기를 제어하는 인터페이스 기술 또는 연구 개발 방향을 통칭하는 말로 통용되고 있다.

최근의 NUI의 대표주자로 떠오른 멀티터치 UI 기술을 비롯, 스마트 디바이스와 소셜 서비스 등과 맞물려 증강현실(Augmented Reality), 상황인식 컴퓨팅(Context-aware Computing) 등이 다양한 센서 기반 컴퓨팅(Sensor-based computing) 기술과 맞물려 대중화 단계에 이르고 있다.

한편, 동작인식(Motion Capture), 컴퓨터 비전(Computer Vision) 등 이전에는 전문 분야의 특수 기술로서 고가의 장비에서만 가능하던 고수준의 컴퓨터 그래픽스 기술이 폰, 게임기, TV 등 개인용 가전 기기와 결합해 시장에서 큰 반향을 일으키고 있다(예를 들어 엑스박스 키넥트 등).

애플의 시리(Siri)나 MS의 텔미(Tell Me) 등에서 볼 수 있듯 음성인식 기술도 시장에서 실용성을 재검증 받고 있다.

◆HTML5(N-스크린을 아우르는 표준화된 앱 개발 플랫폼) = HTML5는 HTML5, CSS3 등 최신 웹 기술을 통칭하는 의미로 사용되고 있다.

HTML5는 특정 플랫폼에 종속되지 않는 공인 표준 웹 기술이므로 당연히 서로 다른 플랫폼에서 가능한 동등한 사용성을 제공하는 하는 동시에 기존에는 특정 디바이스 전용 플랫폼에서만 가능했던 기능까지 제공해 여러 디바이스를 아우르는 애플리케이션 플랫폼으로 자리매김 할 것으로 보고 있다.

지금에 이르러 HTML5의 중요성이 강조되는 배경은 ▲기존의 웹기반 서비스들이 PC, 스마트폰, 태블릿 등 다양한 사용자 단말 장치로 영역을 확대하기 위한 애플리케이션 플랫폼으로서 ‘서비스(인터넷을 통한 배포)+디바이스(다양한 단말에서의 서비스 소비)’ 생태계에서 웹 기반 기술이 명확한 입지를 굳혀가고 있는 산업적 동향을 꼽을 수 있다.

또한 ▲기술적인 측면에서 스마트 기기의 대중화로 인해 전통 IT 기기인 PC를 넘어 여러 개의 스크린(N 스크린)을 가로질러 서로 다른 기기에서도 마치 한 개의 애플리케이션을 계속 이어서 쓰는 것처럼 동등한 사용성을 보장받고자 하는 요구가 대두된 배경이 있다.

이를 위한 기술에 대한 중복 투자를 최소화 할 수 있는 표준 플랫폼의 필요 역시 함께 급부상하게 됐다.

◆스마트워크(Flexible Workspace, 디지털 라이프에서 재정의되고 있는 일과 삶의 경계) = 스마트 디바이스와 클라우드 서비스의 급속한 확산으로 기업 공간에 개인의 디바이스가 개입되는 BYOD(Bring Your Own Device) 동향과 소비 대중이 주도하는 IT 변화(Consumerization of IT)가 현실화 되고 있다.

자연스레 이러한 변화를 수용하기 위한 IT 체계의 변화, 시설 개선 등이 함께 산업에서의 화두로 등장하고 있다.

특히 ‘9to6’ 출퇴근 근무 형태에서 벗어나 개인의 일하는 방식, 내외근 직의 직무 특성 등을 고려한 모바일 환경 및 원격 근무 환경을 지원하는 IT 체계에 대한 투자 관심이 커지고 있다.

IT 인프라 및 물리적 환경에 대한 투자와 더불어 업무 수행 방식과 업무 성과 평가 방식 등 사회 문화적 요소를 함께 변화하는 것도 반드시 고려돼야 할 점으로 예측된다.

고객이 제품 및 서비스에 대해 높은 충성심(?)을 가져 보다 좋은 제품이나 서비스가 있어도 이용하지 않고, 원래 쓰던 제품 및 서비스를 계속 이용하는 것을 말합니다.

기존의 제품 및 서비스보다 더 개선되고 성능이 좋은 것이 나와도 이미 투자된 비용이나 기회비용 때문에(혹은 너무나 익숙해서) 또는 타 제품 및 서비스로의 교체 비용(switching cost)으로 인해 고객은 기존의 제품 및 서비스에 충성을 가지게 되는 것이죠.

기업 및 조직에서는 보통 다음의 단계를 통해 lock in 효과를 거두게 됩니다.

"무상제공 또는 저가제공" → "고객의 고착화" → "유료전환"

예를 들면, 휴대폰 단말기 지급(번호를 바꾸기 어려움), 온라인 게임업체의 저레벨 무료 정책(고레벨에 가까워질수록 이제껏 게임에 투자한 시간과 노력 때문에라도 유료전환), 이동통신업체의 10대 이용자 요금정책(이들이 성인이 되어 실수효자가 될 경우 대부분 자사 서비스 이용) 등이 있겠죠.

고착화 전략은 먼저 시장에 진입한 기업 및 조직에게는 큰 이익이 될 수 있습니다. 기업간의 경쟁이 약화되고, 제품 및 서비스의 질 향상이 더디게 되어 시장독점이 가능하기 때문이죠.
물론 교체 비용의 하락과 높은 기회비용 제공을 통해 고착화 전략에 대한 공격이 가능합니다.

고객이 제품 및 서비스에 대해 높은 충성심(?)을 가져 보다 좋은 제품이나 서비스가 있어도 이용하지 않고, 원래 쓰던 제품 및 서비스를 계속 이용하는 것을 말합니다.

기존의 제품 및 서비스보다 더 개선되고 성능이 좋은 것이 나와도 이미 투자된 비용이나 기회비용 때문에(혹은 너무나 익숙해서) 또는 타 제품 및 서비스로의 교체 비용(switching cost)으로 인해 고객은 기존의 제품 및 서비스에 충성을 가지게 되는 것이죠.

기업 및 조직에서는 보통 다음의 단계를 통해 lock in 효과를 거두게 됩니다.

"무상제공 또는 저가제공" → "고객의 고착화" → "유료전환"

예를 들면, 휴대폰 단말기 지급(번호를 바꾸기 어려움), 온라인 게임업체의 저레벨 무료 정책(고레벨에 가까워질수록 이제껏 게임에 투자한 시간과 노력 때문에라도 유료전환), 이동통신업체의 10대 이용자 요금정책(이들이 성인이 되어 실수효자가 될 경우 대부분 자사 서비스 이용) 등이 있겠죠.

고착화 전략은 먼저 시장에 진입한 기업 및 조직에게는 큰 이익이 될 수 있습니다. 기업간의 경쟁이 약화되고, 제품 및 서비스의 질 향상이 더디게 되어 시장독점이 가능하기 때문이죠.
물론 교체 비용의 하락과 높은 기회비용 제공을 통해 고착화 전략에 대한 공격이 가능합니다.

[지디넷코리아]최근 흩어져 있는 데이터를 공유하는 것에 대한 논의가 활발히 이뤄지고 있다. 특히 원거리의 분산환경 상의 정보뿐만 아니라 서로 성격을 달리하는 정보들(DW, CRM, 인사, 회계 등)간의 긴밀한 데이터 통합이 필수적이다. 이런 요구가 생기는 것은 기업 환경의 급격한 변화에 기인하고 있다. 기업에서는 회사의 업무 우선 순위의 변경이라든지 업무요구의 변화에 따라 자체 자원 조정의 요구에 종종 직면하게 된다. 오라클10g에서는 급격한 변화 요구에 따른 회사 자원의 손쉬운 조정을 가능하게 하는 완벽한 그리드 컴퓨팅 솔루션을 제공한다. 정보 프로비저닝(provisioning)은 분산환경하에서 언제 어디서든지 필요로 하는 정보의 접근을 가능케 하는 그리드 솔루션의 중요한 구성요소이다. 

원하는 곳, 필요한 때에 데이터 얻기
그리드 컴퓨팅은 필요로 하는 자원의 동적 재배치와 가상화를 통한 조정의 어려움을 배제할 수 있다. 정보는 필요로 하는 곳에 반드시 제공되어야 하는 중요한 자원 중 하나이다. 원하는 곳, 필요로 하는 때에 데이터를 얻기 위해서 매우 정교한 정보 프로비저닝 기술이 요구된다. 이러한 프로비저닝 기술은 정보의 물리적인 위치와 상관없이 필요로 하는 시기와 장소에 최적의 정보를 얻을 수 있도록 한다. 그리드 내의 분산 환경이거나 독립형 시스템, 다수의 그리드에 걸쳐 있는 정보를 통합한다. 

정보를 공유하면 사용자가 필요로 할 경우 그것이 어디에 저장되어 있는지 알 필요 없이 정보를 취득할 수 있다. 정보가 어떤 가용 자원상에 있는지 관계없이 처리하기 위해서 그리드는 다수의 시스템에 걸쳐 효율적으로 정보를 공유해야 한다. 그리드는 이기종의 시스템에 있는 데이터 액세스까지도 제공해야만 한다.

오라클10g에서는 분산 SQL, 메시지 큐잉과 복제 기능을 포함한 데이터 공유를 위한 단일 통합환경을 제공하는 오라클 스트림(Streams), 오라클 환경으로부터 non-오라클 시스템의 데이터 접근을 허용하는 ‘투명한 게이트웨이’와 transportable tablespace, data pump 등을 이용한 대규모 데이터 이동 기술을 이용한 정보 프로비저닝 기능을 갖고 있다. 

그 중 오라클에서 제시하는 정보 공유(information sharing) 기법들 중 오라클 스트림에 대해서 자세히 알아보도록 하겠다. 오라클 스트림은 오라클9i R2부터 소개된 정보 공유 기능이다. 오라클 스트림은 데이터베이스 내 또는 하나의 데이터베이스에서 다른 데이터베이스로 데이터(데이터, 트랜잭션 및 이벤트)를 전달할 수 있도록 지원한다. 

예를 들어 스트림을 사용해 데이터베이스 객체의 DML 및 DDL 변경 사항을 이벤트로 캡처할 수 있다. 그런 다음 데이터베이스 객체를 다른 데이터베이스로 효율적으로 복제해 이러한 이벤트를 다른 데이터베이스에 전달할 수 있다. 또한 같은 오라클 버전, OS, 플랫폼과 같은 제한사항이 없으며, 또한 게이트웨이를 사용해 이기종 DBMS(Heterogeneous DBMS; DB2, SQL 서버, 사이베이스 등)와의 연동까지도 가능하다. 

<그림 1> 오라클 스트림

활용방안
데이터 복제 기능 활용
현재의 시스템 환경은 데이터와 인터넷 환경을 통한 사용자의 급격한 증가에 직면하고 있는 상황이다. 고로 OLTP로 운영되는 메인 시스템 같은 경우 피크 타임(peak time)시의 부하량 증가 및 배치 작업시의 OLTP와 대규모 쿼리성 작업의 병목현상으로 인한 문제가 심각하다. 이 경우 보통 OLTP 시스템의 물리적인 증가(CPU, 메모리 증가)를 통해서 문제를 해결하던지 제한적이나마 튜닝을 통해서 해결될 수 있지만, 너무 많은 비용의 소요와 제한적인 해결책이라고 할 수 있다.

OLTP에서 생기는 막대한 데이터들은 배치/리포트용 시스템, fail-over 시스템, 분석 시스템으로 Near Real time으로 이동시키는 것이 가능하다면, 또한 이런 작업을 할 때 OLTP에 부하를 주지 않을 수만 있다면 OLTP 시스템의 안정화, 소규모 투자를 통한 분석/리포트 시스템 구축이라는 두 마리 토끼를 한꺼번에 잡을 수 있다.

현재 이런 작업은 여러 산업 분야에서 사용되고 있으며, 그 중 반도체 생산시스템 분야의 생산 레거시 시스템에서 분석 시스템으로의 데이터 이동 처리 업무에 파일롯 형태로 검토하고 있다. 

데이터 웨어하우스 로딩 사용
OLTP에서 DW 시스템으로 데이터를 이동시키는 전통적인 방법은 배치 프로그램을 통한 하루에 한 두 번씩의 대규모 SQL문의 수행이었다. 그러나 새롭게 개선된 오라클 스트림을 사용하면 OLTP 시스템에 부하 없이 리두 로그 파일의 변경된 내용만을 전달하는 것이 가능하고, 또한 리두 로그 파일이 거의 실시간에 데이터가 생기는 속성으로 인해서 근접 실시간 데이터 이동이 가능하다. 현재의 RTE(Real Time Enterprise) 환경에서 가장 중요한 기능이 제공된다.

현재의 진화하는 DW 시스템은 예전의 오래된 데이터를 누적해서 분석하는 차원에서 진일보해 실시간으로 파악되는 현황을 토대로 분석하는 응용된 DW 시스템으로 나아가고 있다. 몇 일전 혹은 몇 년 전의 가격 추이도 중요한 정보지만 지금 당장의 판매 현황, 판매 추이 분석이 더 중요한 기업환경에서 DW의 ETT 작업에 스트림을 활용할 수 있다. 

메시지 큐잉 기능의 활용
단순한 데이터의 이동뿐만 아니라 하나의 운영 시스템에서의 특정 데이터를 대상으로 다른 복수의 시스템으로 복수의 변형된 데이터로 변환해 전송할 수 있다. 예를 들면 생산시스템에서 회계 시스템, 판매 시스템, 분석 시스템, DW 시스템, CRM 시스템, EIS 시스템 등 다수의 데이터가 필요한 곳으로 보낼 수도 있고, 필요에 의해서 원본 데이터에서 변형된 형태로 데이터를 보낼 수 있다. 오라클 큐잉 매커니즘을 사용하기 때문에 안정적으로 사용되며, 현 업무에서 적용 가능한 데이터 통합(integration) 시스템의 구축도 가능하다. 보통의 메시지를 이용하는 EAI 솔루션과 동일 수준의 데이터 관리, 이벤트 처리가 가능하며 더불어 데이터베이스의 안정성까지 추가적으로 보장한다.

분산환경에서의 데이터 복제 가능
중앙 집중적인 통합 시스템의 문제로 인한 분산환경으로 시스템이 구축돼 있을 경우 서로 공유하는 데이터에 대해서는 분산 복제 기능을 사용해 데이터의 정확성을 맞춰야 하는데, 이 경우 과거 버전의 오라클에서는 db_link, trigger, replication 등의 방법을 이용했다. 이런 방법들은 발표될 시점에서는 아주 강력하고 손쉬운 방법이었으나, 지금은 셋업의 불편, 퍼포먼스의 문제 등으로 인해 그 사용이 제한적인 상태이다. 스트림을 이용한 데이터 복제는 기존의 오라클 데이터 공유(data sharing) 방법에서 할 수 있는 양방향 복제, 데이터 충돌에 따른 resolution, 이기종 DBMS와의 연동뿐만 아니라 더 빠른 속도와 네트워크 부하의 감소, 더 간편한 셋업(configuration)이 가능하다. 

고가용성 솔루션
원본 시스템의 전체 데이터베이스를 백업 시스템으로 near real time으로 이동시킨다면 원본 시스템의 장애시 백업 시스템을 즉시 활용하는 것이 가능하다. 즉 원격지에서의 데이터 보호를 위한 솔루션인 재난복구(DR) 시스템으로도 사용이 가능하다.

스트림 구조
스트림은 오라클9i R2에 소개된 것으로 Logminer(리두 로그 파일 분석기)의 기능을 이용해 리두 로그 파일/아카이브 파일(Archive File)을 읽어서 원하는 테이블, 스키마 혹은 전체 데이터베이스의 변경사항을 캡처해 리모트 데이터베이스(Remote Database)로 전달해 적용한다. 

이러한 방식으로 원격지 데이터베이스간의 정보 공유를 지원하며, 또한 스트림은 전달하는 과정에서 소스 변경사항 이외의 추가적인 변경이나 정보를 맵핑해 타겟 데이터베이스에 반영할 수 있는 트랜스포메이션(transformation) 기능도 지원한다.

<그림 2> 스트림 아키텍처

<그림 3> 3대 기본 요소

캡처
원래 오라클 데이터베이스의 변경은 모두 리두 로그 파일로 기록된다. 이 리두 로그 파일은 향후 복구시 이용될 수 있도록 데이터베이스의 변경 내역을 담고 있으며, 또 아카이브 프로세스에 의해서 리두 로그 파일이 arch 로그 파일로 복사된다.

캡처 프로세스는 소스 데이터베이스의 리두 로그 & 아카이브 로그의의 변동 사항을 읽어서 등록된 객체의 변경사항(DML, DDL)이 있으면 리두 로그 포맷을 LCR 포맷으로 변경해 송신 큐에 넣어 주는 역할을 한다. 즉 리두 로그 파일에 있는 변경된 사항만을 캡처해 LCR이라는 형태로 변환시켜 송신 큐에 넣어주는 역할을 하며 캡처 시작(capture start)에 의해서 ora_cnnn_sid라는 백그라운드 프로세스가 실질적인 작업을 한다. 캡처 프로세스는 buffered 큐 형태의 Sys.AnyData라는 데이터 타입을 이용해 LCR 형태로 저장한다. 스트림에서는 모든 사용자 메시지를 SYS.AnyData 타입으로 랩핑(wrapping)해 전달한다.

<그림 4> 캡처 프로세스

◆ 캡처 진행 과정
[1] 사용자에 의해서 dept 테이블에 변경 요청이 들어옴
[2] 오라클 DBMS는 dept 테이블을 수정하고, 그와 동시에 리두 로그 파일에도 그 내용을 저장함 
[3] 캡처 프로세스는 리두 로그 파일을 분석해 LCR 포맷의 형태로 전환해 SGA 메모리 영역의 buffered 큐에 저장함(ora_cnnn_sid).
[4] 캡처할 때 규칙에 의한 평가, 변환 작업을 수행할 수도 있다(evaluation & transformation).

Staging & Propagation 
소스 데이터베이스 대기열의 변경 사항을 도착지 데이터베이스의 대기열로 전달한다. 도착지(destination) 데이터베이스의 큐에 반영하기 위해 스케줄링을 한다. Staging area는 캡처된 이벤트에 대한 저장, 관리 서비스를 제공하는 큐 매커니즘이다. 동일한 데이터베이스나 다른 데이터베이스에 존재하는 또 다른 staging area로 전달(propagation)될 수 있으며 네트워크 라우팅의 간소화와 트래픽의 감소를 위해 모든 데이터베이스와 애플리케이션에 바로 보낼 필요 없이 일단 일종의 허브 데이터베이스(실제로 적용은 하지 않는)로 전달할 수 있다.

일반적인 큐잉 시스템이 제공하는 데이터의 유실(loss)을 절대로 허용하지 않기 때문에 도착지 사이트에 전달되기 전까지는 큐에 남아있어 데이터 유실이 전혀 있을 수 없다. 또한 표준 방식을 통해 핸들링되므로 PL/SQL, JMS, OCI 프로그래밍 등 일반적인 프로그래밍 방식을 통해서 사용자 프로그램이 enqueue 메시지 처리를 할 수 있다. 

<그림 5> 소스 큐와 Destination 큐

◆ Propagation의 진행 과정
[1] 캡처에 의해서 만들어진 LCR 포맷 데이터나 사용자 프로그램에 의해서 만들어진 사용자 메시지가 큐에 저장된다. 
[2] DBMS_job 또는 DBMS_schedule에 의해 등록된 propagation을 처리하는 job이 설정된 값에 따라(1초부터 초단위로 간격 조정 가능) 큐에서 데이터를 읽어 목적지(도착지) 시스템의 큐에 짚어 넣는다.
[3] 이때 사용되는 큐 테이블은 SGA의 메모리 영역에 있는 것으로서 메모리 사이의 I/O를 수행하기 때문에 빠른 처리 속도를 가진다. 만약 할당된 메모리 영역이 부족할 경우는 스트림을 지원하는 테이블스페이스(디스크)에 저장되어, 데이터 유실이 없도록 하는 안정장치를 갖고 있다. 메모리에서 propagation 작업이 이뤄지다가 아직 도착하지 못한 데이터가 있는 상태에서 DBMS의 갑작스런 정지 상황이 생기면 다시 startup될 때 캡처 프로세스에 의해서 소스 큐에 미 전달된 데이터의 정보를 파악해 다시 큐잉 작업을 수행해 도착지 DBMS에 가는 작업을 자동적으로 수행한다. 

APPLY
Staging area에 있는 이벤트는 apply 프로세스에 의해 소비(consumption)되어, 데이터베이스 내에서 SQL문 형태로 적용되던지, 또는 사용자 메시지의 경우 애플리케이션에 의해서 도착지 데이터베이스에 적용된다. 이때 빠른 처리를 위해서 병렬 apply 서버 셋업이 가능하다. 

결국 범용적인 표준을 따르는 큐에서 데이터를 추출해서 적용하는 것이므로, JMS, C, C++, PLSQL, SOAP (XML/HTTP) 등 어떠한 프로그래밍 방법을 통해서 적용되는 것이 가능하다. 원본 데이터베이스에서 변경된 레코드를 도착지 데이터베이스에서 적용하려고 할 때, 두 데이터를 동시에 변경하면 충돌이 일어날 경우가 있는데, 이 경우 자동적으로 데이터 충돌을 확인해 만약 미리 정의된 해결 루틴이 있다면 그 방법대로 적용하고 해결 루틴이 실패한다면 에러 큐에 저장해 어떠한 경우라도 데이터의 유실이 없도록 한다.

<그림 6> Apply 프로세스

◆ apply 진행 과정
[1] propagation 프로세스에 의해서 도착지 서버의 큐에 도달한 데이터를 apply 프로세스에 의해서 도착지 데이터베이스에 적용한다(ora_annn_SID).
[2] 이때 apply에서 적용하는 핸들러들에 의해서 각 단계나 액션별로 특정 로직을 첨가해 적용되는 데이터에 대한 조작이 가능하다. 
[3] apply 핸들러를 거쳐서 해당 테이블에 최종적으로 적용된다. 

Apply 핸들러
핸들러에는 다음과 같은 5가지 사항으로 생각해 볼 수 있다.

[1] 메시지 핸들러 : 사용자 메시지(Non-LCR) 처리를 전용하는 핸들러
[2] Pre-commit 핸들러 : commit시의 로직 처리할 때 사용하는 핸들러
[3] DML/DDL 핸들러 : Insert/update/delete/DDL 처리에 적용하는 핸들러
[4] Conflict 핸들러 : Apply 적용시 발생하는 데이터 충돌을 해결하는 핸들러 정의이다. 즉 여러 가지 발생할 수 있는 에러를 위한 해결 로직을 구현해 발생할 수 있는 에러를 해결할 수 있도록 한다.
[5] 에러 핸들러 : Apply 적용시 발생하는 에러에 대한 처리 로직을 등록해 사용할 수 있다. 다만 에러 핸들러와 DML 핸들러는 동시에 사용할 수 없다.

<그림 7>Apply 핸들러

스트림 적용 
데이터 충돌 
다음의 <그림 7>과 같이 동시에 서울 데이터베이스와 부산 데이터베이스에서 사원번호가 115번인 사람의 manager_id를 변경했을 경우 서울에서 변경된 사항이 리두 로그에 적용되고 캡처에 의해서 큐에 저장되고, propagation에 의해서 부산 데이터베이스의 큐에 도착하고, apply 프로세스에 의해서 적용되려고 할 때, 이때 부산 데이터베이스의 사원번호 115번이 이미 다른 것으로 변경돼 있는 경우 데이터 충돌이 발생한다. 

<그림 8> 서울과 부산에서의 스트림 적용

<그림 9>오라클 다운 스트림

좀 더 자세히 살펴보면 다음과 같다. 

[1] 소스 사이트에서 데이터를 가져올 때부터 변경되기 전인 old value(manager_id= 100이라고 가정)와 변경된 후인 new value(manager_id=120) 둘 다의 정보(old, new)를 갖고 타겟 사이트로 온다. 
[2] 타겟 사이트에서 해당 건(사원번호 115번)의 현재 value(manager_id=108)와 old value(manager_id=100)를 비교한다. 
[3] 만약 매치한다면 new value로 적용한다. 
[4] 만약 매치가 되지 않는다면, conflict resolution 메쏘드를 이용해 적용을 시도한다. 이때 사용하는 resolution 메쏘드는 timestamp 방식(시간 기준), maximum/minimum value 방식, overwrite(소스 사이트 우선), discard(타겟 사이트 우선), user defined 방식이 있다. 
[5] 만약 resolution 메쏘드로 해결되지 않거나 해결 루틴 자체가 없을 경우 정상적으로 적용되지 못하므로 에러 큐에 저장되어져 DBA의 수동적인 처리를 따르게 된다. 

또한 스트림의 적용 환경은 다음과 같다.

[1] 오라클9i R2 이상 버전(9.2.0.3 이상 추천), 특히 오라클10g에서는 다운 스트림이 적용 가능
스트림은 오라클9i R2의 기본 기능으로 오라클9i R2를 설치하면 스트림을 사용할 수 있는 소프트웨어 및 데이터베이스 내부의 객체는 모두 설치된다. 즉 다른 스크립트를 수행해줄 필요가 없으며 DBMS 설치 후 즉시 사용 가능하며, DBMS 기본 기능임으로 추가적인 비용이 들지 않는다.
[2] 아카이브 로그 모드로 셋업 
캡처 프로세스는 일반적으로 온라인 리두 로그를 읽어서 변경을 Capturing하지만 RAC 환경이나 캡처 프로세스가 다운된 후 재 시작될 때 아카이브 로그 파일을 액세스하는 경우가 있다. 그러므로 소스가 되는 데이터베이스는 반드시 아카이브 로그로 운영되어야 한다.
[3] Initialization 파라미터
Global_names = true(네트워크상에서 unique 오라클을 설정하기 위해 db link를 생성할 때 리모트 데이터베이스의 global_name으로 만들도록 제약을 가하는 파라미터) 

JOB_QUEUE_PROCESSES = 10 
AQ_TM_PROCESSES = 2
STREAMS_POOL_SIZE = 200m

다운 스트림
오라클9i R2에 소개된 스트림은 소스 사이트에서 Capturing을 해 타겟으로 전달해 타겟 사이트가 적용하는 방식의 구조이다. 이 경우 보통 소스 사이트는 주요한 레거시 업무를 처리하고, 타겟 사이트는 DW 등과 같은 쿼리 전용 업무를 운영할 경우가 많다. 주요한 레거시 시스템의 캡처 부하를 없애기 위해서 오라클10g부터는 타겟 사이트에서 직접 캡처를 할 수 있는 다운 스트림 캡처를 제공하기 때문에 소스 사이트의 부하를 획기적으로 줄였다. 

[1] 처리 방식 
로그 트랜스포트 메쏘드(Log transport method)나 FTP와 유사한 방식으로 소스 사이트의 리두 로그를 타겟 사이트로 이동한 후 캡처하는 것이다. 고로 연관된 객체, logminer session, queues, rules, capture process가 타겟 사이트에 생성된다. 특히 소스 사이트에서 하는 일은 리두 로그를 타겟 사이트로 이동시키는 것만 담당하기 때문에 시스템 부하가 거의 없다. 

[2] 장점 
소스 사이트의 부하를 거의 완전히 없앨 수 있다. 또한 캡처 프로세스 관리가 용이하다(여러 개의 다른 소스 사이트의 로그를 캡처하고 제어할 수 있음). 그리고 소스 사이트의 장애에 대한 추가적인 보호 장치로서 역할을 한다.

[3] 제약 사항 
리두 로그 파일, 아카이브 로그 파일을 다른 시스템으로 전송해야 하므로 같은 OS, 오라클10g이어야 한다. 단, 다운 스트림 후 또 다른 타겟 사이트에 전송한다면 스트림의 일반 특성과 마찬가지로 같은 OS일 필요는 없다.

◆ Support 타입
[1] support datatype 
CHAR , NCHAR
VARCHAR2, NVARCHAR2,
NUMBER,
DATE,
RAW,
BLOB, CLOB , NCLOB
TIMESTAMP 
LONG, LONG RAW, UROWID columns 
UROWID columns
BINARY_FLOAT and BINARY_DOUBLE columns -- 오라클10g부터 생긴 데이터 타입
Index organized tables (IOTs): 예외 LOB, overflow segment, partition IOT,
Tables that use function-based & descending indexes

[2] Unsupport datatype 
BFILE, Unicode CLOBs,
ROWID
Changes to SYS objects, Changes to SYSTEM objects,
Temporary Objects,
Simple and nested user-defined datatypes,
Collections (REFs, nested tables and VARRAYs),
XML Type,
Object REFs, 
CREATE TABLE AS SELECT of a table with a clustered key,
Spatial datatypes

데이터 공유 기술 중 최고의 기능을 활용
데이터 공유의 요구가 증가하는 IT 환경에서 오라클의 스트림 기술은 기본적으로 DB 기본 기능에 포함되어 있으므로, 비용이 추가적으로 더 들지 않으면서도 데이터 통합, 데이터 공유의 요구를 완벽히 이룰 수 있다. 더군다나 빠른 처리 메커니즘이나 아주 유연한 변환 기능은 다른 상용 제품을 완전히 대체할 수 있다. 데이터 통합이 주요한 이슈이거나, 기존 시스템에 부하 없이 데이터를 가져오고 싶을 때 활용할 수 있으며, 오라클 데이터 공유 기술 중에 최고의 성능과 기능을 가진 오라클 스트림을 많이 활용해 보길 바란다. 

그리드 컴퓨팅 적용으로 IT 과제 해결
TenG 주식회사의 ‘그리드 TFT 팀’은 IT 시스템을 오라클10g를 적용하기로 결정해 나가는 과정에서 여러 기술적인 요건을 살펴봤다. 또한 그리드 컴퓨팅에 대해 다양한 개념을 접하고 있는 상태이다. 온 디맨드 비즈니스, 어댑티브 비즈니스, 유틸리티 컴퓨팅 등 많은 새로운 컴퓨팅 환경 중에 유독 ‘그리드 컴퓨팅’이 가장 주목받고 있는 이유는 무엇인가? 그 배경에는 크게 두 가지 이유가 있다. 첫 번째는 자원의 효과적 활용, 두 번째는 IT의 복잡성을 줄일 수 있기 때문이다. 

첫 번째, ‘자원의 효율적 활용’은 그리드 컴퓨팅의 기본 개념이라고 볼 수 있다. 즉 표준화되고 모듈화된 스토리지와 서버들을 하나의 풀(pool)로 만들어 놓고 이를 총체적으로 자동 관리하도록 한다는 것이다. 두 번째 ‘IT의 복잡성을 줄인다’는 측면에서 봐도 그리드 컴퓨팅은 IT 인프라의 고립화, 복잡화의 문제점을 해결해 줄 수 있는 실현 가능한 대안이 되고 있는 것이다. 

<그림 10> 인포메이션 아키텍처와 그리드 컴퓨팅과의 관계

이와 같이 데이터베이스 선택 기준이 그리드 컴퓨팅이 되는 것이다. 오라클10g는 그리드의 개념을 데이터베이스 선택기준으로 제시하며 다음과 같은 특성이 기업의 기존 인프라를 그리드 환경으로 전환하도록 지원한다. 

[1] 프로비저닝 
[2] 리소스 풀링 및 가상화 
[3] 양질의 서비스
[4] 관리의 편이성

<표 1> 그리드 컴퓨팅을 통한 기업 IT 과제의 해결

TenG 주식회사와 같이 시스템 중단이 없는 기업 인프라를 갖추고자 한다면 인포메이션 아키텍처를 구성하면서 향후 컴퓨팅 환경의 가장 주요한 변환 추세인 그리드 컴퓨팅을 기업 내에 적용해 나가며 <표 1>과 같은 IT 과제를 해결할 수 있을 것이다. @

[Replication vs. 스트림]

시스템 오버헤드의 감소 이전의 replication 방식은 복제가 설정된 테이블 하나하나 마다 inner-trigger, 패키지를 이용해 트랜잭션이 발생할 때마다 inner-trigger, 패키지가 구동되는 메커니즘을 갖고 있어 오버헤드를 수반하는 방식이었다. 그러나 스트림 방식은 DB 운영 중에 기본적으로 생기는 리두 로그 파일에서 변경된 것만 캡처하고, 또한 데이터베이스 코어 프로세스가 아닌 별도의 캡처 프로세스를 활용함으로 시스템의 로드를 줄인다. 또한 매번 발생하는 트랜잭션마다의 처리가 아니라 리두 로그 파일 단위의 async한 처리 위주임으로 일의 양이 대폭 줄어든다. 더군다나 오라클10g의 다운 스트림을 이용한다면 시스템의 오버헤드를 더 줄일 수 있다. exp/imp/data pump 사용 가능 이전의 replication 방식은 새로운 사이트가 생기거나 데이터를 이동할 경우 exp/imp 등과 같은 bulk 작업이 원활 하지 않았으나, 스트림은 exp/imp/data pump와 같은 기능들을 아무런 제한 없이 사용하는 것이 가능하다. 이전에는 100만건 정도의 데이터를 초기 셋업하는데 10시간 정도 걸렸다면, 스트림에서 pump를 사용하면 1분 이내에 처리가 될 수 있다. transformation 기능 제공 이전의 replication 방식은 단순한 데이터 복제를 하거나 부분 집합 정도의 처리밖에 하지 못했으나, 스트림은 transformation 기능을 이용하거나 apply시 핸들러를 이용한 로직 처리를 통해서 데이터 포맷의 변경, 데이터 처리의 변환까지 가능하다. 데이터 integrate 차원의 기능을 지원한다. DDL 처리시에도 복제 가능 이전의 replication 방식은 멀티 마스터 환경에서만 DDL 변경이 가능했고, 또 이 경우에도 복제 환경을 정지시키고서야 가능했다. 그러나 스트림에서는 복제 환경이 계속되고 있는 상태에서 DDL 처리를 할 수 있다. 이전 방식의 셋업 환경보다 획기적으로 개선됐다. 다른 데이터베이스와 강력한 통합 이전의 replication 방식에서도 이기종과의 통합이 가능했으나 그 제약사항이 많았다. 그러나 스트림에서는 transparent 게이트웨이 및 generic connectivity를 이용해 이기종 DBMS와의 연동을 아주 쉽고 강력하게 이룰 수 있다. 이기종 DBMS에서 어댑터 프로그램을 이용하거나 사용자 프로그램을 이용해서 데이터를 캡처해 낼 수도 있으며, apply시 게이트웨이나 자바 프로그램을 통해서 이기종 DBMS에 적용시키는 것도 가능하다.

[지디넷코리아]최근 흩어져 있는 데이터를 공유하는 것에 대한 논의가 활발히 이뤄지고 있다. 특히 원거리의 분산환경 상의 정보뿐만 아니라 서로 성격을 달리하는 정보들(DW, CRM, 인사, 회계 등)간의 긴밀한 데이터 통합이 필수적이다. 이런 요구가 생기는 것은 기업 환경의 급격한 변화에 기인하고 있다. 기업에서는 회사의 업무 우선 순위의 변경이라든지 업무요구의 변화에 따라 자체 자원 조정의 요구에 종종 직면하게 된다. 오라클10g에서는 급격한 변화 요구에 따른 회사 자원의 손쉬운 조정을 가능하게 하는 완벽한 그리드 컴퓨팅 솔루션을 제공한다. 정보 프로비저닝(provisioning)은 분산환경하에서 언제 어디서든지 필요로 하는 정보의 접근을 가능케 하는 그리드 솔루션의 중요한 구성요소이다. 

원하는 곳, 필요한 때에 데이터 얻기
그리드 컴퓨팅은 필요로 하는 자원의 동적 재배치와 가상화를 통한 조정의 어려움을 배제할 수 있다. 정보는 필요로 하는 곳에 반드시 제공되어야 하는 중요한 자원 중 하나이다. 원하는 곳, 필요로 하는 때에 데이터를 얻기 위해서 매우 정교한 정보 프로비저닝 기술이 요구된다. 이러한 프로비저닝 기술은 정보의 물리적인 위치와 상관없이 필요로 하는 시기와 장소에 최적의 정보를 얻을 수 있도록 한다. 그리드 내의 분산 환경이거나 독립형 시스템, 다수의 그리드에 걸쳐 있는 정보를 통합한다. 

정보를 공유하면 사용자가 필요로 할 경우 그것이 어디에 저장되어 있는지 알 필요 없이 정보를 취득할 수 있다. 정보가 어떤 가용 자원상에 있는지 관계없이 처리하기 위해서 그리드는 다수의 시스템에 걸쳐 효율적으로 정보를 공유해야 한다. 그리드는 이기종의 시스템에 있는 데이터 액세스까지도 제공해야만 한다.

오라클10g에서는 분산 SQL, 메시지 큐잉과 복제 기능을 포함한 데이터 공유를 위한 단일 통합환경을 제공하는 오라클 스트림(Streams), 오라클 환경으로부터 non-오라클 시스템의 데이터 접근을 허용하는 ‘투명한 게이트웨이’와 transportable tablespace, data pump 등을 이용한 대규모 데이터 이동 기술을 이용한 정보 프로비저닝 기능을 갖고 있다. 

그 중 오라클에서 제시하는 정보 공유(information sharing) 기법들 중 오라클 스트림에 대해서 자세히 알아보도록 하겠다. 오라클 스트림은 오라클9i R2부터 소개된 정보 공유 기능이다. 오라클 스트림은 데이터베이스 내 또는 하나의 데이터베이스에서 다른 데이터베이스로 데이터(데이터, 트랜잭션 및 이벤트)를 전달할 수 있도록 지원한다. 

예를 들어 스트림을 사용해 데이터베이스 객체의 DML 및 DDL 변경 사항을 이벤트로 캡처할 수 있다. 그런 다음 데이터베이스 객체를 다른 데이터베이스로 효율적으로 복제해 이러한 이벤트를 다른 데이터베이스에 전달할 수 있다. 또한 같은 오라클 버전, OS, 플랫폼과 같은 제한사항이 없으며, 또한 게이트웨이를 사용해 이기종 DBMS(Heterogeneous DBMS; DB2, SQL 서버, 사이베이스 등)와의 연동까지도 가능하다. 

<그림 1> 오라클 스트림

활용방안
데이터 복제 기능 활용
현재의 시스템 환경은 데이터와 인터넷 환경을 통한 사용자의 급격한 증가에 직면하고 있는 상황이다. 고로 OLTP로 운영되는 메인 시스템 같은 경우 피크 타임(peak time)시의 부하량 증가 및 배치 작업시의 OLTP와 대규모 쿼리성 작업의 병목현상으로 인한 문제가 심각하다. 이 경우 보통 OLTP 시스템의 물리적인 증가(CPU, 메모리 증가)를 통해서 문제를 해결하던지 제한적이나마 튜닝을 통해서 해결될 수 있지만, 너무 많은 비용의 소요와 제한적인 해결책이라고 할 수 있다.

OLTP에서 생기는 막대한 데이터들은 배치/리포트용 시스템, fail-over 시스템, 분석 시스템으로 Near Real time으로 이동시키는 것이 가능하다면, 또한 이런 작업을 할 때 OLTP에 부하를 주지 않을 수만 있다면 OLTP 시스템의 안정화, 소규모 투자를 통한 분석/리포트 시스템 구축이라는 두 마리 토끼를 한꺼번에 잡을 수 있다.

현재 이런 작업은 여러 산업 분야에서 사용되고 있으며, 그 중 반도체 생산시스템 분야의 생산 레거시 시스템에서 분석 시스템으로의 데이터 이동 처리 업무에 파일롯 형태로 검토하고 있다. 

데이터 웨어하우스 로딩 사용
OLTP에서 DW 시스템으로 데이터를 이동시키는 전통적인 방법은 배치 프로그램을 통한 하루에 한 두 번씩의 대규모 SQL문의 수행이었다. 그러나 새롭게 개선된 오라클 스트림을 사용하면 OLTP 시스템에 부하 없이 리두 로그 파일의 변경된 내용만을 전달하는 것이 가능하고, 또한 리두 로그 파일이 거의 실시간에 데이터가 생기는 속성으로 인해서 근접 실시간 데이터 이동이 가능하다. 현재의 RTE(Real Time Enterprise) 환경에서 가장 중요한 기능이 제공된다.

현재의 진화하는 DW 시스템은 예전의 오래된 데이터를 누적해서 분석하는 차원에서 진일보해 실시간으로 파악되는 현황을 토대로 분석하는 응용된 DW 시스템으로 나아가고 있다. 몇 일전 혹은 몇 년 전의 가격 추이도 중요한 정보지만 지금 당장의 판매 현황, 판매 추이 분석이 더 중요한 기업환경에서 DW의 ETT 작업에 스트림을 활용할 수 있다. 

메시지 큐잉 기능의 활용
단순한 데이터의 이동뿐만 아니라 하나의 운영 시스템에서의 특정 데이터를 대상으로 다른 복수의 시스템으로 복수의 변형된 데이터로 변환해 전송할 수 있다. 예를 들면 생산시스템에서 회계 시스템, 판매 시스템, 분석 시스템, DW 시스템, CRM 시스템, EIS 시스템 등 다수의 데이터가 필요한 곳으로 보낼 수도 있고, 필요에 의해서 원본 데이터에서 변형된 형태로 데이터를 보낼 수 있다. 오라클 큐잉 매커니즘을 사용하기 때문에 안정적으로 사용되며, 현 업무에서 적용 가능한 데이터 통합(integration) 시스템의 구축도 가능하다. 보통의 메시지를 이용하는 EAI 솔루션과 동일 수준의 데이터 관리, 이벤트 처리가 가능하며 더불어 데이터베이스의 안정성까지 추가적으로 보장한다.

분산환경에서의 데이터 복제 가능
중앙 집중적인 통합 시스템의 문제로 인한 분산환경으로 시스템이 구축돼 있을 경우 서로 공유하는 데이터에 대해서는 분산 복제 기능을 사용해 데이터의 정확성을 맞춰야 하는데, 이 경우 과거 버전의 오라클에서는 db_link, trigger, replication 등의 방법을 이용했다. 이런 방법들은 발표될 시점에서는 아주 강력하고 손쉬운 방법이었으나, 지금은 셋업의 불편, 퍼포먼스의 문제 등으로 인해 그 사용이 제한적인 상태이다. 스트림을 이용한 데이터 복제는 기존의 오라클 데이터 공유(data sharing) 방법에서 할 수 있는 양방향 복제, 데이터 충돌에 따른 resolution, 이기종 DBMS와의 연동뿐만 아니라 더 빠른 속도와 네트워크 부하의 감소, 더 간편한 셋업(configuration)이 가능하다. 

고가용성 솔루션
원본 시스템의 전체 데이터베이스를 백업 시스템으로 near real time으로 이동시킨다면 원본 시스템의 장애시 백업 시스템을 즉시 활용하는 것이 가능하다. 즉 원격지에서의 데이터 보호를 위한 솔루션인 재난복구(DR) 시스템으로도 사용이 가능하다.

스트림 구조
스트림은 오라클9i R2에 소개된 것으로 Logminer(리두 로그 파일 분석기)의 기능을 이용해 리두 로그 파일/아카이브 파일(Archive File)을 읽어서 원하는 테이블, 스키마 혹은 전체 데이터베이스의 변경사항을 캡처해 리모트 데이터베이스(Remote Database)로 전달해 적용한다. 

이러한 방식으로 원격지 데이터베이스간의 정보 공유를 지원하며, 또한 스트림은 전달하는 과정에서 소스 변경사항 이외의 추가적인 변경이나 정보를 맵핑해 타겟 데이터베이스에 반영할 수 있는 트랜스포메이션(transformation) 기능도 지원한다.

<그림 2> 스트림 아키텍처

<그림 3> 3대 기본 요소

캡처
원래 오라클 데이터베이스의 변경은 모두 리두 로그 파일로 기록된다. 이 리두 로그 파일은 향후 복구시 이용될 수 있도록 데이터베이스의 변경 내역을 담고 있으며, 또 아카이브 프로세스에 의해서 리두 로그 파일이 arch 로그 파일로 복사된다.

캡처 프로세스는 소스 데이터베이스의 리두 로그 & 아카이브 로그의의 변동 사항을 읽어서 등록된 객체의 변경사항(DML, DDL)이 있으면 리두 로그 포맷을 LCR 포맷으로 변경해 송신 큐에 넣어 주는 역할을 한다. 즉 리두 로그 파일에 있는 변경된 사항만을 캡처해 LCR이라는 형태로 변환시켜 송신 큐에 넣어주는 역할을 하며 캡처 시작(capture start)에 의해서 ora_cnnn_sid라는 백그라운드 프로세스가 실질적인 작업을 한다. 캡처 프로세스는 buffered 큐 형태의 Sys.AnyData라는 데이터 타입을 이용해 LCR 형태로 저장한다. 스트림에서는 모든 사용자 메시지를 SYS.AnyData 타입으로 랩핑(wrapping)해 전달한다.

<그림 4> 캡처 프로세스

◆ 캡처 진행 과정
[1] 사용자에 의해서 dept 테이블에 변경 요청이 들어옴
[2] 오라클 DBMS는 dept 테이블을 수정하고, 그와 동시에 리두 로그 파일에도 그 내용을 저장함 
[3] 캡처 프로세스는 리두 로그 파일을 분석해 LCR 포맷의 형태로 전환해 SGA 메모리 영역의 buffered 큐에 저장함(ora_cnnn_sid).
[4] 캡처할 때 규칙에 의한 평가, 변환 작업을 수행할 수도 있다(evaluation & transformation).

Staging & Propagation 
소스 데이터베이스 대기열의 변경 사항을 도착지 데이터베이스의 대기열로 전달한다. 도착지(destination) 데이터베이스의 큐에 반영하기 위해 스케줄링을 한다. Staging area는 캡처된 이벤트에 대한 저장, 관리 서비스를 제공하는 큐 매커니즘이다. 동일한 데이터베이스나 다른 데이터베이스에 존재하는 또 다른 staging area로 전달(propagation)될 수 있으며 네트워크 라우팅의 간소화와 트래픽의 감소를 위해 모든 데이터베이스와 애플리케이션에 바로 보낼 필요 없이 일단 일종의 허브 데이터베이스(실제로 적용은 하지 않는)로 전달할 수 있다.

일반적인 큐잉 시스템이 제공하는 데이터의 유실(loss)을 절대로 허용하지 않기 때문에 도착지 사이트에 전달되기 전까지는 큐에 남아있어 데이터 유실이 전혀 있을 수 없다. 또한 표준 방식을 통해 핸들링되므로 PL/SQL, JMS, OCI 프로그래밍 등 일반적인 프로그래밍 방식을 통해서 사용자 프로그램이 enqueue 메시지 처리를 할 수 있다. 

<그림 5> 소스 큐와 Destination 큐

◆ Propagation의 진행 과정
[1] 캡처에 의해서 만들어진 LCR 포맷 데이터나 사용자 프로그램에 의해서 만들어진 사용자 메시지가 큐에 저장된다. 
[2] DBMS_job 또는 DBMS_schedule에 의해 등록된 propagation을 처리하는 job이 설정된 값에 따라(1초부터 초단위로 간격 조정 가능) 큐에서 데이터를 읽어 목적지(도착지) 시스템의 큐에 짚어 넣는다.
[3] 이때 사용되는 큐 테이블은 SGA의 메모리 영역에 있는 것으로서 메모리 사이의 I/O를 수행하기 때문에 빠른 처리 속도를 가진다. 만약 할당된 메모리 영역이 부족할 경우는 스트림을 지원하는 테이블스페이스(디스크)에 저장되어, 데이터 유실이 없도록 하는 안정장치를 갖고 있다. 메모리에서 propagation 작업이 이뤄지다가 아직 도착하지 못한 데이터가 있는 상태에서 DBMS의 갑작스런 정지 상황이 생기면 다시 startup될 때 캡처 프로세스에 의해서 소스 큐에 미 전달된 데이터의 정보를 파악해 다시 큐잉 작업을 수행해 도착지 DBMS에 가는 작업을 자동적으로 수행한다. 

APPLY
Staging area에 있는 이벤트는 apply 프로세스에 의해 소비(consumption)되어, 데이터베이스 내에서 SQL문 형태로 적용되던지, 또는 사용자 메시지의 경우 애플리케이션에 의해서 도착지 데이터베이스에 적용된다. 이때 빠른 처리를 위해서 병렬 apply 서버 셋업이 가능하다. 

결국 범용적인 표준을 따르는 큐에서 데이터를 추출해서 적용하는 것이므로, JMS, C, C++, PLSQL, SOAP (XML/HTTP) 등 어떠한 프로그래밍 방법을 통해서 적용되는 것이 가능하다. 원본 데이터베이스에서 변경된 레코드를 도착지 데이터베이스에서 적용하려고 할 때, 두 데이터를 동시에 변경하면 충돌이 일어날 경우가 있는데, 이 경우 자동적으로 데이터 충돌을 확인해 만약 미리 정의된 해결 루틴이 있다면 그 방법대로 적용하고 해결 루틴이 실패한다면 에러 큐에 저장해 어떠한 경우라도 데이터의 유실이 없도록 한다.

<그림 6> Apply 프로세스

◆ apply 진행 과정
[1] propagation 프로세스에 의해서 도착지 서버의 큐에 도달한 데이터를 apply 프로세스에 의해서 도착지 데이터베이스에 적용한다(ora_annn_SID).
[2] 이때 apply에서 적용하는 핸들러들에 의해서 각 단계나 액션별로 특정 로직을 첨가해 적용되는 데이터에 대한 조작이 가능하다. 
[3] apply 핸들러를 거쳐서 해당 테이블에 최종적으로 적용된다. 

Apply 핸들러
핸들러에는 다음과 같은 5가지 사항으로 생각해 볼 수 있다.

[1] 메시지 핸들러 : 사용자 메시지(Non-LCR) 처리를 전용하는 핸들러
[2] Pre-commit 핸들러 : commit시의 로직 처리할 때 사용하는 핸들러
[3] DML/DDL 핸들러 : Insert/update/delete/DDL 처리에 적용하는 핸들러
[4] Conflict 핸들러 : Apply 적용시 발생하는 데이터 충돌을 해결하는 핸들러 정의이다. 즉 여러 가지 발생할 수 있는 에러를 위한 해결 로직을 구현해 발생할 수 있는 에러를 해결할 수 있도록 한다.
[5] 에러 핸들러 : Apply 적용시 발생하는 에러에 대한 처리 로직을 등록해 사용할 수 있다. 다만 에러 핸들러와 DML 핸들러는 동시에 사용할 수 없다.

<그림 7>Apply 핸들러

스트림 적용 
데이터 충돌 
다음의 <그림 7>과 같이 동시에 서울 데이터베이스와 부산 데이터베이스에서 사원번호가 115번인 사람의 manager_id를 변경했을 경우 서울에서 변경된 사항이 리두 로그에 적용되고 캡처에 의해서 큐에 저장되고, propagation에 의해서 부산 데이터베이스의 큐에 도착하고, apply 프로세스에 의해서 적용되려고 할 때, 이때 부산 데이터베이스의 사원번호 115번이 이미 다른 것으로 변경돼 있는 경우 데이터 충돌이 발생한다. 

<그림 8> 서울과 부산에서의 스트림 적용

<그림 9>오라클 다운 스트림

좀 더 자세히 살펴보면 다음과 같다. 

[1] 소스 사이트에서 데이터를 가져올 때부터 변경되기 전인 old value(manager_id= 100이라고 가정)와 변경된 후인 new value(manager_id=120) 둘 다의 정보(old, new)를 갖고 타겟 사이트로 온다. 
[2] 타겟 사이트에서 해당 건(사원번호 115번)의 현재 value(manager_id=108)와 old value(manager_id=100)를 비교한다. 
[3] 만약 매치한다면 new value로 적용한다. 
[4] 만약 매치가 되지 않는다면, conflict resolution 메쏘드를 이용해 적용을 시도한다. 이때 사용하는 resolution 메쏘드는 timestamp 방식(시간 기준), maximum/minimum value 방식, overwrite(소스 사이트 우선), discard(타겟 사이트 우선), user defined 방식이 있다. 
[5] 만약 resolution 메쏘드로 해결되지 않거나 해결 루틴 자체가 없을 경우 정상적으로 적용되지 못하므로 에러 큐에 저장되어져 DBA의 수동적인 처리를 따르게 된다. 

또한 스트림의 적용 환경은 다음과 같다.

[1] 오라클9i R2 이상 버전(9.2.0.3 이상 추천), 특히 오라클10g에서는 다운 스트림이 적용 가능
스트림은 오라클9i R2의 기본 기능으로 오라클9i R2를 설치하면 스트림을 사용할 수 있는 소프트웨어 및 데이터베이스 내부의 객체는 모두 설치된다. 즉 다른 스크립트를 수행해줄 필요가 없으며 DBMS 설치 후 즉시 사용 가능하며, DBMS 기본 기능임으로 추가적인 비용이 들지 않는다.
[2] 아카이브 로그 모드로 셋업 
캡처 프로세스는 일반적으로 온라인 리두 로그를 읽어서 변경을 Capturing하지만 RAC 환경이나 캡처 프로세스가 다운된 후 재 시작될 때 아카이브 로그 파일을 액세스하는 경우가 있다. 그러므로 소스가 되는 데이터베이스는 반드시 아카이브 로그로 운영되어야 한다.
[3] Initialization 파라미터
Global_names = true(네트워크상에서 unique 오라클을 설정하기 위해 db link를 생성할 때 리모트 데이터베이스의 global_name으로 만들도록 제약을 가하는 파라미터) 

JOB_QUEUE_PROCESSES = 10 
AQ_TM_PROCESSES = 2
STREAMS_POOL_SIZE = 200m

다운 스트림
오라클9i R2에 소개된 스트림은 소스 사이트에서 Capturing을 해 타겟으로 전달해 타겟 사이트가 적용하는 방식의 구조이다. 이 경우 보통 소스 사이트는 주요한 레거시 업무를 처리하고, 타겟 사이트는 DW 등과 같은 쿼리 전용 업무를 운영할 경우가 많다. 주요한 레거시 시스템의 캡처 부하를 없애기 위해서 오라클10g부터는 타겟 사이트에서 직접 캡처를 할 수 있는 다운 스트림 캡처를 제공하기 때문에 소스 사이트의 부하를 획기적으로 줄였다. 

[1] 처리 방식 
로그 트랜스포트 메쏘드(Log transport method)나 FTP와 유사한 방식으로 소스 사이트의 리두 로그를 타겟 사이트로 이동한 후 캡처하는 것이다. 고로 연관된 객체, logminer session, queues, rules, capture process가 타겟 사이트에 생성된다. 특히 소스 사이트에서 하는 일은 리두 로그를 타겟 사이트로 이동시키는 것만 담당하기 때문에 시스템 부하가 거의 없다. 

[2] 장점 
소스 사이트의 부하를 거의 완전히 없앨 수 있다. 또한 캡처 프로세스 관리가 용이하다(여러 개의 다른 소스 사이트의 로그를 캡처하고 제어할 수 있음). 그리고 소스 사이트의 장애에 대한 추가적인 보호 장치로서 역할을 한다.

[3] 제약 사항 
리두 로그 파일, 아카이브 로그 파일을 다른 시스템으로 전송해야 하므로 같은 OS, 오라클10g이어야 한다. 단, 다운 스트림 후 또 다른 타겟 사이트에 전송한다면 스트림의 일반 특성과 마찬가지로 같은 OS일 필요는 없다.

◆ Support 타입
[1] support datatype 
CHAR , NCHAR
VARCHAR2, NVARCHAR2,
NUMBER,
DATE,
RAW,
BLOB, CLOB , NCLOB
TIMESTAMP 
LONG, LONG RAW, UROWID columns 
UROWID columns
BINARY_FLOAT and BINARY_DOUBLE columns -- 오라클10g부터 생긴 데이터 타입
Index organized tables (IOTs): 예외 LOB, overflow segment, partition IOT,
Tables that use function-based & descending indexes

[2] Unsupport datatype 
BFILE, Unicode CLOBs,
ROWID
Changes to SYS objects, Changes to SYSTEM objects,
Temporary Objects,
Simple and nested user-defined datatypes,
Collections (REFs, nested tables and VARRAYs),
XML Type,
Object REFs, 
CREATE TABLE AS SELECT of a table with a clustered key,
Spatial datatypes

데이터 공유 기술 중 최고의 기능을 활용
데이터 공유의 요구가 증가하는 IT 환경에서 오라클의 스트림 기술은 기본적으로 DB 기본 기능에 포함되어 있으므로, 비용이 추가적으로 더 들지 않으면서도 데이터 통합, 데이터 공유의 요구를 완벽히 이룰 수 있다. 더군다나 빠른 처리 메커니즘이나 아주 유연한 변환 기능은 다른 상용 제품을 완전히 대체할 수 있다. 데이터 통합이 주요한 이슈이거나, 기존 시스템에 부하 없이 데이터를 가져오고 싶을 때 활용할 수 있으며, 오라클 데이터 공유 기술 중에 최고의 성능과 기능을 가진 오라클 스트림을 많이 활용해 보길 바란다. 

그리드 컴퓨팅 적용으로 IT 과제 해결
TenG 주식회사의 ‘그리드 TFT 팀’은 IT 시스템을 오라클10g를 적용하기로 결정해 나가는 과정에서 여러 기술적인 요건을 살펴봤다. 또한 그리드 컴퓨팅에 대해 다양한 개념을 접하고 있는 상태이다. 온 디맨드 비즈니스, 어댑티브 비즈니스, 유틸리티 컴퓨팅 등 많은 새로운 컴퓨팅 환경 중에 유독 ‘그리드 컴퓨팅’이 가장 주목받고 있는 이유는 무엇인가? 그 배경에는 크게 두 가지 이유가 있다. 첫 번째는 자원의 효과적 활용, 두 번째는 IT의 복잡성을 줄일 수 있기 때문이다. 

첫 번째, ‘자원의 효율적 활용’은 그리드 컴퓨팅의 기본 개념이라고 볼 수 있다. 즉 표준화되고 모듈화된 스토리지와 서버들을 하나의 풀(pool)로 만들어 놓고 이를 총체적으로 자동 관리하도록 한다는 것이다. 두 번째 ‘IT의 복잡성을 줄인다’는 측면에서 봐도 그리드 컴퓨팅은 IT 인프라의 고립화, 복잡화의 문제점을 해결해 줄 수 있는 실현 가능한 대안이 되고 있는 것이다. 

<그림 10> 인포메이션 아키텍처와 그리드 컴퓨팅과의 관계

이와 같이 데이터베이스 선택 기준이 그리드 컴퓨팅이 되는 것이다. 오라클10g는 그리드의 개념을 데이터베이스 선택기준으로 제시하며 다음과 같은 특성이 기업의 기존 인프라를 그리드 환경으로 전환하도록 지원한다. 

[1] 프로비저닝 
[2] 리소스 풀링 및 가상화 
[3] 양질의 서비스
[4] 관리의 편이성

<표 1> 그리드 컴퓨팅을 통한 기업 IT 과제의 해결

TenG 주식회사와 같이 시스템 중단이 없는 기업 인프라를 갖추고자 한다면 인포메이션 아키텍처를 구성하면서 향후 컴퓨팅 환경의 가장 주요한 변환 추세인 그리드 컴퓨팅을 기업 내에 적용해 나가며 <표 1>과 같은 IT 과제를 해결할 수 있을 것이다. @

[Replication vs. 스트림]

시스템 오버헤드의 감소 이전의 replication 방식은 복제가 설정된 테이블 하나하나 마다 inner-trigger, 패키지를 이용해 트랜잭션이 발생할 때마다 inner-trigger, 패키지가 구동되는 메커니즘을 갖고 있어 오버헤드를 수반하는 방식이었다. 그러나 스트림 방식은 DB 운영 중에 기본적으로 생기는 리두 로그 파일에서 변경된 것만 캡처하고, 또한 데이터베이스 코어 프로세스가 아닌 별도의 캡처 프로세스를 활용함으로 시스템의 로드를 줄인다. 또한 매번 발생하는 트랜잭션마다의 처리가 아니라 리두 로그 파일 단위의 async한 처리 위주임으로 일의 양이 대폭 줄어든다. 더군다나 오라클10g의 다운 스트림을 이용한다면 시스템의 오버헤드를 더 줄일 수 있다. exp/imp/data pump 사용 가능 이전의 replication 방식은 새로운 사이트가 생기거나 데이터를 이동할 경우 exp/imp 등과 같은 bulk 작업이 원활 하지 않았으나, 스트림은 exp/imp/data pump와 같은 기능들을 아무런 제한 없이 사용하는 것이 가능하다. 이전에는 100만건 정도의 데이터를 초기 셋업하는데 10시간 정도 걸렸다면, 스트림에서 pump를 사용하면 1분 이내에 처리가 될 수 있다. transformation 기능 제공 이전의 replication 방식은 단순한 데이터 복제를 하거나 부분 집합 정도의 처리밖에 하지 못했으나, 스트림은 transformation 기능을 이용하거나 apply시 핸들러를 이용한 로직 처리를 통해서 데이터 포맷의 변경, 데이터 처리의 변환까지 가능하다. 데이터 integrate 차원의 기능을 지원한다. DDL 처리시에도 복제 가능 이전의 replication 방식은 멀티 마스터 환경에서만 DDL 변경이 가능했고, 또 이 경우에도 복제 환경을 정지시키고서야 가능했다. 그러나 스트림에서는 복제 환경이 계속되고 있는 상태에서 DDL 처리를 할 수 있다. 이전 방식의 셋업 환경보다 획기적으로 개선됐다. 다른 데이터베이스와 강력한 통합 이전의 replication 방식에서도 이기종과의 통합이 가능했으나 그 제약사항이 많았다. 그러나 스트림에서는 transparent 게이트웨이 및 generic connectivity를 이용해 이기종 DBMS와의 연동을 아주 쉽고 강력하게 이룰 수 있다. 이기종 DBMS에서 어댑터 프로그램을 이용하거나 사용자 프로그램을 이용해서 데이터를 캡처해 낼 수도 있으며, apply시 게이트웨이나 자바 프로그램을 통해서 이기종 DBMS에 적용시키는 것도 가능하다.