Oracle Synonym(시노님)

1. Synonym이란?

Synonym(시노님) 은 Oracle DB에서 테이블, 뷰, 시퀀스, 프로시저 등 다양한 객체에 별명(Alias)을 붙이는 기능입니다.

쉽게 말해, 실제 객체 이름 대신 내가 원하는 이름으로 접근할 수 있게 해주는 별명표 같은 개념입니다.

실제 객체: HR.EMPLOYEES
시노님:    EMP  ← 이걸로 접근 가능

 

---

2. Synonym을 사용하는 이유

2-1) 다른 스키마 객체에 간편하게 접근

다른 스키마의 테이블을 참조할 때 원래는 스키마명.테이블명 형식으로 써야 합니다.

-- 시노님 없이
SELECT * FROM HR.EMPLOYEES;
SELECT * FROM SCOTT.DEPT;

-- 시노님 사용 후
SELECT * FROM EMP;   -- HR.EMPLOYEES를 가리키는 시노님
SELECT * FROM DEPT;  -- SCOTT.DEPT를 가리키는 시노님

 

2-2) 긴 객체 이름을 짧게

-- 시노님 없이
SELECT * FROM SYSTEM.DBA_LONG_TABLE_NAME_REPORT_2024;

-- 시노님 사용 후
SELECT * FROM REPORT;

 

2-3) 위치 투명성 (Location Transparency)

실제 객체의 위치(스키마, DB 링크 등)가 바뀌어도
시노님만 수정하면 되므로 애플리케이션 코드를 변경할 필요가 없습니다.

기존: APP_USER.ORDER_TABLE → 시노님: ORDERS
변경: NEW_SCHEMA.ORDER_TABLE → 시노님: ORDERS (시노님만 재생성)
→ 애플리케이션 코드 변경 없음 ✅

 

---

3. Synonym의 종류

Oracle Synonym은 Private과 Public 두 가지로 나뉩니다.

구분	Private Synonym	Public Synonym
접근 범위	생성한 사용자만 사용 가능	모든 사용자 사용 가능
생성 권한	일반 사용자 가능	DBA 권한 필요
생성 키워드	CREATE SYNONYM	CREATE PUBLIC SYNONYM
주 용도	개인 편의용	공통 객체 공유용
충돌 시 우선순위	✅ Private이 우선	Public은 후순위

 

---

4. 기본 문법

시노님 생성

-- Private Synonym 생성
CREATE SYNONYM 시노님명
FOR 스키마명.객체명;

-- Public Synonym 생성 (DBA 권한 필요)
CREATE PUBLIC SYNONYM 시노님명
FOR 스키마명.객체명;

 

시노님 삭제

-- Private Synonym 삭제
DROP SYNONYM 시노님명;

-- Public Synonym 삭제
DROP PUBLIC SYNONYM 시노님명;

 

시노님 재생성 (OR REPLACE)

-- 기존 시노님을 삭제하지 않고 바로 교체
CREATE OR REPLACE SYNONYM 시노님명
FOR 스키마명.객체명;

 

---

5. 시노님 정보 조회

생성된 시노님 목록을 확인하는 방법입니다.

내 계정의 시노님 조회

-- 현재 사용자의 Private 시노님 목록
SELECT SYNONYM_NAME,
       TABLE_OWNER,
       TABLE_NAME
FROM USER_SYNONYMS
ORDER BY SYNONYM_NAME;

 

예시

SYNONYM_NAME	TABLE_OWNER	TABLE_NAME
EMP	HR	EMPLOYEES
EMP_SEQ	HR	EMPLOYEES_SEQ
EMP_VIEW	HR	EMP_DETAILS_VIEW
DEPT	SCOTT	DEPT

 

모든 시노님 조회 (DBA 권한)

-- 전체 시노님 조회 (DBA 권한 필요)
SELECT OWNER,
       SYNONYM_NAME,
       TABLE_OWNER,
       TABLE_NAME
FROM DBA_SYNONYMS
WHERE TABLE_OWNER = 'HR'  -- 특정 스키마 필터링
ORDER BY SYNONYM_NAME;

 

Public 시노님 조회

-- Public 시노님 조회
SELECT SYNONYM_NAME,
       TABLE_OWNER,
       TABLE_NAME
FROM ALL_SYNONYMS
WHERE OWNER = 'PUBLIC'
ORDER BY SYNONYM_NAME;

 

---

