위 답변은 제가 시드 하네스 엔지니어링할 때 직접 프롬프트로 지시한, 제가 확실하게 기억하고 있는 선에서 즉답한 내용이고,
구체적인 lessons 누적에 대한 대처 방식 상세는 시드 빌드 과정에서 에이전트가 검토하며 알아서 디테일을 추가해서 반영한 영역이라, (시드로 증류 전 작업하던 프로젝트에서 이미 진행된 부분.)
제가 직접 답변하기보다 실제 구성을 잘 꿰고 있는 시드를 취합한 에이전트한테 물어보는 게 맞는 것 같아서 집에 와서 위 질답에 대한 의견을 물어봤습니다.
정리해 준 답변은 이렇습니다:
- 태그 grep — 작업 컨텍스트 관련 태그로 좁혀서 검색, lessons 전체 통독 아님.
_lessons/README.md인덱스 — 제목·태그·요약 1줄로 grep 전에 1차 필터.- 패턴 승격 — 반복되는 lessons 는
docs/troubleshooting/으로 정착, 50건+ 인덱싱 폴더 ceiling 으로 자연 통제.
Q2 도 같은 맥락에서:
- concurrent 운용은 토큰 절약 목적이 아니라 충돌 방지·rule drift 방지가 주 목적.
이라고 하네요.
토큰 분산 목적이면 제가 위에서 예시로 들은 방식이 정확한 패턴이겠고요.
현재 작업하던 프로젝트들을 뒤져봤는데, lessons가 16개가 최대이더라구요.
그리고 영향 파트 및 Severity를 같이 라벨링하기 때문에 어느정도 누적은 버텨줄 것으로 보이는데,
그 이상 쌓였을 경우에 대한 플랜은 생각해둬야 할 것 같네요.
저의 경우 시드에 대한 테스트를 따로 돌려보는 편이 아니고,
데모 수준의 프로젝트에 이용해 보는 경우가 아닌 실제 본격 작업중인 프로젝트에 적용하고 쓰면서 다듬는 상황이라 측정 자료는 따로 존재하지 않습니다.
RAG 인덱스 최적화 부분은 현재로서는 마크다운 위주의 개발문서 repo 타겟이라 현재 수준으로 적용되어 있습니다.
(* Claude Project의 개발 문서 repo 연동시의 최적화를 목적으로 적용된 부분입니다.)
두 번째 사항에 대해서는, 실질적으로 실시간 동시 운용을 권장 드리는 편은 아닙니다.
목적에 따라 효과적인 모델을 이용하려 할 때가 기본 가정이고,
그 외에는 명백히 서로 다른 파트를 작업할 때는 동시에 이용할 수 있습니다.
예를 들어 Claude로 PM 파트 담당으로 해서 작업 분배 플래닝을 먼저 진행한 뒤,
Antigravity와 Codex에서 FE/BE를 각각 동시에 돌린 후,
PM이 결과 취합하고 다시 다음 플래닝을 하는 식입니다.
그리고 현재로써는 제가 토큰을 아끼는 상황이 아니어서 마스터 시드에 모두 상위 모델로 돌리고 있는 관계로,
토큰 분산은 각 에이전트 플랫폼 별 가성비가 높은 플랜을 선택하고 추가 타 플랫폼도 마찬가지로 가성비 플랜을 구독하여 수평 확장하는 차원에서 접근되어 있습니다.
토큰을 절대적으로 아끼는게 목적이라면 현 시점에서는 본 시드 사용을 권장 드리는 편은 아닙니다.
우선 좋은 프로젝트 소개 감사합니다. 저도 관심있는 분야입니다.
패턴을 잘 정리하셨네요. 본글 보면서 두 가지 자리가 궁금해서 댓글 답니다.
첫 번째 - _lessons/ 누적 비용. lessons 가 100개 >500개 정도로 쌓이면 grep 후 파일 통독 비용이 비례해서 증가할 텐데, AI Native 프로젝트에서 어느 임계점부터 매 태스크 시작 비용이 부담스러워지셨는지 혹시 측정 자료 있으시면 궁금합니다.
v1.3 RAG 인덱스 최적화 섹션이 결국 마크다운 메타데이터라 본질적 해결이 아닌 것 같아서요.
두 번째 - 멀티 에이전트 동시 운용 시 같은 파일이 에이전트 수만큼 중복 로딩되는 자리. 3 에이전트 디자인 베이스인데 각자 세션에서 AGENTS.md + rules.md + architecture.md + STATE.md + lessons 를 다 읽으면, 토큰 분산 목적이 오히려 곱해지는 자리 아닌가요. 이 부분은 혹시 어떻게 풀이하셨는지 아니면 어떻게 푸실건지 궁금합니다.