당신의 데이터가 그래프임을 알려주는 7가지 신호 (Neo4j, GraphRAG, Machine Learning, API 활용)

편집자 주: 지난 10월 GraphConnect 샌프란시스코에서 InfoAdvisors의 수석 프로젝트 관리자인 Karen Lopez는 데이터가 Graph Database에 의해 가장 잘 제공될 시기를 알려주는 방법에 대한 프레젠테이션을 했어요.

GraphConnect SF의 더 많은 비디오를 보고 GraphConnect Europe에 등록하려면 다음을 확인하세요. graphconnect.com.

제 역할은 데이터(데이터뿐만 아니라 데이터 스토리)가 그래프가 필요하다고 알려주는 징후가 있다고 생각하는 이유를 설명하는 것이에요. 그리고 그래프는 어디에나 있을 뿐만 아니라, 세상을 먹고 있으며, 여러분의 데이터는 그걸 알고 있죠.

저는 트윗을 많이 해요. 그리고 데이터 병아리로서 제가 옹호하는 것 중 하나는 모든 사람이 자신의 데이터를 좋아하는지 확인하는 것이기 때문에 소셜 미디어에서 다른 일을 해요. 우리가 데이터를 사랑하는 방법 중 하나는 데이터에 적합한 집을 제공하고 데이터에 적합한 도구와 기술을 제공하는 것이라고 생각해요.

방금 Wi-Fi 없이 비행기에서 내리셨다면(즉, 에어캐나다에 Wi-Fi가 없기 때문에 에어캐나다를 이용하신 경우) 오늘이 무슨 날인지 아시나요? 바로 미래의 날로 돌아가기!

그 중 하나는 Emil이 이미 다루었어요. 현재 Graph Database와 처리 방식과 관계형 데이터베이스가 새로워지고 있는 시점 사이의 유사점이었죠.

관계형 데이터베이스의 발견이나 발명을 겪어본 사람이 있나요?

오늘 초 저는 그래프가 세상을 어떻게 변화시키고 있는지 생각해 보았어요.

우리는 Graph Database가 세계 지도자들에게 미치는 영향에 대해 배웠어요. 저는 그것이 어떤 방식으로든 세상을 바꿀 것이라고 생각해요. 단지 그래프이기 때문이 아니라 데이터가 세상을 바꿀 것이라고 생각하기 때문이죠.

몬산토에서 사람들에게 먹이를 주고 서로를 돌보는 것과 관련된 중요한 문제들과 함께 유전자형과 관련된 새로운 삶의 순환, 그리고 그게 세상을 어떻게 변화시킬지에 대해 이야기했어요.

그 다음엔 데이터 간의 연결을 어떻게 발견하고, 도출하고, 시각적으로 볼 수 있는지에 대해 들었는데요. 탐사보도 기자들이 데이터를 더 효과적으로 공유할 수 있는 방법에 대한 이야기였어요. 왜냐하면 기자들은 데이터를 이해하기 쉬운 형식으로 제공할 수 있거든요. 엄격한 형식의 스프레드시트보다 훨씬 쉽죠. 덕분에 기술 지식이 없는 사람들도 데이터를 더 쉽게 이해할 수 있게 돼요.

식품 추적성과 Lending Club이 MacGyver처럼 마이크로서비스 패키지를 구성한 방법에 대한 이야기도 있었고요.

마지막으로, 문서가 너무 많을 때 어떻게 해야 하는지에 대한 이야기도 들었어요. Graph 기술을 사용해서 문서에서 메타데이터와 태그를 찾는 방법인데요, 검색 결과의 관련성을 높여주면서 불필요한 결과는 걸러낼 수 있죠.

이런 기술들이 세상을 직접적으로 변화시킬 수도 있고, 여러분과 여러분의 조직이 세상을 변화시킬 수 있는 도구를 제공해 줄 수도 있을 거예요.

현실 세계의 계층은 사실 그래프 구조!

그렇다면 왜 그래프일까요?

저는 그래프에 대해 생각하는 것이 왜 중요한지를 설명하는, 조금 짓궂고 논쟁적인 의견을 가지고 있어요.

