OpenTag — Slack용 Claude Tag의 오픈소스 대안, 그리고 셀프 호스팅 AI 에이전트의 진짜 가치

> 핵심 한 줄: Anthropic이 7/2에 공개한 Claude Tag는 Slack 안에서 Claude를 직접 부르는 가장 가벼운 방법이지만, 런타임 락인과 클로즈드 SDK라는 한계가 있다. OpenTag는 CopilotKit의 @copilotkit/bot 위에 같은 UX를 재구성하면서 런타임과 모델을 완전히 내 손에 쥐게 한다.

원문: GeekNews #31158 · GitHub: CopilotKit/open-tag (예정)

• --

들어가며 — Slack 안의 Claude, "한 클릭"의 비용

2026년 7월 2일, Anthropic은 Claude Tag를 공개했다. Slack 메시지에 @Claude 한 번이면 Claude가 스레드를 읽고, 도구를 부르고, 결과를 인라인으로 렌더링한다. 사내 운영팀과 엔지니어링이 이미 Slack에 살고 있는 조직에는 매력적인 제안이다. 별도의 채팅 UI를 들여올 필요도, 에이전트 운영 콘솔을 설치할 필요도 없다.

그런데 발표 후 4일 만인 7월 6일, 긱뉴스를 통해 등장한 OpenTag는 Claude Tag의 UX는 그대로 가져가되, 그 아래에 깔린 런타임을 셀프 호스팅으로 뒤집는다. MIT 라이선스, 4개 패키지 구조, runtime.ts 한 파일로 에이전트 성격이 결정되는 단순함. 이 글은 OpenTag가 어떤 문제를 풀고, 어떤 trade-off를 선택했는지, 그리고 우리 팀이 어떤 경우에 Claude Tag 대신 OpenTag를 골라야 하는지를 풀어본다.

• --

Claude Tag와 OpenTag — 같은 표면, 다른 바닥

두 프로젝트는 Slack 메시지창에 LLM이 응답을 렌더링한다는 점에서 동일하게 보인다. 그러나 3가지 층에서 결정적으로 갈라진다.

| 영역 | Claude Tag (Anthropic) | OpenTag (오픈소스) |

|---|---|---|

| 런타임 호스팅 | Anthropic 관리형 SaaS | 셀프 호스팅 (agent + bot 두 프로세스) |

| 모델 선택 | Claude 모델 패밀리로 고정 | 어떤 LLM이든 AG-UI 백엔드와 연동 |

| SDK 종속 | 클로즈드 Slack 전용 | @copilotkit/bot (오픈 SDK) — Slack/Discord/Telegram/WhatsApp 동일 코드 |

| UI 렌더링 | Slack Block Kit | 크로스 플랫폼 JSX (Block Kit, Components V2, Telegram HTML) |

| 인증 게이트 | 내장 (Anthropic 정책) | human-in-the-loop Approve 게이트 (티켓 생성 직전 명시) |

| 데이터 주권 | Slack 워크스페이스 ↔ Anthropic | 워크스페이스 ↔ 우리 인프라 (외부 송출 없음) |

| 라이선스 | 상용 SLA | MIT |

핵심은 첫 두 행이다. 모델을 우리 것이 아닌 우리의 도구로 운영하느냐(Claude Tag), 모델 자체를 우리가 들고 있느냐(OpenTag). 이 차이는 단순한 기술 선택이 아니라, AI 에이전트를 운영하면서 마주치는 데이터 주권과 벤더 락인 문제의 핵심에 닿는다.

• --

OpenTag의 구조 — 4개 패키지가 만드는 분리

OpenTag는 모놀리식이 아니다. 단일 코드베이스 안에 4개의 역할이 명확히 갈라져 있다. 이 분리가 의도적이라는 점은 README를 보면 바로 드러난다.

1. `bot` — 플랫폼 비종속 봇 엔진

스레딩, 도구 호출, human-in-the-loop 게이트를 담당한다. Slack 메시지 수신 → 컨텍스트 파싱 → runtime에 전달 → 결과를 다시 Slack에 렌더링, 이 흐름의 외부 접점만 책임진다. 즉 Slack 어댑터를 bot-slack으로 분리해 둔 덕분에, 같은 bot 코어가 Discord/Telegram/WhatsApp에서도 그대로 돌아간다.

2. `runtime` — LLM과 도구를 실행하는 AG-UI 에이전트 백엔드

