제네레이터란 무엇인가?

function* sequence(start=0, end=Number.MAX_SAFE_INTEGER, step=1)
{
    for(let value=start; value<end; value+=step)
    {
        yield value;
    }
}

const iterator = sequence(1, 4, 1);
iterator.next(); // {value:1, done: false}
iterator.next(); // {value:2, done: false}
iterator.next(); // {value:3, done: false}
iterator.next(); // {value:undefined, done: true}

for(let value of sequence(0, 6, 2))
{
    console.log(value); // 0, 2, 4가 순차적으로 출력됨
}
const arr = [...sequence(1,10,1)]; // [1,2,3,4,5,6,7,8,9]

쉽게 말하면, 순열을 생성하는 함수라고 할 수 있다. 그런데, 그 순열의 형태가 배열인 것이 아니라, 한 번 호출할 때마다 순차적으로 다른 값을 반환하는 객체 같은 형태(제네레이터 객체)로 생성된다.

파이썬이나 자바스크립트에서는 yield라는 문법을 이용하여 구현된다. 이 때, 제네레이터 객체가 한 번 소비되면(next 함수를 호출하거나, 반복문에서 한 번의 반복을 할 때를 의미한다) 제네레이터 함수에 있는 yield가 있는 문까지 실행되고 함수를 종료한다. 그리고 제네레이터 객체가 다음으로 소비될 때는 이전에 멈췄던 yield 다음 문부터 시작한다. 그렇기 때문에, 제네레이터 함수를 아무 때나 멈출 수 있고 상태를 유지하는 함수로 부르기도 한다.

자바스크립트에는 ES6부터 도입되었으며, 자바스크립트는 제네레이터 객체를 반복 가능 프로토콜과 반복자 프로토콜을 모두 준수하는 객체로 구현한다. 반복 가능 프로토콜과 반복자 프로토콜을 통틀어 이터레이션 프로토콜이라고 한다.

• 반복 가능 프로토콜(이터러블 프로토콜) : 객체에 Symbol.iterator 메소드가 구현되어 있다. 이 메소드의 반환값은 반복자 프로토콜을 준수하는 객체여야 한다. 이 프로토콜을 만족하면 객체를 for of문으로 순회할 수 있으며, 배열 구조 분해 할당으로 배열화할 수 있다.
• 반복자 프로토콜(이터레이터 프로토콜) : 객체에 next 메소드가 구현되어 있다. 이 메소드의 반환값은 {value, done} 형태의 객체여야 하다.

저자는 왜 제네레이터를 까고 있는가?

자바스크립트의 제네레이터는 엉성한 객체 지향 프로그래밍의 결과물입니다.

자바스크립트 제네레이터 객체를 사용하는 문법이 비직관적이기 때문이다. 저자는 자바스크립트의 제네레이터 문법을 만들 때 엉성한 객체 지향 프로그래밍의 패러다임을 버리지 못했다고 지적한다.

const iterator = sequence(1, 4, 1);
console.log(iterator.next().value); // 1
console.log(iterator.next().value); // 2

보는 바와 같이, 자바스크립트에서 수동으로 제네레이터 객체를 소비해 값을 얻기 위해서는 (이터레이터).next().value로 객체의 내용을 2번 추적해야 한다. 이 얼마나 번거롭고 비직관적인가! 자바스크립트의 제네레이터 문법을 모르는 사람들은 next가 무엇을 하는 것이며 왜 그 값의 value를 참조해야 하는지 모를 것이다.

function* sequence(start=0, end=Number.MAX_SAFE_INTEGER, step=1)
{
    for(let value=start; value<end; value+=step)
    {
        yield value;
    }
}

저자는 제네레이터 함수를 만드는 yield 문의 구조적 문제에 대해서도 지적한다. yield문은 근본적으로 명령을 중단하고 다시 시작한다는 의미를 갖고 있기 때문에, 제네레이터 객체가 한 번 소비될 때에만 집중하는 것이 아니라, 제네레이터 객체의 전체의 절차에 집중하게 되는 명령형 프로그래밍에 더 가깝게 프로그래밍하게 된다. 당연히, 여러 번 소비되는 제네레이터에 대해서는 for문과 같은 반복문을 사용할 수밖에 없고, 이것이 아름다운 프로그래밍을 하지 못한다고 저자는 지적한다. (저자는 for문과 같은 반복문을 좋게 보지 않는다.) 또한, 함수를 중단하고 재시도한다는 yield문의 특성상 실행 흐름의 추적이 어려워져서 예측 불가능한 프로그램이 생성될 수 있다는 문제도 있다고 한다.

대안-클로저 제네레이터

function closerSequence(start=0, end=Number.MAX_SAFE_INTEGER, step=1)
{
    let state = start; // initial value
    return function()
    {
        let value = state;
        state += step;
        if(state > end) return; // generator end condition
        return value; // generator yield value
    }
}

const iterator = closerSequence(1, 4, 1);
console.log(iterator()); // 1
console.log(iterator()); // 2

저자는 대안으로 클로저를 이용한 제네레이터 기능을 제안한다. 제네레이터를 클로저로 구현한다면, 자바스크립트의 제네레이터 문법에서 다음의 두 문제가 해결된다.

1. 제네레이터 객체를 소비하는 동작이 직관적이게 변한다. 상태가 있는 제네레이터 객체의 메소드를 호출하여 객체의 상태를 변경하고 결과값의 value를 호출하는 것보다, 그냥 제네레이터 객체를 소비한다는 동작으로 간단하게 변한다. 내부의 상태 등은 제네레이터 내부에 숨겨져 있다.
2. 제네레이터 함수를 만들 때, 한 번 소비할 때의 동작에만 집중할 수 있게 된다. 불필요한 for문은 제거되고, 이전의 상태와 현재 동작에만 집중하여 프로그래밍할 수 있게 된다.

물론, 클로저를 이용한 제네레이터의 구현은 자바스크립트의 클로저와 재귀함수에 대한 이해가 있어야 하며, 절차적으로 사고하는 초보 개발자들이 이해하기 어렵다는 문제는 있다. 또한, 자바스크립트의 이터레이션 프로토콜을 전혀 준수하지 않기 때문에, 바닐라 자바스크립트의 for of 문이나 배열 구조 분해 할당 등 유용한 기능을 사용하려면 별개의 변환 과정을 거쳐야 한다. 변환 함수는 다음에 소개하겠다.

클로저 제네레이터 변환 함수

function generatorToCloser(generator)
{
    return function()
    {
        return generator.next().value;
    }
}

const arr = [2025, 1, 3];
const iter = generatorToCloser(arr[Symbol.iterator]());

iter(); // 2025
iter(); // 1
iter(); // 3
iter(); // undefined

간단하게 바닐라 제네레이터 / 클로저 제네레이터 변환 함수를 만들어 봤다. 우선, 바닐라 제네레이터 객체를 클로저 제네레이터 함수로 변환하는 함수다. 인자로 바닐라 제네레이터 객체를 받으며, 각각의 제네레이터 소비 시에는 generator.next().value를 호출해 소비하는 것이 전부다.

function* closerToGenerator(generator)
{
    let yielder = generator();
    while(yielder !== undefined)
    {
        yield yielder;
        yielder = generator();
    }
}

function closerSequence(start=0, end=Number.MAX_SAFE_INTEGER, step=1)
{
    let state = start; // initial value
    return function()
    {
        let value = state;
        state += step;
        if(state > end) return; // generator end condition
        return value; // generator yield value
    }
}
const iter = closerToGenerator(closerSequence(0, 5, 1));
[...iter] // [0, 1, 2, 3, 4]

다음으로, 클로저를 바닐라 제네레이터 객체로 전환하는 제네레이터 함수다. 클로저 제네레이터를 인자로 받아, 바닐라 제네레이터 객체를 반환한다. 클로저 제네레이터를 값이 undefined가 나올 때까지 반복 호출하나, 값이 나왔을 때 yield문으로 제네레이터 외부로 값을 내보낸다. 이를 이용하면 클로저로 우아하게 제네레이터 코드를 작성하면서도 바닐라 자바스크립트의 이터러블 관련 기능도 누릴 수 있게 된다.

클로저 제네레이터의 예제와 해설

이 파트에서는 <자바스크립트는 왜 그 모양일까?>에 소개된 클로저 제네레이터 팩토리 함수를 각각 소개하고(본인의 스타일로 다시 구현했기에 원본 서적의 코드와 다를 수 있다.), 바닐라 자바스크립트의 제네레이터 문법으로는 어떻게 구현되는지 알아보도록 하겠다.

integer

function integer(start=0, end=Number.MAX_SAFE_INTEGER, step=1)
{
    let state = start;
    return function()
    {
        let value = state;
        state += step;
        if(step > 0 && state > end) return;
        if(step < 0 && state < end) return;
        return value;
    }
}

Python의 range와 비슷하게, 등차순열을 반환하는 제네레이터를 생성한다. from에서 시작하고, step만큼 이동하며, 만약 값이 end 값을 넘어간다면 제네레이터를 종료한다.

해설하자면, integer 팩토리 함수가 호출될 때, state 변수(와 integer 함수의 매개변수들)가 저장되어 있는 객체를 생성한다. 이후, 제네레이터 함수가 반환되는데, 제네레이터 함수는 integer 팩토리 함수가 생성한 state 변수가 있는 객체를 참조하고, state 변수의 값을 바꿀 수 있다. 이후 제네레이터 함수가 한 번 호출될 때마다, 다음을 실행한다.

1. 이전의 상태를 임시 값 value에 저장한다.
2. 상태를 갱신한다.
3. step과 state, end 값을 참조하여, 상태가 종료값의 범위를 넘어가면 undefined를 반환한다.
4. 그렇지 않다면, value를 반환한다.

이러한 동작을 통해, 제네레이터 함수가 호출될 때마다 함수가 참조하는 state 상태(함수가 생성될 떄 같이 생성되었다)를 변경시키고, 함수가 호출될 때마다 상태를 변경시키면서 순열을 반환하게 된다.

똑같은 동작을 바닐라 자바스크립트의 generator 문법으로 구현할 수 있다.

function* integer(start=0, end=Number.MAX_SAFE_INTEGER, step=1)
{
    let state = start;
    while(true)
    {
        let value = state;
        state += step;
        if(step > 0 && state > end) return;
        if(step < 0 && state < end) return;
        yield value;
    }
}

이 동작은 위의 클로저 제네레이터와 최대한 비슷하게 변환한 것이다. return function() 부분을 white(true)로, return value를 yield value로 변환하면 다를 바 없다. 무한루프가 일어나는 것으로 보이지만 실행 시 무한루프는 일어나지 않는데, 제네레이터 객체가 한 번 소비될 때마다 yield value 또는 return문에서 멈추기 때문이다.

element

function element(arr, generator = integer())
{
    return function(...args)
    {
        let index = generator(...args);
        if(index === undefined) return;
        return arr[index];
    }
}

배열을 순회하는 제네레이터를 생성한다. 기본적으로 배열을 인자로 받으며, 배열의 원소를 순차적으로 순회하는 순열을 생성한다.

이 제네레이터는 2번째 인자로 다른 제네레이터를 받을 수 있는데, 다른 제네레이터의 결과를 배열의 해당하는 원소로 매핑시키는 역할을 수행한다. 일종의 함자와 같은 역할이라고 할 수 있겠다. 만약 제네레이터에 배열처럼 map 메소드가 존재한다면, 다음과 같은 느낌일 것이다.

generator.map( item=>arr[item] )

함자란? : 간단히 말하면, 집합에 함수를 통째로 적용시켜서 다른 집합으로 바꾸는 것이다. 이 때 집합의 각 원소 간 상관관계는 보존된다. 더 간단히 말하면 그냥 map 연산이라고 생각하면 된다.

이 설명은 매우 단순화된 설명으로, 자세히 말하면 다음과 같다. 우리가 말하는 오브젝트가 있다. 오브젝트는 자연수나, 정수나, 문자열이나, 벡터나, 혹은 다른 집합이 될 수도 있다. 오브젝트와 오브젝트를 함수처럼 연관시킬 수도 있는데, 이를 범주론에서는 사상이라고 한다. 범주는 오브젝트와 사상을 모은 것이라고 할 수 있다. 여기서 우리는 범주를 다른 범주로 바꾸는 관계를 생각할 수 있을 것이다. 그걸 함자라고 하자. 함자는 대상을 다른 대상으로 바꾸는 것은 사상과 같으나, 사상 역시 다른 사상으로 바꿀 수 있다. 여기서 사상을 다른 사상으로 바꾼다는 것은 원소에 함자를 먼저 적용시킨 뒤 적용시키는 함수와, 원소에 함수를 먼저 적용한 뒤 함자를 적용하는 것이 같음을 의미한다. 함자는 항등사상(자기 자신을 반환하는 함수와도 같다)을 보존하며, 사상 합성(함수의 합성과도 같다) 역시 보존한다.

자바스크립트의 map 연산을 함자와 매우 유사한 역할을 하는 것로 볼 수 있는데, map 연산은 배열의 원소를 다른 원소로 치환하며, 배열의 원소 간 순서 관계를 사상이라고 생각한다면, 원소 간 순서는 변하지 않으므로 구조를 보존하면서 사상을 치환한 것이라고 할 수 있다.

똑같은 동작을 바닐라 자바스크립트의 generator 문법으로 구현할 수 있다.

function* element(arr, generator = integer())
{
    for( let index of generator )
    {
        yield arr[index];
    }
}

이 함수를 활용하여, 객체의 key를 순회하는 제네레이터 팩토리 함수를 추가로 만들 수도 있다.

function keys(obj)
{
    return element(Object.keys(obj));
}

property

function property(obj, generator = element(Object.keys(obj)))
{
    return function(...args)
    {
        let key = generator(...args);
        if(key === undefined) return;
        return [key, obj[key]];
    }
}

Object.entries와 비슷하게, key값과 value값의 튜플을 반환하는 제네레이터를 생성한다. 기본적으로 객체를 인자로 받으며, 객체의 key값을 순회하여 key와 value의 엔트리를 만든다. property 함수는 입력한 제네레이터 함수를 [item, obj[item]]과 같은 관계로 매핑한다.

똑같은 동작을 바닐라 자바스크립트의 generator 문법으로 구현할 수 있다.

function* property(obj, generator = element(Object.keys(obj)))
{
    for( let index of generator )
    {
        yield [index, arr[index]];
    }
}

collect

function collect(generator, arr = [])
{
    return function(...args)
    {
        let value = generator(...args);
        if(value === undefined) return;
        arr.push(value);
        return value;
    }
}

이 제네레이터 함수는 제네레이터를 그냥 실행하는 것과 동일하나, 사이드 이펙트를 발동시킨다. 제네레이터가 한 번 실행될 때마다, 인자로 받은 배열에 제네레이터의 결과를 추가한다. 함수 외부의 데이터를 변경시키는 사이드 이펙트가 발생하기 때문에 썩 좋은 설계라고 하기는 어렵다.

이 함수의 목적은 배열에 제네레이터의 결과를 저장하기 위함인데, 이렇게 변경한다면 순수성을 유지할 수 있을 것이다.

function pureCollect(generator)
{
    let arr = [];
    return function(...args)
    {
        let value = generator(...args);
        if(value === undefined) return;
        arr = [...arr, value];
        return arr;
    }
}

이 제네레이터 함수는 제네레이터를 지금까지 진행했던 제네레이터의 결과값으로 매핑시킨다. 결과적으로 제네레이터를 배열로 변환시키는 역할을 하긴 한다. 제네레이터를 순회할 때마다 새로운 배열 객체가 생성되어서 심각한 가비지 컬렉션을 일으킬 수 있지만, 적어도 순수성은 지킬 수 있다.

다른 방식으로 생각한다면, 배열로 축적한다는 것은 배열의 reduce 메소드와 비슷한 연산이라고 생각할 수도 있지 않을까? reduce와 비슷한 연산을 하도록 제네레이터를 확장해 보았다.

function reduce(generator, reducer, initial)
{
    let accumulator = initial;
    return function(...args)
    {
        let value = generator(...args);
        if(value === undefined) return;
        accumulator = reducer(accumulator, value);
        return accumulator;
    }
}

// 제네레이터의 값을 배열로 누적시키기 위해서는...
let harvester = reduce(generator, function(array, cur) {
    array.push(cur);
    return array;
}, []);

// 보다 엄밀한 순수성을 위해서는...
let pureHarvester = reduce(generator, function(array, cur) {
    return [...array, cur];
}, []);

이 제네레이터 함수는 원본 제네레이터 함수를 리듀서를 적용시킨 누산 결과값으로 변환시킨다. 구체적으로는, 다음과 같은 동작을 한다.

1. accumulator 상태를 선언한 뒤, initial 값으로 초기화한다.
2. 각 제네레이터가 실행될 때마다, 원본 제네레이터를 실행한 뒤, 값이 undefined면 제네레이터를 종료한다.
3. accumulator 상태와 제네레이터의 결과값을 기반으로 누산 연산을 수행하고, 값을 반환한다.

이제 reduce 제네레이터는 보다 순수해졌으며, 비순수성의 도입은 온전히 개발자의 몫이 되었다.

위의 collect 팩토리 함수와 reduce 팩토리 함수의 바닐라 generator 문법 버전은 다음과 같다.

function* collect(generator, arr)
{
    for(let item of generator)
    {
        arr.push(item);
        yield item;
    }
}

function* reduce(generator, reducer, initial)
{
    let accumulator = initial;
    for(let item of generator)
    {
        accumulator = reducer(accumulator, item);
        yield accumulator;
    }
}

repeat

function repeat(generator)
{
    if(generator() === undefined) return;
    return repeat(generator);
}

// 반복문 버전(더글라스 크락포드는 이 버전을 싫어할 것입니다)
function repeat(generator)
{
    while(generator() !== undefined) {};
}

제네레이터는 순열이므로, 순열을 반복해야 한다. 이 함수는 제네레이터도, 제네레이터 팩토리도 아니지만, 제네레이터를 반복해서 완전히 소비시키는 함수다. 반환값은 없다. 저자는 반복문을 싫어하기에 재귀를 이용했는데, 그 중에서도 return문에 함수의 실행값을 집어넣는 꼬리 재귀를 사용하였다. 하지만, 애석하게도 대부분의 자바스크립트 엔진은 꼬리 재귀 최적화를 지원하지 않기에, 많은 양의 반복이 요구되는 제네레이터를 넣으면 스택 오버플로가 뜰 것이다.

바닐라 자바스크립트에서는 그냥 for of 문 써서 반복시키면 된다.

harvest

function harvest(generator)
{
    const result = [];
    repeat(collect(generator, result));
    return result;
}

드디어 제네레이터를 배열로 만드는 함수가 등장했다. harvest 함수는 collect 함수와 repeat 함수의 조합으로, 제네레이터 함수가 소비되면서 result 배열에 그 결과가 저장되고, 완전히 소비되면 배열을 반환하는 형태다.

function harvest(generator)
{
    const result = [];
    const reducer = function(arr, value)
    {
        arr.push(value);
        return arr;
    }
    repeat(reduce(generator, reducer, result));
    return result;
}

이건 reduce 함수를 사용한 형태다. 배열을 선언한 뒤, 제네레이터의 값을 배열로 누적시킨 뒤 이를 반복하여 값을 반환한다.

바닐라 자바스크립트에서는 그냥 배열 구조 분해 할당을 사용하면 된다.

limit

function limit(generator, count = 1)
{
    let num = 0;
    return function(...args)
    {
        if(num >= count) return;
        num += 1;
        return generator(...args);
    }
}

제네레이터의 최대 호출 가능 횟수를 제한시키는 제네레이터를 생성한다. num이라는 내부 상태를 갖고, 제네레이터가 한 번 호출될 때마다 num의 값을 증가시킨다. 만약 미리 설정한 count보다 num 상태가 크거나 같으면 즉시 return하고, 그렇지 않다면 원본 제네레이터를 소비한다.

똑같은 동작을 바닐라 자바스크립트의 generator 문법으로 구현할 수 있다.

function* limit(generator, count = 1)
{
    let num = 0;
    for(let item of generator)
    {
        if(num >= count) return;
        num += 1;
        yield item;
    }
}

filter

function filter(generator, predicate)
{
    return function filterGenerator(...args)
    {
        let value = generator(...args);
        if(value === undefined) return;
        if(predicate(value)) return value;
        return filterGenerator(...args);
    }
}

// 반복문 버전
function filter(generator, predicate)
{
    return function(...args)
    {
        let value = generator(...args);
        while(value !== undefined && !predicate(value))
        {
            value = generator(...args);
        }
        return value;
    }
}

제네레이터와 predicate(술어 함수: boolean을 반환하는 함수)를 인자로 받아, 조건을 만족하는 제네레이터의 결과만 필터링하는 새 제네레이터를 생성한다. 이 제네레이터의 동작은 호출될 때마다 다음과 같이 이루어진다.

1. 우선 원본 제네레이터를 한 번 소비한다.
2. 현재 값이 undefined이면(제네레이터가 끝났으면) undefined를 반환한다.
3. 현재 값이 조건을 만족하면 해당 값을 반환한다.
4. 조건을 만족하지 않는다면, 제네레이터가 조건을 만족할 때까지 함수를 반복하여, 원본 제네레이터를 계속 소비한다.

4번의 동작으로 인해, 제네레이터가 반환한 현재 값이 조건에 만족하지 않는 경우 그 단계를 스킵하는 효과가 있으며, 이는 조건에 만족될 때까지 계속 반복된다.

이것은 바닐라 자바스크립트의 제네레이터 문법으로 다음과 같이 구현할 수 있다.

function filter(generator, predicate)
{
    for(let item of generator)
    {
        if(predicate(item)) yield item;
    }
}

바닐라 제네레이터 문법으로 구현된 부분은 return filterGenerator(...args)와 같이 재귀하는 부분에 대응하는 부분이 따로 보이진 않는데, for문과 조건문이 제네레이터를 소비하고, 조건에 맞지 않을 시 계속 반복하는 것을 내포하고 있기 때문이다.

concat

function concat(...generators)
{
    const generatorGenerator = element(generators);
    let currentGenerator = generatorGenerator();
    return function concatGenerator(...args)
    {
        if(currentGenerator === undefined) return;

        let value = currentGenerator(...args);
        if(value !== undefined) return value;

        currentGenerator = generatorGenerator();
        return concatGenerator(...args);
    }
}

여러 개의 제네레이터를 인자로 받아, 제네레이터를 순차적으로 실행한다. 도중 제네레이터가 끝나면 다음 순서의 제네레이터를 실행한다. 이 제네레이터의 동작은 다음과 같이 이루어진다.

1. 제네레이터 목록을 기반으로, 제네레이터를 순회하는 제네레이터(generatorGenerator)를 생성한다. generatorGenerator는 소비될 때마다 다음 제네레이터를 반환한다.
2. 첫 번째 제네레이터를 currentGenerator 상태에 저장한다.
3. 호출될 때마다, 현재 제네레이터 상태가 없다면, 즉 모든 제네레이터가 끝났다면 제네레이터를 종료한다.
4. 현재 제네레이터를 소비해서 값을 얻는다.
5. 값이 undefined가 아니라면 값을 반환한다.
6. 그렇지 않다면, currentGenerator를 다음으로 넘긴 뒤, currentGenerator가 값이 있는 제네레이터일 때까지 반복한다.

6번으로 인해, 제네레이터가 끝났다면 빈 제네레이터를 스킵하고, 비지 않은 제네레이터가 있을 조건에 맞을 때까지 함수를 반복시킨다.

function* innerGenerator()
{
    yield 1;
    yield 2;
    yield 3;
}

function* outerGenerator()
{
    yield "Hello!";
    yield* innerGenerator();
    yield "World!";
}

[...outerGenerator]; //["Hello!", 1, 2, 3, "World!"]

바닐라 자바스크립트의 제네레이터 문법에서는 yield*라는, 다른 제네레이터에 결과를 위임하는 문법이 있다. 이걸 이용하면, 제네레이터 함수 내에서 다른 제네레이터의 결과물을 순차적으로 반환할 수 있다.

이를 활용하여, concat 제네레이터 팩토리 함수를 바닐라 자바스크립트의 제네레이터 문법으로 아주 쉽게 구현할 수 있다.

function* concat(...generators)
{
    for(let generator of generators)
    {
        yield* generator;
    }
}

참고로 yield*문을 사용하지 않고는 이중 for of문을 이용하여 다음과 같이 구현할 수 있다.

function* concat(...generators)
{
    for(let generator of generators)
    {
        for(let item of generator)
        {
            yield item;
        }
    }
}

join

function join(func, ...generator)
{
    return function()
    {
        let consumed = generator.map( gen=>gen() );
        if(consumed.every( value=>value===undefined )) return;
        return func( ...consumed );
    }
}

여러 개의 제네레이터와 한 개의 함수를 받아, 제네레이터를 한 번에 소비하고 소비된 값에 대한 함수의 결과를 반환하는 제네레이터를 생성한다. concat 제네레이터 팩토리가 제네레이터를 순차적으로 실행한다면, join 제네레이터 팩토리는 여러 개의 제네레이터를 병렬적으로 실행시키는 셈이 된다. 추가로, 제네레이터의 결과를 함수에 적용시키는 꼴이 되므로, 인자로 1개의 제네레이터를 넣는다면 마치 map과 같은 효과를 얻을 수 있다.

이 제네레이터는 실행될 때마다 다음을 수행한다.

1. 제네레이터 배열을 한 번에 실행하여, 제네레이터를 실행한 결과로 매핑한다.
2. 만약 모든 제네레이터 배열이 끝났다면, 제네레이터를 종료한다.
3. 제네레이터 실행 결과를 함수에 넣은 값을 반환한다.

1번으로 인해 여러 제네레이터를 동시에 소비할 수 있으며, 3번으로 인해 여러 제네레이터 함수가 func(...gen)과 같은 형태로 매핑된다.

앞서 join 제네레이터 팩토리가 매핑의 역할을 한다고 말했으므로, 비슷하게 제네레이터를 매핑시키는 element, property를 join을 이용해 재구성할 수 있다.

function element(arr, generator = integer())
{
    return join( (index)=>arr[index], generator );
}
function property(obj, generator=element(Object.keys(arr)))
{
    return join( (key)=>[key, arr[obj]], generator );
}

이것은 바닐라 자바스크립트의 제네레이터 문법으로 다음과 같이 구현할 수 있다.

function* join(func, ...generator)
{
    while(true)
    {
        let consumed = generator.map( gen=>gen.next() );
        if(consumed.every( ({done})=>done===true ) ) return;
        yield func( ...consumed.map( ({value})=>value ) );
    }
}

바닐라 자바스크립트의 제네레이터 함수는 undefined가 묵시적인 끝으로 취급되는 클로저형 제네레이터와는 달리, undefined가 값이더라도 제네레이터가 끝이 아닐 수 있다.

번외 - 재귀적 제네레이터는 어떻게 구현할까?

function* permutation(arr, count, accumulator=[])
{
    if(count <= 0) {
        yield accumulator;
        return;
    }
    for(let i=0; i<arr.length; i++)
    {
        const rest = arr.toSpliced(i, 1);
        yield* permutation(rest, count-1, [...accumulator, arr[i]]);
    }
}

자바스크립트의 제네레이터 문법 중 yield* 문을 적절히 활용하면, 재귀적인 제네레이터를 구현할 수 있다. 위의 코드는 arr 중 count만큼 뽑는 순열을 생성하는 제네레이터 코드인데, 동작은 다음과 같다.

1. count가 0보다 작거나 같으면, 누산된 결과를 그대로 반환한다.
2. 그렇지 않다면, arr의 각 원소에 대해, 다음을 반복한다.
3. arr에서 원소 하나를 제거한 나머지 배열 rest를 만든다.
4. rest와 count-1, 그리고 누산된 결과를 추가해서 새로운 순열을 그대로 반환시킨다. 이 때, 반환되는 순열의 꼴은 [기존 accumulator, arr[i], permutation(rest, count-1)]과도 같을 것이다.

function permutation(arr, count)
{
    if(count <= 0) return ()=>undefined;
    if(count === 1) return join(value=>[value], element(arr));

    const childPermutation = arr.map( (item, i)=>{
        const semiPermutation = permutation(arr.toSpliced(i,1), count-1);
        return join(value=>[item, ...value], semiPermutation);
    } );
    return concat(...childPermutation);
}

이것의 경우, yield*문이 concat으로 변환되며, 조건에 맞는 자기 자신 제네레이터를 연결하는 것으로 해결할 수 있다. 위의 permutation 제네레이터가 아래의 코드로 어떻게 변환되었는지 알아보자.

1. 위의 코드는 재귀적인 permutation으로 나온 제네레이터와, arr[i]를 합성시킬 수 없어서, 임의로 accumulator라는 매개변수를 넘겨서 작성되었다. 만약 제네레이터를 매핑하는 map 함수가 있다면, 다음과 같이 코드를 변경시킬 수 있다.

   function* permutation(arr, count)
   {
    if(count <= 0) return;
    if(count === 1)
    {
        yield* arr.map( value=>[value] );
        return;
    }
    for(let i=0; i<arr.length; i++)
    {
        const rest = arr.toSpliced(i, 1);
        yield* map(permutation(rest, count-1), (value)=>[arr[i], ...value]);
    }
   }

   내부적으로만 쓰면서 외부의 결과를 방해할 우려가 있는 accumulator는 제거되었으며, map 함수로 제네레이터를 변화시킴으로써 좀 더 재귀 제네레이터를 명확히 이해하게 되었다. 종료 조건도 변화되었는데, count가 0 이하일 경우에는 즉시 종료, count가 1일 경우에는 배열의 각 원소에 배열을 씌운 결과를 그대로 제네레이터 형태로 반환하도록 했다.

2. 1번에 의해 변환된 코드를 차례대로 변환해 보자. 우리가 이제부터 만들 제네레이터 팩토리 함수는 제네레이터처럼 행동하는 함수를 반환한다. 우선 if(count <= 0) return;의 경우, 제네레이터가 즉시 종료되므로, ()=>undefined를 반환하도록 바꾼다.

3. if(count === 1) 부분의 경우, 순회 가능한 arr을 value=>[value]로 변환한 결과를 반환하고 있다. 이는, element(arr)에 value=>[value]를 매핑한 결과로 변환할 수 있다. if(count === 1) return join(value=>[value], element(arr));로 변환한다.

