Requery

---
name: requery
description: Agentic retrieval cycle — 첫 검색에서 답을 못 찾으면 표현·시점·관점을 바꿔 다시 검색하는 규율. 작업 기반의 정형·반정형·비정형 자료를 함께 찾는다. Letta filesystem 사례(LoCoMo 74% > Mem0 graph 68.5%)를 참고하며 별도 도구를 추가하지 않는다.
user-invocable: true
---

# Requery — Agentic Retrieval Cycle

`requery`는 첫 질문으로 답을 찾지 못했을 때 표현·시점·관점을 바꿔 다시 검색하는 규율이다.
검색어를 반복해서 재구성하는 방법을 정하며 별도 도구를 추가하지 않는다.

참고한 사례는 Letta 블로그의 *Is a Filesystem All You Need?*다. 이 글의 LoCoMo 질의응답 실험에서는
파일 시스템의 단순 도구(grep·search_files)를 에이전트가 자율적으로 쓴 구성이 74%를 기록해,
그래프 기반 Mem0의 68.5%보다 높았다. 여기서 차용하는 것은 검색 장치를 먼저 복잡하게 만들기보다
질문을 바꿔 다시 찾는 방법이다.

---

## 발동 시점

다음 신호가 잡히면 적용한다.

1. **첫 검색 실패** — 인덱스·헤더·grep을 한 번 확인했지만 답을 찾지 못했다.
2. **인계 누락 의심** — bridge-note·agenda에서 이전 내용을 찾지 못해 "그 내용을 어디에 남겼지?"라는 의문이 생겼다.
3. **정보 변경 의심** — 이름·경로·설명 방식이 바뀌었을 수 있다.
4. **표현 수준의 차이** — 사용자는 추상적으로 묻고 본문에는 구체적인 항목이 적혀 있거나 그 반대다.

첫 검색에서 답을 찾았으면 즉시 끝낸다. 반복 검색을 강제하지 않는다.

---

## 자료 유형별 검색

| 자료 유형 | 예시 | 첫 검색 방법 |
|------|------|------------|
| 정형 | 메모리 인덱스, frontmatter, ADR의 supersedes, agenda 체크박스 | grep과 인덱스 읽기 |
| 반정형 | bridge-note 대화 헤더, devlog 파일명(`{date}_{slug}.md`), journal 헤더(`## YYYY-MM-DD [hostname]`) | head·grep과 본문 읽기 |
| 비정형 | journal 본문, 노트 수신함, bridge-note 본문, devlog 서술 | `rg`와 검색어 재구성 |

정형 자료에서 질문에 맞는 답을 찾으면 한 차례로 끝난다. 반정형 자료는 한두 차례 더 찾아야 할 수 있고,
비정형 자료에서는 검색어를 여러 번 바꾸기도 한다.

---

## 6단계 protocol

```
1. 사용자 질문이나 작업 중 생긴 질문을 확인한다.
2. 정형 자료를 찾는다 — 메모리 인덱스 → 분야 안내가 있으면 경유 → 본문 → ADR의 supersedes 관계
3. 못 찾으면 반정형 자료를 찾는다 — bridge-note 대화 헤더, devlog 날짜, journal 헤더
4. 못 찾으면 비정형 자료를 찾는다 — rg 검색과 본문 읽기
5. 여전히 못 찾으면 질문을 재구성하고 2단계부터 다시 찾는다 — 아래 네 방법을 적용한다.
6. 반복해도 못 찾으면 검색한 범위와 남은 불확실성을 사용자에게 알린다.
```

분야 안내를 두지 않은 작업 기반에서는 인덱스에서 본문으로 바로 간다. 이 절차 때문에 새 라우터를
만들 필요는 없다.

### 질문을 바꾸는 네 방법

