무지성 개발 탈출기 | Feed

JS의 기본 개념 2. this

Sat, 06 Nov 2021 00:00:00 GMT

this란?

함수 내에서 함수를 호출한 객체에 접근하기 위한 JS의 키워드

함수 내에서 this를 보신 적이 있으신가요? 특히 Class나 객체를 생성하기 위해서 선언하는 함수를 사용한 경험이 있다면, this를 많이 보셨을 겁니다. python의 self와 같이 this는 기본적으로 함수를 호출하는 객체를 가리키고 있지만, 선언 방식이나 호출 방식에 따라 전혀 다른 결과가 나올 수 있습니다. 사실 this를 사용할 일이 잘 없지만, 알고 사용하는 것과 모르고 사용하는 것에는 큰 차이가 존재하기 때문에 이번 기회에 정리해보고자 합니다. this 바인딩룰을 소개하기 전에 바인딩룰에 필요한 기본 개념들을 먼저 소개하도록 하겠습니다.

기본 개념

1. `new` 연산자를 통한 객체의 생성 과정

객체의 형식을 정의하는 생성자 함수와 new 연산자를 통해 객체를 생성할 수 있습니다. 이 방식은 세부적으로 아래와 같이 동작합니다.

새로운 객체를 생성하고 생성된 객체가 생성자 함수의 Prototype Object를 참조할 수 있도록 합니다.

구체적으로 표현하자면, 생성자 함수가 가지는 Prototype Object를 Prototype Link에 바인딩 된 새로운 객체를 생성합니다.
생성된 객체를 함수 내의 this로 바인딩하여 함수를 수행합니다. 이때, this를 통해 명시적으로 호출되는 프로퍼티와 메소드를 객체에 추가합니다.
함수의 수행이 완료되면 해당 객체를 반환합니다.

위 생성방식에서처럼 생성자 함수를 통해 객체의 프로퍼티와 메소드를 정의하기 위해서는 반드시 this를 사용해야 한다는 것을 알 수 있습니다.

2. lexical scope

렉시컬 스코프란, 함수의 스코프가 함수의 선언시점의 스코프로 결정되는 방식

스코프는 참조가 가능한 식별자들의 집합으로, 참조 범위를 의미합니다. 자바스크립트는 기본적으로 '함수 블록 스코프'를 사용합니다. 상위 함수 블록에 대해서만 참조가 가능하다는 것입니다. 하지만 '함수 블록 스코프' 만으로는 명확한 참조 범위를 정의할 수 없습니다. 다음의 예를 봅시다.

const x = 10;

function f1() {
		const x = 20;
		console.log(x);           // .... 1
		f2();
}

function f2() {
		console.log(x);            // .... 2
}

f1();

함수 f1의 출력값은 '함수 블록 스코프'이기 때문에 f1 내부에 정의된 x의 값 20을 출력합니다. 하지만 문제는 f2의 출력값입니다. '함수 블록 스코프'를 사용한다고 하였는데, 함수 f2는 선언 시점의 스코프와 실행 시점의 스코프가 다릅니다. 선언 시점의 스코프는 전역이지만 수행 시점의 스코프는 f1내부입니다. 만약 선언 시점의 스코프를 사용한다면 전역의 x, 10의 값을 출력하지만 수행 시점의 스코프를 사용한다면 내부 변수 x, 20의 값을 출력할 것입니다. 여기서 JS는 선언 시점의 스코프를 사용하는 '렉시컬 스코프'를 사용합니다. 즉, 호출 시점의 스코프가 아닌 선언 시점의 스코프를 사용하기 때문에 f2의 출력값은 전역의 x, 10의 값이 됩니다. 이렇게 JS는 '함수 블록 스코프'와 '렉시컬 스코프'를 사용합니다. 함수는 자신이 선언된 상위 함수 블록이 스코프가 됩니다.

this 바인딩 룰

이제 this 바인딩룰을 제시하고 각각에 대해 설명해보자 합니다. 먼저 this 바인딩룰 전체를 살펴보겠습니다.

기본적으로 this는 함수를 호출하는 객체에 바인딩 됩니다. 호출하는 객체가 명시되지 않은 단순 함수 호출의 경우, 전역객체에 바인딩 됩니다.
함수의 내부 함수는 외부 함수의 this로 바인딩 되지 않습니다.
화살표 함수(Arrow function)의 경우, this가 존재하지 않습니다. 그러므로 화살표 함수 내의 this는 다른 변수와 동일하게 함수의 렉시컬 스코프 상의 this를 참조합니다.
클래스(Class)의 경우, 함수 블록 상의 모든 코드는 'strict mode'로 수행됩니다. 'strict mode'는 기본적으로 this를 자동으로 바인딩하지 않으며, 호출 객체가 명시되지 않은 경우, undefined를 반환합니다.

1번 규칙이 기본 규칙이라고 한다면, 나머지는 특수한 상황에서의 규칙이라고 볼 수 있겠습니다. 이제 규칙을 예제와 함께 하나씩 설명해보겠습니다.

1. 기본적으로 `this`는 함수를 호출하는 객체에 바인딩 됩니다. 호출하는 객체가 명시되지 않은 단순 함수 호출의 경우, 전역객체에 바인딩 됩니다.

this는 함수를 호출한 객체에 접근하기 위한 JS의 키워드라고 하였습니다. 메소드는 this를 통해 자신을 호출한 객체에 접근할 수 있습니다. 하지만 호출 객체가 명시되지 않은 경우 전역객체에 바인딩 됩니다. 이때, 전역객체는 JS가 수행되는 환경에 따라 달라집니다.

전역객체의 종류
1. Node - global
2. Browser - window
3. strict mode - undefined
4. DOM - document (전역 객체라기보다는 최상위 객체의 개념)

예제를 통해 첫 번째 규칙을 설명해보도록 하겠습니다. (설명을 위해 모든 예제는 전역객체가 window로 바인딩 되는 브라우저상에서 수행합니다.)

function Human() {
    console.log(this);                  
    
    this.methodA = function () {
            console.log(this);              
    }
}

const chanwoo = new Human();         // .... 1

const chanjong = Human();            // .... 2

chanwoo.methodA();                   // .... 3

const methodAA = chanwoo.methodA;

methodAA();                           // .... 4

생성자 함수 Human를 통해 인스턴스 chanwoo가 생성되었습니다. 인스턴스는 메소드 methodA()를 가지고 있습니다. 출력값을 하나씩 살펴보겠습니다.

인스턴스 chanwoo - new 연산자를 통해 생성자 함수를 호출하게 되면 this가 새롭게 생성된 객체로 바인딩 되기 때문에 생성된 객체가 생성자 함수를 호출하는 것으로 볼 수 있습니다.
전역객체 window - 생성자 함수를 단순 호출하게 되면, 객체 생성이 수행되지 않기 때문에 함수와 마찬가지로 전역객체에 바인딩 됩니다.
인스턴스 chanwoo - 인스턴스 chanwoo는 생성자 함수 내의 this를 통해 methodA() 를 갖게 됩니다. 또한 메소드를 호출하는 객체는 chanwoo이므로 호출하는 객체에 바인딩되는 룰에 의해 출력값은 인스턴스 chanwoo가 됩니다.
전역객체 window - 인스턴스 chanwoo가 가진 methodA()를 새로운 함수 methodAA()로 할당하여 호출하였습니다. methodAA()는 인스턴스 chanwoo의 methodA()이지만 메소드가 어떤 인스턴스에 정의되어있는가는 중요하지 않습니다. 중요한 것은 호출하는 객체입니다. methodAA()의 호출하는 객체는 명시되지 않았기 때문에 전역객체에 바인딩 됩니다.

2. 함수의 내부 함수는 외부 함수의 `this`로 바인딩 되지 않습니다.

1번 규칙 4번 예제에서 메소드의 this 는 정의된 인스턴스가 아닌 호출하는 인스턴스에 바인딩 되는 것을 확인하였습니다. 사실 이러한 결과가 나타나는 것은 중첩된 함수에서 외부 함수 내 선언된 내부 함수의 this는 외부 함수의 this로 바인딩 되지 않기 때문입니다. 만약 내부 함수의 this가 외부 함수의 this로 바인딩 되었다면, 1번 규칙 4번 예제의 결과는 인스턴스 chanwoo가 출력되었을 것입니다. 아래의 예제를 통해 한 번 더 확인해봅시다.

function Human() {
		
		this.methodA = function () {
			  console.log(this);              // .... 1
				
				function innerFunc() {
					console.log(this);
				}
			
				innerFunc();                    // .... 2
		}

		this.methodB = function () {
			  console.log(this);              // .... 3
				setTimeout(function () {
		    		console.log(this);          // .... 4
		    })
		}
}

const chanwoo = new Human();

chanwoo.methodA();
chanwoo.methodB();

methodA()는 this를 통해 자신을 호출한 객체를 출력하고, 내부에 innerFunc()함수를 선언, 수행합니다. methodB()는 내부에서 비동기 함수를 사용, 콜백 함수를 통해서 this를 출력합니다. 두 메소드를 사용하였을 때의 this 바인딩의 결과를 살펴보도록 하겠습니다.

인스턴스 chanwoo - methodA()을 호출하는 객체가 인스턴스 chanwoo이기 때문에 this의 출력값은 chanwoo입니다.
전역객체 window - 내부함수의 this는 외부함수의 this에 바인딩 되지 않습니다. 내부 함수의 호출 객체를 확인해야 합니다. 현재 호출객체가 명시되어있지 않기 때문에 전역객체에 바인딩 됩니다.
인스턴스 chanwoo - methodB()을 호출하는 객체가 인스턴스 chanwoo이기 때문에 this의 출력값은 chanwoo입니다.
전역객체 window - 내부함수의 this는 외부함수의 this에 바인딩되지 않는다고 배웠습니다. 비동기 콜백 함수도 동일합니다. 콜백 함수의 호출 객체는 명시되어있지 않기 때문에 반드시 전역객체에 바인딩 됩니다. 중요한 것은 함수의 호출객체라는 점은 1번 규칙과 동일하다는 것을 알 수 있습니다.

3. 화살표 함수(Arrow function)의 경우, `this`가 존재하지 않습니다. 그러므로 화살표 함수 내의 `this`는 다른 변수와 동일하게 함수의 렉시컬 스코프 상의 `this`를 참조합니다.

화살표 함수는 function 키워드 대신 ()=>{}의 형태로 정의하는 함수를 말합니다. 즉, 화살표 함수는 함수를 정의하는 또 다른 방식입니다. 이렇게 두 가지 방식을 제공하는 것에는 이유가 있습니다. 바로 this 바인딩에 대한 차이입니다. mozlia docs의 화살표 함수에 대한 글을 번역하면 다음과 같습니다.

arrow function은 함수를 편리하게 선언할 수 있는 시맨틱 슈가로만 볼 수 있다. 하지만 그 차이는 this의 바인딩에 있다. 기본적으로 arrow function은 함수 내에 this를 가지지 않는다. 단순히 렉시컬 스코프 상의 this를 참조한다. 이를 통해서 (setTimeout, setInterval, addEventListener) 와 같은 DOM-element function에서의 this 바인딩의 목적을 가진다.

2번 규칙에 따라 내부 함수의 this는 외부 함수의 this에 바인딩 되지 않습니다. 위의 2번 규칙 1번 예시에서처럼 외부함수의 this를 사용하고자 함에도 전역객체로 바인딩 되어 사용하지 못하는 경우가 발생합니다. 이러한 바인딩 문제를 해결하기 위해서 화살표 함수를 사용합니다. 화살표 함수의 this는 렉시컬 스코프 상의 this를 참조하기 때문에 this는 내부 함수를 화살표 함수로 선언하게 되면 외부 함수의 this를 참조하여 사용할 수 있게 됩니다. 위 예제들을 화살표 함수로 바꿔서 출력값을 확인해보도록 하겠습니다.

function Human() {

		this.methodA = function () {
			  console.log(this);              // .... 1
				
				const innerFunc = () => {
					console.log(this);
				}
			
				innerFunc();                    // .... 2
		}

		this.methodB = function () {
			  console.log(this);              // .... 3
				setTimeout(() => {
		    		console.log(this);          // .... 4
		    })
		}
		  
		this.methodC = () => {
				console.log(this);
		}
}

const chanwoo = new Human();

chanwoo.methodA();
chanwoo.methodB();

const methodAA = chanwoo.methodA;
const methodCC = chanwoo.methodC;

methodAA();                             // ... 5
methodCC();                             // ... 6

인스턴스 chanwoo - methodA()을 호출하는 객체가 인스턴스 chanwoo이기 때문에 this의 출력값은 chanwoo입니다.
인스턴스 chanwoo - innerFunc()가 화살표 함수로 선언되었습니다. 화살표 함수는 this가 렉시컬 스코프 상의 this를 참조하기 때문에 1번의 this와 동일한 객체 chanwoo를 출력합니다. 즉, innerFunc()선언한 함수 스코프 상의 this를 참조하기 때문에 반드시 상위 함수 methodA()의 this와 동일한 값을 가지게 됩니다.
- 중요한 것은 innerFunc()를 function 키워드로 정의한 2번 규칙 2번 예제와의 차이입니다. 내부함수의 this는 외부함수의 this에 바인딩 되지 않고, 호출객체가 명시되어있지 않기 때문에 전역객체에 바인딩 되는 결과를 보았을 겁니다. 이렇게 내부 함수에서도 호출 객체에 접근하기 위해서 화살표 함수를 사용합니다.
인스턴스 chanwoo - methodB()을 호출하는 객체가 인스턴스 chanwoo이기 때문에 this의 출력값은 chanwoo입니다.
인스턴스 chanwoo - setTimeout()의 콜백 함수가 화살표 함수로 선언되었습니다. 화살표 함수는 this가 렉시컬 스코프 상의 this를 참조하기 때문에 3번의 this와 동일한 객체 chanwoo를 출력합니다. 즉, setTimeout()의 콜백 함수를 선언한 함수 스코프 상의 this를 참조하기 때문에 반드시 상위 함수 methodB()의 this와 동일한 값을 가지게 됩니다.
전역객체 window - 인스턴스 chanwoo의 메소드 methodA()를 새로운 함수로 선언하여 호출하였습니다. 중요한 것은 호출 객체라고 배웠습니다. methodAA()를 호출하는 객체가 명시되어있지 않기 때문에 this는 전역 객체에 바인딩 됩니다. 화살표 함수 innerFunc()의 this 또한 동일한 객체를 출력합니다.
인스턴스 chanwoo - 인스턴스 chanwoo의 메소드 methodC()를 새로운 함수 methodCC()로 선언하여 호출하였습니다. methodC()는 화살표 함수로 선언되었으며, 화살표 함수는 렉시컬 스코프의 this를 참조한다고 설명하였습니다. 렉시컬 스코프는 함수의 선언 시점의 스코프를 말하기 때문에 화살표 함수의 this를 찾기 위해서는 선언하는 시점을 확인해야 합니다. methodC()가 선언되는 블록은 생성자 함수 내로, 선언 시점의 생성자 함수의 this는 새롭게 생성되는 인스턴스가 바인딩 됩니다. 그러므로 methodC()의 this 또한 인스턴스를 참조하게 됩니다.
- 중요한 것은 화살표 함수의 바인딩은 선언 시점에 이루어지기 때문에 호출 인스턴스의 영향을 받지 않는다는 것입니다. 화살표 함수의 특성으로 인해 methodCC()로 chanwoo의 methodC()를 선언하여 호출하더라도 methodC()의 this는 그대로 인스턴스 chanwoo를 참조하게 됩니다.
- 함수 정의 방법에 따라 바인딩을 위해 확인해야 하는 영역이 호출 영역인지, 선언 영역인지의 차이가 존재하는 것을 기억해야 합니다. methodAA()와의 차이를 생각해봅시다. 기존의 function 키워드로 선언된 메소드는 호출객체에 바인딩 되었습니다. 하지만 화살표 함수로 선언된 메소드는 호출 객체가 아닌 렉시컬 스코프(선언 시점의 상위 함수 스코프) 상의 this를 참조합니다. 이로 인해 호출 객체가 명시되어있지 않음에도 계속해서 this를 통해 인스턴스에 접근할 수 있었습니다.

주의할 점은 화살표 함수의 경우, 명시적 this 바인딩을 통한 바인딩이 수행되지 않습니다.

4. 클래스(Class)의 경우, 함수 블록 상의 모든 코드는 'strict mode'로 수행됩니다. 'strict mode'는 기본적으로 `this`를 자동으로 바인딩하지 않으며, 호출 객체가 명시되지 않은 경우, `undefined`를 반환합니다.

