📱 커뮤니티 카카오톡 데이터 24/7 수집 시스템 구축 여정

ALT

한 여자가 전화기를 앞에 두고 책상에 앉아 있다

📌 프로젝트 개요

목표: 카카오톡 커뮤니티(130명)의 메시지를 24/7 자동 수집하고 DB에 저장하는 시스템 구축

주요 기능 📱

• 실시간 메시지 수집 (메신저봇R - 잇다봇)

• 주기적 배치 수집 (카카오톡 내보내기 파싱)

• 클라우드 서버 운영 (DigitalOcean)

• 자동 백업 시스템

기술 스택 ⚒️

카카오톡 → 메신저봇R (JavaScript) → FastAPI (Python) → SQLite
                                    ↓
                        DigitalOcean 서버 (24/7)

• 프론트엔드: 메신저봇R (Rhino JavaScript 엔진)

• 백엔드: FastAPI + Uvicorn

• 데이터베이스: SQLite (7개 테이블, 3개 트리거)

• 배포: DigitalOcean Ubuntu + Systemd

• 자동화: Bash Shell Scripts

<현재 데이터베이스 구조 (chat_collector.db (180KB)>

지금: v2.1 (6개 테이블)
     ├─ rooms
     ├─ participants  
     ├─ messages ⭐ (핵심)
     ├─ bot_actions
     ├─ statistics_cache
     └─ keyword_trends

나중: product_mentions 추가 (필요시)
     └─ ALTER TABLE 없이 추가만!

🎯 핵심 성과

정량적 성과

✅ 수집 정상 작동: 시스템 구축 완료 3일 만에 839개 메시지 수집!

✅ 다양한 참여자: 46명의 다양한 멤버들 메시지 수집됨

✅ 실시간 반영: 방금 전 메시지(14:53)까지 수집

✅ 안정적 수집 상태: 24/7 서버 가동률 달성

정성적 성과

• 완전 자동화된 데이터 파이프라인 구축

• 중복 방지 및 백업 시스템 완비

• "가정을 의심하는" 디버깅 습관 체득

👍 이젠 가능해진 분석들

와우! 이젠 이런 데이터도 손쉽게 뽑을 수 있음 👍

1. 참여자별 메시지 수 (상위 10명) 💬

2. 인기 상품 검색 (샵검색 기능) 🛒

커뮤니티에서 관심 있는 제품들:

• 그로미미 빨대컵 - 빨대컵

• 에디슨 자기주도컵 - 음료컵

• 마이아 두유제조기 - 이유식

• 트루쿡 4구 - 이유식

• 리틀타익스 미끄럼틀 - 장난감

• 두두 그림자 극장 - 장난감

• 디즈니캐슬레고 - 장난감

• 코코지하우스 - 장난감

발견: 이유식 도구 + 빨대컵 관심 높음!

3. 자주 묻는 질문 유형 ❓

이유식 관련:
- "8시 이유식 150ml...우유를 한 번 빼고 이유식 양을 늘려볼까요?"
- "밥솥이유식하게되면 한칸에 세끼양 큐브를 넣은게 맞나요?"
- "믹서기도 있어야되고 쵸퍼도 있어야되고 그런거죠?!"
- "닌자쵸퍼가 유명하던데 플라스틱 이슈가 있더라구요?!! 뭐 쓰세요?"

육아용품:
- "9갤 아기 외출할때 뭐입혀야할까요?"
- "다들 혹시 이번에 아기 패딩 구매하셨나요?"
- "다들 용량은 270짜리 큰거 쓰시죠?!"

수유/우유:
- "막수 돌 지나면 빠르게 없애야하나요?"
- "막수 계속 이어가도 괜찮아요?"

4. 참여자 유형 분석 👥

발견: 유주맘(운영자)은 가장 긴 메시지 작성 → 상세한 답변 제공하는 역할

이렇게 데이터 파이프라인이 완성되니, 이 외에도 수많은 분석이 가능해졌어요! 🎉 👍

1. 요일/시간대별 활동: 가장 활발한 시점 분석 ("이 커뮤니티는 오후 1~5시에 가장 활발해요!")

2. 인기 상품 리스트: 샵검색 데이터로 "이 달의 인기 육아용품" 정리

3. FAQ 문서: 자주 묻는 질문 + 답변 정리해서 신규 멤버에게 제공

12월 1년 데이터로 확장하면

1. 월별 트렌드: "3월엔 이유식, 6월엔 빨대컵, 12월엔 패딩"

2. 핵심 멤버 분석: 답변을 많이 해주는 "도움이 되는 멤버" 식별

3. 시즌별 FAQ: 계절/월령별 자주 묻는 질문 자동 분류
   

하지만, 이를 위한 여정이 쉽진 않았습니다...🥲

긴 프로젝트 여정 속 여러 시행 착오들이 있었지만,
다음 세 가지 순간들이 가장 기억에 남습니다.

🗺️ 주요 전환점 3가지

1️⃣ 첫 번째 전환점: "완벽한 코드보다 작동하는 시스템"

초기 계획: 메신저봇R로 완벽한 실시간 수집 시스템 구축

발견한 문제: 오픈채팅방에서 발신자 정보 수집 이슈 의심

대안 마련:

• 실시간 수집 (메신저봇R) + 주기적 배치 (카카오톡 내보내기)

• 하이브리드 아키텍처로 설계 변경

교훈:

"완벽한 단일 솔루션이 없을 때는 여러 방법을 조합하자!"

실생활 비유로 설명하자면, 이건 마치 "집 청소 전략"과 같아요:

• 실시간 수집 = 로봇청소기가 매일 돌면서 청소 (소소한 먼지 자동 제거)

• 배치 수집 = 주말마다 하는 대청소 (놓친 부분 완벽하게 정리)

둘 중 하나만으로는 완벽할 수 없지만, 함께 쓰면 집이 항상 깨끗하죠!

2️⃣ 두 번째 전환점: "로컬에서 클라우드로"

문제 상황:

노트북 이동 → Wi-Fi 끊김 → 서버 중단 → 데이터 손실

해결: DigitalOcean 클라우드 서버 배포

• 고정 IP: 159.89.197.XXX

• 24/7 가동 보장

• Systemd로 자동 재시작

배포 자동화 스크립트 개발:

# 수동 배포: 30분 소요, 실수 가능
# → 자동 배포: 2분 소요, 일관성 보장

bash deploy.sh  # 한 줄로 전체 배포 완료

교훈:

"프로덕션 서비스는 처음부터 클라우드에 배포하기!"

실생활 비유를 들자면, 이건 "집에서 하는 부업 vs 사무실 차리기"의 차이예요:

• 로컬 서버 = 집에서 부업 (전기 나가면 끝, 외출하면 중단)

• 클라우드 서버 = 전용 사무실 (24시간 불켜져 있고, 내가 없어도 돌아감)

초기 비용은 좀 들지만, 장기적으로는 훨씬 안정적이죠.

3️⃣ 세 번째 전환점: "당연하다는 가정을 의심하라" 🔍

최대 난관: 커뮤니티 방에서 다른 사람 메시지가 수집되지 않는 문제

삽질의 여정:

1. 1차 시도: API 문제라고 가정

   • response() 함수 → API2 리스너로 전환

   • 코드 안정성은 향상됐지만... 문제 여전

2. 2차 시도: 필드 접근 문제라고 가정

   • msg.author.name 직접 접근 시도

   • null 체크, 안전한 접근 패턴 적용

   • 코드는 더 견고해졌지만... 문제 여전

3. 3차 시도: 메신저봇R의 한계라고 가정

   • 대안 솔루션 준비 (카카오톡 내보내기 파싱)

   • 하이브리드 아키텍처 설계

4. 진짜 원인 발견: 로그를 꼼꼼히 읽다가...

"[DEBUG] skip: not tracked room"  // 이게 계속 뜨네? 심지어...다른 엄마들이 톡을 보내는 시점마다 이게 뜨네?!!😳

결정적 테스트: !방이름 명령어로 확인

• 내가 보낸 메시지: "유주맘/0808/완료기/용인" 출력

• 다른 엄마가 보낸 메시지: "수연맘/0519/후기/남양주" 출력

• 깨달음: 실제 방 이름이 커뮤니티 명이 아닌 ‘발신자 프로필명’이었다! (두둥)

  

  ALT

  한국어 문자 메시지 스크린샷

실제 원인:

// ❌ 문제의 코드
var TARGET_ROOMS = ["유주맘/0808/완료기/용인"];

// 핵심 발견: msg.room은 "방 이름"이 아니라 "발신자 프로필명"!
// → 본인 메시지만 필터 통과, 다른 사람 메시지는 모두 차단 

배경: 카카오톡 업데이트로 오픈채팅방의 room 값이 실제 방 이름('커뮤니티 이유잇다')이 아닌 발신자 프로필명으로 반환되는 현상 발생

해결:

// ✅ 1줄 수정으로 해결
var TARGET_ROOMS = [];  // 빈 배열 = 모든 방 메시지 수집

검증:

• 즉시 다른 참여자 메시지 수집 시작

• DB 확인: 유주맘, 수연맘, 헬린맘 각각 구분되어 저장

교훈:

"복잡한 기술적 문제로 보이는 것이 사실은 1줄짜리 설정 문제일 수 있다"

실생활 비유를 들면, 이건 "자동차가 시동 안 걸릴 때"와 비슷해요:

• 복잡한 해결책: 엔진 뜯어보기, 정비소 가기, 부품 교체

• 실제 원인: 주차 브레이크가 올려져 있었음 😅

항상 간단한 것부터 확인해야 하는 이유죠!

🎓 핵심 교훈 5가지

1. Documentation-Driven Review (DDR)

방법: 코드 및 개발 과정을 항상 문서로 정리하기 → 논리적 오류 발견 가능성 향상!

<ChatCollector 프로젝트 문서 구조>
ChatCollector/
├── chat_collector.db              # SQLite DB (v2.1 스키마)
├── chat_collector_schema_v2.1.sql # DB 스키마 정의
├── ChatCollector.js               # 메신저봇 수집 스크립트 (신뢰성 보강)
├── fastapi/
│   ├── main.py                    # FastAPI 수집 서버
│   └── requirements.txt           # Python 의존성
└── README.md                      # 실행 가이드
└── dev-history.md                 # 개발 히스토리 정리
└── lesson_learned.md              # 배운점 및 인사이트 정리

실제 사례

lesson_learned.md 파일을 꼼꼼히 살펴보다가, 뭔가 이상한 점을 발견...!

ALT

한국 컴퓨터 화면의 스크린샷

문서 내용: "트리거가 자동으로 메시지 카운트를 증가시키는데..."
깨달음: "어? 그럼 내 코드에서 수동으로 +1 하는 건 뭐지?"
확인: Room UPSERT에 message_count += 1 발견
결과: 트리거와 중복! 즉시 수정

내가 다그치자 클로드코드도 자신의 실수를 인정...! 😠

ALT

한국어로 된 문자 메시지의 스크린샷

이번 경험을 통해 개발 과정을 최대한 문서로 남기고, 핵심 문서들은 한번씩 꼼꼼히 읽어보는 시간이 중요하겠다는 생각을 했습니다. 만약 AI에게 코딩을 다 맡긴 채 문서조차 남겨 두지 않았다면, 이 버그는 한참 후 더 큰 문제를 일으켰겠죠.

ALT

문서 중심 개발의 스크린샷

인사이트

"AI가 어련히 알아서 잘 해줬겠지…라는 안일한 태도는 위험하다. 의도적으로 의심하자!"

2. 체계적 문제 해결 프로세스

프로세스:

1. 증상 명확히 파악 ("안 돼요" → "어떤 상황에서 어떻게?")

2. 가설 수립 (가능한 원인 3가지 이상)

3. 체계적 테스트 (한 번에 하나씩 변수 변경)

4. 로그 확인 (추측하지 말고 데이터를 보라)

5. 해결 후 문서화 (같은 문제 재발 방지)

체크리스트:

문제 발생 시:
[ ] 로그에서 정확한 에러 메시지 확인
[ ] 설정 파일/환경 변수 검토
[ ] 가장 간단한 원인부터 테스트
[ ] 플랫폼의 실제 동작 방식 확인
[ ] "당연하다"고 가정한 부분 재검증
[ ] 복잡한 해결책은 마지막 수단

3. 자동화의 가치

원칙: 두 번 이상 하는 작업은 무조건 스크립트로 자동화

적용 사례:

• 배포 스크립트: 30분 → 2분 (93% 시간 절약)

• 자동 백업: 매일 23:30 (잊어버릴 일 없음)

• 메시지 조회: 통계 자동 계산

효과:

1. 시간 절약

2. 휴먼 에러 제거

3. 문서화 자동 완성 (스크립트 자체가 문서)

4. 재현 가능성 보장

4. Happy Accident의 가치

API2 전환은 불필요했지만:

• null 체크 강화

• 안전한 필드 접근 패턴 확립

• 에러 처리 개선

교훈:

"삽질도 결과적으로 코드 품질 향상에 기여한다"

5. 3-2-1 백업 전략

• 3개의 복사본: 원본 + 로컬 백업 + 서버 백업

• 2개의 다른 매체: SSD(로컬) + 클라우드

• 1개는 오프사이트: DigitalOcean 서버

인사이트:

"데이터는 언제든 손실될 수 있다. 백업 없는 데이터는 없는 것과 같다."

🔧 기술적 디테일

메신저봇R 핵심 패턴

// ✅ 올바른 방법
function response(room, msg, sender, isGroupChat, replier, imageDB, packageName) {
    // 메시지 처리 로직
}

// 주의사항:
// - Rhino JavaScript 엔진 (ES5만 지원)
// - var 키워드 사용 필수 (const, let 불가)
// - msg.room은 방 이름이 아니라 발신자 프로필명

중복 방지 메커니즘

-- DB 레벨에서 강제
CREATE UNIQUE INDEX idx_messages_unique
ON messages(room_id, participant_id, sent_at, content);

트리거로 통계 자동화

-- 애플리케이션에서 카운트 건드리지 않음
-- 트리거가 자동으로 message_count 관리
CREATE TRIGGER increment_message_count
AFTER INSERT ON messages
BEGIN
    UPDATE rooms SET message_count = message_count + 1
    WHERE room_id = NEW.room_id;
END;

📊 시스템 아키텍처

┌─────────────────────────────────────────────────┐
│            카카오톡 메시지                       │
└────────────────┬────────────────────────────────┘
                 │
      ┌──────────┴──────────┐
      ▼                     ▼
┌─────────────┐      ┌──────────────────┐
│ 메신저봇R   │      │ 대화 내보내기    │
│ (실시간)    │      │ (주기적 백업)    │
└──────┬──────┘      └────────┬─────────┘
       │                      │
       │ HTTP POST            │ 파일 전송
       ▼                      ▼
┌──────────────────────────────────────────┐
│  DigitalOcean (159.89.197.142:8200)     │
│  ┌────────────────────────────────────┐ │
│  │ FastAPI + SQLite                   │ │
│  │ - 중복 방지 (UNIQUE INDEX)         │ │
│  │ - 트리거 기반 통계                 │ │
│  │ - 24/7 가동                        │ │
│  └────────────────────────────────────┘ │
└──────────────────────────────────────────┘
       │                      ▲
       │                      │
       ▼                      │
┌─────────────┐      ┌─────────────────┐
│ 자동 백업   │      │ 실시간 모니터링 │
│ (매일)      │      │ (SSH)           │
└─────────────┘      └─────────────────┘

🎯 Next Steps

단기 (1주일 내)

• 과거 데이터 마이그레이션 (1년 반치)

• 서버 자동 백업 시스템 구축

• 실시간 수집 데이터 검증

중기 (1개월 내)

• 메시지 분석 기능 (자주 묻는 질문, 트렌드)

• 참여자 온보딩 자동화

• 이메일 자동 발송 시스템

장기

• AI 기반 메시지 분류 및 요약

• 대시보드 구축 (Streamlit/Gradio)

💡 핵심 인사이트

완벽주의를 버리고 실행하자

완벽한 시스템은 없습니다. 하지만 지속적으로 개선하는 시스템은 완벽에 가까워져요.

개발 과정을 꾸준히 문서화하자

문서는 자산이자 미래의 문제를 해결한 열쇠입니다. 미래의 자신을 위해 문서를 남기세요.

가정을 의도적으로 의심하자

복잡한 문제는 대부분 간단한 원인에서 시작됩니다.

Happy Accident도 가치가 있다

삽질도 결과적으로 코드 품질 향상에 기여합니다. 돌아간 길도 여정의 일부입니다.

📚 참고 자료

• 메신저봇R 공식 문서

• FastAPI 공식 문서

• SQLite 공식 문서

• 프로젝트 기간: 2025-11-27 ~ 2025-11-30 (4일)

• 프로젝트 상태: 🟢 운영 중 (실시간 수집 정상 작동)