수십 년 동안 데이터를 다뤄온 경험을 바탕으로 말씀드리자면, 계층적 분류나 세상에 구조를 적용하는 걸 좋아하는 사람이 아무리 많아도, 진짜 계층은 많지 않다고 생각해요.

여기서 '진짜 계층'이란 정확히 하나의 부모를 갖는 트리 구조를 의미해요. 그런 구조는 현실에 잘 없죠. 우리는 데이터가 계층 구조인 척하도록 시스템을 개발하거나 데이터베이스를 설계하는 데 너무 많은 시간을 쏟고 있어요.

HR 조직도나 제품 카탈로그가 계층 구조라고 생각하지만, 데이터에 억지로 계층적인 세계관을 적용하려고 하면 오히려 더 힘들어져요.

다음은 일반적인 계층 구조의 예시예요.

Bedford Falls에 우호적인 은행이 있고, 저축 대부 조합(S&L)을 소유하고 있으며, 사람들이 당신에게 보고한다고 가정해 볼게요. 당신에게 보고하는 사람들이 당신과 다른 관계도 맺고 있다는 사실을 깨닫기 전까지는 괜찮고 멋지죠.

왼쪽에는 계층 구조가 있고, 오른쪽에는 사람들이 서로 보고할 뿐만 아니라, 서로 결혼했거나 관련되어 있거나, 직접 보고하거나 감독자 역할을 한다는 것을 보여주는 더 큰 구조가 있어요.

우리는 사람에 대한 모든 데이터를 계층 구조로 정리하려고 노력하지만, 사람들은 그렇게 움직이지 않죠. 아마 여러분의 데이터도 마찬가지일 거예요.

품목, 제품, 부서, 부품, 설비도 마찬가지예요. 우리는 세상에 구조를 넣으려고 노력하고, 솔루션의 데이터를 통해 그렇게 하려고 하죠. 그리고 보고 구조에는 항상 '점선'이 있기 때문에 우리는 어려움을 겪게 되는 거예요.

사람들은 "한 번에 하나의 직책만 맡을 수 있습니다"와 같은 비즈니스 규칙을 제시하지만, 결국 사람들이 다른 사람을 따라다니거나 다른 사람과 겹치게 되죠. 이런 일은 항상 발생한다니까요.

그리고 ERP나 패키지 공급업체에 돌아가서 "실제로는 이 자리를 채울 사람이 5명이 필요해요. 두 사람은 기본이고 나머지는 보조인데 다른 사람을 뭐라고 불러야 할지 모르겠어요."라고 말하죠. 그러면 그들은 “그런 식으로는 안 돼요. 한 자리에 한 명만 있을 수 있으니까요.”라고 말할 거예요.

관계형 데이터베이스를 사용한 데이터 계층 모델링

관계형 세계에서는 이러한 개념으로 어려움을 겪어요. 저는 관계형 데이터베이스와 트랜잭션 시스템을 사용해서 작업하고 있거든요.

지금 당장 플래그 풋볼 팀을 구성한다면 저는 Team Relational에 속할 거예요. 그게 제가 인생의 대부분을 하는 일이니까요. 저는 SQL Server MVP이고, 데이터 모델러예요. 하루 종일 ERD를 만들죠.

제가 말씀드리고 싶은 건, 저는 고도로 관계형인 데이터 모델을 꿈꾼다는 거예요. 그렇다고 관계형 데이터베이스 시스템이 모든 것에 대한 솔루션이라고 생각하는 건 아니고요.

다음은 누군가가 테이블에 순전히 계층적 보고 구조를 설정할 수 있는 일반적인 방법이에요.

한 부모를 가리키는 직원, 직원 이름 및 직원 직위가 있어요. 이렇게 가르쳤는데, 그러면 사람들이 여러 사람에게 보고할 수 있다는 문제가 생기고, 맨 위에 있는 사람은 어떻게 해야 할까요? 이에 대한 해결 방법이 있긴 해요.

더미 레코드를 만들 수도 있고 CEO가 CEO에게 보고하도록 할 수도 있죠. 데이터가 계층적이라고 생각할 때에도 우리는 데이터를 사용해서 이러한 트릭을 수행해요.

순전히 계층적 구현에도 문제가 있어요. 관계형 세계에서는 직원이 직원에게 보고한다고 말하는 것은 재귀적인 관계죠. 직원들이 서로 여러 관계를 갖고 있다는 사실을 방금 배웠다는 점만 빼면요.

