한눈에 보기

저장소 외부에 표시할 버전은 v4.3, v4.4처럼 두 부분 형식으로 단순화하고, 내부 제품군 표기인 V4는 유지하는 방안이 적절하다. 다만 이번 점검만으로 현재 작업 트리를 “깨끗하고 완전한 v4.3 배포본”이라고 판단할 수는 없다. 이번 작업은 읽기 전용 검토였으며, 저장소 갱신이나 파일 수정, 삭제, 테스트 실행, 배포는 진행하지 않았다.

핵심은 버전 번호 자체보다 출처와 배포 경로를 확인하는 일이다. 설치 이후의 파일 참조, CI 검증, 호스트별 규칙 로딩, 프로젝트 수준의 규칙 적용이 아직 하나의 흐름으로 닫히지 않았다.

버전 표기를 간결하게 하되, 출처 확인은 생략하지 않는다

현재 README는 v4.2.0, 엔지니어링 진입점은 V4.2로 표기돼 있다. 제품군 매핑도 V4만 인식하며, 소규모 버전의 단일 기준은 확인되지 않았다. 원격의 v4.3 태그와 현재 로컬 커밋이 연결된다는 증거도 확보되지 않았다. 따라서 배지나 문구만 바꿔 버전이 정렬됐다고 말할 수는 없다.

권장안은 외부 표기를 v4.3, v4.4 같은 형식으로 통일하고, README와 설치 안내, CI가 참조하는 버전의 출처를 하나로 두는 것이다. 내부 디렉터리 이름을 바꾸거나 과거 기록을 다시 쓰고, 복잡한 버전 체계를 추가할 필요는 없다. 커밋 식별자와 파일 요약값은 사용자 자산 보호와 배포 출처 추적에 계속 쓸 수 있다.

정리 대상으로는 .versions/v4.0.0/의 구버전 캐시가 확인됐다. 다만 실제 배포나 링크가 참조하는지 먼저 확인해야 한다. 반면 verification/legacy-bmad-output/은 기존 ADR에서 참조하고 있으며, _bmad-solo-source/legacy-skills/는 상위 기술의 출처를 살피는 데 중요한 자료다. 둘을 단순한 불필요 캐시로 취급해 바로 삭제해서는 안 된다. 현재 태그 캐시 진입점은 구형 태그 명명 방식의 캐시를 자동 재사용하지 않도록 막고 있다.

설치와 CI: 기본 보호는 있지만 버전 규칙은 아직 미적용

설치 흐름에는 유지해야 할 안전장치가 있다. 설치 진입점은 작업 트리가 변경된 상태에서 덮어쓰기를 거부하고, 배포 진입점은 빠른 전달 업데이트를 요구한 뒤 새 스크립트로 넘긴다. 관리형 배포 조정기도 파일을 쓰기 전에 충돌을 검사한다. 버전 표기를 간소화한다고 이 보호를 없앨 이유는 없다.

다만 설치 진입점은 현재 V4 호환 인자만 받으며, 호스트 선택이나 읽기 전용 사전 점검, 모드 대상 인자를 전달하지 않는다. 의존성 안내는 README에 있지만 설치 과정에서 통합된 의존성 검사를 하지는 않는다. 기존 설치의 업데이트에는 설정된 원격 저장소가 쓰이지만, 확인한 진입점에서는 그 주소가 의도한 저장소인지 검증하지 않는다.

CI도 두 부분 버전 원칙을 검사하지 않는다. 워크플로는 주 브랜치 푸시와 병합 요청을 대상으로 하고, 릴리스 태그 트리거는 설정돼 있지 않다. 플러그인 검사는 구조와 이름을 확인하지만 버전 형식을 검사하지 않는다. 태그 검사는 주 버전 단서만 확인하며, 관련 테스트는 세 부분 버전과 비버전 태그도 허용한다.

최소한 새 릴리스 태그가 v4.숫자 형식인지, 단일 버전 출처와 일치하는지, 현재 표시 문구도 같은지 검사할 필요가 있다. 과거 태그나 제3자 의존성 버전까지 일괄 변경할 필요는 없다. 또 스킬 패키지 검증기는 존재하지만 CI에서 호출되지 않는다. 저장소 안의 참조뿐 아니라 설치 후 경로도 점검하도록 보완해야 한다.

