recursive-decomposition

recursive-decomposition 스킬 개요

recursive-decomposition 스킬은 큰 작업, 여러 파일을 오가는 작업, 여러 단계에 걸친 작업을 더 작은 단위로 나눠 각각 독립적으로 처리한 뒤, 결과를 다시 합쳐 해결하도록 돕습니다. 하나의 프롬프트로는 너무 얕거나 너무 불안정해질 때, 특히 Workflow Automation, 코드베이스 전반 리뷰, 여러 문서에서 정보를 추출하는 recursive-decomposition 작업에 가장 유용합니다.

이 스킬이 필요한 경우

recursive-decomposition 스킬은 단순히 “질문에 답하기”보다 “방대한 자료를 신뢰성 있게 분석하기”가 목적일 때 사용합니다. 예를 들어 많은 파일을 훑기, 코드베이스 전체의 패턴 비교하기, 여러 문서에서 구조화된 사실 추출하기, 분산된 소스에서 통합 보고서 만들기 같은 상황에 잘 맞습니다.

일반 프롬프트와 다른 점

일반 프롬프트는 모델이 한 번에 모든 것을 떠안게 합니다. 반면 이 스킬은 점진적 공개 방식을 따르도록 유도합니다. 먼저 검색 범위를 좁히고, 그다음 관련된 부분으로 재귀적으로 들어가고, 마지막에 합치는 방식입니다. 컨텍스트가 흐려지거나, 파일을 놓치거나, 집계가 들쑥날쑥해져서 품질이 떨어질 수 있는 상황에서 이 차이가 특히 큽니다.

가장 잘 맞는 사용 사례

recursive-decomposition 스킬은 파일이 10개 이상이거나, 토큰이 50k 이상이거나, 빠른 요약보다 체계적인 커버리지가 더 중요한 작업에 특히 잘 맞습니다. 반대로 범위가 좁고 국소적인 질문처럼 직접 처리하는 편이 더 싸고 빠른 경우에는 효율이 떨어집니다.

recursive-decomposition 스킬 사용법

설치하고 활성화하기

recursive-decomposition install을 사용할 때는 이 스킬을 Claude Code 또는 skills-enabled 워크플로에 추가한 다음, 작업이 단일 패스로 감당하기 어려운 게 분명할 때 호출하세요. 저장소의 SKILL.md에는 references/ 아래의 참고 자료가 연결되어 있는데, 실제 판단 기준은 그곳에 있습니다.

올바른 입력부터 시작하기

스킬에 목표, 범위 경계, 출력 형식을 함께 주세요. 좋은 입력 예시는 “src/api, src/services, src/utils 전반의 오류 처리 방식을 분석해서, 패턴·공백·권장사항 표로 반환해줘”입니다. 나쁜 입력 예시는 “이 repo를 검토해줘”처럼 너무 넓고 अस्पष्ट한 요청입니다.

먼저 읽어야 할 파일

recursive-decomposition를 사용할 때는 먼저 SKILL.md를 읽고, 이어서 references/cost-analysis.md, references/codebase-analysis.md, references/document-aggregation.md, references/rlm-strategies.md를 확인하세요. 이 파일들은 언제 재귀적으로 들어가야 하는지, 작업을 어떻게 분할할지, 구조를 잃지 않고 결과를 어떻게 합칠지를 보여줍니다.

더 좋은 결과를 만드는 워크플로

순서는 다음이 가장 좋습니다. 범위를 정의하고, 후보 파일이나 문서를 식별한 뒤, 강하게 필터링하고, 남은 항목을 묶어 배치로 처리하고, 병렬 하위 작업을 실행한 다음, 하나의 스키마로 결과를 합치세요. recursive-decomposition 가이드는 무엇을 제외해야 하는지, 무엇을 증거로 볼 것인지, 최종 출력은 어떤 구조여야 하는지를 분명히 적을수록 효과가 좋아집니다.

recursive-decomposition 스킬 FAQ

recursive-decomposition은 언제 써야 하나요?

파일이 많거나 문서가 많거나 토큰 예산이 큰데, 속도보다 완전성이 더 중요할 때 사용하세요. 작업이 국소적이고 범위가 좁거나 이미 잘 정의되어 있다면, 보통은 직접 처리로 충분합니다.

recursive-decomposition은 코드베이스에만 쓰는 건가요?

아닙니다. 같은 방식은 코드베이스뿐 아니라 연구 노트, PRD, 긴 보고서, 기타 문서 묶음에도 잘 맞습니다. 핵심 조건은 필터링, 분할, 집계의 이점을 얻을 수 있어야 한다는 점입니다.

가장 흔한 실패 요인은 무엇인가요?

가장 흔한 실패는 범위가 불충분하게 정의된 작업에 recursive-decomposition을 쓰는 것입니다. 대상 집합, 출력 형식, 수용 기준을 정해두지 않으면 스킬은 재귀적으로는 효율적으로 돌아가도 결과는 여전히 초점이 흐릴 수 있습니다.

이 스킬은 초보자도 쓰기 쉬운가요?

네, 구체적인 목표와 범위 경계를 설명할 수 있다면 그렇습니다. 초보자는 열린 탐색보다 갭 분석, 인벤토리 작성, 비교 같은 단일 산출물을 요청할 때 보통 가장 좋은 결과를 얻습니다.

recursive-decomposition 스킬 개선 방법

스킬에 더 좁은 검색 틀을 주기

recursive-decomposition를 가장 잘 쓰는 방법은 처음부터 경계가 있는 질문을 주는 것입니다. “repository를 검토해줘” 대신 “src/api와 src/services에서 모든 오류 처리 패턴을 찾아 불일치를 기록하고, 모듈별로 요약해줘”처럼 요청하세요. 프레임을 좁히면 잡음이 줄고, 재귀 처리에 드는 오버헤드가 충분히 가치 있는 작업이 됩니다.

추출 스키마를 제공하기

구조화된 출력을 원한다면 각 항목에 무엇이 들어가야 하는지 명시하세요. 예를 들어 file, pattern, severity, evidence, recommendation처럼 적어두면 됩니다. 이렇게 하면 병렬로 나온 하위 결과들이 제각각 서술되지 않고 서로 비교 가능한 형태로 유지됩니다.

임계값과 제외 항목을 분명히 하기

저장소의 판단 로직은 토큰 수, 파일 수, 그리고 지연 시간보다 품질이 더 중요한지 여부를 중시합니다. 제약 조건을 알고 있다면 그대로 말하세요. 예: “tests는 제외”, “archived docs는 무시”, or