"3시에 만나요"가 국경을 넘으면 무너지는 이유
회의 시간은 사실의 절반에 불과합니다. "3시"라는 말은 장소가 붙지 않으면 아무 의미가 없지만, 분산된 팀은 매일 그렇게 말하고는 왜 누군가는 한 시간 일찍 또는 하루 늦게 접속하는지 궁금해합니다. 두 사람이 서로 다른 지역에 앉아 있는 순간, 평범한 시계 시간은 공유된 정보가 아니라 각자 다르게 해석하는 작은 퍼즐이 됩니다.
세 가지 요소가 표준 시간대를 넘나드는 일정 잡기를 조용히 오류 발생 가능하게 만듭니다.
- 시차는 직관적이지 않습니다. 인도는 UTC+5:30, 네팔은 UTC+5:45이며, 호주 일부 지역도 30분 단위 시차를 사용합니다. 정시 단위로만 머릿속 계산을 하면 지구 상당 부분에 대해 틀리게 됩니다.
- 일광 절약 시간제(DST)는 목표를 움직입니다. 두 도시 간의 시차는 고정되어 있지 않습니다. 런던과 뉴욕은 보통 5시간 차이지만, 매년 봄과 가을에 몇 주 동안은 두 지역이 서로 다른 날짜에 시계를 변경하기 때문에 4시간 또는 6시간으로 변동합니다.
- 시간만 표기하면 모호함이 숨겨집니다. 시간대가 없는 "오후 3시"는 추측을 유발합니다. "오후 3시 ET"조차도 시차가 변동하는 주에는 사람들을 혼란스럽게 만듭니다.
이 모든 것은 특별한 경우가 아닙니다. 평범한 일정 잡기이며, 해결책은 구매해야 하는 도구가 아니라 습관입니다.
대부분의 실수를 방지하는 하나의 습관
매번 시간대를 명시하고, 도시 이름을 함께 표기하십시오.
"UTC+1"과 같은 시차는 정확하지만 차갑습니다. 대부분의 사람들은 직관적으로 와닿지 않습니다. 도시 이름은 시차 와 DST 규칙을 자동으로 전달합니다. 왜냐하면 모든 사람이 런던 또는 뉴욕이 대략 어디에 있는지 알기 때문입니다. 따라서 "15:00에 만나요"라고 쓰는 대신 다음과 같이 작성하십시오:
15:00 런던 / 10:00 뉴욕 / 19:30 뭄바이 — 7월 24일 목요일
한 줄로 여러 작업을 동시에 수행합니다. 기준 시간을 명시하고, 다른 참가자들을 위해 변환하며, "어느 오후 3시?"라는 질문을 완전히 제거합니다. 아무도 변환기를 열어 자신이 시간이 되는지 확인할 필요가 없습니다.
몇 가지 지원 관행을 통해 이 방법을 완벽하게 만들 수 있습니다:
- 서면 기록(계약, 출시 시간, 사고 로그)의 경우 UTC로 합의하십시오. UTC는 DST로 인해 절대 변하지 않으므로 "유지보수 기간은 02:00 UTC에 시작됩니다"라는 문구는 12월과 7월에 동일하게 읽힙니다. 각자가 자신의 현지 시간으로 변환하도록 하십시오.
- 사람을 대상으로 하는 메시지에서는 원시 시차보다 도시 이름을 선호하십시오. "17:00 베를린"은 DST 변경 시에도 유효합니다. 반면 "17:00 UTC+2"는 베를린이 10월 말에 UTC+1로 되돌아갈 때 조용히 틀리게 됩니다.
- 보내기 전에 변환 시간을 확인하십시오. 모든 참가자의 도시를 나란히 보여주는 세계 시계을 빠르게 살펴보면 캘린더 초대에서 유명한 한 시간 차이 오류를 잡아낼 수 있습니다. 10초면 충분하며 통화 실패를 방지합니다.
여러 지역에 걸쳐 자주 일정을 잡는다면, 가장 자주 작업하는 시간대 목록이 있는 참조 자료를 열어 두십시오. 현재 시차를 한 곳에서 보고 DST 변경일에 시차가 변하는 것을 지켜보면 추상적인 규칙을 그냥 읽어낼 수 있는 무언가로 바꿔줍니다.
분산된 팀을 위한 겹치는 시간 찾기
일정 잡기가 가장 어려운 팀은 세 대륙에 걸쳐 있는 팀입니다. 일반적인 형태를 생각해 보십시오: 미국 서부 해안의 엔지니어, 서유럽의 제품 팀, 인도의 전달 팀.
북반구 여름 기준 UTC로 표시한 그들의 실제 근무 시간은 다음과 같습니다:
| 위치 | 현지 09:00–17:00의 UTC |
|---|---|
| 미국 서부 해안 (PDT, UTC−7) | 16:00 – 24:00 |
| 서유럽 (CEST, UTC+2) | 07:00 – 15:00 |
| 인도 (IST, UTC+5:30) | 03:30 – 11:30 |
행이 겹치는 부분을 찾아보십시오. 유럽과 인도는 아침부터 오후까지 편안한 시간대(대략 07:00–11:30 UTC)를 공유합니다. 유럽과 미국 서부 해안은 유럽 늦은 오후(16:00–15:00 — 사실상 피크 시간대에는 겹치는 부분이 거의 없으며, 미국 측이 일찍 시작하거나 유럽 측이 늦게까지 남아 있어야만 열립니다)에 얇은 조각을 공유합니다. 인도와 미국 서부 해안은 거의 겹치지 않습니다.
이것이 선을 따라 해가 지지 않는 팀의 불편한 진실입니다: 세 지역 모두가 편안하게 자리에 앉을 수 있는 단 한 시간도 없을 수 있습니다. 가장 좋은 공유 시간대는 대략 15:00–16:00 UTC 정도이며, 이는 캘리포니아의 아침 식사 시간, 유럽의 늦은 오후, 인도의 저녁 시간에 해당합니다. 누군가는 항상 약간의 희생을 감수해야 합니다.
겹치는 시간이 이렇게 좁을 때 실용적인 방법:
- 고통을 분산시키십시오. 주간 전체 회의가 누군가에게 불편을 줘야 한다면, 항상 같은 사람들에게 부담을 주지 말고 어떤 지역이 불편한 시간대를 맡을지 돌아가며 정하십시오.
- 하나의 기준 시간을 보호하십시오. 겹치는 단 한 시간을 선택하고 모든 사람이 실시간으로 참여해야 하는 회의를 위해 그 시간을 강력하게 방어하십시오. 상태 업데이트에 그 시간을 낭비하지 마십시오.
- 시간을 엄격하게 제한하십시오. 사람들이 오전 7시나 오후 9시에 참여할 때, 회의가 길어지는 것은 실제 비용입니다. 안건을 공개하고 정시에 끝내십시오.
겹치는 시간이 없을 때는 비동기 방식으로 전환
팀이 예를 들어 캘리포니아와 인도(12.5시간 차이)에 걸쳐 있다면 사실상 공유 근무 시간이 없습니다. 실시간 회의를 강요하면 누군가는 매주 오후 10시나 오전 6시에 통화를 해야 하며, 이는 지속 가능하지 않습니다.
해결책은 실시간 회의를 기본값으로 취급하는 것을 중단하는 것입니다. 결정을 문서화하여 두 사람이 동시에 깨어 있어야 하는 상황에 의존하지 않도록 하십시오:
- 실시간 발표 대신 짧은 비디오 워크스루를 녹화하십시오. 상대방은 아침에 시청합니다.
- 상태 및 업데이트를 공유 문서나 스레드로 옮겨 각자가 자신의 근무 시간에 읽고 답변하도록 하십시오.
- 실행 중인 "인계" 노트를 사용하여 로그오프하는 지역이 로그온하는 지역에 컨텍스트를 전달할 수 있도록 하십시오.
비동기 작업은 또한 리뷰, 집중 블록 또는 시간 제한이 있는 인계를 위해 서로 다른 지역에서 실행되는 독립적인 타이머의 이점을 얻습니다. 멀티 타이머을 사용하면 누구의 시계인지 머리로 계산하지 않고도 여러 카운트다운을 동시에 추적할 수 있습니다.
비동기 방식으로는 진정으로 할 수 없는 일, 즉 브레인스토밍, 어려운 의견 충돌, 관계 구축을 위해 소중한 겹치는 시간을 아껴 두십시오.
일광 절약 시간제(DST): 당신을 잡는 함정들
DST는 자신감 있는 일정 관리자도 겸손하게 만드는 부분입니다. 규칙은 균일하지 않습니다:
- 미국과 EU는 변경 날짜가 다릅니다. 미국은 3월 중순에 "앞으로" 이동하고 11월 초에 "뒤로" 이동합니다. EU는 3월 마지막 일요일과 10월 마지막 일요일에 변경됩니다. 1년에 두 번, 몇 주 동안 뉴욕-런던 시차는 평소 5시간이 아닙니다.
- 남반구는 반대입니다. 북반구가 앞으로 이동할 때 호주, 칠레 같은 곳은 뒤로 이동합니다. 그들의 겨울은 당신의 여름이며, 그들의 시계는 반대 방향으로 움직입니다.
- 많은 곳은 전혀 변경하지 않습니다. 인도, 중국을 포함한 아시아 대부분과 적도 주변 전체 지역은 일년 내내 고정된 시차를 유지합니다. 일본은 절대 변경하지 않습니다. 애리조나(대부분)도 변경하지 않는 반면, 미국 산악 시간대의 나머지 지역은 변경합니다.
결론은 모든 규칙을 외우라는 것이 아닙니다. 두 도시 간의 시차가 일정하다고 가정하지 말고, 3월, 10월, 11월의 변경 주변 주에 시차를 다시 확인하라는 것입니다. 이것이 바로 원시 시차보다 도시 이름이 나은 이유입니다. 규칙을 알고 있는 도구는 올바른 날짜에 올바른 시차를 보여주므로 직접 계산할 필요가 없습니다.
실용적인 발송 전 체크리스트
시간대를 넘나드는 초대장을 보내기 전에 다음 사항을 확인하십시오:
- 도시 또는 시간대를 명시했습니까, 아니면 시간만 표기했습니까?
- 각 지역 참가자를 위한 변환 시간을 포함했습니까?
- 지속적이거나 계약적인 내용의 경우 UTC로 기록했습니까?
- 회의가 DST 변경 날짜 근처에 있습니까? 그렇다면 시차를 다시 확인했습니까?
- 보내기 전에 세계 시계를 기준으로 변환 시간을 확인했습니까?
- 이 회의가 누군가의 이른 아침이나 늦은 저녁 시간을 할애할 가치가 있습니까, 아니면 비동기 방식이어야 합니까?
자주 묻는 질문
UTC로 일정을 잡아야 합니까, 아니면 현지 도시 시간으로 해야 합니까?
목적에 따라 둘 다 사용하십시오. 마감일, 유지보수 기간, 계약과 같은 지속적인 서면 기록에는 UTC를 사용하십시오. 절대 변하지 않기 때문입니다. 사람을 대상으로 하는 초대장에는 명명된 도시 시간("15:00 런던")을 사용하십시오. 사람들은 UTC가 아닌 자신의 벽시계를 읽기 때문입니다.
두 도시 간의 시차가 왜 1년 내내 변합니까?
두 지역이 서로 다른 날짜에 일광 절약 시간제를 시행하거나, 한쪽만 시행하고 다른 쪽은 시행하지 않기 때문입니다. 런던과 뉴욕은 1년 중 대부분 5시간 차이지만, 한쪽만 시계를 변경한 몇 주 동안은 4시간 또는 6시간으로 변동합니다.
세 대륙에 걸친 팀을 위한 공정한 회의 시간을 어떻게 찾습니까?
각 사람의 근무 시간을 UTC로 매핑하고 겹치는 부분을 찾으십시오. 종종 유일한 공유 시간대는 누군가를 이른 아침이나 늦은 저녁 시간대로 몰아넣습니다. 따라서 그 부담을 지역 간에 순환시키고, 진정으로 모든 사람의 실시간 참여가 필요한 회의를 위해 그 겹치는 시간을 아껴 두십시오.
겹치는 근무 시간이 전혀 없다면 어떻게 합니까?
비동기 작업에 의존하십시오: 녹화된 워크스루, 공유 문서, 두 사람이 동시에 깨어 있을 필요가 없는 서면 인계. 드문 실시간 세션은 브레인스토밍과 어려운 대화를 위해 아껴 두십시오.
"오후 3시 EST"는 명확합니까?
완전히 그렇지는 않습니다. 여름 동안 미국 동부 해안은 실제로 EST가 아닌 EDT를 사용하므로, 7월의 "오후 3시 EST"는 기술적으로 한 시간 차이가 납니다. 도시 이름("오후 3시 뉴욕")을 사용하면 약어 함정을 완전히 피할 수 있습니다.
시간대를 넘나드는 일정 잡기는 시간대를 명시적으로 밝히고 확인하는 순간부터 더 이상 골칫거리가 아닙니다. 팀의 도시에 대해 세계 시계을 열어 두고, 작업하는 시간대을 북마크에 추가하고, 도구가 시차를 추적하도록 하여 회의 자체에 집중할 수 있도록 하십시오.