이기종 마이그레이션에서 사용자와 권한 이관은 종종 작업의 뒷자리로 밀립니다. "DDL이 끝나면 USER 만들고 GRANT 좀 정리하면 되는 일"이라는 인식 때문입니다. 그런데 실제로 작업을 시작하면 가장 먼저 막히는 곳도 이 영역입니다.

이유는 단순합니다. USER, SCHEMA, ROLE이라는 같은 단어가 DB마다 다른 구조를 가리키기 때문입니다. Oracle의 USER는 계정이자 스키마이자 저장 단위이고, PostgreSQL의 ROLE은 계정일 수도 권한 묶음일 수도 있으며, MySQL의 DATABASE는 곧 SCHEMA입니다. 단어 하나가 양쪽에서 다른 것을 의미하기 때문에, 어느 쪽으로 옮기든 1:1 매핑은 성립하지 않습니다.

이 글은 양방향, 즉 Oracle → 오픈소스와 오픈소스 → Oracle을 모두 다룹니다. 어느 방향이든 USER를 그대로 옮기는 작업이 아니라, 각 USER가 실제로 어떤 역할을 하고 있는지 먼저 분해하고, 타겟 DB의 묶음 방식에 맞춰 다시 조립하는 작업이 필요합니다.

세 DB의 USER, SCHEMA, ROLE — 같은 단어, 다른 구조

표에서 "객체 컨테이너 계층"과 "SQL상 객체 식별"을 분리한 이유는, 두 축이 같지 않기 때문입니다. PostgreSQL은 한 CLUSTER 안에 여러 DATABASE가 존재하지만, SQL 안에서 다른 DATABASE의 객체를 database.schema.object로 참조할 수는 없습니다. cross-database 조회 자체가 불가능하고, 필요하다면 dblink 또는 postgres_fdw로 우회해야 합니다. MySQL은 반대로 한 INSTANCE 안의 모든 DATABASE를 database.table 자격으로 직접 조회할 수 있습니다.

Oracle은 11g까지는 한 DATABASE 안에 모든 USER/SCHEMA가 존재하는 단일 구조였지만, 12c부터 Multitenant 아키텍처가 도입되어 한 CDB(Container Database) 안에 여러 PDB(Pluggable Database)가 존재할 수 있게 되었습니다. PDB는 PostgreSQL의 DATABASE에 가까운 격리 단위로 동작합니다. 19c 이후로는 CDB 구성이 사실상 표준이고, 멀티테넌트 환경의 PDB 단위 격리는 이관 시 중요한 매핑 후보가 됩니다.

이 표가 보여주는 것은 명칭의 차이가 아닙니다. 세 DB가 "사용자라는 개념"을 서로 다른 방식으로 쪼개고 묶어두었다는 사실입니다. Oracle은 USER 안에 계정, 스키마, 저장 단위를 묶었고 ROLE은 별도의 권한 묶음으로 두었습니다. PostgreSQL은 USER와 GROUP을 ROLE 하나로 통합하면서 스키마는 따로 떼어 냈습니다. MySQL은 DATABASE와 SCHEMA를 통합하면서, 사용자는 호스트와 결합된 형태로 별도 관리합니다. 어느 쪽으로 옮기든, 한 DB에서 묶여 있던 것을 풀어내고 다른 DB의 묶음에 다시 끼워 넣어야 합니다.

USER를 옮기기 전에, USER의 실체를 먼저 분류해야 한다

이관의 시작은 타겟 DB의 어떤 객체를 만들지가 아니라, 소스 DB의 USER가 실제로 어떤 역할을 하고 있는지 분류하는 것입니다. 이 분류 없이 USER를 1:1로 옮기면, 권한 묶음으로만 쓰이던 계정이 접속 가능한 사용자가 되거나, 사람이 접속하던 계정이 권한이 없는 빈 컨테이너가 됩니다.

Oracle USER는 보통 다음 네 가지 역할 중 하나 또는 복수에 해당합니다.

