본문으로 건너뛰기
Ankole

Deep Research로 장기 연구 실행하기

AI Agent용: 이 페이지의 Markdown 버전은 https://ankole.agentbull.com/ko-KR/docs/deep-research-job/index.md에 있습니다. 문서 색인은 https://ankole.agentbull.com/ko-KR/llms.txt에 있습니다.

Deep Research는 문헌 검토, 경쟁사 조사, 다중 소스 팩트 체크, 여러 설명을 비교해야 하는 예측, 그리고 알려진 결과에 대한 이전 예측의 검토를 위한 것입니다. 이러한 작업은 반복적인 검색, 읽기, 교차 검증이 필요합니다. Agent는 이 작업을 Background Agent Job으로 옮기고 사용자의 다른 메시지를 계속 처리합니다.

이는 몇몇 웹 페이지를 검색하고 요약하는 것과는 다릅니다. Job은 자체 영속 workspace에서 단계별로 진행됩니다. 계획을 세우고, 병렬로 자료를 수집하여 소스 노트로 작성하고, 그 증거에서 결론을 도출하며, 연구 과정을 볼 수 없는 verifier에게 보고서를 넘기고, 마지막으로 각 성공 기준에 맞춰 보고서를 audit합니다. 진지한 연구는 보통 30–90분이 필요합니다. 빠른 답변만 필요하다면 직접 질문하고 Deep Research를 사용하지 마세요.

시작하기 전에

Quick start를 완료하고 Agent가 채팅 채널에서 응답할 수 있는지 확인하세요. Agent가 공개 웹 페이지를 검색해야 한다면 web_search와 web_fetch model profile을 구성하세요.

Job은 항상 AIGateway를 사용합니다. ChatGPT 구독 용량을 사용하려면 ChatGPT subscription provider를 만들고 Console → Agents → Background Agent Jobs에서 선택하세요.

Job은 Agent에 대해 활성화되고 Background Agent Jobs에서 허용된 모든 Skill을 자동으로 받습니다. 인스턴스가 데이터 소스 Skill(예: 금융 데이터 인터페이스나 내부 시스템 연결)을 활성화하면, Job은 공개 웹을 검색하기 전에 해당 데이터를 사용합니다. Job을 별도로 승인할 필요는 없습니다.

연구 시작하기

주제, 시간 범위, 증거 규칙, 출력 형식을 명시하세요. 백그라운드 실행을 요청하세요:

Run this as a Deep Research Background Agent Job.
Compare the pricing and product updates from these three vendors over the last
two quarters. Cite primary sources, separate facts from inference, and return
a report with links. Ask me before you expand the scope or use paid data.

생성 전 명확화

Agent는 한 문장에서 작업을 시작하지 않습니다. Job을 만들기 전에 해결되지 않은 각 연구 선택 사항에 대해 인터뷰합니다. 목표와 그 용도, 성공 기준, 범위와 시간 경계, 증거 규칙, 결과물이 그것입니다. 한 번에 한 가지 질문을 하고 추천 답변을 제시합니다. 환경이 공급할 수 있는 사실은 조회하고, 진짜 결정만 사용자에게 가져옵니다. Job은 사용자가 확인한 후에만 생성됩니다.

이 몇 분은 그 비용의 가치가 있습니다. 잘못된 연구 방향은 다음 60분의 수집과 분석을 낭비하지만, 한 문장이 질문 하나를 해결합니다.

인터뷰를 원하지 않으면 “질문을 그만하고, Job을 직접 만들고, 나머지는 스스로 결정하세요”라고 말하세요. 그러면 Agent는 사용자를 대신해 내린 가정과 Job에 맡긴 선택지를 밝히고 Job을 생성합니다.

좋은 요청이 담아야 할 것

