I'd like to suggest an alternative, since making multiple columns a clustered key increases the size, and degrades performance of all your non-clustered indexes on the target table. Remember, the cluster key gets stored in all non-clustered indexes whether you ask for it or not.

Merges perform best when both source and target tables are in the same sequence order. Presumably you have your source table ordered by the compound key. So read through it, joining to the target table using the compound key. But write your data out to a new working table that includes the single (primary) key, and is indexed on that key. This working table will be the source of your merge.

Yes, you are reading through your input values twice, but as you pointed out, scanning a table of 10 million rows doesn't take that long at all.

Something to try anyway.