[아이티데일리] 국내 시장에서도 그래프 DB에 대한 관심이 점점 높아지고 있다. 그래프 DB는 데이터 간의 관계성을 명시적으로 저장해, 서로 복잡한 관계로 얽혀있는 데이터들 사이에서 숨어있는 인사이트를 찾아낼 수 있다. 특히 그동안의 데이터 관련 기술들이 분석에 필요한 업무를 줄이고 성능을 높이는 데에 주력했던 반면, 그래프 DB는 기존에는 불가능했던 복합적인 분석까지 가능하게 만든다는 점에서 분석의 패러다임을 바꿀 기술로 평가된다.

가장 촉망받는 NoSQL ‘그래프 DB’

‘데이터베이스(DB)’라고 하면 관계형 DB(Relational Database)를 의미하던 시대가 있었다. 컬럼(column)과 로우(row)로 구성된 테이블에 데이터를 저장하는 관계형 DB는 지금도 DB 시장의 대표주자다. 기업의 IT 환경이 확장되고 변화하면서 관계형 DB만으로 모든 업무를 처리할 수는 없게 됐지만, 그럼에도 불구하고 관계형 DB를 사용하지 않는 기업은 없다고 단언할 수 있다.

오늘날 관계형 DB의 대항마로 노SQL(NoSQL) DB가 부각되고 있다. 노SQL이라는 명칭은 관계형DB의 핵심 중 하나인 SQL을 부정하며 ‘SQL을 사용하지 않는다(No SQL)’, 혹은 ‘SQL만 사용하지는 않는다(Not only SQL)’는 의미에서 붙여졌다. 관계형 DB의 엄격한 스키마(schema) 구조와 정형화된 SQL을 사용하는 대신, 비교적 융통성 있는 모델을 사용해 데이터의 속성을 다양하게 정의하고 편리한 저장과 검색을 지원한다. 특히 관계형 DB가 단일한 서버의 수직(vertical) 확장에 특화돼 있다면, 노SQL DB는 다수의 서버로 늘려나가는 수평(horizontal) 확장이 가능해 많은 데이터를 분산 처리하는 데에 강하다는 특징이 있다.

그렇지만 노SQL DB가 관계형 DB의 대척점에 있거나, 관계형 DB를 대체하기 위해 나온 기술은 아니다. 노SQL DB들은 관계형 DB에서는 찾아볼 수 없는 기능들을 제공하기는 하지만, 그만큼 명확한 한계를 가지고 있기 때문이다. 예를 들어 대표적인 노SQL DB 중 하나인 키-값(key-value) DB는 데이터를 식별하는 ‘키’와 그에 해당하는 ‘값’으로 구성돼, 관계형 DB보다 훨씬 간편하고 빠른 데이터 검색이 가능하다. 하지만 복잡한 연산을 수행하는 능력이 부족해 사용할 수 있는 영역이 제한된다. 이에 따라 복잡한 연산이 필요하지 않으면서 빠른 읽기/쓰기가 필요한 경우에 한정적으로 사용되고 있다. 즉 노SQL DB와 관계형 DB는 서로 상호보완적으로 사용된다는 뜻이다.

현재 노SQL DB 진영에서 가장 뜨거운 관심을 받고 있는 것은 단연 그래프 DB(GraphDB)다. 아직 기술 자체가 미완성이기 때문에 도입 사례가 많지는 않으나, 그래프 DB가 가져올 수 있는 막대한 가능성에 대해 많은 이들이 관심을 보이고 있다. DB엔진닷컴(DB-engines.com)에 따르면 그래프 DB는 나머지 경쟁자들을 큰 격차로 따돌리면서 가장 인기있는 DB로 자리잡고 있다. 시장조사기관인 가트너는 오는 2025년까지 전 세계 기업의 80%가 그래프 DB를 활용할 것으로 예측했다.

데이터 간의 관계성에 주목…복잡한 문제 풀이에 유리

그래프 DB는 수학에서 사용되는 그래프 이론을 활용해 데이터를 저장하고 표현하는 DB다. 흔히 그래프 DB를 그림과 함께 설명하는 경우가 많아 시각화된(graphic) DB로 오해하기도 하지만, 저장한 데이터들의 구조를 보다 쉽게 이해하기 위해 시각적인 표현을 사용하는 것이지 그래프 DB 자체가 시각화된 DB를 의미하는 것은 아니다.

