<div id="readability-page-1" class="page"><article>얼마 전 진행했던 코드리뷰에서 <code>undefined</code>의 사용에 대한 문제로 이야기가 나왔어요. 개인적으로는 너무도 오랫동안 당연하게 <code>null</code>과 <code>undefined</code>를 나름 명확하게 구분했었고, 각 사용처에 맞게 사용하고 있었기에 사실 이 부분에 관해서는 더 알아볼 생각도 없었습니다. 아이러니하게도 이야기가 나왔던 문제는 오해로 생긴 다른 문제였기에 쉽게 해결됐어요. 하지만 관련해서 검색하다가 생각지 못한 내용을 만나게 됩니다. <code>null</code>을 사용하지 말고 <code>undefined</code>만을 사용하자는 주장이었죠. 타입스크립트는 컨벤션에도 명시되어 있었습니다. "Use undefined, do not use null." 이건 예전에 봤었지만 그냥 지나쳤던 것 같아요. 제 고정관념이 너무 확고했거든요.
운이 좋았는지 때마침 보고 있던 더글라스 크록포트 형의 신간에서도 관련된 내용이 있어서 조금 더 생각해볼 수 있었어요. 하지만 책에서는 너무 가볍게 다뤄서 아쉬웠습니다.
이렇게 새롭지 않아 뻔하고 너무 당연했던 것들도 시간이 흐르면 그 패러다임이 달라질 수 있는 것 같아요. 무엇 하나 변하지 않는 게 없네요.
결론적으로 앞으로의 프로젝트에서는 코드베이스에서 <code>null</code>은 직접 사용하지 않고 <code>undefined</code> 만을 사용하는 것을 고려해 보려고 합니다. 특히 토이프로젝트에서는 당분간 <code>null</code>을 사용하지 않을려고 합니다. 뭔가 경험에 기반한 저만의 정답이 나올 때까지요.<ins data-ad-layout="in-article" data-ad-format="fluid" data-ad-client="ca-pub-4811193197471582" data-ad-slot="7153541064"></ins>
<h2>고정관념</h2>
<code>undefined</code>을 생각하면 떠오르는 몇가지 특징 있죠.
<ol>
<li>객체에 없는 프로퍼티에 접근하면 <code>undefined</code>를 얻는다.</li>
<li>변수에 값을 초기화하지 않으면 <code>undefined</code>를 갖는다.</li>
<li><code>undefined</code>는 아직 존재(초기화) 하지 않은 상태를 표현하는 값이다.</li>
<li>그래서 직접적인 할당은 모순을 만든다. 값이 아직 존재하지 않은 상태의 값이니까 말이다. 예를 들어 할당하는 순간 값이 있는 건데 값이 <code>undefined</code>면 아직 존재하지 않는 것이다.</li>
<li><code>undefined</code>를 키워드로 취급하지 않는 예전 브라우저들이 있다. 그래서 <code>undefined</code>를 변수처럼 사용할 수 있어 순수한 <code>undefined</code>가 아닐 수도 있다.</li>
</ol>
그 외에도 많지만 <code>undefined</code>와 <code>null</code>을 구분해서 사용하는 관점에서의 특징을 적어봤어요.
처음 이쪽 세계의 커리어를 쌓고 지금까지 일하면서 보고 느낀 것들에 의해 고정관념이 생긴 것 일 수도 있어요. <code>undefined</code>는 정의되기 전의 일종의 상태 같은 값이기에 <code>빈 값</code>이라는 명확한 의미를 갖는 <code>null</code>을 사용하는 것이 당연하다고 여겼죠. 애초에 이런 생각을 하게 된 이유가 무엇인지 모르겠어요. 내용을 어디서 봤는지도 기억이 안 나고 이렇게 정확하게 정의한 것을 본적이 있는지조차 가물가물합니다. 아무튼 제 머릿속엔 그렇게 박혀있었습니다.
<ul>
<li><code>undefined</code> 는 아직 초기화되지 않은 값, 존재하지 않는다.</li>
<li><code>null</code> 은 빈 값을 표현하는 값, 존재는 한다. (마치 빈 스트링 같이)</li>
</ul>
인터넷에서 제가 이해하고 있는 내용을 제대로 설명하는 이미지를 찾았어요.
<figure>
<img alt="0 vs null vs undefined" src="https://pbs.twimg.com/media/DusCOfyXcAA9_F7?format=jpg&amp;name=large">
<figcaption>출처: <a href="https://twitter.com/ddprrt">Stefan Baumgartner</a></figcaption>
</figure>
사실 <code>null</code>을 잘 구분해서 사용하긴 했지만 단점이 없는 것은 아니에요. <code>null</code>을 사용했기 때문에 <code>undefined</code>와 <code>null</code>을 둘 다 확인해야 하는 경우도 있고요. <code>null</code> 은 타입이 <code>object</code>로 구분되기 때문에 실수를 유발할 수도 있습니다. <code>undefined</code>보다 <code>null</code>이 타이핑하기 짧은 건 사실이지만 애초에 자동으로 초기화된 <code>undefined</code>라는 기본 값을 사용하지 않으니 오히려 코드가 더 길어질 때도 있어요.
<div data-language="javascript"><pre><code>let value;

