Insight Retreat
AI 자동화 봇 만들기 - 슬랙·디스코드·카카오톡 봇에 Claude·GPT 연동
AI·테크

AI 자동화 봇 만들기 - 슬랙·디스코드·카카오톡 봇에 Claude·GPT 연동

슬랙, 디스코드, 카카오톡 봇에 Claude나 GPT를 붙여 업무를 자동화하는 방법을 예시 시나리오와 함께 소개합니다. 에이전트 패턴 적용도 다룹니다.

Insight Retreat·
#AI 봇#자동화#Claude API#GPT API#메신저 봇#바이브코딩#Vercel Functions#Railway#에이전트 패턴

매일 쓰는 메신저 안에서 자연어로 업무를 처리할 수 있다면 일하는 방식이 꽤 달라집니다. 이 글에서는 슬랙과 디스코드 등에 '말하면 일하는 봇'을 붙이는 방법을, 코드 자체보다 구축 과정과 꼭 필요한 구성 요소 중심으로 정리합니다.

바쁜 당신을 위한 30초 요약

AI 자동화 봇은 메신저에서 LLM API를 호출해 자연어로 업무를 처리하는 작은 시스템입니다. 질문에 답하는 수준을 넘어 노션, 구글 캘린더, GitHub Issues에 실제로 기록하거나 수정하는 일까지 합니다. 봇을 만드는 방식은 크게 두 갈래입니다. 하나는 플랫폼이 제공하는 봇 프레임워크(또는 MCP 같은 표준 연동 방식)를 따르는 것이고, 다른 하나는 API를 직접 호출하는 것입니다. 후자에서는 LLM에게 '도구 사용 능력'을 주는 에이전트 패턴까지 확장할 수 있습니다. Vercel Functions나 Railway 같은 서버리스 플랫폼을 쓰면 무료 계층에서도 시작할 수 있습니다.

왜 지금, 메신저 AI 봇이 주목받을까요?

예전 봇은 정해진 명령어만 알아들었습니다. 그런데 LLM이 들어오는 순간, "이번 주 마케팅 회의 잡아줘", "프로젝트 아이디어를 노션에 정리해 줘", "오늘 올라온 버그 이슈를 요약해서 올려줘"처럼 사람이 말하는 그대로 받아들입니다. 자연어를 문맥까지 이해하고 추론할 수 있게 되면서 봇이 스스로 행동하는 범위가 넓어진 셈입니다.

이 흐름을 지지한 것은 서버리스 컴퓨팅의 표준화였습니다. 전용 서버 없이 Vercel Functions나 Railway에 코드를 올리면 봇이 24시간 동작하고, 기업은 물론 개인도 자신만의 AI 비서를 만들어 운영할 수 있게 되었습니다. 인프라 관리에 시간을 쓰고 싶지 않다면 로컬보다 이런 플랫폼에 올리는 편이 효율적입니다.

표: 메신저 AI 봇 핵심 기술 및 활용 분야

항목내용
핵심 기술대규모 언어 모델(LLM) 연동 (Claude API, GPT API)
주요 플랫폼슬랙(Slack), 디스코드(Discord), 카카오톡(KakaoTalk)
자동화 대상노션(Notion), 구글 캘린더(Google Calendar), GitHub Issues 등
배포 환경Vercel Functions, Railway (무료 플랜 활용 가능)
주요 활용회의 일정 관리, 문서 요약, 프로젝트 관리, 고객 응대, 정보 검색

내 손으로 만드는 AI 봇: 실전 제작 가이드

봇을 만드는 큰 흐름은 이렇게 정리됩니다. 메신저 이벤트(메시지 수신 등)를 감지하고 → 이를 LLM에 전달하고 → 응답을 다시 채널로 돌려보낸다. 방식의 차이는 그 중간을 플랫폼 라이브러리로 두느냐, 직접 API를 호출하느냐뿐입니다.

봇 프로젝트를 위해 먼저 할 일

