시행착오와 배움을 기록하는 공간

인터프리터 언어는 변수 선언이 불가능 하다 ?

whoAmI_ — Fri, 2 May 2025 15:50:18 +0900

인터프리터 언어는 변수 선언이 불가능 하다 ?

이 말이 무슨말인가 에 대해서 생각해 보려고 합니다.

인터프리터 언어도 변수 선언이 가능합니다.

단, 명시적인 자료형 선언이 없는 경우가 많고, 변수 선언과 동시에 값을 할당하는 방식 이 일반적 입니다.

이 말이 무슨 말이냐면, 프로그래밍단에서 JavaScript 에서는 변수 선언만 하는 것이 가능해 보입니다.

1. JavaScript에서는 변수 선언만 하는 것이 가능해 보인다.

let x;
console.log(x);  // 출력: undefined

이렇게 선언만 하고 값을 할당하지 않아도 에러는 발생하지 않습니다.

2. 하지만 선언만 하면, 자바스크립트 엔진이 자동으로 undefined 값을 할당한다.

이게 핵심입니다.

JavaScript는 변수 선언 시 자동으로 undefined를 초기값으로 할당합니다.
즉, "변수만 메모리에 올리는 것"이 아니라, "변수 + undefined 값을 같이 할당"하는 것입니다.

let x;  // 실제로는 let x = undefined; 와 비슷하게 동작

이는 호이스팅(hoisting) 개념과도 연결됩니다.

console.log(a); // undefined
var a = 10;

var a;가 코드 실행 전에 메모리에 올라가고, 값은 undefined로 세팅 됩니다.

3. 왜 이렇게 하냐?

JavaScript는 인터프리터 언어로서, 동적 타이핑 및 느슨한 초기화 규칙을 가지고 있기 때문에,
초기화되지 않은 변수에 접근했을 때 치명적 오류를 피하고자 undefined를 기본값으로 할당합니다.
이는 런타임 오류를 줄이려는 목적도 있습니다.

인터프리터 언어인 파이썬도 이와 비슷한 이유로 값을 강제하는 모습을 보이고 있습니다.

파이썬은 변수에 값을 할당하지 않으면 변수로 보지 않는다?

맞습니다.

Python은 변수를 사용하려면 반드시 값을 할당해야 합니다.
x = 10 # Python: 변수 선언 + 값 할당
그렇지 않으면 존재하지 않는 변수로 간주해서 오류가 발생합니다.
변수는 할당되기 전까지 존재하지 않으며, 참조하면 NameError가 발생합니다.
print(x) # NameError: name 'x' is not defined

그래서 파이썬 에서 변수에 아무 값도 없음을 표현하고 싶을 때는 None을 사용합니다.

x = None

None 이란?

Python에는 null이라는 키워드가 없습니다. 대신 None을 사용합니다.
None은 Python의 객체이며, 이는 null과 비슷한 역할이지만 다릅니다.

None은 객체이고, null은 아무것도 없는 것이다 ?

None (Python): NoneType 클래스의 객체입니다. 이는 "값이 없다"를 표현할 명시적인 객체입니다.
null (Java, JavaScript 등): 객체를 참조하지 않는 상태를 나타냅니다. 일반적으로 "값 없음" 또는 "초기화되지 않은 참조"를 의미합니다.
- Java: null은 참조 타입의 기본값
- JavaScript: null은 의도적으로 "값 없음"을 표현하는 값
- Python: None은 같은 목적이지만 엄연한 객체

이렇게 하는 이유는 무엇일까?

“인터프리터는 바로 실행해야하는데, 변수만 선언하면 안되겠지 ! ”

인터프리터 언어의 핵심은 "실행과 해석이 동시에" 이루어진다는 것인데,

그런 상황에서 변수만 '껍데기'로 만들어 놓고 값도 없으면, "이거 뭐 하자는 거지?" 하고 애매해집니다.

그래서 자바스크립트는 "일단 undefined라도 넣어줄게~" 하면서 실행 가능한 상태로 만들어주는 것입니다.

즉, 변수만 덩그러니 선언해 놓는 건 인터프리터 입장에서 불안정하고,
그래서 자바스크립트는 항상 undefined라는 기본값으로 '완성된 상태' 를 보장하려는 것입니다.

이런 점이 컴파일 언어랑 동작 철학이 다른 부분이라 재미있습니다.

SQL JOIN 시 드라이빙 테이블을 좌변에 두는 것이 좋을까

whoAmI_ — Thu, 20 Feb 2025 12:19:52 +0900

정말 기본적인 생각임에도 불구하고, 처음부터 다시 생각해보는 의미로 작성하게 되었다.

SQL에서 JOIN을 사용할 때 ON 조건을 작성하는 방식은 개발자마다 다를 수 있다. 하지만 드라이빙 테이블(Driving Table)을 JOIN 조건의 좌변에 두는 것이 더 좋은지에 대한 고민은 필요하다.

이번 글에서는 드라이빙 테이블의 개념과 JOIN 조건에서 좌변과 우변의 차이를 살펴보고, 어떤 방식이 가독성과 유지보수에 유리한지 정리해 보았다.

1. 드라이빙 테이블이란?

JOIN이 실행될 때, SQL 옵티마이저는 어떤 테이블을 기준으로 다른 테이블과 매칭할지 결정한다. 이때 먼저 처리되는 테이블을 드라이빙 테이블(Driving Table) 이라고 한다.

예제를 살펴보겠다.

SELECT o.order_id, o.order_date, c.customer_name, c.email
  FROM orders o
  JOIN customers c
    ON o.customer_id = c.customer_id
 ORDER BY o.order_date DESC;

위 SQL에서 orders 테이블이 드라이빙 테이블이다. 즉, orders 테이블에서 데이터를 먼저 읽고, 이후 customers 테이블과 매칭하는 방식으로 동작한다.

customers 테이블과 매칭하는 방식으로 동작한다.

2. JOIN 시 좌변과 우변의 차이

아래 두 가지 방식의 JOIN을 비교해 보겠다.

방식 1: 드라이빙 테이블을 우변에 둠

ON c.customer_id = o.customer_id

c.customer_id가 좌변, o.customer_id가 우변이다.
옵티마이저가 내부적으로 실행 순서를 정하지만, 가독성이 떨어질 수 있다.

방식 2: 드라이빙 테이블을 좌변에 둠

ON o.customer_id = c.customer_id

o.customer_id가 좌변, c.customer_id가 우변이다.
드라이빙 테이블이 기준이 되어 직관적이고 가독성이 좋다.

SQL 옵티마이저가 실행 순서를 자동으로 최적화하기 때문에 성능 차이는 크지 않다. 하지만 개발자가 코드를 읽을 때 이해하기 쉬운 방식으로 작성하는 것이 중요하다.

3. 드라이빙 테이블을 좌변에 두는 것이 좋은 이유

✅ 가독성 향상

JOIN을 읽을 때 흐름이 직관적이다.
데이터를 먼저 읽는 테이블을 좌변에 두면 이해하기 쉽다.

✅ SQL 스타일 가이드 권장

많은 스타일 가이드에서 기준이 되는 테이블을 좌변에 배치하는 것을 권장한다.
유지보수 시 가독성이 좋아지고 협업이 쉬워진다.

✅ 실행 계획(EXPLAIN) 확인 필요

SQL 옵티마이저가 실행 순서를 최적화하므로, 실제 실행 방식은 EXPLAIN으로 확인해야 한다.
필요하면 인덱스를 추가하여 최적화할 수 있다.

