They sound similar but they answer different questions.
A Profile answers "what can this user do?" — what objects, fields, apps, and system permissions they have. It controls things like Create/Read/Edit/Delete on objects, Field-Level Security, login hours, and IP restrictions. Every user has exactly one profile.
A Role answers "what records can this user see?" — its only job is to plug the user into the Role Hierarchy, which is what enables managers to see records owned by their reports. A user can exist without a role, in which case they sit at the very top of the hierarchy and don't gain hierarchical access. Roles do not grant any object-level or field-level permission.
So in a typical org you might have one profile called Sales User and use roles to model the org chart — VP Sales > Director > Manager > Rep. Every Sales User has the same profile (same permissions) but different roles (different visibility into reports' opportunities).
A useful diagnostic: if a user can't do something (create a record, edit a field), check the profile and any permission sets. If a user can't see a record they should be able to, check the role hierarchy, sharing rules, and OWD — not the profile.