클래스는 생성자 함수와 동일하게 인스턴스를 생성하기 위해 사용되는 특수한 함수입니다. 클래스를 사용하더라도 this의 바인딩에 대한 위의 규칙들 모두 성립됩니다. 하지만 생성자 함수에서는 this가 전역객체에 바인딩 되었다면 클래스에서는 되지 않는다는 점의 차이가 존재합니다. 클래스와 생성자 함수에는 차이를 몇 가지 더 소개하겠습니다.

클래스의 {} 내에서는 const, function과 같은 키워드를 사용하지 않으며, 프로퍼티와 메소드의 선언 시 생성자 함수에서 this.를 생략한 문법을 사용합니다.
클래스는 기본적으로 new 연산자를 사용하지 않는 호출은 수행될 수 없습니다.
생성자 함수는 메소드가 인스턴스에 선언되지만, 클래스의 메소드는 인스턴스가 아닌 'Prototype Object'에 저장됩니다. 이를 통해 클래스의 인스턴스들은 Prototype Object 내에 선언된 메소드를 공유합니다. (Prototype Object 개념이 낯설다면 이전의 Prototype 포스트를 읽어보시길 권합니다.)
클래스는 함수와는 다르게 호이스팅이 되지 않습니다. 반드시 선언 이후 수행되어야 합니다.

위의 생성자 함수 Human을 클래스로 구현한 예시를 통해 this 바인딩을 설명해보겠습니다.

class Human {
		constructor(name) {
				this.name = name;
		}
		
		methodA = function () {
				console.log(this);
		}
		
		methodB = () => {
				console.log(this);
		}
}

const chanwoo = new Human('chanwoo');

chanwoo.methodA();                      // ... 1
chanwoo.methodB();                      // ... 2

const methodAA = chanwoo.methodA;
const methodBB = chanwoo.methodB;

methodAA();                             // ... 3
methodBB();                             // ... 4

인스턴스 chanwoo - methodA()을 호출하는 객체가 인스턴스 chanwoo이기 때문에 this의 출력값은 chanwoo입니다.
인스턴스 chanwoo - 화살표 함수는 렉시컬 스코프의 this를 참조한다고 설명하였습니다. methodB() 의 this는 호출 객체인 인스턴스 chanwoo이기 때문에 this의 출력값은 chanwoo입니다.
undefined - 인스턴스 chanwoo의 메소드 methodA()를 새로운 함수로 선언하여 호출하였습니다. 중요한 것은 호출 객체라고 배웠습니다. methodAA()를 호출하는 객체가 명시되어있지 않기 때문에 this는 전역 객체에 바인딩 되어야 합니다. 하지만 클래스 내에서는 전역객체가 바인딩 되지 않기 때문에 undefined가 출력됩니다.
인스턴스 chanwoo - 인스턴스 chanwoo의 메소드 methodB()를 새로운 함수 methodBB()로 선언하여 호출하였습니다. methodB()는 화살표 함수로 선언되었으며, 화살표 함수는 렉시컬 스코프의 this를 참조한다고 설명하였습니다. 렉시컬 스코프는 함수의 선언 시점의 스코프를 말하기 때문에 화살표 함수의 this를 찾기 위해서는 선언하는 시점을 확인해야 합니다. methodB()가 선언되는 블록은 생성자 함수 내로, 선언 시점의 생성자 함수의 this는 새롭게 생성되는 인스턴스가 바인딩 됩니다. 그러므로 methodBB()의 this 또한 자신을 가진 인스턴스 chanwoo를 참조하게 됩니다.

조금 더 복잡한 예

지금까지 제시한 바인딩룰을 조금 더 복잡한 예제를 통해 연습해보도록 하겠습니다. 위의 설명이 반복될 수 있으니 충분히 이해하셨다면 넘어가시면 되겠습니다. 인스턴스를 생성하는 함수 Human을 선언하였습니다.

function Human (name) {
	this.name = name; 

	this.methodA = function () {
		function innerFunc() {
			console.log(this);            
		}

		const innerArrowFunc = () =>{
			console.log(this);             
		}
		
		innerFunc();                     // .... a
		innerArrowFunc();                // .... b
	}
	
	this.methodB = () => {
		function innerFunc() {
			console.log(this);            
		}

		const innerArrowFunc = () =>{
			console.log(this);             
		}
		
		innerFunc();                     // .... c
		innerArrowFunc();                // .... d
	}
	
}

const chanwoo = new Human('chanwoo');

chanwoo.methodA();                   // .... 1
chanwoo.methodB();                   // .... 2

const methodAA = chanwoo.methodA;
const methodBB = chanwoo.methodB;

methodAA();                           // .... 3
methodBB();                           // .... 4

생성자 함수의 메소드로, 인스턴스 chanwoo에 의해 호출되었습니다. 외부 함수인 methodA()의 this는 자신의 호출 객체 인스턴스 chanwoo에 바인딩 되었습니다.
1. 전역객체 window - 내부 함수의 this는 외부 함수의 this로 바인딩 되지 않고 전역객체에 바인딩 됩니다.
2. 인스턴스 chanwoo - 화살표 함수는 this가 렉시컬 스코프 상의 this를 참조하기 때문에 외부 함수의 this와 동일하게 됩니다.
생성자 함수의 메소드로, 인스턴스 chanwoo에 의해 호출되었습니다. methodB()는 화살표 함수로 선언되었기 때문에 렉시컬 스코프 상의 this를 참조합니다. 상위 스코프인 생성자 함수 내의 this는 새롭게 생성되는 인스턴스에 바인딩 되고, methodB()의 this 또한 인스턴스 chanwoo에 바인딩 되었습니다.
1. 전역객체 window - 내부 함수의 this는 외부 함수의 this로 바인딩 되지 않고 전역객체에 바인딩 됩니다.
2. 인스턴스 chanwoo - 화살표 함수의 this는 렉시컬 스코프 상의 this를 참조하기 때문에 외부 함수의 this와 동일하게 됩니다.
인스턴스 chanwoo의 메소드 methodA()를 새로운 함수로 선언하여 호출하였습니다. 호출객체가 명시되어있지 않기 때문에 methodA()의 this는 전역객체에 바인딩 됩니다.
1. 전역객체 window - 내부 함수의 this는 외부 함수의 this로 바인딩되지 않고 전역객체에 바인딩 됩니다.
2. 전역객체 window - 화살표 함수의 this 는 렉시컬 스코프 상의 this를 참조하기 때문에 외부 함수의 this와 동일하게 됩니다. methodA()의 this는 전역객체에 바인딩 되기 때문에 동일하게 전역 객체에 바인딩 됩니다.
인스턴스 chanwoo의 메소드 methodB()를 새로운 함수 methodBB()로 선언하여 호출하였습니다. methodB()는 화살표 함수이므로 호출 객체가 명시되어있지 않음에도 렉시컬 스코프의 this를 참조합니다. methodB()가 선언된 생성자 함수의 this는 인스턴스 chanwoo가 바인딩 되기 때문에 methodB() 또한 인스턴스 chanwoo를 참조합니다.
1. 전역객체 window - 내부 함수의 this는 외부 함수의 this로 바인딩 되지 않고 전역객체에 바인딩 됩니다.
2. 인스턴스 chanwoo - 화살표 함수의 this는 렉시컬 스코프 상의 this를 참조하기 때문에 외부 함수의 this와 동일하게 됩니다.

이외

이벤트 리스너의 경우, 이벤트가 등록되는 DOM element에 this가 바인딩됩니다.

document.addEventListener('click', function(){
    console.log(this);                 
})

그래서 this을 말하자면..

this는 함수 내에서 자신(함수)을 호출한 객체에 접근하기 위한 JS의 키워드입니다. 하지만 this가 호출 객체가 바인딩 되지 않는 경우도 존재합니다. 이러한 경우를 네 가지의 바인딩 룰을 통해 소개하였습니다.

this는 호출 객체에 바인딩 되지만 호출 객체가 명시되어있지 않는 경우, 전역 객체에 바인딩 됩니다.
내부 함수의 this는 외부함수의 this로 바인딩 되지 않습니다.
화살표 함수의 this는 렉시컬 스코프의 this를 참조합니다.
클래스의 내부 코드들은 'strict mode' 로 수행됩니다. 'strict mode' 에서는 전역 객체에 대한 바인딩이 수행되지 않기 때문에 this는 undefined가 됩니다.

이렇게 네 가지 규칙만으로도 this를 사용하는 대부분의 코드를 이해할 수 있을 것입니다. 추가로 바인딩을 명시적으로 하기 위해 제공하는 메소드들 소개하겠습니다.

+ this 바인딩 관련 메소드

this의 바인딩이 의도한 방향으로 되지 않는 경우가 있다고 설명하였습니다. 이를 피하고자 JS는 바인딩을 명시적으로 지정하는 메소드를 제공합니다. 이 this 바인딩 메소드들은 Function.prototype에 선언되어있기 때문에 모든 함수에서 사용이 가능합니다.

1. `bind(<object>)`

호출하는 함수의 this에 인자로 전달한 객체를 바인딩한 함수를 반환합니다.

4번 규칙의 3번 예시를 보면 메소드를 외부에서 사용하고자 할 때, 호출 객체에 명시되어있지 않아 this가 전역객체로 바인딩됩니다. 인스턴스를 바인딩하고자 할 때, 이 함수를 사용하여 this를 명시적으로 바인딩 합니다. 이때 함수의 호출이 아닌 함수의 선언임을 기억해야 합니다.

function Human() {
		this.methodA = function () {
			  console.log(this);              
		}
}

const chanwoo = new Human();

const methodAA = chanwoo.methodA;

methodAA();                               // .... 1                

const methodAAA = methodAA.bind(chanwoo);

methodAAA();                               // .... 2

전역객체 window - 내부 함수의 this는 외부 함수의 this로 바인딩되지 않고 전역객체에 바인딩됩니다.
인스턴스 chanwoo - bind()를 통해 명시적으로 chanwoo로 바인딩하였습니다.

2. `call(<object>, ...<params>)`

호출하는 함수의 this에 인자로 전달한 객체를 바인딩하여 함수를 수행합니다.

이미 할당되어있는 객체의 메소드를 다른 객체에 바인딩하여 호출하기 위해 사용합니다. 아래의 apply()와의 차이점은 함수 인자 전달 방식입니다. 바인딩할 객체 이후 모든 파라미터가 수행할 함수의 파라미터로 사용됩니다.

3. `apply(<object>, [<params>])`

호출하는 함수의 this에 인자로 전달한 객체를 바인딩하여 함수를 수행합니다.

이미 할당되어있는 객체의 메소드를 다른 객체에 바인딩하여 호출하기 위해 사용합니다. 아래의 apply()와의 차이점은 함수 인자 전달 방식입니다. 바인딩할 객체 이후 전달되는 배열이 수행할 함수의 파라미터로 사용됩니다.

function Human(name) {
  this.name = name;

  this.methodA = function() {
      console.log(this?.name);
  }

  this.methodB = function(age, gender) {
      console.log(`${this.name}, ${age}, ${gender}`);
  }
}

const chanwoo = new Human('chanwoo');
const chanjong = new Human('chanjong');

const methodBB = chanwoo.methodB;

// 함수 인자 전달
methodBB.call(chanjong, 26, 'man');

// 함수 인자 전달시, 배열을 통한 전달
methodBB.apply(chanjong, [26, 'man']);

call()을 통해 명시적으로 바인딩할 함수 methodBB의 인자는 바인딩 될 객체 이후에 인자로 전달합니다. 반면에 apply()의 경우, 인자를 배열로 전달합니다. 인자 전달 방법의 차이를 제외하고 명시적으로 this를 바인딩하여 함수를 수행하는 기능은 동일합니다.

JS의 기본 개념 1. 프로토타입

Fri, 05 Nov 2021 00:00:00 GMT

프로토 타입이란?

Prototype이란, '원형' 의 뜻을 가지며, 시스템의 미완성 버전 또는 중요한 가능들이 포함된 시스템의 초기모델을 의미한다.

JS에서는 모든 것이 객체입니다. 우리가 사용하는 배열이나 함수도 하나의 객체인데요. 우리가 정의하지 않았던 JS의 내장 함수들, 배열의 forEach(), includes()와 함수의 bind()와 같은 함수들은 우리가 정의하지 않아도 객체에 상속되어 사용할 수 있습니다. 이를 위해 JS는 Prototype, 즉 '객체의 원형' 을 정의하는 방식을 통해 객체가 가지는 특성이나 메소드의 상속을 구현합니다. Prototype을 이해하기 위해서는 반드시 '객체의 원형' 이라는 의미를 기억하는 것이 중요합니다. 이번 포스트에서는 JS가 Prototype을 통해 어떻게 상속을 구현할 수 있는지를 알아보고자 합니다. 본론으로 들어가기 전에 알아야 할 것이 하나 있습니다.

생성자 함수와 `new` 연산자를 통한 객체 생성과정

객체의 상속을 구현하기 전에 우리는 객체의 생성방법에 대해서 이해해야 합니다. 객체 생성과정에서 Prototype을 사용하기 때문입니다. 생성자 함수는 함수 내에서 this를 통해서 새롭게 생성할 객체의 형식을 정의하는 함수입니다. 생성자 함수로 객체의 형식을 정의했다면 new 연산자를 통해서 새로운 객체를 생성합니다.(여기서 생성자 함수는 일반적인 함수와 다를 것이 없지만, 클래스와 같이 함수명의 첫 글자를 대문자로 사용하는 관례가 존재합니다.) 객체 생성과정을 좀 더 세분화하면 아래의 순서를 가집니다.

새로운 객체를 생성하고 생성된 객체가 생성자 함수의 Prototype Object를 참조할 수 있도록 합니다.

구체적으로 표현하자면, 생성자 함수가 가지는 Prototype Object를 Prototype Link에 바인딩 된 새로운 객체를 생성합니다.
생성된 객체를 함수 내의 this로 바인딩하여 함수를 수행합니다. 이때, this를 통해 명시적으로 호출되는 프로퍼티와 메소드를 객체에 추가합니다.
함수의 수행이 완료되면 해당 객체를 반환합니다.

여기서 우리가 집중할 것은 첫 번째 과정입니다. Prototype이라는 단어가 가지는 '원형'이라는 의미에서처럼 JS는 객체에 필요한 프로퍼티와 메소드를 전달하기 위해 Prototype을 바인딩하는 작업이 가장 먼저 수행되고 있습니다. 그럼 이제 Prototype을 구성하는 두 개념 Prototype Object와 Prototype Link에 대해 알아보도록 하겠습니다. (두 번째 과정의 this는 다음 포스팅에서 설명하도록 하겠습니다.)

프로토타입의 구조

Prototype은 객체 자기 자신의 원형을 가리키는 Prototype Link, 자신을 통해 생성될 객체의 원형을 의미하는 Prototype Object로 구성되어있습니다. 이 두 가지 개념을 하나씩 살펴보겠습니다.

Prototype Object

함수가 가지는 프로퍼티로, 자신(함수)을 통해 생성되는 객체들의 원형 객체를 말한다. (자신의 원형이 아님, 이후에 생성될 객체들의 원형인 것을 주의하자!)

중요한 것은 이 객체가 '함수가 가지는 프로퍼티'라는 것입니다. Prototype Object는 생성자 함수를 통해 생성될 객체의 원형을 의미합니다. 객체를 생성할 수 있는 함수에서 사용되는 객체임을 기억해야 합니다. 위에서 생성자 함수를 통한 객체 생성 과정을 설명하였습니다. 그 과정에서 Prototype Object는 함수가 선언되는 시점에 함수와 함께 생성되고, 생성된 Prototype Object는 함수의 prototype 프로퍼티에 바인딩 됩니다.

function Human(name) {
		this.name = name;
}

위의 예제에서 이름 프로퍼티와 인스턴스의 이름을 출력하는 메소드를 가지는 객체의 생성자 함수 Human을 선언하였습니다. JS는 생성자 함수 Human를 선언하는 시점에 자신의 Prototype Object를 생성하고 prototype프로퍼티에 바인딩합니다. 아래는 결과를 그림으로 표현한 것입니다.

1. 아래 박스는 생성자 함수 `Human`입니다. 생성자 함수는 기본적으로 두 개의 프로퍼티를 가집니다.

prototype 프로퍼티

생성자 함수는 자신을 통해 생성될 객체의 원형, Prototype Object를 prototype 프로퍼티를 통해 참조하고 있습니다.
[[Prototype]] 프로퍼티

아래에서 설명할 Prototype Link를 의미하므로 추후 설명하도록 하겠습니다.

2. 위 박스는 생성자 함수 `Human`의 Prototype Object입니다.

객체의 원형이라는 의미는 곧 Human 함수를 통해 생성될 객체들이 사용할 수 있는 영역이라고 생각하면 되겠습니다. 모든 함수의 Prototype Object는 기본적으로 그림과 같이 두 개의 프로퍼티와 빈 슬롯{}을 가집니다. 구조를 하나씩 살펴보겠습니다.

constructor 프로퍼티

Prototype Object이 가지는 프로퍼티로, 자신을 사용하는 생성자 함수를 가리킨다.