마무리

결론적으로, 드라이빙 테이블을 JOIN 조건의 좌변에 배치하는 것이 가독성과 유지보수성 측면에서 유리하다.

핵심 정리

드라이빙 테이블은 먼저 처리되는 테이블이다.
JOIN 시 드라이빙 테이블을 좌변에 두면 코드 가독성이 좋아진다.
SQL 옵티마이저가 실행 순서를 최적화하지만, 가독성을 고려해 좌변 배치를 권장한다.
EXPLAIN을 활용하여 실행 계획을 확인하는 것이 중요하다.

SQL을 작성할 때 단순히 실행만 고려할 것이 아니라, 협업과 유지보수를 위해 더 읽기 좋은 SQL을 작성하는 방법도 고민해야 한다.

데이터베이스 멀티프로세싱과 멀티스레딩 : 오라클과 MySQL 비교

whoAmI_ — Wed, 19 Feb 2025 12:31:49 +0900

데이터베이스를 공부하면서 데이터베이스와 인스턴스, 그리고 하드웨어 코어위에 어떻게 올라가서 돌아가는지 궁금해져서 찾아보게 되었다.

물리적 하드웨어 코어, 하이퍼스레딩, 멀티스레딩, 멀티프로세싱이냐 멀티스레딩이냐 에 대한 개념들도 나오게 되었고, 오라클(Oracle)과 MySQL이 각각 어떤 방식을 쓰는지, 그리고 그게 실제 성능에 어떤 영향을 주는지 알아려고 한다.
→ DBMS는 기본적으로 여러 코어를 활용하며, 코어 수에 따라 성능이 좌우된다.

근데 잠깐, 멀티프로세싱이랑 멀티스레딩이 뭐야?

1. 멀티프로세싱 vs 멀티스레딩, 뭐가 다른데?

1) 멀티프로세싱 (Multi-processing)

쉽게 말해서 여러 개의 독립된 프로세스를 만들어서 동시에 작업하는 방식
프로세스끼리는 메모리를 따로 갖고 있어서 안전하지만, 서로 데이터를 주고받으려면 **IPC(Inter-Process Communication, 프로세스 간 통신)**이 필요해서 오버헤드가 있음
여러 개의 CPU 코어를 활용할 수 있어서 병렬 처리에 유리함

질문: "그럼 멀티코어를 써야 멀티프로세싱이 가능하다는 거야?"

그렇다. 단일 코어에서는 멀티프로세싱을 하더라도 사실상 CPU가 빠르게 왔다 갔다(Switching) 하는 거지, 진짜 병렬이 아니다. 멀티코어가 있어야 각 프로세스가 진짜로 동시에 실행될 수 있음.

잠깐! CPU 코어(Core)와 스레드(Thread)의 관계에 대해서도 잠깐 짚고가자

CPU는 여러 개의 코어(Core)로 구성됨
각 코어는 동시에 하나 이상의 스레드를 실행할 수 있음
하이퍼스레딩(Hyper-Threading, HT) 기술이 적용된 경우, 1코어당 2개의 스레드를 실행할 수 있음

2) 멀티스레딩 (Multi-threading)

하나의 프로세스 안에서 여러 개의 스레드를 만들어서 동시에 작업하는 방식
스레드끼리는 메모리를 공유하니까 데이터 전달이 빠름
하지만 한 스레드가 문제 생기면 다른 스레드에도 영향을 줄 수 있음 (안정성이 낮음)

질문: "그럼 멀티스레딩은 멀티코어 없어도 가능해?"

단일 코어에서는 CPU가 스레드를 번갈아가면서 실행하는 것이기 때문에 실제 병렬은 아니고, 논리적인 동시 실행이다.

멀티코어가 있으면 진짜 동시에 병렬로 실행되면서 성능이 올라갈 것이다.

2. 오라클과 MySQL의 멀티프로세싱 & 멀티스레딩 차이점 ?

1) 오라클(Oracle)은 멀티프로세싱 기반

인스턴스 하나가 멀티프로세스로 실행되며, 각 프로세스 내부에서 멀티스레딩으로 동작

✅ 멀티프로세싱(Multi-Processing)

오라클 인스턴스는 여러 개의 **백그라운드 프로세스(예: DB Writer, Log Writer, Checkpoint, Shared Server 등)**로 구성됨.
즉, 하나의 인스턴스가 여러 개의 프로세스로 실행되므로 멀티프로세싱 환경임.
여러 개의 프로세스는 여러 개의 CPU 코어에 분산되어 실행됨.

✅ 멀티스레딩(Multi-Threading)

각 프로세스 내부에서 여러 개의 스레드를 실행할 수 있음.
즉, 각 프로세스가 멀티스레딩을 지원하여 내부적으로 병렬 처리를 수행함.

오라클의 코어 활용 방식

멀티프로세싱이기 때문에 각 프로세스는 여러 개의 CPU 코어에 할당됨
각 프로세스 내부에서 다시 멀티스레딩을 사용하여 병렬 작업을 수행
즉, 멀티프로세싱 + 멀티스레딩이 동시에 이루어지는 구조
- 예시:
  - DB Writer 프로세스(1코어 할당) → 내부적으로 4개 스레드 실행
  - Log Writer 프로세스(1코어 할당) → 내부적으로 2개 스레드 실행
  - Shared Server 프로세스(2코어 할당) → 내부적으로 다수의 세션 처리

오라클의 동작 방식

클라이언트가 쿼리를 보내면, 오라클이 별도의 서버 프로세스(Server Process)를 생성해서 처리
그리고 이 서버 프로세스들은 각각 독립적으로 실행되니까 안정적임
백그라운드 프로세스도 따로 있어서 캐시 관리, 로그 저장, 복구 작업 같은 걸 별도로 수행
CPU 코어가 많을수록 프로세스를 잘 분산할 수 있어서 성능이 올라감

✅ 오라클의 장점 & 단점

✅ 장점:

프로세스 간 격리가 돼서 안정성이 높음
대규모 트랜잭션 처리(OLTP)에 최적화됨
CPU 코어를 병렬로 활용 가능

❌ 단점:

프로세스 간 통신(IPC) 때문에 오버헤드 발생
프로세스를 여러 개 띄우니까 메모리 사용량 증가

2) MySQL은 멀티스레딩 기반

반면 MySQL은 멀티스레딩을 기본 구조로 가져간다.

인스턴스 하나가 하나의 프로세스로 실행되지만, 내부적으로 여러 개의 스레드를 생성하여 여러 코어를 활용

MySQL의 동작 방식

클라이언트가 쿼리를 보내면, MySQL은 하나의 프로세스 안에서 새로운 스레드를 만들어 처리
오라클처럼 프로세스를 여러 개 만드는 게 아니라, 하나의 프로세스에서 여러 개의 스레드를 생성하는 구조
스레드끼리 메모리를 공유하니까 데이터 처리 속도가 빠름
하지만 하나의 스레드가 장애가 나면 다른 스레드에도 영향을 줄 수 있음

질문: "그럼 MySQL은 멀티코어를 못 쓰는 거야?"

아니지! MySQL도 멀티코어를 활용하는데, 각 스레드가 여러 코어에 분산돼서 실행되는 방식이야.

즉, 멀티코어 환경에서는 MySQL도 병렬 처리가 가능함!

✅ MySQL의 장점 & 단점

✅ 장점:

하나의 프로세스에서 동작하므로 프로세스 간 통신(IPC) 오버헤드가 없음
스레드 간 공유 메모리를 활용하여 빠른 데이터 처리 가능
경량화된 구조로 인해 비교적 적은 리소스로도 실행 가능

❌ 단점:

스레드 간 충돌 문제 발생 가능
하나의 프로세스에서 모든 작업을 하다 보니, 안정성이 상대적으로 낮음
대규모 시스템에서는 멀티프로세싱 기반인 오라클보다 성능이 떨어질 수 있음

3. 오라클과 MySQL의 멀티코어 활용 방식

오라클과 MySQL 모두 단일 코어에서 실행되지 않고, 여러 개의 코어를 활용한다.

1) 오라클의 멀티코어 활용

인스턴스 하나에 여러 개의 서버 프로세스와 백그라운드 프로세스가 분산 실행됨
각 프로세스는 여러 개의 CPU 코어를 활용하여 멀티프로세싱을 수행
내부적으로도 멀티스레딩을 지원하지만, 주된 방식은 멀티프로세싱

2) MySQL의 멀티코어 활용

인스턴스 하나가 하나의 프로세스로 실행되지만, 내부적으로 여러 개의 스레드가 다양한 코어에서 실행됨
멀티스레딩 기반으로 멀티코어를 활용하여 성능을 최적화
CPU 코어가 많을수록 성능 향상이 가능하지만, 스레드 동기화 문제 발생 가능

4. 결론: 오라클 vs MySQL, 언제 무엇을 사용할까?

✔ 오라클이 더 적합한 경우

대규모 시스템, 트랜잭션이 많은 서비스
안정성이 중요한 금융, 엔터프라이즈 환경
멀티코어를 적극 활용해서 확장성을 높여야 하는 경우

✔ MySQL이 더 적합한 경우

웹 서비스, 스타트업, 가벼운 애플리케이션
적은 리소스로 빠르게 데이터 처리를 해야 하는 경우
OLTP보다는 OLAP(분석/조회)에 더 초점이 맞춰진 경우 → OLTP에서는 오라클보다 안정성이 좀 떨어진다는 느낌 → 가벼운 쿼리 중심의 데이터조회(OLAP)에 유리한 면이 있음

결국 오라클은 멀티프로세싱 기반이라 안정적이고 대규모 트랜잭션에 강하고, MySQL은 멀티스레딩 기반이라 가볍고 빠르게 처리할 수 있음

→ 대규모 트랜잭션이면 오라클, 가볍고 빠른 웹 서비스면 MySQL

어떤 DB를 선택할지는 서비스 특성과 운영 환경에 따라 달라지게 된다는 것!

마무리

데이터베이스를 공부하면서 단순히 쿼리를 잘 작성하는 것만이 아니라, DBMS가 하드웨어에서 어떻게 동작하는지 궁금해졌다. 그러다 보니 자연스럽게 멀티프로세싱 vs 멀티스레딩, 그리고 오라클과 MySQL의 차이점까지 알아보게 되었다.

오라클은 멀티프로세싱 기반으로 여러 개의 프로세스를 독립적으로 실행하며, MySQL은 멀티스레딩 기반으로 하나의 프로세스 내에서 여러 스레드가 공유된 자원을 활용하는 방식이다. 이때 CPU의 멀티코어 및 하이퍼스레딩(HT) 기술이 중요한 역할을 한다. 멀티코어는 여러 개의 코어를 활용해 다수의 프로세스를 병렬로 실행할 수 있게 해주며, 하이퍼스레딩은 하나의 코어가 두 개의 논리적 스레드를 실행하도록 최적화된다. 이런 구조 덕분에 오라클은 여러 프로세스를 코어 단위로 분산 처리하는 데 유리하고, MySQL은 하나의 프로세스에서 여러 스레드를 실행하는 데 최적화되어 있다.

결국, 어떤 DBMS를 선택하느냐는 시스템의 특성과 요구 사항에 따라 달라진다. 이제 단순히 “어떤 DB가 더 빠를까?”가 아니라, “내가 설계하는 시스템에 적합한 DB는 무엇일까?”라는 질문을 던져볼 수 있을 것이다.

앞으로도 DB 성능 최적화와 구조적인 이해를 계속해서 쌓아가며, 더 나은 데이터 처리 방식을 고민해봐야겠다.

[분석, 설계] 객체 모델링, 유스케이스 다이어그램, 액터

whoAmI_ — Fri, 14 Jun 2024 02:45:21 +0900

객체 모델링은 요구사항관리인 유스케이스 다이어그램부터 클래스 다이어그램까지 작성하는 것이다.

유스케이스 다이어그램

유스케이스 다이어그램은 먼저 개발하고자 하는 시스템의 대표 기능을 검색해서 작성한다.
모든 기능을 다 유스케이스로 뽑아내지 않아야 한다.
유스케이스의 범위는 하나의 기능이며 이는 서브 시스템 정도이다.

클래스 다이어그램

클래스 다이어그램에서 클래스는 유스 케이스 기반으로 식별한다.
클래스는 객체들의 분류한 기준이다.
클래스는 기능을 기반으로 추출해야 한다.

유스케이스 다이어그램 작성 방법

유스케이스는 개발할 시스템을 기준으로 시스템 밖의 액터를 기준으로 시스템 내부의 서브 시스템의 기능인 유스케이스를 찾아서 정리한다.

시스템 (Systems)

개발하고자 하는 것 그 자체이며, 웹사이트가 될 수도 있고, 소프트웨어 컴포넌트, 애플리케이션 등 다양한 시스템이 될 수 있습니다.

시스템의 범위를 정의하며 흐름이 일어나는 영역의 경계를 정의합니다.

좀 더 쉽게 설명하자면 사각형 범위 안에 있는 흐름은 시스템 안에서만 일어나고, 범위 밖에 있는 흐름은 시스템 안에서 일어나지 않습니다.

사각형의 형태로 표시하고, 상단에 시스템의 이름을 정의합니다.

예시에선 검은색 사각형이 시스템에 해당하는 영역입니다.

액터 (Actors)

시스템 외부에서 시스템과 상호작용하여 특정한 목적을 취하는 객체를 뜻합니다.

액터는 사람이 될 수도 있고, 회사, 다른 시스템, 또는 외부 장비가 될 수도 있습니다.

액터는 반드시 하나 이상의 유스케이스들과 상호작용해야 합니다.

또한 액터 이름은 개인적이거나 무언가를 특정해서 지정하면 안 됩니다.

액터에는 두 가지 종류가 있습니다.

프라이머리 액터 (Primary Actor) : 시스템을 사용하고, 직접 이득을 보는 액터이며 졸라맨으로 표기합니다. 보통 시스템의 왼쪽에 표시합니다.
세컨더리 액터 (Secondary Actor) : 프라이머리 액터가 목적을 달성하기 위해 도움을 주는 액터이며 사각형 박스에 <<actor>>를 입력하여 표기합니다. 보통 시스템의 오른쪽에 표시합니다.

유스케이스 (Use Cases)

시스템 내에서 일련의 작업을 수행하기 위한 행위들을 나타내며, 타원형으로 표기합니다.

관계 (Relationships)

선 또는 화살표로 나타내며, 이어진 2개의 액터 또는 유스케이스들이 서로 상호작용함을 나타냅니다.

유스케이스 명세서 작성 방법

유스케이스 명세 작성 요령

l 대상 시스템이 제공하여야 할 서비스를 시간이 경과되는 순서로 정렬하여 기술 한 것.