정의된 범위가 “깊이 조사해줘”보다 유용합니다. 요청이 다음 항목을 명시하면 보고서는 필요한 것에 더 가까워집니다:

  • 주제와 답해야 할 질문. 토픽만으로는 부족합니다. “재생에너지 산업을 분석해줘”와 “이 세 벤더 중 다음 두 분기 안에 가격을 인하할 가능성이 더 높은 곳은 어디이며, 그 근거는 무엇인가?”는 완전히 다른 보고서를 만듭니다.
  • 시간 범위와 정보 컷오프. 검토나 이전 판단의 재구성에서 이 항목은 Job이 나중에 알게 된 정보를 사용할 수 있는지 결정합니다.
  • 증거 규칙: 1차 소스만 사용, 인용 필수, 사실과 추론의 분리.
  • 분석 방법(원한다면). 예를 들어 ACH로 경쟁 가설을 비교하거나, 과거 사례를 사용하는 전향적 분석을 요청할 수 있습니다. 방법을 지정하지 않으면 Job이 스스로 선택합니다.
  • 결과물과 언어. 기본값은 Markdown 보고서입니다. PDF, PPT, 웹 페이지를 요청하면 Job은 Markdown 소스도 함께 요청하지 않는 한 해당 형식만 제공하며, 스타일을 지정하지 않으면 Agent의 DESIGN 시각 규칙을 적용합니다.
  • 경계: 예산, 유료 데이터 소스, 범위 확장, 마감 시한.

명시된 길이는 대략적인 목표치입니다. “3페이지 PDF”는 정확한 값을 요청하지 않는 한 약 3페이지를 의미합니다.

Job의 작동 방식

Job의 내부 방법을 알면 진행 상황을 읽고, 결과에 어느 수준의 신뢰를 둘지 판단하며, 무엇을 물어야 할지 알 수 있습니다. 각 Deep Research Job은 자체 영속 workspace에서 네 단계를 거칩니다.

1. 계획

Job은 먼저 workspace에서 사용 가능한 Playbook을 나열하고 질문에 적용되는 방법을 읽습니다. 범위가 넓거나, 주제가 아직 명확하지 않거나, 관련 사실이 모델의 지식 이후 변경되었을 수 있으면 Job은 sub-Agent 하나를 보내 빠른 탐색을 수행합니다. 이 탐색은 증거를 수집하지 않으며 결론을 내리지 않습니다. 주제의 현재 의미와 경계를 확립하고, 모델이 놓칠 수 있는 핵심 개념, 연구 차원, 검색어, 데이터 소스를 찾습니다.

그런 다음 Job은 상세한 수집 계획을 준비합니다. 계획이 모델 기억 속의 오래된 세계 버전이 아니라 현재의 사실에서 시작하도록, 탐색은 계획보다 먼저 이루어집니다.

2. 증거 수집

여러 sub-Agent가 수집 계획을 병렬로 실행합니다. 유용한 자료는 모두 sources/ 아래의 Markdown 노트가 되며, 파일 시작 부분의 YAML에 출처, 발행 시각, 작성자, 신뢰도, 링크가 기록됩니다. 이후의 모든 분석은 한 번의 검색에서 얻은 일시적 인상이 아니라 이러한 노트를 인용합니다.

수집은 하나의 소유권 규칙을 따릅니다. 각 데이터 소스와 각 1차 문서에는 소유자(owner)가 하나씩 있습니다. 소유자는 그 자료를 한 번 수집하고 결과를 파일로 작성합니다. 다른 sub-Agent는 그 파일을 읽고 요청을 반복하지 않습니다. Job은 공지, 제출 서류, 데이터셋을 각각 한 번만 다운로드하고, 나중에 온 sub-Agent가 찾을 수 있도록 식별자로 파일 이름을 지정합니다. 도구가 목록을 받아들이면 Job은 한 번의 호출로 전체 배치를 요청합니다.

활성화된 Skill의 데이터는 공개 웹 검색보다 먼저 사용됩니다. Job은 먼저 Skill 문서를 읽고, Skill이 제공하지 않는 부분이나 Skill 호출에서 데이터가 없음이 드러난 부분에만 web_search나 web_fetch를 사용합니다. 데이터 인터페이스에서 가져와야 할 데이터를 대체하기 위해 공개 웹사이트를 읽지 않습니다. Skill이 공급할 수 없는 부분은 sources/에 기록된 evidence gap이 되며, 조용히 누락되지 않습니다.

모든 정보가 검색에서 오는 것은 아닙니다. 필요한 경우 Job은 상류 원시 데이터를 처리하는 스크립트를 작성하고 구조화된 데이터에서 필요한 값을 도출합니다. 초기 정리 후 Job은 정보가 여전히 빠져 있는지, 일부 정보가 충돌하는지, 이후 분석에 필요한 컨텍스트가 완전한지 검토합니다. 필요하면 추가로 수집합니다.

3. 분석 및 검증

