경계에서의 검증: 외부에 닿는 모든 것

1. So What?

어느 순간부터 내 회신 초안을 보다가 한 마디가 자주 떠올랐다. "So What?"

머천트 입장에서 이 회신을 받으면 다음에 무엇을 해야 할까. 기술적으로는 정확하지만 액션이 없는 회신. 원인은 분석했지만 머천트는 무엇도 시작할 수 없는 회신. 그게 So What이 떠오르는 회신이었다.

"수신자 도메인 언어"라는 추상 표현이 있다. 결국엔 머천트의 눈높이에 맞춘다는 뜻이다. 나는 거기를 중점적으로 파고들었다. 회신의 마지막 한 줄에 "당신은 이런 상황이고, 다음으로 X를 하시면 됩니다"를 더한다. 그 한 줄이 회신의 무게를 바꾸는 걸 봤다.

이 사고는 머천트 회신에서 멈추지 않았다. Ops SC, JIRA 에스컬레이션, manager 핸드오프 — 받는 사람이 다른 도메인 언어를 쓸수록 더 정밀해야 했다. 결국 check_response의 tone calibration 룰 — 수신자가 누구인지에 따라 어휘와 구조를 다르게 검사하는 — 도 같은 사고에서 나왔다.

2. 검색 어시스턴트는 시작이지 결론이 아니다

2026-05-02. 사내 RAG 기반 검색 어시스턴트가 만든 검색 결과 요약 위에, 또 다른 LLM(ollama)을 얹어 한 번 더 요약하려는 시도가 내 손에 있었다.

곰곰이 보니 답은 명료했다. 검색 어시스턴트는 조사의 시작을 알리는 도구다. 지난 모든 데이터를 서치해서 한 움큼 쥐어주면, 거기서부터 JIRA와 Confluence MCP로 하나씩 전부 Fetch해 가면서 진위 여부를 파악하는 것 — 그게 이미 가장 최적화된 흐름이었다. ollama로 한 번 더 요약하는 건 합성된 거짓을 만드는 길이었지 결론을 강화하는 길이 아니었다.

여러 시도를 해본 끝의 인정이다. 하나의 효과 없는 아이디어를 포기하면서 알게 된 건, 도구마다 자기 자리가 있다는 것. 검색 어시스턴트는 출발점, MCP fetch는 검증, 결론 인용은 1차 출처에서. 이걸 gate_source_fetch.sh hook으로 코드화했다 — 회신 단계 진입 전에 어시스턴트가 인용한 JIRA / Confluence / URL이 본문 fetch까지 가지 않았으면 차단한다.