agency-agents 딥다이브: 개발·검증·운영의 관점을 역할별로 나누기

한 줄 요약

agency-agents는 개발, 디자인, 테스트, 마케팅과 운영 등 여러 업무의 역할·작업 절차·산출물 기준을 문서로 제공하고, 이를 사용하는 코딩 도구에 설치할 수 있는 오픈소스 역할 모음입니다.

같은 기능을 두고 개발자는 구현을, 디자이너는 사용 흐름을, 운영자는 실패했을 때의 대응을 먼저 봅니다. 혼자 만드는 빌더라면 이 관점을 매번 바꿔 가며 에이전트에게 설명하는 일이 생깁니다. agency-agents는 각 역할이 무엇을 보고 어떤 결과를 내야 하는지 정리된 문서에서 출발하고 싶을 때 살펴볼 만합니다.

앞서 소개한 Superpowers가 개발 단계를 이어 주고, Everything Claude Code가 스킬과 규칙·훅으로 작업 환경을 구성한다면, agency-agents에서는 누가 어떤 관점으로 결과를 읽을지에 주목해 보세요. mattpocock/skills의 요구 정리와도 이어지지만, 여기서는 역할별 책임과 산출물을 비교하는 것이 출발점입니다.

저희가 권하는 첫 시도는 담당 역할 두 개가 만나는 작은 기능입니다. 예약 화면과 저장 API를 만들거나, 완성한 문의 폼을 실제 사용자 흐름으로 검토하는 작업이면 좋겠습니다. 많은 역할을 한꺼번에 부르기보다 같은 요구를 각 역할이 어떻게 읽고, 다음 담당자에게 무엇을 넘기는지 따라가면 쓰임이 선명해집니다.

무엇을 할 수 있나

저장소에는 엔지니어링, 디자인, 제품, 프로젝트 관리, 테스트, 보안, 지원과 여러 업무 영역의 역할 문서가 있습니다. 각 파일은 역할 이름과 설명, 핵심 임무, 지켜야 할 기준, 작업 순서, 결과물 예시를 담습니다. 필요한 문서를 참고 자료로 읽거나 기존 팀 지침에 맞게 조정하고, 지원하는 코딩 도구에 설치할 수 있습니다.

예를 들어 Frontend Developer는 화면 구현과 접근성, 성능, API 연결을 다룹니다. Backend Architect는 데이터 구조와 API 계약, 오류 응답, 신뢰성 같은 관점을 제공합니다. 두 역할을 같은 기능에 적용하면 화면에서 필요한 상태와 서버가 보장할 조건을 나눠 검토할 수 있습니다. 역할 이름보다 문서 안의 실제 임무가 지금 작업과 맞는지 읽어 보세요.

테스트 영역에서는 Evidence Collector와 Reality Checker를 함께 살펴볼 만합니다. 전자는 명세와 재현 가능한 근거를 연결해 문제를 기록하는 쪽에, 후자는 이전 검토와 실제 결과를 대조하며 전체 사용자 흐름을 살펴보는 쪽에 초점이 있습니다. 다만 문서별 표현과 판단 기준이 다르므로 역할을 설치하기 전에 팀의 검수 기준과 비교하는 과정이 필요합니다.

개발 밖의 업무도 있습니다. Paid Media Auditor는 광고 계정 구조와 측정, 예산, 소재 등을 검토하는 관점을, Tracking & Measurement Specialist는 이벤트 설계와 전환 측정, 중복 집계, 동의 상태 같은 관점을 다룹니다. 실제 데이터 연결은 별도 환경에서 준비해야 하지만, 어떤 질문과 자료가 필요한지 정리하는 단계에서도 참고할 수 있습니다.

이 역할 문서는 모델이 따라갈 지침입니다. 파일에 적힌 경력이나 기억, 성과 지표를 실제 사람의 이력이나 측정 결과로 읽지는 않아야 합니다. 어떤 도구를 호출할 수 있는지, 기록이 다음 대화에도 남는지, 여러 역할이 동시에 실행되는지는 사용하는 코딩 도구와 주변 구성에서 결정됩니다. 역할 모음의 범위를 이해하면 필요한 실행 환경도 구체적으로 고를 수 있습니다.

공식 README의 역할 목록을 볼 때는 업무 이름 하나와 다음 담당자에게 넘길 결과 하나를 함께 골라 보세요. “화면을 만든다”보다 “오류 상태와 API 입력 조건을 포함한 화면 변경을 넘긴다”처럼 산출물을 좁히면 역할이 도와줄 지점을 확인하기 좋습니다. 사람이 최종 결정할 조건도 그 옆에 두면 검토가 수월해집니다.

