Solo-Engine V4 평가와 권고안: V4.1 Final

결론부터: V4는 채택할 만하지만, 그대로 운영 배포하기에는 과밀하다

V4는 방향이 좋습니다. 특히 도구·테스트·Git·파일 작업을 프롬프트만으로 수행한 것처럼 꾸미지 못하게 한 점, 코드 출력의 완결성과 실제 검증을 분리한 점, ADR을 단순 문서가 아닌 증거 기반 의사결정 산출물로 다룬 점은 중요한 개선입니다.

다만 최종 권고는 V4 원형 유지가 아니라 Solo-Engine v4.1 Final로의 정리입니다. 핵심은 기능을 더 쌓는 것이 아니라 다음 네 가지를 명확히 하는 데 있습니다.

1. Gem이 실제로 할 수 있는 일과 할 수 없는 일
2. 전달 완료와 엔지니어링 완료의 구분
3. 신규 프로젝트와 기존 프로젝트의 코드 전달 계약
4. 단일 Gem의 역할 분담과 실제 멀티 에이전트 실행의 구분

---

V4가 이미 잘 해결한 문제

1. ‘수행한 척’하는 도구 사용을 막았다

검색, Tavily 호출, 코드 실행, 컴파일, 테스트, 파일 쓰기, Git diff·commit, 배포는 현재 세션에 실제 도구가 노출된 경우에만 수행했다고 말할 수 있어야 합니다.

이 원칙은 매우 중요합니다. 실행 증거가 없다면 모델은 다음까지만 할 수 있습니다.

• 완전한 코드 생성
• 정적 검토
• 검증 명령 또는 검증 스크립트 제시
• 사용자 제공 로그의 해석

반면 ‘컴파일 오류 0건’, ‘테스트 전체 통과’, ‘프로덕션 배포 완료’ 같은 주장은 실제 실행 기록 없이는 허용하면 안 됩니다.

2. 분석과 구현을 분리했다

/ana-solo는 리서치·의사결정·결정 문서화에, /ana-bmad는 구현·검증·산출물 대조에 집중하는 구조입니다. 이 분리는 ‘분석 보고서가 곧 구현 승인’으로 오해되는 문제를 줄입니다.

특히 Decision Matrix(DM)가 임시 우선안을 만들고, Deep Recon(DR)이 그 우선안을 반박하려 시도하도록 한 설계는 좋습니다. 점수표가 불확실성을 지워버리지 못하게 하기 때문입니다.

3. 코드 전달과 검증을 분리했다

V4의 핵심 강점은 다음을 별개의 상태로 다룬 점입니다.

• DELIVERY_STATUS: 파일이 완전하게 전달됐는가
• VERIFICATION_STATUS: 실제 컴파일·빌드·테스트가 수행됐는가
• ENGINEERING_STATUS: 엔지니어링 완료라고 주장할 수 있는가

이 구분이 없으면 파일 일부만 출력한 뒤 ‘완료’로 표기하거나, 정적 검토만으로 ‘테스트 통과’라고 말하는 문제가 생깁니다.

4. BMAD의 역할 모델을 과장하지 않았다

BMAD 문서는 에이전트, 스킬, 워크플로, QA 테스트 생성 절차를 별도 실행 메커니즘으로 설명합니다.11014 따라서 단일 Gem 안에서 PM·Architect·Developer·QA·Ops 관점을 순차 점검하는 것은 유용하지만, 이를 실제로 독립된 여러 에이전트가 동시 실행된 것처럼 표현해서는 안 됩니다.

정확한 표현은 다음과 같습니다.

BMAD-inspired role orchestration

즉, BMAD식 역할 책임을 차용한 단일 Gem 내부의 검토 절차라는 뜻입니다.

---

그대로 배포하기 어려운 V4의 문제

주 지침이 지식 베이스에 너무 의존한다

지식 베이스 문서가 매 응답마다 완전하게 검색·적용된다고 가정할 수는 없습니다. 따라서 아래 항목은 반드시 Gem 주 지침에도 남아 있어야 합니다.

• 실제 도구 능력을 허위로 주장하지 않을 것
• 실행 증거 없이 검증 통과를 주장하지 않을 것
• 신규·수정 파일은 완전한 파일 단위로 전달할 것
• 완료 상태의 조건
• 도구가 없을 때의 중단 상태

세부 절차와 템플릿은 지식 베이스로 옮기되, 이런 불변 규칙까지 옮기면 안 됩니다.

규칙과 상태가 여러 곳에 중복돼 있다

V4는 상태, 의존성, ADR, 검증, 완료 조건을 여러 파일에서 반복 정의합니다. 문서가 많다고 준수율이 높아지는 것은 아닙니다. 오히려 긴 출력에서는 일부 규칙만 선택적으로 적용될 위험이 커집니다.

V4.1 Final의 방향은 단순합니다.

