먼저 결론: V5 실행 계층은 멈추고, V6는 검증을 통과해야 시작할 수 있다

제안된 방향은 명확하다. V5의 실행 계층을 더 보수하기보다 동결하고, 분석 방법과 과거 기록은 보존한다. V6는 상위 조정기 하나, Cline 실행 프레임워크 하나, 외부 검증, 제한적인 텍스트 경험 공유로 단순화한다.

다만 이는 아직 설계안이다. Cline이 조정기에 필요한 실행 이벤트를 안정적으로 제공하는지, 개발자와 리뷰어를 실질적으로 분리할 수 있는지, 외부 게이트가 실패 시 제출을 막는지, 접속이 끊긴 뒤 VPS에서 실제 다음 단계가 실행되는지는 확인되지 않았다. 따라서 지금 V6가 준비됐다고 선언할 수는 없다.

이번 검토에서는 계획서나 코드를 수정하거나 테스트·실행·설치를 진행하지 않았다. 아래 내용은 확인된 과거 기록과 설계 제안, 아직 증거가 부족한 항목을 구분해 정리한 것이다.

V5의 문제는 ‘코드가 길다’는 것만이 아니다

현재 자료에서 확인된 bmad_control_store.py는 315행이다. SQL 데이터베이스가 아니라 파일에 기록을 덧붙이는 저장 모듈이다. 과거에 1,728행이었다는 주장과 해당 버전의 근거는 이번 검토에서 확인되지 않았다.

이 모듈은 디렉터리와 파일 권한, 잠금, 요청 버전, 기록 연속성, 용량 한도, 저장 후 재확인 등을 다룬다. 안전장치 자체가 잘못이라는 뜻은 아니다. 문제는 이 기록 장치가 사람의 결정을 남기는 데 집중하면서도, 그 결정을 인증하거나 실행 권한으로 바꾸고 실제 작업을 시작·진행시키지는 않는다는 점이다. 기록이 정교해도 작업 완료 경로가 입증되는 것은 아니다.

또한 모듈의 코드 길이만으로 모델 입력이 커졌다고 단정할 수 없다. 코드가 반복해서 모델 문맥에 포함됐다는 증거가 있어야 실제 문맥 부담을 주장할 수 있다. 잠금 역시 비차단 방식으로 충돌 시 작업을 거부하는 형태이므로, 실제 대기 고리가 확인되지 않은 상태에서 ‘데드락이 발생했다’고 말할 수는 없다.

실행기 구성에도 부담이 있었다. V5 백엔드는 스킬과 확장, MCP, 프롬프트 템플릿, 컨텍스트 파일을 비활성화하고 도구를 제한했다. 그 상태에서 BMAD 스킬을 사용하려면 주변 계층이 내용을 다시 펼치고 실행 의존성과 버전 대응을 관리해야 한다. BMAD가 완전히 작동 불능이었다는 뜻은 아니지만, 실행기가 제공할 수 있는 스킬 로딩을 외부에서 떠안게 되는 구조다.

231건의 테스트 통과가 증명한 것과 증명하지 않은 것

과거 계획에는 사용자가 확인한 전용 단위 테스트 231건의 통과 기록이 있다. 다만 이번 검토에서 재실행한 결과는 아니다. 같은 계획에는 실제 백엔드 실행, 독립 인증, 클라이언트 종료 후 새 단계 수행, 원격 종단 간 흐름이 아직 검증되지 않았다는 내용도 담겨 있다.

이 기록은 테스트가 무의미했다는 뜻이 아니다. 잠금·버전·예산·경로 같은 개별 동작의 테스트가 통과해도, 실제 CLI가 스킬을 불러오고 모델이 작업을 끝내며 리뷰·제출·복구까지 이어지는 제품 흐름을 입증하지는 못한다는 뜻이다. 시뮬레이션에서 연결 불가를 재현하는 것과, IDE를 닫은 뒤 VPS에서 새 작업 단계가 실제로 시작되는 것도 서로 다른 검증이다.

따라서 과거 테스트는 역사적 자산으로 남기되 V6의 통과 신호로 재사용하지 않는 편이 타당하다. 분석 규칙과 의사결정 기록은 보존하고, V5 실행 계층은 동결하되 완료되지 않은 일을 완료로 표시해서는 안 된다.

V6 제안: 각 구성 요소에 단 하나의 역할만 부여한다

