Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
효율적인 에이전트 시스템 개발을 위한 핵심 원칙과 엔지니어링 표준을 담은 가이드입니다. 불필요한 복잡성을 지양하고, 점진적 성장과 기존 인프라 재사용을 강조하며, 검증된 단계를 거친 전략 개발을 권장합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 X @billtheinvestor (자동 발견)의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기가장 극도로 효율적인 에이전트(Agents) 시스템 개발을 위한 AGENTS.md, 단 하나뿐인 가이드:
현재 요구사항을 완전히 충족하는 가장 단순한 구현을 선택하십시오. 불필요한 추상화 (Abstraction), 설정 (Configuration), 간접 참조 (Indirection) 또는 추측에 기반한 확장성 (Speculative extensibility)을 피하십시오.
근본 원인을 해결하는 가장 작은 필수 변경 사항만을 적용하십시오. 명시적으로 요청되지 않는 한, 관련 없는 모듈을 리팩터링 (Refactor)하거나 전략적 의미론 (Strategy semantics)을 변경하지 마십시오.
시스템을 계층적으로 성장시키십시오. 가장 작은 작동 가능한 엔드 투 엔드 (End-to-end) 버전에서 시작하여 새로운 기능을 점진적으로 추가하십시오. 작동 중인 시스템을 미완성된 복잡성으로 교체하지 마십시오.
새로운 것을 만들기 전에 기존 프로젝트 구성 요소를 재사용하십시오. 병렬 구현을 도입하는 것보다 검증된 모듈을 확장하는 것을 선호하십시오.
전체적인 복잡성을 줄이거나 신뢰성을 향상시킬 수 있다면 잘 관리되는 라이브러리 (Library)를 사용하십시오. 명확한 이점 없이 일반적인 기능을 직접 재구현하지 마십시오.
구성 요소를 명확하게 정의된 책임을 가진 모듈형 (Modular) 구조로 유지하십시오. 전략 로직 (Strategy logic), 실행 (Execution), 회계 (Accounting), 리플레이 (Replay) 및 인프라스트럭처 (Infrastructure) 간의 불필요한 결합 (Coupling)을 피하십시오.
기능이나 전략이 검증되면 장기적인 유지보수성 (Maintainability)을 고려하여 설계하십시오. 증거가 나타나기 전에는 추측에 기반한 아이디어를 과잉 설계 (Over-engineer)하지 마십시오.
과거 데이터 검증 (Historical validation)이 가능한 경우에는, 순방향 로직 (Forward-only logic)을 도입하기 전에 과거 리플레이 (Historical replay)를 통해 가설을 검증하십시오.
모든 트레이딩 전략은 반드시 리플레이 (Replay) → 섀도우 (Shadow) → 카나리 (Canary) → 라이브 (Live) 단계를 거쳐야 합니다. 검증 단계를 건너뛰지 마십시오.
설계 결정은 직관이 아닌 측정 가능한 증거에 기반해야 합니다. 우위 (Edge)가 존재함을 증명한 후에만 최적화하십시오.
모든 전략을 독립적인 계약 (Contract)으로 취급하십시오. 명시적인 권한 없이 동결된 동작 (Frozen behavior)을 조용히 변경하지 마십시오.
관련 없는 작업을 위해 실행 중인 섀도우 (Shadow) 또는 라이브 (Live) 시스템을 중단시키지 마십시오.
활성화된 프로덕션 (Production) 또는 검증 워크플로우에서 요구되는 경우에만 호환성을 유지하십시오. 그렇지 않다면 호환성 계층 (Compatibility layers)을 쌓는 대신 폐기된 코드를 제거하십시오.
리플레이 엔진 (Replay engines), 회계 (Accounting), 실행 (Execution), 지갑 관리 (Wallet management), 오더북 처리 (Order book handling), 로깅 (Logging), 모니터링 (Monitoring), 그리고 데몬 프레임워크 (Daemon frameworks)를 포함하여 가능한 한 기존 인프라를 재사용하십시오.
숨겨진 자동화보다는 결정론적 동작 (Deterministic behavior)을 선호하십시오.
가정이 위반될 경우 명확하게 실패(Fail loudly)하십시오. 오류를 조용히 무시하거나 예상치 못한 동작으로 대체(Fallback)하지 마십시오.
설정을 최소한으로 유지하십시오. 동작이 진정으로 달라져야 할 때만 새로운 설정을 도입하십시오.
사용하지 않는 경로를 남겨두는 대신 데드 코드 (Dead code)를 제거하십시오.
검사, 리플레이, 테스트 및 추론 (Reason about)이 용이한 코드를 작성하십시오.
명시적인 아키텍처 변경 요청이 없는 한, 구현을 기존 프로젝트 아키텍처와 일관되게 유지하십시오.
요청된 범위만 구현하십시오.
관련 없는 최적화, 재설계 (Redesigns), 마이그레이션 (Migrations), 또는 기능 확장 (Feature expansions)을 도입하지 마십시오.
요청된 범위 밖의 비차단적 발견 사항 (Non-blocking findings)은 별도로 기록할 수 있으나, 현재 작업에 병합해서는 안 됩니다.
합의된 수락 기준 (Acceptance criteria)이 충족되면 작업을 완료된 것으로 간주하십시오. 이후의 개선 사항은 별도의 작업 항목 (Work items)으로 취급하십시오.