각 플랫폼에서 봇을 생성하고 API 토큰 또는 웹훅을 등록합니다. 슬랙은 Slack API 사이트에서, 디스코드는 Developer Portal에서, 카카오톡은 카카오 개발자 콘솔에서 봇을 만들어 채널이나 친구 목록에 초대하는 방식입니다. 이때 봇이 메시지를 읽고 쓸 권한(스코프)을 설정하는 것을 빼먹으면 봇이 제대로 작동하지 않으므로, 초기 단계에서 꼭 확인해야 합니다.

LLM API 붙이기

토큰을 발급받았으면 코드에서 해당 LLM을 호출합니다. 아래는 GPT를 부르는 가장 짧은 예시인데, Claude도 anthropic 라이브러리로 거의 동일한 구조입니다.

# 예시: 간단한 GPT API 호출 (Python)
import openai

# openai.api_key = "YOUR_GPT_API_KEY" # 실제 키는 환경 변수로 관리 권장

def get_gpt_response(prompt_text):
    try:
        response = openai.chat.completions.create(
            model="gpt-4o", # 또는 gpt-3.5-turbo 등
            messages=[
                {"role": "system", "content": "당신은 유능한 AI 비서입니다."},
                {"role": "user", "content": prompt_text}
            ],
            max_tokens=500,
            temperature=0.7
        )
        return response.choices[0].message.content
    except Exception as e:
        return f"GPT API 호출 오류: {e}"

# 사용 예시:
# user_message = "오늘 할 일 목록을 작성해줘."
# bot_reply = get_gpt_response(user_message)
# print(bot_reply)

API 키를 코드에 직접 넣는 것은 처음부터 피해야 합니다. 설정 방식을 복잡하게 바꾸기보다, 표준 관행대로 값을 환경 변수에 넣고 코드에서 읽어 오는 방식을 지키는 것이 안전합니다.

외부 서비스 연동 (노션, 구글 캘린더, GitHub Issues)

봇의 진가는 여기부터입니다. "노션에 주간 보고서 초안을 작성해줘"라는 지시를 받으면 봇은 LLM으로 내용을 만들고, 노션 API에 그 페이지를 생성하는 식입니다. 구글 캘린더도 같은 원리로 일정을 만들고, GitHub에서는 이슈를 생성하거나 정리하는 일까지 맡길 수 있습니다.

다만 이런 연결은 생각보다 취약합니다. 외부 API가 스키마를 조금만 바꿔도 봇이 곧바로 영향을 받으므로, 응답 형식이 바뀔 수 있다는 점을 감안하고 오류가 날 것을 전제로 예외 처리를 코드에 넣어 두면 유지보수 부담이 줄어듭니다.

에이전트 패턴 설계: 봇에게 생각하는 힘을 주다

단순히 지시 문장에 응답하는 데 그치지 않고, 목표를 받으면 봇이 중간 단계를 스스로 추론하는 에이전트 패턴도 구현할 수 있습니다. "이번 주 팀 회의 일정을 조율하고 노션에 정리해 줘"라고 했을 때, 봇은 팀원 캘린더를 확인하고 빈 시간을 찾고, 노션 페이지를 만들고, 결과 보고까지 이어집니다. 내부에서는 계획 → 도구 선택 → 실행 → 결과 분석 → 다음 행동 순서로 돌아갑니다.

이를 구현하는 방법은 크게 복잡하지 않습니다. LLM에 '어떤 도구(함수)를 호출하면 되는지'와 '도구 사용 규칙'을 프롬프트나 함수 정의로 알려주는 것입니다. 여기서 요령은 도구 이름과 설명을 좀 더 자연어에 가깝게 지어 주는 것입니다. "캘린더 조회"가 아니라 "특정 기간의 팀원 캘린더에서 빈 일정 검색"처럼 도구가 할 수 있는 범위를 상세히 알려 주면, 봇이 다음 행동을 더 정확하게 고르는 경향이 있습니다.

배포: Vercel Functions와 Railway 무료 플랜 활용