첫째, 실제 접속하는 사람 또는 애플리케이션 계정입니다. 자신의 객체를 가질 수도 있고, 다른 스키마의 객체에만 접근할 수도 있습니다.

둘째, 객체 소유자 역할의 스키마 컨테이너입니다. 직접 접속하지 않고 객체만 보관합니다. 운영 환경에서는 패스워드를 잠가두거나(ACCOUNT LOCK) 강한 패스워드 정책을 적용해 접속을 차단합니다.

셋째, 권한 묶음 역할입니다. Oracle에는 ROLE이 있지만, 일부 조직은 통제 편의 때문에 USER 단위로 권한을 모아두고 다른 USER에게 객체 권한을 GRANT 합니다. 형태는 USER지만 실질적으로는 ROLE입니다.

넷째, 레거시로 남아 있는 사용 중단 계정입니다. 객체도 없고 GRANT만 일부 남아 있는 경우입니다.

이 분류가 끝나야 타겟 DB에서 어떤 객체로 만들지 결정할 수 있습니다. 첫째는 LOGIN 가능한 USER 또는 ROLE로, 둘째는 NOLOGIN ROLE이나 객체 소유자 전용 ROLE로, 셋째는 권한 묶음 ROLE로 분해되고, 넷째는 이관 대상에서 제외하는 것이 자연스러운 선택입니다. 모든 USER를 타겟의 USER로 옮기는 것이 아니라, USER의 실제 역할에 맞는 객체 종류를 다시 골라주는 작업입니다.

역방향도 마찬가지입니다. PostgreSQL ROLE은 LOGIN 여부, INHERIT 여부, 다른 ROLE의 멤버 여부 조합에 따라 역할이 다릅니다. MySQL은 사용자가 호스트와 결합된 단위로 식별되어 같은 사용자명이라도 접속 경로별로 별개의 USER가 존재할 수 있습니다. 이 차이를 무시하고 Oracle USER로 통합하면, 분리되어 있던 권한 경계가 사라집니다.

Oracle → 오픈소스: USER를 분해해야 한다

분류가 끝났다면 타겟 DB의 구조에 맞춰 분해 전략을 세웁니다. 타겟이 PostgreSQL인지 MySQL인지에 따라 결정 사항이 다릅니다.

타겟이 PostgreSQL인 경우, 가장 먼저 결정해야 할 것은 Oracle의 다중 USER를 PostgreSQL의 어느 단위로 흡수할지입니다.

단일 DATABASE 안의 다중 SCHEMA로 흡수하는 방식이 일반적입니다. Oracle의 cross-schema 조회 패턴을 그대로 유지할 수 있고, 백업과 운영이 단일 DATABASE 단위로 통합됩니다. 권한은 SCHEMA 단위로 통제하되, 객체 소유자 ROLE을 별도로 두고 접속 계정 ROLE에 권한을 GRANT 하는 방식으로 구성합니다. 즉 Oracle의 "USER 1개"가 PostgreSQL에서는 "SCHEMA 1개 + 객체 소유자 ROLE 1개 + 접속 계정 ROLE 1개"로 분해되는 패턴입니다.

다중 DATABASE 전략은 USER 또는 업무 단위별로 DATABASE를 분리하는 방식입니다. 격리는 가장 강하지만 DATABASE 간 직접 조회가 불가능하므로, dblink나 postgres_fdw로 우회해야 하고 트랜잭션 일관성이 깨집니다. 다만 소스 Oracle이 이미 12c+ CDB/PDB 구조에서 PDB 단위로 격리되어 운영되고 있었다면, 이 전략이 자연스러운 선택지입니다. Oracle PDB와 PostgreSQL DATABASE는 컨테이너 격리 측면에서 가장 가까운 매핑이고, PDB 단위로 분리되어 있던 cross-PDB 의존성이 거의 없는 시스템이라면 PostgreSQL에서 다중 DATABASE 구조로 이어 가는 것이 운영 모델 변경을 최소화합니다.

