에이전시 에이전츠란? 공개형 인공지능 전문가 팀 가이드

에이전시 에이전츠는 여러 전문가가 실제로 협업하는 운영 플랫폼이 아니라, 코딩 도구에 설치해 쓰는 역할 기반 에이전트 설정 모음입니다. 이 글에서는 개인 개발자, 제품팀, 연구개발팀, 기업 자동화 담당자가 어떤 역할부터 도입하고 어떤 운영 능력을 별도로 준비해야 하는지 정리합니다.

공식 홈페이지에는 현재 역할 기반 에이전트가 146개, 전문 분야가 13개로 표시됩니다. 공식 역할 목록과 공식 저장소를 함께 확인하면, 에이전시 에이전츠는 완성된 인공지능 회사나 자율 운영 플랫폼이 아니라 여러 코딩 도구에 넣어 쓰는 역할 설정 모음이라는 결론에 도달합니다. 빠르게 역할 분담을 만들기에는 적합하지만, 작업 배정과 권한 분리와 품질 검수와 원격 실행 환경은 별도로 설계해야 합니다.

판정: 소규모 실험에는 적합합니다. 기업의 장기 운영에는 설정만 설치해서는 부족합니다. 역할 파일에는 말투만이 아니라 담당 업무, 우선순위, 산출물 형식과 점검 기준이 들어가지만, 실패한 작업을 다시 배정하거나 비밀 정보를 차단하거나 여러 작업의 상태를 통합하는 기능까지 자동으로 제공하지는 않습니다.

이 글은 세 부류를 위한 글입니다.

• 개발, 설계, 테스트 역할을 빠르게 만들려는 개인 개발자
• 인공지능 에이전트 팀을 제품과 콘텐츠 업무에 도입하려는 팀
• 장시간 실행과 병렬 작업을 고려하는 자동화 담당자

에이전시 에이전츠는 다중 에이전트 프레임워크인가요?

엄밀히 말하면 아닙니다. 이 프로젝트의 핵심은 역할별 지침 파일입니다. 파일 하나가 특정 전문가의 업무 방식과 결과물 기준을 설명합니다. 따라서 같은 모델과 같은 코딩 도구를 사용하더라도 역할 파일에 따라 질문하는 순서와 검수 방식이 달라질 수 있습니다.

예를 들어 프런트엔드 역할은 화면 구조와 접근성을 확인하고, 보안 역할은 입력값과 인증 경계를 확인하며, 현실성 검토 역할은 실제 증거가 있는지 따집니다. 이것은 모델을 새로 학습시키는 방식이 아닙니다. 독립된 실행 엔진을 추가하는 방식도 아닙니다.

공식 저장소는 클로드 코드용 설치를 기본으로 설명하면서 다른 도구용 변환 및 설치 방법도 제공합니다. 공식 홈페이지에는 클로드 코드, 커서, 윈드서프, 에이더, 큐웬 코드와 깃허브 코파일럿 등이 표시되어 있습니다. 다만 지원 방식은 도구마다 다릅니다. 어떤 도구는 전용 에이전트 폴더를 사용하고, 어떤 도구는 규칙 파일이나 명령어 변환을 거칩니다. 저장소의 도구별 설치 안내를 먼저 확인해야 합니다.

공식 페이지와 저장소 사이에 역할 수가 다르게 표시되는 점도 확인할 필요가 있습니다. 홈페이지는 146개를 표시하지만 저장소 설명에는 230개 이상이라는 표현이 남아 있습니다. 이 차이는 역할 수가 계속 바뀌거나 문서가 동시에 갱신되지 않았을 가능성을 보여줍니다. 따라서 역할 개수를 도입 성과의 기준으로 삼기보다, 실제 업무에서 산출물이 겹치지 않는지 확인해야 합니다.

개인 개발자는 어떤 역할부터 골라야 하나요?

처음부터 전체 역할을 설치하는 방법은 권하지 않습니다. 역할이 많아질수록 이름은 풍부해지지만, 어떤 역할에 어떤 일을 맡겼는지 추적하기 어려워집니다. 같은 문서를 여러 역할이 다시 쓰거나, 한 역할의 의견이 다음 역할의 입력에 섞이면서 책임 경계가 흐려질 수 있습니다.

개인 프로젝트라면 다음 세 역할부터 시작하는 편이 낫습니다.

1. 계획 역할

요구사항을 작업 목록과 완료 조건으로 바꿉니다.

1. 실행 역할

실제 코드나 문서를 작성합니다.

1. 검수 역할

테스트 결과와 누락 항목을 확인합니다.

역할 파일을 고를 때는 이름보다 네 가지를 읽어야 합니다.