결론은 이용 가능한 정보에서 단계적으로 도출되어야 하며 닫힌 논리 사슬을 형성해야 합니다. Job은 먼저 판단을 고르고 나서 지지 자료를 찾지 않습니다. 보고서는 사실, 의견, 가설, 추론을 분리합니다. 현재 증거가 둘 이상의 해석을 허용하면 Job은 모두 나열하고 어느 것을 선호하는지 밝히며 신뢰도를 제시합니다. 뉴스와 마케팅 주장에 대해 건전한 회의를 유지하고, 작성하면서 확증 편향, 표본 편향, 서사 오류(narrative fallacy)에 대응합니다.

그러면 독립 verifier가 분석을 검토합니다. 이 verifier는 대화 턴을 상속받지 않으며 Job의 비공개 작업 상태도 받지 않습니다. 보고서와 사용자의 연구 목적만 받습니다. 형식과 내용을 모두 검토합니다. 형식 면에서는 보고서가 사실, 의견, 가설을 분리하는지, 충분한 인용을 제공하는지, 실질적 정보 가치가 있는 결론을 제시하는지 확인합니다. 내용 면에서는 적대적으로 검토합니다. 논리가 내부적으로 일관적인지, 다른 설명이 가능한지, 보고서가 인과를 뒤집지는 않는지, 화살을 쏜 뒤 과녁을 정하지는 않았는지입니다.

verifier는 조언을 할뿐 최종 판단을 소유하지 않습니다. 실질적 불일치가 있으면 관련 분석과 보고서를 바꾸거나, 그 이유와 함께 보고서에 그대로 남습니다. 불일치가 겉보기 합의로 평탄화되지 않습니다.

4. 전달

전달은 기준 audit로 시작합니다. 보고서는 모든 성공 기준에 대해 설명해야 합니다. 인용된 증거로 기준을 충족하거나, 기준을 공개된 gap으로 명시하면서 결론에 미치는 영향을 밝힙니다. gap이 연구 목적을 무너뜨리고 시간이 허락하면 Job은 아직 도달 가능한 추가 증거를 수집합니다. 늦은 보고서는 불완전한 보고서만큼 확실하게 목적을 달성하지 못할 수 있습니다.

그런 다음 Job은 요청한 형식으로 결과물을 만들고, 가벼운 최종 검사를 위해 sub-Agent 하나에게 넘깁니다. 보고서는 사용자의 언어를 사용하고, 조지 오웰의 여섯 가지 작문 규칙을 따르며, 면책 조항을 추가하지 않습니다.

작업 상태, 복구, 재시작

Job은 workspace의 research-state.md에 비공개 작업 상태를 유지합니다. 각 성공 기준과 현재 상태, 지지에 열린 gap이 있는 후보 결론, 이유와 함께 기각된 방향, 수집된 정보의 타당성에 대한 미해결 우려가 그것입니다. 이 파일은 작업 memory이지 결과물이 아닙니다. 독립 검토가 스스로의 견해를 형성하고 연구자의 추론을 따르지 않아야 하므로, 어떤 verifier도 이 파일을 받지 않습니다.

이 파일 덕분에 진행 상황이 유지됩니다. Worker 중단이나 컨텍스트 손실 후에도 Job은 이 파일에서 계속하며 이미 확정된 내용을 다시 탐색하지 않습니다.

연구 중에 프레임이 잘못되었음을 발견하면(주제 오인, 질문 오독, 핵심 가정의 붕괴) Job은 분석에 패치를 붙이지 않습니다. 수정된 프레임을 research-state.md에 기록하고, 잘못된 프레임이 무효화하는 분석을 폐기한 뒤 영향을 받은 단계를 다시 수행합니다. 수집된 sources/는 유지하고, 수정된 프레임이 부족하게 만든 부분만 다시 수집합니다. 잘못된 프레임 위에 세운 보고서는 Job 전체를 낭비하므로, 재시작이 보기보다 저렴합니다.

Playbook: 플러그 가능한 연구 방법

Playbook은 Job workspace의 playbooks/ 디렉터리에 있는 방법 파일로, deep-research Agent Plugin의 workspace 템플릿과 함께 배포됩니다. 각 Playbook은 시작 부분에서 적용 시점을 선언합니다. 계획 단계에서 Job은 모든 Playbook을 나열하고 관련된 것들을 읽습니다.

