# 글로벌 팀의 원격 근무 문화 마스터하기

> 10개 시간대, 7년, 하나의 규칙: 기록되지 않으면 일어나지 않은 것이다. 비동기 우선 업무 실전 가이드.
>
> 2024-03-12 — y7.hk

## Zoom 콜 그 이상

원격 근무는 사무실 회의를 Zoom으로 옮기는 게 아니다. 진짜 원격 근무는 비동기 커뮤니케이션과 엄격한 문서화에 크게 의존한다.

시간대를 넘나들며 일할 때는 던진 질문이 12시간 후에야 답을 받을 수 있다고 가정하라. 이 제약이 더 나은 이슈, 더 명확한 RFC, 더 완성도 높은 풀 리퀘스트를 강요한다.

나는 7년간 거의 직접 만나지 못한 사람들과 제품을 만들었다 — 10개가 넘는 시간대에 걸쳐. 유럽과 아시아로 갈라진 크립토 멀티시그 팀부터, 지금 동남아시아에서 이 사이트와 여러 텔레그램 봇을 혼자 운영하는 일까지. 그동안 67개국에서 살았다 — 다르게 말하면 키르기스스탄의 밴 안에서 다이얼업 수준의 연결을 포함해 거의 모든 조건에서 원격 근무를 테스트해봤다.

실제로 효과가 있었던 것들은 이렇다.

## 비동기 우선은 도구가 아니라 규율이다

모두가 "비동기"라고 말한다. 그런데 그들의 Slack을 보면 "잠깐 질문" 핑의 벽과 끝나지 않은 스레드뿐이다. 비동기 우선은 더 엄격한 것을 의미한다:

- **모든 결정이 문서 산출물을 낳는다.** 내 팀의 규칙: 결정은 24시간 안에 기록되어야 한다 — 이슈 트래커, RFC, 프로젝트 문서 중 어디든. 기록되지 않으면 일어나지 않은 것이다.
- **DM이 아니라 채널이 기본.** 다이렉트 메시지는 맥락이 죽는 곳이다. 공개 채널에서 질문하면 답은 다음 사람이 검색할 수 있다.
- **응답 시간 기대치가 명시적.** 우리 기준: 블로커는 같은 영업일, 나머지는 24~48시간. 누구도 온라인 상태를 기대받지 않는다. 이것이 초록 점과 "그냥 확인해봤어"의 불안 극장을 없앤다.

24시간 규칙은 관료적으로 들린다 — 신입이 3개월 된 RFC를 찾아 왜 그런 결정이 내려졌는지 정확히 이해할 때까지. 그때 비로소 값어치를 한다, 보통 첫 달 안에.

## 실제로 실행 가능한 이슈 작성하기

당신이 잠든 지 12시간 후에 깨어나는 동료에게, 모호한 이슈는 하루를 통째로 날리는 비용이다. 그래서 나는 담당자가 나에게 연락할 수 없다고 가정하고 모든 이슈를 쓴다:

- **맥락을 두 문장으로.** 무엇이 깨졌는지 혹은 무엇을 만들며 왜 지금인지.
- **재현 방법 또는 레퍼런스.** 링크, 로그 스니펫, 스크린샷, 이미 해결한 경쟁 제품.
- **완료의 정의.** "더 빠르게"가 아니라 "CI에서 p95 빌드 시간 90초 미만".
- **명시적 비목표.** 가장 과소평가된 한 줄. "이 PR에서 파서를 리팩터링하지 말 것"은 어떤 린터보다 리뷰 사이클을 줄여줬다.

RFC도 같은 대우를 받는다: 문제, 제약, 실제 트레이드오프가 있는 2~3개 옵션, 권고안, 그리고 코멘트 마감일. 마감까지 아무도 반대하지 않으면 권고안이 채택된다. 회의는 필요 없다.

## 시간대 전략: 릴레이를 받아들여라

대부분은 시간대를 문제로 본다. 잘 운영되는 분산 팀은 이를 파이프라인으로 본다 — 릴레이 경주처럼 일이 24시간 순환한다. 하지만 바통 전달은 인수인계가 문서화되어야만 작동한다.

내 규칙:

- **모든 업무 블록을 인수인계 노트로 끝낸다.** 완료된 것, 다음 할 것, 막힌 것. 이슈에 세 줄. 깨어나는 사람이 5분 안에 시작할 수 있어야 한다.
- **겹치는 시간을 찾아 보호한다.** 10시간 이상 차이나면 공유 가능한 낮 시간은 기껏 한 시간. 진짜 동기가 필요한 일에 쓴다: 의견 충돌, 아키텍처 선택, 어려운 피드백.
- **상대방의 명시된 시간 외에는 묻지 않고 회의를 잡지 않는다.** "딱 한 번만"이 사람을 조용히 소진시키는 방법이다.

