외국인 대상 미용시술 챗봇, AI 멀티에이전트로 도전해봤습니다! 💇🏻‍♀️🌍

소개

AI 툴을 계속해서 배우고 익히는 입장에서 늘 고민이 하나 있었습니다. 바로 이걸 어떻게 비즈니스로 연결할 수 있을까? 하는 것이었죠. 단순히 웹 서비스를 만들거나 효율화/자동화를 하는 수준이라면, AI를 "보조 도구"로 쓰는 것에 그칩니다. 저는 그보다 한 단계 나아가, AI 자체가 주체가 되는 서비스를 시도해보고 싶었습니다.

저는 그저 AI를 잘 쓰는 사용자에 머무르고 싶지 않았습니다. 이 변화의 시대에, AI를 도구로 넘어서 비즈니스의 중심축으로 삼아보자는 생각하에, 결국 직접 실험해보기로 결심했습니다.

제가 일하고 있는 도메인에서 요근래 10년간 겪어왔던 중, 가장 급속도로 커지고 있고 앞으로도 큰 성장성을 보이는 시장이 있었는데 이 시장이 바로 외국인을 대상으로 한 한국의 미용 시술 시장입니다. kpop의 유래없는 성장과 여러가지 컨텐츠들이 관광 영역에서는 정말 크게 느껴지고 코로나 때 공실로 거의 초토화가 되었던 명동이 다시 한국 최고의 상권으로 부상하면서 관련 업종이 정말 빠른 속도로 커지고 있습니다.

이 영역에서 흔히 도전하기 어려운 시장. 특히 중동 고객층은 정말 쉽게 접근하기 어려운 시장입니다. 하지만 세계 최고의 화장품 사용량, 겉으로는 안한다고 하지만 50%가 넘는 여성이 피부과 시술을 받았다는 딥리서치의 통계를 보고 이 영역에서 ai를 통한 아이디어로 시장을 뚫어본다면 정말 의미있는 시도가 될 거라고 생각했습니다.

이 고객들은 한국이 언어 장벽, 정보 접근성, 문화적 거리 등으로 중동 고객들은 한국 미용 시술 정보에 접근하기 어렵습니다. 그리고 단순히 정보 제공만으로는 부족하다고 느꼈습니다. 고객의 감정, 신뢰, 배경을 모두 고려한 AI 기반의 정서적이고 전문적인 대화 파트너가 필요하다고 생각했어요.

그래서 생각한 것이 바로 멀티 에이전트를 활용한 직관적인 챗봇 형태의 서비스였습니다. 단순한 FAQ가 아닌, 감정적으로도 지지하고 전문 정보도 정확하게 제공하는 구조를 설계해보았죠.

"AI 시대에 나도 직접 무언가를 만들어내는 주체가 될 수 있다"는 믿음을 품고 시작한 이 도전은, 단순한 기술 실험을 넘어서 제 가능성을 시험하는 여정이기도 했습니다.

진행 방법

🎯 핵심 아이디어

"중동 고객이 한국의 미용 시술 정보를 쉽고, 따뜻하게, 정확하게 얻을 수 있는 멀티 에이전트 기반 챗봇을 만들자!"

멀티 에이전트를 위한 프레임 워크는 진 버디님의 말씀에 따르면 상당히 많습니다.

copilotkit, google adk, langgraph, autogen, crewai

이 중에서 클로드와 이야기를 해보고 가장 쉽고 빠르다는 agno라는 프레임워크로 한번 도전해보기로 결정을 합니다.

멀티 에이전트 구성

https://github.com/agno-agi/agno

이 사이트의 링크를 클로드코드에게 주고 프로젝트의 구조를 잡아갑니다. 세부적인 프레임워크 코드에 대해서는 클로드도 학습이 되어있지 않을게 뻔하기 때문에 context7 mcp의 사용을 잊지맙시다.

이런 식으로 ai를 갈구면서 하나씩 구조를 잡고 최종적으로는 클로드 코드용 프롬프트를 달라고 합니다. 그러면 이런 식으로 프롬프트를 줍니다.

클라우드 코드 - 한국