해당 프로퍼티를 통해서 객체는 자신의 생성자 함수를 참조할 수 있습니다. 주로 생성자 함수가 가지는 static method를 사용하고자 할 때 사용하거나, 해당 객체와 동일한 생성자 함수를 통한 객체를 만들기 위함입니다.

[[Prototype]] 프로퍼티

모든 객체가 가지는 프로퍼티로, 객체 자신의 원형 객체인 Prototype Object를 가리킵니다.

가장 헷갈리는 부분 중의 하나가 Prototype Object의 [[Prototype]] 프로퍼티입니다. Prototype Object도 하나의 객체이기 때문에 [[Prototype]] 프로퍼티를 가집니다. 모든 Prototype Object의 [[Prototype]] 프로퍼티는 동일하게 Object의 Prototype Object를 가리킵니다. 즉, Prototype Object는 Object를 통해서 만들어진, 말 그대로 객체라는 의미가 됩니다. (모든 객체가 Object의 자손임을 의미합니다.) 그림으로 표현하면 아래와 같습니다.
- 위 그림에서 생성자 함수 Human, Animal 모두 Prototype Object를 가지며 Prototype Object들의 [[Prototype]] 프로퍼티는 함수가 다르더라도 동일하게 Object의 Prototype Object를 가리키고 있습니다.
- Object Prototype Object의 [[Prototype]] 프로퍼티는 null 값을 가집니다. [[Prototype]] 프로퍼티가 객체 자신의 원형객체인 Prototype Object를 가리킨다고 설명하였는데 Object Prototype Object는 자신의 원형객체가 존재하지 않으므로 null이 됩니다.

{}

Prototype을 통해 공유될 프로퍼티와 메소드가 들어갈 영역

생성자 함수의 Prototype Object이 가지는 프로퍼티와 메소드가 정의되는 영역입니다. 이후에 설명할 Prototype Link에 의해 모든 객체가 참조할 수 있으며, 생성자 함수의 prototype 프로퍼티를 통해서 추가할 수 있습니다.
```
function Human(name) {
    this.name = name;
}

 // 생성자 함수의 prototype 프로퍼티를 통해서 메소드를 추가하였다.
Human.prototype.printName = function () {
    console.log(this.name);
}
```

Prototype Link

모든 객체(함수 포함)가 가지는 프로퍼티로, 자신의 원형 Prototype Object을 참조하기 위해 사용되는 포인터이다.

모든 객체는 Prototype Link를 가지며, [[Prototype]] 프로퍼티를 통해서 구현됩니다. 이 프로퍼티는 자신의 원형 객체 즉, 객체 자신을 생성할 때 사용하였던 생성자 함수의 Prototype Object를 가리킵니다. 이 프로퍼티를 통해 객체는 생성자 함수의 Prototype Object가 가진 프로퍼티와 메소드를 사용할 수 있습니다. 생성자 함수 Human과 이 함수를 통해 생성되는 인스턴스 chanwoo 예제로 설명하도록 하겠습니다.

function Human(name) {
	  this.name = name;
}

// 생성자 함수의 prototype 프로퍼티를 통해서 메소드를 추가하였다.
Human.prototype.printName = function () {
  console.log(this.name);
}

const chanwoo = new Human('chanwoo');

인스턴스 chanwoo는 생성자 함수 Human을 사용하여 생성되었습니다. Prototype Link의 정의에 따라 chanwoo는 객체이기 때문에 [[Prototype]] 프로퍼티를 가지고 있습니다. 그림으로 표현하자면 아래와 같습니다.

[[Prototype]] 프로퍼티는 __proto__ 프로퍼티를 통해 접근할 수 있습니다. 하지만 최근에는 __proto__ 프로퍼티 대신 Object.getPrototypeOf(), Object의 정적 메소드를 사용하여 접근하도록 권장하고 있습니다.

인스턴스 chanwoo의 [[Prototype]] 프로퍼티는 객체 자신을 생성하기 위해 사용한 생성자 함수인 Human의 Prototype Object를 가리키고 있습니다.

생성자 함수 Human의 Prototype Object의 [[Prototype]] 프로퍼티는 Object의 Prototype Object를 가리킵니다. Object의 Prototype Object는 모든 Prototype Object의 원형이라는 의미를 가집니다.

Object의 Prototype Object의 [[Prototype]] 프로퍼티는 null 값을 가집니다. JS는 모든 것이 객체이며, 모든 객체의 원형이 Object의 Prototype Object이기 때문입니다. 가장 기본이 되는 원형이기 때문에 Object의 Prototype Object가 가진 [[Prototype]] 프로퍼티가 null 값을 가지게 됩니다.

그래서 Prototype Object, Prototype Link를 말하자면..

JS는 Prototype을 통해 객체 지향의 상속을 구현합니다. JS의 객체는 모두 자신의 원형이 존재합니다. 이 원형을 Prototype이라고 하는데요. Prototype은 Prototype Object와 Prototype Link로 구성되어있습니다.

Prototype Object는 함수 측의 구현으로, 생성자 함수를 통해 생성되는 인스턴스들의 원형 객체를 말합니다. 생성자 함수가 선언되는 시점에 해당 함수의 Prototype Object가 생성되며, 함수의 prototype 프로퍼티를 통해서 Prototype Object 내에 상속할 프로퍼티와 메소드를 선언할 수 있습니다.

Prototype Link는 객체 측의 구현으로, 객체 자신이 생성될 때 사용된 원형 객체, Prototype Object를 참조하고 있습니다. Prototype Link는 [[Prototype]] 프로퍼티에 저장되며, 모든 객체가 이 프로퍼티를 가지고 있습니다. 생성자 함수로 생성된 인스턴스의 경우, 함수가 가진 Prototype Object가 이 프로퍼티에 바인딩 되며, 이 프로퍼티를 통해 Prototype Object가 가진 프로퍼티와 메소드를 사용할 수 있습니다.

모든 Prototype Object는 인스턴스들이 참조할 수 있는 프로퍼티와 메소드가 저장될 슬롯과 두 프로퍼티를 가집니다. constructor 프로퍼티는 자신(Prototype Object)을 사용하여 인스턴스를 생성할 생성자 함수를 참조합니다. [[Prototype]] 프로퍼티는 자신의 원형 객체인 Object의 Prototype Object를 참조하고 있습니다. 그리고 아래에서 서술할 Prototype Chain에 의해 모든 객체는 Object의 Prototype Object가 가지는 모든 프로퍼티와 메소드에 접근할 수 있습니다.

Prototype Chain

Prototype Object과 Prototype Link로 구성된 Prototype을 통해 상속을 구현하는 방식이다. 포인터를 통해 선형적으로 참조하는 형식이 chain과 같은 모양이기에 Prototype Chain이라고 합니다.

모든 객체는 자신의 원형 객체 즉, Prototype Object를 참조할 수 있습니다. 이 Prototype Object에는 객체가 상속받을 프로퍼티와 메소드가 저장되어있고, Prototype Link을 통해 Prototype Object에 저장되어있는 프로퍼티와 메소드에 접근할 수 있습니다. Prototype을 통해 상속받는 프로퍼티와 메소드를 사용하는 동작 방식은 아래와 같습니다.

사용하고자 하는 프로퍼티와 메소드가 객체의 슬롯{}에 존재하는지 확인합니다.
현재 객체에 존재하지 않는다면, 객체의 Prototype Link를 통해 원형 객체인 Prototype Object에 접근합니다.
사용하고자 하는 프로퍼티와 메소드가 Prototype Object가 가진 슬롯에 존재하는지 확인합니다.
현재의 Prototype Object에 존재하지 않는다면, 이 Prototype Object의 객체로 간주하고 1~3번의 과정을 반복합니다.
Prototype Object를 접근하는 과정에서 객체의 Prototype Link가 null인 경우, 즉 Object의 Prototype Object인 경우 조회가 종료됩니다.

이렇게 Prototype을 통해 객체가 참조할 수 있는 프로퍼티와 메소드를 조회하는 과정에서 여러 개의 Prototype Object를 거친다고해서 Prototype Chain이라고 합니다. 위에서 사용하였던 예제와 예제의 Prototype 구조 그림을 통해 Prototype Chain을 설명해보도록 하겠습니다.

function Human(name) {
		this.name = name;
}

// 생성자 함수의 prototype 프로퍼티를 통해서 메소드를 추가하였다.
Human.prototype.printName = function () {
  console.log(this.name);
}

const chanwoo = new Human('chanwoo');

chanwoo.printName();                    // ----- A

chanwoo.hasOwnProperty('name');         // ----- B

chanwoo.printNickName();         // ----- C

인스턴스 chanwoo는 생성자 함수가 객체의 형식을 정의하였던대로 name 프로퍼티를 가집니다. name 프로퍼티는 인스턴스의 슬롯(1) 에 존재하고 있습니다. name 프로퍼티를 출력하는 메소드인 printName()을 모든 인스턴스에 선언하게 되면 동일한 함수임에도 인스턴스마다 선언되게 됩니다. 그래서 우리는 모든 인스턴스가 참조할 수 있는 영역인, 생성자 함수 Human의 Prototype Object 내부에 printName()을 선언하였습니다(3). 이후 인스턴스 chanwoo가 printName()을 호출한 상황입니다. 인스턴스가 이 함수를 사용하기 위해 Prototype을 사용하는 과정은 파란색 숫자 순입니다.

1. 먼저 위 코드에서 A, `chanwoo.printName()`을 수행하는 과정을 설명하겠습니다.

인스턴스 chanwoo의 슬롯에 printName()이 존재하는지 확인합니다. 이 슬롯은 인스턴스 각각의 영역으로, name 프로퍼티만 존재합니다.
Prototype Link를 통해 자신의 원형 객체인 Human의 Prototype Object에 접근합니다.
- 모든 객체가 Prototype Link, [[Prototype]]프로퍼티를 가지기 때문에 생성자 함수 Human으로 생성되는 모든 인스턴스가 Human의 Prototype Object에 접근이 가능합니다.
Human의 Prototype Object 내에 printName()이 존재하는지 확인합니다.
printName() 메소드가 존재하기 때문에 Prototype Link를 따라 더 조회하지 않고 해당 메소드를 수행합니다.

2. 다음은 B, `chanwoo.hasOwnProperty('name')`을 수행하는 과정을 설명하겠습니다.

1-3까지 위와 동일, printName() 대신, hasOwnProperty()로 바꿔서 이해하시면 되겠습니다.
Human의 Prototype Object 내에 존재하지 않으므로 Prototype Link에 따라 모든 Prototype Object의 원형인 Object의 Prototype Object에 접근합니다.
- Object의 Prototype Object 는 모든 Prototype Object가 Prototype Link로 참조하고 있기 때문에 모든 객체가 Object의 Prototype Object가 가진 프로퍼티와 메소드를 사용할 수 있습니다.
hasOwnProperty() 메소드가 존재하기 때문에 Prototype Link를 따라 더 조회하지 않고 해당 메소드를 수행합니다.

3. 마지막으로 C, `chanwoo.printNickName()`과 같이 Prototype Chain 상에 존재하지 않는 메소드를 호출하는 경우입니다.

1-4까지 위 과정과 동일합니다.
Object의 Prototype Object에 존재하지 않아 Prototype Link를 따라 Prototype Object에 접근합니다. 이때, Prototype Link가 null 값을 가리키고 있습니다. Prototype Chain의 끝에 도달하였기 때문에 에러를 반환합니다.

Prototype에서 주의할점

생성자 함수를 통해 인스턴스를 선언한 이후에 Prototype Object가 가진 프로퍼티와 메소드가 변경되더라도 Prototype Link를 통해 가리키고 있는 모든 인스턴스에게 변경이 반영됩니다.

생성자 함수를 통한 객체 생성과정을 설명하면서 인스턴스 생성 시점에 Prototype Object가 Prototype Link에 바인딩 된다고 설명하였습니다. 이때 중요한 것은 인스턴스 자신만의 Prototype Object가 생성되는 것이 아닌, Prototype Link를 통해 공통의 Prototype Object를 그저 참조만 하고 있다는 것입니다. Prototype Object 내의 변화가 존재하더라도 참조하고 있는 포인터 Prototype Link는 그대로이기 때문에 그 변화가 인스턴스의 생성 시점과는 무관하게 반영될 수 있는 것입니다.
```
function Human(name) {
    this.name = name;
}

    Human.prototype.greet = function () {
    console.log(`hi, ${this.name}`);          
}

const chanwoo = new Human('chanwoo');
const chanjong = new Human('chanjong');

chanwoo.greet();                       //  .... 1

// 인스턴스 생성 이후에 Prototype Object의 메소드를 변경하였다.
Human.prototype.greet = function () {
    console.log(`안녕, ${this.name}`);          
}

chanwoo.greet();                       //  .... 2
chanjong.greet();                      //  .... 3
```
동일한 이름의 프로퍼티와 메소드가 존재하더라도 Prototype Chain에서 우선적으로 조회되는 프로퍼티와 메소드를 사용합니다.

주의할 것은 참조하기 위한 Prototype Chain의 순서입니다. Prototype Chain은 Human 인스턴스의 슬롯 → Human Prototype Object → Object Prototype Object → null 의 순으로 참조하면서 사용하고자 하는 프로퍼티, 메소드를 조회합니다. 동일한 프로퍼티, 메소드가 슬롯마다 정의될 수 있지만 Prototype Chain의 순서상 앞의 슬롯에 정의된 프로퍼티와 메소드가 우선으로 호출됩니다.
```
function Human(name) {
	this.name = name;
	this.printName = function () {
	    console.log(`${this.name} by instance`);  // ------ 1
	}
}

// 생성자 함수의 prototype 프로퍼티를 통해서 메소드를 추가하였다.
Human.prototype.printName = function () {
    console.log(`${this.name} by proto`);          // ------ 2
}

const chanwoo = new Human('chanwoo');

chanwoo.printName();                                // ----- A
```
예시는 위의 예시에서 동일한 이름을 가진 printName() 메소드가 인스턴스에도 선언되어있는 것을 볼 수 있습니다. 즉, 위 그림에서 살색의 1번 영역과 3번 영역 모두 동일한 이름의 printName() 메소드가 선언된 상태입니다. 하지만 Prototype Chain의 순서상, 인스턴스의 슬롯인 1번을 먼저 조회하기 때문에 결과는 1번 줄이 수행됩니다. 이는 클래스의 메소드 오버라이딩의 개념과 동일하게 동작합니다.

객체 생성 방식에 따라 Prototype Link에 바인딩되는 Prototype Object가 다릅니다.
1. 생성자 함수와 new 연산자
  생성되는 객체의 Prototype Link는 생성자 함수의 Prototype Object가 바인딩됩니다.
2. {} object initializer notation
  생성되는 객체의 Prototype Link는 최상위 Prototype Object인 Object Prototype Object가 바인딩 됩니다.
3. Object.create(<proto>)
  생성되는 객체의 Prototype Link는 인자로 전달되는 *proto*에 바인딩됩니다.

그래서 Prototype Chain을 말하자면..

Prototype Object와 Prototype Link를 통해 프로퍼티와 메소드의 상속 방식을 정의하였다면, Prototype Chain은 상속된 프로퍼티와 메소드를 사용하는 방식이라고 볼 수 있습니다. 프로퍼티나 메소드가 자신의 슬롯에 존재하지 않는 경우, Prototype Link를 통해 자신의 원형 객체 Prototype Object에 접근하여 조회하는 방식이 선형적으로 수행되기 때문에 Prototype Chain이라고 부르게 되었습니다.

끝으로

JS의 객체에 대해 깊이 있게 다뤄보았습니다. 객체의 생성과정, 원형 객체 Prototype Object, 원형 객체 포인터 Prototype Link, 그리고 이 둘을 통해 상속받는 메소드와 프로퍼티를 조회하는 방식 Prototype Chain에 관해 설명하였습니다. 다음 포스팅은 객체 생성과정에서 나왔던 this에 관해 설명해보도록 하겠습니다.

MySQL의 엔진 InnoDB를 알아보자.(2/2)

Wed, 14 Jul 2021 00:00:00 GMT

InnoDB 주요 장점

동작을 수행하는 Commit, 동작 수행 이전 상태로 돌아가는 Rollback과 같은 Transaction 기능을 지원한다.
Row-level locking과 Consistent reads를 통해 다중 사용자 환경에서 동시 수행이 가능하다.
물리적 저장 기준인 PRIMARY KEY를 통한 Clustered index 기능을 제공한다.
데이터 무결성을 보장하기 위한 FOREIGN KEY 기능을 제공한다.

이번 포스팅은 지난 포스팅에 이어서 주요 장점 3, 4번에 대해 다룰 것입니다. 나머지 주요 장점들을 이해하기 위해서 먼저 Index와 Key에 대한 이해가 필요합니다. 그러므로 인덱스를 충분히 설명한 뒤에 장점들에 대해 다루도록 하겠습니다.

