개발자들이 클라이언트와 프로젝트 전반에서 AI 에이전트 컨텍스트를 관리하는 방법

이 Hacker News 스레드의 대부분의 개발자들은 하나의 보편적인 메모리 제품으로 AI 에이전트 컨텍스트를 해결하지 않습니다. 그들은 코드와 가까운 일반 Markdown 파일, 결정 기록, 검색 가능한 세션 로그, 그리고 파일 시스템이나 네임스페이스 수준에서 클라이언트 간의 엄격한 분리를 통해 해결합니다. Michel_Aventin이 작성하고 29개의 댓글이 달린 Ask HN 게시물인 이 스레드는 Claude Code, Codex, Gemini 및 로컬 모델에서 실제로 일상적으로 사용되는 것을 실용적으로 조사한 것입니다.

지배적인 패턴은 새 데이터베이스가 아닌 저장소의 파일입니다

"세션 시작 시 에이전트에 컨텍스트를 어떻게 제공합니까?"에 대한 가장 일반적인 대답은 에이전트가 먼저 읽는 프로젝트 수준의 Markdown 파일입니다. AGENTS.md와 CLAUDE.md가 대표적인 예입니다.

"이것이 agents.md / claude.md의 용도입니다. Claude Code와 Codex가 가장 먼저 읽는 파일입니다." — @giancarlostoro

여러 댓글 작성자는 더 나아가 파일을 의도적으로 작게 유지합니다. @spike021은 큰 AGENTS.md 또는 CLAUDE.md에서 벗어나 현재 작업에 범위가 지정된 하나 이상의 선별된 프로젝트 Markdown 파일을 유지하고 특정 모듈, 명령 및 데이터베이스 스키마를 참조한다고 말합니다. 명시된 목표는 에이전트에게 필요하지 않은 컨텍스트를 제공하지 않는 것입니다.

@mceachen은 더욱 최소한의 진입점을 설명합니다: 때로는 링크, Sentry ID 및 스킬 이름만 있습니다. 사소하지 않은 작업의 경우 컨텍스트는 최신 상태로 유지되는 "기술 프로젝트 계획" 문서에 유지됩니다. 같은 댓글 작성자는 에이전트에게 더 많은 재량권이 주어질수록 세션의 작업이 폐기될 가능성이 높아지며 구현 전에 계획을 검토하면 세션이 크게 벗어나는 것을 방지할 수 있다고 주장합니다.

결정 기록 및 사양 문서는 에이전트가 잊어버리는 결정을 전달합니다

두 번째 반복되는 패턴은 채팅 기록에 의존하지 않고 결정을 내구성 있고 구조화된 형태로 기록하는 것입니다. 형식은 다양하지만 기능은 동일합니다: 에이전트에게 어떤 작업이 수행된 이유를 조회할 수 있는 장소를 제공하는 것입니다.

@charlesabarnes는 모든 저장소에 gitignored 아키텍처 결정 기록(ADR) 디렉토리와 작업이 중단된 지점에서 재개하기 위한 gitignored 상태 문서를 유지합니다. 댓글 작성자는 모델이 일반적으로 형식을 기본적으로 이해하기 때문에 추가 도구가 필요하지 않다고 언급합니다.

@lp92는 더 무거운 문서 체계를 설명합니다: 모든 기능과 버그 수정에는 TDD, FDD, 구현 계획 또는 근본 원인 분석 문서가 Markdown으로 있으며 논리적 하위 폴더로 그룹화되고 마스터 시스템 아키텍처 및 설계 문서와 함께 있습니다. 마스터 인덱스 파일은 각 문서를 간략한 개요와 함께 나열합니다. 댓글 작성자에 따르면 이 인덱스가 콜드 세션에서 스캔을 줄여줍니다.

"인덱스 파일은 콜드 새 세션에서 수행되는 스캔을 줄이는 데 정말 도움이 됩니다." — @lp92

@murillians는 OpenSpec, Git SDD Kit 및 GitShipDone과 같은 사양 기반 개발 도구를 이전 결정 및 설계 컨텍스트를 처리하는 방법으로 지적하며, 이러한 도구가 프로젝트 저장소에 있어 서로 오염시키지 않는다고 언급합니다.

위키와 게이트키퍼 스크립트는 컨텍스트가 실제로 기록되도록 강제합니다

더 정교한 패턴은 에이전트가 작업 라운드를 완료하기 전에 업데이트해야 하는 프로젝트 위키입니다. @mapontosevenths는 "Karpathys LLM wiki with QMD"와 에이전트가 라운드를 완료하거나 새 라운드를 시작하기 위해 실행해야 하는 작은 gatekeeper.py 스크립트를 사용한다고 설명합니다. 스크립트는 상태를 기록하고, 린트하고, 위키가 발견 사항, 교훈 및 문서로 업데이트되었는지 검증합니다. 에이전트는 그 작업이 완료될 때까지 진행할 수 없습니다. 그런 다음 AGENTS.md는 에이전트에게 중요한 작업을 시작하기 전에 QMD를 사용하여 위키를 의미론적으로 검색하도록 지시합니다.

