Graph Note

오늘날 대부분의 대규모 조직에서는 데이터가 사일로에 갇혀 있다는 점을 인지하고 있을 거예요.

데이터 연결이 끊어지면, 보고서가 불완전해지고 제대로 활용하기 어려워지죠. 그래서 데이터 사일로를 통합해서 보여주는 보고서가 필요한 거예요. 그래야 조직 내에서 중요한 정보를 찾고, 비즈니스 성공에 도움이 되는 정확한 정보를 실행하고 제공하는 부서의 능력을 확신할 수 있거든요.

NoSQL: 데이터 사일로에 대한 해답

대부분의 조직은 데이터 사일로 문제를 야기했던 도구와 기술로는 그 문제를 해결할 수 없다는 걸 이미 알고 있어요. 그래서 지난 몇 년 동안 NoSQL 데이터베이스와 기술이 개발되고 배포되는 걸 볼 수 있었죠. NoSQL은 데이터를 더 빠르고, 더 큰 규모로, 더 민첩하게 통합하는 데 도움을 주거든요.

이 강력한 새 데이터베이스와 플랫폼은 기존 방식보다 데이터 통합 시간을 단축시켜 주지만, 개발자 중심이라는 또 다른 과제를 안겨주죠. 특히, 이러한 최신 기술을 개발하고 사용하는 데 필요한 새로운 기술을 습득해야 해요.

우리는 데이터베이스 르네상스라는 멋진 시대에 살고 있고, 멋진 새로운 기술들을 모두 가지고 있지만, NoSQL 전문 지식은 아직 상대적으로 새롭고 발전하고 있어요. 40년 넘게 사람들은 SQL 기반 기술을 사용해서 데이터 관리 및 통합 솔루션을 개발해 왔거든요. 마치 40년 동안 사람들이 오른손으로 데이터 관리를 연습해 온 것과 같은 거죠.

NoSQL의 최첨단에 있는 사람들은 와서 데이터로 무엇을 할 수 있는지 보여주면서 이렇게 말해요. "보세요, 우리는 귀하의 데이터를 사용해서 유연하고 안전하게 대규모로 결과를 제공하고, 현재 수행하는 시간의 1/4 만에 통찰력을 제공할 수 있도록 도와드릴 수 있습니다!" 개발자와 기업은 우리의 말을 듣고 기뻐하며 "좋아요, 한번 해봐요! 어떻게 하면 되죠?"라고 외치죠. 그러면 우리는 "쉬워요! 이 새로운 기술로 성공하기 위해 우리가 할 일은... 왼손을 사용하도록 요청하는 것뿐입니다."라고 대답하는 거예요.

기존 분석 방식으로는 대규모 데이터 세트 내의 복잡한 관계를 처리하기 어려워서, 많은 조직들이 연결된 데이터로부터 강력한 통찰력을 얻는 데 어려움을 겪고 있어요. 진정으로 정보에 기반한 의사 결정을 내리려면 사기 탐지, 추천 시스템 개선, 민감한 데이터 보호, 공급망 최적화 등 데이터 속 숨겨진 연결 고리를 이해하는 게 중요하죠.

그래프 분석은 데이터 엔터티 간의 관계를 분석해서 숨겨진 패턴, 추세, 이상 징후를 찾아내는 데 도움을 줘요. 기존 분석 방법으로는 놓칠 수 있는 예측을 가능하게 하고, 새로운 통찰력을 얻을 수 있게 해주죠.

이번 가이드에서는 그래프 분석이 어떻게 데이터 문제를 기회로 바꿔주는지 알아볼 거예요. 그래프 분석의 실제 적용 사례들을 살펴보고, 가 어떻게 복잡한 데이터 분석을 간소화하고 즉시 활용 가능한 통찰력을 제공하는지 배워볼게요.

사기 탐지 및 위험 분석: 복잡한 사기 계획 탐색

은행, 소매업체, 통신 회사, 전자 상거래 기업들은 모두 보안 위험에 노출되어 있죠. 예를 들어 합성 신원 사기, 계정 탈취, 정교한 교차 채널 공격 등이 있을 수 있어요. 조직은 공유 IP 주소, 장치 지문 일치, 조정된 거래 패턴 등 악의적인 행위자들과 그들의 활동 간의 연결 고리를 식별해서 사기 조직과 사이버 범죄 네트워크의 정체를 밝혀내고 피해를 예방하거나 최소화할 수 있어요. 하지만 안타깝게도, 이런 연결 고리들은 엄격한 테이블 구조를 강요하고 복잡한 관계를 표현하는 데 많은 비용이 드는 기존 관계형 데이터베이스 아키텍처에서는 잘 보이지 않는 경우가 많아요. 특히 JOIN 연산은 더욱 그렇죠. 악의적인 행위자들은 의심스러운 활동을 여러 계정과 채널에 분산시켜서 이러한 구조적 제약, 특히나 `Schema`의 경직성이나 JOIN 관련 성능 제약을 악용하곤 해요.

이러한 아키텍처 제약으로 인해 다음과 같은 시스템이 만들어지게 돼요.

• 사전 정의된 규칙에 의존하며, 진화하는 사기 전술에 제대로 적응하지 못해요.
• 충분한 맥락 정보 없이 연결 고리만 분석하기 때문에 잘못된 경고를 많이 발생시켜요.
• 다양한 플랫폼이나 서비스 전반에서 조직적으로 이루어지는 사기 활동을 제대로 탐지하지 못해요.

관계형 데이터베이스를 사용하는 기존 사기 탐지 시스템이 가진 핵심적인 기술적 문제들을 해결하는 데 도움을 줄 수 있는 Neo4j Aura Graph Analytics를 소개합니다! 아래 표에서 Neo4j Aura Graph Analytics가 사기 탐지에 어떤 영향을 미칠 수 있는지 한번 살펴볼까요?

사용 사례: 자금세탁 집단 식별

그래프 알고리즘은 계정 간의 거래 흐름을 추적해서 잠재적인 자금 세탁 활동을 찾아내요. 예를 들어, 여러 지역에 걸쳐 관련 없는 계정 간에 이체가 빠르게 연속적으로 발생하면 의심스러운 행동을 나타낼 수 있죠. Neo4j AuraDB 같은 Graph Database는 계정을 Node로, 트랜잭션을 Relationship으로 모델링해서 주기, 클러스터 및 "허브" 계정을 감지한답니다.

이 시각화는 전형적인 자금세탁 계획을 보여주네요.

• 여러 관할권에 걸친 국제 거래(미국, 중국, 러시아, 브라질, 인도, 케이맨 제도)
• 조세 피난처의 중앙 허브 계정(케이맨 제도)
• 결국 근원으로 돌아가는 순환적인 돈의 흐름
• 각 전송 시 약간의 양 감소(스트리핑)
• 신속한 연속 전송(모두 몇 시간 내에 발생)

Neo4j Aura 그래프 분석은 중복 제거 및 엔터티 해결을 합리화해서 유사한 엔터티와 그 Relationship을 식별해요. 데이터 엔터티(고객, 계정, 장치 등)를 속성(이름, 주소, 이메일 등)을 소유한 Node로 모델링한 다음 이러한 엔터티 간의 Relationship을 생성해서 상호 작용이나 연결을 나타낼 수 있죠. 이 접근 방식을 사용하면 데이터 생태계 전반에서 엔터티가 어떻게 연결되어 있는지 확인하고 기존 데이터베이스에서 종종 놓치는 패턴을 찾아낼 수 있어요. 예를 들어, 이름은 약간 다르지만 동일한 판매자 계정과 동일한 거래 패턴을 가진 두 개의 고객 레코드가 있는 경우 이를 잠재적인 중복으로 표시할 수 있답니다.

대규모 데이터 세트에서 JOIN 집약적인 작업으로 어려움을 겪는 기존 관계형 데이터베이스와 달리 Neo4j의 솔루션은 대규모 데이터 세트 내의 Relationship을 효율적으로 분석해서 성능 문제 없이 수백만 개의 엔터티로 확장돼요.

Neo4j Aura Graph Analytics는 확률적 커뮤니티 감지와 유사성 알고리즘을 결합해서 정교한 사기 감지도 가능하게 해요. 플랫폼의 약하게 연결된 구성요소 알고리즘은 의심스러운 속성을 공유하는 그룹 계정은 관련 없어 보이는 개체 간의 숨겨진 연결을 드러내죠.

다음과 같은 유사성 알고리즘 Jaccard, 코사인 및 오버랩은 여러 차원에서 서로 다른 엔터티가 얼마나 밀접하게 일치하는지 측정해서 합성 ID를 감지하는 데 도움이 돼요. 예를 들어 Jaccard 유사성은 합법적인 신원 구성 요소의 비정상적인 조합을 식별해서 도난당한 데이터 조각으로 구성된 잠재적인 합성 신원을 표시할 수 있죠. 이 접근 방식은 복잡한 JOIN 작업의 성능 저하 없이 실시간 사기 위험 점수를 생성하므로 금융 기관이 즉시 조치를 취할 수 있답니다.

Neo4j 그래프 기술을 사용해서 자금 세탁을 방지하는 방법에 대해 자세히 알아보려면 다음을 읽어보세요. 이 심층 가이드. Neo4j를 사용한 사기 탐지에 대해 더 자세히 살펴보고 싶다면 다음을 확인하세요. 이 블로그 시리즈.

추천 엔진: 관계를 통해 고객 참여 강화

전자상거래 및 스트리밍 서비스는 기존 추천 시스템으로 인해 어려움을 겪고 있어요. 대부분은 협업 필터링을 사용해서 사용자 유사성이나 과거 상호 작용을 기반으로 항목을 추천하죠. 이 접근 방식은 빈도나 기록 기반 패턴을 넘어 다양한 제품이나 사용자 행동이 어떻게 연결되어 있는지와 같은 복잡한 Relationship을 식별하지 못하는 경우가 많아요.

기존 시스템은 또한 "콜드 스타트" 문제로 어려움을 겪고, 정적인 과거 데이터에 의존해서 진정으로 개인화된 경험을 제한한답니다.

사용 사례: 개인화된 콘텐츠 추천

Netflix나 Spotify 같은 스트리밍 서비스들은 그래프 기반 추천 엔진이 얼마나 뛰어난 개인화 경험을 제공할 수 있는지 보여주는 좋은 예시죠. Netflix는 시청 기록뿐만 아니라 시청 시간, 시간대, 사용 기기 등 시청 방식까지 분석해서 서로 연결된 데이터 포인트를 활용해 복잡한 네트워크를 만들어요.

Spotify도 마찬가지로 음악 객체(노래, 아티스트, 앨범)와 이들의 관계(장르, 분위기, 아티스트)를 나타내는 Knowledge Graph를 사용해서 Discover Weekly 플레이리스트를 제공하고 있어요. 그래프 구조 안에서 콘텐츠 속성과 사용자 행동을 모두 분석함으로써, 기존의 테이블 형태 데이터베이스에서는 놓칠 수 있는 미묘한 음악적 선호도까지 연결할 수 있는 거죠.

스트리밍 플랫폼이 그래프 기반 방식으로 추천 시스템을 설계하는 방법을 한번 살펴볼까요?

이 다이어그램은 서로 연결된 사용자, 프로그램, 완료율, 그리고 기기를 보여주는 스트리밍 플랫폼 네트워크를 나타내요. 그래프 기반 접근 방식은 이러한 엔터티 간의 깊은 관계를 밝혀내서 플랫폼이 상황을 잘 파악한 추천 시스템을 구축할 수 있도록 도와주죠.

Neo4j Aura Graph Analytics는 65개 이상의 내장 그래프 알고리즘, 예를 들어 개인화된 PageRank나 K-최근접 이웃 같은 알고리즘을 통해 다양한 차원에서 관계를 분석해서 추천 정확도를 높여요. 이러한 알고리즘은 그래프 구조를 사용해서 근접성, 영향력, 유사성을 기준으로 항목 점수를 매기고, 1초 안에 개인화된 제안을 제공해서 참여 지표를 개선하는 데 도움을 줘요. Neo4j는 유연한 스키마와 확장 가능한 아키텍처를 통해 개발 주기를 단축시켜 주기도 하고요.

Neo4j는 사용자, 항목, 상호 작용을 Nodes와 Relationships로 모델링해서 복잡한 Queries를 단순화하고 실시간으로 적응하는 추천을 제공해요. 최신 추천 엔진을 위한 이상적인 솔루션이라고 할 수 있죠.

공급망 최적화: 복잡한 네트워크 관계 마스터하기

제조, 소매, 물류, 제약, 식품 회사들은 공급망 문제 때문에 어려움을 겪고 있어요. 공급망 단계 사이의 격차 때문에 가시성이 계속 문제가 되고, 기존 데이터베이스 시스템은 속도가 느리죠. 문제가 발생하면 기업들은 영향을 받는 제품을 빨리 찾아내거나 백업 공급 업체를 찾기가 어려울 때가 많아요. 기존 시스템은 현대 공급망의 고도로 연결된 특성을 처리하도록 만들어지지 않았거든요. 공급업체와 물류 데이터를 저장하기 위해 엄격한 스키마를 사용하기 때문에 상호 의존성을 분석하기가 어렵기 때문이에요.

