Graph Note

• News

관계는 우리 존재의 중심이에요 – 자연과, 환경과, 서로와, 그리고 우리 자신과 함께.

이러한 연결을 통해서 우리는 궁극적으로 지식을 찾고 답과 통찰력을 얻으려고 하죠.

지난 365일 동안 Neo4j와 함께 하면서 회사 문화에 대한 지식과 통찰력, 스웨덴 '라곰'의 "딱 맞는 양"이라는 이념과 실천, 그리고 동료 `Node`들로부터 배우는 점들을 검색 없이도 발견할 수 있었어요. 심지어 저 자신과의 관계도 편안해졌답니다.

입사하기 전에는 일에만 집중하는 경향이 있었고, 일과 삶의 균형을 중요하게 생각하지 않았어요.

조화와 균형을 지지하고 기념하는 '라곰'은 Neo4j 정신에 깊이 뿌리내려 있어요. 분기별 글로벌 웰니스 데이와 같은 기업 이니셔티브, 그리고 사회적 책임을 위한 시간과 공간을 장려하는 것만 봐도 알 수 있죠.

'라곰'을 실천하면서 가족, 친구들과의 관계도 훨씬 더 좋아졌어요.

맥락상 회사 문화를 정의하는 Neo4j의 가치 중 하나는 "긍정적인 의도"인데요. 이는 비록 당신이 그들이나 그들의 결정에 동의하지 않을지라도 다른 사람들이 공동의 이익을 위해 일하고 있다는 심오하고 논리적인 가정이에요. 의사소통에서 긍정적인 의도를 가정함으로써 우리는 신뢰를 구축하고 감정이 아닌 인내와 차분하고 논리적인 사고가 필요한 상황에서 팀이 성공할 수 있도록 돕죠.

단순히 서로를 먼저 이해하려고 노력함으로써 불일치와 갈등이 최소화되고, 사내 정치가 위축되며, 강화된 협력을 통해 우리 모두의 집단적, 개인적 목표를 달성할 수 있어요.

제가 확립한 또 다른 관계는 동료 `Nodes`들과의 관계인데요. 매우 긍정적인 태도를 지닌 똑똑한 사람들과 함께 일하는 것은 일과 삶의 조화를 유지하는 데 엄청난 도움이 되었어요. 그들은 심지어 제가 쉬어야 할 때 쉬도록 하기도 해요.

APAC 지역의 우리 팀은 10배 이상 성장했고, 마케팅 팀의 규모는 3배나 늘어났어요. 팬데믹 기간 동안 지역 전역의 15개 이상의 도시에 기반을 둔 팀과 함께 협력하고 결속하는 것이 어려운 일이 되었죠. 시간대, 다양한 문화, 유행성 스트레스는 모든 사람에게 부담이 될 수 있으며, 특히 아주 어린 팀의 경우 더욱 그렇고요.

고립감을 극복하기 위해 우리는 세션 중에 비즈니스 대화를 하지 않는다는 규칙에 따라 가상 점심 세션을 설정했는데요. 이는 우리가 서로를 더 잘 이해하는 데 도움이 되었어요.

또한, 내 삶의 큰 부분이 공식적으로 인정되고 평등의 혜택을 받게 되면서 나와 나 자신의 관계는 지난 1년 동안 더욱 현실적이고 가시적으로 변했어요.

Neo4j에 오기 전에 관계는 제가 알고 있었지만 집중하지 않았던 것이었는데요. 연결과 관계를 이해하고 기술이 삶을 모방하는 것처럼 데이터 포인트 간의 경로가 인간의 삶으로 확장된다는 점을 인식함으로써 관계를 더 잘 이해하기 시작해요. 이를 실천하면 관계가 깊어지고 개선되며 상승 순환이 시작되죠.

그래프 데이터 플랫폼과의 관계를 강화하고 기술보다 더 광범위한 영향력과 구현을 통해 그 가치를 증폭시키고 크고 작은 기업에 헤아릴 수 없는 이점을 제공해요.

APAC 마케팅 팀 내의 관계는 다른 기능의 다른 팀 구성원으로 확장된 다음 Neo4j 외부의 다른 국가, 지역 및 커뮤니티로 확장되는데요. 관계망은 파트너, 개발자, 정부, 고객 및 잠재 고객으로 확장돼요. 모든 것이 연결되어 있는 거죠.