l SW에 대한 요구정의를 사용자 관점으로 바꾸어 상호작용 사건의 시나리오로 나타내는 것.

l 시나리오가 시작될때 외부 시스템이나 사용자가 기대하는 것.

l 시나리오에 일어나는 사건에 대한 기본 흐름

l 문제가 발생되는 비정상적인 사건에 대한 대안 흐름

l 동시에 병행으로 일어나는 다른 활동에 관한 정보

l 시나리오가 종료되었을 때 시스템의 상태에 대한 정보

간단한 예시

쇼핑몰 고객관리 유스케이스 명세서

쇼핑몰 고객관리 시스템은 고객의 정보를 관리하고, 고객과 관련된 다양한 작업을 수행하는 시스템입니다. 아래는 고객관리 유스케이스와 각 유스케이스에 대한 명세서입니다.

유스케이스 목록

고객 등록 (Customer Registration)
고객 정보 수정 (Update Customer Information)
고객 정보 조회 (View Customer Information)
고객 계정 삭제 (Delete Customer Account)
고객 주문 내역 조회 (View Customer Order History)
고객 문의 처리 (Handle Customer Inquiry)

1. 유스케이스: 고객 등록 (Customer Registration)

유스케이스 이름: 고객 등록

행위자: 고객 (Customer)

설명: 고객이 쇼핑몰에 새로운 계정을 등록합니다.

사전조건: 고객은 쇼핑몰 홈페이지에 접근할 수 있어야 합니다.

후기조건: 새로운 고객 계정이 시스템에 저장됩니다.

주요 시나리오:

고객이 쇼핑몰 홈페이지에 접속한다.
고객이 '회원가입' 메뉴를 선택한다.
고객이 필요한 정보를 입력한다 (이름, 이메일, 비밀번호, 주소 등).
고객이 입력한 정보를 확인하고 제출한다.
시스템이 입력된 정보를 검증한다.
시스템이 새로운 고객 계정을 저장한다.
시스템이 등록 완료 메시지를 고객에게 표시한다.

대체 시나리오:

5a. 입력된 정보가 유효하지 않은 경우:

시스템이 오류 메시지를 표시하고 고객이 정보를 수정 후 다시 제출한다.

MySQL 실습환경 구성하기 - 서버설치

whoAmI_ — Wed, 22 May 2024 10:47:50 +0900

1. 아래 사이트에서 MySQL설치파일을 내려받습니다.

MySQL :: Download MySQL Installer

Note: MySQL 8.0 is the final series with MySQL Installer. As of MySQL 8.1, use a MySQL product's MSI or Zip archive for installation. MySQL Server 8.1 and higher also bundle MySQL Configurator, a tool that helps configure MySQL Server.

dev.mysql.com

2. 다운로드한 파일 실행하여 설치를 시작합니다.

3. 저는 기존에 workbench가 설치되어있어 관련 upgrade를 진행 한 후 아래와 같은 창이 떴습니다.
여기서 설치하고자 하는 Products를 선택해줍니다.
저는 MySQL Server 와 MySQL Router, Sample and Examples 를 택했습니다.

4. 설치를 시작합니다.

5. 그 다음 MySQL 서버에 관한 환경 설정을 수행하는 화면이 나타납니다.

6. 기본포트는 3306인데 3355포트로 변경해보겠습니다.

7. 루트계정에 대한 비밀번호를 입력합니다.

8. 나머지단계는 그대로 Next 진행하고, 마지막으로 지금까지 적용한 환경설정 목록을 확인하고 Excute 버튼을 클릭합니다.

9. 다음으로 MySQL Router 설정을 시작합니다. 별다른 추가 설정 없이 Finish 버튼을 클릭합니다.

10. 다음으로 Samples and Examples 를 설정합니다. 샘플 데이터를 실행할 환경에 대한 접속계정을 입력하는 화면입니다.
여기서는 실습용 샘플 데이터를 적용할 DB 서버와 접속계정(root)과 패스워드를 입력한 뒤 Check버튼을 클릭하여 화면의 상태가 녹색으로 바뀌는지 확인 후 Next 버튼을 클릭합니다.

11. 설치를 모두 마친 후, MySQL DB에 접속해보겠습니다.

윈도우 환경에서 키보드 윈+R 을 누른뒤 cmd를 입력하여 커맨트 창을 켭니다.

12. MySQL 파일이 위치한 C:\Program Files\MySQL 까지 오면 아래와 같은 디렉터리를 확인할 수 있습니다.

C:\Program Files\MySQL\MySQL Router 8.0\bin> 으로 이동 후

MySQL 접속계정(root)과 접속포트(3355)를 mysql -uroot -p --port 3355 와 같이 입력하고 엔터를 누릅니다.
만약 아까 접속포트 변경 없이 기본적인 접속포트 3306으로 설치했다면 mysql -uroot -p 또는 mysql -uroot -p --port 3306 으로 입력하고 엔터를 누릅니다.

mysql> 프롬프트가 나오면 show databases; 명령어를 입력하고 엔터키를 눌러 출력 결과를 확인합니다.

현재 로컬에 설치된 데이터베이스 목록이 나오면 무사히 설치된 것입니다.

데이터 / 데이터베이스 / DBMS / 파일시스템 / 스토리지 관련 용어정리

whoAmI_ — Fri, 17 May 2024 12:00:51 +0900

프로그래밍이나 데이터 관련 공부를 하다보면 관련 용어들이 많이 등장하는데 용어들이 서로 비슷하기도 하고 서로간에 어떠한 관계가 있는지 정리할 필요성을 느껴 기록하게 되었다.
용어들이 점차 확장되도록 정리하려고 했다.

데이터란 ?
데이터는 실세계의 가공되지 않는 모든 자료들을 말한다.우리는 실세계에서 가공되지 않은 자료들이 넘쳐나는 시대에 살고 있는데, 그 중에는 우리에게 유의미한 자료들도 있을것이고, 필요하지 않은 무의미한 정보들도 섞여 있을 것이다.

정보란 ?
그 많은 데이터들 중 우리에게 쓸모있고 의미있는 내용으로 추출하고 가공하여 체계적으로 조직한 데이터를 의미한다.

데이터베이스(Database, DB) 란 무엇일까 ?
한마디로 '데이터의 집합'이라고 할 수 있다.
위에서 얘기한 수많은 방대한 데이터들을 정보로 처리하기 이전에 어떻게 체계적으로 관리할 수 있을지에 대한 고민이 데이터베이스의 시발점이다. 이 수많은 데이터들을 어떤 특정한 조직에서 여러 명의 사용자 또는 응용 시스템들이 공유하고 동시에 접근하여 사용할 수 있도록 구조적으로 통합하여 저장한 운영 데이터의 집합이다.

=> 데이터베이스의 의미를 정리하면
데이터베이스는
1) 공유데이터(shared data) 이다.
2) 통합된 데이터(integrated data) 이다.
3) 저장된 데이터(stored data) 이다.
4) 운영 데이터(operational data) 이다.

* DB는 실시간으로 모두가 공유하는 데이터를 내용에 따라 참조하여 변화시킬 수 있어야 한다.

DBMS(Database Management System, 데이터베이스 관리 시스템) 란 ?

https://medium.com/@erpinformation/what-is-database-management-system-dbms-6-advantages-a3904e8f9989