상위 스킬은 실시간 연결이 아니라 로컬 개작본

현재 활성 경로는 이 제품군의 절차를 가리킨다. 배포 소스 매핑은 제품군 디렉터리를 수집하지만 외부의 과거 스킬 디렉터리는 수집하지 않는다. 확인한 활성 코드에서도 상위 스킬을 실시간으로 검색하거나 갱신하는 흐름은 발견되지 않았다.

따라서 상위 스킬은 현재 진입점의 직접 실행 의존성이 아니다. 동시에 상위 출처가 바뀌어도 이미 추출·개작된 로컬 절차가 자동 갱신되는 것은 아니므로, 유지보수 과정에서 내용이 어긋날 위험이 있다. 과거 스킬을 다시 연결할 때도 파일 하나를 복사하는 것으로 충분하다고 보면 안 된다. 예컨대 과거 도움말 스킬은 설정과 디렉터리 목록, 파서에 의존하고, 과거 빌드 스킬은 렌더링 프로그램을 필요로 한다.

권장 방향은 안정적인 로컬 분석·엔지니어링 진입점은 유지하되, 승인된 상위 스킬을 기능 매핑에 따라 골라 연결하는 것이다. 출처 커밋과 필수 부속 파일도 기록해야 한다. 갱신 때는 추가·삭제·의존성 변화를 감지하고 관련 검증을 통과한 뒤 교체한다. 진행 중인 작업이 계속 바뀌는 상위 브랜치를 직접 읽도록 만드는 방식은 피하는 편이 안전하다. 업데이트 감지와 자동 교체도 별개로 다뤄야 한다. 설치·업데이트 시 확인하거나 정기 알림을 제공할 수 있지만, 기본값으로 백그라운드 감시기를 실행할 필요는 없다.

Cline·Roo·Gemini: 파일 존재와 실제 지원은 다르다

Cline은 CLI와 IDE 플러그인을 제공하며, 애플리케이션 전반에 적용되는 전역 설정과 프로젝트별 설정을 구분한다.41 하지만 이 저장소의 Cline 라우터 템플릿은 비활성 상태다. 배포 회귀 검사는 템플릿을 비활성 복사본으로 유지하고, 실제 Cline 규칙 진입점에 넣지 않도록 요구한다. 따라서 현재 Cline용 배포가 완료됐다고 볼 수 없다.

공통 방법론을 기반으로 CLI와 플러그인에 맞는 얇은 어댑터를 각각 생성하는 것이 권장된다. 분석·실행 역할은 Cline의 Plan/Act 흐름에 맞추고, 사용자가 별도 스킬 명령을 외우거나 Roo 모드 설정을 그대로 가져오지 않도록 해야 한다. 템플릿의 방법론 경로는 저장소 루트를 기준으로 하므로, 다른 프로젝트에 배포할 때는 실제 설치 위치에 맞게 다시 해석해야 한다.

Roo의 배포 매핑은 전역 규칙과 일부 모드를 포함한다. 하지만 파일이 디스크에 있다는 사실만으로 Roo가 이를 읽고 있다고 단정할 수는 없다. 두 사용자 지정 모드에 MCP 권한이 선언돼 있지 않은 반면, 검증기는 권한 그룹을 고정해 검사한다. 증류 도구를 연결하려면 안내 문구뿐 아니라 설정과 검증 코드를 함께 살펴야 한다.

Gemini는 현재 플러그인 및 규칙 디렉터리의 물리적 미러링 형태다. 이는 Gemini CLI의 네이티브 확장 설치가 검증됐다는 뜻은 아니다. Gemini CLI 확장은 스킬과 MCP 등을 묶을 수 있고, 설치 시 원본의 복사본을 만들며 별도 업데이트 절차를 사용한다.119 따라서 기존 미러링 경로와 네이티브 확장 경로를 구분해 지원 범위를 밝혀야 한다.

설치 후 경로에서도 문제가 보인다. 전역 핵심 규칙은 상대 경로로 스킬을 참조하지만, 배포 매핑에서는 규칙 사본과 스킬이 서로 다른 위치에 놓인다. 파일 기준 상대 경로로 해석하면 배포된 스킬에 닿지 않는다.

