레포가 곧 컨텍스트다: 에이전트에게 히스토리가 필요 없는 이유
코딩 에이전트는 당신이 주는 것은 무엇이든 읽습니다. 이는 장점처럼 들리지만, 대개는 문제입니다.
예전에는 에이전트에게 더 많은 문서를 제공하곤 했습니다. 사양서(specs), ADR, 기획 문서 등을 작성했죠. 컨텍스트가 많을수록 좋다고 생각했습니다. 그러다 에이전트가 아주 자신 있게 실수를 저지르는 것을 보았습니다. 그것은 환각(hallucination)이 아니었습니다. 단지 우리가 몇 달 전에 더 이상 사용하지 않기로 한 시스템을 설명하는 오래된 문서를 따르고 있었을 뿐입니다. 에이전트는 진실이 아닌 히스토리에 복종하고 있었던 것입니다.
히스토리는 인간을 위한 것입니다. 시스템이 왜 존재하는지 설명해주고, 트레이드오프(trade-offs)와 과거의 결정들을 이해하도록 도와줍니다.
에이전트는 다릅니다. 그들은 현재의 시스템을 수정합니다. 그 작업에 있어 에이전트에게는 과거의 서술형 문장이 필요하지 않습니다. 그들에게 필요한 것은 현재의 신뢰할 수 있는 단일 출처(source of truth)입니다.
에이전트에게 필요한 것: • 현재의 스키마 • 현재의 모듈 경계 • 현재의 API • 현재의 테스트 • 현재의 설정
에이전트가 데이터베이스를 이해하게 하고 싶다면, 모든 마이그레이션 로그를 다시 읽게 하지 마세요. 현재의 스키마를 주면 됩니다. 아키텍처를 이해하게 하고 싶다면, 오래된 ADR을 읽게 하지 마세요. 현재의 모듈 그래프를 주면 됩니다.
위험한 것은 '컨텍스트 오염(context pollution)'입니다. 이는 사실이 코드와 마크다운 파일이라는 두 곳에 공존할 때 발생합니다. 코드는 빠르게 변합니다. 하지만 서술형 문서는 누군가 기억해낼 때만 변합니다. 두 정보가 어긋나면, 에이전트는 오래된 문서를 신뢰합니다. 에이전트는 인간처럼 눈을 가늘게 뜨고 대조하며 확인하지 않습니다. 읽은 첫 번째 내용을 사실로 받아들입니다.
더 좋은 문서를 쓰려고 애쓰지 마세요. 사실이 부패할 수 있는 지점을 줄이기 시작하세요.
규칙을 텍스트에서 시스템 구조로 옮기세요: • 아키텍처는 디렉토리 구조를 사용하세요. • 의도는 명명 규칙(naming)을 사용하세요. • API는 패키지 export를 사용하세요. • 경계는 린트(lint) 규칙을 사용하세요. • 데이터 계약은 스키마를 사용하세요. • 동작은 테스트를 사용하세요.
README에 적힌 규칙은 제안일 뿐입니다. 하지만 ESLint 설정에 적힌 규칙은 벽입니다. 에이전트는 벽을 무시할 수 없습니다.
저는 지침(instruction) 파일의 크기를 줄였습니다. 이제 더 이상 아키텍처를 재진술하지 않습니다. 대신 아키텍처가 어디에 있는지 가리킬 뿐입니다.
히스토리는 사람을 위해 남겨두세요. 에이전트를 위해서는 현재를 설계하세요.
Source: https://dev.to/gyu07/the-repo-is-the-context-why-agents-dont-need-history-4ien
Optional learning community: https://t.me/GyaanSetuAi