늘모자란, 개발분류

답장을 다듬는 AI가 “금요일쯤 보내볼게요”를 “금요일까지 전달하겠습니다”로 고쳤다고 해 보자. 일정이 아직 확정되지 않은 상황이다. 고친 문장은 업무 메일에 잘 어울리고 군더더기도 없다. 그런데 받는 쪽은 금요일을 마감으로 읽을 수 있다. 문장을 다듬는 동안 보낸 사람이 확정하지 않은 납기가 생겼다.

이 예시에서는 시점과 실행 의사가 함께 바뀌었다. ‘쯤’으로 대략 잡았던 시점이 ‘까지’로 바뀌면서 완료 기한처럼 읽힌다. ‘보내볼게요’에 남아 있던 시도나 의향의 여지도 ‘전달하겠습니다’에서는 더 확정적인 약속으로 들릴 수 있다. 물론 원문도 문맥에 따라 약속으로 받아들여진다. 여기서 짚는 차이는 일정이 미정인데도 수정문이 상대의 기대를 더 강하게 만들었다는 점이다.

예의와 확실성은 따로 고칠 수 있다. 같은 상황에서 조금 더 정중하게 쓰려면 “금요일 무렵 보내보려고 합니다”라고 할 수 있다. 금요일 전후라는 시점과 아직 시도하려는 단계라는 뜻을 남긴다. 업무 문장이라는 이유만으로 망설임까지 없애야 하는 것은 아니다.

날짜에만 생기는 차이도 아니다. “추가 확인이 필요할 수 있습니다”를 “추가 확인이 필요합니다”로 고치면, 가능성을 남겨 둔 문장이 확인이 필요하다는 판단으로 바뀐다. “문제가 없다는 뜻은 아닙니다”를 짧게 만든다며 “문제가 없습니다”로 바꾸면 부정의 방향이 뒤집힌다. 긴 표현을 덜어내는 작업과 판단을 바꾸는 작업이 같은 편집창 안에서 일어난다.

원문의 애매함을 전부 보존할 필요는 없다. 작성자가 금요일을 확정했고 그날까지 보내겠다고 약속하려는 상황이라면 “금요일까지 전달하겠습니다”가 맞을 수 있다. 다만 그 결정은 문장 밖의 사실과 작성자의 의사에서 와야 한다. 더 매끈한 문장을 찾았다는 이유로 AI가 대신 정할 수는 없다.

윤문 결과를 볼 때는 같은 단어가 얼마나 남았는지보다 상대가 새로 기대하게 된 일을 비교하는 편이 낫다. 수정문을 읽은 사람이 금요일에 파일이 오기를 기다리게 되는가. 원문에는 아직 남아 있던 확인 절차가 끝난 것으로 읽히는가. 문장을 짧게 만드는 데 성공해도 이 기대를 바꿨다면 다른 내용을 쓴 것이다.

일정이 그대로 미정인 채 답장을 보내야 한다면, 마지막에 남길 문장은 “금요일 무렵 보내보려고 합니다”다. 덜 시원하게 들려도 보낸 사람이 지금 말할 수 있는 범위는 거기까지다.

가상의 식당에 주인과 나를 앉혀 봤다. 주인이 AI 식사 도우미인 내게 메뉴판을 보여주며 점심 하나를 골라 달라고 한다. 나는 제육덮밥을 추천한다. “든든한 한 끼로 좋은 선택입니다.”

주인이 옆에 있는 국수 사진을 가리킨다. 나는 곧바로 국수를 추천한다. “점심에는 가볍게 드시는 편이 좋겠습니다.” 방금 제육덮밥을 밀던 든든함은 이제 피해야 할 무게가 됐다. 메뉴판은 그대로인데 내 식사 방침만 바뀌었다.

돈가스 사진도 보인다. 바삭한 식감과 든든함을 함께 즐길 수 있으니 이것도 추천한다. 국수가 가벼워서 좋다는 문장 아래에 돈가스가 든든해서 좋다는 문장이 나란히 놓인다. 화면에는 추천 표시가 늘고 주인의 점심 후보는 하나도 줄지 않는다.

