[인터뷰] 홍성봉 아모레퍼시픽 디지털전략유닛 디지털기술개발부 상무
“아모레퍼시픽은 스노우플레이크로 데이터 플랫폼을 이전함으로써 데이터의 3가지 난제를 해결할 수 있었습니다. CRM의 복잡성을 해소했고, 대규모 시각화 요건에 맞는 성능을 확보했으며, 데이터 거버넌스 문제를 해결했습니다. 처리 성능은 65% 빨라졌고, 운영 비용을 40% 절감할 수 있었습니다.”
아모레퍼시픽 디지털전략유닛 디지털기술개발부의 홍성봉 상무는 지난 3일 미국 샌프란시스코에서 열린 ‘스노우플레이크서밋2025’ 현장 인터뷰에서 스노우플레이크 도입 성과에 대해 이같이 밝혔다.
아모레퍼시픽은 2년전 클라우드 네이티브로 구축했던 데이터 분석 플랫폼을 스노우플레이크로 이전했다. 클라우드 네이티브 데이터 플랫폼도 나름 괜찮았지만, 성능 병목과 사용자 증가, 트래픽 증가, 고성능 작업 수요, 운영 복잡성, 안정성, 기술 불일치 등의 문제를 드러냈다.
아모레퍼시픽은 기존 시스템의 문제를 해결하고, 데이터 수집부터 분석에 이르는 모든 프로세스를 표준 SQL을 사용하는 단일 통합 플랫폼에서 실행하는 것을 목표로 스노우플레이크를 선택했다.
홍성봉 상무는 이전 작업이 쉽지는 않았다고 술회했다.
“기존에 구축했던 클라우드 네이티브 형태의 데이터 플랫폼을 스노우플레이크로 이전했는데요. 이전하기까지 거의 2년 정도 시간을 썼습니다. 작년말, 올해초 넘어가면서 어느 정도 마무리 됐고, 그 효과를 분석을 해봤을 때 비용을 굉장히 많이 줄이고 전반적인 워크로드 프로세싱 시간을 많이 줄였습니다. 또 그 와중에 시간이 지났잖아요. 처리하는 데이터 트래픽 양은 줄어들지 않고 더 늘었는데도, 그런 효과를 거뒀다는 겁니다.
그래서 이런 삼박자는 어느 순간에 일어난 게 아니라, 2년 가까운 시간 동안 워크로드를 이동하고, 스노우플레이크에 맞게 데이터 플랫폼 아키텍처를 새로 재구성하고, 그 와중에 이제 스노우플레이크 자체도 나름대로 성능 업그레이드가 있었고, 이런 것들을 경험하면서 결과적으로 비용 절감과 성능 향상이 눈에 띄게 있었다는 것을 공유합니다.”
아모레퍼시픽의 데이터 플랫폼 여정은 3단계에 걸쳐 일어났다고 볼 수 있다. 전통적인 엔터프라이즈급 데이터웨어하우스 구축, 클라우드 네이티브로 전환, 스노우플레이크로 이전의 순서다. 스노우플레이크로 가기 전 클라우드 네이티브 전환에만 3년 정도 걸렸다.
“2018년도에 아모레퍼시픽에 입사했을 때 사내에서 OLAP과 하둡을 쓰고 있었습니다. 제가 온 뒤 그 시스템을 클라우드 네이티브로 이전하는 작업을 먼저 했어요. 그 작업이 3년 정도 걸렸습니다. 그 과정에서 많은 혜택을 보긴 했습니다. 예전에 온프레미스를 쓸 때 운영만 담당하는 전문 엔지니어들이 꽤 많이 필요했어요. 특히 하둡은 더욱 그렇죠. 5~6명 정도가 직접 시스템을 유지 보수하고, 거기에 맵리듀스 코딩할 수 있는 직원이 없으면 운영을 아예 못 했습니다. 그런데, 아모레퍼시픽이 OLAP을 클라우드로 전부 이전하면서 유지보수나 하둡 인력 없이도 빌드업을 쉽게 할 수 있게 됐죠. 혁신적 변화 중 하나였습니다. 워크로드를 옮기고 클라우드에 최적화시켜서 구축하는 데 시간을 꽤 썼고 나름대로 목적을 달성을 했다고 생각합니다.”
클라우드 네이티브 환경에서 아모레퍼시픽은 만족할 수 없었다. 세상의 변화에 대응하기에 새로 구축한 시스템에서 한계를 드러냈다.
“클라우드 네이티브 기반으로 구축이 다 끝날 때 쯤 되니까 세상이 다시 변화하고 있다는 걸 느꼈죠. 요구되는 워크로드의 특성들이 더 고성능을 요구를 하기 시작했어요. 그리고 AI가 늘어나기 시작하니까 데이터를 가져다 쓰는 연관 애플리케이션들이 많아지고요. 우리가 만들었던 데이터 웨어하우스에서 데이터를 퍼서 응용 쪽으로 날라야 되는 이런 데이터 오프로딩, 즉 ETL이라는 과정을 통해서 이뤄지는 오프로딩도 되게 많아졌습니다. 그러자 다시 운영 비용이 쑥 증가하는 겁니다. 기본적으로 ETL이 많아진다는 건 거기에 인력이 들어가야 하고, 데이터 이전에 시간이 또 들어가고, 오류가 발생하고, 이런 문제를 다 수반하거든요. 또, 실시간으로 데이터 프로세싱을 요구하는 시각화가 영업이나 마케팅에서 쓰는 화면이 늘어나면서 갈수록 시각화 트래픽이 늘어났습니다. 그리고, 조금 더 빨리, 실시간으로 보고자 하는 니즈도 늘어나니까 그 트래픽이 감당하기 어려울 정도가 되더라고요.
클라우드 네이티브로 이전이 끝났을 때쯤 새로운 챌린지, 즉 많은 데이터 트래픽과 많은 애플리케이션, 고성능의 실시간을 요구하는 고객 니즈들이 막 나타나니까 조만간 큰 챌린지로 다가올 거라고 생각했습니다. 그래서 클라우드 네이티브 이전이 끝나자마자 다음 단계를 준비하고, 그에 맞는 기술을 파악했습니다. 통합된 레이크 하우스와 레이크 하우스 기반의 웨어하우스를 앞으로의 대세라 보고, PoC를 했습니다. 아모레퍼시픽은 전문적인 데이터 분석가보다 마케터나 영업담당자가 직접 씁니다. 이런 걸 고려했을 때 스노우플레이크가 더 적합하다라고 판단했죠. 그렇게 스노우플레이크를 도입하고, 다시 2년동안 열심히 했죠.”
홍 상무가 스노우플레이크 도입에 앞서 생각했던 가설이 있었다. 비용 절감, ETL, CRM의 복잡성, 데이터 시각화 트래픽 처리 등이었다.
“처음에 도입했을 때 생각했던 그 가설들, 예를 들면 비용이 줄어드는 지, 늘어나는 ETL을 감당하게 되는지, 우리의 CRM에서 갖고 있었던 여러 가지 복잡성 문제를 해결하는 지, 데이터 시각화 트래픽을 잘 처리하는 지 등이 있었어요. 다행히도 모든 가설에서 다 예스가 나왔습니다.
우리가 얻은 성과들이 도입하고 눈 깜짝할 사이에 일어난 건 아닙니다. 스노우플레이크를 도입하고 그 추이를 2년 정도 봤다고 했잖아요. 그 2년 간 워크로드 옮기는 시간도 기본적으로 들어가지만, 그 과정에서 아키텍처 변화에 대한 여러 시도와 튜닝을 병행하면서 계속해서 실험을 반복하면서 오랜 기간에 걸쳐서 만들어낸 결과입니다. 스노플레이크를 도입하면 곧바로 비용이 줄고, 막 성능이 올라가는 건 아니란 말을 하고 싶습니다.
옮기는 것 자체는 오래 걸리는 일은 아닐 수 있어요. 그런데 만약 옮길 때 다시 한 번 스키마 최적화를 하겠다라고 마음먹었다면 오래 걸렸을 겁니다. 클라우드 네이티브로 처음 마이그레이션 할 때 스키마 변경을 많이 하면서 오래 걸렸어요. 그때 한 번 해둔 자산들이 있었고, 일부를 최적화하고, 일부는 그대로 넘기면서 스노우플레이크로 옮기는 시간은 그리 오래 걸리지 않았습니다. 그보다 아키텍처를 물리적 아키텍처로 재설계하고 그 다음에 일부를 튜닝하고, 실험하고, 검증하는 과정들이 좀 더 오래 걸렸습니다.”
구체적으로 보면 비용이 40% 절감되는 것으로 나타났다. 데이터와 내부 트래픽은 더 늘어났음에도 저장 비용은 늘어나지 않는 스노우플레이크 플랫폼의 특성이 한몫했다.
“비용은 전체적으로 40% 절감한 것 같습니다. 스노우플레이크 초기 투자 비용이 있고, 처음엔 이미 쓰던 클라우드와 스노우플레이크를 병행하니까 비용이 증가했을 수 있어요. 하지만, 스노우플레이크는 확실히 트래픽 입장에서 워크로드 증가에 따른 비용 증가가 거의 없더라고요. 클라우드의 컴퓨트 엔진이나 스토리지 비용이 워크로드의 이전을 끝낸 후 급격히 줄어들었습니다. 이건 스노우플레이크의 독특한 과금 체계 때문이라고 봅니다. 스노우플레이크는 스토리지 증가에 대한 비용 증가보다 CPU를 얼마나 쓰느냐에 따른 비용 증가가 훨씬 많거든요. 스노플레이크는 CPU 중심의 과금을 하면서도 고객에게 연산 시간을 절약할 수 있는 업데이트를 굉장히 많이 하는 편이에요. 그래서 워크로드당 단가들이 많이 줄어드는 효과가 있었습니다.”
스노우플레이크의 단순한 아키텍처는 아모레퍼시픽의 데이터 플랫폼에서 봉착했던 여러 난제를 해결하는 효과도 줬다.
“아키텍처 측면에서 보면 스노우플레이크는 단순한 아키텍처를 지향해요. 기존의 클라우드에서는 데이터 파이프라인 연결을 위해서 중간에 수많은 여러 노드들, 그러니까 데이터레이크에서 웨어하우스로, 웨어하우스에서 데이터마트로 가는 과정에서 중간 중간에 쓰이는 여러 가지 구성 요소들이 굉장히 많습니다. 스노우플레이크는 단순한 아키텍처를 지향하다 보니 그런 것들이 이제 없어지는 거죠. 그러면서 인프라 비용 감소도 같이 일어나고요.
특히 우리 회사의 CRM은 실시간으로 매우 복잡하게 세그먼테이션을 나눠야 하는 애플리케이션입니다. 거기에 여러 가지 엔진이 많이 들어가는데, 성능과 처리 규모를 동시에 달성하려다 보니 엄청나게 복잡한 인프라 노드들이 많이 들어갔습니다. 스노우플레이크가 그걸 거의 통으로 다 대체를 해버렸죠.
구동에 들어가는 주변의 제반 인프라들이 많이 없어지고 단일 솔루션 자체로고성능을 내니까 당연히 비용 절감과 성능 증가가 일어나죠. 아까 ETL을 말씀 드렸는데요. 고객이나 상품 데이터를 웨어하우스에 갖고 있으면서 추천을 하는 AI 애플리케이션을 운영한다고 하면, 기존이라면 웨어하우스에서 데이터를 오프로딩하고 카피해서 다시 AI 데이터베이스에 업로드 한 다음 AI 플랫폼을 돌리는 일련의 과정들이 보통 일 배치로 일어납니다. 그것들을 하기 위한 중간 인프라가 들어가고, 모니터링도 해야 하고요. 그런데, 지금은 스노플레이크를 쓰니까 제로 카피 셰어링 같은 걸로 ETL 자체가 없어지고, 데이터도 복제하는 게 아니라 실시간으로 뷰를 제공하는 형태가 되고요. 그러다 보니 웨어하우스에서 바뀐 데이터를 AI/ML 애플리케이션에서도 거의 스트리밍으로 쓸 수 있고, ETL 과정에서 일어나는 인프라도 없어지고, 데이터 오류 케이스도 없어졌습니다. 사실 여기서 발생하는 에러가 꽤 많았거든요. 발생하는 에러의 99.9%가 없어진 것 같아요.
전체적으로 인프라의 비용 절감이 두 군데서 일어나요. 하나는 인프라 비용이고 또 하나는 그 인프라를 운영하기 위한 운영 인력들이죠. 우리 직원들이 그 운영을 다 못하니까 아웃소싱을 꽤 주는데, 그 아웃소싱 비용을 포함해서 전체적인 모니터링이라든지 운영 비용도 한 40% 정도 절감되는 것으로 나온 겁니다.”
아모레퍼시픽에 있어 데이터 3대 난제가 있었다. 현재로선 만족스럽게 난제를 해결했다. 일단 앞서 언급된 CRM 문제가 가장 심각한 고민이었는데 스노우플레이크로 상당 부분 해소됐다.
“3대 데이터 난제라고 부르는 게 있어요. 하나가 CRM이에요. 화장품 업계가 원래 멤버십이 강하기 때문에 초창기 CRM 할 때 내부 고객이 천만명 정도 있었습니다. 그럼 CRM을 하려면, 서울 강남, 서초, 송파 거주, 20~30대 여성, 3개월 내 구매 제품, 장바구니, 선호 브랜드, 구매력 등등 조건을 달면서 고객을 추출할 겁니다. 그 고객의 조건이 우리 시스템에 500개 이상 있습니다. 저는 훨씬 더 많아야 한다고 생각합니다. 아무튼 데이터베이스로 치면 세로에 천만줄이 있고, 필드가 한 500개 넘게 있는 그리드가 있게 됩니다. 그런데 마케터가 어떤 조건으로 고객을 추출할 지 경우의 수가 너무 많아서 필드에 사전 인덱스를 걸 수 없습니다. 그럼 그냥 가서 생으로 쿼리를 해야 되는데 그러니까 이게 소위 말하는 ‘빅 그리드에서의 추출 문제’이죠. 이걸 RDBMS에 돌리면 시스템이 죽습니다. 그래서 프레스토 같은 MPP 엔진을 찾아보고, 이런 저런 방법을 고려하다가 이미 쓰고 있던 엘라스틱서치 검색 엔진으로 했더니 되더라고요. 초기에 CRM을 엘라스틱서치 기반으로 구현했는데 복잡해요. 그러나 엘라스틱서치로 하려니까 인프라가 굉장히 복잡해졌어요.
데이터 웨어하우스에서 고객 정보를 추출해서 엘라스틱서치에 인덱스 DB로 만드는 과정이 고난하고, 또 ETL 과정에서 프로세싱도 많으니까 되기는 한데, 복잡하고 비용도 많이 들고 에러도 많이 나는 식이었습니다. 3년 운영하다가 스노우플레이크로 할 수 있을 것 같아 딱 넣었는데 그 복잡한 인프라를 스노우플레이크 혼자서 다 해내는 겁니다. 이제는 데이터 웨어하우스가 스노우플레이크로 돼 있으니까 따로 ETL 하지 않고, 고객 그리드 만들어서 그대로 빅 그리드 쿼리를 돌려도, 성능이 잘 나옵니다.”
아모레퍼시픽은 전문적인 데이터 분석가보다 현업 부서의 데이터 활용 수요가 많았다. 이런 상황에서 태블로를 활용한 시각화 수요가 많았다. 문제는 태블로에서 처리하는 데이터의 규모가 커지면서 성능 저하가 심각했다는 점이다.
“두 번째 난제는 시각화 문제였습니다. 태블로 툴을 쓰고 있는데요, 현업 마케터나 영업담당자가 요구하는 데이터의 양이 많습니다. 과거 5년 치 데이터를 달라거나 하는 경우요. 쿼리가 복잡하기도 하고 양도 많은데, 그렇게 올라가면 태블로 서버가 데이터마트를 어디를 바라보냐에 따라서 성능이 좌우 되는데 당시 쓰던 클라우드 제품의 성능이 썩 좋지 않았어요. 태블로 측도 데이터 마트에서 데이터를 가져와 렌더링하는 방식이 느리다는 것을 알고 있기 때문에 배치 방식으로 서버가 사전에 데이터를 배치로 받아뒀다가 렌더링 하는 방식을 쓰거든요.
우리는 대부분 배치 방식으로 데이터를 쓰고 있었는데, 데이터 배치 방식이 적용할 수 있는 쿼리 수도 적고, 복잡한 쿼리에 대응하기도 어렵고, 스토리지를 굉장히 많이 차지합니다. 이거를 몇 년을 쓰면서 되도록 실시간 쿼리를 시도했지만 못하고 있었죠. 그러다 스노우플레이크를 알게 된 거에요. 스노우플레이크 한국지사 생기기 전에 알게 됐죠. 수소문을 해서 그 문제를 풀 수 있을 지 논의할 때 한국에 스노우플레이크 지사가 생겨서 테스트를 시작했습니다. 지금은 스노우플레이크를 도입해서 실시간 쿼리로 전환을 많이 했고요, 성능도 꽤 나옵니다. 예전에는 데이터를 6개월치밖에 제공 못하던 걸, 5년치도 제공할 수 있게 됐습니다. 스토리지와 성능의 제약을 어느 정도 넘어서 자유도를 많이 얻게 됐죠.”
오늘날 기업의 다양한 비즈니스 부서에서 데이터를 직접 다루고 싶어한다. 데이터팀에 의존하지 않고 자체적인 데이터웨어하우스를 구축하려는 시도도 이뤄진다. 그런 경우 데이터 거버넌스에 구멍이 생겨 비즈니스에 리스크를 가중시킬 수 있다.
“세번째 난제는 거버넌스의 문제입니다. 우리 회사는 생산부터 판매, 마케팅까지 전 과정을 다 갖고 있어요. 예를 들어 판매 데이터, 마케팅 데이터, 연구 데이터, 공급망 물류 데이터 등등 데이터 속성이 다 다르게 있습니다. 그럼 각 데이터 소모 부서에서 자기만의 독자적인 작은 웨어하우스를 돌리고 싶은 욕구가 있어요. 근데 그거를 따로 떼주면 거버넌스가 깨지고 그러잖아요. 데이터 거버넌스 전문가들은 절대 데이터를 별도로 떼어 주지 말고 들어와서 보게 하라고 합니다. 우리도 그 관점을 계속 견지하고 있었죠.
스노플레이크가 들어오면서 데이터 셰어링 같은 기능을 적극 활용 해서 분야별로 스몰한 웨어하우스를 구축할 수 있게 됐어요. 이게 ETL도 돌고 그러면 거버넌스 문제에서 연결성이 엄청 복잡해지는데, 지금은 코어 웨어하우스에 있는 데이터를 그대로 공유해서 쓰시게 하니까, 한 군데서만 데이터를 잘 관리하면 복사본도 동일한 걸 유지한다는 신뢰가생기잖아요. 스노우플레이크로 거버넌스 리스크를 떨어뜨리면서 각 부서에 맞는 스몰 웨어하우스를 운영할 수 있는 구조를 만들었고, 작년에 공급망 쪽 웨어하우스를 별도로 구축하고, 그 기반으로 해당 부서에 맞는 대시보드도 별도로 제작했습니다. 굉장히 도움되는 결과물이 나왔어요. 해당 부서 직원도 직접 자신의 웨어하우스에 들어가서 쿼리도 직접 날리고, 데이터 분석도 할 수 있고, 조금 건드렸다고 다른 데이터에 영향을 주거나 하는 일도 없어졌죠.”
아모레퍼시픽은 AI 에이전트에서 적극적으로 움직이고 있다. 홍 상무의 조직은 아니지만 별도 AI 조직에서 업계 최초의 대고객용 AI 에이전트를 선보이기도 했다. 홍 상무의 조직은 데이터팀을 위한 에이전트를 스노우플레이크의 코텍스AI를 통해 시도하고 있다.
“제 부서에서 사내용 에이전트 개발 전략을 세우고 있는데, 스노우플레이크의 코텍스 AI로 시범적으로 살펴보고 있습니다. SQL을 잘 모르는 모든 직원도 자연어를 사용해서 대화하듯 회사의 데이터를 쉽게 활용하게 해주는 그런 대화형 에이전트가 목적일 것 같습니다. 다만, 코텍스 AI가 좋고 나쁨을 떠나서, 이제야 산업계에서 에이전트를 만드는 방식과 프레임이 만들어지는 와중이잖아요. 에이전트를 어떻게 개발하느냐에 대한 방법론이 덜 정착된 탓에 퍼포먼스가 좀 안 나오는 듯한 느낌이 있어요. 에이전트를 전담으로 만드는 AI 조직이 했으면 달랐을 텐데, 코텍스 AI로 데이터 전용 에이전트를 만드는 건 우리 같은 데이터 조직에게 아직은 학습 곡선이 좀 있습니다.
예를 들면, 맨 처음에 할 만한 게 당연히 실적을 쉽게 쉽게 뽑아내는 게 있겠죠? 그러면 어느 국가, 어느 영업 채널, 어느 브랜드, 어떤 제품, 어떤 기관, 이렇게 조건을 주면서 매출과 판매 수량이 얼마냐고 물어볼 거잖아요. 그때 에이전트가 잘 인식해야 되는 게 국가, 채널, 브랜드, 상품 같은 걸 사람이 자연어로 막 치면, 표현이 100만가지 나올 거에요 이걸 똑바로 캐치하는 게 굉장히 중요한데 이걸 잘 하려면 LLM을 여러 번 갔다 와야 돼요. 코텍스 AI를 원스텝 RAG 정도로 활용을 하다 보니까 인식률이 좀 떨어지는 것 같아요. 뉴스르 보면 AI를 이용한 에이전트가 금방 나올 것 같은데 업계에서 왜 빨리 안 나오지 라고 생각했는데, 직접 해보니까 그럴 만하다는 걸 알게 됐습니다. 생각보다 너무 복잡한 거에요. 복잡하고 성능 안 나오고 안정성도 떨어지고요.”
그는 AI 에이전트를 위한 데이터를 준비하는 것의 중요성을 강조했다. AI가 인식하고 이해할 수 있게 기업 내부 데이터를 잘 준비해야 한다는 것이다. 스노우플레이크가 올해 스노우플레이크서밋 행사에서 강조한 ‘AI 레디 데이터’와 같은 맥락이다.
“AI 시대가 되면서 작년부터 ‘AI 레디 데이터’란 단어가 많이 쓰이고 있어요. AI 레디 데이터의 정의에 대해서 누구도 속 시원하게 얘기를 잘 안 해주더라고요. 최근에 어렴풋이나마 우리에게 맞는 AI 레디 데이터의 정의를 조금 내리게 됐어요. 옛날에 데이터 거버넌스가 중요하다고 하면, 그때 데이터 거버넌스는 스키마 구조를 잘 문서화하고, 그에 대한 설명을 잘 달아놓고, 다이어그램들을 잘 정리하고, 현행화하는 것들을 많이 얘기했습니다.
AI 레디 데이터란 건 AI가 어떤 데이터에 접근하려 할 때 원하는 데이터가 어디에 있는지 AI 에이전트가 쉽게 찾을 수 있는 형태의 데이터라는 생각이 듭니다. 반대로 말하면 지금은 AI 에이전트가 데이터에 접근하기 어렵다는 얘기에요. AI 에이전트가 데이터에 접근하려면 스키마를 사람처럼 이해를 하고 있어야 합니다. 이거를 이해하려면 이 스키마 구조에 대한 설명이 어딘가에 있어야 되는 거죠. 아마 데이터 거버넌스 툴에 설명을 달아놓는 것처럼요. 일단 기본적으로 지금 우리가 달아놓은 설명의 5배 이상은 달려 있어야 된다고 봅니다. 그래야 AI가 그 설명을 다 읽고 이 필드가 이런 용도로 쓰이는 거구나를 그나마 이해할 수 있어요. 지금은 그런 게 없기 때문에, 특정 쿼리별로 막 커스텀 스트럭처를 달아놓는 형국이거든요. 그러니까 자꾸 질문이 조금만 빗나가면 엉뚱한 데 가서 데이터를 찾는 거예요. 보유한 모든 데이터에 대해서 데이터 설명을 5배 이상 달아야 돼요. AI 시대가 와서 AI를 위해 스키마에 사람이 설명을 일일이 달아야 하는 아이러니한 상황이에요. 사실 코텍스 AI를 갖고 데이터를 탐색하는 에이전트를 만들 때 첫 번째로 부닥쳤던 지점이기도 했습니다.”
스노우플레이크는 올해 행사에서 정형 데이터를 위한 시맨틱 모델을 마켓플레이스를 통해 공유할 수 있는 ‘시맨틱 모델 공유’란 기능을 발표했다. YAML로 수작업으로 만들던 시맨틱을 UI 기반에서 시만들게 개선됐고, 시맨틱을 기업 조직 내부에서 재활용하는 게 더 간단해졌다. 시맨틱 뷰를 만들어서 데이터세트와 함께 마켓플레이스에 공유하게 하면 데이터세트마다 따로 시맨틱을 만들 지 않아도 되기 때문이다. 홍 상무는 해당 기능에 높은 기대감을 표하기도 했다.
글. 바이라인네트워크
<김우용 기자>yong2@byline.network