```text
아직도 쓰는 인수인계 템플릿:
완료:   스키마 마이그레이션 스테이징에 배포됨
다음:   백필 잡 — 실행 준비됨, 승인 필요
막힘:   API 쿼터 증량 (티켓 #4821, 벤더 대기 중)
```

## 문서화를 기본으로

지식이 누군가의 머릿속에만 존재한다면, 팀은 그 지식을 가진 게 아니다 — 의존성을 가진 것이다. 문서는 세 계층을 커버한다:

- **결정** — RFC와 이슈 스레드. 무엇보다 왜를 기록한다.
- **프로세스** — 두 번 이상 하는 모든 것에 런북을: 배포, 롤백, 장애 대응, 온보딩.
- **맥락** — 자기 시간 새벽 2시에 합류한 사람에게도 "우리가 뭘 왜 하는지" 답해주는 프로젝트 문서.

문서는 썩는다. 그래서 문서에는 오너와 리뷰 날짜가 있다. 6개월간 아무도 실행하지 않은 런북은 자산이 아니라 부채다.

## 회의는 예외

동기 시간은 분산 팀의 가장 비싼 자원이다. 돈처럼 써라. 회의를 위한 내 기준:

1. 문서로 해결되지 않은 결정이 있다.
2. 사전에 안건이 공지된다.
3. 참석 못 하는 사람도 기여할 수 있다 — 사전에 코멘트 수집, 후에 노트와 녹화 공유.

나머지는 전부 비동기 업데이트다. 안건에 결정이 없는 "주간 싱크"는 회의가 아니라 캘린더 습관이다. 죽여라.

## 카고 컬트 없는 툴 스택

도구는 그 주변의 규범보다 덜 중요하지만, 최근 몇 번의 세팅에서 살아남은 것들:

- **Linear** — 이슈용. 빠르고, 독단적이며, 기록을 강제한다.
- **Notion** — 문서와 RFC용. 평범한 에디터지만 훌륭한 공유 기억이다.
- **Slack** — 채팅용. 공격적인 채널 규율과 대부분 꺼둔 알림.
- **Loom** — 워크스루용. 3분 화면 녹화가 30분 통화를 대체한다.
- **GitHub** — PR이 곧 문서. 설명은 *무엇*이 아니라 *왜*를 적는다.

스택은 의도적으로 지루하다. 실패 모드는 잘못된 도구를 고르는 게 아니라, 같은 대화를 네 군데에서 나누는 것이다.

## 리모트 퍼스트 vs 리모트 프렌들리

"리모트 프렌들리"는 원격 근무자가 2등 시민임을 의미한다: 결정은 사무실에서 내려지고 이후에 방송된다. "리모트 퍼스트"는 아무도 같은 방을 공유하지 않는다고 가정하고 모든 프로세스를 설계하는 것 — 채용, 리뷰, 기획, 축하 모두. 승진에 "사무실에서 보여야" 한다면, 그건 원격 문화가 아니라 웹캠 달린 사무실이다.

내 테스트: 내일 본사 사무실이 불타버려도 의사결정 방식이 바뀔까? 바뀐다면 너희는 리모트 프렌들리다.

## 외로움 문제

엔지니어링 블로그가 건너뛰는 부분이지만, 원격 근무자가 실제로 퇴사하는 주된 이유다. 나와 내가 관리한 사람들에게 효과가 있던 것:

- **코워킹, 항상.** 장기 체류한 모든 나라에 "내" 코워킹 공간이 있다. 루틴은 기능이다.
- **업무 외 채널.** 반려동물, 음식, 로컬 밋업. 우리 채널은 회사 피벗 두 번을 살아남았다.
- **중요할 때 분기별 대면.** 일주일의 대면 시간은 대략 한 분기의 신뢰를 산다. 상태 업데이트가 아니라 디자인 세션과 저녁 식사에 써라.

## 7년을 살아남은 체크리스트

- [ ] 결정 24시간 안에 기록
- [ ] 질문할 수 없는 사람에게 맞춰 이슈 작성
- [ ] 모든 업무 블록 끝에 인수인계 노트
- [ ] 회의는 안건 + 결정 + 녹화가 있을 때만
- [ ] 문서에 오너와 리뷰 날짜
- [ ] 업무 외 채널 최소 하나는 살아있을 것
- [ ] 겹치는 시간은 상태 보고가 아니라 의견 충돌에 사용

원격 근무는 특전도 위치 정책도 아니다. 운영 체제다 — 그리고 모든 OS처럼, 아무도 보지 않을 때 얼마나 잘 돌아가는지로 평가된다.