전체적으로 이러한 관계는 2021년을 저에게 멋진 한 해로 만드는 데 도움이 되었어요. 그리고 이 관계는 이제 막 시작되었는데요. 우리는 2022년에도 APAC에서 관리형 성장 전략을 계속하여 팀원들과 양질의 관계를 발전시키는 데 집중할 거예요. 뉴노멀을 통해 우리가 서로 직접 만날 수 있게 되기를 바라며, 이를 통해 지금까지의 가상 관계가 더 높은 수준의 상호 연결된 평면으로 발전할 거예요.

나는 더 많은 것을 기대하고 그 이하도 기대하지 않아요.

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

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

저는 수학자이고 박사 과정에서 Graph Theory를 전공하고 있는 타티아나 하팅거에요. 현재 아르헨티나 부에노스아이레스의 Cognitiva에서 인공지능 관련 솔루션을 구현하는 기술 분야의 인지 솔루션 전문가로 일하고 있습니다.

저희가 구현하는 솔루션 중 하나는 다양한 회사를 위한 가상 비서 솔루션인데요, 통신 회사, 금융 서비스, 헬스케어 산업 분야에서 활용되고 있어요.

이번 내용은 페데리코 코스타, 하비에르 포르틸로와 함께 작업한 내용을 바탕으로 하고 있습니다.

저희 팀 리더가 그래프를 사용해서 가상 비서를 향상시키자는 아이디어를 냈을 때, 솔루션 개발에 착수하게 되었어요. 그때부터 어떻게 구현할 수 있을지 조사하기 시작했고, 마침내 해결책을 찾았죠.

소개

저희는 IBM의 AI Watson Assistant 기술과 IBM이 지원하는 Graph Database를 결합했어요. 고객의 선호도나 니즈에 따라 추천을 제공하고 싶었고, 가능한 한 빠르게 결과를 얻고 싶었거든요.

여기서 공유하는 예시는 영화 추천이지만, 사실 모든 유형의 추천이나 검색에 적용할 수 있어요. Graph Database에는 추천에 필요한 모든 정보가 담겨 있답니다.

중요한 점은, 저희가 선택한 지표를 사용해서 계산한 특정 연령대에 대한 가중치가 그래프에 있다는 거예요. 이 엣지 가중치는 가장 빠른 방법으로 추천 프로세스를 수행할 수 있게 해주는 핵심 요소랍니다.

해결하고 싶었던 문제

저희 목표는 가상 비서 환경에서 요청이나 관심사를 기반으로 고객에게 빠른 추천을 제공하는 것이었어요.

이것이 고객과의 첫 번째 소통이라고 가정해볼 수 있어요. 고객의 선호도나 좋아하는 것에 대한 사전 지식이 없는 상태죠. 그래서 정보를 수집해야 하는데, 여기서 가상 비서가 활약하게 돼요.

저희는 사용자의 선호도를 파악하기 위해 어시스턴트가 질문을 던지도록 설계했어요. 좋은 사용자 경험을 제공하고 싶었거든요. Watson Assistant 덕분에 자연어로 대화하는 부분은 물론, 전체 프로세스에 걸리는 시간을 최소화하고 싶었어요.

바로 이 지점에서 Neo4j를 사용한 그래프가 등장하는 거죠!

Watson Assistant Tool

IBM Watson Tool에 대해 조금 이야기해볼게요. 여기서 저희는 가상 비서를 개발했답니다.

IBM Watson Assistant를 사용하면 자연어로 입력된 내용을 이해한 다음, Query에 대한 답변을 제공할 수 있습니다.

Watson Assistant는 구조화되지 않은 데이터를 분석하고 자연어를 처리해요. 문법과 맥락을 이해하기 위해 복잡한 질문을 이해하고 각 경우에 가능한 모든 의미를 평가하는 솔루션을 교육했죠.

Watson 가상 어시스턴트는 학습 기술을 적용해서 문장이나 구문에 대해 미리 정의된 최상의 클래스를 예측한답니다.

가상 비서가 수행하는 이 "사고" 서비스는 텍스트 뒤에 숨겨진 의도를 해석하고 특정 신뢰 수준에 해당하는 분류를 반환해줘요.

선택된 값은 해당 작업을 트리거하는 데 사용되는데요. 해당 작업은 애플리케이션을 리디렉션하거나 질문에 답변하는 것일 수 있어요.

우리 봇은 각 경우에 Cognitiva의 AI 트레이너와 이 가상 비서를 위해 우리를 고용한 회사인 도메인 전문가의 특정 지식에 따라 특정 도메인에서 교육을 받아요.

