왜 알아보기 어렵게 시간을 소수점으로 표시하나요?

지난 엑셀에 MATCHS 함수가 필요할지도 모릅니다에서 오픈서치에 적재된 로그를 쿼리 워크벤치를 통해 가져오면서 생긴 문제를 소개했습니다. 대략 쿼리 워크벤치에서는 베이직 쿼리만 지원하고 또 주요 집계 명령이 한 번에 결과를 200개 까지만 돌려주는데 한 쿼리에 집계 명령 여러 개를 사용하면 명령 각각이 결과를 200개만 돌려줘 결국 이상한 결과를 돌려주게 된다는 내용이었습니다.

그래서 쿼리 워크벤치는 데이터를 꺼내는 데만 사용하고 실제 집계는 엑셀에서 수행하기로 합니다. 그나마 쿼리 워크벤치는 집계 쿼리 없이도 한 번에 최대 1만건 까지만 데이터를 꺼낼 수 있어 한 번에 1만건이 넘는 데이터를 조회하려면 조건을 잘 나눠야 했는데 베이직 쿼리만 지원하는데는 LIMIT 명령을 온전히 지원하지 않아 페이지를 구분해 결과를 받을 수 없었기 때문입니다.

한편 그런 오픈서치에 기반한 시행착오와 엑셀에서 여러 조건을 동시에 만족하는 행의 특정 값을 한 번에 뽑기 위한 시행착오를 겪으며 비즈니스 부서에서 요구하는 통계와 기반 데이터를 전달했습니다. 비즈니스 부서의 감각은 대단했는데 사실 이번 시행착오를 겪으며 이것이 시행착오가 되어야 한다는 사실은 비즈니스 부서의 약간 동물적인 감각 덕분에 감지할 수 있었습니다. 그저 쿼리 워크벤치에 쿼리를 작성해 실행한 다음 나온 결과를 파일로 저장해 보내는 약간 기계적인 역할을 하다 보니 거기 나온 결과가 올바른지에 크게 신경 쓰지 않고 있었습니다. 하지만 비즈니스 부서에서는 숫저를 보고 최소한의 검토를 해 보고는 바로 이 결과에 뭔가 문제가 있다는 사실을 알아냈고 하마터면 엉뚱한 분들을 대상으로 이벤트 보상을 집행할 뻔 했습니다. 보상은 민감한 문제여서 이미 구축된 시스템을 통하는 대신 이런 방식으로 사람 손을 타는 것 자체가 위험한 일인데 거기에 실수 까지 했더라면 큰 문제가 될 수 있었습니다. 역시 능숙한 프로는 다르구나 싶습니다.

비즈니스 부서 역시 대부분은 통계 도구에 요구사항에 따라 예쁘게 정리된 보고서를 사용하시다가 매번 필요한 보고서 모양을 다른 부서에 전달해 그 결과를 받아 검토하는 식으로 작업하는 건 익숙하지 않아 이 의사소통과 결과 도출 자체에도 시행착오를 겪었는데 가령 ‘상위 10%’의 정의에 대해 서로 달리 생각했거나 ‘가장 많이 죽은 사람’과 ‘특정한 사유로 가장 많이 죽은 사람’을 서로 달리 생각하는 등의 자잘한 시행착오가 있었습니다. 그런데 이런 시행착오 중 기억에 남는 것은 ‘시간 표시’에 대한 질문이었습니다. 오늘은 한 행에 1.25라고 기록된 시간을 보고 ‘1분 25초라고 해석하면 되는가?’라는 질문을 받고 이 질문에 답한 다음 왜 시간을 이런 식으로 표시하는지 이유를 생각해보고 다음에 더 잘 하려면 어떻게 해야 할 지도 함께 고민해 두려고 합니다.

일단 1.25는 분, 초를 표현한 것이 아니고 '분' 만을 표현한 숫자입니다. 1분 25초가 아니라 1.25분으로 분, 초로 고치면 1초, 그리고 1/4분이니 합쳐서 1분 15초가 되며 익숙한 시간, 분 표기 방법으로 표시하면 1.25가 아니라 1:15라고 표기해야 합니다. 아무래도 시간 표기는 한 가지 단위에 기초해 소수점을 사용하기 보다는 시간, 분, 초, 천 분의 일 초 단위를 차례로 사용하되 초와 천 분의 일 초 사이에는 콜론 대신 소수점 문자를 사용하는 편이 결과를 읽는 사람에게 더 익숙했을 겁니다. 로그에는 시간을 항상 밀리세컨드, 즉 천분의 일초로 기록하고 있어서 로그에 찍힌 숫자에 1000을 곱해 나온 숫자를 60으로 나눠 '분' 단위로 바꿔 집계 문서를 완성했는데 이는 어쩌면 기록하고 계산하는 입장의 편의만 생각한 결과가 아니었을까 싶습니다.

이렇게 한 첫 번째 이유는 시간을 이런 식으로 소수점을 포함한 숫자로 나타낸 가장 큰 이유는 컴퓨터에서 시간을 기록할 때 숫자 한 덩어리로 기록하는 방법이 널리 사용되기 때문입니다. 가령 유닉스 운영체제에는 타임스탬프라는 값이 있는데 이 숫자는 1970년부터 1초씩 세어 현재까지 지난 숫자를 표시하고 있습니다. 이 숫자를 1970년을 기준으로 이리 저리 잘 계산하면 현재 시간을 구할 수 있는데 이렇게 시간을 숫자 하나로 표현하면 이를 사람이 읽기 편한 방식으로 바꾸는 것은 조금 귀찮을 수 있지만 기록하기도 편하고 계산하기도 편합니다. 가령 어떤 두 가지 시간 차이의 차이를 구할 때 만약 시간이 서로 다른 단위인 시간, 분, 초 등으로 구분되어 있다면 시간은 십진법으로, 분과 초는 육십진법으로 계산해야 합니다. 만약 이런 단위에 천 분의 일 초 단위가 포함되어 있다면 이는 다시 십진법으로 계산해야 해서 계산 과정이 상당히 복잡해질 수 있습니다.

