Asana Dash 공개, AI 팀원을 같은 계획표에 묶는 Asana

Asana가 2026년 6월 4일 런던 Work Innovation Summit에서 "human-agent teams"를 위한 운영체제를 공개했습니다. 공식 발표의 표현은 큽니다. Asana는 사람이 AI 에이전트와 같은 계획, 같은 문맥, 같은 거버넌스 아래에서 핵심 업무를 운영하도록 제품군을 다시 묶었다고 설명합니다.

이번 발표의 제품 이름은 네 갈래입니다. 개인용 AI Chief of Staff인 Asana Dash, 팀 단위의 차세대 AI Teammates, 2026년 5월 인수한 StackAI 기반 cross-system 실행, 그리고 Asana Service Management, Command by Asana, Asana Client Management입니다. Asana는 Agentic Work Management, AI Teammates, AI Studio를 발표 당일부터 제공하고 Dash와 세 가지 신규 앱은 앞으로 몇 달 동안 단계적으로 제공한다고 밝혔습니다.

이 발표가 개발자에게 닿는 이유는 협업툴에 AI 요약 버튼이 하나 더 붙었다는 수준이 아니기 때문입니다. Asana가 노리는 자리는 ChatGPT식 개인 대화창이 아니라 업무의 source of truth입니다. 회의, Slack thread, 이메일, 티켓, PR, 문서, 고객 요청, 계약, 데이터베이스가 따로 흩어져 있을 때 에이전트가 무엇을 보고, 누구에게 승인받고, 어떤 기록을 남기는지를 제품 구조로 다루겠다는 주장입니다.

Asana Dash는 개인에게 붙는 입구입니다. 발표문은 Dash가 각 사용자의 목표, 우선순위, 주의가 필요한 일을 이해하고, 회의와 Slack thread와 이메일의 후속 작업을 Work Graph 안의 구조화된 업무로 바꾼다고 설명합니다. 사용자가 모든 일을 직접 prompt로 정리하는 대신 Dash가 적절한 AI Teammate를 연결해 특정 task나 project를 앞으로 밀도록 설계됐다는 설명입니다.

팀 단위에서는 AI Teammates가 전면에 섭니다. Asana의 AI Teammates 리소스는 이 제품을 "side tab"이 아니라 업무 안에 사는 specialized agents라고 부릅니다. 2026년 3월 공개된 설명에 따르면 Marketing, IT, Ops용 21개 out-of-the-box agent와 no-code builder가 제공됩니다. 예시는 Campaign Brief Writer, Workflow Optimizer, Compliance Specialist, Launch Planner, Bug Investigator, Sprint Coach까지 이어집니다.

Asana가 제시한 베타 수치는 꽤 공격적입니다. 회사는 200개 이상 조직에서 AI Teammates를 테스트했고, 93%의 AI Teammates가 view나 comment가 아니라 full edit access를 받았다고 밝혔습니다. 또 팀이 작업을 2배 빠르게 끝냈고, AI Teammates가 관리한 task는 명확한 owner를 가질 확률이 3.2배, deadline이 정의될 확률이 2.6배 높았다고 설명했습니다. 이 숫자는 독립 벤치마크가 아니라 Asana 자료이므로, 도입 판단에서는 고객사 권한 모델과 감사 로그를 함께 확인해야 합니다.

StackAI는 이번 발표의 실행 범위를 넓히는 부품입니다. Asana는 2026년 5월 28일 StackAI 인수를 완료했습니다. 인수 발표에서 StackAI는 ERP, CRM, ITSM, Salesforce, AWS, Docusign, Oracle, 문서 시스템을 읽고 행동하는 no-code AI workflow 플랫폼으로 설명됐습니다. Asana는 AI Teammates가 Work Graph의 context를 StackAI workflow로 가져가고, 실행 결과와 action을 다시 Asana로 돌려보낸다고 말했습니다.

