슬랙·디스코드 기반 게임 개발팀 일일 요약과 블로커 자동 감지
슬랙과 디스코드에 흩어진 게임 개발팀 대화를 Python 3.12 기반 파이프라인으로 수집하고 담당자·일정·의존성을 추출해 일일 진행 상황 요약과 블로커 알림으로 연결하는 설계, 점수화 기준, 개인정보 보호와 운영 절차를 정리합니다.
핵심 요약
슬랙과 디스코드의 프로젝트 채널 대화를 공식 API와 이벤트 수집기로 모은 뒤 메시지를 작업·결정·리스크·블로커로 분류하면 일일 진행 상황을 자동으로 요약할 수 있습니다. 블로커는 단순한 부정 표현이 아니라 담당자, 의존성, 기한, 미해결 상태를 함께 평가해야 오탐을 줄일 수 있습니다. 최종 알림은 AI가 임의로 판단하게 두지 말고 규칙 기반 점수와 사람의 확인 절차를 결합하는 방식이 안전합니다.
왜 슬랙·디스코드 일일 대화 요약이 필요한가?
게임 개발팀의 진행 정보는 하나의 문서에 모이지 않습니다. 기획자는 슬랙에서 밸런스 변경을 논의하고 프로그래머는 디스코드 스레드에서 빌드 오류를 공유하며 아티스트는 작업 완료 이미지를 별도 채널에 올립니다.
이 정보가 담당자별 기억에 의존하면 다음 문제가 생깁니다.
| 문제 | 실제 영향 |
|---|---|
| 대화가 여러 채널에 분산됨 | 진행 상황을 다시 찾는 데 시간이 걸림 |
| 완료 메시지만 기록됨 | 지연 원인과 의존성이 누락됨 |
| 같은 이슈가 여러 번 언급됨 | 중요도가 과대평가될 수 있음 |
| 결정 사항이 스레드에 묻힘 | 잘못된 버전으로 작업할 위험이 생김 |
| 개인 메시지까지 무분별하게 수집됨 | 신뢰와 개인정보 보호 문제가 발생함 |
따라서 자동화의 목표는 모든 대화를 감시하는 것이 아닙니다. 팀이 이미 공유하기로 합의한 업무 대화에서 실행 가능한 정보만 추출해 다음 날의 의사결정을 돕는 것입니다.
일일 진행 상황 자동 요약 시스템은 어떻게 구성할까?
예시는 Python 3.12, FastAPI, PostgreSQL 16, Redis를 사용하는 서버 구조를 기준으로 합니다. 실제 사용 환경에서는 팀의 인증 방식과 호스팅 정책에 맞게 선택하면 됩니다.
flowchart LR
A[Slack 프로젝트 채널] --> C[수집기]
B[Discord 지정 서버] --> C
C --> D[메시지 정규화 및 중복 제거]
D --> E[작업·결정·리스크 분류]
E --> F[블로커 점수 계산]
E --> G[일일 요약 생성]
F --> H[PM 검토 큐]
G --> I[이메일 또는 Slack 리포트]
H --> J[담당자 확인 후 알림]각 구성 요소의 책임을 분리하면 장애 원인을 찾기 쉽고 모델을 교체하기도 편합니다.
| 구성 요소 | 역할 | 저장할 핵심 필드 |
|---|---|---|
| 수집기 | 허용된 채널의 신규·변경 메시지 수신 | 플랫폼, 채널, 메시지 ID, 작성 시각 |
| 정규화기 | Slack과 Discord의 형식을 통일 | 작성자, 본문, 스레드, 리액션 |
| 분류기 | 메시지의 업무 의미를 판별 | 작업, 완료, 결정, 리스크, 블로커 |
| 점수 계산기 | 블로커의 긴급도와 신뢰도 계산 | 위험 신호, 의존성, 기한, 미해결 상태 |
| 요약기 | 기간별 진행 상황을 문서화 | 완료, 진행 중, 지연, 결정, 다음 액션 |
| 알림기 | PM 또는 담당자에게 결과 전달 | 알림 수준, 원문 링크, 확인 상태 |
어떤 메시지를 수집하고 무엇을 제외할까?
첫 단계는 기술보다 운영 규칙을 정하는 것입니다. 기본값으로 개인 메시지와 사적인 채널은 수집하지 않고 프로젝트에서 명시적으로 허용한 채널만 대상으로 삼는 편이 좋습니다.
일일 요약에 필요한 메시지는 다음과 같습니다.
- 작업 시작, 완료, 보류, 재작업을 나타내는 메시지
- 기획·아트·프로그래밍 사이의 의존성 논의
- 빌드 실패, 테스트 실패, 에셋 누락, 외부 검수 대기
- 일정 변경과 우선순위 변경
- 팀의 실행에 영향을 주는 결정 사항
- 담당자와 다음 액션이 명시된 스레드
반대로 단순한 인사, 반복적인 이모지 반응, 업무와 무관한 대화는 요약 대상에서 제외할 수 있습니다. 다만 리액션을 전부 버리면 승인이나 확인 신호를 놓칠 수 있으므로 확정, 승인, 보류처럼 팀에서 합의한 리액션은 별도로 보존해야 합니다.
정규화된 메시지의 최소 데이터 구조는 다음과 같습니다.
| 필드 | 설명 | 예시 |
|---|---|---|
platform | 원본 서비스 | slack |
channel_id | 채널 식별자 | gameplay-dev |
message_id | 중복 제거용 키 | 플랫폼별 고유 ID |
thread_id | 스레드 묶음 식별자 | 부모 메시지 ID |
author_role | 작성자의 역할 | programmer, designer |
created_at | 원본 작성 시각 | ISO 8601 형식 |
content | 정규화된 본문 | 민감정보 제거 후 저장 |
source_url | 검토용 원문 링크 | 권한이 있는 팀 링크 |
수집 시각은 UTC로 저장하고 보고서 표시는 팀의 기준 시간대인 KST로 변환하는 방식을 권장합니다. 특히 자정 전후에 작성된 메시지가 어느 업무일에 속하는지 명확히 정해야 합니다.
블로커는 왜 발생하고 어떻게 감지할까?
블로커는 “문제가 있다”는 문장 하나만으로 확정할 수 없습니다. 예를 들어 “애니메이션이 아직 안 왔습니다”는 단순한 진행 공유일 수 있지만 “애니메이션이 금요일까지 오지 않으면 통합 테스트를 시작할 수 없습니다”는 일정에 영향을 주는 블로커 후보입니다.
다음 네 가지 신호를 분리해서 추출하면 판단 근거를 설명할 수 있습니다.
| 신호 | 의미 | 예시 |
|---|---|---|
R 위험 표현 | 실패·지연·불가 가능성 | 빌드 실패, 접근 불가 |
D 의존성 | 다른 사람이나 시스템의 선행 작업 | 서버 API 대기 |
T 시간 압박 | 기한 또는 일정 영향 | 오늘, 마감 전, 테스트 차단 |
U 미해결 상태 | 해결책이나 확인자가 없음 | 답변 대기, 담당자 미지정 |
예를 들어 블로커 후보 점수는 다음처럼 계산할 수 있습니다. 이 계수는 정답이 아니라 팀 데이터로 조정해야 하는 초기 기준입니다.
각 변수는 0부터 1 사이로 정규화합니다. B가 0.75 이상이면 긴급 검토 후보, 0.55 이상 0.75 미만이면 PM 검토 큐, 0.55 미만이면 일반 리포트로 보내는 식입니다.
중요한 점은 점수가 높다고 자동으로 팀 전체에 알리지 않는 것입니다. 자동화는 원문 링크와 판단 근거를 함께 보여주고 PM이나 담당자가 확인한 뒤 최종 알림을 보내야 합니다.
규칙과 언어 모델을 어떻게 함께 사용할까?
규칙 기반 탐지는 명확한 표현과 기한을 빠르게 찾는 데 적합합니다. 언어 모델은 여러 메시지와 스레드를 읽고 “이 문제가 일정에 어떤 영향을 주는가?”를 요약하는 데 유리합니다.
권장 순서는 다음과 같습니다.
- 규칙으로 명백한 완료·승인·블로커 표현을 먼저 추출합니다.
- 후보 메시지와 같은 스레드의 앞뒤 문맥만 언어 모델에 전달합니다.
- 언어 모델은 자유로운 문장 대신 정해진 JSON 스키마로 결과를 반환합니다.
- 서버는 점수와 필수 필드를 검증한 뒤 PM 검토 큐에 등록합니다.
from dataclasses import dataclass
@dataclass
class Message:
content: str
has_dependency: bool
has_deadline: bool
unresolved: bool
def blocker_score(message: Message) -> float:
risk_terms = ["실패", "막혔", "불가", "대기", "지연", "오류"]
risk = 1.0 if any(term in message.content for term in risk_terms) else 0.0
dependency = 1.0 if message.has_dependency else 0.0
time_pressure = 1.0 if message.has_deadline else 0.0
unresolved = 1.0 if message.unresolved else 0.0
score = (
0.45 * risk
+ 0.30 * dependency
+ 0.15 * time_pressure
+ 0.10 * unresolved
)
return round(score, 2)언어 모델의 출력에는 다음 필드를 요구하는 것이 실용적입니다.
{
"type": "blocker",
"summary": "콘솔 빌드가 인증 서버 오류로 생성되지 않음",
"owner": "빌드 담당자",
"dependency": "인증 서버 설정 확인",
"deadline": "2026-08-25",
"impact": "QA 테스트 시작 지연 가능성",
"confidence": 0.86,
"source_message_ids": ["message-123"]
}confidence는 사람이 읽기 쉽게 만드는 참고값일 뿐입니다. 신뢰도가 높아도 원문 링크가 없거나 담당자가 비어 있으면 자동 에스컬레이션하지 않는 검증 규칙을 추가해야 합니다.
일일 요약에는 어떤 정보를 넣어야 할까?
좋은 요약은 대화량을 보여주는 보고서가 아니라 다음 행동을 결정하는 문서입니다. 메시지 개수나 가장 많이 말한 사람보다 완료된 작업과 일정에 영향을 줄 수 있는 미해결 항목을 앞에 배치해야 합니다.
권장 출력 구조는 다음과 같습니다.
1. 전체 상태
- 오늘 완료된 주요 작업
- 진행 중인 작업과 현재 담당자
- 일정에 영향을 줄 수 있는 블로커
- 새로 확정된 결정 사항
- 다음 업무일의 우선 액션
2. 작업별 상태
| 상태 | 포함할 내용 |
|---|---|
| 완료 | 작업명, 완료 확인 메시지, 관련 빌드 또는 문서 링크 |
| 진행 중 | 현재 단계, 담당자, 다음 액션 |
| 지연 위험 | 예상 일정, 원인, 영향을 받는 작업 |
| 결정 필요 | 선택지, 결정권자, 결정 기한 |
3. 원문 근거
각 요약 문장에는 원문 메시지나 스레드 링크를 연결합니다. 요약이 틀렸을 때 팀원이 빠르게 수정할 수 있어야 자동화에 대한 신뢰가 유지됩니다.
자동 요약 기능은 어떤 순서로 구현할까?
1단계: 채널과 보고 시간대를 고정한다
먼저 수집 대상 채널, 제외 채널, 업무일의 시작과 종료 시각을 문서로 정의합니다. 예를 들어 평일 09:00부터 18:00까지의 메시지를 KST 기준으로 집계하고 야간 메시지는 다음 업무일의 참고 항목으로 분리할 수 있습니다.
2단계: 메시지를 정규화하고 중복을 제거한다
Slack과 Discord는 사용자 ID, 스레드, 수정 메시지, 첨부 파일을 서로 다른 형식으로 제공합니다. 내부 저장 모델을 하나로 통일하고 platform + channel_id + message_id를 유일 키로 사용하면 재수집에 따른 중복 요약을 줄일 수 있습니다.
메시지가 수정되면 새 메시지로 추가하지 말고 원본 레코드의 버전을 갱신합니다. 삭제된 메시지는 원문을 계속 보존하기보다 삭제 상태와 필요한 감사 로그만 남기는 편이 안전합니다.
3단계: 분류와 블로커 검토를 거쳐 리포트를 발행한다
분류 결과가 만들어지면 먼저 자동 검증을 실행합니다.
- 담당자 없는 블로커는
확인 필요로 표시합니다. - 기한이 과거인 항목은 지연 후보로 분리합니다.
- 같은 이슈의 메시지는 스레드와 이슈 키로 묶습니다.
- 완료 메시지가 있으면 이전 블로커를 자동으로 닫지 말고 확인 이벤트를 기록합니다.
- 보고서 생성 실패 시 원문 수집 데이터는 보존하고 재시도합니다.
그 뒤 PM 검토 큐에서 승인된 항목만 팀 채널이나 이메일로 발행합니다. 리포트 발행 시각과 원문 링크를 함께 남기면 나중에 일정 변경의 근거를 추적할 수 있습니다.
개인정보와 팀 신뢰는 어떻게 보호할까?
대화 자동화는 기술 문제가 아니라 운영 신뢰의 문제이기도 합니다. 다음 원칙을 기본 정책으로 두는 것이 좋습니다.
- 개인 메시지와 비공개 채널은 기본적으로 수집하지 않습니다.
- 수집 대상 채널과 사용 목적을 팀에 공개합니다.
- 모델 입력 전에 이메일, 전화번호, 토큰, 인증 정보 같은 민감정보를 마스킹합니다.
- 원문 보존 기간과 요약 보존 기간을 다르게 설정합니다.
- 팀원이 자신의 메시지가 어떻게 요약됐는지 확인할 수 있게 합니다.
- 자동 알림에는 “AI 분석 결과이며 사람의 확인이 필요함”을 표시합니다.
- API 토큰은 환경 변수나 비밀 저장소에 보관하고 코드 저장소에 포함하지 않습니다.
특히 개발 중인 기능이나 미공개 사업 정보가 대화에 포함될 수 있으므로 외부 모델을 사용할 때는 데이터 처리 조건과 저장 정책을 반드시 검토해야 합니다.
운영 지표는 무엇을 측정할까?
자동화의 성공 여부를 “요약이 생성됐는가”로 판단하면 안 됩니다. 다음 지표를 주간 단위로 확인하는 편이 유용합니다.
| 지표 | 의미 |
|---|---|
| 블로커 확인율 | 자동 감지 항목 중 사람이 실제 이슈로 인정한 비율 |
| 오탐률 | 블로커가 아니어서 제외된 알림 비율 |
| 요약 수정률 | 발행 후 팀원이 수정한 요약 비율 |
| 평균 해결 시간 | 블로커 등록부터 해결 확인까지 걸린 시간 |
| 원문 클릭률 | 팀원이 요약의 근거 링크를 확인한 비율 |
오탐률이 높으면 위험 키워드의 가중치를 낮추고 미해결 상태와 일정 영향을 더 강하게 반영할 수 있습니다. 반대로 중요한 이슈가 누락되면 스레드 문맥, 기한 표현, 의존성 추출 규칙을 점검해야 합니다.
자주 묻는 질문 (FAQ)
슬랙과 디스코드의 모든 대화를 수집해야 하나요?
아닙니다. 프로젝트에서 합의한 공개 채널과 지정 서버만 수집하는 것이 좋습니다. 개인 메시지와 사적인 채널은 기본 제외하고 필요한 경우에도 명시적인 동의와 보존 정책을 먼저 정해야 합니다.
언어 모델만으로 블로커를 판단해도 되나요?
권장하지 않습니다. 언어 모델은 문맥 요약에 사용하고 채널 허용 여부·필수 필드·기한·점수 임계값은 서버의 결정론적 규칙으로 검증해야 오탐과 설명 불가능성을 줄일 수 있습니다.
일일 요약은 언제 발행하는 것이 가장 좋은가요?
팀의 업무일 종료 직후 또는 다음 스탠드업 직전에 발행하는 방식이 일반적입니다. 중요한 것은 시간이 아니라 팀이 실제로 읽고 수정할 수 있는 고정된 시각과 담당자를 정하는 것입니다.
마무리
슬랙·디스코드 기반 일일 요약은 대화 내용을 많이 모으는 프로젝트가 아닙니다. 허용된 채널에서 업무 사실을 구조화하고 블로커의 근거와 다음 액션을 연결하며 사람이 결과를 확인할 수 있게 만드는 협업 시스템입니다.
처음에는 채널 두세 개와 완료·블로커·결정 세 가지 분류만으로 시작하는 편이 좋습니다. 이후 실제 오탐과 누락 데이터를 바탕으로 점수 가중치, 요약 형식, 알림 정책을 조정하면 팀에 맞는 자동화로 발전시킬 수 있습니다.