구성 요소	맡길 역할	넘지 말아야 할 경계
bmad-loop	Story 선택, 실행 단계 조정, 검증·재시도 예산, 상태와 제출 관리	별도의 바깥쪽 반복기나 두 번째 조정기를 만들지 않는다.
Cline CLI	지정된 작업 공간에서 개발 또는 리뷰 세션을 한 번 수행	자체적으로 다른 계획·스케줄·팀 조정 계층을 추가하지 않는다.
BMAD-METHOD	역할과 기획·개발·검토 워크플로 제공	스킬을 사설 복사본으로 만들거나 모든 역할을 매번 불러오지 않는다.
solo-jev-gate	후보 변경의 의미상 범위와 실패 유형 평가	코드를 고치거나 다음 Story를 고르지 않는다.
경험 파일	다음 작업에 유용한, 근거와 적용 범위가 제한된 교훈 보관	승인·권한·필수 테스트를 바꾸지 않는다.

bmad-loop는 그대로 쓰되, 어댑터를 지어내지 않는다

조정기의 역할은 모델이 아니라 프로그램이 Story 선택, 재시도 한도, 필수 게이트, 완료 여부를 결정하도록 하는 것이다. 코드를 작성하고 검토하는 일에는 여전히 모델 세션이 쓰인다.

문서상 일반 흐름은 개발, 검증, 독립 리뷰, 재검증, 제출이다. 다만 기본 설정의 독립 리뷰는 모든 Story에서 무조건 실행되는 형태가 아니며, 일부 검토 예산 종료 경로가 제출을 허용할 수 있다. Story 단위 토큰 한도도 강제 중단이 아니라 경고 성격일 수 있다. V6에서 필수로 삼을 규칙은 상위 조정기의 기존 접점에서 보완해야지, 별도의 선거·재시도·복구·제출 상태 머신을 복제해선 안 된다.

현재 가장 큰 기술적 공백은 Cline과 bmad-loop의 연결이다. 확인된 기본 CLI 목록에는 Cline이 없고, 일반 어댑터 방식은 수명주기 훅을 요구하지만 문서에 제시된 훅 형식에 Cline이 포함되지 않는다. 문서에 이벤트 대응표를 써 넣는 것만으로 적응이 완료되는 것은 아니다.

실제 작업을 시작하기 전에는 새 세션 생성, 시작·완료 이벤트의 세션 식별, 취소 뒤 프로세스 종료, 완료와 일반 메시지의 구분을 실험해야 한다. 사용량 정보가 제공되지 않으면 예산을 강제하고 있다고 표시해서도 안 된다. 이 계약을 충족하지 못하면 공식 지원이나 검증된 접점을 확보할 때까지 멈춰야 한다.

Cline은 개발자와 리뷰어용 프로필 두 개로 운용한다

설계상 개발 프로필과 리뷰 프로필은 서로 다른 설정 및 세션을 쓰되, 별개의 자율 조정기가 되어서는 안 된다. 개발은 승인된 Story 작업 공간에 쓰기 권한을 갖고, 리뷰는 후보 변경과 승인 기준, 실제 테스트 증거만 읽는 구상이다.

제안에는 개발 모델로 Sonnet 5.5, 리뷰 모델로 GPT-6-Sol을 적어두었지만, 이것이 제공자의 실제 모델 식별자라는 점은 확인되지 않았다. 정확한 모델 ID, 제공 방식, 인증 정보, 비용 한도는 비밀이 아닌 설정과 실제 호출 기록으로 검증해야 한다. 또한 프로필 분리가 설정상 존재한다는 사실만으로 리뷰의 독립성이 입증되지는 않는다.

BMAD 스킬은 복사보다 원본의 필요 부분을 불러오는 쪽으로

BMAD는 역할과 절차를 제공하지만, 모든 스킬을 매 작업에 한꺼번에 넣을 필요는 없다. 제안된 역할 구분은 기술 아키텍처, 승인된 Story 구현, 티켓 트리 관리처럼 필요한 업무에 맞춰 호출하는 것이다. 프로젝트 초기화와 렌더링 의존성이 갖춰졌는지도 확인해야 한다. 스킬을 연결하는 것만으로 상위 워크플로가 실행되는 것은 아니다.

자료에 열거된 31개 디렉터리를 모두 ‘실행 가능한 스킬’로 간주해서도 안 된다. 그중에는 모듈 기록용 디렉터리도 포함된다고 적혀 있다. 원본 스킬은 가능한 한 읽기 전용으로 유지하고, 매 요청에는 필요한 역할과 관련된 지침만 제공한다.