데이터베이스를 운영하고 관리하는 소프트웨어를 DBMS라고 한다.
이를 이용하여 데이터베이스에 접근하여 데이터를 조작할 수 있도록 도와준다.
즉, 사용자는 DB에 직접 접근하여 데이터를 다루는 것이 아니라, DBMS의 도움으로 데이터를 다루고 변화시킬 수 있다.
그렇기 때문에 다양한 데이터가 저장되어 있는 데이터베이스는 여러 명의 사용자나 응용 프로그램과 공유하고 동시에 접근이 가능해야 한다.

데이터베이스 시스템(Database System) 이란 ?

https://jgtonys.github.io/school/2018/10/20/database-1/

데이터베이스 시스템은 데이터를 데이터베이스에 구조화하고 저장하며 관리하는 전체 시스템을 가리킨다.
이는 데이터베이스 관리 시스템(DBMS)과 관련된 소프트웨어뿐만 아니라 데이터베이스를 구성하는 하드웨어, 소프트웨어, 데이터, 사용자 등을 모두 포함한다.

- 데이터베이스 관리 시스템 (DBMS) 의 정의를 다시 짚고 가자.
데이터베이스 관리 시스템(DBMS)은 데이터베이스 시스템의 핵심 구성 요소 중 하나로, 데이터를 구조화하고 저장하며 관리하는 소프트웨어를 가리킨다. 이는 사용자가 데이터베이스에 접근하고 데이터를 검색, 추가, 수정, 삭제하는 등의 작업을 수행할 수 있도록 한다.
DBMS는 데이터베이스의 구조를 정의하고 유지하는 데 사용되며, 데이터의 보안, 무결성, 공유, 백업 및 복원 등을 관리한다. 일반적인 DBMS 종류로는 Oracle, MySQL, SQL Server, PostgreSQL, MongoDB 등이 있다.

- 데이터베이스 시스템과 DBMS 의 차이 ?
요약하면, 데이터베이스 시스템은 데이터를 구조화하고 저장하며 관리하는 전체 시스템을 가리키는 반면, 데이터베이스 관리 시스템(DBMS)은 데이터를 구조화하고 저장하며 관리하는 소프트웨어를 가리킨다. DBMS는 데이터베이스 시스템의 일부분으로서 데이터 관리와 관련된 주요 기능을 담당한다.

데이터 언어
데이터 언어는 사용자 또는 응용 프로그램과 DBMS 간에 의사소통(데이터를 정의하고 조작)을 하기위한 언어이다. 데이터 정의 언어(DDL), 데이터 조작 언어(DML), 데이터 제어 언어(DCL) 로 구성되어 있다.

- 데이터 정의 언어 (DDL, Data Definition Language)
DDL은 데이터베이스의 구조를 정의하고 변경하는 데 사용되는 언어이다.
테이블, 인덱스, 뷰와 같은 데이터베이스 객체를 생성(create), 수정(alter), 삭제(drop)하는 데 사용된다.

- 데이터 조작 언어 (DML, Data Manipulation Language)
DML은 데이터베이스에 저장된 데이터를 검색(select), 삽입(insert), 수정(update), 삭제(delete)하는 데 사용되는 언어이다.
DML 명령어는 주로 데이터의 조작과 관련된 작업을 수행한다.

- 데이터 제어 언어 (DCL, Data Control Language)
DCL은 데이터베이스에 대한 접근 권한을 제어(grant, revoke)하는 데 사용되는 언어이다.
DCL 명령어는 데이터베이스 보안과 권한 관리와 관련된 작업을 수행한다.

SQL(Structured Query Language) 란?
구조화된 질의 언어라는 뜻으로 관계형 데이터베이스에서 사용되는 언어이다.
일반적으로 SQL(Structured Query Language)이 가장 널리 사용되는 위에서 언급한 데이터 언어이다.

그럼 전반적인 데이터베이스 관련 개념들의 정의는 알아보았다.
이제 파일시스템 / 스토리지 / 데이터베이스 시스템 과의 관계를 알아보자.

파일 시스템 (File System)

https://www.geeksforgeeks.org/linux-file-system/

파일 시스템은 운영 체제에서 데이터를 저장하고 조직하는 방법이다. 파일 시스템은 파일과 디렉터리를 관리하고, 파일을 생성, 읽기, 쓰기, 삭제하는 기능을 제공한다.
- 파일과 디렉터리의 생성, 삭제
- 파일의 읽기, 쓰기, 수정
- 파일의 권한 및 접근 제어
종류로는 NTFS, FAT32, ext4 등이 있다.

오브젝트 스토리지(object storage)
오브젝트 스토리지(Object Storage)는 파일 시스템과 다른 형태의 스토리지이다. 오브젝트 스토리지는 데이터를 객체(Object)로 저장하고 관리한다. 객체는 데이터와 메타데이터의 조합으로 구성되며, 파일 시스템의 폴더 구조와는 다릅니다. 오브젝트 스토리지는 클라우드 환경에서 주로 사용되며, 대용량의 데이터를 효율적으로 저장하고 접근하는 데 사용 된다.

스토리지 (Storage)
스토리지는 데이터를 물리적으로 저장하는 하드웨어 장치 또는 솔루션이다. 하드 드라이브(HDD), 솔리드 스테이트 드라이브(SSD), 클라우드 스토리지 등으로 구성될 수 있다. (HDD, SSD, NAS, SAN, 클라우드 스토리지 등)

파일시스템과 오브젝트 스토리지, 스토리지의 관계는?
데이터를 파일로 관리하면 파일 시스템을 사용하고, 데이터를 객체로 관리하면 오브젝트 스토리지를 사용한다. 파일 시스템과 오브젝트 스토리지는 둘 다 스토리지의 형태이며, 스토리지는 데이터를 실제로 저장하는 물리적인 장치나 서비스를 가리킨다.

데이터베이스 시스템 (Database System) 의 정의를 다시 한번 내려보자
데이터를 체계적으로 저장, 관리, 검색하는 시스템으로, 파일 시스템과 스토리지 위에 구축된 시스템 이다.

데이터베이스 시스템의 구성요소를 살펴보자면
- 데이터베이스 관리 시스템(DBMS) : 데이터를 관리하고, 쿼리를 처리하고, 트랜잭션을 관리하는 소프트웨어
- 데이터베이스 : 테이블, 열, 행 등 구조화된 데이터가 저장된 논리적 집합
- 메타데이터(시스템 데이터베이스) : 데이터베이스 구조, 제약 조건, 권한 등의 정보를 저장
- 하드웨어 : 데이터베이스를 저장하는 물리적 스토리지와 이를 지원하는 서버 및 네트워크 인프라
들이 모여 데이터베이스 시스템을 이룬다고 볼 수 있다.

시스템 데이터베이스 란 ?
데이터베이스는 시스템 데이터베이스 (데이터 사전, System Database or Data Dictionary) + 저장 데이터베이스 (Stored Database) 로 이루어 진다고 볼 수 있다.

- 시스템 데이터베이스
시스템 데이터베이스는 데이터베이스 시스템의 메타데이터를 저장하는 특수한 데이터베이스이다. 데이터 사전(Data Dictionary) 이라고도 불린다.
- 메타데이터 : 데이터베이스 구조, 스키마, 데이블 정의, 열 정보, 데이터 타입, 인덱스, 제약 조건 등 데이터베이스의 구조와 관련된 정보를 저장한다.
- 관리정보 : 사용자 계정, 권한, 데이터베이스 설정, 트랜잭션 로그 등의 데이터베이스 관리 정보를 포함한다.
- 시스템 관리도구 : 쿼리 최적화, 성능 모니터링, 데이터 무결성 유지 등의 작업에 사용