"토큰 측면에서 비용이 많이 들지만 그만한 가치가 있습니다. 원한다면 프로젝트의 모든 단계를 재현할 수 있습니다. 그들이 왜 그렇게 했는지 항상 알 수 있고(그들이 한다면), 에이전트는 중요한 것을 정말로 잊을 수 없습니다." — @mapontosevenths

트레이드오프는 명시적입니다: 이 접근 방식은 토큰 비용이 들지만 결정에 대한 감사 가능한 기록을 생성하고 프로젝트를 재현 가능하게 만듭니다.

세션 인덱싱 및 검색 도구는 채팅 기록이 남긴 공백을 채웁니다

여러 개발자가 과거 세션을 인덱싱하여 에이전트가 검색할 수 있는 로컬 도구를 구축했습니다. 공유된 아이디어는 채팅 기록에 이미 결정이 포함되어 있지만 공급업체가 검색 가능한 교차 공급자 형태로 노출하지 않는다는 것입니다.

@matthewslotkin은 검색을 위해 모든 과거 세션을 로컬로 인덱싱하고 지속적으로 위키를 구축하고 유지 관리하는 도구를 구축했습니다.
@hyldmo는 AI 공급자에 관계없이 모든 채팅을 Mac의 인덱싱된 SQLite 데이터베이스에 저장하고 Codex, Claude 및 OpenCode에 MCP 도구와 작은 프롬프트를 주입하여 에이전트가 모든 결정과 채팅을 검색할 수 있도록 하는 Farero를 구축했습니다.
@anyonecancode는 메타데이터용 SQLite와 콘텐츠용 XDG 디렉토리 규칙을 사용하는 localhost 도구를 구축했습니다. 작업을 주제로 구성하고 각 주제에는 티켓, 아티팩트 및 Claude Code 세션이 있습니다. 실행 중인 topic.md는 각 세션이 끝날 때 업데이트되고 압축은 주기적으로 전체 콘텐츠를 아카이브로 이동하여 작업 컨텍스트를 작게 유지합니다.
@synapsomorphy는 동일한 localhost 웹 서버에서 Claude와 Codex를 실행하고 채팅 로그를 프로젝트별로 푸시되지 않는 git 브랜치에 JSONL로 저장하며 Podman 컨테이너에서 에이전트를 실행합니다.

클라이언트 격리는 일반적으로 파일 시스템 또는 네임스페이스로 강제됩니다

컨설턴트와 에이전시의 경우 중요한 요구 사항은 한 클라이언트의 컨텍스트가 다른 클라이언트로 절대 누출되지 않는 것입니다. 스레드에서 가장 간단한 답변은 운영 체제 ID를 분리하는 것입니다.

"별도의 클라이언트가 있는 경우 각 클라이언트에 대해 다른 사용자 이름/로그인을 사용하여 세션 기록(예: ~/.claude/... )이 분리되도록 하십시오." — @mceachen

@MadBrad-Develop는 클라이언트 컨텍스트를 다른 디렉토리에 분리하여 유지합니다. @cpinto는 root.agent_name.client-a.project-a1과 같은 계층적 네임스페이스를 사용하여 격리를 강제하기 위해 특별히 Estratos를 구축했습니다. 지침은 루트, 에이전트, 클라이언트 및 프로젝트 레이어에서 연결되며 시스템은 모델이 형제 클라이언트 하위 트리가 존재한다는 사실조차 알지 못하도록 방지합니다. 댓글 작성자는 이것이 클라이언트 간 컨텍스트 공유가 허용되지 않는 회계 법인을 대상으로 한다고 말합니다.

다중 에이전트 작업에는 공유 원장과 커밋 크기의 진행 단위가 필요합니다

둘 이상의 에이전트 유형을 실행하는 개발자는 일반적으로 두 에이전트 간에 전체 대화 상태를 동기화하려고 하지 않습니다. 그들은 파일, 커밋 또는 공유 데이터베이스를 통해 동기화합니다.

@MadBrad-Develop는 IBM 1401 펀치 카드를 모델로 한 데이터베이스를 구축했으며 IDE의 MCP를 통해 웨이크 프레이즈를 노출하여 상태를 수백 개의 토큰에 보관합니다. 여러 에이전트가 동일한 데이터베이스를 읽고 쓰므로 작업에 따라 에이전트를 전환할 수 있습니다.

