AI가 코딩을 시작하기 전, Google EGM은 설계부터 따로 검토합니다

AI와 길게 의논한 뒤 바로 코딩을 맡기면, 대화에서 정한 조건이 설계서에는 빠져 있을 수 있습니다. Google이 공개한 EGM은 구현 전에 설계 대화를 공유하지 않는 AI에게 문서를 다시 읽혀, 이런 빈틈을 찾도록 돕는 오픈소스 플러그인입니다.

저는 이 방식에서 검토자에게 전달하는 정보의 경계에 주목했습니다. 설계 대화를 모르는 AI도 문서만으로 같은 기능을 설명할 수 있는지 먼저 확인하는 것입니다.

Google이 공개한 EGM은 무엇인가요?

Google Open Source Blog는 2026년 10월 22일 Elephant-Goldfish Model(EGM) 플러그인을 공개했다고 발표했습니다. EGM은 새로운 기반 AI 모델이 아니라, AI 코딩 에이전트로 설계서를 작성하고 검토하는 오픈소스 개발 도구입니다. 발표문

이름에 등장하는 두 동물은 역할을 가리킵니다. Elephant는 프로젝트 맥락을 바탕으로 설계를 작성합니다. Goldfish는 설계 대화의 맥락을 물려받지 않고 검토합니다. 현재 README에 따르면 검토자는 설계 초안과 소스 코드를 볼 수 있습니다. 여기서 ‘맥락이 없다’는 말은 필요한 자료조차 보지 않는다는 뜻이 아니라, 설계 과정의 대화를 공유하지 않는다는 뜻에 가깝습니다. 공식 저장소

출처: Google EGM 공식 README, Google EGM contributors. 2026년 10월 23일 실제 화면에서 Goldfish·Human 설명 부분만 잘랐으며 문구는 변경하지 않았습니다. Apache License 2.0 적용 · 라이선스 전문. 썸네일은 별도 AI 제작 개념 이미지로, 실제 제품 화면이나 공식 홍보 이미지가 아닙니다.

같은 대화에서 “문제없어?”라고 묻는 것과 무엇이 다를까요?

제가 주목한 차이는 검토자의 지식이 아니라 전달하는 정보의 경계입니다. 설계에 참여한 AI에게 다시 확인을 부탁하면, 문서에 빠진 내용을 이전 대화에서 가져와 이해할 수 있습니다. 처음 읽는 검토자는 그 설명을 갖고 있지 않습니다.

이때 유용한 질문은 “이 설계가 좋은가요?”보다 “이 문서대로라면 어떤 동작을 만들겠어요?”입니다. 설명이 예상과 다르다면 구현 전에 문장을 고칠 기회가 생깁니다. 물론 새 대화에서도 AI가 빈칸을 추측할 수 있으니, 명시된 내용과 추측한 내용을 나누어 답하도록 해야 합니다.

Google의 발표문도 설계 의도를 다시 설명하게 하는 이해도 확인, 허점을 찾는 검토, 구현에 필요한 정보가 갖춰졌는지 확인하는 절차를 소개합니다. 저는 이 중 첫 단계만 적용해도 설계서를 점검하는 기준을 세우는 데 도움이 될 수 있다고 봅니다. 발표문

가상의 예약 관리 도구라면 이렇게 확인할 수 있습니다

작은 업체가 상담 예약 도구를 만든다고 가정해 보겠습니다. 아래는 이해를 돕기 위한 가상 업무 상황입니다.

처음 요구사항은 “고객이 예약을 취소하면 해당 시간을 다시 예약할 수 있게 해주세요”입니다. 문장은 간단하지만, 구현하려면 몇 가지 결정이 더 필요합니다.

• 취소 버튼을 누른 즉시 시간을 비우나요, 취소 처리가 끝난 뒤 비우나요?
• 같은 시간에 두 고객이 신청하면 누구의 예약이 확정되나요?
• 취소 요청이 실패하면 고객에게 어떤 상태를 보여주나요?
• 예약이 이미 시작된 뒤에도 고객이 직접 취소할 수 있나요?