그래프 분석 모델은 공급망을 서로 연결된 엔터티의 실제 네트워크로 표현해요. Neo4j Aura 데이터베이스를 사용하면 공급망 관리자는 네트워크 깊이에 상관없이 일관된 성능으로 여러 단계의 공급업체, 유통 센터, 운송 경로를 탐색할 수 있어요. 이를 통해 문제가 발생했을 때 실시간으로 영향 분석을 할 수 있을 뿐만 아니라, 기존 관계형 데이터베이스 시스템이 따라올 수 없는 사전 예방적 위험 관리도 가능해져요.

사용 사례: 위험 완화 및 경로 최적화

공장, 유통 센터, 항구, 운송 경로를 서로 연결된 그래프로 모델링함으로써 제조업체는 최적의 배송 경로를 식별하는 동시에 잠재적인 병목 현상을 빠르게 감지하고 예방할 수 있어요.

글로벌 제조업체가 Neo4j를 사용해서 어떻게 공급망을 최적화하는지 한번 살펴볼까요? 아래 시나리오는 다단계 공급망 전체에서 가시성 문제에 직면한 회사가 그래프 분석을 사용해서 전체 공급 네트워크를 그래프로 모델링하고 다음과 같은 통찰력을 얻는 방법을 보여줘요.

• 2차 및 3차 공급업체에 대한 의존도
• 구성 요소 전달을 위한 중요 경로
• 특정 지역의 위험 집중
• 문제 발생 시 대체 소싱 기회

Neo4j의 그래프 모델을 사용하면 신속하게 영향 평가를 하고 대체 공급업체를 활성화할 수 있어요. 최단 경로 알고리즘으로 밀리초 단위로 라우팅을 최적화하는 거죠. 그동안 매개 중심성은 단일 포트가 배송의 80%를 처리하는 것처럼 중요한 오류 지점을 정확히 찾아낸답니다.

Neo4j Aura는 재고 및 운송 시간부터 외부 위험까지 공급망 데이터를 효율적으로 분석해줘요.

사이버 보안 및 위협 탐지: 디지털 위협 환경 매핑

금융 서비스, 정부 기관 및 중요 인프라 부문이 직면한 문제는 정교한 위협인데요, 이들은 네트워크를 통해 측면으로 이동하면서 의도적으로 합법적인 동작을 모방해요. 이러한 위협은 알려진 공격 패턴에 의존하는 기존 탐지 임계값을 회피하죠.

그래프 분석은 보안 데이터를 격리된 경고나 로그가 아닌 상호 연결된 엔터티 및 이벤트로 모델링해요. 사용자, 장치, IP 주소 및 네트워크 활동을 Node와 Relationship으로 표시함으로써 Neo4j는 네트워크 전반에 걸쳐 시간이 지남에 따라 전개되는 공격 패턴을 추적할 수 있어요. 이러한 관계 중심 접근 방식을 통해 보안 팀은 기존 방식에서 볼 수 없었던 측면 이동, 권한 상승, 데이터 유출 시도를 탐지할 수 있는데, 이는 보안정보 및 이벤트 관리(SIEM) 시스템이 놓치는 부분이죠.

Neo4j Aura Graph Analytics 알고리즘은 겉으로는 관련이 없어 보이는 이벤트 사이의 미묘한 연결을 식별하여 매일 발생하는 수십억 건의 보안 이벤트 속에 숨겨져 있을 공동 공격을 밝혀낼 수 있답니다.

사용 사례: 피싱 캠페인에 대응

금융 기관은 공격자가 합법적인 기관을 사칭하여 중요한 시스템에 무단으로 액세스하는 정교한 피싱 캠페인에 직면해 있어요. 이러한 공격에는 일반적으로 스푸핑된 이메일, 가짜 웹사이트, 사회 공학적 전술 등 여러 접점이 포함되어 있어서 기존 보안 도구로는 탐지하기 어렵죠. 이러한 캠페인이 성공하면 자격 증명 도용, 계정 탈취, 그리고 궁극적으로 수천 명의 고객에게 영향을 미치는 데이터 침해로 이어질 수 있어요.

보안 팀의 과제는 여러 시스템과 기간에 걸쳐 서로 다른 지표를 연결하여 조정된 캠페인이 성공하기 전에 식별하는 거예요. 기존 SIEM 시스템은 새로운 공격 기술에 적응할 수 없는 사전 정의된 상관 관계 규칙에 의존하기 때문에 이러한 복잡한 공격 패턴을 식별하는 데 어려움을 겪죠.

보안 팀은 서로 다른 보안 데이터를 포괄적인 그래프 모델로 통합하여 이러한 문제를 극복할 수 있어요. 물리적 개체에 초점을 맞춘 공급망 모델링과 달리 사이버 보안 그래프는 계정, 장치, 애플리케이션 및 네트워크 리소스를 액세스 관계 및 상호 작용 이벤트와 통합합니다. 더욱이, Neo4j LLM 지식 그래프 빌더는 구조화되지 않은 보안 로그 및 위협 인텔리전스 보고서에서 엔터티와 관계를 추출할 수 있답니다.

보안 데이터에 대한 전체적인 뷰를 통해 금융 회사는 IP 주소, 장치 지문, 로그인 시도를 매핑해서 숨겨진 연결을 찾을 수 있어요.

예를 들어 공격자가 탐지를 피하려고 IP 주소를 바꿔도, 그래프 분석을 통해 단일 장치에서 접근하는 의심스러운 계정 클러스터가 드러날 수 있죠. 보안 팀은 그래프를 탐색하면서 네트워크를 통해 공격자의 측면 이동을 추적하고, 캠페인에서 잠재적으로 손상될 수 있는 모든 계정, 시스템, 데이터 세트를 식별할 수 있어요.

Neo4j의 중심성 알고리즘은 공격자가 표적으로 삼을 만한 중요한 리소스를 찾아낼 수 있어요. 예를 들어 PageRank는 과도한 권한을 가진 고도로 연결된 서버를 식별할 수 있고, Label Propagation은 유사한 행동 패턴을 보이는 손상된 사용자 계정 그룹을 탐지하는 데 도움이 되죠. 이런 알고리즘은 데이터베이스 크기에 상관없이 효율적으로 작동하기 때문에, 관계형 데이터베이스 쿼리를 손상시킬 수 있는 성능 저하 없이 페타바이트 규모의 보안 데이터에서 실시간 위협 검색이 가능해요.

콘텐츠 네트워크 및 미디어 인텔리전스: 정보 생태계 탐색

미디어 조직, 뉴스 매체, 콘텐츠 게시자는 콘텐츠, 주제, 객체, 청중 상호 작용 간의 복잡한 관계를 관리하는 데 어려움을 겪고 있어요. 기존 시스템은 키워드 매칭에 의존하기 때문에 콘텐츠 검색 및 인사이트 생성에 한계가 있죠.

그래프 분석은 정보 생태계의 자연스럽게 연결된 구조를 모델링해서 콘텐츠 관리를 혁신해요. Neo4j를 사용하면 조직이 Knowledge Graph를 만들 수 있어요. 기사, 주제, 사람, 장소, 이벤트는 복잡한 JOIN이 필요한 조각난 테이블이 아니라, 서로 연결된 네트워크로 존재하는 거죠. 이 접근 방식은 수백만 개의 문서에서도 일관된 쿼리 성능을 유지하면서, 기존 시스템이 감지할 수 없는 상황별 관계와 패턴을 드러내요.

사용 사례: 잘못된 정보 네트워크 식별

잘못된 정보 캠페인에는 생성된 콘텐츠를 개별적으로 분석할 때 합법적인 것처럼 보이는 조정된 계정 네트워크가 포함돼요. 격리된 콘텐츠에 초점을 맞추는 기존 조정 시스템은 이런 조직적인 노력을 제대로 감지하지 못하죠.

Neo4j는 구조화되지 않은 콘텐츠를 풍부한 Knowledge Graph로 변환해서 이런 문제를 해결해요. 여기서 엔티티와 그 관계가 눈에 보이게 되죠. 예를 들어 미디어 인텔리전스 회사는 사용자 계정, 콘텐츠, 해시태그, 참여 패턴을 상호 연결된 그래프로 모델링해서 정치적 행사 중에 수백만 개의 소셜 미디어 게시물을 분석할 수 있어요. 이렇게 표현하면 기존 분석에서는 보이지 않던 네트워크 구조가 바로 드러나죠.

사용자, 게시물, 관련 해시태그, 다양한 주제를 매핑해서 의심스러운 패턴을 찾아내는 샘플 그래프를 한번 살펴볼까요?

각 게시물은 개별적으로 보면 괜찮아 보일 수 있지만, 그래프에서는 조정된 콘텐츠 증폭, 공유 장치, 유사한 해시태그의 반복 사용을 나타내는 멀티홉 관계를 식별할 수 있어요.

Neo4j의 그래프 알고리즘은 사용자 참여를 분석하는 데 도움을 주는데요. 예를 들어, 학위 중심성 알고리즘(Degree Centrality Algorithm)을 통해 참여를 유도하는 영향력 있는 계정을 식별하고, 루뱅 알고리즘(Louvain Algorithm)으로 상호 작용 패턴을 기반으로 사용자를 의미 있는 커뮤니티로 분류할 수 있죠. 가장 중요한 점은 연결되지 않은 이데올로기 그룹을 연결하는 연결 중심성이 높은 계정이 잠재적인 잘못된 정보 슈퍼전파자로 식별될 수 있다는 거예요. 이러한 전략적 Node에 조정 노력을 집중함으로써 플랫폼은 광범위한 콘텐츠 검열 없이 허위 정보의 확산을 줄일 수 있답니다.

이러한 타겟 접근 방식은 잘못된 정보를 억제할 뿐만 아니라 사용자가 커뮤니티 내에서 그리고 네트워크 전반에서 상호 작용하는 방식을 밝혀 더 깊은 참여 통찰력을 제공해요.

의료 및 생의학 연구: 생명을 구하는 연관성 찾기

의료 서비스 제공자, 제약 회사, 연구 기관은 전자 건강 기록, 게놈 서열, 단백질 상호 작용, 임상 시험을 포괄하는 방대한 생물 의학 데이터 세트를 관리하고 있어요. 기존의 관계형 데이터베이스는 질병, 약물, 환자 간의 관계를 추적하기 어렵게 만드는 방식으로 데이터를 조각화하죠.

관계형 데이터베이스에서 생물학적 관계를 Query하는 작업은 경로 길이에 따라 기하급수적으로 느려지고, 다단계 분석에 많은 비용이 들어요. 다양한 생물 의학 데이터 형식과 온톨로지의 통합을 복잡하게 만드는 엄격한 Schema 요구 사항과 결합된 이러한 단편화는 약물 발견 노력과 포괄적인 환자 치료를 심각하게 방해한답니다.

그래프 분석은 생물학적 시스템을 단절된 데이터 사일로가 아닌 상호 연결된 네트워크로 표현함으로써 생의학 연구를 변화시키는데요. Neo4j의 Schema에 구애받지 않는 구조는 게놈 데이터, 단백질체학, 임상 기록, 연구 문헌을 통일된 Knowledge Graph로 원활하게 통합하여 의료 혁신을 주도하는 상황별 관계를 보존해요. 사전 정의된 JOIN 테이블이 필요한 관계형 데이터베이스와 달리 Neo4j는 관계 깊이에 대한 성능 저하 없이 3단계 약물-단백질-질병 상호 작용을 분석하든 10단계 대사 단계를 분석하든 상관없이 복잡한 경로를 지속적으로 탐색할 수 있어요. 이 기능은 전자 건강 기록(Electronic Health Record)과 CRISPR처럼 서로 다른 데이터 소스를 연결할 때 정말 중요하죠. 기존 시스템이 호환되지 않는 Schema와 지연된 Query 응답으로 어려움을 겪고 있는 심사 결과에요.

사용 사례: 약물 용도 변경

약물 용도 변경, 즉 기존 승인 약물에 대한 새로운 치료 응용 분야를 찾는 것은 일반적으로 10~15년과 수십억 달러가 소요되는 기존 약물 개발보다 더 빠르고 비용 효율적인 치료 경로를 제공해요. 하지만 유망한 용도 변경 후보를 식별하는 것은 쉽지 않아요. 단백질-단백질 상호 작용, 유전자 발현 패턴, 경로 분석, 임상 결과를 포함하여 서로 다른 데이터 세트에 걸쳐 복잡한 생물학적 상호 작용을 분석해야 하거든요. 기존의 데이터베이스 접근 방식은 이러한 다차원 관계 Query로 인해 어려움을 겪기 때문에 잠재적인 연결을 체계적으로 발견하는 것이 거의 불가능하답니다.

