지휘자의 첫 추측이 천장이 된다: 리서치를 축으로 쪼개는 법

앞 글에서 에이전트 리서치가 그럴듯한 헛소리를 섞는 이유와, 그걸 막는 출처 기반 2단계 프로토콜을 개요로 짚었다. 그 글 끝에서 한 가지를 다음으로 미뤘다 — 축 분할(axis discovery)이 왜 조사의 천장을 결정하는가. 이 글이 그 약속을 받는다.

개요에서 축 분할은 "주제를 서로 겹치지 않는 하위 축으로 먼저 쪼개는 것"이라고 한 문장으로 지나갔다. 그 한 문장 안에 사실은 조사 전체의 운명이 걸려 있다. 자료를 얼마나 잘 모으느냐보다 먼저, 무엇을 모을 자리로 잡았느냐가 결과의 상한을 정하기 때문이다. 이 글은 그 메커니즘을 파고, 축을 어떻게 펼치고, 도메인 맵(domain map)으로 어떻게 적어 두고, 거기서 작업 스케줄을 어떻게 뽑고, 본격 수집 전에 빠진 곳을 어떻게 공격하는지를 정리한 노트다.

주제를 한 덩어리로 던지면 첫 추측이 천장이 된다

"이 주제를 여러 사이트에서 조사해서 정리해줘"라고 한 덩어리로 던지면, 지휘하는 에이전트(orchestrator, 일을 쪼개 나눠주고 진행만 관리하는 상위 에이전트)는 그 즉시 머릿속으로 조사 범위를 그린다. 어디를 뒤질지, 무엇이 중요한지에 대한 첫 그림이다. 문제는 이 첫 그림이 암묵적이면서 동시에 최종적이라는 데 있다.

암묵적이라는 건, 그 범위가 어디에도 적히지 않는다는 뜻이다. 최종적이라는 건, 그 뒤에 도는 모든 일꾼 에이전트(worker)가 이 적히지 않은 그림 안에서만 움직인다는 뜻이다. 처음에 떠올리지 못한 관점은 누구의 일거리도 되지 않는다. 일거리가 안 됐으니 조사되지 않고, 조사되지 않았으니 결과에도 없다. 그래서 빠진 줄도 모른 채 지나간다.

이게 단순한 누락과 다른 점은, 누락이 조용하다는 데 있다. 잘못 조사한 자료는 검증 단계에서 걸러진다. 출처가 부실하면 신뢰도 꼬리표가 낮게 붙고, 사실이 틀리면 사실 검증에서 드러난다. 하지만 처음부터 시야 밖에 있던 관점은 검증할 대상조차 없다. 30개 사이트를 깐깐하게 뒤지고 출처를 한 줄 한 줄 대조해도, 첫 그림이 좁았으면 그 좁은 범위를 아주 꼼꼼하게 조사한 결과가 나올 뿐이다. 정밀함은 천장을 올려주지 않는다.

그래서 조사의 품질은 수집의 성실함보다 먼저, 첫 그림의 넓이에서 갈린다. orchestrator의 첫 추측이 곧 조사의 천장이라는 말은 비유가 아니라 절차상의 사실에 가깝다. 천장을 올리려면 첫 추측 단계에 손을 대야 한다.

축 분할: 첫 추측을 펼쳐서 적어 둔다

해법은 첫 그림을 머릿속에 두지 않고, 본격 수집 전에 종이 위로 끌어내 펼치는 것이다. 이게 축 분할(axis discovery)이다. 주제를 한 덩어리로 두지 않고, 서로 독립적인 하위 축(axis, 관점의 한 갈래)으로 먼저 쪼갠다.

"독립적"이 핵심이다. 축끼리 겹치지 않게 잘라야 두 가지를 동시에 얻는다.

• 겹치지 않는 병렬 작업 — 축이 서로 독립이면 여러 에이전트를 각 축에 하나씩 붙여 동시에 돌려도 같은 사이트를 또 뒤지지 않는다. 개요에서 말한 "병렬 중복"이 구조적으로 막힌다.
• 빠진 관점의 가시화 — 축을 나란히 펼쳐 놓으면, 거기 없는 관점이 눈에 띈다. 머릿속 한 덩어리일 때는 무엇이 빠졌는지 보이지 않지만, 서너 개 축으로 갈라 적어 두면 "여기엔 비판적 시각이 없네" 같은 빈자리가 드러난다.

