Chat SDK X 어댑터 공부 정리 | 추상화가 어디까지 책임지는지

Vercel 블로그에서 Chat SDK에 X 어댑터가 추가됐다는 발표가 있었다. 이미 Slack, Discord, GitHub, Teams, Telegram, WhatsApp을 지원하던 SDK에 X(구 Twitter)가 더해진 것이다.

처음엔 채널 하나 늘어난 소식 정도로 읽고 넘기려 했다. 그런데 발표를 좀 더 읽다 보니 “단일 코드베이스로 여러 채널을 지원한다”는 구조 자체가 궁금해졌다. 어댑터가 뭘 담당하고 뭘 담당 안 하는지, 그리고 X 특유의 제약들이 어떻게 반영됐는지 문서를 훑으며 정리해봤다.

1️⃣ 이게 뭐냐?

Vercel Chat SDK는 챗봇을 여러 메시징 플랫폼에 배포할 수 있게 해주는 SDK다. 이번 업데이트로 X 어댑터가 추가되면서 지원 채널이 일곱 개가 됐다.

새 어댑터는 X API v2와 X Activity API를 활용한다. 공개 멘션에 답하거나 DM 대화를 이어갈 수 있고, CRC 검증이나 웹훅 서명 확인처럼 X 특유의 보안 처리는 어댑터 레이어가 알아서 해준다. 오래 실행되는 봇을 위한 OAuth 토큰 자동 갱신도 지원한다.

다만 제약도 명확하다. 반응은 ‘좋아요’만 지원되고, 응답은 완성된 다음 한 번에 게시된다. X 자체에 네이티브 스트리밍이 없기 때문이다. 자동화된 메시지에는 X의 자동화 정책이 그대로 적용된다는 점도 문서에 적혀 있었다. 이 제약들이 어댑터가 “없애줄 수 없는 것들”이라는 게 흥미로웠다.

내가 이해한 바로는, 어댑터는 채널마다 다른 인증·서명 방식을 추상화해서 개발자에게 통일된 인터페이스를 내주는 레이어다. 채널이 늘어날 때마다 코드베이스를 전체적으로 손보지 않아도 된다는 게 이 구조의 이점인 것 같았다.

2️⃣ 내가 든 생각

어댑터 패턴이 이런 방식으로 쓰이는 게 흥미로웠다. Slack 웹훅, GitHub 앱 인증, X CRC 검증은 내부적으로 꽤 다른 방식으로 돌아가는데, 어댑터가 그 차이를 가려줌으로써 개발자는 하나의 인터페이스만 상대하면 된다. 플러그인 구조에 가까운 느낌이었다.

👉🏻 그런데 디자이너 관점에서 보면 다른 질문이 생겼다. 코드 레이어를 통일해도, 채널마다 UX 맥락이 다른 건 그대로다.

X에서 스트리밍이 안 된다는 제약이 그 생각을 자극했다. Slack에서는 봇이 타이핑하는 것처럼 보이지만, X에서는 응답이 완성될 때까지 아무것도 없다가 한꺼번에 게시된다. 같은 SDK로 만든 봇인데 사용자가 느끼는 건 꽤 다를 것이다. 추상화 아래 숨긴 채널 차이가 경험으로는 다시 올라오는 것 같았다.

💡 여기서 드는 질문? 코드 레이어를 통일하면 개발 편의성은 생기는데, 각 채널의 UX 특성은 결국 어디서 다시 신경 써야 하는 걸까?

⭐️ 마지막으로, Chat SDK X 어댑터를 공부하며 든 생각

정리해보니 “단일 코드베이스로 여러 채널 지원”이라기보다, “채널마다 다른 제약을 어댑터가 각각 담당한다”에 가까운 일이었다. 스트리밍 없음, 좋아요만 지원 — 이 제약들은 추상화 뒤에 숨어 있는 게 아니라 문서에 버젓이 나열되어 있었다.

---

참고 원문: Chat SDK adds X adapter support