Intents and Entities

Watson Assistant는 Intents 및 Entities와 함께 작동해요.

Intent란 뭘까요? 사용자 입력의 목적을 나타내요. 예를 들어, 영화 추천 요청이나 필요에 가장 적합한 제품 요청 등 무엇이든 될 수 있죠.

Entity는 Intent와 관련된 용어 또는 개체를 나타내요. 이는 우리가 사용자로부터 얻는 정보인데요. 우리 경우에는 Entity의 값으로 발생할 수 있는 다양한 질문에 대한 가능한 모든 답변을 정의해요.

Entity를 생각해보면 Genre 영화 추천의 경우 다음과 같은 값을 갖죠. drama, sci-fi, comedy, romance, 등.

오른쪽 아래에는 Watson Assistant의 대화 상자가 어떻게 보이는지 보여주는 이미지가 있어요. 보시다시피 트리와 같은 구조를 가지고 있죠. 항상 welcome Node에서 시작해서 anything-else Node로 끝나는데, 다른 모든 Node의 조건과 일치하지 않는 모든 항목이 이동하는 Node에요.

사용자가 입력을 입력할 때마다 Watson Assistant는 이 입력이 Node의 조건 중 하나에 해당하는지, Node의 이 조건이 충족되는지 확인해요. 그렇다면 해당 Node에 설정한 모든 작업이 계속 진행되죠. 우리는 답변을 제공하고 다른 특정 Node나 우리가 원하는 다른 것으로 이동할 수도 있어요.

그래프 디자인

Neo4j를 이용한 그래프 디자인에 대해 말씀드릴게요.

이 그래프에는 다양한 유형의 Node가 포함되어 있어요. 우리는 질문 유형별로 이러한 Node를 정의하는데요. 아래 두 번째 레이어에서 파란색으로 표시되는 Node가 바로 그거에요.

예를 들어 영화 추천을 생각해 본다면, genre, favorite actor, favorite director, 그리고 release date 정도가 있겠죠. 이런 것들이 사용자에게 물어볼 질문들이 될 거예요.

그 아래에는 type value 형태의 정점들이 있어요. 각 값은 질문에 대한 가능한 답변이 되는 거죠.

분홍색 부분에는 가능한 모든 directors가 있는데, 이들은 type question director 정점에 인접해 있어요. 빨간색은 영화의 가능한 모든 genres를 가지고 있고요. 초록색에는 다양한 dates 유형의 영화들이 있을 수 있겠죠.

우리의 경우, modern과 classic으로 나뉘어 있어요. 그리고 회색으로는 모든 type actor 정점이 있고, 이들은 당연히 actor 정점에 인접해 있답니다.

노란색 하단에는 추천 정점이 있는데, 이는 데이터베이스의 모든 영화들이에요. 결과는 상위권에 있죠. 우리가 이름을 붙인 더미 정점인 Start가 보이는데, 이 정점은 question type의 모든 정점에 인접하게 돼요.

앞서 말씀드렸듯이 각 type question은 해당 질문에 대한 가능한 답변에 해당하는 모든 정점에 인접하게 됩니다.

마지막으로 하단에 추천 정점이 있고, 이러한 유형의 정점에 대한 인접성은 정점의 특성에 해당해요.

영화를 본다고 해볼까요? 시애틀의 잠 못 이루는 밤을 빨간색으로 표시했어요.

그러면 Tom Hanks 엣지가 생기겠죠. 왜냐하면 그는 영화에 출연하는 배우이기 때문이에요. 그리고 Classic으로부터 오는 우위를 갖게 될 텐데, 왜냐하면 2000년 이전 영화이기 때문이죠. 또한 Romance라는 이점도 있는데, 그건 영화의 장르니까요. 마지막으로 Nora Ephron이라는 이점도 얻게 되는데, 그녀는 영화의 감독이니까요!

물론 이 예에서는 아주 작은 그래프를 보여드리고 있어요. 간단하게 유지하기 위해 배우 한 명, 감독 한 명, 장르 하나에만 인접한 영화를 만들기로 결정했죠. 물론, 실제로는 훨씬 더 많은 인접성을 가질 수 있을 거예요.

Start 정점과 vertices of type question 사이의 엣지는 엣지 가중치를 갖게 될 거예요. 이러한 가중치는 사용자에게 해당 질문을 요청할 경우 제외될 잠재적 추천의 최소 수에 해당하죠.