설계자에게는 답이 있을 수 있습니다. 하지만 설계서에 적혀 있지 않다면 구현자가 추측해야 합니다. 처음 읽는 AI에게 이런 질문을 뽑아 달라고 한 뒤, 운영자가 실제 정책을 결정해 문서에 반영하는 식입니다.

중요한 것은 질문 수를 늘리는 일이 아닙니다. 취소 시점이나 예약 확정 조건처럼 서비스의 동작을 바꾸는 빈칸을 찾아 사람이 결정하는 것입니다. AI가 제안한 정책을 그대로 채택하는 단계와도 구분해야 합니다.

어떤 팀에 영향을 줄까요?

AI 코딩 도구로 업무 기능을 만드는 소규모 팀이라면, 구현 뒤 발견하던 요구사항 누락을 설계 단계에서 질문으로 꺼내는 데 활용할 수 있습니다. 현재 확인되는 변화는 이런 검토 흐름을 적용할 공개 도구가 생겼다는 점입니다. 실제 재작업이 줄어들지는 문서의 품질과 사람의 판단에 달려 있습니다. 작은 기능 하나에서 구현 전에 찾아낸 누락 조건과 구현 후 다시 고친 요구사항을 기록해 비교해 볼 만합니다.

플러그인을 설치하기 전에도 해볼 수 있는 작은 실험

당장 전체 개발 흐름을 바꿀 필요는 없습니다. 저는 기능 하나를 골라 다음 순서로 비교해 보는 편을 권합니다. 아래는 EGM의 아이디어를 참고한 간단한 수동 실험이며, 플러그인 전체 검토 절차와 같지는 않습니다.

1. 만들 기능, 하지 않을 일, 성공 조건, 오류 상황을 한 문서에 적습니다.
2. 회사의 AI 도구 사용·자료 공유 정책을 먼저 확인하고, 새 대화에는 자격증명과 고객 데이터를 제외한 설계서 및 검토에 필요한 최소한의 자료만 전달합니다.
3. “구현은 하지 말고, 이해한 동작과 문서에 없는 가정을 구분해 설명해 주세요”라고 요청합니다.
4. 답변을 읽고 실제 요구사항과 다른 부분을 설계서에서 고칩니다.
5. 사람이 확인한 문서를 기준으로 구현하고, 구현 후 테스트를 따로 진행합니다.

이 실험의 결과는 “AI가 승인했다”가 아니라, 수정한 조건과 아직 결정하지 않은 항목으로 남기는 편이 좋겠습니다. 필요한 자료를 지나치게 빼서 생긴 질문인지, 정말 문서가 모호해서 생긴 질문인지도 구별해야 합니다.

지원 범위와 한계는 따로 확인해야 합니다

10월 22일 발표문은 Antigravity를 중심으로 설명합니다. 다만 10월 23일 확인한 현재 README에는 Claude Code와 Codex 설치 방법도 올라와 있습니다. 사용할 환경의 최신 안내를 확인하는 것이 안전합니다. 저장소에는 Google이 공식 지원하는 제품이 아니라는 점도 명시되어 있습니다. 공식 README

또한 대화를 분리했다고 AI가 독립적인 전문가가 되거나, 설계의 오류를 모두 찾는 것은 아닙니다. 검토 횟수를 늘리면 시간과 모델 사용 비용도 더 들 수 있습니다. 이번 공개만으로 개발 속도나 결함 감소 효과가 보장됐다고 받아들일 근거는 없습니다.

구현 이후의 검토도 그대로 필요합니다. 설계서와 일치하는 코드라도 실제 환경에서 잘못 동작할 수 있기 때문입니다. 이 단계는 앞서 정리한 AI 코드 리뷰와 검증 흐름으로 이어집니다.

이번 소식에서 제가 가져갈 질문은 하나입니다. “이 설계서를 처음 읽는 AI도, 제가 만들려는 기능을 같은 방식으로 설명할 수 있을까요?” 코드를 쓰기 전에 그 답부터 확인해 보는 것입니다.

저는 설계에 참여하지 않은 AI가 문서를 어떻게 이해하는지 확인하는 단계에 주목합니다. 질문을 많이 만드는 것보다, 실제 동작을 바꾸는 누락 조건을 찾아 사람이 결정하는 편이 중요하다고 봅니다.