프로젝트 규칙도 새 방식과 예전 방식이 함께 남아 있다. 프로젝트 진입점은 단일 포커스 포인터를 사용하는데, 배포되는 핵심 규칙은 이전 활동 계획을 찾는다. 분석 모드의 편집 범위도 새 프로젝트 문서 영역을 포함하지 않는다. 전역에는 재사용 가능한 방법론과 호스트 어댑터만 두고, 프로젝트 수준에는 해당 프로젝트의 진입점·도메인 규칙·결정·작업 정보를 두는 경계를 명확히 해야 한다. 현재 소스 수집기가 저장소의 프로젝트 자료 전체를 배포하지 않는 점은 유지할 만한 경계다.

MCP는 선택 기능으로 연결하고, 의존하는 단계만 멈춘다

권장 구조는 독립 실행되는 로컬 MCP 서비스가 승인된 프로젝트를 읽고 후보 자료를 만드는 방식이다. 최종 자료는 승인된 문서 발행 경로를 통해 프로젝트에 반영한다. 방법론 배포에는 연결 어댑터와 기능 요건을 담되, 서비스 전체 소스를 규칙 패키지에 합치지 않는 편이 낫다.

기능이 실제로 맞는지 먼저 확인해야 한다. 기존 브라운필드 증류 절차는 버전, 도구 선언, 언어 범위, 사용 주체, 분할 처리 능력 확인을 요구한다. 이번 점검에서는 서비스의 현재 소스를 읽지 않았으므로, 특정 인터페이스나 자동 등록이 이미 작동한다고 보장할 수 없다.

일상적인 분석과 코딩에서는 MCP를 보강 기능으로 두고, 증류 엔진이 명시적으로 필요한 초기화 단계에서만 필수 선행 조건으로 취급하는 것이 합리적이다. 서비스가 없으면 의존하는 단계만 멈춰야지 전체 방법론을 사용할 수 없게 해서는 안 된다. 일반 파일 읽기를 엔진 검증으로 간주해서도 안 된다. 오프라인 스캔, 출처 인증, 선택적인 모델 기반 표현 기능은 구분해야 하며, 모델을 사용할 수 없을 때는 구조적 근거와 미확인 상태를 남겨야 한다. 이는 절차의 오프라인 경계와도 맞는다.

GitHub와 SSH 터널을 기본 운영 구조로 삼는 것은 권장되지 않는다. 소스 공개 위치와 서비스 실행 위치를 분리하고, 원격 서비스는 필요할 때만 선택하는 편이 낫다. 원격 실행을 택한다면 데이터 전송, 인증, 프로젝트 격리, 연결 중단, 모델 서비스 의존성을 별도로 다뤄야 한다. 터널만으로 이런 요건이 해결되지는 않는다. 자동 연결도 설치 시 승인된 등록, 사용 시 기능 확인, 작업 시작 시 서비스 버전 고정으로 나누고, 실험적 기능을 자동 다운로드·실행하거나 권한을 넓히지 않도록 해야 한다.

권장 작업 순서

1. v4.3의 실제 출처를 확인하고, 문서·설치 안내·CI가 공유할 단일 버전 기준을 마련한다. 캐시는 배포나 링크의 참조 여부를 확인한 뒤 정리한다.
2. 설치 후 파일 참조, 새 프로젝트 진입점과 규칙 소비자, 문서 편집 권한 범위를 먼저 맞춘다. 그다음 CI에 버전 형식과 스킬 패키지 전체 검사를 추가한다.
3. Cline, Roo, Gemini를 각각 따로 적용하고, 전역 로딩·프로젝트별 덮어쓰기·허용 및 거부 동작·업데이트·제3자 자산 보호를 호스트별로 검증한다.
4. 마지막으로 로컬 증류 서비스를 연결하고 정상 작동, 서비스 부재, 호환되지 않는 버전, 모델 미사용, 중단 상황을 확인한다.

이 항목들은 다음 단계의 작업 제안이지 완료된 구현이 아니다. v4.3은 버전 문구를 고친 시점이 아니라, 출처·배포 경로·호스트 로딩·프로젝트 규칙 소비자를 필요한 수준으로 검증한 뒤에야 납품 가능한 상태로 판단할 수 있다.