Jev는 코딩 에이전트가 아니라 구조화된 판단 도구다

Jev는 상태와 형식이 정해진 질문을 받아 구조화된 답을 돌려주는 시스템으로 소개돼 있다. 코드를 작성하거나 대화하는 코딩 에이전트는 아니다. 따라서 외부 검증에서 의미상 범위 평가나 실패 분류에 활용할 수는 있지만, 모든 코드의 적합성을 혼자 보증한다고 볼 수는 없다.12

권장되는 설계는 먼저 프로그램이 후보 파일 전체와 승인 경로를 결정론적으로 확인하고, 경로 위반은 즉시 실패시키는 것이다. 그다음 Jev가 제한된 변경 사항과 승인 기준, 테스트 증거를 바탕으로 의미상 범위 위반이나 실패 원인을 평가할 수 있다. 결과가 불명확하거나 서비스에 접근할 수 없으면 통과가 아니라 보류로 처리해야 한다.

이 검사는 코드가 작성된 뒤 이뤄지므로 이미 발생한 외부 동작을 되돌리지는 못한다. 작업 공간 격리와 계정 권한, 운영 자격 증명 제한은 별도로 필요하다. Jev의 요청 형식과 응답 검증, 실제 데이터 전송 범위도 구현 전에 확인해야 한다.

제안된 Story 흐름은 어디까지나 아직 설계다

예를 들어 반복 주문 제출을 막는 Story를 진행한다고 하자. 먼저 사람이 승인한 티켓과 허용된 파일 범위, 완료 조건을 확정하고, bmad-loop가 격리된 작업 공간을 만든다. 새 Cline 개발 세션은 해당 티켓과 필요한 경험·코드만 읽고 구현한다. 세션 종료는 작업 종료일 뿐, Story 통과를 의미하지 않는다.

그 뒤에는 변경 파일 전체 확인, 관련 테스트, 외부 범위 평가가 이뤄져야 한다. 결과와 후보 내용의 식별 정보를 고정한 다음, 개발 대화나 개발자의 자기평가를 보지 않는 새 리뷰 세션이 후보와 증거를 살핀다. 리뷰가 거부·불명확·시간 초과라면 제출하지 않는다. 리뷰 이후 코드가 달라지면 기존 승인은 무효다.

교훈은 실제 반례에서 확인된 경우에만 적용 범위와 함께 경험 파일에 남긴다. 최종 변경, 필수 테스트, 외부 게이트, 독립 리뷰가 모두 같은 후보를 가리키는지 확인한 뒤 상위 조정기가 제출한다. 다음 Story는 새 문맥에서 시작하고, 이미 제출된 관련 경험만 읽는다. 이 흐름 전체는 아직 실제로 입증되지 않았다.

특히 ‘리뷰 워크플로가 끝났다’는 이벤트만으로 리뷰 통과를 판단하면 안 된다. 실제 판정과 후보 연결을 확인하는 제출 전 검사가 있어야 하고, 그 검사는 실패할 때 제출을 막아야 한다. 제안된 플러그인과 검사 파일은 아직 만들어지지 않은 설계 자산이다.

원격 실행에서 반드시 시험할 실패 경로

클라이언트나 SSH 연결이 끊긴 뒤에도 VPS에서 새 개발·검증·리뷰 단계가 시작되는지 확인해야 한다. 단지 tmux 세션이 남아 있는 것만으로는 원격 연속 실행을 입증하지 못한다. 반대로 VPS가 완전히 오프라인이면 원격 모델이나 외부 게이트 호출을 계속할 수 있다고 가정하지 말고, 시간 제한 안에 멈춰 증거와 작업 상태를 보존해야 한다.

테스트 실패, 리뷰 거부·시간 초과, 후보 변경, 경험 파일 기록 실패, 제출·병합·티켓 갱신 중단은 각각 실패로 드러나야 한다. 중단 요청 뒤에는 요청을 보냈다는 사실뿐 아니라 실행 세션과 도구 프로세스가 실제로 종료됐는지도 확인해야 한다. 이런 동작을 V5의 별도 복구 상태 머신으로 다시 구현하지 않고, 조정기의 원래 상태 관리에 맞춰야 한다.

V5를 동결하고 V6를 시작할 때의 원칙