설치와 첫 대화

README는 데스크톱 앱과 스크립트 기반 설치, 역할 문서를 참고 자료로 사용하는 경로를 제공합니다. 터미널에서 내용을 살펴보며 시작하려면 저장소를 로컬에 받은 뒤 루트 디렉터리에서 공식 설치 안내를 따릅니다. 실행에 사용할 모델과 코딩 도구는 별도로 준비합니다.

Claude Code를 사용하는 경우 변환 없이 원래의 Markdown 역할 문서를 설치할 수 있습니다. 다음 명령은 Claude Code 통합 문서에 나오는 전체 설치 경로입니다. 먼저 설치 스크립트와 기존 역할 파일의 이름을 비교하면 중복 여부를 살펴보기 좋습니다.

./scripts/install.sh --tool claude-code

처음부터 전체 역할이 필요하지 않다면 README가 안내하는 선택 설치를 이용할 수 있습니다. 다음은 엔지니어링과 보안 영역을 고르는 공식 예입니다. 전체 설치와 선택 설치 중 필요한 범위를 정해 진행하세요. Claude Code 경로는 사용자 디렉터리의 ~/.claude/agents/에 역할을 복사하는 방식입니다.

./scripts/install.sh --tool claude-code --division engineering,security

다른 도구에 사용할 형식은 변환 스크립트로 준비합니다. README에는 먼저 변환 파일을 만들고 설치 대상 도구를 고르는 순서가 있습니다. 예를 들어 Cursor에서 프런트엔드 개발과 UI 디자인 역할만 고르는 예는 다음과 같습니다. 사용하는 도구에 따라 적용 위치와 역할을 불러오는 방법이 달라지므로 해당 통합 절까지 함께 읽어 보세요.

./scripts/convert.sh
./scripts/install.sh --tool cursor --agent frontend-developer,ui-designer

설치할 영역을 살펴보는 명령과 쓰기 전 경로를 확인하는 예도 있습니다. 다음 두 줄은 README의 목록 조회와 OpenCode용 미리보기 예입니다. 두 번째 줄은 OpenCode를 대상으로 하므로 Claude Code 설치가 끝난 뒤 반드시 더 실행해야 하는 단계는 아닙니다. 도구와 필요한 범위를 선택하는 데 참고할 수 있습니다.

./scripts/install.sh --list teams
./scripts/install.sh --tool opencode --division engineering --dry-run

설치 뒤 Claude Code 세션에서는 이름으로 역할을 요청하는 예가 공식 통합 문서에 있습니다. 첫 대화는 Frontend Developer에게 작은 화면 작업의 구조를 읽도록 맡겨 보세요. 아래는 그 방식을 예약 화면에 맞춘 대화 예시입니다. 설치한 역할을 환경에서 사용할 수 있는지, 응답이 지정한 작업 범위에 맞는지 함께 살펴봅니다.

Frontend Developer 역할을 사용해 예약 화면을 살펴봐 주세요.
기존 컴포넌트와 디자인 기준을 따르고,
예약 가능·마감·요청 실패 상태를 어떻게 보여 줄지 정리해 주세요.
코드를 고치기 전에 관련 파일과 API에서 필요한 조건을 알려 주세요.

결과가 너무 넓다면 역할 문서에 들어 있는 모든 임무를 이번 작업에 적용하려는지 봅니다. 작은 예약 화면 수정에 새 디자인 시스템이나 다른 프레임워크 전환까지 필요하지는 않을 수 있습니다. 기존 스택과 변경 범위, 하지 않을 결정은 프로젝트 요구에서 정합니다. 역할의 일반적인 권고를 현재 저장소에 맞추는 과정이 첫 실행의 중요한 부분입니다.

활용 시나리오 1: 예약 화면과 API의 약속 맞추기

예약 가능한 시간을 보여 주고 사용자가 하나를 선택해 신청하는 기능을 만든다고 해 보겠습니다. Frontend Developer는 화면 상태와 입력, 접근성을 보고, Backend Architect는 시간 데이터와 요청 형식, 실패 응답을 살펴볼 수 있습니다. 공식 README의 스타트업 MVP 시나리오도 프런트엔드와 백엔드 역할을 함께 배치합니다. 작은 기능에서는 두 역할이 만나는 계약부터 정리해 보세요.