타겟이 MySQL인 경우, MySQL에는 SCHEMA가 별도 객체로 존재하지 않습니다. DATABASE가 곧 SCHEMA입니다. Oracle USER 하나는 MySQL DATABASE 하나에 대응되고, 그 안의 객체는 모두 같은 DATABASE 아래에 놓입니다. cross-database 조회는 database.table 형식으로 가능하지만, PostgreSQL SCHEMA처럼 search_path로 묶을 수 있는 단위가 없어 무자격 객체명에 의존하던 SQL은 모두 자격을 붙이거나 USE 후 실행되어야 합니다.

MySQL에서 사용자는 'user'@'host' 형식으로 정의되며, 호스트가 다르면 사용자명이 같아도 별개의 USER로 취급되고 권한도 독립적으로 관리됩니다. Oracle에서 sqlnet.ora의 TCP.INVITED_NODES나 Connection Manager로 분리하던 접속 통제가 MySQL에서는 USER 정의 자체로 흡수됩니다. 따라서 Oracle USER 하나를 MySQL로 옮길 때, 어느 접속 경로를 허용할지를 USER 정의 시점에 함께 결정해야 합니다.

MySQL ROLE은 8.0부터 지원되지만 활성화가 명시적입니다. 세션마다 SET ROLE을 호출하거나 activate_all_roles_on_login을 켜야 합니다. Oracle의 DEFAULT ROLE 동작(뒤에서 다룸)을 그대로 가져가려면 이 설정을 함께 검토해야 합니다. 5.x에서 올라오는 환경이라면 ROLE 자체가 없으므로, 권한 묶음을 USER 사이에 반복 GRANT 하던 패턴을 ROLE 기반으로 재정리하는 기회로 삼을 수 있습니다.

오픈소스 → Oracle: ROLE과 SCHEMA를 다시 묶어야 한다

역방향은 반대의 작업입니다. 분리되어 있던 ROLE과 SCHEMA를 Oracle의 USER라는 단위로 다시 묶어야 합니다.

PostgreSQL → Oracle 방향에서 가장 자주 부딪히는 문제는 ROLE과 SCHEMA의 소유 관계입니다. PostgreSQL에서는 한 ROLE이 여러 SCHEMA의 객체를 소유할 수 있고, 한 SCHEMA 안에 여러 ROLE 소유의 객체가 섞일 수도 있습니다. Oracle에서는 객체 소유자가 곧 SCHEMA이기 때문에, 이 다대다 관계를 분해해야 합니다.

가장 단순한 방식은 PostgreSQL의 SCHEMA를 Oracle USER로 매핑하는 것입니다. SCHEMA가 5개라면 Oracle USER 5개를 만들고, 각 SCHEMA의 객체를 해당 USER로 옮깁니다. 그런데 이 매핑은 객체 소유자가 누구냐와 별개로 이루어집니다. PostgreSQL에서 객체 소유자였던 ROLE은 Oracle에서는 별도의 USER 또는 ROLE로 두고, 접속과 권한만 부여하는 형태로 분리합니다.

PostgreSQL의 LOGIN 가능 ROLE은 Oracle USER로, NOLOGIN ROLE은 Oracle ROLE로 옮기는 것이 자연스럽습니다. 한 ROLE이 LOGIN 가능하면서 다른 ROLE의 멤버로 권한을 받는 경우, Oracle에서는 USER + GRANT ROLE 조합으로 재현됩니다.

또 하나의 함정은 search_path입니다. PostgreSQL에서 무자격 객체명에 의존하던 SQL은 Oracle에서 SYNONYM이나 명시적 SCHEMA 자격으로 다시 작성해야 합니다. ROLE 단위 또는 DATABASE 단위로 설정되어 있던 search_path 기본값이 무엇이었는지를 먼저 추출하고, 그 의도를 Oracle SYNONYM 정책으로 번역해야 합니다. PostgreSQL이 다중 DATABASE 구조였다면 Oracle 12c+의 PDB 단위로 매핑하는 것이 격리 의도를 가장 잘 보존합니다.

