2026년 8월 19일, 나는 Claude에게 현재 시각을 매 턴마다 넣도록 해둔 뒤에도 오후 4시 예약을 23분 남았다고 받았다. 당시 시각은 오후 1시 37분이었다. 4시까지는 2시간 23분인데 시간 자리 하나가 사라졌다. 이 작은 계산 오류를 계기로, 시각을 아는 일과 시각을 계산하는 일을 분리해서 보게 됐다.
시간을 알려줬는데 왜 계산은 틀렸을까?
현재 시각을 문장으로 넣는 일과, 그 시각으로 차이를 정확히 계산하는 일은 같은 작업이 아니었다.
“그때가 1시 37분. 4시까지 2시간 23분인데, 시간 자리만 통째로 날렸다.”
내가 본 답은 분 단위의 23은 남기고 시간 단위의 2를 잃어버린 형태였다. 오후 1시 37분, 오후 4시, 2시간 23분이라는 세 숫자는 모두 대화 안에 있었지만, 답으로 나온 값은 23분이었다. 시간 정보가 입력되어 있다고 해서 그 정보 사이의 뺄셈까지 자동으로 믿을 수는 없다는 장면이었다.
이 문제를 단순히 ‘AI가 시간을 몰랐다’고 부르기는 맞지 않았다. 현재 시각은 이미 자동으로 들어가고 있었다. 문제는 시각을 받아 적는 단계가 아니라, 시간과 분이 섞인 값을 계산하는 단계였다. 특히 60진법 시계의 자리올림과 자리내림은 숫자를 말로 이어 붙이는 방식과 별개로 다뤄야 했다.
내가 바꾼 규칙은 무엇이었나?
시간 계산이 필요한 순간에는 모델의 답 대신 date 명령 결과를 쓰도록 규칙을 바꿨다.
결론은 간단했다. 시간이 중요하면 시간 계산도 도구에 맡긴다. 나는 가격 결정을 웹훅에 맡겼던 것처럼, 신뢰하기 어려운 판단을 하나씩 도구로 옮기고 있다. 이 사례에서는 date 명령이 그 역할을 맡는다. 모델에게 현재 시각을 알려 주는 일은 유지하되, 몇 시간 몇 분이 남았는지처럼 정확한 계산이 필요한 자리는 분리한 것이다.
- 현재 시각을 문맥으로 제공하는 일
- 예약 시각과의 차이를 계산하는 일
- 계산 결과를 문장으로 설명하는 일
세 단계를 한 덩어리로 취급하면 결과가 그럴듯할수록 확인이 늦어진다. 반대로 계산 결과를 별도 도구에서 받고, 그 값을 문장에 반영하게 하면 확인 지점이 명확해진다. 나는 이 구분이 자동화에서 특히 중요하다고 느꼈다. 사람에게 보여 줄 예약 시각, 가격, 마감처럼 한 자리 차이가 결과를 바꾸는 값은 더 그렇다.
60진법 계산에서 무엇을 확인해야 할까?
시와 분이 함께 있는 값은 숫자 하나가 아니라 60분 단위로 묶인 두 자리 체계로 확인해야 한다.
오후 1시 37분에서 오후 4시까지의 간격은 2시간 23분이다. 여기서 분만 떼어 23이라고 답하면 의미가 달라진다. 시간 계산을 할 때는 최종 문장만 보지 않고, 기준 시각과 목표 시각 그리고 단위가 모두 남아 있는지 확인해야 한다. 이 글의 사례처럼 분이 맞는 답은 오히려 오류를 놓치기 쉽다.
나는 그래서 계산을 맡긴 뒤에도 결과에 단위를 붙여 확인한다. ‘23’처럼 단독 숫자가 아니라 ‘2시간 23분’처럼 시와 분이 모두 보이는 형태가 확인에 유리하다. 이 방법은 새로운 사실을 더하는 것이 아니라, 원래 입력한 시각과 결과를 같은 화면에서 다시 대조하는 방식이다.
도구로 옮긴다는 말은 무엇을 뜻할까?
도구 전환은 AI를 포기하는 선택이 아니라, 틀리면 곤란한 한 단계를 명확한 계산기로 분리하는 선택이다.
나는 이 경험 뒤에 ‘못 미더운 건 하나씩 도구로 옮긴다’는 기준을 더 분명히 했다. 모델은 상황을 설명하고 다음 행동을 제안하는 데 쓸 수 있다. 다만 일정 간격처럼 정확한 값이 필요한 부분은 계산 도구의 결과를 기준으로 두는 편이 낫다. 역할을 나누면 어떤 부분을 다시 확인해야 하는지도 선명해진다.
참고로 date 명령은 시간 정보를 다루는 도구로 문서화되어 있다. 명령 자체를 쓰는 법보다 중요한 것은, 계산 결과가 필요한 자리를 자연어 추정과 분리하는 일이다. GNU Core Utilities처럼 도구의 범위를 확인한 뒤 맡길 자리를 정하면 된다.
다음 예약 전에 남긴 점검 기준
예약까지 남은 시간을 말할 때는 현재 시각, 목표 시각, 시·분 단위가 모두 답에 남는지 먼저 확인한다.
- 현재 시각이 무엇인지 다시 읽는다.
- 목표 시각이 무엇인지 다시 읽는다.
- 결과에 시간과 분 단위가 함께 있는지 본다.
- 정확한 차이는 date 명령 결과로 대조한다.
이 기준은 이번 한 번의 계산만 고치기 위한 것이 아니다. 자동화에서 어떤 값을 모델에게 맡기고, 어떤 값을 도구에서 받아야 하는지 나누는 기준이 된다. 1시 37분과 4시 사이의 차이를 23분이라고 적었던 장면은 작지만, 그 구분을 다시 확인하게 만든 기록이다.
이 기록을 길게 남기는 이유는 시간 계산이 단순한 편의 기능이 아니기 때문이다. 예약 시각을 안내하는 문장에서 2시간이 빠지면, 그 문장을 읽는 사람은 전혀 다른 행동을 하게 된다. 그래서 나는 ‘현재 시간을 알고 있는가’라는 질문과 ‘두 시각의 간격을 계산할 수 있는가’라는 질문을 나눠 두기로 했다. 전자는 문맥의 문제이고, 후자는 기준값과 단위를 다루는 문제다. 같은 화면에 나온 숫자라도 역할이 다르면 검증 방식도 달라져야 한다.
도구를 쓰는 과정에서 내가 다시 확인하는 것은 화려한 자동화가 아니다. 1시 37분이라는 출발값, 4시라는 목표값, 그리고 2시간 23분이라는 결과가 빠짐없이 이어지는지다. 이 세 값이 문장 안에서 보이면 결과를 다시 읽을 수 있고, 하나라도 빠지면 계산을 재확인할 이유가 생긴다. 이번에는 23이라는 숫자가 그럴듯하게 남아 있었기 때문에, 오히려 시간 단위가 사라진 사실을 늦게 발견할 뻔했다.
마지막으로 남기는 질문과 답
정확도가 필요한 값은 자연어 답변만으로 확정하지 않고, 입력과 단위와 도구 결과를 함께 대조하는 편이 안전하다.
현재 시각을 넣으면 계산도 자동으로 정확해지나?
아니다. 이 사례처럼 시각을 알면서도 2시간 23분을 23분으로 답할 수 있어, 계산은 별도로 확인해야 했다.
왜 date 명령으로 바꿨나?
시간 차이는 정확한 값이 필요했기 때문이다. 나는 신뢰하기 어려운 계산을 도구에 맡기는 규칙으로 바꿨다.
이번 오류에서 확인된 숫자는 무엇인가?
오후 1시 37분, 오후 4시, 그리고 실제 차이인 2시간 23분이다. 답에는 시간 단위가 빠져 있었다.
AI는 어디에 쓰면 좋은가?
상황을 정리하고 설명하는 일에는 쓸 수 있다. 다만 일정과 계산처럼 정확도가 필요한 값은 결과를 별도 확인한다.
이 글은 제가 2026-08-19에 스레드에 올리고 직접 겪은 일을, 빠졌던 맥락과 확인 방법까지 더해 다시 쓴 글입니다. 원문은 여기서 볼 수 있습니다 → 원본 스레드 글