실제 추론이 일어나는 곳이다. runtime.ts의 단일 시스템 프롬프트가 에이전트의 성격을 정의한다. 고객 응대 에이전트, 코드 리뷰 에이전트, 데이터 분석 에이전트 — 모두 같은 런타임을 공유하면서 프롬프트만 갈아끼우면 된다. 이 설계는 에이전트 동작 = 시스템 프롬프트라는 순수한 사고 실험을 코드 레벨에서 가능하게 한다.

3. `bot-ui` — 크로스 플랫폼 JSX 리치 메시지

분석 결과, 표, 막대 차트를 대화창 안에 인라인으로 그린다. Slack은 Block Kit, Discord는 Components V2, Telegram은 HTML — 각자 다른 리치 메시지 스펙을 갖고 있는데, bot-ui는 이 차이를 추상화한다. JSX로 한 번 쓰면 각 플랫폼의 native 컴포넌트로 컴파일된다.

4. `bot-slack` — Slack 어댑터

bot 코어가 메시지를 받고 결과를 돌려주는 데 필요한 Slack Events API, Block Kit, OAuth 처리를 담당한다. Discord로 옮기려면 이 한 패키지만 bot-discord로 교체하면 된다.

이 4분리 구조는 관심사의 분리 원칙을 충실히 따른다. 비즈니스 로직(runtime), 플랫폼 어댑터(bot-slack), 표현 계층(bot-ui)이 서로의 구현 세부사항을 모르고, 단지 메시지 프로토콜로만 대화한다. 이런 구조는 Anthropic이 Claude Tag에서 보여준 클로즈드 일체형 디자인의 정반대极点에 선다.

• --

Generative UI — 대화창 안에 그려지는 표와 차트

Claude Tag의 가장 큰 시각적 임팩트는 메시지 안에 차트가 들어간다는 점이었다. OpenTag는 이 UX를 그대로 가져간다. 에이전트가 "지난 7일 트래픽 추이"를 응답해야 할 때, 텍스트로 "월요일 1,200, 화요일 1,350..." 식으로 나열하는 대신 막대 차트 컴포넌트를 인라인 렌더링한다. 이건 단순한 시각 효과가 아니라, LLM 응답의 정보 밀도를 한 단계 끌어올리는 방법이다.

구체적으로 어떻게 작동하는가. LLM이 chart(bar, data=[...]) 같은 도구 호출을 반환하면, bot-ui가 그 도구 출력을 받아 Slack Block Kit의 section + image + actions 조합으로 변환한다. Discord에서는 embed로, Telegram에서는 MediaGroup으로. 표현 코드는 한 번, 결과는 각 플랫폼에 맞게 — 이게 JSX 추상화의 진짜 가치다.

다만 솔직히 말하면, generative UI는 기술적 가능성과 운영적 필요성 사이의 간극이 있다. 모든 응답을 차트로 그릴 필요는 없다. OpenTag가 잘한 점은 차트를 기본값으로 강제하지 않고, LLM이 판단해서 호출하는 도구로 둔 것이다. 즉 텍스트가 더 적절한 응답에는 텍스트가 그대로 간다.

• --

Human-in-the-Loop — Approve 게이트의 의미

가장 실무적인 부분은 Approve 게이트다. OpenTag의 티켓 생성, 코드 머지, 인프라 변경 같은 부수 작용이 있는 도구는 에이전트가 직접 실행하지 못한다. LLM이 "JIRA 이슈 #1234를 만들어"라고 결론 내리면, 그 결론은 Slack 메시지에 제안으로 뜨고, 사람 채널 멤버가 ✅ 버튼을 눌러야만 실제 티켓이 생성된다.

이게 왜 중요한가. 2025~2026년 AI 에이전트 사고 사례의 대부분은 LLM이 합리적으로 보이지만 운영 정책에 어긋나는 호출을 했을 때 발생했다. Slack에서 @Claude 한 번에 Jira가 열리고, 그 다음에 고객 알림이 가고, 그 다음에 결제 큐가 돌고 — 자동화 체인이 길수록 한 번의 잘못된 호출이 cascade를 만든다. OpenTag의 Approve 게이트는 이 cascade를 사람의 검토 지점에서 명시적으로 끊는다. LLM의 자율성과 운영 통제권을 양다리 타협한 디자인이다.