우리의 목표는 해당 엣지에 최대 가중치가 있는지 질문하는 거예요. 이렇게 하면 최악의 시나리오에서도 추천 정점에 더 빠르게 도달할 수 있답니다.

이 부분에 대해 좀 더 자세히 설명해 볼게요.

우리가 하는 일은 먼저 가능한 각 대답 B에 대해 질문 Q을 던져서, 질문 Q에 사용자가 응답했을 때 제외될 영화의 수를 계산하는 거예요.

그런 다음 그 답변 중 최소값을 취해서 질문 B을 던질 질문 Q, 더미 node 사이의 edge의 무게로 둬요. Start 질문 유형 node Q 사이에 말이죠.

마지막으로 우리는 어느 edge에 최대 가중치가 있는지 질문하죠. 이게 바로 우리가 물어볼 가장 좋은 질문으로 선택할 질문이 될 거예요.

이제 사용자에게 질문을 하고 답변을 얻으면 그래프가 업데이트돼요. 그런 다음 더 이상 관련이 없는 모든 vertex와 edge를 삭제하고, edge 가중치를 계산하는 거죠.

두 가지를 결합하는 방법

이제 우리 솔루션의 두 가지 측면을 어떻게 결합하는지 알려드릴게요. Watson Assistant의 가상 비서와 Neo4j의 그래프 말이죠.

이를 위해 우리는 Watson Assistant와 Neo4j 사이를 오가는 Python 스크립트를 작성했어요. JSON, Watson Developer Cloud 및 Py2neo 라이브러리를 사용했죠.

코드는 세 가지 주요 부분으로 구성돼요.

첫 번째는 Neo4j에서 그래프를 생성하는 부분이에요. 이전에 설명했듯이 몇 가지 기능을 사용해서 vertex와 edge를 만들었죠.

그런 다음 제가 언급한 edge의 가중치를 계산하는 데 필요한 몇 가지 기능이 있어요. Start와 질문 사이에요. 우리는 이전에 본 이 측정항목을 정의하고 솔루션의 각 단계에서 물어볼 가장 좋은 질문을 결정하는 함수를 만들어요. 또한 다음과 같이 그래프를 수정할 수 있는 몇 가지 기능도 있죠. Cypher, Neo4j의 쿼리 언어에요.

마지막으로 Neo4j에서 쿼리를 작성하는 동안 Watson Assistant의 대화 사이를 연결할 수 있게 해주는 코드 부분이 있어요.

우리는 이 작업에 필요한 모든 인텐트, 엔터티 및 컨텍스트 변수를 포함하는 Watson Assistant에서 이 대화 상자를 만들었어요. 의도가 감지되면 Watson은 가능한 한 최단 시간 내에 사용자를 위한 추천을 얻기 위해 필요한 질문을 계속 던지죠.

각 질문 후에 사용자의 응답은 컨텍스트 변수에 저장되고 그래프를 수정하는 데 사용돼요. 주목해야 할 중요한 점은 사용자가 하나 이상의 질문에 대해 명확한 대답을 갖고 있지 않은 경우도 고려한다는 것이에요.

이 경우 그에 따라 그래프를 수정할 거예요.

여기에 우리 솔루션의 작은 다이어그램이 있어요.

한편으로는 Watson Assistant가 있어요. 사용자와 대화를 나눈 다음 두 부분을 연결하는 코드를 작성하죠.

반면에 Neo4j에는 사용자에게 추천하는 데 필요한 모든 정보가 포함된 Graph Database가 있어요.

의도를 감지할 때마다 대화가 시작돼요. 사용자가 무언가를 입력하면 Watson이 의도를 감지하죠. 이를 통해 어떤 그래프를 봐야 하는지 알 수 있어요. 그런 다음 이 단계에서 물어볼 가장 좋은 질문을 계산하는 작업을 진행해요.

이 정보는 Watson Assistant로 다시 전달돼요. 어시스턴트는 사용자에게 해당 질문을 하고 답변을 얻은 다음, 해당 답변을 사용하여 그래프를 수정해요. 우리는 동일한 절차를 계속할 거예요.

영화 추천 예시

이 솔루션이 어떻게 작동하는지 영화 추천 예시를 보여드릴게요.

첫째, 우리는 Start vertex가 상단에 있어요. 그럼 우리는 네 가지 vertices of type 질문을 가지고 있어요. 이 예에서 고려한 질문은 director, genre, date 그리고 actor (영화의) 이에요.

