Hackers could obtain this key when they obtain access to the server binary.
When there is no reason why the users would need legitimate access to the server binary files (which should be the case when they interact with the server via network), it should be possible to harden the server sufficiently to make access impossible.
But keep in mind that when you hardcode a secret key in your application, anyone who has access to the sourcecode can leak the key to a 3rd party - intentionally or accidently. For that reason it would be much smarter to read the key from a configuration file. That way the development team can work with their own development-key, while the production server uses a different key which is only available to the sysadmin which deploys and maintains the server in production.
Another thing which could bite you is using C for a security-relevant server application. I don't want to start a programming language flamewar, but the C programming language is known for certain features which trade security for performance and easily lead to vulnerabilities like buffer overflows which allow arbitrary memory access or even code execution. A careless bug in a completely unrelated part of your netcode could easily allow an attacker to extract the memory which stores your key (no matter if it's hard-coded or read from a config file). But when you insist on writing an application which is security-relevant in C, at least be careful with certain functions like
sprintf and several others which deal with arrays and don't do automatic bound-checking (which, how and why is enough stuff for another question).