"언제 누가 왜 바꿨는지 알 수 있을까요?"
프로젝트 중간에 일정이 갑자기 바뀌었습니다.
팀원들은 모두 당황스러워합니다.
"누가 언제 바꾼 거죠?"
"왜 바꾼 건가요?"
"원래 계획이 뭐였더라?"
하지만 기존 프로젝트 관리 도구는 현재 상태만 보여줄 뿐, 변경 과정은 알 수 없습니다.
일정이 3일에서 1주일로 변경되었지만, 왜 바뀌었는지, 누가 바꿨는지 기록이 없어 나중에 문제가 생겨도 원인을 찾을 수 없습니다.
Git처럼 모든 변경 이력을 추적할 수 있다면 어떨까요?
Event Sourcing은 모든 변경사항을 이벤트로 기록하여 언제, 누가, 왜 바꿨는지 모두 추적할 수 있게 해줍니다.
오늘은 이벤트 기반 아키텍처로 프로젝트의 모든 변화를 기록하는 방법을 알아봅니다.
전통적 상태 기반 모델의 한계
대부분의 프로젝트 관리 도구는 현재 상태만 저장합니다.
문제점:
- 변경 이력 손실: "언제 바뀌었는지" 알 수 없음
- 변경 이유 불명: "왜 바꿨는지" 기록되지 않음
- 변경자 추적 불가: "누가 바꿨는지" 알 수 없음
- 과거 상태 복원 불가: "원래 뭐였는지" 알 수 없음
실제 예시:
- 일정이 3일에서 1주일로 변경됨
- 하지만 왜 바뀌었는지, 누가 바꿨는지 기록이 없음
- 나중에 문제가 생겨도 원인을 찾을 수 없음
Event Sourcing의 마법
Event Sourcing은 모든 변경사항을 이벤트로 기록합니다.
핵심 개념:
- 현재 상태가 아닌 이벤트 스트림 저장
- 이벤트를 재생하여 현재 상태 재구성
- 모든 변경 이력 영구 보존
전통적 모델 vs Event Sourcing:
전통적 모델:
- 현재 상태만 저장
- 변경 이력 손실
- "어떻게" 바뀌었는지 알 수 없음
Event Sourcing:
- 모든 이벤트 저장
- 변경 이력 완전 보존
- "언제, 누가, 왜" 모두 기록
이벤트 예시:
- TaskCreated: 작업 생성
- TaskAssigned: 작업 할당
- TaskStatusChanged: 상태 변경
- TaskDueDateChanged: 마감일 변경
- TaskCompleted: 작업 완료
각 이벤트에는 타임스탬프, 사용자 ID, 변경 이유가 포함됩니다.
CQRS로 읽기/쓰기 최적화
CQRS(Command Query Responsibility Segregation)는 읽기와 쓰기를 분리합니다.
Command Side (쓰기):
- 프로젝트 상태 변경
- 이벤트 생성 및 저장
- 비즈니스 규칙 검증
Query Side (읽기):
- 최적화된 읽기 모델
- 사전 계산된 집계 데이터
- 빠른 대시보드 조회
장점:
- 쓰기: 이벤트 스트림에만 저장 (단순)
- 읽기: 최적화된 뷰에서 조회 (빠름)
- 확장성: 읽기/쓰기 독립적 확장 가능
이벤트 기반 자동 알림
이벤트가 발생하면 자동으로 알림을 보낼 수 있습니다.
이벤트 핸들러 예시:
- TaskOverdue: 담당자에게 알림
- SprintVelocityDrop: 팀 리드에게 경고
- DependencyBlocked: 매니저에게 에스컬레이션
- TaskCompleted + SprintGoalMet: 성공 축하
복합 이벤트 처리:
- 여러 이벤트 조합으로 복잡한 로직 실행
- 예: "작업 완료 + 스프린트 목표 달성" → 자동 축하 메시지
프로젝트 관리에 적용하기
1. 작업 변경 이력 추적
기존 방식:
- 현재 상태만 저장
- 변경 이력 없음
이벤트 기반:
- 모든 변경을 이벤트로 기록
- 언제, 누가, 왜 바꿨는지 모두 추적
2. 프로젝트 타임라인 재구성
가능한 것:
- 프로젝트의 모든 변경사항을 시간순으로 재생
- 특정 시점의 상태로 되돌리기
- 변경 패턴 분석
활용 예시:
- "3개월 전 계획이 뭐였지?" → 이벤트 재생으로 복원
- "왜 일정이 이렇게 늦어졌지?" → 이벤트 분석으로 원인 파악
3. AI 기반 자동 계획 및 보고서 생성
이벤트 기반 아키텍처와 AI를 결합하면 더욱 강력해집니다. 예를 들어, Plexo의 AI Task Breakdown 기능은 기능 설명만 입력하면 AI가 세부 작업·예상 시간·우선순위를 자동 생성하고, 이를 이벤트로 기록하여 모든 계획 변경 과정을 완벽하게 추적할 수 있습니다.
이벤트 기반 집계:
- AI가 생성한 WBS 계획과 실제 진행 상황의 차이를 이벤트로 자동 추적
- 일일/주간/월간 보고서 자동 생성
- 변경 추이 분석
- 팀 활동 패턴 분석
실전 구현 전략
1. 이벤트 스키마 설계
이벤트 구조:
- 이벤트 ID: 고유 식별자
- 이벤트 타입: TaskCreated, TaskAssigned 등
- 타임스탬프: 발생 시간
- 사용자 ID: 변경한 사람
- 페이로드: 변경 내용
- 메타데이터: 변경 이유, IP 주소 등
2. 이벤트 저장소
요구사항:
- 영구 보관
- 빠른 조회
- 확장 가능
도구 선택:
- 소규모: PostgreSQL
- 중규모: EventStore
- 대규모: Kafka + EventStore
3. 읽기 모델 구축
최적화 전략:
- 자주 조회하는 데이터는 사전 계산
- 대시보드용 집계 데이터 별도 저장
- 실시간 업데이트 (이벤트 발생 시)
이벤트 기반 아키텍처의 장단점
장점
완전한 감사 추적
- 모든 변경사항 기록
- 규정 준수 용이
시간 여행 가능
- 과거 상태로 되돌리기
- 특정 시점 상태 확인
유연한 확장
- 새로운 읽기 모델 추가 용이
- 분석 및 리포팅 강화
자동화 가능
- 이벤트 기반 자동 알림
- 복잡한 비즈니스 로직 구현
단점
복잡도 증가
- 구현이 복잡함
- 학습 곡선 존재
저장 공간
- 이벤트가 계속 쌓임
- 장기 보관 시 용량 증가
성능 고려
- 많은 이벤트 재생 시 느려질 수 있음
- 스냅샷 전략 필요
실전 체크리스트
설계 단계
- 이벤트 스키마 정의
- 이벤트 저장소 선택
- 읽기 모델 설계
구현 단계
- 이벤트 핸들러 구현
- 읽기 모델 구축
- 스냅샷 전략 수립
운영 단계
- 이벤트 모니터링
- 읽기 모델 성능 최적화
- 정기적인 이벤트 아카이빙
핵심 정리
이벤트 기반 아키텍처는 복잡하지만 강력한 패턴입니다.
모든 변경사항을 기록하고, 언제든 과거로 돌아갈 수 있으며, 자동화된 시스템을 구축할 수 있습니다.
프로젝트 관리에서도 마찬가지입니다.
Git처럼 모든 변경 이력을 추적하면, 언제든 과거를 확인하고, 문제의 원인을 찾고, 자동화된 워크플로우를 만들 수 있습니다.
다음 프로젝트부터 이벤트 기반 아키텍처를 고려해보세요.
작은 변화가 큰 차이를 만듭니다.
AI 기반 프로젝트 계획과 모든 변경 이력을 추적하는 프로젝트 관리 도구가 필요하신가요? Plexo를 확인해보세요.
