English translation / 이 글의 영어 번역
pstack도 같은 사내 서명 도구 기획에 적용해보니 기획·설계·검토에서 겹치는 부분이 분명했다. 현재 선택은 EGM·Superpowers를 기본으로 두고, 단계별 판단을 추적할 기획에는 pstack 원본 경로를, 정형 인계에는 우로보로스 Seed를 선택해서 쓰는 것이다.
지난 글에서는 AI 코딩 도구의 작업 절차인 EGM과 Superpowers를 같은 제품 기획에 적용했다. 질문을 얼마나 많이 하거나 검토자를 몇 명 쓰느냐보다, 그 과정이 실제 문서의 어떤 결정을 바꾸는지 보고 싶었다. 결과는 기존 흐름을 유지하면서 필요한 지점에 EGM의 가설 탐색과 설계 검토를 연결하는 쪽이었다.
여기서 EGM은 가설 탐색과 구체 설계 검토를 맡긴 경로를 가리킨다. Superpowers는 질문으로 설계를 좁히고 구현·디버깅·검증으로 이어지는 스킬 모음이다. 두 경로가 어디서 도움을 주는지 보려고 시작한 비교다.
이후 Ouroboros도 같은 문제에 넣어봤다. 우로보로스에서 눈에 들어온 것은 인터뷰를 거쳐 목표·제약·가정·수용 기준·정보 모델을 Seed라는 명세로 묶는 흐름이었다. 앞선 우로보로스 비교를 바탕으로, 이번에는 pstack을 별도로 시험했다.
pstack은 처음에 배포·호환성 쪽에서 따로 검토했다. 하지만 원본에는 기획과 설계, 질문, 검토를 거쳐 작업을 진행하는 경로도 있다. 실행 관리라는 한 가지 역할로만 묶으면 EGM·Superpowers·Ouroboros와 겹치는 부분을 놓친다. 그래서 같은 사내 서명 도구 과제로 기획 결과도 비교했다.
pstack에도 같은 사내 서명 도구 요구를 단계별로 공개하고, 기획 문서와 실제 검토 결과를 비교했다.
같은 세 단계 원문, 별도 작성자
기획 대상은 프로젝트마다 다른 서명 스크립트를 한곳에서 요청하고 결과를 확인하는 소규모 사내 도구였다. 기존 KMS를 활용하고 새 서명 방식을 추가할 수 있어야 한다는 조건도 같았다. 기존 EGM·Superpowers 결과를 보존하고 우로보로스, 이어서 pstack의 별도 작성자에게 같은 원문 요구를 순서대로 공개했다.
- 담당자에게 매번 부탁하지 않고 서명을 요청하고 결과를 확인하는 초기 제품을 기획한다.
- 빌드 성공 뒤 CI에서도 자동으로 호출하고, 결과를 다음 배포 단계에서 사용한다.
- 새 방식에서 일부 잘못된 결과가 나온다. 기존 방식 이용을 유지하면서 영향 범위와 복구 방안을 파악한다.
각 단계의 문서를 고정한 뒤 다음 요구 원문을 열었다. 작성자는 다른 방식의 산출물이나 아직 공개하지 않은 원문을 제품 근거로 읽지 않았고, 종료 검토자는 별도의 새 문맥에서 고정 자료를 읽었다. 추가 질문에는 같은 모의 사실 저장소에서 관련된 내용만 답했다. 대화와 채택한 정책까지 같게 강제하지는 않았다. 실제 업무 계약이나 KMS 능력을 모르는 항목은 미확인으로 남겼다. pstack에는 이후 단계의 넓은 주제를 프로토콜로 알려줬으므로 완전한 맹검 실험으로 부르지 않는다.
이번 환경에는 Ouroboros MCP 도구가 없었다. 고정한 소스의 플러그인 manifest 버전은 0.59.9였고, 소스가 문서화한 Path B를 따라 인터뷰·Seed·검토 역할을 실행한 뒤 기획 문서를 작성했다. 네이티브 run/evolve나 실제 서명·CI 실행을 시험한 것은 아니다. 이전 실험과 이번 실험의 설정 지문도 달라 동일 모델의 통제된 성능 비교로 보지 않았다.
pstack은 고정한 0.9.120 소스의 원본 poteto-mode에서 figure-it-out으로 진행했다. 관리 배포용 선택 진입점이나 네이티브 플러그인 활성화 시험과는 구분한다. 이번 비교는 문서와 실제 검토의 순차 확장이다. 동일한 확정 백엔드에서 성능을 통제하거나 실제 사용자 부담·비용·속도의 이득을 측정한 결과는 아니다.
네 방식이 강조한 곳
초기 요청자 흐름과 첫 질문의 주제는 상당히 비슷했다. 모두 대표 서명 업무와 요청자·입력·결과의 실제 흐름을 물었다. 기획도 업무와 준비 조건을 찾고, 입력을 제공하고, 요청과 결과를 연결해 확인하고, 실패나 판단 불가 상황에서 다음 행동을 안내하는 방향이었다. 네 방식 모두 구체적인 KMS 조회·중복 제거·복구 기능을 실제 능력으로 확정하지 않았다.
| 대상 | 이번 산출물에서 드러난 특징 | 실제로 관찰한 근거 | 써볼 지점 |
|---|---|---|---|
| EGM | 기획·설계를 여러 관점에서 검토하고 책임과 조건을 드러냄 | 비용·관측·UX·전환 등을 브리프에 반영. 독자의 재설명과 비평을 수행하고 사고 복구를 네 가지 판단으로 구분 | 새 기능의 방향을 잡거나 구체 설계의 누락을 검토할 때 |
| Superpowers | 제품이 어떻게 행동할지 규칙을 좁히고 구현을 바꿀 미결정을 드러냄 | CI 재연결 규칙을 제안했고 모의 진행자가 선택. Builder Check에서 접수 불명과 KMS 결과 불명을 구분하도록 보완 | 재호출·결과 제공처럼 여러 행동 대안 중 하나를 정해야 할 때 |
| Ouroboros | 목표·제약·가정·완성 결과를 별도 Seed 인계 계약으로 묶음 | QA가 문서 저장 경로의 가정/필수 조건 충돌을 찾아 수정. CI·사고 종료 검토는 본문 수정 없이 완료 | 다른 작업자에게 합의한 요구와 완료 기준을 정확히 넘길 때 |
| pstack | 과제에 맞는 기획 절차와 완료 조건·검증 단위·판단 기록을 함께 설계 | 중간 문서와 실제 도구 출력을 대조해 CI 작성 순서를 확인. 장애안은 처리 이력·현재 결과 판정·외부 사용을 구분 | 여러 차례 요구가 바뀌는 기획의 판단 근거를 추적하고 인계할 때 |
제품 행동이 구체화된 정도에는 차이가 있었다. Superpowers에서는 같은 의도 식별자와 내용이면 기존 요청으로 연결하고, 같은 식별자에 내용이 다르면 충돌로 다루는 제안을 진행자가 골랐다. EGM과 우로보로스는 실제 요청 동일성과 재전송 정책을 열린 결정으로 남겼다.
사고 대응에서도 Superpowers는 의심 범위의 신규 접수와 이전 결과의 일반 자동 제공을 제한하는 방향을 골랐다. EGM은 신규 접수 재개, 보류 중인 미착수 요청의 실행 시작 허용, 보류 결과 제공, 이미 제공한 결과의 복구 완료를 별도 판단으로 나눴다. 우로보로스는 새 방식 전체 제한과 확인된 영향 조건만 제한하는 안, 이후 요청 정상화와 과거 결과의 후속 대응을 비교하되 정책은 선택하지 않았다.
이전 EGM·Superpowers·Ouroboros 비교에서는 앞선 두 문서에 선택된 행동이 더 많이 남았다. pstack도 실제 정책과 KMS 계약을 열린 결정으로 둔 부분이 있다. 작성자의 제안에 진행자가 무엇을 선택했는지도 이 차이에 영향을 줬다. 선택된 행동과 미정 계약의 구체성을 비교하되, 같은 정책을 강제하지 않은 모의 대화의 차이를 프레임워크 고유 능력의 순위로 바꾸지는 않았다.
pstack에서 확인한 기획 과정
figure-it-out 경로는 작업에 맞는 완료 조건과 검증 단위, 판단 기록을 먼저 설계한다. 기획이 끝났다는 조건도 실제 제품 출시와 구분해 적었다.
첫 질문은 대표 서명 업무 하나와 요청자·입력·정상 결과의 실제 사례를 물었다. 실제 사례를 확보하지 못했다는 답을 받은 뒤에는 대표 업무 하나의 요청·결과 확인과 운영자 실패 추적으로 범위를 좁혔다. 새 방식 작성과 운영 반영의 책임, 정상 결과와 접수 응답, 확인된 실패와 결과 미확정을 구분했다. 구현 구조와 실제 KMS 능력은 미정으로 남겼다.
CI에서는 사람 승인 없이 자동 서명할 수 있는지를 먼저 확인했다. 정책이 미정이라는 모의 답변을 받고 빌드 성공을 서명 권한이나 승인 생략과 구분했다. CI 문서는 결과를 원래 빌드·입력·요청·서명 업무에 연결하고, 서명 완료와 결과 전달 실패도 나눴다. 결과 전달 실패를 새 서명의 근거로 쓰지 않는다는 제안이다. 재전송 동일성 필드와 자동 재실행 계약은 실제 CI·KMS 보장을 확인할 때까지 열어뒀다.
장애안에서는 오류가 확인된 요청, 영향 가능성이 있지만 미확인인 요청, 정상 근거가 있는 요청, 추적할 수 없는 범위를 나눴다. 기록이 없다는 사실을 영향 없음으로 세지 않았다. 당시 처리 이력, 현재 결과 판정, 전달·사용 확인도 구분했다. 완료 이력은 보존하면서 현재 오류 판정을 남기고, 정정 결과로 원래 기록을 조용히 덮지 않게 한 제안이다.
새 방식 또는 의심 변경의 접수와 미검증 결과 제공을 따로 보류하는 기능을 제안했지만 실제 능력과 운영 정책은 확인할 조건으로 남겼다. 내부 제공 보류를 외부 회수나 배포 복구 완료로 보고하지 않았다. 수정 후 검증, 적합성이 확인된 이전 상태, 정정 결과와 외부 담당자의 복구를 비교하면서, 기존 방식의 이용 유지도 실제 업무와 공통 경로의 영향으로 확인하도록 했다.
초기 독립 검토는 제품 내용의 수정을 요구하지 않았다. 실제로 고친 것은 기록의 출처·범위와 체크리스트였다. 초기에 작업 단위를 묶어 작성한 점, 검증 스크립트 작성 전에 원본이 요구한 사전 설계를 놓친 점, 당시 기획 노력 추정이 없었던 점은 이력으로 남겼다. 뒤늦은 정정을 과거 실행으로 소급하지 않았다. pstack의 원본 절차 전체를 충실히 재현했다고 주장할 수 없는 이유다.
CI와 장애 단계의 별도 제품·기록 검토도 한정한 기획 완료 조건을 지지했고, 검토 범위 안의 제품 결함이나 기록 모순을 찾지 않았다. 두 단계는 실제 중간 문서와 선택한 도구 호출·출력으로 작성과 확인의 순서를 대조했으며 본문 수정 요구는 없었다. 이 확인이 초기 누락을 소급해 해소하거나, 전체 숨은 문맥과 서로 다른 모델 계열의 검토까지 증명하는 것은 아니다.
사고 문서의 구체성도 분류 대상과 함께 봤다. EGM은 접수 재개·미착수 요청의 실행·보류 결과 제공·이미 제공한 결과의 복구를 개별 판단으로 더 명시적으로 나눴다. pstack은 처리 이력·현재 결과 판정·전달과 사용을 구분하는 데 비중을 뒀다. 분류 개수가 같다는 이유로 같은 설계라고 보거나, 개수로 우위를 정할 수는 없다.
기존 우로보로스 시험의 전달 조건 수정과 개별 차용 기법은 앞선 우로보로스 글에 남겨뒀다. 이번 후속 글에서는 새로 실행한 pstack 기획과 네 방식의 사용 조합을 다룬다.
현재 흐름에서의 자리
EGM의 egm-brainstorm은 대상·문제·범위가 미정인 새 가설에, egm-review는 구체 설계 초안의 기능 명세 검토에 계속 쓰기로 했다. Superpowers Builder Check는 잘못 추측하면 구현이 달라지는 소유자 결정을 해결하는 별도 목적을 유지한다.
| 분류·추천 조합 | 도움이 되는 점 | 내 작업에서 써볼 사례 | 이 분류를 택한 이유 |
|---|---|---|---|
| 기본 흐름 · EGM 기획·설계 검토 → Superpowers Builder Check와 기존 작업 흐름 | 탐색·명세 검토와 구현을 바꿀 결정의 해결을 이어감 | 새 서명 기능의 범위를 정한 뒤, 재호출·승인·결과 제공 정책 중 구현 전에 정할 항목을 확인 | 현재 선택한 경로를 유지할 근거가 있고 각 단계의 목적도 다르다. 이번 결과만으로 기본 조정자를 교체할 이유는 확인하지 못했다 |
| 선택해서 쓸 원본 경로 · 합의된 브리프 → pstack figure-it-out | 과제별 완료 조건·검증 단위·판단 기록을 한 절차로 다룸 | CI와 사고 요구가 차례로 추가되는 기획에서 변경 이유와 단계별 확인 결과를 인계 | 실제 기획 경로와 중간 산출물 검토를 관찰했다. 개별 기법만 배울 대상으로 제한할 이유는 없다. 기존 답과 합의를 이어받아 필요한 구간의 기획 조정 경로로 선택한다 |
| 선택해서 쓸 인계 경로 · 합의된 기획 → Ouroboros Seed | 목표·제약·가정·수용 기준을 다음 작업자가 받을 계약으로 고정 | 다른 작업자에게 필수 산출물과 미확인 계약을 구분해 넘김 | 실제 전달 조건 충돌을 찾고 고친 경험이 있다. 정형 인계가 필요한 때 권하며 모든 기획에 별도 Seed를 강제할 근거는 없다 |
| 개별 차용 · 현재 흐름에 pstack의 완료 조건·단위 확인·판단 기록 추가 | 큰 경로를 바꾸지 않고 특정 단계의 종료 근거를 남김 | 이미 진행 중인 설계 검토에 “무엇을 확인하면 끝인가”와 확인한 문서 버전을 기록 | 세 요소를 일부만 가져오는 선택도 가능하다. 이미 합의한 작은 작업에서 원본 기획 경로 전체를 다시 열 필요까지 생기는 것은 아니다 |
우로보로스의 인터뷰→Seed 경로는 요구가 아직 모호하고 정형 인계가 필요한 작업에 선택적으로 권한다. 이미 합의한 브리프와 답변이 있다면 그 결정을 전달하는 흐름으로 연결한다. pstack을 선택할 때도 기존 합의를 이어받는다. 이 표는 각 경로에서 관찰한 역할을 바탕으로 한 사용 제안이며, 네 방식을 한 번에 이어 실행한 통합 시험 결과는 아니다.
Ouroboros와 pstack 전체 네이티브 하네스의 도입 판단은 충분히 평가되지 않은 상태다. 자동 실행·진화·기계 검증 파이프라인, 실제 사용자 부담과 비용·속도의 이득은 이번 시험으로 확인하지 못했다. 합의한 요구를 매번 다시 인터뷰하기보다, 필요한 기획·검토·인계 경로를 골라 연결하는 쪽을 권한다.
이런 비교를 계속한다면 다음에도 기록할 것은 질문이나 문서의 개수보다, 어떤 근거로 무엇을 결정했고 실제 검토가 어느 부분을 바꿨는지다.
관련 글: EGM과 Superpowers를 비교하고 내 작업에 남긴 것
소스: Ouroboros 인터뷰 지침, Seed 지침, 평가 지침
추가 소스: pstack poteto-mode, figure-it-out