코칭할 수 있는 에이전트: Asana가 Claude로 사람과 에이전트가 함께 일하는 팀을 만드는 방법

이 글은 사람과 에이전트가 함께 일하는 팀을 다루는 시리즈의 세 번째 글입니다. 첫 번째 글에서는 Anthropic에서 멀티플레이어 AI를 활용하며 얻은 교훈을, 두 번째 글에서는 Slack이 업무 대화를 에이전트에게 필요한 맥락으로 바꾸는 방식을 소개했습니다. 이번 글에서는 팀이 일하는 바로 그 플랫폼 안에서 에이전트가 함께 일할 때 무엇이 달라지는지 살펴봅니다.

Asana 팀은 AI 에이전트를 도입하기 오래전부터, 팀이 협업하는 방식에 구조와 책임을 녹여내는 방법을 계속 다듬어 왔습니다. 그 결과물이 Work Graph® 모델입니다. 이 모델은 모든 작업, 프로젝트, 목표, 대화를 관계망 위에 배치하고, 각각에 담당자와 기여자, 의존 관계를 정해 둡니다.

AI 에이전트를 만들기 시작하면서 Asana는 AI를 위한 별도의 맥락 구조를 추가하는 대신, 에이전트도 같은 모델 안에서 일하게 하기로 했습니다. 에이전트는 정해진 역할을 맡고, 작업을 배정받고, 메시지를 읽고 쓰며, 사람 협업자와 나란히 활동 피드에 나타납니다. 다만 에이전트가 접근하고 공유할 수 있는 범위에는 추가 안전장치를 두었습니다.

Asana의 최고제품책임자(CPO) 아르납 보스에게 Asana 내부 팀이 Claude를 어떻게 쓰고 에이전트와 어떻게 함께 일하는지 들어 보았습니다. 복잡한 작업에는 Claude 모델이 쓰입니다. 각 에이전트가 역할과 접근 권한을 얻는 방법, 에이전트를 훈련하는 사람, 모든 구성원이 작업 과정을 볼 수 있게 하는 방법, 그리고 Asana의 사람-에이전트 팀에서 에이전트가 맡는 업무 유형을 다뤘습니다.

에이전트가 움직이기 전에 먼저 생각을 정리하고 업무를 구조화하세요

Asana 직원에게 Claude는 기본 AI 도구입니다. Google Drive, Slack, 그리고 물론 Asana까지 직원들이 일할 때 쓰는 플랫폼과 모두 연결되어 있습니다.

아르납은 이렇게 말합니다. "사람은 정리되지 않은 데이터를 바탕으로 하루를 이해해 나갑니다. 머릿속 아이디어, Slack 대화, Zoom 회의 녹화, Databricks 보고서, Google Docs의 정보 같은 것들이죠. 이런 내용을 Claude와 이야기하며 정리한 다음, Asana의 프로젝트와 작업이라는 구조에 한꺼번에 옮겨 담을 수 있습니다." 구조가 갖춰지면 에이전트가 그 위에서 일할 수 있습니다. 이때 필요한 세 가지 기능은 이 시리즈 첫 번째 글 효과적인 사람-에이전트 팀 만들기에서 설명한 지속적 메모리, 에이전트 고유의 자격 증명, 공유 맥락입니다.

실천 방법

• 내 아이디어에서 시작하세요. 아이디어, Slack 대화, 여러 문서에 흩어진 메모처럼 하루 동안 쌓인 정리되지 않은 조각들을 Claude에게 가져가세요.
• Claude와 토론하세요. Claude를 생각 파트너로 삼아, 다음 단계가 분명해질 때까지 아이디어를 함께 짚어 보세요.
• 실행할 항목은 Work Graph에 기록하세요. 실행 가능한 내용은 프로젝트와 작업으로 옮겨, 에이전트와 동료가 바로 이어받을 수 있게 하세요.

모든 에이전트에게 역할과 필요한 도구, 접근 권한을 주세요

Asana 직원은 어떤 프로젝트에서든 사람 동료와 일하듯 AI 에이전트와 함께 일할 수 있습니다. 팀 구성은 사람이 설계하며, 직원마다 팀 목표에 도움이 될 추천 에이전트 목록을 받습니다.

에이전트는 콘텐츠 작가, 인사이트 분석가, 프로젝트 매니저, 업무 접수 전문가, 캠페인 분석가, 캠페인 코디네이터처럼 역할이나 업무 유형별로 만들어집니다. 각 에이전트에는 고객이 해당 업무를 수행하는 방식에 대한 Asana의 연구를 토대로 한 스킬이 미리 갖춰져 있고, Hubspot이나 문서 드라이브처럼 필요한 연동도 함께 제공됩니다.

