Askitect를 위한 청사진: RDF로 대화 모델링하기

13 Jan 2026 • Essay • AI

지난 글 Askitect, 그리고 프롬프트 엔지니어링의 진화에서 저는 ‘질문하는 건축가(Askitect)’라는 개념을 통해, 단순히 답을 내놓는 AI가 아니라 사용자의 의도를 함께 설계해 나가는 상호작용의 중요성을 이야기했습니다.

추상적인 철학을 넘어, 실제 동작하는 시스템으로 만들기 위해서는 ‘유동적인 자연어(Natural Language)’와 ‘엄격한 논리(Logic)’ 사이를 연결하는 다리가 필요합니다. 이번 글에서는 그 다리의 설계도, 즉 Neuro-symbolic AI 기반의 대화 모델링 청사진을 그려보고자 합니다. 핵심 도구는 RDF(Resource Description Framework)입니다.

1. 의미론적 파서 (Semantic Parser)

우리는 흔히 LLM(Large Language Model)을 ‘지식 저장소’나 ‘추론 엔진’으로 생각합니다. 하지만 Askitect 구조에서 LLM의 가장 강력한 역할은 비정형 자연어를 정형 데이터로 변환하는 ‘의미론적 파서(Semantic Parser)’입니다.

사용자의 말은 모호하고 생략이 많습니다. 이를 논리적으로 처리하기 위해선 먼저 기계가 이해할 수 있는 명확한 구조, 즉 Triples (주어-술어-목적어) 형태로 변환해야 합니다.

예시 상황: 여행 계획

사용자가 다음과 같이 말했다고 가정해 봅시다.

User: “친구랑 도쿄 가려고. 맛집이 제일 중요해.”

Askitect 시스템의 첫 번째 단계(LLM)는 이 문장을 내부 온톨로지(Ontology)에 맞춰 다음과 같은 Turtle(RDF 포맷) 구문으로 번역합니다.

@prefix ex: <http://example.org/travel/> .

# LLM이 추출한 정보
ex:Request_001 a ex:TripPlan ;
    ex:hasDestination ex:Tokyo ;
    ex:hasCompanionType ex:Friend ;
    ex:hasPriority ex:Gastronomy .

이 과정에서 LLM은 “맛집”이라는 단어를 ex:Gastronomy라는 사전에 정의된 개념으로 매핑하고, “친구랑”이라는 표현을 ex:hasCompanionType ex:Friend라는 관계(Relationship)로 확정 짓습니다.

2. 지식 그래프와 상태 관리 (Knowledge Graph as State)

LLM이 번역한 데이터는 휘발되지 않고 지식 그래프(Knowledge Graph)에 저장됩니다. 이것이 바로 대화의 ‘상태(State)’가 됩니다.

순수 LLM 기반의 챗봇은 대화가 길어지면 앞의 내용을 잊거나, 논리적 모순을 일으키기 쉽습니다. 하지만 그래프에 저장된 정보는 명시적이고 영구적입니다.

이제 시스템은 저장된 그래프를 여행 계획 온톨로지(Schema)와 대조해봅니다.

  • 온톨로지 정의: TripPlan 클래스는 반드시 hasDuration(기간)과 hasBudget(예산) 속성을 가져야 한다.
  • 현재 그래프 상태: Request_001 인스턴스에 hasDestination, hasCompanionType, hasPriority만 존재함.
  • 결과: hasDuration과 hasBudget 정보가 결측(Missing)됨.

이 논리적 검증(Validation) 과정은 LLM이 아니라, SHACL(Shapes Constraint Language)이나 SPARQL 쿼리와 같은 심볼릭(Symbolic) 엔진이 담당합니다. 할루시네이션(환각)이 개입할 여지가 없는 수학적 연산의 영역입니다.

3. 질문 생성 메커니즘 (Generating the ‘Ask’)

부족한 정보가 논리적으로 식별되었다면, 이제 다시 LLM이 등장할 차례입니다. 하지만 이번에는 파서가 아니라 NLG(Natural Language Generator) 역할을 수행합니다.

심볼릭 엔진이 “기간(Duration)과 예산(Budget) 정보가 필요함”이라는 목표(Goal)를 던져주면, LLM은 이를 사용자에게 자연스럽게 물어보는 문장을 생성합니다.

System Goal: Request value for ex:hasDuration, ex:hasBudget based on context ex:Request_001.

Askitect (Generated Output): “도쿄로 가시는군요! 맛집 위주의 여행, 기대되네요. 혹시 여행 기간은 며칠로 생각하고 계신가요? 그리고 대략적인 예산 범위도 알려주시면 딱 맞는 식당을 찾아드릴 수 있어요.”

4. 전체 아키텍처 요약

이 과정을 도식화하면 다음과 같은 순환 루프가 만들어집니다.

graph TD
    User(("User (Natural Language)")) -->|Input| Parser["LLM (Semantic Parser)"]
    Parser -->|Turtle/RDF| Graph[("Knowledge Graph (State)")]
    
    subgraph Reasoning ["Symbolic Reasoning"]
        Graph -->|Validation| Validator{"Completeness Check"}
        Validator -->|Missing Info| Goal["Question Goal"]
        Validator -->|Complete| Action["Execute Service"]
    end
    
    Goal -->|Context + Goal| Generator["LLM (Response Generator)"]
    Generator -->|Question| User
  1. Input: 사용자의 말을 RDF로 변환 (LLM)
  2. Update: 지식 그래프 업데이트
  3. Reasoning: 그래프의 완성도 검사 (Symbolic)
  4. Feedback/Output: 부족하면 질문 생성, 충분하면 실행 (LLM)

5. 마치며: ‘확률’과 ‘논리’의 결합

Askitect를 단순한 ‘프롬프트 잘 쓰는 법’으로 보지 않고 시스템 아키텍처로 바라봐야 하는 이유가 여기에 있습니다.

LLM의 유연함(Intuition/Probability)은 사용자의 모호한 언어를 받아들이는 데 사용하고, 지식 그래프의 엄격함(Logic/Symbol)은 대화의 맥락을 유지하고 목표를 달성하는 데 사용하는 것.

이 Neuro-symbolic 결합이야말로, 겉만 번지르르한 수다쟁이 AI가 아니라, 사용자의 진정한 의도를 파악하고 구조화해주는 ‘설계자(Askitect)’를 만드는 청사진이 될 것입니다.

 Askitect  Neuro-symbolic AI  RDF  Ontology  Knowledge Graph  System Design

Comments

Related Posts