이걸 그대로 클로드 코드에 가져가서 집어넣고 개발을 들어갑니다. 바이브 코딩을 할 수록 느끼는 점은 처음에는 이게 뭔가 싶고 모르는 말만 계속 보고있는게 맞나 생각이 들지만, 그럼에도 불구하고 코드를 계속 보고 있으면 뭔가 알게 됩니다. 그래서 언제 얘를 중지시켜야 되는 구나 이걸 알게되는 순간 내가 구현할 수 있는 범위가 늘어난다 이렇게 밖에 설명이 안되네요ㅋㅋ

한국 컴퓨터 화면의 스크린 샷

대략적으로 구성이 되었습니다. 여기서 하나씩 싸우고 갈궈가면서 좀 더 구조를 잡고, 현재 목표로 하는 구조를 잡습니다.

🧩 에이전트 구성

  • 감정 지지 에이전트

    • 사용자의 불안감, 일상적 고민에 대해 따뜻한 언어로 반응

  • 전문 정보 에이전트 (RAG)

    • 시술 정보나 시술별 차이, 효과, 부작용 등을 RAG 기반으로 정확하게 안내

  • 리뷰 요약 에이전트

    • 유튜브에서 제공되는 관련 시술 영상들을 요약해 제공

  • 할랄 가이드 에이전트

    • 한국 내 할랄 식당, 기도실, 종교적 배려 등을 안내

  • 오케스트레이션 에이전트

    • 위 4개의 에이전트 결과를 받아 종합해서 사용자에게 전달할 하나의 메시지를 생성

인터페이스 연결

  • Telegram Bot 인터페이스

    • MVP 테스트를 위해 사용. 다양한 고객 접점을 확보할 수 있는 확장성을 고려함.

웹사이트에 바로 모듈로 채팅을 붙이려다가 다른 스터디에서 텔레그램으로 많이들 작업하시는게 기억이 나서 이걸로 작업해보기로 합니다. 백엔드 서버를 따로 구축해놓고 다른 곳에는 그대로 가져다붙이면 될 거 같아서 우선 텔레그램으로 테스트하기로 합니다.

저희 스터디는 갈 수록 난이도가 높아집니다. 처음에는 supabase로 가볍게 설정부터하고 배포를 하면 아주 훌륭하다라고 칭찬을 듣다가 그걸 계속 하고 있으면 '언제까지 그런 상용서비스를 쓸거냐! 그런 나약한 상태로는 일을 할 수 없다'라는 질타를 받게 됩니다. 이번에는 postgreSQL로 로컬에서 직접 셋팅하고 도커에 올려서 개발서버로 테스트를 하기로 결정합니다.

iPhone의 WhatsApp 스크린 샷

도커라는 말도 이제는 거의 정확하게 이해를 하게 된 거 같습니다. 처음에는 챗봇이 제 말을 아예 알아듣지도 못하다가 몇번의 실패 후에 웹훅도 설정하여 드디어 작동하기 시작합니다. 비록 묻는 말에 대답은 못해도 애기들이 옹알이 하는 것 처럼 json을 그대로 뱉어내는 모습을 보고 참 기쁘고 즐거웠습니다.

클로드코드를 갈궈가면서 에이전트를 더 설정을 해줍니다.

녹색 화면이있는 컴퓨터 화면의 스크린 샷

이런 식으로 끊임없이 갈구고 싸워나가다 보면 하나씩 작동을 하기 시작합니다.

문자 메시지가 포함 된 WhatsApp 앱의 스크린 샷

여기서는 뭔가 근본적인 대책이 필요하다고 느끼고 접근법을 좀 다르게 해보기로 했습니다. 모델도 바꾸고 시스템 프롬프트도 바꿔가면서 에이전트 셋팅을 해야겠다 생각이 들었습니다. 항상 좋은 정보를 들고 오시는 YKim님이 이야기하셨던 openrouter라는 서비스가 생각이 났습니다.

  • OpenRouter

    • Claude, GPT-4, Mistral 등 다양한 모델을 API로 설정하고 성능을 비교함.

https://openrouter.ai/

LMS의 통합 인터페이스

이렇게 생긴 서비스로 여러가지 llm을 하나의 api로 결제까지 하나로 할 수 있는 재미있는 서비스 였습니다. 굳이 llm마다 환경변수 설정 다하고 api 종류별로 다 집어넣고 노가다를 할 필요가 없이 llm을 로컬 모델처럼 바꿔가면서 써볼 수 있다는 거죠. 여러가지 모델을 써볼 수 있고, 똑같은 쿼리로 어떤 결과가 나오는지, 파라메터를 바꿔가면서 즉각적으로 테스트도 해볼 수 있는 아주 재미있는 서비스였습니다.

