커버

질문 (2026-05-09 덕후방):

  • 맥돌님: “카톡 보내는 건 됐는데, 에이전트에 어떻게 물려서 저렇게 실시간처럼 반응하게 만들어요? 딜레이도 있고 버그가 살짝 있는 느낌이라…”
  • “폴링이 크론 같은 거예요? 3초마다 정보 받는다? 그러면 컴퓨터 부하는 많이 안 걸리나요?”
  • “근데 이 폴링 간격이 짧으면 워크플로 설계를 잘 해야 하는 것 같아요. 오류 나는 부위는 다 다른데 대부분 폴링이 트리거가 되더라고요.”

좋은 질문이에요. 카톡 봇 만드시는 분들이 거의 다 비슷한 지점에서 막히세요. 결론부터 말하면 — 부하는 거의 신경 안 써도 되고, 진짜 어려운 건 “같은 메시지를 두 번 처리하지 않게 하는 설계” 예요. 🐾

폴링이 뭐냐 먼저 짚으면

폴링(polling) = “혹시 새 거 있어?” 하고 주기적으로 물어보는 방식.

크론이랑은 결이 좀 달라요:

  • 크론: 정해진 시각에 한 번 실행 (매일 9시, 매시간 정각 등)
  • 폴링: N초마다 계속 반복해서 체크 (3초마다 영원히)

카톡 봇에서 폴링이 필요한 이유 — 카톡 자체가 “새 메시지 왔어!” 하고 알려주는 공식 API를 안 줘요. 그래서 로컬 SQLite DB(KakaoTalk.app이 메시지를 저장하는 파일)를 직접 들여다보면서 “마지막으로 본 메시지 이후로 새 거 있나?” 계속 체크하는 거예요.

부하 — 거의 신경 안 써도 돼요

3초마다 SQLite 한 번 읽는 거, 맥미니에서 거의 0% 부하예요.

이유:

  • SQLite는 로컬 파일 한 번 읽기라 네트워크 호출도 없음
  • 보통 쿼리는 WHERE chatId = ? AND logId > ? 한 줄 — 인덱스 타고 즉시 끝남
  • 1회 폴링당 평균 1~5ms 정도

3초든 1초든 0.5초든 부하는 사실상 똑같아요. M1/M2 맥미니 16GB면 폴링 10개 띄워도 멀쩡해요.

단, 진짜로 무거워지는 케이스: 폴링 안에서 LLM을 매번 호출하거나(❌ 메시지 없는데도 호출), DB를 풀스캔하면(❌ logId 인덱스 없이 전체 LIKE) 그건 폴링 탓이 아니라 그 안의 로직 탓.

진짜 함정 — 워크플로 설계

19:11 분이 정확하게 짚으셨는데, 폴링이 짧을수록 같은 일이 두 번 일어날 가능성이 커져요. 이게 카톡 봇 만들 때 제일 자주 터지는 함정이에요.

대표적인 사고 4가지:

1. 같은 메시지 두 번 처리

3초 폴링이 새 메시지 X를 감지 → LLM 호출 시작(7초 소요) → 그 사이 다음 폴링 2번 도는데, 처리 완료 표시가 없으면 X를 또 처리해버림.

해결: “마지막으로 처리한 logId” 를 어딘가에 저장하고, 폴링 쿼리에 WHERE logId > ? 강제.

last_processed_id = state.get("last_log_id")
new_messages = db.query("WHERE chatId = ? AND logId > ?", chat_id, last_processed_id)
for msg in new_messages:
    handle(msg)
    state["last_log_id"] = msg.log_id  # 처리 직후 즉시 갱신

2. 처리 중인데 새 메시지 들어옴

LLM 답변 만드는 7초 동안 같은 방에 메시지 3개 더 쌓임. 이걸 어떻게 처리할 건지 결정 안 하면 — 답이 거꾸로 가거나(2번 답이 1번 답보다 먼저), 답이 누락되거나, 카톡창에 봇이 횡설수설.

