16 Jan 2026
1. iCalendar: 시대를 초월한 캘린더 표준
iCalendar[1]는 1998년 처음 세상에 등장한 이래, 전 세계의 수많은 기기와 서비스에서 캘린더 정보를 교환하는 사실상의 표준(De facto standard)으로 자리 잡았습니다. 단순한 텍스트 기반의 포맷임에도 불구하고, Google Calendar, Apple Calendar, Microsoft Outlook 등 주요 서비스들이 이를 완벽하게 지원함으로써 플랫폼 간 상호운용성을 보장하는 핵심적인 역할을 수행해왔습니다.
BEGIN:VEVENT
DTSTART:20260116T100000Z
SUMMARY:프로젝트 회의
DESCRIPTION:Q1 프로젝트 계획 수립
END:VEVENT
위와 같이 직관적이고 가벼운 구조는 개발자들이 쉽게 접근하고 구현할 수 있게 했으며, 이는 iCalendar가 20년이 넘는 세월 동안 생명력을 유지할 수 있었던 원동력이 되었습니다. iCalendar는 그 자체로 이미 훌륭하고 완성도 높은 표준입니다.
2. 의미론적 웹을 향한 도전: W3C RDF Calendar (2005)
그러나 2000년대 중반, 웹의 패러다임이 단순한 정보의 연결(Hyperlink)에서 의미의 연결(Semantic Web)로 확장되면서 새로운 도전이 시작되었습니다. 2005년 W3C는 RDF Calendar 워킹 그룹을 통해 iCalendar 데이터를 RDF(Resource Description Framework)로 표현하려는 시도를 했습니다.
이 작업의 목표는 명확했습니다. 캘린더 데이터를 단순한 텍스트 덩어리가 아닌, 기계가 이해하고 추론할 수 있는 지식 그래프의 일부로 편입시키는 것이었습니다. 예를 들어, “회의”라는 이벤트를 단순히 “Meeting”이라는 문자열이 아닌, “누가”, “어디서”, “무엇을” 하는지에 대한 구체적인 의미 정보와 연결하고자 했습니다.
하지만 기존 iCalendar 포맷을 RDF로 완전히 대체하거나 1:1로 매핑하는 것은 쉽지 않았습니다. iCalendar의 유연하고 실용적인 구조와 RDF의 엄격하고 논리적인 구조 사이에는 간극이 존재했기 때문입니다. 결국 RDF Calendar는 흥미로운 실험으로 남았지만, iCalendar를 대체하는 새로운 표준이 되지는 못했습니다.
3. iCalendar의 진화: CONCEPT와 STRUCTURED-DATA
iCalendar는 RDF로 대체되는 대신, 스스로를 진화시키는 방향을 선택했습니다. 기존의 견고한 텍스트 기반 구조를 유지하면서도, 의미론적 웹의 장점을 수용할 수 있는 확장 속성(Property)들을 도입한 것입니다.
3.1 CONCEPT 속성 [2]
CONCEPT 속성은 이벤트나 할 일의 “유형(Type)”을 명확하게 정의할 수 있게 해줍니다. 기존에는 CATEGORIES 속성에 “Meeting”이나 “Birthday” 같은 텍스트 태그를 달았지만, 이는 단순히 문자열에 불과했습니다. 반면 CONCEPT 속성은 URI를 값으로 취합니다.
BEGIN:VEVENT
SUMMARY:팀 회의
CONCEPT:http://example.org/concepts/MeetingEvent
END:VEVENT
위 예시에서 http://example.org/concepts/MeetingEvent라는 URI는 이 이벤트가 정확히 어떤 종류의 회의인지를 전 세계적으로 고유하게 식별해줍니다. 이를 통해 애플리케이션은 이 이벤트가 단순한 “모임”이 아니라 “공식적인 업무 회의”임을 기계적으로 이해하고 처리할 수 있게 됩니다.
3.2 STRUCTURED-DATA 속성 [3]
STRUCTURED-DATA 속성은 iCalendar의 진화를 가장 극적으로 보여주는 기능입니다. 이 속성은 이벤트 안에 JSON-LD나 형식이 지정된 구조화된 데이터를 통째로 임베딩할 수 있게 해줍니다.
BEGIN:VEVENT
SUMMARY:AI 컨퍼런스
STRUCTURED-DATA;FMTTYPE=application/ld+json;SCHEMA="https://schema.org/Event":
{
"@context": "https://schema.org",
"@type": "EducationEvent",
"name": "AI 컨퍼런스 2026",
"offers": {
"@type": "Offer",
"url": "https://example.org/tickets",
"price": "100",
"priceCurrency": "USD"
}
}
END:VEVENT
이제 iCalendar는 단순한 일정 정보뿐만 아니라, 티켓 예매 정보, 장소의 상세 좌표, 연사 정보 등 웹상의 풍부한 메타데이터를 품을 수 있는 “컨테이너” 역할을 하게 되었습니다.
4. 왜 필요한가? 그리고 누가 지원하는가?
이러한 진화는 단순한 기술적 과시가 아닙니다. 현대의 지능형 서비스들이 제대로 동작하기 위한 필수적인 요소입니다.
4.1 “그냥 텍스트”로는 부족하다
“강남역 3번 출구 스타벅스”라는 장소 정보는 사람에게는 완벽하지만, 기계에게는 그저 문자열일 뿐입니다. 하지만 STRUCTURED-DATA를 통해 위도/경도 좌표와 장소 ID를 함께 제공하면, 내비게이션 앱이 정확한 위치로 안내하고, 날씨 앱이 해당 지역의 날씨를 미리 알려줄 수 있습니다. 기계 판독 가능성(Machine Readability)이 비약적으로 향상되는 것입니다.
4.2 주요 서비스들의 지원
- Google (Gmail & Calendar): Google은 이 분야의 선두주자입니다. 항공권 예약 메일이나 호텔 예약 메일이 오면, Google은 그 안에 포함된 Schema.org 기반의 구조화된 데이터를 분석하여 자동으로 캘린더에 일정을 등록해줍니다. 사용자가 일일이 입력하지 않아도 비행기 시간과 호텔 체크인 시간이 캘린더에 나타나는 마법은 바로 이 기술 덕분입니다.
- Apple (Siri & Calendar): Apple의 인텔리전스 기능들도 이러한 구조화된 데이터를 활용하여 “내일 회의 준비해줘”와 같은 자연어 명령을 구체적인 캘린더 액션으로 연결합니다.
5. 결론
iCalendar는 낡은 표준이 아닙니다. 오히려 웹의 발전과 함께 끊임없이 진화하며 자신의 가치를 증명해왔습니다. 2005년 RDF Calendar의 시도는 비록 표준을 대체하지는 못했지만, iCalendar가 CONCEPT와 STRUCTURED-DATA라는 날개를 달고 의미론적 웹의 시대로 날아오르는 중요한 영감을 제공했습니다. 우리는 여전히 .ics 파일을 쓰지만, 그 안에는 이제 단순한 텍스트 그 이상의 “의미”가 담겨 있습니다.
참고 문헌
- [1]B. Desruisseaux, “Internet Calendaring and Scheduling Core Object Specification (iCalendar),” RFC Editor, RFC 5545, Sept. 2009. Available at: https://www.rfc-editor.org/rfc/rfc5545.txt
- [2]C. Daboo, “Support for iCalendar in the Event Publication Extensions to iCalendar,” RFC Editor, RFC 9253, Aug. 2022. Available at: https://www.rfc-editor.org/rfc/rfc9253.txt
- [3]M. Douglass, “Event Publishing Extensions to iCalendar,” RFC Editor, RFC 9073, Aug. 2021. Available at: https://www.rfc-editor.org/rfc/rfc9073.txt
13 Jan 2026
지난 글 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 기반의 챗봇은 대화가 길어지면 앞의 내용을 잊거나, 논리적 모순을 일으키기 쉽습니다. 하지만 그래프에 저장된 정보는 명시적이고 영구적입니다.
부족한 정보의 감지 (Missing Link Detection)
이제 시스템은 저장된 그래프를 여행 계획 온톨로지(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
- Input: 사용자의 말을 RDF로 변환 (LLM)
- Update: 지식 그래프 업데이트
- Reasoning: 그래프의 완성도 검사 (Symbolic)
- Feedback/Output: 부족하면 질문 생성, 충분하면 실행 (LLM)
5. 마치며: ‘확률’과 ‘논리’의 결합
Askitect를 단순한 ‘프롬프트 잘 쓰는 법’으로 보지 않고 시스템 아키텍처로 바라봐야 하는 이유가 여기에 있습니다.
LLM의 유연함(Intuition/Probability)은 사용자의 모호한 언어를 받아들이는 데 사용하고, 지식 그래프의 엄격함(Logic/Symbol)은 대화의 맥락을 유지하고 목표를 달성하는 데 사용하는 것.
이 Neuro-symbolic 결합이야말로, 겉만 번지르르한 수다쟁이 AI가 아니라, 사용자의 진정한 의도를 파악하고 구조화해주는 ‘설계자(Askitect)’를 만드는 청사진이 될 것입니다.
08 Jan 2026
우리는 챗봇에게 ‘답변’을 기대합니다. 검색창에 질문을 입력하고 엔터를 누르는 순간, 우리는 명확하고 즉각적인 해답이 돌아오기를 기다립니다. 이러한 ‘답변하는 기계(Answering Machine)’라는 편향은 현재 AI 인터페이스의 지배적인 패러다임입니다.
하지만 아이러니하게도, 가장 훌륭한 대화는 정답을 제시할 때가 아니라 “좋은 질문”이 돌아올 때 시작됩니다.
1. 답하는 기계를 넘어서 (Beyond the Answering Machine)
현재의 거대언어모델(LLM)들은 사용자의 입력이 아무리 모호해도 어떻게든 답변을 생성해내도록 훈련받았습니다. “맛집 추천해줘”라는 불충분한 정보만 주어져도, AI는 확률적으로 가장 그럴듯한 리스트를 나열합니다.
이는 언뜻 친절해 보일 수 있으나, 치명적인 문제를 안고 있습니다.
- 전제의 오류: 사용자의 의도와 다른 맥락에서 답을 찾을 수 있습니다.
- 피상적인 결과: 구체적인 제약 조건이 없으므로 누구나 얻을 수 있는 일반적인 정보에 그칩니다.
- 할루시네이션(Hallucination): 모르는 것을 모른다고 하지 않고, 그럴듯하게 말을 지어내려는 압박을 받습니다.
우리가 AI를 단순한 검색 도구가 아닌, 문제를 해결하는 동반자(Co-pilot)나 에이전트(Agent)로 격상시키려 한다면, AI는 이제 “모르겠습니다”라고 말할 용기, 그리고 나아가 “이것이 궁금하신가요?”라고 되물어볼 지성을 갖춰야 합니다.
2. 역질문의 핵심: 의도 명확화와 도출
AI가 사용자에게 질문을 던지는 이러한 행위는 정보 검색(Information Retrieval) 분야에서 Clarifying Questions라는 개념으로 연구되고 있습니다.
이 개념은 LangChain과 같은 최신 AI 프레임워크에서 ‘휴먼 인 더 루프(Human-in-the-loop)’ 패턴의 일환으로 적극적으로 도입되고 있습니다.
예를 들어 사용자가 모호한 검색어를 입력했을 때, 시스템은 단순히 결과를 나열하는 대신 “어떤 용도로 찾으시나요?”와 같은 유용한 질문을 제안함으로써 사용자의 의도를 명확히 파악할 수 있습니다. 즉, 단순히 명령을 수행하는 것을 넘어 질문을 통해 문제를 함께 정의해나가는 과정이야말로 에이전트의 핵심 역량입니다.
이 과정은 크게 두 가지 층위로 나뉩니다.
A. 의도 명확화 (Intent Disambiguation)
사용자의 입력이 여러 가지로 해석될 수 있을 때, 그 범위를 좁히는 과정입니다.
User: “우산 챙겨야 할까?”
AI: “지금 계신 곳이 서울인가요, 아니면 다른 지역인가요?”
이는 검색 공간(Search Space)을 줄여 정확도를 높이는 가장 기초적이고 필수적인 단계입니다.
B. 요구사항 도출 (Elicitation)
한 걸음 더 나아가, 사용자가 미처 생각하지 못한 조건을 찾아내는 적극적인 과정입니다. 이는 앞서 이야기한 Askitect의 역할과 맞닿아 있습니다.
graph TD
User("User: 노트북 하나 사고 싶어")
subgraph G1 [Typical AI]
direction TB
Typical["맥북 에어 M3를 추천합니다."]
end
End1((End))
G1 --> End1
subgraph G2 [AI Agent]
direction TB
AgentQ1["Q1. 주로 어떤 용도로 쓰시나요?"]
AgentQ2["Q2. 이동성 vs 고성능 중 무엇이 우선인가요?"]
AgentQ1 --> AgentQ2
end
User -->|Immediate Answer| G1
User -->|Counter-Questioning| G2
%% Force Layout: G1 on Left, G2 on Right
G1 ~~~ G2
%% Styles
style G1 fill:#f9f9f9,stroke:#999,stroke-dasharray: 5 5
style G2 fill:#e6fffa,stroke:#00cc99,stroke-width:2px
style Typical fill:#fff,stroke:#ccc
style End1 fill:#333,stroke:#333,color:#fff
style AgentQ1 fill:#fff,stroke:#ccc
style AgentQ2 fill:#fff,stroke:#ccc
이 과정에서 AI는 사용자의 머릿속에만 있던 암묵적인 지식(Implicit Knowledge)을 도출하여 명시적인 조건(Explicit Constraint)으로 변환합니다.
3. 언제, 어떻게 물어야 하는가?
무턱대고 질문만 하는 AI는 사용자를 피로하게 만듭니다. “역질문의 기술”은 적절한 타이밍과 방식에 달려 있습니다.
Timing: 불확실성의 임계값 (Threshold of Uncertainty)
AI는 자신의 답변에 대한 확신(Confidence Score)이 낮을 때만 개입해야 합니다. 지나치게 뻔한 질문은 대화의 흐름을 저해하고, 시의적절하지 못한 질문은 오류를 방치할 위험이 있습니다. 사용자가 충분한 정보를 주지 않았다고 판단될 때, AI는 답변 생성을 멈추고 질문 모드로 전환하는 판단력, 바로 메타인지(Meta-cognition)가 필요합니다.
Method: 온톨로지 기반의 슬롯 채우기 (Slot Filling)
질문의 방식 또한 중요합니다.
- Bad: “어떤 걸 원하세요?” (너무 광범위함)
- Good: “선호하는 운영체제가 있나요?”, “예산은 100만원 대인가요?”
여기서 ‘운영체제’, ‘예산’ 등은 해당 도메인의 온톨로지(Ontology)에 정의되어 있어야 하는 속성들입니다. 구조화된 지식을 가진 AI만이 막연한 질문이 아니라, 정보를 채워넣어야 할 빈칸(Slot)을 정확히 조준하여 질문할 수 있기 때문입니다. 이것이 뉴로 심볼릭 AI가 빛을 발하는 순간이기도 합니다.
4. Uncertainty as a Feature
우리는 흔히 UX(사용자 경험)를 설계할 때 불확실성을 제거해야 할 버그로 취급합니다. 하지만 AI 시대의 UX에서 불확실성은 그 자체로 중요한 기능(Feature)이 됩니다.
AI가 “저는 확신이 서지 않습니다”라고 시각적으로 표현하거나, “이 부분이 명확하지 않아 A와 B 중 하나로 추정했습니다”라고 투명하게 밝히는 것은 신뢰를 쌓는 과정입니다. 사용자는 이 불확실성을 해소하기 위해 기꺼이 AI의 질문에 답할 것이며, 이 과정 자체가 하나의 협업이 됩니다.
마치며
좋은 대화는 탁구(Ping-pong)와 같습니다. 일방적으로 공을 던지기만 해서는 게임이 성립되지 않습니다.
우리가 만드는 AI가 단순히 명령을 수행하는 비서가 아니라, 생각을 확장해주는 파트너가 되길 원한다면, 이제 기계에게 질문할 수 있는 권한을 부여해야 합니다. 사용자의 짧은 프롬프트 뒤에 숨겨진 거대한 맥락을 파헤치는 ‘역질문의 기술’이야말로, AI가 진정한 지능으로 나아가는 첫걸음이 될 것입니다.