• 기존 계획의 식별자와 미완료 항목, 과거 테스트 기록을 보존한다.
• V5 실행 계층은 중단 상태로 표시하되 미완료 항목을 완료로 바꾸지 않는다.
• V6는 새 계획과 새 아키텍처 결정으로 시작하고, 과거 실행기·저장소·조정 결정을 자동 승계하지 않는다.
• 설치와 모델 호출, 파일 수정, 제출은 별도 승인이 필요한 작업이다. 이번 검토에서는 실행하지 않았다.
• 데이터베이스를 새로 만들지 않는다는 설계 원칙과, Cline 자체 내부 저장 방식까지 금지 대상인지 확인하는 일은 구분한다. 후자는 아직 검증되지 않았다.

최소한의 MVP 통과 기준은 실제 승인된 Story 하나에서 개발, 필수 테스트, Jev 게이트, 독립 리뷰, 원래 조정기를 통한 제출까지 증거를 남기는 것이다. 여기에 클라이언트 연결 해제 뒤의 새 실행 단계, 실패 시 제출 차단, 다음 새 세션에서 경험을 읽는 동작도 확인해야 한다. 한 Story의 성공만으로 연속적인 경험 공유까지 입증할 수 없다면 두 번째 작은 Story가 필요하다.

결론: 더 많은 제어 계층보다 먼저, Cline 연결과 제출 차단을 입증해야 한다

V5에 국소 테스트를 더 보태는 것만으로 원격 제품의 미검증 경로를 해결할 수는 없다. 실행 계층을 동결하고 분석 방법과 역사적 증거를 남기는 방향은 타당하다. V6도 조정기 하나와 실행 프레임워크 하나를 중심으로 단순하게 유지하는 편이 맞다.

하지만 현재 가장 중요한 일은 새 제어기를 만드는 것이 아니다. Cline이 bmad-loop의 실제 실행 계약을 충족하는지, 독립 리뷰가 제출 전 실패 폐쇄 게이트로 연결되는지, 클라이언트 연결이 끊긴 뒤 VPS에서 새로운 작업 단계가 실제로 수행되는지를 먼저 입증해야 한다. 이 경로가 확인되지 않으면 V6도 시작 준비가 끝난 것이 아니다.

먼저 결론: V5 실행 계층은 멈추고, V6는 검증을 통과해야 시작할 수 있다

제안된 방향은 명확하다. V5의 실행 계층을 더 보수하기보다 동결하고, 분석 방법과 과거 기록은 보존한다. V6는 상위 조정기 하나, Cline 실행 프레임워크 하나, 외부 검증, 제한적인 텍스트 경험 공유로 단순화한다.

다만 이는 아직 설계안이다. Cline이 조정기에 필요한 실행 이벤트를 안정적으로 제공하는지, 개발자와 리뷰어를 실질적으로 분리할 수 있는지, 외부 게이트가 실패 시 제출을 막는지, 접속이 끊긴 뒤 VPS에서 실제 다음 단계가 실행되는지는 확인되지 않았다. 따라서 지금 V6가 준비됐다고 선언할 수는 없다.

이번 검토에서는 계획서나 코드를 수정하거나 테스트·실행·설치를 진행하지 않았다. 아래 내용은 확인된 과거 기록과 설계 제안, 아직 증거가 부족한 항목을 구분해 정리한 것이다.

V5의 문제는 ‘코드가 길다’는 것만이 아니다

현재 자료에서 확인된 bmad_control_store.py는 315행이다. SQL 데이터베이스가 아니라 파일에 기록을 덧붙이는 저장 모듈이다. 과거에 1,728행이었다는 주장과 해당 버전의 근거는 이번 검토에서 확인되지 않았다.

이 모듈은 디렉터리와 파일 권한, 잠금, 요청 버전, 기록 연속성, 용량 한도, 저장 후 재확인 등을 다룬다. 안전장치 자체가 잘못이라는 뜻은 아니다. 문제는 이 기록 장치가 사람의 결정을 남기는 데 집중하면서도, 그 결정을 인증하거나 실행 권한으로 바꾸고 실제 작업을 시작·진행시키지는 않는다는 점이다. 기록이 정교해도 작업 완료 경로가 입증되는 것은 아니다.