직원과 다른 사람 사이에는 아마도 수백 가지의 다른 관계가 있을 거예요. 따라서 우리는 관계형 데이터베이스에서와 마찬가지로 고도로 재귀적이고 자기 참조적인 조인(이런 단어는 절대 금지!)으로 끝나게 돼요.

부서 계층의 경우 또 다른 문제가 존재해요.

새로운 수준의 중간 관리자를 추가하거나, 관리자 한 명을 제거하거나, 직원의 절반을 한 관리자에서 다른 관리자로 이동해야 하면 어떻게 될까요? 우리는 관계형 데이터베이스에서 이 모든 것을 할 수 있어요. 이를 수행하는 방법에 대한 블로그 게시물, 스크립트 및 도구가 있지만, 이런 방식으로 수행하려고 하면 지저분해지죠.

관계형 데이터베이스 속이기

우리는 관계 세계의 트릭을 사용해서 실제로는 존재하지 않는다고 이미 말씀드린 계층 구조와 동일한 엔터티와 다른 엔터티 간의 관계를 모두 처리하려고 해요. 특별한 데이터 유형이 있을 수도 있고요.

SQL Server에는 서로 관련된 엔터티에 대한 모든 계층의 경로를 저장하도록 설계된 계층 ID라는 실제 데이터 유형이 있어요. 가지고 놀기 정말 재미있고 계층적 데이터를 사용하여 이러한 모든 트릭을 수행하죠.

유일한 문제는 실제 규모가 아닌 매우 단순한 구조에서만 작동한다는 거예요. 관계형 데이터베이스에서 트릭을 수행하고 있기 때문이죠.

인접 목록을 설정하고, 경로 열거를 수행하는 열에 넣고, 경로 분석 및 중첩 세트를 수행하는 클로저 테이블을 생성할 수 있어요. 관계형 세계에서 이러한 트릭을 구현한 적이 있다면 아마도 작동 방식을 설명하기 위해 긴 문서를 작성해야 했을 거예요.

작동은 하지만, 이걸 구현해야 하는 이유는 관계형 데이터베이스의 기본 가정 때문인데요. 데이터가 쓰기에 최적화되어 있고, 데이터가 매우 엄격한 구조를 따른다는 가정이요.

그건 실패가 아니에요. NoSQL 컨퍼런스에 가면 사람들은 그게 하나의 기능이고 우리가 관계형 데이터베이스를 구축하는 이유라고 말할 거예요. 잘 맞는 데이터에 대한 데이터 스토리는 관계형 데이터베이스에 포함될 가치가 있죠.

관계형 데이터베이스의 데이터 관계 문제

그럼에도 불구하고 우리는 매우 유연하고 매우 중요한 데이터 관계를 다루는 또 다른 문제가 있어요. 외래 키 제약 조건뿐만 아니라, 제가 말했듯이 이러한 것들을 관계형 데이터베이스로 구현하죠. 하지만 우리는 이 계층 구조가 실제로 계층 구조가 아니라는 걸 알게 돼요.

정말 네트워크나 물질형 구조에 가깝거든요. 이는 우리가 관계형 데이터베이스에서 특별한 관계를 구축하지 않는다는 것을 의미해요. 대신 직원 간의 다대다 관계를 관리하기 위해 연관 엔터티인 또 다른 테이블을 만들죠. 우리는 데이터를 가득 채워서 모두 괜찮아요.

지금은 다대다 관계를 처리하기 위한 완전히 다른 문제 세트를 소개했어요. 여기서는 그 모든 문제를 다루지는 않을 거예요. 그들은 단지 절충안일 뿐이죠. 그러나 이는 실제로 관계였던 어떤 것을 테이블, 즉 데이터 항목으로 변환하고 이를 다른 데이터 항목과 마찬가지로 취급한다는 의미에요.

이 때문에 우리는 모든 종류의 특수 처리 및 쿼리를 수행해야 하며, 특정 해결 방법을 구현하여 실수로 발생할 수 있는 여러 가지 이상 현상을 해결해야 해요.

모든 데이터가 고통받고 있습니다

