🐘Elephant-Goldfish Model (EGM)

llm
agentic
multi-agent
design-review
spec-driven-development
egm.dev와 google/elephant-goldfish-model 저장소 해설. 맥락을 다 가진 에이전트로 설계하고, 맥락이 없는 subagent로 검토하는 Google의 오픈소스 코딩 에이전트 plugin
Published

October 25, 2026

“Design with an elephant. Review with a goldfish.”는 egm.dev 첫 화면의 제목입니다. 논문이나 에세이 제목이 아니라 Google이 Apache 2.0으로 공개한 코딩 에이전트용 plugin, Elephant-Goldfish Model(EGM)의 표어입니다. 이 글은 사이트, 사이트가 링크하는 GitHub 저장소 google/elephant-goldfish-model, 발표 글인 Google Open Source Blog 포스트를 읽고 정리했습니다. 저장소는 실행하지 않고 파일을 정적으로만 읽었습니다.

한 줄로 말하면

EGM은 “설계 문서를 쓰는 AI”와 “그 문서를 검토하는 AI”를 서로 다른 맥락에서 돌리게 만드는 Markdown 기반 skill 묶음입니다. 설계자(Elephant)는 프로젝트 이력과 대화를 모두 기억하고, 검토자(Goldfish)는 대화 기록 없이 새로 띄운 subagent라서 문서에 적힌 것만 봅니다. 문서만 읽고 이해가 안 되면, 그 문서는 아직 덜 쓴 것입니다.

이름은 두 동물의 기억력에서 왔습니다. 저장소 문서는 “The Elephant remembers everything.”, “Goldfish have three-second memories”라고 쓰고, 금붕어의 3초 기억이 사실은 속설이라는 각주까지 달아 둡니다(“It’s a myth … But that would ruin the metaphor!”). 그리고 세 번째 주체로 사람을 둡니다. “Humans own the outcomes.”


egm.dev 첫 화면(필자가 헤드리스 Chrome으로 캡처, 2026-10-30). 부제는 “Thousands of Google engineers use this open-source plugin to draft specs with deep-context agents and stress-test them with zero-context subagents before writing code.”입니다. 버튼은 설치 프롬프트를 클립보드에 복사합니다.

0. 읽은 자료와 처리 방식

자료 무엇인가 이 글에서의 처리
egm.dev Astro로 만든 한 페이지짜리 소개 사이트. 저장소 site/ 폴더에 소스가 있음 HTML 본문 전체를 읽고, 헤드리스 Chrome으로 캡처해 절별로 잘라 넣음
GitHub 저장소 plugin 본체. skill 7개, reviewer persona 9개, 문서 기준(rubric) 5개, 설계 문서, 테스트 git clone(15 MB) 후 정적으로 읽음. 실행·설치하지 않음
Google Open Source Blog 발표 글 (2026-10-22) 공개 발표. 저자 Brian Suchy, Jim Quinn, Elise Ewing, Oliver Newth, Dave Rensin 본문 요약, 수명주기 그림 1장 사용
Dave Rensin의 Medium 에세이 EGM의 원래 생각을 적은 글. 사이트·저장소가 모두 “먼저 읽으라”고 권함 본문을 읽지 못함(접근 시 HTTP 403). 아래 Google Research 목록의 초록 요약과 저장소 문서의 인용으로만 다룸
Google Research 출판물 목록 같은 제목의 2026년 출판물. 저자 Dave Rensin. PDF 링크 없음 초록 요약만 사용
GitHub API 저장소 메타데이터 별·포크·이슈·릴리스 수치(조회 시점 값)

사이트에도, 블로그 글에도, 저장소에도 시연 영상은 없었습니다. 웹 검색으로도 EGM 관련 영상은 찾지 못해서 영상 임베드는 없습니다.

1. 지금 공개된 것과 공개되지 않은 것

이 글을 읽기 전에 사실관계를 먼저 정리합니다. “확인” 열이 “확인 못 함”인 항목은 본문에서 단정하지 않았습니다.