• 어떤 입력을 요구하는가
• 어떤 파일이나 자료를 읽는가
• 결과를 어떤 형식으로 내는가
• 완료 여부를 무엇으로 판단하는가

예를 들어 실행 역할의 결과가 “코드를 수정했다”로 끝나면 부족합니다. 변경 파일, 실행한 테스트, 남은 위험과 다음 작업을 함께 내도록 계약해야 합니다. 역할 파일은 성격을 정하는 문서가 아니라 반복 가능한 작업 절차를 정하는 문서로 사용해야 합니다.

제품팀과 콘텐츠팀의 역할 조합은 입력과 출력 계약으로 결정됩니다

제품과 콘텐츠 업무에서는 역할을 많이 추가하는 것보다 입력과 출력의 연결이 중요합니다. 다음과 같이 분리하면 중복을 줄일 수 있습니다.

• 수요 조사 역할: 고객 발언과 검색 자료를 근거와 함께 정리합니다.
• 문제 정의 역할: 조사 결과를 사용자 문제와 우선순위로 바꿉니다.
• 설계 역할: 기능 범위와 화면 또는 문서 구조를 제안합니다.
• 생산 역할: 승인된 구조에 맞춰 초안을 만듭니다.
• 품질 역할: 사실성, 형식, 금지 표현과 누락을 검사합니다.

수요 조사 결과가 표나 목록으로 나오고, 문제 정의 역할은 그 자료를 바탕으로 결정 사항을 내야 합니다. 생산 역할이 조사부터 다시 시작하게 두면 역할 분리가 무의미해집니다.

우리 팀에서는 역할 사이에 다음과 같은 전달 양식을 고정하는 방식을 권합니다.

입력 자료:
결정해야 할 항목:
사용한 근거:
완료된 결과:
남은 불확실성:
다음 역할이 해야 할 일:

이 양식은 특정 도구에 종속되지 않습니다. 클로드 코드에서 시작해 커서로 옮기더라도 결과를 비교하기 쉽습니다. 반대로 역할마다 자유로운 문장을 허용하면 여러 전문가가 서로 다른 의견을 내는 것이 아니라 비슷한 초안을 반복해서 만들 가능성이 커집니다.

여러 전문가 에이전트는 순차와 병렬을 업무 의존성으로 나눕니다

업무 의존성을 기준으로 나눠야 합니다. 앞선 결과가 다음 역할의 입력이 되면 순차 실행이 맞습니다. 서로 다른 파일과 서로 다른 자료를 다루며 결과가 독립적이면 병렬 실행이 가능합니다.

예를 들어 다음 흐름은 순차 작업에 가깝습니다.

1. 요구사항 정리
2. 기술 설계
3. 코드 구현
4. 테스트 작성
5. 보안 검토
6. 문서 갱신

반면 다음 작업은 조건이 맞으면 병렬화할 수 있습니다.

• 한 역할은 문서 구조를 검토합니다.
• 다른 역할은 테스트 누락을 찾습니다.
• 또 다른 역할은 보안 위험을 검토합니다.

코드 구현과 테스트 작성은 동시에 가능하지만, 같은 테스트 파일을 수정하게 하면 충돌 가능성이 생깁니다. 같은 코드 파일을 여러 에이전트가 직접 수정하는 방식은 피해야 합니다. 각 작업을 별도 브랜치나 작업 트리에 격리하고, 마지막에는 사람이 정한 병합 조건을 통과시켜야 합니다.

클로드 코드나 커서가 여러 작업을 실행할 수 있어도, 그것이 곧 작업 조정 기능을 뜻하지는 않습니다. 작업 상태, 재시도 횟수, 변경 파일, 검수 결과를 기록할 저장소가 필요합니다. 커서의 백그라운드 실행 기능도 저장소 접근 권한을 요구하며, 자동 실행에는 프롬프트 주입과 데이터 유출 위험이 있다는 안내가 있습니다. 커서의 백그라운드 에이전트 보안 안내를 확인해야 합니다.

연구개발팀의 역할 편성은 다섯 단계로 나눌 수 있습니다

연구개발팀은 역할 이름을 다음 다섯 단계로 나누면 판단하기 쉽습니다.

• 계획: 요구사항, 범위, 완료 조건을 작성합니다.
• 구현: 승인된 설계를 코드로 옮깁니다.
• 테스트: 단위 테스트와 통합 테스트를 실행합니다.
• 보안 검토: 인증, 입력값, 비밀 정보와 외부 연결을 확인합니다.
• 문서화: 설치법, 변경 내역과 운영 절차를 갱신합니다.

계획과 보안 검토는 구현과 동시에 일부 진행할 수 있습니다. 그러나 보안 검토가 구현 결과를 읽어야 한다면 최종 검토는 구현 뒤에 배치해야 합니다. 문서화도 코드 변경 전부를 알지 못하면 정확하게 끝낼 수 없습니다.