그래프 이론에서는 값들을 꼭짓점(vertex)과 변(edge)으로 저장하고 관계성을 정의하는 것처럼, 그래프 DB는 값(데이터)을 노드(node)와 에지(edge)로 저장한다. 하나의 데이터가 절대적인 값만을 가지고 있는 게 아니라, 다른 데이터들과의 관계성으로 인해 상대적인 값을 갖는다. 예를 들어 서울과 부산 사이에 있는 KTX 정차역들을 노드로 놓고, 각 역 사이의 이동시간을 에지로 저장한다고 하자. 이를 시각화하면 KTX 정차역들 사이의 이동시간을 직관적으로 파악할 수 있다. 서울이라는 데이터에는 ‘부산에서 KTX로 3시간 30분 떨어진 도시’라는 상대적인 값이 주어진다.

물론 두 도시 간의 이동시간 정도는 그래프 DB가 아니어도 충분히 표현할 수 있다. 그래프 DB의 장점은 데이터의 양과 종류가 폭발적으로 늘었을 때 발휘된다. 다시 아까의 예시로 돌아가서 KTX 노선을 30개 정도로 늘려보자. 노선의 방향도 서울-부산 사이의 1개가 아니라 주요 도시들을 모두 연결할 수 있도록 동서남북으로 자유롭게 놓도록 하자. 이런 상황에서 A 도시를 출발해 B 도시까지 가장 빠르게 갈 수 있는 노선을 구하려면 어떻게 해야 할까?

기존의 데이터 저장 방법으로는 이러한 문제를 풀기 어렵다. A-B 사이를 연결하는 도시들 간의 이동 시간의 합을 구하기 위해 반복적으로 데이터 결합(join)을 시도해야 하기 때문이다. 반면 그래프 DB는 이러한 문제를 손쉽게 풀 수 있다. A 도시와 B 도시를 연결하는 수많은 노드와 에지 사이에서 가장 총합이 낮은 경로를 찾는다. 데이터 사이의 관계를 명시적으로 저장하고 있기 때문에 반복적인 결합을 실행할 필요가 없어 연산 시간이 크게 단축된다. 두 지점(도시) 사이를 가장 적은 값(시간)으로 이동하는 최단거리 문제는 수학적으로 그래프 이론을 사용하는 가장 대표적인 사례이기도 하다.

에지를 특정한 값이 아니라 변수로 놓는 것도 가능하다. 서울과 부산 사이의 거리처럼 변하지 않는 값을 입력할 수도 있지만, ‘서울의 인구가 100명 증가하면 부산의 인구가 50명 감소한다’처럼 양자의 상관관계를 표현할 수도 있다는 뜻이다. 이렇게 인구 증감과 같은 변수를 모든 노드에 확대 적용하면 특정 노드의 변화가 전체 도시들에게 어떤 영향을 미치는 지 직관적으로 파악할 수 있다.

한 걸음 더 나아가, 에지를 변수로 가지고 있는 테이블을 여러 개 만들어본다면 어떨까? 가령 ‘도시 사이의 인구 증감’ 테이블에 ‘평균 소득과 인구 증감의 관계’ 테이블을 연결하는 것이다. 후자에 ‘서울은 평균 소득이 100만 원 증가하면 인구가 100명 늘어난다’는 데이터가 갖춰져 있다면, ‘서울의 평균 소득이 100만 원 증가했을 때 부산의 인구가 50명 감소한다’는 결과까지 얻을 수 있다. 앞서 설명했던 최단거리 문제에도 다양한 테이블을 적용해볼 수 있다. ‘각 도시 사이의 이동시간’ 테이블에 ‘각 도시의 현재 날씨’와 ‘날씨와 이동시간의 상관관계’를 결합해보면, 날씨의 영향까지 고려해 서울에서 부산까지 가장 빠르게 갈 수 있는 방법을 찾을 수 있다.

라플라스의 악마

라플라스의 악마(Laplace’s Demon)는 프랑스의 수학자인 피에르시몽 라플라스(Pierre-Simon, marquis de Laplace)가 제시한 가상의 존재다. 라플라스의 악마는 ‘우주에 있는 모든 원자의 위치와 운동량을 알고 있다면, 과거‧현재‧미래의 모든 일들을 알 수 있다’는 생각에서 탄생했다. 실제로 이런 악마가 존재할 수는 없겠지만 하나의 사고실험으로써 많은 관심을 받았다.