또한 모듈의 코드 길이만으로 모델 입력이 커졌다고 단정할 수 없다. 코드가 반복해서 모델 문맥에 포함됐다는 증거가 있어야 실제 문맥 부담을 주장할 수 있다. 잠금 역시 비차단 방식으로 충돌 시 작업을 거부하는 형태이므로, 실제 대기 고리가 확인되지 않은 상태에서 ‘데드락이 발생했다’고 말할 수는 없다.

실행기 구성에도 부담이 있었다. V5 백엔드는 스킬과 확장, MCP, 프롬프트 템플릿, 컨텍스트 파일을 비활성화하고 도구를 제한했다. 그 상태에서 BMAD 스킬을 사용하려면 주변 계층이 내용을 다시 펼치고 실행 의존성과 버전 대응을 관리해야 한다. BMAD가 완전히 작동 불능이었다는 뜻은 아니지만, 실행기가 제공할 수 있는 스킬 로딩을 외부에서 떠안게 되는 구조다.

231건의 테스트 통과가 증명한 것과 증명하지 않은 것

과거 계획에는 사용자가 확인한 전용 단위 테스트 231건의 통과 기록이 있다. 다만 이번 검토에서 재실행한 결과는 아니다. 같은 계획에는 실제 백엔드 실행, 독립 인증, 클라이언트 종료 후 새 단계 수행, 원격 종단 간 흐름이 아직 검증되지 않았다는 내용도 담겨 있다.

이 기록은 테스트가 무의미했다는 뜻이 아니다. 잠금·버전·예산·경로 같은 개별 동작의 테스트가 통과해도, 실제 CLI가 스킬을 불러오고 모델이 작업을 끝내며 리뷰·제출·복구까지 이어지는 제품 흐름을 입증하지는 못한다는 뜻이다. 시뮬레이션에서 연결 불가를 재현하는 것과, IDE를 닫은 뒤 VPS에서 새 작업 단계가 실제로 시작되는 것도 서로 다른 검증이다.

따라서 과거 테스트는 역사적 자산으로 남기되 V6의 통과 신호로 재사용하지 않는 편이 타당하다. 분석 규칙과 의사결정 기록은 보존하고, V5 실행 계층은 동결하되 완료되지 않은 일을 완료로 표시해서는 안 된다.

V6 제안: 각 구성 요소에 단 하나의 역할만 부여한다

구성 요소	맡길 역할	넘지 말아야 할 경계
bmad-loop	Story 선택, 실행 단계 조정, 검증·재시도 예산, 상태와 제출 관리	별도의 바깥쪽 반복기나 두 번째 조정기를 만들지 않는다.
Cline CLI	지정된 작업 공간에서 개발 또는 리뷰 세션을 한 번 수행	자체적으로 다른 계획·스케줄·팀 조정 계층을 추가하지 않는다.
BMAD-METHOD	역할과 기획·개발·검토 워크플로 제공	스킬을 사설 복사본으로 만들거나 모든 역할을 매번 불러오지 않는다.
solo-jev-gate	후보 변경의 의미상 범위와 실패 유형 평가	코드를 고치거나 다음 Story를 고르지 않는다.
경험 파일	다음 작업에 유용한, 근거와 적용 범위가 제한된 교훈 보관	승인·권한·필수 테스트를 바꾸지 않는다.

bmad-loop는 그대로 쓰되, 어댑터를 지어내지 않는다

조정기의 역할은 모델이 아니라 프로그램이 Story 선택, 재시도 한도, 필수 게이트, 완료 여부를 결정하도록 하는 것이다. 코드를 작성하고 검토하는 일에는 여전히 모델 세션이 쓰인다.

문서상 일반 흐름은 개발, 검증, 독립 리뷰, 재검증, 제출이다. 다만 기본 설정의 독립 리뷰는 모든 Story에서 무조건 실행되는 형태가 아니며, 일부 검토 예산 종료 경로가 제출을 허용할 수 있다. Story 단위 토큰 한도도 강제 중단이 아니라 경고 성격일 수 있다. V6에서 필수로 삼을 규칙은 상위 조정기의 기존 접점에서 보완해야지, 별도의 선거·재시도·복구·제출 상태 머신을 복제해선 안 된다.

현재 가장 큰 기술적 공백은 Cline과 bmad-loop의 연결이다. 확인된 기본 CLI 목록에는 Cline이 없고, 일반 어댑터 방식은 수명주기 훅을 요구하지만 문서에 제시된 훅 형식에 Cline이 포함되지 않는다. 문서에 이벤트 대응표를 써 넣는 것만으로 적응이 완료되는 것은 아니다.