6. Private vs Public 시노님 우선순위

같은 이름의 Private과 Public 시노님이 동시에 존재할 경우, Private 시노님이 우선 적용

-- Public 시노님 생성 (DBA가 생성)
CREATE PUBLIC SYNONYM EMP FOR HR.EMPLOYEES;

-- Private 시노님 생성 (일반 사용자가 생성)
CREATE SYNONYM EMP FOR SCOTT.EMP;

-- EMP 조회 시 → Private 시노님 우선 적용
SELECT * FROM EMP;  -- SCOTT.EMP 조회됨

우선순위
1순위: 자신의 스키마에 있는 실제 객체
2순위: Private Synonym
3순위: Public Synonym

---

7. DB Link와 함께 사용

원격 DB의 객체를 로컬처럼 사용할 때 시노님과 DB Link를 함께 활용합니다.

-- DB Link 생성
CREATE DATABASE LINK remote_db
CONNECT TO user IDENTIFIED BY password
USING 'remote_tns';

-- 원격 DB 테이블에 시노님 생성
CREATE SYNONYM REMOTE_EMP
FOR HR.EMPLOYEES@remote_db;

-- 시노님으로 원격 DB 조회 (로컬처럼 사용)
SELECT * FROM REMOTE_EMP;
-- HR.EMPLOYEES@remote_db 와 동일

 

---

8. 자주 쓰이는 패턴

패턴 1 — 공통 테이블 Public 시노님

여러 스키마에서 공통으로 사용하는 코드성 테이블에 Public 시노님을 생성합니다.

-- DBA가 공통 코드 테이블에 Public 시노님 생성
CREATE PUBLIC SYNONYM COMMON_CODE
FOR COMMON.CODE_MASTER;

-- 모든 사용자가 스키마 없이 바로 사용
SELECT * FROM COMMON_CODE WHERE CODE_TYPE = 'STATUS';

 

패턴 2 — 스키마 변경 시 시노님만 교체

객체가 다른 스키마로 이동했을 때 시노님만 재생성합니다.

-- 기존: APP_USER 스키마의 ORDERS 테이블
CREATE SYNONYM ORD FOR APP_USER.ORDERS;

-- 스키마 변경 후: NEW_USER 스키마로 이동
CREATE OR REPLACE SYNONYM ORD FOR NEW_USER.ORDERS;
-- 애플리케이션 코드 변경 없이 그대로 사용 가능 ✅

 

패턴 3 — 개발/운영 환경 분리

-- 개발 환경
CREATE OR REPLACE SYNONYM ORDERS FOR DEV_SCHEMA.ORDERS;

-- 운영 환경
CREATE OR REPLACE SYNONYM ORDERS FOR PROD_SCHEMA.ORDERS;

-- 쿼리는 동일하게 사용
SELECT * FROM ORDERS;

 

---

9. 환경별 시노님(개발, 스테이징) 구성이 다른 이유

실무에서 DEV/STG/PROD 환경을 다루다 보면 이런 의문을 가지게 되었던 것 같습니다.

 

DEV(개발) 서버에는 시노님이 없는데, STG(스테이징) 서버에는 별도 스키마에 시노님이 걸려있다. 왜 그런걸까?

 

DEV 서버 — 시노님 없음

[DEV 서버]
  스키마: comet (단일 스키마)

  개발자가 직접 comet 스키마에 접속
  → 같은 스키마니까 시노님 불필요
  → SELECT * FROM 테이블명 으로 바로 접근

DEV는 개발자가 직접 해당 스키마에 붙어서 개발하기 때문에 굳이 시노님을 걸 이유가 없습니다.
빠르게 개발하고 테스트하는 환경이라 단순하게 유지합니다.

 

STG 서버 — 별도 스키마 + 시노님

[STG 서버]
  스키마 1: comet    ← 실제 데이터/객체가 있는 스키마
  스키마 2: cometqa  ← 테스트용 접속 계정 스키마

  cometqa 입장에서 comet은 남의 스키마
  → comet.테이블명 으로 접근해야 함
  → 근데 매번 comet. 붙이기 번거롭고
  → 애플리케이션 코드가 DEV랑 달라지면 안 되니까
  → 시노님으로 comet.테이블 → 테이블명 으로 별칭

-- STG 서버에서 cometqa 스키마에 시노님 생성
CREATE SYNONYM ORDERS FOR COMET.ORDERS;
CREATE SYNONYM MEMBERS FOR COMET.MEMBERS;

