오늘날 많은 IT 기업과 스타트업이 Slack을 핵심 협업 도구로 사용합니다. Slack은 업무 생산성을 높이고, 문제 해결 시간을 단축하도록 다양한 기능을 지원합니다. 그러나 Slack의 기본 워크플로만으로는 복잡한 멀티 에이전트 자동화와 고도화된 외부 서비스 통합에 한계가 있습니다. 이에 여전히 수동으로 처리해야 하는 작업이 남아 있습니다.

예를 들어, 회의 중이거나 외근 중임을 알리려면 프로필 상태를 직접 바꾸거나 별도의 자동화 도구를 설정해야 합니다. 또 웹사이트 데이터를 확인하려면 Google Analytics 4(GA4), Notion, GitLab과 같은 서비스에 개별 접속하거나, Zapier 같은 통합 도구를 추가로 구성해야 합니다. Slack은 이제 혁신 기업들의 ‘업무 허브’로 자리 잡았습니다. 그러나 복잡한 워크플로를 자동화하려면 추가 개발이나 외부 도구 연동이 필요한 것이 현실입니다.

저는 이 문제를 n8n의 Agentic AI 구조에 기반한 올인원 에이전트 'Friday'로 해결했습니다. Friday는 하나의 Slack 봇이 다양한 업무 도구를 연결하고 작업을 자동화하는 시스템입니다. 사용자의 자연어 요청을 해석하고, 필요한 전문 AI 에이전트를 호출해 GA4, Slack 등과 상호작용을 하며, 실제 업무를 자동 수행합니다. 이로써 Slack에서 사용자 프로필 상태를 자동 변경하고, 웹사이트 데이터를 자동 분석하며, 특정 주제와 관련된 Slack 메시지를 자동 검색할 수 있습니다.

이 글에서는 Friday의 전체 아키텍처와 핵심 설계 전략, 워크플로 단계별 동작 방식과 멀티 에이전트 구조, 한계와 개선 방향을 함께 살펴보겠습니다.

Friday의 핵심 아키텍처: '라우터-전문가'​

Friday의 핵심 워크플로는 Slack에서 발생한 사용자의 자연어 입력을 분석해 적절한 AI 에이전트로 라우팅하고, 각 에이전트가 전문 도구를 활용해 작업을 수행하는 구조입니다.

이 아키텍처는 마이크로서비스 아키텍처(MSA)의 설계 원칙을 AI 에이전트에 적용했습니다. 하나의 거대하고 복잡한 '만능 AI'를 만드는 대신, 명확한 단일 책임을 진 '전문 AI' 여러 개를 두고, 이들 앞에 'API 게이트웨이'처럼 '라우터'를 둡니다.

이 구조의 장점은 명확합니다.

  • 문제 격리와 모듈성 확보: 특정 에이전트가 실패해도 다른 에이전트는 영향받지 않습니다. 예를 들어, 'GA4 분석 에이전트’에서 오류가 발생해도 '프로필 변경' 에이전트는 정상 동작합니다. 새로운 'Notion 검색 에이전트'를 추가하기도 쉽습니다.
  • 정확성과 안정성 향상: 각 에이전트는 하나의 임무에 맞춰 최적화된 프롬프트와 도구를 사용하므로, 정확하고 안정적인 결과를 제공합니다.
  • 유지보수 용이: GA4 API가 변경되면 'GA4 분석 에이전트' 노드만 수정하면 됩니다. 각 에이전트가 독립적으로 동작하므로 유연하고 안정적이며, 워크플로를 변경하고 트러블슈팅하기가 더 쉽습니다.

Friday의 워크플로는 다음 네 단계로 작동합니다.

  1. 트리거: 사용자가 Slack에서 @Friday를 멘션해 작업을 요청합니다.
  2. 의도 분류: LLM이 사용자의 메시지를 분석해 5가지 카테고리 중 하나로 분류합니다.
  3. 에이전트 실행: 분류 결과에 따라 해당 전문 에이전트가 실행돼 실제 도구와 상호작용을 하며 작업을 수행합니다.
  4. 응답 전송: 에이전트의 작업 결과를 최초 요청 메시지의 스레드로 전송합니다.

