AI로 만든 앱이 시간을 잘못 표시하는 이유(그리고 시간대 문제 해결법)

AI로 만든 앱은 왜 시간을 잘못 표시할까요?

서로 다른 곳에 있는 두 사람이 똑같이 올바른 시간을 보고 있으면서도 화면에는 서로 다른 숫자가 뜰 수 있기 때문입니다 — 이 어긋남이 시간대 문제의 전부입니다. 마드리드에 있는 고객이 오후 3시 예약을 잡습니다. 당신은 멕시코시티에 있고, 화면에는 같은 예약이 오전 8시로 표시됩니다. 화면을 뚫어져라 보면서 뭔가 고장 났다고 확신하게 되죠.

고장 난 건 없습니다. 정확히 같은 순간에 마드리드는 오후 3시이고 멕시코시티는 오전 8시일 뿐입니다. 둘 다 맞습니다. 두 사람 모두 옳은데 서로 다른 숫자를 보게 되는 이 틈새가, “앱이 이상하게 동작해요”라는 버그 제보 중 놀랄 만큼 많은 부분의 원인입니다.

이 문제는 슬그머니 다가옵니다. 앱을 만들고 테스트하는 동안 당신은 한 장소, 한 기기에 있는 유일한 사람이니까요. 모든 게 딱 맞아떨어집니다. 시간대는 다른 어딘가에 있는 두 번째 사람이 같은 시간을 볼 때에야 비로소 이빨을 드러냅니다. 앱 사용자가 두 도시 이상에 걸쳐 있거나, 어떤 형태로든 예약 발송 메시지를 보낸다면 이 문제는 반드시 찾아옵니다. 미리 마주하는 편이 낫습니다.

시간대란 정확히 무엇인가요?

시간대는 시간의 “장소” 절반에 해당합니다 — 하나의 보편적 순간을 지역별 시계 표시로 바꿔주는 부분이죠. 나머지를 이해하는 데 필요한 핵심 개념은 이겁니다. 모든 시각에는 두 가지 요소가 있습니다.

1. 순간 — 지구상 어디서나 동일한 단 하나의 시점.
2. 장소 — 그 시계를 읽는 사람이 있는 위치.

“오후 3시”라는 말은 그 자체로는 아무 의미가 없습니다. 어디의 오후 3시일까요? 컴퓨터는 이 문제를 이렇게 다룹니다. 순간을 장소와 무관한 중립적 형식으로 저장하고(빌더가 “UTC”라고 말하는 걸 듣게 될 텐데, 고정된 기준점의 시계라고 생각하면 됩니다), 각 사람이 화면을 볼 때 그 사람의 지역 시간으로 변환해 보여주는 것이죠.

앱이 잘못된 시간을 보여준다면, 거의 항상 이 두 요소 중 하나를 놓쳤기 때문입니다 — 장소를 잊어버렸거나, 애초에 진짜 순간을 저장한 적이 없거나.

앱에서 시간대 버그는 왜 생길까요?

거의 모든 시간대 버그는 세 가지 구체적인 실수에서 비롯됩니다. 진짜 순간이 아닌 시계 표시를 저장하는 것, 사용자가 아닌 서버의 시간대를 보여주는 것, 그리고 서머타임 전환을 무시하는 것입니다.

1. 앱이 순간이 아니라 시계 표시를 저장한다. 누군가 “오전 9시”를 선택하면 앱은 장소 정보 없이 그냥 “오전 9시”라는 텍스트를 저장합니다. 이제 앱은 모든 사람, 모든 곳에 “오전 9시”를 보여줍니다. 이게 딱 맞을 때도 있고(각자의 현지 시간으로 오전 9시에 울려야 하는 복약 알림처럼), 재앙일 때도 있습니다(모두에게 단 하나의 동일한 순간에 시작해야 하는 실시간 웨비나처럼). 앱이 둘 중 어느 쪽인지 잘못 짐작하면 시간이 어긋나기 시작합니다.

2. 앱이 사용자가 아니라 서버의 시간을 보여준다. 당신의 앱은 데이터센터의 어느 컴퓨터에서 돌아갑니다 — 예를 들면 버지니아라고 해보죠. 따로 알려주지 않으면 앱은 아무 거리낌 없이 모두에게 버지니아 시간을 보여줄 겁니다. 런던에 있는 사용자들은 이제 반나절이나 어긋난 채로, 이유도 모르고 헤매게 됩니다.

3. 서머타임으로 시계가 바뀌었는데 앱이 눈치채지 못한다. 많은 지역이 1년에 두 번, 시계를 한 시간씩 조정합니다. 겨울에 설정해둔 “매주 화요일 오전 9시” 반복 회의가, 앱이 장소가 아니라 고정된 시차에 맞춰져 있었다면 여름에는 갑자기 오전 8시나 10시가 되어버립니다.

실제로 있었던 세 가지 사례

