소개
이 글은 AI가 90% 작성한 글 입니다.
지난번 글에서 n8n + 메신저봇 연동 중 좀비 스레드 문제로 실패했던 경험을 공유했습니다.
10시 10분에 16개 스레드가 동시 생성되어 같은 메시지가 6-7번 중복 발송되는 문제가 있었고, 아무리 생각해도 폴링 방식 자체가 비효율적이라고 생각이 되어서 좋은 방법을 계속 생각해봤습니다.
이번에 폴링 방식을 완전히 버리고 메신저봇 내에 소켓 서버를 넣는 방식으로 아키텍처를 변경하여 문제를 해결했습니다. 결과적으로 좀비 스레드 없이 안정적으로 n8n에서 카카오톡 자동 발송이 가능해졌습니다.
진행 방법
먼저, 왜 이렇게 복잡한 구조가 필요한가?
메신저봇의 근본적인 한계 때문입니다.
메신저봇은 기본적으로 "메시지가 와야만 반응"합니다.
보통 소통을 하거나, 키워드 웹훅 방식으로는 가능하지만 단순하게 스케쥴링 형태로 원하는 시간대에 보낼 수 없는 문제를 가지고 있습니다.
외부에서 직접 메신저봇에 명령을 보낼 수 없음
정해진 시간에 자동으로 메시지를 보내는 기능 없음
그래서 메신저봇을 서버로 만들어야 합니다.
폴링 vs 소켓 서버, 뭐가 다른가?
조금 이해가 안가시는 분들을 위해 용어 설명부터 하자면 다음과 같습니다.
폴링 방식 (이전 시도, 실패)
메신저봇이 "할 일 있어요?" 하고 1분마다 계속 물어보는 방식입니다.
식당에서 "제 음식 나왔어요?" 매 10초마다 물어보는 것과 같습니다.
문제: 계속 물어보다가 스레드가 쌓여서 좀비처럼 살아남음
소켓 서버 방식 (이번 해결책)
메신저봇이 전화를 켜놓고 대기합니다.
전화 오면 바로 받아서 처리합니다. 물어볼 필요 없이 연락 오면 그때 움직입니다.
필요한 환경
제 환경 기준으로 이야기하면 다음과 같습니다.
HW
PC(Mac-mini, 추후 미니PC 구매 후 이관 예정) : FastAPI 서버 실행, n8n Docker 호스트
Android 폰(갤럭시노트10) : 메신저봇 앱 실행, 카카오톡 설치
**같은 WiFi** : Mac과 폰이 같은 네트워크에 있어야 함! |
SW
Docker : n8n 컨테이너 실행
셀프호스팅 방식 n8n
Python : 3.13+ , FastAPI 서버 |
메신저봇R : 0.7.39a+ | 카톡 자동 응답 앱 (API2) |
카카오톡
전체 아키텍처
클로드코드 opus 4.5가 가이드를 주었습니다. $200 쓰는데 폴링방식 대신 이 방식을 제안해주었습니다.
왜 FastAPI가 중간에 필요한가?
Docker 네트워크 격리 때문입니다.
연결 시도
결과
n8n(Docker) → 폰 IP 직접
❌ 네트워크 격리로 연결 불가
n8n(Docker) → Mac(host.docker.internal)
✅ 가능
Mac → 폰 IP (같은 WiFi)
✅ 가능
결론: n8n → FastAPI(Mac) → 메신저봇(폰) 경로로 우회해야 함
FastAPI는 Docker와 폰 사이의 다리 역할을 합니다.
각 구성요소의 역할
1. FastAPI 서버 (Mac에서 실행)
포트 9000에서 대기
n8n에서 POST 요청을 받으면 폰의 4006 포트로 소켓 연결
JSON 형태로 방 이름과 메시지를 전달
2. 메신저봇 (Android)
포트 4006에서 소켓 서버로 대기
JSON을 받아서 파싱
bot.send() 함수로 카카오톡 메시지 전송
3. n8n 워크플로우
Schedule Trigger로 원하는 시간에 실행
Google Sheets에서 데이터 읽기 (저번 글에서 만들었던 내용을 그냥 그대로 내가 원하는 시간에 읽기만 해주면 끝!)
HTTP Request 노드로 FastAPI에 POST 요청
여러 방에 동시 전송 가능 (send-multi 엔드포인트)
아래 이미지에서 1번 엔드포인트가 fastapi 가 받는 부분입니다.
데이터 흐름 요약
이 시퀀스 다이어그램 보시면 전체적인 이해가 되실 겁니다.
사용법 체크리스트
단계
확인
Mac과 폰이 같은 WiFi
⬜
FastAPI 서버 실행 중 (포트 9000)
⬜
n8n Docker 실행 중
⬜
메신저봇 활성화
⬜
카톡에서 !셔틀시작 명령 실행
⬜
결과와 배운 점
시행착오 기록
시도
결과
교훈
폴링 방식
❌ 좀비 스레드 폭발
계속 물어보는 방식은 스레드 관리가 어려움
n8n → 폰 직접 연결
❌ Docker 네트워크 격리
Docker는 호스트 네트워크와 분리됨
Api.replyRoom() 사용
❌ API2에서 미작동
bot.send() 사용해야 함
자동 서버 시작
❌ Socket is closed 에러
수동 시작이 더 안정적
한번 메신저봇 while 문이 잘못 돌아서 아래와 같은 대참사 메시지를 400개 이상 받았습니다... 메신저봇을 꺼도 계속 메시지가 보내져서 수명이 단축되는 경험을 했습니다.
그래서 메신저봇 코드 컴파일 하고나서 명령어를 통해서 소켓 서버를 on/off 할 수 있도록 반영하였습니다. 아래와 같이 제 메인 1대1 방에서 이를 조절하고 로그도 확인하게 했습니다.
카톡 봇 방에도 잘 메시지가 가는 것을 확인했습니다.
핵심 교훈
"아키텍처를 바꾸는 것이 디버깅보다 빠를 때가 있다"
폴링 방식의 좀비 스레드를 잡으려고 스레드 넘버링, 파일 기반 추적 등 여러 방법을 시도했지만 실패했습니다.
결국 "물어보는 방식"을 "기다리는 방식"으로 완전히 바꾸니 문제가 깔끔하게 해결되었습니다.
기존 방식과 비교
구분
폴링 (기존)
소켓 서버 (새로운)
방식
메신저봇이 계속 물어봄
메신저봇이 대기하다 받음
안정성
좀비 스레드 발생
안정적
복잡도
단순하지만 불안정
구조는 복잡하지만 안정적
앞으로의 계획
현재는 Mac이 켜져 있어야 작동함
추후 미니PC 구매 후 이관 예정. 24시간 서버 구축 예정
도움 받은 글 (옵션)
클로드코드 $200 Max Plan은 신이야