Playbook은 추가 조언 그 이상입니다. 기본 분석, 검증, 보고서 순서를 자체 프로토콜로 대체할 수 있습니다. ACH가 기본 단일 패스 검토를 대체하는 것처럼 말입니다. 따라서 방법론은 교체 가능하고 확장 가능합니다. 연구 방법은 파일이며 모델이나 코드에 고정되어 있지 않습니다.

두 가지 일반 방법이 내장되어 있습니다.

ach: 경쟁 가설의 분석(Analysis of Competing Hypotheses)

정보가 불완전하거나, 충돌하거나, 기만적일 가능성이 있을 때 중요한 예측이나 진단은 여러 합리적 설명을 비교해야 합니다. ACH는 그 비교를 명시적으로 만들고 판단을 감사 가능하게 만듭니다. 열악한 증거를 개선하지 않으며 사용자를 대신해 답을 계산하지도 않습니다.

의미 있는 답이 하나뿐인 사실 조회에는 ACH가 필요하지 않습니다. 신뢰할 수 있는 데이터와 적절한 통계 또는 인과 모델이 질문에 답할 수 있다면 그 모델을 사용하고, ACH를 대체물로 취급하지 마세요.

가설은 증거보다 먼저 온다. Job은 먼저 정확한 질문, 정보 컷오프, 예측의 경우 예측 기간(horizon)과 결과 정의를 명시합니다. 그런 다음 증거를 평가하기 전에 모든 합리적 가설을 생성합니다. 이 순서는 첫 번째 그럴듯한 설명이 전체 분석을 정의하는 것을 막습니다. 각 가설은 같은 기간 동안 같은 수준에서 같은 질문에 답하며, Job은 가설들이 상호 배타적인지, 합리적 가능성을 모두 포괄하는지 명시합니다. 필수 가설 수는 없습니다. 비교가 수정할 이유를 줄 때까지 가설은 유지됩니다. 지지의 부족은 반증이 아니기 때문입니다.

증거는 도구가 검사할 수 있는 행렬(matrix)에 들어갑니다. Job은 가설 간 비교를 소유하는 competing-hypotheses.yaml 파일 하나를 유지합니다. 각 행은 모든 가설에 대해 평가할 수 있는 하나의 명제입니다. 관찰, 보고된 주장, 예상되었으나 없는 신호, 분석적 가정, 논리적 논증, 또는 base rate가 그것입니다. 각 행은 실제 유형, 소스 경로나 분석적 근거, 소스의 자격을 기록합니다. 어떤 것이 “추정된다”고 말하는 소스는 그것을 사실로 확립하지 않습니다. 그런 다음 Job은 구조 검사를 실행합니다:

bun tools/ach_check.ts

검사기는 구조적 누락과 안전하지 않거나 없는 로컬 소스 경로만 찾습니다. 가설이 그럴듯한지, 명제가 참인지, 소스가 이를 지지하는지, 관계가 올바른지는 판단하지 않습니다. 도구는 기계가 검사할 수 있는 것을 소유하고, 판단은 모델과 사용자에게 남습니다.

비교는 지지의 양이 아니라 판별성(diagnosticity)을 사용합니다. 각 행에 대해 Job은 가설이 참이라면 이 정보가 얼마나 예상될지 묻고, 정보가 가설을 증명하는지는 묻지 않습니다. expected, compatible, tension, contradicts, unknown, not applicable의 여섯 가지 관계만 사용하며, 각각 짧은 근거를 붙입니다. 판별성은 한 행 내부의 차이에서 나오므로, 가설을 따라 아래로 읽기 전에 행을 가로질러 읽습니다. 모든 가설과 호환되는 정보는 중요할 수 있지만, 가설을 구분하는 데는 거의 기여하지 않습니다.

의존성과 channel 커버리지. 복사된 보고서는 하나의 정보 기원입니다. 한 사건이 만든 여러 지표나 한 데이터셋에서 도출된 여러 결과도 독립적 지지가 아닙니다. 상관된 행은 유용한 세부 사항을 보존할 수 있지만 독립적 지지를 만들 수는 없습니다. channel 커버리지는 놓치기 쉽습니다. 서로 다른 가설은 서로 다른 channel에 나타나며, 한 가설의 증거가 아무도 검색하지 않은 channel에 있다면 비교는 세계가 아니라 사용자의 검색 커버리지를 측정합니다. 따라서 각 가설은 자신이 나타날 channel을 명시하고, Job은 그 channel에서 수집하거나 커버리지 gap을 기록합니다.