부처님께 사과드리며 제가 관찰한 주요 내용 중 하나는 모든 데이터가 고통을 받고 있다는 거예요.

그게 무슨 뜻일까요? 저는 이 분야의 전문가는 아니지만, 이 고귀한 진리에 대한 저의 일반적인 이해는 우리가 고통을 겪는다는 거예요. 고통은 단지 문제를 다루거나, 스트레스를 받거나, 고통을 겪는 것을 의미하죠.

보다 일반적으로, 우리는 세상에 있는 것들을 실제로 적용되지 않고 우리가 통제할 수 없는 신념 체계나 구조에 맞추려고 할 때 고통을 겪어요. 그건 진실을 조금 확장한 것이지만, 기본적으로 우리는 원래 의도하지 않은 세상에 일부 데이터 쿼리를 강제하려고 하기 때문에 우리, 데이터 및 비즈니스 사용자가 어려움을 겪는 거예요.

그래프와 그래프 데이터를 다룰 때 중요한 점 중 하나는 관계형 세계에서 외래 키 관계는 전혀 관계가 아니라는 거예요. 관계형 데이터베이스라는 이름은 그래프 다이어그램의 상자나 원 사이의 선이 아니라 테이블이 관계이기 때문에 붙여진 이름이에요.

테이블은 제약 조건이에요. 그건 실제로 데이터가 통제를 벗어나지 않도록 하기 위해 착용하는 안전벨트죠. 이는 비즈니스 사용자가 이야기하거나 우리 삶에서 생각하는 관계가 아니에요. 그렇기 때문에 관계형 세계에서는 이를 생성하여 테이블에 넣어야 하는 거죠.

관계형 데이터베이스의 또 다른 단점은 속성, 태그 또는 레이블을 관계에 할당할 수 없다는 거예요. 데이터베이스에 이름을 부여할 수 있지만 아무도 그 이름을 볼 수 없죠.

그래프에서 중요한 점은 그래프 데이터베이스의 `Node`보다 관계에 우선 순위를 두었다는 거예요. 또한 관계형 데이터베이스는 이러한 관계형 `Query`나 이해를 수행할 때 확장이 잘 되지 않아요.

관계형 데이터베이스는 관계에 관한 것이 아니에요. 데이터 무결성을 위해 그들 사이에 제약이 있는 것들에 관한 것이죠.

저는 이것이 특정 데이터, 또는 더 중요하게는 특정 질문이 그래프에 더 적합하다고 말하는 이유 사이에서 가장 오해되는 차이점이라고 생각해요. 사람들은 "둘 중 하나" 접근 방식을 사용하고 싶어해요. 그래프 데이터베이스와 관계형 데이터베이스 중 어느 것이 더 좋다고 생각하시나요?

그건 제가 대답할 수 있는 질문이 아니에요. 효과적으로 대답하려면 우리가 대답하려는 질문이 무엇인지 알아야 하기 때문이죠.

관계형 데이터베이스는 테이블에 중점을 두고, 그래프 데이터베이스는 관계에 중점을 둬요. 특정 비즈니스 질문은 관계를 발견하든 문서화하든 실제로 관계에 관한 것이죠. 그건 고전적인 절충안이에요.

데이터가 그래프임을 알려주는 7가지 방법

그렇다면 데이터가 그래프라고 말하는 이유는 무엇일까요?

#7. 그 이름

네트워크, 나무, 분류, 조상, 구조 - 사람들이 조직도나 보고 구조에 관해 이야기하기 위해 이러한 단어를 사용한다면, 그들은 데이터와

#6. 그래프 같은 느낌을 주기 위해 트릭을 사용하고 있습니다.

개발자가 관계형 데이터베이스에 데이터를 구현한 다음 그 위에 레이어를 배치하여 그래픽처럼 보이거나 느껴지도록 한다는 이야기를 들어본 적이 있을 거예요. 이것이 바로 우리 모두가 관계 구조를 통해 해왔던 일이죠.

실제로는 관계형 구조뿐만 아니라 계층 구조도 있어요. 저는 관계 이전에 충분히 경험이 있다는 것을 기억하세요. 우리는 계층적 데이터베이스를 갖고 있었어요. XML, JSON 등과 같은 다른 데이터베이스 형식의 계층 구조가 있죠.

