서론 수년간 운영해온 서비스에서 Knowledge Graph를 구성하려면 어디서부터 시작해야 할까요? 새 스키마를 처음부터 설계하는 방법도 있지만, ORM 엔티티나 데이터 모델 같은 개발 코드에는 도메인의 구조가, 비즈니스 로직에는 운영하면서 축적된 규칙과 제약조건이 이미 녹아있습니다.이 지식을 AI로 구조화하면 Knowledge Graph의 출발점을 훨씬 빠르게 만들 수 있습니다. 이 글에서는 기존 Java/Spring 코드에서 그래프 스키마 명세를 추출하고, Amazon Neptune […] ||
서론
수년간 운영해온 서비스에서 Knowledge Graph를 구성하려면 어디서부터 시작해야 할까요? 새 스키마를 처음부터 설계하는 방법도 있지만, ORM 엔티티나 데이터 모델 같은 개발 코드에는 도메인의 구조가, 비즈니스 로직에는 운영하면서 축적된 규칙과 제약조건이 이미 녹아있습니다.
이 지식을 AI로 구조화하면 Knowledge Graph의 출발점을 훨씬 빠르게 만들 수 있습니다.
이 글에서는 기존 Java/Spring 코드에서 그래프 스키마 명세를 추출하고, Amazon Neptune Analytics(그래프 분석에 최적화된 분석 데이터베이스 서비스)와 Amazon Bedrock Knowledge Bases(파운데이션 모델과 데이터 소스를 연결해 RAG를 구성하는 완전 관리형 서비스)를 연결해 GraphRAG를 구현하는 과정을 소개합니다.
이 글에서 다루는 내용
그래프 스키마 설계 : 기존 개발 코드에서 AI와 도메인 전문가 협업으로 Knowledge Graph 스키마를 추출합니다.
Neptune Analytics 적재 : 설계된 스키마 기반으로 데이터를 변환하고 적재합니다.
GraphRAG 질의 구현 : Amazon Bedrock Knowledge Bases를 활용해 자연어로 그래프를 탐색합니다.
사전 준비 사항
AWS 계정
Amazon Bedrock 모델 접근 권한 (Anthropic Claude Sonnet 4.5)
Amazon S3 버킷 (CSV 데이터 업로드용)
Java/Spring 기반 프로젝트 (또는 ORM이 포함된 개발 코드)
왜 기존 코드에서 시작하는가
RAG(Retrieval-Augmented Generation)는 LLM이 외부 지식을 참조해 답변하는 패턴으로 널리 쓰입니다.
공연 티켓 예매 서비스를 예로 들어, 다음 질문을 생각해봅시다.
“스타라이트 페스티벌 2025에 대한 정보와 예약 좌석 정보를 알려주세요.”
단순한 질문도 답하지 못하는데, “서울에서 열리는 공연 중 VIP석이 있고, K-Pop 아티스트가 출연하는 공연은?” 처럼 여러 조건이 결합된 질문이라면 상황은 더 어렵습니다. 이 질문에 답하려면 공연장의 도시, 공연과 공연장의 관계, 좌석 등급, 잔여 예약 수, 아티스트 장르라는 5개 엔티티에 걸친 연결 정보가 필요합니다.
LLM 단독으로는 이런 구조적 데이터를 알 수 없고, 벡터 유사도 검색은 의미적으로 가까운 텍스트 조각을 찾는 데 강하지만, 여러 엔티티를 거쳐야 하는 관계 기반 질의에서는 연결 경로를 추적할 수 없습니다.
Knowledge Graph는 데이터를 노드(개념)와 엣지(관계)의 네트워크로 표현합니다.
위와 같은 질문은 그래프 탐색을 활용하면 보다 효과적으로 처리할 수 있습니다.
그렇다면 이 Knowledge Graph의 설계도, 즉 그래프 스키마는 어디서 가져올 수 있을까요?
사실 우리가 이미 잘 알고 있는 곳에 있습니다. 개발 코드의 ORM(예: JPA 엔티티의 @ManyToOne, @OneToMany) 관계는 이미 그래프 엣지이고, 서비스 로직(예: 유효성 검증, 상태 전이 조건)은 비즈니스 규칙으로 활용할 수 있습니다.
새로 설계하는 것보다 이미 코드에 있는 도메인 지식을 구조화하는 편이 훨씬 빠릅니다.
전체 파이프라인
전체 흐름은 다음과 같습니다.
핵심은 코드에서 AI와 도메인 전문가의 협업으로 만들어지는 spec.json이라는 그래프 스키마 명세입니다.
이 파일이 어떻게 생성되고, Neptune Analy