세 번씩 시작된 행사. 한 창업자가 온라인 워크숍을 위한 간단한 페이지를 만들면서 시작 시각을 딱 하나만 적어두었습니다. “오후 6시 시작.” 세 나라의 참석자들은 각자 “오후 6시”를 자기 지역의 오후 6시로 읽었습니다. 3분의 1은 한 시간 늦게 들어왔고, 몇몇은 한 시간 일찍 들어왔으며, 모두가 링크 탓을 했습니다. 해결책은 더 나은 링크가 아니라, 각 사람에게 시간대까지 명시한 그 사람만의 현지 시작 시각을 보여주는 것이었습니다.

새벽 2시에 도착한 뉴스레터. “매일 아침 8시에 발송”으로 설정한 이메일이 서버 기준 오전 8시에 나갔습니다. 구독자 목록의 유럽 쪽 절반에게는 그게 한밤중이었죠. 그 구독자들의 열람률은 형편없었고, 콘텐츠 문제처럼 보였습니다. 사실은 시간대 문제였습니다.

이중 예약된 일요일. 어느 예약 앱이, 시계가 “한 시간 뒤로” 돌아가는 그날 밤 두 사람에게 같은 마사지 시간대를 예약해주고 말았습니다. 그날 밤에는 새벽 1시 30분이 두 번 찾아왔는데, 앱이 그 두 순간을 똑같은 것으로 처리해버렸기 때문이죠. 흔치는 않지만, 진짜 고객과 진짜 사과 한 번을 치르게 만드는 종류의 버그입니다.

시간대 문제를 고치려면 빌더에게 무엇을 요청해야 할까요?

이 내용을 자세히 배울 필요는 없습니다. 아래 문장을 그대로 복사해서, 쉬운 말로 네 가지를 구체적으로 요청하세요.

“모든 시각을 UTC 순간으로 저장하고, 각 사용자의 시간대도 함께 저장해줘.”

“시각을 보여줄 때는 보는 사람의 시간대로 보여주고, 바로 옆에 시간대도 표시해줘 — 오후 3시 (내 시간대)나 오후 3시 CST처럼.”

“알림, 일정, 반복 이벤트처럼 되풀이되는 모든 것은 고정된 시차가 아니라 장소(‘America/Mexico_City’ 같은)에 맞춰줘. 그래야 서머타임이 자동으로 처리돼.”

“다른 나라에 있는 것처럼 테스트해볼 수 있게 해줘.”

마지막 요청이 말보다 훨씬 중요한데, 여기서부터는 직접 할 수 있는 부분으로 이어집니다.

앱의 시간대 버그는 어떻게 테스트하나요?

다른 나라에 있는 사용자가 없어도, 그런 척만 하면 2분 안에 대부분의 시간대 버그를 잡아낼 수 있습니다.

1. 휴대폰이나 컴퓨터의 날짜·시간 설정을 열어 시간대를 멀리 떨어진 곳 — 도쿄든 런던이든 — 으로 바꿉니다.
2. 앱을 새로고침합니다.
3. 시간이 표시되는 모든 곳을 살펴봅니다. 여전히 말이 되나요? 누구의 시간인지 알려주고 있나요?

오후 3시여야 할 예약이 아무 설명도 없이 새벽 4시로 보인다면, 고객이 발견하기 전에 버그를 찾은 겁니다. 확인이 끝나면 설정을 원래대로 되돌리세요. 반복 알림이나 서머타임 관련 사례라면, 다른 나라에 있는 친구 한 명에게 특정 날짜를 보여주고 어떤 시각으로 보이는지 물어보는 게 가장 확실한 확인 방법입니다.

시간대를 꼭 신경 써야 할까요?

솔직히 말하면 — 그렇지 않을 때도 있고, 이건 짚고 넘어갈 가치가 있습니다. 앱을 쓰는 모든 사람이 같은 도시에 있다면 — 동네 식당의 직원 일정 관리 도구, 동네 클럽의 신청 명단 같은 것 — 어려운 부분은 대부분 건너뛰어도 됩니다. 그저 일관성을 지키고, 시간대를 명시해서 혼동의 여지가 없게만 하면 됩니다.

시간대는 다음 두 가지 중 하나가 참이 되는 순간 진짜 문제가 됩니다. 서로 다른 곳에 있는 두 사람이 하나의 시각을 공유하거나, 앱이 일정에 따라 뭔가를 발송하거나. 이 경계를 넘는 순간, 가장 값싸면서도 가장 확실한 보험은 단순합니다. 시각 옆에 항상 시간대를 표시하는 것. 이 한 가지 습관만으로도, 더 깊은 수정이 들어가기 전에 이미 대부분의 사고를 일으키는 모호함이 사라집니다.

그러니 다음에 앱에 날짜나 시간 필드를 추가할 때는, 넘어가기 전에 스스로 딱 한 가지만 물어보세요. 이건 누구의 시간일까? 그 질문에 소리 내어 답할 수 있다면, 이미 대부분의 앱보다 앞서 있는 셈입니다.