흔한 출발점은 세 축이다 — "공식 출처 / 시장과 실무 / 논란과 실패". 공식 출처는 주제를 정의하는 1차 자료, 시장과 실무는 실제로 어떻게 쓰이는지, 논란과 실패는 무엇이 다투어지고 어디서 깨지는지를 맡는다. 이 셋이 정답은 아니다. 다만 한 덩어리를 셋으로 갈라 놓는 것만으로도, 첫 추측이 보통 놓치는 "논란과 실패" 같은 축이 강제로 시야에 들어온다는 게 핵심이다. 축 분할의 목적은 완벽한 분류가 아니라, 첫 추측을 밖으로 꺼내 공격 가능한 대상으로 만드는 것이다. 머릿속에 있으면 따질 수 없지만, 적혀 있으면 따질 수 있다.

도메인 맵: 각 축이 무엇을 책임지는지 못 박는다

축을 펼쳤으면 각 축이 정확히 무엇을 책임지는지 적어 둬야 한다. 그 자리가 도메인 맵(domain map)이다. 조사의 설계도에 해당하는 한 장의 파일로, 각 축마다 다음을 가진다.

• id / label — 축의 식별자와 사람이 읽을 이름
• 우선순위(priority) — critical / high / medium / low 중 하나. 어느 축에 자원을 먼저 쏟을지를 정한다
• 답해야 할 질문들(questions) — 이 축이 끝났을 때 답이 나와 있어야 할 물음들. 예: 공식 출처 축이라면 "어떤 공식 출처가 이 주제를 정의하는가", "그들은 어떤 용어를 쓰는가"
• 볼 출처 family(source families) — 이 축에서 뒤질 출처의 종류. 공식 웹사이트·문서·정책 페이지, 또는 제품 문서·사례 연구·기술 블로그, 또는 이슈 트래커·사고 보고서·비판적 리뷰 같은 묶음
• 필요 산출물(required outputs) — 이 축이 남겨야 할 결과물. 출처 목록(inventory), 사이트 프로파일(profiles) 등

여기에 더해, 모든 축에 공통으로 적용되는 출처 정책을 맵의 기본값으로 미리 박아 둔다. 선호할 출처와 피할 출처를 조사 시작 전에 정의해 두는 것이다.

• 선호: 공식 문서, 1차 출처, 표준 기구, 규제 기관 발행물, 동료심사 논문
• 피함: 근거 없는 요약, 베껴 쓴 SEO 페이지, 근거 없는 익명 주장

이 정책을 미리 못 박는 이유는, 수집이 한창일 때는 판단이 흔들리기 때문이다. 그럴듯한 요약 페이지를 만나면 일단 담고 싶어진다. 출처 정책이 맵 상단에 적혀 있으면, 그 판단을 매번 새로 하지 않고 정해진 규칙으로 거른다. 도메인 맵은 그래서 단순한 목차가 아니라, 조사 내내 참조되는 계약서에 가깝다. 첫 추측을 적어 둔 종이가, 그대로 조사 전체의 기준선이 된다.

도메인 맵을 작업 스케줄로 푼다

도메인 맵은 설계도일 뿐 아직 작업이 아니다. 일꾼 에이전트가 실제로 집어 들 수 있는 작업 단위로 풀어야 한다. 이 변환을 맡는 게 스케줄 생성이다.

원리는 간단하다. 도메인 맵의 각 축이, 수집의 각 단계마다 하나씩 작업으로 펼쳐진다. Phase 1의 단계는 정찰(source-scout) → 사이트 프로파일(site-profile) → 수집(collection) → 분류(classification) → 출처 검증(source-verification) → 사실 검증(fact-verification)으로 이어지는데, 스케줄 생성기는 "지금 어느 단계인지"를 받아 각 축을 그 단계의 작업으로 변환한다. 예를 들어 정찰 단계라면, 세 축은 각각 "이 축의 단단한 출처 family를 찾아라"라는 작업 세 개가 된다.

이때 두 가지가 자동으로 따라붙는다.

• 우선순위 정렬 — 작업은 축의 우선순위 순으로 늘어선다. critical 축이 맨 앞, low 축이 맨 뒤다. 자원이 한정돼 있을 때 무엇을 먼저 깔지가 스케줄에 박혀 나온다.
• 완료 표식 자리 예약 — 각 작업은 자기가 끝나면 남길 완료 표식(done marker) 파일의 경로를 미리 달고 나온다. 일꾼이 작업을 끝내면 그 자리에 표식을 남기고, 지휘자는 그 표식 개수를 세어 진행을 안다.

도구로 치면 도메인 맵 파일을 입력으로 받아 작업 스케줄 파일을 뱉는 작은 스크립트 하나다. 중요한 건 그 스크립트가 무엇을 하지 않는가다. 웹을 긁지 않고, 모델을 부르지 않는다. 그저 "축 × 단계"를 우선순위 순으로 늘어놓은 표를 만들 뿐이다. 판단은 전부 일꾼 에이전트에게 있고, 스케줄러는 누가 무엇을 언제 집을지의 뼈대만 깐다. 도메인 맵이 "무엇을 책임지나"였다면, 스케줄은 "그걸 어떤 순서로 누가 집나"다.