Index

데이터의 저장된 위치를 일련의 기준으로 정렬하여 저장한 자료구조를 의미합니다. 인덱스와 테이블의 관계는 아래의 그림과 같습니다.

현재 인덱스는 테이블의 첫 번째 컬럼을 기준으로 오름차순 정렬되어있는 것을 볼 수 있습니다. 테이블의 물리적인 저장 순서와는 다르게 인덱스로 지정한 컬럼들의 값을 기준으로 정렬되어있어 필요한 데이터를 빠르게 찾을 수 있도록 도와주는 역할을 수행합니다. 또한, 인덱스를 통해 테이블에 대한 제약조건을 정의할 수 있습니다. 예를 들어 UNIQUE, PRIMARY 인덱스를 정의함으로써 구성된 컬럼을 조건으로 사용한 조회에 대한 성능 향상뿐만 아니라 모든 행이 다른 값으로 삽입되도록 하는 제약 조건을 통해 데이터 무결성을 확보할 수 있습니다.

KEY
제약 조건을 정의하는 인덱스를 구성하는 컬럼들의 집합을 말합니다. 인덱스는 하나 이상의 컬럼을 통해 정의할 수 있으며, SQL문으로 특정 제약조건을 만족하는 컬럼을 키로 가지는 인덱스를 선언하여 제약조건을 정의할 수 있습니다.
```
ALTER TABLE index_test ADD CONSTRAINT <인덱스명> PRIMARY KEY (<컬럼명>);
```

인덱스를 사용하는 방식

InnoDB가 쿼리를 수행할 때 쿼리문의 조건에 사용할 수 있는 모든 인덱스를 찾습니다. 각 인덱스의 Cardinality에 따라 우선순위가 매겨지고, 가장 적은 행을 탐색할 수 있는 인덱스를 사용합니다. 하지만 인덱스로 정의된 컬럼을 조건으로 사용한다고 해서 모두 빠른 조회를 수행하는 것은 아닙니다. 특히 여러 개의 컬럼을 인덱스로 설정하였을 때, 인덱스를 사용하지 못하는 경우가 많은데요. 아래의 경우를 살펴봅시다.

다중 컬럼 인덱스

CREATE TABLE index_test (
	x INT NOT NULL, 
	y INT,
	z INT
	INDEX tidx (x, y, z)
) ENGINE = InnoDB;

INSERT INTO index_test VALUES (2, 3, 2), (4, 1, 3), (1, 2, 5), 
	(5, 2, 4), (3, 2, 1), (4, 3, 2);

여러 컬럼을 사용하여 인덱스를 정의할 수 있지만 지정하는 컬럼의 순서가 매우 중요합니다. 인덱스가 여러 개의 컬럼을 키로 가질 때, 각 컬럼을 독립적으로 고려하지 않고 하나의 값으로 간주하므로 모든 컬럼의 값들을 튜플 화(x, y, z)하여 정렬합니다. 이러한 방식으로 인해 위의 예제에서 tidx의 인덱스는 아래의 그림과 같이 정렬되어있습니다. (InnoDB의 인덱스는 B-Tree 구조로, 이처럼 단순한 배열 방식은 아니지만, leaf node는 아래의 그림과 같이 동일하게 정렬되어있기 때문에 이해를 돕기 위해 사용하였습니다.)

정렬 순서를 보면 컬럼 x의 값을 기준으로 먼저 정렬하고 이후에 y, z 컬럼 순의 기준으로 정렬되어있음을 볼 수 있습니다. 이러한 정렬 순서로 인해 2번째 데이터의 y 컬럼의 값이 3번째 데이터의 y 컬럼의 값보다 크지만, 순서상 앞에 있는 것을 볼 수 있습니다. 그렇다면 이제 이러한 인덱스의 정렬 순서가 조회 시에 어떠한 영향을 미치는지 살펴보겠습니다.

1. 인덱스의 첫번째 컬럼을 사용한 조회
```
EXPLAIN SELECT * FROM index_test WHERE x = 4;
# +---------------------------------------------------------+ 
# |      type     |           key         |      rows       |
# |----------------------------------------------------------
# |      ref      |          tidx         |        2        |
# +---------------------------------------------------------+
```
tidx 인덱스의 첫 번째 컬럼을 사용한 쿼리입니다. 해당 쿼리의 실행계획을 살펴보면, 인덱스를 사용하여 6개의 행 중에 2개의 행만 조회하여 결과를 반환한 것을 확인할 수 있습니다. x 컬럼의 순으로 정렬되어있기 때문에 배열상에서 빠르게 찾을 수 있었습니다.

2. 인덱스의 첫번째 컬럼을 사용하지 않은 조회
```
EXPLAIN SELECT * FROM index_test WHERE y = 2;
# +---------------------------------------------------------+ 
# |      type       |          key        |      rows       |
# |----------------------------------------------------------
# |      index      |         tidx        |        6        |
# +---------------------------------------------------------+
```
tidx 인덱스의 두 번째 컬럼만을 사용한 쿼리입니다. 실행 계획을 통해 해당 쿼리가 인덱스를 사용하였으나, 모든 행을 조회하여 결과를 반환한 것을 확인할 수 있습니다. 인덱스로 정의된 컬럼을 사용하였음에도 모든 행을 조회한 이유는 정렬 순서에 있습니다.

첫 번째 쿼리의 결과는 파란색 박스, 두 번째 쿼리의 결과는 빨간색 박스로 표현하였습니다. 첫 번째 컬럼을 사용한 쿼리의 결과는 순서상 연속된 범위에 존재하며, 이외의 순서에서는 값이 존재하지 않는 것을 보장할 수 있기 때문에 해당 범위 이전과 이후 순서에 대해 탐색할 필요가 없습니다. 하지만 첫 번째 컬럼을 사용하지 않은 쿼리의 경우, Y 컬럼의 값이 동일하더라도 X 컬럼의 값에 따라 우선 정렬되기 때문에 쿼리의 결과가 연속되지 않습니다. 이로 인해 첫 번째 컬럼을 사용하지 않은 쿼리는 모든 범위에 대해 탐색할 수밖에 없습니다. 이러한 컬럼 순서 기반 정렬은 (x, y)와 (x, z) 컬럼을 조건으로 사용하는 경우 또한 동일한 방식으로 조회 범위를 제한합니다.
```
# (x, y) 컬럼 사용
EXPLAIN SELECT * FROM index_test WHERE x = 4 AND y = 3;
# +---------------------------------------------------------+ 
# |      type     |           key         |      rows       |
# |----------------------------------------------------------
# |      ref      |          tidx         |        1        |
# +---------------------------------------------------------+

# (x, z) 컬럼 사용
EXPLAIN SELECT * FROM index_test WHERE x = 4 AND z = 2;
# +---------------------------------------------------------+ 
# |      type     |           key         |      rows       |
# |----------------------------------------------------------
# |      ref      |          tidx         |        2        |
# +---------------------------------------------------------+

# OR 조건 사용은 범위의 제한이 발생하지 않습니다.
SELECT * FROM index_test WHERE x = 4 OR y = 4;
# +---------------------------------------------------------+ 
# |      type       |          key        |      rows       |
# |----------------------------------------------------------
# |      index      |         tidx        |        6        |
# +---------------------------------------------------------+
```
추가로, 여러 컬럼의 집합으로 인덱스를 정의할 수 있지만 컬럼의 값을 인덱스로 저장하기 때문에 인덱스의 크기가 매우 커질 수 있습니다. 인덱스가 커지면 테이블의 크기 또한 커질 뿐만 아니라 성능 저하가 발생할 수 있습니다. 여러 컬럼의 값을 함께 사용하여 조회하는 경우, 여러 컬럼의 값을 사용하여 만든 해시값을 사용한 인덱스를 정의할 수 있습니다. 이럴 때, 단일 컬럼이며 해시값을 통해 인덱스의 크기를 줄일 수 있기 때문에 더 빠른 조회가 가능하게 됩니다.

인덱스 저장 구조

지금까지 인덱스를 표현한 그림에서는 단순히 정렬된 배열 형태로 표현되었지만, 실제로 InnoDB의 인덱스는 B-Tree 구조를 가집니다. 비교를 위해 Hash 구조의 인덱스에 대해서도 함께 설명합니다. 하지만 InnoDB는 Hash 구조의 인덱스는 지원하지 않습니다.

B-Tree

이진 트리를 확장해 하나의 노드가 가질 수 있는 자식 노드의 최대 숫자가 2보다 큰 트리 구조를 의미한다.

그림을 보면 이전에 인덱스를 설명한 것과 동일하게 B-Tree의 leaf node는 그 값들이 모두 정렬된 것을 볼 수 있습니다. 하지만 빠르게 조회의 범위를 좁혀나갈 수 있도록 중간 구분 값(또는 저장된 값)들을 부모 노드로 사용합니다. 이러한 트리 구조는 조회, 삽입, 삭제의 시간 복잡도를 log(N)에 수행할 수 있도록 합니다. 예를 들어 컬럼의 값 12를 인덱스를 사용하여 조회하는 것을 생각해봅시다.

인덱스로 정의된 컬럼을 조건으로 사용하기 때문에 루트 노드 (7, 16)에서 조회를 시작합니다.
조건의 컬럼값 12가 루트 노드에 존재하는지 확인합니다.
존재하지 않기 때문에 이후 X ≤ 7, 7 < X < 16, X ≥ 16의 범위에서 어디에 속하는지 확인합니다.
7 < X < 16의 범위에 존재하기 때문에 중간의 인덱스가 가리키고 있는 자식 노드로 이동합니다.
조건의 컬럼값 12가 자식 노드에 존재하는지 확인합니다.
존재하지 않기 때문에 X ≤ 9, 9 < X < 12, X ≥ 12의 범위에서 어디에 속하는지 확인합니다.
X ≥ 12의 범위에 속하고, 현재의 노드가 leaf node이기 때문에 해당 범위에서부터 순차적으로 탐색하여 12를 찾습니다.

이진 탐색 트리와 유사한 방식으로, 단일 값에 대한 조회뿐 만 아니라 범위를 조건으로 사용하는 조회에 대해서도 효율적입니다. $=$ , $>$ , $>=$ , $<$ , $<=$ , or BETWEEN 연산자에 대해 인덱스를 사용할 수 있습니다.또한 문자열 조회 시, LIKE 연산자는 범위에 대한 조회 방식을 사용하기 때문에 해당 연산자 또한 동일하게 인덱스를 사용할 수 있습니다.

Hash

'key- value' 형식의 해쉬 구조로 인덱스를 저장하여 사용합니다. 이러한 구조는 $=$ , $<=>$ 과 같은 동치 비교 연산에 대해 매우 빠르게 동작하지만, 이외의 비교 연산에 대해서는 인덱스가 사용되지 않습니다. 또한 여러 개의 컬럼으로 인덱스를 정의할 수 있지만 사용되는 컬럼의 값을 모두 사용하여 해시값을 만들기 때문에 반드시 정의된 모든 컬럼을 사용한 조회에서만 인덱스를 사용할 수 있습니다.

3. Clustered Index

PRIMARY Key(기본 키)의 Index를 의미합니다. Primary Index가 아닌 Clustered Index인 이유는 데이터의 물리적인 저장구조가 해당 인덱스를 기준으로 클러스터되어 저장되기 때문입니다. 실제로 InnoDB는 모든 테이블의 데이터를 해당 테이블의 Clustered Index를 기준으로 정렬하여 해당 인덱스를 통한 조회에 최적화되어 저장합니다. (이는 일반적인 인덱스의 역할과는 조금 다릅니다.) 그러므로 조회의 속도를 높이기 위해서는 Clustered Index를 설정하는 PRIMARY KEY를 자주 사용하는 트랜잭션의 유형에 따라 적절하게 설정하는 것이 중요합니다. 실제로 단순히 인덱스 설정만으로도 조회에 대한 성능을 크게 향상할 수 있습니다.

Clustered Index는 제약조건이라는 하나의 '개념'이기 때문에 직접 설정하는 것이 아닌 Primary Key에 의해 설정됩니다.
데이터를 삽입할 때, 인덱스에 대한 정보도 함께 저장해야 하기 때문에 삽입에 대한 성능은 (미비하게) 저하될 수 있습니다. 하지만 인덱스를 설정하여 오는 삽입의 성능 저하보다 조회의 속도 향상의 이점이 훨씬 높습니다.

PRIMARY KEY

'기본 키'는 Clustered Index를 구성하는 컬럼의 집합입니다. 기본 키는 PRIMARY의 제약조건을 만족해야 하는데, 제약조건은 아래와 같습니다.

기본 키의 컬럼들의 값은 모든 행을 구별할 수 있도록 유일한 값이어야 합니다. (UNIQUE INDEX)
여러 개의 컬럼으로 구성될 수 있으나, 구성되는 모든 컬럼은 NULL을 사용할 수 없다. (NOT NULL)

기본 키에 대한 추가적인 설명입니다.

1. 모든 테이블에 대해 기본 키를 반드시 정의해야합니다.

이는 Clustered Index를 통한 데이터의 저장구조를 정의하기 위함입니다. 기본 키의 조건을 만족하는 컬럼이 존재하지 않으면 AUTO INCREMENT 컬럼을 생성하여 사용하는 것이 일반적입니다. 물론 기본 키를 설정하지 않으면 내부적으로 유일 키 중에서 제약조건을 만족하는 컬럼을 사용하거나 아예 보이지 않는 기본 키를 생성하여 사용하기도 합니다.

2. 기본키를 컬럼의 갯수나 형식의 크기를 최소화하여 정의하는 것이 좋습니다.

InnoDB는 모든 보조 인덱스에 기본 키의 컬럼을 추가하여 사용합니다. 이러한 특성으로 인해 기본 키의 크기가 클수록 보조 인덱스 또한 그 크기가 커지게 됩니다. 인덱스가 커질수록 쿼리의 성능 저하가 발생할 수 있기 때문에 기본 키를 최소화하여 정의하는 것이 중요합니다. 아래의 예제를 통해 기본 키와 보조 인덱스의 수행방식을 설명해보도록 하겠습니다.
```
CREATE TABLE t1 (
i1 INT NOT NULL DEFAULT 0,
i2 INT NOT NULL DEFAULT 0,
i3 INT NOT NULL DEFAULT 0,
d DATE DEFAULT NULL,
PRIMARY KEY (i1, i2),
INDEX k_d (d)
) ENGINE = InnoDB;

INSERT INTO t1 VALUES 
    (1, 3, 10, '2021-07-13'),
    (1, 4, 10, '2021-07-13'),
    (6, 9, 11, '2021-07-13'),
    (2, 4, 12, '2021-07-14'),
    (3, 5, 12, '2021-07-11');

EXPLAIN SELECT * FROM t1 where d = '2021-07-13' and i1 = 1;
# +--------------------------------------------------------+ 
# |       type       |         key         |      rows     |
# |---------------------------------------------------------
# |   index_merge    |     k_d, PRIMARY    |        2      |
# +--------------------------------------------------------+

EXPLAIN SELECT * FROM t1 where d = '2021-07-13' and i3 = 10;
# +----------------------------------------------------+ 
# |     type   |     key     |   key_len  |    rows    |
# |-----------------------------------------------------
# |     ref    |     k_d     |      4     |      3     |
# +----------------------------------------------------+
```
k_d 인덱스의 키로 정의된 컬럼은 d뿐이지만, 기본 키의 컬럼과 인덱스의 컬럼을 함께 조건으로 사용하는 경우, 쿼리의 성능이 더 좋습니다. 반면에 기본키 컬럼을 조건으로 사용하지 않는 조회의 경우, k_d 인덱스만 사용합니다. 이 때, 인덱스의 길이인 key_len을 보면, 분명 k_d 인덱스의 키는 d컬럼으로, 인덱스 길이는 3(11일, 13일, 14일)이어야 합니다. 하지만 길이가 4인 것으로 볼 때, k_d 인덱스가 (d, i1, i2)를 키로 사용한 (d, i1)컬럼의 값인 (13, 1), (13, 6), (14, 2), (11, 3)으로 구성되어 있을 것으로 예상할 수 있습니다.

이외의 인덱스 종류

Secondary Index (보조 인덱스)

Clustered Index이외의 모든 인덱스를 말합니다.

UNIQUE INDEX

UNIQUE INDEX는 UNIQUE KEY(유일 키)를 통해 정의할 수 있으며 해당 인덱스는 모든 행을 구분할 수 있는 제약조건을 정의합니다. 제약조건은 아래와 같습니다.
- 유일 키의 컬럼들의 값은 모든 행을 구별할 수 있도록 유일한 값이어야 합니다. (UNIQUE INDEX)
- 단, NULL이 허용됩니다.
유일 키는 NOT NULL의 제약조건이 추가되는 경우, 기본 키가 될 수 있습니다.

