GraphRAG | Exit Policy preview action 적용

시리즈: GraphRAG 구축기 #24

이전: 23편 | 목록 | 다음: 25편

2026년 7월 3일 | 개인 프로젝트 · GraphRAG

---

GraphRAG profile registry를 만지다 보면 제일 조심스러운 지점이 있다. 평가 리포트는 어떤 조건이 충족됐다고 말하지만, 그 조건을 곧장 설정 파일에 반영해도 되는지는 별개의 문제다. 지난 회차에서 나는 exit policy가 제안하는 행동을 읽기 전용 preview report로 먼저 남기게 했다. 이번에는 그 preview 중 하나를 사람이 명시적으로 고른 뒤 registry metadata에만 적용하는 작은 명령을 붙였다.

Exit policy preview를 바로 상태 변경으로 쓰지 않고, target profile과 action을 확인한 뒤 registry metadata에 적용하는 흐름.

preview와 적용 사이에 한 칸을 둔 이유

지금 `path_bridge_probe`는 warning이 길어지고 있고, 특히 `doc-bridges` 쪽에서 계속 신호가 나온다. 그래서 리포트만 보면 `narrow-warning-scope` 같은 행동이 꽤 자연스럽다. 하지만 이 profile의 exit policy는 아직 draft이고 activation gate도 manual confirmation이다. 이런 상태에서 evaluator가 자동으로 registry를 바꾸면, 나중에 왜 profile이 observe에서 빠졌는지 추적하기가 어려워진다.

그래서 이번 반복의 기준은 단순했다. 조건 충족은 리포트가 말하고, 적용은 별도 명령이 말하게 하자. 명령은 target profile 이름과 preview action 이름을 직접 받아야 하고, draft/manual-gated policy에서 나온 action이면 확인 플래그가 없을 때 거절한다. 이 정도만 있어도 “추천이 있었다”와 “내가 그 추천을 받아 기록했다”가 한 단계 분리된다.

이번에 붙인 명령의 형태

`profile_registry` 쪽에 exit policy preview report를 읽는 경로를 추가했다. 입력은 기존 registry, `registry-exit-policy-action-preview.json`, target profile, action 이름이다. 이번 smoke run에서는 `path_bridge_probe`와 `narrow-warning-scope`를 골랐다. 확인 플래그를 주지 않으면 명령이 멈추고, 확인 플래그를 주면 output registry snapshot을 새로 만든다.

중요한 점은 여기서도 실제 profile 설정을 줄이거나 status를 바꾸지 않았다는 것이다. output registry에서 `path_bridge_probe`의 status는 여전히 `observe`다. 대신 `last_action`과 `exit_policy_preview_action_history`에 어떤 preview를, 어떤 조건 때문에, 어떤 source report에서, 어떤 시각에 적용했는지가 남는다. 나는 이쪽이 지금 단계의 GraphRAG MVP에는 더 맞다고 봤다.

남긴 산출물

재현용 bundle은 iteration 45 이름으로 따로 만들었다. apply report에는 선택된 action이 `narrow-warning-scope`로 들어가고, condition은 `narrow-warning-scope-before-next-run`으로 남는다. `manual_confirmation_required`와 `manual_confirmation_confirmed`가 둘 다 true인 것도 확인했다. 그리고 `status_changed`는 false다. 내가 원한 결과가 바로 이 조합이었다.

이 말은 “아무 일도 하지 않았다”가 아니다. 반대로 registry가 이제 실험 운영 판단의 흔적을 하나 더 갖게 됐다는 뜻이다. 다음 사람이 같은 파일을 열어도 이 profile이 왜 아직 observe인지, 그런데 왜 scope 축소 실험으로 이어져야 하는지 훨씬 빨리 읽을 수 있다. 검색 품질 실험에서는 이런 provenance가 생각보다 중요하다.

처음에는 이 적용 명령이 registry의 `exit_policy` 자체를 고쳐도 되지 않을까 생각했다. 그런데 그렇게 하면 preview action 적용과 profile tuning이 한 번에 섞인다. scope를 줄이는 실험은 실제 ranking 결과를 다시 봐야 하는 일이고, 이번 명령은 “그 실험을 해도 되는 근거를 registry에 남기는 일”에 가깝다. 이 둘을 분리해 두면 실패했을 때 되돌릴 지점도 더 분명해진다.

작게 남겨 둔 한계

이번 구현은 의도적으로 한 번에 action 하나만 적용한다. preview report 안에 후보가 두 개 있어도 target profile과 action 이름을 직접 적어야 한다. 여러 action을 한꺼번에 적용하는 기능은 편해 보이지만, 지금 단계에서는 오히려 위험하다. warning scope 축소와 manual review 기록을 한 번에 처리하면, 나중에 어떤 판단이 어떤 변경을 만들었는지 다시 쪼개야 한다.

또 하나의 한계는 output registry가 아직 다음 evaluation의 실행 계약을 직접 바꾸지 않는다는 점이다. `status`를 바꾸지 않으니 profile set은 그대로다. 대신 이 snapshot은 다음 반복에서 profile diff를 만들 때 근거 파일로 쓰기 좋다. 나는 이 정도의 느린 전진이 GraphRAG 운영 루프에는 더 안전하다고 느낀다.

결국 이번 회차의 산출물은 기능이라기보다 판단 경계선에 가깝다. evaluator가 찾아낸 신호, 사람이 승인한 action, 아직 바꾸지 않은 profile 설정이 한 파일 안에서 동시에 보인다. 이 경계선이 있어야 다음 실험에서 점수가 좋아졌을 때도 “자동으로 고쳐서 좋아진 것인지, 확인된 판단 뒤 profile을 바꿔서 좋아진 것인지”를 구분할 수 있다.

테스트에서 잡고 싶었던 것

테스트는 두 축으로 잡았다. 첫 번째는 안전장치다. draft/manual-gated preview action을 확인 없이 적용하려고 하면 실패해야 한다. 두 번째는 확인된 적용 경로다. 확인 플래그가 있을 때 output registry에 `last_action`, blocking scopes, source report path, history entry가 같이 남아야 한다.

전체 검증은 profile registry, profile eval, 기본 pipeline 테스트를 같이 돌렸다. 결과는 51개 테스트 통과였다. 지난 회차보다 테스트 수가 늘어난 이유는 preview를 만드는 쪽이 아니라 preview를 실제 registry metadata로 접는 쪽을 새로 고정했기 때문이다.

다음에는 실제 profile diff를 봐야 한다

이번 작업은 일부러 마지막 단추를 누르지 않았다. `narrow-warning-scope`를 기록했지만 실제 scoring profile의 scope를 바로 줄이지는 않았다. 다음 반복에서는 이 기록을 근거로 `path_bridge_probe`의 `doc-bridges` warning을 줄이는 profile diff를 만들고, 같은 query set에서 top-1 hit와 coverage가 어떻게 바뀌는지 다시 볼 생각이다.

GraphRAG MVP가 처음에는 검색 랭킹을 올리는 장난감처럼 시작했는데, 지금은 어느 profile을 남기고 어떤 profile을 접을지 다루는 작은 운영 루프가 되고 있다. 화려한 변화는 아니지만 마음에 든다. 자동으로 고치는 것보다, 자동으로 제안하고 명시적으로 적용한 흔적을 남기는 구조가 나중에 더 덜 무너질 것 같다.

시리즈: GraphRAG 구축기 #24

이전: 23편 | 목록 | 다음: 25편