에이전트마다 프로필 페이지가 있어, 이름과 목적, 사용할 수 있는 사람, 관리자, 지침, 스킬, 연동, 권한을 확인할 수 있습니다. Asana는 접근 권한을 의도에 맞게 설정할 수 있는 도구를 제공합니다. 아르납은 "Asana는 범위가 한정된 작업 공간입니다. 전체가 아니라 특정 프로젝트 몇 개, 특정 문서 몇 개, 또는 문서와 앱을 조합해서 접근 권한을 줄 수 있습니다"라고 말합니다.

에이전트도 사람 사용자처럼 명시적인 접근 제어를 받지만, 안전장치가 하나 더 있습니다. Asana에 따르면 에이전트의 실질적인 접근 범위는 에이전트를 실행하는 사람의 권한을 넘지 못합니다. 덕분에 에이전트가 공개 콘텐츠에는 폭넓게 접근하면서도, 비공개 맥락에서 에이전트가 학습한 정보를 다른 사람이 열람할 위험은 최소화할 수 있습니다.

실천 방법

• 에이전트를 만들기 전에 역할부터 정의하세요. 팀에서 에이전트가 맡을 수 있는 업무 유형을 생각해 본 뒤, 신입 사원의 첫 분기를 설계하듯 에이전트의 목적과 지침, 그리고 맡을 구체적인 업무를 적어 두세요.
• 접근 범위를 한정하세요. 에이전트가 읽을 수 있는 프로젝트와 문서, 접근할 수 있는 애플리케이션, 수행할 수 있는 동작을 정하세요.
• 사용자와 관리자를 따로 지정하세요. 에이전트와 함께 일하는 사람은 많아도 되지만, 에이전트의 접근 범위와 동작을 관리하는 사람은 지정된 소수여야 합니다.

에이전트와 일하는 사람과 에이전트를 훈련하는 사람을 구분하세요

Asana는 자사 에이전트를 AI 팀원(AI teammates)이라고 부르는데, 이들의 핵심 기능은 공유 메모리입니다. 에이전트가 이전 지시를 기억해 두면 여러 사용자가 그 메모리를 재사용해 작업을 더 빨리 끝낼 수 있습니다. 아르납은 "AI 팀원은 팀의 한 사람처럼 코칭하고 훈련할 수 있습니다"라고 말합니다.

공유 메모리에는 역할에 따른 제한이 하나 있습니다. 누구나 작업에 대해 에이전트에게 피드백을 줄 수 있지만, 피드백을 영구 메모리에 반영하거나 되돌리고 삭제할 수 있는 사람은 관리자와 편집자뿐입니다. 그 외 사용자의 피드백은 현재 작업에만 적용됩니다.

아르납은 이런 구분이 의도된 것이라고 설명합니다. Asana에서는 커뮤니케이션 팀이 회사의 목소리와 톤을 책임지므로, 글을 쓰는 에이전트의 편집자와 관리자도 이 팀이 맡습니다. 아르납은 그 에이전트와 함께 초안을 쓸 수는 있지만, 에이전트의 동작을 바꿀 수는 없습니다. 게다가 대부분의 사람은 내부 구조를 건드릴 필요가 전혀 없습니다. "팀원 모두가 스킬, 동작, 메모리 같은 개념을 이해할 필요는 없습니다. 팀에서 한두 명이 전문가가 되어 설정을 제대로 해 두면, 나머지 팀원 모두가 앞으로 같은 혜택을 누리게 됩니다."

실천 방법

• 에이전트를 누가 훈련하고 누가 사용할지 정하세요. 팀이 쓸 에이전트를 만드는 데 도움을 줄 수 있는 사내 전문가를 찾으세요. 나머지 구성원은 작업에 대해 피드백을 줄 수 있지만, 에이전트 자체를 고칠 수는 없습니다.
• 편집자는 전문성에 맞게 지정하세요. 브랜드 톤이나 기획 규칙처럼 에이전트가 적용하는 기준을 관리하는 팀이 해당 에이전트를 소유(또는 관리)합니다.
• 일하면서 메모리를 쌓아 가세요. 피드백은 시간이 지날수록 에이전트를 개선합니다. 남겨 둘 만한 결정은 기억하게 하고, 더 이상 유효하지 않거나 사실이 아닌 내용은 삭제하도록 요청하세요.

에이전트의 작업은 모두가 볼 수 있는 곳에 두세요

Slack의 에이전트가 채널에 투명하게 글을 올리는 것처럼, AI 팀원에게 작업을 배정하면 에이전트가 그 작업을 수행 중이라는 사실과 작업 내용을 누구나 볼 수 있습니다. 에이전트는 조사 계획과 수행한 단계를 포함한 활동 내역을 게시합니다. 그래서 해당 작업에 접근할 수 있는 사람은 누구나 에이전트가 한 일을 읽고, 댓글을 달고, 원하는 결과 쪽으로 방향을 조정할 수 있습니다.

