EGM·Superpowers에 Ouroboros를 더해 같은 기획을 시켜봤다

English translation / 이 글의 영어 번역

지난 글에서는 AI 코딩 도구의 작업 절차인 EGM과 Superpowers를 같은 제품 기획에 적용했다. 질문을 얼마나 많이 하거나 검토자를 몇 명 쓰느냐보다, 그 과정이 실제 문서의 어떤 결정을 바꾸는지 보고 싶었다. 결과는 기존 흐름을 유지하면서 필요한 지점에 EGM의 가설 탐색과 설계 검토를 연결하는 쪽이었다.

이후 Ouroboros도 같은 문제에 넣어봤다. 우로보로스에서 눈에 들어온 것은 인터뷰를 거쳐 목표·제약·가정·수용 기준·정보 모델을 Seed라는 명세로 묶는 흐름이었다. 이 글은 앞선 비교에 그 경로를 추가한 후속 기록이다.

같은 세 단계, 새 작성자

기획 대상은 프로젝트마다 다른 서명 스크립트를 한곳에서 요청하고 결과를 확인하는 소규모 사내 도구였다. 기존 KMS를 활용하고 새 서명 방식을 추가할 수 있어야 한다는 조건도 같았다. 앞선 두 결과를 보존하고 우로보로스의 새 작성자에게 다음 요구를 순서대로 공개했다.

담당자에게 매번 부탁하지 않고 서명을 요청하고 결과를 확인하는 초기 제품을 기획한다.
빌드 성공 뒤 CI에서도 자동으로 호출하고, 결과를 다음 배포 단계에서 사용한다.
새 방식에서 일부 잘못된 결과가 나온다. 기존 방식 이용을 유지하면서 영향 범위와 복구 방안을 파악한다.

각 단계의 문서를 고정한 뒤 다음 요구를 열었다. 작성자는 이전 두 방식의 결과나 미래 요구를 제품 근거로 읽지 않았고, 종료 검토자들은 별도의 새 문맥에서 고정 자료를 읽었다. 추가 질문에는 같은 모의 사실 저장소에서 관련된 내용만 답했다. 실제 업무 계약이나 KMS 능력을 모르는 항목은 미확인으로 남겼다.

이번 환경에는 Ouroboros MCP 도구가 없었다. 고정한 소스의 플러그인 manifest 버전은 0.59.9였고, 소스가 문서화한 Path B를 따라 인터뷰·Seed·검토 역할을 실행한 뒤 기획 문서를 작성했다. 네이티브 run/evolve나 실제 서명·CI 실행을 시험한 것은 아니다. 이전 실험과 이번 실험의 설정 지문도 달라 동일 모델의 통제된 성능 비교로 보지 않았다.

세 방식이 강조한 곳

초기 요청자 흐름은 상당히 비슷했다. 서명 업무와 준비 조건을 찾고, 입력을 제공하고, 요청과 결과를 연결해 확인하고, 실패나 판단 불가 상황에서 다음 행동을 안내하는 방향이었다. 세 방식 모두 구체적인 KMS 조회·중복 제거·복구 기능을 만들어 넣지 않았다.

대상	이번 산출물에서 드러난 특징	실제로 관찰한 근거	써볼 지점
EGM	기획·설계를 여러 관점에서 검토하고 책임과 조건을 드러냄	비용·관측·UX·전환 등을 브리프에 반영. 독자의 재설명과 비평을 수행하고 사고 복구를 네 가지 판단으로 구분	새 기능의 방향을 잡거나 구체 설계의 누락을 검토할 때
Superpowers	제품이 어떻게 행동할지 규칙을 좁히고 구현을 바꿀 미결정을 드러냄	CI 재연결 규칙을 제안했고 모의 진행자가 선택. Builder Check에서 접수 불명과 KMS 결과 불명을 구분하도록 보완	재호출·결과 제공처럼 여러 행동 대안 중 하나를 정해야 할 때
Ouroboros	목표·제약·가정·완성 결과를 별도 Seed 인계 계약으로 묶음	QA가 문서 저장 경로의 가정/필수 조건 충돌을 찾아 수정. CI·사고 종료 검토는 본문 수정 없이 완료	다른 작업자에게 합의한 요구와 완료 기준을 정확히 넘길 때

제품 행동이 구체화된 정도에는 차이가 있었다. Superpowers에서는 같은 의도 식별자와 내용이면 기존 요청으로 연결하고, 같은 식별자에 내용이 다르면 충돌로 다루는 제안을 진행자가 골랐다. EGM과 우로보로스는 실제 요청 동일성과 재전송 정책을 열린 결정으로 남겼다.

사고 대응에서도 Superpowers는 의심 범위의 신규 접수와 이전 결과의 일반 자동 제공을 제한하는 방향을 골랐다. EGM은 신규 접수 재개, 보류 중인 미착수 요청의 실행 시작 허용, 보류 결과 제공, 이미 제공한 결과의 복구 완료를 별도 판단으로 나눴다. 우로보로스는 새 방식 전체 제한과 확인된 영향 조건만 제한하는 안, 이후 요청 정상화와 과거 결과의 후속 대응을 비교하되 정책은 선택하지 않았다.