4. FOREIGN KEY

외래키는 테이블 간의 데이터의 동일성 제약조건을 정의하기 위해 사용됩니다. 외래키의 제약조건은 자식 테이블에서 외래키로 설정된 컬럼들의 값이 반드시 부모 테이블의 컬럼의 값을 사용하도록 강제합니다. 이를 통해 부모 테이블과 자식 테이블 간의 데이터 동일성을 만족하게 됩니다. 제품 - 주문 - 고객 테이블 예제를 통해 알아보도록 하겠습니다.

CREATE TABLE product (
    category INT NOT NULL, id INT NOT NULL,
    price DECIMAL,
    PRIMARY KEY(category, id)
)   ENGINE=INNODB;

CREATE TABLE customer (
    id INT NOT NULL,
    PRIMARY KEY (id)
)   ENGINE=INNODB;

CREATE TABLE product_order (
    no INT NOT NULL AUTO_INCREMENT,
    product_category INT NOT NULL,
    product_id INT NOT NULL,
    customer_id INT NOT NULL,

    PRIMARY KEY(no),
    INDEX (product_category, product_id),
    INDEX (customer_id),
		
		# 외래키 정의
    FOREIGN KEY (product_category, product_id)
      REFERENCES product(category, id)
      ON UPDATE CASCADE ON DELETE RESTRICT,

    FOREIGN KEY (customer_id)
      REFERENCES customer(id)
)   ENGINE=INNODB;

위의 SQL문을 통해 테이블과 인덱스, 외래키까지 정의하였습니다. 테이블들의 관계를 ERD 다이어그램으로 그려보면 아래와 같이 그릴 수 있습니다.

그림에서 주문 테이블(product_order)와 상품 테이블(product) FK(1)의 표현을 보시면 1: N 관계임을 알 수 있습니다. 자식 테이블인 주문 테이블의 (product_category, product_id) 컬럼의 값은 반드시 부모 테이블인 상품 테이블의 (category, id) 컬럼에 동일한 값이 존재해야 합니다. 두 테이블 간의 관계는 두 가지를 보장하게 됩니다.

주문한 제품이 없는 주문은 존재하지 않습니다.
모든 주문은 회사가 취급하는 제품(제품 테이블에 존재하는 제품)에 대한 주문입니다.

이러한 추상적인 관계의 제약을 데이터베이스에 적용하기 위해 외래키를 사용하는 것입니다. 외래키는 주문이 진행되어 주문 테이블의 행 삽입 시마다 외래키를 통해 제품 테이블의 컬럼값을 확인하는 과정을 거칩니다. 이 과정에서 위의 두 관계를 만족시키지 못하는 경우에는 데이터의 동일성을 유지하기 위해 행이 삽입되지 않습니다. 이와 마찬가지로 주문한 고객이 없는 주문은 있을 수 없기 때문에 FK(2)에 의해 주문 테이블의 customer_id 컬럼의 값은 반드시 고객(customer) 테이블의 id 컬럼에 동일한 값이 존재해야 합니다.

여담으로, 제품 테이블의 기본 키를 (category, id) 순으로 사용하는 것으로 보아 제품 각각에 대한 조회보다 카테고리별 조회가 빈번하게 발생하는 경우라고 생각해볼 수 있겠습니다.

FOREIGN KEY 추가

ALTER TABLE child_tbl_name
    ADD [CONSTRAINT [symbol]] FOREIGN KEY
    [index_name] (col_name, ...)
    REFERENCES parent_tbl_name (col_name,...)
    [ON DELETE reference_option]
    [ON UPDATE reference_option]

reference_option:
    RESTRICT | CASCADE | SET NULL | NO ACTION | SET DEFAULT

외래키의 추가는 자식 테이블에서 정의합니다.(관계를 정의할 대상인 부모 테이블이 존재해야 하기 때문에 어찌 보면 당연합니다..)

CONSTRAINT [symbol] 의 경우, 외래키 제약조건의 이름을 정의하기 위해 사용하며 생략할 수 있으나 이름을 통해 제약조건의 의미를 바로 알아볼 수 있도록 생략하는 것을 피하는 것이 좋습니다.
reference_option 을 통해 제약조건에 의해 부모 테이블의 관계가 정의된 컬럼값의 수정, 삭제 시의 반영방식을 정의 할 수 있습니다.
1. CASCADE
  부모 테이블의 컬럼 값의 수정, 삭제가 자식 테이블의 컬럼에도 동일하게 반영됩니다.
2. SET NULL
  부모 테이블의 컬럼 값의 수정, 삭제시 자식 테이블의 컬럼 값은 NULL을 가집니다.
3. RESTRICT
  수정, 삭제 시 InnoDB의 default 옵션으로, 외래키로 정의된 부모 테이블의 컬럼의 수정, 삭제하지 못하도록 막습니다. NO ACTION 옵션도 같게 동작합니다.

사용시 장점

외래키의 사용이 성능에 대한 이점을 가져다주지는 않습니다. 오히려 삽입 시마다 부모 테이블에 대해 존재 여부를 확인하는 과정을 거쳐야 하기 때문에 성능상 손해라고 볼 수 있습니다. 두 테이블을 외래키를 통해 조인하는 경우, 성능상의 이점을 가진다고 볼 수 있겠지만 이것은 외래키의 사용이 아닌 외래키의 생성 조건에 해당하는 '부모 테이블의 외래키에는 인덱스가 존재하여야 한다'에 의한 것입니다. 조인된 테이블에 대한 조회 시 해당 인덱스를 사용하기 때문입니다. 하지만 테이블 간의 관계를 제약조건을 통해 데이터베이스가 데이터의 동일성을 유지함으로써 구현할 수 있고, 이는 곧 데이터 무결성을 보장한다고 할 수 있겠습니다.

사용시 유의사항

하지만 이러한 제약조건을 만족하기 위해서는 유의해야 하는 것들이 있습니다.

외래키로 정의된 부모 테이블의 컬럼과 자식 테이블의 컬럼은 동일한 형식을 사용합니다.
외래키로 정의된 부모 테이블의 컬럼은 반드시 인덱스가 필요합니다.
외래키 제약조건에 의해 자식 테이블의 행 삽입 시마다 부모 테이블의 외래키로 정의된 컬럼의 값에 대해 존재 여부를 확인해야 합니다. 이 과정을 테이블에 대한 조회가 아닌 인덱스를 사용한 조회를 통해 빠르게 수행하기 위해 외래키로 정의된 컬럼에 인덱스가 정의되어야 합니다. 부모 테이블에서 여러 컬럼을 외래키로 사용할 때도 동일하게 외래키로 정의된 맨 처음 컬럼에 대한 인덱스가 존재하여야 합니다.
파티셔닝된 테이블에 대해서는 외래키를 사용할 수 없습니다.
자식 테이블의 외래키 컬럼 값은 반드시 부모 테이블의 외래키 컬럼에 존재하여야 합니다.
매우 당연한 이야기처럼 들리지만, 지켜지지 않는 경우가 꽤 있습니다. 예를 들어, 앞의 예제에서 아래의 ERD 다이어그램과 같이 카테고리만 따로 모아두는 테이블이 생성되었다고 생각해봅시다.

새로운 카테고리의 제품을 판매하려는 상황을 가정합니다. 이때 카테고리 테이블에 새로운 카테고리 삽입과 제품 테이블에 대한 새로운 카테고리의 물품 삽입을 동시에 실행하려고 하게 되면 간혹 카테고리 테이블에 삽입이 되기 전에 제품 테이블 삽입이 진행되면서 제약조건에 의해 삽입되어야 할 제품들이 누락되는 경우가 발생할 수 있습니다. (생각보다 쉽게 발생할 수 있습니다..)외래키 제약조건의 사용을 고려할 때에는 반드시 부모 테이블에 대한 초기화가 선행되는 작업일 경우에만 사용하거나 동시에 작업이 수행되지 않도록 예외처리를 해둬야 합니다.

정리

이번 포스팅에서는 InnoDB의 3, 4번 장점에 관해 설명하였습니다. 저번 포스팅과 동일하게 기능 구현에서 적용할 수 있는 것들을 정리해보겠습니다.

3. Clustered Index

해당 테이블에서 빈번하게 사용되는 트랜잭션의 조회조건을 파악하여 적합한 기본 키를 설정합니다.
여러 개의 컬럼을 키로 사용하는 경우, 최소 조건이 되는 컬럼을 가장 빠른 순으로 정의합니다.

4. FOREIGN KEY

두 테이블 간 동일성이 유지되어야 하는 컬럼에 대해서 외래키를 사용합니다.
조인이 필요한 테이블에 조인 기준 컬럼을 외래키로 정의합니다.

참고자료

[1] 인덱스와 테이블의 구조 이미지 https://www.ibm.com/support/producthub/db2/docs.html

[2] 외래키 https://dev.mysql.com/doc/refman/5.6/en/create-table-foreign-keys.html

MySQL의 엔진 InnoDB를 알아보자.(1/2)

Tue, 13 Jul 2021 00:00:00 GMT

스타트업 지원사업을 통해 데이터베이스 설계 및 유지보수 컨설팅을 받은 적이 있습니다. 멘토님과 이야기를 나누면서 DBA는 기본적으로 MySQL, MariaDB의 기본 엔진인 InnoDB에 대해 알아야 한다고 조언해주셨습니다. 엔진의 동작 원리에 따라 최적화 및 유지보수가 가능하기 때문인데요. 그래서 이번 포스팅은 MySQL docs에서 소개하고 있는 InnoDB의 장점을 자세히 설명하면서 필요한 주변 개념들도 함께 정리하고자 합니다.

InnoDB 주요 장점

InnoDB는 MySQL 기본 저장 엔진입니다. MySQL docs에서 소개하고 있는 InnoDB의 주요 장점을 살펴보면,

동작을 수행하는 Commit, 동작 수행 이전 상태로 돌아가는 Rollback과 같은 Transaction 기능을 지원한다.
Row-level locking과 Consistent reads를 통해 다중 사용자 환경에서 동시 수행이 가능하다.
물리적 저장 기준인 PRIMARY KEY를 통한 Clustered index 기능을 제공한다.
데이터 무결성을 보장하기 위한 FOREIGN KEY 기능을 제공한다.

이외에도 여러 가지 기능을 제공하지만 이번 포스팅은 주요 장점 1, 2번에 대해 다룰 것입니다. 1번부터 하나씩 살펴보겠습니다.

1. Transaction 기능

Transaction(트랜잭션)이란, 데이터베이스에서 수행하는 작업의 가장 작은 단위를 말합니다. InnoDB는 모든 데이터베이스의 작업을 트랜잭션 단위로 묶어 수행하며, 트랜잭션이 ACID라고 불리는 특성을 만족할 수 있도록 기능을 제공합니다. ACID의 개념을 짧게 정리하면,

ACID

A : Atomicity (원자성)

트랜잭션의 작업은 분리될 수 없습니다. 만약 트랜잭션 내의 모두 작업이 수행되지 않으면 트랜잭션의 수행 이전 상태로 돌아가야 합니다.
C : Consistency (일관성)

트랜잭션의 작업 이전, 이후 모두 데이터베이스의 무결성 제약조건을 만족해야합니다.
I : Isolation (독립성)

트랜잭션이 동시에 수행될 때, 각 트랜잭션 간의 수행이 서로에게 영향을 주지 않고 독립적으로 수행하게 됩니다. 해당 특성은 자원 점유에 대한 문제로, 성능을 위해 격리 수준을 조절할 수 있습니다.
D : Durability(지속성)

데이터 베이스의 무결성 제약을 위해 트랜잭션의 결과는 영속적으로 반영되어야 합니다.

이러한 특성을 만족할 수 있도록 트랜잭션의 COMMIT, ROLLBACK 기능을 제공합니다.

// autocommit은 세션 내에서 지정할 수 있습니다.
SET autocommit = 0;

// autocommit mode에서도 트랜잭션을 명시하여 사용할 수 있습니다.
START TRANSACTION 
// 여러가지 SQL 문.
COMMIT

또한 SQL 쿼리문 각각이 하나의 트랜잭션으로 수행되는 autocommit mode를 제공합니다. 해당 모드에서는 사용자의 커넥션이 발생하였을 때, 새로운 세션을 시작하게 되고 각 쿼리문의 트랜잭션이 자동으로 커밋됩니다. 하지만 세션 내에서 트랜잭션의 에러가 발생하게 되면 해당 트랜잭션의 쿼리문의 수행이 ROLLBACK됩니다.

2. Consistent reads & Row-level locking

데이터베이스의 트랜잭션을 동시에 수행하기 위해서는 동일한 데이터를 동시에 조회하거나 수정/삭제하는 방식을 정의해야 합니다. 이러한 동시성 제어를 위해 Consistent reads와 Row-level locking를 사용합니다.

MVCC(Multi-Version Concurrency Control) 다중 버전 동시성 제어

기본적으로 InnoDB는 여러 시점에 버저닝된 스냅샷을 통해 동시성 제어를 수행합니다. 스냅샷이란, 특정 시점의 데이터의 상태를 말합니다. 데이터를 조회하는 시점에 해당 데이터의 현재 상태를 미리 저장하여 두고 작업을 수행하는 방식으로, 여러 트랜잭션이 동시에 수행되더라도 각각 특정 시점의 데이터 상태를 기준으로 수정/삭제하기 때문에 동시성 제어가 가능하게 됩니다. 이후 각 스냅샷들 간의 변경을 데이터베이스에 반영하는 과정이 내부적으로 이루어집니다. 하지만 문제는 트랜잭션 내에서 여러번의 조회가 발생하는 경우입니다. 설명을 위해 MySQL docs의 예제를 가져왔습니다.

               Session A              Session B

           SET autocommit=0;      SET autocommit=0;
time
|          SELECT * FROM t;
|          #empty set
|                                 INSERT INTO t VALUES (1, 2);
|
v          SELECT * FROM t;
           #empty set
                                  COMMIT;

           SELECT * FROM t;
           # (X)

           COMMIT;

           SELECT * FROM t;
		    # (Y)

예제는 두 개의 세션이 동일한 데이터에 대한 트랜잭션을 수행하고 있습니다. 세션 A가 3번째로 조회하는 시점에 세션 B가 트랜잭션이 COMMIT됨에 따라 데이터베이스에 반영되었습니다. 세션 A에서 3번째 조회 결과인 (X)는 두 가지가 될 수 있습니다.

트랜잭션 내부에서 사용되는 데이터베이스의 상태인 'empty set' → Repeatable Read
세션 B가 수행한 트랜잭션이 반영된 현재 데이터베이스의 상태인 (1, 2) → READ COMMITTED

이러한 단일 트랜잭션 내의 여러 번의 조회 결과를 정의하는 방식을 isolation level(격리 수준)로 정할 수 있는데요. 두 격리 수준에서 동시성 제어는 어떻게 이루어지는지 확인해보겠습니다.

Repeatable Read

innoDB의 격리 수준 중에서 기본설정에 해당하는 수준입니다. 번역하면 '반복 가능한 읽기'인데, 말 그대로 동일 트랜잭션 내에서는 동일한 상태를 반복적으로 읽을 수 있다는 것입니다.

1) Consistent read

트랜잭션 내에서 모든 작업은 최초로 읽은 데이터로 구성된 스냅샷을 사용하며, 트랜잭션이 커밋된 이후에만 새로운 스냅샷을 생성하여 사용합니다. 이를 통해 동일 트랜잭션에서의 모든 조회가 동일한 스냅샷을 보기 때문에 반복적인 읽기가 가능하게 됩니다. 그러므로 트랜잭션 내에서 여러 번의 조회를 수행하더라도 다른 트랜잭션이 삽입, 수정, 삭제한 작업의 결과가 데이터에 반영되지 않습니다. 위의 예제에서는 세션 A의 스냅샷을 사용하고 있기 때문에 세 번째 조회 결과 (X) 또한 세션 B의 수정이 반영되지 않은 'empty set'이 반환됩니다.

트랜잭션의 시작 시점이 아닌 최초 SELECT 문을 통한 조회 시점에 스냅샷이 생성됩니다.
그러므로 최초의 SELECT 문을 수행하기 전 커밋된 다른 트랜잭션의 데이터 수정이 스냅샷에 반영됩니다.

2) Row-level locking

해당 격리 수준에서는 UPDATE, DELETE문을 위한 조회(수정하거나 삭제할 대상을 위한 조회)를 수행할 때 조회하는 조건 방식에 따라 다른 수정 / 삭제 작업인 UPDATE, DELETE문에 대한 잠금이 발생합니다. 모든 잠금은 트랜잭션이 커밋되는 시점에 해제됩니다.

