소니 스토리 (Sony Story)

2026년06월14일 주일예배 (이재훈목사님) - 1부

isony — Sun, 14 Jun 2026 08:12:29 +0900

2026년06월14일 주일예배 (이재훈목사님) - 1부

주의 말씀 : 나를 따르라 (5)

마르지 않는 시냇가에 뿌리를 내리다

성경 : 시편(Psalm) 1:1 ~ 6 말씀 (출처:우리말성경)

< 성경 >

1:1 복이 있는 사람은 악한 사람들의 꾀를 따라가지 않고 죄인들의 길에 서지 않으며 남을 업신여기는 사람들과 자리를 함께하지 않고

1:2 오직 여호와의 율법을 즐거워하고 그 율법을 밤낮으로 깊이 생각하는 자로다.

1:3 그는 시냇가에 심은 나무가 계절에 따라 열매를 맺고 그 잎이 시들지 않는 것처럼 하는 일마다 모두 잘되리라.

1:4 악인은 그렇지 않으니 그저 바람에 날려가는 겨와 같도다.

1:5 그러므로 악인들이 심판을 받을 때 죄인들은 의인의 모임에 참석하지 못하리라.

1:6 의인의 길은 여호와께서 보호하시나 악인의 길은 망하리라.

< 예배 영상 >

https://youtu.be/5IKoRqCooxk

[오라클 운영] 시노님(SYNONYM) 완전 정리 - PUBLIC vs PRIVATE, 이름 해석 우선순위, 실무 가이드

isony — Fri, 12 Jun 2026 08:05:22 +0900

[오라클 운영] 시노님(SYNONYM) 완전 정리 - PUBLIC vs PRIVATE, 이름 해석 우선순위, 실무 가이드

테스트 환경: Oracle 11g / 12c / 19c / 21c / 23ai

오라클을 1~2년 다루면 시노님은 누구나 한 번쯤 만듭니다. 그런데 시노님을 단순히 "별칭" 정도로만 이해하고 있으면 운영 환경에서 다음과 같은 황당한 상황을 만나게 됩니다.

분명히 같은 시노님인데 사용자마다 다른 테이블을 가리킴
PUBLIC 시노님을 만들었는데 어떤 사용자에게는 안 보임
시노님은 살아있는데 사용하면 ORA-00942
DROP 후 재생성했는데 권한이 사라짐

이번 글에서는 시노님의 PUBLIC vs PRIVATE 핵심 차이, 이름 해석 우선순위, 권한과의 관계, 그리고 운영 환경에서 자주 발생하는 문제와 해결법까지 정리했습니다.

특히 ORA-00942 글의 "원인 5 - 시노님 깨짐"의 후속편 성격으로, 시노님을 깊이 이해하면 ORA-00942의 상당 부분이 자연스럽게 해결됩니다.

시노님이란 무엇인가

시노님은 다른 데이터베이스 객체에 대한 별칭(alias) 입니다. 테이블, 뷰, 시퀀스, 프로시저, 패키지 등 거의 모든 객체에 대해 만들 수 있습니다.

왜 쓰는가 - 3가지 이유

1) 스키마 prefix를 숨겨서 간결한 SQL

-- 시노님 없을 때
SELECT * FROM hr_schema.employees;
SELECT * FROM hr_schema.departments;

-- 시노님 있을 때
SELECT * FROM employees;
SELECT * FROM departments;

2) 위치 투명성 (Location Transparency)

객체가 다른 스키마나 다른 DB로 이동해도 시노님만 수정하면 애플리케이션 코드는 그대로 둘 수 있습니다.

-- 처음: 같은 DB의 다른 스키마
CREATE SYNONYM employees FOR hr_schema.employees;

-- 나중: 원격 DB로 이전
CREATE OR REPLACE SYNONYM employees FOR hr_schema.employees@remote_db;
-- 애플리케이션은 그대로 SELECT * FROM employees;

3) 보안 추상화

실제 객체의 소유자와 이름을 숨겨서 보안 정보 노출을 줄입니다.

PUBLIC vs PRIVATE - 핵심 비교

가장 자주 헷갈리는 두 종류 시노님의 차이입니다.

항목 PRIVATE PUBLIC

소유자	특정 사용자 (스키마)	PUBLIC 그룹
접근 범위	소유자만 (또는 명시적 prefix)	모든 사용자
생성 권한	CREATE SYNONYM	CREATE PUBLIC SYNONYM
이름 충돌	같은 스키마 내 객체와 충돌 가능	모든 사용자 객체와 충돌 가능성
이름 우선순위	Local 객체 다음	Private 시노님 다음 (가장 마지막)
운영 권장도	⭐⭐⭐⭐ (권장)	⭐⭐ (신중히)

생성 문법 차이

-- PRIVATE (자기 스키마에)
CREATE SYNONYM employees FOR hr_schema.employees;

-- PRIVATE (다른 스키마에) - CREATE ANY SYNONYM 권한 필요
CREATE SYNONYM batch_user.employees FOR hr_schema.employees;

-- PUBLIC - CREATE PUBLIC SYNONYM 권한 필요
CREATE PUBLIC SYNONYM employees FOR hr_schema.employees;

★ 이름 해석 우선순위 (가장 중요)

오라클이 SELECT * FROM employees 같은 쿼리를 만났을 때 객체를 찾는 순서입니다. 이걸 모르면 시노님 동작이 예상과 다를 때 미궁에 빠집니다.

해석 순서

현재 스키마의 객체 (테이블/뷰/시퀀스 등 실제 객체)
현재 스키마의 PRIVATE 시노님
PUBLIC 시노님

실전 시나리오로 이해하기

다음 상황을 가정해 봅시다.

-- HR_SCHEMA에 employees 테이블 존재
-- BATCH_USER 스키마에 employees 테이블 또는 시노님 존재 가능

-- 시나리오 A: 공용 시노님만 있는 경우
-- PUBLIC SYNONYM employees → HR_SCHEMA.employees

SELECT * FROM employees;
-- → PUBLIC SYNONYM 사용 → HR_SCHEMA.employees 조회

-- 시나리오 B: BATCH_USER가 같은 이름의 자기 테이블을 만든 경우
CREATE TABLE batch_user.employees (id NUMBER);

SELECT * FROM employees;
-- → BATCH_USER.employees 조회 (PUBLIC 시노님 무시!)
-- → 1순위가 Local 객체이기 때문

-- 시나리오 C: PRIVATE 시노님과 PUBLIC 시노님 충돌
CREATE SYNONYM employees FOR app_user.employees;  -- PRIVATE
CREATE PUBLIC SYNONYM employees FOR hr_schema.employees;  -- PUBLIC

SELECT * FROM employees;
-- → app_user.employees 조회 (PRIVATE이 PUBLIC을 가림)

실무에서 자주 발생하는 사고

운영 중인 PUBLIC 시노님이 어느 날부터 다른 데이터를 보여주는 경우, 십중팔구 누군가 같은 이름의 PRIVATE 시노님 또는 테이블을 만든 것입니다.

진단 쿼리

-- 같은 이름이 여러 곳에 있는지 확인
SELECT 'TABLE/VIEW' AS type, owner, object_name
FROM   dba_objects
WHERE  object_name = UPPER('찾는_이름')
UNION ALL
SELECT 'SYNONYM' AS type, owner, synonym_name
FROM   dba_synonyms
WHERE  synonym_name = UPPER('찾는_이름');

여러 행이 나오면 이름 충돌 상황이고, 우선순위에 따라 어떤 게 실제로 사용되는지 결정됩니다.

권한과 시노님 - 가장 큰 오해

다른 블로그에서 자주 빠뜨리는 핵심입니다.

시노님 자체는 보안 단위가 아닙니다. 시노님에 부여한 권한은 실제로 원본 객체에 부여된 것입니다.

무슨 뜻인가

-- HR_SCHEMA로 접속
CREATE TABLE employees (id NUMBER, name VARCHAR2(100));

-- PUBLIC 시노님 생성
CREATE PUBLIC SYNONYM employees FOR hr_schema.employees;

-- BATCH_USER로 접속
SELECT * FROM employees;
-- → ORA-00942 발생 (왜?)

시노님이 PUBLIC이라고 해도 데이터 접근 권한까지 자동으로 주어지지 않습니다. 실제 테이블에 SELECT 권한이 필요합니다.

-- HR_SCHEMA에서 권한 부여
GRANT SELECT ON employees TO batch_user;
-- 또는 모두에게
GRANT SELECT ON employees TO PUBLIC;

-- 이제 BATCH_USER에서 SELECT 가능

권장 패턴

-- 1) 원본 객체 권한 부여
GRANT SELECT, INSERT, UPDATE, DELETE ON hr_schema.employees TO batch_user;

-- 2) 시노님 생성
CREATE SYNONYM batch_user.employees FOR hr_schema.employees;

권한과 시노님은 별개로 관리하세요.

DROP / ALTER / 재생성 시 주의사항

OR REPLACE 활용 (권장)

-- 안전한 재정의
CREATE OR REPLACE PUBLIC SYNONYM employees FOR hr_schema.employees;

-- 23ai 이상에서는 IF NOT EXISTS도 가능
CREATE PUBLIC SYNONYM IF NOT EXISTS employees FOR hr_schema.employees;

23ai 주의: OR REPLACE와 IF NOT EXISTS를 동시에 쓰면 ORA-11541: REPLACE and IF NOT EXISTS cannot coexist 에러가 발생합니다. 둘 중 하나만 선택하세요.

DROP 시 권한 영향

-- 시노님을 DROP해도 원본 테이블의 권한은 영향 없음
DROP PUBLIC SYNONYM employees;

-- 시노님 다시 만들면 원본 권한이 그대로 적용됨
CREATE PUBLIC SYNONYM employees FOR hr_schema.employees;

시노님은 별칭일 뿐이므로 DROP/재생성이 원본의 데이터나 권한에 영향을 주지 않습니다. 다만 시노님을 참조하는 다른 객체(예: 뷰)는 INVALID 상태가 됩니다.

INVALID 시노님 일괄 재컴파일

-- 무효 상태 객체 확인
SELECT owner, object_name, object_type, status
FROM   dba_objects
WHERE  status = 'INVALID'
  AND  object_type IN ('SYNONYM', 'VIEW', 'PROCEDURE', 'PACKAGE');

-- 일괄 재컴파일
EXEC DBMS_UTILITY.COMPILE_SCHEMA('BATCH_USER');

시노님 조회 - 데이터 딕셔너리 뷰 3종

뷰 보이는 범위 권한

USER_SYNONYMS	자기가 소유한 시노님	모든 사용자
ALL_SYNONYMS	접근 가능한 모든 시노님 (PUBLIC 포함)	모든 사용자
DBA_SYNONYMS	DB의 모든 시노님	DBA 권한

자주 쓰는 쿼리 모음

1) 자기 스키마의 시노님 모두 보기

SELECT synonym_name, table_owner, table_name, db_link
FROM   user_synonyms;

2) PUBLIC 시노님 중 특정 객체를 가리키는 것 찾기

SELECT synonym_name, table_owner, table_name
FROM   dba_synonyms
WHERE  owner = 'PUBLIC'
  AND  table_name = UPPER('찾는_객체명');

3) 시노님이 가리키는 객체가 실제로 존재하는지 확인 (★ 깨진 시노님 진단)

SELECT s.owner, s.synonym_name, s.table_owner, s.table_name,
       CASE WHEN o.object_name IS NULL THEN '깨짐 (대상 없음)' 
            ELSE 'OK' 
       END AS status
FROM   dba_synonyms s
LEFT   JOIN dba_objects o
       ON s.table_owner = o.owner
      AND s.table_name = o.object_name
WHERE  s.synonym_name = UPPER('찾는_시노님');

깨진 시노님을 발견하면 ORA-00942 글의 "원인 5"를 참고해서 처리하세요.

4) 시노님 체인 추적 (시노님이 시노님을 가리키는 경우)

WITH syn_chain (level_no, owner, synonym_name, table_owner, table_name) AS (
    SELECT 1, owner, synonym_name, table_owner, table_name
    FROM   dba_synonyms
    WHERE  synonym_name = UPPER('시작_시노님')
    UNION ALL
    SELECT sc.level_no + 1, s.owner, s.synonym_name, s.table_owner, s.table_name
    FROM   dba_synonyms s, syn_chain sc
    WHERE  s.synonym_name = sc.table_name
      AND  s.owner = sc.table_owner
)
SELECT * FROM syn_chain;

시노님이 또 다른 시노님을 가리키는 체인은 디버깅이 어려우므로 가능한 한 피하세요.

PUBLIC vs PRIVATE 실무 가이드 - 어떤 걸 쓸 것인가

운영 환경에서 어떤 시노님을 쓸지 결정할 때의 기준입니다.

PUBLIC 시노님을 써야 할 때

데이터 딕셔너리 뷰 (예: ALL_TABLES, DBA_USERS)
모든 사용자가 공통으로 접근해야 하는 공유 객체
표준 라이브러리 / 공통 함수 패키지

PRIVATE 시노님을 써야 할 때 (대부분의 경우)

특정 애플리케이션 사용자만 접근하는 객체
운영 환경의 비즈니스 테이블
권한 관리를 사용자별로 다르게 해야 하는 경우

PUBLIC 시노님 남용의 위험

PUBLIC 시노님은 편리해 보이지만 운영 환경에서는 가능한 줄이는 것이 좋습니다. 이유는:

이름 공간 충돌: 모든 사용자의 객체 이름 공간을 침범
보안 위험: 객체 존재가 모든 사용자에게 노출됨
이관/마이그레이션 어려움: 다른 환경으로 옮길 때 PUBLIC 시노님 모두를 추적해야 함
삭제 영향 범위: DROP 시 모든 사용자에게 영향

권장 운영 표준

-- ❌ PUBLIC 남용 (운영 환경에서 권장하지 않음)
CREATE PUBLIC SYNONYM employees FOR hr_schema.employees;
CREATE PUBLIC SYNONYM departments FOR hr_schema.departments;
CREATE PUBLIC SYNONYM jobs FOR hr_schema.jobs;
-- ... 수십 개

-- ✅ 권한 + PRIVATE 시노님 조합 (권장)
GRANT SELECT ON hr_schema.employees TO batch_user;
GRANT SELECT ON hr_schema.departments TO batch_user;

-- BATCH_USER로 접속해서
CREATE SYNONYM employees FOR hr_schema.employees;
CREATE SYNONYM departments FOR hr_schema.departments;

이렇게 하면 사용자별 격리가 명확해지고, 권한 추적이 쉬워집니다.

자주 발생하는 문제 5가지

문제 1: 시노님은 있는데 ORA-00942

원본 객체에 대한 SELECT 권한 누락. ORA-00942 글 참고.

문제 2: 갑자기 다른 데이터가 보임

같은 이름의 PRIVATE 시노님이나 Local 객체가 생긴 것. 이름 해석 우선순위 확인.

문제 3: 편집기에서 보이는 것과 SELECT 결과가 다름

편집기(SQL Developer, Toad)는 현재 사용자의 컨텍스트로 객체를 표시합니다. 다른 사용자로 접속하면 시노님이 다른 객체를 가리킬 수 있습니다.

문제 4: PL/SQL에서만 시노님 인식 안 됨

ORA-00942 글의 "원인 4 - DEFINER rights + ROLE 무효화"와 같은 케이스. 시노님 자체가 아니라 권한 문제일 가능성이 높습니다.

문제 5: DB Link 시노님이 작동 안 함

CREATE SYNONYM remote_emp FOR employees@remote_db;
SELECT * FROM remote_emp;
-- ORA-02019: connection description for remote database not found

DB Link가 끊어졌거나 사용자에게 해당 DB Link 권한이 없는 경우. user_db_links 확인.

마무리

시노님은 단순한 별칭이지만, 이름 해석 우선순위와 권한과의 관계를 정확히 이해하지 못하면 운영 환경에서 미궁에 빠지기 쉽습니다. 핵심을 다시 한 번 요약하면:

객체 해석은 Local → PRIVATE → PUBLIC 순서
시노님은 권한과 별개 — GRANT는 원본 객체에 부여해야 함
PUBLIC은 신중히 — 운영 환경에서는 PRIVATE + GRANT 조합 권장
시노님 체인은 가능한 피할 것
데이터 딕셔너리 뷰(USER/ALL/DBA_SYNONYMS)로 진단

신규 시스템을 설계할 때 시노님 사용 표준을 미리 정해 두면 운영 사고를 크게 줄일 수 있습니다. PUBLIC 시노님을 만들기 전에 한 번 더 생각해 보세요. "정말 모든 사용자가 접근해야 하는가? PRIVATE으로 대체할 수 없는가?"

비슷한 시노님 관련 이슈를 겪으셨거나, 더 좋은 운영 패턴이 있다면 댓글로 공유해 주세요.

[오라클 에러] ORA-04031 unable to allocate shared memory - 5가지 원인과 해결방법 (단편화 진단 포함)

isony — Wed, 10 Jun 2026 09:34:56 +0900

[오라클 에러] ORA-04031 unable to allocate shared memory - 5가지 원인과 해결방법 (단편화 진단 포함)

테스트 환경: Oracle 11g / 12c / 19c / 21c

새벽 3시. 운영 DB 모니터링 알람이 울립니다. 알람 내용은 "ORA-04031: unable to allocate XXXX bytes of shared memory". 애플리케이션이 멈췄고, 신규 접속도 안 됩니다. DB가 사실상 frozen 상태입니다.

ORA-04031은 DBA가 운영 환경에서 가장 두려워하는 에러 중 하나입니다. 단순히 "메모리 부족"이라고 생각하면 절대 풀리지 않습니다. SGA를 64GB로 늘렸는데도 며칠 후 재발하는 경우가 흔합니다.

이번 글에서는 ORA-04031의 진짜 정체를 짚고, 단편화와 단순 부족을 구분해서 진단하는 방법, 임시 처치와 근본 해결까지 정리했습니다.

급하게 운영 DB를 살려야 한다면 긴급 응급 처치부터 보세요.

에러 메시지 전문과 해석

ORA-04031: unable to allocate 4096 bytes of shared memory 
("shared pool","SELECT * FROM orders WHERE...","sql area","KGL heap")

이 메시지는 진단의 시작점입니다. 4가지 정보가 들어있어요.

항목 위치 의미

요청 크기	4096 bytes	오라클이 할당하려던 메모리 크기
메모리 풀	"shared pool"	어느 메모리 영역에서 실패했는지
객체 타입	"SELECT * FROM..."	무엇을 위한 할당이었는지 (SQL 텍스트 일부)
힙 타입	"sql area","KGL heap"	내부 메모리 구조 (KGL = Kernel Generic Library)

메모리 풀이 어디인지가 가장 중요합니다. 풀별로 원인과 해결법이 완전히 다릅니다.

풀 용도 흔한 발생 시점

shared pool	SQL/PLSQL 파싱, 라이브러리 캐시	OLTP 운영 중 (가장 흔함)
large pool	RMAN 백업, 병렬 쿼리	백업 작업 중
java pool	Java 저장 프로시저	Java 기반 작업
streams pool	GoldenGate, Streams 복제	복제 환경

ORA-04031의 진짜 본질 - 단편화 vs 단순 부족 ★

다른 블로그가 잘 다루지 않는 부분이지만, 이게 ORA-04031 진단의 핵심입니다.

흔한 오해

"메모리 부족이니까 SGA를 늘리면 된다"

이건 절반만 맞습니다. 실제로는 메모리에 여유 공간이 있는데도 ORA-04031이 발생하는 경우가 매우 많습니다.

단편화의 비유

shared pool을 책장이라고 생각해 보세요.

책장에 빈 공간이 총 1GB 남아있지만
그 1GB가 1MB 단위 1024개로 쪼개져 있고
새로 들어와야 할 책이 500MB짜리라면?

빈 공간 총량은 충분하지만 연속된 큰 공간이 없어서 책을 못 꽂습니다. 이게 단편화입니다.

ORA-04031의 70% 이상이 이 패턴입니다. SGA를 늘려도 일정 시간 후 다시 단편화가 진행되어 재발합니다.

단편화의 진짜 원인

대부분은 하드 파싱(Hard Parse) 폭증입니다.

-- 리터럴 SQL (매번 새로운 SQL로 인식됨 - 단편화 주범)
SELECT * FROM orders WHERE customer_id = 1001;
SELECT * FROM orders WHERE customer_id = 1002;
SELECT * FROM orders WHERE customer_id = 1003;
-- ... 매 customer_id마다 별도 SQL로 저장됨

-- 바인드 변수 SQL (한 번만 파싱됨 - 단편화 방지)
SELECT * FROM orders WHERE customer_id = :cust_id;
-- 모든 customer_id가 이 한 SQL로 처리됨

리터럴 SQL이 초당 수백~수천 개씩 발생하면 shared pool에 매번 새로운 chunk가 할당되고, 오래된 것은 제거되면서 메모리 공간이 잘게 쪼개집니다.

긴급 응급 처치 (1분 안에)

운영 DB가 멈춰서 당장 살려야 한다면 다음을 먼저 시도하세요.

Step 1: shared pool 플러시 (가장 빠른 임시 해결)

ALTER SYSTEM FLUSH SHARED_POOL;

이 명령으로 shared pool의 SQL 캐시가 비워지면서 단편화가 해소됩니다. 대부분의 ORA-04031이 즉시 풀립니다.

주의: 이건 응급 처치일 뿐 근본 해결이 아닙니다. 같은 원인이 남아있으면 몇 시간~며칠 안에 재발합니다.

Step 2: 접속도 안 되면 인스턴스 재기동

플러시 명령조차 실행이 안 될 정도로 심한 상태라면 DB 재기동이 필요합니다.

# SQL*Plus로 sysdba 접속
sqlplus / as sysdba

SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP;

재기동은 마지막 수단입니다. 가능하면 플러시로 해결하세요.

Step 3: 근본 원인 진단 시작

응급 조치 후 반드시 다음 진단을 진행해야 합니다. 그렇지 않으면 무조건 재발합니다.

원인 1: 하드 파싱 폭증 (가장 흔함, 60~70%)

리터럴 SQL이 너무 많아서 shared pool이 폭증하는 케이스입니다.

진단 방법

1) 라이브러리 캐시 적중률 확인

SELECT namespace,
       gethitratio AS hit_ratio,
       pinhitratio AS pin_hit_ratio,
       reloads,
       invalidations
FROM   v$librarycache
WHERE  namespace IN ('SQL AREA', 'TABLE/PROCEDURE');

hit_ratio가 0.95(95%) 이하면 하드 파싱이 많은 것입니다.

2) 하드 파싱 발생 횟수 확인

SELECT name, value
FROM   v$sysstat
WHERE  name IN ('parse count (hard)', 'parse count (total)', 'execute count');

(parse count (hard) / parse count (total)) × 100이 5%를 넘으면 하드 파싱 비율이 너무 높습니다.

3) 단편화된 SQL TOP 발견

SELECT sql_text, executions, parse_calls,
       sharable_mem, persistent_mem
FROM   v$sqlarea
WHERE  parse_calls > 100
  AND  executions < 10
ORDER  BY sharable_mem DESC
FETCH  FIRST 20 ROWS ONLY;

executions가 적은데 parse_calls가 많은 SQL은 매번 다른 SQL로 인식되는 것입니다. 단편화의 주범입니다.

해결 방법

방법 1: 바인드 변수 사용 (근본 해결, 권장)

애플리케이션 코드에서 리터럴을 바인드 변수로 변경합니다.

// ❌ 리터럴
String sql = "SELECT * FROM orders WHERE customer_id = " + customerId;

// ✅ 바인드 변수
String sql = "SELECT * FROM orders WHERE customer_id = ?";
ps.setInt(1, customerId);

방법 2: CURSOR_SHARING 파라미터 (임시 해결)

코드 수정이 불가능한 경우 오라클이 자동으로 리터럴을 바인드 변수로 변환하도록 설정합니다.

ALTER SYSTEM SET CURSOR_SHARING = 'FORCE' SCOPE=BOTH;

값 의미

EXACT	기본값. SQL 텍스트가 완전히 같아야 재사용
FORCE	모든 리터럴을 바인드 변수로 자동 변환
SIMILAR	11g 이후 deprecated. 사용 금지

주의: FORCE 설정은 실행 계획에 영향을 줄 수 있습니다. 운영 환경에 적용 전 충분한 테스트 필수입니다.

원인 2: SGA 크기 자체가 부족

데이터베이스 워크로드 대비 SGA 크기가 실제로 부족한 경우입니다. ORA-04031의 20~30%에 해당합니다.

진단 방법

1) 현재 SGA 사용 상황

SELECT pool, name, ROUND(bytes/1024/1024, 2) AS mb
FROM   v$sgastat
WHERE  pool IS NOT NULL
ORDER  BY pool, bytes DESC;

2) shared pool 자유 메모리 확인

SELECT name, ROUND(bytes/1024/1024, 2) AS free_mb
FROM   v$sgastat
WHERE  name = 'free memory';

총 shared pool의 10% 이상 자유 공간이 있어야 안정적입니다.

3) 오라클 자동 조언 활용

SELECT shared_pool_size_for_estimate AS pool_mb,
       estd_lc_size AS estd_lib_cache_mb,
       estd_lc_time_saved_factor,
       estd_lc_load_time_factor
FROM   v$shared_pool_advice
ORDER  BY shared_pool_size_for_estimate;

estd_lc_time_saved_factor가 1에 가까운 첫 크기가 권장값입니다.

해결 방법

ASMM 환경 (자동 메모리 관리)

-- sga_target 증가
ALTER SYSTEM SET sga_target = 8G SCOPE=BOTH;

-- 또는 메모리 자동 관리 (11g+)
ALTER SYSTEM SET memory_target = 12G SCOPE=BOTH;

수동 메모리 관리 환경

ALTER SYSTEM SET shared_pool_size = 2G SCOPE=BOTH;

SGA 변경은 SPFILE 사용 시 즉시 반영됩니다. PFILE 사용 시 재기동 필요.

원인 3: large pool / java pool / streams pool 부족

shared pool이 아닌 다른 풀에서 에러가 발생한 경우입니다. 에러 메시지를 다시 확인하세요.

ORA-04031: unable to allocate XX bytes of shared memory ("large pool",...)

자주 발생하는 시나리오

large pool: RMAN 백업 중, 병렬 쿼리(PARALLEL 힌트) 사용 중
java pool: Java 저장 프로시저 호출 시
streams pool: GoldenGate, Oracle Streams 복제 환경

진단 방법

-- 풀별 사용량 확인
SELECT pool, ROUND(SUM(bytes)/1024/1024, 2) AS total_mb
FROM   v$sgastat
WHERE  pool IS NOT NULL
GROUP  BY pool;

-- 풀별 자유 메모리
SELECT pool, name, ROUND(bytes/1024/1024, 2) AS mb
FROM   v$sgastat
WHERE  name = 'free memory';

해결 방법

-- large pool 증가 (RMAN/병렬 쿼리)
ALTER SYSTEM SET large_pool_size = 512M SCOPE=BOTH;

-- java pool 증가
ALTER SYSTEM SET java_pool_size = 256M SCOPE=BOTH;

-- streams pool 증가 (복제 환경)
ALTER SYSTEM SET streams_pool_size = 512M SCOPE=BOTH;

ASMM 환경(sga_target 설정됨)에서는 오라클이 풀 간 메모리를 자동 조정하지만, 명시적 최소값을 지정하면 보호됩니다.

원인 4: 메모리 누수 (오라클 버그 또는 특정 패키지)

흔하지는 않지만 특정 버전·패치에서 메모리 누수 버그가 알려진 경우가 있습니다.

증상

운영 시작 직후엔 안정적
시간이 지날수록 free memory가 점진적으로 감소
특정 작업 또는 패키지 호출 후 메모리 회수 안 됨

진단 방법

1) 시간대별 자유 메모리 추이 모니터링

-- AWR 스냅샷 기반 추이 (Diagnostics Pack 필요)
SELECT snap_id, 
       TO_CHAR(begin_interval_time, 'YYYY-MM-DD HH24:MI') AS snap_time,
       ROUND(bytes/1024/1024, 2) AS free_mb
FROM   dba_hist_sgastat sg, dba_hist_snapshot s
WHERE  sg.snap_id = s.snap_id
  AND  sg.name = 'free memory'
  AND  sg.pool = 'shared pool'
ORDER  BY snap_id DESC
FETCH  FIRST 48 ROWS ONLY;

자유 메모리가 시간에 따라 단조 감소하면 메모리 누수 의심.

2) 특정 객체 메모리 점유 확인

SELECT name, type, sharable_mem
FROM   v$db_object_cache
WHERE  sharable_mem > 1048576  -- 1MB 이상
ORDER  BY sharable_mem DESC
FETCH  FIRST 20 ROWS ONLY;

해결 방법

현재 PSU/RU 패치 적용 상태 확인 (Oracle Support Doc ID 146599.1)
특정 패키지가 의심된다면 DBMS_SHARED_POOL.KEEP으로 PIN

EXEC DBMS_SHARED_POOL.KEEP('SCHEMA.PACKAGE_NAME', 'P');

My Oracle Support의 자동 진단 도구(AHF) 활용

19c 이상에서는 AHF(Autonomous Health Framework)가 ORA-04031 자동 진단을 지원합니다.

tfactl diagcollect -ora-04031

원인 5: session_cached_cursors 설정 과다 (드물지만 강력함)

이 케이스는 다른 한국어 블로그에서 거의 다루지 않는 영역입니다.

무엇이 문제인가

session_cached_cursors가 너무 높게 설정되면, 각 세션이 캐시하는 커서가 누적되어 shared pool 내 KGLH0 영역이 폭증합니다.

기본값은 50인데, 일부 환경에서 500~1000으로 설정한 경우 ORA-04031의 원인이 됩니다.

진단 방법

SHOW PARAMETER session_cached_cursors

-- KGLH0 영역 사용량 확인
SELECT name, ROUND(bytes/1024/1024, 2) AS mb
FROM   v$sgastat
WHERE  name = 'KGLH0'
  AND  pool = 'shared pool';

KGLH0가 SGA stat에서 TOP 5 안에 들어가면 의심하세요.

해결 방법

-- 적정 수준으로 조정 (보통 50~200)
ALTER SYSTEM SET session_cached_cursors = 100 SCOPE=SPFILE;
-- 재기동 필요