MySQL → Oracle 방향에서는 DATABASE를 Oracle의 어떤 단위로 받을지가 첫 결정입니다. MySQL DATABASE는 Oracle USER에 대응시키는 것이 일반적입니다. DATABASE = SCHEMA이고 Oracle에서는 USER = SCHEMA이기 때문입니다. 그런데 MySQL에서 같은 사용자명이 여러 호스트 정의로 분리되어 서로 다른 권한을 갖고 있었다면, Oracle USER 하나로 합치는 순간 그 분리가 사라집니다. 분리를 유지하려면 별도 USER로 쪼개거나, Oracle Listener의 TCP.INVITED_NODES/TCP.EXCLUDED_NODES, Database Vault Connect Command Rule 같은 접속 단계 통제로 옮겨야 합니다.

MySQL ROLE은 8.0 이상에서만 존재하므로 소스 버전에 따라 권한 묶음의 표현 방식이 다릅니다. 5.x에서는 같은 권한 묶음이 여러 USER에 반복 GRANT 되어 있는 경우가 많고, 이 패턴은 Oracle로 옮길 때 ROLE로 통합하는 정리 기회가 됩니다. 8.0 ROLE이라면 Oracle ROLE에 자연스럽게 대응됩니다.

무자격 객체 참조 — SYNONYM ↔ search_path ↔ USE

세 DB는 "객체 이름만 적었을 때 어디서 찾을지"를 모두 다른 방식으로 결정합니다.

Oracle은 SYNONYM으로 해결합니다. CREATE PUBLIC SYNONYM EMP FOR HR.EMP로 정의하면 모든 USER가 SELECT * FROM EMP로 접근할 수 있습니다. PRIVATE SYNONYM은 USER별로 자기만의 별칭을 두는 방식입니다.

PostgreSQL은 search_path로 결정합니다. 세션, ROLE, DATABASE 단위로 검색 순서를 설정하고, 무자격 객체명은 이 순서대로 SCHEMA를 훑어가며 찾습니다.

MySQL은 USE database 명령이나 database.table 자격 표기로 결정합니다. SCHEMA 검색 경로 같은 개념이 없어 컨텍스트 전환이 명시적입니다.

방향에 따라 신경 써야 할 지점이 다릅니다.

Oracle → PostgreSQL/MySQL 방향에서는 SYNONYM을 어떻게 대체할지가 핵심입니다. PostgreSQL은 search_path와 VIEW의 조합으로 부분적으로 재현 가능하지만, SECURITY DEFINER 함수의 search_path가 의도하지 않은 SCHEMA를 가리킬 경우 권한 상승 취약점이 될 수 있어 함수 정의 시 SET search_path 절을 명시하는 운영 규칙이 함께 필요합니다. MySQL은 search_path 자체가 없으므로 모든 SQL이 database.table 자격을 갖추거나 USE 후 실행되는 구조로 바뀌어야 합니다. SYNONYM에 의존하던 SQL이 광범위하다면, MySQL 이관은 SQL 재작성 범위가 PostgreSQL 이관보다 훨씬 큽니다.

PostgreSQL/MySQL → Oracle 방향에서는 반대로 search_path와 USE에 의존하던 SQL을 SYNONYM이나 명시적 SCHEMA 자격으로 전환해야 합니다. PostgreSQL의 경우 search_path가 ROLE/DATABASE 단위로 어떻게 설정되어 있었는지 그 의도를 먼저 추출해야 하고, MySQL의 경우 애플리케이션이 어떤 DATABASE를 USE 하고 있었는지를 파악해야 Oracle에서 SYNONYM 정책을 설계할 수 있습니다.

권한 모델 — GRANT의 의미가 같지 않다

세 DB 모두 ROLE 활성화 메커니즘 자체는 존재합니다. 차이는 기본 동작이 자동이냐 명시냐, 그리고 권한 누적이 inherit 기반이냐 활성화 기반이냐에 있습니다.

