에이전트로 커뮤니티를 확장하면서도 사람다움을 지키는 법

Vercel에서 개발자 커뮤니티는 모든 활동의 중심입니다. 커뮤니티야말로 우리가 만든 제품을 실제로 사용하는 사람들과 가장 가까이 소통할 수 있는 통로이기 때문입니다.

커뮤니티가 성장하면서 자동화가 규모 확장에 도움을 주긴 했습니다. 하지만 여전히 질문이 묻히고, 라우팅에 시간이 걸리고, 컨텍스트 전환 때문에 정작 전문성이 필요한 업무에 집중하기 어려웠습니다. 무엇보다 자동화는 가장 중요한 순간, 즉 누군가와 진심으로 소통하며 도움을 주는 그 순간을 대신할 수 없었습니다. 진심으로 관심을 가져주는 사람과 대화하는 느낌은 AI로 재현할 수 없으니까요.

그래서 사람이 직접 하지 않아도 되는 라우팅, 분류, 후속 조치를 에이전트에 맡기기로 했습니다. 이 시스템을 Community Guardian이라 부릅니다. Guardian이 어떤 역할을 하는지, 어떻게 만들었는지, 그리고 엔지니어가 아닌 사람도 에이전트를 만들어 배포할 수 있는 방법까지 함께 이야기해 보겠습니다.

Community Guardian: 운영 레이어

새 게시글이 올라오면 Guardian이 내용을 분석하고, 중복 여부를 확인한 뒤, 해당 분야에 전문성이 있고 여유가 있는 팀원에게 배정합니다. 한 사람당 최대 10개의 질문까지만 담당하고, 이후 새 질문은 다른 팀원에게 넘어가므로 시간대에 관계없이 업무량이 고르게 분산됩니다.

놓치는 질문은 없습니다. 48시간 동안 답변이 없으면 Guardian이 다른 팀원에게 재배정합니다. 추가 정보가 필요한 경우에는 리마인더를 보내고, 대화가 해결되었는지도 자동으로 감지합니다.

내부적으로 Guardian은 AI Gateway를 통해 Claude를 사용하며, Vercel Workflows 위에서 실행됩니다. 덕분에 10분마다 상태를 확인하고, 주기 사이에는 리소스를 소비하지 않고 대기할 수 있습니다.

여기까지가 운영 측면의 이야기입니다. 하지만 팀이 양질의 답변을 하려면 더 나은 컨텍스트도 필요했습니다.

인텔리전스 레이어: 리서치 어시스턴트 c0

Guardian이 운영 업무를 관리하는 동안, c0는 심층 리서치를 담당하는 에이전트입니다. 팀이 이미 업무에 사용하고 있는 Slack에 통합되어 있습니다.

팀원이 특정 스레드에 대한 맥락이 필요하면, c0가 지식 베이스, 문서, GitHub 이슈, 과거 논의 내역을 검색해 컨텍스트 패키지를 구성합니다. 이 패키지 덕분에 개인의 기억에 의존하지 않고도 더 빠르고 정확하게 답변할 수 있습니다.

c0의 역할은 개별 스레드 지원에 그치지 않습니다. 프로덕트 팀과의 피드백 루프를 완성하는 데도 활용됩니다. 커뮤니티의 감정 동향과 반복적으로 발생하는 기술적 난관을 추적하기 때문에, 일주일치 게시글을 몇 시간 들여 직접 분석할 필요 없이 c0에 "주요 제품 피드백"을 요청하면 실제 데이터를 바탕으로 프로덕트 회의에 참여할 수 있습니다.

사람이 집중할 수 있는 시간 되찾기

도입 후 첫 23일간, 이 시스템은 281명의 고유 사용자를 지원했습니다.

실질적인 답변은 여전히 모두 팀원이 직접 작성합니다. 에이전트는 그 답변을 둘러싼 나머지 모든 것을 처리할 뿐입니다. 반복적인 분류와 추적 업무에서 벗어난 덕분에 팀원들은 복잡한 문제를 함께 디버깅하거나, 관계를 쌓거나, 커뮤니티 전체를 위한 콘텐츠를 만들거나, 그저 관심을 갖고 있는 개발자들과 즐겁게 소통하는 데 시간을 쓸 수 있게 되었습니다.

직접 만들어 보세요

이런 시스템을 만드는 데 개발자일 필요는 없습니다. 아이디어만 있으면 됩니다. 저도 엔지니어가 아닙니다. 커뮤니티를 관리하고 개발자들과 대화하는 게 제 일입니다. 물론 우리가 해결하려는 문제를 이해하고 있지만, 매일 프로덕션 코드를 작성하지는 않습니다.