완결성 게이트: 규모를 키우기 전에 빈자리를 공격한다

축을 펼치고 스케줄까지 깔았어도, 첫 추측이 좁았을 위험은 아직 남아 있다. 축을 세 개 그렸다고 그 셋이 충분하다는 보장은 없다. 그래서 본격 수집으로 규모를 키우기 직전에 한 단계를 일부러 끼운다 — 완결성 게이트(completeness gate)다.

이 단계가 하는 일은 협력이 아니라 공격이다. 짜 놓은 축과 도메인 맵을 놓고, "빠진 관점은 없나"를 적대적으로 따진다. 이 주제에서 마땅히 다뤄야 할 시각 중 어느 축에도 안 잡힌 게 있는가. 한쪽으로 치우치진 않았는가. 반대 증거를 담을 자리가 있는가. 통과시키려고 보는 게 아니라, 구멍을 찾으려고 본다.

타이밍이 전부다. 완결성은 본격 수집 전에 공격해야 한다. 이유는 비용이다.

• 수집이 커지기 전에 빠진 축을 찾으면, 도메인 맵에 축 하나를 더 적고 스케줄을 다시 푸는 것으로 끝난다. 거의 공짜다.
• 30개 사이트를 다 뒤지고 분류·검증까지 끝낸 뒤에 "비판적 시각이 통째로 빠졌네"를 알아차리면, 그 축을 위해 수집 단계를 처음부터 다시 돌려야 한다. 이미 쌓인 자료의 균형도 깨진 채다.

그래서 완결성 게이트는 싼 자리에서 비싼 실수를 막는 관문이다. 첫 추측의 한계는 어차피 어딘가에서 드러난다. 그걸 자료가 산처럼 쌓인 뒤에 드러나게 둘지, 종이 한 장에 축 셋이 적혀 있을 때 드러나게 할지의 차이일 뿐이다. 완결성 게이트는 후자를 강제한다.

왜 이 순서가 천장을 올리나

지금까지의 흐름을 한 줄로 묶으면 이렇다. 축을 먼저 펼치고, 도메인 맵에 못 박고, 스케줄로 풀고, 완결성을 공격한다 — 전부 본격 수집이 시작되기 전에.

이 순서가 천장을 올리는 이유는, 첫 추측의 한계를 깨는 시점을 조사의 맨 앞으로 끌어왔기 때문이다. 한 덩어리로 던지면 첫 추측이 적히지도 않은 채 천장으로 굳지만, 축으로 펼쳐 적으면 그 추측이 공격 가능한 대상이 된다. 완결성 게이트는 그 적힌 추측을 조사가 시작되기 전에 두들겨, 좁았던 시야를 자료가 쌓이기 전에 넓힌다. 천장이 굳기 전에 손을 대는 것이다.

그러는 동안 지휘자의 역할은 달라지지 않는다. orchestrator는 여전히 원문을 읽지 않는다. 축을 펼치고 완결성을 따지는 일조차도, 지휘자가 보는 건 도메인 맵·스케줄·완료 표식·파일 개수뿐이다. 원문은 일꾼이 파일에 남기고, 지휘자에게는 상태와 경로와 짧은 메모만 돌려준다. 만약 지휘자가 완결성을 따지겠다고 모든 원문을 끌어와 읽기 시작하면, 그 순간 앞 글들에서 말한 원자료 과적재가 다시 시작된다. 천장을 올리는 작업조차 파일 위에서, 원문을 읽지 않은 채로 이뤄져야 한다는 게 이 프로토콜의 일관된 규율이다.

이 절차들은 한곳에 정리해 공개 저장소로 묶어 두었다. 도메인 맵 템플릿과 스케줄 생성기를 포함한, 설치할 것 없는 순수 파일 규칙이다.

저장소: github.com/aminpiano/agentic-workflows

정리

조사의 천장은 수집의 성실함이 아니라 첫 그림의 넓이에서 갈린다. 주제를 한 덩어리로 던지면 지휘 에이전트의 첫 추측이 적히지도 않은 채 조사의 천장으로 굳고, 그 바깥은 빠진 줄도 모르게 지나간다.

축 분할은 그 첫 추측을 밖으로 꺼내 펼친다. 도메인 맵이 각 축의 책임·우선순위·출처 정책을 못 박고, 거기서 우선순위 순의 작업 스케줄이 풀리고, 완결성 게이트가 본격 수집 전에 빠진 관점을 공격한다. 첫 추측의 한계를 조사가 시작되기 전에 깨는 것 — 그게 천장을 올리는 방법이다. 화려한 알고리즘이 아니라, 머릿속 그림을 종이로 끌어내 공격 가능하게 만드는 단순한 순서다.