Oracle에서 USER에 ROLE을 GRANT 하면 그 ROLE은 기본적으로 DEFAULT ROLE이 되어 로그인 시 자동 활성화됩니다. 별도 호출 없이 권한을 행사할 수 있습니다. 다만 ALTER USER ... DEFAULT ROLE NONE 또는 명시적으로 NON-DEFAULT로 부여된 ROLE, 그리고 IDENTIFIED BY password가 걸린 보호된 ROLE은 세션 안에서 SET ROLE 호출이 필요합니다. 실무에서 대부분의 ROLE이 DEFAULT로 운영되기 때문에 자동 활성화처럼 느껴질 뿐, 활성화 메커니즘 자체는 PostgreSQL/MySQL과 동일하게 존재합니다.

PostgreSQL의 ROLE은 더 일반화된 개념입니다. ROLE은 USER일 수도 GROUP일 수도 있고, 다른 ROLE을 멤버로 가질 수 있습니다. 멤버 ROLE이 부모 권한을 자동으로 행사할지는 INHERIT / NOINHERIT 속성에 따라 갈립니다. 기본값은 INHERIT이라 부모 ROLE의 권한이 자동으로 누적됩니다. NOINHERIT로 정의된 ROLE의 멤버만 SET ROLE을 호출해야 권한을 사용할 수 있습니다. 또한 PostgreSQL에는 DEFAULT PRIVILEGES가 있어, 특정 ROLE이 앞으로 만들 객체에 대한 권한을 미리 정의할 수 있습니다.

MySQL 8.0의 ROLE은 GRANT 받은 시점에는 비활성 상태가 기본입니다. 세션마다 SET ROLE을 호출하거나 activate_all_roles_on_login을 켜야 합니다. 권한은 *.*, db.*, db.table, db.table(col) 네 단계로 부여됩니다.

차이를 한 표로 정리하면 다음과 같습니다.

이관 시 자주 발생하는 사고는 방향에 따라 다릅니다.

Oracle → 오픈소스에서 가장 흔한 사고는 PostgreSQL의 DEFAULT PRIVILEGES를 설정하지 않아, 이관 후 새로 만들어지는 객체에 권한이 자동 부여되지 않는 경우입니다. 운영 안정화 후 "왜 이 ROLE이 새 테이블을 못 보는가"라는 질문이 반복되는 이유가 여기 있습니다. Oracle은 새 객체에 대한 GRANT를 매번 명시적으로 부여하는 운영 관행이라 이 자동화 메커니즘 자체가 누락되는 경우가 많습니다. MySQL로 옮기는 경우에는 ROLE 활성화 기본값 차이로, GRANT 했는데 권한이 작동하지 않는 케이스가 나타납니다.

Oracle 시스템 권한(SELECT ANY TABLE, INSERT ANY TABLE 등) 대응은 타겟 버전에 따라 달라집니다. PostgreSQL 14부터는 pg_read_all_data, pg_write_all_data 같은 predefined role이 도입되어, 한 줄 GRANT로 모든 SCHEMA의 데이터 접근 권한을 부여할 수 있습니다. 13 이하 버전에서는 SCHEMA별로 명시적 GRANT를 반복하거나 이벤트 트리거로 자동 부여해야 했습니다. 다만 14 이상에서도 CREATE ANY TABLE 같은 DDL ANY에 해당하는 predefined role은 존재하지 않으므로, 운영 계정의 객체 생성 권한은 슈퍼유저 권한 또는 이벤트 트리거로 보완해야 합니다. MySQL은 *.* 수준의 GRANT가 ANY 권한에 해당합니다.

오픈소스 → Oracle에서는 반대 문제가 생깁니다. PostgreSQL DEFAULT PRIVILEGES로 자동 부여되던 권한은 Oracle에 직접 대응되는 기능이 없어, 객체 생성 트리거나 운영 절차로 보완해야 합니다. PostgreSQL의 컬럼 단위 GRANT는 Oracle에서도 가능하지만 운영 관행상 흔하지 않아 검토 누락이 자주 발생합니다. PostgreSQL의 INHERIT/NOINHERIT 차이는 Oracle의 DEFAULT/NON-DEFAULT ROLE 설정으로 부분적으로 재현할 수 있지만, ROLE 멤버십을 SET ROLE로 동적으로 전환하던 PostgreSQL 패턴을 Oracle로 그대로 옮기기는 어렵습니다. 세션 내 권한 전환이 자주 발생하던 시스템이라면 권한 모델 재설계가 필요합니다.