그 다음 분홍색으로 표시된 유형 값의 vertex를 가지고 있어요. 모든 directors는 빨간색으로 표시되어 있고, 모든 genres 영화는 녹색으로 표시되어 있어요. 우리는 release dates를 2000년을 기준으로 classic과 modern으로 구분했어요. 그리고 회색으로는 모든 possible actors를 가지고 있어요.

마지막으로 하단에는 추천 vertex가 있어요. 추천 vertex는 우리 데이터베이스에 있는 영화들이에요. 우리는 사용자 추천으로 이러한 영화 중 하나를 찾으려고 노력하고 있어요.

이 부분의 해결방법에서 현재 그래프의 상태가 어떤지 먼저 확인해볼게요.

우리는 14개의 vertex를 가지고 있는데, type actor, 두 개의 vertex는 type date, 26개의 directors 그리고 다섯 개의 genres를 가지고 있어요. 데이터베이스에 있는 46개의 영화로 시작하죠. 사용자에게 물어볼 수 있는 질문은 네 가지에요. 우리는 더미 vertex의 이름을 Start라고 지었어요.

질문할 수 있는 네 가지 질문이 있으므로 더미 node 사이의 edge에 가중치를 부여해요. Start와 그 질문 vertex 사이에요. 제가 언급한 측정항목을 사용하여 이를 계산할 거예요.

우리는 사용자에게 영화의 배우에 대해 묻는 경우 제외될 수 있는 가능한 영화 추천 수를 계산하고, 거기에서 두 영화 사이의 edge 가중치를 얻어요. Start 와 actor 사이는 27이에요.

우리는 다른 세 가지 질문에 대해서도 동일한 작업을 수행하여 두 질문 사이의 edge 가중치를 얻어요. Start와 date 사이는 9, Start와 director 사이는 32, 그리고 Start와 genre 사이는 23이에요.

우리는 최대값을 찾고 있으므로 이 첫 번째 단계에서 선택할 가장 좋은 질문은 director에요. 이는 Watson이 사용자에게 물어볼 가상 비서죠. 여기서는 첫 번째 단계에서 그래프가 어떻게 보이는지 확인하고, 사이에 해당하는 모든 edge 가중치를 갖습니다. Start와 모든 질문 유형 vertex 사이에요.

이런 식으로 대화가 진행될 수 있어요. 먼저 비서가 "안녕하세요. 무엇을 도와드릴까요?"라고 물어보죠. 사용자는 "이번 주말에 볼 만한 영화 추천해 주실 수 있나요?"와 같이 대답할 수 있을 거예요.

이 경우 Watson Assistant는 의도, 즉 영화 추천을 감지하고 "물론입니다. 도와드리러 왔습니다."라는 응답을 시작하죠.

그때 우리는 이전에 가지고 있던 그래프를 살펴보고, 그래프에서 이 경우에 물어볼 가장 좋은 질문을 얻어내요.

우리는 이 질문이 영화 감독에 관한 것이라고 판단하고, "좋아하는 감독이 있나요?"라고 물어보죠. 이에 대해 사용자는 "별로 그렇지 않습니다."라고 대답할 수 있어요. 선호하는 감독이 없을 수도 있지만 괜찮아요.

이 경우 Watson Assistant는 엔터티를 감지하고 Director의 값은 "모르겠어요"가 되죠. 그러면 응답이 시작돼요.

"알겠습니다. 문제 없어요. 그러면 제가 선택할게요." 그리고 사용자로부터 얻은 이 정보를 디렉터라는 컨텍스트 변수에 저장하죠.

그래프를 수정하기 위해 이 컨텍스트 변수를 사용하는데요. 이제 이 단계에서 그래프가 어떻게 보이는지 한번 살펴볼까요?

그래프의 현재 상태를 보면 14개의 vertex 유형이 있어요. Director, 두 가지 유형의 Date, 다섯 개의 Genres, 그리고 여러 Movies가 있죠. 이 경우에는 여전히 36개네요. 사용자로부터 어떠한 정보도 얻지 못했기 때문에 그 어느 것도 배제할 수 없었지만, 질문 수는 3개로 줄었어요.

이제 우리는 세 가지 가능한 질문을 갖게 되었어요. 우리는 사이의 간선 가중치를 계산해야 해요. Start와 남은 세 가지 질문 사이의 가중치요.

이렇게 해서 Start와 Actor 사이의 간선에 대해 27의 가중치를 얻고, Start와 Date 사이에서 9의 가중치를 얻고, Start와 Genre 사이의 가중치는 23이 돼요.

