<p>드라마앤컴퍼니에서 2년 10개월정도의 커리어를 마무리하고 토스로 이직하게 되었다. 그 과정에서 성장했던 것들을 기록해보려고 한다.</p>
<h3>이유</h3>
<p>이직에는 이유가 있어야한다. 나의 경우에는 불안감이었다. 불안은 참으로 어려운 감정이다. 여태까지 나를 성장시킨 원동력이기도 하면서, 늘 내가 올바르지 않은 판단을 할 때의 근본적인 원인이기도 하기 때문이다. 그렇지만 연료로 활용할 가치는 너무나 충분한 감정이라는 것은 부정하지 않는다. 그러다가 재직기간을 2년정도 채워 갈 때 문득 '지금 회사에서 정말 10년동안 일해도 좋겠다.'라는 생각이 들었고 나의 불안은 이런 생각에서 시작했다.</p>
<p>불안함이 없어서 생기는 불안이 있었다. 내 삶은 불안의 연속이었다. 검정고시 고졸이라는 저학력에 대한 불안과 한 순간도 경제활동을 하지 않으면 생계유지에 치명적이기 때문에 생기는 금전적인 불안감. 그 것 말고도 인간관계에서도 늘 불안이 따라왔다. 그러다가 안정적인 직장을 얻고, 좋은 사람들을 많이 알게 되면서 삶에서 불안이 많이 걷어낼 수 있었던 것 같다. 어느 순간부터는 안락함 속에서 삶을 유지하는 것에 익숙해지고 있었다. 내가 앞으로 나아갈 이유에 대한 고민은 당연하게 찾아왔다.</p>
<p>불안하지 않아서 불안함이 생겼다. 어찌보면 나는 불안중독인 사람인 것 같기도 한데 가치판단은 보류하고 그 불안함에 쫓기다 보면 나는 결론적으로는 나아지는 방향으로 가고 있었기 때문에 무언가 행동해야 했다. 그래서 생각한 것이 이직이었다. 그렇게 충동적으로 작년 말에 이력서를 처음 넣기 시작하면서 이직을 시작했다.</p>
<h3>실패</h3>
<p>결론적으로 첫 도전은 실패했다. 이직은 작년 10월 말 부터 4월정도까지 액티브하게 시도했는데 모두 실패했다. 물론 그 과정에서 얻은 경험들은 굉장히 좋았다. 배우는 것도 많았다. 그리고 느낀 건 역시 뭐든 경험을 통해서 얻어야 한다는 것이었다. 이직후기나 면접후기 200개 읽어보는 건 큰 도움이 되지 못했던 것 같다. (위로는 받았다)</p>
<p>실패에 대한 큰 원인들을 생각해보면 그 시기의 고용시장 상황이 좋지 않았던 점, 내가 면접 경험이 턱없이 부족했던 점, 그리고 내 생각의 깊이가 그렇게 깊지 않았던 점 들이 있을 것 같다. 아무튼 여러가지 이유로 나는 수차례 좋지 않은 결과와 마주해야 했고 어느 순간부터는 이게 오기가 생겨서 '이직을 위한 이직’을 하고 있다는 생각이 들었을 때 쯤 중단했다. 뭔가 이대로 이직을 멈추면 실패하는 것, 포기하는 것 이라는 생각에 휩싸여 있었던 것 같다. 그런 생각들이 나를 갉아먹고 있을 때 다행히 스톱할 수 있었다.</p>
<h3>정비</h3>
<p>결국 액티브하게 이직을 하려던 마음을 멈추고 먼저 나를 좀 돌아봤다. 나는 어떤 개발자인가? 나를 채용하고 싶은 이유가 있을까? 먼저 찾아야 하는 건 나의 '특별한 강점’이라는 생각이 들었다. 생각 해 보니 면접중에 '정원님이 다른 개발자들과 비교했을 때 특별히 더 잘하는 것이 있나요?'라는 노골적인 질문을 받은 적도 있었다. 그러면서 내가 면접관으로 참여할 때의 일화가 생각이 났다. 면접자는 분명히 모든 질문에 대부분 대답을 했고, 우려되는 부분이 없었음에도 '뽑아야 하는 이유’를 찾기 어려운 면접자분이셨다. 그 때 나는 스스로 면접관의 역량이 부족하다고 많이 자책했던 기억이 난다. 내가 그 면접자의 강점을 잘 이끌어내는 질문들을 했어야 했는데 그러지 못했다. 그렇기 때문에 나는 면접자에게서 어떤 특별한 '뽑아야 하는 이유’를 찾지 못했고 결국에는 그 분을 뽑지 않았다.</p>
<p>그 때는 스스로 면접관으로서 역량이 너무 부족했기 때문이라고 생각하고 많이 힘들어 했었다. 한 사람의 채용과정에서 내 역량 부족으로 제대로 된 평가를 하지 못했다는 것에 대한 죄책감 같은 것들이 들었다. 물론 반은 맞는 말이지만, 자신을 뽑아야 하는 이유를 어필하고 보여주는 것도 면접자로서의 책임이고 역량이라는 것을 면접자로 면접에 참여하면서 느꼈다.</p>
<p>그래서 일단은 김정원이라는 프론트엔드 개발자가 어떤 강점이 있고, 어떤 특별함이 있는지에 대해서 많이 생각해봤다. 내가 막연하게 생각하고 있던 나의 장점들을 정리해봤다. ‘제품을 만드는 것에 적극적이고 문제를 해결하는 것에 포커스를 맞춘다’ 라는 메이커로서의 역량이 있었고, '타입스크립트에 대한 깊은 이해도를 기반으로 실무코드에 잘 활용하고, CSS 속성들에 관심이 많아서 적재적소에 잘 활용할 수 있는 것, 번들러와 모노레포와 같은 프론트엔드 개발환경에 대한 경험과 클라우드 인프라에 대한 기본적인 이해도를 갖고있다’라는 엔지니어로서의 역량이 있었다. 또 '구성원과 친하게 지낼 수 있다’라는 커뮤니케이션 역량도 있었다. 이 중에서 사실 커뮤니케이션 역량은 면접 과정에서는 말로 풀어내는 것 보다는 면접 경험 전반에 녹아드는 영역이라고 생각한다.</p>
<p>아무튼 이렇게 한 차례 이직 시도를 마무리하면서 스스로에 대한 생각을 정리하면서 앞으로 어떻게 나의 역량을 정의하고 방향을 정할지 생각하는 시간을 가졌다.</p>
<h3>잠깐 사족</h3>
<p>사실 처음 이직을 시도할 때는 굉장히 근자감에 차 있었다. 우리 회사에서 이직한 분들은 모두 다 괜찮은 회사로 잘 이직을 했었고 내가 지금 회사에 입사할 때도 한 번에 입사할 수 있었기 때문이었다. 그리고 스스로 능력에 대해서도 좋게 생각하고 있었다. 좋게 생각하면 자신감이지만 어느정도 오만함을 넘나들고 있었다. 그런데 결과는 앞서 얘기한 것 처럼 좋지 않았다. 인터넷에는 3~4개의 회사를 동시에 합격해서 좋은 곳으로 이직했다는 후기들이 많았었고 나도 그런 미래(?)를 생각하고 있었다. 하지만 현실은 그러지 못했고 내 생각에는 하향 지원으로 넣어본 곳에서 탈락통보를 받기도 하면서 많이 위축되기도 했었다.</p>
<p>지금 생각 해 보면 '면접은 운칠기삼’이라는 말이 어느정도는 맞는 것 같다. 물론 결정적으로는 '기삼’이 제대로 받쳐준다는 전제가 있어야 하겠지만 역시 '운칠’의 영역도 크다고 생각이 든다. 그 때의 시장 상황이나 내가 가고싶은 회사에서 회사에서 필요로 하는 사람, 그리고 내가 어떤 역량에 강점이 있는지 그리고 그걸 봐줄 수 있는 면접관인지까지. 여러가지 예측 불가능한 변수들이 지속적으로 변화한다. 나도 시장이 좋을 때 면접 준비를 철저하게 잘 해서 이직을 했다면 여러군데를 동시에 합격해서 이직하는 경험을 할 수 있었을수도 있고… (아닐 수도 있고… ^^)</p>
<p>아무튼 결국 '운칠기삼’의 중요한 포인트는 ‘포기하지 않는 것’ 정도라고 생각한다.</p>
<h3>이직</h3>
<p>그리고 6월달 쯤에 토스에서 Frontend Platform 공개채용을 진행했고 JD를 보니 내가 지금 회사에서 고민하고 공부했던 일들과 겹치는 것들이 많았고 점점 해당 영역에 흥미를 느끼고 있었던 시점이어서 ‘정말로 큰 기대 없이’ 지원을 해보게 되었다. 물론 토스는 너무나 가고싶던 회사 중 하나였고 특히 내가 사용자로서 팬심이 큰 서비스였다. 그런데도 큰 기대가 없었다는 걸 강조하는 건 어디든 지원을 할 때 나름 기대 안하려고 하지만 내심 기대하는 게 있기 마련인데 이번에는 진짜 없었고(아마 앞선 실패로 인해 자신감이 많이 낮아졌던 탓도 있을 것이다), 전형중에 '시험 전형’이라는 게 있었기 때문에 그냥 내가 지식들을 잘 습득한건지 확인해볼까 하는 마음이 더 컸었다. 시험도 그냥 내가 배운 것 위주로 풀면 되겠다 싶어서 미리 공부를 하지도 않았다. 그런데 내가 잘 공부했었는지 면접을 볼 기회를 잡았고 그대로 최종 합격까지 갈 수 있었다.</p>
<h3>토스의 면접</h3>
<p>토스의 이번 면접 경험은 정말 좋았다. 사실 이전에 토스의 다른 계열사의 면접을 본 적이 있었는데 그 때는 큰 감흥이 없었는데 이번 면접과정은 정말 좋았다. (그 때는 탈락해서 그런 걸수도 있다 ^^) 기술 면접에서는 내 이력서를 정말 자세히 읽어본게 느껴질 만큼 나의 강점들을 잘 이끌어 낼 수 있는 대화로 이끌어 주셨다. 이 전에 내가 고민했던 '면접관의 역량’에 빗대어 봤을 때 역량있는 면접관 분들이라는 느낌이 들었다. 이후 소문의(?) 컬쳐핏 면접도 좋았다. 간략하게 설명하자면 그냥 '있는 그대로의 나’를 보여주면 되었고 '있는 그대로의 생각’을 보여주면 됐다. 다른 컬쳐핏 면접은 보면 가끔 뭔가 '정답’을 말해야 할 것 같고, 그 회사에 대해서 얼마나 알고있는지를 시험보듯 면접이 진행되는데 토스에서는 그런 느낌을 받지 못했다. 그러다보니 면접이 끝나고도 ‘잘 봤다’ 혹은 '망했다’는 생각 자체가 안들었다. 그냥 나는 내 이야기들을 했을 뿐이라서 그러지 않았나 싶다.</p>
<p>그리고 레퍼런스 체크와 오퍼레터 과정을 거쳐서 '최종 합격’을 할 수 있었다. 넉넉하게 보면 거의 1년 정도가 걸린 이직이었다. 주변에서도 많이 축하해줘서 뿌듯했다.</p>
<h3>유종의 미</h3>
<p>나는 다니던 회사에 대해서 애정이 여전히 크다. 드라마앤컴퍼니의 구성원들이나 일하는 방식들에서도 배울점이 아직 너무나 많고, 리멤버라는 서비스에도 애정이 많다. 그리고 당연하지만 아직 내가 해볼 수 있는 것들도 여전히 많다고 생각한다. 그 중에서도 가장 많은 부분을 차지하는 건 '좋은 동료들’이다. 마지막에 재호님과의 원온원에서도 그 얘기를 하면서 살짝 울먹거리기까지 했을 정도였다.</p>
<p>아무튼 그렇기 때문에 남은 시간동안 최대한 유종의 미를 지키고 싶었다. 인수인계할 수 있는 것들을 문서화하고 같이 일했던 사람들과 원온원을 많이 만들고, 나에게 의지했던 사업팀 사람들도 나의 부재가 크지 않도록 파트원 분들에게 많은 부탁도 드렸다… 너무너무 좋은 사람들과 일할 수 있었다는 생각에 지금 이 글을 쓰면서도 가슴이 벅차오르고 있다… (아무튼 진심임)</p>
<p>퇴사하는 날 까지 정시퇴근을 포기하면서 끝까지 많은 사람들과 이야기하고 너무 좋게 마무리 했다. (물론 살짝 아쉬운 것도 있었지만… ^^) 새로운 곳에 가서도 좋은 사람들과 일할 수 있으면 좋겠다. 이런 우려들을 동료들에게 이야기 하면 늘 '정원님이 하기 나름일 거예요’라는 대답을 해줬다. 그게 늘 용기가 되는 것 같다. 토스에서도 사람들과 즐겁게 일할 수 있도록…! 하기 나름을 잘 해보자. 아자아자!</p>
<h3>다음 목표</h3>
<p>나는 검정고시 졸업이라는 객관적으로 아쉬운 학력 갖고 있다. 물론 나는 이것에 대한 불만은 없다. 학력이라는 것은 현대사회를 살아감에 있어서 여전히 중요하지만 그렇다고 절대 극복할 수 없는 것은 아니다. 그걸 내가 지금 증명하고 있다는 생각도 있다. 그런 맥락에서 네임밸류 있는 회사에 간다는 건 나를 설명하기 좀 더 편해지는 것이기도 하다. 이제는 학력을 경력으로 어느정도는 커버할 수 있지 않을까 하는 기대도 있다. (특히 어른들과에 대화에서 고졸 커밍아웃은 늘 1초 정도의 정적을 가져와서 힘들다.)</p>
<p>이런 이야기를 한 이유는 학력과는 별개로 정말 지식의 습득을 위한 공부를 하고싶다는 욕심이 생겼고 그에 맞는 목표를 만들고 있기 때문이다. 특히 요즘에는 AI에 관심이 많은데 AI는 특히 전문 교육과정이 필요한 것 같다. 일단 선형대수학같은 수학적인 부분 부터 시작해서 머신러닝이나 딥러닝 같은 알고리즘을 이해하려면 독학으로는 좀 어렵지 않을까 싶다. 그래서 사이버대학교나 학점은행제 같은 방법으로 공부를 해볼까 생각중인데 회사를 다니면서 할 수 있을지는 잘 모르겠다… 일단은 그런 생각이 있고…</p>
<p>그리고 돈 모으기도 시작했다. 나는 30살 평생 돈을 제대로 모아본 적이 없는데, 최근에는 결혼을 하고 가정을 만들고 싶다는 개인적인 목표가 생겨서 제대로 재테크를 해볼 생각이다. 최근에는 ISA계좌를 만들어서 ETF에 투자를 해보고 있다. 사실 아직도 잘 모르겠는데 결혼 하려면 돈을 모아야 한다. 라는 단순한 이유를 갖고 실행중이다.</p>
<h3>끝으로</h3>
<p>글이 생각보다 길어졌다. 고졸이라는 키워드로 어그로를 끌었지만 사실 고졸과 관련된 이야기는 별로 없다… 나는 지금까지 살면서 직접적으로 고졸이라서 느끼는 디메리트가 많지 않은 것 같다고 생각한다. 물론 분명히 내가 모르게 있었겠지만, 내가 모르니까 된 거 아닌가…? 그럼 럭키 비키 아닌가…? 그렇게 생각한다. 이 글을 읽는 분이 있다면… 음… 아무튼 다 잘 될 겁니다. 꾸준히 열심히 최선의 최선을 다해보세요.</p>
<p>참고로 첫 출근은 9월 9일이다. 아직 출근도 안한 시점에서 이런 글을 쓰는 게 맞나 싶긴하지만, 글 쓸수 있는 여유가 있을 때 써놔야 할 것 같아서 썼다. 무사히(?) 3MR기간을 마칠 때 쯤 새로운 포스팅을 하는 게 단기적인 목표이다.</p>


3년차 프론트엔드 이직기록

View Transition API 알아보기

<p>Typescript 5.4 beta가 출시되었고 그에 따라서 <a href="https://devblogs.microsoft.com/typescript/announcing-typescript-5-4-beta/">블로그 포스팅</a>이 올라왔다. 그 중에서 <code>NoInfer</code>라는 이름의 유틸리티 타입이 추가된 게 눈에 띄었는데, 제법 유용하고 자주 사용될 유틸리티 타입이라는 생각이 들어서 정리해봤다. 위 포스팅에서도 잘 설명되어 있지만 간단하게 알아보자.</p>
<h3>No Inference</h3>
<p>직역하면 '추론하지 마세요’겠다. 말 그대로 타입 추론을 하지 못하게 하는 유틸리티 타입인데, 타입을 작성하다보면 타입을 미리 결정하지 못하고 추론을 통해서 결정해야 하는 상황이 있을 때 보통 제네릭을 활용하여 해결한다. 예를 들어 아래와 같은 상황이 있다.</p>
<pre><code class="language-ts"><span class="hljs-keyword">function</span> pick&lt;T&gt;(<span class="hljs-attr">collection</span>: <span class="hljs-keyword">readonly</span> T[], <span class="hljs-attr">item</span>: <span class="hljs-built_in">string</span>): T {
  <span class="hljs-keyword">return</span> collection.<span class="hljs-title function_">find</span>(<span class="hljs-function">(<span class="hljs-params">_item</span>) =&gt;</span> _item === item);
}
</code></pre>
<p>배열의 요소를 하나 가져오는 함수이다. 그런데 이렇게 하게 된다면 가져오는 아이템의 타입이 너무 열려있어서 좋지 않다. collection의 타입에 따라 item의 타입이 결정될 수 있도록 하고싶은 의도로 코드를 다음과 같이 수정할 수 있다.</p>
<pre><code class="language-ts"><span class="hljs-keyword">function</span> pick&lt;T&gt;(<span class="hljs-attr">collection</span>: <span class="hljs-keyword">readonly</span> T[], <span class="hljs-attr">item</span>: T): T {
  <span class="hljs-keyword">return</span> collection.<span class="hljs-title function_">find</span>(<span class="hljs-function">(<span class="hljs-params">_item</span>) =&gt;</span> _item === item);
}
</code></pre>
<p>그러나 이렇게 타입을 선언하고 실제 사용하게 되면 예상과는 다르게 동작하는 걸 알 수 있다.</p>
<pre><code class="language-ts"><span class="hljs-keyword">const</span> fruits = [<span class="hljs-string">&quot;apple&quot;</span>, <span class="hljs-string">&quot;banana&quot;</span>, <span class="hljs-string">&quot;tomato&quot;</span>] <span class="hljs-keyword">as</span> <span class="hljs-keyword">const</span>;
<span class="hljs-keyword">const</span> item = <span class="hljs-title function_">pick</span>(fruits, <span class="hljs-string">&quot;pineapple&quot;</span>);
<span class="hljs-comment">//    ^</span>
<span class="hljs-comment">//    &#x27;apple&#x27; | &#x27;banana&#x27; | &#x27;tomato&#x27; | &#x27;pineapple&#x27;</span>
</code></pre>
<p><code>pick</code>의 두 번째 인자가 fruits의 요소가 아닌데도 타입에러를 발생시키지 않고 같이 추론의 대상이 되는 문제가 발생한다. 순서대로 첫 번째 인자 T가 추론되어 타입이 결정되고 두번째 인자의 타입은 결정된 타입으로 처리될 거라 기대했지만, 두 번째 인자에서도 동일한 제네릭 T가 사용되기 때문에 함수가 호출될 때 제네릭의 구조가 만족할 수 있는 결과로 추론되어 원하지 않는 상황이 발생했다.</p>
<p>하지만 타입스크립트로 개발을 하다보면 이미 이런 상황들을 많이 겪었고 다음과 같은 방법들을 통해서 해결할 수 있다는 걸 이미 알고 있다.</p>
<pre><code class="language-ts"><span class="hljs-comment">// 제네릭을 하나 더 추가하고 첫 번째 제네릭의 하위 타입으로 만든다</span>
<span class="hljs-keyword">function</span> pick&lt;T, I <span class="hljs-keyword">extends</span> T&gt;(<span class="hljs-attr">collection</span>: <span class="hljs-keyword">readonly</span> T[], <span class="hljs-attr">item</span>: I): T;

<span class="hljs-comment">// 호출 할 때 먼저 제네릭을 확정한다</span>
pick&lt;<span class="hljs-keyword">typeof</span> fruits[<span class="hljs-built_in">number</span>]&gt;(fruits, <span class="hljs-string">&quot;pineapple&quot;</span>);
</code></pre>
<p>보통은 첫 번째 방법을 더 활용하겠지만, T타입의 추론을 막기위해서 제네릭을 하나 더 사용해야 하고 I타입은 오직 T타입의 참조를 위해서만 사용되기 때문에 합리적인 방법은 아니다. 이쯤 되면 <code>NoInfer</code>유틸리티 타입의 역할이 추론될 것이다. <code>NoInfer</code>유틸리티 타입을 사용하면 아래와 같이 합리적이고 간단한 방법으로 처리할 수 있다.</p>
<pre><code class="language-ts"><span class="hljs-keyword">function</span> pick&lt;T&gt;(<span class="hljs-attr">collection</span>: <span class="hljs-keyword">readonly</span> T[], <span class="hljs-attr">item</span>: <span class="hljs-title class_">NoInfer</span>&lt;T&gt;): T;
</code></pre>
<h3>포스팅 한 이유</h3>
<p>최근 Solid.js의 내부 구현이 궁금해서 소스코드를 뒤져보다가 NoInfer 타입을 직접 구현해서 사용하고 있었던 걸 보고 신기하고 유용하다 생각하고 있었는데, 며칠 뒤에 타입스크립트 5.4 베타에 포함될 거라는 이야기를 듣고 반가워서 정리 해 봤다.</p>
<p>만약 <code>NoInfer</code>유틸리티 타입을 미리 사용해 보고 싶다면 아래와 같이 사용할 수 있다.</p>
<pre><code class="language-ts"><span class="hljs-keyword">type</span> <span class="hljs-title class_">NoInfer</span>&lt;T <span class="hljs-keyword">extends</span> <span class="hljs-built_in">any</span>&gt; = [T][T <span class="hljs-keyword">extends</span> <span class="hljs-built_in">any</span> ? <span class="hljs-number">0</span> : <span class="hljs-built_in">never</span>];
</code></pre>
<p>그런데 튜플 타입의 인덱싱을 통해서 어떻게 추론을 막는건지 궁금해서 ChatGPT에게 물어보니 아래와 같은 답변을 해줬다.</p>
<blockquote>
<h4>타입 추론 방지</h4>
<p>튜플과 인덱싱된 접근을 사용하는 것은 타입스크립트의 타입 추론 메커니즘을 '우회’하는 방법입니다. 특정 타입 T에 대해 [T][0]과 같은 표현을 사용하면, 타입스크립트는 T의 타입을 직접적으로 추론하는 대신, T 타입의 요소를 포함하는 튜플의 첫 번째 요소의 타입을 추론하게 됩니다. 이 과정에서 타입스크립트는 T의 타입을 '고정’시키고 추가적인 추론을 수행하지 않으려고 합니다.</p>
<h4>인덱싱된 접근의 역할</h4>
<p>인덱싱된 접근은 타입스크립트에게 타입 정보를 '사용’하도록 강제합니다. 즉, [T][0]은 타입스크립트에게 T 타입의 값을 단순히 사용하는 것이 아니라, 특정 구조(이 경우 튜플) 내에서 T의 타입을 확인하도록 요구합니다. 이 과정에서 타입 추론이 특정 지점에서 ‘멈추고’, 명시적으로 제공된 타입이나 이전에 추론된 타입을 그대로 사용하게 합니다.</p>
</blockquote>
<p>이걸 보고 생각난 것이 <code>never</code>타입을 추론하기 위해서</p>
<pre><code class="language-ts"><span class="hljs-keyword">type</span> <span class="hljs-title class_">IsNever</span>&lt;T&gt; = [T] <span class="hljs-keyword">extends</span> [<span class="hljs-built_in">never</span>] ? <span class="hljs-literal">true</span> : <span class="hljs-literal">false</span>;
</code></pre>
<p>같은 식으로 타입을 튜플의 원소로서 타입을 '확정(가두기)'한 뒤 참조하는 느낌과 비슷하다고 느꼈다.</p>
<p>또한 <code>NoInfer</code>유틸리티 타입에 대해 논의한 <a href="https://github.com/microsoft/TypeScript/issues/14829">깃허브 이슈</a>도 있으니 궁금하면 읽어봐도 재밌을 듯 하다.</p>


