브라우저 훑어보기
•Download as PPTX, PDF•
0 likes•56 views
사내 세미나 발표자료 1. 브라우저의 역사 2. 브라우저의 동작 방식
More Related Content
What's hot
What's hot (20)
Similar to 브라우저 훑어보기
Similar to 브라우저 훑어보기 (20)
브라우저 훑어보기
- 6. 그럼 우리같은 웹개발자, 특히 프론트엔드 개발자에게 운동장은? Browser!
- 7. • 브라우저의 정의 • 브라우저의 역사 • 브라우저의 구성 • 렌더링 엔진은 어떻게 동작하는가 • 출처
- 8. HTML 문서와 그림, 멀티미디어 파일등 월드 와이드 웹을 기반으로 한 인터넷의 컨텐츠를 검색 및 열람하기 위한 응용 프로그램의 총칭. (Feat. 나무위키)
- 10. 브라우저의 역사
- 11. 최초의 브라우저. NeXTSTEP용의 WorldWideWeb
- 17. 승승장구!
- 18. 그러나
- 19. 끼워팔기
- 20. 인수합병 재단 설립
- 21. 95%!
- 24. 어느덧 2008년… 두둥!
- 29. 크롬 브라우저의 본체!
- 31. 2013년 15버전부터 채택 EdgeHTML을 사용하다가 오픈소스 정책에 대한 중요성을 강조하며 크로미움 도입. 2020 1월 정식 공개 2016년 첫 공개 네이버 사용에 최적화 삼성 갤럭시에 기본 탑재되는 브라우저 2020년 기준 모바일 인터넷 브라우저 점유율 6.77%로 크롬과 사파리에 이어 3위 차지중
- 33. “ 사회적 측면, 그리고 개인의 권한에 대해 보자면 인터넷 기반 기술을 하나의 회사에 넘기는 것은 끔찍한 일입니다. (중략) 크로미움 같은 하나의 기술이 높은 점유율을 차지하면, 개발자나 기업은 크로미움 외 다른 기술은 신경쓰지 않게 됩니다. 크로미움 기술만 테스트하면 되니까요. 이런 상황은 정확히 2000년대에도 있었습니다. 그리고 그 현상은 언제든 다시 일어날 수 있습니다. ”
- 34. Future?
- 35. 광고 아님
- 36. 브라우저의 구성
- 45. 브라우저의 구조, 특히 렌더링 엔진을 이해하는 것이 중요!
- 46. 렌더링 엔진은 어떻게 동작하는가
- 47. 멀티 프로세스 아키텍쳐
- 48. 프레임별 렌더러 프로세스
- 49. 렌더러 프로세스의 스레드들
- 51. DOM Tree
- 52. 여기가 파싱이 완료 되어야만 스크립트들이 정상 동작 가능 GA관련 스트립트인데, DOM과 관련이 없는 코드들이기 때문에 async attribute가 있어 preload-scanner를 통해 미리 비동기로 호출됨
- 53. CSSOM Tree
- 54. Render Tree
- 55. 레이아웃과 페인팅 레이아웃 페인팅 * 위치 잡는 단계 * X, Y 좌표 및 Bound Box의 크기를 계산 * 즉 요소들의 기하학적 형태를 확정짓는 단계 * Render Tree와 이 단계를 묶어서 Layout Tree 생성 단계라고도 하 는 듯 * 계산된 스타일들을 실제 픽셀로 변환하는 과정 * 다른 이름으로 레스터라이징 한다고도 표현
- 56. 기존 방식의 레스터라이징
- 57. 모던 브라우저의 레스터라이징
- 58. <video /> <canvas /> 3D transition will-change
- 62. Main Thread Composite Thread Raster Tread Raster Tread Raster Tread
Editor's Notes
- 여러분들은 혹시 나혼자 산다를 좋아하시나요? 제가 제일 좋아하는 프로인데요.
- 최근에 나혼산에 리치언니 박세리 선수가 자주 나오고 있는데요.
- 얼마전에는 골프 해설을 위해서 골프장에 사전답사를 가는 에피소드를 보았는데요. 여기서 골프장의 상태를 잘 이해하는 것이 골퍼들의 성적에 매우 중요하다고 합니다.
- 물론 이건 축구나 야구같은 타 스포츠에도 동일하게 적용이 되겠죠. 아마 홈에서 경기하는 것이 유리한 이유에 바로 이 운동장 상태를 잘 이해하고 있는 것도 큰 이유중 하나 아닐까 싶은데요
- 그럼 우리같은 웹개발자, 특히 프론트엔드 개발자에게 운동장같은 존재는 무엇일까요? (클릭) 아무래도 브라우저가 아닐까 싶어요! 그런 의미에서 프론트엔드 개발자로서 브라우저와 좀 더 친해지기 위해 이 발표를 준비하게 되었습니다.
- 준비한 내용은 이렇게 구성되어 있습니다.
- 그럼 브라우저란 뭘까요? 브라우저란
- 이 9컷 만화는 브라우저가 하는 일을 간단하게 묘사하고 있는데요. 유저가 어떤 자원을 요청하면 이 URL 주소를 가지고 거점역할의 DNS서버에서 실제 IP를 찾아 호스팅서버로가서 원하는 자원을 찾고 유저에게 전달하는거!
- 이런 브라우저의 역사는 어떨까요? 브라우저는 꽤 재미있는 히스토리를 가지고 있어서 소개를 해볼까 합니다.
- 먼저 가장 처음 나온 브라우저는 팀 버너리스가 개발한 월드와이드웹이라는 브라우저 이 브라우저는 Next사에서 개발한 NeXTSTEP이라는 OS에서 사용되었던 브라우저
- 그리고 이 Next사는 스티브잡스가 애플에서 쫓겨난 이후 설립한 회사이죠. 이런 측면에서 스티브잡스로부터 브라우저의 역사가 시작되었다해도 과언이 아닐 것 같네여.
- 어쨋든 이후 1993년 모자이크라는 브라우저가 출시 이는 최초로 이미지, 음악 등의 멀티 미디어를 표시할 수 있도록 함으로써 브라우저 대중화를 이끌었음
- 이후에는 모자이크를 개발한 마크 앤드린슨이 넷스케이프 커뮤니케이션 설립 넷스케이프 네비게이터를 출시하며 브라우저 시장을 선점해 나감
- 넷스케이프 네비게이터가 출시되고 마크 엔드린슨은 좀 더 동적이고 인터렉티브한 웹페이지를 보여줄 수 있는 방법이 없을까 고민 간단한 스크립트 언어를 브라우저에 내장하기로 결정
- 이후 브랜든 에이치라는 개발자를 고용하여 모카라는 언어를 10일만에 만들도록 하는데, 이 언어는 라이브 스크립트로 불리기도 했으며 나중에는 자바스크립트라는 이름으로 최종 변경하면서 넷스케이프 네비게이터 2.0에 탑재한다.
- 그렇게 넷스케이프 브라우저는 거의 독점체제를 유지하며 승승장구 하게 될 줄 알았다!
- OS시장에서 전세계 시장을 쓸어담은 MS에서 WindowOS에 IE를 기본 브라우저로 탑재하며 유저들은 자연스럽게 IE를 주로 사용하게 되었고, 상대적으로 기업 규모가 작은 넷스케이프사는 결국 주도권을 내주며 수면 아래로… 이게 바로 1차 브라우저 전쟁이라고 함
- 그렇게 시장에 도태된 넷스케이프는 마이크로 소프트에 인수가 됨 일부 후계자들에 의해서 모질라 재단이 설립되었고 새로운 오픈소스 기반의 웹브라우저를 개발하는데 이게바로 파이어폭스 브라우저
- 어쨋든, 넷스케이프를 짓누른 IE는 브라우저 점유율 95%를 차지하며 독점적인 지위를 얻게 된다. 그러나 이러한 독점이 지속되면 항상 발생하는 문제가 있죠. 바로 더 발전하기 위한 노력을 하지 않는다는 것입니다.
- 독접 체제를 유지한 IE는 더욱 개선하기 위한 노력을 거의 하지 않음
- 그러다보니 업데이트도 매우 더뎠고, 성능은 폭망에 트렌드를 따라가지도 못하고 심지어 6버전부터는 표준준수를 하지 않으면서 이곳저곳에서 IE에 대한 불만의 목소리가 나오기 시작하죠.
- 그러던 2008년 구글의 크롬이 영웅처럼 등장합니다. 그리고 빠른 성능과 가벼움을 무기로 빠르게 IE의 점유율을 빼앗아오기 시작하죠.
- 그렇게 점차 브라우저 시장을 장악해나간 크롬은 2012년을 기점으로 완전히 ie를 꺾고 브라우저 시장 1위를 차지하게 된다. 이게 2차 브라우저 전쟁이라네요 그리고 그동안 소홀하게 관리되오던 IE는 점차 점유율을 잃으며 빠르게 내리막을 타게 된다. 2020년 1월 서비스 종료!
- 이제 브라우저 시장은 크롬을 중심으로 형성이 되어있으며 그 외에도 많은 브라우저들이 생겼다 없어졌다 하고 있는데.
- 그중에서도 최근까지는 이 다섯개 브라우저가 브라우저 5대장이라고 불리며 사용되고 있다.
- 여담으로 이 다섯개 브라우저에 대해서 다루는 여러 짤들이 이는데 그중에 몇개 가져와 봤음 첫번째는 각 브라우저의 특징을 나타내주고 있는 사진인데, 나는 제대로 써본적이 없어서 잘 모르곘음, 혹시 아는사람 있으면 설명좀 모르긴 몰라도, IE는 역시 쓸모는 없지만 가끔 까기 좋다며 욕을 먹고 있음 두번째 사진은 총에 비교한건데, 여러 종합적인 것을 총의 화력에 빗댄것 같음. 근데 여기서도 역시 IE는 거꾸로 발사되는 총이라고 마지막은 아마 많이들 보셨을거라 생각하는데, 브라우저계의 리더인 크롬이 선창하면 나머지 브라우저들이 후창하는 것을 묘사하고 있어요. 그런데 빠르게 반응하는 다른 브라우저와는 다르게 IE는 모든 선후창이 끝나고나서 첫번째 대답을 하는것으로 IE의 말도안되는 성능을 놀려먹고 있습니다.
- 다시 본론으로 돌아와서, 방금 제가 크롬을 브라우저계의 리더격이라고 표현했는데요, 그 이유에는 당연히 압도적인 점유율이 있겠지만 또 생각해 볼수 있는것이 바로 크로미움이라는 것 때문입니다. 크로미움은 구글에서 오픈소스로 개발하고 있는 프로젝트인데요.
- 브라우저 기반 기술을 총칭해서 크로미움 프로젝트라는 이름으로 진행이 되고 있습니다. 그리고 크롬은 이런 크로미움에 구글 관련 상표, 플레이어, 구글 api등을 접목하며 만든 브라우저죠.
- 이 크로미움은 오픈소스이면서도 매우 잘 만들어져 있기 때문에 많은 브라우저들이 크로미움을 기반기술로 대체하거나 탑재하여 시장에 출시되고 있다. 우리가 잘 아는 브라우저로는 이 네개가 있는데, 오페라는 13년도 부터 크로미움을 도입하였고, 마이크로소프트는 올해 1월 정식으로 크로미움 기반 엣지를 공개했다. 이게 참 많은 화제가 되었는데, 최근 깃헙과 npm등 을 인수하는 등 오픈소스 정책을 강조하는 마이크로 소프트의 최근 방향성을 반영하였다는 것이 공식 입장. 그리고 뭔가 작년쯤부터 엄청 홍보하고 있는것 같은 네이버의 웨일 브라우저. 제대로 써본적은 없는데, 써본사람들 말로는 생각보다 잘 만들었고 특히 네이버를 사용할 때에 정말 최적화 되어있다고 하더군요. 그리고 마지막으로 삼성 인터넷. 이름을 왜이렇게 지었는지 모르겠지만 여튼, 갤럭시에 기본 탑재되는 모바일 브라우저인데 성능이 매우 좋다고 한다. 크롬, 사파리에 이어서 모바일 점유율 3위라고
- 그리고 크로미움은 브라우저 뿐만 아니라 다른 플랫폼에서도 사용되는 추세인데 대표적으로 크로미움과 node js를 결합해서 만든 플랫폼이 electron이 있져. 우리가 사용하는 슬랙, vscode 등이 electronic으로 만들어진 대표 어플리케이션이져.
- 한편 많은 브라우저들이 크로미움을 중심으로 생겨나다보니 또다시 브라우저시장 독점에 대한 우려가 생겼다. 특히 모질라의 CEO 크리스 비어드는 Goodbye, EdgeHTML 이라는 글에서 크로미움의 시장 독식은 2000년대 IE가 그랬던 것처럼 브라우저 기술의 정체를 가져올 것이다라는 우려를 내비추었죠. 하지만 물론 IE는 내부기술인 반면 크로미움은 오픈소스로 공개되었다는 점에서 완전히 동일한 상황은 아니라고 할 수 있는데요. 그럼에도 불구하고 크로미움이 주로 구글 개발자의 주도로 개발되어 간다는 점에서 완전히 터무니없는 말은 아닌 것 같습니다.
- 과연 모질라 재단의 우려처럼 크로미움의 시장 독식이 브라우저 기술의 발전을 저해하게 될지, 혹은 오픈소스의 장점을 살려 모두에게 이로운 방향으로 계속 발전해 나갈지, 혹은 모질라나 애플같이 구글 크로미움과 경쟁구도에 있는 집단 혹은 기업에서 새로운 혁신이 탄생하게 될지 앞으로 지켜보는 것도 재미있을 것 같습니다.
- 지금까지 브라우저의 역사를 장황하게 훑어봤는데요. 역사 파트를 끝내면서 거의 모든 아이티의 역사라는 책한권 소개하려고 해요. 이런 브라우저의 역사도 자세하게 나와있고, 스티브 잡스가 애플을 창업하고 개인용 컴퓨터를 사용화 하는 이야기부터 최근의 클라우드 혁명까지의 아이티 역사를 소개해주는 책인데 시간떼우기 용으로 꽤 괜찮습니다. 혹시 이런 이야기를 좋아하시는 분들은 이 책을 읽어보시길 추천합니다.
- 그다음은 브라우저의 구성인데요.
- 먼저, 브라우저는 기본적으로 이렇게 구성이 되어 있어요.
- 사용자 인터페이스는 눈에 보이는 것 중 컨텐츠가 표시되는 화면을 제외한 모든것이라고 보면 됩니다. 대충 이런걸 총칭한다고 보시면 되빈다.
- 브라우저 엔진은 사용자 인터페이스와 렌더링 엔진사이의 동작을 제어하는 역할을 하구요
- 렌더링 엔진은 요청한 컨텐츠를 표시해주는 역할을 담당하는데, 브라우저의 구성요소중에 거의 제일 중요하다고 할 수 있죠. (클릭)Css를 작성할 때 붙이는 vendor prefix가 바로 이 브라우저간 렌더링 엔진이 달라서 붙여준다고 보면 됨 (클릭)이런 렌더링 엔진은 앞서 봤던 브라우저 5대장별로 원래는 이렇게 구성되어 있었는데, (클릭)최근에는 많은 브라우저에서 크로미움을 채택하면서 지금은 이 세개의 엔진이 주로 사용되고 있다고 보면 될 것 같음. 렌더링 엔진과 관련된 내용은 뒤에서 조금 더 다룰 것
- 통신은 당연히 네트워크 호출에 사용되는 것이고
- 자바스크립트 해석기는 자바스크립트를 실행하는 엔진인데, 대표적으로 구글에서 개발해 역시 크로미움을 구성하고 있는 V8엔진이 가장 유명
- UI 백엔드는 기본적인 UI를 그리는 녀석인데, OS 마다 다른 사용자 인터페이스 체계를 따름 대표적으로 window와 macos간에 버튼의 디자인이 다름.
- 마지막으로 자료 저장소인데, 이는 쿠키나 인덱스드 디비같은 스토리지를 관리하는 부분임
- 웹개발자로서 이러한 브라우저의 구조를 이해하는 것은 더 빠르고 안정적인 웹사이트를 만드는 데에 큰 도움을 준다. 특히 퍼포먼스의 관점에서 보자면, 네트워크의 속도와 화면이 구성되는 렌더링 시간 이 두가지가 가장 큰 영향을 미치는데, 사실상 네트워크는 우리가 컨트롤하기 좀 어려운 부분이기 때문에 퍼포먼스를 개선하기 위해서는 렌더링시간을 단축하는 것이 가장 빠른 방법 따라서 이부분을 담당하는 렌더링 엔진에 대해서 조금 더 알아보자.
- 지금 부터 나오는 렌더링 엔진에 대한 내용은 모두 구글의 개발자 문서에서 참고하였으므로 크로미움의 렌더링엔진에 해당하는 내용들이고, 일부 타 렌더링 엔진을 사용하는 브라우저와는 조금 내용이 다를 수 있다. 근데 아마 여기서 다루는 내용의 큰틀에서 보면 거의 비슷하지 않을까 싶음.
- 먼저 크롬은 멀티프로세스 아키텍처를 채택하고 있음 이 말은 크롬의 여러 탭이 하나의 프로세스에서 모두 처리되는 것이 아닌 탭마다 렌더러 프로세스가 따로 할당되어 있다는 것을 의미 이 말은 또 바꾸어 말해서 탭별로 렌더링 엔진 인스턴스를 따로 가지고 있다고도 표현하더라. 따라서 하나의 탭이 뻗는다고 해도 다른 탭은 안전하게 잘 동작하는걸 보장할 수 있음
- 또한 탭은 물론이고 한 탭 내에 iframe을 통해 보여지는 교차사이트에 대해서도 각각 별도의 렌더링 프로세스를 할당한다.
- 이런 렌더링 프로세스에는 여러개의 스레드가 생성되어 있음 우리가 보통 브라우저는 싱글 스레드로 이루어져 있다 라고 표현을 하는데, 이때 말하는 스레드가 저 Main 스레드를 의미한다. (클릭) 이 메인스레드에서 대부분의 코드가 실행된다. (클릭)두번째로 워커스레드인데, 이건 웹워커 api를 사용해서 일부 자바스크립트 코드를 워커스레드에서 동작시킬 수 있음. 비용이 큰 연산을 처리할 때 주로 사용한다. (클릭)그 외에도 컴포지터 스레드와 레스터 스레드가 있는데, 얘네들은 화면이 매끄럽게 렌더링될 수 있도록 도와주는 스레드이다. 뒤에 한번 더 설명하는 부분이 있을 것.
- 이렇게 구성되어있는 렌더링 엔진이 네트워크로부터 리소스를 받아 화면에 보여주기 까지의 과정을 critical rendering path라고 부른다. 이 과정은 일반적으로 DOM Tree 생성, CSSOM Tree생성, Render Tree생성, 레이아웃, 그리고 페인팅 이렇게 다섯개의 구간으로 나누는 것이 가장 일반적임 (클릭) 그런데 최신 브라우저부터 레이어라는 개념이 생기면서 레이어화 및 컴포지팅이라는 단계를 추가해서 다루기도 함 이때 처음 말한 5개의 작업들이 이루어지는 곳이 메인스레드이고 그래서 브라우저가 싱글스레드다 라고 흔히들 이야기 하는 것이다.
- 이제 이 단계들을 살펴보겠다. 처음으로 DOM Tree 생성 Dom Tree는 문서의 컨텐츠를 설명하는 객체이다. Tree는 HTML 태그간의 관계를 나타냄 당연히 HTML태그가 많아지면 이 과정이 오래걸리게 됨. 과정은 크게 다섯개로 이루어지는데, 처음에 바이트형태로 받은 코드를 인코딩해서 문자열로 만들고 이를 파서를 통해 파싱해서 각각 코튼을 만든다. 이 토큰을 HTML의 정의에 맞는 노드 객체를 생성하고, 부모자식 관계를 반영한 TREE형태로 구축하면 끝. 만약 이 과정중에 중간에 script 태그를 만나게 되면 스크립트 태그를 실행하는 동안 이 과정은 멈추게 됨.
- 그 이유는 스크립트 내에 dom을 조작하는 코드들이 있을 수 있기 때문, 그래서 일반적으로 스크립트 태그를 body태그에서도 아래쪽에 넣어주게 됩니다. 지금보는 화면은 리액트로 만들어진 페이지를 디버깅도구로 확인하고 있여기서도 마찬가지임 여기서 아래쪽을 보면 GA를 불러오는 script에 async라는 어트리뷰트가 있는데 만약 해당 소스코드 내에 돔을 조작하는 코드가 없다는것이 확실하다면 이렇게 async나 defer같은 속성을 추가함으로써 preload-scanner라는걸 통해 미리 스트립트를 비동기로 불러올 수 있게 되빈다.
- 그 다음엔 CSSOM 트리인데, CSS 역시 파싱을 통해 DOM tree와 유사한 CSSOM tree가 생성된다. 브라우저는 각각의 css rule을 통해서 부모 자식관계와 selector에 기초한 사촌관계를 파악하여 tree를 생성한다. 브라우저는 처음에 user agent style sheet를 적용한다. user agent style sheet은 브라우저가 기본적으로 제공하는 스타일을 의미한다. CSSOM이 tree로 된 이유는 cascade down 개념을 구현하기 위해서 이렇게 됨
- 이렇게 DOM Tree와 CSSOM Tree는 중간중간 Javascript도 실행되는 것도 기다리고 하면서 DOM조작이 될건 되고 최종 결과물이 생성되면 이젠 진짜 렌더단계로 돌입한다. 이 단계에서 두 트리를 통해 실제 렌더링에 사용될 Render Tree를 구성하게 됩니다. 이때 Render Tree에는 실제 화면에 렌더링 될 HTML 정보만 갖게된다. 즉 meta 태그나 script태그같은건 다 제외된다. 또 각 HTML에 css를 적용하면서 display :none으로 설정된 노드들도 렌더트리에서는 최종 제외된다.
- 지금 보시는 애니메이션이 기존 브라우저의 레스터라이징 방식인데요. 실제 viewport내에 들어오는 영역만 그때그때 레스터라이징을 해주고 있습니다.
- 반면 최신 브라우저들은 화면을 여러 레이어로 가각 레스터라이징한 후 조합해서 사용하는 방식을 채택하고 있습니다. 좀더 세련된 방식이죠. 이렇게 레이어로 나뉘어진 화면은 개발자도구의 Layers라는 탭에서 확인해볼 수 있는데, 지금 보는 화면은 클로젯의 대시보드 화면을 구성하고 있는 레이어입니다.
- 몇몇 요소들은 항상 이렇게 레이어로 나뉘어지는데요. 그 대표적인 것은 video와 Canvas입니다. 또한 3D Transition과 css에서 will-change속성이 정의되어 있는 요소들도 레이어로 나뉜다고 하네요. 이렇게 만들어진 레이어상에 어떤 변경요소가 감지되면 이제 그 레이어만 새로 레스터라이징을 하기 때문에 성능이 개선된다. 그런데 이 레이어 인스턴스들도 결국 메모리를 소모하는 녀석이기 때문에 너무 지나친 레이어화는 성능에 문제를 발생시킬 수 있습니다.
- 어쨋든 이런 레이어들은 메인스레드에서 정의되며 그 관계를 가지고 레이어 트리가 생성됩니다.
- 그리고 이런 레이어들을 활용해서 필요한 순서와 위치대로 화면에 배치하는 작업이 바로 컴포지팅이다.
- 이제 잠시 앞에 나왔던 두 그림을 잠시 다시보면 Critical rendering path에 2개의 단계가 추가되었고, 렌더러 프로세스에 컴포칫 스레드와 레스터 스레드가 있다고 잠깐 언급했었는데 지금 하고 있는 내용들이 바로 이것들과 관련된 것들입니다.
- Main 스레드에서 레이어 트리를 완성하면 이걸 컴포짓 쓰레드로 넘깁니다. 이 컴포짓 스레드는 하나의 레이어를 여러 타일로 쪼개서 레스터스레드에게 넘겨 레스터라이징을 요청한다 그리고 그 결과물은 GPU 메모리에 저장한다. 그리고 컴포짓 스레드는 화면에 노출되어야 하는 타일들을 모아 컴포지터 프레임을 생성하는데, 이것들일 GPU로 보내져 화면에 그려지게 된다. 이런식으로 컴포지터 스레드를 활용해서 화면을 그리게 되면 아무래도 메인스레드에서 처럼 자바스크립트등의 실행을 기다릴 필요가 없기 때문에 더 빠르고 부드럽게 애니메이션등을 처리할 수 있게 된다.
- 이런 스레드들의 동작은 개발자도구의 퍼포먼스에서 프로파일링을 하면 어느정도 확인이 가능합니다.
- 지금까지 브라우저가 어떻게 동작하는지 렌더링시 발생하는 주요 동작들을 위주로 소개를 해보았는데요. 사실 공부하면 할수록 끝없는 무언가들이 계속 나오더라구요. 아직 공부할게 한참 남았다는 생각이 들었습니다. 그러다보니 빠진 내용들도 많고, 아직 완벽히 이해하지 못하거나 혹은 잘못 이해하고 있는 부분도 충분히 있을거라고 생각합니다. 만약 그런부분이 있다면 정정해주시면 정말 감사하겠습니다! 혹시 내용을 보충해주실 분이나 혹은 질문 있으신 분 계실까요?