한눈에 보기

저장소 외부에 표시할 버전은 v4.3, v4.4처럼 두 부분 형식으로 단순화하고, 내부 제품군 표기인 V4는 유지하는 방안이 적절하다. 다만 이번 점검만으로 현재 작업 트리를 “깨끗하고 완전한 v4.3 배포본”이라고 판단할 수는 없다. 이번 작업은 읽기 전용 검토였으며, 저장소 갱신이나 파일 수정, 삭제, 테스트 실행, 배포는 진행하지 않았다.

핵심은 버전 번호 자체보다 출처와 배포 경로를 확인하는 일이다. 설치 이후의 파일 참조, CI 검증, 호스트별 규칙 로딩, 프로젝트 수준의 규칙 적용이 아직 하나의 흐름으로 닫히지 않았다.

버전 표기를 간결하게 하되, 출처 확인은 생략하지 않는다

현재 README는 v4.2.0, 엔지니어링 진입점은 V4.2로 표기돼 있다. 제품군 매핑도 V4만 인식하며, 소규모 버전의 단일 기준은 확인되지 않았다. 원격의 v4.3 태그와 현재 로컬 커밋이 연결된다는 증거도 확보되지 않았다. 따라서 배지나 문구만 바꿔 버전이 정렬됐다고 말할 수는 없다.

권장안은 외부 표기를 v4.3, v4.4 같은 형식으로 통일하고, README와 설치 안내, CI가 참조하는 버전의 출처를 하나로 두는 것이다. 내부 디렉터리 이름을 바꾸거나 과거 기록을 다시 쓰고, 복잡한 버전 체계를 추가할 필요는 없다. 커밋 식별자와 파일 요약값은 사용자 자산 보호와 배포 출처 추적에 계속 쓸 수 있다.

정리 대상으로는 .versions/v4.0.0/의 구버전 캐시가 확인됐다. 다만 실제 배포나 링크가 참조하는지 먼저 확인해야 한다. 반면 verification/legacy-bmad-output/은 기존 ADR에서 참조하고 있으며, _bmad-solo-source/legacy-skills/는 상위 기술의 출처를 살피는 데 중요한 자료다. 둘을 단순한 불필요 캐시로 취급해 바로 삭제해서는 안 된다. 현재 태그 캐시 진입점은 구형 태그 명명 방식의 캐시를 자동 재사용하지 않도록 막고 있다.

설치와 CI: 기본 보호는 있지만 버전 규칙은 아직 미적용

설치 흐름에는 유지해야 할 안전장치가 있다. 설치 진입점은 작업 트리가 변경된 상태에서 덮어쓰기를 거부하고, 배포 진입점은 빠른 전달 업데이트를 요구한 뒤 새 스크립트로 넘긴다. 관리형 배포 조정기도 파일을 쓰기 전에 충돌을 검사한다. 버전 표기를 간소화한다고 이 보호를 없앨 이유는 없다.

다만 설치 진입점은 현재 V4 호환 인자만 받으며, 호스트 선택이나 읽기 전용 사전 점검, 모드 대상 인자를 전달하지 않는다. 의존성 안내는 README에 있지만 설치 과정에서 통합된 의존성 검사를 하지는 않는다. 기존 설치의 업데이트에는 설정된 원격 저장소가 쓰이지만, 확인한 진입점에서는 그 주소가 의도한 저장소인지 검증하지 않는다.

CI도 두 부분 버전 원칙을 검사하지 않는다. 워크플로는 주 브랜치 푸시와 병합 요청을 대상으로 하고, 릴리스 태그 트리거는 설정돼 있지 않다. 플러그인 검사는 구조와 이름을 확인하지만 버전 형식을 검사하지 않는다. 태그 검사는 주 버전 단서만 확인하며, 관련 테스트는 세 부분 버전과 비버전 태그도 허용한다.

최소한 새 릴리스 태그가 v4.숫자 형식인지, 단일 버전 출처와 일치하는지, 현재 표시 문구도 같은지 검사할 필요가 있다. 과거 태그나 제3자 의존성 버전까지 일괄 변경할 필요는 없다. 또 스킬 패키지 검증기는 존재하지만 CI에서 호출되지 않는다. 저장소 안의 참조뿐 아니라 설치 후 경로도 점검하도록 보완해야 한다.

