늘모자란, 개발분류

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의 방법을 연결하는 것이다. 이번 비교에서 남긴 판단 기준도 같다. 검토 단계가 얼마나 많이 적혀 있는지보다, 그 과정을 거쳐 어떤 결정과 문서가 실제로 달라졌는지를 보려 한다.