만약 그래프 DB에 세상에 존재하는 모든 변수를 입력하면 라플라스의 악마가 될 수 있지 않을까? 현상 간의 인과관계와 영향을 정확히 알고 변수로 입력할 수 있다면 ‘나비가 북경에서 날개짓을 했다’는 현상에서 ‘뉴욕에 태풍이 일어난다’는 미래도 읽어낼 수 있을 것이다. 여기에서 중요한 점은 데이터들 사이의 인과관계를 통해 ‘미래를 읽어낼 수 있다’는 요소다.

기존의 데이터 분석은 과거의 데이터에서 통계적인 특징(pattern)을 찾아 미래를 예측한다. 어떤 시스템에서 수집된 데이터들이 XY 그래프에서 직선에 수렴하는 식으로 나타난다면, 앞으로도 해당 시스템에서는 해당 직선에 수렴하는 데이터들이 생성되리라고 예상하는 식이다. 통계적으로 사공이 많은 배가 산으로 가는 경우가 많았다면, ‘사공이 많으면 배가 산으로 간다’는 결론을 내리는 분석이다.

이러한 전통적인 분석에서 인과관계는 고려되지 않는다. 해당 시스템에서 수집된 데이터가 왜 직선으로 수렴하는지, 사공이 많으면 왜 배가 산으로 가는지는 알지 못해도 된다. 중요한 것은 결과적으로 데이터가 직선으로 수렴하고, 사공이 많으니 배가 산으로 갔다는 결과다. 최근 몇 년간 AI와 머신러닝이 데이터 분석 기술을 크게 성장시키기는 했지만, 결국 축적된 데이터의 통계에 기반하고 있다는 점에서 새로운 지평을 열지는 못했다. AI와 머신러닝 기술이 알고리즘 블랙박스라는 문제를 안고 있었음에도 사용될 수 있었던 것은 인과관계를 따지는 과정이 아니라 통계적인 결과를 이용하기 때문이다.

그래프 DB는 결과가 아니라 인과관계를 통해 미래를 예측한다는 점에서 차별화된다. 그래프 DB의 예측은 노드들을 연결하고 있는 에지, 즉 하나의 데이터가 다른 데이터에 미치는 영향을 순차적으로 따라가면서 이뤄진다. A라는 현상이 Z라는 결과를 만들어내기까지, A-B-C-D-…-Y-Z라는 인과관계를 차례대로 따라간다. 즉 ‘사공이 많다’는 현상에서 ‘배가 산으로 갈 것’이라는 미래를 읽어내기 위해 ‘사공이 많으면 각자 자기주장만 한다’, ‘자기주장만 하다보면 엉뚱한 결과로 이어진다’와 같은 인과관계를 따라간다는 것이다.

여기에서 중요한 차이는, 인과관계를 따지는 그래프 DB에서는 결과에 대한 통계적인 데이터가 필요하지 않다는 점이다. 즉 사공이 많을 경우 배가 산으로 간다는 통계가 축적돼 있지 않더라도, ‘사공이 많다’는 현상이 야기하는 인과관계가 제대로 정립돼 있다면 ‘배가 산으로 간다’는 결과를 예측해낼 수 있다. ‘나비의 날개짓’이 일으키는 현상을 따라가다 보면 ‘뉴욕의 태풍’이라는 전혀 예상할 수 없었던 미래를 알아내는 것도 가능하다. 그래프 DB에서 ‘라플라스의 악마’라는 가능성이 보이는 이유다.

그래프가 필요한 문제부터 찾아야

그래프 DB를 활용하기 전에 고려해야 할 것은 크게 두 가지다. 가장 먼저 그래프 DB를 사용할 필요가 있는지를 고민해야 한다. 대부분의 노SQL DB들이 그렇듯, 그래프 DB는 관계형 DB의 대체재가 아니다. 관계성이 중요하지 않은 문제에서는 기존의 관계형 DB를 사용하는 게 훨씬 유리하다. 가령 한 학급에서 시험 후 과목별 평균점수를 구하는 문제가 있다면, 여기에 굳이 그래프 DB를 활용할 필요는 없다.