실제 작업을 시작하기 전에는 새 세션 생성, 시작·완료 이벤트의 세션 식별, 취소 뒤 프로세스 종료, 완료와 일반 메시지의 구분을 실험해야 한다. 사용량 정보가 제공되지 않으면 예산을 강제하고 있다고 표시해서도 안 된다. 이 계약을 충족하지 못하면 공식 지원이나 검증된 접점을 확보할 때까지 멈춰야 한다.

Cline은 개발자와 리뷰어용 프로필 두 개로 운용한다

설계상 개발 프로필과 리뷰 프로필은 서로 다른 설정 및 세션을 쓰되, 별개의 자율 조정기가 되어서는 안 된다. 개발은 승인된 Story 작업 공간에 쓰기 권한을 갖고, 리뷰는 후보 변경과 승인 기준, 실제 테스트 증거만 읽는 구상이다.

제안에는 개발 모델로 Sonnet 5.5, 리뷰 모델로 GPT-6-Sol을 적어두었지만, 이것이 제공자의 실제 모델 식별자라는 점은 확인되지 않았다. 정확한 모델 ID, 제공 방식, 인증 정보, 비용 한도는 비밀이 아닌 설정과 실제 호출 기록으로 검증해야 한다. 또한 프로필 분리가 설정상 존재한다는 사실만으로 리뷰의 독립성이 입증되지는 않는다.

BMAD 스킬은 복사보다 원본의 필요 부분을 불러오는 쪽으로

BMAD는 역할과 절차를 제공하지만, 모든 스킬을 매 작업에 한꺼번에 넣을 필요는 없다. 제안된 역할 구분은 기술 아키텍처, 승인된 Story 구현, 티켓 트리 관리처럼 필요한 업무에 맞춰 호출하는 것이다. 프로젝트 초기화와 렌더링 의존성이 갖춰졌는지도 확인해야 한다. 스킬을 연결하는 것만으로 상위 워크플로가 실행되는 것은 아니다.

자료에 열거된 31개 디렉터리를 모두 ‘실행 가능한 스킬’로 간주해서도 안 된다. 그중에는 모듈 기록용 디렉터리도 포함된다고 적혀 있다. 원본 스킬은 가능한 한 읽기 전용으로 유지하고, 매 요청에는 필요한 역할과 관련된 지침만 제공한다.

Jev는 코딩 에이전트가 아니라 구조화된 판단 도구다

Jev는 상태와 형식이 정해진 질문을 받아 구조화된 답을 돌려주는 시스템으로 소개돼 있다. 코드를 작성하거나 대화하는 코딩 에이전트는 아니다. 따라서 외부 검증에서 의미상 범위 평가나 실패 분류에 활용할 수는 있지만, 모든 코드의 적합성을 혼자 보증한다고 볼 수는 없다.12

권장되는 설계는 먼저 프로그램이 후보 파일 전체와 승인 경로를 결정론적으로 확인하고, 경로 위반은 즉시 실패시키는 것이다. 그다음 Jev가 제한된 변경 사항과 승인 기준, 테스트 증거를 바탕으로 의미상 범위 위반이나 실패 원인을 평가할 수 있다. 결과가 불명확하거나 서비스에 접근할 수 없으면 통과가 아니라 보류로 처리해야 한다.

이 검사는 코드가 작성된 뒤 이뤄지므로 이미 발생한 외부 동작을 되돌리지는 못한다. 작업 공간 격리와 계정 권한, 운영 자격 증명 제한은 별도로 필요하다. Jev의 요청 형식과 응답 검증, 실제 데이터 전송 범위도 구현 전에 확인해야 한다.

제안된 Story 흐름은 어디까지나 아직 설계다

예를 들어 반복 주문 제출을 막는 Story를 진행한다고 하자. 먼저 사람이 승인한 티켓과 허용된 파일 범위, 완료 조건을 확정하고, bmad-loop가 격리된 작업 공간을 만든다. 새 Cline 개발 세션은 해당 티켓과 필요한 경험·코드만 읽고 구현한다. 세션 종료는 작업 종료일 뿐, Story 통과를 의미하지 않는다.

그 뒤에는 변경 파일 전체 확인, 관련 테스트, 외부 범위 평가가 이뤄져야 한다. 결과와 후보 내용의 식별 정보를 고정한 다음, 개발 대화나 개발자의 자기평가를 보지 않는 새 리뷰 세션이 후보와 증거를 살핀다. 리뷰가 거부·불명확·시간 초과라면 제출하지 않는다. 리뷰 이후 코드가 달라지면 기존 승인은 무효다.

