"이거 회의로 해결할까요?"
이 질문을 하기 전에, 한 번 더 생각해보세요.
동기 커뮤니케이션(회의): 모두 같은 시간에, 같은 장소에서 대화
비동기 커뮤니케이션(문서): 각자의 시간에, 자신의 페이스로 참여
생산성 차이:
- 회의 중심 팀: 의사결정까지 평균 7일
- 비동기 중심 팀: 의사결정까지 평균 2-3일
효율성 증가: 2-3배
처음엔 회의가 빠를 것 같았는데,
막상 진행하니 모두의 일정을 맞추느라 일주일이 걸립니다.
비동기로 하면 각자 시간에 참여할 수 있어서 훨씬 빠릅니다.
이 글에서는 비동기 커뮤니케이션을 체계적으로 구축하는 방법을 다룹니다.
1. 비동기 커뮤니케이션의 원칙
1.1 핵심 원칙
원칙 1: 기록 우선(Documentation First)
동기: 회의 → 의도하지 않은 결정 → 기록 부실
비동기: 문서 작성 → 피드백 수집 → 완벽한 기록
원칙 2: 캡처 가능(Capturable)
회의: 말한 것 vs 기억하는 것이 다름
문서: 명확한 텍스트로 기록됨
원칙 3: 검색 가능(Searchable)
회의: "누가 이걸 말했어?" → 찾을 수 없음
문서: 검색으로 즉시 찾음
1.2 비동기 시스템 구축
4계층 비동기 시스템:
의사결정 문서 (Layer 1)
- 도구: Confluence
- 목적: 모든 중요 의사결정 기록
- 보관: 영구
진행 중인 작업 (Layer 2)
- 도구: GitHub / Linear
- 목적: 작업 진행도, 코멘트
- 보관: 프로젝트 종료 후 1년
빠른 업데이트 (Layer 3)
- 도구: Slack / Teams
- 목적: 즉각적인 소통
- 보관: 7일
실시간 (Layer 4)
- 도구: Video call
- 목적: 긴급 문제 해결만
- 보관: 기록만 보관
정보 유지율:
- 대화: 70% 잃어버림 (48시간 후)
- 회의록: 40% 잃어버림 (1주일 후)
- 문서화: 90% 유지됨 (영구 참조 가능)
- 검색 가능한 문서: 95% 유지됨 (검색으로 찾음)
생산성 영향도 (팀 10명 기준, 월간):
- 정보 찾는 시간 절감: 100시간
- 중복 설명 제거: 50시간
- 문맥 전환 감소: 75시간
- 총 절감: 225시간 (약 28일)
2. 의사결정 문서 작성법
2.1 RFC (Request For Comments) 템플릿
# RFC: 마이크로서비스 아키텍처 전환
## 1. 개요 (2문장)
우리의 모놀리식 아키텍처를 마이크로서비스로 전환합니다.
이를 통해 배포 속도를 3배로 높이고 장애 영향을 축소할 수 있습니다.
## 2. 동기 (왜 지금?)
- 현재 배포 시간: 4시간 (전체 팀이 기다려야 함)
- 장애 발생 시 전체 시스템 영향
- 팀 확장의 병목
## 3. 제안된 솔루션
- 현재: Monolith
- 제안: Microservices (마크로로 3-5개 서비스)
## 4. 대안 검토
| 옵션 | 장점 | 단점 | 비용 |
| ---------------- | ----------- | ----------- | ---- |
| Monolith 유지 | 운영 간단 | 확장 어려움 | 낮음 |
| Microservices | 높은 확장성 | 운영 복잡 | 높음 |
| Modular Monolith | 균형 | 학습곡선 | 중간 |
**권장**: Microservices (높은 성장 예상)
## 5. 구현 계획
- Phase 1: 인프라 준비 (2주)
- Phase 2: 첫 마이크로서비스 이전 (4주)
- Phase 3: 나머지 서비스 이전 (8주)
## 6. 리스크 및 완화
| 리스크 | 영향 | 완화 방안 |
| ----------- | ---- | -------------- |
| 배포 실패 | 높음 | 블루-그린 배포 |
| 성능 저하 | 높음 | 로드 테스팅 |
| 팀 학습곡선 | 중간 | 교육 프로그램 |
## 7. 메트릭
- 성공 지표: 배포 시간 < 30분
- 모니터링: 서비스 간 지연시간 < 100ms
- 실패 기준: 장애 빈도 증가
## 승인 프로세스
- [ ] 기술 팀 검토 (by 월)
- [ ] PM 검토 (by 화)
- [ ] 경영진 승인 (by 수)
## 피드백 기간
이 RFC는 5일간 피드백을 수집합니다 (화-토).
2.2 의사결정 기록(Decision Record) 템플릿
# ADR-001: 데이터베이스로 PostgreSQL 선택
## 상태: 승인됨 (2025-01-20)
## 문제
어떤 데이터베이스를 사용할 것인가?
- 성능: 높은 처리량 필요
- 비용: 제한된 예산
- 팀 역량: SQL 경험 있음
## 고려한 옵션
### Option 1: PostgreSQL
- 장점: 오픈소스, 높은 안정성, 비용 낮음
- 단점: 수평확장 복잡
### Option 2: MongoDB
- 장점: 수평확장 용이
- 단점: 비용 높음 (클라우드), 스키마 관리 어려움
### Option 3: DynamoDB
- 장점: 완전 관리형, 수평확장 자동
- 단점: 비용 높음, 쿼리 제약 많음
## 결정
**PostgreSQL을 선택합니다.**
### 이유
1. 비용: 연간 $5k vs MongoDB $15k vs DynamoDB $20k
2. 팀 역량: SQL 경험 풍부
3. 성능: 향후 3년 예상 처리량 충분
4. 수평확장: Read replica로 충분
## 영향도
- 개발: 친숙한 기술 → 개발 속도 빠름
- 운영: 관리 책임 증가 (클라우드 RDS 사용으로 완화)
- 비용: 연간 $5k 절감
## 되돌리기 계획
MongoDB로 변경 필요시:
- 마이그레이션 비용: $50k
- 마이그레이션 기간: 3주
- 트리거: 처리량 초과 (예: 초당 100,000 요청)
## 검토 일정
6개월 후 (2025-07-20) 재검토
3. 비동기 피드백 수집
3.1 효과적인 피드백 수집
RFC 피드백 프로세스:
- 인지 단계 (24시간): 모든 관심사 보고, Slack 공지
- 리뷰 단계 (3일): 상세 리뷰 및 질문, 문서 코멘트
- 정리 단계 (1일): 저자가 피드백 정리, 문서 업데이트
- 결정 단계 (1일): PM 최종 결정, 문서 승인
피드백 품질 기준:
- 낮은 복잡도: 3-5개 피드백 = 적절, 6개 이상 = 충분
- 높은 복잡도: 6-10개 피드백 = 적절, 11개 이상 = 충분
참여 활성화:
- 조용한 참여자에게 의견 요청
- 간단한 양식 제공 (찬성/반대/의견)
- 모든 피드백 감사 메시지
- 피드백으로 인한 변화 공유
- 공개 댓글로 투명성 높임
3.2 피드백 요청 메시지 작성
좋은 예:
이 기술 선택 RFC에 대한 의견을 부탁드립니다.
특히 다음 관점에서의 피드백을 기대합니다:
1. 개발팀: 구현 난이도, 필요한 기술 교육
2. 운영팀: 운영 복잡도, 모니터링 방안
3. PM: 일정 영향도, 비용
4. 보안: 보안 영향도
피드백 제출 마감: 목요일 17:00
나쁜 예:
의견 주세요.
4. 비동기 도구 활용
4.1 도구별 최적 활용
주요 비동기 도구:
- Confluence: RFC, 설계 문서, 아키텍처 결정 (영구 보관, 검색 우수, 24-72시간 응답)
- GitHub/GitLab: 코드 리뷰, 기술 결정, 이슈 (영구 보관, 검색 우수, 4-24시간 응답)
- Google Docs: 초안 작성, 협업, 빠른 결정 (1년 보관, 검색 양호, 1-8시간 응답)
- Slack: 빠른 질문, 공지, 긴급 항목 (7일 보관, 검색 보통, 1시간 이내 응답)
시나리오별 도구 선택:
- 아키텍처 결정: Confluence (영구 기록)
- 코드 리뷰: GitHub Pull Request
- 빠른 설계 피드백: Google Docs
- 긴급 블로커: Slack thread
- 정책 결정: Confluence + GitHub issue
5. 비동기 회의 폐지 전략
5.1 회의 → 비동기 전환
Before (동기):
월-금: 각 팀별 회의 15개/주
시간: 주 20시간
효율: 30% (3일 지연)
After (비동기):
월-금: RFC 기반 결정
시간: 주 5시간 (긴급만 동기)
효율: 85% (24시간 내 결정)
효과:
- 시간: 75% 절감
- 효율: 180% 향상 (3배 빠름)
- 문서화: 100% vs 30%
5.2 전환 프로세스
Week 1-2: "Async-First" 정책 도입
- 모든 결정은 문서 기반 RFC로
- 회의는 "긴급" 또는 "복잡한 토론"만
- 모든 팀원에게 교육
Week 3-4: 시범 운영
- 일부 회의를 비동기로 전환
- 문제점 식별 및 개선
Week 5+: 전사 확대
- 비동기 문화 정착
6. 비동기 커뮤니케이션의 과제
6.1 잠재적 문제와 해결책
주요 도전과 해결책:
긴급성 부족
- 문제: 중요한 것도 우선순위 안 됨
- 해결: SLA 설정 (긴급: 2시간, 높음: 24시간, 일반: 72시간)
커뮤니케이션 격차
- 문제: 누군가 빠지면 정보 불일치
- 해결: 모든 결정을 위키에 기록, 월 1회 감사
시간대 문제
- 문제: 글로벌 팀은 항상 누군가 기다려야 함
- 해결: 비동기 우선, 매주 1회 동기 미팅, Timezone 순환
관계 형성
- 문제: 비동기로는 친분 형성 어려움
- 해결: 월간 전사 회의 (1시간, 사회적 목적만)
비동기 우선 정책:
- 기본 커뮤니케이션: 비동기 (문서 기반)
- 동기 예외: 위기 상황, 민감한 주제, 복잡한 토론
- 가이드라인: 응답 SLA 설정, 모든 결정 영구 기록, 기본 공개
7. 측정 및 개선
비동기 커뮤니케이션 효과 측정:
- 의사결정 속도: 7일 → 2-3일 (60-70% 개선)
- 문서화 완성도: 40% → 95% (137% 개선)
- 회의 시간: 주 20시간 → 5시간 (75% 절감)
- 팀 만족도: 6.2/10 → 8.1/10 (30% 향상)
핵심 정리
비동기 커뮤니케이션 도입으로:
- 의사결정 60% 빨라짐
- 문서화 95% 완성도
- 회의 시간 75% 절감
- 팀 만족도 30% 향상
생산성 2배 달성 = 개발자 능력 2배
오늘부터 시작하세요:
- RFC 템플릿 만들기
- Confluence 세팅
- 첫 RFC 작성
- 팀 교육
작은 변화가 큰 차이를 만듭니다.
비동기 커뮤니케이션을 지원하는 프로젝트 관리 도구가 필요하신가요? Plexo를 확인해보세요.
