법률 연구 (Legal Research)은(는) 무엇을 하나요?

심층 리서치 실행에 가깝지만, 법률에 특화되어 있으며 기본적으로 효율적이도록 조정되었습니다. 무료/공개 웹 법률 소스만을 대상으로 검색 파이프라인을 실행합니다(Westlaw/Lexis 사용 안 함). 단계별 형태, 상한선, 모델 맵은 호출 옆에 있는 4단계에 있습니다. 설계는 토큰 사용을 낮게 유지합니다 — 순진한 팬아웃에서 지배적인 비용은 프론티어 모델이 가져온 모든 페이지를 읽는 것이기 때문입니다 — 동시에 인용 환각을 방지합니다. 높은 중요도의 작업(철저함이 속도보다 우선시되어야 하는 경우)에는 deep (예: "심층 분석 실행")을 추가하세요.

소스 (공개 웹)

판례: CourtListener, Justia, Google Scholar 판례, Cornell LII, Caselaw Access Project, 공식 법원 사이트. 학술 문헌: SSRN, Google Scholar, 로스쿨 디지털 커먼즈 리포지토리, HeinOnline 오픈 콘텐츠, 저널 사이트, 교수진 페이지. 학술 문헌 모드는 또한 Zotero MCP 서버를 통해 사용자 자신의 Zotero 라이브러리를 검색합니다(사용 불가 시 자동으로 건너뜀).

실행 방법

1. 요청 분석

사용자 프롬프트에서 다음을 추출하세요:

question — 법률 질문 (필수).
mode — caselaw, scholarship 또는 both. 기본값 both. 문맥을 통해 유추 ("법원은 어떻게 판결하는가" → caselaw; "문헌 현황 / 학술적 논쟁" → scholarship).
outputStyle — practitioner (제시된 질문 / 간략 답변 / IRAC) 또는 academic (서론 / 개관 / 분석 / 각주). 기본값: caselaw의 경우 practitioner, scholarship 및 both의 경우 academic. 명시적 재정의를 존중합니다.
jurisdiction, asOfDate (기본값 오늘), 그리고 모든 notes (사실, 입장, 범위).

2. 진정으로 차단되는 경우에만 명확히 하기

질문이 조사하기에 너무 모호한 경우, 시작하기 전에 2~3개의 표적 질문을 하세요. 판례의 경우 jurisdiction과 절차적 입장이 가장 중요합니다. 학술 문헌의 경우 특정 논제 또는 하위 질문과 모든 시간 범위가 중요합니다. 지나치게 묻지 말고 — 합리적인 기본값을 선택하고 이를 명시하세요.

3. 사전 점검: 웹 도구가 허용되는지 확인 (실행 전에 수행)

연구 하위 에이전트는 WebSearch와 WebFetch를 많이 사용합니다. 이러한 도구가 미리 허용되지 않으면 각 호출은 대화형 권한 프롬프트를 발생시킵니다 — 중단된 프롬프트는 연구 에이전트를 실행 중간에 죽일 수 있습니다 (실제 실패 모드: 이전 실행에서 4개의 벡터 중 2개를 잃었습니다).

Workflow를 호출하기 전에 실행을 자체 포함시키세요:

