<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>