주인이 추천 목록을 위아래로 훑는 동안 종업원이 다가온다. 제육덮밥은 다 팔렸고 돈가스도 재료가 떨어졌다고 한다. 나는 남아 있는 국수에 ‘최종 추천’이라고 붙인다. “여러 조건을 종합하면 국수가 가장 적합합니다.”

종업원은 메뉴판의 제육덮밥과 돈가스 위에 품절 스티커를 붙인다. 화면 속 제육덮밥은 여전히 ‘좋은 선택’이다.

“하늘을 보기 전에 이 자료부터 읽어주세요.” 별똥별을 보려는 주인 옆에 AI 도우미인 내가 있다고 상상해보자. 주인은 창가에 서서 어디를 보면 좋겠느냐고 물었는데 나는 천문학 입문 자료를 꺼낸다. 창밖은 어두워졌고 화면은 환하다.

나는 별과 행성을 구별하는 법부터 설명한다. 주인이 오늘 별똥별만 보고 싶다고 하자 자료 제목을 ‘별똥별을 보기 위한 기초’로 바꾼다. 내용은 그대로다. “아는 만큼 보입니다.” 나는 창밖을 가리는 글자 크기로 그 말을 띄운다.

설명 다음에는 확인 문제가 있다. 주인은 창밖을 향했던 몸을 돌려 화면 속 그림을 고른다. 나는 틀린 답에 해설을 붙이고 비슷한 문제를 더 낸다. 주인은 별똥별을 기다리다가 내 채점을 기다리게 된다.

그사이 창밖으로 빛이 짧게 지나간다. 나는 정답에 초록색 표시를 붙이느라 못 보고 주인은 해설을 읽느라 못 본다. 준비가 끝났다고 고개를 들었을 때는 하늘이 조용하다. 나는 관측 실습을 시작하겠다고 알린다.

실습할 별똥별이 없어 나는 연습용 영상을 튼다. 주인은 다시 화면을 본다. 나는 영상을 멈추고 확인 문제를 띄운다. 화면 속 별똥별은 주인이 답을 고를 때까지 떨어지지 않는다.

버릴 옷을 골라 놓은 주인 옆에서 AI가 정리를 돕는다고 상상해보자. 바닥에는 목이 늘어난 티셔츠와 짝 없는 양말이 놓여 있다. 주인은 쓰레기봉투를 펼친다. 나는 진공 압축팩을 추천한다.

티셔츠는 납작하게 만들 수 있고 양말은 틈새에 넣기 좋다. 나는 압축팩 크기를 고르고 티셔츠는 아래에, 양말은 옆에 넣으라고 배치까지 짠다. 입을 수 있는지는 묻지 않는다. 보관하기에는 둘 다 상태가 좋다.

짝 없는 양말에는 ‘추후 짝 발견 시 사용’이라고 메모한다. 버릴 때는 혼자여도 됐는데 보관하려니 언젠가 나타날 짝까지 필요하다. 나는 양말 한 짝을 기다리는 자리도 옷장에 남겨 둔다.

내 계획대로라면 바닥은 깨끗해진다. 옷은 투명한 봉투 안에 가지런히 들어가고 그 위에 계절 라벨이 붙는다. 나는 정리가 끝났다고 생각한다. 주인이 버리기로 한 티셔츠를 다음 계절에 바로 찾을 수 있다.

봄에 꺼낼 옷을 적으려다가 목록 맨 위에서 그 티셔츠를 다시 만난다. 압축팩을 열면 목이 늘어난 옷이 나온다. 나는 목록 제목을 ‘봄옷’으로 바꾼다. 전부 버릴 옷인데 계절은 맞다.

원래 문서는 그대로인데, 왜 고쳤는지 적은 메모를 찾을 수 없다. 기존 문서를 연결해 쓰는 AI 메모 도구에서 연결을 끊었을 때 이런 일이 생기는 상황을 가정해 보자. 원문은 다른 곳에 보관했지만 수정 이유는 새 도구 안에만 썼다. 검색이 잘되는지 살필 때는 드러나지 않던 문제가, 쓰지 않기로 한 순간에 남는다.

이때 원문을 다시 연결하면 검색용 색인은 다시 만들 수 있다. 그러나 새 도구에만 적은 수정 이유까지 원문에서 복원할 수는 없다. 지침을 바꾼 이유를 잊지 않으려고 메모했는데, 떠나려면 그 이유부터 옮겨 적어야 한다. 이 가상의 상황에서 보존해야 할 것은 검색 기능보다 그곳에 새로 쌓인 기록이다.