이 조합은 에이전트 시장에서 자주 생기는 빈틈을 겨냥합니다. 개인 사용자는 Claude Code, Codex, ChatGPT, Gemini CLI 같은 도구에서 자기 세션과 파일을 조율할 수 있습니다. 팀으로 넘어가면 한 사람의 에이전트가 만든 결과를 다른 사람의 에이전트가 어떻게 이어받는지, 누가 승인했는지, 어느 프로젝트의 최신 상태가 진짜인지가 곧 병목이 됩니다. 6월 4일 Reddit의 EngineeringManagers와 aiToolForBusiness 게시물도 같은 질문을 던졌습니다. "한 사람의 agent output이 다른 사람의 agent input이 될 때, 인간이 여전히 접착제인가"라는 문제입니다.

Asana의 답은 에이전트를 업무 기록 안에 넣는 쪽입니다. AI Teammates 설명은 private chat이 아니라 project 안에 agent가 살고, 한 사람이 priority를 바꾸면 roadmap이 팀 전체에 갱신된다고 말합니다. 이 설계가 제대로 작동하려면 agent memory가 개인 대화 내역이 아니라 조직의 permissioned work data를 기준으로 움직여야 합니다. 그래서 Asana는 "shared memory", "multiplayer coordination", "governance"를 반복해서 전면에 놓습니다.

개발팀용으로 예고된 Command by Asana는 이 발표에서 가장 직접적인 developer tools 신호입니다. 발표문은 Command를 "planning and product development system for humans and agents"라고 설명합니다. 과거 ticket, PR, meeting, note의 context에서 spec이 작성됩니다. Engineering manager는 backlog를 release date와 capacity, velocity에 맞춰 시뮬레이션하고, leader는 live dashboard에서 숨은 dependency를 확인하는 구조입니다.

이 설명은 Jira Product Discovery, Linear, GitHub Projects, Aha!와 바로 부딪힙니다. 개발 조직은 이미 issue tracker와 source hosting, docs, incident tool을 갖고 있습니다. Asana가 Command로 들어가려면 "스펙을 잘 써준다"보다 더 구체적인 이점이 필요합니다. 예를 들어 PR의 실제 변경 범위와 ticket의 business objective가 어긋날 때 누가 경고하는지, release blocker가 customer commitment와 연결될 때 어떤 권한으로 일정을 바꾸는지, agent가 만든 spec이 code review와 어떻게 연결되는지가 도입 기준이 됩니다.

Asana Service Management도 같은 논리입니다. Asana는 이 앱이 IT, HR, facilities 같은 service team의 ticketing과 project execution을 합치고, 요청이 다른 팀을 필요로 할 때 ticket에서 project로 context 손실 없이 이동한다고 설명합니다. 기존 ITSM 도구는 ticket queue에 강하고, 프로젝트 관리 도구는 cross-functional execution에 강합니다. Asana는 이 둘 사이의 handoff를 AI agent가 처리할 수 있는 업무 단위로 묶으려 합니다.

Asana Client Management는 agency와 professional services용 패키지입니다. 발표문은 branded client portal, intake부터 delivery까지 한곳에 모이는 communication, SOW creation, asset production, status draft, capacity planning을 언급합니다. 이 영역에서도 agent의 성패는 모델 성능보다 고객별 권한, 변경 이력, 승인 주체, 산출물 버전 관리에 걸립니다. 외부 고객이 보는 portal과 내부 agent가 보는 work graph 사이의 데이터 경계가 약하면 자동화 이득보다 보안 검토 비용이 커질 수 있습니다.

이번 발표의 보조 근거로 Asana는 과거 고객 사례도 제시합니다. AI Teammates 리소스에서 Morningstar는 복잡한 과거 데이터 분석이 몇 주에서 몇 시간으로 줄었다고 말했고, Human-I-T는 매일 수백 대 장비의 RAM, CPU, storage 정보를 검토하는 작업에서 수동 review가 2시간에서 30분으로 줄었다고 밝혔습니다. Human-I-T 사례에는 AI Teammate가 하루 14시간 이상 autonomous로 돌며 downstream reporting을 깨뜨리던 오류 유형을 제거했다는 설명도 붙어 있습니다.

