Show HN: GitAgent, AI agent를 프레임워크 설정이 아닌 Git 저장소로 다루자는 제안

agent 정의를 어디에 둘 것인가

2026년 3월 13일 Show HN에 올라온 GitAgent는 AI agent를 프레임워크별 설정 파일이나 hosted 서비스 내부 상태가 아니라, 일반적인 git 저장소 안의 파일로 정의하자는 제안이다. 핵심 구조는 agent.yaml, SOUL.md, SKILL.md 같은 파일이고, 여기에 memory, tools, knowledge, hooks, compliance 디렉터리를 붙일 수 있다. 크롤링 시점 기준 이 HN 글은 114 points와 24 comments를 기록했다.

핵심 논리는 단순하다. agent가 그냥 repo라면 version control, branching, pull request, review history, rollback이 자동으로 따라온다는 것이다. GitAgent 사이트도 이 점을 강하게 밀고 있다. branch-based deployment, monorepo 기반 shared context, 그리고 “stateless compute, git as state”처럼 실행 중 이벤트를 외부 SaaS에 숨기는 대신 repo history에 남기는 패턴을 예시로 든다.

왜 HN 개발자들이 반응했나

흥미로운 지점은 마케팅 문구보다 fragmentation 문제를 건드렸다는 점이다. HN 본문은 agent framework를 바꿀 때마다 agent 정의 자체를 다시 써야 하는 일이 반복된다고 지적한다. GitAgent는 이를 여러 runtime으로 export 가능한 filesystem 형태의 계약으로 풀려 한다. 공식 사이트 역시 특정 실행 엔진 하나보다 framework-agnostic standard라는 위치를 강조한다.

이 접근은 agent tooling이 점점 stateful하고 proprietary하며 UI 중심으로 가는 흐름과 반대편에 있다. git-native 정의는 prompt, skill, runtime memory, governance artifact를 모두 diff와 code review의 대상으로 끌어온다. 규제 환경이나 팀 협업 관점에서는 이 점이 단순한 “새 agent framework”보다 더 중요할 수 있다.

남아 있는 질문

HN 댓글은 현실적이었다. 실제로 어떤 adapter가 돌아가는지, schema가 얼마나 안정적인지, repo 기반 구조가 운영 마찰을 정말 줄여주는지 같은 질문이 바로 나왔다. 그 검증은 앞으로 필요하다. 그래도 GitAgent는 agent ecosystem 일부가 불투명한 플랫폼 상태 대신, 감사 가능하고 파일 기반인 정의 방식으로 이동하고 있음을 보여주는 분명한 신호다.

원문: GitAgent. 커뮤니티 토론: Hacker News.