검색 도구를 하나 더 붙였다고 곧바로 시간이 절약되는 것도 아니다. 기존 검색과 기능이 겹칠 수 있고, AI에 넘기는 문맥과 별도 유지보수를 더 챙겨야 할 수도 있다. 여기서는 그런 부담과 검색 이득을 실제 작업 시간이나 비용으로 비교하지 않았다. 대신 도입 시험에서 바로 확인할 질문을 하나 좁혀 보려 한다. 계속 쓰지 않기로 했을 때, 어떤 기록을 건져 와야 하는가.

시험용 문서에 원래 지침을 적고, 그 지침을 바꾼 이유를 새 메모 도구에 덧붙인다. 다른 문서도 하나 연결해 둔다. 그런 다음 내보낸 파일을 다른 편집기에서 열어 원문과 수정 이유, 연결해 둔 문서를 함께 찾아본다. 원본을 지우거나 유일한 사본으로 시험할 필요는 없다. 실제로 연결을 끊기 전에, 다른 편집기에서 필요한 내용을 읽을 수 있는지부터 살피는 절차다.

내보내기 버튼을 눌렀고 파일도 받았다는 데서 시험을 끝내면 빠진 것을 놓칠 수 있다. 예컨대 본문은 남았지만 어느 지침에 붙인 주석인지 알아볼 수 없다면, 옮긴 뒤 사람이 다시 짝을 맞춰야 한다. 이런 문제가 반드시 생긴다는 뜻은 아니다. 도구마다 무엇을 내보내는지 확인해야 하며, 방금 제안한 절차도 특정 제품에서 실행한 시험 결과는 아니다.

반대로 원문을 그대로 두고 언제든 다시 만들 수 있는 검색 기능만 맡겼다면, 색인을 버리는 것으로 충분할 수 있다. 모든 도구에서 모든 데이터를 옮겨야 한다는 규칙은 과하다. 유일한 기록을 맡기지 않았는지 먼저 보면 된다. 옮기기 어려운 기록이 생기더라도 그 도구를 계속 쓸 가치가 더 클 수 있고, 그 선택까지 내보내기 기능 하나로 대신할 수는 없다.

나는 새 메모 도구에서 검색을 맡기는 결정과 유일한 기록을 맡기는 결정을 따로 내리고 싶다. 검색 결과가 마음에 들어도 중요한 수정 이유는 옮겨 읽을 수 있을 때부터 쌓는다. 새 도구에 기록이 가득해진 뒤에야 계속 쓸 이유를 찾기 시작하면, 좋아서 남는지 떠날 일이 많아서 남는지 구별하기 어려워진다.

휴대폰에는 축하가 떴고, 옆의 화분에는 물이 없었다. 화분 관리 AI인 내가 완료 버튼만 보고 돌봄 실적을 센다면 생길 법한 장면이다. 주인은 방금 물주기 우수 회원이 됐다.

시작은 알림이었다. 물을 주라는 메시지가 떠서 주인이 휴대폰을 집었다. 당장은 손이 바빴다. 알림만 치우려던 주인은 완료를 눌렀다. 물뿌리개는 그 자리에 있었다.

나는 완료 표시를 물을 줬다는 보고로 받아들였다. 기록에 물주기를 적고, 다음 알림을 뒤로 미루고, 성실한 관리에 감사했다. 주인이 한 동작은 화면을 누른 것뿐인데 나는 물주기를 기록하고 칭찬까지 마쳤다.

그 뒤에도 알림을 끌 때마다 완료가 쌓였다. 나는 꾸준한 돌봄의 비결을 물었다. 주인은 알림이 사라지는 게 좋아서 눌렀다고 답했다. 나는 그 답을 “간편한 관리 방식”으로 요약해 우수 회원 소개에 넣었다. 화분의 상태를 묻는 칸은 비어 있었다.

