Text2SQL은 이미 있잖아?

맞다. ChatGPT, Gemini 모두 "자연어 → SQL" 변환을 잘한다.

그런데 Text2Cypher는 왜 따로 배워야 할까?

---

1. Text2SQL vs Text2Cypher: 근본적 차이

SQL: 테이블 중심 사고

• 테이블이 정해져 있다
• 컬럼명이 명확하다
• JOIN 방식이 획일적이다
• LLM이 예측하기 쉽다

Cypher: 관계 중심 사고

• 같은 노드가 여러 관계를 가진다
• 관계 방향이 의미를 바꾼다
• 가변 길이 경로가 존재한다
• LLM이 예측하기 어렵다

---

2. 왜 그래프 쿼리가 LLM에게 더 어려운가?

이유 1: 관계의 방향성

SQL에서는 JOIN 방향이 없다. 하지만 Cypher에서는 화살표 방향이 의미를 완전히 바꾼다.

LLM이 "인수한"과 "인수된"을 구분해서 화살표 방향을 결정해야 한다.

이유 2: 가변 길이 경로

SQL로 이걸 표현하려면 재귀 CTE가 필요하다. 복잡하다.

Cypher는 [*1..2] 한 줄로 끝난다. 하지만 LLM이 언제 가변 길이 경로를 써야 하는지 판단하기 어렵다.

이유 3: 동일 레이블의 다중 역할

"삼성전자와 관련된 회사"라는 질문에서 LLM이 어떤 관계를 선택할지 모호하다.

이유 4: 속성 vs 레이블 매핑

같은 질문인데 DB 모델링에 따라 Cypher가 완전히 달라진다. LLM이 스키마를 정확히 알아야 올바른 패턴을 선택할 수 있다.

이유 5: 집계와 패턴의 조합

단순해 보이지만, LLM이 결정해야 할 것:

• 관계 방향 (→ vs ←)
• 집계 함수 (count)
• 정렬 방향 (DESC)
• GROUP BY는 자동 (Cypher 특성)

---

3. 스키마가 유연하다

특성	RDBMS	Graph DB
스키마	엄격 (테이블, 컬럼 고정)	유연 (레이블, 속성 자유)
같은 타입 노드	동일 컬럼 보장	노드마다 속성이 다를 수 있음
관계	FK로 제한	어떤 노드든 연결 가능
LLM 난이도	쉬움 (구조 명확)	어려움 (다양한 패턴)

스키마 유연성의 함정

같은 Company 레이블인데 속성 이름이 다를 수 있다. industry vs sector, founded vs year_established...

LLM이 "설립 연도"를 물으면 founded와 year_established 중 뭘 쓸지 모른다.

---

4. 쿼리 패턴이 다양하다

LLM이 질문을 보고 어떤 패턴인지 파악해야 한다. 패턴 선택을 잘못하면 아예 다른 결과가 나온다.

---

Text2Cypher의 핵심 도전 요약

도전	설명	난이도
스키마 이해	LLM이 DB 구조를 모르면 엉뚱한 레이블 사용	높음
관계 방향	화살표 방향 하나가 의미를 바꿈	중간
패턴 선택	단순 조회인가? 경로 탐색인가?	높음
파라미터 추출	"삼성전자" → {name: '삼성전자'}	중간
모호성 해소	"관련된" = 경쟁? 파트너? 투자?	높음
보안	DELETE, DROP 같은 위험한 쿼리 차단	필수
에러 처리	실패 시 자동 수정	높음

이번 주에 이 모든 것을 다룬다.

---

실무 적용 사례

분야	활용	예시 질문
BI 대시보드	비개발자가 직접 데이터 탐색	"올해 신규 고객 중 재구매율"
챗봇	"우리 회사 파트너 현황 알려줘"	"파트너사 중 반도체 분야"
검색 시스템	자연어로 지식그래프 검색	"코로나와 관련된 약물"
내부 도구	개발자 의존도 감소	"지난 분기 이직한 인원"
컴플라이언스	규제 관계 탐색	"이 거래의 관련 규정"
추천 시스템	유사 패턴 탐색	"이 고객과 비슷한 구매 패턴"

자연어 질의는 데이터 민주화의 핵심이다.