비동기 커뮤니케이션으로 생산성 2배 올리기

"이거 회의로 해결할까요?"

이 질문을 하기 전에, 한 번 더 생각해보세요.

동기 커뮤니케이션(회의): 모두 같은 시간에, 같은 장소에서 대화
비동기 커뮤니케이션(문서): 각자의 시간에, 자신의 페이스로 참여

생산성 차이:

• 회의 중심 팀: 의사결정까지 평균 7일
• 비동기 중심 팀: 의사결정까지 평균 2-3일

효율성 증가: 2-3배

처음엔 회의가 빠를 것 같았는데,
막상 진행하니 모두의 일정을 맞추느라 일주일이 걸립니다.
비동기로 하면 각자 시간에 참여할 수 있어서 훨씬 빠릅니다.

이 글에서는 비동기 커뮤니케이션을 체계적으로 구축하는 방법을 다룹니다.

1. 비동기 커뮤니케이션의 원칙

1.1 핵심 원칙

원칙 1: 기록 우선(Documentation First)

동기: 회의 → 의도하지 않은 결정 → 기록 부실
비동기: 문서 작성 → 피드백 수집 → 완벽한 기록

원칙 2: 캡처 가능(Capturable)

회의: 말한 것 vs 기억하는 것이 다름
문서: 명확한 텍스트로 기록됨

원칙 3: 검색 가능(Searchable)

회의: "누가 이걸 말했어?" → 찾을 수 없음
문서: 검색으로 즉시 찾음

1.2 비동기 시스템 구축

4계층 비동기 시스템:

1. 의사결정 문서 (Layer 1)

   • 도구: Confluence
   • 목적: 모든 중요 의사결정 기록
   • 보관: 영구

2. 진행 중인 작업 (Layer 2)

   • 도구: GitHub / Linear
   • 목적: 작업 진행도, 코멘트
   • 보관: 프로젝트 종료 후 1년

3. 빠른 업데이트 (Layer 3)

   • 도구: Slack / Teams
   • 목적: 즉각적인 소통
   • 보관: 7일

4. 실시간 (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 피드백 프로세스:

1. 인지 단계 (24시간): 모든 관심사 보고, Slack 공지
2. 리뷰 단계 (3일): 상세 리뷰 및 질문, 문서 코멘트
3. 정리 단계 (1일): 저자가 피드백 정리, 문서 업데이트
4. 결정 단계 (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 잠재적 문제와 해결책

주요 도전과 해결책:

1. 긴급성 부족

   • 문제: 중요한 것도 우선순위 안 됨
   • 해결: SLA 설정 (긴급: 2시간, 높음: 24시간, 일반: 72시간)

2. 커뮤니케이션 격차

   • 문제: 누군가 빠지면 정보 불일치
   • 해결: 모든 결정을 위키에 기록, 월 1회 감사

3. 시간대 문제

   • 문제: 글로벌 팀은 항상 누군가 기다려야 함
   • 해결: 비동기 우선, 매주 1회 동기 미팅, Timezone 순환

4. 관계 형성

   • 문제: 비동기로는 친분 형성 어려움
   • 해결: 월간 전사 회의 (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배

오늘부터 시작하세요:

1. RFC 템플릿 만들기
2. Confluence 세팅
3. 첫 RFC 작성
4. 팀 교육

작은 변화가 큰 차이를 만듭니다.

---

비동기 커뮤니케이션을 지원하는 프로젝트 관리 도구가 필요하신가요? Plexo를 확인해보세요.