봇은 서버리스 플랫폼에 올려 두면 24시간 동작합니다. Vercel Functions는 Node.js·Python을 지원하며, GitHub와 연결해 코드를 푸시하면 자동 배포됩니다. 배포 후에는 메신저의 웹훅이 Vercel 엔드포인트를 가리키도록 설정하면 됩니다. Railway는 Docker 컨테이너 기반이라 자유도가 더 높지만, 간단한 봇이라면 Vercel이 설정하기 수월합니다.

진입 장벽을 낮춰 주는 것이 '무료 플랜'입니다. 외부 사용자에게 제공하는 서비스가 아니라 내 업무를 위한 도구라면, 무료 한도 안에서 비용 없이 운영할 수도 있습니다. 다만 대부분 호출 수 기준이라 봇이 많은 사용자에게 오가는 실서비스로 커지면 아무래도 유료 전환을 검토하게 됩니다.

자주 부딪히는 문제와 해결

AI 봇 개발에서 어려운 부분은 코드 작성보다 사용자 의도를 해석하는 일입니다. 구글 캘린더 봇을 예로 들면, "다음 주 화요일 오후 2시에 팀 회의 잡아줘"처럼 조건이 명확한 지시는 잘 처리하더라도, "팀원 전원이 참석 가능하게 잡아줘" 같은 문장에는 제대로 대처하지 못할 수 있습니다. '팀원 전체'의 참석 가능 여부를 확인하려면 어떤 API를 어떤 순서로 호출해야 하는지 프롬프트에 명시되어 있지 않기 때문입니다. 이런 실패를 줄이려면 도구 설명을 상세하게 쓰는 것이 기본입니다.

아래는 봇을 업무에 적용하는 두 가지 예시 시나리오입니다.

💻 예시 시나리오 1: 주간 보고서 생성 자동화

매주 성과 리포트의 숫자와 텍스트를 손으로 정리하는 업무를 가정해 보겠습니다. Vercel Functions에 GPT를 얹고, 슬랙 채널에서 "주간 보고서 써줘"라고 하면 스프레드시트의 원자료를 가져와 정해진 서식으로 초안을 만들고, 노션 페이지로 저장하도록 구성할 수 있습니다. 이렇게 하면 리포트 초안 작성에 드는 시간을 크게 줄일 수 있습니다. 다만 결과물을 꼼꼼히 검토하는 과정은 여전히 필요합니다.

💻 예시 시나리오 2: GitHub 이슈 관리 알림

협업 중인 저장소에 올라오는 이슈를 놓치지 않으려면 매번 GitHub을 열어 봐야 합니다. 디스코드 봇에 Claude를 연결하고 웹훅으로 새 이슈를 받아, 요약과 함께 어떤 영역(예: 백엔드 회귀, 디자인 리뷰)에 해당하는지 판단해 특정 채널에 올려 주는 봇을 만들 수 있습니다. 이렇게 분류가 자동화되면 필요한 이슈만 눈에 들어와 확인 부담이 줄어듭니다. LLM의 분류가 항상 정확하지는 않으므로 가끔 결과를 점검해야 하지만, 알림 봇에 LLM의 판단을 얹는 방식은 충분히 실용적입니다.

흔한 오해와 진실

흔히 '봇 만드는 것은 복잡한 코딩 지식이 필수'라는 인상이 있지만, 최근에는 로우코드·노코드 도구나 특정 API를 결합하면 비개발자도 간단한 봇을 만들 수 있습니다. 중요한 것은 어떤 문제를 해결하고 싶은지를 규정하는 일입니다.

'AI 봇은 개인이 쓰기에 너무 비싸다'는 인식도 꼭 맞는 것은 아닙니다. Vercel Functions나 Railway 무료 플랜으로 시작하고, Claude·GPT API도 사용량 단위로 비교적 저렴하게 쓸 수 있어 개인 실험 수준이라면 충분히 감당할 만합니다. 물론 호출량이 크게 늘어난다면 예산 검토가 필요합니다.