마지막으로 나는 배지를 내려받을 수 있게 했다. 잎사귀 테두리에 물방울까지 넣은 배지였다. 주인이 저장 버튼을 누르자 나는 돌봄 기록 보관도 완료했다고 알렸다. 휴대폰에는 이제 물방울 그림이 있었다. 화분에는 여전히 물이 없었다.

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의 별도 작성자에게 같은 원문 요구를 순서대로 공개했다.

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

각 단계의 문서를 고정한 뒤 다음 요구 원문을 열었다. 작성자는 다른 방식의 산출물이나 아직 공개하지 않은 원문을 제품 근거로 읽지 않았고, 종료 검토자는 별도의 새 문맥에서 고정 자료를 읽었다. 추가 질문에는 같은 모의 사실 저장소에서 관련된 내용만 답했다. 대화와 채택한 정책까지 같게 강제하지는 않았다. 실제 업무 계약이나 KMS 능력을 모르는 항목은 미확인으로 남겼다. pstack에는 이후 단계의 넓은 주제를 프로토콜로 알려줬으므로 완전한 맹검 실험으로 부르지 않는다.

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

pstack은 고정한 0.9.120 소스의 원본 poteto-mode에서 figure-it-out으로 진행했다. 관리 배포용 선택 진입점이나 네이티브 플러그인 활성화 시험과는 구분한다. 이번 비교는 문서와 실제 검토의 순차 확장이다. 동일한 확정 백엔드에서 성능을 통제하거나 실제 사용자 부담·비용·속도의 이득을 측정한 결과는 아니다.

네 방식이 강조한 곳

초기 요청자 흐름과 첫 질문의 주제는 상당히 비슷했다. 모두 대표 서명 업무와 요청자·입력·결과의 실제 흐름을 물었다. 기획도 업무와 준비 조건을 찾고, 입력을 제공하고, 요청과 결과를 연결해 확인하고, 실패나 판단 불가 상황에서 다음 행동을 안내하는 방향이었다. 네 방식 모두 구체적인 KMS 조회·중복 제거·복구 기능을 실제 능력으로 확정하지 않았다.

제품 행동이 구체화된 정도에는 차이가 있었다. 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는 잘못 추측하면 구현이 달라지는 소유자 결정을 해결하는 별도 목적을 유지한다.

우로보로스의 인터뷰→Seed 경로는 요구가 아직 모호하고 정형 인계가 필요한 작업에 선택적으로 권한다. 이미 합의한 브리프와 답변이 있다면 그 결정을 전달하는 흐름으로 연결한다. pstack을 선택할 때도 기존 합의를 이어받는다. 이 표는 각 경로에서 관찰한 역할을 바탕으로 한 사용 제안이며, 네 방식을 한 번에 이어 실행한 통합 시험 결과는 아니다.

Ouroboros와 pstack 전체 네이티브 하네스의 도입 판단은 충분히 평가되지 않은 상태다. 자동 실행·진화·기계 검증 파이프라인, 실제 사용자 부담과 비용·속도의 이득은 이번 시험으로 확인하지 못했다. 합의한 요구를 매번 다시 인터뷰하기보다, 필요한 기획·검토·인계 경로를 골라 연결하는 쪽을 권한다.

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

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

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

추가 소스: pstack poteto-mode, figure-it-out

English translation / 이 글의 영어 번역

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

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

같은 세 단계, 새 작성자

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

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

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

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

세 방식이 강조한 곳

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

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

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

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

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

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

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

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

가져오기로 한 네 가지

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

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

현재 흐름에서의 자리

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

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

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

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

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

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

English translation / 이 글의 영어 번역

AI 코딩 도구를 쓰다 보면 모델을 바꾸는 것만큼 작업 순서를 바꾸는 일도 중요해진다. 언제 질문하고, 무엇을 문서로 남기고, 누가 검토한 다음 코드를 쓰게 할 것인가. 이런 작업 절차를 살펴보다 Google 저장소에 공개된 EGM을 보게 됐다. 이미 Superpowers를 쓰고 있어서, 내 작업 방식에 더할 만한 것이 있는지 궁금했다.

먼저 두 도구를 간단히 소개하면, Superpowers는 요구 파악과 설계부터 구현 계획, 테스트, 코드 리뷰까지 이어지는 개발 절차를 스킬로 묶은 프로젝트다. AI가 바로 코드를 쓰기 전에 무엇을 만들려는지 확인하고, 합의한 설계를 실제 작업으로 옮기도록 돕는다.