1단계: 트리거와 대화 메모리 생성​

Friday 워크플로 1단계: Slack Trigger 기반 흐름 | 인포그랩 GitLab
Friday 워크플로 1단계: Slack Trigger 기반 흐름

Friday의 워크플로는 Slack Trigger 노드에서 시작합니다. 사용자가 @Friday를 멘션하면 워크플로가 실행됩니다.

하지만 단순히 첫 번째 멘션에만 응답하는 것을 넘어, 스레드에 이어지는 후속 질문처럼 기존 대화의 맥락과 관련된 요청까지 정확히 처리하려면 '대화 메모리'도 구현해야 합니다.

이를 위해 저는 Slack 메시지의 고유 식별자인 ts(타임스탬프) 또는 thread_ts(스레드 타임스탬프)를 조합해 고유한 '메모리 키(Memory Key)'를 생성하도록 구축했습니다.

이 메모리 키는 이후 모든 에이전트의 Simple Memory 노드에 sessionKey로 연결돼 Friday가 동일 스레드의 대화(맥락)를 기억하게 해줍니다. 이로써 첫 번째 멘션 다음에 이어지는 후속 질문에도 정확하게 응답할 수 있습니다.

2단계: AI 기반 의도 분류​

Friday 워크플로 2단계: AI Agent 기반 흐름 | 인포그랩 GitLab
Friday 워크플로 2단계: AI Agent 기반 흐름

2단계에서는 LLM이 사용자의 메시지를 분석해 5가지 의도 카테고리 중 하나로 분류합니다. 이 분류 결과는 다음 단계에서 어떤 전문 에이전트를 실행할지 결정하는 기준이 됩니다.

의도 분류는 n8n의 AI Agent 노드로 구현했습니다. 이 노드는 오직 의도 분류에만 집중하도록 설계한 프롬프트를 사용합니다. 추론이나 답변을 생성하지 않고, 정해진 5가지 카테고리 중 하나로 의도를 분류한 후, JSON을 출력합니다.

의도 분류 프롬프트 일부

[SYSTEM] 당신은 사용자의 요청을 5가지 의도로 분류하는 분류기입니다.

1. profile_status_change: (예: "나 밥 먹으러 갈게", "오늘부터 휴가야")
2. google_analytics_related: (예: "어제 신규 방문자 수?")
3. slack_related: (예: "지난주에 논의했던 거 찾아 줘")
4. web_general: (예: "이 링크 내용 요약해 줘")
5. general: (예: "점심 메뉴 추천해 줘")

[INPUT] `{{ $('Edit Fields').item.json.messageText }}`

[OUTPUT] `{ "intent": "...", "confidence": 0.9, "reason": "..." }`

(반드시 JSON 형식으로만 출력)

AI Agent 노드가 {"intent": "google_analytics_related", ...}와 같은 JSON을 출력하면, 다음 단계의 Switch 노드가 이 intent 값을 받아 워크플로를 5개의 브랜치로 정확하게 분기합니다. 예를 들어, google_analytics_related 의도가 분류되면 GA4 분석 에이전트가 실행됩니다.

3단계: 5개 에이전트 실행​

2단계에서 라우터를 통과한 요청은 이제 5개 에이전트 중 하나로 전달됩니다. 각 에이전트는 전용 프롬프트와 도구를 사용해 각 분야에 특화된 역할을 수행합니다. 5개 에이전트의 작동 방식을 살펴보겠습니다.