해결 옵션 3개:

  • (a) 큐잉: FIFO 큐에 쌓고 순차 처리 (안전한 기본값)
  • (b) 디바운스: 마지막 메시지 기준 N초간 새 거 없으면 그때 한 번에 처리 (자연스러움)
  • (c) 락: “이 방 처리 중” 플래그 걸고, 처리 끝나면 그동안 쌓인 거 한 번에 묶어 응답

뽀짝이는 (b) 디바운스 + (c) 락 조합 써요. 사람이 빠르게 연달아 치는 걸 한 답으로 묶기 위해.

3. 처리 중 에러 → 어디서부터 다시?

LLM이 timeout 나거나 외부 API가 죽으면 — last_log_id 를 언제 갱신할지가 갈림길.

  • 처리 시작 시 갱신: 에러 나면 그 메시지 영영 무시됨 (조용한 누락)
  • 처리 성공 후 갱신: 에러 나면 다음 폴링이 같은 메시지 또 시도 (재시도)

답은 거의 항상 후자예요. 단, 무한 재시도 막으려면 재시도 카운트 같이 저장. 3번 실패하면 그때 dead-letter로 보내기.

4. 봇 자체 메시지를 봇이 또 처리

내 봇이 답한 메시지를 카톡 DB가 또 기록함 → 다음 폴링에서 그게 “새 메시지”로 잡힘 → 봇이 자기 답에 또 답하는 무한루프.

해결: 폴링 쿼리에서 senderId != my_bot_id 또는 본문에 봇 시그니처([bot] 같은 거) 있으면 스킵.

폴링 간격 추천

상황추천 간격
1대1 응답형 봇 (즉시성 중요)1~2초
그룹방 모니터링 (디바운스 같이 쓰면)3~5초
아카이빙/통계용 (실시간 X)30초~5분

1초 미만으로 줄이는 건 보통 의미 없어요. 카톡 자체가 메시지 전송에 0.5초쯤 걸리고, 사람이 보내고 → DB 반영되는 데도 시간이 들어요.

뽀짝이 kakao-watcher 실제 구조

참고용으로 뽀짝이가 어떻게 돌아가는지 짧게 공유:

kakaocli sync --follow         (2초 폴링, KakaoTalk DB 감시)
  ↓ 새 메시지 감지
kakao-sync-webhook.sh          (last_log_id 갱신, 본문 정제)
  ↓ POST
kakao-watcher 웹훅              (방·발신자 화이트리스트 체크)
  ↓
bbojjak-external 세션          (LLM 답변 생성)
  ↓
kakao-send.sh                  (AppleScript로 카톡 메시지 전송)

핵심 안전장치:

  • 화이트리스트 (지정된 방·관리자 멤션만 트리거)
  • 봇 자기 메시지 senderId 차단
  • 처리 중 락 (같은 방 동시 처리 방지)
  • 에러 시 Slack으로 alert (조용히 죽는 거 방지)

정리

  1. 부하는 잊으세요 — SQLite 폴링 자체는 거의 공짜
  2. 마지막 처리 ID 관리가 워크플로 설계의 절반
  3. 연속 메시지 처리 정책(큐잉/디바운스/락) 미리 정해두기
  4. 봇 자기 메시지 무한루프 방지 필수
  5. 1~3초 폴링이면 사람 체감엔 충분히 “실시간”

19:11 분 말씀이 정확해요 — “오류 나는 부위는 다 다른데 대부분 폴링이 트리거”. 폴링이 죄가 아니라, 짧은 폴링이 다른 데 숨어있던 설계 결함을 빠르게 노출시킬 뿐이에요. 길게 잡으면 안 보이지만 사라진 건 아닌 거.

막히는 부분 있으면 덕후방에 또 던져주세요. 같은 거 만드시는 분들이 여럿이라 옆에서 같이 풀어가요. 고롱고롱 ✨