4. 대망의 나머지 부분이다. yield* map(permutation(rest, count-1), (value)=>[arr[i], ...value]);를 반복해서 반환하는 것에서 볼 수 있듯이, 제네레이터를 순차적으로 실행한다. 우리는 이걸 concat 팩토리 함수를 이용해 바꿀 것이다. map(permutation(rest, count-1), (value)=>[arr[i], ...value])이라는 결과가 각각의 배열의 원소에 대해 반복되고 있으므로, 원래 배열에 대해 map 함수를 이용하여 제네레이터를 생성한다. permutation 팩토리 함수가 제네레이터 함수를 반환한다고 하면, permutation(arr.toSpliced(i,1), count-1)은 제네레이터다. 여기에, 제네레이터를 매핑하는 join 함수를 이용해 arr을 join(value=>[item, ...value], semiPermutation)으로 매핑해준다.

5. 이렇게 변환된 제네레이터 배열을 순차적으로 실행해야 하므로, concat 팩토리 함수에 넣는다. concat 팩토리 함수는 제네레이터 함수를 반환하므로 문제가 없다.

const MyContext = createContext();

function Child1()
{
  console.log("child 1 rerender");
  return <div>Child 1</div>
}
function Child2()
{
  console.log("child 2 rerender");
  const light = useContext(MyContext);
  return <div>{light ? "light" : "dark"}</div>
}

function App() {
  console.log("app rerender");
  const [light, setLight] = useState(true);
  const [count, setCount] = useState(0);

  return (
    <>
      <MyContext.Provider value={light}>
        <Child1 />
        <Child2 />
      </MyContext.Provider>
      <div onClick={()=>setLight( l=>!l )}>변화</div>
      <div onClick={()=>setCount( l=>l+1 )}>{count}</div>
    </>
  )
}

이런 코드를 짰을 때, light 상태를 변화시키면 자식 컴포넌트가 모두 리렌더링되는 경험을 볼 수 있을 것이다. 그래서 사람들은 "Context Provider의 value가 바뀌면 자식이 모두 리렌더링되는구나! 렌더링에 안 좋겠네?"라고 생각하게 될 것이다.

물론, 이 코드에서 "변화" 버튼을 누르면 Child1과 Child2가 리렌더링되는 건 맞으나, Child1이 리렌더링되는 까닭은 Context Provider가 바뀌기 때문이 아니라, 그냥 App의 state가 바뀌었기 때문이다. 부모 컴포넌트의 state가 바뀌면 부모가 렌더링되고, 자식도 같이 렌더링되기 때문이다.

Context.Provider의 상태와 렌더링은 무관하다?

const MyContext = createContext();

function Child1()
{
  console.log("child 1 rerender");
  return <div>Child 1</div>
}
function Child2()
{
  console.log("child 2 rerender");
  const light = useContext(MyContext);
  return <div>{light ? "light" : "dark"}</div>
}

const MemoWrapper = memo( ()=>{
  return <>
    <Child1 />
    <Child2 />
  </>
});

function App() {
  console.log("app rerender");
  const [light, setLight] = useState(true);
  const [count, setCount] = useState(0);

  return (
    <>
      <MyContext.Provider value={light}>
        <MemoWrapper />
      </MyContext.Provider>
      <div onClick={()=>setLight( l=>!l )}>변화</div>
      <div onClick={()=>setCount( l=>l+1 )}>{count}</div>
    </>
  )
}

이 경우에는 변화 버튼을 클릭했을 때, MemoWrapper에 props가 변화하지 않아서 MemoWrapper가 리렌더링되지 않음에도 불구하고, Child2는 리렌더링되고 있다. MyContext.Provider의 value가 바뀌었고, Child2가 MyContext를 소비하고 있기 때문이다.

즉, useContext는 다음의 2개의 역할을 한다.

• Context 매개변수를 받아서, 가장 가까운 부모의 Context.Provider를 찾아서, 그것의 value를 반환한다.
• 해당 Context.Provider를 구독하고, value가 바뀔 때 상태 변화와 관계없이 리렌더링을 수행한다.

정리

Context API를 이용해서 상태를 관리할 때, 하위 컴포넌트를 memo로 감쌌을 때와 감싸지 않았을 때의 동작은 다음과 같다.

• memo로 감싸지 않는 경우
  • Provider 자신 : state가 바뀌었기 때문에 리렌더링된다.
  • 컨텍스트를 소비하는 컴포넌트 : 부모 컴포넌트가 렌더링되기 때문에(+context.provider의 value가 바뀌었기 때문에) 리렌더링된다.
  • 컨텍스트를 소비하지 않는 컴포넌트 : 부모 컴포넌트가 렌더링되기 때문에, 리렌더링된다.
• memo로 감싸는 경우
  • Provider 자신 : state가 바뀌었기 때문에 리렌더링된다.
  • 컨텍스트를 소비하는 컴포넌트 : context.provider의 value가 바뀌었기 때문에 리렌더링된다.
  • 컨텍스트를 소비하지 않는 컴포넌트 : 리렌더링되지 않는다.

작성자는 웹 컴포넌트에 관심이 많다. 웹 컴포넌트는 브라우저에서 컴포넌트 단위로 프론트엔드 개발을 할 수 있게 하는 웹 API의 집합이라고 할 수 있는데, 웹 컴포넌트를 잘 쓰면 어떠한 라이브러리 없이도 컴포넌트의 마운트, 언마운트 등 생명주기를 관리할 수 있으며, _다양한 웹 프레임워크에서 일관되게 동작할 수 있다_는 이점이 있다.

하지만, 단점은 웹 컴포넌트의 기반이 되는 custom element API가 모던 리액트 생테계가 좋아하는 함수형 방식이 아닌, 클래스 기반으로 이루어져 있다는 것이다. 그래서 함수형 컴포넌트를 custom element로 바꿔서 등록시키는 라이브러리를 만들어보고 싶었는데, 감이 잡히지 않았다.

그래서, custom element 기반 웹 라이브러리인 lit을 함수형으로 쓸 수 있게 만드는, functional-lit-element의 구조를 분석해보기로 했다. lit은 HTMLElement를 상속하는 LitElement를 상속하는 클래스형 컴포넌트를 만들어서 컴포넌트 기반 프로그래밍을 할 수 있는 경량화된 라이브러리다. functional-lit-element는 함수형으로 짠 컴포넌트를 LitElement로 변경해주는데, 이 코드를 분석하면 작성자가 원하는 함수형 컴포넌트를 custom element로 바꿔서 등록하는 아이디어를 찾을 수 있을 것이라고 생각했다.

functional-lit-element가 뭔데?

functional-lit-element: A wrapper for LitElement which provides an API similar to React functional components.

import {LitElement, html} from "lit-html";
import functionalElementFactory from "functional-lit-element";

const functionalElement = functionalElementFactory(LitElement);

function MyComponent({className, caption}, {useState})
{
    const [counter, setCounter] = useState(0);
    return html`
        <div class=${className}>
            <div class="caption">${caption}</div>
            <div @onClick=${()=>setCounter(state=>state+1)}>${counter}</div>
        </div>
    `;
}

const todoItemComponent = functionalElement(MyComponent);
customElements.define("todo-item", todoItemComponent);

간단히 말하면, 위의 코드와 같이 리액트의 함수형 컴포넌트스럽게 짠 함수형 컴포넌트를 LitElement를 상속하는 클래스형 컴포넌트로 변환시키는 라이브러리다.

이 라이브러리는 functionalElement라는 함수를 제공하며, 해당 함수에 인자로 들어가는 함수형 컴포넌트는 다음의 규칙을 갖는 함수여야 한다.

• 매개변수는 2개다.
  • 첫 번째 매개변수에는 props 객체가 들어간다. 객체 구조 분해 할당으로 각 props를 가져올 수 있다.
  • 두 번째 매개변수에는 hooks 객체가 들어간다. 객체 구조 분해 할당으로 실제로 사용하는 hooks를 가져올 수 있다. 리액트에서는 미리 라이브러리에서 export된 훅을 가져다가 썼지만, 여기서는 함수의 인자로 가져와야 한다는 것이 차이점이다.
• 반환값은 Lit이 렌더링할 수 있는 값이어야 한다.
  • 주로 Lit이 제공하는 html 태그드 템플릿을 이용한 값이 들어간다.

이렇게 정의한 함수형 컴포넌트를 functionalElement 함수에 집어넣고, 반환된 LitElement를 customElements.define으로 브라우저에 등록시키면 된다.

엔트리포인트

이 라이브러리가 반환하는 메인 함수인 functionalElement는 functionalElementProvider라는 함수의 리턴값으로, 매개변수로 LitElement와 createUseState 등 useState의 생성 함수를 받는다.

이 라이브러리의 브라우저 버전은 functionalElementProvider를 사용하는 것은 동일하나, LitElement를 사용자가 외부에서 주입해야 한다는 점이 차이점이다. 브라우저에서 모듈식 프로그래밍을 하지 않는 경우를 대비하기 위해, FunctionalLitElement 라이브러리를 LitElement를 번들링하는 것을 피하도록 설계된 것으로 보인다.

functionalElementProvider는 dependency를 받아, render 함수를 받아 클래스형 Lit Component를 반환하는 함수를 리턴하는 고차함수다. 이것의 리턴값을 즉, 우리는 render 함수를 받아 클래스형 Lit Component를 반환하는 함수를 사용하게 되는 것이다.

functionalElementProvider

render, props, styles 매개변수를 받아서 LitComponent를 extends한 클래스를 반환한다. 이 중 props와 styles는 반환하는 클래스의 static 메소드를 정의하는 데 쓰인다.

getProps()

const getProps = (element) => Object.keys(props).reduce((renderProps, propName) => {
    renderProps[propName] = element[propName];
    return renderProps;
}, {});

getProps는 element 객체를 받아서 객체를 반환한다. 이 함수에서는 외부에 있는 props 객체의 key값을 통해 객체를 쌓아올리는 과정을 수행하는데, 새 객체에 기존 element 객체의 value를 그대로 대입하고 있다.

getProps 함수는 기존 엘리먼트에 존재하는 여러 프로퍼티 중 props의 key로 지정된 프로퍼티를 필터링하는 함수라고 보면 될 것 같다. 이 함수는 실제 커스텀 엘리먼트 객체 중 어떤 것이 의미 있는 props인지 정의하기 위해 필요하다.

static properties()

static get properties() {
    const dynamicState = {
        _dynamicState: {type: Object},
        _dynamicReducerState: {type: Object},
        _context: {type: Object}
    };
    return Object.assign({}, dynamicState, props);
}

어렵지 않다. 내부에서 정의하는 _dynamicState, _dynamicReducerState, _context 상태와 기존에 존재하던 상태 정의 객체인 props 객체를 합쳐서 새 객체로 만들어 준다.

스프레드 연산자로 더 쉽게 표현하면 이렇게 표현할 수 있다.

static get properties() {
    const dynamicState = {
        _dynamicState: {type: Object},
        _dynamicReducerState: {type: Object},
        _context: {type: Object}
    };
    return {...dynamicState, ...props};
}

constructor()

constructor() {
    super();
    this._dynamicReducerState = new Map();
    this._dynamicState = new Map();
    this._context = new Map();

    this._reducerStateKey = 0;
    this._stateKey = 0;
    this._effectKey = 0;
    this._effects = [];
    this._effectsState = new Map();

    this._contextListeners = new Map();
    this._contextParents = new Map();

    this._createHooks();
}

_createHooks() {
    this._hooks = {};
    this._hooks.useState = createUseState(this);
    this._hooks.useEffect = createUseEffect(this);
    this._hooks.useReducer = createUseReducer(this);
    this._hooks.useContext = createUseContext(this);
    this._hooks.provideContext = createProvideContext(this);
}

hook에서 쓰이는 내부 상태들을 초기화해서 클래스의 인스턴스에 할당한다.

바닐라 자바스크립트에서 리액트의 함수형 컴포넌트를 구현하는 데에 있어서 주안점은 다음과 같다.

• 어떻게 하면 서로 다른 컴포넌트에서 useState를 호출했을 때 일관된 값을 가져올 수 있을까?
• 어떻게 하면 여러 useState를 호출했을 때 일관된 값을 가져올 수 있을까?

functionalLitElement는 근본적으로 클래스인 LitElement를 반환하기 때문에, 클래스의 이점인 메소드의 실행 주체를 기억하는 것을 활용할 수 있다. functionalLitElement는 첫번째 문제를 createUseState에 this를 넘겨주는 방식으로 해결한다. createUseState가 반환하는 함수는 this, 즉 클래스의 인스턴스 자기 자신을 알고 있게 된다.

두 번째 문제는 전통적인 함수형 컴포넌트 구현 방식처럼, hook을 호출한 순서를 따로 기록해두는 방식으로 각각의 hook을 구분하는 방식으로 해결한다. (this._stateKey = 0;)

참고 : 바닐라 자바스크립트로 리액트 훅 구현 방법

1번의 경우는 여러 가지 방법이 있을 수 있다. 공통적으로는 함수형 컴포넌트를 평가할 때 렌더링하는 함수의 실행 순서와 useState의 호출 순서가 동일하다고 가정하고, 외부 변수에 저장하는 아이디어를 채택하고 있다.

가장 간단하게는, useState의 호출 순서를 기록해두고, 호출된 순서에 맞는 값을 가져오는 것이다. 하지만, 중간에 useState를 호출하는 컴포넌트가 제거되거나 추가될 경우 state가 꼬일 수 있다는 단점이 있다.

좀 더 복잡하게는, 컴포넌트를 렌더링할 때 자식 엘리먼트로 함수의 실행 값이 아닌 함수를 넘겨주고, 함수에 상태값을 바인딩하거나, 함수와 부모 함수를 기반으로 key값을 만들어서 그것을 기반으로 값을 가져오거나, 더 복잡하게는 현재 가상 dom의 렌더링 트리를 모사한 상태 트리를 만들어서 트리 상에서 일치하는 상태를 가져오는 방법도 있다.

2번의 경우 1번과 유사하게, 동일 컴포넌트에서 hook의 호출 순서가 동일하다고 보장하고(실제로 react에서는 조건부로 hook을 생성하는 조건부 hook을 금지하고 있다.), 호출 순서를 기록하는 방식으로 구현할 수 있다.

    function ReactMaker()
    {
        const stateStore = new ReactStateMap();
        let currentRenderKey = null;
        let currentRenderStatePointer = 0;
        let rootElement = null;
        useState(initialKey)
        {
            const state = stateStore.get(currentRenderKey, currentRenderStatePointer);
            currentRenderStatePointer++
            function setState(newValue)
            {
                stateStore.set(currentRenderKey, currentRenderStatePointer, newValue);
                render();
            }
            return [state, setState];
        }
        render()
        {
            currentRenderKey = makeKey(rootElement.renderFunction);
            currentRenderStatePointer = 0;
            rootElement.renderFunction();
            // 자식 엘리먼트 렌더링
        }
        createReact(el, rootElement_)
        {
            rootElement = rootElement_;
            // 초기화 함수
        }
        return {useState, createReact};
    }

> 
> 대충 짭액트가 저렇게 구성된다고 보면 될 것 같다.(실제 리액트는 저렇게 안 생겼을 확률이 매우 높다.)


### render()

