TIL Challenge Bot

프로젝트 소개

이 프로젝트는 교보 CDA 1기 과정의 TIL 챌린지를 지원하기 위해 진행되었습니다. 매니저님들이 직접 수행하던 챌린지 글 게시, 좋아요 집계, 월별 주차별 참여 인원 선정 작업을 TIL 챌린지 봇을 통해 자동화하였으며, 주차별 참여 인원과 좋아요 수를 웹페이지에서 한눈에 볼 수 있도록 시각화했습니다.

💡 TIL 챌린지란?
매주 TIL N월 N주차라는 메시지를 슬랙(Slack)에 게시하면, 멤버들은 해당 메시지에 답글로 자신이 작성한 블로그 글의 URL을 올립니다. 다른 사용자들은 해당 글을 읽고, 마음에 들면 좋아요(👍)를 눌러 서로의 학습 내용을 격려하고 공유합니다.

---

프로젝트 개요

배경

Slack 기반 TIL 챌린지에서는 새 답글이 등록될 때, 해당 글에 참여한 일부 멤버만 알림을 받고, 챌린지에 참여하지 않은 멤버들은 새로운 학습 내용이 게시된 사실을 알 수 없었습니다. 이로 인해 ‘서로의 학습 내용을 공유한다’는 챌린지의 본래 취지를 살리지 못한다고 생각했습니다.
또한, 기존에는 매니저님이 매주 수동으로 TIL N월 N주차 글을 작성하고, 참여 현황과 좋아요(👍) 수를 직접 집계하는 방식이 비효율적이라고 판단했습니다. 이러한 문제를 개선하기 위해 본 프로젝트를 시작하게 되었습니다.

목표

• Slack 기반 TIL 챌린지의 운영 과정을 자동화
• 참여 현황 및 성과를 명확히 파악할 수 있도록 하는 챗봇 및 대시보드를 제공

기술 스택

• Python, Slack API, AWS, React

---

주요 기능

1. TIL 챌린지 메세지 및 참여 알림 메시지 게시 자동화
   • 매주 월요일 TIL N월 N주차 메시지를 Slack 채널에 자동으로 게시
     
   • 멤버가 블로그 URL을 첨부한 답글을 달면 전체 채널에 알림 메시지 발송
2. 좋아요(👍) 집계 자동화
   • TIL 챌린지 게시글의 답글에 달린 👍 이 추가/삭제될 때마다 해당 멤버의 좋아요 수를 실시간 집계
   • 좋아요 반영 시 Velog, Github, Naver 블로그 링크 여부 체크를 통해 실제 참여여부를 정확히 관리
3. 월별 챌린저 선정 자동화
   • 매월 첫 번째 월요일에 지난달 전 주차에 참여한 멤버 및 그 중 최고 좋아요 획득자를 자동 선정 및 발표
4. 참여 현황 시각화 대시보드 제공
   • S3에 저장된 JSON 데이터를 React 기반 정적 웹으로 시각화
   • 주차별 참여 인원 및 좋아요 수를 한눈에 확인 가능
5. 운영을 위한 Slack 개인 DM 좋아요 및 에러 알림
   • 좋아요 변동 시 본인 DM으로 상태 메시지 전송
   • 시스템 에러 발생 시 에러 알림 메시지 전송

---

아키텍처

• 서버리스 아키텍처(AWS Lambda) 선택 이유
  • 빠른 배포, 관리 부담 감소, 사용량 기반 과금
• S3 사용 이유
  • 소규모 JSON 데이터 관리에 적합, 단순 구조 유지
• SQS 도입
  • FIFO 큐로 요청 직렬 처리 → 동시성 문제 해결, 데이터 무결성 보장

---

문제 해결 경험

문제 1 - S3 동시성 문제