- 저장 데이터베이스
저장 데이터베이스는 실제 데이터가 저장되는 데이터베이스를 의미한다.

그럼 파일시스템과 스토리지, 데이터베이스 시스템의 관계는 ?

스토리지와 파일 시스템
스토리지는 데이터를 저장하는 물리적 장치이다.
파일 시스템은 이러한 스토리지 장치 위에 구축되어, 데이터를 파일과 디렉터리로 조직하고 관리한다.
파일 시스템은 스토리지에 데이터를 읽고 쓰는 방법을 제공한다.

파일 시스템과 데이터베이스 시스템
파일 시스템은 데이터베이스 시스템의 기초를 형성한다. 데이터베이스 시스템은 파일 시스템을 사용하여 데이터를 물리적으로 저장한다.
데이터베이스 시스템은 파일 시스템 위에 구축되어, 더 높은 수준의 데이터 관리 기능을 제공한다. 파일 시스템은 데이터베이스의 물리적 저장소로 사용되며, DBMS는 이를 통해 데이터를 관리하고 쿼리를 처리한다.
예를 들어, 데이터베이스 시스템에서 테이블에 대한 데이터를 파일 시스템의 파일로 저장한다. DBMS는 이 파일들을 관리하고, 사용자가 SQL 쿼리를 통해 데이터를 접근할 수 있도록 한다.

마지막으로 요약하자면,

스토리지는 데이터를 물리적으로 저장하는 장치이다.
파일 시스템은 스토리지 위에 구축된 소프트웨어 계층으로, 데이터를 파일과 디렉터리로 조직하고 관리한다.
데이터베이스 시스템은 파일 시스템 위에 구축된 소프트웨어 시스템으로, 데이터를 구조화된 방식으로 저장, 관리, 검색하는 기능을 제공한다.

How to backup a postgres database using java / 자바로 postgres DB 백업하기(pg_dump)

whoAmI_ — Tue, 14 May 2024 11:05:21 +0900

자바로 백업모듈을 만들어야 했는데, 자바에서 pg_dump를 실행해 sql파일을 떨구는 일이다.

우리가 가져가고자 하는 백업 프로세스를 간단히 말하자면
전체백업은 하루에 한번, 특정 테이블 데이터는 데이터특성에 따른 주기별로
1) 기존 백업스키마 데이터 삭제
2) 백업테이블 갱신
3) 백업스키마 sql 백업
4) DB 전체 sql 백업
순으로 이루어 진다.

기존에는 리눅스에 쉘스크립트 생성후 cron으로 돌려 파일백업, 전체백업을 진행했는데 이번에는 자바모듈안에서 해결했으면 좋겠다고 하셨다. 백업모듈은 데몬으로 돌아야하는데, 이렇게 실행하나 저렇게 실행하나 데몬역할을 하는거라고 보면 된다고 하셨는데, 서비스로 띄우는것과 약간 차이가 있지 않나 더 알아봐야 할 것 같다.

이 작업을 하기 위해 자바에서 커맨드명령어를 날려 pg_dump를 실행하는 방법을 찾아보았고,

아래 stackoverflow를 통해 해답을 얻을 수 있었다. 8년전 글이기 때문에, 지금 자바에서 pg_dump를 연동하려면 더 나은 방법이 있을지도 모르겠다.

How to backup a postgres database using java

this is the code I am using to back up my database using pg_dump 9.3 in java. The problem I have is that always the result file is empty, and the exit code is 1, any ideas? public static void back...

stackoverflow.com

테스트하는 로컬서버는 윈도우고, 개발서버, 운영서버는 리눅스 이기 때문에 위와같이 로컬테스트 진행 후
리눅스에도 서비스를 띄워 sql파일 백업이 잘 진행되는지 확인해보았다.

pg_dump를 실행시키는 것이기 때문에, 경로를 잘 지정해주어야 한다.
개발, 운영 환경에 맞게 설정파일로 분리하는것이 좋다.

윈도우 pg_dump 경로

database.pgdump.path=C:\\Program Files\\PostgreSQL\\10\\bin\\pg_dump.exe

리눅스 pg_dump 경로

database.pgdump.path=/usr/pgsql-10/bin/pg_dump

또한 전체 파일 백업과, 특정 테이블을 지정하여 sql백업을 받을 수 있다.

pb = new ProcessBuilder(
        dbPgdumpPath, // C:\Program Files\PostgreSQL\10\bin
        "--host", dbHost,
        "--port", dbPort,
        "--username", dbUsername,
        "--no-password",
        "--format", "custom",
        "--blobs",
        "--verbose",
        "--file", fileName);

-t 옵션으로 특정 테이블 지정이 가능하고, --encoding 옵션으로 인코딩포맷 지정이 가능하다.

pb = new ProcessBuilder(
        dbPgdumpPath, // C:\Program Files\PostgreSQL\10\bin
        "--host", dbHost,
        "--port", dbPort,
        "--username", dbUsername,
        "--no-password",
        "--format", "custom",
        "--blobs",
        "--verbose",
        "--encoding", "UTF-8",
        "--file", fileName,
        "-t", tableNm);

백업파일명을 생성할 땐 주로 백업날짜를 붙여 파일명을 생성하니, 그 부분도 신경써주는 것이 좋다.

// 현재 날짜
LocalDate today = LocalDate.now();
// 파일 이름에 포맷을 지정, 오늘 날짜를 포함
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyyMMdd");

현재 날짜 생성 후 fileName 생성시 붙여주면

fileName = dbBackupPath + tableNm + "_backup_" + today.format(formatter) + ".sql";

백업파일생성

파일이 잘 떨어지는 것을 확인할 수 있다.

추가로, 인텔리제이에서 작업시, pg_dump수행 중에 한글이 깨지는 현상이 발생했는데
프로세스의 환경 변수 맵에 LANG 설정을 해주면 한글이 정상 출력 되는 것을 확인할 수 있다.

final Map<String, String> env = pb.environment(); // 프로세스의 환경 변수 맵
env.put("PGPASSWORD", dbPassword);
env.put("LANG", "en_US.UTF-8");

리눅스 마스터 2급 - 과목중요도순

whoAmI_ — Tue, 23 Apr 2024 14:48:54 +0900

업무에서 리눅스 서버 설치, 서비스 배포 등 다룰일이 있어서, 관련 지식을 갖출 겸 공부를 해야겠다고 생각하고
리눅스 마스터 2급 시험을 신청하게 되었다. 리눅스마스터 시험은 1차, 2차에 걸쳐 시행된다.

1차는 온라인(오픈북)시험, 2차는 우리가 익히 아는 실기 시험장에 가서 치루는 CBT 시험으로 이루어진다.

나도 시험을 치루기 전 가장 단기간에 효율적으로 공부하기 위한 방법을 찾아봤고,
다행히도 1차, 2차 모두 합격했고, 빠르게 준비해서 시험을 치루고자 하는 이들을 위해 공부하는 법을 공유하고자 한다.

사실 특별한 방법은 없다.

1차 시험

준비필요 X

1차시험은 집에서 pc로 시험을 치면 된다. 오픈북 시험이라고 봐도 무방하다.
인터넷에 리눅스마스터 2급 족보 를 검색하면 이것저것 많이 나온다.
족보들을 모아두고, ctrl + f 로 시험 때 잘 찾아서 풀면 된다. 1차는 결과가 바로 나온다.
공부 없이도 치고 합격 가능한 1차 시험.

