할 일 앱은 'tomorrow at 9am'을 어떻게 이해할까

좋은 할 일 앱에 “Email Sam tomorrow at 9am"을 입력하면 둘 중 하나가 일어나야 해요. 제목이 “Email Sam"이고 마감일이 다음 날 오전 9:00로 설정된 깔끔한 객체로 할 일을 돌려받거나, 아니면 앱이 아무것도 하지 않아 당신이 날짜 선택기를 채워야 하거나요. 그 두 결과의 차이가 당신이 그 앱을 실제로 쓰느냐를 결정해요.

자연어 날짜 해석은 수십 년간 있어 왔어요. Quicksilver를 구동했어요. Fantastical도 구동했고요. 오늘날엔 출시할 가치가 있는 거의 모든 생산성 앱을 구동해요. 하지만 그게 내부에서 작동하는 방식이 지난 2~3년간 흥미롭게 바뀌었고, 그 결과 2026년은 이 기술이 대부분의 앱에서 영어에 대해 진정으로 해결되고 다른 언어에서도 잘 작동하기 시작한 첫 해예요.

이 글은 그게 어떻게 작동하는지에 대한 둘러보기예요.

문제의 기본 형태

사용자가 문장을 입력해요. 앱은:

1. 그 문장에 날짜가 들어 있기는 한지 판단해야 해요.
2. 들어 있다면, 텍스트의 어느 구간이 날짜를 가리키는지 찾아야 해요.
3. 그 구간을 절대적인 날짜와 시간으로 해석해야 해요.
4. 남은 텍스트가 할 일 제목만 되도록 문장에서 날짜 구간을 제거해야 해요.

이 각 단계에는 저마다의 실패 방식이 있어요. 초기 구현 대부분은 1단계에서 취약해서 거짓 양성을 만들었어요. “Pick up the 15 reports"는 그 달 15일이라는 마감일을 받으면 안 돼요. “Buy 3 apples"는 무슨 세 가지로 해석되면 안 되고요. “Email Sam at IBM"은 아마 시간을 “at I.B.M.“에 고정하는 게 아니죠.

고전적인 전략은 정규 표현식이에요. 놀랍도록 이걸 잘해요. 정성껏 쓴 패턴 한 줌이 사람들이 실제로 할 일 앱에 입력하는 날짜 표현의 90% 이상을 인식할 수 있어요:

• \bin\s+(a|an|\d+|some|several)\s+(min|minute|minutes|hour|hours|hr|hrs|day|days|week|weeks|month|months)\b
• \b\d{1,2}(:\d{2})?\s*(am|pm)\b
• \b(tomorrow|today|tonight|noon|midnight)\b
• \b(monday|tuesday|wednesday|thursday|friday|saturday|sunday)\b

이런 패턴 열다섯에서 스무 개를 조합하면 긴 꼬리를 커버해요. 그런 다음 매치들을 꿰매죠: 날짜 단어 더하기 시간 단어는 특정 순간이 돼요. 한정어 없는 요일 이름은 “그 요일의 다음 발생"을 뜻하고요. 날짜 없이 시간 단어만 있으면 오늘이에요.

정규식이 무너지는 지점

정규식은 세 종류의 입력에서 벽에 부딪혀요:

1. 모호한 표현. “Sometime next week"은 날짜이지만 특정한 게 아니에요.
2. 중의성. “Friday afternoon"은 관습에 따라 오후 2시일 수도 4시일 수도 있어요.
3. 오타와 속어. “tmrw at 9p"는 사람은 해석할 수 있지만, 변형을 잔뜩 넣지 않은 엄격한 정규식은 못 해요.

오랫동안 할 일 앱들은 이것들에 그냥 어깨를 으쓱했어요. “tmrw at 9p"를 입력하면 아무것도 안 나왔죠. “first thing tomorrow"를 입력해도 아무것도 안 나왔고요. 사용자는 격식 있는 버전을 입력하는 법을 배웠어요.

지난 1년의 흥미로운 발전은 온디바이스 언어 모델이 이제 어떤 것도 네트워크로 보내지 않고 이런 경우를 처리할 수 있게 됐다는 거예요. macOS 26부터 쓸 수 있는 Apple의 Foundation Models 프레임워크는 로컬에서 돌아가고 정규식이 놓칠 때 대체 수단으로 쓸 만큼 빠른 모델을 탑재해요. Google도 Android에 비슷한 걸 제공하고요. 그 결과 패턴은 이렇게 생겼어요:

빠른 경로가 90% 경우를 커버해요. 모델이 나머지를 처리하고요. 어느 단계도 사용자의 텍스트를 네트워크로 보내지 않아요. 개인정보 보호와 속도가 둘 다 지켜져요.