UNIQUE Index를 사용할 수 있는 단일 값에 대한 조건을 가진 쿼리에 대해서는 해당 행에 대한 lock을 수행합니다.(Row-level locking)
쿼리문의 대상이 된 행에 대한 lock으로 인해 동시에 수정 / 삭제 작업이 수행되지 못하고 해제될 때까지 지연됩니다.
이외에 방식의 조건의 경우, 조회에 사용된 모든 범위에 대한 lock을 수행합니다.(Gap locking)
조회 범위에 해당하는 행에 대한 잠금으로 인해 동시에 수정 / 삭제 작업이 수행되지 못하고 해제될 때까지 지연됩니다.

READ COMMITTED

격리 수준 중, Repeatable Read 다음 수준으로, 조회를 수행하는 시점에 커밋된 것을 읽는다는 것을 의미합니다.

1) Consistent read

조회 시점마다 새로운 스냅샷을 찍기 때문에 동일 트랜잭션 내에서도 다른 트랜잭션의 수정이 반영된 데이터를 조회할 수 있게 됩니다. 위의 예제에서 매번 조회시마다 해당 시점의 최신 데이터로 스냅샷을 생성합니다. 세번째 조회 시점에는 이전에 커밋된 세션 B의 결과가 반영된 결과인 (1, 2) 행이 결과로 반환됩니다.

2) Row-level locking

Repeatable Read 격리 수준과 동일하게 UPDATE, DELETE문을 위한 조회(수정하거나 삭제할 대상을 위한 조회)를 수행할 때 조회하는 조건 방식에 따라 다른 수정 / 삭제 작업인 UPDATE, DELETE문에 대한 잠금이 발생합니다. 모든 잠금은 트랜잭션이 커밋되는 시점에 해제됩니다.

하지만 다른 점은 조회 범위에 대한 잠금이 아닌 수정을 수행할 행에 대해서만 잠금이 발생하게 됩니다.(Row-level locking)
조건으로 사용되지 않은 행에 대해서는 lock이 존재하지 않기 때문에 다른 트랜잭션의 UPDATE, DELETE가 수행되어 값이 즉시 반영되지만, 조건으로 사용된 행에 대해서는 lock이 해제되고 난 후에 수행됩니다. 이러한 잠금 방식은 동시성을 높이고 교착 상태를 피할 수 있게 합니다. 하지만 Phantom Rows가 발생할 수 있습니다. Phantom Rows에 대한 설명은 해당 링크를 참고하세요.

+) 격리 수준별 Row-level Locking

각 격리 수준의 행 수준의 잠금 차이를 이해하기 위해 MySQL doc의 예제를 설명하고자 합니다.

1. 인덱스를 사용하지 않는 UPDATE / DELETE
```
CREATE TABLE t (a INT NOT NULL, b INT) ENGINE = InnoDB;
INSERT INTO t VALUES (1,2),(2,3),(3,2),(4,3),(5,2);
COMMIT;

# Session A
START TRANSACTION;
UPDATE t SET b = 5 WHERE b = 3;

# Session B
UPDATE t SET b = 4 WHERE b = 2;


EXPLAIN UPDATE t SET b = 5 WHERE b = 3;
# +------------------------------+ 
# |      type     |      rows    |
# |-------------------------------
# |       ALL     |       5      |
# +------------------------------+
```
  예제에는 인덱스를 정의하지 않은 테이블 t가 존재합니다. 세션 A 쿼리문의 실행계획를 통해 조회한 행의 수는 5개로, 수정 작업을 위해 모든 행에 대한 조회가 발생했다는 것을 알 수 있습니다. 세션 A의 트랜잭션 수정 작업이 커밋되지 않은 시점에 동시에 세션 B의 수정 작업을 수행하고자 하는 상황입니다. 각 격리 수준에 따라 수행 결과를 설명해보겠습니다.

Repeatable Read

  세션 A 쿼리문의 실행계획에서처럼 수정 작업의 조건을 만족하는 행을 찾기 위해서 모든 행을 조회하였습니다. 이때, 트랜잭션이 커밋되지 않았기 때문에 조회를 사용한 모든 행에 대한 잠금이 발생합니다. 이전 세션 A의 모든 행에 대한 잠금으로 인해 세션 B의 업데이트는 세션 A의 트랜잭션이 커밋될 때까지 지연됩니다.

READ COMMITTED

  해당 격리 수준에서는 수정 작업의 조건을 만족하는 행을 찾기 위해서 조회한 행이 아닌 실제 수정 작업을 수행하는 행에 대해서만 잠금이 발생합니다. 세션 A를 통해서 UPDATE하지 않은 행 (1, 2) (5, 2)에 대한 잠금이 발생하지 않으므로, 세션 A의 트랜잭션이 커밋되지 않았음에도 세션 B의 수정이 즉시 이루어질 수 있습니다.

2. 인덱스를 사용하는 UPDATE / DELETE
```
CREATE TABLE t (a INT NOT NULL, b INT, c INT, INDEX (b)) ENGINE = InnoDB;
INSERT INTO t VALUES (1,2,3),(2,2,4);
COMMIT;

# Session A
START TRANSACTION;
UPDATE t SET b = 3 WHERE b = 2 AND c = 3;

# Session B
UPDATE t SET b = 4 WHERE b = 2 AND c = 4;


EXPLAIN UPDATE t SET b = 5 WHERE b = 3;
# +---------------------------------------------------------+ 
# |      type     |      possible_keys    |      rows       |
# |----------------------------------------------------------
# |     range     |            b          |        1        |
# +---------------------------------------------------------+
```
Repeatable Read, READ COMMITTED
인덱스를 사용하는 경우, 두 격리 수준 모두 수정 작업을 수행하는 행에 대해서만 잠금이 발생합니다. 사실, Repeatable Read 수준에서는 작업을 수행하는 행에 대한 잠금이 발생한다고 해석하는 것보다는 수정 작업의 조건을 만족하는 행을 찾기 위한 조회가 Unique Index로 인해 작업을 수행하는 행에 대해서만 조회가 발생하고, 조회된 행에 대한 잠금이 발생한다고 보는 것이 맞습니다. 실제 Index가 존재할 때 세션 A의 UPDATE문의 실행계획을 보면 인덱스 b를 사용하여 1개의 행에 대한 조회가 발생한 것을 확인할 수 있습니다.

정리

이번 포스팅에서는 InnoDB의 1, 2번 장점에 관해 설명하였습니다. 장점에 대해 아는 것도 중요하지만 각 장점을 충분히 활용할 수 있도록 기능 구현에서 적용할 수 있는 것들을 정리해보겠습니다.

1. Transaction 기능

반드시 함께 수행되어야 하는 쿼리들에 대해서는 트랜잭션으로 묶어서 사용하도록 합니다. 예를 들어 송금에 대한 기능 구현 시, A의 계좌에서 송금할 금액 차감, B의 계좌에 송금된 금액 가산, A에서 B로 송금한 로그 기록 등 하나라도 누락되어서는 안 되는 일련의 작업을 하나의 트랜잭션화하여 일관된 데이터 삽입이 가능하도록 구현합니다.
트랜잭션 화 하여 수행하는 경우, 트랜잭션을 구성하는 작업 중 하나라도 에러를 반환하면, 해당 트랜잭션이 ROLLBACK되기 때문에 반드시 수행되지 않는 경우에 대해 에러 핸들링이 고려하여야 합니다.

2. Row-level locking과 Consistent reads를 통해 다중 사용자 환경에 대한 동시성 제어

수정 및 삭제 작업 시에 조회 조건을 인덱스를 기준으로 사용하여 행별 잠금으로 수행하도록 합니다. 이를 통해 해당 작업을 수행하지 않는 행에 대해서는 동시에 접근할 수 있도록 합니다.

다음 포스팅에서는 InnoDB의 나머지 3, 4번 장점에 관해 설명하도록 하겠습니다.

MySQL에서 날짜 및 시간 문자열 저장하기

Tue, 06 Jul 2021 00:00:00 GMT

지난 포스팅을 통해 JS에서 날짜 및 시간 데이터를 전달할 문자열은 ISO 8601 형식에 맞춰 사용하기로 하였다. 이제 이 문자열을 데이터베이스에 저장하고자 한다. 하지만 MySQL에서 사용할 수 있는 날짜 및 시간 데이터의 저장 형식은 5가지나 될뿐더러 각 형식에서 사용할 수 있는 문자열의 형식과 ISO 8601의 형식이 다르기 때문에 그대로 사용하기 어렵다. ISO 8601 형식의 문자열에 적합한 저장 형식을 고려하면서 이번 기회에 항상 헷갈렸던 MySQL의 날짜 및 시간 데이터 저장방식을 정리해보았다. **관계형 데이터베이스의 데이터를 다루기 위해서 데이터베이스 관리 시스템(DBMS)을 사용하는데 그 중, MySQL을 기준으로 설명한다.

MySQL의 날짜 및 시간 데이터 형식 (Data Type)

MySQL은 날짜 및 시간 데이터를 5가지의 형식으로 저장한다. 각 형식에 대한 차이와 사용 가능한 문자열을 설명하고자 한다. (숫자를 통한 표현도 가능하지만 여기서는 문자열 형식에 집중하였다.)기본 예제는 '2020-03-20 03:30:58'을 사용한다.

예제환경

각 날짜 및 시간 데이터의 형식을 테스트하기 위해 각 형식의 컬럼을 가진 테이블을 생성하였다. 테이블의 DDL과 생성된 테이블의 컬럼을 아래에 제시하였다.

DROP TABLE  IF EXISTS `type_test`;