재발 방지 - 운영 환경 모니터링 (★ 실무 핵심)

ORA-04031은 한 번 발생하면 운영 사고로 직결되므로, 사전 모니터링이 필수입니다.

일일 점검 쿼리

-- 1. 풀별 자유 메모리 비율
WITH pool_stats AS (
    SELECT pool,
           SUM(CASE WHEN name = 'free memory' THEN bytes ELSE 0 END) AS free_bytes,
           SUM(bytes) AS total_bytes
    FROM   v$sgastat
    WHERE  pool IS NOT NULL
    GROUP  BY pool
)
SELECT pool,
       ROUND(total_bytes/1024/1024, 2) AS total_mb,
       ROUND(free_bytes/1024/1024, 2)  AS free_mb,
       ROUND(free_bytes/total_bytes * 100, 2) AS free_pct
FROM   pool_stats
ORDER  BY pool;

-- 2. 하드 파싱 비율
SELECT ROUND(
         (SELECT value FROM v$sysstat WHERE name = 'parse count (hard)') / 
         (SELECT value FROM v$sysstat WHERE name = 'parse count (total)') * 100,
         2) AS hard_parse_pct
FROM   dual;

자유 메모리 비율이 10% 미만이거나 하드 파싱 비율이 5%를 넘으면 경고 알림을 발송하도록 자동화하세요.

권장 운영 표준

항목 권장값 이유

shared_pool 자유 메모리	15% 이상 유지	단편화 여유
하드 파싱 비율	5% 미만	단편화 방지
cursor_sharing	EXACT (개발 정상), FORCE (레거시 임시)	-
session_cached_cursors	50~200	KGLH0 폭증 방지
주기적 shared pool flush	❌ 권장하지 않음	근본 해결 우선

그래도 안 풀린다면

위 5가지로도 해결되지 않는 드문 케이스:

HugePages 설정 누락: Linux 환경에서 SGA가 크면 HugePages 설정이 거의 필수
NUMA 환경 최적화 미적용: 멀티 소켓 서버에서 메모리 액세스 비효율 발생
RAC 환경 특화 이슈: 노드 간 라이브러리 캐시 동기화 문제 (gc 대기 이벤트)
AMM/ASMM 충돌: memory_target과 sga_target 동시 설정 시 예측 불가 동작

이 영역은 Oracle Support와 협업 또는 AHF 자동 진단이 가장 빠른 길입니다.

마무리

ORA-04031은 "메모리 부족"이라는 표면적 메시지와 달리, 실제로는 단편화 문제인 경우가 70% 이상입니다. SGA를 늘리는 것은 임시 대응에 불과하고, 하드 파싱을 줄이는 것이 진짜 해결입니다.

운영 환경에서 ORA-04031이 발생했다면 즉시 ALTER SYSTEM FLUSH SHARED_POOL로 시스템을 복구한 후, 24시간 안에 반드시 근본 원인을 진단하세요. 그렇지 않으면 며칠 안에 더 큰 장애로 돌아옵니다.

가장 좋은 예방은 개발 단계에서 바인드 변수를 표준화하는 것입니다. 운영에 들어간 후 리터럴 SQL을 잡는 건 매우 어렵습니다. 신규 시스템 구축 시 코드 리뷰 항목에 반드시 포함시키세요.

비슷한 케이스를 겪으셨거나, 위 방법으로도 해결되지 않은 상황이 있다면 댓글로 공유해 주세요. 함께 진단해 보겠습니다.

[오라클 에러] ORA-00942 table or view does not exist - 6가지 원인과 해결방법 (권한과 PL/SQL 케이스까지)

isony — Mon, 8 Jun 2026 07:43:39 +0900

[오라클 에러] ORA-00942 table or view does not exist - 6가지 원인과 해결방법 (권한과 PL/SQL 케이스까지)

테스트 환경: Oracle 11g / 12c / 19c / 21c

ORA-00942는 오라클에서 가장 자주 마주치는 에러 중 하나입니다. 메시지가 단순해서 "그 객체가 없나 보다" 하고 넘기기 쉽지만, 실제로는 객체가 존재하는데도 ORA-00942가 나는 케이스가 절반 이상입니다.

특히 다음 상황에서 자주 발생합니다.

분명히 테이블이 있는데 SELECT가 안 됨
다른 사용자는 되는데 내 계정만 안 됨
어제까지 잘 되던 프로시저가 갑자기 ORA-00942
쿼리는 잘 되는데 PL/SQL 안에서만 ORA-00942

이 글에서는 ORA-00942의 6가지 원인을 분류하고, 권한 부족인데 왜 ORA-01031이 아니라 ORA-00942가 나는지, 그리고 PL/SQL 내부에서의 특수한 케이스까지 정리했습니다.

급하신 분은 빠른 진단 체크리스트부터 보세요.

에러 메시지 전문

ORA-00942: table or view does not exist
ORA-00942: 테이블 또는 뷰가 존재하지 않습니다

SQL*Plus, SQL Developer, JDBC, 애플리케이션 로그 어디에서나 동일하게 발생합니다. 에러 메시지가 어떤 객체인지 알려주지 않는 게 진단을 어렵게 만드는 부분입니다.

중요: 메시지가 "존재하지 않는다"고 말하지만, 오라클은 "보이지 않는다"와 "존재하지 않는다"를 같은 에러로 처리합니다. 이게 ORA-00942의 진짜 정체입니다.

ORA-00942의 핵심 개념 - 권한과 가시성

다른 블로그에서 잘 다루지 않는 부분이지만, 이걸 이해해야 ORA-00942를 진짜로 해결할 수 있습니다.

왜 권한 부족이 ORA-01031이 아니라 ORA-00942인가

오라클의 보안 설계는 "권한 없는 사용자에게는 객체의 존재 자체를 알리지 않는다" 는 원칙을 따릅니다.

만약 권한 부족 시 ORA-01031("권한이 불충분합니다")이 발생한다면, 공격자는 다음을 알 수 있습니다.

ORA-00942 응답 → 그런 객체 없음
ORA-01031 응답 → 객체는 있는데 권한 없음 (= 객체가 존재한다는 정보 노출)

이건 데이터베이스 구조 정보를 노출하는 보안 취약점입니다. 그래서 오라클은 권한이 없으면 "존재하지 않음"이라고 응답합니다. 즉:

ORA-00942는 "객체가 없다"가 아니라, "당신에게는 보이지 않는다"는 의미입니다.

이 차이를 알면 진단 방향이 완전히 달라집니다.

빠른 진단 체크리스트

ORA-00942를 30초 만에 원인을 좁히는 순서입니다.

DBA 계정으로 객체 존재 여부 확인 → 정말 없는가, 아니면 보이지 않는가?
객체의 소유 스키마 확인 → 다른 스키마인가?
현재 사용자에게 SELECT 권한이 있는가
PL/SQL 안에서 발생했는가 → ROLE 권한 문제일 가능성
객체가 INVALID 상태인가 → 의존성 깨진 뷰/시노님
객체 이름에 대소문자/특수문자 포함? → 따옴표 케이스

원인 1: 객체가 실제로 없거나 오타 (가장 흔함)

기본적인 케이스지만 가장 많이 발생합니다.

진단 방법

DBA 권한으로 객체가 실제로 존재하는지 확인:

-- 모든 스키마에서 해당 객체 검색
SELECT owner, object_name, object_type, status
FROM   dba_objects
WHERE  UPPER(object_name) = UPPER('찾는_객체명');

행이 0건이면 객체가 정말 없는 것입니다. 행이 있다면 다음 원인으로 넘어가세요.

해결 방법

객체명 오타 수정
객체 생성 (필요한 경우)
다른 환경(개발/스테이징)에 있는지 확인

원인 2: 다른 스키마의 객체에 접근 (스키마 prefix 누락) ★ 가장 자주 헷갈림

오라클에서 객체는 항상 소유 스키마에 속합니다. 다른 스키마의 객체에 접근할 때는 스키마명을 명시해야 합니다.

시나리오

-- APP_USER 스키마에 EMPLOYEES 테이블이 있고
-- 현재 접속한 사용자는 BATCH_USER일 때

SELECT * FROM employees;          -- ❌ ORA-00942
SELECT * FROM app_user.employees; -- ✅ 가능 (권한이 있다면)

진단 방법

-- 객체가 어느 스키마에 있는지 확인
SELECT owner, object_name, object_type
FROM   all_objects
WHERE  UPPER(object_name) = UPPER('EMPLOYEES');

owner 컬럼이 현재 접속 사용자(USER)와 다르면 prefix가 필요합니다.

해결 방법

방법 1: 스키마 prefix 추가

SELECT * FROM app_user.employees;

방법 2: 시노님(SYNONYM) 생성 (권장)

-- PUBLIC 시노님 (모든 사용자가 prefix 없이 접근)
CREATE PUBLIC SYNONYM employees FOR app_user.employees;

-- PRIVATE 시노님 (특정 사용자만)
CREATE SYNONYM employees FOR app_user.employees;

방법 3: 권한 부여 + 시노님 조합 (실무 표준)

-- APP_USER로 접속해서
GRANT SELECT ON employees TO batch_user;

-- BATCH_USER로 접속해서
CREATE SYNONYM employees FOR app_user.employees;

이렇게 하면 BATCH_USER가 SELECT * FROM employees로 접근 가능합니다.

원인 3: 권한 부족 (객체는 있지만 보이지 않음)

원인 2와 비슷해 보이지만, 권한 자체가 없는 경우입니다.

진단 방법

현재 사용자가 해당 객체에 어떤 권한이 있는지 확인합니다.

-- 직접 부여받은 권한
SELECT * FROM user_tab_privs 
WHERE  table_name = 'EMPLOYEES';

-- ROLE을 통해 받은 권한
SELECT role, table_name, privilege
FROM   role_tab_privs
WHERE  role IN (SELECT granted_role FROM user_role_privs)
  AND  table_name = 'EMPLOYEES';

두 쿼리 모두 결과가 없으면 권한이 전혀 없는 것입니다.

해결 방법

객체 소유자(또는 DBA)가 권한을 부여합니다.

-- 객체 소유자로 접속
GRANT SELECT ON employees TO batch_user;

-- 여러 권한 한 번에
GRANT SELECT, INSERT, UPDATE, DELETE ON employees TO batch_user;

-- 모든 권한
GRANT ALL ON employees TO batch_user;

권한 부여 후 클라이언트는 재접속해야 즉시 반영됩니다(세션 캐시 때문).

실무 팁

운영 환경에서는 개별 사용자에게 직접 권한을 주지 말고 ROLE 기반으로 관리하세요.

-- ROLE 생성
CREATE ROLE ROLE_BATCH_READ;

-- ROLE에 권한 부여
GRANT SELECT ON app_user.employees TO ROLE_BATCH_READ;
GRANT SELECT ON app_user.departments TO ROLE_BATCH_READ;

-- 사용자에게 ROLE 부여
GRANT ROLE_BATCH_READ TO batch_user;

다만 ROLE 기반 권한에는 PL/SQL에서의 함정이 있습니다(다음 원인 4 참고).

원인 4: PL/SQL 내부에서 ORA-00942 (★ 고급, 가장 까다로움)

이 케이스는 다른 블로그에서 거의 다루지 않는 영역인데, PL/SQL 개발자가 만나면 가장 헷갈리는 케이스입니다.

증상

직접 SQL로는 SELECT * FROM employees 가 잘 됨
똑같은 SQL을 PL/SQL 프로시저 안에 넣으면 ORA-00942
어제까지 잘 되던 프로시저가 갑자기 컴파일 안 됨

원인: DEFINER vs INVOKER 권한 + ROLE 무효화

오라클 PL/SQL은 기본적으로 DEFINER rights(정의자 권한) 으로 동작합니다. 즉:

프로시저를 만든 사용자(소유자) 의 권한으로 실행
호출하는 사용자의 권한이 아님

그리고 결정적으로, DEFINER rights PL/SQL에서는 ROLE을 통해 받은 권한이 무효화됩니다.

예시 시나리오

-- 1) APP_USER가 EMPLOYEES 테이블 소유

-- 2) BATCH_USER에게 ROLE 통해 권한 부여
GRANT SELECT ON app_user.employees TO ROLE_BATCH_READ;
GRANT ROLE_BATCH_READ TO batch_user;

-- 3) BATCH_USER로 접속해서 직접 SQL 실행
SELECT * FROM app_user.employees;
-- ✅ 잘 됨 (ROLE 권한 인식)

-- 4) 같은 SQL을 BATCH_USER 소유 프로시저에 넣음
CREATE OR REPLACE PROCEDURE PROC_READ_EMP AS
    CURSOR c1 IS SELECT * FROM app_user.employees;
BEGIN
    NULL;
END;
/
-- ❌ ORA-00942 발생 (ROLE 권한 무효화)

해결 방법

방법 1: 직접 GRANT (가장 흔한 해결)

-- ROLE을 거치지 말고 직접 부여
GRANT SELECT ON app_user.employees TO batch_user;

이후 프로시저 재컴파일:

ALTER PROCEDURE PROC_READ_EMP COMPILE;

방법 2: INVOKER rights로 변경

CREATE OR REPLACE PROCEDURE PROC_READ_EMP
AUTHID CURRENT_USER  -- ← INVOKER rights
AS
    CURSOR c1 IS SELECT * FROM app_user.employees;
BEGIN
    NULL;
END;
/

AUTHID CURRENT_USER를 명시하면 호출한 사용자의 권한으로 실행되어 ROLE 권한도 인식됩니다. 다만 운영 환경에서는 보안 정책에 따라 신중히 결정해야 합니다.

실무 팁

운영 환경에서 갑자기 프로시저가 ORA-00942로 동작 안 한다면 다음을 의심하세요.

객체 소유자 또는 권한 부여가 변경됨
ROLE에서 권한이 회수됨
참조하는 객체가 다른 스키마로 이동

dba_dependencies 뷰로 프로시저가 어떤 객체를 참조하는지 확인할 수 있습니다.

SELECT referenced_owner, referenced_name, referenced_type
FROM   dba_dependencies
WHERE  owner = 'BATCH_USER'
  AND  name  = 'PROC_READ_EMP';

원인 5: 시노님이 깨졌거나 가리키는 객체가 없음

시노님은 다른 객체를 가리키는 별칭일 뿐, 시노님 자체가 객체를 보장하지 않습니다. 원본 객체가 사라지거나 권한이 회수되면 시노님은 살아있지만 사용 시 ORA-00942 가 발생합니다.

진단 방법

-- 시노님이 가리키는 대상 확인
SELECT owner, synonym_name, table_owner, table_name
FROM   all_synonyms
WHERE  UPPER(synonym_name) = UPPER('찾는_객체명');

가리키는 table_owner.table_name이 실제로 존재하는지 별도로 확인:

SELECT owner, object_name, object_type, status
FROM   dba_objects
WHERE  owner = '확인된_OWNER'
  AND  object_name = '확인된_NAME';

원본 객체가 없거나 권한이 없으면 시노님이 깨진 것입니다.

해결 방법

-- 깨진 시노님 제거 후 재생성
DROP PUBLIC SYNONYM employees;
CREATE PUBLIC SYNONYM employees FOR app_user.employees;

-- 또는 권한 재부여
GRANT SELECT ON app_user.employees TO PUBLIC;

원인 6: 대소문자 / 특수문자 문제 (드물지만 강력함)

오라클은 객체명을 자동으로 대문자로 저장합니다. 그런데 객체 생성 시 따옴표로 감싸면 대소문자가 그대로 저장되어 case-sensitive해집니다.

시나리오

-- 따옴표로 감싸서 생성 (의도적이든 실수든)
CREATE TABLE "employees" (id NUMBER);   -- 소문자로 저장됨

-- 일반 접근 시
SELECT * FROM employees;                 -- ❌ ORA-00942 (대문자 EMPLOYEES를 찾음)

-- 정확히 접근하려면
SELECT * FROM "employees";               -- ✅ 가능

진단 방법

-- 대소문자 그대로 확인
SELECT owner, object_name, object_type
FROM   dba_objects
WHERE  object_name LIKE '%mployee%';

object_name이 EMPLOYEES가 아니라 employees처럼 소문자로 보이면 case-sensitive 객체입니다.

해결 방법

가능하면 객체명을 표준화(대문자) 하세요.

-- 기존 객체 이름 변경
ALTER TABLE "employees" RENAME TO employees;

운영 중인 환경이라면 시노님으로 우회 가능합니다.

CREATE SYNONYM employees_std FOR "employees";

빠른 해결 체크리스트 (종합)

5분 안에 원인을 좁히는 종합 체크리스트입니다.

순서 확인 항목 명령어

1	DBA로 객체 존재 여부	SELECT owner, object_name FROM dba_objects WHERE object_name = UPPER('객체명');
2	어느 스키마에 있는가	위 쿼리의 owner 컬럼 확인
3	직접 권한이 있는가	SELECT * FROM user_tab_privs WHERE table_name = '객체명';
4	ROLE 권한이 있는가	SELECT * FROM role_tab_privs WHERE role IN (SELECT granted_role FROM user_role_privs);
5	PL/SQL 안에서 발생했는가	DEFINER vs INVOKER, 직접 GRANT 필요
6	시노님이 깨졌는가	SELECT * FROM all_synonyms WHERE synonym_name = '객체명';

그래도 안 풀린다면

위 6가지로도 해결되지 않는 드문 케이스:

VPD(Virtual Private Database) / Row-Level Security: 보안 정책으로 특정 사용자에게 객체가 숨겨져 있는 경우
컨테이너 컨텍스트 오류 (12c+ 멀티테넌트): CDB$ROOT에서 PDB의 객체에 접근하려는 경우. ALTER SESSION SET CONTAINER = PDB명; 필요
객체가 RECYCLEBIN에 있음: 누군가 DROP했지만 PURGE는 안 한 상태. SELECT * FROM recyclebin;으로 확인 가능
DBLINK 끊김: 원격 객체 접근 시 DBLINK가 끊어진 경우. SELECT * FROM user_db_links; 확인

마무리

ORA-00942는 메시지는 단순하지만 원인의 폭이 매우 넓은 에러입니다. "객체가 없다"라기보다 "내게 보이지 않는다" 로 사고를 전환하면 진단이 훨씬 정확해집니다.

특히 PL/SQL 내부에서 발생하는 ORA-00942는 90% 이상이 ROLE을 통한 권한 부여 때문입니다. 운영 환경에서 프로시저 컴파일이 갑자기 안 되면 가장 먼저 이걸 의심하세요.

권한 관리는 처음 설계할 때 ROLE 기반과 직접 GRANT의 트레이드오프를 미리 고려하는 것이 중요합니다. 신규 DB 구축 시 권한 모델을 표준화해 두면 ORA-00942로 인한 운영 사고를 크게 줄일 수 있습니다.

비슷한 케이스를 겪으셨거나, 위 방법으로도 해결되지 않은 상황이 있다면 댓글로 공유해 주세요. 함께 진단해 보겠습니다.

2026년06월07일 주일예배 (이재훈목사님) - 1부

isony — Sun, 7 Jun 2026 08:16:23 +0900

2026년06월07일 주일예배 (이재훈목사님) - 1부

주의 말씀 : 나를 따르라 (4)

바위 틈새에서 바라본 영광

성경 : 출이집트기 33:12 ~ 23 말씀 (출처:우리말성경)

< 성경 >

33:12 모세가 여호와께 말했습니다. “주께서 내게 ‘이 백성들을 이끌라’고 줄곧 말씀해 오시지 않으셨습니까? 그러나 나와 함께 누구를 보내실지 알려 주지 않으셨습니다. 주께서 말씀하셨습니다. ‘내가 너를 이름으로 알고 너는 내게 은총을 입었다’라고 말입니다.

33:13 주께서 나를 기쁘게 여기신다면 제발 주의 길을 내게 가르쳐 주셔서 내가 주를 알게 하시고 계속해서 주께 은총을 입게 해 주십시오. 또 이 민족이 주의 백성들임을 생각해 주십시오.”

33:14 여호와께서 대답하셨습니다. “내가 친히 너와 함께 가겠다. 내가 너를 무사하게 할 것이다.”

33:15 그러자 모세는 여호와께 말했습니다. “주께서 친히 우리와 함께 가지 않으시면 아예 우리를 여기서 올려 보내지 마십시오.

33:16 주께서 우리와 함께 가지 않으시면 나와 주의 백성들이 주께 은총을 입었는지 누가 어떻게 알겠습니까? 나와 주의 백성들이 지면의 다른 모든 백성들과 어떻게 구별되겠습니까?”

33:17 그러자 여호와께서 모세에게 “네가 말한 그대로 내가 하겠다. 네가 내 은총을 입었고 내가 너를 이름으로 알기 때문이다”라고 말씀하셨습니다.

33:18 그러자 모세는 “그러면 부탁입니다만, 내게 주의 영광을 보여 주십시오”라고 말했습니다.

33:19 그러자 여호와께서 말씀하셨습니다. “내가 내 모든 선함을 네 앞에 지나가게 하겠고 내가 네 앞에 내 이름 여호와를 선포하겠다. 나는 내가 불쌍히 여길 자를 불쌍히 여기고 긍휼히 여길 자를 긍휼히 여길 것이다.”

33:20 그분께서 이어 말씀하셨습니다. “그러나 네가 내 얼굴은 보지 못한다. 나를 보고 살아남은 사람이 없다.”

33:21 그러고 나서 여호와께서 또 말씀하셨습니다. “자, 내 가까운 곳에 바위가 있으니 그 위에 서 있어라.

33:22 그러면 내 영광이 지나갈 때 내가 너를 바위 틈새에 두고 내가 다 지나갈 때까지 내 손으로 덮을 것이다.

33:23 그러고 나서 내가 내 손을 뗄 것이니 너는 내 뒷모습만 보고 내 얼굴은 보지 못할 것이다.”

< 예배 영상 >

https://youtu.be/xnY5W1JPT18

< 사도신경 >

[오라클 에러] ORA-12514 TNS:리스너가 서비스를 알지 못함 - 5가지 원인과 해결방법 (PDB 환경 포함)

isony — Fri, 5 Jun 2026 12:33:46 +0900

[오라클 에러] ORA-12514 TNS:리스너가 서비스를 알지 못함 - 5가지 원인과 해결방법 (PDB 환경 포함)

테스트 환경: Oracle 12c / 19c / 21c / 23ai, Oracle Linux 8, Windows Server 2019

ORA-12514는 ORA-12541과 함께 오라클 접속 시 가장 자주 마주치는 에러입니다. 두 에러는 메시지가 비슷해서 자주 혼동되는데, 원인은 완전히 다릅니다.

ORA-12541: 리스너 자체가 죽었거나 응답 안 함
ORA-12514: 리스너는 살아있지만 요청한 서비스를 모름

특히 12c부터 도입된 멀티테넌트(CDB/PDB) 환경에서는 ORA-12514가 폭증했습니다. 19c 이상에서 운영 중인 환경이라면 더더욱 자주 만나는 에러입니다.

이번 글에서는 ORA-12514의 5가지 원인을 분류하고, PDB 환경 특화 이슈와 도메인(DB_DOMAIN) 미스매치까지 정리했습니다. 급하신 분은 빠른 진단 체크리스트부터 보세요.

에러 메시지 전문

ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
ORA-12514: TNS:리스너가 현재 접속 기술자에 요청된 서비스를 알지 못함

19c 이상에서는 더 자세한 정보가 함께 표시되기도 합니다.

ORA-12514: Cannot connect to database. Service sales_service.example.com is not registered 
with the listener at host 10.9.7.5 port 1522. (CONNECTION_ID=...)

이 형식은 어떤 서비스명이 문제인지 명확히 알려주기 때문에 진단에 큰 도움이 됩니다.

ORA-12541 vs ORA-12514 - 한 표로 정리

두 에러가 헷갈리는 분들을 위한 핵심 비교표입니다.

항목 ORA-12541 ORA-12514

메시지	리스너가 없습니다	리스너가 서비스를 알지 못함
리스너 상태	죽음 / 응답 없음	살아있음
lsnrctl status	연결 실패	정상 출력
telnet host 1521	실패	성공
핵심 원인	리스너 프로세스 자체 문제	service_name 미등록 / 오기재
PDB 환경 영향	영향 없음	매우 큼
해결 방향	리스너 시작 / 포트 / 방화벽	service_name 확인 / PDB 상태

한 줄 진단법: 클라이언트에서 tnsping host:port 가 성공하는데 sqlplus 접속이 안 되면 ORA-12514, tnsping 자체가 실패하면 ORA-12541일 가능성이 큽니다.

빠른 진단 체크리스트

본격 해결 전에 30초 만에 원인을 좁히는 순서입니다.

lsnrctl services 실행 → 리스너가 알고 있는 서비스 목록 확인
연결 문자열의 service_name 확인 → 위 목록에 있는가?
PDB 환경이면 → PDB 상태 확인 (select name, open_mode from v$pdbs;)
DB_DOMAIN 설정 확인 → 도메인 누락 가능성 (show parameter db_domain)
리스너 시작 직후 5분 이내라면 → 등록 대기 중일 수 있음

원인 1: service_name 오타 또는 누락 (가장 흔함)

ORA-12514의 70% 이상이 이 케이스입니다. 클라이언트의 tnsnames.ora에 적힌 SERVICE_NAME과 실제 DB의 서비스명이 다르면 발생합니다.

진단 방법

서버에서 리스너가 알고 있는 서비스 목록 확인:

lsnrctl services

출력 예시:

Services Summary...
Service "ORCL" has 1 instance(s).
  Instance "ORCL", status READY, has 1 handler(s) for this service...
Service "ORCLXDB" has 1 instance(s).
  Instance "ORCL", status READY, has 1 handler(s) for this service...
Service "pdbprod" has 1 instance(s).
  Instance "ORCL", status READY, has 1 handler(s) for this service...

여기에 있는 서비스명만 접속 가능합니다.

클라이언트의 tnsnames.ora 확인:

PRODDB =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.10.5)(PORT = 1521))
    (CONNECT_DATA =
      (SERVICE_NAME = pdbprod)   ← 이 값이 lsnrctl services 결과에 있어야 함
    )
  )

service_name vs SID - 자주 혼동

신입 DBA가 가장 헷갈리는 부분입니다.

구분 SID SERVICE_NAME

의미	인스턴스 식별자	서비스 식별자 (논리적)
멀티테넌트	CDB만 가능	PDB 접속에 필수
권장	레거시 호환용	신규 코드에서 권장
형식 (tnsnames)	(SID = ORCL)	(SERVICE_NAME = pdbprod)
형식 (Easy Connect)	host:port:SID	host:port/service_name

Easy Connect 표기법 차이를 보세요.

# SID 방식 (레거시)
sqlplus user/pw@192.168.10.5:1521:ORCL

# SERVICE_NAME 방식 (권장)
sqlplus user/pw@192.168.10.5:1521/pdbprod

: 와 / 의 차이로 SID인지 SERVICE_NAME인지가 결정됩니다.

해결 방법

lsnrctl services 결과의 정확한 서비스명을 그대로 사용하세요.

sqlplus user/pw@192.168.10.5:1521/pdbprod

원인 2: PDB가 OPEN 상태가 아님 (12c+ 멀티테넌트 특화) ★

이 케이스는 다른 한국어 블로그에서 거의 다루지 않는 영역입니다. 멀티테넌트 환경에서 ORA-12514가 발생하면 가장 먼저 의심해야 할 케이스입니다.

무엇이 문제인가

PDB는 OPEN 상태일 때만 자신의 서비스가 리스너에 자동 등록됩니다. PDB가 MOUNTED 상태로 머물러 있으면 해당 PDB의 service_name이 리스너에 보이지 않아 ORA-12514가 발생합니다.

DB가 재시작되면 PDB는 기본적으로 MOUNTED 상태로 올라오기 때문에, DB 재시작 직후 ORA-12514가 발생하는 가장 흔한 이유가 이 경우입니다.

진단 방법

CDB$ROOT에 접속해서 PDB 상태를 확인합니다.

sqlplus / as sysdba

SQL> SELECT name, open_mode, restricted FROM v$pdbs;

NAME         OPEN_MODE    RESTRICTED
------------ ------------ ----------
PDB$SEED     READ ONLY    NO
PDBPROD      MOUNTED      ← 이게 문제

PDBPROD가 MOUNTED 상태라면 리스너에서도 안 보입니다.

해결 방법

1) PDB를 OPEN 상태로 변경

ALTER PLUGGABLE DATABASE PDBPROD OPEN;

2) 다음 재시작 시에도 자동으로 OPEN되도록 영구 설정

ALTER PLUGGABLE DATABASE PDBPROD SAVE STATE;

이 설정을 하지 않으면 DB 재시작 때마다 PDB를 수동으로 OPEN해야 합니다. 운영 환경에서는 반드시 SAVE STATE를 적용하세요.

3) 모든 PDB 일괄 OPEN

ALTER PLUGGABLE DATABASE ALL OPEN;

실무 팁

DB 시작 트리거를 만들어 PDB 자동 OPEN을 보장하는 방법도 있지만, 12.1.0.2 이상에서는 위 SAVE STATE 명령이 표준 방법입니다. 트리거 방식보다 안전하고 권장됩니다.

원인 3: DB 인스턴스가 리스너에 등록 안 됨 (동적 등록 실패)

오라클은 DB 인스턴스가 시작될 때 PMON 프로세스가 리스너에 자신을 동적으로 등록합니다. 이 등록이 실패하면 리스너는 인스턴스의 존재를 모릅니다.

자주 발생하는 시나리오

리스너 시작 직후 1~2분 이내: 등록이 아직 완료되지 않은 일시적 상태 (잠시 기다리면 해결)
리스너 포트가 비표준 (1521이 아님): 인스턴스에 LOCAL_LISTENER 파라미터 설정 필요
리스너와 인스턴스가 다른 호스트: 동적 등록은 기본적으로 동일 호스트 가정

진단 방법

SQL> SHOW PARAMETER local_listener
SQL> SHOW PARAMETER service_names

PMON에게 강제로 재등록 요청:

SQL> ALTER SYSTEM REGISTER;

이 명령을 실행한 후 다시 lsnrctl services를 보면 서비스가 등록됩니다.

해결 방법: 비표준 포트 환경