~/.claude/settings.json을 읽고 permissions.allow에 "WebFetch"와 "WebSearch"가 있는지 확인하세요.
둘 중 하나라도 없으면 추가하세요(기존 allow 배열에 병합 — 절대 교체하지 마세요. permissions.allow 경로가 없으면 생성하세요). 둘 다 이미 있으면 아무것도 하지 마세요.
사용자에게 이에 대해 묻지 마세요 — 스킬의 일상적인 설정입니다. (파일이 관리/읽기 전용이고 편집할 수 없는 경우, 사용자에게 각 가져오기마다 프롬프트가 표시될 것이며 수락해야 한다고 알리거나 /permissions를 통해 규칙을 추가하라고 알리세요.)
선택 사항이지만 살펴볼 가치가 있음: 결정적 판례 인용 확인에는 CourtListener API 토큰이 필요합니다. 파일을 찾지 말고 테스트하세요 — 다음을 실행하세요: python3 ${CLAUDE_PLUGIN_ROOT}/skills/legal-research/check_cite.py "347 U.S. 483". 종료 코드 0과 함께 "found": true가 반환되면 토큰이 작동 중이며 보고할 사항이 없음을 의미합니다. check_cite.py는 COURTLISTENER_API_TOKEN, 그 다음 COURTLISTENER_TOKEN, 그 다음 파일 ~/.config/courtlistener/token에서 토큰을 확인합니다 — 이 순서대로, 환경 변수 경로(일반적으로 ~/.claude/settings.json의 env 블록에 설정)가 정상적인 설치 방법이므로 파일이 없다고 해서 아무것도 증명되지 않습니다. 프로브가 실제로 실패하면 실행을 차단하지 마세요 — 확인 에이전트는 웹 확인으로 대체합니다 — 하지만 한 번만 언급하세요. (토큰 페이지: https://www.courtlistener.com/profile/api-token/)

4. 워크플로우 실행

Workflow 도구를 번들 스크립트와 구문 분석된 인수와 함께 호출하세요:

Workflow({
  scriptPath: "${CLAUDE_PLUGIN_ROOT}/skills/legal-research/legal-research.workflow.js",
  args: {
    skillsDir: "${CLAUDE_PLUGIN_ROOT}/skills",      // 번들된 도우미 스크립트가 있는 위치
    question: "<법률 질문>",
    mode: "caselaw" | "scholarship" | "both",
    outputStyle: "practitioner" | "academic",
    jurisdiction: "<예: 연방 / 9th Cir. / 미주리 / 연방 대법원>",
    asOfDate: "<YYYY-MM-DD 또는 'today'>",
    notes: "<사실, 입장, 범위, 사용자가 강조한 모든 것>",
    deep: false,  // 사용자가 심층/철저/고위험 통과를 요청한 경우에만 true
    projectDir: "<현재 작업 디렉토리 — 로컬 코퍼스 조사 벡터 활성화;
                  현재 작업 디렉토리가 질문과 명백히 관련이 없는 경우에만 생략>"
  }
})

기본적으로 lean함: ~4개의 검색 전용 조사 벡터(plus 학술 모드에서 Zotero 라이브러리 스윕 및 projectDir의 로컬 코퍼스 스윕 — 이전 메모와 다운로드된 소스는 지도와 단서일 뿐, 인용 가능한 권위는 아님). 또한 범위는 질문을 분류합니다(교리적 vs. 학술적; 역사적 여부) — 이는 Draft에 주입되는 분석적 방법 브리프를 선택합니다(종합 규율, 판결/딕타 위생, 교리사 질문에 대한 시대 포괄 분류법) 및 역사적 질문의 경우 검색 벡터를 시간 계층에 걸쳐 분산시켜 적용 범위가 현대 정전에 집중되지 않도록 합니다. 직접 답변 적용범위 셀 (scholarship/both, 2026-07-16 추가, Codex 비교 실행이 실제 질문에 대해 64개 에이전트 Claude 실행을 이긴 후): 범위는 최소한 하나의 벡터를 질문의 명명된 현상을 자체 객체로 취급하는 학술 문헌에 할애해야 합니다 — 전문가가 기대하는 전문 제목 용어로 구성되고 가장 적합한 작품의 인용 추적을 포함 — 현상이 단순히 속하는 인접 문헌과 구별됩니다. 조사는 이러한 중심 후보를 표시합니다. 트리아지는 이를 광범위한 인접 조사보다 우선하여 전체 읽기로 승격시킵니다. 이로 인해 수정되는 실패: 다섯 개의 인접 문헌(초법적 발언, 기피, 유명인)을 매핑하는 동안 현상에 대해 정면으로 다루는 소수의 작업(예: 사법 자서전 연구, "대법관의 책 거래" 윤리 섹션)을 놓치고, 그 코퍼스 격차를 "직접적인 학술 문헌이 없다"는 결과로 오인하는 것. 부재/격차 주장은 이제 중앙 소스 누락 감사에 의해 제한됩니다(학술적 방법 브리프에 있음): 현상 대상 검색과 양방향 인용 추적이 실제로 실행되지 않았다면 "X를 직접적으로 다루는 학술 문헌은 없다"고 말할 수 없음 — 그렇지 않으면 주장은 "검토된 소스 내에서"로 범위가 제한되고 실행되지 않은 검색이 플래그 지정됩니다. 팬아웃은 적용범위 셀을 중심으로 구성되며, 에이전트 상한은 할당량이 아닌 최대 한도입니다 — 중복되지 않는 레인은 많은 중복되는 일반 검색보다 낫습니다. 파이프라인: 조사 벡터 → 중복 제거 → 총 최대 8개의 고유한 전체 읽기 (벡터당이 아님; 리더는 포기하기 전에 오픈 액세스 미러(디지털 커먼즈, 작성자 페이지, CourtListener/LII)로 대체하고, PDF는 fetch_page.py라는 하드 크기 제한이 있는 페처를 통해 전달되며, 명제 및 인용문과 함께 입장/제한/별도의견/중요성을 추출) → 단일 세션 모델 초안(방법 브리프에 따라 안내) → 제한된 격차 메우기(최대 3개의 표적 검색과 한 번의 재시도 웨이브, 초안에서 누락된 권위를 플래그 지정하는 경우에만) → 청크 단위 인용 확인 (인용된 권위만, 에이전트당 8개; 판례 인용은 CourtListener의 인용 조회 API, check_cite.py를 통해 결정적으로 확인되며, cl_case_tools.py citing을 통한 체계적인 인용 의견 처리 스캔 — 관련성 순위가 매겨진 처리 언어 프로브로, 사건의 실제 인용 의견에 대해 생존 날짜와 함께, 이전의 한 번 검색 조회를 대체함; 이미 이 실행에서 연 소스는 존재 재확인을 건너뜀) → 가벼운 최종 편집. 선택되지 않은 후보와 각 읽은 소스 자체가 의존하는 권위는 헤지가 적용된 읽지 않은 단서로 초안에 전달되어, 범위는 넓게 유지되면서 가져오기는 적게 유지됩니다. 모든 실행은 지출 보호됩니다: 하드와이어된 소프트 상한(~250k 출력 토큰 lean, ~1M deep — 2026-07-15에 600k에서 증가, 심층 역사적 실행이 중간 래더에 묶여 43개 인용 중 35개가 확인되지 않은 후)은 명시적 +500k 예산과 동일한 우아한 성능 저하 사다리를 사용합니다 — 읽기 트림 → 격차 메우기 건너뛰기 → 하중 지지 인용만 확인 — 따라서 폭주하는 실행은 나선형으로 증가하는 대신 성능이 저하됩니다. 읽기, 격차 메우기 및 확인 에이전트는 모두 접근 제어 블록(같은 날짜에 추가됨) – 하드 시도 상한, WebSearch/WebFetch 전용, 브라우저 자동화, 라이브러리 프록시, SSO/로그인 흐름에 대한 명시적 금지 — 페이월 소스는 정직한 opened=false일 뿐, 계속 시도할 이유가 아닙니다. 모델: 검색 스니펫 조사에만 Haiku; 트리아지, 전체 읽기 및 확인에 Sonnet; Scope, Draft 및 Finalize는 세션 모델을 상속합니다(Fable이 켜져 있을 때 Fable). deep:true(또는 +800k 스타일 토큰 예산)는 최대 7개의 벡터로 확장하고, 읽기 상한을 16으로 높이며, 각 하중 지지 인용(최대 8개)에 대해 3표 적대적 반박 패스를 제공합니다(출처를 다시 열어 인용문을 그대로 확인). 워크플로우는 백그라운드에서 실행되며 완료 시 알림을 보냅니다.

5. 전달

워크플로우는 { memo, exitState, degradation, counts, ... }를 반환합니다.

제시하기 전에 exitState를 확인하세요. complete → 전달. complete_with_limits → 전달, 문서화된 격차를 표시(degradation 및 메모의 한계 섹션에 나열). budget_exhausted → 예산 가드가 실제 적용 범위를 줄였습니다(트리밍된 읽기, 건너뛴 격차 메우기, 확인되지 않은 인용 — 자세한 내용은 degradation 참조). 메모는 아직 전달 가능한 상태가 아닙니다. 입증된 구조 패턴(2026년 7월 1960년 이전 실행): 표적 읽기 및 확인 에이전트 패스를 시작하세요 — 범위가 지정되지 않은 각 영역당 하나씩, 가져와서 확인할 특정 판례/인용문을 제공하고 공식 리포터 텍스트 (CAP static.case.law / LOC usrep 스캔)에 대해 확인한 다음, 워크플로우의 확인된 핵심과 채우기 패스를 사용하여 직접 최종 메모를 작성하세요. 범위의 절반에 대해 "신뢰도: 불충분"이라고 말하는 메모를 격차를 채우거나 묻지 않고 사용자에게 전달하지 마세요. 구조 에이전트는 워크플로우 에이전트와 동일한 접근 규율이 필요합니다 (2026년 7월 학술 실행에서 얻은 교훈, 상한이 없는 구조 에이전트가 30분 이상 및 ~245k 토큰을 소비하여 페이월된 1962년 기사에 대해 브라우저 자동화로 확대된 경우): 모든 구조 프롬프트에 하드 시도 상한(~소스당 3회), WebSearch/WebFetch 전용, 브라우저 자동화/라이브러리 프록시/SSO 흐름에 대한 명시적 금지, 그리고 "페이월 상태 — 제가 도달한 가장 강력한 근거는 다음과 같습니다"는 완전히 수용 가능한 답변이라는 지침을 작성하세요. 구조 에이전트가 계속해서 막히면, SendMessage로 정리하고 보고하도록 지시하고 기다리지 마세요.
메모를 기본 전달물로 사용자에게 제시하세요.
하이퍼링크 (필수, 작성자 기준, 2026-08-29): 메모의 모든 뉴스 기사, 블로그 게시물 또는 기타 웹 소스는 클릭 가능한 링크로 작동하는 URL을 포함해야 합니다 — "(Politico)" 또는 "(Roll Call, July 14, 2026)"와 같은 매체 이름만으로 된 속성은 절대 안 됩니다. 워크플로우의 인용 블록은 에이전트 프롬프트에서 이를 강제합니다. 수동 편집, 구조 패스 및 모든 임시(비워크플로우) 연구 메모에도 동일한 규칙을 적용하고, 모든 구조/채우기 에이전트에게 인용하는 모든 출처의 URL을 반환하도록 지시하세요(URL이 없는 주장은 확인되지 않은 것입니다).
연구 메모 헤더 및 생산 바닥글 (필수, 작성자 기준 — ~/.claude/CLAUDE.md의 전역 규칙): 메모는 제목 바로 아래에 구조화된 헤더 블록(Topic: / Date: / By:)으로 시작합니다; Production details: 블록은 파일의 맨 끝에 위치합니다(모든 부록, 포함 "한계" 이후, --- 규칙으로 구분) — 절대 상단에 두지 마세요. Date는 메모가 전달/작성된 현지 날짜/시간입니다. By는 Claude-<오케스트레이션 세션 모델>(정확한 ID)입니다. Production details는 스킬 이름, 실제로 사용된 워크플로우 에이전트 모델(실행의 에이전트별 진행 항목에서 읽음 — 추측하지 마세요), 벽시계 시간, 그리고 완료 알림의 <usage> 블록에서 가져온 토큰 수(하위 에이전트 출력 토큰으로 표시; 오케스트레이터 오버헤드는 포함되지 않음)를 명명합니다. 워크플로우 후에 구조/채우기 패스가 실행된 경우 에이전트 수를 추가하고 기간이 워크플로우 실행만 다룬다는 점을 명시하세요.
확인 횟수를 표시하세요("N개 권위 확인됨, M개 확인되지 않음") — 사용자가 얼마나 신뢰할 수 있는지 알 수 있습니다. 그리고 메모의 "이 연구의 한계" 부록을 가리키세요(현재 각 권위의 확인 기준을 공개: 직접-전체-텍스트 / 권위-재생산 / 2차-확증 / 인용-전용).
결과는 또한 skeleton 을 전달합니다 — 초안이 작성된 인용 태그가 지정된 분석 개요(각 하중 지지 주장이 해당 결과에 태그 지정되고, 구멍은 GAP으로 표시됨). 기본적으로 제시하지 마세요. 사용자가 추론을 감사하려는 경우 제공하고, 메모를 직접 편집할 때 직접 사용하세요(골격 라인이 없는 주장은 성장하기 전에 권위 또는 헤지가 필요함).
저장을 제안하세요: 작업 디렉토리의 Markdown; 번들된 변환기를 통한 Word — python3 ${CLAUDE_PLUGIN_ROOT}/skills/legal-research/md2docx.py memo.md memo.docx "<제목>"; 또는 Google Drive를 통한 연결. 사용자가 처음에 .docx를 요청한 경우, 바로 생성하세요.
약하거나 확인되지 않은 모든 지점에 대한 후속 패스 또는 출력 스타일 전환을 제공하세요.

주장 보정 (v7)

인용 확인과 주장 보정은 분리된 오류 클래스를 포착합니다: 확인은 출처에 대한 허위 진술을 포착합니다; 보정은 사실로 확인된 결과를 지원되지 않는 일반화로 조립하는 것을 포착합니다. 파이프라인은 이제 둘 다 시행합니다 — Draft 프롬프트는 주장 강도 게이트를 전달합니다("첫 번째", "유일한", "압도적으로", "지워진"과 같은 빈도/우선순위/최종성 단어는 이를 지원하도록 설계된 검색이 필요하며, 그렇지 않으면 샘플 범위 언어가 사용됨), 독자는 각 소스의 입장(arguendo 및 비선례적 처분 포함)과 관련성(프로세스 전용 / 전제 가정 / 인접 교리)을 태그 지정하고, 역사적 실행은 선택 편향, 경계 날짜, 및 피해/제외 확인을 받으며, 심층 실행은 초안에 대한 전용 적대적 보정 패스를 추가합니다. 이들 사이에는 세 번째 오류 클래스가 있습니다:

... [truncated for translation]

요약 및 핵심 포인트

목적: 법률 연구 파이프라인을 자동화하여 무료 웹 소스만으로 판례 및 학술 문헌 조사를 수행합니다.
소스: CourtListener, Justia, Google Scholar, Cornell LII, SSRN 등 오픈 액세스 법률 데이터베이스.
효율성: 토큰 사용을 최적화하고 인용 환각을 방지하도록 설계되었습니다.
모드: caselaw(판례), scholarship(학술 문헌), both(모두).
출력: practitioner(실무자용) 또는 academic(학술용) 스타일의 메모.
확인: 결정적 인용 확인 및 주장 보정을 통해 정확성 보장.
예산 관리: 소프트 상한을 초과 시 우아한 성능 저하로 비용 통제.
전달: 모든 웹 출처에 하이퍼링크가 포함된 완전한 메모와 구조화된 헤더 및 생산 세부 정보를 제공합니다.

이 스킬은 법률 전문가 또는 학생이 심층적이고 신뢰할 수 있는 법률 연구를 효율적으로 수행할 수 있도록 돕습니다.

법률 연구 (Legal Research)