말로 설명하면 대시보드가 나온다

"2분기 고객 문의를 주차별로 쪼갠 리포트가 필요해." Slackbot에 이렇게 말하면 인터랙티브 리포트가 채널에 뜬다. Slack이 붙인 새 기능 surfaces다. 워크스페이스 대화와 MCP로 연결한 외부 도구를 뒤져 표와 차트를 만들고 채널이나 DM에 공유할 수 있다. 모든 요금제에서 쓸 수 있고 무료 팀도 포함된다.

그런데 Slack 자체 도움말의 FAQ에 이렇게 적혀 있다. surfaces는 정적 파일이며 새 데이터를 끌어오거나 변경을 반영하지 않는다. 최신 값이 필요하면 같은 프롬프트로 새로 만들어야 한다.

한 줄 정리

프롬프트 한 줄로 대시보드 모양의 결과물이 나오지만 그 안의 숫자는 만든 시점에 박제된다.

한눈에 보기

문턱이 어디까지 내려왔나

전에는 팀 안에서 파이프라인 화면 하나를 보려면 두 갈래였다. 스프레드시트에 손으로 옮겨 적거나 도구를 하나 더 결제하고 연동을 붙이거나. 앞쪽은 사람이 매주 갈리고 뒤쪽은 월 구독이 하나 늘고 관리자가 필요하다. 다섯에서 서른 명 사이 팀이 대개 앞쪽에 머무는 이유가 그것이다.

말로 설명해 결과가 나오는 방식은 그 두 갈래 사이에 새 칸을 하나 만든다. 결제도 연동 설정도 없이 이번 주에만 필요한 화면을 한 번 뽑아 보는 칸. 매주 도는 계기판이 필요한 경우와 이번 회의에만 필요한 정리가 필요한 경우는 다른 문제였는데 지금까지는 같은 도구로 풀어 왔다. 뒤쪽이 훨씬 흔하다.

이름이 위험한 기능

대시보드라는 말에는 약속이 하나 붙어 있다. 지금 보는 값이 지금의 값이라는 약속. surfaces는 그 약속을 안 지키는데 생김새는 지키는 것처럼 생겼다.

월요일 회의에 지난주 파이프라인 화면을 띄워 놓고 이번 주 숫자로 읽는 사고는 기능 결함이 아니라 이름에서 난다. 팀에 풀 때 "대시보드 만들어 준다"고 소개하면 그 사고가 예약된다. "리포트를 그때그때 뽑아 준다"가 지금 상태에 맞는 설명이다. 라이브 데이터는 10월부터 붙는다고 알려졌다.

같은 이유로 채널에 탭으로 고정하는 기능은 지금 단계에서 조심할 만하다. 탭에 걸린 화면은 상시 켜 둔 계기판처럼 읽힌다. 만든 날짜가 화면 어딘가에 크게 박혀 있지 않으면 두 주만 지나도 아무도 언제 뽑은 것인지 기억하지 못한다. 제목에 기준일을 직접 적어 두는 습관 하나로 대부분 막힌다.

Slack이 이 기능을 새로운 파일 유형으로 분류한 것도 같은 얘기를 다른 말로 한 셈이다. 문서와 계기판 사이 어디쯤 있는 물건이고 회사는 문서 쪽으로 분류했다. 쓰는 사람이 계기판 쪽으로 읽으면 그 간격에서 사고가 난다.

권한은 만든 사람을 따라간다

Slackbot은 그 사람이 접근할 수 있는 대화와 연결 소스만 뒤진다. 별도 권한 설정 없이 각자 자기가 볼 수 있는 범위 안에서만 결과가 나온다는 뜻이라 도입 부담이 작다. 사내 도구를 하나 늘릴 때 가장 오래 걸리는 일이 대개 누가 무엇을 볼지 정하는 회의인데 그 회의가 통째로 생략된다.