// vs

let value = null;</code></pre></div>
그래도 <code>null</code>대신 <code>undefined</code>를 사용한다는 건 생각을 해보지도 않았죠. 용도가 다르다고 생각했으니까요. 바꿔 말하면 코드에서 <code>null</code>을 사용하지 않는 것을 생각해본적이 없었죠. 용도가 있으니까요.
<h2>자바스크립트는 두 개네?</h2>
대부분의 프로그래밍 언어는 없음을 표현하는 값 혹은 타입을 갖고 있어요. 보통은 그게 하나죠. 자바나 c, c++, c# 등은 <code>null</code>을 사용하고요. (c는 <code>\0</code>도 사용하지만 <code>null</code>하고 같은 의미니까요.) lisp, objectiv-c, swift는 <code>nil</code>을 사용해요. 그밖에 다른 언어들도 많지만 그나마 조금 알고 있는 언어들만 생각해 봤어요. 네 아무튼 모두 하나에요.
rust 같이 null이 없는 경우도 있긴 하죠. 하스켈도 없어요. 함수형 프로그래밍을 적용한 언어일수록 null을 안 쓰려는 것 같아요. 함수형 언어의 특성상 null 을 두지 않는 방향이 더 맞긴 하겠네요. 불변성을 중시하니 나중에 변경될 수 있는 값 따위는 쓰고 싶지 않을 테니까요. 있거나 혹은 없거나 둘 중 하나겠죠. (함수형 프로그래밍은 잘 모르지만요...)
없음을 이용하는 언어에서는 대부분 한 가지 값을 사용하고 있고 <code>null</code> 과 <code>undefined</code>를 별도로 구분하지 않죠. 사실 이 부분도 전혀 인식하지 않고 있다가 이번에 인지하게 된 것 같아요. "아 자바스크립트는 두 개네?" 그게 문제라고 생각해 봤던 적은 없었습니다. 부정적인 상태를 뜻하는 값이 한 개 이상이라는 점은 Truthy와 Falsy한 값으로 뭉뚱그려진 암묵적인 형 변환이라는 편리함과 모호함을 동시에 선물했고 "잘" 사용하면 됨 아니면 네놈 탓이라는 무서운 압박을 가하는 양날의 검이었죠. 원인을 너무 과대하게 생각한 것 일 수도 있겠네요.
<h2><code>undefined</code> 만을 사용해야하는 이유</h2>
그러면 왜 <code>undefined</code> 만을 사용해야 할까요? <code>null</code>이 <code>undefined</code> 보다 나아서 일까요? <code>undefined</code>만 사용하자는 주장은 사실 둘 중 하나를 사용하자는 주장에 가깝습니다. 그래서 이 문제는 무엇을 사용하지 않는 것이 좋을까 있을까로 해석될 것 같습니다.
<code>null</code>은 개발자의 의도로 사용됩니다. 반면 <code>undefined</code>는 자바스크립트 엔진에 의해서 사용되죠

