일본의 연호에 iOS 개발자가 관심을 가져야 하는 이유

Sungdoo Yoo
4 min readApr 7, 2019

--

2019년 4월 1일, 일본이 새 연호를 선포했다.

2019년 4월 1일부로, 일본은 새로운 연호 레이와(令和)를 쓰게 되었다. 그렇다. 일본은 자체 연호를 쓰는 나라다. 그리고 이 연호는 그저 상징적으로 존재하지 않는다. 일본에서는 아주 많은 사람들이 이 연호를 일상적으로, 그리고 업무적으로 사용한다. iOS 개발자 입장에서, 이는 결코 간과해서는 안 될 사실이다.

iOS는 여러 달력 시스템을 지원한다. 그 중에는 일본력도 있다. 설정앱→언어 및 지역→캘린더 로 들어가면 확인 할 수 있다.

우리는 종종 날짜 시스템이 전 세계적 표준을 따르고 있다고 무의식적으로 생각할 때가 있는데, 이런 생각은 예상치 못한 곳에서 치명적인 버그를 일으킨다.

입사 초기에, Crashlytics에서 지속적으로 잡히는 버그가 있었다. 커스텀으로 만든 DateFormatter에서 잡히는 에러였는데, 아무리 해도 로컬에서는 재현이 되지 않았다. 그 때 에러를 뱉던 코드는 다음과 같다.

아주 간단한 코드다.

우리는 당연히 이 코드가 2016/06/10/09/00 를 출력할거라고 생각했다. 하지만 일본력을 쓰는 사람들은 4004-06-10 09:00:00 +000같은 해괴망측한 숫자를 만나게 된다. 출력값에 대한 기대가 완전히 빗나갔기 때문에, "/" 기호로 문자열을 split 하는 등의 작업에 대해 force-unwrapping 같은 것이라도 하면 영락없이 크래시로 이어지게 된다.

비극은 이 코드가 한국인들의 핸드폰에서는 결코 재현되지 않았다는 점이었다. 크래시 리포트에 버그가 발생했다는 소식은 들려오는데, 우리는 도대체 이 버그가 왜 발생하는지 알 수가 없었다. 크래시가 누적되고, 이 크래시들이 iPhone5의 iOS10에서만 발생한다는 실마리를 바탕으로 구글링을 한 결과, 이 버그의 원인을 만날 수 있었다.

당시 우리는 커스텀 DateModel을 사용하고 있었는데, 이 모델로 ‘연도’에 해당하는 값이 2000언저리라고 가정한 연산을 하던 중, Integer Overflow가 발생한 것이 원인이었다. 특히 iPhone5는 32비트 CPU를 쓰기 때문에, IntegerOverflow에 취약하다. 그 이상의 모델에서는, 이상한 값을 보여줄 지언정 크래시는 나지 않았다.

오직 iPhone5에서만, 그것도 일본에서 일본력을 쓰는 사람들에게서만 나타나는 버그였으니 우리로서는 당연히 재현할 수 없었다.

위 문제는 다음과 같이 코드 한 줄을 추가하여 해결하였다.

이 버그는 아주 많은 교훈을 주었다.

  • 날짜를 다루는 일은 아주 어려운 일이며, 우리가 함부로 커스텀한 DateFormatter나 DateModel을 만들어서 문제를 해결하면 안 된다는 것
  • 가급적 setLocalizedDateFormatFromTemplate 등 처럼 iOS Framework에서제공하는 기능들을 사용해서 문제를 해결해야 한다는 것.
  • UX를 만드는 것은 단순히 예쁜 화면을 만드는 것 뿐이 아니라, 여러 나라의 문화와 생활 관습을 이해하고 반영하는 일이라는 것.
  • 도저히 해결 안 되는 버그도, 포기하지 않고 계속해서 관심을 가지면 어느 순간 실마리를 붙잡을 수 있다는 것.

쓰고 보니 짧은 글이지만, 내가 오기 전부터 몇 년동안 계속해서 발생하던 버그였고, 나도 이 버그를 고치기까지 몇 달이 걸렸다. (물론 이 버그만 고치는데 풀타임을 쓰진 않았다. 시간 날 때 짬짬이 봤기 때문에 오래 걸린 것도 있다.) 고쳤다는 사실보다, 포기하지 않고 물고 늘어진 끝에 얻은 승리였기 때문에 더더욱 기억에 오래 남는 버그였다.

참고

--

--