▲

Show GN: 여러 AI 코딩 에이전트를 단일/다중 코드베이스에서 같이 굴릴 때 쓰는 AGENTS.md 시드 프롬프트 (EstreGenesis)

 (github.com/SoliEstre)
1P by soliestre 1일전 | ★ favorite | 댓글 4개

한 프로젝트에

  • Claude Code
  • Cursor
  • GitHub Copilot
  • Gemini (Antigravity)
  • Cline
  • Windsurf
  • Continue

같은 AI 코딩 에이전트를 토큰 분산(비용 최소화) 목적으로 여러 개를 같이 돌리다 보면,
CLAUDE.md 와 .cursor/rules/, GEMINI.md가 점점 따로 놀기 시작합니다.
EstreGenesis 는 그 문제를 풀어보려고 만든 AI Native 부트스트랩 시드 프롬프트 라이브러리입니다.

https://github.com/SoliEstre/EstreGenesis

시드 파일 하나를 채팅에 첫 메시지로

  • 내용을 복붙해서 붙여 넣거나,
  • 로컬 경로로 제공하거나,
  • 첨부로 던지거나,
  • 채팅으로 설명해서 간접적으로 파일 위치 전달 등

해서 전달해주면

에이전트가

  • 신규 프로젝트를 AGENTS.md 단일 진실 원천 + 각 도구별 브릿지 파일 구조로 부트스트랩해주거나,
  • 이미 산발적 룰 파일이 있는 기존 프로젝트를 검사하고 동일 구조로 마이그레이션해줍니다.

깊이에 따라 3-tier (Master / Lite / Compact) 중 하나를 골라 쓰면 됩니다.

  • Lite 가 기본값이고.
  • 토큰을 쏟아 붓는 스타일이거나(Opus 4.7, GPT 5.5 등의 상위 모델 만을 써서 퀄리티 중시),
    낮은 모델(Sonnet, Haiku)에서 좀 더 하네스를 견고하게 가져가고 싶은 경우 Master 티어를 사용하시면 됩니다.
  • 반대로 시드의 영향을 초소화 하고 싶은 경우 Compact 티어로 가시면 됩니다.

영문/한글 페어로 제공합니다.
두 언어 시드가 phase·migration·운영 가이드까지 동일하게 관리되고 있어서, 이중 언어 팀이면 양쪽 언어 페어로 같이 배치해도 됩니다.

핵심 패턴은 네 가지:

  1. AGENTS.md SSoT + 도구별 얇은 브릿지로 룰 카오스 방지.
  2. .agent/_coordination/ 으로 동시 편집 충돌 방지.
  3. .agent/_lessons/ 로 3시간 디버그가 다음 세션엔 30초 컷이 되도록 재발 방지.
  4. 중대 결정은 Research → Report → Plan 루프를 강제를 통한 리서치 기반의 견고한 개발을 주도.

그리고 이번 v1.6.0 에서 추가한 게 agent-time vs human-time 추정 정책입니다.
AI들이 대부분 계획 수립 시 인간 개발 기준으로 추정 기간을 5~10× 부풀려 잡아주니까,
부트스트랩 Phase 0의 실행 페이스 모드 선택에서

  • Cautious 2~4×
  • Proactive 5~6×
  • Burst 6~8×
  • Sprint 9~10×

중에서 미리 정해두면
모든 추정을 에이전트 작업 시간 + 인간 검토 시간 + 실 경과 기간 로 분리해서 보고하는 식입니다.
프로젝트 진행 중 모드 전환도 가능하고, _lessons/ 로 실측 보정도 됩니다.

그리고 중요한 선택 가능한 정책 중 하나가 (FE/BE와 같은)각 연계 프로젝트 repo와 이를 총괄하는 별도의 개발 문서 전용 repo를 분리해서 운영하는 패턴입니다.

** Antigravity나 Github Copilot 등은 작업 폴더 외 파일 접근이 안되므로 문서 repo 하위에 각 소스 repo를 두고 해당 폴더를 .gitignore에 등록해서 git 스코프를 분리하는 식으로.

이렇게 하면 .md 위주의 문서 repo가 생기는데, 소스가 public repo이더라도 개발 문서만은 private로 해서 공개 범위 조절이 가능해지고,

특히 Claude의 Project에서 프로젝트를 만들어 놓고 이 문서 전용 repo를 프로젝트의 파일에 Github 연결로 끌어와서프로젝트 지식으로 연결하면 프로젝트 문서 기반으로 채팅은 물론 딥리서치까지 가능한 셋팅이 됩니다. (repo push 마다 프로젝트에서 갱신 버튼 클릭 및 동기화 대기 필요.)
코딩 에이전트와 딥리서치 가능한 에이전트를 양쪽으로 이용하면서 딥리서치가 필요한 사항이 생기면 딥리서치 의뢰 프롬프트 요청해서 Claude Proejct에서 딥리서치를 돌리고,
그 결과를 문서 repo의 /archive/<날짜>_<주제>에 넣고 IDE의 에이전트에게 검토 및 취합을 맡기면 프로젝트의 개발 진행을 높은 수준으로 끌어올리는 효과를 보실 수 있습니다.
뿐만 아니라 Claude Project 채팅으로 수익화 및 사업(법률, 특허 등등) 관련 자문도 가능해지므로 이 패턴을 권장드리고 싶습니다.

이 repo는 제 두 번째 본격적인 AI Native 프로젝트를 Antigravity + Claude Code + GitHub Copilot의 3 에이전트 동시 운용하면서 같은 실수 반복 및 불편한 부분들을 개선해가면서 축적된 노하우를 시드로 정리한 것이구요.
그 외 제 다른 프로젝트에서도 유용한 사용 패턴들을 끌어모아 스노우 볼을 굴리고 있습니다.