이렇게 변수를 선언할 때 초깃값을 주지 않는다면 <code>something</code> 이란 변수에는 <code>undefined</code>가 할당됩니다. 굳이 개발자가 명시적으로 할당하지 않아도 그렇게 되지요. 코드상에서 암묵적으로 값이 할당됐다는 설명보다는 이 코드를 실행하기 전에 실행 컨텍스트인 활성 객체(AO)가 새로 생성되고 함수 내부의 변수들을 수집하는 과정에서 코드에서 명시적으로 값을 할당하기 전까진 <code>undefined</code>값을 갖도록 하는 자바스크립트 엔진 내부 작업의 결과라고 설명하는 것이 더 정확합니다. 아무리 코드상에서 변수를 선언함과 동시에 바로 값을 할당했다 치더라도 동작은 우선 <code>undefined</code>값을 갖은 후에 값이 변경되는 형태니까요. 아무튼 일단 'undefined'가 무조건 사용됩니다.
엔진이 <code>null</code>이 아니고 <code>undefined</code>를 사용합니다. 적어도 이 과정에서는 엔진에게 <code>undefined</code> 대신 <code>null</code>을 사용하게 할 방법이 전혀 없습니다. <code>undefined</code>가 디폴트이자 대체 불가능한 값입니다. 함수에서 특별히 값을 리턴하지 않았을 때 <code>undefined</code>를 리턴한다는 점도 마찬가지 입니다.
자 여기서 첫번째 이유
<blockquote>
<blockquote>
"엔진이 <code>null</code>을 사용하지 않고 <code>undefined</code>를 사용하고 있습니다."
</blockquote>
</blockquote>
개발자의 의도로 <code>null</code>을 사용하게 된다면 <code>falsy</code>한 값을 확인해야 하는 상황에서 <code>undefined</code>와 <code>null</code> 두 가지를 모두 명시적으로 확인해야 합니다. 예를 들어 <code>number</code> 변수의 경우 숫자 <code>0</code> 값과 <code>null</code> 값과 <code>undefined</code>를 모두 확인해야 하는 거죠.
두번째 이유
<blockquote>
<blockquote>
"<code>null</code>의 사용은 <code>falsy</code>한 값이 더 추가되는 것이다."
</blockquote>
</blockquote>
그리고 마지막으로 세번째 이유가 있습니다. 유명한 내용이죠.
<blockquote>
<blockquote>
"<code>typeof</code> 키워드를 사용하면 <code>null</code>의 타입을 <code>object</code>로 판별합니다."
</blockquote>
</blockquote>
이건 스펙이 의도한 것이 아닌 자바스크립트 상의 명백한 버그입니다. 버그임에도 바꿀 수 없는 것은 너무 오랜 기간 마치 표준인 것처럼 사용됐고 그래서 이것을 변경했을 때 기존 코드에 미치는 영향이 크기 때문에 울며 겨자 먹기로 그대로 둘 수밖에 없는 것이지요. 이 문제를 해결하기 위해선 <code>typeof</code> 와 함께 또 다른 타입 체크 키워드가 생겨야 할 판입니다. 즉 해결될 가능성이 적습니다.
<code>object</code>를 값으로 사용하는 변수에서 <code>object</code>의 부재로 <code>null</code>을 사용한다면 <code>typeof</code>로 변수를 판별해서 특정 작업을 할 때는 각별히 더 신경 쓰고 조심해야 합니다. 보통 이런 타입 체크 코드는 뭔가 더 조심하려고 만드는 코드인데 그 조심하려고 만드는 코드를 사용할 때 더 조심해야 하고 더 신경이 쓰인다는 것 자체가 참 아이러니한 거죠. <code>null</code>을 사용하지 않으면 이런 문제가 없습니다.
<h2>null을 사용하지 않았을때의 문제점</h2>
첫 번째 문제는 <code>undefined</code>에 대한 문제입니다. <code>undefined</code>는 키워드임에도 불구하고 키워드로 취급하지 않아 식별자로 사용될 수 있었습니다.
<div data-language="javascript"><pre><code>function doSomething1(undefined) {
 console.log(undefined + 1);
}


