content.json

{"pages":[{"title":"About Dave Kim","text":"Intro.안녕하세요. 웹 개발자 김동호입니다.","link":"/about/index.html"}],"posts":[{"title":"Git 블로그 개설","text":"목표 2일에 1글 작성 혹은 커밋 글은 그날 공부한 것을 복습하면서 저녁 10시부터 12시 사이에 작성 작성할 주제는 기술: django, http, docker 책: Deep Work","link":"/2020/04/09/hello-world/"},{"title":"The Weaver","text":"Grant Colfax Tullar라는 시인이 쓴 The weaver라는 시 엘리자베스 엘리엇의 책 ‘고통은 헛되지 않아요’에 인용된 시인데 엘리엇은 이 시로 자신의 책을 마무리 한다 나의 삶이 삐그덕 거리는 순간마다 나의 어리석은 선택에 대한 값을 치르는 것 같다고 생각이 들 때가 많다 그 땐 그렇게 하지 말았어야 했는데 아니면 그 때 그렇게 했어야 했는데 라는 생각들, 낙담들이 자주 나를 괴롭힌다 그 때마다 하나님께서는 위를 보게 하시는데 나의 실패한 선택들과 나의 낙담과 나의 불신앙을 다 사용하셔서 나의 삶을 엮고 계시다는 것을 보여주신다 이 시가 그 모든 것들을 아름답게 그리고 있다 하나님께서는 나의 모든 것을 사용하셔서 그 분께서 기뻐하시는 일에 사용하신다 그 중에서도 슬픔의 검은 실은 그 분이 자주 사용하시는 실이다 The weaver 번역 내 삶은 내 주님과 나 사이의 직물 짜기다나는 색상을 선택할 수 없고주님은 꾸준히 일하신다 주님은 자주 슬픔을 짜시는데,나는 어리석게도 교만에 빠져주님이 위쪽을 보시고나는 아래쪽을 본다는 사실을 망각하곤 한다 직기가 조용해지고북이 움직임을 멈춘 뒤에야하나님은 직물을 펴서 이유를 설명해 주실 것이다 직물 짜는 분의 능숙한 손에는그분이 계획하신 무늬에는검은색 실이 금색, 은색 실만큼이나 필요하다 나를 아시며, 사랑하시며, 돌보시는데그 어떤 것도 이 사실을 흐릴 수 없다그 분은 그 분의 손에 맡기는 사람들에게가장 좋은 것을 주신다 그 분이 주시는 가장 좋은 것은 예수 그리스도 그 분 자신이시니...","link":"/2020/04/09/the-weaver/"},{"title":"이사야 66장 3절","text":"소를 잡아 드리는 것은 살인함과 다름이 없이 하고 어린 양으로 제사드리는 것은 개의 목을 꺾음과 다름이 없이 하며 드리는 예물은 돼지의 피와 다름이 없이 하고 분향하는 것은 우상을 찬송함과 다름이 없이 행하는 그들은 자기의 길을 택하며 그들의 마음은 가증한 것을 기뻐한즉 - 이사야 66장 3절 - 나의 죄, 라는 이 단어가 종종 나에게 주는 인상은 '사실 나는 잘 모르겠는데, 하나님께서 불편해 하신다고 하니깐 고백해야 하는 또 회개해야 하는 무언가이지'이다. 그래서 나의 죄는 자주 어떤 허상과도 같이 느껴진다. 진지해야 대해야 할 의무가 있는 것 같지만 진지하게 대해지지 않는다. 그런데 그런 죄에 대한 인상과는 다르게, 자주 나는 나의 죄가 나의 마음을 좀 먹고 나의 마음 한 가운데에 심연을 만들어 놓는 것을 발견한다. 나의 죄는 나를 불안으로 밀어넣고, 나의 가치를 증명하도록 하고, 가치가 증명되지 못할 경우 다른 사람도 나도 나를 사랑하지 못한다고 말한다. 죄에 대한 나의 인상과 죄가 나의 안에 만들어 놓는 결과 사이의 괴리는 참으로 놀랍다. 나의 정신을, 나의 욕망을, 나의 자유를 조정하는 그 힘에 비해서 나에게 그다지 진지하게 느껴지지 않는다는 것은 무엇을 의미하는 것인가? 하나님께서 이스라엘 사람들에게 그들이 하나님 앞으로 나아가기 전, 소와 양을 바치도록 하셨을 때에 동물의 숨을 끊고 그 동물의 정형을 해야하는 당사자는 제물을 바치는 당사자였다. 하나님께서는 하나님께 나아오는 모든 자가 그 동물을 죽이는 만큼, 그 생명을 죽이는 만큼의 그 진지함으로 죄를 다루기를 요구하셨다. 그러나 시간이 지나고 이스라엘 사람들은 소를, 양을 잡는 것을 그저 도살하는 행위일 뿐인 것으로, 전혀 죄의 댓가를 생각하지 않는 의식으로 전락시켰다. 그들이 제사를 이렇게 일방적인 도살의 의식으로 전향시킨 것은 결국 그들이 진지하게 여기지 않았던 죄의 승리였다. 죄는 여기서 이스라엘 사람들의 욕망의 방향을 조정했는데, 생명을 죽임으로써 죄 그 자신에게 향하던 죄책을 바꾸어서, 도살을 함으로써 그들의 욕망을 긍정하는 방향으로 바꾸어버렸다. 부정한 방법으로 타인의 것을 빼앗아도, 가난한 자들을 무시하며 돌보지 않아도, 자신의 아내가 아닌 다른 여자와 관계를 맺어도, 다시 도살을 하면 될 뿐이었다. 생명을 죽임으로써 죄를 억제한 것이 아니라, 죄를 짓기 위해 도살했다. 나의 마음은 어떠한가? 나는 무엇을 위해 도살하려 하는가? 내가 원하는 것은 여전히 하나님이 원하시는 것과는 다르다. 하나님께서는 하나님께서 나에게 그러하셨듯이 자신을 내어주어 이웃을 사랑하기를 원하신다. 예수 그리스도께서 그러하셨듯이 내가 미워하고 있는 사람들의 유익을 위해 살기를 원하신다. 나의 유일한 안식과 위로와 평안을 안정된 직장과, 편안한 집, 넉넉한 자산이 아니라 하나님 그 분께 두기를 원하신다. 하나님 당신께서는 내가 충분히 이해하지도 못하고, 사랑하지도 않고, 바라지도 않았지만 나에게 말씀하시고 나에게 그리스도를 내어주시고 나의 말을 들으십니다. 당신은 이렇게 말씀하십니다. 나는 나를 구하지 아니하던 자에게 물음을 받았으며 나를 찾지 아니하던 자에게 찾아냄이 되었으며 내 이름을 부르지 아니하던 나라에 내가 여기 있노라 내가 여기 있노라 하였도다 내가 종일 손을 펴서 옳지 않은 길을 걸어가는 패역한 백성들을 불렀나니 하나님 죄를 사랑해서 도살하는 패역한 백성이 여기 있습니다. 저를 불쌍히 여기셔서 당신께서 원하시는 만큼 죄를 진지하게 대하게 하시고 그 죄를 죽이고 당신의 모든 말씀을 기뻐하는 자가 되게 하여 주십시오","link":"/2020/04/10/med_isayiah_6603/"},{"title":"Macbook 외부 키보드로 볼륨 조절","text":"원래 로지텍에서 만든 무선 블루투스 키보드 + 마우스를 쓰고 있었는데, 요즘 타자 입력이 지연되는 문제가 공부에 방해가 될 정도가 되어서 LEOPOLD FC900R 키보드를 큰 맘 먹고(진짜 큰 맘 먹고) 샀다. 하하… 맥북 구입할 때 돈을 많이 써서 키보드를 싼 걸 샀었는데, 이래서 좋은 키보드를 사야하나 싶다.(원래 너무 안좋은 걸 사용해서 그럴 수도 있다 음) 문제는 이전에 사용하던 무선 블루투스 키보드의 경우 별도의 음량 조절 버튼을 제공했는데, 레오폴드 키보드는 그렇지 않아서 음량 조절이 심히 불편하다. 귀찮아봤자 얼마나 귀찮나했는데 진짜 귀찮다. 그래서 구글링을 하고… 한글 구글링으로는 쓸만한 결과를 전혀 얻지 못했지만 영어 구글링에서는 바로 해결책을 준다. :) 3년전 답변자 기준으로 우선 Mac의 키보드 시스템에 맞게 설계된 키보드 혹은 Mac 키보드가 아닌 이상 범용 키보드에서 Mac 음량을 조절할 수는 없다. 따라서 커스텀 단축키를 설정할 수 있는 다른 어플리케이션을 사용하여, 음량 조절과 특정 단축키를 매핑시키는 것을 추천한다. 한 답변자가 추천해준 spark라는 프로그램을 사용해보기로 했다. spark를 설치하고 바로 실행했다. 새로 단축키를 추가하기 위해 +버튼을 누르고 Action을 Volume Up으로 설정한 뒤에 단축키를 설정하면 되는데, 2가지 체크박스가 있다. Display notification icon의 경우 체크하면 볼륨 변화 시 보통 맥에서 볼륨 조절 할때 나오는 창이 생긴다. 이걸 체크 안하면 볼륨 조절할 때 조절은 되지만 조절 정도를 확인할 수 있는 창이 뜨지 않는다. Play feedback when volume is changed의 경우 체크하면 볼륨 변화 시 변화된 볼륨을 들려준다. 두가지 설정 모두 맥의 볼륨 조절에서 기본적으로 제공하는 것이기 때문에 둘 다 체크를 하는 게 좋은 것 같다. Volume Down과 Mute도 동일한 방법으로 설정하면 된다.","link":"/2020/04/15/macbook-volume/"},{"title":"CSS 레이아웃이 다른 문제 해결","text":"현재 Nomad Coder의 airbnb-clone을 수강중이다. 현재 70% 조금 넘게 진행되었는데, 웹 프론트 엔드 부분은 장고 템플릿과 tailwind를 사용해서 만들어졌다. 그런데 강의를 수강하면서 페이지들을 만드는 중에 문제가 발생했고, 강의에서는 이 문제에 대해 아무 언급이 없어서 해결 방법을 찾으려 한다. 문제 발생현재 만들고 있는 airbnb-clone 사이트에서는 예약 가능한 숙소 리스트를 보여준다. 이 숙소 리스트는 홈페이지와 개인 상세 페이지, 이렇게 두 종류의 페이지에서 보여지는데, 홈페이지에서는 예약 가능한 숙소 전체를 볼 수 있고, 개인 상세 페이지에서는 숙소 사업자인 경우 자신이 등록한 숙소 리스트를 볼 수 있다. 그런데 여기서 문제가 발생했다. 정상적으로 출력되는 숙소 리스트 홈페이지와 개인 상세 페이지 모두에서 숙소 리스트가 잘 보여지는 것 같았으나 어떤 개인 상세 페이지에서는 숙소 리스트의 너비가 너무 짧게 설정 되었다. 모두 코드는 동일한 코드를 사용했고 이미지 파일만 달랐는데 이런 문제가 발생했다. 문제가 발생한 숙소 리스트 우선 문제의 html 코드 부분은 아래와 같다. class 값에 따른 css의 자세한 내용은 tailwind를 문서를 읽어야 하지만 대부분의 적용될 스타일은 class명만 봐도 이해가 가능하다 1234567891011<div class=\"flex flex-wrap -mx-40 mb-10\"> <div class=\"w-1/4 mb-10 px-2 overflow-hidden\"> <a href=\"{% url 'rooms:detail' room.pk %}\" > <div class=\"w-full h-64 bg-cover bg-center rounded-lg mb-2\" style=\"background-image: url({{room.first_photo}});\" /></div> ... </a> </div></div> 공부할 내용 찾기 확인한 내용 코드의 두 번째 줄 div는 각각의 숙소 리스트 요소에 해당한다. 이 div의 경우 w-1/4 class가 적용되었는데, 해당 class는 width: 25%가 적용된다. 그렇다면 이 div element의 너비는 자신의 containing block 너비의 1/4이 적용된다. 그런데 정상적으로 출력되는 숙소 리스트의 경우 width 값을 330px정도를 갖는 것에 비해서 비정상적으로 출력되는 숙소 리스트는 140px 정도를 가졌다. 다른 숙소 리스트들도 찾아본 결과 숙소 리스트의 개수에 따라서 각각의 숙소 리스트의 너비가 달라지는 것으로 확인했다. 즉, 사용자의 등록 숙소가 2개, 3개, 4개로 늘어남에 따라서 리스트의 너비도 늘어났다. 공부할 내용 확인한 내용에 따르면 숙소 리스트 요소의 상위 요소들에서 width 값이 명시되지 않았기 때문에 width: 25%를 적용했을 때 값이 불안정하게 바뀌는 것으로 추측할 수 있다. width 값이 결정되는 과정을 이해하기 위해서 containing block을 공부해야 할 것 같고, 또한 브라우저가 block 요소를 그리는 방식인 block formatting context에 대해서도 공부해야 할 것 같다.(이 것이 적절한 문제 해결지점이 아닐 수도 있기 때문에, 공부하면서 원인을 더 찾겠다.)","link":"/2020/04/17/airbnb-clone-problem-1/"},{"title":"CSS Containing Block","text":"airbnb clone 수업 중에 발견한 문제를 해결하기 위해 첫번째로 공부하는 주제는 컨테이닝 블록이다. 컨테이닝 박스란?월드와이드웹 표준을 만드는 단체 w3c에서 작성된 css 공식 문서에서 컨테이닝 블록을 어떻게 설명하는지 확인해보았다. In CSS 2, many box positions and sizes are calculated with respect to the edges of a rectangular box called a containing block. In general, generated boxes act as containing blocks for descendant boxes; we say that a box “establishes” the containing block for its descendants. The phrase “a box’s containing block” means “the containing block in which the box lives,” not the one it generates. - 9.1.2 Containing blocks. CSS 2.1 spec 공식 문서에서는 컨테이닝 블록이라는 개념을 왜 사용하는지와 컨테이닝 블록이 어떻게 설정되는지를 간략하게 설명한다.(자세한 설명은 스펙의 다른 챕터에서 설명을 하고 있다. 후술할 예정) 설명에 따르면 요소들(box들)의 position(CSS에서의 position은 단순히 위치가 아니기 때문에)과 크기(높이와 너비)를 계산하기 위한 기준점을 정하기 위해 필요한 개념이다. 쉽게 말하면 각각의 html요소(box)가 있는(lives) 곳이 컨테이닝 블록이다. 컨테이닝 블록 설정의 자세한 내용을 알려주는 있는 다른 챕터를 확인해 보았다. 해당 내용은 길기 때문에 인용하지는 않지만 여기에서 확인할 수 있다. 컨테이닝 박스 자세히 살펴보기우선 컨테이닝 박스에 대해서 오해하기 쉬운 부분을 이야기 하고 컨테이닝 박스가 position값에 따라서 어떻게 정의되는지 살펴보려고 한다. html을 작성할 때, 요소 안에 요소가 있는 경우 요소를 품은 요소를 부모(상위) 요소라고 하고, 요소 안에 있는 요소를 자식(하위) 요소라고 한다. html 문서들은 이렇게 요소들 간의 계층들을 형성하면서 작성된다. 우리는 브라우저가 이 html 문서를 렌더링하고 그려낸 화면을 보면서 컨테이닝 블록은 부모요소일 것이라고 추측하게 된다. 스펙의 설명에 따르면 대부분의 경우 이 추측은 맞다. 하지만 항상 그런 것은 아니다. 스펙은 부모요소가 컨테이닝 블록이 아닌 경우에 대한 내용, 컨테이닝 블록에 대한 자세한 정의를 설명한다. root element(부모 요소가 없는 유일한 요소)가 있는 직사각형의 영역은 최초 컨테이닝 블록(initial containing block)이다.","link":"/2020/04/21/containing-block/"},{"title":"JS Lexical Scope와 Closure","text":"앞으로 2개의 주제를 다룰 예정인데, 2개의 주제는 모두 JS의 this를 이해하기 위한 내용들이다. this를 이해하는 것에 어려움을 겪으면서 헤메다가 JS의 다른 주제들을 공부하면서 드디어 this를 조금이나마 이해하게 되었다. 그리고 역시 mdn 문서가 짱이다… mdn arrow function 문서를 읽고 나서 this를 이해하는 데 어려움을 겪었던 부분을 많이 해소하게 되었다. 우선 처음에는 lexical scope와 closure를 다루도록 하겠고, 그 다음 JS function과 arrow function을 다루면서 this에 대해 설명해보겠다. 문제의 시작this와의 첫만남심각하게 JS에 대해 잘 모르는(아직도 많이 모르는…) 상태에서 들었던 Code Spitz의 ES6+기초 강의에서 나는 Iterable 예제 코드가 너무 이해가 되지 않았다. 그래서 예제 코드 next 메서드의 return 값을 이리저리 바꿔보면서 this가 누구를 가르키는지 이해해 보려고 했다. Iterator Interface 12345678910111213141516171819202122232425const N2 = class { constructor(max) { this.max = max; } [Symbol.iterator]() { // iterable object which return iterator object let cursor = 0, max = this.max; return { done: false, next() { // iterator object which return IteratorResultObject => (done, value) if (cursor > max) { this.done = true; } else { this.value = cursor * cursor; cursor++; } return this; // this is both iterator object and iteratorResultObject }, }; }};//출처: 코드 스피츠77 ES6+ 기초편 3회차 강의//(https://www.youtube.com/watch?v=xTaCosid1-k&list=PLBNdLLaRx_rIF3jAbhliedtfixePs5g2q&index=4) 위의 예제는 간단하지 않은데 Iterable, Iterator 객체의 정의를 알고 있어야 이해가 되고, 또 Computed property name의 개념을 알아야 `[Symbol.iterator]` 함수가 낯설지 않게 느껴진다. 하지만 이번 주제에서는 앞의 내용들을 다루지 않기 때문에 이미 Iterable과 Iterator의 정의를 알고 있다는 것을 전제로 하고 설명을 하겠다. 예제 코드를 보면 Iterable 객체인 N2가 있고, N2를 Iterable로 만들어주는 `[Symbol.iterator]` 메소드는 next() 함수를 가진 객체를 반환한다. 위의 next 함수가 재밌는 점은 원래 Iterator 객체가 되기 위해서는 해당 객체가 next가 키인 메소드를 가지고 있어야 하고, next 메소드는 key가 각각 value와 done인 IteratorResultObject를 반환해야 한다. 그런데 위의 next 메소드는 this를 반환하는데, 이 this는 next 메소드 자신이 속한 객체를 가리킨다. next가 속한 객체를 보면 next 메서드와 value와 done모두를 가지고 있다. 따라서 next함수는 그냥 IteratorResultObject인 객체를 반환하는 게 아니라 IteratorResultObject이면서 동시에 Iterator인 객체를 반환하게 된다.(어렵다...) 그래서 this는 누구를 가르키는데?지금은 this가 누구를 가르키는 지 코드를 보고 이해할 수 있지만 처음에는 this가 누구를 가르키는 지 이해하기 어려웠다. 앞의 예제 코드에서 N2는 class로 작성되었는데, Java를 사용했던 사람들이라면 누구나 위의 코드가 이해되지 않을 것이다. Java의 경우에는 모든 메소드가 클래스에 귀속되기 때문에 this는 항상 자신을 가지고 있는 인스턴스를 의미한다. 만약에 Java에서처럼 위의 코드를 이해한다면 this는 N2 class를 바탕으로 만들어진 인스턴스를 가르켜야 하고 그 인스턴스는 max 속성과 [Symbol.iterator] 메소드를 가지고 있을 것이다. 그런데 앞서 이야기 했듯이 next 메서드가 반환하는 this는 next 메서드와 value와 done을 모두 가진 객체이다. 이를 통해 알 수 있는 사실은 next메서드를 감싸고 있는 block은 단순히 next를 감싸고 있는 게 아니라 새롭게 생성된 객체라는 것이다. 정리하자면 JS의 this는 Java에서의 this처럼 동작하지 않는다.(추가적으로 Java의 클래스와 JS의 클래스에 대한 차이는 JS의 객체를 공부하고 JS가 프로토타입 체인을 통해 oop를 구현한다는 것을 공부하다보면 이해할 수 있다.). 또한 Java와는 다르게 JS의 객체는 {}을 만드는 것만으로도 생성된다. this가 누구를 가르키는 지의 문제는 Javascript 면접의 단골 질문으로 알려져 있을 정도로 잘 알려진 질문이다. 그런데 이 질문에 대해 대답한 자료들은 그 대답에 따라 발생하는 새로운 질문에 대답해 주지는 않았다. 그래서 우선 대다수의 자료에서 설명하는 this가 누구를 가르키는 지에 대한 대답을 보고서 이어 발생하는 질문을 다루어 보겠다. 다음은 this가 누구를 가르키는 지에 대한 가장 간단한 답이다. The object that is executing the current function. 즉, this는 자신을 실행한 객체를 가르키게 된다. this example 1234567891011function foo() { console.log(this.a); // this points for what?}var bar = { a: 10, foo: foo,};foo(); //undefinedbar.foo(); //10 위의 예제를 보면, foo 함수가 그냥 실행되었을 때와 bar 객체의 함수로 실행되었을 때 결과 값이 다른 것을 보여준다. 그냥 foo함수를 실행한 경우에는 this값이 전역객체 window이다. 따라서 window 객체에 변수 a가 있는지 확인하고, window 객체에는 a가 없기 때문에 undefined를 출력한다. 반대로 foo 함수가 bar 객체의 함수로 실행된 경우 this 값이 bar 객체이기 때문에 bar 객체의 a 값인 10을 출력한다. 이제 문제가 간단하게 해결되었다. this가 함수 실행에 따라서 동적으로 결정된다는 것을 알게 되었다! 가 아니다. 여기서 질문이 발생한다. 변수가 동적으로 binding되는 언어는 dynamic scope를 가진다고 말한다. 그러면 js는 앞서 this가 동적으로 결정된 것을 봤기 때문에 dynamic scope를 가진 언어겠구나라는 생각을 하게 된다. 그런데 ecmascript spec(es6이후의 스펙들)을 보면 lexical binding에 대한 내용만 기술되어 있고 dynamic binding에 대한 내용은 없다. JS를 설명한 모든 자료들은 JS가 lexical scope라고 말한다. 그러면 두 개의 사실이 충돌한다. JS는 lexical scope이므로 함수 사용 시가 아니라 생성 시에 변수가 binding된다. 그런데 this는 함수 사용시에 binding된다. 그렇다면 JS는 기본적으로 lexical binding인데 this만 예외적으로 dynamic binding인가? 헷갈린다. 사실 이 문제에 대한 답은 꼭 scope를 이해하지 않아도 된다. 하지만 이후에 다룰 function, arrow function과 함께 this를 이해하기 위해서는 scope와 closure를 먼저 이해하는 게 도움이 된다. lexical scope vs dynamic scopescope를 간단히 이해하자면 변수의 생명기한과 같다. scope는 변수가 언제 생겨서 언제까지 살아있을 지를 결정한다. 그래서 우리는 프로그래밍을 할 때 변수마다 언제 만들어서 언제까지만 사용할지 고민하고 용도에 맞게 scope를 설정하게 된다. 반복문 안에서만 사용할 변수를 굳이 반복문 밖에서 생성해서 반복문이 끝난 이후에도 살아있게 만들 필요가 없다. 따라서 반복문이 동작하는 동안만 사용할 변수는 반복문 내에 생성한다. 그리고 반복문이 끝나면 사라진다. 그런데 어떤 변수는 반복문이 진행됨에 따라서 값을 기억하거나 축적해야 할 수도 있다. 그런 변수들은 반복문 밖에 생성해서 반복문이 끝나도 값을 기억하고 계속 사용할 수 있도록 한다. 여기서 생각해볼 점은 ‘어떻게 반복문 내에서 반복문 밖에 있는 변수를 사용하는가’이다. ‘반복문 내에서 변수가 선언된 경우, 반복문이 끝나면 변수가 사라진다’는 말은 반복문 내의 scope과 반복문 밖의 scope이 다르다는 걸 의미한다. 이 말은 반복문 안에서 반복문 밖에 있는 변수를 사용하기 위해서는 반복문 밖에 있는 변수를 가지고 와야한다는 뜻이다. 함수에서도 이런 상황이 동일하게 존재한다. 만약 함수 내에서 선언하지 않은 변수를 함수가 사용하고자 한다면 그 변수를 어디에서 찾아가지고 올 것인가? 함수 내에서 선언하지 않은 변수를 찾아오는 방식이 2가지가 있다. 하나가 lexical binding이고 다른 하나가 dynamic binding이다. lexical binding의 경우는 함수가 생성될 때 자신을 포함하고 있는 scope에서 변수를 찾는다. 그리고 JS는 자신을 포함하고 있는 lexical scope에 변수가 없는 경우 자신을 포함하고 있는 scope을 포함하는 scope을 또 추적한다. 이렇게 계속 추적하다가 최초의 scope(보통 전역 scope)에도 없는 경우에는 해당 변수가 없다는 오류를 출력한다. 이렇게 scope를 거꾸로 추적하는 것을 scope chain이라고 한다. 반대로 dynamic binding의 경우에는 함수 내에서 선언하지 않는 변수를 찾을 때에 call stack을 확인한다. call stack을 한층한층 내려가면서 이름이 같은 변수가 있는지 찾고 그 변수를 찾은 경우 해당 변수를 binding한다. JavaScript with Dynamic Scope 12345678910111213function foo() { console.log(x);}function bar() { var x = 15; foo();}var x = 10;foo(); // 10bar(); // 15// 출처: https://bestalign.github.io/2015/07/12/Lexical-Scope-and-Dynamic-Scope/ JavaScript with Lexical Scope 12345678910111213function foo() { console.log(x);}function bar() { var x = 15; foo();}var x = 10;foo(); // 10bar(); // 10// 출처: https://bestalign.github.io/2015/07/12/Lexical-Scope-and-Dynamic-Scope/ 위의 예제는 dynamic scope, lexical scope일 때 값이 어떻게 출력되는지 보여준다.(물론 JS는 lexical scope이기 때문에 2개 중 아래의 예제 대로만 동작한다.) dynamic scope인 경우를 보자. foo 실행시에 자신을 실행한 곳은 전역 환경이다. 따라서 x의 값으로 10을 binding하고 10을 출력한다. bar 실행시에는 bar에서 foo 함수를 실행하고, bar에서 실행된 foo는 x를 찾기 위해 call stack을 확인하고 bar를 찾아낸다. 그런 뒤 bar에 있는 x값 15를 binding하고 15를 출력한다. 그러나 lexical scope는 dynamic scope과 다르다. 자기에게 변수가 없는 경우 자신을 생성한 lexical scope를 확인한다. foo 함수는 bar함수에서 실행되었지만 상관없다. 생성시의 환경은 여전히 전역 환경이다. 따라서 bar 함수 실행시에도 foo 함수는 그대로 10을 binding하고 출력한다. lexical scope와 closureC, Java를 비롯한 대다수의 프로그래밍 언어들은 lexical scope를 채택하여 사용한다. dynamic scope을 사용할 경우 변수 binding이 실행에 따라서 결정되기 때문에 변수 관리와 디버깅이 어렵기 때문이다. 그런데 JS는 lexical scope이면서 함수 생성이 런타임 때 이루어 지기 때문에 closure라는 독특한 환경이 생긴다. C나 Java 같은 정적인 언어들은 컴파일 때 함수의 생성과 메모리 할당이 완료되는 반면 JS의 경우에는 함수의 생성과 메모리 할당이 런타임때 이루어진다. 앞서 이야기 했던 것과 같이 lexical scope은 함수 생성 때의 scope의 변수들이 binding되는데, 함수의 생성이 컴파일 때 완료되는 경우 함수가 볼 수 있는 환경이 전역 변수 밖에 없다.(C나 Java는 함수 내 함수 선언 자체가 불가능하기도 하다.) 그래서 JS는 똑같이 lexical scope이지만 함수 내에서 함수(nested function)를 만든 경우에는 다른 언어들과는 다른 환경이 생긴다. JS는 함수 내 함수(inner function)의 생성이 런타임 때 이루어 지기 때문에 자신을 생성한 함수의 변수들이 자신의 환경이 된다. 이렇게 함수 자신이 선언하지 않았지만 환경으로서 사용할 수 있는 변수들을 자유 변수라고 부른다. JS의 경우 이런 자유 변수들을 읽기만 할 수 있는 게 아니라 변경도 가능하다.(읽기만 가능한 언어들도 있다.) function without exposing closure 1234567891011121314const mainFunc = () => { let i = 100; const externalFunc = () => { console.log(\"It's external the i is \" + i); return i + 1; }; i = externalFunc(); console.log(\"It's main the i is \" + i);};mainFunc(); // It's external the i is 100// It's main the i is 101// 출처: 분명히 출처가 있는데, 어떤 자료에서 보여준 예제인지 찾지 못했습니다. 혹시 출처를 아신다면 답글로 알려주세요.... 위의 예제를 보면 externalFunc 내부에는 변수 i가 없기 때문에 자신을 포함한 scope인 mainFunc를 확인한다. mainFunc에는 i값이 있기 때문에 해당 i값이 binding된다. 변수 i가 externalFunc의 자유변수가 된 것이다. 이제 externalFunc는 자유변수 i까지 포함하는 환경을 가지게 되었다. 위의 예제의 경우에는 externalFunc는 mainFunc 내부에서 실행되고 종료된다. 그래서 i가 externalFunc에서 사용되었지만 mainFunc함수의 종료와 함께 변수 i도 할당이 해제될 것이다. 그러나 경우에 따라서는 내부에서 선언된 externalFunc의 사용에 따라서 i값 할당 해제가 불가능할 수도 있다. function with exposing closure 12345678910111213141516const mainFunc = () => { let i = 100; const externalFunc = () => { console.log(\"It's external the i is \" + i); return (i = i + 1); }; return externalFunc;};let foo = mainFunc();foo(); // It's external the i is 100foo(); // It's external the i is 101foo(); // It's external the i is 102// 출처: 분명히 출처가 있는데, 어떤 자료에서 보여준 예제인지 찾지 못했습니다. 혹시 출처를 아신다면 답글로 알려주세요.... 만약 위의 경우에서 처럼 mainFunc가 externalFunc를 return 하는 경우 외부에서 externalFunc를 사용할 수 있게 된다. 근데 문제는 mainFunc는 externalFunc를 반환하면서 실행이 종료되지만 externalFunc안에서 사용한 mainFunc의 변수 i는 할당 해제가 불가능하다. externalFunc가 변수 i값을 사용하고 있기 때문이다. 이처럼 내부의 함수가 자유변수를 사용하고 외부에 노출된 경우 자신의 변수가 아님에도 불구하고 함수 내부에 해당 자유변수들이 갇힌 공간이 만들어진다. lexical scope이면서도 런타임 때 함수가 생성되는 언어의 경우 함수 내부의 함수가 자유변수를 사용함으로써 자유변수를 가두는 공간이 만들어진다. 이렇게 만들어진 공간은 closure라고 하는데 자유변수들의 closure를 말하는 것이다.(자료에 따라서 closure에 대한 다른 정의를 하기도 한다.) 정리 JS에서 this는 현재 함수를 실행한 객체를 가리킨다. 그런데 JS는 함수 실행시가 아닌 생성시에 변수가 binding되는 lexical scope이다. JS는 함수 생성이 런타임 때 일어나기 때문에 함수 내의 함수(nested function)의 내부 함수(inner function)의 경우 자신을 생성한 함수의 변수들이 환경으로 제공된다. 위의 경우처럼 자신이 선언하지 않았음에서 lexical scope에서 사용할 수 있는 변수들을 자유 변수라고 하고 자유 변수들을 포함하는 갇힌 환경을 closure라고 한다. 이제 다음 글에서는 지금까지 다룬 내용을 바탕으로 function과 arrow function의 실행을 살펴보고, JS가 lexical scope이면서도 불구하고 this가 어떤 이유로 실행시의 객체를 가리키는지를 밝히고 this에 대한 설명을 마무리하겠다. 참고자료 코드스피츠77 ES6+ 기초편 3회차 코드스피츠78 ES6+ 함수와 OOP 2회차 자바스크립트의 스코프와 클로저 Lexical scope and Dynamic Scope","link":"/2020/06/08/js-closure/"},{"title":"나의 공부를 방해했던 잘못된 사고방식","text":"우연히 읽은 어떤 글작년에 분명한 계획도 없이 분주히 컴퓨터 공학 공부를 하던 때였다. 우연히 재능과 열정이 없어도 프로그래밍을 하는 사람들이라는 글을 읽게 되었다. 글을 읽고 나서 나는 뒤통수를 얻어 맞은 것 같은 충격을 받았다.(크게는 아니고 많이 아프게… 그게 그거…) 위의 글은 원래 medium에 게시된 영어로 작성된 원글을 번역한 글이었는데, 글의 주요내용은 이랬다. 프로그래밍은 프로그래밍에 대한 특별한 재능과 열정이 있는 사람들만 할 수 있는 것이 아니다. 프로그래밍은 꾸준히 학습해서 연마해야 할 일련의 기술들일 뿐이다. 그러면서 Django의 Co-Creator인 Jacob Kaplan-Moss(이하 Jacob)를 비롯하여 Bootstrap, PHP, Rails를 만든 사람들이 공통적으로 자신들이 프로그래밍에 특별한 재능이 있는 사람은 아니라고 밝힌 글이나 인터뷰들을 인용한다. 나는 이 사람들이 정말 이런 말을 했는지 궁금했는데, 당장 내가 Django를 공부하고 있어서 Jacob이 어떤 맥락에서 그런 말을 했는지 찾아보게 되었다. 해당 글에서 인용된 말은 Pycon 2015에서 그가 keynote 강연에서 했던 발언이었다. Jacob의 강연은 글에서 인용된 내용 이상으로 유익한 내용이 많았다. 강연의 일부 내용을 소개하겠다. Jacob의 Pycon 2015 KeynoteHi, I’m Jacob, and I’m a mediocre programmer Django의 창시자로 유명한 Jabob은(스스로 Inventor는 아니고 Co-Creator라고 말했다.) 2015 Pycon에서 기조 연설을 하는데, 그는 연설을 시작하면서 겸손하게 자신이 기조 연설을 할만한 자격이 없음에도 불구하고 연설자가 된 사실을 영광스럽게 생각한다고 말한다. 그리고 그의 시작하는 말은 앞으로 그가 전달하고자 하는 메세지와 큰 연관이 있었다. 사람들 대부분이 Jacob 자신이 훌륭한 개발자이기 때문에 성공했다고 생각하지만 그는 자기 자신을 이렇게 소개한다. "I'm at best average programmer"라고. Bell Curve Django라는 거대한 프레임워크를 개발한 사람의 지나친 겸양이라고 생각할 수도 있지만, 그는 bell curve, 우리가 잘 알고 있는 표준 정규 분포 그래프를 보여주면서 표준 정규 분포에 대한 우리의 상식을 상기시킨다. 그 상식은 바로 대부분의 분포는 정규 분포를 따르게 되어 있으며, 대다수의 사람은 분포의 중앙에 위치하고 특별하게 잘하거나 못하는 사람들이 양쪽 끝에 위치한다는 것이다. 그런데 이상하게도 개발업계에 정규분포에 반하는 상식이 있다는 것을 지적한다. 특히 자기 자신이 아주 뛰어난 개발자라는 사실을 어떻게 알 수 있냐고 묻는다. 코드의 라인 수를 보고서 할 수 있는것인지, 아니면 story point(agile 개발에서의 평가 기준 중 하나)를 보고서 평가하는 것인지, 그렇다면 도데체 story point는 무엇인지 질문한다. 그는 개발자들이 논리적이고 분석적이고 사실에 기반한 분야에서 일한다고 믿고 싶어하지만 실제로 우리가 하는 일(개발 실력)에 대해서 말할 수 있는 기술적이거나 시스템적인 방법이 없다고 말한다. 그래서 우리가 평가할 만한 마땅한 방법이나 데이터가 없기 때문에 스토리를 말하는데, 사람들의 프로그래밍 능력에서도 마땅히 평가할 지표가 없기 때문에 흔히 그 사람의 일화나 이야기들을 말한다. Talent Myth 문제는 이런 이야기들은 이야기로 전달되기 때문에 결론적인 평가가 단순화 된다는 것이다.(어떤 기준에 따라서 평가되기 보다는 그 사람의 개발 능력에 대한 추상적인 이미지밖에 없기 때문에) 그래서 그 사람이 끔찍하다거나 그 사람이 쩌는 능력을 가졌다는 식의 이야기를 하게 되고 끔찍함과 쩜(?)의 사이에는 그 어떤 공간도 없게 된다. 사람들은 어떤 사람을 훌륭한 프로그래머라는 바구니와 앉을 자리도 아까운 프로그래머라는 바구니 이 두 바구니 안에만 집어 넣게 되는데, 이런 양극단적인 평가는 앞서 언급한 정규 분포와는 정반대의 분포를 만든다. 이런 평가가 적절하려면 가운데에 분포한 사람이 가장 없고 대다수의 사람들이 끔찍하거나 훌륭한 양쪽 끝에 분포해야 한다. 하지만 개발자들에 대한 분포만 정규분포를 따르지 않는다는 것은 재능 미신(talent myth)일 뿐이다. 이런 재능 미신의 문제는 결국 프로그램 실력이 rock star나 ninja급이 아니라면 프로그램 할 수 없는 세계를 만들어 낸다는 것이다. 그는 만약에 이런 미신이 개발업계에 만연하게 되면 사람들이 계속 개발 분야에 남아있을 수 없게 만들고, 개발 업계에서 떠나게 만들고, 계속 성장하고 발전하는 것을 방해하게 된다고 말한다. Programming isn’t a “passion” or a “talent” but a collection of acquired skills그는 몇년 전에 Kansas University에서 열린 GIS(Geographic Information System)-day 행사에 참석했을 때의 일화를 이야기 한다. 해당 행사 오후 프로그램 중에는 학생들이 자신들의 연구 성과물을 발표하는 프로그램이 있었다. 학생들의 발표들은 기술적으로도 준비가 잘되어있을 뿐더러 흥미로운 주제들을 다루었었다. 그 프로그램에서 한 학생이 매우 뛰어난 발표를 했었다. Kansas 지역에서의 계절성 홍수를 예측하는 시스템이었는데, 역사적인 데이터들과 유량 분석, 강우량 데이터들 등을 사용한 시스템이었다. 그 학생이 사용한 프로그램 도구들은 Pycon 참석자들에게 꽤 익숙한 도구들인데, 그 학생은 AWS, Linux, PostgreSQL, Django, Geodjango를 사용했다. Jacob은 당시 파이썬 개발자를 고용하고 있었기 때문에 몇천줄의 파이썬 코드를 작성한 그 학생에게, 학생이 원하면 면접을 보고 싶다고 말했다. 그런데 그 학생의 대답은 ‘아니요, 그럴 수 없어요, 저는 진짜 프로그래머가 아닌걸요.’이었다. 그 학생은 클러스터 분산 GIS 처리 데이터 파이프 라인을 만들었다. 그럼에도 불구하고 그 학생은 진짜 프로그래머가 아니라고 대답했다. 왜냐하면 ‘개발은 talent myth안에 속한 사람이 하는 일이지 결과물을 만들기 위해 내가 한 일이 아니다’라는 생각 때문이다. 그러나 진실은 개발은 열정이나 선천적인 재능이 아니라 일련의 습득해야 하는 기술들일 뿐이다. 개발은 배울 수 있다. 대다수의 다른 기술들처럼 개발 역시 뛰어난 수준으로 할 수도 있고, 취미생활로도, 파트타임으로도 풀타임으로도 할 수 있다. 만약 우리가 이런 기술들을 평균정도로 가지고 있어도 괜찮다는 것을 인정한다면, 개발 업계에 새로 들어오는 신입들을 더 친근하게 맞아들일 수 있다. 이전에는 그렇지 않았었는데한동안 나 스스로도 개발에 재능이 없는 한 개발자가 될 수 없는데 나는 재능이 없다. 하지만 당장 상황이 산업기능요원을 해야하니깐 현실적으로 공부는 해야겠지라는 생각으로 공부를 하고 있었다. 안타깝게도 이런 마음 상태로는 좀 더 발전하고 싶다던가, 가능성이 있다는 생각보다는, 역시 나는 안되는 건가 하는 생각이 더 많았다. Jacob의 강연을 들으면서 왜 이런 생각을 가지게 되었을까? 생각해보았다. 고등학교 1학년 겨울방학 때였던 것 같다. 당시 나는 수학 공부를 잘 해보고자 꽤 노력 중이었다. 그 노력 중 하나로 방학 때 개설되었던 수학특별반을 수강 신청했다. 이름은 거창하게 수학 특별반이지만 문과였던 우리가 경시대회에 나갈 것도 아니었고, 주로 다루었던 내용은 이전에 배웠던 내용들의 기초들을 질문해보는 것이었다. 지금 기억나는 것은 예를들면 함수의 그래프가 양의 방향으로 움직이는데 왜 함수식은 마이너스로 표시하는지, 허수 i의 제곱이 정말 -1이 되는지, 원을 정의하는 몇 가지 방식들 이런 것들이었다. 나는 그 수업이 어려웠다. 나와는 다르게 다른 친구들은 대답도 잘했고 탈레스 정리니하는 것들을 잘 알고 대답한다는 것에 위축되기도 했다. 그러면서도 당시에 위축될 때마다 ‘오늘부터 알면 되지’라는 생각으로 쉽게 전환이 되었다. 내가 수학자를 할 것도 아니었고, 오늘 모르는 걸 오늘 학습하면 된다고 생각을 했기에 이렇게 공부해봤자 얼마나 잘 할 수 있을지라던가 그런 고민은 없었다. 그래서 비록 입시 수학이라고는 했지만 수학적 사고를 연습하고 문제를 해결하는 과정을 굉장히 즐거운 공부였다. 수학공부에 꽤나 재미를 붙이게 되어서 문과였음에도 불구하고 다른 과목들보다 시간을 많이 쏟았다.(그래서 언어와 외국어 점수가 안좋았…) 대학교에 가고 보니내가 졸업한 대학교는 모든 1학년 학생이 무전공인 단일 학과에 속해있다가 1학년 말에 전공을 선택하고 2학년때부터 전공을 시작하는 시스템이었다. 그래서 고등학생때 문과였던 친구가 이과를 선택하거나 반대인 경우가 흔했다. 나도 본래 문과였으나 1학년 떄 들었던 교양과목에서 배운 html css가 나름 재밌었기에 전산공학을 전공으로 선택했다.(그리고 그 결정을 후회했다…) 지금 돌이켜 보면 나의 커리큘럼은 상당히 엉망이었는데, 딱히 조언을 받지 않았기 때문에 2학년 때 들어야 할 자료구조 수업을 건너뛰거나 3학년때 4학년 전공을 듣거나 했다. 이렇게 하더라도 프로그래밍을 어떻게 하면 될지 터득할 수 있었으면 상관 없었겠지만, 졸업할 때까지 계속 헤멨다. 특히 2학년 때 들었던 외부 강사 특강에서 프로그래밍은 여기에 맞는 재능을 가지지 못하면 할 수 없는 것처럼 잘못 받아들이게 된 것 같다. 그 뒤에 프로그래밍이나 공학 공부, 그리고 진로 문제에서 헤멜 때마다 ‘아 역시 나는 재능이 없어서 이 분야에 계속 할 수 없는건가’라는 생각에 자주 휩싸였다. 이런 생각 때문에 고등학교 때처럼 내가 모르는 것에 부딛혔을 때에 새로 터득하면 된다는 사고방식으로의 회귀가 이루어 지지 않았다. 그래서 더 발전할 수 있었던 것도 하지 못했던 것 같다. 앞으로는 어떤 태도로 공부하는 게 좋을까코드스피츠에서는 현업 개발자들을 위한 스터디 강의를 유투브에 무료로 공개한다. 지금 코드스피츠의 강의들이 굉장히 큰 도움이 되고 있고, 학부 때 따로따로 존재했던 컴퓨터 공학 지식들이 서로 연결이 되고 있는데, 강의를 진행하는 맹기완 대표님은 Javascript 스터디 1강에서 개발자에게 요구되는 자세가 무엇인지를 언급한다. 개발자에게 가장 먼저 요구되는 자세는 개발에 대한 흥미나, 열정이 아니라 개발 산업에 대한 진지함이라고 이야기 한다. 개발산업은 산업이기 때문에 산업에 맞는 진지함이 필요하다. 물론 흥미나 열정이 있는 사람에게 진지함이 있을 가능성이 높겠으나, 우리가 쉽게 이 둘의 차이점을 혼동한다고 말했다. 대표님이 2016년에 신입사원 공채를 위해 작성한 글에서 자신의 회사가 추구하는 것을 고객의 니즈와 예산, 시장의 변화 속에서의 제품의 가치와 방향을 기획하여 뛰어난 프로그래밍 실력으로 이를 실현하는 회사라고 말하는데, 개발을 열정적으로 한다던지 기술을 배우는 것에 아주 큰 흥미가 있다던지가 아니었다. (물론 산업종사자가 아니라 컴퓨터 공학 학문을 하는 사람에게는 해당 주제에 대한 열정이나 흥미가 더 중요할 수도 있다.) 나는 여태까지 재밌는 취미활동을 열정적으로 하듯이 개발 공부를 했다는 것을 깨닫게 되었다. 우선 기본적으로 나도 리누스 토발즈 급의(뭔가 기준을 너무 극단적으로 잡은 것 같다…) 개발자가 되지 못한다 하더라도 당연히 괜찮고, 평균적인 프로그래머가 되어도 괜찮다. 다만 이 말은 극복할 지점에서 노력하기를 포기하고 안주하겠다는 것이 아니라, 특별히 뛰어난 이름난 개발자가 되지 못한다 하더라도 계속해서 개발 산업에 종사할 수 있으며, 개발 산업에 종사하기 위한 공부와 노력을 지속해 나가겠다는 뜻이다. 아직까지도 나의 컴퓨터 공학이나, 개발의 수준이 얕지만(매우 얕…) 더 노력하면 더 발전이 가능하며 할 수 있는만큼 발전이 가능하다. 이런 마음을 가지다 보니 내일 배울 내용들이 더 기대가 되고 지식들이 살처럼 붙는 것 같다. 앞으로 배울 개발 공부들이 더 기대가 된다.","link":"/2020/04/15/restart/"},{"title":"JS Function과 Arrow Function","text":"앞의 글에서는 JS가 lexical scope을 사용하는 언어인데도 불구하고 왜 this가 함수 실행 때 binding되는지 문제제기 했다. 또한 lexical scope와 dynamic scope에 대해서, lexical scope임에도 동적으로 함수가 생성되는 특징 때문에 생겨나는 closure에 대해 다루었다. 이번 글에서는 function과 arrow function의 실행을 다루면서 왜 this가 실행 때 binding되는지와 closure를 사용함으로써 function과 arrow function의 this가 어떻게 달라지는 지 알아보도록 하겠다. 그래서 this는 실행 시에 binding되는거야?사실 이번에 다루는 주제 또한 JS에서는 함수 또한 Object 객체로부터 만들어진 객체라는 지식과, 객체 간 prototype chain을 통해 이루어 지는 유사 상속에 대한 사전 지식이 필요하다. 하지만 해당 주제들은 단일 주제로 다루어야 할만큼 꽤 많은 내용이기 때문에 해당 내용을 안다는 전제 하에 설명을 하겠다.(사실 쉽고 간결하게 설명할 역량이 부족합니다…) ※ 함수 또한 Object 객체로부터 만들어진 객체라는 사실은 함수를 생성한 후에 생성된 함수의 prototype 값을 확인해 보면 proto값이 Object라는 사실로 확인할 수 있다. this example 1234567891011function foo() { console.log(this.a); // this points for what?}var bar = { a: 10, foo: foo}foo(); //undefinedbar.foo(); //10 위의 예제는 지난 글에서 다루었던 예제이다. 위의 예제를 보면 마치 함수 foo에는 this 값이 없어서 this 값을 외부에서 찾아야 할 것 같아 보인다. 그런데 사실은 그렇지 않다. 우리는 JS에서 함수가 실행될 때 주어진 변수만 받아서 쭉 실행되는 것처럼 생각하지만 사실 JS의 함수는 그렇게 동작하지 않는다. JS에서 함수가 동작하는 방식JS에서 함수가 동작하는 방식을 이해하려면 앞서 언급했던 JS에서는 함수도 객체라는 사실을 기억해야 한다. JS에서 함수가 생성될 때는 JS 내부적으로 Function constructor가 함수를 생성한다. contructor가 함수를 생성할 때는 함수 내부에 즉시 prototype이라는 key를 만들고 오브젝트를 할당한다. 그 다음 prototype 오브젝트에 constructor라는 키를 잡고, 함수 자신의 참조 값을 저장한다. 따라서 JS에서 생성된 함수는 다른 언어에서의 함수와는 다르게 그 자체가 객체인 것이다. 아래의 예제는 함수 생성 과정을 간단히 설명한 예제이다. JS내부에서는 아래의 예제의 과정이 자동적으로 이루어진다. JS 함수 생성 과정 12345678910//함수가 생성되면function test() {}//1. 즉시 prototype이라는 키에 오브젝트가 할당되고test.prototype = {};//2. contructor에 함수 자신의 참조 값을 저장한다test.prototype.constructor = test//출처: 클래스 기반 언어 vs 자바스크립트 1/3//(https://www.bsidesoft.com/318) 그러면 위의 과정으로 만들어진 함수는 JS Function 객체 prototype의 모든 메소드들에 접근할 수 있고, 사용할 수도 있다. 그리고 JS 함수는 함수를 실행할 때 Function.prototype.call함수를 사용해서 실행한다 Function.prototype.call MDN 문서 Function.prototype.call 구문 정의 func.call(thisArg[, arg1[, arg2[, …]]]) Function.prototype 메소드들이 여러가지 있지만, JS에서 함수를 실행 할 때는 내부적으로 Function.prototype.call에 의해 이루어 진다. Function.prototype.call은 두 종류의 인자를 받는다. 첫번째로 받는 인자는 thisArg로 객체의 참조 값을 받는다. 두번째로 받는 인자는 함수의 인자들을 배열로 묶은 argList이다. 실제로 console에서 arguments를 확인해보면 각각의 인자들을 확인해볼 수 있다. 함수 인자 확인 12345function test(a, b, c){ console.log(arguments[0], arguments[1], arguments[2]);}test(1, 2, 3); // 1, 2, 3 이를 통해 알 수 있는 사실은 함수에서 this값은 binding되는 게 아니라 인자로 주어진다는 것이다. 위의 예제에서 test함수는 a, b, c 세가지의 인자만 받는 것이라고 생각하지만, 실제 실행 시에는 Function.prototype.call이 사용되며 자동으로 현재 객체의 참조 값이 thisArg로 전달된다. 따라서 this는 lexical scope의 예외가 아니다. this 값은 함수 내부적으로 주어지는 값이다. this example 1234567891011function foo() { console.log(this.a); // this points for what?}var bar = { a: 10, foo: foo}foo(); //undefinedbar.foo(); //10 위의 예제를 다시 보면 foo 함수가 실행될 때, Function.prototype.call에 this 값으로 전역 객체 window가 주어지는 반면 bar.foo 함수가 실행될 때는 foo함수의 this값으로 bar객체의 참조 값이 주어진다. 이제 this에 대한 의문이 풀렸다. 함수의 this가 실행 시의 객체인 이유는 dynamic binding이기 때문이 아니라 함수 내부적으로 this 값이 인자로 전달 되기 때문이다. Arrow Function그런데 내부적으로 this값을 주는 방식으로 함수가 실행되었을 때 불편한 점이 있다. this 값으로 전역객체가 주어질 때 123456789101112131415function Person() { // Person() 생성자는 `this`를 자신의 인스턴스로 정의. this.age = 0; (function growUp() { // 비엄격 모드에서, growUp() 함수는 `this`를 // 전역 객체로 정의하고, 이는 Person() 생성자에 // 정의된 `this`와 다름. this.age++; })();}var p = new Person();console.log(p.age); //0//출처: https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Functions/%EC%95%A0%EB%A1%9C%EC%9A%B0_%ED%8E%91%EC%85%98 (mdn예제를 일부 수정) 위의 예제를 보자. Person 생성자 함수가 있고 생성자 함수 안에는 즉시 실행함수 growUp이 this의 age값을 1 증가 시킨다. 문제는 growUp함수에 입력되는 this 값은 Person의 this 값이 아니다. JS에서 함수들은 객체에서 실행되지 않는다면 this값으로 window객체가 주어진다. 따라서 growUp함수에서 사용하는 this는 Person의 인스턴스가 아니라 전역객체 window이다. 그래서 p.age를 출력해보면 age값이 변하지 않고 그대로 0이 출력된다. closure 을 이용한 this binding 12345678910111213function Person() { var that = this; that.age = 0; (function growUp() { // 콜백은 `that` 변수를 참조하고 이것은 값이 기대한 객체이다. that.age++; })()}var p = new Person();console.log(p.age); //1//출처: https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Functions/%EC%95%A0%EB%A1%9C%EC%9A%B0_%ED%8E%91%EC%85%98 (mdn예제를 일부 수정) 그러면 growUp함수에서 Person 인스턴스를 사용할 수 있는 방법이 없는 것인가? 그렇지 않다. JS의 특징인 closure를 사용하여 우회적으로 사용할 수 있다. 위의 예제를 보면 Person 생성자 함수가 인스턴스 참조 값인 this를 that 변수에 저장한다. growUp 함수는 that 변수가 없기 때문에 자신이 생성되었을 때의 환경에서 자유변수들을 탐색한다. Person 생성자 함수 안에서 Person 인스턴스 참조가 저장된 that 변수를 발견했기 때문에 that.age를 1 증가시킨다. 따라서 p.age를 출력해보면 1이 출력되는 것을 확인할 수 있다. 그런데 위의 방식으로 일일이 인스턴스 참조값을 따로 저장해서 사용하는 방식은 불편하다. 그래서 es6부터는 arrow function이 생겼다. arrow function MDN 문서 this 설명 일부 … EC2015는 스스로의 this 바인딩을 제공하지 않는 화살표 함수를 추가했습니다(이는 렉시컬 컨텍스트안의 this값을 유지합니다). this 문서를 보면 arrow function은 스스로의 this 바인딩을 제공하지 않는다고 설명한다. 이는 기존의 일반 함수들이 내부적으로 Function.prototype.call을 실행하여 this를 인자로 넘기는 방식으로 작동하지 않는다는 의미다. 괄호 설명을 보면 arrow function이 렉시컬 컨텍스트 안의 this 값을 유지한다고 말하는데, arrow function 문서에서는 arrow function이 렉시컬 컨텍스트 안의 this 값을 유지한다는 말을 다른 말로 설명했다. MDN 문서 arrow function 설명 일부 화살표 함수는 전역 컨텍스트에서 실행될 때 this를 새로 정의하지 않습니다. 대신 코드에서 바로 바깥의 함수(혹은 class)의 this값이 사용됩니다. 이것은 this를 클로저 값으로 처리하는 것과 같습니다. … 즉, arrow function의 경우에는 인자로 this가 주어지지 않기 때문에 앞의 예제에서처럼 closure를 사용해 this를 binding하는 것과 동일하게 작동하는 것이다. 이때문에 arrow function은 call, apply를 사용해서 this 값을 인자로 넘겨줘도 넘겨 받은 this를 사용하지 않고 closure의 this를 사용한다. 아래의 arrow function을 사용한 예제를 보면 앞에서 closure를 사용해 this를 binding했을 때와 동일하게 작동하는 것을 확인할 수 있다. arrow function을 사용한 this binding 123456789101112function Person() { this.age = 0; (() => { // arrow function은 closure에 있는 this값을 사용한다. this.age++; })()}var p = new Person();console.log(p.age); //1//출처: https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Functions/%EC%95%A0%EB%A1%9C%EC%9A%B0_%ED%8E%91%EC%85%98 (mdn예제를 일부 수정) 정리 JS에서 일반 함수들은 내부적으로 Function.prototype.call함수를 통해 실행된다. Function.prototype.call함수를 통해 실행될 때 this값과 arguments들이 인자로 주어진다. 따라서 JS에서 this가 실행 시에 결정되는 이유는 dynamic binding처럼 작동하기 때문이 아니라 실행 시에 인자로 주어지기 때문이다. 그런데 위와 같이 작동하는 경우 함수 내의 함수는 this 값으로 자신을 생성한 함수를 받지 못하고 전역객체 window를 받는다.(비엄격모드일 때라는 조건이 있다.) 이럴 경우 내부 함수는 closure를 사용하여 this 값을 우회적으로 받아야 한다. arrow 함수는 this가 내부적으로 binding되지 않고 closure 값을 사용하는 것처럼 this가 binding 된다. 참고자료 자바스크립트의 Function 호출과 this MDN this 문서 MDN arrow function 문서","link":"/2020/06/11/js-function/"},{"title":"Til 1일차","text":"TIL 1일차 - this에 대해 작성한 2개의 글처럼 작성하려면 시간이 많이 소요되기 때문에, TIL에서는 당일 새롭게 알게된 내용들을 간략하게 정리하고 어느정도 공부가 축적되면 단일 주제에 대해서 작성하도록 하자 이번주에는 HTML과 CSS를 공부한다. 공부자료는 크게 2가지 인데, 하나는 ‘모던 웹을 위한 HTML5+CSS3 바이블 3판(윤인성 저)이고 다른 하나는 코드 스피츠 CSS Rendering 강의 6개이다. HTML과 CSS를 사용해왔지만 단일주제로 HTML과 CSS만을 공부해 보는 것은 이번이 처음이다. 그리고 역시나 코드 스피츠 강의는 빡세다… 새로 알게 된 내용HTML 웹 표준에서 지원하지 않는 태그 1<food>My Favorite Food</food> 웹 브라우저에서는 웹 표준에서 정하지 않은 태그도 정상적으로 출력한다. 이 때문에 루비 태그를 지원하지 않는 브라우저에서도 루비 태그를 사용한 html 문서를 출력할 수 있다.(물론 태그가 브라우저에게는 아무 의미가 없기 때문에 원하는대로 작동하지 않는다) select 태그 form 양식에 속해 있는 select 태그는 일반적으로 잘 사용하지 않는다. 이유는 ui가 데스크탑에서 예쁘지 않는데 ui양식을 수정할 수도 없기 때문이다. 그래서 많은 웹 페이지들의 경우 JS과 div를 이용해서 select 기능을 직접 만든다. CSS selector가 존재하는 목적 selector가 존재하는 목적을 다른 CSS 사용자들은 당연히 알고 있었겠지만, 나는 스스로 명확하게 한 문장으로 설명을 못했다. selector로 특정 element의 스타일을 바꾸는 작업을 계속 했음에도 selector가 뭔지 한 문장으로 설명을 못했다.(좀만 생각해보면 쉽게 답할 수 있는데…) 이제 selector가 존재하는 이유를 한 문장으로 설명할 수 있게 되었다. 특정한 HTML 태그를 선택할 때 사용한다. 전후 문자 선택자 간혹 웹페이지 소스 코드를 확인해 보다가 ::after 혹은 ::before가 나올 때 해당 선택자의 역할을 모르지만 검색해보지 않았었다. 이제 이 두가지 선택자의 기능을 알게 되었다. 이 두가지 선택자는 태그 전,후의 text를 선택하는 전후 문자 선택자로서, 선택자 중에서 유일하게 content 속성을 사용할 수 있다.(js를 사용하지 않고도 태그 내의 content 값을 바꿀 수 있다.) 12345678910111213141516171819...<style> p::before{ content: \"📘. \"; } p::after { content: \" - \" attr(data-page) \" page\"; } } p::first-letter { font-size: 3em; }</style>...<p data-page=\"10\">Lorem ipsum dolor sit amet, consectetur adipiscing elit.</p>// 모던 웹을 위한 HTML5+CSS3 바이블 3판, 윤인성 저, 145p, 예제 일부 수정 위의 예제의 경우 p태그 앞에는 📘. 가 추가로 붙게 되고 p태그 뒤에는 p태그 속성 data-page(data-를 붙인 사용자 정의 속성)값 10을 받아서 - 10 page가 붙게 된다. 마지막으로 p태그 컨텐츠의 첫번째 문자 L(Lorem의 ‘L’)이 48px(기본 폰트 사이즈 16px * 3)로 커진다. line-height. text-align 속성 text-align은 block 요소 content의 수평 정렬에 사용하는 속성이다. 그런데 block 요소 content를 위한 수직 정렬을 위한 속성이 없다. line-height 속성은 block 요소 content의 수직 정렬을 우회적으로 가능하게 해준다. 웹 표준 역사, normal flow, float, overflow 코드 스피츠에서는 웹 표준 역사(거대 기업들의 땅따먹기)와 주의 깊게 봐야 할 커뮤니티를 배웠고, normal flow와 float, overflow 일부를 배웠다. 위의 내용들은 전부 새로 배운 내용이지만 정리하기 위해서는 단일 주제를 작성할 만큼의 노력이 필요하기 때문에 이후 여유가 있을 때 작성하기로 하겠다.(매우매우매우매우 유익한 수업이었다.) 2020/6/15 - 1st TIL","link":"/2020/06/15/til-1st/"},{"title":"CSS Position Schemes- Normal Flow","text":"이번 주제는 CSS Position Schemes이다. 가장 기본적인 주제이지만 그렇다고 다루는 내용이 짧은 것은 아니기 때문에 3편에 나누어서 다루도록 하겠다. 이번 글에서는 normal flow에 해당하는 static, relative를 다루고 다음 글에서는 float를 마지막으로는 absolute와 fixed를 다루도록 하겠다. 이번에 다루는 내용들은 코드스피츠 76 CSS Rendering의 강의를 정리한 것이다. Graphics System과 CSS게임, 동영상, 웹 브라우저 등등 우리가 일상적으로 컴퓨터를 사용할 때, 시각적인 요소들이 빠지지 않는다. 우리는 이런 시각적인 요소들을 당연하고 자연스럽게 받아들인다. 그런데 조금 더 생각을 해보면 이런 시각적인 요소들은 당연하지 않다. 우선 화면을 그리는 일은 그 자체로 복잡하고 계산량이 많은 작업이다. 우리가 graphics system을 사용하여 화면을 그리기 위해서는 복잡한 수학과 물리학 공식들을 알고 있어야 한다. 화면에 나타난 시각적인 요소들은 화면이 가지고 있는 무수히 많은 pixel들에게 어떤 값을 주면서 그려지는데, 심지어 화면의 내용은 실시간으로 변한다. 따라서 실시간으로 화면을 그리기 위해서는 화면 각각의 pixel에 복잡한 수학과 물리학 공식을 빠르게 계산하여 pixel에 실시간으로 값을 주어야 한다. 그런데 또 다른 문제가 있다. 우리가 사용하는 컴퓨터의 화면은 각각 다르다. 어떤 화면은 크기가 더 크고, 어떤 화면은 화소가 더 높다. 즉 각 화면마다의 pixel이 다 다르기 때문에, 계산해야 할 결과가 다 다르다. 그럼에도 불구하고 각기 다른 화면에 그려진 시각적인 요소들이 동일하게 표현되어야 한다. 여기서 우리는 graphics system의 도움을 받는데, graphics system은 복잡하고 계산량이 많은 작업인 시각적인 요소를 그리는 일을 각 화면의 크기와 화소가 다르더라도 동일하게 그릴 수 있도록 도와준다. 즉 간략하게 말하자면 화면을 그리는 일은 당연하지도 간단하지도 않은 작업이고 이를 위해 graphics system의 도움을 받는다. 그런데 웹의 graphics 기술은 보통의 graphics system과 다르게 수학과 물리학 공식들을 이해하지 않고도 화면을 그릴 수 있도록 설계되었다. 웹의 graphics 기술은 복잡한 계산 함수들을 나열하지 않고도 추상적인 언어들을 사용하여 화면을 그릴 수 있다. 이렇게 웹에서 간단하고 추상적인 언어를 통해 화면을 그릴 수 있도록 제공하는 언어가 바로 CSS(Cascading Style Sheet)이다. 일반적으로 graphics system에서 시각적인 요소를 그리는 작업은 크게 2가지 단계를 통해 이루어 진다. 먼저 시각적인 요소가 그려질 영역을 계산하는 reflow 단계와, 정해진 영역에 색깔, 질감등을 결정하여 실제 그림을 그리는 단계인 repaint 단계로 나뉜다. 브라우저가 CSS를 해석하여 그림을 그릴 때에도 동일한 단계를 거친다. 먼저 각 element들의 위치와 크기를 계산하는 reflow단계를 거친 후에 실제로 그림을 그리는 repaint 작업을 실행한다.(CSS에서는 repaint이후에도 post-process라는 단계가 더 있지만 이번 주제에서는 다루지 않는다.) 따라서 CSS의 어떤 속성들은 reflow 단계에 영향을 주지만 어떤 속성들은 repaint 단계에 영향을 준다. 이번에 다룰 주제인 CSS position은 화면을 그릴 때에 reflow 단계에 영향을 주는 CSS 속성이다. Position SchemesCSS 2.2 Visual Formmating Model 챕터의 Position Schemes 부분을 보면, Box 모델(margin, border, padding, content값으로 계산하는 기본적인 display model)의 위치를 계산할 때, 계산하는 방식이 3가지로 나뉜다고 설명한다. 첫 번째는 오늘 다룰 normal flow 방식이고, 두 번째는 다음에 다룰 float 방식이고 마지막으로는 세 번째로 다룰 absolute positioning 방식이다. 각각의 방식은 추상적인 값으로 표현된다. normal flow를 예로 들면, position 값이 static혹은 relative인 경우 해당 box는 normal flow를 통해 위치가 계산된다. 하지만 우리가 normal flow에 해당되는 position 값인 static과 relative를 읽는 것 자체로는 해당 box가 어떻게 그려질 지 가늠하기가 어렵다. 이 값들을 굳이 우리 말로 위치가 정적이고 상대적이라고 해석하는 것으로도 해당 box가 어떻게 그려질 지 알 수 없다. 따라서 우리가 이 추상적인 값 static, relative를 읽을 때, 추상적인 의미로 받아들여서는 box가 어디에 위치할 지 알 수 없기 때문에 이 값을 통해 해당 box의 위치가 어떤 방식으로 계산되는 지를 알아야 한다. 즉, static, relative라는 값을 문자 그대로 읽는 것이 아니라 화면을 그리기 위한 수학 공식이나 함수로 이해해야 한다.(다른 CSS 속성들도 마찬가지이다.) 그렇다면 normal flow에 해당하는 static, relative라는 값은 box의 위치를 결정하기 위해 어떤 값을 어떤 방식으로 계산하는 것일까? 웹은 요소를 그릴 때, 위에서 아래의 방향으로, 왼쪽에서 오른쪽 방향으로 그림을 그린다. 따라서 normal flow는 화면에 그려질 box요소의 left top의 값을 계산한다. Normal FlowNormal Flow는 우리 말로 일반 흐름이라고 해석할 수 있지만, 이렇게 해석하면 의미를 명확하게 알 수 없다. 이 단어는 CSS 공식문서에 정의된 고유 명사이기 때문에, 이 단어가 의미하는 바를 이해하기 위해서는 normal flow를 해당 box요소의 left top을 계산하는 방식으로 이해해야 한다. 이제 normal flow가 어떤 값을 계산하는 지는 알게 되었다. 그렇다면 normal flow는 어떤 방식으로 left top 값을 계산하는 것일까? CSS 2.2 Visual Formmating Model 챕터의 Normal Flow 부분을 보면 normal flow가 left top을 계산하는 방식을 3가지로 분류한다. 첫 번째는 block formatting context(이하 bfc), 두 번째는 inline formatting context(이하 ifc), 마지막으로 relative positioning로 분류한다. relative positioning의 경우 normal flow의 일부이지만, bfc, ifc 계산 이후의 추가적인 조작이기 때문에, 실제 normal flow에 해당하는 방식은 bfc와 ifc 이 두가지라고 할 수 있다. BFC와 IFCbfc와 ifc를 설명하기에 앞서서, block과 inline이 의미하는 바를 먼저 이해해야 한다. CSS의 block과 inline또한 CSS에서 사용하는 고유의 의미로 이해해야 한다. CSS에서의 block과 inline은 해당 box 요소가 공간을 자치하는 방식을 의미한다. block은 해당 요소가 부모 요소의 가로 길이를 꽉 채운 한 줄을 차지한다는 의미이다. 반대로 inline은 해당 요소의 content 영역만큼 공간을 차지한다는 의미이다. 이 때문에 inline 요소는 높이와 너비 속성 값을 줘도 적용되지 않는다. 다시 말해, bfc는 해당 box가 부모 요소의 가로 길이 전체를 꽉 채운 한 줄을 차지할 때, left top을 계산하는 방식이고, ifc는 해당 box가 content 영역만큼 공간을 차지할 때, left top을 계산하는 방식이다. normal flow로 box를 그릴 때, block 요소가 그려지는 동안은 bfc가 유지된다.(bfc 방식으로 그림을 그린다.) 그러다가 inline요소가 등장하면 ifc로 바뀐다. 위의 그림은 bfc와 ifc를 간략하게 그린 그림이다. bfc부터 먼저 살펴보면, block은 한 줄 전체를 차지한다고 했기 때문에 모든 block의 left 값은 부모의 left값과 동일하다. 그렇다면, bfc에서 관심을 가져야할 값은 top 값이다. 만약 위에가 block 요소들이었다면 계산은 간편하다. 위에 있는 block요소들의 height값을 모두 더한 값이 새로 그릴 block의 top 값이다. 동시에 bfc의 세로 길이는 bfc에 속한 block 요소들의 높이의 합이 된다. 반면에 ifc의 경우에는 inline 요소는 자신의 content만큼 공간을 차지하기 때문에, 한 줄에 여러 inline 요소가 배치될 수 있다. 따라서 ifc에서는 left 값이 어떤 값이 될지도 고려해야 한다. ifc에서 inline요소의 left 값은 같은 줄 앞에 그려진 inline 요소들의 길이의 합이 된다. 그런데 ifc에서는 inline 요소들의 가로 길이의 합이 부모의 가로 길이를 넘어버리면 다음 줄로 내려가는 기능이 있다. 그렇다면 inline 요소가 자동으로 다음 줄로 넘어 갈 때, 얼만큼 내려가야 할까? 한 줄에 그려진 inline 요소들 중 가장 height 값이 큰 요소의 height 값이 그 줄의 line height가 된다. 따라서 자동으로 다음 줄로 넘어가는 inline 요소의 top 값은 이전 줄 line height값이다. BFC, IFC 이해하기아래의 예제를 보자 See the Pen block-ex1 by psy082 (@psy082) on CodePen. 예제를 보면 red block, blue block은 block 요소이기 때문에 red block의 오른쪽에 공간이 남아 있음에도 불구하고 blue block이 다음 줄에 그려진다. 여기서 생각해볼 점은 red block이 300px만큼만 그려졌지만 차지하는 영역이 300px이라는 말이 아니다. 차지하는 영역 중에서 그림이 그려진 fragment영역이 300px인 것이다. red block은 여전히 부모의 width 만큼을 다 차지한다. 다음 예제를 보자 See the Pen inline-ex1 by psy082 (@psy082) on CodePen. block요소가 부모인 inline 요소 aaa…는 부모가 100px의 너비를 가졌다면 100px에서 끝나야 하는데, block을 뜷고 그려진다. text는 inline 요소인데, 왜 아래 줄로 내려가지 않고 부모의 너비를 넘어서 그려지는 것일까? 만약에 text를 너비 100px에 맞춰서 입력하면 줄에 맞춰서 출력된다. 다음 예제를 보자 See the Pen inline-ex2 by psy082 (@psy082) on CodePen. 이번에는 a문자열을 100px에 맞추어 출력했더니 원하는 대로 a들이 red block 안에 출력되었다. 이는 암묵적으로 브라우저가 그림을 그릴 떄, 공백 문자가 없는 문자열을 하나의 ifc영역으로 본다는 것을 의미한다. enter나 space bar 등의 공백을 주게 되면 문자열 각각은 하나의 inline요소가 된다. 다시 말해, 만약 문자열이 공백문자 없이 하나로 이어졌다면 문자열 전체가 하나의 inline width를 가지게 된다. 만약에 div 내부에 공백 문자를 사용하지 않고 하나로 이어진 문자열을 div 너비에 맞춰서 그려지도록 만들고 싶다면 wordbreak 속성 값을 줘야 한다. wordbreak 속성이 설정되면, 해당 block 안에 있는 문자열의 문자 하나하나가 inline 요소로 처리된다. 이는 브라우저의 reflow 계산양이 늘어난다는 뜻이기 때문에 wordbreak를 많이 설정하게 되면 브라우저의 렌더링이 매우 느려진다.(일반적으로 div요소의 너비를 넘을만큼의 긴 문자열을 작성하는 경우는 거의 없다. 다만 이런 예시들을 통해 block내의 inline요소가 브라우저에게 어떻게 인식되는지를 알 수 있다.) 다음 예제를 보자 See the Pen inline-ex3 by psy082 (@psy082) on CodePen. 코드 결과물을 보기 전에 위의 예제코드를 읽고 화면이 어떻게 그려질 지 예상해 보자. 만약 화면이 어떻게 그려질지 혼동이 온다면 아직 rendering system에 대한 이해가 부족한 것이다. 혼동이 온 이유를 생각해보자. 아마도 span이라는 inline 요소 내부에 red block이 왔기 때문일 것이다. red block의 부모요소는 span이고, red block이 그려지기 전에 WORLD라는 문자열이 왔다. 그러면 red block은 WORLD 옆에 그려지는지 다음 줄에 그려지는 지가 혼동이 온다. 그런데 rendering system을 이해하기 위해서는 rendering system이 DOM의 구조와 일치하지 않는다는 것을 알아야 한다. 그림이 어떻게 그려질 지 예상할 때 혼동이 오는 근본적인 이유는 rendering이 DOM의 구조와 동일하다고 생각하기 때문이다. 그러나 rendering은 element들을 그릴 때, DOM의 맥락에서 그리는 것이 아니라 bfc, ifc의 맥락에서 그린다. DOM의 포함관게에서는 inline 안에 block이 있는 구조이지만 그림을 그리는 브라우저 입장에서는 위의 코드를 그릴 때, bfc시작 -> ifc시작 -> ifc -> 다시 bfc 시작 -> 다시 ifc의 관점에서 그린다.(이는 웹에서 DOM은 의미적인 요소만을 표현하도록 하고 style은 DOM이 아닌 CSS의 조작으로 표현하도록 하는 HTML5 이후의 semantic web의 흐름과도 맞는 관점이다.) 앞의 내용을 정리해보면, position 값이 static, relative인 box 요소의 경우 box 요소의 위치를 계산할 때, normal flow 방식으로 계산한다. 해당 box가 block 요소인 경우 bfc로 그리고, inline인 경우 ifc로 그린다. bfc는 top 값에 관심이 있고, top을 계산하기 위해서는 앞에 그려진 block 요소들의 height 값을 모두 더함으로써 계산할 수 있다. ifc는 left 값에도 관심이 있고, left 값을 계산하기 위해서 앞에 그려진 inline 요소들의 width 값을 모두 더한다. 만약 inline width 값들의 합이 부모 요소의 width 값을 넘어간 경우 마지막 inline 요소는 자동으로 다음 줄에 그려진다. inline요소가 다음 줄에 넘어가서 그려질 때는 이전 줄의 inline 요소들 중 가장 height값이 큰 요소의 height값이 다음 줄에 그려지는 inline 요소의 top값이 된다. 마지막으로 이런 bfc, ifc는 rendering system이기 때문에 dom의 구조와 일치하지 않는다. 계층상 inline요소 안에 block 요소가 있다고 하더라도 rendering system은 각각을 계층적으로 보지 않고 독립적인 bfc, ifc로 그린다. 이제 마지막으로 relative positioning이 남았다. Relative Positioning앞에서 relating positioning이 bfc, ifc 계산에 대한 추가적인 조작이라고 말했다. 다르게 말하면, position: relative는 position: static으로 그림을 그린 이후에 무언가 추가적인 조작이 일어난 결과이다. 실제로 브라우저에서 그림을 그릴 때, position: relative의 경우 먼저 static으로 그림을 그린 뒤에 추가적인 위치 조정이 일어난다는 것을 확인할 수 있다. 우선 아래의 예제를 보자 See the Pen relative positioning by psy082 (@psy082) on CodePen. 이전에 그려졌던 예제와 비슷한 예제인데 다른 점은 span에 position: relative를 주었다. 그림이 어떻게 그려졌는지 살펴보자. 우선 ifc가 유지되면서 ** HELLO WORLD가 그려진다. 그러다가 red block이 등장하면서 bfc가 시작된다. !!로 인해 다시 ifc로 바뀌고 blue block이 등장했기 때문에 다시 bfc가 시작되고 그림 그리는 것이 끝난다. 여기까지가 position: static의 과정이다. position: relative는 단지 이미 position: static으로 그러진 그림에 지정한 위치 값 만큼 요소를 이동시켜서 다시 그리는 것일 뿐이다. 위의 예제를 보면 position: relative가 설정된 span요소 안의 WORLD와 red block이 위에서 50px만큼 내려와 있다. WORLD와 red block이 50px 만큼 다시 위로 올라가면 static으로 그렸을 때와 동일한 그림이다. 앞의 설명에서 브라우저에서 그림을 그릴 때, position: relative의 경우 먼저 static으로 그린 뒤에 추가적인 위치 조정이 일어나는 것을 확인할 수 있다고 했는데, 이번 예제의 경우에도 확인이 가능하다. 브라우저에서 그림을 그릴 때에 나중에 그려진 요소는 먼저 그려진 요소보다 z-index가 높다. 그래서 요소가 겹칠 때 나중에 그려진 요소가 전에 그려진 요소 위에 그려지는 것이다. 그런데 50px 만큼 내려온 red block은 blue block 위에 그려졌다. red block이 먼저 그려졌음에도 불구하고 어떻게 blue block 위에 그려질 수 있을까? 그 이유는 red block이 static으로 그려진 이후에 relative로 위치 조정이 되서 다시 그려졌기 때문에 blue block 보다 z-index가 높아졌기 때문이다. 정리하자면 relative 값은 box의 크기나 width, height 값에 변화를 일으키지 않고 단지 상대적인 위치만 이동시킬 뿐이다. 해당 요소의 reflow계산은 모두 static에서 이루어진다.(static에서 width와 height가 모두 결정된다.) html element들은 position 값을 따로 주지 않는다면 기본적으로 그 값이 static이다. 따라서 대부분의 element들은 normal flow를 통해 계산된다. 그런데 만약 position: absolute나 position: fixed를 사용하는 경우 더 이상 normal flow로 계산되지 않기 때문에 width와 height값을 자동으로 설정해주지 않고, 위치도 자동으로 잡아주지 않는다. 따라서 position: absolute나 position: fixed인 요소들은 반드시 width와 height값을 직접 지정해 주어야 하고 위치 값도 직접 지정해 주어야 한다.(다시 말해, position: absolute, position: fixed일 때 위치 값과 크기 값을 지정해 주는 이유는 normal flow가 아니기 때문이다.) ※ 추가: inline-block많은 글에서 block, inline, inline-block을 같이 다루지만 실제 CSS spec에서는 block, inline과 inline-block이 다른 분류에 속한다. CSS에서 element를 그리는 방식은 display model이라는 큰 범주에서 갈라진다. display model은 6개의 분류로 나뉘는데, 오늘 다루는 normal flow의 block과 inline은 display-outside에 해당하고, inline-block은 display-legacy에 해당한다. inline-block이 legacy에 해당하는 이유는 block과 inline의 관심사가 다름에도 불구하고 두 값이 동일하게 display 속성의 값이기 때문에 동시에 사용할 수 없어서 아예 별도로 inline-block값이 생겨났기 때문이다. 좀 더 설명을 하자면 앞서 이야기 했던 것처럼 block요소는 fragment만큼만 그려지지만 실제로는 부모 길이 한 줄 전체를 차지한다. 이 때문에 옆에 공간이 남아 있음에도 불구하고 공간을 사용할 수 없다. 만약에 block 요소이지만 fragment만큼만 공간을 차지하고 그림이 그려지지 않은 남은 공간도 inline요소처럼 사용하고 싶은 경우에는 display: inline-block을 설정하면 되고 이 경우 block 요소지만 ifc처럼 그려진다.","link":"/2020/07/20/css-position/"},{"title":"CSS Position Schemes- Float","text":"이번 주제는 CSS Position Schemes의 두 번째 방식인 float이다. float가 생성될 때 발생하는 4가지 일을 보면서 float가 box요소의 위치를 계산하는 방식을 이해해 보겠다. 원래 float가 overflow 속성을 가진 요소와 함께 그려질 때의 특이 사항도 다루어야 하지만 사정상(너무 길다…) 해당 내용은 다음에 다루도록 하겠다. 이번에 다루는 내용들은 코드스피츠 76 CSS Rendering의 강의를 정리한 것이다. Float가 생성되면 발생하는 일어떤 element가 float 요소가 되면 다음의 4가지 일이 발생한다. new bfc: 해당 float 요소부터 새로운 bfc가 생성된다. float over normal flow: float로 인해 새로 생성된 bfc에 normal flow로 다른 block 요소가 그려질 수 있다. 이 경우 normal flow로 그려진 block 요소 위에 float 요소가 겹쳐서 그림이 그려진다. text, inline guard: float로 인해 새로 생성된 bfc 이후에 생성된 inline 요소의 경우 float 요소와 겹쳐서 그려지지 않고 float 요소가 차지하는 영역만큼 밀려서 그려진다. line box: float는 새로운 bfc를 생성하지만 bfc 방식으로 위치가 결정되지 않는다. line box 방식으로 위치가 계산된다. 이제부터는 float로 인해 발생하는 각각의 일들을 살펴보도록 하겠다. New BFC and Float Over Normal Flow See the Pen bfc+float by psy082 (@psy082) on CodePen. 위의 예제를 보자. red box이후에 그려지는 green box는 float 요소가 되었다. 따라서 앞의 red box와 동일한 bfc에서 그려지는 게 아니라 앞의 bfc와는 다른 새로운 bfc가 시작된다. 따라서 float 요소는 앞에 그려진 red box와는 겹치지 않지만(bfc가 다르기 때문에) 새로 생성된 bfc에 포함된 sky box와 겹쳐서 그려진다. float의 의미대로 float 요소인 green box가 sky box위에 떠 있는 것이다. ※ 좀 더 생각해볼 점: 따라서 float 요소를 다단으로 여러개 만들면, 그 때마다 새롭게 bfc가 생성되기 때문에 브라우저의 계산량이 늘어난다. 그렇다면, float로 인해 새롭게 생성된 bfc 영역의 크기는 얼마만큼일까?(normal flow에서 bfc의 크기는 부모요소의 너비와 block요소들의 높이 값들의 합이었다.) 바로 float 영역 전체와 inline 영역 전체가 차지하는 공간 끝까지이다. Text, Inline Guard See the Pen bfc+float ex2 by psy082 (@psy082) on CodePen. 위의 예제를 보자. HELLO는 green box가 float가 아니었더라면 green box 다음 줄에 위치할 것이다. 그러나 green box가 float가 되면서 새로운 bfc가 시작되었고, HELLO의 등장으로 새로운 ifc가 다시 시작되지만 green box가 float이기 때문에 green box가 차지하는 만큼 HELLO가 밀려서 그려진다. 재밌는 점은 뒤에 그려진 sky box의 경우, float가 block요소의 경우에는 guard로 작동하지 않기 때문에 겹쳐서 그려진다. 그러면서 동시에 sky box 안의 WORLD라는 text는 inline 요소이기 때문에 inline guard에 걸려서 또 float요소가 차지하는 만큼 밀려서 그려진다. 정리하자면 float요소는 float요소 내부의 inline요소가 아니라면 inline요소와 겹쳐서 그려지지 않는다. 즉, float는 inline 요소에 대하여 guard로 작동한다. 따라서 WOW를 제외한 다른 문자들은 green box와 겹치지 않게 그려진 것이다. Line Boxfloat 요소의 위치는 line box라는 개념을 사용하여 그려진다. 아래 예제를 보면서 float가 어떻게 그려지는 지 살펴보겠다. See the Pen float Line Box by psy082 (@psy082) on CodePen. 혹시 위의 코드를 읽는 것만으로도 그림이 어떻게 그려질 지 예상할 수 있다면, 이 글을 읽지 않아도 된다.(그런 분은 애초에 이 글을 읽으려고 하지 않으시겠지…) 하나씩 하나씩 단계별로 그림이 어떻게 그려지는 지 살펴보자. 아래의 모션은 위의 float 요소들이 단계별로 어떻게 그려지는 지를 보여주는 모션이다. 기본적으로 float 요소들은 line box 내부를 순서대로 차지하면서 그려진다. line box는 bfc 전체 영역을 차지한 상태이다. 1 번째 green box는 float: left이기 때문에 line box 제일 왼쪽에 붙어서 위치한다. 즉, 현재의 line box의 왼쪽 200px을 차지한다. green box가 왼쪽 200px을 차지함에 따라서 line box의 너비가 300px로 줄어 들었다.(높이는 상관이 없다.) 2 번째 yellow box는 float: right이기 때문에 너비 300px의 line box 오른쪽 50px을 차지한다. line box의 너비가 250px로 줄어들었다. 3 번째 yellow box가 float: right이기 때문에 line box 오른쪽 50px을 차지한다. line box의 너비가 200px로 줄어들었다. 4 번째 green box가 float: left이기 때문에 line box 왼쪽 150px을 차지한다. line box의 너비가 50px로 줄어들었다. 5 번째 yellow box가 float: right이기 때문에 line box 오른쪽 150px을 차지해야 겠지만 line box의 너비는 50px밖에 되지 않는다. 그려야 하는 float 요소가 line box보다 큰 경우 line box의 영역이 변한다. line box의 영역을 바꿀 때는 line box의 top을 변화시키는데, 현재까지 그려진 float 요소들 중에서 height 값이 제일 작은 요소의 height 값이 새로운 line box의 top값이 된다. 따라서 현재까지 그려진 float 요소들 중에서 height 값이 제일 작은 4 번째 green box의 50px이 바뀔 line box의 top 값이 된다. 새롭게 구성된 line box는 이전 line box에서 50px 아래로 내려와 너비 200px이 되었다. 5 번째 yellow box는 새롭게 구성된 line box의 오른쪽 150px을 차지한다. line box의 너비가 50px이 되었다. 6 번째 green box가 float: left이기 때문에 line box 왼쪽 150px을 차지해야 겠지만 5 번째 경우와 동일하게 너비가 50px밖에 되지 않으므로 line box를 새로 구성한다. 새로 line box를 구성하기 위해 height 값이 가장 작은 요소인 3 번째 yellow box의 height가 선택되었다. 그러나 새롭게 구성된 line box의 너비도 50px밖에 되지 않는다.(5 번째 yellow box가 3 번째 yellow box보다 더 아래까지 그려졌기 때문이다.) 따라서 line box를 또 새롭게 구성한다. 다음으로 height 값이 작은 5 번째 yellow box의 height값을 기준으로 구성한 line box의 너비는 250px이다. line box내에 6 번째 green box를 그릴 수 있으므로 왼쪽 150px을 차지하도록 그린다. line box의 너비가 100px이 되었다. 7 번째 green box가 float: left이기 때문에 line box 왼쪽 150px을 차지해야 하지만, line box가 100px이므로 이번에도 line box를 새롭게 구성해야 한다. 2 번째 yellow box의 높이가 제일 낮으므로(1 번째 green box도 높이가 2 번째 box와 동일하지만 line box는 기본적으로 float: left요소와 float: right 사이에 위치하도록 구성되기 때문에 1 번째 green box가 선택되지 않고 2 번째 yellow box가 선택된다.) 2 번째 yellow box 아래에 구성되는 line box의 너비가 150px이므로 7 번째 green box를 그릴 수 있다. 7 번째 green box를 그리고 line box의 너비가 0px이 되었다. float 요소들이 그려지는 과정을 보면 알 수 있는 특징이 있다. line box가 계속해서 float: left와 float: right 사이에 구성된다.(빈 공간은 left와 right 사이에만 유효하다.) 따라서 float: right는 float: left 보다 왼쪽에 그리지 않고, float: left는 float: right보다 오른쪽에 그리지 않는다.(물론 다른 높이에서 float: right 보다 float: left가 더 오른쪽에 그려지도록 할 수는 있다. 이 경우는 같은 높이의 경우를 말한 것이다.) ※ 마지막으로 오해하면 안되는 점float 요소가 생성되면 새로운 bfc가 생성된다고 했다. 그렇다면 앞의 예제에서는 7개의 float요소들이 있기 때문에, 7개의 bfc가 생성되었다고 봐야 할까? 그렇지 않다. float가 그려지는 line box가 유지되는 한 같은 bfc에 속하게 된다. line box를 해제하기 위해서는 별도의 다른 방법들을 사용해야 한다.(이번 글에서는 다루지 않는다.) 따라서 위의 예제에서 아직 다루지 않은 부분이 있는데, 마지막에 추가된 ABC 문자열을 가지고 있는 red block 요소이다. 해당 red block은 normal flow bfc이므로 새롭게 생성된 bfc의 시작지점에 위치한다. 문자열 ABC는 float요소와 겹쳐서 그려질 수 없기 때문에 3 번째 yellow box와 4 번째 green box 사이에 위치하게 된다. 그렇다면 만약에 문자열 ABC가 아니라 red block안에 들어갈 수 없을 만큼 긴 문자열, 예를 들면, ABCDEFG인 경우에는 어떻게 그려질까? 문자열은 아래로 내려가면서 float: left와 float: right 사이의 marginal box를 찾아 내려가면서 자신이 그려질 수 있는 marginal box를 찾는다. 이번 예제의 경우에는 ABCDEFG 문자열이 5 번째 yellow box 아래, 6 번째 green box 오른쪽에 그려진다.","link":"/2020/07/21/css-float/"},{"title":"CSS Position Schemes- Absolute Positioning","text":"이번 주제는 CSS Position Schemes의 세 번째 방식인 float이고 이번 주제의 마지막 편이다. 우선 offset에 대해 살펴본 후, parent offset에 따라서 absolute positioning이 어떻게 계산되는지 알아보도록 하겠다. 이번에 다루는 내용들은 코드스피츠 76 CSS Rendering의 강의를 정리한 것이다. Offset과 Frame첫 번째 글에서 CSS에서는 화면 요소의 계산이 직접적으로 수학과 물리학 공식을 적용한 함수를 사용하는 대신 속성에 추상적인 값을 주는 방식으로 구성한다고 했다. normal flow의 경우에는 position: static, position: relative로 값을 주었고, float의 경우에는 float: left, float: right로 값을 주었다. 그런데 첫 번째 글의 도입에서 했던 이야기를 상기해보자. 결국 그림을 그리기 위해서는 화면 요소가 구체적인 값으로 계산되어서 각각의 pixel에 주어져야 한다. 바꾸어 말하면, 결국 우리가 추상적인 값으로 지정한 화면 요소들을 결국 고정된 숫자 값으로 계산된다. 이렇게 계산된 숫자 값을 offset이라고 한다. 즉, offset은 reflow 계산이 끝난 결과 값이다. 때문에 offset 값은 변경이 불가능하며 읽기만 가능하다. 이런 점을 생각해보면, 결국 html, css로 짠 코드는 우리의 희망사항같은 것이다. 우리가 원하는 대로 그림을 그려줄지 말지는 브라우저에 달린 문제이다. 실제로 구형 ie6에서는 float값을 주면 의도하지 않게 padding: 3px이 추가되는 버그가 존재했다. 따라서 html, css rendering으로 그림을 그리는 한, 브라우저가 우리 의도대로 그림을 그리는지 그리지 않는지를 확인하는 방법은 실제 계산된 값은 offset 값을 확인하는 방법 이외에 없다. 그러면 구제적인 값을 알기 위해서 offset값을 읽고 offset 값을 바탕으로 우리가 원하는 대로 화면이 그려지도록 하면 되는 것일까? 안타깝게도 그렇지 않다. 첫 번째 글에서 이야기 했다시피 그림을 그리는 일은 복잡하고 계산량이 많은 작업이다. 따라서 브라우저는 최대한 계산을 효율적으로 하기 위한 최적화 방법을 사용한다. 보통 element들이 그려질 때, 이후에 그려진 요소가 이전에 그려진 요소에 영향을 주거나 반대의 경우가 많이 존재한다. 만약에 복잡한 layout에서 요소 하나를 그릴 때마다 영역 계산을 한번씩 한다면 계산량이 많아진다. 그래서 브라우저는 각각의 요소들 중에 다른 element에 영향을 주거나 영향을 받는 요소들만 묶어서 한번에 계산하려고 한다. 이렇게 한번에 묶어서 계산하는 단위를 frame이라고 한다. 브라우저는 그림을 그릴 때, 변경이 일어날 요소들을 queue에 쌓아두고 frame 단위로 묶어서 frame 단위로 한 번씩만 계산을 하려고 한다. 이렇게 frame 단위로 변경이 일어날 요소들을 한번에 그릴 때 일어나는 일을 flush라고 한다. 브라우저는 쌓여있는 queue를 flush시키는 방식으로 전체 재계산하는 횟수를 줄이려고 한다. 그런데 만약 우리가 rendering 과정 중간에 dom에 접근해서 elementd의 offset을 조사하면 어떻게 될까? 만약 rendering 중간에 offset 값을 요청하게 되면, offset값을 알려주기 위해서 queue의 있는 값들을 지우고 바로 해당 요소의 offset값을 계산해서 보여준다.(뒤의 요소에 따라서 재계산되서 변할 수도 있다.) 그래서 rendering 중간에 offset을 요청하면 브라우저가 해야하는 재계산의 횟수가 늘어나고 브라우저의 최적와 로직이 깨진다. 따라서 offset값은 함부로 사용하면 안되고, 계산이 다 끝난 요소에 한해서 더 이상 다른 요소에 영향을 주지도 영향을 받지도 않는 경우에 읽는 것이 바람직하다. 이런 요소들은 queue에 쌓이지 않기 때문에 offset값이 재계산 되지 않는다. 이런 브라우저의 최적화 방식을 모를 경우, layout을 구성할 때 이전 요소의 offset을 사용해서 다시 layout을 그리려는 실수를 한다. 이런 방식으로 layout을 구성할 경우 재계산 횟수가 늘어나기 때문에 rendering이 느려지는 현상이 발생한다. 정리하자면 offset 값은 조회 전용이다 offset 값을 읽는 행위는 offset 재계산이 일어나지 않는 경우에만 권장된다. offset 값을 바탕으로 layout을 다시 그리려고 해서는 안된다. Offset Parent컴퓨터 입장에서는 offset을 계산하려면, 실제 pixel 값을 계산해야 한다. offset을 계산하는 가장 기본적인 방식은 기준점으로부터의 상대적인 위치이기 떄문에 어디가 기준점인지를 찾는 것이 우선이다.(offset의 원래 의미가 ~부터 ~만큼 떨어져있다는 의미라는 것을 생각해보면 이해하기 쉽다.) 만약 어떤 요소에 left: 100px, top: 100px의 값을 주었다면, 이 말은 기준점으로부터 왼쪽으로 100px 아래로 100px이라는 말이다. 따라서 offset parent는 바로 offset을 계산하기 위한 기준점을 지칭하는 용어이다. 그런데 offset parent도 normal flow의 경우와 동일하게 dom의 구조와 일치하지 않는다. 따라서 dom에서는 부모 요소라도 꼭 offset parent가 아닐 수도 있다. 앞서 다루었던 normal flow를 예로 들면, inline 요소 내부에 block 요소가 있는 경우 bfc의 offset parent를 계산할 때, 부모요소인 inline 요소를 고려하지 않는다. 해당 block요소는 부모 요소들을 거슬러 올라가다가 block요소가 있는 경우 그 block 요소를 offset parent로 삼는다. offset parent: nullhtml 요소 중에는 offset parent가 null인 경우, 즉 offset parent가 없는 경우가 있다. 다음의 3가지 요소들은 offset parent가 null이다. root, html, body: 해당 html요소가 root, html, body인 경우 offset parent가 null이다.(이 요소들은 기준 요소이기 때문에 offset parent가 존재하지 않는 시작점이다.) position: fixed: position: fixed의 경우, offset parent가 존재하지 않는 기준 요소가 되버리기 때문에 offset parent가 없다. out of dom tree: javascript를 통해 createElement로 생성된 요소는 해당 요소가 appendChild로 dom tree안에 추가되지 않는 한 offset parent가 없다. position: absoluteposition: absolute의 경우, offset parent를 정하는 방식이 표준에 정해져 있다.(따라서 dom의 부모는 무시된다.) position: absolute의 경우에는 recursive search를 통해서 offset parent를 찾는다. 재귀적인 방식으로 offset parent를 찾을 때까지 부모요소를 거슬러 올라간다. recursive search가 offset parent를 찾는 방식은 다음과 같다. 부모요소가 position: fixed인 경우: 앞에서 이야기 한 것과 같이 position: fixed는 offset parent가 null이기 때문에 position: absolute의 offset parent도 null이 된다. 부모요소가 position: static이 아닌경우: 즉 position absolute 혹은 position relative인 경우, 해당 부모 요소는 offset parent가 된다. 부모 요소가 body인 경우: body의 경우에도 offset parent가 될 수 있다. 부모 요소가 td, th, tabled인 경우: 표준에 따르면 td, th, table인 경우에도 offset parent가 될 수 있어야 하지만, 대부분의 브라우저에서 이렇게 작동하지 않는다. 일반적으로는 td요소 안에 position: relative인 div를 주고 absolute를 적용한다. position: absolute 요소는 부모 요소를 거슬러 올라가다가 위의 경우에 해당하는 요소를 offset parent로 삼는다. 정리하면 position: absolute라면 offset의 기준점이 내 dom 상에서의 부모가 아니라 조상들 중에 위의 경우에 해당하는 요소이다. 대부분의 요소들이 기본 값인 position: static이기 때문에 일반적으로는 position: relative인 부모를 offset parent로 삼는다. 따라서 많은 경우에 position: relative는 static을 기준으로 요소를 상대적인 위치로 이동할 때 사용하기 보다는 position: absolute의 offset parent로 설정할 때 사용한다. 참조 가능한 offset 값들이제 offset parent를 알았다면, 브라우저가 계산한 다양한 offset값들을 참조할 수 있다.(읽기 전용) offsetLeft offsetTop-> 위의 2개의 값들은 offset parent로 부터 얼만큼 떨어져 있는 지를 알 수 있다. offsetWidth offsetHeight-> 위의 2개의 값들은 해당 요소가 실제로 차지하는 크기를 알 수 있다. offsetScrollLeft offsetScrollTop-> 위의 2개의 값들은 content가 offset parent보다 큰 경우 cotent의 실제 위치를 알 수 있다. offsetScrollWidth offsetScrollHeight-> 위의 2개의 값들은 content가 offset parent보다 큰 경우 cotent의 실제 크기를 알 수 있다. html은 요소에 overflow: hidden을 주면 scroll을 기본적으로 제공한다. 부모 block 보다 큰 content를 넣었기 때문에 scroll이 발생한다는 것을 생각해 본다면, 진짜 컨텐츠의 크기를 알기 위해서는 offsetScroll 값을 확인해야 한다.","link":"/2020/07/21/css-absolute-positioning/"},{"title":"HTML Semantic Web","text":"이번 주제는 본래 웹의 기본적인 컨셉이기도 했지만 html5가 되면서 더 두드러진 html의 특징이 된 semantic web에 대해서 다루도록 하겠다. 이번 내용은 코드스피츠 76 CSS Rendering의 강의를 정리한 것이다. Semantic Websemantic web을 우리 말로 번역하지면 의미론적 웹이라고 할 수 있겠지만, 좀 더 명확한 설명이 필요하다. semantic web은 html 자체만으로도 의미를 가진 하나의 문서가 되도록 웹 페이지를 작성하는 것을 말한다. html5을 사용해서 얻을 수 있는 결과라기 보다는 html5가 지향하는 바에 가깝다. 왜냐하면 여전히 많은 웹페이지들을 dom들을 의미론적으로 구성하고 html이 하나의 독립적인 문서가 되도록 작성하기 보다는 dom을 시각적인 요소에 따라서 구성하기 때문이다. 따라서 semantic web이 지향하는대로 웹 페이지를 구성하기 위해서는 html의 작성은 최대한 문서와 같이 의미론적으로 구성하되, 화면에 보이는 요소는 CSS로만 조작하도록 작성해야 한다.(이렇게 하는 것을 권장한다.) 그렇다면 의미론적으로 웹을 작성하는 이유, semantic web을 구성하는 이유는 무엇일까? 어떤 이점을 얻기 위해서 그런 것일까? 웹은 본래 태생부터 누구나 접근할 수 있는 정보 체계를 추구했다. 여기서 ‘누구나’의 대상은 시각, 청각, 지체 장애인들을 포함한 모든 사람들을 말한다. 더 다양한 사람들이 그 웹페이지에 접근할 수 있다면 그 웹페이지의 웹 접근성이 높다고 말한다. semantic web은 웹 접근성이 높은 웹을 구성할 수 있게 해준다. 그런데 최근에는 새로운 이유로 semantic web의 구성을 지향하게 되었다. 웹을 통한 서비스와 웹을 사용하는 이용자가 많아짐에 따라 현대의 웹페이지의 수는 천문학적인 수가 되었다. 우리가 일반적으로 웹페이지에 접근할 때는 유명한 페이지가 아닌한 도메인, 혹은 ip주소로 접근하는 일은 거의 없다. 대부분 사용자가 검색엔진에 검색을 해서 검색어에 대한 페이지 랭크가 매겨진 결과의 순서대로 사용자에게 제공된다. 따라서 사용자에게 웹페이지가 제공되기 위해서는 검색엔진이 해당 검색어에 대한 유의미한 내용을 담고 있는 컨텐츠라는 것을 알게 해주어야 한다. 잘 구성된 semantic web은 검색엔진이 html문서를 읽었을 때 마치 database에서 바로 데이터를 가지고 오는 것처럼 구조화된 정보를 추출할 수 있도록 해준다. 즉 semantic web을 구성함으로 보다 더 machine-friendly한 문서를 만들 수 있고, 검색엔진에게 높은 점수를 받을 확률이 더 올라간다.(실제로 최근의 웹페이지들은 검색 엔진에서 높은 랭크를 받을 수 있는 검색 엔진 최적화에 많은 노력을 기울이고 있다.) 정리하자면 semantic web을 구성하기 위해서는 개괄적으로는 다음의 원칙을 지키는 것이 좋다. DOM이 의미론적으로 구성되도록, 화면 요소를 기준으로 DOM을 작성하지 않고 내용을 기준으로 구성한다. 앞의 이유로 인해, 줄을 나누기 위한 목적이나 장식을 위한 목적, layout을 구성하기 위한 목적으로 div, p태그를 사용하는 것을 최소화한다. 태그 작성 시, 순수한 워드 문서라고 가정했을 경우 태그를 어떻게 배치하는 것이 좋을 지의 관점에서 태그를 작성한다. 위의 이유로 semantic tag를 활용하는 것이 좋다.(제목을 표현하고 있으면, header tag, 글을 표현하고 있으면 article tag) 따라서 semantic web의 철학에 맞춰서 태그를 구성한다는 말은 더 이상 화면의 구성요소로 dom을 평가할 수 없다는 말이다. 어떤 요소가 dom의 구 조상 먼저 작성되었을 지라도, 화면 구성에서는 제일 밑에 위치하거나 오른쪽에 위치할 수도 있고, 아예 보이지 않게 만들 수도 있다. Semantic Web을 위한 CSS Selector앞에서 semantic web을 위해서는 DOM을 의미론적으로 구성해야 한다고 했다. 그렇다면 의미론적으로 구성한 DOM을 바탕으로 화면 요소는 CSS에서 조작하도록 하기 위해서는 html과 CSS를 어떻게 구성해야 하는 것일까? 애초에 그렇게 구성하는 게 어렵기 때문에 DOM구조에 화면요소가 섞이도록 구성하게 된 것이 아닌가하는 의문이 든다. 물론 쉬운 작업은 아니다. 이 작업을 위해서는 CSS Selector의 적절한 활용이 필요하다. class를 이용하여 semantic web을 구성하려고 할 때의 문제점맨 처음 semantic web을 구성하려고 할 때, 쉽게 선택하는 방법은 class를 사용하려고 하는 것이다. 그러나 단순히 class를 사용해서 semantic web을 구성하려는 선택은 class에 의미를 부여하려는 선택이기 때문에, 이로 인해 스타일과 의미론적 구조 사이에 의존관계가 생긴다. 이렇게 되면, DOM을 class에 맞춰서 구성하게 되고, 이런 의존 관계로 인해 태그의 변화가 기존의 스타일을 깨뜨릴 수도 있다. 이렇게 구성된 사이트는 크기가 커지면 커질수록, css를 사용하는 요소가 많으면 많을 수록 html과 css 모두 수정하기가 어려워지기 때문에, 나중에는 유지보수가 거의 불가능한 html과 css가 만들어 진다. 즉 class를 활용하는 방식은 semantic web을 구성하는 방법이 될 수 없다. CSS Selector를 의미론적으로 구성된 dom에 맞추는 방법CSS Selector의 종류 중에는 CSS Attribute Selector가 있다. attribute selector는 해당 element의 속성을 기반으로 element를 선택할 수 있도록 해준다. 일반적으로는 input요소를 선택할 때 input[type=”text”]의 형식으로 많이 사용한다. 그런데 Attribute Selector의 구조가 SQL Query의 구조와 유사하다 SQL Query의 기본적인 서술은 다음과 같다 SELECT * FROM TABLE WHERE field conditions 그리고 attribut selector의 기본적인 서술을 다음과 같다. base selector[field condition][...][...] 따라서 semantic으로 dom을 구성할 때에 속성 값을 활용하여 구성하고 CSS attribute selector를 사용하면 semantic구조에 따라 스타일이 적용되도록 html과 css를 구성할 수 있다. 예를 들면 html과 CSS를 아래와 같이 구성하는 것이다. See the Pen OJMdXWM by psy082 (@psy082) on CodePen. 일반적으로 name, pw, nick이라는 identifier는 서버와 합의된 값이기 때문에 서버에서 이름을 바꾸지 않는 한 유지되는 값이다. 따라서 스타일을 위와 같이 적용하면 data 구조에 근거를 둔 스타일 적용이 가능하다. 때문에 dom을 변경하지 않고도 디자인 변경이 자유롭게 된다. HTML5 MicrodataApple, Mozilla, Opera등 주요한 웹 브라우저 벤더 회사들이 참여하는 WHATWG라는 W3C 산하 커뮤니티가 있다. W3C 산하 조직이라고 하지만 W3C보다 더 강력한 권한으로(자본도 자기들꺼고 브라우저도 자기들이 만드니깐…) 웹 표준 작성을 주도하고 있다. 이 WHATWG에서 semantic web을 쉽게 구성할 수 있도록 microdata라는 규격을 만들었다. 이 규격은 element에 microdata attribute를 주는 방식으로 semantic web을 구성하도록 스펙을 만들었다. microdata는 완전한 표준은 아니지만 현재 html5에서도 사용할 수 있도록 기본 속성 값으로 제공된다. microdata는 다음과 같은 attribute를 가지고 있다. itemscope: 적용 범위 설정, 현재 의미가 적용되는 태그의 범위를 설정한다. itemtype: 의미 구조를 설명해 주는 참조 자료(문법 레퍼런스와 같은 것이다.) itemid: itemscope 내에서의 항목의 고유 식별자 itemprop: itemscope 내에서의 속성명, itemtype에서 정의된 항목이어야 한다.(권장) content: 비가시적인 항목일 때의 값을 설정 value: 가시적인 값과 다르게 내가 원하는 값을 설정 itemref: itemscope 내에 정의된 항목이 아닌 항목을 설정 표준화된 microdata를 schema를 공유하는 사이트 schema.org에 가보면 semantic으로 웹을 구성하기 위한 모델들을 확인해볼 수 있다. microdata를 사용하면 html에서 제공하는 태그들만으로는 표현할 수 없는 그 이상의 의미를 가진 문서를 만들 수 있다. 예를 들어 최근에 많이 적용되는 다크 테마를 웹페이지에 쉽게 적용할 수 있는가? 만약에 dom과 스타일의 서로 의존하도록 구성되었다면 다크 테마를 적용하는 것은 굉장히 어렵다.(스타일의 변화가 페이지에 어떤 영향을 줄지 다 파악하기 어렵기 때문이다.) 즉, 단순하게 attribute selector를 사용한다고 해서 semantic web이 되는 것이 아니라 의미를 가진 구조로 웹을 구성해야 semantic web이 만들어 지는 것이다. microdata는 의미론적인 구조로 웹을 구성할 수 있도록 도와준다. 아래의 예제는 microdata를 사용해 웹페이지를 구성한 예시이다. See the Pen semantic web ex2 by psy082 (@psy082) on CodePen. 위의 예제를 보면 2개의 itemscope가 있고 각 itemscope는 itemtype에 의해서 정의된다. microdata attribute를 사용하여 의미를 구성한 뒤에는 css(scss)에서 의미론적 구조에 맞게 스타일을 적용한다. 즉 스타일에 따라서 dom이 구성되는 것이 아니라 dom의 의미론적 구조에 따라서 스타일이 적용되었다. ※ microdata를 사용하는 또 다른 장점은 웹 크롤링에도 용이한 페이지가 된다는 것이다. microdata구조에 따라 웹페이지를 파싱하는 서버 부분 라이브러리는 이미 존재하기 때문에 microdata를 사용한 웹페이지는 데이터 추출이 매우 용이하다. HTML5 DatasetHTML5에서는 어떤 element든지 data-로 시작하는 사용자 정의 속성을 부여할 수 있다. HTML5의 dom은 element마다 dataset이라는 key를 가지고 있고 dom에서 data-로 시작하는 속성의 속성 값을 사용할 수 있다. data-set도 표준 spec이기 때문에 microdata를 사용하지 않는다면, 사용자 정의 속성인 data-속성으로 semantic web을 구성할 수도 있다. 아래 예제는 앞의 예제와 동일한 구조이지만 data-속성을 이용한 예시이다. See the Pen semantic web ex3 by psy082 (@psy082) on CodePen. 정리정리하자면 semantic web은 쉽게 작성되는 결과물이 아니라 dom을 의미론적으로 구성하고 그 dom의 구조에 맞춰서 스타일을 적용하는 방식으로 dom과 스타일을 독립적으로 분리한 결과로 만들어진다. 따라서 충분한 고민과 실제로 semantic web을 구성해보는 경험이 모두 필요하다. semantic web을 구성하게 된다면 웹 접근성이 높아질 뿐더러 검색엔진 최적화와 웹 크롤링에도 도움이 된다. 유지보수가 쉽고 생명이 긴 웹페이지 구성을 할 수 있도록 고민을 많이 해보자 ※ 참고 - HTML5 Semantic Tag header: 헤더를 의미 nav: 네이게이션을 의미 aside: 사이드에 위치하는 공간을 의미 section: 여러 중심 내용을 감싸는 공간을 의미 article: 글을 의미 footer: 푸터를 의미 위의 semantic tag들은 css rendering system의 입장에서는 div 태그와 동일하지만 의미론적 dom 구성의 입장에서는 해당 내용이 무엇인지, 그 의미를 알려준다.","link":"/2020/07/21/html-semantic-web/"},{"title":"JS Generator Chaining 이해하기","text":"코드 스피츠 77 es6+ 기초편 강의에서는 generator로 chaining을 구성하는 예제를 다룬다. 해당 강의인 4번째 강의는 이 예제 외에도 중요한 다른 예제들을 다루지만 이번 글에서는 generator chaining의 동작을 살펴보면서 generator의 동작 방식을 이해해 보겠다. 앞으로 다룰 예제는 크게 두가지 객체로 구성되어 있다. 우선 class문법으로 생성된 Stream 객체이다. 해당 객체는 generator들을 입력받아서 입력받은 순서대로 chaining을 걸어서 실행할 수 있게 해준다. 두 번째는 Stream에 입력될 generator 객체들이다. 이 generator 객체들은 꼭 Stream 객체에 입력되지 않더라도 독립적으로 작동하는 generator들이다.(물론 모든 generator가 숫자 데이터가 저장된 배열을 처리하는 generator라는 전제가 있다.) 그렇다면 generator chaining이 어떻게 작동하는지 예제를 보면서 살펴보자. 1234567891011121314151617181920212223const Stream = class {  static get(v) {    return new Stream(v);  }  constructor(v) {    this.v = v;    this.filters = [];  }  add(gene, ...arg) {    this.filters.push(v => gene(v, ...arg));    console.log(this.filters.toString());    return this;  }  *gene() {    let v = this.v;    for (const f of this.filters) {      console.log(v);      v = f(v);    }    console.log(\"yield gene\", v);    yield* v;  }};Colored by Color Scriptercs Stream 객체를 먼저 살펴보겠다. 우선 Stream객체는 생성될 때, chaining으로 처리할 숫자 배열 v를 받아서 저장한 뒤 제네레이터들을 저장할 배열 filters를 저장한다. Stream 객체에서 중요한 메서드는 generator를 저장하는 add 메서드와 generator를 실행하는 gene 메서드(제네레이터)이다. add 메서드는 제네레이터와 제네레이터에 입력할 변수들을(나머지 매개변수로 선언되었기 때문에 없어도 된다.) 매개변수로 입력받는다. 그 다음 v를 입력 받은 generator를 반환하는 arrow function을 filters에 저장한다. 그 다음 Stream 객체의 참조값 this를 반환하고 종료한다. gene 메서드는 filters에 저장된 arrow function을 하나씩 꺼내서 실행시키고 실행 결과로 받은 이터레이터(제네레이터를 처음 실행하면 generator suspend 상태가 되고 next 함수 호출를 실행할 수 있는 이터레이터를 반환하므로)를 다시 v값으로 할당한다. gene 메서드는 filters 안에 저장된 제네레이터들을 순서대로 이터레이터로 전달함으로써 체이닝을 만들다. 체이닝이 끝나면 만들어진 체이닝된 제네레이터를(v에 저장되어 있다.) yield*로 반환한다. 12345678910111213141516171819202122232425262728293031323334const three = function* (data) {  console.log(`three: ${data}`);  for (const v of data) {    console.log(\"three\", three.cnt++);    if (!(v % 3)) yield v;  }};three.cnt = 0; const even = function* (data) {  console.log(`even: ${data}`);  for (const v of data) {    console.log(\"even\", even.cnt++);    if (!(v % 2)) yield v;  }};even.cnt = 0; const take = function* (data, n) {  console.log(`take: ${data}`);  for (const v of data) {    console.log(\"take\", take.cnt++);    if (n--) yield v;    else break;  }};take.cnt = 0; for (const v of Stream.get([1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12])  .add(three)  .add(even)  .add(take, 2)  .gene())  console.log(v);Colored by Color Scriptercs 위의 3개의 generator 각각이 하는 일은 다음과 같다. three - 3의 배수인 값만 반환한다. even - 짝수인 값만 반환한다. take - n 번째까지의 값만 반환한다. 만약의 3개의 generator에 chanining을 걸면 어떻게 될까? 그리고 chanining하는 순서를 바꾸면 어떻게 될까? 우선 위의 예제 코드를 돌리면 6과 12가 출력된다. 대략적으로 chaining된 코드의 동작을 이해하면 이렇다. '3의 배수이면서 2의 배수인 숫자를 먼저 나오는 순서대로 2개까지만 출력하라'. 만약에 generator chaining을 이용하지 않고 위의 로직을 구성하려면 어떻게 해야할까? 아마 3중 for문과 조건문을 사용한 로직을 사용하거나 재귀 함수 로직으로 구성할 수 있을 것 같다. 하지만 이런 두가지 방법 보다 generator chining을 이용하는건 코드의 이해나 변경에 훨씬 용이하다. 그래서 유연함이 필요한 다중 loop로직이라면 generator로 구성하는 것이 더 좋은 것 같다. 코드 예제와 코드 결과값을 보면서 코드의 진헹을 좀 더 자세히 살펴보겠다. 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758const Stream = class {  static get(v) {    return new Stream(v);  }  constructor(v) {    this.v = v;    this.filters = [];  }  add(gene, ...arg) {    this.filters.push((v) => gene(v, ...arg));    console.log(this.filters.toString());    return this;  }  *gene() {    let v = this.v;    for (const f of this.filters) {      console.log(v);      v = f(v);    }    console.log(\"yield gene\", v);    yield* v;  }}; const three = function* (data) {  console.log(`three: ${data}`);  for (const v of data) {    console.log(\"three\", three.cnt++);    if (!(v % 3)) yield v;  }};three.cnt = 0; const even = function* (data) {  console.log(`even: ${data}`);  for (const v of data) {    console.log(\"even\", even.cnt++);    if (!(v % 2)) yield v;  }};even.cnt = 0; const take = function* (data, n) {  console.log(`take: ${data}`);  for (const v of data) {    console.log(\"take\", take.cnt++);    if (n--) yield v;    else break;  }};take.cnt = 0; for (const v of Stream.get([1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12])  .add(three)  .add(even)  .add(take, 2)  .gene())  console.log(v);Colored by Color Scriptercs 위의 예제 코드를 실행시켜 보면 아래와 같은 결과가 나온다. 아래의 결과를 4개로 나누어서 설명하겠다. 1234567891011121314151617181920212223  // 1. add 함수 내부  v => gene(v, ...arg)  v => gene(v, ...arg),v => gene(v, ...arg)  v => gene(v, ...arg),v => gene(v, ...arg),v => gene(v, ...arg)   // 2. *gene 제네레이터 내부  [    1,  2, 3, 4,  5,    6,  7, 8, 9, 10,    11, 12  ]  Object [Generator] {}  Object [Generator] {}  yield gene Object [Generator] {}   // 3. three, even, take 각 함수의 내부  take: [object Generator]  even: [object Generator]  three: 1,2,3,4,5,6,7,8,9,10,11,12   // 4. chaining된 로직에 [1...12]의 배열이 입력되었을 때, for of 를 통해 console.log에서 출력되는 결과값  6  12Colored by Color Scriptercs 우선 chaining은 three, even, take 제네레이터가 Stream 객체 내의 filters 배열에 저장됨으로 시작되었다. filters 배열에 3개의 제네레이터가 저장되었기 때문에 입력을 받아 제네레이터를 반환하는, 3개의 arrow function이 저장된다. gene 제네레이터가 실행되었다. v 값을 확인해보니 Stream 객체의 변수 v에 저장된 [1…12]의 배열이 그대로 출력되었다. for loop가 실행되면서 v = f(v);가 반복 실행된다. loop가 처음 시작될 때, 배열 [1…12]기 제네레이터 three에 매개변수로 전달되어서 실행된다. 따라서 three를 사용할 수 있는 이터레이터 객체가 반환되었고 다시 v에 저장되었다. 다음 loop에서 three 이터레이터 객체가 제네레이터 even에 매개 변수로 전달되어서 실행된다. 이번에도 even을 사용할 수 있는 이터레이터 객체가 반환되었고 다시 v에 저장되었다. 마지막 loop에서 even 이터레이터 객체가 제네레이터 take에 매개 변수로 전달된다. 제네레이터 실행시 반환하는 객체는 이터레이터일뿐만 아니라 이터러블이기 때문에 for of 의 대상이고 따라서 take 이터러블이터레이터 객체를 탐색한다. for of가 시작되었기 때문에 제네레이터 take가 실행되었고 take: [object Generator]를 출력한 뒤에 for of 가 실행되어서 even 이터러블이터레이터 객체를 탐색한다. 따라서 제네레이터 even이 또 실행된다. 실행되었기 때문에 even: [object Generator]를 콘솔에 출력한 뒤 even도 for of 로 three 이터러블이터레이터 객체를 탐색한다. 제네레이터 three가 실행되었기 때문에 three: 1,2,3,4,5,6,7,8,9,10,11,12를 출력한 뒤 3의 배수만 yield한다. yield된 값은 제네레이터 even의 for of의 값으로 전달된다. 제네레이터 even에서는 전달받은 3의 배수 중에서 짝수인 값을 yield한다. yield된 값은 제네레이터 take의 for of의 값으로 전달된다. 따라서 take는 3의 배수이면서 2의 배수인 6의 배수의 값을 2개만 yield한다. ※ 위의 코드 진행에서 유의해서 볼 점 제네레이터 three, even, take는 yield를 사용했지만 Stream객체의 gene generator는 yield를 사용했다. yield* 키위드는 yield* 뒤에 다른 실행된 제네레이터(이터러블이터레이터가 된)가 올 경우에 yield를 해당 제네레이터에 위임한다. 위의 코드에서 보자면 제네레이터는 three, even, take 내부에서 for of 를 사용하여 값을 탐색하기 때문에 이터러블 객체가 입력으로 들어온다는 것을 전제로 한다. 위의 예제에서는 각 제네레이터들이 실행되어서 이터러블이터레이터로 반환된 값을 다음 제네레이터에 넘기는 구조로 진행되기 때문에 yield 키워드를 사용하였지만 제네레이터 gene은 결국 generator의 실행을 시작해야 하기 때문에 yield* 키워드를 사용해서 제네레이터 체이닝이 진행되도록 한 것이다.","link":"/2020/07/25/js-generator-chaining/"},{"title":"Git & Github 요약 정리","text":"git과 github의 기본 개념을 정리했다 VCS와 GitGit은 VCS(Version Control System) 중 하나이다. Version Control System에서 Version이 의미하는 것은 개발 작업이 진행되는 폴더 및 하위 폴더와 파일들의 history를 의미한다. 따라서 VCS가 하는 역할은 개발을 진행할 때, 개발의 환경이 되는 폴더와 파일들의 변경 기록을 저장하고 관리하는 것이다. 그렇다면 VSC가 개발을 진행하는 데 있어서 필요한 이유는 무엇일까? 크게 3가지가 있다. 코드 변경 사항 내역 기록 및 관리 필요한 이전 상태로 rollback 팀단위 개발시 체계적이고 효과적인 협업 우리가 코드를 업데이트 할 때, 많은 경우 버그가 발생하고 해당 버그가 치명적이어서 이전 코드로 돌아가야 할 때가 있다. 또한 팀 단위로 협업이 진행될 때, 어떤 사람이 적용한 코드에서 문제가 발생했는지 확인해야 하는 경우도 있다. 일정 규모 이상의 프로젝트가 진행될 경우 VCS의 사용이 필수적이다. RepositoryRepository는 git이 관리하는 폴더를 의미한다. 일반 폴더는 git에게 아무 의미가 없지만 해당 폴더 내부에서 git init을 통해 .git 폴더가 생성되어서 해당 폴더의 변경사항이 git에 의해 추적되기 시작하면 그 폴더를 repository라고 한다. git repository는 2가지로 분류된다. local repository: local(개발자 개인의 컴퓨터)에 저장된 repository remote repository: 중앙 서버에 저장된 repository, git을 팀 단위의 협업을 할 때 사용한다면 팀에 소속된 개발자들이 공통적으로 참조하는 repository가 있어야 할 것이다. 팀에서 공동으로(꼭 팀 단위가 아니더라도) 원격으로 관리하는 repository를 remote repository라고 한다. 일반적으로 http나 ftp로 접속가능한 서버에서 관리된다. Staging and Commit figure 1. flow of git process git init을 통해 repository가 된 폴더(즉, repository)는 git에 의해 변경 사항이 추적되지만 자동적으로 코드 변경 사항이 저장되지는 않는다. 코드 변경 사항을 git에 저장하고 싶다면 개발자가 변경이 완료된 지점에서 git을 사용한 명령어로 변경점을 저장해야 한다. git에서는 변경 사항의 추적부터 시작하여 변경 사항이 적용되기 까지를 3가지의 상태로 나누어 관리한다. git repository 파일들은 git에 변경점이 저장되지 전에 Modified, Staged, Committed 이렇게 3가지 상태 중 하나로 존재한다. Modified: 이전 변경점 이후에 변경된 파일들은 git에 의해 추적되어서 자동으로 modified 상태가 된다. 만약 아예 파일이 새로 생성되었다면 해당 파일은 modified가 아니라 untracked 상태가 된다. Staged: modified 혹은 untracked 상태인 파일(혹은 폴더)들 중에 git add * 명령어를 통해 index에 등록된 상태를 말한다. git에서는 변경된 파일을 바로 변경 내용으로 저장하기 전에 index에 저장해서 추가적인 변경이 일어날 수 있는 중간 지점을 만들었다. 변경점을 저장하기 전에 누락이라 실수가 있을 수 있는데, 그 때마다 roll back을 한다면 저장소의 log도 길어지고 불편한 지점이 존재한다. 따라서 최종적으로 변경점을 저장하기 전에 변경 내용들을 점검할 수 있는 staged 상태가 있다. Committed: index에 등록된 변경 내용들은 git log에 저장되지 않는다. 아직 변경점이 저장되기 전이기 때문이다. git에서 진짜 변경점을 저장하기 위해서는 index에 등록된 변경 내용들을 git commit 명령어를 사용하여 새로운 snapshot으로 저장해줘야 한다. commit 명령어를 사용할 때, git commit -m "message" -m 옵션을 사용하여 변경 내용에 대한 짧은 설명을 남길 수 있다. log에도 -m 옵션으로 붙여진 메세지가 기록된다. Snapshot이 저장되는 방식git에 저장되는 각각의 변경점을 snapshot이라고 한다. git은 VCS고 VCS에서 roll back 기능을 제공해야 한다면, 이 말은 git의 이전까지의 모든 변경점의 폴더와 파일들을 전부 저장하고 있다는 뜻이다. 그렇다면 매 snapshot마다 폴더와 파일들이 새로 저장되어야 하므로 저장공간을 많이 차지할 것이다. 다행하게도 git은 snapshot마다 폴더와 파일들을 새로 저장하는 방식으로 파일을 관리하지 않는다. git은 현재의 snapshot과 바로 이전의 snapshot과 비교하여 변경된 파일과 변경되지 않는 파일을 구분한다. 만약에 새로 변경된 파일이라면 파일을 새로 저장하지만 변경되지 않은 파일이라면 복사하지 않고 이전 snapshot의 해당 파일의 주소를 가리키게 만든다. 이런 방식으로 저장하면 변경된 파일들이 전부 저장되지만 변경되지 않은 파일들도 불필요하게 저장되는 것을 막을 수 있다. ※ 따라서 개발자가 remote repository에서 repository를 clone 혹은 pull하는 것은 해당 repository의 특정 시점의(일반적으로 가장 최신) snapshot을 받아오는 것이다. Branch와 Merge여태까지 git이 하는 역할과 git으로 snapshot을 저장하기 까지의 과정들, snapshot이 저장되는 방식에 대해서 설명했다. 그렇지만 아직 의문이 남는다. 개발자들이 각자 snapshot을 저장해서 개발을 한다면 어떻게 서로의 변경사항들을 조율할 수 있는것일까? 개발자들 각자의 변경사항들을 합쳐서 새로운 최신 버전의 스냅샷을 만들기 위해서는 어떤 스냅샷을 기준으로 변경 사항들을 합치는 가의 문제를 해결해야 한다. 이 문제를 해결하기 위해서 branch를 사용한다. Branch우리가 git init을 통해 repository를 생성했다면 기본적으로 master branch가 만들어진다. 개발이 이루어질 때는 각 개발자들이 master branch의 snapshot을 가지고 오고 이 master branch를 기준으로 자신이 작업할 새로운 branch를 만들어 낸다. 이렇게 만들어진 branch를 feature branch라고 한다. branch를 새로 생성할 때는 git checkout -b feature_name을 사용한다.(-b 옵션을 붙이면 생성 후에 해당 branch로 바로 이동한다.) Merge각 개발자는 feature branch를 기준으로 개발을 진행하고 개발이 완료되어서 최종 commit 도 완료되면 remote repository에 해당 snapshot을 저장한다. remote repository에 있는 master branch에서는 feature branch로 개발된 내용들을 합치기 위해서 merge한다. master가지를 기준으로 merge할 때는 git merge featrue_name 명령어를 사용한다. Github이전까지의 git의 내용을 이해했다면 Github의 역할도 쉽게 이해할 수 있다. Github은 git의 remote repository를 제공하는 웹서비스 이다. 현재 Github 단순히 중앙 저장소 역할만 하는 것이 아니라, testing, code review, documentation 생성 및 관리, 일정 관리 등의 프로젝트 개발과 운영에 필요한 다양한 기능들을 제공한다. Github 사용하기Github을 사용하면 remote repository를 쉽게 생성할 수 있다. github에 로그인 한 후 new Repository 버튼을 클릭하고 Repository 이름을 설정한다. Create Repository 버튼을 눌러서 remote repository를 생성한 뒤, 주소를 복사한다. git init명령어를 통해 local repository를 생성한다. 새로운 파일을 repository 내에 생성한뒤 git add *, git commit 명령어로 snapshot을 저장한다. git remote add origin '복사한 remote repository 주소'를 사용하여 원격 저장소와 로컬 저장소를 연결한다. git push origin master 명령어를 사용하여 github remote repository master branch에 snapshot을 저장한다.","link":"/2020/07/29/git-basics/"},{"title":"Brandi Internship - Part 1","text":"Wecode!올해 4월 코드스피츠로 자바스크립트 공부를 하던 나는, 자바스크립트가 가지고 있는 깊이와 활용도에 크게 매력을 느꼈다. 다만 아쉬운 점은 혼자서는 큰 단위의 코드를 작성하면서 배운 내용을 적용하기가 어려웠고 프로젝트를 진행하고 싶어졌다. 통신하는 부분의 코드를 작성해보면서 promise와 async await, generator등을 직접 활용해보고 싶었다.(아쉽게도 아직까지도 충분히 활용해보지는 못했다.) 그래서 프로젝트를 진행하면서 코드리뷰를 받을 수 있는 곳을 찾아보게 되었다. 그렇게 찾게 된 곳들은 대부분 부트캠프들이었는데, 나는 당장 다닐 수 있는 곳을 찾았었고, 당시에 당장 등록할 수 있는 곳이면서 프로젝트를 진행할 수 있는 곳인 wecode를 선택하게 되었다. wecode는 3개월동안 2개의 프로젝트와 1달 간의 인턴쉽을 제공하는데 개인적으로 너무 감사한 시간들이었다. 이번 글에서는 여성 의류 플랫폼 서비스를 제공하는 스타트업, Brandi에서 1달간 진행했던 프로젝트와 그 프로젝트를 어떻게 해결했는지 적어보았다. Brandi 인턴쉽의 시작Brandi에서 인턴쉽을 진행한 인원은 총 20명이었다. 10명씩 두 팀으로 나눠서 현재 브랜디에서 운영 중인 서비스 사이트와 어드민 사이트를 만드는 것이 한달 동안의 과제였다. 물론 완전히 동일하게 만들어야 하는 것은 아니었지만 필수 구현으로 제시된 페이지가 꽤 많은 양이었다. 만들어야 할 페이지가 많은 것도 어려움이었지만, 부트캠프 기간동안 react를 사용했던 것과는 다르게 브랜디에서는 vue를 사용해야 했다. 따라서 뷰를 새롭게 공부하는 것과 동시에 많은 페이지들을 구현해야 한다는 부담이 있었다. 일단 우리팀 10명(FE 5명, BE 5명)은 다시 5명씩 서비스팀과 어드민 팀으로 나누었고 나는 어드민 팀에 속하게 되었다. 그리고 우리가 만들어야할 페이지들을 관찰하기 시작했다. 그런데 프론트들은 페이지들을 관찰하기 전에 넘어야 할 산이 있었다. 첫 번째 난관: Webpack편하게 vue-cli3를 사용할까요?회사에서 필수구현으로 명시된 사항 중에 webpack을 사용하여 개발, 배포 환경을 구성해야 한다는 사항이 있었다. 지난 2달동안 wecode에서 리액트로 프로젝트를 진행할 때, CRA를 사용하여 웹팩을 직접 만지는 일 없이 개발, 배포 환경을 제공받았었기 때문에, webpack에 대한 지식이 거의 없었다. 다행히 vue에서도 cra처럼 vue-cli라는 도구가 있었고 vue를 만든 evan you의 팀이 재작년 버전을 3으로 올리면서 vue 환경을 설정할 때의 편의성을 높였기 때문에 쉽게 사용할 수 있었다. 정말 vue-cli3는 사용하기 편리했고, 추가로 설정하고 싶은 로더나 플러그인들은 vue.config.js에 추가하기만 하면 됐다. 문제는 이런 선택이 웹팩을 사용하라는 필수 구현 사항에 배치되는 선택이냐는 것이었다. 우리는 추가적인 설정을 vue.config.js를 사용하여 webpack에 추가할 예정이었기 때문에 아예 웹팩을 사용하지 않는 것도 아니었다. 그래서 우리 인턴쉽을 담당하고 있는 원철님께 slack으로 dm을 날렸다. 다행히도 vue-cli를 사용하고 vue.config.js로 추가 설정을 해도 된다는 답변을 받았다. 덕분에 과제를 받은 첫 째날 퇴근 직전에 프로젝트를 시작할 수 있는 vue 환경 설정을 끝낼 수 있었고, 이제 수 많은 페이지들을 만드는 작업을 시작하면 되었다. 그런데 팀원 중 한명이었던 상훈님이 다른 의견을 내셨다. “근데 vue-cli를 쓰면 왜 작동이 되는거에요? 인턴쉽 과정도 공부인데, 우리가 직접 처음부터 만들어보면 어떨까요?” 그래서 우리팀 프론트 5명은 vue-cli를 사용하지 않고 직접 웹팩을 설정해보기로 결정했다. 그리고 선택을 후회… googling, webpack, vue, none…우리는 vue 공부도 병행해야 했기 때문에, webpack 설정은 프론트에서 나와 상훈님 두명이서 빠르게 진행하기로 하고(너무 몰라서 빠르게 진행할 수 있다고 생각했다…), 다른 3명의 팀원은 뷰 공부를 시작하는 것으로 결정했다. 그리고 정리한 내용을 팀원들에게 전달해주기로 했다. 나와 상훈님 두명은 구글링을 시작했는데, 우리는 webpack 설정에 도움이 될만한 자료들은 다 읽어보았다. 꼭 vue설정이 아니더라도 react설정에서도 도움을 얻을 수 있는 자료가 있다면 찾아서 읽어보았다. 문제는 대부분의 자료들이 너무 얕은 수준의 설정만 제공하고 있다는 점이었다. 우리는 개발환경과, 배포환경을 나누어서 환경 설정을 해야 했는데, 대부분의 자료들은 개발 환경에 맞춰져 있었고, 로더를 붙이는 방식도 조금씩 다 달랐는데 왜 다른지에 대한 이유를 알기도 어려웠다. webpack, vue라는 키워드로 검색해서는 우리가 원하는 자료를 얻기가 어려울 것 같았다. 그래서 일단 브랜디에서도 vue 설정이 있기 때문에 인턴쉽 과정과 인원들을 담당하셨던 팀장님께 가서 어떤 방식으로 웹팩 설정을 하는 것이 좋을지 자료를 얻을 수 있는지 물어보았다. 팀장님의 답변은 “일단 스탠다드한 설정을 찾고, 그 설정에 대해서 커스텀 하게 수정을 하는 방식으로 해야 한다.” 라는 도움이 되면서 도움이 되지 않는 것 같은 답변을 해주셨다. 하하하… 하지만 이 답변이 큰 도움이 되었다. 문제를 해결할 시작점은 “스탠다드한 설정”을 찾는 것이었다. 그런데 “스탠다드한 설정”을 도데체 어디에서 찾는다는 말인가? “스탠다드한 설정”을 찾아 헤메던 우리가 갑자기 깨달은 바가 있었다. 우리가 이미 사용한 vue-cli3가 “스탠다드한 설정”이라는 것 vue-cli3를 뜯어봅시다.CRA에서 webpack 설정을 보기 위해서 eject를 제공하듯이 vue-cli3에서는 inspect라는 명령어를 제공한다. inspect 명령어는 다양한 옵션들을 제공하는데, 개발환경과 배포환경의 파일을 각각 보여주는 옵션도 있었다. 우리는 개발과 배포 환경에서의 웹팩 설정을 output-dev, output-prod라는 파일에 저장하고 두 설정을 비교하기로 했다. 그런데 inspect를 통해 나온 결과물이 각각 1300줄이 넘었다… 우리는 2가지를 확인하기로 했다. 각각의 설정 파일에서 사용한 내용들이 어떤 역할을 하는 것인지 전부 조사하는 것, 그리고 개발환경과 배포환경에서 어떤 차이가 발생하는 확인하는 것이었다. 코드를 한줄한줄 확인하면서 우리는 구글링으로는 알 수 없었던 최적화를 위한 로더와 플러그인들이 vue-cli에 존재한다는 것을 알았고, webpack 설정파일의 대부분이 css처리에 관한 내용이라는 것을 알게 되었다. 우리는 scss만 사용할 예정이었지만, vue-cli의 경우에는 일반적인 사용자의 경우를 다 커버해야 하기 때문에 less, stylus들에 대한 처리도 있었다. 또한 두 환경의 차이는 diffchecker라는 웹 사이트의 도움을 받았다. css의 경우 개발 환경에서는 바로 css를 js에 주입하면 되지만, 배포 환경에서는 css파일로 추출되어야 했기 때문에 이 두 부분을 처리하는 로더와 플러그인이 각각 달랐다. 각 로더와 플러그인들의 역할도 찾았고, 두 환경에서의 차이도 알게 되었기 때문에 wepback 설정을 시작했다. 일단 두 파일 모두의 공통사항은 webpack.config.base라는 파일에 설정하기로 하고 이 설정을 webpack-merge로 받아서 webpack.config.dev, webpack.config.prod에서 사용하기로 했다. 이렇게 순조롭게 진행되면 좋은데, 항상 일은 그렇게 진행되지 않는다… 설정을 하던 중에 뭔가 놓친 것이 있다는 것을 알게 되었는데, 바로 개발 환경에서의 devServer 설정이었다. inpect를 통해서 나온 파일에서는 devServer설정이 없었고, 이렇게 되면 webpack-dev-server를 실행했을 때에 대한 설정이 존재하지 않게 되었다. 그런데 vue-cli3 환경에서는 devServer가 잘 작동을 했다. 뭔가 놓친점이 있다고 생각했고, vue-cli github에서 직접 파일들을 확인해보기로 결정했다. 그렇게 vue-cli 레포지토리에 들어가서 한참을… vue-cli 레포지토리의 파일들을 직접 확인을 한 결과 새로운 사실 2가지를 알게 되었다. 우선 vue-cli3는 웹팩 체인을 사용하여 함수 체이닝으로 웹팩 설정 객체를 만들도록 구성되어 있었다.(그래서 코드들이 훨씬 간편하게 작성되었는데, 우리도 체이닝 방식으로 바꾸고 싶었지만 그러기에는 이미 너무 많은 시간을 사용한 상태였다…) 그리고 devServer설정이 개발 환경에서 빠지는 이유는 devServer설정을 해주는 웹팩 체이닝 파일은 webpack-dev-server가 실행되었을 때, serve 명령어에서 실행되도록 별도로 분리되어 있기 때문에 inpect로는 볼 수가 없게 되어 있었다. 결과적으로 vue-cli3의 devServer 설정은 우리가 그대로 사용하기에는 어렵다고 판단을 했고, 간단하게 contentBase, compress, open, historyApiFallback 옵션만 붙여서 사용하기로 결정했다. 이제 시작이 모든 설정을 정리해서 개발환경과 배포환경이 잘 만들어지는 것을 확인한 것이 토요일 오전 11시 30분쯤이었다… 벌써 한주가 지나갔지만 만들어 진 것은 webpack 설정 뿐, 3주 안에 뷰 공부와 10개가 넘는 페이지에 대한 구현을 해야 했다. 남은 프로젝트를 어떻게 진행했는지는 다음 글에 이어서 적도록 하겠다.","link":"/2020/10/25/brandi-internship-1/"},{"title":"Brandi Internship - Part 2","text":"인턴쉽 2주차 시작처음 브랜디 인턴쉽 시작할 때, 브랜디 측에서 일정에 대해서 혼동한 부분이 있었는데, 본래 15일까지 진행되야 했던 인턴쉽이 8일까지라고 잘못 전달되었었다. 그렇다면 웹팩을 설정한 후 남은 기간은 3주밖에 되지 않았다.(고 생각했다. 나중에 다시 15일까지라는 것을 전달받아서 사실을 4주였다.) 짧은 시간동안에 많은 페이지를 그리려면 한꺼번에 그리는 수밖에 없었다. 그래서 페이지를 관찰해서 작성하는 코드의 숫자를 최소화하면서 효율적으로 코딩을 할 수 있는 부분이 있을 지 찾아보았다. 10개의 페이지를 1개의 컴포넌트로 그리면 어떨까?관찰 시작페이지 관찰을 시작했다. 어드민 페이지에서 큰 카테고리는 주문관리, 취소/환불 관리, 상품 관리, 고객응대관리, 회원 관리가 있었고, 카테고리 하위에 페이지들이 있었다. 다행히도 어드민 페이지는 페이지 간에 유사성이 높았다. 그렇다면 컴포넌트를 만들어서 재사용되게끔 만들면 되었다. 일단 페이지를 관찰한 결과 아래와 같았다. 주문관리, 취소/환불 관리, 상품 관리, 고객응대관리에 속해있는 페이지들은 크게 4개의 요소로 구성되어 있었다. 페이지 제목, 검색 조건을 위한 필터링 박스, breadcrumb, 테이블로 구성되어 있는데, 페이지마다 각 요소의 세부내용이 달랐다. 결과적으로 10개의 페이지를 1개의 컴포넌트에서 그리도록 만들기로 했는데, 그렇게 하기 위해서는 10개의 페이지를 그리는 컴포넌트가 10개의 페이지의 세부 사항들을 다 포괄할 수 있어야 했다. 여기서 vue의 장점이 드러났는데, vue는 코드를 짤 때, 코드를 짜는 사람의 사고를 vue의 구조에 맞추도록 강제한다. vue 파일은 렌더링을 담당하는 template태그, 로직을 담당하는 script태그, 스타일을 담당하는 style 태그로 나누어 진다. 여기서 vue의 사고 방식대로 코드를 짠다면 우리는 데이터 로직과 렌더링 로직을 분리해서 사용할 수 있다. 물론 자유도가 높은 react에서도 가능한 부분이지만 분리가 강제되지는 않기 때문에 쉽게 데이터로직과 렌더링 로직이 분리되지 않은 상태로 짜게 된다. 그러나 vue는 직접적인 데이터 부분을 script에 분리해서 작성하도록 생각을 도와준다.(물론 분리가 안되게 데이터를 전부 template 안에 넣어서 짤 수도 있다. 그런데 이렇게 할거면 vue를 왜 ㅆ..) 다시 돌아가서 각 요소의 세부내용이 다른 부분은 별도의 textMap이라는 파일로 분리했고, textMap에는 화면을 그리는 데 필요한 텍스트 값들(필터링 박스 값들, 테이블의 헤더들 등)을 저장했다. vue에서는 script 부분에서 textMap을 가져와 상태로 저장했고, template 부분에서는 저장한 textMap을 그리는 방식으로 구성했다. 이렇게 구성할 경우 필터링 구성이 변경될 때, 데이터에 해당하는 textMap만 수정하면 되고 렌더링 로직은 수정하지 않아도 된다는 장점이 있었다. 이렇게 구성한 결과 컴포넌트에서는 페이지 uri에 맞는 textMap 값을 읽어서 렌더링 로직에 보내기만 하면 렌더링 로직에서는 받은 값을 그려주기만 하면 되었다. 실제로 프로젝트 후반에 백엔드를 담당한 용민님이 추가적으로 vue를 사용한 페이지 구현에 참여하고 싶다고 하셨을 때, textMap에 정보를 추가하는 정도로도 쉽게 페이지 구현이 될 수 있었다. 컴포넌트 분리하기현재까지는 10개의 페이지를 한개의 컴포넌트에서 그리도록 결정했고, 각 페이지들을 구성하는 text 값들을 textMap으로 분리하는 것으로 결정했다. 이제 컴포넌트들을 어떻게 구성할지를 결정해야 했다. 페이지 제목은 별도의 컴포넌트로 분리할 필요없는 작은 부분이었지만, 필터링 박스, breadcrumb, 테이블은 별도의 컴포넌트로 분리할 필요가 있었다. 그런데 4개의 요소들 중에서 특별히 필터링 박스는 내부를 구성하는 form 요소들이 조금씩 달랐다. 필터링 박스의 경우 내부에서 좀 더 작은 컴포넌트들로 쪼개질 필요가 있었다. 10개의 페이지를 관찰한 결과 필터링 박스 내부의 form 요소들을 8개의 종류로 나눠 볼 수 있었다. 결과적으로는 textMap에서 필터링 박스 내부 form 요소들의 타입 값 1~8을 가지도록 했고, 필터링 박스 내부에서는 textMap의 필터링 타입 값에 따라서 그려지거나 그려지지 않도록 했다. 이해를 돕기 위해 작성한 코드를 보면서 설명하겠다. 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051<template>  <div>    <PageLoading v-if=\"!done\" />    <h3 class=\"page-title\">            <small></small>    </h3>    <FilterBox :filters=\"filters\" :orderStatus=\"orderStatus\" />    <BreadCrumb :orderStatus=\"orderStatus\" />    <Table      :table=\"table\"      :tableMap=\"tableMap\"      :tableId=\"tableId\"      :orderStatus=\"orderStatus\"    />  </div></template> <script>import path from '@/assets/textMap'; ... export default {...    data() {    const {      main,      sub,      filters,      sort,      table,      tableMap,      tableId,      orderStatus    } = path[this.$route.params.subMenu];    return {      main,      sub,      filters,      sort,      table,      tableMap,      tableId,      orderStatus: orderStatus ? orderStatus : 0,      namespace: this.$route.params.subMenu,      done: true    };  }, ...Colored by Color Scriptercs 우선 10개의 페이지를 그리는 컴포넌트 코드이다. 스크립트 태그 안에서는 textMap의 값을 읽어서 저장하고, template태그 안에서는 저장한 textMap 값을 필터링 박스, breadcrumb, 테이블 컴포넌트에 전달한다. 그래서 이 컴포넌트 자체로는 textMap을 전달하는 역할 외에 다른 큰 역할을 부여받지 않았다.(물론 페이지 전환시 loading을 진행하는 역할을 맡긴 했다.) 이제 필터링 박스를 담당하고 있는 컴포넌트 내부를 보면 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051<template>  <div class=\"filter-box\">    <ul class=\"filter-block\">      <li class=\"filter-list\" :key=\"filter.title\" v-for=\"filter of filters\">        <SelectInput v-if=\"filter.type === 1\" :options=\"filter.values\" />        <ButtonDate          v-if=\"filter.type === 2\"          :title=\"filter.title\"          :buttons=\"filter.values\"          :default=\"filter.default\"        />        <SingleButtons          v-if=\"filter.type === 3\"          :title=\"filter.title\"          :buttons=\"filter.values\"          :filterKey=\"filter.key\"          :default=\"filter.default\"        />        <MultiButtons          v-if=\"filter.type === 4\"          :title=\"filter.title\"          :buttons=\"filter.values\"          :default=\"filter.default\"        />        <Date v-if=\"filter.type === 5\" :title=\"filter.title\" />        <Input          v-if=\"filter.type === 6\"          :title=\"filter.title\"          :filterKey=\"filter.key\"          :placeholder=\"filter.values\"        />        <SelectDate          v-if=\"filter.type === 7\"          :options=\"filter.select\"          :buttons=\"filter.values\"          :default=\"filter.default\"        />        <Select          v-if=\"filter.type === 8\"          :title=\"filter.title\"          :filterKey=\"filter.key\"          :options=\"filter.values\"        />      </li>    </ul>    <div class=\"filter-action\">      <div class=\"button search\" @click=\"searchResult\">검색</div>      <div class=\"button reset\" @click=\"reset\">초기화</div>    </div>  </div></template>Colored by Color Scriptercs 필터링 박스 컴포넌트에서는 전달 받은 textMap의 type값을 확인해서 해당 type 값에 해당하는 form 요소만 그려준다. 따라서 페이지가 추가되었거나 특정 페이지의 필터 요소가 변경될 경우에는 textMap값만 변경하면 렌더링 로직을 변경하지 않고도 변경된 사항이 그려진다. api 통신 고려하기그런데 textMap을 구성할 때, 한가지 더 고려할 점이 있었다. 필터링 박스에 해당하는 textMap의 경우 단순히 그림을 그리는 데이터만 있어서는 안되었다. 왜냐하면 선택된 필터 값들은 실제 백엔드에 요청하는 값이 되어야 했기 때문이다. 따라서 textMap은 화면에 표시될 text 값과 백엔드에 보낼 필터 값 2가지 모두를 가지고 있어야 했다. 따라서 textMap은 객체로 만들어졌고, key는 백엔드로 보내는 필터 값, value는 화면에 표시될 text 값으로 구성했다. 아래의 코드는 textMap의 일부이다. 상품에 대한 검색을 할 때 필요한 text 값인데, 백엔드에 보낼 값이 PRODUCT_NAME이라면 해당 값은 화면에 상품명으로 그려진다. 123456789... export const PRODUCT_SELECT = {  PRODUCT_NAME: '상품명',  PRODUCT_NO: '상품번호',  PRODUCT_CD: '상품코드'}; ...cs 그렇다면 유저가 선택한 특정 값, 필터링된 값들은 어디에 저장을 해야 할까? 여기서 2가지의 선택지가 있는데, 하나는 부모 컴포넌트 필터링 박스에서 값을 가지고 있고 자식 form 요소들에 이벤트가 발생했을 때 부모 컴포넌트의 값을 가지도록 하는 방법이다. 다른 방법은 vuex를 사용해서 모든 필터링 값들을 vuex에서 관리하도록 하는 방법이다. 2가지 방법 모두가 장단점이 있었다. 우선 생각을 해보면 중요한 건 데이터와 데이터를 처리하는 로직이고 이 부분의 역할을 컴포넌트가 가질지 vuex가 가질지를 정해야 한다. 컴포넌트가 이 역할을 가진다면 컴포넌트 자체가 독립적이며 의존성이 적은, 좀 더 자유롭게 다른 컴포넌트와 조합이 가능한 컴포넌트를 만들 수 있다. 여기서 또 새롭게 고려할 지점이 생겼는데, 사실 자식이 부모의 상태 값을 바꾸는 것은 vue에서 편리하게 만들 수 있기 때문에 부모가 값을 전부 가지고 있고 상태 값을 처리하는 메소드를 자식 컴포넌트에 넘겨주게 할 수 있다. 하지만 이 경우 부모 컴포넌트의 데이터 로직이 너무 길어진다. 그렇다고 거꾸로 자식이 값을 가지고 있다면 검색이나 초기화 같은 기능을 사용할 때 부모에서 이벤트가 발생하면 자식의 상태 값을 바꾸도록 이벤트 버스를 관리해야 하는데 관리해야 할 상태값과 컴포넌트의 수가 적지 않아서 불편해진다. 그래서 결론적으로 vuex를 사용하기로 결정했다. vuex를 사용한다면 의존성이 생겨서 자유롭게 다른 컴포넌트와 조합이 가능하지는 않지만, 컴포넌트 간 구성이 사실상 정해진 상태이고 vuex만 잘 관리한다면 컴포넌트 구성을 고정한 상태로는 비교적 변화에 유연하게 코드를 구성할 수 있다. 그래서 결과적으로 아래와 같은 구성이 되었다. 정적인 데이터 textMap은 lookup 컴포넌트에서 읽어서 자식 컴포넌트에 전달을 하고, 동적인 상태값들은 각 컴포넌트에서 vuex를 사용하도록 했다. vuex에서는 동적인 상태값들을 관리하고, 저장된 상태값을 사용하여 api 통신도 담당한다. 마지막으로 다음 글에서는 이번 프로젝트에서 vuex를 어떻게 사용했는지를 정리하겠다.","link":"/2020/10/26/brandi-internship-2/"},{"title":"Brandi Internship - Part 3","text":"코드 리뷰처음 브랜디 인턴쉽 기간에는 매주 2번씩 코드 리뷰가 진행되었다. 각 팀에서 현재까지 구현된 내용과 코드들을 리뷰 받는 시간이었다. 프론트의 경우에는 코드를 어떻게 구성했는가 보다는 기능을 구현할 때 어떤 요소들을 고려했는지를 더 많이 질문 받았었다. 필터링된 값들을 쿼리스트링으로 붙이면 어떨까요?피드백 받은 내용들은 대부분 사용자의 편의성에 관련된 내용들이었다. 예를 들면 페이지가 변경될 때, 페이지들의 구성이 동일하기 때문에 사이드 바에서 다른 페이지를 클릭해도 변경되었다는 것을 바로 알아차리기가 어려웠다. 그래서 페이지가 변경된다는 사실을 사용자가 알 수 있도록 페이지가 바뀌기 전에 로딩 창이 있으면 좋겠다는 피드백이 있었고, 피드백대로 로딩 페이지를 붙여 보았다. 그 결과 로딩 페이지 덕분에 페이지 변경 사실을 훨씬 쉽게 알아차릴 수 있었다. 또 다른 피드백 내용 중에는 vuex 파일을 전부 수정했던 피드백이 있었다. 사용자가 필터링 박스에서 특정 필터 값을 선택하고 검색 버튼을 누른 경우에 해당 필터 값들이 uri에 쿼리스트링으로 붙으면 좋겠다는 피드백이 있었다. 이유는 우선 vue나 react같은 spa 페이지 특성상 라우팅 처리는 실제 서버에 대한 요청이 아니라 js가 dom의 조작하는 트리거일 뿐이다. 때문에 새로 고침이나 뒤로가기를 한 경우에 쿼리스트링이 붙은 uri가 히스토리에 저장되지 않는다면 해당 상태 값들은 유지되지 않는다. 또한 단순히 쿼리스트링만 붙이면 되는 것이 아니고 쿼리스트링을 파싱해서 다시 상태 값으로 저장해 주어야 새로고침이나 뒤로 가기가 반영이 되었다. 문제는 이 로직의 처리가 10개의 컴포넌트를 그리는 일을 담당하는 lookup 컴포넌트에서 담당한다는 것이었다. 이게 문제가 되는 이유는 우선 페이지 마다 사용하는 필터 값이 다르고, 또 다 같다고 하더라도 모든 필터 상태 값을 lookup에서 vuex로 넘기도록 로직을 추가해야 한다. vuex를 사용하기로 결정했을 때, 본래 동적으로 vuex 내부를 구성하도록 하려고 했지만 좋은 구성을 하기 위한 자료 부족 + 공부할 시간 부족 등등의 이유로 페이지 마다 하나의 vuex를 가지도록 만들었다. 문제는 필터 값 하나 하나 마다 getters, mutations, actions 함수가 추가되었기 때문에 상태값 개수 x 3 만큼의 코드가 생성되었고, 페이지간의 값이 동일한 경우도 있었는데 중복이 많이 발생하게 되었다. 중복은 그 자체로도 문제일 수도 있지만, 진짜 문제는 로직의 수정이 필요할 때, 중복된 코드 전부를 수정해야 하는 문제가 계속 발생했다. 결론적으로는 현재의 vuex 로직으로는 쿼리스트링을 uri에 추가하고 다시 상태 값으로 저장하는 로직을 만들수가 없었다. 뭔가 vuex 내부 로직을 추상화할 필요가 있었다. getters를 currying으로 구성하기나는 vuex를 각 페이지 별로 나누어서 구성했고 이를 위해 namespace를 이용한 모듈이라는 기능을 사용했다. 모듈을 사용한 경우 vuex에서 제공하는 helper 함수를 사용하면 vue에서 쉽게 특정 store만 사용할 수 있다. 특히 lookup에는 uri의 마지막 값에 따라서 textMap과 store가 매칭되도록 구성되어 있는데, 이렇게 하기 위해서는 uri 파싱이 먼저 일어나고 그 다음 특정 store와 매칭을 시켜야 한다. 문제는 uri를 파싱하는 타이밍과 store를 매칭하는 타이밍이 같다는 것이었는데, vue에서 undefined값으로 store를 찾게 되어서 계속 오류가 발생했다. 그러나 helper함수의 도움을 받으면 store와 매칭되는 타이밍을 지연시킬 수 있다.(선언 시에는 매칭이 되지 않고, 실행되었을 때 특정 store와 매칭된 getters, dispatch 반환하는 함수를 만들 수 있다.) 맨처음에는 getter가 반환하는 값은 값이기 때문에 추상화를 할 수 없다고 생각해서 상태 값마다, getters, mutations, actions를 만들었다. 그러나 추상화를 하기 위해 구글링을 한 결과 getters를 커링함수로 만들면 인자로 상태의 이름을 받아서 값을 반환하도록 만들 수 있었다. 즉 추상화가 가능해졌다. 추상화가 가능해졌을 뿐 아니라 코드의 길이도 훨씬 줄어들었다. 상태 값의 개수만큼 있었던 함수들이 단 하나의 함수로 줄었고, lookup에서도 추상화된 getters와 actions를 사용하면 되기 때문에 페이지 마다 필터값이 달라도 쿼리스트링 값을 읽고 저장할 수 있게 되었다. 아래의 코드를 보면 getters와 mutation이 인자를 받아서 값을 읽거나 바꾸기 때문에 상태값이 추가 되어도 변경될 필요가 없게 되었다. 1234567891011121314151617181920212223242526272829303132333435363738export default {  namespaced: true, ...   getters: {    getFilters(state) {      return makeQs(state, state.dateValue);    },    getValue: state => key => {      return state[key];    }  },   mutations: {    setValue(state, { key, value }) {      state[key] = value;    },    reset(state) {      const defaultTerm = 3;       state.isLoading = false;      state.selectFilter = '';      state.filterKeyword = '';      state.dateValue = 3;      state.filterDateFrom = fromNow(defaultTerm);      state.filterDateTo = new Date();      state.mdSeNo = [];      state.filterOrder = 'NEW';      state.filterLimit = 50;      state.page = 1;      state.filteredResult = [];      state.page_number = 0;      state.total_order_number = 0;    }  }, ...Colored by Color Scriptercs 인턴쉽을 마치면서..인턴쉽을 시작할 때는 부트캠프 때와 동일하게 클로닝 프로젝트를 맡게 된 것, react가 아니라 vue를 사용하게 된 것, 그리고 구현해야 할 페이지가 많았던 것 때문에 이런 저런 아쉬움들이 있었었다. 그러나 인턴쉽을 진행하면서 이전에 진행했던 클로닝 프로젝트보다 더 큰 규모의 사이트를 설계하면서 패턴을 찾아보고, vue의 장점을 경험해 보고, 피드백 과정에서 코드를 리팩토링하고, 문제를 해결해면서 배우게 된 것이 많았다. 특히 이전에는 기능을 구현하는 것 자체에 초점이 있었는데, 피드백을 받으면서 내가 만드는 사이트 혹은 기능이 사용하는 사용자 입장에서 편리한지, 사용자가 어떤 행동까지 할 것이라고 고려해 봤는지 등 사용자 편의성에 대한 고려를 처음 해보게 되었다. 다만 아쉬웠던 것은 “패턴은 제거되는 것이 아니라 발견되는 것”이라는 켄트 백 아저씨의 말처럼 나의 수준에서는 아직 낮은 수준에서의 패턴 찾기밖에 되지 않았고 vuex의 경우 중복이 존재했다. 그래서 코드가 수정되는 경우 다른 코드들도 수정을 해야하는 일이 발생했다. 또한 10개의 페이지를 그릴 때, 각 페이지에 대한 api를 만든 백엔드 팀원은 3명이었는데, 추상화된 vuex를 사용하기 위해서는 백엔드 팀원이 주는 response json의 형식이 동일해야 했다. 프로젝트 말미에 형식을 맞춰달라는 나의 요청에 백엔드 팀원들이 맞추어 주었지만, 미리 맞추지 못해서 네이밍이나 형식이 다소 부자연스러웠다. 앞으로는 이런 부분까지 미리 고려를 하면 좋을 것 같았다. (저의 요청을 들어준 지원, 해준, 용민님 감사합니다…) 마지막으로 webpack 설정에서 체이닝을 통해 간결하게 환경을 구성할 수 있으면 좋았을 것 같은데, 이렇게 하기 위해서는 많은 공부와 경험이 필요할 것 같다. vue-cli3보다 더 좋은 개발, 배포 환경을 구성하기 위해서는 상당히 많은 공부와 경험이 필요하기 때문에 왠만큼 수준이 오르기 전까지는 그냥 vue-cli3를 사용을 하는 것이 좋겠다는 생각을 하게 되었다.(Evan You도 vue-cli쓰라고 했다. 하하..) 저와 인턴쉽을 진행한 10명의 팀원들 모두 수고 많으셨습니다. 다들 앞으로도 빠이팅이에요 :)","link":"/2020/10/27/brandi-internship-3/"},{"title":"JS 실행 컨텍스트 이해하기","text":"올해 초 회사 내 신입사원들이 진행하는 세미나에서 발표한 내용을 git blog에 옮겨보았다.해당 발표에서는 execution context의 동작 방식과 js가 어떻게 execution context를 바탕으로 closure 환경을 제공하는지를 다루었다. 1. 도입 실행 결과 예측해보기 12345678910111213const x = 1; function foo() {    const y = 2;     function bar () {        const z = 3;        console.log(x + y + z);    }    bar();}; foo(); // 실행 결과는?cs → function foo 는 어떻게 동작하는가? Javascript는 script 언어이다. script언어 특성 상 언어의 해석과 실행은 메모리 위에서 런타임에 이루어 진다. c와 java와 같은 compile 언어는 기계어 혹은 바이트 코드로 번역된 결과물이 실행되지만 Javascript는 텍스트 파일이 해석되고 실행된다. 그렇다면 javascript 코드의 해석과 실행은 어떤 과정으로 이루어 질까? js engine은 javascript 문법으로 작성된 텍스트 파일을 parsing & interpreting 하는데 소스코드라는 단위로 실행한다. 소스코드의 종류 (참조 https://262.ecma-international.org/6.0/#sec-types-of-source-code) 소스코드라는 단어 자체는 우리가 굉장히 흔하게 쓰는 단어이지만 ECMAScript spec에서는 소스코드를 별도로 정의하고 있다. ECMAScript spec을 보면 다음 4개의 타입의 코드를 소스 코드라고 정의하며 javascript engine은 다음 4가지의 소스 코드를 실행의 단위로 생각한다. type 설명 전역 코드   전역에 존재하는 소스코드, 전역에 정의된 함수, 클래스 등의 내부 코드는 포함되지 않는다. (Javascript는 로드와 동시에 바로 해석과 실행이 되기 때문에 c와 Java와 같은 실행 시작 점(main 함수)과 같은 역할을 전역 코드가 담당한다. ) 함수 코드   함수 내부에 존재하는 소스코드(function body)를 말한다. 함수 내부에 중첩된 함수, 클래스 등의 내부 코드는 포함되지 않는다. eval 코드   빌트인 전역 함수인 eval 함수에 인수로 전달되어 실행되는 소스코드 모듈 코드   모듈 내부에 존재하는 소스코드를 말한다. 모듈 내부의 함수, 클래스 등의 내부 코드는 포함되지 않는다. 즉, 위의 소스 코드들은 javascript 엔진에 의해 텍스트가 해석(parsing & interpreting)되면서 동시에 실행(evaluating & executing)되는 대상이다. 이 소스코드가 실행될 때 실행컨택스트라고도 부르는 콜 스택이 생성된다. 실행 컨텍스트는 javascript의 콜 스택이다. 따라서 우리가 실행 컨텍스트가 콜 스택이라는 것을 생각한다면 실행 컨텍스트의 개념이 어렵게 다가오지는 않을 것이다. (물론 이렇게 단순하지는 않고 독특한 특징을 가지고 있다. 앞으로 설명할 것이다.) 실행 컨텍스트를 콜 스택이라고 생각한다면 앞에서 나온 예제 코드의 실행 컨텍스트의 변화를 쉽게 그릴 수 있다. 출처.https://meetup.toast.com/posts/123 4가지 타입에 따라서 실행 컨텍스트 내부의 구성(정확하게는 실행 컨텍스트가 가리키는 렉시컬 환경(Lexical Environment) 내부의 구성)이 달라지는데, 오늘은 중요한 내용인 전역 코드와 함수 코드의 실행 컨텍스트에 대해서만 설명하려고 한다. ❓ Javascript의 콜 스택, 실행 컨텍스트를 이해하는 게 유용한 이유는? Javascript의 호이스팅, 클로저와 같은 특성들이 어떤 동작으로 인해 생기는 지 이해할 수 있다. → 코드의 동작 이해하는 데 도움이 되고, 특히 변수의 스코프를 예상할 수 있다. 오늘 다루지는 않지만 generator의 동작의 기반도 실행 컨텍스트와 Lexical Environment이다. 제네레이터의 동작을 이해하는 데도 도움이 된다. 따라서 오늘 설명의 목표는 실행 컨텍스트의 구성과 동작을 대략적으로 이해해서 Javascript에서의 변수, 함수의 스코프를 예상할 때 도움을 얻는 것이다. 2. 소스코드의 실행javascript 소스코드의 실행은 소스코드의 평가와 소스코드의 실행이라는 2개의 과정으로 나뉜다. 아래의 예제를 가지고 2개의 과정을 살펴보겠다. 12345678function foo() {  var a = 1;  let b = 2;  const c = 3;  function bar() {}} foo();cs 그 전에 Quiz ❓ 위의 코드는 앞의 소스코드 정의에 따르면 2개 종류의 소스코드가 존재한다. 어떤 코드들이 존재하는가? 정답은? 전역코드 foo 함수 코드 따라서 위의 코드의 실행에서는 2개의 실행 컨텍스트가 생성될 것이다. 그러면 소스코드의 실행 시점 중에서 실행 컨텍스트는 언제 생성될까? 실행 컨텍스트는 소스 코드의 평가 이전에 생성된다. 실행컨텍스트 생성 → 소스코드 평가 → 소스코드 실행 의 순서로 진행된다. 자바스크립트 엔진은 소스코드를 평가 하기 전에 실행 컨텍스트(Execution Context)와 렉시컬 환경(Lexical Environment)이라는 것을 생성한다. 그 다음 실행 컨텍스트가 렉시컬 환경의 참조 값을 가지도록 한다. 간단하게 그림으로 그리면 아래와 같다. 실제 lexical environment와 environment record는 위의 그림과 조금 다르지만 거의 유사하다. Execution Context Stack이 콜 스택이다. Lexical Environment는 EnvironmentRecord에 식별자와 값의 쌍을 저장하는 Environment Record와 This값이 저장된 ThisValue를 가지고 있다. OuterLexicalEnvironment Reference에는 자신을 생성한 Lexical Environment의 참조 값을 저장된다. 만약 전역 코드라면 OuterLexicalEnvironment Reference이 뭐가 될까? 전역 코드는 자신을 생성한 Lexical Environment가 없기 때문에 항상 null 값을 저장한다. 1) 소스 코드의 평가실행 컨텍스트와 렉시컬 환경이 생성되면 소스코드의 평가가 시작 된다. 소스코드 평가 때는 소스코드에서 변수, 함수등의 선언문만 먼저 실행하여 렉시컬 환경의 환경 레코드에 저장한다. 바로 이 지점이 hoisting이 발생하는 지점이다. 자바스크립트 소스코드에서는 실행 전 평가 시점에 모든 변수들이 이미 environment record에 등록된다. 그래서 123console.log(x) var x = 1;cs 위의 코드를 실행해 보면 ‘x is not defined’ error 가 뜨는 것이 아니라 undefined가 출력 된다. 소스코드 상 var x = 1; 이 console.log(x) 보다 뒤에 있지만 실행 전 평가 시점에 이미 x : undefined 로 등록이 되어 있기 때문에 이런 결과가 나온다. 소스코드의 평가가 끝난 시점에서는 var로 생성된 변수는 등록과 동시에 undefined로 값이 초기화 되고 let과 const으로 선언된 변수의 경우 초기화가 이루어 지지 않고 uninitialized 상태가 된다. 다시 예제 코드로 돌아가보면 123456789function foo() {  var a = 1;  let b = 2;  const c = 3;  function bar() {} } foo(); // 1. Callcs 전역 코드가 실행 되면서 평가 전에 전역 실행 컨텍스트와 전역 렉시컬 환경이 생성될 것이다. 그 다음 평가가 시작되고 전역 코드 내의 모든 변수, 함수 선언 문이 전역 렉시컬 환경의 환경 레코드에 저장된다. foo함수의 경우 평가 후, 실행 전에는 아래와 같은 실행 컨텍스트와 렉시컬 환경이 만들어 진다. (물론 실제로 아래와 같이 구성되는 것은 아니다.) 1234567891011// Running execution context의 LexicalEnvironment {  environmentRecord: {    a: undefined,    b: <uninitialized>,    c: <uninitialized>,    bar: <Function>  },  outer: foo.[[Environment]]}Colored by Color Scriptercs 출처.https://meetup.toast.com/posts/129 3. 실행 컨텍스트와 Lexical Environment의 구성 앞에서는 전역 실행 컨텍스트와 함수 실행 컨텍스트를 구분하지 않고 간단하게 설명을 했는데, 이번에는 예시 코드와 그림을 이용해서 전역 실행 컨텍스트와 함수 실행 컨텍스트의 구성을 더 자세히 살펴보겠다. 123456789101112131415var x = 1;const y = 2; function foo(a) {  var x = 3;  const y = 4;   function bar (b) {    const z = 5;    console.log(a + b + x + y + z);  }  bar(10);} foo(20); // foo 함수 평가 후 실행 전의 실행 컨텍스트와 Lexical Environmentcs 출처.모던 자바스크립트 Deep Dive. 23.6 실행 컨택스트의 생성과 식별자 검색 과정 이웅모 저 전역 객체(브라우저의 경우 window, node의 경우 global) 생성 전역 코드 실행 전역 실행 컨텍스트 생성 전역 렉시컬 환경 생성 전역 환경 레코드 생성 객체 환경 레코드 생성 : 전역 환경을 전역 객체와 연결하기 위해 사용한다.(import 없이 dom과 Math와 같은 빌트인 객체를 사용할 수 있는 이유), var로 선언되는 변수들을 전역 객체의 property로 저장된다 → 콘솔에서 확인할 수 있다. 선언적 환경 레코드 생성 : let, const와 같이 block scope 변수들의 저장 this 바인딩 : this에 전역 객체 바인딩 외부 렉시컬 환경에 대한 참조 결정 foo 함수 실행 함수 실행 컨텍스트 생성 함수 렉시컬 환경 생성 함수 환경 레코드 생성 this 바인딩 (this 바인딩은 이후에 함수에서 따로 설명) 외부 렉시컬 환경에 대한 참조 결정 4. 렉시컬 스코프 vs 다이나믹 스코프오늘 closure에 대해서도 설명을 하려고 하는데 그 전에 잠깐 scope에 대해서 정리해보려고 한다. 실행 컨텍스트는 컴파일 언어의 콜 스택과는 조금 다른 특징을 가진다. 여태까지 설명을 들었을 때는 일반적인 콜스택과 크게 다른 점이 없어 보였는데 어떤 부분이 다르다는 것일까? 바로 실행 컨텍스트가 생성될 때 같이 생성하는 렉시컬 환경 때문에 다른 점이 발생한다. 렉시컬 환경은 실행 컨텍스트 생성 때 같이 생성되는 것은 맞지만 렉시컬 환경을 사용하는 대상이 실행 컨텍스트만 있는 것은 아니다. 아래의 예시를 보자 1234567891011function foo() {  var x = 15;  console.log(x);} function bar() {  console.log(x);} foo(); // 실행 결과는?bar(); // 실행 결과는?cs 정답은? 15 Uncaught ReferenceError: x is not defined 우리가 선언하는 변수는 2가지 특성을 가진다. 하나는 변수가 사용되는 범위인 스코프이고, 다른 하나는 변수가 사용되는 기간인 라이프사이클이다.(두 특성은 잘 혼동되지만 다른 특성이다.) js는 함수 스코프와 블록 스코프 두가지를 제공한다. 함수 스코프는 변수가 사용되는 범위가 함수 내부라는 의미이고, 블록 스코프는 변수가 사용되는 범위가 블록 내부라는 의미이다. 위의 예제를 보면서 scope를 이해해 보자. bar는 변수 x를 사용할 수 없다. 자신의 함수 body 내부에서 x가 선언되지 않았기 때문이다. 반면 foo는 함수 body 내부에 x가 선언되었기 때문에 사용가능하다. 그러면 이제 아래 예시를 보자. 123456789101112function foo() {  console.log(x);} function bar() {  var x = 15;  foo();} var x = 10;foo(); // 실행 결과는?bar(); // 실행 결과는?cs 그렇다면 위의 예시의 결과는 어떨까? 정답은? foo와 bar의 실행 모두 10이 출력 된다. bar 함수에서 foo 함수를 실행한 결과는 왜 15가 아니고 10이 될까? 그건 javascript가 lexical scope 언어이기 때문이다. lexical scope(정적 스코프) 언어는 자신의 스코프에 변수가 없을 때, 자신이 생성된 환경에서 해당 변수를 찾는다.(앞선 예시에서는 bar가 생선된 환경에서도 x가 선언되지 않았기 때문에 에러가 발생했다.) 반대로 dynamic scope(동적 스코프) 언어는 자신의 스코프에 변수가 없을 때, 자신을 호출한 환경에서 해당 변수를 찾는다. 만약에 javascript가 dynamic scope 언어였다면 bar 함수의 실행 결과는 15가 되었을 것이다. 그런데 조금 더 생각해보면 이상하다. var x = 10; 도 실행의 결과인데, dynamic scope 인거 아닌가? 하는 의문이 생길 수도 있는데, 실행 컨텍스트가 생성될 때 실행 컨텍스트는 렉시컬 환경의 참조 값을 가지고 있다는 사실을 기억하자 실행 컨텍스트 생성 이후에 생성하는 렉시컬 환경은 실행 컨텍스트만 참조하는 것이 아니다. 렉시컬 환경 A에서 생성된 함수가 [[Environment]] 에 렉시컬 환경 A의 참조값을 저장하고 있다. 여기서 우리는 실행 컨텍스트가 콜스택일 뿐만 아니라 동시에 렉시컬 환경을 제공해주는 연결점을 얻게 되었다. 렉시컬 환경은 실행 컨텍스트의 입장에서는 실행 환경이 맞다. 그러나 실행 컨텍스트와 렉시컬 환경이 참조 값으로 연결된 다소 느슨한 관계 이기 때문에 실행 환경인 동시에 해당 렉시컬 환경에서 생성된 함수에게는 dynamic scope가 아닌 lexical scope를 제공할 수 있는 것이다. 아래의 예제 코드는 앞의 소스코드의 평가를 설명했던 사용했던 예제인데 우리가 무심코 넘긴 부분이 있다. 바로 outer 값이다. 아래의 렉시컬 환경은 foo 함수 내부의 렉시컬 환경인데 foo 실행 전에 생성된 것이다. foo 함수 내부의 렉시컬 환경의 outer 값을 보면 foo.[[Environment]] 값 즉 foo 함수를 생성했을 때의 렉시컬 환경의 참조 값을 가지고 있다. 즉 예제를 통해 렉시컬 환경이 실행 컨텍스트가 생성 될 때 같이 생성 되지만 생성된 이후에는 실행 컨텍스트에 의해서만 사용되는 것이 아니라 function에 의해서도 사용된다는 것을 알 수 있다. 1234567891011// Running execution context의 LexicalEnvironment {  environmentRecord: {    a: undefined,    b: <uninitialized>,    c: <uninitialized>,    bar: <Function>  },  outer: foo.[[Environment]]}Colored by Color Scriptercs 출처.https://meetup.toast.com/posts/129 정리하면 javascript의 렉시컬 환경은 실행 컨텍스트에게는 실행 환경의 역할을 하고 생성된 함수에게는 lexical environment(정적 환경 - 생성되었을 때의 환경)의 역할을 하게 되는 것이다. javascript 함수가 런타임에 생성되지만 lexical scope을 제공할 수 있는 이유가 여기에 있다. 함수가 렉시컬 환경 값을 [[Environment]]에 저장하고 있기 때문에, 자신의 스코프에 없는 변수를 찾을 때 자신을 호출한 실행 컨텍스트의 렉시컬 환경을 찾지 않고 자신이 생성 되었을 때의 렉시컬 환경을 찾을 수 있는 것이다. 5. Closure “A Closure is the conbination of a function and the lexical environment within which that function was declared.” - MDN Closures클로저는 함수와 그 함수가 선언된 렉시컬 환경과의 조합이다. - MDN문서 Closures “클로저는 자바스크립트의 고유의 개념이 아니다. 함수를 일급 객체로 취급하는 함수형 프로그래밍 언어에서 사용되는 중요한 특성이다.” - 모던 자바스크립트 Deep Dive 24장 클로저 “lexical”이란, 어휘적 범위 지정(lexical scoping) 과정에서 변수가 어디에서 사용 가능한지 알기 위해 그 변수가 소스코드 내 어디에서 선언되었는지 고려한다는 것을 의미한다. - MDN문서 Closures 클로저는 자바스크립트만 가지고 있는 특성/개념이 아니다 . 함수를 일급 객체로 취급하는 함수형 프로그래밍 언어, 여태까지 설명한 내용을 가지고 설명을 하자면 런타임에 함수를 생성하는 lexical scoping 언어라면 모두 가지고 있는 특성이다. 클로저에 대한 설명 자체만으로는 의미가 잘 와 닿지 않지만 앞서서 렉시컬 환경과 함수 객체의 Environment 값에 대해서 설명을 했기 때문에, 함수와 그 함수가 선언된 렉시컬 환경과의 조합이라는 말이 어렴풋하게는 이해가 될 것이다. (안된다면 여태까지 설명한 것 실패…) 예제를 살피면서 클로저가 어떤 상황에서 그 특성이 부각되는 지 알아보려고 한다. 아래의 예제를 보자. 1234567891011const outerFunc = () => {  let i = 100;  const innerFunc = () => {    console.log(\"In innerFunc, the i is \" + i);    return i + 1;  };  i = innerFunc();  console.log(\"In outerrFunc, the i is \" + i);}; outerFunc();Colored by Color Scriptercs 위의 예제를 보면 outerFunc 함수 내부에 innerFunc가 생성되고 innerFunc의 실행이 outerFunc 실행 내부에서 이루어 진다.이런 경우에도 클로저라고 할 수 있을까? 클로저라고 할 수 있다. 하지만 클로저로서의 의미가 없는 클로저이다.앞서 변수에는 2가지 특성이 있다고 했는데 위의 예제에서 만들어진 클로저는 변수의 라이프 사이클이 outerFunc의 실행 종료와 함께 종료되기 때문에 의미 있게 사용되지 못한다. 그러면 이번에는 의미가 있는 클로저의 예제를 보겠다.아래의 소스코드를 보면 outerFunc를 실행할 경우 outerFunc 함수 내부에서 생성한 innerFunc를 반환한다. 이런 경우는 소스코드의 진행이 어떻게 될까? 1234567891011121314const outerFunc = () => {  let i = 100;  const innerFunc = () => {    console.log(\"It's external the i is \" + i);    return (i = i + 1);  };  return innerFunc;}; let foo = outerFunc(); foo();foo();foo();Colored by Color Scriptercs 위의 예제에서는 outerFunc 내부에서 생성한 innerFunc가 변수 i를 가지고 있는 클로저가 외부에 반환된다. 따라서 외부에서 클로저를 사용할 수 있기 때문에 의미 있는 클로저가 만들어졌다. 이번 주제에서는 클로저가 주요 주제가 아니기 때문에 클로저를 사용한 예를 다루지 않았지만 간단히 예를 들어보면 이벤트 핸들러롤 넘기는 함수를 다른 변수들과 함께 넘기고 싶다면 외부 함수를 만들어 매개변수를 받게 하고 해당 매개변수를 사용하는 이벤트 핸들러 함수를 반환하는 클로저 함수를 만들 수도 있다. 그외에도 클로저를 활용하여 클래스의 static 변수를 만드는 예도 있다. 여기서 기억할 점은 다이어그램에서 다 표현하지 못했지만 클로저가 생성되기 위해서는 내부 함수가 자신의 스코프에서 생성하지 않은 변수, 즉 렉시컬 환경에서 생성된 변수를 사용하고 있어야 한다는 것이다. 자신의 스코프에서 생성하지 않았지만 렉시컬 환경을 이용하여 사용할 수 있는 변수들을 자유 변수(free variable)이라고 한다. 클로저는 함수실행이 종료된 이후에도 내부 함수가 외부로 반환되면서 생기는 자유 변수들이 갇힌 공간이다. 만약에 내부 함수가 자유 변수를 사용하고 있지 않다면 자바스크립트 엔진은 최적화를 위해서 내부 함수의 렉시컬 환경을 제거한다. 또한 렉시컬 환경의 변수가 여러 개일 때, 일부의 자유 변수만 사용하는 경우에도 사용하는 자유 변수를 제외하고는 다 제거한다. 참고 자료 모던 자바스크립트 Deep Dive. 이웅모 저 ECMAScript® 2015 Language Specification JavaScript 식별자 찾기 대모험 NHN Cloud Meetup! 블로그 자바스크립트 함수 (1) - 함수 객체, 함수 객체 생성 자바스크립트 함수 (2) - 함수 호출 자바스크립트 함수(3) - Lexical Environment 코드스피츠 78 ES6+ 함수와 OOP 2회차 스터디","link":"/2021/02/25/seminar-execution-context/"},{"title":"코드숨 React 5기 - 1주차 회고","text":"1주차 주간 회고 Facts 웹팩, 바벨 내용 학습 코드숨 1주차 과제 수행 1-1 변수를 외부에 선언하지 않고 count 앱 만들기 1-2 변수를 외부에 선언하지 않고 간단한 사칙연산 계산기 만들기: 기한 내 제출 못함 토스 코딩 테스트 참가 Feelings 웹팩, 바벨을 작년 인턴쉽 때 vue-cli를 사용하지 않고 직접 개발 환경을 세팅할 때 학습한 경험 덕분에 관련된 내용들을 다시 읽었을 때 낯설지는 않았다. 다만 작년에는 빠르게 개발 환경을 만들기에 바빠서 환경 하나하나 추가하면서 빌드된 결과물이 어떤지는 확인하지 않았던 것을 깨달았고, 개발자로서 어떤 태도로 학습을 하고 업무를 진행해야 될지 고민하게 되었다. 작년에 인턴쉽 때 세팅했던 웹팩, 바벨 설정 파일을 다시 보면서 내가 이해하고 설정한 부분과 그 설정의 결과물을 제대로 확인하지 않고 넣었던 부분 모두를 보게 되었는데, 내가 확인하지 않은 설정이었다면 넣지 않는 것이 맞지 않았을까? 하는 생각을 하게 되었다. 애초에 코드숨 교육을 신청한 이유는 개인 공부에서는 받을 수 없는 피드백을 받기 위해서 인데, 그 목적에 맞지 않게 1주를 보냈다. 늦은 제출 - 1-1 과제를 수요일 저녁부터 시작했는데, 그 마저도 깃헙 레포 문제로 목요일에 제출하게 되었다. 1-2 과제도 늦게 시작하는 것에 영향을 주었고, 더 많은 피드백을 받을 기회를 잃어버렸다. 적은 pr - 일요일에 되서야 다른 분들의 pr을 보면서 현재 코드숨을 진행하는 내 방식이 잘못되었다는 것을 깨닫게 되었다. 다른 분들은 조금씩 만들면서 바로바로 pr을 보내고 피드백을 받아서 그 피드백을 반영하는 방식으로 진행했던 반면, 나는 늦게 시작했음에도 한꺼번에 만들어서 pr을 올리려고 하다보니 피드백을 받을 기회를 또 잃어버리게 되었다. 토스 코딩 테스트는 1시간 반의 코딩 테스트와 30분의 서술 테스트로 진행되었는데, 결론적으로 느낀 점은 요구사항을 제대로 확인하는 습관의 부족: 습관은 마음이 급할 때에도 그렇게 행동하도록 하는데 아직 요구사항을 제대로 확인하는 것이 습관이 되지 않은 것을 느꼈다. 이런 행동으로 인해 시간을 더 많이 사용하게 되었다. 기본적인 내용의 경험 부족: 총 문제가 8문제였다. 각각의 문제는 난이도가 높은 것이 아니었는데, js의 기본적인 기능이나 내용을 실제 서비스에서 고민해보고 적용해본 경험이 있는 사람들, 기능의 활용이 몸에 익은 사람들은 빠르게 풀 수 있는 문제였던 것 같다. 나는 아직 그런 내용들을 한번 공부해본 수준이었다는 것을 느꼈다. Findings 항상 hello world를 찍어보는 작은 습관처럼, 수 많은 설정들의 결과를 한번에 확인하는 것이 아니라 자주 사용하는 각각의 설정들이 어떤 빌드 결과물을 내놓는지 보면서 각 설정의 역할을 잘 알고 사용하는 게 필요하다고 느꼈다. 앞으로는 서비스를 만드는 사람으로서 내가 작성한 코드에 좀 더 책임감을 가져야 할 것 같다는 생각을 하게 되었다. 빠른 시작과 빠른 pr을 통해 더 많은 피드백을 받아야 겠다고 생각했다. 연습의 중요성. 정권 찌르기 100번. Affirmation 서비스를 만드는 개발자로서 내가 책임을 지는 제품을 만들 수 있는 태도와 역량을 기르자. 그런 태도와 역량을 기르기 위해 매일 꾸준히 과제를 하고 학습한 내용을 정리하자.","link":"/2021/08/15/codesum-week-1/"},{"title":"코드숨 React 5기 - 2주차 회고","text":"2주차 주간 회고 Facts 코드숨 2주차 과제 수행 2-1 React로 간단한 Counter 앱 구현 2-2 React로 간단한 Todo 앱 구현 HTTP 완벽 가이드 공부 Feelings 코드 포매팅, 변수명 등 코드 작성 때 가독성을 위해 고려하는 기본적인 요소들을 많이 지적받았다. 그만큼 기본적인 부분을 많이 놓치면서 코드를 작성했다는 의미이다. 지금이라도 피드백을 받을 수 있어서 다행이라고 생각했다. 코드가 가독성을 가지려면 2가지: 내가 의도한 바가 있어야 하고, 그 의도한 바가 표현되어야 한다. 아직은 코드에 의도를 잘 담는 연습이 더 필요하다고 느꼈다. 그리고 좋은 의도를 담으려면 좋은 설계에 대한 일반적인 원칙들을 잘 알고 있어야 하지 않을까 하는 생각도 들었다. 피드백을 받으면서 컴포넌트 설계(?)를 어떻게 해야하는 지 처음으로 고민을 하게 되었던 것 같다. 이전에는 컴포넌트 분리의 목적은 한가지였다. 커다란 컴포넌트를 더 작은 단위의 컴포넌트로 분리하는 것. 그저 작은 컴포넌트로 나누는 것에만 집중했기 때문에 나누어진 컴포넌트에 props를 통해 넘기는 값들(상태 값, 상태 변경 함수)을 어떻게 구성해서 넘길 지는 고려해보지 않았다. 첫 번째로 지적받았던 것은 count값을 변경하는 setCount 함수를 하위 컴포넌트가 props에서 setCount라는 이름으로 바로 받아서 사용한 점이다. 사실 하위 컴포넌트는 onClick 이벤트가 발생했을 경우 위임받아서 실행할 함수가 궁금하지 그게 구체적으로 setCount인지는 궁금하지 않다. 따라서 하위 컴포넌트의 인터페이스로 setCount는 너무 구체적인 정보이다. 결론적으로 하위컴포넌트가 외부에 공개해야 할 적절한 인터페이스는 자신이 그릴 상태 값 + 자신이 처리해야 할 이벤트이다.(항상 그런걸까? 좀 더 구체적인 정보가 더 적절한 상황은 없을까? 하는 의문은 있다. 이 지점에서도 역시 좋은 설계에 대한 일반적인 원칙들을 잘 알아야 할 필요성을 느꼈다.) HTTP 완벽 가이드 공부를 매일 20페이지 정도 꾸준히 읽기로 했는데 제출한 과제 피드백을 반영하고 나면 매일 20페이지를 읽는게 녹록하지 않다… Findings 의도를 담은, 의도가 잘 드러나는 코드를 짜는 연습의 부족함 컴포넌트 구현시 외부에 공개할 적절한 인터페이스가 무엇인지 고민해야 한다는 점 좋은 설계에 대한 일반적인 원칙들을 꾸준히 학습해야 할 필요성(어떻게 공부하면 좋을지는 고민이다.) 체력의 부족 Affirmation 적절한 컴포넌트 구성과 관련된 자료를 읽어보기 우선은 여기 매일 30분 조깅하기 HTTP 완벽 가이드 공부 20페이지 읽기 꾸준히 지속하기","link":"/2021/08/22/codesum-week-2/"},{"title":"코드숨 React 5기 - 3주차 회고","text":"3주차 주간 회고 Facts 코드숨 3주차 과제 수행 작성된 todo app에 테스트 작성하기 HTTP 완벽 가이드 공부 못함 Feelings 처음으로 직접 테스트 코드를 짜보았다. 문제는 갑자기 여러 일들이 몰려서 충분히 고민하고 테스트 코드를 짤 시간이 부족했다. 앞으로는 출퇴근 시간에 과제에 대해 고민해보는 것이 좋을 것 같다. 과제를 제출하는 것에 딱 맞춰서 과제를 진행하게 되었다. 과제에서 요구하는 것보다 항상 조금 더 진행하는 것을 목표로 두고 과제를 해야겠다. 테스트는 인터페이스를 테스트 해야한다고 들었는데, 컴포넌트에도 동일한 기준이 적용되는 지도 궁금하다. 이 의문을 계속 가지고 앞으로 과제를 진행해야겠다. 한번 루틴이 깨지면 그 뒤에 와르르 무너지는 것 같다. 기대에 못미치더라도 조금만이라도 공부를 진행해봐야 겠다고 생각하게 되었다. Findings 출퇴근 시간을 활용할 필요성 단순히 과제를 하는 것에 머무르지 않는 태도 루틴이 한번 깨지면 지속하던 것들이 금방 무너진다. 다시 루틴으로 한번에 돌아가려고 하지말고 조금씩이라도 돌아가야겠다. Affirmation 출근/퇴근 지하철 안에서 과제 고민해보기 조금씩 다시 루틴으로 돌아가기","link":"/2021/08/29/codesum-week-3/"},{"title":"코드숨 React 5기 - 4주차 회고","text":"4주차 주간 회고 Facts 코드숨 4주차 과제 수행 To-do 리스트 Redux를 사용하여 리팩터링 하기 레스토랑 정보 확인 및 예약 시스템 구축하기 Feelings 예전에 단지 prop drilling 문제를 해결하기 위한 방식으로 redux를 선택하는 것을 비판하는 Kent Dodds의 글(번역)을 읽었었다. 그리고 결과적으로 데이터를 redux에 캐싱하게 되서 서버와 데이터 불일치를 발생시킬 수 있는 것을 지적한 글 한재엽님의 글도 읽었었기 때문에 redux를 많은 기술 스택에서 채택하는 이유가 궁금했었다. 4주차 강의와 과제를 통해서 상태, 상태를 처리하는 로직과 뷰를 분리하는데에 있어서 redux가 유용하다는 것을 깨달았다. 예전에 redux를 사용했을 때에는 단순히 컴포넌트에 직접 redux state를 붙여서 사용했기 때문에 해당 컴포넌트는 재사용이 불가능했다. 하지만 이번 과제를 통해서 redux state를 사용하는 부분과 컴포넌트 사이에 컨테이너를 위치 시키면 redux state를 사용하는 부분과 컴포넌트가 느슨하게 연결되도록 구성하도록 할 수 있고 변경에 좀 더 유연하도록 구성할 수 있다는 것을 알게 되었다. 기능 구현에 있어서 사용 목적을 분명하게 하고 redux가 제공해주는 이점을 잘 고려해서 사용을 해야 되겠다고 생각했다. TDD를 하기 위해서는 구현하고자 하는 기능이 명확해야 한다는 것을 깨달았다. 너무 당연한 이야기 인데, 테스트 작성 시에 무엇을 작성해야 하는 지를 명시해야 하는데 쉬운 기능을 구현하는데도 불구하고 이 부분이 명확하게 적히지 않는 것을 깨달았다. 그리고 부모 컴포넌트와 자식 컴포넌트 간에 다소 중복되는 테스트가 존재한다고 느끼는 지점들이 있었는데, 이 부분은 내가 해당 컴포넌트가 어떤 역할을 했으면 좋겠는지가 명확하지 않았기 때문에 발생한 문제 같았다. 테스트 문법이나, 테스트 도구가 제공하는 기능들을 잘 모르는 상태에서 작성을 해서 관련된 피드백을 계속 받았다. 테스트 도구가 제공하는 기능들이 어떤 도움을 주는 지에 대해서도 공부가 필요하다고 느꼈다. Findings 해결하고자 하는 문제를 명확하게 해야 적합한 도구를 사용할 수 있다.(해결하고자 하는 문제에 데이터 정합성이 매우 중요한 요소라면 redux는 적합하지 않은 기술일 수 있지만, 관심사의 분리, 컴포넌트 변경이 잦는 문제를 해결할 때는 redux가 유용한 도구인 것 같다.) 테스트 작성 전에 구현하고자 하는 기능이 무엇인지 고민해야 하고 작성한 컴포넌트를 분리한다면 분리할 컴포넌트의 역할이 무엇인지 잘 고민하고 분리해야한다. 의미가 잘 전달되는 테스트를 작성하기 위해서 테스트 도구 기능들을 알아야 할 필요성(공부해야 될 건 항상 많다….) Affirmation 과제풀이와 같은 과정을 영상을 보지 않고 진행해보기(부디…) 피드백 받았던 부분을 포함해서 테스트 도구가 제공하는 기능들 학습하고 5주차 과제에 적용해보기","link":"/2021/09/06/codesum-week-4/"},{"title":"코드숨 React 5기 - 5주차 회고","text":"5주차 주간 회고 Facts 코드숨 5주차 과제 수행 레스토랑 조회 구현하기 Feelings 과제 첫 테스트 작성 시에, 테스트 내용에 redux에 대한 mock이 포함되어 있었다. 그런데 이렇게 작성을 하다보니 mock을 한 redux 초기 상태를 어디에 위치시켜야 할지 혼동이 왔다. 이에 대해 처음부터 redux에 대한 mock을 추가하지 말고 먼저 컴포넌트가 제공해야 하는 기능들을 가장 쉽고 빠르게 작성한 뒤에 green을 통과 하고 나서 mock이 필요한 부분을 찾아서 mock을 추가해야 한다는 피드백을 받았다. 피드백 대로 redux에 대한 mock을 다 지우고 화면을 그리고 기능을 만족하도록 빠르게 작성하고 리팩터링을 하는 방식으로 진행을 했더니 테스트 작성과 코드 구현이 처음보다 수월하게 진행되었다. 처음부터 redux를 넣으려고 했던 것은 여러 단계를 뛰어 넘고 진행하려는 욕심때문이었는데, 다소 지루하더라도 쉽고 빠른 구현 이후에 리팩토링하는 방식으로 진행해야 겠다고 생각했다. redux thunk의 경우에는 테스트를 어떻게 작성해야 할 지 고민이었다. api 통신 부분을 mocking하고 이후에 mocking한 데이터 결과를 action으로 잘 넘기는 지를 테스트 해야하는 지 고민했는데, 결과적으로 나는 테스트를 통해 어떤 피드백을 받기를 원하는가?가 항상 어려운 지점이라는 것을 느꼈다. fetch에 대한 mocking을 어떻게 하는지 글을 찾아보다가 이 글을 읽게 되었는데, 많은 부분을 이해하지 못했지만 중요한 지점이라고 생각한 것은 그 테스트가 실제로 나에게 무엇을 보장해 주는지를 생각하고 테스트를 작성하는 가?라는 질문이었다. 아직 thunk 테스트에서 무엇을 확인해야 할지 감이 잘 잡히지 않았다. 결론적으로 redux thunk 관련된 테스트 작성은 과제 풀이의 도움을 받아야 겠다고 생각했다. 3주차 과제 피드백에서 beforeAll, beforeEach등으로 안전한 테스트를 제공할 수 있다는 내용이 있었는데, 테스트 관련 자료들을 읽으면서 테스트 작성 시에, 특히 mock을 구성할 때 앞서서 작성한 mock이 다른 테스트에 영향을 미칠 수 있는 지점에 대해서도 고려를 해야된다는 것을 알게 되었다. 역시 피드백 내용은 그냥 한귀로 흘리면 안된다는 것을 느꼈다…(잘 몰라서 중요한 걸 들어도 놓치는 것 같다…) Findings 지루하더라도 컴포넌트가 제공해야 할 최소한의 기능 명세와 빠르고 쉬운 구현, 이후에 리팩토링을 해야한다. 테스트를 통해 어떤 피드백을 받고 싶은 지 생각하면서 테스트 작성해야 한다. 기계적으로 아무 생각없이 이전에 작성했던 테스트 코드를 다시 작성하면 안된다. 테스트에 mock이 자주 등장하는 데, mock이 테스트 할 때 왜 필요한지 몰랐다. 이 글을 읽은 덕분에 mock의 목적이 독립적인 단위 테스트 구성을 위한 것임을 알게되었다. 상황에 따라 참이 되거나 거짓이 되는 테스트는 우리에게 아무 것도 보장해주지 않기 때문에, 테스트 결과를 신뢰하기 위해서는 단위 테스트는 항상 동일한 실행 결과를 보장해야 한다. 그러나 다른 함수에 의존하는 함수의 경우에는 의존하는 함수가 항상 같은 결과를 주지 않는 경우(예. fetch response) 테스트 결과는 항상 같은 결과를 보장할 수 없다. 따라서 의존하는 함수나 객체를 흉내내는 함수나 객체가 필요하고 해당 함수나 객체를 test double이라고 부른다는 것을 알게 되었다. test double은 많이 들어봤고, spy, stub… 각각의 차이들도 읽어봤는데 근본적으로 해당 test double들이 어떤 맥락에서 사용이 필요한지를 알게 되었다.(아주 조금 알게 되었다. 언제나 그렇듯 갈길이 멀다…) 각각의 테스트가 독립적으로 동작하는 지 고려하고 작성해야 할 필요성 Affirmation 좀 더 생각하면서 테스트를 작성하고, 욕심부리지 않고 tdd로 과제를 수행하기 thunk에 대한 test와 fetch mocking에 대한 내용 정리하기","link":"/2021/09/13/codesum-week-5/"},{"title":"코드숨 React 5기 - 6주차 회고","text":"6주차 주간 회고 Facts 코드숨 6주차 과제 수행 레스토랑 상세 페이지 구현하기 Feelings 상세 페이지 구현 시, tdd를 하는데도 불구하고 여러 단계의 작업을 한번에 한다는 피드백을 받았다. 역시 쉽지 않다. 아직까지도 “짧은 주기로 피드백”에서 짧은 주기가 불편하고, 그림이 잘 그려지지 않는다. 왜 그런가를 생각해봤을 때, 컴포넌트에 대해서 짧은 주기에 어떤 피드백을 보고싶은지를 모르기 때문이라는 생각이 들었다. 그래서 리액트 컴포넌트에서 나는 무엇을 확인해야 하는지를 다시 되짚어 봤다. 우선 리액트의 전략은 상태 값(state)의 변화가 렌더링의 트리거가 되도록 하는 것이다. 그렇다면 리액트에서 우리가 확인해야 하는 것도 명확하다. 해당 컴포넌트에 상태 값이 주어졌을 때(input) 어떤 화면을 그리는가?(output). 좀 더 rtl(react testing library)의 접근 방식에 따라서 말하면 해당 컴포넌트에 어떤 화면 요소가 표시되어야 하는가?를 확인해야 한다. 여기서 테스트에 대해서 좀 더 생각을 해보면 테스트의 대상이 되는 함수는 결정적이고(deterministic) 부수 효과(side effect)가 없는 순수 함수이어야 한다. 같은 세팅(입력, 환경)에 대한 결과 값이 그 때 그 때 다른 함수라면, 해당 테스트가 주는 피드백은 의미가 없어지기 때문에 테스트하기 어려운 함수(비결정적이고 부수효과가 있는 함수)에 대해서는 테스트를 작성하지 않는다.(작성하지 않는다기 보다는 해당 테스트 결과를 독립적으로, 결정적으로 만들기 위해 다른 도구의 도움을 받아서 작성한다.) 이 관점에서 컴포넌트 또한 순수함수로 작성되어야 한다. 즉, 앞에서 말한 리액트가 화면을 그리는 방식을 생각해봤을 때, 해당 컴포넌트는 주어진 상태 값에 따라서 그려지는 화면 요소가 결정적이고 부수효과가 없어야 한다. 그런데 많은 경우 이런 제약이 깨진다. 컴포넌트 내부에서 상태 값을 결정하기 위한 도구로 useSelector를 사용하는 경우에는 해당 컴포넌트가 비결정적이게 되고, useEffect를 사용하는 경우에는 부수효과가 발생한다. 이런 경우 mock의 도움을 받아서 useSelctor가 반환하는 상태 값, 혹은 useEffect를 통해 제공되는 상태 값을 고정적으로 제공하는 방식으로 독립적인 컴포넌트를 구성한 후 테스트한다. 결국 테스트 하기 어려운 컴포넌트들도 mock의 도움을 받는다면 “해당 컴포넌트에 상태 값이 주어졌을 때(input), 해당 컴포넌트에 어떤 화면 요소가 표시되어야 하는가?”를 확인하는 방식으로 해당 컴포넌트가 제대로 구현되었는지에 대한 피드백을 제공받을 수 있다. 여기서 내가 한 단위의 작업의 크기가 혼동하는 지점이 발생되었다. 화면 요소를 표시하기 위해 어떤 상태 값이 제공되어야 하는지, 더 정확하게는 해당 상태 값이 어떤 방식으로 제공되어야 하는지?는 해당 컴포넌트 인터페이스 설계에 해당하는데, 이 설계는 리팩터링의 바운더리가 되기 때문에 인터페이스 설계는 테스트 이전에 결정되어야 한다. 그런데 컴포넌트를 분리하는 과정에서 컴포넌트의 설계가 변경되는 지점이 발생하고 이 과정에서 한 단위의 작업의 크기가 불분명한 지점이 있었다. 해당 지점은 컴포넌트에서 useSelector나 useEffect를 사용하여 상태 값을 제공받도록 변경하는 지점이다. 맨 처음 컴포넌트를 분리할 때는 props로 상태 값을 부모에서 받아서 그리도록 인터페이스가 설계된 컴포넌트가 상태 값을 부모에게 받지 않고 useSelector를 통해서 redux store에서 값을 받아오도록 할 때, 이 경우에는 설계가 변경되는 것이지 리팩터링이 일어나는 것이 아니다. 기존에 하나의 컴포넌트였던 부분을 redux 값을 받아오는 container와 받은 값을 그리기만 하는 component로 분리하는 과정에서, 기존에 작성된 테스트는 설계가 변경되었기 때문에 무의미한 테스트가 되어버리지만 red 피드백을 계속 보낸다. 당장 나에게 필요한 피드백은 무엇일까? 우선 무의미한 피드백을 계속해서 전달하는 기존의 테스트를 다 삭제를 하는 것이 먼저일까? 잘 모르겠다 container에 대한 테스트와 component에 대한 테스트 중에서는 무엇을 먼저 작성하는 것이 좋을까? 결국 설계의 변경으로 인해 발생한 모든 작업이 하나의 작업으로 묶여서 진행되었고 커밋되었다. 이 작업은 나에게 왜 혼동을 주는 것인가? 생각을 해보면 컴포넌트를 분리하는 과정에서 어떤 피드백을 먼저 받아야 하는가?를 혼동했던 것 같다. 맨 처음 말했던 대로 어떤 화면 요소가 표시되어야 하는가?가 가장 중요한 피드백이기 때문에 component에 대한 테스트가 먼저 작성되어야 할 것 같다. componenet가 구현된 후에 덜 중요한 피드백인 container에 대한 피드백을 받으면 될 것 같다. 앞으로는 나에게 당장 가장 중요한 피드백이 무엇일까?를 생각하고 작성 우선 순위를 정하면 될 것 같다. 위의 잡소리를 다 제거하고, 아샬님이 5기 슬랙 방에 올려주신 기사글과 동영상의 내용을 정리해보면 결국 인출을 해낼 수 있어야 한다. 휴가 기간 동안 라우팅을 나누고 페이지를 tdd로 작성하는 과정을 인출해봤는데 생각에 의존하기 보다 기억에 더 의존하게 되는 것을 발견했다. 그래도 인출의 과정을 거치는 것 자체가 의미가 있었다. 회사에서 하는 작업에서도 어떻게 적용할 수 있을까 고민인데, 대부분의 작업은 회사에서의 작업이기 때문에, 회사에서 하는 작업물을 tdd를 사용하여 더 신뢰할 수 있도록 할 수 있는 것과 동시에 더 자주 인출을 할 수 있는 장점이 있다. 단점은 회사에서의 작업들은 맥락이 다르기 때문에 내가 한 인출에 대해서 적절한 피드백을 스스로 주기가 어렵고 다른 동료에게 받기는 더 어렵다는 것. 그래서 오히려 잘못된 습관을 반복시킬 수도 있을 것 같아서 우선 코드숨에서나 잘 하고 나중에 조금씩 쉬운 작업물부터 시작을 해봐야 겠다고 생각했다. 멘토님이 피드백에서 mock할 상태 값을 지연 평가할 수 있는 given2라는 라이브러리를 소개해주셨다. 각 테스트에서 mock된 데이터가 무엇인지 더 명확하게 표현되는 것 같았다. 나도 필요한 라이브러리를 적절하게 평가하고 선택하는 능력을 잘 갖추었으면 좋겠다고 생각했다. Findings 나에게 당장 가장 필요한 피드백이 무엇인지 생각하고 작성 우선 순위를 정해야 한다. 학습에는 인출이 중요하다. 인출을 통해 현재까지의 학습 정도를 확인하도록 하자. 필요한 라이브러리를 적절하게 평가하는 선택하는 능력의 필요성. Affirmation 나에게 당장 가장 필요한 피드백이 무엇인지 생각하고 작성 우선 순위를 정해서 구현하기. 내가 제대로 학습했는지는 인출이 가능한지를 통해 확인해보기.(여태까지 진행되었던 내용을 다시 진행해보기)","link":"/2021/09/26/codesum-week-6/"}],"tags":[{"name":"poem","slug":"poem","link":"/tags/poem/"},{"name":"suffering","slug":"suffering","link":"/tags/suffering/"},{"name":"meditation","slug":"meditation","link":"/tags/meditation/"},{"name":"isaiyah","slug":"isaiyah","link":"/tags/isaiyah/"},{"name":"CSS","slug":"css","link":"/tags/css/"},{"name":"macbook","slug":"macbook","link":"/tags/macbook/"},{"name":"keyboard","slug":"keyboard","link":"/tags/keyboard/"},{"name":"volume","slug":"volume","link":"/tags/volume/"},{"name":"containing block","slug":"containing-block","link":"/tags/containing-block/"},{"name":"JS","slug":"js","link":"/tags/js/"},{"name":"lexical scope","slug":"lexical-scope","link":"/tags/lexical-scope/"},{"name":"closure","slug":"closure","link":"/tags/closure/"},{"name":"function","slug":"function","link":"/tags/function/"},{"name":"arrow function","slug":"arrow-function","link":"/tags/arrow-function/"},{"name":"TIL","slug":"til","link":"/tags/til/"},{"name":"HTML","slug":"html","link":"/tags/html/"},{"name":"generator","slug":"generator","link":"/tags/generator/"},{"name":"chaining","slug":"chaining","link":"/tags/chaining/"},{"name":"git","slug":"git","link":"/tags/git/"},{"name":"github","slug":"github","link":"/tags/github/"},{"name":"execution context","slug":"execution-context","link":"/tags/execution-context/"}],"categories":[{"name":"개인적인","slug":"개인적인","link":"/categories/%EA%B0%9C%EC%9D%B8%EC%A0%81%EC%9D%B8/"},{"name":"에세이","slug":"개인적인/에세이","link":"/categories/%EA%B0%9C%EC%9D%B8%EC%A0%81%EC%9D%B8/%EC%97%90%EC%84%B8%EC%9D%B4/"},{"name":"묵상","slug":"개인적인/묵상","link":"/categories/%EA%B0%9C%EC%9D%B8%EC%A0%81%EC%9D%B8/%EB%AC%B5%EC%83%81/"},{"name":"Programming","slug":"programming","link":"/categories/programming/"},{"name":"기타","slug":"programming/기타","link":"/categories/programming/%EA%B8%B0%ED%83%80/"},{"name":"CSS","slug":"programming/css","link":"/categories/programming/css/"},{"name":"JavaScript","slug":"programming/javascript","link":"/categories/programming/javascript/"},{"name":"TIL","slug":"til","link":"/categories/til/"},{"name":"HTML","slug":"programming/html","link":"/categories/programming/html/"},{"name":"git","slug":"programming/git","link":"/categories/programming/git/"}]}