🚦 본론

Symbol, 왜 필요한가.

Symbol이라는 타입은 7번째로 ES에서 표준화된 타입입니다.
(가끔 헷갈리는 것이 있는데, 그렇다고 자바스크립트에는 7개의 타입만 존재하는 것이 아닙니다. BigInt라는 타입도 존재합니다.)

하지만... 실제로 프로젝트할 때나 생각보다 쓰지는 않는 타입이라 잘 넘어가는 것이 현실인데요.
그렇지만, 표준화되었다는 것은 무언가가 문제되었다는 것이고, 따라서 이러한 문제점을 인지해야 하는 것이 우선입니다.

무엇이 문제였을까요?

상수 역시 한계는 존재한다.

우리는 책을 쭉 훑어보며, 어떠한 상태더라도 변경이 불가능한 상수라는 것을 확인했습니다.
하지만, 상수의 값을 베낄 수 있다면 어떨까요?
다른 변수로도 해당 변수가 아닌 로직에 접근하여 제어할 수 있다는 의미가 되므로 안전성이 떨어질 수 있습니다.

const Directions = Object.freeze({
	UP: 0,
  	DOWN: 1,
    LEFT: 2,
    RIGHT: 3
})

// 예시로, 한 번 다른 동결된 객체를 하나 더 생성한다.
const Direction = Object.freeze({
    UP: 3,
  	DOWN: 2,
    LEFT: 1,
    RIGHT: 0
})

// 현재 `Directions` 객체의 키들이 저장되어 있다.
const directionArr = Object.keys(Directions);

const moveCallback = (d) => {
    // 원하는 결과 값이 해당하는 프로퍼티 키를 토대로 출력될 것이다.
	console.log(`moved ${directionArr[d]}`); 
}

const move = (cb, direction) => {
	return moveCallback(direction)
}

// 실수로 인수로 다른 객체를 할당했고, 
// 결과적으로 로직은 동작하나 원하는 값이 출력되지 않는다.
move(moveCallback, Direction.UP) // moved RIGHT

즉, 누구나 원하는 상수값을 흉내낼 수 있기에, 안전성이 떨어진다는 것이지요.

누구나 접근할 수 있다는 문제점

또한, 접근을 할 수 있다는 것도 문제입니다. 특히 이는 빌트인 객체에 프로토타입을 새롭게 만들었을 때가 문제지요.

대체적으로 많이 만들어 쓰는 sum이 그렇습니다.

Array.prototype.sum = function () {
	return this.reduce((acc, cur) => acc + cur, 0)
}

만약 이러한 메서드가 실제로 표준화되었다면 어떻게 될까요?
그렇다면 표준화된 메서드가 쉐도잉되어, 결과적으로 이를 모르는 개발자들과의 작업시에 큰 혼동이 있겠지요? 😭

따라서 기존의 개발자들은 이런 생각을 하게 되었습니다.

"접근할 수가 없어 절대 충돌할 수 없는 안전한 타입 값이 없을까"

여러 표준화 논의에 걸쳐, 결국 이러한 기대에 부흥하는 값이 탄생했습니다. 그것이 바로 Symbol입니다.

사용법

생각보다 매우 간단합니다. 그저 Symbol 객체로 직접 감싸주면 됩니다.
이때, 중요한 건 감싸진 값은 string으로 암묵적 타입 변환이 발생하게 됩니다.

const hi = Symbol('hi'); // Symbol(hi)
// 타입은 string으로 변환이 된다.

const test = function() {
  console.log('test!')
};
const symbolTest = Symbol(test); 
// Symbol(function() {
//  console.log('test!')
// })

이러한 값은 고유의 값으로, 다른 문자열, 혹은 똑같은 값을 갖고 있는 심볼로도 비교가 불가능합니다.
(마치 주소값을 가지고 비교하는 것처럼 말이죠)

const hi = Symbol('hi'); // Symbol(hi)
console.log('hi' === hi) // false;

console.log(Symbol('hi') === hi) // false;

혹여나 만약, 내부의 값을 가져오고 싶다면 어떻게 해야 할까요?
이럴 때는 Symbol 프로토타입 객체 안에 내장된 Symbol.prototype.description를 사용하면 됩니다.

console.log(hi.description) // 'hi'

Symbol.for, Symbol.keyFor

그런데 만약 이런 심볼 타입이 여러 곳에 산재한다면, 이 역시 문제가 발생하겠죠?
따라서 이러한 심볼 값을 전역에서 관리해줄 수도 있습니다.
이러한 전역 심볼 레지스트리에 등록된 키와 값은, 일반 심볼로는 접근이 불가능해요.

const hi = Symbol('hi')
// keyFor은 전역 심볼 레지스트리에 등록된 심볼을 검색을 하는 메서드입니다. 
// 이때 전달받는 인수는 오로지 심볼 타입입니다.
console.log(Symbol.keyFor(hi)); // undefined