| 방법 | 적용할 상황 | 예시 |
|---------|---------|------|
| **동의어** | 이름·호칭이 바뀌었을 때 | 옛 컴포넌트명 → 새 컴포넌트명 / 별칭 → 정식 이름 |
| **시점 변경** | 날짜나 대화 묶음이 다를 때 | "지난주 작업" → 해당 날짜 범위 / "어제" → "전 세션 인계" |
| **추상↔구체** | 라벨 vs 항목 | "agenda" → "[ ] 인증 방식 결정" |
| **관점 변경** | 정책·구현·운영 중 다른 관점이 필요할 때 | "인증 정책" → "토큰 만료 설정" → "배포 환경 변수" |

각 방법으로 질문의 표현을 바꿔 다시 검색한다. 반복 횟수에 고정 상한은 두지 않는다. 찾는 데 드는
비용이 문제가 되면 검색어를 바꾼 횟수를 세어 정보나 탐색 경로가 낡았는지 살핀다.

---

## 자제선 (deflationary)

1. **도구 추가** — embedding·BM25·그래프 인덱스의 도입 여부는 grep의 누락·오탐이 두 번 이상 재현될 때 판단한다. 이 스킬은 검색 규율만 정하며 인덱스를 만들지 않는다.
2. **반복 자동화** — 단계마다 에이전트가 판단하므로 검색 전체를 자동 파이프라인으로 바꾸지 않는다.
3. **별도 측정 파이프라인** — Letta 사례에서 차용한 관점은 도구를 잘 쓰는 능력에 있다. 측정 자체를 금지하지는 않는다. 검색어를 재구성한 횟수는 그 자리에서 셀 수 있으므로 별도 인프라를 만들지 않는다. 오래된 정보의 신호로 쓸 때도 막연한 느낌 대신 이 횟수를 센다.

---

## 다른 스킬과의 경계

requery는 기록에 도달하는 경로를 맡는다. 찾은 내용이 맞는지는 다른 축이 판정한다.

| 스킬 | 맡는 일 | requery와의 관계 |
|------|--------|-----------------|
| `scribe` | 세션 뒤에도 남길 내용을 기록한다 (쓰기) | scribe가 남긴 인덱스·헤더·slug가 requery의 검색 경로가 된다. 이름·계층 규약이 바뀌면 두 쪽을 함께 본다 |
| `guard`·`punch`·`witness` | 찾은 근거와 산출물이 맞는지 검증한다 | requery로 찾은 원천을 이들이 대조한다. 찾았다는 사실이 맞다는 근거는 아니다 |
| `autoloop` | 계획·실행·판정 루프를 돌린다 | [Plan]·[Execute]에서 이전 결정이나 기록이 필요할 때 requery를 쓴다 |

---

## 적용 예시

**질문**: "지난주에 인증 방식을 뭘로 정했지?"

```
1. 정형 — 메모리 인덱스에서 해당 프로젝트 항목을 찾아 본문을 읽는다.
   → 본문이 가리키는 decisions/ 의 ADR을 확인한다. supersedes 관계가 있으면 최신 결정을 따라간다.
2. 정형 자료만으로 답이 충분하면 끝낸다.
```

**질문**: "그 기능을 처음에 어떻게 정의했지?"

```
1. 정형 — 인덱스 → 본문 순으로 읽는다.
   현재 정의가 최초 정의를 설명하는지는 따로 확인한다.
2. 시점을 바꿔 "처음 / 초기 / 첫 버전"과 해당 날짜로 다시 검색한다.
3. devlog 파일명이나 journal 헤더에서 그 날짜의 기록을 찾는다.
4. 또는 해당 리포의 git log에서 최초 커밋의 본문을 읽는다.

이 예시에서는 시점을 바꿔 최초 정의를 찾았고 검색은 두세 차례로 끝난다.
```

---

## 작업 기반에 맞추기

작업 기반마다 메모리 경로, devlog 기록 주기, bridge-note 대화 헤더의 형식이 다르다. 세 자료 유형의
매핑과 여섯 단계 절차를 자신의 작업 기반에 맞춰 조정한다. 적용 경위와 탐색 비용 측정 기록은
각 작업 기반의 메모리에 둔다.