편한 만큼 함정도 여기 있다. 정적 파일이라는 말은 만든 사람의 권한으로 긁은 값이 파일 안에 그대로 남는다는 뜻이기도 하다. 대표가 만든 파이프라인 리포트를 전체 채널에 그대로 붙이기 전에 무엇이 들어갔는지는 만든 사람이 확인하고 넘겨야 안전하다.

보존은 워크스페이스 파일 보존 정책을 따른다. 즉 90일 삭제 정책을 걸어 둔 팀이면 이 리포트도 같이 사라진다. 분기 보고 자료를 여기서 만들어 두고 다음 분기에 찾을 생각이면 미리 확인할 항목이다.

찾는 문제도 아직 남아 있다. 만든 결과물을 제목으로 검색하거나 파일 목록에서 보는 기능은 곧 들어온다고 안내돼 있고 지금은 Slackbot 대화 기록을 거슬러 올라가야 한다. Slack 도움말이 링크를 따로 모아 두라고 권하는 상태다. 몇 개까지는 괜찮고 스무 개가 넘으면 관리 부담이 생긴다.

MCP로 무엇을 붙였느냐가 결과를 정한다

이 기능의 성능은 모델보다 연결에서 갈린다. Jira나 Linear를 붙여 두면 프로젝트 이슈를 우선순위나 담당자로 묶어 달라는 요청이 먹힌다. Salesforce를 붙여 두면 거래 단계별 파이프라인 화면이 나온다. 아무것도 안 붙인 워크스페이스에서는 채널 대화만 뒤지므로 결과가 잡담 요약에 가까워진다.

그래서 시험해 볼 순서가 정해진다. 기능부터 켜서 아무거나 시켜 보는 대신 우리 팀이 매주 손으로 옮겨 적는 데이터가 어느 도구에 들어 있는지를 먼저 적어라. 그 도구가 연결 가능한 목록에 있으면 시도할 값이 있고, 없으면 지금은 순서가 아니다.

anyAX 관점

무료 요금제에서도 된다는 말과 마음껏 쓸 수 있다는 말은 다르다. Slackbot 크레딧 한도가 요금제별로 따로 걸려 있어서 다섯 명이 각자 몇 번 만들면 그 달치가 끝난다. 도입 판단을 "된다"에서 멈추지 말고 한 달에 몇 개까지 만들 수 있는지를 먼저 재라.

이번 주에 할 일은 크지 않다. 사람이 손으로 만드는 정기 리포트 하나를 골라 같은 내용을 뽑고 나란히 놓고 보면 된다. 30분 걸리던 것이 프롬프트 한 줄이 되는지, 아니면 고치는 데 40분이 드는지가 그 자리에서 갈린다. 도구를 워크플로에 박는 결정은 그 비교 뒤에 해도 늦지 않다. 10월에 라이브 데이터가 붙으면 기준이 또 달라진다.

더 크게 보면 이런 기능이 늘어날수록 팀에서 값이 오르는 역할이 하나 있다. 무엇을 재야 하는지 아는 사람이다. 리포트를 그리는 일은 이제 문장 하나로 끝나지만 어떤 숫자를 매주 봐야 우리 사업이 굴러가는지는 아무도 대신 정해 주지 않는다. 프롬프트를 잘 쓰는 팀보다 볼 숫자를 정해 둔 팀이 이 기능에서 더 많이 가져간다.

그러니 도입을 논의하는 회의라면 기능 시연으로 시작하지 마라. 우리가 매주 확인해야 할 숫자 다섯 개를 화이트보드에 먼저 적고, 그중 몇 개가 이 도구로 나오는지를 세는 순서가 맞다. 다섯 개를 못 적는 팀이면 도구가 문제가 아니다.

참고

• Slackbot으로 대화형 surface 만들기 (Slack 도움말)
• 프롬프트로 대시보드를 만드는 기능 소개 (Techzine)
• Slackbot 크레딧과 요금제별 한도 (Slack 도움말)