잠재적인 약물 용도 변경 기회를 식별하기 위해 약물, 질병, 유전자, 단백질 간의 관계를 명시적으로 모델링하는 샘플 그래프를 한번 살펴볼까요?

Neo4j는 질병, 약물, 유전자, 단백질, 경로 등 수많은 생물 의학 개체를 포괄적인 Knowledge Graph로 연결해줘요. 공개 데이터와 독점 데이터를 통합해서 기업은 생물학적 메커니즘, 약물 표적, 질병 경로에 대한 통합된 뷰를 만들 수 있죠.

게다가 Neo4j의 Text2Cypher 기능 덕분에, 해당 분야 전문가가 Natural Language Processing 쿼리를 사용해서 정교한 네트워크 분석을 수행할 수 있어요. 전문적인 프로그래밍 기술이 없어도 괜찮아요! 예를 들어 임상의가 "질병 Y에서 상향 조절되는 유전자 X와 동일한 경로를 표적으로 하는 승인된 약물은 무엇입니까?"라고 간단하게 질문할 수 있고, 잠재적인 용도 변경 기회를 시각적으로 매핑된 결과로 얻을 수 있는 거죠.

TensorFlow 같은 Machine Learning 프레임워크와 통합되면, Neo4j는 Graph Neural Network 기술을 통해 새로운 약물 상호작용과 부작용을 예측해서 약물 재활용을 향상시킬 수 있어요. 이런 모델은 Graph 표현 고유의 풍부한 관계 컨텍스트를 사용해서 기존 표 형식 데이터로는 불가능했던 예측 정확도를 달성하는 거죠.

IT 인프라 및 네트워크 관리: 디지털 생태계 매핑

복잡한 IT 인프라를 가진 대기업은 물리적 환경과 가상 환경 전체에서 컴포넌트 간의 관계를 모델링하고 분석하는 데 어려움을 겪고 있어요. 기존 도구는 현대 기술 생태계의 역동적이고 상호 연결된 특성을 제대로 포착하지 못하는 정적인 표현을 사용하기 때문에, 종속성을 이해하고 영향을 추적하며 중요한 경로를 식별하는 게 거의 불가능하죠.

Neo4j Aura Graph Analytics는 기술 환경을 자연스럽게 상호 연결된 시스템으로 모델링해서 IT 인프라 관리를 위한 이상적인 기반을 제공해요. Neo4j는 서버, 애플리케이션, 네트워크 장치, 서비스를 Nodes로 표현하고, 해당 종속성과 통신 경로를 Relationships로 표현해서 전체 생태계의 살아있는 지도를 만드는 거예요.

Neo4j는 다른 방법으로는 즉시 종속성을 매핑해요. 예를 들어 Configuration Management Database는 "이 서버에 장애가 발생하면 어떤 애플리케이션이 영향을 받나요?"와 같은 간단한 Query에 복잡한 JOIN이 필요한 관계형 데이터베이스를 기반으로 구축되었죠. 이는 컨테이너 오케스트레이션이 기존 인벤토리 시스템이 효과적으로 추적할 수 없는 지속적으로 변화하는 인프라를 생성하는 클라우드 네이티브 환경에서 특히 중요해요.

With Neo4j의 실시간 관계 모델링, IT 팀은 폭발 반경 계산을 즉시 시각화하고, 근본 원인 분석을 수행하고, 기존 모니터링 도구에 숨겨져 있던 단일 장애 지점을 식별할 수 있어요.

사용 사례: 클라우드 비용 최적화

환경이 점점 더 복잡해짐에 따라 클라우드 인프라를 최적화하는 건 점점 더 어려워지고 있어요. 일반적으로 조직은 사용되지 않는 Resources를 식별하고, 서비스 간의 종속성을 이해하고, 중요한 비즈니스 운영을 방해하지 않고 컴포넌트를 안전하게 폐기하는 데 어려움을 겪죠. 기존의 클라우드 관리 도구는 기본적인 사용량 지표를 제공하지만, Resources 간의 복잡한 관계 웹을 드러내는 데는 실패했어요. 이로 인해 고아 인스턴스, 과잉 프로비저닝된 서비스, 중복 컴포넌트에 대한 불필요한 지출이 발생해요. 이러한 종속성을 완전히 파악하지 못한 채 비용 절감 계획을 시도하면 기업은 예상치 못한 서비스 중단을 초래할 위험이 있어요.

예를 들어 아래 그래프는 데이터베이스 및 컴퓨팅 인스턴스와 같은 배포된 클라우드 애플리케이션에 대한 종속성을 보여줍니다.

클라우드 인프라에는 사용량 지표를 자세히 보지 않으면 찾기 힘든 고아 인스턴스가 있을 수 있어요.

SaaS 제공업체는 Neo4j를 사용해서 전체 클라우드 인프라를 연결된 그래프로 모델링해서 이런 문제를 해결할 수 있죠. 애플리케이션, 서비스, 데이터베이스, 컴퓨팅 리소스 간의 종속성을 매핑해서 직/간접적인 관계를 모두 보여주는 환경의 포괄적인 디지털 트윈을 만드는 거예요. Neo4j의 중심성 알고리즘을 사용하면 중요한 경로와 병목 현상을 식별하는 동시에, 여전히 비용이 발생하는 고아 리소스와 축소할 수 있는 활용도가 낮은 EC2 인스턴스를 찾을 수 있어요. 가장 중요한 점은, 그래프 시각화가 독립적으로 보이는 서비스 간의 숨겨진 종속성을 보여줘서 팀이 연속적인 오류 없이 중복 구성 요소를 안전하게 해제할 수 있다는 거죠.

Neo4j AuraDB의 실시간 `Query` 기능은 IT 팀이 인프라를 모니터링하고 문제를 해결하는 방식을 바꿔줘요. 제한된 컨텍스트로 미리 정의된 대시보드만 제공하는 기존 모니터링 도구와는 달리, Neo4j는 모든 시작점에서 전체 종속성 체인을 동적으로 탐색할 수 있어요. 사고가 발생하면 팀은 영향을 받는 모든 서비스, 데이터베이스, 애플리케이션 전반에 걸쳐 영향 경로를 즉시 추적할 수 있죠. 예를 들어, 깊이 우선 검색 경로 찾기 알고리즘을 사용하면 여러 서비스 계층에서 API 오류의 근본 원인을 빠르게 추적해서 평균 해결 시간을 크게 줄일 수 있어요. 이러한 실시간 관계 인식은 사전 비용 최적화와 사후 사고 관리 모두에 필요한 상황별 이해를 제공해요. 이건 플랫 파일 CMDB와 기존 모니터링 도구가 제공할 수 없는 기능이죠.

결론

그래프 분석은 기존 시스템이 효과적으로 해결할 수 없는 문제를 해결함으로써 연결된 데이터를 이해하는 새로운 방법을 조직에 제공해요. 그래프 기술은 데이터 포인트 간의 관계를 자연스럽게 모델링함으로써 사기 탐지에서 숨겨진 패턴과 관계를 찾아내고, 미묘한 추천을 제공하고, 복잡한 공급망을 최적화하고, 사이버 보안 방어를 강화하고, 콘텐츠 검색을 개선하고, 생물 의학 연구를 가속화하고, IT 인프라 관리를 단순화하죠.

Neo4j Aura 그래프 분석은 조직이 전문적인 인프라 전문 지식 없이도 그래프 솔루션을 빠르게 구축하고 확장할 수 있는 확장 가능하고 직관적인 플랫폼을 제공해요. 내장된 알고리즘, 직관적인 시각화 기능, 구조화된 데이터와 구조화되지 않은 데이터를 원활하게 결합하는 기능을 통해 팀은 데이터에서 실행 가능한 통찰력을 빠르게 얻을 수 있죠.

궁극적으로 Neo4j Aura Graph Analytics는 조직이 격리된 데이터 포인트를 넘어 비즈니스를 추진하는 관계에 대한 더 깊은 이해를 향해 나아가고 복잡한 과제를 성장과 혁신을 위한 명확한 기회로 전환하도록 도와요.

사랑하는 여러분,

많은 오픈 소스 커뮤니티에서는 사람들이 가입하고 탈퇴하지만, 우리 곁을 떠나는 경우는 드물죠.

정말 안타깝게도, 저희의 친구이자 동료인 Anders Nawroth가 지난 주말 세상을 떠났다는 소식을 전하게 되었어요.

그의 아내와 아들, 그리고 모든 가족들에게 깊은 위로를 전합니다. 사랑하는 친구이자 오랜 동반자를 잃은 슬픔에 함께 마음 아파하고 있어요.
Anders가 힘든 암 투병을 하는 동안 보여준 용기와 의지에 정말 감탄했어요. 모두가 희망을 놓지 않았지만, 결국 역부족이었고 그는 우리 곁을 떠나게 되었네요.

Neo4j를 처음 사용한 분들은 Anders가 작성한 문서와 예제들을 보면서 감동받았을 거예요. 눈에 잘 띄진 않지만, Anders의 작업은 Neo4j를 시작하고 사용하는 많은 사람들에게 큰 도움이 되었죠.

Anders는 조용하고 내성적인 사람이었지만, 사람들과 가르치는 것, 글쓰는 것에 큰 열정을 가지고 있었어요. 뛰어난 기술 작가이자 음악가였지만, 훌륭한 스토리텔러이자 작가이기도 했답니다.

Anders는 Neo Technology의 직원 #4였기 때문에 (현재는 120명이 넘어요!) 그가 없는 시간은 상상하기 어려워요. 그는 사람들이 데이터를 더 잘 이해하도록 돕는 우리의 미션에 깊은 관심을 가지고 있었죠.

조용하고 겸손한 성격 때문에 많은 사람들이 그를 과소평가했지만, 그의 생각과 유머, 지혜를 알아본 사람들은 그와 함께 즐거운 시간을 보냈을 거예요. Anders는 정말 좋은 친구였으니까요.

Anders는 자신의 몸 상태가 좋지 않아서 농담으로 자신의 몸을 '월요일의 농산물'이라고 부르기도 했어요. 하지만 그는 불평하는 대신, 주어진 상황에서 최선을 다하려고 노력했죠. 몸이 아플 때에도 다른 사람들을 돕고, 생각을 나누고, 피드백과 아이디어를 제공하기 위해 대화를 나누는 것을 멈추지 않았어요.

Michaela는 가족 외에 누구보다 Anders를 많이 챙겼어요. 우리 회사의 진정한 심장인 Michaela는 거의 매일 집과 병원을 방문했죠. Anders의 마지막 시간을 더 좋게 만들어준 Mica에게 정말 감사해요.

Anders는 모든 사람이 지식을 공유하고 아이디어와 콘텐츠에 대해 협력하도록 장려했어요. 그는 GraphGists와 DocGists를 오픈 소스 커뮤니티에 기여함으로써 이를 가능하게 했죠.

우리가 Neo4j 문서를 보거나 GraphGist를 사용하거나 그의 음악을 들을 때마다, 그의 유산은 우리 일상 속에 살아 숨 쉬고 있을 거예요.

AsciiDoctor의 창시자인 Dan Allen은 이렇게 말했어요.

앤더스는 제 삶에 큰 영향을 미쳤고, 놀라운 유산을 남겼습니다. 그는 항상 AsciiDoc 및 Asciidoctor의 영웅으로 기억될 거예요. DocGist를 사용할 때마다, 또는 문장 끝에 줄 바꿈을 추가할 때마다 그를 생각할 겁니다.

어쩌면 그의 음악을 통해 그가 어떤 사람이었는지 보여주는 것이 가장 좋을 것 같아요.

사랑하는 친구 Anders, 당신을 우리의 마음과 생각 속에 영원히 간직할게요. 우리 모두에게 영감을 줘서 정말 고마워요.

Farewell.

P.S. 많은 기사를 썼지만, 이렇게 어렵고도 쉬운 기사는 처음이었어요. Anders에 대해 좋은 말을 너무 많이 할 수 있지만, 그가 영원히 우리 곁을 떠났다는 사실을 깨닫는 것은 정말 마음 아픈 일이에요.

Going Meta 라이브 스트리밍 시리즈의 27개 에피소드에서는헤수스 바라사님이 semantics, 온톨로지, Knowledge Graph의 다양한 측면을 탐구했어요.

자, 이제 Going Meta 시즌 1을 마무리할 시간이에요.

정말 엄청난 성공이었죠! 매달 함께 해주신 여러분께 진심으로 감사드려요! Going Meta의 27개 에피소드가 모두 담긴 YouTube 재생 목록은 여기에서 확인하실 수 있어요.

이 글을 쓰고 있는 지금, YouTube 총 조회수는 79,000회를 훌쩍 넘었고, GitHub 저장소도 인기가 많았는데요. 여기에는 각 에피소드와 관련된 모든 자료(코드, 쿼리, 데이터 세트, 온톨로지, 노트북 등)가 모여 있답니다.