초기에는 API Gateway → Lambda → S3 구조로 요청을 처리했습니다. 또한, 챌린지 참여자 수가 10명 내외로 많지 않아 간단히 S3에 JSON 형태로 데이터를 저장하고 읽는 방식이었습니다. 그러나 S3에는 파일 잠금(파일 락) 기능이 없어, 여러 사용자가 동시에 데이터를 읽고 쓰는 상황에서 데이터 무결성이 깨질 수 있었습니다.
예를 들어, A와 B가 동시에 챌린지에 참여하는 글을 남길 때, Lambda는 동일한 S3 JSON 파일을 불러와 각각의 참여 정보를 추가합니다. A가 먼저 S3에 데이터를 반영하고 저장한 직후, B도 이전 상태의 S3 데이터를 기반으로 다시 저장하려 하면 A의 변경 사항이 덮어쓰여져 데이터에 반영되지 않을 수 있습니다.

개선 방법: SQS(FIFO) 도입

이 문제를 해결하기 위해 AWS SQS의 FIFO 큐를 도입했습니다. 새로운 구조는 다음과 같습니다. 이제 모든 요청은 먼저 SQS에 적재되며, FIFO 큐 특성상 메시지를 순서대로 하나씩 Lambda 함수에 전달합니다. 또한, SQS 트리거 설정 시 배치 처리 수를 1로 지정하여 Lambda가 오직 하나의 요청만 순차적으로 처리하도록 했습니다. 이로써 S3 접근 시 모든 이전 요청 처리가 완료된 상태를 보장하여, 동시에 발생할 수 있는 덮어쓰기 문제를 근본적으로 방지하고 S3 데이터의 무결성을 확보할 수 있었습니다.

문제 2 - Slack 이벤트 URL 검증(Challenge 요청) 문제

Slack 이벤트를 구독하려면 Slack에서 제공하는 Challenge 요청에 응답해야 합니다. 이때 Slack은 challenge라는 키를 포함한 값을 보내며, 서버는 해당 challenge 값을 그대로 반환해야 이벤트 구독을 인정받습니다.
하지만 기존 구조(API Gateway → SQS → Lambda)에서는 Slack이 원하는 즉각적인 응답을 제공하기 어려웠습니다. Slack이 challenge 요청을 보내면, API Gateway는 이를 SQS에 전달하고, SQS는 메시지 큐에 성공적으로 저장했다는 응답을 API Gateway로 보내는 식으로 비동기로 동작하기 때문입니다.
그 결과 Slack에게는 challenge 값 대신 SQS 처리 성공 정보가 먼저 반환되어버리고, Slack은 URL 검증에 실패하게 됩니다. Lambda가 나중에 challenge 값을 보내도 이미 검증 요청은 끝난 상태입니다.

개선 방법: Challenge 처리 전용 Lambda 추가

이 문제를 해결하기 위해 Challenge 요청에 대해서만 즉시 응답 가능한 구조를 도입했습니다. SQS로 보내기 전 Challenge 요청 전용 Lambda 함수를 추가하여, 이 Lambda에서 Slack의 challenge 값을 즉시 반환하도록 했습니다. 이렇게 하면 Slack이 바로 원하는 응답을 얻을 수 있어 이벤트 구독이 정상적으로 완료됩니다.
이후 일반 이벤트 요청은 기존대로 SQS를 통해 비동기적으로 처리하면 됩니다. 이를 통해 Slack 이벤트 URL 검증에 실패하는 문제를 해결했습니다.

---

결과 및 성과

• TIL 챌린지 진행 프로세스 완전 자동화
• 새로운 글 게시 및 좋아요 변동에 대한 실시간 알림 제공
• 관리자 수동 집계 업무 완전 대체 및 시각화 대시보드 제공
• AWS 서버리스 아키텍처 도입으로 안정적이고 확장 가능한 서비스 운영 역량 강화

---

🔗 Link

• Home
• 정리 문서
  • 서버리스 아키텍처 선정 배경
  • 문제점과 개선한점
  • Slack Api 이벤트 처리