그래프 DB를 사용해야 하는 문제는 변수가 많고 데이터 간의 관계성과 인과관계가 복잡한 문제들이다. 앞서 설명한 최단거리 문제의 사례로 차량 내비게이션을 들 수 있다. 현 위치에서 목적지까지 가기 위해서는 가장 먼저 도로 정보가 확보돼야 한다. 여기에 관계성이 높은 다양한 데이터들을 결합해 정확도를 높일 수 있다. 공사정보 레이어를 얹어 해당 경로를 피한다거나, 실시간 교통 혼잡도 레이어를 얹어 막히지 않는 길을 찾는 식이다. ‘A 경로가 공사 중이니 B 경로에 차량이 몰릴 것’처럼, 다양한 요소들의 관계를 복합적으로 분석하는 문제에 그래프 DB를 활용할 수 있다.

또한 고려해야 할 것은 데이터 간의 인과관계를 정확히 파악하고 이를 변수로 설정하는 것이다. 변수가 제대로 설정되지 않는다면 정확한 분석이 이뤄질 수 없는 것은 당연하다. 정확한 변수를 설정하기 위해서는 해당 분야에 대한 치밀한 도메인 지식이 필요하다. 데이터들이 어떤 관계성을 가지고 있는 지는 축적된 데이터에 기반한 통계적 지식으로도 알아낼 수 있지만, 겉으로는 잘 드러나지 않는 관계성을 찾고 연결고리를 만들어보는 것은 도메인 지식과 경험에 의거한 직관이 있어야 한다. 긴 지문으로 구성된 수학 문제를 보고 스스로 수식을 세워 해답을 찾아가기 위해서는 유사한 문제들을 풀어보며 축적된 노하우가 필요한 것과 마찬가지다.

그래프 DB 활성화에 총력전 걸겠다
이화식 엔코아 대표

‘인간이 할 수 없는 일’을 한다

1988년 무렵에 ‘오라클 SQL+’라는 책을 구하게 됐다. 아직 오라클이 한국 지사를 세우기도 전, IBM의 정보관리시스템(IMS, Information Management System)로 대부분의 업무를 처리하던 시절이다. 그 책을 출퇴근하는 지하철에서 3일 동안 읽었다. 책을 읽는 동안 앞으로 세상은 반드시 관계형 DB로 간다, 여기에 뛰어들어야 한다고 생각했다.

그래프 DB를 처음 봤을 때, ‘오라클 SQL+’를 읽었을 때와 같은 충격을 받았다. 앞으로 그래프 DB는 관계형 DB가 그랬던 것만큼 IT를 크게 변화시킬 것이다. 그래서 지난 3년간 처음으로 돌아간 마음으로 그래프 DB에 대한 공부에 매진했다.

기존 IT 시스템들의 목표는 사람이 하는 일을 좀 더 편하게 도와주는 것이었다. 다르게 말하자면 ‘인간이 할 수 있는 단순한 일’을 대신해주는 것이다. 지금의 AI나 머신러닝도 마찬가지다. 그렇지만 앞으로 IT는 ‘인간이 할 수 없는 복잡한 일’에 도전해나갈 것이다. 사칙연산으로는 풀 수 없는, 쿼리 몇 줄로는 답이 나오지 않는 문제를 해결하기 위해 나아갈 것이라는 뜻이다. 이런 문제는 지금까지 봐왔던 단편적이고 스칼라(scalla)적인 연산이 아니라, 보다 복잡하고 다원화된 토폴로지(topology) 형태의 연산으로 풀어야 한다. 이는 기존의 관계형 DB로는 해결할 수 없다.

예시를 들어보자. 잔잔한 연못에 돌멩이를 던지면 둥근 파문이 퍼져나간다. 돌멩이를 하나 더 던지면 또 다른 파문이 일어나고, 먼저 생겼던 파문과 겹쳐 서로 영향을 주고받는다. 다섯 개의 돌멩이를 던지면 파문들이 서로 겹치면서 더욱 복잡한 결과를 만들어낸다. 통계에 기반한 지금까지의 분석으로는 돌멩이를 던지면 파문이 일어난다는 결과는 알 수 있지만, 파문들이 서로 겹치면서 만들어내는 모양까지는 예측해낼 수 없었다. 한 걸음 더 나아가서, 첫 번째 던졌던 돌멩이의 크기를 30% 키웠을 때 어떤 모양이 나올 것인가? 두 번째 돌멩이를 던지지 않는다면 어떤 변화가 생길 것인가? 이는 기존의 관계형 DB를 통한 분석으로는 풀 수 없는 문제다. 변수가 너무 많고 연관관계가 복잡하기 때문이다.

