Server UTC vs. local time, setting TZ
A cron expression itself carries no time zone information. The time an expression points to follows the time zone of the system cron runs on. So the same 0 9 * * * will run at a different actual time depending on what the server's time zone is.
Many servers and containers default to the UTC time zone. Korea (KST) is UTC+9, so if you schedule 0 0 * * * (midnight) on a UTC server, it actually runs at 9 AM Korea time. Scheduling with local time in mind and then being off by 9 hours is very common.
Some cron implementations let you add a line like CRON_TZ=Asia/Seoul at the top of the crontab to have it interpreted in a specific time zone. In a container environment, you might instead set the image's TZ environment variable or point /etc/localtime at the region you want. However, whether this is supported varies by implementation, so you need to check.
In regions with daylight saving time (DST), a particular time may be skipped or occur twice on the day the clocks shift, so a job scheduled at that time may be missed or run twice. For important jobs, scheduling in UTC avoids these problems.
Practical tip: think of expressions in UTC, and always check the actual time zone of your deployment environment. For reference, the next run times shown by the tool on this site are based on your browser's local time zone, so you can compare them against the server's time zone.