기본 콘텐츠로 건너뛰기

Slack에 AI 비서를 여러 개 붙여보니 보인 것들 (OpenClaw, Manus, Antigravity, Codex 1차 사용 후기)

Slack에 AI 비서를 여러 개 붙여보니 보인 것들 OpenClaw, Manus, Antigravity, Codex 1차 사용 후기 최근 OpenClaw, Manus, Antigravity, Codex를 각각 Slack에 연결해서 실제 업무 비서처럼 사용할 수 있는지 테스트하고 있다. 처음에는 단순히 “어떤 AI가 더 똑똑한가?”를 비교하려고 했다. 그런데 직접 Slack에 붙여서 써보니 생각보다 비교 포인트가 달랐다. 모델 성능만 중요한 게 아니었다. 실제로는 다음 네 가지가 훨씬 중요했다. 첫째, Slack 안에서 얼마나 자연스럽게 대화하는가. 둘째, 외부 서비스나 내 작업 환경과 얼마나 잘 연결되는가. 셋째, 토큰이나 크레딧 비용이 감당 가능한가. 넷째, 먹통이 되지 않고 안정적으로 계속 운영 가능한가. 결론부터 말하면, 아직 “이거 하나면 끝”이라고 할 만한 도구는 없었다. 각각 장단점이 분명했고, 오히려 역할을 나눠서 섞어 쓰는 쪽이 현실적이라는 느낌이 강했다. Manus: 대화감은 좋지만 비용이 무섭다 가장 사람과 대화하는 느낌에 가까웠던 것은 Manus였다. Slack에서 말을 걸면 꽤 자연스럽게 반응했고, 짧은 메시지를 여러 번 보내면서 대화하듯 진행하는 방식도 나쁘지 않았다. 오히려 너무 자주 쪼개서 메시지를 보내다 보니 Slack 알림이 조금 귀찮을 정도였다. 하지만 문제는 비용이었다. Manus는 PC 설치형 도구가 아니다. 그래서 내 PC 안의 파일을 직접 만지거나 로컬 작업을 수행하는 데에는 한계가 있었다. 뭔가 PC와 연결하는 방법이 있는 것 같기는 했지만, 일단은 GitHub를 연결해서 AI들끼리 작업 내용을 볼 수 있도록 구성했다. 문제는 Slack 안에서 어떤 지시를 했을 때였다. Manus가 관련 정보를 찾기 위해 Slack 메시지를 계속 훑어보는 듯했고, 그 과정에서 크레딧이 빠르게 소모됐다. 실제로 한 번의 작업 지시에서 1,000 크레딧 이상을 사용하고도 “Slack에서 관련 정보를 못 찾았다”는 식...
최근 글

Slack에 AI 비서를 여러 개 붙여보니 보인 것들 (OpenClaw, Manus, Antigravity, Codex 1차 사용 후기)

Slack에 AI 비서를 여러 개 붙여보니 보인 것들 OpenClaw, Manus, Antigravity, Codex 1차 사용 후기 최근 OpenClaw, Manus, Antigravity, Codex를 각각 Slack에 연결해서 실제 업무 비서처럼 사용할 수 있는지 테스트하고 있다. 처음에는 단순히 “어떤 AI가 더 똑똑한가?”를 비교하려고 했다. 그런데 직접 Slack에 붙여서 써보니 생각보다 비교 포인트가 달랐다. 모델 성능만 중요한 게 아니었다. 실제로는 다음 네 가지가 훨씬 중요했다. 첫째, Slack 안에서 얼마나 자연스럽게 대화하는가. 둘째, 외부 서비스나 내 작업 환경과 얼마나 잘 연결되는가. 셋째, 토큰이나 크레딧 비용이 감당 가능한가. 넷째, 먹통이 되지 않고 안정적으로 계속 운영 가능한가. 결론부터 말하면, 아직 “이거 하나면 끝”이라고 할 만한 도구는 없었다. 각각 장단점이 분명했고, 오히려 역할을 나눠서 섞어 쓰는 쪽이 현실적이라는 느낌이 강했다. Manus: 대화감은 좋지만 비용이 무섭다 가장 사람과 대화하는 느낌에 가까웠던 것은 Manus였다. Slack에서 말을 걸면 꽤 자연스럽게 반응했고, 짧은 메시지를 여러 번 보내면서 대화하듯 진행하는 방식도 나쁘지 않았다. 오히려 너무 자주 쪼개서 메시지를 보내다 보니 Slack 알림이 조금 귀찮을 정도였다. 하지만 문제는 비용이었다. Manus는 PC 설치형 도구가 아니다. 그래서 내 PC 안의 파일을 직접 만지거나 로컬 작업을 수행하는 데에는 한계가 있었다. 뭔가 PC와 연결하는 방법이 있는 것 같기는 했지만, 일단은 GitHub를 연결해서 AI들끼리 작업 내용을 볼 수 있도록 구성했다. 문제는 Slack 안에서 어떤 지시를 했을 때였다. Manus가 관련 정보를 찾기 위해 Slack 메시지를 계속 훑어보는 듯했고, 그 과정에서 크레딧이 빠르게 소모됐다. 실제로 한 번의 작업 지시에서 1,000 크레딧 이상을 사용하고도 “Slack에서 관련 정보를 못 찾았다”는 식...