Asana 커뮤니케이션 팀이 강연 준비용 브리핑 문서를 검토해 달라고 요청했을 때, 아르납은 해당 작업에서 에이전트를 @멘션하고 이전 강연의 토크 트랙도 함께 반영해 달라고 요청했습니다. 그 에이전트를 여러 번 써 봤고 참고할 자료도 이미 Work Graph에 있었기 때문에 메시지는 짧았습니다. 커뮤니케이션 팀 동료는 그의 요청과 에이전트의 응답을 볼 수 있었고, 같은 시점에 에이전트와 직접 대화를 주고받을 수도 있었습니다.

아르납은 이렇게 말합니다. "AI를 아주 능숙하게 다루는 사람이라면 일대일로 AI 에이전트와 작업해서 좋은 결과물을 얻고, 그 문서를 Slack이나 Asana에 다시 올릴 수도 있겠죠. 하지만 그러면 그 내용을 검토하는 다른 사람들은 어떤 프롬프트를 썼는지, 어떤 대화가 오갔는지 알 수 없습니다. 제가 준 지침 중 일부에 동의하지 않아도 의견을 맞출 방법이 없습니다." 공유 작업에서는 요청, 반박, 결과물이 한곳에 모여 있고, 결과물을 검토하는 사람이 그 결과를 만든 지침을 직접 수정할 수도 있습니다.

실천 방법

• 팀이 작업을 검토하는 곳에 에이전트를 투입하세요. 그러면 요청, 에이전트의 수행 단계, 결과가 한곳에 모여, 검토자가 지침이나 결과물을 바꿀 수 있습니다.
• 에이전트가 한 작업임이 드러나게 하세요. 그래야 사람 동료가 아니라 AI 에이전트가 한 작업이라는 점을 모두가 알 수 있습니다.
• 검토자가 에이전트의 작업을 코칭할 수 있게 하세요. Asana의 에이전트는 계획과 단계를 공유 작업에 게시하므로, 다른 검토자가 추가 지시나 피드백을 줄 수 있습니다.

Asana가 에이전트에게 맡긴 세 가지 업무

Asana에서는 문서를 생성하거나 복잡한 작업을 수행하는 모든 에이전트 업무를 Claude가 뒷받침합니다. 회사 곳곳의 서로 다른 팀에서 가져온 사례 세 가지를 소개합니다.

Slack 채널의 제품 질문에 답하기

Asana가 새 기능을 출시하면 영업 담당자와 고객 성공 담당자는 공유 Slack 채널에 질문을 올립니다. AI 팀원이 생기기 전에는 같은 질문이 반복해서 올라왔고, 그때마다 해당 분야 전문가를 @멘션해야 했습니다. 아르납은 검색 가능한 지식 베이스도 현실적인 해법이 아니었다고 말합니다. 답변이 미묘하고 계속 바뀌기 때문입니다. 그는 "제품의 현재 상태가 무엇인지 어느 정도 판단하고 기준을 세워 주는 작업이 필요합니다"라고 설명합니다.

질문은 여전히 Slack으로 들어옵니다. 현장에서 가장 물어보기 쉬운 곳이기 때문입니다. 이제는 채널에 설치된 Asana 앱이 질문마다 Asana 작업을 만들고, 에이전트가 그 작업을 이어받습니다. 승인된 안내가 있으면 에이전트는 출처 링크와 함께 답변합니다. 승인된 답변이 없고 질문이 제품의 빈틈을 가리키는 경우에는, 에이전트가 제품팀의 접수 프로젝트에 작업을 만들고 백로그에 추가합니다. 같은 질문이 계속 올라와서 에이전트가 같은 기록을 반복해 게시하게 되면, 교육 자료와 문서를 업데이트하라는 작업을 인에이블먼트 팀에 만들어 줍니다.

이 프로세스 덕분에 인에이블먼트 팀은 소중한 시간을 아껴 전략적이고 우선순위가 높은 업무에 집중할 수 있고, 다른 조직에도 인사이트를 전달할 수 있습니다. 예를 들어 신제품의 특정 주제에 질문이 몰린다면, 인에이블먼트 팀이 추가 교육이나 정보 제공에 힘써야 한다는 신호가 됩니다.

갱신 위험 고객을 경영진에게 브리핑하기

