동시성 제어의 부재: CAP 정리로 본 Excel의 한계
소프트웨어 엔지니어라면 CAP 정리(Consistency, Availability, Partition tolerance)를 알 것입니다. 분산 시스템에서는 이 세 가지를 모두 만족할 수 없다는 이론이죠.
Excel 기반 WBS 관리에서도 비슷한 문제가 발생합니다:
Consistency(일관성): 모든 팀원이 같은 버전을 보고 있는가?
Availability(가용성): 언제든 접근하고 수정할 수 있는가?
Partition tolerance(분할 내성): 네트워크가 끊어져도 작업을 계속할 수 있는가?
Excel은 이 중 어느 것도 제대로 보장하지 못합니다.
읽는 시간: 6분
대상 독자: 소프트웨어 엔지니어, 기술 리드, 아키텍트
파일 기반 시스템의 근본적 한계
Race Condition과 Lost Update 문제
데이터베이스 시스템에서 잘 알려진 Race Condition 문제가 Excel WBS에서도 동일하게 발생합니다:
-- 트랜잭션 A (김팀장)
BEGIN TRANSACTION;
UPDATE tasks SET start_date = '2024-01-15' WHERE task_id = 'T001';
-- 30분 후 COMMIT
-- 트랜잭션 B (박대리) - 거의 동시에 시작
BEGIN TRANSACTION;
UPDATE tasks SET assignee = '이개발' WHERE task_id = 'T001';
-- 35분 후 COMMIT (김팀장 변경사항 덮어씀)
Excel에서는 이런 동시성 제어 메커니즘이 전혀 없습니다. Last Writer Wins 정책만 적용되어 먼저 작업한 사람의 노력이 사라집니다.
버전 관리 시스템의 부재
Git을 사용하는 개발자라면 이해할 것입니다:
# Git에서는 이렇게 충돌을 해결하죠
git merge feature-branch
# Conflict 발생 시 수동 해결
git add resolved-file.js
git commit -m "Merge conflict resolved"
# Excel에서는?
# 충돌 감지 불가 → 데이터 손실 → 수동 복구 → 시간 낭비
확장성 문제: O(n²) 복잡도
팀 크기가 커질수록 파일 공유의 복잡도는 기하급수적으로 증가합니다:
def communication_overhead(team_size):
# 팀원 간 파일 공유 경로의 수
return team_size * (team_size - 1) / 2
# 5명 팀: 10개 경로
# 10명 팀: 45개 경로
# 20명 팀: 190개 경로
Excel WBS는 O(n²) 복잡도로 확장되어 일정 규모를 넘으면 관리 불가능해집니다.
Excel WBS가 우리를 힘들게 하는 7가지 이유
1. 분산 버전 관리 문제
Git의 분산 버전 관리 개념을 파일 기반 WBS에 적용해보면:
# Git 브랜치 모델
main (production WBS)
├── feature/김팀장-일정수정
├── feature/박대리-담당자변경
└── feature/이과장-예산조정
# Excel "브랜치" 모델
WBS_원본.xlsx
├── WBS_김팀장수정.xlsx
├── WBS_박대리수정.xlsx
└── WBS_이과장수정.xlsx
Git에서는 git merge로 변경사항을 통합하지만, Excel에서는 수동 병합만 가능합니다.
더 심각한 문제는 Merge Conflict 감지 불가입니다. 같은 셀을 두 명이 수정해도 경고가 없어 데이터 손실이 발생합니다.
2. 동시성 제어 메커니즘 부재
데이터베이스의 ACID 속성 관점에서 Excel을 분석해보면:
Atomicity(원자성): ❌ 부분 저장 시 일관성 깨짐
Consistency(일관성): ❌ 동시 수정 시 데이터 무결성 보장 안 됨
Isolation(격리성): ❌ 트랜잭션 격리 없음
Durability(지속성): ⚠️ 로컬 파일 손실 위험
# 동시 편집 시나리오 (Pseudo-code)
class ExcelConcurrencyIssue:
def concurrent_edit_scenario(self):
# Thread A: 김팀장
file_a = open("WBS.xlsx", "r+")
data_a = file_a.read()
data_a.modify("start_date", "2024-01-15") # 30분 소요
file_a.write(data_a) # T+30min
# Thread B: 박대리 (거의 동시 시작)
file_b = open("WBS.xlsx", "r+") # 같은 파일
data_b = file_b.read() # 김팀장 수정 전 버전 읽음
data_b.modify("assignee", "이개발") # 25분 소요
file_b.write(data_b) # T+35min (김팀장 변경사항 덮어씀)
# 결과: 김팀장의 30분 작업 손실
이는 Lost Update Problem의 전형적인 사례입니다.
3. 실시간 데이터 동기화 불가
분산 시스템에서 Eventually Consistent 모델도 지원하지 않는 Excel:
// 이상적인 분산 WBS 시스템
class DistributedWBS {
async updateTask(taskId, changes) {
// 1. Optimistic Locking
const version = await this.getTaskVersion(taskId);
// 2. Conflict Detection
if (await this.hasConflict(taskId, version)) {
return this.resolveConflict(taskId, changes);
}
// 3. Atomic Update
await this.atomicUpdate(taskId, changes, version + 1);
// 4. Event Broadcasting
this.broadcastChange(taskId, changes);
}
}
// Excel의 현실
class ExcelWBS {
updateTask(taskId, changes) {
// 1. 파일 열기 (다른 사람이 열고 있는지 모름)
// 2. 수정 (충돌 감지 안 됨)
// 3. 저장 (이전 변경사항 덮어쓰기)
// 4. 이메일로 공유 (수동)
}
}
결과: 데이터 일관성을 보장할 수 없는 시스템
4. 자동화 제로
=IF(D2="완료",E2,IF(D2="진행중",E2*0.5,0))
=SUMIF(C:C,G2,E:E)
=VLOOKUP(A2,Sheet2!A:F,3,FALSE)
# 매번 수동으로 수식 복사, 붙여넣기, 수정...
# 한 셀 잘못 건드리면 #REF! 에러 파티 🎉
=IF(D2="완료",E2,IF(D2="진행중",E2*0.5,0))
=SUMIF(C:C,G2,E:E)
=VLOOKUP(A2,Sheet2!A:F,3,FALSE)
# 매번 수동으로 수식 복사, 붙여넣기, 수정...
# 한 셀 잘못 건드리면 #REF! 에러 파티 🎉
5. 협업 = 이메일 폭탄
월요일 이메일함
- 📧 "WBS 최신 버전입니다" - 09:00
- 📧 "RE: WBS 수정했습니다" - 10:30
- 📧 "RE: RE: WBS 제가 다시 수정" - 11:00
- 📧 "RE: RE: RE: 어느 버전이 최신?" - 14:00
- 📧 "긴급: WBS 충돌났습니다" - 16:00
- 📧 "최종: 이게 진짜 최종" - 18:00
6. 통계는 수작업
번다운 차트 만들기:
- 데이터 범위 선택 (5분)
- 차트 삽입 (2분)
- 서식 조정 (10분)
- 매일 반복... 😫
7. 모바일? 그게 뭔가요?
🚀 현대적 협업 시스템의 아키텍처
CRDT (Conflict-free Replicated Data Types) 기반 해결
Google Docs, Figma 등이 사용하는 CRDT 알고리즘을 WBS 관리에 적용하면:
// CRDT 기반 실시간 WBS 동기화
class CRDTBasedWBS {
constructor() {
this.state = new YMap(); // Yjs CRDT implementation
this.setupRealtimeSync();
}
updateTask(taskId, field, value) {
// 1. 로컬에서 즉시 적용
this.state.get(taskId).set(field, value);
// 2. 자동으로 다른 클라이언트에 전파
// 3. 충돌 시 자동 해결 (CRDT 알고리즘)
// 4. 일관성 보장
}
setupRealtimeSync() {
this.state.observe(event => {
// 변경사항을 실시간으로 UI에 반영
this.updateUI(event.target, event.changes);
});
}
}
WebSocket 기반 실시간 아키텍처
분산 시스템 설계 원칙 적용
실시간 협업의 마법: "마치 한 사무실에 있는 것 같아요"
현대적 프로젝트 관리 도구의 핵심은 실시간 협업입니다. Google Docs를 사용해보신 적 있으신가요? 여러 사람이 동시에 문서를 편집해도 충돌하지 않고, 실시간으로 변경사항이 나타나는 그 경험 말이에요.
Plexo는 바로 그런 경험을 프로젝트 관리에서 제공합니다.
🎬 실제 협업 시나리오
오전 10시: 서울의 김PM이 새 작업을 추가합니다.
오전 10시 3초: 부산의 박개발자 화면에 즉시 새 작업이 나타납니다.
오전 10시 5초: 박개발자가 자신을 담당자로 지정합니다.
오전 10시 8초: 김PM 화면에 박개발자의 아바타가 해당 작업에 표시됩니다.
충돌도 없고, 기다릴 필요도 없고, 메일로 주고받을 필요도 없습니다. 마치 같은 화이트보드를 보고 있는 것처럼 자연스럽죠.
📊 실제 변화의 숫자들
C사에서 Plexo 도입 후 측정한 결과입니다:
- 버전 충돌: 주 12건 → 0건
- 파일 찾는 시간: 일 37분 → 0분
- 상황 파악 시간: 일 45분 → 3분
- 팀 만족도: 5.2 → 8.7 (10점 만점)
🎯 도구 선택 가이드
당신에게 맞는 도구 찾기
도구별 상세 비교
| 기준 | Excel | Google Sheets | Jira | Asana | MS Project | Plexo |
|---|---|---|---|---|---|---|
| 실시간 협업 | ❌ | ✅ | ⚠️ | ✅ | ❌ | ✅ |
| WBS 구조 | ✅ | ⚠️ | ❌ | ⚠️ | ✅ | ✅ |
| 자동 계산 | ⚠️ | ⚠️ | ✅ | ✅ | ✅ | ✅ |
| 번다운 차트 | 수동 | 수동 | ✅ | ✅ | ✅ | ✅ |
| 모바일 | ❌ | ✅ | ✅ | ✅ | ⚠️ | ✅ |
| 학습 곡선 | 낮음 | 낮음 | 높음 | 중간 | 매우 높음 | 낮음 |
| 가격 | $5/월 | 무료 | $7.75/월 | $10.99/월 | $55/월 | $29/월 |
| 추천 대상 | 1인 | 소규모 | 개발팀 | 마케팅 | 대기업 | WBS 중심 |
🔄 마이그레이션 전략
Phase 1: 파일럿 프로젝트 (2주)
Week 1: 준비
- 월: 도구 선정 및 계정 생성
- 화: 팀 교육 (1시간 세션)
- 수: Excel WBS 임포트
- 목: 기본 설정 완료
- 금: 팀 피드백 수집
Week 2: 실전
- 월-목: 실제 프로젝트 운영
- 금: 평가 및 결정
Phase 2: 단계별 전환 (1개월)
Phase 3: 체인지 관리
const changeManagement = {
저항극복: {
'변화 거부': '점진적 도입, 충분한 교육',
'학습 부담': '챔피언 유저 지정, 멘토링',
'기존 방식 고수': '병행 운영 후 점진적 전환',
인센티브: {
early_adopter: '얼리어답터 배지',
first_project: '첫 프로젝트 완료 보상',
knowledge_sharing: '지식 공유 포인트',
성공지표: {
adoption_rate: '> 80%',
user_satisfaction: '> 4.0/5.0',
efficiency_gain: '> 30%',
};
💰 ROI 계산기
숨은 비용 vs 실제 이익
def calculate_roi(team_size=10, hourly_rate=50):
# Excel의 숨은 비용 (월간)
excel_costs = {
"버전 관리 혼란": team_size * 2 * hourly_rate, # 주당 2시간 낭비
"수동 업데이트": team_size * 3 * hourly_rate, # 주당 3시간
"회의 시간": team_size * 1 * hourly_rate, # 주당 1시간 추가
"재작업": team_size * 2 * hourly_rate, # 오류로 인한 재작업
}
monthly_waste = sum(excel_costs.values()) * 4 # 4주
# 도구 비용
tool_cost = team_size * 29 # Plexo 기준
# 월간 절감액
monthly_savings = monthly_waste - tool_cost
return {
"숨은 비용": f"${monthly_waste:,}/월",
"도구 비용": f"${tool_cost}/월",
"순 절감액": f"${monthly_savings:,}/월",
"연간 이익": f"${monthly_savings * 12:,}/년",
"ROI": f"{(monthly_savings / tool_cost * 100):.0f}%"
}
# 10명 팀 기준
result = calculate_roi(10, 50)
print(f"연간 절감: {result['연간 이익']}") # $187,680/년
생산성 개선 효과
🎬 전환 성공 사례
실제 성공 사례: "Excel 지옥에서 탈출한 B사의 기적"
B사는 5명 규모의 마케팅 에이전시입니다. 3개 프로젝트를 동시에 진행하면서 Excel로 일정을 관리했는데, 매주 2번씩 "버전 충돌 사태"가 발생했습니다.
전환의 결심
프로젝트 매니저 최씨는 더 이상 참을 수 없었다고 말합니다:
"클라이언트 미팅에서 진행률을 물어봤는데, 최신 파일이 뭔지 몰라서 5분 동안 파일을 뒤지고 있었어요. 그 순간 정말 창피했습니다."
극적인 변화
Plexo 도입 후 겨우 1주일 만에 팀 분위기가 완전히 바뀌었습니다:
Day 1: 계정 생성과 Excel 파일 자동 임포트 (10분 소요)
Day 2: 첫 실시간 협업 경험 - "우와! 이게 되네요!"
Day 3: 팀 전체 교육 (30분) - "생각보다 쉽네요"
Day 7: 팀 회식에서 "다시는 Excel로 돌아가지 말자" 다짐
1개월 후의 놀라운 결과
- ✅ 버전 충돌: 주 2회 → 0회
- ✅ 회의 시간: 주 10시간 → 5시간 (50% 감소)
- ✅ 프로젝트 정시 완료율: 40% → 85%
- ✅ 팀 만족도: 5.2 → 9.2 (10점 만점)
"이제 클라이언트가 갑자기 현황을 물어봐도 자신 있게 답할 수 있어요. 모든 게 실시간으로 업데이트되거든요." - 최PM
에이전시 C사: 다중 도구 통합
⚡ Quick Start Guide
30분 안에 시작하기
🚀 즉시 실행 체크리스트
Step 1: 도구 선택 (5분)
- □ 팀 규모 확인
- □ 예산 검토
- □ 무료 체험 신청
Step 2: 셋업 (10분)
- □ 계정 생성
- □ 팀원 초대
- □ 기본 프로젝트 생성
Step 3: 데이터 이관 (10분)
- □ Excel 파일 준비
- □ Import 실행
- □ 구조 검증
Step 4: 첫 협업 (5분)
- □ 실시간 편집 테스트
- □ 코멘트 기능 사용
- □ 자동 저장 확인
🎉 축하합니다! Excel 지옥에서 탈출하셨습니다!
도구별 시작 링크
무료 시작
- Google Sheets - 지금 바로
- Notion - 개인 무료
무료 체험
🎯 결론: 더 이상 미루지 마세요
Excel WBS를 고집하는 비용
# 1년 후 누적 손실
team_size = 10
hourly_rate = 50
yearly_loss = team_size * hourly_rate * 8 * 52 # 주당 8시간 낭비
print(f"연간 손실: ${yearly_loss:,}") # $208,000
print("이 돈으로 할 수 있는 것:")
print("- 개발자 1명 추가 고용")
print("- 팀 전체 최신 장비 업그레이드")
print("- 연 2회 팀 워크샵")
오늘이 바로 그날
💬 마지막 한마디
"우리는 항상 이렇게 해왔어"는 가장 위험한 문장입니다.
Excel은 훌륭한 도구입니다.
하지만 팀 협업을 위해 만들어진 도구는 아닙니다.
망치로 나사를 박을 수는 있지만,
드라이버를 쓰는 게 더 현명하지 않을까요?
당신의 팀은 더 나은 도구를 사용할 자격이 있습니다.
🔄 마이그레이션 전략: 파일에서 시스템으로
점진적 전환 아키텍처
Excel에서 현대적 WBS 시스템으로의 전환은 Strangler Fig Pattern을 적용할 수 있습니다:
interface MigrationStrategy {
phase1: "Excel 파일 Import/Export 지원";
phase2: "하이브리드 운영 (Excel + Web)";
phase3: "완전 Web 기반으로 전환";
rollback: "언제든 Excel로 되돌리기 가능";
}
class ExcelMigration {
// Phase 1: 기존 Excel 파일을 구조화된 데이터로 변환
async importExcelWBS(file: File): Promise<WBSStructure> {
const workbook = XLSX.read(await file.arrayBuffer());
const worksheet = workbook.Sheets[workbook.SheetNames[0]];
return this.parseWBSStructure(worksheet);
}
// Phase 2: 언제든 Excel로 내보내기 가능
async exportToExcel(wbs: WBSStructure): Promise<Blob> {
const workbook = XLSX.utils.book_new();
const worksheet = this.createWorksheet(wbs);
XLSX.utils.book_append_sheet(workbook, worksheet, "WBS");
return XLSX.writeFile(workbook, "project_wbs.xlsx");
}
}
기술 스택 비교
| 측면 | Excel | 현대적 WBS 시스템 |
|---|---|---|
| 동시성 | File Locking | CRDT + OT |
| 버전 관리 | 파일명 기반 | Git-like versioning |
| 실시간성 | 없음 | WebSocket + SSE |
| 확장성 | O(n²) | O(log n) |
| 백업 | 수동 | 자동 + 클라우드 |
| API | 없음 | RESTful + GraphQL |
아키텍처 결정 기록 (ADR)
# ADR-001: WBS 관리 시스템 아키텍처
## 상태: 승인됨
## 컨텍스트
- 기존 Excel 기반 WBS는 동시 편집, 버전 관리, 실시간 동기화 한계
- 팀 규모 확장 시 O(n²) 복잡도로 관리 불가능
- 분산 팀 협업 요구사항 증가
## 결정
- CRDT 기반 실시간 동기화
- WebSocket을 통한 양방향 통신
- Event Sourcing으로 변경 이력 추적
- RESTful API로 확장성 보장
## 결과
- 동시 편집 충돌 문제 해결
- 실시간 협업 가능
- 확장 가능한 아키텍처
# ADR-001: WBS 관리 시스템 아키텍처
## 상태: 승인됨
## 컨텍스트
- 기존 Excel 기반 WBS는 동시 편집, 버전 관리, 실시간 동기화 한계
- 팀 규모 확장 시 O(n²) 복잡도로 관리 불가능
- 분산 팀 협업 요구사항 증가
## 결정
- CRDT 기반 실시간 동기화
- WebSocket을 통한 양방향 통신
- Event Sourcing으로 변경 이력 추적
- RESTful API로 확장성 보장
## 결과
- 동시 편집 충돌 문제 해결
- 실시간 협업 가능
- 확장 가능한 아키텍처
🛠️ 기술적 구현 고려사항
1. 데이터 모델링
WBS의 계층 구조를 효율적으로 저장하기 위한 모델:
-- Adjacency List Model (단순하지만 쿼리 복잡)
CREATE TABLE tasks (
id UUID PRIMARY KEY,
parent_id UUID REFERENCES tasks(id),
name VARCHAR(255),
start_date DATE,
due_date DATE,
assignee_id UUID
);
-- Nested Set Model (쿼리 효율적이지만 업데이트 복잡)
CREATE TABLE tasks (
id UUID PRIMARY KEY,
lft INTEGER,
rgt INTEGER,
level INTEGER,
name VARCHAR(255)
);
2. 실시간 동기화 구현
// Operational Transform 기반 충돌 해결
class OperationalTransform {
transform(op1, op2) {
// 동시에 발생한 두 연산을 변환하여
// 모든 클라이언트에서 같은 결과 보장
if (op1.type === 'insert' && op2.type === 'insert') {
return this.transformInsertInsert(op1, op2);
}
// ... 다른 연산 조합들
}
}
// Operational Transform 기반 충돌 해결
class OperationalTransform {
transform(op1, op2) {
// 동시에 발생한 두 연산을 변환하여
// 모든 클라이언트에서 같은 결과 보장
if (op1.type === 'insert' && op2.type === 'insert') {
return this.transformInsertInsert(op1, op2);
}
// ... 다른 연산 조합들
}
}
🎯 도구 선택 가이드: 기술적 요구사항 기반
평가 매트릭스
class ToolEvaluation:
def evaluate_wbs_tools(self):
criteria = {
'real_time_sync': 0.3, # 실시간 동기화
'scalability': 0.25, # 확장성
'api_support': 0.2, # API 지원
'data_export': 0.15, # 데이터 이식성
'customization': 0.1 # 커스터마이징
}
tools = {
'google_sheets': {'real_time_sync': 8, 'scalability': 6, 'api_support': 9},
'notion': {'real_time_sync': 7, 'scalability': 7, 'api_support': 8},
'jira': {'real_time_sync': 5, 'scalability': 9, 'api_support': 9},
'modern_wbs_tools': {'real_time_sync': 9, 'scalability': 8, 'api_support': 9}
}
return self.calculate_scores(tools, criteria)
class ToolEvaluation:
def evaluate_wbs_tools(self):
criteria = {
'real_time_sync': 0.3, # 실시간 동기화
'scalability': 0.25, # 확장성
'api_support': 0.2, # API 지원
'data_export': 0.15, # 데이터 이식성
'customization': 0.1 # 커스터마이징
}
tools = {
'google_sheets': {'real_time_sync': 8, 'scalability': 6, 'api_support': 9},
'notion': {'real_time_sync': 7, 'scalability': 7, 'api_support': 8},
'jira': {'real_time_sync': 5, 'scalability': 9, 'api_support': 9},
'modern_wbs_tools': {'real_time_sync': 9, 'scalability': 8, 'api_support': 9}
}
return self.calculate_scores(tools, criteria)
🔧 Plexo: 엔지니어가 설계한 WBS 시스템
기술적 특징
아키텍처:
- Frontend: Vue 3 + TypeScript (타입 안전성)
- Backend: NestJS + PostgreSQL (확장 가능한 API)
- 실시간 동기화: Yjs CRDT (Google Docs와 동일한 기술)
- 배포: Docker + Kubernetes (클라우드 네이티브)
핵심 기능:
- RESTful API 완전 지원
- WebSocket 실시간 동기화
- Git-like 변경 이력 추적
- Excel Import/Export (마이그레이션 지원)
개발자 친화적:
- OpenAPI 스펙 제공
- SDK 및 CLI 도구
- Webhook 지원
- 커스터마이징 가능한 UI
소프트웨어 엔지니어링 관점에서 프로젝트 관리 도구를 평가해보는 것도 의미가 있습니다.
#SoftwareEngineering #DistributedSystems #CRDT #ProjectManagement