이 패턴은 AutoGen, CrewAI 같은 멀티 에이전트 프레임워크에서도 채택하기 시작했다. 다만 OpenTag는 Slack 메시지 안에 게이트를 넣음으로써 컨텍스트 전환 없이 승인할 수 있게 했다. 별도의 콘솔에 가지 않아도 된다. 이게 운영팀의 마찰을 가장 크게 줄이는 지점이다.

• --

셀프 호스팅의 실제 비용 — 두 프로세스, 한 Redis

README가 솔직히 밝히는 운영 부담은 이렇다.

• agent 프로세스 — LLM과 도구를 실행. GPU가 있다면 로컬 모델, 없다면 API 키.
• bot 프로세스 — Slack 연결. 가벼운 Node.js.
• bot-store-redis — 재시작해도 스레드를 유지하기 위한 저장소. 안 쓰면 in-memory 기본값으로 동작하지만, 컨테이너 재시작 시 컨텍스트가 날아간다.

즉 본질적으로 두 개의 long-running 서비스와 선택적 Redis 한 대. 자체 Kubernetes 클러스터를 굴리는 팀에게는 부담이 안 되지만, AWS Lambda + DynamoDB만 써오던 소규모 팀에게는 새로운 운영 카테고리다. 이 부분이 Claude Tag의 가장 큰 어필 포인트와 정확히 정면으로 부딪힌다. Claude Tag는 운영 부담 0을 파는 대신 런타임을 양도하고, OpenTag는 운영 부담 있음을 감수하고 런타임을 가져온다.

어느 쪽이 옳은가? 답은 데이터가 나가는 게 얼마나 문제인가에 달려 있다. 고객 지원 대화가 외부 SaaS로 송출되면 안 되는 산업(금융, 의료, 공공)에서는 OpenTag가 사실상 유일한 선택지다. 반대로 사내 잡담 수준의 사용이라면 Claude Tag의 편의성이 압도적이다.

• --

런타임 교체 가능성 — `runtime.ts` 한 파일이 에이전트의 운명을 결정한다

OpenTag 아키텍처에서 가장 흥미로운 지점은 runtime.ts의 시스템 프롬프트만 바꾸면 에이전트가 완전히 다른 존재가 된다는 점이다. 이건 단순한 프롬프트 엔지니어링 데모가 아니라, 에이전트 정의 = 단일 프롬프트라는 강한 디자인 철학을 보여준다.

예를 들어:

• 고객 지원 에이전트 → "You are a customer support agent for ${COMPANY}. Always respond in the customer's language. Never promise refunds without manager approval."
• 코드 리뷰 에이전트 → "You are a senior staff engineer reviewing PRs. Focus on data race, error handling, API contract changes. Be terse."
• 데이터 분석 에이전트 → "You are a data analyst. Always cite the source row count and time range. Never extrapolate beyond the data."

이 세 에이전트가 같은 런타임을 공유하고 같은 Slack 인터페이스를 사용한다. 즉 도구 호출 인터페이스는 표준화하고 에이전트 정체성은 프롬프트로 분리한 것이다. 이 패턴은 멀티 에이전트 시스템 설계에서 반복적으로 등장한다. 최근 OpenAI의 AgentKit, Anthropic의 Sub-agent, Google의 Agent2Agent 프로토콜도 모두 같은 방향을 가리키고 있다. OpenTag는 이 흐름을 오픈소스 + 셀프 호스팅 + Slack 인터페이스로 가장 가볍게 구현한 사례다.

다만 runtime.ts 하나에 모든 것을 담는 건 양날의 검이다. 컨텍스트 윈도우가 작은 모델(예: 경량 8B 모델)을 backend로 쓸 때, 시스템 프롬프트가 길어지면 즉시 성능이 떨어진다. 즉 OpenTag로 가면서 동시에 모델 사이즈를 줄이고 싶다면 시스템 프롬프트의 밀도를 상당히 끌어올려야 한다. 단순한 튜닝이 아니라 재작성에 가까운 작업이 필요하다.

• --

같은 코드가 네 개 메신저에서 — `bot-slack`만 바꾸면 된다

OpenTag의 진짜 장기적 가치는 Slack 종속이 아니다라는 점이다. 오늘은 Slack이지만, 내일은 Discord, 모레는 Telegram, 다음 분기는 WhatsApp. 메시징 플랫폼은 조직마다, 지역마다, 그리고 세대마다 달라진다. 한 번 만든 에이전트가 플랫폼 종속이라면 매번 다시 구현해야 한다.