CREATE TABLE `type_test` (
  `mytimestamp` timestamp,
  `mydate` date,
  `mytime` time,
  `mydatetime` datetime,
  `myyear` year
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

DATE

날짜 정보를 저장한다. 사용 가능한 형식은 두 가지이다. 반드시 날짜의 의미를 가진 숫자를 사용해야 한다.

1. 'YYYY-MM-DD' 의 형식

구분자를 사용한 년 - 월 - 일 데이터 형식이다. 아래와 같은 특징을 가진다.

구분자 '-'에 대신 다른 특수 문자로 대체가 가능하다.
년 / 월 / 일의 숫자 모두 날짜의 의미를 지니는 숫자여야 한다. 각각의 유효 범위는 아래와 같다.

(년 / 월 / 일 모두 0은 포함되지 않는다.)
- 'YYYY'의 유효 범위는 [0001, 9999]
- 'MM'의 유효 범위는 [01, 12]
- 'DD'의 유효 범위는 [01, 31]

# OK!
INSERT INTO `type_test` (mydate) VALUES ('2020-03-20');

# OK!
INSERT INTO `type_test` (mydate) VALUES ('2020%03%21');
INSERT INTO `type_test` (mydate) VALUES ('2021~03~22');

# Incorrect date value: '2020-03-32' for column 'mydate' at row 1
# 32일은 날짜의 의미를 가지지 못한다.
INSERT INTO `type_test` (mydate) VALUES ('2020-03-32');

# Incorrect date value: '2020-13-01' for column 'mydate' at row 1
# 13월은 날짜의 의미를 가지지 못한다.
INSERT INTO `type_test` (mydate) VALUES ('2020-13-01');

#Incorrect date value: '2020-01-00' for column 'mydate' at row 1
# 년 / 월 / 일 모두 0은 사용이 불가능하다.
INSERT INTO `type_test` (mydate) VALUES ('2020-01-00');

2. 구분자가 생략된 'YYYYMMDD' 형식

위의 형식에서 구분자가 생략된 형식이다. 구분자를 사용하지 않기 때문에 문자열의 길이를 줄일 수 있으나 자릿 수에 따라 시간적 의미가 달라질 수 있으므로 주의하여야 한다.

# OK!
INSERT INTO `type_test` (mydate) VALUES ('20210320');

# Incorrect date value: '20201301' for column 'mydate' at row 1
# 13월은 날짜의 의미를 가지지 못한다.
INSERT INTO `type_test` (mydate) VALUES ('20201301');

# 2069-03-20이 저장된다.
INSERT INTO `type_test` (mydate) VALUES ('690320');

# 1970-03-20이 저장된다.
INSERT INTO `type_test` (mydate) VALUES ('700320');

네 자리 표현 'YYYY'으로 사용된 년도를 두 자리 표현 'YY' 이 사용 가능하다
두 자리 표현은 표현 범위의 제약으로 필자는 사용하지 않는다. 사용하려면 표현 범위 제약 조건에 대해 올바르게 이해하고 사용하자.

TIME

시간 정보를 저장한다. 여러 가지 형식이 존재하지만, 기본적인 형식만 설명하고 이외의 형식은 예제로 소개만 하였다. DATE와 동일하게 반드시 시간의 의미를 가진 숫자를 사용해야 한다.

1. 기본적인 시,분,초로 구성된 'hh:mm:ss' 형식

구분자를 사용한 시:분:초 데이터 형식이다. 아래와 같은 특징을 가진다.

시 / 분 / 초 각각의 유효 범위는 아래와 같다.
- 'hh'의 유효 범위는 [00, 23]
- 'mm'의 유효 범위는 [00, 60]
- 'ss'의 유효 범위는 [00, 60]
기본 형식 'hh:mm:ss'에서 일의 수인 'D'를 추가하여 'D hh:mm:ss'를 사용할 수 있다.
'D'는 [0, 34] 사이의 값을 가지며, 1일당 24시간씩 더해져서 TIME 형식으로 저장된다.
위의 예제에서는 4일이므로 24*4인 96시간이 더해져 99시간으로 저장된다.
부분 형식 또한 사용이 가능하다.
그중 하나인 'hh:mm' 형식을 예제에서 확인할 수 있다.

# 'hh:mm:ss' 형식, OK!
INSERT INTO `type_test` (mytime) VALUES ('03:30:58');

# Incorrect time value: '03:60:58' for column 'mytime' at row 1
INSERT INTO `type_test` (mytime) VALUES ('03:60:58');

# 'D hh:mm:ss' 형식, OK! '99:30:58'의 값을 가짐.
INSERT INTO `type_test` (mytime) VALUES ('4 03:30:58');

# 'hh:mm' 형식, OK! '03:30:00'의 값을 가짐.
INSERT INTO `type_test` (mytime) VALUES ('03:30');

2. 구분자가 존재하지 않는 'hhmmss' 형식

예제에서처럼 구분자가 존재하지 않는 문자열의 경우, 자릿수가 증가할수록 인식하는 형식이 달라지기 때문에 주의하여야 한다.

# 'hhmmss' 형식, OK! '03:30:58'의 값을 가짐.
INSERT INTO `type_test` (mytime) VALUES ('033058');

# 'mmss' 형식, OK! '00:03:30'의 값을 가짐.
INSERT INTO `type_test` (mytime) VALUES ('0330');

# 'ss' 형식, OK! '00:00:08'의 값을 가짐.
INSERT INTO `type_test` (mytime) VALUES ('8');

# 'ss' 형식, Incorrect time value: '80' for column 'mytime' at row 1
INSERT INTO `type_test` (mytime) VALUES ('80');

# 'mmss' 형식, OK! '00:08:00'의 값을 가짐.
INSERT INTO `type_test` (mytime) VALUES ('800');

# 'mmss' 형식, Incorrect time value: '8000' for column 'mytime' at row 1
INSERT INTO `type_test` (mytime) VALUES ('8000');

# 'hhmmss' 형식, OK! '08:00:00'의 값을 가짐.
INSERT INTO `type_test` (mytime) VALUES ('80000');

** TIME 형식의 경우, 정밀도를 위해 소수 초를 지원한다. 'hh:mm:ss.fraction' 의 형식으로 최대 6자리까지의 소수를 지원하며 소수 초을 사용하기 위해서는 TIME 형식을 선언할 때, DATE(6) 과 같이 자릿수를 명시한다.

DATETIME

날짜 및 시간 정보를 저장한다. 위의 DATE 형식과 TIME 형식을 함께 사용한 '<DATE>T<TIME>'의 형식을 사용한다.

날짜와 시간을 'T'를 통해 구분하며, 구분자 대신 공백을 사용할 수 있다. '<DATE> <TIME>'
<DATE>는 위의 DATE 형식의 설명과, <TIME>는 위의 TIME 형식의 설명과 동일하다.
1. 년 / 월 / 일 / 시 / 분 / 초 모두 각 날짜와 시간의 의미를 가지는 유효 범위 내에 존재하여야 한다.
2. 'YYYY-MM-DD hh:mm:ss', 'YYYYMMDDhhmmss', 'YYYYMMDDThhmmss' 의 형식이 사용가 능하다. (하지만 'YYYYMMDD hhmmss' 의 형식은 불가능하다.)
3. TIME 형식과 동일하게 소수 초를 지원하며 소수 초을 사용하기 위해서는 TIME 형식을 선언할 때, DATETIME(6)와 같이 자릿수를 명시한다.
오프셋의 명시가 가능하다.

명시된 오프셋이 계산된 '2020-03-20 11:30:58'이 저장된다. TIMESTAMP 형식과 동일하게 시간대를 반영하여 저장되는데, 아래의 TIMESTAMP 형식의 설명을 통해 이해할 수 있다.
위의 설명을 통해 DATETIME 형식에는 우리가 사용하고자 했던 '2020-03-20T03:30:58Z'은 삽입이 불가능하다는 것을 알 수 있다.

# 'YYYY-MM-DDThh:mm:ss' 형식, '2020-03-20 03:30:58'
INSERT INTO `type_test` (mydatetime) VALUES ('2020-03-20T03:30:58');

# 'YYYY-MM-DD hh:mm:ss' 형식, '2020-03-20 03:30:58'
INSERT INTO `type_test` (mydatetime) VALUES ('2020-03-20 03:30:58');

# ISO 8601 형식, Data truncation: Incorrect datetime value
INSERT INTO `type_test` (mydatetime) VALUES ('2020-03-20T03:30:58Z');

# 'YYYYMMDDThhmmss' 형식, '2020-03-20 03:30:58'
INSERT INTO `type_test` (mydatetime) VALUES ('20200320T033058');

# 'YYYYMMDD hhmmss' 형식, '2020-03-20 03:30:58'
INSERT INTO `type_test` (mydatetime) VALUES ('20200320 033058');

# 오프셋 명시 형식,  '2020-03-20 11:30:58'
INSERT INTO `type_test` (mydatetime) VALUES ('2020-03-20T03:30:58+01:00');

TIMESTAMP

DATETIME과 동일하게 날짜 및 시간 정보를 저장하며 사용할 수 있는 문자열 형식 또한 <DATE>T<TIME> , <DATE> <TIME>으로 동일하다. 하지만 중요한 두 가지 차이점이 존재한다.

1. 시간 의미의 차이

전달되는 날짜 및 시간 문자열을 그대로 저장하는 DATETIME와 달리 TIMESTAMP 형식은 UTC 시간으로의 변환을 거친 뒤 저장한다. 이러한 변환 과정이 두 형식의 차이를 만드는데, 변환 과정을 '2020-03-20 03:30:58'로 예를 들어 설명한다.

데이터베이스의 환경변수로 설정된 time_zone(시간대)을 통해 해당 지역의 오프셋을 정의한다.
- 아래의 코드를 통해 현재 데이터베이스가 사용하는 시간대를 확인할 수 있다.
```
SELECT @@time_zone; // SYSTEM
SELECT @@system_time_zone; //KST
```
- @@time_zone 은 MySQL이 사용하는 시간대로, 'SYSYEM'의 값은 현재 시간대가 설정되지 않았으며, MySQL을 실행하는 OS의 시간대를 사용한다는 의미를 가진다. SET @@time_zone = '+1'; 와 같이 SET을 통해 특정 시간대를 설정할 수 있다.
- @@system_time_zone은 MySQL을 실행하는 OS의 시간대를 의미한다.
날짜 및 시간 데이터를 정의된 오프셋을 사용하여 UTC 시간으로 변환하여 저장한다.

현재 데이터베이스가 사용하는 시간대가 'KST'이므로 오프셋은 '+9'이다.
내부적으로는 '2020-03-20 03:30:58'으로 저장하는 것이 아닌,
오프셋을 반대로 연산하여 변환된 UTC 시간인 '2020-03-19 18:30:58'UTC 로 저장된다.
조회 시에 현재 데이터베이스의 오프셋을 사용하여 UTC 시간으로 저장되어있는 날짜 및 시간 데이터를 지역 시간으로 바꿔 반환한다.

TIMESTAMP 형식은 데이터 조회시마다 내부 변환 과정을 거친 데이터를 보여주기 때문에 일반적으로 DATETIME과 차이가 나지 않는다. 하지만 행 추가 시점과 조회 시점의 시간대가 변경되는 경우에 그 차이가 나타난다. 아래 코드의 결과를 통해 이해해보자.
```
DELETE FROM type_test;

// SYSTEM = KST = '+09:00'
SELECT @@time_zone; 

INSERT INTO type_test(mydatetime, mytimestamp) 
VALUES ('2020-03-20 03:30:58', '2020-03-20 03:30:58');

SELECT mydatetime, mytimestamp FROM type_test;
# +-------------------------------------------+
# |      mydatetime     |      mytimestamp    |
# |-------------------------------------------|
# | 2020-03-20 03:30:58 | 2020-03-20 03:30:58 |
# +-------------------------------------------+

SET @@time_zone = '+01:00';

SELECT mydatetime, mytimestamp FROM type_test;
# +-------------------------------------------+
# |      mydatetime     |      mytimestamp    |
# |-------------------------------------------|
# | 2020-03-20 03:30:58 | 2020-03-19 19:30:58 |
# +-------------------------------------------+
```
삽입 시점의 데이터베이스의 시간대는 KST으로, 오프셋은 '+9'이다. 시간대를 변경하기 전 조회 시점의 경우, 동일한 시간대, 동일한 오프셋이기 때문에 두 형식 모두 '2020-03-20 03:30:58'을 출력하는 것을 볼 수 있다. TIMESTAMP는 삽입 시점의 오프셋인 '+9'를 고려한 '2020-03-19 18:30:58'UTC 을 저장해두었다. 이후, 조회 시점의 오프셋 또한 '+9'로 동일하기 때문에 DATETIME과 동일한 '2020-03-20 03:30:58'을 반환한다. 하지만 시간대가 변경되고 난 후 TIMESTAMP 형식의 결과는 조회 시점의 시간대를 반영하기 때문에 '2020-03-19 18:30:58'UTC에 조회 시점의 오프셋인 '+1'을 연산한 '2020-03-19 19:30:58'을 반환하게 된다.

2. 표현 범위의 차이

두 번째 차이점인 표현 범위의 차이는 저장 방식의 차이이기도 한데, TIMESTAMP는 UTC 시간으로 변환하여 저장할 때, 유닉스 시간으로 저장한다.

'유닉스 시간이란, UTC 시간의 시작시간인 '1970-01-01 00:00:00'UTC 로부터의 경과 시간을 UTC 초를 나타내는 4 바이트 정수를 의미한다.'

TIMESTAMP는 단순히 '2020-03-20 03:30:58'을 UTC 시간으로 변환한 '2020-03-19 18:30:58'UTC를 저장하는 것이 아닌, '1970-01-01 00:00:00'UTC 부터 '2020-03-19 18:30:58'UTC 까지의 초 수인 $1,584,610,258$ 을 저장한다. 이러한 저장방식은 아래의 특징들과 같은 표현 범위의 차이를 만든다.

유닉스 시간으로 저장되는 TIMESTAMP는 시작 시간인 '1970-01-01 00:00:00'UTC 에서부터만 표현이 가능하다.
UNIX_TIMESTAMP() 함수를 통해 유닉스 시간으로 변환해볼 수 있는데, '1970-01-01 00:00:00'UTC 이전의 날짜를 변환하면 모두 0의 값을 가진다.
```
// 0
SELECT UNIX_TIMESTAMP('1970-01-01 00:00:00'); 

// 1584610258
SELECT UNIX_TIMESTAMP('2020-03-20 03:30:58');

// 0
SELECT UNIX_TIMESTAMP('1945-08-15 00:00:00'); 
```
TIMESTAMP는 4바이트 정수라는 한계로 인해 $2,147,483,647(2^{31}- 1)$ 초까지만 표현이 가능하다. (이를 'Y2K38', 2038년 문제라고 한다.)
실제로 유닉스 시간을 지역 시간으로 변환하는 함수인 FROM_UNIXTIME()으로 계산을 해보면 '2038-01-19 03:14:07'UTC, 한국 시각으로는 '2038-01-19 12:14:07'까지만 표현이 가능한 것을 확인할 수 있다. 표현 범위의 한계를 넘어선 2,147,483,648초를 변환해보면 NULL이 반환된다.
```
// '2038-01-19 12:14:07', '2038-01-19 03:14:07'UTC
SELECT FROM_UNIXTIME(2147483647, '%Y-%m-%d %h:%i:%s');

// NULL
SELECT FROM_UNIXTIME(2147483648, '%Y-%m-%d %h:%i:%s');
```

DATETIME, TIMESTAMP의 표현 범위 차이를 정리하면,

DATETIME은 ['0000-01-01 00:00:00', '9999-12-31 23:58:59']
TIMESTAMP는 ['1970-01-01 00:00:00', '2038-01-19 03:14:07']

하지만 UTC 시간을 따르는 TIMESTAMP는 시간대에 따라, 명시한 오프셋에 따라 그 범위가 다르다.
또한 날짜 및 시간 데이터를 저장할 때는 표현 범위 밖의 데이터는 저장되지 않는다. 아래의 예제로 확인해보자.

# Data truncation: Incorrect datetime value: '1970-01-01 00:00:01' for column
INSERT INTO `type_test` (mytimestamp) VALUES ('1970-01-01 00:00:00');

# Data truncation: Incorrect datetime value: '1970-01-01 09:00:00' for column
INSERT INTO `type_test` (mytimestamp) VALUES ('1970-01-01 09:00:00');

# OK! '1970-01-01 09:00:01'
INSERT INTO `type_test` (mytimestamp) VALUES ('1970-01-01 09:00:01');

# OK! '2020-03-20 11:30:58'
INSERT INTO `type_test` (mytimestamp) VALUES ('2038-01-19 12:14:08+01:00');

# OK! '2038-01-19 12:14:07'
INSERT INTO `type_test` (mytimestamp) VALUES ('2038-01-19 12:14:07');

# Data truncation: Incorrect datetime value: '2038-01-19 12:14:08'
INSERT INTO `type_test` (mytimestamp) VALUES ('2038-01-19 12:14:08');

예제와 같이 한국의 시간대를 사용하여 삽입할 때, 표현 범위는 지역의 오프셋을 고려한 범위인 ['1970-01-01 09:00:01', '2038-01-19 12:14:07']이 된다. 또한 오프셋을 명시한 '2038-01-19 12:14:08+01:00'도 가능한데, 위의 설명과 동일하기 때문에 '2020-03-20 11:30:58'의 값을 가지는 이유에 대해서는 스스로 이해해보자.

결론

DATETIME vs TIMESTAMP

두 형식을 정리해보자면,

두 형식에 사용 가능한 문자열의 형식은 동일하며, 지역 지정자 'Z'가 추가된 문자열은 사용이 불가능하다.
DATETIME은 UTC를 고려하지 않고 지역 시간으로 저장한다.
TIMESTAMP는 UTC를 반영하여 내부적으로 UTC 시간으로 저장해두고 조회 시에 지역 시간으로 변환한다. 이를 통해 조회하는 지역마다 동일한 UTC 시간을 의미할 수 있도록 다르게 표현한다.

** 년도 정보를 저장하는 YEAR 형식도 존재한다. 자세히 다루지 않고 링크로 대체한다.

ISO 8601 형식에 맞는 저장 형식은?

지금까지 MySQL에서 날짜 및 시간 데이터를 저장하는 형식에 대해 알아보았다. ISO 8601 형식의 데이터를 어떤 형식으로 저장해야할까? 날짜 데이터를 저장하는 DATE, 시간 데이터를 저장하는 TIME 두 형식 모두 날짜와 시간 데이터의 부분적인 정보만을 담을 수 있기 때문에 DATETIME, TIMESTAMP가 ISO 8601 형식의 데이터를 저장하는 데 적합하다고 볼 수 있다. ISO 8601 형식의 두 가지 경우에 따라 적합한 저장 방식과 전략을 설정해야 한다.

'YYYY-MM-DDThh:mm:ssZ' 형식의 UTC 시간을 사용하는 경우,

먼저 지역 지정자 'Z'가 추가된 문자열은 사용이 불가능하므로 제거하는 전처리가 필요하다.

DATETIME 형식으로 저장하게 되면 UTC 시간을 고려하지 않기 때문에 UTC 시간의 의미를 그대로 저장할 수 있으므로 UTC 시간을 저장하길 원한다면 해당 형식을 사용하자.
TIMESTAMP에 저장하게 되면 해당 시간이 UTC 시간임에도 불구하고 지역 시간대를 고려한 UTC 시간으로 변환하는 작업을 거친 뒤, 저장되게 된다.~~(UTC 시간의 UTC 시간화..)~~
물론 삽입과 조회 시점의 시간대가 동일한 경우, 저장한 시간의 값은 동일할 수 있으나 UTC 시간의 의미가 사라지게 된다. 또한 시간대가 변경되면 해당 시간대의 오프셋으로 계산되기 때문에 값이 변경될 수 있다. 그러므로 TIMESTAMP를 사용하기 위해서는 '+00:00'으로 오프셋을 명시하여 UTC 시간으로 저장될 수 있도록 하자.

'YYYY-MM-DDThh:mm:ss' 형식의 지역 시간을 사용하는 경우,

DATETIME 형식으로 저장하게 되면 UTC 시간을 고려하지 않기 때문에 지역 시간의 의미를 그대로 저장할 수 있으므로 지역 시간을 저장하길 원한다면 해당 형식을 사용하자.
TIMESTAMP에 저장하게 되면 지역 시간대를 고려한 UTC 시간으로 변환하여 저장하기 때문에 조회하는 지역 시간대를 고려한 지역 시간대를 전달할 수 있다. 하지만 저장하고자 하는 지역 시간의 시간대와 데이터베이스의 시간대가 동일해야 올바른 시간을 전달할 수 있을 것이다.

참고자료

각 형식별 문자열 형식 https://dev.mysql.com/doc/date-and-time-literals.html

각 형식별 내부 저장 구조 https://dev.mysql.com/doc/date-and-time-data-type-representation.html

JS에서 날짜 및 시간 문자열 다루기

Fri, 02 Jul 2021 00:00:00 GMT

날짜 관련 오류가 발생하면 그 때마다 원인을 이해하려고 하기보다 인터넷에서 코드를 긁어와 빠르게 해결하는 것에 집중했었다. 하지만 이번 문제를 접하고, JS에서 날짜를 다루는 것에 대해 정리가 필요할 것 같아 포스팅하게 되었다.

문제

Safari 환경에서 JS의 Date 객체를 사용하여 날짜를 보여주는 UI에서 'Invalid Date' 를 뱉어냈다.

Safari에서 'YYYY-MM-DD hh:mm:ss' (예를 들면 '2020-03-20 03:30:58') 형식의 문자열로 Date 객체를 선언하게 되는 경우 'Invalid Date' 을 반환한다.

JS에서의 Date 객체

JS에서는 Date 객체를 사용하여 날짜를 표현한다. 현재 시각이 필요한 경우, new Date().now() 를 통해 알아내기도 하고, 서버에서 전달받은 날짜 문자열을 new Date(dateString)으로 Date 객체를 만들어 시간/일자 연산(예를 들면, 호텔 체크아웃 날짜 계산)을 하는 등 문자열을 통해 날짜와 시간을 표현해야하는 경우에 쉽게 사용할 수 있다. 하지만 예상한 시간과 다르게 반환되거나 위의 경우처럼 아예 NaN 이 뜨는 등 갖가지 오류를 접하기도 하는데, 실제로 Mozlia web docs를 보면 날짜 문자열 파싱 문제를 미리 경고해두었다.

'Date 생성자(및 동일한 동작의 Date.parse())를 사용한 날짜 파싱은 동작이 일관적이지 못하고 브라우저끼리 차이가 존재하므로 사용하지 않는 것이 좋습니다.'

실제로 그런지 각 브라우저간의 차이를 확인하기 위해 Safari, Chrome, IE, Edge를 준비하고 각 브라우저의 콘솔창을 통해 결과값을 확인해보았다. ~~(Firefox, Opera 등 다른 웹 브라우저는 과제로 남겨두겠다.)~~ 테스트에 사용된 날짜 문자열 '2020-03-20 03:30:58'은 실제로 사용하고 있는 'YYYY-MM-DD hh:mm:ss' 형식의 dummy data이다.

브라우저별 Date 객체 선언 테스트

1. 테스트 코드
new Date('2020-03-20 03:30:58')

2. 테스트 결과

safari - 버전 14.0.3(16610.4.3.1.7)
chrome - 버전 91.0.4472.114(공식 빌드) (arm64)
edge - 버전 91.0.864.59 (공식 빌드) (64비트)
IE - 버전 2004(OS 빌드 19041.985)

동일한 날짜 문자열의 Date 객체를 선언하였음에도 그 결과가 브라우저마다 다른 것을 볼 수 있다. (**브라우저의 실행 지역, 버전에 따라 결과가 다를 수 있습니다.) 이 테스트를 통해 JS가 수행되는 환경에 따라 Date 객체를 통한 파싱의 결과가 다를 수 있다는 것을 알 수 있었다. 그럼에도 불구하고 서버 측에서 날짜 및 시간에 대한 데이터를 문자열 형태로 전달하기 때문에 브라우저상에서 Date 객체를 통해 날짜를 파싱하는 것이 불가피하였다. 그래서 각기 다른 브라우저에서 동일한 파싱 결과를 보여줄 수 있는 다른 방법을 찾아보았다.

원인

하지만 실제 문제의 원인은 날짜 및 시간 데이터의 전달을 위해 내부적으로 사용하던 'YYYY-MM-DD hh:mm:ss' 형식이 날짜 및 시간 문자열 표준 형식인 ISO 8601을 따르지 않은 것이다. 이로 인해 특정 브라우저에서 날짜에 대한 데이터로 인식되지 못하는 문제가 발생했다. 문제를 해결하기 위해서는 날짜 및 시간 문자열의 표준 형식인 ISO 8601의 개념이 필요하기에 나름대로 요약해보았다. 내가 필요한 부분만 가져왔기 때문에 깊게 알고 싶은 분들은 출처를 참조하자.

ISO 8601

ISO 8601은 날짜와 시간과 관련된 데이터 교환을 다루는 국제 표준이다.

날짜표현은 YYYY-MM-DD , 시간 표현은 hh:mm:ss.sss hh:mm:ss 으로 표현되며 구분자는 생략이 가능하다.
날짜와 시간 혼합표현은 <date>T<time>이다.
날짜와 시간은 0을 붙여 고정 자릿수를 유지한다.
시간이 UTC인 경우, 시간 뒤에 빈칸없이 Z를 직접 추가해야 한다. Z는 오프셋이 0인 UTC를 위한 지역 지정자(zone designator)다. <date>T<time>Z 가 된다.

'인터넷 상에서, World Wide Web Consortium (W3C)는 에러율과 소프트웨어 복잡도를 줄이기 위해 제공된 날짜와 시간 형식을 제한하는 표준 프로파일을 정의하기 위해 ISO 8601를 사용한다.'

날짜 및 시간 문자열 형식을 표준에 맞추기 위해서는 'YYYY-MM-DD hh:mm:ss'가 아닌 'YY-MM-DDThh:mm:ssZ' 의 형식을 사용해야 한다. 단순히~~(무지성으로)~~ 날짜와 시간 사이에 'T'를 넣고 맨 마지막에 'Z'가 붙여 표준 형식을 맞추려고 했다면 전혀 다른 날짜 및 시간 정보를 보게 될 것이다. 브라우저가 ISO 8601 문자열로 Date 객체를 생성할 때, 'Z' 문자를 통해 해당 문자열이 표현하는 시간을 오프셋이 0인 UTC 시간으로 인식하기 때문이다. 대신, 맨 뒤의 'Z' 문자를 빼게 되면 해당 문자열이 표현하는 시간을 UTC 시간이 아닌 지역 시간으로 인식하게 된다. 갑자기 등장하는 'UTC', '오프셋', '지역 시간'의 개념이 생소할 수 있다. 아래에서 간단히 설명하는데 혹시 자세히 알고 싶다면 위키를 참조하자.

UTC

GMT(그리니치 평균 시간)로도 불리며, 그리니치 천문대의 시간을 기준으로한 국제 표준시이다.
오프셋

그리니치 천문대의 시간을 기준으로 한 GMT와 지역별의 시간차이를 의미한다.
- 한국은 +9으로, 즉 그리니치 천문대의 시간보다 9시간이 빠르다.
지역 시간

GMT를 기준으로 해당 지역의 오프셋, 썸머 타임등을 반영한 시간이다.
- 현재 이 글에서는 서비스 사용자의 브라우저가 실행되는 지역의 시간을 의미한다.
- **쉬운 설명을 위해 오프셋에 썸머타임 등, 지역시간에 영향을 주는 변수를 모두 포함하겠다.

글만으로는 이해하기 어려울 것 같아 각 브라우저, 문자열 형식별 비교를 위해 3개의 코드를 각 브라우저에서 실행시켜보았다. 결과를 보면서 이해해보자.

브라우저/형식별 Date 객체 선언 테스트

1. 테스트 코드

1-1. 이전 테스트
new Date('2020-03-20 03:30:58')

1-2. 단순히 형식을 맞추기 위한 'T', 'Z' 문자 추가
new Date('2020-03-20T03:30:58Z')

1-3. 지역 시간으로 전달하기 위해 'Z' 제거
new Date('2020-03-20T03:30:58')

2. 테스트 결과

safari - 버전 14.0.3(16610.4.3.1.7)
chrome - 버전 91.0.4472.114(공식 빌드) (arm64)
edge - 버전 91.0.864.59 (공식 빌드) (64비트)
IE - 버전 2004(OS 빌드 19041.985)

new Date('2020-03-20T03:30:58Z')의 결과를 살펴보면 한국의 시간 오프셋은 +9이기 때문에 'T', 'Z' 문자가 추가된 Date 객체의 시간은 03시가 아닌 9시간이 더해진 12시가 된다. 하지만 'T' 문자만 추가한 new Date('2020-03-20T03:30:58')의 결과에서는 오프셋을 계산할 지역 정보가 존재하지 않기 때문에 지역 시간으로 간주하여 시간이 03시 그대로인 것을 볼 수 있다.

해결

이번 문제는 날짜 및 시간의 문자열을 표준 형식으로 맞추는 것으로 문제를 해결할 수 있다. 해결하는 방법은 기준 시간대를 UTC 시간으로 할 것인가, 지역 시간으로 할 것인가에 따라 두 가지로 나뉜다. 이해를 돕기 위해 글의 작성시점인 한국 시각 '2021-06-30 13:49:30'를 예로 들어 설명하고자 한다.

1. UTC 시간을 기준으로 포맷팅

'기존의 시간에서 지역의 시간 오프셋을 반대로 연산하여 UTC 시간으로 바꿔 전달하여 브라우저가 사용자의 지역시간에 맞게 변경할 수 있도록 한다.'

UTC 시간을 기준으로 전달하기 위해 '2021-06-30 13:49:30'을 한국의 오프셋인 '+9'를 고려하여 9시간을 뺀 '2021-06-30T04:49:30'UTC 로 미리 계산, 포맷팅하여 데이터 베이스나 서버의 내부 데이터로 사용하는 방법이다. 브라우저는 '2021-06-30T04:49:30Z'의 문자열로 Date 객체를 생성할 때 해당 시간을 UTC 시간으로 인식하고 브라우저가 실행되는 지역에 맞게 지역 시간으로 변경한다. 한국의 브라우저에서는 9시간이 더해진 '2021-06-30 13:49:30'으로 표현될 것이고, 오프셋이 '+1'인 프랑스의 브라우저에서는 '2021-06-30 05:49:30'으로 표현될 것이다. 이를 통해 지역별 시간대 변환 문제를 해결할 수 있다. 하지만 지역 시간으로 변경하는 연산을 브라우저에게 의존해야 하기 때문에 예기치 않은 문제가 발생할 수 있다는 단점이 있다.(브라우저 종류, 버전에 따라 달라질 수 있다고 한다.) 또한 국내 시간대만 사용하는 서비스의 경우, 지역 오프셋을 미리 계산하는 포맷팅 과정이 불필요할 수 있다.

2. 지역 시간을 기준으로 포맷팅

'지역 시간을 기준으로 전달하기 위해 '2021-06-30 13:49:30'을 '2021-06-30T13:49:30'로 변환하여 데이터 베이스나 서버의 내부 데이터로 사용하는 방법이다.'

지역 시간을 기준으로 전달하기 위해 '2021-06-30 13:49:30'을 '2021-06-30T13:49:30'로 변환하여 데이터 베이스나 서버의 내부 데이터로 사용하는 방법이다. 위의 방법과 달리 브라우저는 '2021-06-30T13:49:30'의 문자열로 Date 객체를 생성할 때 해당 문자열을 지역 시간으로 인식하고 그대로 '2021-06-30 13:49:30'을 표현한다. 국내 시간대만 사용하는 서비스의 경우에는 지역 시간만 사용해도 되기 때문에 바로 적용 가능한 방법이다. 하지만 동일 시간대를 사용하지 않는 다른 지역에서의 접속 시 문제가 발생한다. 해당 지역의 오프셋을 고려하지 않기 때문에 프랑스의 브라우저에서도 동일하게 '2021-06-30 13:49:30'으로 표현된다. 같은 시간이 "표시됐으니 된 거 아냐?" 할 수 있지만, 전혀 다른 의미를 가진다. 프랑스 브라우저의 시간을 한국 시각으로 계산해보면,

'2021-06-30 13:49:30'을 UTC 시간으로 변경하면 -1 시간을 한 '2021-06-30 11:49:30'이 된다.
'2021-06-30 11:49:30'을 한국 시간으로 변경하면 +9 시간을 한 '2021-06-30 20:49:30'이 된다.

프랑스의 브라우저가 나타내는 시간은 전혀 다른 '2021-06-30 20:49:30'을 의미하고 있는 것이다! 한국의 브라우저에서는 내가 점심을 먹고 글을 작성하였다면, 프랑스의 브라우저에서는 저녁을 먹고 글을 작성한 것이 된다. 이처럼 여러 시간대의 글로벌한 서비스를 위해서는 단순히 지역 시간으로 제공하는 것이 아닌 '2021-06-30T13:49:30+9', '2021-06-30T13:49:30+1'과 같이 문자열 끝에 해당 지역의 오프셋을 명시하는 방법을 사용해야 한다. 사실 Date 객체의 toLocaleString() 함수를 사용하여 지역 시간대로 변경할 수 있다고 하지만 이 글에서는 문자열에만 집중해보았다.

3. 날짜 관련 라이브러리 사용

위의 두 가지의 해결 방식은 라이브러리의 사용을 고려하지 않았다. 하지만 라이브러리는 문자열의 형식이나 오프셋 계산등 걱정하지 않고 사용할 수 있도록 많은 기능이 제공된다. 사실상 지금까지의 모든 고민을 해결할 수 있으니 나처럼 고민하지 말고 그냥 사용하자. 추천하는 라이브러리는 day.js 인데 대문부터 크기를 강조하는 것을 보면 다른 날짜 라이브러리보다 가벼운 것은 확실해 보인다. (가벼운 게 최고다.) 함수명이 매우 직관적이라 쉽게 사용할 수 있기 때문에 설명하지 않고 예제와 docs 링크를 남긴다.

// 대충 한국 시간대를 사용하겠다는 코드
import dayjs
import LocalizedFormat from 'dayjs/plugin/localizedFormat';
import relativeTime from 'dayjs/plugin/relativeTime';
import 'dayjs/locale/ko';

dayjs.extend(LocalizedFormat);
dayjs.extend(relativeTime);

dayjs(date).toISOstring()

요약

Date 객체를 사용하여 날짜 및 시간 문자열을 파싱하기 위해서는 표준인 ISO 8601을 따르자. 그래야 브라우저별로 다르게 동작하는 것을 ~~(거의 다)~~ 막을 수 있다.
시간대별로 브라우저의 동작이 다를 수 있으니 서비스에 따라 'UTC 시간', '지역 시간' 또는 '오프셋을 명시한 지역시간' 중 적절한 형식을 사용하자.
그냥 날짜 관련 라이브러리를 사용하자.

다음 포스팅에서는 Node.js(NestJS) - MySQL 데이터 베이스에서 날짜 및 시간 문자열을 다루는 것을 정리해보려고 한다. MySQL에서 날짜 및 시간 문자열을 다루는 형식은 또 다르다. 다음 글은 좀 짧으니 시간이 남는다면 읽어보자.

참고 자료

시간 및 날짜 문자열에 대한 정리 https://meetup.toast.com/posts/130
ISO 8601에 대한 정의 https://ko.wikipedia.org/wiki/ISO_8601

무지성 개발 탈출기 | Feed

JS의 기본 개념 2. this

this란?

기본 개념

1. new 연산자를 통한 객체의 생성 과정

2. lexical scope

this 바인딩 룰

1. 기본적으로 this는 함수를 호출하는 객체에 바인딩 됩니다. 호출하는 객체가 명시되지 않은 단순 함수 호출의 경우, 전역객체에 바인딩 됩니다.

2. 함수의 내부 함수는 외부 함수의 this로 바인딩 되지 않습니다.

3. 화살표 함수(Arrow function)의 경우, this가 존재하지 않습니다. 그러므로 화살표 함수 내의 this는 다른 변수와 동일하게 함수의 렉시컬 스코프 상의 this를 참조합니다.

4. 클래스(Class)의 경우, 함수 블록 상의 모든 코드는 'strict mode'로 수행됩니다. 'strict mode'는 기본적으로 this를 자동으로 바인딩하지 않으며, 호출 객체가 명시되지 않은 경우, undefined를 반환합니다.

조금 더 복잡한 예

이외

그래서 this을 말하자면..

+ this 바인딩 관련 메소드

1. bind(<object>)

2. call(<object>, ...<params>)

3. apply(<object>, [<params>])

JS의 기본 개념 1. 프로토타입

프로토 타입이란?

생성자 함수와 new 연산자를 통한 객체 생성과정

프로토타입의 구조

Prototype Object

1. 아래 박스는 생성자 함수 Human입니다. 생성자 함수는 기본적으로 두 개의 프로퍼티를 가집니다.

2. 위 박스는 생성자 함수 Human의 Prototype Object입니다.

Prototype Link

그래서 Prototype Object, Prototype Link를 말하자면..

Prototype Chain

1. 먼저 위 코드에서 A, chanwoo.printName()을 수행하는 과정을 설명하겠습니다.

2. 다음은 B, chanwoo.hasOwnProperty('name')을 수행하는 과정을 설명하겠습니다.

3. 마지막으로 C, chanwoo.printNickName()과 같이 Prototype Chain 상에 존재하지 않는 메소드를 호출하는 경우입니다.

Prototype에서 주의할점

그래서 Prototype Chain을 말하자면..

끝으로

MySQL의 엔진 InnoDB를 알아보자.(2/2)

InnoDB 주요 장점

Index

인덱스를 사용하는 방식

다중 컬럼 인덱스

인덱스 저장 구조

B-Tree

Hash

3. Clustered Index

PRIMARY KEY

이외의 인덱스 종류

4. FOREIGN KEY

FOREIGN KEY 추가

사용시 장점

사용시 유의사항

정리

3. Clustered Index

4. FOREIGN KEY

참고자료

MySQL의 엔진 InnoDB를 알아보자.(1/2)

InnoDB 주요 장점

1. Transaction 기능

ACID

2. Consistent reads & Row-level locking

MVCC(Multi-Version Concurrency Control) 다중 버전 동시성 제어

Repeatable Read

1) Consistent read