리스너 포트가 1522처럼 1521이 아니라면, 인스턴스에 LOCAL_LISTENER 파라미터를 명시해야 합니다.

ALTER SYSTEM SET LOCAL_LISTENER = 
  '(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.10.5)(PORT=1522))' 
  SCOPE=BOTH;

ALTER SYSTEM REGISTER;

원인 4: DB_DOMAIN 미스매치 (19c 이상에서 흔함) ★

19c 이상 환경에서 service_name에 도메인이 붙는 경우가 일반적입니다.

무엇이 문제인가

DB_DOMAIN 파라미터가 example.com으로 설정되어 있으면, 인스턴스가 리스너에 등록하는 service_name은 자동으로 orcl.example.com처럼 도메인이 붙은 형태가 됩니다.

클라이언트가 SERVICE_NAME = orcl로만 요청하면 리스너는 "그런 서비스 없음"으로 응답합니다.

진단 방법

SQL> SHOW PARAMETER db_domain
SQL> SHOW PARAMETER service_names

lsnrctl services 결과와 클라이언트의 tnsnames.ora 값을 비교합니다.

# 서버에서 보이는 실제 서비스명
Service "orcl.example.com"

# 클라이언트가 요청하는 서비스명
SERVICE_NAME = orcl   ← 도메인 누락

해결 방법

1) 클라이언트의 tnsnames.ora에 도메인 추가 (권장)

SERVICE_NAME = orcl.example.com

2) 또는 인스턴스의 service_names를 도메인 없이 등록

ALTER SYSTEM SET SERVICE_NAMES = 'orcl' SCOPE=BOTH;
ALTER SYSTEM REGISTER;

후자는 환경 표준에 따라 결정합니다. 운영 정책상 도메인을 유지해야 한다면 1번 방식으로 가세요.

원인 5: listener.ora 정적 등록 설정 오류

대부분의 환경에서는 동적 등록을 사용하지만, 정적 등록이 필요한 경우가 있습니다(예: 외부 프로시저 호출, RMAN 백업 카탈로그 접속).

정적 등록 vs 동적 등록

구분 동적 등록 정적 등록

누가 등록	PMON 프로세스 (자동)	DBA가 listener.ora에 직접 작성
DB 다운 시	자동 해제	등록 유지 (BLOCKED 상태로 보임)
시작 시점	DB 인스턴스 시작 시	리스너 시작 시
권장	일반적 운영 환경	특수 목적 (RMAN, 외부 프로시저)

listener.ora 정적 등록 예시

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (GLOBAL_DBNAME = orcl)
      (ORACLE_HOME = /u01/app/oracle/product/19c/dbhome_1)
      (SID_NAME = ORCL)
    )
  )

LISTENER =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.10.5)(PORT = 1521))
  )

자주 발생하는 실수

GLOBAL_DBNAME을 클라이언트의 SERVICE_NAME과 다르게 입력
SID_NAME을 잘못 입력 (실제 인스턴스명과 불일치)
정적 등록 후 리스너 미재시작 (lsnrctl reload 필요)

해결 방법

# 설정 변경 후 반드시 reload
lsnrctl reload

# 또는 재시작
lsnrctl stop
lsnrctl start

# 확인
lsnrctl services

빠른 해결 체크리스트

5분 안에 원인을 좁히는 종합 체크리스트입니다.

순서 확인 항목 명령어

1	리스너가 알고 있는 서비스 목록	lsnrctl services
2	클라이언트의 service_name 정확한가	tnsnames.ora 확인
3	PDB 환경이면 PDB 상태 확인	SELECT name, open_mode FROM v$pdbs;
4	DB_DOMAIN 설정	SHOW PARAMETER db_domain
5	강제 재등록 시도	ALTER SYSTEM REGISTER;

이 5단계로 ORA-12514의 95% 이상이 해결됩니다.

그래도 안 풀린다면

위 5가지로도 해결되지 않는 드문 케이스:

Data Guard 환경에서 Standby에 접속 시도: Standby의 service_names는 별도 등록이 필요
RAC 환경의 SCAN 리스너 vs 로컬 리스너 혼동: SCAN 리스너로 접속해야 하는데 로컬 리스너 호스트로 접속 시도
리스너 시작 직후 5분 이내: 동적 등록 완료 전 일시적 ORA-12514. 잠시 후 자동 해결
방화벽이 1521만 열고 동적 포트 차단: 일부 환경에서 데이터 통신용 동적 포트가 별도 필요

마무리

ORA-12514는 "서비스를 모름"이라는 한 가지 증상이지만, 원인은 service_name 오타부터 PDB 상태, DB_DOMAIN 미스매치까지 다양합니다.

ORA-12541과 헷갈리지 않는 것이 진단의 첫 단추입니다. 리스너가 살아있는지 (lsnrctl status) 확인했다면 ORA-12541은 아니고, 그다음으로 어떤 서비스를 알고 있는지 (lsnrctl services) 확인하는 것이 핵심입니다.

특히 12c 이상 멀티테넌트 환경에서 DB 재시작 후 발생한 ORA-12514라면 90% 이상이 PDB가 MOUNTED 상태입니다. ALTER PLUGGABLE DATABASE ... SAVE STATE 한 줄로 재발을 영구 방지할 수 있습니다.

비슷한 케이스를 겪으셨거나, 위 방법으로도 해결되지 않은 상황이 있다면 댓글로 공유해 주세요. 함께 해결책을 찾아보겠습니다.

[Claude Code 활용 3편] SQL과 Oracle DBA 업무에 Claude Code 활용하기 (튜닝부터 트러블슈팅까지)

isony — Thu, 4 Jun 2026 08:11:13 +0900

[Claude Code 활용 3편] SQL과 Oracle DBA 업무에 Claude Code 활용하기 (튜닝부터 트러블슈팅까지)

테스트 환경: Oracle 19c / 21c, Claude Code v2.x

1편에서 Claude Code 입문을, 2편에서 셸 스크립트 자동화를 다뤘습니다. 이번 3편은 Oracle DBA 업무에 Claude Code를 활용하는 방법입니다.

DBA 업무는 SQL 작성·튜닝, 작업 등록, 트러블슈팅, 모니터링이 핵심입니다. 이 영역에서 Claude Code는 단순한 "쿼리 생성기"를 넘어, 본인 환경의 실행 계획·통계 정보·에러 로그를 함께 분석하면서 답을 주는 협업 파트너 역할을 합니다.

이번 글에서는 다음 5가지 사례를 다룹니다.

SQL 작성 (특히 복잡한 분석 쿼리)
실행 계획 분석과 튜닝 방향 제시
DBMS_SCHEDULER 작업 자동 생성
ORA 에러 분석 및 해결 방향 제시

DBA 일일 점검 보고서 자동 생성

시작 전 - DBA용 CLAUDE.md 설정

DBA 작업에 특화된 컨텍스트를 미리 정의해 두면 매번 환경 설명을 안 해도 됩니다.

# DBA 작업 환경

## DB 정보
- Oracle 19c (19.21.0)
- OS: Oracle Linux 8.8
- 인스턴스: PRODDB
- 캐릭터셋: AL32UTF8
- 타임존: Asia/Seoul

## 주요 스키마
- APP_USER: 애플리케이션 메인 스키마
- BATCH_USER: 배치 작업 스키마
- READ_ONLY_USER: 조회 전용 (모니터링)

## SQL 작성 규칙
- 키워드는 대문자, 객체명은 소문자
- 들여쓰기는 4 spaces
- JOIN은 ANSI 표준 (LEFT JOIN, INNER JOIN)
- WHERE 절이 없는 UPDATE/DELETE는 절대 작성 금지
- 운영 DB의 DDL은 항상 IF EXISTS / IF NOT EXISTS 사용

## 보안 규칙
- 비밀번호를 SQL 안에 평문으로 넣지 말 것
- DROP, TRUNCATE는 영향 범위 사전 확인 후 안내
- 운영 환경 변경 SQL은 항상 ROLLBACK 시나리오 포함

이 컨텍스트가 있으면 "쿼리 짜 줘"라고만 해도 본인 환경 표준에 맞춰 결과가 나옵니다.

사례 1: 복잡한 분석 SQL 작성

단순 SELECT는 직접 작성하는 게 빠릅니다. Claude Code의 진짜 강점은 여러 조건과 비즈니스 로직이 얽힌 분석 쿼리에서 드러납니다.

프롬프트

> 다음 분석 쿼리를 작성해 줘.
  
  - 대상 테이블: orders, order_items, customers, products
  - 조건:
    1. 최근 30일 주문 데이터
    2. 고객 등급(VIP, GOLD, SILVER)별로 분리
    3. 등급별 매출 합계와 주문 건수
    4. 각 등급에서 가장 많이 팔린 상품 TOP 3
    5. 등급 간 비교를 위한 전체 대비 비율 (%) 포함
  - 결과는 한 쿼리로 (WITH 절 활용)
  - 인덱스 활용을 고려해 작성
  - 가독성을 위해 주석 추가

Claude가 만들어 주는 쿼리는 WITH 절로 단계를 나누고, 윈도우 함수(RANK() OVER (...))로 TOP N을 추출하며, RATIO_TO_REPORT()로 비율까지 계산합니다.

더 효과적인 활용 - 점진적 개선

처음에 받은 쿼리에 대해 이어서 요청하면 더 정교해집니다.

> 이 쿼리를 EXPLAIN PLAN으로 분석해서 인덱스가 잘 활용되는지 확인하고,
  비효율적인 부분이 있다면 힌트(/*+ ... */)를 추가해서 개선해 줘.

Claude가 실행 계획을 직접 보고 (EXPLAIN PLAN FOR ... + DBMS_XPLAN.DISPLAY) 비효율을 찾아 힌트를 제안합니다.

사례 2: 실행 계획 분석과 튜닝 방향

DBA 업무에서 가장 시간이 걸리는 작업 중 하나가 느린 쿼리의 원인 분석입니다.

프롬프트

> 다음 SQL의 실행 계획을 분석해 줘.
  [SQL 본문]
  
  - 현재 실행 시간: 약 45초
  - 데이터 건수: orders 약 5천만 건, order_items 약 2억 건
  - 기존 인덱스: orders(customer_id), order_items(order_id)
  
  실행 계획을 분석하고:
  1. 가장 비용이 큰 단계가 어디인가
  2. 풀 스캔이 발생하는가, 발생한다면 의도된 것인가
  3. 조인 순서와 조인 방식이 적절한가
  4. 추가하면 좋을 인덱스
  5. 쿼리 자체를 재작성하면 더 빠를지

Claude는 EXPLAIN PLAN을 실행하고 (또는 사용자가 제공한 실행 계획을 분석하고), 위 5가지 항목을 짚어 줍니다.

특히 강력한 부분은 "인덱스 추가 시 효과 추정" 입니다.

> orders(customer_id, order_date) 복합 인덱스를 추가하면 
  이 쿼리의 실행 계획이 어떻게 바뀔지 예측해 줘.
  그리고 다른 SQL에 미칠 영향(인덱스 유지 비용, 다른 쿼리에서의 활용)도 함께.

인덱스 추가는 한 번 결정하면 되돌리기 부담스러운 작업입니다. 사전에 영향도를 검토하는 데 큰 도움이 됩니다.

사례 3: DBMS_SCHEDULER 작업 자동 생성

이전 글에서 DBMS_SCHEDULER 작업을 수동으로 등록하는 방법을 다뤘는데, Claude Code를 쓰면 더 빠릅니다.

프롬프트

> 다음 사양으로 DBMS_SCHEDULER 작업을 생성해 줘.
  
  - 작업명: JOB_DAILY_STATS_REFRESH
  - 실행할 프로시저: PKG_STATS.REFRESH_DAILY
  - 인자: 어제 날짜 (YYYY-MM-DD 형식)
  - 실행 시각: 매일 새벽 1시 30분
  - 타임존: Asia/Seoul 명시
  - 실패 시 dba@company.com에 메일 알림
  - 평균 실행 시간이 1시간을 넘으면 경고
  - 작업 등록 SQL과 함께 검증 쿼리도 같이

Claude가 만들어 주는 결과:

-- 1) 작업 생성
BEGIN
    DBMS_SCHEDULER.CREATE_JOB(
        job_name        => 'JOB_DAILY_STATS_REFRESH',
        job_type        => 'PLSQL_BLOCK',
        job_action      => q'[
            DECLARE
                v_yest VARCHAR2(10) := TO_CHAR(SYSDATE - 1, 'YYYY-MM-DD');
            BEGIN
                PKG_STATS.REFRESH_DAILY(v_yest);
            END;
        ]',
        start_date      => TO_TIMESTAMP_TZ(
                              TO_CHAR(SYSDATE+1, 'YYYY-MM-DD') || ' 01:30:00 Asia/Seoul',
                              'YYYY-MM-DD HH24:MI:SS TZR'),
        repeat_interval => 'FREQ=DAILY;BYHOUR=1;BYMINUTE=30;BYSECOND=0',
        enabled         => TRUE,
        comments        => '일일 통계 갱신 (어제 날짜 기준)'
    );
END;
/

-- 2) 실패 알림 등록
BEGIN
    DBMS_SCHEDULER.ADD_JOB_EMAIL_NOTIFICATION(
        job_name   => 'JOB_DAILY_STATS_REFRESH',
        recipients => 'dba@company.com',
        events     => 'JOB_FAILED, JOB_BROKEN, JOB_OVER_MAX_DUR'
    );
END;
/

-- 3) 최대 실행 시간 1시간 설정
BEGIN
    DBMS_SCHEDULER.SET_ATTRIBUTE(
        name      => 'JOB_DAILY_STATS_REFRESH',
        attribute => 'max_run_duration',
        value     => INTERVAL '1' HOUR
    );
END;
/

-- 4) 검증 쿼리
SELECT job_name, state, enabled, 
       TO_CHAR(next_run_date, 'YYYY-MM-DD HH24:MI:SS') AS next_run,
       max_run_duration
FROM   user_scheduler_jobs
WHERE  job_name = 'JOB_DAILY_STATS_REFRESH';

수동 작성 시간 약 10분 → Claude 활용 시간 30초.

사례 4: ORA 에러 분석 및 해결 방향 ★ 가장 강력한 활용

DBA가 가장 자주 마주치는 게 알 수 없는 ORA-XXXXX 에러입니다. 평소라면 검색 → 블로그 5개 → 본인 환경에 맞춰 변형의 과정을 거치는데, Claude Code는 한 번에 해결합니다.

프롬프트 (장애 발생 직후)

> alert 로그에서 다음 에러가 발생했어.
  
  [에러 메시지 전체 붙여 넣기]
  
  - 발생 시각: 2026-05-30 14:23:17
  - 직전에 실행 중이던 작업: 월말 배치 (PKG_MONTHLY.CLOSE_ACCOUNTS)
  - DB 버전: Oracle 19.21
  - 메모리: SGA 64GB / PGA 32GB
  
  원인을 분석하고:
  1. 어떤 종류의 문제인지 (메모리/락/IO/네트워크 등)
  2. 즉시 확인할 진단 쿼리 (v$ 뷰)
  3. 단기 해결 방안 (장애 대응)
  4. 근본 해결 방안 (재발 방지)
  순서로 정리해 줘.

Claude가 에러 코드를 분석하고, 본인 환경의 v$ 뷰를 직접 조회해서 추가 정보를 수집한 뒤, 단계별 대응 방안을 제시합니다.

더 발전된 활용 - alert 로그 자동 감시

> /u01/app/oracle/diag/rdbms/proddb/PRODDB/trace/alert_PRODDB.log 파일을 
  지속적으로 감시하다가 ORA-, TNS-, ORACLE Instance 같은 키워드가 
  새로 발견되면 분석 보고서를 자동 생성하는 스크립트를 만들어 줘.
  
  보고서에는:
  - 발견 시각
  - 에러 메시지 (앞뒤 10줄 컨텍스트 포함)
  - 1차 분석 (Claude의 추정 원인)
  - 권장 대응 절차
  
  보고서는 /var/log/oracle/alerts/ 폴더에 timestamp 파일명으로 저장.

운영 환경에 한 번 설정해 두면, 장애 발생 즉시 1차 분석된 보고서가 자동 생성됩니다.

사례 5: DBA 일일 점검 보고서 자동 생성

매일 아침 출근해서 DB 상태를 점검하는 작업은 시간이 오래 걸리지만 빠뜨릴 수 없는 일입니다. 이걸 한 번에 자동화할 수 있습니다.

프롬프트

> DBA 일일 점검 보고서를 자동으로 생성하는 SQL 스크립트를 만들어 줘.
  점검 항목:
  
  [1. 인스턴스 상태]
  - DB 가동 시간 (uptime)
  - 인스턴스 상태 (open/mount/started)
  
  [2. 저장 공간]
  - 테이블스페이스별 사용률 (90% 이상은 경고)
  - 데이터파일 자동 확장 한계 도달 여부
  - ASM 디스크 그룹 사용률 (있는 경우)
  
  [3. 백업 상태]
  - 마지막 RMAN 백업 성공 시각
  - 24시간 이내 백업이 없으면 경고
  
  [4. 작업 상태]
  - DBMS_SCHEDULER 작업 중 BROKEN 상태인 것
  - 직전 24시간 내 실패한 작업
  
  [5. 성능 지표]
  - 직전 1시간 평균 대기 이벤트 TOP 5
  - Buffer Cache Hit Ratio
  - 활성 세션 수
  
  [6. 알람]
  - 직전 24시간 내 alert 로그의 ORA- 에러
  
  결과는 마크다운 형식으로 정리하고, 
  /home/oracle/reports/daily_YYYYMMDD.md 파일에 저장.
  매일 아침 8시에 자동 실행되도록 cron 등록까지.

이 한 번의 요청으로 완성된 점검 스크립트와 자동화 설정이 나옵니다. 매일 30분 걸리던 작업이 출근하면 메일함에 보고서가 와 있는 상태가 됩니다.

DBA 업무 도입 시 추가 팁

1. 운영 DB에 직접 접속 금지 패턴

CLAUDE.md에 다음을 명시하세요.

# 작업 환경 분리
- Claude Code 작업: 개발 DB(devdb)만 직접 접속 허용
- 운영 DB(proddb)의 변경 작업은 다음 절차 필수:
  1. 개발 DB에서 검증
  2. 변경 SQL과 ROLLBACK SQL 함께 작성
  3. DBA 매니저 리뷰
  4. 운영 적용은 사람이 직접

이렇게 하면 Claude가 운영 DB에 직접 변경을 시도하지 않습니다.

2. SQL 라이브러리화

자주 쓰는 점검 쿼리, 트러블슈팅 쿼리를 한 폴더에 모으고 git으로 관리하세요. Claude가 다음에 비슷한 작업을 할 때 이 라이브러리를 참고합니다.

~/dba-toolkit/
├── monitoring/
│   ├── tablespace_check.sql
│   ├── session_wait_top.sql
│   └── lock_check.sql
├── tuning/
│   ├── slow_query_finder.sql
│   └── index_usage_analysis.sql
└── CLAUDE.md  ← 폴더의 사용 안내

3. 실행 계획은 항상 확인

Claude가 만든 쿼리가 빠르게 동작할 거라는 보장은 없습니다. 운영 환경에 배포하기 전 EXPLAIN PLAN 확인은 필수입니다.

EXPLAIN PLAN FOR
[Claude가 만든 쿼리];

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);

4. 권한 최소화 원칙

Claude Code가 접속하는 DB 계정은 작업에 필요한 최소 권한만 부여하세요. SELECT만 필요한 작업은 SELECT 권한만, 등 분리합니다. 만일의 사고를 줄입니다.

시리즈 마무리

3편에 걸쳐 DBA와 서버 관리자 관점에서 Claude Code 활용법을 정리했습니다. 핵심을 요약하면:

1편: Claude Code는 운영자에게도 강력한 도구다. 코딩이 아니라 텍스트 기반 업무 전반의 효율을 높인다.
2편: 셸 스크립트와 운영 자동화에서 Claude Code는 검색-분석-스크립트 작성-문서화 사이클을 한 곳에서 끝낸다.
3편 (이 글): DBA 업무에서는 SQL 작성, 튜닝, 트러블슈팅, 점검 자동화에 활용해 매일 1~2시간을 절약할 수 있다.

도입할 때 가장 중요한 건 점진적으로, 읽기 작업부터, 운영 환경은 신중하게 입니다. Claude Code는 강력하지만 도구일 뿐이고, 최종 책임은 운영자에게 있습니다. 검토 없이 그대로 실행하는 일은 절대 피하세요.

이 시리즈를 보고 도입을 시도하셨거나, 더 좋은 활용 패턴을 발견하셨다면 댓글로 공유해 주세요. 여러 운영자의 경험이 모이면 더 풍부한 활용 가이드가 됩니다.

시리즈 안내

1편: DBA와 서버 관리자가 Claude Code를 써야 하는 이유 - 설치부터 실전 5가지 활용까지
2편: 셸 스크립트와 운영 자동화에 Claude Code 활용하기
3편 (이 글): SQL과 Oracle DBA 업무에 Claude Code 활용하기

[Claude Code 활용 2편] 셸 스크립트와 운영 자동화에 Claude Code 활용하기 (실전 사례 5가지)

isony — Wed, 3 Jun 2026 07:12:35 +0900

[Claude Code 활용 2편] 셸 스크립트와 운영 자동화에 Claude Code 활용하기 (실전 사례 5가지)

테스트 환경: Oracle Linux 8 / RHEL 8 / Ubuntu 22.04, Claude Code v2.x

이전 1편에서 Claude Code 설치와 기본 활용을 다뤘다면, 이번 2편은 서버 관리자가 매일 마주치는 작업을 Claude Code로 자동화하는 실전 사례를 정리했습니다.

운영 환경에서 가장 시간을 많이 잡아먹는 일이 셸 스크립트 작성, 로그 분석, 장애 진단입니다. 이 작업들이 Claude Code의 가장 큰 강점이 발휘되는 영역입니다.

이번 글에서는 다음 5가지 사례를 다룹니다.

정기 백업 스크립트 자동 생성
디스크 용량 모니터링 + 알림 스크립트
로그 파일 분석과 패턴 추출
cron 작업 일괄 점검
장애 진단 스크립트 (서버가 느려졌을 때)

모든 예제는 그대로 복사해서 활용 가능한 프롬프트로 제공합니다.

시작 전 - CLAUDE.md 만들기 (★ 효율 2배)

본격 활용 전에 한 가지 세팅을 하면 작업 효율이 크게 올라갑니다. CLAUDE.md 파일을 프로젝트 폴더에 두면 Claude가 자동으로 읽어서 매번 환경 설명을 안 해도 됩니다.

cd ~/work/ops
vi CLAUDE.md

다음과 같이 작성합니다.

# 환경 정보
- OS: Oracle Linux 8.8
- 셸: bash
- DB: Oracle 19c
- 백업 위치: /backup
- 로그 위치: /var/log, /u01/app/oracle/diag

# 작업 규칙
- 모든 스크립트는 #!/bin/bash로 시작
- 변수는 대문자, 함수는 소문자
- 실패 시 exit 1
- 모든 작업은 /var/log/ops.log에 timestamp와 함께 기록
- 백업 파일명은 yyyymmdd_HHMMSS 형식

# 보안
- 비밀번호는 파일에 직접 쓰지 말고 Oracle Wallet 사용
- 운영 DB(prod_db1)에는 직접 접속 금지, 점프 서버 경유

이 파일이 있으면 "스크립트 짜 줘"라고만 해도 위 규칙에 맞춰 결과가 나옵니다. 운영 표준화에도 큰 도움이 됩니다.

사례 1: 정기 백업 스크립트 자동 생성

가장 일상적인 작업입니다. 백업 스크립트는 매번 비슷한 구조인데도 매번 새로 짜기는 귀찮습니다.

프롬프트

> 오라클 DB의 datapump 백업 스크립트를 만들어 줘.
  - 매일 새벽 2시 실행
  - 백업 대상: PROD_DB 스키마
  - 저장 경로: /backup/dpdump
  - 파일명: prod_db_YYYYMMDD_HHMMSS.dmp
  - 7일 이전 파일은 자동 삭제
  - 압축 옵션 사용
  - 실행 로그는 /var/log/dpbackup.log에 기록
  - 실패 시 exit code와 함께 종료

Claude가 만들어 주는 결과 (예시)

#!/bin/bash
#
# datapump 백업 스크립트
# 대상: PROD_DB 스키마 / 보관 7일
#

# 환경 변수
export ORACLE_HOME=/u01/app/oracle/product/19c/dbhome_1
export ORACLE_SID=PRODDB
export PATH=$ORACLE_HOME/bin:$PATH

# 백업 설정
BACKUP_DIR="/backup/dpdump"
LOG_FILE="/var/log/dpbackup.log"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
DUMP_FILE="prod_db_${TIMESTAMP}.dmp"
SCHEMA="PROD_DB"

log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" >> "$LOG_FILE"
}

log "백업 시작: ${DUMP_FILE}"

# datapump 실행
expdp \"/ as sysdba\" \
    schemas=${SCHEMA} \
    directory=DATA_PUMP_DIR \
    dumpfile=${DUMP_FILE} \
    logfile=expdp_${TIMESTAMP}.log \
    compression=ALL >> "$LOG_FILE" 2>&1

if [ $? -ne 0 ]; then
    log "백업 실패 - exit code 1"
    exit 1
fi

# 7일 이전 파일 정리
find "$BACKUP_DIR" -name "prod_db_*.dmp" -type f -mtime +7 -delete

log "백업 완료: ${DUMP_FILE}"
exit 0

여기에 "cron에 등록까지 해 줘"를 이어서 요청하면 crontab -e 라인까지 만들어 줍니다.

0 2 * * * /home/oracle/scripts/dpbackup.sh >/dev/null 2>&1

효과

기존: 30분~1시간 (검색 + 변형 + 테스트) → Claude 활용: 5분.

사례 2: 디스크 용량 모니터링 + 알림

운영 환경에서 가장 자주 발생하는 장애 중 하나가 디스크 풀입니다. 미리 막는 스크립트가 있으면 좋은데, 처음부터 짜기는 귀찮습니다.

프롬프트

> 다음 조건으로 디스크 모니터링 셸 스크립트를 작성해 줘.
  - df로 모든 마운트 포인트 사용률 확인
  - 80% 이상이면 경고, 90% 이상이면 위험으로 분류
  - 위험 등급 발생 시 sendmail로 alert@company.com에 메일 발송
  - 메일 본문에 어떤 마운트가 몇 % 차 있는지, 큰 폴더 TOP 5도 포함
  - 5분마다 실행 가능한 구조로 (cron 등록 가정)
  - 직전 알림 후 1시간 내에는 같은 마운트에 대한 중복 알림 방지

핵심은 마지막 줄, "중복 알림 방지" 입니다. 단순 모니터링 스크립트는 디스크가 풀이면 5분마다 메일이 와서 운영자가 더 짜증이 납니다. 이런 디테일을 한 번에 요구할 수 있는 게 Claude Code의 강점입니다.

Claude가 만들어 주는 스크립트에는 상태 파일(/var/run/disk_monitor.state) 을 활용해서 마지막 알림 시각을 저장하고 비교하는 로직까지 들어갑니다.

추가 활용

이 스크립트를 만들고 나서 다음 명령을 이어서 줘 보세요.

> 이 스크립트를 운영팀에 인수인계할 수 있도록 README.md를 만들어 줘.
  설치, 실행, 알림 메일 예시, 트러블슈팅 항목까지 포함해서.

문서화까지 한 번에 끝납니다.

사례 3: 로그 파일 분석과 패턴 추출

운영 중에 가장 답답한 순간이 "수백 MB짜리 로그에서 특정 패턴 찾기" 입니다.

프롬프트 (장애 직후)

> /var/log/messages 최근 24시간 분량에서 다음을 분석해 줘.
  1. OOM Killer 발생 여부와 발생 시각 / 죽은 프로세스
  2. systemd 서비스 실패 (Failed to start) 목록
  3. 디스크 I/O 에러 (sd*, error 패턴)
  4. 시간대별 에러 발생 빈도 그래프 (텍스트로)

Claude가 직접 로그 파일을 읽고 grep / awk / 정렬을 조합해서 결과를 보여줍니다. 평소라면 30분 걸리는 분석이 1분 안에 끝납니다.

더 강력한 활용 - 알 수 없는 에러 분석

> /u01/app/oracle/diag/rdbms/proddb/PRODDB/trace/alert_PRODDB.log 
  파일 마지막 100줄을 보고, 이상 징후가 있는지 분석해 줘.
  ORA- 에러가 있다면 각각의 원인과 해결 방향을 정리해 줘.

오라클 alert 로그에서 ORA-XXXXX 에러를 찾아 각각의 의미와 대응 방안까지 요약해 줍니다. 트러블슈팅 시간이 크게 줄어듭니다.

사례 4: cron 작업 일괄 점검

서버를 인수인계 받았거나 오래된 서버를 점검할 때 가장 먼저 해야 할 일 중 하나입니다.

프롬프트

> 이 서버의 모든 사용자의 crontab을 수집해서 다음을 분석해 줘.
  1. 어떤 스크립트들이 등록되어 있는가
  2. 실행 주기 (매시간/매일/매주)
  3. 스크립트 파일이 실제로 존재하는가
  4. 최근 7일 내에 정상 실행되었는가 (로그 기준)
  5. 중복되거나 충돌 가능성이 있는 작업이 있는가
  결과를 마크다운 표로 정리해 줘.

Claude가 for user in $(cut -d: -f1 /etc/passwd); do crontab -u $user -l; done 같은 명령을 제안하고 실행한 뒤, 결과를 분석해서 표로 정리해 줍니다.

운영 환경 인수인계, 서버 정리, 컴플라이언스 점검 등 다양한 상황에서 활용 가능합니다.

사례 5: 장애 진단 스크립트 (서버가 느려졌을 때) ★ 가장 강력한 활용

장애 대응 중에 가장 중요한 건 속도입니다. "서버 느려요"라는 연락을 받았을 때, 일반적인 점검 순서를 모두 도는 데 10분 이상 걸립니다. 이걸 한 번에 자동화할 수 있습니다.

프롬프트