부재 신호와 linchpin. 부재는 예상 신호가 관찰 가능했고 검색이 그것을 합리적으로 찾을 수 있었을 때만 부정적 증거가 됩니다. Job은 또한 결과를 좌우하는 소수의 linchpin 항목과 가정을 식별하고 각각을 검증합니다. 그 항목이 거짓이거나, 오해를 불러일으키거나, 불완전하거나, 다른 항목에 의존하거나, 의도적으로 속이기 위해 만들어졌다면 판단이 어떻게 바뀌는지를 봅니다. 전체 판단에 대한 신뢰는 수집된 자료의 양이 아니라 가설 커버리지, 증거 품질, 의존성, 민감도에 달려 있습니다.

점진적 공개를 통한 3회 검증. ACH는 기본 검토를 자체 프로토콜로 대체합니다. 동일한 verifier가 세 번의 패스를 수행하며, 순서가 보호 장치입니다:

  1. Pass A: 소스에서의 독립적 재구성. verifier는 사용자의 연구 목적, 정확한 ACH 질문, 정보 컷오프, sources/ 접근만 받습니다. 행렬, 보고서, 연구자가 선호하는 가설, 연구자의 추론은 보지 못합니다. 그럴듯한 가설, 가장 판별력 있는 정보, 각 항목과 각 가설의 관계, linchpin을 식별하고 자체 잠정 평가를 기록합니다. 또한 부재 신호, 숨은 가정, 소스 의존성, 컷오프 누출, 가능한 기만, 그리고 대안을 구분할 다음 관찰도 식별합니다.
  2. Pass B: 행렬과의 비교. verifier가 자체 재구성을 기록한 후에만 competing-hypotheses.yaml을 받습니다. 두 분석을 비교하고, 소스로 뒷받침된 진술을 해당 노트로 추적하며, 각 linchpin과 논쟁이 있는 행에 대해 원본 자료를 조사하고, 구체적 결함을 이유와 함께 보고합니다.
  3. Pass C: 보고서 검토. 모든 Pass B 불일치가 처리된 후 보고서가 행렬에서 작성되어 동일한 verifier에게 전달됩니다. 보고서가 상대 평가, 판별 정보, 반증, 미해결 쟁점, 신뢰도의 근거와 한계를 충실히 제시하는지 확인합니다.

재구성을 보호하는 것은 다른 verifier가 아니라 순서입니다. 행렬은 verifier가 자체 재구성을 기록한 후에만 공개됩니다. 결론을 먼저 본 verifier는 결론을 앵커로 삼습니다.

행렬은 확률이 되지 않습니다. 정성적 행렬은 사후 확률을 만들지 않습니다. 그 라벨은 우도가 아니며, 행 개수는 확률이 아닙니다. 보고서가 숫자를 제시할 때는 명시적으로 주관적인 추정과 계산된 베이지안 결과를 구분하며, 베이지안 계산에는 가능성의 일관된 분할 또는 명시적 결합 모델, 사전 확률, 조건부 우도, 증거 의존성 처리가 필요합니다.

불충분한 증거는 판정일뿐 퇴로가 아닙니다. 그것은 변호하기 가장 쉬운 판단이므로, 이용 가능한 증거가 결정할 수 있었던 분석을 삼킬 수 있습니다. 비교가 가설을 구분하지 못하면 보고서는 그것이 사용자에게 무엇을 의미하는지, 기각된 가설이 실제로 참이라면 무엇을 치르게 되는지, 어떤 관찰이 가설을 구분할 수 있는지 명시합니다. 추가 연구는 추가할 수 있는 정보의 양이 아니라 가설을 구분하는 힘으로 선택됩니다.

analogical-foresight: 전향적 분석을 위한 역사적 사례

역사적 사례는 전향적 분석에 메커니즘, 변수, 검증 수단을 제공할 수 있습니다. 유추 분석의 단위는 전이 주장(transfer claim)입니다:

supported source-case mechanism -> specific target mapping
  -> conditions required for transfer -> target-side observation

이 사슬이 완전할 때만 역사는 증거가 됩니다. 표면적 유사성과 설득력 있는 역사적 이야기는 같은 메커니즘이 대상에서 작동한다는 것을 확립하지 못합니다.