먼저 화면 담당에게 사용자가 거치는 상태를 요청합니다. 시간 목록을 읽는 중인지, 선택할 시간이 없는지, 신청 요청이 진행 중인지에 따라 안내가 달라집니다. Frontend Developer 문서는 API 통합과 상태 관리, 오류 피드백, 접근성을 다룹니다. 아래는 이 관점을 예약 작업에 적용한 요청입니다.

예약 시간 선택 화면의 상태와 사용자 동작을 정리해 주세요.
기존 UI 구성과 키보드 조작 방식을 따라갑니다.
목록 조회 중·빈 목록·선택 완료·신청 실패를 나누고,
각 상태에 필요한 API 입력과 응답 조건을 적어 주세요.
서버에서 정해야 할 사항은 임의로 확정하지 마세요.

그다음 서버 담당에게 같은 요구와 화면의 질문을 넘깁니다. Backend Architect 문서는 API 계약과 일관된 오류, 재시도, 멱등성 같은 조건을 다룹니다. 예약이 이미 마감된 경우나 같은 요청이 다시 들어오는 경우를 현재 제품과 데이터 구조에서 어떻게 다룰지 검토하는 데 연결할 수 있습니다.

Backend Architect 역할로 예약 요청의 계약을 검토해 주세요.
화면 담당이 정리한 상태와 기존 API·데이터 구조를 근거로 삼습니다.
시간 식별자, 이미 마감된 경우, 중복 요청의 처리 조건을 제안하고,
현재 구조에서 가능한 최소 변경과 추가 제품 판단을 구분해 주세요.
화면 담당에게 돌려줄 응답 예와 검증할 조건을 남겨 주세요.

여기서 받을 결과는 서로 다른 설계 문서 두 개보다 합의할 조건입니다. 화면은 시간 문자열을 보내고 서버는 시간대 식별자를 기대한다면 그 차이를 먼저 해결합니다. 서버가 마감 오류를 반환하는데 화면 계획에 해당 상태가 없다면 다시 연결합니다. 역할별 결과를 마지막에 합치는 사람은 이런 경계를 읽어야 합니다.

이 시나리오에서는 시간대와 중복 요청처럼 제품 판단이 필요한 부분이 생길 수 있습니다. 역할 이름이 전문적으로 보이더라도 정책을 새로 만들어도 된다는 뜻은 아닙니다. 기존 제품 문서에 조건이 있으면 그것을 따르고, 없다면 질문으로 남깁니다. 설계에서 정한 조건이 실제 요청과 응답, 테스트에 함께 들어갔는지 검토해 보세요.

구현 단계에서는 파일 담당도 정합니다. 화면 역할이 API 파일까지 바꾸고 서버 역할이 컴포넌트를 다시 고치면 변경 이유를 추적하기 어려워집니다. 먼저 입력과 응답의 약속을 합의한 뒤 각 작업의 파일 범위와 검증 결과를 남기면 좋습니다. 여러 역할을 사용하는 방식과 작업공간을 어떻게 나눌지는 실행 도구와 팀 절차에서 결정합니다.

한 사람이 두 역할을 순서대로 사용해도 이 구분은 도움이 됩니다. 처음에는 화면 상태를 읽고, 그 결과를 서버 관점에서 검토한 뒤, 합의한 조건으로 돌아오는 방식입니다. 동시 실행 여부보다 역할 사이에 전달된 정보가 충분한지 살펴보세요. 첫 파일럿에서는 병렬 실행보다 합의한 계약을 끝까지 따라가 보는 데 집중할 수 있습니다.

이 접근의 장점은 “잘 만들어 주세요”를 각 역할이 검토할 항목으로 바꿀 수 있다는 점입니다. 화면 담당은 사용자에게 보이는 상태를, 서버 담당은 그 상태를 뒷받침할 조건을 설명합니다. 결과가 같은 요구에 연결되면 사람이 구현 전에 어긋난 가정을 찾기 쉬워집니다. 역할을 바꿨다는 사실보다 바뀐 질문의 내용을 읽어 보세요.

활용 시나리오 2: 기능 완료를 재현 가능한 근거로 검토하기

예약 화면이 만들어지면 다음 질문은 “화면이 보이는가”에서 “사용자가 예약을 끝낼 수 있는가”로 바뀝니다. 테스트 영역의 Evidence Collector는 명세와 실제 결과를 연결하고, 화면 근거와 동작 근거를 구분하도록 안내합니다. 입력한 화면 한 장으로 저장까지 성공했다고 판단하지 않는 관점이 작은 웹 기능을 검토할 때도 유용합니다.

