문자열
2010년도 이후, 우리는 유니코드라고 불리는 인코딩 방식이 통일된 시대를 살아가고 있습니다. 문자열을 다루는 디테일한 방식에 대해 전부 알 필요는 없지만, 프로그래밍 언어마다 문자열을 다루는 자료형의 차이를 이해하기 위해 문자열을 다루는 기본적인 방식은 알고 있어야 합니다.
문자열 하나는 몇 바이트인가요?
영어의 경우 알파벳 하나가 1 바이트(byte)를 차지하는 시절이 있었습니다. 그러나 글로벌 시대에는 유니코드를 사용해야 텍스트를 정확하게 저장할 수 있습니다. 프로그래밍 언어마다 문자열을 저장하는 자료형이 다 다르므로, "문자열 하나가 몇 바이트인가?"에 대한 답변은 이 자료형이 차지하고 있는 바이트를 이해할 때 답변할 수 있습니다.
유니코드는 무엇인가요?
유니코드(Unicode)는 유니코드 협회(Unicode Consortium)가 제정하는 전 세계의 모든 문자를 컴퓨터에서 일관되게 표현하고 다룰 수 있도록 설계된 산업 표준입니다. 이 표준에는 ISO 10646 문자 집합, 문자 인코딩, 문자 정보 데이터베이스, 문자를 다루기 위한 알고리즘 등을 포함하고 있습니다.
유니코드가 탄생하기 이전에는, 같은 한글이 적힌 텍스트 파일이라도 표현하는 방법이 제각각이었습니다. 어떤 파일이 지원하지 않는 다른 인코딩 형식으로 저장되어 있는 경우에는 파일을 제대로 불러올 수 없었습니다. 기본적으로 유니코드의 목적은 현존하는 문자 인코딩 방법을 모두 유니코드로 교체하는 겁니다.
인코딩(부호화)이란?
인코딩이란 어떤 문자나 기호를 컴퓨터가 이용할 수 있는 신호로 만드는 것입니다.
이 신호를 입력하는 인코딩과 문자를 해독하는 디코딩을 하기 위해서는 미리 정해진 기준을 바탕으로 입력과 해독이 처리되어야 합니다.
이렇게 인코딩과 디코딩의 기준을 문자열 세트 또는 문자셋(charset)이라고 합니다. 이 문자셋의 국제 표준이 유니코드입니다.
ASCII 문자는 무엇인가요?
영문 알파벳을 사용하는 대표적인 문자 인코딩으로 7 비트로 모든 영어 알파벳을 표현할 수 있습니다. 52개의 영문 알파벳 대소문자와, 10개의 숫자, 32개의 특수 문자, 그리고 하나의 공백 문자를 포함합니다.
유니코드는 ASCII를 확장한 형태입니다.
UTF-8과 UTF-16의 차이점은 무엇인가요?
UTF-8과 UTF-16은 인코딩 방식의 차이를 의미합니다. UTF-8은 Universal Coded Character Set + Transformation Format – 8-bit의 약자로, UTF- 뒤에 등장하는 숫자는 비트(bit)입니다.
- UTF-8 특징: 가변 길이 인코딩
UTF-8은 유니코드 한 문자를 나타내기 위해 1 byte(= 8 bits)에서 4 bytes까지 사용합니다.
원리
예를 들어, 코 라는 문자의 유니코드는 U+CF54 (16진수, HEX)로 표현됩니다. 이 문자를 이진법(binary number)으로 표시하면, 1100-1111-0101-0100 이 됩니다. 이 문자를 UTF-8로 표현하면, 다음과 같이 3byte의 결과로 표현됩니다.
1110xxxx 10xxxxxx 10xxxxxx # x 안에 순서대로 값을 채워넣습니다.
11101100 10111101 10010100
let encoder = new TextEncoder(); // 기본 인코딩은 'utf-8'
encoder.encode('코') // Uint8Array(3) [236, 189, 148]
(236).toString(2) // "11101100"
(189).toString(2) // "10111101"
(148).toString(2) // "10010100"ASCII 코드는 7비트로 표현되고, UTF-8에서는 다음과 같이 1 byte의 결과로 만들 수 있습니다. 다음 예제는 b 라는 문자를 UTF-8로 인코딩한 결과입니다.
encoder.encode('b') // Uint8Array [98]
(98).toString(2) // "1100010"
이처럼, UTF-8은 1 byte에서 4 bytes까지의 가변 길이를 가지는 인코딩 방식입니다. 네트워크를 통해 전송되는 텍스트는 주로 UTF-8로 인코딩됩니다. 사용된 문자에 따라 더 작은 크기의 문자열을 표현할 수 있기 때문입니다. ASCII 문자는 1 바이트만으로 표현 가능한 것처럼 말입니다.
UTF-8은 ASCII 코드의 경우 1 byte, 크게 영어 외 글자는 2byte, 3byte, 보조 글자는 4byte를 차지합니다. 이모지는 보조 글자에 해당하기 때문에 4byte가 필요합니다.
2. UTF-8 특징: 바이트 순서가 고정됨
UTF-16에 비해 바이트 순서를 따지지 않고, 순서가 정해져 있습니다.
3. UTF-16 특징: 코드 그대로 바이트로 표현 가능, 바이트 순서가 다양함
UTF-16은 유니코드 코드 대부분(U+0000부터 U+FFFF; BMP) 을 16 bits로 표현합니다.
대부분에 속하지 않는 기타 문자는 32 bit(4 bytes)로 표현하므로 UTF-16도 가변 길이라고 할 수 있으나, 대부분은 2 바이트로 표현합니다
U+ABCD라는 16진수를 있는 그대로 이진법으로 변환하면 1010-1011-1100-1101 입니다. 이 이진법으로 표현된 문자를 16 bits(2 bytes)로 그대로 사용하며, 바이트 순서(엔디언)에 따라 UTF-16의 종류도 달라집니다.
UTF-8에서는 한글은 3 바이트, UTF-16에서는 2 바이트를 차지합니다.
그래픽
비트맵(Bitmap)과 벡터(Vector)는 디지털 이미지의 종류입니다. 디지털 이미지, 또는 이미지라고 불리는 용어는 디지털 카메라를 이용하여 현실세계의 사물을 촬영하거나 스캐너를 이용하여 사진이나 그림을 디지털 형태로 받아들인 것을 가리킵니다. 서로 상반된 방식으로 이미지를 표현하기 때문에 비트맵(Bitmap)과 벡터(Vector)는 큰 차이점이 있습니다.
비트맵
비트맵(Bitmap)은 웹 상에서 디지털 이미지를 저장하는 데에 가장 많이 쓰이는 이미지 파일 포맷 형식입니다. 일반적으로는 래스터 그래픽(점 방식)이라고 합니다. 이미지의 각 점들을 격자형의 픽셀 단위로 구성되며, 한 지역을 차지하는 셀은 위치에 따라 다른 값을 갖습니다.
이런 비트맵은 사각의 픽셀 형태로 모여 있기 때문에 확대를 하면 ‘계단현상’ 또는 ‘깨짐 현상’이 발생하며, 경계가 뚜렷하지 않다는 특징이 있습니다. 이런 식으로 픽셀 단위로 이미지를 표현하는 방식은 컴퓨터에게 부담을 덜 주는 구조로 되어 있습니다. 또한 픽셀 하나 당 모두 색상 값을 가지고 있습니다. 따라서 이미지의 사이즈가 커질수록 용량 또한 무거워진다는 특징이 있습니다.
벡터
벡터(Vector)는 비트맵과는 완전히 다른 방식으로 이미지를 표현합니다. 비트맵이 격자형의 픽셀 단위로 이미지를 구성한다면 벡터는 이미지를 수학적인 공식으로 표현을 합니다.
점과 점을 연결해 선을 표현하고 선과 선을 연결해 면을 표현하는 식의 수학적 원리로 그림을 그리기 때문에 비트맵과는 달리 아무리 확대를 해도 ‘계단현상’ 또는 ‘깨짐 현상’이 발생하지 않습니다. 그러나 그렇기 때문에 벡터 방식으로 이미지를 표현하는 것은 비트맵에 비해 컴퓨터에게 부담을 가하는 방식이므로 주로 도형, 글자 등을 그리는 작업에 사용됩니다. 또한 수학적인 연산으로 만들어진 이미지이기 때문에 사이즈를 키워도 용량에는 변화가 없다는 특징 또한 있습니다.
비트맵(래스터)과 벡터 이미지의 차이점
가비지 컬렉션
가비지 컬렉션은 프로그램에서 더 이상 사용하지 않는 메모리를 자동으로 정리하는 것입니다. 이 기능을 가진 언어(혹은 엔진)는 자바, C#, 자바스크립트 등이 있습니다. C 언어 같은 저수준 언어에서는 메모리 관리를 위해 malloc()과 free()를 사용해 개발자가 스스로 메모리를 할당하고 해제해야 합니다. 그러나 JavaScript는 C언어와는 반대로 고수준 언어로서, 객체가 생성되었을 때 자동으로 메모리를 할당하고 필요하지 않다면 자동으로 해제하는 가비지 컬렉션이 내장되어 있습니다.
고수준 언어와 저수준 언어는 무엇일까요?
C언어가 저수준 언어라고 해서 고수준 언어인 JavaScript에 비해 뒤떨어지는 게 아닙니다. 프로그래밍 언어가 인간에게 친화적인지, 기계에게 친화적인지에 따라 고수준 언어와 저수준 언어로 갈리는 것입니다.
저수준 언어는 보다 기계 친화적인 언어로 레지스터 및 메모리와 직접 상호 작용을 할 수 있기 때문에 전반적으로 빠르게 실행되는 응용 프로그램을 빌드하는 데에 사용됩니다. 또한 저수준 언어는 컴파일러나 인터프리터가 필요하지 않으므로 저수준 언어는 고수준 언어보다 빠른 편입니다.
반대로 고수준 언어는 인간 친화적인 언어로, 인간이 이해하기 쉽고 다양한 작업을 수행하는 프로그램을 개발할 수 있습니다. 영어와 유사한 구문이 있기 때문에 컴파일러 또는 인터프리터를 사용하여 컴퓨터가 읽을 수 있는 기계어 코드로 변환해야 하며, 하드웨어와 직접 상호 작용하지는 않습니다.
개발자가 직접 메모리를 할당하고 해제해야 하는 부분을 가비지 컬렉션이 도와주기 때문에, 개발자가 메모리 관리에 대해 고민할 필요가 없다는 잘못된 인상을 받을 수 있습니다. 실제로 지금까지 여러분은 작은 컴포넌트 및 앱을 개발하면서 메모리 할당 및 해제에 대해 깊은 고민을 하지 않았을 것입니다. 그러나 가비지 컬렉션이 어떻게 동작하는지, JavaScript가 어떻게 메모리를 관리하는지 알아야 훗날 여러분이 개발한 앱의 속도 저하, 예기치 못한 종료, 느린 응답 속도와 같은 문제들이 왜 일어나는지 알 수 있습니다.
메모리 생존주기
- 메모리 생존 주기는 그 어떤 프로그래밍 언어에 관계 없이 비슷합니다.
필요할 때 개발자가 할당합니다. - 할당된 메모리를 사용합니다. (Read and Write)
메모리가 더이상 필요하지 않으면 해제합니다. - 2번의 할당된 메모리를 사용하는 것은 모든 언어에서 명시적으로 사용되는 부분입니다. JavaScript로 예시를 들자면 개발자가 변수를 선언해 값을 할당하여 사용하는 부분이 되겠습니다. 그러나 1번과 3번은 C언어와 같은 기계친화적인 저수준 언어에서는 명시적이고, JavaScript와 같은 고수준 언어에서는 암묵적으로 작동합니다. 따라서 여러분들이 직접 이 부분을 제어하지는 않았을 것입니다.
메모리 할당
JavaScript는 프로그래머 대신, 값을 선언할 때 자동으로 메모리를 할당해줍니다.
1
let arr = [100, 200, 300, 400]여러분들은 여태껏 변수를 선언하고 배열을 할당하여 안에 요소를 집어넣을 때, 그 배열을 담을 메모리의 크기를 고려하지 않았을 것입니다. 이 부분을 JavaScript가 배열과 배열에 담긴 값들을 위한 메모리 크기 할당을 알아서 진행했기 때문입니다. 이 부분은 정수, 문자열, 함수, 객체 모든 부분에서 자동적으로 일어납니다.
할당된 메모리 사용 (값 사용)
기본적으로 할당된 메모리를 읽고 쓰는 것을 의미합니다. 변수나 객체 속성의 값을 읽고 쓰거나, 함수 호출 시에 함수에 인수를 전달하여 수행하는 방식으로 일어납니다.
메모리 해제
할당된 메모리가 더이상 필요 없다면 해제를 해야 앱의 성능을 저하시키지 않습니다.
이 부분에서, 저수준 언어는 개발자가 직접 결정하고 해제하는 방식을 사용합니다. 개발자가 직접 관여하기 때문에 개발자의 제어 정도가 굉장히 높은 편입니다.
그러나 고수준 언어는 앞서 이야기 했듯 가비지 컬렉션이라는 자동 메모리 관리 방법을 내장한 상태입니다. 가비지 컬렉션의 목적은 메모리 할당을 추적하고, 할당된 메모리 블록이 더이상 필요하지 않게 되었는지를 “스스로” 판단하여 필요하지 않다고 판단이 된다면 해당 메모리를 해제합니다. 하지만 언어 스스로 메모리가 여전히 필요한지 필요하지 않은지 판단하는 것은 비결정적인 영역입니다. 그래서 고수준 언어에 내장된 가비지 컬렉터들은 제한적인 해결책을 구현합니다.
대표적인 가비지 컬렉션의 방법
가비지 컬렉션 알고리즘은 이하 2가지 알고리즘이 가장 유명합니다. 이 2가지 알고리즘이 의존하고 있는 개념은 참조(reference)입니다.
참조(reference)
명시적이든, 암묵적이든 관계없이 메모리 관리 관점에서 어떤 객체가 다른 객체에 접근할 수 있다면 다른 객체를 참조한다고 말합니다. 예를 들어서, JavaScript 객체는 자신의 프로토타입(prototype)에 대해 암묵적인 참조를 갖고 있고, 자신의 속성(property) 값에 대한 명시적 참조도 가지고 있습니다.
객체를 참조하는 것에 대해, 객체란 협의적 개념으로 일반적인 JavaScript 객체를 의미하지만 광의적 개념으로 함수 스코프(function scope)나 글로벌 렉시컬 스코프(global lexical scope)까지도 포함한다는 것을 알아둡시다.
렉시컬 스코핑(lexical scoping)
변수 이름이 중첩된 함수에서 해석되는 방식을 정의하는 것으로, 중첩되어 있는 더 안쪽의 함수는 부모 함수가 값을 반환한 다음에도 부모 함수의 스코프를 포함하고 있습니다.
레퍼런스 카운팅(참조 횟수 계산)
한 객체를 참조하는 변수의 수를 추적하는 방법으로 가장 단순한 형태의 가비지 컬렉션 알고리즘입니다.
객체를 참조하는 변수는 처음에는 특정 메모리에 대해 레퍼런스가 하나뿐이지만, 변수의 레퍼런스가 복사될 때마다 레퍼런스 카운트가 늘어납니다. 객체를 참조하고 있던 변수의 값이 바뀌거나, 변수 스코프를 벗어나면 레퍼런스 카운트는 줄어듭니다. 레퍼런스 카운트가 0이 되면, 그 객체와 관련한 메모리는 비울 수 있습니다. 레퍼런스 카운트가 0이 된다는 말은 아무도 그 객체에 대한 레퍼런스를 가지고 있지 않다는 말과 같습니다.
이 방식은 순환 참조로 인한 문제가 생길 가능성이 높습니다.
function reference() {
var obj1 = {};
var obj2 = {};
obj1.p = obj2;
obj2.p = obj1;
}
reference();
위 코드에서는 두 객체가 생성되고 서로를 참조하고 있는 형태이기 때문에 순환 참조가 발생합니다. 이 객체들은 함수 호출 뒤에는 스코프를 벗어나게 되므로 실질적으로 쓸모가 없게 됩니다. 그래서 이들이 차지하던 메모리는 반환될 수 있지만, 레퍼런스 카운팅 알고리즘에서는 두 객체가 적어도 한 번은 참조한 것으로 간주되기 때문에 둘 다 가비지컬렉션이 될 수 없게 됩니다.
트레이싱
한 객체에 flag를 두고, 가비지 컬렉션 사이클마다 flag에 표시 후 삭제하는 mark and sweep 방법입니다.
객체에 in-use flag를 두고, 사이클마다 메모리 관리자가 모든 객체를 추적해서 사용 중인지 아닌지를 표시(mark)합니다. 그 후 표시되지 않은 객체를 삭제(sweep)하는 단계를 통해 메모리를 해제합니다. 현재 대부분의 가비지 컬렉션이 mark and sweep 알고리즘을 이용한 가비지 컬렉터를 장착하고 있습니다.
mark and sweep 알고리즘은 객체가 필요한지 결정하기 위해 해당 객체에 닿을 수 있는지 (reachable)을 판단합니다. 그리고 3단계를 거칩니다.
1 루트(Roots): 일반적으로 루트는 코드에서 참조되는 전역 변수입니다. 예를 들어 자바스크립트에서 루트로 동작할 수 있는 전역 변수는 window 객체입니다. Node.js에서 이와 동일한 객체는 global입니다. 가비지컬렉터는 모든 루트의 완전한 목록을 만들어냅니다.
2 그런 다음 모든 루트와 그 자식들을 검사해서 활성화 여부를 표시합니다(활성상태이면 가비지가 아닙니다). 루트가 닿을 수 없는 것들은 가비지로 표시됩니다.
3 마지막으로 가비지컬렉터는 활성으로 표시되지 않은 모든 메모리를 OS에 반환합니다.
이 방법은 앞선 레퍼런스 카운팅 방법보다는 나은데, ‘참조받지 않는 객체’는 ‘닿을 수 없는 객체’기 때문에 가비지 컬렉션을 통해 메모리를 해제할 수 있기 때문입니다.
메모리 누수
Garbage collected 언어에서 메모리 누수의 주요 원인은 예상치 못한 참조입니다.
예상치 못한 참조는 개발자는 더 이상 사용되지 않을 것이라 생각했지만, 어떠한 이유로 활성화 상태인 루트 트리 안에 존재하는 메모리 조각들입니다. 자바스크립트에서 예상치 못한 참조는 더이상 사용되지 않지만 코드 상 어딘가에 유지되어 해제되지 못한 변수들입니다. 어떤 이들은 이를 개발자의 실수라고 말하기도 합니다. 그래서 자바스크립트에서 발생할 수 있는 일반적인 메모리 누수 형태들을 이해하기 위해서는 흔히 까먹기 쉬운 참조들을 먼저 알 필요가 있습니다.
이런 메모리 누수는 일반적으로 3가지의 형태가 있습니다.
- 우발적으로 생성된 전역변수
- DOM 외부에서의 참조
- 클로저의 잘못된 사용
프로그래밍 언어의 메모리 관리 시스템이 특정 메모리가 실제 사용중인지 미사용중인지 완벽히 구분해내는 것은 사실상 불가능에 가깝습니다. 오직 그 코드를 작성한 개발자들만이 해당 메모리 조각을 운영체제로 반환시킬 수 있는지 여부를 명확히 알 수 있기 때문에 해당 부분들을 잘 확인하여 메모리 누수가 일어나는 부분을 막을 줄 알아야 합니다.
