「해양기상 서비스 선진화 및 재난관리 역량향상 방안 연구」최종보고서

데이터베이스는 여러 사람에 의해 공유되어 사용될 목적으로 통합하여 관리되는 데이터의 집합 또는 그 집합을 관리하는 미들웨어로서, 오랫동안 사용된 SQL, Oracle로 대표되는 관계형 데이터베이스와 빅데이터에 대한 관심이 높아지면서 다양한 분야의 빅데이터를 처리하기 위해 고안된 비관계형 데이터베이스를 예로들 수 있다. 관계형 데이터베이스는 데이터를 열(Column)과 행(Row)으로 구성된 일종의 테이블 형태로 저장하고 데이터의 종속성은 관계(Relation)로 표현되며, 데이터 구조가 고정된 형태로 저장되기 때문에 서로 다른 테이블 간의 관계가 매우 중요한 데이터베이스이다. 비관계형 데이터베이스는 시계열데이터, 그래프데이터, 트리데이터 등의 특정 데이터 구조를 목적으로 만들어졌으며, 목적에 따라 그 특성이 다르나, 공통적으로 스키마가 없는 구조로 구조 변경이 용이한 특성을 가진다. 빅데이터를 간단히 정의하면 데이터를 수집, 저장, 처리, 검색, 공유, 분석, 시각화를 통해 대규모 데이터를 처리하는 플랫폼으로 미래 경쟁가치를 창출하는 원천으로 인정받고 있으나, 수많은 데이터의 양/종류에 따라 전체적인 기술 연계를 통한 활용이 어렵다는 문제를 가지고 있다. 하지만 빠르게 기술이 발전하고 있고, 정부차원의 지원 확대 등을 통해 다양한 분야로 시장이 확대되고 있는 기술이다. 이 중, No SQL에 대해 좀 더 상세히 설명하면, 다양한 NoSQL은 각각 시계열데이터, 그래프데이터, 트리데이터 등의 특정 데이터 구조를 목적으로 만들어진 덕분에 NoSQL마다 그 특성이 다르나, RDBMS 와는 다르게 스키마가 없는 구조로서 구조 변경시 자유롭게 필드를 추가가 가능하다는 특징이 있다. 특히, NoSQL은 많은 서버로의 확장(Scale-out)이 용이하고, NoSQL 에서는 가변적인 구조로 데이터를 저장 할 수 있으며, 데이터의 생산량이 많고 구조가 비정형인 경우에 효율적으로 데이터를 저장할 수 있는 장점을 가지고 있다. 과거에는 일반적으로 사용된 서버는 서버 1대에 운영체제를 바로 올려 가동하는 레거시 시스템을 이용했으나, 기술의 발전으로 서버 1대에 하이퍼바이저를 설치하여 복수의 OS와 업무를 가동시킬 수 있는 레거시, 가상화를 기반으로 하는 서버 기술이 이용되었다. 하이퍼바이저는 호스트 컴퓨터에서 다수의 운영체제를 동시에 실행하기 위한 논리적 플랫폼을 의미한다. 기술이 발전함에 따라 최근에는 클라우드 분산파일 시스템 기반 환경에 가상화 요소를 접목한 하이퍼 컨버지드(HCI) 형태로 변화하고 있으며 하이퍼 컨버지드의 경우 장치가 추가되는 경우에도 논리적으로 하나의 장치로 인식하여 동작하기 때문에 유지보수 및 확장이 용이한 기술이다. 해양기상지리 정보를 위한 데이터베이스(DB)를 설계하는데 있어, 다양한 곳에서 수집되는 해양·기상·지리 정보를 포함하는 데이터에 대한 데이터 정제가 필요하며, 정제된 데이터를 통합하는 격자기반의 통합 DB를 설계해야 할 것이다. 데이터의 정제 및 통합 DB 설계시 DB마다 기준이 동일하지 않기 때문에 기준(도메인)을 표준화하는 작업이 중요하나, 자료의 종류와 양이 방대하고, 관련 부처간, 사용자간 이견이 있기 때문에 별도의 과제를 통해 통합 DB를 설계하는 방안을 제안한다. 새로운 해양/기상/지리 DB를 설계할 때, 격자 정보, 시계열 정보 등 해양기상정보에 특화된 데이터 구조 설계에 유리한 NoSQL DB의 도입을 적극적으로 고려하여 최상의 데이터 관리 체계를 확보해야 할 것이다. 데이터베이스 환경을 검토하는데 있어, 데이터의 종류를 검토하여 최적의 데이터베이스를 선택하는 것이 매우 중요하다. 예를 들어, 해양기상의 특성상 수많은 종류의 해양 기상정보에 대한 시계열 데이터가 생산되고 있으므로, 해양기상정보를 처리하기 위해 InfluxDB(시계열 DB 1위 엔진)를 고려할 수 있다. 한편, 지리 정보, 격자 정보를 생성하기 위한 데이터는 일반 문서형 데이터를 이용하게 되는데 이를 위해 MongoDB(일반 문서형 데이터 DB 1위 엔진)을 고려할 수 있다. 이 밖에도 다양한 데이터베이스들이 데이터 구조와 목적에 따라 서로 다른 특성을 가지고 있기 때문에, 목적에 따라 DB를 선택할 수 있다. 현재 너울 및 월파는 여러 기관 및 연구자에 따라 기준을 정의하는 내용이 상이하기 때문에 예·경보를 위해서는 기준 마련이 우선 필요하며, 설정한 기준에 대하여 장기간 자료를 확보 분석하여 검·보정하는 과정이 필수적이다. 그러나 단일 연구로 동해안 넓은 지역의 모니터링 및 자료 축적에는 시간 및 비용적인 한계를 수반하며, 선행연구의 기준을 활용하면 향후 연구 수행에 있어서 각 기관에서 도출되는 모니터링, 분석 등의 연구 성과를 용이하게 적용할 수 있을 것이다. 또한, 파고와 주기만으로 위험 단계를 구분하고 있어 별도의 후처리 과정없이 현재 생산되고 있는 예측 및 관측정보를 적용하기에도 유리하다. 따라서, 이번 연구에서의 너울 예·경보 가이던스(안)은 과거 피해자료 분석 등의 선행연구를 통해 수립되어 시험적용 중인 너울 경보기준과 동일한 내용으로 수립하였다. 그러나 금회 제시된 너울 예·경보 가이던스(안)은 언론 피해 사례를 기초로 수립되었으며, 실제 운용·분석을 통해 적절한 범위로의 추가 조정 과정이 필요하다. 빅데이터라는 개념이 일반화되면서 데이터의 중요성은 커졌으나 취급하는 데이터의 양이 많으면 많을수록 그 결과를 이해하기 어려워져 데이터의 유용성이 떨어지는 문제점이 발생하게 된다. 데이터의 가시화는 빠르고 정확한 의사결정을 하는데 있어 중요한 요소이다. 따라서, 기상청에서 현재 취급하고 있는 해양기상정보에 기초하여 분야별 맞춤형 서비스를 제공하는데 있어 효과적인 데이터 가시화 방안을 제안한다. 현재 민간 영역에서 제공하는 Windy, Windguru, Windfinder 등의 기상 데이터를 가시화하여 제공하는 서비스 들을 참조하면, 바람, 해수의 방향과 세기를 파티클 애니메이션을 활용하여 표시함으로서 직관적으로 바람, 해수의 움직임을 보여주며, 기압, 기온 등 수치적인 데이터를 컨투어 효과를 이용하여 색상으로 구분된 형태로 표출함으로서 가시성을 높이는 구성을 기본으로 한다. 기상청에서 현재 취급하고 있는 해양기상정보의 종류가 매우 많아, 분야별 맞춤형 서비스를 제공함에 있어 기상정보를 제공하고, 어떤 정보를 시계열 자료, 수치자료, 그래프 등 어떤 형태로 제공할 것인지를 결정하는데 어려움이 따를 것으로 예상된다. 따라서 정보를 구분해서 전달하는 하는 방안이 아닌, 기상청에서 현재 취급하고 있는 모든 해양기상정보를 제공하되, 사용자가 원하는 정보를 선택할 수 있도록 하는 서비스를 제공하는 방안을 제안한다. 이 경우, 시스템의 부하를 줄이기 위해 한 번에 선택되는 기상정보의 종류를 줄이도록 하는 방안을 고려할 수 있다. 하지만 장기적인 관점에서 상기된 모든 서비스를 기상청에서 직접 서비스하는 것 보다 민간사업자와의 협력을 통해 가시화된 기상 정보를 제공하는 방안을 고려할 수 있다. 다시 말해, 기상청은 다양한 해양기상 데이터를 추가 생산하여 민간 사업자에게 제공하여 민간사업자의 예관측 데이터 생산 기반을 강화하는 방안을 제안하며 이를 위해서는 API기반의 해양기상정보의 서비스 확대가 요구된다. 관측되는 숫자, 수치를 제공하는 것과 비교하여 시계열 자료, GIS 기반의 자료 표출 등 종합적인 시각에서 분석할 수 있도록 기상정보를 제공하면 사용자의 편의성을 증대시킬 수 있을 것으로 예상되나, 모든 지역에 대하여 제공하는데 현실적인 어려움이 따를 수 있다. 이 경우, 항만, 기상부이, 등표 등을 우선적으로 선정하여, GIS 기반의 서비스를 제공할 수 있다. 다만, 기상청에서 현재 취급하고 있는 해양기상정보의 종류가 매우 많아, 분야별 맞춤형 서비스를 제공함에 있어 어떤 기상정보를 제공하고, 제공되는 기상정보를 시계열 자료, 수치자료, 그래프 등의 다양한 형태 중 어떤 형태로 제공할 것인지에 대해 선택하는데 어려움이 따를 것으로 예상된다. 따라서 정보를 구분해서 전달하는 방식이 아닌, 기상청에서 현재 취급하고 있는 모든 해양기상정보를 제공하되, 호주의 MetEye 서비스와 같이 사용자가 원하는 정보를 선택하여 표출하는 서비스의 제공을 고려할 수 있다. 이 경우, 시스템의 부하를 줄이기 위해 한 번에 선택되는 기상정보의 종류(예를 들면, 3 종류 이하)를 줄이도록 하는 방안이 고려될 수 있다.