그리고 꼭 코딩 에이전트가 아니어도 Hermes같은 에이전트에게 던져줘도 자기에게 적합한 부분만 잘 흡수해서 반영하니까, 사실상 만능 시드로 보셔도 됩니다.

참고로 라이센스는 Apache 2.0 입니다.

피드백·이슈·다른 AI 도구 브릿지 제안 환영합니다.

함께 보면 좋은 글 β

▲
kurthong 1일전  [-]

우선 좋은 프로젝트 소개 감사합니다. 저도 관심있는 분야입니다.
패턴을 잘 정리하셨네요. 본글 보면서 두 가지 자리가 궁금해서 댓글 답니다.
첫 번째 - _lessons/ 누적 비용. lessons 가 100개 >500개 정도로 쌓이면 grep 후 파일 통독 비용이 비례해서 증가할 텐데, AI Native 프로젝트에서 어느 임계점부터 매 태스크 시작 비용이 부담스러워지셨는지 혹시 측정 자료 있으시면 궁금합니다.
v1.3 RAG 인덱스 최적화 섹션이 결국 마크다운 메타데이터라 본질적 해결이 아닌 것 같아서요.

두 번째 - 멀티 에이전트 동시 운용 시 같은 파일이 에이전트 수만큼 중복 로딩되는 자리. 3 에이전트 디자인 베이스인데 각자 세션에서 AGENTS.md + rules.md + architecture.md + STATE.md + lessons 를 다 읽으면, 토큰 분산 목적이 오히려 곱해지는 자리 아닌가요. 이 부분은 혹시 어떻게 풀이하셨는지 아니면 어떻게 푸실건지 궁금합니다.

답변달기
▲
soliestre 19시간전  [-]

위 답변은 제가 시드 하네스 엔지니어링할 때 직접 프롬프트로 지시한, 제가 확실하게 기억하고 있는 선에서 즉답한 내용이고,
구체적인 lessons 누적에 대한 대처 방식 상세는 시드 빌드 과정에서 에이전트가 검토하며 알아서 디테일을 추가해서 반영한 영역이라, (시드로 증류 전 작업하던 프로젝트에서 이미 진행된 부분.)
제가 직접 답변하기보다 실제 구성을 잘 꿰고 있는 시드를 취합한 에이전트한테 물어보는 게 맞는 것 같아서 집에 와서 위 질답에 대한 의견을 물어봤습니다.

정리해 준 답변은 이렇습니다:

  1. 태그 grep — 작업 컨텍스트 관련 태그로 좁혀서 검색, lessons 전체 통독 아님.
  2. _lessons/README.md 인덱스 — 제목·태그·요약 1줄로 grep 전에 1차 필터.
  3. 패턴 승격 — 반복되는 lessons 는 docs/troubleshooting/ 으로 정착, 50건+ 인덱싱 폴더 ceiling 으로 자연 통제.

Q2 도 같은 맥락에서:

  • concurrent 운용은 토큰 절약 목적이 아니라 충돌 방지·rule drift 방지가 주 목적.

이라고 하네요.

토큰 분산 목적이면 제가 위에서 예시로 들은 방식이 정확한 패턴이겠고요.

답변달기
▲
soliestre 23시간전  [-]

현재 작업하던 프로젝트들을 뒤져봤는데, lessons가 16개가 최대이더라구요.
그리고 영향 파트 및 Severity를 같이 라벨링하기 때문에 어느정도 누적은 버텨줄 것으로 보이는데,
그 이상 쌓였을 경우에 대한 플랜은 생각해둬야 할 것 같네요.

저의 경우 시드에 대한 테스트를 따로 돌려보는 편이 아니고,
데모 수준의 프로젝트에 이용해 보는 경우가 아닌 실제 본격 작업중인 프로젝트에 적용하고 쓰면서 다듬는 상황이라 측정 자료는 따로 존재하지 않습니다.
RAG 인덱스 최적화 부분은 현재로서는 마크다운 위주의 개발문서 repo 타겟이라 현재 수준으로 적용되어 있습니다.
(* Claude Project의 개발 문서 repo 연동시의 최적화를 목적으로 적용된 부분입니다.)

두 번째 사항에 대해서는, 실질적으로 실시간 동시 운용을 권장 드리는 편은 아닙니다.
목적에 따라 효과적인 모델을 이용하려 할 때가 기본 가정이고,
그 외에는 명백히 서로 다른 파트를 작업할 때는 동시에 이용할 수 있습니다.
예를 들어 Claude로 PM 파트 담당으로 해서 작업 분배 플래닝을 먼저 진행한 뒤,
Antigravity와 Codex에서 FE/BE를 각각 동시에 돌린 후,
PM이 결과 취합하고 다시 다음 플래닝을 하는 식입니다.

그리고 현재로써는 제가 토큰을 아끼는 상황이 아니어서 마스터 시드에 모두 상위 모델로 돌리고 있는 관계로,
토큰 분산은 각 에이전트 플랫폼 별 가성비가 높은 플랜을 선택하고 추가 타 플랫폼도 마찬가지로 가성비 플랜을 구독하여 수평 확장하는 차원에서 접근되어 있습니다.
토큰을 절대적으로 아끼는게 목적이라면 현 시점에서는 본 시드 사용을 권장 드리는 편은 아닙니다.

답변달기
▲
soliestre 1일전  [-]

참고로 Claude Project의 파일(프로젝트 지식) 용량 제한은 10MB 가량이므로 repo가 반드시 텍스트 위주여야 합니다.
물론 일부 파일 제외는 Claude Project쪽 UI로 가능하니 폴더로 구분되어있거나 갯수가 적은 정도까지는 괜찮을 수 있습니다.

답변달기