pile·
AI / ML·매스프레소(콴다)매스프레소(콴다)·

새 QANDA 에이전트는 어떻게 만들었나

콴다 백엔드 팀이 Gen AI 시대에 맞춰 앱을 단일 채팅 인터페이스 기반의 능동적 AI 어시스턴트로 재설계한 과정을 다룬다. 핵심은 사용자의 학습 의도를 실시간으로 파악해 대응하는 멀티 에이전트 구조이며, 시스템을 Agent(의도), Tool(해결), Block(응답)으로 추상화하고 LangGraph로 구현했다.

핵심 포인트
  • 기존 "사진 찍으면 풀이" 단일 유즈케이스를 넘어 개념 설명, 유사 문제, 퀴즈 생성 등 다양한 학습 요구를 하나의 채팅 흐름에서 처리하도록 재설계했다.
  • 시스템을 Agent(의도 이해), Tool(문제 해결), Block(시각적 응답) 세 개념으로 추상화했다.
  • 하나의 LLM으로 의도를 one-shot 분류하기 어려워, 문제 풀이 흐름과 자료 생성 흐름을 나눠 전담 Agent를 두는 Swarm 아키텍처로 hand-off한다.
  • 문제 풀이 Agent는 ReAct 구조가 다수 문제와 순서에서 일관성이 떨어져 Plan-and-Execute(+Replan)로 전환했다.
  • 퀴즈, 플래시카드처럼 상호작용이 필요한 결과물은 Artifact라는 독립 단위로 분리해 별도 뷰어와 상태 저장, 비동기 도메인으로 처리한다.
  • Agent 로직과 채팅 UI/흐름 관리를 별도 레이어로 분리해 모듈화, 확장성, 안정성을 확보했다.
상세 정리
  • 방향 재정의: "사용자 학습 목적을 실시간 이해하고 LLM으로 최적 UI/UX 제공"을 목표로, 기능별 API와 화면을 만드는 대신 통합 Agent가 주도하는 단일 채팅 구조를 택했다.
  • Swarm 구조: 첫 요청은 determine_active_agent가 문제 풀이 Agent와 자료 생성 Agent 중 선택해 책임을 이관하고, 컨텍스트가 바뀌면 다른 Agent로 hand-off한다. 정책 안내 info_agent와 쿼터 소진 유저용 vanila_agent도 있다.
  • Swarm 장단점: 각 Agent가 자기 역할만 알아 프롬프트/히스토리를 최소화하고 유즈케이스별 평가/테스트 분리와 관심사 분리, 재사용이 쉬운 대신 목표 도달까지 시간과 비용이 늘어난다.
  • ReAct 한계: 기능을 Tool로 두고 맥락에 따라 호출하는 ReAct는 다수 문제 처리에서 순서가 꼬이거나(1,2번을 다시 푸는 등) DB 우선 조회를 무시하고 눈앞 문제만 처리하는 greedy 경향을 보였다.
  • Plan-and-Execute 전환: 전체 요청 구조를 먼저 Plan으로 정리한 뒤 Execute에서 Tool을 순차 호출하며 상태를 갱신하고, Optional한 Replan으로 결과를 다시 계획에 반영해 순서와 greedy 문제를 해소했다.
  • 문제 풀이 Agent 요구: step-by-step 풀이, 콴다 DB 기반 유사 문제 추천, 자필 풀이 첨삭, 그래프 생성, 다수 문제 분리, 용어 설명을 처리하며 최소 정답률 유지와 DB 문제 활용률 향상으로 비용 최적화도 요구됐다.
  • Artifact 정의: 별도 뷰어에서 상호작용이 일어나 그 결과가 시스템 상태와 AI 응답에 영향을 주는 독립 학습 단위로, 조회 외 CRUD 이벤트 발생이나 세션 상태 저장, 분리된 UI가 필요할 때 Artifact로 판단한다.
  • Generator Agent: 자료 생성 흐름을 담당하며 Plan-and-Execute를 쓰되 복합 조건 로직이 없어 Replan은 생략하고, 생성 Tool이 작동하면 비동기로 Quiz 등 Artifact 도메인 플로우를 실행한다.
  • Artifact 동작: Agents Swarm과 자료 생성 Agent가 생성/수정/읽기 라우팅을 맡고 실제 로직은 도메인별 Artifact Agent(예: Quiz Agent)가 수행하며, 각 Artifact는 자체 뷰로 독립 상호작용한다.
  • Agent와 채팅 분리: 초기엔 Agent가 응답 생성, 블록 변환, 채팅 표시까지 모두 맡아 너무 무거웠는데, Agent는 의도 이해와 Tool 활용, 응답 생성에만 집중하고 쿼터 확인, 컴포넌트 변환, 대화 흐름은 별도 Backend 채팅 레이어로 옮겼다.
  • 구현 스택: 멀티 에이전트, 의도 분기, Tool 호출, Plan-and-Execute, Artifact 생성, Evaluation 시각화까지 모두 LangGraph 기반이며, 초기부터 써온 LangChain 경험을 접목했다.
  • 후속 과제: Evaluation 체계, Latency(TTFT/TPOT)와 Cost(Agent/Tool별, 캐시 비율) 모니터링, Vector DB 기반 Short-Long Term Memory 개인화, 수백 개 Prompt의 A/B 테스트를 다음 편에서 다룰 예정이다.
왜 읽나LLM 기반 제품을 멀티 에이전트, Plan-and-Execute, Artifact 구조로 설계하려는 백엔드/AI 엔지니어에게 실전 아키텍처 참고서.
매스프레소(콴다)
매스프레소(콴다) 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (0)

이 글과 비슷한

  1. AI / ML·LY CorporationLY Corporation·

    Grafana에서 자연어로 장애 원인을 분석하기: LLM 에이전트 기반 SRELens 개발기

    LY Corporation Home SRE 팀이 장애 분석 시 메트릭·로그·트레이스가 각각 다른 화면에 흩어져 있는 문제를 해결하기 위해 Grafana 플러그인 SRELens를 개발했다. SRELens는 LLM 에이전트가 자연어 질의를 받아 실제 관측성 데이터를 조회하고, 근거와 함께 장애 원인 후보를 정리해 주는 도구다. LGTM-P 스택(Loki·Grafana·Tempo·Mimir·Pyroscope)과 FlavaMCP 게이트웨이를 통합해 단일 채팅 인터페이스에서 멀티시그널 분석이 가능하다.

    #llm-app#mcp#observability+2