상위 스킬은 실시간 연결이 아니라 로컬 개작본

현재 활성 경로는 이 제품군의 절차를 가리킨다. 배포 소스 매핑은 제품군 디렉터리를 수집하지만 외부의 과거 스킬 디렉터리는 수집하지 않는다. 확인한 활성 코드에서도 상위 스킬을 실시간으로 검색하거나 갱신하는 흐름은 발견되지 않았다.

따라서 상위 스킬은 현재 진입점의 직접 실행 의존성이 아니다. 동시에 상위 출처가 바뀌어도 이미 추출·개작된 로컬 절차가 자동 갱신되는 것은 아니므로, 유지보수 과정에서 내용이 어긋날 위험이 있다. 과거 스킬을 다시 연결할 때도 파일 하나를 복사하는 것으로 충분하다고 보면 안 된다. 예컨대 과거 도움말 스킬은 설정과 디렉터리 목록, 파서에 의존하고, 과거 빌드 스킬은 렌더링 프로그램을 필요로 한다.

권장 방향은 안정적인 로컬 분석·엔지니어링 진입점은 유지하되, 승인된 상위 스킬을 기능 매핑에 따라 골라 연결하는 것이다. 출처 커밋과 필수 부속 파일도 기록해야 한다. 갱신 때는 추가·삭제·의존성 변화를 감지하고 관련 검증을 통과한 뒤 교체한다. 진행 중인 작업이 계속 바뀌는 상위 브랜치를 직접 읽도록 만드는 방식은 피하는 편이 안전하다. 업데이트 감지와 자동 교체도 별개로 다뤄야 한다. 설치·업데이트 시 확인하거나 정기 알림을 제공할 수 있지만, 기본값으로 백그라운드 감시기를 실행할 필요는 없다.

Cline·Roo·Gemini: 파일 존재와 실제 지원은 다르다

Cline은 CLI와 IDE 플러그인을 제공하며, 애플리케이션 전반에 적용되는 전역 설정과 프로젝트별 설정을 구분한다.41 하지만 이 저장소의 Cline 라우터 템플릿은 비활성 상태다. 배포 회귀 검사는 템플릿을 비활성 복사본으로 유지하고, 실제 Cline 규칙 진입점에 넣지 않도록 요구한다. 따라서 현재 Cline용 배포가 완료됐다고 볼 수 없다.

공통 방법론을 기반으로 CLI와 플러그인에 맞는 얇은 어댑터를 각각 생성하는 것이 권장된다. 분석·실행 역할은 Cline의 Plan/Act 흐름에 맞추고, 사용자가 별도 스킬 명령을 외우거나 Roo 모드 설정을 그대로 가져오지 않도록 해야 한다. 템플릿의 방법론 경로는 저장소 루트를 기준으로 하므로, 다른 프로젝트에 배포할 때는 실제 설치 위치에 맞게 다시 해석해야 한다.

Roo의 배포 매핑은 전역 규칙과 일부 모드를 포함한다. 하지만 파일이 디스크에 있다는 사실만으로 Roo가 이를 읽고 있다고 단정할 수는 없다. 두 사용자 지정 모드에 MCP 권한이 선언돼 있지 않은 반면, 검증기는 권한 그룹을 고정해 검사한다. 증류 도구를 연결하려면 안내 문구뿐 아니라 설정과 검증 코드를 함께 살펴야 한다.

Gemini는 현재 플러그인 및 규칙 디렉터리의 물리적 미러링 형태다. 이는 Gemini CLI의 네이티브 확장 설치가 검증됐다는 뜻은 아니다. Gemini CLI 확장은 스킬과 MCP 등을 묶을 수 있고, 설치 시 원본의 복사본을 만들며 별도 업데이트 절차를 사용한다.119 따라서 기존 미러링 경로와 네이티브 확장 경로를 구분해 지원 범위를 밝혀야 한다.

설치 후 경로에서도 문제가 보인다. 전역 핵심 규칙은 상대 경로로 스킬을 참조하지만, 배포 매핑에서는 규칙 사본과 스킬이 서로 다른 위치에 놓인다. 파일 기준 상대 경로로 해석하면 배포된 스킬에 닿지 않는다.