이 고객 사례는 좋은 증거인 동시에 한계도 분명합니다. Morningstar와 Human-I-T의 인용은 Asana가 선별한 사례입니다. 도입팀은 "몇 시간 절감"보다 어떤 데이터가 agent에게 노출됐는지, agent가 write action을 할 때 어떤 approval gate를 거쳤는지, 실패한 실행이 어떤 로그로 남는지를 확인해야 합니다. AI agent가 팀 업무 안으로 들어오면 생산성 지표와 보안 지표가 같은 dashboard에서 다뤄져야 합니다.

커뮤니티 반응은 아직 작습니다. Hacker News와 GeekNews에는 6월 4일 발표 자체의 큰 토론이 확인되지 않았습니다. 다만 GeekNews의 Code w/ Claude 정리에는 Asana AI Teammates가 shared configuration, role-based access control, auditability를 갖춘 동료처럼 시스템에 들어온다는 세션 내용이 올라와 있습니다. 개발자 커뮤니티의 관심은 모델 이름보다 "agent가 어느 시스템 안에서 권한과 기록을 갖고 일하는가"로 이동하고 있습니다.

경쟁사는 많습니다. Microsoft Copilot은 M365 data와 업무 앱 안에서 개인과 팀 assistant를 넓히고, Atlassian Rovo는 Jira와 Confluence의 조직 지식을 agent로 연결합니다. Salesforce Agentforce와 ServiceNow agent 제품군은 enterprise workflow와 ticketing에 강합니다. Zapier Agents, Workato, Retool Workflows는 cross-app automation의 실행 면을 노립니다. Asana의 차별점은 Work Graph와 project ownership을 앞세워 "누가 무엇을 언제까지 맡았는가"를 agent 실행의 기본 데이터로 쓰겠다는 점입니다.

개발 조직이 이 발표를 볼 때 첫 질문은 "Asana를 써야 하는가"가 아닙니다. 더 나은 질문은 AI agent가 팀 업무에서 일할 때 어떤 shared state가 필요한가입니다. 개인 coding agent는 local repo, terminal, issue description, test result를 다룹니다. 팀 agent는 여기에 priority, owner, approval, customer commitment, incident risk, release date, compliance tag를 더해야 합니다. Asana 발표는 이 추가 데이터가 없으면 에이전트가 빠르게 움직일수록 handoff와 감사 비용이 커진다는 전제를 제품으로 만든 사례입니다.

두 번째 질문은 기존 시스템과의 중복입니다. 개발팀은 Jira나 Linear를 버리지 않을 수 있고, GitHub Projects를 계속 쓸 수 있습니다. 그러면 Command by Asana가 시스템 오브 레코드가 되는지, 아니면 여러 시스템 위의 orchestration layer가 되는지가 중요합니다. StackAI가 외부 시스템에 write action을 수행한다면, 실패한 action과 사람이 되돌린 action이 어느 도구에 남는지도 정해야 합니다.

세 번째 질문은 가격과 권한입니다. 발표문은 Dash와 신규 앱의 구체 가격을 공개하지 않았습니다. AI Teammates 리소스는 새 AI Teammates가 Starter, Advanced, Enterprise, Enterprise+ plan의 add-on으로 제공된다고 설명합니다. 베타에서 full edit access 비율이 93%였다는 수치는 신뢰의 강한 신호로 읽을 수 있지만, 보안팀에는 위험 표면의 확대이기도 합니다. agent가 edit 권한을 받는 순간, prompt 품질보다 permission boundary와 audit trail이 더 실무적인 기준이 됩니다.

Asana의 6월 4일 발표는 "AI가 프로젝트를 관리한다"는 단순한 슬로건보다 좁고 실용적인 질문을 남깁니다. 여러 사람과 여러 agent가 같은 목표를 향해 일할 때, 계획표는 어디에 있고, 누가 수정권한을 가지며, 어떤 실행이 기록으로 남는가. 개인 챗봇 경쟁이 모델 성능과 UI 속도를 겨뤘다면, 팀 agent 경쟁은 권한, shared memory, cross-system execution, 감사 로그의 품질로 갈릴 가능성이 높습니다.