The concept is much easier to understand if the correct terminology is used, particularly making a distinction between URLs and file paths:
# Externally redirect direct client requests for old unfriendly URLs to new friendly URLs
RewriteCond %{THE_REQUEST} ^[A-Z]+\ /old_url_plus_query_string HTTP/
RewriteRule ^old_url$ http://www.example.com/new_url [R=301,L]
#
# Internally rewrite requests for new friendly URLs to index.php script filepath plus query string
RewriteRule ^new_url$ /script_filepath_plus_query [L]
Note also the form of THE_REQUEST, which is the entire HTTP request line as it appears in your raw server access logs, for example:
GET /index.php?var1=x&var2=y&var3=z HTTP/1.1
The old search-engine-unfriendly url-path used to be the same as the internal server filepath.
Now we are using (linking to) a new search-engine-friendly URL (it is a real URL and there is nothing 'virtual' about it), and we are mapping that URL, when requested from the server, to the correct internal filepath+query string needed to generate the content for that new URL.
So this new rule is used to redirect client requests (and only client requests) for the old URL to the new URL.
You may need ten new redirect rules, or you may need fewer. It all depends on the old URLs that you need to redirect, and whether you can devise regular-expressions patterns that will allow you use fewer than ten rules (by "sharing" one rule so that it redirects more than one of the ten "kinds" of the old URLs).
Jim