function doSomething2() {
 var undefined = 0;
 console.log(undefined + 1);
}</code></pre></div>
요즘의 브라우저들은 이 문제가 해결돼서 <code>undefined</code>에 값을 할당할 수 없게 됐죠. 그 이전 브라우저를 지원해야 하는 경우라면 여전히 문제가 발생할 여지가 있습니다. 이게 문제인 것을 몰랐던 개발자도 ESLint 같은 정적 분석 도구의 도움으로 코드 베이스에 이런 말도 안 되는 코드를 만들진 않겠지만 런타임에 외부에서 장난질을 하는 경우는 막을 방법이 없겠죠.
두 번째 문제는 DOM API가 <code>null</code>을 사용한다는 점입니다. 문제라기보다는 자바스크립트 엔진이 <code>undefined</code>를 사용한다는 것을 핑계로 여기까지 왔는데 엥? DOM API에서는 <code>null</code>을 쓰잖아?의 뉘앙쓰입니다. <code>querySelector</code>나 <code>getElementById</code> 같이 DOM에서 엘리먼트를 탐색하는 API들은 찾는 대상을 발견하지 못했을 때 <code>null</code>을 리턴합니다.
세 번째 문제는 JSON에서는 <code>undefined</code>를 사용하지 못한다는 점입니다. 일반적으로 JSON에서는 옵셔널한 값이 없는 경우 null을 사용합니다. <code>undefined</code>은 JSON 스펙에서 사용할 수 없는 값입니다. 뭘 JSON까지 빡빡하게 고려하냐고 생각할 수 있겠지만 어쨌거나 코드에서 사용되니까요. 큰 문제는 없지만 찝찝했던 모호함을 없애고자 여기까지 왔어요. 시작부터 고려되는 예외는 없어야 할 것 같습니다.
<h2><code>undefined</code>만 사용하기</h2>
<code>null</code>을 사용하지 않았을 때의 문제점이 총 세가지가 있었습니다.
<ol>
<li><code>undefined</code>의 순수성</li>
<li>DOM API의 <code>null</code> 사용</li>
<li>JSON에서의 <code>null</code></li>
</ol>
각 문제에 대한 대안을 생각해 볼게요.
<h3><code>undefined</code>의 순수성</h3>
이 부분은 앞서 언급했듯 시간이 흐를수록 사라질 수 있는 문제입니다. 모던 브라우저에서는 <code>undefined</code>가 <code>undefined</code>로 순수하게 보장되니까요. 사실 IE6 초창기 시절부터 개발해왔던 저도 <code>undefined</code>의 값이 변경되서 생겼던 문제는 겪어보지 못했던 것 같습니다. 악의적으로 의도로 문제가 될 순 있지만 어디까지나 그저 가능성만 있었던 거죠.
가장 이상적인 해결책은 이 문제가 발생하지 않도록 브라우저의 지원 범위를 높이는 것입니다. 브라우저의 범위를 정확히 특정하기 조금 애매한데 대충 ES6를 지원하기 전에 대부분 대응됐을 겁니다. 확실한 건 ES6를 지원하는 브라우저라면 문제없다는 점입니다. 그럼에도 불구하고 브라우저를 제한할 수 없는 상황이거나 조금이라도 더 조심하고 싶다면 순수한 <code>undefined</code>를 만들어 사용합니다.
<div data-language="javascript"><pre><code>const undef = (() =&gt; {})();</code></pre></div>
함수가 아무것도 리턴하지 않으면 사이드 이팩트로 <code>undefined</code>를 리턴한다는 점을 이용해서 순수한 <code>undefined</code>를 만들 수 있습니다. 이보다 더 순수한 <code>undefined</code>는 없죠 :)
<h3>DOM API의 <code>null</code> 사용</h3>
이점이 조금 귀찮습니다. 이쯤 와서 생각해 보면 왜 이것들은 <code>null</code>을 굳이 사용해야 했나라는 불만까지 생깁니다. 일례로 비교적 최근에 생긴 <a href="https://blog.shiren.dev/2021-08-30/"><code>WeakRef</code></a>에서 참조 객체가 존재하는지 확인하는 <code>deref()</code>메서드도 참조 객체가 존재하지 않을 때 <code>undefined</code>를 리턴합니다. <code>null</code>을 사용하지 않아요. 근데 왜 DOM API에서만 굳이 사용했냐는 거죠. 불평해서 뭐합니까. 아무튼 사용합니다. <code>querySelector</code> API 에서라도 바뀌었다면 더 좋았지 않았을까 생각해 보지만 또 그렇게 되면 그 나름대로 최악의 일관성이겠네요.
그래서 <code>null</code>을 <code>undefined</code>로 변경해 주는 작업을 매번 할 수밖에 없습니다.
<div data-language="javascript"><pre><code> const element = document.querySelector('#something') || undefined;</code></pre></div>
이건 딱히 대안이라고 볼 수 없겠지만 요즘은 래액트나 뷰같은 프레임웍을 사용하는 것이 보편화됐기 때문에 직접 DOM API에 접근할 일이 거의 없기도 합니다. 라이브러리나 범용 모듈 수준에서만 조금 거슬리겠네요.
<h3>JSON에서의 <code>null</code></h3>
보통 API의 데이터에서 옵셔널한 값이 없는 것을 표현하는 값으로 <code>null</code>을 사용하도록 설계하는데요. JSON 스펙도 스펙이지만 없는 값은 아예 전달을 하지 않는 것이 좋습니다. 말 그대로 "없는" 것이니까요. 없는 값을 표현하기 위해 프로퍼티로 굳이 키와 함께 <code>null</code>을 사용하는 것보다는 아예 해당 프로퍼티를 전달하지 않는 것이 장점이 더 많습니다. 이건 명확한 장점이네요. 적어도 페이로드 용량이라도 줄일 수 있으니까요.
<div data-language="javascript"><pre><code>const badJsonPayload = {
 name: 'shiren',
 ownedHouse: null
}

