agency-agents 기업 도입: 필요한 AI 역할을 고르고 검증하는 방법

agency-agents를 회사에 도입한다면 필요한 역할 하나를 골라 실제 업무 결과와 맞대어 보는 것부터 시작하는 편이 좋습니다. 이 프로젝트는 개발·디자인·마케팅 등 부서별 AI 역할 정의를 모아 둔 것이라, 처음에는 코드 리뷰나 API 문서 초안처럼 사람이 정확성을 확인하기 쉬운 업무를 고르세요. 도입 여부를 가르는 건 역할을 몇 개나 갖췄느냐가 아니라 산출물의 품질과 검토에 드는 시간이에요.

부서 이름은 역할을 찾을 때 쓰는 분류 정도로 보면 충분합니다. 역할 파일을 추가한다고 사내 데이터 연결이나 업무 배분, 승인 절차가 함께 갖춰지지는 않거든요. 그래서 반복 업무의 입력과 완료 조건을 먼저 정해 두는 게 순서입니다.

역할 파일에서 먼저 볼 것: 검토 기준과 산출물

역할 파일은 마크다운으로 쓴 프롬프트입니다. 사내 시스템 연결이나 실행 권한은 사용하는 도구 쪽에서 따로 설정해야 해요. 파일을 열면 '전문가'라는 소개보다, 무엇을 검사하라고 하는지와 결과를 어떤 형식으로 내라고 하는지를 먼저 보시길 권합니다. 흔히 헷갈리는 부분이 인물 설정에 붙은 경력인데, 이건 모델에 부여한 배경일 뿐이라 실제 이력이나 검증된 수행 능력의 근거로 삼을 수 없습니다.

Code Reviewer 역할 정의는 정확성·보안·유지보수성·성능·테스트를 검토 대상으로 제시합니다. 발견 사항은 차단 사유, 개선 제안, 경미한 의견으로 나누고, 문제 위치와 이유, 수정 제안을 함께 내도록 요구하죠. 요구가 이 정도로 구체적이어야 검토하는 사람이 지적이 타당한지, 무엇부터 처리할지 판단하기 쉬워져요.

Technical Writer는 문서와 소프트웨어 버전이 일치하는지, 코드 예제가 실제로 실행되는지까지 요구합니다. 그러니 API 문서 초안을 받았다면 문장이 자연스러운지만 볼 게 아니라, 대상 버전과 내용이 맞는지, 예제가 정말 돌아가는지도 함께 살펴야 합니다.

지침이 구체적이면 평가 기준이 생기지만, 그 지침 자체가 성능 측정 결과인 건 아니에요.

필요한 역할만 골라 같은 조건에서 비교하기

공식 설치 안내에는 개별 역할을 고르는 --agent, 부서를 선택하는 --division, 역할 목록 파일을 쓰는 --agents-file이 나와 있습니다. --list로 목록을 훑어보고, --dry-run으로 설치될 작업을 미리 확인할 수도 있어요. 다만 선택한 도구와 설치 스크립트 버전에서 이 옵션들을 지원하는지는 실행 전에 확인하세요.

골라 낸 역할에는 회사의 입력 자료, 완료 조건, 최종 검토자를 덧붙이는 편이 좋습니다. Technical Writer라면 문서를 읽을 독자, 대상 API 버전, 예제 실행 환경, 배포 전 검토자를 적어 주는 식이에요. 추상적인 품질 요구를 회사 안에서 확인할 수 있는 조건으로 바꾸는 작업이라고 보면 됩니다.

비교 실험은 이런 순서로 진행할 수 있습니다.

1. 반복 업무 하나를 정하고 기존 작업 결과와 평가 자료를 준비합니다.
2. 같은 모델·입력 자료·도구 권한에서 기존 지침과 선택한 역할 정의를 각각 적용합니다.
3. 코드 리뷰는 유효한 지적과 오탐을, 문서는 사실 오류와 예제 실행 실패를 기록합니다.
4. 생성 시간과 함께 사람의 검토·수정 시간, 호출 비용을 비교합니다.

결과를 놓고 판단할 때는 생성 속도보다 사람이 결과를 받아 업무를 끝내기까지 걸리는 시간을 먼저 보세요. 초안이 빨리 나와도 오류를 찾아 고치는 시간이 늘어나면 도입 효과는 작아질 수 있거든요. 추가 검토 역할을 이어 붙이는 건, 비교 과정에서 개선할 지점이 드러난 뒤에 따로 시험하면 됩니다.

확대하기 전에 실행 증거와 권한부터 따져 보기

"예제를 테스트하라"는 지시와 테스트가 실제로 수행됐다는 증거는 구분해야 합니다. 실행 환경이 마련돼 있고 실제 실행 결과를 확인할 수 있어야 요구사항을 지켰는지 판단할 수 있어요. Technical Writer의 결과물도 설명문에 적힌 성공 여부만 읽기보다, 어떤 버전과 환경에서 예제를 실행했는지 확인하는 쪽이 정확합니다.

점검 대상은 역할 파일의 지시, 설치 스크립트, 연결 도구의 권한, 이렇게 셋으로 나눠 보면 정리가 쉽습니다. 역할 파일에서는 업무 범위를 벗어난 지시가 있는지, 설치 스크립트에서는 어떤 작업을 수행하는지를 살피세요. 연결 도구에는 맡긴 업무에 필요한 권한을 부여하고, API 키나 인증정보는 역할 파일에 넣지 않도록 관리해야 해요. 공식 보안 정책도 비밀정보 저장을 피하라고 안내하며, 의심스러운 역할 지시와 실행 가능한 설치 스크립트를 점검 대상으로 다룹니다.

공개된 역할 정의와 설치 안내만 보고 사내 환경에서 설치가 성공할지, 성능이 나아질지를 판단하기는 어렵습니다. 실제 설치·성능 시험을 거치기 전까지는 도입 효과를 검증할 대상으로 남겨 두세요. 설치 예시나 평가 결과를 발행하기 전에는 설치 옵션과 역할 정의를 다시 확인하고, 재현에 쓴 저장소 커밋을 기록해 두세요. 그래야 저장소가 바뀐 뒤에도 같은 조건을 추적할 수 있습니다.