물론 프로그래밍 언어 대부분, 그리고 엑셀 함수에서도 이런 날짜와 시간 계산을 굉장히 편안하게 처리할 수 있는 다양한 기능을 제공하며 심지어 엑셀에서는 주말을 제외한 평일만 세는 등으로 더 편안한 기능을 제공하고 있기도 합니다. 하지만 이런 기능들의 도움을 받는 대신 만약 시간이 숫자 한 덩어리로 표현되어 있다면 그저 십진법으로 두 숫자 사이의 차이를 구한 다음 나온 결과를 사람이 익숙한 시간, 분, 초 등의 서로 단위를 사용한 모양으로 바꿔 주면 됩니다. 단위마다 각기 다른 진법을 사용한 계산은 복잡하고 틀리기 쉽지만 계산 자체는 그냥 덧셈과 뺄셈으로 끝내고 계산이 끝난 다음 사람이 보기 편한 모양으로 바꾸기만 하면 계산 자체를 복잡하지 않게 유지할 수 있습니다.

두 번째 이유는 시간을 기록하고 계산할 때 한 가지 단위만 사용하기 위해서 입니다. 첫 번째 이유에서 시간을 숫자 한 덩어리로 기록하고 계산하기 위함이라는 이유와 비슷한데 만약 사람이 읽기에 더 익숙한 여러 단위로 구성된 둘 이상의 시간을 계산하려면 계산을 시작하기에 앞서 먼저 두 시간의 단위를 맞춰야 합니다. 가령 1일 2시간 15분과 480초를 더하려면 어느 한 쪽의 단위를 바꿔 서로 더할 수 있는 모양으로 바꿔야 합니다. 이 사례에서는 480초를 8분으로 바꿔 15분에 더하면 되지만 이보다 더 복잡한 시간 사이에 계산을 해야 한다면 위에서 설명한 단위마다 서로 다른 진법을 고려해야 해서 계산이 복잡해지고 틀릴 가능성도 높아집니다. 또 계산을 마친 다음 사람에게 익숙한 모양으로 표시한 다음에도 이미 계산이 끝난 이 결과 값에 기반해 다시 계산을 해야 하는 상황이 생길 수 있습니다.

이 때 시간을 1분 25초 처럼 서로 다른 단위로 표시해 두면 사람이 알아보기에 편하기는 하지만 계산을 이어서 하려면 이 상태로는 위에서 설명한 똑같은 문제가 생깁니다. 가령 1분 25초 짜리 이벤트가 네 번 발생하면 시간이 얼마나 걸리는지 계산해야 하는 상황일 때 각 단위에 4를 곱하면 4분과 100초가 되며 뒤쪽은 1분 40초로 바꿔 결과는 5분 40초여야 하는데 이 계산 역시 단위마다 다른 진법을 사용하고 다른 진법의 셈 결과에 따라 숫자를 올릴 때 올린 단위 체계를 따라야 해서 틀리기 쉽습니다.

하지만 1.417분으로 기록해 두면 그냥 이 숫자 전체에 십진법으로 곱셈을 하면 결과를 얻을 수 있어 계산 과정이 단순해져 틀릴 가능성이 줄어듭니다. 하지만 1.417분은 시간을 인식하는 사람 입장에서 직관적이지 않을 수 있는 것은 맞습니다. 또한 이런 소수점 표현은 사실 분, 초 단위로 시간을 표현할 때 정확한 시간을 표현하지도 못합니다.

때문에 자동화된 보고서를 만들 때는 보고서에 표시된 최종 결과를 사용해 다시 계산하지 않는다고 가정하고 사람에게 더 익숙한 서로 다른 날짜, 시간 단위를 사용해 시간을 표시하는데 다만 이번에는 자동화 되지 않은 보고서를 사람이 만들었고 보고서를 만든 사람이 로그에 기록된 천 분의 일 초 단위 숫자를 가져와 계산하기 편한 모양을 유지하는데 집중하는 바람에 사람이 읽기 힘들고 헛갈리며 정확하지 않을 수 있는 표현을 사용했습니다.

결론. 컴퓨터에서 시간을 숫자 한 덩어리로 기록해 두 시각의 차이를 계산하는데 간단히 덧셈, 뺄셈만 사용하면 됩니다. 또 이런 표현은 최종 결과를 다시 계산에 적용하기도 편합니다. 다만 이런 모양은 날짜와 시간을 서로 다른 진법으로 구성된 여러 단위로 읽는데 더 익숙한 사람에게 편안하지 않을 수 있고 또 표현 자체가 정확하지 않을 수 있습니다. 이번에는 자동화 되지 않은 환경에서 보고서를 만드느라 보고서를 만드는 사람 관점에서 더 편한 방법을 사용했지만 보고서를 자동화 할 때는 보고서를 읽는 사람 관점에서 더 편안한 방법을 사용해야 합니다.