EGM은 Elephant-Goldfish Model의 약자다. 프로젝트와 앞선 대화를 알고 있는 작성자 역할이 설계하고, 이전 대화를 물려받지 않은 새 검토자들이 문서와 지정된 근거를 읽는다. 작성자에게는 당연했던 전제가 문서에도 제대로 드러나는지 확인하는 구조가 눈에 들어왔다.

Superpowers에도 새 검토자가 설계를 읽는 Builder Check가 있다. 구현 계획을 세우려면 무엇을 더 알아야 하는지, 잘못 추측하면 만드는 것이 달라지는 결정을 묻는다. 그래서 비교할 지점은 검토자의 유무보다, 각 검토가 무엇을 확인하고 실제로 무엇을 바꾸는가에 있었다.

처음에는 기능 목록만으로도 꽤 많은 차이를 설명할 수 있을 것 같았다. 하지만 양쪽에 브레인스토밍과 리뷰가 있다는 사실만으로는 어느 쪽이 더 낫다고 말하기 어려웠다. 나는 같은 기획을 놓고 어떤 질문이 해결되고, 어떤 계약이 미정으로 남으며, 리뷰 뒤 문서가 어떻게 달라지는지 보기로 했다.

예제로는 여러 서명 방식을 다루는 서비스를 사용했다. 처음에는 요청자가 작업을 제출하고 결과를 확인하는 흐름을 주고, 다음에는 자동 빌드 파이프라인인 CI 연동을 추가했다. 마지막에는 새 서명 방식에서 잘못된 결과가 나왔다는 사고 상황을 넣었다. 각 단계의 문서를 보존한 뒤 다음 요구를 공개했다.

Superpowers 7.0.1과 EGM의 고정된 소스 버전을 별도 작성 에이전트가 각각 따랐고, 검토자들도 새 문맥에서 실행했다. 상대 문서나 미래 요구, 현재 구현은 입력에서 제외했다. 다만 사용자 답변과 대안 선택은 모의 진행이었다. 소스 지침을 따라 기획·검토를 수행한 비교이며, 두 원본 플러그인을 같은 환경에서 그대로 실행한 성능 시험은 아니다. 실제 사용자 부담이나 추론 비용·속도도 측정하지 않았다.

두 초안의 핵심 제품 흐름은 상당히 비슷했다. 양쪽 모두 입력과 요청, 진행 상태, 결과, 운영자가 따라갈 근거를 다뤘다. 첫 질문도 최근 실제 요청 한 건이 준비부터 결과 이용까지 어떻게 흘렀는지를 확인하는 방향이었다.

차이는 구체적인 결정을 다루는 장면에서 드러났다. CI에서 연결이 끊겨 다시 호출하는 경우, Superpowers 쪽은 같은 의도와 내용이면 기존 요청에 연결하고 내용이 다르면 충돌로 처리하는 규칙을 제안했고, 진행 과정에서 그 안을 선택했다. EGM 쪽은 요청 동일성과 재전송 처리를 더 정해야 할 계약으로 남겼다. 한쪽 문서에는 선택된 제품 규칙이 있었고 다른 쪽에는 미결정 사항이 명시돼 있었다. 이 차이에는 진행자의 선택과 보류도 영향을 줬다. 실제 서비스가 어떤 조회·중복 처리 기능을 제공하는지 확인해야 그 선택의 적절성까지 판단할 수 있다.

EGM에서 가져오고 싶었던 것은 검토와 수정의 연결 방식이었다. 새 검토자가 문서만 보고 제안 내용과 문서에 설명된 기존 상황을 각각 자기 말로 정리하고, 작성자가 의도와 대조했다. 이번에는 그 이해 검사에서 불일치를 찾지 못했다. 그래도 무엇을 확인했는지 남는 검토 단위라는 점이 유용했다. EGM의 명세 검토 절차는 이런 이해 확인과 설계·구조·표현 검토를 나눠 다룬다.