2) Row-level locking

READ COMMITTED

1) Consistent read

2) Row-level locking

+) 격리 수준별 Row-level Locking

정리

1. Transaction 기능

2. Row-level locking과 Consistent reads를 통해 다중 사용자 환경에 대한 동시성 제어

MySQL에서 날짜 및 시간 문자열 저장하기

MySQL의 날짜 및 시간 데이터 형식 (Data Type)

예제환경

DATE

1. 'YYYY-MM-DD' 의 형식

2. 구분자가 생략된 'YYYYMMDD' 형식

TIME

1. 기본적인 시,분,초로 구성된 'hh:mm:ss' 형식

2. 구분자가 존재하지 않는 'hhmmss' 형식

DATETIME

TIMESTAMP

1. `new` 연산자를 통한 객체의 생성 과정

1. 기본적으로 `this`는 함수를 호출하는 객체에 바인딩 됩니다. 호출하는 객체가 명시되지 않은 단순 함수 호출의 경우, 전역객체에 바인딩 됩니다.

2. 함수의 내부 함수는 외부 함수의 `this`로 바인딩 되지 않습니다.

3. 화살표 함수(Arrow function)의 경우, `this`가 존재하지 않습니다. 그러므로 화살표 함수 내의 `this`는 다른 변수와 동일하게 함수의 렉시컬 스코프 상의 `this`를 참조합니다.

4. 클래스(Class)의 경우, 함수 블록 상의 모든 코드는 'strict mode'로 수행됩니다. 'strict mode'는 기본적으로 `this`를 자동으로 바인딩하지 않으며, 호출 객체가 명시되지 않은 경우, `undefined`를 반환합니다.

1. `bind(<object>)`

2. `call(<object>, ...<params>)`

3. `apply(<object>, [<params>])`

생성자 함수와 `new` 연산자를 통한 객체 생성과정

1. 아래 박스는 생성자 함수 `Human`입니다. 생성자 함수는 기본적으로 두 개의 프로퍼티를 가집니다.

2. 위 박스는 생성자 함수 `Human`의 Prototype Object입니다.

1. 먼저 위 코드에서 A, `chanwoo.printName()`을 수행하는 과정을 설명하겠습니다.

2. 다음은 B, `chanwoo.hasOwnProperty('name')`을 수행하는 과정을 설명하겠습니다.

3. 마지막으로 C, `chanwoo.printNickName()`과 같이 Prototype Chain 상에 존재하지 않는 메소드를 호출하는 경우입니다.