```jsx
render() {
    super.render();
    this._resetHooks();
    const hooks = {
        useState: this._hooks.useState,
        useEffect: this._hooks.useEffect,
        useReducer: this._hooks.useReducer,
        useContext: this._hooks.useContext,
        provideContext: this._hooks.provideContext,
    };
    const template = render(getProps(this), hooks);
    this._runEffects();
    return template;
}

render 함수는 state가 변경되면 실행되는 메소드다. 다음의 방식으로 실행된다.

1. hook 상태를 초기화한다. useState, useEffect 등 훅을 구분하기 위한 포인터를 0으로 초기화한다.
2. this._hooks에 저장된 훅을 별도의 hooks 객체로 복사한다. const hooks = {…this._hooks}와 동일하다.
3. 함수형 컴포넌트를 실행한다. 이 때, getProps 함수로 반환된 props와 hooks를 인자로 넣는다. 이를 통해 내부에서 클래스의 인스턴스로 바인딩된 훅을 함수형 컴포넌트 내에서 사용할 수 있으며, hook이 호출되면 클래스 인스턴스의 상태를 변경시킨다.
4. 함수형 컴포넌트가 호출되면서 useEffect로 등록된 이펙트를 실행한다.
5. 함수형 컴포넌트가 반환한 템플릿을 반환한다. 이를 기반으로 LitElement 내부에서 실제 dom으로 렌더링을 수행한다.

_runEffect()

_runEffects() {
    return this._effects.map((effect) => {
        return new Promise((resolve, reject) => {
            try {
                return resolve(effect());
            } catch (e) {
                reject(e);
            }
        });
    });
}

useEffect의 실행 과정에서 등록된 사이드이펙트 함수들을 실행한다. 따로 effect()의 결과 함수를 어딘가에 저장하는 부분은 없으므로, 실제 리액트의 useEffect에 있는 cleanup code는 딱히 구현하지 않은 걸로 보인다.

실제 useEffect에서는 dependency 배열을 받아서 해당 배열의 값이 달라질 때 콜백 함수를 실행시키는데, 여기에서 이 부분 처리 로직은 useEffect 내부에 있다.

createUseState

export const createUseState = (element) => {

    const getState = (key) => {
        return element._dynamicState.get(key);
    };

    const setState = (key, value)  => {
        const newState = new Map(Array.from(element._dynamicState.entries()));
        newState.set(key, value);
        element._dynamicState = newState;
    };

    // useState hook
    return (defaultValue = null) => {
        const currentStateKey = element._stateKey;

        if (getState(currentStateKey) === undefined) {
            setState(currentStateKey, defaultValue);
        }

        const changeValue = (newValue) => {
            setState(currentStateKey, newValue)
        };

        element._stateKey++;
        return [getState(currentStateKey), changeValue];
    };
};

동적인 상태를 관장하는 useState 훅은 반환하는 createUseState 함수는 3개의 부분으로 구성된다.

getState

컴포넌트의 _dynamicState 맵에서 key를 찾아서 value를 반환한다.

setState

원래 맵의 엔트리를 복사해서 새 Map 객체를 만든 뒤, 해당 Map에 key - value를 설정해서 새 값을 넣는다. 이후, 컴포넌트의 _dynamicState 프로퍼티를 해당 Map 객체로 변경한다.

useState

컴포넌트의 _stateKey를 받아와 별도의 변수에 저장하고, 현재 호출 중인 useState와 실제 데이터를 매칭시킨다. 참고로 별도의 변수에 저장하지 않으면 changeValue를 호출할 때 changeValue가 가리키는 변수의 실제 주소를 보장하지 못한다는 문제가 생긴다.

만약 실제 데이터가 undefined이면 defaultValue로 초기화한다. 단, 어떤 미치광이가 setState(undefined)를 호출해서 undefined를 상태로 넣으면 다시 defaultValue가 된다는 잠재적인 문제가 있다.

changeValue는 내부에서 정의한 setState를 newValue 하나로 호출하도록 래핑해준다. 단 실제 리액트의 useState처럼 이전 함수에 따라 새 값으로 변경하는 건 불가능한 듯하다.

모든 함수의 내부 실행이 끝나면, element의 _stateKey를 1 올린다. 참고로 _stateKey는 함수형 컴포넌트가 실행되기 직전에 0으로 초기화되므로 같은 useState는 같은 __stateKey를 갖는 것이 보장된다.

리팩토링?

사실 key는 int형 자료형이라서, _dynamicState를 굳이 map으로 선언할 필요는 없어 보인다. 배열을 사용하고, 실제 useState처럼 함수를 받을 수 있도록 바꿔보면 다음과 같이 바꿀 수 있다.

export const createUseState = (element) => {

    const getState = (key) => {
        return element._dynamicState[key];
    };

    const setState = (key, value) => {
        const newState = [...element._dynamicState];
        if(typeof value === "function") newState[key] = value(newState[key]);
        else newState[key] = value;
        element._dynamicState = newState;
    };

    // ... 원래 것과 동일
}

createUseEffect

export const createUseEffect = (element) => {

    const getEffectState = (key) => {
        return element._effectsState.get(key);
    };

    const setEffectState = (key, value)  => {
        const newState = new Map(Array.from(element._effectsState.entries()));
        newState.set(key, value);
        element._effectsState = newState;
    };

    const addEffect = (effect) => {
        element._effects.push(effect);
    };

    const effectStateHasChanged = (stateToWatch, key) => {
        const effectState = getEffectState(key);
        if (effectState.length === 0) {
            return false;
        }

        for(let i = 0; i < stateToWatch.length; i++) {
            if (effectState[i] !== stateToWatch[i]) {
                return true;
            }
        }
        return false;
    };

    // useEffect hook
    return (effect, stateToWatch = undefined) => {
        // If no state to watch, run effect every time
        if (stateToWatch === undefined) {
            addEffect(effect);
            return;
        }

        const currentKey = element._effectKey;

        // If first time useEffect called, set the effect state to watch and run effect
        if (getEffectState(currentKey) === undefined) {
            setEffectState(currentKey, stateToWatch);
            addEffect(effect);
            return;
        }

        // see if state has changed to decide whether effect should run again
        if (effectStateHasChanged(stateToWatch, currentKey)) {
            addEffect(effect);
        }

        setEffectState(currentKey, stateToWatch);
        element._effectKey++;
    }
};

상태 변경에 따른 사이드이펙트를 관장하는 useEffect 훅은 다음의 방식으로 동작한다.

useEffect

• stateToWatch가 undefined이면 모든 경우에 사이드이펙트가 실행되므로, 사이드이펙트를 컴포넌트에 등록시키고 함수를 종료한다.
• 그렇지 않을 경우, 이전 의존성 배열과 현재 의존성 배열의 변경을 비교해야 한다. 해당 부분은 컴포넌트의 _effectState 프로퍼티에 저장되어 있으며, 동일한 useEffect마다 동일한 _effectState를 참조해야 하므로, _effectKey라는 참조 변수를 이용한다.
  • 의존성 배열의 상태가 없으면, useEffect가 가리키는 의존성 배열를 초기화하고 이펙트를 무조건 등록시킨다.
  • effectStateHasChanged 함수를 호출하여, 직전 의존성 배열과 현재 의존성 배열을 비교한다. 만약 다르다면, 이펙트를 등록시킨다.
  • 의존성 배열을 현재 의존성 배열으로 초기화하고, _effectKey를 1 증가시킨다.

getEffectState

컴포넌트에 등록된 _effectsState Map에서 key에 해당하는 값을 가져온다. _effectsState 맵은 함수형 컴포넌트가 가지고 있는 현재 의존성 배열들의 상태가 저장되어 있다.

setEffectState

컴포넌트에 등록된 _effectsState Map을 기반으로 내용이 동일한 새 맵 객체를 생성하고, key에 해당하는 값을 변경시킨 뒤 _effectState를 변경시킨다.

참고로 _effectState의 변경에 따라서 컴포넌트가 리렌더링되는 건 아니다. LitComponent의 properties에 등록되어 있지 않기 때문이다.

addEffect

컴포넌트의 _effects 배열에 인자로 받은 함수를 추가한다.

참고로 _effects 배열은 컴포넌트의 render 메소드가 호출될 때 매번 빈 배열로 초기화되므로, 직전 렌더링 시간에 등록된 사이드이펙트가 또 실행되지는 않는다.

effectStateHasChanged

컴포넌트의 _effectState Map에서 key의 직전 의존성 배열을 가져온다.

현재의 의존성 배열을 기준으로 반복문을 돌리면서 배열이 일치하는지를 파악한다.

만약 달라진 부분이 존재하면 true를 반환하고, 모든 배열의 원소가 일치하면 false를 반환한다.

참고로, 새롭게 생성된 의존성 배열의 원소가 없으면 false를 반환한다.

어떤 미치광이가 의존성 배열의 원소 수를 렌더링할 때마다 다르게 한다면 오류가 날 가능성이 높아지지만, 그 누구도 그렇게 함수형 컴포넌트를 짜지 않으므로 무시해도 좋다.

1차 코딩테스트

실제로 준비했던 것

여태까지 했던 것처럼 프로그래머스 2단계~3단계 문제를 풀면서 준비했다. 3기 후기를 보았을 때 난이도가 거지같이 나온다고 들었기에, 2단계 문제풀이보다 3단계 문제풀이에 집중했던 것 같다.

모의테스트를 보고, 구름 코딩테스트에 익숙해져야 한다고 느꼈다. 그래서 자바스크립트 구름 입출력 코드를 참조해서, 실제 구름 코딩테스트 환경에서 예시 문제를 몇 개 풀어보면서 입출력에 익숙해지는 시간을 가졌다.

회고하면서, 어떻게 준비해야 좋았는가

실제로 코딩테스트 문제를 풀면서, 3기 후기에서 작성했던 것보다는 확실히 쉽게 나온 것 같다고 느껴졌다. 다익스트라 알고리즘 같은 고급 알고리즘을 요구하지는 않았고, 코딩테스트의 기본 유형에 익숙해지고 자유롭게 구사할 수 있을 정도로 준비하면 좋을 것이라고 생각했다. 추가로 구현 문제는 프로그래머스 3단계 수준까지 풀어보는 게 좋다. 특히, 구름 코딩테스트의 특성상 문자열 형태의 데이터가 입출력으로 주어지기에, 문자열을 다루는 유형의 코딩테스트 문제도 풀어보는 게 좋을 듯하다.

요약하자면,

• 구현, 문자열 : 프로그래머스 3단계 수준
• 나머지 : 프로그래머스 2~2.5단계 수준

정도를 목표로 준비하면 될 것 같다.

2차 소프트웨어 지식 테스트

실제로 준비했던 것

이번 소프트웨어 지식 테스트에서는 네트워크, 데이터베이스, 운영체제, 프로그래밍, 아키텍처가 출제된다고 예고되었으며, 그것을 위주로 공부했다. 자료구조나 알고리즘은 나오지 않아서, 과감히 포기했다.

공통

이 블로그 포스트를 참조해서, 어떻게 공부하면 될지 알아보았다. 책을 사는 건 금전적 문제가 있어서, 인터넷으로 공부할 수 있는 gyoogle 블로그와 WeareSoft tech-interview를 보면서 공부했다. 특히 gyoogle 블로그가 많은 도움이 되었다. 이 블로그를 기반으로 공부하면서, 최소한 내가 여기서 다루는 것들을 이해하고 설명할 수 있으며, 설명된 내용을 보고 어떠한 용어인지 말할 수 있는 정도를 목표로 공부했다. 맨 처음에는 gyoogle 블로그를 훑으며 대략적인 흐름을 살펴보았고, 이후 세부적으로 공부할 때 각 내용을 외우면서 설명할 수 있을 정도로 공부했다.

인터넷에 돌아다니는 정처기 필기 문제도 한 번 풀어봤는데, 84점 나오더라. 와우...

컴퓨터 구조

앞서 말한 gyoogle 블로그나 혼공에서 준비한 이 포스트를 기반으로 기초적인 흐름을 잡았다.

지엽적인 것들이 나올 수 있으므로, 이 블로그의 연습문제를 훑어보면서 세부적으로 공부해야 하는 개념들을 익혔다. 지금 되살펴 보면, 이 블로그 연습문제를 봤었기에 내가 한 문제라도 맞힌 게 아닐까 싶다.

운영체제

3기 후기에서 추천한 혼공컴운 책으로 공부했다. 이 책이 비전공자가 이해할 수 있게 쉽게 서술되어 있어서, 공부하기에 아주 좋았다. 나는 이 책을 읽으면서 이전 파트에서 나왔던 것들을 떠올리면서 적용하려고 했던 것 같다. 시간 관계상 나는 운영체제만 다루는 8장 이후부터 읽었었는데, 여러분들은 2장부터 읽기를 바란다.

네트워크

단골로 나오는 OSI 7계층, TCP 3-way handshake, 4-way handshake는 네이버 부스트캠프에서 썼었던 학습정리로 복습하고, 처음 본 개념이었던 TCP의 흐름제어, 혼잡제어나 TLS/SSH handshake 위주로 공부했었다. 네트워크에서 지엽적인 것들이 나올 것 같아서, 네트워크 계층의 프로토콜(IP, ARP, NAT)이나 라우팅 프로토콜(RIP, OSPF, BSP)도 막판에 공부했었는데 거기서는 안 나오더라.

데이터베이스

gyoggle 블로그와 WeareSoft tech-interview를 활용했다. 추가로, 데이터베이스로 SQL 명령어 시험 문제가 나올 수도 있을 것 같아서, 프로그래머스의 SQL 코딩테스트를 몇 개 풀어보면서 SQL 질의어의 기초를 배웠다. 근데 SQL 질의어가 나오지는 않았다더라.

프로그래밍

워낙에 자신 있는 분야라서, 프로그래밍 하면 단골로 나오는 C언어의 증감 연산자와 포인터만 따로 복습했다. 근데 진짜 듣도 보도 못한 게 나오더라.

회고하면서, 어떻게 준비해야 좋았는가

내가 추천하는 공부법은 다음과 같다.

• gyoogle 블로그로 기초 익히기
• 혼공컴운으로 컴퓨터 구조, 운영체제 공부하기
• 이 블로그의 연습문제를 풀면서 컴퓨터 구조를 세부적으로 공부하기
• 적어도 WeareSoft tech-interview에 나오는 질문은 답할 수 있게 준비하기
• 운영체제 관련해서는 계산 문제가 나올 수 있다. 개념을 이해하고 적용해보기
• 각 프로그래밍 언어의 특징적인 주요 문법(객체지향 위주로) 개념 간단하게나마 훝어보기

전공자라면 그렇게 어렵지는 않은 수준으로 출제된 것 같으나, 비전공자의 경우는 쉽지 않았을 겁니다. 단, 잘 외우지 않는 지엽적인 부분이 특정 파트에서 대충 3문제 정도 나왔던 걸로 기억합니다.

문제 유형

객관식, 단답형, 서술형이 나옵니다. 하나의 보기를 주고 여러 개의 문제를 주거나, 이전 문제를 기반으로 꼬리 문제가 출제되는 유형이 굉장히 많이 나왔습니다. 개념 하나를 모르면 줄줄이 틀릴 수밖에 없습니다.

출제 범위

네트워크, 데이터베이스, 프로그래밍 언어, 운영체제, 컴퓨터 구조, 이진법에서 출제되었습니다. 전반적으로 https://gyoogle.dev/blog/ 이분 블로그에서 다루는 부분이 많이 출제되었던 것 같습니다. 단, 프로그래밍 언어 부분과 컴퓨터 구조 부분은 여기서 안 나왔어요. 컴퓨터 구조 부분은 전공책 참조하셔야 합니다.

아키텍처라고 하길래 소프트웨어 공학(설계나 테스트)과 관련된 건가 하고 그것도 공부했었는데, 그건 안 나오더라고요.

후기

아는 것도 몇 개 있었으나, 헷갈리거나 애매한 문제들이 많아서 불안합니다. 대충 28문제에서 17문제 정도는 확실하게 맞는 것 같은데, 부분문제 포함 11문제나 되는 것에서 맞는지 틀린지 모르는 게 있어서 불안하긴 합니다. 그래도 부트캠프인 만큼 컷은 그렇게 높지는 않겠죠...

코딩테스트 후기

오늘 오후 2시경, 현대자동차그룹에서 운영하는 소프티어 부트캠프 1차 합격 메일이 도착했다. 합격이다! 소프티어 부트캠프는 특이하게도 자소서 등을 보지 않고, 순수한 코딩과 소프트웨어 지식만으로 선발한다.

1차 시험은 코딩테스트였는데, 2시간 내에 5문제를 푸는 것이었다. 인터넷 사용은 허용되나, 직접적인 문제를 검색하거나, 생성형 AI를 사용하는 것은 금지되어 있다. 플랫폼은 구름 플랫폼을 사용했는데, 프로그래머스처럼 함수 기반 코테가 아닌, 백준처럼 표준입출력을 이용한 방식이어서 적응하기 애먹었던 기억이 있었다.

2기와 3기 후기에서 코딩테스트 난이도가 괴랄하다고 들었는데, 4기에는 그렇게 괴랄하지는 않았던 것 같다. 대충 난이도는 프로그래머스 2~2.5단계 수준이었다. 나는 4.2솔 정도 했고(나머지 0.2솔은 테케 포함한 기본 상황은 구현했으나 더 넓은 상황을 구현하지 못한 채로 코테가 종료되었음), 그 결과 1차 합격을 할 수 있었다.

2차 준비?

2차는 소프트웨어 지식 테스트로, CS지식에 대한 문제가 출제된다. 문제 유형은 객관식, 단답형, 서술형이며, 분야는 운영체제, 네트워크, 데이터베이스, 프로그래밍 언어, 소프트웨어 아키텍처로 구성된다고 한다. 1차와는 다르게 인터넷 검색 행위는 금지되며, 대신 A4용지 필기는 사용할 수 있다.

CS지식은 네이버 부스트캠프에서도 배운 게 있으나, 2년 전의 일이므로 거의 까먹었으므로 남은 1주일 동안 어떻게든 빠르게 학습해야 한다. 특이하게도 소프트웨어 아키텍처가 분야로 나오는데, 학부 시절에 수강했던 소프트웨어공학입문 수업에서 배운 것과 비슷한 분야가 나오지 않을까 싶다.

2기~3기 후기에 따르면 굉장히 지엽적인 것까지 튀어나오기에, 난이도가 매우 괴랄하다고 한다. 대체 어디까지 지엽적인 게 나오는 거지?

발단: 커리어 잘못 쌓았네...

작성된 프로젝트 경험들이 대부분 일반적인 웹 서비스를 만들고 유지 보수하는 것과 직접적인 연관이 없습니다. 어떻게 보면 '전형적'이라고 할 수 있는 형태의 웹 서비스를 만들고 운영하는 경험도 해보시는 것을 추천해 드립니다. 어느 기업에 지원하셨는지 모르겠으나, 대부분의 기업이 만드는 서비스와는 다소 다른 경험을 쌓으신 것 같습니다. 이력서를 읽는 사람 입장에서는 가장 기본적인 역량에 대한 검증이 어려운 상황이라고 생각합니다. -왓에버 서류검토 중

내 첫 취업 도전기는 혹독했다. 3~4월 동안 대략 17개 정도의 기업에 지원했는데, 서류는 단 하나만 붙었고, 나머지는 전부 서류 광탈이었다. 이력서에 무슨 문제가 있나 싶어서, 이력서 피드백 사이트를 찾아보던 중, 9000원으로 이력서 피드백을 해 준다는 왓에버 서류검토 서비스를 찾아서 이용해 보았다. (+슥삭에서 운영하는 슈퍼패스의 무료 이력서 피드백도 이용해 보았으나, 무려 1달이 넘게도 이력서 피드백을 못 받고 있다. 사실상 껍데기만 남고 서비스를 종료한 것으로 추정되므로, 웬만해서는 9000원 내고 왓에버 서류검토를 이용하는 걸 추천한다.)

결과는 처참했다. 스스로 기술적인 도전들을 어필하여 기술적인 역량이 드러나는 이력서라고 자부하고 있었는데, 서류검토관은 다르게 보고 있었나 싶었다. 제일 충격적이었던 건 그간 쌓아왔던 경험들이 일반적인 프론트엔드 개발과는 거리가 멀었다는 것이었다.(이건 면접까지 갔었던 단 하나의 기업에서도 지적받은 내용이었다.) 내 내다버린 2년이!

그래서 일반적인 프론트엔드 프로젝트 경험을 쌓을 수 있는 사이드프로젝트를 알아보던 중, 우연히 비사이드 포텐데이를 알게 되어서 참여하게 되었다.

포텐데이, 그 10일 간의 기록

Day -4

오후 5시에 포텐데이 참여자는 슬랙과 노션에 초대받았다. 이번 405 포텐데이에서는 기획자 16명, 디자이너 40명, FE 28명, BE 24명이 모였다. 포텐데이 참여자는 프로젝트 시작 시점 2일 전까지 직접 팀을 빌딩할 수 있고, 직접 팀을 빌딩하지 못한 참여자는 비사이드 운영 측에서 인공지능을 활용해 팀을 배정받는다.

생판 모르는 사람들이 팀을 꾸리는 것인 만큼, 이 시점에서는 팀을 꾸리기 위해서 자기 자신의 역량을 어필하는 게 중요했다. 어필하는 방법은 크게 2가지였다.

• 비사이드 커리어 카드를 정성껏 작성하기
• 슬랙에 자신을 어필하는 글 올리기

나는 비사이드 커리어 카드를 작성하여 이전 사이드프로젝트 경험과 역량을 어필하였고, 감사하게도 이를 좋게 봐 준 한 팀에서 컨택을 받아 합류하게 되었다. 이후 프론트엔드 한 분과 디자이너 한 분이 더 합류하여 기획 1명, 디자이너 2명, FE 2명, BE 1명으로 확정하였다.

해커톤류 프로젝트는 포텐데이 말고도 다른 연합동아리에서 해 본 적이 있으나, 그 때는 끝끝내 아무 팀도 구하지 못하고 끝났던 불쾌한 경험이 있었다. 개인적으로 비사이드 포텐데이가 팀 구성에 있어서 그 시절보다 좋았던 경험은 다음과 같았다.

• 생판 모르는 사람들이 온라인으로 진행되는 만큼, 친목 등의 요소를 배제하고 순수한 역량만으로 팀을 꾸릴 수 있다.
• 팀을 못 꾸리는 사람을 위해 2가지의 안전장치가 더 마련되어 있다. 팀을 못 구한 사람은 운영 측에서 랜덤으로 잘 맞는 사람들을 배정하며, 구성원의 불균형 등으로 팀을 못 꾸린 경우는 다크호스 시스템을 운영하여 추가 영입을 노려볼 수 있다.

Day -3~-2

미리 팀을 꾸린 팀은 이때부터 아이디어 선정을 시작하며, 나머지는 팀을 찾는 시간이다. 우리 팀의 경우 6명이서 각자 아이디어 브레인스토밍을 진행하여, 최종적으로는 자서전 작성을 돕는 서비스로 구성하기로 결정했다.

Day -1

이 시점은 직접 팀 빌딩이 끝나고, 비사이드 측에서 팀을 빌딩해주는 날이다. 오후 3시부터는 다크호스 영입을 시작한다. 디자이너가 타 부서보다 많기 때문에, 팀을 찾지 못하고 하차를 결정한 디자이너분들이 많이 있었다.

디자이너 한 분이 개인적 사정으로 인해 팀을 나갔고, 그 자리에 해당 디자이너분이 컨택했던, 협업 경험이 있는 다른 디자이너를 다크호스로 영입하였다.

따로 회의는 없었고, 기획 파트에서 아이디어를 구체화하는 시간을 가졌다.

Day 1

기획자분이 정리한 기획서를 기반으로, 기획안을 피드백하고 실제로 구현할 것들을 결정하는 시간을 가졌다. 백엔드 개발자분이 질문 위주로 초기 구현을 가자고 강력하게 주장하셨다.

FE 측에서는 개발 관련 컨벤션을 결정하고, 초기 개발환경을 세팅하였다. 빠르게 진행해야 한다는 특성을 살려, 개발 세팅이 간편한 vite를 번들러로 채택하였고, 또한 단기 개발의 특성으로 인해 FE 전원이 익숙한 자바스크립트를 이용하였다. 만약 장기 프로젝트라면 TS를 채택했을 것이다.

Day 2~3

다음 회의가 Day 4에 이루어지며, 개발 측에서는 할 수 있는 것이 없으므로 구현 자체가 확정된 로그인 기능의 와이어프레임을 구현하였다.

그 외에도 FE 측에서 라이브러리 사용에 대해 회의를 나누었고, 기술 스택을 결정하였다.

Day 4

기획자분께서 정리하신 IA(정보구조도, 웹∙앱 구축 시 필요한 화면과 메뉴의 정보 구조를 설계 및 정의하는 문서)와 디자이너분의 레퍼런스를 기반으로, 서로 피드백을 나누고 실제 구현 우선순위를 결정하였다. 위의 사진에서 파란색으로 되어 있는 부분이 최우선 구현 내용이다.

이 때, 자서전(폴더) 다수 생성 기능은 최소 기능에 필요하지 않다고 판단되어, 단 하나의 예시 폴더만 보여지도록 구성되었다.

이후 개발 측에서는 결정된 최소 기능 구현체를 바탕으로, 역할을 분담하였다. 나는 서비스 진입 초기 부분인 온보딩, 로그인/회원가입, 홈, 자서전 목록을 담당했다.

Day 5~6

와이어프레임이 Day 6에 구현되므로, 레퍼런스 기반으로 빠르게 핵심 기능 구현을 마무리하고, 디자인을 적용하기로 했다. 온보딩 페이지와 메인화면 자서전 목록 페이지에는 swiper.js 라이브러리가 적용되었는데, 직접 스와이핑 기능을 구현하면 그것이 기술적인 도전이겠지만 시간 관계상 스와이퍼 기능 구현에 시간을 다 쓸 것 같으므로, 라이브러리를 이용하기로 했다. swiper.js는 이전에 stardew dressup에서도 사용한 적이 있었으나, 지금 swiper.js는 web component 기반의 11.1버전으로 업데이트된 상태라서 api가 달라졌다.

Day 7

결정된 와이어프레임과 API 명세서에 따라 구현체를 수정하는 시간을 가졌다. 결정된 와이어프레임과 API에 따라 변경된 구현체는 다음과 같다.

• 5초에 1번씩 다른 사람의 질문을 표시하는 방식으로 변경
  • 이때, 애니메이션 도중에 이전 질문과 현재 질문이 같이 보여지는 부분이 존재해야 한다.
• 사용자 로그인 확인을 매번 /api/auth/check를 호출하는 방식이 아닌, api/login에서 응답받은 key를 localStorage에 저장하고, 해당 key를 바탕으로 요청을 보낼 때 header의 Authorization 헤더에 Token (토큰)으로 넘기도록 변경
• 왜인지 모르겠으나 비밀번호 확인을 백엔드로 넘기도록 변경

추가로 내 파트가 생각보다 일찍 끝났기에 질문 답변 글쓰기에서 질문 목록을 받아오는 것도 구현하였다.

Day 8

이날은 내가 소프티어 부트캠프 코딩테스트를 보는 날이라서, 비사이드 포텐데이에 많이 참여하지는 못했다.

Day 8 회의에서 현재 구현된 것들을 살펴보고, 추가 구현 가능한 기능들을 추려서 구현체를 결정하였다. 이 때 구현체를 결정하는 기준은 다음과 같다.

• 단기간에 디자인의 수정 없이 구현이 가능한가?
• 핵심 컨셉을 보여주는 데 충분한가?

이를 바탕으로 로그아웃 기능과 AI 타래 생성 기능을 구현하기로 하였다. 다른 프론트엔드 파트가 아직 구현이 끝나지 않은 관계로, 내가 추가 기능을 구현하기로 했다.

Day 9

마감일이 얼마 남지 않은 만큼, 우선순위를 정하여 개발을 진행하였다. 내가 Day 9에서 맡은 파트는 추가 기능 구현, 맡은 파트의 그래픽 적용, 그리고 QA에서 나온 버그 수정이었다. 이 때, 추가 기능의 와이어프레임은 오후 12시 이후에, QA 내용은 오후 9시에 받을 수 있으므로, 다음과 같이 우선순위를 정했다.

1. 로그아웃 버튼 구현
2. 이미 확정된 그래픽을 컴포넌트에 적용
3. AI 타래 생성 기능 구현
4. 버그 수정

오후 9시 이후부터는 배포된 프론트엔드 페이지를 기반으로, 각자 테스트를 돌려 QA를 진행하였다. 그 중 특정 플랫폼에서만 레이아웃이 틀어지거나 의도대로 작동되지 않는 문제도 있어서 까다로웠다. 기억에 남는 것은

• iOS에서 뒤로가기 버튼이 컴포넌트 중앙이 아닌 상단에 위치하는 버그
• iOS에서 글 작성 란을 터치하면 확대되는 버그

정도가 있었다.

Day 10

1차 버그 수정한 것을 서버에 반영한 뒤, 2차 QA를 진행했다. 간헐적으로 로그아웃 후 로그인이 진행되지 않는 버그나, 타래 수정 버튼 비활성화 요청 등이 있었으며, 이를 해결하였다.

최종적으로 오후 2시 12분에 최종 PR 머지를 진행하여, 마감시간 전에 완전한 서비스를 제출할 수 있었다.

서비스 소개

'혼자서 간직하고 싶은 이야기'가 있으신가요? '누군가에게 들려주고 싶은 이야기'가 있으신가요? '아직 듣지 못한 부모님의 이야기'가 궁금하신가요? 지금부터 인생을 돌아보며 AI와 함께 자서전을 작성하는 '人타래, 쉽게 엮는 나의 이야기'를 만나보실 수 있습니다! 150개 이상의 재미있는 땀부터 진지한 땀까지 준비되어 있으니 기대해주세요 👏 🤔 타래? 땀? 그게 뭔가요? 🤔 인타래에서는 거창해보이는 자서전 대신 '타래', 형식적일것만 같은 질문 대신 '땀'을 준비했습니다. 더 쉽고, 친근하게 다가가기 위한 노력을 지켜봐주세요! 💁 인타래 주요 기능 💁

• 오늘의 한땀: 매일 다양한 땀을 보내드려요! 어떤 내용으로 타래를 채워나가야 할 지 고민하지 않아도 매일 조금씩 땀을 쓰며 타래를 만들어나갈 수 있습니다.
• AI 자동 타래 작성: 땀이 충분히 쌓이면 AI가 목차 수립부터 내용 작성까지 도와드립니다. 글을 잘 못써도, 악필이어도 괜찮아요!

  인타래 서비스 바로가기

人타래, 쉽게 엮는 나의 이야기는 자서전을 쓰기 어려워하는 사람을 위한 인생 기록 작성, AI 자서전 작성 도우미 서비스이다. 사용자가 날마다 보여지는 질문에 대해 답변을 하여 "땀"을 쓰면, AI가 지금까지 작성한 "땀"들을 모아 "타래"라는 이름의 자서전으로 재구성해주는 서비스이다.

서비스의 목적

• 모바일로 쉽고 꾸준하게 인생 질문들에 답을 하고 기록하며 자서전 소재를 쌓을 수 있도록 한다.
• 다른 사용자들의 다양한 답변과 자서전을 구경할 수 있도록 한다.
• 글을 잘 쓰지 못해도 생성형 AI를 통해서 질문 답변 기반으로 자서전을 자동으로 생성할 수 있다.

주요 기능

• 매일 조금씩 질문에 대한 답을 하며 자서전(타래) 소재를 쌓을 수 있는 오늘의 랜덤 질문(땀) 기능
• 자유롭게 정해진 질문들을 선택해 자서전 소재를 쌓을 수 있는 다양한 땀 질문 쓰러가기 기능
• 질문(땀)들을 엮어 자서전으로 엮는 AI 타래 작성 기능
• 다른 사람들의 예시 질문을 메인화면에서 볼 수 있는 기능

결과 - 포텐데이 1pick 2위

405 비사이드 포텐데이에서 우리 팀의 서비스가 2등을 거머쥐는 성과를 이룰 수 있었다! 아쉽게도 1등은 되지 못했지만, 상위권의 성과를 낼 수 있어서 뿌듯했다.

후기

좋았던 점

• 이전 협업보다 FE끼리 원활하게 소통할 수 있었다. 이전 협업에서는 개발환경, 모킹, 데이터 페칭을 다루는 방식 등 엄밀하게 기술 스택을 결정하지 못하여, 서로 다른 개발 경험을 가진 FE 개발자 측에서 갈등이 있었다. 이번 협업에서는 이전 협업에서의 아쉬웠던 점을 바탕으로, 모킹, 데이터 페칭 등을 명백하게 정의하고, MSW에 대해 잘 모르던 다른 개발자에게 가이드라인을 제시해 좀 더 원활한 개발을 할 수 있었다.

• 애자일 개발 방식을 체험할 수 있었다. 기획자나 디자이너가 먼저 기획을 작성하면 개발자가 그것을 따라가는 방식이 아닌, 한정된 시간 내에 주요 핵심 기능을 결정하고, 디자이너와 개발자가 병렬적으로 진행되는 방식으로 개발을 진행하였다. 와이어프레임, 디자인, API명세가 동시에 주어지기 때문에 프론트엔드 측에서는 기능구현 - 디자인 반영 - 백엔드 반영 - 그래픽 반영 - 추가 기능 구현 순으로 할 일이 많아진다는 단점은 있었으나, 빠르게 기능에 대한 피드백을 받을 수 있다는 이점이 있었다.

아쉬웠던 점

• 여전히 두드러진 기술적인 성장을 하지 못했다는 건 아쉬움이 남는다. 공유 기능이나 사진 입력 기능 등 프로젝트 내에서 시도해볼만 한 기술적인 내용은 있었으나, 한정된 시간 내에 프로토타입을 구현해야 하는 만큼 기본적인 CRUD 위주로 구현된 것은 아쉬웠다.

• 프론트엔드와 백엔드와의 소통이 덜 이루어졌고, 탑다운 방식으로 전파된 것이 아쉬웠다. 프론트엔드는 신입 2명이고, 백엔드는 9년차 베테랑이라서 다가가기 어려운 점도 있었으며, FE와 BE끼리 API 명세서나 ERD 등을 협의하고 어떠한 데이터를 보여줄지 확정지어야 하는데, 그 부분에 대한 소통이 없는 게 아쉬었다. 실제로 이 점 때문에 API 명세서 합의가 늦어져, FE가 임의적으로 구현한 mock api와 실제 BE가 구현한 API와의 규격이 맞지 않아서 FE 측에서 일을 두 번 해야 했던 비효율성이 있었다.

지금까지, 대량의 스크롤이 필요한 리스트를 최적화한 경험이 2번 있었다. 한 번은 prismic에서 미리보기 이미지 리스트를 최적화한 것이었고, 다른 한 번은 xnb.js에서 대량의 텍스트 미리보기 컴포넌트를 최적화한 것이었다. 두 프로젝트의 골자는 보이는 것만 렌더링하는 것이었으나, 그 구현체는 사뭇 달랐다.

왜 보이는 요소만 렌더링해야 하나요?

렌더링 성능 최적화에 있다. 브라우저에서 대량의 dom 요소가 렌더링될 때, 각 요소들의 위치를 결정하는 레이아웃 과정을 거친다. 레이아웃 과정은 렌더링되는 엘리먼트가 많을수록, 렌더링할 엘리먼트의 depth가 클수록 소요 시간이 증가한다. 따라서 어떠한 컴포넌트의 렌더링 시간이 길어진다면 엘리먼트가 많아서 그럴 가능성을 의심해야 하며, 렌더링할 엘리먼트의 수를 줄이면 레이아웃 속도를 향상시킬 수 있다. 이 중, 보이지 않는 엘리먼트는 굳이 렌더 트리에 없어도 되지 않는가? 라는 아이디어에서 출발한 것이 보이는 요소 렌더링 기법인 것이다.

Prismic에서 사용한 기법 - 가상 리스트(windowing) 기법

Prismic에서는 windowing 기법을 사용하여 보이는 요소만 렌더링했다. windowing 기법이란 컴포넌트의 스크롤 위치에 따라, 보이는 요소의 범위를 계산하여, 실제 보이는 요소만 dom 트리에 추가하고, 나머지 요소는 렌더링 자체를 하지 않아버리는 기법을 의미한다.

리액트에서 windowing 기법을 구현하는 라이브러리로는 react-window, react-virtualized가 있으나, Prismic의 미리보기 컴포넌트는 이중 폴더 구조 형태의 리스트로 구성되어 있기에, 좀더 높은 자유도를 위해 직접 구현하였다.

windowing 기법의 구현 원리

가상 리스트 기법은 다음의 원리로 구현된다.

1. 사용자가 scroll 이벤트를 발생시킨다. 컨테이너 컴포넌트의 scrollHeight 요소를 기반으로 렌더링할 요소를 결정한다. (react에서는 여기서 state를 변경하는 방식으로 리렌더링을 유발한다.)
2. 수학을 이용하여 렌더링할 요소의 인덱스 범위를 계산한다.
3. 각 인덱스 범위에 해당하는 요소의 내용을 렌더링한다. 요소의 위치는 position:absolute를 활용한 절대 좌표로 결정된다.

가상 리스트의 인덱스 공식

2번은 현재 스크롤에서 어느 부분이 보여야 할지를 계산하는 방법으로, 가상 리스트를 이해하는 데 가장 중요하니, 부연설명을 해보겠다.

우선, 위의 사진은 리스트의 기본 구조이다. 위에서부터 0번, 1번 순으로 이어지며, 0번과 리스트 컨테이너 사이의 간격을 startPadding, 각 리스트 높이를 elemHeight, 리스트 사이의 간격을 elemGap이라고 하겠다. 여기서 0번 엘리먼트의 시작 y값은 startPadding이며, 종료 y값은 startPadding+elemHeight이다. 1번 엘리먼트의 시작 y값은 startPadding+elemHeight+elemGap이고, 종료 y값은 startPadding+elemHeight+elemHap+elemHeight이다. 이 규칙을 적용하면, i번 엘리먼트의 시작 y값과 종료 y값을 구할 수 있다.

• 시작 y값 : startPadding + (elemHeight+elemGap)*i
• 종료 y값 : startPadding + (elemHeight+elemGap)*i + elemHeight

이제, 저 리스트에 가상의 가로선을 그어보자. 이 가로선이 보이는 엘리먼트의 기준이 되는 선이다. 가로선이 엘리먼트의 시작점에 있을 때, 엘리먼트 중간에 있을 때, 엘리먼트 종료점에 있을 때,엘리먼트와 엘리먼트 사이 공간에 있을 때로 나눠서 생각해보자.

먼저, 가로선 아래에 있는 엘리먼트가 보인다고 가정해보자. 이 가로선은 스크롤의 시작 가로선이다. 사진의 각 경우를 살펴보자.

• 시작점에 있을 때 : 2번부터 보임
• 중간에 있을 때 : 2번부터 보임
• 끝점에 있을 때 : 3번부터 보임
• 사이공간에 있을 때 : 3번부터 보임

스크롤 시작 가로선의 경우, 끝점을 기준으로 보이는 엘리먼트의 인덱스가 나뉘어진다.

다음으로, 가로선 위에 있는 엘리먼트가 보인다고 가정해보자. 이 가로선은 스크롤의 종료 가로선이다. 사진의 각 경우를 살펴보자.

• 시작점에 있을 때 : 1번부터 보임
• 중간에 있을 때 : 2번부터 보임
• 끝점에 있을 때 : 2번부터 보임
• 사이공간에 있을 때 : 2번부터 보임

스크롤 종료 가로선의 경우, 시작점을 기준으로 보이는 엘리먼트의 인덱스가 나뉘어진다.

이를 기반으로, 스크롤 시작 지점과 종료 지점에 보이는 엘리먼트의 인덱스 범위를 시각화해 보았다. 왼쪽 숫자가 스크롤 시작 지점 인덱스 범위, 오른쪽 숫자가 스크롤 종료 지점 인덱스 범위다.

잘 보면, (0번을 제외하고) 각 인덱스 범위의 길이는 elemHeight + elemGap으로 동일하고, 몫 연산을 이용하면 스크롤 시작 지점/종료 지점의 y값을 기준으로 보이기 시작하는/보이기 끝나는 엘리먼트의 인덱스 번호를 알 수 있다.

• 시작점 인덱스 : Math.floor( (scrollStartY - (startGap - elemGap)) / (elemHeight + elemGap) )
• 종료점 인덱스 : Math.floor( (scrollEndY - startGap) / (elemHeight + elemGap) )

windowing 기법의 장단점

장점

• 페이지 내에서 엘리먼트의 수를 줄일 수 있다.
  • 특히, 가상 DOM으로 컴포넌트의 변경 사항을 순회하며 계산하는 리액트와 같은 웹 프레임워크를 사용하는 데에 효과적이다.
  • 엘리먼트의 수가 대량으로 줄어드므로, 리플로우 계산에 사용되는 연산 횟수 역시 줄어든다. 엘리먼트 수가 많고 리플로우가 잦은 웹 페이지에 효과적이다.
• 데이터 기반 렌더링에 효과적이다. 리스트의 실제 내용은 데이터의 인덱스를 기반으로 렌더링이 이루어지므로, 인덱싱이 된 데이터를 렌더링할 수 있다.

  단점

• 구현/이해에 수학적 지식을 요구한다. 좌표 계산을 잘 하지 못하는 사람들은 구현이 힘들 수 있다.
• 엘리먼트의 추가 및 제거가 빈번하게 일어나므로 이 부분에서 오버헤드가 일어날 수 있다.
• 구현에 사용되는 scroll 이벤트의 호출 빈도가 잦다. 원활한 성능을 위해서는 throttle을 사용하여 렌더링 호출 빈도를 줄일 필요가 있다.

왜 Prismic에서는 windowing 기법을 사용했는가?

Prismic 프로젝트는 대량의 이미지를 분류하기 위해 만들어졌다. 이렇기 때문에, 최소 50개 이상, 최대 3000개의 이미지가 미리보기 컴포넌트에 보여지게 된다. 또한, 유틸리티 웹 어플리케이션이라는 앱의 특성상 싱글 페이지 어플리케이션 구현에 용이한 React를 사용하였다.

이러한 Prismic의 특성으로 인해, 미리보기 리스트의 성능을 향상시키기 위해 windowing 기법을 사용하는 것이 효과적이라고 생각했다. 그 이유는 다음과 같다.

• 엘리먼트의 수가 최대 3000개 이상으로 많다. 즉, 렌더링을 할 때 잦은 스크롤로 발생하는 오버헤드보다 대량의 엘리먼트로 인해 발생하는 연산 오버헤드가 크다고 판단했다. windowing 기법은 dom에서 엘리먼트를 제거하므로, 엘리먼트의 수를 효과적으로 줄일 수 있다.
• React를 사용한다. React는 가상 DOM을 사용해서 엘리먼트의 변경 사항을 비교하는데, 엘리먼트의 수가 많으면 가상 DOM 비교에 들어가는 연산이 커질 수밖에 없다. 따라서 엘리먼트의 수를 줄이는 windowing 기법을 사용했다.

xnb.js에서 사용한 기법 - 보이지 않는 요소 hidden처리

xnb.js에서는 보이지 않는 요소의 css display 속성을 hidden 처리하는 기법을 사용하여 보이는 요소만 렌더링했다. intersection observer api를 이용해, 엘리먼트 영역이 보이면 display 속성을 block으로 처리하고, 보이지 않으면 display 속성을 hidden 처리하여서 렌더 트리에서 해당 엘리먼트를 제거하는 방식으로 구현했다.

보이지 않는 요소 hidden처리 기법의 구현 원리

이 기법은 다음의 원리로 구현된다.

1. 모든 요소를 html에 추가한다. 요소는 intersection observer가 감지할 외부 엘리먼트, 실제 내용이 들어갈 내부 엘리먼트로 구성된다.
2. intersection observer가 각 요소의 외부 엘리먼트를 감지하도록 한다.
3. intersection observer가 요소의 보임을 감지하면, 요소의 내부 엘리먼트의 display 속성을 block으로 전환한다. 그렇지 않으면, display 속성을 hidden으로 전환한다.

보이지 않는 요소 hidden처리 기법의 장단점

장점

• 구현이 상대적으로 간단하다. 요소의 배치와 보이는 요소 감지를 전적으로 브라우저에게 맡기기 때문에, 구현이 쉽다.
• 구현에 사용되는 intersection observer 콜백 호출 빈도가 적다. scroll 이벤트와는 달리 intersection observer의 콜백 함수는 요소가 보일 때, 숨겨질 때 1번 발생한다. 이 점에서 오버헤드를 줄일 수 있다.

  단점

• 엘리먼트의 수가 줄어들지 않는다. 이로 인해, 엘리먼트 자체의 연산으로 발생하는 성능 저하를 줄일 수 없다. 리스트 내에 대량의 요소가 존재한다면 이 기법보다는 windowing 기법을 사용하는 것이 효과적이다.
  • 중간에 요소가 추가될 때 많은 양의 엘리먼트의 리플로우가 그대로 일어나므로, 해당 부분에서 불리할 수 있다.
• 내부 엘리먼트의 대략적인 크기를 외부 엘리먼트가 알고 있어야 한다.

왜 xnb.js에서는 보이지 않는 요소 hidden처리 기법을 사용했는가?

xnb.js의 미리보기 컴포넌트는 최대 1만 줄의 텍스트를 렌더링해야 하지만, 청크 단위로 구분되면 최대 100개의 청크만 렌더링하게 된다. 이 점으로 미루어 보아, 보이지 않는 요소 hidden 처리 대신 가상 리스트로 얻을 수 있는 이점이 크게 있지 않을 것이라고 생각했다.

또한, xnb.js 1.3 업데이트는 빠르게 대중에게 퍼블리싱해야 할 필요가 있었다. 이미 2만 여 명의 대중에게 배포된 서비스를 업데이트하는 것이기 떄문에, 업데이트 속도가 늦으면 대중이 불편해할 것이기 때문이라고 판단했다. 그렇기 때문에 빠르게 이해하고 적용할 수 있는 보이지 않는 요소 hidden처리 기법을 사용했다.

두 방법의 차이점

windowing 기법과 보이지 않는 요소 hidden 처리는 보이는 부분만 렌더 트리에 존재한다는 공통점이 있으나, 세부적으로 다음의 차이를 보인다.

const inputForm = document.getElementById("input");
const inputButton = document.getElementById("button");
inputButton.addEventListener( "click", ()=>{
  const newElement = document.createElement("div");
  newElement.className="myComponent";
  newElement.innerHTML = `
    <p>Name : ${inputForm.value}</p>
    <div class="delButton">삭제하기</div>
  `
  document.body.appendChild(newElement);
})

신입 개발자 A는 버튼을 누르면 input 값의 내용을 가져와 새로운 컴포넌트를 추가하는 코드를 만들고 있었다. 그리고 위와 같은 코드로 작성하였다. 여기서 문제, 이 코드의 문제점은 무엇인가? . . . . 바로 크로스 사이트 스크립팅(Cross Site Scripting, XSS) 공격에 취약하다는 것이다. 그렇다면, 크로스 사이트 스크립팅이란 무엇이고, 이 코드가 왜 XSS 공격에 취약한 것인가?

크로스 사이트 스크립팅이란?

크로스 사이트 스크립팅은 개발자가 아닌 외부인이 사이트에 스크립트를 주입할 수 있는 보안상의 이슈로, 주로 검증되지 않은 사용자 문자열을 충분한 유효성 검사나 필터링 없이 그대로 이용할 때 발생한다.

사용자의 브라우저는 악의적인 스크립트가 신뢰할 수 없는지를 감지할 수 없으므로 쿠키, 세션 토큰 또는 다른 중요한 사이트별 정보에 대한 접근 권한을 가져가거나 악의적인 스크립트로 HTML 내용을 다시 쓸 수 있다.

참고로, XSS와 비슷하게 검증되지 않은 사용자 문자열로 보안 이슈가 발생하는 SQL 인젝션이라는 것도 있다. 이것은 사용자 입력을 그대로 SQL 쿼리에 넣으면 생기는 문제.

innerHTML의 위험성

위의 코드를 보자. inputForm 안의 내용을 아무런 필터링 없이, innerHTML 내에 사용하고 있는데, innerHTML은 문자열을 html 코드로 전환하는 getter인 만큼, innerHTML에 사용자가 html 코드를 집어넣으면 그 코드가 html 코드로 그대로 전환된다!

사용자가 <p onclick="alert('Its over 9000!')">클릭하면 신기한일 일어남</p> 을 input form에 입력하고, 버튼을 클릭한다고 가정해보자. inputButton의 클릭 이벤트로 발동된 함수는 newElement.innerHTML을 다음과 같이 해석하게 된다.

<p>Name : <p onclick="alert('Its over 9000!')">클릭하면 신기한일 일어남</p></p>
<div class="delButton">삭제하기</div>

그리고 이게 그대로 html로 해석되면서, "클릭하면 신기한 일 일어남"이라는 문자열을 클릭하면 스크립트가 실행되는 코드가 탄생하게 되는 것이다. 예시는 alert를 이용했지만, alert가 아니라 오만 가지 함수와 코드를 실행할 수 있기에 보안에 취약하다는 잠재적인 문제가 될 수 있다.

스크립트 즉시 실행

그렇다면 당신은 이렇게 생각할 수도 있다. <script></script>를 주입시키면 스크립트가 즉시 실행되는 것이 아닌가? 물론, 이론상으로는 그럴 수 있겠지만 우리의 브라우저는 여러분들 생각보다 똑똑하기 때문에 중간에 인라인 스크립트가 생성되더라도 아무런 행동을 하지 않는다.

그렇다고, 스크립트를 즉시 실행하는 방법이 없는 것은 아니다. 바로 img 태그의 onerror 이벤트를 이용하는 것이다. error 이벤트는 이미지가 로드 실패될 때 호출되며, img 태그가 src에 있는 이미지를 바로 로드 시도하는 것을 이용하면, <img src="" onerror="alert(153)">라는 코드로 다음과 같은 일을 일으킬 수 있다.

• img 태그가 html에 주입되며, src 속성에 저장된 주소로 이미지 로드를 시도한다.
• src가 빈 문자열이기 때문에, 이미지 로드는 실패하고, error 이벤트가 생성된다.
• onerror에 설정된 스크립트가 실행되며, 결과적으로 사용자가 아무것도 하지 않아도 스크립트가 자동으로 실행되는 공격이 수행된다.

저장된 XSS 공격

위의 코드는 XSS 공격의 클라이언트 전용 사례를 제시했지만, 서버와 결합하면 더욱 치명적인 결과가 일어날 수 있다. 사용자가 신뢰하지 않는 html 코드를 그대로 서버에 제출하고, 서버가 해당 문자열을 db에 그대로 저장하는 상황을 생각해 보자.

그리고 웹 사이트가 db에 있는 문자열을 서버에 렌더링할 때, 문자열을 그대로 innerHTML을 이용해 렌더링한다면, 모든 사용자에게 오염된 html을 그대로 배포하게 된다! 이렇게 서버에 스크립트 주입 공격을 db에 저장하고, 신뢰하지 않은 문자열을 그대로 렌더링하는 것을 저장된 XSS 공격이라고 한다.

이 경우에는 프론트엔드 측과 백엔드 측 모두 신뢰하지 않는 문자열을 필터링해서 교차 검증을 하는 것이 중요하다.

대처 방법

필터링을 이용하는 방법이 있다. 사용자의 입력값에 포함된 <>과 같은 html 태그를 <, >로 변경시켜서 사용자의 html 주입 시도를 차단하는 방법이 있다.

innerHTML을 사용할 경우, 검증된 문자열만 템플릿 리터럴에 집어넣거나, 아예 집어넣지 않고, 부득이하게 사용자 텍스트를 컴포넌트 내에 넣을 경우 빈 문자열로 태그를 선언한 뒤, querySelector와 innerText(또는 textContent)를 조합하여 사용자 문자열을 입력하는 방법이 있다.

inputButton.addEventListener( "click", ()=>{
  const newElement = document.createElement("div");
  newElement.className="myComponent";
  newElement.innerHTML = `
    <p></p>
    <div class="delButton">삭제하기</div>
  `
  newElement.querySelector("p").innerText = inputForm.value;
  document.body.appendChild(newElement);
});

innerText로 들어온 문자열은 html 태그에 사용되는 특수 문자도 순수 문자로 판별하여, 사용자 입력을 그대로 출력한다는 특징이 있다.

참고로, innerText와 textContent의 차이는 setter에서는 별 차이가 없고, getter에서 css나 공백 제거 등으로 숨겨진 문자열을 보여주느냐(textContent), 보여주지 않느냐(innerText)의 차이다. textContent가 css 등을 고려하지 않아 리플로우가 일어나지 않아 대체적으로 성능이 좋은 편이다.

그럼, innerHTML은 죄악인가요?

innerHTML이 XSS 공격에 취약한 것은 맞지만, 완전히 사용되어서는 안 되는 것은 아니다. 신뢰할 수 있는 문자열만 innerHTML에 들어간다면, innerHTML은 개발자의 수고를 덜어줄 수 있는 좋은 무기가 된다. 예시를 통해 알아보자.

const newElem = document.createElement("div");
newElem.innerHTML = `
<h3>타이머</h3>
<div class="timerBody">
<span class="hour">59</span>:<span class="minute">59</span>:<span class="second">59</span>
</div>
<div class="timerButton>시작하기</div>
`

이 코드의 경우, innerHTML에 개발자가 검증된 문자열만 들어갔기 때문에, XSS 공격이 일어날 여지가 없다. 바닐라 자바스크립트로 innerHTML을 이용하지 않고 비슷한 코드를 짜려면 createElement를 도배해야 해서 코드의 가독성이 떨어지는 문제가 일어날 수 있다.

참고 자료

https://developer.mozilla.org/ko/docs/Glossary/Cross-site_scripting

https://developer.mozilla.org/ko/docs/Web/Security/Types_of_attacks#cross-site_scripting_xss

개요

웹 xnb 컨버터를 개발하던 중, 우연히 이런 오류를 발견했다.

대량의 텍스트 데이터가 미리보기 컴포넌트에 렌더링되었을 때, 창의 너비를 늘리거나 줄이면 앱이 프리징되는 현상

해당 문제는 웹 xnb 컨버터 1.2 이전에도 있었던 잠재적인 문제였지만, 그 때 다루던 xnb 파일에 저장된 텍스트들은 그렇게 용량이 크지 않았기에, 발견하는 데에 시간이 오래 걸렸다. 스타듀 밸리 1.6 업데이트로 인해 커스텀 자료형 xnb 파일의 데이터를 담은 json 문자열이 5000줄 이상으로 매우 길어지는 경우가 생겼다.

해당 문제는 앱의 사용성과 직결된 프리징 문제였기에, 바로 고치는 작업에 들어갔다.

원인 파악

웹 xnb 컨버터는 반응형 웹을 채택하고 있다. 즉, 웹 페이지의 너비가 일정 크기 이상이면 다른 종류의 레이아웃을 보여줘야 해서, 웹 페이지의 너비를 특정 너비 이하로 줄이거나 특정 너비 이상으로 늘리면 레이아웃 재계산이 발생하게 된다. 문제가 되는 경우는 대용량의 텍스트가 미리보기되는 것으로, 레이아웃 재계산이 발생할 때, 렌더링된 대용량의 텍스트도 같이 레이아웃을 재계산하게 된다.

잠깐 브라우저의 렌더링 과정에 대해 간략하게 알아보자. 브라우저의 렌더링은 html, css 파싱, 렌더 트리 형성, 레이아웃, 페인팅으로 나뉜다. 여기서 일어난 문제는 레이아웃 시간의 급격한 증가인데, 레이아웃을 계산해야 하는 요소의 수가 많을수록 레이아웃 시간이 증가하게 된다. 텍스트 노드의 경우, 띄어쓰기된 각 텍스트의 단어 혹은 (css 속성 중 white-space가 pre인 경우) 줄바꿈을 기준으로 각 부분의 위치를 계산하게 된다. (이 부분은 웹킷 소스코드를 찾아서 분석하려고 했는데 텍스트를 요소로 만드는 코드를 찾을 수 없었습니다... 제보 부탁드립니다)

간단한 실험을 해 봤는데, 매우 긴 문자열(50000자의 한글)을 넣은 뒤 해당 문자열이 속한 태그의 리플로우를 일으켜 보았다.

• 모든 문자가 띄어쓰기가 없을 경우:10ms
• 모든 문자가 띄어쓰기가 있을 경우:2.42s
• 모든 문자가 띄어쓰기가 있는 대신, white-space가 pre인 경우:37ms (대신 rasterize paint에서 500ms 이상 소요)

해결법 고안

레이아웃을 계산해야 하는 텍스트 수가 많다면, 많은 양의 텍스트를 렌더 트리에서 빼 버리면 되지 않을까?라고 생각했다. 렌더 트리에서 엘리먼트를 제거하는 대표적인 방법은 display: none;을 사용하는 것(html 속성의 hidden도 동일한 효과를 낸다.)이다.

첫 번째 고안한 방법은 화면의 크기 변경이 감지되면 일시적으로 미리보기 엘리먼트를 숨기고, 화면 크기 변경이 끝나면 미리보기 엘리먼트를 다시 표시하는 것이었다. 하지만, 그렇게 하면 잦은 화면 변경이 일어나는 모바일 환경에서 사용자 경험을 해치게 되므로, 1안은 포기하였다. (모바일 웹의 특성상, 사용자의 스크롤 행동에 따라 상단 주소표시줄이 나타났다 사라지면서 화면의 크기가 바뀔 수 있다.)

두 번째 방법은 많은 양의 텍스트를 줄 수에 따라 청크로 분리하고, intersection observer api를 사용해 보이는 청크만 렌더링하는 것이다. 화면 너머의 청크는 기본적으로 hidden처리하기로 한다.

첫 번째 시도

class PreviewText extends HTMLElement {
    // data
    #text = "";
    #chunkedText = [];
    // observer
    #observer;

    get text()
    {
        return this.#text;
    }
    set text(value)
    {
        this.#text = value;
        this.#chunkedText = [];
        const sliced = value.split("\n");
        const lines = sliced.length;
        const LINE_CHUNK = 100;
        for(let i=0; i<lines; i+=LINE_CHUNK)
        {
            this.#chunkedText.push(sliced.slice(i, i+LINE_CHUNK).join('\n'));
        }
        this.render();
    }
    constructor()
    {
        super();
        const shadowRoot = this.attachShadow({mode: "open"});
        const style = new CSSStyleSheet();
        style.insertRule("pre { margin:0; }");
        shadowRoot.adoptedStyleSheets = [style];

        this.#observer = new IntersectionObserver((entries, observer)=>{
            for(let entry of entries) {
                entry.target.style.visibility = entry.isIntersecting ? "visible" : "hidden";
            }
        });
    }
    disconnectedCallback()
    {
        this.#observer.disconnect();
    }
    render()
    {
        const children = this.shadowRoot.children;
        const oldLength = children.length;
        const newLength = this.#chunkedText.length;
        const fragment = new DocumentFragment();

        // update existing element
        for(let i=0; i<newLength; i++)
        {
            if(i < oldLength) {
                children[i].textContent = this.#chunkedText[i];
                children[i].style.visibility = "visible";
            }
            else {
                let textNode = document.createElement("pre");
                textNode.textContent = this.#chunkedText[i];
                this.#observer.observe(textNode);
                fragment.append(textNode);
            }
        }
        // remove overflown element
        for(let i=oldLength-1; i>=newLength; i--)
        {
            this.#observer.unobserve(children[i]);
            children[i].remove();
        }
        this.shadowRoot.append(fragment);
    }
}

window.customElements.define("preview-text", PreviewText);

export default PreviewText;

이 코드는 텍스트를 렌더링하는 컴포넌트의 코드로, 바닐라 자바스크립트 + 웹 컴포넌트의 Custom Element, Shadow Dom을 이용해서 제작되었다.

constructor()
{
  super();
  const shadowRoot = this.attachShadow({mode: "open"});
  const style = new CSSStyleSheet();
  style.insertRule("pre { margin:0; }");
  shadowRoot.adoptedStyleSheets = [style];

  this.#observer = new IntersectionObserver((entries, observer)=>{
  for(let entry of entries) {
    entry.target.style.visibility = entry.isIntersecting ? "visible" : "hidden";
  }
});
}

이 커스텀 엘리먼트의 생성자 부분이다. shadow dom을 이용하여 constructor 내부에서도 자식의 dom을 초기화하는 작업을 할 수 있게 했으며, 커스텀 엘리먼트 내의 스타일을 외부 스타일과 분리하였다.

intersection observer api를 이용해, 옵저버를 생성하고, 옵저버가 각 청크의 화면상 보임을 감지하면 청크의 visibility를 전환하도록 하였다.

화면 너머의 청크를 숨기는 것은 display: none; 대신 visibility: hidden;을 사용했었는데, 첫 번째 이유로는 display: none;을 이용하면 intersection observer가 영원히 청크의 가시성을 꺼진 상태로 판별하기 때문이었으며, 두 번째 이유로는 각 청크의 높이 계산을 브라우저에 맡기기 위해서였다. 적용하기 전에 비해 성능 향상은 있었으나, 여전히 50만 자 이상의 텍스트를 렌더링하면 100ms 이상의 시간이 소요된다. 지금 생각해보니, visibility: hidden;은 렌더 트리에서 엘리먼트가 제거되지 않기 때문에 여전히 많은 양의 오브젝트의 바운딩박스를 계산하는 작업이 필요했다. 그럼에도 불구하고 성능 향상이 있었던 것은 대용량의 텍스트를 페인팅하는 작업이 줄어들었기 때문으로 보여진다.

set text(value)
{
  this.#text = value;
  this.#chunkedText = [];
  const sliced = value.split("\n");
  const lines = sliced.length;
  const LINE_CHUNK = 100;
  for(let i=0; i<lines; i+=LINE_CHUNK)
  {
    this.#chunkedText.push(sliced.slice(i, i+LINE_CHUNK).join('\n'));
  }
  this.render();
}

이 커스텀 엘리먼트는 text getter, setter를 가지고 있다. text를 할당하면 원본 텍스트를 \n 기준으로 분리하고, 이 중 100개째의 텍스트를 하나의 청크로 묶어서 chunkedText 프로퍼티에 저장한다. 이후, render 함수를 호출한다.

render()
{
  const children = this.shadowRoot.children;
  const oldLength = children.length;
  const newLength = this.#chunkedText.length;
  const fragment = new DocumentFragment();

  // update existing element
  for(let i=0; i<newLength; i++)
  {
    if(i < oldLength) {
      children[i].textContent = this.#chunkedText[i];
      children[i].style.visibility = "visible";
    }
    else {
      let textNode = document.createElement("pre");
      textNode.textContent = this.#chunkedText[i];
      this.#observer.observe(textNode);
      fragment.append(textNode);
    }
  }
  // remove overflown element
  for(let i=oldLength-1; i>=newLength; i--)
  {
    this.#observer.unobserve(children[i]);
    children[i].remove();
  }
  this.shadowRoot.append(fragment);
}

shadow root의 children을 기준으로, 다음의 작업을 수행한다.

• 이미 존재하던 청크는 내용을 변경한다.
• 새롭게 생긴 청크 수가 원래 청크 수보다 크면, 청크를 생성한 뒤 observer에 해당 청크를 관찰하도록 한다.
• 새롭게 생긴 청크 수가 원래 청크 수보다 작으면, 넘치는 청크의 observer 관찰을 해제시키고, dom에서 제거한다.

이 때 이미 있던 청크의 visibility를 visible로 설정한 이유는 모종의 사유로 인해 새롭게 청크가 생겨날 때 있던 청크가 보여지지 않는 오류가 있기 때문이었으며 (나중에 알았는데, text를 변경할 때 disammountCallback이 호출되어서 모든 청크의 가시성이 해제되기 때문이었다), fragment를 사용하여 dom을 추가한 이유는 불필요하게 실제 dom의 리플로우를 여러 번 일으키는 것을 막기 위해서였다.

첫 번째 시도의 문제점

위에서도 잠깐 언급했었지만, 2가지 문제점이 있었다.

1. 화면 너머의 청크를 숨길 때 visiblity: hidden을 사용했기 때문에 일부 대용량의 텍스트를 렌더링할 때 여전히 100ms 이상의 시간이 소요된다는 점.

   visibility: hidden은 요소를 렌더 트리에서 제거하지 않기 때문에, 여전히 리플로우가 일어나면 보이지 않는 요소도 바운딩박스를 재계산하는 과정을 거쳐야 한다.

2. text를 변경할 때 이미 존재하던 텍스트의 옵저버 관찰이 풀려버리는 문제. 임시로 있던 청크에 visibility: visible을 설정해 보이게 해 놓았으나, 그 점으로 인해 intersection observer를 활용한 청크 단위 렌더링의 효과가 줄어든다는 문제가 있었다.

이 문제를 다음과 같이 해결하기로 하였다.

1. 이 컴포넌트는 코드를 보여주는 용도이기 때문에, <pre> 태그를 사용해서 텍스트를 렌더링하고 있다. 이 태그는 텍스트의 크기와 텍스트 줄 수에 따라 height가 고정적으로 바뀐다. 따라서, 미리 각 청크의 height값을 계산하여 자리를 차지하도록 전환한 뒤, 실제 텍스트를 렌더링하는 청크의 자식 엘리먼트를 숨기기로 하였다. 이렇게 하면 observer가 관찰하는 엘리먼트 자체는 보여진 상태로 유지되어 각 엘리먼트가 화면에 보이는 여부를 항상 관측할 수 있으며, 실제로 렌더링에 영향을 많이 미치는 보이지 않는 텍스트 엘리먼트를 렌더 트리에서 제거할 수 있다는 이점이 있다.

2. connectedCallback에 shadow dom의 모든 자식 엘리먼트를 관찰하게 하는 코드를 추가한다.

두 번째 시도

const LINE_CHUNK = 100;

class PreviewText extends HTMLElement {
    // data
    #text = "";
    #chunkedText = [];
    #lastLines = 0;
    // observer
    #observer;

    get text()
    {
        return this.#text;
    }
    set text(value)
    {
        this.#text = value;
        this.#chunkedText = [];
        const sliced = value.split("\n");
        const lines = sliced.length;
        for(let i=0; i<lines; i+=LINE_CHUNK)
        {
            this.#chunkedText.push(sliced.slice(i, i+LINE_CHUNK).join('\n'));
        }
        this.#lastLines = lines - (this.#chunkedText.length - 1) * LINE_CHUNK;
        this.render();
    }
    constructor()
    {
        super();
        const shadowRoot = this.attachShadow({mode: "open"});
        const style = new CSSStyleSheet();
        style.insertRule(`.wrapper, pre { margin:0; }`);
        style.insertRule(`.wrapper:not(:last-child) { width:100%; height:${LINE_CHUNK*46/3}px; }`);
        style.insertRule(`.wrapper:last-child { width:100%; height:calc(var(--lastLine) * 46px / 3); }`);
        shadowRoot.adoptedStyleSheets = [style];

        this.#observer = new IntersectionObserver((entries, observer)=>{
            for(let entry of entries) {
                const pre = entry.target.firstChild;
                pre.hidden = !entry.isIntersecting;
            }
        });
    }
    connectedCallback()
    {
        for(let child of this.shadowRoot.children) {
            this.#observer.observe(child);
        }
    }
    disconnectedCallback()
    {
        this.#observer.disconnect();
    }
    render()
    {
        const children = this.shadowRoot.children;
        const oldLength = children.length;
        const newLength = this.#chunkedText.length;
        const fragment = new DocumentFragment();
        this.style.setProperty("--lastLine", this.#lastLines);

        // update existing element
        for(let i=0; i<newLength; i++)
        {
            if(i < oldLength) {
                const pre = children[i].firstChild;
                pre.textContent = this.#chunkedText[i];
                //pre.style.visibility = "visible";
            }
            else {
                let wrapperNode = document.createElement("div");
                wrapperNode.className = "wrapper";
                let textNode = document.createElement("pre");
                textNode.textContent = this.#chunkedText[i];
                wrapperNode.append(textNode);
                this.#observer.observe(wrapperNode);
                fragment.append(wrapperNode);
            }
        }
        // remove overflown element
        for(let i=oldLength-1; i>=newLength; i--)
        {
            this.#observer.unobserve(children[i]);
            children[i].remove();
        }
        this.shadowRoot.append(fragment);
    }
}

window.customElements.define("preview-text", PreviewText);

export default PreviewText;

여러분이 알아보기 쉽게, react 코드로 전환하면 다음과 비슷하다. (실제로 작동하는 코드가 아닐 수 있으니 참고만 하시라.)

import { useRef, useEffect } from "react";
import styled from "styled-component";

const LINE_CHUNK = 100;

const Wrapper = styled.div`
margin: 0;
&:not(:last-child) {
  width: 100%;
  height: {LINE_CHUNK * 46/3}px;
}
&:last-child { 
  width: 100%;
  height: calc(var(--lastLine) * 46px / 3);
}
`;

const Pre = styled.pre`
margin: 0;
`

export function PreviewText({text})
{
  const ref = useRef(null);
  const observer = useRef( new IntersectionObserver( (entries, observer)=>{
    for(let entry of entries) {
      const pre = entry.target.firstChild;
      pre.hidden = !entry.isIntersecting;
    }
  } ) );

  useEffect( ()=>{
    for(let child of ref.children) {
      observer.current?.observe(child);
    }

    return ()=>{
      observer.current?.disconnect();
    }
  }, [text] );


  return <div style={ {"--lastLine": lastLine} } ref={ref}>
    {chunkedText.map( (content, i)=>{
      return <Wrapper className="wrapper">
        <Pre>{content}</Pre>
      </Wrapper>
    })}
  </div>
}

chunkedText를 element로 렌더링하는 부분에서, <pre> 태그를 <div> 태그로 감쌌다.

style.insertRule(`.wrapper, pre { margin:0; }`);
style.insertRule(`.wrapper:not(:last-child) { width:100%; height:${LINE_CHUNK*46/3}px; }`);
style.insertRule(`.wrapper:last-child { width:100%; height:calc(var(--lastLine) * 46px / 3); }`);
shadowRoot.adoptedStyleSheets = [style];

this.#observer = new IntersectionObserver((entries, observer)=>{
    for(let entry of entries) {
        const pre = entry.target.firstChild;
        pre.hidden = !entry.isIntersecting;
    }
});

먼저 constructor는 다음과 같이 바뀌었다. pre 엘리먼트는 렌더링되는 문자열의 줄 수와 폰트에 따라 높이가 결정되므로, 래퍼 엘리먼트의 마지막이 아닌 엘리먼트의 높이는 100 * 46/3 px으로 고정된다.

this.#lastLines = lines - (this.#chunkedText.length - 1) * LINE_CHUNK;

마지막 엘리먼트일 경우, lastLine css 변수를 따라 계산되는데, 이것은 text를 청크로 나누는 과정에서 계산되고 할당된다.

observer의 경우, 각 엔트리의 첫 번째 자식의 hidden 여부를 결정하도록 변경했다.

connectedCallback()
{
  for(let child of this.shadowRoot.children) {
    this.#observer.observe(child);
  }
}

해당 커스텀 엘리먼트가 dom에 추가될 때, shadow root의 모든 자식에 대해 관찰을 시도하는 콜백을 추가했다.

let wrapperNode = document.createElement("div");
wrapperNode.className = "wrapper";
let textNode = document.createElement("pre");
textNode.textContent = this.#chunkedText[i];
wrapperNode.append(textNode);
this.#observer.observe(wrapperNode);
fragment.append(wrapperNode);

바뀐 dom 설계에 따라 새로운 엘리먼트를 추가하는 코드다.

<div class="wrapper">
 <pre>(chunkedText[i])</pre>
</div>

를 정의하고 프래그먼트에 추가하는 코드라고 보면 된다.

결과

50만 자의 텍스트 렌더링 기준으로, 이전에는 2s 이상 걸리거나 아예 프리징이 되었던 텍스트 미리보기 컴포넌트의 레이아웃 계산 속도가 1~2ms로 2000배 이상 단축된 모습을 볼 수 있었다.

개요

아직 xnb.js 1.2가 처한 문제와 진행상황에 대해 모른다면, 전편을 읽고 오시라!

Stardew Valley 1.6 업데이트로 인해, 수많은 커스텀 자료형을 가진 xnb 파일이 생겨버렸고, 커스텀 자료구조의 추가를 수월하게 하기 위해 custom scheme을 받아서 커스텀 자료구조를 다룰 수 있게 하는 Reflective Scheme Reader를 개발하였다. 이 다음은 Reflective Scheme Reader가 해석할 수 있는 custom scheme을 만들면 되는 상황이다.

export default {
    Name: "String",
    DisplayName: "String",
    Description: "String",
    Price: "Int32",
    Fragility: "Int32",
    CanBePlacedOutdoors: "Boolean",
    CanBePlacedIndoors: "Boolean",
    IsLamp: "Boolean",
    $Texture: "String",
    SpriteIndex: "Int32",
    $ContextTags: ["String"],
    $CustomFields: {"String": "String"}
}

(위의 c# 코드를 아래의 형태로 바꿔야 한다.) 하지만, 여전히 문제는 남아 있었다. C# 클래스를 custom scheme으로 변환해야 하는데, 현재로서는 수동으로 사람이 C# 코드의 필드명과 타입을 파악하여, 일일이 아래와 같이 작성해줘야 하는 상황이다. 이 부분을 자동화할 수 있다면, 일손이 줄어들어서 개발 속도가 빨라질 것이며, 향후 1.7에서 다른 커스텀 자료형 xnb가 추가되더라도 빠르게 대응할 수 있을 것이라고 생각했다.

그러기 위해서는 C# 코드 문자열에서 타입과 필드명을 추출하는 방안이 필요했다.

마법의 제미니고둥

publicclassCharacterAppearanceData
 {
/// <summary>An ID for this entry within the appearance list. This only needs to be unique within the current list.</summary>
publicstringId;
/// <summary>A game state query which indicates whether this entry applies. Default true.</summary>
    [ContentSerializer(Optional = true)]
publicstringCondition;
/// <summary>The season when this appearance applies, or <c>null</c> for any season.</summary>
    [ContentSerializer(Optional = true)]
publicSeason? Season;
/// <summary>Whether the appearance can be used when the NPC is indoors.</summary>
    [ContentSerializer(Optional = true)]
publicboolIndoors = true;
/// <summary>Whether the appearance can be used when the NPC is outdoors.</summary>
    [ContentSerializer(Optional = true)]
publicboolOutdoors = true;
/// <summary>The asset name for the portrait texture, or null for the default portrait.</summary>
    [ContentSerializer(Optional = true)]
publicstringPortrait;
/// <summary>The asset name for the sprite texture, or null for the default sprite.</summary>
    [ContentSerializer(Optional = true)]
publicstringSprite;
/// <summary>Whether this is island beach attire worn at the resort.</summary>
/// <remarks>This is mutually exclusive: NPCs will never wear it in other contexts if it's true, and will never wear it as island attire if it's false.</remarks>
    [ContentSerializer(Optional = true)]
publicboolIsIslandAttire;
/// <summary>The order in which this entry should be checked, where 0 is the default value used by most entries. Entries with the same precedence are checked in the order listed.</summary>
    [ContentSerializer(Optional = true)]
publicintPrecedence;
/// <summary>If multiple entries with the same <see cref="F:StardewValley.GameData.Characters.CharacterAppearanceData.Precedence" /> apply, the relative weight to use when randomly choosing one.</summary>
/// <remarks>See remarks on <see cref="F:StardewValley.GameData.Characters.CharacterData.Appearance" />.</remarks>
    [ContentSerializer(Optional = true)]
publicintWeight;
 }

와 같은 c# 코드 문자열을 입력받아, 해당 클래스의 필드명과 타입을 반환하는 javascript 함수를 작성해 줘.

> I'd be glad to create a JavaScript function that translates the C# class fields and types, incorporating insights from the provided ratings:
> ```js
function convertC SharpeClassToJavaScript(csharpClassString) {
  // Remove comments and leading/trailing whitespace
  const cleanClassString = csharpClassString.replace(/\/\/.*|\/\*.*?\*\/|^\s+|\s+$/gm, '');
  // Extract field declarations using regular expression
  const fieldMatches = cleanClassString.match(/public (string|int|bool|\?|null) (\w+)(\[[^\]]*\])?( =.+)?;/g);
  if (!fieldMatches) {
    throw new Error('Invalid C# class format or no fields found.');
  }
  // Process each field match and build the JavaScript object
  const jsFields = {};
  for (const match of fieldMatches) {
    const parts = match.split(/\s+/);
    const type = parts[1];
    const name = parts[2];
    let isOptional = false;
    // Check for optional types (nullable or array)
    if (type.endsWith('?')) {
      isOptional = true;
      type = type.slice(0, -1);
    } else if (parts[3] && parts[3].startsWith('[')) {
      isOptional = true;
      type = 'any[]'; // Represent arrays as any[] for simplicity
    }
    // Handle default values
    let defaultValue = null;
    if (parts.length > 5 && parts[4] === '=') {
      defaultValue = parts.slice(5).join(' ');
      // Remove quotes for strings if necessary
      if (defaultValue.startsWith('"') && defaultValue.endsWith('"')) {
        defaultValue = defaultValue.slice(1, -1);
      }
    }
    jsFields[name] = {
      type: convertCSharpeTypeToJavaScript(type),
      optional: isOptional,
      default: defaultValue,
    };
  }
  return jsFields;
}
function convertCSharpeTypeToJavaScript(csharpType) {
  switch (csharpType) {
    case 'string':
      return 'string';
    case 'int':
      return 'number'; // Integers in JavaScript are floating-point numbers
    case 'bool':
      return 'boolean';
    case 'null':
      return 'null';
    default:
      return 'any'; // Handle unknown types as any
  }
}

