가장 극도로 효율적인 에이전트(Agents) 시스템 개발을 위한 AGENTS.md, 단 하나뿐인 가이드:

AGENTS.md

핵심 원칙 (Core Principles)

• 현재 요구사항을 완전히 충족하는 가장 단순한 구현을 선택하십시오. 불필요한 추상화 (Abstraction), 설정 (Configuration), 간접 참조 (Indirection) 또는 추측에 기반한 확장성 (Speculative extensibility)을 피하십시오.

• 근본 원인을 해결하는 가장 작은 필수 변경 사항만을 적용하십시오. 명시적으로 요청되지 않는 한, 관련 없는 모듈을 리팩터링 (Refactor)하거나 전략적 의미론 (Strategy semantics)을 변경하지 마십시오.

• 시스템을 계층적으로 성장시키십시오. 가장 작은 작동 가능한 엔드 투 엔드 (End-to-end) 버전에서 시작하여 새로운 기능을 점진적으로 추가하십시오. 작동 중인 시스템을 미완성된 복잡성으로 교체하지 마십시오.

• 새로운 것을 만들기 전에 기존 프로젝트 구성 요소를 재사용하십시오. 병렬 구현을 도입하는 것보다 검증된 모듈을 확장하는 것을 선호하십시오.

• 전체적인 복잡성을 줄이거나 신뢰성을 향상시킬 수 있다면 잘 관리되는 라이브러리 (Library)를 사용하십시오. 명확한 이점 없이 일반적인 기능을 직접 재구현하지 마십시오.

• 구성 요소를 명확하게 정의된 책임을 가진 모듈형 (Modular) 구조로 유지하십시오. 전략 로직 (Strategy logic), 실행 (Execution), 회계 (Accounting), 리플레이 (Replay) 및 인프라스트럭처 (Infrastructure) 간의 불필요한 결합 (Coupling)을 피하십시오.

• 기능이나 전략이 검증되면 장기적인 유지보수성 (Maintainability)을 고려하여 설계하십시오. 증거가 나타나기 전에는 추측에 기반한 아이디어를 과잉 설계 (Over-engineer)하지 마십시오.

---

전략 개발 (Strategy Development)

• 과거 데이터 검증 (Historical validation)이 가능한 경우에는, 순방향 로직 (Forward-only logic)을 도입하기 전에 과거 리플레이 (Historical replay)를 통해 가설을 검증하십시오.

• 모든 트레이딩 전략은 반드시 리플레이 (Replay) → 섀도우 (Shadow) → 카나리 (Canary) → 라이브 (Live) 단계를 거쳐야 합니다. 검증 단계를 건너뛰지 마십시오.

• 설계 결정은 직관이 아닌 측정 가능한 증거에 기반해야 합니다. 우위 (Edge)가 존재함을 증명한 후에만 최적화하십시오.

• 모든 전략을 독립적인 계약 (Contract)으로 취급하십시오. 명시적인 권한 없이 동결된 동작 (Frozen behavior)을 조용히 변경하지 마십시오.

---

기존 시스템 (Existing Systems)

• 관련 없는 작업을 위해 실행 중인 섀도우 (Shadow) 또는 라이브 (Live) 시스템을 중단시키지 마십시오.

• 활성화된 프로덕션 (Production) 또는 검증 워크플로우에서 요구되는 경우에만 호환성을 유지하십시오. 그렇지 않다면 호환성 계층 (Compatibility layers)을 쌓는 대신 폐기된 코드를 제거하십시오.

• 리플레이 엔진 (Replay engines), 회계 (Accounting), 실행 (Execution), 지갑 관리 (Wallet management), 오더북 처리 (Order book handling), 로깅 (Logging), 모니터링 (Monitoring), 그리고 데몬 프레임워크 (Daemon frameworks)를 포함하여 가능한 한 기존 인프라를 재사용하십시오.

---

엔지니어링 표준 (Engineering Standards)

• 숨겨진 자동화보다는 결정론적 동작 (Deterministic behavior)을 선호하십시오.

• 가정이 위반될 경우 명확하게 실패(Fail loudly)하십시오. 오류를 조용히 무시하거나 예상치 못한 동작으로 대체(Fallback)하지 마십시오.

• 설정을 최소한으로 유지하십시오. 동작이 진정으로 달라져야 할 때만 새로운 설정을 도입하십시오.

• 사용하지 않는 경로를 남겨두는 대신 데드 코드 (Dead code)를 제거하십시오.

• 검사, 리플레이, 테스트 및 추론 (Reason about)이 용이한 코드를 작성하십시오.

• 명시적인 아키텍처 변경 요청이 없는 한, 구현을 기존 프로젝트 아키텍처와 일관되게 유지하십시오.

---

범위 규율 (Scope Discipline)

• 요청된 범위만 구현하십시오.

• 관련 없는 최적화, 재설계 (Redesigns), 마이그레이션 (Migrations), 또는 기능 확장 (Feature expansions)을 도입하지 마십시오.

• 요청된 범위 밖의 비차단적 발견 사항 (Non-blocking findings)은 별도로 기록할 수 있으나, 현재 작업에 병합해서는 안 됩니다.

• 합의된 수락 기준 (Acceptance criteria)이 충족되면 작업을 완료된 것으로 간주하십시오. 이후의 개선 사항은 별도의 작업 항목 (Work items)으로 취급하십시오.