교훈은 실제 반례에서 확인된 경우에만 적용 범위와 함께 경험 파일에 남긴다. 최종 변경, 필수 테스트, 외부 게이트, 독립 리뷰가 모두 같은 후보를 가리키는지 확인한 뒤 상위 조정기가 제출한다. 다음 Story는 새 문맥에서 시작하고, 이미 제출된 관련 경험만 읽는다. 이 흐름 전체는 아직 실제로 입증되지 않았다.

특히 ‘리뷰 워크플로가 끝났다’는 이벤트만으로 리뷰 통과를 판단하면 안 된다. 실제 판정과 후보 연결을 확인하는 제출 전 검사가 있어야 하고, 그 검사는 실패할 때 제출을 막아야 한다. 제안된 플러그인과 검사 파일은 아직 만들어지지 않은 설계 자산이다.

원격 실행에서 반드시 시험할 실패 경로

클라이언트나 SSH 연결이 끊긴 뒤에도 VPS에서 새 개발·검증·리뷰 단계가 시작되는지 확인해야 한다. 단지 tmux 세션이 남아 있는 것만으로는 원격 연속 실행을 입증하지 못한다. 반대로 VPS가 완전히 오프라인이면 원격 모델이나 외부 게이트 호출을 계속할 수 있다고 가정하지 말고, 시간 제한 안에 멈춰 증거와 작업 상태를 보존해야 한다.

테스트 실패, 리뷰 거부·시간 초과, 후보 변경, 경험 파일 기록 실패, 제출·병합·티켓 갱신 중단은 각각 실패로 드러나야 한다. 중단 요청 뒤에는 요청을 보냈다는 사실뿐 아니라 실행 세션과 도구 프로세스가 실제로 종료됐는지도 확인해야 한다. 이런 동작을 V5의 별도 복구 상태 머신으로 다시 구현하지 않고, 조정기의 원래 상태 관리에 맞춰야 한다.

V5를 동결하고 V6를 시작할 때의 원칙

• 기존 계획의 식별자와 미완료 항목, 과거 테스트 기록을 보존한다.
• V5 실행 계층은 중단 상태로 표시하되 미완료 항목을 완료로 바꾸지 않는다.
• V6는 새 계획과 새 아키텍처 결정으로 시작하고, 과거 실행기·저장소·조정 결정을 자동 승계하지 않는다.
• 설치와 모델 호출, 파일 수정, 제출은 별도 승인이 필요한 작업이다. 이번 검토에서는 실행하지 않았다.
• 데이터베이스를 새로 만들지 않는다는 설계 원칙과, Cline 자체 내부 저장 방식까지 금지 대상인지 확인하는 일은 구분한다. 후자는 아직 검증되지 않았다.

최소한의 MVP 통과 기준은 실제 승인된 Story 하나에서 개발, 필수 테스트, Jev 게이트, 독립 리뷰, 원래 조정기를 통한 제출까지 증거를 남기는 것이다. 여기에 클라이언트 연결 해제 뒤의 새 실행 단계, 실패 시 제출 차단, 다음 새 세션에서 경험을 읽는 동작도 확인해야 한다. 한 Story의 성공만으로 연속적인 경험 공유까지 입증할 수 없다면 두 번째 작은 Story가 필요하다.

결론: 더 많은 제어 계층보다 먼저, Cline 연결과 제출 차단을 입증해야 한다

V5에 국소 테스트를 더 보태는 것만으로 원격 제품의 미검증 경로를 해결할 수는 없다. 실행 계층을 동결하고 분석 방법과 역사적 증거를 남기는 방향은 타당하다. V6도 조정기 하나와 실행 프레임워크 하나를 중심으로 단순하게 유지하는 편이 맞다.

하지만 현재 가장 중요한 일은 새 제어기를 만드는 것이 아니다. Cline이 bmad-loop의 실제 실행 계약을 충족하는지, 독립 리뷰가 제출 전 실패 폐쇄 게이트로 연결되는지, 클라이언트 연결이 끊긴 뒤 VPS에서 새로운 작업 단계가 실제로 수행되는지를 먼저 입증해야 한다. 이 경로가 확인되지 않으면 V6도 시작 준비가 끝난 것이 아니다.