agent가 wiki로 task를 풀 수 있느냐가 ground truth — with-wiki vs without-wiki로 측정하기

위키를 검증하는 정책을 여럿 갖춰 둘 수 있다. syntax 깨끗, anchor valid, coverage trend 안정, byte-identical 보장 등. 모두 매일 green이라고 하자. 그런데 이 모든 신호가 답하지 못하는 질문이 하나 남는다 — "이 위키로 AI 에이전트가 실제 task를 풀 수 있는가". 그게 위키 운영의 진짜 목적이다.

현실에서 잘 발생하는 양상은 이렇다. 위키는 valid한 anchor 1,200개를 갖고 있고 함수 coverage 75%를 유지한다. 그런데 에이전트가 "이 라우터의 핸들러는 어디 있나"를 물으면, 정답이 위키 안에 분명히 있는데도, 에이전트는 wiki에 도달하지 못한다. 청크의 임베딩이 task 의도와 align되지 않거나, 검색 stage가 엉뚱한 페이지를 뽑거나, 위키 본문의 표현이 에이전트가 쓰는 어휘와 다르다. wiki 자체는 valid하지만 system 차원에서 wiki가 일을 못 한다.

task 검증은 그 질문에 직접 답한다. 이 글은 task 검증이 어떻게 wiki를 시스템 차원에서 검증하고, 왜 이 검증이 위키 운영의 ground truth인지를 본다.

1. 다른 검증들이 보지 않는 것 — system 차원

위키 자체의 속성을 보는 검증들은 wiki 본문 그 자체를 본다 — syntax 맞음, 좌표 맞음, 양적 충분함, 결정성 있음. 모두 wiki라는 정적 artifact의 속성이다. 그런데 wiki는 단독으로 존재하지 않는다. wiki + RAG + LLM + 사용자 task — 이 system이 wiki의 진짜 존재 이유다. wiki가 잘 적혔는가와 system이 wiki로 일을 하는가는 다른 질문이다.

두 질문이 어긋나는 경우가 흔한 이유는 wiki와 RAG/LLM 사이에 여러 system 변동이 있기 때문이다. embedding 모델이 wiki의 어휘를 잘 cover하는가, chunking 크기가 task 단위와 맞는가, retrieval이 top-K를 잘 뽑는가, LLM이 받은 context를 잘 활용하는가. 이 모든 게 wiki 본문과 무관한 system 변수다 — wiki는 valid한데 system이 일을 못 하면 사용자는 답을 못 받는다.

2. 보는 것 — with-wiki vs without-wiki

task 검증의 측정은 단순하다. 미리 정한 task 7개(예: "이 함수 변경 시 영향 영역", "이 라우터의 핸들러 위치", "이 모듈의 의존 모듈 list")를 두 가지 조건에서 에이전트에 풀게 한다. 한 번은 wiki를 RAG context로 받은 채(with-wiki), 한 번은 위키 없이(without-wiki). 두 조건의 정답률 차이가 wiki의 task-level 가치다.

평균 +47%p ← wiki의 task-level 가치

위 차트는 한 분기 실측 예시다. 7개 task 각각에 대해 delta = with-wiki 정답률 − without-wiki 정답률을 한 막대씩 그렸다 — 막대가 길수록 그 task에서 wiki가 더 크게 작동했다는 뜻이다. 모든 task에서 delta가 양수, 평균 +47%p. 이 숫자가 "이 wiki가 agent의 task를 평균 +47%p 끌어올린다"는 정량 신호다. with-wiki 절대 정답률(평균 78%)이 아니라 delta가 wiki의 본질적 가치를 나타낸다.

3. 코드 — 두 조건 한 번씩

from dataclasses import dataclass
from typing import Callable

@dataclass
class Task:
    prompt: str
    expected: str  # 정답 텍스트 또는 정규식

TASKS = [
    Task("proxy.py의 인증 토큰 검증은 어느 함수가 담당하나?", "verify_token"),
    Task("api/users 라우터의 핸들러 함수 위치는?", "user_handler.py:"),
    # ... 7개
]

def evaluate(agent: Callable[[str, str | None], str], wiki_context: str) -> dict:
    """agent에 with-wiki vs without-wiki 두 조건으로 같은 task를 풀게 한다."""
    with_acc = 0
    without_acc = 0
    for task in TASKS:
        # with-wiki: RAG context 주입 — wiki가 task에 도움 되는지를 본다
        if task.expected in agent(task.prompt, wiki_context):
            with_acc += 1

        # without-wiki: context 없이 모델 본인 지식만으로
        if task.expected in agent(task.prompt, None):
            without_acc += 1

    n = len(TASKS)
    return {
        "with_wiki": with_acc / n,
        "without_wiki": without_acc / n,
        "delta": (with_acc - without_acc) / n,  # ← wiki의 task-level 가치
    }