오늘 바로 시도해볼 요소

직접 붙여볼 수 있는 최소한의 재료를 세 가지로 나눠 보면 이렇습니다. 한 플랫폼(슬랙이나 디스코드 등)에서 봇을 만들어 채널에 초대해서 토큰이 발급되는지 확인하는 것. 파이썬이나 Node.js로 LLM API에 한 번이라도 호출해 메시지 응답을 받아보는 것. 마지막으로 평소 반복하는 업무 하나를 골라, 그 업무에서 쓰는 외부 서비스(노션, 캘린더, 이슈 등)와 연동되는 봇의 흐름을 그려 보는 것입니다. 처음에는 이것만으로도 봇과 에이전트의 구성 요소가 잘 보입니다.

자주 묻는 질문 (FAQ)

AI 봇 개발에 꼭 프로그래밍 언어를 알아야 하나요?

간단한 봇은 로우코드·노코드 도구로도 만들 수 있습니다. 다만 LLM API와 외부 서비스를 유연하게 연결하려면 파이썬이나 자바스크립트 기초가 있는 편이 편리합니다. 특히 API 호출과 JSON 응답 처리에 익숙해지면 만들 수 있는 봇의 범위가 크게 넓어집니다.

Claude API와 GPT API 중 무엇을 선택하는 것이 좋을까요?

두 API 모두 장단점이 있어 한쪽이 절대적으로 낫다고 보기는 어렵습니다. GPT는 모델 선택지가 넓고, Claude는 문서를 차분하게 정리하는 응답 스타일로 선호되기도 합니다. 정답은 프로젝트의 컨텍스트 길이와 예산, 우선순위에 따라 달라집니다. 둘 다 소액으로 시험해 본 뒤 하나로 정하는 방법이 무난합니다.

에이전트 패턴은 비개발자도 구현할 수 있나요?

도구 호출을 프롬프트로 구성하는 작업이라 최소한의 개념은 알아야 합니다. LangChain 같은 프레임워크가 진입 장벽을 낮춰 준 덕분에, 예제 골격을 가져와 조합하면 비개발자도 도전해 볼 수 있습니다. 다만 에이전트가 임의로 행동하지 못하도록 권한 범위를 한정하는 설계는 개발자의 역할로 남습니다.

Vercel Functions나 Railway의 무료 플랜으로 충분한가요?

개인 실험이나 소규모 팀 용도라면 대체로 충분합니다. 단, 이벤트 호출이 늘어나거나 LLM 요청이 쉬지 않고 이어지면 한계에 닿을 수 있고, 그 기점은 플랫폼이 정한 무료 한도를 관찰하면서 판단하는 것이 현실적입니다.

봇이 스스로 판단하며 작업할 때 발생하는 문제는 무엇인가요?

대표적인 문제는 환각과 판단 실수입니다. 없는 일정을 지어내거나 이후 작업 흐름을 잘못 판단할 수 있으므로, 중요한 작업 전에는 사용자 확인을 거치도록 설계하는 것이 좋습니다. 명확한 사용 규칙과 권한 범위, 오류 처리, 검증 절차를 함께 두는 것이 기본입니다.


📚 참고 문헌 및 공식 레퍼런스 (References)

  • Slack API Documentation, 『Bolt Framework for JavaScript & Event Subscriptions』
  • Discord Developer Portal, 『Interactions & Slash Command Gateway Specifications』

🔮 관련 인사이트 & 추천 가이드

글쓴이 Insight Retreat

IT 업계에서 개발·PM·컨설팅 역할을 했고, 은퇴 후 현재는 헤드헌터로 일하고 있습니다. 사주명리와 심리학은 오래 관심을 두고 공부해 온 분야입니다.

IT 현장 경험과 AI 개발 도구를 직접 써 보며 정리한 글입니다.

※ 코드와 설정은 작성 시점 기준이며 환경에 따라 다를 수 있으니 테스트 환경에서 먼저 확인한 뒤 적용하세요. 운영자 소개와 글 작성 방식