이제 새로운 시즌을 시작할 때가 된 것 같아요. 이전 시즌의 핵심 주제에서 완전히 벗어나진 않겠지만, GraphRAG와 Knowledge Graph에 좀 더 집중해보려고 해요.

시즌 1에서는 Graph Database, semantics, 온톨로지의 몇 가지 기본 원칙을 다뤘어요. 특히 Knowledge Graph를 깊이 있게 조사하면서 그 안에 숨겨진 무한한 가능성을 발견했고, 인공지능부터 데이터 관리까지 다양한 분야에 적용할 수 있다는 것을 알게 되었죠.

에피소드 20은 이미 그동안 다뤘던 내용을 요약하는 역할을 했는데요. 첫 번째 에피소드에서는 데이터 엔지니어링, 지식 관리, 개발자/데이터 통합, 고급 semantics라는 몇 가지 주제를 다루기도 했어요.

저희 웹사이트에서 모든 내용을 읽고 시청하실 수 있어요. 도 준비되어 있답니다. 이 글에서는 Going Meta 첫 번째 시즌을 마무리하는 추가 7개의 에피소드를 다룰 거예요.

Going Meta 20개 에피소드 요약

에피소드 21-27: GenAI, RAG 및 Knowledge Graph

21화부터는 AI 트렌드를 따라갔어요. 에피소드 전반에 걸쳐 다양한 주제를 섞는 대신, Knowledge Graph를 사용해서 GenAI 및 (Graph)RAG에 집중했죠. 각 에피소드에서는 새로운 측면을 다루고, Knowledge Graph와 온톨로지가 데이터 작업의 새로운 방식에 특히 어떻게 유용한지 보여줄 거예요.

(Graph)RAG

Retrieval-Augmented Generation은 2023년 말에 떠오르는 주제였으니, 자세히 살펴보는 건 당연하겠죠? 특히 Large Language Model(LLM)과 결합해서 Knowledge Graph 및 온톨로지를 통해 GenAI 결과를 더 정확하고, 상황에 맞게, 이해하기 쉽게 만드는 방법을 탐구했어요.

RAG 패턴이 어떻게 LLM의 창의력/환각 문제를 해결하고, 데이터 세트에서 AI 에이전트가 지원하는 그래프 모델로 이동하는 반사 에이전트를 구축하는 데 도움이 되는지도 살펴봤답니다.

에피소드:

Ep 22 — Knowledge Graph가 포함된 RAG
Ep 23 — Knowledge Graph를 사용한 고급 RAG 패턴
Ep 24 — KG+LLM: 온톨로지 기반 RAG 패턴
Ep 27 — LangGraph로 반사 에이전트 구축

도메인별 정보에 대해 벡터와 그래프를 사용하는 접근 방식, 또는 Knowledge Graph와 결합해서 사용하는 접근 방식을 비교해봤어요.

에피소드:

21 — 벡터 기반 Semantic Search 및 그래프 기반 Semantic Search
23 — Knowledge Graph를 사용한 고급 RAG 패턴

정확성과 특이성을 높이기 위해 Knowledge Graph와 LLM을 결합하는 경우가 많아서, 이 세그먼트의 모든 에피소드의 거의 일부가 됐죠. LLM을 사용해서 CSV 파일에서 Knowledge Graph를 만드는 방법도 살펴봤어요.

data.world 벤치마크를 자세히 살펴보면, 온톨로지가 포함된 Knowledge Graph가 LLM 결과를 크게 향상시키는 것으로 나타났어요.

에피소드:

Ep 25 — 자동화된 KG 구축을 위한 LLM
Ep 25 — LLM QA에서 KG의 역할에 대한 data.world 벤치마크 추출

시즌 2

하지만 여기서 멈추지 않을 거예요! 시즌 2가 곧 시작될 예정이거든요. 새 시즌을 통해 에피소드 27에서 시작한 작업을 이어가면서, Knowledge Graph와 GraphRAG의 병치 및 다양한 개념을 보여줌으로써 GenAI 지원 애플리케이션을 구축하는 방법에 대해 더 깊이 알아보고 싶어요.

Going Meta – Ep 27: LangGraph를 사용하여 반사 에이전트 구축

이렇게 하면 여러분이 따라가면서 아이디어를 훨씬 더 빠르게 실제 생활로 전환할 수 있는 기회를 얻게 될 거예요.

물론, 의미론과 존재론을 완전히 배제하지는 않을 거고요. 언제나 그렇듯이 여러분의 제안도 기다리고 있어요. 에피소드에 좋을 것 같다고 생각되는 내용이 있으면 핑(YouTube 댓글, Discord 등)을 보내주세요!

Going Meta가 2024년 6월부터 시즌 2 ( 에피소드 1)으로 돌아올 예정이에요. 앞으로의 여정에 계속 함께 해주시면 좋겠어요!

자원

RAG 정확도 향상을 위해 텍스트 추출, 네트워크 분석, LLM 프롬프트 및 요약을 결합합니다.

저는 종종 GraphRAG라고 불리는 그래프를 통한 Retrieval-Augmented Generation(RAG) 구현에 대한 새로운 접근 방식에 항상 흥미를 느껴요. 하지만 GraphRAG라는 용어를 들으면 모든 사람이 서로 다른 구현을 염두에 두는 것 같아요. 이번 블로그 게시물에서는 '로컬에서 글로벌로 GraphRAG' Microsoft 연구원의 기사 및 구현을 살펴볼게요. Knowledge Graph 구성 및 요약 부분을 다루고 검색기는 다음 블로그 게시물에 남겨 두겠습니다. 연구원들이 코드 저장소를 제공해줘서 정말 고마워요. 프로젝트 페이지도 있답니다.

위에서 언급한 기사에서 취한 접근 방식은 정말 흥미로워요. 제가 알기로는, 여러 소스의 정보를 압축하고 결합하기 위한 파이프라인의 한 단계로 Knowledge Graph를 사용하는 것이 포함되는데요. 텍스트에서 entity와 relationship을 추출하는 것은 새로운 것은 아니죠. 하지만 저자들은 압축된 그래프 구조와 정보를 다시 자연어 텍스트로 요약하는 참신한(적어도 저에게는) 아이디어를 소개해요. 파이프라인은 그래프를 생성하기 위해 처리되는 문서의 입력 텍스트로 시작돼요. 그런 다음 그래프는 다시 자연어 텍스트로 변환되죠. 생성된 텍스트에는 이전에 여러 문서에 분산된 특정 entity 또는 그래프 커뮤니티에 대한 요약 정보가 포함되어 있어요.

정말 간단하게 말하면, GraphRAG 파이프라인에 대한 입력은 다양한 정보가 포함된 소스 문서예요. 문서는 LLM을 사용하여 처리되어 해당 relationship과 함께 문서에 나타나는 entity에 대한 구조화된 정보를 추출하죠. 이렇게 추출된 구조화된 정보는 Knowledge Graph를 구성하는 데 사용돼요.

Knowledge Graph 데이터 표현을 사용하면 특정 entity에 대한 여러 문서나 데이터 소스의 정보를 빠르고 직접적으로 결합할 수 있다는 장점이 있어요. 앞서 언급했듯이 Knowledge Graph가 유일한 데이터 표현은 아니에요. Knowledge Graph가 구성된 후 그래프 알고리즘과 LLM 프롬프트의 조합을 사용하여 Knowledge Graph에서 발견된 entity 커뮤니티의 자연어 요약을 생성해요.

이러한 요약에는 특정 entity 및 커뮤니티에 대한 여러 데이터 소스와 문서에 분산된 요약 정보가 포함되어 있답니다.

파이프라인을 더 자세히 이해하려면 원본 문서에 제공된 단계별 설명을 참조하세요.

소개

GraphRAG용 Neo4j를 사용해 본 적이 있다면 이미 생성 모델의 출력 품질을 향상시킬 수 있는 잠재력을 알고 계실 거예요. 전통적으로 이를 위해서는 Neo4j와 Cypher에 대한 깊은 지식이 필요했죠. 이번 포스팅에서는 공식적으로 Neo4j GraphRAG Python 패키지(neo4j-graphrag)를 소개할게요. 이 패키지는 개발자를 위한 RAG(Retrieval-Augmented Generation) 애플리케이션에 Neo4j의 통합을 단순화하도록 설계되었답니다.

GraphRAG Python 패키지는 RAG 설정에서 검색 및 생성 프로세스를 효율적으로 관리할 수 있는 도구를 제공해요. 이 게시물이 끝나면 패키지를 사용하여 검색 작업을 실행하는 데 능숙해질 거예요. 다음 게시물에서는 전체 엔드투엔드 RAG 파이프라인을 구축할 수 있는 패키지 생성 기능에 대해 자세히 알아볼 거예요.

GraphRAG란 무엇입니까?

neo4j-graphrag 패키지는 GraphRAG(그래프 검색 증강 생성)를 용이하게 해줘요. Neo4j에서는 그래프 데이터베이스를 벡터 검색과 통합하는 것이 RAG의 다음 개척지를 대표한다고 믿고 있어요.

설정

영화 추천 Knowledge Graph를 시뮬레이션하는 사전 구성된 Neo4j 데모 데이터베이스에 연결하여 시작해 봐요. 다음에서 액세스하세요: 사용자 이름과 비밀번호로 "recommendations"를 사용하면 돼요. 이 설정은 Vector Embedding 데이터가 이미 사용할 준비가 된 Neo4j 데이터베이스의 일부인 현실적인 시나리오를 제공해 준답니다.

Cypher 명령어를 입력해서 데이터를 시각화해 보세요.

MATCH (n) RETURN n LIMIT 25;

오른쪽의 각 Node 세부 정보에서 plotEmbedding 속성을 확인해 보세요. 데모 전반에 걸쳐 Vector Search를 수행하기 위해 이러한 임베딩을 사용할 거예요. moviePlotsEmbedding이 존재하는지 확인하기 위해 Cypher 명령을 입력해서 Vector Index를 생성해 봅시다.

SHOW INDEXES YIELD * WHERE type='VECTOR';

Python 환경에서 다음 다른 패키지와 함께 neo4j-graphrag 패키지를 설치하세요.

pip install neo4j-graphrag neo4j openai

계속해서 Neo4j Python 드라이버를 사용하여 Neo4j 데이터베이스에 대한 연결을 설정해 봐요.

from neo4j import GraphDatabase
# Demo database credentials
URI = "neo4j+s://demo.neo4jlabs.com"
AUTH = ("recommendations", "recommendations")
# Connect to Neo4j database
driver = GraphDatabase.driver(URI, auth=AUTH)

이 데모를 위해서는 OpenAI API 키 세트가 있는지 확인해야 해요.

import os
os.environ["OPENAI_API_KEY"] = "sk-…"

검색

우리 패키지는 다양한 검색 전략에 맞춰진 다양한 검색기를 제공해요 (전체 목록에 대한 문서). 적절한 것을 선택하는 것은 특정 요구 사항에 따라 달라지죠. 여기서는 VectorRetriever 클래스를 사용할게요.

from neo4j-graphrag.retrievers import VectorRetriever
from neo4j-graphrag.embeddings.openai import OpenAIEmbeddings
embedder = OpenAIEmbeddings(model="text-embedding-ada-002")
retriever = VectorRetriever(
    driver,
    index_name="moviePlotsEmbedding",
    embedder=embedder,
    return_properties=["title", "plot"],
)

우리는 text-embedding-ada-002를 사용하는데, 데모 데이터베이스의 영화 플롯 임베딩이 이 모델을 사용하여 생성되어 보다 관련성 높은 검색 검색이 가능해졌기 때문이에요. 반환된 결과를 사용자 정의하는 방법이 있는데, 여기서는 Node 속성 title과 plot이 반환되도록 return_properties를 지정했어요.

검색어를 사용하여 Query와 밀접하게 일치하는 영화 줄거리를 검색하면 Approximate Nearest Neighbor Search를 실행하여 Query와 가장 잘 일치하는 상위 3개의 영화 줄거리를 식별해 준답니다.

query_text = "A movie about the famous sinking of the Titanic"
retriever_result = retriever.search(query_text=query_text, top_k=3)
print(retriever_result)

items=[
RetrieverResultItem(content="""
{'title': 'Titanic', 
 'plot': 'An unhappy married couple deal with their problems on board the ill-fated ship.'}""", 
  metadata={'score': 0.9450652599334717, 'nodeLabels': None, 'id': None}), 
RetrieverResultItem(content="""
{'title': 'Night to Remember, A', 
 'plot': 'An account of the ill-fated maiden voyage of RMS Titanic in 1912.'}""", 
  metadata={'score': 0.9428615570068359, 'nodeLabels': None, 'id': None}), 
RetrieverResultItem(content="""
{'title': 'Titanic', 
 'plot': 'A seventeen-year-old aristocrat falls in love with a kind, but poor artist aboard the luxurious, ill-fated R.M.S. Titanic.'}""", 
  metadata={'score': 0.9422949552536011, 'nodeLabels': None, 'id': None})] 