인공지능 시대에 맞추어, 구글의 인공지능 Gemini를 활용해 기본적인 아이디어를 알아보았다. 역시 인공지능이다. 개발자도 인공지능을 활용하면 능률을 올릴 수 있다. 실제로 저 코드를 돌려본 결과, 나름 어느 정도의 정확성을 띄는 걸 보일 수 있다.

인공지능 코드분석

기본적으로, 인공지능이 내린 해답은 정규 표현식을 이용한 방법으로, 특정 패턴이 일치한 모든 문자열을 추출해, 해당 문자열에서 타입과 필드명 정보를 추출하는 방식이다.

const cleanClassString = csharpClassString.replace(/\/\/.*|\/\*.*?\*\/|^\s+|\s+$/gm, '');

필요 없는 주석과 공백을 제거하는 코드이다. 사용된 정규표현식은 다음의 4개의 정규표현식으로 나눌 수 있는데, 그것은 다음과 같다. \/\/.* : // (아무 문자)를 감지하는 정규표현식이다. \/\*.*?\*\/ : /* (아무 문자) */를 감지하는 정규표현식이다. 이 때 .*?은 non-greedy한 방식으로 아무 문자를 찾겠다는 의미다. 즉, /*yes*/no*/와 같은 문자열이 있을 때, /*yes*/만 추출하겠다는 의미다. ^\s+ : 문자열의 시작이 공백 문자의 연속인 경우를 감지하는 정규표현식이다. \s+$ : 문자열의 끝이 공백 문자의 연속인 경우를 감지하는 정규표현식이다. 정규 표현식 뒤에 붙은 gm 플래그는 전역적으로, 여러 라인에 걸쳐서 문자열을 탐지하라는 의미다.