#5. 소프트웨어 공급업체가 불가능하다고 할 때

그 이유는 보통 그래프 기반이 아닌 데이터베이스나 그래프 처리 방식을 전제로 설계했기 때문일 거예요. 이제 와서 레이어를 덧붙이거나 상용 제품에 추가하려니 쉽지 않은 거죠.

#4. 질문이 엉뚱하게 느껴질 때

데이터 자체가 그래프 형태라서, 즉 구조적인 부분이 중요해서 Graph Database와 처리가 필요하다고 말하는 게 더 일반적이에요. 데이터가 그래프 형태일 *수도* 있지만, 중요한 건 데이터에 어떤 질문을 던지고 싶은가 하는 점이죠.

일반적으로 쿼리 언어를 배울 때 데모나 프레젠테이션에서 "모든 주문과 해당 주문 라인을 보여주세요" 같은 간단한 관계형 쿼리를 보게 되죠. Structured Query Language나 관계형 데이터베이스를 배우기엔 좋지만, 요즘 데이터에 대해 던지는 어려운 질문은 아니에요.

요즘은 법의학이나 사기 방지 담당자에게 "이 사람을 3단계 이상으로 아는 사람이 이 우체국을 방문해서 이 위치에서 이 나라로 상자를 배송한 적이 몇 번이나 있었나요?" 같은 질문을 던지곤 해요. 물론 그래프가 아닌 데이터베이스에서도 해당 데이터를 추적하고 응답할 수 있지만, 비용이 많이 들고 실행하는 데 오래 걸릴 거예요.

게다가, 이런 질문에 답하기 위해 완전히 별도의 솔루션을 찾아야 할 가능성도 높죠. 이는 보통 예산 문제나 추가적인 기술적인 문제로 이어지는데, 답변을 최적화하기 위해 해당 질문에 맞춰 특별히 설계된 솔루션이 필요하기 때문이에요.

분석가와 설계자로서 비즈니스 사용자에게 "더 심오한 질문은 무엇인가요?"라고 묻는 건 별로 좋은 방법이 아니라고 생각해요. 거래 시스템을 구축할 때 그런 질문을 하지 않는 이유는, 첫째는 대답이 두렵기 때문이고, 둘째는 그들이 필요로 하는 것을 제공하지 못할 수도 있기 때문이죠.

데이터가 엉망진창이 될 수 있거든요. 관계형 데이터베이스만으로는 감당하기 힘들죠. 데이터의 단순한 8단계 경로가 아니라, 수백, 수천 개가 넘는 경로 또는 Node가 있을 수 있으니까요.

#3. IT 팀에서 "느려질 거예요"라고 말할 때

혹은 "다른 시스템에 영향을 미칠 거예요", "데이터 웨어하우스를 구축해야 해요", "그 질문에는 답할 수 없을 것 같아요"라고 말할 수도 있겠죠. 이런 징조가 보인다면 정말 필요한 건 올바른 도구일지도 몰라요.

#2. 데이터에 특정 질문을 던지면 안 된다고 할 때

#1. Neo4j로 Proof of Concept를 만들었더니 잘 작동할 때

이게 최고죠!

"Proof of Concept를 구축했는데, 그건 그냥 빠른 프로토타입을 만들고 .NET에서 코딩을 좀 한 구식 Proof of Concept가 아니었어요. 실제로 Neo4j의 기본 데이터 모델과 시각화를 활용해서 Proof of Concept를 구축한 거죠."

Proof of Concept를 수행하는 것만으로도 데이터나 Query가 그래프 형태라는 걸 증명할 수 있어요.

Graph Database를 사용해야 하는 경우

우리 모두 Graph Database가 가장 잘 작동하는 상황을 강조하는 수많은 사례 연구를 들어봤을 거예요. 몇 가지 예를 살펴볼까요?

재귀 (Recursion):

재귀적인 질문이 있을 때마다 Graph Database를 사용해야 해요. 재귀는 어떤 것들이 무한한 수의 관계로 이어져서 매우 불규칙한 답변 세트를 생성하는 경우를 말해요.