먼저 검토할 요구와 실행 환경을 좁혀 줍니다. Evidence Collector 문서는 재현 가능한 문제만 기록하고, 검토하지 못한 범위는 별도로 남기며, 원래 요구에 없던 조건을 추가하지 않도록 안내합니다. 예약 기능에서는 정상 신청과 마감 응답, 실패 후 다시 시도하는 흐름에 적용해 볼 수 있습니다.

Evidence Collector 역할로 승인한 예약 요구와 구현을 대조해 주세요.
테스트용 환경과 가상 입력만 사용합니다.
화면 상태는 이미지로, 신청 성공과 실패는 응답·저장 결과 등
해당 동작을 보여 주는 근거로 연결해 주세요.
문제는 재현 순서·기대 동작·실제 동작·근거 위치로 정리하고,
수행하지 못한 항목은 제품 결함과 구분해 남겨 주세요.

역할 문서에 나오는 예시 명령도 현재 프로젝트와 대조해야 합니다. 일부 테스트 역할은 특정 스크립트 이름과 경로, 로컬 포트를 전제로 한 예를 담고 있습니다. 그 파일이 현재 저장소에 있는지 살펴보고, 팀이 실제로 쓰는 테스트 도구와 실행 방법을 연결하세요. 역할 파일을 설치한 것만으로 예시의 스크립트나 테스트 환경이 함께 준비되는 것은 아닙니다.

근거를 받으면 주장을 하나씩 읽습니다. 마감 상태의 화면을 보여 주는 이미지는 안내 문구를 검토하는 데 도움이 됩니다. 실제 서버가 마감 요청을 거절하는지는 응답과 저장 결과 같은 동작 근거가 필요합니다. 반대로 요청이 실패했다는 로그만으로 사용자가 오류 안내를 읽을 수 있었다고 판단하지는 않습니다. 화면과 동작의 근거를 함께 두면 빠진 부분을 찾기 좋습니다.

Reality Checker 문서는 앞선 검토와 실제 결과를 다시 대조하고, 전체 사용자 흐름과 준비 상태를 판단하는 역할을 제시합니다. 이 역할에는 보수적인 판정 표현과 예시 기준이 들어 있습니다. 팀에서는 고정된 품질 점수나 반복 횟수보다 승인한 요구와 실행 근거를 최종 판단의 기준으로 정해 두세요.

Reality Checker 역할로 예약 흐름의 검토 근거를 다시 읽어 주세요.
화면 진입부터 시간 선택, 신청 결과 확인까지 요구와 연결합니다.
앞선 보고서에서 근거가 부족한 주장을 찾고,
추가로 필요한 검사와 재현된 결함을 구분해 주세요.
출시 판단은 팀 승인 절차로 넘길 수 있도록 남은 항목을 정리해 주세요.

두 검토 역할을 함께 쓴다면 서로 다른 책임을 주는 편이 좋습니다. 첫 역할은 재현과 근거 정리, 다음 역할은 요구와 근거의 대응과 남은 범위 검토를 맡깁니다. 같은 문서를 같은 방식으로 두 번 읽는 것보다 검토할 질문이 분명해집니다. 다만 같은 모델이 다른 역할로 답했다는 사실만으로 완전히 독립된 검증을 얻었다고 보기는 어렵습니다.

보고서가 서로 다를 때는 더 엄격한 말투를 자동으로 고르기보다 근거를 대조합니다. 한쪽은 테스트 환경에 접근하지 못했고 다른 쪽은 다른 버전의 화면을 봤을 수 있습니다. 같은 변경과 같은 요구를 보고 있는지부터 맞춥니다. 결함이 있다면 재현 가능한 수정 요청으로, 근거가 부족하다면 필요한 추가 검사로 이어질 수 있어야 합니다.

이 시나리오에서 역할 문서의 장점은 검토 형식을 시작할 수 있다는 점입니다. 팀마다 매번 다른 방식으로 “확인했다”고 보고하던 일을 재현 순서와 결과, 근거 위치로 정리할 수 있습니다. 첫 도입에서는 발견한 문제 개수보다 다음 담당자가 같은 문제를 다시 확인할 수 있는지 살펴보시면 좋겠습니다.

활용 시나리오 3: 광고 계정 검토와 전환 측정 점검 나누기