const fieldMatches = cleanClassString.match(/public (string|int|bool|\?|null) (\w+)(\[[^\]]*\])?( =.+)?;/g);

C# 코드에서 프로퍼티 선언 부분을 추출하는 코드이다. 구체적으로는, 다음과 같다. public (string|int|bool|\?|null) : public (타입명) 을 추출한다. 다만, optional 타입(public string? MyVariable)의 경우 추출하지 못하는 버그가 있다. (\w+) : 변수명을 추출한다. (\[[^\]]*\])? : [test123]과 같은, 배열 여부를 추출한다. 구체적으로는, [를 감지하는 \[, 대괄호 내 ]이 아닌 문자열을 감지하는 [^\]]*, ]를 감지하는 \]로 나뉜다. 사실 이 부분은 인공지능의 한계로, 원래 c# 문법이 아니다. ( =.+)?; : 변수의 마지막 부분을 추출한다. = 뒤에 아무거나 있거나 없는 경우를 추출하며, 마지막은 ;로 끝나야 한다.

for (const match of fieldMatches) {
    const parts = match.split(/\s+/);
    const type = parts[1];
    const name = parts[2];
    let isOptional = false;
    // Check for optional types (nullable or array)
    if (type.endsWith('?')) {
      isOptional = true;
      type = type.slice(0, -1);
    } else if (parts[3] && parts[3].startsWith('[')) {
      isOptional = true;
      type = 'any[]'; // Represent arrays as any[] for simplicity
    }

fieldMatches는 정규표현식의 그룹과 상관없이 매치된 모든 문자열 전체를 배열로 저장한다. 이 배열을 순회한다.

• 우선, 공백 문자를 기준으로 파트를 나눈다.
• type, name을 추출하고, type이 ?로 끝나는 경우에는 optional 플래그를 true로 변경시킨다.
  • 다만, 인공지능이 생성한 정규표현식에 오류가 있어서 public int? MyProperty;와 같은 실제 optional field는 추출하지 못한다.
• 파트의 4번째가 존재하고, [로 시작할 때, 배열로 간주하고 type을 any[]로 설정한다.
  • *단, 실제 C# 코드에서는 배열 프로퍼티를 public int[] test;와 같이 선언하지, public int test []와 같이 선언하지 않는다.

    let defaultValue = null;
    if (parts.length > 5 && parts[4] === '=') {
      defaultValue = parts.slice(5).join(' ');
      // Remove quotes for strings if necessary
      if (defaultValue.startsWith('"') && defaultValue.endsWith('"')) {
        defaultValue = defaultValue.slice(1, -1);
      }
    }

추출한 문자열에 =가 있는 경우, parts 뒤에 있는 모든 문자열을 디폴트 값으로 취급하고, 이를 변수에 저장한다. 만약 ""로 시작하는 경우는 앞 뒤의 따옴표를 제거한다.

jsFields[name] = {
      type: convertCSharpeTypeToJavaScript(type),
      optional: isOptional,
      default: defaultValue,
    };

result 객체의 이름 필드에, 타입, optional 여부, default 값을 저장한 객체를 할당한다.

자잘한 오류들이 있어서 실제로 적용시킬 수는 없으나, 기본적으로 정규표현식을 이용한다는 아이디어를 얻었으므로, 이 아이디어를 기반으로 코드를 개조할 생각이다.

결과물

const enums = [
    "Season",
    "Gender",
    "MachineOutputTrigger",
    "MachineTimeBlockers",
    "QuantityModifier.ModificationType",
    "QuantityModifier.QuantityModifierMode",
    "PetAnimationLoopMode",
    "LimitedStockMode",
    "ShopOwnerType",
    "StackSizeVisibility",
    "QuestDuration",
    "WildTreeGrowthStage",
    "PlantableRuleContext",
    "PlantableResult"
];

function convertCSharpTypeToSchemeData(raw)
{
    if(raw === "int") return "Int32";
    if(raw === "string") return "String";
    if(raw === "double") return "Double";
    if(raw === "bool") return "Boolean";
    if(raw === "float") return "Single";
    if(raw === "char") return "Char";
    if(enums.includes(raw)) return "Int32";

    let isArray = raw.endsWith("[]");
    if(isArray) return `Array<${convertCSharpTypeToSchemeData(raw.slice(0,-2))}>`;

    if(raw.startsWith("List")) {
        const [,value]= /List<([\w?\[\]<,.>]+)>/.exec(raw);
        return [ convertCSharpTypeToSchemeData(value) ];
    }
    if(raw.startsWith("Dictionary")) {
        const [,key,value] = /Dictionary<([\w?\[\]<.>]+),([\w?\[\]<.>]+)>/.exec(raw);
        return {
            [convertCSharpTypeToSchemeData(key)] : convertCSharpTypeToSchemeData(value)
        }
    }
    return raw;
}

function isPrimitive(type)
{
    const primitiveList = [
        "Int32",
        "Single",
        "Double",
        "Boolean",
        "Char",
        "Point",
        "Vector2",
        "Vector3",
        "Vector4",
        "Rectangle"
    ];

    return primitiveList.includes(type);
}


function convertCSharpClassToSchemeData(csharpClassString)
{
    const cleanClassString = csharpClassString.replace(/\/\/.*|\/\*.*?\*\/|^\s+|\s+$/gm, '').replace(/,\s*/gm, ',');

    const regExp = /(\[ContentSerializer\(Optional = true\)\]\n|\[ContentSerializerIgnore\]\n)?public ([\w?\[\]<.,>]+) ([\w_]+)(;| = | { get)/;
    const fieldMatches = cleanClassString.match(new RegExp(regExp, "g"));

    console.log(fieldMatches);

    let result = {};

    for(let rawCode of fieldMatches)
    {
        let [, decorator, type, field] = regExp.exec(rawCode);
        let optional = false;
        if(decorator === "[ContentSerializerIgnore]\n") continue;
        if(type.endsWith("?")) {
            optional = true;
            type = type.slice(0, -1);
        }
        type = convertCSharpTypeToSchemeData(type);

        if(decorator === "[ContentSerializer(Optional = true)]\n" && !isPrimitive(type)) optional = true;

        if(optional) field = "$"+field;
        result[field] = type;
    }

    console.log("export default "+JSON.stringify(result, null, 2)+";");

    return result;
}

다음과 같은 코드를 작성하였다. 전반적으로, 제미니가 사용한 코드를 기반으로 코드를 깔끔하게 다듬고 실제 C# 코드에 맞게 수정하였다.

코드 분석

const regExp = /(\[ContentSerializer\(Optional = true\)\]\n|\[ContentSerializerIgnore\]\n)?public ([\w?\[\]<.,>]+) ([\w_]+)(;| = | { get)/;

타입을 정의하는 코드를 추출하는 정규표현식을 정의한다. 이 정규표현식이 cleanClassString에서 타입 코드의 목록을 추출하는 역할도 하지만, 각 타입 코드 문자열에서 데코레이터, 타입, 필드를 추출하는 역할을 하기도 한다. 구체적으로 분석하자면 다음과 같다.

• (\[ContentSerializer\(Optional = true\)\]\n|\[ContentSerializerIgnore\]\n)? : 데코레이터 부분을 추출한다.
  • [ContentSerializer(Optional = true)]는 해당 c# 필드가 시리얼라이즈되었을 때, 즉 xnb 파일로 변환했을 때 optional한지를 나타내는 필드다. 해당 데코레이터가 존재하면, 해당 필드를 xnb 파일로 다음과 같이 저장한다.
    • 원시 자료형(int, float, double, boolean, char) : 아무런 영향이 없다. 그대로 저장한다.
    • 참조형 자료형(string, List, Dictionary, 사용자 정의 클래스 등) : nullable 자료형으로 래핑되어서 저장된다. 값이 null이면 첫 번째 바이트에 0을 저장하고 종료하며, 값이 null이 아니면 첫 번째 바이트에 사용되는 리더의 일련번호를 저장한 뒤 두 번째 바이트부터 실제 타입의 리더를 사용해 저장된다.
  • [ContentSerializerIgnore]는 해당 c# 필드가 시리얼라이즈되지 않는다는 의미다. 해당 데코레이터가 존재하면, 저장을 무시한다.
• public ([\w?\[\]<.,>]+) : 타입 부분을 추출한다. 타입은 int, string, bool 등만 존재하는 것이 아니라, 사용자 정의 클래스도 존재하며, 제네릭 클래스나 심지어는 .이 붙은 클래스도 존재하기에 다음과 같이 정규표현식을 작성했다.
• ([\w_]+) : 변수명 부분을 추출한다. 사실 생각해보니 (\w+)로 작성해도 _를 인지할 수 있다.
• (;| = | { get) : 이 부분이 실제로 변수를 선언하는 것인지를 파악한다. ;로 끝나거나, =로 끝나거나, { get으로 끝나는 경우는 시리얼라이즈되는 변수로 파악한다. 변수가 아닌 함수 등을 거르기 위해 사용되었다.

참고로 필드의 디폴트 값은 관심사가 아니기 때문에 추출하지 않는다.

const fieldMatches = cleanClassString.match(new RegExp(regExp, "g"));

위의 정규표현식을 기반으로, C# 코드에서 프로퍼티를 선언한 코드의 목록을 추출한다.

for(let rawCode of fieldMatches)
{
    let [, decorator, type, field] = regExp.exec(rawCode);
    let optional = false;
    if(decorator === "[ContentSerializerIgnore]\n") continue;
    if(type.endsWith("?")) {
        optional = true;
        type = type.slice(0, -1);
    }

    type = convertCSharpTypeToSchemeData(type);

    if(decorator === "[ContentSerializer(Optional = true)]\n" && !isPrimitive(type)) optional = true;
    if(optional) field = "$"+field;
    result[field] = type;
}

모든 프로퍼티 선언 코드 목록에 대해, 다음의 코드를 실행한다.

• 위에서 선언한 정규 표현식을 기반으로, 데코레이터, 타입, 필드를 추출해 변수에 저장한다. let [, decorator, type, field]와 같이 생긴 요상한 문법은 ES6에서 추가된 구조 분해 할당이다. 콤마 앞에 아무것도 안 쓴 이유는 일치하는 전체 문자열을 안 쓰겠다는 의미.
• 데코레이터가 [ContentSerializerIgnore]인 경우 무시하고 다음으로 넘어간다.
• 타입이 ?로 끝날 경우, nullable한 원시 자료형이다. optional을 true로 하고 type 문자열에서 ?를 제거한다.
• 데코레이터가 [ContentSerializer(Optional = true)]이고, 타입이 원시 자료형이 아닌 경우, optional을 true로 한다.
• C# 타입을 xnb.js의 custom scheme이 사용하는 타입으로 변화시킨다. 해당 함수는 하술.
• optional이 true일 때, 필드명 앞에 $를 추가한다.
• result 객체에 값을 저장한다.

function convertCSharpTypeToSchemeData(raw)
{
    if(raw === "int") return "Int32";
    if(raw === "string") return "String";
    if(raw === "double") return "Double";
    if(raw === "bool") return "Boolean";
    if(raw === "float") return "Single";
    if(raw === "char") return "Char";
    if(enums.includes(raw)) return "Int32";

    let isArray = raw.endsWith("[]");
    if(isArray) return `Array<${convertCSharpTypeToSchemeData(raw.slice(0,-2))}>`;

    if(raw.startsWith("List")) {
        const [,value]= /List<([\w?\[\]<,.>]+)>/.exec(raw);
        return [ convertCSharpTypeToSchemeData(value) ];
    }
    if(raw.startsWith("Dictionary")) {
        const [,key,value] = /Dictionary<([\w?\[\]<.>]+),([\w?\[\]<.>]+)>/.exec(raw);
        return {
            [convertCSharpTypeToSchemeData(key)] : convertCSharpTypeToSchemeData(value)
        }
    }
    return raw;
}

C# 타입을 xnb.js의 custom scheme이 사용하는 타입으로 변화시키는 함수다. 다음의 과정을 거친다.

• 원시 타입이 int, string, double, bool, float, char일 경우, 해당하는 타입으로 변화시킨다. 참고로 저 타입은 xnb 리더의 타입 이름들이다. (Int32Reader의 경우 Int32)
• 원시 타입이 미리 정의된 enum에 속해 있을 경우, Int32를 리턴한다. enum 자료형은 xnb 파일에 전부 int형으로 저장된다.
• 원시 타입 문자열이 []로 끝날 경우, Array 자료형이다. 원시 타입 문자열에서 []를 제거한 문자열에 대해 다시 해당 변환 과정을 수행하고, Array<타입>을 리턴한다.
• 원시 타입 문자열이 List로 시작할 경우, List 자료형이다. 원시 타입 문자열에서 <> 내부의 값을 추출한 뒤, 해당 값에 대해 변환 과정을 수행하고, [ 타입 ]을 리턴한다.
• 원시 타입 문자열이 Dictionary로 시작할 경우, Dictionary 자료형이다. <> 내부 key와 value 타입 값을 추출한 뒤, 해당 값에 대해 변환 과정을 수행하고, {key 타입 : value 타입}을 리턴한다.

console.log("export default "+JSON.stringify(result, null, 2)+";");

결과값을 콘솔에 추가한다. 사용자는 콘솔에 찍힌 결과값을 복붙해 파일에 저장할 수 있다.

결과

이렇게 C# 코드를 xnb.js가 해석하는 custom scheme으로 변경하는 코드를 만들었더니, 작업 프로세스가 비약적으로 단축된 모습을 보였다. 기존에는 C# 코드를 직접 불러와 일일이 해석하고 타이핑하는 과정을 거쳤다면, 이제는 C# 코드 복사 -> 함수 실행 -> 실행 결과를 js 파일로 저장하는 과정으로 단축되었기 때문이다. 물론 C# 코드에 적힌 필드의 저장 순서와 실제 xnb 파일에 저장된 필드 저장 순서가 다른 경우도 있어서 그 부분은 직접 수정이 필요했지만, 어쨌거나 대부분의 경우는 잘작동되는 모습을 보였다!

한국 시간으로 2024년 3월 20일 오전 3시, Stardew Valley 1.6이 업데이트되었다. 이에 따라 Stardew Valley의 유틸리티 웹 앱인 xnb.js와 stardew dressup의 업데이트가 불가피해졌다. Stardew Valley 1.6 업데이트가 xnb.js와 stardew dressup에 미치는 영향은 다음과 같다.

• xnb.js
  • 대규모의 xnb 데이터 포맷 변경
    • stardew valley가 사용하는 Data를 담은 xnb 파일이 더 이상 {string: string} 형의 딕셔너리 자료형이 아닌, c# 객체를 담은 커스텀 자료구조 포맷으로 변경되었다.
• stardew dressup
  • 신규 모자, 상의, 악세서리 추가
  • 체형 스프라이트 변경

따라서, 거의 2년 만에 xnb.js와 stardew dressup을 업데이트하기로 결정했다.

문제 상황

에릭 바론, 이게 맞아요?

Stardew Valley 1.6에서는 수많은 양의 데이터를 저장하는 새로운 클래스들이 생겼다. 1.5까지는 클래스의 양이 적었기 때문에, 다음의 방식으로 코드를 추가했었다.

import {BaseReader,
    ListReader,
    Int32Reader,
    StringReader,
    DictionaryReader,
    NullableReader
} from "../../readers/readers.js"; //@xnb/readers
import FishPondRewardReader from "./FishPondRewardReader.js";

/**
 * FishPondData Reader
 * @class
 * @extends BaseReader
 */
export default class FishPondDataReader extends BaseReader {
    static isTypeOf(type) {
        switch (type) {
            case 'StardewValley.GameData.FishPond.FishPondData':
                return true;
            default: return false;
        }
    }
    static parseTypeList() {
        return ["FishPondData", 
            "List<String>", "String", // requiredTags
            null, // spawnTime
            "List<FishPondReward>", ...FishPondRewardReader.parseTypeList(), //producedItems
            "Nullable<Dictionary<Int32,List<String>>>:4", 
            "Dictionary<Int32,List<String>>", "Int32", "List<String>", "String" //populationGates
        ];
    }
    static type()
    {
        return "Reflective<FishPondData>";
    }

    /**
     * Reads FishPondData from buffer.
     * @param {BufferReader} buffer
     * @param {ReaderResolver} resolver
     * @returns {object}
     */
    read(buffer, resolver) {
        const int32Reader = new Int32Reader();
        const stringListDictReader = new NullableReader( new DictionaryReader(
            new Int32Reader(),
            new ListReader( new StringReader() )
        ) );

        const RequiredTags = resolver.read(buffer);
        const SpawnTime = int32Reader.read(buffer);
        const ProducedItems = resolver.read(buffer);
        const PopulationGates = stringListDictReader.read(buffer, resolver);

        return {
            RequiredTags,
            SpawnTime,
            ProducedItems,
            PopulationGates
        };
    }

    write(buffer, content, resolver) {
        const stringListReader = new ListReader( new StringReader() );
        const int32Reader = new Int32Reader();
        const fishPondRewardListReader = new ListReader( new FishPondRewardReader() );
        const stringListDictReader = new NullableReader( new DictionaryReader(
            new Int32Reader(),
            new ListReader( new StringReader() )
        ) );

        this.writeIndex(buffer, resolver);

        stringListReader.write(buffer, content.RequiredTags, resolver);
        int32Reader.write(buffer, content.SpawnTime, null);
        fishPondRewardListReader.write(buffer, content.ProducedItems, resolver);
        stringListDictReader.write(buffer, content.PopulationGates, resolver);
    }

    isValueType() {
        return false;
    }
}

c# 클래스를 기반으로, 읽기 함수, 쓰기 함수, parseTypeList(언팩한 json을 yaml 포맷으로 바꾸는 데 annotation을 붙이는 데 필요하다)를 일일이 작성하고, 이를 클래스로 만들어야 했다. 1.5까지는 커스텀 자료구조를 저장하는 xnb 파일이 별로 없어서 전통적인 방식을 유지해도 상관이 없었으나, 1.6에서 대규모의 커스텀 자료구조 xnb 파일이 추가되면서, 전통적인 방식을 고수하면 유지보수하기 매우 어려울 것이라는 생각이 들었다. 따라서, 타입 구조 객체를 받아서 위와 같은 코드로 동작하는 xnb 리더를 만들기로 결정했다.

공통점 파악

using Microsoft.Xna.Framework.Content;
using System.Collections.Generic;

namespace StardewValley.GameData.FishPond
{
    public class FishPondData
    {
        public List<string> RequiredTags;

        [ContentSerializer(Optional = true)]
        public int SpawnTime = -1;

        public List<FishPondReward> ProducedItems;

        [ContentSerializer(Optional = true)]
        public Dictionary<int, List<string>> PopulationGates;
    }
}

read(buffer, resolver) {
    const int32Reader = new Int32Reader();
    const stringListDictReader = new NullableReader( new DictionaryReader(
        new Int32Reader(),
        new ListReader( new StringReader() )
    ) );

    const RequiredTags = resolver.read(buffer);
    const SpawnTime = int32Reader.read(buffer);
    const ProducedItems = resolver.read(buffer);
    const PopulationGates = stringListDictReader.read(buffer, resolver);

    return {
        RequiredTags,
        SpawnTime,
        ProducedItems,
        PopulationGates
    };
}

위는 원본 c# 클래스이며, 아래는 해당 c# 클래스의 인스턴스를 저장하는 xnb 파일을 불러오는 read 함수다. 클래스의 필드명이 언팩 객체의 필드명이 되며, [ContentSerializer(Optional = true)]가 붙은 필드는 nullable로 감싸주고 있다. resolver(xnb 파일의 헤더를 읽어와 필요한 reader를 선언한다)에 정의되지 않은, 원시 자료형 reader나, nullable reader는 따로 리더 인스턴스를 선언한 뒤 이를 기반으로 읽기 과정을 수행하며, 그렇지 않은 경우 resolver에 읽기 과정을 맡긴다.

잘 생각해 보면, 미리 객체의 key와 reader를 대응시킨 map을 만든 뒤 이를 순회하면 해결할 수 있을 것 같다.

read(buffer, resolver) {
  const result = {};
  for(let [key, reader] of this.readers.entries())
  {
    if(reader.isValueType()) result[key] = reader.read(buffer);
    else if(reader.constructor.type() === "Nullable") result[key] = reader.read(buffer, resolver);
    else result[key] = resolver.read(buffer);
  }

  return result;
}

이렇게 변환할 수 있다. write 역시 비슷한 방식으로 바꿀 수 있다.

문제는 타입 데이터를 기반으로 커스텀 reader를 생성하는 것에 있었는데...

접근 과정

분석 결과, 커스텀 클래스형 자료구조 플러그인은 ReflectiveReader를 사용하고 있었으며, ReflectiveReader의 하위 데이터로 C# 클래스를 갖는 것을 확인할 수 있다. 이를 기반으로, 타입을 정리한 scheme 객체를 이용해 해당 타입 구조를 언팩하고 패킹할 수 있는 ReflectiveReader를 반환하기로 결정한다.

xnb.js가 xnb 파일을 언팩하는 과정은 다음과 같다.

1. lz4 혹은 lzx로 압축된 파일의 압축을 해제한다.
2. 헤더 부분의 유효성을 확인하고, 헤더 데이터를 추출한다.
3. 리더 데이터를 읽어온다.
4. 문자열로 된 리더 데이터를 기반으로, TypeReader static 클래스에서 문자열로 된 리더를 실제 객체 리더로 변환한다.
5. 실제 리더 객체 리스트를 기반으로, 데이터를 언팩한다.

xnb.js가 문자열로 된 리더를 실제 객체로 변환하는 과정은 다음과 같다.

1. 생 문자열로 된 리더를 간략화한다. 이 과정은 디버깅에도 쓰이지만, 리더 객체를 빠르게 찾거나, yaml로 변환할 때 타입을 첨부하는 데에도 쓰인다.
2. 간략화된 문자열을 기반으로 실제 리더 객체를 반환한다.

예시로, Microsoft.Xna.Framework.Content.DictionaryReader｀2[[System.String, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089],[StardewValley.GameData.Fences.FenceData, StardewValley.GameData, Version=1.6.1.24080, Culture=neutral, PublicKeyToken=null]] 문자열은 Dictionary<String, StardewValley.GameData.Fences.FenceData> 로 간략화되고, 다시 이것이 new DictionaryReader(new StringReader(), new FenceDataReader()) 로 바뀌는 형태다.

처음에는 ReflectiveReader를 상속하는 별도의 클래스를 만들거나, ReflectiveReader를 반환하는 함수를 reader 라이브러리에서 만들까 생각했지만, 전자의 경우는 유연성이 떨어질 것으로 예상되며, 후자의 경우는 reader 라이브러리에서 현재 임포트된 reader를 알기 위해 core 라이브러리를 참조하게 되는 경우가 있어서, core 라이브러리의 TypeReader 클래스, 즉 문자열 리더를 기반으로 실제 리더를 반환시키는 것을 담당하는 클래스를 수정하기로 결심했다.

TypeReader 클래스는 다음과 같은 수정과정을 거쳤다.

1. simplifyType, getReader 메소드는 ReflectiveReader / ReflectiveScheme 문자열이 감지되면, 하위 타입을 기반으로 ReflectiveScheme<${simple}> / ReflectReader 객체를 반환한다. 이 때, 하위호환성을 위해 이미 ReflectedReader를 커스텀 리더 클래스로 구현한 경우 그것을 우선시한다.
2. simplifyType, getReader 메소드는 알 수 없는 문자열이 감지되면 해당 클래스를 지원하는 schemes가 있는지 감지하고, 있으면 ReflectiveScheme<${simple}> / ReflectReader 객체를 반환한다.
3. 커스텀 타입 구조를 임포트할 수 있는 setSchemes, addSchemes API를 추가했다. 이 때, 임포트를 진행할 때 미리 임포트한 객체를 실제 Reader 객체로 변환시킨다.
4. scheme을 reader로 변환시키는 코드는 다음과 같다.

function convertSchemeEntryToReader(scheme)
{
    if(typeof scheme === "string") return TypeReader.getReader(scheme);

    if(Array.isArray(scheme)) {
        const ListReader = TypeReader.getReaderClass("ListReader");
        return new ListReader(convertSchemeEntryToReader(scheme[0]));
    }
    if(typeof scheme === "object") {
        const keyCount = Object.keys(scheme).length;
        if(keyCount === 1) {
            const DictionaryReader = TypeReader.getReaderClass("DictionaryReader");
            const [key, value] = Object.entries(scheme)[0];

            return new DictionaryReader(
                convertSchemeEntryToReader(key),
                convertSchemeEntryToReader(value)
            );
        }
        else if(keyCount > 1) {
            return convertSchemeToReader(scheme);
        }
    }
    throw new XnbError(`Invalid Scheme to convert! : ${scheme}`);
}

function convertSchemeToReader(scheme)
{
    const result = new Map();
    for(let [key, type] of Object.entries(scheme))
    {
        let reader = convertSchemeEntryToReader(type);

        if(key.startsWith("@")) {
            key = key.slice(1);
            if(!reader.isValueType()) {
                try {
                    reader = new TypeReader.readers.NullableReader(reader);
                }
                catch {
                    throw new XnbError("There is no NullableReader from reader list!");
                }
            }
        }
        result.set(key, reader);
    }
    return result;
}

• scheme 오브젝트의 key, value를 순회한다.
  • value를 기반으로 리더를 반환하는데,
    • value가 문자열이면 해당 타입과 일치하는 reader 객체를 반환한다.
    • value가 ["Type"] 형태면 reader 객체를 ListReader로 감싼다.
    • value가 {"KeyType" : "ValueType"} 형태면 reader 객체를 DictionaryReader로 감싼다.
    • 그 밖의 경우, 재귀적으로 실행한다.
  • 만약 key가 @key 타입인 경우, 해당 key는 optional 필드이다.
    • NullableReader로 reader 객체를 감싼다.
    • 만약 reader 객체가 primitive 자료형을 다루는 객체인 경우, 해당 객체는 nullable로 감싼 형태로 패킹되지 않으므로, reader 객체를 감싸지 않는다.
• 변환된 key와 value를 map 객체에 저장한다. map 객체에 저장하는 까닭은 map 객체는 추가한 순서를 보장하므로, 필드의 순서가 중요한 xnb 언팩에 적합하기 때문이다.

이를 기반으로, reflectiveReader는 이름과 readers를 기반으로 다음의 언팩/패킹 과정을 거치게 된다.

/**
 * Reflective Reader
 * @class
 * @extends BaseReader
 */
export default class ReflectiveSchemeReader {
    static isTypeOf(type) {
        return false;
    }
    static hasSubType() {
        return false;
    }
    static type()
    {
        return "ReflectiveScheme";
    }
    /**
     * @constructor
     * @param {Object} object scheme
     */
    constructor(name, readers) {
        this.name = name;
        this.readers = readers;
    }

    /**
     * Reads Reflection data from buffer.
     * @param {BufferReader} buffer
     * @returns {Mixed}
     */
    read(buffer, resolver) {
        const result = {};
        for(let [key, reader] of this.readers.entries())
        {
            if(reader.isValueType()) result[key] = reader.read(buffer);
            else if(reader.constructor.type() === "Nullable") result[key] = reader.read(buffer, resolver);
            else result[key] = resolver.read(buffer);
        }

        return result;
    }

    /**
     * Writes Reflection data and returns buffer
     * @param {BufferWriter} buffer
     * @param {Number} content
     * @param {ReaderResolver} resolver
     */
    write(buffer, content, resolver) {
        this.writeIndex(buffer, resolver);
        for(let [key, reader] of this.readers.entries())
        {
            reader.write(buffer, content[key], (reader.isValueType() ? null : resolver));
        }

• read 함수는 readers의 entries를 순회해, reader가 value 타입이거나 nullable 타입이면 reader 객체를 이용해 데이터를 가져오고, 그렇지 않으면 미리 정의된 resolver를 이용해 데이터를 가져온다. 불러온 데이터를 기반으로 result 객체에 저장한다.
• write 함수는 index를 먼저 저장한 뒤, readers의 entries를 순회해, reader가 원시 타입이면 resolver 매개변수에 null을, 그렇지 않으면 resolver 객체를 인자로 넣어 reader를 이용해 값을 쓴다.
  • resolver 매개변수에 원시 타입 여부를 구분하는 까닭은, xnb 포맷이 원시 타입 데이터를 저장하기 전에 사용하는 리더의 인덱스를 저장하지 않기 때문이다.

향후 개발사항

• 잠재적으로 특정 c# 클래스의 프로퍼티 타입이 다른 c# 클래스를 참조할 수 있다. 해당 부분은 고려가 필요할 것.
• 아직 yaml을 대응하기 위한 parseTypeList 함수를 안 만들었다. 곧 만들 예정.

리액트에서 다른 컴포넌트에 스와이퍼 페이지네이션 부착하기

<div class="swiper">
    <div class="swiper-wrapper">
        <div>1</div>
        <div>2</div>
        <div>3</div>
        <div>4</div>
    </div>
</div>
<nav class="pagination">
    <div class="pagination-button"></div>
    <div class="pagination-button"></div>
    <div class="pagination-button"></div>
    <div class="pagination-button"></div>
</nav>

위와 같은 구조의 html을 짜고 싶었다. swiper 엘리먼트 내부에서 각 엘리먼트가 스와이프되고, pagination 엘리먼트 내에 있는 각 원소를 클릭하면 스와이퍼가 자동으로 이동하도록 만들고 싶었다. 이걸 react와 swiper.js로 짜야 한다. 어떻게 해야 할까?

Swiper.js는 기본적으로 Swiper 컴포넌트 내에 pagination, navigation 등 엘리먼트를 자동으로 생성한다. 하지만 Swiper 내용과 페이지네이션을 분리하고 싶을 때가 있다.

Swiper 컴포넌트의 pagination 속성에는 el이라는 속성이 있다. null로 지정하면 기본적으로 Swiper 컴포넌트 내에 새로운 페이지네이션 태그를 생성하지만, CSSSelector 문자열이나 html 엘리먼트를 넣을 수 있다. 리액트에서 어떠한 컴포넌트의 실제 html 엘리먼트를 가져오려면? ref를 이용하면 된다.

아니 이게 왜 안 돼요

import {useRef} from "react";
import {Pagination} from "swiper";
import {Swiper, SwiperSlide} from "swiper/react";

function mySwiper()
{
    const paginationElement = useRef(null);
    return (
        <>
            <Swiper 
                pagination={
                    el=paginationElement.current,
                    clickable=true
                }
                modules={[Pagination]}
            >
                <SwiperSlide><div>1</div></SwiperSlide>
                <SwiperSlide><div>2</div></SwiperSlide>
                <SwiperSlide><div>3</div></SwiperSlide>
                <SwiperSlide><div>4</div></SwiperSlide>
            </Swiper>
            <nav ref={paginationElement}></nav>
        </>
    );
}

그래서 Swiper 컴포넌트 밖에 nav 태그를 추가하고, ref를 준 뒤 pagination.el에 ref.current를 대입하는 것을 시도했지만 실패했다. 왜 실패했을까?

paginationElement ref는 처음에 null로 초기화된다. mySwiper 함수형 컴포넌트가 렌더링되면 Swiper 컴포넌트를 초기화할 때 pagination.el에 null이 대입되고, 이를 기반으로 스와이퍼를 생성한다. 이후 ref가 컴포넌트에 부착되면 ref.current에 컴포넌트의 실제 엘리먼트가 대입된다. 즉 이 경우는 Swiper 컴포넌트가 이미 null로 초기화된 후 paginationElement ref를 nav 태그에 부착했기 때문에 안 되는 것이다.

function useSwiperRef()
{
    const [wrapper, setWrapper] = useState(null);
    const ref = useRef(null);

    useEffect(() => {
        setWrapper(ref.current);
    }, []);

    return [wrapper, ref];
};

이 방법을 해결하기 위해 구글링을 하다, 위의 커스텀 hook을 이용하면 가능하다고 한다. 실제로 돌려보니 잘 되었다. 그렇다면 대체 왜 이 커스텀 hook을 이용하면 swiper의 pagination을 잘 부착할 수 있는 것일까?

왜 될까

useSwiperRef를 이용하면 mySwiper 컴포넌트의 렌더링이 2번 실행된다. 1번은 null을 이용하여 Swiper를 초기화하지만, nav 태그에 ref가 부착되면 mySwiper 컴포넌트가 다시 렌더링되어, nav 태그의 실제 dom을 이용하여 Swiper를 초기화한다.

좀 더 자세하게 살펴보면 다음과 같다.

1. mySwiper 컴포넌트를 처음 렌더링을 시도한다. mySwiper 함수의 useSwiperRef 함수를 실행한다.
2. useSwiperRef 함수가 실행되고 wrapper state와 ref가 리턴된다.
3. 리턴값을 평가한다. Swiper 컴포넌트를 렌더링 시도하는데, 아직 ref가 바인딩되지 않았으므로 ref는 null으로 취급한다.
4. ref.current가 실제 nav 태그의 dom으로 대입된다.
5. 컴포넌트가 렌더링 완료되면 커스텀 훅 안에 있는 useEffect를 실행한다. setWrapper로 state를 변경한다.
6. 리액트는 mySwiper의 state가 변경되었다고 판단하고, mySwiper를 리렌더링한다.
7. useSwiperRef 함수가 실행되고, wrapper state와 ref를 가져온다.
8. 리턴값을 평가한다. Swiper 컴포넌트를 렌더링 시도하면서 nav 태그의 dom으로 대입된 ref.current를 갖고 Swiper를 렌더링한다.
9. 컴포넌트가 렌더링 완료되면 커스텀 훅 안에 있는 useEffect를 실행하려고 하나, 2번째 인자가 빈 배열이므로 실행하지 않는다.

useEffect의 2번째 인자

useEffect는 2개의 인자를 받으며, 첫 번째 인자로 컴포넌트가 마운팅되고 업데이트될 때 실행하는 콜백 함수를, 두 번째 인자로 배열을 받는다. 2번째 인자의 의미가 무엇일까?

기본적으로 useEffect는 렌더링 함수가 마무리되면 바로 실행된다. 하지만 모든 업데이트 때마다 useEffect의 함수를 실행하면 성능이 저하될 것이다. 그래서 일부 상태가 변경될 때에만 실행되게 하도록 만들고 싶은데 이것이 useEffect의 2번째 인자의 존재 의의다.

useEffect가 실행될 때, 직전에 실행했던 배열의 각 원소와 현재 실행되는 배열의 원소를 비교하여, 그 내용이 변경되면 콜백 함수를 실행한다. 그 예시는 다음과 같다.

function MyComponent()
{
    const [toggle, setToggle] = useState(false);
    const [count1, setCount1] = useState(0);
    const [count2, setCount2] = useState(0);
    useEffect( ()=>{
        console.log("yes!");
    }, [toggle, count1] );
    return <>
        <button onClick={()=>setToggle( prev=>!prev )} >toggle</button>
        <button onClick={()=>setCount1( prev=>prev+1 )} >count1</button>
        <button onClick={()=>setCount2( prev=>prev+2 )} >count2</button>
    </>
}

MyComponent 컴포넌트가 렌더링되고, [false,0]을 기준으로 useEffect를 실행했다. 만약 toggle이 true가 되었다면, [true,0]으로 배열의 내용이 바뀌었으므로 useEffect가 실행된다. 반면, count2가 2로 변해도 배열의 내용은 [false, 0] 그대로이므로 useEffect는 실행되지 않는다.

레퍼런스

• https://github.com/nolimits4web/swiper/issues/3855
• https://ko.reactjs.org/docs/hooks-effect.html
• https://yceffort.kr/2022/04/deep-dive-in-react-rendering

개요(Prismic 프로젝트의 특성)

Prismic은 최대 3000개 이상의 대규모 이미지를 쉽게 카테고라이징할 수 있게 돕는 목적으로 만들어졌다. 그러므로, 3000개 이상의 이미지가 동시에 웹 메모리에 올라와도 애플리케이션이 프리징되지 않아야 할 필요가 있다. 1개의 이미지를 1MB라고 가정하면, 3000개의 이미지는 약 3GB정도 될 것이다. 3GB 정도 되는 파일이 메모리에 올라왔을 때, 브라우저가 프리징되는지 가능성을 알아보기 위해, 간단한 실험을 해 보았다.

실험

실험 1

간단히 3GB짜리 통짜 파일을 업로드했다. 업로드 자체만으로 브라우저가 크래시되는 일은 없었다. 또한, 1000개의 파일을 업로드하여 blob 객체가 1000개 메모리에 있더라도, 브라우저의 메모리가 고갈날 일은 없었다. 따라서, 단순 업로드 자체는 파일의 용량과 상관없이 자바스크립트가 감당할 수 있음을 알았다.

실험 2

function onFileInput(e)
{
  const blob = e.target.files[0];
  if(blob === null) return;
  blob.text().then(e=>console.log(e));
}
document.getElementById("test").addEventListener("change", onFileInput);

500MB짜리 파일을 업로드해서 1초 후에 전문을 텍스트로 읽어오기를 시도하였다. 브라우저가 파일 처리를 시도하다 콘솔이 멈추더니 out of memory로 메모리 부족 오류가 생겼다.

실험 3

function addDom(rawText)
{
  const newElem = document.createElement("p");
  newElem.innerText = rawText.slice(0, 20);
  document.body.appendChild(newElem);
}
function onFileInput(e)
{
  const blobs = e.target.files;
  for(let blob of blobs) {
    blob.text().then(addDom);
  }
}
document.getElementById("test").addEventListener("change", onFileInput);

이번에는 1MB짜리 파일을 1000개 업로드한 뒤, 1000개의 파일의 시작 부분을 dom에 추가하였다. 실험 결과, 여유롭게 실행되는 모습을 볼 수 있었다. 참고로 동일한 실험을 별도의 텍스트 배열에 추가하고, 그 배열의 시작부를 dom에 출력하려고 하면 메모리 오류를 반환한다.

가능성 확인

Prismic의 경우, 3000개의 이미지의 비트맵 정보가 필요한 것이 아닌, 3000개의 이미지의 주소 참조만 blob 데이터로 저장하고, 필요할 때 단 하나의 이미지의 미리보기를 렌더링할 것으로 구현되므로, 메모리 부족 관련 성능 문제는 걱정하지 않아도 될 듯 하다. 따라서, 구현 가능성이 존재한다!

Blob 데이터는 어디에 저장될까?

크롬 개발자 도구로 blob이 메모리 상에 점유되는 용량을 분석하면 매우 작은 용량을 점유하는 것으로 드러난다. blob을 콘솔로 출력해 보아도 그 어디에도 내용은 없다.

let p="";
for(let i=0;i<100000;i++){
    p+=Math.random()*89+10;
}
let blob = new Blob([p]);
p = 123;

이 코드를 실행시키면, 대용량의 문자열이 생성되어 메모리에 저장되었다가(이 때 concanated string이 많이 생성되어 메모리 용량이 치솟다 최종 문자열을 제외한 나머지는 가비지 컬렉션된다.), 블롭화되고 원본 대용량 문자열은 가비지 컬렉션된다. 그런데도 let text = await blob.text(); 와 같은 방식으로 텍스트를 읽어올 수 있으며, 놀랍게도 해당 텍스트는 외부 텍스트로 취급되어 점유하는 메모리는 고작 20byte밖에 되지 않는다.

과연, blob의 내용은 실제로 어디에 저장되어 있으며, 어떻게 blob의 메타데이터만으로 원본 데이터를 읽어올 수 있는 것일까?

크롬 기준으로 blob의 실제 내용은 자바스크립트의 힙이 아닌 별개의 공간에 저장된다. 크롬 자체적으로 blob을 저장하는 메모리가 존재하며, blob이 메모리 이상으로 너무 크거나 blob 메모리의 최대 용량이 전부 차면 디스크에 저장한다.

blob 데이터는 자바스크립트 코드 등에서 참조가 있는지 없는지를 계산하여, 참조가 없으면 가비지 컬렉션을 수행한다. 만약 object url로 blob을 변환했으면, 해당 object url은 blob의 내부 데이터를 “참조”하게 되어 가비지 컬렉션이 일어나지 않는다. 이는 해당 object url 문자열을 더 이상 참조하지 않더라도 blob URL store라는 곳에 내부적으로 저장되므로 가비자 컬렉션이 일어나지 않는다. 브라우저 창이 꺼지면 연결된 blob은 전부 가비지 컬렉션된다.

크롬 기준으로 현재 브라우저 창이 점유하는 실제 blob 오브젝트 데이터의 내역은 chrome://blob-internals/에서 확인할 수 있다.

파일의 경우는 blob 메모리에 실제 데이터 자체를 저장하는 것이 아니라, blob 데이터에 로컬 파일 시스템을 참조하는 경로만 저장된다. 실질적으로 File 객체의 실제 데이터는 파일 경로에 그대로 존재하며, 어딘가로 복사되지는 않는다. 파일을 읽어올 때는 File System API가 blob 메모리에 저장된 파일 경로 포인터를 기반으로 직접 로컬 파일에서 데이터를 읽어온다.

이 때는 네이버 부스트캠프 멤버십이 있었다. 간략하게 말하자면 4번의 스프린트를 진행하면서 도메인 지식을 향상시키고, 그룹 프로젝트로는 Monument Gallery라는 프로젝트를 진행했었다. 간략하게 말하면, Monument Gallery는 사용자 Notion의 포스트 데이터를 불러와서, 키워드 및 사진을 분석해 3D 공간으로 시각화하는 가상공간 프로젝트다. (현재는 서버비 문제로 인해 서비스 종료 상태) Notion API로 사용자의 기록물들을 분석하고, 키워드와 사진 등 데이터를 추출하여, 이를 맵 데이터로 저장한다. 맵 데이터는 트리 구조로 구성되며, 트리 구조의 자료를 용이하게 렌더링할 수 있는 react-three/fiber를 사용하여 3D 공간에 표현하였다. 생성된 기록물들은 공유할 수 있으며, 메인 로비에서 직접 탐방하거나, 링크 공유를 통해 다른 사람이 생성한 기록물을 조회할 수 있다.

Monument Gallery 관련해서 다양한 기술적인 문제들을 마주했는데, 해당 기술적인 문제는 다른 포스트에 작성하겠다.

2023

2023년은 내 대학 생활의 마지막 장이었다. 그런데 뭔가 대외활동이라거나 그런 걸 한 건 아니었고, 그냥 과제의 노예로 살았다. 되새겨 보면 이 때 취업 준비를 더 할 걸 그랬다. 하지만 사람의 몸은 하나다

2023년은 게임 프로젝트 2개와, 사이드 웹 프로젝트 2개, 그리고 해커톤으로 정리할 수 있겠다. 프론트엔드 개발자가 웬 게임을 만드느냐 하겠지만, 사실 원래 나는 게임을 만드는 거에도 관심이 있기도 했고, 졸업 작품으로 그 동안 배운 기술들을 시험해보는 가장 좋은 수단이 게임이라고 생각하기도 했으며, 이 참에 유니티를 더 배워보고자 싶었기 때문이다.

게임 프로젝트

내가 다니는 학과에는 Creative Capstone Project라고 그 동안 배웠거나 관심이 있는 기술을 적극 활용해서, 혼자서 기획, 디자인, 개발을 모두 진행하는 일종의 졸업창작프로젝트 같은 수업이 있다. 아래의 두 프로젝트는 모두 Creative Capstone Project의 일환으로 제작되었다.

Guidance 플레이 링크 1학기에는 Guidance라는 항아리형 퍼즐 액션 게임을 만들었다. '교육 시스템의 실패'를 주제로 하여, 현 교육의 양상을 게임 시스템으로 대표되는 교육 시스템이, 주인공인 선생에게, 학생을 빠르게 졸업으로 인도하라는 게임의 규칙을 제공하는 형태로 표현하였다. 플레이어인 선생은 화면에 보이는 학생에게 화면을 터치하여 '과제'를 주어 학생을 그 쪽으로 이동할 수 있으며, 교육 시스템이 제공하는 시간 제한 이내에 학생을 졸업까지 보내는 것이 목표다.

이 프로젝트는 작년 7월에 GIGDC에 출품했으며(상은 못 탔다), 작년 12월 교내 전시회에 출품하여 실제 플레이어의 반응을 보기도 했다. 그 과정에서 게임 디자인적으로 개선이 필요한 부분이 몇몇 보여서, 그 부분을 2월에 수정하여 개선할 계획이다. Guidance 관련된 이야기는 아마 Guidance를 추가로 개발할 때 더 풀어나갈 예정이다.

Fluctus of Deliberation 플레이 링크 2학기에는 Fluctus of Deliberation이라는 아케이드 게임을 만들었다. Guidance에서 다뤘던 '교육 시스템의 실패'와 '숙고'의 연장선으로, 인간이 생각하는 과정에서 영감을 얻은 아케이드 게임이다. 주인공은 탐사정 로봇인 '뉴로비'(사진의 노란색 로봇)을 조작하여, 밑에서부터 올라오는 생각 방울을 연속해서 잡으면서 버티면서 맨 밑으로 내려가야 한다. 단순한 게임이지만, 검증된 장르의 특성상 의외로 재미가 있었으며, 특히 방울을 잡으면 대시하는 조작감이 인상적이다.

이 프로젝트는 Creative Capstone Project 2에서 A+이라는 성적을 받았다.

개인 프로젝트

Prismic 링크 마지막 학기에 2개의 프로젝트를 진행했었다. 그 중 하나는 Prismic이라는 이름의 이미지 분류기이다. 사실 이 프로젝트는 본인이 직접 사용하기 위해 만들었는데, 그 당시 인공지능 이미지 학습에 빠져 있던 나는 학습할 데이터를 손수 이미지 뷰어를 보면서 분류하는 것에 지쳐 있었고, 어떻게 하면 더 편하게 이미지를 보면서 분류를 쉽게 할지를 고민하다 만들게 되었다.

이 프로젝트는 여러 이미지 파일들을 업로드하고, 분류할 카테고리를 입력한 뒤 미리보기 이미지를 보면서 이미지를 분류해나간다. 전부 분류가 완료되었으면 완료된 이미지는 폴더로 나뉘어져 압축 파일로 다운로드할 수 있다.

간단해 보이지만, 의외로 생각할 거리들이 정말 많았던 사이드 프로젝트였다. 당장 생각나는 것들만 나열해 보아도 다음과 같다.

• 프로젝트 특성상 대규모의 이미지 파일(최대 1000개 이상)을 처리해야 하는데, 업로드하고 다운로드하는 데 메모리가 바닥나지는 않는가?
• 모바일에서 스크롤을 내리거나 올릴 때 레이아웃이 변경되는 애니메이션을 처리해야 한다. 어떻게 하면 잦은 리렌더링으로 인한 성능저하 없이 애니메이션을 구현할 수 있는가?
• 디렉토리 버튼을 클릭하면 카테고리로 분류된 이미지 미리보기 목록이 표시되어야 한다. 프로젝트 특성상 컴포넌트가 너무 많으면 렌더링 속도가 저하되는데, 어떻게 해결할 수 있는가?
• 가상 리스트로 위의 문제를 해결하였다. 그런데 이미지 캐싱이 안 되어서 스크롤할 때마다 이미지를 다시 불러오는 상황. 어떻게 해결해야 하는가?

Prismic을 개발하면서 봉착한 기술적인 문제들이 꽤 많아서, 개발하면서 따로 개인 Notion 페이지에 정리해 두었다. 해당 이야기들은 차후 다른 포스트에서 공개적으로 풀어나갈 예정이다.

(이 프로젝트는 사용성 개선 등 아직 개선이 더 필요한 프로젝트라 공개하지는 않고 있다) 다음 프로젝트는 다른 사람이 만든 코어 키퍼 픽셀 맵 아트 툴을 리메이크하는 프로젝트였다. 기존 맵 아트 툴은 예전의 데이터에서 멈춰 있었으며, 사용성에서 문제가 많아서 개선하기로 결심했다. 처음에는 기존 프로젝트를 약간 손보고 기능을 추가하는 것에서 끝내려고 했으나, 코드에 새로운 기능을 추가하기에는 기존 코드에 문제가 많았기에 아예 기존 코드의 로직만 분석한 뒤 새로 만들기로 했다.

원래 프로젝트가 바닐라 자바스크립트였고, 상당히 간단한 프로젝트였기에 굳이 리액트처럼 무거운 웹 프레임워크(리액트는 라이브러리지만)를 쓸 필요는 없다고 판단하였고, 경량화되고 속도도 빠르며 다른 웹 프레임워크에 부착할 수도 있는 lit을 사용해서 개발하였다. 특이한 기술적인 경험을 한 것은 아니었으나, 원본 프로젝트의 로직을 이해해야 가능한 프로젝트였기에, 코드를 읽는 능력을 많이 요구하는 프로젝트였다. 실제 현업에서는 다른 사람이나 전업자의 코드를 읽는 능력이 필요할 것이라고 예상되기에, 해당 부분을 어필할 수 있을 것 같다.

Core Keeper Pixel Map Art Tool 개발하면서 봉착한 기술적 문제는 향후 다른 포스트에서 풀어나갈 예정이다. 이것도 노션에 초안을 작성해두었다.

해커톤

11월에는 '구름톤 대학'이라는 이름의 연합동아리에 소속하여, '단풍톤' 해커톤에 참여하였다. 개인적으로나, 팀적으로나 결코 좋은 성적을 거두지는 못했던 프로젝트였으나, 본격적으로 기획자, 디자이너, 백엔드 개발자와 역할을 분담하여 진행한 프로젝트라는 점에서 의의가 있었다.(마지막 스프린트에서 디자이너와 호흡이 아주 잘 맞았다)

무슨 아이디어로 나갔는지는 비밀로 하겠다. 기술적인 문제에 도전할 수 있는 아이디어가 아니었으며, 실제로도 기술적인 고민을 하지 못했다는 점은 아쉬웠다.

2024년, 무엇을 할 것인가?

우선 거의 방치 수준으로 이루어진 개발 블로그를 천천히 채워나갈 계획이며, 추가적으로 새 프로젝트의 아이디어가 생각나기 전까지는 2022년~2023년에 개발했던 프로젝트들의 유지보수 및 업데이트를 진행할 예정이다.

요새 채용시장이 불황이라고 한다. 너무 슬프다. 그래도 취업에 도전해야만 한다. 지금까지는 준비와 준비와 준비의 기간이었으니, 이제는 도전해야 할 시기다.

현재 Stardew Dressup 1.1버전을 개발하고 있다. 주된 변경 내역은 디자인 수정으로, 픽셀스럽고 다듬어진 디자인으로 변경하면서, 겸사겸사 성능을 향상시키는 것이 주 목적이다.

개발 예정 목록은 다음과 같다.

• 랜더마이징 기능 추가
• 버그 수정
  • 모바일에서 한글 폰트가 굵게 나오는 버그 수정
  • 모바일에서 하단이 짤려 나오는 버그 수정
• 사용성 개선
  • 의상 선택 창 퍼포먼스 개선
  • 리사이징 퍼포먼스 개선
  • 모바일에서 스와이프를 할 때 하단이 스와이프가 안 되는 문제 수정
  • 의상 선택 창 동기화 퍼포먼스 개선
• 디자인 변경
• 일부 코드 리팩토링

문제 상황

Swiper.js의 페이지네이션 태그 분리

Stardew Dressup은 스와이프 기능을 구현하기 위해 Swiper.js 라이브러리를 사용하고 있다.(리액트, 앵귤러, 뷰 등 다른 SPA 라이브러리/프레임워크용 버전을 지원한다) 리액트의 Swiper.js(swiper-react)는 기본적으로 스와이퍼 컴포넌트를 생성할 때 pagination 엘리먼트를 같이 생성하는데, 이것을 다른 태그에 소속되도록 분리할 수 있다.

import {useState, useRef, useEffect} from "react";
import {Pagination} from "swiper";
import {Swiper} from "swiper/react";

// from https://github.com/nolimits4web/swiper/issues/3855
function UseSwiperRef()
{
  const [el, setEl] = useState(null);
  const elRef = useRef(null);
  useEffect( ()=>{
    selEl(elRef.current);
  }, []);
  return [el, elRef];
}
function MySwiper()
{
  const [el, elRef] = UseSwiperRef();
  return <>
    <Swiper
      pagination={el:el}
      module={[Pagination]}
    >
        <SwiperSlide>123</SwiperSlide>
    </Swiper>
      <div className="mySwiperPagination" ref={elRef} />
  </>
}

참고 : UseSwiperRef를 사용한 이유는 Swiper 컴포넌트 이후에 존재하는 컴포넌트에 ref를 부착하면 Swiper 컴포넌트가 평가될 때 ref는 아직 아무 컴포넌트에도 부착되지 않은 상태이므로 {current:null}로 평가된다. 따라서 useState와 useEffect를 사용하여 컴포넌트가 생성 완료된 후 ref.current를 state로 넣어서 리렌더링을 시도하도록 하였다.

Swiper.js braekpoints

Swiper.js에서는 breakpoints라는 기능을 제공한다. breakpoints는 window나 현재 스와이퍼 컨테이너의 가로 길이나 해상도 비율에 맞춰 스와이퍼가 다르게 동작하도록 하는 기능이다. 숫자를 키값으로 적으면 가로 길이 기준으로, @로 시작하는 문자를 키값으로 적으면 해상도 기준으로 동작한다. 리액트에서 Swiper.js의 breakpoints를 사용하는 법은 다음과 같다.

function MySwiper()
{
  return <>
    <Swiper
        slidesPerView:{2},
      spaceBetween:{10},
      breakpoints:{
        // when window width is >= 768px
        768: {
          slidesPerView: 3,
          spaceBetween: 20
        },
        // when window width is >= 1366px
        1366: {
          slidesPerView: 5,
          spaceBetween: 30
        }
      }
    >
        <SwiperSlide>123</SwiperSlide>
    </Swiper>
  </>
}

위의 코드는 기본적으로 2개의 보이는 슬라이드와 10px의 갭으로 스와이퍼가 동작하지만, 창 크기가 768px 이상일 때는 3개의 보이는 슬라이드와 20px의 갭으로, 1366px 이상일 때는 5개의 보이는 슬라이드와 30px의 갭으로 동작한다.

breakpoints 버그

문제는 위와 같이 ref를 이용해서 pagination을 다른 태그로 분리하고, breakpoints를 사용했을 때, 창이 가장 작은 breakpoints 미만으로 줄어들었을 때(위의 예시에서는 768px 이상이었다가 768px 미만으로 줄어드는 상황) pagination.el이 null로 초기화되어버리는 버그가 일어난다는 것이다.

나는 1366px 이상일 때는 스와이퍼가 세로로, 1366px 미만일 때는 스와이퍼가 가로로 동작하도록 만들고, 1366px 미만일 때 페이지네이션의 현재 페이지가 하이라이트되도록 만들었는데, 1366px 이상이었다가 창이 1366px 미만으로 줄어들었을 때 페이지네이션의 하이라이트가 동작하지 않았던 것이다. 디버깅을 해 보니 swiper.params.pagination.el이 null로 변경되어 있어서 pagination의 update가 아예 동작하지 않았다.

function isPaginationDisabled() {
  return !swiper.params.pagination.el || !swiper.pagination.el || !swiper.pagination.$el || swiper.pagination.$el.length === 0;
}

function update() {
  // Render || Update Pagination bullets/items
  const rtl = swiper.rtl;
  const params = swiper.params.pagination;
  if (isPaginationDisabled()) return;
  //...
}

(Swiper.js 라이브러리의 modules/pagination 코드의 일부.)

Swiper.js의 breakpoints 동작원리

setBreakPoint

Swiper.js는 화면 크기가 변경되면, breakpoints를 param으로 갖고 있는 Swiper 객체에 대해, setBreakPoint라는 함수를 호출한다. setBreakPoint는 현재 스와이퍼 객체에 대해 해당하는 breakpoint를 구하고, 해당 breakpoints에 대해 현재 파라미터와 해당하는 breakpoints의 파라미터를 덮어씌운다.

function setBreakpoint() {
  const swiper = this;
  const {
    activeIndex,
    initialized,
    loopedSlides = 0,
    params,
    $el
  } = swiper;
  const breakpoints = params.breakpoints;
  if (!breakpoints || breakpoints && Object.keys(breakpoints).length === 0) return; // Get breakpoint for window width and update parameters

  const breakpoint = swiper.getBreakpoint(breakpoints, swiper.params.breakpointsBase, swiper.el);
  if (!breakpoint || swiper.currentBreakpoint === breakpoint) return;
  const breakpointOnlyParams = breakpoint in breakpoints ? breakpoints[breakpoint] : undefined;
  const breakpointParams = breakpointOnlyParams || swiper.originalParams;
  //중략
  extend(swiper.params, breakpointParams);
  //후략
}

(Swiper.js 라이브러리의 core/breakpoints/setBreakPoint.js 코드의 일부.) 여기서 extend 함수는 {...swiper.params, ...breakpointParams}의 깊은 복사 버전이라고 생각하면 되겠다.

getBreakPoint

현재 스와이퍼 객체의 breakpoint가 무엇인지를 구하는 함수다. getBreakPoint의 알고리즘을 간단하게 말로 풀어서 설명하면 다음과 같다.

0. 아래 내용은 base가 window 기반일 때를 기준으로 한다.
1. Swiper 객체가 현재 갖고 있는 breakpoints 객체의 키값에 대해 매핑을 하여 points 변수에 저장한다.
   • 각 breakpoint가 @로 시작하는 문자열일 경우, height * 비율을 breakpoint width로 정한다.
   • 그렇지 않을 경우 자기 자신을 breakpoint width로 정한다.
2. points 배열을 작은 순으로 정렬한다.
3. points 배열을 순회하여 각 원소에 대해 현재 window.width가 breakpoint width보다 크면 해당 key를 breakpoint로 정한다. 즉, 현재 window.width보다 작은 breakpoint width들 중 가장 큰 것이 결과값이 된다.
4. 아무 조건도 일치하지 않는 경우 결과값은 "Max"가 된다.

예를 들어 breakpoints의 키값이 [768, 1366]이라고 하자. 창 크기가 1920일 때, 첫 번째 루프에서 768이 조건에 맞고, 두 번째 루프에서 1366이 조건에 맞으므로 결과값은 1366이 된다. 반면 창 크기가 320일 경우는 첫 번째 루프에서 768이 조건에 맞지 않고, 두 번째 루프에서 1366이 조건에 맞지 않으므로 결과값은 "Max"가 된다.

Breakpoint가 현재 창 너비보다 작은 지점 중 가장 큰 것, 즉 창 너비가 소속된 범위를 의미하므로 창 너비가 어떤 breakpoint보다도 작으면 결과값이 Min이 되어야 하는데 Max이다. 왜일까

버그 원인 해결

breakpoints가 제일 작은 쪽으로 화면이 줄어들었을 때는 다음의 현상이 일어난다.

1. 화면 크기가 변경되면 setBreakPoint 함수가 호출된다.
2. setBreakPoint 함수에서 getBreakPoint 함수를 호출한다.
3. getBreakPoint 함수는 현재 window의 너비가 어떠한 breakpoints보다도 작으므로 "Max"를 반환한다.
4. breakpoints 객체에서 getBreakPoint의 리턴값이 key값인 value를 찾는다.(this.breakpoints[this.getBreakPoint()]와 같다.)
5. 해당 키값이 breakpoints 파라미터에 존재하면 이를 breakpointParams으로 삼는다. 존재하지 않으면 originalParams 파라미터를 breakpointParams으로 삼는다.
6. 스와이퍼의 현재 params에 breakpointParams를 덮어씌운다.

즉, getBreakPoint가 Max를 반환하는 상황(화면의 너비보다 작은 breakpoints가 없음)에서 breakpoints 객체에 Max라는 키값이 존재하지 않으니, Swiper 객체를 처음 초기화했을 때의 파라미터로 덮어씌우는 상황이라고 할 수 있다.

여기서 문제는 Swiper의 페이지네이션을 분리하기 위해 pagination.el에 state를 할당하는 과정에서 나온다. 맨 처음 el state는 null이기 때문에 originalParams.pagination.el이 null이 되어버린 것이다.

해당 문제는 breakpoints 파라미터 객체에 Max 프로퍼티를 추가하여, breakpoints로 변경되는 부분만 초기화하면 해결된다.

function MySwiper()
{
  const [el, elRef] = UseSwiperRef();
  return <>
    <Swiper
        slidesPerView:{2}
      spaceBetween:{10}
      breakpoints:{
        // when window width is >= 768px
        768: {
          slidesPerView: 3,
          spaceBetween: 20
        },
        // when window width is >= 1366px
        1366: {
          slidesPerView: 5,
          spaceBetween: 30
        }
        // default(when window width is < 768px)
        Max: {
          slidesPerView: 2,
          spaceBetween: 10
        }
      }
        pagination={el}
      module={[Pagination]}
    >
        <SwiperSlide>123</SwiperSlide>
    </Swiper>
      <div className="mySwiperPagination" ref={elRef} />
  </>
}

이렇게 하면 pagination.el 파라미터가 null로 초기화되지 않는다!

(출처 : https://dev.to/coderslang/javascript-interview-question-34-different-ways-to-get-the-current-date-in-js-4c25)

우선 시작하기 전에 위 사진의 문제를 풀어보자. 답은 true일까, false일까? 답은 이 글 맨 마지막에 알려주겠다.

명시적 형변환과 암시적 형변환

자바스크립트는 약타입 언어다. 그래서 "123" + 4 같은 것을 처리할 때 다른 강타입 언어는 타입이 달라서 오류를 뱉겠지만, 자바스크립트는 어떻게든 형변환해서 처리한다. 이 때, 프로그래머가 명시적으로 값의 타입을 변환시키면(Number(123) 같은 경우) 명시적 형변환이라고 하고, 그렇지 않고 자바스크립트 엔진이 알아서 형변환하도록 하는 것을 암시적 형변환이라고 한다.

원시 자료형의 형변환

원시 자료형에는 Number, String, Boolean, null, undefined, Symbol(ES6부터), BigInt(ES2020부터)가 존재한다. 이 중 가장 많이 쓰이고 많이 변환되는 문자열, 숫자, 불리언 자료형으로의 형변환에 대해 알아보자.

toString(문자열 형변환)

"Lybell".concat(123)은 무엇을 반환해야 할까? 문자열에 숫자나 불리언 등을 결합하고 싶을 때 등의 상황에서, 자바스크립트는 암묵적으로 문자열이 아닌 자료형을 문자열로 형변환하는 toString 추상 연산을 호출한다.

ECMAScript 명세서에서 정의하고 있는 각 자료형의 문자열 형변환 규칙은 다음과 같다.

명시적으로 문자열로 형변환을 하기 위해서는 템플릿 리터럴을 사용하거나, String() 함수를 이용하면 된다.(new String()을 사용하면 문자열처럼 보이는 객체가 생성되므로 주의!) value+""와 같은 방법도 존재하나, preferedType이 string이 아니라 default이고, 객체를 형변환할 때 valueOf나 @@Symbol.toPrimitive 메소드가 다른 리터럴을 반환한다면 그것을 기준으로 문자열로 형변환되기 때문에 원하는 값을 얻지 못할 수 있다.

//String() 함수
console.log(String(123)) // 문자열 123
console.log(String(true)) // 문자열 "true"

//템플릿 리터럴
console.log(`${123}`) // 문자열 "123"
console.log(`${10000000000n}`) // 문자열 "10000000000"
console.log(`${undefined}`) // 문자열 "undefined"
console.log(`${null}`) // 문자열 "null"
console.log(`${Symbol()}`) // TypeError
console.log(`${[1,2,3]}`) // 문자열 "1,2,3"
console.log(`${{a:12}}`) // 문자열 "[Object Object]"

//value+""로 문자열 이어붙이기
console.log(123+""); // 문자열 "123"
console.log(null+""); // 문자열 "null"

//객체의 경우
const test = {valueOf:()=>300, toString:()=>"yes"};
console.log(`${test}`); // 문자열 "yes"
console.log(String(test)); // 문자열 "yes"
console.log(test+""); // 문자열 "300"?!

toNumber(숫자 형변환)

123 - "45"는 무엇을 반환해야 할까? 숫자와 숫자가 아닌 것을 연산하거나 비교해야 할 때, 자바스크립트는 암묵적으로 숫자가 아닌 것을 숫자로 형변환하는 toNumber 추상 연산을 호출한다.

ECMAScript 명세서에서 정의하고 있는 각 자료형의 숫자형 형변환 규칙은 다음과 같다.

문자열이 숫자로 형변환될 때 적절하지 않은 포맷(예시:123a)이면 NaN을 반환하며, 공백만 있는 문자열이 0을 반환한다는 것을 기억하도록 하자.

여기에서 빈 배열이 0으로 형변환되는 이유를 알 수 있는데, 빈 배열은 toPrimitive(value, "number")를 호출하면 [].toString()의 값인 빈 문자열("")이 원시 자료형으로 반환되고, 이것을 숫자형으로 파싱하면 0이 되기 때문에 빈 배열이 0으로 초기화되는 것이다.

명시적으로 숫자형으로 형변환을 하기 위해서는 Number() 함수를 사용하거나, unary plus 연산자를 이용하면 된다. 단, Number() 함수는 BigInt형의 값 역시 잘 변환할 수 있기 때문에, 완벽한 toNumber는 아니다.

//Number() 함수
console.log(Number("123")) // 숫자 123
console.log(Number("123.45")) // 숫자 123.45
console.log(Number("123p")) // NaN
console.log(Number(" ")) // 숫자 0
console.log(Number(1234n)) // 숫자 1234

//unary plus 연산자
console.log(+"1024") // 숫자 1024
console.log(+undefined) // NaN
console.log(+null) // 숫자 0
console.log(+Symbol()) // TypeError
console.log(+1024n) // TypeError
console.log(+true) // 숫자 1
console.log(+[]) // 숫자 0
console.log(+[1,2,3]) // NaN
console.log(+{}); // NaN

//객체의 경우
const test = {valueOf:()=>300, toString:()=>"yes"};
console.log(+test); // 숫자 300
const test2 = {toString:()=>""};
console.log(+test2); // 숫자 0

toNumeric

내부 연산 toNumber와 비슷하지만, toNumeric은 원시 자료형으로 만든 뒤 그 값이 BigInt형이면 BigInt형 값 그 자체를 반환한다.

toBoolean(불리언 형변환)

조건문에서 true나 false가 아닌 것이 들어갔을 때 어떻게 처리해야 할까? 조건문 등 불리언 값이 필요한 상황에서 불리언 값이 아닌 값이 들어갔을 때, 자바스크립트는 암묵적으로 불리언 자료형이 아닌 것을 불리언 값으로 형변환하는 toNumber 추상 연산을 호출한다.

ECMAScript 명세서에서 정의하고 있는 각 자료형의 불리언 형변환 규칙은 다음과 같다.

Object는 빈 배열이든, 빈 객체든, 심지어 new Boolean(false)와 같은 값이 false인 불리언 래퍼 객체든 무조건 true로 형변환된다는 사실에 유의하자.

명시적으로 불리언으로 형변환을 하기 위해서는 Boolean() 함수를 사용하거나, !! 연산자를 이용하면 된다. !! 연산자는 !으로 값을 형변환한 뒤 불리언 값을 뒤집고, 다시 !을 붙이면 그 값이 뒤집어져 최종적으로 값이 불리언으로 형변환되는 원리다.

//Boolean() 함수
console.log(Boolean(123)) // true
console.log(Boolean(0)) // false
console.log(Boolean(NaN)) // false
console.log(Boolean(" ")) // true

//!! 연산자
console.log(!!123) // true
console.log(!!"yes") // true
console.log(!!" ") // true
console.log(!!"") // false
console.log(!!Symbol()) // true
console.log(!!1024n) // true
console.log(!!null) // false
console.log(!!undefined) // false
console.log(!![]) // true
console.log(!!{}) // true
console.log(!!(new Boolean(false)) )// true

Object의 형변환

Object 자료형은 원시 자료형으로 변환하기 위해 특수한 형변환 과정을 거친다. ECMAScript 명세서에서 정의하고 있는 Object의 원시 자료형 형변환은 다음과 같다. 이해를 돕기 위해 자바스크립트로 짠 toPrimitive 함수를 같이 첨부한다.

function isPrimitive(object)
{
  if(object === null) return true;
  return (typeof object !== "object" && typeof object !== "function");
}
function assertHint(preferedType)
{
  if(preferedType === undefined) return "default";
  if(preferedType === "string") return "string";
  return "number";
}

function toPrimitive(object, preferedType)
{
  if(isPrimitive(object)) return object;
  if(Symbol.toPrimitive in object)
  {
    let hint = assertHint(preferedType);
    let primitive = object[Symbol.toPrimitive](hint);
    if(isPrimitive(primitive)) return primitive;
    throw new TypeError("Cannot convert object to primitive value");
  }
  return toOrdinaryPrimitive(object, preferedType);
}

function toOrdinaryPrimitive(object, hint="number")
{
  let methodNames;
  if(hint === "string") methodNames=["toString", "valueOf"];
  else methodNames=["valueOf", "toString"];
  for(let name of methodNames)
  {
    if(!(name in object)) continue;
    if(typeof object[name] !== "function") continue;
    let primitive = object[name]();
    if(isPrimitive(primitive)) return primitive;
  }
  throw new TypeError("Cannot convert object to primitive value");
}

0. 만약 원시 자료형이면 값을 그대로 반환한다.

1. @@Symbol.toPrimitive 메소드의 존재 여부를 파악한다.
2. 만약 @@Symbol.toPrimitive 메소드가 존재하면, preferedType을 통해 hint를 추측한다.
   • preferedType이 정해지지 않으면 기본적으로 default
   • preferedType이 string이면 string
   • 그 외에는 number
3. 만약 @@Symbol.toPrimitive 메소드가 존재하면, [Symbol.toPrimitive](hint) 메소드를 호출한다. 그 값이 원시 자료형이면 값을 반환하고, 그렇지 않으면 오류를 반환한다.
4. valueOf와 toString을 기반으로 형변환을 진행한다. 이 때 preferedType이 무엇인지에 따라 다르다.
   • preferedType이 string이면 toString, valueOf 우선
   • 그 외에는 valueOf, toString 우선
5. 각 methodName에 대해 형변환을 진행한다. 이 때 해당하는 메소드가 존재하지 않거나, 해당하는 식별자가 메소드가 아니면 건너뛴다. 반환값이 원시 자료형이면 값을 반환한다.
6. 만약 @@Symbol.toPrimitive, toString, valueOf 모두 존재하지 않으면 Uncaught TypeError: Cannot convert object to primitive value 에러를 반환한다.

@@Symbol.toPrimitive

Symbol.toPrimitive 심볼은 ES6부터 추가된 원시 자료 형변환 메소드로, valueOf와 toString보다 우선된다. valueOf나 toString과는 다르게 Object.prototype에는 @@Symbol.toPrimitive 메소드가 정의되어 있지 않다.

@@Symbol.toPrimitive 메소드는 하나의 매개변수를 가지며, 그 인자의 값은 반드시 "string", "number", "default" 중 하나가 와야 한다. 리턴값은 반드시 원시 자료형이어야 하고, 위에서 보았듯이 객체 자료형이면 에러가 뜬다. 사용자가 이 메소드를 정의하고자 한다면 hint값에 따라 값이 달라지는 구조로 코드를 작성해야 한다.

다음의 예제를 보자.

let example = {
  [Symbol.toPrimitive](hint){
    if(hint === "number") return 123;
    if(hint === "string") return '456';
    return 789;
  }
}
console.log(+example); // unary plus는 preferType이 number이므로 123이 반환됨
console.log(example*1); // -, * /, %는 preferType이 number이므로 123이 반환됨

console.log(`${example}`); // 템플릿 문자열은 preferType이 string이므로 '456'이 반환됨
console.log("".concat(example)); 
// 문자열의 concat 메소드는 preferType이 string이므로 '456'이 반환됨

console.log(0 + example); // + 연산자는 preferType이 default이므로 789가 반환됨
console.log(789 == example); // == 연산자는 preferType이 default이므로 789가 반환됨

valueOf

valueOf 메소드는 원시 자료 형변환 메소드로, 원시 자료형을 반환하는 데에 쓰인다. 객체도 반환할 수 있으나, 객체가 반환되면 암시적 형변환에서 무시된다. 많은 사람들이 valueOf는 숫자만 반환할 수 있다고 오해하지만, 그렇지 않다. 객체를 대표할 수 있는 원시 자료형이면 뭐든지 반환할 수 있다.(그래도 숫자를 반환하는 것이 권장된다.)

기본적으로 Object.prototype에는 valueOf 메소드가 정의되어 있으며, 그 값은 자기 자신을 반환한다. 그래서 일반적인 객체는 toString을 기반으로 원시 자료형으로 변경되게 된다. Date 객체의 valueOf 메소드는 1970년 1월 1일 0시 0분 0.0초부터 지금까지 걸린 시간을 숫자형으로 반환한다.

객체를 대표하는 숫자같은 것을 반환한다는 점에서 unary plus 연산자와도 비슷함을 느낄 수 있으나, unary plus 연산자가 평가될 때 valueOf 메소드가 toString보다 우선될 뿐 대체가 불가능하다.

toString

toString 메소드는 원시 문자열 형변환 메소드로, 객체를 대표하는 문자열을 반환하는 데에 쓰인다. 사실 toString 역시 문자열이 아는 것들이 반환될 수 있으나, 웬만해서는 문자열을 반환해야 한다.

기본적으로 Object.prototype에는 toString 메소드가 정의되어 있으며, 그 값의 결정 방식은 다음과 같다.

1. caller가 undefined이면 [Object Undefined]를 반환한다.
2. caller가 null이면 [Object Null]을 반환한다.
3. caller가 원시 자료형이면 이를 래퍼 객체로 변환한다.
4. builtinTag를 결정한다. 결정 방식은 다음과 같다.
   • caller.isArray() === true이면 Array
   • caller가 [[ParameterMap]] 내부 슬롯이 있으면(=argument 객체) Arguments
   • caller가 [[Call]] 내부 메소드가 있으면(=함수) Function
   • caller가 [[ErrorData]] 내부 슬롯이 있으면(=Error 객체) Error
   • caller가 [[BooleanData]] 내부 슬롯이 있으면(=불리언) Boolean
   • caller가 [[NumberData]] 내부 슬롯이 있으면(=숫자형) Number
   • caller가 [[StringData]] 내부 슬롯이 있으면(=문자열) String
   • caller가 [[DateValue]] 내부 슬롯이 있으면(=Date 객체) Date
   • caller가 [[RegExpMatcher]] 내부 슬롯이 있으면(=정규 표현식) RegExp
   • 그 외의 경우 Object
5. caller에 @@Symbol.toStringTag 프로퍼티가 존재하고, 그것이 문자열인지 확인한다. 만약 그렇다면 tag는 caller[Symbol.toStringTag]로 정해지고, 그렇지 않으면 builtinTag로 결정된다.
6. 문자열 [Object (tag)]를 반환한다.

ES6부터 추가된 Map, Set, Promise 등의 객체는 각 객체의 프로토타입에 @@Symbol.toStringTag가 설정되어 있으므로, 따로 빌트인 태그 결정 방식을 변경하지 않아도 무방하다.

Function.prototype과 Array.prototype에는 별도의 toString 메소드가 오버라이딩되어 있으며, Object.prototype.toString의 로직을 따르지 않는다. 대신, 다음과 같이 call 메소드를 사용함으로써 Object.prototype.toString의 로직을 따르게 변경할 수 있다.

console.log(String(function(a,b){return a+b})); // "function(a,b){return a+b})"
console.log(String([1,2,3])) // "1,2,3"
console.log(Object.prototype.toString.call([1,2,3])) // "[Object Array]"

각 연산별 형변환 규칙

산술 연산자, 비트 연산자(+ 제외)

산술 연산자(-, *, /, %, **)와 비트 연산자(|, &, ^, <<, >>, >>>)는 추상 연산으로 ApplyStringOrNumericBinaryOperator라는 연산을 이용하여 값을 계산한다. 값을 계산할 때에는 기본적으로 숫자형/BigInt형으로 변환되며, 객체를 원시 자료형으로 변환할 때 preferType은 number로 정해진다.(@@Symbol.toPrimitive("number"), valueOf, toString 순으로 우선순위를 가짐)

ECMAScript 명세서에서 정의하고 있는 산술 연산자의 알고리즘은 다음과 같다. 이해를 돕기 위해 자바스크립트로 짠 binaryOperator 함수를 같이 첨부한다.

function toNumeric(value)
{
  const numeric = toPrimitive(value, "number");
  if(typeof numeric === "bigint") return numeric;
  return +numeric;
}
function binaryOperator(lval, operator, rval)
{
  const lnum = toNumeric(lval);
  const rnum = toNumeric(rval);
  if(typeof lnum !== typeof rnum) {
  throw new TypeError("Cannot mix BigInt and other types, use explicit conversions");
  }
  if(typeof lnum === "bigint") return bigIntOperator(lnum, operator, rnum);
  return numberOperator(lnum, operator, rnum);
}

1. 좌항과 우항에 각각 toNumeric 추상 연산을 적용하여 숫자형/bigInt형으로 만든다.

• 이때 각 항이 객체이면 preferType을 number로 설정하여 원시 자료형으로 변환한다.
  2. 만약 좌항과 우항이 다른 타입이면 TypeError를 반환한다.
  3. 연산자를 기반으로 좌항과 우항을 연산한다. 연산자에 대한 설명은 생략한다.

산술 연산자 +

산술 연산자 중 + 연산자는 문자열 연결 연산자의 역할로도 사용할 수 있기 때문에, 다른 산술 연산자와는 다른 양상을 띈다. 그것은 객체를 원시 자료형으로 변경할 때 preferType이 default로 정해진다는 것이다. 즉, 객체에 @@Symbol.toPrimitive가 존재하면 인자로 "default"가 들어간 값이 출력된다.

ECMAScript 명세서에서 정의하고 있는 + 연산자의 알고리즘은 다음과 같다. 이해를 돕기 위해 자바스크립트로 짠 plusOperator 함수를 같이 첨부한다.

function plusOperator(lval, rval)
{
  const leftPrim = toPrimitive(lval); // preferType default
  const rightPrim = toPrimitive(rval);
  if(typeof leftPrim === "string" || typeof rightPrim === "string") {
    const leftStr = toString(leftPrim);
    const rightStr = toString(rightPrim);
    return leftStr.concat(rightStr);
  }
  return binaryOperator(leftPrim, "+", rightPrim);
}

1. 좌항과 우항에 각각 toPrimitive 추상 연산을 적용하여 원시 자료형으로 만든다.
   • 이때 각 항이 객체이면 preferType을 default로 설정하여 원시 자료형으로 변환한다.
2. 만약 원시 자료형으로 변한 좌항 또는 우항의 타입이 문자열이면,
   1. 변환된 원시 자료형 값들을 문자열로 형변환한다.
   2. 좌항에 우항을 연결한 문자열을 반환한다.
3. 그렇지 않으면, 일반적인 산술 연산자의 알고리즘을 따른다. 이때 실질적으로 계산하는 값으로 취급되는 것은 preferType이 default로 설정된 원시 자료형이지, preferType이 number로 취급되는 것이 아님에 주의하자.

비교 연산자(부등호)

ECMAScript 명세서에서 비교 연산자는 특이하게 정의된다. 모두 같은 기본 추상 연산인 IsLessThan(left, right, leftFirst)를 사용하기 때문에, 순서와 최종 리턴값이 달라진다. 그 표는 다음과 같다.

isLessThan에 세 번째 연산자로 left가 right보다 실제로 더 왼쪽에 있는가를 표시하는데, 그 이유는 자바스크립트는 왼쪽에서 오른쪽으로 값을 평가하고, 형변환 과정에서 생기는 잠재적인 부수 효과가 왼쪽에서 오른쪽으로 평가되는 것처럼 보이게 하기 위해서이다.(객체의 원시 자료형 변환은 함수를 통해 이루어지기 때문에, 해당 함수에 부수효과가 존재하면 원시 자료형 변환에 부수효과가 존재한다.)

ECMAScript 명세서에서 정의하고 있는 비교 연산자의 형변환 과정은 다음과 같다. 이해를 돕기 위해 자바스크립트로 작성한, a<b인 상황을 기준으로 한 isLessThen(left, right)의 코드를 같이 첨부한다.

function _BigInt(value)
{
  try {
    return BigInt(value);
  }
  catch {
    return undefined;
  }
}
function oneIsBigInt_and_OtherIsString(left, right)
{
  if(typeof left === "string" && typeof right === "string") return true;
  if(typeof left === "bigint" && typeof right === "string") return true;
  return false;
}
// 문자열 비교 함수
function stringIsLessThen(left, right)
{
  const leftLength = left.length;
  const rightLength = right.length;
  for(let i=0; i<Math.min(leftLength, rightLength); i++)
  {
    const leftChar = left.charCodeAt(i);
    const rightChar = right.charCodeAt(i);
    if(leftChar < rightChar) return true;
    if(leftChar > rightChar) return false;
  }
  return leftLength < rightLength;
}
// 숫자형 비교 함수
function numberIsLessThen(left, right)
{
  if(Number.isNaN(left) || Number.isNaN(right)) return undefined;
  if(left === +0 && right === -0) return false;
  if(left === -0 && right === +0) return true;
  if(left === Infinity || right === -Infinity) return false;
  if(left === -Infinity || right === Infinity) return true;
  return left < right;
}

function _isLessThen(left, right)
{
  //좌우항을 원시 자료형으로 변환. 
  /*
  실제 자바스크립트에서는 a<b뿐만 아니라 a>b 같은 것도 IsLessThan 추상 연산을 쓰기 때문에, 
  isLessThen(b,a) 같은 것은 right를 먼저 원시 자료형으로 변경시킴으로써 
  부수효과의 순서를 맞출 필요가 있다.
  */
  const leftPrim = toPrimitive(left, "number");
  const rightPrim = toPrimitive(right, "number");

  //원시 좌우항이 모두 문자열이면 문자열 비교 수행
  if(typeof leftPrim === "string" && typeof rightPrim === "string") {
     return stringIsLessThen(leftPrim, rightPrim);
  }

  //한쪽이 BigInt형이고 다른 한쪽이 문자열이면 문자열을 BigInt형으로 변환 후 비교
  if(oneIsBigInt_and_OtherIsString(leftPrim, rightPrim)) {
    const leftBigInt = _BigInt(leftPrim);
    const rightBigInt = _BigInt(rightPrim);
    if(leftBigInt === undefined || rightBigInt === undefined) return undefined;
    return leftBigInt < rightBigInt;
  }

  //좌우항을 숫자형/bigInt형으로 변환
  /*
  toNumeric의 대상이 되는 leftPrim과 rightPrim은 원시 자료형이며,
  원시 자료형끼리의 형변환은 자바스크립트 내부에서 취급하기 때문에
  부수효과가 일어나지 않는다. 따라서 순서를 바꿔서 처리할 필요가 없다.
  */
  const leftNum = toNumeric(leftPrim);
  const rightNum = toNumeric(rightPrim);

  //좌우항의 타입이 같을 경우 그대로 각 타입의 비교 조건으로 비교
  if(typeof leftNum === typeof rightNum) {
    if(typeof leftNum === "bigint") return leftNum < rightNum;
    return numberIsLessThen(leftNum, rightNum);
  }

  //한쪽이 숫자형, 한쪽이 bigInt형일 때 비교
  if(Number.isNaN(leftNum) || Number.isNaN(rightNum)) return undefined;
  if(leftNum === Infinity || rightNum === -Infinity) return false;
  if(leftNum === -Infinity || rightNum === Infinity) return true;
  return leftNum < rightNum;
}

function isLessThen(left, right)
{
  return _isLessThen(left, right) ?? false;
}

1. 좌항과 우항을 원시 자료형으로 변환한다. 이 때 preferType은 number로 한다.
2. 좌항과 우항이 모두 문자열이면 문자열의 비교 연산을 수행한다.

• 각각의 문자를 0부터 각 문자열의 길이의 최솟값까지 순회하여, 실질적으로 저장된 숫자값(자바스크립트는 utf-16으로 문자열을 인코딩한다)이 다르면 그것을 결과로 취한다.
• 모든 문자열이 같을 경우, 길이를 비교한다.
  3. 한쪽이 BigInt형이고, 한쪽이 문자열이면 문자열을 BigInt로 형변환한 뒤 값을 비교한다.
• 문자열을 BigInt형으로 변환하지 못했을 경우 최종 비교값은 undefined(=false가) 된다.
  4. 원시 자료형으로 변환된 각 항을 toNumeric 추상 연산을 적용하여 숫자형/BigInt형으로 변환한다.
  5. 만약 타입이 같을 경우, 그대로 비교한다.
• 숫자형의 경우
  • 어느 한쪽이 NaN이면 undefined이다.
  • 어느 한쪽이 +0이고 다른 쪽이 -0이면 같은 것으로 취급한다.
  • 어느 한쪽이 양의 무한대이면 그 쪽을 큰 것으로 취급한다.
  • 어느 한쪽이 음의 무한대이면 그 쪽을 작은 것으로 취급한다.
  • 어느 쪽에도 해당하지 않을 경우 실수 비교 연산을 수행한다.
• BigInt형의 경우
  • 실수 비교 연산을 수행한다.
  6. 어느 한쪽이 NaN이면 undefined이다.
  7. 어느 한쪽이 양의 무한대이면 그 쪽을 큰 것으로 취급하고, 음의 무한대이면 작은 것으로 취급한다.
  8. 각 항을 실수로 변경한 후 비교 연산을 수행한다.

비교 연산자(==)

동등 비교 연산자(==)는 추상 연산으로 isLooselyEqual이라는 연산을 이용하여 값을 계산한다. !=의 경우도 동일한 연산을 사용하며, 값만 반대일 뿐이다.

ECMAScript 명세서에서 정의하고 있는 ==의 형변환 과정은 다음과 같다. 이해를 돕기 위해 자바스크립트로 작성한 isLooselyEqual 코드를 같이 첨부한다.

function type(value)
{
  if(value === null) return "null";
  if(typeof value === "function") return "object";
  return typeof value;
}
function typeCheck(left, right, [type1, type2="any"])
{
  const leftType = type(left);
  const rightType = type(right);
  if(type2 === "any") return (leftType === type1 || rightType === type2);
  if(leftType === type1 && rightType === type2) return true;
  if(rightType === type1 && leftType === type2) return true;
  return false;
}
function objectTypeCheck(left, right)
{
  const rightValueType = ["number", "string", "symbol", "bigint"].includes(type(right));
  return type(left) === "object" && rightValueType;
}

function isLooselyEqual(left, right)
{
  //타입이 같을 시 strict 비교
  if(type(left) === type(right)) return left === right;

  //한쪽이 null이고 다른 쪽이 undefined이면 true
  if(typeCheck(left, right, ["null", "undefined"])) return true;

  //한쪽이 숫자형이고 다른 쪽이 문자열이면 문자열을 숫자로 변환
  if(typeCheck(left, right, ["number", "string"])) {
    return isLooselyEqual(+left, +right);
  }
  if(typeCheck(left, right, ["bigint", "string"])) {
    return isLooselyEqual(BigInt(left), BigInt(right));
  }

  //한쪽이 boolean형이면 불리언을 숫자로 변환
  if(typeCheck(left, right, ["boolean"])) {
    if(type(left) === "boolean") return isLooselyEqual(+left, right);
    if(type(right) === "boolean") return isLooselyEqual(left, +right);
  }

  //한쪽이 object형이면 object를 원시 자료형(perferType은 default)으로 변환
  if(objectTypeCheck(left, right)) return isLooselyEqual(toPrimitive(left), right);
  if(objectTypeCheck(right, left)) return isLooselyEqual(left, toPrimitive(right));

  //한쪽이 Number이고 다른 한쪽이 BigInt형일 때
  if(typeCheck(left, right, ["number", "bigint"])) {
    if(!Number.isFinite(left) || !Number.isFinite(right)) return false;
    return left == right;
  }
  return false;
}

1. 좌항과 우항의 타입이 같으면 값을 기준으로 비교한다.
2. 한쪽이 null이고 다른 쪽이 undefined이면 true를 반환한다.
3. 한쪽이 숫자형이고 다른 쪽이 문자열이면 문자열을 숫자로 형변환한 후 비교한다.
4. 한쪽이 BigInt형이고 다른 쪽이 문자열이면 문자열을 BigInt로 형변환한 후 비교한다.
5. 한쪽이 Boolean형이면 불리언을 숫자로 형변환한다.
6. 한쪽이 Object형이고 다른 한쪽이 숫자형(숫자로 형변환된 불리언 포함), 문자열, BigInt, Symbol형이면 Object를 추상 연산 toPrimitive()을 이용하여(preferType은 default이다) 원시 자료형으로 변경한 뒤, 이를 기반으로 계산한다.
7. 한쪽이 숫자형이고 다른 쪽이 BigInt형이면
   • 한쪽이 NaN, Infinity, -Infinity면 false를 반환한다.
   • 각 항을 실수로 변경한 후 비교한 값을 결과로 취한다.
8. 그 외의 경우, false를 반환한다.

맨 처음 문제의 답

답은 false다. new Date()와 Date.now()는 자료형이 각각 Object와 Number로 다르기 때문에, 형변환의 과정이 필요하다. 이 때, Object는 해당 오브젝트의 @@Symbol.toPrimitive 메소드를 우선적으로 호출하고(이 때 hint는 default이다) 없으면 valueOf, 그래도 없으면 toString 메소드를 호출한다. new Date()는 [Symbol.toPrimitive] 메소드가 존재하며, 그 값은 문자열이므로 문자열과 숫자를 비교하게 된다. 문자열과 숫자를 비교할 때에는 문자열 쪽이 숫자로 형변환되어서 비교된다. 이 때 NaN과 숫자는 다른 값이므로 false가 나온다.

+7기 기준, 멤버십에 입과한 캠퍼는 전체의 70% 정도였다.

나는 챌린지 때 어떻게 공부했는가

혹시 다음 8기생에게 참고삼아서 내 챌린지 때 공부 방법을 잠깐 써 보기로 하겠다. 멤버십 합격 기준은 정말 베일에 쌓여 있고, 자기가 멤버십에 들어올 실력이 아닌 것 같은데 붙었다는 사람도 있다고 하니 진짜 챌린지 그 순간만 바라보고 공부하는 것이 능사인 것 같다. 챌린지 수료한 사람의 공통된 말이지만, 챌린지는 멤버십에 가기 위한 수단보다는 지속 가능한 개발자로 성장하기 위한 경험이라고 생각한다.

1. 7시 커트라인은 안 중요하다. 7시는 자신의 페이스를 체크하기 위한 중간 체크포인트일 뿐이다. 사실 예상 문제 해결시간이 8시간인 것도 있는 만큼, 정말 장식인 게 느껴진다.
2. 나의 경우, 문제 해결을 위한 배경지식을 얕게 공부하고 문제를 설계하고 해결한 뒤, 학습정리를 수행했다. 단, 이 경우는 본인의 페이스에 맞게 조절하는 것이 좋다. 다른 분은 학습정리로 먼저 탄탄한 배경지식을 갖고 설계를 한 뒤 문제를 풀었다.
3. 점심시간은 따로 주어지지 않는데, 나는 피어세션이 끝나면 12시에 점심을 먹으면서 문제를 파악했다. 체크아웃을 한 뒤, 저녁을 먹고 1시간 정도 휴식을 가진 뒤 다시 작업에 들어갔다.
4. 학습정리를 좀 빡세게 했다. 4시간 정도. 부스트캠프를 하면서 기록을 남길 일이 종종 있는데, 기록은 본인이 어떻게 학습했는지, 그 학습으로 어떻게 성장하고 있는지를 남기는 강력한 증거이므로 나는 문제 해결에 집중하기보다는 문제를 어떻게 풀었는지, 그리고 그 과정에서 무엇을 배웠는지 기록을 열심히 하는 것을 추천드리고 싶다.
   • 학습정리의 경우 나는 큰 틀을 기준으로 작은 주제를 dfs식으로 파고드는 방식으로 정리했는데, 작은 주제를 파고들 때 잘 끊는 것 역시 중요한 것 같다.
5. 주말은 하루를 쉬고, 나머지 하루는 리팩토링 등 일주일 활동을 보충하는 시간으로 보냈다.
6. 커뮤니티 활동 역시 중요하다고 생각한다. 피어세션이든, 슬랙에서의 토론이든 열심히 질문하고 열심히 답변하자. 나는 주로 슬랙에서 질문을 보고 아는 것들은 열심히 답변하는 방향으로 활동했었다.
   • 부스트캠프 문제를 풀다 보면 일부러 모호하게 지문이 적혀 있어서 다양한 해석의 여지가 있는 부분이 있다. 그것도 많이. 웬만해서는 해석에 대한 질문보다는 문제에 담긴 원리 등 확장성 있는 질문을 하는 것이 좋을 것이다.

그 외에 중요하다고 생각한 것들

1. 중요한 것은 다른 사람들과의 비교가 아닌, 어제의 자신과의 비교다. 어제의 자신과 비교하면서 더 나은 방향으로 나아가는 것이 지속 가능한 개발자이기에.
   • 이 과정에서 다른 사람들을 벤치마킹하려는 의지를 보이는 것이 중요하다. 자신의 팀뿐만 아니라 다른 캠퍼의 코드도 구경해 보자.
2. 비록 자신이 실력이 뛰어나서 문제를 7시간 내에 풀었더라도, 더 나은 개선의 의지를 보이는 것이 중요하기에, 7시간 업적에 연연하지 않고 리팩토링을 진행하는 것이 좋을 것이다.
3. 잠은 중요하다. 무조건 새벽 4시 전에는 자도록 하자. 새벽에는 능률이 떨어질 뿐더러, 무엇보다 늦잠 자다 체크인 시간에 늦을 수 있다.

css 효과에 블러를 적용하지 않으면 60fps를 유지하던 캔버스가 블러를 적용시키니 30fps 정도로 프레임이 뚝 떨어지는 모습을 볼 수 있다. 아마 css 블러와 web 캔버스 api가 역시너지를 일으키면서 gpu를 잡아먹는 것으로 보이는데, 자세한 것은 더 찾아봐야 할 것 같다.

특이한 점은 backdrop-filter를 적용한 엘리먼트와 캔버스가 겹치면 캔버스가 실제로 다른 엘리먼트에 가려져 보이지 않아도 무조건 프레임 드랍이 일어난다는 것이다.

결론적으로 오늘의 교훈은 다음과 같다.

• css 블러와 캔버스 api는 절대 겹치지 않도록 할 것. 가급적이면 블러 효과가 들어간 배경을 사용할 때 포토샵 등으로 블러를 먼저 먹인 이미지를 사용할 것.
  • 헤더에 backdrop-filter는 본문에 캔버스 api를 사용하지 않을 때에나 사용할 것.
• 캔버스 자체적으로 블러 효과를 먹이고 싶을 경우 css 블러를 사용하는 것이 아니라 캔버스 자체 블러 필터를 사용할 것. (pixi.js의 경우 blurfilter가 존재)

7월 18일부터 8월 12일까지 4주간 진행된 부스트캠프 웹・모바일 7기 챌린지가 드디어 막을 내렸다.

각 일차 회고록

16일차

이제부터는 배경지식이 없습니다. 미션을 해결하기 위해 얻어야 하는 지식도 스스로 알아가셔야 합니다.

4주차부터는 기본적으로 주어지는 배경지식이 없다. 그래서 문제를 읽고 배경지식을 유추해서 공부해야 한다. 진정한 야생은 최소한의 길잡이조차 주어지지 않고, 자기가 스스로 부스트캠프가 야생이라는 것이 느껴지는 순간이었다. 사실 16일차 문제와 비슷한 것을 13일차에 이미 시도한 적이 있었다. 그 때에는 거의 야매로 배워서 적용했었는데, 16일차에서 복습하면서 제대로 적용하니 내 지식이 강화된 느낌이었다. 더불어 이전 프로젝트를 하면서 썼던 기술을 적용하는 과정에서 해당 기술의 문제점을 파악할 수 있었다. 이 과정에서 부스트캠프 도중에 배웠던 테크닉이 또다시 빛을 발했다.

4주차에서 유일하게 7시간 내에 클리어한 문제였다. 나머지는 기본적으로 밤 10시에 끝냈고 마지막 날은 새벽에 끝을 보았다.

17일차

설계의 중요성

설계가 정말 중요한 문제가 나왔다. 바로 전일차에 나왔던 것은 물론 이전에 배웠던 설계방식과 학습 내용을 가져와야 풀 수 있는 문제였다. 추가적으로 학습해야 하는 배경지식이 있다기보다는 이전에 반복적으로 나온 것들을 어디까지 확실히 알고 있냐는 느낌이었다.

코드를 짜다가 특정 모듈에 로직이 너무 집중되어서 비대해지는 것 아니냐는 지적을 받았다. 해당 문제를 해결하기 위해 학습정리를 하다 특정한 디자인 패턴을 알게 되었고 그것을 적용하였다. 나중에 다시 알아보니 이미 코드를 짜면서 쓰고 있었는데 그 명칭과 효과를 몰랐던 패턴이었다더라.

18일차

이게 10시간이 걸릴 게 아닌데?! -그 당시 나, 학습노트에 느낀 점을 쓰며

예전에 개인 프로젝트를 하면서 한 번 다뤄본 것이 주제로 나왔다. 그때는 원리를 모르고 썼었는데, 이번에 직접 구현하면서 원리를 알아가니 좋았다더라. 그런데 한 번 다뤄본 거고 설계가 어렵지 않은 것 같았지만 끝나고 나니 10시간이나 걸렸다더라.

끝없는 예외처리

4주차 문제들이 다 그렇지만, 예외처리가 정말 중요했었다. 개발자는 자신이 생각한 플로우대로 사용자들이 따라올 것이라고 생각하지만, 실제 환경에서 사용자는 개발자가 상상치도 못한 창발적인 방법으로 버그를 찾기도 한다. 그래서 가능한 한 사용자가 할 수 있는 모든 방법을 틀어막아서(?) 사용자가 개발자가 의도한 방법대로 프로그램을 사용하도록 유도하는 것이 예외처리다. 아마도 사용자 입장에서 어떻게 하면 프로그램에 버그가 날까 하고 생각하면서 가능한 모든 수를 생각하느라 늦어진 게 아닐까 싶다. 그만큼 예외처리도 잘 이루어졌던 것 같다.

19일차

(슬랙에 어떤 분이 올리신 사진의 원본. 정보유출 문제로 그 사진을 올릴 수 없지만 대충 이번 부스트캠프에서 악명 높은 문제 4천왕을 꼽은 내용이었다. 그리고 끝판왕이 19일차.)

마지막 일차라 그런지, 지금까지 나왔던 대부분의 CS지식과 테크닉을 총동원해서 풀어야 하는 문제가 나왔다. 그 중 화룡점정은 지금까지 나왔던 미션들이 나열되는 부분. 챌린지 4주간의 기억을 되돌아볼 수 있었던 가슴 뭉클한 시간이었다.

놀랍게도 19일차 문제는 내가 한 라이브러리를 써서 해 봤던 문제였다. 하지만 그 때는 라이브러리를 쓸 줄만 알았지 라이브러리가 어떻게 굴러가는지는 몰랐었다. 힘들게 직접 구현해보니 라이브러리의 소중함을 알게 되었다더라.

20일차

훈련소 수료 기다리는 훈련병같지 않아요? -누군가

고통스러웠던 19일차 미션이 끝나고, 피어세션 시간이 되었다. 가장 어려운 미션이라 모두 힘들어했지만 그래도 어떻게든 끝낸 모습을 볼 수 있었다. 19일차에는 시간이 빨리 지나가서 어느덧 새벽이 되었는데, 막상 모든 미션이 끝난 20일차가 되고 수료식만을 남겨둔 상황에서는 시간이 정말 가지 않았다. 누군가는 훈련소 수료 기다리는 훈련병이라느니, 전역 기다리는 장병 같다느니 하는데 딱 그 느낌인 것 같다.

팀 회고 시간에는 3주차처럼 갈틱폰을 진행했다. 이번 주차 갈틱폰도 재미있는 주제들이 나왔다. 참고로 위의 짤을 슬랙 갤러리 채널에 올렸는데, 놀랍게도 챌린지 갤러리 명예의 전당 2위에 빛나는 영광을 얻을 수 있었다!

챌린지 수료식은 zep이라는 가상공간 플랫폼에서 진행되었다. 방명록이나 zep 미니게임, 슬랙에 올라왔던 사진들을 모아놓은 갤러리 등 예쁘게 꾸며져 있었다. 특히 가장 압권이었던 건 내준내상이었는데, 온갖 웃긴 상드립을 볼 수 있어서 재미있었다. 마지막으로 zoom에서 소감을 발표하고 7시에 헤어졌는데, 챌린지가 완전히 끝났다는 느낌이 드니 뿌듯하면서도 아쉬운 느낌이 들었다.

(3주차 캠퍼들과 같이 찍은 그 당시 사진.)

챌린지 수료 후기

(미션은 이제 없다!)

당연한 거지만, 챌린지가 끝나니 매우 후련했다. 6개월치 공부를 한 달만에 끝낸 듯한 느낌이었고, 거기에 놀라운 건 그 중 절반이나 소화했다는 것이다. 절반이라고 말하면 별거 아닌 것 같지만, 무려 3개월이다! 챌린지의 1/6밖에 소화하지 못했어도 1달치 공부다. 챌린지를 하지 않고 개인 공부만 했다면 3개월치도 아니고 3일치 공부밖에 소화하지 못했을 것이다.

챌린지 과정은 힘들었지만, 그만큼 얻어간 것들도 많았다. 많은 사람들이 챌린지 힘들다 해서 얼마나 힘들겠냐고 챌린지 시작 전에는 생각했지만, 진짜 자바스크립트 난생 처음 해 본 사람부터 수년간 자바스크립트로만 코드를 짠 사람들, 전공자 졸업생에 회사를 퇴사하고 온 사람들까지 전부 다 가리지 않고 힘들어했다.

대충 어떻게 어려웠냐면, 설계과정이 어려웠다. 우리가 아는 코딩테스트 같은 알고리즘적인 어려움이 아니라, 설계를 제대로 하기 위해서 해당하는 CS지식이 정확이 어떻게 돌아가는지를 알고 있어야 했고, 나는 그 기초 CS지식에 대한 내용이 거의 없는 상태로 들어왔기 때문에, 전공자보다 배는 공부해야 했다. 그나마 코드를 많이 짜 봤기 때문에 코드 짜는 데에 어려운 점은 없었다.

미션 자체의 분량도 엄청났고, 구현해야 할 것들도 상당히 많았다. 한 미션의 경우 무려 800줄이 넘는 코드를 작성해야 했다. 분명 2시쯤에 밥을 먹고 설계를 완료하면 그래도 7시 이전에는 끝낼 수 있을 것 같았는데, 코드를 짜다 보면 이렇게 오래 걸릴 게 아닌데...?라고 말하는 자기 자신을 볼 수 있었다. 이 미션이 만약 학교 전공수업 중에 나온 미션이라면 일주일을 줬을 것이다.

무엇보다도 끝없는 밤샘으로 인한 체력적 소모가 심했다. 나는 23주차 기준으로 평균적으로 오후 910시에 미션을 완료한 편이었지만, 아직 학습정리가 남아 있었기 때문에, 미션 도중 배웠던 점을 정리하고 학습정리를 다 끝내고 나면 새벽에 자는 경우가 부지기수였다. 한번은 고된 피로로 인해 늦잠을 자는 경우도 있었고, 특히 마지막 날에는 미션이 새벽에 끝났기 때문에 학습정리까지 마무리하느라 밤을 새고 말았다.

힘든 것들만 있는 것 같았지만, 얻어간 것들도 상당히 많았다. 챌린지 기간 동안 얻어간 것들은 후술한다.

챌린지에서 얻어간 것들

다양한 CS지식들

개구리를 해부하지 말고, 직접 만들어라.

부스트캠프에서 제일 많이 얻어갔던 것이었다. 본래 나는 프로그래밍을 많이 하는 과 출신이었고, 그만큼 코드도 많이 짜 봤지만, 전공자는 아니라서 CS지식에 취약했었다. 부스트캠프에서 제공하는 잘 짜여진 미션을 받고, 코드를 설계하면서, 학교에서는 공부하지 못했던 CS지식을 넓고 깊게 알 수 있었다.

특히 가장 좋았던 것은 CS지식에 대한 흐름을 확실히 알 수 있었다는 것이다. 책이나 아티클을 보고 공부하는 것만으로는 좋아, 그런 지식이 있어. 그래서 어쩌라는 거지? 라는 느낌이 들었으며, 정확히 알아도 알지 못하는, 외우기만 하는 느낌이었다면, 부스트캠프를 하면서 해당 CS지식을 모사하며 직접 만들어 보니, CS지식에 대한 개괄적인 지식이 아니라 알고리즘을 위한 흐름 위주로 공부하게 되고, 이러한 원리로 해당 CS지식이 굴러간다는 것을 알게 되었다.

커밋 컨벤션

(부스트캠프 직전 프로젝트인 Stardew Dressup 커밋. 부스트캠프 도중 프로젝트는 커밋 내용만으로 주제가 스포되기 때문에 올릴 수 없다.)

본래 나는 커밋 컨벤션을 그렇게 지키는 편이 아니었다. 2일차까지 커밋을 대충 작성했는데, 3일차 피어세션 때 다른 동료들이 커밋 컨벤션을 잘 지키면서 공부한 흔적을 잘 보여준 것을 보고, 그 동안 나의 커밋 스타일이 개판이었다는 것을 자각하게 되었다. 이후 커밋 컨벤션을 스스로 만들어서, 챌린지 20일차까지 커밋 컨벤션을 지키려고 노력하고 있다. 전 세계에 내 서비스를 퍼블리싱할 가능성도 있기 때문에 웬만해서는 영어로 커밋 메시지를 쓰려고 노력하고 있다.

동료학습

누구도 완벽할 수는 없다. 완벽하지 않기 때문에 서로를 지탱하는 동료가 있는 것이다.

부스트캠프 이전, 나는 혼자서 모든 것을 해결하려는 사람이었다. 혼자서 공부하고, 개인 프로젝트를 진행하면서 누군가와 같이 공부한다는 생각 자체를 하지 않았다. 하지만 부스트캠프라는 좋은 기회에서 동료들과 같이 코드를 리뷰하면서(내 코드를 남이 볼 것이라는 걸 생각하지도 못했다.) 지식을 공유하고, 때로는 지식을 전수받기도 하면서 같이 성장한다는 기쁨을 누릴 수 있었다.

부스트캠프는 학교 수업 등과 다르게 줄세우기가 없다. 정말로 다른 사람의 객관적인 실력을 아무도 모른다. 그렇기 때문에 저 사람들을 멤버십에 가기 위한 경쟁자로 보는 게 아니라 멤버십은 하늘에 맡기고 서로 성장하는 동료로 쉽게 볼 수 있었던 것 같다.

동시에, 완벽한 사람은 없다는 것을 알게 되었다. 슬랙에서 날아다니는 사람조차도 부족한 면모는 있으며, 반면 아무리 코드 실력이 부족한 사람이라도 강점이 있기 마련이다.

학습 방법

부스트캠프가 지향하는 학습 방법은 만들면서 배우기다. 특정한 지식을 직접 만들어 보고, 만드는 과정에서 설계적 완성도를 끌어올리거나 실제와 더 흡사하게 만들기 위해 깊게 공부하고, 이 과정에서 새로 배운 것들을 기록하여 훗날의 자신이나 다른 사람들이 쉽게 볼 수 있게 공유하는 것이 부스트캠프의 학습 방식이다.

내가 지향하는 학습 방식도 이와 비슷하다. 실제로 만들면서 배우기를 부스트캠프 이전에도 수행했기도 했다. xnb.js를 제작할 때에는 npm과 번들러, xnb 파일의 구조와 버퍼를 다루는 방법, 워커 스레드에 대해 배웠고, stardew dressup을 제작할 때에는 react, pixi.js에 대해 배웠다. 만약 내가 stardew dressup을 react로 제작하지 않았다면 react를 왜 써야 하는지도 몰랐을 것이다. 부스트캠프에서 새로 알게 된 것은 만들면서 배우기를 CS지식을 공부하는 데에도 적용할 수 있다는 것과, 프로젝트를 만들기 위한 수단으로써의 학습이 아닌 학습의 수단으로써의 프로젝트라는 패러다임을 전환할 수 있었다는 것이다.

부스트캠프가 끝났는데도 아직도 모르는 것들이 산더미다. 그래도 부스트캠프에서 만든 분야는 흐름은 말할 수 있는 수준으로 끌어올려졌다. 그래서 부스트캠프에서 얕게 넘어갔던, 또는 몰랐던 것들은 부스트캠프 스타일로 스스로에게 미션을 주어서 학습해볼 계획이다.

챌린지에서 기여했던 것들

코드 스타일

참 챌린지 기간인 '야생' 에 어울리네요. 짧은 시간인데 뭐든지 필요하면 뚝딱뚝딱 만들어 잘 쓰시는군요....ㅋㅋㅋㅋ 구현력이 대단하십니다. 저는 하루만에 저렇게 절대 못 할 것 같아요.. 일주일동안 교과서같은 모범 코드 잘 봤습니다 -피어세션 한 캠퍼분

피어 세션을 하면서 코드 스타일에 대한 칭찬을 많이 받았었다. 사실 코드 스타일에 대해 자신은 없는 편이었고, 본래 목적이 코드 스타일 개선이었던지라, 의외로 코드 스타일에 칭찬을 받아서 코드에 대해 자신감이 조금씩 생기는 것 같았다.

부스트캠프에서 나는 다른 사람을 이끌어주는 포지션이 되었다. 대학에서 하던 게 자바스크립트로 코드 짜는 거라서 그런지, CS지식이나 공대생처럼 사고하기 같은 건 하지 못하지만 내 장기인 자바스크립트 테크닉이나 코드를 예쁘게 보이게 하는 법 같은 부분을 중점적으로 피드백했었다.

나와 함께 했던 18명의 캠퍼분들에게 미숙한 코드를 좋게 봐주셔서 감사할 따름이다.

자바스크립트 테크닉

let [first, second, ...rest] = [1,2,3,4,5]; // 구조 분해 할당
let {x, y} = position; // 객체 구조 분해 할당
let copied = [...origin]; // 스프레드 연산자.

// 함수 구조분해 할당
function moveForward({x,y})
{
  return {x:x+1, y};
}

// 배열 고차함수
Array.from({length:100}, (_,i)=>i)
  .map(elem=>elem*2)
  .filter(elem=>elem>10)
  .reduce((sum, cur)=>sum+cur, 0);

// promise 감싸기
function sleep(millis)
{
  return new Promise(resolve=>setTimeout(resolve, millis));
}

// promise 체이닝
sleep(1000)
  .then( ()=>console.log("1s 경과") )
  .then( ()=>sleep(2000) )
  .then( ()=>console.log("2s 추가경과") )

// 파이프 함수
pipe(
  mult(2),
  filter(elem=>elem>10),
  average
)([1,2,3,4,5,6,7,8,9,10]) 

// 정규표현식 체이닝
regexpChain(
  [/^create\s+(.*)/i, ([,n])=>pipe(parseCreate, createPlayer)(n)],
  [/^move\s+(.*)/i,   ([,n])=>pipe(parseMove,     movePlayer    )(n)],
  [/^delete\s+(.*)/i, ([,n])=>pipe(parseDelete, deletePlayer)(n)]
  [/.*/, ()=>console.log("다시 입력하세요!")]
)(command);

function moveForward({x,y}){} 이런식으로 선언하고 파라미터를 따로 파싱할 필요가 없어서 되게 좋은 것 같아요! 이런식으로 편한 문법들이 많은데 저는 아직 활용을 잘 못하고 있었네요. 배워갑니다! 전체적으로 문법 활용을 잘 하셔서 깔끔하고 간결하게 짜신 것 같아요 bb -피어세션 한 캠퍼분

올해 초, 코딩테스트를 공부하면서 자바스크립트에 대한 고급 테크닉들을 많이 배웠고, 함수형 프로그래밍에도 어느 정도 관심 있어서 고차함수의 사용이나 배열 메소드 체이닝 등 기초적인 함수형 사고방식을 배웠다. 본격적으로 부스트캠프를 하면서 여러 자바스크립트 테크닉들을 미션에서 많이 사용했고, 피어세션에서 다른 분들에게 피드백을 하면서 지금까지 사용했던 자바스크립트 테크닉들을 알려주기도 했다.

커맨드의 파싱, 이후 로직을 단계별로 구분해서 함수형 프로그래밍적으로 구현하신 부분도 인상깊습니다.. 많이 배워갑니다. -피어세션 한 캠퍼분

올해 초에 배운 것뿐만 아니라, 미션 도중 함수형 프로그래밍을 적용해서 이를 사용하기도 했는데, 대표적으로 위에 적었던 파이프 함수와 정규표현식 체이닝이다. 정규표현식 체이닝은 과도한 정규표현식 파싱 반복에 화가 나서 만든 기법이었는데, 결과적으로 가독성이 향상되는 효과를 얻을 수 있었고, 해당 부분을 배우려고 하는 캠퍼들도 있었다.

1주차와 3주차에 만난 한 캠퍼분이 있다. 지식을 빨아들이는 스펀지같은 분이었는데, 1주차에 내가 알려주었던 자바스크립트 테크닉들을 3주차에 적용해서 사용한 것을 보고 뿌듯함과 존경심을 느꼈다. 나의 지식으로 누군가가 성장하는 것을 통해 동료학습을 통해 모두를 끌어올리는 느낌을 알 수 있었다.

챌린지에서 아쉬웠던 것들

자신의 코드 스타일 개선

피어세션하셨던 많은 분들이 내 코드를 칭찬해 주셨긴 하지만, 사실 나는 코드 스타일을 개선하려고 부스트캠프에 온 거였다. 물론 챌린지 전에 비해 각 함수 코드가 짧아지고, 가급적이면 순수함수로 짜려고 노력하는 습관이 길들여지긴 했지만, 근본적으로 내 코드가 좋은 코드인가? 라는 질문에 답하려면 그러지는 못할 것 같다.

좋은 코드는 바보가 봐도 이해할 수 있는 코드, 그러니까 별다른 주석 없이도, 코드를 처음 본 사람이나 미래의 내가 흐름을 이해할 수 있는 코드 라고 생각한다. 나는 부스트캠프 이후 각 함수가 무슨 역할을 하는지까지는 어느 정도 정리할 수 있는 수준까지는 왔지만, 전체적인 코드의 흐름은 아직까지도 부족한 것 같다.

7시간 제한 업적에 매몰

챌린지 7시간 제한은 일종의 체크포인트이자 코드를 빨리 완성해야 된다는 일종의 자극제 역할을 하지만, 피어세션 때 마지막으로 gist를 수정한 시간이 전일 19시인가 라는 항목 때문에, 정작 7시간 이내에 마무리한 미션은 코드를 개선하면 7시간 안에 코드를 다 짰다는 업적이 손실되는 것처럼 느껴졌기 때문에, 코드를 19시 이후에 개선하는 것에 대해 소극적이었다. 오히려 7시간 내에 끝낸 미션보다 7시간을 넘겨서 끝낸 미션에 대해 리팩토링을 더 부담없이 할 수 있었던 것 같다.

아마 다시 챌린지 1일차로 돌아가게 된다면 7시간 제한은 장식으로 생각하고, 7시간 제한 안에 코드를 짰어도 코드 리팩토링을 더 신경쓸 것 같다.

멤버십?

사실 챌린지 끝나고 1주일이 된 시점에서 멤버십에 대한 욕심이 없다고는 말할 수 없다. 챌린지 도중에는 챌린지 미션과 학습에만 집중하다 보니 멤버십에 관한 생각은 까맣게 잊어버렸지만, 막상 챌린지가 끝나니 이왕이면 멤버십까지 가서 더 성장하고 싶다는 생각이 들었다. 물론 멤버십에 아쉽게 들어가지 못하더라도, 챌린지에서 공부하는 법이나 여러 코드 스타일들, CS지식들을 배웠기 때문에, 이를 기반으로 더 성장할 수 있다고 생각한다.