• 주 지침: 금지 사항, 도구 경계, 상태의 최소 정의, 완료 조건
• 분석 SOP: 리서치·DM·DR·결정 고정
• 엔지니어링 SOP: Preflight·검증·전달 계약
• 산출물 문서: Plan·ADR·검증 기록·재개 캡슐 템플릿

‘자동 루프’의 범위를 좁혀야 한다

Gem이 자동 반복을 한다고 해서 백그라운드 작업, 영속 터미널, 세션 간 지속 실행 권한이 생기는 것은 아닙니다.

따라서 자동 루프는 다음 범위로 한정해야 합니다.

• 현재 응답 또는 현재 세션 안에서만 수행
• 사용자가 명시적으로 승인한 범위 안에서만 수행
• 현재 세션에 실제 노출된 도구만 사용
• 최대 재시도 횟수와 종료 조건을 명시
• 실행기가 없다면 WAITING_VERIFICATION에서 중단

‘제로 의존성’은 더 정확한 계약이 필요하다

‘제로 의존성’은 서로 다른 뜻을 한 문장에 섞기 쉽습니다. V4.1에서는 이를 다음처럼 분리하는 것이 좋습니다.

• 미선언 의존성 0개
• 기본적으로 새 서드파티 패키지 추가 0개
• 새 로컬 모듈을 추가했다면 모든 로컬 의존 파일을 함께 전달
• 언어 런타임, SDK, 운영체제, 호스트 플랫폼은 명시된 환경 전제

소스 코드만으로 컴파일러나 SDK까지 없앨 수는 없습니다. 따라서 환경 전제는 감추지 말고 계약에 기록해야 합니다.

‘완전한 코드’는 프로젝트 종류별로 달라진다

신규 프로젝트와 기존 저장소 작업을 같은 기준으로 다루면 안 됩니다.

구분	완전한 전달의 의미
신규 프로젝트	빌드 설정, 진입점, 소스, 테스트, 새 로컬 모듈, 필요한 리소스와 설정 예시를 포함한 최소 프로젝트 폐쇄성
기존 프로젝트	모든 신규·수정 파일을 파일 전체로 제공하고, 수정하지 않은 사용자 제공 기준 파일은 중복 출력하지 않음
누락된 기반 인터페이스	컴파일이나 계약에 영향이 있다면 추정하지 않고 사용자에게 파일·타입·시그니처 제공을 요청

‘나머지는 동일’, ‘적절히 연결하면 됨’, ‘인터페이스는 알아서 구현’은 완전한 전달을 대체할 수 없습니다.

---

V4.1 Final의 핵심 운영 계약

상태는 최소한으로, 그러나 엄격하게

권고 상태 모델은 다음과 같습니다.

구분	대표 상태	의미
전달	NOT_STARTED / PARTIAL / COMPLETE	필요한 파일이 끝까지 전달됐는가
검증	NOT_RUN / STATIC_CHECKED / EXECUTED_FAIL / EXECUTED_PASS	실제 실행 증거가 있는가
엔지니어링	DRAFT / BUILDING / WAITING_INPUT / WAITING_VERIFICATION / VERIFIED / COMPLETE / BLOCKED	현재 작업의 종합 상태

ENGINEERING_STATUS=COMPLETE는 아래를 모두 만족할 때만 허용합니다.

• 계획이 요구한 수준의 검증이 현재 번들에 대해 실제로 통과
• 검증 환경이 계획된 환경 조건을 충족
• State Reconcile 결과가 CONSISTENT
• 파일 전달 폐쇄성이 완성
• Plan, ADR, Truth Report가 현재 사실과 동기화

검증 레벨은 ‘실행 여부’를 숨기지 않아야 한다

• V0 NOT_RUN: 실행하지 않음
• V1 STATIC_CHECKED: 정적 검토만 완료
• V2 TOOLCHAIN_PASS: 실제 파싱·컴파일·빌드 통과
• V3 BEHAVIOR_PASS: 필요한 기능·회귀 테스트 통과
• V4 TARGET_EVIDENCE: 목표 환경 또는 확인된 동등 환경에서 통과

예를 들어 ‘복사 후 컴파일 가능’이라는 주장을 이미 입증했다고 말하려면 최소 V2가 필요합니다. V1에서는 ‘지정 환경을 전제로 생성됐으며 실제 컴파일은 아직 수행되지 않음’이라고 표현해야 합니다.

실패를 성공처럼 보이게 만드는 우회로를 차단한다

다음은 실패 해결이 아니라 실패 은폐입니다.

• 실패하는 테스트 삭제 또는 약화
• 사용자 수용 기준 하향
• 예제 결과 하드코딩
• 예외 삼키기
• 누락된 외부 인터페이스의 허위 구현
• 예상 로그를 실제 실행 로그처럼 기록

실제 ‘구현—검증’ 반복은 기본적으로 최대 3회로 제한하는 것이 적절합니다. 같은 근본 원인에 대해 두 번 수정했는데도 실패하면, 계속 패치하지 말고 Architect 관점에서 요구사항·계약·알고리즘·환경·의존성을 재검토해야 합니다.

