Qwen Cloud Global AI Hackathon 2026 — Track 3: Agent Society를 위해 작성됨.

아이디어

대부분의 "AI 마케팅" 도구들은 하나의 LLM(대규모 언어 모델)이 여러 역할을 수행하는 방식입니다. 즉, 소셜 포스트를 생성하는 단일 프롬프트, 광고 분석가인 척하는 다른 프롬프트, 그리고 자신의 준수 여부를 스스로 감사하는 척하는 또 다른 프롬프트가 이어지는 식입니다. 이번 해커톤의 Track 3는 이와 다른 것을 요구합니다. 바로 실제 팀처럼 업무를 분담하고 서로 의견을 달리할 수 있는 전문화된 에이전트들로 구성된 _에이전트 사회 (agent society)_입니다.

이것이 제가 Nexus AI와 함께 구축하고자 했던 것입니다. Social Manager, Brand Guardian, Digital Marketer, Ads Manager, SEO Expert, Analytics, Conversion Optimizer, Community Engagement, Market Intelligence, Dynamic CFO, Security SRE, Calendar Planner, 그리고 Media Generator까지 총 13개의 전문 에이전트로 구성되어 있으며, 이들은 Alibaba Cloud의 DashScope SDK를 통한 Qwen-Max를 기반으로 중앙 오케스트레이터(orchestrator)에 의해 조정됩니다.

진정한 "사회"가 된 순간

제가 가장 중요하게 생각하는 기능은 단일 에이전트의 기능이 아니라, 두 에이전트 사이에서 일어나는 일입니다. Social Manager가 LinkedIn 포스트 초안을 작성합니다. 그 무엇도 자동으로 게시되기 전에, Brand Guardian이 해당 초안을 독립적으로 검토합니다.

실제 실행 사례 중 하나에서, Social Manager의 초안에는 _"14일 이내에 ROAS 4.2배 보장, 아니면 환불"_이라는 문구가 포함되어 있었습니다. Brand Guardian은 이를 포착하여 근거 없는 재무 보장이라고 플래그를 지정하고, 게시를 차단했으며, 구체적인 이유와 수정 제안을 담아 인간 승인 대기열로 전달했습니다. 그와 동시에, 해당 문구가 없는 두 번째 초안은 문제없이 통과되어 동일한 사이클 내에서 자동으로 게시되었습니다.

이것이 바로 핵심적인 가치입니다. 실제로 작동하는 것, 즉 두 에이전트와 하나의 거부권(veto), 그리고 그에 부착된 실제 이유입니다. 단순히 서로 달라 보이는 두 개의 결과물을 만들어내는 공유된 스크립트가 아닙니다.

실제로 무엇이 고장 났는가 (데모에는 아무도 넣지 않는 부분)

이 빌드에 대한 솔직한 버전은 다음과 같습니다. 제가 물려받은 코드베이스는 프로젝트 중간에 비동기 (async) PostgreSQL 설계에서 동기 (synchronous) SQLite 설계로의 마이그레이션 (migration)을 시도했으나, 결코 완료되지 않은 상태였습니다. 데이터베이스 계층은 동기 방식으로 이동했지만, 모든 라우터 (router)는 여전히 비동기 세션 (async session)을 기대하고 있었습니다. 설정 파일 (config file)은 코드에서 여전히 기대하는 것과는 다른 필드 이름으로 다시 작성되어 있었고, 테스트 스위트 (test suite)의 픽스처 (fixtures)는 여전히 비동기 방식이었습니다. 이 중 그 어느 것도 제대로 부팅조차 되지 않았습니다.

작동하는 데모를 만들기 위해서는 단 하나의 에이전트 (agent)라도 실행되기 전에 설정, 데이터베이스 세션 처리, 모든 라우터, 오케스트레이터 (orchestrator), 테스트 픽스처에 이르기까지 전체 스택 (stack)을 관통하는 이러한 불일치를 추적해야 했습니다. 일단 부팅이 된 후에는 더 까다로운 버그가 조용히 나타났습니다. 일부 에이전트들이 잘못된 형태의 데이터를 조용히 반환하고 있었던 것입니다. 예를 들어, 주제로 "SEO"를 언급하게 된 소셜 포스트 (social post)가 있으면, Brand Guardian의 검토 작업이 자신의 템플릿 대신 SEO 에이전트의 응답 템플릿에 의해 가로채지는 일이 발생했습니다. 이는 기반이 되는 시뮬레이터 (simulator)가 단순한 키워드 매칭 (keyword matching) 방식으로 응답을 라우팅했기 때문이며, "SEO"는 마케팅 포스트에서 언급될 수 있는 일반적인 단어였기 때문입니다.

저는 "API 호출이 200을 반환했다"는 것을 정답의 증거로 신뢰하기를 거부하고, 대신 13개의 에이전트 각각이 전체 사이클 동안 실제로 무엇을 생성하는지 엔드 투 엔드 (end to end)로 체계적으로 감사 (auditing)함으로써 이 문제를 발견할 수 있었습니다. 13개 중 2개가 조용히 잘못되어 있었습니다. 이를 해결하려면 모든 에이전트의 라우팅 키를 사용자 콘텐츠와 절대로 충돌할 수 없는 무언가, 즉 출력물이 다른 누군가와 우연히 공유할 수 있는 일반적인 단어가 아니라 각 에이전트 고유의 고정된 시스템 프롬프트 (system prompt)를 기반으로 다시 설정해야 했습니다.

Qwen Cloud를 직접 사용하기

배관 공사가 완료되자 통합 자체는 간단했습니다: 모든 에이전트가 공유하는 단일 QwenClient를 통해 Alibaba Cloud의 네이티브 엔드포인트에 대해 dashscope.Generation.call()을 호출하고, 데모가 실시간 네트워크 조건이나 API 할당량에 의존하지 않도록 고충실도 로컬 시뮬레이터(high-fidelity local simulator)를 폴백(fallback)으로 사용했습니다. 저는 시뮬레이터와는 독립적으로 실제 경로를 검증했습니다. 실제 클라이언트 클래스를 통해 문자 그대로 "reply with exactly: REALAPIWORKED"을 전송했고, Qwen-Max로부터 실제 단어를 받았으며, 시뮬레이터가 그것을 조용히 가로채지 않았음을 확인했습니다.

다음 단계

에이전트들이 실제 소셜 계정(X/Twitter부터 시작)에서 활동할 수 있도록 하는 실제 OAuth와, 이것이 단순한 로컬 데모가 아닌 배포를 진행하는 것이 남아있습니다. 에이전트 로직과 Qwen 통합은 돌이켜보면 항상 쉬운 부분이었습니다. 진정한 작업은 '다중 에이전트(multi-agent)'라는 것이 제가 주장할 수 있는 명제가 아니라, 증명할 수 있는 사실로 만드는 것이었습니다.

Qwen Cloud Global AI Hackathon 2026, 트랙 3: 에이전트 사회를 위해 제작됨.
코드: github.com/MelekhYomi/mark-agen-nexus-ai

_Whatsapp +2347068561873