항목 상태 근거
plugin 소스 전체(skill·persona·rubric·설계 문서·테스트) 공개, Apache 2.0 저장소 LICENSE, plugin.json
첫 릴리스 v0.1.0 공개, 2026-10-27 게시. 서명된 ZIP 2종 + SHA256SUMS GitHub releases API, docs/releases.md
지원 호스트 Antigravity, Claude Code, Codex는 자동 fixture 통과. Claude Cowork, ChatGPT Work는 설치되지만 검증 공백이 열려 있음(#105, #106). omp는 커뮤니티 설치 확인만 docs/harnesses.md, TESTING.md
“수천 명의 Google 엔지니어가 사용” 주장만 있음. 사이트·README는 “Thousands of Google engineers”, 블로그는 “thousands of Googlers … every day”. 구체적 숫자나 측정 방법은 없음 확인 못 함
EGM이 품질·속도를 올린다는 정량 근거 공개된 것 없음. 저장소 FAQ가 스스로 “Completing the EGM workflow alone does not demonstrate a productivity improvement.”라고 씀 docs/faq.md
Google 내부판과 공개판의 차이 알 수 없음. 설계 문서 날짜는 2026-06~07인데 공개 git 이력은 2026-10-21 “initial open-source release” 커밋에서 시작함. 내부 이력은 합쳐져서 공개되지 않음 docs/designs/*.md 날짜, git log
Rensin 에세이 본문 공개돼 있지만 필자는 읽지 못함 Medium 403
1.0 계약(skill 이름·인자·출력 경로·보고서 형식 고정) 예정. pre-1.0이라 minor 버전에서 호환이 깨질 수 있다고 명시 docs/releases.md
다른 개발 환경 지원 확대 예정. 발표 글이 “other development environments planned”라고 씀. docs/releases.md는 Cursor 어댑터(.cursor-plugin/plugin.json)를 “present일 때” 맞추라고 언급하지만 그 파일은 저장소에 없음 발표 글, docs/releases.md
릴리스·패키징·skill 아이콘 설계 문서 Draft 상태. 세 문서 모두 “Maintainer scope approval … pending” docs/designs/releases.md 등

저장소 규모(2026-10-30 GitHub API 조회): 별 5,852, 포크 357, 열린 이슈 58, 기여자 14명, 커밋 108개. 공개 이력은 10일 남짓인데 커밋의 절반 이상(84개)이 10월 24~26일 사흘에 몰려 있습니다. 공개 직후 바쁘게 다듬는 중인 프로젝트입니다.

2. 아이디어: 설계는 맥락으로, 검토는 맥락 없이

2.1 문제 설정

저장소의 docs/designs/architecture.md는 대화형 AI 코드 생성이 겪는 실패를 네 가지로 정리합니다.

실패 유형(원문) 뜻 EGM의 대응
Hallucination Cascades & Context Pollution 한 스레드가 인터뷰·설계·구현을 다 하면 추측이 맥락에 쌓이고, 모델이 자기 가정을 스스로 승인함 설계자와 검토자의 맥락을 분리(Goldfish)
Premature Implementation (“Weeds Syndrome”) 코딩 에이전트가 구조를 생각하기 전에 근처 파일부터 고침 설계 단계에서는 코드를 쓰지 않음(“No Code” rule), Zoom Out 검토
Chat Dump Fatigue 긴 설계·리뷰를 채팅창에 쏟아 대화 이력을 더럽힘 모든 긴 산출물을 파일(artifact)로 씀
Documentation Drift 설계 문서가 코드가 바뀌면서 낡음 설계 문서를 docs/designs/에 커밋하고 /egm-drift-report로 주기 점검

핵심은 첫 줄입니다. 같은 맥락 창이 문서를 쓰고 검토하면, 모델은 자기가 기억하는 것을 문서에도 적었다고 착각합니다. docs/designs/review.md의 표현으로는 “The model assumes the context it holds in memory is obvious from the text”입니다. 사람도 자기가 쓴 글의 빈틈을 못 보는 것과 같은 현상입니다.

2.2 세 주체


저장소의 og 이미지(site/public/og.png). Elephant는 “Remembers everything”, Goldfish는 “Remembers nothing”입니다. 파란 코끼리와 주황 금붕어 로고는 EGM의 색 체계 전체(Elephant 계열 skill은 파랑, Goldfish 계열 skill은 주황)로 이어집니다.

egm.dev의 “Design with context. Review with fresh eyes.” 절(필자 캡처). Goldfish 설명이 “read only the draft spec and live source code, without conversation bias”라는 점이 중요합니다. Goldfish가 아무것도 모르는 것이 아니라, 대화를 모르는 것입니다.
역할 보는 것 하는 일
Elephant 프로젝트 이력, 요구사항, 이전 결정, 대화 전체 문제를 파고들고 설계 문서를 씀. 검토 결과를 받아 고칠지 반박할지 정함
Goldfish 대상 문서, 그 문서가 링크한 파일, 선택적으로 주어진 읽기 목록(GoldfishContext). 대화 기록은 못 봄 빠진 가정, 정의 안 된 용어, 구현 위험을 찾음. 읽기 전용
사람 중요한 목표와 제약 trade-off를 정하고 설계를 승인하고, 사람 동료 리뷰(PR)를 받음

에세이에 대해 필자가 확인할 수 있었던 것은 Google Research 목록의 초록뿐입니다. 초록 요약에 따르면 에세이는 세 갈래를 다룹니다. AI를 도구로 쓰는 법(가정을 묻고 채점 기준을 세우는 반복 대화, 최종 판단은 사람), Elephant-Goldfish 모델(긴 대화로 코드 전에 설계 문서를 만들고, 기억 없는 새 세션이 그 문서를 이해해야 코드를 요청), 그리고 일의 미래(여러 AI 조수를 관리하는 위임 능력). 발표 글은 에세이의 한 문장 “Design is the new code.”를 인용합니다.

3. 워크플로: 아이디어에서 검증된 설계 문서까지


Google Open Source Blog 발표 글의 수명주기 그림. Phase 1 Growing the Elephant(/egm-brainstorm), Phase 2 Drafting with the Elephant(/egm-draft), Phase 3 The Goldfish Protocol(/egm-review). 금붕어 셋은 Comprehension Check, Hostile Critic, Implementation Readiness입니다. 이 그림은 검토를 세 단계로 그리지만, 실제 skill은 다섯 단계를 돕니다(3.3절).

egm.dev의 “Go from an idea to a verified spec.” 절(필자 캡처). Brainstorm → Draft → Review 다음에 “Once you approve the spec, ask your coding agent to build it.”이 오고, 구현 뒤에 Check for drift가 붙습니다. 구현 자체는 EGM의 skill이 아닙니다.

3.1 /egm-brainstorm: 아이디어를 가설로

Elephant가 사용자에게 열린 질문을 여러 턴 던져 문제를 좁힙니다. 객관식 선택지를 주는 것은 금지입니다(“STRICTLY FORBIDDEN from using structured question tools … during open-ended questioning”). 문제·제약·성공 기준이 정리되면 2~3문장의 가설을 보여 주고, 사용자가 “Review with Goldfishes”를 고를 때만 subagent를 띄웁니다. 그 전에 띄우는 것도 금지입니다.

검토는 6개 관점의 Goldfish를 병렬로 띄워 합니다. 순서대로 돌리면 앞 검토가 뒤 검토를 끌고 간다는 이유입니다. 흥미로운 점은 이 6개 관점이 별도 persona가 아니라, 문서 검토용 persona들의 Mode: BRAINSTORM 분기라는 것입니다. persona 파일을 열어 대응시키면 다음과 같습니다.

관점(SKILL.md 표) 실제로 띄우는 persona 던지는 질문(원문 요약)
Contrarian / YAGNI zoom_out 이게 꼭 있어야 하나? 기존 라이브러리·서비스로 90%가 해결되지 않나?
Cost, Quota & Token Economics design_critic 최대 QPS, 메모리, DB 부하, LLM 토큰 예산은?
UX & Developer Ergonomics comprehension API·CLI가 관례에 맞나? 에러 메시지가 행동 가능한가?
Migration & Backward Compatibility implementation_readiness 기존 데이터·클라이언트는 어떻게 옮기나? 중간 롤백은?
Observability & SRE Debuggability codebase_details 새벽 3시에 on-call이 어떻게 장애를 추적하나?
Long-Term Tech Debt & Maintenance structural 2년 뒤 유지보수 부담이 되는 강한 결합은 없나?

이름과 역할이 잘 안 맞는 대응(예: 문서 형식을 보는 structural이 brainstorm에서는 기술 부채를 봄)은 persona 수를 늘리지 않으려고 기존 파일에 모드를 덧붙인 결과로 보입니다(✍️ 필자 해석). 결과물은 concepts_brief.md이고, 개요·분석·Goals/Non-Goals·기각한 대안·핵심 결정을 담습니다. 기각한 대안을 따로 적게 하는 이유는 “/egm-draft copies these into Alternatives Considered and has no other source for them”, 즉 다음 단계가 이 정보를 얻을 곳이 여기뿐이기 때문입니다.

3.2 /egm-draft: 절 단위로 승인받으며 설계 문서 작성

brief를 받아 docs/designs/<feature>.md를 씁니다. 개요·목표·문제 → 기술 계획 → 대안 → 구현 계획 순으로 한 절씩 쓰고 채팅에서 피드백을 받은 뒤 다음 절로 갑니다. 템플릿(design_doc.md)에서 눈에 띄는 칸은 두 가지입니다.

  • Open Questions: 아직 답이 없는 질문을 세션을 넘어 남겨 둡니다. 템플릿 주석은 “preserve conversational memory and prevent future sessions from re-asking questions”라고 씁니다. 대화가 끝나면 사라지는 Elephant의 기억 일부를 문서로 옮기는 장치입니다.
  • Critical User Journeys(CUJs): Given/When/Then 형식으로 기대 동작을 적습니다.

문서 끝의 ## Detailed Implementation Plan 헤더가 중요한 경계입니다. /egm-review는 이 헤더를 기준으로 문서를 위쪽 FeatureRange(구조)와 아래쪽 DetailedRange(구현 계획)로 나누고, 단계마다 다른 범위를 검토시킵니다.

3.3 /egm-review: 다섯 단계 Goldfish 검토

발표 글과 사이트는 검토를 세 가지(이해도 확인, 적대적 비평, 구현 준비도)로 소개하지만, skills/egm-review/SKILL.md가 실제로 정의하는 것은 다섯 단계입니다. 앞의 Step 1~4는 Elephant가 하는 준비(입력 확인, 실행 모드 선택, 경계 찾기, 배치)라서 검토 단계 번호가 5부터 시작합니다.


/egm-review의 실제 실행 순서(필자가 SKILL.md와 persona 파일을 읽고 그린 개념도, v0.1.0 기준). 위 줄이 단계, 아래 상자가 그 단계에서 띄우는 Goldfish persona와 검토 범위·기준입니다. Stage 7과 9의 결과만 Elephant 쪽 /egm-resolve로 넘어갑니다.
단계 Goldfish persona(역할명) 검토 범위 기준 문서 보는 것
5 Zoom Out zoom_out(Skeptical Architect) 문서 전체 zoom-out-standard 근본 문제를 푸는가, YAGNI, 기존 코드 재사용, 고도 조절(구조 절에 코드 세부가 섞이지 않았나)
6 Comprehension comprehension(Naive Reader) Feature + Detailed 없음 먼저 문서를 자기 말로 다시 설명하고, 못 하는 절은 Blocker. 정의 안 된 용어·전제
7 Critic design_critic, structural, style FeatureRange feature-spec-standard 단일 장애점, 규모 한계, 실패 모드, 형식, 문체
8 Zoom Out(2차) zoom_out 문서 전체, 6·7단계에서 새로 붙은 부분 위주 zoom-out-standard 비평에 대응하느라 덧붙인 방어적 과잉 설계 걷어내기
9 Implementation Readiness implementation_readiness, codebase_details, style DetailedRange implementation-readiness-standard 바꿀 파일 목록, 실제 코드와 맞는 함수 시그니처, 검증 단계. 구현자에게 설계 결정을 떠넘기지 않았나

몇 가지 설계가 눈에 띕니다.

  • Stage 6의 “다시 설명하기”: Comprehension persona는 결함 목록을 내기 전에 What this proposes와 How the existing system works, per this document를 2~5문장씩 씁니다. 근거는 persona 파일의 한 문장입니다. “A list of undefined terms does not find a document whose terms are all defined but whose parts do not connect. The paraphrase does.” 용어가 모두 정의돼 있어도 조각들이 이어지지 않는 문서는 용어 검사로는 못 잡지만, 요약을 시켜 보면 드러난다는 것입니다. 그래서 이 단계만 synthesizer를 거치지 않고 직접 띄웁니다. synthesizer는 결함만 남기고 요약을 버리기 때문입니다.
  • Stage 8이 따로 있는 이유: 비평가가 “이런 실패는 어떻게 할 거냐”고 물으면 저자는 방어 장치를 덧붙이고, 문서는 비대해집니다. 그래서 비평 뒤에 Zoom Out을 한 번 더 돌려 그 추가분만 다시 봅니다. 단 1차에서 이미 받아들인 결정은 다시 지적하지 않게 합니다.
  • 호출 방식: Stage 5~9는 서로 의존하므로 다중 선택을 막고(“to protect topological dependencies (5 → 6 → 7 → 8 → 9)”), 실행 모드를 4개 중 하나로 고르게 합니다(단계마다 멈추는 대화형, 끝까지 돌리고 통합 보고서 하나를 쓰는 모드, 구조만, 구현 계획만).
  • synthesizer: 여러 Goldfish를 병렬로 띄우고 결과를 🔴 Blocker / 🟡 Major / 🟢 Nit로 묶어 중복을 제거한 보고서를 씁니다. 선택적으로 같은 reviewer를 A·B 두 개 띄워 재현율을 높일 수 있습니다. 실패하거나 시간 초과된 reviewer는 한 번 재시도하고, 그래도 실패하면 not run으로 표시하며, “지적 0건”으로 세지 말라고 명시합니다.

3.4 /egm-resolve: 검토 결과를 Elephant가 처리

검토 결과는 대화를 기억하는 Elephant 맥락으로 돌아옵니다. Elephant는 지적마다 네 가지 중 하나를 붙입니다.

분류 뜻 제약
PROPOSE FIX 맞는 지적. 정확한 수정안을 만듦
CONTEST 틀린 지적. 반박 근거를 댐 근거는 Goldfish도 읽을 수 있는 것(파일과 심볼, 문서에 적힌 결정)이어야 함. 이해도 지적은 반박 불가
ESCALATE 틀렸지만, 문서 밖 지식으로만 반박 가능 사용자가 결정. Elephant는 Goldfish만을 위한 맥락을 문서에 덧붙이지 않음
DECLINE Nit. 기록만 하고 고치지 않음

CONTEST의 제약이 EGM의 원리를 잘 보여 줍니다. Elephant가 “그건 우리가 대화에서 이미 정했어”라고 반박할 수 있으면 Goldfish 검토는 의미가 없어집니다. 그래서 반박도 문서와 코드 안의 근거로만 하게 하고, 이해도 지적(“이 부분을 이해 못 하겠다”)은 아예 반박할 수 없게 합니다. 독자가 이해 못 했다는 사실 자체가 결함이기 때문입니다.

반복 종료 규칙은 egm-review-loop에 있습니다. Blocker·Major가 없는 라운드를 “clean”으로 보고, clean 라운드 2회 연속이면 수렴, 5라운드가 상한입니다. 새 지적이 이전 수정을 되돌려야 풀리는 경우(진동)에도 사용자에게 묻습니다. 사용자는 지적을 일괄 수락, 하나씩 대화, artifact에 인라인 댓글(권장), 중간에 질문 끼워 넣기 중 하나로 처리합니다.

3.5 그 밖의 skill


egm.dev의 “Included skills” 절(필자 캡처). 파란 아이콘(Brainstorm·Draft·Resolve·Bootstrap)이 Elephant 쪽, 주황 아이콘(Review·Review loop·Drift Report)이 Goldfish·점검 쪽입니다.
skill 하는 일 SKILL.md 길이
/egm-brainstorm 아이디어를 질문으로 좁히고 6관점 Goldfish로 검토해 concepts_brief.md 작성 264줄
/egm-draft brief를 절 단위 승인 방식으로 설계 문서로 314줄
/egm-review 위 다섯 단계 검토 지휘 402줄
/egm-review-loop 지정한 reviewer 묶음을 병렬로 돌리는 반복 구동기. 설계 문서 외에 README 등에도 사용 191줄
/egm-resolve 지적 분류와 수정 적용 187줄
/egm-drift-report 커밋된 설계 문서·README와 현재 코드를 비교해 차이만 YYYY-MM-DD_DRIFT_REPORT.md로 보고 67줄
/egm-bootstrap 기존 코드베이스에 디렉터리별 README를 아래에서 위로 생성. 말단 README는 “Peanuts”, 상위 요약은 “Hay”라고 부름 427줄

/egm-bootstrap은 Elephant의 기억을 미리 만들어 두는 도구로 읽힙니다. Elephant가 프로젝트를 “다 기억”하려면 그 기억이 어딘가에 값싸게 읽을 수 있는 형태로 있어야 하고, 저장소 문서도 “We need to make all of this information available to LLMs in a way they can navigate cheaply”라고 씁니다. 공개 후 일주일 만에 들어온 커밋 05f8984(#109)가 바로 이 skill의 환각 문제를 고친 것입니다. 파일·디렉터리 이름만 보고 RPC·enum·불변식을 지어내지 못하게, 모든 항목에 [file:symbol] 인용을 강제했습니다.

4. 저장소 구조: 코드가 아니라 프롬프트와 기준 문서

EGM에는 실행 코드가 거의 없습니다. 사용자 쪽에서 동작하는 것은 전부 Markdown이고, Python은 패키징·릴리스 스크립트와 테스트뿐입니다. docs/privacy.md도 “The runtime package does not operate a hosted service, database, analytics client, or telemetry endpoint”라고 밝힙니다. 모델 호출은 사용자가 쓰는 호스트(Claude Code, Codex 등)의 계정으로 갑니다.

경로 내용
skills/egm-*/SKILL.md skill 7개의 본문. 각 폴더에 TEST.md, test_scenarios.yaml, 아이콘, Codex용 agents/openai.yaml
agents/*.md Goldfish persona 7개 + synthesizer + bootstrap orchestrator = 9개. 호스트 중립 원본
.claude-plugin/agents/*.md Claude Code용 얇은 어댑터. 원본 persona를 읽으라고 지시하고 도구·맥락만 제한
resources/document_standards/ 검토 기준 5개: feature-spec, implementation-readiness, zoom-out, heilmeier, re-implementation
docs/designs/ EGM 자신의 설계 문서(EGM 방식으로 작성). architecture, review, brainstorm, draft, bootstrap 등
distributions/claude/ Claude용으로 패키징한 사본(scripts/pack_plugin.py가 생성)
tests/unit/ 매니페스트 일관성, 링크 무결성, 표 형식, SKILL.md 크기 제한(24,000바이트) 등 정적 검사
site/ egm.dev의 Astro 소스와 스크린샷

Goldfish의 “맥락 없음”이 실제로 어떻게 구현되는지는 Claude Code 어댑터에서 보입니다. 예를 들어 .claude-plugin/agents/comprehension.md의 frontmatter는 tools: [Read, Grep, Glob], omitClaudeMd: true입니다. 쓰기 도구가 없고, 프로젝트의 CLAUDE.md도 읽지 않습니다. 그리고 subagent를 띄울 수 없는 호스트에서는 검토를 멈추라고 skill마다 적혀 있습니다. “a review in the same context is not a Goldfish review.”

호스트별 검증 기록(TESTING.md의 Harness Test Record, 모두 2026-10-22~27)은 다음과 같습니다.

호스트 Brainstorm Draft Review 비고(원문 요약)
Antigravity CLI 1.4.5 Pass Pass Pass native reviewer 16개 실행, 5~9단계 순서 확인. bootstrap은 크기 제한 초과로 미검증
Claude Code 2.1.308 Pass Pass Pass after fix 처음엔 단계 순서 실패, 수정 후 재실행 통과
Claude Cowork 복구 후 완료 완료 부분(5~7단계) 사용량 한도로 8단계에서 중단
OpenAI Codex 0.163.0 Pass Pass Pass live 테스트 2개 573초, native reviewer 15개
ChatGPT Work 완료 완료 reviewer 9개 완료 격리 확인 probe가 UNKNOWN 반환
omp v18.12.6 미실행 미실행 미실행 커뮤니티 설치 확인만

이 표의 “Pass”는 워크플로가 끝까지 정해진 순서로 돌았는지를 보는 것이지, 검토가 좋은 지적을 했는지를 보는 것이 아닙니다. test_scenarios.yaml도 열어 보면 “이 문구가 출력에 있어야 한다/없어야 한다”는 정규식 단언입니다. docs/designs/review.md는 이 파일을 “Benchmark test suite evaluating model review precision and recall”이라고 부르지만, 필자가 본 시나리오들은 precision/recall을 계산하는 구조가 아니었습니다.

5. 비판적으로 보면

강점

  • 원리가 단순하고 옮겨 쓰기 쉽습니다. 핵심은 “쓴 맥락과 읽는 맥락을 분리하라” 한 문장이고, plugin 없이도 새 채팅 창에 문서만 붙여 넣으면 흉내 낼 수 있습니다. 저장소의 getting started도 처음엔 도구 없이 대화 순서만 몇 번 따라 해 보라고 권합니다.
  • “다시 설명하기” 테스트는 체크리스트형 검토의 빈틈을 정확히 짚습니다. 용어가 다 정의돼 있어도 논리가 이어지지 않는 문서를 잡는 방법으로 설득력이 있습니다.
  • 반박에도 규칙이 있습니다. CONTEST는 Goldfish가 읽을 수 있는 근거로만 가능하고, 이해도 지적은 반박할 수 없습니다. 설계자가 대화 맥락으로 검토를 무력화하는 길을 막습니다.
  • 과잉 설계를 되돌리는 단계(Stage 8)가 있습니다. 비평 → 방어 장치 추가 → 비대화로 이어지는 흔한 흐름을 제도로 끊습니다.
  • 실패를 성공으로 세지 않는 규칙이 곳곳에 있습니다. 실패한 reviewer는 not run, 읽기 요청만 하고 결과가 없으면 읽은 것이 아님(TESTING.md), subagent가 없으면 검토 중단.
  • 스스로의 한계를 적습니다. FAQ는 작은 버그 수정에는 쓰지 말라고 하고, 설계 문서가 늘면 사람 리뷰가 병목이 될 수 있다고 인정하며, 워크플로를 마친 것만으로는 생산성 향상이 증명되지 않는다고 씁니다.

약점과 한계

  • 효과에 대한 정량 근거가 공개돼 있지 않습니다. “수천 명의 Google 엔지니어”는 숫자도 측정 방법도 없는 주장이고, 결함 발견률·재작업 감소·소요 시간 같은 수치는 어디에도 없습니다. architecture.md의 대안 비교도 직접 생성 방식이 “higher comment density per kLOC”를 낳는다고 쓰지만 수치는 없습니다.
  • Goldfish의 독립성은 맥락 독립성이지 모델 독립성이 아닙니다. 검토자는 대개 같은 호스트의 같은 모델 계열입니다(Claude 어댑터는 model: inherit). 대화로 생긴 편향은 끊지만, 모델이 공통으로 가진 맹점은 그대로 공유할 수 있습니다. 블로그의 RDA 리뷰에서 저자들이 생성기와 평가기를 다른 모델로 둔 이유를 “to mitigate potential bias between the generator and evaluator”라고 밝힌 것과 비교됩니다(✍️ 필자 의견).
  • “맥락 없음”의 경계가 실제로는 흐립니다. Goldfish는 문서가 링크한 파일과 GoldfishContext 읽기 목록을 읽습니다. 그 목록을 누가 고르느냐(Elephant 또는 사용자)에 따라 검토자가 보는 세계가 달라지고, 링크를 많이 걸수록 문서의 자기완결성 검사는 약해집니다.
  • 검토 비용이 큽니다. 한 번의 전체 검토가 5단계, 단계당 최대 3개 reviewer, 선택 시 A·B 중복, resolve 반복 최대 5라운드입니다. Antigravity 기록에서 native reviewer 16개, Codex에서 live 테스트 2개에 573초가 걸렸습니다. 토큰 비용 수치는 공개되지 않았습니다. 사이트는 “Go from an idea to a verified spec”이라고 쓰지만, 여기서 “verified”는 Goldfish들이 지적을 더 내지 않았다는 뜻이지 설계가 맞다는 증명이 아닙니다.
  • 문서와 skill 사이의 drift가 이미 있습니다. drift 검출을 기능으로 내세우는 프로젝트라서 더 눈에 띕니다. 필자가 v0.1.0 이후 커밋(f0ba151, 2026-10-28)에서 확인한 것은 다음과 같습니다.
문서의 서술 실제 skill·persona 위치
architecture.md: 검토는 “4-tier evaluation pipeline”, Step 5~8(8 = Implementation Readiness) egm-review SKILL.md: 5단계, Step 5~9(8 = 2차 Zoom Out, 9 = Readiness) docs/designs/architecture.md Phase 3
review.md: Stage 7 기준에 heilmeier-standard 포함, Stage 9 기준에 re-implementation-standard 포함 SKILL.md는 Stage 7에 feature-spec-standard만, Stage 9에 implementation-readiness-standard만 넘김. heilmeier는 어느 skill에서도 기본으로 쓰지 않음 docs/designs/review.md Stage Breakdown
발표 글·사이트: 검토는 세 가지 확인 다섯 단계(Zoom Out 두 번 포함) 발표 글 Phase 3
egm-review는 단계당 재검토 최대 1회 egm-review-loop는 clean 라운드 2회 연속 수렴, 상한 5라운드 두 상한이 어떻게 겹치는지는 문서에서 확인 못 함

어느 쪽이 의도인지는 알 수 없습니다. 내부에서 쓰던 문서가 공개 정리 중에 skill만 먼저 바뀌었을 가능성이 있습니다(✍️ 필자 추정).

  • 프롬프트 규칙이 매우 강하고 많습니다. brainstorm·draft·review skill 앞부분에 “STRICTLY FORBIDDEN”, “MUST”가 붙은 실행 규칙이 각각 13·13·11개 있고(아첨 금지, 사과 금지, 특정 형용사 금지, 한 턴에 질문 하나 등), 거의 같은 블록이 세 파일에 복사돼 있습니다. 모델이 이 규칙을 얼마나 지키는지는 정규식 테스트로 일부만 확인됩니다. SKILL.md 크기 제한(24,000바이트) 테스트가 따로 있다는 것 자체가 프롬프트가 커지는 압력을 보여 줍니다.
  • pre-1.0입니다. skill 이름·인자·출력 경로·보고서 형식이 아직 고정되지 않았고, minor 버전에서 호환이 깨질 수 있습니다.

6. 블로그의 다른 글과 이어 보기

같은 원리, 즉 “새로 띄운 맥락이 문서만 보고 일을 해낼 수 있어야 그 문서가 쓸모 있다”는 생각은 로봇 쪽 에이전트 연구에도 나옵니다.

  • ASPIRE 리뷰: 코딩 에이전트가 로봇 프로그램을 고치며 배운 것을 텍스트 skill로 쌓는데, skill을 등록하려면 새로 띄운 검증자 액터가 제안문만 보고 원래 과제를 다시 풀어야 합니다. EGM의 Comprehension 단계와 구조가 같습니다. 그 리뷰에서 짚었듯이 ASPIRE 코드의 README는 이 검사가 “passing shows the text transmits, not that it transfers”라고 스스로 한계를 적는데, EGM의 Goldfish 통과에도 똑같이 적용되는 말입니다. 문서가 전달된다는 것이지, 설계가 맞다는 것은 아닙니다. ASPIRE가 액터끼리 대화 이력을 주고받지 않게 해 맥락 오염을 막는 설계도 EGM과 같은 발상입니다.
  • RDA(Reward Design Agent) 리뷰: 생성기와 평가기를 다른 모델로 분리해 편향을 줄이려 한 사례입니다. EGM은 맥락을 분리하고, RDA는 모델을 분리합니다.
  • RF-Agent 리뷰: LLM 에이전트가 보상 함수 코드를 쓰고 결과를 보며 고치는 반복 구조입니다. 생성과 평가가 한 루프 안에 있을 때 무엇이 평가 신호가 되는지 비교해 볼 만합니다.

요약

EGM이 무엇인가. Google이 2026년 10월 Apache 2.0으로 공개한 코딩 에이전트 plugin입니다(v0.1.0, Antigravity·Claude Code·Codex 등 지원). 실체는 Markdown skill 7개, reviewer persona 9개, 검토 기준 문서 5개입니다. Dave Rensin의 에세이 “Elephants, Goldfish, and the New Golden Age of Software Engineering”의 생각을 도구로 만든 것입니다.

핵심 아이디어. 설계 문서는 맥락을 다 가진 Elephant가 사용자와 대화하며 쓰고, 검토는 대화 기록 없이 새로 띄운 읽기 전용 Goldfish subagent들이 합니다. 검토는 Zoom Out → 이해도(다시 설명하기) → 비평 → 2차 Zoom Out → 구현 준비도의 다섯 단계이고, 결과는 Elephant가 고침·반박·상향·기각으로 처리합니다. 반박은 Goldfish도 읽을 수 있는 근거로만 할 수 있습니다. 승인된 설계 문서는 저장소에 커밋되고, 구현 뒤에는 drift report로 코드와 비교합니다.

보이지 않는 것. 효과에 대한 정량 근거는 공개돼 있지 않고, “수천 명의 Google 엔지니어”는 검증할 수 없는 주장입니다. 테스트는 워크플로가 정해진 순서로 도는지를 확인할 뿐 검토 품질을 재지 않습니다. Goldfish는 대화 맥락에서는 독립적이지만 모델은 같을 수 있습니다. 공개 열흘 만에 이미 설계 문서와 skill 사이에 몇 군데 어긋남이 있습니다.

참고 링크

이 글에 대해

이 글은 논문 리뷰가 아니라 공개 웹 자료와 오픈소스 저장소를 읽고 정리한 글입니다. 출처는 egm.dev, 그 사이트가 링크하는 GitHub 저장소(main 브랜치, 커밋 f0ba151, 2026-10-28), Google Open Source Blog 발표 글, Google Research 출판물 목록 페이지입니다. 저장소는 clone해서 파일을 읽기만 했고, plugin을 설치하거나 skill을 실행하지는 않았습니다. 따라서 이 글의 동작 설명은 skill과 persona 파일에 적힌 지시를 옮긴 것이고, 모델이 실제로 그 지시대로 움직이는지는 확인하지 않았습니다.

확인하지 못한 것: Dave Rensin의 Medium 에세이 본문은 접근이 막혀(HTTP 403) 읽지 못했습니다. 에세이 내용은 Google Research 목록의 초록 요약과 저장소·발표 글의 인용으로만 다뤘습니다. “수천 명의 Google 엔지니어가 사용한다”는 주장, Google 내부판과 공개판의 차이, 효과에 대한 정량 수치는 공개 자료에서 확인할 수 없었습니다. 시연 영상은 찾지 못했습니다.

표기 규칙: 인용문(기울임)은 원문 그대로입니다. “✍️ 필자”가 붙은 문장과 5절의 평가는 필자의 해석입니다. 별·포크·이슈 수 같은 저장소 수치는 조회 시점의 값이라 이후 바뀝니다.

조회 시점: 2026-10-30. 이 글의 게시 날짜(2026-10-25)는 블로그의 날짜 배정 규칙에 따른 것이고, 실제 조회와 작성은 2026-10-30에 했습니다. 그래서 2026-10-25 이후에 나온 v0.1.0 릴리스(10-27)와 그 뒤 커밋도 반영돼 있습니다.