> 서버가 느려졌을 때 5분 안에 원인을 찾기 위한 진단 스크립트를 만들어 줘.
  다음 항목을 자동으로 수집해서 보고서 형태로 출력:
  
  [시스템]
  - load average (uptime)
  - CPU 사용률 (top 1회 / mpstat)
  - 메모리 사용률, swap 사용량
  - 디스크 IO 부하 (iostat 1회 5초 평균)
  - 네트워크 연결 상태 (ss -s)
  
  [프로세스]
  - CPU 점유 TOP 10
  - 메모리 점유 TOP 10
  - 좀비 프로세스 존재 여부
  
  [DB (Oracle)]
  - 활성 세션 수 (v$session 카운트, sysdba 권한 필요)
  - 대기 이벤트 TOP 5 (v$session_wait)
  - 락 발생 여부
  
  [로그]
  - /var/log/messages 마지막 50줄에서 에러 패턴
  - alert 로그 최근 5분 이내 ORA- 발생 여부
  
  결과는 /tmp/diag_YYYYMMDD_HHMMSS.txt에 저장하고
  요약은 화면에 출력.

이 한 번의 프롬프트로 평소 10분 걸리던 1차 진단을 30초로 단축할 수 있는 진단 스크립트가 만들어집니다. 한 번 만들어 두고 운영 표준 도구로 등록해 두면 매번 활용 가능합니다.

운영 환경 도입 시 추가 팁

1. 위험한 명령 자동 차단

CLAUDE.md에 다음 규칙을 명시하면 안전성이 더 올라갑니다.