데이터 딕셔너리 의존 코드 — 운영 자동화의 사각지대

USER와 권한 이관에서 가장 자주 누락되는 영역이 데이터 딕셔너리 의존 코드입니다.

세 DB의 카탈로그 구조는 모두 다릅니다. Oracle은 DBA_*, ALL_*, USER_* 뷰를 제공하고, 12c+ CDB 환경에서는 CDB_* 뷰가 추가되어 PDB 전체를 조회할 수 있습니다. PostgreSQL은 information_schema(SQL 표준)와 pg_catalog(고유)를 함께 제공하며, MySQL은 information_schema, performance_schema, 그리고 mysql 시스템 스키마를 제공합니다.

이름이 비슷한 컬럼이라도 의미가 다르고, 각 DB 고유 정보 중 일부는 표준 information_schema에 존재하지 않아 각 DB의 고유 카탈로그로 우회해야 합니다. 인덱스 크기, 테이블 통계, 시퀀스의 현재값 같은 정보는 표준 뷰에 없습니다.

방향과 관계없이 이관 순서는 같습니다. 첫째, 소스 DB의 카탈로그를 참조하는 모든 SQL을 전수 추출합니다. 둘째, 각 SQL이 어떤 정보를 가져오는지 분류합니다. 셋째, 타겟 DB의 어떤 카탈로그로 대체할지 매핑합니다. 이 작업을 이관 후로 미루면, 오픈 직후 모니터링이 작동하지 않는 사각지대가 생기고, 그 사각지대가 운영 안정화 기간 전체에 그늘을 드리웁니다.

결론

사용자와 권한 이관은 GRANT 문장을 옮기는 일이 아닙니다. 소스 DB가 USER/ROLE/SCHEMA라는 단어 안에 묶어두었던 역할들을 풀어내고, 타겟 DB의 묶음 방식에 맞춰 다시 조립하는 작업입니다. 그래서 모든 USER가 타겟의 USER가 되지 않고, 모든 ROLE이 타겟의 ROLE이 되지도 않습니다. 각 객체의 실제 역할에 맞는 자리를 다시 골라주는 일입니다.

방향에 관계없이 네 가지 질문으로 수렴됩니다.

첫째, 소스 DB의 USER/ROLE 각각이 실제로 어떤 역할(접속 계정, 스키마 컨테이너, 권한 묶음, 사용 중단)을 하고 있는가.

둘째, 무자격 객체 참조에 의존하는 SQL이 어디에 얼마나 있고, 타겟 DB의 메커니즘(SYNONYM, search_path, USE)으로 어떻게 대체할 것인가.

셋째, 권한 모델의 자동 활성화 기본값, 미래 객체 권한 부여, 컨테이너 단위 격리(Oracle PDB ↔ PostgreSQL DATABASE) 같은 소스 DB의 동작을 타겟 DB에서 어떻게 재현할 것인가.

넷째, 데이터 딕셔너리에 의존하는 운영 스크립트는 얼마나 존재하고, 어떤 카탈로그로 옮길 것인가.

이 질문에 답이 나오기 전에 USER 생성 스크립트를 짜기 시작하면, 작업은 진행되지만 설계는 부재한 상태가 됩니다. 그리고 이 부재는 오픈 후 권한 사고나 운영 자동화의 공백으로 돌아옵니다.

USER가 함께 가지고 있던 또 하나의 측면, 즉 DEFAULT TABLESPACE와 객체가 실제로 어떤 물리 공간에 어떻게 놓이는지는 다음 글에서 이어서 살펴봅니다. 사용자라는 단위에서 "누구의 것인가"를 분리해 냈다면, 이제 "어디에 놓이는가"가 남습니다.