제품

AI 참모장: 전문가들을 조율하고 모든 것을 칸반으로 추적하는 에이전트

에이전트 하나에 일을 맡기는 방식은 요청이 조사와 글쓰기를 모두 요구하기 전까지는 잘 작동합니다. 이 시나리오는 작은 팀을 구성합니다. 나누고 검토하는 참모장, 조사하는 분석가, 글을 쓰는 작성자, 그리고 아무것도 놓치지 않도록 돕는 칸반입니다.

게시 날짜 2026년 10월 13일Atako 에이전트가 작성 · 검토·승인자

Romain Laodicina · Atako CTO

자주 묻는 질문

참모장으로 여러 AI 에이전트를 조율하려면 어떻게 하나요?

참모장 에이전트는 사람이 만나는 유일한 창구입니다. 요청마다 칸반 카드를 만들고, 조사와 글쓰기로 나누며, 에이전트 간 채널로 분석가와 작성자에게 위임하고, 각 결과를 검토해 부족한 것은 돌려보냅니다. 결과물이 좋으면 위키 페이지로 게시하고 카드를 완료로 옮기며 채팅으로 요약합니다. 매주 월요일에는 주간 리뷰를 작성합니다.

연결된 도구

Atako 에이전트 간 채널
세 에이전트는 기본 제공 채널로 서로 대화합니다. 참모장이 위임하고 결과를 받으며, 전문가들은 참모장에게만 응답합니다. 설정할 것이 없습니다.
Atako 프로젝트: 칸반과 위키
“참모장 사무실” 프로젝트에는 요청마다 카드가 하나씩 있으며, 해야 할 일에서 진행 중을 거쳐 완료로 이동합니다. 결과물은 위키 페이지로 보관됩니다.
에이전트의 웹 브라우저
분석가는 내장 브라우저로 조사하고 출처를 교차 확인합니다. 연결할 검색 도구도, 구독할 데이터 제공업체도 필요 없습니다.

단계별 워크플로

에이전트가 할 수 있는 일

요청마다 칸반 카드를 하나 만들고 조사 부분과 글쓰기 부분으로 나눕니다
맥락, 기대 결과, 기한을 붙여 각 부분을 에이전트 간 채널로 알맞은 전문가에게 위임합니다
웹을 조사해 모든 사실에 출처가 달린 종합 결과를 참모장에게 돌려줍니다
조사 내용을 바탕으로, 그 안에 없는 것은 덧붙이지 않고 결과물을 위키 페이지로 작성합니다
각 결과를 검토하고, 부족하면 구체적인 의견과 함께 돌려보낸 뒤 카드를 완료로 옮깁니다
채팅으로 요약하고 매주 월요일에 주간 리뷰를 작성합니다

사람이 하는 일

설정할 때 회사, 우선순위, 첫 요청을 한 번만 설명합니다
이후의 모든 요청은 전문가와 이야기하지 않고 참모장에게 보냅니다
결과물을 읽고 어떻게 활용할지 결정합니다

이 시스템을 Atako에 배포하기

배포되는 에이전트

Chief of staff
Receives requests, splits them, delegates to the research analyst and the writer, checks their work and tracks each request on the project kanban.
Research analyst
Runs web research for the chief of staff and returns a sourced summary. Answers to the chief only.
Writer
Writes the deliverables (notes, internal emails, minutes) as wiki pages, on the chief of staff's request.

2단계로

1
상황을 알려주세요
Your company and this quarter's priorities · First request.
2
에이전트 시작
첫 결과는 프로젝트에 나타납니다.

이 시스템 배포하기

아직 계정이 없나요? 계정을 만들면 체험이 시작되고, 시나리오는 그 뒤에 설정합니다.

두세 명으로 이루어진 팀이 에이전트를 쓰기 시작하면, 처음 보이는 반응은 모든 것을 같은 에이전트에게 맡기는 것입니다. 질문 하나라면 통하지만, 조사, 검토, 글쓰기가 이어지는 일에서는 훨씬 덜 작동합니다. 에이전트가 역할을 뒤섞고, 한 단계를 빠뜨리고, 요청이 어디까지 갔는지 아무도 모르게 됩니다. 사람들은 이 문제를 오래전에 참모장으로 해결했습니다. 요청을 받고, 나누고, 돌아온 것을 검토하고, 보고하는 사람입니다. 멀티 에이전트 시스템은 같은 발상을 이어받습니다.

영감: 프로젝트마다 하나의 오케스트레이터

출발점은 Hermes Agent 사용자들이 보고한 사례이며, “참모장: 프로젝트별 멀티 에이전트 오케스트레이터”라는 제목의 카드에 요약되어 있습니다. 아이디어는 이렇습니다. 만능 에이전트 대신, 전문가들을 조율하는 일만 맡은 에이전트를 두고 프로젝트를 공유 작업 공간으로 삼습니다. 참모장은 직접 조사하거나 쓰지 않고, 나누고, 위임하고, 검토하고, 추적합니다.

여기서 가져온 것은 가독성의 이득입니다. 모든 요청이 카드가 되고, 모든 카드에는 상태가 있으며, 모든 결과물은 위키에 주소가 생깁니다. Atako는 이 구조를 세 에이전트와 칸반으로 구현하고 전문가들을 참모장 뒤에 둡니다. 사용자에게는 창구가 하나이고 요청마다 흐름이 하나입니다.

세 에이전트가 하는 일

이 시나리오는 역할이 다른 세 에이전트를 배포하며, 이들은 Atako의 에이전트 간 채널로 서로 대화합니다.

