AI 업무 화면은 왜 ‘링크’에서 ‘실행 가능한 객체’로 바뀌는가: Slack Work Object Embeds가 보여준 변화
협업 도구의 다음 경쟁은 AI가 답을 얼마나 잘 만드는지가 아니라, 대화가 오가는 자리에서 업무 객체를 열고 수정하고 승인할 수 있는지에 달려 있습니다.
협업 도구의 다음 경쟁은 AI가 답을 얼마나 잘 만드는지가 아니라, 대화가 오가는 자리에서 업무 객체를 열고 수정하고 승인할 수 있는지에 달려 있습니다.
들어가며 — 독자가 지금 이 문제를 검색하는 이유
협업 채널에 문서 링크, 대시보드 링크, 티켓 링크를 올리는 일은 익숙합니다. 하지만 링크를 누른 뒤 별도 화면으로 이동하고, 다시 대화 맥락으로 돌아와 결정을 공유하는 과정은 여전히 남아 있습니다.
Slack이 2026년 10월 15일 발표한 Work Object Embeds는 이 흐름을 바꾸려는 기능입니다. 지원되는 앱과 에이전트의 링크를 Slack 스레드 안에서 실시간 인터랙티브 콘텐츠로 열 수 있게 한다는 설명입니다. 이제 검토해야 할 질문은 “어떤 AI 챗봇을 추가할까?”가 아닙니다. “우리 팀의 문서, 지표, 승인 업무는 어떤 대화 맥락에서 작동해야 하는가?”에 더 가깝습니다.
링크는 참고 자료였고, 업무 객체는 대화의 일부가 됩니다
기존 협업 채널의 링크는 대체로 참고 자료를 가리킵니다. 대화는 Slack에 있고 실제 작업은 외부 앱에서 이뤄집니다. 누가 무엇을 확인했는지, 변경 사항이 대화 속 어떤 결정과 연결되는지는 사람이 다시 정리해야 합니다.
Work Object Embeds가 제시하는 방식은 다릅니다. Slack은 지원 앱과 에이전트의 링크를 스레드에서 실시간 인터랙티브 콘텐츠로 열 수 있다고 설명합니다. 즉, 링크는 더 이상 “나중에 열어볼 주소”에 그치지 않고, 대화 중인 사람이 업무 대상을 직접 다루는 진입점이 됩니다.
이 변화가 중요한 이유는 AI 결과물이 놓이는 자리가 달라지기 때문입니다. AI가 작성한 초안, 조회한 지표, 처리 대기 중인 업무 항목이 별도 AI 창에 머물지 않고 팀 대화 안에 놓일 수 있습니다. 검토 의견과 승인 판단도 같은 맥락에서 이어질 가능성이 생깁니다.
다만 이것이 모든 앱 링크를 곧바로 편집 가능한 화면으로 바꾼다는 뜻은 아닙니다. Slack은 “지원되는 앱과 에이전트”를 전제로 설명하고 있습니다. 실제 지원 범위와 파트너별 제공 기능은 도입 전에 확인해야 합니다.
출처: Slack 공식 발표, Work With Live App Content Without Leaving Slack
AI 도입의 중심이 ‘답변 창’에서 ‘업무가 일어나는 자리’로 이동합니다
많은 AI 도입 논의는 모델 성능이나 챗봇 인터페이스에서 시작합니다. 하지만 팀 업무에서는 답변을 받는 것보다, 그 답변이 다음 행동으로 이어지는지가 더 중요할 때가 많습니다.
예를 들어 회의 스레드에서 다음과 같은 흐름을 생각해볼 수 있습니다.
1. 담당자가 대화 안에서 특정 업무 객체를 엽니다.
2. 팀원이 같은 스레드에서 내용과 AI가 남긴 결과를 검토합니다.
3. 필요한 수정이나 승인 판단이 대화 맥락과 함께 남습니다.
4. 이후 참여자는 별도 설명 없이 스레드와 업무 객체를 함께 확인합니다.
이 방식에서 AI는 독립된 대화 상대라기보다 업무 객체를 다루는 여러 참여자 중 하나에 가깝습니다. 도구를 새로 도입할 때도 “AI가 무엇을 답할 수 있는가”만 봐서는 부족합니다. AI 결과가 문서, 업무 항목, 대시보드, 승인 절차 중 어디에 놓여야 하는지까지 함께 설계해야 합니다.
Slack의 발표는 이런 제품 변화가 이미 협업 화면에서 시작되고 있음을 보여줍니다. 대화와 실행 화면이 분리된 상태를 당연하게 볼 이유는 줄어들고 있습니다.
권한은 새로 만드는 것이 아니라 기존 앱 권한을 따라야 합니다
대화 안에서 외부 업무 객체를 다룰 수 있게 되면, 편의성만큼 권한 관리도 중요해집니다. Slack은 Work Object Embeds가 기존 인증과 앱 권한을 따르며, 관리자가 조직 또는 워크스페이스 단위로 접근을 제어할 수 있다고 설명합니다.
이 원칙은 도입 검토의 기준이 될 수 있습니다. Slack 안에 표시된다고 해서 Slack 사용자가 모두 같은 내용을 보거나 수정할 수 있어서는 안 됩니다. 원본 앱의 권한 체계와 접근 제어가 유지되는지 확인해야 합니다.
특히 다음 항목을 먼저 점검할 필요가 있습니다.
- 스레드에서 열리는 업무 객체가 원본 앱의 인증과 권한을 그대로 적용하는가
- 조직 또는 워크스페이스 관리자가 해당 기능의 접근 범위를 제어할 수 있는가
- 읽기, 수정, 승인처럼 서로 다른 행동이 원본 시스템의 권한과 일치하는가
- 대화 참여자와 실제 업무 객체 접근 권한자가 다를 때 어떤 화면과 안내가 표시되는가
- 지원 앱, 요금제, 국내 제공 범위가 현재 계약 환경에서 제공되는가
마지막 항목은 공개 발표만으로 단정하기 어렵습니다. 파트너별 제공 범위와 요금제는 실제 도입 전에 별도로 확인해야 합니다.
바로 적용하는 체크리스트 또는 비교 기준
Work Object Embeds와 같은 기능을 검토할 때는 AI 기능 목록보다 아래 질문에 답해보는 편이 실무적입니다.
- [ ] 팀이 가장 자주 공유하는 링크는 무엇인가: 문서, 업무 티켓, 지표, 승인 요청 중 어디에 가까운가
- [ ] 그 링크를 열기 위해 대화를 떠나는 과정에서 어떤 정보가 자주 빠지는가
- [ ] 대화 안에서 확인만 하면 되는 업무와 수정·승인까지 필요한 업무는 각각 무엇인가
- [ ] 원본 앱의 인증과 권한이 Slack 화면에서도 그대로 적용되는가
- [ ] 조직 또는 워크스페이스 관리자가 기능 사용 범위를 통제할 수 있는가
- [ ] 지원되는 앱과 에이전트가 현재 팀의 핵심 업무 도구와 맞는가
- [ ] 대화 기록과 업무 객체의 변경 이력을 함께 확인할 수 있는가
- [ ] 외부 앱, 파트너, 요금제별 지원 범위는 도입 시점에 재확인했는가
마무리
Slack Work Object Embeds가 보여주는 변화는 링크 미리보기 개선에 그치지 않습니다. 협업 도구 안에서 대화와 실행을 더 가깝게 연결하려는 시도입니다. AI 도입의 기준도 답변 품질만으로는 부족해집니다. 팀이 실제로 검토하고 수정하고 승인하는 업무 객체가 대화 속 어디에 놓이는지를 봐야 합니다.
우리 팀에서 가장 자주 공유하지만, 링크를 열고 다시 설명해야만 일이 진행되는 업무 객체는 무엇인가요?
이 글이 도움이 되었나요?
관련 포스트
Claude Agent Skills로 반복 문서 산출물을 팀 표준으로 만드는 법
매번 프롬프트를 다시 쓰는 대신, `SKILL.md`·템플릿·검증 체크리스트를 한 폴더에 묶으면 리서치 브리프나 보고서 같은 반복 문서 업무를 팀 표준 산출물로 재현할 수 있습니다.
AI Mode 시대 글 구조, “키워드 1개”보다 “하위 질문 지도”부터 만들어야 합니다
AI 검색에 맞는 글쓰기는 새로운 꼼수가 아니라, 하나의 키워드를 독자의 후속 질문 묶음으로 쪼개고 각 질문마다 근거·예시·다음 행동을 붙이는 구조 설계입니다.
n8n·Zapier·Make, AI에게 실행 권한을 주기 전에 먼저 비교해야 할 것
노코드 자동화 도구를 AI/MCP에 연결할 때는 “무엇을 자동화할 수 있나”보다 “AI가 어디까지 실행·수정할 수 있나”를 먼저 봐야 합니다.
Chrome DevTools MCP, AI 코딩 에이전트에게 “브라우저 실행 결과”를 보게 하는 법
AI가 코드를 고쳤다고 끝내지 말고, Chrome DevTools MCP로 실제 브라우저의 DOM·콘솔·성능 트레이스까지 확인하게 만들어야 합니다.
P&ID·설계 PDF를 RAG에 넣기 전: 표·도형·체크박스 추출 품질부터 검증하는 법
설계 PDF 기반 RAG의 첫 산출물은 챗봇이 아니라, 원문과 대조해 통과 여부를 판단할 수 있는 **추출 승인표**여야 합니다.
Azure MCP Server 2.0으로 클라우드 점검 에이전트를 만들기 전, 먼저 줄일 것들
Azure MCP Server 2.0은 "AI가 클라우드를 운영하게 하는 도구"라기보다, 먼저 읽기·점검·권고 범위로 제한한 뒤 권한과 도구 목록을 검증해야 하는 연결 지점입니다.