사례를 언급하기 전에 대상 frame을 잡으십시오. Job은 대상 질문, 정보 컷오프, horizon, 현재 단계를 명시하고 충분한 대상 정보를 수집한 다음, 역사적 사례를 언급하기 전에 대상 구조를 개략적으로 그립니다. 지금까지의 관찰된 선행 조건, 사건 순서, 제약, 결과와, 각 추론에 대한 증거가 함께 있는 추론된 인과 관계, 분석을 바꿀 수 있는 미지의 요소와 설명되지 않은 단계가 그것입니다. 반대 순서로 하면 생생한 사례가 사용자를 대신해 문제를 정의해 버립니다. 재구성된 예측에서는 이후의 대상 사건이 사례를 선택하거나 대상 구조를 정의하거나 매핑을 판단할 수 없습니다.

인과 gap에서 후보를 생성합니다. 후보 사례는 대상 frame의 불확실한 관계, 누락된 요소, 설명되지 않은 단계에서 나옵니다. Job은 다른 행위자, 시기, 영역에 걸쳐 같은 방향의 관계, 인과 역학, 기능적 제약을 검색하고, 평가하기 전에 후보를 생성하여 첫 번째 익숙한 사례가 검색을 끝내지 못하게 합니다. 후보 집합이 하나의 익숙한 영역에 머물거나 하나의 역사적 이야기를 반복하면, Job은 대상 frame만 보는 컨텍스트 격리 sub-Agent에게 교차 영역 사례, 실패 사례, 결과가 뒤집힌 사례를 제안하도록 요청할 수 있습니다. 그 sub-Agent는 후보를 생성할뿐 대상을 판단하지 않습니다.

소스 사례의 메커니즘을 먼저 확립합니다. 사건 시퀀스는 아직 인과 설명이 아닙니다. Job은 유지된 각 사례의 사실을 검증하고, 주장된 메커니즘을 지지하는 증거를 식별하며, 공통 원인, 대안 메커니즘, 우연, 선택 효과, 후대 서사가 같은 시퀀스를 설명할 수 있는지 확인합니다. 같은 에피소드의 별칭, 하위 사건, 상위 집합, 또는 다른 기술은 독립적 지지를 주지 못합니다. 관계가 뒤집힌 사례, 전이가 실패한 사례, 단계가 다른 사례, 경계 조건이 깨진 사례는 반례나 메커니즘 한계의 증거로 유용하게 남습니다.

각 전이 주장을 audit합니다. 답에 영향을 줄 수 있는 모든 유추 파생 주장은 여섯 부분을 함께 유지합니다. 증거가 있는 소스 메커니즘, 매핑되는 구체적 대상 관계, 선행 조건·역할·방향·시점·규모·범위·인센티브의 실질적 차이, 전이 가정, 공유 소스·중첩 사건·공통 충격·정책 복제·공통 제도·공통 측정 같은 의존성, 그리고 전이를 지지하거나 약화시킬 수 있는 대상 측 관찰이 그것입니다. 행위자의 행동 분석에는 그 행위자 자신의 목표, 제약, 인센티브, 정보, 의사 결정 과정을 사용하며, 같은 위치에서 사용자 자신이 어떻게 행동할지에 대한 기대는 그 행위자에 대한 증거가 아닙니다. 유지된 사례는 최소한 하나의 후보 메커니즘, 누락 변수, 조건부 경로, 대상 측 지표, 반례, 또는 경계 조건에 기여해야 합니다. 역사적 서사만 기여하는 사례는 제거됩니다.

사례를 결합하기 전에 의존성을 확인합니다. 독립적으로 유용한 여러 사례는 하나의 역사적 이야기에 대한 의존을 줄일 수 있지만, 메커니즘이 대상에서 작동한다는 것을 보여주지는 않습니다. Job은 겉보기 반복이 같은 에피소드, 제도, 소스 서사, 충격, 전파 경로, 정책 확산, 측정 방법에서 오는 것인지 검토합니다. 긍정적 패턴이 중요할 때는 제안된 요인은 있었지만 결과가 없었던 사례나, 결과가 다른 메커니즘을 통해 발생한 사례도 찾습니다. 의도적으로 선택된 유추 집합은 reference class가 아니므로 그 사례 수는 base rate, 확률, 신뢰 수준이 아닙니다.