metadata={'__retriever': 'VectorRetriever'}

정규식을 사용해서 `retriever_result`를 더 자세하게 파싱할 수도 있어요.

import re

for k, item in enumerate(retriever_result.items):
    plot = re.search(r"'plot':s*'([^']*)'", item.content).group(1)
    title = re.search(r"'title':s*'([^']*)'", item.content).group(1)
    score = item.metadata["score"]
    print(f"Result {k}: {title} - {score} - {plot}")

Result 0: Titanic - 0.9450652599334717 - An unhappy married couple deal with their problems on board the ill-fated ship.
Result 1: Night to Remember, A - 0.9428615570068359 - An account of the ill-fated maiden voyage of RMS Titanic in 1912.
Result 2: Titanic - 0.9422949552536011 - A seventeen-year-old aristocrat falls in love with a kind, but poor artist aboard the luxurious, ill-fated R.M.S. Titanic.

GraphRAG

이제 `Retriever`가 간단한 GraphRAG 파이프라인에 어떻게 적용되는지 한번 살펴볼까요? `neo4j-graphrag` 패키지를 사용해서 GraphRAG 쿼리를 실행하려면 몇 가지 구성 요소가 필요해요.

1. Neo4j Driver — Neo4j 데이터베이스에 쿼리할 때 사용돼요.
2. Retriever — `neo4j-graphrag` 패키지에서 몇 가지 구현체를 제공하고, 만약 제공되는 구현체 중에 여러분의 요구사항에 맞는 게 없다면 직접 만들 수도 있어요.
3. LLM — 답변을 생성하려면 LLM을 호출해야겠죠? `neo4j-graphrag` 패키지는 현재 OpenAI LLM에 대한 구현체만 제공하지만, 인터페이스는 LangChain 채팅 모델과 호환되고 필요하다면 여러분만의 인터페이스를 만들 수도 있답니다.

실제로는 단 몇 줄의 코드만 있으면 돼요.

from neo4j-graphrag.llm import OpenAILLM
from neo4j-graphrag.generation import GraphRAG

# LLM
# Note: the OPENAI_API_KEY must be in the env vars
llm = OpenAILLM(model_name="gpt-4o", model_params={"temperature": 0})

# Initialize the RAG pipeline
rag = GraphRAG(retriever=retriever, llm=llm)

# Query the graph
query_text = "What movies are sad romances?"
response = rag.search(query_text=query_text, retriever_config={"top_k": 5})
print(response.answer)

다양한 유형의 `Retriever`를 커스터마이징하는 방법은 다음 포스팅에서 자세히 알아볼게요.

요약

여러분을 초대해서 neo4j-graphrag 프로젝트에 패키지화하고, 댓글이나 GraphRAG를 통해 여러분의 통찰력을 공유해주시면 감사하겠습니다. 디스코드 채널을 통해서도 소통할 수 있어요.

패키지 코드는 오픈 소스이고 에서 찾을 수 있습니다. 언제든지 이슈를 올려주세요!

GenAI(생성 AI) 애플리케이션을 구축하기 위한 언어, 프레임워크, 도구 옵션이 정말 많죠? 이제 막 시작하는 단계라면 이런 결정을 내리고 모든 것을 통합하는 방법을 알아내는 게 부담스러울 수 있어요.

우리 팀은 몇 가지 핵심 기술이 포함된 스타터 키트 프로젝트를 제공해서 이 프로세스를 단순화하려고 사전 패키지된 솔루션을 개발해 왔어요. 그 중 하나가 바로 오늘 포스팅 주제인 Java에서 Spring AI를 사용해서 GenAI 애플리케이션을 구축하는 방법이에요.

Spring AI란 무엇인가요?

Spring AI는 GenAI 애플리케이션을 구축하기 위한 프레임워크예요. LLM(Large Language Model) 및 RAG(Retrieval-Augmented Generation)와 같은 GenAI 모델 및 아키텍처 작업을 위한 도구와 유틸리티를 제공하죠. Java에는 GenAI를 위한 다른 옵션도 있지만 Spring AI는 다양한 커뮤니티에 걸친 소수의 Neo4j 초기 통합 중 하나랍니다.

이 프로젝트에는 무엇이 포함되어 있나요?

모든 코드와 배경 정보는 spring-ai-starter-kit GitHub 저장소에 있어요. 여기서 일부 코드를 살펴볼 거지만, 언제든지 저장소를 다시 참조할 수 있어요.

Neo4j를 사용해서 구조화된 데이터(예: entity 및 relationship)는 물론 관련 Vector Embedding이 포함된 구조화되지 않은 텍스트 데이터를 저장해요. 벡터에 대한 유사성 검색을 실행한 다음, 검색 `query`를 실행해서 추가 관련 entity를 가져올 수 있죠. 오늘은 OpenAI 모델을 선택할게요. 하지만 다른 모델로 교체할 수도 있어요. Spring AI 지원 LLM를 참고하세요.

프로젝트의 pom.xml 파일을 살펴보면 이 프로젝트에 포함된 네 가지 종속성을 확인할 수 있어요.

• Spring Web(REST API 생성용)
• OpenAI(또는 Mistral AI, Ollama 등과 같은 기타 LLM 모델)
• Neo4j 벡터 데이터베이스(벡터 저장 및 `query`용)
• Spring Data Neo4j(Spring 애플리케이션에서 Neo4j 작업용)

우리가 사용하는 데이터 세트는 EDGAR에서 제공한 SEC 서류예요. 여기에는 회사 및 개인 서류 제출을 위한 문서 모음이 포함되어 있죠. 문서는 일반 텍스트로 되어 있고, 다양한 회사에 대한 재무 정보가 포함되어 있어요. 우리 팀은 이 데이터를 회사, 재무 형태 및 관리자에 대한 정보가 포함된 Knowledge Graph로 정리했어요. 여기에는 다음이 포함돼요.

1. 양식 10-K — 상장 회사가 SEC에 제출해야 하는 연례 보고서. 회사의 재무 성과에 대한 포괄적인 요약을 제공해요.
2. 양식 13 — 1억 달러 이상의 자산을 관리하는 기관 관리자가 제출함

Neo4j로 노래와 가사 카탈로그를 만들고, 내장된 Gen AI 기능으로 내용 기반 노래 찾기!

여러분, 노래 제목이나 누가 불렀는지 기억은 안 나는데, 대략적인 내용만 어렴풋이 기억나는 노래를 찾고 싶었던 적 없으신가요? 딱 4줄의 코드로 이 문제를 해결하는 도구를 만들어 볼 거예요.

인터넷은 금방 지나갈 과대 광고일 뿐이에요. 장기적으로 봤을 때, 사람들이 인터넷 서핑에 그렇게 많은 시간을 쏟고 싶어 하진 않을 거라고 생각해요.

이 말은 1996년에 스웨덴 통신부 장관이었던 이네스 우스만(Ines Uusmann)이 했던 말인데요. 그녀의 말처럼 인터넷이 과대 광고였을 수도 있죠. 하지만 인터넷은 이미 20년 넘게 우리 곁에 있었고, 이제는 절대 사라지지 않을 존재에 대한 과대 광고였던 것 같아요. 인터넷 없는 현대 생활은 상상하기 힘들 정도니까요. 사실 90년대 초반에 과대광고를 불러일으킨 건 바로 월드 와이드 웹(World Wide Web)의 등장 때문이었죠.

마찬가지로 많은 사람들이 AI를 과대 광고라고 부르기도 해요. 물론 그럴 수도 있지만, 인터넷의 과대 광고와 굉장히 비슷하다고 생각해요. AI는 반세기가 넘는 역사를 가지고 있고, 오늘날의 인터넷처럼 우리 삶에 필수적인 존재로 계속 남아있을 거라고 믿어요. 인터넷에 WWW가 있다면, AI에는 LLM(Large Language Model)과 GenAI 같은 존재가 있는 거죠.

만약 제 예측이 맞다면, 특히 소프트웨어 개발자라면 ChatGPT와 대화하는 것뿐만 아니라, 이 기술을 직접 사용하는 방법을 배우면서 새로운 기술을 배우고 받아들이는 게 중요할 거예요. 그리고 그렇게 하기 위해 꼭 수학자일 필요도 없어요! AI를 쉽게 사용할 수 있도록 도와주는 훌륭한 도구들이 정말 많거든요. 그중 하나가 바로 Neo4j랍니다.

Neo4j와 AI

Vector Search가 뭔지 너무 깊게 들어가진 않을게요. 간단하게 설명하자면, 벡터는 화살표처럼 길이와 방향을 가진 것이라고 생각하면 돼요. 2차원에서는 아래 그림처럼 x와 y 두 숫자로 벡터를 표현할 수 있죠.

Vector Embedding은 LLM이 자연어 텍스트(또는 이미지나 음악)의 내용을 나타내는 단일 벡터를 생성하도록 하는 건데요. 예를 들어, 이 블로그 글 전체를 하나의 벡터로 표현하는 거죠. 그런데 위 그림처럼 2차원 벡터가 아니라, 1000차원이 넘는 벡터(OpenAI의 경우 1536차원)를 사용해요. 이렇게 텍스트를 숫자로 표현한 다음, 이걸 이용해서 GenAI와 Neo4j에 대한 다른 블로그 글(제가 쓴 글이 몇 개 있어요 😉)처럼 비슷한 텍스트를 검색할 수 있는 거예요. 이때 텍스트에 사용된 단어의 유사성이 아니라, 텍스트의 실제 의미(LLM이 이해하도록 설계된)를 기준으로 검색하는 거죠.

Neo4j를 사용하면 Vector Embedding을 Node의 Property로 저장한 다음, 특정 임베딩과 유사한 Node를 검색할 수 있어요. 검색 속도를 높이기 위해 이런 벡터들을 Indexing할 수도 있고요. 바로 이 기능을 이용해서 가사 검색기를 만들 거예요.

가사 검색기가 왜 필요할까요?

그런데 왜 이런 도구를 만들고 싶을까요? ChatGPT도 이 기능을 꽤 잘하거든요. 예를 들어, 제가 ChatGPT에게 이렇게 물어봤어요.

메탈리카 노래 중에 전쟁에서 심하게 다쳐서 감각을 잃은 남자에 대한 노래가 뭐였지?

그러자 ChatGPT는 이렇게 대답했어요.

당신이 언급한 메탈리카의 노래는 'One'입니다. "One"은 1988년 앨범 "...And Justice for All"의 트랙입니다. 이 곡은 제1차 세계대전 당시 부상을 입어 시각, 청각, 언어 등 모든 감각을 잃은 군인의 이야기를 담은 달튼 트럼보(Dalton Trumbo)의 소설 'Johnny Got His Gun'에서 영감을 받았다. 메탈리카는 이 노래에서 전쟁의 공포와 고통, 그리고 그러한 비극적인 상황에서 일어날 수 있는 개인의 정체성 상실을 전달한다.

음, 우리가 직접 이런 도구를 만들고 싶은 이유는 몇 가지가 있어요.

• ChatGPT는 Language Model이 훈련될 때 존재했던 정보만 알고 있어요. 그래서 만약 메탈리카의 최신 앨범 '72 Seasons'에 수록된 곡이었다면 찾지 못했을 거예요.
• ChatGPT는 훌륭하지만, 완전히 신뢰할 수는 없어요. 때로는 솔직한 거짓말을 하기도 하거든요.
• Spotify 같은 음악 서비스에 이 기능을 넣는다면, 모든 노래가 아니라 라이브러리에 있는 노래만 검색하면 되겠죠.
• 그리고 Spotify 같은 도구에 이런 기능을 통합하려면, 채팅 기능보다는 좀 더 명확하게 정의된 API를 통합하고 싶을 거예요.

우리가 만들 도구

시작하기 전에 OpenAI 계정을 만들어야 해요. Neo4j는 임베딩을 수행하기 위해 OpenAI, VertexAI, AWS Bedrock을 지원하지만, 이번에는 OpenAI를 사용할 거예요. OpenAI 계정은 유료 계정이라서 비용이 발생할 수 있지만, 제가 이 글을 쓰면서 테스트하는 데 사용한 비용은 2센트도 안 됐어요. OpenAI 계정에서 API Key를 생성해야 하고, 이 키는 아래 쿼리에서 $apiKey로 사용될 거예요.

GenAI 지원은 Neo4j 5.x 버전에서 점진적으로 이루어졌는데요. 여기서 사용할 가장 최신 기능인 임베딩 절차는 Neo4j 5.15에서 출시되었기 때문에, 이 버전을 사용할 거예요.

