시간 표현상대 날짜Temporal RetrievalTEMPO셀프 쿼리메타데이터 필터TypeSafeJevChoice날짜 계산임베딩한국어 검색RAGOllama한국어 검색 스택실측 벤치마크
'지난달 글'은 누가 계산하나 — 시간 표현과 검색, 계산하게 할 것인가 고르게 할 것인가 (한국어 검색 스택 11편)
8편에서 '2026년 4월에 올라온 RAG 글'은 정규식 몇 줄로 풀렸습니다. 날짜가 숫자로 적혀 있었기 때문입니다. 그런데 사람은 그렇게 묻지 않습니다. '지난달 RAG 글', '올봄에 쓴 보안 글', '도커 첫걸음 시리즈가 나온 다음에 쓴 Git 글'. 이 글은 오늘을 2026년 10월 14일로 고정하고 이런 질문 38개로, 시간 표현을 날짜 범위로 바꾸는 일을 누구에게 맡겨야 하는지 쟀습니다. 정규식은 하나도 읽지 못했습니다. 로컬 LLM은 날짜를 직접 계산해 nDCG@10 0.735까지 올렸지만 '두 달 전'을 하루짜리 날짜로 읽어 결과가 텅 빈 질문을 만들었습니다. Jev에게 글마다 날짜를 판정시키면 '지난달'은 완벽했지만 '지난 분기'는 56%였습니다. 같은 Jev가 코드가 펼쳐 준 기간 후보 20개 중에서 고르게 하자 26개를 전부 맞혔고, 사건 기준 질문은 검색이 기준 글을 찾게 한 설계가 0.832로 상한선(0.851)에 다가갔습니다. 계산은 코드가, 판단은 Jev가, 찾기는 검색이. Jev 2,627회 호출에 0.06달러. 인터랙티브 4개와 삽화 7장.
8편의 결론 중 하나는 "날짜는 코드에 맡겨라"였습니다. '2026년 4월에 올라온 RAG 글'에서 2026년 4월을 정규식으로 꺼내 작성일 필드와 비교하면, 임베딩(0.355)도 Jev(0.708)도 아닌 코드가 0.840으로 이겼습니다. Jev는 날짜 조건 807쌍을 하나도 틀리지 않았지만, 맞는 달의 글이 후보 40개 안에 들어오지 않아 졌습니다.
그런데 그 질문들은 쉬운 쪽이었습니다. 날짜가 숫자로 적혀 있었으니까요. 실제 사람은 이렇게 묻습니다.
"지난달 올라온 RAG 글"
"올봄에 쓴 보안 글"
"지난 분기에 나온 Claude Code 글"
"도커 첫걸음 시리즈가 나온 다음에 쓴 Git 글"
이 질문들은 누군가 날짜 범위로 바꿔 줘야 합니다. 오늘이 10월이니 지난달은 9월, 지난 분기는 7~9월. 정규식은 '지난달'이라는 글자에서 9월을 꺼낼 수 없고, Jev 문서는 7편에서 확인했듯 산술과 날짜를 약점으로 꼽습니다. 그러면 누가 계산해야 할까요?
이 문제는 연구에서도 아직 거의 풀리지 않았습니다. Abdallah 등의 TEMPO(2026년 1월, arXiv:2601.09523)는 13개 분야 1,730개의 시간 추론 검색 질문으로 12개 검색 시스템을 시험했는데, 가장 좋은 시스템도 nDCG@10이 32.0이었습니다. 우리 질문은 TEMPO보다 훨씬 단순하지만(시간 범위 하나에 주제 하나), 바로 그래서 '누가 날짜를 계산하나'라는 질문만 깔끔하게 떼어 볼 수 있습니다.
1
계산을 맡기면 틀리는 곳이 생긴다
LLM은 '두 달 전'을 8월 한 달이 아니라 8월 14일 하루로 읽었다. Jev는 '지난달'은 완벽했지만 '지난 분기'는 56%, '작년'은 73%.
2
코드가 펼치고, Jev가 고른다
코드가 '2026년 9월 (09-01~09-30)', '2026년 3분기 (07-01~09-30)'처럼 날짜를 붙인 후보 20개를 만들고 Jev가 하나를 고르면 달력 표현 26개 전부 정답.
3
'그 글 이후'는 검색의 일
기준이 되는 글을 찾는 일은 판단이 아니라 검색이었다. 임베딩 1위가 12개 중 10개, Jev 고르기는 7개. 둘을 나눠 맡긴 설계가 0.832.
1부. 실험 설계: 오늘은 10월 14일
문서는 1~10편과 같은 블로그·뉴스 589건이고, 가장 최근 글이 10월 13일이라 오늘을 2026년 10월 14일 로 고정했습니다. 질문은 두 종류 38개입니다.
종류
표현과 이 글의 해석 관례
개수
달력 표현
지난달(9월) · 이번 달(10/1~오늘) · 최근 2주(9/30~오늘) · 최근 한 달(9/14~오늘) · 두 달 전(8월) · 석 달 전(7월) · 지난 분기(7~9월) · 올해 상반기(1~6월) · 올봄(3~5월) · 지난겨울(12~2월) · 작년(2025년) · 올해 초(1~2월) · 올여름(6~8월)
26 (표현 13 × 주제 2)
사건 기준
'Jev 특집 이후', '도커 첫걸음 시리즈가 나온 다음에', "'RAG 완전 이해' 글보다 먼저", "'MCP 완전 이해' 글 이전", 'Claude Code 특집 이후', "'MCP가 세션을 지웠다' 글 뒤"
12 (기준 글 6 × 주제 2)
'두 달 전'이 8월 한 달인지, 8월 14일 언저리인지는 사람마다 다릅니다. 이 글은 '그달 전체'로 정했고, 위 표가 정답의 관례입니다. 정답은 주제(태그 또는 제목·요약의 용어)에 해당하면서 작성일이 기간 안에 있는 글 전부입니다.
비교한 방법
방법
누가 시간 표현을 날짜로 바꾸나
그다음
임베딩 그대로
아무도 (질문 문장 전체를 임베딩)
상위 10개
정규식 파서 (8편)
정규식. `N년 N월`, `N년 이전` 같은 숫자 패턴만
코드 필터 → 주제 검색
LLM 셀프 쿼리
로컬 LLM(qwen3.8)이 오늘 날짜와 관례를 받고 시작·끝 날짜를 직접 계산. 사건 질문이면 기준 글 검색어와 이전/이후를 뽑음
코드 필터 → 주제 검색. 사건은 검색 1위 글의 작성일 기준
Jev가 날짜까지 판정
Jev. 주제로 찾은 후보 40개마다 "오늘은 10월 14일. 이 문서가 질문이 찾는 글인가(조건 포함)?"
확률 순 정렬
코드가 펼치고 Jev가 고르기
코드가 날짜를 붙인 기간 후보 20개를 만들고, Jev가 Choice로 하나를 고름. 사건 질문은 검색 상위 5개 글 중 기준 글을 Jev가 고름
8편의 정규식은 숫자 날짜만 찾도록 만들어져 있어 '지난달', '올봄', '석 달 전'을 하나도 읽지 못했습니다. 달력 표현 질문에서는 그냥 하이브리드 검색으로 돌아가 0.264였습니다. 사건 질문에서는 'Claude Code 특집 이후'의 '특집'을 카테고리 조건으로 오인하기까지 했습니다. 정규식을 표현마다 늘려 갈 수는 있지만, '지난겨울'이 12~2월이고 '올해 초'가 1~2월이라는 관례까지 정규식에 넣는 순간 그것은 이미 작은 날짜 계산기입니다.
로컬 LLM에게 오늘 날짜와 관례(봄=3~5월 등)를 주고 시작·끝 날짜를 쓰게 하자 0.735까지 올랐고, 기간 밖 글은 0%였습니다. 달력 표현 26개 중 20개(77%)에서 거른 결과가 정답 기간과 정확히 같았습니다.
틀린 6개 중 4개가 문제였습니다. '두 달 전'과 '석 달 전'을 8월 14일 하루, 7월 14일 하루로 읽은 것입니다. 계산 자체는 맞습니다. 오늘에서 정확히 두 달 전은 8월 14일이니까요. 하지만 검색으로는 치명적입니다. 그날 쓴 Git 글은 1편뿐이라 결과가 거의 비었습니다(빈 결과 15%). 나머지 2개는 '최근 2주'를 하루 늦게 시작한 것으로 피해가 작았고, '이번 달'의 끝을 10월 31일로 잡은 것은 오늘 이후 글이 없으니 결과가 같았습니다.
Jev는 비교는 완벽, 계산은 한 단계까지만
Jev에게 계산을 맡기면 어떨까요? 두 가지로 쟀습니다. 하나는 실제 검색처럼 주제 후보 40개를 판정시키는 것(0.661, 기간 밖 44%), 다른 하나는 판정 능력만 떼어 보는 것입니다. 주제가 맞는 글 1,057쌍마다 "오늘은 10월 14일이다. 이 문서는 '지난달' 작성된 글인가?"를 물었습니다.
모양이 분명합니다. '지난달'처럼 오늘의 달에서 하나 빼면 되는 표현은 완벽합니다. '지난 분기'처럼 오늘이 몇 분기인지 알아내고, 그 전 분기가 몇 월부터 몇 월인지 계산해야 하는 표현에서 무너집니다. 8편에서 본 '적힌 날짜 비교는 완벽'과 7편에서 본 '계산이 필요한 주장은 약함'이 한 표에 같이 나온 셈입니다. 그리고 실제 검색(후보 40개 판정)에서는 여기에 8편의 문제가 겹칩니다. 'Git 글 중에서 두 달 전에 나온 것'의 후보 40개에 8월 글이 거의 없으니, Jev가 아무리 잘 걸러도 나머지 자리는 기간 밖 글로 채워집니다.
그래서 계산을 Jev에게서 빼앗았습니다. 코드가 오늘 날짜로부터 기간 후보 20개를 만듭니다. '2026년 10월 (이번 달, 10-01~10-14)', '2026년 9월 (09-01~09-30)', … , '최근 2주 (09-30~10-14)', '2026년 3분기 (07-01~09-30)', '2026년 봄 (03-01~05-31)', '2025년 (01-01~12-31)'. 날짜가 전부 붙어 있습니다. Jev는 질문을 보고 Choice로 하나를 고르기만 합니다.
결과는 달력 표현 26개 전부 정답 이었습니다. 직접 판정에서 56%였던 '지난 분기'도 '2026년 3분기 (07-01~09-30)'를 정확히 골랐습니다. 이제 Jev는 '지난 분기'가 몇 월인지 계산할 필요가 없습니다. '지난 분기'라는 말과 '2026년 3분기'라는 이름이 같은 것을 가리키는지만 판단하면 됩니다. 그것은 Jev가 잘하는 일입니다. 검색 점수는 0.814로, 정답 기간을 그대로 넣은 상한선과 같았습니다. 비용은 질문당 Jev 호출 1회(약 1,250토큰), 1만 건에 0.5달러입니다.
'도커 첫걸음 시리즈가 나온 다음에 쓴 Git 글'은 두 단계입니다. 먼저 '도커 첫걸음 시리즈'가 어느 글인지 찾아 작성일(9월 27일)을 알아내고, 그 뒤에 쓴 Git 글을 거릅니다. 둘째 단계는 코드의 일이 분명합니다. 첫째 단계는 누구의 일일까요?
여기서는 검색이 이겼습니다. LLM이 뽑은 사건 검색어('도커 첫걸음 시리즈')로 하이브리드 검색을 해서 1위를 그대로 쓰면 12개 중 10개가 맞았고, 상위 5개 중 Jev에게 고르게 하면 7개였습니다. 'Claude Code 특집'이라는 말에 Jev는 제목에 'Claude Code'가 든 다른 글(소스 유출 사건)을 고르기도 했습니다. 질문 속 이름과 글 제목을 맞추는 일은 판단이 아니라 찾기 이고, 그 일은 임베딩이 잘합니다.
다만 Jev의 확신도는 여기서도 쓸모가 있었습니다. 정답 글이 후보에 있었던 경우 Jev의 틀린 선택은 모두 확신도 0.62 이하였고, "0.7보다 낮으면 검색 1위를 쓴다"는 규칙 하나로 검색과 같은 10개가 됩니다. 남은 2개('RAG 완전 이해' 글 이전)는 둘 다 틀렸습니다. 'RAG 생태계 완전 가이드'가 1위로 올라와 정답 글이 후보 5개에 들지도 못했고, 그때 Jev는 틀린 글을 0.75~0.83의 확신으로 골랐습니다. 후보에 정답이 없으면 확신도도 경고하지 못합니다. 8~10편에서 거듭 본 그 교훈입니다.
4부. 설계: 계산은 코드, 판단은 Jev, 찾기는 검색
① 표현 종류 가르기
숫자 날짜(2026년 4월)는 정규식으로(8편). 달력 표현은 ②, 사건 기준은 ③
② 코드가 펼치고 Jev가 고른다
오늘 날짜로 기간 후보(월별·분기·반기·계절·연도·최근 N주)를 날짜와 함께 만들고, Jev Choice로 하나를 고른다. 확신도가 낮으면 LLM 계산이나 사용자 확인으로
③ 기준 글은 검색이 찾는다
사건 검색어로 하이브리드 1위. 그 글의 작성일 필드가 기준. Jev로 다시 고르려면 확신도 0.7 이상일 때만
④ 필터와 주제 검색
코드가 작성일로 거르고, 그 안에서 주제를 하이브리드(필요하면 Jev 재정렬)로 찾는다
파이프라인
달력 표현
사건 기준
전체 nDCG@10
기간 위반율
하이브리드 그대로
0.264
0.263
0.263
72%
LLM 셀프 쿼리
0.672
0.870
0.735
0%
Jev가 날짜까지 판정
0.694
0.591
0.661
44%
코드가 펼치고 Jev가 고르기 (사건도 Jev)
0.814
0.804
0.811
1%
설계안 (달력은 ②, 사건은 ③)
0.814
0.870
0.832
0%
정답 기간 (상한선)
0.814
0.930
0.851
0%
상한선과 남은 차이 0.019는 전부 사건 기준의 'RAG 완전 이해' 두 질문에서 나옵니다. 기준 글이 후보에도 들지 못한 경우입니다.
아래에서 질문을 골라 네 방법의 상위 10개를 날짜와 함께 보세요.
LLM이 아니라 Jev에게 고르게 하는 이유
LLM 셀프 쿼리도 꽤 좋았습니다(0.735). 그런데도 달력 표현을 Jev의 고르기로 바꾼 이유는 세 가지입니다.
실패의 모양. LLM은 틀릴 때 그럴듯한 날짜를 지어냅니다('8월 14일 하루'). 고르기는 코드가 만든 후보 밖으로 나갈 수 없으니, 틀려도 '9월 대신 8월'처럼 이웃한 기간으로 틀립니다.
확신도. Jev는 고른 후보에 확신도를 붙입니다. 확신도가 낮으면 "9월 글을 찾을까요, 3분기 전체를 찾을까요?"라고 되물을 수 있습니다. LLM이 쓴 날짜에는 그런 신호가 없습니다.
비용과 속도. Jev 호출 1회는 0.25초 안팎에 1만 건당 0.5달러입니다. 로컬 LLM은 질문당 1.4초(M 시리즈 맥, 사고 끔)였습니다.
해석 관례는 필자가 정했습니다. '두 달 전 = 8월 한 달', '올해 초 = 1~2월'은 하나의 관례일 뿐입니다. LLM이 '두 달 전'을 하루로 읽은 것도 틀린 해석이라기보다 다른 관례입니다. 다만 코드가 펼친 후보 목록은 관례를 명시적으로 드러내므로, 서비스마다 고치기 쉽습니다.
기간 후보 목록이 모든 표현을 덮지는 않습니다. '지난 금요일', '설 연휴 이후', '3주 전'처럼 목록에 없는 표현이 오면 Jev는 가장 가까운 후보를 고를 것입니다. 목록 밖 표현은 확신도가 낮을 것으로 예상되지만, 이 글에서 재지는 않았습니다.
질문 38개, 표현마다 2개뿐입니다. 표현별 수치는 흔들릴 수 있습니다. Jev 직접 판정 정확도는 글 1,057쌍으로 잰 것이라 비교적 안정적입니다.
TEMPO의 시간 추론과는 다른 문제입니다. TEMPO는 '시간에 따른 변화를 여러 문서로 종합'하는 훨씬 어려운 과제입니다. 이 글은 시간 표현을 작성일 범위로 바꾸는 입구만 다뤘습니다.
Jev는 jev-latest(1.13), 2026년 10월 초 기준입니다. 이 실험의 Jev 호출은 2,627회, 입력 151만 토큰, 약 0.06달러였습니다.
출처
Abdelrahman Abdallah, Mohammed Ali, Muhammad Abdul-Mageed, Adam Jatowt, "TEMPO: A Realistic Multi-Domain Benchmark for Temporal Reasoning-Intensive Retrieval", 2026, arXiv:2601.09523 — 13개 분야 1,730개 질문, 최고 시스템 nDCG@10 32.0
