클라우드에서 완성하는 풀 스택 그래프: Neo4j로 GraphRAG 마스터하기

• Cypher & GQL

편집자 주: 이 강연은윌 리옹 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으로 직접 문의하셔도 돼요. 궁금한 점이 있다면 언제든지 연락 주세요!
이 튜토리얼이 여러분께 도움이 되었기를 바라며, 유용한 자료들을 잘 활용하시길 응원할게요!

• Bloom
• Cypher
• 풀스택 GraphQL
• GraphQL
• GraphQL API
• Neo4j GraphQL 라이브러리
• Vercel

---

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

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