따라서 전역 심볼 레지스트리에 등록하는 방법은, Symbol.for입니다.
Symbol.for은 좀 특이하게 동작하는데요, 등록과 검색 모두 가능합니다.
일단 검색해보고, 안되면 직접 자기가 키와 값을 생성해버립니다.

그리고 Symbol.keyFor 메서드는 오직 검색만 가능한 기능을 하죠.
검색 결과는 심벌 값의 키이며, 없다면 undefined입니다.

const s = Symbol.for('hi');
console.log(Symbol.keyFor(s)); // 'hi'

프로퍼티 은닉화

프로퍼티를 숨길 수 있고, 충돌하지 않게 한다는 점은 안전하게 메서드를 관리할 수
있다는 장점을 주게 되었습니다.

const _s = (key) => Symbol.for(key)

Array.prototype[_s('sum')] = function () {
	return this.reduce((acc, cur) => acc + cur, 0)
}

console.log([1,2,3,4][_s('sum')]()) // 10

모양이 이상하지만, 만약 해당 프로퍼티를 토대로 좀 더 세밀한 접근자 프로퍼티를 생성한다면 어떨까요? 사용자들에게는 제대로 보이지 않으나 내부적으로 정상 기능을 하게 되고, 좀 더 안전한 코드 관리가 가능해지는 장점이 생깁니다.

잘 알려진 심볼 (Well-known Symbol)

이 친구들은 좀 범용적으로 우리가 사용하는 심볼들이에요.
이 친구들은 기본적으로 자바스크립트 엔진의 내부 알고리즘에 사용되는 친구들인데, 대표적으로 Symbol.iterator와 Symbol.search가 있습니다.

실제로 Symbol.iterator을 갖게된 객체는 iterable한 속성을 가질 수 있습니다. 아마 이것이 근간이 되어 for ... in ... 문법을 사용할 수 있게 된 것이 아닐까 추측하고 있습니다. (어마무시하죠?)

개인적으로 함수형 프로그래밍을 할 때도 유용하게 썼던 것 같습니다.

const iterableObject = {
    0: 1,
    1: 2,
    2: 3,
    3: 4,
    4: 5,
	[Symbol.iterator]() {
    	let cur = 0;
	    const max = Object.keys(iterableObject).length;
        
        return {
          next() {
            return { value: iterableObject[cur++], done: cur > max + 1 };
          }
        };
    }
};

// 이제는 객체 순회를 통해 값에 접근할 수 있군요! 😮
for (let i of iterableObject) {
	console.log(i)
}

// 1
// 2
// 3
// 4
// 5

이렇게 이터레이션 프로토콜을 심볼로 구현하니, 이제는 프로퍼티 키가 겹치는 것에 대한 두려움에서 벗어나게 되었다는 점이, 어떻게 보면 표준을 만들어내는 개발자 분들께는 꽤나 큰 위안이 될 것 같아요!

💡 그렇다면, Symbol.search는 무엇일까요?

이 친구는 인덱스 검색에 관한 메서드를 만드는 데 사용된 친구에요.
실제로 String.prototype.search (문자열이나 정규표현식 패턴에 맞춰 인덱스 검색을 반환하는 친구)를 사용할 때 호출된다고 하네요!

class SearchStr {
  constructor(value) {
    this.originalString = value;
    this.value = new RegExp(value);
  }
  
  [Symbol.search](string) {
    const idx = string.search(this.value);
    if (idx < 0) return null;
    
    return string.slice(idx, idx + this.originalString.length);
  }
}

// search로 호출될 때, 해당 원하는 로직이 반환되게끔 할 수 있어요 😉
console.log('Hello, World!'.search(new SearchStr('Wor'))); // Wor

🎉 마치며

'왜 내 프로젝트는 Symbol을 쓰지 않았을까'하며 지나친 후회는 하지 않으셔도 무방합니다.
실제로도 MDN에서도 해당 타입에 관하여 다음과 같이 말합니다.

Symbol 타입은 고도로 특화된 용도로 쓰이며, 범용성은 현저히 떨어집니다.

우리가 이를 안 썼다고 자책하기보다는, 좀 더 실용적으로 프로젝트를 했다고 생각하면 편할 것 같아요.

모든 개발은 리소스 싸움이라고 생각해요. 리소스 투입 대비, 얼마나 산출이 되는지에 따라 사람의 능력이 결정된다고 생각합니다.

만약 소소하고 작은 프로젝트에 이러한 타입을 사용한다면, 이는 어쩌면 바늘로 소 잡는 격일 수도 있으므로, 우리는 합리적으로 개발을 한 것이랍니다. 😉

그럼, 다들 오늘도 즐거운 코딩하시길 바라며. 이상! 🌈

📁 참고자료

MDN - Symbol