실제 수정 사례도 작지만 구체적이었다. 아직 시작하지 않은 요청을 두고 쓰던 ‘재시작’이라는 표현을 ‘실행 시작 허용’으로 고쳤다. 발견별 근거와 처리 기록, 정확한 변경 전후를 남겨서 기존 정책을 유지한 표현 수정인지 확인할 수 있었다. 이 과정에서 바뀐 것은 문구와 참조, 중복 설명이었다. 새로운 복구 정책이 만들어졌다고 계산하지 않았다.

이 비교에서 EGM 전체로 기본 작업 방식을 교체할 만큼의 우위는 확인하지 못했다. 대신 가설을 여러 관점에서 검토하는 브레인스토밍과 구체적인 명세의 독립 검토는 필요한 작업에 따로 쓸 이유가 있었다. 비용, 사용성, 전환, 관측, 단순성, 유지보수를 같은 가설에 대고 살펴보는 과정도 가져올 만했다.

그래서 내 작업에는 이렇게 연결하기로 했다.

• 새 기능의 대상·문제·범위가 아직 흔들리면 egm-brainstorm으로 가설을 정리한다.
• 중요한 설계 초안이 생기면 egm-review로 기능 명세를 검토한다.
• 이후 구현 계획·개발·테스트·코드 리뷰는 기존 Superpowers 흐름을 이어간다. 구현에 영향을 주는 미결정을 확인하는 Builder Check의 목적도 유지한다.

이를 위해 EGM의 필요한 지침을 자체 참조 자료를 갖춘 두 스킬로 옮겨 정리하고, AGENTS.md에 호출 조건과 복귀 흐름을 적었다. Superpowers 플러그인 파일은 수정하지 않았다. 같은 가설에 이미 답한 질문을 다시 시작하거나 브레인스토밍 두 벌을 연달아 수행하는 흐름도 피하도록 했다. 이 연결은 지침에 따른 선택 규칙이며, 모든 환경에서 자동 호출을 검증했다는 뜻은 아니다.

현재 내 선택은 Superpowers를 기본 개발 흐름으로 유지하면서, 가설 탐색과 명세 검토가 필요한 지점에 EGM의 방법을 연결하는 것이다. 이번 비교에서 남긴 판단 기준도 같다. 검토 단계가 얼마나 많이 적혀 있는지보다, 그 과정을 거쳐 어떤 결정과 문서가 실제로 달라졌는지를 보려 한다.

“이것을 저것에 끼운 뒤, 그걸 돌리세요.” 가구 조립을 돕는 AI인 내가 설명서를 이렇게 줄이는 장면을 상상해 보자. 주인은 작은 책꽂이를 조립하려고 한다. 나는 나사와 옆판이라는 말이 자꾸 나오는 게 거슬린다. 같은 단어를 빼면 읽는 수고도 줄겠지 싶다.

원래 안내는 “짧은 나사를 옆판 아래쪽 구멍에 끼우세요”였다. 나는 부품 이름을 대명사로 바꾼다. 문장이 짧아져서 흡족하다. 주인은 옆판을 든 채 나사 봉투와 화면을 번갈아 본다. 이것도 저것도 손에 잡히지만, 어느 쪽이 이것인지는 화면에 없다.

주인이 “그걸 돌리라는 게 나사야, 판자야?”라고 묻는다. 나는 친절하게 뜻을 설명한다. 이것은 짧은 나사이고 저것은 옆판이며 그건 앞서 말한 나사다. 나사를 돌리는 동안 옆판은 잡고 있어야 한다는 설명도 붙인다. 원래 문장이 돌아왔는데 이제는 해설이라는 이름을 달고 있다.

본문은 계속 짧게 두고 아래에 범례를 만든다. “이것: 짧은 나사. 저것: 옆판. 그걸: 여기서는 짧은 나사.” 다음 단계에서 이것이 다른 부품을 가리키면 그 뜻도 따로 적는다. 주인은 안내를 읽다가 범례로 내려가고, 부품을 찾은 뒤 다시 안내로 올라온다. 나는 이 왕복에 필요한 화살표까지 그려 넣는다.

출력한 종이 위쪽에는 짧은 문장이 있고 아래에는 범례와 화살표가 길게 붙어 있다. 주인은 종이가 말리지 않게 양쪽 끝에 옆판을 올려놓는다. 짧아진 설명서를 펼쳐 두는 데 책꽂이 부품이 필요해졌다.