LLM + SaaS Automated Workflow 예시
LLM과 유명 SaaS를 통합하면 다음과 같은 automated workflow system을 구축할 수 있다.
- 코드 리뷰 파이프라인: GitHub PR 오픈 이벤트 감지 → LLM이 diff 분석 및 리뷰 코멘트 자동 작성 → 보안 취약점 발견 시 Slack #security 채널에 즉시 경보
- 영업 인텔리전스: Gmail에서 잠재고객 이메일 수신 → LLM이 요약·의도 분석 → Salesforce CRM에 리드 자동 등록 → Google Calendar에 팔로업 일정 추가
- 콘텐츠 발행 자동화: Notion에 초안 작성 → LLM이 SEO 최적화 → GitHub Actions 트리거 → 블로그 자동 배포 후 Twitter/X에 홍보 트윗 게시
- 데이터 리포팅: 매일 오전 S3에서 전날 로그 수집 → LLM이 이상 탐지 및 요약 → Google Sheets에 기록 → Slack에 일일 리포트 전송
- 고객 지원 자동화: Slack에서 고객 문의를 실시간 감지 → LLM이 의도 분류 → Jira에 티켓 자동 생성 → 담당자에게 Slack 알림 발송
- HR 온보딩: 신규 직원 Google Workspace 계정 생성 감지 → LLM이 온보딩 문서 개인화 → Notion 워크스페이스 초대 → Slack 환영 메시지 자동 발송
각각의 시나리오를 구현할 때 핵심 선택지가 바로 MCP 방식과 CLI 방식이다.
MCP vs CLI: 핵심 차이
MCP는 '연결 상태를 유지'하고 '스키마를 자동 동기화'하는 과정에서 더 많은 토큰을 사용한다. 반면 CLI는 필요한 데이터만 딱 잘라서 전달하므로 토큰 최적화에 유리하다.
| 구분 | SaaS MCP (신경 연결형) | SaaS CLI (리모컨 조종형) |
|---|---|---|
| 토큰 비용 | 상대적으로 높음 (스키마 상시 교환, 맥락 유지 비용) | 매우 낮음 (결과값만 딱 전달받음) |
| 개발 난이도 | 높음 (MCP 서버 구축 및 프로토콜 구현) | 낮음 (기존 CLI 명령어를 호출만 하면 됨) |
| 반응 속도 | 빠름 (연결 유지로 즉시 실행) | 느림 (매번 쉘 실행 및 인증 필요) |
| 상호작용 | 지능적/복합적 (실시간 대화 및 모니터링) | 단순/단발적 (명령 → 결과) |
| 에러 대응 | 구조적이고 능동적인 복구 가능 | 텍스트 기반 에러 메시지 해석 필요 |
| 연결 지속성 | WebSocket/HTTP 장기 연결 | 요청 시마다 새 프로세스 |
| 실시간성 | Push 이벤트 수신 가능 | Pull만 가능 (폴링 필요) |
| 다중 API 조율 | 자연스러운 파이프라인 | 수동 스크립트 체이닝 |
| 주요 활용 | 복잡한 에이전트 서비스, 24/7 모니터링 | 자동화 스크립트, 일회성 데이터 처리 |
시나리오별 심층 비교
시나리오 1: GitHub 이슈 자동 답변
javascript
[Claude] ←─── MCP 프로토콜 (영구 연결) ───→ [GitHub]
↓ "Issue #123 읽어줘"
↓ 자동 인증 유지 + 실시간 이슈 목록 변경 감지 + 스키마 자동 동기화
↓ "이 이슈에 답변 달아줘: '버그 재현 완료했습니다'"
↓ 추가 설정 없이 즉시 실행, 맥락 유지됨- Claude가 GitHub 이슈 상태를 지속적으로 인지
- "이 이슈"라는 대화 맥락이 MCP 세션에 유지됨
- 에러 발생 시 즉각 Claude에게 전달 (예: "권한 없음")
javascript
[Claude] ──→ 명령어 생성 ──→ [터미널] ──→ gh CLI ──→ [GitHub]
$ gh issue view 123 --json title,body
↓ 결과를 텍스트로 받아 Claude가 읽음
↓ "이 이슈에 답변 달아줘" → Claude가 #123 기억 필요
$ gh issue comment 123 --body "버그 재현 완료했습니다"
↓ 실행 후 연결 끊김- 매번 독립적인 명령 실행 (stateless)
- Claude가 이슈 번호를 명령어에 명시해야 함
- 에러는 stdout/stderr 파싱 필요
시나리오 2: Slack 채널 실시간 모니터링
javascript
[Claude + Slack MCP] ←→ WebSocket 연결 ←→ [Slack API]
↓ "#support 채널을 지켜보다가 '긴급'이라는 단어가 나오면 알려줘"
↓ MCP가 Slack Event를 실시간 스트리밍
↓ [15분 후 메시지 도착]
→ "긴급 메시지 감지! #emergency 채널에 알림 전송할까요?"- 실시간 이벤트 스트림 수신
- Claude가 Slack을 "귀"처럼 지속적으로 청취
- 상태 변화에 능동적 반응 가능
javascript
[Claude] ──→ [slack-cli] ──→ [Slack API]
$ slack-cli chat list --channel support --limit 10
↓ 결과 분석 → '긴급' 단어 확인
↓ 모니터링 반복 시 매번 새 명령 실행 필요 (비효율)
$ slack-cli chat list --channel support --limit 10 (1분 후 반복...)- Pull 방식으로만 데이터 조회 가능
- 실시간 모니터링 불가 (폴링 필요)
- 매번 명령 실행 비용 발생
시나리오 3: Gemini로 이미지 분석
javascript
[Claude] ←─── MCP ───→ [Gemini API]
↓ "이 이미지 분석해줘" (이미지 첨부)
- Gemini 응답이 Claude 세션에 자연스럽게 통합
- 스트리밍 응답 실시간 전달
- 에러 시 자동 재시도 작동javascript
[Claude] ──→ [gemini-cli 실행]
$ gemini-cli analyze-image \
--image="photo.jpg" \
--prompt="이 이미지에 뭐가 있나요?"
→ {"response": "고양이가 소파에 누워있습니다"}
↓ Claude가 이 텍스트를 읽고 사용자에게 전달- 단발성 요청에 적합
- 멀티턴 대화 흐름은 Claude가 수동으로 관리 필요
시나리오 4: Gmail → 캘린더 일정 자동 추가
javascript
[Claude] ←─── MCP ───→ [Gmail API + Calendar API]
↓ "받은편지함에서 'Meeting' 포함된 최근 메일 찾아줘"
↓ "이 메일 분석해서 내일 오후 2시 캘린더에 추가해줘"
→ Gmail 읽기 → Claude 분석 → Calendar 쓰기 (단일 트랜잭션)
- 모든 인증이 MCP 세션에 유지됨- 다중 API 조율이 자연스러움
- Claude가 "비서"처럼 자율적으로 API 체인 실행
javascript
[Claude] ──→ 명령 1: Gmail 검색
$ gam user me show messages query "subject:Meeting" maxresults 5
↓
[Claude] ──→ 명령 2: 내용 분석 (Claude가 직접)
↓
[Claude] ──→ 명령 3: 캘린더 이벤트 생성
$ gcal add \
--title="Team Meeting" \
--start="2024-01-15T14:00:00" \
--duration=60- 수동 파이프라인 구성 필요
- 각 단계마다 인증 재확인 가능성
- Claude가 "프로그래머"가 되어 스크립트를 작성해야 함
무엇을 선택해야 할까?
MCP를 선택해야 하는 경우
- 고도화된 에이전트: LLM이 스스로 판단하여 여러 SaaS를 넘나들며 복합 업무 수행
- 실시간 협업: Slack 모니터링, 실시간 이슈 추적 등 '지속성'이 핵심인 서비스
- 능동적 모니터링: "이 PR을 계속 지켜보다가 approve되면 머지해줘" 같은 워크플로우
- UX 중심: 사용자가 "이거 알아서 해줘"라고 말하면 처리되는 지능형 비서 경험
- 다중 API 조율: 여러 API를 하나의 워크플로우로 묶어야 할 때
CLI를 선택해야 하는 경우
- 단순 반복 작업: "매일 아침 9시에 이 리포트를 S3에 올려줘" 같은 정형화된 업무
- 비용 민감형 서비스: LLM 호출 횟수와 토큰 사용량을 극도로 절약해야 하는 환경
- 기존 인프라 활용:
aws-cli,gh-cli등 기존 도구를 그대로 활용하여 개발 기간 단축 - 단발성 요청: 한 번 물어보고 끝나는 작업, CI 파이프라인 빠른 통합
결론
MCP는 '똑똑하지만 유지비가 드는 정규직 직원'을 고용하는 것이다.
CLI는 '싸고 빠르지만 매번 지시를 내려야 하는 프리랜서'를 쓰는 것이다.
권장 개발 로드맵
비용과 성능 사이의 균형
- CLI로 시작 → 토큰 비용 최소화하며 비즈니스 로직 검증
- 워크플로우 빈도 증가 확인 → 특정 플로우가 반복적·복합적으로 사용될 때
- MCP로 전환 → LLM의 판단력과 실시간성이 중요해지는 시점에 업그레이드