예를 들어, Graph Database는 소셜 미디어에서 잘 작동해요. 한 사람은 3명의 팔로워를 가질 수 있지만, 다른 사람은 1억 명의 팔로워를 가질 수도 있잖아요. 그리고 '케빈 베이컨' 문제나 조직과 관련된 조직에도 잘 작동하죠.

마스터 데이터 관리 (Master Data Management):

많은 사람들이 마스터 데이터 관리를 그래프 문제라고 생각하지 않지만, 사실은 그렇답니다. 제품 라인, 제품 구성, 고객은 항상 그래프 형태의 질문이니까요.

네트워크 및 IT 운영 (Network and IT Operations):

궁극적인 그래프는 IT 시스템이라고 생각해요. 저는 매일 이와 관련된 작업을 하고 있죠. 여기에는 자산, 신원, BOM, 누가 무엇을 사용하는지, 어디에 있는지 등 모든 것이 포함돼요.

실시간 추천 (Real-time Recommendation):

추천 엔진뿐만 아니라, 우리가 연결되어 있다는 사실을 알게 되지만 미처 깨닫지 못하는 경우도 많죠. 경쟁 우위에 대한 많은 이야기가 있는데, 데이터에 대한 질문을 던질 수 있고 Graph Database가 이러한 질문에 답할 수 있다는 걸 알게 되는 위치에 대한 내용이에요.

법의학 및 사기 (Forensics and Fraud):

이건 행동 패턴을 추적할 수 있기 때문에 정말 흥미로워요. 사람들은 어떻게 행동하고, 언제 평소와 다르게 행동할까요? 행동의 변화는 사기적인 행위를 나타낼 수도 있고, 그냥 상점을 지나가는 사람일 수도 있겠죠.

리소스 최적화 (Resource Optimization):

이 부분에서 IT 전문가들은 다음과 같은 질문을 통해 조직에 금전적인 절감과 위험 완화를 제공할 수 있어요. "거기에 도달하는 가장 빠른 경로는 무엇인가?", "물건은 어디에 있는가?", "핫스팟, 활용도가 낮은 서버, 일정이 초과된 사람들은 어디에 있는가?"

프로모션 구축 (Promotion Building):

Graph Database는 더 많은 구매와 갱신을 유도하는 소매 프로모션을 구축하는 데에도 사용될 수 있어요. 또는 타겟 제안이나 제공할 생각조차 못 했던 항목에 사용될 수도 있겠죠.

데이터 모델링과 그래프

제가 데이터 모델러라고 말씀드렸죠? 제가 그래프에서 제일 좋아하는 점 중 하나는 논리적인 모델과 물리적인 모델이 분리되어 있지 않다는 거예요. 기본적인 데이터 모델이 곧 작성하는 물리적인 그래프 그 자체가 데이터 모델이자 데이터베이스가 되는 거죠.

화이트보드에 명사를 동그라미로 그리고, 그 사이에 관계를 추가하는 데이터 모델링을 할 수 있어요. 그러면 비즈니스 담당자, 최고 경영진, 관리자, 다른 IT 담당자 등 모든 레벨의 사람들이 쉽게 이해할 수 있죠.

또 다른 의견이 분분할 수 있는 아이디어가 있는데요. 기존의 엔터티-관계 데이터 모델도 여전히 중요한 역할을 한다는 거예요. 그렇다고 해서 반드시 Graph Database를 만들어야 한다는 의미는 아니지만, 어떤 회사들은 현재 데이터(데이터의 모양, 예외, 속성, 레이블)에 대해 수십 년 동안 쌓아온 이해를 가지고 있고, 이걸 그래프 구현에 활용할 수 있다는 거죠.

데이터 관계가 더 나은 통찰력을 얻는 방법

거의 제한 없이 그래프 처리를 하고 쿼리를 실행할 수 있는 핵심은 고객 레벨에서 시작해서 계속 확장해 나갈 수 있다는 점이에요.

전통적인 관계형 프로젝트에서는 범위가 명확하게 정의되어 있어야 하죠. 정말 비용이 많이 들고 민첩하게 개발해야 한다면, 무기한 대기열에서 끝날 가능성이 높아요.

사례 연구: Polyvore

Polyvore를 사용하면 젊은 패셔니스타들이 웹사이트에서 사진을 스크랩하고, 기본적인 메타데이터와 함께 하나의 이미지로 합쳐서 공유하고, 다른 사람들이 '좋아요'를 누를 수 있어요.