각 역할의 완료 조건은 짧고 검증 가능해야 합니다.

• 계획: 작업 목록마다 담당 파일과 완료 조건이 있습니다.
• 구현: 변경 파일과 실행 명령을 기록합니다.
• 테스트: 성공과 실패 결과를 원문에 가깝게 남깁니다.
• 보안: 위험 항목마다 재현 조건과 대응 여부를 표시합니다.
• 문서: 새 사용자가 별도 설명 없이 따라 할 수 있는지 확인합니다.

역할이 같은 파일을 수정해야 한다면 병렬 실행을 중지하고, 브랜치 또는 작업 트리 격리를 먼저 적용해야 합니다. 병합 기준에는 자동 테스트 통과뿐 아니라 변경 범위, 비밀 정보 노출 여부와 사람이 읽을 수 있는 설명도 포함해야 합니다.

기업 프로젝트에는 별도의 거버넌스가 필요합니다

사용할 수는 있지만, 역할 설정만 설치해 기업용 운영 체계가 완성되지는 않습니다. 기업에서 빠지는 부분은 대체로 다음 다섯 가지입니다.

1. 권한

어떤 역할이 저장소를 읽고 쓰는지 정해야 합니다.

1. 비밀 정보

응용 프로그램 인터페이스 키와 배포 자격 증명을 역할 파일이나 프롬프트에 넣지 않아야 합니다.

1. 로그

작업 입력, 도구 호출, 변경 파일과 승인자를 남겨야 합니다.

1. 보존 정책

소스 코드와 고객 자료를 얼마나 오래 보관할지 정해야 합니다.

1. 사람의 승인

배포, 데이터 삭제, 권한 변경은 자동 완료로 처리하지 않아야 합니다.

에이전시 에이전츠는 역할의 업무 지침을 제공하지만, 완전한 신원 관리와 감사 추적과 샌드박스를 자동으로 제공하지 않습니다. 특히 역할 파일에 “보안 전문가”라고 적혀 있어도 실제 운영 환경에서 파일 접근 권한이 제한되는 것은 아닙니다. 권한은 실행 도구와 운영 환경에서 별도로 통제해야 합니다.

기업 도입에서는 다음 기준을 먼저 문서화해야 합니다.

• 읽기 전용으로 시작할 저장소
• 쓰기 권한을 허용할 디렉터리
• 외부 네트워크 연결 허용 여부
• 명령 실행 전 승인 단계
• 실패 작업의 재시도 조건
• 사람이 최종 승인해야 하는 변경 유형

이 기준이 없다면 역할 수를 늘릴수록 편리함보다 관리 대상이 빠르게 늘어납니다.

첫 설치는 여섯 단계로 진행합니다

공식 저장소의 설치 방식이 바뀔 수 있으므로 게시 전에는 설치 안내와 스크립트를 다시 확인해야 합니다. 현재 공식 홈페이지에는 복사 방식과 설치 스크립트 방식이 함께 안내되어 있습니다.

첫 단계: 저장소와 라이선스를 확인합니다

공식 저장소의 최신 변경 내역, 역할 디렉터리와 라이선스를 확인합니다. 공식 홈페이지는 이 프로젝트를 엠아이티 라이선스로 표시합니다. 기업 내부 배포를 검토할 때도 원본 라이선스와 각 파일의 변경 이력을 함께 보관해야 합니다. 공식 라이선스와 저장소 안내에서 확인할 수 있습니다.

두 번째 단계: 역할을 세 개만 고릅니다

계획, 실행, 검수 역할을 하나씩 선택합니다. 이름이 비슷한 역할을 여러 개 설치하지 않습니다. 첫 검증의 목적은 전체 역할을 시험하는 것이 아니라 역할 간 결과가 실제로 달라지는지 확인하는 것입니다.

세 번째 단계: 사용하는 도구에 맞춰 설치합니다

클로드 코드라면 공식 안내에 따라 사용자 에이전트 폴더에 역할 파일을 복사합니다. 커서는 전용 규칙이나 에이전트 형식으로 변환해야 할 수 있습니다. 설치 명령은 운영체제와 저장소 버전에 따라 달라질 수 있으므로, 오래된 블로그의 명령을 그대로 복사하지 않는 편이 안전합니다.

네 번째 단계: 입력과 출력 계약을 만듭니다

각 역할마다 입력 자료, 금지 범위, 산출물 형식과 완료 조건을 적습니다. 역할 파일 자체를 수정할 때는 원본과 내부 수정본을 구분합니다. 그래야 업데이트 뒤에 어떤 기준이 바뀌었는지 비교할 수 있습니다.

다섯 번째 단계: 실제 작업 하나로 실행합니다