핵심은 마지막 줄의 delta다. with-wiki 정답률이 70%여도, without-wiki가 65%면 delta는 5%p — wiki가 task에 거의 도움 안 됨이라는 신호다. with-wiki 70%, without-wiki 30%면 delta 40%p — wiki가 강력하게 작동한다. 절댓값이 아니라 delta가 본질적 metric이다.

4. 왜 월 1회인가 — cost와 신호 grain

주기가 월 1회인 건 LLM 호출 비용 때문이다. 7 task × 2 condition × 평가 한 번에 LLM 호출 14번. 평균 토큰량을 감안하면 nightly의 ~3배 cost. 매일 돌리면 비용이 누적되고, 같은 wiki에 매일 같은 task를 풀게 하는 신호 가치는 낮다 — 한 달 단위로 의미 있는 grain이다.

월 1회 주기가 의미 있게 작동하려면 검증하는 task 자체가 안정적이어야 한다. task list가 매월 바뀌면 delta 추이가 noise가 된다. task list를 한 분기 단위로 freeze하고, 분기 말에 task list 자체를 재검토한다. 안정된 task list 위에서 delta의 시계열이 의미 있는 trend를 만든다.

알림은 baseline 대비 -10%p 이상 떨어지면 발동한다. 지난 달 delta가 43%p였는데 이번 달이 30%p면 fail. 위키가 어딘가에서 task에 덜 도움 되는 상태가 됐다는 신호 — 그게 wiki 본문 문제인지 RAG 변경인지 LLM 모델 변경인지는 별도 진단이 필요하다.

5. 의외성 — wiki를 검증하는 게 아니라 system을 검증한다

이 검증이 본질적으로 의외인 이유는 한 가지다. 다른 검증들은 wiki 자체의 속성을 본다. task 검증은 wiki가 system 안에서 일하는가를 본다.

이 차이가 본질적인 건, wiki를 잘 적는 게 wiki 운영의 진짜 목적이 아니기 때문이다. wiki 운영의 진짜 목적은 "agent가 task를 더 잘 풀게 하는 것"이다. 잘 적힌 wiki여도 agent가 못 읽으면 무의미하다. 잘 안 적힌 wiki여도 agent가 어떻게든 task를 풀면 (의외로) 의미 있다.

task 검증은 이 진짜 목적에 직접 답한다. 그래서 task 검증 fail은 다른 종류 fail과 본질이 다르다. wiki 정적 속성 검증 fail은 wiki의 어디를 고쳐야 하는지를 가르친다. task 검증 fail은 system 어딘가가 안 맞는다는 신호 — wiki일 수도 있고, RAG일 수도 있고, LLM 변경일 수도 있다. 진단은 분기 단위 작업이지만, "system이 잘 작동하는가"를 매월 묻는 자리는 task 검증뿐이다.

6. 무엇을 해결하고 어떤 효과가 있나

이 검증의 효과는 한 가지다 — wiki 운영이 "잘 적기"가 아니라 "system 차원에서 일하기"로 frame이 바뀐다. wiki를 잘 적는 작업이 매월 +delta로 측정되니, 의미 없는 잘 적기(coverage 75%인데 delta는 5%p)에 시간을 안 쓰게 된다. 반대로 의미 있는 잘 적기(coverage는 안 늘었는데 delta가 +10%p)에 보상이 돌아간다.

잡지 못하는 것은 — 사실 이 검증이 catch range가 가장 넓다. fail이면 wiki·RAG·LLM·embedding 어느 곳이든 문제일 수 있다. 진단은 인간 손이 필요하다. 그러나 "문제가 있다"는 신호 자체를 만드는 자리로서 이 검증을 대체할 자리는 없다.

7. 정리

다수 task × 2 condition으로 wiki의 task-level 가치를 월 단위로 측정하는 검증에서 delta가 본질 metric이고 baseline -10%p가 알림 임계치가 된다. wiki 자체가 아니라 wiki를 포함한 system 전체를 검증한다 — 그래서 fail은 진단 비용이 크지만 신호 가치가 가장 크다.

위키 운영의 진짜 목적은 "agent가 task를 더 잘 풀게 하는 것"이지 "wiki가 잘 적혀 있는 것"이 아니다. 잘 적힌 wiki여도 agent가 못 읽으면 무의미. 못 적힌 wiki여도 agent가 어떻게든 task를 풀면 의미 있다. 매월 +delta가 그 진짜 목적에 직접 답하는 자리다. wiki의 정적 속성을 보는 검증들이 다 통과해도, system 차원에서 wiki가 일하는지는 별개로 측정해야 한다 — 그게 이 검증의 자리고, 위키 운영의 진짜 ground truth다.

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.