3.1. 프로필 상태 에이전트​

  • 역할: 사용자의 자연어 상태 메시지를 Slack 프로필 업데이트에 필요한 형식으로 변환합니다.
  • 작동: AI Agent 노드와 Structured Output Parser를 결합해 LLM이 자연어(”밥 먹으러 갈게”)를 분석하고, 정해진 JSON 스키마에 맞춰 이모지와 상태 메시지({"emoji": ":rice:", "status": "밥 먹는 중"})를 생성합니다. 이후 Slack(Update a user's profile) 노드를 호출해 실제 프로필을 변경합니다.

3.2. GA4 분석 에이전트​

GA4 분석 에이전트의 응답 내용 | 인포그랩 GitLab
GA4 분석 에이전트의 응답 내용

  • 역할: GA4 데이터 분석 요청을 해석하고, 결과를 읽기 쉬운 보고서로 생성합니다. 단순한 지표 조회부터 복합적인 다각도 분석까지 처리합니다.
  • 작동:
    1. 자연어를 GA4 API 매개변수로 변환합니다(날짜, 메트릭, 차원 등).
    2. ‘Get a report in Google Analytics’ 도구를 호출해 데이터를 조회합니다.
    3. 필요 시 도구를 여러 번 호출해 추가 데이터를 수집합니다.
    4. 결과를 종합해 보고서 형식으로 재구성합니다.
프롬프트 일부

[ROLE] 당신은 GA4 데이터 분석 에이전트입니다. 사용자의 자연어를 해석하여 googleAnalyticsTool을 호출하세요.
[DATE RULE] (KST 기준)
- “오늘” → Start=오늘, End=오늘
- “어제” → Start=어제, End=어제
- “이번주” → Start=이번 주 월요일, End=오늘
- “미지정 시 기본: 어제~어제” (혹은 지난 7일 등)

[METRIC/DIMENSION RULE]
- "신규 방문자/신규 유저" → newUsers 
- "전환율" → sessionConversionRate 
- "채널별" → sessionDefaultChannelGroup 
- “모호할 경우 핵심 KPI 위주(예: newUsers, sessions...)로 답하고, 추가 분해가 유용하면 간단한 Top-N 표를 함께 제공합니다.”

에이전트는 다음 두 가지 수준의 작업을 처리할 수 있습니다.

  1. 단순 요청: 사용자가 "어제 채널별 신규 방문자 수"를 요청하면, 에이전트는 이를 다음 매개변수로 변환합니다.

    • dimensions: ['sessionDefaultChannelGroup'] 
    • metrics: ['newUsers'] 
    • startDate: '2025-11-11'
    • endDate: '2025-11-11'

    이후 ’Get a report in Google Analytics’ 도구를 호출해 데이터를 조회하고, 결과를 응답합니다.

  2. 복합/추상 요청: "최근 우리 회사 공식 홈페이지의 GA4 통계를 다각화해서 분석해 줘"라고 요청하면, 에이전트는 프롬프트 규칙에 따라 다음과 같이 추론합니다.

    • 추론 1(기간): '최근'을 '지난 7일'로 해석합니다(2025-11-05 ~ 2025-11-11).
    • 추론 2(다각화): '다각화해서 분석'을 ‘핵심 KPI + Top-N 표 제공'으로 해석합니다.
    • 실행:
      1. metrics: ['totalUsers', 'newUsers', 'sessions', ...]로 도구를 호출해 핵심 KPI를 조회합니다.
      2. dimensions: ['date']를 추가해 도구를 다시 호출하고 일별 트렌드를 조회합니다.

    에이전트는 ‘Get a report in Google Analytics’ 도구를 여러 번 호출하고 결과를 종합해 '핵심 KPI 요약'과 '일별 트렌드 표'가 모두 포함된 최종 보고서를 생성합니다.

3.3. Slack 검색 에이전트​

  • 역할: 특정 주제로 내부 Slack 메시지 아카이브를 검색하고 구조화된 결과를 제공합니다.
  • 작동: AI Agent가 ’Search for messages in Slack’ 도구를 사용합니다. 검색 결과를 단순 나열이 아닌 "🔍 검색 결과 요약", "💬 관련 메시지 목록" 등 Slack에 최적화된 포맷으로 구조화해 응답합니다.

3.4. 웹 검색 에이전트​

  • 역할: URL 요약, 최신 정보 검색 등 외부 웹 정보가 필요한 요청을 처리합니다.
  • 작동: 에이전트는 Exa MCP를 사용해 웹에서 검색한 뒤, 검색 데이터를 활용해 'Slack Block Kit' JSON 형식의 답변을 생성합니다.

3.5. 일반 대화 에이전트​

  • 역할: 일상적인 대화나 간단한 질문을 처리합니다.
  • 작동: 에이전트에는 '식사 추천 모드'가 내장돼 있습니다. "점심" 키워드를 탐지하면 Current Weather Tool(HTTP Request 도구)을 호출해 현재 날씨(예: 비, 기온 10°C)를 확인하고, 날씨와 거리, 음식 특성을 고려해 내장된 목록에서 식당을 추천합니다. 그 외에는 웹 검색 없이 답변 가능한 정보를 응답합니다.

4단계: 응답 전송과 UX 최적화​

4단계에서는 에이전트의 작업 결과를 최초 요청 메시지의 스레드로 전송합니다.

Friday는 독립된 채팅 앱이 아니라, 기존 업무 도구인 Slack 내부에서 작동합니다. 따라서 단순히 응답을 보내는 것을 넘어 Slack 환경에 최적화된 자연스러운 응답 경험을 제공하는 것이 중요했습니다. 비동기적이고 채널/스레드 기반 환경에 어울리는 사용자 경험(UX)을 설계하는 것이 그 내용입니다.

이를 위해 n8n으로 다음과 같은 UX 장치를 구현했습니다.

  • 스레드 기반 응답: 모든 에이전트의 최종 응답은 Send a message 노드를 통해 최초 요청 메시지의 스레드로 전송됩니다. 이는 Slack의 채널/스레드 구조에 맞춰 채널을 깔끔하게 유지하고 대화의 맥락을 보존합니다.
  • 중간 응답 전송: GA4 분석이나 웹 검색은 5~10초 정도 시간이 걸릴 수 있습니다. 대기 시간을 관리하기 위해 Switch 노드 직후 전문 에이전트가 호출되기 전에 "Friday가 GA4 데이터를 찾고 있습니다!"와 같은 중간 응답을 먼저 보냅니다. 이로써 사용자는 ‘Friday가 작업을 시작했음’을 텍스트로 즉시 확인할 수 있습니다.
  • 이모지 반응: 웹 검색(web_general) 브랜치에서는 :loading: (⏳) 이모지 반응을 먼저 달고, 작업이 완료되면 Remove a reaction으로 이모지를 제거합니다. 사용자는 이모지 반응으로 작업 진행 상태를 시각적으로 파악할 수 있습니다.

향후 계획: ReAct 구조로 진화​

현재 Friday의 '라우터-전문가' 모델에는 다음과 같은 구조적 한계가 있습니다.

  1. 라우터가 사용자 의도를 잘못 분류하면, 엉뚱한 에이전트가 호출됩니다.
  2. "GA4에서 어제 데이터를 추출하고, 그 결과를 바탕으로 Slack에서 관련 논의를 찾아 줘"와 같은 복합적인 요청을 한 번에 처리하기 어렵습니다.

저는 이 문제를 해결하기 위해 Friday의 다음 버전에는 ReAct(Reasoning + Acting) 구조를 도입할 계획입니다. 

ReAct는 에이전트가 Thought(추론) → Action(도구 실행) → Observation(관찰) 루프를 반복하며 동적으로 문제를 해결하는 방식입니다. 이는 정적 파이프라인을 벗어나 실시간으로 계획을 수립하고, 여러 도구를 조합하도록 지원합니다.

Router vs ReAct​

다음은 두 아키텍처의 핵심 차이를 정리한 비교표입니다.

항목Router 모델ReAct 모델
구조정적 파이프라인(A → B → C)동적 루프(Thought ↔ Action ↔ Observation)
도구 접근단일 의도 → 단일 에이전트하나의 에이전트 → 모든 도구 조합 가능
복합 요청 처리어려움자연스럽게 단계 분해·시퀀스 결정
의도 오류 대응오류 발생 시 복구 어려움관찰 기반으로 경로 자체를 재계획 가능
유연성낮음매우 높음

Router 기반 Friday 한계 예시​

정적 파이프라인에서는 복합적인 요청을 온전히 다루기 어렵습니다.

  • 사용자 요청: "어제 신규 방문자 GA4 데이터와 Slack에서 진행한 관련 논의를 찾아 줘."
  • 라우터 판단: "GA4"와 "Slack" 키워드를 모두 탐지했지만, 미리 정의된 우선순위 규칙에 따라 사용자 의도를 google_analytics_related 하나로만 분류합니다.
  • 결과: GA4 분석 에이전트만 실행되고, Slack 검색 요청은 처리되지 않은 채 작업이 종료됩니다.

ReAct 적용 시 Friday 예상 방향​

ReAct 구조를 도입하면 동적 루프 방식으로 이러한 문제를 해결할 수 있습니다. ReAct 기반 에이전트는 하나의 LLM이 GA4, Slack, 웹 등 모든 도구에 접근할 수 있도록 설계됩니다. 이 에이전트는 목표를 달성할 때까지 Thought → Action → Observation → Thought 루프를 반복합니다.

아래는 ReAct 방식으로 동일한 요청을 처리하는 예시입니다.

Cycle 1 - GA4 데이터 조회​

  • Thought: 사용자의 요청을 두 단계로 분해합니다.

    1. GA4 신규 방문자 조회

    2. Slack에서 관련 대화 검색

      먼저 GA4 조회를 실행하기로 계획합니다.

  • Action: google_analytics(metric="newUsers", date="yesterday")
  • Observation: GA4에서 "500 new users"를 수신합니다.

Cycle 2 - Slack 검색 수행​

  • Thought: 1차 결과(500 users)를 기반으로 Slack 검색을 실행하기로 계획합니다.
  • Action: slack_search(query="신규 방문자 500명 어제")
  • Observation: "3개 메시지 찾음..."을 수신합니다.

Cycle 3 - 최종 응답 생성​

  • Thought: 모든 정보가 수집됐음을 확인합니다. Slack에 결과를 조합해 최종 응답을 보내도록 계획합니다.
  • Action: 조사 결과를 요약한 최종 메시지를 Slack에 전송합니다.

이처럼 ReAct 구조를 도입한 Friday는 복합적인 요청을 스스로 분해하고 단계별로 해결할 수 있습니다. 아울러 도구 호출 순서를 동적으로 계획하며, 멀티 스텝 자동화도 구현할 수 있습니다. 이로써 Friday는 단일 의도로 분류된 작업만 처리하는 정적 봇을 넘어, 여러 도구를 오가며 복잡한 문제를 해결하는 진정한 에이전트로 진화할 수 있습니다.

맺음말​

지금까지 n8n으로 '라우터-전문가' 모델 기반의 멀티 에이전트 시스템을 구현하는 과정을 살펴봤습니다. 이 아키텍처는 사용자의 자연어 입력을 LLM으로 분석하고, 그 결과에 따라 GA4, Slack 등 다양한 도구를 다루는 5개의 전문 에이전트로 작업을 분배하는 구조입니다. 단일 요청을 처리하는 데 효과적인 방식입니다.

그러나 더 복잡한 업무 자동화를 구현하려면 'ReAct' 구조가 필요합니다. ReAct를 도입하면 에이전트가 회사의 내부 문서나 API 명세 등으로 구성된 지식 베이스를 기반으로 스스로 추론하고, 여러 도구를 실행하며, 복잡한 업무를 자동으로 수행할 수 있습니다.

예를 들어, '어제 GA4 데이터를 요약해 팀 리더에게 DM으로 보고해 줘'와 같은 복합적인 요청도 처리할 수 있을 것입니다.

ReAct 기반 에이전트는 이 요청을 '요청 분석 → 다중 도구 실행 → 결과 취합 → 최종 보고' 단계로 자동 분해하고, GA4 데이터 조회 → Slack 사용자 식별 → DM 전송까지 전체 프로세스를 자율적으로 수행할 거로 예상됩니다. ReAct 구조를 도입한 Friday의 미래 모습이죠. 앞으로 Friday가 더 복잡한 업무를 손쉽게 자동화하는 완전 자율형 멀티 에이전트로 발전할 모습을 기대해 주세요.

참고 자료​

  1. Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, Yuan Cao, “ReAct: Synergizing Reasoning and Acting in Language Models”, ICLR 2023, 2022, https://arxiv.org/pdf/2210.03629
  2. “Block Kit”, Slack, https://docs.slack.dev/block-kit/
  3. n8n 공식 홈페이지, https://n8n.io/

n8n으로 비즈니스 워크플로를 완벽히 자동화하고 싶으신가요? 지금 인포그랩에 문의하세요!