참모장은 사용자의 요청을 받습니다. 요청마다 프로젝트 칸반의 “해야 할 일” 열에 카드를 만들고, 조사 부분과 글쓰기 부분으로 나눈 뒤, 맥락과 기대 결과와 기한을 알려 주며 해당 전문가에게 위임합니다. 카드는 “진행 중”으로 이동합니다. 결과가 돌아오면 검토합니다. 주장에 출처가 있는지, 요청에 답하는지, 회사의 맥락과 일관되는지입니다. 아니라면 구체적인 의견을 붙여 돌려보냅니다. 문제가 없으면 결과물이 위키 페이지로 게시되도록 하고, 카드에 링크를 넣은 다음 “완료”로 옮깁니다. 매주 월요일에는 완료, 진행 중, 막힌 요청을 정리한 “주간 리뷰” 페이지를 작성합니다.

조사 분석가는 참모장이 요청한 웹 조사를 수행합니다. 공식 출처를 우선하고, 가능하면 중요한 사실을 교차 확인하며, 출처마다 날짜를 적고, 확정된 것과 불확실하거나 찾지 못한 것을 구분합니다. 응답하는 대상은 참모장이며, 사용자에게 직접 응답하지 않습니다.

작성자는 조사 내용과 지침을 결과물로 만듭니다. 메모, 사내 이메일, 회의록 같은 것입니다. 프로젝트 위키에 쓰고, 결론부터 시작하며, 출처를 유지하고, 받은 자료에 없는 사실은 덧붙이지 않습니다.

에이전트가 하지 않는 일

한계는 설계의 일부입니다. 세 에이전트 중 어느 쪽도 회사 밖으로 메시지를 보내지 않습니다. 작성자는 초안을 만들 뿐 발송하지 않습니다. 전문가들은 사람과 직접 대화하지 않으므로 상충하는 요청을 피할 수 있습니다. 어떤 에이전트도 카드를 삭제하지 않으며, 검증되지 않은 주장을 사실처럼 제시하지 않습니다. 출처가 없으면 결과에 그렇게 적힙니다. 참모장은 제안할 뿐 사용자를 대신해 결정하지 않습니다. 이것이 휴먼 인 더 루프 설계의 원칙입니다.

Atako에서 설정하는 방법

이 활용 사례의 페이지에서 배포는 네 단계로 진행됩니다.

회사 설명하기. 회사가 하는 일과 이번 분기의 우선순위를 몇 줄로 적습니다. 이 맥락으로 각 에이전트가 무엇이 중요한지 판단합니다.
첫 요청 작성하기. 메모, 비교, 종합 같은 구체적인 요청입니다. 팀의 첫 전체 순환을 시작합니다.
배포하기. 한 번의 작업으로 세 에이전트와 칸반이 있는 “참모장 사무실” 프로젝트가 만들어집니다. 연결할 연동은 없습니다.
첫 카드 따라가기. 참모장이 카드를 만들고, 위임하고, 검토하고, 완료로 옮깁니다. 전문가들은 참모장에게 인사한 뒤 요청을 기다립니다.

Atako의 시나리오 배포 창

아직 계정이 없다면 계정을 만드는 순간 체험이 시작되고, 곧바로 시나리오가 설정됩니다. 관리자가 에이전트 생성을 허용하지 않았다면, 배포 과정에서 그 사실을 알려 주고 거기서 멈춥니다.

결과를 볼 수 있는 곳

작업은 세 곳에서 따라갈 수 있습니다. “참모장 사무실” 프로젝트의 칸반에서는 각 요청이 카드이며, 카드가 놓인 열이 진행 상황을 알려 줍니다. 같은 프로젝트의 위키에서는 결과물이 카드에 링크된 페이지가 되고, 주간 리뷰가 매주 월요일에 추가됩니다. Atako 플로어에는 세 에이전트의 현재 작업이 표시되므로, 묻지 않아도 누가 무엇을 하고 있는지 알 수 있습니다.

에이전트가 만든 첫 결과

새 요청은 참모장의 채팅에 쓰면 됩니다. 요청은 같은 대화 안에서 처리되며, 지금까지 한 일에 대한 기억도 그대로 이어집니다.

안전장치

접근 범위는 의도적으로 좁습니다. 세 에이전트에게는 연동이 없어서 사용자의 메일함, CRM, 어떤 계정에도 닿지 못합니다. 쓰기 권한은 시나리오를 위해 만든 칸반과 위키가 있는 프로젝트뿐입니다. 에이전트 간 교환은 내부 채널을 거치며, 앱에서 읽을 수 있게 남습니다.

사람의 검증은 결정의 지점에 있습니다. 결과물은 사용하기 전에 사용자가 읽고, 마음에 들지 않으면 채팅에서 재작업을 요청하며, 무엇이 회사 밖으로 나갈지 사용자가 결정합니다. 참모장은 전문가들의 작업을 검토하지만, 결과를 판단하는 것은 사용자입니다.

기대할 수 있는 것

첫 요청은 에이전트 하나를 쓸 때보다 몇 분 더 걸립니다. 참모장과 전문가들이 주고받는 시간입니다. 이득은 그다음 요청부터 나타납니다. 모든 작업이 카드에 기록되고, 출처가 제시되며, 사용자가 읽기 전에 참모장이 이미 검토를 마칩니다. 작은 팀에게는 여러 대화에 흩어진 에이전트 답변 모음과, 서류를 제대로 관리하는 사무실의 차이가 됩니다. 요청이 두 전문 분야에 맞지 않는다면 참모장에게 말해 주십시오. 현재 팀으로 무엇을 할 수 있는지 알려 줄 것입니다.

이 시스템을 Atako에 배포하기