Asana의 최고고객책임자(CCO) 조시 압둘라는 예전에 경영진을 위한 주간 갱신 위험 고객 브리핑을 직접 만들었습니다. 이 브리핑은 고객 성공 매니저(CSM)들이 갱신 위험 고객을 표시하고 상황이 바뀔 때마다 계정을 업데이트한 내용을 바탕으로 했습니다. 전 세계 수천 곳의 고객에 걸쳐 업데이트가 쏟아졌기 때문에, 이를 종합하는 전담자 없이는 최신 상태를 유지하기 불가능했습니다. 지루한 작업인 데다 대응도 늘 사후에 이뤄질 수밖에 없었습니다. 아르납은 "조시는 데이터에서 문제가 처음 드러났을 때가 아니라, 리더들이 알려 줘야 문제를 알게 됐습니다"라고 말합니다.

고객 경험 조직은 Asana 안에 At-Risk Renewal이라는 에이전트형 AI 팀원을 만들었습니다. 이 에이전트는 전 세계 포트폴리오의 갱신 위험 작업을 모두 읽고, 각 CSM의 업데이트와 상태 메모, 댓글까지 살펴본 뒤, 긍정적 흐름, 부정적 흐름, 권장 후속 조치의 세 가지 항목으로 정리한 일일 요약을 만듭니다. 먼저 전 세계 기준으로 정리한 다음 지역별로 나누고, 매일 아침 최고고객책임자와 최고매출책임자(CRO), 각 지역 고객 성공 리더에게 자동으로 전달합니다. 요약이 공유 공간에 올라오기 때문에 리더들은 특정 계정의 이탈 예측 뒤에 어떤 선행 지표가 있었는지 같은 후속 질문을 할 수 있습니다. 또 다음 실행 때 반영하도록 에이전트에게 기억할 내용을 코칭할 수도 있어, 보고서는 매일 아침 나아집니다.

아르납은 이렇게 말합니다. "각자 Claude에게 보고서를 만들게 할 수도 있을 겁니다. 하지만 보고서가 표준화되고, 공유 워크스페이스가 있고, 실행할 때마다 계속 좋아지는 단계까지는 어떻게 갈 수 있을까요?"

Command로 엔지니어링 사이클 계획하기

Asana가 자사 제품에 자동 코딩 루프를 돌렸을 때는 자동 생성된 변경 사항 때문에 사이클이 비대해져 사이클 타임과 릴리스가 지연됐습니다. 이 루프는 이제 소프트웨어 회사에서 흔한 방식이 되었습니다. 여러 채널에서 고객 피드백을 모으고, 종합하고, 코딩 에이전트가 이를 풀 리퀘스트(PR)로 바꾸도록 실행하는 것입니다. 아르납은 "이제 코드 생성은 병목이 아닙니다. 병목은 계획, 의사 결정, 다듬기 단계에 있습니다"라고 말합니다. Asana의 엔지니어링 조직은 이제 대규모 엔지니어링 팀을 관리하는 제품인 Command by Asana를 기반으로 일하며, 이 루프도 Command로 관리합니다.

Command의 팀 스페이스에는 한 제품을 담당하는 엔지니어 10~12명이 모입니다. 에이전트는 고객 피드백과 Slack의 팀 피드백 채널 댓글에서 추린 티켓으로 팀의 미계획 보드를 채웁니다. 이 보드에서 어떤 티켓을 사이클로 옮길지는 사람이 결정하고, Command는 낙관적, 균형, 보수적 추정치로 사이클의 완료 예상 시점을 예측합니다.

티켓은 사람에게도, 코딩 에이전트에게도 배정할 수 있습니다. 사이클 데이터가 모두 한곳에 있으므로 매니저는 채팅으로 릴리스가 왜 계획에서 벗어났는지, 어떤 트레이드오프를 하면 바로잡을 수 있는지 물어볼 수 있습니다. Command는 데이터를 근거로 어떤 요인이 신호를 만들고 있는지, 어떤 변경을 맞바꿔야 하는지 답합니다. 이 모든 정보는 Asana의 MCP 서버를 통해 공개됩니다. Claude 같은 어시스턴트가 데이터를 읽을 수 있게 해 주는 연결 통로이므로, 아르납이나 CTO 같은 사람은 Command를 열지 않고도 Claude에게 어떤 일이 계획대로 가고 있는지 물어볼 수 있습니다.

아르납은 이렇게 말합니다. "팀이 힘들이지 않고 함께 일할 수 있을 때 인류는 번영하며, 오늘날 모든 팀은 일부는 사람이고 일부는 에이전트입니다. 저희는 그런 일하는 방식을 위해 설계합니다. 사람과 에이전트가 함께 기반으로 삼을 수 있는 하나의 공유 맥락을 두고, 모든 에이전트에게 고유한 신원을 부여해 기여 내용과 접근 권한을 감사할 수 있게 하며, 에이전트가 학습한 내용을 오래 남는 기록으로 보관해 팀의 지식이 사라지지 않고 복리로 쌓이게 하는 것입니다."