우리는 최대값을 찾고 있으므로 이 단계에서는 영화의 배우에 대해 묻는 것이 가장 좋은 질문이라고 선택할 수 있겠죠.

이제 이 단계에서 그래프가 어떻게 보이는지 한번 살펴볼까요?

Director 타입의 vertex는 더 이상 관련 정보가 아니기 때문에 사라졌어요. 이미 사용자에게 물어봤으니 다시 물어볼 필요는 없겠죠? 그래서 가능한 질문 vertex는 세 개가 남았네요.

대화는 계속 진행될 거예요. 배우에 대해 물어봐야 한다는 걸 알고 있으니, 어시스턴트는 "가장 좋아하는 배우는 누구인가요?"라고 물어볼 거예요. 그러면 사용자는 "저는 톰 행크스의 열렬한 팬입니다!"라고 대답할 수 있겠죠.

여기서 우리는 정보를 얻고, actor 엔티티를 감지하는데, 이번에는 값이 Tom Hanks네요.

이 정보는 그래프를 수정하는 데 사용될 context variable에 저장돼요. 이제 그래프가 어떻게 보이는지 한번 살펴볼까요?

두 개의 Date 타입 vertex와 다섯 개의 Genre 타입 vertex가 있네요. 이 단계에서는 가능한 추천 영화 수가 확 줄었어요. 남은 영화는 9편이고, 남은 질문 수는 2개입니다.

이 단계에서는 두 edge의 edge weight를 계산해야 해요. Start와 이 두 가지 가능한 질문이 있네요.

Start와 Date 사이의 edge weight를 계산하면 3이 돼요. 그리고 Start와 Genre 사이의 edge weight를 계산하면 4가 되죠. 우리는 최대값에 관심이 있으니 영화의 장르를 선택할 거예요.

이제 그래프를 한번 살펴볼까요?

이 단계에서는 그래프가 훨씬 작아졌어요. 더 이상 Actor 타입의 vertex는 없고, Actor 질문 vertex 역시 사라졌죠. 이들은 더 이상 우리와 관련이 없으니까요. 우리에게는 Genre와 Date, 이렇게 두 가지 질문이 남아있고, 우리는 가장 좋은 질문은 영화의 Genre에 관한 것이라는 사실을 확인했어요.

그렇게 대화가 진행되는 거예요. 어시스턴트는 "어떤 장르를 선호하시나요?"라고 물어보죠. 사용자는 "로맨스 영화를 보는 것 같아요."라고 말할 수 있고요. 이 단계에서 엔터티를 감지하는데, genre의 값은 Romance가 되는 거죠.

다시 한번 이 정보를 컨텍스트 변수 genre에 저장하고, 그래프를 다시 수정하는 데 사용할 거예요.

이 단계에서 그래프의 현재 상태를 살펴보면 Date 타입의 Node가 두 개, Movie 타입의 Node가 한 개 있는 것을 확인할 수 있어요.

이제 사용자에게 추천을 해줄 수 있는 단계에 왔어요. 아직 한 가지 질문이 남아있지만, 기존 방식대로 했다면 모든 질문을 다 해야 했을 거예요. 하지만 이 솔루션을 사용하면 질문 하나를 아낄 수 있었죠.

이것은 아주 작은 예시라서 솔루션을 쉽게 볼 수 있도록 단순하게 유지하고 싶었어요. 데이터 양이 엄청나게 많은 경우에 가장 큰 이점을 얻을 수 있고, 가능한 많은 추천을 배제할 수 있답니다.

이것이 현재 그래프의 모습이에요.

다음과 같은 Node 타입이 하나 남아있네요. 바로 Recommendation! 추천해 드릴 영화라는 뜻이죠. 두 개 이상의 추천을 원할 수도 있어요. 사용자에게 제공하는 추천 목록을 3개, 5개, 또는 원하는 만큼 가질 수 있고, 순위대로 정렬될 수도 있답니다.

어시스턴트가 이 영화를 추천해 줄 거예요.

영화는 바로 시애틀의 잠 못 이루는 밤이에요. 이 영화는 1993년에 나온 클래식 로맨스 영화라는 것을 알고 있죠. 톰 행크스와 멕 라이언이 출연하고 노라 에프론이 감독을 맡았고요.

결국 추천을 받았습니다!

요약