NoInfer 알아보기

<p>2022년에 이어서 2023년도 개발자로 보냈다. 2023년에는 기술 관련 포스팅을 좀 많이 작성해보려고 했는데… 2개 정도 올렸다… 그 중에 하나는 재작년 태스크에 대한 트러블슈팅… 블로그를 많이 남겨야 하는 이유중에는 특히 내가 한 해동안 뭘 했는지 기록을 남기는 용도로서도 굉장히 중요하단 걸 느꼈다. 분명 알찬 한해를 보낸 것 같은데 블로그만 보면 별 거 안한 것 같아 보이고 그러니 좀 서운(?)하다. 올 해는 전반적으로 뭔가 폭발적인 성장! 10보 전진! 같은 것 보다는 내년의 추진력을 위해 준비하는 한 해가 되었는데 그만큼 평화롭기도 하면서 뭔가 뒤흔들어야 한다는 위기감도 같이 느꼈다. 하지만 나는 뭐든 기대 이상으로 잘 하니까 너무 걱정말자…! (아무튼 믿기)</p>
<h2>개인</h2>
<p>먼저 올해 내가 개인적으로 이룬 성장들… 이 퍼뜩 떠오르지는 않아서 아쉽다. 열심히 회사 생활을 했고 더 좋은 코드에 대한 막연함을 조금씩 실제로 코드에 반영해 보기도 했지만 어쩐지 아쉬움이 남는 이유가 뭘까 생각 해 보니 느껴지는 게 아마 '의식적인 성장’이 부족했기 때문이 아닌가 싶다. 작년에 '성장’이란 게 내가 좋은 개발자가 되기 위해서 노력하면 알아서 따라올 것이라고 말했었는데, 스스로 내린 결론에 좀 안일하게 참여했었다. <strong>성장을 위한 성장</strong>은 여전히 경계해야 하지만, 그렇다고 그냥 성장이 알아서 따라오는 건 아닌 것 같다. 내가 어떤 부분에서 성장했는지 아는 것도 성장의 일부인데 올 해는 그런 부분들이 제대로 못 챙겼던 것 같다.</p>
<h4>독서</h4>
<p>클린 아키텍처를 읽었다. 그동안 막연하게 알고 있으면서 알고 있다고 착각하던 것들을 좀 명료하게 머릿속에 정리할 수 있었다. 흩어져서 얽히는 관심사를 나누는 다양한 방법들에 대한 고민들을 해소하는 방법들에 대해서 좀 더 정확하게 볼 수 있게 된 듯 하다. 물론 1회독에 모든 내용을 이해하지는 못했지만 굉장히 적절한 타이밍에 읽었다는 생각이다. 만약 좀 더 빨리 읽었다면 분명 이해하지 못한 부분이 더 많았을테고 더 늦게 읽었다면 왜 이걸 이제야…! 했을 것 같다. 마침 내가 고민하고 있는 부분들에 대해서 설명해주고 있었기 때문에 더 효과적으로 읽을 수 있었던 것 같다.</p>
<p>그리고 웹파트 내에서도 '함께 자라기’라는 책을 읽으면서 북스터디를 했는데 역시 도움되는 내용들이 많았다. 협업을 하면서도 그렇지만 개인적으로도 어떤 태도로 함께 해야하는지, 결국 우리가 함께 잘 해야하는 이유가 무엇인지에 대해서 조금 더 명확하게 알 수 있었다. 읽는 동안 파트원들 모두가 공감할 수 있었던 부분들이 많았다. 우리가 어떨 때 효율적으로 일하고 어떤 상황에서 건강하게 의사소통 할 수 있는지는 이미 경험으로 막연히 알고 있었고, 그것들을 합리적으로 설명해주는 것 만으로 의식적인 습득을 할 수 있었고 그런 방법들을 '내 것’으로 만드는 데에 도움이 되었다.</p>
<h4>직관</h4>
<p>올 해는 '의식적으로 좋은 코드를 작성’하기 위한 고민을 많이했다. (혹은 ‘의식적으로 나쁜 코드 피하기’) 동료 분 중에 한 분이 '정원님은 직관이 좋다’라고 말씀해 주신 적이 있었는데 그 이야기를 처음 들었을 때는 단순하게 '오 내가 직관을 잘 활용하는 구나’라고 생각하고 기분이 좋았는데, 스스로 곰곰히 생각 해 보니 직관을 잘 활용한다기 보다는 그냥 직관에 의존하면서 코드를 작성하고 있었지 않았나 싶었다. 분명 결과물은 괜찮은 것 같은데 이게 왜 괜찮은지 설명해 보라고 하면 할 수 있을까? 라는 두려움이 생긴 것이다. 그래서 클린 아키텍처를 읽기 시작했다. 지식보다는 경험이 중요한 것은 알고있지만 내 경험을 올바르게 공유하고 더 개선하기 위해서는 경험을 지식으로 정제할 수 있어야 한다. 올 해는 그것에 대한 중요성을 확실하게 느꼈고, 다양한 방법으로 나아지려고 하고 있다. 그 방법 중에 하나로 <a href="/2023/%EC%A7%81%EA%B4%80-%EC%A3%BC%EB%8F%84-%EA%B0%9C%EB%B0%9C%EC%97%90%EC%84%9C-%EB%B2%97%EC%96%B4%EB%82%98%EA%B8%B0">직관 주도 개발에서 벗어나기</a> 포스팅을 작성했다.</p>
<h2>회사</h2>
<h4>흑자전환</h4>
<p>회사가 흑자전환을 했다! 처음 입사할 때 재호님 면접에서 '지금 회사가 J커브를 목전에 두고 있다고 생각하고 그 과정을 같이 나아가고 싶다’고 말씀드렸었는데 정말 그 일이 일어나니 제법 가슴이 웅장해졌었다. 내가 앞으로 회사원으로 일을 하면서도 이번에 얻은 '함께 이겨내는 경험’이 굉장히 값진 경험으로 작용할 거라는 기대가 된다. 물론 회사원이 아니라 내 일을 하게 되더라도</p>
<h4>채용</h4>
<p>흑자전환과 함께 제품팀의 인원을 크게 증가시키게 되었고 드디어 우리 파트의 인원 보충이 결정되었다. 무려 11명까지 TO가 나왔다. 같은 IC레벨의 동료분께서 많은 부분들을 책임져 주신 덕분에 채용도 무사히 진행되었다. (이 자리를 빌어 J님께 다시 한 번 감사합니다…) 한 분은 오퍼가 잘 되지 않아서 지금은 10명까지는 인원이 채용되었고 한 명이 더 남았다. 함께 일하고 싶은 사람들을 채용하기 위해서는 필연적으로 면접을 봐야하는데 나에게 면접관으로 참여할 수 있는 기회도 많이 주어졌었다. 처음에는 많이 부담스러웠지만, 면접을 보다 보니 정량적인 기준보다는 어떤 '느낌적인 느낌’이란 게 생각보다 많이 작용하게 된다는 걸 알았다. 그래서 면접관도 역량이 굉장히 중요하다… 면접관들에게 '같이 일하고 싶은 동료’라는 이미지를 주는 것은 지원자의 역량이 가장 클 것이지만 그것을 100% 보여줄 수 있는 좋은 질문들과 대화를 이끌어내는 것이 쉽지 않다는 것이다. 그리고 그 결과들을 통해서 함께 하고싶은가? 라는 질문에 대한 결정을 하는 것도 쉽지 않다. 면접을 보고 두 시간을 넘게 같이 면접을 본 동료와 고민하기도 했었다. 이런 모든 과정에서 같이 팀을 만들어나가는 경험으로서 값진 고민들을 많이 할 수 있었다. 사실 ‘내가 면접관으로써 충분한 역량을 갖고 있는가?’ 라는 질문에는 아직 답을 잘 못하겠지만, 아무튼 최선을 다했다!</p>
<h4>동기부여</h4>
<p>하지만 나는 개인적으로 올 해 '일’에 대한 동기부여를 크게 받지는 못했다. 나름 노력은 했는데 자연 발생(?)하는 동기부여와 노력으로 얻은 동기부여는 조금 다르다. 자연산이 아니라 양식 동기부여(…)같은 느낌이라고 설명하면 적절한 비유가 될 것 같다. 물론 동기부여를 양식으로 얻을 수 있는 것도 중요하다. 앞으로 일을 하면서 모든 일들이 재미있고 내가 하고싶고 강한 동기부여를 느끼고 하지는 않을 테니까. 개발자이면서 회사원으로써 일을 지속가능하게 하기 위해서는 스스로 동인을 계속 찾아야 한다. 그게 아니면 그냥 부품처럼 일하게 되는 거라고 생각한다. 그런 맥락에서 올 해는 그런 것들을 잘 연습할 수 있었다. 정신승리도 승리다! 아무튼 내가 하는 일을 사랑할 수 있도록 끊임없이 노력해야 한다. (너무 괴롭지 않은 선에서)</p>
<h4>파운데이션크루</h4>
<p>크루 특성상 하나의 제품을 맡지 않고, '제품 전반’이라는 모호한 범위를 담당해야 하기 때문에 크루원이 모두 한 가지 목표에 집중하기 어려웠다. 이런 저런 상황들이 고려되어 9월달 부터는 코어크루에서 파운데이션크루로 크루명도 변경했다. 올 해 상반기는 크루 내 메인태스크로 '투데이 탭’을 개발했는데 웹은 스콥아웃이 되어서 굵직한 태스크는 없었다. 그래서 CS 혹은 사업팀 요청사항들을 개선해주는 등 지원업무가 많았어서 보니까 위에서 말한 것 처럼 동기 부여가 쉽지 않았다. 이런 과정에서 그냥 할 수 있는 태스크들을 내가 어렵게 해보는 등의 노력을 좀 더 했으면 좋았을 걸 하는 아쉬움도 있다.</p>
<h4>ISMS-P</h4>
<p>하반기 크루 태스크는 ISMS-P 대응을 위한 작업이 메인이었다. 내가 주도적으로 진행했던 태스크는, 1. 기존 어드민의 Internal API를 모두 API Gateway로 옮기는 작업, 2. 구버전 어드민의 채용관련 기능을 모두 옮겨오는 작업, 3. 제품 전체에 환경변수를 인프라단계에서 주입하도록 변경하는 작업 이었다.</p>
<p>API Gateway 적용 작업은 정말 공교롭게도 이전에 내가 어드민에서 내부 API를 처리하는 방법을 일원화하는 작업을 했었는데 그게 도움이 되어서 생각보다 빨리 끝낼 수 있었다. 그리고 구버전 어드민 이전에서는 반복되는 UI와 Form에 대해서 추상화된 구조를 정의한 뒤 작업하여서 그나마 순조롭게 진행할 수 있었다. 또 View에서 사용했던 테이블을 다시 추상화해서 Form 내부에서 활용해야 하는 상황이 있었는데 이 때 컴포넌트 구조에 대한 고민을 많이 할 수 있었다. 마지막으로 전품 전체에 대한 환경변수 처리에 대해서는 빌드타임과 런타임이 인프라 내에서 어떻게 처리되고 빌드타입에서 주입된 환경변수들이 Next.js내에서 어떤 식으로 Resolve되고, 실제로 빌드된 서버가 동작할 때 어떤 상황에서 빌드타임 환경변수와 런타임 환경변수를 참조하는지 명확하게 이해할 수 있었다. 그리고 같이 해결한 것 중 하나가 기존에 ECS가 아니라 EC2에 PM2로 서버를 띄우던 서비스가 있었는데 해당 프로젝트를 데브옵스 팀에서 ECS로 옮겨주셔서 거기서 내가 PM2를 걷어내는 작업을 진행했고 덕분에 기존에 갖고있던 환경변수 주입 타이밍 이슈로 SSG페이지를 생성하지 못했던 문제를 같이 해결할 수 있었다. 환경변수 관련 작업에서는 인프라와 컨테이너 전반에 대한 경험을 많이 할 수 있어서 좋았다.</p>
<hr>
<p>2022년 까지는 확실히 회사에서 얻을 수 있는 성장들이 많았는데 2023년은 개인의 노력으로 얻어야 하는 성장의 비율이 늘어났다. 그 과정에서 솔직히 방황하면서 보낸 시간들이 있었지만 그게 절대 낭비라고 생각하지는 않는다. 덕분에 엄청 많은 고민들을 할 수 있었고 무조건 필요한 시간이었으니 차라리 2년차 개발자일 때 깨달아서 다행이라고 생각한다. 물론 아직 진행중인 고민들도 엄청나게 많다. (진짜 엄청 많다) 그러므로 2023년은 문제정의의 해라고 생각하고 2024년은 그 문제들을 하나씩 격파하는 해가 될 것이라는 기대감을 가져봐야겠다. 아무튼 2024년, 멋지게 보내보자! 아뵤뵷~!</p>


2023년 회고

직관 주도 개발에서 벗어나기

<p>작년에 개발한 Drag and Drop으로 파일 첨부하기 기능을 구현하면서 생겼던 문제와 해결방법에 대해서 거의 1년이 다 되어가는 시점에서 다시 정리해서 올려본다. 사실 사내 발표를 위해 준비했던 자료를 글로 다시 풀어 작성하는 정도인데 지금 생각 해 보니 아쉬운 점이 많았던 결과와 과정이었던 것 같다. 그래도 그만큼 성장한 거라고 생각하기.</p>
<hr>
<p>채용 솔루션에 메시지 기능을 추가하면서 PO님께서 조심스럽게 요청사항을 추가하셨다. 드래그 앤 드랍으로 파일을 첨부할 수 있도록 해달라는 것인데 채팅 화면에 파일을 가져와서 떨구면 바로 파일이 첨부되는 기능이었다. 그 때 이미 SDK를 이용해서 메시지 보내기와 파일 보내기 기능이 모두 구현되어 있었고 재미있을 것 같아서 흔쾌히 수락했고 작업은 금방 끝날 것 같다고 말했다. 전에 MDN에서 본 <code>Drag and Drop API</code>를 사용하면 금방 구현할 수 있을거라고 생각했었기 때문이다.</p>
<p>지금까지 그 어떤 태스크 진행하면서도 생각대로 된 적이 없었음에도 왜 그런 안일한 생각을 했던걸까… 아무튼 당연히 생각대로 되지 않은 부분들이 너무 많았고 해결 과정을 공유해볼까 한다.</p>
<h3>Drag and Drop API</h3>
<p>말 그대로 브라우저 내에서 요소들을 Drag and Drop 할때의 동작을 제어해줄 수 있는 API이다. Draggable한 (image, anchor 등) 요소들이 Drag될 때 발생하는 이벤트들을 조작할 수 있으며 운영체제의 Drag and Drop API와도 연동이 되어서 외부로 파일을 끌어오는 기능에도 사용할 수 있다.</p>
<h3>구현</h3>
<p>기능 스펙은 매우 간단했다. 외부에서 파일을 드래그해서 채팅창 영역으로 끌고오면 첨부가 될 것을 알리는 오버레이로 띄우고 그 상태에서 드랍을 하게되면 파일을 전송해준다.</p>
<p><a href="/images/dnd_example.gif" target="_blank"><img src="/images/dnd_example.gif" alt=""></a></p>
<p>처음에는 아래 코드 수준으로 간단하게 구현할 수 있을거라고 기대했다.</p>
<pre><code class="language-tsx"><span class="hljs-keyword">const</span> [enteredDrag, setEnteredDrag] = <span class="hljs-title function_">useState</span>(<span class="hljs-literal">false</span>);

<span class="hljs-keyword">return</span> (
  <span class="language-xml"><span class="hljs-tag">&lt;<span class="hljs-name">ChatContainer</span>
    <span class="hljs-attr">onDragEnter</span>=<span class="hljs-string">{()</span> =&gt;</span> {
      setEnteredDrag(true);
    }}
    onDragLeave={() =&gt; {
      setEnteredDrag(false);
    }}
    onDrop={() =&gt; {
      // ...
    }}
  &gt;
    {enteredDrag &amp;&amp; <span class="hljs-tag">&lt;<span class="hljs-name">AttachmentOverlay</span> /&gt;</span>}
    <span class="hljs-tag">&lt;<span class="hljs-name">Chat</span> /&gt;</span>
  <span class="hljs-tag">&lt;/<span class="hljs-name">ChatContainer</span>&gt;</span></span>
);
</code></pre>
<p>그러나 생각한대로 overlay가 노출되지 않았다. 이유는 두가지가 있었는데 첫번째로는 overlay가 화면을 가리면서 dragLeave와 dragEnter이벤트가 무한 반복으로 발생하는 것이었다. overlay컴포넌트가 마운트 되면서 기존에 dragOver되어 있던 element에서 dragLeave가 발생하면서 enteredDrag가 <code>false</code>로 처리되고 다시 overlay아래쪽에 있던 element에서 dragEnter가 발생한다. 그러면서 enteredDrag는 다시 <code>true</code>가 되면서 이벤트가 무한반복하게 된다.</p>
<p>두번째로는 drag이벤트가 모두 버블링으로 이벤트가 전파되기 때문에 <code>ChatContainer</code>안에서 발생하는 모든 이벤트에 대해서 이벤트 핸들러가 동작하게 되어 기대하는 동작이 이뤄지지 않는 것이었다.</p>
<p>아무튼 특정 경계에서만 dragEnter와 dragLeave 이벤트 핸들러가 동작할 수 있도록 해야했다. 처음 시도했던 방법은 이벤트가 발생한 <code>target</code>과 <code>currentTarget</code>이 일치할 때만 이벤트가 발생하도록 했는데, 경계에 겹치는 요소가 있으면 거기서 문제가 발생했다. 경계에 겹치는 요소에서 dragEnter가 발생하면 <code>target</code>과 <code>currentTarget</code>이 다르기 때문에 의도대로 동작하지 않았다.</p>
<h4>경계 정하기</h4>
<p>특정 경계를 넘어서 들어오는 dragEnter 이벤트에서만 동작하도록 하기 위해선 어떻게 해야할까? 결론적으로 <code>relatedTarget</code>을 통해서 분기를 나눌 수 있었다. <code>relatedTarget</code>은 MouseEvent객체의 속성 중 하나인데 커서가 들어오거나 나갈 때의 대상이 되는 요소를 담고 있다. (참고: <a href="https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent/relatedTarget">MDN - relatedTarget</a>) 즉 dragEnter의 <code>relatedTarget</code>이 <code>ChatContainer</code>에 포함(contain)되지 않는다면 <code>ChatContainer</code>를 기준으로 밖에서 진입한 dragEnter 이벤트라는 것을 알 수 있다. dragLeave이벤트도 동일하게 조건을 넣어줄 수 있다.</p>
<p>아래 이미지처럼 event의 <code>relatedTarget</code>이 경계로 지정한 요소에 contain 되고 있다면 경계에서 발생한 이벤트가 아니기 때문에 무시해버리면 된다.</p>
<p><a href="/images/2023-05-21-14-00-15.png" target="_blank"><img src="/images/2023-05-21-14-00-15.png" alt="relatedTarget에 맞춰서 이벤트 동작의 여부를 결정하는 다이어그램"></a></p>
<p>위 방법으로 다음과 같이 코드를 작성해서 처리할 수 있었다.</p>
<pre><code class="language-tsx"><span class="hljs-keyword">const</span> [enteredDrag, setEnteredDrag] = <span class="hljs-title function_">useState</span>(<span class="hljs-literal">false</span>);

<span class="hljs-keyword">const</span> <span class="hljs-title function_">setEnterDragWithBoundary</span> = (<span class="hljs-params">
  e: React.DragEvent&lt;HTMLDivElement&gt;,
  value: <span class="hljs-built_in">boolean</span>
</span>) =&gt; {
  <span class="hljs-keyword">if</span> (
    relatedTarget <span class="hljs-keyword">instanceof</span> <span class="hljs-title class_">HTMLElement</span> &amp;&amp;
    <span class="hljs-comment">// Container에 포함된다면 return</span>
    (e.<span class="hljs-property">currentTarget</span>.<span class="hljs-title function_">contains</span>(relatedTarget) )
  ) {
    <span class="hljs-keyword">return</span>;
  }

  <span class="hljs-title function_">setEnterDrag</span>(value);
  };

