Would it make sense or provide an advantage of sorts to break a HMAC-SHA256 secret key into two components and hide one component in an applicable server side configuration file and the other component in (closed source, server side) compiled code?
I would choose both half's to be long enough that they individually contain enough entropy to ensure that even if the other half of the key is compromised, the other half of the key remains too long/complex to be brute forced. For example, each half is 32 crypto-sudo-random bytes that are concatenated to form the full secret key.
I understand generally it is not recommended to hide secret keys in source code as source code is difficult to keep secret, but I cannot see anything but advantages by employing this. If the source code key is stolen, the configuration key is still hidden and too long to be brute forced. Alternatively, if an attacker manages to steal the configuration key but does not keep a copy of the compiled source code's key, they still cannot forge the JWT tokens signatures.
Therefore my question is: Am I over looking some sort of obvious flaw in this design or does it truly provide at least a little bit better security? Furthermore, if there is no obvious flaw, is it reasonable to believe this truly does add to the protection of the secret key?