그런데 1차는 이렇게 쉽게 시험을 쳐도 2차는 제대로 공부해야 시험장에 가서 문제를 풀 수 있다는 점을 기억해야 한다..

2차 시험

기출 -> 개념 -> 기출 -> 개념 -> 기출 ......

먼저 리눅스마스터 2급 2차 필기 기출문제 사이트

리눅스마스터 2급 필기 기출문제 전자문제집 CBT - 최강 자격증 기출문제 전자문제집 CBT

리눅스마스터 2급 필기 기출문제 전자문제집 CBT

www.comcbt.com

최근 3년도 기출문제를 다 풀며 개념을 확인한다. 처음에는 모르는 개념이 나와 시간이 좀 걸릴 수 있는데,
한두장 정도 풀다보면 뒤에서는 같은 개념에서 문제가 반복되어 출제 된다.
물론 자격증취득용이기도 하지만, 이왕이면 따는김에 공부도 되었으면 해서 중요한 파일시스템, 소유권 그리고 중요한 개념들은 인터넷 검색해가면서 공부하며 문제를 풀었다.

2과목은 크게 총 9개과목으로 나뉘어지는데 1-6, 7-9 장으로 묶어서 보면 된다.
각 과목별로 중요도와 배분된 문제수에 차이가 있다.

첫번째 과목 문제배분과 중요도 순서이다.

1. 파일시스템 관련 명령어 (권한 및 그룹 설정 과 파일시스템 관리)
2. 프로세스 관리
3. 셸, 소프트웨어 설치
4. 에디터, 주변 장치

두번째 과목 중요도 순서

1. 인터넷 활용
2. X-Windows
3. 응용분야

과목별로 중요도와 문제비중이 높은 과목순서대로 공부를 했다.
실제로 문제풀이나 시험에서도 위와같은 비율로 출제가 된다.

시험에 합격하는것도 중요하지만, 이왕이면 공부해서 머릿속에 오래 남기자는 마음으로
모르는 개념이 나올때마다 관련 자료들을 3-5개이상 찾아보면서 공부했다.

Databricks 스파크 시작(내용무)

whoAmI_ — Tue, 26 Mar 2024 15:56:24 +0900

Databricks - Sign In

community.cloud.databricks.com

노트북 생성하고, 클러스터 생성 완료

kaggle 사이트 접속, 로그인 후 데이터 내려받기

[JVM] Class Loader

whoAmI_ — Sun, 21 Jan 2024 22:24:35 +0900

jvm에 대해 검색하면 자주 보이는 부분이 heap메모리 영역과 runtime data area 에 대한 글들을 많이 볼 수 있다.

나는 우리가 작성하는 소스코드가 메모리에 어떻게 올라가고 어떻게 동작하는지 궁금하여 JVM에 관한 책들을 읽게 되었다.
간략하게 말하자면 우리가 작성한 자바 소스코드는 먼저 자바컴파일러에 의해 컴파일 되어 JVM이 실행할수있는 class 파일로 변환되고
클래스 로더가 JVM으로 클래스를 로드 한 후 로딩, 링킹 과정을 거쳐 runtime data area에 배치한다.

Image Reference:-Oracle

JVM에서 Class파일의 실행은 Class Loader를 통해 로딩되면서 시작되기 때문에, Class Loader에 대한 이야기를 먼저 정리해보려고 한다.

https://www.artima.com/insidejvm/ed2/lifetype.html

Class Loader

Java의 특성 중 하나는 Runtime시에 동적으로 Class를 읽어온다는 것이다.

모든 Class는 참조되는 순간 동적으로 Load 및 Link가 이루어진다. 이러한 방식을 Dynamic Loading 이라고 한다.

JVM에서 Dynamic Loading을 담당하는 주체는 바로 Class Loader이다.

즉, Class Loader란 JVM내로 Class를 Load하고 Link를 통해 적절히 배치하는 일련의 작업을 수행하는 모듈이라고 정의할 수 있다.

Dynamic Loading

Load가 어느 시점에 수행되느냐에 따라 Load Time Dynamic Loading 과 Runtime Dynamic Loading으로 구분된다.

Load Time Dynamic Loading
하나의 Class를 Loading하는 과정에서 이에 관련된 Class들을 한꺼번에 Loading 하는 방식
Runtime Dynamic Loading
소스 코드에서 객체를 참조하는 순간에 동적으로 Loading 하는 방식(Reflection이라는 기술의 기본이 되어 Spring과 같은 Framework에도 널리 사용되고 있다.)

아까 Class Loader란 JVM내로 Class를 Load하고 Link를 통해 적절히 배치하는 일련의 작업을 수행 한다고 하였는데, JVM은 동일한 Class를 중복해서 Loading 하지 않는다. 그렇기 때문에 해당 Class가 JVM에 이미 Load 되어 있는지 확인하는 과정이 필요하게 되는데, 이 과정에서 Class를 구별하는 방법은 Class의 이름이다.

Class의 이름이라고 하면 보통 Full Qualified Name(Package Name과 Class Name을 점(.)으로 연결한 이름)을 의미한다.

그러나 Class Loader가 Class를 인식하는 것은 여기에 Class를 Load한 Class Loader의 이름까지 포함한다. Loader Name + Package Name + Class Name 까지 동일해야 같은 Class로 인식한다.

Class Loader가 Class를 Load할 때 JVM에 있는 모든 Class를 찾아다니며 이름을 확인하는 것이 아니라 Namespace라는 것을 사용한다.

Namespace

Class Loader는 Namespace를 각각 하나씩 가지고 있어 자신이 Load한 Class의 Full Qualified Name을 저장해 놓는다. 자신의 Namespace에 이름이 없다면, 같은 Class라도 Class Loader만 다르다면 중복해서 Load가 가능하다는 것을 의미하기도 한다.

그럼 언제 Class Loader가 자신의 Namespace를 검색할까?

바로 Symbolic Reference 를 수행할 때 이다. 객체의 이름으로 참조를 할 때마다 Class Loader는 해당 Class를 Load 해야 할 지의 여부를 결정하기 위해 Namespace를 참조하게 된다. 그런데 Java는 자신이 참조하는 Class를 Load할 때 반드시 참조하는 Class와 참조되는 Class가 동일한 Class Loader를 사용해야만 한다는 규칙이 있다.

Symbolic Reference

자바에서 심볼릭 레퍼런스(symbolic reference)는 클래스 이름이나 인터페이스 이름으로 클래스나 인터페이스를 참조하는 방식을 말한다. 기본 자료형(primitive data type)을 제외한 모든 타입은 심볼릭 레퍼런스를 통해 참조된다.

심볼릭 레퍼런스 예시 ( String 클래스를 심볼릭 레퍼런스로 참조하는 예 )

String str = "Hello, world!";

이 코드에서 str은 String 클래스의 인스턴스를 참조한다. 그러나 str은 String 클래스의 주소를 직접 참조하는 것이 아니라, String 클래스의 이름인 "java.lang.String"으로만 참조한다.

실행 시점에 JVM은 "java.lang.String"을 통해 String 클래스를 찾고, 그 주소를 str에 연결한다.

다른 예시, 다음 코드는 Runnable 인터페이스를 심볼릭 레퍼런스로 참조하는 예이다.

Runnable runnable = () -> System.out.println("Hello, world!");