이건 본질적으로 메타데이터와 함께 의상과 특별한 기능들을 수집하는 크라우드소싱 방식이에요. 이걸 통해서 최종 사용자들이 제품을 어떻게 사용하고, 구매하고, 조합하는지를 제품 공급업체나 제조업체에 알려줄 수 있죠.

게다가 '좋아요'와 댓글을 통해 소셜 참여도 가능하게 만들어요. 본질적으로 누군가가 마치 세상의 모든 상점을 소유한 것처럼 사람들의 제품으로 구성된 가상 웹 상점을 구성하는 것과 같아요.

하지만 제품, 메타데이터, 사람들이 사용하는 제품, 제품이 함께 사용되는 방식, 새로운 조합에 대한 사람들의 생각 등 근본적인 관계는 제조업체와 공급업체가 이 공간에서 사용자와 상호 작용하고 자체 콘테스트를 만들 수 있는 기회를 제공해요. 정말 흥미롭죠? 게다가 후속 데이터를 마이닝할 수 있다는 점은 엄청난 힘을 가지고 있어요.

마스터 데이터 관리에 대한 참고 사항

마스터 데이터도 그래프인 이유는 고객에 대해 중요한 질문을 할 수 있을 뿐만 아니라, 이름 철자, 해당 이름과 연결된 전화번호와 같은 구문뿐만 아니라 상호 작용 횟수 및 유형과 같은 다른 패턴을 사용해서 고객 데이터의 중복을 제거할 수도 있기 때문이에요.

데이터에 대한 360도 뷰를 가지고 있기 때문에 이전에는 물어볼 수 없었던 질문을 할 수 있게 되는 거죠. 하지만 그건 단순한 데이터 그 이상이에요.

그래프 시작하기

그래프를 시작하기 위한 몇 가지 팁을 드릴게요.

• O'Reilly Graph Database 책을 읽어보세요. 무료로 다운로드할 수 있어요.
• Graph Database에 대한 무료 온라인 강좌를 들어보세요.
• RDBMS-그래프 개념과 도구에 대해 자세히 알아보세요.
• Neo4j를 설치하고 직접 플레이해보세요.
• GraphGist를 탐색하면서 재미있게 보내세요 (제가 두 번째로 좋아하는 GraphGist가 벨기에 맥주에 관한 것이라는 사실에 너무 놀라지는 마세요).
• 제 마스터 데이터가 그래프인 이유에 대한 백서를 읽어보세요 (약간 편향적이지만 그래도 추천해요).

특정 조직에서 그래프의 세계로 뛰어드는 또 다른 좋은 방법은 주요 데이터 중심 비즈니스 담당자에게 데이터에 대해 묻고 싶지만 할 수 없었던 질문이 있는지 물어보는 거예요.

그런 다음 현재 관계형 데이터베이스에 문서화되지 않은 데이터의 관계가 있을 수 있다는 점을 비즈니스 사용자가 이해하도록 도와주세요. 과거에는 다른 데이터베이스나 다른 테이블에 있는 데이터가 여전히 필수적인 관계를 가질 수 있다는 점을 상기시키는 대신 관계는 단지 제약일 뿐이라고 말했었죠.

자신의 데이터에 대한 새로운 통찰력을 발견하면 조직은 기존 데이터의 데이터 관계를 기반으로 경쟁 우위를 확보할 수 있어요.

기존 데이터로 얻을 수 있는 통찰력을 정량화할 수 있다는 건 조직이 새로운 데이터, 외부 데이터 또는 새로운 질문을 통해 더 많은 통찰력을 얻는 방법을 이해하도록 돕는 첫 번째 단계가 될 거예요.

Karen의 강연에서 영감을 받으셨나요? GraphConnect Europe 2016년 4월 26일에 등록해서 진화하는 그래프 데이터베이스 기술 세계에 대한 업계 최고의 프레젠테이션과 워크숍을 만나보세요.

---

에이치시스템즈의 LogTree는 Neo4j 기반 GraphRAG 플랫폼으로, 데이터를 자동으로 지식그래프화하고 자연어 질의로 즉시 답을 제공합니다.

👉 에이치시스템즈 홈페이지