새로운 예제보다 현재 진행 중인 작은 작업을 선택합니다. 계획 역할에는 요구사항을, 실행 역할에는 승인된 계획을, 검수 역할에는 변경 결과와 테스트 출력을 전달합니다.

여섯 번째 단계: 실패와 재시도를 기록합니다

결과만 저장하지 말고 실패 원인을 구분합니다. 입력 부족, 권한 부족, 도구 오류, 잘못된 역할 선택은 재시도 방법이 서로 다릅니다. 같은 프롬프트를 반복하는 방식은 운영 자동화가 아닙니다.

팀 규모별 운영 선택은 작업량으로 판단합니다

확장 여부는 역할 개수가 아니라 동시 실행 수, 의존성 설치 시간과 작업 지속 시간으로 판단해야 합니다. 역할이 많아도 한 번에 하나씩 실행하면 로컬 환경으로 충분할 수 있습니다. 반대로 역할이 세 개뿐이어도 장시간 실행과 병렬 작업이 반복되면 원격 환경이 더 적합할 수 있습니다.

여기서 점수는 제품 성능 점수가 아니라 운영 적합도입니다. 지속적으로 온라인 상태를 유지해야 한다면 클라우드 맥 원격 환경 안내를 검토할 수 있습니다. 국내 사용자를 대상으로 지연 시간과 접속 조건을 따로 비교하려면 한국 클라우드 맥 대여 안내도 함께 확인하는 편이 좋습니다.

원격 환경을 선택한다고 해서 권한 문제가 사라지는 것은 아닙니다. 원격 맥은 실행 장소를 바꿔 줄 뿐입니다. 저장소 권한, 비밀 정보 주입, 접속 기록과 승인 절차는 계속 설계해야 합니다.

정식 도입 전에는 검수 목록을 먼저 통과시켜야 합니다

아래 목록은 역할을 늘리기 전에 실제 프로젝트로 확인할 항목입니다.

• [ ] 계획 역할의 결과에 작업 범위와 완료 조건이 포함되어 있습니다.
• [ ] 실행 역할이 계획에 없는 파일을 임의로 수정하지 않습니다.
• [ ] 검수 역할이 실행 역할과 다른 기준으로 결과를 평가합니다.
• [ ] 실패 원인을 입력 부족, 권한 문제, 도구 오류로 구분할 수 있습니다.
• [ ] 같은 작업을 다시 실행해도 결과 비교가 가능합니다.
• [ ] 역할 사이에 고객 자료와 비밀 정보가 불필요하게 전달되지 않습니다.
• [ ] 사람이 승인해야 하는 변경 유형이 문서로 정리되어 있습니다.
• [ ] 같은 파일을 수정하는 작업이 브랜치나 작업 트리로 분리됩니다.
• [ ] 최종 결과에 변경 파일, 테스트 결과와 남은 위험이 포함됩니다.
• [ ] 역할 파일을 업데이트한 뒤 기존 결과가 달라지는지 재검증합니다.

우리는 첫 도입에서 실제 프로젝트 하나를 고르고, 계획 역할 하나와 실행 역할 하나와 검수 역할 하나만 먼저 검증하는 방식을 권합니다. 세 역할이 서로 다른 결과를 만들지 못한다면 역할을 더 설치할 이유가 없습니다. 반대로 세 역할의 책임과 출력이 분명하고 재시도가 가능하다면 콘텐츠, 보안, 문서 역할을 순서대로 추가할 수 있습니다.

현재 로컬 노트북에서 실행하는 방식은 짧은 테스트에는 간단하지만, 절전과 네트워크 단절과 개인 권한에 영향을 받습니다. 여러 역할을 동시에 오래 돌리면 작업 상태를 잃기 쉽고, 같은 저장소를 건드릴 때 충돌도 늘어납니다. 그렇다고 곧바로 원격 환경으로 옮길 필요는 없습니다. 작업 지속 시간과 동시 실행 수가 늘어나는 시점에 격리된 원격 맥 환경을 선택하는 편이 비용과 관리 복잡성을 함께 비교하기 좋습니다. 장시간 실행이 필요한 경우에는 맥 미니 렌탈과 원격 접속 방식 비교를 확인해 보시기 바랍니다.

에이전시 에이전츠는 역할을 빠르게 만드는 좋은 출발점입니다. 다만 역할 설정 모음을 기업 협업 플랫폼으로 오해하면 권한, 로그, 병합과 승인 단계에서 문제가 생깁니다. 먼저 작은 실제 작업으로 세 역할을 검증하고, 역할이 장시간 또는 병렬로 실행되는 시점에 제크브이피에스의 원격 맥과 격리 환경을 검토하는 순서가 가장 현실적입니다.