Neo4j 자체 인스턴스를 사용하고 있다면, neo4j-genai-plugin-5.XX.0.jar 파일을 복사해서 plugins 폴더에 넣어준 다음 Neo4j를 재시작해야 해요. AuraDB를 사용하고 있다면, 기본적으로 이 기능들을 바로 사용할 수 있답니다.

이 글의 내용을 테스트해보고 싶다면 AuraDB Free 인스턴스를 설정하는 것도 좋은 방법이에요. 여기서 무료 계정을 만들 수 있어요: 그리고 인스턴스를 만들어서 직접 테스트해볼 수 있죠. OpenAI 계정도 필요하다는 점, 잊지 마세요!

이번 글에서는 특정 기능을 구현하는 애플리케이션을 만들지는 않을 거예요. 대신 Neo4j Browser에서 Cypher 쿼리를 작성해볼 건데요, 실제 서비스를 개발한다면 당연히 이 쿼리들을 애플리케이션 코드에 통합해야겠죠?

세상 모든 노래에 대해 다 해보면 좋겠지만, 아쉽게도 그런 데이터를 구할 수가 없어서... 대신 St. Anger 앨범까지의 Metallica 노래 가사 라이브러리를 찾았어요. HTML 형식이었지만, 가사를 파싱해서 아티스트 (여기서는 Metallica 하나뿐!), 앨범, 노래로 이루어진 그래프를 만들었답니다. 노래 가사는 각 `Song` **node**의 문자열 **property**로 저장했어요.

직접 테스트해보고 싶다면, 아래 코드를 실행해서 똑같은 데이터셋을 가져올 수 있어요. 물론, 아래 `import` 구문에서 사용하는 것과 동일한 **스키마**를 따른다면, 좋아하는 아티스트와 노래를 사용해도 괜찮아요!

LOAD CSV WITH HEADERS FROM 'https://drive.google.com/uc?export=download&id=1uD3h7xYxr9EoZ0Ggoh99JtQXa3AxtxyU' AS line
CREATE (song:Song {name: line.Song, lyrics: line.Lyrics})
MERGE (album:Album {name: line.Album})
MERGE (artist:Artist {name: line.Artist})
MERGE (song)-[:IS_ON]->(album)
MERGE (album)-[:PERFORMED_BY]->(artist)

자, 이제 **database**가 준비됐으니, 제일 먼저 할 일은 **vector**에 사용할 **property**에 대한 **vector index**를 만드는 거예요. 여기서는 `embedding`이라는 **property**를 사용할 거고, `Song` **node**에 저장할 거예요. `1536`은 **vector**의 차원인데 (OpenAI가 사용하는 차원과 같아요!), 마지막 **property**인 `'cosine'`은 사용할 유사도 알고리즘이에요. 일반적으로 `'cosine'`이 가장 많이 쓰인답니다.

CREATE VECTOR INDEX song_embeddings IF NOT EXISTS
FOR (s:Song) ON (s.embedding)
OPTIONS {
  indexConfig: {
    `vector.dimensions`: 1536,
    `vector.similarity_function`: 'cosine'
  }
}

다음으로는 모든 노래 가사에 대한 **Vector Embedding**을 추가해야 해요. 간단한 `MATCH` **query**를 사용해서 노래를 찾은 다음, 가사 **property** 문자열을 **embedding** 함수에 전달하면 돼요.

MATCH (song:Song)
WITH song, genai.vector.encode(song.lyrics, "OpenAI", {token: $apiKey}) AS vector
CALL db.create.setNodeVectorProperty(song, "embedding", vector)

`db.create.setNodeVectorProperty()` **procedure**는 `SET song.embedding = 임베딩`과 똑같은 역할을 하지만, **vector**를 더 효율적인 형식으로 저장해준다는 점이 다르답니다.

이 **query**는 **database**에 있는 모든 노래에 대해 OpenAI **API**를 한 번씩 호출하기 때문에, 실행하는 데 시간이 좀 걸릴 거예요. 위 함수 대신 **batch procedure**를 사용하는 방법도 있는데, 이 경우에는 (여기서는) 단 한 번의 **API** 호출만 발생해요.

MATCH (song:Song)
WITH collect(song.lyrics) AS lyrics, collect(song) AS songs
CALL genai.vector.encodeBatch(lyrics, "OpenAI", {token: $apiKey}) YIELD index, resource, vector
CALL db.create.setNodeVectorProperty(songs[index], "embedding", vector)

여기서 주의할 점은 한 **batch**에 포함할 수 있는 항목 수에 제한이 있다는 거예요 (OpenAI의 경우 2048개). 따라서 **database**에 Metallica 말고 다른 아티스트의 노래도 있다면, 예를 들어 아티스트별로 또는 앨범별로 나눠서 처리해야 할 거예요.

자, 이제 모든 설정이 끝났으니 가사 **search**를 수행할 준비가 됐어요. 검색할 문구는 `phrase`라는 **parameter**로 설정하고, `apiKey`는 여전히 **parameter**로 유지할 거예요 (아래에는 표시하지 않았지만요).

:params 
{
  phrase: "A song about a guy who is so badly wounded in war so he no longer has any senses",
  apiKey: "*****"
}

**search**를 하려면, 먼저 똑같은 함수를 호출해서 검색 문구에 대한 **Vector Embedding**을 생성해야 해요. 그런 다음, 전용 **procedure**를 사용해서 **database**에서 가장 유사한 **embedding**을 가진 노래를 찾아주는 **vector search**를 수행하면 된답니다.

WITH genai.vector.encode($phrase, "OpenAI", {token: $apiKey}) AS embedding
CALL db.index.vector.queryNodes('song_embeddings', 1, embedding) YIELD node AS song, score
RETURN song.name

이것이 우리에게 DISPOSABLE HEROES라는 답을 주네요. 글쎄요, 그건 우리가 기대했던 건 아니었어요. 우리는 ONE을 생각하고 있었거든요. DISPOSABLE HEROES 역시 고통에 대한 전쟁 노래이기 때문에 정답이긴 하지만, 우리가 원하는 건 아니죠. 이건 정확한 과학이 아니니까요. 그래서 일반적으로 최고의 일치 항목 수를 요청하는 게 가장 좋아요. 올바른 것은 일반적으로 상위 3~5개 결과에 있거든요. queryNodes의 두 번째 매개변수는 우리가 원하는 결과이니까, 이를 3으로 늘리면 돼요.

WITH genai.vector.encode($phrase, "OpenAI", {token: $apiKey}) AS embedding
CALL db.index.vector.queryNodes('song_embeddings', 3, embedding) YIELD node AS song, score
RETURN song.name

이제 다시 실행해볼게요.

DISPOSABLE HEROES
ONE
ONE

됐네요! 두 번째 일치로 올바른 것을 얻었어요. 그리고 세 번째 경기는…? 왜 우리는 그것을 두 번 얻을까요? 음, 두 개 이상의 앨범에 포함되어 있기 때문에 우리가 모델링한 대로 데이터베이스에 복제되는 거죠.

이것이 우리 솔루션을 뒷받침하는 Knowledge Graph를 갖는 것이 매우 좋은 점이에요. 가사를 기반으로 노래를 찾은 다음 그래프를 탐색하여 다른 모든 것을 찾을 수 있거든요.

WITH genai.vector.encode($phrase, "OpenAI", {token: $apiKey}) AS embedding
CALL db.index.vector.queryNodes('song_embeddings', 3, embedding) YIELD node AS song, score
MATCH (song)-[:IS_ON]->(album:Album)-[:PERFORMED_BY]->(artist:Artist)
RETURN song.name AS Song, album.name AS Album, artist.name AS Artist

이제 결과는 이렇습니다.

Song                Album                  Artist
DISPOSABLE HEROES   MASTER OF PUPPETS      Metallica
ONE                 S&M                    Metallica
ONE                 And Justice For All..  Metallica

이제 제대로 작동하는지 확인하기 위해 한 번 더 테스트하면 돼요. 이번에는 다음을 검색해볼게요.

악몽을 꾸는 소년의 노래

결과는 다음과 같아요.

Song                           Album                  Artist
Enter Sandman                  Black Album            Metallica
Enter Sandman                  S&M                    Metallica
The thing that should not be   MASTER OF PUPPETS      Metallica

Enter Sandman은 제가 의도한 것이므로 성공이라고 해야겠죠?

됐어요. 네 줄의 코드로 지능형 노래 시놉시스 찾기를 완료했어요!

참고 자료

Vector Search Index에 대한 문서는 다음과 같아요.

벡터 검색 인덱스 – Cypher 매뉴얼

여기에서 내장 함수/절차에 대한 문서를 찾을 수 있어요.

GenAI 통합 – Cypher 매뉴얼

확장 법칙은 정체될 수 있지만 GenAI는 줄어들지 않았어요. 엔지니어들은 어디에서나 무엇이 작동하고 어떻게 유용하게 만들 수 있는지 알아내느라 바빴죠. GraphRAG, 즉 Knowledge Graph와 Retrieval-Augmented Generation (RAG)이 결합된 기술은 다양한 기술로 발전해 왔고, 연구 논문과 소프트웨어 통합도 활발하게 이루어지고 있어요.

이 점을 염두에 두고 두 번째 GenAI 그래프 모임을 준비했고, 그래프와 LLM의 교차점에서 일하는 뛰어난 분들을 초대했어요. 목표는 GraphRAG 주변에서 일어나는 많은 일에 대한 메모를 파악하고 비교하는 것이었답니다.

회고전: 5월부터 지금까지

5월 첫 번째 GenAI 그래프 모임 이후 GraphRAG의 타임라인이에요 (완전하진 않지만요!).

처음에 GenAI 그래프 모임에서 GenAI 애플리케이션이 세 가지 주요 버킷의 소스 데이터를 사용하는 것을 관찰하면서 검색을 위해 Knowledge Graph를 사용하는 방법을 탐색했었죠.

1. 텍스트 파일 또는 PDF의 구조화되지 않은 데이터
2. 기존 데이터베이스의 구조화된 데이터
3. 두 가지가 결합된 혼합 데이터

여름 동안 개발자와 기업의 관심이 엄청나게 증가했어요. 프로젝트는 "PDF로 채팅" 또는 "CSV로 채팅"과 같이 구조화되지 않았거나 구조화된 데이터로 시작하는 경향이 있었죠. 하지만 첨단 기술이 앞으로 나아갈 길을 제시했음에도 불구하고 많은 사람들이 파일럿 단계에서 정체되었어요.

개념 증명 이상의 일을 할 수 있었던 사람들의 공통점은 무엇이었을까요? 저희 경험에 따르면 비정형 데이터와 정형 데이터 사이에 더 강력한 연결이 있어서 혼합 데이터의 최적 지점에 도달하는 것 같았어요.

편집자 주: 이 강연은윌 리옹 at 클라우드 개발자를 위한 Neo4j의 Connections 이벤트 그래프.

풀스택 개발자의 관점에서 Neo4j가 현대 클라우드 생태계에 어떻게 적응하는지 공유할게요. 저는 Neo4j의 개발자 관계 팀에서 일하고 있고, Neo4j와 다양한 기술을 통합하고 고객이 이미 이 작업을 수행하는 방법을 살펴보는 데 많은 시간을 보내고 있어요.

Neo4j 그래프 플랫폼

데이터베이스로서 Neo4j는 우리 애플리케이션의 아키텍처 핵심에 딱 맞는 것 같아요. 우리가 생각해야 할 것은 Neo4j가 다른 기술과 어떻게 작동하는지인데, 이는 우리가 달성하려는 목표에 따라 달라지죠. 위 다이어그램에서 오른쪽의 데이터 과학 및 분석 사용 사례부터 왼쪽의 더 많은 트랜잭션 운영 애플리케이션 구축에 이르는 스펙트럼을 볼 수 있어요. 이 블로그를 통해 저는 스펙트럼의 왼쪽 측면에 더 집중하고, 예를 들어 클라이언트와 데이터베이스 사이에 있는 API 계층을 구축하여 Neo4j로 운영 워크로드를 처리하는 방법을 공유할 거예요.

랍스터 그래프 애플리케이션

Lobsters는 Hacker News와 비슷한 뉴스 애그리게이터 사이트인데, 댓글을 보면 좀 더 친근한 느낌이 들 수도 있어요. 기술 커뮤니티에서 무슨 일이 일어나고 있는지 살펴보기 좋은 사이트죠. 그래서 Lobsters 사이트의 그래프 버전을 만들어보면 재미있을 것 같아서, "Lobsters Graph"라는 이름으로 만들어봤어요. 기본적으로 Lobsters에서 데이터를 가져오는 그래프 시각화 애플리케이션이에요. 여전히 인기 있는 기사와 관련 주제를 볼 수 있지만, 정보를 좀 더 시각적인 방식으로 볼 수 있다는 게 장점이죠. 기사의 태그와 주제를 기반으로 내가 관심 있는 내용을 더 빠르게 확인할 수 있고요. Lobsters Graph가 어떻게 생겼는지 간단하게 보여주는 데모 영상이에요.

