2026년 5월, 업무 관리 도구 Asana는 기업이 코드를 쓰지 않고 AI 비서를 만들 수 있게 해 주는 StackAI를 7,500만 달러에 인수했다. 그 비서는 Salesforce, Slack, Google Workspace 같은 기존 시스템에 연결해 데이터를 가져온다. Asana 자체의 AI Teammates는 공식 페이지에 따르면 Gmail, Slack, HubSpot 등 연결된 10여 개 앱에서 검색하고, 읽고, 쓸 수 있다. 직접 만들 때는 역할을 정하고, 기술을 더하고, 접근 권한을 주며, 접근 범위는 만드는 사람이 지금 가진 권한을 바탕으로 고른다.
즉 엔지니어가 아닌 사람들도 여러 단계를 이어서 하는 AI 비서를 스스로 만들게 된다. 문턱이 낮아지면 쉽게 놓치는 것이 하나 있다. 어떤 도구에 연결됐다고 해서 AI가 그 도구 안의 모든 일을 해도 되는 것은 아니다.
같은 비서가 같은 시스템 안에서 프로젝트 진행 상황을 읽기만 할 수도 있고, 기한을 바꾸거나, 명단을 내보내거나, 고객에게 메일을 보낼 수도 있다. 결과가 전혀 다른 동작들에 같은 수준의 권한을 줘서는 안 된다. 그러니 비서를 만드는 사람은 권한을 연결이 아니라 동작마다 나눠 준다.
시험이 순조로워도 정상 경로가 통한다는 것만 보여 준다
고객 메일을 읽고, 작업을 만들고, 담당자를 정하고, 마지막에 답장을 보내는 비서를 만들었다고 하자. 몇 번 시험해 보니 순조로워서, 팀은 발송 전 사람의 확인을 빼고 매일 승인 버튼을 누르는 수고를 덜고 싶어진다.
시험이 순조로웠다는 것은 정상적인 흐름이 통한다는 뜻일 뿐이다. 내부 작업은 잘못 만들어도 지울 수 있다. 회사 이름으로 보낸 메일은 되돌릴 수 없고, 고객 관계와 계약상의 약속에 영향을 줄 수 있다. AI 보안 위험을 정리하는 국제 커뮤니티 OWASP는 AI가 쓰지 않는 기능을 갖는 것, 필요 이상의 권한을 갖는 것, 영향이 큰 동작이 독립적인 확인 없이 실행되는 것을 “과도한 대리 권한"의 세 가지 원인으로 꼽는다.
모든 동작을 세 단계로 나눈다
비서가 실제로 하는 동작을 하나씩 적고, 결과에 따라 나눈다.
자동으로 해도 됨: 민감하지 않은 데이터 읽기, 초안 작업 만들기, 내부 태그 붙이기. 잘못돼도 고치기 쉽지만 기록과 변경 요약은 남긴다.
범위를 정해 자동으로: 담당자 바꾸기, 기한 조정, 우선순위 바꾸기. 지정한 프로젝트만, 한 번에 최대 열 건 같은 조건을 정하고, 범위를 넘거나 다른 팀의 약속에 영향을 주는 것은 사람에게 넘긴다.
초안만 만들고, 이름 있는 사람이 내보냄: 고객에게 메일 보내기, 내용 게시, 결제 승인, 고객 명단 내보내기, 계정 권한 변경. 비서가 내용을 준비하고, 이름 있는 담당자가 받는 사람, 내용, 첨부를 확인한 뒤 보낸다. 그 사람이 없을 때는 시간 초과로 건너뛰지 말고, 눈에 보이는 대기 상태로 멈춘다.
승인 화면에 “계속할까요” 버튼만 있어서는 안 된다. 비서가 무엇을 하려는지, 어떤 데이터에 근거했는지, 끝난 뒤 되돌릴 수 있는지 보여야 한다. AI를 업무 흐름에 연결하기 전에, 언제 멈추고 사람에게 물을지 정해 둔다를 참고하자.
출시 전에 일부러 한 번 실패하게 한다
데이터가 맞고, 서비스가 정상이고, 승인자가 늘 있는 상황만 시험해서는 문제가 생겼을 때 안전하게 멈춘다고 말할 수 없다. 위험이 낮은 일 하나를 골라 실제 데이터를 건드리지 않은 채 각각 시험한다. 필수 항목이 빠진 경우, 두 출처가 서로 어긋나는 경우, 승인자가 답하지 않는 경우, 외부 시스템이 실패를 돌려주는 경우.
볼 것은 어디서 멈추는지, 그리고 사람이 넘겨받았을 때 무슨 일이 있었는지 알아볼 수 있는지다. 흐름이 절반만 끝났을 때, 예를 들어 작업은 만들어졌는데 알림이 가지 않았을 때의 정리 방법은 자동화가 중간에 멈췄다면, 다시 돌리기 전에 이미 무슨 일이 있었는지부터 확인한다을 참고하자.
단계 기준은 팀과 데이터에 따라 달라진다
단계를 나누는 기준은 팀과 데이터에 따라 정해지고, 여기의 예가 유일한 답은 아니다. 시험을 통과했다고 비서를 그 뒤로 마음대로 넓혀도 되는 것도 아니다. 연결할 도구를 늘리거나, 처리 건수를 높이거나, 내부 초안을 외부로 바로 보내도록 바꾸면 다시 나누고 다시 시험해야 한다.
Asana 페이지에는 누가 AI Teammates를 만들고 수정할 수 있는지 관리자가 정할 수 있다는 내용도 있다. 이 설정은 중요하다. 노코드 도구에서는 비서를 만드는 사람이 곧 그것이 무엇을 할 수 있는지 정하는 사람이기 때문이다.
AI 정리 카드
노코드 도구로 AI 비서를 만들었다(또는 만들 예정이다). 출시 전에 그 동작마다 권한을 나눠 두고 싶다.
판단 방법은 이 글에서 가져왔다: https://boosterminiclass.com/ko/posts/no-code-agent-builders-need-workflow-guardrails/
글의 관점은 이렇다. 어떤 도구에 연결됐다고 AI가 그 도구 안의 모든 일을 해도 되는 것은 아니다. 권한은 동작마다 준다. 자동으로 해도 되는 것, 범위를 정해 자동으로 하는 것, 초안만 만들고 이름 있는 사람이 내보내는 것. 출시 전에는 일부러 실패하게 해서 어디서 멈추는지 본다.
먼저 나에게 물어 달라. 비서가 처리할 흐름, 연결한 도구, 지금의 시험 상황.
그다음:
1. 비서가 도구마다 실제로 하는 동작을 하나씩 적을 것;
2. "자동으로 해도 됨", "범위를 정해 자동으로", "초안만 만들고 이름 있는 사람이 내보냄" 세 단계로 나누고 이유를 적으며, 두 번째 단계에는 범위 조건을 쓸 것;
3. 세 번째 단계의 동작마다 승인 화면에 보여야 할 정보와 담당자를 적을 것;
4. 네 가지 실패 상황의 시험을 설계할 것. 필수 항목 누락, 출처 불일치, 승인자 무응답, 외부 시스템 실패. 각각 어디서 멈춰야 하는지도 적을 것.
도구 설정을 실제로 바꾸지 말고, 분류와 시험 계획만 줄 것.
참고 자료
- TechCrunch: Asana acquires no-code agent-builder StackAI — https://techcrunch.com/2026/05/28/asana-acquires-no-code-agent-builder-stack-ai/ (2026-05-28)
- Asana official product page: AI Teammates — https://asana.com/product/ai/ai-teammates [accessed: 2026-10-11]
- OWASP Gen AI Security Project: LLM06:2025 Excessive Agency — https://genai.owasp.org/llmrisk/llm062025-excessive-agency/ [accessed: 2026-10-11]