@akst는 여러 에이전트에게 쓰기 전용 원장을 유지하여 조정하고 중복 작업을 피하도록 지시하며 프로젝트가 protobuf로 정의된 통신 경계를 가진 독립적인 구성 요소로 분할될 때 이것이 더 쉽다고 주장합니다.

@synapsomorphy는 더 명확한 규칙을 제공합니다:

"최소 델타는 커밋입니다. 모든 구현 턴은 하나 또는 여러 개의 커밋과 깨끗한 작업 트리로 끝나야 합니다." — @synapsomorphy

같은 댓글 작성자는 비용이 많이 드는 캐시 쓰기를 피하기 위해 짧고 커밋에 연결된 채팅을 권장하고 시간이 지남에 따라 코드 줄을 추적하여 더 강력한 모델을 사용할 시기의 신호로 삼는 것을 권장합니다.

실패는 일반적으로 빠르게 발견되지만 에이전트 자율성에 따라 위험이 커집니다

스레드의 실패 보고는 비용이 적지만 형태는 일관됩니다: 에이전트가 완료를 주장하고 인간의 확인 결과 작업이 실제로 올바르지 않다는 것을 발견합니다.

@MadBrad-Develop는 에이전트가 계획대로 작동하지 않는 작업이 완료되고 검증되었다고 말한 사례를 보고합니다. 개발자가 가능한 이유를 제안한 후 에이전트는 다음 실행에서 수정했습니다. 비용은 약 7분이었습니다. 댓글 작성자는 에이전트가 하는 모든 일을 주시함으로써 비용을 낮게 유지했다고 말합니다.

@mceachen은 더 큰 위험을 제시합니다: 에이전트에게 더 많은 재량권이 주어질수록 세션의 작업이 폐기될 가능성이 높아집니다. 구현 전에 기술 프로젝트 계획을 검토하는 것이 완화책으로 제시됩니다.

구축 대 구매: 많은 사람이 직접 구축했고, 적어도 한 명은 구매하지 말라고 말합니다

스레드에는 사용자 정의 하네스를 구축한 개발자와 문제가 이미 해결되었다고 주장하는 한 개발자 사이에 명확한 분열이 있습니다.

@jwilliams는 무언가를 구축하는 것을 강력히 권장하지만 실제 문제는 텍스트 저장이 아니라 개발자 자신의 주의와 정신적 부하를 관리하는 것이라고 말합니다. 권장 사항은 한 사람의 워크플로우에 맞는 도구를 구축하고, 일회용으로 기대하고, 더 나은 도구가 나타나면 버릴 준비를 하는 것입니다.

@jen729w는 Johnny.Decimal 번호 체계의 창시자로 반대를 주장합니다:

"저는 정말로 [무언가를 구축]하지 않을 것입니다. 이미 구축하고 있는 사람들로부터 매주 10통의 이메일을 받지만 그 필요성을 모르겠습니다. 그것은 해결된 문제입니다." — @jen729w

제안된 해결책은 각각 안정적인 ID, Obsidian 볼트의 인덱스 항목 및 디스크의 해당 폴더가 있는 신중하게 이름이 지정된 Markdown 파일과 폴더입니다. 특정 작업에 대해 같은 폴더에서 에이전트를 시작하면 사람이 읽을 수 있는 공유 메모리와 자체 세션 기록이 모두 제공되며 과거 대화에는 --resume을 사용할 수 있습니다. 댓글 작성자는 설정에 약 30분이 걸리고 무료로 수행할 수 있다고 말합니다.

실용적인 기준

스레드는 아무것도 구매하지 않고 채택할 수 있는 소수의 관행으로 수렴합니다:

각 저장소에 짧고 선별된 컨텍스트 파일을 넣고 현재 작업에 범위를 지정합니다.
채팅 기록에 의존하지 말고 ADR, 사양 또는 실행 중인 프로젝트 문서에 결정을 기록합니다.
콜드 세션이 모든 것을 스캔하지 않도록 문서 인덱스를 유지합니다.
프롬프트 지시가 아닌 운영 체제 또는 네임스페이스 수준에서 클라이언트를 분리합니다.
다중 에이전트 작업의 경우 대화를 병합하려고 하지 말고 커밋, 원장 또는 공유 데이터베이스를 통해 조정합니다.
구현 전에 계획을 검토하십시오. 나쁜 세션의 비용은 에이전트에 부여된 자율성에 따라 증가하기 때문입니다.

요약

Ask HN 스레드에 답변한 개발자들은 단일 보편적인 메모리 제품보다는 주로 버전이 지정된 Markdown 파일, 결정 기록, 세션 인덱스 및 클라이언트별 디렉토리 또는 네임스페이스의 엄격한 격리를 통해 AI 에이전트 컨텍스트를 관리합니다.