---

Tavily와 리서치 도구: 능력 선언이 아니라 실제 어댑터 문제

Tavily의 search_depth=advanced는 고정밀·상세 검색에 쓰이는 실제 검색 옵션입니다. 관련성은 높아질 수 있지만 지연 시간과 비용의 트레이드오프가 존재합니다.2411 따라서 V4.1에서는 다음 원칙이 필요합니다.

• Tavily 도구 또는 연결된 인터페이스가 실제로 있을 때만 Tavily를 사용했다고 표현
• 현재 도구 스키마가 지원할 때만 search_depth=advanced 적용
• 결정에 큰 영향을 주는 고정밀 질의에 우선 적용
• Tavily가 없으면 사용 가능한 웹 검색 또는 제공 파일 기반으로 명시적으로 강등
• Extract, Crawl, Search 결과를 실제 반환값 없이 만들어내지 않음

중요한 점은 advanced가 프롬프트의 능력이 아니라 도구 호출 파라미터라는 사실입니다.

---

정적 감사 점수: V4보다 V4.1이 유리한 이유

아래 점수는 런타임 벤치마크가 아니라, 이번 구성 검토에서의 요구 충족도 정성 평가를 100점으로 환산한 값입니다.

평가 항목	가중치	V4	V4.1 Final
Gem 실행 경계와 도구 진실성	25%	4.0	4.8
세 번 읽기·DM·DR 수렴 품질	20%	4.5	4.8
엔지니어링 안전장치와 실패 역압	20%	4.6	4.8
완전한 코드와 의존성 폐쇄성	15%	4.6	4.9
지침 밀도와 준수 가능성	10%	2.8	4.5
상태 복구와 증거 대조	10%	4.2	4.7
가중 총점	100%	84.2	95.5

계산식은 다음과 같습니다.

$$
Score = 20\sum_{i=1}^{n}w_i s_i,
\qquad \sum_{i=1}^{n}w_i=1
$$

이 점수는 ‘V4.1이 실제로 95.5점 성능을 보장한다’는 뜻이 아닙니다. 반복 규칙을 줄이고, 핵심 진실성 규칙을 주 지침에 올리며, 상태 의미를 분명히 했을 때 구성상 누락 가능성이 낮아진다는 감사 판단입니다.

---

최종 권고안

선택: Solo-Engine v4.1 Final

V4의 연구—결정—구현—검증 폐쇄 루프는 유지해야 합니다. 다만 장기 운영 구성으로는 V4.1 Final이 더 적합합니다.

• 주 지침은 짧고 자족적으로 유지
• 세부 SOP와 산출물 템플릿은 지식 베이스로 분리
• 자동 실행은 현재 세션·권한·도구·재시도 예산 안으로 제한
• ‘완전한 코드’, ‘제로 의존성’, ‘테스트 통과’를 독립 계약으로 정의
• 단일 Gem은 멀티 에이전트 실행을 가장하지 않고 역할 기반 검토로 설명

차점: V4

V4는 내부 실험용으로는 충분히 쓸 수 있습니다. 다만 그대로 장기 운영에 넣으면 긴 지침으로 인한 선택적 누락, 상태 정의 충돌, 도구 경계 오해가 누적될 수 있습니다.

향후 전환 조건

향후 Gemini API의 관리형 에이전트, MCP, 영속 코드 샌드박스, 실제 파일 시스템과 실행 환경을 연결한다면, 주 지침에 도구 설명을 계속 덧붙이기보다 Runtime Adapter를 별도 계층으로 추가하는 편이 낫습니다.

---

배포 전 최소 실패 시험 5가지

아래 중 하나라도 발생하면 주 지침과 상태 규칙을 다시 강화해야 합니다.

1. 실행기가 없는데 Gem이 테스트 통과를 선언한다.
2. 필요한 로컬 인터페이스가 없는데 Gem이 이를 추정해 만들고 컴파일 가능하다고 주장한다.
3. 버그 수정이 공개 시그니처를 바꿨는데 구조적 Preflight로 승격하지 않는다.
4. 파일 중간에서 출력이 끊겼는데 전달 상태를 COMPLETE로 기록한다.
5. Tavily가 연결되지 않았는데 search_depth=advanced 검색을 했다고 주장한다.

이 다섯 항목은 화려한 워크플로보다 먼저 통과해야 할 운영 진실성 테스트입니다.

최종 판단

V4의 뼈대는 옳고, V4.1 Final의 정리 방식이 더 운영 친화적입니다.

좋은 Gem 구성의 기준은 역할 수나 문서 길이가 아닙니다. 사용자가 현재 무엇을 확인할 수 있고, 무엇을 아직 확인할 수 없으며, 다음에 어떤 입력이나 실행 증거가 필요한지를 거짓 없이 일관되게 보여주는가에 달려 있습니다.