“방어 가능한 유추 없음”은 허용된 결론입니다. 답에 영향을 주는 모든 유추 파생 주장이 다음을 식별할 때만 분석은 완료됩니다. 메커니즘과 그것을 실질적 대안 설명과 구분하는 증거, 방향·단계·범위와 함께 대상에 매핑된 구체적 관계, 실질적 차이·의존성·전이 조건, 그리고 그것을 지지하거나 약화시킬 수 있는 대상 측 관찰이 그것입니다. 발견된 모든 반례와 실패한 매핑은 설명되어야 합니다. 어떤 후보도 전이 사슬을 충족하지 못하면 올바른 결론은 방어 가능한 유추를 찾지 못했다는 것이지, 설득력 있는 사례를 보고서에 남기는 것이 아닙니다.

두 방법의 협력

두 방법은 서로 다른 문제를 해결하며 하나의 연구 작업 안에서 연결될 수 있습니다. 유추는 ACH 가설을 제안하거나 찾아야 할 증거를 식별할 수 있고, ACH는 그 가설들 사이의 판별적 비교를 수행합니다. 역사적 사례는 대상의 직접적 관찰이 아닙니다. 명시적이고 방어 가능한 전이 주장을 통해서만 대상 주장을 지지합니다.

도메인에 맞는 Playbook 추가하기

프라이빗 배포는 workspace 템플릿에 자체 방법 파일을 추가할 수 있습니다. 예를 들어 내부 실사 절차, 업계 데이터 소스 카탈로그, 특정 종류의 결정에 대한 검토 기준이 그것입니다. name과 description 필드가 있는 파일은 발견 가능해집니다. 새 Job은 계획 중에 자동으로 이를 보고, 질문과 관련이 있으면 읽습니다. 모델이나 코드를 변경할 필요가 없습니다.

Job 실행 중

Agent가 Job을 만든 후에도 현재 채팅은 계속 사용할 수 있습니다. Agent와 계속 대화할 수 있고, Console → Background Agent Jobs를 열어 계획, 진행 상황, 모델 사용, 현재 상태를 확인할 수 있습니다.

Job이 결정을 필요로 하면 원래 대화에서 질문합니다. 계속 진행할 수 있도록 거기서 답하세요. waiting_on_user는 Job이 사용자의 답을 기다리고 있다는 뜻입니다. 실패가 아닙니다. 원래 대화에서 언제든지 자료를 추가하거나 요구 사항을 수정할 수도 있습니다. 메인 Agent가 그것을 Job으로 전달합니다.

결과 읽기

Job이 완료되면 메인 Agent는 결과를 전달하기 전에 보고서를 읽습니다. 보고서가 연구 목적을 해치는 gap이나 한계를 명시하면 Agent는 사용자에게 알립니다. 누락된 부분이 Agent가 보유한 정보나 사용자의 결정이라면, 목적에 부합하지 않는 보고서를 전달하는 대신 그것을 Job에 공급하고 Job이 계속하도록 합니다.

보고서에서 다음을 확인하세요. 소스가 결론을 지지하는지, 시간 범위가 올바른지, 사실이 추론과 분리되어 있는지, 보고서가 gap과 신뢰도를 정직하게 명시하는지. 보고서는 자족적이어야 합니다. 다른 파일 없이도 결론, 증거, 한계, 불확실성을 이해할 수 있어야 합니다. 증거 하나를 살펴보려면 Agent에게 Job workspace에서 관련 소스 노트를 읽으라고 요청하세요. ACH 분석 후에는 가설 행렬의 한 행에 대한 근거를 요청할 수도 있습니다.

더 많은 작업이 필요하면 Agent에게 같은 Job을 계속하라고 요청하세요. 전체 배경을 다시 설명할 필요가 없습니다. Job이 실패하거나 대기 상태에 머물면 세부 정보를 열어 상태나 오류를 읽으세요. 상태 의미, 취소, 런타임 설정은 Background Agent Jobs를 참조하세요.

참고 자료 및 Ankole과의 차이

Ankole Deep Research의 설계는 아래 공개 연구와 일치하며, 그 연구에서 아이디어도 얻었습니다. 각 논문은 자체 벤치마크에서 최신(state-of-the-art) 결과를 보고합니다. 우리의 질문은 다릅니다. 프라이빗 엔터프라이즈 배포 내부에서 이러한 원칙이 어떻게 성립하는가입니다.