우리의 주요 목표는 고객의 관심사나 요청에 따라 고객에게 빠른 추천을 제공하기 위해 가상 비서를 사용하는 것이었어요. 이 문제를 해결하는 데 필요한 모든 정보를 Neo4j Graph Database 형태로 모델링했답니다.

대화를 가능하게 해주는 Watson Assistant 인스턴스를 만들어 볼게요. 저희는 솔루션의 두 가지 측면을 결합하는데요. 어시스턴트가 특정 의도를 감지할 때마다 edge 가중치를 통해 그래프에 의해 결정되는 순서대로 사용자 선호도를 알아보기 위해 사용자에게 질문을 시작하는 거죠.

사용자로부터 답변을 얻으면 그래프를 수정하기 위해 이 정보를 저장하고, 추천을 작성하는 데 필요한 모든 정보를 얻을 때까지 동일한 방식으로 대화를 계속해요.

이 솔루션을 요약하면, 저희가 얻은 것은 인간 간의 대화를 시뮬레이션하는 프로세스와 가능한 가장 짧은 시간에 솔루션에 도달할 수 있도록 도와주는 Neo4j 모델을 사용한 추천 시스템이라고 할 수 있어요.

솔루션의 이점/잠재력

일반적인 가상 비서는 사용자의 질문에 답변하기 위해 훈련을 받지만, 그 능력에는 한계가 있죠. 일반적으로 반응적인 형태이고, 대화는 단방향적인 경향이 있어요. 또, 지능은 사용자의 요청을 해석하고 이에 대한 답변을 제공하는 것에만 집중되어 있고요.

저희가 생각하는 이러한 유형 기술의 다음 단계는 가상 비서가 특정 도메인의 전문가가 되어, 가장 관련성이 높은 질문을 먼저 제시하여 사용자에게 유용한 지침을 제공하는 대화형 및 양방향 대화를 구축하는 것이에요. 궁극적으로 목표는 사용자가 가능한 한 빠르고 효율적으로 최상의 답변을 얻을 수 있도록 돕는 것이죠.

해당 분야 전문가가 가질 수 있는 모든 정보가 포함된 하나 이상의 그래프를 통해 가상 비서에 또 다른 지능 계층을 추가한 셈이에요.

이러한 유형의 솔루션에 대한 몇 가지 가능한 응용 분야는 특정 제품에 대한 판매 고문이나 전문 판매원이 될 수 있다는 점이에요.

다양한 유형의 제품에 해당하는 그래프를 가질 수 있어요. 냉장고 추천에 대한 그래프, 전자레인지용 그래프, TV용 그래프 등을 가질 수 있는 거죠. 이러한 경우 추천 node는 저희가 사용할 수 있는 제품이 되고요. 그런 다음 질문은 해당 제품의 크기, 가격 또는 모든 유형의 특성에 해당할 수 있겠죠.

그런 다음 예비 의료 진단이나 환자 지원에도 적용될 수 있어요. 저희의 node는 가능한 모든 질병이 될 수 있으며, 환자가 가지고 있는 다양한 증상에 대해 질문할 수 있고요.

마지막으로, 기술 지원을 위한 문제 해결을 위해 보조자가 사용자에게 질문하여, 저희가 돕고 싶은 장치의 특정 오작동에 도달할 수 있는 최선의 방향을 안내하기를 원할 수도 있겠죠.

또한 이 동일한 솔루션에는 다양한 테마나 주제에 대한 그래프가 있을 수 있으므로, 어시스턴트는 한 번에 두 개 이상의 주제에 대해 사용자에게 지침을 제공할 수 있으며, 여기에서 다양한 유형의 의도를 모두 감지할 수 있다는 점도 언급하고 싶네요.

Cognitiva에서는 Neo4j 그래프 데이터베이스를 사용하여 가상 비서를 반응형으로 만들고 각 단계에서 최고의 질문을 할 수 있도록 함으로써 강화했어요. 이 프로세스는 사용자 선호도를 파악하는 데 도움이 되며, 이를 가능한 가장 빠른 방법으로 수행하여 사용자에게 귀중한 조언을 제공할 수 있게 되는 거죠.

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

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

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

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

식품 추적성과 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 플랫폼으로, 데이터를 자동으로 지식그래프화하고 자연어 질의로 즉시 답을 제공합니다.

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

"항상 이유를 물어보세요" 라고 Stephen O'Grady, Redmonk의 공동 창립자가 말했어요.