이러한 문제를 해결하기 위해서는 각 변수들이 가지고 있는 인과관계를 찾고 그들 간의 가중치(weight)를 찾아서 분석해야 한다. 첫 번째 돌멩이가 나머지 현상들에 어떤 영향을 미쳤는지를 정확히 파악하고 있다면 크기를 30% 키웠을 때 어떤 결과가 일어날 지를 예측할 수 있다. 이것이 그래프 DB가 하는 일이다.

많은 사람들이 그래프 DB에 대해 오해하고 있는 부분은, 그래프 DB가 기존에 있던 기능들을 대체하는 게임 체인저라고 생각하는 것이다. 내가 오라클 DB를 처음 봤을 때는 기존 DB들을 전부 밀어내는 게임 체인저라고 생각했지만, 그래프 DB는 그렇지 않다. 그래프 DB의 역할은 기존 기술들로는 거의 불가능한 분석들을 가능케 하는 것에 있다. 인간이 할 수 있는 일을 쉽고 편리하게 만드는 것이 아니라, 인간이 할 수 없었던 일을 가능케 하는 것 말이다.

그래프 DB 활성화가 마지막 과업이다

하지만 그래프 DB는 좋은 제품을 골라 도입하면 해결되는 만능의 도구가 아니다. 관계형 DB를 사용하기 위해 SQL을 공부하듯 그래프 DB에 맞는 쿼리를 공부한다고 사용할 수 있는 기술이 아니라는 의미다. 데이터를 넣고 빼고 처리해야하니 쿼리를 공부하는 것은 당연하지만, 그건 전체의 20%에 불과하다. 나머지 80%는 네트워크 위상(topology)들을 처리할 수 있는 이론들을 공부해야 한다. 이러한 이론들은 굉장히 광범위하게 펼쳐져있고, 하나만 가지고도 논문을 쓸 수 있을 정도로 깊은 영역이다. 이러한 이론들을 실제 도메인 지식과 결합해서 나오는 브랜치(branch)들은 어마어마하게 많다.

오늘날 대학교에서 이런 이론에 대한 학습 기회를 제공하는 경우는 찾아보기 힘들다. 공부를 하겠다고 나서는 학생들도 드물고, 그나마 관심이 있는 학생들은 지식의 폭은 좁고 도메인 지식도 없으니 스스로 공부하는 것은 불가능하다. 최소한 국내에서 대기업이라고 불릴 정도의 규모와 인재를 갖추지 않으면 시작하기도 어렵다. 하지만 그들은 엉덩이가 무거워서 쉽게 움직이려 들지 않는다. 시간이 지난다고 자연스럽게 달라질 분야는 아니라고 본다.

이러한 상황에 변화의 모멘텀을 주는 게 나 같은 기존 플레이어들의 역할이다. 그래프 DB에 대한 관심을 제고하기 위해서는 두 가지를 모두 알고 있는 전문가가 나서야 한다. 이것으로 무엇을 할 수 있는지, 그리고 어떻게 해야 하는지를 제시할 수 있는 사람 말이다. 여기에 더해 새로운 기술을 활용할 수 있는 기업이 믿고 맡길 만한 신뢰가 갖춰져 있다면 더욱 좋다. 나는 지난 30년 간 현업에서 뛰면서 축적한 도메인 지식이 있으니 어떤 데이터로 무엇을 할 수 있는지를 제시할 수 있고, 이론과 기술에 대해 많은 공부를 하면서 어떻게 해야 하는지도 알게 됐다. 데이터 전문가들이 갖춰진 엔코아라는 조직도 갖추고 있다. 부끄럽지만 시장에서 이화식이라는 이름으로 신뢰도 제법 얻고 있다고 생각한다.

