Generate 2 independent keys from a master key The scenario is like this: I need 2 keys for different purposes (encryption + encryption, encryption + mac, or whatever). Because it is not good practice to reuse the same key, I'd like the 2 keys to be independent. But remembering 2 different keys are cumbersome (don't question this please), so I think there should be some way to generate these keys from one common master key.

The closest crypto tool for this job I can find is a KDF. However, the KDF usually takes as an additional input: the salt. Should I randomly generate and remember a salt, or simply use a hash function such as SHA512 and divide its output into 2 keys? 

I think in this scenario, there's no need to worry about the possible recovery of the master key from the derived keys, because the derived keys are no less important than the master key. The compromise of the derived keys is just as bad as that of the master key. The importance is instead focused on the independence between the 2 derived keys, since at least there are some encryption and mac schemes such that, when used together, would become totally broken if keys are not independent.
The purpose of the salt is to limit the cost that an adversary can share between multiple targets.  The salt need not be random.  It need only be unique per user.

If two users share a salt (possibly an empty salt), then the work to find at least one of their keys can be shared with Oechslin's rainbow tables on a parallel machine so that the expected cost to find at least one of their keys in a batch multi-target attack is about half the expected cost of a single-target attack, and the expected time to find at least one of their keys is at most one eighth the expected time of a single-target attack.

In general, if there are $n$ possible keys, and $t$ targets, and you parallelize the computation about $p \geq t^2$, then the expected cost to find at least one is $n/t$ and the expected time to find the first one is $n/pt$, at most about $n/t^3$.

If you use 256-bit keys, then the number of users necessary to make this significant is impossibly high, so you can safely use an empty salt in that case.  The salt is important only for ≤128-bit keys.  (This is why AES-128 should already be considered to have a &lt;128-bit security level, and why you should use AES-256 anyway.)

If you have a notion of a user id unique to a key, you could just concatenate it with the name of your application as the salt, with no need for storage.  If you don't have a notion of a unique user id, using a random salt reduces the probability that the adversary can share work between two attack targets.  The longer the salt, the lower the probability of a collision enabling the adversary can share work.  Use a 256-bit salt, and there will never be a collision unless your implementation is broken.
A secondary purpose of a KDF is to map a high-entropy but possibly nonuniform secret into a uniform secret.  If your master key came from a Diffie–Hellman key agreement and is the bit string encoding of some unique representative of a residue class modulo a large safe prime, or is the byte string encoding of a point on an elliptic curve, then the master key is not uniformly distributed among bit strings, but does have high entropy.  A KDF smooths out the distribution on bit strings so it is effectively uniform.
The purpose of a password hash (scrypt, argon2, etc.) is to use all your available resources to drive up the cost of a single evaluation of the hash, which a brute force attack must do repeatedly.  Willing to spend 1sec on hashing?  Force the adversary to compute two million (say) HMAC-SHA256 computations instead of one for each guess.  Willing to spend 1 GB RAM on hashing?  Force the adversary to commit the area of 1 GB RAM in each parallel hashing circuit—which otherwise could have been dedicated to many more parallel hashing circuits if it were not memory-hard, like PBKDF2—or spend double the time hashing if they can only fit 512 MB RAM, etc.  If you can't raise the number of possibilities for the secret, e.g. if your secret was chosen by a human, you can at least raise the cost of testing each possibility in a brute force attack.


These considerations apply independently:


Have a human-chosen password?  Probably has ≪128 bits entropy.  Use a password hash like argon2id with a salt to (a) drive up the cost of each guess, (b) map a nonuniform bit string into a uniform bit string, and (b) prevent the adversary from sharing work between multiple targets.  Make sure if the user ever changes the password, the salt changes too, so if it's deterministically chosen, it can't just be an application name and user id—it must also include, say, a revision number.
Have a machine-generated memorable diceware password chosen from ${\sim}2^{128}$ possibilities?  Use a KDF like HKDF with a salt to (a) turn a nonuniform bit string of 128 bits entropy into a uniform bit string, and (b) prevent the adversary from sharing work between multiple targets.  Using a password hash to drive up the cost of each guess doesn't hurt if this is only ever used in an interactive application, but it's not necessary.
Have a shared secret encoding of an $x$ coordinate on Curve25519 from an X25519 key agreement, so that $x^3 + 486662 x^2 + x$ is a quadratic residue modulo $2^{255} - 19$?  Use a KDF like HKDF to turn it into a uniform random bit string.  Salting doesn't hurt in this case, but it's not necessary.