📱 스마트폰이 개발 컨트롤 타워가 되다: Codex + MCP + Slack 연동 가이드

“PC에서 AI가 일하고, 나는 iPhone으로 운영한다” 2026년, AI 개발 환경은 '코드 생성'을 넘어 'AI 운영체제(OS)' 시대로 진화했습니다. 과거처럼 개발자가 하루 종일 IDE와 SSH에 매달리는 대신, 이제는 AI 에이전트가 실무를 처리하고 인간은 승인과 지시만 내리는 구조 로 바뀌고 있습니다. 특히 OpenAI Codex의 모바일 지원으로, 언제 어디서나 iPhone만으로 전체 시스템을 통제할 수 있게 되었습니다. 💡 왜 이 조합이 혁신적인가? 단순히 AI에게 코딩을 맡기는 것이 아닙니다. 핵심은 회사 업무 환경(Google Workspace, Slack) 전체를 AI와 연결 하는 데 있습니다. Codex : 메인 AI 에이전트 역할 (코드 작성 및 시스템 제어) MCP (Model Context Protocol) : AI가 외부 시스템(문서, 메일 등)을 읽고 쓸 수 있게 하는 표준 프로토콜 Google Workspace : Gmail, Docs, Drive 연동으로 회의록 작성부터 장애 메일 분석까지 자동화 Slack : 이 모든 과정을 통제하는 '모바일 운영 콘솔' 🚀 완벽한 AI 개발 환경 구축 시나리오 1. 인프라 준비 (메인 PC) 집이나 회사의 PC(Mac Mini, Linux 등)에 Codex, MCP Server, Docker, 그리고 GitHub 연동을 세팅하여 24시간 가동 상태로 만듭니다. 2. MCP로 업무망 연결 Gmail / Docs MCP : 장애 알림 요약, PRD 자동 업데이트 Slack MCP : 전용 AI 운영 채널(예: #ai-devops ) 생성 3. 모바일(iPhone)에서 원격 제어 출근길이나 외근 중에도 Slack이나 ChatGPT 앱(Codex 연동)을 열어 이렇게 지시합니다. "오늘 아침 들어온 장애 메일 요약하고, Slack 논의 내용 기반으로 PR 생성해줘." 점심시간에 PR...

자동화 스크립트의 성패를 가르는 차이: 결국은 UX다

개발 현장이나 운영 조직에서 시스템 운영 효율화를 위해 자동화 스크립트를 작성하는 일은 흔합니다. 요즘은 AI의 도움을 받아 누구나 빠르고 쉽게 스크립트를 생성할 수 있는 시대가 되었습니다. 하지만, 동일한 AI 도구를 사용해 동일한 목적의 스크립트를 만들더라도 어떤 스크립트는 팀원들의 사랑을 받고, 어떤 스크립트는 외면받습니다. 그 이유가 무엇일까요? 최근 같은 현장에서 스크립트를 주로 개발하는 동료와 저의 사례를 통해, 사용자의 선택을 받는 자동화 툴의 핵심 에 대해 이야기해보려 합니다. "작동은 하는데, 손이 너무 많이 가요" 동료가 만든 스크립트는 분명히 요구된 '목적'을 달성하는 코드였습니다. 하지만 스크립트를 실행하기 위해 거쳐야 하는 과정이 문제였습니다. 스크립트 실행을 위해 Gateway 서버에 수동으로 접속 해야 함 로그인 후 필요한 정보를 수동으로 조회 해야 함 사용자가 직접 상태를 확인하고, 필요한 부분만 골라 스크립트의 파라미터로 입력 해야 비로소 실행됨 결국 이 스크립트를 사용하려면 작업자가 시스템의 구조를 잘 알아야 했고, 실행 전후로 긴장감을 늦출 수 없었습니다. 스크립트라는 '도구'를 쓰기 위해 '사람'이 맞춰줘야 하는 상황이었죠. "클릭 한 번이면 다 알아서 해주네요" 반면, 제가 팀에 제공한 스크립트의 방향성은 달랐습니다. 사용자가 목적만 선택 하면 스크립트가 목표 대상 Gateway 서버에 알아서 접속 하고 필요한 정보를 스스로 수집 하여 사용자에게 보여줍니다. 사용자가 내용 확인 후 '다음(Next)' 액션을 누르면 작업이 안전하게 수행되고, 실행 전과 후의 결과를 비교 하여 보고하기 쉬운 형태로 증거(Evidence) 파일까지 자동으로 남깁니다. 이 스크립트를 사용하기 위한 **사전 준비는 '0(제로)'**입니다. 결국 팀원들은 제 스크립트만을 사용하게 되었고, 동료는 자동화 업무...

직원 한 명 월급으로 전 직원에게 1:1 AI 비서를 붙여준 후기 (ft. AI Assistant Ops)

직원 한 명 월급으로 전 직원에게 1:1 AI 비서를 붙여준 후기 (ft. AI Assistant Ops) 안녕하세요! 요즘 주변 대표님들이나 실무자분들을 만나면 다들 'AI 도입' 이야기를 많이 하시죠? 저도 처음엔 반신반의했습니다. "과연 우리 회사에 쓸모가 있을까?", "사람 일자리를 뺏는 건 아닐까?" 싶었는데, 최근 도입한 'AI Assistant Ops' 서비스 덕분에 완전히 생각이 바뀌었습니다. 직접 써보고 피부로 느낀 찐 후기를 남겨볼까 합니다. 1. 보고 지옥 탈출! 영업 효율이 미쳤습니다. 예전엔 매번 직원들한테 "이번 달 현황 어때?", "전월 대비 변동 사항 리포트 정리해 와"라고 지시했잖아요? 직원들은 보고서 쓴다고 정작 중요한 영업할 시간을 뺏기고, 저는 저대로 기다리느라 답답했습니다. 그런데 지금은 그냥 AI한테 물어봅니다. 누가 어떤 상황인지, 어떤 변화가 있는지 실시간 리포트를 바로바로 받아볼 수 있거든요. 잔무의 획기적 단축: 직원들은 보고를 위한 잔무가 확 줄어드니 온전히 고객에게만 집중할 수 있게 되었습니다. 생산성 극대화: 인원을 더 늘리지 않았는데도 직원 1인당 커버할 수 있는 고객 수가 늘어나서 자연스럽게 매출이 오르는 걸 경험하고 있습니다. 2. 에이스가 퇴사해도 걱정 없는 이유: '사내 정보의 자산화' 제가 가장 든든하게 생각하는 부분은 전 직원에게 맞춤형 '1인 1비서'가 생겼다는 겁니다. 우리 회사의 데이터와 에이스 직원의 영업 노하우가 매월 지속적으로 AI에게 학습(파인튜닝)됩니다. 이게 진짜 대박인 게, 일 잘하던 에이스가 갑자기 퇴사하더라도 그 노하우가 사내 AI에 고스란히 남아있어서 전체적인 영업 품질이 그대로 방어된다는 점입니다. 반대로 아직 일이 서툰 신입 사원이 들어와도, 똑똑해진 AI 비서의 서포트를 받으니 금방 베테랑처럼 일할 수 있게 상향 평...

Antigravity IDE에 메신저 붙여봤더니... MCP 연동 실전 후기

Antigravity IDE에 메신저 붙여봤더니... MCP 연동 실전 후기 Auto Accept가 사라진 날 어제 갑작스럽게 Antigravity IDE가 업데이트되면서 Auto Accept 기능이 비활성화 됐습니다. AI가 코드를 제안할 때마다 일일이 Accept 버튼을 눌러야 하는 상황. 처음엔 별거 아니라 생각했는데... 막상 닥쳐보니 그 귀찮음이 엄청났습니다. (초반에 이걸 어떻게 다 누르고 살아왔는지 새삼 신기할 지경;;) 그래서 어쩔 수 없이 새 기능 탭을 뒤적이기 시작했습니다. 발견: 외부 메신저 연동 기능! 업데이트 노트를 보던 중 흥미로운 기능 하나를 발견했습니다. 외부 메신저 연동 지원 — MCP(Model Context Protocol)를 통해 Slack, Discord 등 외부 메신저와 AI 에이전트를 직접 연결할 수 있게 됐습니다. 이 기능, 사실 OpenClaw(Claude 기반 자율 에이전트)를 겨냥한 포지셔닝처럼 보입니다. 메신저에서 AI에게 직접 업무를 지시하는 방식은 이미 OpenClaw가 핵심 경쟁력으로 내세우던 부분이거든요. "오, 이거 재밌겠는데?" 하고 바로 시도에 들어갔습니다. MCP 연동 실전 — 헤매고 또 헤매고... MCP 서버 설정은 생각보다 쉽지 않았습니다. Antigravity의 에이전트 패널에서 MCP 스토어를 찾고, Slack MCP 서버를 연결하는 과정에서 인증 토큰 설정, 워크스페이스 권한 설정 등 몇 가지 허들이 있었습니다. 솔직히 꽤 헤맸습니다. 공식 문서가 아직 부족한 탓에 설정 파일을 직접 수정해야 하는 부분도 있었고요. 하지만 결국 성공! 메신저에서 Antigravity AI 에이전트에게 직접 메시지를 보낼 수 있게 됐습니다. 연동 후 첫 인상 처음 메시지를 던졌을 때, AI의 반응은 꽤 인상적이었습니다. 질문에 대해 조목조목 상세하게, 심지어 장황할 정도로 답변해줬거든요. OpenClaw + ChatGPT 조합보다 오히려 나을 수...

[AI 꿀팁] Gemini 3.5 Flash vs 3.1 Pro, 내 토큰이 순식간에 녹아내린 이유와 똑똑한 모델 선택 가이드

[AI 꿀팁] Gemini 3.5 Flash vs 3.1 Pro, 내 토큰이 순식간에 녹아내린 이유와 똑똑한 모델 선택 가이드 안녕하세요! 최근 구글의 차세대 AI 라인업인 Gemini 3.5 Flash 와 Gemini 3.1 Pro 를 사용해 보시면서 "어? 왜 이렇게 토큰(비용)이 순식간에 사라지지?" 하고 당황하셨던 분들 많으실 겁니다. 질문 몇 개 안 한 것 같은데 토큰 제한이 걸리거나 비용이 청구되는 눈물 나는 상황... 도대체 왜 이런 일이 발생하는지, 그리고 내 지갑을 지키면서 AI 효율을 극대화하는 모델 및 옵션 선택 기준 을 총정리해 드립니다! 1. 내 토큰은 어디로 사라졌을까? 범인은 'Thinking 모드' 구글 Gemini 3.x 라인업의 가장 강력한 무기는 바로 '내장형 고도화 추론(Thinking) 기능'입니다. AI가 정답을 내기 전에 내부적으로 깊게 고민하는 단계를 거치는 것인데요. 여기서 반전이 있습니다. AI가 내부적으로 머리를 굴리며 쓴 혼잣말(추론 토큰)이 모두 '출력(Output) 토큰 사용량'에 포함되어 계산 된다는 점입니다! Thinking (High) 모드의 무서움: 사용자가 질문을 한 줄만 던졌어도, AI는 완벽한 정답을 내기 위해 백그라운드에서 스스로 에이전트 루프를 돌리며 수만 토큰을 써버립니다. 겉보기엔 짧은 답변이라도 실제로는 엄청난 토큰이 소모되는 주범이죠. 늘어난 출력 창: Gemini 3.5 Flash는 한 번에 뿜어낼 수 있는 출력 한도가 65,536 토큰 으로 대폭 늘어났습니다. 모델이 글을 길게 쓰거나 깊게 생각하기 시작하면 한 번의 대화로도 토큰이 텅텅 비게 됩니다. 2. Gemini 모델별 'Thinking 레벨'에 따른 토큰 소모량 비교 모든 모델의 최대 입력은 100만 토큰, 최대 출력은 65,536 토큰으로 동일하지만, Thinking 설정에 따라 내부 토큰 배분이 완전히 달라집니다. ...