어떤 프로젝트를 진행할지 결정할 때, 개발자는 빌드 요청받은 항목의 의미와 더 넓은 맥락을 고려해야 해요. Redmonk는 개발자 중심의 산업 분석 회사로, 상위 20개 프로그래밍 언어를 꾸준히 추적하고 있죠. Stephen O'Grady의 말입니다.

이번 주 GraphConnect 2018 (뉴욕)에서 진행된 5분 인터뷰에서 Stephen O'Grady는 그래프 기술의 사용 사례와 미래에 대한 생각을 공유했어요.

더 넓은 기술 생태계에서 그래프는 어떤 역할을 할까요?

O'Grady: 제 생각에 그래프 기술의 흥미로운 점은 지난 10년 정도에 걸쳐 등장한 다양한 비관계형 기술 중 하나라는 거예요. 수십 년 동안 관계형 데이터베이스를 사용하다가 이제는 분리되었죠. 지금은 모든 종류의 전문화된 데이터 저장소를 가지고 있어요.

이건 다양한 작업에 맞는 다양한 도구를 사용하는 접근 방식이라서 의미가 있죠. 특히 그래프는 그래프를 횡단하고 이전의 관계형 기술보다 훨씬 더 빠르게 작업을 수행할 수 있다는 점에서 다양한 문제에 대해 다양한 작업을 가능하게 해주기 때문에 가치가 있어요.

사용 사례를 보면 그래프는 꽤 다양해요. 오늘 여러분은 배달 라우팅부터 소셜 그래프 순회, 사물 인터넷(IoT) 사용 사례에 이르기까지 모든 것에 대한 이야기를 들어보셨을 거예요. 실제로 어디든 엔터티가 있고, 어떤 목적으로든 분석해야 하는 엔터티 간의 관계가 있다면 Graph Database가 꽤 잘 맞을 거예요.

그래프와 다른 기술 사이에 공생 관계가 있다고 생각하시나요?

O'Grady: 네, 떠오르는 것 중 하나가 인공지능이죠. Hillary Mason이 오늘 기조 연설에서 말했듯이, Machine Learning, Deep Learning 등의 작업을 수행하고 이러한 종류의 기술과 접근 방식을 다양한 데이터 문제에 적용하고 있어요.

제 생각에는 이러한 Machine Learning 시스템에 공급할 데이터 세트 중 일부가 본질적으로 그래프가 될 것이라는 점에서 자연스러운 적합성이 있어요. 따라서 이를 탐색하고 처리할 수 있고 두 시스템 간의 통합 지점을 가질 수 있다는 점은 정말 멋질 거예요.

그래프 기술의 미래는 어디로 향할 거라고 보시나요?

O'Grady: 제 관점에서는 그래프 기술이 주류로 자리 잡아야 한다고 생각해요. 왜냐하면 지금은 꽤 오랫동안 매우 유용한 도구였지만, 여전히 전문화되어 있고 많은 경우 틈새 시장에 머물러 있거든요. 우리가 궁극적으로 원하는 것은 그래프가 실질적이고 중요한 기술이며, 오늘날 관계형 데이터베이스처럼 사람들이 많은 것을 선택하고 분석할 수 있는 기술이라는 것을 모두가 이해하는 시점에 도달하는 것이죠.

GraphConnect 기조연설에서 가장 큰 시사점은 무엇이었나요?

O'Grady: 제 기조연설에서 얻은 가장 큰 교훈은 개발자, 실무자, 데이터 과학자 모두가 한 발 물러서서 우리가 무엇을 구축하고 있는지, 그리고 더 중요하게는 왜 그것을 구축하는지에 대해 생각해봐야 한다는 거예요.

이 업계에는 사람들이 흥미를 느꼈거나 지시를 받았기 때문에 무언가를 만들어 온 역사가 있죠. 그런데 우리가 만든 것 중 일부는 때때로 해를 입히고 심지어 잠재적으로 위험하기까지 했어요.

그래서 개발자들이 윤리적인 이유뿐만 아니라 자신의 경력이나 수익 잠재력과 같이 훨씬 더 중요한 목적을 위해서라도, 자신이 무엇을 만들고 있고, 무엇을 만들도록 요청받고 있는지 더 넓은 맥락에서 의식하도록 노력해야 한다는 아이디어인 거죠. 딱 하나만 가져갔으면 하는 게 있다면, 항상 "왜?"라는 질문을 던지는 거예요.

앞으로 5분 인터뷰에서 Neo4j 프로젝트에 대해 공유하고 싶으신가요? content@neo4j.com으로 연락 주세요!

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

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