const goodJsonPayload = {
 name: 'shiren'
}</code></pre></div>
그리고 어차피 실제로 저는 <code>ownedHouse</code>가 없으니까요. ㅜㅜ
<h2>마무리</h2>
새로운 기술을 공부하는 것도 중요하지만 확고하다고 생각한 것들에 다른 의견을 수용하고 새로운 시각으로 바라보며 좀 더 깊이 있고 풍성한 생각을 갖도록 노력하는 것도 중요한 것 같습니다. 이런 융통성을 갖기란 정말 힘들죠. 더글라스 크록포드의 신작 말미에는 이런 내용이 나옵니다. "과학은 장례식 한 번에 하나씩 발전한다 ." 새로운 패러다임이 나오고 바뀌는 속도에 비해 사람들이 패러다임을 받아들이고 수용하는 능력은 부족하기 때문에 사람이 죽어 세대가 바뀌어야 발전한다는 의미입니다. 개인적으로 이 책에서 제일 인상 깊었던(?) 부분이기도 합니다. 변하지 않는 확고한 생각들이 쌓이면 쌓일수록 꼰대가 되는 것이겠죠. 이 바닥에서 변하지 않은 것은 변하지 않는 것 따윈 없다는 사실인 것 같습니다.</article></div>

shiren.dev RSS Feed

얼마 전 진행했던 코드리뷰에서 의 사용에 대한 문제로 이야기가 나왔어요. 개인적으로는 너무도 오랫동안 당연하게 과 를 나름 명확하게 구분했었고, 각 사용처에 맞게 사용하고 있었기에 사실 이 부분에 관해서는 더 알아볼 생각도 없었습니다. 아이러니하게도 이야기가 나왔던 문제는 오해로 생긴 다른 문제였기에 쉽게 해결됐어요. 하지만 관련해서 검색하다가 생각지 못한 내용을 만나게 됩니다. 을 사용하지 말고 만을 사용하자는 주장이었죠. 타입스크립트는 컨벤션에도 명시되어 있었습니다. "Use undefined, do not use null."…

null 떠나고 만난 undefined

댓글