이 코드에서 runnable은 Runnable 인터페이스의 구현체를 참조한다. 하지만 runnable은 Runnable 인터페이스의 주소를 직접 참조하는 것이 아니라, Runnable 인터페이스의 이름인 "java.lang.Runnable"으로만 참조한다.

실행 시점에 JVM은 "java.lang.Runnable"을 통해 Runnable 인터페이스를 찾고, 그 주소를 runnable에 연결한다.

심볼릭 레퍼런스는 다음과 같은 경우에 사용된다.

클래스나 인터페이스를 미리 정의하지 않고 사용해야 하는 경우
클래스나 인터페이스를 동적으로 로드해야 하는 경우
클래스나 인터페이스를 반환해야 하는 경우

심볼릭 레퍼런스를 사용하면 코드의 유연성이 향상되고, 런타임 시점에 클래스나 인터페이스를 동적으로 선택할 수 있다.

메소드 호출은 런타임에 실제로 해결되지만, Symbolic Reference는 컴파일 시간에 사용된다.

Class exHello {
	Class c1 = Class.forName(exem.package.jvmclass);
}

Class Loader1, Class Loader2가 있을때, Class Loader2가 exHello를 Load하고 나서 exem.package.jvmclass 를 참조하기 위해 Class Loader1가 아닌 Class Loader2가 Load를 한다는 말 이다.

참조관계가 있는 Class들은 같은 Class Loader를 사용해야 한다 는 원칙이 있기 때문이다.

이 때 Class Loader가 단 하나만 사용되거나 수많은 Class Loader들이 제각각 Load 하는 상황이 발생하지 않도록 Class Loader Delegation Model 의 방법이 사용된다.

https://www.infoworld.com/article/3700054/all-about-java-class-loaders.html

Class Loader Delegation Model

: Load의 요청을 위계적으로 전달하는 방식을 의미한다.

JVM내에는 여러 개의 Class Loader가 있으며 Class Loader는 위계 구조, 계층 구조를 가지고 있다. Class Loader Delegation Model은 이러한 위계 구조를 바탕으로 서로에게 임무를 **위임(Delegation)**하는 일련의 방법을 말한다.

Class Loader는 Bootstrap Class Loader / Extension Class Loader / Application Class Loader 등으로 구별 되고 있다.

Bootstrap Class Loader

부모를 가지지 않는 가장 상위의 Class Loader 이다.
JVM 기동 시에 가장 먼저 생성, $JAVA_HOME/jre/lib/rt.jar 를 Load 하는 작업을 수행한다. 그 이후 Object Class를 포함한 Java API들을 Load 하게 된다.
Native Code로 구현되어 있다.

⇒ JAVA 를 수행하기 위한 Runtime 환경을 구성하는 기초 단계에 포함 된다.

Extention Class Loader

BootStrap Class Loader 를 부모로 하고 기본 Java API를 제외한 $JAVA_HOME/jre/lib/ext에 위치한 확장 Class들을 Load하는 작업을 수행한다.

Bootstrap Class Loader 와 Extension Class Loader는 JVM을 위한 Class Loader 라고 할 수 있다.

Application Class Loader(= System Class Loader)

System Class Loader라는 명칭으로 부르기도 한다.
System Class Loader와 User Defined Class Loader를 합쳐서 부르기도 한다.
JVM이 아니라 Application User를 위한 Class Loader이다. $CLASSPATH 또는 java.class.path에 위치한 Class 들을 Load 한다.

User Defined Class Loader

Application에서 직접 생성이 가능하다. 보통 WAS나 Framework에서는 User Defined Class Loader를 생성해서 사용하는 경우가 많다. User Defined Class Loader는 System Class Loader의 하위에 있으며 User Defined Class Loader 들 끼리도 계층을 가지게 된다.

Class Loader Delegation Model은 Load의 요청을 위계적으로 전달하는 방식을 의미하는데 이 요청은 위로 위임을 하게 된다.

Class를 탐색하는 것도 이와 유사하다. 일단 Namespace를 검색하여 이미 Load된 Class 라면 이를 반환하고 Load 되어 있지 않으면 Parent 에게 위임을 하게 된다. 만약 Parent Class Load가 이를 완료하지 못하면 자신이 Class를 Load한다.

Class의 Load 과정 정리

Class Loader가 Load 요청을 받으면 내부적으로 loadClass()라는 Method가 수행된다. loadClass() : Class가 이미 Load되어있으면 반환, 아니면 Parent Class Loader에게 위임
Parent Class Loader 도 이 Class를 Load 하지 않았다면 findClass() 를 호출한다. findClass() : 요청받은 Class Loader가 직접 파일 시스템을 탐색하여 Class를 Load 한다.

예제

System Class Loader 에게 특정 Class를 Load 하도록 하는 작업 요청했다고 가정.

이 특정 Class는 파일시스템 어딘가에 존재할 것이고 그 디렉토리는 $CLASSPATH 로 지정한 것.

1) 이 경우 System Class Loader는 자신의 Namespace를 찾아보고 Load 한 적이 없으면 자신이 Load를 시도하는 것이 아니라 Extension Class Loader에게 요청을 위임하게 된다.

2) 이 Extension Class Loader도 역시 자신의 Namespace 를 검색하여 Class를 찾지 못할 경우 다시 Load 작업은 Bootstrap Class Loader로 넘어가서 같은 작업을 반복한다.

3) 여기서도 실패하게 되면 $CLASSPATH 를 직접 찾아보고 해당 Class를 Load 하게 되는 것이다.

JVM에서 Default 로 사용하는 Class Loader는 System Class Loader 이며 User Defined Class Loader를 생성할 때 별도의 Parent를 지정하지 않게 되면 System Class Loader가 부모가 된다.

보통 WAS의 경우에는 User Defined Class Loader를 만들어 이를 주로 사용하게 된다. $WAS_HOME과 같은 특정 디렉토리를 설정하여 검색하도록 되어있다.

Class Loader Delegation Model의 또 한가지 원칙은 Class Loader 자신과 자신의 Parent Class Loader의 정보는 열람이 가능하지만 자신보다 하위에 있거나, 부모가 같더라도 형제처럼 갈라진 Class Loader에게는 위임도 불가능하고 Namespace의 정보를 제공받지 못한다는 것이다.

⇒ 자기 역할이 아니면 완료하지 못하니 상위로 위임. 각자 자기가 맡은 것만 로딩한다.

클래스는 부모부터 로딩. 상속관계이면 하위는 볼 수 없다. 그러면 밑에서 처리한다.

클래스 로더에게 역할을 분배. 그리고 상위 클래스로더는 하위 클래스 로더를 보지 못하니

하위에서 상위에게 일을 위임하고 상위에서 하지 못하는 것은 제일 하위가 다 하는 것이다.

상속관계의 특징은 자식은 부모를 볼 수 있다. 부모는 자식을 볼 수 없다.

생성자도 항상 부모 생성자부터 처리하고 자식 생성자 처리.

이렇게 하는 것은 부모 클래스를 로딩하고 난 후에 자식 클래스를 로딩해야 정상적인 관계가 만들어진다는 뜻 이다.

위에서부터 다 메모리에 로딩해야 자기가 상위를 보면서 처리한다는 표현이다.

이러한 특성들을 바탕으로 WAS벤더들은 나름의 Class Loader Tree를 구성하여 사용한다. WAS 라는 것은 J2EE 표준을 따른 구현체 이다. J2EE 안에는 JNDI, JMS등등의 여러 서버들이 구성되어 있기는 하지만, 가장 중요한 것은 Web Container와 EJB Container 라고 생각된다.