프로젝트 규칙도 새 방식과 예전 방식이 함께 남아 있다. 프로젝트 진입점은 단일 포커스 포인터를 사용하는데, 배포되는 핵심 규칙은 이전 활동 계획을 찾는다. 분석 모드의 편집 범위도 새 프로젝트 문서 영역을 포함하지 않는다. 전역에는 재사용 가능한 방법론과 호스트 어댑터만 두고, 프로젝트 수준에는 해당 프로젝트의 진입점·도메인 규칙·결정·작업 정보를 두는 경계를 명확히 해야 한다. 현재 소스 수집기가 저장소의 프로젝트 자료 전체를 배포하지 않는 점은 유지할 만한 경계다.

MCP는 선택 기능으로 연결하고, 의존하는 단계만 멈춘다

권장 구조는 독립 실행되는 로컬 MCP 서비스가 승인된 프로젝트를 읽고 후보 자료를 만드는 방식이다. 최종 자료는 승인된 문서 발행 경로를 통해 프로젝트에 반영한다. 방법론 배포에는 연결 어댑터와 기능 요건을 담되, 서비스 전체 소스를 규칙 패키지에 합치지 않는 편이 낫다.

기능이 실제로 맞는지 먼저 확인해야 한다. 기존 브라운필드 증류 절차는 버전, 도구 선언, 언어 범위, 사용 주체, 분할 처리 능력 확인을 요구한다. 이번 점검에서는 서비스의 현재 소스를 읽지 않았으므로, 특정 인터페이스나 자동 등록이 이미 작동한다고 보장할 수 없다.

일상적인 분석과 코딩에서는 MCP를 보강 기능으로 두고, 증류 엔진이 명시적으로 필요한 초기화 단계에서만 필수 선행 조건으로 취급하는 것이 합리적이다. 서비스가 없으면 의존하는 단계만 멈춰야지 전체 방법론을 사용할 수 없게 해서는 안 된다. 일반 파일 읽기를 엔진 검증으로 간주해서도 안 된다. 오프라인 스캔, 출처 인증, 선택적인 모델 기반 표현 기능은 구분해야 하며, 모델을 사용할 수 없을 때는 구조적 근거와 미확인 상태를 남겨야 한다. 이는 절차의 오프라인 경계와도 맞는다.

GitHub와 SSH 터널을 기본 운영 구조로 삼는 것은 권장되지 않는다. 소스 공개 위치와 서비스 실행 위치를 분리하고, 원격 서비스는 필요할 때만 선택하는 편이 낫다. 원격 실행을 택한다면 데이터 전송, 인증, 프로젝트 격리, 연결 중단, 모델 서비스 의존성을 별도로 다뤄야 한다. 터널만으로 이런 요건이 해결되지는 않는다. 자동 연결도 설치 시 승인된 등록, 사용 시 기능 확인, 작업 시작 시 서비스 버전 고정으로 나누고, 실험적 기능을 자동 다운로드·실행하거나 권한을 넓히지 않도록 해야 한다.

권장 작업 순서

1. v4.3의 실제 출처를 확인하고, 문서·설치 안내·CI가 공유할 단일 버전 기준을 마련한다. 캐시는 배포나 링크의 참조 여부를 확인한 뒤 정리한다.
2. 설치 후 파일 참조, 새 프로젝트 진입점과 규칙 소비자, 문서 편집 권한 범위를 먼저 맞춘다. 그다음 CI에 버전 형식과 스킬 패키지 전체 검사를 추가한다.
3. Cline, Roo, Gemini를 각각 따로 적용하고, 전역 로딩·프로젝트별 덮어쓰기·허용 및 거부 동작·업데이트·제3자 자산 보호를 호스트별로 검증한다.
4. 마지막으로 로컬 증류 서비스를 연결하고 정상 작동, 서비스 부재, 호환되지 않는 버전, 모델 미사용, 중단 상황을 확인한다.

이 항목들은 다음 단계의 작업 제안이지 완료된 구현이 아니다. v4.3은 버전 문구를 고친 시점이 아니라, 출처·배포 경로·호스트 로딩·프로젝트 규칙 소비자를 필요한 수준으로 검증한 뒤에야 납품 가능한 상태로 판단할 수 있다.