“in 2 hours"가 보기보다 어려운 이유

“in 2 hours"라는 표현은 쉬워 보여요. 그렇지 않아요.

사용자는 다음 중 무엇이든 뜻할 수 있어요:

• 지금부터 정확히 2시간 뒤, 분 단위로요.
• 지금부터 2시간 뒤, 깔끔하게 가장 가까운 15분으로 반올림.
• 지금부터 2시간 뒤, 단 그게 사용자가 표시한 수면 시간에 떨어지면 다음 날 아침.
• 다음 정시의 시작부터 2시간 뒤(“in 2 hours"를 오후 1시 55분에 말하면 오후 3시 55분이 아니라 4시 00분을 뜻할 수도 있어요).

대부분의 앱은 하나를 골라 고수해요. 가장 흔한 건 “지금부터 정확히 2시간 뒤, 분 단위"인데, 우아함을 예측 가능성과 맞바꾼 거예요. 오후 1시 23분에 “in 2 hours"를 입력한 사용자는 오후 3시 23분에 알림을 받아요. 깔끔한 시간을 원할 때 정수를 입력하는 법을 배우게 되죠.

“tomorrow"가 오전 9시로 기본값을 두는 이유

시간 없이 “tomorrow"를 입력하면, 앱은 시간을 골라야 해요. 관습은 시장의 거의 모든 앱에서 오전 9:00로 수렴했어요. 왜일까요?

잘못 추측하는 비용이 비대칭이기 때문이에요. 앱이 오전 9시를 골랐는데 당신이 오전 11시를 원했다면, 알아챘을 때 빠르게 조정할 수 있어요. 앱이 자정이나 어떤 무작위 시각을 고르면, 당신은 자는 동안 알림을 받거나 완전히 놓쳐요. 오전 9시는 거의 모든 종류의 업무 할 일에 안전한 기본값이에요.

몇몇 앱은 오전 8시를 기본값으로 둬요. 몇몇은 할 일을 입력한 하루 중 시각을 써요(“오후 2시에 말했으니 아마 내일 오후 2시를 뜻하겠지”). 후자는 영리하지만 미덥지 않아요. 오후 2시에 할 일을 입력하는 대부분의 사람은 미래의 업무일에 하고 싶은 할 일을 업무 중에 입력하는 거지, 다음 날 정확히 오후 2시를 뜻하는 게 아니거든요.

TodoBar 안에서는 이게 어떤 모습인가

TodoBar는 위에서 설명한 2단계 패턴을 써요. 시간 표현이 있는 할 일을 입력하면 정규식 계층이 먼저, 1밀리초 미만에 발동해요. 날짜를 찾으면, 할 일이 올바른 마감 시간이 붙은 채 목록에 나타나요. 정규식 계층이 표현을 해석하지 못하면, 온디바이스 Foundation Models 분류기가 보통 약 50밀리초의 지연으로 한 번 시도해요. 어느 쪽이든, 어떤 텍스트도 당신의 Mac을 벗어나지 않아요.

정규식 계층이 인식하는 패턴은 지원 페이지에 문서화돼 있어요. 빠른 참고로, 이것들은 전부 작동해요:

• “in 30 minutes”
• “in 2 hours”
• “in a couple hours”
• “tomorrow”
• “tomorrow at 9am”
• “tonight”
• “tonight at 8”
• “next Friday”
• “Friday at 5pm”
• “May 12”
• “May 12 at 2pm”
• “the 15th”
• “in 3 days”
• “1 week from now”
• “first thing tomorrow”

파서가 처리할 수 없는 무언가를 입력해도, 할 일은 마감일 없이 추가되고, 행의 종 버튼에서 수동으로 하나 붙일 수 있어요. 파서의 실패 방식은 “할 일 손실"이 아니라 “마감일 미부착"이에요.

이 모든 게 어디로 가는가

다음 흥미로운 영역은 다국어 해석이에요. “mañana a las 9” 같은 스페인어 표현이 영어 동등물만큼 잘 작동해야 하고, 로컬라이제이션을 진지하게 받아들이는 앱에서는 점점 그렇게 되고 있어요. Apple의 온디바이스 모델은 우리 내부 테스트에서 스페인어를 잘 처리해요. 같은 접근이 프랑스어, 독일어, 일본어, 그리고 아마 대부분의 주요 언어에 내년 안에 통할 거예요.

조각들은 다 여기 있어요. 예전엔 비싼 클라우드 왕복이었던 게 이제 50밀리초 걸리는 로컬 함수 호출이에요. 인디 할 일 앱이 사용자당 추론 청구서 없이 무료로 그걸 출시할 수 있다는 사실이 진짜 이야기예요.