애플리케이션 아키텍처

데모에서 보셨듯이, 아주 간단한 그래프 시각화 애플리케이션이에요. 이제 이 애플리케이션을 어떻게 구축했는지, 좀 더 구체적으로 아키텍처가 어떤 모습인지 자세히 살펴볼게요. 풀 스택 개발자로서 우리가 다루는 문제들을 보여주는 몇 가지 흥미로운 부분들이 있거든요. Lobsters의 JSON endpoint에서 데이터를 가져와 Neo4j에 로드하는 방법, 그리고 Neo4j에 데이터가 있으면 해당 데이터를 애플리케이션 계층에 노출하는 방법을 공유할게요.

Neo4j로 데이터를 가져오는 방법

가장 먼저 Neo4j AuraDB 인스턴스를 실행해야 해요. 저는 AuraDB 무료 인스턴스를 사용했는데, 이런 취미 프로젝트를 시작하기에 딱 좋은 방법이죠. 다행히 Lobsters는 데이터를 몇 가지 JSON 피드에 게시하고 있어요. 예를 들어, hottest.JSON endpoint는 순위가 가장 높은 기사를 기준으로 정렬된 리더보드 역할을 해요. 최신 endpoint도 있어서 Lobsters에 게시된 최신 기사를 추적할 수도 있고요.

그래프 데이터 모델링

다음 단계는 반복적인 과정인 그래프 데이터 모델링이에요. 제 소스 데이터는 JSON이고요. 이걸 그래프로 표현하기 위해, 먼저 Node가 될 엔터티를 식별하는 것부터 시작해요. 이 경우에는 Node는 기사, 기사를 게시한 사용자, 그리고 기사와 연결되는 태그가 되겠죠.

그 다음에는 이러한 개체들이 어떻게 연결되어 있는지 생각해요. 이게 바로 Relationship이 되는 거죠. 마지막으로, 제가 가지고 있는 Property들을 살펴보죠. 예를 들어 기사에는 ID, URL, 관련 점수가 있어요. 이러한 Property들은 Node나 Relationship에 저장되는 속성이 되는 거예요. 이 반복적인 프로세스의 마지막 단계는 애플리케이션과 데이터 모델의 비즈니스 요구 사항을 살펴보고, 비즈니스 요구 사항에 대한 질문에 답하는 이 그래프를 통한 순회가 있는지 확인하는 거예요.

이 경우에는 매우 간단해요. 상위권 기사도 보고 싶고, 태그도 보고 싶어요. 그리고 동일한 태그가 있는 다른 기사를 볼 수 있기를 원하죠. 따라서 기사 Node를 ID나 점수별로 정렬하고, 해당 태그 Relationship을 순회해야 한다고 생각하게 돼요. 이 데이터 모델링 프로세스를 진행하면서 다음과 같은 훌륭한 도구를 사용할 수 있어요. Arrows는 다이어그램을 그리는 데 유용하죠. Arrows에서 다이어그램을 그린 후에는 이미지로 내보낼 수도 있고, 데이터 모델을 설명하는 JSON을 내보낼 수도 있어요. JSON 데이터를 버전 제어로 관리하고 프로젝트에 참여하는 다른 사람들과 모델을 공유할 수 있다는 점이 정말 좋죠.

Cypher에서 JSON 데이터 작업

이제 데이터 모델과 JSON 데이터가 준비되었어요. 여기서부터는 Cypher를 사용해서 해당 JSON 데이터를 가져와 Neo4j에 로드할 거예요. 다행히 Neo4j에는 APOC Load JSON procedure가 있답니다.

이건 APOC 절차 라이브러리의 일부인데요, APOC를 표준 라이브러리처럼 생각하면 돼요. 몇몇 프로시저와 기능으로 Cypher를 확장해주고, JSON 데이터 작업을 가능하게 해주거든요. apoc.load.json과 함께라면, JSON 엔드포인트로 가서 Cypher를 사용해 데이터를 다시 가져올 수 있어요. 들어오는 JSON 객체(여기선 객체 배열)를 반환하는 것뿐이지만, Cypher를 사용해서 그래프에서 만들고 싶은 데이터 모델을 설명하고 Cypher로 풀어낼 수 있죠. 각 기사에 대해 Cypher를 써서 기사 `Node`, 사용자 `Node`, 태그, 그리고 `Relationship`을 그래프에 생성하는 거예요.

이렇게 Cypher 구문 하나로 데이터를 로드했어요. 이제 Neo4j Browser나 Bloom을 사용해서 쿼리할 수 있죠. 랍스터 데이터를 특정 시점에 표현하는 데는 괜찮지만, 인터넷 검색을 할 때 매일 아침 사이트에 가서 그날의 블로그를 읽고 싶을 수도 있잖아요? 그럼 데이터는 계속 새로고침되어야 하고, 이 스크립트를 제 컴퓨터에서만 실행할 수는 없겠죠. 클라우드에 지속적으로 실행되면서 랍스터 데이터를 가져오는 무언가가 필요할 거예요.

Github 작업 – 플랫 데이터 크론 작업

바로 이럴 때 GitHub Actions가 등장하는 거죠! GitHub 이벤트에 응답하는 맥락에서 GitHub Actions를 많이 보셨을 텐데요. 예를 들어 코드를 체크인하거나 GitHub에 Pull Request가 들어오면 GitHub Actions를 사용해서 테스트를 실행하거나 배포를 트리거할 수 있어요. GitHub Actions를 cron 작업처럼 사용해서 매시간, 매일 실행할 수도 있고요.

GitHub 팀에서 플랫 데이터라는 GitHub Action을 출시했는데, 정말 깔끔하더라고요. 이걸 사용하면 JSON이나 CSV 같은 플랫 파일 엔드포인트로 가는 GitHub 작업을 만들거나, 주기적으로 데이터베이스 `Query`를 실행한 다음 해당 데이터를 GitHub에 커밋할 수 있어요. 데이터에 대한 기록도 남길 수 있고, 데이터를 데이터베이스에 로드하는 등의 후처리 단계도 정의할 수 있죠.

위에서 보시는 것처럼 GitHub 리포지토리에서는 이 플랫 데이터 GitHub 작업을 사용해서 Lobsters JSON 엔드포인트로 이동하고, 최신 .json 파일을 가져와 GitHub에 체크인하는 YAML 파일을 생성해요. 이 데이터는 자주 바뀌는 데이터가 아니라서 cron에서 매시간 실행되도록 설정해뒀어요.

Github 작업: 데이터 로드를 위한 평면 그래프

해당 데이터를 Neo4j Aura에 로드하기 위한 후처리 작업으로, 저는 평면 그래프라는 간단한 GitHub Action을 만들었어요. 이걸 사용하면 JSON 데이터로 작업하는 방법(여기서는 Cypher를 사용하겠죠?)을 정의할 수 있답니다.

전체 YAML 파일은 다음과 같아요.

먼저 Flat Data GitHub Action을 사용해서 최신 .json 파일을 가져와요. 그리고 Flat Graph GitHub Action을 사용하면 되죠. GitHub에는 비밀로 체크인된 Neo4j Aura 인스턴스에 대한 자격 증명이 있답니다. 다음은 JSON 배열을 반복하는 방법을 알려주는 Cypher 쿼리에요. apoc.load.json을 사용해서 이 쿼리와 매우 유사하게 만들 수 있지만, 이번에는 해당 JSON을 Cypher 파라미터로 전달할 거예요. 이렇게 하면 데이터가 Neo4j Aura에서 매 시간마다 계속 업데이트될 거예요.

Neo4j Bloom을 사용한 시각적 탐색

데이터를 시각적으로 탐색하는 방법 중 하나는 Neo4j Bloom을 사용하는 거예요.

Bloom은 Neo4j에 데이터만 있다면 그래프 UI를 만들 수 있는 아주 훌륭한 노코드 솔루션이에요. 하지만 이번 경우에는 Bloom이 딱 맞는 선택은 아니에요. 좀 더 간단한 걸 원하고, Bloom의 모든 기능을 다 보여주고 싶지도 않거든요. 웹 애플리케이션을 만들고 싶어요.

Neo4j GraphQL 라이브러리를 사용하여 API 계층 구축

데이터베이스를 프론트엔드 애플리케이션에 바로 노출하는 대신, 클라이언트와 데이터베이스 사이에 API 계층을 두고 싶어요. 여기에는 몇 가지 커스텀 로직이 들어가고, 보통 인증도 여기서 처리하죠. 이 프로젝트에서는 다양한 도구를 사용해서 이 문제를 해결할 수 있는 여러 방법이 있는데, 이번에는 Neo4j GraphQL 라이브러리를 사용해서 GraphQL API를 만들어볼게요.

Neo4j GraphQL 라이브러리는 JavaScript GraphQL API를 만들기 위한 JS 라이브러리가 아니에요. 다시 말하지만, 클라이언트와 데이터베이스 사이에 있는 이 레이어의 경우 GraphQL을 사용해서 데이터베이스에 직접 쿼리하지 않아요. 그럼에도 불구하고 Neo4j GraphQL 라이브러리는 시작할 때 여러 가지 장점을 제공해준답니다. 혹시 GraphQL에 익숙하지 않다면, 이건 기본적으로 API 쿼리 언어이자 API 요청을 처리하기 위한 런타임이라고 생각하면 돼요.

GraphQL을 사용하면 작업 중인 데이터 형태를 정확하게 정의하고 API에서 사용할 수 있는 엄격한 유형 시스템을 갖게 돼요. 클라이언트에서 해당 데이터를 쿼리하는 방법을 정의하는 거죠. 여기서 그래프 부분이 중요한데, 이러한 유형들이 어떻게 연결되는지를 설명해주거든요. GraphQL의 그래프는 다른 유형을 참조하는 유형의 관계 필드에 대한 아이디어를 가지고 있어요.

쿼리할 때 클라이언트는 GraphQL 유형 정의에 설명된 이 데이터 그래프를 자유롭게 탐색해서 클라이언트가 관심 있는 데이터, 또는 클라이언트가 렌더링해야 하는 데이터(예: 애플리케이션의 뷰)를 가져올 수 있어요. 다시 가져오려는 데이터를 지정하는 클라이언트와 결합된 이 유형 시스템은 우리가 돌아오는 데이터의 모양과 유형을 정확히 알고 있다는 걸 의미하고, 이는 클라이언트를 위해 유형이 안전한 데이터로 작업할 수 있는 정말 좋은 방법이에요.

언급했듯이 Neo4j GraphQL 라이브러리는 JS 그래픽 API를 구축하기 위한 JavaScript 라이브러리예요. API 레이어를 구축할 때 작성해야 하는 상용구 코드를 줄이는 데 정말 도움이 될 거예요. 새로운 GraphQL 라이브러리를 사용해서 GraphQL 유형 정의를 정의하고 이를 라이브러리에 전달하면, GraphQL API를 생성하는 데 필요한 많은 작업을 대신 처리해줘요. 따라서 Neo4j GraphQL 라이브러리의 주요 목표 중 하나는 GraphQL 최초 개발 아이디어를 지원하는 것이죠.

이건 GraphQL API뿐만 아니라 데이터베이스에 대한 데이터 모델을 정의하는 GraphQL 유형 정의가 있다는 걸 의미해요. GraphQL 정의는 실제로 데이터베이스의 데이터 모델을 구동할 수 있답니다. API에서 이는 Neo4j와 GraphQL 레이어로 작업할 때 두 개의 별도 스키마를 유지할 필요가 없다는 걸 의미하죠.

앞서 언급한 도구인 Arrows의 좋은 점 중 하나는 그래프 다이어그램을 만들 때 내보내기 옵션 중 하나가 GraphQL 유형 정의라는 거예요. 이러한 유형 정의는 Neo4j GraphQL 라이브러리에서 작동하고요. 그래프 모델을 시각적으로 정의하면 Arrows에서 직접 GraphQL 유형 정의를 내보낼 수 있어요.

GraphQL CRUD API 자동 생성

유형 정의가 있으면 이를 Neo4j GraphQL 라이브러리에 넘겨주세요. 그러면 모든 CRUD 작업(Create, Read, Update, Delete)이 생성될 거예요. 기본적으로 유형 정의에 정의된 모든 유형에 대한 작업이죠.

이건 순서 지정, 페이지 매김, 복잡한 필터링을 추가하고 데이터베이스가 지원하는 공간 및 시간 기본 유형에 대한 지원을 추가해서 Node 유형을 검색하기 위한 API의 진입점이에요.

GraphQL에서 Cypher 생성

쿼리 시 임의의 GraphQL 요청은 Cypher로 변환돼요. 개발자 입장에서 데이터 계층에서 데이터를 가져오는 방법을 설명하기 위해 많은 상용구 코드를 작성할 필요가 없다는 걸 의미하죠. 이는 개발자 생산성에 좋지만, 여기에는 또 다른 엄청난 성능 이점이 있어요. 단일 데이터베이스 쿼리를 생성하고 있고, 이는 데이터베이스에 대한 단일 왕복 여행이며 데이터베이스는 해당 쿼리를 최적화할 수 있거든요.