새 광고 계정을 인수하면서 보고된 전환과 실제 문의 수가 다르다면 예산부터 조정하기 어렵습니다. agency-agents의 공식 README는 광고 계정 인수 시 감사와 측정, 전략, 소재, 보고 역할을 나누는 구성을 소개합니다. 작은 팀이라면 Paid Media Auditor와 Tracking & Measurement Specialist 두 역할부터 비교해 볼 수 있습니다.

Paid Media Auditor 문서는 계정 구조와 측정, 입찰·예산, 검색어와 소재, 랜딩 페이지를 여러 영역으로 나눕니다. 이 중 당장 필요한 검토 범위를 고르고 읽기용 자료를 제공해 보세요. 실제 계정 변경까지 한 번에 맡기기보다 어떤 근거가 필요한지 정리하는 출발점으로 쓸 수 있습니다.

Paid Media Auditor 역할로 신규 인수 계정의 검토 계획을 세워 주세요.
이번 범위는 캠페인 구조와 전환 설정, 랜딩 페이지입니다.
제공한 익명화 보고서와 설정 설명만 근거로 사용하고,
관찰 사실·가능한 원인·추가로 필요한 자료를 구분해 주세요.
예산과 설정은 변경하지 말고 우선 검토할 항목을 정리해 주세요.

이 결과에서 전환 집계의 문제를 발견했다면 측정 역할로 질문을 좁힙니다. Tracking & Measurement Specialist 문서는 태그 관리, GA4 이벤트, 광고 전환, 브라우저와 서버 이벤트 중복, 동의 신호 검증 등을 다룹니다. 실제 연결 도구가 있는 경우와 보고서만 읽는 경우를 구분해야 합니다.

Tracking & Measurement Specialist 역할로 전환 집계 차이를 살펴봐 주세요.
측정 계획과 테스트 이벤트, 익명화한 집계 자료를 제공합니다.
폼 제출, 유효 문의, 광고 전환이 각각 무엇을 뜻하는지 먼저 맞추고,
중복 발생·누락·집계 기간 차이를 검토할 순서를 제안해 주세요.
계정 쓰기와 실제 고객 데이터 조회는 이번 범위에 넣지 않습니다.

출발점은 숫자의 정의를 맞추는 것입니다. 버튼 클릭과 폼 저장, 담당자가 확인한 문의가 서로 다른 사건이라면 같은 전환 수로 비교할 수 없습니다. 광고 플랫폼과 분석 도구가 사용하는 기간과 분류 기준도 다를 수 있습니다. 역할이 제공하는 점검 관점을 사용하되 실제 원인은 제공된 설정과 테스트 근거로 좁혀 나갑니다.

태그와 이벤트가 준비돼 있다면 테스트 입력 한 번이 어떤 경로로 기록되는지 따라가 봅니다. 브라우저 이벤트와 서버 이벤트가 모두 있는 경우 중복을 어떻게 구분하는지, 동의 상태가 바뀌면 어떤 처리를 하는지 살펴볼 수 있습니다. 이런 검토는 역할 문서의 측정과 디버깅 범위에 연결됩니다. 조직의 데이터 정책과 실제 서비스 설정을 기준으로 조건을 정해야 합니다.

이때 역할 파일의 목표 지표나 성과 표현을 현재 계정의 예상 성과로 옮기지 않습니다. 계정 규모와 입력 자료, 운영 이력에 따라 판단이 달라지며, 개선 폭을 말하려면 별도의 실행과 측정 근거가 필요합니다. 첫 결과는 “얼마를 절감한다”는 약속보다 문제 후보와 필요한 근거, 사람이 승인할 조치를 분명히 하는 쪽이 좋겠습니다.

실제 API나 MCP를 연결하려면 권한과 조회 범위, 데이터 전송 위치를 별도로 정합니다. 역할 문서에 도구 이름이 적혀 있다고 연결 권한이 생기지는 않습니다. 인증 정보는 문서와 대화에 붙이지 않고 연결 환경에서 관리하세요. 보고서를 공유할 때도 계정 식별자와 고객 정보를 제거하고 검토에 필요한 설정과 집계만 남기는 편이 좋습니다.

개발 역할과 운영 역할을 같은 저장소에서 찾을 수 있다는 점은 이 모음의 흥미로운 부분입니다. 예약 기능의 신청 성공을 검증한 뒤 실제 문의로 어떻게 집계되는지까지 관점을 이어 갈 수 있습니다. 다만 각각의 검토 결과와 승인 범위를 분명히 남겨야 다음 담당자가 근거를 이해할 수 있습니다. 역할을 늘리는 만큼 전달할 자료도 함께 설계해 보세요.