이렇게 그동안 쌓아온 경험과 기술, 조직과 네임밸류 등 모든 것들을 총동원해, 내년부터는 국내에 그래프 DB가 활성화될 수 있도록 직접 뛰어들고자 한다. 전국을 떠돌며 진기한 물건을 소개하는 보부상처럼, 실제 프로젝트들을 직접 진두지휘하면서 그래프 DB라는 물건이 무엇을 할 수 있는지를 보여주는 레퍼런스를 만들어나가겠다. 처음에는 사람들이 어려워하겠지만, 몇 가지 성공적인 레퍼런스를 접하고 나면 “이런 것도 되는구나”하는 가능성을 깨닫게 될 것이다. 처음 물꼬를 터주기만 하면 금방 큰 파도가 일어날 것이다.

스스로 참 운이 좋은 사람이라고 생각한다. 늘 타이밍 좋게 재미있는 것들을 만나 내가 할 수 있는 일들을 해왔기 때문이다. 아주 오래 전에 관계형 DB가 그랬고, 지금은 그래프 DB가 그렇다. 그렇기 때문에 더욱 사명감을 느낀다. 그냥 내버려둬서는 그래프 DB가 국내에서 활성화되는 날은 요원하다. 그동안 쌓아온 모든 것들을 그래프 DB에 쏟아서 세상 사람들이 잘 쓸 수 있도록 해주는 것이 내가 마지막으로 해야 할 일이라고 생각한다.

네오포제이 선두…한국 지사 설립한 타이거그래프도 주목

현재 그래프 DB 중에서 가장 앞서나가고 있는 것은 네오포제이(Neo4J)다. ‘포 제이’라는 이름에서 연상되듯 자바로 구현됐으며, 기본적으로 JVM(Java Virtual Machine) 위에서 작동하는 1세대 그래프 DB다. 상위권 그래프 DB들이 대부분 다양한 데이터 모델들을 지원하는 멀티모델(multi-model) DB인 반면, 네오포제이는 순수한 네이티브 그래프 DB를 표방하며 가장 많은 인기를 누리고 있다. 그래프 DB를 위한 전용 쿼리 언어인 사이퍼(Cypher)를 사용하며, 사이퍼 커뮤니티의 핵심 기여자 중 하나이기도 하다.

커뮤니티를 통해 오픈소스 라이선스로도 사용할 수 있지만, 동명의 회사를 통해 엔터프라이즈 버전을 이용하면 보다 강력한 서비스 지원을 받는 것도 가능하다. 다만 그래프 DB 자체가 워낙 빠르게 발전하고 있는 기술이기 때문에, 오픈소스 버전을 사용할 경우 업데이트 속도를 따라가기에 벅찰 수도 있다. 기존의 데이터들을 그래프 DB가 처리할 수 있도록 다양한 알고리즘이 마련돼 있는데, 이러한 알고리즘들이 하루가 다르게 추가‧변경‧삭제되기 때문에 주의가 요구된다. 물론 이는 네오포제이만의 문제는 아니며, 오픈소스 라이선스로 제공되는 모든 그래프 DB들이 유사한 어려움을 겪고 있다.

국내에 정식으로 지사를 설립해 서비스되는 제품으로는 타이거그래프(TigerGraph)가 있다. 최초에 스토리지 및 시각화 중심으로 개발된 1세대, 확장성에 중점을 뒀으나 복잡한 쿼리 수행에 어려움이 있었던 2세대에 이어, 수평적인 확장이 가능하면서도 쿼리 속도를 높여 기존 제품들의 문제를 해결한 3세대 제품으로 꼽힌다. 자바 대신 C++로 개발됐으며, 테라바이트 이상의 방대한 데이터 분석에서 특히 높은 성능을 발휘한다. 최소 5홉(hop) 이상의 관계로 엮인 데이터들을 실시간으로 분석할 수 있다. 기존 관계형 DB에서 사용하던 SQL과 유사한 GSQL을 제공해 접근성이 높은 것도 장점이다.

이외에도 국내 기업 비트나인이 서비스하는 아젠스그래프(AgensGraph)가 있다. 관계형 DB와 그래프 DB를 지원하는 멀티모델 DB로 개발됐으며, SQL과 사이퍼를 모두 처리할 수 있다. 지난해 4월에는 아파치재단의 오픈소스 프로젝트 아파치 에이지(Apache AGE)에 인큐베이팅되며 높은 가능성을 인정받았다. 그래프 DB에 대한 관심이 거의 없었던 국내 시장에서 선제적으로 제품을 개발해 공급해왔으며, 국내외에서 지속적으로 파일럿 프로젝트를 비롯한 실증 사례를 만들어온 만큼 향후 성장이 기대된다.