일반적으로 GraphQL을 사용하면 여러 데이터베이스 요청이 발생하죠. 이걸 캐싱하고 일괄 처리하는 방법을 고민해야 하지만, Neo4j GraphQL 라이브러리를 사용하면 기본적으로 생성되는 단일 데이터베이스 `쿼리`를 사용해서 루트에서 전체 요청을 자동으로 해결해줘요.

Cypher로 GraphQL 확장하기

이제 Neo4j 그래프 라이브러리를 사용해서 타입 정의 없이 무료로 생성되는 기본 CRUD 기능을 넘어서 볼 거예요. 정의하고 싶은 사용자 정의 로직이 있다면, Cypher GraphQL `스키마` 지시문을 사용할 수 있어요.

`스키마` 지시문은 서버 측에서 발생하는 사용자 정의 작업이 있다는 걸 나타내는 GraphQL에 내장된 확장 메커니즘이에요. Neo4j GraphQL 라이브러리에는 꽤 많은 지시문이 있는데요. 개발자가 지시문을 통해 API를 구성하는 주요 방법이죠. Cypher 지시문은 Neo4j GraphQL 라이브러리에서 제가 제일 좋아하는 기능이자, 아마도 가장 강력한 기능일 거예요. 이걸 사용하면 Cypher `쿼리`를 작성하고, Cypher `쿼리`에 매핑되는 타입 정의의 필드에 주석을 달 수 있어요.

즉, Cypher에서 사용자 지정 복잡한 로직을 작성하고 `스키마`에 주석을 달기만 하면 해당 기능을 추가할 수 있다는 거죠. 드라이버 연결 생성에 대해 걱정할 필요도 없어요. GraphQL 요청에서 생성된 단일 생성 데이터베이스 `쿼리`와 계속 작동하니까요. 하위 `쿼리`로 연결되므로 주소 지정, 데이터 계층으로 여러 번 왕복하지 않고 데이터베이스가 `쿼리`를 최적화하도록 하는 것의 성능 이점을 계속 활용할 수 있어요.

프론트엔드에서 그래프로 작업하는 방법: Next.js

이제 GraphQL API가 있고 타입 정의가 정의되었고, Neo4j GraphQL 라이브러리를 사용하고 있고, 클라이언트에서 GraphQL 요청을 작성해서 애플리케이션에서 렌더링하려는 데이터를 정확하게 가져올 수 있어요. 다음 단계는 프론트 엔드에서 그래프 데이터와 GraphQL을 사용해서 작업하는 방법에 대해 생각하는 거예요.

저는 Next.js를 사용하는 걸 좋아해요. React를 기반으로 구축된 프레임워크죠. SEO에 매우 유용한 서버 측 렌더링이나 파일 기반 라우팅과 같은 일부 기능을 추가하는 메타 프레임워크라고도 해요. 새로운 JavaScript 파일이나 구성 요소를 생성하고 성능을 위해 이미지 압축 및 코드 분할을 처리하기 위한 경로를 자동으로 확보할 수 있어요.

특히 우리와 관련된 기능은 서버 측 API 경로인데요. Next.js를 사용하면 그래프 시각화가 될 프런트엔드 React 코드를 만들 수 있어요. GraphQL 엔드포인트를 API 경로로 구축하고 배포할 수도 있고요. 이는 서버리스 기능으로 배포되죠. 이제 하나의 프레임워크를 사용하는 하나의 코드베이스에 프런트엔드와 백엔드 코드가 모두 있는 거예요.

아폴로 클라이언트

React 애플리케이션으로서 우리는 일반적으로 아폴로 클라이언트 GraphQL 데이터로 작업해요.

여기서는 Apollo Client 인스턴스를 생성한 다음 이를 React 컴포넌트 계층 구조에 주입해요. 애플리케이션의 모든 React 컴포넌트는 React의 훅에 액세스할 수 있어서 GraphQL `쿼리`를 작성할 수 있죠. 그러면 Apollo Client가 데이터 가져오기를 처리하는데요. 동일한 데이터를 요청하는 경우 Apollo Client는 API 계층으로 이동하는 대신 로컬에 캐시할 수 있어요. Apollo Client는 또한 이 데이터를 React 컴포넌트의 상태 데이터로 관리한답니다.

우리가 해야 할 일은 애플리케이션을 처음 로드할 때 가져오려는 모든 데이터를 정의하는 GraphQL `쿼리`를 작성하는 거예요. 이 경우에는 점수별로 정렬된 기사가 될 텐데, 현재 시점에서 가장 높은 기사를 제공하겠죠. 또한 사용자 상호 작용을 처리해서 해당 주제 중 하나를 클릭하면 API로 돌아가 해당 특정 태그에 연결된 더 많은 기사를 가져올 수 있기를 원해요.

React Force Graph를 사용한 그래프 데이터 시각화

이제 프론트 엔드에 데이터가 있고 그래프 시각화를 구축하려고 해요.

대부분의 그래프 시각화의 중요한 특징은 강제 지향 레이아웃이라는 아이디어인데요. 이는 시각화의 `노드`가 서로 밀어내는 반발 자성을 가지며 `관계`가 스프링 역할을 하여 `노드`를 끌어당기는 물리 시뮬레이션이 브라우저에서 진행되고 있음을 의미해요.

이 물리 시뮬레이션을 실행하고 시각화가 안정화되면 특정 `노드`가 다른 `노드`에 연결되는 위치와 그래프에서 `노드` 그룹이 존재하는 위치를 해석할 수 있는 클러스터와 커뮤니티가 형성되는 위치를 확인할 수 있죠. 기본적으로 거의 모든 `노드` 차트 시각화에서 강제 방향 레이아웃에 대한 아이디어를 볼 수 있어요. 물론 사용할 수 있는 다른 레이아웃 알고리즘이 있지만 Neo4j Bloom 및 Neo4j Browser에서 볼 수 있듯이 강제 지정이 매우 일반적이랍니다.

우리는 React를 사용하고 있으므로 다음과 같은 React 라이브러리를 사용해 볼게요. React Force Graph. 이는 Force Graph라는 라이브러리 위에 구축되었어요. 3D 그래프 구현을 구축할 수 있는 3D 버전도 있는데, 이는 본질적으로 React Force Graph에 대한 React 바인딩이에요.

이 경우 GraphQL `쿼리`는 JSON JavaScript의 객체로 다시 제공되므로 이를 React Force Graph 라이브러리에 쉽게 전달할 수 있어요. `노드` 대신 텍스트를 시각화하고 싶기 때문에 약간의 구성을 수행해야 하지만 그래프 시각화를 구축하기 위해 몇 가지 사소한 구성 외에 수행해야 할 작업은 많지 않아요.

이제 프론트 엔드에 그래프 시각화가 있고 Neo4j에서 데이터를 가져오는 GraphQL API를 통해 데이터를 가져오고 있어요. 이 데이터는 GitHub 작업을 사용하여 지속적으로 업데이트되고 있답니다.

Vercel을 사용한 배포

이제 프런트엔드 React 앱과 GraphQL을 모두 사용하여 애플리케이션을 배포할 차례인데요. 바로 Vercel을 사용해 볼 거예요. Vercel은 개발자에게 최적화된 배포 플랫폼이죠. Vercel에서는 Lobsters Graph용 GitHub 저장소를 연결할 수 있어요.

제 GraphQL API가 Vercel에 의해 서버리스 기능으로 배포될 예정이고 Neo4j Aura 인스턴스에 연결할 수 있어야 하기 때문에 환경 변수와 Neo4j Aura 인스턴스에 대한 연결 자격 증명을 입력하여 약간의 구성을 수행해야 해요.

GitHub 저장소를 처음 연결할 때 Vercel은 애플리케이션을 빌드한 다음 정적 React 코드를 Vercel CDN에 배포한답니다.

기본적으로 두 개의 도메인이 제공되는데요. 위에 보이는 것처럼 사용자 지정 도메인을 추가해서 특정 배포 미리보기 URL을 얻을 수도 있어요. Pull Request가 있거나 GitHub에 새로운 코드를 Push할 때마다 Vercel은 이 GitHub 저장소에 업데이트가 있다는 알림을 받게 돼요.

Vercel은 앱을 빌드하고 특정 미리보기 URL을 만들어 팀원들이나 클라이언트와 공유할 수 있게 해주죠. 이 미리보기 빌드를 사용하면 라이브 애플리케이션에 배포된 것과 똑같이 애플리케이션과 상호 작용할 수 있지만, 프로덕션 도메인으로 꼭 승격할 필요는 없어요. 팀에서 확인하고 검토한 후에 해당 Pull Request를 병합할 준비가 되면 앱의 프로덕션 URL로 승격되는 거죠. Vercel은 미리보기 빌드 아이디어를 관리하고 팀과 공유할 미리보기 URL을 제공하는 데 정말 유용한 것 같아요.

이제 앱이 활성화되었어요! 최신 Lobsters 뉴스와 함께 그래프 시각화를 볼 수 있을 뿐만 아니라, /API/GraphQL에서 GraphQL API에도 접근할 수 있어요. React 앱은 CDN에 배포되었고, GraphQL API는 Vercel에 의해 서버리스 기능으로 배포되었답니다. Next.js의 API 경로 기능을 활용하기만 하면 돼요.

애플리케이션 구축 방법

방금 구축한 애플리케이션의 아키텍처를 다시 한번 살펴볼까요? GitHub Actions를 사용해서 백그라운드에서 크론 작업을 설정해서 Lobsters JSON 엔드포인트에서 지속적으로 데이터를 가져왔어요. 그리고 Cypher를 사용해서 해당 데이터를 Neo4j Aura 인스턴스에 로드하고 GraphQL API를 구축했죠.

Neo4j GraphQL 라이브러리를 사용해서 애플리케이션 데이터를 프론트엔드 애플리케이션에 노출했어요. 프론트엔드 애플리케이션은 그래프 시각화를 생성하기 위해 반응형 그래프 컴포넌트를 사용하는 React 앱이고요. 관련된 모든 코드는 GitHub에서 확인할 수 있어요. . 더 자세한 내용이 궁금하신 분들을 위해 3부작 블로그 튜토리얼 시리즈도 준비했어요. 오늘 이야기한 다양한 단계를 좀 더 자세히 살펴볼 수 있도록 말이죠. 이 링크도 참고해주세요!

이 애플리케이션을 Neo4j 라이브 스트림에서 만들었는데, 여기서는 Neo4j의 많은 사람들과 커뮤니티의 다른 분들이 애플리케이션을 구축하고, 데이터로 작업하고, 그래프 데이터 과학을 수행하는 방법을 보여준답니다. 라이브 코딩을 좋아하신다면 라이브 스트림이 딱일 거예요. 질문도 하고, 관심 있는 부분에 대해 더 깊이 파고들 수도 있으니까요. 녹화된 영상은 Neo4j 유튜브 채널이나 Neo4j 트위치 채널에서 찾아볼 수 있어요.

리소스

흥미로운 자료 몇 가지를 더 소개해 드릴게요. 먼저 Neo4j AuraDB 무료 버전이 있어요. Neo4j Aura는 무료 등급을 제공해서 "무료"라고 부르는데요, 취미 프로젝트나 개발에 사용할 수 있도록 아주 쉽게 시작할 수 있는 Neo4j AuraDB 인스턴스를 만들 수 있답니다.
GitHub Actions, Vercel, 그리고 Neo4j AuraDB 모두 무료 버전을 제공한다는 점도 기억해두면 좋을 것 같아요. 신용카드 정보 없이도 이 앱을 구축하는 데 필요한 모든 서비스를 무료로 이용할 수 있다는 거죠. 물론, 실제 서비스를 배포하고 확장할 준비가 되면 각 서비스의 유료 플랜을 이용할 수도 있고요.

더 자세한 정보가 필요하신 분들을 위해 Neo4j GraphQL 라이브러리 랜딩 페이지를 방문해 보세요. 다양한 기능에 대한 정보와 문서, 예제 링크를 찾아볼 수 있을 거예요. Neo4j의 GraphAcademy에는 Neo4j GraphQL 라이브러리를 사용해서 GraphQL API를 구축하는 방법을 자세히 알려주는 교육 과정도 준비되어 있답니다.
Neo4j GraphQL 팀은 유럽에서 소프트웨어 엔지니어를 채용하고 있다고 해요. 채용 공고는 에서 확인하거나, GraphQL@neo4j.com으로 직접 문의하셔도 돼요. 궁금한 점이 있다면 언제든지 연락 주세요!
이 튜토리얼이 여러분께 도움이 되었기를 바라며, 유용한 자료들을 잘 활용하시길 응원할게요!