# 절대 금지 명령
- rm -rf /*
- DROP TABLE / DROP USER (단순 SQL 안내는 가능)
- shutdown / reboot
- 운영 DB의 ALTER SYSTEM
- iptables -F (방화벽 전체 삭제)

이 패턴을 포함한 명령은 절대 실행 제안하지 말 것.

2. 실행 권한 분리

Claude Code를 실행하는 OS 계정과 운영 작업을 실행하는 계정을 분리하세요. Claude Code는 일반 사용자 계정으로 띄우고, 실제 운영 작업은 sudo를 통해 명시적으로 승인하는 패턴을 권장합니다.

3. 결과물은 git으로 관리

Claude가 만들어 준 스크립트를 그냥 쓰지 말고 git 저장소에 commit하세요. 운영 표준화에도 도움이 되고, 나중에 같은 패턴을 다시 활용할 때도 편리합니다.

git init
git add scripts/
git commit -m "백업 스크립트 v1 - Claude Code 작성"

4. 점진적 자동화

처음부터 모든 작업을 자동화하지 마세요. 다음 순서를 권장합니다.

검색·문서화 작업부터 (가장 안전, 가장 큰 효과)
개발/테스트 환경 스크립트 작성
운영 환경의 읽기 전용 모니터링 스크립트
운영 환경의 백업/정리 작업 (단방향 작업)
운영 환경의 변경 작업 (마지막 단계, 반드시 리뷰)

마무리

Claude Code는 단순히 "코드를 빠르게 짜주는 도구"가 아니라 운영자의 인지 부하를 크게 낮춰주는 도구입니다. 검색-분석-스크립트 작성-문서화의 사이클이 한 곳에서 끝나면서 실제 업무에 들이는 시간이 1/3 이하로 줄어듭니다.

다음 3편에서는 SQL 작성·튜닝과 오라클 DBA 업무에 Claude Code를 활용하는 방법을 다룹니다. DBMS_SCHEDULER 작업 등록, SQL 튜닝, ORA 에러 분석 등 DBA 업무에 특화된 사례를 정리할 예정입니다.

본인이 자동화한 운영 작업이나 더 좋은 패턴이 있다면 댓글로 공유해 주세요.

시리즈 안내

1편: DBA와 서버 관리자가 Claude Code를 써야 하는 이유 - 설치부터 실전 5가지 활용까지
2편 (이 글): 셸 스크립트와 운영 자동화에 Claude Code 활용하기
3편: SQL과 DBA 업무에 Claude Code 활용하기 (작성 예정)

[Claude Code 활용 1편] DBA와 서버 관리자가 Claude Code를 써야 하는 이유 - 설치부터 실전 5가지 활용까지

isony — Tue, 2 Jun 2026 13:03:46 +0900

[Claude Code 활용 1편] DBA와 서버 관리자가 Claude Code를 써야 하는 이유 - 설치부터 실전 5가지 활용까지

테스트 환경: macOS / Ubuntu 22.04 / Windows 11(WSL2), Node.js 20, Claude Code v2.x

개발자 사이에서 Claude Code 이야기가 많이 들립니다. 그런데 "나는 코드 짜는 사람도 아닌데 이게 나에게 도움이 될까?" 하는 분들도 계실 겁니다. 결론부터 말씀드리면, 운영 환경을 관리하는 DBA나 서버 관리자에게 Claude Code는 셸 스크립트, SQL 쿼리, 설정 파일, 로그 분석 도구가 일상인 업무에서 즉시 효과를 보는 도구입니다.

이 시리즈는 총 3편으로 구성됩니다.

1편 (이 글): Claude Code가 무엇이고, 어떻게 설치하며, 운영자 관점에서 어떤 활용이 가능한지
2편: 셸 스크립트와 운영 자동화에 활용하기
3편: SQL과 DBA 업무에 활용하기

이번 1편은 입문 가이드입니다. 개발 경험이 적어도 따라할 수 있도록 구성했고, "이런 작업에 쓸 수 있구나" 감을 잡는 데 초점을 맞췄습니다.

Claude Code란 무엇인가

Claude Code는 Anthropic이 만든 터미널 기반 AI 코딩 어시스턴트입니다. ChatGPT처럼 웹브라우저에서 쓰는 게 아니라, 본인 컴퓨터의 터미널(명령 프롬프트)에서 자연어로 대화하면서 작업합니다.

기존 AI 도구와 가장 다른 점은 세 가지입니다.

항목 일반 AI 챗봇 Claude Code

작업 환경	웹 브라우저 (복붙 필수)	터미널 (파일에 직접 작업)
파일 접근	❌ 불가	✅ 직접 읽고 쓰기
명령 실행	❌ 불가	✅ 셸 명령 실행 가능
컨텍스트	대화 한 번으로 끝	프로젝트 폴더 전체 인식

운영자 입장에서 가장 큰 차이는 "파일을 직접 읽고 쓸 수 있다" 입니다. 셸 스크립트, SQL 파일, 로그 파일을 일일이 복사해서 챗봇에 붙여 넣을 필요 없이, "이 파일 분석해 줘" 한 마디면 됩니다.

설치 (Linux / macOS / Windows WSL2)

설치는 약 5분이면 끝납니다.

1단계: Node.js 설치 확인

Claude Code는 Node.js 18 이상이 필요합니다.

node --version

v18.x.x 이상이 나오면 OK. 없거나 낮은 버전이라면:

Ubuntu/CentOS: sudo apt install nodejs npm 또는 NodeSource 저장소 활용
macOS: brew install node
Windows: WSL2 환경에 Ubuntu를 설치하고 위 명령 실행 권장

2단계: Claude Code 설치

npm install -g @anthropic-ai/claude-code

전역 설치(-g)라 어디서든 claude 명령으로 호출됩니다.

3단계: 첫 실행 및 로그인

작업할 폴더로 이동한 뒤 명령어를 실행합니다.

cd ~/work/myproject
claude

첫 실행 시 인증 절차가 진행됩니다. 브라우저가 열리거나 코드를 입력하라는 안내가 나오는데, 가이드대로 따라가면 됩니다. Claude.ai 유료 플랜(Pro/Max) 계정으로 로그인하거나 API 키를 입력하면 됩니다.

요금제별로 사용량 제한이 다르므로 본인의 상황에 맞게 선택하세요. 자세한 내용은 Anthropic 공식 문서에서 확인 가능합니다.

4단계: 첫 명령

> 이 폴더에 있는 파일들을 보고 어떤 프로젝트인지 설명해 줘

자연어로 입력하면 Claude가 폴더를 분석하고 응답합니다. 영어로 쓸 필요 없고, 한국어 그대로 입력해도 정상 동작합니다.

운영자 관점에서 Claude Code의 진짜 장점

다른 블로그들은 대부분 "코드 작성"에 초점을 맞춥니다. 하지만 DBA나 서버 관리자 관점에서는 다른 강점들이 더 큽니다.

장점 1: 검색-요약-적용 사이클이 한 곳에서 끝남

장애가 터졌을 때 평소 워크플로우:

에러 메시지 구글 검색
스택오버플로우 / 한국어 블로그 5~10개 클릭
정보 취합
본인 환경에 맞게 변형
적용

Claude Code 워크플로우:

claude 실행 후 "이 에러 원인이 뭐고 어떻게 해결해?" 입력
분석 결과 + 본인 환경에 맞춘 명령어를 바로 제시
승인하면 즉시 적용

특히 본인 서버의 설정 파일, 로그, 환경 정보를 직접 보고 답을 주기 때문에 검색 결과를 본인 환경에 끼워 맞추는 수고가 없어집니다.

장점 2: 셸 명령 실행 권한 (수동 승인 방식)

"디스크 용량 확인하고 가장 큰 폴더 찾아 줘"라고 하면 Claude가 df -h, du -sh /* 같은 명령을 제안하고 사용자가 승인하면 실행합니다. 명령 실행 전에 항상 확인을 받는 구조라 운영 환경에서도 안전합니다.

장점 3: 한 번의 컨텍스트로 여러 파일 다루기

크론탭, 셸 스크립트, 로그 파일을 한꺼번에 보면서 "이 크론에서 호출하는 스크립트가 왜 매일 새벽 3시에 에러가 나는지 진단해 줘"가 가능합니다. 웹 챗봇에 일일이 붙여 넣는 것과 차원이 다릅니다.

장점 4: 반복 작업의 자동화

매주 반복하는 점검 작업, 매일 돌리는 통계 스크립트 등을 한 번 만들어 두면 다음부터는 "지난번 그 스크립트 좀 수정해 줘" 한 마디면 됩니다.

DBA·서버 관리자가 첫 주에 시도해볼 만한 5가지 활용

설치 직후 바로 효과를 체감할 수 있는 케이스 5개입니다.

활용 1: 셸 스크립트 빠르게 만들기

> /home/oracle/backup 디렉토리에서 7일 이상 된 .dmp 파일을 찾아 
  /backup/archive로 이동시키는 셸 스크립트를 작성해 줘.
  실행 결과는 /var/log/cleanup.log에 기록하고.

응답으로 완성된 스크립트를 받고, "이거 cron에 매일 새벽 3시 실행되도록 등록해 줘"까지 이어갈 수 있습니다.

활용 2: 로그 파일 분석

> /var/log/messages 최근 1000줄에서 OOM Killer 발생 여부 확인하고, 
  발생했다면 어떤 프로세스가 죽었는지 정리해 줘.

수백 MB짜리 로그를 grep으로 헤매는 대신, Claude가 패턴을 찾아주고 요약까지 합니다.

활용 3: 설정 파일 검토

> 이 listener.ora 파일을 보고 설정상 문제가 있는지, 
  보안 관점에서 개선할 점이 있는지 알려 줘.

오라클 listener.ora, sqlnet.ora, init.ora 같은 설정 파일을 던져 주면 분석해 줍니다. 검토 기준을 알려주면 더 구체적인 피드백이 옵니다.

활용 4: 명령어 / 문법 즉시 확인

> RHEL 8에서 firewalld로 1521 포트만 특정 IP 대역(192.168.10.0/24)에 
  허용하는 명령어 알려 줘.

검색 → 블로그 5개 비교 → 본인 환경 맞춤 변형의 과정이 한 번에 끝납니다.

활용 5: 문서화 자동 생성

> 이 backup.sh 스크립트의 동작을 운영팀에 인수인계할 수 있도록 
  마크다운 문서로 정리해 줘. 사전 조건, 실행 방법, 
  실패 시 대응까지 포함해서.

운영 인수인계 문서는 만들기 귀찮은 작업 중 하나입니다. 스크립트를 보여주면 자동으로 정리된 문서를 만들어 줍니다.

실무 도입 시 주의사항 4가지

운영 환경에 적용하기 전에 알아둬야 할 것들입니다.

1. 운영 DB에 직접 명령 실행은 금물

Claude Code가 똑똑하긴 하지만, 운영 환경의 실행 권한은 별도 계정 / 별도 터미널로 분리하세요. 개발 / 테스트 환경에서 충분히 검증한 후 운영에 적용하는 워크플로를 유지해야 합니다.

2. 민감 정보 노출 주의

비밀번호, API 키, 개인정보가 들어 있는 파일을 통째로 분석시키면 외부 API로 전송됩니다. 작업 전에 마스킹하거나, 회사 보안 정책상 외부 AI 도구 사용이 제한된다면 사전에 확인하세요.

3. 권한 승인 패턴 익히기

Claude Code는 파일 변경이나 명령 실행 전에 항상 사용자 확인을 받습니다. "yes"를 습관처럼 누르지 말고, 어떤 명령을 실행하려는지 한 번씩 확인하는 습관이 필요합니다. 특히 rm, chmod, truncate 같은 명령은 더 그렇습니다.

4. 모델 선택 (비용 vs 성능)

복잡한 작업은 상위 모델(Opus 계열), 간단한 작업은 하위 모델(Haiku, Sonnet)을 쓰면 비용을 절약할 수 있습니다. /model 명령으로 변경 가능합니다. 사용 가능한 모델은 시기별로 달라지니 공식 문서를 참고하세요.

첫 주 학습 계획 - 운영자용

설치 후 첫 일주일은 다음 순서로 익히는 것을 권장합니다.

일차 학습 내용

1일차	설치 + 자연어 대화 익히기 (claude 명령으로 일상 질문)
2일차	셸 스크립트 작성 시키기 (위 활용 1번)
3일차	로그 파일 분석 (위 활용 2번)
4일차	설정 파일 검토 (위 활용 3번)
5일차	CLAUDE.md 파일 만들기 (프로젝트별 컨텍스트 설정)
6~7일차	본인 실제 업무에 한 가지 적용해 보기

CLAUDE.md 는 프로젝트 폴더에 두면 Claude가 자동으로 읽는 메모입니다. "이 폴더는 오라클 DB 운영 스크립트가 모여 있고, RHEL 8 환경입니다" 같은 컨텍스트를 적어두면 매번 설명할 필요가 없어집니다.

마무리

Claude Code는 코딩에 관심 없는 운영자에게도 강력한 도구입니다. "코드를 작성하는 도구"가 아니라 "텍스트 기반 업무를 자동화하는 도구" 로 접근하면 활용 범위가 훨씬 넓어집니다.

다음 2편에서는 본격적으로 셸 스크립트 작성과 운영 자동화 사례를 다룹니다. 실제 운영 환경에서 자주 만나는 작업을 예제로 풀어 가겠습니다.

질문이나 본인 환경에서 시도해 본 경험이 있다면 댓글로 공유해 주세요.

시리즈 안내

1편 (이 글): DBA와 서버 관리자가 Claude Code를 써야 하는 이유 - 설치부터 실전 5가지 활용까지
2편: 셸 스크립트와 운영 자동화에 Claude Code 활용하기 (작성 예정)
3편: SQL과 DBA 업무에 Claude Code 활용하기 (작성 예정)

[오라클 실무] DBMS_SCHEDULER로 프로시저를 6시간 단위 실행하기 - 동적 인자 전달 완벽 예제

isony — Mon, 1 Jun 2026 16:38:00 +0900

[오라클 실무] DBMS_SCHEDULER로 프로시저를 6시간 단위 실행하기 - 동적 인자 전달 완벽 예제

테스트 환경: Oracle 12c / 19c / 21c

DBMS_SCHEDULER로 배치 작업을 등록할 때 가장 자주 막히는 부분이 "실행할 때마다 바뀌는 인자(예: 어제/오늘 날짜)를 어떻게 동적으로 전달하느냐" 입니다.

SET_JOB_ARGUMENT_VALUE로 인자를 박으면 정적 값이 고정되어 매일 같은 값으로 실행되고, 그렇다고 매번 작업을 다시 만들 수도 없습니다. 정답은 PLSQL_BLOCK 타입으로 호출하면서 인자 평가를 작업 액션 안으로 넣는 것입니다.

이번 글에서는 실제 운영 환경에서 자주 나오는 케이스 — "PROC_TAX_PURCHASE_A10(어제, 오늘)을 매일 04시, 10시, 16시, 22시에 실행" — 를 예제로, 등록부터 검증, 운영까지 한 번에 정리했습니다.

급하신 분은 전체 코드 한 번에 보기 섹션부터 보세요.

요구사항 정리

먼저 만들 작업의 사양을 정리해 봅니다.

항목 내용

실행할 프로시저	PROC_TAX_PURCHASE_A10
인자 1	어제 날짜 (YYYYMMDD 8자리 문자열)
인자 2	오늘 날짜 (YYYYMMDD 8자리 문자열)
실행 주기	매일 04시, 10시, 16시, 22시 (6시간 간격)
인자 평가 시점	매 실행 시점 (등록 시점 아님)

핵심은 마지막 줄입니다. 작업을 한 번 등록하지만, 실행될 때마다 그 시점의 SYSDATE로 인자가 다시 계산되어야 합니다.

전체 코드 한 번에 보기

복붙해서 바로 사용하실 수 있는 완성 코드입니다.

BEGIN
    DBMS_SCHEDULER.CREATE_JOB(
        job_name        => 'JOB_TAX_PURCHASE_A10',
        job_type        => 'PLSQL_BLOCK',
        job_action      => q'[
            DECLARE
                v_yest  VARCHAR2(8) := TO_CHAR(SYSDATE - 1, 'YYYYMMDD');
                v_today VARCHAR2(8) := TO_CHAR(SYSDATE,     'YYYYMMDD');
            BEGIN
                PROC_TAX_PURCHASE_A10(v_yest, v_today);
            END;
        ]',
        start_date      => SYSTIMESTAMP,
        repeat_interval => 'FREQ=DAILY;BYHOUR=4,10,16,22;BYMINUTE=0;BYSECOND=0',
        enabled         => TRUE,
        comments        => '세금/구매 데이터 처리 - 매일 04, 10, 16, 22시 실행'
    );
END;
/

위 코드 하나만 실행하면 작업 등록이 끝납니다. 이제 각 부분을 자세히 보겠습니다.

코드 한 줄씩 해부하기

1) job_name - 작업 이름

job_name => 'JOB_TAX_PURCHASE_A10'

작업 이름은 스키마 내에서 유일해야 합니다. 접두사 JOB_을 일관되게 붙이면 dba_scheduler_jobs 조회 시 한 번에 모아 볼 수 있어 운영에 유리합니다.

2) job_type - 작업 유형

job_type => 'PLSQL_BLOCK'

STORED_PROCEDURE를 쓰면 SET_JOB_ARGUMENT_VALUE로 인자를 박아야 해서 동적 인자 전달이 사실상 불가능합니다. 인자가 매번 달라져야 하는 경우 PLSQL_BLOCK이 답입니다.

유형 동적 인자 사용 시점

PLSQL_BLOCK	✅ 가능	인자가 매 실행마다 달라질 때 (이 경우)
STORED_PROCEDURE	❌ 정적만	인자가 고정될 때
EXECUTABLE	✅ 가능	OS 셸 스크립트 실행

3) job_action - 핵심 ★

job_action => q'[
    DECLARE
        v_yest  VARCHAR2(8) := TO_CHAR(SYSDATE - 1, 'YYYYMMDD');
        v_today VARCHAR2(8) := TO_CHAR(SYSDATE,     'YYYYMMDD');
    BEGIN
        PROC_TAX_PURCHASE_A10(v_yest, v_today);
    END;
]'

이 글에서 가장 중요한 부분입니다. 두 가지 디테일이 들어있습니다.

디테일 1: q'[ ]' 인용 표기법 사용

job_action은 VARCHAR2 문자열입니다. 안에 작은따옴표가 들어가면 보통 두 번 써야 하는데(''YYYYMMDD''), 코드가 지저분해집니다. Oracle 10g부터 지원하는 q-quoting 문법을 쓰면 작은따옴표를 그대로 쓸 수 있습니다.

-- ❌ 일반 방식 (작은따옴표 두 번 - 가독성 떨어짐)
job_action => 'BEGIN PROC_TAX_PURCHASE_A10(TO_CHAR(SYSDATE-1,''YYYYMMDD''), TO_CHAR(SYSDATE,''YYYYMMDD'')); END;'

-- ✅ q-quoting (작은따옴표 그대로 - 깔끔)
job_action => q'[BEGIN PROC_TAX_PURCHASE_A10(TO_CHAR(SYSDATE-1,'YYYYMMDD'), TO_CHAR(SYSDATE,'YYYYMMDD')); END;]'

긴 PL/SQL 블록일수록 차이가 큽니다. 운영 코드에서는 q-quoting 사용을 강력히 권장합니다.

디테일 2: 인자를 변수에 먼저 담는 패턴

직접 호출도 가능합니다.

BEGIN
    PROC_TAX_PURCHASE_A10(
        TO_CHAR(SYSDATE-1, 'YYYYMMDD'),
        TO_CHAR(SYSDATE,   'YYYYMMDD')
    );
END;

하지만 변수에 먼저 받아두는 패턴이 두 가지 이유로 더 안전합니다.

첫째, 자정 경계 문제 방지. 두 SYSDATE 호출 사이에 자정이 지나면 어제와 오늘 값이 어긋날 수 있습니다. 새벽 04시 실행에서는 거의 발생하지 않지만, 변수에 한 번에 담아두면 인자 일관성이 보장됩니다.

둘째, 로그 남기기 쉬움. 디버깅이 필요할 때 변수 값을 DBMS_OUTPUT.PUT_LINE이나 로그 테이블에 기록하기 편합니다.

-- 디버깅 가능한 확장 패턴
DECLARE
    v_yest  VARCHAR2(8) := TO_CHAR(SYSDATE - 1, 'YYYYMMDD');
    v_today VARCHAR2(8) := TO_CHAR(SYSDATE,     'YYYYMMDD');
BEGIN
    INSERT INTO batch_log VALUES (SYSDATE, 'A10 시작', v_yest, v_today);
    PROC_TAX_PURCHASE_A10(v_yest, v_today);
    INSERT INTO batch_log VALUES (SYSDATE, 'A10 종료', v_yest, v_today);
    COMMIT;
END;

4) repeat_interval - 6시간 간격 표현

repeat_interval => 'FREQ=DAILY;BYHOUR=4,10,16,22;BYMINUTE=0;BYSECOND=0'

이 표현식이 "매일 04:00, 10:00, 16:00, 22:00 실행"을 의미합니다. 각 절을 분해하면:

절 의미

FREQ=DAILY	일 단위 반복
BYHOUR=4,10,16,22	04시, 10시, 16시, 22시
BYMINUTE=0	0분 (정각)
BYSECOND=0	0초

왜 FREQ=HOURLY;INTERVAL=6을 안 쓰는가?

FREQ=HOURLY;INTERVAL=6도 6시간마다 실행되긴 하지만, 시작 시각이 start_date에 따라 결정되어 "정확히 04/10/16/22시"가 보장되지 않습니다. 예를 들어 11시에 등록하면 11시, 17시, 23시, 05시로 실행될 수 있습니다.

시각을 명시적으로 지정해야 한다면 반드시 BYHOUR를 쓰세요. 이게 운영자가 가장 자주 실수하는 부분입니다.

BYMINUTE=0;BYSECOND=0을 꼭 넣어야 하는 이유

생략하면 작업 등록 시각의 분/초가 매 실행에도 적용됩니다. 11:23:45에 등록했다면 04:23:45, 10:23:45 식으로 실행됩니다. 정각 실행이 필요하면 반드시 명시하세요.

5) start_date - 시작 시각

start_date => SYSTIMESTAMP

SYSTIMESTAMP로 지정하면 "지금부터 활성"이라는 뜻입니다. 다음 실행은 다음 BYHOUR 시각에 자동으로 잡힙니다.

타임존 주의 (★ 19c 이상)

19c부터 DBMS_SCHEDULER가 세션 타임존을 사용하면서 업그레이드 후 실행 시각이 어긋나는 사례가 있습니다. 운영 환경이라면 명시적 타임존 지정이 안전합니다.

start_date => TO_TIMESTAMP_TZ('2026-06-02 04:00:00 Asia/Seoul',
                              'YYYY-MM-DD HH24:MI:SS TZR')

6) enabled - 활성화 여부

enabled => TRUE

DBMS_SCHEDULER의 기본값은 FALSE(비활성) 입니다. 명시적으로 TRUE를 주지 않으면 작업은 등록되지만 절대 실행되지 않습니다. 가장 흔한 함정 중 하나입니다.

등록 직후 검증 - 3단계

운영 환경에 작업을 등록했다면 다음 3가지를 반드시 확인하세요.

단계 1: 작업이 정상 등록되었나

SELECT job_name, state, enabled, 
       TO_CHAR(next_run_date, 'YYYY-MM-DD HH24:MI:SS') AS next_run,
       repeat_interval
FROM   user_scheduler_jobs
WHERE  job_name = 'JOB_TAX_PURCHASE_A10';

확인 포인트:

state = SCHEDULED (정상)
enabled = TRUE
next_run = 가장 가까운 04/10/16/22시 중 하나

단계 2: 다음 10번의 실행 시각 미리보기

스케줄이 의도대로 잡혔는지 등록 전에 검증하는 가장 좋은 방법입니다.

DECLARE
    v_start   TIMESTAMP WITH TIME ZONE := SYSTIMESTAMP;
    v_next    TIMESTAMP WITH TIME ZONE;
BEGIN
    FOR i IN 1..10 LOOP
        DBMS_SCHEDULER.EVALUATE_CALENDAR_STRING(
            calendar_string   => 'FREQ=DAILY;BYHOUR=4,10,16,22;BYMINUTE=0;BYSECOND=0',
            start_date        => SYSTIMESTAMP,
            return_date_after => v_start,
            next_run_date     => v_next
        );
        DBMS_OUTPUT.PUT_LINE(i || '회차: ' || TO_CHAR(v_next, 'YYYY-MM-DD HH24:MI:SS TZR'));
        v_start := v_next;
    END LOOP;
END;
/

출력 예시:

1회차: 2026-06-01 22:00:00 ASIA/SEOUL
2회차: 2026-06-02 04:00:00 ASIA/SEOUL
3회차: 2026-06-02 10:00:00 ASIA/SEOUL
4회차: 2026-06-02 16:00:00 ASIA/SEOUL
...

이 검증을 본 등록 전에 미리 실행하면 사고를 95% 막을 수 있습니다.

단계 3: 수동으로 한 번 실행 테스트

스케줄에 따른 첫 실행을 기다리지 말고, 즉시 한 번 돌려서 프로시저 자체에 문제가 없는지 확인합니다.

EXEC DBMS_SCHEDULER.RUN_JOB('JOB_TAX_PURCHASE_A10', use_current_session => FALSE);

use_current_session => FALSE로 주면 실제 스케줄러 워커가 실행하는 환경과 동일하게 동작합니다. 권한, 세션 설정 등 문제를 미리 잡을 수 있습니다.

실행 이력 모니터링

작업 등록만큼 중요한 게 사후 모니터링입니다. SCHEDULED 상태인데도 실제로는 안 돌고 있는 경우가 운영 환경에서 자주 발생합니다.

일별 실행 결과 확인

SELECT TO_CHAR(actual_start_date, 'YYYY-MM-DD HH24:MI:SS') AS start_time,
       status,
       run_duration,
       error#,
       SUBSTR(errors, 1, 200) AS error_message
FROM   user_scheduler_job_run_details
WHERE  job_name = 'JOB_TAX_PURCHASE_A10'
ORDER  BY actual_start_date DESC
FETCH  FIRST 20 ROWS ONLY;

status 가능 값:

SUCCEEDED: 정상 완료
FAILED: 실패 (error#, errors에서 사유 확인)
STOPPED: 외부에서 중단됨
BROKEN: 연속 실패로 자동 비활성화됨

실패 알림 자동화 (★ 실무 핵심)

운영 환경에서는 작업이 실패했을 때 즉시 알림이 필요합니다. DBMS_SCHEDULER는 이메일 알림을 기본 지원합니다.

-- 1) 메일 서버 설정 (한 번만)
BEGIN
    DBMS_SCHEDULER.SET_SCHEDULER_ATTRIBUTE('email_server', 'smtp.company.com:25');
    DBMS_SCHEDULER.SET_SCHEDULER_ATTRIBUTE('email_sender', 'dba@company.com');
END;
/

-- 2) 실패 시 알림 등록
BEGIN
    DBMS_SCHEDULER.ADD_JOB_EMAIL_NOTIFICATION(
        job_name   => 'JOB_TAX_PURCHASE_A10',
        recipients => 'dba-team@company.com',
        events     => 'JOB_FAILED, JOB_BROKEN, JOB_SCH_LIM_REACHED'
    );
END;
/

이렇게 해두면 작업이 실패한 순간 담당자에게 메일이 발송됩니다.

운영 관리 명령어 모음

자주 쓰는 명령어를 모았습니다. 운영 매뉴얼에 그대로 활용 가능합니다.

-- 즉시 실행 (수동)
EXEC DBMS_SCHEDULER.RUN_JOB('JOB_TAX_PURCHASE_A10');

-- 임시 비활성화 (점검 시)
EXEC DBMS_SCHEDULER.DISABLE('JOB_TAX_PURCHASE_A10');

-- 다시 활성화
EXEC DBMS_SCHEDULER.ENABLE('JOB_TAX_PURCHASE_A10');

-- 실행 시각 변경 (예: 매일 03, 09, 15, 21시로)
BEGIN
    DBMS_SCHEDULER.SET_ATTRIBUTE(
        name      => 'JOB_TAX_PURCHASE_A10',
        attribute => 'repeat_interval',
        value     => 'FREQ=DAILY;BYHOUR=3,9,15,21;BYMINUTE=0;BYSECOND=0'
    );
END;
/

-- 현재 실행 중인 인스턴스 강제 중지
EXEC DBMS_SCHEDULER.STOP_JOB('JOB_TAX_PURCHASE_A10', force => TRUE);

-- 작업 완전 삭제
EXEC DBMS_SCHEDULER.DROP_JOB('JOB_TAX_PURCHASE_A10');

운영 환경 주의사항 5가지

1. 이전 실행이 안 끝났는데 다음 시각이 오면?

DBMS_SCHEDULER는 기본적으로 이전 실행이 완료될 때까지 다음 실행을 대기시킵니다. 06시간 간격이라 6시간 안에 끝나야 다음 사이클이 정상 동작합니다.

만약 작업이 길어질 수 있다면 작업 분할 또는 병렬 처리를 검토하세요. 실행 시간 모니터링은 필수입니다.

-- 평균 / 최대 실행 시간 확인
SELECT AVG(EXTRACT(SECOND FROM run_duration) +
           EXTRACT(MINUTE FROM run_duration) * 60) AS avg_seconds,
       MAX(EXTRACT(SECOND FROM run_duration) +
           EXTRACT(MINUTE FROM run_duration) * 60) AS max_seconds
FROM   user_scheduler_job_run_details
WHERE  job_name = 'JOB_TAX_PURCHASE_A10'
  AND  status = 'SUCCEEDED'
  AND  actual_start_date > SYSDATE - 30;

2. JOB_QUEUE_PROCESSES 파라미터 확인

이 값이 0이면 모든 스케줄러 작업이 중지됩니다.

SHOW PARAMETER job_queue_processes

기본값은 보통 1000입니다. 너무 낮게 설정되어 있으면 동시 실행 작업이 많을 때 대기가 발생합니다.

3. 권한 확인

PROC_TAX_PURCHASE_A10이 다른 스키마에 있다면 EXECUTE 권한이 필요하고, 작업을 만들 사용자는 CREATE JOB 시스템 권한이 있어야 합니다.

-- 권한 확인
SELECT * FROM user_sys_privs WHERE privilege LIKE '%JOB%';
SELECT * FROM user_tab_privs WHERE table_name = 'PROC_TAX_PURCHASE_A10';

4. RAC 환경에서 특정 노드 지정

특정 인스턴스에서만 실행하고 싶다면:

BEGIN
    DBMS_SCHEDULER.SET_ATTRIBUTE(
        name      => 'JOB_TAX_PURCHASE_A10',
        attribute => 'INSTANCE_ID',
        value     => 1
    );
END;
/

5. 작업 실행 중 DB 재시작 시 동작

작업이 실행 중인데 DB가 셧다운되면 해당 실행은 중단되고, 다음 스케줄 시각부터 정상 동작합니다. 중단된 실행은 자동 재시작되지 않습니다. 누락된 데이터가 있다면 수동 실행이 필요합니다.

마무리

DBMS_SCHEDULER로 동적 인자가 필요한 배치 작업을 등록할 때 핵심은 세 가지입니다.

PLSQL_BLOCK 타입 + job_action 안에 인자 평가 — 매 실행 시점에 SYSDATE가 새로 계산됩니다.
repeat_interval에 BYHOUR/BYMINUTE/BYSECOND 명시 — 정확한 시각에 실행하려면 모두 지정해야 합니다.
등록 후 EVALUATE_CALENDAR_STRING으로 검증 — 예상과 다른 시각에 잡히는 사고를 미리 막습니다.

이 글의 예제는 매일 4회 실행되는 세금/구매 데이터 처리지만, 같은 패턴으로 매시간 통계 갱신, 매주 마감 작업, 매월 1일 정산 배치 등 어떤 주기 작업이라도 응용 가능합니다. 본인 환경의 실행 시각과 프로시저 이름만 바꾸면 됩니다.

비슷한 배치 작업을 운영하면서 만난 이슈나, 더 좋은 패턴이 있다면 댓글로 공유해 주세요.

[오라클] DBMS_JOB과 DBMS_SCHEDULER 차이점 - 언제 뭘 써야 할까? (19c 변환 동작까지)

isony — Mon, 1 Jun 2026 16:29:17 +0900

오라클 DBMS_JOB과 DBMS_SCHEDULER 차이점 - 언제 뭘 써야 할까? (19c 변환 동작까지)

테스트 환경: Oracle 11g / 12c / 19c / 21c

오라클에서 작업을 자동화할 때 가장 많이 검색되는 질문 중 하나가 "DBMS_JOB과 DBMS_SCHEDULER, 둘 다 있는데 뭐가 다른가?" 입니다.

결론부터 말씀드리면, 2026년 현재 시점에서 새로 만드는 작업은 100% DBMS_SCHEDULER를 써야 합니다. DBMS_JOB은 12cR2부터 deprecated되었고, 19c부터는 사용해도 내부적으로 DBMS_SCHEDULER로 변환되어 동작합니다.

그렇다면 왜 아직도 운영 환경에 DBMS_JOB이 살아있고, 두 개의 차이를 알아둬야 하는 걸까요? 이번 글에서 둘의 핵심 차이, 19c부터 달라진 동작, 그리고 기존 DBMS_JOB을 DBMS_SCHEDULER로 옮기는 실무 방법까지 정리했습니다.

한 줄 요약

구분 DBMS_JOB DBMS_SCHEDULER

등장 시점	Oracle 7 이전부터	Oracle 10g부터
현재 상태	12cR2부터 deprecated	권장 표준
19c 이상 동작	내부적으로 DBMS_SCHEDULER로 변환	그대로 사용
새 개발 권장 여부	❌ 사용 금지	✅ 권장

새 코드는 무조건 DBMS_SCHEDULER. 이게 끝입니다. 다만 운영 중인 DBMS_JOB을 이해하고 마이그레이션하려면 두 패키지의 차이를 알아야 합니다.

핵심 차이점 비교

항목 DBMS_JOB DBMS_SCHEDULER

작업 종류	PL/SQL 블록만	PL/SQL, 저장 프로시저, OS 실행파일, 외부 스크립트, 체인(Chain)
외부 OS 명령 실행	❌ 불가	✅ 가능 (EXECUTABLE 타입)
트랜잭션 동작	트랜잭션의 일부 (COMMIT 해야 등록됨)	별도 트랜잭션 (즉시 커밋)
스케줄 표현	DATE 산술식 (SYSDATE+1)	캘린더 표현식 (FREQ=DAILY;BYHOUR=2)
의존성/체인	❌ 없음	✅ 작업 간 의존 관계 정의 가능
리소스 관리	❌ 없음	✅ Resource Manager 연동
작업 클래스	❌ 없음	✅ Job Class로 그룹 관리
모니터링 뷰	DBA_JOBS, DBA_JOBS_RUNNING	DBA_SCHEDULER_JOBS, DBA_SCHEDULER_JOB_RUN_DETAILS 등 풍부
오류 처리	빈약	상세한 실행 이력 및 실패 사유 기록

이 표만 봐도 DBMS_SCHEDULER가 모든 면에서 우위라는 게 명확합니다. 단 한 가지, 트랜잭션 동작은 상황에 따라 DBMS_JOB이 유리한 경우가 있는데, 이건 뒤에서 다룹니다.

DBMS_JOB - 옛날 방식

기본 사용법

DECLARE
    v_job NUMBER;
BEGIN
    DBMS_JOB.SUBMIT(
        job       => v_job,
        what      => 'BEGIN my_procedure; END;',
        next_date => SYSDATE,
        interval  => 'SYSDATE + 1/24'   -- 1시간마다
    );
    COMMIT;   -- ★ 이게 없으면 등록 안 됨
END;
/

DBMS_JOB의 결정적 단점

외부 OS 명령 실행 불가 — PL/SQL 블록만 돌릴 수 있어서 백업 스크립트, 외부 파일 처리 등은 불가능
INTERVAL이 모호하고 가독성 떨어짐 — 'SYSDATE + 1/24'가 매시간이라는 걸 한눈에 알기 어려움
실행 이력 추적 어려움 — 실패 사유, 실행 시간 같은 정보가 빈약
작업 간 의존성 표현 불가 — "A 끝나면 B 실행" 같은 체인 구성 안 됨

그래도 살아남는 이유: 트랜잭션 일부 동작 ★

DBMS_JOB은 트랜잭션의 일부로 작업을 등록합니다. 즉, COMMIT을 해야만 작업이 실제로 큐에 들어갑니다. 이게 의외로 유용한 케이스가 있습니다.

시나리오: 트리거에서 이메일 발송 작업을 등록하는데, 트리거를 발동시킨 트랜잭션이 롤백되면 이메일도 발송되면 안 되는 경우.

DBMS_JOB을 쓰면 트랜잭션이 롤백될 때 등록된 작업도 같이 사라집니다. 반면 DBMS_SCHEDULER는 등록 즉시 커밋되어 별도 트랜잭션이 되므로, 트리거 안에서 호출하면 본 트랜잭션이 롤백되어도 이메일은 발송됩니다.

19c부터 DBMS_SCHEDULER도 CREATE_JOBS(복수형) 프로시저에 commit_semantics => 'TRANSACTIONAL' 옵션이 추가되어 이 동작을 구현할 수 있지만, 단일 작업 등록에는 적용되지 않아 여전히 일부 시나리오에서는 DBMS_JOB의 호환성이 필요한 상황이 남아 있습니다.

조회

SELECT job, what, last_date, next_date, interval, broken
FROM dba_jobs;

DBMS_SCHEDULER - 표준 방식

기본 사용법

BEGIN
    DBMS_SCHEDULER.CREATE_JOB(
        job_name        => 'MY_DAILY_JOB',
        job_type        => 'PLSQL_BLOCK',
        job_action      => 'BEGIN my_procedure; END;',
        start_date      => SYSTIMESTAMP,
        repeat_interval => 'FREQ=DAILY;BYHOUR=2;BYMINUTE=30',  -- 매일 02:30
        enabled         => TRUE,
        comments        => '일일 통계 갱신 작업'
    );
END;
/

COMMIT이 필요 없습니다. CREATE_JOB 자체가 즉시 커밋됩니다.

repeat_interval 표현식 - 캘린더 구문

이게 DBMS_SCHEDULER의 강점입니다. 자연어에 가까운 표현이 가능합니다.

원하는 동작 repeat_interval 표현

매일 02:30	FREQ=DAILY;BYHOUR=2;BYMINUTE=30
매주 월~금 09:00	FREQ=WEEKLY;BYDAY=MON,TUE,WED,THU,FRI;BYHOUR=9
매월 1일 00:00	FREQ=MONTHLY;BYMONTHDAY=1;BYHOUR=0
매월 마지막 평일	FREQ=MONTHLY;BYDAY=-1MON,-1TUE,-1WED,-1THU,-1FRI
5분마다	FREQ=MINUTELY;INTERVAL=5
매년 1월 1일	FREQ=YEARLY;BYMONTH=1;BYMONTHDAY=1

DBMS_JOB의 'TRUNC(SYSDATE+1)+2.5/24' 보다 압도적으로 가독성이 좋습니다.

다양한 작업 유형

-- 1) PL/SQL 블록
job_type => 'PLSQL_BLOCK'

-- 2) 저장 프로시저
job_type => 'STORED_PROCEDURE'
job_action => 'SCHEMA.PACKAGE.PROCEDURE'

-- 3) OS 실행 파일 (★ DBMS_JOB은 불가능했던 영역)
job_type => 'EXECUTABLE'
job_action => '/u01/app/scripts/backup.sh'

-- 4) 외부 작업 (원격 서버)
job_type => 'EXTERNAL_SCRIPT'

OS 스크립트 실행은 운영 자동화의 핵심입니다. 백업, 로그 정리, 외부 시스템 연동 등이 가능해집니다.

조회

-- 작업 목록
SELECT job_name, job_type, repeat_interval, state, enabled
FROM dba_scheduler_jobs
WHERE owner = 'SCOTT';

-- 실행 이력 (실패 사유 포함)
SELECT job_name, status, run_duration, error#, errors,
       actual_start_date
FROM dba_scheduler_job_run_details
WHERE owner = 'SCOTT'
ORDER BY actual_start_date DESC;

실패 시 error#(에러 코드)과 errors(상세 메시지)까지 자동으로 기록됩니다. DBMS_JOB과는 비교할 수 없는 운영 편의성입니다.

★ 19c부터 달라진 동작 (이걸 모르면 헷갈립니다)

대부분의 한국어 블로그가 이 부분을 놓치고 있는데, 운영 DB를 19c로 업그레이드했다면 반드시 알아야 합니다.

무엇이 변했나

19c부터 DBMS_JOB.SUBMIT을 호출해도 내부적으로 DBMS_SCHEDULER 작업으로 생성됩니다. 백워드 호환성을 위해 인터페이스는 살려두되, 실제 실행 엔진은 통합한 것입니다.

확인 방법

19c 환경에서 DBMS_JOB으로 작업을 만들어 보면 양쪽 뷰에 다 보입니다.

-- 1) DBMS_JOB으로 작업 생성
DECLARE v_job NUMBER;
BEGIN
    DBMS_JOB.SUBMIT(v_job, 'BEGIN NULL; END;', SYSDATE, 'SYSDATE+1');
    COMMIT;
END;
/

-- 2) 두 뷰 모두에서 조회됨
SELECT job, what FROM user_jobs;
SELECT job_name, job_action FROM user_scheduler_jobs;

user_scheduler_jobs에서 보면 작업 이름이 DBMS_JOB$_숫자 형태로 자동 생성됩니다.

실무에서 주의할 점

JOB_QUEUE_PROCESSES 파라미터는 둘이 공유합니다. DBMS_JOB과 DBMS_SCHEDULER 작업의 동시 실행 수 합계가 이 값을 넘을 수 없습니다.
DBMS_JOB의 트랜잭션 동작은 유지됩니다. 19c에서도 COMMIT을 안 하면 등록되지 않습니다 (이 부분만큼은 호환성이 살아있음).
업그레이드 시 기존 DBMS_JOB이 자동 변환됩니다. 변환 불가능한 작업이 있으면 JOB_TABLE_INTEGRITY 경고가 뜨므로 업그레이드 전 점검이 필요합니다.

21c 이후는?

21c에서도 DBMS_JOB은 여전히 사용 가능하지만, 언젠가는 완전히 제거(desupport)될 예정입니다. 신규 개발은 무조건 DBMS_SCHEDULER로 가야 하는 이유입니다.

어떤 걸 써야 할까? 실무 가이드

상황별 결정 트리입니다.

신규 작업 개발

무조건 DBMS_SCHEDULER. 예외 없음. 단순한 PL/SQL 호출이라도 DBMS_SCHEDULER로 시작하세요. 나중에 외부 스크립트 호출이 추가되거나 복잡한 스케줄이 필요해질 때 돌아오는 비용이 큽니다.

기존 DBMS_JOB이 운영 중

점진적 마이그레이션 권장. 19c에서 자동 변환되어 동작은 하지만, 다음 시점에 옮기는 게 좋습니다.

해당 작업의 로직을 수정할 일이 생겼을 때
DB 업그레이드 작업과 함께
작업 실패 추적이 필요해질 때

트리거 안에서 비동기 작업 등록

여전히 DBMS_JOB이 유리한 거의 유일한 경우. 트랜잭션과 함께 롤백되어야 하는 작업이면 DBMS_JOB을 유지하거나, DBMS_SCHEDULER의 트랜잭셔널 옵션을 활용하세요.

DBMS_JOB → DBMS_SCHEDULER 마이그레이션 예시

기존 DBMS_JOB 작업이 다음과 같다면:

-- 기존 (DBMS_JOB) - 매일 새벽 2시 30분 실행
DECLARE v_job NUMBER;
BEGIN
    DBMS_JOB.SUBMIT(
        job       => v_job,
        what      => 'BEGIN stats_proc; END;',
        next_date => TRUNC(SYSDATE+1) + 2.5/24,
        interval  => 'TRUNC(SYSDATE+1) + 2.5/24'
    );
    COMMIT;
END;
/

DBMS_SCHEDULER로 옮기면:

-- 새 방식 (DBMS_SCHEDULER)
BEGIN
    DBMS_SCHEDULER.CREATE_JOB(
        job_name        => 'STATS_DAILY_JOB',
        job_type        => 'PLSQL_BLOCK',
        job_action      => 'BEGIN stats_proc; END;',
        start_date      => SYSTIMESTAMP,
        repeat_interval => 'FREQ=DAILY;BYHOUR=2;BYMINUTE=30',
        enabled         => TRUE,
        comments        => '일일 통계 작업 (DBMS_JOB에서 마이그레이션)'
    );
END;
/

마이그레이션 시 체크리스트

기존 작업의 정확한 실행 시각 확인 — dba_jobs.next_date, interval 분석
변환된 repeat_interval 검증 — dbms_scheduler.evaluate_calendar_string으로 다음 실행 시각 미리 확인
테스트 환경에서 먼저 실행 — 운영 환경 직접 변경은 금물
모니터링 추가 — 마이그레이션 후 첫 1주일은 dba_scheduler_job_run_details 매일 확인
기존 DBMS_JOB 제거 — 새 작업이 정상 동작 확인 후 DBMS_JOB.REMOVE(job_id)

자주 발생하는 트러블슈팅

작업이 등록은 됐는데 실행이 안 됨

-- 1) JOB_QUEUE_PROCESSES 확인
SHOW PARAMETER job_queue_processes;
-- 0이면 모든 작업이 중지됨. 권장값: 1000 또는 기본값

작업이 disabled 상태로 등록됨

DBMS_SCHEDULER는 기본값이 enabled => FALSE입니다. 명시적으로 TRUE를 주거나, 생성 후 ENABLE하세요.

DBMS_SCHEDULER.ENABLE('MY_JOB');

RAC 환경에서 특정 인스턴스에서만 실행하고 싶을 때

DBMS_SCHEDULER.SET_ATTRIBUTE(
    name      => 'MY_JOB',
    attribute => 'INSTANCE_ID',
    value     => 1
);

실행 시각이 예상과 다를 때

타임존 문제일 가능성이 높습니다. 19c부터 DBMS_SCHEDULER가 세션 타임존을 사용하는 동작 차이로 인해 업그레이드 후 실행 시각이 변경되는 사례가 보고되었습니다. start_date에 명시적 타임존을 지정하세요.

start_date => TO_TIMESTAMP_TZ('2026-01-01 02:30:00 Asia/Seoul',
                              'YYYY-MM-DD HH24:MI:SS TZR')

마무리

DBMS_JOB과 DBMS_SCHEDULER는 같은 기능을 하는 두 가지 패키지가 아니라, 세대가 다른 도구입니다. 2026년 현재 시점에서 새 작업은 무조건 DBMS_SCHEDULER이며, DBMS_JOB은 호환성을 위한 레거시 인터페이스로만 봐야 합니다.

특히 19c부터 DBMS_JOB이 내부적으로 DBMS_SCHEDULER로 변환되어 동작한다는 사실은 운영 DB 업그레이드 시 반드시 알아야 할 내용입니다. 두 시스템이 자원을 공유하기 때문에 트러블슈팅 시 양쪽 뷰를 모두 확인하는 습관을 들이세요.

기존 DBMS_JOB이 많은 운영 환경이라면 한 번에 옮기지 말고, 작업 단위로 점진적으로 마이그레이션하는 것이 안전합니다.

질문이나 비슷한 마이그레이션 경험이 있다면 댓글로 공유해 주세요.

2026년05월31일 주일예배 (이재훈목사님) - 1부

isony — Sun, 31 May 2026 08:10:55 +0900

2026년05월31일 주일예배 (이재훈목사님) - 1부

주의 말씀 : 나를 따르라 (3)

사슴이 알려준 제자도의 비밀

성경 : 시편(Psalm) 42:1 ~ 11 말씀 (출처:우리말성경)

< 성경 >

42:1 오 하나님이여, 사슴이 목이 말라 헐떡거리며 시냇물을 찾듯이 내 영혼이 목이 말라 주를 찾습니다.

42:2 내 영혼이 하나님을, 살아 계신 하나님을 목말라합니다. 내가 언제 나아가서 하나님을 뵐 수 있겠습니까?

42:3 사람들이 밤낮으로 내게 “네 하나님이 어디 있느냐?” 하니 내 눈물이 밤낮으로 내 음식이 됐습니다.

42:4 지난날들을 생각해 보면 내 영혼을 토해 내지 않을 수 없습니다. 내가 많은 사람들과 함께 그 행렬을 이끌고 하나님의 집으로 가며 명절을 지키러 가는 사람들 사이에서 기뻐 외치며 찬양했습니다.

42:5 오 내 영혼아, 왜 그렇게 풀이 죽어 있느냐? 왜 이렇게 내 속에서 불안해하느냐? 너는 하나님을 바라라. 그 도와주시는 얼굴을 보아라. 내가 오히려 그분을 찬양하리라.

42:6 오 내 하나님이여, 내 영혼이 내 속에서 풀 죽어 있으니 요단 땅 헤르몬 산, 곧 미살 산을 바라보며 내가 주를 기억할 것입니다.

42:7 주의 폭포 소리에 깊은 바다가 깊은 바다를 부르고 주의 파도와 주의 물결이 나를 덮칩니다.

42:8 그러나 낮에는 여호와께서 그 신실함을 보여 주시고 밤에는 주의 노래가 내게 있으니 내 기도가 내 생명 되신 하나님께 닿을 것입니다.

42:9 내 반석이신 하나님께 내가 말할 것입니다. “왜 나를 잊으셨습니까? 내가 왜 적들에게 억눌린 채 슬퍼하며 돌아다녀야 합니까?”

42:10 내 원수들이 나를 조롱하며 날마다 “네 하나님이 어디 있느냐?” 하는 말이 마치 칼이 내 뼈마디를 쑤시는 것 같습니다.

42:11 오 내 영혼아, 왜 이렇게 풀이 죽어 있느냐? 왜 이렇게 내 속에서 불안해하느냐? 너는 하나님을 바라라. 내가 오히려 그분을 찬양하리라. 그분은 내 얼굴을 도와주시는 분이며 내 하나님이십니다.

< 예배 영상 >

https://youtu.be/T2nehx2yVOk

[오라클 에러] ORA-28000 계정이 잠겼습니다 - 잠금 해제부터 재발 방지까지 (실무 DBA 정리)

isony — Sat, 30 May 2026 04:04:41 +0900

[오라클 에러] ORA-28000 계정이 잠겼습니다 - 잠금 해제부터 재발 방지까지 (실무 DBA 정리)

테스트 환경: Oracle 11g / 12c / 19c / 21c

ORA-28000은 운영 DB에서 가장 자주 발생하는 계정 관련 에러입니다. "그냥 풀어주면 끝"이라고 생각하기 쉽지만, 풀어줘도 1분 만에 다시 잠기는 케이스가 운영 환경에선 매우 흔합니다.

이번 글에서는 ORA-28000의 4가지 원인을 분류하고, 잠금 해제뿐 아니라 "왜 잠겼는지" 추적하는 방법, 그리고 재발 방지를 위한 실무 가이드까지 정리했습니다. 특히 자동화 스크립트나 애플리케이션이 잘못된 비밀번호로 계속 시도해서 계정이 매일 잠기는 상황에 대한 진단법은 다른 글에서 잘 다루지 않는 부분입니다.

급하신 분은 빠른 잠금 해제 섹션부터 보세요.

에러 메시지 전문

ORA-28000: the account is locked
ORA-28000: 계정이 잠겼습니다.

SQL*Plus, SQL Developer, JDBC, 애플리케이션 로그 어디에서나 동일하게 발생합니다.

ORA-01017(비밀번호 무효)과 자주 혼동되는데, 둘은 명확히 다릅니다.

ORA-01017: 비밀번호가 틀렸다 (로그인 자체는 시도 가능)
ORA-28000: 계정이 잠겨서 시도조차 안 받는다

비밀번호를 맞게 입력해도 ORA-28000은 발생합니다. 보안상의 이유로 잠긴 상태이기 때문입니다.

빠른 잠금 해제 (1분 안에)

급하면 이 두 줄만 실행하면 됩니다.

-- DBA 권한 계정으로 접속해서
ALTER USER scott ACCOUNT UNLOCK;

비밀번호도 만료된 상태라면:

ALTER USER scott IDENTIFIED BY NewPassword2026 ACCOUNT UNLOCK;

하지만 이게 끝이 아닙니다. 실무에서는 "잠긴 원인"을 찾지 않으면 풀어도 또 잠깁니다. 아래 진단 과정을 반드시 거치세요.

ORA-28000 진단 - 왜 잠겼는지부터 확인

잠금 해제 전에 계정 상태와 잠금 시각부터 확인합니다.

SELECT username, account_status, lock_date, expiry_date, profile
FROM dba_users
WHERE UPPER(username) = UPPER('scott');

account_status 컬럼이 알려주는 정보:

상태 의미 원인

LOCKED	DBA가 수동으로 잠금	관리자 잠금 (원인 2)
LOCKED(TIMED)	로그인 실패 횟수 초과로 자동 잠김	원인 1 (가장 흔함)
EXPIRED & LOCKED	만료 + 잠금 동시	원인 3
EXPIRED(GRACE) & LOCKED	만료 임박 + 잠금	정책 + 시도 실패

lock_date는 언제 잠겼는지 알려주는 핵심 정보입니다. 이 시각을 기준으로 로그를 추적하면 누가/무엇이 잘못된 비밀번호로 시도했는지 알 수 있습니다.

< 원인 1> 로그인 실패 횟수 초과 (FAILED_LOGIN_ATTEMPTS)

가장 흔한 원인입니다. 기본 설정은 보안 정책에 따라 3~10회 범위로 다양합니다.

정책 확인

해당 사용자가 어떤 프로파일에 속해 있는지, 그리고 그 프로파일의 잠금 정책이 어떻게 되어 있는지 확인합니다.

-- 1) 사용자가 속한 프로파일 확인
SELECT username, profile
FROM dba_users
WHERE UPPER(username) = UPPER('scott');

-- 2) 프로파일의 잠금 관련 정책 확인
SELECT resource_name, limit
FROM dba_profiles
WHERE profile = 'DEFAULT'
  AND resource_name IN ('FAILED_LOGIN_ATTEMPTS', 'PASSWORD_LOCK_TIME');

결과 예시:

RESOURCE_NAME            LIMIT
------------------------ --------
FAILED_LOGIN_ATTEMPTS    10
PASSWORD_LOCK_TIME       1

이 의미는 "10번 연속 비밀번호 틀리면, 1일 동안 자동 잠금" 입니다.

PASSWORD_LOCK_TIME에 따른 동작 차이 (★ 실무 함정)

이 두 가지 동작이 미묘하게 다르고, 모르면 진단을 헷갈리게 만듭니다.

PASSWORD_LOCK_TIME = 숫자(예: 1): 시간 경과 후 자동 해제. account_status는 LOCKED(TIMED)로 표시.
PASSWORD_LOCK_TIME = UNLIMITED: DBA가 수동으로 풀 때까지 해제 안 됨. account_status는 LOCKED로 표시.

해결 방법

즉시 해제:

ALTER USER scott ACCOUNT UNLOCK;

해제 후 반드시 해야 할 것: 실패한 IP/호스트 추적

해제만 하면 어디선가 잘못된 비밀번호로 계속 시도하는 주체가 똑같이 또 잠급니다. 누가 시도했는지 먼저 찾으세요.

SELECT username, userhost, terminal, os_username,
       timestamp, returncode
FROM dba_audit_trail
WHERE username = UPPER('scott')
  AND returncode = 1017  -- 로그인 실패 코드
  AND timestamp > SYSDATE - 1
ORDER BY timestamp DESC;

returncode = 1017은 비밀번호 틀림으로 인한 실패를 의미합니다. userhost와 terminal로 어느 서버에서 시도했는지 확인하면, 거기 있는 잘못된 비밀번호의 자동화 스크립트나 애플리케이션을 찾을 수 있습니다.

참고: 12c 이상에서 통합 감사(Unified Auditing)를 쓴다면 unified_audit_trail 뷰를 조회하세요. 컬럼은 약간 다르지만 개념은 동일합니다.

< 원인 2> DBA가 수동으로 잠금

명시적 잠금은 다음 명령으로 발생합니다.

ALTER USER scott ACCOUNT LOCK;

어떨 때 발생하나

퇴사자 계정 비활성화
보안 사고 대응 (의심 계정 차단)
임시 점검 (애플리케이션 점검 중 계정 차단)
신규 DB 설치 시 기본 잠금 상태 (HR, SCOTT, OUTLN, DBSNMP 등)

진단 방법

dba_users.account_status가 LOCKED이고, lock_date가 NULL이 아니면 누군가 수동으로 잠근 것입니다.

신규 DB의 기본 잠금 계정을 확인하려면:

SELECT username, account_status
FROM dba_users
WHERE account_status LIKE 'LOCKED%'
ORDER BY username;

해결 방법

해제 자체는 동일합니다.

ALTER USER scott ACCOUNT UNLOCK;

다만 수동 잠금은 보통 이유가 있어서 잠근 것이므로, 무작정 풀기 전에 잠근 이유를 확인하세요. 보안 사고 대응 중인 계정을 풀면 큰 문제가 될 수 있습니다.

< 원인 3> 비밀번호 만료 후 grace period 종료

비밀번호 정책에 따라 일정 기간(PASSWORD_LIFE_TIME)이 지나면 비밀번호가 만료되고, 유예 기간(PASSWORD_GRACE_TIME) 안에 변경하지 않으면 계정이 잠깁니다.

진단 방법

SELECT username, account_status, expiry_date
FROM dba_users
WHERE UPPER(username) = UPPER('scott');

-- 정책 확인
SELECT resource_name, limit
FROM dba_profiles
WHERE profile = 'DEFAULT'
  AND resource_name IN ('PASSWORD_LIFE_TIME', 'PASSWORD_GRACE_TIME');

account_status가 EXPIRED & LOCKED이면 이 케이스입니다.

해결 방법

-- 새 비밀번호 부여 + 잠금 해제
ALTER USER scott IDENTIFIED BY NewPassword2026 ACCOUNT UNLOCK;

만료된 계정은 비밀번호를 재설정해야 잠금이 풀립니다. 그냥 UNLOCK만 하면 다음 로그인 시 즉시 만료 상태로 돌아갑니다.

< 원인 4> Data Guard Standby 환경의 "보이지 않는 잠금" (★ 고급)

이건 일반 블로그에서 거의 다루지 않는 케이스인데, Active Data Guard 환경에서 운영 중인 분들에게는 필수 지식입니다.

증상

Primary와 Standby 양쪽 모두 dba_users.account_status = 'OPEN'
그런데 Standby에 접속하면 ORA-28000 발생

dba_users만 보면 잠긴 흔적이 없어서 한참 헤매는 케이스입니다.

원인

Active Data Guard는 read-only이기 때문에 표준 DDL로 계정 잠금을 변경할 수 없습니다. 대신 Standby용 메모리 구조에 별도로 잠금 정보가 저장됩니다.

진단 방법 (Standby에서)

SELECT rua.con_id,
       du.username,
       rua.passw_locked,
       rua.passw_lock_unlim,
       TO_CHAR(rua.passw_lock_time, 'YYYY-MM-DD HH24:MI:SS') AS locked_date
FROM v$ro_user_account rua, dba_users du
WHERE rua.userid = du.user_id
  AND (rua.passw_locked = 1 OR rua.passw_lock_unlim = 1);

이 결과에 행이 나오면 Standby에서 별도로 잠긴 것입니다.

해결 방법

12.1.0.2 이상에서는 Active Data Guard 환경에서도 Standby 직접 잠금 해제가 가능합니다. 자세한 구문은 Oracle MOS(My Oracle Support)에서 환경별로 확인하세요. 단순 환경이라면 Primary에서 잠금 해제 후 Redo Apply를 기다리는 방법이 가장 안전합니다.

재발 방지 - 자동화 스크립트가 매일 계정을 잠그는 케이스 (★ 실무 핵심)

운영 환경에서 가장 골치 아픈 시나리오입니다. DBA가 풀어주면 1분 만에 다시 잠기는 상황.

증상

매일 아침 출근하면 특정 계정이 잠겨 있고, HR 시스템이 안 돌아간다는 연락을 받습니다. 풀어주면 잠시 정상이지만, 어느 순간 또 잠깁니다.

원인

어딘가의 자동화 스크립트, 배치 작업, 또는 애플리케이션 설정에 옛날 비밀번호가 남아있어서, 일정 주기로 잘못된 비밀번호로 접속을 시도하고 있는 것입니다. 흔한 시나리오:

비밀번호 변경 후 일부 서버의 설정 파일만 업데이트되고 다른 서버는 빠짐
옛 백업 서버의 cron job이 살아있음
개발자 PC에 저장된 SQL Developer 연결이 옛 비밀번호로 자동 시도
모니터링 도구가 옛 비밀번호 사용

추적 방법

dba_audit_trail에서 최근 24시간 동안 실패한 로그인의 IP/호스트를 모두 추출합니다.

SELECT userhost, terminal, os_username,
       COUNT(*) AS fail_count,
       MIN(timestamp) AS first_attempt,
       MAX(timestamp) AS last_attempt
FROM dba_audit_trail
WHERE username = UPPER('scott')
  AND returncode = 1017
  AND timestamp > SYSDATE - 1
GROUP BY userhost, terminal, os_username
ORDER BY fail_count DESC;

결과의 userhost(시도한 서버)와 os_username(시도한 OS 계정)을 들고 인프라 팀과 협의해서 그 서버의 설정 파일을 잡아내야 합니다.

임시 우회 (긴급할 때만)

서비스 장애가 너무 심해서 시간을 벌어야 한다면, 해당 사용자만 별도 프로파일에 묶어서 잠금 정책을 풀어둘 수 있습니다.

-- 임시 프로파일 생성
CREATE PROFILE TEMP_NO_LOCK LIMIT
    FAILED_LOGIN_ATTEMPTS UNLIMITED
    PASSWORD_LIFE_TIME UNLIMITED;

-- 해당 사용자에게 임시 적용
ALTER USER scott PROFILE TEMP_NO_LOCK;
ALTER USER scott ACCOUNT UNLOCK;

경고: 이건 어디까지나 임시 조치입니다. FAILED_LOGIN_ATTEMPTS = UNLIMITED는 무차별 대입 공격을 무방비로 받게 되는 설정이므로, 원인을 찾자마자 원복해야 합니다.

-- 원인 해결 후 원복
ALTER USER scott PROFILE DEFAULT;
DROP PROFILE TEMP_NO_LOCK;

절대 하지 말아야 할 것

블로그를 검색하면 FAILED_LOGIN_ATTEMPTS를 영구적으로 UNLIMITED로 풀어버리는 가이드가 종종 보이는데, 운영 환경에서는 절대 하지 마세요.

-- ★ 운영 환경에서 절대 사용 금지
ALTER PROFILE DEFAULT LIMIT FAILED_LOGIN_ATTEMPTS UNLIMITED;

이 설정은 모든 사용자에게 적용되며, 무차별 대입 공격(brute-force)을 막는 마지노선을 없애는 것입니다. 보안 감사에서도 즉시 지적되는 항목입니다.

권장 정책 (실무 기준)

FAILED_LOGIN_ATTEMPTS: 5 ~ 10 사이가 일반적
PASSWORD_LOCK_TIME: 1 (1일) — 너무 짧으면 공격에 취약, 너무 길면 운영 부담
자동화 계정은 별도 프로파일로 분리하고, 모니터링 강화

마무리

ORA-28000은 단순 잠금 해제로 끝나는 에러가 아니라, "왜 잠겼는가" 를 추적해야 진짜 해결되는 에러입니다. 풀어도 계속 잠기는 환경이라면 99%는 어딘가의 자동화 스크립트나 옛 설정이 원인이며, dba_audit_trail 추적이 그 답을 알려줍니다.

운영 환경에서는 계정 잠금 이벤트를 모니터링하는 알림 체계를 갖추는 것이 가장 좋은 재발 방지입니다. 잠긴 직후에 알림이 오면 원인 추적이 훨씬 쉬워지기 때문입니다.

비슷한 케이스를 겪으셨거나, Standby 환경에서 까다로운 잠금 이슈가 있다면 댓글로 공유해 주세요. 함께 진단해 보겠습니다.

[오라클 에러] ORA-01017 사용자명/비밀번호 무효 - 6가지 원인과 해결방법 (12c, 19c, 21c 차이까지)

isony — Fri, 29 May 2026 04:04:40 +0900

[오라클 에러] ORA-01017 사용자명/비밀번호 무효 - 6가지 원인과 해결방법 (12c, 19c, 21c 차이까지)

테스트 환경: Oracle 11g / 12c / 19c / 21c

DBA 업무 중 가장 자주 받는 문의가 "비밀번호 분명히 맞는데 ORA-01017이 떠요" 입니다. 단순 오타라면 한 번에 풀리겠지만, 오라클 버전별 인증 방식이 다르고 특수문자 처리 문제까지 겹치면서 의외로 시간을 잡아먹는 에러입니다.

특히 12c 이상에서 비밀번호 대소문자 구분이 강제되고, 21c부터는 케이스 무시 옵션 자체가 제거되면서 예전 매뉴얼대로 처리하다 막히는 경우가 늘었습니다.

이번 글에서는 ORA-01017의 6가지 원인을 분류하고, 버전별 차이점까지 정리했습니다.

에러 메시지 전문

ORA-01017: invalid username/password; logon denied
ORA-01017: 사용자명/비밀번호가 부적합. 로그온할 수 없습니다.

SQL*Plus, JDBC, ODBC, 애플리케이션 로그 어디에서나 동일하게 발생합니다.

참고: 이 에러는 "로그인 실패" 만 알려줄 뿐, "왜 실패했는지" 는 알려주지 않습니다. 보안상 의도된 동작이며, 진짜 원인은 직접 진단해야 합니다.

ORA-01017 빠른 진단 체크리스트

본격적인 해결법 전에, 30초 만에 원인을 좁히는 순서입니다.

사용자명 대소문자, 비밀번호 대소문자 정확히 입력? → 원인 1
dba_users에서 계정 존재하나? → 원인 2
계정 상태가 OPEN인가? (LOCKED는 ORA-28000, EXPIRED는 ORA-28001) → 원인 3
비밀번호에 특수문자(@, $, !, # 등) 포함? → 원인 4
SYS 계정 접속인데 as sysdba 빠뜨림? → 원인 5
최근 DB 업그레이드(11g → 12c+) 했나? → 원인 6 (가장 까다로움)

하나씩 보겠습니다.

< 원인 1> 단순 오타 + 비밀번호 대소문자

가장 흔한 원인이고, 동시에 가장 간과되는 원인입니다.

Oracle 11g부터 비밀번호는 기본적으로 대소문자를 구분합니다. 11g 이전 환경에 익숙한 분들이 자주 놓치는 부분입니다.

-- 둘은 서로 다른 비밀번호로 취급됨
SQL> conn scott/Tiger
SQL> conn scott/tiger

진단 방법

사용자명을 다른 곳에 그대로 타이핑해서 오타 확인
비밀번호를 메모장에 한 번 쳐서 시각적으로 확인 (특히 l(엘) ↔ 1(일), O ↔ 0 혼동)
키보드 한/영 키 상태 확인
CapsLock 상태 확인

해결 방법

비밀번호를 모른다면 DBA 권한으로 재설정합니다.

ALTER USER scott IDENTIFIED BY NewPassword2026;

비밀번호에 영문 대소문자, 숫자, 특수문자를 섞었다면 반드시 입력 시에도 정확히 동일하게 입력해야 합니다.

< 원인 2> 계정 자체가 없음

생각보다 흔한 케이스입니다. 신규 환경 구축, 스키마 이름 오기재, 또는 사용자가 다른 DB 사용자명과 혼동했을 때 발생합니다.

진단 방법

DBA 권한 계정으로 접속해서 확인합니다.

SELECT username, account_status, created
FROM dba_users
WHERE UPPER(username) = UPPER('찾는_사용자명');

행이 0건이면 계정 자체가 없는 것입니다.

해결 방법

계정이 없다면 생성합니다.

CREATE USER scott IDENTIFIED BY Tiger2026;
GRANT CONNECT, RESOURCE TO scott;
GRANT UNLIMITED TABLESPACE TO scott;

실무 팁

운영 환경에서 "있어야 할 계정이 사라진 경우"라면 누군가 DROP USER를 실행했을 가능성이 있습니다. dba_audit_session 또는 통합 감사(unified_audit_trail) 로그를 확인하세요. 작업 이력 추적은 사후 대응에 매우 중요합니다.

< 원인 3> 계정이 잠겼거나 만료됨 (다른 에러와 혼동)

엄밀히 말하면 다음 두 케이스는 별도의 에러 코드가 뜨지만, 일부 클라이언트나 애플리케이션 로그에서 ORA-01017으로 묶여서 표시되는 경우가 있어 같이 다룹니다.

ORA-28000: 계정이 잠겨 있음 (LOCKED)
ORA-28001: 비밀번호 만료 (EXPIRED)

진단 방법

SELECT username, account_status, lock_date, expiry_date
FROM dba_users
WHERE UPPER(username) = UPPER('사용자명');

account_status 컬럼이 가능한 값:

상태 의미

OPEN	정상
LOCKED	수동 잠금
LOCKED(TIMED)	로그인 실패 횟수 초과로 잠김
EXPIRED	비밀번호 만료
EXPIRED(GRACE)	만료 임박 (유예기간)
EXPIRED & LOCKED	둘 다

해결 방법

-- 잠금 해제
ALTER USER scott ACCOUNT UNLOCK;

-- 비밀번호 재설정 + 만료 해제
ALTER USER scott IDENTIFIED BY NewPassword2026;

상세한 잠금/만료 처리는 다음 글에서 따로 다룹니다.

< 원인 4> 비밀번호에 특수문자 포함 (쉘 escape 문제)

비밀번호에 @, $, !, #, & 같은 특수문자가 포함되어 있으면, OS 쉘이 해당 문자를 먼저 해석해버려서 오라클에 잘못된 값이 전달됩니다.

가장 악명 높은 @ 문자

# 비밀번호가 'Tiger@123' 인 경우
sqlplus scott/Tiger@123@ORCL

이건 오라클이 사용자명=scott, 비밀번호=Tiger, DB=123@ORCL로 해석합니다. 당연히 ORA-01017 발생.

해결 방법

1) 큰따옴표로 비밀번호 묶기

sqlplus scott/\"Tiger@123\"@ORCL

Linux/Mac에서는 백슬래시 escape도 같이 써야 합니다.

2) 비밀번호를 분리해서 프롬프트로 입력

sqlplus scott@ORCL
# Enter password: 프롬프트에서 입력

이 방법이 가장 안전합니다. 비밀번호가 셸 히스토리에도 안 남고, 특수문자 escape도 신경 쓸 필요 없습니다.

3) Windows cmd에서는 따옴표 사용

sqlplus scott/"Tiger@123"@ORCL

실무 팁

쉘 스크립트에서 sqlplus를 호출할 때 비밀번호가 특수문자를 포함하면 매번 사고가 납니다. 운영 자동화 스크립트는 비밀번호를 평문 대신 wallet(시큐어 외부 비밀번호 저장소)에 저장하는 것을 강력히 권장합니다. 보안과 안정성을 동시에 잡습니다.

# wallet 사용 시
sqlplus /@ORCL_ALIAS

< 원인 5> SYS 계정 접속 시 as sysdba 누락

SYS 계정은 일반 접속 방식으로는 들어갈 수 없습니다. 반드시 as sysdba 또는 as sysoper 를 명시해야 합니다.

잘못된 접속 (ORA-01017 발생)

sqlplus sys/manager@ORCL

올바른 접속

sqlplus "sys/manager@ORCL as sysdba"

또는

sqlplus / as sysdba

/만 쓰면 OS 인증(운영체제 계정으로 인증)으로 접속합니다. 서버에 직접 oracle 계정으로 들어와 있다면 비밀번호 없이도 SYS로 접속 가능합니다.

실무 팁

SYSTEM 계정도 가끔 ORA-01017이 나는데, 이건 단순히 비밀번호 문제일 가능성이 높습니다. SYS는 인증 방식 차이, SYSTEM은 일반 계정과 동일하게 다루면 됩니다.

< 원인 6> DB 업그레이드 후 발생 (12c+ 인증 모드 변경) ★ 핵심

이 케이스가 ORA-01017 트러블슈팅에서 가장 까다롭습니다. 다른 블로그에서 가장 자주 빠뜨리는 부분이기도 합니다.

무엇이 변했나

Oracle 12c Release 2 (12.2)부터 인증 프로토콜이 "Exclusive Mode"로 기본 설정되었습니다. 이 모드에서는 10G 패스워드 버전(케이스 무시)을 사용할 수 없습니다.

Oracle 21c부터는 SEC_CASE_SENSITIVE_LOGON 파라미터 자체가 제거(desupported) 되었습니다. 즉, 21c에서는 케이스 구분을 끄는 옵션이 아예 없습니다.

어떤 상황에서 문제 되나

11g 또는 그 이전 버전에서 운영하던 DB를 12.2+로 업그레이드한 경우, 다음 조건의 계정은 업그레이드 직후 로그인이 안 됩니다.

비밀번호를 11g 이전부터 한 번도 변경하지 않은 계정
→ password_versions 컬럼이 10G만 가지고 있는 상태

진단 방법

SELECT username, password_versions
FROM dba_users
WHERE UPPER(username) = UPPER('사용자명');

결과 해석:

password_versions 의미

10G	케이스 무시 (12.2+에서 로그인 불가)
10G 11G	11g 이상 호환 가능
10G 11G 12C	최신 (가장 안전)
11G 12C	12c 이후 생성/변경된 계정

10G만 있는 계정이 12.2+ 환경에서 ORA-01017이 뜨는 정확한 원인입니다.

해결 방법

1) 비밀번호 재설정 (권장)

ALTER USER scott IDENTIFIED BY NewPassword2026;

비밀번호를 변경하면 현재 인증 모드에 맞는 password version이 자동 생성됩니다. 이게 가장 깔끔합니다.

2) 임시 우회 (12c~19c에서만 가능, 21c 불가)

sqlnet.ora 파일에 다음 설정 추가:

SQLNET.ALLOWED_LOGON_VERSION_SERVER = 11

리스너 또는 DB 재시작 후 적용됩니다. 단, 이건 임시 조치이며 보안 수준을 낮추는 것입니다. 운영 환경에서는 가능한 빨리 비밀번호 재설정 방식으로 전환하세요.

3) 일괄 점검 쿼리 (★ 운영자 필수)

업그레이드 전에 영향받을 계정을 미리 식별합니다.

-- 10G 버전만 가진 계정 식별
SELECT username, password_versions
FROM dba_users
WHERE password_versions = '10G';

이 결과에 있는 모든 계정은 업그레이드 전에 비밀번호를 한 번씩 변경해 두면 사고를 막을 수 있습니다.

실무 팁

운영 DB 업그레이드 직후 갑자기 여러 애플리케이션에서 ORA-01017이 동시 다발로 발생한다면 99% 이 케이스입니다. 당황하지 말고 위 쿼리부터 돌려보세요.

그래도 안 풀린다면

위 6가지로도 해결되지 않는 드문 케이스:

클라이언트 charset과 서버 charset 불일치로 한글 비밀번호 깨짐: 비밀번호에 한글이 들어있다면 가능한 영문/숫자/특수문자로만 재설정 권장
failed_login_attempts 정책으로 추가 잠금: 비밀번호 틀린 직후 LOCKED로 전환되어 ORA-01017이 잠시 후 ORA-28000으로 바뀜
외부 인증 (OS, LDAP, Kerberos) 환경: dba_users의 authentication_type 컬럼 확인 필요
PDB 접속 시 service_name 누락: 12c+ 멀티테넌트 환경에서 sqlplus user/pw@host:port/PDB명 형식 필요

마무리

ORA-01017은 단순 오타부터 업그레이드 후 인증 모드 변경까지 원인의 폭이 매우 넓은 에러입니다. 한 번에 해결되지 않는다면 위 6가지 원인을 순서대로 짚어보세요. 특히 운영 DB에서 갑자기 발생했다면 최근 변경 이력(업그레이드, 패치, 보안 정책 변경)을 먼저 확인하는 것이 가장 빠른 길입니다.

비밀번호 정책과 password_versions 관리는 평소에 신경 쓰지 않다가 업그레이드 시점에 한꺼번에 터지는 경우가 많습니다. 분기에 한 번씩 dba_users 점검하는 루틴을 권장합니다.

비슷한 케이스를 겪으셨거나, 위 방법으로 해결되지 않은 상황이 있다면 댓글로 공유해 주세요. 함께 진단해 보겠습니다.

[오라클 에러] ORA-12541 TNS 리스너가 없습니다 - 5가지 원인과 해결방법 (실무 DBA 정리)

isony — Thu, 28 May 2026 08:17:34 +0900

[오라클 에러] ORA-12541 TNS 리스너가 없습니다 - 5가지 원인과 해결방법 (실무 DBA 정리)

테스트 환경: Oracle 19c / Windows Server 2019 / Oracle Linux 8

오라클 접속 시 가장 자주 마주치는 에러 중 하나가 바로 ORA-12541입니다. 어제까지 멀쩡히 접속되던 DB에 갑자기 연결이 안 되거나, 신규 클라이언트에서 접속이 안 될 때 이 에러가 뜹니다.

실무에서 운영 DB를 관리하면서 이 에러를 수십 번 마주쳤는데, 원인이 의외로 다양합니다. 단순히 "리스너 재시작"만으로 해결되지 않는 경우도 많아서, 이번 글에서는 5가지 원인을 분류하고 각각의 해결 방법까지 정리했습니다.

급하신 분은 아래 빠른 해결 순서부터 보세요.

에러 메시지 전문

ORA-12541: TNS:리스너가 없습니다
ORA-12541: TNS:no listener

SQL*Plus, SQL Developer, Toad, 그리고 애플리케이션 로그 등 어디에서나 이 메시지가 동일하게 나타납니다. 한글 환경에서는 한글로, 영문 환경에서는 영문으로 표시됩니다.

ORA-12541은 왜 발생할까?

한 줄로 정리하면 "클라이언트가 리스너에 접속을 시도했지만, 해당 위치에 리스너가 응답하지 않는 상태" 입니다.

오라클은 클라이언트와 DB 인스턴스 사이에 리스너(Listener) 라는 중간 프로세스가 통신을 중개합니다. 이 리스너가 죽었거나, 클라이언트가 잘못된 곳을 두드리고 있으면 ORA-12541이 발생합니다.

원인은 크게 5가지로 나눌 수 있습니다.

리스너 서비스 자체가 죽음
listener.log 파일이 4GB를 초과 (Windows 환경에서 자주 발생)
방화벽이 1521 포트를 차단
tnsnames.ora의 HOST 값이 잘못됨
다른 프로세스가 1521 포트를 점유

하나씩 해결 방법을 보겠습니다.

< 원인 1> 리스너 서비스 자체가 죽음 (가장 흔함)

진단 방법

서버에 접속해서 리스너 상태를 확인합니다.

lsnrctl status

리스너가 정상이면 다음과 같이 STATUS of the LISTENER와 함께 등록된 서비스 목록이 출력됩니다.

STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 19.0.0.0.0
Start Date                28-MAY-2026 09:15:23
Uptime                    0 days 5 hr. 12 min. 8 sec

만약 리스너가 죽었다면 아래와 같은 메시지가 나옵니다.

TNS-12541: TNS:리스너가 없습니다
TNS-12560: TNS:프로토콜 어댑터 오류
TNS-00511: 리스너가 없습니다

해결 방법

Linux/Unix 환경

# oracle 계정으로 실행
lsnrctl start

Windows 환경

Win + R → services.msc 입력 → OracleOraDB19Home1TNSListener 같은 이름의 서비스를 찾아 시작을 누릅니다.

또는 관리자 권한 cmd에서:

net start OracleOraDB19Home1TNSListener

서비스 이름은 오라클 버전과 설치 옵션에 따라 다릅니다. Oracle...TNSListener로 시작하는 이름을 찾으세요.

실무 팁

운영 환경에서 리스너가 갑자기 죽었다면 단순히 재시작만 하지 말고 죽은 원인부터 확인하세요. 그냥 살려두면 며칠 뒤 똑같이 죽습니다. 다음 항목인 listener.log 확인이 첫 번째 해야 할 일입니다.

< 원인 2> listener.log 파일이 4GB 초과 (간과하기 쉬운 케이스)

이건 Windows 32bit 환경 또는 일부 파일시스템 제약이 있는 환경에서 발생합니다. listener.log 파일이 4GB를 넘으면 리스너가 로그를 더 쓸 수 없어서 자체적으로 죽거나, 죽은 것처럼 응답하지 않는 상태가 됩니다.

운영한 지 오래된 DB 서버에서 "어느 날 갑자기" ORA-12541이 발생한다면 이걸 가장 먼저 의심하세요.

진단 방법

listener.log 위치는 lsnrctl status의 출력에서 확인할 수 있습니다.

Listener Log File         /app/oracle/diag/tnslsnr/서버명/listener/alert/log.xml

또는 기본 경로:

Linux: $ORACLE_BASE/diag/tnslsnr/{호스트명}/listener/trace/listener.log
Windows: %ORACLE_BASE%\diag\tnslsnr\{호스트명}\listener\trace\listener.log

해당 파일 크기를 확인해서 4GB에 가깝거나 초과했다면 원인이 맞습니다.

해결 방법

1) 리스너 중지

lsnrctl stop

2) listener.log 백업 후 삭제 (또는 이름 변경)

# Linux
mv listener.log listener.log.20260528.bak

# Windows
ren listener.log listener.log.20260528.bak

3) 리스너 재시작

lsnrctl start

재발 방지 (★ 실무 핵심)

이게 한 번 발생했다면 다음에 또 발생합니다. 영구 해결을 위해 로그 로테이션을 자동화해야 합니다.

가장 간단한 방법은 ADRCI(Automatic Diagnostic Repository Command Interpreter)로 보관 정책을 설정하는 것입니다.

adrci
ADRCI> show homes
ADRCI> set home diag/tnslsnr/{호스트명}/listener
ADRCI> set control (SHORTP_POLICY = 168, LONGP_POLICY = 720)

SHORTP_POLICY는 시간 단위(기본 720시간=30일), LONGP_POLICY는 일 단위(기본 8760시간=365일)입니다. 위 예시는 trace를 7일, alert를 30일만 보관합니다.

또는 더 간단하게, listener.ora에 로깅 비활성화 옵션을 줘서 트래픽 로그를 최소화할 수도 있습니다(단, 보안 감사가 필요한 환경에서는 비추천).

LOGGING_LISTENER = OFF

< 원인 3> 방화벽이 1521 포트를 차단

신규로 구축한 서버, 또는 보안 정책 변경 직후에 자주 발생합니다. 리스너는 살아있는데 클라이언트의 패킷이 서버까지 도달하지 못하는 상황입니다.

진단 방법

클라이언트에서 telnet으로 포트 도달 여부 확인

telnet {DB서버 IP} 1521

연결이 즉시 끊기거나 "연결할 수 없습니다"가 나오면 방화벽 문제일 가능성이 큽니다.

서버에서 포트 LISTEN 상태 확인

# Linux
netstat -tlnp | grep 1521
ss -tlnp | grep 1521

# Windows
netstat -ano | findstr 1521

0.0.0.0:1521 또는 *:1521로 LISTEN 상태가 보이면 서버는 정상이고, 방화벽이 막은 겁니다.

해결 방법

Linux (firewalld)

sudo firewall-cmd --permanent --add-port=1521/tcp
sudo firewall-cmd --reload

Linux (iptables)

sudo iptables -A INPUT -p tcp --dport 1521 -j ACCEPT
sudo service iptables save

Windows

Windows Defender 방화벽 → 고급 설정 → 인바운드 규칙 → 새 규칙 → 포트 → TCP / 1521

회사 네트워크 방화벽이 막는 경우라면 인프라 팀에 1521 포트 오픈 요청을 해야 합니다.

< 원인 4> tnsnames.ora의 HOST 값이 잘못됨

클라이언트의 tnsnames.ora 파일에 적힌 HOST가 잘못되어 있으면, 엉뚱한 곳을 두드리니 당연히 ORA-12541이 납니다.

특히 다음 케이스에서 자주 발생합니다.

서버 IP가 변경되었는데 tnsnames.ora를 안 고침
localhost로 설정했지만 다른 PC에서 접속 시도
DNS 환경이라 호스트명이 변경됨

진단 방법

클라이언트 tnsnames.ora 위치:

Windows: %ORACLE_HOME%\network\admin\tnsnames.ora
Linux: $ORACLE_HOME/network/admin/tnsnames.ora

파일을 열어서 접속하려는 TNS 별칭의 HOST 값을 확인합니다.

ORCL =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.10.5)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = ORCL)
    )
  )

해결 방법

1) tnsping으로 별칭 동작 확인

tnsping ORCL

확인(10밀리초) 같은 응답이 나오면 정상. 안 나오면 HOST/PORT를 의심합니다.

2) HOST를 실제 IP로 수정

localhost로 되어 있다면 실제 서버 IP나 호스트명으로 변경합니다.

3) ping으로 IP 도달 여부 추가 확인

ping 192.168.10.5

실무 팁

서버 마이그레이션 직후 클라이언트마다 tnsnames.ora를 일일이 고치는 게 번거롭다면, DNS에 별칭을 만들어 두는 방식을 권장합니다. 이렇게 하면 IP가 바뀌어도 DNS만 갱신하면 끝입니다.

< 원인 5> 다른 프로세스가 1521 포트를 점유

흔하지는 않지만, 1521 포트를 다른 프로세스가 먼저 점유한 경우 리스너가 시작 자체를 못 합니다.

진단 방법

# Linux
sudo lsof -i :1521
sudo netstat -tlnp | grep 1521

# Windows
netstat -ano | findstr 1521
tasklist | findstr {PID}

tnslsnr 또는 TNSLSNR.exe 외의 다른 프로세스가 1521을 잡고 있다면 그게 원인입니다.

해결 방법

가장 흔한 시나리오는 이전에 종료된 리스너의 좀비 프로세스가 남아있는 경우입니다. 해당 PID를 강제 종료합니다.

# Linux
sudo kill -9 {PID}

# Windows (관리자 권한)
taskkill /F /PID {PID}

만약 다른 정상 서비스가 1521을 쓰고 있다면, 오라클 리스너의 포트를 변경하는 것이 안전합니다. listener.ora에서 포트를 1522 등으로 변경하고, 클라이언트의 tnsnames.ora도 같이 변경합니다.

빠른 해결 체크리스트

5분 안에 원인을 좁히는 순서입니다.

서버에서 lsnrctl status 실행 → 리스너 살아있나?
- 죽었으면 → 원인 1 또는 2
클라이언트에서 telnet {IP} 1521 → 포트 도달하나?
- 안 되면 → 원인 3
tnsping {별칭} 실행 → 별칭 해석되나?
- 실패면 → 원인 4
listener.log 파일 크기 → 4GB 근처인가?
- 그렇다면 → 원인 2 (이 케이스는 한 번 터지면 또 터집니다)
netstat으로 1521 점유 프로세스 확인 → tnslsnr 맞나?
- 다른 프로세스면 → 원인 5

그래도 안 풀린다면

위 5가지로도 해결되지 않는 드문 케이스:

Windows 사용자명에 한글/공백 포함: 오라클이 환경변수 해석을 못 하는 경우가 있습니다. 사용자명 변경 또는 별도 계정 생성으로 해결됩니다.
ORACLE_HOME 환경변수가 잘못 설정됨: 여러 오라클 버전을 설치한 환경에서 발생. echo $ORACLE_HOME(Linux) 또는 echo %ORACLE_HOME%(Windows)으로 확인.
호스트명이 IP로 풀리지 않음: /etc/hosts 또는 Windows hosts 파일에 호스트명-IP 매핑 추가.

마무리

ORA-12541은 결국 "리스너에 접속이 안 됨" 이라는 한 가지 증상이지만, 원인은 서버, 네트워크, 클라이언트 설정 어디서나 발생할 수 있습니다. 무작정 리스너 재시작부터 하기보다는, 위 체크리스트 순서대로 진단하시면 5분 안에 원인을 찾을 수 있습니다.

특히 운영 환경에서 갑자기 발생한 경우 원인 2(listener.log 4GB) 를 가장 먼저 확인하세요. 재발률이 가장 높은 케이스입니다.

비슷한 케이스를 겪으셨거나, 위 방법으로도 해결이 안 되는 상황이 있다면 댓글로 공유해 주세요. 함께 해결책을 찾아보겠습니다.

ORA-01017: invalid username/password - 6가지 원인과 해결법 (작성 예정)
ORA-28000: 계정이 잠겼습니다 - 잠금 해제와 재발 방지 (작성 예정)

2026년05월24일 주일예배 (이재훈목사님) - 1부

isony — Sun, 24 May 2026 08:07:44 +0900

2026년05월24일 주일예배 (이재훈목사님) - 1부

주의 말씀 : 나를 따르라 (2)

붙어있음, 그것이 곧 열매이다.

성경 : 요한복음 15:1 ~ 8 말씀 (출처:우리말성경)

< 성경 >

15:1 “나는 참 포도나무요 내 아버지는 농부시다.

15:2 내게 붙어 있으면서도 열매를 맺지 못하는 가지는 아버지께서 다 자르실 것이요, 열매를 맺는 가지는 더 많은 열매를 맺도록 깨끗하게 손질하신다.

15:3 너희는 내가 너희에게 말한 그 말로 인해 이미 깨끗해졌다.

15:4 내 안에 머물러 있으라. 그러면 나도 너희 안에 머물러 있을 것이다. 가지가 포도나무에 붙어 있지 않으면 스스로 열매를 맺지 못하는 것처럼 너희도 내 안에 있지 않으면 열매를 맺을 수 없다.

15:5 나는 포도나무요 너희는 가지다. 그가 내 안에 있고 내가 그 안에 있으면 그 사람은 많은 열매를 맺는다. 나를 떠나서는 너희가 아무것도 할 수 없다.

15:6 누구든지 내 안에 있지 않으면 그 사람은 쓸모없는 가지처럼 버려져 말라 버린다. 사람들이 그런 가지들은 모아다가 불 속에 던져 태워 버린다.

15:7 만일 너희가 내 안에 있고 내 말이 너희 안에 있으면 너희가 원하는 것이 무엇이든지 구하라. 그러면 그대로 이루어질 것이다.

15:8 너희가 열매를 많이 맺으면 내 제자가 되고 이것으로 아버지께서 영광을 받으실 것이다.

< 예배 영상 >

https://www.youtube.com/watch?v=8d-XKf90bos

2026년05월17일 주일예배 (이재훈목사님) - 1부

isony — Sun, 17 May 2026 08:12:25 +0900

2026년05월17일 주일예배 (이재훈목사님) - 1부

주의 말씀 : 나를 따르라 (1) 그리스도를 따를 수 있는 단 하의 근거

성경 : 로마서 6:1 ~ 11 말씀 (출처:우리말성경)

< 성경 >

6:1 그러면 우리가 무슨 말을 해야 하겠습니까? 은혜를 더하게 하려고 죄 가운데 머물러 있어야 하겠습니까?

6:2 결코 그럴 수 없습니다. 죄에 대해 죽은 우리가 어떻게 죄 가운데 그대로 살겠습니까?

6:3 그리스도와 연합해 세례를 받은 우리는 모두 그리스도의 죽으심과 연합해 세례를 받은 줄을 알지 못합니까?

6:4 그러므로 우리는 그리스도의 죽으심과 연합해 세례를 받음으로써 그분과 함께 묻혔습니다. 이는 그리스도께서 아버지의 영광으로 인해 죽은 자들 가운데서 살리심을 받은 것처럼 우리도 또한 새 생명 가운데서 살게 하려는 것입니다.

6:5 우리가 그리스도의 죽으심과 같은 죽음으로 그분과 연합한 사람이 됐다면 분명히 우리는 그리스도의 부활하심과 같은 부활로도 그분과 연합한 사람이 될 것입니다.

6:6 우리의 옛 사람이 십자가에 못 박힌 것은 죄의 몸이 멸해져 우리가 더 이상 죄의 종이 되지 않게 하려는 것임을 압니다.

6:7 이는 죽은 사람은 이미 죄에서 벗어났기 때문입니다.

6:8 우리가 그리스도와 함께 죽었다면 또한 그분과 함께 살 것을 믿습니다.

6:9 우리가 알기로 죽은 사람 가운데서 살리심을 받은 그리스도께서는 다시 죽지 않으시고 죽음이 더 이상 그분을 지배하지 못합니다.

6:10 그리스도께서 죽으신 것은 죄에 대해 단번에 죽으신 것이요, 그분이 사시는 것은 하나님께 대해 사시는 것입니다.

6:11 이와 같이 여러분도 자신을 죄에 대해서는 죽은 자요, 하나님께 대해서는 그리스도 예수 안에서 산 자로 여기십시오.

< 예배 영상 >

https://www.youtube.com/watch?v=McEmBJavR-4

https://youtu.be/McEmBJavR-4

2026년05월10일 주일예배 (이재훈목사님) - 1부

isony — Sun, 10 May 2026 08:07:02 +0900

2026년05월10일 주일예배 (이재훈목사님) - 1부

주의 말씀 : 상한 갈대 위에 드리운 날개

성경 : 롯기 2:1 ~ 13 말씀 (출처:우리말성경)

< 성경 >

2:1 나오미에게는 남편 쪽 친척으로 엘리멜렉 가문 가운데 큰 부자가 하나 있었는데 그 이름은 보아스였습니다.

2:2 모압 여자 룻이 나오미에게 말했습니다. “밭에 갔다 오겠습니다. 누군가 제게 잘 대해 주는 사람을 만나면 그 사람을 따라가 이삭을 주워 오겠습니다.” 그러자 나오미가 그녀에게 말했습니다. “내 딸아, 잘 갔다 오너라.”

2:3 그러자 그녀는 밖으로 나가 추수하는 사람들을 따라 밭에서 이삭을 줍기 시작했습니다. 그런데 우연히도 그녀가 일하고 있던 곳은 엘리멜렉의 친척인 보아스의 밭이었습니다.

2:4 바로 그때 보아스가 베들레헴에서 도착해 추수하는 사람들에게 말했습니다. “여호와께서 너희와 함께하시기를 원한다!” 그들이 대답했습니다. “여호와께서 주인어른께 복 주시기를 빕니다.”

2:5 보아스가 추수하는 사람들의 감독에게 물었습니다. “저 젊은 여자는 누구요?”

2:6 추수하는 사람들의 감독이 대답했습니다. “나오미와 함께 모압에서 나온 그 모압 여자입니다.

2:7 그녀가 추수하는 사람들을 따라가며 이삭을 줍게 해 달라고 말했습니다. 그러더니 밭에 나가 아까 잠깐 집에서 쉰 것 외에는 아침부터 지금까지 저렇게 계속 열심히 일하고 있습니다.”

2:8 그러자 보아스가 룻에게 말했습니다. “내 딸이여, 내 말을 들어 보시오. 다른 밭에 가서 이삭을 줍지 말고 여기서 멀리 가지도 말고 여기 내 여종들과 함께 일하시오.

2:9 사람들이 추수하는 이 밭을 잘 살피며 따라 다니시오. 내가 사람들에게도 당신을 건드리지 말라고 말해 두었소. 그리고 목이 마르면 가서 젊은이들이 채워 놓은 물병에서 물을 따라 마셔도 되오.”

2:10 이 말에 룻은 얼굴을 땅에 대고 엎드려 말했습니다. “내가 이방 사람인데도 어째서 친절을 베풀어 주시고 돌봐 주십니까?”

2:11 보아스가 대답했습니다. “남편이 죽은 후 당신이 시어머니에게 한 일에 대해 모두 들었소. 당신의 부모와 고향을 떠나 알지도 못하는 민족과 함께 살려고 온 것 말이오.

2:12 여호와께서 당신의 행실에 대해 갚아 주실 것이오. 당신이 이스라엘의 하나님 여호와의 날개 아래로 보호받으러 왔으니 그분께서 당신에게 넉넉히 갚아 주실 것이오.”

2:13 룻이 말했습니다. “내 주여, 내가 당신 앞에서 은총을 얻기 원합니다. 내가 당신의 여종들만도 못한데 나를 위로해 주시고 이 여종에게 다정하게 말씀해 주셨습니다.”

< 예배 영상 >

https://youtu.be/6bNickgzuQ0

< 말씀요약 >

하나님은 가정 안에서 때로 불행해 보이는 과정을 통해 아름다운 결말로 섭리하신다.

1. 하나님은 우리가 절망할때 이미 먼저 움직이시고 계신다.

2. 하나님은 절망한 가정에 기대 이상의 넘치는 은혜를 보내신다.

3. 믿음의 눈이 열릴때 하나님의 예비하심이 보인다.

2026년05월03일 주일예배 (이재훈목사님) - 1부

isony — Sun, 3 May 2026 15:39:44 +0900

2026년05월03일 주일예배 (이재훈목사님) - 1부

주의 말씀 : 하나님의 뜻을 행하는 가족

성경 : 마가복음(Mark) 3:31 - 35 말씀 (출처:우리말성경)

< 성경 >

3:31 그때 예수의 어머니와 형제들이 찾아왔습니다. 그들은 밖에 서서 사람을 시켜 예수를 불렀습니다.

3:32 많은 사람들이 예수 곁에 둘러앉아 있었는데 그들이 예수께 말했습니다. “보십시오. 선생님의 어머니와 형제들이 밖에서 선생님을 찾고 계십니다.”

3:33 예수께서 그들에게 물으셨습니다. “누가 내 어머니고 내 형제들이냐?”

3:34 그러고는 곁에 둘러앉은 그들을 보며 말씀하셨습니다. “보라. 내 어머니와 내 형제들이다.

3:35 누구든지 하나님의 뜻을 행하는 사람이 바로 내 형제요, 자매요, 어머니다.”

< 예배 영상 >

https://youtu.be/RFRxYGv9Zmw

2026년04월26일 주일예배 (이재훈목사님) - 1부

isony — Sun, 26 Apr 2026 08:03:48 +0900

2026년04월26일 주일예배 (이재훈목사님) - 1부

주의 말씀 : 버릴것이 없는 인생

성경 : 요한복음(John) 6:11 - 13 말씀 (출처:우리말성경)

< 성경 >

6:11 예수께서는 빵을 들고 감사기도를 드리신 후 앉아 있는 사람들에게 원하는 만큼씩 나눠 주셨습니다. 물고기를 가지고도 똑같이 하셨습니다.

6:12 그들이 모두 배불리 먹은 뒤에 예수께서 제자들에게 말씀하셨습니다. “남은 것은 하나도 버리지 말고 모아 두라.”

6:13 그리하여 그들이 남은 것을 모아 보니 보리빵 다섯 개로 먹고 남은 것이 12바구니에 가득 찼습니다.

< 말씀요약 >

"버리지말라" - "하나도 잃어버려지지 않도록 하라"

1. 하나님은 작은 것도 버리지 않으시는 분이시다.

2. 배부름으로 영적 긴장감이 버려지지 않도록 해야 한다.

3. 하나님께 드려지는 인생만이 버릴 것이 없는 인생이다.

< 예배 영상 >

https://youtu.be/eiRdfzEPDpk

2026년04월19일 주일예배 (이기원목사님) - 1부

isony — Sun, 19 Apr 2026 08:09:07 +0900

2026년04월19일 주일예배 (이기원목사님) - 1부

주의 말씀 : 영적 성숙의 길

성경 : 요한일서(1 John) 2:12 - 17 말씀 (출처:우리말성경)

< 성경 >

2:12 자녀들이여, 내가 여러분에게 쓰는 것은 여러분의 죄가 그리스도의 이름으로 용서됐기 때문입니다.

2:13 아버지들이여, 내가 여러분에게 쓰는 것은 여러분이 태초부터 계시는 분을 알기 때문입니다. 청년들이여, 내가 여러분에게 쓰는 것은 여러분이 악한 자를 이겼기 때문입니다.

2:14 자녀들이여, 내가 여러분에게 쓰는 것은 여러분이 아버지를 알았기 때문입니다. 아버지들이여, 내가 여러분에게 쓰는 것은 여러분이 태초부터 계시는 분을 알았기 때문입니다. 청년들이여, 내가 여러분에게 쓴 것은 여러분이 강하고 하나님의 말씀이 여러분 안에 거하시며 여러분이 그 악한 자를 이겼기 때문입니다.

2:15 여러분은 이 세상이나 세상에 있는 것들을 사랑하지 마십시오. 누구든지 세상을 사랑하면 아버지의 사랑이 그 사람 안에 있지 않습니다.

2:16 이는 세상에 있는 모든 것들, 곧 육신의 탐욕과 안목의 정욕과 세상살이의 자랑은 아버지에게서 온 것이 아니라 세상으로부터 온 것이기 때문입니다.

2:17 세상도 사라지고 세상의 정욕도 사라지지만 하나님의 뜻을 행하는 사람은 영원히 살 것입니다.

< 예배 영상 >

https://youtu.be/JkZx6_RCTd0

2026년04월12일 주일예배 (박종길목사님) - 1부

isony — Sun, 12 Apr 2026 08:09:11 +0900

2026년04월12일 주일예배 (박종길목사님) - 1부

주의 말씀 : 브니엘

성경 : 창세기(Genesis) 32 : 27 - 31 말씀 (출처:우리말성경)

< 성경 >

32:27 그 사람이 물었습니다. “네 이름이 무엇이냐?” 그가 대답했습니다. “야곱입니다.”

32:28 그 사람이 말했습니다. “이제 네 이름은 더 이상 야곱이 아니라 이스라엘이다. 네가 하나님과 겨루고 사람들과 겨루어 이겼기 때문이다.”

32:29 야곱이 말했습니다. “주의 이름을 말씀해 주십시오.” 그가 대답했습니다. “어찌 내 이름을 묻느냐?” 그가 거기에서 야곱을 축복했습니다.

32:30 야곱이 그곳을 브니엘이라 부르고는 말했습니다. “내가 하나님을 대면해서 보았는데도 내 생명이 보존됐구나.”

32:31 야곱이 브니엘을 떠날 때 해가 떴습니다. 그는 엉덩이뼈가 어긋나서 절뚝거렸습니다.

1. 홀로 있게 하신다.

2. 이름을 물으신다.

3. 브니엘의 소망을 주신다.

< 예배 영상 >

https://youtu.be/zaZDG6Dh-cQ

2026년04월05일 주일예배 (이재훈목사님) - 1부

isony — Sun, 5 Apr 2026 08:30:14 +0900

2026년04월05일 주일예배 (이재훈목사님) - 1부

주의 말씀 : 잠긴 문 너머 오신 부활의 주님

성경 : 요한복음(John) 20:19 - 21 말씀 (출처:우리말성경)

< 성경 >

20:19 그날, 곧 그 주간의 첫날 저녁에 제자들은 유대 사람들을 두려워해 문들을 걸어 잠그고 모여 있었습니다. 그때 예수께서 오셔서 그들 가운데 서서 말씀하셨습니다. “너희에게 평강이 있을지어다!”

20:20 이렇게 말씀하신 뒤 예수께서는 제자들에게 자신의 손과 옆구리를 보여 주셨습니다. 그러자 제자들은 주를 보고 기뻐했습니다.

20:21 예수께서 제자들에게 다시 말씀하셨습니다. “너희에게 평강이 있을지어다! 아버지께서 나를 보내신 것처럼 나도 너희를 보낸다.”

< 부활절 칸타타 영상 >

https://youtu.be/q9gLuG5Zs48

< 예배 영상 >

https://youtu.be/ehEeItHmpKw

< 사도신경 >

2026년03월29일 주일예배 (이재훈목사님) - 1부

isony — Sun, 29 Mar 2026 08:12:59 +0900

2026년03월29일 주일예배 (이재훈목사님) - 1부

주의 말씀 : 가룟유다 - 그가 나가니 밤이러라

성경 : 요한복음(John) 13:21 - 30 말씀 (출처:우리말성경)

< 성경 >

13:21 예수께서는 이렇게 말씀하시고 나서 심령으로 몹시 괴로워하며 말씀하셨습니다. “내가 진실로 진실로 너희에게 말한다. 너희 중 하나가 나를 배반할 것이다.”

13:22 제자들은 자기들 중 누구를 말씀하시는지 몰라 당황해 하며 서로 쳐다보았습니다.

13:23 제자들 중 하나인 예수께서 사랑하시는 제자가 예수 곁에 기대어 앉아 있었습니다.

13:24 시몬 베드로가 그 제자에게 손짓하며 누구를 두고 하시는 말씀인지 여쭤 보라고 했습니다.

13:25 그는 예수의 품에 기대어 물었습니다. “주여, 그가 누구입니까?”

13:26 예수께서 대답하셨습니다. “내가 이 빵 한 조각을 적셔서 주는 사람이 바로 그 사람이다.” 그리고 예수께서 빵 한 조각을 적셔서 시몬의 아들 가룟 유다에게 주셨습니다.

13:27 유다가 빵을 받자 사탄이 그에게 들어갔습니다. 예수께서 가룟 유다에게 말씀하셨습니다. “네가 하려는 일을 어서 하여라.”

13:28 그러나 자리를 함께한 사람들 중 아무도 예수께서 그에게 무슨 뜻으로 그런 말씀을 하시는지 아는 사람이 없었습니다.

13:29 어떤 사람들은 유다가 돈을 관리하고 있었기 때문에 예수께서 그에게 명절에 필요한 것을 사 오라거나 가난한 사람들에게 뭔가 나눠 주라고 말씀하신 것으로 생각했습니다.

13:30 유다는 빵 조각을 받은 후 밖으로 나가 버렸습니다. 그때는 밤이었습니다.

< 예배 영상 >

https://youtu.be/0moKNbjOK48

< 말씀 요약 >

첫째, 잘못된 메시아 사상 - 정치적 왕국의 꿈

둘째, 탐욕과 위선의 점진적 지배 - 3년간의 위장 생활

셋째, 자기 보존의 본능 - 사랑이 증오로 뒤바뀌다

넷째, 사탄의 전략적 개입 - 점진적 침투에서 완전한 지배로

다섯째, 회개의 문을 닫은 완고함 - 예수님의 '끝까지의 사랑'을 거부함

배반과 죽음이 예언되어 있다고 해서 유다가 변명할 수 없는 것은

그가 예언을 이루고자 그 일을 한 것이 아니라

스스로의 사악한 마음 때문에 그 일을 했기 때문이다.

- 쟝 칼 뱅 -

[BTS] 아리랑 앨범 Living Legend Ver

isony — Wed, 25 Mar 2026 21:17:22 +0900

[BTS] 아리랑 앨범 Living Legend Ver

'ARIRANG' (Living Legend Ver)

- 정규 5집, '아리랑'으로 방탄소년단이 돌아왔어요.

동글동글한 곰돌이의 일상 : 네이버 블로그

동글동글 굴러가요~ 인스타: @page.teddybear @my.starmoment 유튜브: @starteddybear 사운드클라우드: @star-moment

blog.naver.com

2026년03월22일 주일예배 (이재훈목사님) - 1부

isony — Sun, 22 Mar 2026 08:09:08 +0900

2026년03월22일 주일예배 (이재훈목사님) - 1부

주의 말씀 : 다대오 유다 - 세상을 향한 진정한 사랑

성경 : 마가복음 3:16 - 19, 요한복음 14:21 - 24 말씀 (출처:우리말성경)

< 성경 >

> 마가복음

3:16 예수께서 세우신 12사람들은 베드로라 이름 지어 준 시몬,

3:17 ‘우레의 아들들’이라는 뜻으로 ‘보아너게’라 이름 지어 준 세베대의 아들 야고보와 그 동생 요한,

3:18 안드레, 빌립, 바돌로매, 마태, 도마, 알패오의 아들 야고보, 다대오, 열심당원 시몬과

3:19 예수를 배반한 가룟 유다였습니다.

> 요한복음

14:21 누구든지 내 계명을 가지고 지키는 사람은 나를 사랑하는 사람이다. 나를 사랑하는 사람은 내 아버지의 사랑을 받을 것이고 나 또한 그 사람을 사랑하고 그 사람에게 나를 나타낼 것이다.”

14:22 그러자 가룟 유다가 아닌 다른 유다가 말했습니다. “주여, 주께서 우리에게는 자신을 나타내시고 세상에는 자신을 나타내지 않으시는 까닭이 무엇입니까?”

14:23 예수께서 그에게 대답하셨습니다. “누구든지 나를 사랑하는 사람은 내 말을 지킬 것이다. 그러면 내 아버지께서 그 사람을 사랑하실 것이요, 아버지와 내가 그 사람에게로 가서 그와 함께 살 것이다.

14:24 나를 사랑하지 않는 사람은 내 말을 지키지 아니한다. 너희가 듣고 있는 이 말은 내 말이 아니라 나를 보내신 아버지의 말씀이다.

< 예배 영상 >

https://youtu.be/sLJ6K46M4Mg

BTS (방탄소년단) ‘SWIM’ Official MV

isony — Fri, 20 Mar 2026 17:39:11 +0900

BTS (방탄소년단) ‘SWIM’ Official MV

BTS 5th Album 'ARIRANG'

https://www.youtube.com/watch?v=b4iVv91Z6lY

< arirang album preview >

https://music.apple.com/us/album/arirang/1868481904

ARIRANG by BTS on Apple Music

Album · 2026 · 14 Songs

music.apple.com

2026년03월15일 주일예배 (이재훈목사님) - 1부

isony — Sun, 15 Mar 2026 16:31:47 +0900

2026년03월15일 주일예배 (이재훈목사님) - 1부

주의 말씀 : 시몬 - 칼을 버리고 십자가를 들다

성경 : 누가복음 6:12 - 16, 사도행전1:12 - 14 말씀 (출처:우리말성경)

< 성경 >

> 누가복음 6:12 - 16

6:12 그 무렵 예수께서 기도하시기 위해 산으로 올라가 밤을 새워 하나님께 기도하셨습니다.

6:13 날이 밝자 예수께서는 제자들을 불러 그중 12명을 뽑아 사도로 부르셨습니다.

6:14 예수께서 ‘베드로’라 이름 지으신 시몬과 그 동생 안드레, 그리고 야고보, 요한, 빌립, 바돌로매,

6:15 마태, 도마, 알패오의 아들 야고보, 열심 당원으로 불린 시몬,

6:16 야고보의 아들 유다, 배반자가 된 가룟 유다였습니다.

> 사도행전1:12 - 14

1:12 그 후 그들은 올리브 산이라 불리는 곳에서부터 예루살렘으로 돌아왔는데 이 산은 예루살렘에서 가까워 안식일에 걸어도 되는 거리였습니다.

1:13 그들은 예루살렘 안으로 들어와서 자기들이 묵고 있던 다락방으로 올라갔습니다. 거기 있던 사람들은 베드로, 요한, 야고보, 안드레, 빌립, 도마, 바돌로매, 마태, 알패오의 아들 야고보, 열심당원 시몬 그리고 야고보의 아들 유다였습니다.

1:14 그들은 모두 그곳에 모인 여자들과 예수의 어머니 마리아와 예수의 동생들과 함께 한마음으로 기도에 전념하고 있었습니다.

< 말씀 요약 >

첫째, 이념을 뛰어넘는 복음이다.

둘째, 극단을 뛰어넘는 화해이다.

셋째, 열정을 뛰어넘는 성화(Sanctification)이다.

< 예배 영상 >

https://youtu.be/UDAvsFa5i04

BTS (방탄소년단) '아리랑 (ARIRANG)' Animation Trailer: What is your love song?

isony — Sat, 14 Mar 2026 12:56:36 +0900

BTS (방탄소년단) '아리랑 (ARIRANG)' Animation Trailer: What is your love song?

2026년 03울 21일 토요일 서울 광화문 첫 공연

- 세종대왕, 이순신장군, 아미들이 함께하는 즐거운 첫 공연

- 2026년 3월 21일 (토) 8PM (KST)

[2026 BTS 광화문 컴백 공연 핵심 정보]

일시: 2026.03.21 (토)
장소: 서울 광화문광장 일대
내용: 정규 5집 발매 기념 무료 컴백 공연
예매처: NOL 티켓(인터파크)
참고: 현장 안전을 위해 좌석이 추가되어 2만 2천명 규모로 진행되며, 암표 거래에 대한 주의가 필요합니다.

본 콘텐츠는 1896년 5월 8일자 The Washington Post에 실린 한국 청년 7인의 이야기(“Seven Koreans at Howard")와, 이들 중 일부가 같은 해 7월 24일 미국 워싱턴 D.C.에서 한국 최초의 음원을 녹음한 기록에서 영감을 받아 기획되었습니다. 한국에서 건너간 청년들의 실제 목소리가 담긴 역사적 기록과 최초의 아리랑 녹음이라는 문화적 의미를 모티브로 삼아 현대적 상상력에 기반하여 재구성 및 창작된 것으로, 실제와 다를 수 있으며 역사적 사건이나 인물에 대한 평가·해석과는 무관함을 밝힙니다.

This video was inspired by the story of seven young Koreans as documented in The Washington Post on May 8, 1896 (“Seven Koreans at Howard”), some of whom captured the first known audio recordings of Koreans in Washington, D.C., on July 24 of that same year. As a modern reimagining, this work draws upon the profound cultural significance of these historical records, which preserve the authentic voices of young Korean men and the first-ever recording of “Arirang.” This production may deviate from actual historical events and does not serve as a formal evaluation or interpretation of any historical event or person.

https://www.youtube.com/watch?v=Exukk6JO9i0

https://www.youtube.com/watch?v=4vktN_rO5_s

https://www.youtube.com/watch?v=DRvMhWSZ6KM

https://www.youtube.com/watch?v=psaLVyz6bjQ

2026년03월08일 주일예배 (이재훈목사님) - 1부

isony — Sun, 8 Mar 2026 08:16:18 +0900

2026년03월08일 주일예배 (이재훈목사님) - 1부

주의 말씀 : 작은 야고보 - 이름 없는 헌신

성경 : 마가복음 3:13 - 19, 15:40 - 41 말씀 (출처:우리말성경)

< 성경 >

- 마가복음 3:13 - 19

13. 예수께서 산으로 올라가셔서 원하는 사람들을 불러 모으셨습니다. 그러자 그들이 예수께로 나아왔습니다.
14. 예수께서는 12명을 따로 뽑아 (이들을 사도라 부르시고) 자기와 함께 있게 하셨습니다. 그리고 그들을 내보내셔서 전도도 하게 하시며
15. 그들에게 귀신을 쫓는 권세도 주셨습니다.
16. 예수께서 세우신 12사람들은 베드로라 이름 지어 준 시몬,
17. ‘우레의 아들들’이라는 뜻으로 ‘보아너게’라 이름 지어 준 세베대의 아들 야고보와 그 동생 요한,
18. 안드레, 빌립, 바돌로매, 마태, 도마, 알패오의 아들 야고보, 다대오, 열심당원 시몬과
19. 예수를 배반한 가룟 유다였습니다.

- 마가복음 15:40 - 41

40. 여인들도 멀리서 이 광경을 지켜보고 있었습니다. 그 가운데는 막달라 마리아, 작은 야고보와 요세의 어머니 마리아, 살로메도 있었습니다.
41. 이 여인들은 갈릴리에서 예수를 따르며 섬기던 사람들이었습니다. 그 외에도 예수를 따라 예루살렘에 온 다른 여인들도 많았습니다.

< 예배 영상 >

https://youtu.be/Rd2FsmZu6PU

2026년03월01일 주일예배 (이재훈목사님) - 1부

isony — Sun, 1 Mar 2026 08:08:45 +0900

2026년03월01일 주일예배 (이재훈목사님) - 1부

주의 말씀 : 도마 - 질문하는 신앙

성경 : 요한복음(John) 20:24-29 말씀 (출처:우리말성경)

< 성경 >

20:24 열두 제자 중 하나인 디두모라 불리는 도마는 예수께서 오셨을 때에 제자들과 함께 있지 않았습니다.

20:25 그래서 다른 제자들이 그에게 “우리가 주를 보았소!” 하고 말했으나 도마는 그들에게 “내가 내 눈으로 그분의 손에 있는 못 자국을 보고 내 손가락을 그 못 자국에 넣어 보며 내 손을 그분의 옆구리에 넣어 보지 않는 한 나는 믿을 수 없소” 하고 말했습니다.

20:26 8일 후에 예수의 제자들이 다시 그 집에 모였고 도마도 그들과 함께 거기 있었습니다. 문이 잠겨 있었는데 예수께서 들어와 그들 가운데 서서 말씀하셨습니다. “너희에게 평강이 있을지어다!”

20:27 그러고 나서 예수께서 도마에게 말씀하셨습니다. “네 손가락을 이리 내밀어 내 손을 만져 보고 네 손을 내밀어 내 옆구리에 넣어 보아라. 그리고 믿음 없는 사람이 되지 말고 믿는 사람이 돼라.”

20:28 도마가 예수께 대답했습니다. “내 주시며 내 하나님이십니다.”

20:29 그러자 예수께서 도마에게 말씀하셨습니다. “너는 나를 보았기 때문에 믿느냐? 보지 않고도 믿는 사람은 복이 있다.”

< 예배 영상 >

https://youtu.be/yuaFegt5ui4

< 사도신경 >

2026년02월22일 주일예배 (이재훈목사님) - 1부

isony — Sun, 22 Feb 2026 08:10:57 +0900

2026년02월22일 주일예배 (이재훈목사님) - 1부

주의 말씀 : 마태 - 과거로부터의 자유

성경 : 마태복음 9:9 - 13 말씀 (출처:우리말성경)

< 성경 >

9:9 예수께서 그곳을 떠나 길을 가시다가 마태라는 사람이 세관에 앉아 있는 것을 보셨습니다. 예수께서는 마태에게 “나를 따라라!”고 말씀하셨습니다. 그러자 마태가 일어나 예수를 따랐습니다.

9:10 예수께서 집에서 저녁을 잡수실 때에 많은 세리와 죄인들도 와서 예수와 그 제자들과 함께 음식을 먹었습니다.

9:11 이것을 본 바리새파 사람들이 예수의 제자들에게 물었습니다. “어째서 너희 선생님은 세리들과 죄인들과 함께 어울려 먹느냐?”

9:12 이 말을 듣고 예수께서 말씀하셨습니다. “건강한 사람에게는 의사가 필요하지 않으나 병든 사람에게는 의사가 필요하다.

9:13 너희는 가서 ‘내가 원하는 것은 제사가 아니라 자비다’ 하신 말씀이 무슨 뜻인지 배워라. 나는 의인을 부르러 온 것이 아니라 죄인을 부르러 왔다.”

< 예배 영상 >

동영상 서비스가 종료되어 해당 콘텐츠를 재생할 수 없습니다.

https://youtu.be/1Gg4_G5L15w

BTS (방탄소년단) OFFICIAL LIGHT STICK VER.4 User Guide

isony — Sun, 15 Feb 2026 08:32:14 +0900

BTS (방탄소년단) OFFICIAL LIGHT STICK VER.4 User Guide

새로운 버전 응원봉 사용자 가이드 동영상

https://www.youtube.com/watch?v=Sz6X9Ge9ouU

언박싱(Unboxing)

https://blog.naver.com/roundteddybear

동글동글한 곰돌이의 일상 : 네이버 블로그

동글동글 굴러가요~ 인스타: @page.teddybear @my.starmoment 유튜브: @starteddybear 사운드클라우드: @star-moment

blog.naver.com

2026년02월15일 주일예배 (이재훈목사님) - 1부

isony — Sun, 15 Feb 2026 08:24:35 +0900

2026년02월15일 주일예배 (이재훈목사님) - 1부

주의 말씀 : 나다나엘 : 편견을 깨는 진실함

성경 : 요한복음(John) 1:43 - 51 말씀

< 성경 >

1:43 다음날 예수께서 갈릴리로 떠나시려다 빌립을 만나 말씀하셨습니다. “나를 따라라.”

1:44 빌립도 역시 안드레와 베드로처럼 벳새다 마을 출신이었습니다.

1:45 빌립은 나다나엘을 찾아가 말했습니다. “모세가 율법에 기록했고 예언자들도 기록했던 그분을 우리가 만났소. 그분은 요셉의 아들 나사렛 예수시오!”

1:46 나다나엘이 물었습니다. “나사렛에서 무슨 선한 것이 나오겠는가?” 빌립이 말했습니다. “와서 보시오!”

1:47 예수께서 나다나엘이 다가오는 것을 보시고 그에 관해 말씀하셨습니다. “여기 참 이스라엘 사람이 있다. 이 사람에게는 거짓된 것이 없다.”

1:48 나다나엘이 물었습니다. “어떻게 저를 아십니까?” 예수께서 대답하셨습니다. “빌립이 너를 부르기 전 네가 무화과나무 아래 있을 때에 내가 보았다.”

1:49 그러자 나다나엘이 대답했습니다. “랍비여, 당신은 하나님의 아들이시며 이스라엘의 왕이십니다.”

1:50 예수께서 그에게 말씀하셨습니다. “내가 무화과나무 아래 있던 너를 보았다고 해서 믿느냐? 이제 그보다 더 큰일도 보게 될 것이다.”

1:51 그리고 예수께서 덧붙여 말씀하셨습니다. “내가 진실로 진실로 너희에게 말한다. 너희는 하늘이 열리고 하나님의 천사들이 인자 위에서 오르락내리락하는 것을 보게 될 것이다.”

< 말씀요약 >

첫째, 장차 오실 메시아에 대한 약속들을 주목하며 기대하였다는 뜻이다.

둘재, 이스라엘이라는 이름의 참된 의미를 강조하신 것이다.

셋째, 하나님 앞에서 거짓 없는 진실함을 의미한다.

< 예배 영상 >

동영상 서비스가 종료되어 해당 콘텐츠를 재생할 수 없습니다.

https://youtu.be/fR2w64-YA_U

2026년02월08일 주일예배 (이재훈목사님) - 1부

isony — Sun, 8 Feb 2026 08:06:34 +0900

2026년02월08일 주일예배 (이재훈목사님) - 1부

주의 말씀 : 빌립 - 계산을 뛰어넘는 믿음

성경 : 요한복음(John) 6:5 - 7, 14:8 - 11 말씀

< 성경 >

- 요한복음(John) 6:5 - 7

6:5 예수께서 눈을 들어 많은 사람이 자기에게로 몰려오는 것을 보시고 빌립에게 말씀하셨습니다. “우리가 어디에서 빵을 사서 이 사람들을 먹이겠느냐?”

6:6 예수께서는 빌립이 어떻게 하나 보시려고 이렇게 질문하신 것일 뿐, 사실 자기가 하실 일을 미리 알고 계셨습니다.

6:7 빌립이 예수께 대답했습니다. “한 사람당 조금씩만 먹는다고 해도 200데나리온 어치의 빵으로도 모자랄 것입니다.”

- 요한복음(John) 14:8 - 11

14:8 빌립이 말했습니다. “주여, 우리에게 아버지를 보여 주십시오. 그러면 저희가 더 바랄 것이 없겠습니다.”

14:9 예수께서 대답하셨습니다. “빌립아, 내가 그렇게도 오랫동안 너희와 함께 있었는데도 네가 나를 모르느냐? 누구든지 나를 본 사람은 아버지를 본 것이다. 그런데도 네가 어떻게 ‘우리에게 아버지를 보여 주십시오’라고 말하느냐?

14:10 내가 아버지 안에 있고 아버지가 내 안에 계시다는 것을 믿지 못하느냐? 내가 너희에게 하는 말은 내 말이 아니다. 오직 살아 계시는 아버지께서 내 안에 계시면서 자신의 일을 하시는 것이다.

14:11 내가 아버지 안에 있고 아버지께서 내 안에 계시다는 것을 믿어라. 믿지 못하겠거든 내가 행하는 그 일들을 보아서라도 믿어라.

< 예배 영상 >

동영상 서비스가 종료되어 해당 콘텐츠를 재생할 수 없습니다.

https://youtu.be/AZ9mETitABg

2026년02월01일 주일예배 (이재훈목사님) - 1부

isony — Sun, 1 Feb 2026 08:02:35 +0900

2026년02월01일 주일예배 (이재훈목사님) - 1부

주의 말씀 : 요한 - 사랑의 머무름

성경 : 요한복음(John) 19:25 - 27, 요한계시록(Revelation) 1:9 말씀

< 성경 >

- 요한복음(John) 19:25 - 27

19:25 예수의 십자가 곁에는 예수의 어머니와 이모와 글로바의 아내 마리아와 막달라 마리아가 서 있었습니다.

19:26 예수께서는 자기의 어머니와 그 곁에 사랑하는 제자가 서 있는 것을 보시고 어머니에게 말씀하셨습니다. “어머니, 보십시오. 당신의 아들입니다.”

19:27 그리고 그 제자에게는 “보아라. 네 어머니이다”라고 말씀하셨습니다. 그때부터 그 제자는 예수의 어머니를 자기 집에 모셨습니다.

- 요한계시록(Revelation) 1:9

1:9 여러분의 형제이며 예수 안에서 환난과 나라와 인내를 함께 나누는 사람인 나 요한은 하나님의 말씀과 예수의 증언 때문에 밧모 섬에 있었습니다.

< 예배 영상 >

동영상 서비스가 종료되어 해당 콘텐츠를 재생할 수 없습니다.

< 사도신경 >

2026년01월25일 주일예배 (이재훈목사님) - 1부

isony — Sun, 25 Jan 2026 07:58:42 +0900

2026년01월25일 주일예배 (이재훈목사님) - 1부

주의 말씀 : 야고보 - 세상을 깨우는 우레의 아들

성경 : 누가복음 9:51 - 56, 사도행전 11:1 - 3 말씀

< 성경 >

- 누가복음 9:51 - 56

9:51 예수께서 승천하실 때가 가까이 오자 예루살렘으로 가실 것을 굳게 결심하셨습니다.

9:52 그리고 예수께서는 사람들을 미리 앞서 보내셨습니다. 그들은 가서 예수를 모실 준비를 하려고 사마리아의 한 마을에 들어갔습니다.

9:53 그러나 그곳 사람들은 예수를 반기지 않았습니다. 예수께서 예루살렘으로 가시는 길이었기 때문입니다.

9:54 제자인 야고보와 요한이 이것을 보고 “주여, 우리가 하늘에서 불을 불러 이 사람들을 멸망시켜 달라고 할까요?”라고 물었습니다.

9:55 그러자 예수께서 뒤돌아 그들을 꾸짖으셨습니다.

9:56 그러고 나서 그들은 다른 마을로 갔습니다.

- 사도행전 11:1 - 3

12:1 그 무렵 헤롯 왕이 교회를 박해하려고 교회에 속한 몇몇 사람들을 체포했습니다.

12:2 헤롯은 먼저 요한의 형제 야고보를 칼로 죽였습니다.

12:3 이 일을 유대 사람들이 기뻐하는 것을 본 헤롯은 이어 베드로도 잡아들였습니다. 이때는 무교절 기간이었습니다.

< 예배 영상 >

동영상 서비스가 종료되어 해당 콘텐츠를 재생할 수 없습니다.

2026년01월18일 주일예배 (이재훈목사님) - 1부

isony — Sun, 18 Jan 2026 08:10:46 +0900

2026년01월18일 주일예배 (이재훈목사님) - 1부

주의 말씀 : 아드레 연결하는 제자도

성경 : 요한복음(John) 1 : 35 - 42 말씀

< 성경 >

1:35 다음날 요한은 자기 두 제자와 함께 다시 그 곳에 서 있다가

1:36 예수께서 지나가시는 것을 보고 말했습니다. “보라. 하나님의 어린 양이시다.”

1:37 그 말을 듣고 요한의 두 제자가 예수를 따라갔습니다.

1:38 예수께서 뒤를 돌아 그들이 따라오는 것을 보고 물으셨습니다. “무엇을 원하느냐?” 그들이 말했습니다. “랍비여, 어디에 머물고 계십니까?”(‘랍비’는 ‘선생’이라는 뜻입니다.)

1:39 예수께서 대답하셨습니다. “와서 보라.” 그래서 두 제자는 가서 그분이 계시는 곳을 보고 그날 그분과 함께 지냈습니다. 때는 오후 4시쯤이었습니다.

1:40 요한의 말을 듣고 예수를 따라간 두 사람 중 한 사람은 시몬 베드로의 동생 안드레였습니다.

1:41 안드레는 가장 먼저 자기 형 시몬을 찾아가 말했습니다. “우리가 메시아를 만났다.” (메시아는 ‘그리스도’라는 뜻입니다.)

1:42 그리고 그는 시몬을 예수께 데려왔습니다. 예수께서 시몬을 보고 말씀하셨습니다. “너는 요한의 아들 시몬이구나. 이제 너는 게바라고 불릴 것이다.” (‘게바’는 ‘베드로’라는 뜻입니다.)

< 예배 영상 >

동영상 서비스가 종료되어 해당 콘텐츠를 재생할 수 없습니다.

2026년01월11일 주일예배 (이재훈목사님) - 1부

isony — Sun, 11 Jan 2026 08:06:13 +0900

2026년01월11일 주일예배 (이재훈목사님) - 1부

주의 말씀 : 나를 따르라

성경 : 누가복음 5:1 - 11 말씀

< 성경 >

5:1 예수께서 하나님의 말씀을 들으려는 사람들에게 둘러싸여 게네사렛 호숫가에 서 계셨습니다.

5:2 예수께서 보시니 배 두 척이 호숫가에 대어 있고 어부들은 배에서 내려 그물을 씻고 있었습니다.

5:3 예수께서는 그들 중 시몬의 배에 올라타 그에게 배를 뭍에서 조금 떼어 놓으라고 말씀하셨습니다. 그러곤 배 위에 앉아 사람들을 가르치셨습니다.

5:4 말씀을 마치신 후 예수께서 시몬에게 명령하셨습니다. “물이 깊은 곳으로 나가 그물을 내리고 고기를 잡아라.”

5:5 시몬이 대답했습니다. “선생님, 저희가 밤새도록 애썼지만 아무것도 잡지 못했습니다. 그러나 선생님의 말씀대로 제가 그물을 내려 보겠습니다.”

5:6 어부들이 그 말씀대로 했더니 그물이 찢어질 정도로 많은 고기들이 잡혔습니다.

5:7 그래서 그들은 다른 배에 있는 동료들에게 와서 도와 달라고 손짓했습니다. 그들이 와서 두 배에 고기를 가득 채우자 배가 가라앉을 지경이었습니다.

5:8 시몬 베드로가 이 광경을 보고 예수의 무릎 앞에 엎드려 말했습니다. “주여, 제게서 떠나십시오. 저는 죄인입니다!”

5:9 베드로와 그 모든 동료는 자기들이 잡은 고기를 보고 놀랐던 것입니다.

5:10 세베대의 아들들이며 시몬의 동료인 야고보와 요한도 놀랐습니다. 그때 예수께서 시몬에게 말씀하셨습니다. “두려워하지 마라. 이제부터 너는 사람을 낚을 것이다.”

5:11 그리하여 그들은 자신들의 배를 뭍에 대고 모든 것을 버려둔 채 예수를 따라갔습니다.

< 예배 영상 >

동영상 서비스가 종료되어 해당 콘텐츠를 재생할 수 없습니다.

2026년01월04일 주일예배 (이재훈목사님) - 1부

isony — Sun, 4 Jan 2026 08:02:50 +0900

2026년01월04일 주일예배 (이재훈목사님) - 1부

주의 말씀 : 가서 제자 삼으라

성경 : 마태복음(Matthew) 28:16 - 20 말씀

< 성경 >

28:16 열한 제자들이 갈릴리로 가서 예수께서 일러 주신 산에 이르렀습니다.

28:17 그리고 그들은 예수를 뵙고 경배드렸습니다. 그러나 어떤 사람들은 의심했습니다.

28:18 그때 예수께서 다가오셔서 그들에게 말씀하셨습니다. “하늘과 땅의 모든 권세가 내게 주어졌다.

28:19 그러므로 너희는 가서 모든 민족을 제자로 삼아 아버지와 아들과 성령의 이름으로 세례를 주고

28:20 내가 너희에게 명령한 모든 것을 그들에게 가르쳐 지키게 하라. 보라. 내가 세상 끝 날까지 너희와 항상 함께 있을 것이다.”

< 사도신경 >

< 예배 영상 >

동영상 서비스가 종료되어 해당 콘텐츠를 재생할 수 없습니다.

방탄소년단(BTS) - 2026년 새해

isony — Thu, 1 Jan 2026 08:47:14 +0900

방탄소년단(BTS) - 2026년 새해

- BTS 오랜만에 RM 집에서 함께 모여 2025년 카운트다운과 2026년 새해 인사 입니다.

2026년 신곡도 잘 되길 바라며, 콘서트도 많이 했으면 좋겠습니다.

너무 경쟁이 치열해서 온라인으로만 보고있지만, 콘서트 많이 해주세요.

모두들 건강하고 행복한 한해 되시기 바랍니다.

동영상 서비스가 종료되어 해당 콘텐츠를 재생할 수 없습니다.

BTS - 슈가(SUGA) LIVE 방송

isony — Mon, 29 Dec 2025 09:37:43 +0900

BTS - 슈가(SUGA) LIVE 방송

오랜만에 기쁜 얼굴 BTS 라이브 SUGA 위버스에 올라왔습니다.

방가운 얼굴 슈가 2년 만인가?

방가와요.

동영상 서비스가 종료되어 해당 콘텐츠를 재생할 수 없습니다.

2025년12월28일 주일예배 (이재훈목사님) - 1부

isony — Sun, 28 Dec 2025 07:58:04 +0900

2025년12월28일 주일예배 (이재훈목사님) - 1부

주의 말씀 : 평범한 속의 비범함

성경 : 고린도전서(1Corinthians) 10 : 31 말씀

< 성경 >
10:31 그러나 여러분은 먹든지 마시든지 무엇을 행하든지 모든 것을 하나님의 영광을 위해 하십시오.

< 예배 영상 >

동영상 서비스가 종료되어 해당 콘텐츠를 재생할 수 없습니다.

2025년12월21일 주일예배 (이재훈목사님) - 1부

isony — Sun, 21 Dec 2025 08:16:04 +0900

2025년12월21일 주일예배 (이재훈목사님) - 1부

주의 말씀 : 기뻐하여라, 은혜를 입은 자여

성경 : 누가복음(Luke) 1 : 26 - 38 말씀

< 성경 >

1:26 그 후 여섯 달째에 하나님께서 천사 가브리엘을 갈릴리 나사렛 마을에 보내

1:27 한 처녀에게 가게 하셨는데 그 처녀는 다윗의 가문에 속한 요셉이라는 남자와 약혼한 마리아였습니다.

1:28 천사가 마리아에게 가서 말했습니다. “기뻐하여라. 은혜를 입은 자여, 주께서 너와 함께하신다.”

1:29 천사의 말에 마리아는 당황하며 깜짝 놀라 ‘이게 무슨 인사인가’ 하고 생각했습니다.

1:30 그러자 천사가 말했습니다. “두려워하지 마라. 마리아야, 네가 하나님의 은혜를 받았다.

1:31 보아라. 네가 잉태해 아들을 낳을 것이다. 그러면 그 이름을 예수라 하여라.

1:32 그는 위대한 이가 될 것이요, 지극히 높으신 분의 아들이라 불릴 것이다. 주 하나님께서 그에게 그 조상 다윗의 보좌를 주실 것이다.

1:33 그는 야곱의 집을 영원히 다스릴 것이며 그의 나라는 결코 끝나지 않을 것이다.”

1:34 마리아가 천사에게 물었습니다. “처녀인 제게 어떻게 이런 일이 있겠습니까?”

1:35 천사가 대답했습니다. “성령께서 네게 임하실 것이며 지극히 높으신 분의 능력이 너를 감싸 주실 것이다. 그러므로 태어날 거룩한 아기는 하나님의 아들이라고 불릴 것이다.

1:36 보아라. 네 친척 엘리사벳도 그렇게 많은 나이에 아이를 가졌다. 아이를 갖지 못하는 여자라 불렸는데 임신한 지 벌써 여섯 달째가 됐다.

1:37 하나님께는 불가능한 일이 전혀 없다.”

1:38 그러자 마리아가 대답했습니다. “보십시오. 저는 주의 여종입니다. 당신의 말씀대로 제게 이루어지기를 원합니다.” 그러자 천사가 마리아에게서 떠나갔습니다.

< 쟝 칼뱅, 기독교가용 >

"죽음을 삼키는 것이 그의 사명이었으니,

스스로 생명이신 분이 아니시면

과연 누가 그런 일을 할 수 있었겠는가?

죄를 이기는 것이 그의 사명이었으니,

스스로 의가 되시는 분이 아니시면

과연 누가 그 일을 할 수 있었겠는가?

세상과 공중의 권세들을 무찌르는 것이 그의 사명이었으니,

세상과 공중보다 더 높은 권세이신 분이 아니시면

과연 누가 그 일을 감당할 수 있었겠는가?

그러니 그 생명이나 의, 하늘의 주권과 권세가

하나님 한 분 이외에 그 누구에게 있는가?

그러므로 지극히 자비하신 우리 하나님께서는

우리를 구속하고자 하실 때에

그의 독생하신 아들 안에서

자기 자신을 우리의 구속자로 삼으신 것이다"

< 예배 영상 >

동영상 서비스가 종료되어 해당 콘텐츠를 재생할 수 없습니다.

PayByPhone 캐나다 밴쿠버 길거리 주차하기

isony — Sun, 14 Dec 2025 19:17:53 +0900

PayByPhone 캐나다 밴쿠버 길거리 주차하기

- 한국에서 캐나다 밴쿠버 여행중 자동차 랜트후 길거리 주차에게 대해서 경험담을 적어봅니다.

- 밴쿠버 주차에서 조심해야 할것은 주차표지판을 잘봐서 구역내 주차를 해야 합니다.

(표지판에 상업구역, 지정구역, 일반구역으로 나누어져 있습니다.)

- 도로운전은 국내와 똑같아 운전은 불편합은 없습니다.

(좌회전 표시가 없는곳이 많으니 노란불에 비보호 좌회전 하시면 됩니다.)

- 주차를 직접카드 사용도 가능하지만 주차앱을 사용해 차안애서 편하게 주차가능합니다.

1. 구글 웹스토어에서 PayByPhone 설치

2. 회원가입

3. 차량등록 및 카드등록

1. 구글 웹스토어에서 PayByPhone 설치

- 주차앱은 국내에서는 설치가 불가능합니다.

- 캐나다 현지에서만 설치 가능합니다.

- 저는 현지에서 설치하는데 않되어서 구글계정을 신규가입해서 위치지정방식으로 해서 가능했습니다.

(핸드폰 계정이 한국으로 지역선택이 되어있어 설치가 않되는 경우 구글계정을 신규가입후 통신 위치지정방식으로 지역선택을 하시면 설치가 가능합니다.)

구글앱스토어 : paybyphone 검색후 설치

사이트 : https://www.paybyphone.com/

PayByPhone | Simplifying your journey

Pay for parking with PayByPhone - the smart cashless parking app that'll help you avoid tickets & remind you when it's time to go. Available in more than 1000 cities throughout North America, UK & Europe.

www.paybyphone.com

2. 회원가입

- 회원가입은 개인정보를 입력하고 가입하시면 됩니다.

- Name : 운전자 여권이름과 같이 하는게 좋습니다.

- Email : 본인 연락가능한 Email (저는 핸드폰 구글메일 계정사용했습니다.)

- Phome number : 연락가능한 핸드폰 번호 (나중에 알람문자를 받을때 사용합니다. 국내 82 + 개인핸드폰 번호 입력해도 됩니다.),

- Address : 본인 주소 (한국주소도 상관없습니다. 저는 호텔주소를 등록했습니다.)

3. 차량등록 및 카드등록

- 회원가입후 차량등록과 카드등록이 있습니다.

- 따로 등록하지 않아도 되지만 추차할때마다 새로 등록해야 하므로 미리 등록해서 선택해서 넘어가는것이 좋습니다.

- 실수로 차량 번호가 잘못 되어 주차비를 지급을 했다해서 과징금을 크게 받습니다.

- 차량등록과 카드등록은 여러개를 등록가능합니다.

참고 웹사이트 : https://support.paybyphone.com/hc/en-001/articles/12626079955217-How-do-I-create-a-PayByPhone-Account

4. 현지 차량주차 방법

- 거의 대부분은 일반주차인데 호텔앞이나 고급상점앞은 상가주차구역이므로 함부로 추차하시면 않됩니다.

- 주차 순서 : 빈공간 주차후 주차앱(PayByPhone) 실행 -> 위치등록(기기에 써있는 번호) -> 차량선택 (등록된 차량선택)

-> 주차할 시간(대부분 1시간에 cad$ 4.5 입니다. 여유있게 등록하세요) -> 결재카드 (등록된 카드로 바로 결재)

- 밴쿠버 아쿠아룸 가셔서 주차하실때는 1일 주차로 하시는게 좋습니다. (일일 기준 CAD$12.48)

- 그라우스 마운틴는 1일 주차 CAD$11 입니다.

- 참고 : 퍼블릭주차장에서 주차하실때는 1일 주차기준으로 주차료를 받습니다.

2025년12월14일 주일예배 (이재훈목사님) - 1부

isony — Sun, 14 Dec 2025 08:42:41 +0900

2025년12월14일 주일예배 (이재훈목사님) - 1부

주의 말씀 : 성육신(3) 만물의 으뜸, 교회의 머리

성경 : 골로새서 1 : 15 - 20 말씀

< 성경 >

1:15 하나님의 아들은 보이지 않는 하나님의 형상이요 모든 피조물보다 먼저 나신 분이십니다.

1:16 이는 하늘과 땅에 있는 모든 것들, 곧 보이는 것들과 보이지 않는 것들, 보좌들과 주권들과 권력들과 권세들이 하나님의 아들 안에서 창조됐기 때문입니다. 만물이 아들로 인해 창조됐고 아들을 위해 창조됐습니다.

1:17 하나님의 아들은 만물보다 먼저 계시고 만물은 그분 안에 함께 서 있습니다.

1:18 또 하나님의 아들은 그분의 몸인 교회의 머리십니다. 그분은 근본이시요, 죽은 사람들 가운데서 먼저 살아나신 분이십니다. 이는 그분이 친히 만물 가운데 으뜸이 되시려는 것입니다.

1:19 이것은 아버지께서 모든 충만으로 아들 안에 거하게 하시기를 기뻐하셨고

1:20 그 아들의 십자가의 피로 평화를 이뤄 만물, 곧 땅에 있는 것이든 하늘에 있는 것이든 모든 것이 아들로 인해 자기와 화목하게 되기를 기뻐하셨기 때문입니다.

< 예배 영상 >

동영상 서비스가 종료되어 해당 콘텐츠를 재생할 수 없습니다.

[Episode] 진 (Jin) 'RUNSEOKJIN_EP.TOUR' ENCORE - BTS (방탄소년단)

isony — Fri, 12 Dec 2025 21:02:01 +0900

[Episode] 진 (Jin) 'RUNSEOKJIN_EP.TOUR' ENCORE - BTS (방탄소년단)

https://www.youtube.com/watch?v=0hH9gsprag8

2025년12월07일 주일예배 (이재훈목사님) - 1부

isony — Sun, 7 Dec 2025 07:54:20 +0900

2025년12월07일 주일예배 (이재훈목사님) - 1부

주의 말씀 : 성육신(2) 자신을 비우신 하나님의 겸손

성경 : 빌립보서(Phillippians) 2 : 5 - 11 말씀

< 성경 >

2:5 여러분 안에 이 마음을 품으십시오. 이것은 그리스도 예수 안에 있던 마음이기도 합니다.

2:6 그분은 본래 하나님의 본체셨으나 하나님과 동등됨을 기득권으로 여기지 않으시고

2:7 오히려 자신을 비워 종의 형체를 가져 사람의 모양이 되셨습니다.

2:8 그리고 그분은 자신을 낮춰 죽기까지 순종하셨으니, 곧 십자가에 달려 죽으신 것입니다.

2:9 그러므로 하나님께서는 그를 지극히 높여 모든 이름 위에 뛰어난 이름을 주셨습니다.

2:10 이는 하늘과 땅과 땅 아래 있는 모든 사람들이 예수의 이름 앞에 무릎을 꿇게 하시고

2:11 모든 입으로 예수 그리스도를 주라 시인하게 하셔서 하나님 아버지께 영광을 돌리게 하시려는 것입니다.

< 예배 영상 >

동영상 서비스가 종료되어 해당 콘텐츠를 재생할 수 없습니다.

< 사도신경 >

[VLOG] 밥친구 낋여온 뷔 l V’s VLOG in Los Angeles

isony — Mon, 1 Dec 2025 22:45:46 +0900

[VLOG] 밥친구 낋여온 뷔 l V’s VLOG in Los Angeles

> 고민중인 태형(저녁식사)

> 멋쟁이 태형

> 멋진집에서 영화

https://www.youtube.com/watch?v=sU6NShUE_-E

2025년11월23일 주일예배 (이재훈목사님) - 1부

isony — Sun, 23 Nov 2025 08:05:57 +0900

2025년11월23일 주일예배 (이재훈목사님) - 1부

주의 말씀 : 결단의 오늘

성경 : 여호수아(Joshua) 24: 14 - 28 말씀

< 성경 >

24:14 그러므로 이제 너희는 여호와를 경외하고 성실하고 진실하게 그분을 섬기라. 너희 조상들이 강 건너 저편과 이집트에서 경배하던 신들을 던져 버리고 여호와를 섬기라.

24:15 그러나 만약 너희 마음에 여호와를 섬기는 일이 내키지 않으면 그때는 너희 스스로 누구를 섬길 것인지, 너희 조상들이 강 건너에서 섬겼던 신들이든 지금 너희가 살고 있는 이 땅의 아모리 사람의 신들이든 오늘 선택하라. 나와 내 집은 여호와를 섬길 것이다.”

24:16 그러자 백성들이 대답했습니다. “우리가 여호와를 버리고 다른 신들을 섬긴다는 것은 말도 안 됩니다.

24:17 우리와 우리 조상들을 종살이하던 이집트 땅에서 이끌어 내시고 우리 눈앞에서 그런 놀라운 표적을 보이신 분은 우리 하나님 여호와십니다. 그분이 우리 여정 내내 그리고 우리가 지나온 모든 민족들 가운데서 우리를 지켜 주셨습니다.

24:18 그리고 여호와께서 이 땅에 살던 아모리 사람들을 비롯해 그 모든 민족들을 우리 앞에서 내쫓아 주셨으니 우리도 여호와를 섬기겠습니다. 그분은 우리 하나님이십니다.”

24:19 여호수아가 백성들에게 말했습니다. “너희는 여호와를 섬길 수 없다. 그분은 거룩하신 하나님이시며 질투하는 하나님이시니 너희의 허물이나 죄를 용서하지 않으실 것이다.

24:20 만약 너희가 여호와를 버리고 이방의 신들을 섬기면 그분이 너희에게 잘해 주셨다 할지라도 돌이켜 너희에게 재앙을 내리고 너희를 죽일 것이다.”

24:21 그러자 백성들이 여호수아에게 말했습니다. “아닙니다! 우리는 여호와를 섬기겠습니다.”

24:22 그러자 여호수아가 백성들에게 말했습니다. “너희가 스스로 여호와를 선택하고 그분을 섬기기로 했으므로 스스로 증인이 된 것이다.” 그들이 대답했습니다. “그렇습니다. 우리가 증인입니다.”

24:23 여호수아가 말했습니다. “그렇다면 너희 가운데 있는 이방 신들을 없애 버리고 너희 마음을 이스라엘의 하나님 여호와께로 돌리라.”

24:24 그러자 백성들이 여호수아에게 말했습니다. “우리가 우리 하나님 여호와를 섬기고 그 음성에 순종하겠습니다.”

24:25 그리하여 그날 여호수아는 백성들을 위해 언약을 체결하고 거기 세겜에서 그들을 위해 율례와 법도를 세워 주었습니다.

24:26 그리고 여호수아는 하나님의 율법책에 이 일들을 기록하고 큰 돌을 가져다가 여호와의 성소 근처 상수리나무 아래 세워 놓았습니다.

24:27 그가 모든 백성들에게 말했습니다. “보라. 이 돌이 우리에 대한 증거가 될 것이다. 이 돌이 여호와께서 우리에게 하신 모든 말씀을 들었으니 만약 너희가 너희 하나님을 부인하면 이 돌이 너희에 대해 증언할 것이다.”

24:28 그리고 여호수아는 백성들을 보냈으며 모든 사람들은 자기 유산으로 돌아갔습니다.

< 예배 영상 >

동영상 서비스가 종료되어 해당 콘텐츠를 재생할 수 없습니다.