에이전트를 많이 만드는 것보다 더 어려운 일은, 그 에이전트를 여러 실행 환경에서 일관되게 쓰게 만드는 것입니다. agency-agents는 이 지점을 정면으로 건드립니다. 단순한 프롬프트 모음이 아니라, 역할별 에이전트 레시피를 한 저장소에 모아 두고 convert.sh와 install.sh로 여러 툴에 맞게 배포하는 구조입니다.
이 레포의 흥미로운 점은 “얼마나 많은 에이전트가 있느냐”보다, 에이전트 정의를 배포 가능한 자산으로 취급한다는 태도입니다. Claude Code만 바라보는 프로젝트가 아니라, Cursor·Copilot·Gemini CLI·OpenCode·OpenClaw·Aider·Windsurf·Kimi Code 같은 여러 런타임을 같은 설계 아래 다루려는 시도에 가깝습니다.
한 저장소, 여러 런타임
agency-agents는 engineering, design, marketing, product, project-management, specialized 같은 카테고리로 역할을 쪼갭니다. 각 에이전트 파일에는 보통 다음 요소가 함께 들어갑니다.
- 정체성(identity)
- 성격(personality)
- 미션(mission)
- 워크플로우(workflow)
- 산출물(deliverables)
- 성공 지표(success metrics)
- 커뮤니케이션 스타일(communication style)
즉, 이 레포는 “대충 이런 역할이 있으면 되겠지” 수준이 아닙니다. 에이전트가 어떤 톤으로 말해야 하는지, 어떤 결과물을 내야 하는지까지 포함한 운영 단위의 레시피를 제공하려고 합니다.
convert.sh가 중요한 이유
이 프로젝트의 핵심은 사실 convert.sh입니다. 많은 에이전트 레포가 하나의 포맷만 잘 지원하면 끝이라고 생각하지만, 실제 현장에서는 도구가 제각각입니다. 어떤 팀은 Claude Code를 쓰고, 어떤 팀은 Cursor를 쓰고, 또 어떤 팀은 OpenCode나 Copilot을 씁니다.
여기서 convert.sh는 다음 역할을 합니다.
- 공통 레시피를 읽는다.
- 툴별 제약에 맞게 표현을 바꾼다.
- 각 런타임이 이해할 수 있는 파일로 내보낸다.
이 구조가 중요한 이유는, 에이전트가 단순한 텍스트 프롬프트가 아니라 이식 가능한 구성요소가 되기 때문입니다. 같은 역할 정의를 여러 툴에서 재사용할 수 있으면, 도구를 바꿔도 팀의 작업 방식이 크게 흔들리지 않습니다.
install.sh가 해결하는 문제
배포는 변환만으로 끝나지 않습니다. 실제 사용자는 “어디에 복사해야 하지?”, “지금 설치된 툴은 무엇이지?”, “이 환경에서는 어떤 파일을 써야 하지?” 같은 질문에 부딪힙니다. install.sh는 이 마지막 마일을 담당합니다.
즉, 이 레포는 다음 두 단계를 분리합니다.
convert.sh: 형식을 맞춘다install.sh: 환경에 심는다
이 분리는 사소해 보이지만 실무에서는 꽤 큽니다. 변환과 설치가 섞이면 디버깅이 어려워지고, 특정 툴에만 종속된 설치 스크립트가 되기 쉽습니다. 반대로 둘을 나누면, 포맷 변화와 설치 문제를 따로 추적할 수 있습니다.
왜 이 접근이 유용한가
이 구조의 장점은 세 가지로 정리할 수 있습니다.
1. 벤더 종속을 줄인다
에이전트 정의를 한 툴의 규칙에 맞춰 고정하지 않으니, 도구를 바꿔도 자산이 그대로 살아남습니다. 이건 단순한 편의 기능이 아니라, 팀의 운영 리스크를 줄이는 장치입니다.
2. 역할을 재사용하기 쉬워진다
프론트엔드, 백엔드, DevOps, 마케팅, 프로젝트 관리처럼 역할이 명확할수록 재사용 가치가 커집니다. 한 번 잘 정의한 에이전트를 여러 프로젝트에 가져다 쓰기 쉬워집니다.
3. 팀의 기준을 파일로 남길 수 있다
많은 조직이 “좋은 에이전트 사용법”을 문서로만 남기고 끝냅니다. 그런데 이 레포는 그 기준을 실제 배포물로 만듭니다. 결국 스타일 가이드가 아니라 실행 가능한 운영 규칙이 됩니다.
다만, 만능은 아니다
이런 구조가 좋다고 해서 무조건 복잡도를 줄이는 것은 아닙니다. 오히려 역할이 너무 많아지면 다음 문제가 생깁니다.
- 에이전트 수가 늘수록 관리 비용이 올라간다
- 툴별 출력 차이 때문에 미세한 깨짐이 생길 수 있다
- “누가 언제 어떤 에이전트를 써야 하는가”를 정하지 않으면 선택 비용이 생긴다
그래서 이런 레포는 보통 많이 넣는 것보다, 실제로 쓸 것만 남기는 운영이 더 중요합니다. 에이전트 카탈로그가 커질수록 선별과 검증이 핵심이 됩니다.
이 레포를 보는 가장 실용적인 관점
agency-agents는 유명한 대형 에이전트 컬렉션으로 볼 수도 있지만, 더 정확하게는 에이전트 레시피의 배포 계층으로 보는 편이 맞습니다. 즉, 핵심 가치는 “112명 전문가 팀” 같은 스케일이 아니라, 그 팀을 여러 툴로 옮겨 심을 수 있게 만든 구조에 있습니다.
그 관점에서 보면 이 프로젝트는 다음 질문에 답합니다.
- 에이전트를 한 곳에서 정의할 수 있는가?
- 그 정의를 여러 툴로 복제할 수 있는가?
- 설치 과정까지 자동화할 수 있는가?
- 툴이 바뀌어도 팀의 기준은 유지되는가?
이 질문에 꽤 설득력 있게 답하는 프로젝트가 바로 agency-agents입니다.
마치며
AI 에이전트 생태계는 점점 “무슨 모델을 쓰느냐”보다 “어떤 운영 단위로 에이전트를 관리하느냐” 쪽으로 이동하고 있습니다. agency-agents는 그 변화의 한가운데에 있습니다. 역할 정의를 자산으로 다루고, 변환과 설치를 분리하고, 여러 런타임에 배포할 수 있게 만드는 방식은 앞으로 더 많은 프로젝트가 참고할 만한 패턴입니다.
다만 실제 도입에서는 에이전트 수보다 팀이 정말 쓸 수 있는가를 먼저 봐야 합니다. 좋은 레포는 많지만, 좋은 운영 모델은 드뭅니다. 이 프로젝트의 가치는 그 운영 모델 쪽에 더 가깝습니다.
참고 자료
- GitHub: https://github.com/msitarzewski/agency-agents
- Raw README: https://raw.githubusercontent.com/msitarzewski/agency-agents/main/README.md
- 공식 소스 캡처:
/home/ubuntu/wiki/raw/articles/github-msitarzewski-agency-agents.md