<span class="hljs-keyword">return</span> (
<span class="language-xml"><span class="hljs-tag">&lt;<span class="hljs-name">ChatContainer</span>
  <span class="hljs-attr">onDragEnter</span>=<span class="hljs-string">{()</span> =&gt;</span> {
    setEnterDragWithBoundary(true);
  }}
  onDragLeave={() =&gt; {
    setEnterDragWithBoundary(false);
  }}
  onDrop={() =&gt; {
    // ...
  }}
&gt;
  {enteredDrag &amp;&amp; <span class="hljs-tag">&lt;<span class="hljs-name">AttachmentOverlay</span> /&gt;</span>}
  <span class="hljs-tag">&lt;<span class="hljs-name">Chat</span> /&gt;</span>
<span class="hljs-tag">&lt;/<span class="hljs-name">ChatContainer</span>&gt;</span></span>
</code></pre>
<p>이렇게 처리해서 drag이벤트가 Container의 밖에서 안으로 들어올때나 안에서 밖으로 나갈 때만 동작하도록 할 수 있었다.</p>
<p>그러나 이렇게해서 끝이 났다면, 블로그 포스팅까지는 하지 않았을 것이다… 새로운 시련이 생겼는데 바로 사파리에서 문제가 발생했다.</p>
<h3>사파리(Safari) 이슈</h3>
<p>사파리에서는 drag이벤트에서 <code>relatedTarget</code>이 모두 <code>null</code>로 평가되는 치명적인 이슈가 있었다. 찾아보니 굉장히 오래된 <a href="https://bugs.webkit.org/show_bug.cgi?id=66547">버그</a>였고, 2011년에 보고 된 이후로 지금까지도 방치되고 있는 듯 하다. IE가 떠나고 나니 이제 사파리가 그 자리를 대신 하는듯한 느낌…^^ 그렇다고 해서 사파리를 배제할 수는 없었다… 다시 생각해 봐도 <code>relatedTarget</code>을 사용하지 않고 구현할 수 있는 방법은 떠오르질 않았고, 결국에는 ref를 사용해서 <strong><code>relatedTarget</code>을 직접 구현하는</strong> 방식으로 진행했다.</p>
<h4><code>relatedTarget</code>을 직접 구현</h4>
<p><code>relatedTarget</code>을 직접 구현하기 위해서는 dragEnter, dragLeave일 때 참조하는 <code>relatedTarget</code>이 각자 다른 방식으로 구현되어야 했다. 먼저 dragEnter일 때는 간단하게 구현이 가능했다. 아래처럼 마지막으로 dragLeave가 발생할 때 <code>target</code>을 <code>relatedTarget</code>에 할당해주면 된다. 그럼 그 다음 바로 발생하는 dragEnter이벤트의 <code>relatedTarget</code>이 마지막으로 dragLeave가 일어난 element를 참조한다.</p>
<p>dragEnter의 relatedTarget이 결정되고 참조되는 과정을 이미지로 표현하면 아래와 같다.</p>
<p><a href="/images/2023-05-21-16-38-45.png" target="_blank"><img src="/images/2023-05-21-16-38-45.png" alt="A에서 B로 드래그 이벤트가 이동하면서 ref를 사용하여 만든 임의의 relatedTargetRef을 결정하고 참조하는 방법을 보여주는 다이어그램, A에서 DragLeave이벤트가 발생하면 relatedTargetRef에 이벤트의 target을 할당하고 B에서 DragEnter이벤트가 발생하면 relatedTargetRef을 참조하여 relatedTarget을 찾는다."></a>
비교적 간단하게 dragEnter 이벤트의 <code>relatedTarget</code>을 결정할 수 있었다.</p>
<p>그러나 dragLeave이벤트의 <code>relatedTarget</code>을 결정하는 방법은 바로 떠오르지 않았다. dragEnter가 발생하는 요소를 참조해야 하는데 dragLeave이벤트가 발생하는 시점에서 외부 맥락에서는 어떤 요소로 이동할지를 알 수 없었기 때문이다. 즉 내가 갈 곳을 내가 나가는 시점에서 바로 알 수 있는 방법이 없다.</p>
<p><a href="/images/2023-05-21-16-51-07.png" target="_blank"><img src="/images/2023-05-21-16-51-07.png" alt=""></a></p>
<p>이 문제를 해결하기 위해서 꽤나 많은 고민을 했는데, 결국에는 방법을 찾을 수 있었다. 바로 <code>document.elementFromPoint</code>메서드를 사용하는 것이다. 아마 바로 이해되는 사람도 있을테고 그걸로 어떻게? 할 수도 있는데, 아주 원초적이고 단순한 방법으로 다음으로 이동할 요소를 가져올 수 있었다.</p>
<p><code>elementFromPoint</code>메서드는 특정 위치에 존재하는 요소를 가져오는 메서드이다. 그리고 dragLeave가 발생한 시점의 마우스 좌표에 있는 요소는 dragLeave가 발생한 이후 dragEnter가 발생하는 요소와 동일할 것이다. 그렇다면 dragLeave가 발생하는 시점의 마우스 좌표를 가져와 <code>elementFromPoint</code>로 요소를 가져오면, 해당 요소가 dragLeave의 <code>relatedTarget</code>으로 사용될 수 있다는 것이다.</p>
<p>그리하여 아래와 같이 dragLeave와 dragEnter의 <code>relatedTarget</code>을 명령형으로 결정해 줄 수 있게되었다.</p>
<p><a href="/images/2023-05-21-17-09-13.png" target="_blank"><img src="/images/2023-05-21-17-09-13.png" alt=""></a></p>
<pre><code class="language-tsx"><span class="hljs-keyword">const</span> [enterDrag, setEnterDrag] = <span class="hljs-title function_">useState</span>(<span class="hljs-literal">false</span>);
<span class="hljs-keyword">const</span> relatedTargetRef = useRef&lt;<span class="hljs-title class_">HTMLElement</span> | <span class="hljs-literal">null</span>&gt;(<span class="hljs-literal">null</span>);

<span class="hljs-keyword">const</span> <span class="hljs-title function_">setEnterDragWithBoundary</span> = (<span class="hljs-params">
  e: React.DragEvent&lt;HTMLDivElement&gt;,
  value: <span class="hljs-built_in">boolean</span>
</span>) =&gt; {
  <span class="hljs-keyword">const</span> relatedTarget =
    <span class="hljs-comment">// e.relatedTarget이 없다면, enter일 때는 relatedTargetRef를, leave일 때는 elementFromPoint을 통해서 relatedTarget을 가져옴</span>
    e.<span class="hljs-property">relatedTarget</span> ||
    (value
      ? relatedTargetRef.<span class="hljs-property">current</span>
      : <span class="hljs-variable language_">window</span>.<span class="hljs-property">document</span>.<span class="hljs-title function_">elementFromPoint</span>(e.<span class="hljs-property">clientX</span>, e.<span class="hljs-property">clientY</span>));

  <span class="hljs-keyword">if</span> (
    relatedTarget <span class="hljs-keyword">instanceof</span> <span class="hljs-title class_">HTMLElement</span> &amp;&amp;
    e.<span class="hljs-property">currentTarget</span>.<span class="hljs-title function_">contains</span>(relatedTarget)
  ) {
    <span class="hljs-keyword">return</span>;
  }

  relatedTargetRef.<span class="hljs-property">current</span> = <span class="hljs-literal">null</span>;
  <span class="hljs-title function_">setEnterDrag</span>(value);
};

<span class="hljs-keyword">return</span> (
  <span class="language-xml"><span class="hljs-tag">&lt;<span class="hljs-name">ChatContainer</span>
    <span class="hljs-attr">onDragEnter</span>=<span class="hljs-string">{e</span> =&gt;</span> {
      setEnterDragWithBoundary(e, true);
    }}
    onDragLeave={e =&gt; {
      // dragLeave를 할 때 dragEnter할 때 참조할 relatedTargetRef를 결정
      if (e.target instanceof HTMLElement) {
        relatedTargetRef.current = e.target;
      }
      setEnterDragWithBoundary(e, false);
    }}
    onDrop={() =&gt; {
      // ...
    }}
  &gt;
    {enteredDrag &amp;&amp; <span class="hljs-tag">&lt;<span class="hljs-name">AttachmentOverlay</span> /&gt;</span>}
    <span class="hljs-tag">&lt;<span class="hljs-name">Chat</span> /&gt;</span>
  <span class="hljs-tag">&lt;/<span class="hljs-name">ChatContainer</span>&gt;</span></span>
);
</code></pre>
<p>기본적으로는 <code>relatedTarget</code>을 참조하고 만약 <code>relatedTarget</code>이 <code>null</code>이라면, dragEnter의 상황에서는 직접 정의한 <code>relatedTargetRef</code>를 참조하도록 하고 dragLeave의 상황에서는 <code>elementFromPoint</code>으로 가져온 요소를 참조하도록 하여 구현하게 되었다.</p>
<p>물론 이후에도 몇가지 예외처리가 필요했지만, 이렇게 일단락하여 기능을 구현하여 배포할 수 있었고 그러면서 발생했던 가장 골치아팠던 문제들을 해결했던 과정을 정리해봤다.</p>
<hr>
<h3>회고</h3>
<p>당시에는 이 문제를 해결했음에 성취감이 굉장했다. 불가능할 것 같은 상황을 내가 알고있는 지식을 활용해서 하나씩 해결해 내는 과정에서 느끼는 카타르시스는 '이 맛에 개발자 한다’는 느낌을 낭낭하게 받을 수 있게 해줬다. 주니어는 그렇다. 뭔가 복잡한 문제를 역량을 통해 해결하는 것을 통해서 성장한다고 느낀다. 그런 관점에서는 좋았지만 이제 와서 생각해 보면 나는 이런 해결 방법이 <strong>좋지 못했다</strong> 라고 회고한다. 개발역량을 증명하는 것과 좋은 코드를 쓰는 것은 비슷하면서도 다른 부분이 많은 것 같다. 내가 알고있는 다양한 API들과 메서드들을 잘 사용해서 어려운 문제를 해결해내는 것은 개발자로서 가져야 하는 소양임은 분명하지만 그게 좋은 방법인지에 대한 고민도 함께 해야하는 것이다. 일단 위 코드는 실제로 다양한 예외처리와 함께 구현되었을 때 한 눈에 이해하기가 많이 어렵다. 만약 누군가 이 코드를 수정해야 하고 나에게 설명을 요구한다면 나는 꽤나 민망한 상황을 마주하게 될 것 같다는 생각이다.</p>
<p>어떤 동료분이 '차력쇼’라는 표현을 자조적으로 사용했었다. 그러니까 이렇게 어떤 문제를 해결하기 위해서 A to Z로 명령형인 코드를 짜는 과정을 위트있게 표현한 것인데 나는 이런 문제해결 방식이 말 그대로 차력쇼가 아니었을까 생각한다. 만약 <strong>그 어떤 라이브러리나 마크업 구조를 변경하지 않고</strong>라는 전제가 있는 상태로 파일 첨부 기능을 구현해야 하는 상황이었다면 최선을 다했다고 생각하겠지만, <strong>유지보수 가능한 프로덕션 레벨의 서비스의 코드</strong>를 작성해야 하는 상황에서 이렇게 한 땀 한 땀 구현한 건 그냥 주니어의 객기가 아니었을까… 싶은 아쉬움이 남는다. 하지만, 지금와서 이런 회고를 할 수 있다는 게 어느정도는 성장을 통해 가질 수 있는 시야라고 생각하기도 하기 때문에 내가 잘 가고있구나 라는 생각도 든다.</p>
<p>다음에는 ‘이렇게 차력쇼를 할 수 있겠군… 하지만 좀 더 좋은 방법을 찾아볼까?’ 라는 식으로 문제를 세련되게 해결해보고 싶다.</p>


Drag and Drop을 활용한 파일첨부 기능 개발기

<p>개발자로 일을 시작한지 1년 정도가 지났다. 그동안 드라마앤컴퍼니의 컨텐츠 크루와 커리어 크루에 있으면서 정말 다른 성격의 두 가지 제품을 함께 만들며 느낀 점과 앞으로 성장하고 싶은 방향 들을 적어내려가 보려고 한다.</p>
<p>작년의 나와 비교했을 때 뭐가 달라졌을까? 주니어 개발자들이 모두 갖고있는 걱정과 강박이 <strong>성장</strong>이 아닐까 싶다. 일년 전 보다 더 나은 코드를 짤 수 있고 일년 전 보다 더 나은 설계를 할 수 있게 되기를 바라는 것이 아직도 성장해야 하는 입장에서 당연하게 바라는 것이겠지만, 내가 좋은 개발자가 되기 위해 그냥 계속 정진하면 따라오는 게 성장이라는 점 또한 말하지 않아도 지당하다. 그러면 내가 생각하는 <strong>좋은 개발자</strong>가 무엇인지에 대한 정의가 먼저 되어야 내가 바라는 성장이 따라올 것 이다.</p>
<h2>좋은 개발자?</h2>
<p>그래서 내가 생각하는 좋은 개발자는 무엇일까 생각해봤다. 1년 정도 개발자로 일을 하면서 느낀 게 있다면, 스스로 개발자라고 정의하기 전에 제품을 만드는 사람이라고 정의하고 싶다는 것이다. 제품은 반드시 사용되어야 가치가 있을테고 때문에 사용자가 가장 중요하다. 그리고 좋은 제품을 만들 때 필요한 다양한 리소스 중에서 나는 사용자의 피부에 닿는 인터렉션을 담당하는 부분을 만드는 개발자이다. 그런 제품을 만들기 위해서는 UX에 대한 이해와 사용자가 불편을 느끼는 지점들을 잘 파악해야 하고, 그런 문제들을 개발이라는 도구를 통해서 풀어나갈 수 있어야 한다.</p>
<h3>내가 되고싶은 좋은 개발자</h3>
<p>그런 관점에서 좋은 제품을 만드려는 의지는 결국 좋은 개발자가 되는 방향과 연결된다. 당연하게도 사용자는 빠르게 화면을 보고 지체없이 원하는대로 빠르게 작동하기를 원한다. 그러기 위해서는 사용자에게 우리의 제품이 전달되는 유일한 통로인 네트워크에 대해서 잘 이해하고 있어야 하며 코드가 어떤 환경에서도 빠르고 문제없이 동작 할 수 있도록 성능과 안정성을 생각하며 작성해야 한다. 그리고 필요한 기능을 제공하기 위한 API들을 잘 이해하고 있어야 한다. 또한 사용자가 원하는 것이 무엇인지 빠르게 확인하고 피드백을 반영하기 위해서는 생산성 또한 아주 중요하다. 그러기 위해서는 변화에 유연한 설계와 기능과 의존성의 분리 등 신경써야 하는 것이 정말 많아진다. 결국에는 좋은 제품을 만드는 개발자가 되기 위해서 필연적으로 개발적인 역량이 필요한 것이다.</p>
<p>좋은 개발자가 되기 위해 좋은 개발자가 되는 건 어려운 것 같다. 영어를 잘 하기 위해 영어공부를 하는 것이 동기부여가 잘 되지 않는 것 처럼. 올 해는 막연히 ‘좋은 개발자가 되고싶다.’ 라고 생각하기 보다는, <strong>사용자에게 훌륭한 경험을 주는 제품을 만들 수 있는 좋은 개발자</strong>가 되어보려는 방향을 명확히 할 수 있었던 한 해가 된것 같다.</p>
<h3>아쉬운 점</h3>
<p>아쉬운 점도 확실한데, 제품을 만드는 사람으로써의 개발자, 내가 되고싶은 좋은 개발자에 대한 정립은 잘 해낸 것 같지만, 정작 기술적인 성장에 있어서는 많이 더뎠던 것 같다. 부트캠프에서 주 5일 하루 12시간씩 공부할 때와 비견하면 안되겠지만, 그럼에도 아쉬운 건 어쩔 수 없는 것 같다. 매번 좋은 아티클들을 읽어보려고 북마크 해두고 있지만 시간내어 읽는 것이 쉽지가 않다. 네트워크나 인프라에 대한 지식도 좀 더 깊이있게 배워야 하는데 아직까지 회사에서 실제로 하는 업무에 엮이지 않은 영역에 대한 공부를 적극적으로 하지 못하고 있는 것 같아서 아쉽다. 이 부분에 대한 해소도 올해 다양한 방법으로 시도해 볼 생각이다.</p>
<h2>앞으로</h2>
<p>아무튼 2022년은 내가 처음 개발자로써 제품에 기여해보고 좋은 개발가 되기위해 가야할 방향을 정하는 소스를 입력받는 한 해가 되었다면 2023년은 좀 더 능동적인 학습을 통해서 그 소스들을 갖고 추진력을 만들기 시작하는 해가 되었으면 한다. 개발자 커리어가 늦었다면 늦었다고 할 수 있지만 그럴수록 조급하지 않고 그 전에 내가 쌓은 인사이트와 경험들을 어떻게 더 녹여서 시너지를 낼 수 있을지 고민하면서 성장하고 싶다.</p>
<h3>독서</h3>
<p>처음에 기능개발을 하면서 코드를 짤 때 의존성을 적당히 분리하고, 적당히 변경할 수 있도록하여 당장 돌아가는 코드만 짜도 뿌듯했었는데, 점점 협업하는 사람들이 많아지고 내가 짠 코드가 다양한 곳에 영향을 줄 수 있게 된다는 것을 느끼면서 코드에 대한 책임감이 늘어갔다. 그에 따라서 코드의 맥락적인 구조나 설계, 디자인패턴, 방법론등에 대한 고민을 많이 하게 되었는데 그런 부분들을 책을 통해 해소할 수 있지 않을까 싶다. 지금까지 개발에 대한 방법론이나 철학에 대한 책이 얼마나 도움이 될까 싶은 의문이 있었어서 굳이 시간투자를 하지 않았는데, (사실 저런 생각을 할 때는 책을 읽었어도 별 도움이 되지 않았을 것 같다.)이제는 내가 고민하는 분명한 지점이 있고 해소하고 싶은 것들이 있으니 한 권씩 읽고 느낀 점들을 블로그에 올려볼 생각이다.</p>
<h3>사이드 프로젝트</h3>
<p>이건 진짜… 사실 2022년에도 계속해서 진행하던 사이드 프로젝트가 있었는데 솔직히 의욕부족으로 인해 제대로 진행하지 못했었다. 백엔드 개발까지 함께 하려니까 힘이 부치기도 했고… 작년에 못했던 걸 올 해라고 갑자기 할 수 있지는 않을 것 같지만, 일단 기능을 더 축소하더라도 배포정도는 해봐야하지 않을까?! 사실 초반에 너무 힘을 주고 시작한 게 이렇게 의욕상실까지 오지 않았을까 싶다. 그래서 가능하면 최소기능으로 배포 한 다음 천천히 기능을 붙여보는 방법으로 방향을 전환해볼까 생각중이다. 디자인도 내가 해보겠다고 피그마 파일 만들고 했었는데, 정말… 열정을 불태우는데에 모든 연료를 써버린 것 같다. 2023년 리필된 열정을 이번에는 효율적으로 사용해보자.</p>
<h3>코어크루</h3>
<p>그리고 1월 16일 부터는 컨텐츠크루, 커리어크루를 지나 코어크루에서 일하게 될 것 같다. 근 일년동안 회사가 투자유치 이후 빠르게 성장해야하는 과정에 있다보니 조직구조의 변화가 많이 있었다. 덕분에(?) 다양한 도메인의 제품을 모두 경험할 수 있었고, 그 베이스를 토대로 코어크루에서 리멤버 제품 전체에 적절하게 기여할 수 있지 않을까 기대된다. 사실 나는 제품을 함께 만들어 나가는 것에 큰 만족을 느낀다고 생각했었기 때문에 커리어에 남아있을까 했었는데, 그렇다고 내가 제품 없이 다른 방향성으로 기여하는 방식으로 일해 본 적도 없으니까. 이번에 해보고 판단해볼 생각이다. 그리고 확실히 제품에 대한 바인딩이 없는 작업들이 많을테니까 지금까지와는 다른 방향으로 기술적 고민들이 있지 않을까 기대하는 부분도 있다. 그리고 인프라…! 진짜 인프라쪽도 많이 공부해보고 싶다. 아쉬운 점이라면 지금까지 컨텐츠크루와 커리어크루를 계속 함께 일했던 PO님과의 생이별이 있었다… 일을 함에 있어서도 서로 이해도가 있고 인간적으로도 편한 부분이 있었어서 참 좋은 파트너다 라고 생각했지만 이번 조직개편때는 함께하지 못하게 되었다. 결국 다양한 사람들과 빠르게 적응하는 것도 역량이니까… 서로 홀로서기 해보자고 하며 응원하며 보내줬다(?)</p>
<p>하나의 회사를 다니면서 이렇게 다양한 경험을 쌓아갈 수 있는 건 진짜 행운이라고 생각한다. 일년 동안 세 번 도메인을 바꿔가면서 일한다? 경험에 목마른 주니어 개발자에겐 최고의 환경 아닐까? 물론 한 도메인에 전문성을 갖는 것도 좋지만 아직은 다양한 방향에 대해서 고민해볼 수 있는 시점에서는 더 많은 인풋을 가져올 수 있는 환경이 좋다고 생각한다. 아무튼 올해는 코어크루에서 폭풍성장 해보자! 파이팅!</p>


2022년 회고

<p>뭔가 매 달 회고를 쓰고 싶은 마음이었지만, 그게 처음부터 바로 할 수 있을만큼 쉬운 일은 아니었음을 깨달았다. 아무튼 이것도 배움이라고 생각해버리기… (머쓱)</p>
<h2>돈 버는 프로덕트</h2>
<p>컨텐츠 크루에서 커리어 크루로 옮기고 가장 달라진 것 중에 하나는 프로덕트가 회사의 매출에 큰 비중을 차지하고 있었다는 것. 그리고 모든 사용자가 유료 사용자라는 것. 때문에 모든 의사결정이 매출에 영향을 주고받을 수 밖에 없다는 것이다. 컨텐츠에서 커리어로 옮긴 이유는 하나의 제품을 애정을 갖고 만들고 싶었던 마음이 컸기 때문인데 커리어 제품은… 뭔가 내가 만드는 느낌은 전혀 아니었다. 뭔가… 다양한 이해관계가 한 곳에 모여져서 만들어지는 하나의 집합체(?) 같은 느낌으로 다가왔고 그래서 처음에는 적응하기 어려웠다. 그동안 매출과 관련없는 제품을 만드는 것이 얼마나 온실안의 화초같은 느낌으로 일하고 있었는지도 느꼈다. 이게 당연히 좋고 나쁘고의 문제는 아니고 일하는 지금까지와는 다른 방식으로 일함에 있어 적응이 필요했다는 이야기이다.</p>
<p>같은 회사 내에서 제품의 성격이 이렇게 다를 수 있다는 것도 재미있고 막상 이제 이런 특징을 받아들이고 나니 이런 비즈니스적인 의존성이 강한 제품을 만들어나감에 있어 다른 팀과의 커뮤니케이션이 얼마나 중요한지 등 좀더 사업적인 영역을 생각 해 볼 수 있어서 나에게는 너무 좋은 경험이 되고있다. 아무튼 뭐든 피할 수 없다면 즐기는 거다…! 이런 챌린지가 오히려 좋다는 것도 느끼는 중. 개발자가 성장하는 방법중에 하나라고 생각하고 이해를 기반으로 좋은 제품을 만들고 문제를 찾고 해결하는 사이클을 온전히 경험할 수 있음에 감사한다.</p>
<p>아쉬운 것이라면 내가 아직 맡은 제품의 도메인에 대한 이해가 부족하기 때문에 의견을 말할 때 조금씩 머뭇거림이 생기기는 한다. 구직자와 구인자, 그리고 그 와중에도 헤드헌터와 리크루터 적극적 구직자와 소극적 구직자에 대한 persona를 형성해냄에 있어 경험이 부족하기 때문인 것도 클 것 같다. 요런 부분들은 내가 이직을 많이 해보지 않으면, 혹은 채용에 직간접적으로 개입하지 않으면 경험해보기 어려운 부분이기 때문에 어떻게 채워야 할 지 고민해봐야 할 것같다. (커뮤니티는 내가 커뮤니티 이용자 입장에서 생각해 보기가 쉬웠기 때문에 좀 더 적극적이고 자신감 있게 의견을 낼 수 있어서 좋았다) 일단은 기획단에서 사용자 인터뷰를 진행하고 있기 때문에 해당 인터뷰들을 참고하며 노력중.</p>
<h2>메시지 기능</h2>
<p>10월부터의 가장 큰 이슈는 메시지 기능 개선이었는데, 우리가 채팅 서버를 만들기에는 리소스도 부족하고 시행착오가 쉽게 용납되지 않는 프로덕트이다 보니까 안전하게 외부 채팅 SDK를 사용해서 구현하기로 했다. 다행히 UIKit도 함께 제공했기 때문에 조금 빠르게 만들 수 있을거라고 기대했는데, 전혀 아니었다. 물론 UIKit 덕분에 적은 시행착오로 태스크를 진행할 수 있었지만 UIKit 자체가 유연하지 못하게 설계된 부분이 많았고 (우리가 기능을 거의 다 커스텀해서 사용했기 때문에 더 힘들었다.) 솔루션의 정책상 구현하기 어려운 부분들을 온갖 수단을 동원해서(?) 돌아갈 수 있도록 하는 일들이 많았다. 정말정말 다양한 문제들에 부딪혔었는데 다행히 모두 방법을 찾았다. 정말 '문제 해결 능력’을 최대한 발휘했던 태스크… 그리고 다양한 묘수들을 내가 찾아내기도 했어서 더 뿌듯했다.</p>
<p>곧 해당 태스크에 대한 회고를 진행할 예정인데 할 이야기가 많을 것 같다. 먼저 개발적으로 POC를 너무 얕게 하고 시작했다. 워낙 유명한 채팅 SDK이다 보니까 당연히 다 될 것이라고 생각했던 기능들이 제한되는 경우도 많았고, 문서에 숨겨놓은 듯이 존재하는 제약조건들을 개발 중간에 발견하면서 개발일정이나 방향에 계속해서 변수가 생겼었다. 또 구현에 앞서 SDK 공급업체와도 충분한 논의를 거쳐서 좀 더 SDK에 이해가 깊은 사람들과 이야기 해 볼수 있었는데 개발일정이 급하다는 이유로 해당 과정을 생략했던 부분 (이 부분도 개발 막바지 쯤에 깨달았다)도 아쉬움이 크다. 마지막으로는 예외처리에 대해서 크게 신경쓰지 못한 부분도 배포 이후 CS이슈 해결을 힘들게 만들었다. 유료로 제공하는 프로덕트인 부분에서 기능 장애 CS는 치명적이고 빠르게 해결해야 한다. 하지만 SDK쪽 디버깅에 대한 대비를 제대로 하지 못해서 (모니터링 솔루션이 있었지만 내가 잘 파악하지 못했기 때문에 활용을 잘 못했던 것도 너무 아쉽다) 장애 대응을 빠르게 하지 못했다. 그리고 이게 경험의 차이라는 것도 다시금 느꼈다. 만약 내가 다음에 이런 CS이슈가 예상되는 태스크를 한다면 예외처리와 디버깅에 있어서 좀 더 신경을 쓰지 않을까…</p>
<p>그럼에도 스스로 잘 했다고 생각한 건, view영역을 최대한 UIKit의 의존성을 제거하기 위해 새롭게 개발했던 부분이 나중에 개발 효율성에 긍정적으로 작용했다는 점 정도… 사실 아쉬움이 너무 많은 태스크이기도 했지만 그만큼 배울 게 많았던 태스크라고 생각하려고 한다.</p>
<h2>yarn berry</h2>
<p>팀원중에 한 분이 yarn berry를 다양한 레포에 적용하기 시작했다. 나는 솔직히 yarn berry에 대해서 긍정적으로 생각하지는 않는다. 아직 생태계가 정착한 느낌이 들지는 않고, 기존에 node_modules를 통한 의존성 관리 방식에 분명 문제가 있기는 하지만 그게 생산성에 크게 치명적인가를 생각 해 보면 그렇지도 않은 것 같고 오히려 yarn berry를 사용하면서 생기는 문제들에 대한 트러블슈팅에 리소스를 할애해야 한다면 생산성에 악영향이 있을 것 같기 때문이다. 특히 <code>'토스에서 쓰니까 좋은 것 아니야?'</code> 라는 느낌의 접근은 정말 경계해야 한다고 생각했다. 아무튼 그런 생각을 갖고 있는 상황에서 해당 팀원분께서 yarn berry 관련해서 발표하는 자리를 만들어주셔서 이야기를 들어봤는데 현재 패키지 매니저의 문제점 부터 이런 것들을 yarn berry가 어떻게 해결했는지 등을 상세히 설명해 주셨고 몇 프로젝트에서는 확실히 유의미하게 빌드속도가 빨라진 것을 볼 수는 있었다. 그래서 나도 생각이 조금 변한 부분이 있었는데 그럼에도 아직까지는 위험요소들이 있다고 생각이 들었고 커리어 제품군에서는 조금 더 시간을 들여 지켜본 이후에 적용해 보기로 했다.</p>
<p>개발자라면 새로운 기술에 계속해서 열린마음(?)으로 받아들이고 빠르게 적용해봐야 한다고는 하지만, 나는 그게 프로덕션 레벨이라면 너무 보수적으로 접근하게 되는 것 같다. 이제 2년차 완전 주니어인데 벌써 이렇게 소극적으로 신기술을 대하는 게 안좋은 것 같으면서도 제품을 만드는 입장에서는 이런 새로운 기술의 도입이 염려스러운 건 또 어쩔 수 없는 것 같다.</p>
<h2>1년</h2>
<p>11월 22일은 입사 1주년이었다. 처음 입사할 때는 사실 아주 큰 기대는 하지 않았었는데 다니면서 느끼는 건 우리 회사가 외부에 알려진 것에 비해 굉장히 좋은 조직문화를 갖고 있고 정말 전망이 좋은 제품을 정말 좋은 사람들과 만들고 있다는 것들을 느낀다. 최근에는 동료분 중에 한 분이 밖에서 회사 얘기를 하면서 회사나 대표 욕을 하지 않는 회사는 여기가 처음이라는 말을 듣고는 더 그렇게 느끼기 시작한 것 같다. 물론 사람마다 다르겠지만 일단 나에게는 굉장히 잘 맞는 회사라는 것은 확실하다. 원래는 개발자가 되면 1~2년 정도씩 다니면서 회사를 옮겨서 다양한 곳에서 일해보려 했었는데, 드라마앤컴퍼니 내에서도 충분히 다양한 경험들을 쌓으면서 개발자로서, 제품을 만드는 사람으로서 두 마리 토끼를 잡으면서 성장할 기회가 많다는 것을 느꼈다. 또 정말 최고의 복지는 좋은 동료들 이라는 것도 실감중… 인간이 5명 이상이 모이면 반드시 한 명은 쓰레기라는 말이 있는데, 그게 맞는 말이라면 아무래도 내가 그 쓰레기를 담당하고 있는 게 분명한 것 같다. 나도 이전보다 회사에서 많이 밝아진 부분이 있어서 (물론 내가 스스로 노력한 부분도 많았지만) 인간적인 성장도 함께 할 수 있는 듯 하다.</p>
<p>회사 사람들과는 취미활동도 많이 공유하고 퇴근하고는 클라이밍, 주말에는 등산이나 배드민턴도 자주 치러 다녀서 주변에서 <code>'회사 사람들이랑 정말 잘 지내는 것 같다'</code>는 이야기를 많이 듣는다. 아무튼 나는 지금 회사 대만족하면서 다니는 중. 혹시 나랑 같이 클라이밍 가고 싶으면 <a href="https://hello.remember.co.kr/">여기</a>서 지원하길 ^^</p>
<hr>
<p>아무튼 이렇게 11월까지의 밀린 회고를 해봤다. 곧 연말이고 해서 또 2022년의 회고를 작성할 <strong>예정</strong>이다. 또 그전에 Drag and Drop으로 파일 첨부하기 기능을 만들면서 겪은 트러블 슈팅들을 포스팅 해볼 생각이다.</p>


22년 9월 ~ 11월 회고

<blockquote>
<p><strong>* 2023. 2. 12 이 포스팅은 잘못된 정보를 다루고 있습니다. 올바른 내용을 별도로 첨부해두겠습니다.</strong></p>
</blockquote>
<p>최근 iOS 웹뷰에서 파일 다운로드를 동작시키기 위한 태스크를 진행하면서 막혔던 부분이 있었다. 웹뷰에서는 파일 다운로드가 열리지 않기 때문에 사파리 창을 띄워서 다운로드를 발생시켜야 했었는데 아무리 다운로드 버튼을 눌러도 새 창이 뜨지 않는 문제가 있었다. 고민하다가 사파리 브라우저에서 해당 페이지의 버튼을 눌러보니 팝업 차단으로 막히고 있었던 것… 웹뷰에서는 팝업이 차단 될 뿐 차단 안내가 되지 않아서 몰랐던 것이었다.</p>
<h3>왜 차단될까?</h3>
<p>브라우저에서 click 이벤트를 통해서 동작하는 open메서드는 신뢰할 수 있는 이벤트로 판단하고 팝업차단 없이 동작한다고 알고있었다. 그런데 찾아보니, 해당 이벤트 핸들러가 콜스택에서 사라진 이후에 비동기적으로 동작하게 되면 팝업 차단이 일어날 수 있다는 내용을 발견했다.그래서 바로 <code>setTimeout</code> 메서드를 사용해서 콜스택이 비워진 다음 <code>window.open</code>메서드를 호출했지만 문제없이 동작했다. 테스트로 사용한 코드들은 아래와 같았고 모두 문제없이 동작했다. 그렇다면 비동기 호출이 문제가 아닌건데…</p>
<blockquote>
<p>콜스택과 관계없이 AJAX응답 이후 비동기로 실행될 때 차단되는 걸로 확인했다. 글을 작성할 당시에는 브라우저에서 AJAX통신을 인식하고 차단할 거라고 예상을 못했었나보다.</p>
</blockquote>
<pre><code class="language-js"><span class="hljs-comment">// 태스크큐에 전달</span>
<span class="hljs-keyword">const</span> <span class="hljs-title function_">openNaverSite</span> = (<span class="hljs-params"></span>) =&gt; {
  <span class="hljs-built_in">setTimeout</span>(<span class="hljs-function">() =&gt;</span> <span class="hljs-variable language_">window</span>.<span class="hljs-title function_">open</span>(<span class="hljs-string">&#x27;https://www.naver.com&#x27;</span>, <span class="hljs-string">&#x27;_blank&#x27;</span>), <span class="hljs-number">0</span>);
};
<span class="hljs-keyword">const</span> btn = <span class="hljs-variable language_">document</span>.<span class="hljs-title function_">querySelector</span>(<span class="hljs-string">&#x27;#btn&#x27;</span>);
btn.<span class="hljs-title function_">addEventListener</span>(<span class="hljs-string">&#x27;click&#x27;</span>, <span class="hljs-function">() =&gt;</span> {
  <span class="hljs-variable language_">window</span>.<span class="hljs-built_in">setTimeout</span>(<span class="hljs-function">() =&gt;</span> <span class="hljs-title function_">openNaverSite</span>(), <span class="hljs-number">0</span>);
});

<span class="hljs-comment">// 마이크로 태스크큐에 전달</span>
<span class="hljs-keyword">const</span> <span class="hljs-title function_">openNaverSite</span> = (<span class="hljs-params"></span>) =&gt; {
  <span class="hljs-keyword">return</span> <span class="hljs-keyword">new</span> <span class="hljs-title class_">Promise</span>(<span class="hljs-function"><span class="hljs-params">res</span> =&gt;</span> {
    <span class="hljs-variable language_">window</span>.<span class="hljs-title function_">open</span>(<span class="hljs-string">&#x27;https://www.naver.com&#x27;</span>, <span class="hljs-string">&#x27;_blank&#x27;</span>);
    <span class="hljs-title function_">res</span>(<span class="hljs-literal">true</span>);
  });
};
<span class="hljs-keyword">const</span> btn = <span class="hljs-variable language_">document</span>.<span class="hljs-title function_">querySelector</span>(<span class="hljs-string">&#x27;#btn&#x27;</span>);
btn.<span class="hljs-title function_">addEventListener</span>(<span class="hljs-string">&#x27;click&#x27;</span>, <span class="hljs-function">() =&gt;</span> {
  <span class="hljs-title function_">openNaverSite</span>().<span class="hljs-title function_">then</span>(<span class="hljs-function">() =&gt;</span> {
    <span class="hljs-variable language_">window</span>.<span class="hljs-title function_">open</span>(<span class="hljs-string">&#x27;https://www.naver.com&#x27;</span>, <span class="hljs-string">&#x27;_blank&#x27;</span>);
    <span class="hljs-comment">// 네이버 창이 두 개 연속으로 뜬다</span>
  });
});
</code></pre>
<h3>원인</h3>
<p>이런저런 케이스를 테스트하다가 발견한 것은 click이벤트 이후 <code>1000ms</code> 이후에 발생하는 <code>window.open</code>메서드에 대해서 팝업 차단이 된다는 사실이었다. 때문에 비동기 로직이 <code>1000ms</code>이내에 완료된다면 <code>window.open</code>메서드가 정상적으로 동작하는 것이었다. 특이한 것은 크롬에서는 제한시간이 <code>5000ms</code>정도로 더 넉넉했다. 구글링해서 찾은 국내 자료들은 대부분이 비동기로 호출한 함수 내에서 <code>window.open</code>메서드가 호출되면 차단된다고 설명하고 있는데 실제로는 그렇지 않았다. 아마 비동기 로직의 처리 속도가 대부분 1000ms를 넘기 때문인지 아니면 이후에 정책이 바뀐건지는 알 수 없다. 아무튼 결론적은 아래와 같다.</p>
<blockquote>
<p>반은 맞고 반은 틀린데, 사파리는 비동기 로직과는 상관없이 AJAX응답 이후 로직이 실행되는가 여부에 따라 팝업 차단을 하게 된다. (XHR, fetch 모두 동일) 클릭 이벤트 이후 일정 시간이 지나고 window.open이 팝업 차단으로 막히는 것은 맞다.</p>
</blockquote>
<h3>결론</h3>
<ul>
<li>사파리에서는 click이벤트 발생한지 1000ms이후에 <code>window.open</code>메서드가 호출되면 팝업차단이 된다.
<ul>
<li>크롬에서는 시간제한이 5000ms로 훨씬 넉넉하다.</li>
</ul>
</li>
</ul>
<blockquote>
<p>실제 결론은 window.open 이벤트는 클릭액션 이후 사파리는 <code>1000ms</code>, 크롬에선 이후 <code>5000ms</code>가 지나면 팝업차단이 이뤄지고, 사파리의 경우 클릭액션을 통한 호출이라고 하더라도 AJAX요청을 거치면 팝업차단이 된다. 비동기와는 전혀 관련이 없다.</p>
</blockquote>
<h3>나의 해결방법</h3>
<p>대부분의 솔루션은 비동기 로직 이전에 <code>window.open</code>을 통해 새창을 열고 메서드가 반환한 객체를 통해 새 창의 <code>window</code>객체에 접근해서 <code>location.href</code>의 setter를 사용해서 주소를 변경하는 식으로 안내하고 있지만 아쉽게도 웹뷰에서 새 창을 띄웠을 때 정상적으로 연결이 되지 않는 듯 했다. 다운로드 전용 페이지를 만들고 해당 페이지에 다운받을 파일의 정보를 넘긴 뒤 해당 페이지에서 비동기 로직을 처리한 뒤 자동으로 다운받게 만드는 방식으로 해결할 수 있었다.</p>
<blockquote>
<p>제대로 파악을 하지 않고 글을 작성했었던 것이 아쉬운 글이다. SEO에도 적지만 노출되고 있었는데 혹시나 피해가 가지 않았을까도 걱정된다. 블로그에 댓글 기능을 켜두지 않아서 잘못된 정보를 정정받을 수 있는 기회도 놓쳤다고 생각하니 더욱 아쉽다. 댓글기능을 추가해야겠다.</p>
</blockquote>


window.open과 팝업차단

<p>작년 11월 개발자가 된 이후로 회사에서도 많은 일들이 있었다. 투자 받은 이후 사무실을 굉장히 좋은 곳으로 옮기기도 했고, 팀 리더분이 퇴사해서 팀에 리더자리가 공석이 되었다. (지금은 임시 리더분이 계신다) 또 최근에는 조직개편이 되어서 정들었던 컨텐츠 크루를 <strong>잠시</strong> 떠나게 되었다. 뭔가 앞으로도 꽤 많은 변화가 있지 않을까 싶다.</p>
<p>블로그에는 기술적인 트러블 슈팅이나, 새롭게 알게 된 것들을 많이 적고 싶었는데 그러지는 못해서 아쉽다. 기대하기로는 이번 달 부터는 매월 회고록을 작성하면서 그 달의 생각과 기술적으로 새롭게 알게 된 것들을 정리해볼까 한다. 일단 계획은… 아무튼 이런 기록을 남기는 습관을 만들기 위해서 일단 지금까지의 회고를 간단하게 작성해보려고 한다. 첫 회고이니 만큼 좀 넓은 범위의 이야기를 해볼 생각이다.</p>
<h3>제품에 애정을 갖는 것</h3>
<p>이번에 조직개편을 하면서 새삼 놀랐던 것은 내가 만들던 제품에 얼마나 큰 애정이 있었는지 알게 되었다는 것이다. 만약 진정성 없이 그저 개발만 했었다면 동기부여도 잘 되지 않았을거고 사용자에게 어떻게 하면 더 좋은 경험을 줄 수 있을지 이렇게까지 고민해보지 못했을 것 같다. 기술적인 역량은 당연한 것이고 그걸 뛰어넘어 더 '좋은 제품을 만드는 개발자’가 되려면 진정성을 갖고 제품을 사랑하는 것이라는 것도 배울 수 있는 기회였다. 그대로 새롭게 이동한 커리어 크루에서도 잘 해보자!</p>
<h3>누군가 짠 코드</h3>
<p>취업 이후 가장 많이한 것은 누군가가 짠 코드를 수정하는 일이었다. 물론 새롭게 작성한 코드도 많았지만 그 와중에도 내가 작성하지 않은 코드를 수정하는 것은 불가피했다. 그러면서 솔직히 불만이 없었다면 거짓말이었을 것 같다. 입사 초반에는 대놓고 불만을 토로했는데, 지금와서는 어리석은 짓이었다고 생각한다. 이미 작성 된 코드는 이미 일어난 일이다. 그리고 그때는 그게 옳았을 수도 있고, 더 좋은 코드를 생각할 수 있는 여건이 되지 않았을 수도 있다. 지금 당장 내가 짠 코드를 봐도 못마땅한 것들이 계속 보이는데 어쩔 수 없지 않았을까… 막상 내가 '못마땅한 코드’를 짜는 당사자가 될 수도 있다고 생각하니까 간사하게도 누군가 짠 코드에 대해서 이해심을 가지려고 노력하는 모습이 웃긴다.</p>
<p>누군가 짠 코드를 보면서도 성장할 수 있는 방법은 두가지 정도가 있는 것 같다. 첫 번째로 왜 이렇게 짰을까? 를 생각해보면서 코드 당사자(?)의 사고를 생각해 본다. 그러다 보면, '이래서 이렇게 할 수 밖에 없었구나’를 알게 되고 그걸 넘어서 '이렇게 했다면 어땠을까?'까지 간다면 베스트다. 두 번째로는 왜 이 코드가 못마땅한지 정확하게 파악해 보는 것이다. 보통 코드가 못마땅한 건 컨벤션이나 네이밍같은 것 보다는 기능의 수정이 어렵고 이해하기 어려운 경우가 대부분이다. 결국에는 설계의 문제인 경우가 많다. 그렇다면 어떻게 했으면 좋았을까를 내가 다시 생각해보는 것이다. 여건이 된다면 직접 리팩터링도 하면 베스트다.</p>
<p>아무튼 앞으로도 계속해서 개발을 한다면 대부분이 누군가 짠 코드를 수정하는 일이 될 텐데 여기에 불평 불만을 갖는 건 좋을 게 전혀 없다.</p>
<h3>앞으로</h3>
<p>개발자로서 성장하는 건 뭘까? 예전에는 지식을 많이 쌓는 일이라고 생각했었다. 자바스크립트에 대한 동작원리나 다양한 API를 더 많이 알게 되는 것이 성장인 줄 알았는데 이건 그냥 배움인 것 같다. 미시적으로 느끼는 건 하나의 기능을 설계하더라도 축적된 경험을 통해서 다양한 케이스에 대한 대응을 할 수 있는 설계를 할 수 있는 것에 대한 중요성을 느끼고 있다. 결국 <strong>올바른 경험의 축적</strong>이 성장과 가장 가까운 정의가 아닐까 싶다. 성장과 배움은 비슷하면서도 분리되기 때문에 이 두가지를 확실히 구분해서 이끌어가는 방향으로 나아갈 생각이다. 배움 측면에서는 네트워크와 인프라에 지속적으로 관심을 가져야 할 것 같다.</p>
<hr>
<p>앞으로는 트러블슈팅이 있을 때 마다 기록하려고 더 노력해 보려고 한다. 최근에는 <code>window.open</code> 메서드가 실행될 때 어떨 때 파업차단으로 처리되고 어떨 때 그냥 열리는지에 대해서 고민한 적이 있었는데 이 부분도 확실히 정리해서 포스팅 해보고 싶다.</p>


22년 8월 회고

<h2>인스턴스</h2>
<ul>
<li>클라우딩 컴퓨팅의 단위</li>
<li>하나의 인스턴스는 격리된 컴퓨팅 공간으로 동작한다</li>
<li>인스턴스는 유형별로 성능이 모두 다르며, 성능이나 목적에 맞는 유형을 선택해서 만들어야 한다</li>
<li>인스턴스의 네트워크 정책은 보안그룹을 통해 결정된다</li>
<li>사용자 데이터를 통해서 인스턴스가 실행될 때 자동으로 동작할 스크립트를 지정할 수 있다</li>
</ul>
<h3>온디멘드 인스턴스</h3>
<ul>
<li>사용한 만큼 초 단위로 요금을 내는 인스턴스, 가장 기본적인 방식이다.</li>
<li>가장 유연하게 운용이 가능하다</li>
</ul>
<h3>예약 인스턴스</h3>
<ul>
<li>1년, 3년 단위로 계약해서 사용하는 인스턴스</li>
<li>최대 75% 저렴하다 (온디멘드 대비)</li>
</ul>
<h3>스팟 인스턴스</h3>
<ul>
<li>싯가로 책정된 여분의 인스턴스를 사용하는 방식</li>
<li>요금은 인스턴스중 가장 저렴 (최대 90%)</li>
<li>하지만 지정한 요금 이상으로 인스턴스의 삿가가 올라가면 해당 인스턴스는 2분의 유예기간 이후 자동으로 중단됨</li>
<li>때문에 진행 상황을 잃으면 안되는 작업에는 적합하지 않음</li>
</ul>
<h4>스팟 요청</h4>
<ul>
<li>하나의 작업을 위해 스팟 인스턴스를 유지할 수 있도록 하는 서비스</li>
<li>스팟 요청에서는 설정한 예산에 맞춰서 최적의 스팟 인스턴스를 계속 요청해서 작업을 유지해줌</li>
<li>인스턴스가 계속해서 지속적으로 중단되고 재실행 될 수 있기 때문에 복구가 보장되는 작업에 적합</li>
<li>더 이상 작업이 불필요 하게 되면 반드시 스팟 요청을 철회하고 스팟 인스턴스를 직접 종료해줘야 함
<ul>
<li>만약 스팟 요청이 실행되고 있고 스팟 인스턴스만 종료하면 스팟 요청은 다시 스팟 인스턴스를 만들어서 실행시킴</li>
</ul>
</li>
</ul>
<h3>전용 호스트</h3>
<ul>
<li>AWS 데이터 센터의 물리적인 서버를 렌탈하는 방식</li>
<li>클라이언트 정책에 따라 물리적인 서버가 필요하거나 라이센스 관련 제한이 있을 때 사용</li>
<li>요금은 온디멘드와 예약 방식중에 선택해서 지불할 수 있다
<ul>
<li>마찬가지로 예약이 최대 75% 저렴하다</li>
</ul>
</li>
</ul>
<h3>전용 인스턴스</h3>
<ul>
<li>전용 호스트 같이 물리적으로 격리된 공간에 EC2 인스턴스를 제공받는 방식</li>
<li>동일한 AWS계정 내의 다른 인스턴스와 하드웨어 공유가 가능</li>
</ul>
<h3>Hibernate (절전 모드)</h3>
<ul>
<li>EC2 인스턴스를 절전 모드로 들어가게 해준다.</li>
<li>기존의 인스턴스 중단을 하게 되면 작업 내역과 루트 EBS불륨의 모든 데이터를 잃게 되고, 인스턴스를 재시동할 때 사용자 데이터의 스크립트를 다시 시작하여 비효율적일 수 있다.</li>
<li>절전 모드에서는 인스턴스의 메모리를 모두 저장한 채로 중단하고 저장한 메모리를 복구하여 인스턴스를 재시작하기 때문에 상태를 유지하면서 빠르게 인스턴스를 재시작 시킬 수 있다.
<ul>
<li>메모리 전체를 루트 EBS볼륨에 덤프하여 보관하고 해당 EBS볼륨을 암호화 처리 해야한다</li>
</ul>
</li>
<li>모든 인스턴스 유형에서 지원하지 않음</li>
<li>인스턴스의 램은 최대 150GB까지만 지원하며 EBS불륨의 사이즈는 램의 데이터를 모두 덤프할 수 있을만큼 충분히 여유있어야 한다</li>
<li>스팟 인스턴스에서는 사용이 불가능</li>
<li>절전 모드로는 60일까지만 유지 가능</li>
</ul>
<h3>EC2 Nitro</h3>
<ul>
<li>EC2의 개선된 가상화 기술을 도입한 차세대 플랫폼</li>
<li>고성능 컴퓨팅과 네트워킹을 제공하고 더 빠른 속도의 EBS볼륨을 제공
<ul>
<li>최대 64,000 IOPS의 속도를 제공</li>
<li>기존에는 최대 32,000 IOPS의 속도로 제공</li>
</ul>
</li>
<li>더 나은 보안 제공</li>
<li>A1, T3, C5, C6, D3, M5 등의 인스턴스 패밀리에서 제공</li>
</ul>
<h3>vCPU 최적화</h3>
<ul>
<li>인스턴스는 컴퓨팅을 담당하는 코어와 스레드를 제공한다</li>
<li>만약 4코어 2스레드라면 총 8개의 스레드가 제공되며 각 스레드 하나를 vCPU로 일컫는다.</li>
<li>상황에 따라 코어의 갯수, 코어당 스레드의 갯수를 축소하여 비용을 절감할 수 있다
<ul>
<li>컴퓨팅 성능이 필요 이상으로 부여되는 경우</li>
<li>코어당 라이센스를 지불해야 하는 경우</li>
<li>코어당 하나의 스레드가 성능에 더 좋은 경우</li>
</ul>
</li>
</ul>
<h3>용량 예약</h3>
<ul>
<li>AZ내에서 원하는 인스턴스의 공간을 미리 할당하여 확보할 수 있다.</li>
<li>해당 인스턴스가 당장 필요하지는 않지만 공간을 미리 확보하여 필요할 때 동작을 보장받을 수 있어야 할 때 사용한다</li>
</ul>
<h2>보안그룹</h2>
<ul>
<li>하나 이상의 인스턴스의 네트워크 인/아웃바운드 규칙을 지정해 줄 수 있음</li>
<li>인스턴스 역시 하나 이상의 보안규칙을 가질 수 있음</li>
<li>각 포트별로 들어오고 나갈 수 있는 포트와 IP주소를 지정해 줄 수 있음</li>
<li>IP주소 뿐만 아니라 다른 보안그룹을 예외 규칙에 추가하여 인스턴스 사이의 네트워크 규칙을 쉽게 지정해 줄 수 있다.</li>
</ul>
<h2>SSH</h2>
<ul>
<li>외부에서 인스턴스 내부로 터미널을 통해서 접속할수 있다. 인스턴스에 지정한 키 페어를 통해 자격증명을 해야 접속할 수 있다.</li>
<li>키 페어는 생성할 때 한 번 컴퓨터에 저장할 수 있고 그 이후에는 절대 재발급이 안되기 때문에 잘 보관해야 한다.</li>
</ul>
<h2>IP</h2>
<ul>
<li>하나의 인스턴스는 퍼블릭IP와 프라이빗IP를 갖는데 퍼블릭IP를 통해 외부와 통신할 수 있다.</li>
<li>프라이빗IP를 통해서는 AWS서비스 내에서 통신할 수 있다.</li>
<li>퍼블릭IP는 인스턴스를 실행할 때 마다 변경된다.</li>
<li>탄력적IP를 통해서 인스턴스가 재실행되어도 퍼블릭IP를 유지할 수 있고 계정별로 5개를 기본으로 사용할 수 있다
<ul>
<li>탄력적IP는 발급받고 인스턴스에 바인딩 하지 않고 보관하게 되면 요금이 발생</li>
<li>로드밸런서 등을 이용해서 외부와 연결하는 게 더 좋기 때문에 사용을 지양하는 게 좋다</li>
</ul>
</li>
</ul>
<h2>배치 그룹</h2>
<ul>
<li>다수의 인스턴스를 다양한 방법으로 AZ(Availability Zone)에 배치할 수 있다.</li>
<li>작업에 따라 적절한 배치 전략을 선택할 수 있다.</li>
</ul>
<h3>클러스터 배치 그룹</h3>
<ul>
<li>같은 AZ내에 같은 클러스터 내에 인스턴스들을 배치하는 방식으로 동작한다.</li>
<li>물리적으로 같은 랙 내부에 인스턴스들이 동작하므로 인스턴스간의 통신에서 초저지연을 기대할 수 있다.</li>
<li>단 클러스터가 포함된 랙이 이슈가 생기면 모든 인스턴스가 영향을 받기 때문에 위험도가 높다.</li>
</ul>
<h3>분산형 배치 그룹</h3>
<ul>
<li>모든 인스턴스를 AZ내에 모두 다른 랙에 배치한다</li>
<li>하나의 배치그룹 당 최대 7개의 인스턴스를 포함할 수 있으며 각 인스턴스는 모두 다른 랙에 배치되기 때문에, 모든 인스턴스가 예상치 못한 하드웨어 이슈에 영향을 받을 확률이 거의 없다.</li>
</ul>
<h3>파티션 배치 그룹</h3>
<ul>
<li>인스턴스를 파티션이라는 논리 구조로 묶어서 배치한다.</li>
<li>하나의 파티션은 같은 랙에서 동작하며 스프레드 방식과 동일하게 같은 AZ내에서 최대 7개까지 관리할 수 있다.</li>
<li>인스턴스 별로 파티션을 지정해주거나 자동으로 배치할 수 있다.</li>
<li>하나의 랙에 이슈가 생기면 해당하는 파티션에 포함된 인스턴스들만 영향을 받게 된다.</li>
</ul>
<h2>네트워크</h2>
<h3>ENI</h3>
<ul>
<li>가상 네트워크 인터페이스</li>
<li>하나의 ENI는 하나의 사설 아이피를 할당받는다.</li>
<li>하나의 EC2 인스턴스는 다수의 ENI가 바인딩 될 수 있다.</li>
<li>인스턴스간의 ENI는 이동 및 교체가 가능하다</li>
</ul>
<h2>스토리지</h2>
<h3>EBS</h3>
<ul>
<li>Elastic Block Store</li>
<li>인스턴스가 실행되는 동안 연결 가능한 네트워크 드라이브</li>
<li>네트워크를 통해 연결되기 때문에 지연이 발생할 수 있음</li>
<li>인스턴스 종료 이후에도 데이터를 유지할 수 있다.</li>
<li>CCP 레벨에서는 하나의 EBS는 하나의 EC2 인스턴스에 마운트 가능하며, 어소시어에트 레벨에서는 일부 EBS는 다중연결을 지원한다</li>
<li>동일 AZ내에 있는 인스턴스간의 마운트/언마운트가 가능하다</li>
<li>인스턴스를 생성할 때 Root에 마운트된 EBS볼륨은 기본적으로 인스턴스가 종료되면 삭제되도록 설정되어 있다
<ul>
<li>해당 속성을 비활성화 하여 인스턴스가 종료되어도 Root EBS볼륨을 유지할 수 있다</li>
</ul>
</li>
</ul>
<h4>EBS 볼륨 유형</h4>
<p><strong>일반 목적 SSD</strong></p>
<ul>
<li>일반적인 애플리케이션에 적합, 가성비가 좋음</li>
<li>시스템의 부트 볼륨 등으로 사용된다.</li>
<li>1GiB - 16TiB까지 제공</li>
<li><strong>gp3</strong>
<ul>
<li>기본으로 3,000 IOPS의 성능과 초당 125MiB/s 처리속도</li>
<li>최대 16,000 IOPS, 1,000MiB/s 처리 속도까지 증가 가능</li>
</ul>
</li>
<li><strong>gp2</strong>
<ul>
<li>이전 버전의 볼륨으로 최대 3,000 IOPS의 성능</li>
<li>GiB당 3IOPS를 제공하도록 설정되어 있음 5,334 GiB에서 3,000 IOPS이 성능 제공</li>
</ul>
</li>
</ul>
<p><strong>프로비저닝 된 IOPS의 SSD</strong></p>
<ul>
<li>IOPS 성능을 유지해야 하는 중요한 비즈니스 애플리케이션에 적합</li>
<li>DB 워크로드에 적합</li>
<li><strong>io1/io2</strong>
<ul>
<li>4GiB - 16TiB까지 제공</li>
<li>io2는 io1보다 높은 성능을 같은 비용으로 사용할 수 있기 때문에 io2를 선택할 수 있으면 io2를 선택하는 게 좋음</li>
<li>최대 32,000 IOPS의 성능</li>
<li>Nitor EC2 인스턴스에서는 최대 64,000 IOPS까지 가능</li>
</ul>
</li>
<li><strong>io2 Block Express</strong>
<ul>
<li>4GiB - 64TiB까지 제공</li>
<li>밀리초 미만의 지연속도</li>
<li>최대 256,000 IOPS의 성능 (IOPS:GiB의 비율이 1,000:1)</li>
</ul>
</li>
</ul>
<p><strong>HDD</strong></p>
<ul>
<li>부트 볼륨으로 사용할 수 없음</li>
<li>125MiB - 16TiB까지 제공</li>
<li><strong>st1</strong>
<ul>
<li>처리량에 최적화되어 있음</li>
<li>빅데이터, 데이터 웨어하우징, 로그 처리에 적합</li>
<li>최대 처리량 500MiB/s, 최대 성능 500 IOPS</li>
</ul>
</li>
<li><strong>sc1</strong>
<ul>
<li>아카이브에 최적화되어 있음</li>
<li>접근 빈도가 낮은 고용량 데이터에 적합</li>
<li>최저 비용으로 데이터를 저장할 수 있음</li>
<li>최대 처리량 250MiB/s, 최대 성능 250 IOPS</li>
</ul>
</li>
</ul>
<h4>EBS 다중연결</h4>
<ul>
<li>io1/io2 에서만 사용 가능</li>
<li>같은 AZ내에 여러 인스턴스에 연결해서 사용할 수 있음</li>
<li>클러스트 인식 파일 시스템 에서만 사용가능
<ul>
<li>XFS, EX4 등은 사용 불가</li>
</ul>
</li>
</ul>
<h4>EBS 암호화</h4>
<ul>
<li>EBS볼륨을 생성할 때 암호화를 활성화 할 수 있음</li>
<li>암호화된 볼륨과 인스턴스간의 모든 데이터 전송이 암호화됨</li>
<li>스냅샷을 생성할 때 암호화되어 생성됨
<ul>
<li>스냅샷에서 생성된 모든 볼륨은 암호화됨</li>
</ul>
</li>
<li>암호화 방식은 투명하게 공개되어 AWS에서 처리됨</li>
<li>성능상의 영향이 거의 없음</li>
<li>KMS(AES-256)를 활용</li>
<li>암호화 되지 않은 스냅샷을 암호화하여 사용할 수 있음</li>
<li>이에 따라 암호화 되지 않은 볼륨도 스냅샷 복사를 통해 암호화 할 수 있음
<ul>
<li>먼저 암호화되지 않은 볼륨의 스냅샷을 생성</li>
<li>생성된 스냅샷을 암호화
<ul>
<li>해당 과정을 생략하고 암호화 되지 않은 스냅샷을 통해 바로 암호화된 볼륨을 생성할 수도 있음</li>
</ul>
</li>
<li>암호화된 스냅샷을 사용해서 새로운 볼륨 생성
→ <strong>암호화된 볼륨으로 생성됨</strong></li>
</ul>
</li>
</ul>
<h4>스냅샷</h4>
<ul>
<li>EBS 볼륨을 백업하는 것</li>
<li>스냅샷을 이용해 EBS볼륨을 복원할 수 있다.</li>
<li>스냅샷은 서로 다른 리전이나 AZ에 복사하여 이동할 수 있다.</li>
</ul>
<h3>EFS</h3>
<ul>
<li>Elastic File System</li>
<li>EC2 인스턴스에 마운트 되는 NFS(Network File System)를 관리하는 서비스</li>
<li>EBS와 다르게 다중 AZ에서 사용할 수 있음</li>
<li>가용성과 확장성이 EBS에 비해 높으며, 비용도 많이 듬</li>
<li>gp3 기준으로 3배 정도 비싸지만, 데이터를 사용한 만큼만 지불하기 때문에 많은 양을 저장하는 게 아니라면 EFS가 더 저렴할 수도 있음</li>
<li>NFSv4.1 프로토콜로 동작</li>
<li>리눅스에서만 마운트 가능</li>
<li>보안 그룹을 이용해서 컨트롤한다</li>
<li>1000개의 클라이언트, 초당 최대 10GB의 처리량을 지원</li>
<li>용량은 최대 페타바이트 급으로 사용량에 따라 자동으로 확장되기 때문에 따로 용량을 지정하지 않아도 됨 (사용한 만큼만 지불)</li>
<li><strong>성능 모드</strong>
<ul>
<li>웹서버와 같이 지연시간에 민감할 경우 범용 성능 모드를 사용
<ul>
<li>작은 파일에 신속하게 접근해야 할 때</li>
</ul>
</li>
<li>대규모 워크플로우를 처리해야 할 때는 Max I/O 성능 모드를 사용
<ul>
<li>지연 시간은 조금 더 걸리지만 높은 처리량</li>
</ul>
</li>
</ul>
</li>
<li><strong>처리량 모드</strong>
<ul>
<li>버스팅 처리량 모드
<ul>
<li>1TB당 50MiB/s → 최대 100MiB/s까지 확장 가능</li>
</ul>
</li>
<li>프로비저닝 된 처리량 모드
<ul>
<li>크기에 상관없이 1GiB/s 까지 지정 가능</li>
</ul>
</li>
</ul>
</li>
<li>스토리지 계층
<ul>
<li>파일에 대한 수명주기 관리 기능</li>
<li>일정 주기에 한 번씩 접근 빈도에 따라 다른 계층으로 파일을 이동시킴</li>
<li>접근 빈도가 낮은 파일은 EFS-IA라고 부르는 저비용의 계층으로 이동시킴
<ul>
<li>단 해당 계층에 있는 파일을 이동시킬 때 추가 비용이 발생하기 때문에 빈도가 낮은 파일만 위치시켜야 효율적인 비용 전략이 가능</li>
</ul>
</li>
</ul>
</li>
</ul>
<h3>AMI</h3>
<ul>
<li>Amazon Machine Image</li>
<li>인스턴스의 운영체제의 설정과 기본 환경 설정을 사전에 정의해 패키징한 이미지</li>
<li>사용자가 만든 AMI는 리전에 종속된다</li>
<li>다양한 AMI를 선택하여 인스턴스를 생성할 수 있다
<ul>
<li>공개 AMI : AWS에서 제공하는 AMI</li>
<li>사용자 AMI : 사용자가 직접 정의한 AMI</li>
<li>마켓플레이스 AMI : 사용자, 기관에서 유/무료로 제공하는 AMI</li>
</ul>
</li>
</ul>
<h3>인스턴스 스토어</h3>
<ul>
<li>인스턴스의 물리 서버에 연결된 하드웨어 드라이브를 제공한다.</li>
<li>물리적으로 연결되어 있기 때문에 네트워크로 연결된 EBS보다 빠른 응답속도와 I/O성능을 보장한다.</li>
<li>단 인스턴스를 종료하면 데이터가 손실된다
<ul>
<li>때문에 장기적인 데이터 보다는 버퍼, 캐시, 스크래치 데이터 등을 저장하는데 적합하다.</li>
</ul>
</li>
<li>EC2 서버에 장애가 발생하면 영향을 받는다.</li>
</ul>


[AWS] EC2

<h2>간단정리</h2>
<ul>
<li>AWS서비스 내의 모든 정책과 권한에 대한 설정을 담당</li>
<li>최소 권한 부여를 원칙으로 설계해야 한다.</li>
</ul>
<h4>정책</h4>
<ul>
<li>AWS 서비스 내의 각 <strong>기능에 대한 권한</strong>의 벌크를 지정한 JSON</li>
<li>어떤 서비스 내의 읽기, 쓰기, 지우기 등의 권한을 지정해 줄 수 있다.</li>
<li>AWS에서 기본적으로 정의된 것이 있고 사용자가 임의로 추가할 수 있다.</li>
</ul>
<h4>사용자</h4>
<ul>
<li>root 계정이 아닌 계정들, 임의로 추가 및 삭제가 가능</li>
<li>사용자별로 액세스 키를 통해 AWS콘솔에 접근할 수 있다.</li>
<li>사용자는 사용자 그룹, 직접 설정을 통해 정책의 영향을 받을 수 있다.</li>
<li>사용자는 하나 이상의 사용자 그룹에 포함될 수 있다.</li>
</ul>
<h4>사용자 그룹</h4>
<ul>
<li>사용자 그룹을 통해 다수의 사용자가 정책을 공유할 수 있도록 할 수 있음</li>
<li>하나 이상의 사용자를 그룹에 포함시킬 수 있으며, 이미 다른 그룹에 있는 사용자도 포함시킬 수 있다.</li>
</ul>
<h4>역할</h4>
<ul>
<li>AWS 서비스 내에 접근할 수 있는 권한을 부여할 수 있는 자격 증명</li>
<li>AWS 서비스(대표적으로 EC2 인스턴스), 다른 AWS 계정, 그 외 에서 해당 AWS의 서비스 내에 접근할 수 있도록 하고 권한을 부여한다.</li>
<li>역할의 권한은 정책을 통해서 지정할 수 있다.</li>
<li>역할은 생성할 때 유형을 지정하고 해당 유형에만 역할을 부여할 수 있다.</li>
</ul>


[AWS] IAM

<p>올해 11월 드디어 프론트엔드 개발자라는 직업으로 회사에 취직했다. 프리랜서로 일을 오래 하다보니까 회사라는 조직의 구성원으로 뭔가 잘 해낼 수 있을까에 대한 걱정이 있었지만, 입사한 지 이제 3주차에 이르면서 느끼는 것은 <code>역시 나는 적응은 잘해</code>정도이다.</p>
<p>20대 중반부터는 근자감을 자주 느꼈다. 뭘 하든 빨리 이해하고 빨리 적응하고, 주변 사람들은 내가 뭘 하던 넌 뭐든 잘할 거라고 치켜세워 주는 반응이 많았다. 늘 그런 치켜 세우는 평가에 경각심을 가졌지만 근자감을 만들어주는데 큰 기여를 하지 않았을까 싶다. 그럼에도 <strong>근거없는</strong> 자신감인 이유에는 내가 뭔가 이루거나 해낸 게 없었기 때문이다.</p>
<p>아무튼 이런 근자감은 역시나 독이 되어서 <code>내가 안해서 그렇지 하면 잘한다.</code>라는 그릇된 생각을 만들게 했었다. 그리고 뭐든 하면 잘 할거니까 아직은 좀 더 이것저것 찍어먹어 보면서 경험을 쌓으려고 했었다. 그러다가 시간이 흘러 20대 후반이 됐을 때의 <code>다재무능</code>한 나를 발견할 수 있었다. 그 때부터 마음이 조급해졌다.</p>
<p>연봉만 보고 개발자가 되려는 사람들에 대해서는 부정적으로 생각하지만 그만큼 경제적인 보장은 중요하다. 생각 해 보면 나 자신도 영향이 전혀 없었다고 하면 거짓말이다. 하지만 진짜로 개발자가 되기 위해서는 돈을 좇는 것 만으로는 어려울 것이다. 진짜로 개발을 좋아하는 마음을 갖기 위해서는 진심이 없으면 불가능하다는 것을 내가 길을 걸으며 느꼈다.</p>
<p>개발자가 되기위한 소양을 물어보면 세가지 정도 대답할 수 있을 것 같다. <code>문제를 해결하는 능력</code>, <code>새롭게 배우는 것을 즐기는 마음</code>, <code>원활한 소통</code> 사실 어디서나 강조하고 있는 내용들이기 때문에 개발자로 취업을 준비하려는 사람들이라면 그냥 외우듯이 알고있는 내용들일 것이다. 중요한 건 <strong>‘이 소양들을 내가 정말로 갖고있는가?’</strong> 에 대한 의문을 던졌을 때 나오는 대답을 봐야한다는 것이다. 개인적으로는 개발자가 되려면 가져야 하는 것을 개발자가 되기로 했기 때문에 갖는 건 지속가능하기 어렵다고 생각한다.</p>
<p>나는 완전 비전공자 개발자다. 고졸이니까 원래 하던 디자인일도 사실 비전공으로 독학을 통해 배웠다. 요즘에 보면 비전공자 개발자가 정말 많다. 오히려 전공자 보다 많은 게 아닐까? 생각이 들 정도로 비전공자 개발자가 많다. 이유 중에는 비전공자를 타겟팅한 학원들의 홍보와 마켓팅이 큰 비중으로 있겠지만, 그보다는 전공과 관계없이 위에서 언급한 소양들을 가진 사람들이라면 정말 누구나 개발에 빠르게 눈을 뜰 수 있기 때문이라고 생각한다. 그리고 나와같은 비전공자나 저학력자 들에게 <code>실력</code>만으로 평가받아서 내 가치를 증명할 수 있다는 점도 큰 매력으로 느껴질 거라고 생각한다. 이제는 내가 개발을 공부하면서 느낀 점들을 이야기해 보겠다.</p>
<h2>개발 공부</h2>
<p>비전공자가 개발 공부하는 방법은 보통 독학과 부트캠프가 있을 것이다. 나같은 경우는 독학으로 시작했다가 좋은 기회에 무료로 진행한 부트캠프에 참여할 수 있었다. 사실 독학으로 시작했던 것도 금전적인 문제가 가장 컸었기 때문이었는데, 둘 다 해본 입장에서는 <strong>부트캠프를 다니는 것을 강력하게 추천한다. 가능하면 오프라인으로.</strong> 내가 다녔던 부트캠프를 진행한 업체는 저퀄리티 강의영상과 과장하는 마케팅으로 유명한 곳이었기 때문에 사실 처음에는 큰 기대는 하지 않았다. 그럼에도 배움에 있어 가장 중요한 것은 배우는 사람이라고 생각했기 때문에 마음을 확실히 먹고 시작했는데 의외로 오프라인 강의는 퀄리티가 좋고 강사진들도 굉장히 훌륭했다. 그리고 함께 배우는 수강생들에게도 정말 많은 자극을 받고 선순환에 기여할 수 있었다. 수료를 하고 취업을 한 지금 상황에서는 좋은 기회를 무료로 제공해준 것에 감사한 마음이 크다.</p>
<p>프론트엔드 부트캠프 과정은 다 비슷한 기술스택으로 진행된다. 알고리즘/자료구조, HTML/CSS, 자바스크립트, 리액트, 리덕스. 내 생각엔 딱 이만큼은 정말 <strong>확실하게</strong> 배우는 것이 좋을 것 같다. 괜히 이런저런 라이브러리 여러개를 아는 것 보다는 리액트 하나를 확실하게 아는 게 좋다고 생각한다. 기업에서도 배움의 넓이 보다는 깊이를 더 본다. 이 사람이 기술하나를 얼마나 깊이까지 다뤄봤는가를 중요하게 보기 때문이다. 하나를 제대로 배울 수 있는 사람은 뭐든 제대로 배울 수 있는 사람이라고 생각할 것이다.</p>
<p>HTML과 CSS도 제대로 알고 가면 좋다. 물론 대부분의 부트캠프와 기업에서 조차 시멘틱 마크업이나 접근성에 관련해서는 큰 비중을 두지는 않지만 그만큼 스스로의 경쟁력으로 가져갈 수 있는 부분이기 때문이다.</p>
<p>그리고 자바스크립트를 배울 때에는 <strong>실행컨텍스트, 이벤트루프, 클로저, 비동기 처리</strong>와 같은 핵심 개념들에 대해서 <strong>적확한 이해</strong>를 반드시 챙겨야한다. 절대로 그냥 피상적으로 외우는 방식이 아닌, 내가 모든 개념에 대해서 자바스크립트를 배우는 사람들에게 이해를 목표로 설명할 수 있을 정도로 이해하고 있어야 한다. 프론트엔드 개발자가 사용하는 언어는 자바스크립트로 한정되어 있기 때문에 더더욱 이 하나의 언어를 완벽하게 파악하고 있어야 한다.</p>
<p>대부분에 기업에서 사용하고 있는 리액트 또한 그 동작원리에 대한 이해가 필수이다. 컴포넌트의 라이프사이클, 성능 최적화, Virtual DOM 등 아주 기본적인 키워드에 대해서 정확하게 파악하고 있어야 한다. 결국에는 정말, 정말 모든 것을 알고있어야 한다는 것이다. 이해가 안되서 넘어가는 것이 없도록 배워야 한다. 당장에 이해가 안되는 부분이 있으면 반드시 나중에 다시한 번 이해하려고 시도해야 한다.</p>
<p>모든 개념을 이해의 영역으로 가져와야 진짜로 배웠다고 할 수 있는 것이다. 자바스크립트는 말할 것도 없고 CSS도 배워보면 Stacking Context, Block Format Context 등 어려운 개념들이 굉장히 많고 HTML에서도 Outline Algorithms이나 WAI-ARIA 같은 생소한 개념이 등장한다. 우리가 개발자가 된다는 것은 전문가가 되어야 한다는 의미이다. 수많은 광고처럼 취미로 사이트를 만들려고 하는 것이 아니기 때문에 더 학문적으로 접근할 필요가 분명히 있다고 생각한다.</p>
<h2>테스트와 면접</h2>
<p>기업에 이력서를 넣고 코딩테스트나 과제전형을 통과하면 면접을 보게된다. 나같은 경우는 코딩테스트 준비에 꽤나 애를 먹었는데, 코딩테스트는 알고리즘(DFS/BFS, 이분탐색, 투포인터 등…)을 숙달하는 것도 중요하지만, 문제를 보고 바로 접근방법을 도출해내는 것도 중요하다. 문제를 보고 어떤 방식으로 풀어야 할지 한 번에 파악할 수 있는 능력은 정말 다양한 유형의 문제를 풀어야만 터득할 수 있는 듯 하다.</p>
<p>그리고 나같은 경우는 DP와 같이 난이도가 높은 유형은 거의 포기를 했다(…) 다른 알고리즘 유형과 다르게 논리적인 점화식을 통해서 풀어야 하기 때문에 어떻게 해도 머릿속으로 그림이 그려지질 않았다. 나머지 유형같은 경우는 머릿속에서 다이어그램을 그리면서 진행하면 어떻게든 풀 수 있었지만 DP만큼은 어떻게 해도 어려웠다. 2차원 DP는 더욱. (나는 아직도 0-1 배낭 문제를 풀어보라고 하면 못한다.) 그래서 아예 DP유형에 대해서는 대비를 전혀 하지 않았다. 사실 수시전형의 개발자 채용에서는 코딩테스트의 난이도가 그렇게 높지 않기 때문에 DP문제가 나오는 경우도 거의 없을 것이다.</p>
<p>수시채용에서는 코딩테스트는 백준 실버3 ~ 골드4 정도 난이도의 문제가 나오기 때문에 너무 어렵게 생각하지 않아도 될 것 같다. 만약 공채를 준비한다면 실버1 ~ 골드2 까지 생각해야 한다. 그러나 요즘에는 부트캠프 출신의 비전공자 개발자들이 많아지면서 CS나 알고리즘과 같은 이론지식 보다는 더 실무에 밀접한 능력을 보려고 하는 추세로 변하고 있는 듯 하고, 코딩테스트가 아닌 과제전형으로 진행하는 경우도 많다. 하지만 CS지식과 알고리즘, 특히 자료구조는 반드시 알고있어야 하는 지식이니 개발자의 소양이라 생각하고 반드시 학습하길 바란다. 또한 관련 내용을 기술면접에서 물어볼 수도 있다.</p>
<p>나같은 경우에도 코딩테스트는 전혀 없이 과제전형으로 진행한 회사에서 좋은 평가를 받으면서 최종합격을 할 수 있었다. 과제를 진행하면서 상당히 디테일하게 문서화를 진행하면서 작업했는데 처음에 기술스택을 선정한 이유부터 과제를 하면서 했던 고민과 해결 과정들을 모두 문서화해서 정리했고 모든 코드들을 작성한 이유들을 가능한 많이 담아서 함께 제출했다. 그 덕분에 좋은 인상을 남길 수 있었으리라 생각된다.</p>
<p>기술 면접같은 경우는 위에서 말했듯이 코어한 개념들을 완벽하게 이해한 상태로 정말 <strong>기술면접은 두렵지 않을 만큼 철저하게 준비하면 된다.</strong> 그리고 면접관들은 보통 이력서를 보고 질문을 하기 때문에, 어떤 질문을 해도 대답을 할 수 있는 기술이 아니라면 기술스택에서 제외하는 것을 추천한다. 이렇게 완벽하게 준비한 상태라고 해도 분명히 내가 모르는 질문이 나올 수 있기 때문에 본인이 할 수 있는 한 최대한 완벽하게 준비해야만 한다. 기술면접에 자신이 없다면 아직 취업준비가 되지 않은 것이니 더 준비를 하는 것을 추천한다. 또한 앞서 말했듯 기술면접에서 CS나 알고리즘, 자료구조 등의 전공지식을 물어볼 수 있으니 프로세스와 스레드, 네트워크 프로토콜, 기본적인 큐, 스택, 해시테이블, BST 등의 자료구조와 정렬 알고리즘 정도는 숙지해두면 좋을 것 같다.</p>
<p>인성면접을 볼 때에는 보통 성격, 협업 태도, 상황 대처능력 등을 중점으로 물어본다. 또한 해당 회사에 지원한 이유, 회사에서 기여할 수 있는 부분등 매우 알려진 질문들이 들어오기 때문에 예상 질문에 대한 답변을 모두 한 번 작성해 보는 것을 추천한다. 또한 스타트업 같은 경우에는 인성면접이 CEO면접일 가능성이 높기 때문에 입사하고 싶은 회사의 정보를 가능한 샅샅히 알아보고 가면 좋다. 회사의 비전, 투자 현황, CEO에 대한 인터뷰 영상, 프로덕트에 대한 이해를 숙지하고 면접에 임해 CEO에게 회사에 대한 높은 이해도를 비추면 더 좋은 평가를 받을 수 있을 것이다.</p>
<hr>
<p>아무튼 이렇게 신입 개발자의 첫 걸음을 내딛었다. 26살쯤에 개발자 전향을 시작해서 약 16개월의 준비기간(실제로는 12개월 정도일 것이다) 끝에 개발자로 취업할 수 있었다. 만약에 6개월 만에 개발자가 된다는 광고에 혹한다면 스스로 반성하고(물론 될 수는 있다. 될 수는) 개발자라는 직업에 대해서 더 무겁게 생각해 보길 바라고, 나 같은 경우에는 고졸도 검정고시로 원래 하던일도 개발과는 거리가 있었음에도 괜찮은 회사에 취직할 수 있었음에 감사하면서도 나 말고 많은 사람들이 그럴 수 있으리라 믿는다. 그렇기에 이 글이 사람들에게 희망과 도움이 되었으면 한다.</p>


프론트엔드 개발자 취업 후기

<ul>
<li>네트워크 프로토콜과 통신을 7개의 계층으로 표현하여 기능별로 나누고 계층으로 구분한 것</li>
<li>물리적인 단계에서 논리적인 단계를 흐름별로 파악할 수 있게 해줌</li>
<li>때문에 중간에 문제가 생기면 7단계 중에서 어느 곳에서 문제가 생겼는지 빠르게 파악하고 해당 부분만 수리하거나 교체하여 복구할 수 있음</li>
<li>네트워크 장비를 만들 때 호환성을 위한 표준을 정의하기 위해서</li>
</ul>
<h2>OSI 7 Layer 모델</h2>
<ul>
<li>Application (layer 7 - 논리적)
<ul>
<li>응용 서비스 HTTP(웹) / SMTP(메일)</li>
</ul>
</li>
<li>Presntation
<ul>
<li>인코딩 / 암호화 / 압축</li>
</ul>
</li>
<li>Session
<ul>
<li>TCP / IP 통신 연결을 수립 / 유지 / 중단</li>
</ul>
</li>
<li>Transport
<ul>
<li>TCP / UDP</li>
</ul>
</li>
<li>Network
<ul>
<li>IP통신, 라우팅</li>
</ul>
</li>
<li>Data Link
<ul>
<li>이더넷, 랜카드, MAC통신, 에러검출 / 재전송</li>
</ul>
</li>
<li>Physical (layer 1 - 물리적)
<ul>
<li>네트워크 하드웨어 전송기술</li>
</ul>
</li>
</ul>
<h3>Layer 1 - Physical</h3>
<ul>
<li>장치 사이의 물리적인 통신을 위해 전기적, 기계적인 방법으로 동작한다.</li>
<li>통신 단위는 비트이며 <strong>데이터 전송에</strong>만 관여하고 데이터의 진단이나 가공에는 전혀 관여하지 않는다.</li>
<li>대표적인 장비로 통신 케이블, 리피터, 허브 등이 있다.</li>
</ul>
<h3>Layer 2 - Data Link</h3>
<ul>
<li>Pysical Layer에서 송수신되는 정보의 오류와 흐름을 관리하여 통신이 무사히 수행될 수 있도록 한다.</li>
<li>장치별로 고유한 MAC주소를 가지고 통신을 하게 되며, ‘프레임’ 단위를 통해 통신한다.
<ul>
<li>MAC주소는 IEEE802에서 관리한다.</li>
</ul>
</li>
<li>Point to Point 방식으로 신뢰성 있는 전송을 보장하며 CRC기반의 오류 제어와 흐름제어가 필요하다.</li>
<li>장비로는 네트워크 브릿지, 스위치, 모뎀 등이 해당하며 MAC주소도 해당 계층에서 관리한다.</li>
</ul>
<h3>Layer 3 - Network</h3>
<ul>
<li>가장 중요한 Layer로 데이터를 다른 목적지로 가장 빠르고 안전하게 전달하는 기능(Routing)을 담당한다.</li>
<li>IP 주소를 통해서 통신하며, 네트워크 관리자가 직접 할당한다.</li>
<li>데이터가 큰 경우 Packet단위로 분할하여 전송하고, Packet단위로 송신된 데이터를 조립한다.</li>
<li>경로를 찾아주는 기능(Routing)만 담당하고 Packet의 신뢰성(에러제어), 흐름제어에 대한 기능은 없다
<ul>
<li>상위 Layer인 Layer 4 - Transport에서 담당한다</li>
</ul>
</li>
<li>Layer 3 를 거치면서 Packet의 헤더에 수신 및 발신 주소를 포함한다.</li>
<li>장비로는 라우터, L3 스위치, IP 공유기 등이 있다.</li>
</ul>
<h3>Layer 4 - Trasport</h3>
<ul>
<li>호스트 간의 데이터 전송을 담당하며 데이터의 흐름제어와 신뢰성을 보장해준다.</li>
<li>포트를 열어서 응용프로그램들이 데이터를 송수신 할 수 있도록 해준다.</li>
<li>Segment를 단위로 상용한다.</li>
<li><strong>TCP 프로토콜</strong>
<ul>
<li>패킷에 대한 신뢰성을 보장한 연결지향성 서비스를 제공한다</li>
<li>송신자와 수신자의 확실한 연결을 보장한 상태에서 통신을 시도한다.
<ul>
<li>연결 시 3-way handshaking 방식으로 연결한다.</li>
<li>종료 시 4-way handshaking 방식으로 종료한다.</li>
</ul>
</li>
<li>모든 패킷의 손실, 중복, 순서바뀜 등을 방지하고 보장한다.</li>
<li>UDP에 비하여 상대적으로 속도가 느리다.</li>
<li>Network Layer의 패킷에 대하여 신뢰성을 제공한다.</li>
</ul>
</li>
<li><strong>UDP 프로토콜</strong>
<ul>
<li>신뢰성을 보장하지는 않지만 실시간으로 멀티캐스팅이 가능하다</li>
<li>송신자와 수신자 사이의 별도의 연결 과정없이 통신을 시도한다.</li>
<li>모든 패킷의 손실, 중복, 순서바뀜 등에 대해 무방비하다.
<ul>
<li>수신하는 쪽에서 오류와 흐름제어를 스스로 갖추어 해결할 수 있다.</li>
</ul>
</li>
<li>TCP에 비하여 상대적으로 속도가 빠르다.</li>
</ul>
</li>
<li>Hardware Layer로 구분하기는 모호하지만 Port를 관리하는 L4 로드 밸런서라는 장비가 있다.</li>
</ul>
<h3>Layer 5 - Session</h3>
<ul>
<li>응용프로그램에서 통신을 위한 논리적인 연결에 대한 방법을 제공한다.
<ul>
<li>운영체제의 Session Table을 통해 로컬 및 원격 어플리케이션 간의 IP와 Port 연결을 관리한다.</li>
</ul>
</li>
<li>앞의 4개의 Layer와 무관하게 응용 프로그램 관점에서 접근해야 한다.</li>
<li>세션의 설정, 유지, 종료, 전송 중단시 복구 등의 기능이 있다.</li>
<li>TCP / IP 세션을 만들고 없애는 책임을 갖는다.</li>
</ul>
<h3>Layer 6 - Presentation</h3>
<ul>
<li>데이터의 인코딩, 암호화 등 메타정보 처리에 대한 부담을 Application Layer에서 덜어준다.</li>
<li>MIME인코딩, 암호화 작업 등이 이 Layer에서 이루어 진다.</li>
<li>해당 데이터의 타입에 대한 구분, 인코딩과 디코딩 등을 담당한다.</li>
</ul>
<h3>Layer 7 - Application</h3>
<ul>
<li>최종 목적지이자 시발점으로 HTTP, FTP, SMTP, POP3, IMAP, Telnet과 같은 프로토콜이 있다.</li>
<li>사용자와 가장 밀접하게 닿아있는 Layer이며 어플리케이션 레벨에서 필요한 서비스를 수행한다.</li>
</ul>


[네트워크] OSI 7 Layers

<ul>
<li>운영체제가 저장매체에 파일을 읽고 쓰기 위한 자료구조 / 알고리즘</li>
</ul>
<h2>파일 시스템이 필요한 이유</h2>
<ul>
<li>데이터를 저장매체에서 관리하는데에 0과 1로 이루어진 비트를 단위로 관리하기에 오버헤드가 너무 큼</li>
<li>때문에 데이터를 블록단위로 묶어서 관리하기로 함 (보통 4KB)</li>
<li>블록마다 고유 번호를 부여해서 관리</li>
<li>그러나 사용자가 블록의 고유번호를 관리하는 것은 불가능
<ul>
<li>사용자가 접근하기 쉬운 추상적인 객체로 묶어서 관리 → 파일</li>
<li>각 파일 안에서는 데이터가 블록단위로 관리됨</li>
</ul>
</li>
<li>저장매체에 파일을 효율적으로 저장하기 위해서는 가능한 연속적인 공간에 파일을 저장해야 함
<ul>
<li>그러나 외부 단편화 문제, 파일 사이즈 변경 문제로 연속적인 공간을 보장할 수 없기 때문에 불연속 공간에서 파일을 저장하는 방법이 필요</li>
<li>블록 체이닝 : 각 블록을 링크드 리스트로 연결 → 파일을 탐색하기 위해 항상 첫 번째 블록부터 주소를 따라가서 탐색해야 하는 단점</li>
<li>인덱스 블록 : 각 블록에 대한 위치 정보(주소)를 기록해서 한 번에 블록을 찾아갈 수 있도록 함</li>
</ul>
</li>
</ul>
<h2>다양한 파일 시스템</h2>
<ul>
<li>Window : FAT, FAT32, NTFS
<ul>
<li>블록 위치를 FAT라는 자료구조에 기록</li>
</ul>
</li>
<li>리눅스(UNIX) : ext2, ext3, ext4
<ul>
<li>인덱스 블록의 일종인 inode 방식을 사용</li>
</ul>
</li>
</ul>
<h2>파일 시스템과 시스템 콜</h2>
<ul>
<li>파일 시스템이 다르더라도 하나의 시스템콜을 통해서 지원되도록 구현되어 있음</li>
<li>시스템 콜을 통해 저장매체에 접근하게 되면 운영체제에서 파일 시스템에 맞게끔 동작하게 됨</li>
</ul>
<h2>inode 파일 시스템 구조</h2>
<ul>
<li>수퍼 블록 : 파일 시스템에 대한 정보
<ul>
<li>파일 시스템의 정보와 파티션에 대한 정보를 갖고 있음</li>
</ul>
</li>
<li>아이노드 블록 : 파일 상세 정보 → 프로세스의 PCB와 비슷한 역할
<ul>
<li>파일별로 inode를 하나씩 갖고 있으며 각 inode는 식별자를 갖음 → inode 식별자로 실제 데이터에 접근할 수 있음</li>
<li>파일 시스템 내부에서는 inode를 기반으로 파일을 엑세스 함</li>
<li>inode 기반 메타 데이터들을 저장하고 있음
<ul>
<li>파일 접근 권한</li>
<li>소유자 정보</li>
<li>파일 사이즈</li>
<li>생성 시간, 수정 시간</li>
<li>데이터의 위치 등</li>
</ul>
</li>
<li>다이렉트 블록안에 실제 데이터 블록의 주소를 보관할 수 있는 공간
<ul>
<li>다이렉트 블록은 보통 12개</li>
<li>실제 데이터 블록은 12개를 훨씬 상이하는 경우가 많음</li>
<li>추가적인 데이터 블록의 주소는 인다이렉트 블록안에 저장되며</li>
<li>재귀적으로 데이터 블록의 주소를 저장할 수 있음
<ul>
<li>싱글 → 더블 → 트리플</li>
</ul>
</li>
<li>다이렉트 블록의 사이즈에 따라서 파일 하나당 최대 사이즈가 달라짐</li>
</ul>
</li>
</ul>
</li>
<li>데이터 블록 : 실제 데이터</li>
</ul>
<h2>가상 파일 시스템 (Virtual File System)</h2>
<ul>
<li>파일 시스템 관리를 추상화하는 기법</li>
<li>네트워크 등 다양한 기기에서 동일한 파일 시스템 인터페이스를 통해 관리할 수 있도록 하는 방법</li>
<li>하나의 시스템콜을 기기별로 알맞은 read_spec/write_spec 코드를 구현</li>
<li>이를 통해 모두 다른 디바이스 / 파일시스템도 같은 동일한 인터페이스로 사용 가능</li>
</ul>
<h3>디바이스의 종류</h3>
<ul>
<li>블록 디바이스 (Block Device)
<ul>
<li>HDD, CD/DVD와 같이 블록 혹은 섹터 등 정해진 단위로 데이터를 송수신, IO 송수신 속도가 높음</li>
</ul>
</li>
<li>캐릭터 디바이스 (Character Device)
<ul>
<li>키보드, 마우스 등 Byte 단위 데이터 전송, IO 송수신 속도가 낮음</li>
</ul>
</li>
</ul>


[CS] 파일 시스템

<ul>
<li>리눅스에서 하나의 프로세스에 할당하는 메모리는 4GB정도</li>
<li>하지만 통상 시스템 물리 메모리는 8GB~32GB 정도</li>
<li>프로세스당 할당된 메모리는 4GB이지만 프로세스가 실제로 동작할 때 참조하는 메모리는 제한적</li>
<li>CPU가 실제로 프로세스에서 참조하는 공간만 물리 메모리에 할당할 수 있음</li>
</ul>
<h2>아이디어</h2>
<ul>
<li>프로세스는 가상메모리의 주소를 사용하고, 데이터를 읽거나 쓸 때 물리 주소로 변환하여 참조할 수 있다.</li>
<li>프로세스는 가상 주소를 먼저 참조하고 MMU에 의해 물리주소를 확인하여 물리 메모리에 접근할 수 있다</li>
</ul>
<h3>MMU (Memory Management Unit)</h3>
<ul>
<li>CPU에서 가상 주소 메모리 접근이 필요할 때, 해당 가상주소를 물리주소로 변환해 주는 하드웨어</li>
</ul>
<h2>페이징</h2>
<ul>
<li>물리메모리에 할당된 가상메모리 공간의 효율적인 관리를 위해 페이지 단위의 크기를 동일하게 설정하여 관리함</li>
<li>하드웨어에서 지원에 따라 페이징 크기가 다름
<ul>
<li>인텔 x86 시스템에서는 4KB, 2MB, 1GB 단위로 지원</li>
<li>리눅스에서는 4KB로 페이징</li>
</ul>
</li>
<li>해당 페이지 단위로 가상메모리를 구분하고 해당 단위만큼 물리메모리에 할당</li>
<li>각각에 프로세스의 PCB에는 가상주소와 물리주소의 매핑정보가 있는 Page Table 구조체를 가리키는 주소가 있음</li>
<li>CPU에서 가상주소에 접근하면 가상주소가 포함된 페이지를 탐색 → 해당 페이지를 인덱스로 Page Table에서 접근하여 물리 메모리 주소를 받아와 해당 주소로 CPU에서 처리</li>
</ul>
<h3>구조</h3>
<ul>
<li>Page(Page Frame) : 고정된 크기의 Block (보통 4KB)</li>
<li>가상주소 V는 두개의 영역으로 구분됨
<ul>
<li>p : 가상 메모리의 페이지 주소 (기준) → 12~31비트</li>
<li>d : 페이지 내에서 참조하는 위치 (오프셋) → 0~11비트</li>
<li>p + d : 실제 물리주소</li>
</ul>
</li>
</ul>
<blockquote>
<p>프로세스가 4GB를 사용하는 이유는 32bit 시스템 내에서 4GB이내의 모든 주소를 저장할 수 있기 때문</p>
</blockquote>
<h3>동작</h3>
<ul>
<li>프로세스에서 특정 가상 주소에 엑세스하기 위해서 다음의 단계를 진행
<ol>
<li>해당 프로세서의 Page Table에 가상 주소가 포함된 Page번호가 있는지 확인</li>
<li>Page번호가 있다면 해당 Page번호가 매핑된 물리 메모리 주소를 알아냄 (p’)</li>
<li>해당 물리메모리 주소(p’) + 오프셋(d)를 계산하여 실제 물리 메모리 주소를 확인</li>
</ol>
</li>
<li>Page Table에 저장된 페이지에 Valid-Invalid Bit를 저장해서 물리메모리에 해당 페이지가 들어가 있는지 바로 확인할 수 있음</li>
</ul>
<h3>페이징 시스템과 MMU</h3>
<ul>
<li>CPU에서 가상주소 접근하면 MMU를 통해 물리주소를 받아올 수 있음</li>
<li>프로세스를 생성하면 CR3 레지스터에 Page Table의 Base주소를 저장</li>
<li>MMU는 CPU가 요청한 가상 주소에 해당하는 물리주소를 Page Table에 접근하여 가져옴</li>
</ul>
<h2>다중 단계 페이징 시스템</h2>
<ul>
<li>프로세스에서 할당된 모든 가상 메모리에 대한 페이지 정보를 Page Table에 저장하는 것은 굉장한 낭비</li>
<li>페이지 정보를 단계를 나눠 생성하여 필요한 페이지만 생성하여 자원을 절약</li>
<li>Page Table을 Directory로 한 단계 더 거쳐 접근하도록 하여 실제 존재하는 Page Table만 관리할 수 있도록 함</li>
<li>Page Directory는 실제로 존재하는 Page Table만을 연결하여 만듬</li>
</ul>
<h2>MMU와 TLB</h2>
<ul>
<li>MMU가 동작할 때 데이터의 이동이 잦음
<ul>
<li>CPU에서 가상주소로 요청 → MMU에서 PageTable에 접근하여 물리 주소 획득 → 획득한 물리 메모리 주소로 가서 데이터 획득 → CPU에 획득한 데이터 전달</li>
</ul>
</li>
<li>해당 동작의 반복을 줄이기 위해 TLB를 통해 가상주소에 대한 물리주소를 캐싱하여 동작을 줄일 수 있음
<ul>
<li>CPU에서 가상주소를 요청했을 때 먼저 TLB를 확인하여 캐싱된 물리주소가 있다면 바로 처리</li>
</ul>
</li>
</ul>
<h2>페이징 시스템과 공유 메모리</h2>
<ul>
<li>프로세스 사이에서 동일한 물리 주소를 가르킬 수 있음</li>
<li>대표적으로 모든 프로세스의 커널 영역의 경우 물리메모리에서 동일한 주소를 갖고있음</li>
<li>하나의 프로세스를 Fork하여 프로세스를 복사하여 만들 경우 복사된 가상 메모리는 부모 프로세스와 같은 물리메모리를 공유하고 <strong>해당 프로세스에서 데이터가 수정될 경우 그 때 새롭게 물리 메모리를 할당</strong>함</li>
</ul>
<h2>요구 페이징 (Demand Paging 또는 Demanded Paiging)</h2>
<ul>
<li>선행 페이징과 반대되는 개념</li>
<li>프로세스의 데이터를 모두 메모리에 올리지 않고 실행 중 필요한 시점에서 메모리에 적재하는 기법</li>
<li>중간에 필요가 없어진 페이지 프레임은 다시 저장매체에 저장 (페이지 교체 알고리즘)</li>
</ul>
<h3>페이지 폴트 인터럽트 (Page Fault Interrupt)</h3>
<ul>
<li>필요한 페이지가 물리 메모리에 없을 때 일어나는 인터럽트</li>
<li>Page Fault가 일어나면 해당하는 페이지를 물리 메모리에 올리게 됨</li>
<li>Page Fault가 자주 일어나게 되면 성능에 영향이 생기기 때문에 최적화를 해줘야 함
<ul>
<li>자주 사용되거나 반드시 사용될 데이터는 미리 물리 메모리에 올려놓는 알고리즘을 구성</li>
</ul>
</li>
<li>Page Fault가 발생할 때는 외부 저장장치와 통신이 발생하기 때문에 병목이 발생할 수 있음</li>
</ul>
<h2>페이지 교체 정책 (Page Replacement Policy)</h2>
<ul>
<li>새로운 페이지를 물리 메모리에 올려야 하는 상황에 물리 메모리가 부족할 때
<ul>
<li>기존에 올라와 있던 페이지 중 하나를 물리메모리에서 내리고 외부 저장장치에 저장한 뒤</li>
<li>새로운 페이지를 해당 공간에 올린다</li>
<li>이 때, 기존에 올라와 있던 페이지 중 어떤 페이지를 내려야 할 지 선택하는 것이 페이지 교체 정책</li>
</ul>
</li>
</ul>
<h3>FIFO</h3>
<ul>
<li>가장 먼저 올라온 페이지가 가장 먼저 교체됨</li>
</ul>
<h3><strong>OPT</strong></h3>
<ul>
<li>OPTimal Repacement Algorithm</li>
<li>앞으로 가장 오랫동안 사용하지 않을 페이지가 먼저 교체됨</li>
<li>그러나 가장 오랫동안 사용하지 않을 페이지를 알아내는 것은 사실상 불가능</li>
<li>일반적인 OS에서는 구현 불가능</li>
</ul>
<h3><strong>LRU</strong></h3>
<ul>
<li>Least Recently Used</li>
<li>가장 오래 전에 사용된 페이지를 교체</li>
<li>가장 많이 사용되는 알고리즘</li>
</ul>
<h3><strong>LFU</strong></h3>
<ul>
<li>Least Frequently Used</li>
<li>가장 적게 사용된 페이지를 교체</li>
</ul>
<h3><strong>NUR</strong></h3>
<ul>
<li>Not Used Recently</li>
<li>NRU와 같지만 각 페이지 마다 참조 비트와 수정 비트를 넣어 사용빈도가 낮은 페이지부터 교체되도록 우선순위를 추가한다
<ul>
<li>(참조, 수정)으로 했을 때 (0, 0), (0, 1), (1, 0), (1, 1) 순으로 페이지를 교체</li>
</ul>
</li>
</ul>
<h3>스레싱</h3>
<ul>
<li>페이지 폴트가 너무 많이 발생하여 과도한 페이지 교체 작업으로 인해 CPU 동작이 중단되는 상황</li>
</ul>
<h2>세그멘테이션</h2>
<ul>
<li>가상 메모리를 서로 크기가 다른 논리적 단위인 세그먼트로 분할해서 관리하는 방법</li>
<li>페이징 기법과 다르게 각 블록의 크기가 다를 수 있음</li>
<li>각 세그먼트별로 역할이나 의미를 갖는 경우가 많음</li>
<li>페이징 방식과 물리주소 계산방식은 유사하다
<ul>
<li>가상주소로 요청을 들어오면 세그먼트 테이블에서 물리메모리의 기준주소와 오프셋을 더해 실제 주소를 받아올 수 있음</li>
</ul>
</li>
</ul>


[CS] 가상메모리

<ul>
<li>Light Weight Process 라고 부르기도 함 → 프로세스 처럼 동작하지만 더 가볍고 작음</li>
<li>프로세스는 기본적으로 직접적으로 데이터 접근이 불가능 → IPC 기법을 활용해 간접적으로 데이터 통신을 사용</li>
<li>스레드는 하나의 프로세스 안에서 생성되며 다수의 스레드 생성 가능</li>
<li>스레드들은 동시에 실행 가능 → 병렬 처리가 가능</li>
<li>하나의 프로세스 안에서 동작하므로 프로세스 내부의 데이터를 공유하며 접근 가능</li>
</ul>
<h2>스레드의 구조</h2>
<ul>
<li>하나의 프로세스 내에서 스택과 레지스터(PC, SP)를 스레드별로 별도로 관리한다.
<ul>
<li>실제로는 프로세스의 스택과 힙 영역 사이에 공간을 할당한다.</li>
</ul>
</li>
<li>때문에 스택영역 외(힙, 코드, 데이터)에는 하나의 프로세스 내에서 스레드끼리 공유가 가능하다</li>
</ul>
<h2>멀티 태스킹 / 멀티 프로세싱</h2>
<h3>멀티 태스킹</h3>
<ul>
<li>다수의 프로세스를 하나의 CPU가 빠르게 교체하면서 작업하여 동시에 여러개의 프로세스가 구동되는 것처럼 하는 기능</li>
<li>스케쥴러와 컨텍스트 스위칭을 통해 구현할 수 있음</li>
</ul>
<h3>멀티 프로세싱</h3>
<ul>
<li>하나 혹은 다수의 프로세스를 다수의 코어가 분할하여 작업을 처리하는 방법</li>
<li>하나의 프로세스 내의 다수의 스레드를 각 코어가 병렬로 처리해 하나의 프로세스의 작업을 다수의 코어가 나누어 처리할 수 있음</li>
</ul>
<h2>장단점</h2>
<h3>장점</h3>
<ul>
<li>프로세스 내에서 기능별로 스레드를 구분하면, 하나의 기능이 지연되어도 프로세스의 응답성을 보장할 수 있음</li>
<li>프로세스 내의 스레드 사이에서 공유되는 영역(코드, 힙, 데이터)에서 IPC처리 없이 직접 자원 공유가 가능</li>
<li>하나의 프로세스 내에서 다수의 스택을 사용하기 때문에 시스템자원을 절약할 수 있음</li>
</ul>
<h3>단점</h3>
<ul>
<li>프로세스 내부의 하나의 스레드에만 문제가 생겨도 전체 프로세스가 영향을 받음
<ul>
<li>크롬 브라우저에서는 멀티 프로세스를 활용하기 때문에 하나의 탭에 문제가 생겨도 다른 탭에 영향이 없음</li>
</ul>
</li>
<li>스레드를 많이 생성하게 되면 컨텍스트 스위칭이 자주 일어나 성능이 저하될 수 있음 → 리눅스에서는 쓰레드와 프로세스를 같이 다루기 때문에 모두 스케쥴링 하게 됨</li>
<li>프로그램이 복잡해짐</li>
</ul>
<h2>동기화 이슈</h2>
<ul>
<li>다수의 스레드 사이의 실행 순서는 보장되지 않기 때문에 공유된 공간의 변수를 사용할 때 예측하지 못한 동작이 일어날 수 있음
<ul>
<li>코드가 실행될 때 어셈블리어 레벨의 연산 중간에 컨텍스트 스위칭이 일어나게 되면 연산이 누락되는 등의 문제가 발생할 수 있음</li>
</ul>
</li>
<li>때문에 다양한 방법을 통해 스레드의 작업 순서를 맞춰 동기화에 문제가 없게 해야함</li>
</ul>
<h3>Mutual Exclusion (상호 배제)</h3>
<ul>
<li>스레드에서 하나의 연산을 하나의 스레드가 끝낼 때 까지 다른 스레드에서 접근하지 못하도록 방지하는 기법</li>
<li>하나의 연산을 점유하고 있는 스레드가 중간에 컨텍스트 스위칭이 일어나 다른 스레드에서 같은 연산을 처리할 때 이미 점유중인 스레드가 있다면 해당 스레드는 점유가 끝날 때 까지 대기함</li>
<li>스레드에서 반드시 한 번에 처리되어야 하는 임계영역을 지정하여 임계자원의 동기화를 보장할 수 있음</li>
</ul>
<h3>Mutex와 Semaphore(세마포어)</h3>
<ul>
<li>Mutex(Binary Semaphore)
<ul>
<li>임계구역에 하나의 스레드만 들어갈 수 있음</li>
</ul>
</li>
<li>Semaphore
<ul>
<li>임계구역 내에 다수의 스레드가 들어갈 수 있음</li>
<li>Counter를 통해 리소스에 접근할 수 있는 허용 가능한 스레드 수를 제어</li>
<li>바쁜 대기 → 임계구역에 접근하지 못하도록 스레드 내에서 Counter 값을 조건으로 임계구역 앞에서 무한 Loop를 돌려 접근을 방지시킴</li>
<li>대기 큐 → 운영체제 기술로 해당 스레드의 상태를 ready상태에서 대기 상태로 바꾸거나 스케쥴러의 대기 큐에 할당하여 접근을 방지시킴
<ul>
<li>세마포어를 구현해 놓은 시스템 API 함수가 있음 → POSIX 세마포어
<ul>
<li><code>sem_open()</code> : 세마포어 생성</li>
<li><code>sem_wait()</code> : 임계영역 접근 전 세마포어 상태를 확인해 세마포어를 잠그거나 풀릴 때 까지 대기</li>
<li><code>sem_post()</code> : 임계영역에 대한 접근이 끝나고 세마포어의 잠금을 해제</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
</ul>
<h3>Deadlock(교착상태)와 Starvation(기아상태)</h3>
<h4>교착상태(Deadlock)</h4>
<ul>
<li>무한 대기 상태 : 두 개 이상의 작업이 서로 작업이 끝나야 진행할 수 있는 상태에서 대기하게 되어 진행이 되지 않는 상태</li>
<li>교착 상태가 발생하는 조건 4가지
<ul>
<li>Mutual exclusion (상호 배제) : 프로세스들이 필요로 하는 자원에 대해 배타적인 통제권을 요구</li>
<li>Hold and wait (점유 대기) : 프로세스가 할당된 자원을 가진 상태에서 다른 자원을 기다림</li>
<li>No preemption (비선점) : 프로세스가 어떤 자원의 사용을 끝내기 전까지 그 자원을 선점할 수 없음</li>
<li>Circular wait (순환 대기) : 각 프로세스는 순환적으로 다음 프로세스가 요구하는 자원을 갖고 있음</li>
</ul>
</li>
<li>위의 네가지 조건 중에 하나를 예방/해결하는 방법으로 교착상태를 방지할 수있다</li>
</ul>
<h4>기아상태(Starvation)</h4>
<ul>
<li>특정 프로세스(스레드)의 우선순위가 낮아서 원하는 자원을 계속 할당 받지 못하는 상태</li>
<li>교착상태와 차이 → 교착상태는 여러 프로세스가 동일 자원 점유를 요청할 때 발생, 기아상태는 여러 프로세스가 작원을 점유할 때, 우선순위가 낮은 프로세스가 영원히 자원 할당이 되지 않는 경우를 의미</li>
<li>우선순위를 수시로 변경해서 해결
<ul>
<li>오래 기다린 프로세스의 우선순위를 높여주기</li>
<li>우선순위가 아니라 Queue방식으로 처리</li>
</ul>
</li>
</ul>


[CS] 스레드

[CS] 프로세스

<h2>운영체제</h2>
<ul>
<li>사용자는 응용프로그램을 이용해 원하는 작업을 실행</li>
<li>이 때 응용프로그램이 작업을 수행하기 위해서 시스템 자원을 요청.</li>
<li>운영체제는 응용프로그램이 요청한 시스템 자원을 효율적으로 분배하여 제공/회수한다.</li>
</ul>
<h2>Interface</h2>
<ul>
<li>사용자가 운영체제를 사용하기 위해서 인터페이스가 필요한데 Shell이 그 역할을 해줌
<ul>
<li>명령어를 통해 운영체제를 사용할 수 있음</li>
<li>Shell 또한 일종의 응용프로그램</li>
</ul>
</li>
<li>응용프로그램이 운영체제를 사용하기 위해서는 API (Application Programming Interface)이 그 역할을 한다.
<ul>
<li>API는 프로그래밍 언어별로 제공되어야 한다.</li>
<li>함수로 제공하여 호출을 통해 운영체제를 조작한다.</li>
<li>보통은 함수들을 묶어서 라이브러리 형태로 제공.</li>
</ul>
</li>
<li>Shell은 사용자, API는 응용프로그램이 운영체제를 사용하기 위한 인터페이스
<ul>
<li>결국은 Shell도 API를 사용해서 동작한다.</li>
</ul>
</li>
<li>운영체제는 시스템 콜을 통해 운영체제의 기능을 사용할 수 있게 해준다.
<ul>
<li>API는 시스템 콜을 사용해 운영체제의 기능을 사용할 수 있다.</li>
<li>시스템 콜은 운영체제를 직접 사용하기 때문에 사용방법이 까다롭고 어렵기 때문에 API로 사용하는 것이 인간 입장에서 편리하다.</li>
</ul>
</li>
<li>사용자 → 응용프로그램 → API → 시스템 콜 → 운영체제 → 하드웨어</li>
</ul>
<h3>시스템 콜과 API</h3>
<ul>
<li>시스템 콜 : 운영체제가 제공하는 기능 호출 함수
<ul>
<li>유닉스 계열은 보통 POSIX API를 기준으로 시스템콜을 정의</li>
<li>커널 모드에서 실행</li>
</ul>
</li>
<li>API : 각 언어별로 시스템 콜을 호출할 수 있는 Wrapper 함수
<ul>
<li>사용자 모드에서 실행</li>
</ul>
</li>
</ul>
<h2>CPU Protection Rings</h2>
<ul>
<li>CPU는 권한 모드를 갖고 있음
<ul>
<li>사용자 모드 → 일반적인 명령을 실행할 수 있음
<ul>
<li>응용 프로그램에서 사용</li>
</ul>
</li>
<li>커널 모드 → 특권 명령어 실행과 자원 접근을 가능하게 해줌
<ul>
<li>운영체제에서 사용</li>
</ul>
</li>
</ul>
</li>
<li>인텔 CPU 기준으로 <code>Ring3</code> ~ <code>Ring0</code>까지 권한이 있음
<ul>
<li><code>Ring3</code>을 보통 사용자 모드라고 지칭</li>
<li><code>Ring0</code>를 보통 커널 모드라고 지칭</li>
</ul>
</li>
<li>CPU에서는 현재 모드를 참조하여 권한이 없는 명령을 차단하여 보호</li>
<li>사용자가 응용프로그램을 사용할 때 커널 모드에서 조작해야 하는 명령은 API와 시스템 콜을 통해 운영체제가 커널모드에서 CPU에게 명령을 전달</li>
<li>보통 하드웨어에 접근해야 하는 경우 커널 모드에서 실행된다.</li>
</ul>
<h3>Kernel</h3>
<ul>
<li>사전적 의미로 <code>알맹이 / 핵심</code></li>
<li>운영체제의 핵심적인 알맹이</li>
</ul>
<h3>Shell</h3>
<ul>
<li>사전적 의미로 껍데기</li>
<li>운영체제의 핵심적인 기능을 감싸는 껍데기</li>
</ul>


[CS] 운영체제

<p>자바스크립트를 공부하면서 개인적으로 자바스크립트에서 가장 중요한 개념을 꼽자면 <code>실행 컨텍스트</code>를 꼽는다. 자바스크립트의 핵심 개념들을 나열 해 보라고 한다면 보통 프로토타입, this 바인딩, 호이스팅, 렉시컬 스코프, 클로저, 이벤트 루프등을 떠올릴 수 있고 그 중에서도 앞의 개념들을 관통하는 가장 핵심적인 개념이 <code>실행 컨텍스트</code>이다.</p>
<h2>실행 환경</h2>
<p>실행 컨텍스트(이하 EC; Execution Context)는 실행 컨텍스트 스택에서 구성된다. 그리고 모든 코드는 EC 안에서 작동한다. 코드가 평가되기 위해서 자바스크립트 엔진은 EC를 생성한 뒤 코드를 평가하는데 EC가 생성되는 상황은 크게 세가지가 있다.</p>
<ol>
<li>전역 코드의 실행 → 전역 EC 생성</li>
<li>함수의 실행 → 함수 EC 생성</li>
<li><code>eval</code>코드의 실행 → eval EC 생성</li>
</ol>
<blockquote>
<p>실행 컨텍스트 스택과 콜 스택은 같은 의미이다.</p>
</blockquote>
<p>EC가 생성되면 생성 단계와 실행 단계를 거쳐 코드를 실행하게 된다. 생성 단계에서는 코드를 전체적으로 평가하고 렉시컬 환경(Lexical Environment)을 생성한다. 그리고 그 렉시컬 환경 내에서는 스코프 체인을 위한 외부 렉시컬 환경 참조 바인딩(Outer Lexical Environment Reference), 식별자 탐색을 위한 객체 환경 레코드(Object Environment Recode)가 연결되고, 전역EC의 경우에는 let과 const로 선언된 변수/상수를 저장하는 선언 환경 레코드(Declarative Environment Record)가 환경 레코드에 연결된다. 마지막으로 해당 렉시컬 환경의 this를 결정하는 this 참조 바인딩이 처리된다.</p>
<p>추가로 ES6이후부터는 블록 스코프별로 렉시컬 환경이 새로 생성되고 현재 실행중인 EC의 렉시컬 환경을 교체하는 식으로 스코프를 처리한다. 이 때 외부 렉시컬 환경 참조를 블럭문이 정의되었던 렉시컬 환경으로 바인딩 하여, 블록 스코프 내에서 스코프 체인이 일어날 수 있도록 해준다.
이렇게 렉시컬 환경과 변수 환경이 생성하면서 식별자에 대한 호이스팅이 일어나게 되고 var변수에는 <code>undefined</code>를 let과 const에는 <code>&lt;uninitialized&gt;</code>로 초기화하여 미리 식별자를 할당하게 된다. 이후에 코드가 실행되면서 실제 변수 할당이 일어난다.</p>
<p>var로 선언된 변수를 저장하기 위한 변수 환경(Variable Environment)도 함께 EC에 연결된다. 변수 환경은 EC 별로 생성되기 때문에 EC내에서 렉시컬 환경이 변경되어도(블록문 실행 등) var변수에 접근할 수 있게 해준다.</p>
<h2>전역 EC</h2>
<p>브라우저의 렌더링 단계에서 <code>&lt;script&gt;</code>태그를 만나면 자바스크립트 엔진에서 EC 스택에 전역 EC를 생성한다. 전역 EC에는 객체 환경 레코드를 통해 globalThis객체에 참조할 수 있게끔 연결이 되며 globalThis또한 별도로 바인딩된다. 일반적으로 전역에서 this를 참조하게 되면 globalThis에 연결되지만 strict mode에서는 <code>undefined</code>로 연결이 된다.</p>
<p>전역 EC의 전역 렉시컬 환경은 별도의 선언 환경 레코드를 갖고 있는데, 이곳에는 let과 const로 선언 된 변수/상수를 별도로 관리한다. var 변수의 경우 globalThis의 프로퍼티로 등록 된 후 변수 환경에서 참조되는 방식으로 식별자를 갖는다면 let과 const는 별도의 공간에 저장되어 globalThis의 프로퍼티와 충돌을 방지한다.</p>
<p>이 후 코드 실행 단계에서 함수 객체가 생성되게 된다면 현재 실행 컨텍스트에 바인딩 된 렉시컬 환경을 함수 객체의 내부슬롯 <code>[[Environment]]</code>에 바인딩하여 이후 함수가 호출 되었을 때의 외부 렉시컬 환경 참조를 결정할 수 있도록 한다.</p>
<h3>블록 렉시컬 환경</h3>
<p>ES6의 let과 const는 블록레벨 스코프를 갖는다. 그렇기 때문에 블록문이 실행 될때 EC는 그대로 유지 된 채로 렉시컬 환경의 바인딩이 교체되는 방법으로 새로운 스코프를 갖게 된다. 이 때 블록 렉시컬 환경이 생성되는데 블록문 내에서의 식별자를 저장하고 외부 렉시컬 환경 참조는 원래 바인딩 되어있었던 렉시컬 환경을 가르켜 스코프 체인을 생성한다.</p>
<h2>함수 EC</h2>
<p>자바스크립트 엔진에서 함수가 호출되면 EC 스택에 함수 EC를 생성한다. 이 때의 EC 스택에는 전역 EC가 있을 수도 있고, 이벤트 루프를 통해 호출된다면 비어있을 수도 있다. 함수 EC가 생성되면 EC 생성 단계에 진입하여 함수 렉시컬 환경을 만들고 이 때 함수가 호출된 방법에 따라 this가 결정되고 외부 렉시컬 환경 참조에 호출된 함수 객체의 <code>[[Environment]]</code> 내부 슬롯에 연결된 렉시컬 환경을 바인딩하여 렉시컬 스코프를 생성한다.</p>
<p>이후 함수 환경 레코드를 생성하여 매개변수와 arguments변수를 초기화하고 함수 내부에서 선언된 식별자들을 초기화 한다. (호이스팅) 이 때 var와 let, const를 별도로 분리하지 않고 함수 환경 레코드 내에서 모두 초기화 한다. 다음 코드 실행 단계에서 초기화 된 식별자에 할당이 일어난다. 만약 이 때 함수 내부에서 함수가 선언된다면 해당 함수객체의 내부슬롯 <code>[[Environment]]</code>에 <em>함수가 선언된 함수의 렉시컬 환경</em>이 바인딩 되고 만약 선언된 함수가 반환되거나 외부에 할당되어 해당 함수 EC가 삭제된 이후에도 남아있다면 연결된 렉시컬 환경은 <code>[[Environment]]</code>의 참조로 남아 클로저를 생성한다.</p>
<p>eval EC의 경우도 비슷하게 작동하며 eval코드는 자바스크립트의 대표적인 안티패턴이므로 거의 사용되지 않기 때문에 생략한다.</p>
<hr>
<p>개인적으로는 자바스크립트의 작동 원리는 실행 컨텍스트에 대한 치밀한 이해만 있다면 반 이상은 이해할 수 있다고 생각한다. 때문에 자바스크립트를 제대로 공부한다면 반드시 적확하게 이해할 필요가 있는 부분이기 때문에 한 번 더 정리를 했다. 이미 알고 있는 내용임에도 용어나 원리가 헷갈리기도 했다. 이 매커니즘을 머릿속에서 언제든지 그릴 수 있을 때 까지 계속 공부해야 할 필요가 있다고 생각한다.</p>


자바스크립트의 핵심 '실행 컨텍스트'

<p>자바스크립트에서는 비교연산이 두가지 있다. <code>==</code>과 <code>===</code> 로 전자는 동등비교연사자, 후자는 일치비교연산자라고 부르기도 한다. (일단 나는 그렇게 부른다.) 대부분의 자바스크립트 개발자들은 두 비교연산자의 차이점은 비교연산시에 동적으로 타이핑을 하느냐로 알고 있을 것이고, 나도 그랬었다. 그렇다면 아래 표현식들의 결과는 어떻게 나올까?</p>
<pre><code class="language-js">[] == <span class="hljs-literal">true</span>;
<span class="hljs-literal">null</span> == <span class="hljs-number">0</span>;
</code></pre>
<p>결론부터 말하자면 둘 다 <code>false</code>가 나온다. 우리는 동등 비교연산<code>==</code>을 하게되면 양쪽의 피연산자의 값을 형변환을 이용한 뒤 일치연산을 하는 것으로 알고있다. 그렇다면 일반적으로 아래와 같은 방식으로 비교할 것이라고 기대한다.</p>
<pre><code class="language-js">[] == <span class="hljs-literal">true</span>; <span class="hljs-comment">// []를 boolean으로 형변환 한다</span>
<span class="hljs-literal">true</span> == <span class="hljs-literal">true</span>; <span class="hljs-comment">// true를 반환한다</span>

<span class="hljs-literal">null</span> == <span class="hljs-number">0</span>; <span class="hljs-comment">// null을 0으로 형변환 한다</span>
<span class="hljs-number">0</span> == <span class="hljs-number">0</span>; <span class="hljs-comment">// true를 반환한다</span>
</code></pre>
<p>그런데 왜 둘 다 <code>false</code>가 나오는 것일까? 정답은 자바스크립트는 동등 비교 연산시에 ECMAScript에서 지정한 <a href="https://262.ecma-international.org/5.1/#sec-11.9.3">동등 비교 연산 알고리즘</a>을 통해 형변환을 진행하기 때문이다. 그 중에는 다음과 같은 내용이 있다.</p>
<ol>
<li>If Type(x) is Boolean, return the result of the comparison ToNumber(x) == y.</li>
<li>If Type(y) is Boolean, return the result of the comparison x == ToNumber(y).</li>
</ol>
<p>그렇다. 양쪽의 피연산자 중 하나가 <strong>boolean일 경우 number로 형변환을 한 뒤 비교한다</strong>는 내용이다. 왜 동등 비교연산에서 이런 짓을 하는지는 브렌던 아이크씨가 알겠지만, 일단은 동등 비교연산에서는 위의 알고리즘을 따른다는 것이다. 그럼 다시 <code>[] == true</code>가 어떻게 작동하는지 생각 해 보자</p>
<pre><code class="language-js">[] == <span class="hljs-literal">true</span> <span class="hljs-comment">// boolean인 true를 number로 형변환 한다</span>
[] == <span class="hljs-number">1</span> <span class="hljs-comment">// true를 number로 바꾸면 1이다. 이제 빈 배열을 number로 형변환 한다</span>
<span class="hljs-number">0</span> == <span class="hljs-number">1</span> <span class="hljs-comment">// 빈 배열을 number로 바꾸면 0이 나온다 (1이 아니다) 결국 0과 1을 비교하게 되어서 false가 출력된다.</span>
</code></pre>
<p>이런 과정을 거쳐 <code>false</code>가 출력되는 것이었다. 왜 이따위로 만들었는지는 정말 모르겠다.</p>
<p>그럼, <code>null == 0</code>이 안되는 이유는? 역시 동등 비교 연산 알고리즘에 답이 있다. 해당 문서에 <code>null</code>과 <code>undefined</code>에 대한 정의는 아래의 두개 뿐이다.</p>
<ol start="2">
<li>If x is null and y is undefined, return true.</li>
<li>If x is undefined and y is null, return true.</li>
</ol>
<p>즉 <code>null</code>과 <code>undifined</code>는 서로 비교했을 때 <code>true</code>를 반환하고 다른 연산시에는 형변환을 하지 않는다. 그렇기 때문에 <code>null == 0</code>을 했을 때 <code>null</code>은 아예 형변환을 하지 않게되고 그대로 비교하게 되기 때문에 <code>false</code>를 반환하게 된다.</p>
<p>보통 자바스크립트를 학습할 때 동등비교연산<code>==</code> 보다는 일치비교연산<code>===</code>을 사용하라고 배우게 된다. 그리고 사실 <code>===</code>만 사용하게 되면 위의 문제로 고민할 필요도 없다. 그럼에도 개발자로서 <strong>왜?</strong> 라는 질문을 해보는 것이 중요하다. 위 사실을 알게 되었든 아니든 <code>===</code>만을 사용하면 이런 문제를 고민할 필요는 없겠지만 그럼에도 동등비교연산의 매커니즘을 적확히 파악하여 다음과 같은 상황에 대한 처리방법을 생각 할 수 있었다.</p>
<blockquote>
<p>만약 어떤 값에 대하여 <code>null</code>이 들어올지 <code>undefined</code>가 들어올지 확실하지 않은 상황에서,
<code>if (value == null) {}</code>과 같은 방법으로 <code>nullish</code>한 값에 대한 처리가 가능해 진다.</p>
</blockquote>


자바스크립트 동등비교연산자 (==)

<p>자바스크립트 공부중 어려웠던 내용을 복습해 보려고 한다. 그 중 하나가 Iterable / Iterator / Generator 였다. 패스트캠퍼스 Nodejs 올인원 패키지에서는 제대로 설명해 주지 않아서 조금 아쉬웠다. 강좌의 분량을 생각하면 어쩔 수 없기도 했지만, 이해하는데 꽤나 시간을 많이 들였다. 물론 지금도 바로 설명하라고 하면 한참을 어버버 거릴 것 같다. 지식의 상태로 있는 내용들을 내것으로 만드는 건 반복 학습 뿐이라고 생각되기 때문에 다시 한 번 정리해 본다.</p>
<blockquote>
<h5>참고 자료 :</h5>
<ul>
<li>https://poiemaweb.com/es6-iteration-for-of</li>
<li>https://poiemaweb.com/es6-generator</li>
</ul>
</blockquote>
<h1>Iteration Protocol</h1>
<p>ES6에서 새로 도입된 데이터 컬렉션 객체(대표적으로 Array)를 순회하기 위한 Protocol(정의된 규칙)이다. 이 프로토콜을 준수한 객체만이 for of 문으로 순회할 수 있고 Spread문법의 피연산자가 될 수 있다. Iteration Protocol은 Iterable Protocol과 Iterator Protocol을 총칭한다.</p>
<h2>1. 이터러블(Iterable)</h2>
<p><strong>Symbol.iterator를 키로 갖고있는 메소드를 가지고 있는 객체를 말한다.</strong> 별도로 Symbol.iterator를 키로 하여 메소드를 정의해 주거나 프로토타입 상속을 통해서 Symbol.iterator를 키로 갖고있는 메소드를 갖고 있다면 Iterable Protocol의 조건을 충족하여 Iterable이라고 할 수 있다. Iterable객체는 for of문으로 순회할 수 있고 Spread문법의 피연산자로 사용할 수 있다. 대표적으로 Array 객체가 있다. <em>(ES9부터는 Object도 피연산자로 사용할 수 있다.)</em></p>
<pre><code class="language-javascript"><span class="hljs-keyword">const</span> array = [<span class="hljs-number">1</span>, <span class="hljs-number">2</span>, <span class="hljs-number">3</span>, <span class="hljs-number">4</span>, <span class="hljs-number">5</span>];

<span class="hljs-variable language_">console</span>.<span class="hljs-title function_">log</span>(<span class="hljs-title class_">Symbol</span>.<span class="hljs-property">iterator</span> <span class="hljs-keyword">in</span> array); <span class="hljs-comment">//true</span>

<span class="hljs-keyword">for</span> (<span class="hljs-keyword">const</span> item <span class="hljs-keyword">of</span> array) {
  <span class="hljs-variable language_">console</span>.<span class="hljs-title function_">log</span>(item);
}
</code></pre>
<h3>1.1 빌트인 이터러블</h3>
<p>ES6를 기준으로 이터러블을 지원하는 객체는 아래와 같다.</p>
<blockquote>
<p>Array, String, Map, Set, TypedArray(Int8Array, Uint8Array, Uint8ClampedArray, Int16Array, Uint16Array, Int32Array, Uint32Array, Float32Array, Float64Array), DOM data structure(NodeList, HTMLCollection), <em>Arguments</em></p>
</blockquote>
<h2>2. 이터레이터(Iterator)</h2>
<p>이터러블 객체의 Symbol.iterator 메소드를 호출하면 Iterator객체를 반환한다. 반환된 Iterator객체는 next메소드를 소유하고 있으며 next메소드를 호출할 때 iterator result 객체를 반환한다면 Iterator Protocol을 충족하여 Iterator라고 할 수 있다. iterator result 객체는 value와 done 프로퍼티를 갖고 있으며, value는 현재 순회하는 값을 갖고 있고 done은 순회가 언제 끝나는지 알려준다. next메소드는 반복적을 호출되다가 모든 요소를 순회하게 되면 value프로퍼티는 undefined, done프로퍼티는 true가 되며 순회를 중단한다.</p>
<pre><code class="language-javascript"><span class="hljs-keyword">const</span> array = [<span class="hljs-number">1</span>, <span class="hljs-number">2</span>, <span class="hljs-number">3</span>, <span class="hljs-number">4</span>, <span class="hljs-number">5</span>];

<span class="hljs-keyword">const</span> iterator = array[<span class="hljs-title class_">Symbol</span>.<span class="hljs-property">itrator</span>]();
<span class="hljs-comment">//Symbol.itrator를 호출해서 반환된 iterator를 받는다.</span>

<span class="hljs-variable language_">console</span>.<span class="hljs-title function_">log</span>(iterator.<span class="hljs-title function_">next</span>()); <span class="hljs-comment">//반복</span>
<span class="hljs-comment">//{ value: 1, done: false }</span>
<span class="hljs-comment">//{ value: 2, done: false }</span>
<span class="hljs-comment">//{ value: 3, done: false }</span>
<span class="hljs-comment">//{ value: 4, done: false }</span>
<span class="hljs-comment">//{ value: 5, done: false }</span>
<span class="hljs-comment">//{ value: undefined, done: true }</span>
</code></pre>
<p><a href="https://images.velog.io/images/kimjeongwonn/post/32adbcb3-27a2-4ddc-97e1-b3b0ed4f2c1b/image.png" target="_blank"><img src="https://images.velog.io/images/kimjeongwonn/post/32adbcb3-27a2-4ddc-97e1-b3b0ed4f2c1b/image.png" alt=""></a></p>
<h2>3. 이터러블 객체 순회하기</h2>
<p>Iteration Protocol을 준수하는 객체를 순회하는 반복문/연산자가 있는데 대표적으로는 for of문이 있다. 이런 반복문/연산자들은 Iterable 객체에서 Iterator를 조작하여 iterator result를 참조해 명령을 실행한다.</p>
<h3>3.1 for of문</h3>
<p>for of문은 해당하는 객체의 Iterator를 통해 받는 iterator result객체의 done프로퍼티가 true가 될 때까지 value프로퍼티의 값을 순회하며 변수에 할당한다. 위의 빌트인 이터러블안의 객체는 모두 순환이 가능하기 때문에 문자열도 순환이 가능하다.</p>
<pre><code class="language-javascript"><span class="hljs-comment">//배열</span>
<span class="hljs-keyword">for</span> (<span class="hljs-keyword">const</span> i <span class="hljs-keyword">of</span> [<span class="hljs-number">1</span>, <span class="hljs-number">2</span>, <span class="hljs-number">3</span>, <span class="hljs-number">4</span>, <span class="hljs-number">5</span>]) {
  <span class="hljs-variable language_">console</span>.<span class="hljs-title function_">log</span>(i); <span class="hljs-comment">//1 2 3 4 5</span>
}

<span class="hljs-comment">//문자열</span>
<span class="hljs-keyword">for</span> (<span class="hljs-keyword">const</span> i <span class="hljs-keyword">of</span> <span class="hljs-string">&#x27;abcde&#x27;</span>) {
  <span class="hljs-variable language_">console</span>.<span class="hljs-title function_">log</span>(i); <span class="hljs-comment">//&#x27;a&#x27; &#x27;b&#x27; &#x27;c&#x27; &#x27;d&#x27; &#x27;e&#x27;</span>
}
</code></pre>
<h2>4. 제네레이터(Generator)</h2>
<p>직접 이터러블 객체를 만들 수도 있다. 먼저, Iteration Protocol에 맞춰 <em>value와 done프로퍼티를 return하는 next메소드를 return하는 Symbol.iterator 메소드</em> 를 직접 작성하여 객체에 할당해주는 방법도 있지만 제네레이터 함수를 이용해 더 쉽게 이터러블 객체를 생성할 수 있다.</p>
<p>아래 예제를 통해 제네레이터의 생성과 순회를 살펴보자.</p>
<pre><code class="language-javascript"><span class="hljs-comment">//function* 을 통해 제네레이터 함수를 만들 수 있다. (화살표 함수는 사용할 수 없다.)</span>
<span class="hljs-keyword">function</span>* <span class="hljs-title function_">counter</span>(<span class="hljs-params"></span>) {
  <span class="hljs-variable language_">console</span>.<span class="hljs-title function_">log</span>(<span class="hljs-string">&#x27;Point 1&#x27;</span>);
  <span class="hljs-keyword">yield</span> <span class="hljs-number">1</span>;
  <span class="hljs-comment">//next 메소드를 호출하면 yield까지의 명령이 처리된 뒤, yield에서 반환되는 값이 iterator result 객체의 value에 할당된다. 그 뒤 다음 next메소드가 호출 될 때 까지 대기한다.</span>
  <span class="hljs-variable language_">console</span>.<span class="hljs-title function_">log</span>(<span class="hljs-string">&#x27;Point 2&#x27;</span>);
  <span class="hljs-keyword">yield</span> <span class="hljs-number">2</span>;
  <span class="hljs-variable language_">console</span>.<span class="hljs-title function_">log</span>(<span class="hljs-string">&#x27;Point 3&#x27;</span>);
  <span class="hljs-keyword">yield</span> <span class="hljs-number">3</span>;
  <span class="hljs-variable language_">console</span>.<span class="hljs-title function_">log</span>(<span class="hljs-string">&#x27;done&#x27;</span>); <span class="hljs-comment">//모든 순회가 끝나고 done 프로퍼티가 true가 된다.</span>
}

<span class="hljs-keyword">const</span> generatorObj = <span class="hljs-title function_">counter</span>();
<span class="hljs-comment">/* 제네레이터 함수를 호출해서 제네레이터 객체를 생성한다.
제네레이터를 통해 생성된 객체는 이터러블이면서 이터레이터이기 때문에 굳이 Symbol.iterator를 호출하지 않아도 next메소드를 통해 순회할 수 있다. */</span>

<span class="hljs-keyword">for</span> (<span class="hljs-keyword">const</span> i <span class="hljs-keyword">of</span> generatorObj) {
  <span class="hljs-variable language_">console</span>.<span class="hljs-title function_">log</span>(i);
}
<span class="hljs-comment">//이터러블 객체이기 때문에 for of 문으로 바로 순회가 가능하다.</span>
<span class="hljs-comment">//물론 이터레이터이기도 하기 때문에 next메소드를 호출하여 원하는 시점에서 호출이 가능하다.</span>

generatorObj.<span class="hljs-title function_">next</span>();
<span class="hljs-comment">//next를 통해 순회하게 되면 yield로 반환된 값을 value프로퍼티의 값으로 갖는 iterator result 객체가 반환된다. 제네레이터 함수 안에 마지막 yield가 끝난 뒤에는 done프로퍼티는 true가 되며 순회가 종료된다.</span>
</code></pre>
<p>위의 예제의 <strong>제네레이터 함수</strong>를 통해 <strong><em>이터러블이면서 이터레이터인</em> 제네레이터 객체</strong>를 생성하고 생성된 제네레이터 객체는 이터러블 처럼 for of를 통해 순회하거나 이터레이터 처럼 next메소드를 통해 순회할 수 있다.</p>
<h3>4.1 제네레이터에 인수를 전달하여 호출하기</h3>
<p>제네레이터 함수는 함수이기 때문에 인자를 받아 제네레이터 객체를 생성할 수 있다.
다음과 같이 인자로 입력받은 횟수만큼 반복하는 제네레이터를 생성해보자.</p>
<pre><code class="language-javascript"><span class="hljs-keyword">function</span>* <span class="hljs-title function_">gen</span>(<span class="hljs-params">n</span>) {
  <span class="hljs-keyword">for</span> (<span class="hljs-keyword">let</span> i = <span class="hljs-number">0</span>; i &lt;= n; <span class="hljs-keyword">yield</span> i++) <span class="hljs-variable language_">console</span>.<span class="hljs-title function_">log</span>(<span class="hljs-string">`current number : <span class="hljs-subst">${i}</span>, last number : <span class="hljs-subst">${n}</span>`</span>);
}

<span class="hljs-keyword">const</span> genObj = <span class="hljs-title function_">gen</span>(<span class="hljs-number">10</span>);
<span class="hljs-comment">//10번 순회할 수 있는 제네레이터 오브젝트를 생성</span>

<span class="hljs-variable language_">console</span>.<span class="hljs-title function_">log</span>(genObj.<span class="hljs-title function_">next</span>()); <span class="hljs-comment">//반복 호출하면 아래와 같은 콘솔을 볼 수 있다.</span>

<span class="hljs-comment">/*
제네레이터 함수 안에 있는 console.log가 출력
current number : 1, last number : 10
next메소드가 반환된 iterble result가 console.log를 통해 출력
{value: 0, done: false}
... 계속 순회하다가 인자로 넣은 마지막 숫자에 도달하면 아래와 같이 done이 true가 되어 순회를 종료
current number : 10, last number : 10
{value: 10, done: false}
{value: undefined, done: true}
*/</span>
</code></pre>
<h3>4.2 next메소드에 인수를 전달하여 제네레이터 호출하기</h3>
<p>제네레이터는 이터레이터와는 다르게 next메소드에 인자를 전달하면 제네레이터 함수의 yield에 할당되어 작동한다. 이를 통해 좀 더 유연하게 제네레이터를 활용할 수 있다.
아래의 예제를 통해 인자가 어떻게 전달되는지 알 수 있다.</p>
<pre><code class="language-javascript"><span class="hljs-keyword">function</span>* <span class="hljs-title function_">gen</span>(<span class="hljs-params">n</span>) {
  <span class="hljs-keyword">let</span> res;
  res = <span class="hljs-keyword">yield</span> n;

  <span class="hljs-variable language_">console</span>.<span class="hljs-title function_">log</span>(res);
  res = <span class="hljs-keyword">yield</span> res;

  <span class="hljs-variable language_">console</span>.<span class="hljs-title function_">log</span>(res);
  res = <span class="hljs-keyword">yield</span> res;

  <span class="hljs-variable language_">console</span>.<span class="hljs-title function_">log</span>(res);
  <span class="hljs-keyword">yield</span> res;
}

<span class="hljs-keyword">const</span> genObj = <span class="hljs-title function_">gen</span>(<span class="hljs-number">0</span>); <span class="hljs-comment">//0 으로 초기값 지정</span>

<span class="hljs-variable language_">console</span>.<span class="hljs-title function_">log</span>(genObj.<span class="hljs-title function_">next</span>()); <span class="hljs-comment">//제네레이터 함수 시작 =&gt; value:0</span>
<span class="hljs-variable language_">console</span>.<span class="hljs-title function_">log</span>(genObj.<span class="hljs-title function_">next</span>(<span class="hljs-number">1</span>)); <span class="hljs-comment">//yield에 1을 전달 이후 함수 다시시작</span>
<span class="hljs-variable language_">console</span>.<span class="hljs-title function_">log</span>(genObj.<span class="hljs-title function_">next</span>(<span class="hljs-number">2</span>)); <span class="hljs-comment">//반복</span>
<span class="hljs-variable language_">console</span>.<span class="hljs-title function_">log</span>(genObj.<span class="hljs-title function_">next</span>(<span class="hljs-number">3</span>)); <span class="hljs-comment">//더이상 yield가 없기 때문에 종료</span>
<span class="hljs-variable language_">console</span>.<span class="hljs-title function_">log</span>(genObj.<span class="hljs-title function_">next</span>(<span class="hljs-number">4</span>)); <span class="hljs-comment">//{ value: undefined, done: true }</span>

<span class="hljs-comment">/*
{ value: 0, done: false }
{ value: 1, done: false }
{ value: 2, done: false }
{ value: 3, done: false }

*/</span>
</code></pre>
<p>next메소드에 인수가 있을 경우에는 yield는 두가지 역할을 하게 된다.</p>
<ol>
<li>value값 반환</li>
<li>next의 인수를 변수에 할당</li>
</ol>
<p>먼저 res에 리터럴을 할당하기 위해서 자바스크립트가 yield n을 처리하게 된다. <strong>그 과정에서 yield가 처리되면서 다음 next까지 함수가 일시정지 되게 된다.</strong> 그리고 다음 next가 호출 될 때 받은 인자를 yield가 반환하여 res변수에 할당하게 된다. 그리고 다시 다음 yield까지 실행한 뒤 일시정지 된다. 이 과정이 마지막 yield까지 반복된다.</p>
<p><a href="https://images.velog.io/images/kimjeongwonn/post/ccdb0940-e2fd-4b12-b7bb-f25a8bb52570/image.png" target="_blank"><img src="https://images.velog.io/images/kimjeongwonn/post/ccdb0940-e2fd-4b12-b7bb-f25a8bb52570/image.png" alt=""></a></p>
<h3>4.3 return을 통해 제네레이터를 강제 종료</h3>
<p>제네레이터 함수 안에서 return이 실행되는 즉시 done은 true가 되고 return에서 반환된 값을 가진 iterator result 객체가 반환된 뒤 제네레이터가 종료된다.</p>
<pre><code class="language-javascript"><span class="hljs-keyword">function</span>* <span class="hljs-title function_">gen</span>(<span class="hljs-params">n</span>) {
  <span class="hljs-keyword">for</span> (<span class="hljs-keyword">let</span> i = <span class="hljs-number">0</span> ; <span class="hljs-literal">true</span> ; i++) {
  <span class="hljs-keyword">if</span> (i &gt; <span class="hljs-number">5</span>) <span class="hljs-keyword">return</span> <span class="hljs-string">&#x27;end&#x27;</span>
  <span class="hljs-keyword">yield</span> i;
}

<span class="hljs-keyword">const</span> genObj = <span class="hljs-title function_">gen</span>();

<span class="hljs-variable language_">console</span>.<span class="hljs-title function_">log</span>(genObj.<span class="hljs-title function_">next</span>()) <span class="hljs-comment">//반복</span>
<span class="hljs-comment">/*
{value: 0, done: false}
{value: 1, done: false}
{value: 2, done: false}
{value: 3, done: false}
{value: 4, done: false}
{value: 5, done: false} //for of 등을 통한 순회에서는 여기까지만 순회한다.
{value: &#x27;end&#x27;, done: true}
{value: undefined, done: true}
...
*/</span>
</code></pre>
<p>return에서 값을 반환하면서 동신에 done이 true가 되기 때문에 for of문 들을 통한 순회에서는 그 전의 값까지만 순회한다.</p>
<h3>4.4 비동기 처리</h3>
<p>함수의 비동기 처리도 제네레이터를 통해 구현할 수 있지만 ES8의 async/await가 완전히 그 기능을 대체하고 있으니 이곳에 설명은 생략한다.</p>
<h2>마치며</h2>
<p>첫 번째 복습기록이다. 내가 이해가 안되었던 부분들을 최대한 이해할 수 있도록 풀어 썼다. 개인적으로는 next메소드에 인수를 넣어 호출할 때 어째서 인수로 넣은 값이 res에 할당된 뒤 console.log로 출력되는지 계속 고민했고, 그렇게 알게 된 내용을 좀 더 자세히 서술했다. 물론 다른 사람들은 당연하게 이해하고 넘어갈 수 있는 부분이었더라도 나는 저 부분이 쉽게 넘어가지지 않았다. 또한 나도 이렇게 복습/복기를 하면서 새로운 사실도 알게되었다. 현재는 React를 배우고 있는데 당연한 듯이 Object 객체에 Spread 연산을 쓰는 강의를 보면서 Object는 이터러블이 아닌데 어떻게 Spread연산이 동작하나 싶었는데 ES9부터 Object에서 Spread연산이 작동한다는 사실도 알게되었다.</p>