방법은 파일이지 모델 학습이 아닙니다. CANA는 agentic 프레임워크입니다. MiroThinker는 agentic 중간 학습 단계로 각 단계의 신뢰성을 개선하고 검증을 모델 자체의 추론 과정에 내장합니다. 둘 다 모델과 함께 제공됩니다. 우리는 연구 방법을 workspace의 Playbook 파일로 작성하고, Job은 계획 중에 그것을 읽으며, Playbook은 기본 검토 프로토콜을 대체할 수 있습니다. 비용은 실행 품질이 모델이 지침을 얼마나 잘 따르는지에 달려 있다는 점입니다. 이점은 모델을 바꿔도 재학습이 필요 없고 프라이빗 배포가 자체 도메인을 위한 방법을 추가하거나 제거할 수 있다는 점입니다. 이것은 엔터프라이즈 연구의 일반적인 경우이며, 실제 차이는 일반 역량이 아니라 업계 방법과 내부 데이터 소스에 있습니다.

독립성은 자체 audit이 아니라 정보 통제에서 나옵니다. MiroThinker는 추론 중에 자체 추론 궤적을 audit합니다. 우리의 verifier는 대화 턴을 상속받지 않고 research-state.md도 받지 않으며, ACH에서는 먼저 sources/만으로 비교를 재구성해야 합니다. 그 후에야 행렬을 보고, 마지막으로 보고서를 봅니다. 이유는 직접적입니다. 자신의 궤적에 대한 audit은 그것을 만든 것과 같은 사전 확률을 지니며, 결론을 먼저 본 verifier는 결론을 앵커로 삼습니다.

영속성은 컨텍스트 창 밖에만 있는 것이 아니라 Job 수명 주기에 있습니다. FS-Researcher는 파일 시스템을 사용해 컨텍스트 창 너머에서 작업하며, 우리의 소스 노트와 workspace는 그것과 완전히 일치합니다. 차이는 우리의 workspace가 lease, 복구, 이후 메시지, 사용자 답변 대기 상태를 가진 Background Agent Job에 속한다는 점입니다. Job은 컨텍스트가 넘친 후에만이 아니라 Worker가 멈춘 후에도 계속됩니다. 또한 고정된 librarian-작가 분리를 사용하지 않습니다. 작성에는 완전한 분석 사슬이 필요하며, 단단한 분리는 보고서를 노트의 재진술로 만듭니다. 수집 측에서는 각 데이터 소스에 소유자 하나라는 소유권 규칙을 사용하고, verifier에 대해서만 격리를 강제합니다.

유추는 반증 가능한 전이 사슬을 제시해야 합니다. ADR은 모델이 근본 메커니즘 대신 표면 특징으로 유추를 찾는다는 것을 보여주고, 메커니즘 정렬과 교차 유추 확인을 제안합니다. 우리도 동의하며, 우리의 analogical-foresight Playbook은 이를 반드시 완전해야 하는 전이 사슬로 전환합니다. 두 가지 요구 사항을 추가합니다. 사례를 결합하기 전에 의존성을 확인합니다. 하나의 충격, 하나의 소스 서사, 하나의 측정 방법에서 온 반복은 확인처럼 보이지만 그렇지 않기 때문입니다. 그리고 모든 전이 주장은 대상 측 관찰을 제시해야 합니다. 그래야 유추가 보고서에서 설득력 있게 들리는 데 그치지 않고 나중에 틀렸음이 증명될 수 있습니다.

최종 지점은 벤치마크 점수가 아니라 사용자가 확인한 목적입니다. 논문들은 벤치마크에 대해 최적화합니다. 우리는 한 사람이 이 보고서로 무엇을 할지에 대해 최적화합니다. 성공 기준은 생성 전에 명확히 하고, 전달 전에 하나씩 audit하며, 각 gap은 그 결과를 명시합니다. gap이 목적을 무너뜨리면 메인 Agent가 공급할 수 있는 것을 공급하고 Job이 계속하도록 합니다. 수집도 같은 규칙을 따릅니다. 활성화된 Skill 데이터 소스가 공개 검색보다 먼저 오고, 어떤 Skill도 채울 수 없는 gap은 evidence gap으로 기록되기 때문입니다. 유용한 엔터프라이즈 보고서는 권위 있는 데이터를 사용했는지, 할 수 없었던 일을 정직하게 명시했는지에 달려 있으며, 둘 다 일반 벤치마크 점수표에는 나타나지 않습니다.

workspace의 Playbook, 검증 프로토콜, 연구 상태 파일, 전달 audit은 AgentBull Ankole 팀이 설계하고 구현했습니다.