@copilotkit/bot SDK는 이 문제를 플랫폼 비종속 코어 + 플랫폼 어댑터 패턴으로 푼다. 즉 bot 패키지가 메시지를 받아서 응답을 돌려준다는 추상 인터페이스만 정의하고, bot-slack이 그걸 Slack Events API에 매핑한다. Discord 어댑터를 추가하려면 bot-discord 패키지만 새로 쓰면 된다. 핵심 비즈니스 로직(runtime)은 한 줄도 바뀌지 않는다.

이 분리 덕분에 OpenTag는 메신저 시장 변화에 대한 헤지가 된다. WhatsApp가 기업용으로 강해지든, Discord가 SaaS 통합을 늘리든, Telegram이 클로즈드 환경을 강화하든 — 우리 에이전트 코드는 그대로다. 어댑터만 갈아끼우면 된다. Claude Tag가 Slack 종속인 것과 대비된다. 물론 Anthropic도 장기적으로는 멀티 플랫폼 확장을 할 가능성이 높지만, 오픈소스 우선 전략을 취하지 않는 한 우리 팀이 우선순위를 통제할 수 없다.

• --

우리 팀이 OpenTag를 골라야 하는 경우 — 의사결정 트리

OpenTag가 항상 옳은 선택은 아니다. 다음 4가지 신호가 모두 참이면 OpenTag가 합리적 선택이다.

1. 데이터 주권이 운영 정책이다 — 고객/환자/시민 데이터가 외부 SaaS로 송출되면 컴플라이언스 위반인 경우. 금융, 의료, 공공, 일부 B2B SaaS.
2. 모델 선택의 자유가 필요하다 — Claude 외 모델(GPT-5.5, Gemini, Llama, 사내 fine-tune)을 같은 Slack 인터페이스로 부르고 싶은 경우. 벤더 종속 회피는 단순한 비용 문제가 아니라 전략적 보험이다.
3. 멀티 에이전트 실험을 직접 한다 — 여러 시스템 프롬프트를 동시에 시험하고, 비교하고, A/B 테스트하고 싶은 경우. 클로즈드 SaaS에서는 이게 외부 요청 → 응답 대기의 비동기 게임이 된다.
4. 운영 엔지니어링 역량이 있다 — 두 개의 long-running 서비스와 Redis 정도를 운영상 작은 비용으로 보는 팀. K8s, Terraform, Datadog이 이미 깔려 있는 팀이라면 1시간 안에 띄울 수 있다.

이 중 하나라도 아니오라면 Claude Tag나 다른 관리형 SaaS가 합리적 선택이다. OpenTag는 기술적으로 우아한 게 아니라 전략적으로 필요할 때 정당화된다.

• --

결론 — *UX는 빌리되, 런타임은 가져온다*

OpenTag의 진짜 메시지는 기술 자체가 아니라 AI 에이전트의 운영 주권을 누가 쥐는가다. Claude Tag가 가장 빠른 onboarding을 파는 대신 런타임을 양도한다면, OpenTag는 MIT 라이선스의 4개 패키지를 파는 대신 우리 팀이 모든 결정을 직접 내리게 한다. 이건 단순한 오픈소스 vs 클로즈드 논쟁이 아니라, 에이전트 시대의 인프라 선택에 대한 질문이다.

Slack 안에서 Claude를 부르는 UX는 더 이상 차별화 포인트가 아니다. CopilotKit의 @copilotkit/bot이 증명했듯, 이 UX는 단 4개 패키지로 재현 가능하다. 진짜 차별화는 그 아래에서 어떤 모델을 돌리고, 어떤 도구를 연결하고, 어떤 데이터가 어디로 흐르느냐다. 그 선택을 우리 팀이 직접 하고 싶다면 OpenTag는 가장 가벼운 진입점이다. 반대로 그런 결정을 양도해도 되는 상황이라면 Claude Tag의 운영 부담 0은 강력하다.

둘 다 틀린 선택은 없다. 다만 우리 팀의 운영 정책, 데이터 거버넌스, 장기 전략에 따라 정답이 갈라진다. OpenTag는 그 정답을 우리 손에 두는 선택이다.

• --

• 카테고리: AI/ML · 태그*: OpenTag, ClaudeTag, CopilotKit, 셀프호스팅, Slack봇, AG-UI, generative UI, human-in-the-loop, AI에이전트, MIT라이선스