공식 예시에서 인계 방식 읽기

저장소의 Nexus Spatial Discovery Exercise는 여러 역할이 제품 기회를 검토하는 공식 예시 문서입니다. 시장, 기술 구조, 브랜드, 고객 지원, UX와 실행 계획 같은 관점이 한 결과물에 모여 있습니다. 역할별 출력과 마지막 종합 부분을 읽으며 어떤 정보를 주고받는지 살펴보기 좋습니다.

이 자료는 제품 탐색 연습의 산출물로 읽습니다. 안에 담긴 시장 규모나 경쟁 평가를 현재 사업 판단의 확정 근거로 가져오기보다, 서로 다른 역할의 결론을 어떻게 묶는지 보는 데 초점을 맞춰 보세요. 특히 역할별로 다른 가정이 나왔을 때 종합 문서가 그것을 드러내는지, 추가 판단으로 남기는지 확인할 수 있습니다.

작은 팀에 적용한다면 같은 수의 역할을 재현할 필요는 없습니다. 사용자 문제를 보는 역할과 구현 가능성을 보는 역할을 먼저 골라 각자 필요한 입력을 적습니다. 그다음 두 결과가 충돌하는 조건을 모으고 결정할 담당자를 정해 보세요. 공식 예시의 쓰임은 인원 규모를 따라 하는 것보다 결과물 사이의 연결을 읽는 데 있습니다.

README에는 스타트업 MVP와 기업 기능 개발, 광고 계정 인수 등 다른 역할 조합도 있습니다. 현재 프로젝트의 병목과 가까운 예를 고른 뒤 필요한 역할만 남길 수 있습니다. 개발 순서를 더 구체화하고 싶다면 Superpowers, 검증과 규칙을 환경에 붙이고 싶다면 ECC를 함께 비교해 보세요. 역할, 절차, 실행 환경을 나눠 생각하면 겹치는 지침을 줄이기 좋습니다.

어떤 팀에 맞나

장점: 한 사람이 개발과 디자인, 검증과 운영을 오가거나 여러 담당자의 검토 관점을 정리하려는 팀이 살펴볼 만합니다. 역할 문서를 출발점으로 임무와 산출물을 구체화할 수 있고, 필요한 영역만 선택할 수 있습니다. 특히 구현 결과를 다음 담당자에게 어떻게 설명할지 고민하는 빌더에게 역할별 예시가 도움이 됩니다.

운영 부담: 역할 문서를 읽고 기존 스택과 팀 정책에 맞게 조정할 시간이 필요합니다. 일반적인 임무와 예시 명령, 목표 지표가 현재 작업에 맞는지 확인해야 합니다. 여러 역할을 실행하면 모델 호출과 결과 검토가 늘어나며, 상충하는 제안을 정리할 담당자도 필요합니다. 처음에는 역할 두 개와 인계할 결과물 하나로 범위를 좁혀 보세요.

실행 환경: 역할 모음 자체와 코딩 도구의 기능은 구분합니다. 실제 파일 접근과 명령 실행, 서비스 연결, 기억의 지속성, 동시 작업 방식은 사용하는 도구에서 정합니다. 다른 도구로 옮길 때는 변환 파일과 설치 경로를 살펴보고, 역할을 읽었다는 응답보다 실제 사용할 수 있는 기능을 확인합니다. 공통 폴더에 설치한 역할이 다른 프로젝트에 미치는 영향도 운영 범위에 넣습니다.

라이선스와 책임: agency-agents 저장소는 MIT입니다. 수정·재배포할 때 LICENSE의 조건을 확인하고, 연결 도구와 모델 서비스의 이용 조건도 함께 살펴봅니다. 역할 이름에 전문가가 들어가더라도 실제 전문 검토와 조직의 승인 책임이 자동으로 넘어가지는 않습니다. 코드와 계정 설정을 바꾸는 결정은 원래 담당자의 검토 절차에 연결해 두면 좋겠습니다.

원문과 함께 읽기

마치며

하이프마크 빌더 커뮤니티는 앞으로도 이렇게 직접 살펴본 AI 도구와 오픈소스를 꾸준히 공유하려고 합니다. 빌더 여러분께 도움이 될 좋은 자료들을 계속 모아 나누겠습니다.

오픈채팅방: AI빌더스
도입 상담·문의: 문의 폼
다음 글 받아보기: 블로그 RSS · AI 자료실