아이디어는 취리히에서의 발표에서 시작되었습니다. 당시 커뮤니티 워크플로를 자동화하는 방법을 보여주었는데, 그건 스크립트, 규칙, if-this-then-that 로직으로 이루어진 전통적인 자동화였습니다. 동작은 했지만 취약했습니다. 예외 상황이 생길 때마다 새 규칙을 추가해야 했으니까요.

더 똑똑한 방식을 원했기에, 코딩 에이전트를 활용해 사고 레이어(thinking layer)를 추가하는 실험을 시작했습니다. "새 게시글 도착"과 "행동 실행" 사이에 놓이는 단계입니다. "'billing'이 포함되면 결제 팀으로 라우팅"하는 방식 대신, "게시글을 읽고, 이 사람이 실제로 필요로 하는 것을 파악한 다음, 판단하라"는 방식으로 바뀐 것입니다.

사고 레이어는 마치 또 한 명의 DX 엔지니어가 각 게시글을 살펴보는 것과 같습니다. 사용자가 "작동이 안 돼요"라고 말할 때 행간을 읽고, 3개월 전 GitHub 이슈와 연결 짓고, 좌절감인지 단순한 혼란인지 구분하며, 에스컬레이션할지 추가 정보를 수집할지 판단할 수 있습니다. 이런 방식으로 구축했기에 저는 원하는 것을 일반 영어로 설명하고, 작동하는 코드를 받아 실제 커뮤니티 스레드에 테스트한 뒤, 반복적으로 개선할 수 있었습니다.

작업별로 다른 모델을 사용하고, 에이전트가 문서와 커뮤니티를 읽을 수 있게 하고, 실패 시 일시 중지·재개·복구가 가능하도록 만들고 싶었습니다. 이 모든 것을 처음부터 직접 구축하는 대신, 필요한 기능을 코딩 에이전트에 설명했고, 이미 이런 복잡성을 처리해 주는 AI Gateway, AI SDK, Vercel Workflows를 조합하는 방향으로 자연스럽게 정리되었습니다.

시스템을 만든 프롬프트들

첫 번째 프롬프트는 핵심 아이디어를 담은 것이었습니다. "커뮤니티 운영을 도와줄 에이전트를 만들어 줘. 게시글 배정이나 포맷팅 같은 일상적인 업무를 처리하는 거야. 어떤 모델이 가장 잘 맞을지 아직 모르니까 API 키를 새로 발급받지 않고도 쉽게 전환할 수 있게 해 줘. AI SDK를 사용해."

이후로는 시스템을 이해하게 되면서 프롬프트가 점점 구체적으로 발전했습니다. "10분마다 실행돼서 최신 스레드를 확인하게 해 줘." 처음에는 크론 잡을 썼지만, Vercel Workflows로 전환했습니다. 지속적 실행(durable execution) 덕분에 에이전트가 확인 주기 사이에 일시 중지했다가 정확히 멈춘 지점부터 재개할 수 있었기 때문입니다.

"4시간마다 배정 담당자를 로테이션해 줘." 프롬프트 하나가 다음 질문을 열어주었습니다. 튜토리얼이나 문서를 따른 게 아니라 대화를 나눈 것이고, 시스템은 그 대화 속에서 자라났습니다.

정확한 용어를 알 필요도, 코딩을 할 줄 알 필요도 없습니다. 문제를 충분히 잘 알아서 설명할 수 있고, 기대와 다르게 동작할 때 기꺼이 반복 수정할 의지만 있으면 됩니다. 사고 레이어는 자동화를 "정해진 규칙을 그대로 따르는 것"에서 "상황을 이해하고 판단을 내리는 것"으로 바꿔 줍니다.

진심을 담아 만들기

커뮤니티의 본질은 사람입니다. 우리는 팀원들이 충분한 시간과 에너지를 갖고 온전히 몰입하며, 커뮤니티의 개발자들과 함께, 그들을 위해 만들어 갈 수 있기를 바랍니다.

비슷한 시스템을 만들어 보고 싶다면, c0는 Slack, Teams, Discord 등 다양한 플랫폼에서 에이전트를 구축할 수 있는 통합 TypeScript SDK인 Chat SDK로 만들었습니다. Guardian은 지속적 실행을 위해 Vercel Workflows를 사용합니다. 여러분이 만든 것을 커뮤니티에서 공유해 주세요. 저희가 경험하며 배운 것들을 언제든 기꺼이 나누겠습니다.