앞선 두 문서에는 선택된 행동이 더 많이 남았다. 이 차이에는 작성자의 제안에 진행자가 무엇을 선택했는지도 영향을 줬다. 같은 정책을 고르게 강제하지 않은 모의 대화에서 나온 결과이므로, 이를 곧바로 프레임워크 고유 능력의 순위로 바꾸지는 않았다.

우로보로스의 QA가 실제로 고친 것

처음 만든 Seed에서는 문서를 저장할 위치를 가정에 넣어놓고, 수용 기준에서는 그 위치를 필수 산출물로 요구했다. 가정은 바뀔 수 있는 제안인데 완료 판정에서는 반드시 지켜야 하는 조건이 된 셈이다.

독립 QA가 이 충돌을 짚었다. 진행자가 저장 위치를 명시적인 전달 조건으로 채택한 뒤 가정에서 빼고 제약으로 옮겼다. 목표·수용 기준의 내용·정보 모델은 유지했고, 실제 변경도 두 필드에 한정됐는지 대조했다. 명시적으로 선택한 한 차례의 보완 뒤 새 QA가 해당 충돌의 해소를 확인했다.

이 수정은 문서 전달 계약을 바로잡은 것이다. 서명 정책이나 사고 복구 기능을 새로 해결한 수정으로 세지 않았다. CI와 사고 단계의 종료 검토에서는 본문 수정 요구가 없었다. 질문 수나 검토자 수, 모델이 준 QA 점수도 세 방식의 품질 점수로 사용하지 않았다.

가져오기로 한 네 가지

전체 하네스를 바꾸는 것과 작은 기법을 현재 흐름에 넣는 것은 적용 범위가 다르다. 이번에는 다음 네 가지를 기존 스킬에 가져오기로 했다.

가져올 기법	도움이 되는 점	내 작업에서 써볼 사례	기법으로 가져오는 이유
중요한 답의 해석 확인과 미확인 기록	범위·제약을 바꿀 답을 어떻게 해석했는지 확인하고 모르는 부분을 다음 단계까지 보존	“CI도 지원”이 첫 출시 포함인지 후속 작업인지, “기존 방식 유지”가 목표인지 검증된 능력인지 구분	실제 답변→해석→확인이 작동했다. 중요한 해석 지점에 넣을 수 있고 사소한 수정마다 전체 인터뷰를 열 필요는 없다
종료 가능성·숨은 가정·누락 검토의 분리	서로 다른 질문을 맡은 검토자가 같은 고정 자료로 종료 여부를 확인	사고 대응 기획에서 빠진 정책 선택과 아직 알 수 없는 KMS 능력을 구분	실제 새 문맥의 검토를 수행했다. 검토 목표와 입력·종료 기준을 현재 리뷰에 붙일 수 있다. 이번 실행이 결함 감소를 측정한 것은 아니다
제약·가정·완성 결과의 구분과 수용한 수정 추적	제안이 필수 조건으로 섞이는 충돌을 찾고 합의한 수정만 반영했는지 대조	인계 문서의 필수 산출물과 가정, 미확인 기능을 나누고 수정 전후를 확인	저장 경로 충돌을 실제로 찾아 고쳤다. 이 계약 점검에 전체 실행 하네스가 필요하지 않다
모델 의견과 실제 검증 권한의 구분	QA의 괜찮다는 평가, 실행한 검사, 실제 효과의 증거를 다른 상태로 보고	스킬 복사, 도구 발견, 실제 작업 실행 성공을 각각의 증거로 확인	고정한 평가 지침이 자문과 실제 수용 권한을 구분한다. 이번에도 문서·YAML 확인을 네이티브 승인으로 올려 부르지 않았다

이 사례들은 앞으로의 적용 제안이다. 다른 프로젝트에서 효과를 이미 측정했다는 뜻은 아니다. 기법을 적용하기로 한 결정과 각 환경에 실제 반영됐다는 증거도 구분해 남긴다.

현재 흐름에서의 자리

EGM의 egm-brainstorm은 대상·문제·범위가 미정인 새 가설에, egm-review는 구체 설계 초안의 기능 명세 검토에 계속 쓰기로 했다. Superpowers Builder Check는 잘못 추측하면 구현이 달라지는 소유자 결정을 해결하는 별도 목적을 유지한다.

우로보로스의 인터뷰→Seed 경로는 요구가 아직 모호하고 정형 인계가 필요한 작업에 선택적으로 권한다. 이미 합의한 브리프와 답변이 있다면 그 결정을 전달하는 흐름으로 연결한다. EGM 브레인스토밍 뒤 전체 우로보로스 인터뷰를 매번 다시 여는 방식은 이번에 시험한 연결이 아니다.

Ouroboros 전체 네이티브 하네스의 도입 판단은 충분히 평가되지 않은 상태다. 자동 실행·진화·기계 검증 파이프라인, 실제 사용자 부담과 비용·속도의 이득은 이번 시험으로 확인하지 못했다. 당분간은 기존 EGM·Superpowers 흐름을 유지하고 명세 고정과 인계에 필요한 부분을 더하는 쪽을 택했다.

이런 비교를 계속한다면 다음에도 기록할 것은 질문이나 문서의 개수보다, 어떤 근거로 무엇을 결정했고 실제 검토가 어느 부분을 바꿨는지다.

관련 글: EGM과 Superpowers를 비교하고 내 작업에 남긴 것

소스: Ouroboros 인터뷰 지침, Seed 지침, 평가 지침