Google Analytics Dashboard의 스크린 샷
메시지가있는 채팅 페이지의 스크린 샷

이렇게 같은 쿼리로도 llm마다 다양한 답변을 보여줍니다. 여기서 파라메터 설정을 바꿔보면 또 여러가지 반응들을 볼 수 있어서 llm의 구조에 대해서 좀 더 배울 수 있게되는 부분이 있습니다.

이걸로 gemini pro로 바꿔보기도 하고 시스템 프롬프트도 바꿔가면서 챗봇을 옹알이하던 수준에서 사람으로, 더 똑똑한 사람으로 업그레이드 시켜갑니다.

한국어 문자 메시지의 스크린 샷

여기까지 작업을 하니, 뭔가 이상하다는 느낌이 좀 들기 시작했습니다. 애초에 설계는 감정적인 아이도 있고 똑똑한 아이도 있고, 소문을 빨리 줏어듣는 아이도 있어서 네 개의 에이전트가 서로 정보를 주고 받으면서 같이 일을 해야하는데 전체를 관리하는 오케스트레이션 에이전트 한놈만 일하고 나머지는 아예 일을 안하는 느낌이었습니다. 그래서 agno에서 지원하는 모니터링 시스템이 없나하고 열심히 찾아봤는데 자체적으로 지원하지는 않는 느낌이었습니다.

이 부분을 확인하기 위해서 찾은 정보는 에이전트들이 어떻게 작동하고 있는지 더 잘 확인하기 위해, OpenTelemetry를 활용해 시스템 안에서 어떤 일이 일어나고 있는지를 들여다볼 수 있게끔 할 수 있다는 걸 찾았습니다. 예를 들어, 어떤 에이전트가 응답이 느린지, 어디서 오류가 나는지, 어떤 순서로 호출되는지 등을 눈에 보이게 추적할 수 있게 된 거예요. 멀티 에이전트 구조처럼 복잡한 시스템일수록, 이렇게 보이는 상태로 관리하는 게 정말 중요하다는 걸 알게 되었습니다.

NFL 통계 - 스크린 샷 - NFL 통계 - 스크린 샷 - NFL 통계 -
한국어 텍스트가있는 검은 색 화면

이런 식으로 누가 일을 하고 있고 어떤 일을 해서 어떻게 전달해서 최종적인 결과물이 뭔지 살펴볼 수 있도록 할 수 있다는 걸 배웠습니다. 확인한 결과, 역시 관리자 한 명만 일하고 있고 나머지 에이전트들은 아무런 일을 하고 있지 않았습니다. 이걸 해결하려면 llm api부터 다 뜯어야하는데 여러가지를 써보려고 openrouter에서 api를 받아오지만 이걸 트래킹하려면 Lang DB에서 이 api를 지원해야하는데 이걸 지원을 안한다는 걸 알게되었습니다.

멀티 에이전트 쪽은 역시나 가장 최신의 기술이기 때문에 아직 준비되어 있는 것도 적다는 걸 알았고, 지금은 뭔가 하기 힘든 영역일 수록 앞으로 기회는 더 크다고 생각이 듭니다.

결과와 배운 점

✅ 배운 점

  • 멀티 에이전트는 확실히 고도화된 분야라는 걸 체감했습니다. 단순한 챗봇을 넘어, 여러 역할의 AI가 협업하는 구조는 상상 이상으로 유용했고, 실제 구현도 가능합니다.

  • 비전공자도 초기 셋업은 충분히 가능하다는 점도 큰 수확이었습니다. LLM에게 직접 구조를 물어보면서도 많은 진척이 가능했어요.

  • 다만, 정확하게 원하는 방식으로 작동하게 하려면 고도의 설계 능력이 요구됩니다. 시스템 프롬프트, 파라미터 설정, 아키텍처 설계 등에서 시행착오가 많았습니다. 이 기술을 가지고 있다면 앞으로 다가올 AI 시장에서 아주 강력한 무기를 들고 있는 것과 마찬가지라는 생각이 들었습니다.


🔥 AI 시대의 주역이 될 수 있다는 마음가짐으로, 빡세게 도전해보세요! 생각보다 멀리 갈 수 있습니다. 함께 갑시다!

2
7개의 답글

뉴스레터 무료 구독

👉 이 게시글도 읽어보세요