-- 이제 cometqa에서 스키마명 없이 접근 가능
SELECT * FROM ORDERS;   -- COMET.ORDERS와 동일
SELECT * FROM MEMBERS;  -- COMET.MEMBERS와 동일

 

핵심 이유 — 쿼리 코드 통일성

이게 가장 중요한 이유입니다. 시노님이 없으면 환경마다 쿼리가 달라집니다.

-- ❌ 시노님 없는 경우: 환경마다 쿼리가 달라짐
DEV  쿼리 : SELECT * FROM ORDERS
STG  쿼리 : SELECT * FROM COMET.ORDERS  ← 스키마명 붙여야 함
PROD 쿼리 : SELECT * FROM COMET.ORDERS

-- ✅ 시노님 있는 경우: 모든 환경에서 동일한 쿼리
DEV  쿼리 : SELECT * FROM ORDERS
STG  쿼리 : SELECT * FROM ORDERS  ← 시노님 덕분에 동일
PROD 쿼리 : SELECT * FROM ORDERS  ← 시노님 덕분에 동일

환경마다 쿼리가 달라지면 애플리케이션 코드를 환경별로 따로 관리해야 하는 문제가 생깁니다.
시노님을 걸어두면 어느 환경에서든 같은 쿼리로 동작하게 됩니다.

 

환경별 구성 요약

환경	스키마 구성	시노님	이유
DEV	단일 스키마	❌ 없음	개발자가 직접 스키마 접속
STG	comet + cometqa	✅ 있음	별도 계정에서 comet 스키마 접근
PROD	comet + 운영계정	✅ 있음	운영 계정과 실제 스키마 분리

 

결론
환경별로 시노님이 다른 건 "어느 환경에서도 같은 코드로 동작하게 하기 위한 수단" 입니다.
DEV에서는 빠르고 단순하게, STG/PROD 에서는 계정 분리 + 시노님으로 보안 및 코드 통일성을 추구하는 구조 입니다.

 

---

10. 시노님 사용 시 주의사항

시노님은 권한을 부여하지 않는다

시노님을 만들어도 원본 객체에 대한 접근 권한이 없으면 사용할 수 없습니다.

반드시 원본 객체에 대한 권한을 별도로 부여해야 합니다.

-- ❌ 시노님만 생성하면 권한 없이 접근 불가
CREATE SYNONYM EMP FOR HR.EMPLOYEES;
SELECT * FROM EMP;  -- ORA-01031: insufficient privileges 오류

-- ✅ 원본 객체 권한 부여 후 시노님 사용
GRANT SELECT ON HR.EMPLOYEES TO APP_USER;
CREATE SYNONYM EMP FOR HR.EMPLOYEES;
SELECT * FROM EMP;  -- 정상 조회

 

시노님은 객체가 아니다

시노님은 실제 데이터를 가지지 않습니다.
원본 객체가 삭제되면 시노님은 Invalid 상태가 됩니다.

-- 원본 테이블 삭제
DROP TABLE HR.EMPLOYEES;

-- 시노님 조회 시 오류 발생
SELECT * FROM EMP;  -- ORA-04043: object EMP does not exist

-- Invalid 시노님 확인
SELECT SYNONYM_NAME, STATUS
FROM USER_SYNONYMS
WHERE STATUS = 'INVALID';

 

Public 시노님 이름 충돌 주의

Public 시노님은 모든 사용자에게 영향을 미치므로
Oracle 시스템 객체와 이름이 겹치지 않도록 주의합니다.

-- ❌ 시스템 객체와 이름이 겹칠 수 있어 위험
CREATE PUBLIC SYNONYM DUAL FOR MY_SCHEMA.MY_TABLE;

-- ✅ 명확한 이름으로 생성
CREATE PUBLIC SYNONYM MY_REPORT_TABLE FOR MY_SCHEMA.MY_TABLE;

 

---

11. 최종 정리

항목	내용
개념	객체에 별명을 붙이는 기능
종류	Private (개인용) / Public (전체 공유)
생성 가능 객체	테이블, 뷰, 시퀀스, 프로시저, 함수, DB Link 등
주요 장점	긴 이름 단축, 다른 스키마 접근 편의, 위치 투명성
주의사항	권한은 별도 부여 필요, 원본 삭제 시 Invalid
우선순위	실제 객체 > Private > Public